MiWi: Criando redes MiWi com PIC18F4550

Depois de nossa série sobre o protocolo MiWi, chega a hora de colocar tudo em prática. Assim, vamos criar aqui um projeto de redes MiWi com o PIC. Vou selecionar o PIC18F4550, pois depois poderemos atualizar o projeto, adicionando o controle através da porta USB.
Se vocês perderam algum dos posts anteriores, podem acessá-los pela lista abaixo:
1- MiWi: Dispositivos e topologias de rede;
2- MiWi: Endereçamento;
3- MiWi: Relatórios de protocolo;
4- MiWi: Mensagens de Stack e Serviços
5- MiWi: Segurança
Como a biblioteca da Microchip para o MiWi foi desenvolvida recentemente, há ainda alguns bugs e também muitas atualizações. Ela é fornecida com o Microchip Application Libraries, e a última versão disponível agora, enquanto escrevo este artigo, é a versão de junho de 2011 (Stack MiWi 4.2). Quem estiver com sua versão desatualizada, é bom atualizar.

Hardware do projeto

Desenhamos o circuito do projeto no KiCad, que pode ser visto abaixo:

Criamos o componente MRF24J40MA, já que o KiCad não o possui. Você poderá obter todos os datasheets relacionados a este módulo no site da Microchip.
O módulo MRF24J40MA é o módulo que fará todo o trabalho de transmissão e recepção de pacotes. Você o controla via barramento SPI. Ele na verdade é um transceiver feito pela Microchip para os protocolos ZigBee ou MiWi... Mas como um transceiver, você poderá criar qualquer protocolo de comunicação com ele. O Stack MiWi não está no módulo, mas é implementado pelas bibliotecas da Microchip.
Para você ter uma visão geral dos registradores disponíveis deste módulo, procure pelo datasheet do circuito integrado principal dele, o MRF24J40. Há ainda uma versão deste módulo de maior alcance, chamado de MRF24J40MB.
A alimentação do módulo é de 3.3V. Para simplificar o desenho acima, não incluímos a fonte. Portanto, quando você for implementar este projeto, lembre-se de incluí-la.

Incluindo os arquivos do projeto

Vamos agora ao PCAD, e vamos criar um novo projeto com PICF4550. Os arquivos que devemos incluir são os arquivos abaixo:

Arquivo	Pasta
Console.c	\Microchip Solutions\Microchip\WirelessProtocols\
MSPI.c	\Microchip Solutions\Microchip\WirelessProtocols\
SymbolTime.c	\Microchip Solutions\Microchip\WirelessProtocols\
MiWi.c	\Microchip Solutions\Microchip\WirelessProtocols\MiWi\
MRF24J40.c	\Microchip Solutions\Microchip\Transceivers\MRF24J40\
MiWi.c	\Microchip Solutions\Microchip\WirelessProtocols\MiWi\

Os cabeçalhos relacionados com estes arquivos podem ser adicionados para facilitar a visualização. Por fim, devemos copiar três arquivos que serão necessários para o projeto: ConfigApp.h, HardwareProfile.h, SystemProfile.h. Para o projeto de um dispositivo End Device, nós vamos copiar estes arquivos do diretório Microchip Solutions\MiWi DE Demos\Node 2. Para Coordinators, devemos copiar estes arquivos do diretório Microchip Solutions\MiWi DE Demos\Node 1. São eles que conterão as configurações de rede do projeto, bem como o esquema de ligação deste projeto.
Assim que copiar estes arquivos para a pasta do projeto, inclua-os. Fazendo isto, vamos editar o arquivo HardwareProfile.h, para que ele reflita o nosso esquemático:

#ifndef _HARDWARE_PROFILE_H
    #define _HARDWARE_PROFILE_H
    
    #include "GenericTypeDefs.h"
    #include "ConfigApp.h"
    #include <p18cxxx.h>
    
    #define CLOCK_FREQ          48000000
    
    #define RFIF                INTCON3bits.INT2IF
    #define RFIE                INTCON3bits.INT2IE
    
    #define PHY_CS              LATCbits.LATC2
    #define PHY_CS_TRIS         TRISCbits.TRISC2
    #define RF_INT_PIN          PORTBbits.RB2
    #define RF_INT_TRIS         TRISBbits.TRISB2
    
    #define SPI_SDI             PORTBbits.RB0               
    #define SDI_TRIS            TRISBbits.TRISB0
    #define SPI_SDO             LATCbits.LATC7
    #define SDO_TRIS            TRISCbits.TRISC7
    #define SPI_SCK             LATBbits.LATB1
    #define SCK_TRIS            TRICBbits.TRISB1

    #define PHY_RESETn          LATCbits.LATC0
    #define PHY_RESETn_TRIS     TRISCbits.TRISC0
    #define PHY_WAKE            LATCbits.LATC1
    #define PHY_WAKE_TRIS       TRISCbits.TRISC1
    
    #define LED_1               PORTEbits.RE0
    #define LED_1_TRIS          TRISEbits.TRISE0
    #define LED_2               PORTEbits.RE1
    #define LED_2_TRIS          TRISEbits.TRISE1
    #define LED_3               PORTEbits.RE2
    #define LED_3_TRIS          TRISEbits.TRISE2

    #define TMRL                TMR0L
    
    #define TOOGLE(c)           c = ~c

#endif

Aqui nós definimos todas as ligações feitas com o módulo MRF24J40MA. Se alguma destas definições faltar, o compilador gerará erros. O clock e o registrador do timer usado também devem ser definidos aqui, para que o Stack MiWi possa fazer as temporizações corretamente. Portanto, você não poderá usar este timer.

Configurando o projeto

A configuração do projeto é feita no arquivo ConfigApp.h. Veja quais opções você poderá selecionar neste arquivo:

Configuração	Descrição
ENABLE_CONSOLE	Habilita a impressão de mensagens pela serial do microcontrolador. Comente esta definição, para desabilitá-la.
SIMPLE_EXAMPLE	Desabilita todas as funções mais avançadas do Stack. Insira esta definição no projeto, para habilitá-la.
ENABLE_NETWORK_FREEZER	Grava todos os dados mais importantes de uma conexão em memória não volátil, para rápido restabelecimento da rede. É necessário ter esta memória no projeto.
HARDWARE_SPI	Utiliza o módulo SPI nativo do microcontrolador para comunicação. Comentando-se esta definição, o Stack tentará emular uma SPI. Recomendável usar o SPI nativo.
PROTOCOL_P2P	Habilita a rede P2P. Não pode ser definido juntamente com PROTOCOL_MIWI
PROTOCOL_MIWI	Habilita a rede MiWi Mesh. Não pode ser definido juntamente com PROTOCOL_P2P
NWK_ROLE_COORDINATOR	Define o dispositivo como Coordinator. Não pode ser definido juntamente com NWK_ROLE_END_DEVICE.
NWK_ROLE_END_DEVICE	Define o dispositivo como End Device. Não pode ser definido juntamente com NWK_ROLE_COORDINATOR.
MRF24J40	Define que o módulo MRF24J40MA de 2.4GHz será usado. Não pode ser definido junto com outros transceivers.
MRF49XA	Define que o módulo subGHz MRF49XA da Microchip será usado. Não pode ser definido junto com outros transceivers.
MRF89XA	Define que o módulo subGHz MRF89XA da Microchip será usado. Não pode ser definido junto com outros transceivers.
MY_ADDRESS_LENGTH	Define o tamanho do endereço permanente do nó, em bytes.
EUI_0 - EUI_7	Esta é a definição do endereço EUI do módulo. Cada dígito é um byte do endereço.
TX_BUFFER_SIZE	Define o tamanho do buffer de transmissão.
RX_BUFFER_SIZE	Define o tamanho do buffer de recepção.
MY_PAN_ID	Define o PANID do dispositivo.
ADDITIONAL_NODE_ID_SIZE	Define o tamanho dos dados adicionais que serão anexados à requisição P2P. Estas são informações que os dispositivos querem compartilhar com outros pontos na conexão. Estes dados serão definidos pela aplicação.
CONNECTION_SIZE	Define o máximo de conexões P2P que este dispositivo permite ao mesmo tempo.
TARGET_SMALL	Remove algumas funcionalidades para diminuir o código gerado.
ENABLE_PA_LNA	Habilita o amplificador de potência em transceivers que o possuem.
ENABLE_HAND_SHAKE	Habilita o hand-shake antes da comunicação. Sem isto, os transceivers RF só poderão fazer broadcast, ou possuir o endereço de destino programado no firmware para comunicação com um dispositivo.
ENABLE_SLEEP	Permite que o dispositivo vá para o modo sleep e volte dele.
ENABLE_ED_SCAN	Habilita a detecção de energia, para descobrir qual o canal que possui menos ruído.
ENABLE_ACTIVE_SCAN	Habilita o Active Scan, para detectar as conexões atualmente existentes.
ENABLE_SECURITY	Habilita a encriptação de dados na transmissão.
ENABLE_INDIRECT_MESSAGE	Fará com que o dispositivo guarde mensagens para dispositivos que estão em modo sleep, até que eles retornem ao funcionamento normal.
ENABLE_BROADCAST	Fará com que o dispositivo envie broadcasts aos dispositivos em modo sleep, até que eles retornem ao funcionamento normal.
RFD_WAKEUP_INTERVAL	Define o intervalo de wakeup para dispositivos RFD em segundos. Esta definição no entanto não é utilizada pelos dispositivos RFD, mas pelos dispositivos FFD, para calcular seus vários timeouts.
ENABLE_FREQUENCY_AGILITY	Faz com que o dispositivo possa mudar de canal, quando houver uma súbita mudança no ruído.

Alterando o valor destas definições, você poderá configurar seu projeto de acordo com suas necessidades. É sempre bom dar uma olhada nestas configurações depois de copiar os arquivos.

Arquivo principal do projeto

No arquivo principal, você precisará definir algumas coisas também. Vamos ao esqueleto básico deste arquivo:

#include <stdio.h>
#include "GenericTypeDefs.h"
#include "Compiler.h"
#include "WirelessProtocols/MSPI.h"
#include "WirelessProtocols/MCHP_API.h"

#include "HardwareProfile.h"

#if ADDITIONAL_NODE_ID_SIZE > 0
 BYTE AdditionalNodeID[ADDITIONAL_NODE_ID_SIZE] = {0x01};
#endif

BYTE myChannel = 11;

#pragma config FOSC=HSPLL_HS
#pragma config CPUDIV=OSC1_PLL2
#pragma config PLLDIV=5
#pragma config USBDIV=2
#pragma config CCP2MX=ON
#pragma config WDT=OFF
#pragma config WDTPS=32768
#pragma config MCLRE=ON
#pragma config LVP=OFF
#pragma config VREGEN=ON
#pragma config IESO=OFF
#pragma config PWRT=ON
#pragma config BOR=OFF
#pragma config CP0=OFF
#pragma config CP1=OFF
#pragma config CP2=OFF
#pragma config CP3=OFF
#pragma config CPB=OFF
#pragma config CPD=OFF
#pragma config WRT0=OFF
#pragma config WRT1=OFF
#pragma config WRT2=OFF
#pragma config WRT3=OFF
#pragma config WRTB=OFF
#pragma config WRTC=OFF
#pragma config WRTD=OFF
#pragma config EBTR0=OFF
#pragma config EBTR1=OFF
#pragma config EBTR2=OFF
#pragma config EBTR3=OFF
#pragma config EBTRB=OFF
#pragma config DEBUG=ON
#pragma config XINST=ON

void UserInterruptHandler(void)
{
}              

void main(void)
{
 BYTE i=0xFF;
 
 RCON = 0x80;           // Habilita prioridades para interrupções
 ADCON0 = 0x00;
 ADCON1 = 0x0F;       // PORTA só como entradas e saídas digitais.
 CMCON = 0x07;        // Comparadores desligados.
 TRISA = 0xFF;
 TRISB = 0x05;
 TRISC = 0x00;
 PORTC = 0x06;
 TRISD = 0x00;
 PORTD = 0x00;
 TRISE = 0x07;
 PORTE = 0xFF;
 INTCON = 0x00;
 INTCON2 = 0x00;
 INTCON3 = 0x00;
 // Configura o módulo SPI
 SSPSTAT = 0xC0;
 SSPCON1 = 0x20;
 
 INTCONbits.GIEH = 1;
 RFIF = 0;               // Limpa o interrupt flag do chip.
 RFIE = 1;
 INTCON2bits.INTEDG2 = 0;

 MiApp_ProtocolInit(FALSE);
 if(MiApp_SetChannel(myChannel) == FALSE)
 {
  return;
 }
 MiApp_ConnectionMode(ENABLE_ALL_CONN);
 while((i = MiApp_EstablishConnection(0xFF, CONN_MODE_DIRECT)) == 0xFF);
 #ifdef ENABLE_DUMP
        DumpConnection(0xFF);
 #endif
 LED_2 = 1;
 for(;;)
 {
  if(MiApp_MessageAvailable())
  {
   // Aqui tratamos a mensagem recebida.
   MiApp_DiscardMessage();
  }
 }
}

O código acima é de um arquivo prinpipal para o projeto de dispositivo End Device. A diferença entre o End Device e o Coordinator é apenas a função main. Duas definições devem ser feitas no arquivo principal. A primeira é a definição da variável AdditionalNodeID, conforme pode ser visto acima. Os arquivos do Stack MiWi usam esta variável, portanto é necessário pelo menos definí-la. A segunda definição é a da função UserInterruptHandler. Esta função é chamada depois que a interrupção do MiWi for executada, e precisa também ser declarada, mesmo que nada seja feito ali.
Além destas declarações, você deverá ainda configurar o módulo SPI e habilitar a interrupção que você definiu para o módulo MRF24J40MA (o Stack não faz isto como acontece em outras bibliotecas Microchip). Feito isto, seu projeto está pronto para funcionar.
As diferenças existentes neste arquivo acima, para o projeto do Coordinator são poucas. Compare com o código abaixo (do Coordinator):

MiApp_ProtocolInit(FALSE);
 if(MiApp_SetChannel(myChannel) == FALSE)
 {
  return;
 }
 MiApp_ConnectionMode(ENABLE_ALL_CONN);
 MiApp_StartConnection(START_CONN_DIRECT, 10, 0);
 #ifdef ENABLE_DUMP
        DumpConnection(0xFF);
 #endif
 LED_2 = 1;
 for(;;)
 {
  if(MiApp_MessageAvailable())
  {
   MiApp_DiscardMessage();
  }
 }

Pode-se observar que o End Device usa a função MiApp_EstablishConnection, enquanto o Coordinator usa a função MiApp_StartConnection. Esta função inicializa a rede MiWi, e somente com uma rede estabelecida, é que os dispositivos End Device podem estabelecer conexões.

Conclusão

Terminamos aqui com a criação de um projeto MiWi. No nosso próximo post, iremos desvendar um pouco mais as rotinas usadas pelo Stack, para implementar a comunicação via protocolo MiWi, comparando com o que já foi escrito sobre o protocolo, aqui.

MiWi: Segurança

Continuando nossa série de posts sobre o protocolo MiWi, nós terminaremos nossa descrição do protocolo, tratando agora da questão da Segurança de rede. Estou aqui traduzindo parte do datasheet, Application Note AN1066 - MiWi Wireless Networking Protocol Stack. Para quem não viu os outros tópicos, aqui está uma pequena lista de referência:
1- MiWi: Dispositivos e topologias de rede;
2- MiWi: Endereçamento;
3- MiWi: Relatórios de protocolo;
4- MiWi: Mensagens de Stack e Serviços
O protocolo MiWi segue a definição de segurança MAC especificada no IEEE 802.15.4. Todos os 7 modos de segurança definidos na especificação são suportados no protocolo MiWi. Estes podem ser divididos em três grupos:

• O modo AES-CTR encripta os dados do protocolo MiWi. Quem estiver atacando não irá entender o conteúdo do pacote MiWi sem uma chave. Este modo de segurança não pode verificar a integridade do pacote ou o conteúdo do cabeçalho MiWi, e mais importante, o endereço fonte original do pacote.
• Os modos AES-CBC-MAC garantem a qualidade do pacote MiWi. O Message Integrity Code (Código de integridade de mensagem - MIC) inserido no pacote garante que o pacote, incluindo o cabeçalho e os dados, não foram modificados de qualquer forma durante a transmissão. O tamanho do MIC é determinado pelo modo em particular; MICs maiores fornecem uma proteção maior. Os dados do pacote MiWi não são encriptados nestes modos.
• Os modos AES-CCM combinam os dois modos anteriores para garantir tanto a integridade do pacote quanto os dados encriptados.

Modo de segurança 00h, que especifica nenhuma segurança, é essencialmente o procoloco MiWi com o modo de segurança desligado. A capacidade de cada um dos modos de segurança pode ser visto na tabela abaixo:

Modo de segurança		Serviços de segurança				MIC (Bytes)
Identificador	Nome	Controle de Acesso	Encriptação de dados	Integridade de dados	Pureza sequencial
01h	AES-CTR	X	X		X	0
02h	AES-CCM-128	X	X	X	X	16
03h	AES-CCM-64	X	X	X	X	8
04h	AES-CCM-32	X	X	X	X	4
05h	AES-CBC-MAC-128	X		X		16
06h	AES-CBC-MAC-64	X		X		8
07h	AES-CBC-MAC-32	X		X		4

O stack fornece suporte de segurança na camada de protocolo MiWi. Quando segurança é ligada, o bit de segurança (bit 0) do byte Frame Control é setado. Assim que a segurança é ligada, o stack a utiliza em todos os pacotes do protocolo MiWi. O cabeçalho do protocolo MiWi (exceto hops, tipo de relatório e Report ID) são usados como dados de autenticação para todos os modos de segurança, exceto modo 01h. O tipo de relatório e o Report ID são assegurados, assim como os dados do relatório. Dados adicionais da suíte de segurança do IEEE 802.15.4 podem ser encontradas na seção 7.6 do padrão.
Quando a segurança é habilitada, o stack adiciona três novos items ao cabeçalho do pacote, imediatamente antes dos dados:

• o contador de frame
• o endereço longo da fonte
• a número da chave de sequência

O formato do cabeçalho de protocolo MiWi, com a segurança habilitada, é mostrado abaixo:

Quando a segurança é usada, entre 13 e 29 bytes adicionais são requeridos para o cabeçalho de segurança auxiliar e o MIC, dependendo da combinação do modo de segurança e da camada assegurada. Usuários precisarão balancear as necessidades de segurança e o impacto no tamanho dos dados (e a performance associada), associado com a combinação de definições de segurança.
A segurança no protocolo MiWi checa o contador de frames para evitar ataques repetidos. Somente pacotes MiWi de um membro da família de nós (como nós pais ou filhos) são checados para o contador de pureza. A razão é que somente tais nós são capazes de saber se outros membros da família de nós deixaram ou se uniram à rede. Qualquer pacote dos membros da família são obrigados a ter o contador de frame não menor que o contador de frame armazenado, do contrário, o pacote é descartado. Qualquer pai irá resetar o contador correspondente do pacote recebido assim que o filho correspondente se unir ou reunir à rede.
A segurança de protocolo assume que todas as informações de segurança, incluindo a chave de 16 bytes de segurança, número de chave de sequência e modo de segurança estejam preconfiguradas no stack. a forma recomendada de se fazer isto é programar tais chaves diretamente no software embarcado do sistema, de forma que nenhuma chave de segurança seja transferida durante o funcionamento da rede.

Conclusão

Aqui terminamos a descrição do protocolo MiWi, tratando dos modos de segurança disponíveis. Em breve, trataremos da criação de projetos MiWi, usando os microcontroladores da família Microchip.

Google Wallet: pagamento por celular

A Google parece reunir uma grande quantidade de pessoas criativas nestes dias. A última idéia é a do Google Wallet, uma carteira eletrônica pelo celular: todas transações comerciais serão feitas através de um aplicativo no celular.
Segundo o site EETimes India, é a NXP quem está auxiliando a Google com a parte de NFC (near-field communication), empresa esta que já atua na área de pagamento móvel, controle de acesso, infraestrutura de trânsito, autenticação de dispositivos e soluções eGovernment, tais como ePassport, carteiras de motoristas, carteiras de identidade e cartões de planos de saúde.
A aplicação da Google vai utilizar a solução de transação móvel da NXP, o NXP PN65 NFC, que inclui o controlador de rádio NFC, o elemento embarcado seguro e o software NFC em um simples dispositivo. O elemento embarcado seguro permite o pagamento pelo Google Wallet, e usa criptografia avançada para aumentar a segurança em tais transações.
Como é uma aplicação NFC, como o RFID, tudo que o usuário fará é aproximar seu celular de superfícies preparadas para a transação, e o pagamento poderá ser realizado. Não só pagamento, mas também cartões de desconto, pontos de fidelidade, etc. Se esta tecnologia pegar mesmo, não demorará muito para dados de carteira de identidade, carteira de motorista, CPF e outros também serem disponibilizados nesta forma...
O NFC de fato foi inventado pela NXP em 2002, a partir de uma combinação do RFID com tecnologias de interconexão. Em 2004 a NXP fundou o fórum NFC, para tornar a tecnologia mais conhecida e também torná-la padrão. Com a adoção da tecnologia pela Google, provavelmente a solução da NXP se tornará muito mais difundida.

MiWi: Mensagens de Stack e Serviços

Continuando nossa série sobre o protocolo MiWi, vamos hoje falar sobre mensagens de stack e serviços. O texto que trago aqui é uma tradução de parte do datasheet, Application Note AN1066 - MiWi Wireless Networking Protocol Stack.
Para quem não acompanhou nossa série deste o começo, ela se divide já em 3 partes:
1- MiWi: Dispositivos e topologias de rede;
2- MiWi: Endereçamento;
3- MiWi: Relatórios de protocolo

Fornecer alocação de endereços e serviços de roteamento são apenas o começo de uma solução de rede wireless. Além destes, o protocolo MiWi fornece outros serviços opcionais que ajudam os desenvolvedores a alcançar uma solução mais rapidamente. Estes serviços incluem criar conexões dinamicamente entre dois dispositivos sem precisar conhecer qualquer informação sobre o dispositivo antes do tempo (por exemplo, sockets), e a habilidade de procurar a rede por um endereço longo de um dispositivo específico.

Descobrindo nós na rede através do EUI

Quando dois nós comunicam por uma rede MiWi, eles usam seus endereços curtos. Se a topologia de rede mudar, seria útil encontrar aquele dispositivo novamente. Já que o endereço curto do dispositivo é atribuído a ele pelo seu dispositivo pai, o endereço curto curto do destino pode ter mudado. Se este é o caso, então o novo endereço curto deve ser descoberto antes que a comunicação possa ser restabelecida. Diferentemente do endereço curto, o EUI do dispositivo nunca muda e é globalmente único. Se um dispositivo conhece o EUI do outro dispositivo, ele será capaz de distinguir este dispositivo de qualquer outro. Assim, procurar pelo EUI de um dispositivo se torna importante para restabelecer comunicação entre dois dispositivos que se movem. Esta busca é possível no protocolo MiWi.
Como vimos no último post, há dois pacotes de stack que são definidos para ajudar com a busca de determinado EUI: EUI_ADDRESS_SEARCH_REQUEST e EUI_ADDRESS_SEARCH_RESPONSE. O pacote de requisição é transmitido para o primeiro Coordinator, que se encarrega de fazer um broadcast para todos os outros Coordinators. Este pacote é repetido até que o contador de hops chegue a 0.
Se algum dos Coordinators encontrar o dispositivo entre seus dispositivos filho, ele enviará a resposta de volta, de nó em nó, até o dispositivo que gerou a requisição.
Abaixo temos um diagrama do que foi descrito aqui:

Abrindo uma conexão com um dispositivo

Outra funcionalidade que pode ser importante para algumas redes é a capacidade de dinamicamente estabelecer conexões na rede. Isto é útil em redes onde a preconfiguração de nós precisa ser mínima.
Como um exemplo, um usuário pode desejar adicionar um novo interruptor de luz a um sistema de controle de iluminação. Como este interruptor sabe qual luz ele deve enviar seus pacotes? Uma forma é ter algum tipo de interface onde o dispositivo instalador manualmente programa os endereços do controlador e do alvo nos dispositivos.

Cluster Socket

Um método mais dinâmico seria ter um push button tanto na luz quanto no interruptor. Você pressiona primeiro o push button na luz, e então o do interruptor, dentro do período de tempo especificado. Isto permite os dois dispositivos saberem que eles precisam se comunicar um com o outro. Isto permite mudança dinâmica em tempo real no comportamento da rede de uma forma simples e mais simples ao usuário.
O protocolo MiWi define esta conexão dinâmica como um cluster socket. Um cluster socket existe entre dois nós que são membros da rede e são formados com base no endereço curto.
No exemplo anterior, apertar o push button do interruptor envia um OPEN_CLUSTER_SOCKET_REQUEST ao PAN Coordinator com a informação daquele dispositivo (veja também nosso post sobre Relatórios de Protocolo). Isto notifica o PAN Coordinator que o dispositivo está procurando por alguém para se comunicar. O PAN Coordinator mantém a requisição aberta pelo tempo especificicado pela aplicação. Se uma requisição similar vier da luz, o PAN Coordinator combina o a informação de endereço curto de ambos dispositivos em um OPEN_CLUSTER_SOCKET_RESPONSE e o envia para o interruptor e a luz. Finalmente, o PAN Coordinator remove a requisição de abertura de socket. Se o PAN Coordinator não receber uma segunda requisição de abertura de socket dentro do tempo especificado, então ele irá finalizar a requisição sem enviar uma resposta ao nó que a requisitou.
Se os dispositivos em F e G receberem o OPEN_CLUSTER_SOCKET_RESPONSE, eles podem examinar os dados daquele pacote e determinar se aquele dispositivo é, de fato, o dispositivo que eles querem comunicar. Esta é uma decisão do nível de aplicação, não é fornecida pelo stack.
Abaixo temos um diagrama de abertura de cluster socket:

P2P Socket

Apesar de dispositivos P2P somente se comunicar com um dispositivo e eles não se comunicam através da rede, eles ainda podem requerer uma conexão dinâmica. Dispositivos P2P devem ter um algoritmo diferente dos cluster sockets já que eles não são membros da rede.
Quando um dispositivo P2P quer se comunicar com um diferente nó, ele primeiro faz um broadcast de um pacote OPEN_P2P_SOCKET_REQUEST que contém o EUI completo do dispositivo. Qualquer dispositivo que receber esta requisição e deseja se comunicar com aquele dispositivo envia um pacote OPEN_P2P_SOCKET_RESPONSE que contém seu próprio EUI, informando o primeiro dispositivo que ele quer se comunicar. Na implementação atual, somente coordinators são capazes de receber o OPEN_P2P_SOCKET_REQUEST.
Aqui podemos ver como este procedimento acontece:

Conclusão

Hoje vimos a descrição dos serviços e como o protocolo utiliza os relatórios descritos no último post para implementá-los. No próximo post da série, terminamos de fazer a descrição do protocolo, comentando sobre a questão da segurança na rede MiWi.

MIWi: Relatórios de Protocolo

Continuando nossa série sobre o MiWi, vamos agora falar dos relatórios de protocolo. Mais uma vez, estarei traduzindo parte da documentação fornecida pela Microchip: Application Note AN1066 - MiWi Wireless Networking Protocol Stack.

MiWi Protocol Reports

O protocolo MiWi transporta pacotes entre dispositivos usando pacotes especiais chamados de relatórios (reports). O protocolo permite a implementação de até 256 tipos de relatórios, cada um com um ID diferente.
O relatório tipo 00h é reservado para pacotes de protocolo da rede MiWi, onde os dados do pacote (payload) são direcionados para o stack. Por exemplo, um ACK possui o tipo de relatório 00h (por ser um pacote de stack).
O tipo de relatório e o Report ID são definidos no cabeçalho do pacote, como já foi descrito no post MiWi: Endereçamento. O tamanho e conteúdo dos dados de um relatório depende do Report ID. Na implementação atual do MiWi, o tamanho do payload varia de 0 bytes (há alguns pacotes que não precisam de enviar dados, o próprio Report ID já é a informação) até 10 bytes, com o byte menos significativo sendo enviado primeiro.
Vejamos então a lista de relatórios deste protocolo.

Tipo de Relatório	Report ID	Nome
00h	10h	OPEN_CLUSTER_SOCKET_REQUEST
	11h	OPEN_CLUSTER_SOCKET_RESPONSE
	12h	OPEN_P2P_SOCKET_REQUEST
	13h	OPEN_P2P_SOCKET_RESPONSE
	20h	EUI_ADDRESS_SEARCH_REQUEST
	21h	EUI_ADDRESS_SEARCH_RESPONSE
	30h	ACK_REPORT_TYPE
01h-FFh	00h-FFh	Disponível para o usuário

Vamos agora fazer uma descrição de cada um destes relatórios:

OPEN_CLUSTER_SOCKET_REQUEST

Tipo de Relatório (1 Byte)	Report ID (1 byte)	Requesting EUI Address (8 bytes)
00h	10h	O EUI do dispositivo que inicia a requisição

O endereço de destino do cabeçalho de protocolo MiWi deve ser o do PAN Coordinator (0000h). O endereço fonte do cabeçalho de protocolo MiWi deve ser o do dispositivo que está iniciando a requisição. O campo Requesting EUI Address especifica o EUI do dispositivo que inicia a requisição, com o byte menos significativo primeiro.

OPEN_CLUSTER_SOCKET_RESPONSE

Tipo de Relatório (1 Byte)	Report ID (1 byte)	Resulting EUI Address (8 bytes)	Resulting Short EUI Address (2 bytes)
00h	11h	O EUI do dispositivo final	O endereço curto do dispositivo final

O endereço de destino do cabeçalho de protocolo MiWi deve ser o dispositivo que requisitou originalmente esta resposta. O endereço fonte deve ser do PAN Coordinator, já que este pacote específico se origina ali. O campo Resulting EUI Address especifica o EUI do dispositivo que respondeu à requisição (LSB primeiro). Note que este é um endereço diferente daquele especificado no endereço de destino do protocolo MiWi.
O campo Resulting Short Address é o endereço curto do dispositivo que respondeu à requisição. Com a combinação do EUI e do endereço curto enviado para ambos nós requisitantes, eles serão capazes de comunicar na rede e encontrar um ao outro se algum deles se mover na rede. Assim que o OPEN_CLUSTER_SOCKET_RESPONSE é enviado, o PAN Coordinator não mais manterá qualquer informação do socket.

OPEN_P2P_SOCKET_REQUEST

Tipo de Relatório (1 Byte)	Report ID (1 byte)
00h	12h

As informações tanto da fonte quanto do destino no cabeçalho de protocolo MiWi deve ser FFFFh. O campo de Hops do cabeçalho de protocolo MiWi deve ser 00h para prevenir rebroadcast do pacote. O PANID de fonte e de destino de nível MAC deve ser FFFFh. O endereço curto MAC de destino deve ser FFFFh. O endereço de fonte de nível MAC deve ser modo Long Address.

OPEN_P2P_SOCKET_RESPONSE

Tipo de Relatório (1 Byte)	Report ID (1 byte)
00h	13h

As informações tanto da fonte quanto do destino no cabeçalho de protocolo MiWi deve ser FFFFh. O campo de Hops do cabeçalho de protocolo MiWi deve ser 00h. O PANID de fonte e de destino de nível MAC deve ser FFFFh. Os endereços MAC de destino e fonte devem ser ambos endereços longos (EUIs).

EUI_ADDRESS_SEARCH_REQUEST

Tipo de Relatório (1 Byte)	Report ID (1 byte)	Search EUI Address (8 bytes)
00h	20h	O EUI do dispositivo que está sendo procurado

O endereço curto e PANID de destino do cabeçalho de protocolo MiWi dever ser o endereço de broadcast, FFFFh.O endereço e PANID de fonte do cabeçalho de protocolo MiWi deve ser a informação de endereço que está requisitando a busca. Na recepção deste pacote, um coordinator na rede irá retransmitir este pacote como broadcast se o número de hops for maior que 00h. O coordinator irá decrementar o contador de hops antes de retransmitir o pacote. O coordinator não irá mudar o valor do número de sequência do protocolo MiWi quando transmitir o pacote.

EUI_ADDRESS_SEARCH_RESPONSE

Tipo de Relatório (1 Byte)	Report ID (1 byte)	Search EUI Address (8 bytes)	Search Results PANID (2 bytes)	Search Results Short Address (2 bytes)
00h	21h	O EUI do dispositivo que está sendo procurado	O PANID do dispositivo resultante	O endereço curto do dispositivo resultante

O pacote EUI_ADDRESS_SEARCH_RESPONSE deve ser enviado de volta para o endereço do dispositivo que originalmente enviou a requisição (o dispositivo mencionado nos campos de fonte do protocolo MiWi do pacote de requisição).

ACK_REPORT_TYPE

Tipo de Relatório (1 Byte)	Report ID (1 byte)
00h	30h

O endereço fonte do ACK de protocolo MiWi deve ser igual ao endereço de destino do protocolo MiWi que fez a requisição do Acknoledgement. O endereço de destino do pacote de ACK deve ser igual ao endereço de fonte do protocolo MiWi do pacote que requer um Acknoledgement.

Conclusão

Aqui nós tratamos dos vários tipos de pacotes usados pelo protocolo MiWi, para transportar dados. Já tratei aqui de uma introdução ao protocolo MiWi, bem como da forma que este protocolo faz o endereçamento de dispositivos. No próximo post da série, iremos ver mais sobre mensagens de stack e serviços.

MiWi: Endereçamento

Continuando nossa série de posts sobre o protocolo MiWi, vamos falar um pouco mais sobre a forma de endereçamento.

Atribuição de endereços

O protocolo MiWi usa os endereços fornecidos pela especificação IEEE 802.15.4. Ela defina três tipos de endereços:

1. Extended Organizationally Unique Identifier (EUI): Este endereço é um número de 8 bytes que é único em todo o mundo. Todo dispositivo usando esta especificação tem que ter um EUI único. Os 3 bytes superiores do EUI são comprados da IEEE, enquanto que os outros 5 bytes do EUI estão disponíveis para o usuário da forma que lhe for conveniente, desde que eles permaneçam globalmente únicos.
2. PAN Identifier (PANID): O PANID é um endereço de 16 bits que define um grupo de nós. Todos os nós no PAN compartilham um PANID comum. O dispositivo assume o PANID assim que ele escolhe se juntar àquela PAN.
3. Short Address: Também conhecido como endereço do dispositivo, este endereço é um endereço de 16 bits atribuído ao dispositivo pelo seu Coordinator. Ele deve ser único na PAN. O PAN Coordinator sempre possui este endereço como 0000h.

O protocolo MiWi usa os 16 bits disponíveis no Short Address para ajudar com o roteamento e troca de informações nos nós. O significado de cada bit é mostrado abaixo.

O campo Parent's Number (bits 10 a 8) é único para cada coordinator da rede, incluindo o PAN Coordinator. Como este campo só possui 3 bits, temos no máximo 8 coordinators em uma rede.
O campo RxOffWhenIdle (bit 7) é o inverso da propriedade definida pela IEEE 802.15.4 de RxOnWhenIdle. Quando o bit está setado, ele indica que este dispositivo vai desligar seu transceptor quando estiver desocupado e ficará incapacitado de receber pacotes. Qualquer dispositivo deverá rotear qualquer pacote que tenha este bit setado ao dispositivo pai deste dispositivo. O dispositivo pai por sua vez vai guardar estes pacotes até que ele volte a habilitar seu transceptor e requeira os dados. Se este bit não for setado no endereço do dispositivo, então o dispositivo é sempre capaz de receber pacotes.
O campo Child's Number (bits 6 a 0) de cada coordinator da rede é 00h. Isto indica que eles estão operando como coordinators. Outros valores para este campo são determinados pelo tipo de dispositivo (FFD ou RFD), assim como sua função na PAN. Abaixo temos uma idéia geral de como endereços são determinados.

Como pode-se ver, o PAN Coordinator possui endereço 0000h. Outros Coordinators assumem um endereço específico para os grupos, enquanto os dispositivos ligados a estes Coordinators, assumem um endereço ligado a eles.

Mensagens no protocolo MiWi

Assim que uma rede é formada, o próximo passo é definir como serão transferidos os pacotes pela rede MiWi. Se por acaso uma conexão P2P foi formada, então o endereço usado será o endereço longo, e não o endereçamento curto (Short Address) usado no item anterior.

Formato do pacote

O protocolo MiWi usa a camada MAC da especificação IEEE 802.15.4 para seus pacotes. Nós que se uniram à rede usarão o modo Short Address fornecido por esta especificação. Nós P2P, como dissemos há pouco, usarão o modo Long Address para a fonte e destino.
Acima desta camada reside o cabeçalho do protocolo MiWi que contém informação necessária para roteamento e processamento de pacotes. A figura abaixo mostra o formato do cabeçalho:

Hops: Quantidade de vezes que o pacote pode ser retransmitido, onde o valor 0 significa que este pacote não pode ser retransmitido. Tamanho de 1 byte.
Frame Control: Conjunto de bits que definem o comportamento deste pacote. Tamanho de 1 byte.
Dest PANID: O PANID do destino, tamanho de 2 bytes no protocolo MiWi.
Dest Short Address: Endereço final do destino, com 2 bytes de tamanho.
Source PANID: O PANID da fonte, com 2 bytes.
Source Short Address: Endereço da fonte do pacote, com 2 bytes.
Sequence number: Número de sequência que serve para monitorar o status de um pacote enquanto trafega pela rede, com 1 byte de tamanho.
Report Type: O agrupamento da mensagem contida neste pacote. Todos os pacotes gerados pelo stack possuem valor 00h, enquanto que os pacotes gerados pelo usuário podem variar de 01h a FFh. Tamanho de 1 byte.
Report ID: Tipo de mensagem contida neste pacote, com 1 byte.

Abaixo uma descrição dos bits do Frame Control:

Bit	Nome do campo	Descrição
7-3	Reservados	Mantidos como '0' nesta implementação.
2	ACKREQ	Acknoledge Request bit, que quando setado, requere de uma camada superior um Acknoledgement de recepção do dispositivo de destino.
1	INTRCLST	Intra Cluster bit, reservado nesta implementação, usar como '1'.
0	ENCRYPT	Encrypt bit, que quando setado, indica que o pacote é encriptado no nível de aplicação.

Roteamento

Roteamento em uma rede wireless pode ser muito difícil e uma tarefa que consome muito recurso. O protocolo MiWi resolve este problema usando a alocação de endereços para indicar o pai do dispositivo a receber o pacote, e também usando os serviços IEEE já existentes para ajudar a trocar e chavear informações na rede.

Descobrindo Coordinators vizinhos

Uma das tarefas do algoritmo de roteamento é determinar o próximo passo para qualquer pacote. O protocolo MiWi usa o mecanismo de união da rede IEEE, adicionado ao tráfego normal de rede, para descobrir estes caminhos. Quando qualquer dispositivo se une à rede, ele primeiro envia um pacote beacon de requisição. Todos os Coordinators que recebem o pacote de requisição enviam um pacote beacon informando dispositivos próximos de suas informações de rede.
No protocolo MiWi, três bytes de informação adicional são inseridas no payload do pacote beacon para ajudar com o roteamento:
Protocol ID (1 byte): Isto ajuda a distinguir protocolos de rede MiWi de outros protocolos IEEE 802.15.4, que possam estar operando na mesma região. O Protocol ID deve ser sempre 4Dh.
Version Number (1 byte): O número de versão desta especificação. Stacks baseados nesta especificação deverão ser sempre 10h.
Local Coordinators (1 byte): Este campo é um campo de bits que indica quais coordinators são atualmente visíveis pelos coordinator que está enviando o pacote beacon. Cada posição no campo de bits representa diretamente um de 8 possíveis coordinators. O bit 0 é o endereço 0000h (o Pan Coordinator). O bit 1 indica que este coordinator pode falar diretamente com o 0100h. Como dissemos antes, temos no máximo 8 coordinators, e cada bit aqui especifica um deles. A Microchip dá um exemplo de como este campo ficaria em um coordinator de endereço 200h, que possui o PAN Coordinator e o coordinator 500h. Seu campo de bits ficaria b00100101. Observem que neste exemplo, o próprio coordinator se coloca como visível, o que não deixa de fazer sentido.

Através do campo Local Coordinators, todos os coordinators da rede poderão saber quais as possíveis rotas para todos os nós sem precisar enviar requisições específicas.

Roteando para outros dispositivos

Roteando em uma rede MiWi se torna fácil assim que se tem conhecimento dos coordinators mais próximos, assim como o que aqueles coordinators podem ver. O algoritmo de roteamento segue o fluxograma abaixo:

Mensagens de Broadcast

Quando um coordinator de rede MiWi recebe um pacote de broadcast, ele irá retransmitir o broadcast contanto que o contador de hops (o primeiro byte do cabeçalho) não for igual a zero. Pacotes de broadcast não são repassados para end devices.
Pacotes de broadcast devem ter sempre seu ACK request bit (tanto no cabeçalho MiWi quanto no cabeçalho MAC) definidos como '0'. Coordinators que recebem o pacote devem processar o pacote depois de recebê-lo.

Conclusão

Aqui vimos como os endereços deste protocolo funcionam, bem como funciona o esquema de roteamento de mensagens. Esperamos ter esclarecido esta parte do protocolo, e já nos preparando para a próxima parte.

MiWi: Dispositivos e Topologias de rede

Recentemente iniciei um trabalho onde eu teria que desenvolver um equipamento que pudesse se comunicar através de algum tipo de protocolo wireless. Meu cliente então me trouxe uma placa de desenvolvimento que usa o módulo MRF24J40MA da Microchip. Devo confessar que não tinha qualquer experiência com protocolos wireless, e vi uma ótima oportunidade de dar inicio aos meus estudos nesta área. O que vou escrever aqui está baseado no Application Note AN1066 - MiWi Wireless Networking Protocol Stack, da Microchip.
Por enquanto, fiquemos com a introdução à este protocolo, baseado nas camadas MAC (Medium Access Layer) e PHY (Physical Layer) da especificação do IEEE 802.15.4. Esta especificação é a mesma especificação básica para o protocolo ZigBee, portanto para aqueles que já estão familiarizados com este protocolo, muita coisa por aqui será apenas repetição do que já viram. No caso, o ZigBee e o MiWi desenvolvem as camadas superiores que não são definidas por esta especificação.
Vejamos então o que a especificação IEEE 802.15.4 define, ao mesmo tempo que tratarmos do que o MiWi adiciona. Em primeiro lugar, ela define três frequências de operação: 2.4GHz, 915MHz e 868MHz. Cada frequência oferece um número fixo de canais, e possui uma taxa máxima de transmissão, que para facilitar, disponho no quadro abaixo:

Frequência	Canais (Número do canal)	Máximo Throughput de dados (kbps)
868 MHz	1 (0)	20
915 MHz	10 (1-10)	40
2.4 GHz	16 (11-26)	250

Um pacote MAC do IEEE 802.15.4 tem tamanho máximo de 127 bytes, incluindo um CRC de 16 bits. Além disto, o IEEE 802.15.4 opcionalmente usa um mecanismo de transferência com Acknoledge no MAC. Isto significa que há um flag especial ACK no cabeçalho do pacote. Quando este flag está setado, um Acknoledgement é requerido. Isto vai garantir que o pacote foi recebido, embora isto não garanta que o pacote chegue a camadas superiores dentro do stack (o pacote pode ser descartado por alguma camada intermediária do stack). Se o flag ACK for setado e o ACK não for recebido dentro de certo tempo, o transmissor fará uma nova transmissão. Ele repetirá isto uma certa quantidade de vezes até gerar um erro.

Tipos de dispositivos

O IEEE 802.15.4 também define dispositivos baseados em sua funcionalidades, que são basicamente duas. Disponibilizo aqui também uma tabela com a descrição de cada dispositivo.

Tipo de Dispositivo	Serviços oferecidos	Fonte de Tensão típica	Configuração típica para o Receptor oscioso
Full Function Device (FFD)	Todos ou a maior parte	Rede de alimentação	Ligado
Reduced Function Device (RFD)	Limitado	Bateria	Desligado

Já o MiWi define três tipos de dispositivos, desta vez em relação ao seu status na rede. Aqui temos o PAN Coordinator, o Coordinator e o End Device.

Tipo de Dispositivo	Tipo de dispositivo IEEE	Função típica
PAN Coordinator	FFD	Um por rede. Forma a rede, aloca os endereços de rede, mantém a tabela de conexões.
Coordinator	FFD	Opcional. Estende o alcance físico da rede. Permite que mais nós se unam à rede. Pode também executar funções de monitoramento ou controle.
End Device	FFD ou RFD	Executa funções de monitoramento e controle.

Topologias de rede

Dos três dispositivos definidos pelo protocolo MiWi, o mais importante para a a rede é o PAN Coordinator. É ele quem inicializa a rede, seleciona o canal e o PAN ID da rede. Todos os outros dispositivos devem obedecer as instruções dadas pelo PAN Coordinator, para se unir à rede. Esta rede pode ter quatro configurações possíveis, que vamos mostrar aqui. As imagens foram retiradas do já mencionado Application Note.

Configuração em Estrela

A configuração em estrela consiste de um PAN Coordinator e um ou mais End Devices. Na rede em estrela, todos os dispositivos se comunicam unicamente com o PAN Coordinator. Se algum dispositivo precisa enviar dados para outro dispositivo, ele enviará primeiro para o PAN Coordinator, que por sua vez encaminhará o pacote para o outro dispositivo.

Configuração Cluster-Tree

Na configuração Cluster-Tree, continuamos a ter apenas um PAN Coordinator. Contudo, outros Coordinators podem se unir à rede, formando uma estrutura de rede em árvore: o PAN Coordinator seria a raiz, os Coordinators seriam os ramos, e os End Devices seriam as folhas. Neste tipo de rede, todas as mensagens enviadas pela rede seguem o caminho da estrutura em árvore. Já que as mensagens podem ser roteadas através de mais de um nó para que elas cheguem a seu destino, este tipo de rede algumas vezes é referido como redes multi-hop (salto múltiplo).

Configuração Mesh

A rede Mesh é parecida com a rede Cluster-Tree, exceto pelo fato de que dispositivos FFD podem rotear mensagens diretamente a outros dispositivos FFD, ao invés de seguir a estrutura de árvore da rede. No entanto, mensagens de dispositivos RFD ainda precisam passar pelo elemento pai deste dispositivo.
Uma grande vantagem nesta topologia é a diminuição no tempo de latência das mensagens, além da confiabilidade ser aumentada. Como as redes cluster-tree, a rede mesh é também uma rede multi-hop.

Configuração Ponto a ponto (P2P)

O tipo mais simples de configuração, aqui não há distinção entre pai ou filho, pois a comunicação é direta.

Redes Multi-acesso

Uma rede IEEE 802.15.4 é uma rede multi-acesso, significando que todos os nós em uma rede possuem igual acesso ao meio de comunicação. Há dois tipos de mecanismos multi-acesso: beacon (farol) e non-beacon.
Em uma rede beacon, os nós podem transmitir em fatias de tempo predefinidas. O PAN Coordinator periodicamente inicia com um superframe, identificado como um beacon frame, e todos os nós na rede devem sincronizar com este frame. A cada nó é atribuída uma fatia específica no superframe, durante a qual, é permitida a transmissão e recepção. Um superframe pode também conter um slot comum durante a qual todos os nós competem pelo acesso do canal.
Em uma rede non-beacon, todos os nós em uma rede podem transmitir a qualquer hora desde que o canal esteja desocupado. A versão atual do MiWi suporta apenas redes non-beacon.

Primeiras conclusões

Temos aqui uma pequena descrição deste protocolo wireless da Microchip. Hoje em dia, os protocolos wireless estão cada vez mais fáceis de ser implementados, já que muitos fabricantes desenvolvem módulos completos.
Este protocolo tem como vantagem o custo, além de seus módulos possuírem tamanhos reduzidos.
Posteriormente falarei mais sobre o endereçamento neste protocolo, bem como o sistema de mensagens.