V0.2ROLL Routing Requirements; The connected home1 Anders Brandt March 2008.

V0.2 ROLL Routing Requirements; The connected home 1

ROLL

Routing Requirements;The connected home

Anders Brandt March 2008


The connected home

• A world of Buzzwords...– Home Control or– Home Automation or– Intelligent Home or– Smart House or– ...

(pick one)


The connected home


Entering a room


Entering a room, v.2


Leaving home

OFF OFF

OFF

OFF

OFF

OFF


Leaving home, Cont’d

• ”Turn off group”– User experience matters

• Lamps must (appear to) react at the same time• Visible lamps typically within direct range =>

1. Address group unacknowledged

2. Address individual nodes to ensure new state

– IP Multicast is not the solution• IP Multicast requires subscription from targets• Groupcast is needed (bitmap addressing in

subnet)


Moving nodes• Media center is

within direct range of remote control


Moving nodes, Cont’d• Media center is

within direct range of remote control

• Now the user walks to the kitchen...


Moving nodes, Cont’d• Remote control

is out of range


Moving nodes, Cont’d• Remote control

must find available ”routers”


Moving nodes, Cont’d• ”Router” is

used to talk to media center


Devices in the home

• Lamp module

• Switch module

• Movement sensor

• Smoke alarm

• Remote control


Devices in the home, Cont’d

• Lamp module &Switch module– Static location– Always on– Distributed all over the house– Obvious routing resources

(battery backup is rare)


Devices in the home, Cont’d• Movement sensor &

Smoke alarm– Battery-operated– Mounted in inconvenient places– Important to safety– Battery lifetime optimized via 99%+ sleep mode– Requesting remaining battery is difficult

• Node only listens rarely

– Routing should be avoided


Devices in the home, Cont’d• Remote control

– Battery-operated– Mobile– Only wakes up when operated (or moved)– May have to remember several gateways

– Not attractive as routing resource


draft-brandt-roll-home-routing-reqs

• Application use cases

• Specific routing requirements forthe connected Home

• A comment on traffic patterns



• Support for multiple paths. Nodes may be– failing– powered off– moved

• Ability to locate a working path within 250ms

• Neighbor discovery must be smart or frequent– Consumers move nodes at will ...



• ”Groupcast”– Ability to address a set of devices, e.g. lamps– Reveiving nodes are grouped by the sender

(IP multicast receivers join a group individually)

Bug: ”all devices (multicast)” – should read “all devices (broadcast)”



• Constrained routing– Routing must respect node limitations

• CPU speed• Memory size• Battery capacity• Sleep intervals• Safety

(Do not drain the battery of a smoke alarm)

• convenience of changing battery(Do not drain the battery of a ceiling-mounted sensor)



• Scalability and traffic patterns– Support 200+ nodes in a subnet

(Many sensors/light devices in a future home)

– Large systems structured into many subnets• (Cabled) backbone• Managability• Security• Isolating problems

(all the usual IP reasons)



• Traffic patterns– Central lighting control

• any-to-one + one-to-many(all switches talk to the central controller. Controller controls light)

– Distributed mesh system• any-to-many

(many controllers/switches control light devices directly)


Anders Brandt [email protected]

Conclusion

• Unique requirements to routing

• Real applications - it is out there already...

• Should be considered in protocol studies

• Comments are welcome on the list

V0.2ROLL Routing Requirements; The connected home1 Anders Brandt March 2008.

Documents

Transcript of V0.2ROLL Routing Requirements; The connected home1 Anders Brandt March 2008.