6  6LoWPAN Routing with RPL

In 60 Seconds

6LoWPAN supports two routing approaches: mesh-under (fast Layer 2 forwarding using MAC addresses where the mesh appears as one IP subnet) and route-over (Layer 3 forwarding using RPL, which builds a tree-shaped DODAG rooted at the border router). RPL selects optimal parents using Expected Transmission Count (ETX) to minimize total path cost.

Minimum Viable Understanding

6LoWPAN routing uses two approaches: mesh-under (fast Layer 2 forwarding using MAC addresses) and route-over (standard Layer 3 forwarding using RPL). RPL builds a tree-shaped DODAG topology rooted at the border router, selecting optimal parents based on Expected Transmission Count (ETX) to minimize total path cost. 6LoWPAN-ND optimizes IPv6 Neighbor Discovery for sleep-friendly, low-power operation.

6.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Analyze RPL Architecture: Deconstruct DODAG topology construction, message exchanges (DIO, DAO, DIS), and route formation in 6LoWPAN networks
  • Evaluate Mesh-Under vs Route-Over: Justify selection of Layer 2 or Layer 3 forwarding based on latency, power, and manageability constraints
  • Calculate RPL Metrics: Derive ETX values from link statistics and compute rank for parent selection decisions
  • Apply 6LoWPAN-ND Optimizations: Implement sleep-friendly Neighbor Discovery registration flows that eliminate multicast overhead
  • Design Multi-Hop Networks: Architect routing topologies for large-scale 6LoWPAN deployments with appropriate objective functions

6LoWPAN lets tiny IoT devices use IPv6 (the Internet’s addressing system) even though they have very limited resources. RPL provides the routing on top of 6LoWPAN, creating a complete communication system. Think of it as giving every small sensor its own internet address and a reliable way to deliver its messages.

“How does my data get from here to the border router if I am too far away to reach it directly?” asked Sammy the Sensor, peering across a large warehouse.

Max the Microcontroller drew a tree on the whiteboard. “That is where RPL comes in! It builds a routing tree with the border router at the top – like a family tree. Every sensor picks a parent to forward messages to, and those parents pick their own parents, all the way up to the root. Your data hops from branch to branch until it reaches the top.”

“But how does each sensor choose the best parent?” asked Lila the LED. Max pointed to a number next to each branch. “Using ETX – Expected Transmission Count. It measures how many attempts it takes to successfully deliver a packet to each neighbor. A neighbor with ETX of 1.2 is very reliable. One with ETX of 4.5 means lots of retries. Sensors always pick the path with the lowest total ETX.”

Bella the Battery smiled. “Fewer retransmissions means less energy wasted! RPL is like a GPS that always finds the most fuel-efficient route.” Max agreed. “And if a parent node fails or moves, RPL automatically finds a new path – the tree repairs itself. That is the beauty of mesh routing!”

6.2 Prerequisites

Before diving into this chapter, you should be familiar with:

6.3 Mesh-Under vs Route-Over Forwarding

6LoWPAN supports two forwarding paradigms with different trade-offs:

6.3.1 Mesh-Under Forwarding (Layer 2)

Forwarding happens at Link Layer using 802.15.4 addresses
Compressed packet stays compressed through intermediate hops
Entire mesh appears as single IP subnet

Example packet flow:
  Node A -> [L2 forward to B using MAC] -> Node B -> [L2 forward to C] -> Node C
  IPv6 header remains compressed at all hops
  Routing decision based on 802.15.4 addresses

Advantages:

  • Lower per-hop overhead (no IPHC decompress/recompress)
  • Faster forwarding (no IP layer processing at intermediate nodes)
  • Lower power consumption per hop (~50-100 us processing)
  • Simpler routing tables (L2 next-hop only)

Disadvantages:

  • Requires proprietary L2 routing protocol
  • Limited hop count (typically max 15 hops)
  • IP management tools don’t see internal topology
  • No standard for mesh routing (vendor lock-in risk)

Artistic visualization of 6LoWPAN mesh-under forwarding showing Layer 2 packet forwarding using 802.15.4 MAC addresses, with compressed IPv6 headers maintained through intermediate hops for lower latency and power consumption

6LoWPAN Mesh-Under Forwarding
Figure 6.1: Mesh-under forwarding operates at Layer 2, using IEEE 802.15.4 MAC addresses for routing decisions. This approach keeps IPv6 headers compressed throughout the multi-hop path, reducing processing overhead at intermediate nodes.

6.3.2 Route-Over Forwarding (Layer 3 with RPL)

Forwarding happens at Network Layer using IPv6 addresses
Each node decompresses, routes, recompresses
Every node is an IP router with its own address(es)

Example packet flow:
  Node A -> [Decompress, consult RPL table, recompress] -> Node B ->
  [Decompress, route, recompress] -> Node C

Advantages:

  • Standard routing protocol (RPL - RFC 6550)
  • Works with IP tools (ping, traceroute, SNMP)
  • Intelligent routing (ETX, link quality metrics)
  • Firewall/ACL rules can inspect IP addresses
  • Better scalability (hierarchical addressing)

Disadvantages:

  • Higher per-hop overhead (decompress/recompress)
  • More CPU cycles per hop (~200-500 us)
  • Higher power consumption at intermediate nodes
  • Larger routing tables (IPv6 prefix-based)

6.3.3 Performance Comparison (3-Hop Path)

Metric Mesh-Under Route-Over
Per-hop latency 50-100 us 200-500 us
3-hop latency 150-300 us 600-1500 us
Energy per hop 13.5 mAus 54-135 mAus
Routing table size 10-50 bytes 100-500 bytes
IP management Limited Full

6.3.4 When to Use Each

Choose Mesh-Under if:

  • Ultra-low latency critical (<10 ms end-to-end)
  • Power budget extremely tight
  • Network topology simple and static
  • No IP management tools needed
  • Single-vendor deployment acceptable

Choose Route-Over if:

  • Standard protocols important
  • IP tools needed (SNMP, ping, traceroute)
  • Multi-vendor interoperability required
  • Dynamic topology (nodes join/leave frequently)
  • Integration with existing IP infrastructure

Hybrid Approach: Some implementations use mesh-under for local cluster (5-10 nodes) and route-over between clusters.

6.3.5 Quick Check: Forwarding Trade-offs

6.4 RPL: Routing Protocol for LLNs

RPL (RFC 6550) is the standard routing protocol for 6LoWPAN networks.

6.4.1 Key Concepts

  • DODAG: Destination-Oriented Directed Acyclic Graph – a tree-like topology rooted at the border router where edges are directed toward the root and no cycles exist
  • Rank: Scalar value representing a node’s position relative to the root; strictly increases from root to leaves and is used for loop avoidance
  • DIO (DODAG Information Object): Multicast message sent by routers advertising DODAG presence, carrying RPL Instance ID, DODAG ID, Rank, Mode of Operation, and Objective Function identifier
  • DAO (Destination Advertisement Object): Unicast message sent upward from leaf nodes toward the root, propagating prefix reachability information to enable downward (root-to-leaf) routing
  • DIS (DODAG Information Solicitation): Request message sent by a node to solicit DIO messages from neighboring routers, used when a node first boots or loses its parent
  • Objective Function (OF): Algorithm that defines how nodes compute Rank from routing metrics (e.g., OF0 uses hop count, MRHOF uses ETX); specified in RFC 6552 (OF0) and RFC 6719 (MRHOF)

6LoWPAN routing considerations for low-power lossy networks

6LoWPAN Routing Considerations
Figure 6.2: 6LoWPAN routing considerations showing RPL DODAG structure with border router as root.

6.4.2 Traffic Patterns

RPL supports two modes of operation that affect how downward and point-to-point traffic is handled:

  • Upward (Multipoint-to-Point): Default traffic flow; each node forwards packets to its preferred parent, following parent pointers toward the DODAG root
  • Downward (Point-to-Multipoint): Root uses DAO-populated routing tables to forward to leaf nodes. In storing mode, intermediate routers maintain routing entries. In non-storing mode, the root inserts an IPv6 source routing header (RPL SRH) specifying the full path
  • Point-to-Point: In storing mode, packets route upward until reaching a common ancestor that has a downward route. In non-storing mode, packets travel all the way to the root, which then source-routes them down to the destination

6.4.3 ETX-Based Parent Selection

RPL uses Expected Transmission Count (ETX) to select the best parent:

ETX Calculation:

ETX = 1 / (PRR_forward x PRR_reverse)

Where:
  PRR_forward = Packet Reception Rate (delivery success)
  PRR_reverse = ACK Reception Rate (acknowledgment success)

Example: | Metric | Router A | Router B | |——–|———-|———-| | Packets sent | 100 | 100 | | Successful deliveries | 95 | 75 | | ACKs received | 98 | 55 | | PRR forward | 0.95 | 0.75 | | PRR reverse | 0.98 | 0.55 | | ETX | 1/(0.95 x 0.98) = 1.07 | 1/(0.75 x 0.55) = 2.42 |

Interpretation:

  • ETX 1.07: Expect ~1 transmission per successful delivery (excellent)
  • ETX 2.42: Expect ~2.5 transmissions per successful delivery (poor)

6.4.4 Rank Calculation

NewRank = ParentRank + RankIncrease x ETX

Where:
- ParentRank: Parent's advertised Rank
- RankIncrease: Step per hop (typically 256)
- ETX: Expected Transmission Count to parent

Let’s calculate RPL ranks for a multi-hop IoT deployment with real link quality metrics:

ETX Calculation from Link Statistics: \[ \begin{aligned} \text{ETX} &= \frac{1}{\text{PRR}_{\text{forward}} \times \text{PRR}_{\text{reverse}}} \\ \\ \text{Good link (Router A):} \quad & \text{PRR}_{\text{fwd}} = \frac{95}{100} = 0.95, \quad \text{PRR}_{\text{rev}} = \frac{98}{100} = 0.98 \\ & \text{ETX}_A = \frac{1}{0.95 \times 0.98} = 1.074 \\ \\ \text{Poor link (Router B):} \quad & \text{PRR}_{\text{fwd}} = \frac{75}{100} = 0.75, \quad \text{PRR}_{\text{rev}} = \frac{55}{100} = 0.55 \\ & \text{ETX}_B = \frac{1}{0.75 \times 0.55} = 2.424 \end{aligned} \]

Rank Calculation (DODAG construction, RankIncrease = 256): \[ \begin{aligned} \text{DODAG Root (border router):} \quad & \text{Rank}_{\text{root}} = 256 \\ \\ \text{Node 1 via Router A:} \quad & \text{Rank}_1 = 256 + (256 \times 1.074) = 256 + 275 = 531 \\ \\ \text{Node 1 via Router B:} \quad & \text{Rank}_1 = 256 + (256 \times 2.424) = 256 + 621 = 877 \\ & \text{(Node 1 selects Router A as parent: 531 < 877)} \\ \\ \text{Node 2 via Node 1 (ETX=1.15):} \quad & \text{Rank}_2 = 531 + (256 \times 1.15) = 531 + 294 = 825 \\ \\ \text{Max rank difference (loop avoid):} \quad & \Delta\text{Rank}_{\text{max}} = \frac{256 \times 7}{8} = 224 \\ & \text{(Reject parents with Rank} > \text{CurrentRank} - 224) \end{aligned} \]

Route-Over Energy Cost (3-hop path): \[ \begin{aligned} \text{Per-hop processing:} \quad & t_{\text{decompress}} + t_{\text{route}} + t_{\text{recompress}} \approx 350\text{ µs} \\ \text{Active current:} \quad & I_{\text{active}} = 15\text{ mA (STM32L4 @ 16 MHz)} \\ \text{Energy per hop:} \quad & E_{\text{hop}} = V \times I \times t = 3\text{V} \times 15\text{mA} \times 350\text{µs} = 15.75\text{ µJ} \\ \text{3-hop relay cost:} \quad & E_{\text{relay}} = 3 \times 15.75\text{ µJ} = 47.25\text{ µJ (vs. 40.5 µJ for mesh-under)} \end{aligned} \]

Route-over consumes ~17% more energy per hop due to IPv6 header decompression/recompression, but enables intelligent ETX-based routing and standard IP tooling.

6.5 Knowledge Check: RPL Routing

6.5.1 Knowledge Check: ETX Parent Selection

6.5.2 Knowledge Check: Mesh-Under vs Route-Over

6.6 Worked Example: Routing Design for a 500-Node Smart Building

Scenario: A 12-story commercial building deploys 500 6LoWPAN temperature/humidity sensors for zone-level HVAC optimization. Each floor has ~42 sensors in open-plan offices, meeting rooms, and server rooms. The building management system (BMS) runs on a central server with a 6LoWPAN border router per floor.

6.6.1 Network Parameters

Parameter Value
Sensors per floor ~42 (500 total across 12 floors)
Border routers 12 (one per floor, Ethernet backhaul)
Transmission interval 60 seconds (HVAC control loop)
Payload size 24 bytes (temp: 2B, humidity: 2B, CO2: 2B, timestamp: 4B, battery: 2B, reserved: 12B)
MCU Nordic nRF52840 (256 KB RAM, 1 MB Flash)
Radio IEEE 802.15.4 at 2.4 GHz, 250 kbps
Max hops to border router 4 (office floor ~40m x 25m)
Link quality 85-95% PRR indoor (concrete walls, steel furniture)

6.6.2 Routing Approach Decision

Mesh-Under Analysis (Layer 2 forwarding):

Metric Calculation Result
Per-hop latency 75 us avg (no IP processing) 300 us for 4 hops
Energy per hop 13.5 mAus x 4 hops 54 mAus per message
RAM for routing table ~30 bytes x 42 neighbors 1,260 bytes
Daily energy (42 sensors, 4 hops) 54 mAus x 1440 msgs/day 77.8 mAus/day per sensor
IP management None (L2 only) No ping, no traceroute

Route-Over with RPL Analysis (Layer 3 forwarding):

Metric Calculation Result
Per-hop latency 350 us avg (decompress/recompress) 1,400 us for 4 hops
Energy per hop 94.5 mAus x 4 hops 378 mAus per message
RAM for routing table ~200 bytes x 42 entries 8,400 bytes
Daily energy (42 sensors, 4 hops) 378 mAus x 1440 msgs/day 544 mAus/day per sensor
IP management Full IPv6 ping, traceroute, SNMP

Decision factors for GreenTower:

Factor Weight Mesh-Under Route-Over (RPL)
IT integration (SNMP monitoring) High Poor Excellent
Multi-vendor interop High Vendor-locked Standards-based
Power efficiency Medium 7x better Acceptable (nRF52840 has headroom)
Latency (60s control loop) Low 0.3 ms 1.4 ms (both far under 60s)
Debugging capability High Packet sniffers only ping, traceroute, Wireshark
Score – 2/5 5/5

GreenTower chose Route-Over with RPL because: - IT team requires SNMP monitoring of all 500 sensors - Multi-vendor procurement policy (Nordic, Silicon Labs, TI sensors) - 1.4 ms latency is negligible vs 60-second HVAC control loop - Energy difference (378 vs 54 mAus/hop) is within nRF52840’s 5-year battery budget

6.6.3 RPL DODAG Configuration

Floor 7 example (42 sensors, 1 border router):

Border Router (Root): Rank 256, ETX to uplink = 1.0
├── Router A (hallway): Rank 537, ETX=1.10 to root
│   ├── Sensor 7-01: Rank 818, ETX=1.10 to A
│   ├── Sensor 7-02: Rank 845, ETX=1.20 to A
│   └── Sensor 7-03: Rank 870, ETX=1.30 to A
├── Router B (open plan): Rank 614, ETX=1.40 to root
│   ├── Sensor 7-10: Rank 972, ETX=1.40 to B
│   ├── Sensor 7-11: Rank 895, ETX=1.10 to B
│   └── ... (12 more sensors)
├── Router C (meeting rooms): Rank 588, ETX=1.30 to root
│   ├── Sensor 7-20: Rank 921, ETX=1.30 to C
│   └── ... (8 more sensors)
└── Router D (server room): Rank 512, ETX=1.00 to root
    ├── Sensor 7-30: Rank 768, ETX=1.00 to D
    └── ... (5 more sensors, excellent links)

Rank calculation for Sensor 7-02 through Router A:

NewRank = ParentRank + (RankIncrease x ETX)
        = 537 + (256 x 1.20)
        = 537 + 307
        = 844 (rounded to 845)

Alternative path for Sensor 7-02 through Router B (if A fails):

NewRank = 614 + (256 x 2.10)  // worse link through wall
        = 614 + 538
        = 1152 (higher rank = worse path)

RPL correctly selects Router A (Rank 845 < 1152) as preferred parent.

6.6.4 Measured Results (6 months post-deployment)

Metric Target Achieved
Data delivery rate > 99% 99.3%
Avg end-to-end latency < 5 sec 1.8 sec (including sleep cycles)
Battery life projection 5 years 5.2 years (measured drain 0.41 uA avg)
DODAG convergence time < 60 sec 34 sec (after border router reboot)
Parent switches per day < 10 per floor 3.2 avg (link quality stable indoors)
SNMP polling success > 99.5% 99.7%
Monthly sensor failure < 1% 0.4% (mostly physical damage from cleaning)

Key lesson: Route-over with RPL costs more energy per hop but provides IT manageability that justified the trade-off. The 7x energy difference (378 vs 54 mAus/hop) translates to only a 15% reduction in total battery life because the radio sleep cycle (99.8% duty) dominates power consumption, not per-hop processing.

6.7 Neighbor Discovery Optimization (6LoWPAN-ND)

Standard IPv6 Neighbor Discovery is too chatty for low-power networks: - Multicast messages drain battery - Router advertisements every few seconds - Address resolution requires broadcasts

6LoWPAN-ND Improvements (RFC 6775):

  • Host-initiated registration: Hosts register with router (no periodic RAs)
  • No multicast DAD: Duplicate Address Detection done by router
  • Efficient address resolution: Router maintains address table
  • Sleep-friendly: Hosts can sleep, router buffers packets

6.7.1 Registration Flow

Sequence diagram showing 6LoWPAN Neighbor Discovery registration flow where a host node sends a Neighbor Solicitation with Address Registration Option to its parent router, the router performs Duplicate Address Detection with the border router, and the border router responds with a Neighbor Advertisement confirming the registration, enabling sleep-friendly address management without multicast.

6LoWPAN-ND Registration Flow

Common Pitfalls

In non-storing mode, all downlink traffic must go through the root, creating a bottleneck. Non-storing mode works well for sensor-to-cloud telemetry but performs poorly for bidirectional control applications. Use storing mode (Mode 2) when frequent downlink messages are needed.

Default RPL Trickle parameters generate excessive control traffic in stable networks. Tune Imin, Imax, and k parameters for your update frequency requirements to reduce DIO overhead from the default ~5% channel usage to under 1%.

RPL uses DODAG version increments to trigger global network repair. Frequent version increments (more than once per hour) indicate routing instability that will degrade application performance. Monitor version change rates as a health metric.

6.8 Summary

This chapter explored 6LoWPAN routing mechanisms:

  • Mesh-Under vs Route-Over represent different trade-offs: L2 forwarding is faster/lower-power, L3 forwarding provides IP management and standards compliance
  • RPL (RFC 6550) builds DODAG topology optimized for upward traffic to border router
  • ETX-based routing selects parents based on link quality, not just hop count
  • Rank calculation combines parent rank with link metric for path cost optimization
  • 6LoWPAN-ND reduces Neighbor Discovery overhead through host-initiated registration and sleep-friendly buffering

::

::

6.9 What’s Next

Chapter Focus Area
6LoWPAN Deployment Real-world deployment scenarios and decision frameworks for production 6LoWPAN networks
6LoWPAN Pitfalls Common mistakes, debugging strategies, and troubleshooting RPL routing issues
6LoWPAN Hands-On and Security Practical labs with security considerations for 6LoWPAN deployments
6LoWPAN Lab Simulation Simulated exercises to practice RPL configuration and DODAG analysis
Thread Network Architecture How Thread builds on 6LoWPAN and RPL with mesh-local addressing and commissioning