UPnP Overview

Introduction

A growing number of embedded devices are connected to TCP/IP networks. And many of these devices are no longer passive network nodes, waiting for someone else to control them. They are full-blown network citizens, actively communicating with their peers and often relying on the network services provided by other devices to do their job. For this to work, all these devices must be configured properly. Configuring the network parameters (e.g., IP address, netmask, etc.) of a device is a tedious task, as many devices do not have an appropriate user interface to do this comfortably. This is especially an issue with consumer devices, where the user might not even have the necessary technical knowledge to configure such a device. And as the number of devices in a network grows, configuring each device separately is no longer practical. There from comes the need for the automatic configuration of network devices and the automatic discovery and invocation of network services. In recent years, the industry has come up with a variety of different technologies and specifications to address this. One of these technologies is UPnP™ - Universal Plug and Play.

UPnP Technology

UPnP (Universal Plug and Play) technology offers pervasive peer-to-peer network connectivity of PCs, periperials, consumer electronics and home automation devices. The UPnP architecture is a distributed, open networking architecture based on TCP/IP and Web technologies like HTTP, XML and SOAP to enable seamless proximity networking in addition to control and data transfer among networked devices.

The UPnP Forum, founded in 1999, is the industry initiative responsible for defining the specifications and standards for UPnP technology. In addition to the UPnP Device Architecture, which forms the basis of UPnP, the UPnP Forum defines device control protocols for specific device categories such as audio/video, home automation, networking, printing, etc.

The UPnP Device Architecture

The UPnP Device Architecture is the core of the UPnP technology and defines the basic network protocol for communication among devices. The UPnP Device Architecture specifies six levels of protocols and technologies that must be implemented in a UPnP device. These are:

Addressing,
Discovery,
Description,
Control,
Eventing, and
Presentation.

Addressing

Every device must be assigned a unique network address. In case of TCP/IP networks this can be done with the help of a DHCP (Dynamic Host Configuration Protocol) server. Should, however, no DHCP server be available, another way of assigning an IP addresses must be found. Apart from manual configuration, which is often undesirable, a method called APIPA (Automatic Private IP Addressing, or AutoIP for short) is used. In this case, a device's TCP/IP stack randomly chooses an IP address in the private (link-local) IP address range 169.254.0.0 to 169.254.255.255. To prevent two or more devices from accidentally selecting the same address, each device must probe, using the ARP (Address Resolution Protocol), whether the chosen address is available.

Discovery

A user or device must be able to find a service provided by one or more devices in the network. The important part here is that the user (or device) usually does not care which device implements the service, as long as the service with specific properties is available and accessible. A typical example for service discovery is: I need to print a document in color. Give me an IP address and port number where I can send the print job to, using the Internet Printing Protocol (IPP), so that the document will be printed in color.

What all technologies for service discovery have in common is, that they make use of IP multicasting. IP multicasting uses addresses in a special address range (224.0.0.0 to 239.255.255.255). A packet (typically, a UDP packet) sent to a multicast address is received by all hosts listening to that specific address. UPnP uses SSDP - the Simple Service Discovery Protocol for that purpose.

Service discovery is implemented in the following way:

An application or device that needs a certain service sends a request describing the required properties of the service to a specific multicast address (and port number).
Other applications or devices on the same network receive the request, and if they provide the requested service themselves (or know another device that implements the service), respond with a message describing where the service can be found.
The application or device searching for the service collects all responses, and from the responses chooses the one service provider it is going to use.

In addition, devices that join or leave a network can send announcements to other devices describing the availability of the services they provide.

Description

Once a certain service has been discovered, it may be necessary to obtain more information about the service. For example, if a service consists of multiple operations, it is necessary to find out exactly what operations are supported, and what arguments must be passed to them. This is the purpose of service description.

In case only well-defined service protocols are used (e.g., HTTP, Internet Printing, or media streaming), service description is not necessary, because the only information needed to access the service is the network address (IP address and port number, or URI), and this information can be obtained by service discovery. In other cases, such as UPnP, the information obtained via service discovery may be insufficient to successfully access the service. In such a case, service discovery only returns the address of a network resource that provides detailed information about the capabilities of the service, and how to access them.

Control

After an application has obtained enough information about the services it wants to access — either via service discovery alone, or together with service description, the application will access or invoke them in order to control the device. This is usually beyond the scope of most service discovery technologies, and the domain of specialized technologies and protocols. Examples for such technologies are HTTP (HyperText Transfer Protocol), SOAP, Java RMI (Remote Method Invocation), CORBA (Common Object Request Broker Architecture), or media streaming protocols such as RTSP (Real Time Streaming Protocol). UPnP uses SOAP for service invocation.

Eventing

Eventing allows a device to notify interested parties about changes to its internal state, without requiring interested devices to actively poll its state. UPnP uses GENA, a protocol based on HTTP and XML, for eventing.

Presentation

Presentation allows a device to display a user interface that can be used for monitoring or controlling the device by a human. UPnP capable devices use web technologies — HTTP and HTML — to implement the user interface. Thus, a web browser is necessary to display such a user interface. The web browser usually does not run on the device itself, but on a PC, smartphone or network-enabled TV.