idnits 2.17.1 draft-munoz-6tisch-multi-phy-nodes-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 2124 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154g' is mentioned on line 325, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-14 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH J. Munoz, Ed. 3 Internet-Draft Inria 4 Intended status: Informational X. Vilajosana 5 Expires: January 3, 2019 Universitat Oberta de Catalunya 6 T. Chang 7 Inria 8 July 2, 2018 10 Problem Statement for Generalizing 6TiSCH to Multiple PHYs 11 draft-munoz-6tisch-multi-phy-nodes-00 13 Abstract 15 The present document describes the needs that arise when considering 16 to use more than one PHY in a IPv6 over the TSCH mode of 17 IEEE802.15.4e (6TiSCH) network. These considerations are present in: 18 the choice of the PHY, the MAC layer -TSCH- configuration, the 6top 19 protocol, 6LoWPAN and RPL. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 3, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Neighbor Considerations . . . . . . . . . . . . . . . . . . . 3 57 3. MAC Sub-Layer Considerations . . . . . . . . . . . . . . . . 4 58 3.1. Network Formation . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Discovering Node PHY Capabilities . . . . . . . . . . . . 4 60 3.3. TSCH Configuration . . . . . . . . . . . . . . . . . . . 5 61 3.3.1. Timeslot Duration . . . . . . . . . . . . . . . . . . 5 62 3.3.2. Channel Hopping Sequence . . . . . . . . . . . . . . 5 63 4. 6top Sub-Layer Considerations . . . . . . . . . . . . . . . . 6 64 4.1. Resource Allocation . . . . . . . . . . . . . . . . . . . 6 65 4.2. Duty Cycle Regulations . . . . . . . . . . . . . . . . . 6 66 5. 6LoWPAN Considerations . . . . . . . . . . . . . . . . . . . 6 67 6. RPL Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 9.2. Informative References . . . . . . . . . . . . . . . . . 7 73 9.3. Other Informative References . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 The protocol stack in a IPv6 over the TSCH mode of IEEE802.15.4e 79 (6TiSCH) network is defined by multiple protocols covering multiple 80 layers starting from the link layer, up to the application layer 81 [I-D.ietf-6tisch-architecture]. This protocol stack sits on top of 82 the IEEE802.15.4 O-QPSK PHY, at 2.4 GHz, that allows the exchange of 83 frames of 127 B over 16 frequencies at 250 kbps. Since 2012, more 84 PHYs are available within the IEEE802.15.4 specification, e.g. the 85 IEEE802.15.4g amendment [IEEE802154g] of the IEEE802.15.4 standard, 86 designed for Smart Utility Networks (SUN) application, introducing 87 the SUN-OFDM, SUN-FSK and SUN-O-QPSK PHYs. The main differences with 88 the previous IEEE802.15.4 O-QPSK PHY is support of link-layer frames 89 up to 2047 B long, the possibility of being used either at the same 90 2.4 GHz band or in sub-GHz, regionally defined bands, and variable 91 data rate that goes from 6.25 kbps up to 800 kbps. 93 Radio chips supporting all these new PHY configurations are now 94 available, giving the opportunity to implementers to exploit the 95 benefits of this diversity in terms of throughput, range and 96 reliability that each PHY brings with it. 98 However, the adoption of a PHY different from IEEE802.15.4 O-QPSK 99 poses new design considerations across the 6TiSCH protocol stack. 100 Even though layer separation exists between protocols, from the link 101 layer upwards, 6TiSCH protocols have been designed considering one 102 PHY only. This approach of having links over multiple PHYs in the 103 same network is new, and poses up-to-now unknown considerations for 104 network designers. 106 This document describes how the behavior of each item of the 6TiSCH 107 protocol stack may be impacted by the inclusion of multiple PHYs with 108 such different properties. 110 This document makes the assumption that the reader is familiar with 111 the [I-D.ietf-6tisch-terminology] and [I-D.ietf-6tisch-architecture], 112 as well as the protocols mentioned there. 114 Solutions for the considerations here exposed are out of the scope of 115 this document. This document is to be considered only for 116 informative purposes. 118 2. Neighbor Considerations 120 In a low-power wireless network with a single PHY, a neighbor node to 121 a particular node A is any node within its interference domain. If 122 nodes are able to use multiple PHYs, a pair of nodes using a specific 123 PHY may be within the same interference domain and when using another 124 PHY, they may not. In addition, nodes also can communicate over 125 different frequency bands. So now the definition of a neighbor node 126 changes to any device within the same interference domain for a given 127 PHY configuration and frequency band. This modifies how nodes can 128 manage their neighbors' information. 130 Neighbor information is accessed by both the MAC and routing layers. 131 Letting which layer to handle the multiple PHY information changes 132 the network protocol stack significantly. In case of handling by the 133 MAC layer, an entity between MAC and Routing to choose which PHY 134 layer to use is required. This entity could be part of Scheduling 135 Function (Section 4.3). In case of handling by Routing layer, each 136 PHY layer could be considered as a neighbor. For RPL, if only one 137 DODAG exist through the network, a dedicated Objective Function for 138 multiPHY features is required. If each PHY layer has a DODAG 139 corresponding with, the OF for 6TiSCH could be used with little 140 modification. However, this increases the complexity of the network. 142 3. MAC Sub-Layer Considerations 144 The considerations that arise according to the used PHY include 145 network formation, node discovery, and TSCH configuration. 147 3.1. Network Formation 149 Getting nodes to join the network as fast as possible is a major 150 interest to minimize energy consumption. Radio activity is the most 151 power consuming task for nodes, therefore the more time nodes spend 152 listening to get an Enhanced Beacon (EB) the more energy they 153 consume, reducing their lifespan. Considering a current 6TiSCH 154 network, with just one PHY and one frequency band (16 frequencies), 155 nodes have to tune their radios in one frequency wait for an EB. 156 Nodes which are already part of the network transmit EBs in a round- 157 robin fashion on these 16 frequencies. If the node did not receive 158 any EB after some time, it may tune its radio on a different 159 frequency and listen again for an EB. This means a node listen for a 160 long time before hearing an EB. 162 In the case of multiple PHYs, nodes attempting to join the network 163 need to over even more PHYs, until hearing an EB. A mechanism might 164 be needed to reduce join time, for example use a particular PHY for 165 joining. 167 3.2. Discovering Node PHY Capabilities 169 For 6TiSCH networks using one PHY configuration, discovering the PHY 170 neighbor node's capabilities is not necessary. But in a new multiPHY 171 network context, knowing the capabilities of neighbor nodes is 172 important. Once a node is part of the network, it may have not have 173 joined using the most convenient PHY configuration for this pair of 174 nodes. Any of these nodes might then (a) unicast a request its 175 neighbors to get the information about their PHY capabilities, or (b) 176 discover the PHY capabilities of the neighbors by listening for EBs 177 at specific times over other PHYs. 179 If using (a), further choices need to be taken to decide whether 180 nodes would use shared slots or negotiate dedicated timeslots to test 181 the connectivity over other PHYs. Agreeing on which PHY to test and 182 when has to be done under the already tested PHY configuration, and 183 the energy consumption footprint of this process may be too heavy. 184 If using (b), it may take long time until the most efficient PHY 185 configuration is discovered between two nodes. 187 3.3. TSCH Configuration 189 A multi-PHY approach has an impact on timeslot duration and channel 190 hopping sequence. 192 3.3.1. Timeslot Duration 194 The diversity of data rates of the PHYs in the IEEE802.15.4-2015 195 standard makes it challenging to find a timeslot duration that is 196 both efficient and fits all PHYs options. In current 6TiSCH 197 networks, a common practice is to have a timeslot of 10 ms. This is 198 time enough for transmitting a 127 B frame using IEEE802.15.4 O-QPSK, 199 taking roughly 4 ms, to wait for the acknowledgment, leaving a 200 handful of milliseconds for data processing with proper guard times. 202 But for multiple PHYs with data rates going from 6.25 kbps up to 800 203 kbps and with maximum frame size of 2047 B, the time of transmission 204 for a full size packet varies from 0.020 s (800 kbps) to 2.62 s (6.25 205 kbps). With such disparity, considering a timeslot long enough (> 206 2.62 s) to allow the transmission (and its acknowledge frame) of the 207 maximum frame size with the slowest data rate results in a waste of 208 time (network resources) if faster PHY can be used, by leaving the 209 most part of the timeslot unused. Such a long timeslot would cause 210 slotframes to have a duration in the order of minutes (considering 211 for example a slotframe of 101 timeslots), and as tight 212 synchronization is mandatory, multiple KA frames would have to be 213 sent within the same slotframe, considerably reducing the network 214 resources and efficiency. 216 On the other hand, choosing a shorter timeslot poses a rigid 217 limitation in the size of the frames when slow data rates PHYs are 218 used. By having timeslots in the order of 10's of ms, the frame size 219 for slow data rate is heavily reduced: with a 100 ms timeslot, only 220 78 B can be transmitted using 6.25 kbps, without considering time for 221 acknowledgment and guard times. 223 Multi-PHY designs should therefore tune these parameters to find the 224 right trade-off between shorter or longer timeslots (limiting sizes 225 of frames with some PHYs), as well as the size of the slotframe. 227 3.3.2. Channel Hopping Sequence 229 Current 6TiSCH implementations use the 2.4 GHz band, with 16 230 frequencies separated by 5 MHz and 2 MHz wide. Channel hopping 231 sequences use only the frequency number identification. By 232 introducing multiple PHYs, these do not have the same characteristics 233 of channel spacing, bandwidth nor channel numbering. Moreover, 234 channels from different PHYs may overlap. 236 As a result, by only referring to a channel by some index doesn't 237 carry over to multiple PHYs. Multi-PHY designs need to solve how to 238 identify channels. 240 4. 6top Sub-Layer Considerations 242 The 6top sub-layer [I-D.ietf-6tisch-6top-protocol] is responsible for 243 allocating cells between pairs of neighbor nodes. In a multi-PHY 244 environment, cells have different capabilities depending on the PHY 245 used. Moreover, in some frequency bands, duty cycle regulation must 246 be met. 248 4.1. Resource Allocation 250 Current 6TiSCH networks account the network resources allocation in 251 the amount of cells per slotframe a pair of nodes needs. In a multi- 252 PHY design, allocating cells does not provide enough information, 253 since depending on the PHY used, more or less data can fit in a 254 timeslot. Multi-PHY designs have to define how to network resource 255 needs are measured. 257 4.2. Duty Cycle Regulations 259 Duty cycle regulations apply to most frequency bands. These 260 regulations vary from country to country, so multi-PHY designs need 261 to comply with local regulations. 263 5. 6LoWPAN Considerations 265 6LoWPAN has been initially designed with IEEE802.15.4 O-QPSK in mind. 266 Header compression, fragmentation and reassembly are the main tasks 267 of this adaptive layer. However, in this new context, other PHYs 268 allow to send more than 127 bytes in one frame. 6LoWPAN 269 functionalities should be adapted to efficiently fit in the layer 270 below. This includes the sizes of the fragments, that should be 271 calculated depending on the PHY to be used and the maximum amount of 272 data that can transport, given the length of the timeslot. 274 6. RPL Considerations 276 In multi-PHY design, RPL is impacted in several ways: Objective 277 Functions must now consider more than one PHY, and each node's rank 278 must be calculated accordingly. 280 A multi-PHY design may consider new Objective Functions that take 281 into account the difference in throughput, resource occupancy and 282 energy consumption of each PHY. For example, in OF0 [RFC6552] , the 283 'rank_factor' can have a different value for each PHY, depending on 284 its characteristics. 286 7. Security Considerations 288 This document discusses a number of elements to consider when 289 designing a multi-PHY solution based on 6TiSCH. It does not define a 290 new protocol. 292 8. IANA Considerations 294 This document does not require any IANA actions. 296 9. References 298 9.1. Normative References 300 [I-D.ietf-6tisch-architecture] 301 Thubert, P., "An Architecture for IPv6 over the TSCH mode 302 of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work 303 in progress), April 2018. 305 [I-D.ietf-6tisch-terminology] 306 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 307 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 308 draft-ietf-6tisch-terminology-10 (work in progress), March 309 2018. 311 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 312 Protocol for Low-Power and Lossy Networks (RPL)", 313 RFC 6552, DOI 10.17487/RFC6552, March 2012, 314 . 316 9.2. Informative References 318 [I-D.ietf-6tisch-6top-protocol] 319 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 320 Operation Sublayer Protocol (6P)", draft-ietf-6tisch-6top- 321 protocol-12 (work in progress), June 2018. 323 9.3. Other Informative References 325 [IEEE802154g] 326 IEEE standard for Information Technology, "IEEE standard 327 for Information Technology, IEEE Std. 802.15.4, Part. 328 15.4: Wireless Medium Access Control (MAC) and Physical 329 Layer (PHY) Specifications for Low-Rate Wireless Personal 330 Area Networks, June 2011 as amended by IEEE Std. 331 802.15.4g, Part. 15.4: Low-Rate Wireless Personal Area 332 Networks (LR-WPANs) Amendment 3: Physical Layer (PHY) 333 Specifications for Low Data-Rate, Wireless, Smart Metering 334 Utility Networks", April 2012. 336 Authors' Addresses 338 Jonathan Munoz (editor) 339 Inria 340 2 rue Simone Iff 341 Paris 12 75012 342 France 344 Email: jonathan.munoz@inria.fr 346 Xavier Vilajosana 347 Universitat Oberta de Catalunya 348 156 Rambla Poblenou 349 Barcelona, Catalonia 08018 350 Spain 352 Email: xvilajosana@uoc.edu 354 Tengfei Chang 355 Inria 356 2 rue Simone Iff 357 Paris 12 75012 358 France 360 Email: tengfei.chang@inria.fr