[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05                                             
CoRE                                                     P. van der Stok
Internet-Draft                                          Philips Research
Expires: January 5, 2011                                    July 4, 2010


                 CoAP utilisation for building control
                      draft-vanderstok-core-bc-00

Abstract

   This draft describes an example use of the RESTful CoAP protocol to
   control equipment in buildings such as HVAC and lighting.  A few
   basic design assumptions are stated first.  The uri structure is
   exploited to define multicast scopes.  RFC 3986 divides the uri in
   (1) a scheme, (2) an authority part, used here to locate the building
   under control, (3) a path, used here to locate the resource under
   control, and (4) a query and fragment part, only the query part is
   discussed in the context of service discovery.  This I-D supports the
   view that (1) building control will move in steps towards all-IP
   control networks building on the legacy efforts provided by DALI,
   LON, BACnet, ZigBee and other standards, and (2) the provision of a
   reliable group communication protocol is essential.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 5, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



van der Stok             Expires January 5, 2011                [Page 1]


Internet-Draft    CoAP utilisation for building control        July 2010


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.


Table of Contents

   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  URI structure  . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Authority part . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Path part  . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Group Addressing . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Payload examples . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Service discovery  . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Security considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 15
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
































van der Stok             Expires January 5, 2011                [Page 2]


Internet-Draft    CoAP utilisation for building control        July 2010


1.  Motivation

   The CoAP protocol [IDcoap] aims at providing a user application
   protocol architecture which is targeted to a network of nodes with a
   low resource provision such as memory, CPU capacity and energy.
   Although in general, IT application manufacturers strive to provide
   the highest possible functionality and quality for a given price, in
   building control, manufacturers tend to compete by delivering a given
   functionality and quality for the lowest price.  A low resource
   budget reduces the price of the nodes and a large effort is spent on
   reducing the message length.  This approach is reinforced by the
   required low energy consumption by battery-less nodes.  Reduction of
   the packet size is obtained by using the header reduction of 6lowpan
   and encouraging small payloads.  Constraints on the message contents
   are imposed by the long history of control in the building which has
   led to the development of much legacy knowledge and applications.
   Reuse of this knowledge will stimulate the introduction of all-IP
   control within the buildings.  This draft aims at an approach in
   which the payload can be built on existing control standards, and
   future new standards to emerge.  The syntax of the control messages
   is specified in the standard (e.g.  BACNet, LON, DALI, KNX, etc.).
   The description of the services is based on the same standard.
   Consequently, the syntax of the service discovery messages, partially
   expressed in the uri, is related to the chosen legacy control
   standard.  From the above the basic syntax assumptions can be
   summarized as:

   -  Generate small payloads

   -  Compatible with legacy standards (e.g.  LON, BACnet, DALI, ZigBee
      Device Objects)

   -  Service discovery in agreement with legacy standards and uri
      conventions.

   Of prime importance in building control (at least lighting and HVAC)
   is the concept of a group.  Many control messages are multicast from
   one device to a group of devices (e.g. from light switch to all
   lights in a room).  The scope of a multicast or a service discovery
   message depends upon the group of nodes that is targeted.
   Determining multicast scopes on the basis of hop count or the
   existence of edge routers is not always sufficient in buildings where
   the network architecture may be independent of the controlled areas
   (e.g. rooms) in the building.  Consequently, additional protocol
   oriented assumptions are:






van der Stok             Expires January 5, 2011                [Page 3]


Internet-Draft    CoAP utilisation for building control        July 2010


   -  A syntactic definition of the multicast scope applicable to all
      multicasts in the building

   -  Pervasive existence of groups of resources

   For clarity, this I-D limits itself to two types of applications: (1)
   M2M control applications running within a building area without any
   human intervention after start-up of a given network segment and (2)
   maintenance oriented applications where data are collected from node
   in several building areas to nodes inside or outside the building,
   and humans may intervene to change control settings.








































van der Stok             Expires January 5, 2011                [Page 4]


Internet-Draft    CoAP utilisation for building control        July 2010


2.  URI structure

   This I-D looks at three aspects of the uri: scheme, authority, and
   path.  The scheme is assumed to be set to coap.  The authority is
   defined within the context of the standard internet naming, while the
   path is valid in relation to a given DNS addressing unit.  An example
   from RFC 3986 [RFC3986] is:
   foo://example.com:8042/over/there?name=ferret#nose, where "foo" is
   the scheme, "example.com:8042" is the authority, "/over/there" is the
   path, "name=ferret" is the query, and "nose" is the fragment.
   Fragments are not supported in CoAP.

2.1.  Authority part

   A building can be unambiguously be addressed by it GPS coordinates or
   more functionally its zip/post code.  For example the Dutch Internet
   provider, KPN, assigns to each subscriber a name based on its
   postcode.  Analogously, an example authority for a building can be
   given by: //bldg.zipcode_localnr.Country/ or more concretely an
   imaginary address in the Netherlands as: //bldg.5533BA_125a.nl/.  The
   bldg prefix can identify building control oriented IP network
   traffic.  Arriving at the node identified with 5533BA_125a.nl, the
   receiving service can parse the rest of the uri and send the message
   on to the specified resource (node).  Other naming schemes are
   possible and can be freely used.  The authority structure looks more
   than adequate to address the specified building and its control
   nodes.  No additional work is required to standardize its syntax.

2.2.  Path part

   Buildings have a structure dependent on their size and function.
   This ranges from a single hall without any structure to a complex
   building with floors, wings, offices and possibly a structure within
   individual rooms.  The naming of the building control equipment and
   the actual control strategy are intimately linked to the building
   structure.  It is therefore convenient to name the equipment with
   their location within the building.  Consequently, the path part of
   the uri identifying a piece of equipment is expressed in the building
   structure.  An example is: wing/floor/office/left_hand_corner.

   Within the building, devices communicate with each other.  Often a
   device needs to communicate to all devices of a given type within a
   given area of the building.  For example a light switch addresses all
   lights within a given corridor, or a heating unit accesses all
   radiator actuators on a floor.  Although intuitively easy to
   understand the relative location is verbose and needs much contextual
   knowledge within a device.  For example a switch located at room
   25b006 of floor one, expressed as: //bldg.5533BA_125a.nl/floor1/



van der Stok             Expires January 5, 2011                [Page 5]


Internet-Draft    CoAP utilisation for building control        July 2010


   25b006/, can specify a command to light_1 within the same room with
   //bldg.5533BA_125a.nl/floor1/25b006/light_1.  This approach seems to
   lead to rather verbose uri strings in the packet contrary to the
   small packet assumption.  Working out a control application later in
   the text, shows that the uri disappears largely from the packet.
   Question exists whether the syntax of a path needs to be standardized
   for building control.  Given the examples later in the text, this
   does not seem to be necessary.











































van der Stok             Expires January 5, 2011                [Page 6]


Internet-Draft    CoAP utilisation for building control        July 2010


3.  Group Addressing

   As already suggested by the examples above the uri is intimately
   associated with the scope of the messages.  This provides a better
   handle to define the multicast scope than the traditional TTL counter
   preventing the multicast message to pass one or more routers.  This
   more sophisticated scoping mechanism is needed to separate the
   network layout from the multicast scopes.  This is also witnessed by
   all the work done by the BACnet over IP standardization to define the
   scope of the service discovery messages.

   Given a network configuration and associated prefixes, the network
   operator needs to define an appropriate set of multicast groups which
   can be mapped to the building areas.  Knowledge about the
   hierarchical structure of the building areas may assist in defining a
   network architecture which encourages an efficient multicast
   implementation.  Example multicast groups become:

      /path         targeted group

      /             "the whole building"

      /floor1       "all nodes on floor1"

      /wing3        "all nodes in wing 3"

      /floor1/wing2 "all nodes belonging to wing 2 at floor 1"

      /floor2/bu036 "all nodes belonging to office bu036 at floor 2"

   Preferably these multicast groups are created automatically.  Their
   automatic creation is out of the scope of this I-D.  This concept can
   be refined by defining, like done for DALI, scenes within the context
   of a floor or a single office.  For example the setting of all blue
   lights in office bu036 of floor 2 can be realized by sending a
   message to the multicast group "/floor2/bu036/blue-lights".  All
   multicast groups are associated with one IP address, similar to the
   individual nodes in a building area.  Consequently, when the
   application specifies the sending of an "on" message to all blue
   lights in the office, the message is multicast to the associated IP
   address and a large part of the uri can be removed from the message.

   The large number of multicast addresses looks difficult to handle.
   The suggestion is made that the nodes and not the services are part
   of a multicast group.  That means that all services on a given node
   belong to the same multicast addresses to which the node belongs.
   The number of multicast groups to which a given node belongs is then
   possibly limited to 10.  For example the node belonging to the "blue



van der Stok             Expires January 5, 2011                [Page 7]


Internet-Draft    CoAP utilisation for building control        July 2010


   lights" group in a given corridor will also belong to the groups:
   "whole building", "given floor", "given wing", "given corridor",
   "lights in given corridor", and "blue lights in given corridor".

   The path can be used to define the groups and associated multicast
   scopes.  Naming is building dependent and does not need extra
   standardization efforts.  In the context of an administrated
   professional building, groups can be defined off-line and stored in
   configuration files referred to by the DHCP server.  In the
   information file participation to all groups is stored.  In the
   context of the home, groups are named on-line by the tenant, possibly
   storing the group names and members in files for later personnel
   reference.  A reliable group communication (multicast) is essential
   for an efficient building control application.





































van der Stok             Expires January 5, 2011                [Page 8]


Internet-Draft    CoAP utilisation for building control        July 2010


4.  Payload examples

   Every node with a network address is completely identified with uri
   structure //authority/path.  The next part of the uri is composed of
   resource identification and function specification.  The names of
   device types and their associated attributes are typically a subject
   for standardization.  For example there is no standard for naming
   building control devices unambigously in a uri.  When a GET with an
   uri like: /floor1/25b006/t-sensor1/temperature is sent, the
   underlying assumption is that the resource with name t-sensor1 of a
   given standard type (e.g. temperture sensor) exists and that this
   standard type has the readable attribute: temperature.  It is
   unlikely that such a building control wide standard will appear
   within a short time from now.  Consequently, the first use of CoAP in
   building control must rely on naming standards which exist today.  It
   is assumed that devices exchange messages with a content defined by
   one of the already existing building control standards e.g.  BACnet,
   LON, DALI, ZigBee Device Objects (ZDO), KNX, and others.  All these
   standards know the concepts of type (class) and type (class)
   instances.  Within a given type a number of attributes exists which
   can be modified or read with a more or less complex invocation
   syntax.  This draft proposes that the functional part of the uri
   first describes the standard and then continues with a standard
   dependent syntax, to be defined by the standardization committee
   interested to conform to CoAP.  For example a command to a heating
   unit with a BACnet interface can be expressed with //authority/path/
   resource/BACnet/BACnet_defined_command or a command to a DALI light
   can be expressed with //authority/path/resource/DALI/
   DALI_defined_command.  For example the request: PUT /floor1/bu036/
   light1/DALI/30lumen , assuming that light1 is a DALI device,
   translates to CoAP header [IDcoap]:

   -  dest IP address defined by: /floor1/bu036/light1

   -  T bits to 0: Confirmable message

   -  Code = 2: PUT method

   -  OC bits set to 1 (for one Mime option)

   -  Transaction ID set

   -  Option type= 5, content type: /application/DALI

   -  DALI command: set intensity to 30 lumen

   The new option sub type shows that new application mime types need to
   be defined to cover the building control standards: e.g.



van der Stok             Expires January 5, 2011                [Page 9]


Internet-Draft    CoAP utilisation for building control        July 2010


   /application/DALI, /application/BACnet, etc.

   Examples of wireless, battery-less nodes are sensors used for
   measuring presence, temperature, light intensity, or humidity.
   Battery-less means that the nodes are switched off most of the time
   and sporadically power up and send out their current measured value.
   This value is either sent to a controller node or to a group of
   actuator nodes.  Examples are presence detection sent to lamps, or
   humidity level to a fan.  The destination nodes of the measurements
   are probably powered by the mains or a derivative of the mains.  It
   seems unrealistic to have the controller or the actuator nodes send
   request messages to the batteryless nodes, after which the sender has
   to wait an interval determined by the operation of the sender.  More
   natural is that the batteryless node wakes up and sends its message
   to controller or actuator nodes which are always ready to receive a
   message.  For example, without controller node, the presence detector
   can send presence regularly to a group of lights.  The group can be
   defined on-line, by having the lights subscribe to the presence
   service, or the group can be defined off-line by the manager of the
   control network.  On-line definition is more natural in a dynamic
   home environment, while off-line is more natural in the office
   environment.  Off-line has the added advantage of checking on missing
   nodes.  For subscription the subscribing nodes have to learn the IP
   address(es) of the service(s) to which they want to subscribe.  In
   case of off-line the servers have to learn the IP address of the
   multicast group.  The latter can be learnt from DHCP options, by
   inserting the destination IP address inside the configuration file of
   the battery-less node.

   The CoAP protocol foresees the use of a non confirmable message
   packet to send these unsolicited responses to the multicast group or
   the single controller.  Again the syntax of the commands are most
   likely defined by legacy standards.  Assuming the DALI standard, the
   command PUT /floor2/bu036/blue-lights/DALI/on leads to the following
   packet lay-out:

   -  dest multicast IP address defined by: /floor1/bu036/blue lights

   -  T bits to 1: Non Confirmable message

   -  Code = 2, PUT method

   -  OC bits set to 1 (for one Mime option)

   -  Transaction ID set, for prevention of double messages






van der Stok             Expires January 5, 2011               [Page 10]


Internet-Draft    CoAP utilisation for building control        July 2010


   -  Option type= 5, content type: /application/DALI

   -  DALI command: switch ON
















































van der Stok             Expires January 5, 2011               [Page 11]


Internet-Draft    CoAP utilisation for building control        July 2010


5.  Service discovery

   Service discovery is intimately linked to the building structure.
   When for example a lamp wants to discover the controller, it is only
   interested in the controllers sitting in the same office (area) as
   itself.  Consequently, the service discovery is related to the groups
   defined according to the building structure.  It is advisable to send
   a discovery message to a given group.  Also the packet does not need
   the complete uri in the uri option.  In conformace with RFC 5785
   [RFC5785], a packet from a controller with the request to return the
   device types of all DALI devices within the office bu036 can look
   like:

   -  dest multicast IP address defined by: /floor1/bu036/

   -  T bits to 0: Confirmable messages

   -  Code 0: GET method

   -  OC bits set to 2 (for Mime and URI option)

   -  Transaction ID set

   -  Option type= 1, LEN=21, "/well-known/resources"

   -  Option type= 5, content type: /application/DALI

   -  DALI command: "return device type"

   The responses from the DALI nodes may look like:

   -  dest IP address of controller

   -  T bits to 2: Acknowledgement messages

   -  CODE = 0, OK

   -  OC bits set to 1 (for Mime option)

   -  Transaction ID identical

   -  Option type= 5, content type: /application/DALI

   -  DALI command: "type = Lamp"

   The rest of the protocol is dictated by the legacy standard in use
   but encapsulated within the CoAP discovery messages as shown above.




van der Stok             Expires January 5, 2011               [Page 12]


Internet-Draft    CoAP utilisation for building control        July 2010


   To promote a step-wise introduction of CoAP, the suggestion is to
   separate the service discovery protocol messages from the service
   description syntax.  The same CoAP protocol messages can be exchanged
   between nodes, but the description syntax (e.g. xmi, ZDO, or BACnet)
   is left free.  Assuming a building control standard BS.  The goal is
   to exchange the BS messages sent by the service discovery BS client
   with CoAP messages as described above.  At the CoAP server, the BS
   message is passed on to the BS server.  The result from the BS server
   is packed in a CoAP packet as described above and returned to the BS
   client.

   The second step of CoAP introduction uniformizes the sevice discovery
   clients for interested BS's.  Additional standardization effort is
   needed to provide all functionality supported by all existing
   standards.  For example not all service discovery protocols support
   the option to return answers from a given type of resource only.
   Such a general extension can be expressed with the transported uri
   /well-known/resources/?resource=X. A benefit of such standardisation
   of discovery queries over all legacy standards is that the legacy
   standards may enjoy additional facilities like resource directories,
   which enhance the scalability of the service discovery protocol.  The
   I-D explains how buidling control is based on a hierachical structure
   of the building areas, and that control message scope and discovery
   message scope are defined by this building structure.  It is shown
   that the uri can express this structure but does not need
   standardization.  Also larger parts of the complete uri does not need
   to be transported in the message but is expressed as a Multicast or
   Unicast IP address in the IP header.  It is shown that it is possible
   to transport legacy commands (.e.g. expressed in BACnet, LON, DALI,
   ZigBee, etc.) inside CoAP message structure.  This necessitates the
   definition of additional IANA mime codes, and the mapping of legacy
   specific service discovery semantics to CoAP service discovery
   messages.

   It is expected that many control messages are sent by battery-less
   sensors with their own specific sending intervals to a group of
   actuator nodes or controllers.  Given the importance of groups and
   associated multicast messages, the specification of a reliable
   multicast protocol with related multicast scope is needed.












van der Stok             Expires January 5, 2011               [Page 13]


Internet-Draft    CoAP utilisation for building control        July 2010


6.  Security considerations

   Based on the programming model presented in this I-D, security
   scenarios for building control need to be stated.  Appropriate
   methods to counteract the proposed threats can be based on the work
   done elsewhere, for example in the ZigBee over IP context.













































van der Stok             Expires January 5, 2011               [Page 14]


Internet-Draft    CoAP utilisation for building control        July 2010


7.  IANA considerations

   This I-D proposes the following additions to the Media type
   identifiers in conformance with the proposals done in [IDcoap].

                      Internet media type       code

                      /application/BACnet       xx

                      /application/DALI         xx+1

                      /application/ZDO          xx+2

                      /application/LON          xx+3

                      /application/KNX          xx+4

                      /application/exi/building xx+5

                      /application/exi/metering xx+6































van der Stok             Expires January 5, 2011               [Page 15]


Internet-Draft    CoAP utilisation for building control        July 2010


8.  Acknowledgements

   This I-D has benefited from conversations with and comments from
   Kerry Lynn, Andrew Tokmakoff, Emmanuel Frimout, Jamie Mc Cormack,
   Oscar Garcia, Dee Denteneer, Joop Talstra, Gerald Martocci, and .














































van der Stok             Expires January 5, 2011               [Page 16]


Internet-Draft    CoAP utilisation for building control        July 2010


9.  References

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 3986,
              January 2005.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              April 2010.

   [IDcoap]   Shelby, Z., Frank, B., and D. Sturek, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-01pre5
              (work in progress), June 2010.

   [BACnet]   xx, Z., "BACnet over IP", June 1998.

   [ZigBee]   xx, Z., "ZigBee device objects over IP", June 2009.

   [LON]      xx, Z., "LON objects", June 1990.
































van der Stok             Expires January 5, 2011               [Page 17]


Internet-Draft    CoAP utilisation for building control        July 2010


Author's Address

   Peter van der Stok
   Philips Research
   High Tech Campus
   Eindhoven,   5656 AA
   Netherlands

   Email: peter.van.der.stok@philips.com
   URI:   http://www.research.philips.com/









































van der Stok             Expires January 5, 2011               [Page 18]