IoT(Internet Of Things)
The official title of 802.15.4 is Low-Rate Wireless Personal Area Networks (LR-WPANs). As the title says, this is the specification for Small Area Network (Personal Area Network) with very low data rate and very low energy consumption. And it is basically the specification for MAC layer. It also provides the general guide lines for PHY layer but there can be many other implementation with different PHY implementation.
This page covers the MAC side of 802.15.4. It shows where the MAC sits in the stack, what it can do, and what its four frame types look like on the air. The PHY side, with its bands, modulations and PPDU format, is on the 802.15.4 PHY page.
Overall Protocol Stack
Before we look at individual frames, let's place the MAC in the stack. 802.15.4 defines only the two lowest layers, the PHY and the MAC. Everything above the MAC comes from another standard, and that choice decides whether the network is ZigBee, 6LoWPAN or something else.
Overall protocol stack suggested by 802.15 and MAC and PHY frame are is as follows.
The left side of the picture shows how one frame is nested. The MAC frame becomes the PHY payload, and the PHY adds its own two headers in front of it. The right side shows the service access points, SAPs, through which each layer serves the layer above it.
- Sync Header (SHR) : the preamble and the Start of Frame Delimiter. The receiver uses it to detect the frame and to lock its timing.
- PHY Header : the frame length of the PSDU. The picture labels this block MHR, but the standard abbreviation is PHR. MHR is the MAC Header in the upper row.
- PHY Payload (PSDU) : the complete MAC frame, that is MAC Header, MAC Payload and MAC Footer. Its maximum length is 127 octets.
- MCPS SAP and MLME SAP : the MAC data service and the MAC management service. Upper layers send data through MCPS, and they control the MAC, for example for a scan or an association, through MLME.
- PD SAP and PLME SAP : the same split one layer down. PD carries data to the PHY, and PLME carries management requests such as channel selection and energy detection.
Currently (as of Jun 2015), there are two most widely used implementation that adopting this architecture. They are ZigBee and 6LoPAN and their overall structure is as follows. (I will post separate pages for ZigBee and 6LoPAN)
Both stacks in the picture keep the same MAC block with the same two SAPs. The difference is the block above the MAC. ZigBee puts its own network and application layers there. 6LoWPAN, written 6LoPAN in the picture, puts an adaptation layer there, and that layer lets IPv6 run over 802.15.4 frames. The bottom block of each stack carries the stack name, but the radio under both stacks is still an 802.15.4 PHY. So a ZigBee node and a 6LoWPAN node can use the same 802.15.4 radio hardware and differ only in software.
802.15.4 stops at the MAC : the network layer and everything above it come from ZigBee, 6LoWPAN or another stack.One MAC frame fits in one PHY frame : the MAC frame is the PSDU, so the 127 octet PSDU limit is also the MAC frame limit.Each layer has a data SAP and a management SAP : MCPS and PD carry data, while MLME and PLME carry control.
Summary
Let's collect the main MAC properties in one list before we go into the frame formats. Most items below appear again later on this page, either as a field in the frame header or as a behaviour you can see in the captures.
- Allow mesh networking and a node can forward a packet to another node
- A Node uses 64 bit address (extended address) or 16 bit address (short address)
- There can be Node Coordinator (like WiFi AP) and the coordinator assigns 16 bit address for use during the association
- Maximum Frame Size is 127 bytes : How can this small frame carry IPv6 packet (usually very big) ?
- Perform retransmission (Fully Acknowleged protocol for transfer reliability)
- Operates base on CSMA-CA or ALOHA channel access
- Support Energy Detection (ED) capability
- Support Link Quality Indicatioin (LQI)
- (Optional) I can allocate guaranteed time slot (GTS)
- (Optional) it can perform routing (Data Link layer routing)
The fourth item raises a real problem, and the list leaves it open. IPv6 requires every link to carry a packet of 1280 octets. An 802.15.4 frame carries at most 127 octets, and the MAC header and FCS can take 25 of them. Link-layer security can take another 21 octets, so in the worst case only 81 octets remain. The IPv6 header alone uses 40 of those octets, and UDP uses 8 more.
6LoWPAN solves this with an adaptation layer between IPv6 and the MAC. The layer compresses the IPv6 and UDP headers, because many header fields can be derived from the 802.15.4 addresses. It also splits a large IPv6 packet into fragments, sends each fragment in its own 802.15.4 frame, and reassembles the packet at the receiver. This adaptation layer is the block above the MAC in the 6LoPAN stack of the Overall Protocol Stack section.
Two address sizes serve two purposes : the 64 bit extended address is unique to the device, and the 16 bit short address saves header space after association.127 octets is the whole MAC frame : headers, security and FCS all come out of it, so the space left for upper-layer data is much smaller.IPv6 needs an adaptation layer : 6LoWPAN header compression and fragmentation make the 1280 octet IPv6 MTU possible over 127 octet frames.
Frame Structure
Every 802.15.4 MAC frame has the same outer shape: a MAC Header (MHR), a MAC Payload and a MAC Footer (MFR). The MFR is always the 2 octet FCS. The first field of the MHR, the Frame Control field, tells the receiver which of the four frame types it holds.
There are four different MAC frames as listed below :
- Beacon frames : Used by a Coordinator
- MAC command frames : Used for handling all MAC peer entity control transfer
- Acknowledgement frames : Used for confirming successful frame reception
- Data frames : Used for all transfer of data
Data Frame is the frame over which IPv6 packets are being carried. Followings are the structure of each type of frames.
< 802.15.4 Figure 38—Beacon frame format >
Following is an example 802.15.4 MAC frame captured by Wireshark from Wirehshark - IEEE 802.15.4 page.
Decoded
IEEE 802.15.4 Beacon, Src: 0x0000
Frame Control Field: Beacon (0x8000)
.... .... .... .000 = Frame Type: Beacon (0x0000)
.... .... .... 0... = Security Enabled: False
.... .... ...0 .... = Frame Pending: False
.... .... ..0. .... = Acknowledge Request: False
.... .... .0.. .... = Intra-PAN: False
.... 00.. .... .... = Destination Addressing Mode: None (0x0000)
..00 .... .... .... = Frame Version: 0
10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x0002)
Sequence Number: 99
Source PAN: 0x01ff
Source: 0x0000
Superframe Specification
.... .... .... 1111 = Beacon Interval: 15
.... .... 1111 .... = Superframe Interval: 15
.... 1111 .... .... = Final CAP Slot: 15
...0 .... .... .... = Battery Extension: False
.1.. .... .... .... = PAN Coordinator: True
1... .... .... .... = Association Permit: True
GTS
GTS Descriptor Count: 0
GTS Permit: False
Pending Addresses: 0 Short and 0 Long
ZigBee Beacon
Protocol ID: 0
Stack Profile: Network Specific (0x00)
Protocol Version: 2
Router Capacity: True
Device Depth: 0
End Device Capacity: True
Extended PAN ID: Miniware_6f:73:6e:65:73 (00:00:72:6f:73:6e:65:73)
Tx Offset: 16777215
Update ID: 0
0000 00 80 63 ff 01 00 00 ff cf 00 00 00 20 84 73 65 ..c......... .se
0010 6e 73 6f 72 00 00 ff ff ff 00 nsor......
Let's read the Frame Control field of this beacon first, because the same 16 bits open every capture on this page. Wireshark shows the field as 0x8000, but the hex dump starts with 00 80. The field is sent low octet first, so the dump shows the two octets in reverse order. The three lowest bits give the frame type, and the red line in each capture marks them. The values are 000 for a beacon, 001 for data, 010 for an acknowledgment and 011 for a MAC command.
The two addressing mode fields then decide how long the addressing fields are. This beacon has no destination address and a 16 bit source address, so its addressing fields hold only the Source PAN and the Source. In the Superframe Specification, Beacon Interval and Superframe Interval are the Beacon Order and the Superframe Order. The value 15 means that the PAN sends no periodic beacons, so this is a nonbeacon-enabled PAN. In such a PAN, a coordinator sends a beacon only in reply to a Beacon Request command during a scan.
< 802.15.4 Figure 46—Data frame format >
Following is an example 802.15.4 MAC frame captured by Wireshark from Wirehshark - IEEE 802.15.4 page.
Decoded
IEEE 802.15.4 Data, Dst: Broadcast, Src: 0x2c4d
Frame Control Field: Data (0x8841)
.... .... .... .001 = Frame Type: Data (0x0001)
.... .... .... 0... = Security Enabled: False
.... .... ...0 .... = Frame Pending: False
.... .... ..0. .... = Acknowledge Request: False
.... .... .1.. .... = Intra-PAN: True
.... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
..00 .... .... .... = Frame Version: 0
10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x0002)
Sequence Number: 14
Destination PAN: 0x01ff
Destination: 0xffff
Source: 0x2c4d
[Extended Source: ExeginTe_ff:ff:00:20:07 (00:1c:da:ff:ff:00:20:07)]
[Origin: 23]
ZigBee Network Layer Data, Dst: Broadcast, Src: 0x2c4d
Frame Control Field: Data (0x0248)
.... .... .... ..00 = Frame Type: Data (0x0000)
.... .... ..00 10.. = Protocol Version: 2
.... .... 01.. .... = Discover Route: Enable (0x0001)
.... ...0 .... .... = Multicast: False
.... ..1. .... .... = Security: True
.... .0.. .... .... = Source Route: False
.... 0... .... .... = Destination: False
...0 .... .... .... = Extended Source: False
Destination: 0xfffd
Source: 0x2c4d
Radius: 30
Sequence Number: 123
[Extended Source: ExeginTe_ff:ff:00:20:07 (00:1c:da:ff:ff:00:20:07)]
[Origin: 19]
ZigBee Security Header
Security Control Field
...0 1... = Key Id: Network Key (0x01)
..1. .... = Extended Nonce: True
Frame Counter: 0
Extended Source: ExeginTe_ff:ff:00:20:07 (00:1c:da:ff:ff:00:20:07)
Key Sequence Number: 0
Message Integrity Code: 9376f9f8
[Expert Info (Warn/Undecoded): Encrypted Payload]
[Message: Encrypted Payload]
[Severity level: Warn]
[Group: Undecoded]
Data (20 bytes)
Data: 31316d646805adc32b8eafa8e32b726e3bb5a52e
[Length: 20]
0000 41 88 0e ff 01 ff ff 4d 2c 48 02 fd ff 4d 2c 1e A......M,H...M,.
0010 7b 28 00 00 00 00 07 20 00 ff ff da 1c 00 00 31 {(..... .......1
0020 31 6d 64 68 05 ad c3 2b 8e af a8 e3 2b 72 6e 3b 1mdh...+....+rn;
0030 b5 a5 2e 93 76 f9 f8 ....v..
Intra-PAN is True in this frame, so the frame carries the Destination PAN only and leaves out the Source PAN. Later editions of 802.15.4 call this bit PAN ID Compression. The MAC Payload is a ZigBee network layer frame. ZigBee security has encrypted the application data, so Wireshark cannot decode the last 20 octets.
< 802.15.4 Figure 48—MAC command frame format>
Following is an example 802.15.4 MAC frame captured by Wireshark from Wirehshark - IEEE 802.15.4 page.
Decoded
IEEE 802.15.4 Command, Dst: 0x0000, Src: ExeginTe_ff:ff:00:20:07
Frame Control Field: Command (0xc823)
.... .... .... .011 = Frame Type: Command (0x0003)
.... .... .... 0... = Security Enabled: False
.... .... ...0 .... = Frame Pending: False
.... .... ..1. .... = Acknowledge Request: True
.... .... .0.. .... = Intra-PAN: False
.... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
..00 .... .... .... = Frame Version: 0
11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x0003)
Sequence Number: 12
Destination PAN: 0x01ff
Destination: 0x0000
Source PAN: 0xffff
Extended Source: ExeginTe_ff:ff:00:20:07 (00:1c:da:ff:ff:00:20:07)
Command Identifier: Association Request (0x01)
Association Request
.... ...0 = Alternate PAN Coordinator: False
.... ..1. = Device Type: True (FFD)
.... .1.. = Power Source: True (AC/Mains Power)
.... 1... = Receive On When Idle: True
.1.. .... = Security Capability: True
1... .... = Allocate Address: True
0000 23 c8 0c ff 01 00 00 ff ff 07 20 00 ff ff da 1c #......... .....
0010 00 01 ce ...
Command Identifier 0x01 is the Association request, the first row of the command frame identifier table under 802.15.4 Figure 48. The device sends this command with its 64 bit extended source address, because it has no short address before association. The Allocate Address bit asks the coordinator for a 16 bit short address, which is the address assignment of the Summary list. Acknowledge Request is True, so the coordinator must answer with an acknowledgment frame.
< 802.15.4 Figure 47—Acknowledgment frame format >
Following is an example 802.15.4 MAC frame captured by Wireshark from Wirehshark - IEEE 802.15.4 page.
Decoded
IEEE 802.15.4 Ack, Sequence Number: 12
Frame Control Field: Ack (0x0002)
.... .... .... .010 = Frame Type: Ack (0x0002)
.... .... .... 0... = Security Enabled: False
.... .... ...0 .... = Frame Pending: False
.... .... ..0. .... = Acknowledge Request: False
.... .... .0.. .... = Intra-PAN: False
.... 00.. .... .... = Destination Addressing Mode: None (0x0000)
..00 .... .... .... = Frame Version: 0
00.. .... .... .... = Source Addressing Mode: None (0x0000)
Sequence Number: 12
0000 02 00 0c
This acknowledgment carries Sequence Number 12, the same value as the Association request above. The acknowledgment has no address fields, so the sender matches it to its own frame by this number only. The hex dump holds 3 octets, the Frame Control field and the Sequence Number. The 2 octet FCS of 802.15.4 Figure 47 is not in the capture.
The three lowest Frame Control bits give the frame type : 000 is a beacon, 001 is data, 010 is an acknowledgment and 011 is a MAC command.The addressing modes set the header length : each address can be absent, 16 bits or 64 bits, so the MHR length changes from frame to frame.Multi-octet fields are sent low octet first : 0x8000 in the decode appears as 00 80 in the hex dump.An acknowledgment carries only a sequence number : the sender matches it to the frame it sent by that number.
Reference
- RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks
- Wireshark wiki - IEEE 802.15.4 : source of the sample captures