802.15.4 is the spec for wireless PAN (Personal Area Network), i.e. Zigbee and 6LowPan.
802.15.4 specifies the PHY and MAC. It’s low power, low range, and low bitrate. Typically for sensors and actuators that are not active all the time.
The PHY does energy detection to check if the channel is free. There are several algorithms available for medium access, mostly used is CSMA-CA.
Payload is encapsulated in the PPDU.
MAC has two types of services: data and management. Field in the beginning indicates which type it is and which optional fields are included. The management is handled by the MLME (Mac subLayer Management Entity). It handles things like choosing channels, beacons and scanning, acknowledgements, ….
There are two types of devices: reduced function (RFD) and full function (FFD). The RFD are always leaf nodes, FFD devices can be coordinator or leaf node. The PAN coordinator creates a network and assign itself a 16-bit PAN ID (allowing multiple networks to coexist). It also assigns itself a short address (16 bit). There is a discovery mechanism using beacons. The beacon says that the coordinator exists and invites other nodes to join. A beacon-enabled PAN beacons at a regular rate, but it’s also possible for a leaf node to send an explicit beacon request (which can save on battery power). Thus there are 3 types of scans: energy detection, passive scan (wait for regular rate beacon), active scan (send beacon request). LQI indicates link quality.
The beacon starts the time controlled by the PAN coordinator. After the beacon there are a number of slots where either devices can send whenever they want (but this has contention) and a period where the timeslots are reserved for a specific device to send (no contention). Since beacon rate is constant, devices can predict when there will be a beacon and wake up just before to receive it.
Note that “promiscuous mode” defined by the standard means that incorrect packets are filtered out, but Linux defines it as all packets, including those with incorrect checksum.
Spec defines MAC management commands.
Scan pauses transmissions and filters for only beacon frames. It switches channels after a specfic time and thus scans all channels. Result is a number of beacon frames with their LQI.
Association starts with association request sent by peer which is acked immediately. Then the coordinator has a specified time to decide if it wants to accept, if yes sends association response.
Disassociation can be started either by coordinator and peer.
Since PAN ID is only 16 bit, there is a chance of conflict. Either coordinator detects this itself because it receives a beacon from another coordinator with the same PAN ID. Also a peer can detect it when it receives a beacon from a coordinator with a different address. It must then send a conflict notification to the coordinator. This starts a procedure to resync.
It is possible that a device looses track of its coordinator. There is a procedure to resync.
Linux has a softmac implementation of mac802154, there are no (upstream) hardMAC drivers yet. Above that there is cfg802154 and nl802154, similar to wlan.
On a single PHY, several subinterfaces can be created: node (= leaf), monitor (= sniffer) and coordinator. The coordinator was added by Miquel. Currently it can send beacons, more functionality to be added.
Frame validation and acknowledgements is typically handled by hardware even with softmac. Acknowledgements must be sent immediately so hard to do in software, and it has to go through filters first to know if it should be acknowledged. Therefore the hardware also has filters.
Before Miquel’s contribution, everything (e.g. PAN ID) had to be configured statically.
For scanning, there’s a scan request in nl802154 with parameters; this is translated by the cfg802154 layer and forwarded to the MAC layer. A background thread is created to receive the beacon requests, check validity and send it to userspace over nl802154.
Beacon interface is similar: nl802154 command. Beacon interval as parameter. If this is 15, no requests are sent instead it only responds to beacon requests.
iwpan tool gives shell access to these commands, cfr.
For processing association requests (as a coordinator), currently all associations are allowed, there’s just a limit on the number of devices that are allowed to connect. This has to be improved.
For associated devices you get a network interface. To actually get sensor data and expose it in the usual way (e.g. iio) there is no infrastructure now, but the idea is to create a greybus for it.