idnits 2.17.1 draft-ietf-6lowpan-usecases-10.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 2 instances 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 (July 27, 2011) is 4650 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 1168, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5996 (ref. '5') (Obsoleted by RFC 7296) == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-17 == Outdated reference: A later version (-10) exists of draft-ietf-6lowpan-routing-requirements-09 Summary: 2 errors (**), 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: January 28, 2012 Simula Research Laboratory 6 N. Chevrollier 7 TNO 8 JP. Vasseur 9 Cisco Systems, Inc 10 July 27, 2011 12 Design and Application Spaces for 6LoWPANs 13 draft-ietf-6lowpan-usecases-10 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 January 28, 2012. 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 . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . 16 84 3.3.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 17 85 3.4. Healthcare . . . . . . . . . . . . . . . . . . . . . . . . 19 86 3.4.1. A Use Case and its Requirements . . . . . . . . . . . 19 87 3.4.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 20 88 3.5. Vehicle Telematics . . . . . . . . . . . . . . . . . . . . 21 89 3.5.1. A Use Case and its Requirements . . . . . . . . . . . 21 90 3.5.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 22 91 3.6. Agricultural Monitoring . . . . . . . . . . . . . . . . . 23 92 3.6.1. A Use Case and its Requirements . . . . . . . . . . . 23 93 3.6.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 25 94 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 96 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 97 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 98 7.1. Normative References . . . . . . . . . . . . . . . . . . . 31 99 7.2. Informative References . . . . . . . . . . . . . . . . . . 31 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 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 [6]. 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 Readers are expected to be familiar with all the terms and concepts 159 that are discussed in "IPv6 over Low-Power Wireless Personal Area 160 Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and 161 Goals" [3], and " Transmission of IPv6 Packets over IEEE 802.15.4 162 Networks" [4]. 164 Readers would benefit from reading 6LoWPAN ND [7], 6LoWPAN header 165 compression [8], and 6LoWPAN Routing Requirements [9] for the details 166 of the 6LoWPAN work. 168 This document defines the following terms: 170 LC (Local Controller) 172 A logical functional entity that performs the special role of 173 coordinating and controlling its child nodes for local data 174 aggregation, status management of local nodes, etc. There may be 175 multiple instances of local controller nodes in a LoWPAN. 177 LBR (LoWPAN Border Router) 179 A border router is located at the junction of separate LoWPAN 180 networks or between a LoWPAN network and another IP network. 181 There may be one or more LBRs at the LoWPAN network boundary. A 182 LBR is the responsible authority for IPv6 Prefix propagation for 183 the LoWPAN network it is serving. An isolated LoWPAN also 184 contains a LBR in the network, which provides the prefix(es) for 185 the isolated network. 187 1.2. Premise of network configuration 189 The IEEE 802.15.4 standard distinguishes between two types of nodes, 190 reduced-function devices (RFDs) and full-function devices (FFDs). As 191 this distinction is based on some MAC features that are not always in 192 use, we are not using this distinction in this document. 194 6LoWPAN networks can be deployed using either route-over or mesh- 195 under architectures. As the choice of route-over or mesh-under does 196 not affect the applicability of 6LoWPAN technologies to the use cases 197 described in the document, we will use the term "6LoWPAN network" to 198 mean either a route-over or mesh-under network. 200 Communication to corresponding nodes outside of the LoWPAN is 201 becoming increasingly important for convenient data collection and 202 remote control purposes. The intermediate LoWPAN nodes act as packet 203 forwarders (LM) or LoWPAN routers (LR) and connect the entire LoWPAN 204 in a multi-hop fashion. LoWPAN Border Routers (LBRs) are used to 205 interconnect a LoWPAN to other networks, or to form an extended 206 LoWPAN by connecting multiple LoWPANs. Before LoWPAN nodes obtain 207 their IPv6 addresses and the network is configured, each LoWPAN 208 executes a link-layer configuration either by the mechanisms 209 specified in 6lowpan ND [7] or by using a coordinator who is 210 responsible for link-layer short address allocation. However, the 211 link-layer coordinator functionality is out of the scope of this 212 document. Details of address allocation of 6LoWPAN ND is in [7]. 214 A LoWPAN can be configured as Mesh Under or Route Over (see 215 Terminology in [7]). In a Route Over configuration, multihop 216 transmission is carried out by LRs using IP routing. In a Mesh Under 217 configuration, the link-local scope reaches to the boundaries of the 218 LoWPAN, and multihop transmission is achieved by forwarding data at 219 the link layer or in an 6LoWPAN adaptation layer. More information 220 about Mesh Under and Route Over is in 6LoWPAN ND [7] and 6LoWPAN 221 Routing Requirements [9]. 223 2. Design Space 225 Inspired by [10], this section lists the dimensions used to describe 226 the design space of wireless sensor networks in the context of the 227 6LoWPAN Working Group. The design space is already limited by the 228 unique characteristics of a LoWPAN (e.g., low-power, short range, 229 low-bit rate) as described in [3]. The possible dimensions for 230 scenario categorization used in this document are described as 231 follows: 233 o Deployment: LoWPAN nodes can be scattered randomly or they may be 234 deployed in an organized manner in a LoWPAN. The deployment can 235 occur at once, or as an iterative process. The selected type of 236 deployment has an impact on node density and location. This 237 feature affects how to organize (manually or automatically) the 238 LoWPAN and how to allocate addresses in the network. 240 o Network Size: The network size takes into account nodes that 241 provide the intended network capability. The number of nodes 242 involved in a LoWPAN could be small (10 nodes), moderate (several 243 100s), or large (over a 1000). 245 o Power Source: The power source of nodes, whether the nodes are 246 battery-powered or mains-powered, influences the network design. 247 The power may also be harvested from solar cells or other sources 248 of energy. Hybrid solutions are possible where only part of the 249 network is mains-powered. 251 o Connectivity: Nodes within a LoWPAN are considered "always 252 connected" when there is a network connection between any two 253 given nodes. However, due to external factors (e.g., extreme 254 environment, mobility) or programmed disconnections (e.g., 255 sleeping mode), the network connectivity can be from 256 "intermittent" (i.e., regular disconnections) to "sporadic" (i.e., 257 almost always disconnected network). Differences in L2 duty- 258 cycling settings may additionally impact the connectivity due to 259 highly varying bit-rates. 261 o Multi-hop communication: The multi-hop communication factor 262 highlights the number of hops that has to be traversed to reach 263 the edge of the network or a destination node within it. A single 264 hop may be sufficient for simple star-topologies, but a multi-hop 265 communication scheme is required for more elaborate topologies, 266 such as meshes or trees. In previous work by academia and 267 industry on LoWPANs, various routing mechanisms were introduced, 268 such as data-centric, event-driven, address-centric, localization- 269 based, geographical routing, etc. This document does not make use 270 of such a fine granularity but rather uses topologies and single/ 271 multi-hop communication. 273 o Traffic Pattern: several traffic patterns may be used in LoWPANs. 274 To name a few, Point-to-Multi-Point (P2MP), Multi-Point-to-Point 275 (MP2P) and Point-to-Point (P2P). 277 o Security Level: LoWPANs may carry sensitive information and 278 require high-level security support where the availability, 279 integrity, and confidentiality of the information are crucial. 281 o Mobility: Inherent to the wireless characteristics of LoWPANs, 282 nodes could move or be moved around. Mobility can be an induced 283 factor (e.g., sensors in an automobile), hence not predictable, or 284 a controlled characteristic (e.g., pre-planned movement in a 285 supply chain). 287 o Quality of Service (QoS): QoS issues in LoWPANs may be very 288 different from the traditional end-to-end QoS as in LoWPAN 289 applications, one end is not a single sensor node, but often a 290 group of sensor nodes. Parameters for QoS should consider 291 collective data for latency, packet loss, data throughput, etc. 292 In addition, QoS requirements can be different based on the data 293 delivery model such as event-driven, query-driven, continuous 294 real-time, or continuous non-real-time delivery model, which 295 usually coexist in LoWPAN applications. QoS issues in LoWPANs are 296 more likely related to corresponding application specific data 297 delivery requirements within resource-constrained LoWPANs. 299 3. Application Scenarios 301 This section lists a fundamental set of LoWPAN application scenarios 302 in terms of system design. A complete list of practical use cases is 303 not the objective of this document. 305 3.1. Industrial Monitoring 307 LoWPAN applications for industrial monitoring can be associated with 308 a broad range of methods to increase productivity, energy efficiency, 309 and safety of industrial operations in engineering facilities and 310 manufacturing plants. Many companies currently use time-consuming 311 and expensive manual monitoring to predict failures and to schedule 312 maintenance or replacements in order to avoid costly manufacturing 313 downtime. LoWPANs can be inexpensively installed to provide more 314 frequent and more reliable data. The deployment of LoWPANs can 315 reduce equipment downtime and eliminate manual equipment monitoring 316 that is costly to be carried out. Additionally, data analysis 317 functionality can be placed into the network, eliminating the need 318 for manual data transfer and analysis. 320 Industrial monitoring can be largely split into the following 321 application fields: 323 o Process Monitoring and Control: combining advanced energy metering 324 and sub-metering technologies with wireless sensor networking in 325 order to optimize factory operations, reduce peak demand, 326 ultimately lower costs for energy, avoid machine downtimes, and 327 increase operation safety. 329 A plant's monitoring boundary often does not cover the entire 330 facility but only those areas considered critical to the process. 331 Easy to install wireless connectivity extends this line to include 332 peripheral areas and process measurements that were previously 333 infeasible or impractical to reach with wired connections. 335 o Machine Surveillance: ensuring product quality and efficient and 336 safe equipment operation. Critical equipment parameters such as 337 vibration, temperature, and electrical signature are analyzed for 338 abnormalities that are suggestive of impending equipment failure 339 (see Section 3.2). 341 o Supply Chain Management and Asset Tracking: with the retail 342 industry being legally responsible for the quality of sold goods, 343 early detection of inadequate storage conditions with respect to 344 temperature will reduce risk and cost to remove products from the 345 sales channel. Examples include container shipping, product 346 identification, cargo monitoring, distribution and logistics. 348 o Storage Monitoring: sensor systems designed to prevent releases of 349 regulated substances to ground water, surface water and soil. 350 This application field may also include theft/tampering prevention 351 systems for storage facilities or other infrastructure, such as 352 pipelines. 354 3.1.1. A Use Case and its Requirements 356 Example: Hospital Storage Rooms 358 In a hospital, maintenance of the right temperature in storage rooms 359 is very critical. Red blood cells need to be stored at 2 to 6 360 degrees Celsius, blood platelets at 20 to 24 C, and blood plasma 361 below -18 C. For anti-cancer medicine, maintaining a humidity of 45% 362 to 55% is required. Storage rooms have temperature sensors and 363 humidity sensors every 25m to 100m, based on the floor plan and the 364 location of shelves, as indoor obstacles distort the radio signals. 365 At each blood pack a sensor tag can be installed to track the 366 temperature during delivery. A LoWPAN node is installed in each 367 container of a set of blood packs. In this case, highly dense 368 networks must be managed. 370 All nodes are statically deployed and manually configured with either 371 a single- or multi-hop connection. Different types of LoWPAN nodes 372 are configured based on the service and network requirements. 373 Especially, LCs play a role in aggregation of the sensed data from 374 blood packs. In the extended networks, more than one LoWPAN LCs can 375 be installed in a storage room. In the case that the sensed data 376 from an individual node is urgent event-driven data such as outrange 377 of temparature or humidity, it will not be accumulated (and further 378 delayed) by the LCs but immediately relayed. 380 All LoWPAN nodes do not move unless the blood packs or a container of 381 blood packs is moved. Moving nodes get connected by logical 382 attachment to a new LoWPAN. When containers of blood packs are 383 transferred to another place of the hospital or by ambulance, the 384 LoWPAN nodes on the containers associate to a new LoWPAN. 386 This type of application works based on both periodic and event- 387 driven notifications. Periodic data is used for monitoring the 388 temperature and humidity in the storage rooms. The data over or 389 under a pre-defined threshold is meaningful to report. Blood cannot 390 be used if it is exposed to the wrong environment for about 30 391 minutes. Thus, event-driven data sensed on abnormal occurrences is 392 time-critical and requires secure and reliable transmission. 394 LoWPANs must be provided with low installation and management costs, 395 and for the transportation of blood containers, precise location 396 tracking of containers is important. The hospital network manager or 397 staff can be provided with an early warning of possible chain 398 ruptures, for example by conveniently accessing comprehensive online 399 reports and data management systems. 401 Dominant parameters in industrial monitoring scenarios: 403 o Deployment: pre-planned, manually attached 405 o Mobility: no (except for asset tracking) 407 o Network Size: medium to large size, high node density 409 o Power Source: most of the time battery-operated 411 o Security Level: business-critical. Secure transmission must be 412 guaranteed. 414 o Multi-hop communication: multi-hop networking 416 o Connectivity: always on for crucial processes 418 o QoS: important for time-critical event-driven data 420 o Traffic Pattern: P2P (actuator control), MP2P (data collection) 422 o Other Issues: Sensor network management, location tracking, real- 423 time early warning 425 3.1.2. 6LoWPAN Applicability 427 The network configuration of the above use case can differ 428 substantially by system design. As illustrated in Figure 1, the 429 simplest way is to build a star topology inside of each storage room. 430 Based on the layout and size of the storage room, the LoWPAN can be 431 configured in a different way of mesh topology as shown in Figure 2. 433 Each LoWPAN node may reach the LBR by a predefined routing/forwarding 434 mechanism. Each LoWPAN node configures its link-local address and 435 obtains a prefix from its LBR by an 6LoWPAN ND procedure [7]. LoWPAN 436 nodes need to build a multi-hop connection to reach the LCs and LBR. 438 Secure data transmission and authentication is crucial in a hospital 439 scenario to prevent personal information to be retrieved by an 440 adversary. Confidential data must be encrypted not only in 441 transmission, but also when stored on nodes, because nodes can 442 potentially be stolen. 444 The data volume is usually not so large in this case, but is 445 sensitive to delay. Data aggregators can be installed for each 446 storage room, or just one data aggregator can collect all data. To 447 make a light transmission, UDP is likely to be chosen, but secure 448 transmission and security mechanism must be added. To increase 449 security, link-layer mechanisms and/or additional security mechanisms 450 should be used. 452 Because a failure of a LoWPAN node can critically affect the storage 453 of the blood packs, network management is important in this use-case. 454 A light-weight management mechanism must be provided for the 455 management. 457 The service quality of this case is highly related to effective 458 handling of event-driven data which is delay intolerant and mission 459 critical. The event of wrong humidity and temperature needs to be 460 detected as quickly and reliable as possible. It is important to 461 provide efficient resource usage for such data with consideration of 462 minimal usage of energy. Energy aware QoS support in wireless sensor 463 networks is a challenging issue [13]. It can be considered to 464 provide appropriate data aggreation for minimizing the delay, 465 maximizing the accuracy of the delivery by using power-affluent 466 nodes, or aided by middleware or other types of network elements. 468 When a container is moved out from the storage room, and connected to 469 the other hospital system (if the hospital buildings are fully or 470 partly covered with LoWPANs), a mechanism to rebind to a new parent 471 node and a new LoWPAN must be supported. In the case that it is 472 moved by an ambulance, it will be connected to an LBR in the vehicle. 473 This type of mobility is supported by 6LoWPAN ND and routing 474 mechanism. 476 LoWPANs must be provided with low installation and management costs, 477 providing benefits such as reduced inventory, and precise location 478 tracking of containers, and mobile equipment (moving beds at the 479 hospital or ambulances). 481 LBR 482 | LBR: LoWPAN Border Router 483 LC----------LC----------LC LC: Local Controller node 484 / | \ / | \ / | \ (Data Aggregator) 485 n n n n n n n n n n: LoWPAN node 487 Figure 1: Storage rooms with a simple star topology 489 +------------+-----------+ 490 | | | LBR: LoWPAN Border Router 491 LBR LBR LBR (LC) LC: Local Controller node 492 | | | (Data Aggregator) 493 LC - n LC - n n n: LoWPAN Node 494 / | | | | / \ 495 n n - LC n - n - n n - n 496 | | \ | |\ 497 n n n - n n n n 499 Figure 2: Storage rooms with a mesh topology 501 3.2. Structural Monitoring 503 Intelligent monitoring in facility management can make safety checks 504 and periodic monitoring of the architecture status highly efficient. 505 Mains-powered nodes can be included in the design phase of a 506 construction or battery-equipped nodes can be added afterwards. All 507 nodes are static and manually deployed. Some data is not critical 508 for security protection (such as periodic or query-driven 509 notification of normal room temperature), but event-driven emergency 510 data (such as a fire alarm) must be handled in a very critical 511 manner. 513 3.2.1. A Use Case and its Requirements 515 Example: Bridge Safety Monitoring 517 A 1000m long concrete bridge with 10 pillars is described. Each 518 pillar and the bridge body contain 5 sensors to measure the water 519 level, and 5 vibration sensors are used to monitor its structural 520 health. The LoWPAN nodes are deployed to have 100m line-of-sight 521 distance from each other. All nodes are placed statically and 522 manually configured with a single-hop connection to the local 523 coordinator. All LoWPAN nodes are immobile while the service is 524 provided. Except from the pillars, there are no special obstacles of 525 attenuation to the node signals, but careful configuration is needed 526 to prevent signal interference between LoWPAN nodes. 528 The physical network topology is changed in case of node failure. On 529 the top part of each pillar, a sink node is placed to collect the 530 sensed data. The sink nodes of each pillar become data gathering 531 point of the LoWPAN hosts at the pillar and act as local 532 coordinators. 534 This use case can be extended to medium or large size sensor networks 535 to monitor a building or for instance the safety status of highways 536 and tunnels. Larger networks of the same kind still have similar 537 characteristics such as static node placement, manual deployment and 538 dependent on the blue print of the structure, mesh topologies will be 539 built with mains-powered relay points. Periodic, query-driven, and 540 event-driven real-time data gathering is performed and the emergency 541 event-driven data must be delivered without delay. 543 Dominant parameters in structural monitoring applications: 545 o Deployment: static, organized, pre-planned 547 o Mobility: none 549 o Network Size: small (dozens of nodes) to large 551 o Power Source: mains-powered nodes are mixed with battery powered 552 (mains-power nodes will be used for local coordination or relays). 554 o Security Level: safety-critical. Secure transmission must be 555 guaranteed. Only authenticated users must be able to access and 556 handle the data. 558 o Multi-hop communication: multi-hop mesh networking is recommended 559 to be supported. 561 o Connectivity: always connected or intermittent by sleeping mode 562 scheduling. 564 o QoS: Emergency notification (fire, over-threshold vibrations, 565 water level, etc.) is required to have priority of delivery and 566 must be transmitted in a highly reliable manner. 568 o Traffic Pattern: MP2P (data collection), P2P (localized querying) 570 o Other Issues: accurate sensing and reliable transmission are 571 important. In addition, sensor status reports should be 572 maintained in a reliable monitoring system. 574 3.2.2. 6LoWPAN Applicability 576 The network configuration of this use case can be done by simple 577 topologies, however, there are many extended use cases for more 578 complex structures. The example bridge monitoring case may be the 579 simplest case (an example topology is illustrated in Figure 3). 581 The LoWPAN Nodes are installed on the place after manual optimization 582 of their location. As the communication of the leaf LoWPAN nodes may 583 be limited to the data gathering points, both 16-bit and 64-bit can 584 be used for IPv6 link-local addresses [4]. 586 Each pillar might have one LC for data collection from each pillar. 587 Communication schedules should be set up between leaf nodes and their 588 LC to efficiently gather the different types of sensed data. Each 589 data packet may include meta-information about its data, or the type 590 of sensors could be encoded in its address during the address 591 allocation. 593 This type of application works based on periodic, query-driven and 594 event-driven notifications. The data over or under a pre-defined 595 threshold is meaningful to report. Event-driven data sensed on 596 abnormal occurrences is time-critical and requires secure and 597 reliable transmission. Conflictly, for energy conservation, all 598 nodes may have periodic and long sleep modes but wake up on certain 599 events. To ensure the reliability of such emergency event-driven 600 data, such data is immediately relayed to a power-affluet or mains- 601 power node which usually takes a LoWPAN router role, and does not go 602 into a long sleep status. The data gathering entity can be 603 programmed to trigger actuators installed in the infrastructure, when 604 a certain threshold value has been reached. 606 Due to the safety-critical data of the structure, authentication and 607 security are important issues here. Only authenticated users must be 608 allowed to access the data. Additional security should be provided 609 at the LBR for restricting the access from outside of the LoWPAN. 610 The LBR may take charge of authentication of LoWPAN nodes. Reliable 611 and secure data transmission must be guaranteed. 613 LBR - LC ----- LC ------ LC LBR: LoWPAN Border Router 614 /| | | LC: Local Controller node 615 n n n - n - n n - n n: LoWPAN Node 616 /\ | | | | 617 n n n - n n - n - n 619 Figure 3: A bridge monitoring scenario 621 3.3. Connected Home 623 The "Connected" Home or "Smart" home is with no doubt an area where 624 LoWPANs can be used to support an increasing number of services: 626 o Home safety/security 628 o Home Automation and Control 630 o Healthcare (see above section) 631 o Smart appliances and home entertainment systems 633 In home environments LoWPAN networks typically comprise a few dozen 634 and probably in the near future a few hundreds of nodes of various 635 nature: sensors, actuators and connected objects. 637 3.3.1. A Use Case and its Requirements 639 Example: Home Automation 641 The home automation and control system LoWPAN offers a wide range of 642 services: local or remote access from the Internet (via a secured 643 edge router) to monitor the home (temperature, humidity, activation 644 of remote video surveillance, status of the doors (locked or open), 645 etc.) but also for home control (activate the air conditioning/ 646 heating, door locks, sprinkler systems, etc.). Fairly sophisticated 647 systems can also optimize the level of energy consumption thanks to a 648 wide range of input from various sensors connected to the LoWPAN: 649 light sensors, presence detection, temperature, etc. in order to 650 control electric window shades, chillers, air flow control, air 651 conditioning and heating with the objective to optimize energy 652 consumption. 654 With the emergence of "Smart Grid" applications, the LoWPAN may also 655 have direct interactions with the Grid itself via the Internet to 656 report the amount of KWatts that could be load shed (Home to Grid) 657 and to receive dynamic load shedding information if/when required 658 (Grid to home): this application is also referred to as Demand- 659 Response application. Another service known as Demand Side 660 Management (DSM) could be provided by utilities to monitor and report 661 to the user its energy consumption with a fine granularity (on a per 662 device basis). Other inputs such as dynamic pricing can also be 663 received by the user from the utility that can then turn on and off 664 some appliances according to its local policy in order to reduce its 665 energy bill. 667 In terms of home safety and security, the LoWPAN is made of motion- 668 and audio-sensors, sensors at doors and windows, and video cameras to 669 which additional sensors can be added for safety (gas, water, CO, 670 Radon, smoke detection). The LoWPAN typically comprises a few dozen 671 nodes forming an ad-hoc network with multi-hop routing since the 672 nodes may not be in direct range. It is worth mentioning that the 673 number of devices tends to grow considering the number of new 674 applications for the home. In its most simple form, all nodes are 675 static and communicate with a central control module but more 676 sophisticated scenarios may also involve inter-device communication. 677 For example, a motion/presence sensor may send a multicast message to 678 a group of lights to be switched on, or a video camera will be 679 activated sending a video stream to a gateway that can be received on 680 a cell phone. 682 Ergonomics in Connected Homes is a key and the LoWPAN must be self- 683 managed and easy to install. Traffic patterns may greatly vary 684 depending on the applicability and so does the level of reliability 685 and QoS expected from the LoWPAN. Humidity sensing is typically not 686 critical and requires no immediate action whereas tele-assistance or 687 gas leak detection is critical and requires a high degree of 688 reliability. Furthermore, although some actions may not involve 689 critical data, still the response time and network delays must be on 690 the order of a few hundreds of milliseconds to preserve the user 691 experience (e.g. use a remote control to switch a light on). A 692 minority of nodes are mobile (with slow motion). With the emergence 693 of energy related applications it becomes crucial to preserve data 694 confidentiality. Connected Home LoWPAN usually do not require multi- 695 topology or QoS routing. Fairly simple QoS mechanisms are enough for 696 handling emergency data. It can be programmed to alarm by actuators 697 or to operate sprinklers. 699 Dominant parameters for home automation applications: 701 o Deployment: multi-hop topologies 703 o Mobility: some degree of mobility 705 o Network Size: medium number of nodes, potentially high density 707 o Power Source: mix of battery and mains-powered devices 709 o Security Level: authentication and encryption required 711 o Multi-hop communication: no requirement for multi-topology or QoS 712 routing 714 o Connectivity: intermittent (usage-dependent sleep modes) 716 o QoS: support of limited QoS for emergency data (alarm) 718 o Traffic Pattern: P2P (inter-device), P2MP and MP2P (polling) 720 3.3.2. 6LoWPAN Applicability 722 In the home automation use case, the network topology is made of a 723 mix of a battery operated and mains-powered nodes that both 724 communication with each other and a LBR provides connectivity to the 725 outside of world for control management (Figure 4). 727 In home network, installation and management must be extremely simple 728 for the user. Link local IPv6 addresses can be used by nodes with no 729 external communication and the LBR allocates routable addresses to 730 communicate with other LoWPAN nodes not reachable over a single radio 731 transmission. 733 n --- n 734 | | LBR: LoWPAN Border Router 735 Internet/ ------- LBR/LC -- n --- n ---- LC LC: Local controller node 736 Utility network | | /|\ n: LoWPAN Node 737 n ---- n n n n 739 (outside) (home automation system) 741 Figure 4: Home Automation scenario 743 In some scenarios, the traffic will be sent to a LC for processing 744 that may in turn decide of local actions (switch a light on, ...). 745 In other scenarios, all devices will send their data to the LCs that 746 may also act as the LBR for data processing and potential relay of 747 data to outside of the LoWPAN. It does not mean that every device 748 gets through the LC and LBR for communicating each other. For the 749 sake of illustration, some of the data may be processed to trigger 750 local action (e.g. switch off an appliance), simply store and sent 751 once enough data has been accumulated (e.g. energy consumption for 752 the past 6 hours for a set of appliances) or could trigger an alarm 753 immediately sent to a datacenter (e.g. gas leak detection). 755 Although in the majority of cases nodes within the LoWPAN will be in 756 direct range, some nodes will reach the LBR/LC with a 2-3 hops path 757 (with the emergence of several low-power media such as low-power PLC) 758 in which case LoWPAN routers will be deployed in the home to 759 interconnect the various IPv6 links. 761 The home LoWPAN must be able to provide extremely reliable 762 communication in support of some specific application (e.g. fire, gas 763 leak detection, health monitoring) whereas other application may not 764 be critical (e.g humidity monitoring). Such emergency data has the 765 same QoS issues with the event-driven data in the other applications, 766 and can be delivered by pre-defined paths through mains-powered node 767 without being stored in intermidiate nodes such as LCs. Similarly 768 some information may require the use of security mechanisms for 769 authentication, confidentiality. 771 3.4. Healthcare 773 LoWPANs are envisioned to be heavily used in healthcare environments. 774 They have a big potential to ease the deployment of new services by 775 getting rid of cumbersome wires and simplify patient care in 776 hospitals and for home care. In healthcare environments, delayed or 777 lost information may be a matter of life or death. 779 Various systems, ranging from simple wearable remote controls for 780 tele-assistance or intermediate systems with wearable sensor nodes 781 monitoring various metrics to more complex systems for studying life 782 dynamics, can be supported by LoWPANs. In the latter category, a 783 large amount of data from various LoWPAN nodes can be collected: 784 movement pattern observation, checks that medicaments have been 785 taken, object tracking, and more. An example of such a deployment is 786 described in [11] using the concept of Personal Networks. 788 3.4.1. A Use Case and its Requirements 790 Example: healthcare at home by tele-assistance 792 A senior citizen who lives alone wears one to few wearable LoWPAN 793 nodes to measure heartbeat, pulse rate, etc. Dozens of LoWPAN nodes 794 are densely installed at home for movement detection. A LBR at home 795 will send the sensed information to a connected healthcare center. 796 Portable base stations with LCDs may be used to check the data at 797 home, as well. The different roles of devices have different duty- 798 cycles, which affect node management. 800 Multipath interference may often occur due to the mobility of the 801 patients at home, where there are many walls and obstacles. Even 802 during sleeping, the change of the body position may affect the radio 803 propagation. 805 Data is gathered both periodically and event-driven. In this 806 application, event-driven data can be very time-critical. Thus, 807 real-time and reliable transmission must be guaranteed. 809 Privacy also becomes an serious issue in this case, as the sensed 810 data is very personal. A small set of secret keys can be shared 811 within the sensor nodes during bootstapping procedures in order to 812 build a secure link without using much of memory and energy. In 813 addition, different data will be provided to the hospital system from 814 what is given to a patient's family members. Role-based access 815 control is needed to support such services, thus support of 816 authorization and authentication is important. 818 Dominant parameters in healthcare applications: 820 o Deployment: pre-planned 822 o Mobility: moderate (patient's mobility) 824 o Network Size: small, high node density 826 o Power Source: hybrid 828 o Security Level: Data privacy and security must be provided. 829 Encryption is required. Role based access control is required to 830 be supported by light weight authentication mechanism 832 o Multi-hop communication: multi-hop for homecare devices, star 833 topology on patients body. Multipath interference due to walls 834 and obstacles at home must be considered. 836 o Connectivity: always on 838 o QoS: high level of reliability support (life and death 839 implication), role-based 841 o Traffic Pattern: MP2P/P2MP (data collection), P2P (local 842 diagnostic) 844 o Other issues: Plug-and-play configuration is required for mainly 845 non-technical end-users. Real-time data acquisition and analysis 846 are important. Efficient data management is needed for various 847 devices which have different duty-cycles, and for role-based data 848 control. Reliability and robustness of the network are also 849 essential. 851 3.4.2. 6LoWPAN Applicability 853 In this use case, the local network size is rather small (less than 854 10s of nodes). The home care system is statically configured with 855 multi-hop paths and the patient's body network can be built as a star 856 topology. The LBR at home is the sink node in the routing path from 857 sources on the patient's body. A plug-and-play configuration is 858 required. As the communication of the system is limited to a home 859 environment, both 16-bit and 64-bit can be used for IPv6 link-local 860 addresses [4]. An example topology is provided in Figure 5. 862 The patient's body network can be simply configured as a star 863 topology with a LC dealing with data aggregation and dynamic network 864 attachment when the patient moves around at home. As multipath 865 interference may often occur due to the patients' mobility at home, 866 the deployment of LoWPAN nodes and transmission paths should be well 867 considered. At home, some nodes can be installed with power- 868 affluence status, and those LoWPAN nodes can be used for relaying 869 points or data aggregation points. 871 The sensed information must be maintained with the identification of 872 the patient no matter if the patient visits the connected hospital or 873 stays at home. If the patient's LoWPAN uses globally unique IPv6 874 address, the address can be used for the identification. However, it 875 causes cost for privacy and security. The hospital LoWPAN where the 876 patient's information is transferring needs to operate additional 877 identification system together with strong authority and 878 authentication mechanism. The connection between the LBR at home and 879 the LBR at Hospital must be reliable and secure, as the data is 880 privacy-critical. To achieve this, additional policy for security is 881 recommended between the two LoWPAN. 883 n - n I: Internet 884 | | LBR: Edge Router 885 LBR --- I -- LBR - n - n - LC LC: Local controller node 886 /|\ | | /|\ n: LoWPAN Node 887 .. . .. n -- n n n n 889 (hospital) (home system) (patient) 891 Figure 5: A mobile healthcare scenario. 893 3.5. Vehicle Telematics 895 LoWPANs play an important role in intelligent transportation systems. 896 Incorporated in roads, vehicles, and traffic signals, they contribute 897 to the improvement of safety of transporting systems. Through 898 traffic or air-quality monitoring, they increase the possibilities in 899 terms of traffic flow optimization and help reducing road congestion. 901 3.5.1. A Use Case and its Requirements 903 Example: Telematics 905 As shown in Figure 6, LoWPAN Nodes are included in roads during their 906 construction for motion monitoring. When a car passes over these 907 nodes, the possibility is then given to track the trajectory and 908 velocity of cars for safety purposes. 910 The lifetime of the LoWPAN Nodes incorporated into roads is expected 911 to be as long as the life time of the roads (about 10 years). Multi- 912 hop communication is possible between LoWPAN Nodes, and the network 913 should be able to cope with the deterioration over time of the node 914 density due to power fails. Sink nodes placed at the side of road 915 are most likely mains-powered, LoWPAN Nodes in the roads run on 916 battery. Power saving schemes might intermittently disconnect the 917 nodes. A rough estimate of 4 nodes per square meter is needed. 918 Other applications may involve car-to-car communication for increased 919 road safety. 921 Dominant parameters in vehicle telematics applications: 923 o Deployment: pre-planned (road, vehicle) 925 o Mobility: none (road infrastructure), high (vehicle) 927 o Network Size: large (road infrastructure), small (vehicle) 929 o Power Source: hybrid 931 o Security Level: handling physical damage and link failure 933 o Multi-hop communication: multi-hop, especially ad-hoc 935 o Connectivity: intermittent 937 o Traffic Pattern: mostly Multi-Point-to-Point (MP2P), Point-to- 938 Multi-Point (P2MP) 940 3.5.2. 6LoWPAN Applicability 942 For this use case, the network topology includes fixed LBRs that are 943 mains-powered and have a connection to high speed networks (e.g., 944 Internet) in order to reach the transportation control center 945 (Figure 6). These LBRs may be logically combined with LC as a data 946 sink to gather sensed data from a number of LoWPAN Nodes inserted in 947 the tarmac of the road. In the road infrastructure, a LoWPAN with 948 one LBR forms a fixed network and the LoWPAN nodes are installed by 949 manual optimization of their location. 951 +-----+ 952 | LBR |--------------------------- LBR ... 953 +-----+ (at the road side) 954 -------|------------------------------ 955 | 956 n -- n --- n --- n +---|---+ LBR: LoWPAN Border Router 957 / \ | | n-n-n | n: LoWPAN Node 958 n n n +---|---+ 959 (cars) 960 -------------------------------------- 962 Figure 6: Telematics scenario. 964 Given the fact that nodes are incorporated in the road, tampering 965 with sensors is difficult for an adversary. However, the application 966 must be robust against possible attacks and node failures. Sensed 967 data should thus be used primarily for monitoring purposes, not to 968 instruct (and potentially mislead) traffic participants. 970 3.6. Agricultural Monitoring 972 Accurate temporal and spatial monitoring can significantly increase 973 agricultural productivity. Due to natural limitations, such as a 974 farmers' inability to check the crop at all times of day or 975 inadequate measurement tools, luck often plays a too large role in 976 the success of harvests. Using a network of strategically placed 977 sensors, indicators such as temperature, humidity, and soil condition 978 can be automatically monitored without labor intensive field 979 measurements. For example, sensor networks could provide precise 980 information about crops in real time, enabling businesses to reduce 981 water, energy, and pesticide usage and enhancing environment 982 protection. The sensing data can be used to find optimal 983 environments for the plants. In addition, the data on the planting 984 condition can be saved by sensor tags, which can be used in supply 985 chain management. 987 3.6.1. A Use Case and its Requirements 989 Example: Automated Vineyard 991 In a vineyard with medium to large geographical size, a number of 50 992 to 100 LC nodes are manually deployed in order to provide full signal 993 coverage over the study area. An additional number of 100 to 1000 994 leaf nodes with (possibly heterogeneous) specialized sensors (i.e., 995 humidity, temperature, soil condition, sunlight) are attached to the 996 LCs in local wireless star topologies, periodically reporting 997 measurements to the associated LCs. For example, in a 20-acre 998 vineyard with 8 parcels of land, 10 LoWPAN Nodes are placed within 999 each parcel to provide readings on temperature and soil moisture. 1000 The LoWPAN Nodes are able to support a multi-hop forwarding/routing 1001 scheme to enable data transmission to a sink node at the edge of the 1002 vineyard. Each of the 8 parcels contains one data aggregator to 1003 collect the sensed data. 1005 Localization is important for this type of LoWPAN where installed in 1006 a geographically large area, for pinning down where an event 1007 occurred, and for combining gathered data with their actual position. 1008 Using manual deployment, device addresses can be used for identifying 1009 the position and localization. For randomly deployed nodes, a 1010 localization algorithm needs to be applied. 1012 There might be various types of sensor devices deployed in a single 1013 LoWPAN, each providing raw data with different semantics. Thus, an 1014 additional method is required to correctly interpret sensor readings. 1015 Each data packet may include meta-information about its data, or a 1016 type of a sensor could be encoded in its address during address 1017 allocation. 1019 Dominant parameters in agricultural monitoring: 1021 o Deployment: pre-planned 1023 The nodes are installed outdoors or in a greenhouse with high 1024 exposure to water, soil, dust, in dynamic environments of moving 1025 people and machinery, with growing crop and foliage. LoWPAN nodes 1026 can be deployed in a pre-defined manner, considering the harsh 1027 environment. 1029 o Mobility: all static 1031 o Network Size: medium to large, low to medium density 1033 o Power Source: all nodes are battery-powered except the sink, or 1034 energy harvesting 1036 o Security Level: depending on business-purpose. Light-weight 1037 security or a simple shared key management can be used depending 1038 on the business purpose. 1040 o Multi-hop communication: mesh topology with local star 1041 connections. 1043 o Connectivity: intermittent (many sleeping nodes) 1045 o Traffic Pattern: Mainly MP2P/P2MP. P2P actuator triggering. 1047 o Other issues: Time synchronization among sensors are required, but 1048 the traffic interval may not be frequent (e.g. once in 30 minutes 1049 to 1 hour). 1051 3.6.2. 6LoWPAN Applicability 1053 The network configuration in this use case might, in the most simple 1054 case, look like illustrated in Figure 7. This static scenario 1055 consists of one or more fixed LBR that are mains-powered and have a 1056 high-bandwidth connection to a backbone link, which might be placed 1057 in a control center, or connect to the Internet. The LBRs are 1058 strategically located at the border of vineyard parcels, acting as 1059 data sinks. A number of LCs are placed along a row of plants with 1060 individual LoWPAN nodes spread around them. 1062 While the LBRs implement the IPv6 Neighbor Discovery protocol (RFC 1063 4861 [2]) to connect the outside of the LoWPAN, the LoWPAN Nodes 1064 operate a more energy-considering ND described in [7], which includes 1065 basic bootstrapping and address assignment. Each LBR can have 1066 predefined forward management information to a central data 1067 aggregation point, if necessary. 1069 LoWPAN nodes may send event-driven notifications when readings exceed 1070 certain thresholds, such as low soil humidity; which may 1071 automatically trigger a water sprinkler in the local environment. 1072 For increased energy efficiency, all LoWPAN Nodes are in periodic 1073 sleep state. However, the LCs need to be aware of sudden events from 1074 the leaf nodes. Their sleep periods should therefore be set to 1075 shorter intervals. Communication schedules must be set up between 1076 master and leaf nodes, and time synchronization is needed to account 1077 for clock drift. 1079 Also, the result of data collection may activate actuators. Context- 1080 awareness, node identification and data collection on the application 1081 level are necessary. 1083 I 1084 | 1085 | n n n n n n n n n I: Internet 1086 | \|/ \|/ \|/ LBR: LoWPAN Border Router 1087 LBR----LC------LC------LC LC: Local Controller node 1088 | /|\ /|\ /|\ n: LoWPAN node 1089 | n n n n n n n n n 1090 | 1091 LBR 1092 ... 1094 Figure 7: Automated vineyard scenario. 1096 4. Security Considerations 1098 Relevant security considerations are listed by application scenario 1099 in Section 3 and the security considerations in RFC 4919 [3] and RFC 1100 4944 [4] apply as well. 1102 The physical exposure of LoWPAN nodes (especially in outdoor 1103 networks) allows an adversary to capture, clone, tamper with, or even 1104 destroy these devices. Given the safety issues involved in some use 1105 cases, these threats place high demands for resiliency and 1106 survivability upon the LoWPAN. The generally wireless channels of 1107 LoWPANs are susceptible to several security threats. Without proper 1108 security measures, confidential information might be snooped by a 1109 "man in the middle". An attacker might also modify or introduce data 1110 packets into the network, for example to manipulate sensor readings 1111 or to take control over sensors and actuators. This specification 1112 expects that the link layer is sufficiently protected, either by 1113 means of physical or IP security for the backbone link or with MAC 1114 sublayer cryptography. However, link-layer encryption and 1115 authentication may not be sufficient to provide confidentiality, 1116 authentication, integrity, and freshness to both data and signaling 1117 packets. 1119 Due to their low-power nature, LoWPANs are especially vulnerable to 1120 denial-of-service (DoS) type attacks. Example DoS attacks include 1121 attempts to drain a node's battery by excessive querying or to 1122 introduce a high-power jamming signal that makes LoWPAN nodes 1123 dysfunctional. Security solutions must therefore be lightweight and 1124 support node authentication, so that message integrity can be 1125 guaranteed and misbehaving nodes can be denied participation in the 1126 network. A node must authenticate itself to trusted nodes before 1127 taking part in the LoWPAN. 1129 While IPsec is mandatory with IPv6 [4], considering the power 1130 constraints and limited processing capabilities of IEEE802.15.4 1131 devices, IPsec is computationally expensive; Internet key exchange 1132 (IKEv2) messaging described in [5] is not suited for LoWPANs as the 1133 amount of signaling in these networks should be minimized. Thus, 1134 LoWPANs may need to define their own keying management method that 1135 requires minimum overhead in terms of packet size and message 1136 exchange [12]. IPsec provides authentication and confidentiality 1137 between end nodes and across multiple LoWPAN links, and may be useful 1138 only when two nodes want to apply security to all exchanged messages. 1139 However, in many cases, the security may be requested at the 1140 application layer as needed, while other messages can flow in the 1141 network without security overhead. 1143 Security requirements may differ by use case. For example, 1144 industrial and structural monitoring applications are safety-critical 1145 and secure transmission must be guaranteed, so that only 1146 authenticated users are able to access and handle the data. In 1147 health care systems, data privacy is an important issue. Encryption 1148 is required, and role-based access control is needed for proper 1149 authentication. In home automation scenarios, critical applications 1150 such as door locks, require a high security and robustness against 1151 intrusion. On the other hand, a remote controlled light switch has 1152 no critical security threats. 1154 5. IANA Considerations 1156 This document contains no actions for IANA. 1158 6. Acknowledgements 1160 Thanks for David Cypher for giving more insight on the IEEE 802.15.4 1161 standard, and Irene Fernandez, Shoichi Sakane and Paul Chilton for 1162 review and valuable comments. 1164 7. References 1166 7.1. Normative References 1168 [1] Kent, S. and K. Seo, "Security Architecture for the Internet 1169 Protocol", RFC 4301, December 2005. 1171 [2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1172 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1173 September 2007. 1175 [3] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over 1176 Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, 1177 Assumptions, Problem Statement, and Goals", RFC 4919, 1178 August 2007. 1180 [4] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1181 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", 1182 RFC 4944, September 2007. 1184 [5] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key 1185 Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 1187 [6] IEEE Computer Society, "IEEE Std. 802.15.4-2006 (as amended)", 1188 2007. 1190 7.2. Informative References 1192 [7] Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 1193 Discovery Optimization for Low Power and Lossy Networks 1194 (6LoWPAN)", draft-ietf-6lowpan-nd-17 (work in progress), 1195 June 2011. 1197 [8] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams 1198 in Low Power and Lossy Networks (6LoWPAN)", 1199 draft-ietf-6lowpan-hc-15 (work in progress), February 2011. 1201 [9] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1202 Statement and Requirements for 6LoWPAN Routing", 1203 draft-ietf-6lowpan-routing-requirements-09 (work in progress), 1204 February 2011. 1206 [10] Roemer, K. and F. Mattern, "The Design Space of Wireless Sensor 1207 Networks", December 2004. 1209 [11] den Hartog, F., Schmidt, J., and A. de Vries, "On the Potential 1210 of Personal Networks for Hospitals", May 2006. 1212 [12] Dutertre, B., Cheung, S., and J. Levy, "Lightweight key 1213 management in wireless sensor networks by leveraging initial 1214 trust", April 2004. 1216 [13] Chen, D. and P. K. Varshney, "QoS Support in Wireless Sensor 1217 Networks: A survey", June 2004. 1219 Authors' Addresses 1221 Eunsook Kim 1222 ETRI 1223 161 Gajeong-dong 1224 Yuseong-gu 1225 Daejeon 305-700 1226 Korea 1228 Phone: +82-42-860-6124 1229 Email: eunah.ietf@gmail.com 1231 Dominik Kaspar 1232 Simula Research Laboratory 1233 Martin Linges v 17 1234 Snaroya 1367 1235 Norway 1237 Phone: +47-4748-9307 1238 Email: dokaspar.ietf@gmail.com 1240 Nicolas G. Chevrollier 1241 TNO 1242 Brassersplein 2 1243 P.O. Box 5050 1244 Delft 2600 1245 The Netherlands 1247 Phone: +31-15-285-7354 1248 Email: nicolas.chevrollier@tno.nl 1250 JP Vasseur 1251 Cisco Systems, Inc 1252 1414 Massachusetts Avenue 1253 Boxborough MA 01719 1254 USA 1256 Phone: 1257 Email: jpv@cisco.com