| CoRE | P.D.V. van der Stok |
| Internet-Draft | Philips Research |
| Intended status: Informational | K.E. Lynn |
| Expires: January 12, 2012 | Consultant |
| July 11, 2011 |
CoAP Utilization for Building Control
draft-vanderstok-core-bc-04
This draft describes an example use of the RESTful CoAP protocol for building automation and control (BAC) applications such as HVAC and lighting. A few basic design assumptions are stated first, then URI structure is utilized to define group as well as unicast scope for RESTful operations.
The authority portion of the URI is used to identify a device (group) and the resulting DNS name is bound to a unicast (multicast) address. Naming is building or organization dependent, must be flexible, and does not require standardization efforts but SHOULD conform to some uniform convention.
It is shown that DNS-based service discovery can be used to locate URIs on the scale necessary in large commercial BAC deployments. Finally, a method is proposed for mapping URIs onto legacy BAC resources, e.g., to facilitate application-layer gateways.
This proposal supports the view that 1) service discovery is complementary to resource discovery and facilitates control network scaling, and 2) building control is likely to move in steps toward all-IP control networks based on the legacy efforts provided by DALI, LON, BACnet, ZigBee, and other standards,
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 12, 2012.
Copyright (c) 2011 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 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
In addition, the following conventions are used in this document:
A CoAP end-point, or server, is identified by a unique {IP address, port} tuple. A server is completely specified by the authority part of a URI.
A device is the physical object that is connected to the network. A device may host one or more CoAP servers.
A service (in the service discovery sense) is a related set of resources on a CoAP server. A URI completely specifies the syntax of a service interface. Metadata describe the semantics of the service interface. The semantics may include the relation between service and the hardware connected to the device. A CoAP server may expose one or more services.
In examples below involving URIs, the authority is preceded by double slashes "//" and path is preceded by a single slash "/". The examples may make use of full or partial host names and the difference should be clear from the context.
The CoAP protocol [I-D.ietf-core-coap] aims at providing a user application protocol architecture for a network of devices with a low resource provision such as memory, CPU capacity, and energy. In general, IT application manufacturers strive to provide the highest possible functionality and quality for a given price. In contrast, the building automation controls market is highly price sensitive and manufacturers tend to compete by delivering a given functionality and quality for the lowest price. In the first market a decreasing memory price leads to more software functionality, while in the second market it leads to a lower Bill of Material (BOM).
The vast majority of devices in a typical building control application is resource constrained, making the standardization of a lightweight application protocol like CoAP a necessary requirement for IP to penetrate the device market. The low energy consumption requirement of battery-less devices reinforces this approach. Low resource budget implies low throughput and small packet size as for [IEEE.802.15.4]. Reduction of the packet size is obtained by using the header reduction of 6LoWPAN [RFC4944] and encouraging small payloads.
Several legacy building control standards (e.g. [BACnet], [DALI], [KNX], [LON], [ZigBee], etc.) have been developed based on years of accumulated knowledge and industry cooperation. These standards generally specify a data model, functional interfaces, packet formats, and sometimes a physical medium for data objects and function invocation. Many of these industry standards also specify proprietary transport protocols, necessitating expensive stateful gateways for these standards to interoperate. Many more recent building control network include IP-based standards for transport (at least to interconnect islands of functionality) and other functions such as naming and discovery. CoAP will be successful in the building control market to the extent that it can represent a given standard's data objects and provide functions, e.g. resource discovery, that these standards depend on.
From the above the basic syntax properties can be summarized as:
| - | Generate small payloads. |
|---|---|
| - | Compatible with legacy standards (e.g. LON, BACnet, DALI, ZigBee Device Objects). |
| - | Service/resource discovery in agreement with legacy standards and naming conventions. |
This submission defines an approach in which the payload contains messages with a syntax defined by legacy control standards. Accordingly, the syntax of the service/resource discovery messages encapsulates legacy control standard. The intention is a progressive approach to all-IP in building control. In a first stage standard IETF based protocols (e.g. CoAP, DNS-SD) are used for transport of control messages and discovery messages expressed in a legacy syntax. This approach enables the reuse of controllers based on the semantics of the chosen control standard. In a later stage a complete redesign of the controllers can be envisaged guided by the accumulated experience with all-IP control.
Two concepts, hierarchy and group, are of prime importance in building control, particularly in lighting and HVAC. Many control messages or events are multicast from one device to a group of devices (e.g. from a light switch to all lights in an area). The scope of a multicast command or discovery message determines the group of devices that is targeted. A group scope may be defined as link-local, as a tree maintained by an IP-multicast protocol, or an overlay that corresponds to the logical structure of a building or campus and is independent of the underlying network structure. Techniques for group communication are discussed in [I-D.rahman-core-groupcomm].
As described in "Commercial Building Applications Requirements" [I-D.martocci-6lowapp-building-applications] it is typical practice to aggregate building control at the room, area, and supervisory levels. Furthermore, networks for different subsystems (lights, HVAC, etc.) or based on different legacy standards have historically been isolated from each other in so-called "silos". RESTful web services [Fielding] represent one possible way to expose functionality and normalize data representations between silos in order to facilitate higher order applications such as campus-wide energy management.
Consequently, additional group properties are:
| - | Devices may be part of one or more groups. |
|---|---|
| - | Resources addressed by a group must be uniformly and consistently named across all targeted devices. |
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 commissioning of a given network segment and (2) maintenance oriented applications where data are collected from devices in several building areas by devices inside or outside the building, and humans may intervene to change control settings. This I-D compares commercial building solutions with solutions for the home.
This I-D considers three elements of the URI: scheme, authority, and path, as defined in "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986]. The authority is defined within the context of standard DNS host naming, while the path is valid in relation to a fully qualified domain name (FQDN) plus optional port (and protocol is implicit, based on scheme). An example based on [RFC3986] is: foo://host.example.com:8042/over/there?name=ferret#nose, where "foo" is the scheme, "host.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.
The CoAP URI scheme syntax is specified in section 6.1 of [I-D.ietf-core-coap] and is compatible with the "http" scheme specification [RFC2616]. The scheme is implicit from the perspective of the service, but it indicates the protocol used to access the service to potential clients.
TBD: we have yet to fully explore the utility of a separate scheme (e.g., "coapm") to support group communication models as described in [I-D.rahman-core-groupcomm].
The authority part is either a literal IP address or a DNS name comprised of a local part, specifying an individual device or group of devices, and a global part specifying a (sub)domain that may reflect the logical hierarchical structure of the building control network. The result is said to be a fully qualified domain name (FQDN) which is globally unique down to the group or device level. An optional port number may be included in the authority following a single colon ":" if the service port is other than the default CoAP value. The authority resolves to a {IP-address, port} tuple. The IP-address may be either unicast or multicast. The authority therefore identifies an individual server or a named group of servers.
The CoAP spec [I-D.ietf-core-coap] states "When a CoAP server is hosted by a 6LoWPAN device, it SHOULD also support a port in the 61616-61631 compressed UDP port space defined in [RFC4944]." As shown below, DNS-SD [I-D.cheshire-dnsext-dns-sd] is a viable technique for discovering dynamic host and port assignments for a given service. However, the use of dynamic ports in URIs is likely to lead to brittle (non-durable) identifiers as there is no assurance that a CoAP server will consistently acquire the same dynamic port and different {IP-address, port} tuples conventionally represent different servers.
A building can be unambiguously addressed by it GPS coordinates or more functionally by its zip or postal code. For example the Dutch Internet provider, KPN, assigns to each subscriber a host name based on its postcode. Analogously, an example authority for a building may 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 specify the target device within the building. Arriving at the device identified by //bldg.5533BA-125a.nl, the receiving service can parse the path portion of the URI and perform the requested method on the specified resource.
Buildings have a logical internal structure dependent on their size and function. This ranges from a single hall without any structure to a complex building with wings, floors, 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 natural to name the equipment based on their location within the building. Consequently, the local part of the URI identifying a piece of equipment is expressed in the building structure. An example is: //light-27.floor-1.west-wing...
This proposal assumes a minimal level of cooperation between the IT and building management infrastructure, namely the ability of the former to delegate DNS subdomains to the latter. This allows the building controls installer to implement an appropriate naming scheme with the required granularity. For institutional real estate such as a college or corporate campus, the authority might be based on the organization's domain, e.g. //device-or-group.floor.wing.bldg.campus.example.com/. In cases where subdomain delegation is not an option, structure can still be represented in a "flat" namespace, subject to the 63 octet limit for a DNS label: //group1-floor2-west-bldg3-campus.example.com.
Most communication is device to device (M2M) within the building. Often a device needs to communicate to all devices of a given type within a given area of the building. For example a thermostat may access all radiator actuators in a zone. A light switch located at room 25b006 of floor one, expressed as: //switch0.25b006.floor1.5533BA-125a.nl/, might specify a command to light1 within the same room with //light1.25b006.floor1.5533BA-125a.nl/. This approach can lead to rather verbose URI strings in the packet, contrary to the small packet assumption. The question arises as to whether the syntax of the authority part needs to be standardized for building control. Given the examples later in the text, naming authorities for building control appears more to be the concern of the building owner or the installer than a standardization concern.
The path identifies the addressable attributes of the service at the highest possible granularity. A set of paths defines the syntax of the service invocation and constitutes the interface description of the service. Every network service attribute is completely identified by a URI scheme://authority/path. In analogy, the path part of the URI specifies the resource of a given server. The naming of the services and their associated attributes are typically subjects for standardization. There is no widely accepted standard for uniformly naming building control services in a URI. A vigorous effort is undertaken by the oBIX working group of OASIS [oBIX], but its current impact is limited. There is also an open source point naming effort underway called Project Haystack [HAYSTACK].
The path is constructed like a file system path name. It consists of a sequence of one or more name fields, with each field preceded with a slash, like /func1/subf2/final. The set of paths is structured as a tree. The last name in a name field sequence is called a leave of the tree, and the authority is the root of the path tree of a given host. The semantics of a given sub-tree in the path tree is specified by the Interface Description (if=) attribute described in [I-D.ietf-core-link-format]. As for file systems some tree naming with associated semantics can be standardized such as the de facto PC standard directory "documents and settings" with the sub-directories "My documents", "usradmin", etc. When a given body, e.g. XXX, has defined a name structure and semantics for the path tree, we say that "if = XXX" for the path tree conforms to the name structure defined by XXX.
When a GET method with an URI like "//t-sensor1.25b006.floor1.example.com/temperature" is sent, it represents an a priori understanding that the server with name t-sensor1 exists, provides a service of a given standard type (with associated semantics) (e.g. ZigBee temperature sensor), and that this standard type has the readable attribute: temperature. When commands are sent to a group of servers it MUST be the case that the targeted resource has the same path on all targeted servers. Therefore, it is necessary to establish at least a local uniform path naming convention to achieve this. One approach is to include the name of the standard, e.g. BACnet, as the first element in the path and then employ the standard's chosen data scheme (in the case of BACnet, /bacnet/device/object/property).
The organization responsible for defining a given industry standard XXX (e.g. BACnet, ZigBee, etc.) can register the /.well-known/XXX prefix and specify the allowable path-names that may occur under this prefix. The same body also defines the "if=XXX" attribute. This allows the standards development organization responsibile for XXX to define the name space and resources associated with the prefix together with the associated semantics. The registered /.well-known/XXX URI effectively defines a standard object model, or schema, for services of the XXX application protocol. Manufacturers may optionally define proprietary resources that can be discovered dynamically using methods described below.
Although the authority part names need not always be transported, the path names MUST be transported in the CoAP packets. Therefore, it is advisable to make the resource names as short as possible, even at the detriment of the clarity of the meaning of the path name.
Within building control it is necessary to send the same command to a set of servers or devices. Grouping allows to invoke the set of services with one application command to be executable within a specified time interval. Given a network configuration, the network operator needs to define an appropriate set of 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 group communication implementation. IP-multicasting over the group is a possible approach for building control, although proxy-based methods may prove to be more appropriate in some deployments [I-D.rahman-core-groupcomm].
Example device groups become:
| URI authority | Targeted group |
|---|---|
| //all.bldg6... | "all devices in building 6" |
| //all.west.bldg6... | "all devices in west wing, building 6" |
| //all.floor1.west.bldg6... | "all devices on floor 1, west wing, ..." |
| //all.bu036.floor1.west.bldg6... | "all devices in office bu036, ..." |
The granularity of this example is for illustration rather than a recommendation. Experience will dictate the appropriate hierarchy for a given structure as well as the appropriate number of groups per subdomain. Note that in this example, the group name "all" is used to identify the group of all devices in each subdomain. In practice, "all" could name an address record in each of the DNS zones shown above and would bind to a different multicast address [RFC3596] in each zone. Highly granular multicast scopes are only practical using IPv6. The multicast address allocation strategy is beyond the scope of this I-D, but various alternatives have been proposed [RFC3306][RFC3307][RFC3956]. Some techniques in this proposal, e.g. service discovery as described below, can be accomplished with a single CoAP-specific multicast address as long as the desired scope is building-wide.
To illustrate the concept of multiple group names within a building, consider the definition, as done with [DALI], of scenes within the context of a floor or a single office. For example, the setting of all blue lights in office bu036 of floor 1 can be realized by multicasting a message to the group "//blue-lights.bu036.floor1". Each group is associated with a multicast IP address. 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. The URI-Host option [I-D.ietf-core-coap] need not be sent as part of the message. However to identify the resource that is addressed, a short version of the resource path can be inserted as an option as explained in [I-D.ietf-core-link-format].
The binding of a group FQDN to a multicast address (i.e., creation of the AAAA record in the DNS zone server) happens during the commissioning process. Resolution of the group name to a multicast address happens at restart of a device. A multicast address and associated group name in this context are assumed to be long-lived. It can happen that during operation the membership of the group changes (less or more lights) but its address is not altered and neither is its name. In the limit, the group can degrade to a single controller that represents a non-networked subsystem replacing the original networked group of devices. Group membership may be managed by a protocol such as Multicast Listener Discovery [RFC5790].
Similarly, a group can identify a set of services on one device. For examples a device contains four I/O channels. The device hosts one server which provides four services to access each of the four individual channels separately. Commonly, it is also required to access a subset of all four channels simultaneously. An additional path identifies the group of services. An example set of services and service-group becomes:
| URI path | Targeted group |
|---|---|
| /IOchannel/channel1... | "channel 1 of the IO channel device " |
| /IOchannel/channel2... | "channel 2 of the IO channel device " |
| /IOchannel/channel3... | "channel 3 of the IO channel device " |
| /IOchannel/channel4... | "channel 4 of the IO channel device " |
| /IOchannel/group1-3... | "channel 1 to 3 of the IO channel device " |
A group defines a set of servers or a set of service attributes. Grouping of the service attributes is provided by the device manufacturer. Grouping of the services is supported by DNS and multicast protocols. The multicast address(es) identify the servers belonging to the group. A given server might belong to a number of groups. For example the server belonging to the "blue-lights" group in a given corridor might also belong to the groups: "whole building", "given wing", "given floor", "given corridor", and "lights in given corridor". From the perspective of a server, the main consequence of joining a group is it should accept packets for an additional IP address. The granularity of the domain names may have an impact on the complexity of the DNS infrastructure but not necessarily on the low-resource destinations or sources. Assuming that resolution of addresses only happens at device start-up, the complexity of the DNS server need not affect the responsiveness of the devices.
In summary, the authority portion of the URI resolves to an IP-address and port number, and identifies a server or group of servers. Authority naming is building or organization dependent, must be flexible, and does not require standardization efforts but SHOULD conform to some uniform convention. Path naming SHOULD conform to the naming convention of a standardization body.
Service discovery in building control should rely on a minimal need for intervention by humans (or complete absence of humans) during system setup, bootstrapping, restart, configuration and daily operation. The goals for service discovery area:
| Goal | Goal description |
|---|---|
| Return_instance | Return all instances of a given service type within a given domain |
| Group_instance | Group a set of instances within a group associated with a domain |
| Instance_resolution | Resolve the instance name to usable invocation information (e.g. IP address and port) |
| Group_resolution | resolve the group name to usable invocation information (e.g. IP address and port) |
These goals are necessary to support the operation of commercial building control. Returning the instances results in a list of names. For building control these names can be any sequence of characters as long as for each service instance these names are unique within the domain. In [I-D.cheshire-dnsext-dns-sd] the office equipment in the IT domain is recommended to use understandable and human-readable names. The Home domain may have a need for human understandable names. This is not the case for the commercial building automation domain. However, uniqueness of the name is necessary for the application that needs to address the service interface on the devices in a consistent manner. Given the large number of devices in a building (several hundreds to thousands) scaling is an important aspect of the service discovery. A set of central DNS servers will provide the scalability. The expectation is that names need to be managed consistently by a central authority which can be supported by the DNS server. Tools will assist the installer and operator of the network to do the installation, configuration and maintenance of the network structure. Small devices will use the DNS server to learn the communication partners providing a given service within their domain and to resolve the IP addresses of the communication partners.
Within the home it is more important that the names convey the purpose of the service to the user reading the names and selecting his favored service instance. Non-unique names, although confusing, can probably be handled by the user of these names. Scalability is less of an issue because a smaller number of devices is implicated. The network in the home is probably more dynamic than its commercial counter-part, with many movements of devices and arrival or removal of devices.
Section 5 presents some examples of DNS structures to show how the choice of names influences the granularity of the discovery. In sections 5.1 and 5.3 a grouping example and a commissioning example, filling the DNS, are presented.
DNS-Based Service Discovery (DNS-SD) defines a conventional way to configure DNS PTR, SRV, and TXT records to facilitate discovery of services within a subdomain, re-using the existing DNS infrastructure. This section gives a cursory overview of DNS-SD; see [I-D.cheshire-dnsext-dns-sd] for a complete description.
A DNS-SD service instance name is of the form <Instance>.<ServiceType>.<Location>.
The Location part of the service name is identical to the global (DNS subdomain) part of the authority in URIs that identify the resources on this device or group and may identify a building zone as in the examples above.
The ServiceType is composed of multiple parts: 1) the IP protocol part, 2) the application or service type of the defining organization (e.g. ZigBee HomeAutomation), and optionally 3) the subtype of the service (e.g. temperature sensor). The ServiceType SHOULD have the form [_subtype._sub.]_type._proto. The _proto identifier provides a transport protocol hint as required by the SRV record definition [RFC2782] and, in the case of CoAP, it is always "_udp". The _type identifier is determined by standards development organization (SDO) and MUST be registered with dns-sd.org [dns-sd]. The SDO is then free to specifiy one or more _subtype identifiers, which must be unique for a given _type. The _subtype and _type labels are separated by the literal "._sub" label.
A PTR record with the label "_type._proto" is defined for each end-point in a selected domain, and this record's value is set to the service instance name (which in turn identifies the SRV and TXT records for the CoAP end-point). Assuming that the DALI organization defines _type as "dali" and _proto as "udp" for its CoAP binding, PTR records with the label "_dali._udp" are stored in DNS-SD. Assuming ZigBee HomeAutomation defines _type as "HomeAutomation", PTR records with label "_HomeAutomation._udp" are stored. This approach permits DNS-SD to return all services pertaining to HomeAutomation or DALI.
DNS-SD also supports one level of subtype, which can be used to locate services based on the object model (schema) of a given standard. [I-D.cheshire-dnsext-dns-sd] suggests to separate the subtype from the service by _sub. For example: _AI._sub._bacnet._udp for an Analog Input object of BACnet or _lamp._sub._dali._udp for a lamp type of DALI. The maximum length of the type and subtype fields is 14 octets, but shorter names are encouraged to reduce packet sizes.
The Instance part of the service name may be changed during the commissioning process. It must be unique for a given ServiceType within the subdomain. The complete service name uniquely identifies an SRV and a TXT record in the DNS zone. The granularity of a service name MAY be at the group or server level, or it could represent a particular resource (service interface) within a CoAP device. The SRV record contains the host (AAAA record) name and port of the service. In the case where a service name identifies a particular functional entry point, the path part of the URI MUST be placed in the TXT record (PATH=).
In general, the authority "www.example.com" does not refer to a canonical host name (the label of a AAAA record). Logically, it refers to the "world wide web service" for the example.com domain. Literally, the "www" is probably the label of a CNAME record that names a AAAA record that may in turn specify more than one address (in the case of round-robin load leveling between identical origin server instances).
The SRV record functions something like the CNAME in this case, except that it is capable of resolving to a canonical host name plus a listening socket. An optional TXT record may be configured with the same name as the SRV record and be used to store context-dependent key=value pairs. For example, a multi-function device might define a service name for each "base URI" that locates a service interface (e.g. abs-path=/.well-known/zigbee/sensor/). Thus, the URI coap://host.example.com/temp might resolve through DNS-SD lookups to coap://[fdfd::1234]/.well-known/zigbee/sensor/temp.
TODO: Kerry: this last line needs quite some explanations !!!!
Devices in a given Location with given ServiceType, _type._proto, may be enumerated by sending a DNS query for PTR records named _type._proto to the authoritative server for that zone associated with the Location. A list of names for SRV records matching that ServiceType.Location is returned. Each SRV record contains the host name and port of a CoAP server. The IP address of the device is obtained by resolving the host name. DNS-SD also specifies an optional TXT record, having the same name as the SRV record, which can contain "key=value" attributes. Apart from defining standardized resources identified by IF=XXX, the XXX organization may also define the standard "key=value" pairs present in the TXT record, e.g. type=switch. By convention, the first pair is txtver=<number> so that different versions of the XXX schema may interoperate. For example: A query is sent to DNS-SD to return all DALI lamps within the domain office5/mybuilding and with ServiceType: _lamp._sub._dali._udp. DNS-SD returns the list of all SRV records and AAAA records of the devices within the domain providing the wanted service.
Service discovery is concerned with finding the IP address, port, protocol, and possibly path of a named service. Resource discovery is a fine-grained enumeration of resources (path-names) within a service. [I-D.ietf-core-link-format] specifies a resource discovery pattern, such that sending a confirmable GET message for the /.well-known/core resource returns a set of links available from the server. These links may describe resources hosted on that server or on other servers.
Assuming the ability to multicast the GET over the site link, CoAP resource discovery can be used to enumerate attributes and populate the DNS-SD database in a semi-automated fashion. CoAP resource descriptions can be imported into DNS-SD for exposure to service discovery by using /.well-known/core attributes as the basis for a unique "Instance" name, and the ServiceType, while using some means to establish in which subdomain the service should be registered
(TBD).
The DNS TXT record can be populated by importing the other resource description attributes as they share the same key=value format specified in Section 6 of [I-D.cheshire-dnsext-dns-sd]. The values stored in the DNS-SD directory are extracted from the information stored in the resource directory associated with a set of CoAP hosts [I-D.shelby-core-resource-directory]. The resources describe how the services can be manipulated in detail and in concreto.
It is assumed that a resource directory exists per 6LoWPAN [RFC4944], possibly running on the edge router. The DNS-SD provides a larger scope by storing the info of all services over a set of interconnected 6LoWPANs. Where the resource directory is possibly completely adequate for home networks, handling of multiple resource directories can be quite cumbersome for the many 6LoWPANs envisaged for offices. However, during network configuration, the resource directory can be used as long as the DNS is not yet accessible.
The DNS-SD approach is complementary to the more fine-grained resource discovery, fits better the concept of discovering devices with given properties (services). DNS-SD supports a hierarchical approach to the naming of the services as discussed in section 3. DNS-SD provides a directory structure that scales well with the network size as shown by its present-day operation.
An example is presented which explains the Resource Record (RR) structure on the DNS server. This section follows the mapping specified in [I-D.lynn-core-discovery-mapping], which defines how to fill the DNS-SD records from the link extension values. Suppose the services are delivered by ZigBee home automation devices. The example subtype- and context- names are assumed to be standardized by the ZigBee alliance. All devices are situated in one office with location office4.bldg8.example.com. The names in the examples are more verbose than recommended to make the examples more readable. The table presents the services provided in the office control network:
| service | ServiceType | Number |
|---|---|---|
| illumination | _OnOff_light._sub._HomeAutomation._udp | 4 |
| presence | _occup_sensor._sub._HomeAutomation._udp | 1 |
| temperature | _temp_sensor._sub._HomeAutomation._udp | 1 |
| shading | _shade_control._sub._HomeAutomation._udp | 1 |
For every service there is a PTR record stored, with as label the ServiceType, that points to the service instances. The unique Instance names identify the service instances. The unique names are represented as id-x, with x in natural numbers. They are usually created at the factory floor and somehow attached to the product. The ServiceTypes have been suffixed with .04.8 to represent office4 in building8.
| _OnOff_light._sub._HomeAutomation._udp.04.8 | PTR | id-1._OnOff_light |
|---|---|---|
| _OnOff_light._sub._HomeAutomation._udp.04.b8 | PTR | id-2._OnOff_light |
| _OnOff_light._sub._HomeAutomation._udp.04.b8 | PTR | id-3._OnOff_light |
| _OnOff_light._sub._HomeAutomation._udp.04.b8 | PTR | id-4._OnOff_light |
| _occup_sensor._sub._HomeAutomation._udp.04.b8 | PTR | id-5._occup_sensor |
| _temp_sensor._sub._HomeAutomation._udp.04.b8 | PTR | id-6._temp_sensor |
| _shade_control._sub._HomeAutomation._udp.04.b8 | PTR | id-7._temp_sensor |
In the above example the id-x identifiers without the subtype suffix would be discriminating enough.
Discovery can be done with the following results. A query with the following argument returns
| query argument | result list |
|---|---|
| .04.8 | id-1._OnOff_light |
| ....... | |
| id-7._temp_sensor | |
| _HomeAutomation._udp.04.b8 | id-1._OnOff_light |
| ....... | |
| id-7._temp_sensor | |
| _OnOff_light._sub._HomeAutomation._udp.04.b8 | id-1._OnOff_light |
| ....... | |
| id-4._OnOff_light | |
| _occup_sensor._sub._HomeAutomation._udp.04.b8 | id-5._occup_sensor |
When other offices are included in the database, the query argument 04.b8 selects those entries which are associated with office4 in building8 and rejects any others. The example shows clearly the query granularity that can be obtained and the care that must be exercised when defining the names of the ServiceTypes.
The unique identifiers suffixed with their subtype are the labels of the SRV, AAAA and TXT records describing the service instance. The SRV record specifies the location (authority) and the port number. In the authority o4.b8 refers to office4 in building8. The AAAA record specifies the IP-address, while the TXT record specifies the subtype and the data representation of the legacy parser (IF = ZigBee).
| id-1._OnOff_light | SRV | light1.o4.b8.example.com | Port-x |
|---|---|---|---|
| AAAA | FDFD::1234 | ||
| TXT | IF=ZigBee | ||
| id-2._OnOff_light | SRV | light2.o4.b8.example.com | Port-x |
| AAAA | FDFD::1235 | ||
| TXT | IF=ZigBee | ||
| id-3._OnOff_light | SRV | light3.o4.b8.example.com | Port-x |
| AAAA | FDFD::1236 | ||
| TXT | IF=ZigBee | ||
| id-4._OnOff_light | SRV | light4.o4.b8.example.com | Port-x |
| AAAA | FDFD::1237 | ||
| TXT | IF=ZigBee | ||
| id-5._occup_sensor | SRV | occup.o4.b8.example.com | Port-x |
| AAAA | FDFD::1238 | ||
| TXT | IF=ZigBee | ||
| id-6._temp_sensor | SRV | temp.o4.b8.example.com | Port-x |
| AAAA | FDFD::1239 | ||
| TXT | IF=ZigBee | ||
| id-7._shade_control | SRV | shade.o4.b8.example.com | Port-x |
| AAAA | FDFD::1240 | ||
| TXT | IF=ZigBee |
It is possible that the temperature sensor and occupancy sensor are delivered on one device. The consequence is that one device hosts two services. In the DNS table the four lights and the shade controller are unaffected. However, the PTR records with the occupancy and temperature sensor point to the same unique identifier id-8 that is suffixed with the name of the subtype. This example shows that the subtype suffix is needed to discriminate between the two services.
| _occup_sensor._sub._HomeAutomation._udp | PTR | id-8._occup_sensor |
|---|---|---|
| _temp_sensor._sub._HomeAutomation._udp | PTR | id-8._temp_sensor |
Two SRV records with accompanying AAAA and TXT records describe the two servers, each providing one service, in more detail. The servers share the same IP address but are connected to different ports, and do have a different paths names. The TXT record is used to specify the path part with "PATH=".
| id-8._occup_sensor | SRV | occup.o4.b8.example.com | Port-x |
|---|---|---|---|
| AAAA | FDFD::1241 | ||
| TXT | PATH=/os IF=ZigBee | ||
| id-8._temp_sensor | SRV | temp.o4.b8.example.com | Port-y |
| AAAA | FDFD::1241 | ||
| TXT | PATH=/ts IF=ZigBee |
The path names /ts and /os are short names for temperature_sensor and occupancy_sensor respectively. Not all multi-function devices will use different ports for the individual functions. It is also quite common to use different IP interfaces with different IP addresses, reflected by the value of the AAAA records.
Another aspect is the grouping of servers. Where in the former section the names of the services are standardized names, this is less probable for the group names. Usually the group names are application specific or are standardized at the manufacturer. For example, assume that a group all-light.o4.b8.example.com is created which contains all four lights inside office4. The accompanying ServiceType can be defined as _all_light._sub._HomeAutomation._udp. The use of HomeAutomation is taken although _all_light is not a supported service within HomeAutomation profile. The ServiceType suffixed with 04.b8 points to a unique identifier defined as _all_light.04.b8, assuming that this is the only _all_light group within office 4 of building 8. The PTR record looks like:
| _all_light._sub._HomeAutomation._udp.04.b8 | PTR | _all_light.04.b8 |
|---|---|---|
It is assumed that the group all_light.o4.b8.example.com has received a multicast address: FF1E::148. The accompanying SRV, AAAA, and TXT RR become:
| _all_light.04.b8 | SRV | all_light.o4.b8.example.com | Port-z |
|---|---|---|---|
| AAAA | FF1E::148 | ||
| TXT | IF=ZigBee |
In some cases it may be desirable to show all hosts which are part of the multicast group. This can be done using the PTR records which point to the authorities of the associated hosts. The AAAA records provide the IP addresses of the hosts.
| all_light.o4.b8.example.com | PTR | light1.o4.b8.example.com |
|---|---|---|
| all_light.o4.b8.example.com | PTR | light2.o4.b8.example.com |
| all_light.o4.b8.example.com | PTR | light3.o4.b8.example.com |
| all_light.o4.b8.example.com | PTR | light4.o4.b8.example.com |
| light1.o4.b8.example.com | AAAA | FDFD::1234 |
| light2.o4.b8.example.com | AAAA | FDFD::1235 |
| light3.o4.b8.example.com | AAAA | FDFD::1236 |
| light4.o4.b8.example.com | AAAA | FDFD::1237 |
The entries in DNS can be used to form groups with the light weight group management protocol and multicast listener discovery [RFC5790]. In contrast to the earlier examples the name of the PTR record is a domain name and not a ServiceType.
The populated DNS-SD server provides the necessary support for the applications to execute their control loops with minimum operator support. The operation of the office network can be split up in phases. In a first phase the network is commissioned, such that a relation is established between the IP address, the servicetype and the domain. The servicetype can be extracted from the link-format as described in [I-D.shelby-core-resource-directory]. After commissioning this information is stored in the DNS-SD files. In a second phase groups are formed and group names with their IP address are stored in the DNS-SD files. The IP multicast addresses are communicated to the members of the groups. In the third and final phase, applications query DNS-SD to find the IP addresses of the services within a given domain, and of the groups within a given domain.
In the home, a commissioning phase requiring the intervention of an installer (a "truck roll") is to be avoided if possible. Here the first phase consists of the booting up devices which insert their services resources to a link-format directory. The information from the resource directory can be inserted into DNS-SD or into xmDNS [I-D.lynn-dnsext-site-mdns] when appropriate. In the second phase remote controllers or other hand-held devices can be used to discover the services of a given type, to group the services, and to store the group names into DNS-SD or xmDNS as appropriate. Pointing out the members of a group can be in any kind of manner from typing members in, selecting them from a browser list, etc.
For clarity it is assumed in this section that a device hosts one server. The URI of the device together with its service completely determines the function of the device within the building. The authority part of the URI represents the location of the host within the domain name space. Given the authority naming presented in section 2.2 the authority name represents the location of the host within the building.
Commissioning means the following three actions:
| - | Defining the URI (location) |
|---|---|
| - | Assigning an IP address to the URI |
| - | mapping the unique device identifier to the URI |
Two cases of the office network are considered for commissioning: (1) no 6LBR and no DNS server connected, and (2) a 6LBR connects the office network to a DNS server.
When an architect has designed the building and described all light points, ventilators, heating- and cooling units, and sensors, it is necessary to identify all these devices spatially and functionally. Storing the triple Instance.ServiceType.Location into DNS-SD represents the commissioning process. The Instance is the unique identifier given to the device in the factory but which has no relation to its later location. The ServiceType together with the Location fully determine the semantics of the data returned by the device.
Design decision: A commissioning tool with access to the network is used for the commissioning phase.
For example, dependent on used technology and production process, the following situation (state) exists in a host after physical installation of the devices:
Consider the commissioning process (1) with a central DNS-SD server and (2) without a central server using xmDNS. The commissioning processes described below are just examples and should not be taken as working procedures for commissioning devices in a building.
The installer reads with a bar code reader, attached to the commissioning tool, the identifier of the device to commission. It is assumed that the tool can learn the IP address of the device with the given identifier. The tool displays on a screen the physical lay-out of the devices within the building. The installer selects, on the screen of the tool, the physical location of the chosen device. From the designated physical location the tool creates the URI of the selected device. The tool inserts the URI and the IP address into the DNS server. For example the light with URI light1.o4.b8.example.com is represented with an AAAA record:
| light1.o4.b8.example.com | AAAA | FDFD::1234 |
|---|---|---|
The tool reads the service name and type from the device using resource information stored according to the link-format [I-D.ietf-core-link-format]. With this information the tool constructs the PTR, SRV and TXT records according to the example presented in section 5.
This is done for all devices within a given part of the building. After the commissioning process, all resources of each device have an URI and IP address which are stored in the central DNS-SD server. When devices are restarted, the DHCP server allocates IP addresses to the device and updates the DNS server.
It is assumed that the building network is composed of independent network segments (possibly a single site) such that each device on a given segment can communicate directly with any other device on this segment. The segments are not connected to a 6LBR and have no access to DNS or other servers. The installer knows these segments and has a list of devices for a given segment. In the tool the installer selects the names which belong to the given building segment. The selected names are converted to site-local authorities and stored in the tool. All devices are assumed to have selected a site-local IP address. Assume that every device has a unique barcode within the building and that the corresponding device knows the bar code number. The installer reads with a bar code reader, attached to the tool, the Instance name of the device to commission. The installer selects, on the screen of the tool, the physical location of the chosen device. The tool knows the authority of the selected device. The tool broadcasts the bar code number and authority to all connected devices. The device with the given barcode number, extends the authority with the path name of the resources. For each resource, the device multicasts the site-local IP-address and the site-local URI to the xmDNS servers in the connected devices. This concludes the commissioning of a network segment. All resources of each device have a site-local URI and a site-local IP address which are stored in the xmDNS servers.
Proxies will be used in CoAP networks for at least two major reasons: (1) http/coap proxy, and (2) proxy of service on battery-less device. The first proxy is probably implemented as forward proxy, while the latter is probably implemented as backward proxy. The battery-less device will at rare occasions (when it is not sleeping) and during installation answer the GET /.well-known/core request. The return data are used by the installation tool to make the proxy device return the same resource names on /.well-known/core as is returned by the sleeping device. An installation tool installs on the proxy all the resources of the sleeping device for which the proxy is assumed to answer. Each resource on the proxy is informed of the service name of the sleeping device by the installation tool. Consequently, the proxy is discovered as a multi-service host with as many path names as it proxies sleeping services. The services of the sleeping devices should not be discoverable via DNS-SD. However, AAAA records are generated for the sleeping device host name. This host name is used by the proxy to subscribe to the services of the sleeping device. For example assume two sleeping devices, an occupancy sensor and a temperature sensor, and one proxy. Two service types are defined with PTR records in DNS-SD. The identifier id-1 of the proxy is used by the installation tool to define the Instances.
| _occup_sensor._sub._HomeAutomation._udp.04.b8 | PTR | id-1._occup_sensor |
|---|---|---|
| _temp_sensor._sub._HomeAutomation._udp.04.b8 | PTR | id-1._temp_sensor |
Two SRV records with accompanying AAAA and TXT records describe the two services in more detail. The services share the same IP address, are connected to the same port, but do have different paths names. The TXT record is used to specify the path part with "PATH=".
| id-1._occup_sensor | SRV | proxy.o4.b8.example.com | Port-x |
|---|---|---|---|
| AAAA | FDFD:: 1241 | ||
| TXT | PATH=/os IF=ZigBee | ||
| id-1._temp_sensor | SRV | proxy.o4.b8.example.com | Port-x |
| AAAA | FDFD:: 1241 | ||
| TXT | PATH=/ts IF=ZigBee | ||
| sl-ts.o4.b8.example.com | AAAA | FDFD::1242 | |
| sl-os.o4.b8.example.com | AAAA | FDFD::1243 |
The path names /ts and /os are short names for temperature_sensor and occupancy_sensor respectively and were taken over from link-format information contained in the sleeping devices. Two AAAA records are provided for the two sleeping devices. The proxy has used the domain names of the sleeping devices to subscribe to the publications of the two sleeping devices.
It is important to remark that there are now two services with the same resources present on two different devices: the sleeping device and its proxy. When a host invokes the /.well-known/core resource, it should be possible to distinguish between the proxy (to be invoked) and the sleeping device (not to be invoked). The distinction is necessary once the sleeping device is discoverable and the sleeping device is awake from time to time. It is suggested that the link-format syntax allows to make this distinction.
Before CoAP devices can come to market, manufacturers must agree that the type and attributes of the device can be interpreted according to some generally recognized syntax. At this moment no such generally recognized syntax exists for CoAP devices. We do not expect an IETF working group to standardize such a syntax, and we are convinced that syntax standardization is the responsibility of industry standards organizations. Given the long history of building control, many groups have defined a data representation for building control devices for example BACnet, ZigBee, oBIX, LON, KNX, and many others. It is our believe that new representations will be defined and must coexist with the named legacy ones.
The CoAP protocol should transport any data representation, and certainly the legacy ones. As pointed out earlier, this has consequences for the naming of resources. In some cases a CoAP device can handle more than one legacy representation. Given that a CoAP device can handle representation of standard XXX, this I-D proposes that such a CoAP device can communicate with legacy devices via a CoAP/legacy gateway (router).
+------+ +------+ +------+
| yyy | | zzz | | zzz |
| link | | CoAP | | CoAP |
+------+ +------+ +------+
| +---------+
|---------| CoAP |-->
| | gateway |
+------+ +---------+ +-----------+
| yyy | | zzz ; yyy |
| link | | CoAP |
+------+ +-----------+
Figure 1 represents the network architecture which is expected for the purpose of this I-D. The CoAP gateway connects one link with two legacy devices -containing legacy data representation "yyy"- with the wireless CoAP network composed of three CoAP hosts. Two CoAP hosts contain the CoAP stack with a zzz representation and one host contains the CoAP stack with a zzz and an yyy representation. The yyy hosts can freely communicate according to the yyy link protocol over the yyy link. The zzz CoAP hosts, including the zzz;yyy host can freely exchange zzz data representations according to the CoAP protocol over the wireless 6LoWPAN network. The zzz;yyy host can send yyy data representations to the CoAP gateway which passes them on to the specified yyy legacy host. The yyy legacy device returns data to the requesting zzz;yyy CoAP host via the same gateway.
The CoAP hosts can address the legacy devices behind the gateway in at least 4 ways.
The major advantage of all four approaches is that the gateway only handles the URI or IP address and port number to select the destination legacy device independent of the type of legacy device and the contents of the legacy payload of the message. In Figure 1 the gateway connects to a single link. For example, this would be the case for DALI standard. Other legacy standards, like BACnet, LON, allow networks composed of multiple links.
An example of an invocation of a ZZZ service (See figure 2). The resource path /.well-known/ZZZ identifies the parser of the ZZZ syntax. A 12 octet string completely describes the ZZZ command. The host is completely identified by the authority in the URI. The ZZZ parser on the host is identified by the port number in the UDP header (not shown).
Client CoAP/ZZZ
| device
| REQUEST |
|-------- CON [0x5577] PUT /.well-known/ZZZ -------->|
| binary 12 octet string |
| |
| RESPONSE |
|<---------- ACK [0x5577] 2.00 OK ----------------- |
| |
An example of an invocation of a DALI legacy device behind a gateway is given in figure 3. The resource path /.well-known/DALI identifies the DALI device. The application sets a value of 200 in the DALI device in the attribute 256 defined by the DALI spec.
Client DALI/CoAP
| gateway
| REQUEST |
|------- CON [0x5577] PUT /.well-known/DALI -------->|
| binary 16 bit payload dt*256 + 200 |
| |
| RESPONSE |
|<---------- ACK [0x5577] 2.00 OK ----------------- |
| |
Two types of gateways are considered; (1) CoAP gateway to a single legacy link, called yyy/CoAP gateway, and (2) CoAP gateway to legacy network, called xxx/CoAP gateway. The source encapsulates the data with the corresponding representation inside a CoAP message and sends these messages to the gateway. In the gateway the XXX/YYY data is removed from the CoAP message and transported to the desired device. Returning an answer to the invoking host needs to be done in two different ways dependent on the addressing type of the XXX/YYY standard. The IP-device-identifier (INI) can be (1) the IP-address, (2) the IP-address, port number, (3) the URI, or (4) the path .
It is assumed that the gateway conforms to the core standard at the internet interfaces. Consequently, all resources are visible at /.well-known/core by invoking a GET. These entries can be entered into DNS-SD with a commissioning tools as proposed in section 5.3; according to the rules specified in section 4. Filling in the address mapping tables is done in a similar way as done for other Application Level Gateways (ALG).
Discovery of legacy gateways is not very different from discovery of proxies in section 5.4. the consequences for discovery are listed for the four modes of addressing legacy devices via a gateway of section 6.1.
This I-D explains how naming in building control is based on a hierarchical structure of the building areas. It is shown that DNS naming can be used to express this hierarchy in the authority portion of the URI, down to the group or device level. The hierarchical naming scheme need not be standardized, but rather can be designed to suit the application. However, it is recommended that the scheme be employed consistently throughout the delegated subdomain(s).
The authority portion of the URI is resolved by the client, using conventional DNS, into the unicast or multicast IP address of the targeted device(s). Taking advantage of the CoAP design [I-D.ietf-core-coap], the URI-Host option need not be transmitted in requests to origin servers and thus there is no performance penalty for using descriptive naming schemes. The CoAP design allows sending a short URI to distinguish between resources on a given device, resulting in very compact identifiers.
DNS-SD [I-D.cheshire-dnsext-dns-sd] can be used to scale up service discovery beyond the 6LoWPAN. DNS-SD can be used to enumerate instances of a given service type within a given sub-domain. This affords additional flexibility, such as the ability to discover dynamic port assignments for CoAP device, locate CoAP devices by subtype, or bind service names for particular CoAP URIs.
This I-D discusses the addressing, discovery and naming of legacy devices behind gateways. The discovery of backward proxies of sleeping devices is handled in a similar fashion.
A targeted resource is specified by the path portion of the URI. Again, this I-D does not mandate a universal naming standard for resources but uses examples to show how resources could be named for various legacy standards. An obvious requirement for resources that are accessed by multicast is that they MUST all share the same path. It is shown that it is possible to transport legacy commands (e.g. expressed in BACnet, LON, DALI, ZigBee, etc.) inside a CoAP message body. This necessitates the definition of an additional IANA mime code, and the mapping of legacy specific discovery semantics to CoAP resource discovery messages or DNS-SD lookups.
TBD: The detailed CoAP security analysis needs to encompass scenarios for building control applications.
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 may be based on the work done elsewhere, for example in the ZigBee over IP context.
Multicast messages are, by their nature, transmitted via UDP. Any privacy applied to such messages must be block oriented and based on group keys shared by all targeted devices. The CoRE security analysis must be broadened to include multicast scenarios.
This I-D proposes that associations which standardize device representations (like BACnet, ZigBee, DALI,...) contact IANA to reserve the prefix /.well-known/XXX for the standard XXX.
This I-D has benefited from conversations with and comments from Andrew Tokmakoff, Emmanuel Frimout, Jamie Mc Cormack, Oscar Garcia, Dee Denteneer, Joop Talstra, Zach Shelby, Jerald Martocci, Anders Brandt, Matthieu Vial, Jerome Hamel, George Yianni, and Nicolas Riou.
From bc-01 to bc-02
- Removed all references to multicast and multicast scope, given draft of rahman group communication.
- Adapted examples to CoAP-2 and core-link drafts.
- transport short URL for destination recognition.
- Elaborated legacy discovery under DNS-SD.
From bc-02 to bc-03
- Elaboration on gateways, commissioning and legacy networks.
- Recommendation to extend DNS-SD naming with sn, st, and ss attributes.
From bc-03 to bc-04
- moved core link extension sub-section to resource directory draft
- extended use of service type
- gave DNS record examples and worked out multifunction device
- added proxy discovery and legacy gateway discovery
- defined path tree and corresponding schema
- reviewed definition of server, service, device, service attribute, and resource
| [I-D.cheshire-dnsext-dns-sd] | Cheshire, S and M Krochmal, "DNS-Based Service Discovery", Internet-Draft draft-cheshire-dnsext-dns-sd-10, February 2011. |
| [I-D.cheshire-dnsext-multicastdns] | Cheshire, S and M Krochmal, "Multicast DNS", Internet-Draft draft-cheshire-dnsext-multicastdns-14, February 2011. |
| [I-D.ietf-core-coap] | Shelby, Z, Hartke, K, Bormann, C and B Frank, "Constrained Application Protocol (CoAP)", Internet-Draft draft-ietf-core-coap-08, October 2011. |
| [I-D.ietf-core-link-format] | Shelby, Z, "CoRE Link Format", Internet-Draft draft-ietf-core-link-format-09, November 2011. |
| [I-D.martocci-6lowapp-building-applications] | Martocci, J, Schoofs, A and P Stok, "Commercial Building Applications Requirements", Internet-Draft draft-martocci-6lowapp-building-applications-01, July 2010. |
| [I-D.rahman-core-groupcomm] | Rahman, A and E Dijk, "Group Communication for CoAP", Internet-Draft draft-rahman-core-groupcomm-07, October 2011. |
| [I-D.shelby-core-resource-directory] | Shelby, Z and S Krco, "CoRE Resource Directory", Internet-Draft draft-shelby-core-resource-directory-02, October 2011. |
| [I-D.lynn-core-discovery-mapping] | Lynn, K and Z Shelby, "CoRE Link-Format to DNS-Based Service Discovery Mapping", Internet-Draft draft-lynn-core-discovery-mapping-01, July 2011. |
| [I-D.lynn-dnsext-site-mdns] | Lynn, K and D Sturek, "Extended Multicast DNS", Internet-Draft draft-lynn-dnsext-site-mdns-01, March 2011. |
| [BACnet] | Bender, J. and M. Newman, "BACnet/IP", Web http://www.bacnet.org/Tutorial/BACnetIP/index.html, 2000. |
| [ZigBee] | Tolle, G., "A UDP/IP Adaptation of the ZigBee Application Protocol", Internet-Draft draft-tolle-cap-00, October 2008. |
| [LON] | LONTalk protocol specification, version 3", 1994. | , "
| [DALI] | DALI Manual", Web http://www.dali-ag.org/c/manual_gb.pdf, 2001. | , "
| [KNX] | Kastner, W., Neugschwandtner, G. and M. Koegler, "AN OPEN APPROACH TO EIB/KNX SOFTWARE DEVELOPMENT", Web http://www.auto.tuwien.ac.at/~gneugsch/fet05-openapproach-preprint.pdf, 2005. |
| [IEEE.802.15.4] | Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (LR-WPANs) ", IEEE Std 802.15.4-2006, June 2006. | , "
| [HAYSTACK] | Project Haystack ", Web http://project-haystack.org/, 2011. | , "
| [oBIX] | Frank, B., "oBIX working group", Web http://www.obix.org, 2006. |
| [Fielding] | Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures, Second Edition", Doctoral dissertation , University of California, Irvine , Web http://www.ics.uci.edu/~fielding/pubs/dissertation/top.html, 2000. |
| [ZigBee-IP] | ZigBee Smart Energy Profile 2.0 Application Protocol Specification ", Draft ZigBee-11167, March 2011. | , "
| [dns-sd] | dns-sd servicetype registration ", Web http://www.dns-sd.org/ServiceTypes.html, 2011. | , "