Implementação e avaliação de um protocolo de comunicações de tempo-real em redes IEEE

Transcrição

1 Faculdade de Engenharia da Universidade do Porto Implementação e avaliação de um protocolo de comunicações de tempo-real em redes IEEE Diogo Pereira VERSÃO PROVISÓRIA Dissertação realizada no âmbito do Mestrado Integrado em Engenharia Electrotécnica e de Computadores Major Telecomunicações Orientador: Prof. Dr. Paulo Portugal Junho, 2011

2 Diogo Pereira, 2011 ii

3 Resumo Este documento tem como objectivo descrever a implementação de um protocolo para suportar comunicação de tempo real em redes IEEE O Wi-Fi (IEEE ) é actualmente a rede sem fios mais utilizada a nível mundial. No entanto, a sua aplicação em ambientes industriais apresenta algumas limitações, devido à dificuldade em suportar tráfego de tempo-real, isto é, tráfego trocado entre sensores, controladores e actuadores, comum neste tipo de ambientes. Através da implementação de dois mecanismos, FCR (Force Collision Resolution) e TDMA (Time Division Multiple Access), é possível introduzir melhorias no mecanismo EDCA (Enhanced Distributed Channel Access), implementado na norma IEEE e. Através da utilização da fila de voz, atribui-se uma elevada prioridade ao tráfego, e juntamente com a desactivação do backoff usufruir-se-á dum sistema determinístico, o qual deve estar aplicado nos processos industriais. Consequentemente, estando o backoff desactivado, e havendo a possibilidade de existir uma retransmissão, o número de colisões seguramente irá aumentar. A gestão do múltiplo acesso ao meio (TDMA) é a forma mais eficiente para a eliminação de colisões resultantes dessas mesmas retransmissões. Estes mecanismos serão descritos no documento, de uma forma mais rigorosa, como também analisados os que actualmente são mais aplicados em redes com elevados requisitos temporais. Com esta proposta, é possível obter um atraso médio constante e relativamente mais baixo, bem como, um throughput e alcançar metas temporais (deadlines) impostas pelas comunicações em tempo real. iii

4

5 Abstract This document aims to describe the implementation of a protocol for real-time IEEE networks. Wi-Fi (IEEE ) is a currently the most wireless network used in the worldwide. However, their application in industrial environments has some limitations because of difficulty in supporting real-time traffic, i.e., traffic exchanged between sensors, controllers and actuators, which is common in these environments. Through the implementation of two mechanisms, FCR (Force Collision Resolution) and TDMA (Time Division Multiple Access), is possible to delete of the limitations of the mechanism EDCA (Enhanced Distributed Channel Access) used in the IEEE e standard. Through the use of the voice queue, thus giving high priority traffic, and with backoff disable is possible enjoy a deterministic system, which must be applied in industrial processes. Consequently, while the bakcoff is disabling, and having the possibility of a relay, the number of collisions will surely increase. The management of multiple media access (TDMA) is the most efficient way to eliminate these collisions resulting of retransmissions. These mechanisms are described in the document, more rigorous, but also analyzed those who currently are implemented in networks with high temporal requirements. With this proposal, it is possible obtain a constant average delay and relatively low, as well a throughput and deadline imposed by real-time communications. v

6 vi

7 Agradecimentos Agradeço ao meu Orientador, Professor Paulo Portugal, pela simpatia e pelo apoio prestado em virtude de melhor compreender o projecto. Aos meus Pais, porque sem a ajuda deles não estaria a concluir este curso. A Ti pela compreensão e apoio ao longo de todo o curso, e em especial nesta fase final. vii

8 viii

9 Índice Resumo... iii Abstract... v Agradecimentos... vii Índice... ix Lista de Figuras... xi Lista de Tabelas... xii Lista de Equações... xiii Lista de Algoritmos...xiv Abreviaturas e Símbolos... xv Capítulo Introdução Contexto Objectivos Estrutura... 3 Capítulo Norma IEEE IEEE Mecanismo de acesso ao meio DCF Distributed Coordination Function PCF Point Coordination Function HCCA HCF Controlled Channel Access EDCA Enhanced Distributed Channel Access Conclusão ix

10 Capítulo Mecanismo RT-WiFi Descrição do mecanismo FCR Force Collision Resolution TDMA Time Division Multiple Access Algoritmo baseado em comunicações TDMA Análise Temporal Conclusão Capítulo Driver MadWifi Estrutura do MadWifi Work Flow do MadWifi Transmissão Recepção Estruturas no MadWifi Capítulo Implementação do RT-WiFi TSm Time Separation mechanism TDMA Time Division Multiple Access Dificuldades Capítulo Conclusão Referências x

11 Lista de Figuras Figura Controlo de Processos Industriais... 1 Figura Fluxograma do CSMA/CA... 6 Figura Arquitectura MAC da norma IEEE Figura Arquitectura MAC da norma IEEE e... 8 Figura 2.4 Intervalos de espera do mecanismo DCF e PCF... 9 Figura Classes de Tráfego - IEEE e Figura Mecanismo EDCA Figura Arquitectura RT-WiFi Figura Ciclo do Protocolo TDMA Figura Arquitectura do MadWifi Figura 4.2 Classificação quanto à prioridade de um pacote de dados Figura 4.3 Encapsulamento e encriptação de um pacote de dados Figura Processamento de um pacote de gestão Figura Envio de um pacote de dados ou gestão Figura 4.6 Inclusão do buffer na fila de transmissão e envio do mesmo Figura Fluxograma da transmissão de um pacote de dados/gestão Figura 4.8 Recepção de um pacote de dados/gestão Figura 4.9 Verificação do tipo de pacote Figura Processamento dos pacotes de dados Figura Processamento dos pacotes de gestão Figura Fluxograma da recepção de um pacote de dados/gestão Figura Modificações na função ieee80211_classify() para seleccionar a fila de voz Figura Alteração dos parâmetros da fila de Voz Figura Alteração dos parâmetros da fila de voz Figura Ciclo do Protocolo TDMA Figura Fluxograma da recepção de um beacon Figura Flag GrantoSend Figura Recepção de um Beacon Figura 5.8 Introdução do envio de um pacote através do mecanismo TDMA xi

12 Lista de Tabelas Tabela Prioridade IEEE 802.1D para IEEE e Tabela Parâmetros do mecanismo EDCA Tabela Estruturas no MadWifi xii

13 Lista de Equações Equação Equação Equação Equação Equação Equação Equação xiii

14 Lista de Algoritmos Algoritmo 3.1 Recepção de um Beacon Algoritmo 3.2 Interrupção SP id Algoritmo 3.3 Interrupção EP id Algoritmo 3.4 Transmissão Algoritmo 5.1 Transmissão de um pacote xiv

15 Abreviaturas e Símbolos AC ACK AIFSN AP CA CSMA CW CW DCF DIFS DMA EDCA FCR HAL HCCA HCF IEEE MAC MadWifi PC PCF QoS RT STD TDMA TR TXOP WLAN Access Categories Acknowleged Arbitration Interframe Space Number Access Point Collision Avoidance Carrier Sense Multiple Access Contention Window Contention Window Distributed Coordenation Function Distributed Interframe Space Direct memory access Enhanced Distributed Channel Access Force Collision Resolution Hardware Abstraction Layer HCF Controlled Channel Access Hybrid Coordenation Function Institute of Electrical and Electronics Engineers Mechanism Access Control Multiband Atheros Driver WiFi Point Coordinator Point Coordinator Function Quality of Service Real Time Standard Topoly Default Time Division Multiple Access Tempo Real Transmission Oportunity Wireless Local Area Network xv

16

17 Capítulo 1 Introdução As comunicações existentes em ambientes industriais, são caracterizadas por possuírem requisitos temporais exigentes, devido à existência de sensores, controladores e actuadores, que efectuam trocas de dados (Figura 1.1) periodicamente. Derivado a estas exigências, as comunicações reivindicam melhores infra-estruturas, e em virtude do aparecimento de novas tecnologias, na área das redes, é possível usufruir de uma melhor troca de informação entre os sistemas autónomos existentes numa fábrica. Processo Sensor Actuador Controlador Figura Controlo de Processos Industriais Mediante o grau de exigência de um processo, pode definir-se dois tipos de serviços. Um desses dois tipos é designado por Hard Real-Time, ou seja, comunicações que requerem sistemas com acções precisas e delineadas previamente. Com a implementação deste tipo de 1

18 2 Norma IEEE serviço, a ocorrência de respostas imprevisíveis é nula, assim como, as acções de um processo industrial passam a ser realizadas num reduzido espaço de tempo. O outro tipo de serviço é designado por Soft Real-Time, o qual possui requisitos menos exigentes, sendo que estes permitem a ocorrência de falhas de transmissão, como colisões e o não alcance de algumas metas temporais (deadlines). De forma a colmatar as limitações existentes na rede, a introdução de um protocolo que melhore estas infra-estruturas, é vista como uma solução promissora e viável, introduzindo maior eficácia nos meios de transmissão de comunicações em tempo-real Contexto Esta dissertação surge na sequência de um trabalho de doutoramento efectuado pelo colega Robson Costa, com o tema A TDMA-based Mechanism for Real-Time Communication in IEEE e Networks [1]. Trabalho este que expõe uma solução para serviços de comunicações em tempo-real para redes wireless. A norma IEEE Wireless Local Area Networks (WLANs) possui propriedades que vão ao encontro dos objectivos definidos para este trabalho, proporcionando ao desenvolvimento desta solução custos reduzidos. Este facto deve-se à norma ser implementada de forma generalizada em grande parte dos equipamentos disponíveis no mercado, tornando-se assim o valor do equipamento mais reduzido em comparação com outros. Esta norma sendo de fácil configuração, e sem necessidade de introduzir alterações no hardware, foi assim aceite e seleccionada como uma norma para as tecnologias sem fios 1. Baseando-se na norma apresentada anteriormente, foi feita uma pesquisa sobre os três 2 principais mecanismos deste standard, de forma a alcançar uma solução viável para a introduzir em comunicações sem fios de tempo real, em ambientes industriais. Para este projecto, a rede wireless basear-se-á em serviços que apenas exigem garantias soft real-time, devendo-se este facto ao ambiente em que esta rede será implementada. As acções desencadeadas no decorrer de processos fabris, não necessitarão de garantias rigorosas, podendo assim facilitar a ocorrência de algumas perdas durante uma transmissão. 1 Mais conhecida por WiFi 2 i) Medium Access Control, ii) Admission Control e iii) Scheduler 2

19 Objectivos Objectivos Para a realização deste projecto foram definidos dois objectivos: 1. O primeiro objectivo deste projecto é averiguar a viabilidade da solução encontrada para comunicações em tempo real em redes IEEE , através da implementação dos dois mecanismos, FCR e TDMA, a serem apresentados como solução. Mecanismos que serão testados e validados a posteriori num ambiente proposto. 2. O segundo objectivo será garantir o funcionamento da rede implementada com garantias determinísticas em sistemas de controlo automático, sendo que os requisitos com maior importância consistem em atrasos na transmissão, perda de pacotes e reduzidos valores de jitter (variação média do atraso na entrega de dados numa rede). Com estes dois objectivos alcançados, será possível concluir este projecto com êxito Estrutura O documento encontra-se dividido em 5 capítulos. No primeiro capítulo será apresentada uma introdução ao projecto, expondo o contexto e objectivos definidos inicialmente para este trabalho. No capítulo seguinte (capítulo 2), será elaborada uma análise às redes IEEE , focando a norma IEEE e aplicada ao suporte de tráfego de tempo-real, e expondo as suas limitações. No terceiro capítulo, de forma a colmatar as limitações expostas, serão apresentados os mecanismos FCR e TDMA. No quarto capítulo será apresentada uma descrição do driver utilizado, ilustrado através de fluxogramas a transmissão/recepção do mesmo. No quinto capítulo será descrita a implementação dos mecanismos TDMA e FCR, de forma pormenorizada, como também as dificuldades que foram surgindo ao longo do trabalho. Para finalizar, no último capítulo (capítulo 6) será elaborada uma conclusão para analisar o trabalho desenvolvido. 3

20 Capítulo 2 Norma IEEE Com o intuito de estabelecer um conjunto de regras nas comunicações sem fio 3, em 1990 o Institute of Electrial and Electronics Engineers (IEEE) criou um grupo de trabalho para elaborar o conjunto de regras. Inicialmente foi desenvolvida e aprovada uma norma, designada por IEEE , que possuía uma taxa nominal de dados entre 1 Mbps e 2 Mbps. Com o passar dos anos, foram desenvolvidos novos standards, que permitissem melhorar a taxa nominal de dados. Nove anos após (1999) o primeiro modelo, as normas IEEE 802.1b e IEEE a foram aprovadas, sendo que estas usufruíam da gama de frequências entre 2.4 GHz e 5 GHz, possibilitando o alcance de valores entre 11 Mbps e 54 Mbps, respectivamente. Passado algum tempo foi aprovada uma nova norma, designada por IEEE g, que utiliza a gama de frequência 2.4 GHz (como na norma IEEE b), sendo que possui uma taxa nominal de dados no valor de 54 Mbps. Com vista a introduzir qualidade de serviço (QoS) no meio de transmissão, foi desenvolvida uma normal, designada por IEEE e, que implementa quatro filas de diferentes prioridades, de modo a permitir que dados com elevada prioridade sejam transmitidos preferencialmente. Mais recentemente, através da aprovação da norma IEEE n é possível usufruir da gama de frequência desde os 2.4 GHz e/ou 5GHz, com uma taxa nominal de dados até os 600 Mbps. Como é possível observar, o avanço tecnológico no que se refere às comunicações Wi-Fi é elevado. Sendo que este avanço veio trazer grandes mudanças ao meio de transmissão entre equipamentos, proporcionando uma alternativa ao suporte por cabos, mas ainda com algumas limitações. 3 Mais conhecidas do Wi-Fi 4

21 IEEE Mecanismo de acesso ao meio 5 Este capítulo tem como objectivo de apresentar a norma IEEE , descrevendo especificamente o mecanismo de acesso ao meio utilizado, e o que tem vindo a ser desenvolvido de modo a introduzir uma melhor qualidade de serviço às comunicações Wi-Fi IEEE Mecanismo de acesso ao meio O mecanismo utilizado no controlo de acesso ao meio do standard IEEE é o CSMA com Collision Avoidance (CSMA/CA), que se posiciona como apoio para os mecanismos de acesso ao meio. Este mecanismo de modo evitar colisões, utiliza um sistema que permite verificar se o meio está livre ou ocupado. Visto isto, uma estação a quando da transmissão de um pacote, primeiramente escuta o meio num pré-determinado intervalo de tempo, designado por IFS (Interframe Space), com o intuito de verificar se outra estação está a utilizar o mesmo canal de comunicação ou a mesma área de comunicação. Caso o meio de transmissão se encontre livre, após o intervalo de tempo IFS, a estação que pretende transmitir um pacote possui agora a possibilidade para o fazer. Caso o meio esteja ocupado, o número de retransmissões efectuadas será incrementado, e a estação irá aguardar por um intervalo de tempo, designado por backoff, aleatório para uma nova transmissão. Na Figura 2.1Erro! A origem da referência não foi encontrada. é possível observar o fluxo para o envio de um pacote no CSMA/CA. 5

22 6 Norma IEEE Enviar Pacote Escutar o meio Meio livre? Não Activa o Backoff Sim Espera IFS Não Incrementa as tentativas Nº máximo de tentativas alcançado? Escuta o meio Sim Descarta Pacote Meio livre? Não Sim Inicia a Transmissão Não Pacote em Broadcast? Não Espera pelo pacote ACK ACK recebido? Sim Sim Transmissão bem sucedida Figura Fluxograma do CSMA/CA A subcamada MAC do IEEE (Figura 2.2) está dividida por duas funções, pelo DCF e por um mecanismo opcional Point Coordination Function (PCF). O DCF é um mecanismo de suporte do IEEE , que implementa um procedimento, designado de backoff, onde escuta o meio antes de iniciar uma transmissão, de forma a verificar se o meio de transmissão está disponível para a troca de pacotes entre duas estações. O PCF introduz um sistema centralizado de polling, que tem a função de apoiar a sincronização na transmissão de dados, ou seja, quando uma estação é alertada através de polling significa que esta durante um período de tempo tem a permissão de aceder ao meio de transmissão, evitando assim competições entre duas ou mais estações. 6

23 IEEE Mecanismo de acesso ao meio 7 Required for Contention-Free Services MAC Extent Poin Coordination Function (PCF) Distributed Coordination Function (DCF) Used for Contention Services and basis for PCF Figura Arquitectura MAC da norma IEEE O standard IEEE e em redes Wi-Fi, agrega qualidade de serviço (QoS) às redes IEEE , permitindo a transmissão em diferentes classes de tráfego, além de proporcionar o recurso ao Transmission Oportunity (TXOP), que permite a transmissão em rajadas, optimizando a utilização da rede. O QoS, consiste numa capacidade da rede que providencia um tipo de funcionalidade, sendo que, sem suporte do mesmo pacote, ao ser enviado pela rede pode levar um tempo indefinido a chegar ao destino [2]. No caso dos ambientes industriais, este tipo de funcionalidade é fortemente imprescindível devido às necessidades da rede, e à relevante importância da transmissão de dados entre sensores/controladores. Neste tipo de configuração de rede, é incorporada uma função de coordenação, designada por Hybrid Coordination Funtion (HCF), sendo apenas usada em configurações de redes com QoS. Este mecanismo garante acesso ao meio de transmissão através da alocação de oportunidades de transmissão (TXOP) a cada estação. Cada TXOP é definido por um intervalo de tempo, possuindo uma variável de início e outra de máximo, que indica a duração que cada estação possui acesso ao meio. A alocação do meio de acesso é feita através de dois mecanismos específicos do HCF, o Enhanced Distributed Channel Access (EDCA) e o HCF Controlled Channel Access (HCCA). 7

24 8 Norma IEEE Required for Prioritized QoS Services Required for Parameterized QoS Services Required for Contention-Free Services for non-qos STA, optional otherwise Hybrid Coordination Function (HCF) MAC extended Poin Coordination Function (PCF) HCF Contention Access (EDCA) HCF Controlled Access (HCCA) Used for Contention Services, basis for PCF and HCF Distributed Coordination Function (DCF) Figura Arquitectura MAC da norma IEEE e O mecanismo EDCA foi desenvolvido, para melhorar o mecanismo DCF fornecendo diferentes transmissões através de quatro diferenciadas classes de tráfego DCF Distributed Coordination Function O mecanismo DCF é a base dos mecanismos de acesso ao meio da norma IEEE , onde caso o meio esteja livre durante um intervalo de tempo de espera, DIFS (Distributed Interframe Space), a transmissão é iniciada. Em virtude do meio não estar disponível, a estação que tenciona transmitir selecciona um tempo aleatório, designado de backoff (múltiplo da duração de um slot), para que após esse mesmo tempo seja efectuada uma retransmissão. Neste caso, as estações mantêm a escuta do meio de acesso para a retransmissão, num intervalo DIFS. Se o meio de transmissão se encontrar ocupado, devido a interferências ou outras transmissões, o tempo de backoff é parado, de modo a que não seja decrementado até ao meio estar desimpedido, dentro de um intervalo DIFS. Sendo que um novo valor aleatório de backoff é seleccionado para a nova transmissão, levando a que o tamanho da janela de contenção (Contention Window), isto é, tamanho máximo de dados possíveis a retransmitir, seja decrementado. Para que o intervalo de retransmissão esteja sempre actualizado, este é guardado numa variável designada por backoff counter, mas atingindo o valor zero, a estação pode tentar uma nova transmissão. Para que sejam impostas diferentes prioridades a certos dados, é imposto um intervalo de repouso entre novas transmissões, designado por Interframe Space (IFS) (Figura 2.4). Cada nível de prioridade, é definido por diferentes IFSs, havendo os SIFS (Short Interframe Space), usados também para o envio de pacotes ACK, dando assim uma maior prioridade à transmissão dos mesmos; o PIFS (PCF Interfram Space), apenas as estações que operam 8

25 IEEE Mecanismo de acesso ao meio 9 através do PCF o poderão usar; o DIFS (Distributed Interframe Space), é usado por estações que operam sobre o mecanismo DCF, para transmitirem pacotes de dados e pacotes de gestão; e por fim o EIFS (Extended Interframe Space), usado para comunicação de condições de erros. Figura 2.4 Intervalos de espera do mecanismo DCF e PCF PCF Point Coordination Function Com o intuito de melhorar a transmissão em tempo-real, surgiram várias soluções que facultavam uma boa qualidade de serviço. O Point Coordination Function (PCF) é uma das soluções, tendo sido proposto como um mecanismo de acesso ao meio adicional no standard IEEE original [1]. Esta solução introduz um sistema centralizado de polling, que tem a função de apoiar a sincronização na transmissão de dados, onde o Coordenator Point (PC) desempenha o papel de controlo na acção de polling HCCA HCF Controlled Channel Access Além do PCF foi proposto outro mecanismo, designado por HCCA apresentado no standard IEEE e, baseando-se de certa forma na solução apresentada anteriormente, mas com o objectivo de melhorar a solução anterior. Tem como suporte o esquema round-robin, e foi pensado para assegurar os requisitos de atraso limitado, expostos pelo mecanismo PCF. O HCCA baseia-se na estrutura do mecanismo PCF, onde possui um controlador na acção de polling, que efectua essa mesma acção para todas as estações existentes na lista de polling, mesmo que as mesmas não possuam pacotes a transmitir. Neste último caso, a estação corresponde com a transmissão de um pacote sem informação. Devido à funcionalidade central o PC irá sofrer uma sobrecarga dentro de um determinado intervalo de tempo, sendo 9

26 10 Norma IEEE sensivelmente a diferença entre o instante em que é enviado o pacote de polling, e a confirmação da recepção do mesmo, isto é, a recepção do pacote ACK 4. Com a intenção de introduzir melhorias neste mecanismo, de forma a reduzir a sobrecarga no PC, foram propostos vários mecanismos, como a inserção de um framework de controlo substituindo o tradicional CSMA [1], através da taxa média de dados e do tamanho médio dos pacotes, são calculados os recursos necessários para o envio de cada mensagem num fluxo, permitindo assim distribuir os recursos uniformemente consoante a necessidade de cada fluxo. A existência de várias propostas (discutidos em [1]), não implica que todas sejam capazes de suportar comunicações em tempo-real com garantias de QoS. Através de melhorias incluídas no mecanismo HCF (PCF e HCCA) incorporado no IEEE e, serão colmatadas algumas das limitações existentes anteriormente. Mesmo que o mecanismo PCF consiga controlar os sensíveis atrasos das aplicações, é um método bastante complexo e quase nenhuma placa de rede sem fios é capaz de implementar [1]. Contudo, certos estudos têm vindo a mostrar que o mecanismo HCCA não é capaz de garantir requisitos especiais, que poderão surgir nas aplicações de tempo-real. Este mecanismo, pode não vir a ser implementado na próxima geração de cartas de rede WLAN, mesmo que o problema da indisponibilidade do mecanismo PCF seja superado. Posto isto, é importante chegar à conclusão que o mecanismo necessário para a diferenciação de estações com diferentes características temporais, passa por introduzir diferentes métodos no controlo de acesso ao meio (MAC) EDCA Enhanced Distributed Channel Access O mecanismo Enhanced Distributed Channel Access (EDCA) veio introduzir quatro categorias (Figura 2.5) de acesso ao mecanismo já existente DCF, permitindo assim diferenciar serviços no acto da transmissão. 4 ACK : ACKNOWLEDGE 10

27 PRIORIDADE IEEE Mecanismo de acesso ao meio 11 Classes de Tráfego (AC) Cada pacote que seja processado na camada MAC, é definido por uma certa prioridade, que de seguida será mapeada entre as quatro classes de tráfego. ALTA VOZ VÍDEO BEST EFFORT BAIXA APLICAÇÕES DE BACKGROUND Figura Classes de Tráfego - IEEE e Cada classe da Figura 2.5 é baseada nos oito níveis de prioridade do standard IEEE 802.1D (tabela 3.1). Tabela Prioridade IEEE 802.1D para IEEE e Prioridade 802.1D Designação 802.1D Prioridade e Designação e 1 BK Background 2 Spare 0 BE Best Effort 3 EE Excellent Effort 4 CL Controlled Load 5 VI Video 6 VO Voice 7 NC Network Control 0 BK - Background 1 BE Best Effort 2 VI - Video 3 VO Voice 11

28 12 Norma IEEE Para cada classe, é associado um diferente nível de serviço, baseado em três mecanismos independentes, o Arbitration Interframe Space (AIFS), o Transmission Opportunity time interval (TXOP) e o Contention Window (CW). Cada estação que opere sobre EDCA, o pacote irá esperar se o meio de acesso estiver ocupado um intervalo de tempo com a duração AIFS [AC]. Esta duração é dada por: [ ] [ ] (2.1), onde o valor de AIFSN[AC] é um inteiro positivo que deverá ser maior ou igual a dois para todas as estações, excepto no caso de pontos de acesso com suporte de QoS (QAPs) que deverá ser um inteiro maior ou igual a um. Na Figura 2.6 é possível observar a diferença entre o mecanismo EDCA e DCF, como também a relação entre o AIFS de cada categoria de acesso (AC). Figura Mecanismo EDCA Os parâmetros default definidos pelo mecanismo EDCA, estão presentes na Tabela 2.2. Sendo que o valor de acwmin e acwmax, dependem das características da camada física de cada standard, com exemplo, no IEEE e o acwmin=31 e acwmax=

29 Conclusão 13 Tabela Parâmetros do mecanismo EDCA Parâmetros CWmin CWmax AIFSN BK acwmin acwmax 7 EDCA BE acwmin acwmax 3 VI ( ) acwmin 2 VO ( ) ( ) Conclusão A transmissão em tempo-real, através dos mecanismos já existentes não é eficaz ao ponto de garantir na aplicação em certos serviços com necessidade de características temporais de tempo-real. Desde do primeiro desenvolvimento de um mecanismo que introduzisse melhoramentos na comunicação em redes IEEE , até à introdução do standard IEEE e, com a utilização do mecanismo EDCA para o controlo do acesso ao meio, foram introduzidos melhoramentos em grande parte, mas no entanto apareceram outras limitações à comunicação. Portanto, conclui-se que a utilização deste tipo de redes para a troca de tráfego com características temporais rigorosas, ainda não garante grande confiabilidade, o que leva a que sejam desenvolvidos outros métodos/mecanismos que permitam garantir elevadas taxas de sucesso, em comunicações em tempo-real. 13

30 Capítulo 3 Mecanismo RT-WiFi Conforme o que foi concluído no segundo capitulo, a necessidade da introdução de um mecanismo que melhore a transmissão de dados em tempo-real, é evidente. Nesta segunda parte do Capitulo 2 são descritos dois mecanismos que possibilitam o uso da camada MAC do IEEE e, para comunicações de dados em tempo-real em redes IEEE Na camada inferior da norma IEEE , é usada a separação de tráfego com o intuito de garantir a uma estação de tempo-real (RT), uma superioridade no acesso ao meio em relação a estações STD (implementam o mecanismo EDCA com valores AIFSN/CW default). A um nível mais elevado, é implementado o mecanismo TDMA que permite a existência de várias estações RT, através da atribuição de um intervalo de tempo específico para cada uma transmitir Descrição do mecanismo Como foi referido acima, o mecanismo RT-WiFi vem propor qualidade de serviço (QoS) às comunicações em ambientes de tempo-real. Este mecanismo baseia-se na subcamada MAC das redes IEEE e (Figura 3.1). A implementação de um mecanismo que encaminhe o tráfego das estações de tempo-real para um nível mais elevado, é uma das soluções sugeridas. Para que isto aconteça é utilizado, na camada MAC mais baixa, o mecanismo Force Collision Resolution (FCR) [5], que atribui uma maior prioridade ao tráfego das estações de RT em comparação com as STD. 14

31 Descrição do mecanismo 15 Figura Arquitectura RT-WiFi FCR Force Collision Resolution O Force Collision Resolution (FCR) impõe ao tráfego de tempo-real uma maior prioridade através da configuração dos parâmetros AIFS/CW nas estações de tempo-real. São escolhidos valores para que quando uma estação de RT (Real-Time) colidir com uma ou mais estações STD (Standard Topology Default), a estação RT efectue a retransmissão de um pacote antes de qualquer uma das estações STD. Sendo que, nas estações STD que implementam o mecanismo EDCA, a quando uma retransmissão aguardam um intervalo de tempo (backoff) de acordo com os parâmetros definidos em cada categoria de acesso (VI, VO, BE e BK). Com isto, é imposto ao tráfego proveniente de uma estação de RT, uma maior prioridade. Para que uma transmissão de dados seja efectuada ao nível mais elevado de prioridade, a categoria de acesso seleccionada é a de voz (VO), definida no mecanismo EDCA. O valor do AIFSN é o default, e considera-se o valor de CW como acw min =acw max =0. Existe a probabilidade de mais que uma estação de tempo-real esteja a transmitir, o que levará a consecutivas colisões entre duas ou mais estações. Este facto deve-se à configuração da CW, pois considerando o valor da mesma igualado a zero, leva a que o backoff seja desactivado, conduzindo as retransmissões a serem efectuadas no mesmo instante. Para a resolução deste problema é utilizado um mecanismo que permite dividir o meio de transmissão em slots, sendo este designado por Time Division Multiple Access (TDMA). 15

32 16 Mecanismo RT-WiFi No que se refere ao parâmetro TXOP, que permite a transmissão num certo intervalo de tempo limitado, não é considerado devido à existência de transmissão de dados numa única categoria TDMA Time Division Multiple Access Como foi referido anteriormente (3.2 - FCR Force Collision Resolution), a utilização mecanismo TDMA permite eliminar as colisões que perante a implementação do mecanismo FCR surgem. Este mecanismo consiste na divisão da banda de transmissão em vários ciclos de transmissão TDMA, designado por Service Interval (C SI ). Estes ciclos divididos em slots, C id, em que cada estação RT 5 id utiliza o seu respectivo slot param a troca de tráfego. Figura Ciclo do Protocolo TDMA Cada ciclo começa com a transmissão de uma trama designada por Beacon (C beacon ) enviado pelo AP (Access Point). Este é usado como um sincronizador de forma às estações saberem que vai iniciar um intervalo de transmissão. Após a recepção do Beacon cada RT id selecciona o instante de início (SP id ) e instante final (EP id ), respectivamente. Uma estação RT id só pode disputar o acesso à banda de transmissão no seu slot respectivo. As restantes estações, STD, poderão em simultâneo disputar o mesmo intervalo de transmissão, o que pode levar a que colisões ou erros ocorram durante a transmissão de uma estação RT. Com isto serão necessárias retransmissões, estas realizadas em acordo com as regras do standard, que permitem lidar com este tipo de problemas, não deixando que os pacotes transmitidos sejam descartados. Normalmente, as transmissões são finalizadas antes da ocorrência do final do slot (EP id ), no entanto em certas circunstâncias pode ser excedido, no caso de elevado volume de tráfego. Neste último caso a transmissão a decorrer não é 5 Estação id de tempo-real, onde id encontra-se entre 1 e np (1 id np) 16

33 TDMA Time Division Multiple Access 17 abortada, mas não são permitidas retransmissões. Esta situação não leva a que ocorram conflitos entre o slot RT id e o slot seguinte (RT id+1 ), sendo considerado o meio de transmissão ocupado e a transmissão não será iniciada. Como mostra a Figura 3.2 no final do último slot, instante EP np, é necessário considerar um intervalo designado de gap (C gap ), utilizado para assegurar que os pacotes Beacon são transmitidos sincronicamente. Existe esta necessidade, porque em conformidade com o standard o intervalo de tempo entre Beacon s deve ser múltiplo de 1024 µs, não sendo necessariamente um múltiplo de, existindo assim a necessidade de compensação de tempo de forma a alcançar um intervalo múltiplo de 1024 µs. A duração de cada intervalo, C id, deve assegurar um tempo de resposta limitado em aplicações de tráfego em tempo-real, de modo que em cenários onde exista tráfego proveniente de outras estações que não de tempo-real disponham da possibilidade de disputar o meio de acesso com as estações de tempo-real Algoritmo baseado em comunicações TDMA Com base no que foi descrito acima é possível elaborar um algoritmo baseado no protocolo TDMA, de forma a ser aplicado futuramente em estações de tempo-real. Algoritmo 3.1 Recepção de um Beacon 1: 2: 3: 4: 5: 6: [ ] Quando um beacon é recebido por uma estação RT, primeiramente é definido o instante inicial do slot, SP id (linha 2). De seguida é calculado o instante final, EP id (linha 3), de um slot C id. Para finalizar são inicializadas as interrupções de início (linha 4) e de conclusão (linha 5) de um slot C id. Algoritmo 3.2 Interrupção SP id 1: 2: 3: 17

34 18 Mecanismo RT-WiFi O algoritmo 2 ilustra o que se sucede quando a interrupção, usada no algoritmo 1, é executada no instante SP id. Nesse instante, de forma a permitir à estação RT id transmitir a flag GranToSend (linha 2) é activada. Algoritmo 3.3 Interrupção EP id 1: 2: 3: O algoritmo 3 é o inverso do ilustrado no algoritmo 2. Neste caso, quando é alcançado o instante EP id, a interrupção declarada no algoritmo 1 (linha 5),, a flag GranToSend (linha 2) é desactivada. Isto que significa que a estação RT id está impedida de efectuar o envio de um pacote. Algoritmo 3.4 Transmissão 1: 2: 3: A transmissão de um pacote é ilustrada no algoritmo 4, sendo que, só é permitida a uma estação RT transmitir um pacote quando esta possuir a flag GranToSend activa, e a fila de transmissão possuir um ou mais pacotes Análise Temporal Nesta secção, será feita uma análise temporal ao mecanismo TDMA. O intervalo de tempo (C id ), isto é, um slot, em que uma estação RT id, acede ao meio é obtido através da seguinte equação: [ ] (3.1) A variável RN consiste no número máximo de retransmissões que pode ser efectuada em cada slot, e o C att refere-se à duração de uma transmissão (bem sucedida ou não). Já o C guard consiste num intervalo de tempo, designado por slot de vigilância, que permite lidar com possíveis interferências causadas por transmissões de estações STD. O intervalo de tempo necessário para transmitir um pacote (C att ), sendo que poderá ser bem sucedida a transmissão ou ocorrer uma colisão, é dado por: 18

35 Análise Temporal 19 [ ] (3.2) A duração da transmissão de um pacote de dados é definido por C data, e o intervalo necessário para receber a confirmação do envio do mesmo, é decretado por C ack. Esta equação também é valida para o caso de uma transmissão sofrer uma colisão, sendo que o tempo limite para uma transmissão é definido por timeout = SIFS + C ack. O parâmetro C guard, usada na equação [ ] (3.1), define um intervalo de tempo em que uma estação RT id, poderá sofrer interferências. Isto é, este parâmetro declara o máximo atraso que uma estação RT id pode sofrer, antes de tentar aceder ao meio de transmissão. Esta situação ocorre quando um pacote com um tamanho MPDU 6 máximo inicia a transmissão, imediatamente antes do instante inicial de um slot (SP id ). Este parâmetro é dado por: [ ] (3.3) A variável C MPDUmax é a duração de um pacote com o tamanho MPDU máximo, definido pela norma IEEE O instante inicial (SP id ) de um slot, e o instante final (EP id ), correspondente a uma estação de tempo-real id (RT id ) são definidos por: [ ] (3.4) (3.5) O intervalo de tempo correspondente a um ciclo de TDMA, designado por C SI, é dado por: [ ] (3.6) A variável C beacon corresponde à duração de um Beacon, o intervalo de tempo em que uma estação RT id competir pelo meio de acesso é definido por C id e a variável é o valor mínimo entre dois beacons consecutivos. 6 MPDU : MAC Protocol Data Unit 19

36 20 Mecanismo RT-WiFi Conclusão Os mecanismos descritos neste capítulo permitirão que estações com requisitos temporais elevados (Real-Time), e estações que não possuam essa particularidade (STD), usufruam do mesmo meio de acesso sem que existam colisões na transmissão de dados. Conclui-se portanto, que com pequenas alterações ao mecanismo utilizado pelo standard IEEE e, isto é, o mecanismo EDCA, é possibilitado que a transmissão de dados com elevados requisitos temporais, seja eficiente e possua elevado QoS, através da atribuição de elevada prioridade sobre outro tipo de tráfego. Colmatando o problema das colisões entre estações de tempo-real, devido ao primeiro mecanismo, o uso do método TDMA para o acesso ao meio, consegue colmatar tais problemas, reservando para cada estação um intervalo de transmissão. Estes factos foram provados [1], pelo que no seguimento do trabalho serão utilizados de forma a serem validados em ambiente real. 20

37 Capítulo 4 Driver MadWifi O MadWifi (Multiband Atheros Driver WiFi) é um driver open source criado para placas de rede wireless Atheros. Possui suporte de vários modos de operação, como o de estação, AP, Adhoc, Ahdemo e monitorização, sendo que cada modo possui diferentes funcionalidades. O driver MadWifi implementa o protocolo CSMA na camada MAC, como descrito no standard IEEE Usando este driver é possível criar múltiplas interfaces virtuais numa única carta de rede física, onde cada interface virtual pode trabalhar em diferentes modos. Suporta as variáveis a, b e g, derivadas do standard IEEE Nem todo o projecto é open source devido ao facto de depender à camada HAL, isto é, Hardware Abstractions Layer, estando unicamente disponibilizado em formato binário. O driver utiliza a camada HAL para chamar funções impostas ao hardware. Contudo, a comunidade MadWifi desenvolveu um driver, designado por ath5k, que permitirá facultar um driver para cartas WLAN completamente open source, devido às funções do hardware serem invocadas directamente, sem necessidade do uso das funções implementadas na camada HAL. Devido à existência de novos protocolos derivados do standard IEEE , e perante as novas exigências na área das telecomunicações, foi também desenvolvido um driver designado por ath9k que permitirá a operação de redes/equipamentos operação do protocolo IEEE n. Sendo que este projecto está unicamente focado numa pequena modificação no driver MadWifi, não será necessário a modificação de código referente à camada HAL, como também o uso da variável n, o que nos assim permite focar a nossa discussão apenas no driver MadWifi básico, isto é, no driver do equipamento a utilizado. 21

38 22 Driver MadWifi Estrutura do MadWifi O driver pode ser dividido em três camadas (Figura 4.1), que interagem umas com as outras, a quando da sua utilização, sendo elas: fila Net80211, camada HAL e camada ATH. 1. Fila Net80211 corresponde à camada onde são implementadas as funções do protocolo IEEE Camada HAL como foi referido anteriormente, é a camada responsável pelos pedidos efectuados ao hardware. 3. Camada ATH é a camada central do driver, pois posiciona-se como intermediário entre as duas camadas anteriores, Net80211 e HAL, sendo que invoca a camada Net80211 na necessidade de funcionalidades relacionadas com o protocolo IEEE , e interage com a camada HAL a quando da necessidade de uma comunicação com o hardware. TCP/IP Net80211 ATH HAL Figura Arquitectura do MadWifi 22

39 Work Flow do MadWifi Work Flow do MadWifi O driver processa um pacote, quando o mesmo é-lhe enviado pela camada IP, sendo responsável pela inserção do header para posteriormente ser remetido para a camada física. Para que seja possível este pacote ser expedido na rede , o mesmo é encapsulado com o MAC header do standard IEEE Caso haja necessidade do envio de informação adicional, como a taxa de transmissão, a potência de transmissão e o RTS 7, é invocado um descritor da transmissão no driver. Esta informação é enviada para a camada HAL, que configurará o hardware de acordo com os parâmetros definidos, seguidamente o pacote é direccionado para a camada física para ser enviado na rede. A existência de vários tipos de pacotes (dados, gestão e controlo), sendo que cada tipo possui diferentes funcionalidades o driver MadWifi possui diferentes funções que permitem processar cada tipo de pacote. Com isto, é então possível dividir o driver em três categorias diferentes: 1. Transmissão/Recepção de pacotes de dados; 2. Transmissão/Recepção de pacotes de gestão; 3. Transmissão/Recepção de pacotes de controlo; A última categoria é implementada no hardware, sendo que, por exemplo, quando é recebido um pacote acknowledge (ACK), devido a uma transmissão efectuada, este é processado na camada física, e não na camada Net As duas primeiras categorias, estão em certa parte relacionadas, devido a usufruírem tanto ao longo da transmissão como da recepção das mesmas funções, como iremos ver de seguida na figura 3.2 e RTS : Real-Time Strategy 23

40 24 Driver MadWifi Transmissão Com intuito de ilustrar a forma como é efectuada uma transmissão no driver, serão apresentados de seguida um conjunto de fluxogramas, juntamente com uma pequena descrição sobre a função de cada uma das fases. Pacotes de Dados ieee80211_classify() 2 1 ieee80211_hardstart() Figura 4.2 Classificação quanto à prioridade de um pacote de dados O processamento de um pacote que a posteriori será transmitido, tem como inicio a função ieee80211_hardstart() camada Net , que se insere na camada Net Função esta que é invocada pelo kernel para transmitir um pacote, sk_buff *skb, através do equipamento indicado através da estrutura net_device *dev. Primeiramente, o pacote a ser enviado é classificado (ieee80211_classify() camada Net80211) quanto à sua prioridade, para futuramente ser direccionado para a fila de transmissão correspondente consoante a prioridade adoptada. Existem quatro filas de prioridade, VO Voice, VI Video, BE Best Effort e BK Background, sendo a primeira a de maior prioridade e a última a de menor. No fluxo 2 é retornado o valor zero (0) em caso da classificação da prioridade do pacote foi efectuada com sucesso. Após a classificação do pacote a função ath_hardstart() camada ATH - é invocada para prosseguir com o processamento do pacote a transmitir, onde é retornado zero (0) caso o pacote for despachado correctamente para a função ath_hardstart(). 24

41 Work Flow do MadWifi 25 ieee80211_hardstart() ieee80211_encap() 2 1 ath_hardstart() Figura 4.3 Encapsulamento e encriptação de um pacote de dados Nesta segunda fase, a função ath_hardstart() camada ATH - é responsável por invocar a função que encapsula o pacote a ser transmitido. A cargo da função ieee80211_encap() está a inserção do MAC header, e logo de seguida o pacote já encapsulado é retornado para a função ath_hardstart() que invocará a função ath_tx_start() camada ATH - para o envio do pacote. Após invocar a função ath_tx_start() é retornada a variável NETDEV_TX_OK (=0) em caso do envio do envio do pacote foi efectuado com sucesso, ou retorna a variável NETDEV_TX_BUSY (=1) em caso da fila de transmissão estar ocupada ou cheia. Pacotes de Gestão ieee80211_mgmt_output() ath_mgtstart() Figura Processamento de um pacote de gestão Os pacotes de gestão são gerados na função ieee80211_mgmt_output() - camada Net80211 perante o tipo de pacote. Após isto é invocada a função ath_mgtstart() camada ATH - que é responsável pelo envio do pacote, recorrendo-se à função ath_tx_start() camada ATH. Caso o envio do pacote seja finalizado com êxito, será retornado o valor zero (0). 25

42 26 Driver MadWifi Pacotes de Dados e Gestão ath_hardstart() ath_mgtstart() ath_tx_start() Figura Envio de um pacote de dados ou gestão A função ath_tx_start() camada ATH - é onde o fluxo na transmissão de um pacote de dados ou gestão, se intercepta. Esta função é responsável por encriptar o pacote a ser expedido, caso necessite, como também mapear o pacote no buffer DMA 8, e seleccionar a fila de transmissão correspondente de acordo com a prioridade do pacote (controlo de QoS). Esta função também é responsável por criar uma estrutura, que armazena a informação relativa à transmissão. ath_tx_start() ath_tx_txqaddbuf() ath_hal_txstart() Figura 4.6 Inclusão do buffer na fila de transmissão e envio do mesmo Nesta fase, a função ath_tx_txqaddbuff() camada ATH, coloca o buffer na fila seleccionada anteriormente, e invoca a função ath_hal_txstart() camada HAL responsável por remeter o bufffer a transmitir para o hardware. Esta última função retorna o valor um (1), caso a transmissão tenha sido efectuada com sucesso. 8 DMA : Direct Memory Access 26

43 Work Flow do MadWifi 27 Pacote de Dados 2 ieee80211_classify() ieee80211_hardstart() 1 Pacote de Gestão ieee80211_mgmt_output() ieee80211_encap() 2 1 ath_hardstart() ath_mgtstart() ath_tx_start() ath_tx_txqaddbuf() ath_hal_txstart() Figura Fluxograma da transmissão de um pacote de dados/gestão A Figura 4.7 representa um fluxograma de como é efectuada a transmissão de um pacote de dados/gestão, através da junção dos pequenos fluxos descritos anteriormente (desde a Figura 4.2 à Figura 4.6) Recepção Em seguimento à secção anterior ( Transmissão), serão apresentados, de seguida, um conjunto de fluxogramas que permitirão entender, a forma como é feito o processamento de um pacote recebido. Pacotes de Dados e Gestão ath_intr() ath_rx_tasklet() Figura 4.8 Recepção de um pacote de dados/gestão 27

44 28 Driver MadWifi O alerta da recepção de um pacote é feito por uma interrupção que é gerada a nível do hardware. Esta interrupção é gerida pela função ath_intr() camada ATH -, onde através da verificação do tipo de interrupção, é invocada a função correspondente ao processamento do pacote recebido. Neste caso, a função que processará o pacote de dados/gestão é a ath_rx_tasklet() camada ATH onde o pacote é admitido, e o nó receptor é identificado. ath_rx_tasklet() ieee80211_input() Figura 4.9 Verificação do tipo de pacote Após o pacote ser admitido como válido, será analisado o seu conteúdo na função ieee80211_input() camada Net com o objectivo de verificar em que tipo se insere. Após esta verificação, é invocada a função ieee80211_deliver_data() camada Net caso o tipo de pacote seja de dados, ou então será invocada a função ieee80211_recv_mgmt() camada Net80211 para o tipo de pacotes de gestão. Pacotes de Dados ieee80211_input() ieee80211_deliver_data() Pacote de Dados Figura Processamento dos pacotes de dados A função ieee80211_deliver_data(), redirecciona o pacote de dados para a camada superior (TCP/IP), sendo daí endereçado para o endereço MAC correspondente. 28

45 Work Flow do MadWifi 29 Pacotes de Gestão ieee80211_input() ieee80211_recv_mgmt() Pacote de Gestão Figura Processamento dos pacotes de gestão Caso o tipo de pacote seja de gestão, a função que o irá processar é a ieee80211_recv_mgmt(), esta que através do seu conteúdo poderá, como por exemplo, definir os parâmetros do nó de acordo com o beacon recebido. ath_intr() ath_rx_tasklet() ieee80211_input() ieee80211_deliver_data() Pacote de Dados ieee80211_recv_mgmt() Pacote de Gestão Figura Fluxograma da recepção de um pacote de dados/gestão A Figura 4.12Figura 4.7 representa um fluxograma de como é efectuada a recepção de um pacote de dados/gestão, através da junção dos pequenos fluxos descritos anteriormente (desde a Figura 4.8 à Figura 4.11). 29

46 30 Driver MadWifi Estruturas no MadWifi Tabela Estruturas no MadWifi Estrutura Descrição struct net_dev *dev Estrutura correspondente a cada carta de rede wireless. Contem toda a informação referente à mesma struct ath_hal *ah Hardware Access Layer (HAL) API struct ath_softc *sc Armazena os parâmetros de configuração do software para o equipamento struct sk_buff *skb Cada pacote enviado/recebido é armazenado nesta estrutura. skb->data[] contem os dados do pacote struct ieee80211vap *vap Armazena as estatísticas relacionadas com a rede WiFi 30

47 Capítulo 5 Implementação do RT-WiFi Perante a estrutura e o work flow do driver MadWifi, foi possível implementar os mecanismos inseridos na nossa proposta de melhoria, apresentados na secção 0 e 3.3 -, das redes e, suportando transporte de dados em tempo-real. Para este projecto foi apenas necessário focar-nos na parte da transmissão/recepção de pacotes de dados, pois o nosso objectivo é apenas alterar o modo como é efectuada a transmissão de um pacote e não o modo como é feita a aceitação de um AP, a quando um equipamento móvel/fixo tenta aceder à rede TSm Time Separation mechanism Este mecanismo provém da alteração de certos parâmetros do protocolo IEEE e, tendo como designação WME (WiFi multimédia extension) e que através de um conjunto de parâmetros, concede às transmissões a possibilidade de possuir um QoS elevado em comparação com outros protocolos do standard IEEE Existindo assim uma extensão designada por WME (WiFi multimedia extension) que faculta vários parâmetros configuráveis, de forma a permitir uma qualidade de serviço elevada. Com o intuito de implementar o mecanismo TSm, foi necessário impor ao device driver duas regras importantes: A utilização da fila de voz; Retransmissão de um pacote com backoff desactivo. 31