KR102537175B1 - Deterministic and synchronous multichannel extension multi-superframe slot scheduling method for allocating guaranteed time slot by utilizing information sharing between nodes - Google Patents

Abstract

A node and system based on the TaCFPext protocol that allocates an extended guaranteed time slot (extGTS) within at least one Contention Access Period (CAP) based on a request, response, and notification between a pair of nodes are disclosed.

Description

DSME multi-superframe slot scheduling method for allocating GTS by utilizing information sharing between nodes

The present disclosure relates to a DSME multi-superframe slot scheduling method including an allocation procedure for exchanging requests, responses, and notifications between nodes in order to allocate a guaranteed time slot (GTS) within a contention access period (CAP).

The IEEE 802.15.4-2015 standard is widely used in industrial wireless sensor networks (IWSN) by providing a Deterministic and Synchronous Multichannel Extension (DSME) and Time-Slotted Channel Hopping (TSCH) Medium Access Control (MAC) scheme.

The IEEE 802.15.4-2015 standard aims to ensure deterministic delay and high reliability performance using multiple channels and scheduled contention-free transmission.

In the DSME network, nodes perform data communication based on a multi-superframe structure. 3 shows an example of a DSME multi-super frame structure. The coordinator node periodically transmits an enhanced beacon (EB) for network synchronization, and the time between two consecutive EBs transmitted by the same coordinator node is referred to as a beacon interval (BI). BI consists of several multi-superframes, and each multi-superframe includes a plurality of superframes. Each super frame is divided into 16 slots numbered 0 to 15 and consists of a beacon frame, a CAP, and a CFP. In a beacon frame (i.e., slot 0), the coordinator node transmits EB. In a CAP starting along the beacon frame and ending before slot 9, nodes transmit aperiodic traffic and control packets using CSMA/CA. In CFP (e.g. slots 9-15), each slot is used as a GTS that is exclusively assigned to a particular sender-receiver pair. In GTS, nodes transmit periodic traffic using Time Division Multiple Access (TDMA). The DSME multi-super frame structure is defined by three configurable MAC parameters, macSuperframeOrder (SO), macMultisuperframeOrder (MO) and macBeaconOrder (BO), which are selected so that 0≤SO≤MO≤BO≤14 and determine the following. Relevant values:

-Number of multi-superframes in a BI: 2 ^{( BO - MO )}

- Number of superframes in a multi-superframe: 2 ^{( MO - SO )}

2 ^SO symbols- Superframe duration (SD): aBaseSuperframeDuration

2 ^SO symbols

2 ^MO symbols - Multi-superframe duration (MD): aBaseSuperframeDuration

2 ^MO symbols

2 ^BO symbols- Beacon interval (BI): aBaseSuperframeDuration

2 ^BO symbols

Here, aBaseSuperframeDuration is a constant value of 960 symbols. DSMEs can also use CAP reduction options. 4 shows an example of a DSME multi-super frame structure in which the CAP reduction option is activated. As shown in FIG. 4, when the CAP reduction option is activated, only the first superframe of each multi-superframe includes a CAP, and other superframes are used as CFPs including 15 GTSs.

The IEEE 802.15.4 standard defines two channel distribution methods for DSME networks: channel hopping and channel adaptation. In channel hopping, the assigned GTS hops through a series of predefined frequency channels (i.e., a hopping sequence) to smooth out the effects of external interference. In channel adaptation, a sender node assigns a GTS on a single frequency channel or another frequency channel to a receiver node based on its knowledge of the current link quality. After that, if the link quality of the allocated GTS deteriorates, it is recommended to release the allocation of the existing GTS and allocate a new GTS to a frequency channel having better link quality. In this disclosure, channel hopping is considered as a basic channel distribution method. This is because, in general, the basic channel distribution method can provide higher reliability than channel adaptation due to its robustness against external interference.

In channel hopping, the hopping sequence is the same for all nodes, but each node starts hopping at a different channel frequency. In particular, the channel frequency at which a node starts hopping is determined by the node's channel offset. A channel offset is chosen when a node joins the network, and neighboring nodes do not have the same channel offset. Then, when two nodes want to communicate via GTS, the sender and receiver nodes use the channel frequency determined by the channel offset of the receiver node. In particular, the channel frequency used during GTS is derived as follows.

Here, macHoppingSequenceList represents a hopping sequence, and macHoppingSequenceList[m] represents the m-th channel frequency number of macHoppingSequenceList. i is the slot index of CFP, j is the SD index meaning the index of the super frame in BI, l is the slot number of CFP, macChannelOffset is the channel offset of the receiver node, macPanCoordinatorBsn is the sequence number of EB sent by the PAN coordinator, and macHoppingSequenceLength is is the length of the hopping sequence. 5 shows an example of channel scheduling in channel hopping. In FIG. 5, the hopping sequence is [1, 2, 3, 4, 5, 6, 7] and two nodes use 1 and 3 as channel offsets, respectively. Node 1 using channel offset 1 starts hopping at channel frequency 1. The node using channel offset 3 (Node 2) starts hopping at channel frequency 3.

To allocate and manage GTS, nodes in the DSME network maintain two data attributes: Slot Allocation Bitmap (SAB) and Allocation Counter Table (ACT). The SAB is a bitmap that stores the state of the GTS in multiple superframes assigned to a node and its 1-hop neighbors. Figure 6 shows the SAB bitmap format in channel hopping. The SAB includes as many SAB subblocks as the number of superframes in the multi-superframe. One SAB subblock consists of 7 bits when the CAP reduction option is disabled and 15 bits when enabled. Each bit in the SAB subblock indicates whether one slot of the CFP is already used as a GTS (i.e. set to 1) or available (i.e. set to 0). Meanwhile, the ACT is a data table including information for managing the allocated GTS, such as super frame ID, slot ID, channel ID, direction, address, and idle counter. The super frame ID is an index of a super frame to which a GTS is allocated in multi super frames. Slot ID is the index of the slot used by GTS in CFP. Channel ID is the channel offset of the receiver node. The direction specifies whether the node is a sender (ie TX) or a receiver (ie RX). The address specifies the sender's address if the direction is RX and the recipient's address if the direction is TX. The idle counter counts the number of idle multi-superframes since the last use of GTS.

7 shows a GTS allocation procedure in which Node B transmits a DSME GTS Request command to Node C to request GTS allocation. The DSME GTS request command specifies the command type (i.e. allocation), number of GTS required, preferred super frame, preferred slot and SAB subblock, etc. Upon receiving the DSME GTS request command, Node C compares allocation information (ie, SAB) with the received SAB subblock of the DSME GTS request command. Then, Node C reserves the GTS and broadcasts a DSME GTS Response command for granting the GTS allocation. The DSME GTS response command contains the command type, request result (i.e. acknowledgment), sender node address, receiver node's channel offset, and a SAB subblock indicating the newly allocated GTS. Upon receiving the DSME GTS response command, Node B updates the SAB and ACT using the SAB subblock included in the received DSME GTS response command, and then broadcasts the DSME GTS Notify command. The DSME GTS notification command contains the same information as the DSME GTS response except for the sender's address. The address of the DSME GTS notification indicates the address of the recipient node. Upon receiving the DSME GTS notification command, Node C updates SAB and ACT. Meanwhile, Nodes A and D, which are 1-hop neighbor nodes of Node B or Node C, eavesdrop on the DSME GTS response and DSME GTS notification command, respectively. The SAB subblock of the instruction is then compared to the ACT. Update the SAB if the newly assigned GTS does not conflict with the existing GTS. Otherwise, a DSME Duplicated Allocation Notification command is sent to either the sender node or the receiver node to notify that the newly allocated GTS is invalid and should be canceled. Similarly, the GTS deallocation procedure is performed by exchanging DSME GTS request, DSME GTS response, and DSME GTS notification commands. The GTS deallocation procedure is initiated by both the sender node and the receiver node when the allocated GTS expires. Expiration of the GTS is detected by checking the idle counter in the ACT. The sender node increments the idle counter by 1 when no ACK frame is received from the GTS. The receiver node increments the idle counter by one if no data frame is received in the GTS. The sender or receiver node confirms that the GTS has expired when the idle counter is greater than macDsmeGtsExpirationTime, which corresponds to the default value of 7.

DSME and TSCH have advantages in different traffic situations. In particular, DSME provides high scalability by supporting slot scheduling in the CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) method in the CAP (Contention Access Period) section, so it is robust even under dynamic traffic conditions. On the other hand, TSCH is suitable for static traffic conditions because much of the slot scheduling remains in the upper layer, i.e. IETF 6TiSCH. Therefore, DSME can be a promising MAC solution to meet the traffic adaptability requirements of IWSN.

However, DSME can suffer from inefficiency in the highly variable traffic load environment of IWSN. DSME uses a multiple superframe structure composed of multiple superframes, and each superframe is divided into a fixed CAP ratio and a CFP (Contention Free Period) determined by several MAC parameters. In CAP, nodes exchange control packets to allocate guaranteed time slots (GTS) using contention-based CSMA/CA. Then, in CFP, nodes transmit data packets using the assigned GTS. When the traffic load is high, if the CFP of the current multi-superframe does not have space to allocate a new GTS, the node must delay or drop data packets that cannot be sent to the next multi-superframe. Also, since the remaining CAPs are not used, bandwidth is wasted. The DSME may activate the CAP reduction option, which allows nodes to allocate additional GTSs by changing the CAPs of superframes other than the first of the multi-superframes to CFPs. However, these CAP reduction options must be activated at network startup and cannot be deactivated again even if the traffic load decreases again. Consequently, slot scheduling for new data packets is hampered due to lack of CAPs.

Therefore, many studies have been conducted to improve the adaptability of DSME networks to traffic load changes. Kauer et al (2016) proposed a distributed slot scheduling method for wireless multi-hop DSME. Nodes predict in advance the amount of traffic to be injected into each communication link and allocate or de-allocate the GTS accordingly. Lee et al (2016) proposed a slot scheduling method for node movement in DSME. Here, the nodes periodically transmit slot allocation information such as the allocated GTS list and the number of packets to be transmitted to the coordinator. The coordinator uses the information to reallocate the GTS allocated to the moved node to another node. Battaglia et al (2020) improved the usefulness of CFP by proposing a sharable GTS concept for DSME networks that can be redundantly allocated to one or more periodic traffics with periods longer than the length of multi-superframes. However, these studies generally use the fixed multi-superframe structure of the DSME standard, making it difficult to adapt to very diverse traffic loads.

In order to solve this problem, studies considering the dynamic adjustment of the DSME multi-superframe structure according to traffic load changes have been conducted. Sahoo et al (2017) proposed a dynamic GTS allocation method to reduce retransmission delay in DSME networks. Here, the coordinator recognizes whether each transmission of the GTS has succeeded or failed in the CFP of one super frame through a beacon including a group acknowledgment (ACK). Then, at the beginning of the next superframe, slots of the CAP are used as many as the number of failed transmissions for retransmission. Kurunathan et al (2019) proposed a dynamic multi-super frame tuning method to provide better quality of service (QoS) in DSME networks. Here, the coordinator maintains network information such as node list and GTS allocation status. The coordinator uses this information to calculate the number of GTSs required for the network, switches the CAP reduction option, and adjusts the length of multiple superframes. However, these studies assume that nodes continuously transmit the same amount of traffic. This approach has a disadvantage in that the multi-superframe structure cannot be changed even if the amount of traffic transmitted by each node changes.

The present disclosure provides a node or system based on the TaCFPext protocol, which provides a node information sharing method for dynamically allocating extGTS to at least one CAP in addition to CFP.

The present disclosure provides a node or system that dynamically allocates and manages extGTS according to traffic load by providing an extGTS allocation procedure and a de-allocation procedure, respectively.

According to an embodiment of the present disclosure, in a slot scheduling method of a system configured with a Deterministic and Synchronous Multichannel Extension (DSME) network, a sender node, in at least one Contention Access Period (CAP) included in multiple superframes of the DSME network Transmitting a request for allocating an extended guaranteed time slot (extGTS) to a recipient node, selecting, by the recipient node, at least one slot of the CAP for allocating the extGTS according to the request, the recipient node (a) transmitting a response including information on the selected slot to the sender node, and broadcasting, by the sender node, a notification including information on extGTS allocated to the selected slot.

In the transmitting of the request, the sender node transmits the request including information on the number of extGTS required, a super frame, a slot, and a traffic-adaptive slot allocation bitmap (taSAB) subblock of the CAP to the receiver node. transmission, and the taSAB subblock may include extGTS allocation information for channel offsets and slots in a super frame including the CAP in the form of a matrix.

In this case, in the step of selecting the slot, the receiver node compares the taSAB subblock included in the request with the taSAB subblock of the receiver node for the CAP, and determines the usability of the slot included in the request. and, if a slot included in the request is identified as unavailable, select at least one available slot different from the slot included in the request.

The slot scheduling method of the system may further include updating, by the sender node, taSAB and a traffic-adaptive allocation counter table (taACT) of the sender node based on a response received from the receiver node. In this case, the taACT includes information on a super frame ID, a slot ID, and a channel offset related to the allocated extGTS, and the step of broadcasting the notification includes broadcasting the notification related to the updated taSAB and taACT. can be cast.

Meanwhile, the channel frequency (C_ext) of the extGTS can be derived through the following formula.

,

,

Here, the HoppingSequenceList_ext[m] represents the m-th channel frequency of the modified hopping sequence for extGTS, i is the slot index of extCFP, and j is the SD (Superframe Duration) index representing the superframe index in BI (Beacon Interval). , l is the number of slots in extCFP, macChannelOffset is the channel offset of the receiver node, macPanCoordinatorBsn is the sequence number of the Enhanced Beacon (EB) sent by the Personal Area Network (PAN) coordinator, and macHoppingSequenceLength is the hopping sequence length of the existing hopping sequence.

The slot scheduling method of the system may include designating, by a node 1-hop adjacent to the sender node, the CAP as a Listen Only Period (LOP) based on the broadcast notification; The method may further include updating taSAB of the 1-hop neighboring node based on the designated LOP.

Meanwhile, in the slot scheduling method of the system, the sender node increases an idle counter in taACT by a predetermined value whenever an ACK frame is not received. If the idle counter is greater than or equal to a threshold value, the sender node The method may further include transmitting a request for de-allocation of the extGTS to the receiver node.

In this case, the first threshold of the idle counter corresponding to the deallocation condition of the extGTS allocated in the CAP is the idle counter corresponding to the deallocation condition of the GTS (Guaranteed Time Slot) allocated in the CFP (Contention Free Period) may be smaller than the second threshold of

According to an embodiment of the present disclosure, in a slot scheduling method of a node included in a Deterministic and Synchronous Multichannel Extension (DSME) network, the node includes at least one Contention Access Period (CAP) included in multiple superframes of the DSME network Transmitting a request for allocating an extended guaranteed time slot (extGTS) to another node, receiving a response including information on a slot selected according to the request from the receiver node, the node, the selected and broadcasting a notification including information about the extGTS assigned to the slot.

The slot scheduling method of a node/system according to the present disclosure is meaningful in that it provides a specific communication method between nodes for allocating extGTS to a CAP.

A system utilizing TaCFPext according to the present disclosure can effectively manage traffic load by flexibly utilizing extGTS, which has a lighter release condition than GTS generally allocated to CFP.

1 is a diagram for explaining the configuration of a system according to an embodiment of the present disclosure;
2 is a flowchart for explaining a slot scheduling method of a system/node according to an embodiment of the present disclosure;
3 to 7 are diagrams for explaining a multi-superframe configuration or operation of an existing DSME network;
8 is a diagram for explaining the overall operation of a system according to an embodiment of the present disclosure;
9 is a diagram for explaining the configuration of taSAB used for slot scheduling according to an embodiment of the present disclosure;
10 is a diagram for explaining a configuration of a Changeable CAP Bitmap (CCB) used for slot scheduling according to an embodiment of the present disclosure;
11 is a diagram for illustratively explaining the distribution of 40 nodes included in a network according to an embodiment of the present disclosure, and
12 to 23 are diagrams for explaining the effect of the TaCFPext protocol when compared to existing DSME schemes.

Prior to a detailed description of the present disclosure, the method of describing the present specification and drawings will be described.

First, terms used in the present specification and claims are general terms in consideration of functions in various embodiments of the present disclosure. However, these terms may vary depending on the intention of a technician working in the art, legal or technical interpretation, and the emergence of new technologies. In addition, some terms are arbitrarily selected by the applicant. These terms may be interpreted as the meanings defined in this specification, and if there is no specific term definition, they may be interpreted based on the overall content of this specification and common technical knowledge in the art.

In addition, the same reference numerals or numerals in each drawing attached to this specification indicate parts or components that perform substantially the same function. For convenience of description and understanding, the same reference numerals or symbols are used in different embodiments. That is, even if all components having the same reference numerals are shown in a plurality of drawings, the plurality of drawings do not mean one embodiment.

Also, in the present specification and claims, terms including ordinal numbers such as “first” and “second” may be used to distinguish between elements. These ordinal numbers are used to distinguish the same or similar components from each other, and the meaning of the term should not be construed as being limited due to the use of these ordinal numbers. For example, the order of use or arrangement of elements associated with such ordinal numbers should not be limited by the number. If necessary, each ordinal number may be used interchangeably.

In this specification, singular expressions include plural expressions unless the context clearly dictates otherwise. In this application, the terms "comprise" or "consist of" are intended to designate that there is a feature, number, step, operation, component, part, or combination thereof described in the specification, but one or more other It should be understood that the presence or addition of features, numbers, steps, operations, components, parts, or combinations thereof is not precluded.

In the embodiments of the present disclosure, terms such as “module,” “unit,” and “part” are terms used to refer to components that perform at least one function or operation, and these components are hardware or software. It may be implemented or implemented as a combination of hardware and software. In addition, a plurality of "modules", "units", "parts", etc. are integrated into at least one module or chip, except for cases where each of them needs to be implemented with separate specific hardware, so that at least one processor can be implemented as

In addition, in an embodiment of the present disclosure, when a part is said to be connected to another part, this includes not only a direct connection but also an indirect connection through another medium. In addition, the meaning that a certain part includes a certain component means that it may further include other components without excluding other components unless otherwise stated.

This disclosure describes the TaCFPext protocol, and nodes and systems using TaCFPext, that enable each node to adaptively reserve time and frequency slots in a distributed manner in response to constantly changing traffic loads.

Here, the system may include a plurality of nodes capable of directly/indirectly communicating with each other. For example, referring to FIG. 1 , a system may include a plurality of nodes selectively connected through a DSME network 10 .

Each node may correspond to a sensor device, a control device, a monitoring device, a relay device, a management device, a server device, a customer device, and the like, and may also correspond to various types of electronic devices constituting an industrial wireless sensor network. Meanwhile, a node may correspond to a virtual entity defined as a virtual network point.

In TaCFPext, nodes temporarily use CAPs as extCFPs when they cannot allocate any more GTSs to exchange data packets within the CFPs of the current multi-superframe due to high traffic load conditions. Then, when the traffic load decreases again, extCFP returns to the CAP. 8 shows the overall operation of each node according to TaCFPext. If a node determines that there is not enough space to allocate a GTS in the CFP of the current multi-super frame, the TaCFPext operation is activated to extend the CFP. In (a) of FIG. 8, Node B transmits a DSME GTS request command to attempt GTS assignment to communicate with Node C, but fails three consecutive times. Node B assumes that there is no space to allocate GTS in the CFP of the current multi-super frame and executes TaCFPext consisting of two procedures: 1) selecting a changeable CAP and 2) allocating extGTS. In the mutable CAP selection procedure, the node checks if extCFP must be used, and if so, selects a CAP to change to extCFP in multiple superframes. If there are already extCFPs in the current multi-super frame with enough slots for the new extGTS, the node proceeds to the next step to allocate them. Otherwise, the node selects one of the CAPs other than the CAP of the first superframe and uses it as extCFP. The CAP of the first super frame is not used with extCFP to ensure a common CAP for nodes in the DSME network. In (b) of FIG. 8, Node B first checks whether there is an extCFP with enough slots for a new extGTS in the current multi-superframe, then selects the CAP of the second superframe as a configurable CAP and allocates the extGTS through the extGTS allocation procedure. can do.

In the extGTS allocation procedure, a node sends a DSME extGTS Request (Request), a DSME extGTS Response (DSME extGTS Response) and a DSME extGTS Notification (including a traffic-adaptive SAB (taSAB) subblock to express allocation information in CAP and extCFP). Notify) commands are sequentially exchanged, and extGTS is allocated from the selected 'changeable CAP'. In (c) of FIG. 8, Node B transmits a DSME extGTS request command to Node C to initiate an extGTS allocation procedure. The DSME extGTS request command includes a taSAB subblock for expressing CAP allocation information in the second super frame. Upon receiving the DSME extGTS request command, Node C compares the allocation information and taSAB subblock in the DSME extGTS request command. After verifying that the CAPs of the second super frame of both nodes have enough slots for the new extGTS, Node C determines the extGTS allocation and responds with a DSME extGTS response command containing a taSAB subblock indicating the new extGTS. Upon receiving the DSME extGTS response command, Node B updates taSAB and taACT (traffic-adaptive ATC) to store the new extGTS, and then sends a DSME extGTS notification command to Node C. The DSME extGTS notify command includes the same taSAB subblock as the DSME extGTS response command indicating the new extGTS. Upon receiving the DSME extGTS notify command, Node C updates taSAB and taACT. Meanwhile, Nodes A and D overhear the DSME extGTS response and DSME extGTS notify command and update taSAB to keep the allocation information of CAP and extCFP up-to-date. After updating taACT and taSAB, Nodes A, B, C and D use the updated taACT and taSAB to update the multi-super frame structure.

Nodes in a DSME network may have different multi-superframe structures as a result of TaCFPext operation. When a pair of nodes use the CAP of a specific super frame as extCFP, the corresponding 1-hop neighbor node designates the CAP as a LOP (Listen Only Period) during extCFP. ExtGTS allocated from extCFP hops all multi-channels except the control channel. In the LOP, nodes (i.e., Node A and Node D in FIG. 8(d)) simply listen to the control channel to collide-free (i.e., Node B and Node C in FIG. 8(d)) within the extCFP Check contention-free) transmission. And, upon receiving a DSME extGTS response or a DSME extGTS notification command from another node, the corresponding node updates its own allocation information in multiple superframes.

As mentioned earlier, TaCFPext currently starts up under high traffic load conditions where there is no room to allocate additional GTS to CFPs in multiple superframes. Therefore, nodes in the DSME network must first be aware of this high traffic load condition in a decentralized manner before TaCFPext operation can be initiated.

As an example, when a pair of nodes allocate a GTS by exchanging DSME GTS request and DSME GTS response commands, SABs are compared to check each other's CFP availability.

Specifically, a sender node (ex. node B) may transmit a request for allocating a guaranteed time slot (GTS) within a contention free period (CFP) to a receiver node. This request may include information on command type (allocation), required number of GTSs, preferred super frame, preferred slot, and SAB subblock.

In this case, the recipient node receiving the request may compare the SAB subblock included in the request with the SAB subblock of the recipient node to determine whether the GTS can be assigned to the (preferred) CFP. If the number of slots to which a new GTS is to be allocated is not secured, such as information on another GTS already allocated on the SAB subblock (preferred super frame) of the receiver node, the receiver node Can be identified as non-allocable.

In addition, the receiver node (eg node C) may transmit a response to the sender node regarding whether or not the GTS is allocated to the CFP (allocation availability).

If a response indicating that allocation is possible is received, the sender node may allocate the GTS within the CFP by transmitting a DSME GTS Notify to the receiver node, similar to the existing DSME.

On the other hand, if a response indicating that allocation is not possible is received, the sender node may attempt (transmit a request) GTS allocation for a CFP different from the CFP in which the previous GTS allocation failed.

Specifically, if the number of SAB subblocks included in the DSME GTS request command is less than the number of superframes in multiple superframes, a pair of nodes (sender node, receiver node) must exchange commands several times to compare the entire CFP. That is, assuming that the number of SAB subblocks included in the DSME GTS request command is k, in order to compare all CFPs in multiple super frames, the DSME GTS request command and the DSME GTS response command are calculated by calculating the number of super frames in the multi super frames. The value divided by k must be sequentially exchanged. Therefore, if a node fails to allocate GTS 2 ^(MO-SO) /k times consecutively, it determines that the current DSME network is in a high traffic load state and starts TaCFPext operation.

When the TaCFPext operation starts, a series of processes for allocating an extended GTS (extGTS) in at least one CAP may be performed.

First, a node may select at least one CAP (Contention Access Period) within multiple superframes of the DSME network.

Specifically, when TaCFPext starts, the node determines which CAP to change to extCFP in multiple superframes by performing a changeable CAP selection procedure. If there is already an extCFP with enough slots for the new extGTS, the node does not select an additional CAP and uses the existing extCFP to allocate the extGTS. However, otherwise, the node must select some CAPs or LOPs from multiple superframes to change to extCFP. Among CAPs and LOPs, a node must first select a LOP to minimize changes in use of its 1-hop neighbors' CAPs. A node can select an LOP with enough slots for a new extGTS by referring to the bitmap storing the extGTS assigned to the node and its 1-hop neighbors. If the number of available slots within extCFP and LOP is insufficient, the node selects a CAP (except for the CAP in the first superframe) that changes to extCFP in the next multi-superframe. TaCFPext guarantees a common CAP for nodes in the DSME network by excluding the CAP of the first superframe from the mutable CAP selection procedure.

For the mutable CAP selection procedure, nodes use two new attributes: Traffic Adaptive SAB (taSAB) and Traffic Adaptive ACT (taACT). The former is a two-dimensional bitmap that stores the state of extGTS in multiple superframes allocated to itself and its 1-hop neighbors, and the latter is a data structure that stores information for managing the allocated extGTS. 9 shows the bitmap format of taSAB. In FIG. 9, the contiguous taSAB sub-blocks represented by a two-dimensional bitmap in which columns and rows represent channel offsets and slots, respectively, describe extGTS allocation information for all channel offsets in extCFP. This two-dimensional structure of taSAB allows nodes to be aware of all extGTS assigned to their 1-hop neighbors, converting CAPs to LOPs in a distributed manner. In the channel hopping of the existing DSME, the SAB subblock is represented as a one-dimensional bitmap containing only the GTS allocation information for one channel offset used by the node, whereas taACT maintains the same field structure as the ACT of the existing DSME, so that the node You can manage extGTS from within extCFP.

The detailed operation of mutable CAP selection is given in Algorithm 1.

Algorithm 1 includes the two attributes described above (i.e. taACT, taSAB) and three variables (i.e. channelOffset , NumberOfChannels and numSlots) are included. The table item of taACT includes extGTS information such as super frame ID of multi-super frame, slot ID of super frame, and channel offset. The super frame ID of the table entry is expressed using the array of Equation 2 below.

sid _i is the superframe ID of the ith table entry in taACT, and N corresponds to the number of extGTS allocated to the node. taSAB is expressed as a three-dimensional array having [superframe ID] [slot ID] [channel offset] as an element. channelOffset, NumberOfChannels, and numSlots represent the channel offset of the extGTS to be allocated, the number of physical channels supported by the IEEE 802.15.4 physical (PHY) layer, and the number of slots required to allocate a new extGTS, respectively. The algorithm also uses four additional attributes (eg extCFP , LOP , CAP , conArray , and ocpSC ) to track the state of the CAP across multiple superframes. extCFP , LOP , and CAP are data structures that store indexes of superframes to which extCFP, LOP, and CAP belong, respectively. conArray is a concatenated array of extCFP , LOPs and CAPs used to select mutable CAPs. ocpSC is a vector of occupied slot counters, with elements 2 ^(MO-SO) representing the number of slots occupied by extGTS within extCFP and LOP. temp_sid and slotCnt are variables for checking the super frame ID stored in conArray and calculating the number of slots available in the changeable CAP, respectively. Finally, SID is a return array containing the mutable CAP's super frame ID.

After ocpSC , extCFP , LOP , conArray , CAP , SID , slotCnt , and temp_sid are initialized, the node interrogates taACT and taSAB successively to determine the superframe ID of an existing extCFP, LOP, or CAP, and/or within extCFP and LOP. Check available slots. First, the node checks the super frame ID of the table entry in taACT (ie taACT.sid ) to determine the super frame to which the existing extCFP belongs, and adds it to extCFP if it is not an element of extCFP . Similarly, the node examines the bits of taSAB denoted by taSAB[i][j][k] with three indices (i.e. super frame ID i, slot ID j, channel offset k), and the super frame to which the existing LOP belongs. , and check the occupied slots within extCFP and LOP. If the specific bit of taSAB is 1, the node checks whether the super frame ID i is an element of extCFP and LOP. If the super frame ID i is not an element of extCFP, the corresponding slot can be inferred to be extGTS assigned to a 1-hop neighbor. Therefore, the node adds the super frame ID i to the LOP if it is not an element of the LOP . The node then checks whether the channel offset k is equal to the channel offset of the extGTS to be allocated. If so, the corresponding slot can be inferred to be an existing extGTS that collides with the new extGTS to be allocated. Therefore, the node increases the value of ocpSC[i] by 1 to calculate the number of slots occupied in extCFP or LOP belonging to the i-th super-frame in multi-super-frames. After examining taACT and taSAB, the node adds superframe IDs not included in LOP and extCFP to CAP except for the superframe ID of the first superframe.

After updating the CAP, the three properties extCFP , LOP and CAP are merged and stored in conArray . The node then selects a mutable CAP by considering the number of occupied slots in each extCFP, LOP or CAP. In conArray , super frame IDs of extCFP, LOP, and CAP are sequentially arranged. Using this conArray , the node first stores extCFP's superframe ID in temp_sid and then checks the number of occupied slots in extCFP (i.e. ocpSC [temp_sid]). If the number of occupied slots in extCFP is less than 8, it means that extCFP has free slots. Therefore, in this case, the node adds the super frame ID of extCFP to SID and the number of slots available in extCFP (ie, 8- ocpSC [temp_sid]) to slotCnt. If the number of available slots in extCFP is less than the required number of slots (i.e. numSlots), the super frame ID of the next extCFP in conArray is added to the SID in the same way. Then, if the number of free slots in all extCFP is less than numSlots, the super frame ID of the LOP in conArray is added to the SID. Similarly, if the number of slots available for all extCFPs and LOPs is less than numSlots, the super frame ID of the CAP in conArray is added to the SID . After updating the SID , if slotCnt is greater than numSlots, the SID is returned to the mutable CAP. Otherwise, an empty array is returned since there are not enough slots available to allocate the required extGTS.

A node may change the selected CAP to an extended Contention Free Period (extCFP). If the existing extCFP is selected, this process can be omitted. Alternatively, if an existing LOP is selected, the LOP may be changed to extCFP.

As such, when the changeable CAP selection procedure is completed, the node may allocate at least one extGTS in the changed extCFP.

Specifically, a pair of nodes (ie, sender and receiver) perform an extGTS allocation procedure through exchange of three commands (ie, DSME extGTS request, DSME extGTS response, and DSME extGTS notify).

In this regard, FIG. 2 is a flowchart illustrating a process of allocating an extGTS by a pair of nodes.

Referring to FIG. 2, a sender node (eg node B) may transmit a request for allocating extGTS to a CAP to a receiver node (S210).

Specifically, to initiate the extGTS allocation, the sender node transmits a DSME extGTS request containing the required number of GTSs, preferred superframes, preferred slots, and taSAB subblocks of the configurable CAP.

Then, the receiver node may select at least one slot of the CAP for allocating the extGTS according to the request (S220).

Specifically, upon receiving a DSME extGTS request, the receiver (receiver node) compares the taSAB subblock of the received DSME extGTS request with the corresponding taSAB and, if the preferred slot is available, selects a slot adjacent to the preferred slot for the new extGTS. . If not, another available slot is selected for the new extGTS.

Then, the receiver node may transmit a response including information on the selected slot to the sender node (S230).

Specifically, the receiver responds with a DSME extGTS response containing a taSAB subblock indicating the new extGTS.

And, the sender node may broadcast a notification including information about the extGTS allocated to the selected slot (S240).

Specifically, upon receiving the DSME extGTS response, the sender updates taSAB and taACT and broadcasts a DSME extGTS notification indicating the new extGTS.

Upon receiving the DSME extGTS notify command, the receiver updates taSAB and taACT. The sender's and receiver's 1-hop neighbors overhear the DSME extGTS response or DSME extGTS announcement and update taSAB.

Similarly, extGTS deallocation is performed by exchanging these three commands. The receiver and sender increment the table entry counter value in taACT by 1 each time no data frame or ACK frame is received during extGTS. If the value of this counter is greater than macDsmeGtsExpirationTime/2, the extGTS is considered expired and the sender or receiver initiates the extGTS deallocation procedure. In the existing DSME, the GTS expired when the counter value of the ACT table entry was greater than macDsmeGtsExpirationTime. That is, the sender or receiver according to the present disclosure may deallocate the extGTS prior to the GTS of the CFP when the traffic load decreases.

When an extGTS allocation or deallocation occurs, a node and its one-hop neighbors convert mutable CAPs to extCFPs or LOPs, or vice versa. To track these extCFP/LOP translations in a decentralized manner, nodes maintain an attribute, a mutable CAP bitmap (CCB), representing the translation status of all CAPs (i.e. CAP, LOP and extCFP) in multiple superframes. . CCB is a one-dimensional bitmap, and the 2-bit subblocks of CCB represent CAP, LOP, and extCFP as 00, 01, and 10, respectively, as shown in FIG.

After updating taSAB and taACT, the node performs a CCB update for each mutable CAP in the taSAB subblock included in the DSME extGTS response or DSME extGTS notify command. The detailed behavior of the CCB update is given in Algorithm 2, which includes an attribute (e.g. CCB ) and three variables (e.g. node_extGTS_presence, node_extGTS_cnt, all_extGTS_cnt), in addition to the attributes and variables used in Algorithm 1, the state of mutable CAPs and changes Check the extGTS assigned to the available CAPs.

A CCB is represented as a one-dimensional array containing 2 ^(MO-SO) 2-bit subblocks as elements. node_extGTS_presence is a boolean variable indicating whether there is an extGTS assigned to a node in a mutable CAP. node_extGTS_cnt and all_extGTS_cnt are counter values indicating the number of extGTS allocated to the node and the total number of extGTS in the changeable CAP, respectively. Upon receiving a DSME extGTS response or DSME extGTS notify command, the node checks the 'Management Type' field of the command. If it indicates 'extGTS assignment' (i.e. management_type == 001) then the node converts the mutable CAP to extCFP. If the node overhears the above command, it means extGTS is assigned to a 1-hop neighbor, so if the state of the mutable CAP is CAP, it changes the mutable CAP to LOP. In the case of 'extGTS deallocation' (i.e. management_type == 000), the node checks all super frame indexes (i.e. sid _i ) in taACT.sid to see if there is an extGTS assigned to the mutable CAP and calculates it. If the specific super frame index, sid _i , is equal to changeableCAP_sid, the node sets node_extGTS_presence to TRUE and increments node_extGTS_cnt by 1. The node then examines all bits of the taSAB subblock corresponding to the changeable CAP (ie taSAB [changeableCAP_sid] [j] [k]) to count the number of all extGTSs included in the changeable CAP. If a specific bit in the taSAB subblock is 1, it indicates that the mutable CAP has extGTS, so the node increments all_extGTS_cnt by 1.

After completing the taACT.sid and taSAB probes, the node determines the state transition of the mutable CAP based on node_extGTS_presence, node_extGTS_cnt, and all_extGTS_cnt. If node_extGTS_presence is TRUE, it indicates that the node in the mutable CAP has extGTS assigned to it, so the node converts the mutable CAP to extCFP. Otherwise, the node checks if all_extGTS_cnt is greater than node_extGTS_cnt, and if so, it indicates that the mutable CAP's 1-hop neighbor has an assigned extGTS, so the node converts the mutable CAP to a LOP. If node_extGTS_presence is FALSE and all_extGTS_cnt is less than node_extGTS_cnt, mutable CAPs MUST remain CAPs.

Unlike CFP's GTS, extGTS hops channels according to a modified hopping sequence (ie, HoppingSequenceList_ext) in which the control channel is excluded from the existing hopping sequence. The channel frequency used during extGTS (i.e., C_ext) is derived as follows.

Here, HoppingSequenceList_ext[m] represents the m-th channel frequency of the modified hopping sequence for extGTS, i is the slot index of extCFP, j is the SD index representing the index of the super frame in BI, and l is the number of slots in extCFP (i.e., 8), macChannelOffset is the channel offset of the receiver node, macPanCoordinatorBsn is the sequence number of EB sent by the PAN coordinator, and macHoppingSequenceLength is the hopping sequence length of the existing hopping sequence.

The performance of TaCFPext was evaluated through experimental simulation using MATLAB simulator. The effect of TaCFPext was verified by comparing the simulation results with the conventional DSME of the IEEE 802.15.4 standard. The following subsections present the simulation setup and configuration and describe the simulation results in detail.

In the simulation, network instances consisting of 20, 40, 60, 80, 100, 120, 140, 160, 180, and 200 nodes, respectively, were considered. In each instance, nodes are randomly placed in a 15 X 15 m ² area and the transmission range is 10 m. 11 shows an example of a network deployment with 40 nodes. Each node forms a sender-receiver pair with one of its single-hop neighbors, and the sender transmits a specified number of data packets per multiple superframe to the receiver, to which a dedicated GTS is assigned to the CFP. If all required GTSs cannot be allocated due to high contention in CAPs or lack of space in CFPs, nodes drop data packets that cannot be transmitted in the current multi-superframe. Two traffic scenarios, static and dynamic traffic scenarios, were considered to check the adaptability of TaCFPext to various traffic. In a static traffic scenario, the sender sends the same number of packets (i.e. 7 packets) in every multi-super frame. On the other hand, in the dynamic traffic scenario, the nodes in the network are divided into two groups, each group consisting of the same number of nodes. Nodes belonging to the same group generate the same pattern of dynamic traffic at 8 beacon intervals. Nodes in a group transmit 21 packets per multiple superframes in the 3rd and 4th beacon intervals (i.e. high traffic), and only transmit 1 packet per multiple superframes in the remaining beacon intervals (i.e. low traffic). . Meanwhile, nodes in the other group generate high traffic in the seventh and eighth beacon intervals. This configuration for dynamic traffic scenarios is a way to track the behavioral patterns of GTS assignment and node deassignment under various traffic load environments. The performance of TaCFPext was compared with that of conventional DSMEs in terms of number of GTS allocated, packet drop rate, GTS allocation delay, average delay, total throughput and fairness index. In the case of existing DSMEs, both DSME network environments with or without the CAP reduction option were considered. In TaCFPext and conventional DSME, it is assumed that all nodes maintain the same DSME multi-superframe structure with SO, MO, and BO set to 3, 5, and 6, respectively. The simulation was repeated 100 times. Detailed simulation parameters are listed in Table 1 below.

Parameters Values PHY IEEE 802.15.4 Modulation O-QPSK (4bits/symbol) Bit rate 250 kbps Number of channels 16 SO, MO, BO 3, 5, 6 AIFS 12 symbols LIFS 40 symbols aUnitBackoffPeriod 20 symbols aBaseSlotDuration 60 symbols PHY header 6 bytes MAC header 10 bytes Payload size 127 bytes ACK size 11 bytes Multi-superframe duration 491.52ms Slot length 7.96ms Superframe duration 112.88ms

Figure 12 shows the change in the number of assigned GTSs over time in a static traffic scenario with 100 nodes (i.e., 50 sender-receiver pairs). The upper and lower figures of FIG. 12 show the number of GTSs assigned during the total simulation time (i.e., 60 seconds) and from the start of the simulation to 5 seconds, respectively. Since one packet is transmitted in one slot, each node in the network must allocate 7 GTSs to transmit 7 packets in one multi-superframe. Therefore, 350 GTSs must be allocated in one multi-superframe to accommodate the entire traffic load for 50 node pairs. Generally, in FIG. 12, the number of assigned GTSs increases and then maintains a specific value. Considering the interval in which the number of allocated GTSs is kept constant, the number of GTSs allocated to TaCFPext and CAP reduction performing DSMEs (ie, 350) is greater than that of existing DSMEs (ie, 323). DSMEs performing TaCFPext and CAP reduction can have enough space to allocate a large number of GTSs through extCFP and CAP reduction options, respectively, and existing DSMEs maintain a relatively limited CFP length compared to DSMEs performing TaCFPext and CAP reduction do. Therefore, in the existing DSME, some nodes cannot allocate GTSs and the number of allocated GTSs does not reach 350. Meanwhile, in the figure below, the number of GTSs allocated to TaCFPext and existing DSMEs increases rapidly compared to DSMEs performing CAP reduction. In TaCFPext and traditional DSME, nodes try to allocate a GTS in every superframe because every superframe in multiple superframes contains a CAP. However, in the CAP reduction DSME, since the CAP is included only in the first superframe of multi-superframes, the node can attempt GTS allocation only in the first superframe. Therefore, the number of GTSs allocated to the CAP reduction DSME increases only in the first super frame of the multi-super frame.

Figure 13 shows packet drop rates in static traffic scenarios for various node counts. In the simulation, if a node fails to allocate the required GTS in multiple superframes, it drops packets that cannot be transmitted in the current multiple superframes. In the figure, as the number of nodes increases, the packet drop rate increases. This is because as the number of nodes increases, it is more likely that a node fails to allocate a GTS due to high contention in the CAP. Additionally, some nodes may fail to allocate GTS due to lack of space in CFP, which also increases the packet drop rate. Overall, TaCFPext has a smaller packet drop rate than conventional DSMEs and DSMEs with CAP reduction. In TaCFPext, every superframe in multi-superframes contains a CAP so that nodes have more opportunities to allocate GTS in high contention. It also changes the CAP to extCFP to provide sufficient space for GTS allocation even if the number of GTS required increases. However, in conventional DSMEs, when the number of nodes exceeds 60, the packet drop rate increases rapidly due to lack of CFP space. Performing CAP reduction In DSME, multi-superframes contain only one CAP even though there is sufficient CFP space in the multi-superframes. Therefore, in DSMEs that perform CAP reduction, the CAP length is limited when the number of nodes increases.

Figure 14 shows the total throughput for various node numbers in static traffic scenarios. In FIG. 14, as the number of nodes increases, the amount of traffic injected into the network increases and thus the total throughput increases. When the number of nodes exceeds 60, the total throughput of TaCFPext, the existing DSME, and the DSME performing CAP reduction starts to make a difference due to the difference in packet drop rate (see the result of FIG. 13). In our simulations, when the number of nodes varied from 60 to 200, the average number of packets transmitted by the nodes decreased from 853.23 to 789.25 in TaCFPext, from 850.40 to 599.30 in conventional DSME, and from 847.7 to 681.26 in DSME performing CAP reduction. Thus, TaCFPext exhibits a higher total throughput than the other cases because the node transmits a larger number of packets on average. Quantitatively, it achieves 16.20% and 6.03% higher total throughput, respectively, compared to conventional DSMEs and DSMEs implementing CAP reduction.

Figure 15 shows the GTS allocation delay for various node numbers in static traffic scenarios. The GTS allocation delay in the simulation represents the average time it takes for a node to complete an allocation for the required GTS from the start of the simulation. Overall, the GTS allocation delay increases due to the high contention of CAPs as the number of nodes increases. In the figure, TaCFPext and conventional DSMEs show significantly shorter GTS allocation delays than DSMEs performing CAP reduction. This is because multiple CAPs exist in one multi-super frame in TaCFPext and existing DSMEs, whereas only one CAP is included in one multi-super frame in CAP reduction DSME. On the other hand, compared to conventional DSME, TaCFPext shows slightly longer GTS allocation delay at the point where the number of nodes is 80. When the number of nodes exceeds 60, some nodes in the existing DSME fail to allocate GTS due to lack of space. On the other hand, in TaCFPext, in this case, the CAP of the multi-super frame is changed to extCFP so that the node can allocate extGTS. In the figure, due to this additional allocation of extGTS, TaCFPext exhibits a slightly longer GTS allocation delay compared to conventional DSME.

Figure 16 shows the average delay for various node counts in a static traffic scenario. The average delay in the simulation represents the average time it takes a node to transmit a packet. Overall, the average delay of TaCFPext is shorter than that of DSMEs with CAP reduction and existing DSMEs. TaCFPext allows the node to change the CAP to extCFP if the space in the CFP is not sufficient to allocate the required GTS. However, in the existing DSME, when the number of nodes exceeds 60, some nodes cannot allocate the required GTS due to lack of CFP space, and the average number of packets transmitted within the multi-super frame decreases. Therefore, the average time for each node to transmit one packet increases rapidly. Meanwhile, in the result of FIG. 15, in TaCFPext, a node allocates a GTS and transmits a packet before a node of a DSME performing CAP reduction. Quantitatively, TaCFPext reduced average latency by 10.44% and 3.89%, respectively, compared to conventional DSME and DSME with CAP reduction.

17 shows fairness indices for various node numbers in static traffic scenarios. The fairness index (F) can be calculated as follows.

Here, n is the number of sender nodes, i is the sender's node ID, and x _i is a fairness parameter and means the number of packets transmitted by each sender node. In the simulation, the node drops data packets as many as the number of unallocated GTSs during multiple superframes. Therefore, in Equation 4, the fairness index differs depending on whether each sender node has successfully allocated a GTS. In the figure, the fairness index decreases as the number of nodes increases. Performing TaCFPext and CAP reduction DSME maintains a high level of fairness index, which gradually decreases when the number of nodes exceeds 100. On the other hand, when the number of nodes is 60, the fairness index of the existing DSME rapidly decreases. This is because CFP is running out of space. On the other hand, when the number of nodes is 100 or more, the fairness index of TaCFPext is slightly larger than DSME performing CAP reduction. TaCFPext multi-superframes can use more CAPs than DSME multi-superframes with CAP reduction. Therefore, in TaCFPext, the number of nodes that successfully allocate GTS during one multi-superframe is greater than that of DSME performing CAP reduction, so the difference in the number of packets transmitted between nodes becomes smaller.

Figure 18 shows the number of assigned GTSs over time in a dynamic traffic scenario with 100 nodes. The top, middle, and bottom figures of FIG. 18 show changes in the number of GTSs allocated in TaCFPext, existing DSMEs, and CAP reduction DSMEs, respectively. In a dynamic traffic scenario, nodes alternately generate high and low traffic loads depending on the group they belong to, so that the number of assigned GTSs increases at high traffic loads and increases and decreases at low traffic loads. For TaCFPext (i.e., upper figure), the interval between increasing and decreasing the number of assigned GTSs barely overlaps between the two groups. On the other hand, for conventional DSMEs and DSMEs implementing CAP reduction (i.e., middle and lower figures), these gaps overlap a lot. This difference between TaCFPext and other cases is caused by a difference in behavior between extGTS deallocation and GTS deallocation. extGTS is deallocated if not used for 3 multi-superframes and GTS is deallocated if not used for 7 multi-superframes. Therefore, nodes in TaCFPext can deallocate unnecessary GTSs before nodes in other cases. As a result, TaCFPext frees up more space in the CFP by de-allocating unnecessary GTS earlier, which is needed for the next higher traffic load. On the other hand, in the existing DSME, the number of GTSs assigned to a group increases and then is maintained at a constant number under high traffic load. This is because nodes no longer allocate GTS due to lack of space in CFP. Then, as nodes belonging to other groups deallocate unnecessary GTSs, the number of allocated GTSs increases again. Performing CAP reduction The number of allocated GTSs in the DSME increases by less than TaCFPext at high traffic loads. Performing CAP reduction DSME's multi-superframes contain one CAP, and TaCFPext's multi-superframes contain several CAPs. Therefore, under high traffic load, nodes in DSME performing CAP reduction wait longer than nodes in TaCFPext when GTS allocation fails.

Figure 19 shows packet drop rates for various node numbers in dynamic traffic scenarios. 19, the packet drop rate increases as the number of nodes increases. This is because the number of nodes failing to allocate GTS increases due to high contention in CAP and lack of space in CFP. In dynamic traffic scenarios, the packet drop rate is higher than in static traffic. This is because, unlike static traffic scenarios that require one initial GTS allocation procedure, nodes in dynamic traffic scenarios repeatedly perform GTS allocation and deallocation procedures whenever the traffic load changes. That is, in dynamic traffic scenarios, nodes that fail to allocate GTS repeatedly occur. Overall, TaCFPext has a lower packet drop rate compared to conventional DSMEs and DSMEs with CAP reduction. In TaCFPext, nodes use CAPs as extCFPs in case of high traffic load and deallocate unnecessary GTS before nodes in other cases to free up more space in CFP for the next high traffic load. Thus, TaCFPext minimizes GTS allocation failures due to lack of space in CFP. On the other hand, in the existing DSME, as the number of nodes increases, the number of nodes that fail to allocate GTS due to lack of CFP space rapidly increases. CAP reduction In case of DSME, multiple superframes contain only one CAP. Therefore, the number of nodes failing to allocate GTS due to lack of CAP is higher than in TaCFPext, even though CFP maintains a relatively larger space.

Figure 20 shows the total throughput for various node numbers in a dynamic traffic scenario. In FIG. 20, as the number of nodes increases, the total amount of traffic load increases and thus the total throughput increases. TaCFPext, traditional DSME and CAP reduction performed DSMEs show different aggregate throughput regardless of the number of nodes. This is because the number of lost packets is different between TaCFPext, the existing DSME, and the DSME performing CAP reduction, even if the number of nodes is small in a dynamic traffic scenario. In particular, when the number of nodes increases from 20 to 120, the average number of packets transmitted by each node decreases from 388.72 to 265.77 in TaCFPext, from 277.42 to 130.74 in conventional DSME, and from 344.20 to 214.27 in DSME with CAP reduction. As a result, TaCFPext exhibits a greater total throughput than other cases. Quantitatively, TaCFPext achieves 71.03% and 20.50% higher total throughput compared to conventional DSME and DSME with CAP reduction, respectively.

Figure 21 shows the GTS allocation delay for various node numbers in dynamic traffic scenarios. In dynamic traffic scenarios, the GTS allocation delay is the average time it takes for a node to complete its allocation for the required GTS from the point where the demand for GTS allocation occurs (i.e., at the start of the simulation and the change from low traffic load to high traffic load). indicates In FIG. 21, the GTS allocation delay increases as the number of nodes increases due to high CAP contention. Overall, TaCFPext has lower GTS allocation delay than conventional DSMEs and DSMEs with CAP reduction. In TaCFPext, nodes start de-allocating GTS before nodes in other cases. In this case, nodes belonging to one group complete GTS allocation before nodes belonging to the other group start to allocate GTS. However, in the existing DSME and DSME performing CAP reduction, nodes belonging to one group may not complete GTS allocation before nodes belonging to another group allocate GTS. In this case, the nodes in both groups try to allocate and deallocate the GTS simultaneously. Therefore, TaCFPext has a shorter GTS allocation delay due to less CAP contention compared to the existing DSME and DSME implementing CAP reduction. On the other hand, existing DSMEs have longer GTS allocation delays than in other cases. In the existing DSME, due to lack of CFP space, a node belonging to one group cannot allocate a GTS until a node belonging to another group completes the GTS deallocation. Therefore, in the existing DSME, the GTS allocation delay greatly increases due to the time the node waits for the GTS allocation release. CAP reduction DSMEs have longer GTS allocation delays than TaCFPext due to the amount of time nodes wait for GTS allocations to reconnect. Performing CAP reduction In DSME, multi-superframes contain only one CAP, so if a node fails a GTS allocation due to a conflicting CAP (compared to a node using TaCFPext), the node is likely to wait longer to retry the GTS allocation. is high

Figure 22 shows the average delay for various node numbers in dynamic traffic scenarios. In FIG. 22, as the number of nodes increases, the number of dropped packets increases, so the average delay increases. Contrary to the results of the static traffic scenario (see Figure 16), the difference in the behavior of GTS allocation and deallocation results in the required GTS allocation. Overall, TaCFPext has shorter average delays compared to conventional DSMEs and DSMEs with CAP reduction. In the result of FIG. 19, nodes using TaCFPext allocate GTS and transmit data packets before nodes in other cases. Also, from the result of FIG. 19 , it is confirmed that TaCFPext has a lower packet drop rate than other cases. Thus, TaCFPext keeps the average time each node takes to transmit one packet shorter than in other cases. Quantitatively, TaCFPext reduced average latency by 41.61% and 16.85%, respectively, compared to conventional DSME and DSME with CAP reduction.

23 shows fairness indices for various node numbers in dynamic traffic scenarios. In a dynamic traffic scenario, whenever a high traffic load occurs, the number of nodes unable to allocate a GTS increases due to lack of space in the CFP. Therefore, the fairness index of the dynamic traffic scenario is smaller than that of the static traffic scenario regardless of the number of nodes. Overall in the figure, TaCFPext has a higher fairness index than the other cases. Referring to FIGS. 18 and 19 , it can be seen that TaCFPext maintains the number of assigned GTSs at a high level even under high traffic load, and maintains a low level of packet drop ratio as the number of nodes increases. That is, in TaCFPext, when the traffic load is high, the number of nodes that fail to allocate GTS due to lack of CFP space is smaller than in other cases, and as a result, the difference in the number of transmitted packets between nodes is smaller than in other cases. However, in conventional DSMEs, as the number of nodes increases, the number of nodes that fail to allocate GTS due to lack of CFP space when the traffic load is high increases. Also, in the CAP reduction DSME, since only one CAP is included in a multi-superframe, nodes easily fail in GTS allocation due to high CAP contention. Quantitatively, TaCFPext achieved 25.60% and 8.96% higher fairness indices, respectively, compared to conventional DSMEs and DSMEs implementing CAP reduction.

Meanwhile, various embodiments described above may be implemented in a recording medium readable by a computer or a similar device using software, hardware, or a combination thereof.

According to the hardware implementation, the embodiments described in this disclosure are application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), and field programmable gate arrays (FPGAs). ), processors, controllers, micro-controllers, microprocessors, and electrical units for performing other functions.

In some cases, the embodiments described herein may be implemented by a processor itself. According to software implementation, embodiments such as procedures and functions described in this specification may be implemented as separate software modules. Each of the software modules described above may perform one or more functions and operations described herein.

On the other hand, computer instructions or computer programs for performing processing operations in the electronic device 100 according to various embodiments of the present disclosure described above are provided on a non-transitory computer-readable medium can be stored in Computer instructions or computer programs stored in such a non-transitory computer readable medium, when executed by a processor of a specific device, cause the above-described specific device to perform processing operations in the node/electronic device according to various embodiments described above.

A non-transitory computer readable medium is a medium that stores data semi-permanently and is readable by a device, not a medium that stores data for a short moment, such as a register, cache, or memory. Specific examples of the non-transitory computer readable media may include CD, DVD, hard disk, Blu-ray disk, USB, memory card, ROM, and the like.

Although the preferred embodiments of the present disclosure have been shown and described above, the present disclosure is not limited to the specific embodiments described above, and is common in the technical field belonging to the present disclosure without departing from the gist of the present disclosure claimed in the claims. Of course, various modifications and implementations are possible by those with knowledge of, and these modifications should not be individually understood from the technical spirit or perspective of the present disclosure.

100: System 100-1, 2, 3, 4, ... : node

Claims (10)

In the slot scheduling method of a system composed of a Deterministic and Synchronous Multichannel Extension (DSME) network,
Transmitting, by the sender node, a request for allocating an extended guaranteed time slot (extGTS) to at least one contention access period (CAP) included in multiple superframes of the DSME network to a receiver node;
selecting, by the recipient node, at least one slot of the CAP for allocating the extGTS according to the request;
transmitting, by the receiver node, a response including information on the selected slot to the sender node;
broadcasting, by the sender node, a notification including information about the extGTS allocated to the selected slot;
designating, by a node one-hop adjacent to the sender node, the CAP as a Listen Only Period (LOP) based on the broadcasted announcement; and
Updating, by the 1-hop neighboring node, taSAB of the 1-hop neighboring node based on the designated LOP; According to claim 1,
Sending the request,
The sender node transmits the request including information on the number of extGTS required, a super frame, a slot, and a traffic-adaptive slot allocation bitmap (taSAB) subblock of the CAP to the receiver node;
The taSAB subblock,
The method of scheduling slots in a system comprising extGTS allocation information for channel offsets and slots in a super frame including the CAP in the form of a matrix. According to claim 2,
The step of selecting the slot is,
the recipient node compares a taSAB subblock included in the request with a taSAB subblock of the recipient node for the CAP to identify availability of a slot included in the request;
and if the slot included in the request is identified as unavailable, selecting at least one available slot different from the slot included in the request. According to claim 1,
The slot scheduling method of the system,
Further comprising, by the sender node, updating taSAB and a traffic-adaptive allocation counter table (taACT) of the sender node based on the response received from the receiver node;
The taACT,
Contains information about super frame ID, slot ID, and channel offset related to the allocated extGTS;
Broadcasting the notification,
and broadcasting the notification related to the updated taSAB and taACT. According to claim 1,
The channel frequency (C_ext) of the extGTS is derived through the following formula,

,

The HoppingSequenceList_ext[m] represents the m-th channel frequency of the modified hopping sequence for extGTS, i is the slot index of extCFP, j is the SD (Superframe Duration) index representing the superframe index in BI (Beacon Interval), l is the number of slots in extCFP, macChannelOffset is the channel offset of the receiver node, macPanCoordinatorBsn is the sequence number of the Enhanced Beacon (EB) sent by the Personal Area Network (PAN) coordinator, and macHoppingSequenceLength is the hopping sequence length of the existing hopping sequence. method. delete According to claim 1,
The slot scheduling method of the system,
increasing, by the sender node, an idle counter in taACT by a predetermined value whenever an ACK frame is not received; and
and transmitting, by the sender node, a request to release the allocation of the extGTS to the receiver node when the idle counter is greater than or equal to a threshold value. According to claim 7,
The first threshold of the idle counter corresponding to the deallocation condition of the extGTS allocated in the CAP is the second threshold of the idle counter corresponding to the deallocation condition of the GTS (Guaranteed Time Slot) allocated in the CFP (Contention Free Period). A method of scheduling slots in a system that is less than a threshold. delete In the computer program stored on a computer readable recording medium,
A computer program stored in a computer readable recording medium, which is executed by a processor of an electronic device to cause the electronic device to perform the slot scheduling method of claim 1.

Images