6TiSCH Operation Sublayer (6top) Protocol (6P)

This document defines the "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control layer. 6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document. A 6top SF decides when to add/delete cells, and it triggers 6P Transactions. The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF.

Introduction

All communication in an "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH) network is orchestrated by a schedule [START_REF] Watteyne | Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement[END_REF]. The schedule is composed of cells, each identified by a [slotOffset,channelOffset] (Section 3.2.4). This specification defines the 6TiSCH Operation Sublayer (6top) Protocol (6P), which is terminated by 6top. 6P allows a node to communicate with a neighbor node to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another. This results in distributed schedule management in a 6TiSCH network. 6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document. The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF. The example network depicted in Figure 1 is used to describe the interaction between nodes. We consider the canonical case where node "A" issues 6P Requests (also referred to as "commands" in this document) to node "B". We use this example throughout this document: node A always represents the node that issues a 6P Request, and node B represents the node that receives this request. o Node A MAY also monitor statistics to determine whether collisions are happening on a particular cell to node B. If this feature is enabled, node A communicates with node B to "relocate" this particular cell to a different [slotOffset,channelOffset] location in the TSCH schedule.

This results in distributed schedule management in a 6TiSCH network.

The 6top SF defines when to add/delete a cell to/on a neighbor. Different applications require different SFs; this topic is out of scope for this document. Different SFs are expected to be defined in future companion specifications. A node MAY implement multiple SFs and run them at the same time. At least one SF MUST be running. The SFID field contained in all 6P messages allows a node to invoke the appropriate SF on a per-6P Transaction basis. Section 2 describes 6top. Section 3 defines 6P. Section 4 provides guidelines on how to define an SF.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

6TiSCH Operation Sublayer (6top)

As depicted in Figure 2 ----------------------------------------- ----------------------------------------- o A hard cell is read-only for 6top.

+ | 6top | +-
In the context of this specification, all the cells used by 6top are soft cells. Hard cells can be used, for example, when "hard-coding" a schedule [START_REF] Vilajosana | Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration[END_REF].

Using 6P with the Minimal 6TiSCH Configuration

6P MAY be used alongside the minimal 6TiSCH configuration [START_REF] Vilajosana | Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration[END_REF].

In this case, it is RECOMMENDED to use two slotframes, as depicted in Figure 3: o Slotframe 0 is used for traffic defined in the minimal 6TiSCH configuration. In Figure 3, Slotframe 0 is five slots long, but it can be shorter or longer.

o 6P allocates cells from Slotframe 1. In Figure 3, Slotframe 1 is 10 slots long, but it can be shorter or longer. The minimal 6TiSCH configuration cell SHOULD be allocated from a slotframe of higher priority than the slotframe used by 6P for dynamic cell allocation. This way, dynamically allocated cells cannot "mask" the cells used by the minimal 6TiSCH configuration. 6top MAY support additional slotframes; how to use additional slotframes is out of scope for this document. 6P enables two neighbor nodes to add/delete/relocate cells in their TSCH schedule. Conceptually, two neighbor nodes "negotiate" the location of the cells to add, delete, or relocate in their TSCH schedule.

6P Transactions

We call "6P Transaction" a complete negotiation between two neighbor nodes. A particular 6P Transaction is executed between two nodes as a result of an action triggered by one SF. For a 6P Transaction to succeed, both nodes must use the same SF to handle the particular transaction. A 6P Transaction starts when a node wishes to add/delete/relocate one or more cells with one of its neighbors. A 6P Transaction ends when (1) the cell(s) has been added/deleted/ relocated in the schedule of both nodes or (2) the 6P Transaction has failed.

6P messages exchanged between nodes A and B during a 6P Transaction SHOULD be exchanged on non-shared unicast cells ("dedicated" cells) between nodes A and B. If no dedicated cells are scheduled between nodes A and B, shared cells MAY be used.

Keeping consistency between the schedules of the two neighbor nodes is important. A loss of consistency can cause loss of connectivity. One example is when node A has a transmit cell to node B but node B does not have the corresponding reception cell. To verify consistency, neighbor nodes maintain a sequence number (SeqNum).

Neighbor nodes exchange the SeqNum as part of each 6P Transaction to detect a possible inconsistency. This mechanism is explained in Section 3.4.6.2.

An implementation MUST include a mechanism to associate each scheduled cell with the SF that scheduled it. This mechanism is implementation specific and is out of scope for this document.

A 6P Transaction can consist of two or three steps. A 2-step transaction is used when node A selects the cells to be allocated. A 3-step transaction is used when node B selects the cells to be allocated. An SF MUST specify whether to use 2-step transactions, 3-step transactions, or both.

We illustrate 2-step and 3-step transactions using the topology in Figure 1. In this example, the 3-step transaction occurs as follows:

1. The SF running on node A determines that two extra cells need to be scheduled to node B. The SF uses a 3-step transaction, so it does not select candidate cells. The messages are encapsulated within the Payload IE header. The Group ID is set to the IETF IE value defined in [START_REF] Kivinen | IEEE 802.15.4 Information Element for the IETF[END_REF]. The content is encapsulated by a subtype ID, as defined in [START_REF] Kivinen | IEEE 802.15.4 Information Element for the IETF[END_REF].

Node

Since 6P messages are carried in IEs, IEEE bit/byte ordering applies. Bits within each field in the "6top IE" subtype are numbered from 0 (leftmost and least significant) to k-1 (rightmost and most significant), where the length of the field is k bits. Fields that are longer than a single octet are copied to the packet in the order from the octet containing the lowest-numbered bits to the octet containing the highest-numbered bits (little endian).

This document defines the 6top IE, a subtype of the IETF IE defined in [START_REF] Kivinen | IEEE 802.15.4 Information Element for the IETF[END_REF], with subtype SUBID_6TOP. The subtype content of the 6top IE is defined in Section 3.2.2. The length of the 6top IE content is variable.

Generic 6P Message Format

All 6P messages follow the generic format shown in Figure 6. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other Fields... +-+-+-+-+-+-+-+-+-

Type (T):

The type of message. The message types are defined in Section 6.2.2.

Reserved (R): Reserved bits. These two bits SHOULD be set to zero when sending the message and MUST be ignored upon reception. Section 6.2.6 provides the format of the 6P CellOptions bitmap; this format applies unless redefined by the SF. Figure 7 shows the meaning of the 6P CellOptions bitmap for the 6P ADD, DELETE, and RELOCATE Requests (unless redefined by the SF). Figure 8 shows the meaning of the 6P CellOptions bitmap for the 6P COUNT and LIST Requests (unless redefined by the SF).

Note: Here, we assume that node A issues the 6P command to node B. ------------+----------------------------------------------------- ------------+----------------------------------------------------- ------------+----------------------------------------------------- ------------+----------------------------------------------------- ------------+----------------------------------------------------- ------------+----------------------------------------------------- ------------+----------------------------------------------------- ------------+----------------------------------------------------- Note: Here, we assume that node A issues the 6P command to node B. ------------+----------------------------------------------------- ------------+----------------------------------------------------- ------------+----------------------------------------------------- ------------+----------------------------------------------------- ------------+----------------------------------------------------- ------------+----------------------------------------------------- ------------+----------------------------------------------------- ------------+-----------------------------------------------------+ |TX=1,RX=1,S=1| All cells marked as TX, RX, and SHARED It is composed of a concatenation of zero or more 6P Cells as defined in Figure 9. The content of the CellOptions field specifies the options associated with all cells in the CellList. This necessarily means that the same options are associated with all cells in the CellList.

+-------------+-----------------------------------------------------+ | CellOptions | The type of cells B adds/deletes/relocates to its | | Value | schedule when receiving a 6P ADD/DELETE/RELOCATE | | | Request from A | +-------------+-----------------------------------------------------+ |TX=0,RX=0,S=0| Invalid combination. RC_ERR is returned | +-
+ |TX=0,RX=0,S=1| Invalid combination. RC_ERR is returned | +-
+ |TX=0,RX=1,S=1| Add/delete/relocate TX|SHARED cells at B | | | (RX|SHARED cells at A) | +-
+-------------+-----------------------------------------------------+ | CellOptions |
+ |TX=0,RX=0,S=0| All cells | +-
| +-------------+-----------------------------------------------------+
A 6P Cell is a 4-byte field; its default format is:

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Consider the topology in Figure 1; in this case, the SF on node A decides to add NumCells cells to node B. Node A's SF selects NumCandidate cells from its schedule. These are cells that are candidates to be scheduled with node B. The CellOptions field specifies the type of these cells. NumCandidate MUST be greater than or equal to NumCells. How many cells node A selects (NumCandidate) and how that selection is done are specified in the SF and are out of scope for this document. Node A sends a 6P ADD Request to node B that contains the CellOptions, the value of NumCells, and a selection of NumCandidate cells in the CellList. If the NumCandidate cells do not fit in a single packet, this operation MUST be split into multiple independent 6P ADD Requests, each for a subset of the number of cells that eventually need to be added. In the case of a 3-step transaction, the SF is responsible for ensuring that the returned Candidate CellList fits into the 6P Response.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | slotOffset | channelOffset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata | CellOptions | NumCells | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CellList ... +-+-+-+-+-+-+-+-+-
Upon receiving the request, node B checks to see whether the CellOptions are set to a valid value as noted by Figure 7. If this is not the case, a Response with code RC_ERR is returned. If the number of cells in the received CellList in node B is smaller than NumCells, node B MUST return a 6P Response with the RC_ERR_CELLLIST code. Otherwise, node B's SF verifies which of the cells in the CellList it can install in node B's schedule, following the specified CellOptions field. How that selection is done is specified in the SF and is out of scope for this document. The verification can succeed (NumCells cells from the CellList can be used), fail (none of the cells from the CellList can be used), or partially succeed (fewer than NumCells cells from the CellList can be used). In all cases, node B MUST send a 6P Response that includes a return code set to RC_SUCCESS and that specifies the list of cells that were scheduled following the CellOptions field. That list can contain NumCells elements (succeed), 0 elements (fail), or between 0 and NumCells elements (partially succeed). Upon receiving the response, node A adds the cells specified in the CellList according to the CellOptions field.

Deleting Cells

Cells are deleted by using the 6P DELETE command. The Type field (T) is set to REQUEST. The Code field is set to DELETE. Figure 12 defines the format of a 6P DELETE Request.

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Its format is the same as that in the 6P ADD command, but its content could be different.

+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata | CellOptions | NumCells | +-
CellOptions: Indicates the options that need to be associated with the cells to delete. Only cells matching the CellOptions can be deleted.

NumCells: The number of cells from the specified CellList the sender wants to delete from the schedule of both sender and receiver. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- CellOptions: Indicates the options that need to be associated with cells to be relocated.

+-+-+ |Version| T | R | Code | SFID | SeqNum | +

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata | CellOptions | NumCells | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Relocation CellList ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Candidate CellList ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

NumCells: The number of cells to relocate. MUST be greater than or equal to 1. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CellList ... +-+-+-+-+-+-+-+-+-Figure 15 CellList it can install in its schedule. How that selection is done is specified in the SF and is out of scope for this document. That verification for the Candidate CellList can succeed (NumCells cells from the Candidate CellList can be used), fail (none of the cells from the Candidate CellList can be used), or partially succeed (fewer than NumCells cells from the Candidate CellList can be used). In all cases, node B MUST send a 6P Response that includes a return code set to RC_SUCCESS and that specifies the list of cells that will be rescheduled following the CellOptions field. That list can contain NumCells elements (succeed), 0 elements (fail), or between 0 and NumCells elements (partially succeed). If N < NumCells cells appear in the CellList, this means that the first N cells in the Relocation CellList have been relocated and the remainder have not. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When receiving a LIST command, node B returns the cells scheduled with A in its schedule that match the CellOptions field as specified in Section 3.2.3.

+-+-+ |Version| T | R | Code | SFID | SeqNum | +-
When node B receives a LIST Request, the returned CellList in the 6P Response contains between 0 and MaxNumCells cells, starting from the specified offset. Node B SHOULD include as many cells as will fit in the frame. If the response contains the last cell, node B MUST set the Code field in the response to RC_EOL ("End of List", as per Figure 38 in Section 6.2.4), indicating to node A that there are no more cells that match the request. Node B MUST return at least one cell, unless the specified offset is beyond the end of B's cell list in its schedule. If node B has fewer than Offset cells that match the request, node B returns an empty CellList and a Code field set to RC_EOL. To clear the schedule between nodes A and B (for example, after a schedule inconsistency is detected), node A issues a CLEAR command. The Type field (T) is set to REQUEST. The Code field is set to CLEAR. Figure 24 defines the format of a 6P CLEAR Request.

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Its format is the same as that in the 6P ADD command, but its content could be different.

+-+-+ |Version| T | R | Code | SFID | SeqNum | +-
Figure 25 defines the format of a 6P CLEAR Response.

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

+-+-+ |Version| T | R | Code | SFID | SeqNum | +

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: 6P CLEAR Response Format

When a 6P CLEAR command is issued from node A to node B, both nodes A and B MUST remove all the cells scheduled between them. That is, node A MUST remove all the cells scheduled with node B, and node B MUST remove all the cells scheduled with node A. In a 6P CLEAR command, the SeqNum MUST NOT be checked. In particular, even if the request contains a SeqNum value that would normally cause node B to detect a schedule inconsistency, the transaction MUST NOT be aborted. Upon 6P CLEAR completion, the value of SeqNum MUST be reset to 0.

The return code sent in response to a 6P CLEAR command SHOULD be RC_SUCCESS unless the operation cannot be executed. When the CLEAR operation cannot be executed, the return code MUST be set to RC_RESET. The 6P SIGNAL message allows the SF implementations on two neighbor nodes to exchange generic commands. The payload in a received SIGNAL message is an opaque set of bytes passed unmodified to the SF. The length of the payload is determined by the Length field of the Payload IE header. How the generic SIGNAL command is used is specified by the SF and is outside the scope of this document. The Type field (T) is set to REQUEST. The Code field is set to SIGNAL. Figure 26 defines the format of a 6P SIGNAL Request.

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Its format is the same as that in the 6P ADD command, but its content could be different.

+-+-+ |Version| T | R | Code | SFID | SeqNum | +-
Figure 27 defines the format of a 6P SIGNAL Response.

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ supported by all future versions of the protocol. This ensures that when node B sends a 6P Response to node A indicating that it does not implement the 6P version in the 6P Request, node A can successfully parse that response.

When a node supports a version number received in a 6P Request message, the Version field in the 6P Response MUST be the same as the Version field in the corresponding 6P Request. Similarly, in a 3-step transaction, the Version field in the 6P Confirmation MUST match that of the 6P Request and 6P Response of the same transaction.

SFID Checking

All messages contain an SFID field. A node MAY support multiple SFs at the same time. When receiving a 6P message with an unsupported SFID, a node MUST reply with a 6P Response with a return code of RC_ERR_SFID. The SFID field in the 6P Response MUST be the same as the SFID field in the corresponding 6P Request. In a 3-step transaction, the SFID field in the 6P Confirmation MUST match that of the 6P Request and the 6P Response of the same transaction.

Concurrent 6P Transactions

Only a single 6P Transaction at a time in a given direction can take place between two neighbors. That is, a node MUST NOT issue a new 6P Request to a given neighbor before the previous 6P Transaction it initiated has finished (or possibly timed out). If a node receives a 6P Request from a given neighbor before having sent the 6P Response to the previous 6P Request from that neighbor, it MUST send back a 6P Response with a return code of RC_RESET (as per Figure 38 in Section 6.2.4) and discard this ongoing second transaction. A node receiving a RC_RESET code MUST abort the second transaction and treat it as though it never happened (i.e., reverting changes to the schedule or SeqNum done by this transaction).

Nodes A and B MAY support having two transactions going on at the same time, one in each direction. Similarly, a node MAY support concurrent 6P Transactions with different neighbors. In this case, the cells involved in an ongoing 6P Transaction MUST be "locked" until the transaction finishes. For example, in Figure 1 The SeqNum MUST be implemented as a lollipop counter: it rolls over from 0xFF to 0x01 (not to 0x00). This is used to detect a neighbor reset. Figure 28 lists the possible values of the SeqNum. ----------+------------------------------ In both cases, node B detects the inconsistency.

+-----------+------------------------------+ | Value | Meaning | +-----------+------------------------------+ | 0x00 |
If the inconsistency is detected during a 6P Transaction (Figure 31), the node that has detected it MUST send back a 6P Response or 6P Confirmation with an error code of RC_ERR_SEQNUM. In this 6P Response or 6P Confirmation, the SeqNum field MUST be set to the value of the sender of the message (0 in the example in Figure 31). ). 6P benefits from the same level of security as any other Payload IE. 6P does not define its own security mechanisms. In particular, although a key management solution is out of scope for this document, 6P will benefit from the key management solution used in the network. This is relevant, as security attacks such as forgery and misattribution attacks become more damaging when a single key is shared amongst a group of more than two participants.

6P does not provide protection against DoS attacks. Example attacks include not sending confirmation messages in 3-step transactions and sending incorrectly formatted requests. These cases SHOULD be handled by an appropriate policy, such as rate-limiting or time-limited blacklisting of the attacker after several attempts. The effect on the overall network is mostly localized to the two nodes in question, as communication happens in dedicated cells. This section defines subregistries within the "IPv6 Over the TSCH Mode of IEEE 802.15.4e (6TiSCH)" parameters registry, hereafter referred to as the "6TiSCH parameters" registry. Each subregistry is described in a subsection.

6P Version Numbers

The name of the subregistry is "6P Version Numbers".

The following note is included in this registry: "In the 6top Protocol (6P) [RFC8480], there is a field to identify the version of the protocol. This field is 4 bits in size." The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [START_REF] Cotton | Guidelines for Writing an IANA Considerations Section in RFCs[END_REF]. Wang, et

Wang

Figure 1 :

 1 Figure 1: A Simple 6TiSCH Network

Figure 2 :

 2 Figure 2: 6top in the Protocol Stack

Figure 3 :

 3 Figure 3: 2-Slotframe Structure when Using 6P alongside the Minimal 6TiSCH Configuration

Figure 5 Figure

 5 Figure5shows an example 3-step 6P Transaction. In a 3-step transaction, node B selects the candidate cells. Several elements are left out so that the diagram is easier to understand.

Figure 6 :

 6 Figure 6: Generic 6P Message Format

  the 6P CellOptions bitmap applies to all elements in the CellList field. The possible values of the 6P CellOptions are as follows: o TX = 1 (resp. 0) refers to macTxType = TRUE (resp. FALSE) in the macLinkTable of 802.15.4 [IEEE802154]. o RX = 1 (resp. 0) refers to macRxType = TRUE (resp. FALSE) in the macLinkTable of 802.15.4. o S = 1 (resp. 0) refers to macSharedType = TRUE (resp. FALSE) in the macLinkTable of 802.15.4.

  + |TX=1,RX=0,S=0| Add/delete/relocate RX cells at B (TX cells at A) | +-

  + |TX=0,RX=1,S=0| Add/delete/relocate TX cells at B (RX cells at A) | +-

  + |TX=1,RX=1,S=0| Add/delete/relocate TX|RX cells at B (and at A) | +-

  + |TX=1,RX=0,S=1| Add/delete/relocate RX|SHARED cells at B | | | (TX|SHARED cells at A) | +-

  + |TX=1,RX=1,S=1| Add/delete/relocate TX|RX|SHARED cells at B | | | (and at A) | +-

+Figure 7 :

 7 Figure 7: Meaning of the 6P CellOptions Bitmap for the 6P ADD, DELETE, and RELOCATE Requests

  The type of cells B selects from its schedule when | | Value | receiving a 6P COUNT or LIST Request from A, | | | from all the cells B has scheduled with A | +-

  + |TX=1,RX=0,S=0| All cells marked as RX only | +-

  + |TX=0,RX=1,S=0| All cells marked as TX only | +-

  + |TX=1,RX=1,S=0| All cells marked as TX and RX only | +-

  + |TX=0,RX=0,S=1| All cells marked as SHARED (regardless of TX, RX) | +-

  + |TX=1,RX=0,S=1| All cells marked as RX and SHARED only | +-

  + |TX=0,RX=1,S=1| All cells marked as TX and SHARED only | +-

Figure 8 :

 8 Figure 8: Meaning of the 6P CellOptions Bitmap for the 6P COUNT and LIST Requests

Figure 9 :

 9 Figure 9: 6P Cell Format

Figure 10 :

 10 Figure 10: 6P ADD Request Format

  Figure 12: 6P DELETE Request Format

  Figure 13 defines the format of a 6P DELETE Response and Confirmation.

Figure 14 :

 14 Figure 14: 6P RELOCATE Request Format

Wang

  Figure 17: Example of a Partially Successful 2-Step 6P RELOCATE Transaction

Figure 18 :

 18 Figure 18: Failed 2-Step 6P RELOCATE Transaction Example

  Figure 23: 6P LIST Response Format

  Figure 24: 6P CLEAR Request Format

  Figure 26: 6P SIGNAL Request Format

  Figure 27: 6P SIGNAL Response Format

  Clear, or after device reset | | 0x01-0xFF | Lollipop counter values | +-

o

  SHOULD contain a list of current implementations, at least during the Internet-Draft (I-D) state of the document, per [RFC7942]. Wang, et al. a performance evaluation of the scheme, possibly through references to external documents. o SHOULD define the format of the SIGNAL command payload and its use. o MAY redefine the format of the CellList field. o MAY redefine the format of the CellOptions field. o MAY redefine the meaning of the CellOptions field. 5. Security Considerations 6P messages are carried inside 802.15.4 Payload Information Elements (IEs). Those Payload IEs are encrypted and authenticated at the link layer through CCM* [CCM-Star] ("CCM" stands for "Cipher block Chaining --Message authentication code"

Wang

  Figure 34: IETF IE Subtype SUBID_6TOP

  Figure 35: 6P Version Number Entry

  , 6top is the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control (MAC) layer [IEEE802154]. We use "802.15.4" as a short version of "IEEE Std 802.15.4" in this document.

		.
	|	.	|
	|	higher layers	|
	+-

  The Code field contains a 6P command identifier when the 6P message has a Type value of REQUEST. Section 6.2.3 lists the 6P command identifiers. The Code field contains a 6P return code when the 6P message has a Type value of RESPONSE or CONFIRMATION. Section 6.2.4 lists the 6P return codes. The same return codes are used in both 6P Response and 6P Confirmation messages. 6top Scheduling Function Identifier (SFID): The identifier of the SF to use to handle this message. The SFID is defined in Section 4.1. SeqNum: The sequence number associated with the 6P Transaction. Used to match the 6P Request, 6P Response, and 6P Confirmation of the same 6P Transaction. The value of SeqNum MUST be different for each new 6P Request issued to the same neighbor and using the same SF. The SeqNum is also used to ensure consistency between the schedules of the two neighbors. Section 3.4.6 details how the SeqNum is managed.

	RFC 8480	6top Protocol (6P)	November 2018
	Code:
	Wang, et al.	Standards Track	[Page 12]

Other Fields: The list of other fields and how they are used are detailed in Section 3.3. 6P Request, 6P Response, and 6P Confirmation messages for a given transaction MUST share the same Version, SFID, and SeqNum values. Future versions of the 6P message SHOULD maintain the format of the 6P Version, Type, and Code fields for backward compatibility. 3.2.3. 6P CellOptions An 8-bit 6P CellOptions bitmap is present in the following 6P Requests: ADD, DELETE, COUNT, LIST, and RELOCATE. The format and meaning of this field MAY be redefined by the SF; the routine that parses this field is therefore associated with a specific SF. o In the 6P ADD Request, the 6P CellOptions bitmap is used to specify what type of cell to add. o In the 6P DELETE Request, the 6P CellOptions bitmap is used to specify what type of cell to delete. o In the 6P RELOCATE Request, the 6P CellOptions bitmap is used to specify what type of cell to relocate. o In the 6P COUNT and LIST Requests, the 6P CellOptions bitmap is used as a selector of a particular type of cells. Wang, et al. Standards Track [Page 13]

  : 6P RELOCATE Response and Confirmation Format CellList: A list of zero or more 6P Cells. Node A's SF wants to relocate NumCells cells. Node A creates a 6P RELOCATE Request and indicates the cells it wants to relocate in the Relocation CellList. It also selects NumCandidate cells from its schedule as candidate cells to relocate the cells to, and it puts them in the Candidate CellList. The CellOptions field specifies the type of the cell(s) to relocate. NumCandidate MUST be greater than or equal to NumCells. How many cells it selects (NumCandidate) and how that selection is done are specified in the SF and are out of scope for this document. Node A sends the 6P RELOCATE Request to node B. Upon receiving the request, node B checks to see if the length of the Candidate CellList is greater than or equal to NumCells. Node B's SF verifies that all the cells in the Relocation CellList are scheduled with node A and are associated with the options specified in the CellOptions field. If either check fails, node B MUST send a 6P Response to node A with return code RC_ERR_CELLLIST. If both checks pass, node B's SF verifies which of the cells in the Candidate

  When a timeout occurs, the transaction MUST be canceled at the node where the timeout occurs. The value of the 6P Timeout should be greater than the longest possible time it takes to receive the 6P Response or Confirmation. The value of the 6P Timeout hence depends on the number of cells scheduled between the neighbor nodes, the maximum number of link-layer retransmissions, etc. The SF MUST determine the value of the timeout. The value of the timeout is out of scope for this document.

	RFC 8480 RFC 8480	6top Protocol (6P) 6top Protocol (6P)	November 2018 November 2018
	3.4.4. 6P Timeout Specifically, if node A receives the link-layer acknowledgment for
	its 6P Request, it will increment the SeqNum by exactly 1 after the
	A timeout occurs when the node that successfully sent a 6P Request 6P Transaction ends. This ensures that, for the next 6P Transaction
	does not receive the corresponding 6P Response within an amount of where it sends a 6P Request, the 6P Request will have a different
	time specified by the SF. In a 3-step transaction, a timeout also SeqNum.
	occurs when a node sending the 6P Response does not receive a 6P
	Similarly, node B increments the SeqNum by exactly 1 after having received the link-layer acknowledgment for the 6P Response (2-step 6P Transaction) or after having sent the link-layer acknowledgment for the 6P Confirmation (3-step 6P Transaction). When node B receives a 6P Request from node A with SeqNum equal to 0, it checks the stored SeqNum for A. If A is a new neighbor, the stored SeqNum in B will be 0. The transaction can continue. If the stored SeqNum for A in B is different than 0, a potential Confirmation. 3.4.5. Aborting a 6P Transaction inconsistency is detected. In this case, B MUST return RC_ERR_SEQNUM
	with SeqNum=0. The SF of node A MAY decide what to do next, as
	If the receiver of a 6P Request fails during a 6P Transaction and is described in Section 3.4.6.2.
	unable to complete it, it SHOULD reply to that request with a 6P
	Response with return code RC_RESET. Upon receiving this 6P Response,
	the initiator of the 6P Transaction MUST consider the 6P Transaction
	as having failed.
	Similarly, in the case of a 3-step transaction, when the receiver of
	a 6P Response fails during the 6P Transaction and is unable to
	complete it, it MUST reply to that 6P Response with a 6P Confirmation
	with return code RC_RESET. Upon receiving this 6P Confirmation, the
	sender of the 6P Response MUST consider the 6P Transaction as having
	failed.
	3.4.6. SeqNum Management
	The SeqNum is the field in the 6top IE header used to match Request,
	Response, and Confirmation messages for a given transaction. The
	SeqNum is used to detect and handle duplicate commands
	(Section 3.4.6.1) and inconsistent schedules (Section 3.4.6.2). Each
	node remembers the last used SeqNum for each neighbor. That is, a
	node stores as many SeqNum values as it has neighbors. In the case
	of supporting multiple SFs at a time, a SeqNum value is maintained
	, node C can per SF and per neighbor. In the remainder of this section, we
	have a different ongoing 6P Transaction with nodes B and R. If a describe the use of SeqNum between two neighbors; the same happens
	node does not have enough resources to handle concurrent 6P for each other neighbor, independently.
	Transactions from different neighbors, it MUST reply with a 6P
	Response with return code RC_ERR_BUSY (as per Figure 38 in When a node resets, or after a CLEAR Transaction, it MUST reset
	Section 6.2.4). If the requested cells are locked, it MUST reply to SeqNum to 0. The 6P Response and 6P Confirmation for a transaction
	that request with a 6P Response with return code RC_ERR_LOCKED (as MUST use the same SeqNum value as that in the request. After every
	per Figure 38). The node receiving RC_ERR_BUSY or RC_ERR_LOCKED MAY transaction, the SeqNum MUST be incremented by exactly 1.
	implement a retry mechanism as defined by the SF.
	Wang, et al. Wang, et al.	Standards Track Standards Track	[Page 32] [Page 33]

RFC 8480 6top Protocol (6P)

November 2018

Upon receiving the response with code RC_SUCCESS, node A relocates the cells specified in the Relocation CellList of its RELOCATE Request to the new locations specified in the CellList of the 6P Response, in the same order. If the received return code is RC_ERR_CELLLIST, the transaction is aborted and no cell is relocated.

In the case of a 2-step transaction, node B relocates the selected cells upon receiving the link-layer ACK for the 6P Response. In the case of a 3-step transaction, node B relocates the selected cells upon receiving the 6P Confirmation.

The SF SHOULD NOT relocate all cells between two nodes at the same time, as this might result in the schedules of both nodes diverging significantly.

Figure 16 shows an example of a successful 2-step 6P RELOCATE Transaction. ------------------------------------->| ------------------| -------------------------------------| (1,2)->(5,3 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Its format is the same as that in the 6P ADD command, but its content could be different.

+----------+ +----------+ | Node

CellOptions: Specifies which type of cell to be counted.

Figure 21 defines the format of a 6P COUNT Response.

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Node A issues a COUNT command to node B, specifying some cell options. Upon receiving the 6P COUNT Request, node B goes through its schedule and counts the number of cells scheduled with node A in its own schedule that match the cell options in the CellOptions field of the request. Section 3.2.3 details the use of the CellOptions field.

Node B issues a 6P Response to node A with return code RC_SUCCESS and with NumCells containing the number of cells that match the request. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 Its format is the same as that in the 6P ADD command, but its content could be different.

CellOptions: Specifies which type of cell to be listed.

Reserved: Reserved bits. These bits SHOULD be set to zero when sending the message and MUST be ignored upon reception.

Offset: The offset of the first scheduled cell that is requested. The mechanism assumes that cells are ordered according to a rule defined in the SF. The rule MUST always order the cells in the same way.

MaxNumCells: The maximum number of cells to be listed. Node B MAY return fewer than MaxNumCells cells --for example, if MaxNumCells cells do not fit in the frame.

Wang, et al. ----------------- Figure 30 shows an example 3-step transaction in which node A receives an out-of-order duplicate 6P Response after having sent a 6P Confirmation. ------------------------------------- ------------------------------------ There are two cases in which a schedule inconsistency happens.

Standards Track

The first case is when a node loses state --for example, when it is power-cycled (turned off, then on). In that case, its SeqNum value is reset to 0. Since the SeqNum is a lollipop counter, its neighbor detects an inconsistency in the next 6P Transaction. This is illustrated in Figures 31 and32. ------------------------------------ ------------------ ------------------------------------ ------------------------------------- ----------------- ------------------------------------ ------------------------------------- ------------------------------------- The second case is when the maximum number of link-layer retransmissions is reached on the 6P Response of a 2-step transaction (or, equivalently, on a 6P Confirmation of a 3-step transaction). This is illustrated in Figure 33.

RFC 8480 6top Protocol (6P) November 2018

6P Message Types

The name of the subregistry is "6P Message Types".

The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a field to identify the type of message. This field is 2 bits in size."

Each entry in the subregistry must include the message type in the range b00-b11, the corresponding name, and a reference to the 6P message type's documentation.

Initial entries in this subregistry are as follows: -----+--------------+----------- -----+--------------+-----------+ Figure 36: 6P Message Types All other message types are Unassigned.

The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [START_REF] Cotton | Guidelines for Writing an IANA Considerations Section in RFCs[END_REF].

6P Command Identifiers

The name of the subregistry is "6P Command Identifiers".

The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a Code field that is 8 bits in size. In a 6P Request, the value of this Code field is used to identify the command."

Each entry in the subregistry must include an identifier in the range 0-255, the corresponding name, and a reference to the 6P command identifier's documentation. Initial entries in this subregistry are as follows: -----------+------------+----------- -----------+------------+-----------+ Figure 37: 6P Command Identifiers

The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [START_REF] Cotton | Guidelines for Writing an IANA Considerations Section in RFCs[END_REF].

6P Return Codes

The name of the subregistry is "6P Return Codes".

The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a Code field that is 8 bits in size. In a 6P Response or 6P Confirmation, the value of this Code field is used to identify the return code."

Each entry in the subregistry must include a return code in the range 0-255, the corresponding name, the corresponding description, and a reference to the 6P return code's documentation. If the return code corresponds to a Response error, the "Is Error?" entry must indicate "Yes". Otherwise, "No" must be used. -----+-----------------+---------------------------+----------- -----+-----------------+---------------------------+----------- The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [START_REF] Cotton | Guidelines for Writing an IANA Considerations Section in RFCs[END_REF].

6P Scheduling Function Identifiers

The name of the subregistry is "6P Scheduling Function Identifiers".

The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a field to identify the Scheduling Function to handle the message. This field is 8 bits in size."

Each entry in the subregistry must include an SFID in the range 0-255, the corresponding name, and a reference to the 6P Scheduling Function's documentation.

There are currently no entries in this subregistry. -----+---------------------------------+-------------------------- -----+---------------------------------+-------------------------- -----+---------------------------------+-------------------------- The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [START_REF] Cotton | Guidelines for Writing an IANA Considerations Section in RFCs[END_REF]. Wang, et

+-


Fabian Rincon

Yasuyuki Tanaka
email: yasuyuki.tanaka@inria.fr

Thomas Watteyne
email: thomas.watteyne@inria.fr

On the Impact of WiFi on 2.4 GHz Industrial IoT Networks

Keywords: IEEE802.15.4, TSCH, IEEE802.11, coexistence

Many Industrial IoT TSCH networks, such as SmartMesh IP, operate in the same 2.4 GHz frequency band as WiFi. As the smart factory becomes more and more connected, WiFi starts being rolled out on many factory floors. It is hence completely legitimate to question whether WiFi impacts Industrial IoT TSCH networks, and in particular their endto-end reliability. In a setup which replicates a worst case industrial setting, we conduct a thorough experimental study which looks at the performance of a 47-mote SmartMesh IP network undergoing several levels of WiFi interference. The result is that, even though the latency and power consumption of the network increase, end-to-end reliability stays at 100% even under very high WiFi interference. The conclusion is that TSCH technology at 2.4 GHz, such as SmartMesh IP, is perfectly appropriate to for an industrial environment where WiFi is heavily used. This paper is complemented by a research report which contains all the information needed to replicate the measurements, and the raw data.

I. INTRODUCTION

Time Synchronized Channel Hopping (TSCH) is the medium access control (MAC) mode that was added to the 2015 revision of the IEEE802.15.4 standard to "better support the industrial markets" [1]. The IETF 6TiSCH working group further defines a fully standardized protocol stack, by associating IEEE802.15.4 TSCH with an "upper stack" which includes the routing and application layers [START_REF] Watteyne | Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement, IETF Std. RFC7554[END_REF]. Other standards such as WirelessHART and ISA100.11a have defined similar TSCH-based solutions on top of IEEE802.15.4 for the industrial markets.

While the IEEE802.15.4 standard supports several frequency band, by far the most used in the TSCH context is the 2.400-2.485 GHz ISM ("Industrial Scientific and Medical") band. The main reasons for that are that (1) the band is 85 MHz wide, giving a channel hopping solution enough frequency diversity to efficiently fight external interference and multi-path fading, and (2) the band is the same wordwide, so manufacturers can make a single product rather than having to make per-region variants of their hardware/software.

TSCH networks operating at 2.4 GHz have been very successful commercially, with tens of thousands of networks Figure 1: The experimental setup replicates a factory floor on which WiFi networks are deployed alongside an Industrial IoT TSCH network. This setup is a worst case in which any WiFi impactss all parts of the TSCH network. To ensure our measurements reflect the real world, we use the commercial SmartMesh IP, the market leader in TSCH technology. operating today1 . Their applications are highly industrial, such as monitoring bearing temperature, motor current, wellheads on offshore platforms, air compressors in refineries, etc.

The question about coexistence between WiFi and TSCH is a perfectly legitimate one. First, WiFi and TSCH share the same frequency band, and since a WiFi signal covers 4 TSCH frequencies, a WiFi device transmitting can block up to 4 TSCH devices. Second, a WiFi device emits at a much higher power, overpowering a IEEE802.15.4 signal sent at the same time. This fear is confirmed in single-channel IEEE802.15.4-based solutions, such as ZigBee. Those systems typically require a site survey before deployment so the ZigBee operates on a frequency outside of the frequencies used by WiFi in that factory 2 . Third, industrial plants are evolving, with the line between the "office" and the "factory" blurring. This means that it's not unusual to see WiFi rolled out throughout a factory floor.

The goal of this paper is precisely to answer this question: Will a WiFi network deployed on a factory floor (adversely) impact the Industrial IoT TSCH network operating in the same radio space? We look at this question purely from an industrial use point of view. That is, the most important is to understand whether WiFi can alter the dependability of the network: can it cause nodes to de-synchronize and loose connectivity to the network, and/or impact the endto-end reliability of the network? As a second point, we are interested in seeing the impact of WiFi of performance metric that are typically considered secondary for process monitoring applications: end-to-end latency, battery lifetime, and network formation time.

Unlike previous work that addressed similar questions, we adopt an experimental approach. This is due to 3 considerations. First, the topic includes multiple wireless technologies, with behaviors that encompass every layer in the protocol stack, from complex phenomena in propagation, all the way to the algorithms that run on the systems. We don't believe that analysis or simulation is able to accurately capture all of those. Second, we have access to the market leading hardware and have, in practice, the means of conducting an experimental measurements campaign that uses exactly the same technology is being used throughout the Industrial IoT space. We use Analog Devices SmartMesh IP because it's the market leading TSCH commercial product with over 76,000 networks running [START_REF] Watteyne | Technical Overview of SmartMesh IP[END_REF], and because it's performance is understood and published [START_REF] Watteyne | Industrial IEEE802.15.4e Networks: Performance and Trade-offs[END_REF]. Finally, we want to ensure the validity and usefulness of our findings to a practical user, and so what to "play user" and report on down-toearth measurements with real devices.

The contribution on this paper is three-fold:

• We develop a methodology and a set of tools that ensure the repeatability of the results, and that described thoroughly both in this paper and a companion research report, and that is published under an open-source license.

• We show how the TSCH network, even under levels of WiFi interference much higher than would be seen in practice, the functionality of the TSCH network is unaffected, and that it maintains an end-to-end reliability of 100%. • We quantify the impact of WiFi on end-to-end latency, battery lifetime, and network formation time.

The remainder of this paper is organized as follows. Section II goes through the previous published work most related to this study. Section III describes the overall setup of the experiment. This description, together with the companion research report, ensure repeatability of the experiment. Section IV lists the performance metrics of the SmartMesh IP network we are monitoring during an experiment, details how they are gathered, and discusses why they are representative. Section V presents the results and discusses their importance in the context of Industrial IoT applications. Finally, Section VI summarizes this paper and lists the lessons learned.

II. RELATED WORK

This section gives the necessary background on IEEE802.15.4 and WiFi, then surveys recently published work that we believe it the most related to the study presented in this paper. Our focus in our work that relates to evaluating the robustness of an IEEE802.15.4-based network against interference from other networks, in parciular WiFi.

The IEEE802.15.4 standard cuts the 2.4 GHz ISM band into 16 orthogonal frequencies. An IEEE802.15.4-compliant signal is 2 MHz wide; adjacent frequencies are 5 MHz apart. TSCH uses "Channel Hopping", i.e. when two neighbor nodes exchange data frames, successive frames are sent on different frequencies. Channel hopping is well known to combat external interference and multi-fading, and is therefore used in Bluetooth, some cellular systems, and all TSCH-based low-power wireless soutions [START_REF] Watteyne | Reliability Through Frequency Diversity: Why Channel Hopping Makes Sense[END_REF].

The IEEE802.11 standard (the standard promoted by the WiFi Alliance) uses the exact same 2. [START_REF] Watteyne | Industrial IEEE802.15.4e Networks: Performance and Trade-offs[END_REF] The output power of a WiFi and IEEE802.15.4 device is also quite different. To have the longest range, WiFi access points can have an output power of +23 dBm (200 mW). In comparison, to conserve battery, IEEE802.15.4 radios are typically used at 0 dBm (1 mW); Analog Devices' SmartMesh product lines are an exception as they output +8 dBm (6 mW). As a rule of thumb, the output poiwer of WiFi is roughly 100× the output power of IEEE802.15.4.

Wagh et al. [START_REF] Wagh | Performance Evaluation of IEEE 802.15.4 Protocol Under Coexistence of WiFi 802.11b[END_REF] evaluate ZigBee under WiFi traffic by simulation, using NS-2. They collect packet error rate and bit error rate values, for different distances between the WiFi access point and the ZigBee network, and for different frequency offsets between WiFi and ZigBee. They conclude that 8-m distance and 8 MHz frequency offset is a safe configuration to avoid interference by WiFi.

Lim et al. [START_REF] Lim | Dynamic Performance of IEEE 802.15.4 Devices under Persistent WiFi Traffic[END_REF] conduct a series of experiments using offthe-shelf IEEE802.15.4 and WiFi devices. They vary the physical position of the different devices, as well as the frequencies used by both technologies. They witness the WiFi interference impacting the bit errors of IEEE802.15.4, but also the fact that the CCA (Clear Channel Assessment) returns a "medium busy" reading, causing the IEEE802.15.4 devices to back off.

Wagh et al. [START_REF] Wagh | Performance Evaluation of IEEE 802.15.4 Protocol Under Coexistence of WiFi 802.11b[END_REF] and Lim et al. [START_REF] Lim | Dynamic Performance of IEEE 802.15.4 Devices under Persistent WiFi Traffic[END_REF] discuss how some coordination between WiFi networks and IEEE802.15.4 networks is needed to make the latter perform well. We believe that this option is not realistic as background network activities dynamically change, and because one cannot always have full control over all the wireless networks at a deployment site. Measurements by Marcoen et al. [START_REF] Marcoen | On the Performance of 802.15.4e in the Real World[END_REF] support this case. They conduct measurements in an office and in a home with two IEEE802.15.4 radio devices. Their results show interference level varying over time, even on the same channel.

The works above all focus on single-channel IEEE802.15.4 technolgies such as ZigBee. The more recent TSCH [1] mode of the same standard is, however, very different.

Vigelm et al. [START_REF] Vilgelm | Time Slotted Channel Hopping for Smart Metering: Measurements and Analysis of Medium Access[END_REF] evaluate TSCH performance with Open-WSN 3 running on Zolertia Z1 devices, with WiFi background traffic. In one of their three interference scenarios, heavy traffic is generated over two WiFi channels: 1 and 5.

The results shows that the mean end-to-end packet delivery ratio is 90% or more, even under heavy WiFi traffic when application traffic is low.

Experiments by Gursu et al. [START_REF] Gursu | Reliable co-existence of 802.15.4e TSCH-based WSN and Wi-Fi in an Aircraft Cabin[END_REF] also show that the channel hopping nature of TSCH is efficient at combating WiFi interference. In their experiments, three WiFi APs operate on three channels: 1, 5, and 11.

Another insight given by Vilgel et al. [START_REF] Vilgelm | Time Slotted Channel Hopping for Smart Metering: Measurements and Analysis of Medium Access[END_REF] and Gursu et al. [START_REF] Gursu | Reliable co-existence of 802.15.4e TSCH-based WSN and Wi-Fi in an Aircraft Cabin[END_REF] is that TSCH could perform better than what they show in terms of end-to-end reliability and latency. The key is the TSCH schedule. Because TSCH operates in a deterministic manner, network nodes need to know when they can transmit a frame and when they should listen for an incoming frame. TSCH performance depends heavily on the schedule being used [START_REF] Alves | IEEE 802.15.4e TSCH Mode Performance Analysis[END_REF].

Previously published related work on the impact of WiFi on TSCH networks is sparse, and focuses only on academic and canonical settings, in particular in terms of TSCH schedule, number of nodes, and thoroughness of the experiment. We believe that there is a real need, from an end-user point of view, to have a study that shows the impcat of WiFi on a real commercial TSCH implementation. This paper contributes to answering that need.

III. EXPERIMENTAL SETUP

The driving requirements of the experimental setup are (1) we want to use equipment which matches what is being used 3 A reference open-source 6TiSCH implementation, http://www. openwsn.org/ in the Industrial IoT, (2) we want to have full control over the WiFi interference, i.e. deploying in a building where there is WiFi is not enough, and (3) we want to create a worst case scenario in which any WiFi signal impacts the entire SmartMesh IP network.

To satisfy requirement (1), we use SmartMesh IP devices (see Section III-A). To satisfy requirement (2), the experiment takes place in an underground parking lot at the Inria-Paris research center. No WiFi infrastructure is deployed in that space, giving us full control over the WiFi interference we generate during the experiment. To satisfy requirement (3), the devices are all co-located on a cart to create a worstcase situation in which WiFi traffic from any WiFi router impacts all nodes in the SmartMesh IP network.

In this section, we explain the hardware, the system configuration, and the scenarios used in our experimental study. The experimental setup is thoroughly explained in the companion research report to this publication [START_REF] Rincón | Experimental Study on the Coexistence between SmartMesh IP and WiFi[END_REF].

A. Hardware 1) Motes: We use 47 DC9025 prototypes motes, by Analog Devices. At the heart of this mote is an LTP5902 module 4 , which itself contains the LTC5800 System-on-Chip (ARM Cortex-M3, IEEE802.15.4-compliant radio). The DC9025 mote further features an MMCX antenna connector, an external whip antenna, a holder for two AA batteries, and a plastic enclosure. Fig. 2b shows the DC9025 mote with the cover of the plastic enclosure removed.

The motes run the unmodified default SmartMesh IP firmware.

2) Manager: We use the DC2274 SmartMesh IP manager 5 . This manager features the same LTP5902 module as on the mote, but running the embedded manager firmware, and a USB connection to access its serial ports. Fig. 2a shows the DC2274 SmartMesh IP manager.

3) WiFi interference: To generate the WiFi interference, we use three tp-link TL-WR841N WiFi routers, and 7 Raspberry Pi 3 Model B+ single board computers.

B. System Configuration

The experiment consists of a SmartMesh IP network undergoing WiFi interference, as depicted in Fig. 1.

The SmartMesh IP network is composed of 1 manager and 47 motes. The motes send a data packet to the manager every 30 s, and a health report each 5 min. The manager is connected over USB to the master Raspberry Pi. The master Raspberry Pi asks the manager for a snapshot of the network every 15 min. All this data is stored on the master Raspberry Pi in log files.

To create the WiFi interference, we use 3 routers whose power supply is controlled by the master Raspberry Pi using a relay. We are turn any WiFi route on or off programmatically. Each WiFi network operates on a different frequency. We choose WiFi channels 1 (2.401-2.423 GHz), 6 (2.426-2.448 GHz), and 11 (2.451-2.473 GHz) which are orthogonal to one another, and generate interference over the entire 2.4 GHz ISM band. This combination of WiFi channels is commonplace in commercial deployments.

To generate WiFi traffic, we use two slave Raspberry Pi boards per router, and have those continuously exchange a file using Secure Copy Protocol (SCP). SCP allows us to control the maximum data transfer rate, which impacts the amount of interference generated. The transmitting Raspberry Pi is connected by Ethernet to the router, the receiving Raspberry Pi is connected over WiFi. The transmitting Raspberry Pi starts the file transfer process: the data is sent to the router over Ethernet, then from the router to the receiving Raspberry Pi over WiFi.

These operations are orchestrated by the master Raspberry Pi which issues commands over SSH on all slave Raspberry Pi's.

C. Scenarios

We collect the metrics listed in Section IV under different levels of WiFi interference.

The power supply of each WiFi router is controlled through a series of relays by the master Raspberry Pi. We can hence hence have 0, 1, 2 or 3 WiFi routers operating. Having a router at all, even without any active traffic, already generates interference as the router sends WiFi beacons every 100 ms. http://www.analog.com/en/design-center/ evaluation-hardware-and-software/evaluation-boards-kits/dc2274a-a.html Once a router is running, we use the two slave Raspberry Pi's attached to it to exchange data. That exchange can be done at several rates, resulting in more or less interference. We use 3 exchange rates: 0 MBps (no transfer, i.e. only the router is running), 1.5 MBps and 3.0 MBps. This results in 10 configurations, summarized in Table I.

IV. PERFORMANCE METRICS

To quantify the impact of WiFi interference, we monitor the performance metrics of the SmartMesh IP network that undergoes that interference. The key metrics are the average end-to-end latency, the link layer stability and the end-toend reliability. We also monitor the battery lifetime, the average link stability per channel, the network formation time.

All of these metrics are gathered and published by the SmartMesh IP network, through a combination of health reports sent by the motes, and the snapshots taken at the manager. These metrics can hence be extracted from the log files gathered by the master Raspberry Pi. The remainder of this section details how.

The average end-to-end latency, average link layer stability and end-to-end reliability are automatically gathered by the SmartMesh IP manager. The master Raspberry Pi, as part of its snapshot, issues a getNetworkInfo command every 15 min, to extract those metrics from the SmartMesh IP manager, into the log file.

We compute the battery lifetime from the charge the motes report every 15 min in their device health report. That charge is reported in milli-coulombs (mC). Then use (1) to turn that charge into a battery lifetime, where BC is the battery charge in mAh, ED is the experiment duration in seconds, and C is the charge consumed by the mote in mC. We assume the mote is powered by a pair of 1.5 V AA batteries, holding 2200 mAh of charge.

lif etime(years) = BC • ED C • 1 24 • 365 (1)
To compute the average link stability per channel, we use the extended health report each mote published every 15 min. This contains the number of transmission attempts and the number of transmission failures over the last 15 min, for each neighbor, for each channel. We use (2) to compute link stability 6 .

stability = 1 -transmission attempts transmission f ailures (2)

To observe the network formation time of each mote, we timestamp when the experiment starts, and when each of the motes joins the network. The start of the experiment is when the manager is reset. A mote has joined the network when the manager publishes an eventMoteOperational notification.

V. EXPERIMENTAL RESULTS

We run the network for 9.5 h for each of the configurations in Table I. At each configuration, the SmartMesh IP network completely re-builds. The resulting network is very shallow (mostly 1-hop, with sometimes as 2-hop transmission), as all nodes are co-located.

A. Link Stability

We use the terms link stability and packet delivery ratio interchangeably, to refer to the portion of frames sent from mote to its neighbor that are successfully acknowledged. The link stability only depends on the WiFi interference, and does not reflect in any way the performance of the SmartMesh IP network. It is, however, a good metric to quantify the impact of WiFi interference on the physical layer.

In Fig. 3, we plot the link stability per frequency. We confirm that, when only one router is on (the "1 WiFi" cases) only IEEE802.15.4 channels 11-14 are affected. When adding more WiFi routers (each operating on a different frequency), more IEEE802.15.4 channels are affected. Second, we see that a data transfer at 3 MBps can lower the link stability down to 40% on the frequencies the WiFi activity goes on. As a point of comparison, Brun-Laguna et al.measure the link stability in an office building in which WiFi is heavily used, and the average link stability is never below 85%, on any frequency [START_REF] Brun-Laguna | Using SmartMesh IP in Smart Agriculture and Smart Building Applications[END_REF]. The maximum level of WiFi interference generated in our experiments is far more than what a TSCH network would experience in a typical WiFi-savvy environment.

Fig. 3 shows that the setup we have chosen results in WiFi interference that does impact the IEEE802.15.4 links, and that does so far more than the typical impact one would see in an office building.

Fig. 4 shows link-layer stability, but averaged over all channels. The result is perhaps more readable than Fig. 3. The green dot in Fig. 4 represents the link-layer stability with no WiFi router on. That average is 96%, which is expected 7 . The average link-layer stability decreases both 6 The terms "link stability" and "packet delivery ratio (PDR)" can be used interchangeably. 7 Multi-path fading explains that this isn't 100% with the number of WiFi routers on, and with the amount of traffic on those WiFi networks. The worst average linklayer stability is 51%.

B. Average End-to-End Latency

The fact that the link-layer stability isn't 100% means that a node sometimes needs to link-layer retry a frame for it to be successfully received. Retrying takes time, so we expect the average end-to-end latency to increase with the level of WiFi interference. Fig. 5 shows this average end-toend latency, measured on the SmartMesh IP network. As a baseline, without WiFi interference, the end-to-end latency is 700 ms. This value can be decreased or decreased by changing the configuration of the network (see [START_REF] Watteyne | Industrial IEEE802.15.4e Networks: Performance and Trade-offs[END_REF] for an in-depth discussion). In this paper we use it as a baseline and don't look at its actual value.

As expected, the average latency increases with the level of WiFi interence, up to 2.2 s.

C. Battery Lifetime

We compute the battery lifetime indirectly by gathering the average current draw of the nodes after the 9.5 h of the experiment, then compute the expected lifetime assuming (1) the motes are powered by a 2,200 mAh 2×AA battery pack, and (2) that the batteries are a perfect bucket of charge. Both these assumptions can be challenged, and, given the fact that only one experiment is conducted for each WiFi interference level, the results only indicate general trends.

We plot the battery lifetime in two ways. Fig. 6 shows the distribution of battery life for each level of WiFi As the link layer stability decreases, the number of retransmissions increases, which necessary increases the energy consumption of the motes. The mean battery lifetime for all levels is between 6 and 7 years, and while the impact of WiFi interference is visible, it is minimal. Fig. 7 plots the network lifetime, i.e. the time until the first mote depletes its battery. Fig. 7 corresponds to the "min" values of Fig. 6, i.e. the bottom of the whiskers.

D. End-to-End Reliability

We define end-to-end reliability as the portion of the data packets generated by the motes that reach the manager. SmartMesh IP announces end-to-end reliability above 99.999%, the "five nines" rule which is used across the industrial networking domain.

Fig. 8 shows end-to-end reliability measured in our experiment. In all cases, end-to-end reliability is 100%, not a single packets is lost. This holds even with the highest level of interference where the average link-layer stability is as low as 51%, and which the SmartMesh IP stack compensates for through more link-layer retransmissions.

This result is of utmost importance for industrial applications, for which any data packet lost could result in factory

0 W i F i -0 M B p s 1 W i F i -0 M B p s 1 W i F i -1 . 5 M B p s 1 W i F i -3 M B p s 2 W i F i -0 M B p s 2 W i F i -1 . 5 M B p s 2 W i F i -3 M B p s 3 W i F i -0 M B p s 3 W i F i -1 . 5 M B p s 3 W i F i -3 M B p s

E. Network Formation Time

All TSCH networks today have a similar join procedure. A new node starts by listening for beacon frames sent by nodes already in the network, synchronizes to the network, and performs a security handshake with a security manager which is usually running next to the gateway of the network. The same general procedure is shared by WirelessHART. ISA100.11a and 6TiSCH.

In our experimental setup, all nodes are running and try to join the network at the same time as soon as the manager is switch on. This creates congestion, which results in a backoff mechanism in to resolve the congestion between the different security handshake. WiFi interference indirectly causes the network formation time to increase, because it decreases the link layer which in turn increases the retransmission and overall congestion.

We witness this is Fig. 9, which shows how the portion of joined nodes increases as time elapses after the manager has been switched on. Without interference, the 47 mote network forms in roughly 7 min. At very high WiFi interference, the network perfectly forms, only it takes close to 25 min.

VI. CONCLUSIONS

SmartMesh IP and WiFi both operate in the 2.4 GHz ISM frequency band. This paper reports on a thorough experimental study which looks at the performance of a 47-mote SmartMesh IP network undergoing several levels of WiFi interference. The result is that the latency, power consumption and formation time of the SmartMesh IP network only very slightly increase even under very high WiFi interference, without any effect on the 100% end-to-end reliability or overall function of the network. The conclusion is that TSCH technology at 2.4 GHz, and SmartMesh IP in particular, are perfectly appropriate to the used in an environment where WiFi is heavily used.

  (a) DC2274 SmartMesh IP manager (b) DC9025 SmartMesh IP mote

Figure 2 :

 2 Figure 2: In the experiment, we use one DC2274 SmartMesh IP manager and 47 DC9025 SmartMesh IP motes.

Figure 3 :Figure 4 :

 34 Figure3: Plotting the link stability as a function of channel clearly shows the frequency band each WiFi router interferes with. We also see that, the worst case WiFi interference is far heavier than what is typically seen in a office environment[START_REF] Brun-Laguna | Using SmartMesh IP in Smart Agriculture and Smart Building Applications[END_REF].

Figure 5 :

 5 Figure 5: Because WiFi causes nodes to have to retransmit link-layer frames, an increase in WiFi interference causes the end-to-end latency to increase.

Figure 6 :

 6 Figure6: Battery lifetime distribution of all motes. Whiskers show the min/max lifetime, the box the standard deviation around the average lifetime. Battery lifetime for all levels is between 6 and 7 years, and while the impact of WiFi interference is visible, it is minimal.

Figure 7 :

 7 Figure 7: Because WiFi causes nodes to retransmit link-layer frames, they consume more, and the motes' battery lifetime decreases.

Figure 8 :

 8 Figure 8: Even under extreme levels of WiFi interference, the end-to-end reliability of the SmartMesh IP network remains at 100%. Not a single packet is lost in any of the 10 experiments.

Figure 9 :

 9 Figure 9: Network formation time.

Table I :

 I The 10 configurations used in the experiment, giving us several levels of WiFi interference of 3 WiFi channels.

	# WiFi channel 1 WiFi channel 6 WiFi channel 11
		(2.412 GHz)	(2.437 GHz)	(2.462 GHz)
	1	off	off	off
	2	0 MBps	off	off
	3	1.5 MBps	off	off
	4	3.0 MBps	off	off
	5	0 MBps	0 MBps	off
	6	1.5 MBps	1.5 MBps	off
	7	3.0 MBps	3.0 MBps	off
	8	0 MBps	0 MBps	0 MBps
	9	1.5 MBps	1.5 MBps	1.5 MBps
	10	3.0 MBps	3.0 MBps	3.0 MBps

One vendor alone, Emerson, announces over 39,000 networks sold, which translates into over 12 Billion operating hours. https: //www.emerson.com/en-us/expertise/automation/industrial-internet-things/ pervasive-sensing-solutions/wireless-technology

Typical ZigBee networks are configured to operate on IEEE802.15.4 channel 26 (2.480 GHz), which is usually not used by WiFi.

http://www.analog.com/media/en/technical-documentation/data-sheets/

59012ipmfa.pdf


Jonathan Muñoz
email: jonathan.munoz@inria.fr

Paul Muhlethaler
email: paul.muhlethaler@inria.fr

Xavier Vilajosana
email: xvilajosana@uoc.edu

Thomas Watteyne
email: thomas.watteyne@inria.fr

Why Channel Hopping Makes Sense, even with IEEE802.15.4 OFDM at 2.4 GHz

Keywords: IoT Enabling Technologies, IoT Protocols and Standards, Ultra-low power IoT Technologies, Industrial IoT and Factory of Things, OFDM

Since its 2015 revision, IEEE802.15.4 now supports the OFDM physical layer at 2.4 GHz, on top of the popular O-QPSK modulation. Chips capable of both O-QPSK and OFDM are currently available . The question now is whether OFDM is relevant for low-power wireless mesh networking; given its prevalence in 4G cellular, it could be a game-changer. We start by collecting a comprehensive connectivity dataset, 141,587,000 data points, continuously over 21 days. We then show, in an entirely counter-intuitive manner, that OFDM alone is not enough to cope with external interference and multi-path fading, and we recommend combining OFDM with channel hopping at the link layer. In the presence of WiFi interference, we further recommend using OFDM option 1 MCS3, a fast 800 kbps mode, which does not use frequency repetition, even though the latter is meant to increase frequency diversity.

I. INTRODUCTION

Due to their ease of deployment and low cost, low power wireless mesh networks have become a connectivity solution for commercial, industrial, governmental, urban and personal applications.

The preferred standard for those wireless networks is IEEE802.15.4. It defines the physical (PHY) and Medium Access Control (MAC) layers. While the initial 2003 version of the standard only included O-QPSK (Offset Quadrature Phase-Shift Keying), the latest 2015 version has added OFDM (Orthogonal Frequency Division Multiplexing). This might be a game-changer for low-power wireless, as OFDM promised longer range and high data rates, provided, that is, OFDM is capable of coping with external interference and multi-path fading.

This paper contributes to analyzing the relevance of OFDM for low-power wireless applications. We base our analysis on a comprehensive connectivity dataset, 141,587,000 points, collected continuously over 21 days. Entirely counter-intuitively, we show that OFDM is actually prone to external interference and multi-path fading in a very similar way to O-QPSK. We therefore recommend combining OFDM with channel hopping at the link layer. Because of external interference, we further recommend Figure 1: A test node consists of a Raspberry Pi driving an AT86RF215, capable of both O-PSK and OFDM at 2.4 GHz. using fast communication (in particular OFDM option 1 MCS3), without frequency repetition, even when the latter appears to be, on paper, beneficial.

The remainder of this paper is organized as follows. Section II presents an overview of IEEE802.15.4 O-QPSK and OFDM. Section III enumerates the contributions of this paper. Section IV provides the details of the experimental setup. Section V analyzes the results and gives the lessons learned from this dataset. Finally, Section VI concludes this paper.

II. OVERVIEW AND RELATED WORK

The IEEE802.15. [START_REF] Watteyne | Lessons Learned from Large-scale Dense IEEE802.15.4 Connectivity Traces[END_REF] The latest 2015 version of this standard adds the OFDM (Orthogonal Frequency Division Multiplexing) PHY layer at 2.4 GHz. OFDM is a more recent technique than O-QPSK, borrowed from much more powerful networks such as 4G cellular. It is designed to combat multi-path fading at the PHY layer, something O-QPSK does not do. Fig. 2 shows how O-QPSK and OFDM channelize the same 2.4 GHz frequency band.

OFDM has 4 ways of grouping sub-carriers to form an OFDM symbol; they are called "options". In this paper, we are interested in option 1, as it allows the highest data rate (and in particular data rates higher than O-QPSK). In OFDM option 1, each channel is composed of 104 subcarriers, each modulated independently. This means that a frame is actually composed of dozens of signals, all at a slightly different frequency within the channel. The idea is that multi-path fading and external interference only affect a portion of the sub-carriers. Smart inter-subcarrier coding compensates for that, resulting in a higher Packet Delivery Ratio (PDR) between neighbors.

Each sub-carrier is modulated. OFDM option 1 defines 2 sub-carrier modulations. It also defines the use of "frequency repetition", in which the same information is encoded onto multiple sub-carriers. The combination of modulation and level of frequency repetition is called Modulation and Coding Scheme (MCS). In this paper, we look at the MCS settings which yield the highest and lowest data rates: MCS0 and MCS3. Table I summarizes the MCS settings explored in this paper.

Wireless is unreliable by its very nature. In low-power wireless, the two phenomena that most impact the reliability of wireless links are external interference and multi-path fading.

The effect of external interferences on IEEE802.15.4 is well studied. Khaleel et al. [START_REF] Khaleel | Impact of Wi-Fi Traffic on the IEEE 802.15.4 Channels Occupation in Indoor Environments[END_REF] study the interference between IEEE802.15.4 and IEEE802.11b WiFi. By using the RSSI indicator, they sense the frequency spectrum under different WiFi data rate conditions. They conclude that, under the range of a WiFi connection of 3 Mbit/s and operating at the same frequency, an IEEE802.15.4 device is not capable of successfully accessing the medium up to 90% of the time.

Guo et al. [START_REF] Guo | Impacts of 2.4-GHz ISM Band Interference on IEEE 802.15.4 Wireless Sensor Network Reliability in Buildings[END_REF] analyze how different Interference Sources increment the Packet Error Rate for IEEE80.15.4 radio links. With combinations of Interference Source (None, WiFi, Bluetooth and Microwave), distance between TX and RX, distance between IS and RX, position of IS in relation to TX-RX and IEEE802.15.4 channel; the authors observed that WiFi and microwave ovens can degrade the quality of the radio links, causing a 25% PER depending of the distances between TX, RX, IS and as well as the chosen channel.

In order to better understand the impact WiFi net-works have on IEEE802.15.4 networks, Watteyne et al. [START_REF] Watteyne | Lessons Learned from Large-scale Dense IEEE802.15.4 Connectivity Traces[END_REF] record the connectivity between 350 nodes on the IoT-lab testbed [START_REF] Adjih | FIT IoT-LAB: A Large Scale Open Experimental IoT Testbed[END_REF], located in an office building with WiFi networks around. Nodes communicate on the 16 frequencies defined in the O-QPSK PHY. The authors show that WiFi beacons (including when the WiFi network sits idle) hamper the connectivity on a considerable number of IEEE802.15.4 links, causing a drop in their PDR from 90% to 70-80%. Watteyne et al. [START_REF] Watteyne | Mitigating Multipath Fading through Channel Hopping in Wireless Sensor Networks[END_REF] observe how multi-path fading affects wireless communication. They have a node transmit frames from a robotic arm that changes its position by steps of 1 cm inside a 20 cm × 35 cm area. In total, the arm goes over to 735 positions, with the transmitter node sending 1,000 frames of 29 B at each position to a receiver node located 5 m away. This experiment is performed 16 times, one for each IEEE802.15.4 O-QPSK frequency at 2.4 GHz. The results show that moving the transmitter node by 3 cm can make the PDR of the wireless link to go from 100% to 0%.

Time Synchronized Channel Hopping (TSCH) deals with external interference and multi-path fading at the Medium Access Control (MAC) layer. When two neighbor nodes exchange frames, they send subsequent frames at different frequencies, resulting in channel hopping. The idea is that, if external interference or multi-path fading causes the transmission of a frame to fail, the retransmission happens at a different frequency, and therefore has a higher chance of succeeding than if retransmitted on the same frequency.

The IETF 6TiSCH working group standardizes how to combine TSCH with IPv6. Watteyne et al. [START_REF] Watteyne | Industrial IEEE802.15.4e Networks: Performance and Trade-offs[END_REF] show the performance on a commercial TSCH solution, SmartMesh IP, providing over 99.999% end-to-end reliability with over 10 years of battery lifetime. TSCH and 6TiSCH networks are considered the future of low power wireless [START_REF] Watteyne | Industrial Wireless IP-Based Cyber -Physical Systems[END_REF].

Similar to TSCH, OFDM is a technique that copes with external interference and multi-path fading. Yet, unlike TSCH, this happens at the PHY layer.

Lee et al. [START_REF] Lee | Implementation of IEEE 802.15.4g Wireless Communication Platform for Smart Utility Service[END_REF] combine a 32-bit micro-controller with an FPGA and a radio frequency ASIC to create a smart home system using IEEE802.15.4 FSK and OFDM. The authors are able to consult the home's water and electricity consumption remotely over the Internet.

In our previous publication [START_REF] Munoz | Overview of IEEE802.15.4g OFDM and its Applicability to Smart Building Applications[END_REF], we conduct a series of experiments using one fixed transmitter node and 3 receiver nodes. The nodes consist of a Raspberry Pi, a battery pack and an ATREB215-Xplained pro board featuring an AT86RF215 radio chip implementing IEEE802.15.4 O-QPSK, FSK and OFDM at sub-GHz and 2.4 GHz. All nodes are mounted on 1.8 m poles. In that paper, we explore 4 PHYs: O-QPSK at 2.4 GHz, OFDM option 1 MCS2 at sub-GHz, OFDM option 1 MCS3 at sub-GHz, and OFDM option 2 MCS5 at sub-GHz. For each PHY, the transmitter sends 100 127 B and 2047 B frames over all available frequencies in each PHY. We show that the IEEE802.15. [START_REF] Watteyne | Lessons Learned from Large-scale Dense IEEE802.15.4 Connectivity Traces[END_REF] in sub-GHz are suitable for Smart Building applications due to their higher PDR and lower power consumption in comparison with the well-known O-QPSK PHY.

One major difference with the current paper is that OFDM is evaluated at sub-GHz; this changes everything from a wireless point of view (interference, multi-path, etc). None of the lessons learnt from the current paper could have been possible from the data gathered for [START_REF] Munoz | Overview of IEEE802.15.4g OFDM and its Applicability to Smart Building Applications[END_REF]. That being said, we refer the interested reader to [START_REF] Munoz | Overview of IEEE802.15.4g OFDM and its Applicability to Smart Building Applications[END_REF] for an in-depth overview of OFDM, albeit at sub-GHz.

Surprisingly, little related work exists on evaluating the usefulness of OFDM in low-power wireless, even less at 2.4 GHz. This paper contributes to filling that void.

Specifically, the goal of this paper is to answer the following questions. Is OFDM a valid alternative for lowpower wireless? How does OFDM compare to O-QPSK in the IEEE802.15.4 context? How should OFDM be used at 2.4 GHz?

III. CONTRIBUTIONS

This paper focuses on IEEE802.15.4 OFDM option 1 (both MCS0 and MCS3), and O-QPSK, at 2.4 GHz. Its contributions are 4-fold:

1) We define a methodology and provide tools to continuously evaluate the PDR of a wireless link using off-the-shelf hardware. 2) We collect a connectivity dataset which contains 141,587,000 points; to the best of our knowledge the most comprehensive OFDM/O-QPSK dataset at 2.4 GHz to date. 3) In an entirely counter-intuitive manner, we show that channel hopping (at the MAC layer) is needed to achieve reliable connectivity, even when using IEEE802.15.4 OFDM at 2.4 GHz. 4) In a similarly counter-intuitive manner, we recommend not using frequency repetition to cope with external WiFi interference.

IV. EXPERIMENTAL SETUP

This section provides all the necessary information for the reader to reproduce the experiments. This study is carried out by successive experiments using 4 nodes: one transmitter (TX) and three receivers (RX). In an experiment, the four nodes configure their radios with the three PHYs described in III. In O-QPSK, the nodes tune their radios to the 16 channels available in the 2.4 GHz frequency band. In OFDM, we switch between 17 channels, a subset of the 64 available (see rationale in Section IV-B).

A. Hardware

A node consists of a Raspberry Pi 3 (rPi) model B and an ATREB215-XPRO radio board (featuring the AT86RF215 chip capable of both O-QPSK and OFDM), and a 2 dBi omni-directional antenna. The rPi drives the radio board through an SPI bus. The electronic devices, connectors and cables are placed inside a plastic box. The antennas are fixed outside the box. Fig. 1 shows a picture of the node. Table I shows the performance of the radio.

B. Software

A Linux Debian distribution is running on the rPi of each node. Nodes are synchronized over NTP. A number of scripts drive the experiment1 . These scripts configure the radios with a specific PHY, frequency, and for enough time to allow the TX node to send 1,000 127 B frames. TX power is +8 dBm; the spacing between frames is 20 ms. The experiment runs continuously: the nodes loop through all PHY settings, each time sending 1,000 frames.

Because looping over 64 channels for OFDM would be too time consuming, they loop over the subset of 17 channels listed in Table II For each frame it receives, the RX node logs the PHY and channel used, the sequence number in the received frame, the RSSI value and whether the FCS is Since 1,000 frames are sent, we can compute the PDR for each PHY/channel combination, and see its evolution over time.

C. Deployment Environment

We conduct the experiments within the Inria-Paris building in France. Fig. 3 shows the location of the nodes. The floor is covered with carpet, the ceiling is metallic, with two concrete staircases and two elevator shafts in the center of the floor. Divisions between offices are made of glass and prefabricated walls. External walls are made of concrete with glass windows.

The nodes are installed on 1.8 m PVC poles. Experiments were conducted for 21 continuous days, with people around and WiFi being actively used during business hours.

V. EXPERIMENTAL RESULTS

We collected a dataset of 141,587,000 atomic measurements. This section lists the lessons learnt from analyzing this dataset.

A. On Power Consumption

Table I shows the current consumption of the radio for the 3 PHYs. The most energy-hungry operation a node performs is to have its radio on. An advanced MAC layer such as TSCH turns the radio off most of the time; a radio duty cycle below 1% is commonplace. The results about current draw from our previous publication [START_REF] Munoz | Overview of IEEE802.15.4g OFDM and its Applicability to Smart Building Applications[END_REF] hold in this analysis; we hence refer the interested reader to that publication.

B. On the PDR over the 2.4 GHz frequency band

Table III shows the PDR of the three links for each PHY layer, averaged over time and over all channels. While it is impossible to draw any general conclusion about data gathered over just 3 links, we can make two interesting observations. First, OFDM consistently yields a better PDR than O-QPSK. Second, MCS3 yields a better PDR than MCS0, even when it offers a much higher data rate and uses no frequency repetition. This will be explained in Section V-F.

The average PDR does not give us nearly as many insights as Fig. 4, which plots the PDR of each link evolving during the 21 days of the experiment, for each channel. Fig. 4 is for node B, equivalent lessons learnt appear for the other nodes. Drawing a subplot for each channel allows us to "see" the effect of external interference and multi-path fading on a channel-by-channel basis. For easier readability, each subplot is highlighted in green when PDR>50%. This section makes a number of qualitative observations which are analyzed in greater detail in subsequent sections.

Fig. 4 shows that there is no single frequency that is "good" all the time. The PDR on each frequency is dynamic, as a result of changes in the environment. One can clearly see week-end/weekday and day/night transitions.

These dynamics in PDR are caused by multi-path fading and external interference. It is entirely expected -and well documented -in the IEEE802.15.4 O-QPSK case. In an entirely counter-intuitive manner, they are also equally present in OFDM. OFDM was designed to combat multi-path fading and external interference at the PHY layer, by encoding data on dozens of frequencies. One would expect the resulting frequency diversity at the PHY layer to cause the per-channel PDR to be very stable. The reason we do see PDR dynamics in OFDM is that the channels are only 1.094 MHz wide: C. Impact of Nearby WiFi Fig. 4(b) shows a constantly bad link for channels 3, 7, 11. This can be attributed to external interference. To verify this, we use the iwlist Linux utility to list the RSSI and frequency of the WiFi signals received by node B, see Fig. 5. WiFi activity is centered on WiFi channels 1 (2.412 GHz), 6 (2.437 GHz) and 11 (2.462 GHz). Node B receives 21 WiFi signals; the highest noise level is in the 2.404-2.414 GHz band, the same as channels 3, 7, 11 in Fig. 4(b).

Section V-F further details why the same does not happen to MCS3.

D. Quantifying Multi-path Fading in OFDM

Multi-path fading causes some frequencies to exhibit a PDR above 50%, others below. The experiment is conducted in cycles of approximately 30 min, during which the TX node sends 1,000 frames on each PHY and channel. This means that, every 30 min, we can compute the PDR of each link, on each channel, for each PHY. above 50%. In the absence of external interference and multi-path fading, either all channels would be good, or bad. That is, there would be a single bar at the maximum number of channels.

Rather, we see that, for O-QPSK, in most of the cases 13 channels are "good", the remaining 3 being affected by multi-path fading or interference. This is a simple way of "seeing" those effects, and is entirely expected for O-QPSK. What is counter-intuitive is that OFDM is affected by multi-path fading and external interference in a way similar to O-QPSK.

E. Coherence Bandwidth

When node A sends a frame to node B on frequency f 1 , and that transmission fails because of multi-path fading, a valid approach is to re-transmit on a different frequency f 2 . We are interested in understanding how far f 2 should be from f 1 to offer enough frequency diversity. We call "coherence bandwidth" the difference |f 2 -f 1 | which is sufficient for a link to transition from "bad" (PDR<50%) to "good" (PDR>50%).

We explore this experimentally in our dataset: we find a frequency with PDR<50%, and see how big a frequency shift is needed to result in PDR>50%. Fig. 7 shows the result. When using O-QPSK (fig. 7(a)) and OFDM option 1 MCS3 (fig. 7(c)), a frequency shift of 10 MHz is sufficient 60% of the time. For OFDM option 1 MCS0, a frequency shift of 10 MHz is sufficient 40% of the time, 80% of the time with a shift of 20 MHz.

F. Pros and Cons of Frequency Repetition

Our previous publication [START_REF] Munoz | Overview of IEEE802.15.4g OFDM and its Applicability to Smart Building Applications[END_REF] shows how frequency repetition improves the PDR of links at sub-GHz frequencies. Higher levels of frequency repetition should result in a higher PDR. This is not what we see when comparing MCS3 (no repetition) to MCS0 (4 × repetition).

The reason is that frequency repetition increases the time on air of a frame, making it more prone to collisions with other radio signals. As seen in Fig. 5, there are WiFi networks in the proximity of node B, each of which emits beacons at least every 100 ms, even when the WiFi network sits idle. A 127 B frame takes with OFDM option 1 MCS0 (100 kbps) roughly 10 ms to be transmitted, only 1.27 ms with MCS3 (800 kbps). Frequency Repetition is useful only if there is no strong external interference.

VI. CONCLUSIONS AND FUTURE WORK

This paper investigates the usefulness of IEEE802.15.4 OFDM at 2.4 GHz, how it compares to O-QPSK, and how it should be used. Our analysis is based on a 141,587,000point connectivity dataset gathered indoors over 21 days.

We show that OFDM alone does not yield immunity to multi-path fading and external interference. We recommend combining OFDM with channel hopping at the MAC layer, with subsequent channels in the hopping sequence separated by at least 20 MHz. In the presence of nearby WiFi access points, we further recommend using OFDM option 1 MCS3 (i.e. without frequency repetition), with frames shorter than 127 B. Since IEEE802.15.4 radios chips implementing multi-PHYs are now available, as future work we perceive the need of a MAC layer that can dynamically configure the transceiver in order to choose the most convenient PHYaccording to desired range, latency, power consumption...for each pair of nodes.

Figure 2 :

 2 Figure 2: The O-QPSK PHY of IEEE802.15.4-2015 divides the 2.4 GHz band into 16 channels, each 2 MHz wide, separated by 5 MHz. The OFDM option 1 PHY divides the band into 64 channels, 1.094 MHz wide, separated by 1.2 MHz. Greyed-out channels are the ones used in our experiments.

Figure 3 :

 3 Figure 3: The location of the nodes in the Inria-Paris building during the 21-day experiment.

Figure 4 :

 4 Figure 4: PDR per PHY channel for node B during 21 days. Areas in green indicate PDR greater than 50%.

Figure 5 :

 5 Figure 5: Strengths of the WiFi signals received at node B.

Fig. 6

 6 plots the number of channels which exhibit a PDR OFDM option 1 MCS3 (800 kbps)

Figure 6 :

 6 Figure 6: Number of frequencies with PDR>50%, for node B.

  OFDM option 1 MCS3 (800 kbps)

Figure 7 :

 7 Figure 7: Coherence bandwidth.

  -2015 standard [1] defines the PHY and MAC layer specifications for symmetric low data rate wireless mesh communication used by low-cost low-power devices. This standard can operate in the 2.4 GHz unlicensed frequency band, which is what most deployments use. This technology has been deployed for industrial, urban, home and commercial applications. Most major chip vendors offer IEEE802.15.4-compliant radios at a low price, typically under 5 USD. The first version of this standard appeared in 2003, and includes the O-QPSK PHY at 2.4 GHz. This PHY cuts the 2.4 GHz frequency band into 16 channels. Each channel is 2 MHz wide, adjacent channels are separated by 5 MHz. The data rate is 250 kbps; the maximum frame length is 127 B. Direct Sequence Spread Spectrum (DSSS) is used to offer coding gain.

Table I :

 I Radio characteristics and details of the PHY explored in this paper.

	PHY	data rate	sensitivity	condition	TX current (+8 dBm) RX current	sub-carrier modulation freq. rep.
	O-QPSK	250 kbps -104 dBm	PSDU length 20 B PER<1%	63.05 mA	31.85 mA	N.A.	N.A.
	OFDM Option 1 MCS0	100 kbps -112 dBm	PSDU length 250 B 67.25 mA PER<10%	30.65 mA	BPSK rate 1/2	4×
	OFDM Option 1 MCS3	800 kbps -105 dBm	PSDU length 250 B 67.15 mA PER<10%	30.65 mA	QPSK rate 1/2	none
								OFDM PHYs

Table II :

 II Center frequencies of the channels used for IEEE802.15.4 O-QPSK and OFDM

	center	O-QPSK	OFDM	center
	frequency	channel	channel frequency
	2.400 GHz		0	2.4012 GHz
	2.405 GHz	11	3	2.4048 GHz
	2.410 GHz	12	7	2.4096 GHz
	2.415 GHz	13	11	2.4144 GHz
	2.420 GHz	14	16	2.4204 GHz
	2.425 GHz	15	20	2.4252 GHz
	2.430 GHz	16	24	2.4300 GHz
	2.435 GHz	17	28	2.4348 GHz
	2.440 GHz	18	32	2.4396 GHz
	2.445 GHz	19	36	2.4444 GHz
	2.450 GHz	20	41	2.4504 GHz
	2.455 GHz	21	45	2.4552 GHz
	2.460 GHz	22	49	2.4600 GHz
	2.465 GHz	23	53	2.4648 GHz
	2.470 GHz	24	57	2.4696 GHz
	2.475 GHz	25	61	2.4744 GHz
	2.480 GHz	26	63	2.4768 GHz
				, which are chosen to almost match the
				frequencies used in O-QPSK. In total, 50 channels are tested:
				16 in O-QPSK, 17 in both OFDM option 1 MCS0 and
				MCS3.

Table III :

 III PDR for each node, averaged over time and over all channels.

The software used for these experiments is available under an opensource license at https://github.com/openwsn-berkeley/range_test/releases/ tag/REL-3.0.0.