idnits 2.17.1 draft-ietf-6lowpan-usecases-09.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 is 1 instance of too long lines in the document, the longest one being 1 character 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 18, 2011) is 4846 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-15 == Outdated reference: A later version (-15) exists of draft-ietf-6lowpan-hc-13 == Outdated reference: A later version (-10) exists of draft-ietf-6lowpan-routing-requirements-08 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN Working Group E. Kim 3 Internet-Draft ETRI 4 Intended status: Informational D. Kaspar 5 Expires: July 22, 2011 Simula Research Laboratory 6 N. Chevrollier 7 TNO 8 JP. Vasseur 9 Cisco Systems, Inc 10 January 18, 2011 12 Design and Application Spaces for 6LoWPANs 13 draft-ietf-6lowpan-usecases-09 15 Abstract 17 This document investigates potential application scenarios and use 18 cases for low-power wireless personal area networks (LoWPANs). This 19 document provides dimensions of design space for LoWPAN applications. 20 A list of use cases and market domains that may benefit and motivate 21 the work currently done in the 6LoWPAN WG is provided with the 22 characteristics of each dimension. A complete list of practical use 23 cases is not the goal of this document. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 22, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.2. Premise of network configuration . . . . . . . . . . . . . 5 74 2. Design Space . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 9 76 3.1. Industrial Monitoring . . . . . . . . . . . . . . . . . . 9 77 3.1.1. A Use Case and its Requirements . . . . . . . . . . . 10 78 3.1.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 11 79 3.2. Structural Monitoring . . . . . . . . . . . . . . . . . . 12 80 3.2.1. A Use Case and its Requirements . . . . . . . . . . . 13 81 3.2.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 14 82 3.3. Connected Home . . . . . . . . . . . . . . . . . . . . . . 15 83 3.3.1. A Use Case and its Requirements . . . . . . . . . . . 15 84 3.3.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 17 85 3.4. Healthcare . . . . . . . . . . . . . . . . . . . . . . . . 18 86 3.4.1. A Use Case and its Requirements . . . . . . . . . . . 18 87 3.4.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 20 88 3.5. Vehicle Telematics . . . . . . . . . . . . . . . . . . . . 20 89 3.5.1. A Use Case and its Requirements . . . . . . . . . . . 21 90 3.5.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 22 91 3.6. Agricultural Monitoring . . . . . . . . . . . . . . . . . 22 92 3.6.1. A Use Case and its Requirements . . . . . . . . . . . 22 93 3.6.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 24 94 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 96 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 97 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 98 7.1. Normative References . . . . . . . . . . . . . . . . . . . 29 99 7.2. Informative References . . . . . . . . . . . . . . . . . . 29 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 102 1. Introduction 104 Low-power and lossy networks (LLNs) is the term commonly used to 105 refer to networks made of highly constrained nodes (limited CPU, 106 memory, power) interconnected by a variety of "lossy" links (low- 107 power radio links or powerline communication (PLC)). They are 108 characterized by low speed, low performance, low cost, and unstable 109 connectivity. A LoWPAN is a particular instance of an LLN, formed by 110 devices complying with the IEEE 802.15.4 standard [4]. Their typical 111 characteristics can be summarized as follows: 113 o Limited processing capability: the smallest common LoWPAN nodes 114 have 8-bit processors with clock rates around 10 MHz. Other 115 models exist with 16-bit and 32-bit cores (typically ARM7), 116 running at frequencies in the order of tens of MHz. 118 o Small memory capacity: the smallest common LoWPAN nodes have a few 119 kBytes of RAM with a few dozens of kBytes of ROM/flash memory. 120 While the memory sizes of nodes continue to grow (e.g., IMote has 121 64K SRAM, 512K Flash memory), the nature of small memory capacity 122 for LoWPAN nodes remains a challenge. 124 o Low power: wireless radios for LoWPANs are normally battery- 125 operated. Their RF transceivers often have a current draw of 126 about 10 to 30 mA, depending on the used transmission power level. 127 In order to reach common indoor ranges of up to 30 meters and 128 outdoor ranges of 100 meters, the used transmission power is set 129 around 0 to 3 dBm. Depending on the processor type, there is an 130 additional battery current consumption of the CPU itself, commonly 131 in the order of tens of milliamperes. However, the CPU power 132 consumption can often be reduced by a thousandfold when switching 133 to sleep mode. 135 o Short range: the Personal Operating Space (POS) defined by IEEE 136 802.15.4 implies a range of 10 meters. For real implementations, 137 the range of LoWPAN radios is typically measured in tens of 138 meters, but can reach over 100 meters in line-of-sight situations. 140 o Low bit rate: the IEEE 802.15.4 standard defines a maximum over- 141 the-air rate of 250K bit/s, which is most commonly used in current 142 deployments. Alternatively, three lower data rates of 20K, 40K 143 and 100K bit/s are defined. 145 As any other LLN, a LoWPAN does not necessarily comprise of sensor 146 nodes only, but may also consist of actuators. For instance, in an 147 agricultural environment, sensor nodes might be used to detect low 148 soil humidity and then send commands to activate the sprinkler 149 system. 151 After defining common terminology in Section 1.1 and describing the 152 characteristics of LoWPANs in Section 2, this document provides a 153 list of use cases and market domains that may benefit and motivate 154 the work currently done in the 6LoWPAN WG. 156 1.1. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [1]. 162 Readers are expected to be familiar with all the terms and concepts 163 that are discussed in "IPv6 over Low-Power Wireless Personal Area 164 Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and 165 Goals" [2], and " Transmission of IPv6 Packets over IEEE 802.15.4 166 Networks" [3]. 168 Readers would benefit from reading 6LoWPAN ND [5], 6LoWPAN header 169 compression [6], and 6LoWPAN Routing Requirements [7] for the details 170 of the 6LoWPAN work. 172 This document defines the following terms: 174 LC (Local Controller) 176 A logical functional entity that performs the special role of 177 coordinating and controlling its child nodes for local data 178 aggregation, status management of local nodes, etc. There may be 179 multiple instances of local controller nodes in a LoWPAN. 181 LBR (LoWPAN Border Router) 183 A border router is located at the junction of separate LoWPAN 184 networks or between a LoWPAN network and another IP network. 185 There may be one or more LBRs at the LoWPAN network boundary. A 186 LBR is the responsible authority for IPv6 Prefix propagation for 187 the LoWPAN network it is serving. An isolated LoWPAN also 188 contains a LBR in the network, which provides the prefix(es) for 189 the isolated network. 191 1.2. Premise of network configuration 193 The IEEE 802.15.4 standard distinguishes between two types of nodes, 194 reduced-function devices (RFDs) and full-function devices (FFDs). As 195 this distinction is based on some MAC features that are not always in 196 use, we are not using this distinction in this document. 198 6LoWPAN networks can be deployed using either route-over or mesh- 199 under architectures. As the choice of route-over or mesh-under does 200 not affect the applicability of 6LoWPAN technologies to the use cases 201 described in the document, we will use the term "6LoWPAN network" to 202 mean either a route-over or mesh-under network. 204 2. Design Space 206 Inspired by [8], this section lists the dimensions used to describe 207 the design space of wireless sensor networks in the context of the 208 6LoWPAN Working Group. The design space is already limited by the 209 unique characteristics of a LoWPAN (e.g., low-power, short range, 210 low-bit rate) as described in [2]. The possible dimensions for 211 scenario categorization used in this document are described as 212 follows: 214 o Deployment: LoWPAN nodes can be scattered randomly or they may be 215 deployed in an organized manner in a LoWPAN. The deployment can 216 occur at once, or as an iterative process. The selected type of 217 deployment has an impact on node density and location. This 218 feature affects how to organize (manually or automatically) the 219 LoWPAN and how to allocate addresses in the network. 221 o Network Size: The network size takes into account nodes that 222 provide the intended network capability. The number of nodes 223 involved in a LoWPAN could be small (10 nodes), moderate (several 224 100s), or large (over a 1000). 226 o Power Source: The power source of nodes, whether the nodes are 227 battery-powered or mains-powered, influences the network design. 228 The power may also be harvested from solar cells or other sources 229 of energy. Hybrid solutions are possible where only part of the 230 network is mains-powered. 232 o Connectivity: Nodes within a LoWPAN are considered "always 233 connected" when there is a network connection between any two 234 given nodes. However, due to external factors (e.g., extreme 235 environment, mobility) or programmed disconnections (e.g., 236 sleeping mode), the network connectivity can be from 237 "intermittent" (i.e., regular disconnections) to "sporadic" (i.e., 238 almost always disconnected network). Differences in L2 duty- 239 cycling settings may additionally impact the connectivity due to 240 highly varying bit-rates. 242 o Multi-hop communication: The multi-hop communication factor 243 highlights the number of hops that has to be traversed to reach 244 the edge of the network or a destination node within it. A single 245 hop may be sufficient for simple star-topologies, but a multi-hop 246 communication scheme is required for more elaborate topologies, 247 such as meshes or trees. In previous work by academia and 248 industry on LoWPANs, various routing mechanisms were introduced, 249 such as data-centric, event-driven, address-centric, localization- 250 based, geographical routing, etc. This document does not make use 251 of such a fine granularity but rather uses topologies and single/ 252 multi-hop communication. 254 o Traffic Pattern: several traffic patterns may be used in LoWPANs. 255 To name a few, Point-to-Multi-Point (P2MP), Multi-Point-to-Point 256 (MP2P) and Point-to-Point (P2P). 258 o Security Level: LoWPANs may carry sensitive information and 259 require high-level security support where the availability, 260 integrity, and confidentiality of the information are crucial. 261 This high level of security may be needed in case of structural 262 monitoring of key infrastructure or health monitoring of patients. 264 o Mobility: Inherent to the wireless characteristics of LoWPANs, 265 nodes could move or be moved around. Mobility can be an induced 266 factor (e.g., sensors in an automobile), hence not predictable, or 267 a controlled characteristic (e.g., pre-planned movement in a 268 supply chain). 270 o Quality of Service (QoS): for mission-critical applications, 271 support of QoS is mandatory in resource-constrained LoWPANs. 273 3. Application Scenarios 275 This section lists a fundamental set of LoWPAN application scenarios 276 in terms of system design. A complete list of practical use cases is 277 not the objective of this document. 279 3.1. Industrial Monitoring 281 LoWPAN applications for industrial monitoring can be associated with 282 a broad range of methods to increase productivity, energy efficiency, 283 and safety of industrial operations in engineering facilities and 284 manufacturing plants. Many companies currently use time-consuming 285 and expensive manual monitoring to predict failures and to schedule 286 maintenance or replacements in order to avoid costly manufacturing 287 downtime. LoWPANs can be inexpensively installed to provide more 288 frequent and more reliable data. The deployment of LoWPANs can 289 reduce equipment downtime and eliminate manual equipment monitoring 290 that is costly to be carried out. Additionally, data analysis 291 functionality can be placed into the network, eliminating the need 292 for manual data transfer and analysis. 294 Industrial monitoring can be largely split into the following 295 application fields: 297 o Process Monitoring and Control: combining advanced energy metering 298 and sub-metering technologies with wireless sensor networking in 299 order to optimize factory operations, reduce peak demand, 300 ultimately lower costs for energy, avoid machine downtimes, and 301 increase operation safety. 303 A plant's monitoring boundary often does not cover the entire 304 facility but only those areas considered critical to the process. 305 Easy to install wireless connectivity extends this line to include 306 peripheral areas and process measurements that were previously 307 infeasible or impractical to reach with wired connections. 309 o Machine Surveillance: ensuring product quality and efficient and 310 safe equipment operation. Critical equipment parameters such as 311 vibration, temperature, and electrical signature are analyzed for 312 abnormalities that are suggestive of impending equipment failure 313 (see Section 3.2). 315 o Supply Chain Management and Asset Tracking: with the retail 316 industry being legally responsible for the quality of sold goods, 317 early detection of inadequate storage conditions with respect to 318 temperature will reduce risk and cost to remove products from the 319 sales channel. Examples include container shipping, product 320 identification, cargo monitoring, distribution and logistics. 322 o Storage Monitoring: sensor systems designed to prevent releases of 323 regulated substances to ground water, surface water and soil. 324 This application field may also include theft/tampering prevention 325 systems for storage facilities or other infrastructure, such as 326 pipelines. 328 3.1.1. A Use Case and its Requirements 330 Example: Hospital Storage Rooms 332 In a hospital, maintenance of the right temperature in storage rooms 333 is very critical. Red blood cells need to be stored at 2 to 6 334 degrees Celsius, blood platelets at 20 to 24 C, and blood plasma 335 below -18 C. For anti-cancer medicine, maintaining a humidity of 45% 336 to 55% is required. Storage rooms have temperature sensors and 337 humidity sensors every 25m to 100m, based on the floor plan and the 338 location of shelves, as indoor obstacles distort the radio signals. 339 At each blood pack a sensor tag can be installed to track the 340 temperature during delivery. A LoWPAN node is installed in each 341 container of a set of blood packs. In this case, highly dense 342 networks must be managed. 344 All nodes are statically deployed and manually configured with either 345 a single- or multi-hop connection. Different types of LoWPAN nodes 346 are configured based on the service and network requirements. 347 Especially, LCs play a role in aggregation of the sensed data from 348 blood packs. In the extended networks, more than one LoWPAN LCs can 349 be installed in a storage room. In the case that the sensed data 350 from an individual node is urgent event-driven data such as outrange 351 of temparature or humidity, it will not be accumulated (and further 352 delayed) by the LCs but immediately relayed. 354 All LoWPAN nodes do not move unless the blood packs or a container of 355 blood packs is moved. Moving nodes get connected by logical 356 attachment to a new LoWPAN. When containers of blood packs are 357 transferred to another place of the hospital or by ambulance, the 358 LoWPAN nodes on the containers associate to a new LoWPAN. 360 This type of application works based on both periodic and event- 361 driven notifications. Periodic data is used for monitoring the 362 temperature and humidity in the storage rooms. The data over or 363 under a pre-defined threshold is meaningful to report. Blood cannot 364 be used if it is exposed to the wrong environment for about 30 365 minutes. Thus, event-driven data sensed on abnormal occurrences is 366 time-critical and requires secure and reliable transmission. 368 LoWPANs must be provided with low installation and management costs, 369 and for the transportation of blood containers, precise location 370 tracking of containers is important. The hospital network manager or 371 staff can be provided with an early warning of possible chain 372 ruptures, for example by conveniently accessing comprehensive online 373 reports and data management systems. 375 Dominant parameters in industrial monitoring scenarios: 377 o Deployment: pre-planned, manually attached 379 o Mobility: no (except for asset tracking) 381 o Network Size: medium to large size, high node density 383 o Power Source: most of the time battery-operated 385 o Security Level: business-critical. Secure and reliable 386 transmission must be guaranteed. 388 o Multi-hop communication: multi-hop networking 390 o Connectivity: always on for crucial processes 392 o QoS: important for time-critical event-driven data 394 o Traffic Pattern: P2P (actuator control), MP2P (data collection) 396 o Other Issues: Sensor network management, location tracking, real- 397 time early warning 399 3.1.2. 6LoWPAN Applicability 401 The network configuration of the above use case can differ 402 substantially by system design. As illustrated in Figure 1, the 403 simplest way is to build a star topology inside of each storage room. 404 Based on the layout and size of the storage room, the LoWPAN can be 405 configured in a different way of mesh topology as shown in Figure 2. 407 Each LoWPAN node may reach the LBR by a predefined routing/forwarding 408 mechanism. Each LoWPAN node configures its link-local address and 409 obtains a prefix from its LBR by an 6LoWPAN ND procedure [5]. LoWPAN 410 nodes need to build a multi-hop connection to reach the LCs and LBR. 412 The data volume is usually not so large in this case, but is 413 sensitive to delay. Data aggregators can be installed for each 414 storage room, or just one data aggregator can collect all data. To 415 make a light transmission, UDP is likely to be chosen, but secure 416 transmission and security mechanism MUST be added. To increase 417 security, link-layer mechanisms and/or additional security mechanisms 418 SHOULD be used. 420 Because a failure of a LoWPAN node can critically affect the storage 421 of the blood packs, network management is important in this use-case. 422 A light weight management mechanism MUST be provided for the 423 management. 425 When a container is moved out from the storage room, and connected to 426 the other hospital system (if the hospital buildings are fully or 427 partly covered with LoWPANs), a mechanism to rebind to a new parent 428 node and a new LoWPAN MUST be supported. In the case that it is 429 moved by an ambulance, it will be connected to an LBR in the vehicle. 430 This type of mobility is supported by 6LoWPAN ND and routing 431 mechanism. 433 LoWPANs MUST be provided with low installation and management costs, 434 providing benefits such as reduced inventory, and precise location 435 tracking of containers, and mobile equipment (moving beds at the 436 hospital or ambulances). 438 LBR 439 | LBR: LoWPAN Border Router 440 LC----------LC----------LC LC: Local Controller node 441 / | \ / | \ / | \ (Data Aggregator) 442 n n n n n n n n n n: LoWPAN node 444 Figure 1: Storage rooms with a simple star topology 446 +------------+-----------+ 447 | | | LBR: LoWPAN Border Router 448 LBR LBR LBR(LC) LC: Local Controller node 449 | | | (Data Aggregator) 450 LC - n LC - n n n: LoWPAN Node 451 / | | | | / \ 452 n n - LC n - n - n n - n 453 | | \ | |\ 454 n n n - n n n n 456 Figure 2: Storage rooms with a mesh topology 458 3.2. Structural Monitoring 460 Intelligent monitoring in facility management can make safety checks 461 and periodic monitoring of the architecture status highly efficient. 462 Mains-powered nodes can be included in the design phase of a 463 construction or battery-equipped nodes can be added afterwards. All 464 nodes are static and manually deployed. Some data is not critical 465 for security protection (such as normal room temperature), but event- 466 driven emergency data (such as a fire alarm) MUST be handled in a 467 very critical manner. 469 3.2.1. A Use Case and its Requirements 471 Example: Bridge Safety Monitoring 473 A 1000m long concrete bridge with 10 pillars is described. Each 474 pillar and the bridge body contain 5 sensors to measure the water 475 level, and 5 vibration sensors are used to monitor its structural 476 health. The LoWPAN nodes are deployed to have 100m line-of-sight 477 distance from each other. All nodes are placed statically and 478 manually configured with a single-hop connection to the local 479 coordinator. All LoWPAN nodes are immobile while the service is 480 provided. Except from the pillars, there are no special obstacles of 481 attenuation to the node signals, but careful configuration is needed 482 to prevent signal interference between LoWPAN nodes. 484 The physical network topology is changed in case of node failure. On 485 the top part of each pillar, an sink node is placed to collect the 486 sensed data. The sink nodes of each pillar become data gathering 487 point of the LoWPAN hosts at the pillar as local coordinators. 489 This use case can be extended to medium or large size sensor networks 490 to monitor a building or for instance the safety status of highways 491 and tunnels. Larger networks of the same kind still have similar 492 characteristics such as static node placement, manual deployment and 493 dependent on the blue print of the structure, mesh topologies will be 494 built with mains-powered relay points. Periodic and event-driven 495 real-time data gathering is performed and the emergency event-driven 496 data MUST be delivered without delay. 498 Dominant parameters in structural monitoring applications: 500 o Deployment: static, organized, pre-planned 502 o Mobility: none 504 o Network Size: small (dozens of nodes) to large 506 o Power Source: mains-powered nodes are mixed with battery powered 507 (mains-power nodes will be used for local coordination or relays). 509 o Security Level: safety-critical. Secure transmission must be 510 guaranteed. Only authenticated users must be able to access and 511 handle the data. 513 o Multi-hop communication: multi-hop mesh networking is recommended 514 to be supported. 516 o Connectivity: always connected or intermittent by sleeping mode 517 scheduling. 519 o QoS: Emergency notification (fire, over-threshold vibrations, 520 water level, etc.) is required to have priority of delivery and 521 must be transmitted in a highly reliable manner. 523 o Traffic Pattern: MP2P (data collection), P2P (localized querying) 525 o Other Issues: accurate sensing and reliable transmission are 526 important. In addition, sensor status reports should be 527 maintained in a reliable monitoring system. 529 3.2.2. 6LoWPAN Applicability 531 The network configuration of this use case can be done by simple 532 topologies, however, there are many extended use cases for more 533 complex structures. The example bridge monitoring case may be the 534 simplest case (an example topology is illustrated in Figure 3). 536 The LoWPAN Nodes are installed on the place after manual optimization 537 of their location. As the communication of the leaf LoWPAN nodes may 538 be limited to the data gathering points, both 16-bit and 64-bit can 539 be used for IPv6 link-local addresses [3]. Each pillar may have one 540 LC for data collection from each pillar. Communication schedules 541 should be set up between leaf nodes and their LC to efficiently 542 gather the different types of sensed data. Each data packet may 543 include meta-information about its data, or the type of sensors could 544 be encoded in its address during the address allocation. 546 This type of application works based on both periodic and event- 547 driven notifications. The data over or under a pre-defined threshold 548 is meaningful to report. Event-driven data sensed on abnormal 549 occurrences is time-critical and requires secure and reliable 550 transmission. For energy conservation, all nodes may have periodic 551 and long sleep modes but wake up on certain events. The data 552 gathering entity can be programmed to trigger actuators installed in 553 the infrastructure, when a certain threshold value has been reached. 555 Due to the safety-critical data of the structure, authentication and 556 security are important issues here. Only authenticated users MUST be 557 allowed to access the data. Additional security SHOULD be provided 558 at the LBR for restricting the access from outside of the LoWPAN. 560 The LBR may take charge of authentication of LoWPAN nodes. Reliable 561 and secure data transmission must be guaranteed. 563 LBR - LC ----- LC ------ LC LBR: LoWPAN Border Router 564 /| | | LC: Local Controller node 565 n n n - n - n n - n n: LoWPAN Node 566 /\ | | | | 567 n n n - n n - n - n 569 Figure 3: A bridge monitoring scenario 571 3.3. Connected Home 573 The "Connected" Home or "Smart" home is with no doubt an area where 574 LoWPANs can be used to support an increasing number of services: 576 o Home safety/security 578 o Home Automation and Control 580 o Healthcare (see above section) 582 o Smart appliances and home entertainment systems 584 In home environments LoWPAN networks typically comprise a few dozen 585 and probably in the near future a few hundreds of nodes of various 586 nature: sensors, actuators and connected objects. 588 3.3.1. A Use Case and its Requirements 590 Example: Home Automation 592 The home automation and control system LoWPAN offers a wide range of 593 services: local or remote access from the Internet (via a secured 594 edge router) to monitor the home (temperature, humidity, activation 595 of remote video surveillance, status of the doors (locked or open), 596 etc.) but also for home control (activate the air conditioning/ 597 heating, door locks, sprinkler systems, etc.). Fairly sophisticated 598 systems can also optimize the level of energy consumption thanks to a 599 wide range of input from various sensors connected to the LoWPAN: 600 light sensors, presence detection, temperature, etc. in order to 601 control electric window shades, chillers, air flow control, air 602 conditioning and heating with the objective to optimize energy 603 consumption. 605 With the emergence of "Smart Grid" applications, the LoWPAN may also 606 have direct interactions with the Grid itself via the Internet to 607 report the amount of KWatts that could be load shed (Home to Grid) 608 and to receive dynamic load shedding information if/when required 609 (Grid to home): this application is also referred to as Demand- 610 Response application. Another service known as Demand Side 611 Management (DSM) could be provided by utilities to monitor and report 612 to the user its energy consumption with a fine granularity (on a per 613 device basis). Other inputs such as dynamic pricing can also be 614 received by the user from the utility that can then turn on and off 615 some appliances according to its local policy in order to reduce its 616 energy bill. 618 In terms of home safety and security, the LoWPAN is made of motion- 619 and audio-sensors, sensors at doors and windows, and video cameras to 620 which additional sensors can be added for safety (gas, water, CO, 621 Radon, smoke detection). The LoWPAN typically comprises a few dozen 622 nodes forming an ad-hoc network with multi-hop routing since the 623 nodes may not be in direct range. It is worth mentioning that the 624 number of devices tends to grow considering the number of new 625 applications for the home. In its most simple form, all nodes are 626 static and communicate with a central control module but more 627 sophisticated scenarios may also involve inter-device communication. 628 For example, a motion/presence sensor may send a multicast message to 629 a group of lights to be switched on, or a video camera will be 630 activated sending a video stream to a gateway that can be received on 631 a cell phone. 633 Ergonomics in Connected Homes is a key and the LoWPAN must be self- 634 managed and easy to install. Traffic patterns may greatly vary 635 depending on the applicability and so does the level of reliability 636 and QoS expected from the LoWPAN. Humidity sensing is typically not 637 critical and requires no immediate action whereas tele-assistance or 638 gas leak detection is critical and requires a high degree of 639 reliability. Furthermore, although some actions may not involve 640 critical data, still the response time and network delays must be on 641 the order of a few hundreds of milliseconds to preserve the user 642 experience (e.g. use a remote control to switch a light on). A 643 minority of nodes are mobile (with slow motion). With the emergence 644 of energy related applications it becomes crucial to preserve data 645 confidentiality. Connected Home LoWPAN usually do not require multi- 646 topology or QoS routing and fairly simple QoS mechanisms must be 647 supported by the LoWPAN (the number of Class of Services is usually 648 limited). 650 Dominant parameters for home automation applications: 652 o Deployment: multi-hop topologies 653 o Mobility: some degree of mobility 655 o Network Size: medium number of nodes, potentially high density 657 o Power Source: mix of battery and mains-powered devices 659 o Security Level: authentication and encryption required 661 o Multi-hop communication: no requirement for multi-topology or QoS 662 routing 664 o Connectivity: intermittent (usage-dependent sleep modes) 666 o QoS: support of limited QoS (small number of Class of Service) 668 o Traffic Pattern: P2P (inter-device), P2MP and MP2P (polling) 670 3.3.2. 6LoWPAN Applicability 672 In the home automation use case, the network topology is made of a 673 mix of a battery operated and mains-powered nodes that both 674 communication with each other and a LBR provides connectivity to the 675 outside of world for control management (Figure 4). 677 In home network, installation and management must as extremely simple 678 for the user. Link local IPv6 addresses can be used by nodes with no 679 external communication and the LBR allocates routable addresses to 680 communicate with other LoWPAN nodes not reachable over a single radio 681 transmission. 683 n --- n I: Internet 684 | | LBR: LoWPAN Border Router 685 Internet/ ------- LBR/LC -- n --- n ---- LC LC: Local controller node 686 Utility network | | /|\ n: LoWPAN Node 687 n ---- n n n n 689 (outside) (home automation system) 691 Figure 4: Home Automation scenario 693 In some scenarios, the traffic will be sent to a LC for processing 694 that may in turn decide of local actions (switch a light on, ...). 695 In other scenarios, all devices will send their data to the LCs that 696 may also act as the LBR for data processing and potential relay of 697 data to outside of the LoWPAN. It does not mean that every device 698 gets through the LC and LBR for communicating each other. For the 699 sake of illustration, some of the data may be processed to trigger 700 local action (e.g. switch off an appliance), simply store and sent 701 once enough data has been accumulated (e.g. energy consumption for 702 the past 6 hours for a set of appliances) or could trigger an alarm 703 immediately sent to a datacenter (e.g. gas leak detection). 705 Although in the majority of cases nodes within the LoWPAN will be in 706 direct range, some nodes will reach the LBR/LC with a 2-3 hops path 707 (with the emergence of several low power media such as low power PLC) 708 in which case LoWPAN routers will be deployed in the home to 709 interconnect the various IPv6 links. 711 The home LoWPAN must be able to provide extremely reliable 712 communication in support of some specific application (e.g. fire, gas 713 leak detection, health monitoring) whereas other application may not 714 be critical at all (e.g humidity monitoring). Similarly some 715 information may require the use of security mechanisms for 716 authentication, confidentiality. 718 3.4. Healthcare 720 LoWPANs are envisioned to be heavily used in healthcare environments. 721 They have a big potential to ease the deployment of new services by 722 getting rid of cumbersome wires and simplify patient care in 723 hospitals and for home care. In healthcare environments, delayed or 724 lost information may be a matter of life or death. 726 Various systems, ranging from simple wearable remote controls for 727 tele-assistance or intermediate systems with wearable sensor nodes 728 monitoring various metrics to more complex systems for studying life 729 dynamics, can be supported by LoWPANs. In the latter category, a 730 large amount of data from various LoWPAN nodes can be collected: 731 movement pattern observation, checks that medicaments have been 732 taken, object tracking, and more. An example of such a deployment is 733 described in [9] using the concept of Personal Networks. 735 3.4.1. A Use Case and its Requirements 737 Example: healthcare at home by tele-assistance 739 A senior citizen who lives alone wears one to few wearable LoWPAN 740 nodes to measure heartbeat, pulse rate, etc. Dozens of LoWPAN nodes 741 are densely installed at home for movement detection. A LBR at home 742 will send the sensed information to a connected healthcare center. 743 Portable base stations with LCDs may be used to check the data at 744 home, as well. The different roles of devices have different duty- 745 cycles, which affect node management. 747 Multipath interference may often occur due to the mobility of the 748 patients at home, where there are many walls and obstacles. Even 749 during sleeping, the change of the body position may affect the radio 750 propagation. 752 Data is gathered both periodically and event-driven. In this 753 application, event-driven data can be very time-critical. Thus, 754 real-time and reliable transmission must be guaranteed. 756 Privacy also becomes an serious issue in this case, as the sensed 757 data is very personal. In addition, different data will be provided 758 to the hospital system from what is given to a patient's family 759 members. Role-based access control is needed to support such 760 services, thus support of authorization and authentication is 761 important. 763 Dominant parameters in healthcare applications: 765 o Deployment: pre-planned 767 o Mobility: moderate (patient's mobility) 769 o Network Size: small, high node density 771 o Power Source: hybrid 773 o Security Level: Data privacy and security MUST be provided. 774 Encryption is required. Role based access control is required to 775 be supported by light weight authentication mechanism 777 o Multi-hop communication: multi-hop for homecare devices, star 778 topology on patients body. Multipath interference due to walls 779 and obstacles at home must be considered. 781 o Connectivity: always on 783 o QoS: high level of support (life and death implication), role- 784 based 786 o Traffic Pattern: MP2P/P2MP (data collection), P2P (local 787 diagnostic) 789 o Other issues: Plug-and-play configuration is required for mainly 790 non-technical end-users. Real-time data acquisition and analysis 791 are important. Efficient data management is needed for various 792 devices which have different duty-cycles, and for role-based data 793 control. Reliability and robustness of the network are also 794 essential. 796 3.4.2. 6LoWPAN Applicability 798 In this use case, the local network size is rather small (less than 799 10s of nodes). The home care system is statically configured with 800 multi-hop paths and the patient's body network can be built as a star 801 topology. The LBR at home is the sink node in the routing path from 802 sources on the patient's body. A plug-and-play configuration is 803 required. As the communication of the system is limited to a home 804 environment, both 16-bit and 64-bit can be used for IPv6 link-local 805 addresses [3]. An example topology is provided in Figure 5. 807 The patient's body network can be simply configured as a star 808 topology with a LC dealing with data aggregation and dynamic network 809 attachment when the patient moves around at home. As multipath 810 interference may often occur due to the patients' mobility at home, 811 the deployment of LoWPAN nodes and transmission paths should be well 812 considered. At home, some nodes can be installed with power- 813 affluence status, and those LoWPAN nodes can be used for relaying 814 points or data aggregation points. 816 The sensed information MUST be maintained with the identification of 817 the patient no matter if the patient visits the connected hospital or 818 stays at home. If the patient's LoWPAN uses globally unique IPv6 819 address, the address can be used for the identification. However, it 820 causes cost for privacy and security. The hospital LoWPAN where the 821 patient's information is transferring needs to operate additional 822 identification system together with strong authority and 823 authentication mechanism. The connection between the LBR at home and 824 the LBR at Hospital must be reliable and secure, as the data is 825 privacy-critical. To achieve this, additional policy for security is 826 recommended between the two LoWPAN. 828 n - n I: Internet 829 | | LBR: Edge Router 830 LBR --- I -- LBR - n - n - LC LC: Local controller node 831 /|\ | | /|\ n: LoWPAN Node 832 .. . .. n -- n n n n 834 (hospital) (home system) (patient) 836 Figure 5: A mobile healthcare scenario. 838 3.5. Vehicle Telematics 840 LoWPANs play an important role in intelligent transportation systems. 841 Incorporated in roads, vehicles, and traffic signals, they contribute 842 to the improvement of safety of transporting systems. Through 843 traffic or air-quality monitoring, they increase the possibilities in 844 terms of traffic flow optimization and help reducing road congestion. 846 3.5.1. A Use Case and its Requirements 848 Example: Telematics 850 As shown in Figure 6, scattered LoWPAN Nodes are included in roads 851 during their construction for motion monitoring. When a car passes 852 over these nodes, the possibility is then given to track the 853 trajectory and velocity of cars for safety purposes. 855 The lifetime of the LoWPAN Nodes incorporated into roads is expected 856 to be as long as the life time of the roads (about 10 years). Multi- 857 hop communication is possible between LoWPAN Nodes, and the network 858 should be able to cope with the deterioration over time of the node 859 density due to power fails. Sink nodes placed at the side of road 860 are most likely mains-powered, LoWPAN Nodes in the roads run on 861 battery. Power saving schemes might intermittently disconnect the 862 nodes. A rough estimate of 4 nodes per square meter is needed. 863 Other applications may involve car-to-car communication for increased 864 road safety. 866 Dominant parameters in vehicle telematics applications: 868 o Deployment: scattered, pre-planned 870 o Mobility: none (road infrastructure), high (vehicle) 872 o Network Size: large (road infrastructure), small (vehicle) 874 o Power Source: hybrid 876 o Security Level: low 878 o Multi-hop communication: multi-hop, especially ad-hoc 880 o Connectivity: intermittent 882 o QoS: support of limited QoS 884 o Traffic Pattern: mostly Point-to-Point (P2P), Point-to-Multi-Point 885 (P2MP) 887 3.5.2. 6LoWPAN Applicability 889 For this use case, the network topology includes fixed LBRs that are 890 mains-powered and have a connection to high speed networks (e.g., 891 Internet) in order to reach the transportation control center 892 (Figure 6). These LBRs may be logically combined with LC as a data 893 sink to gather sensed data from a number of LoWPAN Nodes inserted in 894 the tarmac of the road. In the road infrastructure, a LoWPAN with 895 one LBR forms a fixed network and the LoWPAN nodes are installed by 896 manual optimization of their location. 898 +-----+ 899 | LBR |----------------------------- LBR ... 900 +-----+ (at the road side) 901 -------|------------------------------ 902 | 903 n -- n --- n --- n +---|---+ LBR: LoWPAN Border Router 904 / \ | | n-n-n | n: LoWPAN Node 905 n n n +---|---+ 906 (cars) 907 -------------------------------------- 909 Figure 6: Telematics scenario. 911 3.6. Agricultural Monitoring 913 Accurate temporal and spatial monitoring can significantly increase 914 agricultural productivity. Due to natural limitations, such as a 915 farmers' inability to check the crop at all times of day or 916 inadequate measurement tools, luck often plays a too large role in 917 the success of harvests. Using a network of strategically placed 918 sensors, indicators such as temperature, humidity, soil condition, 919 can be automatically monitored without labor intensive field 920 measurements. For example, sensor networks could provide precise 921 information about crops in real time, enabling businesses to reduce 922 water, energy, and pesticide usage and enhancing environment 923 protection. The sensing data can be used to find optimal 924 environments for the plants. In addition, the data on the planting 925 condition can be saved by sensor tags, which can be used in supply 926 chain management. 928 3.6.1. A Use Case and its Requirements 930 Example: Automated Vineyard 932 In a vineyard with medium to large geographical size, a number of 50 933 to 100 LC nodes are manually deployed in order to provide full signal 934 coverage over the study area. An additional number of 100 to 1000 935 leaf nodes with (possibly heterogeneous) specialized sensors (i.e., 936 humidity, temperature, soil condition, sunlight) are attached to the 937 LCs in local wireless star topologies, periodically reporting 938 measurements to the associated LCs. For example, in a 20-acre 939 vineyard with 8 parcels of land, 10 LoWPAN Nodes are placed within 940 each parcel to provide readings on temperature and soil moisture. 941 The LoWPAN Nodes are able to support a multi-hop forwarding/routing 942 scheme to enable data transmission to a sink node at the edge of the 943 vineyard. Each of the 8 parcels contains one data aggregator to 944 collect the sensed data. 946 Localization is important for this type of LoWPAN where installed in 947 a geographically large area, for pinning down where an event 948 occurred, and for combining gathered data with their actual position. 949 Using manual deployment, device addresses can be used for identifying 950 the position and localization. For randomly deployed nodes, a 951 localization algorithm needs to be applied. 953 There might be various types of sensor devices deployed in a single 954 LoWPAN, each providing raw data with different semantics. Thus, an 955 additional method is required to correctly interpret sensor readings. 956 Each data packet may include meta-information about its data, or a 957 type of a sensor could be encoded in its address during address 958 allocation. 960 Dominant parameters in agricultural monitoring: 962 o Deployment: pre-planned 964 The nodes are installed outdoors or in a greenhouse with high 965 exposure to water, soil, dust, in dynamic environments of moving 966 people and machinery, with growing crop and foliage. LoWPAN nodes 967 can be deployed in a pre-defined manner, considering the harsh 968 environment. 970 o Mobility: all static 972 o Network Size: medium to large, low to medium density 974 o Power Source: all nodes are battery-powered except the sink, or 975 energy harvesting 977 o Security Level: business-critical. Light-weight security or a 978 global key management can be used depending on the business 979 purpose. 981 o Multi-hop communication: mesh topology with local star 982 connections. 984 o Connectivity: intermittent (many sleeping nodes) 986 o QoS: support of limited QoS (small number of Class of Service) 988 o Traffic Pattern: Mainly MP2P/P2MP. P2P actuator triggering. 990 o Other issues: Time synchronization among sensors are required, but 991 the traffic interval may not be frequent (e.g. once in 30 minutes 992 to 1 hour). 994 3.6.2. 6LoWPAN Applicability 996 The network configuration in this use case might, in the most simple 997 case, look like illustrated in Figure 7. This static scenario 998 consists of one or more fixed LBR that are mains-powered and have a 999 high-bandwidth connection to a backbone link, which might be placed 1000 in a control center, or connect to the Internet. The LBRs are 1001 strategically located at the border of vineyard parcels, acting as 1002 data sinks. A number of LCs are placed along a row of plants with 1003 individual LoWPAN nodes spread around them. 1005 While the LBRs implement the IPv6 Neighbor Discovery protocol (RFC 1006 4861) to connect the outside of the LoWPAN, the LoWPAN Nodes operate 1007 a more energy-considering ND described in [5], which includes basic 1008 bootstrapping and address assignment. Each LBR can have predefined 1009 forward management information to a central data aggregation point, 1010 if necessary. 1012 LoWPAN nodes may send event-driven notifications when readings exceed 1013 certain thresholds, such as low soil humidity; which may 1014 automatically trigger a water sprinkler in the local environment. 1015 For increased energy efficiency, all LoWPAN Nodes are in periodic 1016 sleep state. However, the LCs need to be aware of sudden events from 1017 the leaf nodes. Their sleep periods should therefore be set to 1018 shorter intervals. Communication schedules must be set up between 1019 master and leaf nodes, and global time synchronization is needed to 1020 account for clock drift. 1022 Also, the result of data collection may activate actuators. Context- 1023 awareness, node identification and data collection on the application 1024 level are necessary. 1026 I 1027 | 1028 | n n n n n n n n n I: Internet 1029 | \|/ \|/ \|/ LBR: LoWPAN Border Router 1030 LBR----LC------LC------LC LC: Local Controller node 1031 | /|\ /|\ /|\ n: LoWPAN node 1032 | n n n n n n n n n 1033 | 1034 LBR 1035 ... 1037 Figure 7: Automated vineyard scenario. 1039 4. Security Considerations 1041 Security requirements differ by use case. For example, industrial 1042 and structural monitoring applications are safety-critical. Secure 1043 transmission MUST be guaranteed, and only authenticated users MUST be 1044 able to access and handle the data. Lightweight key mechanisms can 1045 be used. In health care system, data privacy is an important issue. 1046 Encryption is required, and role-based access control is required to 1047 be supported by a proper authentication mechanism. 1049 5. IANA Considerations 1051 This document contains no actions for IANA. 1053 6. Acknowledgements 1055 Thanks for David Cypher for giving more insight on the IEEE 802.15.4 1056 standard, and Irene Fernandez, Shoichi Sakane and Paul Chilton for 1057 intensive review and valuable comments. 1059 7. References 1061 7.1. Normative References 1063 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1064 Levels", BCP 14, RFC 2119, March 1997. 1066 [2] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over 1067 Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, 1068 Assumptions, Problem Statement, and Goals", RFC 4919, 1069 August 2007. 1071 [3] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1072 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", 1073 RFC 4944, September 2007. 1075 [4] IEEE Computer Society, "IEEE Std. 802.15.4-2006 (as amended)", 1076 2007. 1078 7.2. Informative References 1080 [5] Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 1081 Discovery Optimization for Low-power and Lossy Networks", 1082 draft-ietf-6lowpan-nd-15 (work in progress), December 2010. 1084 [6] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams 1085 in 6LoWPAN Networks", draft-ietf-6lowpan-hc-13 (work in 1086 progress), September 2010. 1088 [7] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1089 Statement and Requirements for 6LoWPAN Routing", 1090 draft-ietf-6lowpan-routing-requirements-08 (work in progress), 1091 November 2010. 1093 [8] Roemer, K. and F. Mattern, "The Design Space of Wireless Sensor 1094 Networks", December 2004. 1096 [9] den Hartog, F., Schmidt, J., and A. de Vries, "On the Potential 1097 of Personal Networks for Hospitals", May 2006. 1099 Authors' Addresses 1101 Eunsook Kim 1102 ETRI 1103 161 Gajeong-dong 1104 Yuseong-gu 1105 Daejeon 305-700 1106 Korea 1108 Phone: +82-42-860-6124 1109 Email: eunah.ietf@gmail.com 1111 Dominik Kaspar 1112 Simula Research Laboratory 1113 Martin Linges v 17 1114 Snaroya 1367 1115 Norway 1117 Phone: +47-4748-9307 1118 Email: dokaspar.ietf@gmail.com 1120 Nicolas G. Chevrollier 1121 TNO 1122 Brassersplein 2 1123 P.O. Box 5050 1124 Delft 2600 1125 The Netherlands 1127 Phone: +31-15-285-7354 1128 Email: nicolas.chevrollier@tno.nl 1130 JP Vasseur 1131 Cisco Systems, Inc 1132 1414 Massachusetts Avenue 1133 Boxborough MA 01719 1134 USA 1136 Phone: 1137 Email: jpv@cisco.com