Sending multiple packets per guaranteed time slot in IEEE 802.15.4 DSME: Analysis and evaluation

Coping with bursty traffic is a common yet challenging task in the industrial Internet of Things (IoT). For example, 6LoWPAN is a standard that defines the integration of LoWPAN with IPv6, by fragmenting large IPv6 packets into several smaller MAC‐layer packets. Therefore, it is necessary to envision message delivery mechanisms, which provide support for highly varying traffic. In this paper, we analyze sending multiple packets per guaranteed time slot (GTS) in IEEE 802.15.4 DSME to alleviate traffic during the contention‐access period (CAP) and increase the reliability in scenarios with bursty traffic. The evaluation shows that increasing parameter SO extends the network throughput beyond default operating conditions and also provides overprovisioning beneficial for delivering sporadic messages. A comparison with the transmission of a single packet per GTS demonstrates a reduction of the total number of transmitted CAP messages by 99% while increasing the packet reception ratio by 48% for bursts with 20 packets.


INTRODUCTION
Universal addressability and connectivity of devices are fundamental pillars of the IoT. For example, the Internet Engineering Task Force proposed the 6LoWPAN 1 standard to achieve addressability and interoperability of heterogeneous MAC-layer protocols with common Internet standards. This standard defines the integration of IPv6 into Low-Power Wireless Personal Area Networks (LoWPAN). Such integration is achieved by fragmenting large IPv6 packets into several smaller MAC-layer packets. This means, a short burst of MAC-layer packets is generated for each sent IPv6 packet. In general traffic patterns with bursts are common in IoT applications, they impose stringent requirements on the MAC-layer protocol in terms of reliability and adaptability to time-varying traffic. 1,2 In 2015, the IEEE 802.15.4 standard was extended for applications with such strict reliability demands by new MAC-layer protocols: Deterministic and Synchronous Multi-channel Extension (DSME) and Time-Slotted Channel Hopping (TSCH). Both protocols schedule time and frequency slots, thus eliminating packet collisions due to interferences within the network. We believe that the adaptability of DSME to time-varying traffic and topology changes provides the support needed to realize IoT applications, which experience the above-described dynamic traffic patterns. The management of bursty traffic places a high demand of slot negotiations that needs to be served almost at the same time.
Although the DSME slot (de)allocation process allows reliable data transmissions, vulnerabilities of CSMA/CA affect the slot management. Therefore, it is necessary to envision mechanisms that alleviate CSMA traffic and also provide responsiveness of the network without diminishing its performance.
We conceive two ways to address this congestion problem: Firstly, negotiating multiple GTS in one handshake and secondly, using the entire GTS to send several packets in a single slot. The first option requires far-reaching modifications of the allocation handshake to incorporate information about additional slots to negotiate. Currently, there is no mechanism known that can allocate several slots in bounded time. The second option considerably lowers the load caused by slot allocations since the number of required GTS is significantly reduced. In this paper, we analyze the second option by considering time-varying traffic. This study is made in terms of CSMA traffic, packet reception ratio (PRR), the average number of allocated GTS, latency, and energy consumption. Simulations are performed using OMNET++ 3 and openDSME. 4

DESCRIPTION OF DSME
As depicted in Figure 1, DSME divides time into superframes (SF), each consisting of 16 time slots. The first of these slots is used to transmit beacons containing network and time information while the remaining slots are split into a contention-access period (CAP) with eight and a contention-free period (CFP) with seven slots.  5 Hence, the choice of SO is relevant for the analysis of sending multiple packets per GTS, as it determines not only the maximum number of packets to be delivered per GTS but also implicitly the length of the CAP in the dataframe structure of DSME. GTS (de)allocations follow a 3-way handshake, that is done in a distributed manner on a per-hop basis. The handshake, is performed in the CAP and is therefore prone to contention. 6 As exemplified in Figure 2, three messages, a unicast GTS Request and two broadcasts GTS Response and GTS Notify, are exchanged between nodes A and B respectively. The GTS negotiation guarantees a common "collision-free" selection of the tuple (channel, superframe, GTS number). The collision-free assumption holds as long as neighbors of A and B detect slot inconsistencies by checking their own GTS schedules. A detection of slot inconsistencies triggers the deallocation of a target GTS.
For this work, an open-source implementation of IEEE 802.15.4 DSME, OpenDSME, is used. The Scheduling module is the feature of main interest, because it determines how many and in which combination (channel, superframe, GTS number) slots should be allocated. To this end, openDSME provides the TPS algorithm, a traffic-aware scheduling algorithm, which updates the GTS schedule at the beginning of every MSF based on exponential moving average of the rate of incoming packets. 5

RELATED WORK
An analysis of the influence of parameters SO and MO in DSME was made by F. Kauer. 5 Explicitly, it is stated that a small value of SO, that is, slots with short length, increases throughput for transmission of single small-size packets. Contrary, setting up a larger value of SO improves the lifetime of networks with low traffic, since nodes can turn off their transceivers while packet transmission is no longer required. Another alternative to exploit slots with large length is to send multiple packets per GTS. This option is also discussed by Kauer, but not formally analyzed, because it is considered that incrementing the value of SO to double the number of transmitted packets per GTS, will end up with the same throughput as a single packet transmission mechanism with the original SO and twice the number of GTS. Therefore, only transmissions of a single packet per GTS are considered in Kauer's work.
Vallati et al performed simulations by using the network simulator Cooja to analyze the GTS allocation process. 7 Their work aims to select CSMA/CA parameters that minimize the number of contention access periods to complete the network setup procedure. The DSME implementation used in their analysis delivers four packets per GTS. Results evidence the advantage of sending multiple packets per GTS in contrast to a single packet per GTS.
A proposal for sending multiple packets per time slot has been implemented for wireless body area sensor networks (WBASNs) based on IEEE 802.15.4. 8 In the work, a frame aggregation mechanism is proposed to provide high performance in patient monitoring systems. To this end, traffic pattern analysis and quality of service (QoS) requirements (eg, high reliability, low energy consumption, restricted delay, etc.) are used to determine resources required by sensor nodes in such systems.

THEORETICAL CONSIDERATIONS
Bursty traffic leads to a temporarily increased number of GTS negotiations and thus to increased congestion of the CAP. As a result, a significant number of GTS allocations fail, resulting in larger queues and ultimately packet loss. 9 This can be counteracted by transmitting multiple packets in a single GTS, which reduces the number of required GTS and hence the number of CAP messages for GTS negotiations. For the number of transmissions per GTS, a best-case and a worst-case estimation can be given. According to the IEEE 802.15.4 standard, 6 an acknowledgment (ACK) during a CFP is transmitted at earliest a turnaround time after the last symbol of the data frame is received (best-case). In the worst-case, a receiver should wait for an ACK a maximum waiting time, which amounts to a unit backoff period and a turnaround time. Therefore, the number of transmissions, , per GTS is bounded by where S GTS = 60 ⋅ 2 SO is the number of symbols per GTS, P is the payload of the packet in bytes (2 symbols per byte), and IFS = 40 symbols when P > 18 Bytes and IFS = 12 symbols, otherwise. The number of 34 and 54 symbols include the overhead of the physical layer packets, the payload of the ACK and the minimum and maximum ACK wait duration, respectively. TPS estimates the number of required GTS based on the lower bound obtained from this expression. Table 1 shows that the number of packets per GTS increases exponentially for an increasing SO and a payload of 127 bytes. That is because by enlarging SO, the duration D GTS of a GTS doubles, as given by D GTS = 0.96 ms ⋅ 2 SO . However, this can lead to more than twice as many transmitted packets. For example, two packets can be transmitted for SO = 4, while up to five packets can be transmitted for SO = 5. The reason is that the duration of a frame transmission, including the acknowledgment, does not exactly match the duration of a GTS. The unused time at the end of GTS increases with an increasing SO until it is large enough to transmit an extra packet. Consequently, the potential throughput of the network increases by transmitting multiple packets per GTS and larger values of SO. Since the number of packets per GTS increases exponentially, the number of CAP messages is assumed to decrease exponentially as well, especially because fewer collisions occur and fewer packets have to be retransmitted. On the other hand this can result in larger GTS queues and thus a larger packet delay, since packets can not be transmitted immediately upon arrival. Instead, they are transmitted in big chunks of packets in few GTS. Also the probability of having overprovisioning increases for higher values of SO, because is larger and sending M additional packets could result in the allocation of a new GTS and overprovisioning for at least − M additional packet transmissions. This reduces delays and avoids queue drops because packets are transmitted immediately upon a burst and queued packets can be (re)transmitted faster.

SCENARIO DESCRIPTION
To evaluate the performance of sending multiple packets per GTS in multi-hop networks under bursty traffic, a grid topology with 4 × 4 nodes is considered. Table 2 summarizes the simulation setup. The parameter SO bounds the maximum number of packets that can be sent in a GTS and MO determines the period, D MSF , in which a GTS schedule is updated by TPS (eg, D MSF = 7.8464 seconds for MO = 9). We fixed BO to 9 and thus BI equals 7.8464 seconds. In this evaluation, each node has a MAC queue capacity of 80 packets, which is split in a CAP queue, Q CA , and a GTS queue, Q CF , used to store messages to be sent in CAP and CFP respectively. Transmitting nodes generate packets per burst. The packet generation interval follows a normal distribution with a mean, = 16 seconds, and a SD = 0.5 second. This is, is chosen in a way that it is on average at least twice as long as D MSF for MO = 9, to allow for the allocation and deallocation of GTS. A static shortest path routing is used, in which a bijective pairing is implemented to guarantee all outer nodes of the grid communicate with a unique and fixed chosen partner and the path lengths between communicating nodes is at least 2. Inner nodes act as relays, that is, they receive and forward packets. Therefore, six communication pairs (ie, 6 routes) are active per run: Two routes with path length 3 and 4 with path length 2. A total of 20 runs is conducted and results are shown with a 95% confidence level.

EVALUATION
As predicted in Section 4, simulations yield an exponentially increasing number of transmitted packets per GTS for an increasing SO. However, the actual number of packets transmitted in a GTS can be highly unbalanced, for example, with = 16, SO = 6 and two allocated GTS, about 11 packets are transmitted in the first GTS and 5 in the second, resulting in an average of 8 packets per GTS.
As fewer GTS need to be allocated, fewer CAP messages have to be transmitted for SO ≥ 4 when compared to a single packet transmission per GTS (SO = 3). This is illustrated in Figure 3. The effect is further enhanced by TPS, which deallocates GTS cautiously. For example, only one GTS is required for SO = 6 and = 10 so that there is almost no CAP traffic. It may seem counter-intuitive at first that the number of CAP messages decreases for SO = 3 with an increasing , while it increases for higher values of SO. The reason is that for SO = 3 contention increases with increasing as more nodes try to (de)allocate GTS. Therefore, nodes go into backoff more often and as long as not all required GTS are (de)allocated according to the incoming traffic rates, queues at the MAC layer (ie, Q CA and Q CF ) overflow and the number of GTS handshakes during the CAP decreases, resulting in a lower PRR. On the other hand, SO = 6 performs best for all . For example, in case of = 10, the traffic in the CAP is reduced by 99% in comparison to a single packet transmission per GTS (SO = 3).
The mentioned queue drops are also reflected in the packet reception ratio (PRR) as shown in Figure 4. For transmissions of a single packet per GTS (SO = 3), the PRR decreases exponentially for an increasing to a value of 33.6% at = 40. Contrary, higher values of SO result in a PRR above 80% for ≤ 40, with SO = 6 performing best. That is because fewer GTS are required and it is more likely that all GTS negotiations can be performed and no packets will be dropped due to a full queue. Therefore, it is possible to transmit about 30 packets more per burst while maintaining the same PRR, by choosing SO = 3 instead of SO = 6. Additionally, it should be noted that lost packets are expected for = 40 for any SO, since it exactly matches the capacity of the GTS queue. For < 8 is no packet loss was observed.
As mentioned in Section 4, the packet transmission delay should increase for an increasing SO as packets are delayed and sent in a single slot. This is, however, disproved by Figure 5. Here the delay per hop for SO = 3 is significantly higher than the delay for other values of SO. This is true for two reasons: on the one hand, more GTS have to be allocated for For example, for SO = 6 and = 15, two slots are allocated so that five extra packets can be transmitted. This reduces the length of GTS queue and therefore the packet transmission delay. For = 6, 2 slots with = 5 are allocated for SO = 5 and 1 slot with = 10 is allocated for SO = 6. Although the overprovisioning is four packets in both cases, the D MSF is longer for SO = 6, resulting in a higher expected time until the next allocated GTS and thus in an increased delay. Figure 6 shows the average number of allocated GTS for transmitting nodes for different values of and SO. The larger the SO, the more packets can be sent per GTS and the fewer GTS must be allocated. On the other hand, a too large SO results in an overprovisioning. For example, it can be seen that SO = 5 is optimal for = 4, since SO = 4 requires two more allocated GTS and SO = 6 implies an overprovisioning of 6-7 packets. Moreover, the average number of allocated GTS is higher than expected, for example, for SO = 3 and = 8, one would expect an average of 4 allocated GTS instead of about 5.7 GTS, since the number of required GTS is either 0 or 8. However, TPS keeps one remaining slot per established link, increasing the average number of allocated GTS. For large bursts for SO = 3 with ≥ 32, nodes reach their own slot (de)allocation rate limits given the increasing amount of slots to negotiate per CAP. For the evaluated burst size, this limit is not reached for configurations with SO > 3.
At last, it should be noted that sending multiple packets per GTS is not beneficial for all types of applications. CAPs are longer for larger values of SO, potentially resulting in a considerable fraction of it not being utilized. This idle time can be counterproductive for energy-harvesting devices, since nodes have to stay active during the whole CAP. However, the remaining time in the CAP gives room for sending other types of control messages (eg, link quality indicator) relevant for the management and maintenance of the network. Figure 7 shows the average total energy consumption per node. The energy consumption for a single packet per GTS (SO = 3) is highest because there are more GTS negotiations in the CAP during which the transceiver is active. Additionally, it can be seen that the energy consumption stays constant for SO = 6 until = 16. Here, the nodes need to allocate 2 GTS instead of 1, resulting in a higher energy consumption. For = 1 higher values of SO result in a higher energy consumption because the receiver has to stay active during the whole GTS. Finally, the evaluation assumes that all nodes generate similar amounts of traffic. If the generation rates of individual nodes vary considerably, a lot of time might be wasted during GTS for large SO. In that sense, it is necessary to carefully define the value of SO that optimally fits the traffic demand of the network. Energy consumption during idle time of a GTS can be reduced by the transmitter announcing the end of the communication to the receiver. Then, both communication partners can turn off their transceivers for the remaining part of the current GTS.

CONCLUSION
In this paper, we consider the transmission of multiple packets per GTS to reduce the number of slot allocations and to increase the reactivity of DSME networks under bursty traffic patterns, for example, 6LoWPAN applications. A theoretical estimation is given and the results are verified by simulation. The simulations show that changing SO = 3 to SO = 6 results in a higher PRR in a grid topology with 16 nodes for different burst sizes. It also increases the GTS length and the number of transmittable packets per GTS from 1 to 11 and reduces the number of GTS (de)allocation messages by up to 99%. At the same time, it enlarges the length of the CAPs significantly, leaving CAPs at the end of a MSF unused most of the time. Therefore, finding an algorithm to tune the number of CAPs according to the traffic demand of the network is an essential next step, especially because DSME can currently either use all CAPs or a single CAP per MSF (CAP-reduction).

ACKNOWLEDGMENT
This research is partially supported by the German Academic Exchange Service (DAAD). Open access funding enabled and organized by Projekt DEAL.