| 6TiSCH | J. Munoz, Ed. |
| Internet-Draft | Inria |
| Intended status: Informational | X. Vilajosana |
| Expires: January 3, 2019 | Universitat Oberta de Catalunya |
| T. Chang | |
| Inria | |
| July 2, 2018 |
Problem Statement for Generalizing 6TiSCH to Multiple PHYs
draft-munoz-6tisch-multi-phy-nodes-00
The present document describes the needs that arise when considering to use more than one PHY in a IPv6 over the TSCH mode of IEEE802.15.4e (6TiSCH) network. These considerations are present in: the choice of the PHY, the MAC layer -TSCH- configuration, the 6top protocol, 6LoWPAN and RPL.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The protocol stack in a IPv6 over the TSCH mode of IEEE802.15.4e (6TiSCH) network is defined by multiple protocols covering multiple layers starting from the link layer, up to the application layer [I-D.ietf-6tisch-architecture]. This protocol stack sits on top of the IEEE802.15.4 O-QPSK PHY, at 2.4 GHz, that allows the exchange of frames of 127 B over 16 frequencies at 250 kbps. Since 2012, more PHYs are available within the IEEE802.15.4 specification, e.g. the IEEE802.15.4g amendment of the IEEE802.15.4 standard, designed for Smart Utility Networks (SUN) application, introducing the SUN-OFDM, SUN-FSK and SUN-O-QPSK PHYs. The main differences with the previous IEEE802.15.4 O-QPSK PHY is support of link-layer frames up to 2047 B long, the possibility of being used either at the same 2.4 GHz band or in sub-GHz, regionally defined bands, and variable data rate that goes from 6.25 kbps up to 800 kbps.
Radio chips supporting all these new PHY configurations are now available, giving the opportunity to implementers to exploit the benefits of this diversity in terms of throughput, range and reliability that each PHY brings with it.
However, the adoption of a PHY different from IEEE802.15.4 O-QPSK poses new design considerations across the 6TiSCH protocol stack. Even though layer separation exists between protocols, from the link layer upwards, 6TiSCH protocols have been designed considering one PHY only. This approach of having links over multiple PHYs in the same network is new, and poses up-to-now unknown considerations for network designers.
This document describes how the behavior of each item of the 6TiSCH protocol stack may be impacted by the inclusion of multiple PHYs with such different properties.
This document makes the assumption that the reader is familiar with the [I-D.ietf-6tisch-terminology] and [I-D.ietf-6tisch-architecture], as well as the protocols mentioned there.
Solutions for the considerations here exposed are out of the scope of this document. This document is to be considered only for informative purposes.
In a low-power wireless network with a single PHY, a neighbor node to a particular node A is any node within its interference domain. If nodes are able to use multiple PHYs, a pair of nodes using a specific PHY may be within the same interference domain and when using another PHY, they may not. In addition, nodes also can communicate over different frequency bands. So now the definition of a neighbor node changes to any device within the same interference domain for a given PHY configuration and frequency band. This modifies how nodes can manage their neighbors' information.
Neighbor information is accessed by both the MAC and routing layers. Letting which layer to handle the multiple PHY information changes the network protocol stack significantly. In case of handling by the MAC layer, an entity between MAC and Routing to choose which PHY layer to use is required. This entity could be part of Scheduling Function (Section 4.3). In case of handling by Routing layer, each PHY layer could be considered as a neighbor. For RPL, if only one DODAG exist through the network, a dedicated Objective Function for multiPHY features is required. If each PHY layer has a DODAG corresponding with, the OF for 6TiSCH could be used with little modification. However, this increases the complexity of the network.
The considerations that arise according to the used PHY include network formation, node discovery, and TSCH configuration.
Getting nodes to join the network as fast as possible is a major interest to minimize energy consumption. Radio activity is the most power consuming task for nodes, therefore the more time nodes spend listening to get an Enhanced Beacon (EB) the more energy they consume, reducing their lifespan. Considering a current 6TiSCH network, with just one PHY and one frequency band (16 frequencies), nodes have to tune their radios in one frequency wait for an EB. Nodes which are already part of the network transmit EBs in a round-robin fashion on these 16 frequencies. If the node did not receive any EB after some time, it may tune its radio on a different frequency and listen again for an EB. This means a node listen for a long time before hearing an EB.
In the case of multiple PHYs, nodes attempting to join the network need to over even more PHYs, until hearing an EB. A mechanism might be needed to reduce join time, for example use a particular PHY for joining.
For 6TiSCH networks using one PHY configuration, discovering the PHY neighbor node's capabilities is not necessary. But in a new multiPHY network context, knowing the capabilities of neighbor nodes is important. Once a node is part of the network, it may have not have joined using the most convenient PHY configuration for this pair of nodes. Any of these nodes might then (a) unicast a request its neighbors to get the information about their PHY capabilities, or (b) discover the PHY capabilities of the neighbors by listening for EBs at specific times over other PHYs.
If using (a), further choices need to be taken to decide whether nodes would use shared slots or negotiate dedicated timeslots to test the connectivity over other PHYs. Agreeing on which PHY to test and when has to be done under the already tested PHY configuration, and the energy consumption footprint of this process may be too heavy. If using (b), it may take long time until the most efficient PHY configuration is discovered between two nodes.
A multi-PHY approach has an impact on timeslot duration and channel hopping sequence.
The diversity of data rates of the PHYs in the IEEE802.15.4-2015 standard makes it challenging to find a timeslot duration that is both efficient and fits all PHYs options. In current 6TiSCH networks, a common practice is to have a timeslot of 10 ms. This is time enough for transmitting a 127 B frame using IEEE802.15.4 O-QPSK, taking roughly 4 ms, to wait for the acknowledgment, leaving a handful of milliseconds for data processing with proper guard times.
But for multiple PHYs with data rates going from 6.25 kbps up to 800 kbps and with maximum frame size of 2047 B, the time of transmission for a full size packet varies from 0.020 s (800 kbps) to 2.62 s (6.25 kbps). With such disparity, considering a timeslot long enough (> 2.62 s) to allow the transmission (and its acknowledge frame) of the maximum frame size with the slowest data rate results in a waste of time (network resources) if faster PHY can be used, by leaving the most part of the timeslot unused. Such a long timeslot would cause slotframes to have a duration in the order of minutes (considering for example a slotframe of 101 timeslots), and as tight synchronization is mandatory, multiple KA frames would have to be sent within the same slotframe, considerably reducing the network resources and efficiency.
On the other hand, choosing a shorter timeslot poses a rigid limitation in the size of the frames when slow data rates PHYs are used. By having timeslots in the order of 10's of ms, the frame size for slow data rate is heavily reduced: with a 100 ms timeslot, only 78 B can be transmitted using 6.25 kbps, without considering time for acknowledgment and guard times.
Multi-PHY designs should therefore tune these parameters to find the right trade-off between shorter or longer timeslots (limiting sizes of frames with some PHYs), as well as the size of the slotframe.
Current 6TiSCH implementations use the 2.4 GHz band, with 16 frequencies separated by 5 MHz and 2 MHz wide. Channel hopping sequences use only the frequency number identification. By introducing multiple PHYs, these do not have the same characteristics of channel spacing, bandwidth nor channel numbering. Moreover, channels from different PHYs may overlap.
As a result, by only referring to a channel by some index doesn't carry over to multiple PHYs. Multi-PHY designs need to solve how to identify channels.
The 6top sub-layer [I-D.ietf-6tisch-6top-protocol] is responsible for allocating cells between pairs of neighbor nodes. In a multi-PHY environment, cells have different capabilities depending on the PHY used. Moreover, in some frequency bands, duty cycle regulation must be met.
Current 6TiSCH networks account the network resources allocation in the amount of cells per slotframe a pair of nodes needs. In a multi-PHY design, allocating cells does not provide enough information, since depending on the PHY used, more or less data can fit in a timeslot. Multi-PHY designs have to define how to network resource needs are measured.
Duty cycle regulations apply to most frequency bands. These regulations vary from country to country, so multi-PHY designs need to comply with local regulations.
6LoWPAN has been initially designed with IEEE802.15.4 O-QPSK in mind. Header compression, fragmentation and reassembly are the main tasks of this adaptive layer. However, in this new context, other PHYs allow to send more than 127 bytes in one frame. 6LoWPAN functionalities should be adapted to efficiently fit in the layer below. This includes the sizes of the fragments, that should be calculated depending on the PHY to be used and the maximum amount of data that can transport, given the length of the timeslot.
In multi-PHY design, RPL is impacted in several ways: Objective Functions must now consider more than one PHY, and each node's rank must be calculated accordingly.
A multi-PHY design may consider new Objective Functions that take into account the difference in throughput, resource occupancy and energy consumption of each PHY. For example, in OF0 [RFC6552] , the 'rank_factor' can have a different value for each PHY, depending on its characteristics.
This document discusses a number of elements to consider when designing a multi-PHY solution based on 6TiSCH. It does not define a new protocol.
This document does not require any IANA actions.
| [I-D.ietf-6tisch-architecture] | Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Internet-Draft draft-ietf-6tisch-architecture-14, April 2018. |
| [I-D.ietf-6tisch-terminology] | Palattella, M., Thubert, P., Watteyne, T. and Q. Wang, "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", Internet-Draft draft-ietf-6tisch-terminology-10, March 2018. |
| [RFC6552] | Thubert, P., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, DOI 10.17487/RFC6552, March 2012. |
| [I-D.ietf-6tisch-6top-protocol] | Wang, Q., Vilajosana, X. and T. Watteyne, "6TiSCH Operation Sublayer Protocol (6P)", Internet-Draft draft-ietf-6tisch-6top-protocol-12, June 2018. |