-
Notifications
You must be signed in to change notification settings - Fork 15
Sparrow Beacon Format
The 802.15.4 beacons are useful for automatically discovering a network that provides the services requested by a joining device. In Sparrow there is a specific format to use in the beacons to make joining devices understand what services are available.
IEEE 802.15.4 specifies an optional beacon payload. This is used for meta data about the network. The 802.15.4 standard leaves the format of the beacon payload open, which raises the possibility that a device could misinterpret a beacon from an unrelated system as containing relevant information, or vice versa. The payload format defined for Yantzi/Sparrow devices is designed to reduce the risk of such misunderstandings.
-
The first byte in the payload describes the payload data protocol type. In order to be compatible with existing ZigBee payload formats, the first data byte in the payload is 0xFE for Yanzi/Sparrow defined payloads.
-
The Data is created in a LTV / “Length, Type and Value” manner and there can be multiple entries in a beacon payload. The sum of the length of these entries must match the length of the payload as recorded in the beacon frame for the beacon to be considered well formed.
-
Some LTV entries contain OUIs of 24 or 36 bits. Currently only one 24 bit OUI value and one 36 bit OUI value are used, adding further redundancy.
All integers are in Network Byte Order. All strings are UTF-8 encoded.
-------------------------------------------
| Length | Type | Value |
| 1-byte | 1-byte | |
-------------------------------------------
A typical beacon payload will be like the following:
0xfe [L T V] [L T V] 0x00
Where the last byte is a terminating zero length entry.
Specification of the types are as follows:
-
Length - single byte representing the number of bytes in this LTV entry as an unsigned number. Note that it includes the length of the length byte and the type byte. E.g. minimal length is 2 on valid LTVs except the null LTV which has the length of 1 but encodes it as zero (special case).
-
Type - a single byte type representing the type of the field - defined types are:
- 0x01 - 6LoWPAN network type - signalling a 6lowpan network. Data is always: 0x02, 0x01
- 0x02 - OUI-24 defined format (see below).
- 0x03 - Location/Network identifier EUI64. Data is 8 bytes EUI64.
- 0x04 - Probe destination (not used in Sparrow)
- 0x05 - ETX * 128 of node transmitting this beacon reply. 16 bit unsigned integer in network byte order, representing the fixed point value of ETX * 128 (not used in Sparrow)
- 0x06 - OUI-36 defined format (see below).
-
Value - a byte sequence that is defined by the type field.
The OUI-based payload is based on the OUI of the defining part. Yanzi Networks have defined a set of OUI-based types. The 0x02 type is used and the first three bytes of the data will then be a part of the type. For Yanzi - that owns the OUI 0x00 0x90 0xDA using Yanzi-type 1 and a 4-byte value would be:
| L | T | OUI | T V1 V2 V3 V4 |
0x0A 0x02 0x00 0x90 0xDA 0x01 0x01 0x02 0x03 0x04
Note that there is no need for an extra length within the OUI-based LTV as the T is just extended to include the OUI + and extra type.
LTV type 0x6 implies an OUI-36 based format. The value part of the LTV-entry then consists of an OUI-36 followed by additional data, the format of which depends on the particular OUI-36 used. Currently, only one such OUI-36 is used. It is owned by SICS and has the following hexadecimal value:
70-B3-D5-7D-5
In the following, we will refer to these LTV entries as "SICS OUI" entries. The format of (the value part of) such a LTV-entry is:
SICS OUI FORMAT ITEM
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 36 bits | 4 bits | Variable length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length is a whole number of bytes (at least five) with the OUI-36 stored in the first four bytes and the most significant bits of the fifth byte and the format code stored in the four least significant bits in the fifth byte. The following values of the FORMAT field are defined:
- 0x1 - Short item type, consisting of a short operator (8 bits) followed by an argument (size depends on operator)
- 0x2 - Long item type, consisting of a long operator (16 bits) followed by an argument (size depends on operator)
The rest of the FORMAT field values are reserved for future use.
The following short operators are defined, with the corresponding arguments:
- 0x01 - Service description (format below)
The rest of the short operators are reserved.
There are currently no long format items defined.
The service description contains type, address and port encoded in 19 bytes.
Type Address port
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 byte | 16 bytes | 2 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This include the type argument that describe which type of service that is in the 6LoWPAN network.
Types:
- 0x01 - LWM2M server (CoAP)
- 0x02 - LWM2M server (CoAPs)
- 0x03 - LWM2M bootstrap server (CoAP)
- 0x04 - LWM2M bootstrap server (CoAPs)
- 0x05 - Sparrow device server (UDP / Encap)
A beacon containing a single LTV entry that designates an unencrypted LWM2M server with address 0x23...47 and port number 0x3210 looks as follows, with one line per byte:
Byte# Value Comment
0 0xFE Indicates a Sparrow beacon payload
1 0x1B Length part of LTV, indicates a 27 byte size
2 0x06 LTV type 6, indicating an OUI-36
3 0x70 First byte of SICS OUI
4 0xB3 ...
5 0xD5
6 0x7D
7 0x51 Last four bits of SICS OUI and FORMAT code 1, short item
8 0x01 Operator 1, service description
9 0x01 LWM2M server (CoAP)
10 0x23 First byte of IPv6 address of server
...
25 0x47 Last byte of IPv6 address of server
26 0x32 First (most significant) byte of UDP port number of server
27 0x10 Second (least significant) byte of UDP port number of server
28 0x00 Termination of beacon payload