1 / 10

Home Control in a consumer’s perspective

This paper discusses the challenges of limited integration and competition in home control systems, the importance of a common platform, and the steps required for migration towards interoperability. It also examines the requirements for a discovery protocol and backbone routing in IoT.

cmeeks
Download Presentation

Home Control in a consumer’s perspective

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IETF-80, Prague, Internet of Things Workshop March 2011 Home Control in aconsumer’s perspective www.iab.org/about/workshops /smartobjects/papers/Brandt.pdf Anders Brandt Sigma Designs abr@sdesigns.dk

  2. Today • Many application protocols • BACnet, DALI, LonWorks, Z-Wave,HomePlug, Zigbee, ... • Millions of devices installed • Limited integration • Available product range: one standard only • Many ”silos”: HVAC, fire alarms, ... • Limited competition  Higher cost • High cost  Limited market growth • ....

  3. Zigbee commands HomePlug commands Z-Wavecommands BACnet commands Z-Wave BACnet HomePlug Zigbee Today, Cont’d • Application protocol transport over IP • One network  Simpler installation and managementStill no interoperability between protocols.

  4. One common platform? • What if • resources could be discovered across subnets? • legacy protocols could interoperate? • IP really supported battery operated nodes? • Are we looking for • a one fits all solution? • support for any device in the world? • 85% support for 85% of devices?

  5. How to migrate? • Incremental steps • Legacy protocol over IP (UDP encapsulation) • Add IP connectivity to devices that werenever built for IP networking (=> gateways) • Add discovery functionality (to gateways) • Introduce native devices built for discoveryand an interoperable protocol • Vendor-specific advanced features?

  6. What is required? • A discovery protocol to advertize • Local resources  (CoAP, mDNS, etc.) • Resources in other subnets • Legacy devices in other subnets • Sleeping nodes • e.g. Temperature sensors and door locks.

  7. What is required? • A discovery protocol that • Does not rely on multicast • MAY use multicast if supported by a subnet • Does not flood LLN style networks with traffic • Most discoverable properties are static • One candidate: • draft-brandt-coap-subnet-discovery.

  8. What is required? • Application compatibility:M2M style command sets • Short, strictly defined paths, e.g. • /m2m/light/type [enum switch, dimmer] • /m2m/light/level [int 0..100] • ”Sufficient” subset • Not trying to cover all functionality of all standards • Input needed from industry alliances

  9. What is required? • Backbone routing by default • (What happened to HomeGate?) • IP battery support: • ICMP ”Destination Responding Slowly” • IP host sends ”Set temp threshold = x” • Border router resolves destination address tonode_type == sleeping • Router returns ICMP ”Destination Responding Slowly” • IP host increases application ack timeout value application command is not retransmitted n times

  10. IETF-80, Prague, Internet of Things Workshop March 2011 Thank You www.iab.org/about/workshops /smartobjects/papers/Brandt.pdf Anders Brandt Sigma Designs abr@sdesigns.dk

More Related