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 ∗ 2BO 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 ∗ 2BO
= 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 ∗ 2SO 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 2 SO 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 Type
Apresenta 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 Pending
Deve 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 Compression
Se 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 Number

Especifica 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 Identifier

Quando 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 Address

Quando 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 Identifier

Quando 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 Address

Quando presente, especifica o endereço do dispositivo transmissor do quadro.

Campo: Auxiliary Security Header

Especifica 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 Payload

Conté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 Frame

Conté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 Specification
O 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 List
Cada 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 successful
0x01 PAN at capacity
0x02 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 Reserved
0x01 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]