Difference between revisions of "NIS Generic Application Protocol"
(Created page with "== Generic Application Protocol description == === Nemeus uplink protocol === Nemeus uplink protocol is used to send sensor data to application server. The payload contains...") |
m (Lcs moved page MSxxx Generic Application Protocol to NIS Generic Application Protocol without leaving a redirect) |
(No difference)
|
Latest revision as of 08:34, 8 September 2017
1 Generic Application Protocol description
1.1 Nemeus uplink protocol
Nemeus uplink protocol is used to send sensor data to application server. The payload contains the following fields:
- <mask>: At least 1 byte containing a bit field identifying the fields included in the frame. The meaning of the mask is specific to the couple device/port. Thus, the application server knows the mask meaning according to the data profile linked to the couple device/port. The most significant bit of the <mask> is used to extend the mask on the next byte: 1 means not extended (mask is on 7 bits) and 0 means extended (mask is on 14 bits). When extended, the following byte can also be extended according to its most significant bit. When the <mask> field is on several bytes, it is encoded in little endian (LSB first). For example, a <mask> coded on 2 bytes like “00100001 11001100” will be on 14 bits: “10011000100001”. Each bit indicates the presence/absence of a field. When a field is present, it appears in the frame according to the bit position (beginning with the least significant bit).
- <field1>: first data field identified by the data profile linked to the couple device/port.
- …
- <fieldN>: last data field identified by the data profile linked to the couple device/port.
1.2 Nemeus downlink protocol
Nemeus downlink protocol is used to exchange commands between application servers (located in network infra or in configuration PC) and sensor embedded applications.
Application port is used to address an application (application ports are bound with LoRaWAN ports). Thus, the protocol consists in a binary payload exchanged on a port. The payload contains the following fields:
- <cmd>: 1 byte identifying an applicative command/response.
- <mask>: At least 1 byte containing a bit field identifying the fields included in the frame. See uplink protocol above for description.
- <field1>: first data field identified by the data profile linked to the couple device/port.
- …
- <fieldN>: last data field identified by the data profile linked to the couple device/port.
Most significant bit of <cmd> field specifies if response is expected by the server or not (commands of type “set” doesn’t require any answer, especially when radio interface is used).
<cmd> values are defined for each application port (e.g. <cmd> value 0x01 has a different meaning on port 1 than on port 2).
A response reuse the same <cmd> as the received command, except the most significant bit which is forced to 0 (because a response doesn’t expect any response). The response <mask> indicates which fields of the command have been actually processed.
When a parameter type size is more than one byte, it is encoded in little endian (LSB first).
Downlink command may be received either from network application server or from PC configuration tool through AT command.
The generic application AT command is used:
AT+GA=DIND,<port>,<hexpayload>.