-
Notifications
You must be signed in to change notification settings - Fork 2
OSNP over IEEE 802.15.4
OSNP over IEEE 802.15.4 is designed for embedded and possibly battery powered devices. It provides a way to exchange OSNP Application Layer messages over an IEEE 802.15.4-2003 interface.
The protocol is designed to work with any IEEE 802.15.4-2003 (or above) transceiver, and maintains its frame structure, although it redefines some of its MAC Commands to better fit the needs of an OSNP network.
Security is defined according the IEEE 802.15.4-2003 standard, with additional commands meant to make session persistence resistant to sudden power losses or other events.
If you are not familiar with OSNP yet, please read the OSNP Application Layer specifications first. If you are not familiar with IEEE 802.15.4-2003 standard, I suggest you read that first, but most concepts will be repeated here.
In a 802.15.4 network a device must assume the role of PAN (Personal Area Network) coordinator, which controls communication between all other devices and allocates short addresses. In an OSNP network, this role is performed by the Hub. The Hub always starts a non-beacon enabled PAN. This allows battery powered devices to save power by determining their own duty cycle independently.
Each PAN has its own 2-bytes identifier, which must be unique in the radio range of the hub and its associated devices.
Devices communicate with the hub by exchanging frames.
Unlike most network protocols, the IEEE 802.15.4 header fields are encoded using little-endian.
The frame structure is according the IEEE 802.15.4-2003 standard. This was a practical choice, since many compatible transceiver supporting this frame format exist on the market. In the 2006 version of the standard the security header has been redefined. Since most 802.15.4-2003 transceiver offer hardware encryption/decryption support and many support only the older header format, we decided to use that.
The frame structure is as follow:
| Octets: 2 | 1 | 0/2 | 0/2/8 | 0/2 | 0/2/8 | variable | 2 |
|---|---|---|---|---|---|---|---|
| Frame control | Sequence Number | Destination PAN | Destination Address | Source PAN | Source Address | Payload | FCS |
The frame control is composed of two bytes. For easy of reading, we'll look at them individually, in the same order in which they are encoded in the frame. All reserved bits must be set to 0
| Bit: 0-2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|
| Frame type | Security Enabled | Frame pending | Ack request | Intra-PAN | Reserved |
OSNP uses 3 of the defined frame types. Their values are
| Value | Type |
|---|---|
| 0x01 | Data |
| 0x02 | Acknowledgment |
| 0x03 | MAC Command |
This bit indicates whether this frame is secured or not
This bit indicates whether the hub has pending frames for the device.
This bit indicates whether an Ack is requested for this frame or not
This bit is set when the source PAN is equal to the destination PAN and is thus omitted in the header.
| Bit: 0-1 | 2-3 | 4-5 | 6-7 |
|---|---|---|---|
| Reserved | Destination addressing mode | Reserved | Source addressing mode |
Both fields have the same encoding and they indicate how the destination and source addresses, respectively, are written in the header. Their value can be as follows:
| Value | Type |
|---|---|
| 0x00 | PAN and address not present |
| 0x02 | Short address (16-bit) |
| 0x03 | Extended address (64-bit) |
The sequence number is a number incremented by one for each frame sent. It is used to as a reference number to acknowledge frames. This counter is allowed to roll over (i.e. after 255 it will be 0 again)
This is the destination PAN identifier. It is only present if the Destination Addressing Mode is not set to "Address not present"
This is the destination address. It can be either the extended address (8 bytes) or the assigned short address (2 bytes). If the Destination Addressing Mode is set to "Address not present" this field is omitted.
This field is the source PAN identifier. It is only present if the Source Addressing Mode is not set to "Address not present" and the Intra-PAN bit of the Frame Control field is not set.
This is the source address. It can be either the extended address (8 bytes) or the assigned short address (2 bytes). If the Source Addressing Mode is set to "Address not present" this field is omitted.
The payload contains the actual data to be sent. This field has the following format
| Octets: 0/4 | 0/1 | variable | 0/4/8/16 |
|---|---|---|---|
| Frame counter | Key Counter | Data | MIC |
The frame counter is a 32-bit counter and provides protection against replay attacks. It must be incremented at least by one after each sent frame. The hub and the device both have their own counter. This counter is not allowed to roll-over.
This field is only present if the Security Enabled bit of the Frame Control bit is set.
The key counter is one byte and should be set at "0x01" for frames sent from a device to the hub and at "0x10" for frame going from the hub to the device. Any other value is reserved for future use.
This field is only present if the Security Enabled bit of the Frame Control bit is set.
This is the (possibly encrypted) data of the frame. In case of a Data frame, this contains an OSNP packet (command, response or notification). In case of a MAC Command frame, the data depends on the specific command.
This is the Message Integrity code. This field is only present if the Security Enabled bit of the Frame Control bit is set. Its length depends on the security level supported by the device. In this revision only one security level is officially defined and supported, with an 8-byte MIC.
This field is a 2-byte checksum. It is usually appended/verified by the transceiver. It is defined in the IEEE 802.15.4 specifications.