IoT(Internet Of Things)

 

 

 

Wireless PAN - IEEE 802.15.4 - Network

 

This page looks at an 802.15.4 network from above the radio. It asks two questions: which kinds of device take part, and how they connect to each other. Both answers shape the layers above the MAC, including the way 6LoWPAN forwards a packet across several hops. The frame formats themselves are on the 802.15.4 MAC and 802.15.4 PHY pages.

Type of Device

There are two types of Devices taking part in 802.15.4 based WPAN Network. One is FFD (Full Function Device) and the other one is RFD (Reduced Function Device).

FFD (Full Function Device) : This type of device support full functionality of 802.15.4 MAC functionality and is able to act both as network coordinator and network end-devices. Working as a coordinator, it can transmit Beacon frames and offer various services like Synchronization, communication, network Join services.

RFD (Reduced Function Device) : This type of device can act as only an end devices and may interact with only a single FFD. Usually this device are equipped with a terminal sensing or actuating components like transducers, light switches, lamps etc.

Let's look at how the two types are mixed in a real network. RFC 4919 expects most devices in a LoWPAN to be RFDs, which are extremely limited. FFDs are present in much smaller numbers. They typically have more resources, and they may run on mains power. So the FFDs do the work that the RFDs cannot do: network coordination, packet forwarding, and the interface to other types of network.

One FFD in each PAN takes the coordinator role, and this role has a practical cost. A device can always use its IEEE 64-bit extended address. It can also receive a 16-bit short address, but only after an association event, because the PAN coordinator function hands those addresses out. RFC 4944 warns that a short address is valid only for the lifetime of that association. If the association expires, or the PAN coordinator fails, the short address can become invalid. The PAN coordinator is therefore a single point of failure for short addressing.

The beacon frames of the FFD paragraph above also come in two modes. In a beacon-enabled network, the coordinator's beacons synchronize the devices, and superframes with a contention-free Guaranteed Time Service become possible. In a nonbeacon-enabled network, data frames use unslotted CSMA/CA. Beacons are still useful there, but for link-layer device discovery during association and disassociation, not for synchronization.

  • Most devices are RFDs : a LoWPAN is mostly small RFDs, with fewer FFDs that have more resources.
  • FFDs carry the network : coordination, packet forwarding and the interface to other networks run on FFDs.
  • An RFD talks to one FFD : it can only be an end device.
  • Short addresses depend on the coordinator : the PAN coordinator hands them out at association, and they last only as long as that association.
  • Beacons have two uses : synchronization in a beacon-enabled network, and device discovery in a nonbeacon-enabled one.

Network Topologies

According to IEEE 802.15.4 4.3 Network topologies, three different types of Network Topoligies are possible with various combinations of FFD and RFDs. These topoligies are Star, Peer to Peer (Mesh) and Tree.

< Star Topology >

 

Star topology: FFDs and RFDs around one PAN coordinator, with every communication flow ending at the PAN coordinator

In the star topology every arrow ends at the PAN coordinator. The other devices do not exchange frames with each other directly, so the PAN coordinator relays all traffic between them. The star holds both FFDs and RFDs, because an RFD needs only one FFD to talk to, and here that FFD is the PAN coordinator.

< Peer-to-Peer Topology >

 

Peer-to-peer topology: four FFDs linked to each other, one of them the PAN coordinator, and a single RFD linked only to the PAN coordinator

In the peer-to-peer topology the FFDs link to each other directly, and two FFDs can reach each other over more than one path. The RFD on the right still has only one link, to the PAN coordinator. This is the RFD restriction from the section above. An RFD talks to a single FFD, so it can only sit at the edge of a mesh.

< Tree >

 

Tree topology: seven clusters, PAN ID 1 to PAN ID 7, each with its own PAN coordinator, with the first PAN coordinator in PAN ID 1 and links joining neighbouring clusters

The tree picture joins several clusters. Each circle is one PAN, with its own PAN ID and its own PAN coordinator, drawn in grey. The first PAN coordinator, drawn in black, sits in PAN ID 1. Inside a cluster the devices hang off each other in branches, and links join each cluster to its neighbours. So a frame from PAN ID 7 to the first PAN coordinator passes through PAN ID 6 and PAN ID 2 on the way.

The three topologies trade simplicity for reach. A star keeps forwarding simple, because only the PAN coordinator forwards, but the network ends where the radio range of the PAN coordinator ends. A peer-to-peer or tree network reaches further by forwarding across several hops. RFC 4919 notes that multi-hop routing in a mesh makes intermediate devices act as packet forwarders at the link layer, and that these are typically FFDs. 6LoWPAN supports this with the mesh header of RFC 4944, which carries the originator and final addresses and a Hops Left counter.

  • A star has one forwarder : every flow goes through the PAN coordinator.
  • A peer-to-peer network has many paths : FFDs link to each other directly, and an RFD stays at the edge.
  • A tree joins clusters : each cluster has its own PAN ID and PAN coordinator, under one first PAN coordinator.
  • Multi-hop topologies put the load on FFDs : the forwarding devices are typically FFDs, and the 6LoWPAN mesh header carries the frame between them.

Reference

The additions to this page are based on the two RFCs below.

[1] RFC 4919 : IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals, section 3 and section 4.2

[2] RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks, section 2, section 3 and section 5.2