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]