Universidade Federal de Uberlândia

FEELT – Faculdade de Engenharia Elétrica

Projeto 1 - Simulação de Rede Local Sem Fio (WLAN) Padrão IEEE 802.11ac
usando ns-3
PROJETO INTERDICIPLINAR PARA ELETRÔNICA E TELECOMUNICAÇÕES
Professor: Paulo Roberto Guardieiro

Aline Mendonça Silva 11611ETE008

Uberlândia – MG
08 de julho de 2019
SUMÁRIO
1 – INTRODUÇÃO .............................................................................................. 3
2 – OBJETIVOS ................................................................................................... 4
3 – FUNDAMENTAÇÃO TEÓRICA .................................................................. 5
3.1 – Intervalo de Guarda (GI) ................................................................... 5

3.2 – Largura de Banda do Canal ............................................................... 6

3.3 – Índices MCS (Modulation and Coding Set) ...................................... 6

3.4 – Spatial Stream (SS) ........................................................................... 7

3.5 – Beamforming .................................................................................... 7

3.6 – MIMO-MU ....................................................................................... 8

4 – DESENVOLVIMENTO ................................................................................ 9
5 – RESULTADOS E DISCUSSÕES ................................................................ 10
6 – CONCLUSÃO .............................................................................................. 20
7 – REFERÊNCIAS ........................................................................................... 22
ANEXO A .......................................................................................................... 23
1 – INTRODUÇÃO
A conectividade Wireless para computadores é uma alternativa de comunicação
inclusa em praticamente todos os dispositivos novos, como celulares e notebooks. Em
particular, a rede sem fio IEEE 802.11, frequentemente denominada WI-FI foi uma das
grandes novidades tecnológicas dos últimos anos. Atuando na camada física, o 802.11 define
uma série de padrões de transmissão e codificação para comunicações sem fio, sendo os mais
comuns: FHSS (Frequency Hopping Spread Spectrun), DSSS (Direct Sequence Spread
Spectrum) e OFDM (Orthogonal Frequency Division Multiplexing). Sua flexibilidade e
desempenho têm determinado sua utilização em hotspots e permitido a proliferação deste
tipo de solução de acesso a serviços em aeroportos, bares e ambientes públicos.
O Grupo IEEE 802 LMSC (LAN / MAN Standards Committee) possui
vários standards referentes a tecnologia Wi-Fi, cobrindo desde a definição do suporte rádio
até aspectos de segurança e qualidade de serviço. O mesmo desenvolveu alguns dos padrões
mais conhecidos de redes locais/metropolitanas cabeadas como o Ethernet (802.3) e os
denominados padrões de suporte de rede, como os mais conhecidos, 802.11a, 802.11b,
802.11g e 802.11n.
Ainda mais, as soluções de redes locais sem fio (Wireless Local Area Network –
WLAN) oferecidas pelos padrões da IEEE 802.11 têm sido implantadas em ambientes
corporativos (escritórios), permitindo uma rápida instalação sem a necessidade de
fiação/cabeamento, e reduzindo custos de infraestrutura.
O padrão IEEE 802.11ac, foco do trabalho, se trata de uma evolução do padrão
802.11n, onde utiliza-se as técnicas aplicadas nos padrões anteriores, como a tecnologia
MIMO. Porém, ao contrário do 802.11n, que desenvolveu novos recursos MAC para
melhoras a eficiência, o mesmo usa técnicas similares, com uma exceção. Ao invés de usar
o MIMO apenas para aumentar o número de fluxo de dados enviados para um único cliente,
o 802.11ac é pioneiro para uma forma de MIMO para vários usuários, que permite que um
ponto de acesso (AP) envie para vários clientes ao mesmo tempo.
Para que a implementação do MIMO multiusuário fosse possível, o 802.11ac
específica até oito Spatial Streams (SS), ou seja, o dobro da quantidade em relação ao
802.11n. Esses Spatial Streams extras podem ser usados para transmitir para vários clientes
ao mesmo tempo, assim, com a capacidade de transmissão em alta velocidade para vários
clientes simultaneamente, o 802.11ac acelera ainda mais as redes.
As principais diferenças entre os padrões 802.11n e 802.11ac são o aumento da
largura de banda, onde foram adicionados canais de 80MHz e 160MHz, além dos canais de
20MHz e 40MHz, o suporte de bandas de frequência apenas de 5GHz, inclusão da
modulação QAM-256, suporte de tecnologia beamforming explícito de pacotes de dados
nulo (NDP) e a inclusão da transmissão multiusuário.
O grupo do IEE 802.11 possui um método estruturado de introdução de novas
tecnologias, ou seja, quando uma lacuna é identificada no padrão existente, um número
suficiente de participantes pode iniciar um grupo de estudo para investigar se há justificativa
suficiente para desenvolver uma nova tecnologia. Normalmente, quando uma última grande
implementação está encerrando, o projeto de desenvolvimento de uma nova implementação
de um padrão se inicia. O método estruturado de desenvolver novos padrões levou a uma
longa história de inovação, oferecendo novas camadas físicas e aprimoramentos à camada
Medium Access Control (MAC) em termos de segurança e qualidade de serviço, conforme
mostrado na Figura 1.

Figura 1 – Evolução do Padrão IEEE 802.11

2 – OBJETIVOS
O objetivo do presente projeto consistiu-se no estudo do exemplo de configuração
de rede local sem fio padrão IEEE 802.11ac disponibilizado [1]. Em sequência, foi utilizado
o software Network Simulator (NS-3) para simulação de uma mesma rede local sem fio
padrão IEEE 802.11ac operando no modo infraestrutura, exibido na Figura 2.

Figura 2 – Modo infraestrutura do padrão IEEE 802.11ac

 Na realização da simulação no modo presente na Figura 2, o nó N1 de rede sem fio,
também chamado de STA (Station) transmite dados para o nó N2 AP (AccessPoint). Esses
dados deverão ser gerados por uma aplicação de rede, que utiliza o TCP e o UDP como
protocolos da camada de transporte, e opera com o enlace sem fio a 5 GHz.
Baseando-se nessas informações, foi proposta a implementação do NS-3 para o
padrão 802.11ac (WIFI_PHY_STANDARD_80211ac), para que, em seguida, fosse
apresentado os resultados da mesma, juntamente com as seguintes curvas:
• Gráficos da vazão em função da largura de banda de canal, variando entre 20, 40,
80 e 160MHz, utilizando o protocolo UDP e TCP;
• Gráficos da vazão em função do MCS (Modulation and Coding Set) utilizado, para
distâncias de 50,100, 150 e 200 metros, entre n1 e n2;
• Gráficos para o percentual de perdas de pacotes (valores médios para cinco rodadas
de simulação) em função da distância, variando entre 50, 100, 150 e 200 metros,
ente s1 e n2.

3 – FUNDAMENTAÇÃO TEÓRICA
Essa seção objetiva-se de fundamentar os conceitos principais utilizados para
realização e análise da implementação e dos resultados obtidos no presente projeto.

3.1 – Intervalo de Guarda (GI)

O intervalo de guarda pode se definido como o intervalo de tempo que um sinal

espera para ser transmitido, levando em conta que outro já está sendo. Em outras palavras,
no processo de transmissão de dados, pode-se ocorrer fatores que causam atrasos do sinal,
resultando na sobreposição e interferência de sinais, assim, esse intervalo de guarda evita a
perda do sinal mediante a essas consequências.
O padrão 802.11n conseguiu otimizar o intervalo de tempo entre símbolos
(caracteres) nas transmissões, de modo a minimizar a interferência entre símbolos (Inter
Symbol Interference – ISI). Esta interferência ocorre justamente quando o retardo entre
diferentes trajetórias RF excede o intervalo de guarda. Nas versões anteriores do protocolo
802.11 este intervalo era de 800 ns, porem no padrão 802.11n este intervalo pôde ser
reduzido para 400 ns, permitindo assim a duplicação da quantidade de símbolos transmitidos
por unidade de tempo, e uma melhoria significativa na taxa de transferência final.
Já o padrão 802.11ac mantém a capacidade de selecionar um intervalo de proteção
OFDM encurtado se o transmissor e o receptor forem capazes de processá-lo. Com o
802.11ac, ele tem exatamente o mesmo efeito do 802.11n: o intervalo de guarda diminui de
800 ns para 400 ns, proporcionando um aumento de 10% na taxa de transferência. A maioria
das implementações do 802.11n provou ser capaz de implementar o intervalo de guarda curta
sem dificuldade ou efeitos adversos. Embora o intervalo de guarda curta seja opcional,
espera-se que ele seja amplamente suportado, assim como era com o 802.11n.

3.2 – Largura de Banda do Canal

A Largura de banda pode ser definida como a faixa que delimita a operação para
transmissão de sinais, ou seja, a frequência mínima e máxima que o canal pode operar. As
versões anteriores do IEEE 802.11 operam sobre um canal de 20 MHz com modulação
OFDM ou 22 MHz com modulação DSSS. O padrão 802.11n introduziu a possiblidade de
utilização de canais com 40 MHz de banda, permitindo a duplicação das taxas de
transferência por canal, além de permitir também a combinação de dois canais sem
superposição de 20 MHZ para formar um único canal de 40 MHz. Já o padrão 802.11ac
utiliza as larguras de banda 20, 40, 80 e 160MHz, sendo as duas últimas, novidade em relação
ao 802.11n, o que possibilitou o aumento no valor da vazão.

3.3 – Índice MCS (Modulation and Coding Set)

Pode-se definir o MCS como uma taxa de modulação que representa os Spatial
Streams (SS), o tipo de codificação de erros utilizado na transmissão R, que representa
proporção útil de informação contida no código transmitido (por exemplo, um código com
taxa R = 1/2 transmite um bit de carga para cada dois bits no canal, ou seja, de cada dois
bits, um é um bit de código redundante adicionado para detectar e corrigir erros), e por fim,
o tipo de modulação utilizado (BPSK, QPSK, 16-QAM, 64-QAM ou 256-QAM). O 802.11n
define 77 combinações diferentes de modulação e codificação, enquanto o 802.11ac possui
apenas 10 valores, indo do MCS 0 ao MCS 9, utilizados no presente projeto, suportando até
oito Spatial Streams, como pode ser observado na Tabela 1

Tabela 1 – Valores de MCS, tipo de modulação e código R

 3.4 – Spatial Stream (SS)

A ideia central do MIMO, é a transmissão de múltiplos fluxos de dados pelo mesmo

canal de rádio. Cada um desses fluxo de dados é chamado de fluxo espacial pois é um
caminho separado através do espaço entre pares de comunicação. Quando um enlace MIMO
só pode transmitir usando um único fluxo, ele não é realmente MIMO e não há nenhuma
melhoria na vazão.
Fluxos espaciais são criados tendo múltiplos caminhos independentes através do
espaço entre dois dispositivos como mostrado na Figura 2, que em uma rede 802.11 típica,
são um ponto de acesso e um dispositivo cliente. Como os dois caminhos não interferem
entre si, as transmissões independentes podem ser enviadas através de cada caminho,
duplicando a taxa de transferência. Na linguagem do campo, o grau de similaridade entre os
caminhos é chamado de correlação (na Figura 3, os dois caminhos são ditos não
correlacionados).
Assim, ao projetar produtos, os projetistas pensam em formas de posicionar a antena
para que a correlação seja minimizada, de modo que a vazão geral do sistema possa ser
melhorada.

Figura 3 – Exemplo de fluxo espacial (SS) entre dois dispositivos

3.5 – Beamforming

Beamforming é um processo pelo qual o emissor de uma transmissão pode

preferencialmente direcionar sua energia para um receptor a fim aumentar a relação sinal-
ruído e, portanto, a velocidade da transmissão. De um modo geral, pode ser agrupado em
dois tipos principais. O beamforming explícito é baseado no transmissor e receptor trocando
informações sobre as características do canal de rádio para extrair o máximo desempenho
do canal de rádio com base nas medições de qualidade do canal, enquanto o beamforming
implícito é baseado em inferências das características do canal quando os frames são
perdidos. O beamforming explícito é geralmente mais poderoso porque as medições de canal
são mais detalhadas do que a inferência de perda, mas a medição explícita e a troca de dados
no link de rádio devem ser suportadas por ambas as extremidades do link.
O MIMO multiusuário representa o maior potencial do 802.11ac, embora ainda tenha
que ser comprovado em produtos comercialmente disponíveis em uso generalizado. Antes
do 802.11ac, todos os padrões 802.11 eram de usuário único: todas as transmissões enviadas
eram enviadas apenas para um único destino. O Beamforming é usado ocasionalmente em
tais redes como um meio de aumentar a potência do sinal em uma parte do território do AP
para aumentar a taxa de dados no receptor. Assim, como o padrão 802.11ac possui quatro
Spatial Streams a mais em relação ao 802.11n, isso permite que ele utilize os mesmos para
transmitir dados de mais clientes ao mesmo tempo a uma alta velocidade.

3.6 – MIMO-MU

As transmissões multiusuário são um novo recurso dentro do 802.11. Se houver dois

receptores localizados em direções suficientemente diferentes, uma transmissão em forma
de feixe pode ser enviada para cada um deles ao mesmo tempo. A Figura 4 compara as
tecnologias MIMO de usuário único usadas no 802.11n com o novo MIMO multiusuário do
802.11ac. Na Figura 4 (a), todos os fluxos espaciais são direcionados para um dispositivo
receptor. Em 2013, vários fluxos espaciais foram uma inovação técnica comum, suportada
em todos os APs 802.11n e em quase todos os dispositivos clientes. Em contraste, a Figura
4 (b) mostra o que significa para um transmissor MIMO ser multiusuário. Na figura, o ponto
de acesso está transmitindo quatro fluxos espaciais simultâneos. A mágica do MU-MIMO é
que os quatro fluxos espaciais estão sendo transmitidos para três dispositivos separados. Dois
dos fluxos espaciais são transmitidos para um laptop que suporta transmissão de dados em
alta velocidade. Cada um dos outros dos fluxos espaciais é transmitido para um único
dispositivo de fluxo, como um telefone ou um computador tablet. Para manter as três
transmissões separadas, o AP usa beamforming para focar cada uma das transmissões em
direção ao seu respectivo receptor.
Para que esse tipo de cenário funcione, é necessário que os receptores estejam
localizados em direções diferentes o suficiente para que as transmissões focadas não
interfiram umas nas outras. Devido ao potencial de interferência interstream, transmissões
multiusuário requerem feedback mais atualizado. O MIMO multiusuário tem o potencial de
mudar a forma como as redes Wi-Fi são construídas porque permite uma melhor reutilização
espacial. Uma das chaves para construir uma rede 802.11 de qualquer tipo é reutilizar o
mesmo canal em vários lugares.
 Figura 4 – Comparação entre SU-MIMO e MU-MIMO

Além dos conceitos citados anteriormente, pode-se destacar também o conceito de

vazão (Throughput), que é definida como sendo a quantidade de dados transferidos de um
lugar a outro, ou a quantidade de dados processados em um determinado espaço de tempo.
Também pode-se destacar o conceito de pacote, que é a unidade de transferência de
informação, e seu tamanho é definido como sendo a soma das informações de informações
complementares (cabeçalho) e dos dados em si que devem ser enviados, ou seja, a carga útil
(payload).

4 – DESENVOLVIMENTO
Como mencionado na Seção 2, para o desenvolvimento do projeto, foi utilizado o
simulador Network Simulator (NS-3) que foi desenvolvido para sistemas baseados em redes
de computadores, seguindo o princípio da simulação de eventos discretos, sendo um
software livre e de código aberto.
Para a realização da simulação no ns-3, seria necessário a escrita de um programa
principal em C++, o qual construiria os vários elementos necessários para descrever a rede
simulada em questão, bem como toda a atividade desejada na mesma. No entanto, no
presente projeto foi disponibilizado o código já pronto “vht-wifi-network.cc” [1], que simula
uma conexão local entre dois nós com valores pré-definidos.
 Mesmo com o corpo do código já pronto e disponível, para a execução do projeto
em questão, foram necessárias a implementação de algumas mudanças no mesmo, para que
atendesse as especificações do projeto. Entre essas mudanças, destaca-se a inserção de um
ganho na antena do transmissor e do receptor, necessária devido às maiores distâncias
presentes no projeto.
Assim, adotou-se como sendo o ganho do transmissor “TxGain” 12 dBi e o ganho
do receptor “RxGain” também como sendo 6 dBi. Esses valores foram baseados em
DataSheets de roteadores comerciais.
Além dessa alteração, foram feitas algumas outras, que podem ser observadas no
Anexo A, onde está presente o código utilizado, assim como as mudanças e os comentários
feitos para melhor entendimento do funcionamento do mesmo.
Para a geração dos resultados mencionados na Seção 2 dos Objetivos do projeto,
foi necessário modificar as variáveis “distance”, “udp” e “channelWidth” referente ao
protocolo TCP e UDP, que foi modificado um por um, para atender a todas as combinações
do projeto, presentes nos tópicos da Seção 2. Destaca-se que a variação também poderia ser
feita diretamente no script do código, declarando as variáveis com todos os valores de uma
vez, e em seguida percorrendo-os com um laço for.

5 – RESULTADOS E DISCUSSÕES
Primeiramente, foram realizadas as simulações mantendo uma distância entre os
nós fixa de 50 metros, já que a mesma apresenta os melhores valores de vazão para todos os
valores de MCS. Assim, variou-se a largura de banda, e alternou-se o protocolo de
transferência de dados da camada de transporte entre TCP e UDP. Os resultados e os gráficos
gerados podem ser vistos nas figuras a seguir.

Vazão (Mbits/s)
Largura de
UDP TCP
banda (MHz)
Long GI Short GI Long GI Short GI
20 5,8056 6,5522 5,0970 5,7943
40 12,1858 13,5871 10,7071 11,8400
80 26,5431 29,5460 23,5213 25,9667
160 53,1981 59,0908 46,5932 52,0666
Tabela 1 - Vazão em função da largura de banda e protocolo de transporte (MCS = 0)
 VAZÃO (MBITS/S) X LARGURA DE BANDA (MHZ)
70

60

50
VAZÃO (MBITS/S)

40 UDP Long GI
UDP Short GI
30
TCP Long GI
20 TCP Short GI

10

0
0 20 40 60 80 100 120 140 160 180
LARGURA DE BANDA (MHZ)

Gráfico 1 - Vazão em função da largura de banda e protocolo de transporte (MCS = 0)

Vazão (Mbits/s)
Largura de UDP TCP
banda (MHz) Long GI Short GI Long GI Short GI
20 35,6848 39,671 31,6614 35,2988
40 74,0805 82,3873 66,1956 74,0183
80 155,849 171,947 135,775 149,092
160 292,89 321,129 244,263 264,831
Tabela 3 - Vazão em função da largura de banda e protocolo de transporte (MCS = 4)

VAZÃO (MBITS/S) X LARGURA DE BANDA (MHZ)

350

300

250
VAZÃO (MBITS/S)

200 UDP Long GI

UDP Short GI
150
TCP Long GI
100 TCP Short GI

50

0
0 20 40 60 80 100 120 140 160 180
LARGURA DE BANDA (MHZ)

Gráfico 2 - Vazão em função da largura de banda e protocolo de transporte (MCS = 4)

 Vazão (Mbits/s)
Largura de
UDP TCP
banda (MHz)
Long GI Short GI Long GI Short GI
20 71,3578 79,3538 63,3089 70,6821
40 142,808 157,42 123,722 137,391
80 0 0 0 0
160 0 0 0 0
Tabela 4 - Vazão em função da largura de banda e protocolo de transporte (MCS = 8)

VAZÃO (MBITS/S) X LARGURA DE BANDA (MHZ)

180

160

140

120
VAZAÕ (MBITS/S)

100 UDP Long GI

UDP Short GI
80
TCP Long GI
60
TCP Short GI
40

20

0
0 20 40 60 80 100 120 140 160 180
LARGURA DE BANDA (MHZ)

Gráfico 3 - Vazão em função da largura de banda e protocolo de transporte (MCS = 8)

Através das tabelas e dos gráficos mostrados acima nota-se primeiramente que os
valores de vazão aumentam consideravelmente quando se altera a largura de banda do canal
de 20 MHz para 40 MHz, 80 MHz e 160 MHz, chegando a quase o dobro um do outro. Além
disso, o tipo de intervalo de guarda também influencia nos valores, sendo os mesmos,
maiores quando se trata do Short GI.
Também pode-se destacar a influência do índice MCS, já que ao aumentar o valor
do mesmo, gera um aumento proporcional no valor da vazão para o mesmo tamanho de
pacote com o mesmo intervalo de guarda e largura de canal. Esse fato deve-se ao tipo de
modulação e correção de erros.
No decorrer das simulações, pôde-se notar que para as situações em que o valor de MCS
era mais elevado, como o MCS = 8, a transmissão não era concluída. Isso deve-se ao fato da
vazão decrescer muito, fazendo com que a informação não fosse transmitida de maneira
eficiente. Este acontecimento impediu a total compilação do código por completo, pois
uma das linhas do mesmo testa o valor de vazão anterior com o atual, e caso o valor de
 vazão anterior seja maior, a simulação é interrompida, como mostrado no gráfico do MCS
= 8.

Essa queda apresentada no valor da vazão está diretamente ligada ao tipo de

modulação dos valores de MCS mais elevados. Para MCS maiores que 2, o tipo de
modulação é do tipo QAM, e quanto maior o número da modulação QAM, maior o número
de símbolos, o que resulta em uma maior quantidade de dados enviados. Porém, quanto
maior a quantidade de símbolos, maior é a probabilidade de ocorrência de interferências,
em sua maioria, causadas pela ambiguidade dos símbolos.
Em seguida, as simulações foram feitas mantendo uma largura de banda fixa de 160
MHz e variando-se a distância entre 50, 100, 150 e 200 metros, assim como os valores de
MCS de 0 a 9, a fim de obter-se os valores de vazão. Os resultados e os gráficos gerados
com as especificações citadas podem ser vistos nas figuras a seguir.

Vazão (Mbits/s)
MCS UDP TCP
Long GI Short GI Long GI Short GI
0 53,1686 59,0602 46,9893 52,1732
1 105,984 117,149 93,9208 103,771
2 155,278 171,29 135,382 148,584
3 203,568 224,05 175,098 190,743
4 292,867 321,172 244,637 264,969
5 374,51 409,326 305,062 329,845
6 402,495 438,721 321,053 346,067
7 216,664 232,601 177,065 190,454
8 0 0 0 0
9 0 0 0 0
Tabela 5 - Vazão em função do MCS para 50 metros
 VAZÃO (MBITS/S) X MCS
500
450
400
350
VAZÃO (MBITS/S)

300
UDP Long GI
250
UDP Short GI
200
TCP Long GI
150
TCP Short GI
100
50
0
0 1 2 3 4 5 6 7 8 9
MCS

Gráfico 4 - Vazão em função do MCS para 50 metros

Vazão (Mbits/s)
MCS UDP TCP
Long GI Short GI Long GI Short GI
0 53,1663 59,0566 46,9859 52,1685
1 105,976 117,139 93,915 103,798
2 155,261 171,274 135,454 148,534
3 199,05 219,103 170,014 186,044
4 0 0 0 0
5 0 0 0 0
6 0 0 0 0
7 0 0 0 0
8 0 0 0 0
9 0 0 0 0
Tabela 6 - Vazão em função do MCS para 100 metros
 VAZÃO (MBITS/S) X MCS
250

200
VAZÃO (MBITS/S)

150
UDP Long GI
UDP Short GI
100
TCP Long GI
TCP Short GI
50

0
0 1 2 3 4 5 6 7 8 9
MCS

Gráfico 5 - Vazão em função do MCS para 100 metros

Vazão (Mbits/s)
MCS UDP TCP
Long GI Short GI Long GI Short GI
0 53,1639 59,0543 46,9824 52,1662
1 105,965 117,123 93,8987 103,79
2 8,48225 9,29597 0,0069504 0,011584
3 0 0 0 0
4 0 0 0 0
5 0 0 0 0
6 0 0 0 0
7 0 0 0 0
8 0 0 0 0
9 0 0 0 0
Tabela 7 – Vazão em função do MCS para 150 metros
 VAZÃO (MBITS/S) X MCS
140

120

100
VAZÃO (MBITS/S)

80 UDP Long GI
UDP Short GI
60
TCP Long GI
40 TCP Short GI

20

0
0 1 2 3 4 5 6 7 8 9
MCS

Gráfico 6 – Vazão em função do MCS para 150 metros

Vazão (Mbits/s)
MCS UDP TCP
Long GI Short GI Long GI Short GI
0 53,0544 58,9742 46,8828 52,2021
1 0 0 0 0
2 0 0 0 0
3 0 0 0 0
4 0 0 0 0
5 0 0 0 0
6 0 0 0 0
7 0 0 0 0
8 0 0 0 0
9 0 0 0 0
Tabela 8 – Vazão em função do MCS para 200 metros
 VAZÃO (MBITS/S) X MCS
70

60

50
VAZÃO (MBITS/S)

40 UDP Long GI
UDP Short GI
30
TCP Long GI
TCP Short GI
20

10

0
0 1 2 3 4 5 6 7 8 9
MCS

Gráfico 7 – Vazão em função do MCS para 200 metros

A partir dos resultados obtidos no segundo tópico, pôde-se entender que o MCS e GI
contribuem para o aumento da vazão, ou seja, quanto maior o MCS, maior a vazão e para
Shorts GI, a vazão também é maior. Contudo, quando grandes distâncias separam os nós n1
e n2 e utiliza-se valores altos de MCS, ao quais combinam-se entre si, a vazão é seriamente
afetada, pois nessas condições a distância euclidiana entre os símbolos da modulação QAM
é um grande problema, prejudicando a transmissão. Esse fato é ocorrido devido à diminuição
inter simbólica para o caso em que uma grande quantidade de dados é transmitida. Além
disso, nas transmissões que obtiveram sucesso, pôde-se notar que houve uma certa
constância nas vazões com o mesmo índice MCS e diferentes distâncias.
Na terceira parte do projeto (terceiro tópico dos objetivos), os cálculos realizados
envolveram cálculos de percetuais de perdas, sendo assim, necessário a introdução ao código
disponibilizado [1] de uma ferramenta disponível no próprio ns-3, o Flowmonitor. Tal
ferramenta, permite o cálculo dos valores desejados, ou seja, do percetual, já que um dos
dados colhidos no ambiente de simulação é o número de pacotes perdidos.
Para que o Flowmonitor realizasse o monitoramento da simulação, foi necessário a
inserção de alguns comandos no código, presente no Anexo A. Além disso, ressalta-se que
considerou-se que o número de pacotes enviados era de 1000000, sendo o mesmo mostrado
também através do Flowmonitor.
 Distância Percentual de pacotes perdidos (%)
(m) MCS 0 MCS 4 MCS 8
50 99,5070 99,507 99,507
100 99,5071 96,9692 100
150 99,5071 96,9732 100
200 99,4437 100 100
Tabela 9 – Percentual de perdas em função da distância para 20 MHz

PE RCE NT UA L DE PACOT ES PE RDI DO S (%) X DI STÂ NCI A (M)

100.5
100
PERCENTUAL DE PACOTES PERDIDOS (%)

99.5
99
98.5
98
MCS 0
97.5
MCS 4
97
MCS 8
96.5
96
95.5
95
50 100 150 200
DISTÂNCIA (M)

Gráfico 8 – Percentual de perdas em função da distância para 20 MHz

Distância Percentual de pacotes perdidos (%)

(m) MCS 0 MCS 4 MCS 8
50 98,9653 93,7042 87,8962
100 98,9653 93,7046 100
150 98,9653 100 100
200 98,9654 100 100
Tabela 10 – Percentual de perdas em função da distância para 40 MHz
 PERCENTUAL DE PACOTES PERDIDOS (%) X DISTÂNCIA (M)
102
PERCENTUAL DE PACOTES PERDIDOS (%) 100
98
96
94
92
MCS 0
90
MCS 4
88
86 MCS 8
84
82
80
50 100 150 200
DISTÂNCIA (M)

Gráfico 9 – Percentual de perdas em função da distância para 40 MHz

Distância Percentual de pacotes perdidos (%)

(m) MCS 0 MCS 4 MCS 8
50 97,7464 86,7585 97,7464
100 97,7466 87,0334 100
150 97,7463 100 100
200 97,7464 100 100
Tabela 11 – Percentual de perdas em função da distância para 80 MHz

PE RCE NT UA L DE PACOT ES PE RDI DO S (%) X DI STÂ NCI A (M)

102
100
PERCENTUAL DE PACOTES PERDIDOS (%)

98
96
94
92
MCS 0
90
MCS 4
88
MCS 8
86
84
82
80
50 100 150 200
DISTÂNCIA (M)

Gráfico 10 – Percentual de perdas em função da distância para 80 MHz

 Distância Percentual de pacotes perdidos (%)
(m) MCS 0 MCS 4 MCS 8
50 95,4855 75,1259 100
100 95,4858 100 100
150 95,4831 100 100
200 95,4903 100 100
Tabela 12 – Percentual de perdas em função da distância para 160 MHz

PE RCE NT UA L DE PACOT ES PE RDI DO S (%) X DI STÂ NCI A (M)

103
100
PERCENTUAL DE PACOTES PERDIDOS (%)

97
94
91
88 MCS 0
85 MCS 4
82 MCS 8
79
76
73
70
50 100 150 200
DISTÂNCIA (M)

Gráfico 12 – Percentual de perdas em função da distância para 160 MHz

Destaca-se que foram escolhidos valores de MCS de 0, 4 e 8 para o primeiro tópico

do projeto, já que cada um desses possui tipos de modulações diferentes, sendo o MCS 0
BPSK, o MCS 4 16-QAM e o MCS 8 256-QAM. Além disso, entre esses MCS há também
uma difereçã no tipo de código de correção de erros, sendo R = ½, ¾ e ¾. Esses fatores
influenciam diretamente no percentual de perdas de pacotes, já que para distâncias de 50
metros, uma perda menor de pacotes pode ser notada, e para distâncias mais altas como de
200 metros, a perda chega a ser de 100%, devido à inconclusão e insucesso da transmissão.

6 – CONCLUSÃO
Após a realização de todas as etapas do projeto e analisando os resultados do
mesmo, foi possível analisar os aspectos que influenciaram nos valores, assim como a forma
que isso foi feito. Além disso, algumas conclusões podem ser feitas acerca dos conceitos
empregados nas situações simuladas no ambiente de simulação ns-3.
 Primeiramente, pode-se dizer que a largura de banda e o intervalo de guarda (GI)
são elementos que, dependendo de como são combinados entre si, alteram de maneira
significativa o valor da vazão. Assim sendo, o valor de 160 MHz de largura de banda,
considerando as transmissões realizadas com sucesso e (para distâncias menores), é o valor
que gerou uma maior vazão, considerando todos os valores MCS. Por outro lado,
considerando distâncias maiores, o valor de largura de banda que gerou uma maior vazão foi
o de 40 MHz de largura de banda.
Além disso, destaca-se o valor do MCS, que tem grandes contribuições para o
aumento da vazão, já que o mesmo depende do tipo de modulação e do código R, fazendo
com que altas velocidades de transmissão de dados sejam alcançadas.
Outro aspecto a ser levado em conta é a distância entre os nós AP (n1) e o nó cliente
(n2), já que a mesma não altera os valores de vazão de forma significativa, desde que as
potências e ganhos do transmissor e receptor sejam suficientes para a transmissão de dados
com sucesso. Assim, a distância possui uma grande influência na transmissão, já que a
mesma agrega atenuações e perdas no sinal, quando se trata de longas distâncias, sem
alteração no ganho e na potência. Assim, é importante destacar a necessidade de bons valores
de ganho de transmissão e recepção, para que essas perdas com longas distâncias sejam
minimizadas.
Em relação ao tipo de protocolo de transporte utilizado, ou seja, o TCP ou UDP
pode-se ser citado também as influências. Considerando o protocolo TCP, o mesmo
apresenta uma maior confiabilidade, mas em compensação gera uma vazão menor devido à
fase inicial denominada por Three-way handshake, que gera um atraso maior que o UDP.
Deve-se ressaltar que a utilização do tipo de protocolo depende do tipo de aplicação e da
finalidade da mesma, ou seja, caso seja uma situação em que perdas são toleradas, o UDP é
a melhor opção, enquanto o TCP pode ser utilizado para aplicações que exigem uma menor
perda de dados e não necessita de uma vazão tão alta. Assim sendo, nota-se que os resultados
de vazão obtidos com o protocolo UDP, são bem maiores em comparação aos obtidos com
o TCP.
7 – REFERÊNCIAS
[1] < https://www.nsnam.org/doxygen/vht-wifi-network_8cc_source.html> - Acessado em
08/07/2019;

[2] GAST, M. S.; 802.11ac: A Survival Guide, O'Reilly Books, 2013;

[3] < https://www.teleco.com.br/tutoriais/tutorial802-11ac/pagina_2.asp> - Acessado em

08/07/2019;

[4] <https://www.nsnam.org/docs/models/html/flow-monitor.html> - Acessado em

08/07/2019;

[5] < https://www.tp-link.com/ae/home-networking/dsl-modem-router/tdw8961n/ > -

Acessado em 08/07/2019
 ANEXO A

/* -*- Mode: C++; c-file-style: "gnu"; indent-tabs-mode:nil; -*- */

/*
* Copyright (c) 2015 SEBASTIEN DERONNE
*
* This program is free software; you can
redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation;
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330,
Boston, MA 02111- 1307 USA
*
* Author: Sebastien Deronne <sebastien.deronne@gmail.com>
*/

#include "ns3/flow-
monitor-module.h"
#include "ns3/command-
line.h" #include
"ns3/config.h"
#include
"ns3/uinteger
.h" #include
"ns3/boolean.
h" #include
"ns3/double.h
" #include
"ns3/string.h
" #include
"ns3/log.h"
#include "ns3/yans-
wifi-helper.h"
#include "ns3/ssid.h"
#include "ns3/mobility-
helper.h" #include
"ns3/internet-stack-helper.h"
#include "ns3/ipv4-address-
helper.h" #include "ns3/udp-
client-server-helper.h"
#include "ns3/packet-sink-
helper.h" #include "ns3/on-
off-helper.h"
#include "ns3/ipv4-global-
routing-helper.h" #include
"ns3/packet-sink.h"
#include "ns3/yans-wifi-channel.h"
//#include "yans-wifi-phy.h"
//#include
"wifi-
phy.h"
#include
"ns3/packet
.h"
//#include "yans-wifi-phy.h"

// This is a simple example in order to show how to

configure an IEEE 802.11ac Wi-Fi network.
//
// It outputs the UDP or TCP goodput for every VHT MCS
value, which depends on the MCS value (0 to 9, where 9
is
// forbidden when the channel width is 20 MHz), the
channel width (20, 40, 80 or 160 MHz) and the guard
interval (long)
// or short). The PHY bitrate is constant over all
the simulation run. The user can also specify the
distance between
// the access point and the station: the larger the
distance the smaller the goodput.
//
// The simulation assumes a single station in an
infrastructure network:
//
// STA AP
// * *
// | |
// n1 n2
//
//Packets in this simulation aren't marked with a
QosTag so they are considered
//belonging to BestEffort Access

Class (AC_BE). using namespace ns3;

NS_LOG_COMPONENT_DEFINE ("vht-wifi-network");

int main (int argc, char *argv[])

{
bool udp = false; // define se é udp(true)
ou tcp(false) bool useRts = false;
double simulationTime = 10; //seconds
double distance = 200.0; //distancia em metros
entre ap e o nó int mcs = 0; // -1 indicates an
unset value
double
minExpectedThroughput
= 0; double
maxExpectedThroughput
= 0;

std::string data[] =
{"0_20_0","0_40_0","0_80_0","0_160_0","4_20_0","4_40_0","4_80_0","4
_160_0","8_20_0","8_40_0","8_80_0","8_160_0",};
//
"1_20_0","1_20_1","1_40_0","1_40_1","1_80_0","1_80_1","
1_160_0","1_ 160_1",
//"2_20_0","2_20_1","2_40_0","2_40_1","2_80_0","2_80_1"
,"2_160_0"," 2_160_1",
//
"3_20_0","3_20_1","3_40_0","3_40_1","3_80_0","3_80_1","3
_160_0","3_ 160_1",
//
"4_20_0","4_20_1","4_40_0","4_40_1","4_80_0","4_80_1","4
_160_0","4_ 160_1",
//"5_20_0","5_20_1","5_40_0","5_40_1","5_80_0","5_80_1",
"5_160_0"," 5_160_1",
//"6_20_0","6_20_1","6_40_0","6_40_1","6_80_0","6_80_1",
"6_160_0"," 6_160_1",
//"7_20_0","7_20_1","7_40_0","7_40_1","7_80_0","7_80_1",
"7_160_0"," 7_160_1",
//"8_20_0","8_20_1","8_40_0","8_40_1","8_80_0","8_80_1",
"8_160_0"," 8_160_1",
//
"9_20_0","9_20_1","9_40_0","9_40_1","9_80_0","9_80_1","9
_160_0","9_ 160_1",};
int cont=0;
CommandLine cmd;
cmd.AddValue ("distance", "Distance in meters between
the station and the access point", distance);
cmd.AddValue ("simulationTime", "Simulation time
in seconds", simulationTime);
cmd.AddValue ("udp", "UDP if set to 1, TCP
otherwise", udp); cmd.AddValue ("useRts",
"Enable/disable RTS/CTS", useRts); cmd.AddValue
("mcs", "if set, limit testing to a specific MCS (0-
9)", mcs);
cmd.AddValue ("minExpectedThroughput", "if set,
simulation fails if the lowest throughput is below this
value", minExpectedThroughput); cmd.AddValue
("maxExpectedThroughput", "if set, simulation fails if
the highest throughput is above this value",
maxExpectedThroughput);
cmd.Parse (argc,argv);

if (useRts)
{
Config::SetDefault
("ns3::WifiRemoteStationManager::RtsCtsThreshold",
StringValue ("0"));
}

double prevThroughput [8];//vetor de tamanho 8

"vazão anterior" for (uint32_t l = 0; l < 8; l++)
//preenche o vetor com zeros
{
prevThroughput[l] = 0;
}
std::cout << "MCS value" << "\t\t" << "Channel width"
<< "\t\t" << "short GI" << "\t\t" << "Throughput" <<
'\n'; //mostra no terminal o que está sendo compilado
int
min
Mcs
=
0;
int
max
Mcs
=
9;
// int mcspula
= minMcs+1; if
(mcs >= 0 &&
mcs <= 9)
{
minMcs = mcs;
//maxMcs = mcs;
}

//for (int mcs = minMcs; mcs <= maxMcs; mcs=(mcspula*4)+mcs)

//varre os valores de mcs 1 3 e 9
//for (int mcs = minMcs; mcs <= maxMcs;
mcs=mcs+7) //mcs 7 for (int mcs = minMcs; mcs
<= maxMcs; mcs++)
{
uint8_t
index =
0;
double
previous
= 0;
for (int channelWidth = 20; channelWidth <= 160;
)//varre os canais definidos
{
if (mcs == 9 && channelWidth == 20)//depois de de
varrer todos os valores de mcs dobra o valor de
largura do canal
{
channe
lWidth
*= 2;
contin
ue;
}
for (int sgi = 0; sgi < 2; sgi++) //altera o guard
interval entre long e short
{
uint32_t payloadSize; //1500
byte IP packet if (udp)
{
payloadSize = 1472; //bytes
}
else
{
payloadSize = 1448; //bytes
Config::SetDefault ("ns3::TcpSocket::SegmentSize",
UintegerValue (payloadSize));
}

NodeContainer wifiStaNode;
//cria o nó 1
wifiStaNode.Create (1);
NodeContainer wifiApNode;
//cria o nó 2
wifiApNode.Create (1);

YansWifiChannelHelper channel = YansWifiChannelHelper::Default ();

//cria um canal wifi no modelo yans
YansWifiPhyHelper phy = YansWifiPhyHelper::Default
();//cria uma camada fisica(phy) no modelo yans
phy.SetChannel (channel.Create ());//atribui camada
phy ao canal phy.Set("TxGain",
DoubleValue(12.0));//Transmission gain (dB).
phy.Set("RxGain", DoubleValue(6.0));//Reception gain
(dB). phy.Set("TxPowerStart", DoubleValue(18.0));
//Minimum available transmission level (dbm).
phy.Set("TxPowerEnd", DoubleValue(18.0));
//Maximum available transmission level (dbm).

// Set guard interval

phy.Set ("ShortGuardEnabled", BooleanValue (sgi));

WifiHelper wifi; //cria um objeto WifiNetDevice

wifi.SetStandard (WIFI_PHY_STANDARD_80211ac);//define o
padrão wifi WifiMacHelper mac;//cria os layers para o
wifi

std::ostringstream oss;//classe de
saída para string oss << "VhtMcs" <<
mcs; wifi.SetRemoteStationManager
("ns3::ConstantRateWifiManager","DataMode",
StringValue (oss.str ()),
"ControlMode", StringValue (oss.str ()));

Ssid ssid = Ssid ("ns3-80211ac"); //The IEEE

802.11 SSID Information Element

mac.SetType ("ns3::StaWifiMac",
"Ssid", SsidValue (ssid)); //atribuindo valor do ssid
de acordo com o padrao escolhido para o nó1

NetDeviceContainer staDevice;
staDevice = wifi.Install (phy, mac,
wifiStaNode); //vetor da station definido e
criado

mac.SetType ("ns3::ApWifiMac",
"EnableBeaconJitter",
BooleanValue (false),
"Ssid", SsidValue (ssid));//atribuindo valor do ssid de acordo com o
padrao escolhido para o nó2

NetDeviceContainer apDevice;
apDevice = wifi.Install (phy, mac,
wifiApNode);//vetor do AP definido e criado

// Set
channel
width
Config::
Set
("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/Ch
annelWidth", UintegerValue
(channelWidth));//Configurando o valor do canal

// Set guard interval

// Config::Set
("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/HtConfig
uration/Shor tGuardIntervalSupported", BooleanValue
(sgi));

// mobility.
MobilityHelper mobility;//atribui posições e modelos
de mobilidade para nós
Ptr<ListPositionAllocator> positionAlloc =
CreateObject<ListPositionAllocator>
();//classe ponteiro

positionAlloc->Add (Vector (0.0, 0.0, 0.0));//adiciona

a posição do nó ap
positionAlloc->Add (Vector (distance, 0.0,
0.0));//adiciona a posição do nó cliente
mobility.SetPositionAllocator (positionAlloc);

mobility.SetMobilityModel

("ns3::ConstantPositionMobilityModel");

mobility.Install (wifiApNode);
mobility.Install (wifiStaNode);

/* Internet stack*/
InternetStackHelper stack;//agrega as funcionalidades
IP/UDP/TCP ao nós existentes
stack.Install
(wifiApNode);
stack.Install
(wifiStaNode);

Ipv4AddressHelper address;//classe auxiliar para

facilitar a vida ao fazer a atribuição de endereços
IPv4 simples em scripts address.SetBase
("192.168.1.0", "255.255.255.0");
Ipv4InterfaceContainer staNodeInterface;//mantém
um vetor de Std::par de Ptr<Ipv4> e indice de
interface Ipv4InterfaceContainer
apNodeInterface;

staNodeInterface = address.Assign
(staDevice); apNodeInterface =
address.Assign (apDevice);

/* Setting applications */
ApplicationContainer serverApp;//mantém um vetor de ponteiros ns3::
aplication
if (udp)
{
//UDP
flow
uint1
6_t
port
= 9;
UdpServerHelper server (port);//Cria um aplicativo de
servidor que espera por pacotes UDP de entrada e usa a
informação transportada em sua carga útil para
calcular atraso e para determinar se alguns pacotes
são perdidos.
serverApp = server.Install
(wifiStaNode.Get (0));
serverApp.Start (Seconds (0.0));
serverApp.Stop (Seconds (simulationTime + 1));
UdpClientHelper client (staNodeInterface.GetAddress
(0), port);//Cria um aplicativo cliente que envia
pacotes UDP com um número de sequência de 32 bits e
um registro de data e hora de 64 bits.
client.SetAttribute ("MaxPackets", UintegerValue
(4294967295u));//Registra um atributo a ser
definido em cada Aplicativo após sua criação.
client.SetAttribute ("Interval", TimeValue (Time ("0.00001")));
//packets/s
client.SetAttribute ("PacketSize", UintegerValue
(payloadSize)); ApplicationContainer clientApp =
client.Install (wifiApNode.Get (0));//mantém um
vetor de ponteiros ns3 :: aplication clientApp.Start
(Seconds (1.0));
clientApp.Stop (Seconds (simulationTime + 1));
}
else
{
//TCP flow
uint16_t port = 50000;
Address localAddress (InetSocketAddress
(Ipv4Address::GetAny (), port));
PacketSinkHelper packetSinkHelper
("ns3::TcpSocketFactory", localAddress);//Um
auxiliar para tornar mais fácil instanciar um ns3 ::
PacketSinkApplication em um conjunto de nós.
serverApp = packetSinkHelper.Install
(wifiStaNode.Get (0)); serverApp.Start (Seconds
(0.0));
serverApp.Stop (Seconds (simulationTime + 1));

OnOffHelper onoff ("ns3::TcpSocketFactory",

Ipv4Address::GetAny ());//Um auxiliar para tornar
mais fácil instanciar um ns3 :: OnOffApplication em
um conjunto de nós.
onoff.SetAttribute ("OnTime", StringValue
("ns3::ConstantRandomVariable[Constant=1]"));
onoff.SetAttribute ("OffTime", StringValue
("ns3::ConstantRandomVariable[Constant=0]"));
onoff.SetAttribute ("PacketSize", UintegerValue
(payloadSize)); onoff.SetAttribute ("DataRate",
DataRateValue (1000000000));
//bit/s
AddressValue remoteAddress (InetSocketAddress
(staNodeInterface.GetAddress (0),
port));//Implementação de AttributeValue para
Address.
onoff.SetAttribute ("Remote", remoteAddress);
ApplicationContainer clientApp = onoff.Install
(wifiApNode.Get (0));
clientApp.Start (Seconds (1.0));
clientApp.Stop (Seconds
(simulationTime + 1));
}

Ipv4GlobalRoutingHelper::PopulateRoutingTables
();//Constroi um banco de dados de roteamento e
inicializa as tabelas de roteamento dos nós na
simulação.
// Flow monitor
Ptr<FlowMonitor>
flowMonitor;
FlowMonitorHelper
flowHelper;
flowMonitor =
flowHelper.InstallAll();
Simulator::Stop (Seconds
(simulationTime + 1));
Simulator::Run ();//roda a
simulação
Simulator::Destroy ();//Execute os eventos
agendados com ScheduleDestroy ().
uint64_t
rxBytes =
0; if
(udp)
{
rxBytes = payloadSize * DynamicCast<UdpServer> (serverApp.Get (0))-
>GetReceived ();
}
else
{
rxBytes = DynamicCast<PacketSink> (serverApp.Get
(0))->GetTotalRx ();
}
double throughput = (rxBytes * 8)/ (simulationTime * 1000000.0);
//Mbit/s

//flowMonitor->SerializeToXmlFile("teste.xml",
true, true); flowMonitor-
>SerializeToXmlFile(data[cont]+"_50m.xml", true,
true);//envia pro arquivo

std::cout << mcs << "\t\t\t" << channelWidth << " MHz\t\t\t" << sgi
<< "\t\t\t" << throughput << " Mbit/s" << std::endl;

//test first element

if (mcs == 0 && channelWidth == 20 && sgi == 0)
{
if (throughput < minExpectedThroughput)
{
NS_LOG_ERROR ("Obtained throughput " << throughput
<< " is not expected!");
exit (1);
}
}
//test last element
if (mcs == 9 && channelWidth == 160 && sgi == 1)
{
if (maxExpectedThroughput > 0 &&
throughput >
maxExpectedThroughput)
{
NS_LOG_ERROR ("Obtained throughput " << throughput
<< " is not expected!");
exit (1);
}
}
//test previous throughput is smaller (for
the same mcs) if (throughput > previous)
{
previous = throughput;
}
//else
//{
// NS_LOG_ERROR ("Obtained throughput " << throughput
<< " is not expected!");
// exit (1);
//}
//test previous throughput is smaller (for the same
channel width and GI)
if (throughput > prevThroughput [index])
{
prevThroughput [index] = throughput;
}
//else
//{
// NS_LOG_ERROR ("Obtained throughput " << throughput
<< " is not expected!");
//exit (1);
/
/
}
index++;
cont++;
}
channelWidth *= 2;
}
}
return 0;
}