Sparrow Beacon Format

802.15.4 Beacons

The 802.15.4 beacons are useful for automatically discovering a network that is providing 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.

Basic Beacon Format

IEEE 802.15.4 specifies an optional beacon payload. This is used for meta data about the network. The first byte in the payload describes the payload data protocol type. In order to be compatible with existing ZigBee payload formats first data byte in the payload is, 0xFE, for Yanzi/Sparrow defined payloads. The Data is created in a TLV / “Length, Type and Value” manner and there can be multiple entries in a beacon payload. 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 [T L V] [T L 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 TLV entry. Note that it includes the length of the length byte and the type byte. E.g. minimal length is 2 on valid TLVs except the null TLV 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.

OUI-24 based entry format

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 TLV as the T is just extended to include the OUI + and extra type.

OUI-36 based entry format

TLV type 0x6 implies an OUI-36 based format. The value part of the TLV-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 TLV entries as "SICS OUI" entries. The format of (the value part of) such a TLV-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.

Short operators

The following short operators are defined, with the corresponding arguments:

• 0x01 - Service description (format below)

The rest of the short operators are reserved.

Long operators

There are currently no long format items defined.

Service description item

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)

Examples

A beacon containing a single TLV 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 TLV, indicates a 27 byte size
    2    0x06  TLV 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