Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DO SUL E SUDESTE DO PARÁ
INSTITUTO DE GEOCIÊNCIAS E ENGENHARIAS
FACULDADE DE COMPUTAÇÃO
Bacharelado em Sistemas de Informação
Análise de Confiabilidade de Garantia de Qualidade de
Serviço (QoS) em uma Arquitetura WiMAX através de
métricas de Qualidade de Experiência (QoE)
Edney Almeida do Nascimento
Fernando Alves Miranda
MARABÁ
2013
Edney Almeida do Nascimento
Fernando Alves Miranda
Análise de Confiabilidade de Garantia de Qualidade de Serviço (QoS)
em uma Arquitetura WiMAX através de métricas de Qualidade de
Experiência (QoE)
Trabalho de Conclusão de Curso,
apresentado para obtenção do grau de
Bacharel em Sistemas de Informação.
Orientador: Prof. Msc. Warley Muricy
Valente Junior.
MARABÁ
2013
Edney Almeida do Nascimento
Fernando Alves Miranda
Análise de Confiabilidade de Garantia de Qualidade de Serviço (QoS)
em uma Arquitetura WiMAX através de métricas de Qualidade de
Experiência (QoE)
Trabalho de Conclusão de Curso,
apresentado à Universidade Federal do Sul e
Sudeste do Pará, como parte dos requisitos
necessários para obtenção do Título de
Bacharel em Sistemas de Informação.
Marabá: 20 de Dezembro de 2013.
____________________________________________________
Prof. Msc. Warley Muricy Valente Junior
Faculdade de Computação/UFPA - Orientador
____________________________________________________
Prof. Esp. Rangel Filho Teixeira
Faculdade de Computação/UFPA - Membro
____________________________________________________
Prof. Esp. Gleison de Oliveira Medeiros
Faculdade de Computação/UFPA - Membro
Marabá, PA.
2013
IV
DEDICATÓRIA
Dedico este trabalho aos primeiros e
principais mestres da minha vida, meu pai
Joaquim, e minha mãe Edna, por
mostrarem que laços de sangue também
são criados pelo coração. Aos mestres!
Edney Almeida do Nascimento
Dedico este trabalho às duas mulheres da
minha vida, Albertina Alves Miranda,
minha mãe e Francisca Araújo de
Almeida, minha avó, por serem o elo forte
que une nossa família.
Fernando Alves Miranda
V
AGRADECIMENTOS
Agradecemos primeiramente a Deus, pela oportunidade da vida, por ter nos ajudado nos
momentos difíceis da vida e por sempre estar conosco, e à Universidade Federal do Pará.
Ao Prof. Esp. Rangel Filho Teixeira, coordenador do Curso de Sistemas de Informação,
pela longa empreitada no decorrer do trabalho.
Ao Prof. Msc. Warley Muricy Valente Junior pela orientação competente, dedicando-se
de forma marcante na elaboração deste trabalho, e pela enorme paciência na correção de
cada capítulo.
A todos familiares, amigos, companheiros e parceiros, pelo incentivo na busca do
conhecimento, força, paciência e compreensão nessa fase de nossas vidas.
VI
SUMÁRIO
LISTA DE FIGURAS ................................................................................................... VIII
LISTA DE QUADROS ................................................................................................... IX
LISTA DE TABELAS ..................................................................................................... X
LISTA DE ABREVIATURAS E SIGLAS ..................................................................... XI
RESUMO ...................................................................................................................... XIV
ABSTRACT ................................................................................................................... XV
1. INTRODUÇÃO ............................................................................................................ 1
2. QUALIDADE DE SERVIÇO EM REDES WIMAX .................................................. 5
2.1 Padrão IEEE 802.16 – Redes WiMAX .................................................................. 5
2.2 Família IEEE 802.16 .............................................................................................. 7
2.3 Arquitetura e Protocolos WiMAX ........................................................................ 10
2.4 QoS em Redes WiMAX ....................................................................................... 14
2.5 Resumo do Capítulo ............................................................................................. 19
3. QUALIDADE DE EXPERIÊNCIA EM REDES SEM FIO ...................................... 20
3.1 Qualidade de Experiência (QoE) .......................................................................... 20
3.1.1 Métricas Subjetivas ....................................................................................... 22
3.1.2 Métricas Objetivas ......................................................................................... 23
3.1.2.1 Peak Signal to Noise Ratio – PSNR ....................................................... 24
3.1.2.2 Structural Similarity Index – SSIM ........................................................ 25
3.1.2.2 Video Quality Metric (VQM) ................................................................. 27
3.2 Resumo do capitulo .............................................................................................. 29
4. TRABALHOS RELACIONADOS ............................................................................ 30
4.1 Resumo do Capítulo ............................................................................................. 33
5. MATERIAIS E MÉTODOS ....................................................................................... 34
5.1 Metodologia .......................................................................................................... 34
5.2 Ferramentas .......................................................................................................... 35
5.3 Resumo do Capítulo ............................................................................................. 39
6. AVALIAÇÃO DE GARANTIA DE QUALIDADE ................................................. 40
6.1 Parâmetros de Simulação e Topologia de rede ..................................................... 40
6.2 Análises das Simulações ....................................................................................... 43
6.3 Resumo do Capítulo ............................................................................................. 55
VII
7. CONCLUSÃO ............................................................................................................ 56
8. REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................... 58
APÊNDICE A – Scripts TCL de Cenário e agentes configurados para rede WiMAX no
sentido uplink: ................................................................................................................ 65
APÊNDICE B – Scripts TCL de Cenário e agentes configurados para rede WiMAX no
sentido downlink: ............................................................................................................ 83
VIII
LISTA DE FIGURAS
Figura 1 – Conectividade PMP e Mesh ............................................................................ 6
Figura 2 – Pilha de protocolos padrão IEEE 802.16 ...................................................... 10
Figura 3 – Arquitetura de rede proposta pela WiMAX Fórum. ..................................... 12
Figura 4 – Pilha de protocolos do IEEE 802.16. ............................................................ 13
Figura 5 – Arquitetura de QoS no WiMAX ................................................................... 17
Figura 6 – Quadro de gerenciamento WiMAX .............................................................. 18
Figura 7 – Abordagem objetiva x Abordagem subjetiva. ............................................... 22
Figura 8 – Estrutura de funcionamento do SSIM. .......................................................... 26
Figura 9 – Ilustração de uma simulação no ns-2 ............................................................ 36
Figura 10 – Logo representante da tecnologia WiMAX ................................................ 36
Figura 11 – Imagem de uma execução do EvalVid ........................................................ 37
Figura 12 – Imagem de uma execução do MSU VQMT ................................................ 37
Figura 13 – Imagem de um gráfico plotado pelo XGRAPH .......................................... 38
Figura 14 - Logomarca do Ubuntu ................................................................................ 39
Figura 15 – Cenário e topologia de Rede das simulações .............................................. 42
Figura 16 – Vazão média para todas as CoS em simulações de tráfegos uplink. ........... 45
Figura 17 - Vazão média para todas as CoS em simulações de tráfego downlink. ........ 46
Figura 18 – Atraso médio de pacotes para todas as CoS em simulações uplink. ........... 47
Figura 19 – Atraso médio de pacotes para todas as CoS em simulações downlink. ...... 47
Figura 20 – PSNR dos vídeos para tráfego uplink. ........................................................ 49
Figura 21 – PSNR dos vídeos para tráfego downlink. .................................................... 50
Figura 22 – VQM dos vídeos para tráfego uplink. ......................................................... 50
Figura 23 – VQM dos vídeos para tráfego downlink...................................................... 51
Figura 24 – SSIM dos vídeos para tráfego uplink. ......................................................... 52
Figura 25 – SSIM dos vídeos para tráfego downlink ..................................................... 52
Figura 26 – Diferenciação do Frame 888: Enviado X Recebido .................................... 54
IX
LISTA DE QUADROS
Quadro 1 – Principais emendas do padrão IEEE 802.16. ................................................. 9
Quadro 2 – Classes de serviços WiMAX e seus parâmetros de QoS. ............................ 16
Quadro 3 – Resumo dos trabalhos relacionados discutidos. .......................................... 32
Quadro 4 - Comparativo do frame 600 do vídeo antes e após a simulação. .................. 53
X
LISTA DE TABELAS
Tabela 1 - Valores do MOS. ........................................................................................... 23
Tabela 2 – Mapeamento PSNR para MOS ..................................................................... 25
Tabela 3 – Parâmetros utilizados nas simulações ........................................................... 41
Tabela 4 – Parâmetros de QoS configurados.................................................................. 42
Tabela 5 – Parâmetros dos vídeos utilizados .................................................................. 44
XI
LISTA DE ABREVIATURAS E SIGLAS
SI Sistema de Informação
TI Tecnologia da Informação
AAA Authentication, Authorization and Accounting
ANSI American National Standards Institute
AP Access Point
ASN Access Service Network
ATM Asynchronous Transfer Mode
BE Best Effort
BS Base Station
CAC Connection Admission Control
CDR Constant Bit Rate
CID Connection Identifier
CoS Class of Service
CSF Contrast Sensitivity Function
CSN Connectivity Service Network
DCT Discrete Cosine Transform
DL-MAP Downlink Bandwidth Allocation Map
DSA-REQ Dynamic Service Addition Request
DSA-RSP Dynamic Service Addition Reponse
ertPS extended real-time Polling Service
ETSI European Telecommunications Standards Institute
E1/T1 E-carrier/T-carrier
FIFO First In First Out
FTP File Transfer Protocol
HTTP Hypertext Transfer Protocol
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
ISO International Organization for Standardization
ITU International Telecommunication Union
LAN Local Area Network
LC Local Contrast
XII
LOS Line-of-Sight
MAC Media Access Control
MAC CPS Common Part Sublayer
MAC CS Service-Specific Convergence Sublayer
MAC SS Security Sublayer
MAN Metropolitan Area Network
MIB Management Information Base
MIMO Multiple-Input Multiple-Output
MN Mobile Node
MOS Mean Option Score
MS Mobile Station
NAP Network Access Provider
NIST National Institute of Standards and Technology
NLOS No Line-Of-Sight
nrtPS non real-time Polling Service
Ns-2 Network Simulator 2
NSP Network Service Provider
OFDM Orthogonal Frequency Division Multiplexing
OFDMA Orthogonal Frequency Division Multiple Access
PDP Policy Decision Point
PHY Physical
PMP Point-to-Multipoint
PSNR Peak Signal to Noise Ratio
QoE Quality of Experience
QoS Quality of Service
RR Round Robin
rtPS real-time Polling Service
SAP Service Access Point
SFID Service Flow Identifier
SS Subscriber Station
SSIM Structural Similarity Index
STA Stations
TKN Telecommunication Networks Group
Tcl Tool Command Language
XIII
TK Tk GUI toolkit
UGS Unsolicited Grant Service
UL-MAP Uplink Bandwidth Allocation Map
UMTS Universal Mobile Telecommunication System
VQM Video Quality Metric
Wi-Fi Wireless Fidelity
WiMAX Worldwide Interoperability for Microwave Access
WLAN Wireless Local Area Network
WMAN Wireless Metropolitan Area Network
xDSL Digital Subscriber Line
XIV
RESUMO
O WiMAX ou padrão IEEE 802.16, e o seu framework de Qualidade de Serviço (QoS),
é uma tecnologia para redes sem fio do tipo WMAN de grande potencial, de modo a
garantir uma conexão sem fio estável e que atende a necessidade de diferentes aplicações.
O WiMAX implementa nativamente na sua camada MAC suporte para o framework de
QoS, que é um padrão de qualidade voltado para o fluxo de serviço com foco na rede. A
Qualidade de Experiência (QoE), é outro padrão de qualidade, porém voltado para o
aspecto visual do usuário final. Foram realizado estudos e experimentos no framework de
QoS do módulo WiMAX para ns-2: de autoria de Aymen Telecom. Avaliou-se o grau de
confiabilidade de implementação da garantia de QoS do módulo, através de cenários que
represente a internet do futuro, injetando tráfegos reais de vídeos, voz e ftp no cenário de
simulação de modo a permitir a definir não somente métricas de QoS (melhorias no plano
fim–a–fim nas arquiteturas de redes), mas também métricas de QoE (melhorias para as
aplicações multimídias a partir da perspectiva/experiência do usuário). Este trabalho
propõe uma análise de confiabilidade, onde serviços serão requisitados por diversos
dispositivos, em um cenário concorrente, em programas de simulação e coleta de dados,
para verificar se realmente a arquitetura de rede em questão, o WiMAX, faz o correto uso
e implemento desses padrões de qualidade. Os resultados das simulações mostraram que
o framework garante a mínima garantia de QoS necessária para diferentes vídeos, porém
percebeu-se que a resolução e o grau de complexidade do vídeo influênciam na qualidade
de experiência do usuário.
Palavras – chaves: WiMAX, Qualidade de Serviço, Qualidade de Experiência.
XV
ABSTRACT
WiMAX or IEEE 802.16, and its framework of Quality of Service (QoS) is a technology
for wireless networks WMAN kind of great potential, in order to secure a stable
connection without wire and meets the need of different applications. The WiMAX
implements natively on your MAC layer support for QoS framework, which is a quality
standard facing the service flow with a focus on network. The Quality of Experience
(QoE) is another standard of quality, but facing the visual aspect of the end user. Studies
and experiments were performed in the framework of QoS of WiMAX module for ns- 2:
authored by Aymen Telecom. We evaluated the reliability of implementation of QoS
guarantee of the module through scenarios that represent the future of the internet,
injecting real traffic video, voice and ftp in simulation scenario to allow not only to define
QoS metrics (some improvements in end-to-end in network architectures), but also
metrics (QoE enhancements for multimedia applications from the view / user experience).
This paper proposes a reliability analysis, where services will be required by various
devices in a competing scenario, simulation and data collection programs to verify that
indeed the network architecture in question, WiMAX, makes the correct use and
implement these standards. The simulation results showed that the framework guarantees
the minimum guarantee required QoS for different videos, but it was noticed that the
resolution and complexity of the influence video quality of user experience.
Keywords: WiMAX, Quality of Service, Quality of Experience.
1
1. INTRODUÇÃO
Na atual revolução industrial, ficou claro que a tecnologia e a informação iriam
ocupar um papel fundamental no mundo, e quem possuísse controle e alcance da mesma
teriam uma grande vantagem sobre os demais. Atualmente, isso se confirma com o
número cada vez maior de aparelhos celulares, smartphones, tablets dentre outros
aparelhos, vendidos em escala de milhões, pelo simples fato de manter conectado o
proprietário as informações, através da grande rede que é a internet. Se tratando de
universo virtual e as diversas transformações tecnológicas, no futuro haverá uma
concordância incontestável entre homem e a tecnologia (Claro, 2009).
Com a mesma velocidade que os aparelhos são vendidos e melhoram, as
tecnologias contidas neles também evoluem, criando um vasto conjunto de possibilidades
e tipos de serviços que podem ser oferecidos por empresas do ramo. Essas empresas
buscam meios de conectarem seus usuários da melhor forma possível, e atender todas
suas necessidades, buscando sempre a mobilidade e praticidade (Vaczelewski et al, 2011).
As conexões sem fio surgiram com o propósito de fornecer conectividade transparente
com mobilidade e principalmente qualidade na oferta de serviço, com os avanços das
tecnologias de acesso sem fio que visam diminuir cada vez mais as distâncias geográficas,
e promover qualidade de conexão, grandes operadores de rede tem procurado as melhores
soluções de modo a aliar a qualidade de serviço prestado pela rede e disponibilidade de
serviço oferecido (Corrêa et al, 2006).
Uma tecnologia que garante essa conexão é o WiMAX (Worldwide
Interoperability of Microwave Access – Interoperabilidade Mundial para Acesso de
Micro-ondas), ou padrão IEEE 802.16, e o seu framework1 de QoS (Quality of Service –
Qualidade de Serviço) que visa garantir uma conexão sem fio estável e que atenda a
necessidade de diferentes aplicações (Ieee, 2006).
A tecnologia WiMAX, através do padrão IEEE 802.16, é uma tecnologia de rede
MAN (Metropolitan Area Network – Rede de Área Metropolitana) sem fio, com suporte
a cobertura na ordem de até 50 km e taxas nominais de transmissão de até 74 Mbps, além
1 Framework é um conjunto de classes e ferramentas que colaboram para realizar uma responsabilidade
para um domínio de um subsistema da aplicação
2
de melhorias comparadas aos padrões anteriores como QoS e interfaces para redes IP,
ATM, E1/T1 e Ethernet (Figueiro, 2008). Este padrão especifica as camadas MAC e PHY
da pilha de protocolos. O padrão 802.16 possui várias emendas sendo a emenda 802.16e,
última catalogada em dezembro de 2005, utilizada como padrão, tendo como principais
requisitos, frequências de 2 – 6 GHz, condição de modulação de canal NLOS (non-line-
of-sight – Sem linha de visada), taxa de transferência máxima de 15 Mbps, suporte à
mobilidade (handover) e raio de célula de 2 – 5 km (Ieee, 2006).
O WiMAX, com sua ementa IEEE 802.16e, fornece suporte à QoS na camada
MAC de modo que a interação com o gerenciamento de recursos de rádio e camada física
ocorram de uma maneira mais fácil. Seu framework adota cinco classes de serviços ou
CoS (Class of Service – Classes de Serviços): UGS (Unsolicited Grant Service - Serviço
de Concessão não Solicitado), rtPS (real-time Polling Service – Serviço de Locação em
Tempo Real), ertPS (extend real-time Polling Service – Serviço de Locação em Tempo
Real Estendido), nrtPS (non real-time Polling Service – Serviço de Locação Sem Tempo
Real) e BE (Best Effort – Melhor Esforço), que classificam o tipo de serviço para
prioridade na execução. Fornecer a conexão para esses dispositivos com qualidade é um
grande desafio levando em conta, interferências no sinal de transmissão, limitação da
infraestrutura, mobilidade dos usuários, dentre outros fatores (Delicato et. al, 2008).
De acordo com uma pesquisa realizada pela Cisco Systems (Cisco, 2012), o
tráfego de dados em redes públicas, privada e na internet deve crescer numa taxa anual
de 29% nos próximos quatros anos, devido à forte demanda por vídeos e ao crescimento
da utilização de smartphone, tablets e TVs com internet. O tráfego de streaming de vídeo
exige algumas variáveis da rede que influenciam na sua qualidade final, como uma taxa
de bits mínima (largura de banda), requer atraso e variação de atraso delimitados e baixos,
e principalmente a perca de pacotes deve ser mantido abaixo de um limite rigoroso para
ter uma qualidade visual aceitável (Nunes, 2011).
Frente a necessidade de prover a melhor qualidade a ser oferecida para o usuário
final, esse projeto tem como objetivo realizar uma análise de confiabilidade para tráfegos
de vídeos com graus de complexidades diferentes em um módulo para o ns-2 (Network
Simulator 2) que visa implementar o QoS para tecnologias WiMAX.
O trabalho servirá como referência e recomendação para pesquisadores e
projetistas da área de redes e telecomunicações, de modo permitir uma avaliação técnica
3
do grau de confiabilidade de implementação deste módulo. Para isto será realizada
simulações utilizando três diferentes tipos de tráfegos reais: Vídeo, Voz e FTP.
Esse trabalho propõe uma análise e avaliação, onde serviços serão requisitados
por diversos dispositivos, em um cenário concorrente, em programas de simulação e
coleta de dados, para verificar se realmente a arquitetura de rede em questão, o WiMAX,
faz o correto uso e implemento desses padrões de qualidade para tráfegos de vídeos.
Será feito estudo e experimentos no módulo de QoS para WiMAX implementado
para o simulador de rede ns-2 por Aymen (Belghith, Nuaymi, 2008), avaliando assim o
grau de confiabilidade de implementação da garantia de QoS do módulo, através de
cenários que represente a internet do futuro, injetando tráfegos reais de vídeos, além de
tráfegos simulados para aplicativos de tempo real e navegação na internet no cenário de
simulação de modo a permitir a definir não somente métricas de QoS (melhorias no plano
fim–a–fim nas arquiteturas de redes ), mas também métricas de QoE (melhorias para as
aplicações multimídias a partir da perspectiva/experiência do usuário);
A realização das simulações ocorrerá em cenários usando como referência o
padrão IEEE 802.16e (Padrão WiMAX com suporte a qualidade de serviço), de modo a
permitir a avaliação do comportamento da rede utilizando QoS. O resultado desse projeto,
poderá permitir que pesquisadores avaliem diferentes cenários usando vídeo em tempo
real em arquiteturas WiMAX que realmente implemente QoS e que garantam o QoE para
o usuário.
Neste capitulo apresentamos uma pequena introdução sobre os aspectos de
qualidade de serviço presentes em rede WiMAX, em conjunto de conceitos de métrica de
avaliações, enfatizando os assuntos referentes a motivação e objetivos deste trabalho, que
serão apresentado e discutido nos capítulos posteriores.
O capítulo 2 apresenta conceitos sobre qualidade de serviços (QoS) em redes
WiMAX, descrevendo seus principais padrões homologados, protocolos e arquitetura que
o envolvem, e suas classes de serviços.
O capítulo 3 aborda conceitos e métricas de avaliações a respeito da qualidade de
experiência (QoE), destacando suas principais métricas de avaliações e conceitos sobre
essa nova forma de avaliação com o foco na percepção do usuário.
4
O capítulo 4 descreve alguns trabalhos relacionados ao tema deste trabalho, com
descrições resumidas, descrevendo os pontos fortes e críticas dos mesmos, comparando-
os com o presente trabalho.
O capitulo 5 versa sobre as ferramentas e metodologia utilizada para o
desenvolvimento deste trabalho, descrevendo alguns conceitos, pontos fortes, críticas e
possíveis ferramentas alternativas.
O capitulo 6 descreve as simulações e testes efetuados, exibindo os dados e
resultados obtidos, juntamente com as avaliações dos tráfegos multimídias através das
métricas de QoS e QoE.
Por fim, são feitas as considerações finais de acordo com os resultados obtidos,
descrevendo o resultado da análise de confiabilidade, as dificuldades enfrentadas e
proposta para futuros trabalhos na mesma linha de pesquisa.
5
2. QUALIDADE DE SERVIÇO EM REDES WIMAX
Neste capítulo abordaremos sobre a tecnologia de comunicação de redes utilizada
nesta proposta, o padrão IEEE 802.16. Iremos demostrar as vantagens de utilizar essa
tecnologia, suas ementas e especificações, os principais protocolos e arquiteturas
envolvidas, em conjunto com definições sobre o framework de Qualidade de Serviço
(QoS) para essa tecnologia, destacando sua aplicabilidade e benefícios.
2.1 Padrão IEEE 802.16 – Redes WiMAX
O WiMAX (Worldwide Interoperability of Microwave Access –
Interoperabilidade Mundial para Acesso de Micro-ondas) ou padrão IEEE 802.16 é uma
tecnologia padronizada de rede sem fio que permite substituir as tecnologias de acesso de
banda larga por cabo e ADSL (Asymmetric Digital Subscriber Line - Linha Digital
Assimétrica para Assinante), permite a comunicação fixa entre um ou mais pontos,
comunicação portátil e comunicação móvel sem fio sem a necessidade de visada direta
com a estação base (Ieee, 2005).
O WiMAX é uma tecnologia de rede do tipo WMAN (Wireless Metropolitan Area
Network – Rede de Área Metropolitana Sem Fio), com suporte a cobertura na ordem de
até 50 km para estações assinantes (SS – Subscriber Station) e de 5 a 15 km para estações
móveis (MS – Mobile Station), com taxas de transmissão de até 74 Mbps, além de
melhorias como implantação de QoS (Quality of Service – Qualidade de Serviço) e
interfaces para redes IP (Internet Protocol - Protocolo de internet), ATM (Asynchronous
Transfer Mode - Modo de Transferência Assíncrona), E1/T1 e Ethernet (Figueiro, 2008).
O padrão IEEE 802.16 possui um aspecto muito importante, ele define a camada MAC
(Media Acess Control – Controle de Acesso ao Meio) que suporta múltiplas
especificações da camada PHY (Physical Layer – Camada Física) da pilha de protocolos
para redes WMAN. Isto é de grande utilidade para que fornecedores e fabricantes de
equipamentos possam diferenciar suas ofertas de serviços (Fagundes, 2005).
6
O WiMAX possui dois modos de conectividade: Ponto-Multiponto (PMP – Point-
to-Multipoint) e Malha (Mesh). A Figura 1 ilustra esses dois modos de conectividade para
uma rede WiMAX.
Figura 1 – Conectividade PMP e Mesh
Fonte: Figueiro, 2008.
Na topologia ilustrada, são definidos os elementos BS (Base Station – Estação
Base) e SS (Subscriber Station – Estação assinante). A BS efetua a interface entre a rede
sem fio e uma rede-núcleo (Core Network) através de interfaces IP e ATM. A SS
possibilita o usuário de acessar a rede por meio do enlace com a BS, utilizando uma
topologia PMP. Porém, a SS pode se conectar a uma ou mais SS intermediarias, até atingir
a BS o que caracteriza uma topologia Mesh, o que representa uma estratégia interessante
para expandir a área de cobertura total de uma rede sem a necessidade de um aumento
proporcional dos números de BSs, o que representa uma economia nos custos de
implantação e expansão da rede, pois as SSs possuem custos inferiores ao das BSs
(Figueiro, 2008).
O IEEE 802.16 suporta algumas variações na camada física, tanto para ambientes
com linha de visada (LOS – Line-of-Sight) quanto para ambientes e condições sem linha
de visada (NLOS – No Line-of-Sight). Em ambientes de LOS, frequências na faixa de 10
a 66 GHz são utilizadas, no entanto, essas faixas de frequência possuem pouca
propagação multipercurso, então faixas de baixa frequência, de 2 a 11 GHz são mais
adequadas. Outra vantagem para utilizar baixas frequências são os modos de operação da
7
camada física aplicáveis a elas, que são técnicas de multiplexação: OFDM (Orthogonal
Frequency Division Multiplexing - Multiplexação por Divisão de Frequência Ortogonal)
e OFDMA (Orthogonal Frequency Division Multiple Access – Acesso Múltiplo por
Divisão de Frequência Ortogonal). Na teoria básica do OFDM, sua ideia é dividir o fluxo
digital de alta taxa de bits em um esquema de baixa taxa e a transmissão paralela usando
subportadoras. Utilizando um sinal OFDM é possível organizar as portadoras de tal
maneira que suas bandas laterais se sobreponham sem a ocorrência de interferência entre
as mesmas, mas para que isso ocorra, mais portadoras precisam ser matematicamente
ortogonais (Fagundes, 2005). O OFDMA combina o acesso múltiplo por divisão de
frequência com acesso múltiplo por divisão de tempo. Essas duas modulações são de
muita utilidade em condições NLOS, pois aumentam a propagação das ondas de rádio.
Outra vantagem do padrão 802.16 é o suporte à mobilidade, que e implantado em
umas de suas emendas, permitindo handover transparente entre MSs e BSs, ou seja,
permite que um MS troque de estação base com velocidade veicular de até 120 km/h de
forma que as aplicações que estão em utilização da rede em tempo real não sofram
nenhuma falha ou pausa no seu funcionamento e de maneira imperceptível para o usuário
(Andreadis et al, 2011).
2.2 Família IEEE 802.16
Fornecer a conexão para dispositivos sem fio com qualidade é um grande desafio
levando em conta, interferências no sinal de transmissão, limitação da infraestrutura,
mobilidade dos usuários, dentre outros fatores (Delicato et al, 2008). O padrão IEEE
802.16, ou WiMAX como também é chamado, foi criado com o intuito de complementar
e sanar as limitações do padrão IEEE 802.11 conhecido como Wi-Fi (Wireless Fidelity –
Fidelidade Sem Fio) (IEEE 802.11, 2005). O padrão 802.16 foi desenvolvido de modo
compatível aos padrões do ITU (International Telecommunication Union – União
Internacional de Telecomunicação) e do ETSI (European Telecommunications Standards
Institute - Instituto Europeu de Padronização de Telecomunicações) caracterizando-se
como um padrão global (Viscaino, 2008).
O padrão IEEE 802.16-2001 foi aprovado em dezembro de 2001 e publicado no
ano seguinte. Foi a primeira versão da família 802.16 também conhecida como IEEE
8
WirelessMAN ou ainda “Air Interface for Fixed Broadband Wireless Access System”
(Interface Aérea para Sistema de Acesso sem Fio de Banda Larga Fixa), e possuía como
principais características o fornecimento a acesso de uma rede para edifícios através de
comunicação utilizando uma antena externa com uma estação base, fazendo uso da
topologia PMP, operando em frequências de rádio de 10 a 66 GHz com taxas de
transmissão média de 70 Mbps e necessitava de ambiente LOS. Suas emendas sucessoras
ao padrão IEEE 802.16 possibilitaram que uma única estação base (BS) ofereça BWA
(Broadband Wireless Access – Acesso a Banda Larga sem Fio) para estações assinantes
fixas e estações moveis.
A versão 802.16a foi aprovado em Abril de 2003, o qual foi projetado para operar
em frequências mais baixas comparadas ao seu antecessor, em frequências de 2 a 11 GHz,
com suporte para condições sem visada (NLOS). Suas características com taxas de
transmissão de 75 Mbps, com alcance de até 50 km visava competir com tecnologias que
ofereciam acesso a última milha como xDSL (Digital Subscriber Line – Linha Digital do
Assinante) e cable modems (cabo modem). O padrão IEEE 802.16b criado
posteriormente, possui aspectos relativos à qualidade de serviço. O IEEE 802.16c prover
interoperabilidade, protocolos e especificações de testes de conformação. O padrão IEEE
802.16-REVd, que foi publicado em 2004, após inúmeras revisões nas emendas anteriores
e diversas inclusões. Esse novo padrão consolidou as emendas 802.16a e 802.16c em
apenas um padrão, se tornando o padrão base. Como características dessa nova emenda,
podemos mencionar a provisão de suporte para antenas MIMO (Multiple-Input Multiple-
Output – Múltiplo de Entrada Múltiplo de Saída), aumentando a confiabilidade do alcance
multipercurso.
Especificações de mobilidade foram publicadas com o padrão 802.16e em 2005,
este padrão é a solução banda larga sem fio móvel do WiMAX, como largura de banda
limitada (máx. 5 MHz), com diferentes possibilidade de faixas frequência (2 a 6 GHz),
velocidade e antenas menores possibilitando o handover em velocidades veiculares de até
150 Km/h com latências menores de 50 ms, que garante que aplicações em tempo real,
como streaming de vídeos ou VoIP, não sofram detração ou interrupções. O padrão IEEE
802.16e utiliza OFDMA que é similar ao OFDM pelo fato de dividir as portadoras em
várias sub-portadoras, porem vai mais além, agrupando diversas sub-portadoras em sub-
canais, onde um único cliente poderá transmitir utilizando todas sub-portadoras no espaço
da portadora (Lima et al, 2004).
9
Outros padrões estão sendo desenvolvidos, alguns deles aguardando aprovação
para publicação, contendo melhorias nos padrões anteriores ou novas implementações.
Dentre essas propostas podemos citar: o IEEE 802.16f com a proposta de proporcionar
um modelo para gerenciamento de redes no padrão IEEE 802.16d, utilizando nodos
gerenciados e banco de dados contendo fluxos de serviços, também introduzindo o
conceito de redes em malha (mesh networks); o IEEE 802.16g possui a proposta de provê
esquemas de gestão de rede, produzindo um gerenciamento eficiente e interoperável da
rede, mobilidade, espectro e a padronização do comportamento do plano de gerência em
dispositivos 802.16 fixos e móveis com o foco nos padrões IEEE 802.16d e IEEE
802.16e; o IEEE 802.16i que tem como proposta fornecer melhorias na mobilidade para
o 802.16 MIB (Management Information Base – Gerenciamento da Base de Informação)
na camada de enlace (MAC), na camada física (PHY) e outros procedimentos de gestão;
o IEEE 802.16k tem em seu escopo a proposta de definir procedimentos e melhoramentos
na camada de enlace (MAC) de modo que o padrão IEEE 802.16d posso assegurar a
funcionalidade brigde (ponte); o IEEE 802.16h propõe melhorar mecanismos MAC para
permitir coexistência entre dispositivos IEEE 802.16d isentos de licença, ou que utilizem
a mesma banda (Ilyas, 2008).
O Quadro 1 exibe as principais emendas do padrão IEEE 802.16 e suas respectivas
especificações
Quadro 1 – Principais emendas do padrão IEEE 802.16.
Fonte: Adaptada de Ahson, Ilyas, 2008.
Principais Emendas
802.16 802.16e 802.16f 802.16g 802.16k 802.16h
Tipo Padrão Padrão Alteração Padrão Padrão Alteração
Principais
Características
Taxas de
transferências
de 32 a 134
Mbps, com
mobilidade
fixa e raio de
2 a 5 km.
Suporte à
mobilidade
(handover),
com taxas
de
transmissão
de no
máximo
15Mbps.
Modelo e
sistema de
gerenciamento
de redes para
nodos e banco
de dados de
fluxos de
serviços
(NMS), e
redes em
malha.
Esquemas de
gestão de rede,
gerenciamento
eficiente e
interoperável
da rede,
melhorias e
avanços na
mobilidade.
Definir os
procedimentos
para suportar a
funcionalidade
ponte (bridge)
e melhorias na
camada de
enlace (MAC).
Desenvolver
métodos
para
melhorar o
desempenho
WiMAX
isentos de
licença
Homologação Dez. - 2001 Dez. - 2005 Set. - 2005 Set. - 2007 Mar. - 2007 Jul. - 2010
Faixa de
Frequência
10 – 66
GHz
2 – 6
GHz
2 – 11 GHz
10-66 GHz
2 – 11 GHz /
10-66 GHz
2 – 11 GHz
10-66 GHz
2 – 11 GHz
10-66 GHz
Visibilidade LOS NLOS NLOS NLOS NLOS NLOS
10
2.3 Arquitetura e Protocolos WiMAX
Abordaremos a seguir a arquitetura e protocolos utilizados em redes WiMAX,
dando foco para as duas primeiras camadas da pilha de protocolo: a camada física e a
camada de enlace de dados (MAC), como pode ser visto na Figura 2.
Aplicação
Apresentação
Sessão
Transporte
Rede
Enlace de
Dados
Física
Controle de Acesso ao Meio
Gerenciamento de QoS
Suporte para as PHYs OFDM e OFDMA
Segurança (Enterprise Class)
Sincronismo
Interface para IP, ATM, E1/T1, Ethernet
Dynamic Frequency Selection (DFS), em bandas
não licenciadas
Suporte a sistemas com antenas adaptativas
Suporte a Topologia Mesh (opcional)
OFDM FFT-256, TDMA (TDD/FDD)OFDMA FFT 2048 pontos com TDMA (TDD/FDD)Single Carrier (SCa) FTT 2048 pontos com TDMA (TDD/FDD) TDMA (TDD/FDD) BPSK, QPSK, 4-QAM, 16-QAM, 64-QAM, 256-QAMWirelessHUMANAté 66 GHzAté 74 Mbit/sPotência máxima de transmissão: +28 dBmÁreas de cobertura Ponto-Multiponto: 8-20 km (rural), 2-8 km (urbano) Ponto-a-Ponto: acima de 40 km
Figura 2 – Pilha de protocolos padrão IEEE 802.16
Fonte: Figueiro, 2008.
O padrão IEEE 802.16 desenvolvido, define uma camada física para sistemas em
operações em duas faixas de bandas: 10 a 66 GHz e 2 a 11 GHz, e possui como finalidade
especificar uma interface sem fio para redes metropolitanas (WMAN). As normas e regras
desenvolvidas pela IEEE para o padrão 802.16 foram adotadas mundialmente, inclusive
pela ISO (International Organization for Standardization – Organização Internacional
para Padronização), e definem a pilha de protocolo conforme o modelo OSI (Open
Systems Interconnection - Interconexão de Sistemas Abertos), demonstrado na Figura 2.
Esse modelo é dividido em camadas hierárquicas no qual cada camada utiliza as funções
da própria camada ou da camada anterior para tornar o processo de transporte de
informação transparente para o usuário, seja ele um programa ou uma outra camada. Na
Figura 2, duas camadas são detalhadas com algumas de suas especificações para a pilha
de protocolo do padrão do WiMAX, a camada de enlace (MAC) e a camada física, com
suas principais modulações e funções.
11
Como o padrão IEEE 802.16 foi criado para satisfazer a necessidade de diversos
setores da indústria, suas emendas e revisões eram criados e adicionados ao padrão,
tornando-o complexo e que abrangia um grande escopo de atuação, e possibilitando várias
opções de implementações.
Para que todos os fabricantes de equipamentos, semicondutores, integradores de
sistemas e provedores de serviços obtivessem compatibilidade, conformidade e
interoperabilidade entre si, foi formado em 2001 o WiMAX Fórum (WiMAX Forum,
2013), que fornece certificações de interoperabilidade de produtos baseados no padrão
IEEE 802.16, possibilitando a interação e padronização de produtos e serviços para a
indústria e afins que irão desenvolver produtos para a tecnologia WiMAX.
A Figura 3 demostra uma das principais extensões ao padrão IEEE 802.16 que é
uma sugestão de modelo padronizado de arquitetura de rede, chamado de modelo de
referência de rede WiMAX.
O provedor de acesso à rede (NAP – Network Acess Provider) é a entidade que
disponibiliza o acesso de rádio aos provedores de serviços à rede (NSPs – Network
Service Providers) e controla as redes para serviço de acesso (ASNs – Acess Service
Network). Os NSPs fornecem a conectividade IP e os serviços WiMAX, e também
gerenciam as redes de serviços de conectividade (CSNs – Connectivity Service Network).
O WiMAX suporta dois tipos de mobilidade em sua arquitetura: Mobilidade apoiada por
ASN e Mobilidade apoiada por CSN (ANDREWS et al, 2007).
12
Figura 3 – Arquitetura de rede proposta pela WiMAX Fórum.
Fonte: Adaptada de Wimax Forum, 2006.
R1: As conexões IEEE 802.16 entre estação assinante/estação móvel (SS / MS)
com a estação base (BS);
R2: Ocorre a autenticação, autorização dos serviços, as configurações de host IP
e o gerenciamento da mobilidade;
R3: Os protocolos entre ASN e CSN para suporte a autenticação, autorização e
auditoria;
R4: Os protocolos entre ASN-GWs (ASN Gateways) para coordenar a mobilidade
das estações móveis e interoperabilidade entre ASNs;
R5: Os protocolos de interconectividade entre os CSNs;
R6: Os protocolos para a comunicação entre estação base (BS) e ASN-GW;
R7: O ponto de referência opcional entre o ponto de decisão de política (PDP) e o
ponto de aplicação de política (PAP);
R8: As mensagens entre estações base (BSs) para garantir handover rápido e
transparente.
13
CS SAP
SUBCAMADA DECONVERGÊNCIA (CS)
MAC SAP
PARTE COMUM DASUBCAMDA MAC
(MAC CPS)
SUBCAMDA DEPRIVACIDADE
PHY SAP
CAMADA FÍSICA (PHY)
MA
CP
HY
Transformação ou mapeamento de dados da rede externa em SDUs MAC (oferece suporte a ATM e protocolos baseados em pacotes)
Funcionalidades do núcleo MAC do sistema de acesso, alocação de largura de banda, estabelecimento e manutenção de conexão
Autenticação, troca de chaves seguras e criptografia
Diversas especificações, cada uma delas apropriada a uma dada faixa de frequência
Figura 4 – Pilha de protocolos do IEEE 802.16.
Fonte: IEEE Std 802.16-2001, 2001.
Os protocolos presentes no padrão IEEE 802.16 são classificados no modelo OSI
nos níveis: Usuário, Controle e Gerência. Pode-se observar na Figura 4, a existência de
duas últimas camadas: a camada de enlace (MAC) e a camada física (PHY).
A camada de enlace (MAC - Medium Access Control - Controle Médio de Acesso)
é responsável por implementar o método de acesso ao meio, delimitar a estrutura de
quadro de enlace e fazer o reconhecimento dos endereços MAC, possui também o
objetivo de detectar e corrigir (opcional) os erros que ocorram no nível físico durante a
transmissão de bits. A camada MAC é dividida em três subcamadas no IEEE 802.16:
Subcamada de Convergência de Serviços Específicos (MAC CS - Service Specific
Convergence Sublayer), Subcamada de Parte Comum (MAC CPS – Common Part
Sublayer) e Subcamada de Segurança (MAC SS – Security Sublayer).
A subcamada MAC CS é responsável por transformar os dados recebidos do ponto
de acesso de serviço (SAP – Servicce Access Point) em pacotes de dados MAC, a
transformação mapeia informações da rede externa em informação MAC, como fluxo de
serviço e identificador de conexão (CID). A subcamada também é responsável pela
manutenção/provisionamento de QoS e permissão de alocação de banda. A subcamada
MAC CPS possui a funcionalidade de controle de acesso, alocação de banda,
estabelecimento e manutenção da conexão, troca de dados, controle PHY e outras
informações de gerenciamento com a camada PHY através da PHY SAP. A subcamada
14
MAC SS tem como função a autenticação, a troca de chaves seguras, criptografia e
integridade do controle de acesso. A troca segura de chaves entre as BSs e SS/MS é
efetuada utilizando protocolo de chave privadas (EKLUND et al, 2002).
A camada física (PHY) tem a função de transmitir e receber os dados. Na faixa de
espectro de 10 a 66 GHz ela especifica ambiente considerando linha de visada (LOS)
entre BS e SS, suportando ampla largura de banda de 20, 25 ou 26 MHz (Ilyas, 2008). No
projeto de especificação da camada física a propagação LOS foi utilizada, pois em faixas
de frequências mais altas (10 – 66 GHz) não há suporte para propagação NLOS, devido
essa restrição, a técnica de modulação escolhida foi a SCM (Single Carrier Modulation
– Modulação Única de Portadora) com FEC (Forward Error Correction – Correção
Antecipada de Erros), a qual foi denominada “Wireless MAN-SC”. Para faixas de
frequências mais baixas (2 – 11 GHz) o padrão 802.16 especifica bandas licenciadas e
não licenciadas. Oferece suporte a propagação NLOS e modulação OFDM e OFDMA
com desempenho e nível de eficiência espectral alto (LIMA et al, 2004).
2.4 QoS em Redes WiMAX
O WiMAX implementa QoS (Quality of Service – Qualidade de Serviço) na sua
camada de enlace (MAC) de forma nativa, especificamente no padrão IEEE 802.16e, o
que facilita a interação com o gerenciamento de recursos de rádio, camada física e
proporciona para fabricantes e desenvolvedores uma vasta possibilidade de aplicações
utilizando esse recurso. Nas especificações para interface aérea do padrão IEEE 802.16 o
conceito de QoS está relacionado à: classificação, escalonamento por fluxos de serviços
e estabelecimento de serviços (IEEE STD 802.16-2001, 2001).
O framework do WiMAX no padrão IEEE 802.16e utiliza cinco classes de
serviços (CoS – Class of Service): UGS (Unsolicited Grant Service – Serviço de
Concessão não Solicitado), ertPS (extend real-time Polling Service – Serviço de Locação
em Tempo Real Estendido), rtPS (real-time Polling Service – Serviço de Locação em
Tempo Real), nrtPS (non real-time Polling Service – Serviço de Locação Sem Tempo
Real) e BE (Best Effort – Melhor Esforço), que são utilizados para classificar os fluxos
de serviços.
15
A CoS UGS suporta tráfegos em tempo real, bastante sensível ao atraso, possui
pacotes de dados de tamanho fixo e requer alocação fixa de largura de banda. A BS
fornece concessões sem solicitação.
A CoS ertPS é uma classe de serviço relativamente nova comparada com as quatro
demais, e foi adotada recentemente pelo padrão. Suporta trafego de tempo real como a
UGS, porém possui requisitos de tolerância ao atraso e taxa de dados. A BS também
fornece concessões sem solicitação, mas com alocação dinâmica.
A CoS rtPS também suporta tráfegos em tempo real, contudo, os dados são mais
tolerantes ao atraso que as classes de serviços de tempo real anteriores, e o tamanho dos
pacotes de dados são dinâmicos. A BS executa periodicamente uma alocação individual
para requisições de banda de SSs para essa classe de serviço.
A CoS nrtPS é uma classe de serviço com tráfego de dados que não são de tempo
real, requer um mínimo de reserva de taxa de dados. A BS executa uma alocação
individual para requisições de banda de SSs.
Enfim a CoS BE que suporta aplicações sem garantias em termos de atraso e taxa
de dados. As estações assinantes (SSs) enviam suas requisições através de mecanismos
de contenção do canal (NUAYMI, 2007).
Cada classe de serviço possui um conjunto de parâmetros de QoS que são inclusos
na definição do fluxo de serviço quando a CoS está ativa para este fluxo, parâmetros
como: prioridade de trafego, jitter, máxima e mínima taxa de dados, máximo atraso e
latência máxima.
No Quadro 2 essas cinco CoS e algumas das aplicações típicas onde elas são
aplicadas avaliando os parâmetros de QoS para cada aplicação são listadas.
16
Quadro 2 – Classes de serviços WiMAX e seus parâmetros de QoS.
Fonte: Adaptada de Belghith, Nuaymi, 2008.
No padrão 802.16 a camada de enlace é orientada a conexão, onde mensagens de
sinalização entre estação base e estação assinantes necessitam ser trocadas para que um
fluxo de serviço seja estabelecido. Cada fluxo de serviço recebe uma série de parâmetros
QoS e é caracterizado por eles na sua classificação, onde são indicados latência e jitter
necessários e a garantia de vazão. Cada fluxo de serviço recebe da estação base um único
identificador, chamado SFID (Service Flow Identifier – Identificador de fluxo de serviço),
com a finalidade de identificar cada fluxo de serviço individualmente. Todo fluxo de
serviço ativo possui também um identificador de conexão, chamado de CID (Connection
Identifier), ou seja, para cada conexão entre estação base e estação assinante associada a
um ou mais fluxos de serviço, será atribuído um CID (Ieee 802.16e, 2005).
A arquitetura de QoS do WiMAX é apresentada na Figura 5, onde podemos
observar que escalonadores, classificadores e parâmetros de QoS estão presentes na
camada de enlace (MAC) na estação base (BS) e na estação assinante (SS). O papel da
BS na arquitetura de QoS do WiMAX é efetuar o gerenciamento e a manutenção da QoS
de todos pacotes transmitidos, gerenciando a distribuição dinâmica de tempo de uso da
largura da banda para as SSs, utilizando as informação que as SS enviam pelos quadros
de gerenciamento. Um modelo de quadro de gerenciamento é ilustrado na Figura 6.
Serviço de
Escalonamento
Dados Correspondentes
a Prestação de Serviços Aplicações Típicas
Parâmetros de QoS
Obrigatórios
Unsolicited Grant Service
(UGS)
Unsolicited grant service
(UGS)
VoIP sem supressão de
silêncio
Vazão máxima sustentada
Latência máxima tolerada
Jitter tolerado
Extended Real-Time
Polling Service (ertPS)
Extended realtime
variable-rate service
(ERT-VR)
VoIP com supressão de
silêncio
Vazão mínima reservada
Vazão máxima sustentada
Latência máxima tolerada
Prioridade de tráfego
Jitter tolerado
Real-Time Polling
Service (rtPS)
Real-time variable-rate
service (RT-VR)
Streaming de áudio ou
vídeo
Vazão máxima reservada
Vazão máxima sustentada
Latência máxima tolerada
Prioridade de tráfego
Non-Real-Time Polling
Service (nrtPS)
Non-real-time variable
rate service (NRT-VR)
FTP (File Transfers
Protocol)
Vazão mínima reservada
Vazão máxima sustentada
Prioridade de tráfego
Best-Effort Service (BE) Best-effort service (BE) Web browsing, e-mail Vazão máxima sustentada
Prioridade de tráfego
17
Figura 5 – Arquitetura de QoS no WiMAX
Fonte: VALENTE, 2011.
Para que a comunicação aconteça entre BS e SS, o controle de admissão de
conexão (CAC – Connection Admission Control), que fica dentro da BS deve ser
acionado, onde as solicitações podem ser iniciadas através da BS, que é uma condição
obrigatória, ou pode ser iniciada pela SS que é uma condição opcional. O CAC efetua a
admissão ou rejeição das requisições de conexão, utilizando os parâmetros de QoS para
efetuar essa avaliação. As mensagens requisitando acesso contêm esses dados de QoS e
são chamadas de DSA-REQ (Dynamic Service Addition Request – Solicitação de Adição
de Serviço Dinâmico), se os parâmetros de QoS estiverem de acordo com os recursos
disponíveis da BS, é enviado como resposta de aceitação a mensagem chamada DAS-
RSP (Dynamic Service Addition Reponse – Resposta de Adição de Serviço Dinâmico) da
BS para a SS, após é criado o novo fluxo de serviço que recebe um SFID. Após criado, o
fluxo de serviço é classificado, onde os pacotes de dados são mapeados para uma conexão
específica para que a transmissão entre pares MAC possa ocorrer. No processo de
18
mapeamento o pacote de dados é associado a uma conexão, juntamente é criando uma
associação com as características do fluxo de serviço desta conexão (NEVES, 2010).
Figura 6 – Quadro de gerenciamento WiMAX
Fonte: Eklund et al, 2002.
Continuando o processo de comunicação entre BS e SS, após a classificação
do fluxo de serviços, inicia-se o aspecto mais complexo na provisão de QoS para os
pacotes individuais, que é realizada por três escalonadores: Escalonadores Downlink e
Escalonadores Uplink, situados na BS, onde gerenciam os fluxos no sentindo downlink
ou uplink respectivamente de BS para SS ou inverso, e o Escalonador da estação assinante
(SS) que gerencia os fluxos no sentindo uplink, da SS para BS. O objetivo do escalonador
é determinar o perfil de streaming de dados (Burst Profile), requisitos de largura de banda
das SS, parâmetros de modulação, parâmetros de codificação e o período que cada
conexão terá de transmissão, utilizando os parâmetros de QoS que estão associados ao
fluxo de serviço.
O escalonador downlink que fica na BS, possui um papel simples comparado
ao escalonador uplink, pois as filas de pacotes downlink ficam na BS e seus estados são
de fácil acesso local. As informações contendo decisão de alocação de tempo de uso da
banda são transmitidas no subquadro downlink contendo o campo DL-MAP (Downlink
Bandwidth Allocation Map – Mapa de Alocação de Largura de Banda Downlink),
ilustrado na Figura 6. Através desse campo, é informada a SSs o tempo e as propriedades
da camada física para a transmissão de pacotes.
19
O papel do escalonador uplink, situado na BS, é uma pouco mais complexo,
pois as filas de fluxos de pacotes uplink estão espalhadas entre as SSs, seus estados e
requisitos de QoS precisam ser obtidos através de solicitação a cada SSs. Todas as
informações depois de coletadas, irão ser armazenadas numa fila virtual, assim o
escalonador uplink decidirá as alocações que devem ser feitas baseando-se nas
solicitações de banda, parâmetros de QoS e prioridades de classes de serviços. Essas
informações são transmitidas para as SSs pelo campo UL-MAP (Uplink Bandwidth
Allocation Map - Mapa de Alocação de Largura de Banda Uplink).
Por fim, há o escalonador situado na estação assinante (SS), que visita as filas
e seleciona os pacotes para transmissão. Os pacotes selecionados são transmitidos para a
BS e os dados de tempo de alocação e parâmetros de QoS são informados no campo UL-
MAP do quadro de gerenciamento (RODRIGUES, 2009).
2.5 Resumo do Capítulo
Este capítulo abordou sobre as tecnologias que serão utilizadas neste projeto,
descrevendo conceitos, suas ramificações e ementas, protocolos e arquiteturas
envolvidas, dentre outras características sobre a redes WiMAX. Também abordou sobre
o framework de QoS e suas classes de serviços, demostrando a arquitetura, conceitos e
classificações de cada classe para cada tipo de tráfego.
O capítulo 3 mostrará definições e conceitos a respeito da Qualidade de
Experiência (QoE) voltada para redes sem fio, abordando as métricas utilizadas para
avaliação da qualidade final de vídeos.
20
3. QUALIDADE DE EXPERIÊNCIA EM REDES
SEM FIO
Esse capítulo descreve sobre Qualidade de Experiência (QoE) demostrando
conceitos e a sua aplicabilidade, detalhando algumas métricas de qualidade que utilizam
parâmetros analíticos humanos de avaliação de qualidade, com o foco em vídeos
transmitidos através de redes sem fio. As métricas serão divididas em duas categorias:
subjetiva e objetiva, onde serão abordados conceitos, estruturas e modelos matemáticos
utilizados para realizar as avaliações.
3.1 Qualidade de Experiência (QoE)
O crescente desenvolvimento tecnológico e a grande necessidade da nova geração
de usuários na utilização de recursos multimídias espalhados nas diversas plataformas
atuais de comunicação como VoIP (Voice over Internet Protocol – Voz sobre Protocolo
de Internet), IPTV (Internet Protocol Television – Protocolo de Internet para Televisão),
streaming de aplicações de áudio e vídeos e clouding computer2, demandam a criação de
meios eficientes de transmissão e comunicação, na sua maioria portáteis e de rápido
acesso. Mas disponibilizar apenas o acesso não é mais o suficiente.
As aplicações e serviços assim como seus usuários atuais exigem um nível de
qualidade na entrega e utilização dos mesmos, tanto no ponto de vista da disponibilidade
da rede (QoS – Quality of Service – Qualidade de Serviço), quanto na visão do usuário
final (QoE – Quality of Experience – Qualidade de Experiência). Nas próximas seções
será estudado com mais profundidade a maneira pelo qual podemos quantificar o nível de
qualidade dos serviços prestados do ponto de vista do usuário. As tecnologias de acesso
sem fio, como o WiMAX, e o seu framework de QoS (Ieee, 2005), garantem uma conexão
sem fio estável e que atenda aos requisitos de diferentes aplicações e principalmente as
do usuário final. O desempenho da rede atualmente é avaliado através das métricas de
QoS, que são definidas como um conjunto de métricas que indicam a capacidade da rede
2 É um modelo que possibilita acesso, de modo conveniente e sob demanda, a um conjunto de recursos
computacionais configuráveis (por exemplo, redes, servidores, armazenamento, aplicações e serviços) que
podem ser rapidamente adquiridos e liberados com mínimo esforço gerencial ou interação com o provedor
de serviços.
21
em disponibilizar garantia de serviços. A implementação do QoS é importante para uma
avaliação de qualidade do serviço entregue utilizando métricas como vazão, jitter, atraso,
perda de pacotes, mas apenas do ponto de vista da rede, não considerando o ponto de vista
do usuário. Contudo o foco tem mudado para o ponto de vista do usuário final em relação
ao serviço entregue e sua utilização, pois ele é o principal interessado na utilização dos
serviços e não existe padrão de qualidade melhor que a opinião do usuário.
O QoE visa utilizar métricas de avaliação para a melhor utilização considerando
o ponto de vista do usuário e suas percepções. O termo QoE surgiu para ocupar outros
pontos de avaliações e métricas para aplicações multimídias para o usuário, avaliando o
impacto das aplicações através da sensibilidade humana. Diferente das técnicas de
avaliação de QoS, que se baseiam apenas em parâmetros da rede, métricas de QoE são
usadas para mensurar como o usuário percebe a aplicação (Oliveira, 2011). A utilização
destas métricas servem como extensão aos parâmetros de QoS, melhorando o controle e
operações nas arquiteturas de redes e protocolos, consequentemente, proporcionando
melhorias para serviços de aplicações de áudio e vídeo (FERREIRA, 2009).
O estudo do QoE, tem sido uma forte tendência e de destaque mundial, possuindo
grupos importantes de pesquisas como: International Telecommunication Union –
Telecommunication Standardization Sector (ITU-T – União Internacional de
Telecomunicações – Setor de Normatização das Telecomunicações) (ITU-R
Recommendation BT.500-11, 2002), Video Quality Experts Group (VQEG - Grupo de
Especialistas em Qualidade de Vídeo) (VQEG, 2000) e ETSI (European
Telecommunications Standard Institute - Instituto Europeu de Padronização de
Telecomunicações), STQ (Technical Committee Speech Processing, Transmission and
Quality Aspects – Comitê Técnico para Discurso de Processamento, Aspectos de
Qualidade e Transmissão) (ETSI, 2011) e (ITU-R RECOMMENDATION P.800-1,
1998), (LU et al, 2004).
As métricas de QoE, retornam um valor quantitativo no qual é mapeado para uma
faixa e valores qualitativos, essas métricas podem ser objetivas e subjetivas. A Figura 7
apresenta a principal diferença entre as abordagens, na qual a subjetiva é baseada na
opinião dos usuários onde as emoções, serviços e experiência influenciam bastante. Por
outro lado a objetiva tenta assimilar a percepção humana através de algoritmos baseados
em informações da rede, transporte e fatores de aplicação.
22
Figura 7 – Abordagem objetiva x Abordagem subjetiva.
Fonte: Oliveira, 2011.
A seguir iremos detalhar um pouco mais sobre essas duas abordagens, tipos de
métricas e suas principais utilizações.
3.1.1 Métricas Subjetivas
As métricas subjetivas têm como objetivo avaliar a qualidade dos serviços
prestados por aplicações baseadas na opinião/percepção do usuário. A qualificação da
mídia é feita conforme a experiência que o usuário teve diante da mesma, atribuindo uma
nota conforme seu ponto de vista. Essa métrica depende apenas do usuário final, já que o
grande objetivo é melhorar os serviços para ele. É a abordagem mais precisa para se
avaliar a qualidade de um vídeo, porém o índice de qualidade fornecido pelo usuário pode
sofrer várias mudanças e depender de fatores como experiência em avaliação, o humor
do usuário no momento do teste e outros fatores emocionais.
Os métodos de avaliação têm como base técnicas definidas com padrão
internacional, como a ITU-T. Existem normas especificas para cada atuação e suas
particularidades como: televisão a cabo e aplicações multimídias. Outras especificações
como configuração do ambiente, escolha dos avaliadores, metodologia dos testes também
são recomendadas pelas normas. As normas mais utilizadas são a BT.500 da ITU (ITU,
2000) e a P.900 da ITU (ITU, 2008).
O processo e avaliação subjetiva segue uma sequência de ação: primeiramente é
feita a construção de um painel de observadores que irá avaliar um ou mais vídeos,
analisar e atribuir uma nota conforme seu consentimento e conforme a sua opinião sobre
23
a qualidade do vídeo. Essa nota possui uma escala de valores pré-formatados que
dependendo do objetivo da avaliação podem ser previamente descritos aos avaliadores.
A forma de resultados mais comum para a avaliação subjetiva é a medição através do
MOS (Mean Option Score - Opção Média de Pontuação), na qual as notas para o vídeo
possuem uma escala de 1 a 5, onde 1 representa a pior nota e cinco a maior, como mostra
na Tabela 1 os valores e seus respectivos significados (DARONCO, 2009).
Tabela 1 - Valores do MOS.
Fonte: Daronco, 2009.
Embora a abordagem utilizando as métricas subjetivas sejam as mais precisas,
pois conta diretamente com a opinião/avaliação do principal alvo da aplicação, o usuário
final, esse tipo de teste demanda muito tempo para sua execução, pois requer uma
quantidade significante de avaliadores, o que acarreta em maiores custos e investimentos.
Outro ponto negativo é a dependência humana para realização dos testes, o que impede
que a abordagem seja feita inúmeras vezes e de forma automatizada em sistemas de tempo
real. Outras métricas que funcionam independente da interação humana podem ser
utilizadas no QoE, são as métricas objetivas, que serão detalhadas a seguir.
3.1.2 Métricas Objetivas
A abordagem objetiva, diferente da subjetiva, dispensa a interação humana para
avaliação e visualização dos vídeos, utiliza métricas com algoritmos e modelos
matemáticos computacionais quantitativos, onde os valores computados são mapeados
em valores subjetivos de qualidade. Os modelos matemáticos estimam a qualidade do
vídeo recebido pelo usuário comparando com a qualidade do vídeo original, levando em
conta características como aspectos de luminosidade, contraste, estrutura entre outros, a
fim de se aproximar o máximo da percepção humana de qualidade de vídeo simulando a
sensibilidade do SVH (Sistema Visual Humano) (WINKLER, 2005).
MOS Qualidade Dano ao Vídeo
5 Excelente Imperceptível
4 Bom Perceptível
3 Razoável Levemente Razoável
2 Pobre Irritante
1 Ruim Muito irritante
24
As principais vantagens de utilizar as métricas objetivas são as infinitas
possibilidades de cenários e testes que podem ser criadas e analisadas/avaliadas inúmeras
vezes, diminuindo o tempo das avaliações, custos e investimentos. Outro ponto positivo
é a possibilidade de automação dessas métricas, utilizando aplicativos de tempo real, e
executando a comparação entre o vídeo original repetida vezes sem o desgasto e cansaço
que teria com um avaliador humano. As principais métricas objetivas utilizadas para
avaliar a qualidade de vídeos são: PSNR (Peak Signal to Noise Ratio – Sinal de Pico para
Taxa de Ruído) (Winkler, 2005), SSIM (Structural Similarity Index – Índice de
Similaridade Estrutural) (Niranjan et al, 2000), VQM (Video Quality Metric – Métrica de
Qualidade de Vídeo) (Revés et al, 2006). A seguir iremos falar um pouco mais sobre cada
uma delas.
3.1.2.1 Peak Signal to Noise Ratio – PSNR
O PSNR é a métrica mais tradicional, que estima a qualidade do vídeo em
decibéis, comparando o vídeo original ao vídeo recebido pelo usuário considerando o
aspecto de luminosidade (Winkler, 2005). O PSNR é derivado de outra métrica, chamada
de MSE (Mean Squared Error – Erro Quadrático Médio). O MSE calcula a média de
erro, variação de um atributo real em relação ao qual esse mesmo atributo foi estimado.
Resumindo, ele compara a qualidade do frame recebida pelo usuário ao frame original
(Mallowski, Claben, 2008). O cálculo do MSE é realizado através da soma das diferenças
quadráticas de todos os pixels da imagem original e da imagem processada que está sendo
avaliada. Após isso, o resultado é dividido pelo número de pixels totais, como pode ser
observado na Equação 1.
Equação 1 𝑀𝑆𝐸 = ∑ 𝑀
𝑖=1 ∑ 𝑁𝑗=1 [(f (i,j)−𝐹(𝑖,𝑗))]
2
𝑀 𝑥 𝑁
Onde f (i, j) é o valor de cada pixel na imagem original, F (i,j) é o valor do pixel
na imagem avaliada, M é o número de linhas, e N o número de colunas do quadro. O
MSE resultará sempre em valores positivos e seu valor mínimo é zero e o máximo é 100
se o valor for zero, significa que as imagens são iguais (Begazo, 2012). A partir do MSE
pode-se finalmente obter o valor do PSNR, que é expresso em dB (decibel), utilizando a
Equação 2:
25
Equação 2 𝑃𝑆𝑁𝑅 = 20 log10 (𝑀𝐴𝑋
√𝑀𝑆𝐸)
Onde MAX é o valor máximo do pixel (255 para 8 bits). Há uma qualificação para
o resultado do PSNR, que pode ser usado para mapear valores de MOS. Confira na Tabela
2 o mapeamento PSNR para MOS (JAIN, 2004).
Tabela 2 – Mapeamento PSNR para MOS
Fonte: Jain, 2004.
O PSNR é a métrica mais popular como dito acima, porém não a mais completa,
pois indica apenas a diferença dos frames recebidos em relação aos frames originais,
desconsiderando características importantes do SVH (Sistema Visual Humano)
(FERREIRA, 2009).
3.1.2.2 Structural Similarity Index – SSIM
O SSIM se difere do PSNR pelo fato de sua avaliação não apenas analisar a taxa
de erro do vídeo recebida em relação ao vídeo original, ele avalia o vídeo levando em
consideração algumas características do SVH, ele analisa a similaridade de cores,
luminosidade e estrutura, verificando frame por frame coletando e armazenando esses
valores em vetores para cada atributo, vetor para luminosidade, vetor para estrutura e
outro vetor para cor. Após analisar todos os frames, obtém-se a média de cada vetor e a
combinação dessas três medias gera o valor do SSIM, indicando a qualidade do vídeo
(Nijaran et al, 2000). Todos os aspectos combinados geram um único valor, chamado de
índice (index) como é visto na Figura 8 (MÁSSON, WANG, 2004).
PSNR (dB) MOS
> 37 5 (Excelente)
31 - 37 4 (Bom)
25 - 31 3 (Regular)
20 - 25 2 (Pobre)
< 20 1 (Péssimo)
26
Figura 8 – Estrutura de funcionamento do SSIM.
Fonte: Adaptada de Másson, Wang, 2004.
A formula utilizada para ser obter o valor do index que indica a qualidade do SSIM
é esta apresentada abaixo na Equação 3 (NIJARAN et al, 2000):
Equação 3 𝑆𝑆𝐼𝑀 (𝑥, 𝑦) = (2𝜇𝑥𝜇𝑦+𝑐1)(2𝜍𝜊𝜐𝑥𝑦+ 𝑐2)
(𝜇𝑥2+𝜇𝑦
2+𝑐1)(𝜎𝑥2+ 𝜎𝑦
2+𝑐2)
Onde:
𝜇𝑥 é a média de x;
𝜇𝑦 é a média de y;
𝜎𝑥2 é a variância de x;
𝜎𝑦2 é a variância de y;
𝜍𝜊𝜐𝑥𝑦 é a covariância de y;
𝑐1 = (𝑘1𝐿)2, 𝑐2 = (𝑘2𝐿) são duas constantes, L o valor máximo que pode ser
atribuído a cada pixel, 𝑘1 = 0,01 e 𝑘2 = 0,03 por padrão.
O valor de SSIM resulta em um valor decimal que fica entre 0 e 1, quanto mais
próximo do 1 melhor será a qualidade do vídeo, quanto mais perto do zero pior a
qualidade. Caso o valor recebido seja 1, significa que o vídeo recebido pelo usuário
corresponde em 100% ao vídeo original (TAKAHASHI et al, 2008).
27
3.1.2.2 Video Quality Metric (VQM)
A métrica objetiva denominada VQM foi desenvolvida pelo The Institute for
Telecommunication Sciense (ITS – Instituto de Ciência de Telecomunicação) (Xiao,
2000). Assim como as métricas citadas anteriormente, o VQM também compara o vídeo
original em relação ao vídeo recebido pelo usuário, porém essa métrica é mais completa
que PSNR e SSIM, pois avalia nos seus parâmetros a distorção das cores, distorção dos
pixels, nível de ruído e o nível de brilho (qualidade) do vídeo. É essa combinação de
parâmetros e fatores que geram a métrica VQM. Desse modo, essa métrica de avaliação
é a que mais se aproxima das avaliações de imagens e vídeo feitas pelo SVH (FERRUS,
2006).
O VQM “calibra” os parâmetros na primeira etapa efetuando a comparação do
contraste e brilho. Na segunda etapa ele compara o alinhamento espacial, verificando a
posição no eixo horizontal e vertical de ambos os vídeos. Na terceira etapa ele analisa a
quantidade de pixels perdidos em relação ao vídeo original e por fim, na quarta etapa,
verifica-se o alinhamento temporal que compara o tempo no qual cada frame foi recebido
em relação ao tempo no qual o mesmo deveria ter sido entregue, nessa quarta etapa o
principal objetivo é avaliar o atraso do vídeo recebido pelo usuário (FERREIRA, 2009).
Essa métrica é baseada na DCT (Discrete Cosine Transform – Transformada
Discreta do Cosseno), e para obtenção matemática do VQM os seguintes passos abaixo
são realizados (REIGOTA, 2006):
1º - É feito uma transformação do vídeo para o formato YUV (Y é a luminância,
U (R-Y) é o sinal R (Red) vermelho e Y somados, V(B-Y) é o sinal de B (Blue) azul e Y.
2 º - DCTs de blocos 8x8 são usados para separar as imagens em diferentes
frequências.
3 º - É feito a conversão dos coeficientes da DCT para LC (Local Contrast -
Contraste Local) usando aa equação 4:
Equação 4 𝐿𝐶𝑖 = 𝐷𝐶𝑇𝑖,𝑗 (
𝐷𝐶
1024)2
𝐷𝐶
No qual DC é o coeficiente DCT com índices (posição do pixel) (i,j) = (0,0).
28
4 º - Agora a conversão do LC para “a diferença apenas perceptível” (just
noticeable difference), segundo a equação 5:
Equação 5 𝐽𝑁𝐷𝑖,𝑗 = 𝐿𝐶𝑖,𝑗. 𝐶𝑆𝐹𝑖,𝑗
Sendo o CSF a Função de Sensitividade do Contraste (Contrast Sensitivity
Function) (Peli, 1999).
5 º - Nessa etapa o cálculo da seleção ponderada da média e máxima distorções é
feito. A diferença absoluta (D) entre o vídeo original e reduzido é calculada para cada um
dos coeficientes JND (Just Noticeable Difference - Diferença Apenas Perceptível), como
abaixo:
Equação 6 VQM = media (|D|) + 0.005.máximo(|D|)
Quanto mais próximo o resultado do VQM for de 0, significa que melhor será
a qualidade do vídeo, sendo 0 o melhor possível, o que indica uma menor distorção em
relação ao vídeo original (Niranjan et al 2000). Há ainda outras métricas para avaliação
objetiva como: Moving Picture Quality Metric (Métrica de qualidade para Imagens em
Movimento - MPQM) (Drakos, Moore 1996) e Perceptual Evaluation of Video Quality
(Avaliação Perceptiva da Qualidade de Vídeo – PEVQ) (PEVQ, 2010), que não serão o
foco deste trabalho já que, as métricas anteriormente citadas fornecem resultados
satisfatórios para a análise e estudo efetuado neste trabalho.
Além de oferecer os serviços audiovisuais multimídias de qualidade aos usuários,
utilizando as métricas de análise e avaliação do meio de transmissão, levando em conta o
ponto de vista da rede (QoS), as aplicações atuais devem se preocupar com o principal
interessado, o usuário final. Desse forma, é necessário aplicar novas métricas para avaliar
e aprimorar os serviços fornecidos conforme resultados obtidos pelo ponto de vista do
cliente, utilizando assim métricas especializadas para isto (QoE). Apresentamos métricas
que possuem o intuito de avaliar a satisfação e nível de qualidade do serviço fornecido do
ponto de vista de quem poderá melhor julgar, para que com esses resultados, sejam feitas
alterações e modificações nos meios de transmissão e de qualidade de serviço do ponto
de vista da rede, ou seja, a ideia é integrar os resultados das métricas de QoE para que
junto com as os resultados das métricas de QoS, ajustem o meio de transmissão e
ambiente operacional, visando a melhor qualidade para o usuário final.
29
3.2 Resumo do capitulo
Este capítulo abordou conceitos e métricas referentes a Qualidade de Experiência,
com o foco na medição de qualidade de vídeos trafegados em uma rede sem fio. Foram
descritos duas classes de métricas: métricas subjetivas, que se baseiam na opinião e
percepção do usuário, e métricas objetivas, que dispensam a interação humana para
avaliação se baseando em algoritmos e modelos matemáticos.
O capitulo 4 mostrará alguns trabalhos relacionados com a proposta deste projeto,
com temas relacionados a redes WiMAX, avaliação de QoS e QoE em vídeos, e a garantia
de qualidade do usuário final.
30
4. TRABALHOS RELACIONADOS
Este capítulo apresenta alguns trabalhos relacionados que efetuaram análise e
avaliação do desempenho de redes sem fio na transmissão de conteúdo multimídia,
através de implementações de topologias variadas e padrões de redes diferenciados. Os
trabalhos apresentam métricas tradicionais de qualidade de serviço (QoS) e qualidade de
experiência (QoE) em seus métodos de avaliação.
O autor de Ferreira (2008) efetuou análises e avaliações em um testebed no padrão
para rede local sem fio (WLAN – Wireless Local Area Network) IEEE 802.11 utilizando
transmissões de streaming de vídeos em uma topologia Ponto-Multiponto. Ferreira
(2008) efetuou uma análise comparativa entre duas ementas do padrão para Wifi
(Wireless Fidelity), IEEE 802.11b e IEEE 802.11g, para avaliar qual padrão teria o melhor
desempenho na transmissão de fluxo contínuo de vídeo, simulando características de
vídeo em formato IPTV (Internet Protocol Television – Protocolo de Internet para
Televisão). A avaliação ocorreu utilizando técnicas de QoS, onde o foco de qualidade é
voltado para os serviços da rede. Os resultados não foram satisfatórios, Ferreira concluiu
que para transmissões de vídeo o padrão IEEE 802.11g possui resultados mais
satisfatórios em relação ao seu antecessor IEEE 802.11b, porém o autor concluiu que
embora seja possível a transmissão de vídeo por esse padrão, não se pode garantir a
qualidade final do resultado da transmissão, e que são necessários mecanismos que
permitam garantir a qualidade de serviço exigida pela aplicação para que melhores
resultados possam ser obtidos. Semelhante a nossa proposta, Ferreira efetuou análises e
avaliações de tráfegos de vídeo em redes wireless, porém as avaliações deste autor apenas
envolveram métricas de qualidade voltada para a rede (QoS).
Pereira (2004) adotou também o padrão IEEE 802.11 para redes wireless em seu
projeto, através de simulações utilizando uma topologia ad-hoc. O autor avaliou o tráfego
de vídeo utilizando métricas de QoS, e concluiu que os problemas na qualidade final do
vídeo, após sua transmissão, não depende da topologia de rede utilizada, e sim de
mecanismos que possam efetuar essa classificação de serviços e priorizar os mesmos de
acordo com ambiente utilizado. O autor efetuou a avaliações do trafego de vídeo
transmitidos por redes sem fio, semelhante a proposta deste projeto, contudo o autor
31
utilizou uma topologia ad-roc, além de outro padrão de rede, IEEE 802.11, e novamente
avaliou apenas requisitos de qualidade voltados para a rede.
No trabalho dos autores Avelar et al. (2008) avaliaram o protocolo PMIPv6 quanto
ao suporte à QoE para tráfego de vídeo em um Testebed do padrão 802.11 para tecnologia
wireless, focando na mobilidade. Os autores propõe uma nova implementação para o
protocolo PMIPv6, com algoritmos de antecipação de handoff transparente baseando-se
no nível de sinal do nó móvel (MN - Mobile Node). Eles utilizaram streaming de vídeo
como tráfego gerado e avaliaram os dados transmitidos utilizando métricas PSNR e
SSIM. Nos resultados a implementação da proposta obteve resultados positivos e
melhores nas métricas de QoE do que o protocolo antecessor ao PMIPv6, o MIPv6,
justificando melhorias no ponto de vista de percepção do usuário como principal
justificativa para adesão do novo protocolo. Os autores Avelar et al. avaliam tráfego de
vídeo, através de redes sem fio, utilizando métricas de qualidade de experiência, que é o
mesmo objetivo da proposta deste projeto, porem os autores utilizaram como metodologia
o uso de um testebed, e padrão de rede Wifi, diferentes dos usados por esse projeto, onde
a avaliação será feita em um tráfego de vídeo real, possuindo diferentes complexidades
em redes PMP do tipo WiMAX.
Os autores Sousa et al. (2008) realizaram testes e estudos em um testebed
utilizando a tecnologia WiMAX. Os autores realizaram avaliações utilizando como
métricas para qualidade de vídeo transmitido o MOS e PSNR, com equipamentos
ofereciam suporte a duas classes de serviços (CoS) do WiMAX: BE e rtPS. Após testes
realizados, os resultados mostraram que quando os recursos são suficientes a tecnologia
apresenta um bom desempenho e os requisitos das aplicações e vídeo são atendidas sem
problemas para ambas as classes. Porém, quando o cenário utilizado possuía recursos de
banda limitada, o desempenho foi classificado como ruim para as duas classes de serviços.
Semelhante a nossa proposta, os autores utilizaram o padrão WiMAX para a rede sem fio,
e avaliaram a qualidade de vídeo transmitidos utilizando métricas de qualidade de
experiência, nossa proposta utilizará uma CoS a mais que os autores acima, a UGS,
realizando as avaliações e testes em simulações utilizando vídeos de diferentes
complexidades.
As análises e simulações também podem ser efetuadas em ambientes virtuais para
a tecnologia WiMAX, como exemplo o trabalho do autores Vishwanath et al. (2009), que
32
investigaram a QoE em transmissão de vídeos sobre redes WiMAX utilizando um
simulador de redes virtual. A qualidade foi medida através de simulações, avaliando
métricas como PSNR, além de outros parâmetros de QoS. Como resultado os autores
destacaram várias relações de perda-e-ganho entre os parâmetros do ponto de vista da
rede, e a correlação da variação de parâmetros como banda disponível e latência com a
qualidade final do vídeo. Em nossa proposta iremos avaliar vídeos com diferentes
complexidades em um tráfego real, utilizando mais métricas de QoE nas avaliações, do
que as utilizadas pelo autor acima.
Diferente do que foi visto em todos os trabalhos apresentados e estudados, nossa
proposta visa analisar a confiabilidade de garantia de qualidade de serviço numa
arquitetura WiMAX que provê QoS, utilizando métricas de QoE, utilizando diferentes
complexidades de vídeos.
No quadro 3 é apresentado os trabalhos relacionados discutidos neste capítulo com
uma pequena descrição a respeito de cada um deles.
Quadro 3 – Resumo dos trabalhos relacionados discutidos.
Autor Descrição
Ferreira, 2008
Utilizou um testebed, numa topologia PMP, e métricas de
QoS, efetuou a análise comparativa entre os padrões IEEE
802.11b e IEEE 802.11g avaliando o desempenho numa
transmissão de vídeo continuo.
Pereira, 2004 Utilizou simulação, avaliou trafego de vídeo em uma rede
wireless do tipo AD-HOC, padrão IEEE 802.11, utilizando
métricas de QoS.
Avelar et al., 2008
Como topologia PMP, e métricas de QoS e QoE, avaliou o
protocolo PMIPv6 quanto ao suporte a QoE para tráfego de
vídeo em um Testebed no padrão IEEE 802.11.
Sousa et al., 2008
Realizou teste em ambientes físicos utilizando o WiMAX,
avaliando vídeos transmitidos pela rede wireless com
métricas de QoE, porem com equipamentos que
suportavam duas classes de serviços: BE e rtPS.
Vishwanath et al., 2009 Foram feitas simulações numa arquitetura PMP, efetuando
avaliação de vídeos transmitidos por redes WiMAX,
utilizando métricas de QoE.
Fonte: Própria autoria.
33
4.1 Resumo do Capítulo
Este capítulo apresentou trabalhos relacionados ao da proposta deste projeto,
explanando resumidamente sobre os objetivos e resultados dos autores, comentando as
semelhanças entre os trabalhos citados e a nossa proposta.
No próximo capítulo iremos abordar sobre os matérias e métodos utilizados neste
projeto, descrevendo a metodologia aplicada e as ferramentas necessárias para o
desenvolvimento do projeto.
34
5. MATERIAIS E MÉTODOS
Este capítulo descreve sobre a metodologia e as ferramentas utilizadas para a
realização da proposta. O trabalho descreve as etapas utilizadas para a realização da
proposta visando a conclusão do trabalho, e como foram aplicadas, em seguida tanto as
ferramentas utilizadas para o presente trabalho, quanto as que não foram, serão
justificadas.
5.1 Metodologia
Na etapa inicial foi realizado o estudo do estado da arte sobre redes sem fio e
assuntos complementares com intuito de obter entendimento e embasamento
bibliográfico para a realização da proposta. Foram realizadas pesquisas acerca das teorias
e conceitos envolvendo as redes sem fio e as métricas de qualidade que a regem: WiMAX,
Qualidade de Serviço (QoS), Qualidade de Experiência (QoE), através de referências
bibliográficas, tais como artigos científicos, teses, revistas técnicas e etc.
No segundo momento foi realizado o estudo das ferramentas que visam
implementar a proposta, e de qual maneira poderíamos representa-la computacionalmente
de acordo com as referências bibliográficas estudadas. Optamos por realizarmos nossa
proposta utilizando simulações virtuais, pois possuem custos mais baixos para
implementações, levando também em consideração que no ambiente virtual, testes
poderiam ser feitos incansavelmente e análises e coletas de dados de uma forma mais
prática que as demais. Pesquisas foram realizadas acerca de soluções, a partir de dois
módulos que implementam QoS no WiMAX e que são amplamente utilizados pela
comunidade científica, a pesquisa se orientou em realizar testes de confiabilidade dos
mesmos conforme o estabelecido pelo padrão IEEE 802.16e por meio de simulação, e
obtivemos êxito. Houve modificações no módulo, em relação aos arquivos TCL, que
foram estudados e adaptados para a nossa proposta.
No terceiro momento, realizamos a montagem do cenário, com as configurações
adequadas para os testes de simulação, junto com as configurações adequadas para
realizar a avaliação exata de acordo com o módulo escolhido, foi realizada a coleta dos
35
dados, para as posteriores avaliações, para que com esses dados e resultados em mãos,
pudesse ser feita a devida análise e conclusão a cerca da confiabilidade ou não do módulo.
5.2 Ferramentas
Nesta seção iremos apresentar as ferramentas utilizadas para a realização da
proposta, justificando suas escolhas e apresentando outras possíveis ferramentas
semelhantes.
Para prover a avaliação dos módulos disponíveis, foi utilizada a ferramenta ns - 2
(Network Simulation version 2), um simulador de redes virtual gratuito de código fonte
aberto, que permite ao usuário realizar ajustes e adaptações. O simulador oferece suporte
a simulações com um grande número possibilidades de atores e variações de cenários
(com fio e sem fio), com diferentes cenários baseados nos protocolos TCP, UDP entre
outros. A programação do ns-2 é feita em duas linguagens: C++, (para estrutura básica,
protocolos, agentes e etc.) e TCL (Tool Command Language – Linguagem de comando e
ferramenta), para uso como front-end3. O TCL é uma linguagem interpretada, o qual seus
scripts4 são desenvolvidos e alterados sem a necessidade de recopilação do ns-2, essa
linguagem foi desenvolvida pelo MIT (Massachusetts Institute of Technology - Instituto
de Tecnologia de Massachusetts) (ns-2, 2011). A escolha do ns -2 se justifica por alguns
motivos, em especial o fato de ser um ambiente de simulação totalmente descritivo, que
possui uma forte documentação relacionada a simulações para tecnologias de rede sem
fio, e por ser bastante difundido na literatura científica e acadêmica, e como já dito
anteriormente se trata de uma ferramenta livre de código aberto.
Além do ns -2 existem outras ferramentas presentes na literatura que permitem a
simulação de redes como QualNet, OPNET e OMNeT++ (Pan, 2008). A escolha do ns-
2, ao invés de outros simuladores, se deu por fatores como: diferentemente de dois
similares citadas acima, QualNet e OPNET, que são de caráter comercial e de código
fonte fechado o ns-2 é grátis e possui código fonte aberto. Além do mais, entre as outras
ferramentas de simulação o ns-2 se diferencia por permitir avaliações mais profundas e
propor novas tecnologias relacionadas a protocolos, e por operar em camadas de redes
3 Interfaces gráficas que permitem ao usuário interagir com programas que trabalham originalmente em
modo texto. 4 Script é um texto com uma série de instruções escritas para serem seguidas, ou por pessoas em peças
teatrais ou programas televisivos, ou executadas por um programa de computador
36
mais aprofundadas (camada de enlace - MAC) dos quais as outras ferramentas não atuam.
Outro principal motivo para a escolha no ns -2, é pelo fato do módulo de QoS WiMAX
disponível na literatura científica, ter sido desenvolvido e testado nesta ferramenta de
simulação.
Figura 9 – Ilustração de uma simulação no ns-2
Fonte: Nam, 2013.
O módulo de QoS WiMAX escolhido para a proposta de avaliação, foi o
desenvolvido por Aymen (Belghith, A., Nuaymi, L., 2008), por possuir uma estrutura pré-
definida, documentação clara e consistente, e por ter como principal proposta a
implementação das classes de serviços (CoS) de forma correta obedecendo estritamente
o padrão IEEE 802.16e, além de a implementação ser feita no ns-2. Nas pesquisas
realizadas desta proposta foi encontrado outro módulo que implementa QoS no WiMAX,
o módulo desenvolvido pela LRC (Laboratório de Redes de Computadores) da
UNICAMP (Universidade Estadual de Campinas) (LRC, 2008), mas não possuía
documentação consistente para a implementação, tão pouco referências bibliográficas
para consultas na literatura, e infelizmente todas as tentativas de contato com a equipe do
LRC, foram sem sucesso, o que não favoreceu na utilização de seu módulo.
Figura 10 – Logo representante da tecnologia WiMAX
Fonte: Wimax Forum, 2006.
37
A ferramenta utilizada para avaliação e suporte da proposta foi o EvalVid (Klaue
et al, 2003), um framework utilizado para transmissão e avaliação da qualidade de fluxos
de vídeo transmitidos em redes simuladas, para medir diversas métricas entre elas as de
qualidade de experiência (QoE), tais como PSNR e MOS. Na literatura não foi encontrado
nenhuma outra ferramenta com as mesmas especificações e funcionalidade para esse tipo
de avaliação quanto o EvalVid.
Figura 11 – Imagem de uma execução do EvalVid
Fonte: Própria autoria.
Outra ferramenta utilizada para avaliação foi o MSU VQMT (Video Quality
Measurement Tool – Ferramenta para Medição de Qualidade de Vídeo), desenvolvido
pelo grupo de pesquisa MSU Graphics & Media Lab da Universidade de Moscou (Msu,
2013), que também avalia e calcula métricas de QoE em fluxos de vídeos transmitidos
pela rede.
Figura 12 – Imagem de uma execução do MSU VQMT
Fonte: Própria autoria.
38
Para a plotagem de dados representativos por escala gráfica, utilizamos a
ferramenta XGRAPH, uma ferramenta de geração de gráficos que já faz parte do conjunto
de ferramentas presentes no ns-2, de licença livre (GPL5), sendo compatível nas
plataformas Windows, Unix e Linux (Xgraph, 2013). O XGRAPH efetua a plotagem e
visualização interativa dos dados obtidos através do scripts Tcl/TK.
Outra ferramenta similar ao XGRAPH é o Gnuplot, que também possui
compatibilidades nas plataformas Windows e Unix, também de licença livre (GPL), mas
não foi utilizado por ser mais complexo que o XGRAPH, pois o Gnuplot é um programa
dirigido a comandos para plotagem de dados e funções, que em geral, aceita expressões
matemáticas para a plotagem dos dados (Gnuplot, 2010). Levando em consideração o fato
do XGRAPH fazer parte do leque de ferramentas já disponíveis no ns-2, de sua eficiência
e praticidade, foi essa a ferramenta escolhida para serem gerados os gráficos.
Figura 13 – Imagem de um gráfico plotado pelo XGRAPH
Fonte: Gnuplot, 2010.
Por fim, o sistema operacional utilizado foi o Ubuntu, na versão 9.04 (Ubuntu,
2009), um sistema de licença livre (GPL) e de código aberto (open source) para
plataforma Linux, um sistema operacional bastante conhecido e difundido no meio
acadêmico e científico. A escolha do Ubuntu não foi de caráter obrigatório, pois o
simulador virtual ns-2 e suas ferramentas também podem ser instalados e utilizados em
outros sistemas operacionais com o Windows, por exemplo, que através do Cygwin
instala e permite a configuração e uso do ns-2 no sistema da Microsoft (Cygwin, 2013).
A escolha pelo Ubuntu foi levada em consideração por: se tratar de um sistema
operacional de código aberto, então qualquer alteração ao núcleo do sistema ou nos
demais componente poderiam ser feitas, e o ns-2 foi escrito nativamente para plataformas
5 GNU General Public License (Licença Pública Geral), GNU GPL ou simplesmente GPL, é a designação
da licença para software livre idealizada por Richard Matthew Stallman em 1989, no âmbito do projeto
GNU da Free Software Foundation (FSF – Fundação de Software Livre) (GNU, 2007).
39
Linux, então seus recursos e funcionalidades são mais eficazes e eficientes nesta
plataforma. Em outras plataformas o ns-2 funciona por adaptações e emulações realizadas
por programas terceiros. Outro ponto forte para a escolha do Ubuntu foi o fato de que em
quase 100% das referências bibliográficas consultadas na literatura, a utilização do ns-2
ocorreu em plataformas Linux, e que a própria documentação do módulo escolhido,
deixava recomendações para o seu uso em plataformas Linux.
Figura 14 - Logomarca do Ubuntu
Fonte: Ubuntu, 2009
O fato do Windows não executar o ns-2 nativamente, precisando de programas
terceiros, e que drivers e outras configurações do sistema operacional poderiam interferir
nas simulações, sendo um software de caráter comercial e de arquitetura fechada, o que
impossibilitaria alterações direto no núcleo do sistema, justifica por ele não ter sido
escolhido para este projeto.
5.3 Resumo do Capítulo
Este capítulo abordou sobre a metodologia utilizada para a realização da proposta
deste projeto, detalhando o caminho metodológico utilizado, seguido pelas ferramentas,
detalhando suas principais funções, conceitos e possíveis alternativas que poderiam
também ter sido utilizadas em seus lugares com as mesmas especificações.
No próximo capitulo abordaremos sobre o estudo de caso da proposta, onde
apresentaremos os dados e informações coletadas, derivados de nosso trabalho e
pesquisas.
40
6. AVALIAÇÃO DE GARANTIA DE QUALIDADE
Este capítulo apresenta as avaliações e resultados da proposta deste projeto, por
meio do módulo de simulação para redes WiMAX, no simulador de redes ns-2 versão
2.29. São apresentados os resultados das simulações de rede, para tráfego de dados de
diferentes tipos, como voz, melhor esforço (HTTP - Hypertext Transfer Protocol -
Protocolo de Transferência de Hipertexto, FTP - File Transfert Protocol – Protocolo de
Transferência de Arquivos) e tráfego de vídeo, em um cenário de concorrência por largura
de banda. Os resultados foram obtidos através de métricas de QoS (vazão e atraso), e
métricas de QoE (PSNR, SSIM, VQM), no qual o foco foi avaliar se existe integridade
na garantia de qualidade de serviço por parte do módulo proposto por Aymen (Belghith,
A., Nuaymi, L., 2008), em relação a tráfegos multimídias.
6.1 Parâmetros de Simulação e Topologia de rede
O ns-2 é uma das ferramentas mais utilizadas para simulações de redes, porém por
padrão não permite a simulações em redes WiMAX com suporte nativo à QoS, por esse
motivo, utilizamos o módulo desenvolvido por Aymen (Belghith, A., Nuaymi, L., 2008),
que em sua proposta afirmar implementar três classes de serviços: UGS, rtPS e BE.
Dessa maneira, utilizou-se neste trabalho o simulador de rede ns-2 e o módulo que
implementa QoS para WiMAX devidamente configurados, para analisar e investigar a
confiabilidade de garantia de qualidade de serviço nesta arquitetura, avaliando tráfegos
de streaming de vídeo através de métricas de QoS e QoE.
Para as simulações de tráfegos multimídias, utilizou-se da ferramenta EvalVid,
que nos permitiu inserir tráfegos de vídeos reais no simulador ns-2, para que o cenário
fosse o mais realístico possível e possibilitasse a utilização das métricas de QoE com
maior proximidade e fidelidade em comparação com avaliações em ambientes reais.
Os valores configurados para rede cabeada foram definidos de forma a não
introduzir atraso na rede com o fim de não interferir na avaliação deste parâmetro. Os
valores de largura de banda na BS descritos na Tabela 3 para cada resolução de vídeo
indicam a largura de banda máxima suportada pela BS em cada simulação em ambos os
sentidos de tráfego. Os valores de taxa de dados requerida, descritos na Tabela 3,
41
representam a somatória dos valores de taxa máxima sustentada, conforme mostrado mais
adiante na Tabela 4, configurados para as classes de serviço rtPS, UGS e BE para todas
as simulações. A Tabela 3 apresenta um resumo dos parâmetros utilizados nas
simulações, como modulação, frequência dentre outros.
Tabela 3 – Parâmetros utilizados nas simulações
Fonte: Própria autoria.
Os parâmetros de QoS para os tráfegos de vídeo como taxa mínima reservada e
taxa máxima sustentada foram configurados de forma a permitir que os tráfegos fluísse
sem gargalo. Os valores de referência, mínimos e máximos de vazão necessária para os
vídeos, foram obtidos através de simulações utilizando apenas tráfego de vídeo. Para as
classes UGS e BE os valores foram os mesmo para todos os cenários sendo 1,5 Mbps
para taxa máxima sustentada e 1 Mbps para taxa mínima reservada. O resumo das
configurações dos parâmetros específicos para cada classe de serviço utilizada nas
simulações, presente na BS e nas SS para as interfaces 802.16e estão descritas na Tabela
4 a seguir.
Parâmetros de Simulação Valor
Rede Cabeada
Capacidade do Enlace 100 Mbps
Atraso do Enlace 1 ms
Tamanho do Buffer 50
Tipo de Fila Drop Tail
WiMAX
Raio de Cobertura 1000 m
Frequência 3,5 GHz
Padrão IEEE 802.16e
Modulação OFDM
Escalonador Round Robin
Resolução do Video (pixel) Largura de banda na BS
(Mbits)
Taxa de dados requerida
(Mbits)
Baixa (176 x 144) 5,4 7,5
Media (352 x 288) 5,4 9,5
Alta (1280 x 720) 15 18,5
Tempo de cada Simulação por Video (pixel) Tempo (s)
Baixa (176 x 144) 40
Media (352 x 288) 35
Alta (1280 x 720) 40
Número de simulações para cada vídeo no cenário 20
42
Tabela 4 – Parâmetros de QoS configurados
CoS Tráfego utilizado Prioridade de
Tráfego
Taxa de Tráfego Máximo
Sustentado - Mbps
Taxa de Tráfego
Mínimo Reservado
- Mbps
rtPS
Vídeo (Highway)
VBR 5 1,5 1
Vídeo (Paris) VBR 5 3,5 3
Vídeo (Big B.
Bunny) VBR 5 12,5 10
UGS CBR 5 1,5 1
BE CBR 1 1.5 1
Fonte: Própria autoria.
A topologia utilizada para as avaliações e análises nas simulações está
representada na Figura 9. Para todas as simulações utilizamos a topologia Ponto-
Multiponto (PMP), numa infraestrutura composta por um Servidor (Sink Node), por uma
Estação Base (BS) com suporte à tecnologia WiMAX, e de cinco estações assinantes
(SS’s) com interface 802.16e. Os tráfegos foram organizados em dois sentidos, downlink
e uplink, para cada simulação, utilizando três diferentes resoluções de vídeo, baixa
(176x144 pixels), média (352x288 pixels) e alta (1280x720 pixels), totalizando 6
diferentes configurações para às simulações. Os vídeos estão representados na Figura 9
da esquerda para a direita em nível de resolução da mais baixa para mais alta.
Figura 15 – Cenário e topologia de Rede das simulações
Fonte: Própria autoria.
43
O cenário possuí apenas uma cobertura WiMAX, distribuída pela BS, e assim
todas as cinco SS’s estão dentro do alcance desta tecnologia de acesso sem fio. Para este
cenário, configuramos duas estações assinantes para trafegarem utilizando tipos de dados
que se encaixariam na classe de serviço BE, outras duas estações assinantes trafegarem
utilizando tipos de dados que se encaixariam na classe de serviço UGS, e por fim nosso
principal foco, uma última estação assinante trafegando tipos de dados que se encaixariam
na classificação de serviço como rtPS, no caso conteúdos multimídia de vídeos, que
exigem um alto desempenho da rede e um alto padrão de qualidade pelo usuário final.
Foram adotados três vídeos: “Highway”, “Paris” e “Big Buck Bunny”. O vídeo
“Highway” apresenta uma rodovia sendo percorrida, no vídeo “Paris” é apresentado um
diálogo entre duas pessoas, e por fim no vídeo “Big Buck Bunny” é apresentado uma
animação gráfica. Os vídeos possuem graus de complexidade diferenciados, que segundo
(Moles, 1973) está relacionado a quantidade de informação que são alteradas de uma
imagem para outra, através da dialética original e banal, aplicando este conceito aos
vídeos, adotando cada imagem como um quadro do vídeo, a diferença da quantidade de
informação de um quadro para seu posterior, determina o grau de complexidade. Desta
maneira, os vídeos são classificados de maneira crescente pelo grau de complexidade na
seguida ordem: “Highway”, “Paris” e “Big Buck Bunny”.
Este cenário foi configurado através de scripts TCL e executado 20 vezes para
produzir o resultado de cada simulação. Os scripts estão listados nos Apêndices A e B,
para tráfegos de uplink e downlink respectivamente.
6.2 Análises das Simulações
As simulações foram realizadas utilizando-se o mesmo cenário, mudando apenas
a resolução e o nível de complexidade dos vídeos trafegados. No cenário proposto, a
concorrência pela largura de banda foi maior do que largura de banda disponível para
atender a demanda, desse modo, o que se esperava é que o framework de QoS avaliado
entrasse em ação mapeando cada tipo de tráfego para suas devidas classes de serviços,
escalonando-os para priorizar o tráfego corretamente. Em cada simulação, foram
utilizados os tráfegos de background6 referentes às CoS UGS e BE para competir por
6 O tráfego de background ou melhor esforço é um tráfego de fundo com baixa prioridade. Ex.: Um
download usando FTP, um envio de e-mail ou navegação na web.
44
prioridades de acesso ao meio e largura de banda com o tráfico que deveria receber maior
prioridade, no caso do cenário proposto, o tráfego de vídeo, que não deveria ser afetado
por limitações de banda ou falha no escalonamento de prioridades de acesso aos recursos
da BS, mesmo com outros tráfegos concorrendo por estes recursos.
As simulações foram realizadas utilizando três vídeos: “Highway”, “Paris” e “Big
Buck Bunny”, disponíveis no formato YUV (Y é a luminância, U (R-Y) é o sinal R (red)
vermelho e Y somados, V(B-Y) é o sinal de B(blue) azul e Y). Eles estão disponíveis na
Biblioteca de Vídeos da Universidade do Estado do Arizona - EUA (ASU – Arizona State
University) (Yuv, 2013). O vídeo “Highway” foi o primeiro utilizado nas simulações,
possui baixa resolução e um nível complexidade pequeno, com 1200 quadros, dimensão
de 176x144 pixels com uma taxa de apresentação de 30 quadros por segundo. O segundo
vídeo, “Paris”, possui resolução média e um nível de complexidade mediano, com 1064
quadros, dimensão de 352x288 pixels com uma taxa de apresentação de 30 quadros por
segundo. Por fim, o terceiro vídeo “Big Buck Bunny” foi utilizando em alta definição e
possui um alto nível de complexidade, com 960 quadros, dimensão de 1280x720 pixels
com uma taxa de apresentação de 24 quadros por segundo. A amostragem de todos os
vídeos é 4:2:0, e todos foram comprimidos através de um codec MPEG-4. Na Tabela 5
apresentamos os parâmetros e detalhes de cada vídeo utilizado.
Tabela 5 – Parâmetros dos vídeos utilizados
Vídeos Avaliados
Vídeo Highway Paris Big Buck Bunny
Quadro 1200 1064 960
Amostragem 4:2:0 4:2:0 4:2:0
Resolução (Pixels) 176 x 144 352 x 288 1280 x 720
Compressão MPEG-4 MPEG-4 MPEG-4
Taxa 30 30 24
Tamanho de pacotes (bytes) 1052 1052 1052
Fragmentação máxima de pacotes (bytes) 1024 1024 1024
Formato YUV YUV YUV
Fonte: Própria autoria.
45
Nas simulações realizadas, o objetivo inicial foi avaliar a qualidade do vídeo
percebida pelo usuário, utilizando métricas objetivas de QoE, porém foi necessário
analisar também a confiabilidade do módulo através das métricas de QoS, e para isso
foram mensurados alguns valores de que QoS, tanto no sentido uplink quanto no sentido
downlink. A análise de QoS é necessária para a avaliação, pois permite comparar a
qualidade do ponto de vista da rede com a percebida pelo usuário. Nas Figuras de 10 à
13 as legendas “Situação 1”, “Situação 2” e “Situação 3” correspondem às simulações
onde os tráfegos de background concorrem com o vídeo “Highway” na Situação 1, com
o vídeo “Paris” na Situação 2 e com o vídeo “Big Buck Bunny” na Situação 3. A Figura
10 e a Figura 11 apresentam os níveis de vazão7 dos vídeos nos sentidos uplink e downlink
respectivamente.
Figura 16 – Vazão média para todas as CoS em simulações de tráfegos uplink.
Fonte: Própria autoria.
7 Vazão em um ambiente de redes de computadores é uma determinada quantidade de bits que passa por
um link entre um nodo emissor e um receptor, por uma unidade de tempo.
46
Figura 17 - Vazão média para todas as CoS em simulações de tráfego downlink.
Fonte: Própria autoria.
Os vídeos “Big Buck Bunny”, “Paris” e “Highway” conseguiram atingir uma
média de 9,06, 2,4 e 0,75 Mbps respectivamente em ambos os sentidos de tráfegos. Esses
valores estão dentro dos limites configurados na Tabela 4 o que comprova que o módulo
de QoS avaliado respeitou as configurações de taxa mínima reservada e máxima
sustentada solicitadas para todos os fluxos de vídeos mapeados para a CoS rtPS, conforme
descrito nesta tabela.
Para à CoS UGS os resultados foram semelhante à CoS rtPS, onde a taxa média
aproximada de 1,33 Mbps para as simulações no sentido downlink e 1,27 Mbps para as
simulações de uplink estão dentro dos limites estabelecidos para esses fluxos, conforme
mostrado anteriormente na Tabela 4. Os fluxos da CoS BE não foram admitidos no
sentido downlink por isso a Figura 11 exibe vazão zero, já no sentido uplink estes tráfegos
foram admitidos porém enviaram dados esporadicamente. Esse comportamento é
justificado, pois a classe BE tem menor prioridade de acesso que a UGS e rtPS e portanto
o módulo de QoS alocou recursos de acordo com os requisitos exigidos para cada CoS e
aplicou as devidas prioridades nos tráfegos.
A diferença de tempo entre o instante em que o transmissor envia um pacote de
dados e o instante que o receptor recebe este pacote é definido como atraso, e seu
comportamento é em função da carga na rede. Abaixo estão ilustrados os gráficos com a
47
média do atraso dos pacotes, no sentido uplink apresentado pela Figura 12, e no sentido
downlink pela Figura 13.
Figura 18 – Atraso médio de pacotes para todas as CoS em simulações uplink.
Fonte: Própria autoria.
Figura 19 – Atraso médio de pacotes para todas as CoS em simulações downlink.
Fonte: Própria autoria.
Como os tráfegos classificadas com a CoS BE não obtiveram vazão no sentido
downlink nas simulações, também não apresentaram atraso neste mesmo sentido.
48
No sentido uplink onde ocorreu vazão da CoS BE, esse tráfego apresentou os
maiores níveis de atraso que as demais classes, destaque para as simulações com o vídeo
Paris com níveis de 410 ms (milissegundos) de atraso. Esse comportamento ocorre, pois
o BE é o tipo de fluxo com menor prioridade e, portanto não tem garantia nenhuma de
serviços sendo que seus pacotes serão sempre escalonados para a fila de menor prioridade.
No gráfico de atraso uplink o tráfego UGS teve um atraso máximo de 6 ms, o
menor dentre todos em todas as simulações, o que comprova que o módulo aplicou as
configurações corretas para este tipo de fluxo, visto que o mesmo deve receber concessões
periódicas de transmissão e sua largura de banda fixa deve ser negociada no início da
criação do fluxo de serviço para garantir que o atraso de seus pacotes seja minimizado.
Os fluxos de vídeos tiveram um atraso tolerável, pois eles podem tolerar até 300
milissegundos segundo a recomendação G.114 do ITU-T (ITU-T, 2011) e portanto o
atraso médio máximo 52 milissegundos no sentido uplink para o vídeo em resolução HD
está dentro dos limites aceitáveis.
Os parâmetros acima medidos indicam apenas métricas de QoS, onde podemos
inferir que ocorreu uma diferenciação de prioridades e alocações de recursos para
diferentes tipos de classes de serviços, porém o principal objeto desta proposta é avaliar
se a QoS deste módulo realmente apresenta níveis adequados para prover a garantia de
qualidade das mídias trafegadas na rede, por isso o objetivo da avaliação do vídeo é
validar a eficácia do mapeamento de QoS proposto pela rede WiMAX, do ponto de vista
do usuário e desta maneira, utilizando algumas métricas objetivas de QoE.
O cenário para a avaliação dos vídeos foi apresentado na Figura 9, onde o vídeo
recebido pelo usuário com perspectiva de garantia de QoS foi avaliado numa rede
WiMAX. A primeira métrica de QoE avaliada foi a PSNR. Os vídeos obtiveram a média
PSNR para tráfego uplink igual a 33,09 dB para o vídeo “Highway”, 33,23 dB para o
vídeo “Paris”, e 33,35 dB para o vídeo “Big Buck Bunny”. Este último vídeo apresentou
um maior nível de PSNR por ter menor diferença entre os quadros enviados e os recebidos
o que resultou em um vídeo entregue com maior proximidade à qualidade original.
Usando a Tabela 2 de mapeamento de valores PSNR para MOS, todos os vídeos são
49
qualificados como BOM. Na Figura 14 podemos visualizar os níveis do PSNR nos
respectivos frames8.
Figura 20 – PSNR dos vídeos para tráfego uplink.
Fonte: Própria autoria.
A média PSNR para tráfego downlink foi igual a 33,07 dB para o vídeo
“Highway”, de 33,19 dB para o vídeo “Paris”, e de 33,34 dB para o vídeo “Big Buck
Bunny”, o que segundo a Tabela 2 significa que todos os vídeos também se qualificam
como BOM. Na Figura 15 podemos visualizar os níveis do PSNR nos respectivos frames
para o sentido downlink.
8 Frame (em Português: quadro ou moldura) é cada um dos quadros ou imagens fixas de um produto
audiovisual (Aumont, 2001).
50
Figura 21 – PSNR dos vídeos para tráfego downlink.
Fonte: Própria autoria.
Figura 22 – VQM dos vídeos para tráfego uplink.
Fonte: Própria autoria.
51
A segunda métrica de QoE avaliada foi a VQM em ambos os sentidos downlink e
uplink. Os resultados são exibidos nas Figuras 16 e 17, respectivamente.
Figura 23 – VQM dos vídeos para tráfego downlink.
Fonte: Própria autoria.
Os vídeos obtiveram a média VQM para tráfego uplink igual a 1,99 para o vídeo
“Highway”, de 2,82 para o vídeo “Paris”, e de 4,66 para o vídeo “Big Buck Bunny”.
Para tráfegos downlink, os vídeos obtiveram a média VQM igual a 1,98 para o
vídeo “Highway”, de 2,76 para o vídeo “Paris”, e de 4,64 para o vídeo “Big Buck Bunny”.
Em ambos os sentidos os resultados foram satisfatórios, já que na métrica VQM
quanto mais próximo do valor 0 melhor é qualificado o vídeo, podendo ser melhorado
algo na transmissões para vídeos em alta definição, onde obtivemos a menor taxa na
qualidade.
Por fim, a terceira e última métrica de QoE avaliada no tráfego dos vídeos foi a
SSIM. Os vídeos obtiveram a média SSIM para tráfego uplink igual a 0,91 para o vídeo
“Highway”, 0,94 para o vídeo “Paris”, e 0,91 para o vídeo “Big Buck Bunny”, conforme
a Figura18, com os níveis do SSIM por frames.
Para tráfegos downlink, os vídeos obtiveram a média SSIM igual a 0,91 para o
vídeo “Highway”, de 0,94 para o vídeo “Paris”, e de 0,91 para o vídeo “Big Buck Bunny”,
conforme demostrado na Figura 19, com os níveis do SSIM por frames.
52
Figura 24 – SSIM dos vídeos para tráfego uplink.
Fonte: Própria autoria.
Figura 25 – SSIM dos vídeos para tráfego downlink
Fonte: Própria autoria.
Em ambos os sentidos, os resultados obtidos corresponderam a mais de 90% de
qualidade em todos os vídeos recebidos, pois segundo a métrica quanto mais próximo o
valor do SSIM for de 1, melhor será a qualidade do vídeo.
Para fim de comparação visual apresentamos o Quadro 4 com o frame de número
600 de cada vídeo analisado.
53
Quadro 4 - Comparativo do frame 600 do vídeo antes e após a simulação.
Highway Original Paris Original Big Buck Bunny Original
Resultado no sentido downlink
Resultado no sentido uplink
Fonte: Própria autoria.
Na comparação entre o frame 600 do vídeo original comparada ao vídeo recebido,
principalmente no vídeo Big Buck Bunny, percebe-se uma leve mudança no brilho da
imagem, no entanto isto não afetaria a experiência do usuário, pois a taxa de amostragem
dos vídeos está entre 24 e 30 frames por segundo e uma pequena distorção em um frame
pode ser imperceptível para o usuário.
Após a leitura e análise dos resultados apresentados, relacionados as métrica de
QoE (PSNR, SSIM e VQM), pode-se concluir que o módulo garante a qualidade mínima
necessária para vídeos com diferentes graus de complexidade e diferentes resoluções, pois
todos os vídeo são classificados como BOM. Além do que, percebeu-se que o grau de
complexidade afeta diretamente a qualidade final do vídeo, o que foi demostrado nos
gráficos, onde houve diferenciação nos resultados das métricas para o vídeo de alta
qualidade comparada aos demais.
Para os vídeos de baixa e média resolução, ocorreu uma estabilidade nos
resultados das métricas de QoE, pois estes não exigiram muito da rede, e não possuíam
54
muitos detalhes no seu conteúdo, o que poderia acarretar em distorções e percas de
qualidade.
Mesmo o framework garantindo a qualidade mínima dos vídeos, notou-se que para
vídeos de alta definição (“Big Buck Bunny”) apresentou-se altos picos de distorção nas
métricas de QoE baseadas nos frames, e isto se deve pelo fato das métricas de QoE
utilizadas neste trabalho avaliarem a qualidade do vídeo efetuando uma comparação entre
o frame original do vídeo com o frame do vídeo trafegado na rede. O vídeo de alta
definição exige mais requisitos da rede como taxa mínima de atraso e uma vazão mínima
garantida para serem trafegados, pois possuem tamanhos e complexidade diferentes do
que os vídeos de menores qualidades.
Nas avaliações de QoE do vídeo “Big Buck Bunny”, ocorreu uma pequena perca
de pacotes no início do tráfego, o que ocasionou a perca de um frame do vídeo recebido,
que gerou um deslocamentos de frames no vídeo. Como a perca foi de apenas um frame,
aos olhos do usuário final, isso se tornou imperceptível, mas como as métricas de QoE
comparam frames por frames, as diferenciações de cores, luminosidade, brilho,
quantidade de pixels, e demais variáveis são apontadas nos gráficos dos resultados. A
Figura 20 ilusta a diferenciação do frame de número 888 enviado para o frame
correspondente recebido.
Figura 26 – Diferenciação do Frame 888: Enviado X Recebido
Fonte: Própria autoria.
O módulo de QoS para as redes WiMAX apresentou um comportamento aceitável
para a qualidade de tráfego multimídia trafegados na redes, avaliados através de métricas
de QoE, porém este, não garantiu essa qualidade a nível de excelência, e deixou a desejar
quanto aos vídeos de alta definições com um grau maior de complexidade. Como
55
recomendação, as normas da IEEE para esse framework de QoS, poderiam adotar novas
estratégias de escalonamento e algoritmos que garantam a qualidade para todos os tipos
de vídeos, em especial para os vídeos de alta definição, pois é o tráfego que apresenta
maior crescimento para a internet do futuro e segundo as estatísticas, se tornará uns dos
principais recursos requisitados nos próximos anos.
6.3 Resumo do Capítulo
Este capítulo tratou do principal objetivo desta proposta, realizar uma análise de
confiabilidade do módulo de QoS para redes WiMAX em vídeos com diferentes graus de
compleixidade. Diversos resultados foram avaliados e as análises e conclusões sobre a
qualidade dos vídeos foram apresentadas.
No próximo capítulo iremos apresentar as conclusões e considerações finais deste
projeto, abordando nosso ponto de vista em relação aos resultados e considerações para
trabalhos futuros.
56
7. CONCLUSÃO
Este trabalho realizou uma análise de confiabilidade de garantia de QoS, proposto
por um framework que implementa CoS para tecnologia WiMAX, mensurando dados
multimídias trafegados por essa rede através de métricas de QoE e QoS. A escolha da
tecnologia sem fio que obedece ao padrão IEEE 802.16e, denominada também como
WiMAX, possui em seu escopo um framework de QoS por padrão em sua camada de
enlace (MAC), que garante a implementação de CoS para escalonamento e uma melhor
distribuição de recursos.
Foi utilizado o simulador de redes ns-2, um dos mais difundidos no meio
acadêmico, em conjunto com um módulo desenvolvido para possibilitarmos simular uma
arquitetura WiMAX com implementação de três CoS’s dentro do simulador.
Foi efetuado testes e simulações com coletas de dados, tendo como foco o tráfego
multimídia do tipo vídeo, com três complexidades visuais diferentes, avaliando o vídeo
após o tráfego pela rede, utilizando métricas de QoE para constatar se a garantia de
qualidade é respeitada.
Conforme os resultados de várias simulações, concluímos que o framework de
QoS na arquitetura WiMAX pode manter a mínima qualidade dos dados para diferentes
tipos de tráfegos multimídia na rede. Em todos os resultados as avaliações de QoE
obtiveram notas médias classificadas como BOM e EXCELENTE, o que garante a
confiabilidade do módulo de QoS avaliado. Nossa proposta permitiu adicionarmos
diferentes tipos de tráfegos com diferentes demanda de recursos da rede, e avaliar com
métricas de qualidade de experiência, os dados recebidos após o tráfego, que de acordo
com seus parâmetros de QoS configurados, tiveram seus requisitos de QoS e QoE
satisfeitos, mesmo em situações que os recursos de banda da rede estavam esgotados.
Contudo, concluímos que para tráfegos multimídia com vídeos em alta definição,
poderia ser adotadas novas estratégias de escalonamento e algoritmos que garantam a
qualidade para esse tipo de conteúdo, com o foco na qualidade final para o usuário.
A principal contribuição deste trabalho é fornecer à comunidade científica uma
documentação de referência e recomendação para pesquisadores e projetistas da área de
redes e telecomunicações, de modo permitir uma avaliação técnica do grau de
confiabilidade de implementação do módulo de QoS no ns-2 para tecnologia WiMAX,
módulo de autoria de Aymen (Belghith, Nuaymi, 2008).
57
Durante o desenvolvimento da proposta deste projeto, ocorreram dificuldades pela
dupla no aprendizado e domínio do simulador de redes ns-2, que possui uma curva de
aprendizagem muita baixa, as configurações de scripts TCL foram uma tarefa bastante
onerosa. Tivemos algumas dificuldades também na implementação e configuração do
módulo do WiMAX para este simulador, adaptando alguns scripts para se adequarem ao
cenário utilizado.
Para trabalhos futuros, propõem-se utilizar um módulo para o simulador ns-2 com
suporte a todas as cinco classes de serviços que o framework de QoS do WiMAX suporta,
testando o comportamento para todos os tipos de tráfegos, simulando em uma rede
heterogênea (WiMAX e LTE) como diversas demandas de tráfego, o que exigiria mais
da rede e das garantias de QoS, avaliando esses dados e resultados com métricas de QoE
objetivas e subjetivas, como por exemplo a métrica MOS. Seria interessante avaliar a
garantia de QoS através de métricas QoE em uma arquitetura composta por redes
heterogênias como WiMAX e LTE em um cenário com suporte a handover transparente
entre estas tecnologias.
58
8. REFERÊNCIAS BIBLIOGRÁFICAS
Andreadis, Alessandro. RIZZUTO, Sandro. ZAMBON, Riccardo. “A New NS2 Tool to
Investigate QoS Management over Mobile WiMAX”. SIMUTools 2011. Fevereiro,
2011.
Andrews, Jeffrey G. GHOSH, Arunabha. MUHAMED, Rias. “Fundamentals of WiMAX
– Understanding Broadband Wireless Networking”. Editora Prentice Hall. 2007.
Avelar, Edson Adriano M.; Marques, Lorena Lima; Bemerguy, Thiago; DIAS, Kelvin
Lopes. "Avaliando o protocolo PMIPv6 quanto ao Suporte à Qualidade de
Experiência para Tráfego de Vídeo em um Testbed 802.11". CNPq, processos
475814/2008-8 e 309142/2008-3, 2008.
Ahson, S., Ilyas, M. “WiMAX : standards and security” / Syed Ahson and Mohammad
Ilyas. Includes bibliographical references and index. ISBN 978-1-4200-4523-9
(alk. paper) 1. Wireless communication systems. 2. Broadband communication
systems. 3. IEEE 802.16 (Standard) I. Ilyas, Mohammad, 1953- II. Title.
TK5103.2.A432. 2008
Begazo, Dante Coaquira. "Avaliação objetiva e subjetiva de qualidade de vídeo via rede
IP com variação de atraso". Escola Politécnica da Universidade de São Paulo,
Dissertação de Mestrado. São Paulo - SP, 2012. Disponível em:
<http://www.teses.usp.br/teses/disponiveis/3/3142/tde-16072013-122005/pt-
br.php>. Acesso em: Dezembro de 2013.
Belghith, A. Nuaymi, L. “Design and Implementation of a QoS-included WiMAX
Module for NS-2 Simulator”. SIMUTools, 2008. Disponível em:
<http://perso.telecom-bretagne.eu/aymenbelghith/tools/>. Acesso em: Julho de
2013.
Cisco, System Inc. “Cisco Visual Networking Index: Forecast and Methodology, 2011–
2016” Disponível em: <http://www.itu.int/md/dologin_md.asp?lang=en&id=S12-
WTPF13IEG2-INF-0002!!PDF-E>. Acesso em: Outubro de 2013.
Claro, Fernanda Del. “O avanço tecnológico no mundo econômico”. FAE Centro
Universitário. Vitrine da Conjuntura, Curitiba, v.2, n.8, Outubro, 2009. Disponível
em: <www.fae.edu/galeria/getImage/1/731424487250267.pdf>. Acesso em: Julho
de 2013.
Chen, Tao. “QoS Support in Packet Networks (presentation)”. University of Trento, Italy.
May, 2004. Disponível em: <http://science.unitn.it/~tomasi/think/pdf/chp.ppt>.
Acesso em: Setembro de 2004.
59
Corrêa, U., Pinto, A., Codas, A., Ferreira, D., Montez, C. “Redes Locais Sem Fio:
Conceito e Aplicações”. Departamento de Automação e Sistemas – Programa de
Pós-Graduação em Engenharia Elétrica Universidade Federal de Santa Catarina
(UFSC).Campus Universitário – Trindade 88040-900 – Florianópolis – SC –Brasil.
Cygwin. “Get that Linux feeling - on Windows”. Disponível em: <
http://www.cygwin.com/>. Acesso em: Outubro de 2013.
Daronco, F.C. Avaliação Subjetiva de Qualidade Aplicada à Codificação de Vídeo
Escalável. 2009. 146 f. Dissertação (Mestrado em Ciências da Computação).
Programa de Pós-graduação em Computação, Universidade Federal do Rio Grande
do Sul, Porto Alegre. 2009.
Delicato, Flávia C.; Pirmez , Luci; Cesar, Jaime Jr; Vianna , Nilson; Souza, Aline
Macedo de; Oliveira, Ana Liz S. “Redes WiMAX: Arquitetura, Protocolos,
Segurança e QoS”. 26º SimpósioLuciana dos Santos Lima, Luiz Fernando Gomes
Soares, Markus Endler Brasileiro de Redes de Computadores e Sistemas
Distribuídos. 2008.
Drakos, Nikos. Moore Ross. “Moving Pictures Quality Metric (MPQM)”. Computer
Based Learning Unit, University of Leeds. Mathematics Department, Macquarie
University, Sydney. 1996. Disponível em:
<http://www.irisa.fr/armor/lesmembres/Mohamed/Thesis/node105.html>. Acesso
em: Maio de 2013.
Eklund, Carl; Marks, Roger B.; Stanwood, Kenneth L; Wang, Stanley. IEEE Standard
802.16: A Technical Overview of the WirelessMAN™ Air Interface for Broadband
Wireless Access. IEEE C802.16.02/05. June 04, 2002. Disponível em
<http://www.ieee802.org/16/docs/02/C80216-02_05.pdf>. Acesso em: Julho 2013.
ETSI STQ. European Technical Committe for Speech, Transmission, Planning, and
Quality of Service. Disponível em: <http://portal.eetsi.org/>. Acesso em: Abril de
2013.
EvalVid. “A Video Quality Evaluation Tool-set”. Disponível em: < http://www2.tkn.tu-
berlin.de/research/evalvid/>. Acesso em: Outubro de 2013.
Fagundes, Eduardo Mayer. “WiMAX”. 2005. Disponível em:
<http://www.efagundes.com/artigos/Arquivos_pdf/WiMAX.pdf>. Acesso em:
Julho de 2013.
Fayad, M. E.; Schmidt, D. C. “Object-oriented Application frameworks”.
Communications of the ACM, Vol. 40, 10 p., 1997.
Ferreira, José Jailton Henrique Júnior. “Handover Transparente para Tráfego Multimídia
em uma Arquitetura Integrada WiMAX/MIP/MPLS Móvel”. Universidade Federal
do Pará. Webmedia, 2009.
60
Ferreira, Gildevane Aparecido. “Avaliação de Transmissão de Fluxo Contínuo de Vídeo
em Redes IP sem fio – Padrão IEEE 802.11b e 802.11g”. Dissertação (Mestrado) -
Curso de Pós-graduação em Gestão e Gerenciamento de Redes de
Telecomunicações. PUC - Campinas, 2008.
Ferrus, R.; Gelonch, A.; Casadevall, F.; ReveS, X.; Nafisi, N. “EVEREST testbed: QoS
management evaluation in B3G networks”. 2nd International Conference on
Testbeds and Research Infrastructures for the Development of Networks and
Communities. 2006.
Figueiredo, Fabrício Lira. Fundamentos da Tecnologia WIMAX. Centro de Pesquisa e
Desenvolvimento em Telecomunicações - 2008. Disponível em:
<http://www2.cpqd.com.br/file.upload/sas1437_tecnologia_wimax_port_v02.pdf
>. Acesso em: Abril de 2012.
GNU, Operating System. “GNU General Public License”. Junho, 2007. Disponível em:
<http://www.gnu.org/copyleft/gpl.html>. Acesso em: Outubro 2013.
Gnuplot. “Official gnuplot documentation”. Setembro, 2010. Disponível em: <
http://www.gnuplot.info/documentation.html>. Acesso em: Outubro de 2013.
IEEE - Institute of Electrical and Electronics Engineers. “IEEE standard for local and
metropolitan area networks”. Disponível em:
<http://standards.ieee.org/getieee802/download/802.16e-2005.pdf>. Acesso em:
Abril de 2013.
IEEE. Institute of Electrical and Electronics Engineers. “IEEE Standard for Local and
Metropolitan Area Networks – Part 16: Air Interface for Fixed Broadband Wireless
Access Systems, Amendment 2: Physical and Medium Access Control Layers for
Combined Fixed and Mobile Operation in Licensed Bands, Corrigendum 1”, Std
802.16e TM -2006. Fev. 2006.
IEEE. Institute of Electrical and Electronics Engineers. “IEEE standard for local and
metropolitan area networks Part 16: Air interface for fixed and mobile broadband
wireless access systems (amendment and corrigendum to IEEE Std 802.16-2004)”,
Std 802.16eTM-2005.Disponível em:
<http://standards.ieee.org/getieee802/download/802.16e-2005.pdf>. Acesso em:
Julho de 2013.
IEEE Std 802.16.2-2001. IEEE Recommended Practice for Local and metropolitan area
networks. Coexistence of Fixed Broadband Wireless Access Systems. September
10, 2001. Disponível em:
<http://ieeexplore.ieee.org/servlet/opac?punumber=8755>. Acesso em: Julho
2013.
Ilyas, Mohamed. AHSON, Syed. “WiMAX – Applications”. Editora CRC Press. 2008.
61
ITU-R. Recommendation BT.500-11, “Methodology for the Subjective Assessment of
the Quality of Television Pictures”, Technical Report, 2002.
ITU-R. Recommendation P.800-1, “Series P: Telephone transmission quality, telephone
installations, local line networks”, Technical Report, 1998.
ITU. Recommendation ITU-R BT.500: Methodology for the Subjective Assessment of
the Quality of Television Pictures, 2000. Disponível em:
<http://www.dii.unisi.it/~menegaz/DoctoralSchool2004/papers/ITU-R_BT.500-
11.pdf/>. Acesso em: Abril de 2013.
ITU. Recommendation ITU-T P.900: Subjective Video Quality Assessment Methods for
Multimedia Application, 2008. Disponível em: <http://www.itu.int/rec/T-REC-
P.910- 200804-I />. Acesso em: Abril de 2013.
ITU-T. “Recommendation ITU-T G.114: One-way transmission time”. 2011. Disponível
em: <http://www.itu.int/rec/T-REC-G.114/>. Acesso em: Outubro de 2013.
Jain, R. “Quality of experience”. IEEE Multimidia. Volume 11, p. 90 – 98. 2004.
Klaue, Jirka; Rathke, Berthold; Wolisz, Adam. “EvalVid - A Framework for Video
Transmission and Quality Evaluation”. Proc. of the 13th International Conference
on Modelling Techniques ad Tools for Computer Performance Evaluation, Urbana,
Illinois, USA. Setembro, 2003. Disponível em: < http://www.tkn.tu-
berlin.de/fileadmin/fg112/Hard_Software_Components/Software/evalvid.pdf>.
Acesso em: Outubro de 2013.
Lima, Luciana dos Santos; SOARES, Luiz Fernando Gomes; ENDLER, Markus.
“WiMAX: Padrão IEEE 802.16 para Banda Larga Sem Fio”. Departamento de
Informática - Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio).
Setembro,2004.
Lopes, M. C., “Transmissão de vídeo em redes sem fio padrão IEEE 802.11b”.
Monografia de Mestrado Profissional. Instituto de Computação, Unicamp, 2006.
LRC. Computer Networks Laboratory. “WiMAX module for the ns-2 simulator”.
UNICAMP, 2008. Disponível em: <http://www.lrc.ic.unicamp.br/wimax_ns2/>.
Acesso em: Outubro de 2013
Lu, L.,WANG, Z.,BOVIK, A. “Video Quality Assessment based on Structural Distortion
Measurement”. Signal Processing: Image Communication, special issue on
“Objective Video Quality Metrics, vol. 19,p. 121-132. Fevereiro, 2004.
Mallowski, M., Claben, D. “Performance of Video Telephony Services in UMTS using
Live Measurements and Network Emulation” Wireless Personal Communications:
An International Journal. Volume 47. p. 19-32. ISSN: 0929-6212. 2008.
62
Másson, E.; Wang, Y. Introduction to Computation and Learning in Artificial Neural
Networks.European Journal of Operational Research, North-Holand, v. 47, p. 1–
28, 1990.
MOLES, Abraham. "Teoria da complexidade e civilização industrial. In: MOLES,
Abraham et al. Civilização industrial e cultura de massas. Trad. Maria Cecília Baeta
Neves. Petrópolis:Vozes, 1973.
MSU. “MSU Video Quality Measurement Tool”. Disponível em:
<http://compression.ru/video/quality_measure/video_measurement_tool_en.html>
Acesso em: Outubro de 2013.
Nam. “Nam: Network Animator”. LBL. Julho, 2002. Disponível em:
<http://www.isi.edu/nsnam/nam/index.html>. Acesso em: Outubro de 2013.
Neves, Pedro; Sargento, Susana; Fontes, Francisco; Bohnert, Thomas M.; Monteiro, João.
“Quality of Service Differentiation in WiMAX Networks”. University of Aveiro /
Institute of Telecommunications. March 2010. Disponível em:
<http://cdn.intechopen.com/pdfs/9694/InTech-
Quality_of_service_differentiation_in_wimax_networks.pdf>. Acesso em: Julho
de 2013.
Niranjan et al. “Image Quality Assessment Based on a Degradation Model,” IEEE
Transaction on Image Processing, Vol. 9, abril 2000.
Nist. "National Institute of Standards and Technology Draft Definition of Cloud
Computing". Disponível em: <http://csrc.nist.gov/groups/SNS/cloud-computing>.
Acesso em: Julho de 2013.
NS. “The Network Simulator – ns - 2”. 2011. Disponível em: <
http://nsnam.isi.edu/nsnam/index.php/User_Information>. Acesso em: de 2013.
Nuaymi, Loutfi. “WiMAX - Technology for Broadband Wireless Access”. Editora John
Wiley & Sons. 2007.
Nunes, Mário Serafim. “Quality of Service of Video Streaming”. Instituto Superior
Técnico – IST. Outubro, 2011. Disponível em: <http://comp.ist.utl.pt/pdeec-
qs/bibliografia/50-QoS%20Video%20streaming.pdf>. Acesso em: Outubro de
2013.
Oliveira, Rosinei de Souza. “Predição de Qualidade de experiência em Redes WiMAX
em Aplicações de Vídeo baseada em Aspectos de Qualidade de Serviço”.
Universidade Federal do Pará. Webmedia, 2011.
Pan, Jianli. “A Survey of Network Simulation Tools: Current Status and Future
Developments”. Novembro, 2008. Disponível em:
<http://www.cs.wustl.edu/~jain/cse567-08/ftp/simtools.pdf>. Acesso em:
Novembro de 2013.
63
Peli, Eli. “The Contrast Sensitivity Function (CSF) and Image Discrimination”. Schepens
Eye Research Institute, Harvard Medical School, Boston. 1999. Disponível em:
<http://www.theschepens.org/faculty/peli/papers/contrast/contrast.pdf>. Acesso
em: Maio de 2013.
Pereira, Mateus Casanova. “Análise de Desempenho em Redes Wireless Ad-Hoc e
Estabelecimento de um Acordo de Nível de Serviço Pró-Ativo”. UFSC -
Universidade Federal de Santa Catarina, Florianópolis, Março de 2004.
PEVQ. Perceptual Evaluation of Video Quality. Disponível em <http://www.pevq.org/>.
Acesso em: Abril de 2013.
REIGOTA, Nilvana dos Santos. “Comparação da transformada Wavelet discreta e da
transformada do Cosseno, para compressão de imagens de impressão digital”.
Dissertação (Mestrado) Escola de Engenharia de São Carlos Universidade de São
Carlos, 2006. Disponível em: <
http://www.teses.usp.br/teses/disponiveis/18/18152/tde-27042007-
101810/publico/Nilvana.pdf>. Acesso em: Outubro de 2013.
Revés, X., Nafisi, N., Ferrís, R. and Gelonch, A. (2006). “User perceived Quality
Evaluation in a B3G Network Testbed”, In Proc. of IST Mobile Summit, pages 1-
5, Mykonos.
Rodrigues, Carino Andrade. "Escalonamento de Trafego em Redes WiMAX no Modo
PMP". Dissertação de Mestrado em Engenharia Elétrica. Universidade de Brasilia.
Julho 2009. Disponivel em:
<http://repositorio.unb.br/bitstream/10482/3877/1/2009_CarinoAndradeRodrigues
.pdf>. Acesso em: Julho de 2013.
Sousa, B., Pentikousis, K., Curado, M. “Experimental Evaluation of Multimedia Services
in WiMAX”. In: MOBIMEDIA - International Mobile Multimedia
Communications Conference, Finlândia, 2008.
Souza et al. “Multimedia Transmission on Amazon Region using Wireless Broadband
Networks”. In: IEEE International Symposium on Broadband Multimedia Systems
and Broadcasting, 2009.
Takahashi, A., HANDS, D., BARRIAC, V. “Standardization activities in the ITU for a
QoE assessment of IPTV”. IEEE Communication Magazine. fev. 2008.
Ubuntu. “Ubuntu 9.04 (Jaunty Jackalope)”. Abril, 2009. Disponível em: <http://old-
releases.ubuntu.com/releases/9.04/>. Acesso em: Outubro de 2013.
Vaczelewski, G., Souza, C., Feltrin, R. “A Transformação nas Empresas a partir do
Avanço Tecnológico”. Curso de Administração da Universidade Luterana do
Brasil. 2011. Disponível em:
64
<http://guaiba.ulbra.br/seminario/eventos/2011/artigos/administracao/salao/772.p
df>. Acesso em: Outubro de 2013.
Valente, Warley Murici Junior. “Arcabouço para Aprovisionamento de QoS e QoE em
Redes Sem Fio Heterogêneas WiMAX/Wi-Fi com Garantia de Equidade entre
Vazões”. Universidade Federal do Pará. Webmedia. 2011.
Viscaíno, Jorge López. “WiMAX: IEEE 802.16”. Tampere Polytechnic,
Telecommunications Engineering. Junho, 2008.
Vishwanath et al. “Perspectives on Quality of Experience for Video Streaming over
WiMAX”. Mobile Computing and Communications Review, v. 13, 2009.
VQEG. Final report from the Video Quality Expert Group on the Validation of Objetive
Models of the Video Quality Assessment, 2000. Disponível em:
<http://www.vqeg.org/>. Acesso em: Abril de 2013.
Wimax Forum. “Mobile WiMAX Network Architecture and Specifications”. Documents
related to WiMAX in IMT-2000. Agosto, 2006. Disponível em: <
http://www.wimaxforum.org/technology/documents >. Acesso em: Junho de 2013.
Winkler, S. “Digital Video Quality: Vision Models and Metrics”. John Wiley & Sons,
Ltd. ISBN: 0-470-02404-6. 2005.
XGRAPH. “General Purpose 2-D Plotter”. Março, 2013. Disponível em:
<http://www.xgraph.org/#anch1>. Acesso em: Outubro de 2013.
Xiao, F. “DCT-based Video Quality Evaluation MSU Video Quality Metric”. Disponível
em: <http://compression.ru/video/quality_measure/vqm.pdf>. Acesso em:
Fevereiro de 2013.
YUV. “YUV Video Sequences”. Disponível em: <http://trace.eas.asu.edu/yuv/>. Acesso
em: Outubro de 2013.
65
APÊNDICE A – Scripts TCL de Cenário e agentes
configurados para rede WiMAX no sentido uplink:
# Cenário 1 - Uplink
# Author: Fernando A. Miranda
# Edney Almeida
#
#
# Server [0.0.0] Video (UDP) - send
# | UGS1 Send
# | UGS2 Send
# | BE1 Send
# | BE2 Send
# | SS_UGS1 | Sink (UDP) - Receive
# (Y) SS_UGS2 | Sink (UDP) - Receive
# BS [1.0.0] 802.16d SS_BE1
# SS_BE2
#
#
# SS_rtPS [1.0.1] 802.16d | Sink (UDP) - receive
if {$argc != 7} {
puts ""
puts "Oops ! o script requer 7 argumentos. Veja abaixo:"
puts "Uso: ns script.tcl modulation cyclic_prefix
rtPS_scheduler nomeDoArquivoDeVideo fbandwidt data-rate-nodos-
UGS1-em-Mbps nome-do-diretorio-de-saida"
puts ""
puts " MODULAÇÃO: OFDM_BPSK_1_2, OFDM_QPSK_1_2,
OFDM_QPSK_3_4"
puts " OFDM_16QAM_1_2, OFDM_16QAM_3_4,
OFDM_64QAM_2_3, OFDM_64QAM_3_4"
puts ""
puts " cyclic_prefix: 0.25, 0.125, 0.0625, 0.03125"
puts
puts " rtPS scheduler: RR, mSIR, WRR, TRS_RR, TRS_mSIR"
exit
}
# criando as variáveis globais
set dirSimulacao [lindex $argv 6]
set output_dir ./resultados;
file mkdir $output_dir/$dirSimulacao
set traffic_start 2
set tempo_fim_simulacao 0
66
set packetSize 1052
set max_fragmented_size 1024
set infoSim [open $output_dir/$dirSimulacao/infoSimulacao.txt w]
puts $infoSim "Simulacao: [lindex $argv 6]";
puts $infoSim "Modulacao: [lindex $argv 0]";
puts $infoSim "Prefixo ciclico: [lindex $argv 1]";
puts $infoSim "Escalonador: [lindex $argv 2]";
puts $infoSim "Vídeo: [lindex $argv 3]";
puts $infoSim "Largura do canal: [lindex $argv 4]";
puts $infoSim "Tempo de início: $traffic_start";
#set default_modulation OFDM_16QAM_3_4
# Configura Wimax
Mac/802_16 set debug_ 0
#define coverage area for base station:
Phy/WirelessPhy/OFDM set g_ [lindex $argv 1]; # define cycle
prefix [0.25, 0.125, 0.0625, 0.03125]
Phy/WirelessPhy set Pt_ 0.025
Phy/WirelessPhy set RXThresh_ 1.26562e-13;# 2.025e-12 = 500m
radius 1.26562e-13 = 1000m
Phy/WirelessPhy set CSThresh_ [expr 0.8*[Phy/WirelessPhy set
RXThresh_]]
# Parameter for wireless nodes
set opt(chan) Channel/WirelessChannel ;# tipo de
canal
set opt(prop) Propagation/TwoRayGround ;# modelo de
rádio propagação
set opt(netif) Phy/WirelessPhy/OFDM ;# network
interface type
set opt(mac) Mac/802_16 ;# MAC type
set opt(ifq) Queue/DropTail/PriQueue ;# tipo de
interface da fila
set opt(ll) LL ;# tipo da
camada de link
set opt(ant) Antenna/OmniAntenna ;# antenna
model
set opt(ifqlen) 1000 ;# quantidade
máxima de pacotes na fila
set opt(adhocRouting) DSDV ;# routing
protocol
set opt(x) 1100 ;# X dimension of the
topography
set opt(y) 1100 ;# Y dimension of the
topography
#create the simulator
set ns [new Simulator]
#Gera o arquivo de trace
$ns use-newtrace
set wtrace [open $output_dir/$dirSimulacao/wtrace.tr w]
67
$ns trace-all $wtrace
# Arquivos de trace
# Vazão
set banda_rtps [open $output_dir/$dirSimulacao/banda_rtps.tr w]
set banda_ugs1 [open $output_dir/$dirSimulacao/banda_ugs1.tr w]
set banda_ugs2 [open $output_dir/$dirSimulacao/banda_ugs2.tr w]
set banda_be1 [open $output_dir/$dirSimulacao/banda_be1.tr w]
set banda_be2 [open $output_dir/$dirSimulacao/banda_be2.tr w]
# Perca de pacotes
set loss_be1 [open $output_dir/$dirSimulacao/loss_be1.tr w]
set loss_be2 [open $output_dir/$dirSimulacao/loss_be2.tr w]
set loss_ugs1 [open $output_dir/$dirSimulacao/loss_ugs1.tr w]
set loss_ugs2 [open $output_dir/$dirSimulacao/loss_ugs2.tr w]
# Delay
set delay_be1 [open $output_dir/$dirSimulacao/delay_be1.tr w]
set delay_be2 [open $output_dir/$dirSimulacao/delay_be2.tr w]
set delay_ugs1 [open $output_dir/$dirSimulacao/delay_ugs1.tr w]
set delay_ugs2 [open $output_dir/$dirSimulacao/delay_ugs2.tr w]
#create the topography
set topo [new Topography]
$topo load_flatgrid $opt(x) $opt(y)
#puts "Topology criada"
# set up for hierarchical routing (needed for routing over a
basestation) : cria o roteamento hierárquico
$ns node-config -addressType hierarchical
AddrParams set domain_num_ 2 ;# domain
number
lappend cluster_num 1 1 ;# cluster
number for each domain
AddrParams set cluster_num_ $cluster_num
#Aymen#lappend eilastlevel 1 2 ;# number of nodes for
each cluster (1 for sink and one for mobile node + base station
lappend eilastlevel 1 29
AddrParams set nodes_num_ $eilastlevel
puts "Configuração para o endereçamento hieráquico pronto"
# Create God
create-god 30
# Cria o servidor que enviará o vídeo, ele está no primeio
espaço de endereços [0 = domínio, 0=subdomínio e 0=numero único
no subdomínio]
set servidor [$ns node 0.0.0]
$servidor set X_ 150.0
$servidor set Y_ 100.0
$servidor set Z_ 0.0
puts "criei o nó servidor"
#creates the Access Point (Base station)
68
$ns node-config -adhocRouting $opt(adhocRouting) \
-llType $opt(ll) \
-macType $opt(mac) \
-ifqType $opt(ifq) \
-ifqLen $opt(ifqlen) \
-antType $opt(ant) \
-propType $opt(prop) \
-phyType $opt(netif) \
-channel [new $opt(chan)] \
-topoInstance $topo \
-wiredRouting ON \
-agentTrace OFF \
-routerTrace OFF \
-macTrace ON \
-movementTrace OFF
Mac/802_16 set fbandwidth_ [lindex $argv 4]e+6; # largura do
canal em Mhz [ 5 | 10 | 20 ]e+6
#puts "Configuração para BS pronta"
set bsWIMAX [$ns node 1.0.0]
$bsWIMAX color "red"
$ns at 0 "$bsWIMAX label bsWIMAX([$bsWIMAX node-addr])"
$bsWIMAX random-motion 0
# define o posicionamento para a BS (fixo)
$bsWIMAX set X_ 500.0
$bsWIMAX set Y_ 350.0
$bsWIMAX set Z_ 0.0
set clas [new SDUClassifier/Dest]
[$bsWIMAX set mac_(0)] add-classifier $clas
set bs_sched [new WimaxScheduler/BS]
$bs_sched set-default-modulation [lindex $argv 0]
;#OFDM_BPSK_1_2
[$bsWIMAX set mac_(0)] set-scheduler $bs_sched
[$bsWIMAX set mac_(0)] set-channel 0
puts "BS criada"
# Criando um link entre o servidor e a BS
$ns duplex-link $servidor $bsWIMAX 100Mb 1ms DropTail
################################################################
#####################################
# RTPS - Real-Time Polling Service
################################################################
#####################################
set first_rtPS 100
set nb_rtPS 1
$bs_sched set-SymbolNumberForUnicastRequest 20
#bs_sched set-rtPSscheduling scheduling
69
# "RR", "mSIR", "mmSIR", "WRR", "TRS_RR", "TRS_mSIR", ...
set rtPS_scheduler_ [lindex $argv 2]
$bs_sched set-rtPSscheduling $rtPS_scheduler_
# seed the default RNG
global defaultRNG
$defaultRNG seed 9999
#### interval_ ########
set interval_rtPS(1) 0.01
set interval_rtPS(2) 0.04
set interval_rtPS(3) 0.05
set interval_rtPS(4) 0.02
set interval_rtPS(5) 0.05
set interval_rtPS(6) 0.04
set interval_rtPS(7) 0.03
set interval_rtPS(8) 0.02
set interval_rtPS(9) 0.03
#######################
#### SNR ############
set SNR_rtPS(1) 7.0
set SNR_rtPS(2) 7.5
set SNR_rtPS(3) 9.0
set SNR_rtPS(4) 12.0
set SNR_rtPS(5) 17.0
set SNR_rtPS(6) 17.5
set SNR_rtPS(7) 20.0
set SNR_rtPS(8) 24.0
set SNR_rtPS(9) 25.5
#### WRR #########
if {$rtPS_scheduler_ == "WRR"} {
set WRR_rtPS(1) 1
set WRR_rtPS(2) 1
set WRR_rtPS(3) 1
set WRR_rtPS(4) 2
set WRR_rtPS(5) 2
set WRR_rtPS(6) 3
set WRR_rtPS(7) 3
set WRR_rtPS(8) 4
set WRR_rtPS(9) 4
}
##################
##################
#set-TRSparameters-SNR-Tr-Tp-L SNRth Tr Tp L
$bs_sched set-TRSparameters-SNR-Tr-Tp-L 8.5 2 3 4
##################
$ns node-config -wiredRouting OFF \
-macTrace ON \
70
set node_rtPS [$ns node 1.0.2] ;# create the node with given @.
$node_rtPS random-motion 0 ;# disable random motion
$node_rtPS base-station [AddrParams addr2id [$bsWIMAX node-
addr]] ;#attach mn to basestation
#compute position of the node
$node_rtPS set X_ [expr 500.0]
$node_rtPS set Y_ [expr 700.0]
$node_rtPS set Z_ 0.0
puts "node_rtPS: tcl=$node_rtPS; id=[$node_rtPS id];
addr=[$node_rtPS node-addr] Trafego de Vídeo"
set clas [new SDUClassifier/Dest]
[$node_rtPS set mac_(0)] add-classifier $clas
#set the scheduler for the node. Must be changed to -shed [new
$opt(sched)]
set ss_sched [new WimaxScheduler/SS]
[$node_rtPS set mac_(0)] set-scheduler $ss_sched
[$node_rtPS set mac_(0)] set-channel 0
# Criar uma agent UDP e anexar ao sink
set udp_rtPS [new Agent/myUDP]
$ns attach-agent $node_rtPS $udp_rtPS
$udp_rtPS set packetSize_ $packetSize
$udp_rtPS set fid_ 1
$udp_rtPS set_filename "$output_dir/$dirSimulacao/rtPS.e"
# Criar o agent null para o sink traffic
set null_rtPS [new Agent/myEvalvid_Sink]
$ns attach-agent $servidor $null_rtPS
$null_rtPS set_filename "$output_dir/$dirSimulacao/rtPS.r"
# Attach the 2 agents
$ns connect $udp_rtPS $null_rtPS
# Configurações do escalonador da BS para adição de fluxo
## add-flow TrafficPriority MaximumSustainedTrafficRate
MinimumReservedTrafficRate ServiceFlowSchedulingType
##ServiceFlowSchedulingType: (0=>SERVICE_UGS),
(1=>SERVICE_rtPS), (2=>SERVICE_ertPS), (3=>SERVICE_nrtPS),
(4=>SERVICE_BE)
$ss_sched add-flow 5 1750 1500 1 ;# taxa máxima sustentada = 3,5
Mbps e taxa mínima reservada 3 Mbps
puts $infoSim "Video: taxa min reservada.: 3Mbps";
puts $infoSim "Video: taxa max sustentada: 3,5Mbps";
##set-PeerNode-SNR PeerNode =(id do nodo [$nodo id]) SNR
$ns at 1.6 "$bs_sched set-PeerNode-SNR [$node_rtPS id]
$SNR_rtPS([expr 1])"
##set-PeerNode-UnicastRequestPeriodicity PeerNode Periodicity
$ns at 1.6 "$bs_sched set-PeerNode-UnicastRequestPeriodicity
[$node_rtPS id] 2"
71
if {$rtPS_scheduler_ == "WRR"} {
# set-PeerNode-WRRscheduling PeerNode Weight
$ns at 1.6 "$bs_sched set-PeerNode-WRRschedulingForrtPS
[$node_rtPS id] $WRR_rtPS([expr 1])"
}
################################################################
#####################################
#
# Aqui inserimos o tráfego de video real - framwork Evalvid
#
################################################################
#####################################
# Aqui é definido o arquivo de vídeo
global ns max_fragmented_size tempo_fim_simulacao
set original_file_name [lindex $argv 3] ;# Arquivo
trace que representa o vídeo original passado via linha de
comando
set trace_file_name [lindex $argv 3].dat ;# Arquivo que
representa fo vídeok no formato que o evalvid espera
set original_file_id [open $original_file_name r]
set trace_file_id [open $trace_file_name w]
set pre_time 0
while {[eof $original_file_id] == 0} {
gets $original_file_id current_line
scan $current_line "%d%s%d%d%f" no_ frametype_
length_ qtdPackets_ tmp2_
#puts "Tempo envio Frame nº: $no_ tempo: $tmp2_"
set time [expr int(($tmp2_ - $pre_time)* 1000000.0)]
#set time [expr int($tmp2_ * 1000000.0)]
if { $frametype_ == "I" } {
set type_v 1
set prio_p 0
}
if { $frametype_ == "P" } {
72
set type_v 2
set prio_p 0
}
if { $frametype_ == "B" } {
set type_v 3
set prio_p 0
}
if { $frametype_ == "H" } {
set type_v 1
set prio_p 0
}
puts $trace_file_id "$time $length_ $type_v $prio_p
$max_fragmented_size"
set pre_time $tmp2_
}
puts "Video Pronto para envio"
close $original_file_id
close $trace_file_id
set end_sim_time $pre_time
set trace_file [new Tracefile]
$trace_file filename $trace_file_name
set video1 [new Application/Traffic/myEvalvid]
$video1 attach-agent $udp_rtPS
$video1 attach-tracefile $trace_file
################################################################
#########################################
# UGS - Unsolicited Grant Service (exempo de aplicação:
VoIP sem supressão de silêcio)
################################################################
#########################################
#### interval_ of the CBR traffic ####
73
set interval_ugs(1) 0.15
set interval_ugs(2) 0.2
set interval_ugs(3) 0.25
set interval_ugs(4) 0.27
set interval_ugs(5) 0.3
set interval_ugs(6) 0.04
set interval_ugs(7) 0.05
set interval_ugs(8) 0.1
set interval_ugs(9) 0.1
######################################
#### SNR of the UGS connections#########
set SNR_ugs(1) 9.5
set SNR_ugs(2) 12.5
set SNR_ugs(3) 16.5
set SNR_ugs(4) 20.5
set SNR_ugs(5) 22.5
set SNR_ugs(6) 12.5
set SNR_ugs(7) 12.5
set SNR_ugs(8) 12.5
set SNR_ugs(9) 12.5
########################################
$ns node-config -wiredRouting OFF \
-macTrace ON
### UGS 1 ###
set nodeUGS1 [$ns node 1.0.3]
;
$nodeUGS1 random-motion 0
;# desabilita movimento aleatório
$nodeUGS1 base-station [AddrParams addr2id [$bsWIMAX node-addr]]
;# anexa nodo móvel à estação base
$nodeUGS1 set X_ 500.0
$nodeUGS1 set Y_ 390.0
$nodeUGS1 set Z_ 0.0
set clasUGS1 [new SDUClassifier/Dest]
[$nodeUGS1 set mac_(0)] add-classifier $clasUGS1
set ss_sched [new WimaxScheduler/SS]
[$nodeUGS1 set mac_(0)] set-scheduler $ss_sched
[$nodeUGS1 set mac_(0)] set-channel 0
puts "nodeUGS1: tcl=$nodeUGS1; id=[$nodeUGS1 id];
addr=[$nodeUGS1 node-addr]"
# Criar Agente UDP para tráfego UGS1
set udp_ugs1 [new Agent/UDP]
$udp_ugs1 set packetSize_ 1000
$ns attach-agent $nodeUGS1 $udp_ugs1
puts "criei udp_ugs1"
# Create a CBR traffic source and attach it to udp_ugs1
74
set cbr_ugs1 [new Application/Traffic/CBR]
$cbr_ugs1 set packetSize_ 1000 ;#packetSize_ * 8bits / interval_
/ 1000000 = x Mbps
$cbr_ugs1 set interval_ 0.005333333 ;# 1,5 Mbps
#$cbr_ugs1 set rate_ [lindex $argv 5]Mb
$cbr_ugs1 attach-agent $udp_ugs1
puts "Crei um app de voz UGS1"
puts $infoSim "UGS1: rate [expr [$cbr_ugs1 set packetSize_] * 8
/ [ $cbr_ugs1 set interval_] / 1000000] Mbps";
# Create the Null agent to sink traffic
set sink_ugs1 [new Agent/LossMonitor]
$ns attach-agent $servidor $sink_ugs1
# Attach the 2 agents
$ns connect $udp_ugs1 $sink_ugs1
$udp_ugs1 set fid_ 2
#$udp_ugs1 set prio_ 2
set n3 0.14999999999999999
## add-flow TrafficPriority MaximumSustainedTrafficRate
MinimumReservedTrafficRate ServiceFlowSchedulingType
##ServiceFlowSchedulingType: 0=>SERVICE_UGS, 1=>SERVICE_rtPS,
2=>SERVICE_nrtPS, 3=>SERVICE_BE
#$ss_sched add-flow 5 [expr 30 + [$cbr_ugs1 set packetSize_] *
[Mac/802_16 set frame_duration_] / $n3] 0 0
$ss_sched add-flow 5 500 250 0
##set-PeerNode-SNR PeerNode SNR
$ns at 1.5 "$bs_sched set-PeerNode-SNR [$nodeUGS1 id]
$SNR_ugs(1)"
##set-PeerNode-UGSPeriodicity PeerNode Periodicity (periodicity
of the reservation, every k frames)
$ns at 1.5 "$bs_sched set-PeerNode-UGSPeriodicity [$nodeUGS1 id]
1"
$ns node-config -wiredRouting OFF \
-macTrace ON
### UGS 2 ###
set nodeUGS2 [$ns node 1.0.4]
$nodeUGS2 random-motion 0 ;#
disable random motion
$nodeUGS2 base-station [AddrParams addr2id [$bsWIMAX node-addr]]
;#attach mn to basestation
$nodeUGS2 set X_ 500.0
$nodeUGS2 set Y_ 380.0
$nodeUGS2 set Z_ 0.0
set clasUGS2 [new SDUClassifier/Dest]
[$nodeUGS2 set mac_(0)] add-classifier $clasUGS2
set ss_sched2 [new WimaxScheduler/SS]
[$nodeUGS2 set mac_(0)] set-scheduler $ss_sched2
75
[$nodeUGS2 set mac_(0)] set-channel 0
puts "nodeUGS2: tcl=$nodeUGS2; id=[$nodeUGS2 id];
addr=[$nodeUGS2 node-addr]"
# Criar Agente UDP para tráfego UGS1
set udp_ugs2 [new Agent/UDP]
$udp_ugs2 set packetSize_ 1000
$ns attach-agent $nodeUGS2 $udp_ugs2
# Create a CBR traffic source and attach it to udp_ugs
set cbr_ugs2 [new Application/Traffic/CBR]
$cbr_ugs2 set packetSize_ 1000 ;#600x8/0.005=960k
$cbr_ugs2 set interval_ 0.005333333;# 1.5 Mbps
#$cbr_ugs2 set rate_ [lindex $argv 5]Mb
$cbr_ugs2 attach-agent $udp_ugs2
puts $infoSim "UGS2: rate = [expr [$cbr_ugs2 set packetSize_] *
8 / [ $cbr_ugs2 set interval_] / 1000000] Mbps";
# Create the Null agent to sink traffic
set sink_ugs2 [new Agent/LossMonitor]
$ns attach-agent $servidor $sink_ugs2
# Attach the 2 agents
$ns connect $udp_ugs2 $sink_ugs2
$udp_ugs2 set fid_ 3
#$udp_ugs2 set prio_ 2
set n4 0.14999999999999999; #0.20000000000000001
## add-flow TrafficPriority MaximumSustainedTrafficRate
MinimumReservedTrafficRate ServiceFlowSchedulingType
##ServiceFlowSchedulingType: (0=>SERVICE_UGS),
(1=>SERVICE_rtPS), (2=>SERVICE_ertPS), (3=>SERVICE_nrtPS),
(4=>SERVICE_BE)
#$ss_sched2 add-flow 5 [expr 30 + [$cbr_ugs2 set packetSize_] *
[Mac/802_16 set frame_duration_] / $n4] 0 0
$ss_sched2 add-flow 5 750 500 0 ;# maximum = 1,5 Mbps reservado
= 1 Mbps
##set-PeerNode-SNR PeerNode SNR
$ns at 1.5 "$bs_sched set-PeerNode-SNR [$nodeUGS2 id]
$SNR_ugs(1)"
##set-PeerNode-UGSPeriodicity PeerNode Periodicity (periodicity
of the reservation, every k frames)
$ns at 1.5 "$bs_sched set-PeerNode-UGSPeriodicity [$nodeUGS2 id]
1"
################################################################
####################################################
76
# BE - Best Effort (Melhor Esforço) - Prioridade Baixa
################################################################
####################################################
$bs_sched set-contention-size 5
set BE_scheduler_ [lindex $argv 3]
$bs_sched set-BEscheduling $BE_scheduler_
$ns node-config -wiredRouting OFF \
-macTrace ON ;# Mobile nodes
cannot do routing.
### BE 1 ###
set nodeBE1 [$ns node 1.0.5]
$nodeBE1 random-motion 0
$nodeBE1 base-station [AddrParams addr2id [$bsWIMAX node-addr]]
$nodeBE1 set X_ 250.0
$nodeBE1 set Y_ 700.0
$nodeBE1 set Z_ 0.0
set clas [new SDUClassifier/Dest]
[$nodeBE1 set mac_(0)] add-classifier $clas
set ss_sched [new WimaxScheduler/SS]
[$nodeBE1 set mac_(0)] set-scheduler $ss_sched
[$nodeBE1 set mac_(0)] set-channel 0
set udp_be1 [new Agent/UDP]
$udp_be1 set fid_ 4
#$udp_be1 set prio_ 3
set sink_be1 [new Agent/LossMonitor]
#sinkNode is transmitter
$ns attach-agent $nodeBE1 $udp_be1
$ns attach-agent $servidor $sink_be1
$ns connect $udp_be1 $sink_be1
set cbr_be1 [new Application/Traffic/CBR]
$cbr_be1 set packetSize_ 1000 ;#600x8/0.005=960k
#$cbr_be1 set interval_ 0.00533333
$cbr_be1 set rate_ 1.5Mb
$cbr_be1 attach-agent $udp_be1
puts "nodeBE1: tcl=$nodeBE1; id=[$nodeBE1 id]; addr=[$nodeBE1
node-addr]"
##set-PeerNode-SNR PeerNode SNR
$ns at 1.5 "$bs_sched set-PeerNode-SNR [$nodeBE1 id] 2"
##set-BwRequestSendingPeriod BwRequestSendingPeriod_
$ss_sched set-BwRequestSendingPeriod 1
## add-flow TrafficPriority MaximumSustainedTrafficRate
MinimumReservedTrafficRate ServiceFlowSchedulingType
77
##ServiceFlowSchedulingType: (0=>SERVICE_UGS),
(1=>SERVICE_rtPS), (2=>SERVICE_ertPS), (3=>SERVICE_nrtPS),
(4=>SERVICE_BE)
$ss_sched add-flow 1 0 0 4
### BE 2 ###
set nodeBE2 [$ns node 1.0.6]
;
$nodeBE2 random-motion 0
;# disable random motion
$nodeBE2 base-station [AddrParams addr2id [$bsWIMAX node-addr]]
;#attach mn to basestation
$nodeBE2 set X_ 200.0
$nodeBE2 set Y_ 700.0
$nodeBE2 set Z_ 0.0
set clas [new SDUClassifier/Dest]
[$nodeBE2 set mac_(0)] add-classifier $clas
set ss_sched [new WimaxScheduler/SS]
[$nodeBE2 set mac_(0)] set-scheduler $ss_sched
[$nodeBE2 set mac_(0)] set-channel 0
puts "nodeBE2: tcl=$nodeBE2; id=[$nodeBE2 id]; addr=[$nodeBE2
node-addr]"
set udp_be2 [new Agent/UDP]
$udp_be2 set fid_ 6
#$udp_be2 set prio_ 1
set sink_be2 [new Agent/LossMonitor]
$ns attach-agent $nodeBE2 $udp_be2
$ns attach-agent $servidor $sink_be2
$ns connect $udp_be2 $sink_be2
#create video traffic
set cbr_be2 [new Application/Traffic/CBR]
$cbr_be2 set packetSize_ 1000 ; #packetSize_ x 8bits
/interval_= xMbps
#$cbr_be2 set interval_ 0.00533333
$cbr_be2 set rate_ 1.5Mb
$cbr_be2 attach-agent $udp_be2
##set-PeerNode-SNR PeerNode SNR
$ns at 1.5 "$bs_sched set-PeerNode-SNR [$nodeBE2 id] 1"
##set-BwRequestSendingPeriod BwRequestSendingPeriod_
$ss_sched set-BwRequestSendingPeriod 1
## add-flow TrafficPriority MaximumSustainedTrafficRate
MinimumReservedTrafficRate ServiceFlowSchedulingType
##ServiceFlowSchedulingType: (0=>SERVICE_UGS),
(1=>SERVICE_rtPS), (2=>SERVICE_ertPS), (3=>SERVICE_nrtPS),
(4=>SERVICE_BE)
$ss_sched add-flow 1 0 0 4
78
# Procedimento para calculo de largura de banda recebida pelos
nodos
proc calculaVazao {} {
global sink_be1 sink_be2 sink_ugs1 sink_ugs2 null_rtPS
banda_rtps banda_ugs1 banda_ugs2 banda_be1 banda_be2 udp_rtPS
servidor
#Obtem uma instância do objeto Simulator
set ns [Simulator instance]
#Configura o intervalo de chamada recursiva
set time 0.5
#Calcula o número de bytes recebidos pelos Sink
# em determinado instante
#set bwRTPS [$null_rtPS set bytes_]
set bwBE1 [$sink_be1 set bytes_]
set bwBE2 [$sink_be2 set bytes_]
set bwUGS1 [$sink_ugs1 set bytes_]
set bwUGS2 [$sink_ugs2 set bytes_]
#set bwRTPS [$udp_rtPS set bytes_]
#Obtém o tempo corrente
set now [$ns now]
#Calcula a largura de banda (em MBit/s) e as
# escreve nos arquivos
#puts $banda_rtps "$now [expr $bwRTPS/$time*8/1000000]"
set vazaobe1 [expr $bwBE1/$time*8/1000000]
set vazaobe2 [expr $bwBE2/$time*8/1000000]
set vazaougs1 [expr $bwUGS1/$time*8/1000000]
set vazaougs2 [expr $bwUGS2/$time*8/1000000]
puts $banda_be1 "$now [format %.4f $vazaobe1]"
puts $banda_be2 "$now [format %.4f $vazaobe2]"
puts $banda_ugs1 "$now [format %.4f $vazaougs1]"
puts $banda_ugs2 "$now [format %.4f $vazaougs2]"
#puts $banda_rtps "$now [expr
$bwServidor/$time*8/1000000]"
#Inicializa as variáveis nos Sinks
$sink_be1 set bytes_ 0
$sink_be2 set bytes_ 0
$sink_ugs1 set bytes_ 0
$sink_ugs2 set bytes_ 0
#Chamada recursiva
$ns at [expr $now+$time] "calculaVazao"
}
proc calculaTaxaPerdaPacotes {} {
global sink_be1 sink_be2 sink_ugs1 sink_ugs2 null_rtPS
banda_rtps banda_ugs1 banda_ugs2 banda_be1 banda_be2 udp_rtPS
servidor loss_be1 loss_be2 loss_ugs1 loss_ugs2
79
set ns [Simulator instance]
#Configura o intervalo de chamada recursiva
set time 0.5
set now [$ns now]
set lossBE1 [$sink_be1 set nlost_]
set lossBE2 [$sink_be2 set nlost_]
set lossUGS1 [$sink_ugs1 set nlost_]
set lossUGS2 [$sink_ugs2 set nlost_]
puts $loss_be1 "$now [expr $lossBE1]"
puts $loss_be2 "$now [expr $lossBE2]"
puts $loss_ugs1 "$now [expr $lossUGS1]"
puts $loss_ugs2 "$now [expr $lossUGS2]"
$sink_be1 set nlost_ 0
$sink_be2 set nlost_ 0
$sink_ugs1 set nlost_ 0
$sink_ugs2 set nlost_ 0
$ns at [expr $now+$time] "calculaTaxaPerdaPacotes"
}
set holdtime 0
set holdseq 0
set holdtime1 0
set holdseq1 0
set holdtime2 0
set holdseq2 0
set holdtime3 0
set holdseq3 0
proc calculaDelay {} {
global sink_be1 sink_be2 sink_ugs1 sink_ugs2 null_rtPS
banda_rtps banda_ugs1 banda_ugs2 banda_be1 banda_be2 udp_rtPS
servidor holdtime holdseq holdtime1 holdseq1 holdtime2 holdseq2
holdtime3 holdseq3 delay_be1 delay_be2 delay_ugs1 delay_ugs2
set ns [Simulator instance]
#Configura o intervalo de chamada recursiva
set time 0.5
set now [$ns now]
set lastPktTimeBE1 [$sink_be1 set lastPktTime_]
set npktsBE1 [$sink_be1 set npkts_]
set lastPktTimeBE2 [$sink_be2 set lastPktTime_]
set npktsBE2 [$sink_be2 set npkts_]
set lastPktTimeUGS1 [$sink_ugs1 set lastPktTime_]
set npktsUGS1 [$sink_ugs1 set npkts_]
set lastPktTimeUGS2 [$sink_ugs2 set lastPktTime_]
set npktsUGS2 [$sink_ugs2 set npkts_]
if { $npktsBE1 > $holdseq } {
80
puts $delay_be1 "$now [expr ($lastPktTimeBE1 -
$holdtime)/($npktsBE1 - $holdseq)]"
} else {
puts $delay_be1 "$now [expr ($npktsBE1 - $holdseq)]"
}
if { $npktsBE2 > $holdseq1 } {
puts $delay_be2 "$now [expr ($lastPktTimeBE2 -
$holdtime1)/($npktsBE2 - $holdseq1)]"
} else {
puts $delay_be2 "$now [expr ($npktsBE2 - $holdseq1)]"
}
if { $npktsUGS1 > $holdseq2 } {
puts $delay_ugs1 "$now [expr ($lastPktTimeUGS1 -
$holdtime2)/($npktsUGS1 - $holdseq2)]"
} else {
puts $delay_ugs1 "$now [expr ($npktsUGS1 -
$holdseq2)]"
}
if { $npktsUGS2 > $holdseq3 } {
puts $delay_ugs2 "$now [expr ($lastPktTimeUGS2 -
$holdtime3)/($npktsUGS2 - $holdseq3)]"
} else {
puts $delay_ugs2 "$now [expr ($npktsUGS2 -
$holdseq3)]"
}
#set holdTimes
set holdtime $lastPktTimeBE1
set holdseq $npktsBE1
set holdtime1 $lastPktTimeBE2
set holdseq1 $npktsBE2
set holdtime2 $lastPktTimeUGS1
set holdseq2 $npktsUGS1
set holdtime3 $lastPktTimeUGS2
set holdseq3 $npktsUGS2
$ns at [expr $now+$time] "calculaDelay"
}
# @EVENTOS : Aqui é feita a programação de eventos da simulação
puts "PROGRAMANDO OS EVENTOS ..."
set time_fim_trafego [ expr $end_sim_time]
puts "tempo fim da simulação $time_fim_trafego"
$ns at [expr $traffic_start ] "$video1 start"
$ns at [expr $traffic_start] "$cbr_ugs1 start"
$ns at [expr $traffic_start + 8.0] "$cbr_ugs2 start"
$ns at [expr $traffic_start + 1.0] "$cbr_be1 start"
$ns at [expr $traffic_start + 1.0] "$cbr_be2 start"
puts "PROGRAMEI O INICIO VÍDEO : $video1 $traffic_start"
81
$ns at [ expr $time_fim_trafego + $traffic_start] "$video1
stop"
$ns at [ expr $time_fim_trafego + $traffic_start]
"$cbr_ugs1 stop"
$ns at [ expr $time_fim_trafego + $traffic_start]
"$cbr_ugs2 stop"
$ns at [ expr $time_fim_trafego + $traffic_start] "$cbr_be1
stop"
$ns at [ expr $time_fim_trafego + $traffic_start] "$cbr_be2
stop"
puts "PROGRAMEI O FIM VÍDEO : $video1 para [expr
$time_fim_trafego + $traffic_start]"
$ns at [expr $time_fim_trafego + $traffic_start + 4.0]
"$null_rtPS closefile"
$ns at [expr $time_fim_trafego + $traffic_start + 4.0]
"$udp_rtPS closefile"
puts "PROGRAMEI O FECHAMENTO DO ARQUIVO DE TRACE DO RECEPTOR DO
VÍDEO $video1 para : [ expr $time_fim_trafego + $traffic_start +
4.0 ]"
if { $tempo_fim_simulacao <= $end_sim_time } {
set tempo_fim_simulacao [ expr $time_fim_trafego +
$traffic_start + 5.0]
puts "NOVO INSTANTE DE FINALIZAÇÃO DA SIMULAÇÃO :
$tempo_fim_simulacao "
}
puts "FINALIZEI A CONFIGURAÇÃO DO VÍDEO."
# Procedimento de finalização da simulação: grava arquivos de
trace e mostras gráficos de QoS (Vazão, perda de pacotes e
atraso)
proc finish {} {
global ns wnam wtrace dir output_dir dirSimulacao banda_rtps
banda_ugs1 banda_ugs2 banda_be1 banda_be2 loss_be1 loss_be2
loss_ugs1 loss_ugs2 delay_be1 delay_be2 delay_ugs1 delay_ugs2
$ns flush-trace
close $banda_rtps
close $banda_ugs1
close $banda_ugs2
close $banda_be1
close $banda_be2
close $loss_be1
close $loss_be2
close $loss_ugs1
close $loss_ugs2
close $delay_be1
close $delay_be2
close $delay_ugs1
close $delay_ugs2
82
#close $wnam
close $wtrace
puts "Simulação Finalizada."
# grafico de vazão
exec xgraph $output_dir/$dirSimulacao/banda_ugs1.tr
$output_dir/$dirSimulacao/banda_ugs2.tr
$output_dir/$dirSimulacao/banda_be1.tr
$output_dir/$dirSimulacao/banda_be2.tr -geometry 800x600 &
# grafico de perda de pacotes
exec xgraph $output_dir/$dirSimulacao/loss_ugs1.tr
$output_dir/$dirSimulacao/loss_ugs2.tr
$output_dir/$dirSimulacao/loss_be1.tr
$output_dir/$dirSimulacao/loss_be2.tr -geometry 800x600 &
# grafico do delay
exec xgraph $output_dir/$dirSimulacao/delay_ugs1.tr
$output_dir/$dirSimulacao/delay_ugs2.tr
$output_dir/$dirSimulacao/delay_be1.tr
$output_dir/$dirSimulacao/delay_be2.tr -geometry 800x600 &
exit 0
}
$ns at $traffic_start "calculaVazao"
$ns at $traffic_start "calculaTaxaPerdaPacotes"
$ns at $traffic_start "calculaDelay"
$ns at [expr $tempo_fim_simulacao ] "finish"
puts "Início da Simulação ..."
$ns run
83
APÊNDICE B – Scripts TCL de Cenário e agentes
configurados para rede WiMAX no sentido downlink:
# Cenário - Downlink
# Author: Fernando A. Miranda
# Edney Almeida
#
#
# Server [0.0.0] Video (UDP) - send
# | UGS1 Send
# | UGS2 Send
# | BE1 Send
# | BE2 Send
# | SS_UGS1 | Sink (UDP) - Receive
# (Y) SS_UGS2 | Sink (UDP) - Receive
# BS [1.0.0] 802.16d SS_BE1
# SS_BE2
#
#
# SS_rtPS [1.0.1] 802.16d | Sink (UDP) - receive
if {$argc != 7} {
puts ""
puts "Oops ! o script requer 7 argumentos. Veja abaixo:"
puts "Uso: ns script.tcl modulation cyclic_prefix
rtPS_scheduler nomeDoArquivoDeVideo fbandwidt data-rate-nodos-
UGS1-em-Mbps nome-do-diretorio-de-saida"
puts ""
puts " MODULAÇÃO: OFDM_BPSK_1_2, OFDM_QPSK_1_2,
OFDM_QPSK_3_4"
puts " OFDM_16QAM_1_2, OFDM_16QAM_3_4,
OFDM_64QAM_2_3, OFDM_64QAM_3_4"
puts ""
puts " cyclic_prefix: 0.25, 0.125, 0.0625, 0.03125"
puts
puts " rtPS scheduler: RR, mSIR, WRR, TRS_RR, TRS_mSIR"
exit
}
# criando as variáveis globais
set dirSimulacao [lindex $argv 6]
set output_dir ./resultados;
file mkdir $output_dir/$dirSimulacao
set traffic_start 2
set tempo_fim_simulacao 0
set packetSize 1052
84
set max_fragmented_size 1024
set infoSim [open $output_dir/$dirSimulacao/infoSimulacao.txt w]
puts $infoSim "Vídeo...........: [lindex $argv 3]";
puts $infoSim "Simulacao.......: [lindex $argv 6]";
puts $infoSim "Modulacao.......: [lindex $argv 0]";
puts $infoSim "Prefixo ciclico.: [lindex $argv 1]";
puts $infoSim "Escalonador.....: [lindex $argv 2]";
puts $infoSim "Largura do canal: [lindex $argv 4]";
puts $infoSim "Tempo de início.: $traffic_start";
#set default_modulation OFDM_16QAM_3_4
# Configure Wimax
Mac/802_16 set debug_ 0
#define coverage area for base station:
Phy/WirelessPhy/OFDM set g_ [lindex $argv 1]; # define cycle
prefix [0.25, 0.125, 0.0625, 0.03125]
Phy/WirelessPhy set Pt_ 0.025
Phy/WirelessPhy set RXThresh_ 1.26562e-13;# 2.025e-12 = 500m
radius 1.26562e-13 = 1000m
Phy/WirelessPhy set CSThresh_ [expr 0.8*[Phy/WirelessPhy set
RXThresh_]]
# Parameter for wireless nodes
set opt(chan) Channel/WirelessChannel ;# tipo de
canal
set opt(prop) Propagation/TwoRayGround ;# modelo de
rádio propagação
set opt(netif) Phy/WirelessPhy/OFDM ;# network
interface type
set opt(mac) Mac/802_16 ;# MAC type
set opt(ifq) Queue/DropTail/PriQueue ;# tipo de
interface da fila
set opt(ll) LL ;# tipo da
camada de link
set opt(ant) Antenna/OmniAntenna ;# antenna
model
set opt(ifqlen) 1000 ;# quantidade
máxima de pacotes na fila
set opt(adhocRouting) DSDV ;# routing
protocol
set opt(x) 1100 ;# X dimension of the
topography
set opt(y) 1100 ;# Y dimension of the
topography
#create the simulator
set ns [new Simulator]
$ns use-newtrace
#Gera o arquivo de trace
set wtrace [open $output_dir/$dirSimulacao/wtrace.tr w]
85
$ns trace-all $wtrace
# Arquivos de trace
# Vazão
set banda_rtps [open $output_dir/$dirSimulacao/banda_rtps.tr w]
set banda_ugs1 [open $output_dir/$dirSimulacao/banda_ugs1.tr w]
set banda_ugs2 [open $output_dir/$dirSimulacao/banda_ugs2.tr w]
set banda_be1 [open $output_dir/$dirSimulacao/banda_be1.tr w]
set banda_be2 [open $output_dir/$dirSimulacao/banda_be2.tr w]
# Perca de pacotes
set loss_be1 [open $output_dir/$dirSimulacao/loss_be1.tr w]
set loss_be2 [open $output_dir/$dirSimulacao/loss_be2.tr w]
set loss_ugs1 [open $output_dir/$dirSimulacao/loss_ugs1.tr w]
set loss_ugs2 [open $output_dir/$dirSimulacao/loss_ugs2.tr w]
# Delay
set delay_be1 [open $output_dir/$dirSimulacao/delay_be1.tr w]
set delay_be2 [open $output_dir/$dirSimulacao/delay_be2.tr w]
set delay_ugs1 [open $output_dir/$dirSimulacao/delay_ugs1.tr w]
set delay_ugs2 [open $output_dir/$dirSimulacao/delay_ugs2.tr w]
#create the topography
set topo [new Topography]
$topo load_flatgrid $opt(x) $opt(y)
#puts "Topology criada"
# set up for hierarchical routing (needed for routing over a
basestation) : cria o roteamento hierárquico
$ns node-config -addressType hierarchical
AddrParams set domain_num_ 2 ;# domain
number
lappend cluster_num 1 1 ;# cluster
number for each domain
AddrParams set cluster_num_ $cluster_num
#Aymen#lappend eilastlevel 1 2 ;# number of nodes for
each cluster (1 for sink and one for mobile node + base station
lappend eilastlevel 1 29
AddrParams set nodes_num_ $eilastlevel
puts "Configuração para o endereçamento hieráquico pronto"
# Create God
create-god 30
# Cria o servidor que enviará o vídeo, ele está no primeio
espaço de endereços [0 = domínio, 0=subdomínio e 0=numero único
no subdomínio]
set servidor [$ns node 0.0.0]
$servidor set X_ 150.0
$servidor set Y_ 100.0
$servidor set Z_ 0.0
puts "criei o nó servidor"
#creates the Access Point (Base station)
86
$ns node-config -adhocRouting $opt(adhocRouting) \
-llType $opt(ll) \
-macType $opt(mac) \
-ifqType $opt(ifq) \
-ifqLen $opt(ifqlen) \
-antType $opt(ant) \
-propType $opt(prop) \
-phyType $opt(netif) \
-channel [new $opt(chan)] \
-topoInstance $topo \
-wiredRouting ON \
-agentTrace OFF \
-routerTrace OFF \
-macTrace ON \
-movementTrace OFF
Mac/802_16 set fbandwidth_ [lindex $argv 4]e+6; # largura do
canal em Mhz [ 5 | 10 | 20 ]e+6
#puts "Configuração para BS pronta"
set bsWIMAX [$ns node 1.0.0]
$bsWIMAX color "red"
$ns at 0 "$bsWIMAX label bsWIMAX([$bsWIMAX node-addr])"
$bsWIMAX random-motion 0
# define o posicionamento para a BS (fixo)
$bsWIMAX set X_ 500.0
$bsWIMAX set Y_ 350.0
$bsWIMAX set Z_ 0.0
set clas [new SDUClassifier/Dest]
[$bsWIMAX set mac_(0)] add-classifier $clas
set bs_sched [new WimaxScheduler/BS]
$bs_sched set-default-modulation [lindex $argv 0]
;#OFDM_BPSK_1_2
[$bsWIMAX set mac_(0)] set-scheduler $bs_sched
[$bsWIMAX set mac_(0)] set-channel 0
puts "BS criada"
# Criando um link entre o servidor e a BS
$ns duplex-link $servidor $bsWIMAX 100Mb 1ms DropTail
################################################################
#####################################
# RTPS - Real-Time Polling Service
################################################################
#####################################
set first_rtPS 100
set nb_rtPS 1
$bs_sched set-SymbolNumberForUnicastRequest 20
#bs_sched set-rtPSscheduling scheduling
87
# "RR", "mSIR", "mmSIR", "WRR", "TRS_RR", "TRS_mSIR", ...
set rtPS_scheduler_ [lindex $argv 2]
$bs_sched set-rtPSscheduling $rtPS_scheduler_
# seed the default RNG
global defaultRNG
$defaultRNG seed 9999
#### interval_ ########
set interval_rtPS(1) 0.01
set interval_rtPS(2) 0.04
set interval_rtPS(3) 0.05
set interval_rtPS(4) 0.02
set interval_rtPS(5) 0.05
set interval_rtPS(6) 0.04
set interval_rtPS(7) 0.03
set interval_rtPS(8) 0.02
set interval_rtPS(9) 0.03
#######################
#### SNR ############
set SNR_rtPS(1) 7.0
set SNR_rtPS(2) 7.5
set SNR_rtPS(3) 9.0
set SNR_rtPS(4) 12.0
set SNR_rtPS(5) 17.0
set SNR_rtPS(6) 17.5
set SNR_rtPS(7) 20.0
set SNR_rtPS(8) 24.0
set SNR_rtPS(9) 25.5
#### WRR #########
if {$rtPS_scheduler_ == "WRR"} {
set WRR_rtPS(1) 1
set WRR_rtPS(2) 1
set WRR_rtPS(3) 1
set WRR_rtPS(4) 2
set WRR_rtPS(5) 2
set WRR_rtPS(6) 3
set WRR_rtPS(7) 3
set WRR_rtPS(8) 4
set WRR_rtPS(9) 4
}
##################
##################
#set-TRSparameters-SNR-Tr-Tp-L SNRth Tr Tp L
$bs_sched set-TRSparameters-SNR-Tr-Tp-L 8.5 2 3 4
##################
$ns node-config -wiredRouting OFF \
-macTrace ON \
88
set node_rtPS [$ns node 1.0.2] ;# create the node with given @.
$node_rtPS random-motion 0 ;# disable random motion
$node_rtPS base-station [AddrParams addr2id [$bsWIMAX node-
addr]] ;#attach mn to basestation
#compute position of the node
$node_rtPS set X_ [expr 500.0]
$node_rtPS set Y_ [expr 700.0]
$node_rtPS set Z_ 0.0
puts "node_rtPS: tcl=$node_rtPS; id=[$node_rtPS id];
addr=[$node_rtPS node-addr] Trafego de Vídeo"
set clas [new SDUClassifier/Dest]
[$node_rtPS set mac_(0)] add-classifier $clas
#set the scheduler for the node. Must be changed to -shed [new
$opt(sched)]
set ss_sched [new WimaxScheduler/SS]
[$node_rtPS set mac_(0)] set-scheduler $ss_sched
[$node_rtPS set mac_(0)] set-channel 0
# Criar uma agent UDP e anexar ao sink
set udp_rtPS [new Agent/myUDP]
$ns attach-agent $servidor $udp_rtPS
$udp_rtPS set packetSize_ $packetSize
$udp_rtPS set fid_ 1
$udp_rtPS set_filename "$output_dir/$dirSimulacao/rtPS.e"
# Criar o agent null para o sink traffic
set null_rtPS [new Agent/myEvalvid_Sink]
$ns attach-agent $node_rtPS $null_rtPS
$null_rtPS set_filename "$output_dir/$dirSimulacao/rtPS.r"
# Attach the 2 agents
$ns connect $udp_rtPS $null_rtPS
# Configurações do escalonador da BS para adição de fluxo
## add-flow TrafficPriority MaximumSustainedTrafficRate
MinimumReservedTrafficRate ServiceFlowSchedulingType
##ServiceFlowSchedulingType: (0=>SERVICE_UGS),
(1=>SERVICE_rtPS), (2=>SERVICE_ertPS), (3=>SERVICE_nrtPS),
(4=>SERVICE_BE)
$ss_sched add-flow 5 700 500 1 ;# taxa máxima sustentada = 3,5
Mbps e taxa mínima reservada 3 Mbps
puts $infoSim "Video: taxa min reservada.: 2Mbps";
puts $infoSim "Video: taxa max sustentada: 3,5Mbps";
##set-PeerNode-SNR PeerNode =(id do nodo [$nodo id]) SNR
$ns at 1.5 "$bs_sched set-PeerNode-SNR [$node_rtPS id]
$SNR_rtPS([expr 1])"
##set-PeerNode-UnicastRequestPeriodicity PeerNode Periodicity
$ns at 1.5 "$bs_sched set-PeerNode-UnicastRequestPeriodicity
[$node_rtPS id] 2"
89
if {$rtPS_scheduler_ == "WRR"} {
# set-PeerNode-WRRscheduling PeerNode Weight
$ns at 1.5 "$bs_sched set-PeerNode-WRRschedulingForrtPS
[$node_rtPS id] $WRR_rtPS([expr 1])"
}
################################################################
#####################################
#
# Aqui inserimos o tráfego de video real - framwork Evalvid
#
################################################################
#####################################
# Aqui é definido o arquivo de vídeo
global ns max_fragmented_size tempo_fim_simulacao
set original_file_name [lindex $argv 3] ;# Arquivo
trace que representa o vídeo original passado via linha de
comando
set trace_file_name [lindex $argv 3].dat ;# Arquivo que
representa fo vídeok no formato que o evalvid espera
set original_file_id [open $original_file_name r]
set trace_file_id [open $trace_file_name w]
set pre_time 0
while {[eof $original_file_id] == 0} {
gets $original_file_id current_line
scan $current_line "%d%s%d%d%f" no_ frametype_
length_ qtdPackets_ tmp2_
#puts "Tempo envio Frame nº: $no_ tempo: $tmp2_"
set time [expr int(($tmp2_ - $pre_time)* 1000000.0)]
#set time [expr int($tmp2_ * 1000000.0)]
if { $frametype_ == "I" } {
set type_v 1
set prio_p 0
}
if { $frametype_ == "P" } {
90
set type_v 2
set prio_p 0
}
if { $frametype_ == "B" } {
set type_v 3
set prio_p 0
}
if { $frametype_ == "H" } {
set type_v 1
set prio_p 0
}
puts $trace_file_id "$time $length_ $type_v $prio_p
$max_fragmented_size"
set pre_time $tmp2_
}
puts "Video Pronto para envio"
close $original_file_id
close $trace_file_id
set end_sim_time $pre_time
set trace_file [new Tracefile]
$trace_file filename $trace_file_name
set video1 [new Application/Traffic/myEvalvid]
$video1 attach-agent $udp_rtPS
$video1 attach-tracefile $trace_file
################################################################
#########################################
# UGS - Unsolicited Grant Service (exempo de aplicação:
VoIP sem supressão de silêcio)
################################################################
#########################################
#### interval_ of the CBR traffic ####
91
set interval_ugs(1) 0.15
set interval_ugs(2) 0.2
set interval_ugs(3) 0.25
set interval_ugs(4) 0.27
set interval_ugs(5) 0.3
set interval_ugs(6) 0.04
set interval_ugs(7) 0.05
set interval_ugs(8) 0.1
set interval_ugs(9) 0.1
######################################
#### SNR of the UGS connections#########
set SNR_ugs(1) 9.5
set SNR_ugs(2) 12.5
set SNR_ugs(3) 16.5
set SNR_ugs(4) 20.5
set SNR_ugs(5) 22.5
set SNR_ugs(6) 12.5
set SNR_ugs(7) 12.5
set SNR_ugs(8) 12.5
set SNR_ugs(9) 12.5
########################################
$ns node-config -wiredRouting OFF \
-macTrace ON
### UGS 1 ###
set nodeUGS1 [$ns node 1.0.3]
$nodeUGS1 random-motion 0
;# desabilita movimento aleatório
$nodeUGS1 base-station [AddrParams addr2id [$bsWIMAX node-addr]]
;# anexa nodo móvel à estação base
$nodeUGS1 set X_ 500.0
$nodeUGS1 set Y_ 390.0
$nodeUGS1 set Z_ 0.0
set clasUGS1 [new SDUClassifier/Dest]
[$nodeUGS1 set mac_(0)] add-classifier $clasUGS1
set ss_sched [new WimaxScheduler/SS]
[$nodeUGS1 set mac_(0)] set-scheduler $ss_sched
[$nodeUGS1 set mac_(0)] set-channel 0
puts "nodeUGS1: tcl=$nodeUGS1; id=[$nodeUGS1 id];
addr=[$nodeUGS1 node-addr]"
# Criar Agente UDP para tráfego UGS1
set udp_ugs1 [new Agent/UDP]
$udp_ugs1 set packetSize_ 1000
puts "criei udp_ugs1"
# Create a CBR traffic source and attach it to udp_ugs1
92
set cbr_ugs1 [new Application/Traffic/CBR]
$cbr_ugs1 set packetSize_ 1000 ;#packetSize_ * 8bits / interval_
/ 1000000 = x Mbps
$cbr_ugs1 set interval_ 0.005333333
#$cbr_ugs1 set rate_ [lindex $argv 5]Mb
$cbr_ugs1 attach-agent $udp_ugs1
puts "Crei um app de voz UGS1"
puts $infoSim "UGS1: rate [expr [$cbr_ugs1 set packetSize_] * 8
/ [ $cbr_ugs1 set interval_] / 1000000] Mbps";
# Create the Null agent to sink traffic
set sink_ugs1 [new Agent/LossMonitor]
$ns attach-agent $servidor $udp_ugs1
$ns attach-agent $nodeUGS1 $sink_ugs1
# Attach the 2 agents
$ns connect $udp_ugs1 $sink_ugs1
$udp_ugs1 set fid_ 2
#$udp_ugs1 set prio_ 2
set n3 0.14999999999999999
## add-flow TrafficPriority MaximumSustainedTrafficRate
MinimumReservedTrafficRate ServiceFlowSchedulingType
##ServiceFlowSchedulingType: 0=>SERVICE_UGS, 1=>SERVICE_rtPS,
2=>SERVICE_nrtPS, 3=>SERVICE_BE
#$ss_sched add-flow 5 [expr 30 + [$cbr_ugs1 set packetSize_] *
[Mac/802_16 set frame_duration_] / $n3] 0 0
$ss_sched add-flow 5 [expr 750] 500 0
##set-PeerNode-SNR PeerNode SNR
$ns at 1.5 "$bs_sched set-PeerNode-SNR [$nodeUGS1 id]
$SNR_ugs(4)"
##set-PeerNode-UGSPeriodicity PeerNode Periodicity (periodicity
of the reservation, every k frames)
$ns at 1.5 "$bs_sched set-PeerNode-UGSPeriodicity [$nodeUGS1 id]
1"
$ns node-config -wiredRouting OFF \
-macTrace ON
### UGS 2 ###
set nodeUGS2 [$ns node 1.0.4]
$nodeUGS2 random-motion 0 ;#
disable random motion
$nodeUGS2 base-station [AddrParams addr2id [$bsWIMAX node-addr]]
;#attach mn to basestation
$nodeUGS2 set X_ 500.0
$nodeUGS2 set Y_ 400.0
$nodeUGS2 set Z_ 0.0
set clasUGS2 [new SDUClassifier/Dest]
[$nodeUGS2 set mac_(0)] add-classifier $clasUGS2
set ss_sched2 [new WimaxScheduler/SS]
93
[$nodeUGS2 set mac_(0)] set-scheduler $ss_sched2
[$nodeUGS2 set mac_(0)] set-channel 0
puts "nodeUGS2: tcl=$nodeUGS2; id=[$nodeUGS2 id];
addr=[$nodeUGS2 node-addr]"
# Criar Agente UDP para tráfego UGS1
set udp_ugs2 [new Agent/UDP]
$udp_ugs2 set packetSize_ 1000
# Create a CBR traffic source and attach it to udp_ugs
set cbr_ugs2 [new Application/Traffic/CBR]
$cbr_ugs2 set packetSize_ 1000 ;#600x8/0.005=960k
$cbr_ugs2 set interval_ 0.005333333
#$cbr_ugs2 set rate_ [lindex $argv 5]Mb
$cbr_ugs2 attach-agent $udp_ugs2
puts $infoSim "UGS2: rate = [expr [$cbr_ugs2 set packetSize_] *
8 / [ $cbr_ugs2 set interval_] / 1000000] Mbps";
# Create the Null agent to sink traffic
set sink_ugs2 [new Agent/LossMonitor]
$ns attach-agent $nodeUGS2 $sink_ugs2
$ns attach-agent $servidor $udp_ugs2
# Attach the 2 agents
$ns connect $udp_ugs2 $sink_ugs2
$udp_ugs2 set fid_ 3
#$udp_ugs2 set prio_ 2
set n4 0.14999999999999999; #0.20000000000000001
## add-flow TrafficPriority MaximumSustainedTrafficRate
MinimumReservedTrafficRate ServiceFlowSchedulingType
##ServiceFlowSchedulingType: (0=>SERVICE_UGS),
(1=>SERVICE_rtPS), (2=>SERVICE_ertPS), (3=>SERVICE_nrtPS),
(4=>SERVICE_BE)
#$ss_sched2 add-flow 5 [expr 30 + [$cbr_ugs2 set packetSize_] *
[Mac/802_16 set frame_duration_] / $n4] 0 0
$ss_sched2 add-flow 5 750 500 0
##set-PeerNode-SNR PeerNode SNR
$ns at 1.5 "$bs_sched set-PeerNode-SNR [$nodeUGS2 id]
$SNR_ugs(4)"
##set-PeerNode-UGSPeriodicity PeerNode Periodicity (periodicity
of the reservation, every k frames)
$ns at 1.5 "$bs_sched set-PeerNode-UGSPeriodicity [$nodeUGS2 id]
1"
94
################################################################
####################################################
# BE - Best Effort (Melhor Esforço) - Prioridade Baixa
################################################################
####################################################
$bs_sched set-contention-size 5
set BE_scheduler_ [lindex $argv 3]
$bs_sched set-BEscheduling $BE_scheduler_
$ns node-config -wiredRouting OFF \
-macTrace ON ;# Mobile nodes
cannot do routing.
### BE 1 ###
set nodeBE1 [$ns node 1.0.5]
$nodeBE1 random-motion 0
$nodeBE1 base-station [AddrParams addr2id [$bsWIMAX node-addr]]
$nodeBE1 set X_ 250.0
$nodeBE1 set Y_ 700.0
$nodeBE1 set Z_ 0.0
set clas [new SDUClassifier/Dest]
[$nodeBE1 set mac_(0)] add-classifier $clas
set ss_sched [new WimaxScheduler/SS]
[$nodeBE1 set mac_(0)] set-scheduler $ss_sched
[$nodeBE1 set mac_(0)] set-channel 0
set udp_be1 [new Agent/UDP]
$udp_be1 set fid_ 4
#$udp_be1 set prio_ 3
set sink_be1 [new Agent/LossMonitor]
#sinkNode is transmitter
$ns attach-agent $servidor $udp_be1
$ns attach-agent $nodeBE1 $sink_be1
$ns connect $udp_be1 $sink_be1
set cbr_be1 [new Application/Traffic/CBR]
$cbr_be1 set packetSize_ 1000 ;#600x8/0.005=960k
#$cbr_be1 set interval_ 0.00533333
$cbr_be1 set rate_ 1.5Mb
$cbr_be1 attach-agent $udp_be1
puts "nodeBE1: tcl=$nodeBE1; id=[$nodeBE1 id]; addr=[$nodeBE1
node-addr]"
##set-PeerNode-SNR PeerNode SNR
$ns at 1.5 "$bs_sched set-PeerNode-SNR [$nodeBE1 id] 20"
##set-BwRequestSendingPeriod BwRequestSendingPeriod_
$ss_sched set-BwRequestSendingPeriod 1
95
## add-flow TrafficPriority MaximumSustainedTrafficRate
MinimumReservedTrafficRate ServiceFlowSchedulingType
##ServiceFlowSchedulingType: (0=>SERVICE_UGS),
(1=>SERVICE_rtPS), (2=>SERVICE_ertPS), (3=>SERVICE_nrtPS),
(4=>SERVICE_BE)
$ss_sched add-flow 1 0 0 4
### BE 2 ###
set nodeBE2 [$ns node 1.0.6]
;
$nodeBE2 random-motion 0
;# disable random motion
$nodeBE2 base-station [AddrParams addr2id [$bsWIMAX node-addr]]
;#attach mn to basestation
$nodeBE2 set X_ 200.0
$nodeBE2 set Y_ 700.0
$nodeBE2 set Z_ 0.0
set clas [new SDUClassifier/Dest]
[$nodeBE2 set mac_(0)] add-classifier $clas
set ss_sched [new WimaxScheduler/SS]
[$nodeBE2 set mac_(0)] set-scheduler $ss_sched
[$nodeBE2 set mac_(0)] set-channel 0
puts "nodeBE2: tcl=$nodeBE2; id=[$nodeBE2 id]; addr=[$nodeBE2
node-addr]"
set udp_be2 [new Agent/UDP]
$udp_be2 set fid_ 6
#$udp_be2 set prio_ 1
set sink_be2 [new Agent/LossMonitor]
$ns attach-agent $servidor $udp_be2
$ns attach-agent $nodeBE2 $sink_be2
$ns connect $udp_be2 $sink_be2
#create video traffic
set cbr_be2 [new Application/Traffic/CBR]
$cbr_be2 set packetSize_ 1000 ; #packetSize_ x 8bits
/interval_= xMbps
#$cbr_be2 set interval_ 0.00533333
$cbr_be2 set rate_ 1.5Mb
$cbr_be2 attach-agent $udp_be2
##set-PeerNode-SNR PeerNode SNR
$ns at 1.5 "$bs_sched set-PeerNode-SNR [$nodeBE2 id] 20"
##set-BwRequestSendingPeriod BwRequestSendingPeriod_
$ss_sched set-BwRequestSendingPeriod 1
## add-flow TrafficPriority MaximumSustainedTrafficRate
MinimumReservedTrafficRate ServiceFlowSchedulingType
##ServiceFlowSchedulingType: (0=>SERVICE_UGS),
(1=>SERVICE_rtPS), (2=>SERVICE_ertPS), (3=>SERVICE_nrtPS),
(4=>SERVICE_BE)
96
$ss_sched add-flow 1 0 0 4
# Procedimento para calculo de largura de banda recebida pelos
nodos
proc calculaVazao {} {
global sink_be1 sink_be2 sink_ugs1 sink_ugs2 null_rtPS
banda_rtps banda_ugs1 banda_ugs2 banda_be1 banda_be2 udp_rtPS
servidor
#Obtem uma instância do objeto Simulator
set ns [Simulator instance]
#Configura o intervalo de chamada recursiva
set time 0.5
#Calcula o número de bytes recebidos pelos Sink
# em determinado instante
#set bwRTPS [$null_rtPS set bytes_]
set bwBE1 [$sink_be1 set bytes_]
set bwBE2 [$sink_be2 set bytes_]
set bwUGS1 [$sink_ugs1 set bytes_]
set bwUGS2 [$sink_ugs2 set bytes_]
#set bwRTPS [$udp_rtPS set bytes_]
#Obtém o tempo corrente
set now [$ns now]
#Calcula a largura de banda (em MBit/s) e as
# escreve nos arquivos
#puts $banda_rtps "$now [expr $bwRTPS/$time*8/1000000]"
set vazaobe1 [expr $bwBE1/$time*8/1000000]
set vazaobe2 [expr $bwBE2/$time*8/1000000]
set vazaougs1 [expr $bwUGS1/$time*8/1000000]
set vazaougs2 [expr $bwUGS2/$time*8/1000000]
puts $banda_be1 "$now [format %.4f $vazaobe1]"
puts $banda_be2 "$now [format %.4f $vazaobe2]"
puts $banda_ugs1 "$now [format %.4f $vazaougs1]"
puts $banda_ugs2 "$now [format %.4f $vazaougs2]"
#puts $banda_rtps "$now [expr
$bwServidor/$time*8/1000000]"
#Inicializa as variáveis nos Sinks
$sink_be1 set bytes_ 0
$sink_be2 set bytes_ 0
$sink_ugs1 set bytes_ 0
$sink_ugs2 set bytes_ 0
#Chamada recursiva
$ns at [expr $now+$time] "calculaVazao"
}
proc calculaTaxaPerdaPacotes {} {
97
global sink_be1 sink_be2 sink_ugs1 sink_ugs2 null_rtPS
banda_rtps banda_ugs1 banda_ugs2 banda_be1 banda_be2 udp_rtPS
servidor loss_be1 loss_be2 loss_ugs1 loss_ugs2
set ns [Simulator instance]
#Configura o intervalo de chamada recursiva
set time 0.5
set now [$ns now]
set lossBE1 [$sink_be1 set nlost_]
set lossBE2 [$sink_be2 set nlost_]
set lossUGS1 [$sink_ugs1 set nlost_]
set lossUGS2 [$sink_ugs2 set nlost_]
puts $loss_be1 "$now [expr $lossBE1]"
puts $loss_be2 "$now [expr $lossBE2]"
puts $loss_ugs1 "$now [expr $lossUGS1]"
puts $loss_ugs2 "$now [expr $lossUGS2]"
$sink_be1 set nlost_ 0
$sink_be2 set nlost_ 0
$sink_ugs1 set nlost_ 0
$sink_ugs2 set nlost_ 0
$ns at [expr $now+$time] "calculaTaxaPerdaPacotes"
}
set holdtime 0
set holdseq 0
set holdtime1 0
set holdseq1 0
set holdtime2 0
set holdseq2 0
set holdtime3 0
set holdseq3 0
proc calculaDelay {} {
global sink_be1 sink_be2 sink_ugs1 sink_ugs2 null_rtPS
banda_rtps banda_ugs1 banda_ugs2 banda_be1 banda_be2 udp_rtPS
servidor holdtime holdseq holdtime1 holdseq1 holdtime2 holdseq2
holdtime3 holdseq3 delay_be1 delay_be2 delay_ugs1 delay_ugs2
set ns [Simulator instance]
#Configura o intervalo de chamada recursiva
set time 0.5
set now [$ns now]
set lastPktTimeBE1 [$sink_be1 set lastPktTime_]
set npktsBE1 [$sink_be1 set npkts_]
set lastPktTimeBE2 [$sink_be2 set lastPktTime_]
set npktsBE2 [$sink_be2 set npkts_]
set lastPktTimeUGS1 [$sink_ugs1 set lastPktTime_]
set npktsUGS1 [$sink_ugs1 set npkts_]
set lastPktTimeUGS2 [$sink_ugs2 set lastPktTime_]
set npktsUGS2 [$sink_ugs2 set npkts_]
98
if { $npktsBE1 > $holdseq } {
puts $delay_be1 "$now [expr ($lastPktTimeBE1 -
$holdtime)/($npktsBE1 - $holdseq)]"
} else {
puts $delay_be1 "$now [expr ($npktsBE1 - $holdseq)]"
}
if { $npktsBE2 > $holdseq1 } {
puts $delay_be2 "$now [expr ($lastPktTimeBE2 -
$holdtime1)/($npktsBE2 - $holdseq1)]"
} else {
puts $delay_be2 "$now [expr ($npktsBE2 - $holdseq1)]"
}
if { $npktsUGS1 > $holdseq2 } {
puts $delay_ugs1 "$now [expr ($lastPktTimeUGS1 -
$holdtime2)/($npktsUGS1 - $holdseq2)]"
} else {
puts $delay_ugs1 "$now [expr ($npktsUGS1 -
$holdseq2)]"
}
if { $npktsUGS2 > $holdseq3 } {
puts $delay_ugs2 "$now [expr ($lastPktTimeUGS2 -
$holdtime3)/($npktsUGS2 - $holdseq3)]"
} else {
puts $delay_ugs2 "$now [expr ($npktsUGS2 -
$holdseq3)]"
}
#set holdTimes
set holdtime $lastPktTimeBE1
set holdseq $npktsBE1
set holdtime1 $lastPktTimeBE2
set holdseq1 $npktsBE2
set holdtime2 $lastPktTimeUGS1
set holdseq2 $npktsUGS1
set holdtime3 $lastPktTimeUGS2
set holdseq3 $npktsUGS2
$ns at [expr $now+$time] "calculaDelay"
}
# @EVENTOS : Aqui é feita a programação de eventos da simulação
puts "PROGRAMANDO OS EVENTOS ..."
set time_fim_trafego [ expr $end_sim_time]
puts "tempo fim da simulação $time_fim_trafego"
$ns at [expr $traffic_start] "$video1 start"
$ns at [expr $traffic_start + 0.0] "$cbr_ugs1 start"
$ns at [expr $traffic_start + 8.0] "$cbr_ugs2 start"
$ns at [expr $traffic_start + 1.0] "$cbr_be1 start"
$ns at [expr $traffic_start + 1.0] "$cbr_be2 start"
puts "PROGRAMEI O INICIO VÍDEO : $video1 $traffic_start"
99
$ns at [ expr $time_fim_trafego + $traffic_start + 2]
"$video1 stop"
$ns at [ expr $time_fim_trafego + $traffic_start]
"$cbr_ugs1 stop"
$ns at [ expr $time_fim_trafego + $traffic_start]
"$cbr_ugs2 stop"
$ns at [ expr $time_fim_trafego + $traffic_start] "$cbr_be1
stop"
$ns at [ expr $time_fim_trafego + $traffic_start] "$cbr_be2
stop"
puts "PROGRAMEI O FIM VÍDEO : $video1 para [expr
$time_fim_trafego + $traffic_start]"
$ns at [expr $time_fim_trafego + $traffic_start + 4.0]
"$null_rtPS closefile"
$ns at [expr $time_fim_trafego + $traffic_start + 4.0]
"$udp_rtPS closefile"
puts "PROGRAMEI O FECHAMENTO DO ARQUIVO DE TRACE DO RECEPTOR DO
VÍDEO $video1 para : [ expr $time_fim_trafego + $traffic_start +
4.0 ]"
if { $tempo_fim_simulacao <= $end_sim_time } {
set tempo_fim_simulacao [ expr $time_fim_trafego +
$traffic_start + 5.0]
puts "NOVO INSTANTE DE FINALIZAÇÃO DA SIMULAÇÃO :
$tempo_fim_simulacao "
}
puts "FINALIZEI A CONFIGURAÇÃO DO VÍDEO."
# Procedimento de finalização da simulação: grava arquivos de
trace e mostras gráficos de QoS (Vazão, perda de pacotes e
atraso)
proc finish {} {
global ns wnam wtrace dir output_dir dirSimulacao banda_rtps
banda_ugs1 banda_ugs2 banda_be1 banda_be2 loss_be1 loss_be2
loss_ugs1 loss_ugs2 delay_be1 delay_be2 delay_ugs1 delay_ugs2
$ns flush-trace
close $banda_rtps
close $banda_ugs1
close $banda_ugs2
close $banda_be1
close $banda_be2
close $loss_be1
close $loss_be2
close $loss_ugs1
close $loss_ugs2
close $delay_be1
close $delay_be2
close $delay_ugs1
100
close $delay_ugs2
#close $wnam
close $wtrace
puts "Simulação Finalizada."
# grafico de vazão
exec xgraph $output_dir/$dirSimulacao/banda_ugs1.tr
$output_dir/$dirSimulacao/banda_ugs2.tr
$output_dir/$dirSimulacao/banda_be1.tr
$output_dir/$dirSimulacao/banda_be2.tr -geometry 800x600 &
# grafico de perda de pacotes
exec xgraph $output_dir/$dirSimulacao/loss_ugs1.tr
$output_dir/$dirSimulacao/loss_ugs2.tr
$output_dir/$dirSimulacao/loss_be1.tr
$output_dir/$dirSimulacao/loss_be2.tr -geometry 800x600 &
# grafico do delay
exec xgraph $output_dir/$dirSimulacao/delay_ugs1.tr
$output_dir/$dirSimulacao/delay_ugs2.tr
$output_dir/$dirSimulacao/delay_be1.tr
$output_dir/$dirSimulacao/delay_be2.tr -geometry 800x600 &
exit 0
}
$ns at $traffic_start "calculaVazao"
$ns at $traffic_start "calculaTaxaPerdaPacotes"
$ns at $traffic_start "calculaDelay"
$ns at [expr $tempo_fim_simulacao ] "finish"
puts "Início da Simulação ..."
$ns run
