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.
Nenhum comentário:
Postar um comentário