idnits 2.17.00 (12 Aug 2021) /tmp/idnits46957/draft-ietf-6lo-use-cases-03.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 36 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 (October 30, 2017) is 1664 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '6lo' is mentioned on line 133, but not defined == Missing Reference: '6lo-ap-nd' is mentioned on line 704, but not defined == Unused Reference: 'I-D.hou-6lo-plc' is defined on line 924, but no explicit reference was found in the text == Unused Reference: 'IEEE1901.1' is defined on line 952, 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 (-17) exists of draft-ietf-6lo-nfc-07 == Outdated reference: draft-ietf-lwig-energy-efficient has been published as RFC 8352 == Outdated reference: A later version (-13) exists of draft-ietf-roll-aodv-rpl-02 == Outdated reference: A later version (-04) exists of draft-satish-6tisch-6top-sf1-03 == Outdated reference: A later version (-05) exists of draft-hou-6lo-plc-01 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: May 3, 2018 UPC/i2cat 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 October 30, 2017 17 IPv6 over Constrained Node Networks (6lo) Applicability & Use cases 18 draft-ietf-6lo-use-cases-03 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 link layer networks connecting 29 devices to each other or to each cloud. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 3, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 67 3. 6lo Link layer technologies and possible candidates . . . . . 4 68 3.1. ITU-T G.9959 (specified) . . . . . . . . . . . . . . . . 4 69 3.2. Bluetooth LE (specified) . . . . . . . . . . . . . . . . 4 70 3.3. DECT-ULE (specified) . . . . . . . . . . . . . . . . . . 5 71 3.4. MS/TP (specified) . . . . . . . . . . . . . . . . . . . . 5 72 3.5. NFC (specified) . . . . . . . . . . . . . . . . . . . . . 6 73 3.6. PLC (specified) . . . . . . . . . . . . . . . . . . . . . 6 74 3.7. IEEE 802.15.4e (specified) . . . . . . . . . . . . . . . 7 75 3.8. LTE MTC (example of a potential candidate) . . . . . . . 8 76 3.9. Comparison between 6lo Link layer technologies . . . . . 8 77 4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 9 78 4.1. jupitermesh in Smart Grid using 6lo in network layer . . 9 79 4.2. Wi-SUN usage of 6lo stacks . . . . . . . . . . . . . . . 11 80 5. Design Space and Guidelines for 6lo Deployment . . . . . . . 12 81 5.1. Design Space Dimensions for 6lo Deployment . . . . . . . 12 82 5.2. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) . . . . 14 83 6. 6lo Use Case Examples . . . . . . . . . . . . . . . . . . . . 16 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 89 10.2. Informative References . . . . . . . . . . . . . . . . . 19 90 Appendix A. Other 6lo Use Case Examples . . . . . . . . . . . . 21 91 A.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 21 92 A.2. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 22 93 A.3. Use case of MS/TP: Management of District Heating . . . . 22 94 A.4. Use case of NFC: Alternative Secure Transfer . . . . . . 23 95 A.5. Use case of PLC: Smart Grid . . . . . . . . . . . . . . . 24 96 A.6. Use case of IEEE 802.15.4e: Industrial Automation . . . . 25 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 99 1. Introduction 101 Running IPv6 on constrained node networks has different features from 102 general node networks due to the characteristics of constrained node 103 networks such as small packet size, short link-layer address, low 104 bandwidth, network topology, low power, low cost, and large number of 105 devices [RFC4919][RFC7228]. For example, some IEEE 802.15.4 link 106 layers have a frame size of 127 octets and IPv6 requires the layer 107 below to support an MTU of 1280 bytes, therefore an appropriate 108 fragmentation and reassembly adaptation layer must be provided at the 109 layer below IPv6. Also, the limited size of IEEE 802.15.4 frame and 110 low energy consumption requirements make the need for header 111 compression. The IETF 6LoPWAN (IPv6 over Low powerWPAN) working 112 group published an adaptation layer for sending IPv6 packets over 113 IEEE 802.15.4 [RFC4944], a compression format for IPv6 datagrams over 114 IEEE 802.15.4-based networks [RFC6282], and Neighbor Discovery 115 Optimization for 6LoPWAN [RFC6775]. 117 As IoT (Internet of Things) services become more popular, IPv6 over 118 various link layer technologies such as Bluetooth Low Energy 119 (Bluetooth LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless 120 Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token 121 Passing (MS/TP), Near Field Communication (NFC), Power Line 122 Communication (PLC), and IEEE 802.15.4e (TSCH), have been defined at 123 [IETF_6lo] working group. IPv6 stacks for constrained node networks 124 use a variation of the 6LoWPAN stack applied to each particular link 125 layer technology. 127 In the 6LoPWAN working group, the [RFC6568], "Design and Application 128 Spaces for 6LoWPANs" was published and it describes potential 129 application scenarios and use cases for low-power wireless personal 130 area networks. Hence, this 6lo applicability document aims to 131 provide guidance to an audience who is new to IPv6-over-lowpower 132 networks concept and wants to assess if variance of 6LoWPAN stack 133 [6lo] can be applied to the constrained L2 network of their interest. 134 This 6lo applicability document puts together various design space 135 dimensions such as deployment, network size, power source, 136 connectivity, multi-hop communication, traffic pattern, security 137 level, mobility, and QoS requirements etc. And it described a few 138 set of 6LoPWAN application scenarios and practical deployment as 139 examples. 141 This document provides the applicability and use cases of 6lo, 142 considering the following aspects: 144 o 6lo applicability and use cases MAY be uniquely different from 145 those of 6LoWPAN defined for IEEE 802.15.4. 147 o It SHOULD cover various IoT related wire/wireless link layer 148 technologies providing practical information of such technologies. 150 o A general guideline on how the 6LoWPAN stack can be modified for a 151 given L2 technology. 153 o Example use cases and practical deployment examples. 155 2. Conventions and Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 3. 6lo Link layer technologies and possible candidates 163 3.1. ITU-T G.9959 (specified) 165 The ITU-T G.9959 recommendation [G.9959] targets low-power Personal 166 Area Networks (PANs). G.9959 defines how a unique 32-bit HomeID 167 network identifier is assigned by a network controller and how an 168 8-bit NodeID host identifier is allocated to each node. NodeIDs are 169 unique within the network identified by the HomeID. The G.9959 170 HomeID represents an IPv6 subnet that is identified by one or more 171 IPv6 prefixes [RFC7428]. The ITU-T G.9959 can be used for smart home 172 applications. 174 3.2. Bluetooth LE (specified) 176 Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 177 4.1, and developed even further in successive versions. Bluetooth 178 SIG has also published Internet Protocol Support Profile (IPSP). The 179 IPSP enables discovery of IP-enabled devices and establishment of 180 link-layer connection for transporting IPv6 packets. IPv6 over 181 Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or 182 newer. 184 Devices such as mobile phones, notebooks, tablets and other handheld 185 computing devices which will include Bluetooth 4.1 chipsets will 186 probably also have the low-energy variant of Bluetooth. Bluetooth LE 187 will also be included in many different types of accessories that 188 collaborate with mobile devices such as phones, tablets and notebook 189 computers. An example of a use case for a Bluetooth LE accessory is 190 a heart rate monitor that sends data via the mobile phone to a server 191 on the Internet [RFC7668]. A typical usage of Bluetooth LE is 192 smartphone-based interaction with constrained devices. 194 3.3. DECT-ULE (specified) 196 DECT ULE is a low power air interface technology that is designed to 197 support both circuit switched services, such as voice communication, 198 and packet mode data services at modest data rate. 200 The DECT ULE protocol stack consists of the PHY layer operating at 201 frequencies in the 1880 - 1920 MHz frequency band depending on the 202 region and uses a symbol rate of 1.152 Mbps. Radio bearers are 203 allocated by use of FDMA/TDMA/TDD techniques. 205 In its generic network topology, DECT is defined as a cellular 206 network technology. However, the most common configuration is a star 207 network with a single Fixed Part (FP) defining the network with a 208 number of Portable Parts (PP) attached. The MAC layer supports 209 traditional DECT as this is used for services like discovery, 210 pairing, security features etc. All these features have been reused 211 from DECT. 213 The DECT ULE device can switch to the ULE mode of operation, 214 utilizing the new ULE MAC layer features. The DECT ULE Data Link 215 Control (DLC) provides multiplexing as well as segmentation and re- 216 assembly for larger packets from layers above. The DECT ULE layer 217 also implements per-message authentication and encryption. The DLC 218 layer ensures packet integrity and preserves packet order, but 219 delivery is based on best effort. 221 The current DECT ULE MAC layer standard supports low bandwidth data 222 broadcast. However the usage of this broadcast service has not yet 223 been standardized for higher layers [RFC8105]. DECT-ULE can be used 224 for smart metering in a home. 226 3.4. MS/TP (specified) 228 MS/TP is a contention-free access method for the RS-485 physical 229 layer, which is used extensively in building automation networks. 231 An MS/TP device is typically based on a low-cost microcontroller with 232 limited processing power and memory. Together with low data rates 233 and a small address space, these constraints are similar to those 234 faced in 6LoWPAN networks and suggest some elements of that solution 235 might be leveraged. MS/TP differs significantly from 6LoWPAN in at 236 least three aspects: a) MS/TP devices typically have a continuous 237 source of power, b) all MS/TP devices on a segment can communicate 238 directly so there are no hidden node or mesh routing issues, and c) 239 recent changes to MS/TP provide support for large payloads, 240 eliminating the need for link-layer fragmentation and reassembly. 242 MS/TP is designed to enable multidrop networks over shielded twisted 243 pair wiring, although not according to standards, in lower speeds, 244 normally 9600 bit/s, re-purposed telecom wiring is widely in use, 245 keeping deployment cost down. It can support a data rate of 115,200 246 baud on segments up to 1000 meters in length, or segments up to 1200 247 meters in length at lower baud rates. An MS/TP link requires only a 248 UART, an RS-485 transceiver with a driver that can be disabled, and a 249 5ms resolution timer. These features make MS/TP a cost-effective and 250 very reliable field bus for the most numerous and least expensive 251 devices in a building automation network [RFC8163]. MS/TP can be 252 used for the management of district heating. 254 3.5. NFC (specified) 256 NFC technology enables simple and safe two-way interactions between 257 electronic devices, allowing consumers to perform contactless 258 transactions, access digital content, and connect electronic devices 259 with a single touch. NFC complements many popular consumer level 260 wireless technologies, by utilizing the key elements in existing 261 standards for contactless card technology (ISO/IEC 14443 A&B and 262 JIS-X 6319-4). NFC can be compatible with existing contactless card 263 infrastructure and it enables a consumer to utilize one device across 264 different systems. 266 Extending the capability of contactless card technology, NFC also 267 enables devices to share information at a distance that is less than 268 10 cm with a maximum communication speed of 424 kbps. Users can 269 share business cards, make transactions, access information from a 270 smart poster or provide credentials for access control systems with a 271 simple touch. 273 NFC's bidirectional communication ability is ideal for establishing 274 connections with other technologies by the simplicity of touch. In 275 addition to the easy connection and quick transactions, simple data 276 sharing is also available [I-D.ietf-6lo-nfc]. NFC can be used for 277 secure transfer in healthcare services. 279 3.6. PLC (specified) 281 Unlike other dedicated communication infrastructure, the required 282 medium (power conductor) is widely available indoors and outdoors. 283 Moreover, wired technologies are more susceptible to cause 284 interference but are more reliable than their wireless counterparts. 285 PLC is a data transmission technique that utilizes power conductors 286 as medium. 288 The below table shows some available open standards defining PLC. 290 +-------------+-----------------+------------+-----------+----------+ 291 | PLC Systems | Frequency Range | Type | Data Rate | Distance | 292 +-------------+-----------------+------------+-----------+----------+ 293 | IEEE1901 | <100MHz | Broadband | 200Mbps | 1000m | 294 | | | | | | 295 | IEEE1901.1 | <15MHz | PLC-IoT | 10Mbps | 2000m | 296 | | | | | | 297 | IEEE1901.2 | <500kHz | Narrowband | 200Kbps | 3000m | 298 +-------------+-----------------+------------+-----------+----------+ 300 Table 1: Some Available Open Standards in PLC 302 [IEEE1901] defines broadband variant of PLC but is effective within 303 short range. This standard addresses the requirements of 304 applications with high data rate such as: Internet, HDTV, Audio, 305 Gaming etc. Broadband operates on OFDM (Orthogonal Frequency 306 Division Multiplexing) modulation. 308 [IEEE1901.2] defines narrowband variant of PLC with less data rate 309 but significantly higher transmission range that could be used in an 310 indoor or even an outdoor environment. It is applicable to typical 311 IoT applications such as: Building Automation, Renewable Energy, 312 Advanced Metering, Street Lighting, Electric Vehicle, Smart Grid etc. 313 Moreover, IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer 314 and fully endorses the security scheme defined in 802.15.4. 315 [RFC8036]. A typical use case of PLC is smart grid. 317 3.7. IEEE 802.15.4e (specified) 319 The Time Slotted Channel Hopping (TSCH) mode was introduced in the 320 IEEE 802.15.4-2015 standard. In a TSCH network, all nodes are 321 synchronized. Time is sliced up into timeslots. The duration of a 322 timeslot, typically 10ms, is large enough for a node to send a full- 323 sized frame to its neighbor, and for that neighbor to send back an 324 acknowledgment to indicate successful reception. Timeslots are 325 grouped into one of more slotframes, which repeat over time. 327 All the communication in the network is orchestrated by a 328 communication schedule which indicates to each node what to do in 329 each of the timeslots of a slotframe: transmit, listen or sleep. The 330 communication schedule can be built so that the right amount of link- 331 layer resources (the cells in the schedule) are scheduled to satisfy 332 the communication needs of the applications running on the network, 333 while keeping the energy consumption of the nodes very low. Cells 334 can be scheduled in a collision-free way, introducing a high level of 335 determinism to the network. 337 A TSCH network exploits channel hopping: subsequent packet exchanges 338 between neighbor nodes are done on a different frequency. This means 339 that, if a frame isn't received, the transmitter node will re- 340 transmitt the frame on a different frequency. The resulting "channel 341 hopping" efficiently combats external interference and multi-path 342 fading. 344 The main benefits of IEEE 802.15.4 TSCH are: 346 - ultra high reliability. Off-the-shelf commercial products offer 347 over 99.999% end-to-end reliability. 349 - ultra low-power consumption. Off-the-shelf commercial products 350 offer over a decade of battery lifetime. 352 - 6TiSCH at IETF defines communications of TSCH network and it 353 uses 6LoWPAN stack [RFC7554]. 355 IEEE 802.15.4e can be used for industrial automation. 357 3.8. LTE MTC (example of a potential candidate) 359 LTE category defines the overall performance and capabilities of the 360 UE(User Equipment). For example, the maximum down rate of category 1 361 UE and category 2 UE are 10.3 Mbit/s and 51.0 Mbit/s respectively. 362 There are many categories in LTE standard. 3GPP standards defined the 363 category 0 to be used for low rate IoT service in release 12. Since 364 category 1 and category 0 could be used for low rate IoT service, 365 these categories are called LTE MTC (Machine Type Communication) 366 [LTE_MTC]. 368 LTE MTC offer advantages in comparison to above category 2 and is 369 appropriate to be used for low rate IoT services such as low power 370 and low cost. LTE MTC can be used for a gateway of a wireless 371 bachhaul network. 373 3.9. Comparison between 6lo Link layer technologies 375 In above clauses, various 6lo Link layer technologies and a possible 376 candidate are described. The following table shows that dominant 377 paramters of each use case corresponding to the 6lo link layer 378 technology. 380 +-----------+--------+--------+--------+--------+--------+--------+--------+ 381 | | Z-Wave | BLE |DECT-ULE| MS/TP | NFC | PLC | TSCH | 382 +-----------+--------+--------+--------+--------+--------+--------+--------+ 383 | | Home |Interact| | | Health-| |Industr-| 384 | Usage | Auto- |w/ Smart| Meter |District| care | Smart |ial Aut-| 385 | | mation | Phone | Reading| Heating| Service| Grid | mation | 386 +-----------+--------+--------+--------+--------+--------+--------+--------+ 387 | Topology | L2-mesh| Star | Star | Bus | P2P | Star | | 388 | & | or | | | | | Tree | Mesh | 389 | Subnet | L3-mesh| No mesh| No mesh| MS/TP | L2-mesh| Mesh | | 390 +-----------+--------+--------+--------+--------+--------+--------+--------+ 391 | | | | | | | | | 392 | Mobility | No | Low | No | No |Moderate| No | No | 393 | Reqmt | | | | | | | | 394 +-----------+--------+--------+--------+--------+--------+--------+--------+ 395 | | High + | | High + | High + | | High + | High + | 396 | Security | Privacy| Parti- | Privacy| Authen.| High |Encrypt.| Privacy| 397 | Reqmt |required| ally |required|required| |required|required| 398 +-----------+--------+--------+--------+--------+--------+--------+--------+ 399 | | | | | | | | | 400 | Buffering | Low | Low | Low | Low | Low | Low | Low | 401 | Reqmpt | | | | | | | | 402 +-----------+--------+--------+--------+--------+--------+--------+--------+ 403 | Latency, | | | | | | | | 404 | QoS | High | Low | Low | High | High | Low | High | 405 | Reqmt | | | | | | | | 406 +-----------+--------+--------+--------+--------+--------+--------+--------+ 407 | | | | | | | | | 408 | Data |Infrequ-|Infrequ-|Infrequ-|Frequent| Small |Infrequ-|Infrequ-| 409 | Rate | ent | ent | ent | | | ent | ent | 410 +-----------+--------+--------+--------+--------+--------+--------+--------+ 411 | RFC # | | | | | draft- | draft- | | 412 | or | RFC7428| RFC7668| RFC8105| RFC8163|ietf-6lo|hou-6lo-| RFC7554| 413 | Draft | | | | | -nfc | plc | | 414 +-----------+--------+--------+--------+--------+--------+--------+--------+ 416 Table 2: Comparison between 6lo Link layer technologies 418 4. 6lo Deployment Scenarios 420 4.1. jupitermesh in Smart Grid using 6lo in network layer 422 jupiterMesh is a multi-hop wireless mesh network specification 423 designed mainly for deployment in large geographical areas. Each 424 subnet in jupiterMesh is able to cover an entire neighborhood with 425 thousands of nodes consisting of IPv6-enabled routers and end-points 426 (e.g., hosts). Automated network joining and load balancing allows a 427 seamless deployment of a large number of subnets. 429 The main application domains targeted by jupiterMesh are smart grid 430 and smart cities. This includes, but is not limited to the following 431 applications: 433 o Automated meter reading 435 o Distribution Automation (DA) 437 o Demand-side management (DSM) 439 o Demand-side response (DSR) 441 o Power outage reporting 443 o Street light monitoring and control 445 o Transformer load management 447 o EV charging coordination 449 o Energy theft 451 o Parking space locator 453 jupiterMesh specification is based on the following technologies: 455 o The PHY layer is based on IEEE 802.15.4 SUN specification [IEEE 456 802.15.4-2015], supporting multiple operating modes for deployment 457 in different regulatory domains and deployment scenarios in terms 458 of density and bandwidth requirements. jupiterMesh supports bit 459 rates from 50 kbps to 800 kbps, frame size up to 2048 bytes, up to 460 11 different RF bands and 3 modulation types (i.e., FSK, OQPSK and 461 OFDM). 463 o The MAC layer is based on IEEE 802.15.4 TSCH specification [IEEE 464 802.15.4-2015]. With frequency hopping capability, TSCH MAC 465 supports scheduling of dedicated timeslot enabling bandwidth 466 management and QoS. 468 o The security layer consists of a certificate-based (i.e. X.509) 469 network access authentication using EAP-TLS, with IEEE 470 802.15.9-based KMP (Key Management Protocol) transport, and PANA 471 and link layer encryption using AES-128 CCM as specified in IEEE 472 802.15.4-2015 [IEEE 802.15.4-2015]. 474 o Address assignment and network configuration are specified using 475 DHCPv6 [RFC3315]. Neighbor Discovery (ND) [RFC6775] and stateless 476 address auto-configuration (SLAAC) are not supported. 478 o The network layer consists of IPv6, ICMPv6 and 6lo/6LoPWAN header 479 compression [RFC6282]. Multicast is supported using MPL. Two 480 domains are supported, a delay sensitive MPL domain for low 481 latency applications (e.g. DSM, DSR) and a delay insensitive one 482 for less stringent applications (e.g. OTA file transfers). 484 o The routing layer uses RPL [RFC6550] in non-storing mode with the 485 MRHOF objective function based on the ETX metric. 487 4.2. Wi-SUN usage of 6lo stacks 489 Wireless Smart Ubiquitous Network (Wi-SUN) is a technology based on 490 the IEEE 802.15.4g standard. Wi-SUN networks support star and mesh 491 topologies, as well as hybrid star/mesh deployments, but are 492 typically laid out in a mesh topology where each node relays data for 493 the network to provide network connectivity. Wi-SUN networks are 494 deployed on both powered and battery-operated devices. 496 The main application domains targeted by Wi-SUN are smart utility and 497 smart city networks. This includes, but is not limited to the 498 following applications: 500 o Advanced Metering Infrastructure (AMI) 502 o Distribution Automation 504 o Home Energy Management 506 o Infrastructure Management 508 o Intelligent Transportation Systems 510 o Smart Street Lighting 512 o Agriculture 514 o Structural health (bridges, buildings etc) 516 o Monitoring and Asset Management 518 o Smart Thermostats, Air Conditioning and Heat Controls 520 o Energy Usage Information Displays 521 The Wi-SUN Alliance Field Area Network (FAN) covers primarily outdoor 522 networks, and its specification is oriented towards meeting the more 523 rigorous challenges of these environments. Examples include from 524 meter to outdoor access point/router for AMI and DR, or between 525 switches for DA. However, nothing in the profile restricts it to 526 outdoor use. It has the following features; 528 o Open standards based on IEEE802, IETF, TIA, ETSI 530 o Architecture is an IPv6 frequency hopping wireless mesh network 531 with enterprise level security 533 o Simple infrastructure which is low cost, low complexity 535 o Enhanced network robustness, reliability, and resilience to 536 interference, due to high redundancy and frequency hopping 538 o Enhaced scalability, long range, and energy friendliness 540 o Supports multiple global license-exempt sub GHz bands 542 o Multi-vendor interoperability 544 o Very low power modes in development permitting long term battery 545 operation of network nodes 547 In the Wi-SUN FAN specification, adaptation layer based on 6lo and 548 IPv6 network layer are described. So, IPv6 protocol suite including 549 TCP/UDP, 6lo Adaptation, Header Compression, DHCPv6 for IP address 550 management, Routing using RPL, ICMPv6, and Unicast/Multicast 551 forwarding is utilized. 553 5. Design Space and Guidelines for 6lo Deployment 555 5.1. Design Space Dimensions for 6lo Deployment 557 The [RFC6568] lists the dimensions used to describe the design space 558 of wireless sensor networks in the context of the 6LoWPAN working 559 group. The design space is already limited by the unique 560 characteristics of a LoWPAN (e.g., low power, short range, low bit 561 rate). In [RFC6568], design space dimensions are described; 562 Deployment, Network size, Power source, Connectivity, Multi-hop 563 communication, Traffic pattern, Mobility, Quality of Service (QoS). 564 However, in this document, the following design space dimensions are 565 considered: 567 o Deployment/Bootstrapping: 6lo nodes can be connected randomly, or 568 in an organized manner. The bootstrapping has different 569 characteristics for each link layer technology. 571 o Topology: Topology of 6lo networks may inherently follow the 572 characteristics of each link layer technology. Point-to-point, 573 star, tree or mesh topologies can be configured, depending on the 574 link layer technology considered. 576 o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the 577 characteristics of each link layer technology. Some link layer 578 technologies may support L2-mesh and some may not support. 580 o Multi-link subnet, single subnet: The selection of multi-link 581 subnet and single subnet depends on connectivity and the number of 582 6lo nodes. 584 o Data rate: Originally, the link layer technologies of 6lo have low 585 rate of data transmission. But, by adjusting the MTU, it can 586 deliver higher data rate. 588 o Buffering requirements: Some 6lo use case may require more data 589 rate than the link layer technology support. In this case, a 590 buffering mechanism to manage the data is required. 592 o Security and Privacy Requirements: Some 6lo use case can involve 593 transferring some important and personal data between 6lo nodes. 594 In this case, high-level security support is required. 596 o Mobility across 6lo networks and subnets: The movement of 6lo 597 nodes is dependent on the 6lo use case. If the 6lo nodes can move 598 or moved around, it requires a mobility management mechanism. 600 o Time synchronization requirements: The requirement of time 601 synchronization of the upper layer service is dependent on the 6lo 602 use case. For some 6lo use case related to health service, the 603 measured data must be recorded with exact time and must be 604 transferred with time synchronization. 606 o Reliability and QoS: Some 6lo use case requires high reliability, 607 for example real-time service or health-related services. 609 o Traffic patterns: 6lo use cases may involve various traffic 610 patterns. For example, some 6lo use case may require short data 611 length and random transmission. Some 6lo use case may require 612 continuous data and periodic data transmission. 614 o Security Bootstrapping: Without the external operations, 6lo nodes 615 must have the security bootstrapping mechanism. 617 o Power use strategy: to enable certain use cases, there may be 618 requirements on the class of energy availability and the strategy 619 followed for using power for communication [RFC7228]. Each link 620 layer technology defines a particular power use strategy which may 621 be tuned [I-D.ietf-lwig-energy-efficient]. Readers are expected 622 to be familiar with [RFC7228] terminology. 624 o Update firmware requirements: Most 6lo use cases will need a 625 mechanism for updating firmware. In these cases support for over 626 the air updates are required, probably in a broadcast mode when 627 bandwith is low and the number of identical devices is high. 629 o Wired vs. Wireless: Plenty of 6lo link layer technologies are 630 wireless except MS/TP and PLC. The selection of wired or wireless 631 link layer technology is mainly dependent on the requirement of 632 6lo use cases and the characteristics of wired/wireless 633 technologies. For example, some 6lo use cases may require easy 634 and quick deployment and some 6lo use cases may require continuous 635 source of power. 637 5.2. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) 639 The following guideline targets candidates for new constrained L2 640 technologies that consider running modified 6LoWPAN stack. The 641 modification of 6LoWPAN stack should be based on the following: 643 o Addressing Model: Addressing model determines whether the device 644 is capable of forming IPv6 Link-local and global addresses and 645 what is the best way to derive the IPv6 addresses for the 646 constrained L2 devices. Whether the device is capable of forming 647 IPv6 Link-local and global addresses, L2-address-derived IPv6 648 addresses are specified in [RFC4944], but there exist implications 649 for privacy. For global usage, a unique IPv6 address must be 650 derived using an assigned prefix and a unique interface ID. 651 [RFC8065] provides such guidelines. For MAC derived IPv6 address, 652 please refer to [RFC8163] for IPv6 address mapping examples. 653 Broadcast and multicast support are dependent on the L2 networks. 654 Most lowpower L2 implementations map multicast to broadcast 655 networks. So care must be taken in the design when to use 656 broadcast and try to stick to unicast messaging whenever possible. 658 o MTU Considerations: The deployment SHOULD consider their need for 659 maximum transmission unit of a packet (MTU) over the link layer 660 and should consider if fragmentation and reassembly of packets are 661 needed at the 6LoWPAN layer. For example, if the link-layer 662 supports fragmentation and reassembly of packets, then 6LoWPAN 663 layer may skip supporting fragmentation/reassembly. In fact, for 664 most efficiency, choosing a low-power link-layer that can carry 665 unfragmented application packets would be optimum for packet 666 transmission if the deployment can afford it. Please refer to 6lo 667 RFCs [RFC7668], [RFC8163], [RFC8105] for example guidance. 669 o Mesh or L3-Routing: 6LoWPAN specifications do provide mechanisms 670 to support for mesh routing at L2. [RFC6550] defines L3 routing 671 for low power lossy networks using directed graphs. 6LoWPAN is 672 routing protocol agnostic and other L2 or L3 routing protocols can 673 be run using a 6LoWPAN stack. 675 o Address Assignment: 6LoWPAN requires that IPv6 Neighbor Discovery 676 for low power networks [RFC6775] be used for autoconfiguration of 677 stateless IPv6 address assignment. Considering the energy 678 sensitive networks [RFC6775] makes optimization from classical 679 IPv6 ND [RFC4861] protocol. It is the responsibility of the 680 deployment to ensure unique global IPv6 addresses for the Internet 681 connectivity. For local-only connectivity IPv6 ULA may be used. 682 [RFC6775] specifies the 6LoWPAN border router(6LBR) which is 683 responsible for prefix assignment to the 6lo/6LoWPAN network. 6LBR 684 can be connected to the Internet or Enterprise network via its one 685 of the interfaces. Please refer to [RFC7668] and [RFC8105] for 686 examples of address assignment considerations. In addition, 687 privacy considerations [RFC8065] must be consulted for 688 applicability. In certain scenarios, the deployment may not 689 support autoconfiguration of IPv6 addressing due to regulatory and 690 business reasons and may choose to offer a separate address 691 assignment service. 693 o Header Compression: IPv6 header compression [RFC6282] is a vital 694 part of IPv6 over low power communication. Examples of header 695 compression for different link-layers specifications are found in 696 [RFC7668], [RFC8163], [RFC8105]. A generic header compression 697 technique is specified in [RFC7400]. 699 o Security and Encryption: Though 6LoWPAN basic specifications do 700 not address security at network layer, the assumption is that L2 701 security must be present. In addition, application level security 702 is highly desirable. The working groups [ace] and [core] should 703 be consulted for application and transport level security. 6lo 704 working group is working on address authentication [6lo-ap-nd] and 705 secure bootstrapping is also being discussed at IETF. However, 706 there may be different levels of security available in a 707 deployment through other standards such as hardware level security 708 or certificates for initial booting process. Encryption is quite 709 important if the implementation can afford it. 711 o Additional processing: [RFC8066] defines guidelines for ESC 712 dispatch octets use in the 6LoWPAN header. An implementation may 713 take advantage of ESC header to offer a deployment specific 714 processing of 6LoWPAN packets. 716 6. 6lo Use Case Examples 718 As IPv6 stacks for constrained node networks use a variation of the 719 6LoWPAN stack applied to each particular link layer technology, 720 various 6lo use cases can be provided. In this clause, one 6lo use 721 case example of Bluetooth LE (Smartphone-Based Interaction with 722 Constrained Devices) is described. Other 6lo use case examples are 723 described in Appendix. 725 The key feature behind the current high Bluetooth LE momentum is its 726 support in a large majority of smartphones in the market. Bluetooth 727 LE can be used to allow the interaction between the smartphone and 728 surrounding sensors or actuators. Furthermore, Bluetooth LE is also 729 the main radio interface currently available in wearables. Since a 730 smartphone typically has several radio interfaces that provide 731 Internet access, such as Wi-Fi or 4G, the smartphone can act as a 732 gateway for nearby devices such as sensors, actuators or wearables. 733 Bluetooth LE may be used in several domains, including healthcare, 734 sports/wellness and home automation. 736 Example: Use of Bluetooth LE-based Body Area Network for fitness 738 A person wears a smartwatch for fitness purposes. The smartwatch has 739 several sensors (e.g. heart rate, accelerometer, gyrometer, GPS, 740 temperature, etc.), a display, and a Bluetooth LE radio interface. 741 The smartwatch can show fitness-related statistics on its display. 742 However, when a paired smartphone is in the range of the smartwatch, 743 the latter can report almost real-time measurements of its sensors to 744 the smartphone, which can forward the data to a cloud service on the 745 Internet. In addition, the smartwatch can receive notifications 746 (e.g. alarm signals) from the cloud service via the smartphone. On 747 the other hand, the smartphone may locally generate messages for the 748 smartwatch, such as e-mail reception or calendar notifications. 750 The functionality supported by the smartwatch may be complemented by 751 other devices such as other on-body sensors, wireless headsets or 752 head-mounted displays. All such devices may connect to the 753 smartphone creating a star topology network whereby the smartphone is 754 the central component. 756 7. IANA Considerations 758 There are no IANA considerations related to this document. 760 8. Security Considerations 762 Security considerations are not directly applicable to this document. 763 The use cases will use the security requirements described in the 764 protocol specifications. 766 9. Acknowledgements 768 Carles Gomez has been funded in part by the Spanish Government 769 (Ministerio de Educacion, Cultura y Deporte) through the Jose 770 Castillejo grant CAS15/00336. His contribution to this work has been 771 carried out in part during his stay as a visiting scholar at the 772 Computer Laboratory of the University of Cambridge. 774 Thomas Watteyne, Pascal Thubert, Xavier Vilajosana, Daniel Migault, 775 and Jianqiang HOU have provided valuable feedback for this draft. 777 Das Subir and Michel Veillette have provided valuable information of 778 jupiterMesh and Paul Duffy has provided valuable information of Wi- 779 SUN for this draft. 781 10. References 783 10.1. Normative References 785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 786 Requirement Levels", BCP 14, RFC 2119, 787 DOI 10.17487/RFC2119, March 1997, 788 . 790 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 791 over Low-Power Wireless Personal Area Networks (6LoWPANs): 792 Overview, Assumptions, Problem Statement, and Goals", 793 RFC 4919, DOI 10.17487/RFC4919, August 2007, 794 . 796 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 797 "Transmission of IPv6 Packets over IEEE 802.15.4 798 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 799 . 801 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 802 Routing Requirements in Low-Power and Lossy Networks", 803 RFC 5826, DOI 10.17487/RFC5826, April 2010, 804 . 806 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 807 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 808 DOI 10.17487/RFC6282, September 2011, 809 . 811 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 812 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 813 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 814 Low-Power and Lossy Networks", RFC 6550, 815 DOI 10.17487/RFC6550, March 2012, 816 . 818 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 819 Application Spaces for IPv6 over Low-Power Wireless 820 Personal Area Networks (6LoWPANs)", RFC 6568, 821 DOI 10.17487/RFC6568, April 2012, 822 . 824 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 825 Bormann, "Neighbor Discovery Optimization for IPv6 over 826 Low-Power Wireless Personal Area Networks (6LoWPANs)", 827 RFC 6775, DOI 10.17487/RFC6775, November 2012, 828 . 830 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 831 Constrained-Node Networks", RFC 7228, 832 DOI 10.17487/RFC7228, May 2014, 833 . 835 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 836 IPv6 over Low-Power Wireless Personal Area Networks 837 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 838 2014, . 840 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 841 over ITU-T G.9959 Networks", RFC 7428, 842 DOI 10.17487/RFC7428, February 2015, 843 . 845 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 846 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 847 Internet of Things (IoT): Problem Statement", RFC 7554, 848 DOI 10.17487/RFC7554, May 2015, 849 . 851 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 852 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 853 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 854 . 856 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 857 Statement for the Routing Protocol for Low-Power and Lossy 858 Networks (RPL) in Advanced Metering Infrastructure (AMI) 859 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 860 . 862 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 863 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 864 February 2017, . 866 [RFC8066] Chakrabarti, S., Montenegro, G., Droms, R., and J. 867 Woodyatt, "IPv6 over Low-Power Wireless Personal Area 868 Network (6LoWPAN) ESC Dispatch Code Points and 869 Guidelines", RFC 8066, DOI 10.17487/RFC8066, February 870 2017, . 872 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 873 M., and D. Barthel, "Transmission of IPv6 Packets over 874 Digital Enhanced Cordless Telecommunications (DECT) Ultra 875 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 876 2017, . 878 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 879 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 880 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 881 May 2017, . 883 10.2. Informative References 885 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 886 C., and M. Carney, "Dynamic Host Configuration Protocol 887 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 888 2003, . 890 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 891 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 892 DOI 10.17487/RFC4861, September 2007, 893 . 895 [I-D.ietf-6lo-nfc] 896 Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, 897 "Transmission of IPv6 Packets over Near Field 898 Communication", draft-ietf-6lo-nfc-07 (work in progress), 899 June 2017. 901 [I-D.ietf-lwig-energy-efficient] 902 Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy- 903 Efficient Features of Internet of Things Protocols", 904 draft-ietf-lwig-energy-efficient-08 (work in progress), 905 October 2017. 907 [I-D.ietf-roll-aodv-rpl] 908 Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S. 909 Anand, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy 910 Networks (LLNs)", draft-ietf-roll-aodv-rpl-02 (work in 911 progress), September 2017. 913 [I-D.ietf-6tisch-6top-sf0] 914 Dujovne, D., Grieco, L., Palattella, M., and N. Accettura, 915 "6TiSCH 6top Scheduling Function Zero (SF0)", draft-ietf- 916 6tisch-6top-sf0-05 (work in progress), July 2017. 918 [I-D.satish-6tisch-6top-sf1] 919 Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S. 920 Anand, "Scheduling Function One (SF1) for hop-by-hop 921 Scheduling in 6tisch Networks", draft-satish-6tisch-6top- 922 sf1-03 (work in progress), February 2017. 924 [I-D.hou-6lo-plc] 925 Hou, J., Hong, Y., and X. Tang, "Transmission of IPv6 926 Packets over PLC Networks", draft-hou-6lo-plc-01 (work in 927 progress), June 2017. 929 [IETF_6lo] 930 "IETF IPv6 over Networks of Resource-constrained Nodes 931 (6lo) working group", 932 . 934 [G.9959] "International Telecommunication Union, "Short range 935 narrow-band digital radiocommunication transceivers - PHY 936 and MAC layer specifications", ITU-T Recommendation", 937 January 2015. 939 [LTE_MTC] "3GPP TS 36.306 V13.0.0, 3rd Generation Partnership 940 Project; Technical Specification Group Radio Access 941 Network; Evolved Universal Terrestrial Radio Access 942 (E-UTRA); User Equipment (UE) radio access capabilities 943 (Release 13)", December 2015. 945 [IEEE1901] 946 "IEEE Standard, IEEE Std. 1901-2010 - IEEE Standard for 947 Broadband over Power Line Networks: Medium Access Control 948 and Physical Layer Specifications", 2010, 949 . 952 [IEEE1901.1] 953 "IEEE Standard (work-in-progress), IEEE-SA Standards 954 Board", . 956 [IEEE1901.2] 957 "IEEE Standard, IEEE Std. 1901.2-2013 - IEEE Standard for 958 Low-Frequency (less than 500 kHz) Narrowband Power Line 959 Communications for Smart Grid Applications", 2013, 960 . 963 Appendix A. Other 6lo Use Case Examples 965 A.1. Use case of ITU-T G.9959: Smart Home 967 Z-Wave is one of the main technologies that may be used to enable 968 smart home applications. Born as a proprietary technology, Z-Wave 969 was specifically designed for this particular use case. Recently, 970 the Z-Wave radio interface (physical and MAC layers) has been 971 standardized as the ITU-T G.9959 specification. 973 Example: Use of ITU-T G.9959 for Home Automation 975 Variety of home devices (e.g. light dimmers/switches, plugs, 976 thermostats, blinds/curtains and remote controls) are augmented with 977 ITU-T G.9959 interfaces. A user may turn on/off or may control home 978 appliances by pressing a wall switch or by pressing a button in a 979 remote control. Scenes may be programmed, so that after a given 980 event, the home devices adopt a specific configuration. Sensors may 981 also periodically send measurements of several parameters (e.g. gas 982 presence, light, temperature, humidity, etc.) which are collected at 983 a sink device, or may generate commands for actuators (e.g. a smoke 984 sensor may send an alarm message to a safety system). 986 The devices involved in the described scenario are nodes of a network 987 that follows the mesh topology, which is suitable for path diversity 988 to face indoor multipath propagation issues. The multihop paradigm 989 allows end-to-end connectivity when direct range communication is not 990 possible. Security support is required, specially for safety-related 991 communication. When a user interaction (e.g. a button press) 992 triggers a message that encapsulates a command, if the message is 993 lost, the user may have to perform further interactions to achieve 994 the desired effect (e.g. a light is turned off). A reaction to a 995 user interaction will be perceived by the user as immediate as long 996 as the reaction takes place within 0.5 seconds [RFC5826]. 998 A.2. Use case of DECT-ULE: Smart Home 1000 DECT is a technology widely used for wireless telephone 1001 communications in residential scenarios. Since DECT-ULE is a low- 1002 power variant of DECT, DECT-ULE can be used to connect constrained 1003 devices such as sensors and actuators to a Fixed Part, a device that 1004 typically acts as a base station for wireless telephones. Therefore, 1005 DECT-ULE is specially suitable for the connected home space in 1006 application areas such as home automation, smart metering, safety, 1007 healthcare, etc. 1009 Example: Use of DECT-ULE for Smart Metering 1011 The smart electricity meter of a home is equipped with a DECT-ULE 1012 transceiver. This device is in the coverage range of the Fixed Part 1013 of the home. The Fixed Part can act as a router connected to the 1014 Internet. This way, the smart meter can transmit electricity 1015 consumption readings through the DECT-ULE link with the Fixed Part, 1016 and the latter can forward such readings to the utility company using 1017 Wide Area Network (WAN) links. The meter can also receive queries 1018 from the utility company or from an advanced energy control system 1019 controlled by the user, which may also be connected to the Fixed Part 1020 via DECT-ULE. 1022 A.3. Use case of MS/TP: Management of District Heating 1024 The key feature of MS/TP is it's ability to run on the same cabling 1025 as BACnet and some use of ModBus, the defacto standard for low 1026 bandwith industry communication. Specially Modbus has been around 1027 since the 1980 and is still the standard for talking to fans, heat 1028 pumps, water purifying equipment and everything else delivering 1029 electricity, clean water and ventilation. 1031 Example: Use of MS/TP for management of district heating 1032 The mechanical room in the cellar of an apartment building gets 1033 district heating and electricity from the utility providers. The 1034 room has a Supervisory Control And Data Acquisition (SCADA) computer 1035 talking to a centralized server and command center somewhere else 1036 over IP, on the other hand it is controlling the heating, fans and 1037 distribution panel over a 2-wire RS-485 based protocol to make sure 1038 the logic controller for district heating keeps a constant 1039 temperature at the tapwater, the logic controller for heat produktion 1040 keeps the right radiator temperature depending on the weather and the 1041 fans have a correct speed and are switched off in case district 1042 heating fails to prevent cooling out the building and give certain 1043 commands in case smoke is detected. Speed is not important, in this 1044 usecase, 19,200 bit/s capable equipment is sold as high speed 1045 communication capable. Reliability is important, this not working 1046 will easily give millions of dollars of damage. Normally the setup 1047 is that the SCADA device asks a question to a specific controlling 1048 device, gets an answer from the controlling device, asks a new 1049 question to some other device. 1051 A.4. Use case of NFC: Alternative Secure Transfer 1053 According to applications, various secured data can be handled and 1054 transferred. Depending on security level of the data, methods for 1055 transfer can be alternatively selected. 1057 Example: Use of NFC for Secure Transfer in Healthcare Services with 1058 Tele-Assistance 1060 A senior citizen who lives alone wears one to several wearable 6lo 1061 devices to measure heartbeat, pulse rate, etc. The 6lo devices are 1062 densely installed at home for movement detection. An LoWPAN Border 1063 Router (LBR) at home will send the sensed information to a connected 1064 healthcare center. Portable base stations with LCDs may be used to 1065 check the data at home, as well. Data is gathered in both periodic 1066 and event-driven fashion. In this application, event-driven data can 1067 be very time-critical. In addition, privacy also becomes a serious 1068 issue in this case, as the sensed data is very personal. 1070 While the senior citizen is provided audio and video healthcare 1071 services by a tele-assistance based on LTE connections, the senior 1072 citizen can alternatively use NFC connections to transfer the 1073 personal sensed data to the tele-assistance. At this moment, hidden 1074 hackers can overhear the data based on the LTE connection, but they 1075 cannot gather the personal data over the NFC connection. 1077 A.5. Use case of PLC: Smart Grid 1079 Smart grid concept is based on numerous operational and energy 1080 measuring sub-systems of an electric grid. It comprises of multiple 1081 administrative levels/segments to provide connectivity among these 1082 numerous components. Last mile connectivity is established over LV 1083 segment, whereas connectivity over electricity distribution takes 1084 place in HV segment. 1086 Although other wired and wireless technologies are also used in Smart 1087 Grid (Advance Metering Infrastructure - AMI, Demand Response - DR, 1088 Home Energy Management System - HEMS, Wide Area Situational Awareness 1089 - WASA etc), PLC enjoys the advantage of existing (power conductor) 1090 medium and better reliable data communication. PLC is a promising 1091 wired communication technology in that the electrical power lines are 1092 already there and the deployment cost can be comparable to wireless 1093 technologies. The 6lo related scenarios lie in the low voltage PLC 1094 networks with most applications in the area of Advanced Metering 1095 Infrastructure, Vehicle-to-Grid communications, in-home energy 1096 management and smart street lighting. 1098 Example: Use of PLC for Advanced Metering Infrastructure 1100 Household electricity meters transmit time-based data of electric 1101 power consumption through PLC. Data concentrators receive all the 1102 meter data in their corresponding living districts and send them to 1103 the Meter Data Management System (MDMS) through WAN network (e.g. 1104 Medium-Voltage PLC, Ethernet or GPRS) for storage and analysis. Two- 1105 way communications are enabled which means smart meters can do 1106 actions like notification of electricity charges according to the 1107 commands from the utility company. 1109 With the existing power line infrastructure as communication medium, 1110 cost on building up the PLC network is naturally saved, and more 1111 importantly, labor operational costs can be minimized from a long- 1112 term perspective. Furthermore, this AMI application speeds up 1113 electricity charge, reduces losses by restraining power theft and 1114 helps to manage the health of the grid based on line loss analysis. 1116 Example: Use of PLC (IEEE1901.1) for WASA in Smart Grid 1118 Many sub-systems of Smart Grid require low data rate and narrowband 1119 variant (IEEE1901.2) of PLC fulfils such requirements. Recently, 1120 more complex scenarios are emerging that require higher data rates. 1122 WASA sub-system is an appropriate example that collects large amount 1123 of information about the current state of the grid over wide area 1124 from electric substations as well as power transmission lines. The 1125 collected feedback is used for monitoring, controlling and protecting 1126 all the sub-systems. 1128 A.6. Use case of IEEE 802.15.4e: Industrial Automation 1130 Typical scenario of Industrial Automation where sensor and actuators 1131 are connected through the time-slotted radio access (IEEE 802.15.4e). 1132 For that, there will be a point-to-point control signal exchange in 1133 between sensors and actuators to trigger the critical control 1134 information. In such scenarios, point-to-point traffic flows are 1135 significant to exchange the controlled information in between sensors 1136 and actuators within the constrained networks. 1138 Example: Use of IEEE 802.15.4e for P2P communication in closed-loop 1139 application 1141 AODV-RPL [I-D.ietf-roll-aodv-rpl] is proposed as a standard P2P 1142 routing protocol to provide the hop-by-hop data transmission in 1143 closed-loop constrained networks. Scheduling Functions i.e. SF0 1144 [I-D.ietf-6tisch-6top-sf0] and SF1 [I-D.satish-6tisch-6top-sf1] is 1145 proposed to provide distributed neighbor-to-neighbor and end-to-end 1146 resource reservations, respectively for traffic flows in 1147 deterministic networks (6TiSCH). 1149 The potential scenarios that can make use of the end-to-end resource 1150 reservations can be in health-care and industrial applications. 1151 AODV-RPL and SF0/SF1 are the significant routing and resource 1152 reservation protocols for closed-loop applications in constrained 1153 networks. 1155 Authors' Addresses 1157 Yong-Geun Hong 1158 ETRI 1159 161 Gajeong-Dong Yuseung-Gu 1160 Daejeon 305-700 1161 Korea 1163 Phone: +82 42 860 6557 1164 Email: yghong@etri.re.kr 1165 Carles Gomez 1166 Universitat Politecnica de Catalunya/Fundacio i2cat 1167 C/Esteve Terradas, 7 1168 Castelldefels 08860 1169 Spain 1171 Email: carlesgo@entel.upc.edu 1173 Younghwan Choi 1174 ETRI 1175 218 Gajeongno, Yuseong 1176 Daejeon 305-700 1177 Korea 1179 Phone: +82 42 860 1429 1180 Email: yhc@etri.re.kr 1182 Deoknyong Ko 1183 SKtelecom 1184 9-1 Byundang-gu Sunae-dong, Seongnam-si 1185 Gyeonggi-do 13595 1186 Korea 1188 Phone: +82 10 3356 8052 1189 Email: engineer@sk.com 1191 Abdur Rashid Sangi 1192 Huaiyin Institute of Technology 1193 No.89 North Beijing Road, Qinghe District 1194 Huaian 223001 1195 P.R. China 1197 Email: sangi_bahrian@yahoo.com 1199 Take Aanstoot 1200 Modio AB 1201 S:t Larsgatan 15, 582 24 1202 Linkoping 1203 Sweden 1205 Email: take@modio.se 1206 Samita Chakrabarti 1207 San Jose, CA 1208 USA 1210 Email: samitac.ietf@gmail.com