Universal Plug and Play (UPnP) was originally designed for consumer electronics, mobile devices, home automation, and personal computer networks emphasizing zero configuration networking – the idea that setting up a service doesn’t require any manual configuration. It includes automatic assignment of network addresses, automatic distribution of hostnames, and automatic discovery of network services. Although UPnP envisioned interoperation with consumer electronics and home automation, its first international specification published in 2008 by ISO/
IEC29 before the Internet of Things became a popular buzz word.
The UPnP set of standards has evolved to better support audio/video equipment, remote user interfaces, quality of service, and remote access from the Web. As recently as 2015, the UPnP Forum published the UPnP Device Architecture 2.030 specification that extends into the Web through XMPP integration. The IoT Management and Control Architecture31
published September 10, 2013, addresses more directly home automation requirements with the inclusion of sensor management.
29 ”ISO/IEC standard on UPnP device architecture makes networking simple and easy.” International Organization for Standardization. 10 December 2008.
Retrieved 11 September 2014.
30www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v2.0.pdf
31http://upnp.org/specs/iotmc/UPnP-iotmc-IoTManagementAndControl- Chapter 2 Iot Frameworks and ComplexIty
83 The UPnP protocol stack (Figure 2-11) may be regarded as IoT
frameworks, though loosely as UPnP is tightly bound to IP and the network services built around IP such as DHCP, DNS, IP multicast, and so on. UPnP network topologies parallel that of IP network topologies.
The UPnP Device Architecture layer consists of a discovery service named Simple Service Discovery Protocol (SSDP) that supports passive discovery request-response as well as active service availability notification and unsolicited advertisements using local multicast addressing. The General Event Notification Architecture (GENA) handles the details of registering notification events and sending notification messages when events are triggered. The Simple Object Access Protocol (SOAP) uses XML-formatted messages that are delivered using RESTful HTTP request- response exchanges. UPnP also supports IP multicast events for simple messages that need to be broadcast to multiple UPnP nodes.
HTTP
Multicast Messaging
(SOAP) Notification
(GENA) Discovery
(SSDP)
UPnP Applications UPnP Vendor Specific Layer UPnP Forum Standardization Layer
UPnP Device Architecture Layer
TCP / UDP IPv4 / IPv6
Figure 2-11. UPnP protocol stack
UPnP networks (Figure 2-12) consist of two node types, control points and Devices. Devices host Services. Device nesting is supported; the top- level Device is known as the Root Device. Devices are conceptual objects but are identified using IP addresses. Control points contain code that controls devices or otherwise interacts with services.
Chapter 2 Iot Frameworks and ComplexIty
UPnP can be divided into six architectural elements: addressing, discovery, description, control, event notification, and presentation.
Architectural elements roughly follow six phases of UPnP service and control point interactions:
I. Addressing: Zero-touch configuration motivated the use of DHCP (Dynamic Host Configuration Protocol) so the device would automatically look for a DHCP service to obtain an IP address. If no DHCP service was available, the UPnP device will autogenerate an IP address. The device can automatically obtain a DNS name using DNS forwarding. Secure device and control point identity was not a major focus.
II. Discovery: Service discovery automation is achieved through proactive “alive” messages that are broadcast periodically to listening control points. Control points can send discovery messages
Control Point
Control Code
Root Device
Device Service Service Control Point
Control
Code Service
Figure 2-12. UPnP network nodes consist of control points and Devices that host Services
Chapter 2 Iot Frameworks and ComplexIty
85 with filters for the class of interesting service. This
approach removes the need for statically configured services enabling dynamic services (that can go online or go offline easily). Control points rely on SSDP notifications to keep them appraised of service online status. Service name URLs are public which could have privacy implications. Secure discovery was not a major focus.
III. Description: Discovery reveals the existence of UPnP devices and services, but control points may require more context to determine if they are relevant to control point applications. Device description allows introspection using an XML description of the device structure. It includes the following information:
• Vendor-specific details include manufacturer name, model, version, serial number, and URLs to vendor-specific web sites.
• Service details include URLs for control, event notification, and service description. Service commands and their parameters are detailed.
• Variables that describe Runtime state are described in terms of data type, expected range, and event characteristics.
IV. Control: Control point code is expected to identify which commands and data objects are supported by the service to construct a program sequence that uses them to achieve application objectives.
Command formatting is specified using SOAP protocol following the request- response pattern.
Chapter 2 Iot Frameworks and ComplexIty
V. Event Notification: Services built around sensors and physical devices may change internal state autonomously. Control points seeking to be appraised of service and variable state changes can register for asynchronous notifications when things change.
Notification messages are small; if the control point needs more information than is available in the notification message, it may need to follow the notification with a request-response interaction.
UPnP event notification capability is referred to as the General Event Notification Architecture (GENA).
VI. Presentation: Normally, UPnP nodes operate as headless entities. Nevertheless, users may need to monitor and control things. UPnP services can support web browser user interfaces by returning a URL to a web page markup (HTML) that exposes service variables and control widgets.