-
Notifications
You must be signed in to change notification settings - Fork 2.1k
[RFC] Towards an IEEE 802.15.4 MAC layer #15313
Copy link
Copy link
Open
Labels
Area: networkArea: NetworkingArea: NetworkingDiscussion: RFCThe issue/PR is used as a discussion starting point about the item of the issue/PRThe issue/PR is used as a discussion starting point about the item of the issue/PR
Description
Description
I open this issue to specify a roadmap for a standard IEEE 802.15.4 MAC layer implementation.
This is desirable for several reasons:
- The IEEE 802.15.4 MAC is designed for low power devices. This would indeed improve our "radios always listening" situation, since the standard describes several mechanisms for receiving data "only when it's needed".
- Security is part of the standard (authentication, encryption).
- Interoperability with other IEEE 802.15.4 devices (e.g Full MAC devices)
- It can be used to implement other standards on top (e.g 6TiSCH, which runs on top of the TSCH mode of IEEE 802.15.4)
- Device discovery (scanning)
- Support for Full-function devices (FFD) and Reduced-function devices (RFD).
Required steps
Since the standard is retro-compatible, we could focus on implementing "some" parts of the IEEE 802.15.4 2006 standard and keep extending as needed. At some point we should be able to introduce primitives of the 2015 standard and amendments (e.g 2012e, TSCH).
The MAC layer can be implemented using the IEEE 802.15.4 SAP API (see #11324 ). The minimal IEEE 802.15.4 MAC layer would only require to implement the "non-beacon" operation, since it's the one used for 6LowPAN. Besides that, we would need:
- Coordinator roles (PAN coordinator, etc)
- PAN association (joining a coordinator)
- Receive / send data inside a PAN (e.g use short address when possible, etc)
- Scanning (only active mode is required, since it would operate as a beacon-less network), to detect coordinators.
In the mid/long term, some desirable features:
- Indirect Transmission (a coordinator maintains a queue of frames for RFD nodes, and the RFD node polls periodically to check if there are frames for it).
- Security (authentication, encryption) (it already started in Initial implementation of IEEE 802.15.4 security #15150 )
- Beacon-enabled operations ("superframes", Guaranteed Time Slots, etc).
- TSCH mode :)
Architecture
Note the MAC layer is independent of the network stack:
+-------------------------+ +-------------------------+
| | | |
| GNRC Netif | | LWIP |
| | | |
+-------------------------+ +-------------------------+
^ ^
|MCPS/MLME |MCPS/MLME
| |
v v
+------------------------------------------------------------+
| |
| IEEE 802.15.4 MAC |
| |
+------------------------------------------------------------+
^
| SubMAC API
v
+------------------------------------------------------------+
| |
| IEEE 802.15.4 SubMAC |
| |
+------------------------------------------------------------+
^
| Radio Ops/
v Event Notification
+------------------------------------------------------------+
| |
| IEEE 802.15.4 Radio HAL |
| |
+------------------------------------------------------------+
Roadmap
- Implement MCPS-DATA primitive (send/receive data)-
- Implement PAN coordinator and coordinator role
- Implement association mechanism
- Implement Scanning
- TBD
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Area: networkArea: NetworkingArea: NetworkingDiscussion: RFCThe issue/PR is used as a discussion starting point about the item of the issue/PRThe issue/PR is used as a discussion starting point about the item of the issue/PR