A Subcamada MAC

Na arquitetura em camadas do padrão 802.15.4, a subcamada MAC provê uma entre interface entre a subcamada de convergência de serviços (SSCS - Service Specific Convergence Sublayer) e a camada física. A subcamada MAC dá acesso à camada física, sendo responsável pela implementação das seguintes funcionalidades:

• Acesso ao canal de rádio via slotted e unslotted CSMA-CA; • Validação de frames;• Entrega confiável de dados (entrega com reconhecimento de frames, implementando um

enlace confiável entre duas subcamadas MAC parceiras);• Associação e desassociação de dispositivos à rede;• Gerenciamento de sinalizadores (beacons), no caso de um nó coordenador; • Suporte opcional à implementação de mecanismos de segurança do dispositivo; • Gerencimento de fatias de tempo garantidas (GTS - Guaranteed Time Slot).

As entidades da sub-camada MAC oferecem dois grupos de serviços às camadas superiores:• MAC Data Service (MCPS): provê serviços de transporte de dados entre subcamadas MAC

parceiras, ou seja, viabiliza a transmissão e a recepção de MPDUs (MAC PDUs). Os serviços da subcamada MAC são acessíveis através do ponto de acesso a serviço MCPS-SAP (MAC Common Part Sublayer Data SAP) .

• MAC Management Service (MLME): provê funções de gerenciamento do nível MAC para as camadas superiores. São acessíveis através do ponto de acesso a serviço MLME-SAP (MAC Layer Management Entity SAP).

O MLME também é responsável por manter uma base de dados de objetos gerenciados pertencentes à subcamada MAC, referenciado como MAC PIB (MAC Layer PAN Information Base). A MAC PIB contém atributos/variáveis MAC acessíveis às aplicações. O MLME também tem acesso aos serviços MCPS para o transporte de dados.

Figura 1 - A Camada MAC

Como mostrado na Figura 1, a camada física interage com a subcamada MAC por meio de primitivas de serviço de dados providas através do PD-SAP (Physical Data – Service Access Point) e de primitivas de serviço de gerência providas através do PLME-SAP (Physical Layer Management Entity - Service Access Point) pela entidade de gerência da camada física PLME.

As primitivas da subcamada MAC e da camada física somam um total de 49 no padrão, das quais

35 pertencem à subcamada MAC. Das 35 primitivas da subcamada MAC as principais são:

Serviço de dados MAC: • MCPS-DATA: troca de pacotes de dados entre MAC e camada superior (SSCS).

Serviços de gerenciamento MAC: • MLME-ASSOCIATE/DISASSOCIATE: (Des)associa à rede; • MLME-SYNC / SYNC-LOSS: (Des)sincronização do dispositivo; • MLME-SCAN: verifica os canais de rádio; • MLME-GET / SET: lê/escreve os parâmetros da MAC PIB; • MLME-START / BEACON-NOTIFY: gerenciamento de beacon; • MLME-POLL: sincronização sem beacon; • MLME-GTS: gerência de GTS; • MLME-ORPHAN: gerenciamento de dispositivo órfão; • MLME-RX-ENABLE: habilita/desabilita o sistema de rádio.

Por exemplo, o uso das primitivas relacionadas ao serviço de dados da camada MAC é mostrado na Figura 2 abaixo:

Figura 2 – Exemplo de Primitiva de Serviço MAC

Modos de Operação

Uma rede 802.15.4 possui basicamente dois modos de operação, conforme as demandas das aplicações:

• um modo beacon-enabled, que faz uso periódico de quadros denominados beacons (sinalizadores), que são pacotes de controle que delimitam os quadros utilizados pelo coordenador para sincronizar com os demais dispositivos da rede. Este modo de operação utiliza uma estrutura de dados especial denominada de superframe para sincronizar o acesso ao canal e as transmissões de dados;

• um modo beaconless, que não faz uso de beacons, os quais ficam desabilitados. Neste modo, os dispositivos se comunicam de modo assíncrono, ficando continuamente em “receive mode”, à espera das transmissões dos outros nós. Para as transmissões, os nós competem pelo canal usando o protocolo de acesso unslotted non-persistent CSMA/CA.

O modo beacon-enabled é usado em redes com aplicações que demandam largura de banda dedicada e baixas latências. Os beacons são transmitidos pelo coordenador da PAN e o seu objetivo primário é permitir a sincronização dos dispositivos da rede com o coordenador da PAN,

determinando quando estarão liberados para a transmissão e recepção de mensagens. Numa rede beacon-enabled a necessidade de transmitir e receber beacons regularmente aumenta a carga de demanda por potência nos dispositivos da rede. O coordenador da PAN transmite beacons em intervalos pré-determinados de tempo, que podem variar de 15ms a 245(252)s.

Numa rede nonbeacon-enabled, beacons não são transmitidos regularmemte pelo coordenador (embora ainda sejam necessários para propósitos de associação de um dispositivo com um coordenador). Ao contrário, as comunicações são assíncronas – um dispositivo se comunica com o coordenador apenas quando precisa, o que pode ser relativamente infrequente. Isso permite uma maior conservação da energia do dispositivo.

Estrutura do Superframe

O formato de um superframe é definido pelo coordenador da PAN, e é sempre iniciado com um quadro do tipo beacon. O superframe é composto por uma parte ativa e uma parte inativa (opcional), durante a qual o coordenador pode entrar em um modo de economia de energia. A parte ativa é dividida em um número de intervalos de tempo (slots) de mesmo tamanho, sendo o quadro de beacon transmitido no primeiro slot de cada superframe (Figura 3).

Figura 3 – Superframe: Período Ativo e Período Inativo

Um dispositivo pode transmitir a qualquer momento durante um slot, mas deve completar sua transação antes do próximo beacon. O acesso ao canal durante este período de tempo é baseado em contenção (disputa); entretanto, o coordenador da PAN pode dedicar alguns slots de tempo do período ativo a aplicações que demandem baixa latência ou largura de banda específica. Estes slots de tempo garantidos são chamados de GTS – Guaranteed Time Slots e, em conjunto, formam um período livre de contenção, localizado imediatamente antes do próximo beacon.

Em resumo, a parte ativa do superframe pode ser dividida em dois períodos distintos: um Período de Acesso com Contenção (CAP – Contention Access Period), que sempre deve existir no superframe, e um Período Livre de Contenção (CFP - Contention Free Period), que é opcional.

Figura 4 – Superframe: Contention Access Period (CAP) e Contention-Free Period (CFP)

O período de contenção deve conter, pelo menos, oito slots ativos de tempo, podendo chegar até a 16, que é o valor default. Durante o CAP, o acesso ao canal é feito usando uma variante do CSMA-CA denominada de Slotted CSMA-CA, observando-se que todas as operações baseadas em contenção devem ser completadas antes que o período livre de contenção CFP se inicie.

Já no período livre de contenção o coordenador reserva um conjunto de fatias de tempo, denominado de GTS – Guaranteed Time Slot, para um determinado dispositivo. Durante um período de GTS, o dispositivo tem acesso exclusivo ao canal e não executa CSMA-CA. O período livre de contenção pode acomodar até sete slots de tempo, sendo que um GTS pode ocupar mais de um slot, conforme mostrado na Figura 5.

Figura 5 – Estrutura do Superframe

O tamanho do período livre de contenção pode variar dependendo da demanda dos dispositivos da rede. O início do período livre de contenção e a duração do superframe são comunicados pelo coordenador da PAN aos dispositivos conectados à rede por meio dos beacons. Deve ser observado que todas as operações usando as fatias garantidas de tempo devem terminar antes do início do próximo GTS ou antes do fim do período livre de contenção, como mostrado na figura acima.

Tamanho do Superframe

Do ponto de vista prático, dois tamanhos são importantes: o tamanho total do superframe e o tamanho da sua parte ativa. O tamanho total do superframe é medido pelo intervalo de tempo no qual o coordenador transmite os seus beacons, denominado de Beacon Interval (BI) sendo que pode existir uma porção inativa durante a qual o coordenador pode entrar em estado low-power (modo sleep). O intervalo de tempo relativo somente à parte ativa do superframe é denominada de Superframe Duration (SD).

A duração desses dois intervalos de tempo é definida pelos valores dos parâmetros macBeaconOrder (BO) e macSuperframeOrder (SO) existentes na MAC PIB. Esses parâmetros são determinados pelo coordenador da PAN e controlam, respectivamente, o tamanho total do superframe (parâmetro BO) e o tamanho do período ativo dentro do superframe (parâmetro SO). Para valores iguais de SO e BO, a duração da parte ativa do superframe será igual à duração do intervalo entre beacons e, nesse caso, não existirá a parte inativa dentro da estrutura do superframe. Caso SO < BO, o superframe apresentará uma parte inativa.

O atributo macBeaconOrder (BO) está relacionado ao intervalo de tempo BI em que o coordenador deve transmitir seus beacons e é definido da seguinte forma:

BI = aBaseSuperframeDuration 2∗ BO símbolos onde:

aBaseSuperframeDuration = 960 símbolos (16 slots * 60 símbolos/slot = 960)0 ≤ BO ≤ 14

O atributo BO define a ordem do superframe, isto é, quantas estruturas de duração base formarão o superframe (em última instância, BO define o tamanho total do superframe). Por exemplo, para BO = 0 (superframe de ordem 0), o intervalo entre beacons será: BI = aBaseSuperframeDuration 2∗ BO

= 960 x 20 = 960 símbolos, com o superframe apresentando 16 slots (1 beacon + 15 slots). Para BO = 1 (superframe de ordem 1), o intervalo entre beacons BI será de 960 x 21 = 1920 símbolos, com o superframe apresentando 32 slots (1 beacon + 15 slots + 16 slots), assumindo-se que o tamanho do slot é o mesmo.

O tamanho mínimo de um slot é dado pelo parâmetro aBaseSlotDuration, definido como 60 símbolos em um superframe de ordem zero. Portanto, para um superframe dessa ordem – isto é, com 16 slots – o número total de símbolos no superframe é igual a 16 slots * 60 símbolos/slot = 960 símbolos (ou 960 x 4 bits por símbolo = 1920 bits).

O outro parâmetro importante para o superframe é o macSuperframeOrder (SO), que define a duração da sua porção ativa Superframe Duration (SD) da seguinte maneira:

SD = aBaseSuperframeDuration 2∗ SO símbolos, onde: 0 ≤ SO ≤ BO ≤ 14

Em suma, PANs que desejarem usar a estrutura do superframe devem setar o parâmetro macBeaconOrder com um valor entre 0 and 14, inclusive, e macSuperframeOrder com um valor entre 0 e o valor de macBeaconOrder, inclusive. PANs que não desejarem usar o superframe devem setar os dois parâmetros, macBeaconOrder e macSuperframeOrder com valores igual a 15. Neste tipo de rede, o coordenador não transmite beacons, exceto após receber um comando de beacon request. Além disso, todas as transmissões – exceto os quadros de ack e quaisquer quadros de dados que imediatamente seguem os acks de comandos data request – devem usar o método unslotted CSMA-CA para acesso ao canal. Além disso, nessas redes a reserva de slots de tempo GTS não é permitida.As Figuras 6 e 7 ilustram todos esses parâmetros.

Figura 6 – Superframe: Beacon Interval (BI) e Superframe Duration (SD)

Figura 7 – Superframe: Parâmetros da MAC PIB

Resumo. In the beacon-enabled mode of IEEE 802.15.4, each node employs two system parameters: BO and SO, which define beacon interval (BI) and superframe duration SD, respectively, i.e., BI = aBaseSuperframeDuration x 2BO and SD = aBaseSuperframeDuration x 2SO, for 0 ≤ SO ≤ BO ≤ 14. aBaseSuperframeDuration denotes the minimum number of symbols in an active period, which is fixed to 960 symbols. The active period of each superframe consists of three parts: beacon, contention access period (CAP) and contention free period (CFP), while the active period is further equally divided into 16 time slots called aNumSuperframeSlots. The length of one slot is equal to aBaseSlotDuration x 2SO symbols, where aBaseSlotDuration is the minimum number of symbols in a slot and equal to 60 symbols. Figure 1 shows an example of the superframe structure. In IEEE 802.15.4 standard, BO and SO shall be equal for all superframes on a PAN. All devices shall interact with the PAN only during the active portion of a superframe.

Mecanismo de Acesso ao Meio: Introdução

Como visto, dependendo da configuração de rede, uma rede 802.15.4 pode usar um dos dois mecanismos de acesso ao canal de rádio. Em uma rede com beacon habilitado, o mecanismo slotted CSMA-CA é utilizado pelo MAC para transmissões dentro da porção CAP do superframe; já em redes sem beacon, o método de acesso padrão (“unslotted” CSMA-CA) é usado. Em ambos os casos, o algoritmo é implementado com base em unidades de tempo chamadas “períodos de backoff” (BP = Backoff Period). Um período de backoff é o tempo necessário para se transmitir 20 símbolos ou 4 x 20 = 80 bits, se a rede utilizar o modo de operação da camada física em 2.4GHz. O tamanho de uma unidade do período de backoff é dado pelo parâmetro aUnitBackoffPeriod.

O CSMA-CA deve ser usado antes da transmissão de quadros de dados (data frames) ou de quadros de comando (command frames) transmitidos dentro do CAP, a menos que o quadro possa ser rapidamente transmitido após o acknowledgment de um quadro de comando de data request. O CSMA-CA não deve ser usado na transmissão de quadros beacon em uma rede beacon-enabled, de quadros de acknowledgment (nesse caso, muda-se apenas o modo de operação de RX para TX e transmite-se imediatamente o Ack) ou quadros de dados transmitidos dentro do CFP.

O funcionamento nesses dois métodos é o seguinte. Quando um dispositivo deseja transmitir em uma rede com beacon desabilitado, ele primeiro verifica se um outro dispositivo está transmitindo no mesmo canal. Se assim for, ele espera por um período aleatório (isto é, realiza o procedimento de backoff) ou indica uma falha de transmissão depois de alguns tentativas sem sucesso. Como mencionado, quadros de Ack que estejam confirmando uma transmissão anterior não usam o mecanismo CSMA-CA uma vez que eles são enviados imediatamente após o pacote anterior

recebido (ou seja, o nó que recebeu o pacote simplesmente executa o procedimento de troca de recepção para transmissão e envia imediatamente a confirmação).

Já em uma rede com beacon habilitado, qualquer dispositivo que pretenda transmitir durante o período de contenção espera pelo início do próximo slot de tempo e, então, determina se um outro dispositivo está transmitindo no mesmo slot. Se um outro já está transmitindo, o dispositivo recua por um número aleatório de slots ou então indica uma falha na transmissão depois de algumas tentativas.

No slotted CSMA-CA, as fronteiras dos períodos de backoff de cada dispositivo da PAN devem estar alinhadas com as fronteiras dos slots do superquadro do coordenador PAN, isto é, o início do primeiro período de backoff de cada dispositivo é alinhado com o início da transmissão do beacon. A subcamada MAC deve assegurar que a camada física inicie todas as suas transmissões no limite de um período de backoff. No unslotted CSMA-CA, os períodos de backoff de um dispositivo não estão relacionados no tempo aos períodos de backoff de qualquer outro dispositivo da PAN.

Mecanismo de Acesso ao Meio: Parâmetros da MAC PIB

Como visto, no modo de operação com beacon desabilitado, o padrão IEEE 802.15.4 utiliza a técnica unslotted CSMA/CA para controle de acesso ao meio. Em tal técnica, uma transmissão se inicia com a espera por um tempo aleatório de períodos de backoff entre 0 e 2BE - 1, onde BE = Backoff Exponential, podendo BE assumir um valor entre 3 (macMinBE) e 5 (macMaxBE). O parâmetro macMinBE é uma constante cujo intervalo de valores está entre 0 e macMaxBE, com valor default igual a 3. Por sua vez, o intervalo de macMaxBE é de 3 a 8, com valor default igual a 5. Logo, macMinBE pode assumir valores entre 0 e 8, com valor default 3.

Uma vez que o tempo selecionado expira, o nó verifica se o canal está disponível para transmissão, procedimento denominado de Clear Channel Assessment (CCA). Esse procedimento é executado no tempo de 8 símbolos. Se o canal estiver ocupado, o nó incrementa BE (limitado a macMaxBE) e repete o processo de espera. O limite de tentativas de acesso ao canal é determinado por macMaxCSMABackoffs (4 tentativas, por default). Se, após essas tentativas, o nó não conseguir ter acesso ao canal, é declarada uma falha de acesso ao canal. Se o canal estiver livre, executa-se o procedimento de troca de modo do rádio – de recepção para transmissão – e transmite-se o pacote. O tempo de execução da troca de modo do rádio é de 12 símbolos.

Na transmissão de um pacote, pode ser solicitada a confirmação de recebimento (ACK - acknowledgement). O procedimento de acesso ao canal não é realizado para envio do ACK, ou seja, o nó que recebeu o pacote simplesmente executa a troca de recepção para transmissão e envia imediatamente a confirmação. Se ocorrer uma falha na recepção do ACK, o nó que enviou o pacote tentará transmiti-lo novamente, após a espera de um macAckWaitDuration (54 símbolos no modo 2.4GHz). É declarada uma falha de transmissão por colisão se o reconhecimento não for recebido após um número de tentativas determinado por macMaxFrameRetries (3 tentativas por default).

Verifica-se que as características do unslotted CSMA/CA tornam a rede mais susceptível a colisões e incita uma maior disputa pela utilização do meio do que em modos que utilizam beacons para sincronização. Além disso, dispositivos IEEE 802.15.4 operando em unslotted CSMA/CA deixam de escutar o canal durante a inversão do rádio, havendo riscos de colisões. Estas colisões podem ocorrer no início da transmissão de um pacote ou na transmissão do pacote de reconhecimento.

Como apresentado na Figura 8, o tempo de verificação de atividade no canal somado ao tempo de inversão de rádio é de 20 símbolos. A colisão no início da transmissão ocorre se outro dispositivo

iniciar o procedimento de CCA durante os 12 primeiros símbolos deste processo, pois, se isto ocorrer, o procedimento de CCA será completado com o canal ainda livre.

Figura 8 – Colisão no início da transmissão

Uma colisão na transmissão do pacote ACK é exemplificada na Figura 9. Como a duração de um CCA (8 símbolos) é inferior ao tempo de inversão do rádio (12 símbolos), existe uma janela de colisão de 4 símbolos. Assim, se um nó iniciar o procedimento de CCA nesta janela para transmissão de um ACK, ocorrerá uma colisão. Um outra situação de colisão é mostrada na Figura 10.

Figura 9 – Colisão durante a transmissão do quadro ACK

Figura 10 – Outro exemplo de colisão

Acesso ao Meio: Batery Life Extension

Em aplicações com baixas taxas de dados, a atividade associada ao monitoramento resulta em um ciclo de trabalho (“duty cycle”) pequeno, com consumo de energia mais reduzido. Entretanto, em cenários de altas taxas de dados, em que longos períodos de monitoramento (polling) são necessários, existe um consumo de energia muito mais acentuado.

O IEEE 802.15.4 suporta um modo de operação denominado "Life Batery Extension (BLE)”, em que o parâmetro Backoff Expoent (BE) do CSMA-CA é limitado ao intervalo 0-2, permitindo reduzir muito o ciclo de trabalho em aplicações de baixo tráfego. No entanto, em condições de redes densas, este modo pode resultar em uma taxa de colisões excessiva.

Acesso ao Meio: O Algoritmo Slotted CSMA/CA

O algoritmo slotted CSMA/CA também tem a sua operação baseada nos períodos de backoff (BP - Backoff Periods). O algoritmo depende fundamentalmente de três variáveis:

1. O Backoff Exponent (BE), parâmetro que está relacionado a quantos períodos de backoff o dispositivo deve esperar antes de tentar acessar o canal;

2. A Contention Window (CW), que representa o tamanho da janela de contenção medida em número de períodos de backoff durante o qual o canal deve ser sentido inativo antes dele ser efetivamente acessado pelo dispositivo, e

3. O Number of Backoff (NB), que representa o número tentativas de acesso ao canal.

A Figura 11 apresenta o fluxograma do CSMA/CA em suas versões slotted e unslotted.

Primeiramente, o Number of Backoff e a Contention Window são inicializados com os valores NB = 0 e CW = 2. Em redes unslotted ou em redes slotted nas quais o campo do superframe “Battery Life Extension (BLE)” é igual a 0, BE deve ser inicalizado com o valor macMinBE (default = 3). Em redes slotted nas quais o campo Battery Life Extension = 1, BE deve ser inicializado com o menor valor entre 2 e macMinBE. Note que se macMinBE for igual a zero, a característica de “collision avoidance” do algoritmo ficará desabilitada durante a primeira iteração.

Em seguida, o algoritmo inicia um contador de número randômico de períodos de backoff (BP – Backoff Periods), uniformemente gerado entre 0 e 2BE – 1. O contador deve se iniciar na fronteira do BP para garantir sincronismo. Quando os períodos de backoff expiram, o algoritmo executa a operação CCA nos limites dos BPs para avaliar a atividade do canal. Se o canal estiver ocupado, CW é reinicializado para CWini = 2, e os parâmetros número de tentativas de acesso ao canal (NB) e expoente de backoff (BE) são incrementados, observando-se que BE não deve exceder macMaxBE.

Se o número máximo de backoffs é alcançado (ou seja, se NB = macMaxCSMABackoffs = 5), o algoritmo informa uma falha para a camada acima; caso contrário, a operação de backoff é reiniciada. Na verdade, o protocolo permite um número de tentativas depois de cada fracasso, que corresponde ao valor do parâmetro aMaxFrameRetries (valor default = 3).

Uma vez que o canal estiver ocioso, CW é decrementado. A operação CCA é repetida se CW for diferente de 0. Se o canal é sentido novamente como inativo, o nó tenta transmitir desde que o restante do BPs no atual CAP seja suficiente para transmitir o quadro e o reconhecimento subseqüente. Caso contrário, o CCA e o quadro de transmissão são ambos deferidos para o próximo superframe. Isto é chamado de “deferência de CCA”.

Figura 11 – O Método de Acesso CSMA/CA

Mediante a isso, em redes com quadros de sinalização para sincronismo, o mecanismo slotted CSMA/CA deve ser criteriosamente avaliado, uma vez que seu comportamento é afetado por seus parâmetros de inicialização, quais sejam: (i) o mínimo backoff exponent (macMinBE); (ii) o máximo backoff exponent (aMaxBE); o (iii) valor inicial do CW (Cwinit); e (iv) o número de máximo de backoffs (macMaxCSMABackoffs).

Resumo. In CAP, each node performs the CSMA/CA algorithm before transmitting data frame or MAC command frame. Each device maintains three parameters: the number of backoff (NB), contention window (CW), and backoff exponent (BE). NB denotes the required NB while attempting to transmit data; CW denotes the number of backoff periods that need to be clear before committing

transmission; and BE denotes how many backoff periods a device need to wait before trying to access the channel. The initial value of NB, CW, and BE are equal to 0, 2, and macMinBE, respectively, where macMinBE is equal to 3. In the located boundary of the next no atual CAP backoff period, a device takes delay for random backoff between 0 and 2BE – 1 unit backoff period (UBP), where UBP is equal to 20 symbols (or 80 bits). A device performs clear channel assessment (CCA) to make sure whether the channel is idle or busy, when the number of random backoff periods is decreased to 0. The value of CW will be decreased by one if the channel is idle; and the second CCA will be performed if the value of CW is not equal to 0. If the value of CW is equal to 0, it means that the channel is idle after twice CCA; then a device is committed the data transmission. However, if the CCA is busy, the value of CW will reset to 2; the value of NB is increased by 1; and the value of BE is increased by 1 up to the maximum BE (macMaxBE), where the value macMaxBE is equal to 5. The device will repeatedly take random delay if the value of NB is less than the value of macMaxCSMABackoff, where the value of macMaxCSMABackoff is equal to 4; and the transmission attempt is decided to be failure if the value of NB is greater than the value of macMaxCSMABackoff.

Formato do Quadro 802.15.4

No padrão 802.15.4, a estrutura geral da PDU do nível MAC (MPDU) foi projetada para ser flexível o bastante para acomodar as necessidades de diferentes aplicações e topologias de rede e, ao mesmo tempo, permitir a definição de um protocolo de nível MAC relativamente simples.

O formato genérico de um quadro MAC (MPDU) e o seu encapsulamento na camada física são mostrados, respectivamente, nas Figuras 12 e 13. Como se vê, o MPDU é composto por um cabeçalho (MHR – MAC Header), por uma Unidade de Serviço de Dados (MSDU – MAC Service Data Unit) também referenciada de MAC Payload, e por um rodapé (MFR – MAC Footer).

Figura 12 – Formato Genérico de uma MAC PDU

Figura 13 – Encapsulamento de uma MAC PDU na Camada Física

O cabeçalho contém informações sobre o tipo de quadro (a norma define quatro diferentes tipos de quadro, todos eles baseados no formato genérico), o número de sequência (que varia de acordo com o tipo de pacote enviado), as identificações de endereços (da rede PAN destinatária e remetente, e o endereço do dispositivo destinatário e remetente) e um campo que informa as opções de segurança utilizadas no quadro. O payload contém os dFigura 13 – Encapsulamento ados provindos da camada acima e o rodapé (MFR) contém a sequência de verificação de erros do quadro.

O primeiro campo do cabeçalho é o campo de controle de quadro (Frame Control). Este campo indica o tipo de quadro MAC sendo transmitido, define o formato do campo de endereço, e controla o reconhecimento (acknowledgment) de quadros. Em suma, o campo de controle determina como é o restante do frame e o que ele contém.

O tamanho do campo de endereço pode variar entre 0 e 20 bytes. Por exemplo, um quadro de dados pode conter a informação de endereço fonte e de destino, enquanto que um quadro de acknowledgment não contém qualquer informação de endereço. Por outro lado, um quadro beacon pode conter apenas informação de endereço de origem. Além disso, endereços curtos ou endereços IEEE de 64 bits podem ser usados. Esta flexibilidade exibida pelo formato do quadro MAC ajuda a aumentar a eficiência do protocolo, mantendo os pacotes curtos.

O cabeçalho MAC também trata das opções auxiliares de segurança usadas na transmissão do quadro. Para tanto é utilizado o padrão de criptografia avançado (AES), que descreve rotinas de segurança utilizando chaves com comprimento de 128, 192 ou 256 bits.

O campo de payload possui tamanho variável; entretanto, observa-se que o tamanho total de quadro MAC não pode exceder 127 bytes de comprimento. Os dados contidos no campo de payload são dependentes do tipo de quadro.

Outros campos do quadro MAC são o número de seqüência e a seqüência de verificação de quadro (FCS - Frame Sequence Check). Numa rede 802.15.4 uma transação só é considerada um sucesso quando o quadro de reconhecimento (ack) contém o mesmo número de seqüência do quadro recebido previamente. O FCS ajuda verificar a integridade do quadro MAC. O FCS é implementado como uma verificação de redundância cíclica (CRC – Cyclic Redundancy Check) de 16-bit padronizado pelo do ITU-T.

Campo: Frame Control

O campo de controle do cabeçalho MAC possui o seguinte conteúdo:

Figura 14 – Formato do Campo Frame Control

Frame TypeApresenta os seguintes valores (a faixa entre 100 a 111 é considerada “Reserved”).:

000 – Beacon 001 – Data 010 – Ack 011 – Command

Security Enabled Deve ter valor 1 se está protegido pelo MAC. Neste caso, o campo Auxiliary Security Header deve estar presente. Se 0, não há proteção no nível MAC.

Frame PendingDeve ter o valor 1 se o dispositivo que está enviando o quadro tem mais dados para o receptor e zero caso contrário. Este campo só deve ser usado em quadros beacon ou em quadros transmitidos durante o CAP numa rede beacon-enabled, ou então a qualquer momento por dispositivos operando numa rede nonbeacon-enabled. Em todas as outras situações ele deve ter o valor 0 na transmissão e ignorado na recepção.

Acknowledgment Request (AR) Especifica se um acknowledgment é requerido do receptor na recepção de um quadro de dados ou de comando. Se igual a 1 o receptor deve enviar o ack, mas somente se as condições estabelecidas para envio forem cumpridas (ex: o número de sequência incluído nos dados recebidos ou no comando MAC deve ser copiado para o campo de número de sequência do quadro reconhecido. Isso garante ao originador da transação saber que ele recebeu o a acknowledgment apropriado).

PAN ID CompressionSe igual a 1 e os endereços de origem e destino estão incluídos no quadro, indica que deve ser assumido que o campo Source PAN Identifier omitido do cabeçalho deve ser considerado igual ao campo Destination PAN Identifier.

Destination Addressing Mode e Source Addressing Mode Podem assumir os seguintes valores (Figura 15):

Figura 15 – Valores possíveis de Destination Addressing Mode e Source Addressing Mode

Frame Version Especifica o número da versão do frame. O valor 0 indica compatibilidade com o padrão IEEE Std 802.15.4-2003.

Campo: Sequence NumberEspecifica a sequência de identificação do quadro. Para quadros beacon, especifica um BSN. Para quadros do tipo data, acknowledgment ou command, o número de sequência DSN é usado para fazer o casamento (“match”) de um quadro de acknowledgment com um quadro de dados ou um quadro de comando.

Campo: Destination PAN IdentifierQuando presente, especifica o identificador único da PAN do receptor do quadro. Um valor de 0xFFFF representa o identificador de broadcast de PAN, que deve ser aceito como um identificador de PAN válido por todos os dispositivos correntemente ouvindo naquele canal.

Campo: Destination AddressQuando presente, define o endereço do receptor. Um valor de 0xFFFF representa o endereço curto

de broadcast, que deve ser aceito como um endereço válido por todos os dispositivos correntemente ouvindo naquele canal.

Campo: Source PAN IdentifierQuando presente, especifica o identificador único da PAN do dispositivo transmissor do quadro. Este campo deve ser incluído no quadro apenas se o campo Source Addressing Mode é diferente de zero. O identificador da PAN de um dispositivo inicialmente determinado durante o processo de associação do dispositivo à PAN mas pode mudar em decorrência de uma resolução de um conflito de identificadores de PAN.

Campo: Source AddressQuando presente, especifica o endereço do dispositivo transmissor do quadro.

Campo: Auxiliary Security HeaderEspecifica informação requerida para o processamento de segurança. O campo deve estar presente somente se o bit “Security Enabled” do campo de controle do cabeçalho estiver ligado.

Campo: Frame PayloadContém informação específica do tipo de quadro. Se o bit “Security Enabled” cabeçalho estiver ligado o payload pode estar protegido por criptografia.

Campo: FSC FrameContém o resultado da aplicação do CRC de 16 bits do ITU-T sobre o cabeçalho e o payload.

Tipos de Quadro MAC

Como mencionado, o nível MAC define quatro tipos diferentes de quadros (frames). São eles:• Beacon frame: usado pelo coordenador para transmitir beacons;• Data frame: usado em todas as transferências de dados;• Acknowledgment frame: usado para confirmar o sucesso na recepção de um quadro;• Command frame: usado para controlar as transferências entre entidades MAC parceiras.

Apenas os quadros de dados e os quadros beacon contém informações enviadas pelas camadas superiores; os quadros de reconhecimento e quadros de comandos MAC são quadros originados no próprio MAC e são usados para comunicação peer-to-per (subcamadas MAC parceiras).

O Quadro de Sinalização (Beacon Frame)

Quadros beacon se originam de dentro da camada MAC, a partir do nó coordenador, numa rede beacon-enabled. O beacon é sempre transmitido no início do slot 0 do superframe, sem fazer o uso de CSMA. A Figura 16 a ilustra o formato do quadro beacon.

Figura 16 – Formato do Quadro Beacon

O quadro beacon carrega várias informações importantes sobre a rede. Ele especifica, dentre outras coisas: a estrutura do superframe, a identificação do coordenador da PAN, informações sobre os campos GTS, quem tem dados pendentes no coordenador e se o coordenador está aceitando novos dispositivos, por exemplo.

Campo: Superframe Specification

Este campo, mostrado na Figura 16, define os principais parâmetros relacionados ao formato (tamanho) da estrutura do superframe: (i) Beacon Order (BO), que especifica o intervalo de transmissão entre beacons; (ii) Superframe Order (SO), que define o tamanho da parte ativa do superframe (isto é, estado de receiver habilitado), (iii) Final CAP Slot, que define qual é o slot final usado no CAP. A duração do CAP deve ser maior ou igual ao valor especificado pelo parâmetro aMinCAPLength.

Além desses três campos, são ainda definidos três outros campos importantes. Um deles é o BatteryLifeExtension, que está relacionado à conservação da bateria. Se esse campo é assinalado como TRUE, todas as transações contention-based tem que começar dentro de um tempo igual a macBattLifeExtPeriods períodos de backoff (valor default 6) após o inter-frame space (IFS) do quadro de beacon. O IFS é um tempo necessário para a camada física processar o pacote recebido da camada MAC. Todo frame transmitido deve ser seguido de um período de IFS, cujo tamanho depende do tamanho do quadro que está sendo transmitido.

Figura 17 – IFS – Inter-Frame Space

O campo PAN Coordinator informa quem está transmitindo o beacon: se o coordenador da PAN (valor igual a 1) ou não (valor igual a 0). Por último, o campo Association Permit define se o coordenador da PAN está atualmente aceitando novos pedidos de associação. É igual a 1 se o parâmetro macAssociationPermit é colocado em TRUE, significando que novas associações estão sendo aceitas.

Campo: GTS

O GTS é um campo de tamanho variável dentro do superframe e possui o seguinte formato:

Figura 18 – Formato do Campo GTS

GTS SpecificationO campo GTS Specification é formatado como na Figura 19. O campo GTS Descriptor Count define o número de GTS Descriptors existentes na GTS List. Se esse valor é igual a zero, os campos

GTS Directions e GTS List do quadro beacon não existem. O campo GTS Permit indica se o coordenador da PAN está aceitando pedidos de GTS. É igual a 1 se o parâmetro macGTSPermit é TRUE; do contrário deve ser igual a 0.

Figura 19 – Formato do Campo GTS Specification

GTS Directions É formatado como mostrado na Figura 20. GTS Directions Mask é uma máscara que diz a direção de cada GTS no superframe, conforme definido pela GTS List. Cada bit da máscara deve ser colocado em 1 se o GTS é “receiver-only” ou em 0 se ele é “transmit-only”. A direção do GTS é definida relativamente à direção da transmissão do quadro de dados pelo dispositivo.

Figura 20 – Formato do Campo GTS Directions

GTS ListCada GTS Descriptor da GTS List possui as informações listadas na Figura 21. Como visto, o número de descritores da GTS List é especificada no campo GTS Specification, e é limitado a 7.

Figura 21 – Formato do Campo GTS List

O Device Short Address contém o endereço curto do dispositivo para o qual o GTS está associado; o GTS Starting Slot define o slot de início deste GTS dentro do superframe e o GTS Length contém o número de slots contíguos do superframe daquele GTS.

Campo: Pending Address O campo Pending Address possui o formato geral apresentado na Figura 22(a) e contém uma especificação básica sobre os endereços pendentes, além da lista destes endereços.

Figura 22(a) - Formato do campo Pending Address

O campo Pending Address Specification informa basicamente o número de endereços curtos e estendidos contidos no campo Address List. A Figura 22(b) mostra um detalhamento do campo Pending Address Specification:

Figura 22 – Formato do campo Pending Address Specification

O campo Address List, cujo tamanho é determinado pelos valores especificados no campo Pending Address Specification, contém os endereços dos dispositivos que possuem correntemente mensagens pendentes com o coordenador. A lista de endereços não deve conter o endereço broadcast curto.

O número máximo de endereços pendentes é limitado a sete e pode compreender tanto endereços curtos como estendidos. Os endereços curtos devem aparecer primeiro na lista.

Campo: Beacon Payload

É uma sequência opcional de bytes de tamanho limitado a aMaxBeaconPayloadLength, especificada pela camada acima para ser transmistida no quadro beacon. O conjunto de bytes a ser transmitido no payload é copiado de macBeaconPayload.

O Quadro de Dados (Data Frame)

O quadro de dados é usado para viabilizar a transferência de dados entre dois nós da rede. Este tipo de quadro é construído pela camada MAC ao receber um comando Data Request da camada usuária acima. A estrutura do quadro de dados é mostrada na Figura 23.

Figura 23 – Formato do Quadro de Dados

No Frame Control, o campo Type possui o valor 001, indicando um quadro de dados e o campo Security Enabled é colocado em 1 caso a segurança seja habilitada. O campo Sequence Number contém o número de sequência do quadro, que deve ser igual ao valor corrente da variável macDSN. Os campos de endereço contém o endereço destino e/ou endereço origem dependendo dos settings do campo de Frame Control e o Auxiliary Security Header, se presente, contém a informação requerida para o processamento de segurança do quadro.

O Processo de Transferência de Dados

Como visto, numa rede 802.15.4 o coordenador da PAN pode operar a sua rede com ou sem superframe. No primeiro caso, ele inicia o superframe com um quadro beacon, que tem propósitos de sincronização e também serve para descrever a estrutura do superframe e enviar informação de controle para os dispositivos da PAN. Quando um dispositivo necessita enviar dados para o coordenador (fora do GTS) ele deve aguardar pelo quadro beacon para se sincronizar e depois competir pelo acesso ao canal. Por outro lado, a comunicação do coordenador para um dispositivo é indireta: o coordenador armazena os dados e anuncia a situação de entrega pendente no quadro beacon. Os dispositivos (finais) usualmente dormem a maior parte do tempo e acordam periodicamente para ver se tem dados pendentes a receber do coordenador verificando os beacons recebidos do seu coordenador. Quando eles percebem que existe uma mensagem disponível para eles, eles a requisitam explicitamente durante o CAP. Por fim, quando um coordenador A deseja falar com um outro coordenador B, ele deve se sincronizar com o beacon de B e agir com um

dispositivo final.

Na comunicação sem superframe, o coordenador da PAN nunca envia beacons, e a comunicação acontece na base do unslotted CSMA-CA. O coordenador está sempre ligado (ON) e pronto para receber dados de um dispositivo final enquanto que a transferência de dados na direção oposta é “poll-based”: o dispositivo final periodicamente acorda e faz um “polling” no coordenador buscando por mensagens pendentes. O coordenador envia essas mensagens ou entao sinais informando que elas não estão disponíveis. Já a comunicação entre coordenadores não apresenta nenhum problema já que ambos os nós permanecem ativos (ON) todo o tempo.

Em resumo, no padrão 802.15.4, existem três tipos de operações de transferência de dados: (i) transferência de dados de um dispositivo para um coordenador; (ii) transferência de dados de um coordenador para um dispositivo; e (iii) transferência de dados entre dois dispositivos pares numa rede multi-hop. Na topologia em estrela, só duas dessas transações são usadas porque os dados só podem ser transmitidos entre o coordenador e um dispositivo. Em uma topologia ponto-a-ponto, os dados podem ser trocados entre quaisquer dois dispositivos na rede; consequentemente, as três operações podem ser utilizados nesta topologia.

Transferência de Dados de um Dispositivo para o Coordenador

Quando um dispositivo deseja transferir dados para um coordenador em uma beacon-enabled PAN, ele primeiro escuta pelo beacon. Quando este é encontrado, o dispositivo é sincronizado com o superframe. No momento apropriado, o dispositivo transmite seu quadro de dados ao coordenador usando slotted CSMA-CA. O coordenador pode reconhecer a recepção com sucesso dos dados através da transmissão de um quadro de Acknowledgment opcional. Esta sequência está resumida na Figura 24.

Figura 24 – Transferência de Dados de Dispositivo para Coordenador (rede com beacons)

Se a rede não usa beacons, o dispositivo simplesmente transmite os seus dados para o coordenador usando unslotted CSMA-CA. O coordenador confirma a recepção dos quadros transmitindo um quadro Ack opcional. Esta sequência é sumarizada na Figura 25.

Figura 25 – Transferência de Dados de Dispositivo para Coordenador (rede sem beacons)

Transferância de Dados do Coordenador para um Dispositivo

Quando o coordenador quer transferir dados para um dispositivo em uma rede beacon-enabled, ele indica no quadro beacon que a mensagem de dados está pendente. O dispositivo periodicamente escuta por beacons e, se uma mensagem está pendente, transmite um comando MAC solicitando os dados, usando slotted CSMA-CA. O coordenador reconhece a recepção bem sucedida do pedido de dados transmitindo um quadro de confirmação. Os dados pendentes são, então, enviados usando slotted CSMA-CA ou, se possível, imediatamente após o reconhecimento. O dispositivo pode reconhecer a recepção com sucesso dos dados, transmitindo um quadro de confirmação opcional. Após a conclusão da operação, a mensagem é removida da lista de mensagens pendentes do beacon. Esta sequência é sumarizada na Figura 26.

Figura 26 – Transferência de Dados do Coordenador para um Dispositivo (rede com beacons)

Quando um coordenador deseja transferir dados para um dispositivo em uma PAN sem beacon habilitado, ele armazena os dados esperando o dispositivo apropriado fazer contato solicitando os dados. Um dispositivo pode estabelecer contato através da transmissão de um comando MAC de requisição de dados ao seu coordenador, a uma taxa definida pela aplicação, usando unslotted CSMA-CA. O coordenador reconhece a recepção bem sucedida do pedido de dados pela transmissão de um quadro de confirmação. Se um quadro de dados encontra-se pendente, o coordenador transmite os dados para o dispositivo utilizando unslotted CSMA-CA. Se não existe um quadro pendente, o coordenador indica este fato seja no quadro de confirmação após a requisição de dados ou em um quadro de dados com payload de comprimento zero. Se solicitado, o dispositivo reconhece a boa recepção do quadro de dados através da transmissão de um quadro de confirmação. Esta sequência é resumida na Figura 27.

Figura 27 – Transferência de Dados do Coordenador para um Dispositivo (rede sem beacons)

Transferência peer-to-peer

Existe ainda a possibilidade de comunicação entre dispositivos não coordenadores no modo peer-to-peer, não necessitando sincronização para a troca de mensagens. Numa rede peer-to-peer, cada

dispositivo pode se comunicar com qualquer outro que estiver na esfera de alcance do seu rádio. Para isso, o dispositivo simplesmente transmite os seus dados usando unslotted CSMA-CA.

Primitivas de Serviço Usadas na Transferência de Dados

O diagrama de sequência da Figura 28 mostra as primitivas de serviço que são trocadas em uma solicitação de transferência de dados realizada com sucesso. Nota-se que MCPS-DATA.request é a primitiva de serviço usada para solicitar ao MAC o início da transferência de dados de um dispositivo a outro.

Figura 28 – Diagrama de Sequência de um MCPS-DATA.request realizada com Sucesso

Alguns dos parâmetros da primitiva MCPS-DATA.request são mostrados na Figura 29.

Figura 29 – Parâmetros da Primitiva MCPS-Data.request

Resumindo a Transferência de Dados. Quando um dispositivo deseja enviar dados para um coordenador no modo de operação com a estrutura do superframe habilitada, primeiramente ele deve esperar o recebimento de um beacon para que ocorra a sincronização com o superframe. Em um tempo apropriado, a informação coletada na rede é transmitida para o coordenador usando o slotted CSMA-CA. O coordenador, opcionalmente, pode enviar uma mensagem de reconhecimento para garantir que o pacote chegou corretamente (Figura 30a). Entretanto, quando a estrutura do superframe não é habilitada, o dispositivo não necessita esperar o recebimento de um beacon para enviar uma informação. Em um tempo apropriado, a informação é transmitida utilizando o unslotted CSMA-CA (Figura 30b).

Figura 30 – Transferência de Dados do Coordenador para um Dispositivo: (a) com beacons; (b) sem beacons

Quando um coordenador deseja enviar dados para um dispositivo no modo de operação com a estrutura do superframe habilitada, ele indica explicitamente no beacon sua intenção de transmissão. Um dispositivo na rede deve esperar o beacon vindo do coordenador para então sincronizar com ele utilizando o slotted CSMA-CA, disputando com os outros dispositivos durante o período de tempo CAP (Contention Access Period), ou esperando sua vez durante o período de CFP (Contention Free Period), no qual existem timeslots reservados pelo coordenador para cada equipamento na rede. Ao receber um beacon, o dispositivo percebe que uma mensagem está pendente e, dessa forma, envia uma requisição para o coordenador, autorizando-o a transmitir a informação. Ao receber a autorização, o coordenador envia uma mensagem de reconhecimento informando que a autorização chegou corretamente e, em seguida, a informação pendente é transmitida utilizando-se slotted CSMA-CA. Este procedimento é ilustrado na Figura 31(a). Entretanto, quando a estrutura do superframe não está habilitada, o procedimento é ligeiramente diferente. No caso, dispositivos de rede são configurados para enviarem mensagens periodicamente ao coordenador para saber se informações estão pendentes. Caso alguma informação esteja pendente, o coordenador as envia para os dispositivos conforme a descrição da Figura 31(b).

Figura 31 – Transferência de Dados do Coordenador para um Dispositivo - (a) com beacons; (b) sem beacons

Quadro de Confirmação (Acknowledgment Frame)

Este tipo de quadro é usado pela camada MAC para confirmar o recebimento de quadros de dados e quadros de comandos trocados entre os nós da rede. O quadro de Acknowledgment apresenta a estrutura mostrada na Figura 32:

Figura 32 – Formato do Quadro de Acknowledgment

O campo type do Frame Control apresenta o valor 010, indicando um quadro de confirmação. O

quadro Ack possui apenas um cabeçalho e um rodapé, não possuindo campo de payload (carrega zero bytes). O cabeçalho MHR possui apenas os campos Frame Control e Sequence Number.

Se o quadro de confirmação está sendo enviado em resposta a um comando MAC MCPS-DATA.request, o dispositivo que envia o ack deve verificar se tem dados pendentes a enviar para o receptor. Se ele puder determinar isso antes de enviar o quadro de Ack ele deve setar o campo Frame Pending informando a situação de pendência de dados ou, caso não possa, setar esse campo com o valor 1. Se o quadro de confirmação está sendo enviado em resposta a um quadro de dados ou a qualquer outro tipo de quadro de comando MAC, o dispositivo deve setar o campo de quadros pendentes para zero. Todos outros campos do Frame Control devem ser setados em zero.

O campo Sequence Number deve conter o valor do número de sequência recebido no quadro para qual o Ack é enviado.

Quadro de Comando MAC (MAC Command Frame)

A Figura 33 mostra a estrutura geral do quadro de comando, que se origina de dentro da subcamada MAC. No cabeçalho MHR, o campo type do Frame Control apresenta o valor 011, indicando um quadro de comando. O payload MAC contém o identificador do comando MAC e o payload do comando propriamente dito.

Figura 33 – Formato do Quadro de Comando

Os comandos definidos pela subcamada MAC estão listados na Figura 34. Deve ser observado que um dispositivo FFD deve ser capaz de transmitir e receber todos os tipos de comandos, com exceção do GTS Request, enquanto que os requisitos para um RDF estão indicados com um “X” na figura. Os comandos MAC devem ser transmitidos apenas no CAP nas redes beacon-enabled ou a qualquer hora em redes nonbeacon-enabled.

Figura 34 – Comandos MAC

Comando de Pedido de Associação (Association Request)

Para se associar a uma PAN, a camada acima solicita ao MAC que ele inicie um procedimento de associação com a PAN selecionada. Isto envolve enviar um pedido de associação ao coordenador da PAN e esperar pela mensagem de aceitação correspondente. Se aceito na PAN, o nó requerente recebe um endereço curto de 16-bits, que ele pode usar posteriormente em lugar do seu endereço IEEE estendido de 64 bits.

O comando MAC usado por um dispositivo para solicitar associação a uma PAN é o Association Request. Todos os dispositivos devem ser capazes de emitir este comando, embora não seja requerido a um RFD ser capaz de recebê-lo. O dispositivo só pode se associar através do coordenador da PAN ou de um coordenador qualquer que permita a associação. O comando Association Request deve ser formatado como ilustrado na Figura 35.

Figura 35 – Formato do Comando Association Request

Campos do Cabeçalho MHR

No cabeçalho, o Source Addressing Mode deve indicar endereçamento estendido e o Destination Addressing Mode deve ser definido com o mesmo modo daquele indicado no quadro beacon ao qual o comando de pedido de associação se refere. O campo de Pending Frame deve ser ajustado para zero e ignorado na recepção, e o campo AR (Ack Requested) deve ser definido como 1.

O campo Destination PAN Identifier deve conter o identificador da PAN à qual se deseja associar. O campo Destination Address contém o endereço do coordenador ao qual o pedido de associação está sendo enviado, obtido do quadro de beacon por ele enviado. O campo Source PAN Identifier deve conter o identificador de PAN broadcast. O campo Source Address contém o endereço estendido do remetente, e deve ser igual a macExtendedAddress.

O Campo Capability Information

Este campo é formatado como na Figura 36.

Figura 36 – Formato do campo Capability Information do Comando Association Request

Device Type é igual a 1 se o dispositivo é um FFD e zero para indicar um RFD; Power Source é igual a 1 se o dispositivo está recebendo potência de uma fonte de corrente alternativa, caso contrário, é igual a 0; Receiver On When Idle é igual a 1 se o dispositivo não desabilita o seu receptor para conservar energia nos períodos de inatividade e 0, caso contrário; Security Capability é igual a 1 se o dispositivo é capaz de enviar e receber quadros MAC criptografados conforme especificado no padrão, caso contrário, deve ser 0; e Allocate Address é igual a 1 se o dispositivo deseja que o coordenador aloque para ele um endereço curto de 16 bits, do contrário, é 0.

A primitiva usada para solicitar ao MAC a associação a uma PAN é a MLME-ASSOCIATE.request. Os parâmetros desta primitiva são mostrados na Figura 37.

Figura 37 – Parâmetros da Primitiva MLME-ASSOCIATE.Request

Os valores válidos do status do pedido de associação são retornados na correspondente primitiva Association Response e são mostrados abaixo:

0x00 Association successful0x01 PAN at capacity0x02 PAN access denied 0x03-7F Reserved.0x80–0xff Reserved for MAC primitive enumeration values

O dispositivo que requisita a associação deve tentar associar-se somente depois de ter feito uma reinicialização da subcamada MAC, o que é feito com a emissão da primitiva MLME-RESET.request, com o parâmetro SetDefaultPIB igual a TRUE, e depois ter concluída uma busca ativa ou passiva de canais (procedimento denominado “channel scan”, brevemente descrito na próxima seção). Os resultados da busca de canais são então utilizados para escolher a PAN adequada. O algoritmo de seleção da PAN adequada a partir da lista de descritores de PAN retornados do procedimento de chaninel scan está fora do escopo do padrão.

Após a seleção da PAN com o qual se deseja associar, o dispositivo (i.e., a camada superior ao MAC) deve requerer ao seu MAC, através da primitiva de associação MLME-ASSOCIATE.request, que o MLME configure atributos específicos da PHY PIB e da MAC PIB, com os seguintes valores necessários para a associação:

— phyCurrentChannel: deve ser igual ao parâmetro ChannelNumber da primitiva MLME-ASSOCIATE.request.

— phyCurrentPage: deve ser igual ao parâmetro ChannelPage da primitiva MLME- ASSOCIATE.request.

— macPANId: deve ser igual ao parâmetro ChannelPage da primitiva MLME- ASSOCIATE.request.

— macCoordExtendedAddress ou macCoordShortAddress: dependendo de qual modo de endereço é conhecido a partir do quadro beacon do coordenador ao qual se pretende associar, deve ser igual ao parâmetro CoordAddress da primitiva MLME-ASSOCIATE.request.

A sequência global de mensagens (primitivas) trocadas para a associação a uma PAN é mostrada na Figura 38.

Figura 38 – Diagrama de Sequência de Mensagens para Associação a uma PAN

********** INSERIR CRIANDO A PAN ***********

Comando de Notificação de Desassociação (Disassociation Notification Command)

Dispositivos podem se desassociar da rede a qualquer momento e o comando MAC que implementa uma solicitação de desassociação é o Disassociation Notification. A solicitação pode partir do dispositivo ou do coordenador da PAN, conforme códigos abaixo:

0x00 Reserved0x01 The coordinator wishes the device to leave the PAN 0x02 The device wishes to leave the PAN 0x03-7F Reserved.0x80–0xff Reserved for MAC primitive enumeration values

O procedimento de desassociação é iniciado na camada acima do MAC com emissão da primitiva MLME-DISASSOCIATE.request, cujos parâmetros são mostrados na Figura 39. Quando um coordenador quer que um de seus dispositivos associados deixe a PAN, o MLME do coordenador deve enviar o comando de notificação de desassociação na forma especificada pelo parâmetro

TxIndirect da primitiva MLME-DISASSOCIATE.request. Se TxIndirect é TRUE, o MLME do coordenador usa transmissão indireta, isto é, o quadro de comando de notificação de desassociação é adicionado à lista de transações pendentes armazenadas no coordenador e extraído posteriormente pelo dispositivo receptor. Se o quadro de comando não é extraído com êxito pelo dispositivo, o coordenador considera o dispositivo dissociado. Se TxIndirect é FALSE, o MLME deve enviar o comando de notificação de desassociação para o dispositivo diretamente, no CAP – para redes beacon-enabled – ou imediatamente – para redes sem beacon. Se a transmissão direta ou indireta falha, o coordenador deveria considerar o dispositivo desassociado.

Figura 39 – Parâmetros da primitiva MLME-DISASSOCIATE.request

Se um dispositivo associado quer deixar a PAN, o MLME do dispositivo envia o comando de notificação de desassociação ao seu coordenador. Se o comando não pode ser enviado devido a uma falta de acesso ao canal, a subcamada MAC deve notificar a camada superior. Se o reconhecimento (Ack) do pedido de desassociação não for recebido, o dispositivo deve se auto considerar desassociado.

Se o endereço do remetente (Source Address) for igual macCoordExtendedAddress, o dispositivo deve considerar-se desassociado. Se o comando for recebido por um coordenador e o remetente não é igual a macCoordExtendedAddress, ele deve verificar se o endereço de origem corresponde a um dos seus dispositivos associados; em caso afirmativo, o coordenador deve considerar o dispositivo desassociado.

Um dispositivo associado deve desassociar-se removendo todas as suas referências para a PAN. Em outras palavras, o MLME retornará a macPANId, macShortAddress, macAssociatedPANCoord, macCoordShortAddress e macCoordExtend-Address os valores default. Por sua vez, o coordenador deve desassociar um dispositivo removendo todas as referências para esse dispositivo. A camada superior do dispositivo solicitante será notificada do resultado do processo de desassociação através da primitiva MLME-DISASSOCIATE.confirm. A Figura 40 ilustra a sequência de mensagens para um dispositivo para desassociar-se da PAN. A Figura 41 mostra uma desassociação iniciada por um coordenador em uma rede beacon-enabled.

Figura 40 – Sequência de mensagens trocadas em desassociação iniciada por um dispositivo

Figura 41 – Sequência de mensagens trocadas em uma desassociação iniciada por um coordenador, em uma rede operando com beacon s

Comando de Notificação de Conflito de PAN ID (PAN ID conflict notification command)

Este comando é enviado de um dispositivo para o coordenador da PAN quando um conflito de PAN ID é detectado. O coordenador da PAN conclui que um conflito está presente se uma das seguintes situações ocorre:

– Ele recebe um quadro beacon com os campos PAN Coordinator setado em 1 e PAN Identifier igual a macPANId (obs: um quadro beacon com o campo PAN Coordinator igual a 1 significa que ele está sendo transmitido pelo coordenador da PAN, e o identificador deste dispositivo é dado pelo parâmetro macPANId);

– Ele recebe um comando PAN ID conflict notification de um dispositivo associado à sua PAN.

Um dispositivo associado à rede através do coordenador da PAN (isto é, o parâmetro macAssociatedPANCoord é igual a TRUE) conclui que existe um conflito de PAN ID se ocorre a seguinte situação: um beacon é recebido pelo dispositivo com os campos PAN Coordinator igual a 1, PAN identifier igual a macPANId, e um endereço que não é igual nem a macCoordShortAddress e nem a macCoordExtendedAddress.

Um dispositivo que está associado através de um coordenador que não seja o PAN Coordinator não deve ser capaz de identificar um conflito de PAN ID's.

Na detecção de um conflito, o MLME emite a primitiva MLME-SYNC-LOSS.indication para a camada superior com o parâmetro LossReason setado em PAN_ID_CONFLICT. A camada superior do coordenador da PAN deve então solicitar a execução de um procedimento de varredura ativa (“active scan”), que é usado para encontrar PAN's em uma lista de canais. Usando essa informação, um novo identificador de PAN é selecionado (o algoritmo para selecionar o PAN ID mais adequado não faz parte do escopo do padrão).

Se a camada superior seleciona um novo PAN ID, ela emite então uma primitiva MLME-START.request com o parâmetro CoordRealignment setado em TRUE a fim de realinhar a PAN.

Procedimento de Scan Ativo e Passivo

A operação de scan permite a um dispositivo localizar qualquer coordenador que esteja transmitindo beacons dentro do alcance do seu rádio e é requisitado pela emissão da primitiva de serviço MLME-SCAN.request, com o parâmetro ScanType indicando se o scan é ativo ou passivo. Os parâmetros da primitiva são mostrados na Figura 42.

Figura 42 – Parâmetros da primitiva MLME-SCAN.request

O scan atua sobre uma lista especificada de canais. Para cada canal que se deseja fazer a varredura, o dispositivo primeiramente deve chavear para o canal desejado, atualizando o valor dos parâmetros phyCurrentChannel e phyCurrentPage.

No procedimento de scan ativo, o comando beacon request (vide adiante) é emitido para extrair o beacon de um coordenador; já no scan passivo, o beacon request não é transmitido. A Figura 43 ilustra o diagrama de sequência do scan ativo.

Se um beacon válido é recebido e macAutoRequest é igual a FALSE, o MLME deve indicar os parâmetros do beacon para a camada superior e isso é feito emitindo a primitiva MLME-BEACON-NOTIFY.indication. Se o beacon é recebido e macAutoRequest é TRUE, o MLME deve primeiro emitir a primitiva MLME- BEACON-NOTIFY.indication se o beacon contém algum payload. O MLME deve então comparar seu endereço com aqueles endereços do campo Address List do quadro

beacon. Se a Address List contém o endereço curto ou estendido do dispositivo e source PAN identifier é igual a macPANId, então o MLME deve seguir o procedimento de extração de dados pendentes do coordenador.

Figura 43 – Diagrama de Sequência da Mensagem Active Scan

Antes de começar o scan, seja ativo ou passivo, a subcamada MAC salva o valor de macPANId, alterando-o para valor 0xFFFF durante toda a duração do scan. Isso permite ao dispositivo receber todos os beacons e não somente os beacons da PAN corrente. Ao final do scan, este valor é restaurado pela subcamada MAC.

Comando de Requisição de Sinalizador (Beacon Request Command )

O comando Beacon Request é usado por um dispositivo para localizar todos os coordenadores dentro de sua faixa de comunicação de rádio durante uma varredura ativa (active scan). Este comando é opcional para um RFD. O comando deve ser formatado como ilustrado na Figura 44.

Figura 44 – Fomato do Comando Beacon Request

No MHR, o campo Destination Addressing Mode deve ser definido para indicar endereçamento curto, e o Source Addressing Mode definido para indicar que a informação de endereço fonte não está presente. O campo Frame Pending deve ser colocado em zero e ignorado na recepção. Os campos AR e o Security Enabled devem também ser ajustado para zero. O campo Destination PAN Identifier deve conter o identificador de broadcast da PAN e o Destination Address deve conter o endereço curto de broadcast.

Como visto, a primitiva MLME-BEACON-NOTIFY.indication é usada para enviar os contidos dentro de um quadro beacon recebido pela subcamada MAC para a camada superior. Os parâmetros desta primitiva são mostrados abaixo na Figura 45.

Figura 45 – Parâmetros da Primitiva MLME-BEACON-NOTIFY.indication

O PANDescriptor para o beacon recebido é mostrado na Figura 46.

Figura 46 – PANDescriptor

Comando de Notificação de Órfão (Orphan notification command) (Processo de Realinhamento de Dispositivo Órfão – Orphaned device realignment )

Se a camada imediatamente superior ao MAC de um nó recebe repetidas falhas de comunicação após os seus pedidos de transmissão de dados, ela pode concluir que o dispositivo se tornou órfão (isto é, que houve perda se sincronização com o coordenador da PAN). Uma falha de comunicação ocorre quando uma transação não é completada, por exemplo, no caso de um quadro de confirmação Ack não ser recebido após macMaxFrameRetries tentativas em enviar os dados. Se a camada superior conclui que o dispositivo está órfão, ela pode instruir o MLME a realizar o procedimento conhecido como realinhamento de dispositivo órfão (Orphaned Device Realignment) ou então optar por ressetar a subcamada MAC e depois executar a procedimento de associação.

Se a decisão tomada pela camada superior é realizar o procedimento de realinhamento de dispositivo órfão, ela deve emitir a primitiva MLME-SCAN.request, com o parâmetro ScanType setado para varredura de órfão (orphan scan) e o parâmetro ScanChannel contendo a lista de canais a serem verificados. Ao receber essa primitiva, a subcamada MAC inicia a varredura. Se a varredura

de órfão for bem sucedida, o dispositivo atualiza a sua MAC PIB com a informação de PAN contida no comando Coordinator Realignment (vide adiante).

A varredura de órfão permite a um dispositivo tentar mudar o seu coordenador na sequência de uma perda de sincronização. Durante uma varredura de órfão, a subcamada MAC deve descartar todos os quadros recebidos da camada física que não sejam quadros de comando de realinhamento de coordenador.

Como visto, uma varredura de órfão sobre um determinado conjunto de canais é solicitada usando a primitiva MLME-SCAN.request, com o parâmetro ScanType definido para indicar uma varredura de órfão. Para cada canal, o dispositivo deve primeiro mudar para o canal definindo phyCurrentChannel e phyCurrentPage de acordo e, em seguida, enviar um comando de notificação de órfão (Orphan Notification command). O comando de notificação de órfão é usado por um dispositivo que tenha perdido a sincronização com o seu coordenador. Todos os dispositivos devem ser capazes de transmitir este comando, embora não seja necessário a um RFD ser capaz de recebê-lo. O formato do comando é ilustrado na Figura 47.

Figura 47 – Formato do Comando Orphan notification

Após a transmissão bem sucedida do comando de notificação de órfão, o dispositivo deve habilitar o seu receptor para, no máximo, macResponseWaitTime. Se o dispositivo recebe com êxito o comando de realinhamento de coordenador dentro deste tempo, o dispositivo termina a verificação. Se esse comando não for recebido, o processo é repetido para o próximo canal e processo termina quando todos os canais forem verificados. Um exemplo de diagrama de sequência do procedimento de varredura de órfão e relinhamento de coordenador é mostrado na Figura 48.

Figura 48 – Diagrama de Sequência do Procedimento Orphan Scan and Realignment

Se um coordenador recebe o comando Orphan Notification, o MLME envia a primitiva MLME- ORPHAN.indication para a camada acima. Esta camada busca então na sua lista de dispositivos pelo dispositivo indicado na primitiva. Se um registro do dispositivo é encontrado na lista, a camada envia um comando de Coordinator Realignment para o dispositivo órfão usando a primitiva MLME-ORPHAN.response, com o parâmetro AssociatedMember setado em TRUE e o parâmetro ShortAddress com o correspondente endereço alocado para o dispositivo órfão. Isso tudo deve ocorrer dentro do tempo limite macResponseWaitTime. O comando de realinhamento deve conter o identificador de PAN corrente, macPANId, o canal e página correntes, e o endereço curto do dispositivo órfão. Se nenhum registro do dispositivo órfão for encontrado, a camada envia uma primitiva MLME-ORPHAN.response para o MLME, com o parâmetro AssociatedMember setado como FALSE. A Figura 49 ilustra o diagrama de sequência do procedimento de notificação de órfão decorrente do recebimento do comando Orphan Notification.

Figura 49 – Diagrama de Sequência para Orphan Notification

Comando Realinhamento de Coordenador (Coordinator Realignment command )

O comando de realinhamento de coordenador é enviado pelo coordenador PAN ou um coordenador após a recepção de um comando de notificação de órfão de um dispositivo que é reconhecido como sendo da sua PAN ou quando qualquer dos atributos de configuração da PAN mudar devido ao recebimento de uma primitiva MLME-START.request.

Se ele é enviado após a recepção de um comando de notificação de órfão, ele é mandado diretamente ao dispositivo órfão, como mostrado na Figura 46. Se o comando é enviado quando há mudança de qualquer atributo de configuração da PAN (por exemplo, PAN Identifier, short address, channel, ou channel page), ele é enviado por broadcast para a PAN.

O comando de realinhamento de coordenador é formatado como na Figura 50.

Figura 50 – Formato do Comando Coordinator Realignment

No MHR, o campo Destination Addressing Mode deve indicar endereçamento estendido se o comando é direcionado a um dispositivo órfão ou endereçamento curto se deve ser broadcasted para a PAN. O campo Source Addressing Mode deve indicar endereçamento estendido e o Destination PAN Identifier deve conter o identificador de broadcast da PAN. O campo Destination Address deve conter o endereço estendido do dispositivo órfão se o comando é direcionado para ele

ou, do contrário, deve conter o endereço curto de broadcast. O campo Source PAN Identifier deve ter o valor de macPANId, e o Source Address o valor de macExtendedAddress.

No payload, o campo PAN Identifier deve conter o identificador de PAN que o coordenador pretende utilizar para todas as futuras comunicações. O campo Coordinator Short Address deve conter o valor de macShortAddress. Channel Number deve conter o número do canal que o coordenador pretende utilizar paratodas as futuras comunicações.

Se o comando de realinhamento é broadcasted para a PAN, o campo Short Address deve ser configurado para 0xFFFF e ignorado na recepção. Se o comando é enviado diretamente para um dispositivo órfão, este campo deve conter o endereço curto que o dispositivo órfão deve utilizar para operar na PAN. Se o dispositivo órfão não possuir um endereço curto porque ele sempre usa o seu endereço estendido, este campo deve conter o valor 0xFFFE. O campo Channel Page (vide Figura 51), se presente, deve conter a página do canal que o coordenador pretende usar para todas as futuras comunicações. Este campo pode ser omitido se a página de novo canal é a mesma que a anterior página do canal.

Figura 51 – Configurações da Channel Page

Comando de Requisição de GTS - Fatias de Tempo Garantidas (GTS Request Command )

O comando de pedido de GTS é usado por um dispositivo associado que está solicitando do coordenador PAN a alocação de um novo GTS ou a desalocação de um GTS existente. O formato do comando é ilustrado na Figura 52.

Figura 52 – Fomato do Comando GTS Request

No MHR, o campo Destination Addressing Mode deve indicar que a informação de endereço destino não está presente, e o Source Addressing Mode deve indicar endereçamento curto. O campo Frame Pending deve ser zero e ignorado na recepção e o AR deve ser colocado em 1. O campo Source PAN Identifier deve conter o valor de macPANId, e o Source Address o valor macShortAddress.

O campo GTS Characteristics é formatado como ilustrado na Figura 53.

Figura 53 – Fomato do Comando GTS Characteristics

O GTS Length contém o número de slots do superframe sendo requisitados para o GTS. O campo GTS Direction deve ser fixado em 1 se o GTS é para ser um GTS “receive-only” ou ajustado para zero se é ser um GTS “transmit-only”. A direção do GTS é definida em relação definido em relação à direção das transmissões de quadros de dados pelo dispositivo. O campo Characteristics Type deve ser 1 se as características referem-se a uma alocação de GTS ou zero referem-se a uma desalocação de GTS.

***************************************** FIM ************************************************

Tópicos que faltaram:1. Starting and realigning a PAN /Beacon generation /Device discovery [p.24-31]2. Synchronization and Transaction Handling [p.36-40]3. Transmission, Reception, and Acknowledgment [p.40-48]4. GTS allocation and management [p.48-54]