universidade federal de pernambuco centro de …tg/2019-1/tg_ec/monografia_do_tg_de_ro… · access...

UNIVERSIDADE FEDERAL DE PERNAMBUCOCENTRO DE INFORMÁTICA

GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO

Refinamentos nas Simulações dos Protocolos MACMulticanais para Comunicações Muitos-para-Muitos

Baseados no IEEE 802.11 PSM

Rogério Bezerra Santos

Trabalho de Graduação

RECIFE3 de julho de 2019





Trabalho apresentado ao Programa de Graduação em En-genharia da Computação do Centro de Informática da Uni-versidade Federal de Pernambuco como requisito parcialpara obtenção do grau de Bacharel em Engenharia daComputação.

Orientador: Prof. Dr. Renato Mariz de Moraes






Trabalho apresentado ao Programa de Graduação em Engenharia da Compu-tação do Centro de Informática da Universidade Federal de Pernambuco comorequisito parcial para obtenção do grau de Bacharel em Engenharia da Compu-tação. Defendido e aprovado em 3 de julho de 2019.

BANCA EXAMINADORA:

Prof. Dr. Renato Mariz de MoraesCIn - UFPE(Orientador)

Prof. Dr. Kelvin Lopes DiasCIn - UFPE(Avaliador)


Agradecimentos

Agradeço a Deus pela minha vida e por estar sempre presente me ajudando em todas as situa-ções.

Aos meus pais, Elias e Rosa, que sempre foram meus parceiros e nunca fizeram algo dife-rente de me apoiar. Vocês são minha inspiração.

À minha companheira Vivielle Pereira, que dividiu comigo os momentos de comemoraçãoe de lamento nessa jornada além do amor que sempre me demonstrou. Foco, Fé e Diversão.

Ao meu orientador, o Prof. Dr. Renato Mariz de Moraes, por sua destacável competênciae paixão por oferecer oportunidades de aprendizado aos seus alunos e me orientar durante todoeste tempo.

A Pabblo Ghobad, Daniel Adauto e João Paulo Marques, que encararam estes desafios depesquisa junto comigo.

Aos meus colegas da graduação, que fizeram parte desta história, em especial a João Vi-cente, parceiro de tudo na universidade.

Por fim, a todos que me ajudaram direta ou indiretamente nesta jornada. Meu muito obri-gado a todos.

iv

Resumo

Este trabalho avalia o desempenho dos protocolos atuais muitos-para-muitos (M2M, do inglêsmany-to-many) de redes sem fio ad hoc M2MMAC e H-M2MMAC. Estes protocolos são de-nominados muitos-para-muitos por permitir que cada dispositivo na rede transmita e recebadados de outros dispositivos simultaneamente. Ambos os protocolos utilizam técnicas MIMO(do inglês, Multiple Input and Multiple Output) para viabilizar este tipo de comunicação. Estesprotocolos se concentram na camada de Controle de Acesso ao Meio (MAC, do inglês MediumAccess Control) das redes sem fio. Eles são caracterizados por uma arquitetura Split Phase,ou seja, possuem duas fases de comunicação dentro de um intervalo entre beacons (quadrosou frames de gerenciamento transmitidos periodicamente), sendo a primeira fase, denominadajanela ATIM (do inglês Announcement Traffic Indication Map/Message), responsável apenaspelo anúncio da intenção de transmitir e negociação de recursos da rede e a segunda fase res-ponsável pela comunicação efetiva de dados, de forma semelhante à especificação do proto-colo IEEE 802.11 PSM. O protocolo H-M2MMAC é uma variação híbrida e adaptativa doM2MMAC, pois permite que a comunicação de dados se estenda até a fase de negociação se-guinte, o que permite o aumento do desempenho da rede em situações de alta carga. A este tipode transmissão dá-se o nome de Transmissão Estendida. Os dois protocolos não exigem o usode um dispositivo full duplex, mas de um transmissor e um receptor, ambos simplex com cadeiasparalelas de processamento de sinal, compondo um transceptor integrado. Para avaliar o de-sempenho e validar os modelos matemáticos dos dois protocolos muitos-para-muitos estudadosneste trabalho, foram realizadas simulações utilizando o simulador de rede Network Simulator3 (NS-3), que é referência nesta área. O desempenho da rede foi avaliado quanto à vazão agre-gada de saturação, situação em que todos os nós da rede possuem dados para enviar a todos osoutros. As simulações foram avaliadas quanto ao número de antenas, quantidade de nós na redee duração da janela ATIM levando-se em consideração restrições presentes em casos práticos.Foi verificado que o M2MMAC com essas restrições possui um desempenho inferior ao espe-rado pela simulação em seu trabalho original. Assim o desempenho do M2MMAC original secomporta como um limite superior do desempenho real do protocolo. Também verificou-se queo H-M2MMAC apresenta um desempenho superior ao M2MMAC devido à sua funcionalidadede estender dinamicamente algumas comunicações.

Palavras-chave: Redes Ad Hoc, Muitos-para-Muitos, Camada MAC, MIMO, M2MMAC,H-M2MMAC, simulação computacional.

v

Abstract

This work verifies the performance evaluation of the many-to-many protocols for wirelessnetworks M2MMAC and H-M2MMAC. These protocols are called many-to-many becausethey allow each device on the network to transmit and receive data from other devices simulta-neously. Both protocols use MIMO (Multiple Input and Multiple Output) techniques to enablethis type of communication. These protocols focus on the Medium Access Control (MAC)layer of the wireless networks. They are characterized by a Split Phase architecture, that is,they have two phases of communication within a beacon interval (periodically transmitted ma-nagement frames), the first phase, called the ATIM window (Announcement Traffic IndicationMap/Message), responsible only for the announcement of the intention to transmit and nego-tiate network resources, similar to the specification of the IEEE 802.11 PSM protocol. TheH-M2MMAC protocol is a hybrid and adaptive variation of the M2MMAC because it allowsthe data communication to extend to the next negotiation phase, which allows the increase ofthe performance of the network in situations of high load. This type of transmission is calledExtended Transmission. The two protocols do not require the use of a full duplex device, butrather a transmitter and a receiver, both simplex with parallel signal processing chains, com-posing an integrated transceiver. To verify the performance and to validate the mathematicalmodels of the two many-to-many protocols studied in this work, simulations were performedusing the Network Simulator 3 (NS-3), which is a reference in this area. The network per-formance was evaluated for the aggregate saturation rate, in which all nodes in the networkhave data to send to all others. The simulations were evaluated for the number of antennas,number of nodes in the network and duration of the ATIM window considering restrictions ob-served in real scenarios. It was verified that the M2MMAC performs less than expected by thesimulation in its original work which serves as an upperbound. It has also been found that H-M2MMAC performs better than M2MMAC because of its functionality to dynamically extendsome communications.

Keywords: Ad Hoc Networks, Many-to-Many, MAC Layer, M2MMAC, H-M2MMAC,MIMO, computer simulation.

vi

Sumário

1 Introdução 11.1 Motivação 11.2 Objetivos 21.3 Estrutura do Documento 3

2 Revisão Bibliográfica 42.1 Introdução 42.2 Comunicação Muitos-para-Muitos em Redes Sem Fio 42.3 Padrões IEEE 802.11 5

2.3.1 IEEE 802.11 DCF 52.3.2 IEEE 802.11 PSM 82.3.3 IEEE 802.11ac 82.3.4 IEEE 802.11ax 10

2.4 Trabalhos relacionados 102.4.1 DCA - Protocolo de Atribuição Dinâmica de Canais 102.4.2 MMAC - Protocolo MAC Multicanal 112.4.3 H-MMAC - Protocolo MAC Multicanal Híbrido 122.4.4 M2MMAC - Protocolo MAC Multicanal para Comunicação Muitos-

para-Muitos 142.4.5 H-M2MMAC - Protocolo MAC Multicanal Híbrido para Comunicação

Muitos-para-Muitos 162.5 Conclusão do Capítulo 20

3 Simulação do Protocolo M2MMAC 243.1 Introdução 243.2 Arquitetura da Simulação 243.3 Quantidade de Negociações 263.4 Vazão Agregada de Saturação 263.5 Conclusão do Capítulo 29

4 Simulação do Protocolo H-M2MMAC 304.1 Introdução 304.2 Arquitetura da Simulação 304.3 Vazão Agregada de Saturação 324.4 Conclusão do Capítulo 34

vii

5 Conclusões 355.1 Trabalhos Futuros 35

A Simulação em Detalhes 37A.1 Simulação do M2MMAC 37

A.1.1 Janela ATIM 37A.1.2 Fluxo de Controle 39A.1.3 Scripts 46

A.2 Simulação do H-M2MMAC 49A.2.1 Scripts 49

Lista de Figuras

2.1 Diagrama temporal de funcionamento do mecanismo básico de acesso IEEE802.11 DCF. Fonte: [13] 6

2.2 Ilustração do problema do terminal escondido e do terminal exposto 72.3 Diagrama temporal de funcionamento do IEEE 802.11 PSM com seus interva-

los entre beacons dividido em janela ATIM e a fase de comunicação. Fonte:[14] 9

2.4 Ilustração de uma rede BSS com detecção multiusuário MIMO (MU-MIMO).Fonte: [17] (Adaptada) 10

2.5 Diagrama temporal de funcionamento do protocolo DCA. Fonte: [21] 112.6 Diagrama temporal de funcionamento do protocolo MMAC. Fonte: [22] 122.7 Diagrama temporal de funcionamento do protocolo H-MMAC. Fonte: [23] 132.8 Três nós S, D e E realizam transmissão e recepção simultânea de pacotes em

uma rede muitos-para-muitos. Fonte: [9] 152.9 Diagrama temporal de funcionamento do protocolo M2MMMAC, represen-

tado por um intervalo entre beacons, dividido em janela de negociação e decomunicação. Fonte: [9] 16

2.10 Fluxograma de um intervalo entre beacons de decisões e ações realizadas pelotransmissor executando o M2MMAC. Fonte: [9] 17

2.11 Fluxograma de um intervalo entre beacons de decisões e ações realizadas peloreceptor executando o M2MMAC. Fonte: [9] 18

2.12 Exemplo de dois intervalos entre beacons de uma rede executando o protocoloH-M2MMAC. Fonte: [10] 19

2.13 Fluxograma de um intervalo entre beacons de decisões e ações realizadas pelotransmissor executando o H-M2MMAC. Fonte: [10] 21

2.14 Fluxograma de um intervalo entre beacons de decisões e ações realizadas peloreceptor executando o H-M2MMAC. Fonte: [10] 22

3.1 Número de negociações bem sucedidas durante Janela ATIM de 20ms e 40mse B=3 e B=5 antenas de recepção, para o modelo de simulação de Ghobad e anova simulação DCF refinado. 27

3.2 Vazão agregada de saturação obtida da simulação de Ghobad e da simulaçãoDCF refinado em função do número de nós participantes da rede (C) para dife-rentes durações da Janela ATIM e quantidades de antenas de recepção (B). 28

ix

4.1 Comparação da vazão agregada de saturação do protocolo H-M2MMAC entreo modelo de Adauto e a simulação, em função do número de nós participantesda rede (C) para diferentes durações da Janela ATIM e quantidades de antenasde recepção (B). 32

4.2 Vazão agregada de saturação dos protocolos M2MMAC e H-M2MMAC, si-mulados em função do número de nós participantes da rede (C) para diferentesdurações da Janela ATIM e quantidades de antenas de recepção (B). 33

Lista de Tabelas

2.1 Comparativo entre os protocolos MAC multicanais 23

3.1 Parâmetros e valores utilizados na simulação do protocolo M2MMAC. Fonte: [9] 25

xi

CAPÍTULO 1

Introdução

1.1 Motivação

As redes sem fio ou redes wireless encontram aplicação em diversos dispositivos móveis comosmartphones, tablets, laptops, smart TVs dentre outros. A tendência do aumento da demandapor este tipo de comunicação é ainda mais visível quando pensamos na Internet das Coisas.As redes sem fio possuem vantagem sobre as redes cabeadas por serem práticas e de baixocusto, além de oferecer uma experiência móvel mais flexível a seus usuários. Por outro lado,fatores como velocidade de locomoção do usuário, segurança e cobertura do sinal podem pesarna decisão pelo uso de redes deste tipo. O meio de difusão dos sinais normalmente é o ar e elespodem sofrer diversos fenômenos que dificultem sua decodificação por parte do receptor, comopor exemplo interferências, perda por propagação, desvanecimento, ruído térmico, múltiplospercursos entre outros [1]. O projeto de uma rede sem fio deve considerar estes fatores, sob orisco de inviabilizar seu uso.

Um dos tipos de organização de redes sem fio são as redes ad hoc. Elas se diferenciamdas redes convencionais que centralizam seu gerenciamento em um ponto de acesso (AccessPoint) e são de propósito geral. As redes ad hoc são descentralizadas, e possuem propósitosespecíficos. Elas são projetadas para situações em que uma infraestrutura não está disponível.Ela é formada por dispositivos, ou nós, que se auto-organizam de forma dinâmica dentro deuma topologia arbitrária [2]. Um dos tipos de redes ad hoc são as redes multi hop, em que osdispositivos encaminham os pacotes de forma comunitária até os seus destinos que não seriamalcançáveis com apenas uma transmissão direta (um "salto").

Dentre as aplicações das redes ad hoc estão as rede de sensores sem fio, conhecidas tambémcomo WSN (do inglês Wireless Sensor Networks), em que os nós são responsáveis por coletarinformações físicas do ambiente e transformar em sinais digitais que são processados coletiva-mente [3]. Além disso, a robustez que as redes ad hoc fornecem, sua ausência de necessidadede infraestrutura e sua mobilidade as tornam aplicáveis em atividades médicas, militares, deresgate, em Internet das Coisas (Smart Things), Cidades Inteligentes (Smart Cities), PrédiosInteligentes (Smart Buildings) e em redes com mobilidade como as redes veiculares VANETs(do inglês, Vehicular Ad Hoc Networks) [2].

Outros desafios que redes sem fio ad hoc enfrentam são as próprias limitações dos disposi-tivos, como a limitação de memória, poder de processamento e capacidade das baterias. Estesrecursos devem ser aproveitados de forma eficiente, ainda porque os nós necessitam lidar como próprio gerenciamento da rede, que inclui o controle de acesso ao meio, o roteamento e asinalização.

Para lidar com este gerenciamento, os dispositivos utilizam de protocolos de camada de

1

Controle de Acesso ao Meio (MAC, do inglês Medium Access Control) como o IEEE 802.11,conhecido comercialmente como Wi-Fi. O IEEE 802.11 permite a escolha de até três canais defrequência não sobrepostos na faixa de 2,4GHz ou de até 24 canais não sobrepostos na faixade 5GHz [4], [5], no entanto é possível propor melhorias no protocolo para utilizar múltiploscanais, permitindo a redução no número de colisões e aumento da vazão da rede.

Para aproveitar os vários canais não sobrepostos, diversos protocolos foram propostos, al-guns deles seguindo a abordagem Split Phase utilizada pelo IEEE 802.11 PSM [4], [6]. O PSM(do inglês Power Saving Mode/Mechanism) permite a redução do consumo de energia, pois acomunicação se divide em duas partes, a primeira é a janela ATIM (do inglês AnnouncementTraffic Indication Map/Message), fase em que ocorrem os avisos das intenções de se transmi-tir e a negociação dos recursos da rede. Na fase seguinte, a janela de comunicação, os nósque negociaram com sucesso poderão transmitir seus dados e participar de recepções. Aque-les que não participaram de nenhuma negociação entrarão num estado de economia de energiachamado DOZE mode.

Outra forma de utilizar os vários canais não sobrepostos disponíveis é utilizando a comu-nicação muitos-para-muitos (M2M, do inglês many-to-many) [7], [8], em que cada nó da redepode enviar e receber dados de vários outros nós simultaneamente, utilizando técnicas como oMIMO (do inglês Multiple Inputs and Multiple Outputs) e FDMA (do inglês Frequency Divi-sion Multiple Access).

Neste contexto, Ghobad [9] propôs o protocolo M2MMAC, um protocolo para redes adhoc, que se baseia no split phase do IEEE 802.11 PSM e utiliza o MIMO para permitir a comu-nicação muitos-para-muitos. Adauto [10], por sua vez, propôs uma variação deste protocolo, oH-M2MMAC, que é híbrido, o que significa que uma transmissão iniciada durante uma janelade comunicação pode se estender até o intervalo entre beacons seguinte. Sobre estes protoco-los é importante verificar seus desempenhos utilizando simulações computacionais e compararcom o desempenho de outros protocolos predecessores.

1.2 Objetivos

O objetivo geral deste trabalho é verificar o desempenho dos protocolos M2MMAC e H-M2MMAC através de simulações computacionais, verificando a vazão de saturação, estadoem que todos os dispositivos da rede possuem dados para enviar a todos os outros e incluindorestrições práticas que os estudos anteriores não consideraram (nas avaliações de desempenhoanteriores, um nó poderia insistir em continuar negociando durante a janela ATIM mesmo queo número de canais disponíveis ou de antenas de recepção não permitissem um estabelecimentode mais uma negociação, ou mesmo se dois nós já tivessem negociado com sucesso, eles po-deriam continuar tentando negociar). Como objetivos específicos, consideram-se as seguintesetapas:

• Revisão de protocolos que serviram como base para os protocolos muitos-para-muitosavaliados neste trabalho;

• Analisar a simulação do protocolo M2MMAC e propor ajustes;

• Propor uma simulação para o protocolo H-M2MMAC, visto que ainda não há simulaçãocomputacional para avaliar o desempenho deste protocolo na literatura;

• Comparar os resultados entre as simulações dos protocolos.

1.3 Estrutura do Documento

O restante deste trabalho está organizado da seguinte forma: o capítulo 2 apresenta uma revisãosobre as comunicações muitos-para-muitos, as especificicações dos padrões IEEE 802.11 maisrelevantes para este trabalho, os protocolos MAC multicanais que serviram de base para osprotocolos muitos-para-muitos estudados neste trabalho e uma revisão dos protocolos muitos-para-muitos M2MMAC e H-M2MMAC. O Capítulo 3 apresenta a metodologia da nova simu-lação do M2MMAC proposta e compara seus resultados com a simulação anterior. O Capítulo4 propõe uma metodologia de simulação do protocolo H-M2MMAC e compara seus resultadoscom o M2MMAC. Por fim, o Capítulo 5 conclui este trabalho e indica trabalhos futuros.

CAPÍTULO 2

Revisão Bibliográfica

2.1 Introdução

Este capítulo apresenta algumas definições importantes para o entendimento deste trabalho.Revisa-se a comunicação muitos-para-muitos em redes ad hoc sem fio e o protocolo IEEE802.11. Descreve-se ainda sobre alguns trabalhos precursores dos protocolos muitos-para-muitos estudados neste trabalho. São apresentados neste capítulo alguns protocolos que uti-lizam abordagens multicanal, técnica precursora da comunicação muitos-para-muitos em redessem fio. São ainda revistos os protocolos M2MMAC e H-M2MMAC, pioneiros no uso detécnicas muitos-para-muitos para redes ad hoc.

2.2 Comunicação Muitos-para-Muitos em Redes Sem Fio

Em [7], [8] é mostrado que técnicas muitos-para-muitos são capazes de aumentar a vazão darede e reduzir o atraso fim-a-fim, elevando o desempenho da rede sem fio. Redes de comuni-cações muitos-para-muitos (M2M) permitem que cada nó possa receber e transmitir dados demúltiplos outros nós simultaneamente. Isto significa que para cada par de dispositivos na rededeve haver um par de fluxos de transmissão, um para envio de dados e outro para recepção.Uma das formas de ter um fluxo bidirecional é utilizando alguma técnica full duplex que con-siga utilizar o mesmo canal de frequência para este fim. O grande desafio da comunicação fullduplex que utilize apenas um canal é eliminar a auto-interferência, devido à grande diferençade potência entre o sinal transmitido pelo próprio dispositivo e o sinal recebido de outros. Al-gumas técnicas são descritas em [11], [12], mas elas requerem o uso de um hardware complexoque consiga filtrar o sinal recebido e elevaria o custo do dispositivo e seu consumo energético,além de ser menos robustas quanto à relação sinal-ruído.

Os autores de [7], [8] apresentam uma abordagem híbrida FDMA/CDMA-SIC para comu-nicação M2M. Ela possui algumas restrições como o posicionamento dos nós, que devem estarcontidos em uma malha, de tal modo que o raio de transmissão de um nó não pode coincidircom o raio de transmissão de outro nó que utilize o mesmo código de espalhamento.

Outra abordagem é o uso da comunicação híbrida FDMA/MIMO [7]. Este modelo é a baseda comunicação muitos-para-muitos dos protocolos estudados neste trabalho, o M2MMAC [9]e o H-M2MMAC [10]. A técnica MIMO utiliza múltiplas antenas de transmissão e recepçãopara explorar a propagação de múltiplos percursos. Os dispositivos da rede devem possuir umtransmissor com uma antena capaz de transmitir em múltiplas frequência e um receptor commúltiplas antenas (também conhecido como array ou arranjo de antenas). Com este esquema,

4

obtêm-se um transceptor integrado que funciona transmitindo e recebendo simultaneamente.O MIMO, porém, possui requisitos de posicionamento dos dispositivos, devido ao efeito dacorrelação espacial, que pode dificultar a decodificação dos sinais.

2.3 Padrões IEEE 802.11

O IEEE 802.11 [6], também conhecido comercialmente como Wi-Fi, é atualmente o padrãoconsolidado para a comunicação em redes locais sem fio (WLAN, do inglês Wireless LocalArea Network). Ele é utilizado de forma crescente nos dispositivos como laptops, smartphones,smart TVs, entre outros dispositivos para comunicação principalmente com a Internet [1]. OIEEE 802.11 atua nas camadas física (PHY) e de enlace (MAC) especificando uma série depadrões de transmissão. Esta seção apresenta os padrões da família 802.11 mais relevantespara este trabalho.

2.3.1 IEEE 802.11 DCF

A Função de Coordenação Distribuída (DCF, do inglês Distributed Coordination Function) [6]é a técnica de Controle de Acesso ao Meio (MAC, do inglês, Medium Access Control) utilizadano IEEE 802.11 tanto no modo ad hoc, ou sem infraestrutura (IBSS, do inglês IndependentBasic Service Set), quanto no modo com infraestrutura (BSS, do inglês Basic Service Set),quando há um access point gerenciando a rede.

A função utiliza o mecanismo de Acesso Múltiplo com Verificação de Portadora com Pre-venção de Colisão (CSMA/CA, do inglês Carrier Sense Multiple Access/Collision Avoidance),em oposição ao CSMA/CD (do inglês Collision Detection), que realiza a detecção de colisões,desafiador em comunicações sem fio. O mecanismo do CSMA/CA se baseia em resguardos(em inglês backoffs) exponenciais binários e em intervalos de tempo predeterminados antes doinício de transmissões (ver Figura 2.1). Essas técnicas são necessárias porque a transmissão noar não permite que uma colisão seja detectada imediatamente, nem que seja possível identificarde forma autônoma uma transmissão bem sucedida.

Quando um dispositivo na rede possuir dados a ser transmitidos para um destinatário, eledeve realizar a escuta do canal identificando se ele está livre ou ocupado. Caso o canal seencontre livre por um período igual a DIFS (do inglês DCF Interframe Space), a transmissãoestá apta para acontecer. Caso contrário, o dispositivo transmissor deve continuar monitorandoo canal até que ele esteja disponível por um intervalo de tempo igual a DIFS. Para reduzir aprobabilidade de colisões neste início de transmissão, o transmissor deve escolher aleatoria-mente um número w dentro de um intervalo predefinido que será armazenado no seu contadorde resguardo. Este contador deve ser decrementado sempre que um slot de tempo for transcor-rido sem que seja detectada alguma transmissão após os intervalos DIFS. Em outras palavras,caso seja detectada uma outra transmissão durante esta espera, o contador de resguardo deveser paralisado até o fim da transmissão e de um intervalo de tempo DIFS. Quando o contadorde resguardo atingir zero, o dispositivo estará apto a transmitir.

Os slots correspondem ao intervalo de tempo discreto produzido pelo processo de res-guardo. O contador de resguardo armazena o número de slots de tempo a ser aguardados. O

Figura 2.1 Diagrama temporal de funcionamento do mecanismo básico de acesso IEEE 802.11 DCF.Fonte: [13]

intervalo de escolha deve ocorrer entre 0 e w−1, em que w é denominado Janela de Contenção(em inglês, Contention Window), com valor igual a CWmin na primeira tentativa de transmis-são. A cada tentativa de retransmissão, o valor de w deve ser dobrado até atingir o valor limiteCWmax = 2mCWmin em que m é o número de colisões anteriores. Por isso este procedimento éconhecido como Resguardo Exponencial Binário (em inglês Binary Exponential Backoff ). Umnúmero R de tentativas de retransmissão é realizado antes que um pacote seja definitivamentedescartado.

Para evitar que um dispositivo com muitos pacotes em sua fila de transmissão utilize ex-cessivamente o canal, de forma a monopolizá-lo, sempre que uma transmissão bem sucedidaocorre, o transmissor deve realizar o procedimento de resguardo aleatório.

Como o transmissor não é capaz de identificar sozinho se a transmissão foi bem sucedida, oreceptor deve enviar de volta um pacote de reconhecimento ACK (do inglês Acknowledgement)após um período SIFS (do inglês Short Interframe Space) menor que DIFS, para que a conclu-são de transmissões em andamento tenha prioridade na utilização do canal, pois nenhum outronó na rede terá tempo de iniciar uma nova transmissão. Caso o pacote ACK não seja recebidoaté um limite de tempo ACKtimeout , deve-se considerar que a transmissão foi mal-sucedida edeve-se realizar um novo procedimento de resguardo, com a janela de contenção dobrada.

O procedimento descrito anteriormente é conhecido como Mecanismo Básico de Acesso(em inglês Basic Access Mechanism), e funciona como uma negociação em duas vias (eminglês two-way handshake). Um outro procedimento disponível é o mecanismo de RTS/CTS,que funciona como uma negociação em quatro vias (em inglês four-way handshake). Nestemecanismo, sempre que um nó com dados a transmitir detectar o canal livre por um períodoDIFS, ele deve transmitir um pequeno frame RTS (do inglês Request to Send), solicitando a

Figura 2.2 Ilustração do problema do terminal escondido e do terminal exposto

reserva do canal durante o período necessário para a transmissão. O destinatário, por sua vez,após um intervalo de tempo SIFS, deve transmitir de volta um pequeno frame CTS (do inglêsClear to Send) para confirmar a reserva. Os outros nós da rede que escutaram esta negociaçãodeverão se abster de transmitir pelo tempo definido. O CTS é importante para que os nós queestão ao alcance do destinatário, mas não estão ao alcance do remetente, possam se abster detransmitir. Este mecanismo do RTS/CTS é conhecido como Detecção Virtual de Portadora(em inglês Virtual Carrier Sense). Estas informações são registradas em cada dispositivo emuma estrutura de dados denominada NAV (do inglês Network Allocation Vector), indicando aabstenção da transmissão e seu tempo de duração, para evitar colisão.

Quando uma colisão de pacotes de controle acontece, caso a camada física dos dispo-sitivos envolvidos na colisão tenha em sua implementação, é enviada uma primitiva PHY-RXEND.indication para alertar os outros nós da rede sobre a colisão. Assim, os nós que a de-tectarem deverão se abster de transmitir por um período EIFS (do inglês Extended InterframeSpace), que é maior que DIFS e é função do tempo restante estimado para uma transmissãoconsiderando os atrasos de propagação [6].

Este procedimento diminui drasticamente a probabilidade de colisão de pacotes de dados,inclusive mitigando o problema do terminal escondido, ilustrado na Figura 2.2, que ocorrequando uma estação não é capaz de detectar uma transmissão em execução para um receptorpróximo e começa a transmitir, causando uma colisão. No entanto, o mecanismo de RTS/CTSnão é capaz de resolver o problema do terminal exposto, que ocorre quando um nó da rede seabstem de transmitir por estar próximo demais de um outro nó transmissor, sendo que o seureceptor está distante o suficiente da transmissão em andamento e não causaria uma colisão.

Os protocolos analisados neste trabalho possuem características do IEEE 802.11 DCF.

2.3.2 IEEE 802.11 PSM

As redes sem fio são utilizadas principalmente por dispositivos que não estão conectados afontes externas de energia, que são alimentados por baterias. Geralmente estes dispositivospossuem limitação de tamanho e peso, dificultando o uso de baterias maiores. Principalmentenas redes ad hoc e de sensores, em que pode ser desejado um tempo de carga maior, a duraçãodas baterias é primordial. Por outro lado, é desejável que as técnicas de economia de energianão comprometam o desempenho geral da rede.

Um dispositivo na rede consome energia principalmente quanto transmite dados (TX mode),mas também enquanto processa recepções de dados (RX mode). Os nós de uma rede IEEE802.11 utilizam técnicas de contenção e detecção de portadora (em inglês carrier sense) egastam energia realizando estes procedimentos, mesmo que não estejam transmitindo dados nomomento. O consumo de energia neste estado ocioso (IDLE mode) não é insignificante numasituação de restrição energética.

O padrão IEEE 802.11 define um modo de economia de energia denominado PSM (do in-glês Power Save Mode/Mechanism) [4], [6]. Ele é aplicável tanto para redes com infraestrutura(BSS, do inglês Basic Service Set) quanto em redes sem infraestrutura (IBSS, do inglês Inde-pendent Basic Service Set). Os parágrafos a seguir descrevem o funcionamento do PSM emredes IBSS.

O PSM descreve duas fases de comunicação (ver Figura 2.3). A primeira é a janela ATIM(ou ATIM-window, do inglês Announcement Traffic Indication Message/Map), fase em que osnós que desejam transmitir dados enviam pacotes de controle, denominados pacotes ATIM,conscientizando os nós receptores de sua intenção. Desta forma, caso as negociações tenhamsido bem sucedidas, os nós da rede que possuem pacotes a enviar ou a receber saberão da suacondição ao final da janela ATIM. A janela ATIM ocorre nas mesmas bases do 802.11 DCF.A fase seguinte é a janela de comunicação, quando ocorre a transmissão de pacotes de dadosentre os nós que negociaram com sucesso na janela ATIM.

A grande vantagem do PSM é que os nós que não participarão de nenhuma transmissão ourecepção naquele momento poderão entrar no modo de economia de energia (DOZE mode ouSLEEP mode) na fase de comunicação. Neste estado, as função do dispositivo são desativadasem sua maioria para economizar energia. Estas duas fases ocorrem dentro de um intervaloentre beacons (em inglês beacon interval), que são frames de gerenciamento transmitidos pe-riodicamente. Todos os dispositivos devem voltar ao estado ativo (AWAKEN mode) antes doinício da próxima janela ATIM, no próximo intervalo entre beacons, para não causar prejuízosà comunicação.

Esta arquitetura utilizada pelo IEEE 802.11 é conhecida como split phase e é a base dosprotocolos de camada MAC estudados neste trabalho.

2.3.3 IEEE 802.11ac

O IEEE 802.11ac [5] é um dos padrões comerciais de comunicação local sem fio (WLAN,do inglês Wireless Local Area Network), sucessor do IEEE 802.11n, foi desenvolvido paramelhorar a experiência das WLANs aumentando sua vazão de dados. Ele foi desenvolvido entre2011 e 2013, tendo sido publicado em dezembro de 2013 pelo IEEE. Assim como os demais

Figura 2.3 Diagrama temporal de funcionamento do IEEE 802.11 PSM com seus intervalos entre bea-cons dividido em janela ATIM e a fase de comunicação. Fonte: [14]

protocolos da família, ele também é um protocolo baseado em contenção. Seu funcionamentoé baseado na Função de Coordenação Distribuída (DCF, do inglês Distributed CoordinationFunction), com o uso do CSMA/CA e incluindo a aplicação do mecanismo de RTS/CTS.

O padrão comercial anterior, o IEEE 802.11n [15], foi o primeiro a fazer uso do MIMO (doinglês Multiple Input and Multiple Output) na comunicação em WLANs. Ele especifica queos dispositivos da rede tenham até quatro antenas e possam utilizar a diversidade espacial, oconhecimento do estado do canal (CSI, do inglês channel state information) e a formação deraios direcionados (em inglês beamforming) [16] para aumentar a vazão da rede até 600MHz.

O IEEE 802.11ac, por sua vez, especifica que os dispositivos utilizem até oito antenas.Além disso, o protocolo utiliza até 24 canais de 10MHz, ou ainda pode combinar em canais de20MHz, 80MHz ou até 160MHz. É possível ainda utilizar uma constelação como a 256QAM(do inglês Quadrature Amplitude Modulation). Ele permite o uso do MU-MIMO (MIMO Mul-tiusuário, em inglês Multiuser MIMO), que torna possível que um dispositivo transmita dadospara vários outros num mesmo canal de frequência, o que é conhecido como um-para-muitos.A Figura 2.4 ilustra uma rede com infraestrutura realizando MU-MIMO. A vantagem do MU-MIMO é ainda mais perceptível em redes ad hoc, pois há uma maior homogeneidade de comu-nicação entre os dispositivos do que numa rede com um access point.

Figura 2.4 Ilustração de uma rede BSS com detecção multiusuário MIMO (MU-MIMO). Fonte: [17](Adaptada)

2.3.4 IEEE 802.11ax

O IEEE 802.11ax é o mais novo padrão comercial da família, sucessor do 802.11ac. Atu-almente o IEEE estima que o protocolo seja ratificado em junho de 2020 [18], apesar de jáexistirem dispositivos "pré-padrão"sendo fabricados. A Wi-Fi Alliance iniciou uma campanhapara que o padrão seja conhecido comercialmente como Wi-Fi 6. Este padrão estabelece ouso do Acesso Múltiplo por Divisão de Frequência Ortogonal (OFDMA, do inglês OrthogonalFrequency Division Multiplexing/Multiple Access), em que os canais de frequência são dividi-dos em múltiplos canais ortogonais, chamados de subcanais ou subportadoras. Outro desafioimportante do IEEE 802.11ax é permitir mais usuários conectados por access point principal-mente em redes densas. Para isto, o padrão define a Coloração de BSS Sobrepostas (OBSS, doinglês Overlapping Basic Service Set) [19], uma técnica em que é utilizado um número (cor)a nível de camada física para cada rede. Os dispositivos, identificando estas cores, decidemdinamicamente por considerar o canal livre, permitindo um maior reuso espacial.

2.4 Trabalhos relacionados

2.4.1 DCA - Protocolo de Atribuição Dinâmica de Canais

O protocolo DCA (do inglês Dynamic Channel Assignment) [20] especifica que haja um canalde controle dedicado e n canais de transmissão de dados. O objetivos é evitar a contenção noscanais de dados, a partir da reserva de canal. Para que o funcionamento seja possível, cadadispositivo deve estar equipado com dois transceptores half-duplex, um sintonizado no canalde controle e outro que trocará de canal dinamicamente de acordo com as negociações.

Figura 2.5 Diagrama temporal de funcionamento do protocolo DCA. Fonte: [21]

Quando um dispositivo possuir dados para transmitir, ele deve consultar em uma estruturade dados chamada CUL (do inglês Channel Usage List) se o destinatário já está envolvido emalguma transmissão e se há pelo menos um canal livre. Esta estrutura de dados é preenchida deacordo com a escuta de pacotes RTS/CTS realizadas no canal de controle. Caso o destinatárioesteja livre no momento e haja um canal disponível, é realizada a troca de RTS/CTS de formaidêntica ao IEEE 802.11. Quando o destinatário recebe o RTS, ele verifica sua CUL se háum canal livre. Se houver, o canal será utilizado. Se não houver, o CTS é respondido coma informação de outro canal e com o tempo restante para que o canal esteja livre. Durante anegociação, os outros dispositivos da rede atualizam suas estruturas de dados de acordo com asua escuta do canal de controle.

A Figura 2.5 ilustra o funcionamento do protocolo DCA. As transmissões são anunciadase negociadas no canal de controle, sendo feita a escolha de um canal. Em seguida, ocorre atransmissão de dados no canal correspondente, seguido de um pacote de reconhecimento.

É importante destacar que o número máximo de canais que o DCA consegue utilizar com-pletamente é igual a Td/Tc, em que Td e Tc são o tempo de transmissão de pacotes de dados ede controle respectivamente. Além disso, em casos de saturação da rede, a contenção no canalde controle pode causar a subutilização do canal de controle e uma solução para este problemaé aumentar o comprimento dos pacotes de dados [21].

2.4.2 MMAC - Protocolo MAC Multicanal

O protocolo MMAC (do inglês Multi-channel MAC) [22] foi um dos primeiros a solucionar oproblema do terminal escondido multicanal. No caso de dispositivos com apenas um transcep-tor half-duplex, não é possível monitorar mais de um canal ao mesmo tempo e escutar a troca depacotes RTS/CTS. Desta forma, caso nenhuma medida adicional fosse tomada, os dispositivosnão poderiam evitar as colisões decorrentes do problema do terminal escondido apenas usandoo CSMA/CA.

O MMAC define que a comunicação seja dividida em duas fases (split phase), assim comono IEEE 802.11 PSM, dentro de um intervalo entre beacons. Na primeira fase, a janela ATIM,todos os dispositivos que tenham dados em seus buffers para transmitir devem enviar pacotesATIM em um canal padrão predeterminado. No pacote ATIM deve ser incluída a Lista deCanais Preferenciais (PCL, do inglês Preferrable Channel List). O destinatário deve escolherum canal de acordo com a PCL do remetente e sua própria PCL. Um pacote ATIM-ACK éenviado de volta com o canal escolhido. Tendo o remetente escolhido o canal definido no

Figura 2.6 Diagrama temporal de funcionamento do protocolo MMAC. Fonte: [22]

ATIM-ACK, ele deve enviar um pacote ATIM-RES para que os dispositivos em sua vizinhançaatualizem suas PCLs. Este tipo de negociação é conhecida como negociação de três vias (eminglês three-way handshake).

Na fase seguinte, os dispositivos devem migrar para os canais definidos durante a fase an-terior e trocar pacotes RTS/CTS, pois outros dispositivos podem ter escolhido o mesmo canal.As estações que não tenham participado de negociações na fase anterior, pode entrar no DOZEmode durante a fase de comunicação, a fim de economizar energia, até o início do próximo in-tervalo entre beacons, quando devem voltar ao estado AWAKEN para participar das negociaçõesda nova janela ATIM.

Na Figura 2.6, durante a janela ATIM, um nó A possui dados em seu buffer para transmitira um nó B. Apenas o canal 1 é utilizado durante esta fase. É realizado o three-way handshakepara estabelecer a negociação, sendo o canal 1 o escolhido pelo nó B para a comunicação. Emseguida, os nós C e D negociam o canal 2 para comunicação. Na fase seguinte, os nós migrampara o canal selecionado, utilizam o mecanismo de detecção virtual de portadora na janela decomunicação a fim de evitar colisões com outros nós que possam ter escolhido o mesmo canale a transmissão de dados é realizada, sendo reconhecida com pacotes ACK.

Na avaliação de desempenho em seu trabalho original, o protocolo MMAC possui desem-penho superior ao IEEE 802.11 e um desempenho comparável a outros que utilizam mais deum transceptor.

2.4.3 H-MMAC - Protocolo MAC Multicanal Híbrido

O protocolo híbrido H-MMAC [23] (do inglês Hybrid Multi-channel MAC) foi criado como propósito de aproveitar a ociosidade dos canais de apenas comunicação durante a janelaATIM do MMAC para transmissão de dados. Em outras palavras, o protocolo permite que,em situações específicas, alguns nós continuem a transmitir dados durante a janela ATIM dointervalo entre beacons seguinte, enquanto os outros nós realizam o three-way handshake no

Figura 2.7 Diagrama temporal de funcionamento do protocolo H-MMAC. Fonte: [23]

canal principal.Os nós de uma rede com o protocolo H-MMAC são diferenciados entre os que estão re-

alizando negociações e os que estão realizando transmissões de dados na janela ATIM entreestes dois modos respectivamente: normal ou estendido. A Figura 2.7 ilustra estes modos detransmissão.

Os nós que estão no modo estendido podem continuar se comunicando durante a janelaATIM do intervalo entre beacons seguinte, ou até mesmo durante a janela de comunicação senão houverem outros nós que tenham reservado o mesmo canal. Assim como no MMAC, osnós não são capazes de monitorar mais de um canal de frequência ao mesmo tempo. Por isso,os nós que estiverem no modo estendido e tiverem seu canal de comunicação reservado poroutros nós deverão se abster de transmitir naquela janela de comunicação.

Para viabilizar a utilização do protocolo evitando o problema do terminal escondido, o H-MMAC define os seguintes estados:

• Normal: refere-se aos nós que estão trocando pacotes de controle na janela ATIM atual;

• Ongoing: refere-se aos nós que estão no modo estendido e estão participando de trans-missões de dados durante a janela ATIM atual;

• Limited: refere-se aos nós que possuem informações limitadas sobre os seus vizinho porestarem no modo ongoing na ultima janela ATIM;

• Unknown: refere-se aos nós aos quais não se tem informações.

Na realidade, um nó sempre estará nos estados Normal ou Ongoing, mas a sua percepçãosobre os seus vizinhos é que poderá assumir os outros estados. O protocolo H-MMAC mantémestas informações do estado dos seus vizinhos para determinar se eles estão aptos ou não parase comunicar. Tais informações são mantidas numa estrutura de dados chamada NIL (do inglêsNeighbor Information List), no qual também é registrado em que canal os seus vizinhos estãose comunicando.

Assim como no MMAC, cada nó mantém uma Lista de Canais Preferenciais (PCL, doinglês Preferrable Channel List), para a escolha dos melhores canais possíveis, de forma que aalocação de canais se dê de forma homogênea e maximize os uso dos recursos disponíveis.

Transmissões estendidas devem ser suspensas no início da janela de comunicação seguintepara manter a justiça e evitar a monopolização do canal.

Os autores indicam que o ganho de desempenho do protocolo ocorre quando a rede está emalto uso. Numa situação de baixa carga, é mostrado que o desempenho geral da rede piorariacom o uso das transmissões estendidas [23]. O protocolo é dito híbrido por considerar o estadoda rede, pois numa situação de baixa carga, as transmissões estendidas não ocorrem.

2.4.4 M2MMAC - Protocolo MAC Multicanal para Comunicação Muitos-para-Muitos

O Protocolo MAC Multicanal para Comunicação Muitos-para-Muitos M2MMAC [9] foi pro-posto para permitir a comunicação muitos-para-muitos, ou seja, a transmissão e recepção si-multânea de dados, se baseando no protocolo IEEE 802.11. O M2MMAC requer que os nós darede estejam equipados com um transmissor e um receptor, ambos simplex, que se configuremcomo um transceptor integrado capaz de receber dados em um canal e transmitir em múltiploscanais de frequência.

Assim como alguns dos protocolos discutidos neste trabalho, o M2MMAC também é umprotocolo Split Phase e utiliza duas fases durante um intervalo entre beacons. Neste protocolo,durante a fase de negociação (janela ATIM) cada nó que participe de uma negociação bemsucedida reserva para si um canal de recepção. A rede deve dispor de M canais de frequêncianão sobrepostos.

Como premissa do protocolo, os nós devem utilizar alguma técnica de sincronização out-of-band tal como GPS [9], [24], de forma que todos os nós da rede iniciem o intervalo entrebeacons no mesmo instante. Assume-se ainda que os nós da rede estão distantes o suficientepara evitar a correlação espacial de sinais, para permitir o uso da detecção de múltiplos usuários(MU-MIMO) [7], [9], [25]. Além disso, todo nó da rede consegue alcançar qualquer outro emseu raio de comunicação, o que caracteriza uma rede de salto único (single hop).

Os nós de uma rede M2MMAC precisam manter uma estrutura NAV (do inglês, NetworkAllocation Vector), de forma semelhante ao 802.11, porém modificada para indicar quais canaisestão reservados e quais não estão sendo utilizados. Este controle é necessário porque nesteprotocolo não é permitido que dois nós reservem o mesmo canal de frequência para recepção.

Além disso, o NAV registra a informação de quantos fluxos de comunicação aquele nó estácomprometido. Este controle é necessário por causa da limitação imposta pelo MU-MIMO,de que o número de fluxos de recepção é limitado pelo número de antenas, de forma queo receptor precisa de pelo menos B antenas para decodificar B− 1 sinais, desde que os nósestejam suficientemente distantes para evitar a correlação espacial. Os nós da rede atualizamseu NAV de acordo com os pacotes de controle trocados na rede. Ao final de um intervalo entrebeacons, o NAV deve ser limpo.

Durante a janela ATIM, o objetivo de cada nó que tenha dados em seu buffer para transmitiré estabelecer um par de fluxos, sendo um de recepção e outro de envio, garantindo uma comu-nicação bidirecional. O nó fonte deve transmitir um pacote ATIM no canal padrão preestabele-cido. Por sua vez, o nó destinatário deve verificar em seu NAV a possibilidade de estabelecermais um fluxo de transmissão para a próxima fase. Caso positivo, ele deve responder com umpacote ATIM-ACK informando o canal de recepção escolhido e o número de pacotes que eleeventualmente tenha para transmitir ao nó fonte. Caso não seja possível comportar mais aquele

Figura 2.8 Três nós S, D e E realizam transmissão e recepção simultânea de pacotes em uma redemuitos-para-muitos. Fonte: [9]

fluxo, o nó poderá responder com um pacote ATIM-NACK, informando desta impossibilidadee alertando aos outros nós da rede sobre esta liberação de canal. Por outro lado, outra aborda-gem é o uso de temporizadores que limitariam o tempo de aguardo pelo ATIM-ACK, evitandoo uso do ATIM-ACK e evitando o consumo de energia pelo rádio.

Uma troca de pacotes ATIM e ATIM-ACK indica uma negociação bem sucedida, que houveuma reserva de fluxos bidirecionais, que aqueles nós poderão transmitir dados entre si na fasede comunicação de forma exclusiva, incluindo os pacotes de reconhecimento ACK. O protocoloexige que nunca seja realizada uma negociação de apenas um fluxo, pois ainda que um nó sótenha dados a receber, ele precisará enviar pacotes de reconhecimento ACK.

No M2MMAC, os nós da rede que porventura não tenham participado de nenhuma comu-nicação bem sucedida na janela ATIM devem se abster de transmitir durante a fase seguinte decomunicação, tal como o IEEE 802.11 PSM. Eles podem então entrar no DOZE mode a fim deeconomizar energia.

A Figura 2.8 ilustra três nós S, D e E durante a janela de comunicação realizando a co-municação muitos-para-muitos. Cada dispositivo recebe B− 1 fluxos com suas B antenas derecepção, enquanto transmite dados para os outros dois nós em seus respectivos canais de re-cepção, usando sua única antena de transmissão, tal como a detecção multiusuário MU-MIMOestabelece.

A Figura 2.9 corresponde ao diagrama temporal para estes três nós S, D e E durante a janelaATIM, quando ocorre três negociações com sucesso com a troca de pacotes ATIM e ATIM-ACK. No exemplo da figura foi considerado o uso de temporizadores, dispensando o uso depacotes ATIM-NACK. Na fase seguinte, na janela de comunicação, ocorre a transmissão dedados e de pacotes de reconhecimento ACK. É importante observar que não há espera para oinício de uma transmissão de dados na janela de comunicação, pois no caso do canal ideal,

Figura 2.9 Diagrama temporal de funcionamento do protocolo M2MMMAC, representado por um in-tervalo entre beacons, dividido em janela de negociação e de comunicação. Fonte: [9]

como cada canal foi previamente reservado, não deve ocorrer colisão de dados.As Figuras 2.10 e 2.11 apresentam o fluxograma dos eventos que acontecem num transmis-

sor e num receptor, respectivamente, durante um intervalo entre beacons.

2.4.5 H-M2MMAC - Protocolo MAC Multicanal Híbrido para ComunicaçãoMuitos-para-Muitos

O Protocolo MAC Multicanal Híbrido para Comunicação Muitos-para-Muitos (H-M2MMAC)[10] foi desenvolvido com o objetivo de integrar a abordagem híbrida do H-MMAC com aabordagem muitos-para-muitos do M2MMAC. Em outras palavras, ele permite que os disposi-tivos de uma rede que estavam transmitindo dados continuem se comunicando durante a janelaATIM subsequente.

O H-M2MMAC possui requisitos semelhantes ao M2MMAC, que são o uso de algum me-canismo de sincronização de beacons de forma out-of-band (por exemplo, GPS [24]), conhe-cimento do estado dos canais, nós distantes o suficiente para que não haja correlação espacialdevido ao uso do MU-MIMO, uso de um transceptor integrado constituído de um receptor ca-paz de receber em um único canal utilizando B antenas e um transmissor capaz de transmitirem múltiplos canais.

Além disso, o protocolo foi projetado para redes single hop. Desta forma, todos os nósdevem estar próximos o suficiente entre si para que a comunicação possa sempre ser realizadaem um salto. Supõe-se ainda que há M canais de frequência ortogonais não sobrepostos.

O protocolo define dois modos em que as estações podem estar transmitindo. No modode transmissão normal (N-Tx), o fluxo segue de forma normal, igual ao M2MMAC, com atransmissão ocorrendo apenas durante a janela de comunicação. No modo estendido (E-Tx)estão os nós que podem se comunicar durante a janela de negociação seguinte.

O protocolo ainda limita que a extensão da comunicação só ocorra na janela de comuni-cação do segundo intervalo entre beacons se nenhum outro nó da rede tiver reservado aquele

Figura 2.10 Fluxograma de um intervalo entre beacons de decisões e ações realizadas pelo transmissorexecutando o M2MMAC. Fonte: [9]

Figura 2.11 Fluxograma de um intervalo entre beacons de decisões e ações realizadas pelo receptorexecutando o M2MMAC. Fonte: [9]

Figura 2.12 Exemplo de dois intervalos entre beacons de uma rede executando o protocolo H-M2MMAC. Fonte: [10]

canal. Por isso, é possível que aquele par de nós fique sem poder transmitir até o intervalo entrebeacons seguinte. Com isso, o desempenho da rede cai, por reduzir a vazão da rede e geraratrasos. É mostrado em [10], [21], [23] que em caso de alto tráfego ou saturação da rede aabordagem estendida obtém seus melhores resultados, superando o desempenho do modo nor-mal. Por isso, o H-M2MMAC foi desenvolvido para escolher dinamicamente entre os modosN-Tx e E-Tx.

A Figura 2.12 ilustra o funcionamento de uma rede que executa o protocolo H-M2MMACdurante dois intervalos entre beacons. Para monitorar o canal e definir se é possível continuaruma comunicação durante a janela de comunicação, os dois nós devem monitorar os dois ca-nais que estavam utilizando até então, para evitar colisões desnecessárias. O tempo mínimode monitoramento do H-MMAC deve ser (Tchannel_switching +DIFS+CWmin ×Slot_time) [23].O H-M2MMAC também prevê esta possibilidade e que este seja o tempo mínimo de moni-toramento para cada canal em seu trabalho original [10]. Porém, como são realizadas duastrocas de canais, este tempo total será o dobro. Além disso, como é considerado que a redeestá em condições ideais, ou seja, a rede utiliza canais não sobrepostos e ortogonais de formaque não há interferências, CWmin pode ser reduzido a zero. Desta forma, o tempo mínimo demonitoramento dos canais é 2× (Tchannel_switching +DIFS).

A decisão pelo modo de transmissão normal ou estendido ocorre durante a fase de negocia-ção. Quando um nó inicia a negociação, ele seleciona o modo estendido sempre que o númerode tentativas de retransmissão é superior ao limiar E-Tx_Retry_Threshold. O segundo critériopara a seleção do modo E-Tx é quando o número de pacotes no buffer de um nó for superiorao número de intervalos lslot dentro da janela de comunicação. lslot é o tempo para transmissãodo maior pacote de dados possível mais o tempo de transmissão do pacote de reconhecimento

ACK. Esta escolha é enviada dentro do pacote ATIM.Mesmo que um nó tenha iniciado uma transmissão solicitando uma comunicação normal,

é possível que o nó destinatário solicite que aquela negociação se concretize como uma comu-nicação estendida. Isso acontecerá quando o número de pacotes em seu buffer for superior aonúmero de intervalos lslot dentro de uma janela de comunicação.

Assim como no M2MMAC, no H-M2MMAC os nós devem manter uma estrutura de dadosNAV, um vetor que indicará o conhecimento do estado dos canais. Como cada canal é efetiva-mente reservado, o NAV deve indicar quais canais estão ocupados. Além disso, o NAV deveregistrar em qual canal aquele nó estará sintonizado. Devido a limitação imposta pelo númerode antenas, o NAV deve ainda armazenar em quantos fluxos de recepção aquele dispositivo es-tará envolvido. O NAV ainda registra a frequência para envio dos pacotes ACK e a quantidadede pacotes a ser recebidos. Por fim, o NAV registra o endereço do nó a ser inserido nos pacotesATIM.

A outra estrutura de dados utilizada pelo H-M2MMAC em cada nó é o NIL (do inglêsNeighbor Information List), que registra informações dos vizinhos, tais como endereço, canalde frequência de recepção e classificação.

Assim como no H-MMAC, os nós são classificados em Normal, Ongoing, Limited e Unk-nown. De acordo com o tipo de transmissão N-Tx ou E-Tx as estações são classificadas emNormal ou Ongoing respectivamente. No momento quem que se encerra uma janela ATIM, osnós que estavam transmitindo dados no modo E-Tx não têm informações sobre seus vizinhos,logo ele deve classificá-los como Unknown. Da mesma forma, estes nós serão classificadospelos seus vizinho como Limited, por não terem participado da fase de negociação.

As Figuras 2.13 e 2.14 apresentam o fluxograma dos eventos que acontecem num transmis-sor e num receptor, respectivamente, durante um intervalo entre beacons.

2.5 Conclusão do Capítulo

Este capítulo revisou a comunicação muitos-para-muitos, capaz de aumentar o desempenho dasredes sem fio, que é a motivação dos protocolos estudados neste trabalho. Foi apresentado oprotocolo IEEE 802.11, seu modo de economia de energia e algumas de suas versões comerci-ais. Foi explicado o protocolo DCA, que foi umas das primeiras abordagens multicanal, moti-vadora dos protocolos MMAC e H-MMAC. Por fim, foram revistos os protocolos M2MMACe H-M2MMAC, que foram pioneiros por representar uma técnica muitos-para-muitos, sendo osegundo uma abordagem híbrida, ambos baseados no IEEE 802.11.

A Tabela 2.1 apresenta uma comparação das principais características dos protocolos mul-ticanais e muitos-para-muitos apresentados neste capítulo.

Figura 2.13 Fluxograma de um intervalo entre beacons de decisões e ações realizadas pelo transmissorexecutando o H-M2MMAC. Fonte: [10]

Figura 2.14 Fluxograma de um intervalo entre beacons de decisões e ações realizadas pelo receptorexecutando o H-M2MMAC. Fonte: [10]

Tabela 2.1 Comparativo entre os protocolos MAC multicanais

DCA MMAC H-MMAC M2MMACH-

M2MMAC

Multicanal Sim Sim Sim Sim SimMuitos-para-Muitos

Não Não Não Sim Sim

Quantidadede transcep-tores

2 half-dup. 1 half-dup. 1 half-dup.

1 receptor e1 transm.(ambossimplex)

1 receptor e1 transm.(ambossimplex)

Canal decontroleexclusivo

Sim Não Não Não Não

Split phase Não Sim Sim Sim SimPermitetransmitirdados du-rante janelaATIM

Não possuijanela ATIM

Não Sim Não Sim

Reserva decanal

Sim Não Não Sim Sim

CAPÍTULO 3

Simulação do Protocolo M2MMAC

3.1 Introdução

Em [9], foi desenvolvido um modelo matemático para avaliar a vazão agregada de saturação darede e foi construída uma simulação computacional para validar o modelo, utilizando o simu-lador de rede Network Simulator 3 (NS-3) [26]. No entanto, é possível observar que essa simu-lação anteriormente proposta carece de algumas restrições previstas pelo protocolo M2MMACdurante a janela ATIM, relativas à não consideração de que os nós da rede devem parar de tentarnegociar ao não poder comportar mais fluxos de comunicação, seja por limitação no número decanais ou antenas, ou mesmo para não negociar duas vezes com um mesmo nó com o qual jáo tenha feito com sucesso. Neste capítulo é apresentada uma nova proposta de simulação pararefletir melhor as restrições do protocolo M2MMAC e reavaliar seu desempenho.

Nas seções seguintes é apresentada a arquitetura da simulação e as modificações realizadasem relação à simulação original de Ghobad. São verificados o número de negociações e a vazãode saturação da rede, que são indicadores do seu desempenho. Os resultados são comparadoscom os resultados anteriores de Ghobad.

3.2 Arquitetura da Simulação

Ghobad [9] disponibiliza sua simulação em detalhes no seu trabalho, com as modificações queforam feitas no simulador de rede Network Simulator 3 (NS-3). Estes códigos foram usadoscomo base para a nova proposta de simulação. A simulação representa um intervalo entre be-acons dividido em duas partes, a janela ATIM e a janela de comunicação. Os dispositivos sãoposicionados aleatoriamente em um plano quadrado utilizando a distribuição uniforme, perma-necendo fixos durante toda a simulação. A simulação corresponde a um estado de saturação,quando as filas (buffers) de dados a serem transmitidos de todos os dispositivos da rede semprepossuem dados para se enviar.

Durante a primeira fase, a janela ATIM, os nós da rede trocam continuamente pacotes ATIMe ATIM-ACK a fim de reservar fluxos de comunicação entre si. A troca com sucesso de pacotesATIM e ATIM-ACK entre dois nós representa uma negociação bem-sucedida. A quantidadede negociações bem sucedidas é um parâmetro de entrada para a fase seguinte, a janela decomunicação.

Na nova simulação proposta neste trabalho, os nós da rede ficarão impedidos de realizaruma negociação sempre que um dos eventos abaixo ocorrer:

• Se dois nós já negociaram com sucesso durante a janela ATIM, eles ficarão impedidos de

24

Tabela 3.1 Parâmetros e valores utilizados na simulação do protocolo M2MMAC. Fonte: [9]

Parâmetro Valor

Número de Nós (C) 60Antenas de Recepção (B) 3Canais Disponíveis (M) 24Taxa de Transmissão (R) 2MbpsIntervalo entre Beacons (lbeacon) 100msJanela ATIM (latim) 20msAtraso de Propagação (δ ) 1µsPacote de Dados (DATA) 512BytesCabeçalho MAC 34BytesCabeçalho PHY 24BytesPacote ACK 304bitsPacote RTS 352bitsPacote CTS 304bitsSlot de Tempo (σ ) 20µsShort Interframe Space (SIFS) 10µsDCF Interframe Space (DIFS) 50µsÁrea da rede (A) 250m2

enviar outro pacote ATIM para tentar negociar entre si novamente;

• Quando não houver mais canais de frequência disponíveis e um dos nós participantesdaquela negociação ainda não houver reservado um canal de recepção;

• Quando um dos nós participantes da negociação já estiver comprometido com B − 1negociações bem sucedidas, sendo B igual ao número de antenas, limitação imposta peloMIMO;

Estas restrições não ocorriam na simulação original de Ghobad. Nela, os nós tentavam rea-lizar negociações ininterruptamente até o final da janela ATIM, mesmo que não fosse possívelreservar novos fluxos de comunicação. A nova simulação proposta, por sua vez, leva em consi-deração estas interrupções nas negociações por parte dos nós que já atingiram seu limite. Com aredução no número de nós disputando o canal durante a janela ATIM, há também uma alteraçãona carga da rede nesta fase, por isso denominamos esta nova simulação de DCF refinado.

É considerado que a camada física (PHY) é ideal, por simplicidade, o que significa que elaé sempre capaz de fazer aquilo a que se dispõe, como a detecção de múltiplos usuários MIMOe a multiplexação nos canais de frequência.

A Tabela 3.1 apresenta os parâmetros e valores utilizados nas simulações, exceto quandoespecificado, e corresponde aos valores padrão do IEEE 802.11b, pois nas simulações a janelaATIM é implementada como uma rede 802.11b, assim como cada fluxo durante a janela decomunicação é implementado como uma rede 802.11b, como forma de replicar o MU-MIMO

em condições físicas ideais. Os resultados são obtidos através da médias de 20 rodadas desimulação e são apresentados com um intervalo t-student de 99% de confiança.

O desempenho do protocolo é avaliado no trabalho de Ghobad [9] em função do númerode nós na rede, do número de canais, do número de antenas e do tamanho da janela ATIM. Elecompara o desempenho da rede durante a janela ATIM com alguns modelos teóricos do IEEE802.11 DCF, sendo o de Tinnirello [27] o que mais se aproximou de seus resultados, devido aosseus refinamentos. No entanto, a janela ATIM do protocolo H-M2MMAC difere da situação doDCF em uma rede saturada comum, pois alguns nós podem ficar impedidos de enviar pacotesATIM. Este impedimento acontece quando o número de antenas é insuficiente para que aquelenó comporte mais fluxos de recepção. Outra limitação é quando há mais nós participando denegociações bem sucedidas do que canais disponíveis, impossibilitando que qualquer outro nópossa reservar mais um canal de frequência para si.

3.3 Quantidade de Negociações

Na Figura 3.1, a vazão agregada de saturação é obtida do modelo de simulação original deGhobad [9] e da nova simulação DCF refinado, com o número de nós variando de 3 a 24. Estaescolha do limite no número de nós é feita para que ele seja inferior ao número de canais doIEEE 802.11ac, que especifica até 24 canais de frequência não sobrepostos de 20MHz na faixanão licenciada de 5GHz [5], [28]. Foram considerados dois casos para a simulação de Ghobad:o caso que chamamos de saturado, em que todos os nós tentam negociar com todos os outrosnós mesmo que já tenham realizado uma negociação bem sucedida, situação que permite acomparação com o modelo matemático do DCF de Tinnirello; e o caso normal, em que cadanó de um par de nós apenas possui um pacote ATIM para enviar entre si.

Na simulação normal de Ghobad quando um nó A negocia com sucesso com um nó B,o nó B ainda pode tentar negociar com o nó A, segundo o código em anexo no seu trabalhooriginal. Na Figura 3.1, a curva da simulação normal tende rapidamente à curva da simulaçãocom saturação, por isso consideraremos apenas a simulação normal neste trabalho.

Quanto ao DCF refinado, que corresponde a um conjunto de restrições que mais se aproxi-mam do protocolo M2MMAC, é possível perceber que o número de negociações bem-sucedidasé inferior ao da simulação de Ghobad. A restrição causada pelo número de antenas não foi con-siderada por Ghobad e observa-se, pelo gráfico, que há uma redução expressiva no número denegociações realizadas com sucesso no DCF refinado. No DCF refinado com 20ms de janelaATIM e B = 5 antenas é possível verificar que ocorre uma tendência à saturação próxima àcurva da simulação de Ghobad nas mesmas condições, causada pelo efeito da duração da ja-nela ATIM. Esta observação fica mais evidente quando comparamos apenas as simulações doDCF refinado com B = 5.

3.4 Vazão Agregada de Saturação

A vazão agregada de saturação é a velocidade média do tráfego de dados úteis da rede durantea janela de comunicação. Ela é a razão entre a quantidade de dados úteis que trafega na rede e

3 6 9 12 15 18 21 24

Número de nós (C)

0

10

20

30

40

50

60

70

80

90

Quantidade d

e n

egocia

ções b

em

sucedid

as n

a jan

ela

AT

IM

Simulação de Ghobad com saturação (40ms)

Simulação de Ghobad (40ms)

Simulação de Ghobad com saturação (20ms)

Simulação de Ghobad (20ms)

Simulação DCF refinado (40ms, B=5)




Figura 3.1 Número de negociações bem sucedidas durante Janela ATIM de 20ms e 40ms e B=3 e B=5antenas de recepção, para o modelo de simulação de Ghobad e a nova simulação DCF refinado.

3 6 9 12 15 18 21 24

Número de nós (C)

0

10

20

30

40

50

60

70

80

90

100

110

120

130

Vazão a

gre

gada d

e s

atu

ração (

Mbps)

Simulação de Ghobad (ATIM=20ms, B=5)




Simulação DCF refinado (ATIM=20ms, B=5)




Figura 3.2 Vazão agregada de saturação obtida da simulação de Ghobad e da simulação DCF refinadoem função do número de nós participantes da rede (C) para diferentes durações da Janela ATIM equantidades de antenas de recepção (B).

o tempo transcorrido. A figura 3.2 apresenta a vazão agregada de simulação como resultado dasimulação descrita por Ghobad e a nova simulação proposta.

Como esperado, nos casos em que houve maior número de negociações bem-sucedidas,houve também uma maior vazão agregada de saturação. A simulação de Ghobad se comportoucomo um limite superior ao DCF refinado, cujo desempenho foi limitado pelo menor númerode negociações estabelecidas, por possuir mais restrições que o aproximou mais do protocoloM2MMAC.

Apesar de Ghobad não ter considerado o número de antenas durante a janela ATIM, eleconsidera esta restrição durante a janela de comunicação. Desta forma, os casos com 5 antenaspossuem um desempenho melhor que os casos com 3 antenas.

Observando a curva da simulação do DCF refinado com a janela ATIM de 20ms e B = 5antenas, verificamos que a janela ATIM reduzida foi incapaz de fornecer, sob as novas restri-ções, o maior desempenho que a rede poderia oferecer, como obtido na simulação de Ghobadnas mesmas condições.

Tendo em vista estes resultados, vimos que a simulação de Ghobad se comporta como umlimite superior do desempenho real do protocolo M2MMAC. A forma como os nós da redenegociam varia de acordo com o número de antenas e com a duração da janela ATIM. A nova

simulação DCF refinado mostra que o número de negociações bem-sucedidas influencia muitona vazão agregada de saturação da rede e consequentemente no seu desempenho, de formaque, com o aumento do número de nós, é necessário considerar aqueles parâmetros ao buscaro melhor desempenho da rede. Não foi realizada uma comparação com o modelo de Tinirelloporque ele carece das mesmas restrições que a simulação do protocolo M2MMAC de Ghobade gera resultados muito próximos deste último.


Este capítulo revisou a simulação de Ghobad e apresentou uma nova proposta de simulaçãodo protocolo M2MMAC, indicando as restrições na janela ATIM necessárias para que a novasimulação seja mais fiel ao protocolo M2MMAC que a simulação anterior. Os resultados in-dicaram uma redução expressiva no número de negociações bem-sucedidas durante a janelaATIM, mas com tendência a se aproximar das curvas da simulação de Ghobad com o aumentodo número de nós, sendo este um limite superior devido à duração da janela ATIM. Na fasede comunicação, verificou-se uma redução na vazão agregada de saturação em todas as simu-lações. Observou-se ainda uma tendência de saturação no caso da janela ATIM com 20ms e 5antenas de recepção, indicando que o tamanho da janela ATIM influencia no desempenho darede.

CAPÍTULO 4

Simulação do Protocolo H-M2MMAC

4.1 Introdução

Adauto [10] propôs em seu trabalho o protocolo H-M2MMAC, uma abordagem híbrida doprotocolo muitos-para-muitos ad hoc M2MMAC. Ele desenvolveu um modelo matemáticopara comparar o desempenho do protocolo em relação a outros protocolos MAC, como oM2MMAC, o H-MMAC, o MMAC, o TMMAC [29] e o IEEE 802.11.

Para validar o modelo matemático, é importante que seja desenvolvida uma simulação com-putacional. Desta forma, utilizamos o simulador de rede Network Simulator 3 (NS-3) [26]

Nas seções seguintes é descrita a arquitetura da simulação e sua metodologia e são apre-sentados e discutidos os resultados, sendo feita uma comparação entre o M2MMAC e o H-M2MMAC.

4.2 Arquitetura da Simulação

Adauto [10] especifica duas condições que, quando ambas são atendidas, um nó escolherá omodo de transmissão estendida (E-Tx). Estas condições são:

• Quando o número de colisões na fase de negociação supera o valor E-Tx_Retry_Threshold;

• Quando o número de pacotes no buffer de um dos nós que participa da negociação ésuperior ao número de intervalos lslot dentro de uma janela de comunicação.

A intenção da segunda condição é garantir que um par de nós não estabeleça um par defluxos E-Tx desnecessariamente, quando não houver dados suficientes para transmitir durantea janela ATIM seguinte. Na simulação proposta neste trabalho, consideramos a situação desaturação da rede, quando sempre há dados a ser transmitidos entre todos os nós. Por isso, porsimplicidade, consideraremos que esta condição sempre estará atendida.

O protocolo H-M2MMAC especifica que o uso de pacotes ATIM-NACK, que é uma res-posta negativa dada pelos nós que não são capazes de comportar mais fluxos, é opcional e podeser substituída pelo uso de temporizadores [10]. Porém, a abordagem com temporizadorespode ser precipitada, pois um nó que envia um pacote ATIM e não obtêm uma resposta nãotem como saber se houve uma colisão ou se o nó destinatário apenas não podia mais aceitarnegociações. Como o número de colisões faz parte da primeira condição para se escolher omodo E-Tx, o modo estendido pode ser escolhido de forma precoce.

A contagem de colisões pode ser feita de forma individual, com cada nó contando suastentativas de retransmissão; ou global para a toda a rede, com todos os nós ouvindo a rede

30

durante a janela ATIM. O protocolo não especifica de qual forma isto deve acontecer. Para finsde simplificação, utilizaremos um contador global para todos os nós.

Dang [23] especifica para o H-MMAC, protocolo em que o H-M2MMAC também se ba-seia, o valor de E-Tx_Retry_Threshold = 4 na avaliação de desempenho do seu protocolo eutilizaremos o mesmo valor aqui.

Não fica claro no protocolo H-M2MMAC em que momento a contagem de colisões é rei-niciada. A possibilidade mais razoável é que o reinício ocorra ao início de cada intervalo entrebeacons e utilizaremos nesta simulação.

A escolha de canais é realizada de forma aleatória com base no registro de utilização de cadacanal. Uma transmissão que foi negociada no canal padrão obrigatoriamente será do tipo N-Tx.Assim como fizemos na simulação do protocolo M2MMAC, consideraremos que o número decanais sempre sera maior ou igual ao número de nós na rede. Desta forma, sempre haverá umcanal de frequência livre para ser reservado para recepção pelos nós.

A simulação representa dois intervalos entre beacons consecutivos. Na primeira janelaATIM, os nós tentam negociar normalmente e o número de colisões é monitorado. O númerode negociações realizadas com sucesso após o limiar E-Tx_Retry_Threshold ser atingido ésegregado do número de negociações antes do limiar ser atingido. Para fins de simplificação,foi escolhida uma quantidade de nós para estar no modo N-Tx proporcional ao número denegociações N-Tx, e o restante dos nós para o modo E-Tx durante este primeiro intervalo entrebeacons.

No segundo intervalo entre beacons, apenas os nós que estavam no modo normal (N-Tx)participam da fase de negociação, enquanto os outros nós, que estão no modo ongoing, con-tinuam transmitindo até o final da janela de comunicação. Essa decisão foi tomada devido àpremissa que o número de canais disponíveis era sempre menor ou igual ao número de nós narede.

Os nós que escolherem o modo estendido no segundo intervalo entre beacons foram defi-nidos para transmitir até o fim da janela ATIM do terceiro intervalo entre beacons, tendo estetempo de duração adicional descontado dos cálculos do resultado, como forma de compensar ofato do primeiro intervalo entre beacons não possuir transmissões de dados em andamento nasua janela ATIM.

No terceiro intervalo entre beacons só são simuladas as transmissões de dados que esco-lheram o modo estendido na janela ATIM anterior, até o fim da janela ATIM, não havendonenhuma negociação. Isto equivale a uma situação de finalização da simulação em que os buf-fers de todos os nós são esvaziados ao fim do segundo intervalo entre beacons, sendo mantidosapenas os pacotes dos nós que já seriam transmitidos até o fim da janela ATIM do terceirointervalo entre beacons.

Todos os parâmetros e valores não especificados aqui foram configurados de acordo com aTabela 3.1, e corresponde aos valores padrão do IEEE 802.11b. Também é considerada umacamada física (PHY) é ideal. Os resultados são obtidos através da médias de 20 rodadas desimulação e são apresentados com um intervalo t-student de 99% de confiança.

O número de negociações na janela ATIM não foi comparado com o M2MMAC, pois onúmero de nós que participam desta fase é variável e sua comparação com outros protocolosnão teria sentido prático.

3 6 9 12 15 18 21 24

Número de Nós (C)

0

10

20

30

40

50

60

70

80

90

100

110

Va

zã

o a

gre

ga

da

de

sa

tura

çã

o (

Mb

ps)

Modelo H-M2MMAC (ATIM=20ms, B=5)




Simulação H-M2MMAC (ATIM=20ms, B=5)




Figura 4.1 Comparação da vazão agregada de saturação do protocolo H-M2MMAC entre o modelo deAdauto e a simulação, em função do número de nós participantes da rede (C) para diferentes duraçõesda Janela ATIM e quantidades de antenas de recepção (B).

4.3 Vazão Agregada de Saturação

Adauto [10] descreve um modelo matemático para cálculo da vazão de saturação. Os resultadosdo seu modelo matemático são comparados com a simulação proposta neste trabalho. A Figura4.1 apresenta a vazão agregada de saturação do protocolo H-M2MMAC.

O modelo matemático do H-M2MMAC, assim como no M2MMAC, também não leva emconsideração alguns fenômenos do protocolo que acontecem durante a janela ATIM, quandoalguns nós se abstêm de negociar novos fluxos assim que não podem mais comportar estescompromissos.

A simulação se assemelha ao modelo quanto à duração da janela ATIM, que tanto com20ms quanto com 40ms de duração apresentam resultados próximos, exceto na simulação com5 antenas a partir de 15 nós, em que a janela ATIM de 20ms parece atingir sua saturação e aescolha pela janela ATIM de 40ms se sobressai. Adauto mostra em seu trabalho original queeste fenômeno também ocorre no modelo a partir de 30 nós.

Na simulação, como esperado, com um pequeno número de nós competindo na janelaATIM, o desempenho da rede é melhor quando reduzimos esta janela e resta mais tempo para

3 6 9 12 15 18 21 24

Número de nós (C)

0

10

20

30

40

50

60

70

80

90

100

110

120

Vazão a

gre

gad

a d

e s

atu

ração (

Mbps)





Simulação M2MMAC (ATIM=20ms, B=5)




Figura 4.2 Vazão agregada de saturação dos protocolos M2MMAC e H-M2MMAC, simulados em fun-ção do número de nós participantes da rede (C) para diferentes durações da Janela ATIM e quantidadesde antenas de recepção (B).

transmitir dados. Por outro lado, com o aumento no número de nós a duração da janela ATIMpassa a necessitar de mais tempo para que mais negociações bem-sucedidas sejam realizadas,fazendo com que a janela ATIM de 40ms apresente melhores resultados.

A Figura 4.2 compara o desempenho dos protocolos H-M2MMAC e M2MMAC. As curvasdo protocolo híbrido apresentam desvantagem ou empate quando há poucos nós na rede, masapresentam melhor desempenho com o aumento do número de nós, o que mostra a vantagemdo uso do protocolo híbrido com o aumento da carga da rede.

Novamente a escolha da duração da janela ATIM se mostra importante para os dois pro-tocolos. Observando as simulações com B = 5 antenas de recepção, a escolha por uma janelaATIM de 20ms limita o número de negociações de forma que satura e até reduz o desempenhopotencial da rede com o aumento no número de dispositivos.

A duração da janela ATIM está relacionada ao número de estações na rede (C), de canaisde frequência (M) e de antenas de recepção disponíveis (B), sendo necessário analisar seu valorideal caso a caso.


Este capítulo apresentou uma proposta de simulação do protocolo H-M2MMAC. Foram des-critas algumas simplificações na metodologia da simulação. Os resultados foram comparadoscom o modelo matemático apresentado por Adauto, mostrando divergências nos resultados,em que não foi possível concluir outros motivos, além dos problemas das premissas do modelomatemático, que se baseou no mesmo modelo do M2MMAC e as novas premissas e correçõesda nova simulação. Apesar das diferenças, ambos evidenciam que a duração da janela ATIMpassa a suprimir o potencial de desempenho do protocolo com o aumento no número de nósna rede. A simulação do protocolo H-M2MMAC também foi comparada com a simulaçãodo H-M2MMAC. Os resultados mostram a vantagem de se utilizar o protocolo híbrido com oaumento da carga da rede.

CAPÍTULO 5

Conclusões

Foram apresentadas neste trabalho novas propostas de simulação dos protocolos muitos-para-muitos M2MMAC e H-M2MMAC, ambos promissores por permitirem o aumento da vazãodas redes de fio ad hoc, a redução do atraso fim-a-fim e utilizarem o mecanismo de economiade energia do protocolo IEEE 802.11 PSM. Também foram revisados alguns protocolos multi-canais antecessores que serviram como base para os protocolos muitos-para-muitos estudadosaqui. Foram revisados ainda alguns dos Padrões IEEE 802.11 como a Função de Coordena-ção Distribuída, e os padrões 802.11ac e 802.11ax, que possibilitam às estações a detecção demúltiplos usuários MIMO.

A simulação aqui proposta do protocolo M2MMAC leva em consideração que, durantea janela ATIM, os nós que não podem mais comportar fluxos de recepção, por limitação nonúmero de antenas, número de canais, ou mesmo por já terem negociado com sucesso antes,devem se abster de tentar realizar novas negociações. Esta consideração nos mostra resultadosmais próximos ao comportamento real do protocolo que o modelo matemático e a simulaçãopreviamente utilizadas no trabalho original que especifica o protocolo. Os resultados mostraramresultados inferiores ao que se conhecia anteriormente por considerar as limitações da realidadeprática.

A simulação do protocolo H-M2MMAC foi proposta com algumas considerações em suaimplementação descritas no capítulo 3, devido a definições que não ficaram claras na propostaoriginal sobre o comportamento na janela ATIM e a escolha entre os modos normal ou esten-dido. Os resultados das simulações confirmam a melhora no desempenho do protocolo quandopresente em uma rede com alta carga.

Adicionalmente, foi verificada a necessidade de adaptar a duração da janela ATIM deacordo com o número de dispositivos na rede, com o número de antenas e com o númerode canais de recepção. Uma escolha incorreta desta duração pode limitar o desempenho darede, desperdiçando recursos. Em especial, a mudança de 3 para 5 antenas de recepção emcada dispositivo indicava de forma clara a necessidade por períodos maiores de negociação.

5.1 Trabalhos Futuros

Como trabalhos futuros, percebemos a necessidade de um método que adapte o tamanho dajanela ATIM de forma dinâmica, que considere a carga e os recursos da rede para atingir umequilíbrio entre uma quantidade de negociações suficiente e tempo suficiente para transmissãode dados.

Sugere-se que seja feita uma investigação mais profunda da relação entre os modelos mate-

35

máticos utilizados nos trabalhos de Ghobad e Adauto, baseados no modelo de Tinnirello, queconsideram uma janela ATIM saturada, cujos nós trocam pacotes ATIM sem restrições, e asrestrições reais dos protocolos, que passam a ser consideradas neste trabalho.

É necessária ainda uma investigação destes protocolos em estados de não-saturação, emuma comparação com aos outros protocolos para redes ad hoc predecessores. Sugere-se tam-bém a análise do consumo de energia dos dispositivos da rede.

Finalmente, sugere-se que sejam feitas novas simulações que considerem os desafios exis-tentes na camada física (PHY), ao invés de um modelo ideal. Uma sugestão adicional é o usode transceptores full duplex, capazes de transmitir e receber dados numa mesma frequência aomesmo tempo.

APÊNDICE A

Simulação em Detalhes

A simulação computacional foi realizada no simulador de rede Network Simulator 3 (NS-3),versão 3.26, utilizando uma máquina virtual com o sistema operacional Ubuntu 16.04.5 LTS.Como os protocolos M2MMAC e H-M2MMAC são Split Phase, a simulação foi dividida emduas partes. A primeira parte é a janela ATIM, em que ocorre a troca de pacotes ATIM eATIM-ACK. A quantidade de negociações bem-sucedidas nesta fase é utilizada como entradana janela de comunicação, fase em que ocorre a troca de pacote de dados úteis.

As simulações deste trabalho são baseadas na simulação do M2MMAC feita por Ghobadem [9]. Ele considerou um estado de saturação, quando todos os nós da rede possuem dados emseus buffers para enviar a todos os outros. No entanto, esta consideração pode gerar resultadosimprecisos, pois durante a janela ATIM, alguns nós podem atingir um limite de negociações eficarem impossibilitados de reservar novos fluxos para a fase seguinte. Este limite ocorre sem-pre que não há mais canais disponíveis para reservar, quando o número de fluxos de recepçãoque um nó já se comprometeu é igual a B− 1, sendo B o número de antenas de recepção, ouquando dois nós já tiverem negociado e não deverão negociar novamente.

A primeira grande alteração na simulação de Ghobad se refere ao modo como um intervaloentre beacons é simulado. Antes, eram executadas 20 rodadas de simulação da janela ATIM. Amédia do número de negociações bem-sucedidas era então utilizado como entrada na janela decomunicação, que era executada também em 20 rodadas. Na nova simulação, a saída de cadarodada da janela ATIM é utilizada individualmente como entrada em cada uma das 20 rodadasde simulação da janela de comunicação.

As seções seguintes apresentam os códigos das alterações feitas nas simulações.

A.1 Simulação do M2MMAC

A.1.1 Janela ATIM

No código principal da janela ATIM, foram feitas algumas correções em relação à simulaçãode Ghobad. O tempo SIFS foi corrigido para 10µs, como definido na tabela 3.1. O númeromáximo de tentativas de retransmissão foi reduzido para 3, como especificado no IEEE 802.11PSM para pacotes ATIM [4], [6]. Abaixo estão os códigos do script principal da janela ATIMque foram alterados. Os trechos de código que foram omitidos se mantiveram como na simu-lação original de Ghobad.

atim-window.cc

37

1 static void2 AtimFailed (std::string context, Mac48Address value)3 {4 NS_LOG_UNCOND (context << " An atim transmission has failed " <<

Simulator::Now ().GetSeconds () );5 }6

7 int main (int argc, char *argv[])8 {9 double interval = 0.00001; // seconds, ajustado segundo tabela

10

11 CommandLine cmd; //Novos parametros adicionados. Sao utilizadospelo script orquestrador

12 cmd.AddValue ("simStart", "Simulation Start", simStart);13 cmd.AddValue ("simEnd", "Simulation End", simEnd);14 cmd.AddValue ("B", "Number of antennae", B);15

16 Config::SetDefault ("ns3::WifiRemoteStationManager::MaxSsrc",StringValue ("3")); //Numero maximo de retransmissoes depacotes ATIM corrigido

17

18 uint32_t maxPacketCount = 1; //Impede que dois nos tentem realizarmais de uma negociacao

19

20 ApplicationContainer apps = server.Install (c);21 apps.Start (Seconds (simStart));22 apps.Stop (Seconds (simEnd));23

24 UdpClientHelper client (i.GetAddress (0), port);25 client.SetAttribute ("MaxPackets", UintegerValue (maxPacketCount))

;26 client.SetAttribute ("Interval", TimeValue (interPacketInterval));27 client.SetAttribute ("PacketSize", UintegerValue (MaxPacketSize));28 //para cada servidor, comecando do zero que jah estah setado29 for (uint16_t serverNode = 0; serverNode < nStas; serverNode++) {30 client.SetAttribute("RemoteAddress", AddressValue(i.GetAddress

(serverNode)));31 //pegue cada cliente32 for (uint16_t clientNode = 0; clientNode < nStas; clientNode

++) {33 if (clientNode == serverNode)34 {35 continue;36 }37 double min = 0;38 double max = 32; //Valores do IEEE 802.11

39 Ptr<UniformRandomVariable> y = CreateObject<UniformRandomVariable> ();

40 y->SetAttribute ("Min", DoubleValue (min));41 y->SetAttribute ("Max", DoubleValue (max));42 double initbackoff = simStart+ floor(y->GetValue())*

timeSlot;43 apps = client.Install (c.Get (clientNode));44 apps.Start (Seconds (initbackoff));45 apps.Stop (Seconds (simEnd));46 }47 }48

49 Config::Connect ("/NodeList/*/DeviceList/0/RemoteStationManager/MacTxAtimFailed", MakeCallback (&AtimFailed));

50

51 ArpCache a;52 a.PopulateArpCache ();53 Simulator::Stop (Seconds (simEnd));54 Simulator::Run ();55 Simulator::Destroy ();56 return 0;57 }

A.1.2 Fluxo de Controle

Na janela ATIM da simulação original de Ghobad, foram editados diversos arquivos no núcleodo NS-3 para que os pacotes RTS/CTS se comportassem como pacotes ATIM/ATIM-ACK.Nesta nova simulação, estes arquivos foram novamente alterados para que os pacotes ATIM eATIM-ACK sejam removidos dos buffers dos dispositivos sempre que não for possível com-portar mais fluxos. Adicionalmente, os nós que não puderem mais participar de negociaçõessão colocados no SLEEP mode. Vale ressaltar que a janela de comunicação foi mantida comofeita por Ghobad. A seguir estão os trechos de código que indicam estas alterações.

dca-txop.cc

1 #include "wifi-mac-header.h"2 class DcaTxop::Dcf : public DcfState3 {4 private:5 virtual void DoNotifyAtimDrop(WifiMacHeader hdr){6 m_txop->RemoveAtim (hdr);7 }8 DcaTxop *m_txop;9 };

10

11 void12 DcaTxop::RemoveAtim (WifiMacHeader hdr)13 {14 bool Condition;15 Condition = m_queue->RemovebyAddress(WifiMacHeader::ADDR1, hdr.

GetAddr2());16

17 if (Condition == 0){18 CancelRetransmission();19 }20 }21

22 void23 DcaTxop::CancelRetransmission(void){24 if (!m_txOkCallback.IsNull ())25 {26 m_txFailedCallback (m_currentHdr);27 }28 m_stationManager->ReportFinalAtimFailed (m_currentHdr.GetAddr1

(), &m_currentHdr);29 m_currentPacket = 0;30 m_dcf->ResetCw ();31 m_dcf->StartBackoffNow (m_rng->GetNext (0, m_dcf->GetCw ()));32 RestartAccessIfNeeded ();33 }

dcf-manager.cc

1 #include "wifi-mac-header.h"2 bool3 DcfState::GetAtimRetransmission(void){4 return m_atimretransmission;5 }6 void7 DcfState::SetAtimRetransmission(bool atimretransmission){8 m_atimretransmission = atimretransmission;9 }

10 void11 DcfState::NotifyAtimDrop(WifiMacHeader hdr)12 {13 DoNotifyAtimDrop(hdr);14 }15 /**16 * Listener for NAV events. Forwards to DcfManager17 */

18 class LowDcfListener : public ns3::MacLowDcfListener19 {20 public:21 virtual void LowToManager (WifiMacHeader hdr){22 m_dcf->InManager(hdr);23 }24

25 void26 DcfManager::InManager(WifiMacHeader hdr){27 m_states[0]->NotifyAtimDrop(hdr);28 }

edca-txop-n.cc

1 class EdcaTxopN::Dcf : public DcfState2 {3 private:4 virtual void DoNotifyAtimDrop(WifiMacHeader hdr){5 m_txop->NotifySleep();6 }7 }

mac-low.cc

1 void2 MacLow::VerifySleep(void)3 {4 m_phy->SetNumberOfCommunicationLink(1); //increasing the number

of communication links on this node5 //NS_LOG_UNCOND (" number of communication link " << m_phy->

GetNumberOfCommunicationLink());6 if (m_phy->GetNumberOfCommunicationLink() >= m_phy->

GetNumberOfReceiveAntennas() - 1){7 m_phy->SetSleepMode();8 }9 }

10

11 void12 MacLow::ReceiveOk (Ptr<Packet> packet, double rxSnr, WifiTxVector

txVector, WifiPreamble preamble, bool ampduSubframe)13 {14 //Se for ATIM15 if (hdr.IsAtim ())16 {

17 // NS_LOG_UNCOND ("MacLow::ReceiveOk: IsAtim");18 if (ampduSubframe)19 {20 NS_FATAL_ERROR ("Received ATIM as part of an A-MPDU");21 }22 else23 {24 if (isPrevNavZero25 && hdr.GetAddr1 () == m_self)26 {27 NS_LOG_DEBUG ("rx ATIM from=" << hdr.GetAddr2 () << ",

schedule ATIMACK");28 NS_ASSERT (m_sendAtimAckEvent.IsExpired ());29 m_stationManager->ReportRxOk (hdr.GetAddr2 (), &hdr,30 rxSnr, txVector.GetMode

());31 m_sendAtimAckEvent = Simulator::Schedule (GetSifs (),32 &MacLow::

SendAtimAckAfterAtim,this,

33 hdr.GetAddr2 (),34 hdr.GetDuration (),35 txVector,36 rxSnr);37

38 m_phy->SetNumberOfCommunicationLink(1); //increasingthe number of communication links on this node

39 // NS_LOG_UNCOND (" number of communication link " <<m_phy->GetNumberOfCommunicationLink());

40

41 m_dcfListeners[0]->LowToManager(hdr);42

43 }44 else45 {46 NS_LOG_DEBUG ("rx ATIM from=" << hdr.GetAddr2 () << ",

cannot schedule ATIMACK");47 }48 }49 } //Caso nao seja, veja se eh ATIMACK50 else if (hdr.IsAtimAck ()51 && hdr.GetAddr1 () == m_self52 && m_atimAckTimeoutEvent.IsRunning ()53 && m_currentPacket != 0)54 {55 // NS_LOG_UNCOND ("MacLow::ReceiveOk: IsAtimAck ");

56 if (ampduSubframe)57 {58 NS_FATAL_ERROR ("Received ATIMACK as part of an A-MPDU");59 }60

61 NS_LOG_DEBUG ("receive ATIMACK from=" << m_currentHdr.GetAddr1());

62

63 SnrTag tag;64 packet->RemovePacketTag (tag);65 m_stationManager->ReportRxOk (m_currentHdr.GetAddr1 (), &

m_currentHdr,66 rxSnr, txVector.GetMode ());67 m_stationManager->ReportAtimOk (m_currentHdr.GetAddr1 (), &

m_currentHdr,68 rxSnr, txVector.GetMode (),

tag.Get ());69 NS_LOG_UNCOND ("HANDSHAKE from " << hdr.GetAddr1 () << " to "

<< m_currentHdr.GetAddr1 () << " OK ");70 m_atimAckTimeoutEvent.Cancel ();71 NotifyAtimAckTimeoutResetNow ();72 // NS_LOG_UNCOND ("MacLow::ReceiveOk: Resetamos o ATIMACK

Timeout");73 // m_listener->GotCts (rxSnr, txVector.GetMode ()); //VER ESSA

LINHA74 NS_ASSERT (m_sendDataEvent.IsExpired ());75 //AQUI EH ONDE O SEND_DATA OCORRERIA MAS NAO VAI OCORRER76 //NO LUGAR DISSO, FAREMOS O PROCEDIMENTO QUE OCORRE APOS O ACK

PARA SATISFAZER A CAMADA DE CIMA77

78

79 m_listener->GotAtimAck (rxSnr, txVector.GetMode ());80 FlushAggregateQueue ();81 m_ampdu = false;82

83 VerifySleep();84 }85 }

wifi-mac-queue.cc

1 Ptr<const Packet>2 WifiMacQueue::DequeueByTidAndAddress (WifiMacHeader *hdr, uint8_t

tid,3 WifiMacHeader::AddressType

type, Mac48Address dest)4 {5 Cleanup ();6 Ptr<const Packet> packet = 0;7 if (!m_queue.empty ())8 {9 PacketQueueI it;

10 for (it = m_queue.begin (); it != m_queue.end (); ++it)11 {12 if (it->hdr.IsData ())13 {14 if (GetAddressForPacket (type, it) == dest15 && it->hdr.GetQosTid () == tid)16 {17 packet = it->packet;18 *hdr = it->hdr;19 m_queue.erase (it);20 m_size--;21 break;22 }23 }24 }25 }26 return packet;27 }28

29 bool30 WifiMacQueue::RemovebyAddress (WifiMacHeader::AddressType type,

Mac48Address dest)31 {32 Cleanup ();33 if (!m_queue.empty ())34 {35 PacketQueueI it;36 for (it = m_queue.begin (); it != m_queue.end (); ++it)37 {38 if (it->hdr.IsData ())39 {40 if (GetAddressForPacket (type, it) == dest)41 {42 m_queue.erase (it);43 m_size--;44 return true;45 }46 }47 }

48 }49 return false;50 }

wifi-phy.cc

1 WifiPhy::WifiPhy ()2 : m_mpdusNum (0),3 m_plcpSuccess (false),4 m_txMpduReferenceNumber (0xffffffff),5 m_rxMpduReferenceNumber (0xffffffff),6 m_endRxEvent (),7 m_endPlcpRxEvent (),8 m_standard (WIFI_PHY_STANDARD_UNSPECIFIED),9 m_isConstructed (false), //true when ready to set frequency

10 m_channelCenterFrequency (0),11 m_initialFrequency (0), //Store frequency until initialization.12 m_frequencyChannelNumberInitialized (false), //Store

initialization state.13 m_channelNumber (0),14 m_initialChannelNumber (0), //Initial channel number.15 m_totalAmpduSize (0),16 m_totalAmpduNumSymbols (0),17 m_numberOfLinks (0)18 {19 NS_LOG_FUNCTION (this);20 m_random = CreateObject<UniformRandomVariable> ();21 m_state = CreateObject<WifiPhyStateHelper> ();22 }23

24 void25 WifiPhy::SetNumberOfCommunicationLink (uint32_t link)26 {27 m_numberOfLinks = m_numberOfLinks + link;28 }

wifi-remote-station-manager.cc

1 TypeId2 WifiRemoteStationManager::GetTypeId (void)3 {4 static TypeId tid = TypeId ("ns3::WifiRemoteStationManager")5 .SetParent<Object> ()6 .SetGroupName ("Wifi")

7 .AddTraceSource ("MacTxAtimFailed",8 "The transmission of a Atim packet by the MAC

layer has failed",9 MakeTraceSourceAccessor (&

WifiRemoteStationManager::m_macTxAtimFailed),

10 "ns3::Mac48Address::TracedCallback")11 ;12 return tid;13 }14

15 void16 WifiRemoteStationManager::ReportAtimFailed (Mac48Address address,

const WifiMacHeader *header)17 {18 NS_LOG_FUNCTION (this << address << *header);19 NS_ASSERT (!address.IsGroup ());20 WifiRemoteStation *station = Lookup (address, header);21 station->m_ssrc++;22 m_macTxAtimFailed (address);23 //DoReportAtimFailed (station);24 }

yans-wifi-phy.cc1 void2 YansWifiPhy::SendPacket (Ptr<const Packet> packet, WifiTxVector

txVector, WifiPreamble preamble, enum mpduType mpdutype)3 {4

5 //At the end of the file6 if (GetNumberOfCommunicationLink() >= GetNumberOfReceiveAntennas()

- 1)7 {8 SetSleepMode();9 }

10 }

A.1.3 Scripts

Para orquestrar as duas fases do protocolo M2MMAC, foi desenvolvido um script em ShellScript responsável por executar cada rodada de simulação e gerenciar o gerador de númerosaleatórios. Ele foi implementado de tal forma que as sementes do gerador são as própriasrodadas de simulação, para que os resultados sejam reprodutíveis e para evitar a correlaçãoentre os números gerados [9].

runBIm2mmac.sh

1 #!/bin/bash2 echo Iniciando a simulacao3 START_TIME=$SECONDS4 #rm *.pcap5

6 #CONFIGS7 COUNTER=18 nRuns=209 nStas=3 #De 3 a 24, de 3 em 3

10 nStas=${1:-$nStas}11 M=2412 B=5 #3 ou 513 B=${2:-$B}14

15 #CONFIGS ATIM16 ATIMSTART=1.0017 ATIMEND=1.0418 atimProgram="atim-window"19

20 #CONFIGS COMM21 COMMSTART=1.0022 COMMEND=1.0623 nSched=024 commProgram="comm-window"25

26 echo "Serao $nRuns rodadas de $atimProgram e $commProgram com $nStasnos, $B antenas de recepcao, $M canais com ATIM Window

encerrando em $ATIMEND segundos:"27

28

29 TOTALSCHEDD=030 rm resumo"$nStas".out31

32 TOTALTX=033 rm datatx"$nStas".out34

35 while [ $COUNTER -le $nRuns ]36 do37 echo38 echo "Run=$COUNTER"39

40

41 echo Iniciando a ATIM Window

42 cd ns-3.26atim43

44

45 ./waf --run "scratch/$atimProgram --nStas=$nStas --nRuns=$COUNTER --simStart=$ATIMSTART --simEnd=$ATIMEND --B=$B" >../log.out 2>&1

46 cd ..47 HANDSHAKES=$(cat log.out | grep "HANDSHAKE" --count)48 echo "$HANDSHAKES" >> resumo"$nStas".out49 echo "$HANDSHAKES handshakes agendados"50 TOTALSCHEDD=$(($TOTALSCHEDD+$HANDSHAKES))51

52

53

54 echo Iniciando a Communication Window55 cd ns-3.26comm56

57

58 ./waf --run "scratch/$commProgram --nStas=$nStas --M=$M --B=$B--nSched=$((HANDSHAKES*2)) --nRuns=$COUNTER --simStart=$COMMSTART --simEnd=$COMMEND" > ../CommLog.out 2>&1

59 cd ..60 DATATX=$(cat CommLog.out | grep "DATATX" --count)61 echo "$DATATX" >> datatx"$nStas".out62 echo "Throughput: $(echo "scale=5; ($DATATX*512*8*10/1000000)"|

bc) Mbps"63 TOTALTX=$(($TOTALTX+$DATATX))64

65

66 ((COUNTER++))67 done68

69 rm log.out70 rm CommLog.out71 cat resumo"$nStas".out72 cat datatx"$nStas".out73 echo74

75 echo "Total em todas as rodadas - ATIM Window"76 echo "$TOTALSCHEDD"77 MEDIA=$(echo "scale=5; ($TOTALSCHEDD/$nRuns)" | bc)78 echo "Media por rodada"79 echo $MEDIA80 echo "Numero maximo de streams"81 echo "nSched = $(echo "scale=1;($MEDIA*2)" | bc)"82 echo

83

84 echo "Total em todas as rodadas - COMM Window"85 echo "$TOTALTX"86 PACOTES=$(echo "scale=5; ($TOTALTX/$nRuns)" | bc)87 echo "Media de Pacotes por rodada"88 echo $PACOTES89 echo90 echo "Throughput"91 THROUGHPUT=$(echo "scale=5; ($PACOTES*512*8*10/1000000)"| bc)92 echo "$THROUGHPUT Mbps"93 echo94

95

96 ELAPSED_TIME=$(($SECONDS - $START_TIME))97 echo "Tempo decorrido"98 echo "$(($ELAPSED_TIME/60)) min $(($ELAPSED_TIME%60)) sec"99 echo Finalizando a simulacao

A.2 Simulação do H-M2MMAC

Todas as alterações para a simulação do protocolo H-M2MMAC foram feitas apenas no scriptorquestrador, cujo código é fornecido abaixo (em Shell Script). Nesta simulação, são executa-das 20 rodadas de teste com dois intervalos entre beacons cada, como descrito no capítulo 4. Onúcleo do simulador é mantido idêntico à simulação do M2MMAC.

A.2.1 Scripts

runBIhm2mmac.sh

1 #!/bin/bash2 echo Iniciando a simulacao3 START_TIME=$SECONDS4 #rm *.pcap5

6 #CONFIGS7 COUNTER=18 nRuns=209 nStas=6 #De 3 a 24, de 3 em 3

10 nStas=${1:-$nStas}11 M=2412 B=5 #3 ou 513 B=${2:-$B}14

15 #CONFIGS ATIM16 ATIMSTART=1.0017 ATIMEND=1.0218 atimProgram="atim-window"19

20 #CONFIGS COMM21 COMMSTART=1.0022 COMMEND=1.0823 nSched=024 commProgram="comm-window"25

26 echo "Serao $nRuns rodadas de $atimProgram e $commProgram com $nStasnos, $B antenas de recepcao, $M canais com ATIM Window

encerrando em $ATIMEND segundos:"27

28 TOTALSCHEDD=029 rm resumo"$nStas".out30

31 TOTALTX=032 rm datatx"$nStas".out33

34 while [ $COUNTER -le $nRuns ]35 do36 echo37 echo "Run=$COUNTER"38

39

40 echo Iniciando a ATIM Window 141 cd ns-3.26atim42

43

44

45 ./waf --run "scratch/$atimProgram --nStas=$nStas --nRuns=$COUNTER --simStart=$ATIMSTART --simEnd=$ATIMEND --B=$B" >../log.out 2>&1

46 cd ..47 HANDSHAKES=$(cat log.out | grep "HANDSHAKE" --count)48 rm chunk0.out49 rm chunk1.out50 awk ’/An atim transmission has failed/ { delim++ } { file =

sprintf("chunk%s.out", int(delim>2)); print > file; }’ < log.out

51 NTXCOUNT=$(cat chunk0.out | grep "HANDSHAKE" --count)52 ETXCOUNT=$(cat chunk1.out | grep "HANDSHAKE" --count)53 echo NTX = "$NTXCOUNT"54 echo ETX = "$ETXCOUNT"

55 echo "$HANDSHAKES" >> resumo"$nStas".out56 echo "$HANDSHAKES handshakes agendados"57 TOTALSCHEDD=$(($TOTALSCHEDD+$HANDSHAKES))58

59

60

61 echo Iniciando a Communication Window 162 cd ns-3.26comm63

64 nStasNTx=065 nStasETx=066 if [ $HANDSHAKES -ne 0 ]67 then68 nStasNTx=$(($nStas*$NTXCOUNT/($NTXCOUNT+$ETXCOUNT)))69 nStasETx=$(($nStas-$nStasNTx))70 fi71

72 echo nStasNTx = "$nStasNTx"73 echo nStasETx = "$nStasETx"74

75 ./waf --run "scratch/$commProgram --nStas=$nStasNTx --M=$M --B=$B --nSched=$((NTXCOUNT*2)) --nRuns=$COUNTER --simStart=$COMMSTART --simEnd=$COMMEND" > ../CommLog.out 2>&1

76 cd ..77 DATANTX=$(cat CommLog.out | grep "DATATX" --count)78 TOTALTX=$(($TOTALTX+$DATANTX))79

80 cd ns-3.26comm81 newCOMMEND=$(echo "$COMMEND+0.10" | bc)82 ./waf --run "scratch/$commProgram --nStas=$nStasETx --M=$M --B=

$B --nSched=$((ETXCOUNT*2)) --nRuns=$COUNTER --simStart=$COMMSTART --simEnd=$newCOMMEND" > ../CommLog.out 2>&1

83 cd ..84 DATAETX=$(cat CommLog.out | grep "DATATX" --count)85 echo DATANTX = "$DATANTX" e DATAETX = "$DATAETX"86 echo newCOMMEND = "$newCOMMEND"87 echo "Throughput: $(echo "scale=5; (($DATANTX+$DATAETX)

*512*8*10/1000000)"| bc) Mbps"88 TOTALTX=$(($TOTALTX+$DATAETX))89

90 COMM1TX=$(($DATANTX+$DATAETX))91

92

93

94

95 echo Iniciando a ATIM Window 2

96 cd ns-3.26atim97

98

99 newnStas=$nStasNTx100 ./waf --run "scratch/$atimProgram --nStas=$newnStas --nRuns=

$COUNTER --simStart=$ATIMSTART --simEnd=$ATIMEND --B=$B" >../log.out 2>&1

101 cd ..102 HANDSHAKES=$(cat log.out | grep "HANDSHAKE" --count)103 rm chunk0.out104 rm chunk1.out105 awk ’/An atim transmission has failed/ { delim++ } { file =

sprintf("chunk%s.out", int(delim>2)); print > file; }’ < log.out

106 NTXCOUNT=$(cat chunk0.out | grep "HANDSHAKE" --count)107 ETXCOUNT=$(cat chunk1.out | grep "HANDSHAKE" --count)108 echo NTX = "$NTXCOUNT"109 echo ETX = "$ETXCOUNT"110 echo "$HANDSHAKES" >> resumo"$nStas".out111 echo "$HANDSHAKES handshakes agendados"112 TOTALSCHEDD=$(($TOTALSCHEDD+$HANDSHAKES))113

114

115

116 echo Iniciando a Communication Window 2117 cd ns-3.26comm118

119 nStasNTx=0120 nStasETx=0121 if [ $HANDSHAKES -ne 0 ]122 then123 nStasNTx=$(($newnStas*$NTXCOUNT/($NTXCOUNT+$ETXCOUNT)))124 nStasETx=$(($newnStas-$nStasNTx))125 fi126

127 echo nStasNTx = "$nStasNTx"128 echo nStasETx = "$nStasETx"129

130

131 ./waf --run "scratch/$commProgram --nStas=$nStasNTx --M=$M --B=$B --nSched=$((NTXCOUNT*2)) --nRuns=$COUNTER --simStart=$COMMSTART --simEnd=$COMMEND" > ../CommLog.out 2>&1

132 cd ..133 DATANTX=$(cat CommLog.out | grep "DATATX" --count)134 TOTALTX=$(($TOTALTX+$DATANTX))135

136 cd ns-3.26comm137 ./waf --run "scratch/$commProgram --nStas=$nStasETx --M=$M --B=

$B --nSched=$((ETXCOUNT*2)) --nRuns=$COUNTER --simStart=$COMMSTART --simEnd=1.10" > ../CommLog.out 2>&1

138 cd ..139 DATAETX=$(cat CommLog.out | grep "DATATX" --count)140 echo "Throughput: $(echo "scale=5; (($DATANTX+$DATAETX)

*512*8*10/1000000)"| bc) Mbps"141 TOTALTX=$(($TOTALTX+$DATAETX))142

143 COMM2TX=$(($DATANTX+$DATAETX))144

145 TOTAL1E2TX=$(echo "(($COMM1TX+$COMM2TX)/2.0)"| bc)146 echo "$TOTAL1E2TX" >> datatx"$nStas".out147

148

149 echo150 ((COUNTER++))151 done152

153 rm log.out154 rm CommLog.out155 cat resumo"$nStas".out156 cat datatx"$nStas".out157 echo158

159

160

161 ELAPSED_TIME=$(($SECONDS - $START_TIME))162 echo "Tempo decorrido"163 echo "$(($ELAPSED_TIME/60)) min $(($ELAPSED_TIME%60)) sec"164 echo Finalizando a simulacao

Bibliografia

[1] T. Rappaport, Comunicações Sem Fio: Princípios e Práticas, 2nd. São Paulo: PearsonPrentice Hall, 2009, ISBN: 0130422320.

[2] M. G. Rubinstein, I. M. Moraes, M. E. M. Campista, L. H. M. Costa e O. C. M. Duarte,“A survey on wireless ad hoc networks”, em IFIP International Conference on Mobileand Wireless Communication Networks, Springer, 2006, pp. 1–33.

[3] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam e E. Cayirci, “Wireless sensor networks:a survey”, Computer networks, vol. 38, nº 4, pp. 393–422, 2002.

[4] IEEE Computer Society LAN MAN Standards Committee, “Wireless LAN MediumAccess Control (MAC) and Physical Layer (PHY) Specifications: Higher Speed PhysicalLayer (PHY) Extension in the 2.4GHz Band”, IEEE Standard 802.11b-1999, 1999.

[5] ——, “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications-Amendment 4: Enhancements for Very High Throughput for Operation in Bands below6GHz”, IEEE Standard 802.11ac-2013, 2013.

[6] ——, “Wireless LAN medium access control (MAC) and physical layer (PHY) specifi-cations”, IEEE Standard 802.11-1997, 1997.

[7] R. M. de Moraes, Performance Analysis of Wireless Networks, PhD thesis, University ofCalifornia, California, dez. de 2005.

[8] R. M. De Moraes, H. R. Sadjadpour et al., “Many-to-many communication for mobile adhoc networks”, IEEE Transactions on Wireless Communications, vol. 8, nº 5, pp. 2388–2399, 2009.

[9] P. C. Ghobad, M2MMAC: Um Novo Protocolo MAC Multicanal para ComunicaçãoMuitos-para-Muitos em Redes 802.11, Dissertação de Mestrado, UNB (Universidadede Brasília), Brasília, Brazil, jul. de 2017.

[10] D. A. R. Adauto, H-M2MMAC: Uma Nova Abordagem Híbrida do Protocolo MAC Mul-ticanal para Comunicação Muitos-para-Muitos, Trabalho de Graduação, UFPE (Univer-sidade Federal de Pernambuco), Recife, Brazil, dez. de 2017.

[11] A. Sabharwal, P. Schniter, D. Guo, D. W. Bliss, S. Rangarajan e R. Wichman, “In-bandfull-duplex wireless: Challenges and opportunities”, IEEE Journal on selected areas incommunications, vol. 32, nº 9, pp. 1637–1652, 2014.

[12] Z. Zhang, X. Chai, K. Long, A. V. Vasilakos e L. Hanzo, “Full duplex techniques for5G networks: self-interference cancellation, protocol design, and relay selection”, IEEECommunications Magazine, vol. 53, nº 5, pp. 128–137, 2015.

54

[13] M. Davis, “A wireless traffic probe for radio resource management and QoS provisioningin IEEE 802.11 WLANs”, em Proceedings of the 7th ACM international symposium onModeling, analysis and simulation of wireless and mobile systems, ACM, 2004, pp. 234–243.

[14] Y. Tseng, C. Hsu e T. Hsieh, “Power-saving protocols for IEEE 802.11-based multi-hopad hoc networks”, Computer Networks, vol. 43, nº 3, pp. 317–337, 2003.

[15] IEEE Computer Society LAN MAN Standards Committee, “Wireless LAN Medium Ac-cess Control (MAC) and Physical Layer (PHY) Specifications-Amendment 5: Enhance-ments for Higher Throughput”, IEEE Standard 802.11n-2009, 2009.

[16] Y. Du, Multiuser Detection in Multiple Input Multiple Output Orthogonal Frequency Di-vision Multiplexing Systems by Blind Signal Separation Techniques, PhD thesis, FloridaInternational University, Miami, Florida, mar. de 2012.

[17] O. Bejarano, E. W. Knightly e M. Park, “IEEE 802.11 ac: from channelization to multi-user MIMO”, IEEE Communications Magazine, vol. 51, nº 10, pp. 84–90, 2013.

[18] OFFICIAL IEEE 802.11 WORKING GROUP PROJECT TIMELINES, http://www.ieee802.org/11/Reports/802.11_Timelines.htm, Accessed: 2019-06-14.

[19] A. Malhotra, M. Maity e A. Dutta, “How much can we reuse? An empirical analysis ofthe performance benefits achieved by spatial-reuse of IEEE 802.11 ax”, em 2019 11thInternational Conference on Communication Systems & Networks (COMSNETS), IEEE,2019, pp. 432–435.

[20] S.-L. Wu, C.-Y. Lin, Y.-C. Tseng e J.-L. Sheu, “A new multi-channel MAC protocol withon-demand channel assignment for multi-hop mobile ad hoc networks”, em ProceedingsInternational Symposium on Parallel Architectures, Algorithms and Networks. I-SPAN2000, IEEE, 2000, pp. 232–237.

[21] D. N. M. Dang e C. S. Hong, “H-MMAC: A hybrid multi-channel MAC protocol forwireless ad hoc networks”, em 2012 IEEE International Conference on Communications(ICC), IEEE, 2012, pp. 6489–6493.

[22] J. So e N. H. Vaidya, “Multi-channel mac for ad hoc networks: handling multi-channelhidden terminals using a single transceiver”, em Proceedings of the 5th ACM interna-tional symposium on Mobile ad hoc networking and computing, ACM, 2004, pp. 222–233.

[23] D. N. M. Dang, C. S. Hong e S. Lee, “A hybrid multi-channel MAC protocol for wirelessad hoc networks”, Wireless Networks, vol. 21, nº 2, pp. 387–404, 2015.

[24] I. A. Getting, “Perspective/navigation-the global positioning system”, IEEE spectrum,vol. 30, nº 12, pp. 36–38, 1993.

[25] S. Umamaheshwar, T. A. Kumar e K. S. Rao, “Performance evaluation of multiuserMIMO detection techniques”, em 2015 International Conference on Green Computingand Internet of Things (ICGCIoT), IEEE, 2015, pp. 1178–1183.

[26] NS-3 PROJECT, Network Simulator 3, https://www.nsnam.org/releases/ns-3-26/, Accessed: 2019-06-18.

[27] I. Tinnirello, G. Bianchi e Y. Xiao, “Refinements on IEEE 802.11 Distributed Coordi-nation Function Modeling Approaches”, IEEE Transactions on Vehicular Technology,vol. 59, nº 3, pp. 1055–1067, 2010.

[28] Federal Communications Comission (FCC), Radio Spectrum Allocation, https://www.fcc.gov/engineering-technology/policy-and-rules-division/general/radio-spectrum-allocation, Accessed: 2019-06-18.

[29] J. Zhang, G. Zhou, C. Huang, S. H. Son e J. A. Stankovic, “TMMAC: An energy ef-ficient multi-channel mac protocol for ad hoc networks”, em 2007 IEEE InternationalConference on Communications, IEEE, 2007, pp. 3554–3561.

universidade federal de pernambuco centro de …tg/2019-1/tg_ec/monografia_do_tg_de_ro… · access...

Documents