Testes baseados na percepção humana

De forma a avaliar a viabilidade desta arquitectura do ponto de vista da utilização real por humanos, foram utilizadas diversas aplicações representativas de vários tipos de serviços e foi recolhida a opinião dos utilizadores nas diversas fases.

As aplicações utilizadas foram telefonia IP, vídeo telefonia, streaming de áudio e vídeo, transferência de dados (mgen, ftp e http) e jogos multi-utilizador (quake 2) [IDSO].

Apesar de algumas destas aplicações serem de difícil teste enquanto o utilizador se move (por exemplo jogar quake), a percepção geral dos utilizadores foi a de que a arquitectura e o demonstrador conseguem suportar a transparência desejada em termos de mobilidade e QoS, uma vez que os utilizadores não conseguiram detectar qualquer problema ou interferência aquando dos instantes de handover.

Para a realização destes testes foram escolhidos estudantes com hábitos de utilização da Internet, contudo sem qualquer conhecimento da rede e da arquitectura que estavam a utilizar. Estes utilizadores foram sujeitos a situações de handover transparente, de paging e foram cobrados (virtualmente) de acordo com o perfil de QoS dos serviços utilizados e da própria utilização da rede. A rede foi sujeita a condições de sobrecarga forçada para se poder aferir a eficácia da diferenciação de serviço e de perfis. Conforme o esperado, os utilizadores com perfis de QoS de menor prioridade foram os que registaram queixas de degradação de serviço.

Os parágrafos seguintes descrevem testes formais realizados ao sistemas, e que foram seleccionados de forma a cobrirem situações de pior-caso para o comportamento da arquitectura, dadas as limitações logísticas existentes no demonstrador.

Teste 1 - Dois utilizadores, um com um perfil de serviço “gold” e outro com um perfil de serviço “bronze” acederam ao mesmo conteúdo (um fluxo áudio mp3) em condições de carga na rede. A aplicação que reproduziu o fluxo áudio não tinha qualquer armazenamento (buffering) temporário. O utilizador com perfil “gold” realizou vários

handovers com QoS e AAAC enquanto a música tocava, sem que ele conseguisse detectar

os instantes de handover, pois não houve qualquer perda de pacotes (mesmo com a sobrecarga efectuada na rede). Todos os bytes enviados e recebidos foram tarifados de

Avaliação de Desempenho da Arquitectura Proposta

183

acordo com o DSCP, representativo do serviço utilizado. O utilizador com perfil “bronze” realizou o mesmo teste. Devido ao seu perfil ser de prioridade inferior e a rede estar sobrecarregada (com tráfego artificial), este utilizador detectou diversos cortes (mesmo sem efectuar handovers). No entanto, também nesta situação, o utilizador foi incapaz de detectar os instantes dos handovers, ou seja, ou níveis de QoS recebidos foram uniformes. Devido ao facto de este utilizador ter utilizado um perfil de serviço de menor prioridade, e de ter recebido menos bytes (alguns perderam-se antes de serem entregues) a sua tarifação foi inferior à do utilizador com o perfil “gold”. De notar, no entanto, que os factores de custo de utilização podem ser dependentes de outros aspectos que não apenas os níveis de QoS. No limite, um utilizador “preferencial” poderá ter um serviço melhor a um custo mais reduzido que um outro utilizador “menos preferencial” (podemos ter um “grande” cliente empresarial como exemplo de um utilizador preferencial. Este é um aspecto associado aos problemas discutidos na secção 2.3.6 de problemas comerciais).

Teste 2 - Para aferir a real distinção e diferenciação de serviço e de QoS, foi realizado um teste em que dois utilizadores com perfis distintos (“bronze” e “gold”) visualizaram um fluxo de vídeo simultaneamente, enquanto alguns handovers foram realizados. O cenário utilizado era composto por duas redes de acesso wireless (IEEE 802.11b e uma rede Ethernet. Inicialmente, os dois utilizadores, cada qual com o seu terminal, estavam ligados em cada uma das redes wireless. O fluxo de vídeo utilizado tinha características de largura de banda muito exigentes (cerca de 4 Mbps). Atendendo a que a largura de banda efectivamente disponível numa ligação 802.11b é apenas de cerca de 5,5 Mbps é facilmente dedutível que não há suficiente largura de banda disponível para acomodar os dois fluxos (unicast) na mesma célula wireless. Assim, enquanto cada utilizador estava numa rede de acesso wireless distinta não se observou qualquer anomalia na visualização do fluxo de vídeo em qualquer dos terminais. O passo seguinte consistiu em mover o utilizador com o perfil “gold” para a proximidade da rede de acesso wireless ocupada pelo utilizador com perfil “bronze”. Ao perder sinal relativamente à célula que ocupava e detectando uma outra célula com melhor condições de sinal, o terminal do utilizador com o perfil “gold” realizou um handover rápido com QoS e AAAC para a célula ocupada pelo outro utilizador. Uma vez que a largura de banda disponível não era suficiente para ambos os fluxos, detectou-se que o utilizador com o serviço de perfil “bronze” começou a não receber todos os pacotes, acabando por forçar a aplicação de

Serviços Multimédia Sobre Redes Heterogéneas

184

visualização do vídeo a não exibir o filme. Em contrapartida, o utilizador com o serviço de perfil “gold” realizou o handover sem notar qualquer interferência, e continuou a visualizar o vídeo em condições perfeitas. Após isto, este utilizador, moveu-se para a rede de acesso Ethernet. Mais uma vez o handover foi realizado sem qualquer interferência ao nível da visualização do vídeo, e uma vez que os recursos na rede wireless onde o utilizador com o perfil serviço de “bronze” aumentaram, este viu a sua aplicação de vídeo a mostrar de novo o filme. O último passo deste teste consistiu em forçar um handover do utilizador com perfil “bronze” para a rede Ethernet. O handover foi realizado sem que o utilizador pudesse registar qualquer interferência na visualização, e uma vez que os recursos disponíveis na rede Ethernet eram suficientes para acomodar os dois utilizadores com os dois fluxos de vídeo, ambos puderam continuar a observar os vídeos sem qualquer problemas.

Teste 3 - Foram realizados testes com perfis de serviço “gold” mas com limitação de largura de banda. Nestes casos, verificou-se que sempre que os utilizadores tentaram utilizar aplicações que exigiam mais largura de banda do que aquela que o seu perfil permitia, mesmo tendo alta prioridade, havia perdas de pacotes correspondente aos pacotes descartados pelos routers de acesso. Ou seja, o serviço tinha de facto prioridade elevada e não era afectado pela introdução de tráfego concorrente menos prioritário, mas também não permitia a utilização de mais recursos do que os especificados no perfil.

É de salientar que nestes testes, foram envolvidas todas as entidades e módulos definidos na arquitectura apresentada, à excepção dos agentes e módulos de paging. Também se deve notar que estes testes foram realizados em ambiente semi-controlado, e que em alguns casos, problemas associados com as placas de rede (nomeadamente passarem de modo stand-by para modo activo) eram aparentes. Obviamente que estas situações, tendo sido devidamente identificadas, e sendo reprodutíveis, não são de relatar neste ponto.