# Novel Extensions to Enhance Scalability and Reliability of the IEEE 802.15.4-DSME Protocol
## 3 Shareable D-DSME Extension
### EnhanceD DSME Allocation Procedure
** The _PAN-Coordinator_ sends the GTS allocation response to the node indicating the _FlowIdentifier_\(f\), the _shGTSId_ (i.e., slot id and superframe id of the assigned _shGTS_ within the multi-superframe), the assigned _shGTSOffset_ and the _shGTSInterval_. Once the response is received, if the allocation was successful, the node requesting the GTS updates its own _macDSMESAB mask_ and its macDSMEACT table, which was modified (compared with the one used in DSME) in order to contain these new data fields. The new GTS assignment is communicated through the beacon to all the other nodes in the network that are compliant with D-DSME. Finally, the node sends a notification message \(M_{not}\) broadcast to all the other nodes, indicating the newly allocated GTSs, in order to mantain compatibility with the nodes compliant with the standard DSME protocol. \(M_{not}\) is sent only if the GTS is allocated to one flow for the first time, while no notification is needed when it is shared multiple times among several flows. This choice is to prevent the nodes that are not compliant with D-DSME from detecting multiple allocation events. The Shareable D-DSME allocation procedure is up to the _PAN-Coordinator_. The nodes requesting _shGTS_ allocation have to wait for a response from the _PAN-Coordinator_, otherwise they cannot use any shGTS. The node that requests a shGTS, after a timeout with no response from the _PAN-Coordinator_, will retransmit the allocation request. During the allocation phase messages can be lost, i.e., the allocation request or the allocation response can be lost. In the first case, as the node requesting the shGTS allocation does not receive any response, it will retransmit the allocation request. Even in the case that the allocation response is lost, the node requesting the shGTS allocation will retransmit the allocation request. In this case the _PAN-Coordinator_ replies to the node with the same allocation response transmitted following the first request. The process will repeat until either a reply (positive or negative) is received by the node or a timeout elapses. Hence, termination is always guaranteed. Conversely, if the _PAN-Coordinator_ replies to a shGTS request and the node is not able to receive the reply or to transmit other requests (e.g., due to a temporary channel unavailability), the shGTS allocation may result in an inconsistent state. In fact, the shGTS is allocated, but the node cannot use it. However, the inconsistent state has a limited duration, as the node that is not able to communicate will request again a shGTS for the same flow after a given sleep interval and the _PAN-Coordinator_ will reply with the same shGTS previously assigned. **Transmission on _shGTSs_. The data in the macDSMEACT table are used by each node to know when it can transmit in the assigned _shGTS_. First, the node determines the current _multi-superframe id_ (_MSFId_). This is done using the index (_SFId_) of the superframe that is transmitted by the DSME coordinator in the beacon (Section 7.4.2.5 in [1]). The _SFId_ specifies the index of the current superframe in a beacon interval. If each multi-superframe contains \(n_{SF}\) superframes, \(MSFId=(SFId\mod n_{SF})\). A node that wants to know if the _shGTS_ with id equal to _shGTSId_ within the current multi-superframe is assigned to a flow \(f\) checks if the following condition is met. \[(MSFId-shGTSOffset)\mod shGTSInterval=0 \tag{4}\]  
If condition 4 is met, then the _shGTS_ with id equal to _shGTSId_ is used to transmit the frames of the flow \(f\).