In this section we compare UPnP, DPWS and CoAP in terms of 1) architectural communi- cation model, 2) protocol stack requirements (i.e., type of support protocols needed in the protocol stack), 3) suitability for constrained terminals of type TT2 and TT3.
7.4.1 Architectural Communication Model
• CoAP: is intended as a protocol to replace HTTP in constrained environments, that is, HTTP can be used in the unconstrained portion of the network, whereas CoAP is used within the constrained network domain. Of course, to do so, proper HTTP/CoAP translation proxies should reside somewhere in the unconstrained network domain. Note that the translation proxy can also be placed in the Gateway interfacing the con- strained network with the unconstrained one. CoAP is designed for constrained net- work domains for the following two reasons: 1) CoAP implements a reduced set of HTTP functionalities in a binary format (thus being efficiently implementable on con- strained MCUs), 2) differently from HTTP, CoAP does not need TCP support, which is
known to be heavy in terms of resources (RAM and ROM) and often largely subopti- mal for constrained networks with large delays, small bandwidth and high packet error rates. It shall be observed, that CoAP provides a basic subset of REST methods of HTTP, i.e., GET, PUT, POST, DELETE, that are thought of as the minimal functionalities needed to retrieve data or command an actuator.
• UPnP: is a technology that allows network terminals to self-discover their presence, offered services and also to exchange data, including multimedia. UPnP Devices and UPnP Control Points are the physical entities of a UPnP architecture. Discovery and description mechanisms allow for zero configuration, self-discovery of terminals and offered services as well as self-maintenance of the UPnP topology. Periodic exchange of messages allows for maintaining the network state. From an architectural point of view, UPnP builds on top of HTTP and, as such, its scope and functionalities are complementary with respect to those offered by CoAP (which is a lightweight HTTP replacement). In particular, UPnP adds further functionalities with respect to HTTP at the cost of some additional complexity.
• DPWS: is a solution to bring Web Service functionalities (messaging, discovery, de- scription, and eventing) to resource-constrained devices. Since the communication uses UDP or TCP/HTTP DPWS is like UPnP complementary to CoAP. But there are some activities in working on an SOAP-over-CoAP binding (see [34]) which could com- bine the smallweight communication of CoAP with the easy-to-use web services of DPWS.
7.4.2 Protocol Stack Requirements
• CoAP: requires UDP and IP support. Referring to scenario S2, if user U communi- cates to the resource R natively using CoAP messages, no HTTP/CoAP translation is required. Elsewhere, HTTP/CoAP translation services are required when the user U has a standard IP protocol stack and only supports HTTP.
• UPnP:requires TCP, UDP and IP networking support. In addition, the various aspects of the operation of the UPnP entities depend on SSDP, HTTP, SOAP, XML and HTML processing.
• DPWS: requires IP (v4/v6) in combination with UDP (SOAP-over-UDP) or TCP and HTTP (SOAP-over-HTTP) support. Like UPnP DPWS also uses several web service technologies like SOAP and XML.
7.4.3 Suitability for Constrained Devices
• CoAP:requires UDP and IP support. In case the constrained end devices have lim- ited resources (e.g., TT3 terminals) and cannot implement a CoAP-compatible protocol stack, the Gateway node may implement HTTP/CoAP functionalities, acting as a proto- colwrapper, and interact with the constrained terminals through dedicated, technology dependent and lightweight protocols. Referring to scenario S2, this means that the
Gateway G will have to intercept HTTP/CoAP messages coming from the user U and directed to the constrained resources R that reside within its domain and perform the needed translation/adaptation towards them. Direct implementation of typical CoAP- ready protocol stacks shall be feasible for TT2 devices, whereas TT3 devices may require additional wrapping/adaptation functionalities from the Gateway.
• UPnP:UPnP procedures depend on continuous networking transactions and as such might be considered as a prohibiting factor in the cases where energy consumption is a critical design consideration. In addition, for constrained terminals of type TT2 and TT3, UPnP functionalities may be implemented by a Gateway node, which will then interact with the constrained devices exposing simple communication interfaces through the utilization of appropriate physical and link layer drivers. For constrained devices, we thus foresee UPnP used in conjunction with a Gateway that works as a wrapper, and implements the needed high level logic to expose constrained devices in the networks as if they were fully functional UPnP nodes. In case of scenario S2, the user may be a fully functional UPnP node and the Gateway G will contain the needed UPnP functionalities to make all terminals within its constrained domain reachable and fully interoperable through UPnP technology. In this case, the Gateway G shall im- plement the needed higher layer UPnP logic and the needed translation/adaptation mechanisms to communicate with the constrained terminals.
• DPWS: The usage of web services generates communication (XML-based message format) and computing (XML parsing) overhead which increases the energy consump- tion in the network nodes. The use of gateway nodes to implement the communication with constrained devices (already mentioned in CoAP and UPnP) is of course also applicable in DPWS and allows to integrate those nodes in DPWS networks.
7.4.4 Comparison in Terms of Security Features
The three different protocols for the realization of M2M communications identify security frameworks that at minimum can aid in the enforcement of access control based on various forms of authentication mechanisms. Provisioning of keying and security material is consid- ered as the starting point in all mechanisms. In the case of UPnP there is a mechanism that can be used for ownership establishment that in turn allows for more granular access con- trol. In the case of DPWS and CoAP, however, there are no protocol specific mechanisms but both protocols depend on transport or network layer security.
The following Table2 summarizes the various security aspects of the three different proto- cols.
7.4.5 Concluding Remarks
At is should be now clear from the above discussion, different M2M standards have not been designed with interoperability in mind. They in fact differ in terms of application-layer protocol architecture and sometimes also in terms of offered functionalities. As an example,
Feature UPnP DPWS CoAP Authentication /
Authorisation
Signature keys are used to verify signed action requests
SSL/TLS sessions
can be mutually
authenticated
Either IPsec secu- rity associations or DTLS channel estab- lishment can be mu- tually authenticated Encryption / Pri-
vacy
If required actions and responses can be authenticated
Encrypted by default In DTLS and
IPsec/ESP en-
cryption is by default Transport Layer
Security
No Yes Yes (if DTLS is used)
Network Layer Security
No No Yes (If IPsec-ESP is
used) Easily Applica-
ble
No, there is need for supporting Device Security
Yes if platform offers Transport Layer Se- curity
Yes if DTLS or IPsec is supported by the device
Table 2: Comparison of Security Functionalities of UPnP, DPWS and CoAP.
CoAP offers a very limited set of functionalities such as “set” a parameter, “get” a value, etc., that are thought of for tiny sensor devices, whereas more complex M2M engines such as UPNP offers additional and advanced features such as node discovery, multimedia data handling and data security. The reason behind that is that these two standards have been designed having different application domains in mind (different network/device and service types). However, with the advent of the Internet of Things, communication possibilities will be tremendously increased, leading to the need for interoperability across different M2M technologies.
The bottom line of all that is that there is amissing translation functionalitythat must be provided to ensure interoperability. Providing such an interoperability is one of the main objective of the IoT-A protocol stack. In Section7.5we address this problem, by detailing how this will be accomplished by our design.