The Journal of Spontaneous Networking
It Just Works: UPnP in the Digital Home
by Michael Jeronimo
September 30, 2004
<< Page 5 of 5
Phases of Operation
Addressing
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 devices 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
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
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 devices include a URL of its device description
XML document in their advertisements 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:
- The ControlURL is where control points post requests to control
this service. A UPnP device vendor specifies one for each device.
- The EventSubURL is where control points post requests to
subscribe to events. The event subscription URL must be unique within the device; no
two services may have the same URL for eventing. 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.
- 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 introspects 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.
Figure 8 illustrates the steps taken by a UPnP control point application to discover
and introspect a device's capabilities.
Figure 8 - Retrieving Device and Service Descriptions
Control
Control is the UPnP phase to 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 envelope An XML schema that defines a framework for
describing what is in a message, how to process it, and whether that processing is
optional or mandatory.
- The SOAP encoding rules Another XML schema that defines a set of
rules for expressing instances of application-defined data types.
- The SOAP binding A convention for using different transport
protocols. SOAP can potentially be used in combination with a variety of other
transport protocols (however SOAP messages are most commonly carried by HTTP).
- The SOAP RPC representation A convention for representing remote
procedure calls and responses.
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.
Eventing
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:
- The service of interest
- A URL to which the events can be sent
- A subscription time for the event notification
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.
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, for example - 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
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.
Summary
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.
Resources:
Universal Plug and Play
http://www.upnp.org
Digital Living Network Alliance
http://www.dlna.org
Networked Media Product Requirements (NMPR)
http://www.intel.com/technology/dhdevnet
SOAP, XML, HTTP, and other Web Standards
http://www.w3c.org
UPnP Design by Example
http://www.amazon.com
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).
<< Page 5 of 5
