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.