IEEE 802.15.4

IEEE 802.15.4 is a standard which specifies the physical layer and media access control for low-rate wireless personal area networks (LR-WPANs). It is the basis for the ZigBee, ISA100.11a , WirelessHART, and MiWi specifications, each of which further extends the standard by developing the upper layers which are not defined in IEEE 802.15.4. Alternatively, it can be used with 6LoWPAN and standard Internet protocols to build a Wireless Embedded Internet.

The basic framework conceives a 10-meter communications range with a transfer rate of 250 kbit/s

Lower transfer rates of 20 and 40 kbit/s were initially defined, with the 100 kbit/s rate being added in the current revision.

Important features include real-time suitability by reservation of guaranteed time slots, collision avoidance through CSMA/CA and integrated support for secure communications.

IEEE 802.15.4-conformant devices may use one of three possible frequency bands for operation.

Protocol architecture

Devices are conceived to interact with each other over a conceptually simple wireless network .

The physical layer:

PHY manages the physical RF transceiver and performs channel selection and energy and signal management functions.It operates on one of three possible unlicensed frequency bands:

868.0-868.6 MHz: Europe, allows one communication channel (2003, 2006)

902-928 MHz: North America, up to ten channels (2003), extended to thirty (2006)

2400-2483.5 MHz: worldwide use, up to sixteen channels (2003, 2006)

Beyond these three bands, the IEEE 802.15.4c study group is considering the newly opened 314-316 MHz, 430-434 MHz, and 779-787 MHz bands in China, while the IEEE 802.15 Task Group 4d is defining an amendment to the existing standard 802.15.4-2006 to support the new 950 MHz-956 MHz band in Japan. First standard amendments by these groups were released in April 2009.

The MAC layer:

The medium access control (MAC) enables the transmission of MAC frames through the use of the physical channel

It offers a management interface and itself manages access to the physical channel and network beaconing

It also controls frame validation, guarantees time slots and handles node associations. Finally, it offers hook points for secure services.

Network model

Node types: The standard defines two types of network node.

FFD(full-function device): It can serve as the coordinator of a personal area network just as it may function as a common node. It implements a general model of communication which allows it to talk to any other device: it may also relay messages, in which case it is dubbed a coordinator (PAN coordinator when it is in charge of the whole network).

RFD( reduced-function devices):These are meant to be extremely simple devices with very modest resource and communication requirements; due to this, they can only communicate with FFD's and can never act as coordinators.

Topologies

Networks can be built as either peer-to-peer or star networks. Every network needs at least one FFD to work as the coordinator of the network. Each device has a unique 64-bit identifier, and if some conditions are met short 16-bit identifiers can be used within a restricted environment.

Data transport architecture:
Frames are the basic unit of data transport, of which there are four fundamental types (data, acknowledgment, beacon and MAC command frames)Additionally, a superframe structure, defined by the coordinator, may be used, in which case two beacons act as its limits and provide synchronization to other devices as well as configuration information. A superframe consists of sixteen equal-length slots, which can be further divided into an active part and an inactive part, during which the coordinator may enter power saving mode, not needing to control its network.Within superframes contention occurs between their limits, and is resolved by CSMA/CA

Data transfers to the coordinator require a beacon synchronization phase, if applicable, followed by CSMA/CA transmission (by means of slots if superframes are in use); acknowledgment is optional. Data transfers from the coordinator usually follow device requests: if beacons are in use, these are used to signal requests; the coordinator acknowledges the request and then sends the data in packets which are acknowledged by the device. The same is done when superframes are not in use, only in this case there are no beacons to keep track of pending messages.