[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-roll-home-routing-reqs

Networking Working Group                                      A. Brandt
Internet Draft                                             Zensys, Inc.
Intended status: Informational                                 G. Porcu
Expires: November 2008                                   Telecom Italia
                                                           May 13, 2008


    Home Automation Routing Requirement in Low Power and Lossy Networks
                  draft-brandt-roll-home-routing-reqs-01


Status of this Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on November 13, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document presents home control and automation application
   specific requirements for ROuting in Low power and Lossy networks
   (ROLL). In a modern home, a high number of wireless devices are used
   for a wide set of purposes. Examples include lighting control,
   heating control, sensors, leak detectors, healthcare systems and
   advanced remote controls. Because such devices only cover a limited



Brandt                Expires November 13, 2008                [Page 1]


Internet-Draft   draft-brandt-roll-home-routing-reqs           May 2008


   radio range, multi-hop routing is often required. The aim of this
   document is to specify the routing requirements for networks
   comprising such constrained devices in a home network environment.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

Table of Contents


   1. Terminology....................................................3
   2. Introduction...................................................3
   3. Home automation applications...................................4
      3.1. Turning off the house when leaving........................4
      3.2. Energy conservation and optimizing energy consumption.....5
      3.3. Moving a remote control around............................5
      3.4. Adding a new lamp module to the system....................5
      3.5. Controlling battery operated window shades................6
      3.6. Remote video surveillance.................................6
      3.7. Healthcare................................................6
         3.7.1. At-home health reporting.............................7
         3.7.2. At-home health monitoring............................7
         3.7.3. Healthcare routing considerations....................8
      3.8. Alarm systems.............................................8
      3.9. Battery-powered devices...................................8
   4. Unique requirements of home automation applications............9
      4.1. Support of groupcast......................................9
      4.2. Metric-based Routing......................................9
      4.3. Support of Mobility......................................10
      4.4. Support of periodical scanning...........................10
      4.5. Scalability..............................................10
      4.6. Convergence Time.........................................11
      4.7. Manageability............................................11
   5. Traffic pattern...............................................11
   6. Open issues...................................................11
   7. Security Considerations.......................................12
   8. IANA Considerations...........................................12
   9. Acknowledgments...............................................12
   10. References...................................................12
      10.1. Normative References....................................12
      10.2. Informative References..................................12
   Author's Addresses...............................................12
   Intellectual Property Statement..................................13
   Disclaimer of Validity...........................................13


Brandt                Expires November 13, 2008                [Page 2]


Internet-Draft   draft-brandt-roll-home-routing-reqs           May 2008



1. Terminology

   ROLL:        ROuting in Low-power and Lossy networks

   Access Point:  The access point is an infrastructure device that
                 connects the low power and lossy network system to the
                 Internet, possibly via a customer premises local area
                 network (LAN).

   LAN:         Local Area Network.

   PAN:         Personal Area Network.
                 A geographically limited wireless network based on
                 e.g. 802.15.4 or Z-Wave radio.

   Channel:      RF frequency band used to transmit a modulated signal
                 carrying packets.

   Downstream:   Data direction traveling from a LAN to a PAN device.

   Upstream:     Data direction traveling from a PAN to a LAN device.

   RF:          Radio Frequency.

   Sensor:      A PAN device that measures data and/or detects an
                 event.

   HA:          Home Automation.



2. Introduction

   This document presents the home control and automation application
   specific requirements for Routing in Low power and Lossy Networks
   (ROLL). In a modern home, a high number of wireless devices are used
   for a wide set of purposes. Examples include lighting control
   modules, heating control panels, light sensors, temperature sensors,
   gas/water leak detectors, motion detectors, video surveillance,
   healthcare systems and advanced remote controls. Basic home control
   modules such as wall switches and plug-in modules may be turned into
   an advanced home automation solution via the use of an IP-enabled
   application responding to events generated by wall switches, motion
   sensors, light sensors, rain sensors, and so on.




Brandt                Expires November 13, 2008                [Page 3]


Internet-Draft   draft-brandt-roll-home-routing-reqs           May 2008


   Because such devices only cover a limited radio range, multi-hop
   routing is often required. These devices are usually highly
   constrained in term of resources such as battery and memory and
   operate in unstable environments. Persons moving around in a house,
   opening or closing a door or starting a microwave oven affect the
   reception of weak radio signals. Reflection and absorption may cause
   a reliable radio link to turn unreliable for a period of time and
   then being reusable again, thus the term "lossy".

   Unlike other categories of PANs, the connected home area is very much
   consumer-oriented. The implications on network nodes in this aspect,
   is that devices are very cost sensitive, which leads to resource-
   constrained environments having slow CPUs and small memory
   footprints. At the same time, nodes have to be physically small which
   puts a limit to the physical size of the battery; and thus, the
   battery capacity. As a result, it is common for low-power sensor-
   style nodes to shut down radio and CPU resources for most of the
   time. Often, the radio uses the same power for listening as for
   transmitting.

   Section 3. describes a few typical use cases for home automation
   applications. Section 4. discusses the routing requirements for
   networks comprising such constrained devices in a home network
   environment. These requirements may be overlapping requirements
   derived from other application-specific requirements documents or as
   listed in [I-D.culler-roll-routing-reqs].

3. Home automation applications

   Home automation applications represent a special segment of networked
   wireless devices with its unique set of requirements. To facilitate
   the requirements discussion in Section 4, this section lists a few
   typical use cases of home automation applications. New applications
   are being developed at a high pace and this section does not mean to
   be exhaustive. Most home automation applications tend to be running
   some kind of command/response protocol. The command may come from
   several places. For instance a lamp may be turned on, not only be a
   wall switch but also from a movement sensor.

3.1. Turning off the house when leaving

   Using the direct analogy to an electronic car key, a house owner may
   activate the "leaving home" function from an electronic house key,
   mobile phone, etc. For the sake of visual impression, all lights
   should turn off at the same time. At least, it should appear to
   happen at the same time. A well-known problem in wireless home
   automation is the "popcorn effect": Lamps are turned on one at a


Brandt                Expires November 13, 2008                [Page 4]


Internet-Draft   draft-brandt-roll-home-routing-reqs           May 2008


   time, at a rate so slow that it is clearly visible. Some existing
   home automation solutions use a clever mix of a "subnet groupcast"
   message with no acknowledgement and no forwarding before sending
   acknowledged singlecast messages to each lighting device.

   The controller forms the groups and decides which nodes should
   receive "turn-off" or "turn-on" requests.

   Thus, a solution is needed for addressing groups of nodes without
   prior management of group membership in the receiving nodes.

3.2. Energy conservation and optimizing energy consumption

   Parts of the world using air conditioning may let shades go down and
   turn off the AC device when leaving home. Air conditioning may start
   by timer or via motion sensor when the owner returns home. The owner
   may even activate the air conditioning via cell phone before getting
   home.

   Geographical areas using central heating may turn off heating when
   not at home and use a reduced temperature during night time.

   The power grid may experience periods where more wind-generated power
   is produced than is needed. Typically this may happen during night
   hours. The washing machine and dish washer may just as well work
   while power is cheap. The electric car should also charge its
   batteries on cheap power.

   Most of these applications are mains powered and may thus provide
   reliable routing resources.

3.3. Moving a remote control around

   A remote control is a typical example of a mobile device in a home
   automation network. An advanced remote control may be used for
   dimming the light in the dining room while eating and later on,
   turning up the music while doing the dishes in the kitchen. Reaction
   must appear to be instant (within a few hundred milliseconds) even
   when the remote control has moved to a new location. The remote
   control may be communicating to either a central home automation
   controller or directly to the lamps and the media center.

3.4. Adding a new lamp module to the system

   Small-size, low-cost modules may have no user interface except for a
   single button. Thus, an automated inclusion process is needed for
   controllers to find new modules. Inclusion covers the detection of


Brandt                Expires November 13, 2008                [Page 5]


Internet-Draft   draft-brandt-roll-home-routing-reqs           May 2008


   neighbors and assignment of a unique node ID. Inclusion should be
   completed within a few seconds.

3.5. Controlling battery operated window shades

   In consumer premises, window shades are often battery-powered as
   there is no access to mains power over the windows. For battery
   conservation purposes, the receiver is sleeping most of the time. A
   home automation controller sending commands to window shades via ROLL
   resources will have no problems delivering the packet to the router,
   but the router will have to wait for some time before the command can
   be delivered to the window shades; e.g. up to 250ms.

3.6. Remote video surveillance

   Remote video surveillance is a fairly classic application for Home
   networking providing the ability for the end user to get a video
   stream from a Web Cam reached via the Internet, which can be
   triggered by the end-user that has received an alarm from a movement
   sensor or smoke detector - or the user simply wants to check the home
   status via video.
   Note that in the former case, more than likely, there will be a form
   of inter-device communication: indeed, upon detecting some movement
   in the home, the movement sensor may send a request to the light
   controller to turn-on the lights, to the Web Cam to start a video
   stream that would then be directed to the end user (cell phone, PDA)
   via the Internet.
   By contrast with other applications, e.g. industrial sensors where
   data would mainly be originated by sensor to a sink and vice versa,
   this scenario implicates a direct inter-device communication between
   ROLL devices.

3.7. Healthcare

   By adding communication capability to devices, patients and elderly
   citizens may be able to do simple measurements at home. Thanks to
   online devices, a doctor can keep an eye on the patient's health and
   receive warnings if a new trend is discovered by automated filters.

   Fine-grained daily measurements presented in proper ways may allow
   the doctor to establish a more precise diagnosis.

   Such applications may be realized as wearable products which
   frequently do a measurement and automatically deliver the result to a
   data sink locally or over the Internet.




Brandt                Expires November 13, 2008                [Page 6]


Internet-Draft   draft-brandt-roll-home-routing-reqs           May 2008


   Applications falling in this category are referred to as at-home
   health reporting. Whether measurements are done in a fixed interval
   or if they are manually activated, they leave all processing to the
   receiving data sink.

   A more active category of applications may send an alarm if some
   alarm condition is triggered. This category of applications is
   referred to as at-home health monitoring. Measurements are
   interpreted in the device and may cause reporting of an event if an
   alarm is triggered.

   Many implementations may overlap both categories.

3.7.1. At-home health reporting

   Applications might include:

   o  Temperature

   o  Weight

   o  Blood pressure

   o  Insulin level

   Measurements may be stored for long term statistics. At the same
   time, a critically high blood pressure may cause the generation of an
   alarm report. Refer to 3.7.2.

   To avoid a high number of request messages, nodes may be configured
   to autonomously do a measurement and send a report in intervals.

3.7.2. At-home health monitoring

   An alarm event may become active e.g. if the measured blood pressure
   exceeds a threshold or if a person falls to the ground.

   Applications might include:

   o  Temperature

   o  Weight

   o  Blood pressure

   o  Insulin level



Brandt                Expires November 13, 2008                [Page 7]


Internet-Draft   draft-brandt-roll-home-routing-reqs           May 2008


   o  ECG

   o  Position tracker

3.7.3. Healthcare routing considerations

   From a ROLL perspective, all the above-mentioned applications may run
   on battery. They may also be portable and therefore need to locate a
   new neighbor router on a frequent basis.
   Not being powered most of the time, the nodes should not be used as
   routing nodes. However, sleeping, battery-powered nodes may be
   involved in routing. Examples include cases where a person falls
   during a power blackout. In that case it may be that no mains-powered
   routers are available for forwarding the alarm message to a (battery-
   backed) internet gateway located out of direct range.

   Delivery of measurement data has a more relaxed requirement for route
   discovery time compared to a remote control. On the other hand, it is
   critical that a "person fell" alarm is actually delivered in the end.

3.8. Alarm systems

   A home security alarm system is comprised of various devices like
   vibration detectors, fire or carbon monoxide detection system, door
   or window contacts, glass-break detector, presence sensor, panic
   button, home security key.

   Some smoke alarms are battery powered and at the same time mounted in
   a high place. Battery-powered safety devices should only be used for
   routing if no other alternatives exist. A smoke alarm with a drained
   battery does not provide a lot of safety. Also, it may be
   inconvenient to exchange battery in a smoke alarm. Finally, routing
   via battery-powered nodes may be very slow if they are sleeping most
   of the time.
   All of the above-mentioned reasons suggest that routing should be
   avoided via this category of devices.

   A plethora of applications could be developed for home alarm system:
   most of them, most of the time, have prevention and monitoring
   activity in which routing requirements are deterministic, but all of
   them have an alarm state in which nodes may burst an aperiodic alarm.

3.9. Battery-powered devices

   For convenience and low operational costs, power consumption of
   consumer products must be kept at a very low level to achieve a long
   battery lifetime. One implication of this fact is that RAM memory is


Brandt                Expires November 13, 2008                [Page 8]


Internet-Draft   draft-brandt-roll-home-routing-reqs           May 2008


   limited and it may even be powered down; leaving only a few 100 bytes
   alive during the sleep phase.

4. Unique requirements of home automation applications

   Home automation applications have a number of specific requirements
   related to the set of home networking applications and the perceived
   operation of the system.

4.1. Support of groupcast

   The routing protocol must provide the ability to route a packet
   towards a single device (unicast), a set of devices (also referred to
   as "groupcast" in this document) or all devices (broadcast) in the
   house.

   The support of unicast, groupcast and broadcast also has an
   implication on the addressing scheme and are outside the scope of
   this document that focuses on the routing requirements aspects.

   It MUST be to possible to address a group of receivers known by the
   sender even if the receivers do not know that they have been grouped
   by the sender.

   Alternatively, a companion specification SHOULD define how to
   indirectly address a group of nodes on the application layer via
   classic broadcast in the network layer; e.g. by use of a bitmap in a
   header extension.

4.2. Metric-based Routing

   [ABR NOTE: IETF-71 WG meeting indicated that the term "constrained"
   has a very specific meaning in the routing community inside IETF.
   What I understood was that the draft should be using the term
   "metric-based routing"]

   Simple battery-powered nodes such as movement sensors on garage doors
   and rain meters may not be able to assist in routing. Depending on
   the node type, the node never listens at all, listens rarely or makes
   contact on demand to a pre-configured target node. Attempting to
   communicate to such nodes may require long time before getting a
   response.

   Other battery-powered nodes may have the capability to participate in
   routing. The routing protocol should either share the load between
   nodes to preserve battery or only route via mains-powered nodes if



Brandt                Expires November 13, 2008                [Page 9]


Internet-Draft   draft-brandt-roll-home-routing-reqs           May 2008


   possible. The most reliable routing resource may be a battery-backed,
   mains-powered smoke alarm.

   The routing protocol MUST support metric-based routing taking into
   account node properties (CPU, memory, level of energy, sleep
   intervals, safety/convenience of changing battery).

4.3. Support of Mobility

   In a home environment, although the majority of devices are fixed
   devices, there is still a variety of mobile devices: for example a
   multi-purpose remote control is likely to move. Another example of
   mobile devices is wearable healthcare devices.

   While healthcare devices delivering measurement results can tolerate
   route discovery times measured in seconds, a remote control appears
   unresponsive if using more than 0.5 seconds to e.g. pause the music.

   While, in theory, all battery-powered devices and mains-powered plug-
   in modules may be moved, the predominant case is that the sending
   node has moved while the rest of the network has not changed.

   The routing protocol MUST provide mobility with convergence time
   below 0.5 second if only the sender has moved.

   The routing protocol SHOULD make use of the fact that if not being
   able to deliver a packet, it is most likely that the sending node
   moved; rather than the rest of the network.

4.4. Support of periodical scanning

   The routing protocol MUST support the recognition of neighbors and
   periodical scanning. This process SHOULD preserve energy capacity as
   much as possible.

   (Derived from use case 3.8. Alarm Systems)

4.5. Scalability

   Looking at the number of wall switches, power outlets, sensors of
   various nature, video equipment and so on in a modern house, it seems
   quite realistic that hundreds of low power devices may form a home
   automation network in a fully populated "smart" home. Moving towards
   professional building automation, the number of such devices may be
   in the order of several thousands.




Brandt                Expires November 13, 2008               [Page 10]


Internet-Draft   draft-brandt-roll-home-routing-reqs           May 2008


   Thus, the routing protocol MUST support 250 devices in a subnet.
   The routing protocol SHOULD support 2500 devices in a subnet.

4.6. Convergence Time

   A home automation PAN is subject to various instability due to signal
   strength variation, moving persons and the like. Furthermore, as the
   number of devices increases, the probability of a node failure also
   increases.

   Measured from the transmission of a packet, the following convergence
   time requirements apply.

   The routing protocol MUST converge within 0.5 second if no nodes have
   moved.

   The routing protocol MUST converge within 2 seconds if the
   destination node of the packet has moved.

4.7. Manageability

   The ability of the home network to support auto-configuration is of
   the utmost importance. Indeed, most end users will not have the
   expertise and the skills to perform advanced configuration and
   troubleshooting. Thus the routing protocol designed for home PAN MUST
   provide a set of features including 0 configuration of the routing
   protocol for a new node to be added to the network.

   Furthermore, a failing node MUST NOT have a global impact on the
   routing protocol. The routing protocol SHOULD support the ability to
   isolate a misbehaving node thus preserving the correct operation of
   overall network.

5. Traffic pattern

   Depending on the philosophy of the home network, wall switches may be
   configured to directly control individual lamps or alternatively, all
   wall switches send control commands to a central lighting control
   computer which again sends out control commands to relevant devices.

   In a distributed system, the traffic tends to be any-to-many. In a
   centralized system, it is a mix of any-to-one and one-to-many.

6. Open issues

   Other items to be addressed in further revisions of this document
   include:


Brandt                Expires November 13, 2008               [Page 11]


Internet-Draft   draft-brandt-roll-home-routing-reqs           May 2008


   o  Load Balancing (Symmetrical and Asymmetrical)

   o  Security



7. Security Considerations

   TBD

8. IANA Considerations

   This document includes no request to IANA.

9. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.



10. References

10.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2. Informative References

   [I-D.culler-roll-routing-reqs]
             Vasseur, J. and D. Culler, "Routing Requirements for Low
             Power And Lossy Networks",
             draft-culler-roll-routing-reqs-* (work in progress).

Author's Addresses

   Anders Brandt
   Zensys, Inc.
   Emdrupvej 26
   Copenhagen, DK-2100
   Denmark

   Email: abr@zen-sys.com






Brandt                Expires November 13, 2008               [Page 12]


Internet-Draft   draft-brandt-roll-home-routing-reqs           May 2008


   Giorgio Porcu
   Telecom Italia
   Piazza degli Affari, 2
   20123 Milan
   Italy

   Email: giorgio.porcu@telecomitalia.it


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The IETF Trust (2008).



Brandt                Expires November 13, 2008               [Page 13]


Internet-Draft   draft-brandt-roll-home-routing-reqs           May 2008


   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.









































Brandt                Expires November 13, 2008               [Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/