The Artima Developer Community
Sponsored Link

The Journal of Spontaneous Networking
It Just Works: UPnP in the Digital Home
by Michael Jeronimo
October 5, 2004

<<  Page 3 of 3


Phases of Operation


Addressing is the process by which a device automatically acquires an IP address. It is the first step in the operation of a UPnP device. Addressing allows a device to join the network and to prepare to communicate with other UPnP devices and control points. The addressing protocols built in to UPnP devices allow devices to join an IP network dynamically and to acquire an address without user configuration.

Addressing takes into account whether a device is operating in an unmanaged or managed network. An unmanaged, or ad-hoc, network is a network where there are no pre-existing infrastructure devices (or they are currently inoperable), and the network nodes themselves make up the network. A managed, or infrastructure, network allows devices to acquire an IP address from a DHCP server on the network. As a result, UPnP devices must support both the Dynamic Host Configuration Protocol (DHCP) and the dynamic configuration of private link-local addresses (Auto-IP).

A device first attempts to contact a DHCP service to acquire an address. If it fails to locate a DHCP server, the device uses Auto-IP, which enables devices to select addresses without a DHCP server being present to assign that address. The addresses are taken from a set of well-known, non-routable addresses. DHCP is a UDP-based protocol, while Auto-IP uses the Address Resolution Protocol (ARP).


Description allows devices to list the functionality they provide. Descriptions of devices and their services are contained in XML-based description documents. The device description document contains device information such as manufacturer, make, model, and serial number; a list of services provided by the device; and a list of embedded devices. A service description document contains detailed information about a device's service, the actions that service provides, and the service's parameters and return value. The description documents are used by control points in the device discovery process to learn more about a device. Figure 7 illustrates the device and service description hierarchy.

Figure 7 - The UPnP Device and Service Hierarchy


Discovery defines how a device announces its presence, and how control points discover it. A UPnP device is like a mini network server that can be discovered and controlled by a UPnP control point. The discovery process enables control points to find devices and services of interest and retrieve information about them. UPnP devices use the Simple Service Discovery Protocol (SSDP) for Discovery. SSDP extends the HTTP (Hypertext Transfer Protocol) header to provide a simple multicast-based discovery protocol.

Once a device has acquired an IP address, that device periodically advertises itself and its services on the network. A device includes a URL of its device description XML document in its advertisement and discovery responses. That URL provides control points with the information those control points need to retrieve the device and service descriptions. The description documents are retrieved by control points and parsed to understand all about that device. A vendor can add extensions beyond the basic functions and include those extensions in the description docs. That extension mechanism allows a control point to prefer an optional or vendor-specific interface over the standard one.

Every service contained in a device maintains three URLs that provide the information necessary for control points to communicate with that service:

  1. The ControlURL is where control points post requests to control the service. A UPnP device vendor specifies one for each device.

  2. The EventSubURL is where control points post requests to subscribe to events. There is one EventSubURL for each service in a device. If a service has no evented variables, that service does not have eventing. If a service does not have eventing, the EventSubURL element must be present but should be empty.

  3. The DescriptionURL tells control points the location to retrieve the service description document from. The service description XML document is returned via an HTTP GET request. Sometimes even after recognizing a UPnP Forum device type, a control point discovers individual service description documents. Since some service interfaces are optional, not all vendors may implement a particular capability. For example, a UPnP-enabled printer that does not support color printing will likely choose not to implement actions to adjust color properties.
  4. Figure 8 illustrates the steps taken by a UPnP control point application to discover a device's capabilities.

    Figure´┐Ż8 - Retrieving Device and Service Descriptions


    Control is the UPnP phase when control points invoke the actions of a device's services. When a service receives a control message, that service acts upon that message. UPnP relies on the Simple Object Access Protocol (SOAP) for device control. SOAP brings together XML and HTTP to provide a Web-based messaging and remote procedure call mechanism. XML expresses the message content, while HTTP sends messages to their destination. SOAP is specified as a set of conventions that govern the format and processing rules of SOAP messages. SOAP consists of four parts:

    The SOAP message is the basic unit of communication between peers. SOAP messages are written in XML, making SOAP platform independent: any system capable of creating and parsing XML documents can send and receive SOAP messages. The power of XML allows SOAP messages to be fairly complex in structure and to transmit highly complex data types.


    UPnP employs an event notification system using a publisher/subscriber model in which control points may subscribe to events sent by a service, and services publish event notifications to subscribers. An event is a message from a service to subscribed control points. Events keep control points informed of changes in state associated with a service. Control points subscribe to events, and the service notifies interested control points of events.

    A control point interested in receiving notification of state variable changes subscribes to an event source by sending a subscription request that includes:

    A subscription is a request to receive all state variable changes: UPnP provides no mechanism to subscribe to events on a variable-by-variable basis. If a service accepts the subscription request, that service responds with a unique subscription identifier and the duration for the subscription. The unique identifier allows the control point to refer to the subscription in subsequent requests to the service, such as renewing or canceling the subscription. The duration specifies the length of time that the subscription is valid and maintained by the service. If one or more of a service's state variables are evented, the service publishes updates to the subscribers when the variables change.

    Figure 9 shows how a control point communicates with a service to subscribe to and receive notifications of state variable changes.

    Figure 9 - State Changes and Notifications

    All subscribers are sent all event messages. Subscribers receive event messages for all evented variables, and event messages are sent regardless of the reason the state variable changed, e.g., in response to an action request or due to an internal state change. UPnP's only guarantees that a message gets delivered to a subscriber is that it the eventing protocol (GENA) uses TCP for transport.

    When a subscription expires, the subscription identifier becomes invalid, and the publisher stops sending event messages to that subscriber. If the subscriber tries to send any message other than a subscription request message - a subscription renewal request or a subscription cancellation message - the publisher rejects that message due to the invalid subscription identifier.

    All subscriptions must be renewed periodically for the control points to continue to receive notifications. To keep a subscription active, a control point must send a renewal message before that subscription expires. The renewal message is sent to the same URL as the original subscription message, but the renewal message does not include a delivery URL for event messages. Instead, the renewal message includes the subscription identifier received in the initial message accepting the subscription. When a control point no longer wants to receive events from a service, the control point can cancel its subscription.


    Presentation is the process where a device presents a browser-based user interface for manual user control and to allow viewing of that device's status. Each UPnP device contains an internal HTTP Web server and may provide a Web page for browser-based clients. That Web page serves as the device's manual interface that complements the device's programmatic SOAP-based control interface. The browser-based interface is used to control the device, to change operational parameters, to view device and service information, or for any other device-specific functionality implemented by the manufacturer. The presentation page provides a simple, consistent way to work with UPnP devices and requires no custom software.

    Superset Standards: NMPR, DLNA

    UPnP is the foundation of other home networking standards such as the Digital Living Network Alliance (formerly the Digital Home Working Group) and Intel's Networked Media Products Requirements (NMPR) specifications. These upcoming specifications add to the UPnP foundation, going beyond the basic UPnP device architecture specification to include media formats and other issues such as Digital Rights Management (DRM) to ensure a higher degree of device interoperability.

    UPnP also addresses many of the new usage models of the digital home mentioned earlier. The UPnP Remote User Interface (RUI) is a new standard recently released by the UPnP Forum. Remote UI allows for the splitting of core application logic from user interaction, with each implemented on different devices. Essentially, Remote UI moves the point of user interaction away from an application running on a specific device, such as a PC or a CE (Consumer Electronic) device, to one or more Remote UI devices. The RemoteUIClientDevice supplies input and output services such as mouse, keyboard, and display that together comprise the user interface. Applications run on a host supporting the RemoteUIServerDevice and are matched with compatible Remote UI devices.

    The new Remote UI standard will enable vendors to create devices that free the user from the location of the application. For example, a user could use an e-Book style device supporting the RemoteUIClient standard to read the evening news in a comfortable chair in the family room while the application building the user's custom newspaper is running on the desktop PC in the den and pulling in content from the Internet.


    The UPnP Device Architecture provides a common framework upon which interoperable devices and services can be built, while still allowing vendors the freedom to innovate and create interesting new device types for the digital home. UPnP technology is the foundation for higher levels of automation and new usage models in the home and office.

    Talk Back!

    Discuss this article in the Articles Forum Topic It Just Works: UPnP in the Digital Home

    About the Author

    Michael Jeronimo has been a developer for 16 years and is currently a staff software architect at Intel Corporation. His product expertise includes compilers, networking, Internet security, and software development tools for parallel processing architectures. He has four patents pending for Intel and has been actively involved in standards development with groups such as the Distributed Management Task Force (DMTF), the Internet Engineering Task Force (IETF), and the UPnP Forum. Michael recently co-authored UPnP Design By Example (with Jack Weast, Intel Press).


    Universal Plug and Play

    Digital Living Network Alliance

    Networked Media Product Requirements (NMPR)

    SOAP, XML, HTTP, and other Web Standards

    UPnP Design by Example

    Mark Walker, Jim Edwards, Michael Jeronimo, John G. Ritchie, Ylian Saint-Hilaire, Remote I/O: Freeing the Experience from the Platform with UPnP Architecture. in Intel Technology Journal, Vol. 6, Issue 4 (2002).

    <<  Page 3 of 3

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use