- Generated on Fri Dec 20 2024 20:02:11 by
1.9.8
Support for IEEE 802.15.4 Deterministic and Synchronous Multi-channel Extension. More...
Support for IEEE 802.15.4 Deterministic and Synchronous Multi-channel Extension.
The IEEE 802.15.4 standard with its widespread usage in wireless sensor and actuator networks was extended by several techniques that allow reliable data transmission for critical applications, such as industrial plants. This includes the Deterministic and Synchronous Multi-channel Extension (DSME) that allows for distributed assignment of time slots on multiple channels.
RIOT provides DSME support via the open source implementation openDSME.
A PAN coordinator device initializes a DSME superframe structure which consists of a series of superframes that repeat indefinitely. A superframe consists of a Beacon Slot, a Contention Access Period and Contention Free Period.
BS CAP CFP BS +------------------------------------------------------+---- | | |--|--|--|--|--|--| | ... | | |--|--|--|--|--|--| | | | |--|--|--|--|--|--| | ... | | |--|--|--|--|--|--| | +---+--------------------------------+--+--+--+--+--+--+---+ <------------------- Superframe ----------------------->
Each period of the superframe serves a dedicated purpose:
DSME allows to extend the number of GTS resources by combining superframes into a multisuperframe structure. The number of superframes per multisuperframes is configurable. This extend the number of GTS to seven times the number of superframes per multisuperframe.
Joining devices scan for beacons and perform the association procedure with the the (PAN) coordinator. On success, the device is ready to communicate with other devices in the DSME network. To extend the network, coordinator devices can associate to any other coordinator (including the PAN coordinator) and start emitting beacons in a different Beacon Slot offset. Devices can then join the network via the new coordinator. DSME manages beacon scheduling automatically and handles beacon collisions accordingly.
The DSME superframe structure relies on three configuration parameters: Superframe Order (SO), Multisuperframe Order (MO) and Beacon Order (BO). These parameters affect the slot duration (and therefore the superframe duration), the number of superframes per multisuperframe and the beacon interval.
The DSME standard defines the slot duration as slot_duration = aBaseSlotDuration * aSymbolDuration * 2^SO. and the superframe duration as "sf_duration = 16 * slot_duration". aBaseSlotDuration=60 as per standard and aSymbolDuration (us) depends on the underlying PHY (16 for O-QPSK).
The number of superframes per multisuperframe is given by sf_per_msf=2^(MO-SO).
The beacon interval (in number of multisuperframes) is given by msf_per_bi=2^(BO-SO)
For example, an O-QPSK PHY with SO=3, MO=4 and BO=5 renders a slot duration of 7.68 ms, a superframe duration of 122.8 ms, 2 superframes per multisuperframe (msf_duration=245.7 ms) and a beacon interval of 2 multisuperframes (beacon_interval=492 ms).
The slot duration trades off maximum frame length and transmission delay during GTS transmissions. A value equal or higher than 3 allows transmission of 127 bytes frames. Increasing the number of superframes per multisuperframe increases on one hand transmission delay, because the period of a single GTS is the duration of the multisuperframe. On the other hand it decreases energy consumption, because a device transmit less often. Increasing the beacon interval extends the number of coordinators in wireless reach and reduces energy consumption. However, it slows the scanning and joining procedure.
The configuration of SO, MO and BO must be compliant with:
With the purpose of reducing energy consumption and extending the GTS resources even more, the MAC defines a CAP Reduction mode that turns all CAP (except the first one in a multisuperframe) into CFP. This adds 8 GTS per superframe that reduces CAP.
With CAP Reduction on, increasing the number of superframes per multisuperframe improves energy efficiency, because nodes spend less time on CAP. However, note that this renders less CAP time which is required for slot negotiation.
A slot is defined by a superframe ID, a superframe slot and a channel offset. The superframe ID is contained in {0..n-1}, where n is the number of superframes per multisuperframe. The ID of the first superframe (the one aligned with the start of a multisuperframe) is 0.
The superframe slot values depend on the superframe ID.
The channel offset is {0..m-1}, with m the number of channels.
The RIOT implementation uses the DSMEAdaptionLayer wrapper internally (provided by openDSME) to manage scanning/joining and automatic slot allocation. The MAC implementation defines several scheduling strategies, but the default is used (Traffic-aware and Predictive Scheduling). The port introduces an openDSME GNRC Network Interface, that can be used via GNRC communication interface and Network protocol registry.
The following network options (Netopt - Configuration options for network APIs) are used for DSME setup.
Configuration:
Modules | |
| DSME Platform interface implementation. | |
| Implementation of the DSME Platform interface. | |
Files | |
| file | dsme_atomic.h |
| file | dsme_platform.h |
| file | dsme_settings.h |
Data Structures | |
| struct | ieee802154_dsme_alloc_t |
| DSME Allocation descriptor. More... | |
Macros | |
| #define | CONFIG_OPENDSME_GNRC_PKTSNIP_TYPE GNRC_NETTYPE_UNDEF |
| default GNRC Pktsnip type for openDSME packets | |
| #define | CONFIG_OPENDSME_MAX_NEIGHBOURS (20U) |
| maximum number of DSME neighbours | |
| #define | CONFIG_OPENDSME_MAX_LOST_BEACONS (8U) |
| maximum number of lost beacons before assuming the device desynchronized. | |
| #define | CONFIG_OPENDSME_CAP_QUEUE_SIZE (8U) |
| DSME CAP queue size. | |
| #define | CONFIG_OPENDSME_CFP_QUEUE_SIZE (22U) |
| DSME CFP queue size (for GTS transmissions) | |
Functions | |
| int | gnrc_netif_opendsme_create (gnrc_netif_t *netif, char *stack, int stacksize, char priority, const char *name, netdev_t *dev) |
| Creates an openDSME network interface. | |
| #define CONFIG_OPENDSME_CAP_QUEUE_SIZE (8U) |
DSME CAP queue size.
The CAP queue stores frames to be sent during the Contention Access Period using CSMA-CA. Because the transmission delay of CSMA-CA is lower compared to GTS transmissions, small values are preferred to reduce memory requirements.
Definition at line 230 of file opendsme.h.
| #define CONFIG_OPENDSME_CFP_QUEUE_SIZE (22U) |
DSME CFP queue size (for GTS transmissions)
The CFP queue stores frames to be sent during the Contention Free Period using a dedicated GTS. In contrast to CSMA-CA transmissions, GTS transmission take longer as a result of slot schedules. Therefore, the GTS queue should have more capacity than the CAP queue (CONFIG_OPENDSME_CAP_QUEUE_SIZE)
Definition at line 242 of file opendsme.h.
| #define CONFIG_OPENDSME_GNRC_PKTSNIP_TYPE GNRC_NETTYPE_UNDEF |
default GNRC Pktsnip type for openDSME packets
Definition at line 199 of file opendsme.h.
| #define CONFIG_OPENDSME_MAX_LOST_BEACONS (8U) |
maximum number of lost beacons before assuming the device desynchronized.
Sets the maximum number of lost beacons before the MAC triggers a de-association procedure. Higher values are beneficial in noisy environments, because the MAC will keep synchronization despite losing some beacons. However, lower values are better for mobile nodes, because devices may sinchronize faster to a new coordinator.
Definition at line 219 of file opendsme.h.
| #define CONFIG_OPENDSME_MAX_NEIGHBOURS (20U) |
maximum number of DSME neighbours
Definition at line 206 of file opendsme.h.
| int gnrc_netif_opendsme_create | ( | gnrc_netif_t * | netif, |
| char * | stack, | ||
| int | stacksize, | ||
| char | priority, | ||
| const char * | name, | ||
| netdev_t * | dev | ||
| ) |
Creates an openDSME network interface.
| [out] | netif | The interface. May not be NULL. |
| [in] | stack | The stack for the network interface's thread. |
| [in] | stacksize | Size of stack. |
| [in] | priority | Priority for the network interface's thread. |
| [in] | name | Name for the network interface. May be NULL. |
| [in] | dev | Device for the interface |
1.9.8