Cenários chave

Após a validação das entidades mais relevantes do ponto de vista da arquitectura de QoS, vamos analisar o comportamento da arquitectura em cenários chave.

6.3.2.1 Tempo de registo

O atraso de registo é o tempo que decorre desde que o utilizador (após ligar o terminal) inicia o processo de autorização e o terminal fica pronto para o serviço. Neste contexto, existem atrasos de dois tipos: os atrasos das camadas inferiores (1 e 2), dependentes da tecnologia e do meio de transmissão e os atrasos das camadas superiores, dependentes do(s) protocolo(s) utilizado(s) (atraso provocado pelo envio e processamento das mensagens 1 a 4 apresentadas na Figura 32).

Assim, o tempo total de registo poderá ser indicado pela fórmula seguinte:

es isSuperior AtrasoNíve es isInferior AtrasoNíve sto AtrasoRegi = +

O primeiro termo (AtrasoNíveisInferiores) é totalmente dependente da tecnologia e não depende do protocolo ou arquitectura utilizada, impondo assim um limite inferior inultrapassável. O segundo termo (AtrasoNíveisSuperiores) é dependente da velocidade das ligações utilizadas, do desempenho dos sistemas (router de acesso e sistema de AAAC), do protocolo e número de mensagens trocadas e, no caso de um utilizador em

roaming, da distância eléctrica e velocidade de transmissão da ligação entre os sistemas de

AAAC do seu domínio origem e do domínio onde se encontra:

∑

∑

= AtrasoLigações AtrasoProcessamento DistânciaAAACs es

isSuperior AtrasoNíve

O primeiro termo (ΣAtrasoLigações), relativo ao atraso das ligações, entre o terminal móvel e o router de acesso, e entre o router de acesso e o sistema de AAAC pode ser normalmente desprezável, uma vez que a infra-estrutura de gestão é normalmente sobredimensionada em termos de recursos necessários e as velocidades de transmissão entre os elementos de controlo são normalmente elevadas (por exemplo, ligações

FastEthernet). Desta forma, os atrasos de processamento (ΣAtrasoProcessamento) nos

Serviços Multimédia Sobre Redes Heterogéneas

178

dominantes, especialmente no caso de sobrecarga de processamento (muitos pedidos em simultâneo) ou subdimensionamento de capacidade de processamento (no caso de terem de gerir bases de dados muito grandes). No entanto, com o aumento de capacidade de processamento dos sistemas actuais, estes atrasos podem ser facilmente reduzidos. Assim, o factor mais restritivo de todos, poderá ser, em caso de utilizadores em roaming, a distância entre os sistemas de AAAC envolvidos (DistânciaAAACs). No entanto, este parâmetro não é dos mais importantes em termos de desempenho da arquitectura, desde que seja mantido em valores relativamente baixos em termos de percepção humana e semelhante ao que se experimenta actualmente em termos de redes celulares. Esta arquitectura é desta forma similar em desempenho aos sistemas actuais, do ponto de vista de tempo de registo.

6.3.2.1.1 Resultados obtidos

A Tabela 15 apresenta os valores dos tempos de autenticação medidos no cenário de demonstração (Figura 53). A numeração das mensagens respeita a numeração apresentada nas Figura 32 e Figura 33.

Nº ∆t (s) 1 0 2 0.169 3 0.209 4 0.224 5 0.800

Tabela 14: Desempenho da autenticação

Estes resultados confirmam a aptidão desta arquitectura e respectiva sinalização como base para uma futura arquitectura de próxima geração.

6.3.2.2 Tempo de autorização de serviço

O tempo de autorização de serviço é o tempo decorrido desde que o utilizador decide usufruir de determinado serviço até que os recursos estejam disponíveis para isso. Na Figura 32, este será o tempo decorrido entre as mensagens 5 e 11. Este tempo é composto essencialmente pelos atrasos nas ligações (i) entre os terminais (origem e destino) e os seus

routers de acesso, (ii) entre os routers de acesso e os QoS Brokers e (iii) entre os dois routers de acesso (distância eléctrica entre ambos) e ainda pelos atrasos de processamento

Avaliação de Desempenho da Arquitectura Proposta 179 Rs DistânciaA essamento AtrasoProc ções AtrasoLiga ioSessão AtrasoIníc =

∑

∑

O primeiro destes termos (ΣAtrasoLigações) é normalmente muito reduzido (e é de difícil medição) uma vez que os terminais e os routers estão normalmente muito próximos, o mesmo se passando entre os routers e os QoS Brokers (e neste caso as ligações são normalmente sobredimensionadas). Quanto aos tempos de processamento (ΣAtrasoProcessamento)(que foram medidos nas secções anteriores), pode-se repetir a ideia apresentada na secção anterior relativamente à capacidade de processamento dos dispositivos de hoje em dia, ou seja, o aumento da capacidade de processamento deixa antever que não haverá qualquer limitação a este nível. Pode ainda acrescentar-se que num cenário de produção, os dispositivos utilizados serão ainda mais eficazes e poderosos, podendo eventualmente realizar diversas tarefas em hardware específico. Assim, uma vez mais, a distância eléctrica entre a origem e o destino da ligação (DistânciaARs) poderá ser o factor com maior preponderância no atraso total. No entanto, este é um limite físico da rede que não depende de todo da arquitectura proposta e não é passível de ser reduzido em termos arquitecturais.

6.3.2.2.1 Resultados obtidos

A Tabela 15 apresenta os valores de tempo de sinalização na autorização de serviço medidos no demonstrador (Figura 53). A numeração das mensagens está de acordo com a apresentado na Figura 32 e Figura 33.

Nº ∆t (s)

5 0 6 0.754 7 0.767 8 3.494

Tabela 15: Desempenho da autorização

Os resultados obtidos demonstram a validade da arquitectura e desempenhos que ao nível dos esperados em cenários de produção. A diferença de tempos entre a mensagem 7 e a mensagem 8 deve-se a duas componentes distintas: o tempo de configuração do router de acesso e os instantes em que a aplicação do cliente gera tráfego. Devido à utilização de sinalização implícita, a mensagem 8 é um pacote de uma aplicação do cliente que foi apenas gerado naquele instante.

Serviços Multimédia Sobre Redes Heterogéneas

180

6.3.2.3 Atraso de Handover

O atraso no handover é, sem dúvida, o mais crítico de todos os atrasos, em termos de sensibilidade e percepção do utilizador. O handover terá de ser efectuado muito rapidamente de modo a ser transparente para o utilizador e também para as aplicações, especialmente as aplicações multimédia. O atraso total do processo de handover é composto por diversos factores independentes, sendo que alguns apresentam limites rígidos inalteráveis, enquanto que outros podem ser passíveis de serem reduzidos ou desprezados: atrasos de transmissão, atrasos de computação ou processamento, e atrasos de

handover de nível 2.

∑

∑

∑

= AtrasoTransmissão AtrasoComputação HandoverNível2 over

AtrasoHand

Os atrasos de transmissão (ΣAtrasoTransmissão) são compostos pelos atrasos das ligações entre os diversos elementos: terminal móvel e routers de acesso, routers de acesso e QoS Brokers, entre os QoS Brokers envolvidos e entre os routers de acesso “novo” e “antigo”.

O tempo total de handover é o tempo passado desde a mensagem 3 (Figura 34) até à mensagem 12. No entanto, o tempo que o terminal móvel está sem conectividade e sem recursos atribuídos é apenas o tempo despendido no handover de nível 2 (ΣHandoverNível2), ou seja, o tempo que o terminal demora a mudar de uma célula para outra (tempo passado entre as mensagens 10a e 12). Este é um comportamento fundamentalmente associado ao desempenho da camada física dos dispositivos.

6.3.2.3.1 Resultados obtidos

A Figura 53 ilustra o cenário utilizado para fazer as medições do desempenho da arquitectura no que diz respeito ao handover. A Tabela 16 apresenta os resultados obtidos, mais relevantes do ponto de vista do handover. No demonstrador foi utilizado apenas um QoS Broker. Desta forma, a mensagem 5 definida nas Figura 34 e Figura 35, não existe.

Avaliação de Desempenho da Arquitectura Proposta 181 Nº ∆ (s) Nº ∆ (s) 2 0 7 1,087 3 1,006 8 1,114 4a 1,029 9 1,126 4b 1,065 10 1,144 6 1,086 12 1,257

Tabela 16: Tempos da sinalização de handover

6.3.2.3.2 Latência Geral Durante o processo de Handover

Os resultados medidos mostram que o tempo de preparação do handover se situa na ordem dos 138ms (diferença de tempos entre as mensagens 3 e 10). Se considerarmos que o terminal se está a deslocar a 250km/hora, toda a negociação prévia do handover se realiza em apenas 9,6m. Atendendo às dimensões das células rádio, e às suas sobreposições (várias dezenas de metros), podemos concluir que o desempenho da arquitectura proposta é adequado a ser utilizado em cenários reais.

Dos resultados observados, o tempo de todo o processo de handover (mensagens 3 a 12), relevante do ponto de vista do terminal que se está a mover, é cerca de 250ms, que é um valor dentro do parâmetros aceitáveis.

6.3.2.3.3 Pacotes perdidos durante o Fast Handover

Os testes e medições realizados permitiram avaliar que, utilizando aplicações correntes baseadas em UDP (para voz e vídeo), graças à preparação do handover antes da sua realização (make before break) e graças ao mecanismo de bicasting implementado no

router antigo, o número de pacotes perdidos não ultrapassa um a dois por aplicação,

havendo mesmo casos em que não se perde qualquer pacote. A perda de pacotes ocorre apenas aquando do handover para a rede Ethernet. Verificou-se que a perda de pacotes ocorre devido ao tempo que a própria interface física Ethernet do PC Linux leva a ficar disponível, partindo de uma situação sem ligação.

6.3.2.3.4 Atraso na preparação do handover introduzido pela componente de QoS

Foi feito um teste em que toda a componente de QoS (envolvendo os QoS Brokers) foi omitida do processo de Fast Handover. Esse teste permitiu avaliar o tempo de processamento extra que é introduzido pela componente de QoS na preparação do

handover. Os resultados obtidos mostram que esse atraso extra se situa na ordem dos 8ms.

Serviços Multimédia Sobre Redes Heterogéneas

182

que portanto não implica uma perda de serviço) e que com este processo se garantem os recursos necessários na célula para onde o terminal se deseja mover, pode considerar-se que este tempo é bastante satisfatório e que não compromete a solução proposta.