cases where all the nodes in the network are within the transmission range of the PAN coordinator. The presence of multiple coordinators, in this case, facilitates beacon discovery and synchronization.
The facility described above may also be used to build multi-cluster PANs and even span distances that exceed the transmission range of coordinator nodes. Interleaving of active periods allows devices with appropriate capabilities to participate in two or more clusters. The resulting tree may then function as a multi-hop network, which is particularly attractive in a number of PAN and sensor network scenarios.
Leaving the cluster. A device may decide to leave (or ‘disassociate from’) the cluster it currently belongs to, which is accomplished by sending a disassociation notification to the coordinator. A device may also be asked to leave by the cluster coordinator, which prepares a disassociation command to be sent (in the form of a downlink packet) to the device. This command may be directly sent to the device, or a regular downlink procedure may be used. In the latter case, the coordinator announces the pending downlink packet in the beacon frame; the device must then explicitly request that this packet is transmitted. Either way, the packet that announces disassociation must be acknowledged by the receiving device.
2.9 Format of the PHY and MAC frames
Finally, we will briefly describe the format of protocol data units (PDUs or packets) at both PHY and MAC layers.
Each PHY layer packet consists of the following elements:
• it begins with a synchronization header, which allows the receiver to synchronize to the incoming transmission;
• it contains a PHY header, which informs the receiver about the size of the subsequent payload;
• it contains a payload – the MAC layer packet.
The PHY header contains a 7-bitfield referred to as the Frame Lengthfield. Its value can be between zero andaMaxPHYPacketSize(the value of which is 127), but some values are reserved. The only allowed values of Frame Length are 5, for acknowledgment packets, and 9 or above, for other kinds of MAC layer packets.
Each MAC layer packet consists of the header, which provides administrative and security information, a variable length payload, and a footer which contains the frame check sequence. The details of the MAC layer packet structure are shown in Table 2.3.
The Frame Controlfield announces the frame type, addressingfields, and other control information, as shown in Table 2.4.
Sequence Number field contains the beacon sequence number, in case of a beacon frame, or a data sequence number that is used to match an acknowledgment frame to the corresponding data or MAC command frame.
Destination and Source PAN Identifier fields, as well as the corresponding Address fields, are optional; their presence and format are guided through appropriate settings in
Table 2.3 MAC packet structure
Element Field Length (in bytes) header Frame Control 2
Sequence Number 1 Destination PAN Identifier 0 or 2 Destination Address 0, 2, or 8 Source PAN Identifier 0 or 2 Source Address 0, 2, or 8 Auxiliary Security Header 0, 5, 6, 10, or 14 payload frame payload variable footer Frame Check Sequence 2
Table 2.4 Structure of the Frame Control Field in the MAC packet header Subfield Bits Allowed values and their meaning Frame Type 0-2 000 Beacon
001 Data
010 Acknowledgment 011 MAC command Security Enabled 3 1 frame is protected Frame Pending 4 1 more data is pending Acknowledgment Request 5 1 acknowledgment is requested
PAN ID Compression 6 1 destination and source PAN identifiers, equal – the latter can be omitted Destination Addressing Mode 10-11 00 PAN ID and address not present
10 16-bit short addresses used 11 64-bit extended addresses used Frame Version 12-13 00 frame compliant with 2003 standard
01 frame compliant with 2006 standard Source Addressing Mode 14-15 00 PAN ID and address not present
10 16-bit short addresses used 11 64-bit extended addresses used Note: Values not shown are reserved for future use.
the Destination and Source Addressing Mode subfields. The short address value of FFFF16
(where the subscript 16 indicates that the number is written using hexadecimal digits) indicate a broadcast transmission that should be received by all devices currently listening to the channel.
The Auxiliary Security Headerfield contains information related to security processing; more details on security provisions of the 802.15.4 standard are given in Chapter 11.
The MAC footer contains a two-byte ITU-T CRC value which is calculated using a standard polynomial of degree 16. It protects the MAC header and the payload.
2.9. FORMAT OF THE PHY AND MAC FRAMES 37 Beacon frame format. The header for a beacon frame contains the followingfields: Frame Control, Sequence Number, Addressing, and Auxiliary Security Header. The addressing fields do not contain any destination addressfields, as the beacon is essentially broadcast to both current and prospective members of the cluster (PAN). The payload contains the superframe specification, the GTS information fields, the Pending Address information fields, and beacon payload.
The Superframe Specificationfield occupies two bytes (16 bits), and contains the current values of the following subfields:
• Beacon Order and Superframe Order, which determine the duration of the beacon interval and active portion of the superframe;
• thefinal superframe slot used by the CAP, the duration of which must not be shorter thanaMinCAPLength symbols;
• Battery Life Extension, which is set to one if frames transmitted to the device emitting the beacon are required to start in or before macBattLifeExtPeriods full backoff periods after the IFS following the beacon;
• PAN Coordinator, which is set to one if the device emitting the beacon is the PAN coordinator (as explained in Section 2.8); and
• Association Permit, which is set to one if the coordinator is accepting association requests.
The GTS information, which is optional, consists of the following:
• the GTS specificationfield, which specifies the number of subsequent GTS descriptors (or, rather, the number of GTSs currently allocated in the CFP) and a GTS Permit subfield which is set to one if the coordinator is currently accepting GTS requests;
• the GTS directionsfield, actually a 7-bit mask that specifies the directions of currently allocated GTSs in the superframe (one for downlink-only, zero for uplink-only); and
• the GTS List field, which lists the GTS descriptors of currently allocated GTSs (of which there can be up to seven); each descriptor consists of the device short address, the starting slot and the duration of the appropriate GTS.
The Pending Address information, which is optional, list the addresses of devices that currently have messages pending with the coordinator. It consists of the following:
• the Pending Address Specificationfield, which contains the number of short addresses pending as well as the number of extended addresses pending; followed by
• the actual addresses, of which there may be at most seven, either short or extended ones (but the short ones must appear before the extended ones).
If the coordinator has more than seven pending packets at a given time, it may announce them in successive beacon frames, but no beacon frame can contain more than seven pending addresses.
Data frame format. The data frame format generally conforms to the rules for the MAC packet outlined above.
Acknowledgment frame format. The acknowledgment frame contains just the Frame Con- trol Field, the Sequence Number equal to the Sequence Number of the data or MAC command frame being acknowledged, and the Frame Check Sequence.
MAC command frame format. A number of MAC commands may be transmitted using this format, which generally conforms to the rules for the MAC frame outlined above but with the payload consisting of a Command Frame Identifier and the corresponding Command Payload. The available MAC commands include Association request and response, Disas- sociation notification, Data request (for extracting the pending downlink packet), Orphan notification, Beacon request (in non-beacon enabled networks), GTS request, Coordinator realignment, and PAN ID conflict notification. The interested reader canfind more details on these in the standard (IEEE 2006).