Based on MSF, the related works in
Section 3, and prior work [
1,
8], we designed a multi-modal variant of the 6TiSCH stack, as depicted in
Figure 1. Central to this effort is our new SF (i.e., 3MSF), which uses supercells and hence constitutes a variable-duration slot approach. This section outlines the ground rules for 3MSF. More specifically,
Section 4.1 describes how our perceived need for simultaneous Tx requires an abstracted way of tagging cells.
Section 4.2 gives an overview of the 3MSF slotframes and how they are different from the solutions that inspired them. Next,
Section 4.3 discusses how timeslot timings relate to supercell lengths, followed by a description of how supercells mandate a new way to determine the next link to wake up for in
Section 4.4, as well as an explanation of all the different 6P transactions 3MSF uses (and when it does) in
Section 4.5. Finally,
Section 4.6 discusses the use of routing metrics, a topic that is more indirectly related to 3MSF but played a major role in its design nonetheless.
4.1. TSCH Mode Abstraction
As we wanted to use a Parent-Oriented (PO) approach (meaning devices are RPL neighbors) based on prior work [
1,
8] combined with a Tx-based routing metric (see
Section 4.6), we needed a way to keep fresh inferred metrics without crowding the schedule. Hence, we devised an abstraction called “TSCH modes”. A TSCH mode uniquely identifies which communication mode(s) to use in a (super)cell, and (potentially) when to do so. Firstly, we defined a unique non-simultaneous TSCH mode for each unique communication mode. In a supercell tagged with a non-simultaneous TSCH mode, transmission can only occur on the corresponding communication mode. Through a process we elaborate on in
Section 4.3, one can determine the number of consecutive subcells required for a supercell tagged with a non-simultaneous TSCH mode. The timeslot timings (see [
2] (Section 6.5.4.2)) to use follow from this supercell length.
Additionally, we defined a group of simultaneous TSCH modes. During simultaneous transmission, an identical copy of a packet (including MAC sequence number) is sent on all (available) communication modes pointed to by the simultaneous TSCH mode. The length of a supercell tagged with a simultaneous TSCH mode equates to the longest supercell length that would ordinarily be used for any non-simultaneous TSCH mode corresponding to the communication modes it points to. For example, if the non-simultaneous TSCH modes corresponding to its underlying communication modes require a supercell of length two and three, then a supercell tagged with a simultaneous TSCH mode has a supercell length of three. Simultaneous transmissions must adhere to the timeslot timings required for this longest underlying supercell length.
Alternating TSCH mode is a special simultaneous mode that almost entirely evaluates to one of the other simultaneous TSCH modes (including its timings), depending on the starting ASN and the length of the slotframe (all 3MSF slotframes are of equal length, see
Section 4.2). The only difference is that the length of a supercell tagged with alternating mode is fixed to the longest required supercell length of any of the simultaneous TSCH modes to which it can evaluate. Alternating TSCH mode provides a means of cycling through all possible interface-modes towards a neighbor while occupying a minimal amount of time-frequency space.
The TSCH mode abstraction uses a 3-bit representation, as we use the same (currently reserved) protocol bits used by Rady et al. [
16], i.e., the three MSBs of the
CellOptions field contained in certain 6P requests (see
Section 4.5) and the three MSBs of the
Link Options fields (one per minimal supercell) contained in TSCH EBs. Since the amount of information one can encode with 3 bits is limited, we made (reasonable) assumptions about the hardware capabilities of an average 6TiSCH node. More specifically, we assumed all devices to have at most two interfaces (which operate in different frequency ranges or the communication modes of which are otherwise orthogonal between them), each supporting at most two unique communication modes. In addition, all network devices must either own the same set of interface-modes or otherwise be aware of the superset of interface-modes that exist throughout the network (presumably through some mechanism that is beyond the scope of this paper).
Barring two special values, the 3-bit TSCH mode encoding follows an
m.ii dot notation format (MSB-first), where
denotes the index of an interface in an ordered list of interfaces known to all nodes and
m denotes the index of the communication mode in one of two ordered lists (i.e., the one corresponding to the interface with index
), both of which are known to all nodes.
Table 2 lists all TSCH mode encodings.
4.2. Slotframe Structure
For 3MSF, we maintained (in spirit) the three slotframes of Rady et al. [
16] (and MSF) and added two more. The minimal slotframe is virtually identical. As shown in
Figure 5, it contains a minimal supercell for every unique interface-mode. The string of minimal supercells starts at a slot offset of zero and spans exactly as many consecutive subcells (see
Section 2.2) as needed to accommodate one supercell per unique interface-mode without the minimal supercells overlapping with one another. When a new slotframe comes around and it is time to advertise the TSCH network, an identical EB must be broadcast on each consecutive minimal supercell of said slotframe, with no retransmissions allowed. This could be achieved by, for example, having a separate buffer (i.e., from the broadcast buffer) for EBs, giving absolute priority to EBs in minimal supercells, and simply adding as many EBs to the EB buffer as there are minimal supercells.
At first glance, the negotiated slotframe also incurs minimal changes from Rady et al. [
16] (and MSF) in the sense that, e.g., adding at least one negotiated Tx supercell towards an RPL parent when it becomes preferred remains mandatory. However, we consider devices, and not individual communication modes, to be independent RPL neighbors. Therefore, the cost associated with each communication mode is no longer automatically accounted for through routing layer operations alone. Negotiated supercells can only overlap with autonomous Tx supercells and certain so-called “shadow” supercells (more about that later). All negotiated supercells towards a given neighbor can only be tagged with a single non-simultaneous TSCH mode at a time.
Our autonomous slotframe uses the alternating TSCH mode (see
Section 4.1), mostly to maintain up-to-date inferred metrics for all interface-modes of each neighbor towards whom a node can (still) use an autonomous Tx supercell. Since autonomous supercells always occupy the same number of subcells, we slightly modified the hashing function to ensure they fall within predetermined bins, meaning overlapping autonomous supercells start and end at the same slot offsets.
With MSF, a node cannot use an autonomous Tx cell towards a neighbor to which it already has a negotiated Tx cell. However, in our case, if we have negotiated Tx supercells towards a given neighbor, we also require at least one Tx supercell tagged with the alternating TSCH mode towards the same neighbor. Otherwise, we could not maintain fresh inferred metrics towards it.
The only way to maintain fresh inferred metrics and consistent MAC sequence numbers is to allow non-probe (see
Section 4.6) unicast packets on both kinds of supercells. That is, once we have attempted transmission of a unicast packet with a given MAC sequence number towards a given neighbor, we cannot send it a unicast packet with a lower sequence number before a certain (typically quite long) lifetime expires to maintain sequence number consistency. Therefore, once we attempt transmitting a unicast packet (and its MAC sequence number is “on-air”), it must be dequeued before the next unicast packet (i.e., with a consecutive sequence number) can be transmitted to the same neighbor. Put differently, if a given unicast packet can only be sent on Tx supercells tagged with a certain TSCH mode, other Tx supercells to the same neighbor cannot be used for the transmission of other unicast packets as long as we are attempting to transmit the current packet. As such, if we allowed non-probe unicast packets on negotiated Tx supercells only, retransmissions of those packets would often cause us to skip the Tx supercells tagged with alternating mode, thereby preventing us from maintaining fresh inferred metrics.
If the Tx supercells tagged with the alternating TSCH mode (i.e., to be used towards neighbors we already have negotiated Tx supercells towards) were autonomous Tx supercells, they would be shared. Since non-probe unicast transmissions would be allowed on these supercells, this would be especially problematic in networks with a tree-like routing topology and mostly MP2P traffic. Hence, we required another slotframe based on the alternating TSCH mode: the probing slotframe. The probing slotframe is managed in a similar fashion to the negotiated slotframe (see
Section 4.5). As with negotiated supercells, probing supercells also correspond to dedicated links. Probing supercells can only overlap with autonomous Tx supercells, and the probing slotframe handle must be greater than the autonomous slotframe handle but less than the negotiated slotframe handle.
A node must install exactly one probing Rx and one probing Tx supercell towards a newly preferred parent (in that order) before it can install a negotiated Tx supercell towards the same parent, and both probing supercells must remain scheduled as long as at least one negotiated Tx supercell is scheduled towards the same neighbor. Additionally, a node cannot have an autonomous Tx supercell towards neighbors it already has a probing Tx supercell towards. All unicast traffic is allowed on both probing and negotiated supercells. That said, probes may be dropped in favor of other unicast packets under certain conditions (see
Section 4.6).
MSF’s windowed counter mechanism for negotiated cell management [
7] (Section 5.1) is problematic for negotiated Rx cells because the owner of an autonomous Rx cell does not know when the owner of the corresponding autonomous Tx cell backs off (see
Appendix B). Therefore, 3MSF updates this mechanism slightly. More specifically, when there is no negotiated Rx supercell towards the preferred parent, the probing Rx supercell (as well as the packets received on it) and not the autonomous Rx supercell (nor the packets received on it from the preferred parent) is taken into account for downstream traffic adaptation. This works because the probing Rx supercell towards the preferred parent is mandatory (so we can maintain fresh inferred metrics towards the preferred parent) but (unlike autonomous supercells) the corresponding probing Tx supercell (as seen from the preferred parent’s perspective) is not shared.
Finally, this brings us to the shadow slotframe, which is more of a pseudo-slotframe, as shadow supercells are not considered when determining the next link to use (hence the slotframe handle
∞). As far as the processes that govern the selection of the next link are concerned (see
Section 4.4), the shadow slotframe does not exist. The sole purpose of the shadow slotframe is to build (in parallel) an alternative to the current negotiated slotframe towards the preferred parent if we wish to change the interface-mode to be used in the negotiated cells towards it. Shadow supercells can only overlap with autonomous Tx supercells and negotiated supercells, regardless of type.
The sequence of 6P transactions required to switch the interface-mode used in the negotiated supercells towards the preferred parent is called the “shadow operations”.
Section 4.5 explains which transactions make up the shadow operations, and
Section 4.6 explains when shadow operations with the preferred parent are triggered.
4.3. Timeslot Timings and Supercell Length
3MSF uses variable-duration timeslots by aggregating consecutive “unit-duration” subslots in a superslot. The timing intervals to use within a superslot are (mostly) dictated by the data rate of the communication mode(s) it uses and the maximum packet size for said communication mode(s). After all, by definition, each (super)slot must allow for the exchange of a unicast packet and a corresponding acknowledgement (ACK).
Figure 6 shows the layout of TSCH timing intervals for acknowledged transmission [
2] (Section 6.5.4.2). Knowing which values to use starts with determining appropriate lower/upper limits for the timing intervals of each non-simultaneous TSCH mode. It is important to remember that a non-simultaneous TSCH mode maps to a single communication mode, as explained in
Section 4.1.
All relationships between the different timing intervals are listed in (
4) or can otherwise be derived from it.
where:
| the time between performing (optional) Clear Channel Assessment (CCA) and the start of transmission; |
| the receiver guard time; |
| the time needed to transmit packet of maximum size; |
| the time to the earliest possible start of reception; |
| the time to the start of transmission; |
| the time to the start of (optional) CCA by the transmitter; |
| the duration of (optional) CCA by the transmitter; |
| the smallest possible time between the end of transmission and the start of ACK reception; |
| the time between the end of reception and the start of ACK transmission; |
| the transmitter guard time (not used for synchronization); |
| the time needed to transmit an ACK of maximum size; |
| must be greater than or equal to the time needed for the remaining operations and going to sleep. |
Once you have determined appropriate ranges for the timing intervals of each non-simultaneous TSCH mode, you must decide on the exact intervals that make up a unit-length superslot and together amount to unit duration. The supercell length used for a given non-simultaneous TSCH mode determines how to derive the timing intervals from the intervals of a unit-length superslot. While superslot duration is an integer multiple of unit duration, where the multiple is the superslot/supercell length, the timings that make up superslot duration are not necessarily multiplied by the supercell length. That is, we require
,
,
, and
to remain constant. In addition,
and
each differ from their unit-duration counterparts by a unique factor. Similarly,
and
differ from their unit-duration counterparts by the same factor. Afterwards, the remaining values can be determined using (
4).
Determining appropriate supercell timings and lengths is an exercise in scheduling efficiency, as the best choice largely depends on the spread of data rates across communication modes. It should be noted that all nodes must have a common understanding of the supercell length to use for each non-simultaneous TSCH mode (which themselves map to a single communication mode), either by statically configuring them with such information a priori or through some mechanism that is beyond the scope of this paper.
Unit-length superslot timings are disseminated conventionally, i.e., with the TSCH Timeslot IE [
2] (Section 7.4.4.4) in EBs. Similarly, we designed a new sub-IE for the IETF IE, which we termed the “Timing” sub-IE, to carry the three coefficients used to derive
,
,
, and
from their unit-duration counterparts. More specifically, as shown in
Figure 7, the Timing sub-IE contains a variable-length
FactorList, where each entry follows a specific format. That is, each entry maps a supercell length greater than 1 to three 8-bit fixed-point scaling factors. The two factors for
and
have six spaces behind the binary point, whereas the scaling factor for
and
has four. Support for supercell lengths greater than 1 requires an IETF IE with a Timing sub-IE in every EB.
In
Section 4.1, we mentioned how the supercell length for a simultaneous TSCH mode equates to the longest supercell length we would ordinarily use for any non-simultaneous TSCH mode corresponding to the communication modes to which it (i.e., the simultaneous TSCH mode) points. As always, its length dictates the timing intervals to use in a supercell. As such, for simultaneous transmission, the same timings apply to all underlying communication modes, which makes synchronization relatively straightforward. That is, assuming transmission is truly simultaneous at the link layer, we need only derive the drift from the first ACK (with ACK-based synchronization) or the first packet (with frame-based synchronization) received.
4.4. TSCH Link Selection
Supercells require a slightly modified TSCH link selection process. Presumably, the next active link (and hence how long a node can sleep) is determined when operations on the current link have concluded. At that point, a node iterates through all slotframes in ascending order of slotframe handles. For each supercell encountered, the node calculates how many slot offsets its first subcell is removed from the last subcell of the current supercell. At the same time, the node tracks a single supercell, which we call the Current Best Supercell (CBS). That is, the first supercell the node encounters automatically becomes the CBS. Then, for every next supercell, it compares the distance to the CBS with the distance to the given supercell. If the distance to the given supercell is less than or equal to the distance to the CBS and there is no overlap between them or the given supercell has precedence (see
Section 2.1.2), the given supercell becomes the CBS. Finally, the node is left with the most appropriate next link to wake up for.
Figure 8 puts the process of next active link selection in a handy flowchart.
A backup link may also be selected when retrieving the next active link. Normally (i.e., without supercells) a backup link is selected from all Rx links that coincide with the ultimately selected next active link. Selection happens according to the lowest slotframe handle among all eligible backup links (since only Rx links are eligible). However, when using supercells, only Rx supercells that start at the same slot offset as the ultimately selected next active supercell, and fall entirely within said supercell, are eligible as a backup supercell.
4.5. 6P Transactions
3MSF uses the
Metadata field of 6P request messages [
11] (Section 3.3) to indicate to which slotframe a request pertains. For the probing and shadow slotframe, the
Metadata field value equals the respective slotframe handle, whereas for the negotiated slotframe, the value is zero. In
Section 4.2, we mentioned that the shadow slotframe is effectively a pseudo-slotframe with a handle of
∞. In practice, you would simply give the shadow slotframe a handle (e.g., 5) and treat it as an escape value.
Figure 9 shows a possible
ADD transaction, which works the same for the probing, negotiated, and shadow slotframes. Node #2 wants to install two negotiated Tx supercells towards its preferred parent #1, forms an
ADD request with a
Metadata field value of 0, and populates its
CellList [
11] (Section 3.2.4) with groupings of consecutive subcells. Each subcell grouping must accommodate at least one supercell of the length required by the TSCH mode contained in the three MSBs of the request’s
CellOptions field. The
NumCells field indicates how many subcells from the
CellList #2 wishes to install towards #1 in the slotframe pointed to by the
Metadata field. Hence,
NumCells must be an integer multiple of the required supercell length, and the subcell groupings in the
CellList must accommodate at least this integer multiple of supercells. Upon receiving the
ADD request and performing all the checks required by 6P, #1 verifies that (1)
NumCells is an integer multiple of the required supercell length; (2) each subcell grouping has a length greater than or equal to the supercell length; and (3) the proposed subcell groupings can accommodate a number of supercells greater than or equal to
NumCells divided by the required supercell length. If the additional verification fails, or if #1 has no space left in its schedule to pick at least one supercell from the subcell groupings proposed by #2, #1 returns a 6P response containing the code
RC_SUCCESS and an empty
CellList. Otherwise, #1 returns an
RC_SUCCESS response with a non-empty
CellList, which is less than or equal to
NumCells in length, and where all groupings are integer multiples of the required supercell length. It should be noted that it seems more appropriate to return a 6P response containing the code
RC_ERR_CELLLIST if the additional checks were to fail. Unfortunately, this would violate RFC 8480 [
11] (Section 3.3.1).
Very similar to
ADD transactions are
DELETE transactions, which 3MSF only uses for the negotiated slotframe. We retain all rules from RFC 8480 [
11] (Section 3.3.2) concerning the deletion of cells (using a two-step 6P transaction). Additionally, we require (1) all subcell groupings to match actual supercells; and (2)
NumCells to be an integer multiple of the required supercell length.
3MSF also supports 6P
RELOCATE transactions for the relocation of negotiated and probing supercells. We retain all rules from RFC 8480 [
11] (Section 3.3.3) concerning the relocation of cells (using a two-step 6P transaction). Additionally, we require (1) all subcell groupings in a
RELOCATE request’s relocation
CellList, as well as those in the response’s
CellList (if non-empty), to match actual supercells; (2)
NumCells to be an integer multiple of the required supercell length; and (3) the subcell groupings in a
RELOCATE request’s candidate
CellList to each have a length greater than or equal to the supercell length and together be able to accommodate greater than or equal to the integer multiple of supercells specified in (2).
Figure 10 shows an example of a possible (successful)
RELOCATE transaction for 3MSF.
CLEAR transactions work nearly identically between 3MSF and MSF, with one small caveat. A CLEAR request with a Metadata field value of zero removes all supercells (towards the same neighbor) from the negotiated, probing, and shadow slotframes. Such a “general” CLEAR request/transaction is used if there is any risk of an inconsistent negotiated slotframe. Otherwise, a slotframe-specific CLEAR request is used.
Finally, this leaves us with the sequence of 6P transactions we call shadow operations, which can only be initiated by a node towards its preferred parent under the following conditions:
Shadow operations initiated by said node are not already ongoing (previous operations need to be terminated first; further details on this are discussed later);
A non-shadow 6P transaction is not currently ongoing with the preferred parent in any direction;
A non-shadow 6P transaction is not already scheduled to be initiated at some point in the future (e.g., because of a retry);
There is not already a maximum number of concurrent 6P transactions ongoing;
The node has a probing Tx supercell towards its preferred parent.
During shadow operations, a node first determines how many negotiated Tx supercells it has towards its preferred parent before sending it an
ADD request for (at most) the same number of shadow Tx supercells. Upon successfully installing at least one shadow Tx supercell (a maximum number of retries is allowed until at least one such supercell is added), the node may do the same for negotiated Rx supercells (if there are any, the same rules apply for retries). Finally, the node initiates a custom two-step
SIGNAL transaction (e.g., see
Figure 11). When this transaction completes successfully (with the same rules applying for retries) and not at any other point in time, all negotiated supercells involved are removed, new negotiated supercells are derived from the shadow supercells towards said neighbor, those shadow supercells are removed, and shadow operations terminate (in that order).
Since the interface-mode used in negotiated supercells performed poorly, all traffic belonging to shadow operations must be sent using probing supercells only. Unfortunately, this creates a minor bottleneck due to the MAC sequence number consistency requirements mentioned in
Section 4.2.
During shadow operations, the following rules apply (besides any rules mentioned previously):
Switching the frozen interface-mode to the preferred parent (which triggers new shadow operations, see
Section 4.6) or switching the preferred parent while shadow operations with it are ongoing causes them to terminate, i.e., by aborting any ongoing non-
CLEAR transactions belonging to those shadow operations and initiating appropriate
CLEAR transactions. Receiving a response code requiring a shadow transaction be aborted and a
CLEAR request (of any kind) be sent to the preferred parent (e.g., because it detected an inconsistency), or exceeding the retry limit for a non-
CLEAR shadow request, has a similar effect.
4.6. Related to Metrics
As explained in
Section 2, supporting multi-modal operation affects all layers that derive functionality from link-layer operation. With 6TiSCH, the chosen RPL OF imposes requirements on the TSCH SF, and vice versa. Based on the premise of avoiding excessive parent changes/local repairs [
1], we combined 3MSF with a slightly adapted version of our Dual Radio-Interface Routing Protocol for LLNs (DRiPL) OF, referred to as DRiPLOF [
8].
Most changes applied to DRiPLOF relate to routing metrics (see
Appendix C for other differences). Physical links [
8] (Section 4.2) (which are distinct from TSCH links) now equate to interface-modes, and inferred metrics now belong to interface-modes. We use the Expected number of Transmissions (ETX) [
10] (Section 4.3.2) as the inferred metric. This means that we still require a metric threshold to asses an interface-mode’s status. However, as different Tx attempts of the same packet can now occur on different interface-modes, we can no longer just update ETX when a (unicast) packet is dequeued. Instead, we perpetually calculate ETX for each interface-mode as the ratio of a Tx and ACK counter, both of which are tied to a single interface-mode of a given neighbor and are updated after each Tx attempt across said interface-mode. In addition, we penalize ETX if we fail to transmit on an interface-mode for a number of consecutive attempts, regardless of attempts on other interface-modes. To qualify as a Tx attempt, a packet must have been on-air or its transmission must have been postponed because CCA failed (CCA is not mandatory). We consider CCA failures as Tx attempts to mitigate denial-of-service attacks through jamming, as only Tx attempts lead to inferred metric updates.
Figure 12 illustrates the flow of events when the process governing inferred metric updates is called.
When an inferred metric changes, the preferred interface-mode towards the corresponding neighbor is (re-)selected. However, since the interface-mode used for unicast transmissions is now dictated by the supercells they occur in, the preferred interface-mode is no longer automatically used for all unicast transmissions towards a given neighbor. That is, swapping out the interface-mode to use in negotiated supercells towards the preferred parent on every preferred interface-mode change is not feasible. Thus, performing such a switch is rate-limited. We call the interface-mode to use in all negotiated supercells towards the preferred parent the “frozen” interface-mode.
A frozen interface-mode switch can only occur when the inferred metric of the currently preferred and/or frozen interface-mode towards the preferred parent changes. If a node does not have any negotiated supercells towards its preferred parent and it has not yet initiated a (currently ongoing) 6P transaction to add such supercells, shadow operations are not needed, and the node can simply alter the CellOptions field of the 6P ADD request it will supposedly send to its preferred parent soon. In this case, a node must switch frozen interface-mode if the inferred metric of the currently preferred interface-mode towards the preferred parent is better than the inferred metric of its frozen interface-mode, i.e., without applying hysteresis. Otherwise, shadow operations are always triggered when a frozen interface-mode switch is required for one of the following reasons:
If the frozen interface-mode went down, switch to the currently preferred interface-mode if that one is up.
If neither the frozen nor the currently preferred interface-mode is down but the absolute difference between their inferred metrics exceeds a hysteresis threshold, switch to the preferred interface-mode.
If the preferred interface-mode towards the preferred parent fails, a preferred parent switch will occur soon and shadow operations cannot be triggered.
Finally, the path cost through a candidate neighbor is the sum of the normalized metric towards it and (because we use ETX) the rank it advertises. Metric normalization consists of (1) calculating a weight based on the number of unavailable interface-modes towards a neighbor using (
5), and (2) calculating the normalized metric using (
6).
where:
W | the metric normalization weight; |
| the number of interface-modes per node; |
| the number of valid physical links towards a given neighbor; |
| the maximum number of invalid physical links towards any neighbor, must be and ; |
| a constant divider, which must be ; |
| a weight offset, which must be and ; |
| the normalized metric towards a given neighbor; |
S | a constant scale multiplier; |
| the inferred metric of either the frozen interface-mode (to the preferred parent), or the preferred interface-mode (to other neighbors). |
The way we calculate weights using (
5) is slightly modified from [
8] (Equation (
2)). That is, we introduce a weight offset
term to allow for additional fine-tuning.
Enough unicast packets must be sent to all neighbors on all interface-modes such that their normalized metric (and therefore, path cost) is always a reasonably accurate reflection of their capabilities. Since an interface-mode’s inferred metric is updated after each unicast Tx attempt on a supercell tagged with a TSCH mode corresponding to (at least) said interface-mode, and there is often a non-equal amount of Tx opportunities per interface-mode towards the same neighbor over time, maintaining fresh inferred metrics without incurring excessive overhead is tricky, especially considering the MAC sequence number consistency requirements discussed in
Section 4.2.
The mechanism governing reachability detection/metric freshness generally determines a target (i.e., a neighbor). In our case, the same neighbor must remain the target until we have reached a minimal number of Tx attempts on all its interface-modes. Although a Tx attempt of any unicast packet will update an inferred metric, some unicast packets only serve to determine reachability through an interface-mode and/or to maintain a fresh inferred metric for it. Sending such packets over interface-modes with already up-to-date inferred metrics is wasteful.
Contiki-NG [
18], the Operating System (OS) we based our firmware on when designing and evaluating our 6TiSCH architecture, normally (i.e., in single-mode configuration) uses unicast RPL control messages as probes (we used unicast DODAG Information Solicitation (DIS) messages because DIOs advertise DODAG connectivity, which is not allowed by 3MSF prior to said node having at least one negotiated Tx (super)cell towards its preferred parent) to determine neighbor reachability and obtain metrics, as opposed to IPv6 Neighbor Unreachability Detection (NUD) [
19] (Section 5.5). However, the probing of a given neighbor completes as soon as a unicast packet towards it (probe or not) is dequeued following a valid Tx attempt. As such, the probing mechanism was modified. Although the principles behind sending enough packets on each interface-mode of a neighbor are likely very similar regardless of the mechanism, we limit our discussion to Contiki-NG probing.
Figure 13 illustrates the updated flow of events involved in Contiki-NG probing. Upon selecting a new probing target, a unicast probing packet is buffered towards it. For every interface-mode of the target, we count the number of unicast Tx attempts since its selection. When the required number of Tx attempts is reached for every interface-mode of the current probing target, it is unselected. When a packet for the current probing target is removed from the corresponding Tx buffer upon a valid Tx attempt, a unicast probe is added to that buffer. When a unicast packet towards a neighbor is retrieved from the corresponding Tx buffer, the unicast packet that would otherwise (i.e., through other criteria) be sent next is first inspected. That is, if it is a probe but the neighbor is no longer a probing target, or there is more than one packet in the buffer and the supercell to send it on is eligible for transmission of non-probe unicast packets, the probe is dropped, and another unicast packet is retrieved (which is then also inspected). This way, we do not violate the MAC sequence number consistency requirements or create excessive overhead.