There is a difference between mechanism and policy. In IEEE802.15.4e, the mechanism is how to synchronize the network, and enable channel hopping; the policy is how to use the resulting slotted organization to efficiently transport data over multiple hops. IEEE802.15.4e defines the mechanisms, but not the policy.
The figure below presents a simple case of a 8-node IEEE802.15.4e network with a slot frame length of 10 slots. IEEE802.15.4e defines how nodes synchronize; because on each slot, a node has a choice of 16 frequency channels, this results in a grid structure, with time on the x-axis, and frequency on the y-axis. IEEE802.15.4e does not specify how these cells are to be used: a mechanism is missing which allows each pair of neighbor nodes to agree on cells to communicate on. Agreeing is necessary because the transmitter will need to transmit at the same time and frequency as the receiver is listening. Each slot only allows the transmission of data in one direction, so if two nodes want to establish bidirectional connectivity, they need to schedule at least two cells, one in each direction.
IEEE802.15.4e does not specify how such distributed scheduling should happen. Because the next upper layer (6LoWPAN) assumes that all nodes are capable to communicating with all of their neighbors, there is a "gap" to be filled to glue IEEE802.15.4e to the upper stack. This Section describes a protocol which we have developed, called uRES, which allows each node to establish bidirectional connectivity with all of its neighbors.
A slot in the scheduling table of a node can take one of the following states:
When a node has just joined a network, the first slot in its slotframe is of type ADV, the second of type RES, and all the rest are of type OFF. uRES is used to populate the OFF slots, so that a node has exactly one TX slot to each neighbor and one RX slot from each neighbor. uRES packets are exchanged exclusively in the RES slot of the slotframe.
The following is an example which shows the procedure when mote-6 joins in network, where mote-4 and mote-5 are in radio range of mote-6.
There are two methods to establish the links.
The procedure may involves 6 related packets, including, Advertisement BEACON, ResLinkReq, ResLinkResp, RemoveLinkReq, ScheduleReq (option), ScheduleResp. (option)
Considering the integrity of IEEE802.15.4 specification, uRes related packets must be coded in Information Elements (IE). The IEs of Advertisement packets must be carried by payload IEs of BEACON, and the IEs of other packets above must carried by payload IEs of DATA.
The related IEs are defined as follows
SubID(7bits) | type(7bits) | Function | source |
0x1a | Short | TSCH synchronization IE – containing ASN, used to synchronize to the network | IEEE802.15.4e |
0x1b | Short | TSCH slotframe and link IE – containing slotframe definition and definition of links, used to join network and link reservation | IEEE802.15.4e |
0x1c | Short | TSCH Timeslot Template IE --containing only the ID of the template | IEEE802.15.4e |
0x9 | Long | TSCH Channel hopping IE --containing only the ID of the sequence | IEEE802.15.4e |
0x40 | Short | uResLinkType IE – containing slotframe definition, links definition and link type definition, used to join network | uRes |
0x41 | Short | uRes command IE --containing command ID | uRes |
0x42 | Short | uResBandwidth IE –containing SlotframeID and number of slots to be reserved, used in link reservation request | uRes |
0x43 | Short | uResGeneral Schedule IE –containing compressed schedule, e.g. BitMap | uRes |
| Link Type |
0x00 | Advertisement |
0x01 | TX |
0x02 | RX |
0x03 | TXRX |
Command ID | function |
0x00 | Reserve Link Request |
0x01 | Reserve Link Response |
0x02 | Remove Link Request |
0x03 | Schedule Request |
0x04 | Schedule Response |
When Compression Type =0x00, i.e. BitMap
The IEs in each packet are summarized as follows.
Packet name | Sync | Frame&Link | Timeslot | Ch-Hopping | LinkType | uRes-Cmd | Bandwidth | Schedule |
Advertisement | X | X | X | X | option |
|
|
|
ResLinkReq |
| option |
|
|
| X | option | option |
ResLinkResp |
| option |
|
|
| X |
| option |
RemoveLinkReq |
| option |
|
|
| X |
| option |
ScheduleReq |
|
|
|
|
| X |
|
|
ScheduleResp |
| option |
|
|
| X |
| option |
Since Slotframe and Link IE (Frame&Link IE) is used in multiple packets, we define its coding and function in each packet as follows.
Frame&Link IE in advertisement provides one slotframe information and the link(s) in the slotframe for mote to join in network.Frame&Link IE in ResLinkReq defines the proposed candidate link list, from which the destination mote will choose links for reservation. Frame&Link IE in RemoveLinkReq defines the links, which will be removed. Function of Frame&Link IE in ResLinkResp packet defines every slotframe by (Slotframe ID, Size), which the associated mote can use and defines Links, which the associated mote can use. The Frame&Link in ScheduleResp lists all of links used by the sender of the packet.
In addition, General Schedule IE can be used as alternative of Frame&Link IEs in the packets except advertisement BEACON.
As alternative of Frame&Link IE, General Schedule IE will represent different information in different packets.
For example, type=0x00, i.e. BItMap.Since a mote may use multiple Slotframes, BitMap will be the results of overlapping the link usage in every Slotframe. Thus, SlotframeID must be set as 0xFF. Here is an example. Assume number of channel is 8, and there are two Slotframes, the first one size=12, and the second one size=36, the BitMap IE example is shown as follows.
The figure below illustrates the finite-state machine of reservation. Res circles indicate state; green rounded rectangles indicate reservation commands and notification of command reception. Blue rectangles indicate middle procedures of reservation.
Reservation module starts with an “IDLE” state. Reservation module is driven by button interrupt. When you press button, reservation module will check variable “button_event”.
pseudo-code:
Switch button_event:
Case 0:
Case 1:sending “Link Request” command.
Case 2:sending “remove links” command.
Default: sending a data at a TX slot, not at a TXRX slot.
Button_event++;
When a “Link Request” command is triggered, reservation module will do serial procedures to generate a “Link Request” message.
When a “Remove Link” command is triggered, reservation module will do serial procedures to generate a “Remove Link” message.
When calling “Link Response” command, reservation module will do serial procedures to generate a “Link Response” message.
This function is called by task_resNotifSendDone(). It will check the variable “State”.
pseudo-code:
Switch State:
Case S_WAIT_RESLINK REQUEST_SENDDONE:
Chang state to S_WAIT_FORRESPONSE.
Case S_WAIT_RESLINK RESPONSE_SENDDONE
Chang state to S_IDLE.
Casse S_WAIT_REMOVE LINK REQUEST_SENDDONE
Chang state to S_IDLE.
When received a uRes command, reservation module will check variable “uResCommandID”.
pseudo-code:
Switch uResCommandID:
Case 0: this is “Link Request” command, calling “notifyreceiveuResLink Request”.
Case 1: this is “Link Response” command, calling “notifyReceiveuResLink Response”.
Case 2: this is “remove link” command, calling “notifyReceiveRemove Link Request”.
Case 3: this is “schedule request” command.
Case 4: this is “schedule response” command.
When received “Link Request” command, reservation module allocates links for sender mote. Then, reservation module adds new slots to “scheduleBuffer”, and calls “Link Response” command.
When received “Link Response” command, reservation module adds new links to “scheduleBuffer”.
When receive “remove link” command, reservation module removes links from “scheduleBuffer”.
When “reservation_pretendSendData” is triggered, reservation module generates a new data message.
When “reservation_pretendSendData” is triggered, reservation module will print message data.
When calling “res_send()”, res module will check the creator of msg.
pseudo-code:
If(msg->creater == COMPONENT_RESERVATION)
Send data at TXRX slot
If(msg->creater== COMPONENT_UPPERLAYER)
Send data at TX slot
Call res_send_interval()
Reservation code url:
In the implementation of uRES, a number of failsafe components are added to uRES.
Each instance of uRES has a maximum lifetime after which it is terminated. This is useful in the case when the replier disappears while the requester is waiting for its answer. In that case, the lifetime of the associated uRES instance expires, the instance is terminated and the reserved cell is returned to its initial OFF state.
Whenever a node transmits a uRES request to schedule a cells (txCommand is set to RES_ACTION_REQ_CELL), it also checks whether it has a RX cell scheduled from that same neighbor, and indicates that in the rxCommand, rxSlotOffset and rtxChannelOffset portion of the uRES message. Similarly, the replier indicates whether it has a TX cell to that neighbor in the txCommand, txSlotOffset and txChannelOffset portion of the uRES message. This allows node to opportunistically verify that their schedules are consistent.
When a node detects and inconsistency, it cancels all TX and RX slots with that neighbor and issues a uRES message with txCommand set to RES_ACTION_FREE_CELL for that neighbor. Upon receiving this message, the neighbor also cancels all TX and RX. Because the implementation regularly checks whether there is a TX slot to each stable neighbor, a node will invoke a new instance of uRES to re-establish connectivity.
This fail-safe component enabled uRES to be robust against nodes being reinitialized at any time.
uRES schedules TX and RX slots explicitly between neighbor nodes. An alternative is to declare shared reception slots among all nodes in the network. This results in a slotted ALOHA communication scheme, which may complement or replace the explicit use of uRES. Note that this scheme has not been implemented yet, but will be used for the interoperability operation.