1. Dominik Kaspar, Eunsook Kim, Carles Gomez, Carsten Bormann
Problem Statement and Requirements for 6LoWPAN Mesh Routing (draft-dokaspar-6lowpan-routreq-04)
IETF-71 Philladelphia
Tuesday, March
Dominik Kaspar, Eunsook Kim, Carles Gomez, Carsten Bormann

2. IETF-71 Philadelphia– 6lowpan
Update (-04)
Update in Problem Statement
6LoWPAN routing protocols should support multiple device types and roles.
Handling sleeping nodes is very critical in 6LoWPANs, more than in traditional ad-hoc networks.
A possibly simpler routing problem; 6LoWPANs might be either transit-networks or stub-networks.
A possibly harder routing problem; routing in 6LoWPANs requires to consider power-optimization, harsh environment, data-aware routing, etc. These are not easy requirements to satisfy together
Application-specific features affect the design of 6lowpan routing requirements and the corresponding solutions
IETF-71 Philadelphia– 6lowpan

3. IETF-71 Philadelphia – 6lowpan
Update (-04)
Scenario Considerations are updated
6LoWPAN Communication Models
Flooding (in very small networks)
Data-aware routing (dissemination vs. gathering)
Event-driven vs. query-based routing
Geographic routing
Probabilistic routing
Hierarchical routing
Network properties & Node properties are updated
Node and gateway spatial distribution
Traffic Patterns, Topology and Applications
Transmission Range
IETF-71 Philadelphia – 6lowpan

4. IETF-71 Philadelphia – 6lowpan
Update (-04)
Skeleton has changed
Routing Requirements depending on the 6LoWPAN device types/roles
Routing Requirements depending on types of 6LoWPAN applications
Mesh-under specific requirements
-> MAC coupled requirements
IETF-71 Philadelphia – 6lowpan

5. IETF-71 Philadelphia – 6lowpan
Update (-04)
Role dependent requirements
6LoWPAN routing protocols SHOULD be simple and of low computational complexity
6LoWPAN routing protocols SHOULD have a low routing state.
6LoWPAN routing protocols SHOULD cause minimal power consumption, both in the efficient use of control packet and also in the process of packet forwarding after route establishment.
Neighbor discovery for 6LoWPAN routing SHOULD be energy-efficient.
6LoWPAN routing protocols SHOULD be reliable despite unresponsive nodes.
Application dependent requirements
6LoWPAN routing protocols SHOULD be robust to dynamic loss rates
An important trait of LoWPAN devices is their unreliability due to limited system capabilities, and also because they might be closely coupled to the physical world with all its unpredictable variation(including RSSI and interference variation), noise, and asynchrony.
6LoWPAN routing protocols SHOULD allow for dynamically adaptive topologies and mobile nodes.
6LoWPAN routing protocols SHOULD be scalable
6LoWPAN protocol control messages SHOULD be secured.
IETF-71 Philadelphia – 6lowpan

6. IETF-71 Philadelphia – 6lowpan
Update (-04)
MAC coupled requirements
6LoWPAN routing protocol control messages SHOULD not create fragmentation of physical layer (PHY) frames.
For neighbor discovery, 6LoWPAN devices SHOULD avoid sending "Hello" messages. Instead, link-layer mechanisms (such as acknowledgments or beacon responses) MAY be utilized to keep track of active neighbors.
In order to find energy-optimal routing paths, LoWPAN mesh routing protocols should minimize power consumption by utilizing a combination of the link quality indication (LQI) provided by the MAC layer and other measures, such as hop count. Variability of LQI withtime should be considered.
The procedure of local repair and related control messages should not harm overall energy consumption from the routing protocols. Local repair (when possible) can help reducing loss rates, end-to-end delivery delays, and in successful cases a reduction of control overhead.
IETF-71 Philadelphia – 6lowpan

7. IETF-71 Philadelphia – 6lowpan
Next Step
Will 6LoWPAN do the work for routing requirements?
Good way to cooperate with ROLL work?
What can be the next step of this work?
IETF-71 Philadelphia – 6lowpan