MAC : UNB

A UNB radio link is slow. The uplink runs at 100 baud, or 600 baud in the USA, and the downlink at 600 baud, as the PHY : UNB page explains. So every bit of MAC overhead costs real time on the air. This page looks at the two MAC frames defined in ETSI GS LTN 003, and at the credentials that identify and authenticate each frame.

Followings are the topics to be covered in this page.

UNB Uplink MAC Frame

The uplink frame is where UNB carries almost all of its traffic. It must fit a useful message, an address and a check into as few bytes as possible. Let's see how the fields share that small budget, and what the payload limit means in practice.

Following is UL MAC Frame Structure defined in LTN 003 5.2.2.2

UNB uplink MAC frame structure

The six fields in the diagram above are sent in this order, and all of them are counted in bytes.

Preamble : 4 Bytes
Frame Sync : 2 Bytes, for frame synchronization
End-Device ID : 4 Bytes, labelled End Point ID in the diagram
Payload : 0 to 12 Bytes
Auth : variable length, for authentication
FCS : 2 Bytes, a CRC as the Frame Check Sequence

The payload can be empty, and it can never exceed 12 Bytes. All the other fixed fields together take 12 Bytes, so a full uplink frame is at least 24 Bytes before the authentication field is added. In other words, even a full frame spends at least half of its fixed length on overhead.

At 100 baud with BPSK, one byte takes 80 ms on the air. So the 4 Byte preamble alone takes 0.32 seconds, and a full frame without its authentication field takes about 1.9 seconds. This is why the payload limit is so strict. A longer payload would raise the airtime of every frame, and in Europe the uplink is also limited to a 1% mean transmission time.

The End-Device ID field is 4 Bytes, which is 32 bits. That matches the length of the NID, the end-point identifier described in the credentials section of this page.

The uplink payload is 0 to 12 Bytes : a UNB message is a short report, not a data stream.
The fixed overhead is 12 Bytes : preamble, frame sync, End-Device ID and FCS, before the variable authentication field.
A full frame takes about 1.9 seconds at 100 baud : so the frame length directly limits how many messages fit under the duty cycle.

UNB Downlink MAC Frame

The downlink frame is built for a different job. It is sent by a LAP, at 600 baud, in a short window after the LEP has transmitted. So the downlink frame does not need the same fields as the uplink frame, and its field sizes are given in bits rather than bytes.

Following is DL MAC Frame Structure defined in LTN 003 5.2.3.2

UNB downlink MAC frame structure

The seven fields in the diagram above are sent in this order.

Preamble : 32 bits
Frame Sync : 13 bits, for frame synchronization
flags : 2 bits
FCS : 8 bits, the Frame Check Sequence
Auth : 16 bits, for authentication
Error Codes : variable
Payload : variable

Let's compare this frame with the uplink frame. The downlink preamble is 32 bits, which is the same length as the 4 Byte uplink preamble. After that the two frames differ. The downlink frame sync is 13 bits instead of 16 bits, and the FCS is 8 bits instead of a 2 Byte CRC. The authentication field has a fixed length of 16 bits, while it is variable on the uplink.

The field order is also different. On the uplink, the FCS closes the frame. On the downlink, the FCS and the authentication field come before the error codes and the payload. The downlink frame also adds two fields that the uplink frame does not have: a 2 bit flags field and a variable error code field.

The downlink field list has no End-Device ID. LTN 003 does not explain how a LEP recognises a downlink frame as its own. Note, however, that the LEP receives downlink messages only in the fixed reception window after its own uplink transmission, as the PHY page describes.

The downlink fixed fields total 71 bits : 32 bit preamble, 13 bit frame sync, 2 bit flags, 8 bit FCS and 16 bit authentication.
The FCS comes early in the downlink frame : it sits before the error codes and the payload, not at the end of the frame.
The downlink frame carries no End-Device ID : the field list in LTN 003 5.2.3.2 does not include one.

How does a UNB frame identify and authenticate its LEP?

Both frames above carry an authentication field, and the uplink frame carries an End-Device ID. But what values go into these fields? Clause 5.4.1 of LTN 003 defines the two credentials that a UNB end-point uses on the radio interface.

The first credential is the identifier, called NID. Each UNB end-point gets a unique NID, and the NID is 32 bits long. The Central Registration Authority (CRA) allocates ranges of NIDs to LEP manufacturers and manages the list of NID ranges. Every radio packet that a UNB end-point sends is tagged with the NID of that end-point.

The second credential is the end-point secret key, called SEK. Each UNB end-point has a 128 bit SEK. The SEK is used to authenticate each radio packet that the end-point transmits.

Authentication is not the same as ciphering. The SEK authenticates the radio packet, but it does not cipher the service payload. Payload ciphering is done at the application level. So the UNB MAC layer proves who sent a frame, and the application protects what the frame says.

The two credentials also stay with the device. When an end-user moves a LEP to a new service provider, the LTN network manages the portability. The NID and the SEK of the LEP remain the same.

NID is the 32 bit identity of a UNB end-point : it fits the 4 Byte End-Device ID field of the uplink frame.
The CRA allocates NID ranges : LEP manufacturers receive ranges, so each NID is unique.
SEK is a 128 bit key for authentication only : the service payload is ciphered at the application level, not by the SEK.
Portability does not change the LEP : the NID and the SEK stay the same, and the LTN network manages the change.

Reference

[1] ETSI GS LTN 003 V1.1.1 (2014-09) - Low Throughput Networks (LTN); Protocols and Interfaces, clauses 5.2.2.2, 5.2.3.2, 5.4.1 and 8.1.2