População Alvohttps://www.anacom.pt/render.jsp?contentId=55129
Definição e selecção da amostrahttps://www.anacom.pt/render.jsp?contentId=55130
Controlo de qualidade dos resultadoshttps://www.anacom.pt/render.jsp?contentId=55131
Precisão dos resultadoshttps://www.anacom.pt/render.jsp?contentId=55132
Ponderaçãohttps://www.anacom.pt/render.jsp?contentId=55133
Arquitectura Técnica, Modo de Funcionamento e Detalhe dos Componenteshttps://www.anacom.pt/render.jsp?contentId=55134
População Alvo
A população-alvo é constituída pelos lares de Portugal Continental onde resida pelo menos um indivíduo que utilize a Internet a partir de sua casa, tendo como ISP (Internet Service Provider) um dos seguintes Operadores e Pacotes correspondentes:
|
ISPs Alvo |
Tecnologia |
Oferta Comercial a Analisar |
Oferta Comercial a Analisar |
|
Cabovisão |
Cabo |
10Mbps |
512Kb |
|
Clix |
ADSL |
24Mbps |
1Mbps |
|
Sapo |
ADSL |
4Mbps |
1Mbps |
|
Vodafone |
ADSL |
12Mbps |
1Mbps |
|
Zon |
Cabo |
10Mbps |
512Kb |
As ofertas analisadas correspondem à Oferta mais representativa do Operador.
Definição e selecção da amostra
O método para a selecção da amostra corresponde a uma amostragem probabilística. Foi desenhada uma amostra aleatória estratificada por região (Tabela 6) e, dentro de cada uma destas, por NUTIII, tendo sido seleccionada a partir de listagens de endereços incluídos nas regiões consideradas neste estudo. A estratificação por região foi distribuída proporcionalmente ao número de lares clientes dos operadores e das ofertas em estudo em cada uma das regiões.
Dentro do lar foi seleccionado um dos principais decisores pela contratação do serviço de Internet. Foram excluídos do estudos todos os lares em que pelo menos um dos elementos trabalhasse em entidade ou departamentos relacionados com: ICP-ANACOM, telecomunicações ou estudos de mercado. O recrutamento foi feito por telefone.
Em cada lar foi seleccionado apenas um acesso que durante o período de testes (sete dias), permaneceu reservado à realização dos testes (consultar ponto 2.6 Após controlo de qualidade, foram consideradas 258 medições válidas, que se distribuem da seguinte forma:
|
ISP |
Nº de |
Região |
Nº de |
|
Cabovisão |
52 |
Algarve e Alentejo |
25 |
|
Clix |
52 |
Centro |
57 |
|
Sapo |
51 |
Lisboa |
102 |
|
Vodafone |
53 |
Grande Porto |
39 |
|
Zon |
50 |
Norte |
35 |
Note-se que a distribuição por região teve por único objectivo garantir uma dispersão geográfica das medições e não a obtenção de representatividade estatística.
As regiões apresentadas correspondem a uma agregação das regiões NUTIII:
- Algarve a Alentejo: Alentejo Central; Alentejo Litoral; Alto Alentejo; Baixo Alentejo; Lezíria do Tejo; Algarve.
- Centro: Baixo Mondego; Baixo Vouga; Beira Interior Norte; Beira Interior Sul; Cova da Beira; Dão-Lafões; Médio Tejo; Oeste; Pinhal Interior Norte; Pinhal Interior Sul; Pinhal Litoral; Serra da Estrela.
- Lisboa: Grande Lisboa; Península de Setúbal.
- Grande Porto
- Norte: Alto Trás-os-Montes; Ave; Cávado; Douro; Entre Douro e Vouga; Minho-Lima; Tâmega.
Em cada lar foi realizado um total de 61 medições (9 por dia da semana e 8 por cada fim-de-semana). Em cada indicador, operador e período horário foram realizados pelo menos 3 testes (um teste para o servidor na FCCN e dois para os servidores em ISP internacionais), desta forma tem-se 3 testes X 61 períodos X 52 lares, obtendo-se 9.516 medições por indicador e operador, em média.
A realização dos testes decorreu durante os dias úteis e fins-de-semana entre 5 de Dezembro de 2009 e 17 de Março de 2010 1, conforme a seguinte distribuição horária:
|
Ordem |
Dias Úteis |
Fins-de-Semana |
|
Das 8 às 10 horas |
X |
X |
|
Das 10 às 12 horas |
X |
X |
|
Das 12 às 16 horas |
X |
X |
|
Das 16 às 18 horas |
X |
X |
|
Das 20 às 21 horas |
X |
X |
|
Das 21 às 23 horas |
X |
X |
|
Das 23 à 1 hora |
X |
X |
|
Da 1 às 4 horas |
X |
X |
Controlo de qualidade dos resultados
Em todas as etapas do estudo foi feito um rigoroso controlo de qualidade do trabalho realizado. Na primeira fase, durante o período de recolha dos dados, foi feita uma monitorização regular dos dados recolhidos com vista à detecção de situações anómalas. Alguns exemplos passam pela identificação de velocidades máximas superiores às declaradas pelos participantes, estando, por isso, fora do Universo em estudo, ou velocidades muito baixas justificadas por causas imputáveis ao painelista. Paralelamente, foi solicitado a todos os painelistas, e não apenas nos casos que suscitaram dúvidas, o envio da factura para confirmar a oferta comercial em análise durante o período de testes.
Após as medições, foi feita a identificação de Outliers para posterior análise. Foram eliminados os valores extremos justificados por downtime de servidor(es) ou falhas imputáveis aos painelistas. Os restantes valores, apesar de extremos, foram mantidos uma vez que não foram atribuíveis a outras fontes que não o serviço do operador.
Precisão dos resultados
A precisão dos resultados obtida para uma média, com um nível de confiança de 95%, para um dos indicadores recolhidos (neste caso a velocidade de Download) descreve-se no seguinte quadro:
|
Servidor |
Precisão Absoluta (kbps) |
Precisão Relativa |
||||||||
|
Cabovisão |
Clix |
Sapo |
Vodafone |
Zon |
Cabovisão |
Clix |
Sapo |
Vodafone |
Zon |
|
|
USA |
42,18 |
34,53 |
45,44 |
20,30 |
55,74 |
2.3% |
1.8% |
2.2% |
1.0% |
2.6% |
|
UK |
68,69 |
64,95 |
57,78 |
59,74 |
92,58 |
1.7% |
2.0% |
2.4% |
1.5% |
2.3% |
|
Nacional |
102,98 |
164,45 |
59,17 |
186,08 |
120,04 |
1.4% |
2.6% |
2.2% |
2.0% |
1.5% |
De notar que, para o cálculo da margem de erro, se utilizou a fórmula correspondente a uma amostragem aleatória simples uma vez que não se conhecem os pesos das variáveis de cruzamento.
Para uma leitura mais detalhada das Margens de Erro deve ser consultado o Anexo 6.1.
Ponderação
A cada elemento da amostra foi atribuído um peso que permitiu a inferência estatística para o conjunto da população alvo. O método utilizado para a determinação destes pesos, ou factores de extrapolação, foi o ajustamento por margens que acerta os resultados obtidos a totais conhecidos de variáveis auxiliares com o objectivo de corrigir eventuais distorções observadas na amostra.
Numa primeira fase ponderou-se cada painelista tendo em conta a região e operador a que pertence tendo por base a informação fornecida pelos ISP quanto ao peso de cada região no total dos clientes respectivos da Oferta em análise.
Posteriormente, procedeu-se a um ajustamento que consistiu em substituir os ponderadores iniciais dos indivíduos da amostra pelos ponderadores finais ajustados, sendo estes tão próximos quanto possível dos iniciais, utilizando uma função distância que satisfez as seguintes restrições: para as variáveis Dia da semana e Período, as observações ponderadas das modalidades destas variáveis na amostra, após o ajustamento, ficaram com o mesmo peso dentro de cada operador e servidor.
A determinação destes ponderadores assume-se então como um problema de optimização cujo objectivo é a minimização da distância entre os pesos iniciais e os finais ajustados, sujeita às condições que garantem que as variáveis auxiliares extrapoladas com os pesos finais ajustados sejam iguais aos totais populacionais conhecidos.
Arquitectura Técnica, Modo de Funcionamento e Detalhe dos Componentes
A solução utilizada para a aferição da qualidade do serviço de acesso à banda larga fixa foi a ferramenta IxChariot.
Tendo como objectivo de teste a aferição de qualidade de serviço de ISPs, o IxChariot permitiu medir o desempenho do serviço de acesso à Internet de forma a identificar características descritivas da experiência do utilizador.
IxChariot é uma solução geradora e analisadora de tráfego criando com precisão fluxos de dados entre transacções cliente/servidor, oferecendo fluxos de tráfego reais entre pontos terminais de rede (endpoints) para os mais relevantes protocolos de transporte (TCP, UDP, RTP, IPX).
Figura 6 - Componentes do sistema IxChariot
(Clique na imagem para ver a figura numa nova janela)
Na Figura 6 estão representados os componentes do sistema IxChariot. Os testes são efectuados de um ''Endpoint'' para outro ''Endpoint'', o agendamento e as ordens de execução dos testes são enviados pela ''IxChariot Console''. O Performance Endpoint n+1 corresponde aos agentes de software instalados nos servidores nacionais e internacionais.
Para este serviço a solução consistiu em colocar um ''Performance Endpoint'' nos servidores alvo nacionais e internacionais, alocados para esta aferição. Os restantes Endpoints são agentes de hardware que foram instalados nos lares dos painelistas com ligações banda larga a aferir. A ''IxChariot Console'' fez a gestão e agendamento dos testes entre os vários ''Performance Endpoints'' distribuídos nas redes e o ''Performance Endpoint'' instalado nos servidores nacionais e internacionais (Performance Endpoint n+1) cuja descrição já foi incluída no detalhe dos testes móveis (servidores alvo comuns).
A ''IxChariot Console'' efectuou o agendamento, colecta e armazenamento dos dados obtidos através dos testes efectuados, em conjunto com a aplicação ''Aptixia Test Conductor''.
Como resultado, obtêm-se medidas detalhadas da experiência do utilizador final, assim como medidas indicadoras do desempenho da rede.
O tráfego aplicacional numa rede é dinâmico, o que se traduz numa variedade estatística de medidas de desempenho em constante mudança. Através da distribuição de pontos finais de rede (IxChariot endpoints), o IxChariot permite obter uma imagem da rede em cada instante, permitindo identificar eventuais problemas de desempenho da mesma.
No caso particular das transferências de ficheiros através do Bittorrent (testes Peer-to-Peer) foi implementado uma topologia de teste semelhante a uma transferência por FTP, ou seja incluiu-se em cada transferência apenas 2 peers (um ficou instalado num cliente teste/residência, o outro num servidor alvo). Os testes foram realizados à semelhança dos restantes através do IxChariot (emulação de Bittorrent). Não existe um controlo de largura de banda centralizado da ferramenta, em vez disso cada peer é responsável por tentar maximizar a sua largura de banda de download através de uma variante de um conhecido mecanismo intitulado ''tit-for-tat'' 2. Este mecanismo baseia-se simplesmente num efeito de reciprocidade entre peers quando todos colaboram na partilha dos ficheiros. Ou seja se um peer que inicie um download de um ficheiro mostrar vontade de cooperar, deixando que outros peers realizem em simultâneo o upload desse mesmo ficheiro, vai automaticamente beneficiar de mais velocidade no download. Quando o processo de download é iniciado pela primeira vez os peers por defeito são optimistas e contam todos com a colaboração entre si. Após os primeiros segundos de trocas de ficheiros, caso este optimismo inicial não seja confirmado para alguns peers (disponibilidade para upload), então será exercido o mecanismo chamado de asfixia (choking) da velocidade de upload de uns que significa o download para outros. No caso concreto dos testes efectuados foram utilizados apenas 2 peers configurados da forma mais optimista para que fosse maximizada a largura de banda em ambos os sentidos. Em termos de publicação de resultados foram apresentados os testes referentes ao sentido de download em analogia à transferência por FTP.
-
Arquitectura do Sistema
As unidades de medida (agentes de hardware) foram instaladas em casa dos painelistas, através de envio dos agentes de hardware. Os agentes serão detectados pela solução Discovery Server após instalação correcta.
Figura 7 - Arquitectura do sistema proposto
(Clique na imagem para ver a figura numa nova janela)
O controlo remoto de cada um dos agentes de software foi feito através do ''IxChariot Console'', canto inferior esquerdo da Figura 7, instalado numa máquina independente, proporcionando em conjunto com o ''Aptixia Test Conductor'' o agendamento detalhado através de ordens de trabalho nos domínios do tempo, operador, tecnologia, tipo de aplicação, etc.
-
Identificação do agente
A solução oferecida identificou cada um dos clientes através do IP atribuído. A eventual alteração do IP por refrescamento automático do ISP ou outra situação como a reinicialização da máquina, foi contemplada através de um serviço de DNS dinâmico.
Foi também usado um código único no momento da instalação para verificação do registo a cada execução da aplicação.
1 Interrupção de medições entre os dias 23 de Dezembro de 2009 e 3 de Janeiro de 2010 por se considerar como um período atípico.
2 Nice Guys Finish Firsthttp://en.wikipedia.org/wiki/Nice_Guys_Finish_First.
