RFC 6568
Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
RFC 6568 ✨ Part 1 of 6 🦋
Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) 🎀
Title block, the tea 🍓 Okay bestie, this RFC is by E. Kim (ETRI), D. Kaspar (Simula Research Laboratory), and JP. Vasseur (Cisco Systems, Inc.). It's an Informational doc, so it's published for info and is not a standards-track spec 💅 It came out in April 2012, and its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's standing all on its own 👑
Abstract
okay so this doc looks at what LoWPANs (low-power wireless personal area networks) could actually be used for 🧚 It lays out dimensions of the design space for LoWPAN applications, and it gives a list of use cases and market domains that could benefit from, and motivate, the work the 6LoWPAN Working Group is doing right now ✨ A complete list of practical use cases is explicitly not the goal here, so don't come for it 🙈
Status of This Memo
ngl this part is kinda legal-coded, but here's the tea 💖 This document is not an Internet Standards Track specification. It's published for informational purposes only 🌸
It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and it was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the deets 🦋
For the current status of this doc, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6568 💜
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🔥
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this doc 🙈 Any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💅
Heads up: this document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exception is formatting it for publication as an RFC, or translating it into languages other than English. 🫶
Table of Contents
1. Introduction ....................................................3
1.1. Terminology ................................................5
1.2. Premise of Network Configuration ...........................5
2. Design Space ....................................................6
3. Application Scenarios ...........................................8
3.1. Industrial Monitoring ......................................8
3.1.1. A Use Case and Its Requirements .....................9
3.1.2. 6LoWPAN Applicability ..............................10
3.2. Structural Monitoring .....................................12
3.2.1. A Use Case and Its Requirements ....................12
3.2.2. 6LoWPAN Applicability ..............................14
3.3. Connected Home ............................................15
3.3.1. A Use Case and Its Requirements ....................15
3.3.2. 6LoWPAN Applicability ..............................17
3.4. Healthcare ................................................18
3.4.1. A Use Case and Its Requirements ....................18
3.4.2. 6LoWPAN Applicability ..............................19
3.5. Vehicle Telematics ........................................20
3.5.1. A Use Case and Its Requirements ....................21
3.5.2. 6LoWPAN Applicability ..............................21
3.6. Agricultural Monitoring ...................................22
3.6.1. A Use Case and Its Requirements ....................22
3.6.2. 6LoWPAN Applicability ..............................24
4. Security Considerations ........................................25
5. Acknowledgements ...............................................26
6. References .....................................................26
6.1. Normative References ......................................26
6.2. Informative References ....................................271. Introduction ✨
okay so Low-power and lossy networks (LLNs) is the umbrella term for networks built from super constrained nodes (limited CPU, memory, and power) linked together by a bunch of "lossy" links, like low-power radio links or Power-Line Communication (PLC) 🧚 They're low speed, low performance, low cost, and have unstable connectivity, so they're kinda chaotic, but iconic in their own way 💀
A LoWPAN is a specific kind of LLN, made of devices that follow the IEEE 802.15.4 standard [5] 🌈 Their typical characteristics go like this:
- Limited Processing Capability: The smallest common LoWPAN nodes have 8-bit processors with clock rates around 10 MHz. Other models have 16-bit and 32-bit cores (usually ARM7), running at frequencies on the order of tens of MHz 🔥
- Small Memory Capacity: The smallest common LoWPAN nodes have a few kilobytes of RAM and a few dozen kilobytes of ROM/flash memory. Node memory keeps growing (IMote, for example, has 64 KB SRAM and 512 KB Flash memory), but small memory capacity for LoWPAN nodes is still a challenge 💜
- Low Power: Wireless radios for LoWPANs are normally battery-operated 🔋 Their radio frequency (RF) transceivers often draw about 10 to 30 mA, depending on the transmission power level. To reach common indoor ranges of up to 30 meters and outdoor ranges of 100 meters, the transmission power is set around 0 to 3 dBm. Depending on the processor type, the CPU itself adds battery current consumption, commonly on the order of tens of milliamperes. The good news? CPU power consumption can often be cut by a thousandfold when it switches to sleep mode 😭
- Short Range: The Personal Operating Space (POS) defined by IEEE 802.15.4 implies a range of 10 meters. For real implementations, LoWPAN radio range is typically measured in tens of meters, but it can reach over 100 meters in line-of-sight situations 🦋
- Low Bit Rate: The IEEE 802.15.4 standard defines a maximum over-the-air rate of 250 kbit/s, which is the most commonly used rate in current deployments. Three lower data rates of 20, 40, and 100 kbit/s are also defined 🍓
A LoWPAN isn't necessarily just sensor nodes, either. It can also have actuators 🧚 For example, in an agricultural environment, sensor nodes might detect low soil humidity and then send commands to activate the sprinkler system 🌸
After defining common terminology in Section 1.1 and describing LoWPAN characteristics in Section 2, this document gives a list of use cases and market domains that may benefit from, and motivate, the work currently happening in the 6LoWPAN Working Group 💅
1.1. Terminology
Readers are expected to be familiar with all the terms and concepts in "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [2], and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [3]. So go read those first, bestie 📚
Readers would also benefit from reading 6LoWPAN Neighbor Discovery (ND) [6], 6LoWPAN header compression [7], and 6LoWPAN routing requirements [8] for the details of 6LoWPAN work 🫶
This document defines the following terms:
LC (Local Controller) A logical functional entity that has the special job of coordinating and controlling its child nodes for local data aggregation, status management of local nodes, and so on. There may be multiple instances of local controller nodes in a LoWPAN 👑
LBR (LoWPAN Border Router) A border router located at the junction of separate LoWPANs, or between a LoWPAN and another IP network. There may be one or more LBRs at the LoWPAN boundary. An LBR is the responsible authority for IPv6 Prefix propagation for the LoWPAN it serves. An isolated LoWPAN also contains an LBR in the network, and the LBR provides the prefix(es) for that isolated network 🧚
1.2. Premise of Network Configuration
The IEEE 802.15.4 standard splits nodes into two types: reduced-function devices (RFDs) and full-function devices (FFDs) 🌈 This distinction is based on some Medium Access Control (MAC) features that aren't always in use, so this document doesn't use the distinction 🙈
6LoWPANs can be deployed using either route-over or mesh-under architectures. Since the choice between route-over and mesh-under doesn't affect how well 6LoWPAN technologies fit the use cases described in this document, we'll use the term "6LoWPAN" to mean either a route-over or a mesh-under network 💖
Talking to corresponding nodes outside the LoWPAN is getting more and more important for convenient data collection and remote control 🔥 The intermediate LoWPAN nodes act as packet forwarders at the link layer or as LoWPAN routers, connecting the whole LoWPAN in a multi-hop fashion. LBRs are used to interconnect a LoWPAN with other networks, or to form an extended LoWPAN by connecting multiple LoWPANs 🦋
Before LoWPAN nodes get their IPv6 addresses and the network gets configured, each LoWPAN runs a link-layer configuration, either through the mechanisms specified in [6] or by using a coordinator that's responsible for link-layer short address allocation. The link-layer coordinator functionality is out of scope for this document, though 💅 Details of address allocation in 6LoWPAN ND are in [6] 🫶
A LoWPAN can be configured as mesh-under or route-over (see Terminology in [6]). In a route-over configuration, multi-hop transmission is carried out by LoWPAN routers using IP routing. In a mesh-under configuration, the link-local scope reaches the boundaries of the LoWPAN, and multi-hop transmission is achieved by forwarding data at the link layer or in a 6LoWPAN adaptation layer. More info on mesh-under and route-over is in [6] and [8] 🌸
Part 1 done!! Part 2 is coming next, so stay tuned, bestie 🧚💜
2. Design Space ✨
okay bestie, this section is where we list the dimensions (basically the axes) used to describe the design space of wireless sensor networks in the context of the 6LoWPAN Working Group 💖 It's inspired by [9], and the design space is already kinda limited by the unique LoWPAN vibes (low power, short range, low bit rate) as described in [2] 🦋 Here are the possible dimensions for scenario categorization used in this doc:
- Deployment: LoWPAN nodes can be scattered randomly, or they can be deployed in an organized manner in a LoWPAN 🌸 The deployment can happen all at once, or as an iterative process. The type of deployment you pick has an impact on node density and location. This feature affects how to organize the LoWPAN (manually or automatically) and how to allocate addresses in the network, so it's a big deal 💅
- Network Size: The network size takes into account the nodes that provide the intended network capability. The number of nodes in a LoWPAN could be small (ten), moderate (several hundred), or large (over a thousand) 🧚
- Power Source: Whether the nodes are battery-powered or mains-powered influences the network design, and it's giving main character energy 🔋 The power may also be harvested from solar cells or other sources of energy. Hybrid solutions are possible where only part of the network is mains-powered ✨
- Connectivity: Nodes within a LoWPAN are considered "always connected" when there is a network connection between any two given nodes 💜 However, due to external factors (e.g., extreme environment, mobility) or programmed disconnections (e.g., sleeping mode), network connectivity can range from "intermittent" (i.e., regular disconnections) to "sporadic" (i.e., almost always disconnected) 🥺 Differences in L2 duty-cycling settings may also impact connectivity due to highly varying bit rates.
- Multi-Hop Communication: This factor highlights the number of hops that have to be traversed to reach the edge of the network or a destination node within it 🦋 A single hop may be sufficient for simple star topologies, but a multi-hop communication scheme is required for more elaborate topologies, such as meshes or trees. Previous work on LoWPANs by academia and industry introduced various routing mechanisms, such as data-centric, event-driven, address-centric, localization-based, geographical routing, etc. This document does not make use of such a fine granularity but rather uses topologies and single/ multi-hop communication 🗺️
- Traffic Pattern: Several traffic patterns may be used in LoWPANs, like Point-to-Multipoint (P2MP), Multipoint-to-Point (MP2P), and Point-to-Point (P2P), to name a few 🌈
- Security Level: LoWPANs may carry sensitive information and require high-level security support, where the availability, integrity, and confidentiality of the information are crucial 🔐 (this part is serious, no cap)
- Mobility: Inherent to the wireless characteristics of LoWPANs, nodes could move or be moved around 🚗 Mobility can be an induced factor (e.g., sensors in an automobile), and hence not predictable, or a controlled characteristic (e.g., pre-planned movement in a supply chain) 📦
- Quality of Service (QoS): QoS issues in LoWPANs may be very different from traditional end-to-end QoS, because in LoWPAN applications one end is not a single sensor node but often a group of sensor nodes 🫶 Parameters for QoS should consider collective data for latency, packet loss, data throughput, etc. QoS requirements can also differ based on the data delivery model, such as event-driven, query-driven, continuous real-time, or continuous non-real-time. These delivery models usually coexist in LoWPAN applications 🌀 QoS issues in LoWPANs are more likely related to corresponding application-specific data delivery requirements within resource-constrained LoWPANs.
3. Application Scenarios 🎀
this section lists a fundamental set of LoWPAN application scenarios in terms of system design 💖 A complete list of practical use cases is not the goal of this document, so don't expect every single one 🙈
3.1. Industrial Monitoring 🏭
LoWPAN applications for industrial monitoring can be linked to a broad range of methods that boost productivity, energy efficiency, and safety of industrial operations in engineering facilities and manufacturing plants ✨ Lots of companies currently use time-consuming and expensive manual monitoring to predict failures and schedule maintenance or replacements, all to avoid costly manufacturing downtime 😩 LoWPANs can be inexpensively installed to provide more frequent and more reliable data. Deploying them can reduce equipment downtime and eliminate manual equipment monitoring that is costly to perform. Plus, data analysis functionality can be placed into the network, so there's no need for manual data transfer and analysis 🧠
Industrial monitoring can be largely split into the following application fields:
- Process Monitoring and Control: This application field combines advanced energy metering and sub-metering technologies with wireless sensor networking to optimize factory operations, reduce peak demand, ultimately lower energy costs, avoid machine downtimes, and increase operation safety ⚡
A plant's monitoring boundary often doesn't cover the entire facility, only the areas considered critical to the process. Wireless connectivity that is easy to install extends that line to include peripheral areas and process measurements that were previously infeasible or impractical to reach with wired connections 🌿
- Machine Surveillance: This application field ensures product quality and efficient and safe equipment operation 🔧 Critical equipment parameters such as vibration, temperature, and electrical signature are analyzed for abnormalities that suggest impending equipment failure 🚨
- Supply Chain Management and Asset Tracking: The retail industry is legally responsible for the quality of the goods it sells, so early detection of inadequate storage conditions with respect to temperature will reduce the risk and cost of removing products from the sales channel 📦 Examples include container shipping, product identification, cargo monitoring, distribution, and logistics 🚢
- Storage Monitoring: This application field includes sensor systems designed to prevent releases of regulated substances into ground water, surface water, and soil 🌍 It may also include theft/tampering prevention systems for storage facilities or other infrastructure, such as pipelines 🛢️
3.1.1. A Use Case and Its Requirements 🩸
Example: Hospital Storage Rooms 🏥
In a hospital, keeping the right temperature in storage rooms is super critical 🌡️ Red blood cells need to be stored at 2 to 6 degrees Celsius, blood platelets at 20 to 24 degrees C, and blood plasma below -18 degrees C 🧊 For anti-cancer medicine, a humidity of 45% to 55% is required 💊 Storage rooms have temperature sensors and humidity sensors every 25 to 100 m, based on the floor plan and the location of shelves, because indoor obstacles distort the radio signals 📡 At each blood pack, a sensor tag can be installed to track the temperature during delivery. A LoWPAN node is installed in each container of a set of blood packs. In this case, highly dense networks must be managed 🫧
All nodes are statically deployed and manually configured with either a single- or multi-hop connection. Different types of LoWPAN nodes are configured based on the service and network requirements. In particular, LCs play a role in aggregating the sensed data from blood packs 🧩 In the extended networks, more than one LoWPAN LC can be installed in a storage room. If the sensed data from an individual node is urgent event-driven data, such as an outrange of temperature or humidity, it will not be accumulated (and further delayed) by the LCs but will be immediately relayed 🚀
All LoWPAN nodes do not move unless the blood packs or a container of blood packs is moved 🧘 Moving nodes get connected by logical attachment to a new LoWPAN. When containers of blood packs are transferred to another place in the hospital or by ambulance, the LoWPAN nodes on the containers associate with a new LoWPAN 🚑
This type of application works based on both periodic and event-driven notifications 🔔 Periodic data is used for monitoring temperature and humidity in the storage rooms. Data over or under a predefined threshold is meaningful to report. Blood cannot be used if it is exposed to the wrong environment for about 30 minutes, so event-driven data sensed on abnormal occurrences is time-critical and requires secure and reliable transmission 😱
LoWPANs must be provided with low installation and management costs 💸 For transporting blood containers, precise location tracking of containers is important 📍 The hospital network manager or staff can be given an early warning of possible chain ruptures, for example by conveniently accessing comprehensive online reports and data management systems 💻
Dominant parameters in industrial monitoring scenarios:
- Deployment: Pre-planned, manually attached.
- Network Size: Medium to large size, high node density.
- Power Source: Battery-operated most of the time.
- Connectivity: Always on for crucial processes.
- Multi-Hop Communication: Multi-hop networking.
- Traffic Pattern: P2P (actuator control), MP2P (data collection).
- Security Level: Business-critical. Secure transmission must be guaranteed 🔒
- Mobility: None (except for asset tracking).
- QoS: Important for time-critical event-driven data ⏰
- Other Issues: Sensor network management, location tracking, real-time early warning 🚨
3.1.2. 6LoWPAN Applicability ✨
okay so the network setup for this use case can look super different depending on how you design it 🧚 the simplest option is a star topology inside each storage room (see Figure 1). depending on the room's layout and size, you can switch to a mesh instead (Figure 2) 🕸️
LBR
| LBR: LoWPAN Border Router
LC----------LC----------LC LC: Local Controller node
/ | \ / | \ / | \ (Data Aggregator)
n n n n n n n n n n: LoWPAN node
Figure 1: Storage Rooms with a Simple Star Topology +------------+-----------+
| | | LBR: LoWPAN Border Router
LBR LBR LBR (LC) LC: Local Controller node
| | | (Data Aggregator)
LC - n LC - n n n: LoWPAN node
/ | | | | / \
n n - LC n - n - n n - n
| | \ | |\
n n n - n n n n
Figure 2: Storage Rooms with a Mesh Topologyeach LoWPAN node can reach the LBR through a predefined routing/forwarding mechanism 🦋 every node sets up its own link-local address and gets a prefix from its LBR using a 6LoWPAN ND procedure [6]. and the LoWPAN nodes need to build a multi-hop connection so they can reach the LCs and the LBR 🌈
secure data transmission and authentication are a BIG deal in a hospital 😭 we don't want personal info getting grabbed by some random adversary. confidential data has to be encrypted not just while it's moving, but also when it's sitting on the nodes, because nodes can potentially get stolen 💀
the data volume usually isn't huge here, but it's super sensitive to delay ⏰ data aggregators can go in each storage room, or one data aggregator can collect everything. UDP is likely the pick to keep things light 🪶 but a secure transmission and security mechanism has to be added on top. to level up security, link-layer mechanisms and/or additional security mechanisms should be used 🔐
network management is a must 💜 because if one LoWPAN node fails, it can seriously mess with the storage of the blood packs 🩸 so a lightweight management mechanism must be provided for this.
the service quality here is all about handling event-driven data that's delay intolerant and mission critical 🚨 wrong humidity and wrong temperature need to be detected as fast and reliably as possible. it's important to use resources efficiently for this kind of data while keeping energy usage minimal 🔋 energy-aware QoS support in wireless sensor networks is a challenging issue [12] (literally a whole research topic, bestie). one idea is appropriate data aggregation to minimize delay and maximize delivery accuracy by using power-affluent nodes, and it can also be aided by middleware or other types of network elements 🧠
when a container gets moved out of the storage room and connected to another hospital system (if the buildings are fully or partly covered with LoWPANs), a mechanism to rebind to a new parent node and a new LoWPAN must be supported 🔁 if an ambulance takes it away, it'll connect to an LBR in the vehicle 🚑 this kind of mobility is supported by the 6LoWPAN ND and routing mechanism, so it's already got your back ✨
last but not least, LoWPANs must be provided with low installation and management costs 💰 that means reduced inventory and precise location tracking of containers and mobile equipment (like beds moved around the hospital, or ambulances) 🛏️
3.2. Structural Monitoring 🌉
ok this one is giving infrastructure main character 🏗️ intelligent monitoring in facility management can make safety checks and periodic monitoring of the building's status super efficient. mains-powered nodes can be included in the design phase of construction, or battery-equipped nodes can be added later on 🔌🔋 all nodes are static and manually deployed. some data isn't critical for security protection (like periodic or query-driven notifications of normal room temperature), but event-driven emergency data (like a fire alarm) must be handled in a very critical manner 🔥
3.2.1. A Use Case and Its Requirements 🌁
Example: Bridge Safety Monitoring
okay picture this 👀 a 1000-m-long concrete bridge with 10 pillars. each pillar and the bridge body have 5 sensors measuring the water level, and 5 vibration sensors monitoring the structural health 🌊 the LoWPAN nodes are deployed so they're 100-m line-of-sight distance from each other. all the nodes are placed statically and manually configured with a single-hop connection to the local coordinator 📍 every LoWPAN node stays immobile while the service is running. besides the pillars there are no special obstacles blocking node signals, but you do need careful configuration to stop signal interference between LoWPAN nodes 📡
the physical network topology changes if a node fails 💔 on the top part of each pillar, a sink node gets placed to collect the sensed data. the sink nodes of each pillar become the data-gathering points for the LoWPAN hosts at that pillar, and they act as local coordinators 👑
this use case can be extended to medium or large sensor networks to monitor a building or, for instance, the safety status of highways and tunnels 🛣️ bigger networks of the same kind still have similar vibes, like static node placement and manual deployment. depending on the blueprint of the structure, mesh topologies will be built with mains-powered relay points 🕸️ periodic, query-driven, and event-driven real-time data gathering is performed, and the emergency event-driven data must be delivered without delay 🚨
dominant parameters in structural monitoring applications:
- Deployment: Static, organized, pre-planned.
- Network Size: Small (dozens of nodes) to large.
- Power Source: Mains-powered nodes are mixed with battery-powered nodes. (Mains-powered nodes will be used for local coordination or relays.)
- Connectivity: Always connected, or intermittent via sleeping mode scheduling.
- Multi-Hop Communication: It is recommended that multi-hop mesh networking be supported.
- Traffic Pattern: MP2P (data collection), P2P (localized querying).
- Security Level: Safety-critical. Secure transmission must be guaranteed. Only authenticated users must be able to access and handle the data. 🔒
- Mobility: None.
- QoS: Emergency notification (fire, over-threshold vibrations, water level, etc.) is required to have priority of delivery and must be transmitted in a highly reliable manner. 🚨
- Other Issues: Accurate sensing and reliable transmission are important. In addition, sensor status reports should be maintained in a reliable monitoring system. 🫶
3.2.2. 6LoWPAN Applicability 💅
the network configuration for this use case can be done with simple topologies 🧩 however, there are lots of extended use cases for more complex structures. the example bridge monitoring case may be the simplest one. (an example topology is shown in Figure 3.)
LBR - LC ----- LC ------ LC LBR: LoWPAN Border Router
/| | | LC: Local Controller node
n n n - n - n n - n n: LoWPAN node
/\ | | | |
n n n - n n - n - n
Figure 3: A Bridge Monitoring Scenariothe LoWPAN nodes get installed in place after their locations are manually optimized 📌 since the leaf LoWPAN nodes' communication may be limited to the data-gathering points, both 16-bit and 64-bit addresses can be used for IPv6 link-local addresses [3] 🎀
each pillar might have one LC for data collection. communication schedules should be set up between leaf nodes and their LC so the different types of sensed data get gathered efficiently 🗓️ each data packet may include meta-information about its data, or the type of sensors could be encoded in its address during address allocation 🏷️
this type of application works with periodic, query-driven, and event-driven notifications 🔔 data over or under a predefined threshold is meaningful to report. event-driven data sensed during abnormal occurrences is time-critical and requires secure and reliable transmission ⚡ alternatively, for energy conservation, all nodes may have periodic and long sleep modes but wake up on certain events 😴 to make sure emergency event-driven data is reliable, that data is immediately relayed to a power-affluent or mains-powered node that usually takes a LoWPAN router role and doesn't go into a long sleep status 💪 the data-gathering entity can be programmed to trigger actuators installed in the infrastructure when a certain threshold value is reached ⚙️
because the structure's data is safety-critical, authentication and security are important issues here 🛡️ only authenticated users must be allowed to access the data. additional security should be provided at the LBR to restrict access from outside the LoWPAN. the LBR may take charge of authenticating LoWPAN nodes. reliable and secure data transmission must be guaranteed 🫡
3.3. Connected Home 🏡
The "Connected" Home or "Smart" home is without doubt an area where LoWPANs can be used to support an increasing number of services 💖
- Home safety/security 🔐
- Home automation and control 🤖
- Healthcare (see Section 3.4) 🩺
- Smart appliances and home entertainment systems 📺
in home environments, LoWPANs typically comprise a few dozen nodes and, probably in the near future, a few hundred nodes of various types: sensors, actuators, and connected objects 🌸
3.3.1. A Use Case and Its Requirements ✨
Example: Home Automation 🏡
okay so the home automation and control LoWPAN is giving everything. 💖 You can get local or remote access from the Internet (through a secured edge router) to keep an eye on the house: temperature, humidity, remote video surveillance, whether the doors are locked or open, etc. 🔐 You can also control it: turn on the air conditioning or heating, lock doors, run the sprinklers, and so on. 🌸 Fairly sophisticated systems can even optimize energy use, since they pull in input from sensors across the LoWPAN (light sensors, presence detection, temperature, etc.) 🧠 to control electric window shades, chillers, air flow, air conditioning, and heating. Main character energy, honestly 💅
With the rise of "Smart Grid" applications, the LoWPAN may also talk directly to the Grid itself over the Internet 🔌. It can report how many kilowatts could be load-shed (home to Grid) and receive dynamic load-shedding information when it's needed (Grid to home). This is called a Demand-Response application 🫶. There's also Demand-Side Management (DSM), where utilities monitor energy consumption and report it back to the user with fine granularity (per device!) 📊. The user can get other inputs from the utility too, like dynamic pricing. Depending on local policy, the utility may then switch some appliances on or off to lower its energy bill ⚡.
Now for home safety and security 🚨. The LoWPAN is made up of motion sensors, audio sensors, door and window sensors, and video cameras, and you can add more for safety (gas, water, CO, Radon, smoke detection) 🧯. It's typically a few dozen nodes forming an ad hoc network with multi-hop routing, because the nodes may not all be in direct range 🕸️. The number of devices tends to grow too, since there are more and more new apps for the home 📱. In its simplest form, all nodes are static and talk to a central control module. But more sophisticated scenarios can involve inter-device communication 🤝. For example, a motion or presence sensor might send a multicast message to a group of lights to switch them on, or a video camera might be activated to stream video to a cell phone through a gateway 🎥.
Ergonomics in connected homes is everything 💅, so the LoWPAN must be self-managed and easy to install. Traffic patterns can vary a lot depending on the application, and so can the level of reliability and QoS expected from the LoWPAN 📈. Humidity sensing is typically not critical and needs no immediate action. Tele-assistance or gas-leak detection, on the other hand, is critical and requires a high degree of reliability 🚒. Some actions may not involve critical data, but the response time and network delays must still be on the order of a few hundred milliseconds for a good user experience (like using a remote control to switch a light on) 💡. A minority of nodes are mobile, moving slowly 🐢. With energy-related applications on the scene, it becomes crucial to preserve data confidentiality 🔒. Connected home LoWPANs usually do not require multi-topology or QoS routing 🙅♀️. Fairly simple QoS mechanisms are enough for emergency data, though. They can be programmed to sound an alarm through actuators or to run the sprinklers 🚿.
Dominant parameters for home automation applications:
- Deployment: Multi-hop topologies.
- Network Size: Medium number of nodes, potentially high density.
- Power Source: Mix of battery-powered and mains-powered devices.
- Connectivity: Intermittent (usage-dependent sleep modes).
- Multi-Hop Communication: No requirement for multi-topology or QoS routing.
- Traffic Pattern: P2P (inter-device), P2MP, and MP2P (polling).
- Security Level: Authentication and encryption required.
- Mobility: Some degree of mobility.
- QoS: Support of limited QoS for emergency data (alarm).
3.3.2. 6LoWPAN Applicability 🧚
In the home automation use case, the network topology is a mix of battery-operated and mains-powered nodes that talk to each other. An LBR provides connectivity to the outside world for control management (Figure 4) 🌐.
In the home network, installation and management must be extremely simple for the user 🙈. Link-local IPv6 addresses can be used by nodes with no external communication, and the LBR allocates routable addresses so nodes that can't reach each other over a single radio transmission can still communicate 📡.
n --- n
| | LBR: LoWPAN Border Router
Internet/ ----- LBR/LC -- n --- n ---- LC LC: Local Controller node
Utility network | | /|\ n: LoWPAN node
n ---- n n n n
(outside) (home automation system) Figure 4: Home Automation ScenarioIn some scenarios, traffic gets sent to an LC for processing, and the LC may then decide on local actions (switch a light on, ...) 💡. In other scenarios, all devices send their data to the LCs, which may also act as the LBR for data processing and for relaying data outside of the LoWPAN 🔄. That doesn't mean every device talks to every other device through the LC and LBR, though 🙅♀️. For illustration, some data may be processed to trigger local action (like switching off an appliance). Other data may just get stored and sent once enough has built up (like energy consumption for the past 6 hours for a set of appliances) 🗂️. And some data triggers an alarm that gets sent to a datacenter right away (like gas-leak detection) 🚨.
Most nodes in the LoWPAN will be in direct range, but some will reach the LBR/LC over a path of 2-3 hops (with several low-power media emerging, such as low-power PLC) 🔁. In that case, LoWPAN routers will be deployed in the home to interconnect the various IPv6 links 🧩.
The home LoWPAN must be able to provide extremely reliable communication for some specific applications (fire, gas-leak detection, health monitoring) 🔥, while other applications may not be critical (humidity monitoring) 💧. Emergency data has the same QoS issues as event-driven data in other applications. It can be delivered over pre-defined paths through mains-powered nodes without being stored in intermediate nodes such as LCs ⚡. Similarly, some information may need security mechanisms for authentication and confidentiality 🔐.
3.4. Healthcare 🩺
LoWPANs are envisioned to be heavily used in healthcare environments 💜. They have a high potential to make new services easier to deploy by getting rid of cumbersome wires, and they simplify patient care in hospitals and at home (home care) 🏥. In healthcare, delayed or lost information may be a matter of life or death 😭.
There's a whole range of systems that LoWPANs can support 🌈. On one end are simple wearable remote controls for tele-assistance. Then there are intermediate systems with wearable sensor nodes monitoring various metrics. At the complex end are systems for studying life dynamics. In that last category, a large amount of data can be collected from various LoWPAN nodes: movement pattern observation, checks that medicaments have been taken, object tracking, and more 🧠. An example of such a deployment is described in [10] using the concept of "personal networks" 📚.
3.4.1. A Use Case and Its Requirements 👑
Example: Healthcare at Home by Tele-Assistance 🏠
A senior citizen who lives alone wears one to several wearable LoWPAN nodes to measure heartbeat, pulse rate, etc. 💓 Dozens of LoWPAN nodes are densely installed around the home for movement detection. An LBR at home sends the sensed information to a connected healthcare center 🏥. Portable base stations with LCDs may also be used to check the data at home. The different roles of devices have different duty cycles, which affects node management ⏱️.
Multipath interference may often occur because patients move around at home, where there are many walls and obstacles 🧱. Even during sleep, changing body position may affect radio propagation 😴.
Data is gathered in both periodic and event-driven fashion. In this application, event-driven data can be very time-critical 🚨. So real-time and reliable transmission must be guaranteed ⏰.
Privacy is a serious issue here too, since the sensed data is very personal 🫣. A small set of secret keys can be shared among the sensor nodes during bootstrapping, so a secure link can be built without using much memory and energy 🔑. Different data is also provided to the hospital system than to a patient's family members 👨👩👧. Role-based access control is needed to support this, so support of authorization and authentication is important 🛡️.
Dominant parameters in healthcare applications:
- Deployment: Pre-planned.
- Network Size: Small, high node density.
- Power Source: Hybrid.
- Connectivity: Always on.
- Multi-Hop Communication: Multi-hop for home-care devices; patient's body network is star topology. Multipath interference due to walls and obstacles at home must be considered.
- Traffic Pattern: MP2P/P2MP (data collection), P2P (local diagnostic).
- Security Level: Data privacy and security must be provided. Encryption is required. It is required that role-based access control be supported by a lightweight authentication mechanism.
- Mobility: Moderate (patient's mobility).
- QoS: High level of reliability support (life-or-death implication), role-based.
- Other Issues: Plug-and-play configuration is required for mainly non-technical end-users. Real-time data acquisition and analysis are important. Efficient data management is needed for various devices that have different duty cycles, and for role-based data control. Reliability and robustness of the network are also essential. 💖
3.4.2. 6LoWPAN Applicability 🏠
okay so bestie, in this use case the local network is pretty small, like 10 nodes or less 🥺. The home care system is statically configured with multi-hop paths, and the patient's body network can be built as a star topology 🌟. The LBR at home is the sink node in the routing path from sources on the patient's body. A plug-and-play configuration is required. Since the communication stays inside a home environment, both 16-bit and 64-bit addresses can be used for IPv6 link-local addresses [3]. Here's an example topology in Figure 5 💅.
The patient's body network can be simply configured as a star topology with an LC handling data aggregation and dynamic network attachment when the patient moves around at home 🚶♀️. Multipath interference may often happen because the patient is mobile at home, so the deployment of LoWPAN nodes and transmission paths should be well considered 🧠. At home, some nodes can be installed with power-affluence status, and those LoWPAN nodes can be used for relaying points or data aggregation points 🔌.
The sensed information must be maintained with the identification of the patient, whether the patient visits the connected hospital or stays at home 🩺. If the patient's LoWPAN uses a globally unique IPv6 address, that address can be used for patient identification. However, this comes with a cost in terms of privacy and security 🙈. The hospital LoWPAN that receives the patient's information needs to operate an additional identification system, together with a strong authority and authentication mechanism 🔐. The connection between the LBR at home and the LBR at the hospital must be reliable and secure, because the data is privacy-critical 💜. To get there, an additional policy for security between the two LoWPANs is recommended ✨.
n - n I: Internet
| | LBR: Edge Router
LBR --- I -- LBR - n - n - LC LC: Local Controller node
/|\ | | /|\ n: LoWPAN node
.. . .. n -- n n n n
(hospital) (home system) (patient)Figure 5: A Mobile Healthcare Scenario 🎀
3.5. Vehicle Telematics 🚗
LoWPANs play an important role in intelligent transportation systems 🛣️. Built into roads, vehicles, and traffic signals, they help improve safety in transportation systems. Through traffic or air-quality monitoring, they increase the possibility of traffic flow optimization, and they help reduce road congestion 🚦.
3.5.1. A Use Case and Its Requirements
Example: Telematics 🏎️
As shown in Figure 6, LoWPAN nodes for motion monitoring are incorporated into roads during road construction 🛤️. When a car passes over these nodes, it becomes possible to track the trajectory (path) and velocity of the car, for safety purposes 👀.
The lifetime of LoWPAN nodes incorporated into roads is expected to be as long as the lifetime of the roads (about 10 years) ⏳. Multi-hop communication is possible between LoWPAN nodes, and the network should be able to cope with the deterioration over time of node density due to power failures 🔋. Sink nodes placed at the side of the road are most likely mains-powered, while LoWPAN nodes in the roads run on batteries. Power-saving schemes might intermittently disconnect the nodes. A rough estimate of 4 nodes per square meter is needed 📏. Other applications may involve car-to-car communication for increased road safety 🚙💨.
Dominant parameters in vehicle telematics applications:
- Deployment: Pre-planned (road, vehicle).
- Network Size: Large (road infrastructure), small (vehicle).
- Power Source: Hybrid.
- Connectivity: Intermittent.
- Multi-Hop Communication: Multi-hop, especially ad hoc.
- Traffic Pattern: Mostly MP2P, P2MP.
- Security Level: Handling physical damage and link failure.
- Mobility: None (road infrastructure), high (vehicle).
3.5.2. 6LoWPAN Applicability
For this use case, the network topology includes fixed LBRs that are mains-powered and have a connection to high-speed networks (e.g., the Internet) so they can reach the transportation control center (Figure 6) 🏢. These LBRs may be logically combined with an LC as a data sink, gathering sensed data from a number of LoWPAN nodes inserted in the road pavement 🧩. In the road infrastructure, a LoWPAN with one LBR forms a fixed network, and the LoWPAN nodes are installed by manual optimization of their location 📍.
+-----+
| LBR |--------------------------- LBR ...
+-----+ (at the roadside)
-------|------------------------------
|
n -- n --- n --- n +---|---+ LBR: LoWPAN Border Router
/ \ | | n-n-n | n: LoWPAN node
n n n +---|---+
(cars)
--------------------------------------Figure 6: Telematics Scenario 🎀
Since the nodes are built into the road, it's pretty hard for an adversary to tamper with the sensors 🙅♀️. Still, the application must be robust against possible attacks and node failures 🛡️. So the sensed data should be used primarily for monitoring purposes, not to instruct (and potentially mislead) traffic participants 🚫🚗.
3.6. Agricultural Monitoring 🌾
Accurate temporal and spatial monitoring can significantly increase agricultural productivity 📈. Because of natural limitations, like a farmer not being able to check crops at all times of the day, or inadequate measurement tools, luck often plays too large a role in the success of harvests 🍀. With a network of strategically placed sensors, indicators such as temperature, humidity, and soil condition can be monitored automatically, without labor-intensive field measurements 🤖. For example, sensor networks could provide precise information about crops in real time, letting businesses reduce water, energy, and pesticide usage while enhancing environmental protection 🌍. The sensing data can be used to find optimal environments for the plants 🌱. On top of that, data on planting conditions can be saved by sensor tags, which can be used in supply-chain management 📦.
3.6.1. A Use Case and Its Requirements
Example: Automated Vineyard 🍇
In a vineyard of medium to large geographical size, between 50 and 100 LC nodes are manually deployed to provide full signal coverage over the study area 🗺️. An additional 100 to 1000 leaf nodes, with (possibly heterogeneous) specialized sensors (i.e., humidity, temperature, soil condition, sunlight), are attached to the LCs in local wireless star topologies, periodically reporting measurements to the associated LCs 📡. For example, in a 20-acre vineyard with 8 parcels of land, 10 LoWPAN nodes are placed within each parcel to provide readings on temperature and soil moisture 🌡️. The LoWPAN nodes are able to support a multi-hop forwarding/routing scheme to enable data transmission to a sink node at the edge of the vineyard. Each of the 8 parcels contains one data aggregator to collect the sensed data 🧺.
Localization is important for this type of LoWPAN when it's installed in a geographically large area, so you can pin down where an event occurred and combine gathered data with the actual positions of the devices 📌. With manual deployment, device addresses can be used for identifying their position and localization. For randomly deployed nodes, a localization algorithm needs to be applied 🎯.
There might be various types of sensor devices deployed in a single LoWPAN, each providing raw data with different semantics 🤹♀️. Thus, an additional method is required to correctly interpret sensor readings. Each data packet may include meta-information about its data, or the type of sensor could be encoded in its address during address allocation 🏷️.
Dominant parameters in agricultural monitoring:
- Deployment: Pre-planned.
The nodes are installed outdoors or in a greenhouse, with high exposure to water, soil, and dust, in dynamic environments of moving people and machinery, and with growing crops and foliage. LoWPAN nodes can be deployed in a predefined manner, with consideration given to harsh environments 🌦️.
- Network Size: Medium to large, low to medium density.
- Power Source: All nodes are battery-powered except the sink, or energy harvesting ☀️.
- Connectivity: Intermittent (many sleeping nodes) 😴.
- Multi-Hop Communication: Mesh topology with local star connections 🕸️.
- Traffic Pattern: Mainly MP2P/P2MP. P2P actuator triggering 💧.
- Security Level: Depends on the purpose of the business. Lightweight security or simple shared-key management can be used, depending on the purpose of the business 🔑.
- Mobility: All static 🪴.
- Other Issues: Time synchronization among sensors is required, but the traffic interval may not be frequent (e.g., once every 30 to 60 minutes) ⏰.
3.6.2. 6LoWPAN Applicability
The network configuration in this use case might, in the simplest case, look like the one illustrated in Figure 7 🍷. This static scenario consists of one or more fixed LBRs that are mains-powered and have a high-bandwidth connection to a backbone link, which might be placed in a control center or connected to the Internet 🖥️. The LBRs are strategically located at the border of vineyard parcels, acting as data sinks. A number of LCs are placed along a row of plants, with individual LoWPAN nodes spread around them 🌿.
While the LBRs implement the IPv6 Neighbor Discovery protocol (RFC 4861 [1]) to connect to the outside of the LoWPAN, the LoWPAN nodes operate a more energy-conserving ND described in [6], which includes basic bootstrapping and address assignment 🔋. Each LBR can have predefined forward management information to a central data aggregation point, if necessary 📬.
LoWPAN nodes may send event-driven notifications when readings exceed certain thresholds, such as low soil humidity, which may automatically trigger a water sprinkler in the local environment 💦. For increased energy efficiency, all LoWPAN nodes are in periodic sleep state. However, the LCs need to be aware of sudden events from the leaf nodes, so their sleep periods should be set to shorter intervals ⚡. Communication schedules must be set up between master and leaf nodes, and time synchronization is needed to account for clock drift ⌚.
Also, the result of data collection may activate actuators 🚿. Context awareness, node identification, and data collection at the application level are necessary 🧠✨.
I
|
| n n n n n n n n n I: Internet
| \|/ \|/ \|/ LBR: LoWPAN Border Router
LBR----LC------LC------LC LC: Local Controller node
| /|\ /|\ /|\ n: LoWPAN node
| n n n n n n n n n
|
LBR
...Figure 7: Automated Vineyard Scenario 🍓
4. Security Considerations 🔐
Okay bestie, security is where things get real 😭 Relevant security considerations are listed by application scenario in Section 3. The security considerations in RFC 4919 [2] and RFC 4944 [3] apply as well.
The physical exposure of LoWPAN nodes (especially in outdoor networks) means an adversary can capture, clone, tamper with, or even destroy these devices 💀 Given the safety issues in some use cases, these threats demand serious resiliency and survivability from the LoWPAN. The generally wireless channels of LoWPANs are susceptible to several security threats. Without proper security measures, confidential information might be snooped by a "man in the middle". An attacker might also modify or introduce data packets into the network, for example to manipulate sensor readings or to take control of sensors and actuators. This specification expects that the link layer is sufficiently protected, either by means of physical or IP security for the backbone link or with MAC sublayer cryptography. However, link-layer encryption and authentication may not be sufficient to provide confidentiality, authentication, integrity, and freshness to both data and signaling packets 🫠
Because they're low-power, LoWPANs are especially vulnerable to denial-of-service (DoS) attacks 🚨 Example DoS attacks include attempts to drain a node's battery by excessive querying, or to introduce a high-power jamming signal that makes LoWPAN nodes dysfunctional. Security solutions must therefore be lightweight and support node authentication, so that message integrity can be guaranteed and misbehaving nodes can be denied participation in the network. A node must authenticate itself to trusted nodes before taking part in the LoWPAN. No skipping this step, periodt ✨
Considering the power constraints and limited processing capabilities of IEEE 802.15.4 devices, IPsec is computationally expensive. Internet key exchange (IKEv2) messaging as described in [4] is not suited for LoWPANs, as the amount of signaling in these networks should be minimized. Thus, LoWPANs may need to define their own key-management method that requires minimum overhead in terms of packet size and message exchange [11]. IPsec provides authentication and confidentiality between end nodes and across multiple LoWPAN links, and may be useful only when two nodes want to apply security to all exchanged messages. However, in many cases, the security may be requested at the application layer as needed, while other messages can flow in the network without security overhead. Recent work [13] shows some promise for minimal IKEv2 implementations 👀
Security requirements may differ by use case 💖 For example, industrial and structural monitoring applications are safety-critical, and secure transmission must be guaranteed so that only authenticated users are able to access and handle the data. In healthcare systems, data privacy is an important issue. Encryption is required, and role-based access control is needed for proper authentication. In home automation scenarios, critical applications such as door locks require high security and robustness against intrusion. On the other hand, a remote-controlled light switch has no critical security threats 💡
5. Acknowledgements 🫶
Special thanks to Nicolas Chevrollier for participating in the initial design of the document. Also, thanks to David Cypher for giving more insight on the IEEE 802.15.4 standard, and to Irene Fernandez, Shoichi Sakane, and Paul Chilton for their review and valuable comments 🌸
6. References 📚
6.1. Normative References
[1] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[2] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007.
[3] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.
[4] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[5] IEEE Computer Society, "IEEE Standard for Local and Metropolitan Area Networks -- Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)", IEEE Std. 802.15.4-2011, September 2011.
6.2. Informative References
[6] Shelby, Z., Ed., Chakrabarti, S., and E. Nordmark, "Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)", Work in Progress, October 2011.
[7] Hui, J., Ed., and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011.
[8] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem Statement and Requirements for 6LoWPAN Routing", Work in Progress, November 2011.
[9] Roemer, K. and F. Mattern, "The Design Space of Wireless Sensor Networks", IEEE Wireless Communications, Vol. 11, No. 6, pp. 54-61, December 2004.
[10] den Hartog, F., Schmidt, J., and A. de Vries, "On the potential of personal networks for hospitals", International Journal of Medical Informatics, 75, pp. 658-663, May 2006.
[11] Dutertre, B., Cheung, S., and J. Levy, "Lightweight Key Management in Wireless Sensor Networks by Leveraging Initial Trust", SDL Technical Report SRI-SDL-04-02, April 2004.
[12] Chen, D. and P.K. Varshney, "QoS Support in Wireless Sensor Networks: A Survey", Proc. 2004 Int. Conf. Wireless Networks (ICWN 2004), June 2004.
[13] Kivinen, T., "Minimal IKEv2", Work in Progress, February 2011.
Authors' Addresses 🦋
Eunsook Kim
ETRI
161 Gajeong-dong
Yuseong-gu
Daejeon 305-700
Korea
Phone: +82-42-860-6124
EMail: eunah.ietf@gmail.com
Dominik Kaspar
Simula Research Laboratory
Martin Linges v 17
Snaroya 1367
Norway
Phone: +47-6782-8200
EMail: dokaspar.ietf@gmail.com
JP. Vasseur
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
EMail: jpv@cisco.com📦 where this page comes from
- ietf: rfc6568 2012-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms