idnits 2.17.1 draft-ietf-6lo-use-cases-04.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 : ---------------------------------------------------------------------------- ** There are 35 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2215 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '6lo' is mentioned on line 136, but not defined == Missing Reference: '6lo-ap-nd' is mentioned on line 805, but not defined == Unused Reference: 'I-D.hou-6lo-plc' is defined on line 1036, but no explicit reference was found in the text == Unused Reference: 'IEEE1901.1' is defined on line 1082, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-22) exists of draft-ietf-6lo-nfc-09 == Outdated reference: A later version (-18) exists of draft-ietf-roll-aodv-rpl-02 == Outdated reference: A later version (-01) exists of draft-ietf-6tisch-6top-sfx-00 == Outdated reference: A later version (-10) exists of draft-ietf-6lo-blemesh-02 == Outdated reference: A later version (-05) exists of draft-hou-6lo-plc-03 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group Y-G. Hong 3 Internet-Draft ETRI 4 Intended status: Informational C. Gomez 5 Expires: September 6, 2018 UPC 6 Y-H. Choi 7 ETRI 8 D-Y. Ko 9 SKtelecom 10 AR. Sangi 11 Huaiyin Institute of Technology 12 T. Aanstoot 13 Modio AB 14 S. Chakrabarti 15 March 5, 2018 17 IPv6 over Constrained Node Networks (6lo) Applicability & Use cases 18 draft-ietf-6lo-use-cases-04 20 Abstract 22 This document describes the applicability of IPv6 over constrained 23 node networks (6lo) and provides practical deployment examples. In 24 addition to IEEE 802.15.4, various link layer technologies such as 25 ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, PLC (IEEE 1901.2), 26 and IEEE 802.15.4e (6tisch) are used as examples. The document 27 targets an audience who like to understand and evaluate running end- 28 to-end IPv6 over the constrained node networks connecting devices to 29 each other or to other devices on the Internet (e.g. cloud 30 infrastructure). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 6, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 68 3. 6lo Link layer technologies and possible candidates . . . . . 4 69 3.1. ITU-T G.9959 (specified) . . . . . . . . . . . . . . . . 4 70 3.2. Bluetooth LE (specified) . . . . . . . . . . . . . . . . 4 71 3.3. DECT-ULE (specified) . . . . . . . . . . . . . . . . . . 5 72 3.4. MS/TP (specified) . . . . . . . . . . . . . . . . . . . . 5 73 3.5. NFC (specified) . . . . . . . . . . . . . . . . . . . . . 6 74 3.6. PLC (specified) . . . . . . . . . . . . . . . . . . . . . 7 75 3.7. IEEE 802.15.4e (specified) . . . . . . . . . . . . . . . 7 76 3.8. LTE MTC (example of a potential candidate) . . . . . . . 8 77 3.9. Comparison between 6lo Link layer technologies . . . . . 9 78 4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 10 79 4.1. jupitermesh in Smart Grid using 6lo in network layer . . 10 80 4.2. Wi-SUN usage of 6lo stacks . . . . . . . . . . . . . . . 12 81 4.3. G3-PLC usage of 6lo in network layer . . . . . . . . . . 13 82 4.4. Netricity usage of 6lo in network layer . . . . . . . . . 14 83 5. Design Space and Guidelines for 6lo Deployment . . . . . . . 15 84 5.1. Design Space Dimensions for 6lo Deployment . . . . . . . 15 85 5.2. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) . . . . 17 86 6. 6lo Use Case Examples . . . . . . . . . . . . . . . . . . . . 18 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 92 10.2. Informative References . . . . . . . . . . . . . . . . . 22 93 Appendix A. Other 6lo Use Case Examples . . . . . . . . . . . . 24 94 A.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 24 95 A.2. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 25 96 A.3. Use case of MS/TP: Building Automation Networks . . . . . 26 97 A.4. Use case of NFC: Alternative Secure Transfer . . . . . . 26 98 A.5. Use case of PLC: Smart Grid . . . . . . . . . . . . . . . 27 99 A.6. Use case of IEEE 802.15.4e: Industrial Automation . . . . 28 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 102 1. Introduction 104 Running IPv6 on constrained node networks has different features from 105 general node networks due to the characteristics of constrained node 106 networks such as small packet size, short link-layer address, low 107 bandwidth, network topology, low power, low cost, and large number of 108 devices [RFC4919][RFC7228]. For example, some IEEE 802.15.4 link 109 layers have a frame size of 127 octets and IPv6 requires the layer 110 below to support an MTU of 1280 bytes, therefore an appropriate 111 fragmentation and reassembly adaptation layer must be provided at the 112 layer below IPv6. Also, the limited size of IEEE 802.15.4 frame and 113 low energy consumption requirements make the need for header 114 compression. The IETF 6LoPWAN (IPv6 over Low powerWPAN) working 115 group published an adaptation layer for sending IPv6 packets over 116 IEEE 802.15.4 [RFC4944], which includes a compression format for IPv6 117 datagrams over IEEE 802.15.4-based networks [RFC6282], and Neighbor 118 Discovery Optimization for 6LoPWAN [RFC6775]. 120 As IoT (Internet of Things) services become more popular, IPv6 over 121 various link layer technologies such as Bluetooth Low Energy 122 (Bluetooth LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless 123 Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token 124 Passing (MS/TP), Near Field Communication (NFC), Power Line 125 Communication (PLC), and IEEE 802.15.4e (TSCH), have been defined at 126 [IETF_6lo] working group. IPv6 stacks for constrained node networks 127 use a variation of the 6LoWPAN stack applied to each particular link 128 layer technology. 130 In the 6LoPWAN working group, the [RFC6568], "Design and Application 131 Spaces for 6LoWPANs" was published and it describes potential 132 application scenarios and use cases for low-power wireless personal 133 area networks. Hence, this 6lo applicability document aims to 134 provide guidance to an audience who are new to IPv6-over-low-power 135 networks concept and want to assess if variance of 6LoWPAN stack 136 [6lo] can be applied to the constrained layer two (L2) network of 137 their interest. This 6lo applicability document puts together 138 various design space dimensions such as deployment, network size, 139 power source, connectivity, multi-hop communication, traffic pattern, 140 security level, mobility, and QoS requirements etc. In addition, it 141 describes a few set of 6LoPWAN application scenarios and practical 142 deployment as examples. 144 This document provides the applicability and use cases of 6lo, 145 considering the following aspects: 147 o 6lo applicability and use cases MAY be uniquely different from 148 those of 6LoWPAN defined for IEEE 802.15.4. 150 o It SHOULD cover various IoT related wire/wireless link layer 151 technologies providing practical information of such technologies. 153 o A general guideline on how the 6LoWPAN stack can be modified for a 154 given L2 technology. 156 o Example use cases and practical deployment examples. 158 2. Conventions and Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 3. 6lo Link layer technologies and possible candidates 166 3.1. ITU-T G.9959 (specified) 168 The ITU-T G.9959 Recommendation [G.9959] targets low-power Personal 169 Area Networks (PANs), and defines physical layer and link layer 170 functionality. Physical layers of 9.6 kbit/s, 40 kbit/s and 100 171 kbit/s are supported. G.9959 defines how a unique 32-bit HomeID 172 network identifier is assigned by a network controller and how an 173 8-bit NodeID host identifier is allocated to each node. NodeIDs are 174 unique within the network identified by the HomeID. The G.9959 175 HomeID represents an IPv6 subnet that is identified by one or more 176 IPv6 prefixes [RFC7428]. The ITU-T G.9959 can be used for smart home 177 applications. 179 3.2. Bluetooth LE (specified) 181 Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 182 4.1, and developed even further in successive versions. Bluetooth 183 SIG has also published Internet Protocol Support Profile (IPSP). The 184 IPSP enables discovery of IP-enabled devices and establishment of 185 link-layer connection for transporting IPv6 packets. IPv6 over 186 Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or 187 newer. 189 Many Devices such as mobile phones, notebooks, tablets and other 190 handheld computing devices which support Bluetooth 4.0 or subsequent 191 chipsets also support the low-energy variant of Bluetooth. Bluetooth 192 LE is also being included in many different types of accessories that 193 collaborate with mobile devices such as phones, tablets and notebook 194 computers. An example of a use case for a Bluetooth LE accessory is 195 a heart rate monitor that sends data via the mobile phone to a server 196 on the Internet [RFC7668]. A typical usage of Bluetooth LE is 197 smartphone-based interaction with constrained devices. Bluetooth LE 198 was originally designed to enable star topology networks. However, 199 recent Bluetooth versions support the formation of extended 200 topologies, and IPv6 support for mesh networks of Bluetooth LE 201 devices is being developed [I-D.ietf-6lo-blemesh] 203 3.3. DECT-ULE (specified) 205 DECT ULE is a low power air interface technology that is designed to 206 support both circuit switched services, such as voice communication, 207 and packet mode data services at modest data rate. 209 The DECT ULE protocol stack consists of the PHY layer operating at 210 frequencies in the 1880 - 1920 MHz frequency band depending on the 211 region and uses a symbol rate of 1.152 Mbps. Radio bearers are 212 allocated by use of FDMA/TDMA/TDD techniques. 214 In its generic network topology, DECT is defined as a cellular 215 network technology. However, the most common configuration is a star 216 network with a single Fixed Part (FP) defining the network with a 217 number of Portable Parts (PP) attached. The MAC layer supports 218 traditional DECT as this is used for services like discovery, 219 pairing, security features etc. All these features have been reused 220 from DECT. 222 The DECT ULE device can switch to the ULE mode of operation, 223 utilizing the new ULE MAC layer features. The DECT ULE Data Link 224 Control (DLC) provides multiplexing as well as segmentation and re- 225 assembly for larger packets from layers above. The DECT ULE layer 226 also implements per-message authentication and encryption. The DLC 227 layer ensures packet integrity and preserves packet order, but 228 delivery is based on best effort. 230 The current DECT ULE MAC layer standard supports low bandwidth data 231 broadcast. However the usage of this broadcast service has not yet 232 been standardized for higher layers [RFC8105]. DECT-ULE can be used 233 for smart metering in a home. 235 3.4. MS/TP (specified) 237 Master-Slave/Token-Passing (MS/TP) is a Medium Access Control (MAC) 238 protocol for the RS-485 [TIA-485-A] physical layer and is used 239 primarily in building automation networks. 241 An MS/TP device is typically based on a low-cost microcontroller with 242 limited processing power and memory. These constraints, together 243 with low data rates and a small MAC address space, are similar to 244 those faced in 6LoWPAN networks. MS/TP differs significantly from 245 6LoWPAN in at least three respects: a) MS/TP devices are typically 246 mains powered, b) all MS/TP devices on a segment can communicate 247 directly so there are no hidden node or mesh routing issues, and c) 248 the latest MS/TP specification provides support for large payloads, 249 eliminating the need for fragmentation and reassembly below IPv6. 251 MS/TP is designed to enable multidrop networks over shielded twisted 252 pair wiring. It can support network segments up to 1000 meters in 253 length at a data rate of 115.2 kbit/s or segments up to 1200 meters 254 in length at lower bit rates. An MS/TP interface requires only a 255 UART, an RS-485 [TIA-485-A] transceiver with a driver that can be 256 disabled, and a 5 ms resolution timer. The MS/TP MAC is typically 257 implemented in software. 259 Because of its superior "range" (~1 km) compared to many low power 260 wireless data links, MS/TP may be suitable to connect remote devices 261 (such as district heating controllers) to the nearest building 262 control infrastructure over a single link [RFC8163]. MS/TP can be 263 used for building automation networks. 265 3.5. NFC (specified) 267 NFC technology enables simple and safe two-way interactions between 268 electronic devices, allowing consumers to perform contactless 269 transactions, access digital content, and connect electronic devices 270 with a single touch. NFC complements many popular consumer level 271 wireless technologies, by utilizing the key elements in existing 272 standards for contactless card technology (ISO/IEC 14443 A&B and 273 JIS-X 6319-4). NFC can be compatible with existing contactless card 274 infrastructure and it enables a consumer to utilize one device across 275 different systems. 277 Extending the capability of contactless card technology, NFC also 278 enables devices to share information at a distance that is less than 279 10 cm with a maximum communication speed of 424 kbps. Users can 280 share business cards, make transactions, access information from a 281 smart poster or provide credentials for access control systems with a 282 simple touch. 284 NFC's bidirectional communication ability is ideal for establishing 285 connections with other technologies by the simplicity of touch. In 286 addition to the easy connection and quick transactions, simple data 287 sharing is also available [I-D.ietf-6lo-nfc]. NFC can be used for 288 secure transfer in healthcare services. 290 3.6. PLC (specified) 292 PLC is a data transmission technique that utilizes power conductors 293 as medium. Unlike other dedicated communication infrastructure, 294 power conductors are widely available indoors and outdoors. 295 Moreover, wired technologies are more susceptible to cause 296 interference but are more reliable than their wireless counterparts. 297 PLC is a data transmission technique that utilizes power conductors 298 as medium. 300 The below table shows some available open standards defining PLC. 302 +-------------+-----------------+------------+-----------+----------+ 303 | PLC Systems | Frequency Range | Type | Data Rate | Distance | 304 +-------------+-----------------+------------+-----------+----------+ 305 | IEEE1901 | <100MHz | Broadband | 200Mbps | 1000m | 306 | | | | | | 307 | IEEE1901.1 | <15MHz | PLC-IoT | 10Mbps | 2000m | 308 | | | | | | 309 | IEEE1901.2 | <500kHz | Narrowband | 200Kbps | 3000m | 310 +-------------+-----------------+------------+-----------+----------+ 312 Table 1: Some Available Open Standards in PLC 314 [IEEE1901] defines a broadband variant of PLC but is effective within 315 short range. This standard addresses the requirements of 316 applications with high data rate such as: Internet, HDTV, Audio, 317 Gaming etc. Broadband operates on OFDM (Orthogonal Frequency 318 Division Multiplexing) modulation. 320 [IEEE1901.2] defines a narrowband variant of PLC with less data rate 321 but significantly higher transmission range that could be used in an 322 indoor or even an outdoor environment. It is applicable to typical 323 IoT applications such as: Building Automation, Renewable Energy, 324 Advanced Metering, Street Lighting, Electric Vehicle, Smart Grid etc. 325 Moreover, IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer 326 and fully endorses the security scheme defined in 802.15.4 [RFC8036]. 327 A typical use case of PLC is smart grid. 329 3.7. IEEE 802.15.4e (specified) 331 The Time Slotted Channel Hopping (TSCH) mode was introduced in the 332 IEEE 802.15.4-2015 standard. In a TSCH network, all nodes are 333 synchronized. Time is sliced up into timeslots. The duration of a 334 timeslot, typically 10ms, is large enough for a node to send a full- 335 sized frame to its neighbor, and for that neighbor to send back an 336 acknowledgment to indicate successful reception. Timeslots are 337 grouped into one of more slotframes, which repeat over time. 339 All the communication in the network is orchestrated by a 340 communication schedule which indicates to each node what to do in 341 each of the timeslots of a slotframe: transmit, listen or sleep. The 342 communication schedule can be built so that the right amount of link- 343 layer resources (the cells in the schedule) are scheduled to satisfy 344 the communication needs of the applications running on the network, 345 while keeping the energy consumption of the nodes very low. Cells 346 can be scheduled in a collision-free way, introducing a high level of 347 determinism to the network. 349 A TSCH network exploits channel hopping: subsequent packet exchanges 350 between neighbor nodes are done on a different frequency. This means 351 that, if a frame isn't received, the transmitter node will re- 352 transmitt the frame on a different frequency. The resulting "channel 353 hopping" efficiently combats external interference and multi-path 354 fading. 356 The main benefits of IEEE 802.15.4 TSCH are: 358 - ultra high reliability. Off-the-shelf commercial products offer 359 over 99.999% end-to-end reliability. 361 - ultra low-power consumption. Off-the-shelf commercial products 362 offer over a decade of battery lifetime. 364 - 6TiSCH at IETF defines communications of TSCH network and it 365 uses 6LoWPAN stack [RFC7554]. 367 IEEE 802.15.4e can be used for industrial automation. 369 3.8. LTE MTC (example of a potential candidate) 371 LTE category defines the overall performance and capabilities of the 372 UE (User Equipment). For example, the maximum down rate of category 373 1 UE and category 2 UE are 10.3 Mbit/s and 51.0 Mbit/s respectively. 374 There are many categories in LTE standards. 3GPP standards defined 375 the category 0 to be used for low rate IoT service in release 12. 376 Since category 1 and category 0 could be used for low rate IoT 377 service, these categories are called LTE MTC (Machine Type 378 Communication) [LTE_MTC]. And 3GPP standards defined the MTC 379 Enhancements in release 13. 381 LTE MTC offer advantages in comparison to above category 2 and is 382 appropriate to be used for low rate IoT services such as low power 383 and low cost. 385 LTE MTC can be used for tracking services, such as asset tracker, 386 bicycle/cat tracker and etc with national wide. LTE MTC can be also 387 used for monitoring & control service, such as car mobility record 388 and weather observation that require much more traffic than other IoT 389 services. Since the traffic collected by other IoT devices such as 390 LoRa, Z-wave and BLE is small, LTE MTC can be used as a bachhaul of 391 other IoT networks. 393 3.9. Comparison between 6lo Link layer technologies 395 In above clauses, various 6lo Link layer technologies and a possible 396 candidate are described. The following table shows that dominant 397 paramters of each use case corresponding to the 6lo link layer 398 technology. 400 +-----------+--------+--------+--------+--------+--------+--------+--------+ 401 | | Z-Wave | BLE |DECT-ULE| MS/TP | NFC | PLC | TSCH | 402 +-----------+--------+--------+--------+--------+--------+--------+--------+ 403 | | Home |Interact| |Building| Health-| |Industr-| 404 | Usage | Auto- |w/ Smart| Meter | Auto- | care | Smart |ial Aut-| 405 | | mation | Phone | Reading| mation | Service| Grid | mation | 406 +-----------+--------+--------+--------+--------+--------+--------+--------+ 407 | Topology | L2-mesh| Star | Star | MS/TP | P2P | Star | | 408 | & | or | & | | | | Tree | Mesh | 409 | Subnet | L3-mesh| Mesh | No mesh| No mesh| L2-mesh| Mesh | | 410 +-----------+--------+--------+--------+--------+--------+--------+--------+ 411 | | | | | | | | | 412 | Mobility | No | Low | No | No |Moderate| No | No | 413 | Reqmt | | | | | | | | 414 +-----------+--------+--------+--------+--------+--------+--------+--------+ 415 | | High + | | High + | High + | | High + | High + | 416 | Security | Privacy| Parti- | Privacy| Authen.| High |Encrypt.| Privacy| 417 | Reqmt |required| ally |required|required| |required|required| 418 +-----------+--------+--------+--------+--------+--------+--------+--------+ 419 | | | | | | | | | 420 | Buffering | Low | Low | Low | Low | Low | Low | Low | 421 | Reqmt | | | | | | | | 422 +-----------+--------+--------+--------+--------+--------+--------+--------+ 423 | Latency, | | | | | | | | 424 | QoS | High | Low | Low | High | High | Low | High | 425 | Reqmt | | | | | | | | 426 +-----------+--------+--------+--------+--------+--------+--------+--------+ 427 | | | | | | | | | 428 | Data |Infrequ-|Infrequ-|Infrequ-|Frequent| Small |Infrequ-|Infrequ-| 429 | Rate | ent | ent | ent | | | ent | ent | 430 +-----------+--------+--------+--------+--------+--------+--------+--------+ 431 | RFC # | | | | | draft- | draft- | | 432 | or | RFC7428| RFC7668| RFC8105| RFC8163|ietf-6lo|hou-6lo-| RFC7554| 433 | Draft | | | | | -nfc | plc | | 434 +-----------+--------+--------+--------+--------+--------+--------+--------+ 436 Table 2: Comparison between 6lo Link layer technologies 438 4. 6lo Deployment Scenarios 440 4.1. jupitermesh in Smart Grid using 6lo in network layer 442 jupiterMesh is a multi-hop wireless mesh network specification 443 designed mainly for deployment in large geographical areas. Each 444 subnet in jupiterMesh is able to cover an entire neighborhood with 445 thousands of nodes consisting of IPv6-enabled routers and end-points 446 (e.g. hosts). Automated network joining and load balancing allows a 447 seamless deployment of a large number of subnets. 449 The main application domains targeted by jupiterMesh are smart grid 450 and smart cities. This includes, but is not limited to the following 451 applications: 453 o Automated meter reading 455 o Distribution Automation (DA) 457 o Demand-side management (DSM) 459 o Demand-side response (DSR) 461 o Power outage reporting 463 o Street light monitoring and control 465 o Transformer load management 467 o EV charging coordination 469 o Energy theft 471 o Parking space locator 473 jupiterMesh specification is based on the following technologies: 475 o The PHY layer is based on IEEE 802.15.4 SUN specification [IEEE 476 802.15.4-2015], supporting multiple operating modes for deployment 477 in different regulatory domains and deployment scenarios in terms 478 of density and bandwidth requirements. jupiterMesh supports bit 479 rates from 50 kbps to 800 kbps, frame size up to 2048 bytes, up to 480 11 different RF bands and 3 modulation types (i.e., FSK, OQPSK and 481 OFDM). 483 o The MAC layer is based on IEEE 802.15.4 TSCH specification [IEEE 484 802.15.4-2015]. With frequency hopping capability, TSCH MAC 485 supports scheduling of dedicated timeslot enabling bandwidth 486 management and QoS. 488 o The security layer consists of a certificate-based (i.e. X.509) 489 network access authentication using EAP-TLS, with IEEE 490 802.15.9-based KMP (Key Management Protocol) transport, and PANA 491 and link layer encryption using AES-128 CCM as specified in IEEE 492 802.15.4-2015 [IEEE 802.15.4-2015]. 494 o Address assignment and network configuration are specified using 495 DHCPv6 [RFC3315]. Neighbor Discovery (ND) [RFC6775] and stateless 496 address auto-configuration (SLAAC) are not supported. 498 o The network layer consists of IPv6, ICMPv6 and 6lo/6LoPWAN header 499 compression [RFC6282]. Multicast is supported using MPL. Two 500 domains are supported, a delay sensitive MPL domain for low 501 latency applications (e.g. DSM, DSR) and a delay insensitive one 502 for less stringent applications (e.g. OTA file transfers). 504 o The routing layer uses RPL [RFC6550] in non-storing mode with the 505 MRHOF objective function based on the ETX metric. 507 4.2. Wi-SUN usage of 6lo stacks 509 Wireless Smart Ubiquitous Network (Wi-SUN) is a technology based on 510 the IEEE 802.15.4g standard. Wi-SUN networks support star and mesh 511 topologies, as well as hybrid star/mesh deployments, but are 512 typically laid out in a mesh topology where each node relays data for 513 the network to provide network connectivity. Wi-SUN networks are 514 deployed on both powered and battery-operated devices. 516 The main application domains targeted by Wi-SUN are smart utility and 517 smart city networks. This includes, but is not limited to the 518 following applications: 520 o Advanced Metering Infrastructure (AMI) 522 o Distribution Automation 524 o Home Energy Management 526 o Infrastructure Management 528 o Intelligent Transportation Systems 530 o Smart Street Lighting 532 o Agriculture 534 o Structural health (bridges, buildings etc) 536 o Monitoring and Asset Management 538 o Smart Thermostats, Air Conditioning and Heat Controls 540 o Energy Usage Information Displays 541 The Wi-SUN Alliance Field Area Network (FAN) covers primarily outdoor 542 networks, and its specification is oriented towards meeting the more 543 rigorous challenges of these environments. Examples include from 544 meter to outdoor access point/router for AMI and DR, or between 545 switches for DA. However, nothing in the profile restricts it to 546 outdoor use. It has the following features; 548 o Open standards based on IEEE802, IETF, TIA, ETSI 550 o Architecture is an IPv6 frequency hopping wireless mesh network 551 with enterprise level security 553 o Simple infrastructure which is low cost, low complexity 555 o Enhanced network robustness, reliability, and resilience to 556 interference, due to high redundancy and frequency hopping 558 o Enhaced scalability, long range, and energy friendliness 560 o Supports multiple global license-exempt sub GHz bands 562 o Multi-vendor interoperability 564 o Very low power modes in development permitting long term battery 565 operation of network nodes 567 In the Wi-SUN FAN specification, adaptation layer based on 6lo and 568 IPv6 network layer are described. So, IPv6 protocol suite including 569 TCP/UDP, 6lo Adaptation, Header Compression, DHCPv6 for IP address 570 management, Routing using RPL, ICMPv6, and Unicast/Multicast 571 forwarding is utilized. 573 4.3. G3-PLC usage of 6lo in network layer 575 G3-PLC [G3-PLC] is a narrow-band PLC technology that is based on 576 ITU-T G.9903 Recommendation [G.9903]. G3-PLC supports multi-hop mesh 577 network, and facilitates highly-reliable, long-range communication. 578 With the abilities to support IPv6 and to cross transformers, G3-PLC 579 is regarded as one of the next-generation NB-PLC technologies. 580 G3-PLC has got massive deployments over several countries, e.g. 581 Japan and France. 583 The main application domains targeted by G3-PLC are smart grid and 584 smart cities. This includes, but is not limited to the following 585 applications: 587 o Smart Metering 588 o Vehicle-to-Grid Communication 590 o Demand Response (DR) 592 o Distribution Automation 594 o Home/Building Energy Management Systems 596 o Smart Street Lighting 598 o Advanced Metering Infrastructure (AMI) backbone network 600 o Wind/Solar Farm Monitoring 602 In the G3-PLC specification, the 6lo adaptation layer utilizes the 603 6LoWPAN functions (e.g. header compression, fragmentation and 604 reassembly) so as to enable IPv6 packet transmission. LOADng, which 605 is a lightweight variant of AODV, is applied as the mesh-under 606 routing protocol in G3-PLC networks. Address assignment and network 607 configuration are based on the bootstrapping protocol specified in 608 ITU-T G.9903. The network layer consists of IPv6 and ICMPv6 while 609 the transport protocol UDP is used for data transmission. 611 4.4. Netricity usage of 6lo in network layer 613 The Netricity program in HomePlug Powerline Alliance [NETRICITY] 614 promotes the adoption of products built on the IEEE 1901.2 Low- 615 Frequency Narrow-Band PLC standard, which provides for urban and long 616 distance communications and propagation through transformers of the 617 distribution network using frequencies below 500 kHz. The technology 618 also addresses requirements that assure communication privacy and 619 secure networks. 621 The main application domains targeted by Netricity are smart grid and 622 smart cities. This includes, but is not limited to the following 623 applications: 625 o Utility grid modernization 627 o Distribution automation 629 o Meter-to-Grid connectivity 631 o Micro-grids 633 o Grid sensor communications 635 o Load control 636 o Demand response 638 o Net metering 640 o Street Lighting control 642 o Photovoltaic panel monitoring 644 Netricity system architecture is based on the PHY and MAC layers of 645 IEEE 1901.2 PLC standard. Regarding the 6lo adaptation layer and 646 IPv6 network layer, Netricity utilizes IPv6 protocol suite including 647 6lo/6LoWPAN header compression, DHCPv6 for IP address management, RPL 648 routing protocol, ICMPv6, and unicast/multicast forwarding. Note 649 that the layer 3 routing in Netricity uses RPL in non-storing mode 650 with the MRHOF objective function based on the own defined Estimated 651 Transmission Time (ETT) metric. 653 5. Design Space and Guidelines for 6lo Deployment 655 5.1. Design Space Dimensions for 6lo Deployment 657 The [RFC6568] lists the dimensions used to describe the design space 658 of wireless sensor networks in the context of the 6LoWPAN working 659 group. The design space is already limited by the unique 660 characteristics of a LoWPAN (e.g. low power, short range, low bit 661 rate). In [RFC6568], the following design space dimensions are 662 described: Deployment, Network size, Power source, Connectivity, 663 Multi-hop communication, Traffic pattern, Mobility, Quality of 664 Service (QoS). However, in this document, the following design space 665 dimensions are considered: 667 o Deployment/Bootstrapping: 6lo nodes can be connected randomly, or 668 in an organized manner. The bootstrapping has different 669 characteristics for each link layer technology. 671 o Topology: Topology of 6lo networks may inherently follow the 672 characteristics of each link layer technology. Point-to-point, 673 star, tree or mesh topologies can be configured, depending on the 674 link layer technology considered. 676 o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the 677 characteristics of each link layer technology. Some link layer 678 technologies may support L2-mesh and some may not support. 680 o Multi-link subnet, single subnet: The selection of multi-link 681 subnet and single subnet depends on connectivity and the number of 682 6lo nodes. 684 o Data rate: Typically, the link layer technologies of 6lo have low 685 rate of data transmission. But, by adjusting the MTU, it can 686 deliver higher upper layer data rate. 688 o Buffering requirements: Some 6lo use case may require more data 689 rate than the link layer technology support. In this case, a 690 buffering mechanism to manage the data is required. 692 o Security and Privacy Requirements: Some 6lo use case can involve 693 transferring some important and personal data between 6lo nodes. 694 In this case, high-level security support is required. 696 o Mobility across 6lo networks and subnets: The movement of 6lo 697 nodes depends on the 6lo use case. If the 6lo nodes can move or 698 moved around, a mobility management mechanism is required. 700 o Time synchronization requirements: The requirement of time 701 synchronization of the upper layer service is dependent on the 6lo 702 use case. For some 6lo use case related to health service, the 703 measured data must be recorded with exact time and must be 704 transferred with time synchronization. 706 o Reliability and QoS: Some 6lo use case requires high reliability, 707 for example real-time service or health-related services. 709 o Traffic patterns: 6lo use cases may involve various traffic 710 patterns. For example, some 6lo use case may require short data 711 length and random transmission. Some 6lo use case may require 712 continuous data and periodic data transmission. 714 o Security Bootstrapping: Without the external operations, 6lo nodes 715 must have the security bootstrapping mechanism. 717 o Power use strategy: to enable certain use cases, there may be 718 requirements on the class of energy availability and the strategy 719 followed for using power for communication [RFC7228]. Each link 720 layer technology defines a particular power use strategy which may 721 be tuned [I-D.ietf-lwig-energy-efficient]. Readers are expected 722 to be familiar with [RFC7228] terminology. 724 o Update firmware requirements: Most 6lo use cases will need a 725 mechanism for updating firmware. In these cases support for over 726 the air updates are required, probably in a broadcast mode when 727 bandwith is low and the number of identical devices is high. 729 o Wired vs. Wireless: Plenty of 6lo link layer technologies are 730 wireless, except MS/TP and PLC. The selection of wired or 731 wireless link layer technology is mainly dependent on the 732 requirement of 6lo use cases and the characteristics of wired/ 733 wireless technologies. For example, some 6lo use cases may 734 require easy and quick deployment, whereas others may need a 735 continuous source of power. 737 5.2. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) 739 The following guideline targets new candidate constrained L2 740 technologies that may be considered for running modified 6LoWPAN 741 stack on top. The modification of 6LoWPAN stack should be based on 742 the following: 744 o Addressing Model: Addressing model determines whether the device 745 is capable of forming IPv6 Link-local and global addresses and 746 what is the best way to derive the IPv6 addresses for the 747 constrained L2 devices. Whether the device is capable of forming 748 IPv6 Link-local and global addresses, L2-address-derived IPv6 749 addresses are specified in [RFC4944], but there exist implications 750 for privacy. For global usage, a unique IPv6 address must be 751 derived using an assigned prefix and a unique interface ID. 752 [RFC8065] provides such guidelines. For MAC derived IPv6 address, 753 please refer to [RFC8163] for IPv6 address mapping examples. 754 Broadcast and multicast support are dependent on the L2 networks. 755 Most low-power L2 implementations map multicast to broadcast 756 networks. So care must be taken in the design when to use 757 broadcast and try to stick to unicast messaging whenever possible. 759 o MTU Considerations: The deployment SHOULD consider their need for 760 maximum transmission unit (MTU) of a packet over the link layer 761 and should consider if fragmentation and reassembly of packets are 762 needed at the 6LoWPAN layer. For example, if the link layer 763 supports fragmentation and reassembly of packets, then 6LoWPAN 764 layer may skip supporting fragmentation/reassembly. In fact, for 765 most efficiency, choosing a low-power link layer that can carry 766 unfragmented application packets would be optimum for packet 767 transmission if the deployment can afford it. Please refer to 6lo 768 RFCs [RFC7668], [RFC8163], [RFC8105] for example guidance. 770 o Mesh or L3-Routing: 6LoWPAN specifications do provide mechanisms 771 to support for mesh routing at L2. [RFC6550] defines layer three 772 (L3) routing for low power lossy networks using directed graphs. 773 6LoWPAN is routing protocol agnostic and other L2 or L3 routing 774 protocols can be run using a 6LoWPAN stack. 776 o Address Assignment: 6LoWPAN requires that IPv6 Neighbor Discovery 777 for low power networks [RFC6775] be used for autoconfiguration of 778 stateless IPv6 address assignment. Considering the energy 779 sensitive networks [RFC6775] makes optimization from classical 780 IPv6 ND [RFC4861] protocol. It is the responsibility of the 781 deployment to ensure unique global IPv6 addresses for the Internet 782 connectivity. For local-only connectivity IPv6 ULA may be used. 783 [RFC6775] specifies the 6LoWPAN border router(6LBR) which is 784 responsible for prefix assignment to the 6lo/6LoWPAN network. 6LBR 785 can be connected to the Internet or Enterprise network via its one 786 of the interfaces. Please refer to [RFC7668] and [RFC8105] for 787 examples of address assignment considerations. In addition, 788 privacy considerations [RFC8065] must be consulted for 789 applicability. In certain scenarios, the deployment may not 790 support autoconfiguration of IPv6 addressing due to regulatory and 791 business reasons and may choose to offer a separate address 792 assignment service. 794 o Header Compression: IPv6 header compression [RFC6282] is a vital 795 part of IPv6 over low power communication. Examples of header 796 compression for different link-layers specifications are found in 797 [RFC7668], [RFC8163], [RFC8105]. A generic header compression 798 technique is specified in [RFC7400]. 800 o Security and Encryption: Though 6LoWPAN basic specifications do 801 not address security at the network layer, the assumption is that 802 L2 security must be present. In addition, application level 803 security is highly desirable. The working groups [ace] and [core] 804 should be consulted for application and transport level security. 805 6lo working group is working on address authentication [6lo-ap-nd] 806 and secure bootstrapping is also being discussed at IETF. 807 However, there may be different levels of security available in a 808 deployment through other standards such as hardware level security 809 or certificates for initial booting process. Encryption is 810 important if the implementation can afford it. 812 o Additional processing: [RFC8066] defines guidelines for ESC 813 dispatch octets use in the 6LoWPAN header. An implementation may 814 take advantage of ESC header to offer a deployment specific 815 processing of 6LoWPAN packets. 817 6. 6lo Use Case Examples 819 As IPv6 stacks for constrained node networks use a variation of the 820 6LoWPAN stack applied to each particular link layer technology, 821 various 6lo use cases can be provided. In this clause, one 6lo use 822 case example of Bluetooth LE (Smartphone-Based Interaction with 823 Constrained Devices) is described. Other 6lo use case examples are 824 described in Appendix. 826 The key feature behind the current high Bluetooth LE momentum is its 827 support in a large majority of smartphones in the market. Bluetooth 828 LE can be used to allow the interaction between the smartphone and 829 surrounding sensors or actuators. Furthermore, Bluetooth LE is also 830 the main radio interface currently available in wearables. Since a 831 smartphone typically has several radio interfaces that provide 832 Internet access, such as Wi-Fi or 4G, the smartphone can act as a 833 gateway for nearby devices such as sensors, actuators or wearables. 834 Bluetooth LE may be used in several domains, including healthcare, 835 sports/wellness and home automation. 837 Example: Use of Bluetooth LE-based Body Area Network for fitness 839 A person wears a smartwatch for fitness purposes. The smartwatch has 840 several sensors (e.g. heart rate, accelerometer, gyrometer, GPS, 841 temperature, etc.), a display, and a Bluetooth LE radio interface. 842 The smartwatch can show fitness-related statistics on its display. 843 However, when a paired smartphone is in the range of the smartwatch, 844 the latter can report almost real-time measurements of its sensors to 845 the smartphone, which can forward the data to a cloud service on the 846 Internet. In addition, the smartwatch can receive notifications 847 (e.g. alarm signals) from the cloud service via the smartphone. On 848 the other hand, the smartphone may locally generate messages for the 849 smartwatch, such as e-mail reception or calendar notifications. 851 The functionality supported by the smartwatch may be complemented by 852 other devices such as other on-body sensors, wireless headsets or 853 head-mounted displays. All such devices may connect to the 854 smartphone creating a star topology network whereby the smartphone is 855 the central component. Support for extended network topologies (e.g. 856 mesh networks) is being developed as of the writing. 858 7. IANA Considerations 860 There are no IANA considerations related to this document. 862 8. Security Considerations 864 Security considerations are not directly applicable to this document. 865 The use cases will use the security requirements described in the 866 protocol specifications. 868 9. Acknowledgements 870 Carles Gomez has been funded in part by the Spanish Government 871 through the Jose Castillejo CAS15/00336 grant, and through the 872 TEC2016-79988-P grant. His contribution to this work has been 873 carried out in part during his stay as a visiting scholar at the 874 Computer Laboratory of the University of Cambridge. 876 Thomas Watteyne, Pascal Thubert, Xavier Vilajosana, Daniel Migault, 877 and Jianqiang HOU have provided valuable feedback for this draft. 879 Das Subir and Michel Veillette have provided valuable information of 880 jupiterMesh and Paul Duffy has provided valuable information of Wi- 881 SUN for this draft. Also, Jianqiang Hou has provided valuable 882 information of G3-PLC and Netricity for this draft. Kerry Lynn and 883 Dave Robin have provided valuable information of MS/TP and practical 884 use case of MS/TP for this draft. 886 10. References 888 10.1. Normative References 890 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 891 Requirement Levels", BCP 14, RFC 2119, 892 DOI 10.17487/RFC2119, March 1997, 893 . 895 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 896 over Low-Power Wireless Personal Area Networks (6LoWPANs): 897 Overview, Assumptions, Problem Statement, and Goals", 898 RFC 4919, DOI 10.17487/RFC4919, August 2007, 899 . 901 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 902 "Transmission of IPv6 Packets over IEEE 802.15.4 903 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 904 . 906 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 907 Routing Requirements in Low-Power and Lossy Networks", 908 RFC 5826, DOI 10.17487/RFC5826, April 2010, 909 . 911 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 912 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 913 DOI 10.17487/RFC6282, September 2011, 914 . 916 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 917 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 918 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 919 Low-Power and Lossy Networks", RFC 6550, 920 DOI 10.17487/RFC6550, March 2012, 921 . 923 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 924 Application Spaces for IPv6 over Low-Power Wireless 925 Personal Area Networks (6LoWPANs)", RFC 6568, 926 DOI 10.17487/RFC6568, April 2012, 927 . 929 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 930 Bormann, "Neighbor Discovery Optimization for IPv6 over 931 Low-Power Wireless Personal Area Networks (6LoWPANs)", 932 RFC 6775, DOI 10.17487/RFC6775, November 2012, 933 . 935 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 936 Constrained-Node Networks", RFC 7228, 937 DOI 10.17487/RFC7228, May 2014, 938 . 940 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 941 IPv6 over Low-Power Wireless Personal Area Networks 942 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 943 2014, . 945 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 946 over ITU-T G.9959 Networks", RFC 7428, 947 DOI 10.17487/RFC7428, February 2015, 948 . 950 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 951 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 952 Internet of Things (IoT): Problem Statement", RFC 7554, 953 DOI 10.17487/RFC7554, May 2015, 954 . 956 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 957 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 958 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 959 . 961 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 962 Statement for the Routing Protocol for Low-Power and Lossy 963 Networks (RPL) in Advanced Metering Infrastructure (AMI) 964 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 965 . 967 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 968 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 969 February 2017, . 971 [RFC8066] Chakrabarti, S., Montenegro, G., Droms, R., and J. 972 Woodyatt, "IPv6 over Low-Power Wireless Personal Area 973 Network (6LoWPAN) ESC Dispatch Code Points and 974 Guidelines", RFC 8066, DOI 10.17487/RFC8066, February 975 2017, . 977 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 978 M., and D. Barthel, "Transmission of IPv6 Packets over 979 Digital Enhanced Cordless Telecommunications (DECT) Ultra 980 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 981 2017, . 983 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 984 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 985 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 986 May 2017, . 988 10.2. Informative References 990 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 991 C., and M. Carney, "Dynamic Host Configuration Protocol 992 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 993 2003, . 995 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 996 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 997 DOI 10.17487/RFC4861, September 2007, 998 . 1000 [I-D.ietf-6lo-nfc] 1001 Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, 1002 "Transmission of IPv6 Packets over Near Field 1003 Communication", draft-ietf-6lo-nfc-09 (work in progress), 1004 January 2018. 1006 [I-D.ietf-lwig-energy-efficient] 1007 Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy- 1008 Efficient Features of Internet of Things Protocols", 1009 draft-ietf-lwig-energy-efficient-08 (work in progress), 1010 October 2017. 1012 [I-D.ietf-roll-aodv-rpl] 1013 Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S. 1014 Anand, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy 1015 Networks (LLNs)", draft-ietf-roll-aodv-rpl-02 (work in 1016 progress), September 2017. 1018 [I-D.ietf-6tisch-6top-sfx] 1019 Dujovne, D., Grieco, L., Palattella, M., and N. Accettura, 1020 "6TiSCH 6top Scheduling Function Zero / Experimental 1021 (SFX)", draft-ietf-6tisch-6top-sfx-00 (work in progress), 1022 September 2017. 1024 [I-D.ietf-6lo-blemesh] 1025 Gomez, C., Darroudi, S., and T. Savolainen, "IPv6 Mesh 1026 over BLUETOOTH(R) Low Energy using IPSP", draft-ietf-6lo- 1027 blemesh-02 (work in progress), September 2017. 1029 [I-D.satish-6tisch-6top-sf1] 1030 Anamalamudi, S., Liu, B., Zhang, M., Sangi, A., Perkins, 1031 C., and S. Anand, "Scheduling Function One (SF1): hop-by- 1032 hop Scheduling with RSVP-TE in 6tisch Networks", draft- 1033 satish-6tisch-6top-sf1-04 (work in progress), October 1034 2017. 1036 [I-D.hou-6lo-plc] 1037 Hou, J., Hong, Y., and X. Tang, "Transmission of IPv6 1038 Packets over PLC Networks", draft-hou-6lo-plc-03 (work in 1039 progress), December 2017. 1041 [IETF_6lo] 1042 "IETF IPv6 over Networks of Resource-constrained Nodes 1043 (6lo) working group", 1044 . 1046 [TIA-485-A] 1047 "TIA, "Electrical Characteristics of Generators and 1048 Receivers for Use in Balanced Digital Multipoint Systems", 1049 TIA-485-A (Revision of TIA-485)", March 2003, 1050 . 1053 [G3-PLC] "G3-PLC Alliance", . 1055 [NETRICITY] 1056 "Netricity program in HomePlug Powerline Alliance", 1057 . 1059 [G.9959] "International Telecommunication Union, "Short range 1060 narrow-band digital radiocommunication transceivers - PHY 1061 and MAC layer specifications", ITU-T Recommendation", 1062 January 2015. 1064 [G.9903] "International Telecommunication Union, "Narrowband 1065 orthogonal frequency division multiplexing power line 1066 communication transceivers for G3-PLC networks", ITU-T 1067 Recommendation", August 2017. 1069 [LTE_MTC] "3GPP TS 36.306 V13.0.0, 3rd Generation Partnership 1070 Project; Technical Specification Group Radio Access 1071 Network; Evolved Universal Terrestrial Radio Access 1072 (E-UTRA); User Equipment (UE) radio access capabilities 1073 (Release 13)", December 2015. 1075 [IEEE1901] 1076 "IEEE Standard, IEEE Std. 1901-2010 - IEEE Standard for 1077 Broadband over Power Line Networks: Medium Access Control 1078 and Physical Layer Specifications", 2010, 1079 . 1082 [IEEE1901.1] 1083 "IEEE Standard (work-in-progress), IEEE-SA Standards 1084 Board", . 1086 [IEEE1901.2] 1087 "IEEE Standard, IEEE Std. 1901.2-2013 - IEEE Standard for 1088 Low-Frequency (less than 500 kHz) Narrowband Power Line 1089 Communications for Smart Grid Applications", 2013, 1090 . 1093 [BACnet] "ASHRAE, "BACnet-A Data Communication Protocol for 1094 Building Automation and Control Networks", ANSI/ASHRAE 1095 Standard 135-2016", January 2016, 1096 . 1099 Appendix A. Other 6lo Use Case Examples 1101 A.1. Use case of ITU-T G.9959: Smart Home 1103 Z-Wave is one of the main technologies that may be used to enable 1104 smart home applications. Born as a proprietary technology, Z-Wave 1105 was specifically designed for this particular use case. Recently, 1106 the Z-Wave radio interface (physical and MAC layers) has been 1107 standardized as the ITU-T G.9959 specification. 1109 Example: Use of ITU-T G.9959 for Home Automation 1110 Variety of home devices (e.g. light dimmers/switches, plugs, 1111 thermostats, blinds/curtains and remote controls) are augmented with 1112 ITU-T G.9959 interfaces. A user may turn on/off or may control home 1113 appliances by pressing a wall switch or by pressing a button in a 1114 remote control. Scenes may be programmed, so that after a given 1115 event, the home devices adopt a specific configuration. Sensors may 1116 also periodically send measurements of several parameters (e.g. gas 1117 presence, light, temperature, humidity, etc.) which are collected at 1118 a sink device, or may generate commands for actuators (e.g. a smoke 1119 sensor may send an alarm message to a safety system). 1121 The devices involved in the described scenario are nodes of a network 1122 that follows the mesh topology, which is suitable for path diversity 1123 to face indoor multipath propagation issues. The multihop paradigm 1124 allows end-to-end connectivity when direct range communication is not 1125 possible. Security support is required, specially for safety-related 1126 communication. When a user interaction (e.g. a button press) 1127 triggers a message that encapsulates a command, if the message is 1128 lost, the user may have to perform further interactions to achieve 1129 the desired effect (e.g. a light is turned off). A reaction to a 1130 user interaction will be perceived by the user as immediate as long 1131 as the reaction takes place within 0.5 seconds [RFC5826]. 1133 A.2. Use case of DECT-ULE: Smart Home 1135 DECT is a technology widely used for wireless telephone 1136 communications in residential scenarios. Since DECT-ULE is a low- 1137 power variant of DECT, DECT-ULE can be used to connect constrained 1138 devices such as sensors and actuators to a Fixed Part, a device that 1139 typically acts as a base station for wireless telephones. Therefore, 1140 DECT-ULE is specially suitable for the connected home space in 1141 application areas such as home automation, smart metering, safety, 1142 healthcare, etc. 1144 Example: Use of DECT-ULE for Smart Metering 1146 The smart electricity meter of a home is equipped with a DECT-ULE 1147 transceiver. This device is in the coverage range of the Fixed Part 1148 of the home. The Fixed Part can act as a router connected to the 1149 Internet. This way, the smart meter can transmit electricity 1150 consumption readings through the DECT-ULE link with the Fixed Part, 1151 and the latter can forward such readings to the utility company using 1152 Wide Area Network (WAN) links. The meter can also receive queries 1153 from the utility company or from an advanced energy control system 1154 controlled by the user, which may also be connected to the Fixed Part 1155 via DECT-ULE. 1157 A.3. Use case of MS/TP: Building Automation Networks 1159 The primary use case for IPv6 over MS/TP (6LoBAC) is in building 1160 automation networks. [BACnet] is the open international standard 1161 protocol for building automation, and MS/TP is defined in [BACnet] 1162 Clause 9. MS/TP was designed to be a low cost multi-drop field bus 1163 to inter-connect the most numerous elements (sensors and actuators) 1164 of a building automation network to their controllers. A key aspect 1165 of 6LoBAC is that it is designed to co-exist with BACnet MS/TP on the 1166 same link, easing the ultimate transition of some BACnet networks to 1167 native end-to-end IPv6 transport protocols. New applications for 1168 6LoBAC may be found in other domains where low cost, long distance, 1169 and low latency are required. 1171 Example: Use of 6LoBAC in Building Automation Networks 1173 The majority of installations for MS/TP are for "terminal" or 1174 "unitary" controllers, i.e. single zone or room controllers that may 1175 connect to HVAC or other controls such as lighting or blinds. The 1176 economics of daisy-chaining a single twisted-pair between multiple 1177 devices is often preferred over home-run Cat-5 style wiring. 1179 A multi-zone controller might be implemented as an IP router between 1180 a traditional Ethernet link and several 6LoBAC links, fanning out to 1181 multiple terminal controllers. 1183 The superior distance capabilities of MS/TP (~1 km) compared to other 1184 6lo media may suggest its use in applications to connect remote 1185 devices to the nearest building infrastructure. for example, remote 1186 pumping or measuring stations with moderate bandwidth requirements 1187 can benefit from the low cost and robust capabilities of MS/TP over 1188 other wired technologies such as DSL, and without the line-of-site 1189 restrictions or hop-by-hop latency of many low cost wireless 1190 solutions. 1192 A.4. Use case of NFC: Alternative Secure Transfer 1194 According to applications, various secured data can be handled and 1195 transferred. Depending on security level of the data, methods for 1196 transfer can be alternatively selected. 1198 Example: Use of NFC for Secure Transfer in Healthcare Services with 1199 Tele-Assistance 1201 A senior citizen who lives alone wears one to several wearable 6lo 1202 devices to measure heartbeat, pulse rate, etc. The 6lo devices are 1203 densely installed at home for movement detection. An LoWPAN Border 1204 Router (LBR) at home will send the sensed information to a connected 1205 healthcare center. Portable base stations with LCDs may be used to 1206 check the data at home, as well. Data is gathered in both periodic 1207 and event-driven fashion. In this application, event-driven data can 1208 be very time-critical. In addition, privacy also becomes a serious 1209 issue in this case, as the sensed data is very personal. 1211 While the senior citizen is provided audio and video healthcare 1212 services by a tele-assistance based on LTE connections, the senior 1213 citizen can alternatively use NFC connections to transfer the 1214 personal sensed data to the tele-assistance. At this moment, hidden 1215 hackers can overhear the data based on the LTE connection, but they 1216 cannot gather the personal data over the NFC connection. 1218 A.5. Use case of PLC: Smart Grid 1220 Smart grid concept is based on numerous operational and energy 1221 measuring sub-systems of an electric grid. It comprises of multiple 1222 administrative levels/segments to provide connectivity among these 1223 numerous components. Last mile connectivity is established over LV 1224 segment, whereas connectivity over electricity distribution takes 1225 place in HV segment. 1227 Although other wired and wireless technologies are also used in Smart 1228 Grid (Advance Metering Infrastructure - AMI, Demand Response - DR, 1229 Home Energy Management System - HEMS, Wide Area Situational Awareness 1230 - WASA etc), PLC enjoys the advantage of existing (power conductor) 1231 medium and better reliable data communication. PLC is a promising 1232 wired communication technology in that the electrical power lines are 1233 already there and the deployment cost can be comparable to wireless 1234 technologies. The 6lo related scenarios lie in the low voltage PLC 1235 networks with most applications in the area of Advanced Metering 1236 Infrastructure, Vehicle-to-Grid communications, in-home energy 1237 management and smart street lighting. 1239 Example: Use of PLC for Advanced Metering Infrastructure 1241 Household electricity meters transmit time-based data of electric 1242 power consumption through PLC. Data concentrators receive all the 1243 meter data in their corresponding living districts and send them to 1244 the Meter Data Management System (MDMS) through WAN network (e.g. 1245 Medium-Voltage PLC, Ethernet or GPRS) for storage and analysis. Two- 1246 way communications are enabled which means smart meters can do 1247 actions like notification of electricity charges according to the 1248 commands from the utility company. 1250 With the existing power line infrastructure as communication medium, 1251 cost on building up the PLC network is naturally saved, and more 1252 importantly, labor operational costs can be minimized from a long- 1253 term perspective. Furthermore, this AMI application speeds up 1254 electricity charge, reduces losses by restraining power theft and 1255 helps to manage the health of the grid based on line loss analysis. 1257 Example: Use of PLC (IEEE1901.1) for WASA in Smart Grid 1259 Many sub-systems of Smart Grid require low data rate and narrowband 1260 variant (IEEE1901.2) of PLC fulfils such requirements. Recently, 1261 more complex scenarios are emerging that require higher data rates. 1263 WASA sub-system is an appropriate example that collects large amount 1264 of information about the current state of the grid over wide area 1265 from electric substations as well as power transmission lines. The 1266 collected feedback is used for monitoring, controlling and protecting 1267 all the sub-systems. 1269 A.6. Use case of IEEE 802.15.4e: Industrial Automation 1271 Typical scenario of Industrial Automation where sensor and actuators 1272 are connected through the time-slotted radio access (IEEE 802.15.4e). 1273 For that, there will be a point-to-point control signal exchange in 1274 between sensors and actuators to trigger the critical control 1275 information. In such scenarios, point-to-point traffic flows are 1276 significant to exchange the controlled information in between sensors 1277 and actuators within the constrained networks. 1279 Example: Use of IEEE 802.15.4e for P2P communication in closed-loop 1280 application 1282 AODV-RPL [I-D.ietf-roll-aodv-rpl] is proposed as a standard P2P 1283 routing protocol to provide the hop-by-hop data transmission in 1284 closed-loop constrained networks. Scheduling Functions i.e. SF0 1285 [I-D.ietf-6tisch-6top-sfx] and SF1 [I-D.satish-6tisch-6top-sf1] is 1286 proposed to provide distributed neighbor-to-neighbor and end-to-end 1287 resource reservations, respectively for traffic flows in 1288 deterministic networks (6TiSCH). 1290 The potential scenarios that can make use of the end-to-end resource 1291 reservations can be in health-care and industrial applications. 1292 AODV-RPL and SF0/SF1 are the significant routing and resource 1293 reservation protocols for closed-loop applications in constrained 1294 networks. 1296 Authors' Addresses 1297 Yong-Geun Hong 1298 ETRI 1299 161 Gajeong-Dong Yuseung-Gu 1300 Daejeon 305-700 1301 Korea 1303 Phone: +82 42 860 6557 1304 Email: yghong@etri.re.kr 1306 Carles Gomez 1307 Universitat Politecnica de Catalunya/Fundacio i2cat 1308 C/Esteve Terradas, 7 1309 Castelldefels 08860 1310 Spain 1312 Email: carlesgo@entel.upc.edu 1314 Younghwan Choi 1315 ETRI 1316 218 Gajeongno, Yuseong 1317 Daejeon 305-700 1318 Korea 1320 Phone: +82 42 860 1429 1321 Email: yhc@etri.re.kr 1323 Deoknyong Ko 1324 SKtelecom 1325 9-1 Byundang-gu Sunae-dong, Seongnam-si 1326 Gyeonggi-do 13595 1327 Korea 1329 Phone: +82 10 3356 8052 1330 Email: engineer@sk.com 1332 Abdur Rashid Sangi 1333 Huaiyin Institute of Technology 1334 No.89 North Beijing Road, Qinghe District 1335 Huaian 223001 1336 P.R. China 1338 Email: sangi_bahrian@yahoo.com 1339 Take Aanstoot 1340 Modio AB 1341 S:t Larsgatan 15, 582 24 1342 Linkoping 1343 Sweden 1345 Email: take@modio.se 1347 Samita Chakrabarti 1348 San Jose, CA 1349 USA 1351 Email: samitac.ietf@gmail.com