idnits 2.17.1 draft-ekim-6lowpan-scenarios-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 985. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 996. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1003. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1009. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2008) is 5765 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Example' on line 812 == Unused Reference: '1' is defined on line 907, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4919 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-05) exists of draft-chakrabarti-6lowpan-ipv6-nd-04 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 9 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 Expires: January 15, 2009 N. Chevrollier 5 TNO 6 D. Kaspar 7 Simula Research Laboratory 8 JP. Vasseur 9 Cisco Systems, Inc 10 July 14, 2008 12 Design and Application Spaces for 6LoWPANs 13 draft-ekim-6lowpan-scenarios-03 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 15, 2009. 40 Abstract 42 This document investigates potential application scenarios and use 43 cases for low-power wireless personal area networks (LoWPANs). 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Design Space . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 7 50 3.1. Industrial Monitoring . . . . . . . . . . . . . . . . . . 7 51 3.1.1. Application Features . . . . . . . . . . . . . . . . . 7 52 3.1.2. A Use Case and its Requirements . . . . . . . . . . . 9 53 3.1.3. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 10 54 3.2. Structural Monitoring . . . . . . . . . . . . . . . . . . 11 55 3.2.1. Application Features . . . . . . . . . . . . . . . . . 11 56 3.2.2. A Use Case and its Requirements . . . . . . . . . . . 12 57 3.2.3. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 13 58 3.3. Healthcare . . . . . . . . . . . . . . . . . . . . . . . . 14 59 3.3.1. Application Features . . . . . . . . . . . . . . . . . 14 60 3.3.2. A Use Case and its Requirements . . . . . . . . . . . 14 61 3.3.3. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 15 62 3.4. Connected Home . . . . . . . . . . . . . . . . . . . . . . 16 63 3.5. Vehicle Telematics . . . . . . . . . . . . . . . . . . . . 18 64 3.6. Agricultural Monitoring . . . . . . . . . . . . . . . . . 19 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 24 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 24 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 71 Intellectual Property and Copyright Statements . . . . . . . . . . 26 73 1. Introduction 75 LoWPANs are inexpensive, low-performance, wireless communication 76 networks, and are formed by devices complying with the IEEE 802.15.4 77 standard [3]. Their typical characteristics can be summarized as 78 follows: 80 o Low power: depending on country regulations and used frequency 81 band, the maximum transmit power levels can be up to 1000 mW [3]. 82 However, typical wireless radios for LoWPANs are battery-operated 83 and consume between 10 mW and 20 mW [4]. 85 o Short range: The Personal Operating Space (POS) defined by IEEE 86 802.15.4 implies a range of 10 meters. For real implementations, 87 the range of LoWPAN radios is typically measured in tens of 88 meters, but can go far beyond that in line-of-sight situations 89 [4]. 91 o Low bit rate: the IEEE 802.15.4 standard defines a maximum over- 92 the-air rate of 250 kb/s, as well as lower data rates of 40 kb/s 93 and 20 kb/s for each of the currently defined physical layers (2.4 94 GHz, 915 MHz and 868 MHz, respectively). 96 o Small memory capacity: common RAM sizes for LoWPAN devices consist 97 of a few kilobytes, such as 4 KB. 99 o Limited processing capability: current LoWPAN nodes usually have 100 8-bit processors with clock rates around 10 MHz. 102 The IEEE 802.15.4 standard distinguishes between two types of nodes, 103 reduced-function devices (RFDs) and full-function devices (FFDs). 104 Through their inability to transmit MAC layer beacons, RFDs can only 105 communicate with FFDs in a resulting "master/slave" star topology. 106 FFDs are able to communicate with peer FFDs and with RFDs in the 107 aforementioned relation. FFDs can therefore assume arbitrary network 108 topologies, such as multi-hop meshes. 110 LoWPANs do not necessarily comprise of sensor nodes only, but may 111 also consist of actuators. For instance, in an agricultural 112 environment, sensor nodes might detect low soil humidity and then 113 send commands to activate the sprinkler system. 115 A LoWPAN network can be seen as a network of small star-networks, 116 each consisting of a single FFD connected to zero or more RFDs. The 117 FFDs themselves act as packet forwarders or routers and connect the 118 entire LoWPAN in a multi-hop fashion. A LoWPAN domain is defined by 119 the number of devices controlled by the LoWPAN coordinator. Each 120 LoWPAN has a single coordinator, which must be of FFD type and it is 121 responsible for address allocation. A LoWPAN coordinator is 122 responsible for a single LoWPAN. 124 O X 125 | | C: Coordinator 126 C --- O --- O --- X O: FFD 127 / \ \ X: RFD 128 X X X 130 Figure 1: Example of a simple LoWPAN 132 Furthermore, communication to corresponding nodes outside of the 133 LoWPAN is becoming increasingly important. The distinction between 134 RFDs and FFDs and the introduction of additional functional elements, 135 such as gateways or border routers, increase the complexity on how 136 basic network functionality (e.g., routing and mobility) can be 137 designed for LoWPANs. 139 After describing the characteristics of a LoWPAN, this draft provides 140 a list of use cases and market domains that may benefit and motivate 141 the work currently done in the 6LoWPAN WG. 143 2. Design Space 145 Inspired by [5], this section describes the potential dimensions that 146 could be used to describe the design space of wireless sensor 147 networks in the context of the 6LoWPAN WG. The design space is 148 already limited by the unique characteristics of a 6LoWPAN (e.g., 149 low-power, short range, low-bit rate) as described in [2]. The 150 possible dimensions for scenario categorization used in this draft 151 are described as follows: 153 o Deployment: In a LoWPAN, sensor nodes can be scattered randomly or 154 they may be deployed in an organized manner. The deployment can 155 occur at once, or as an iterative process. The selected type of 156 deployment has an impact on node density and location. This 157 feature affects how to organize (manually or automatically) the 158 sensor network, and how to allocate addresses in the network. 160 o Mobility: Inherent to the wireless characteristics of LoWPANs, 161 sensor nodes could move or be moved around. Mobility can be an 162 induced factor (e.g., sensors in an automobile), hence not 163 predictable, or a controlled characteristic (e.g., pre-planned 164 movement in a supply chain). 166 o Network Size: The network size takes into account nodes that 167 provide the intended network capability (i.e., FFD). The number 168 of nodes involved in a LoWPAN could be small (10 nodes), moderate 169 (several 100s), or large (over a 1000). 171 o Power Source: Whether the sensor nodes are battery-powered or 172 mains-powered influences the network design. A hybrid solution is 173 also possible where only part of the network (e.g., FFDs) is 174 mains-powered. 176 o Security Level: sensor networks may carry sensitive information 177 and require high-level security support where the availability, 178 integrity, and confidentiality of the information are primordial. 179 This high level of security may be needed in case of structural 180 monitoring of key infrastructure or health monitoring of patients. 182 o Routing: The routing factor highlights the number of hops that has 183 to be traversed to reach the edge of the network or a destination 184 node within it. A single hop may be needed for simple star- 185 topologies or a multi-hop communication scheme for more elaborate 186 topologies, such as meshes or trees. From previous work on 187 LoWPANs from academia and industry, various routing mechanisms 188 have been introduced, such as data-centric, event-driven, address- 189 centric, localization-based, or geographical routing. We do not 190 use such a fine granularity in our draft but rather use topologies 191 and single/multi-hop communication when referring to the routing 192 categorization. 194 o Connectivity: Nodes within a LoWPAN are considered "always 195 connected" when there is a network connection between any two 196 given nodes. However, due to external factors (e.g., extreme 197 environment, mobility) or programmed disconnections (e.g., 198 sleeping mode), the network connectivity can be from 199 "intermittent" (i.e., regular disconnection) to "sporadic" (i.e., 200 almost always disconnected network). 202 o Quality of Service (QoS): for mission-critical applications, 203 support of QoS is mandatory in resource-constrained LoWPANs. 205 o Traffic Pattern: several traffic patterns may be used in sensor 206 networks. To name a few, Point-to-Multi-Point (P2MP), Multi- 207 Point-to-Point (MP2P) and Point-to-Point (P2P). 209 3. Application Scenarios 211 This section lists a fundamental set of LoWPAN application scenarios 212 in terms of system design. A complete list of practical use cases is 213 not the goal of this draft. The intention is to define a minimal set 214 of LoWPAN configurations to which any other scenario can be 215 abstracted to. Also, the characteristics of the scenarios described 216 in this section do not reflect the characteristics that every LoWPAN 217 must have in a particular environment (e.g., healthcare). 219 3.1. Industrial Monitoring 221 3.1.1. Application Features 223 Sensor network applications for industrial monitoring can be 224 associated with a broad range of methods to increase productivity, 225 energy efficiency, and safety of industrial operations in engineering 226 facilities and manufacturing plants. Many companies currently use 227 time-consuming and expensive manual monitoring to predict failures 228 and to schedule maintenance or replacements in order to avoid costly 229 manufacturing downtime. Deploying wireless sensor networks, which 230 can be installed inexpensively and provide more frequent and more 231 reliable data, can reduce equipment downtime and eliminate costly 232 manual equipment monitoring. Additionally, data analysis 233 functionality can be placed into the network, eliminating the need 234 for manual data transfer and analysis. 236 Industrial monitoring can be largely split into the following 237 application fields: 239 o Process Monitoring and Control: combining advanced energy metering 240 and sub-metering technologies with wireless sensor networking in 241 order to optimize factory operations, reduce peak demand, and 242 ultimately lower costs for energy. 244 Manufacturing plants and engineering facilities, such as product 245 assembly lines and engine rooms, can be drastically optimized 246 using wireless sensor technology in order to ensure product 247 quality, control energy consumption, avoid machine downtimes, and 248 increase operation safety. In industrial settings, sensors such 249 as vibration detectors can be used to continuously monitor 250 equipment and predict equipment failure and to detect the need for 251 maintenance, with far greater precision. This allows companies to 252 avoid costly equipment failures or shutdowns of production lines 253 and therefore increase their productivity. 255 Greater access to process parameters gives engineers better 256 visibility and ultimately better decision making power. Various 257 sensor measurements, such as gas pressure, the flow of liquids and 258 gases, room temperature and humidity, or tank charging levels may 259 be used together with controllers and actuators to improve a 260 plant's productivity in a continuous self-controlling loop, in 261 which instruments can be upgraded, calibrated, and reconfigured as 262 needed via the wireless channel. 264 A plant's monitoring boundary often does not cover the entire 265 facility but only those areas considered critical to the process. 266 Easy to install wireless connectivity extends this line to include 267 peripheral areas and process measurements that were previously 268 infeasible or impractical to reach with wired connections. 270 o Machine Surveillance: ensuring product quality and efficient and 271 safe equipment operation. Critical equipment parameters such as 272 vibration, temperature, and electrical signature are analyzed for 273 abnormalities that are suggestive of impending equipment failure 274 (see Section 3.2). 276 o Supply Chain Management and Asset Tracking: with the retail 277 industry being legally responsible for the quality of sold goods, 278 early detection of inadequate storage conditions with respect to 279 temperature will reduce risk and cost to remove products from the 280 sales channel. Examples include container shipping, product 281 identification, cargo monitoring, distribution and logistics. 283 Global supply chain and transportation applications increasingly 284 require real-time sensor and location information about their 285 supplies and assets. Wireless sensor networks meet these 286 requirements efficiently with low installation and management 287 costs, providing benefits such as reduced inventory, increased 288 asset utilization, and precise location tracking of containers, 289 goods, and mobile equipment. Clients can be provided with an 290 early warning of possible chain ruptures, for example by using 291 call centers or conveniently accessing comprehensive on-line 292 reports and data management systems. Such reports could include 293 monitoring of current states, the history of goods with critical 294 conservation conditions, and in critical areas the monitoring 295 status of oil containers, or verification of chemical gas 296 substance concentration. 298 For instance, thousands of cargo ships loaded with millions of 299 containers are sailing the oceans today. However, supply and 300 demand are not equally distributed around the world, which results 301 in high costs for shipping empty containers. Sophisticated IT 302 systems try to circumnavigate this problem and precision planning 303 is critical in any case: the customer always expects containers to 304 arrive just in time. Wireless sensor networks have a great 305 potential of making this growing market even more efficient by 306 allowing more reliable tracking and identification of containers, 307 and cargo monitoring for hazardous freight detection or 308 identification of illegal shipment. 310 Also, the process of loading and unloading can be implemented more 311 efficiently. For example, after a crane operator has lifted a 312 container from the deck, its content is identified and taken to 313 the corresponding warehouse -- on a driverless truck whose 314 movements are controlled at centimeter precision by transponders 315 under the asphalt. 317 o Storage Monitoring: sensory systems designed to prevent releases 318 of regulated substances to ground water, surface water and soil. 319 This application field may also include theft/tampering prevention 320 systems for storage facilities or other infrastructure, such as 321 pipelines. 323 3.1.2. A Use Case and its Requirements 325 Storage Monitoring (Hospital Storage Rooms) 327 In a hospital, maintenance of the right temperature in storage rooms 328 is very critical. Red blood cells need to be stored at 2 to 6 329 degrees Celsius, blood platelets at 20 to 24 C, and blood plasma 330 below -18 C. For anti-cancer medicine, maintaining a humidity of 45% 331 to 55% is required. Storage rooms have temperature sensors and 332 humidity sensors every 25m to 100m, based on the floor plan and the 333 location of shelves, as indoor obstacles distort the radio signals. 334 At each blood pack a sensor tag can be installed to track the 335 temperature during delivery. A sensor node is installed in each 336 container of a set of blood packs. In this case, highly dense 337 networks must be managed. 339 All nodes are statically deployed and manually configured with either 340 a single- or multi-hop connection to the coordinator. FFD and RFD 341 nodes are configured based on the topology. 343 All sensor nodes do not move unless the blood packs or a container of 344 block packs is moved. Moving nodes get connected by logical 345 attachment to a new coordinator. Placement of coordinators differs 346 between various service scenarios. 348 The network configuration and routing tables are not changed in the 349 storage room unless node failure occurs. 351 This type of application works based on both periodic and event- 352 driven notifications. Periodic data is used for monitoring the right 353 temperature and humidity in the storage rooms. The data over or 354 under a pre-defined threshold is meaningful to report. Blood cannot 355 be used if it is exposed to the wrong environment for about 30 356 minutes. Thus, event-driven data sensed on abnormal occurrences is 357 time-critical and requires secure and reliable transmission. 359 Due to the time-critical sensing data, reliable and secure data 360 transmission is highly important. 362 Dominant parameters in industrial monitoring scenarios: 364 o Deployment: pre-planned, manually attached 366 o Mobility: no (except for the asset tracking case) 368 o Network Size: medium to large size, high node density 370 o Power Source: all battery-operated 372 o Security Level: business-critical. Secure and reliable 373 transmission must be guaranteed. An extra key mechanism can be 374 used. 376 o Routing: single- to multi-hop. Routing tables are merely changed 377 after configuration, except in the asset tracking case. Node 378 failure or indoor obstacles will cause the changes. 380 o Connectivity: always on for crucial processes, otherwise 381 intermittent 383 o QoS: important for time-critical event-driven data 385 o Traffic Pattern: P2P (actuator control), MP2P (data collection) 387 o Other Issues: Sensor network management 389 3.1.3. 6LoWPAN Applicability 391 The network configuration of the above use-case can differ 392 substantially by system design. The simplest way is to build up a 393 star topology inside of the storage rooms, and connect the storage 394 rooms with one link. In this case the sensor nodes in the container 395 can be either FFDs or RFDs. 397 The PAN coordinators, C1, C2 and C3 are also 6LoWPAN routers. Each 398 sensor node builds up its link-local address and may get a prefix 399 from its default router by ND procedure (Mesh-under based ND 400 optimization is on-going work in the WG [7], and route-over based ND 401 optimization will be handled as well). Inside of the storage room, 402 the each node does not need to get a globally unique IPv6 address. 403 However, the container can be moved inside or outside of the 404 hospital, so that globally unique addresses may be needed depending 405 on the purpose of the system. Address auto-configuration is 406 explained in Chapter 6 of RFC 4944. When the system only uses link- 407 local scope, 16-bit addresses can be utilized, but 64-bit addresses 408 are recommended for globally unique addressing. 410 X X X X X X X X X 411 \ | / \ | / \ | / 412 C1 -------- C2 -------- C3 C: LoWPAN coordinator (FFD) 413 / | \ / | \ / | \ (Data Aggregator) 414 X X X X X X X X X X: FFD or RFD 416 Figure 2: Storage rooms with simple star topology 418 The data volume is usually not so big in this case, but it is 419 sensitive for delay. Data aggregators can be installed for each 420 storage room, or just one data aggregator can collect all data. To 421 make a light transmission, UDP (encapsulated in 6LoWPAN header or as 422 it is) will be chosen, but secure transmission and security mechanism 423 should be added. To increase security, MAC layer mechanisms or 424 additional security mechanisms can be used. 426 Because a failure of a sensor node can critically affect the storage 427 of the blood packs, network management is important here. SNMP-lite 428 should be provided for the management. 430 When the container is moved out from the storage room, and connected 431 to the hospital system (if the hospital buildings are fully or partly 432 covered with 6LoWPANs), it should rebind to a new parent and a 433 6LoWPAN router. ND will support this procedure. In case that it is 434 moved by an ambulance, it will be connected to the vehicle gateway or 435 router. 437 3.2. Structural Monitoring 439 3.2.1. Application Features 441 Intelligent monitoring in facility management can make safety checks 442 and periodic monitoring of the architecture status highly efficient. 443 Mains-powered nodes can be included in the design phase of a 444 construction or battery-equipped nodes can be added afterwards. 446 3.2.2. A Use Case and its Requirements 448 Bridge Safety Monitoring 450 A 1000m long bridge with 10 pillars is described. Each pillar and 451 the bridge body contain 5 sensors to measure the water level, and 5 452 vibration sensors are used to monitor its structural health. The 453 sensor nodes are deployed to have 100m line-of-sight distance from 454 each other. All nodes are placed statically and manually configured 455 with a single-hop connection to the coordinator. All sensor nodes do 456 not move while the service is provided. The network configuration 457 and routing tables are changed only in case of node failure. Except 458 from the pillars, there are no special obstacles of attenuation to 459 the sensor signals, but careful configuration is needed to prevent 460 signal interference between sensors. 462 The network configuration and routing tables are changed only in case 463 of node failure. On the top part of each pillar, an "infrastructure" 464 FFD sink node is placed to collect the sensed data. The FFD is the 465 LoWPAN coordinator of the sensors for each pillar which can be either 466 FFDs or RFDs. 468 A logical entity of data gathering can lie with each LoWPAN 469 coordinator. Communication schedules must be set up between leaf 470 nodes and their LoWPAN coordinator to efficiently gather the 471 different types of sensed data. Each data packet may include meta- 472 information about its data, or the type of sensors could be encoded 473 in its address during the address allocation. The data gathering 474 entity can be programmed to trigger actuators installed in the 475 infrastructure, when a certain threshold value has been reached. 476 This type of application works based on both periodic and event- 477 driven notifications. The data over or under a pre-defined threshold 478 is meaningful to report. The event-driven data sensed on abnormal 479 occurrences is time-critical and requires secure and reliable 480 transmission. For energy conservation, all sensors could have 481 periodic and long sleep modes but wake up on certain events. 483 The LoWPAN coordinators can play the role of a gateway, so that a 484 third party with internet access can check the status of the specific 485 pillar. Due to the contents of the data, only authenticated users 486 should be allowed to access the data. 488 This use case can be extended to medium or large size sensor networks 489 to monitor a building or for instance the safety status of highways 490 and tunnels. Larger networks of the same kind still have similar 491 characteristics such as static nodes, manual deployment, and mostly 492 star (or multi-level of star) topologies, and periodic and event- 493 driven real-time data gathering. 495 Dominant parameters in structural monitoring applications: 497 o Deployment: static, organized, pre-planned 499 o Mobility: none 501 o Network Size: small (dozens of nodes) to large, low density 503 o Power Source: mostly battery powered (except LoWPAN coordinators) 505 o Security Level: safety-critical. Secure transmission must be 506 guaranteed. Only authenticated users should be able to access and 507 handle the data. Lightweight key mechanisms can be used. 509 o Routing: star-topology (potentially hierarchical) In case of 510 hierarchical case, reorganization of routing tree may be the 511 issue. However, routing table may merely be changed after 512 configuration. Node failure or indoor obstacles will cause the 513 changes. 515 o Connectivity: always connected or intermittent by sleeping mode 516 scheduling. 518 o QoS: Emergency notification (fire, over-threshold vibrations, 519 water level, etc) is required to have priority of delivery and 520 must be transmitted in a highly reliable manner. 522 o Traffic Pattern: MP2P (data collection), P2P (localized querying) 524 o Other Issues: accurate sensing and reliable transmission are 525 important. In addition, sensor status reports may be needed to 526 maintain a reliable monitoring system. 528 X X X 529 \ | / 530 X --- O --- X 531 / | \ O: LoWPAN coordinator (FFD) 532 X X X X: FFD or RFD 534 Figure 3: A LoWPAN with a simple star topology. 536 3.2.3. 6LoWPAN Applicability 537 3.3. Healthcare 539 3.3.1. Application Features 541 LoWPANs are envisioned to be heavily used in healthcare environments. 542 They would ease the deployment of new services by getting rid of 543 cumbersome wires and ease the patient care and life in hospitals and 544 for home care. In this environment, delay or lost information may be 545 a matter of life or death. 547 Various systems ranging from simple wearable remote controls for 548 tele-assistance or intermediate systems with wearable sensors 549 monitoring various metrics to more complex systems for studying life 550 dynamics can be supported by the LoWPAN. In this latter category, a 551 large amount of data from various sensors can be collected: movement 552 pattern observation, checks that medicaments have been taken, object 553 tracking, and more. An example of such a deployment is described in 554 [6] using the concept of Personal Networks. 556 3.3.2. A Use Case and its Requirements 558 Healthcare at Home by Tele-Assistance 560 An old citizen who lives alone wears one to few wearable sensors to 561 measure heartbeat, pulse rate, etc. Dozens of sensor nodes are 562 densely installed at home for movement detection. A LoWPAN home 563 gateway will send the sensing data to the connected healthcare 564 center. Portable base stations with LCDs may be used to check the 565 data at home, as well. The different roles of devices have different 566 duty-cycles, which affect node management. 568 Multipath interference may often occur due to the patients' mobility 569 at home, where there are many walls and obstacles. Even during 570 sleeping, the change of the body position will affect the radio 571 propagation. 573 Data is gathered both periodically and event-driven. In this 574 application, event-driven data can be very time-critical. Thus, 575 real-time and reliable transmission must be guaranteed. 577 Privacy also becomes an issue in this case, as the sensing data is 578 very personal data. In addition, different data will be provided to 579 the hospital system than what is given to a patient's family members. 580 Role-based access control is needed to support such services, thus 581 support of authorization and authentication is important here. 583 Dominant parameters in healthcare applications: 585 o Deployment: pre-planned 587 o Mobility: moderate (patient's mobility) 589 o Network Size: small, high node density 591 o Power Source: hybrid 593 o Security Level: Data privacy and security must be provided. 594 Encryption is required. Role based access control is required to 595 be support by proper authentication mechanism 597 o Routing: multihop for homecare devices, star topology on patients 598 body. Multipath interference due to walls and obstacles at home 599 must be considered. 601 o Connectivity: always on 603 o QoS: high level of support (life and death implication), role- 604 based 606 o Traffic Pattern: MP2P/P2MP (data collection), P2P (local 607 diagnostic) 609 o Other issues: Plug-and-play configuration is required for mainly 610 non-technical end-users. Real-time data acquisition and analysis 611 are important. Efficient data management is needed for various 612 devices which have different duty-cycles, and for role-based data 613 control. Reliability and robustness of the network are also 614 essential. 616 3.3.3. 6LoWPAN Applicability 618 In this use-case, the network size is rather small (less than 10s of 619 nodes). The home system is static with multi-hop paths, and the 620 patient's body network can be built on single-hop. The home gateway 621 will be the sink node in the routing path. A 6LoWPAN router is 622 logically or physically combined with it. A plug-and-play 623 configuration is required. Each home system node will get a link- 624 local IPv6 address following the auto-configuration described in RFC 625 4944. As the communication of the system is limited to the home, 626 both 16-bit and 64-bit can be used to create their IPv6 link-local 627 addresses. 629 Multi-hop communication can be achieved by either mesh-under or 630 route-over routing mechanisms. In case the mesh-under mechanism is 631 provided, the 6LoWPAN router becomes the only router, and ND is done 632 as [7] describes. The mesh-under based ND is still on-going work, 633 and the routing mechanism is in study. When route-over is used, some 634 FFDs will play role in 6lowpan routers and the network will build up 635 one IPv6 link. IP-based routing is now chartered at the ROLL WG. 637 The patient's body network can be simply configured by a single-hop. 638 [7] is used in there, but RA may need to be optimized as it is sent 639 to the FFD (or in other name, coordinator) by unicast, and the 640 coordinator forward it to his neighbor nodes. 642 The mobility of the patient's body area network is caused by the 643 patient's movement within the home. If there are not many obstacles 644 to block or distort the signal, it may not need additional mobility 645 support. If not, additional mobility support must be provided. 646 Currently there is no mobility work is handled by the 6LoWPAN WG. 648 +-------+ +--------------+ +----------+ +----------+ 649 | Sinks | ---- | Home Gateway | ---- | Backbone | ---- | Hospital | 650 +-------+ +--------------+ +----------+ +----------+ 651 | 652 | ------------------------ 653 | | 654 O O -- O --- O --- X O: FFD 655 /|\ | |\ X: RFD (or FFD) 656 X X X X X X 658 (patient) (home system) 660 Figure 4: A mobile healthcare scenario. 662 3.4. Connected Home 664 The "Connected" Home or "Smart" home is with no doubt an area where 665 LoWPANs can be used to support an increasing number of services: 667 o Home safety/security 669 o Home Automation and Control 671 o Healthcare (see above section) 673 o Smart appliances and home entertainment systems 675 In home environments LoWPAN networks typically comprise a few dozen 676 and probably in the near future a few hundreds of nodes of various 677 nature: sensors, actuators and connected objects. 679 [Example]: Home Automation 681 In terms of home safety and security, the LoWPAN is made of motion, 682 audio, door/window sensors, video cameras to which additional sensors 683 can be added for security (gas, water, CO, Radon, smoke detection). 684 The LoWPAN typically comprises a few dozen of nodes forming a ad-hoc 685 network with multi-hop routing since the nodes may not be in direct 686 range. In its most simple form all nodes are static and communicate 687 with a central control module but more sophisticated scenarios may 688 also involve inter-device communication. For example, a motion/ 689 presence sensor may send a multicast message to a group of lights to 690 be switched on, a video camera will be activated sending a video 691 stream to a gateway that can be received on a cell phone. 693 The Home automation and control system LoWPAN offers a wide range of 694 services: local or remote access from the Internet (via a secured 695 gateway) to monitor the home (temperature, humidity, activation of 696 remote video surveillance, status of the doors (locked),...) but also 697 for home control (activate the air conditioning/heating, door locks, 698 sprinkler systems, ...). Fairly sophisticated systems can also 699 optimize the level of energy consumption thanks to a wide range of 700 input from various sensors connected to the LoWPAN: light sensors, 701 presence detection, temperature, ... in order to control electric 702 window shades, chillers, air flow control, air conditioning and 703 heating with the objective to optimize energy consumption. 705 Ergonomics in Connected Homes is key and the LoWPAN must be self- 706 managed and easy to install. Traffic patterns may greatly vary 707 depending on the applicability and so does the level of reliability 708 and QoS expected from the LoWPAN. Humidity sensing is typically not 709 critical and requires no immediate action whereas tele-assistance or 710 gas leak detection is critical and requires a high degree of 711 reliability. Furthermore, although some actions may not involve 712 critical data, still the response time and network delays must be on 713 the order of a few hundreds of milliseconds to preserve the user 714 experience (e.g. use a remote control to switch a light on). A 715 minority of nodes are mobile (with slow motion). Connected Home 716 LowPAN usually do not require multi-topology or QoS routing and 717 fairly simple QoS mechanisms must be supported by the LoWPAN (the 718 number of Class of Services is usually limited). 720 Dominant parameters for home automation applications: 722 o Deployment: multi-hop topologies 724 o Mobility: small degree of mobility 725 o Network Size: medium number of nodes, potentially high density 727 o Power Source: mix of battery and AC powered devices 729 o Security Level: authentication and encryption required 731 o Routing: no requirement for multi-topology or QoS routing 733 o Connectivity: intermittent (usage-dependent sleep modes) 735 o QoS: support of limited QoS (small number of Class of Service) 737 o Traffic Pattern: P2P (inter-device), P2MP and MP2P (polling) 739 3.5. Vehicle Telematics 741 LoWPANs play an important role in intelligent transportation systems. 742 Incorporated in roads and/or, they contribute to the improvement of 743 safety of transporting systems. Through traffic or air-quality 744 monitoring, they increase the possibilities in terms of traffic flow 745 optimization and help reducing road congestion. 747 [Example]: Telematics 749 Scattered sensors are included in roads during their construction for 750 motion monitoring. When a car passes over of these sensors, the 751 possibility is then given to track the trajectory and velocity of the 752 car for safety purposes. The lifetime of sensor devices incorporated 753 into roads is expected to be as long as the life time of the roads 754 (10 years). Multihop communication is possible between sensors, and 755 the network should be able to cope with the deterioration over time 756 of the node density due to power failure. Sinks placed at the road 757 side are mains-powered, sensor nodes in the roads run on battery. 758 Power savings schemes might intermittently disconnect sensors nodes. 759 A rough estimate of 4 sensors per square meter is needed. Other 760 applications may involve car-to-car communication for increased road 761 safety. 763 Dominant parameters in vehicle telematics applications: 765 o Deployment: scattered, pre-planned 767 o Mobility: high 769 o Network Size: large 770 o Power Source: mostly battery powered 772 o Security Level: low 774 o Routing: multi-hop 776 o Connectivity: intermittent 778 o QoS: support of limited QoS 780 o Traffic Pattern: mostly Multi-Point-to-Point (MP2P) 782 +-------+ 783 | Sinks | (at the road side) 784 +-------+ 785 -------|------------------------------ 786 | 787 O --- O --- O ----- O +---|---+ 788 / \ | | X-O-X | (cars) 789 O O --- O +---|---+ O: FFD 790 X: RFD 791 -------------------------------------- 793 Figure 5: Multi-hop LoWPAN combined with mobile star LoWPAN. 795 3.6. Agricultural Monitoring 797 Accurate temporal and spatial monitoring can significantly increase 798 agricultural productivity. Due to natural limitations, such as a 799 farmers' inability to check the crop at all times of day or 800 inadequate measurement tools, luck often plays a too large role in 801 the success of harvests. Using a network of strategically placed 802 sensors, indicators such as temperature, humidity, soil condition, 803 can be automatically monitored without labor intensive field 804 measurements. For example, sensor networks could provide precise 805 information about crops in real time, enabling businesses to reduce 806 water, energy, and pesticide usage and enhancing environment 807 protection. The sensing data can be used to find optimal 808 environments for the plants. In addition, the data on the planting 809 condition can be saved by sensor tags, which can be used in supply 810 chain management. 812 [Example]: Automated Vineyard 814 In a vineyard with medium to large geographical size, a number of 50 815 to 100 FFDs nodes are manually deployed in order to provide full 816 signal coverage over the study area. These FFD nodes support a 817 multi-hop routing scheme to enable data forwarding to a sink node at 818 the edge of the vineyard. An additional number of 100 to 1000 819 (possibly different) specialized RFD sensors (i.e., humidity, 820 temperature, soil condition, sunlight) are attached to the FFDs in 821 local wireless star topologies, periodically reporting measurements 822 to the associated master FFD. For example, in a 20-acres vineyard 823 with 8 parcels of land, 10 sensors are placed within each parcel to 824 provide readings on temperature and soil moisture. Each of the 8 825 parcels contains 1 FFD sink to collect the sensor data. 10 826 intermediate FFD "routers" are used to connect the sinks to the main 827 gateway. 829 Sensor nodes may send event-driven notifications when readings exceed 830 certain thresholds, such as low soil humidity; which may 831 automatically trigger a water sprinkler in the local environment. 832 For increased energy efficiency, all sensors are in periodic sleep 833 state. However, FDD nodes need to be aware of sudden events from 834 RFDs. Their sleep periods should therefore be set to shorter 835 intervals. Communication schedules must be set up between RFDs and 836 FFDs and global time synchronization is needed to account for clock 837 drift. 839 Sensor localization is important for geographical routing, for 840 pinning down where an event occurred, and for combining gathered data 841 with their actual position. Using manual deployment, device 842 addresses can be used. For randomly deployed nodes, a localization 843 algorithm needs to be applied. 845 There might be various types of sensor devices deployed in a single 846 LoWPAN, each providing raw data with different semantics. Thus, an 847 additional method is required to correctly interpret sensor readings. 848 Each data packet may include meta-information about its data, or a 849 type of a sensor could be encoded in its address during address 850 allocation. 852 Dominant parameters in agricultural monitoring: 854 o Deployment: pre-planned 856 The sensor nodes are installed outdoors or in a greenhouse with 857 high exposure to water, soil, dust, in dynamic environments of 858 moving people and machinery, with growing crop and foliage. 859 Sensor nodes can be deployed in a pre-defined manner, considering 860 the harsh environment. 862 o Mobility: all static 863 o Network Size: medium to large, low to medium density 865 o Power Source: all nodes are battery-powered, except the sink 867 o Security Level: business-critical. Light-weight security or a 868 global key management can be used depending on the business 869 purpose. 871 o Routing: mesh topology with local star connections. Routing table 872 is merely changed after configuration. Node failure or indoor 873 obstacles will cause the changes. 875 o Connectivity: intermittent (many sleeping nodes) 877 o QoS: not critical 879 o Traffic Pattern: Mainly MP2P/P2MP. P2P for Gateway communication 880 or actuator triggering. 882 o Other issues: Time synchronization among sensors are required, but 883 the traffic interval may not be frequent (e.g. once in 30 minutes 884 to 1 hour). 886 X X X X X X X X X X X X 887 +---------+ \|/ \|/ \|/ \|/ 888 | Gateway | ---- O ---- O ---- O ---- O 889 +---------+ /|\ /|\ /|\ /|\ X: RFD 890 X X X X X X X X X X X X O: FFD 892 Figure 6: An aligned multi-hop LoWPAN. 894 4. Security Considerations 896 To be defined. 898 5. Acknowledgements 900 Thanks to David Cypher for giving more insight on the IEEE 802.15.4 901 standard and to Irene Fernandez for her review and valuable comments. 903 6. References 905 6.1. Normative References 907 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 908 Levels", BCP 14, RFC 2119, March 1997. 910 [2] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over 911 Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, 912 Assumptions, Problem Statement, and Goals", RFC 4919, 913 August 2007. 915 [3] IEEE Computer Society, "IEEE Std. 802.15.4-2006", October 2003. 917 6.2. Informative References 919 [4] Bulusu, N. and S. Jha, "Wireless Sensor Networks", July 2005. 921 [5] Roemer, K. and F. Mattern, "The Design Space of Wireless Sensor 922 Networks", December 2004. 924 [6] den Hartog, F., Schmidt, J., and A. de Vries, "On the Potential 925 of Personal Networks for Hospitals", May 2006. 927 [7] Chakrabarti, S. and E. Nordmark, "LoWPAN Neighbor Discovery 928 Extensions, draft-chakrabarti-6lowpan-ipv6-nd-04 (work in 929 progress)", November 2007. 931 Authors' Addresses 933 Eunsook Kim 934 ETRI 935 161 Gajeong-dong 936 Yuseong-gu 937 Daejeon 305-700 938 Korea 940 Phone: +82-42-860-6124 941 Email: eunah.ietf@gmail.com 943 Nicolas G. Chevrollier 944 TNO 945 Brassersplein 2 946 P.O. Box 5050 947 Delft 2600 948 The Netherlands 950 Phone: +31-15-285-7354 951 Email: nicolas.chevrollier@tno.nl 953 Dominik Kaspar 954 Simula Research Laboratory 955 Martin Linges v 17 956 Snaroya 1367 957 Norway 959 Phone: +47-4748-9307 960 Email: dokaspar.ietf@gmail.com 962 JP Vasseur 963 Cisco Systems, Inc 964 1414 Massachusetts Avenue 965 Boxborough MA 01719 966 USA 968 Phone: 969 Email: jpv@cisco.com 971 Full Copyright Statement 973 Copyright (C) The IETF Trust (2008). 975 This document is subject to the rights, licenses and restrictions 976 contained in BCP 78, and except as set forth therein, the authors 977 retain all their rights. 979 This document and the information contained herein are provided on an 980 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 981 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 982 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 983 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 984 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 985 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 987 Intellectual Property 989 The IETF takes no position regarding the validity or scope of any 990 Intellectual Property Rights or other rights that might be claimed to 991 pertain to the implementation or use of the technology described in 992 this document or the extent to which any license under such rights 993 might or might not be available; nor does it represent that it has 994 made any independent effort to identify any such rights. Information 995 on the procedures with respect to rights in RFC documents can be 996 found in BCP 78 and BCP 79. 998 Copies of IPR disclosures made to the IETF Secretariat and any 999 assurances of licenses to be made available, or the result of an 1000 attempt made to obtain a general license or permission for the use of 1001 such proprietary rights by implementers or users of this 1002 specification can be obtained from the IETF on-line IPR repository at 1003 http://www.ietf.org/ipr. 1005 The IETF invites any interested party to bring to its attention any 1006 copyrights, patents or patent applications, or other proprietary 1007 rights that may cover technology that may be required to implement 1008 this standard. Please address the information to the IETF at 1009 ietf-ipr@ietf.org.