Industry pundits have been predicting the direction personal computers (PC) and consumer electronics products (CE) would eventually take. The basic technologies had all been present for some time: Widely accepted digital media formats for the delivery of audio-visual content, wired and wireless networks in the home as a backplane for device connectivity, and broadband Internet connections for high-speed access to Internet-based content. Nevertheless, the anticipated convergence of personal computers and consumer electronics remained out of reach until recently. The missing ingredient: a widely-adopted, standards-based network technology to allow devices from the personal computer and consumer electronics worlds to offer their functionalities and advertise their services to other network devices.
As a result of those efforts, standards-based products in the market are beginning to break down barriers between PC and CE devices and are providing new usage models to consumers. For example, digital media adapters (DMAs) are devices that reside in the entertainment center with outputs to the television and audio equipment and a wired or wireless connection to the home network. DMAs allow the user to view content from the PC, typically located in another room such as the den or home office, on the TV and stereo in the entertainment center. Because of the UPnP A/V standards, all of the content in the home will soon be aggregated into a single, virtual content store available to any networked UPnP A/V device.
Work in the UPnP Forum continues, with more devices and innovative usage models on the horizon. Consider digital photography. A user will soon be able to take photographs with a digital camera, bring that camera home and set it on the counter. The camera will wirelessly upload the pictures to a central storage location in the home, making those pictures available for viewing on any device capable of image display. To peruse those photos with friends, a user might sit on a couch and view the pictures on a TV. To edit those pictures, a user could access them from the PC. Personal media center devices will allow people to take their pictures with them to show their friends. There will be fewer hurdles of directly transporting pictures from one device to another - content will be automatically transferred and accessed, and all devices will have access to the same content at any time.
UPnP implicitly enables the notion of a digital home platform: an abstraction that brings coherence to previously separate islands of connectivity in the home. The digital home platform will span wired and wireless networks, entertainment devices, telephone equipment, home control, and so on, linking the various networks in the home into a single logical network of programmable devices, as shown in Figure 1.
Control points on the network, such as the PC in the den, or the television and remote control in the entertainment area, will have programmatic access to all of the devices on the network and will be able to run programs that aggregate the devices into innovative applications.
In addition, UPnP technology provides an important usability benefit: it helps transform the home computing environment from a simple PC-in-the-den model to a user- or activity-centered model. New usage models are already being developed that support activities in the home in their natural settings. For example, as we've seen with entertainment, content brought in to the PC from the Internet can be enjoyed in the home environment most suitable for music and video - the entertainment center.
In the future, user interface devices will be tailored more closely to user activities, moving beyond the simple keyboard and mouse interface. For example, in the kitchen there might be a durable and easy-to-clean touch screen display that can handle user interaction with a program running on a remote PC. The new UPnP Remote UI is designed to facilitate such a transition. Remote UI enables the separation of application logic from user interface. This will be a boon to new usage models that allow the user to interact with an application from many user interface points throughout the home.
Committees, or working groups, of the UPnP Forum build upon the common framework by collaborating to define standard device types. The UPnP Device Architecture document details the protocols and conventions required of UPnP devices, and explains the basic pattern all UPnP devices follow in their operation:
Each UPnP phase has related network protocols. The TCP/IP protocol suite and HTTP provide the basic network connectivity for UPnP. Figure 2 shows the basic UPnP protocol stack.
A few aspects of UPnP require the sender to communicate with many recipients. For example, the UPnP device discovery mechanism allows devices to send presence announcements to all of the other devices on the network, letting them know of that device's availability. For that purpose, UPnP relies on a form of HTTP that is sent over multicast UDP, called HTTPMU. In some cases, response messages are sent directly back to the source using HTTP over unicast UDP, called HTTPU. The multicast-oriented protocol stack is shown in Figure 3.
A UPnP device may also contain other devices. That logical composition of devices gives the designer flexibility when determining how to implement the device. It also allows the embedded device to be discovered and used independently from the main container device. Figure 4 shows a detailed UML class diagram for a UPnP device.
Those familiar with interface-oriented object model systems, such as Microsoft COM or CORBA, can draw an analogy: a UPnP device is similar to an object, the services are like interfaces supported by the object, and the actions in a service are like functions in an interface.
Each UPnP service also has a service type Uniform Resource Identifier (URI) that uniquely identifies the service. Standard service types are defined by a UPnP Forum working committee. Every service also has a
serviceId URI that uniquely identifies the service among all of a device's services. No two services may share the same
serviceId. The services that a device must implement are determined by the device's type. The working committees of the UPnP Forum standardize the set of services a device type must support.
Each service may also maintain variables that represent that service's current status. A service may have zero or more such variables. Each state variable has a name, a type, a default value, and a current value. It also has a set of allowed values to describe the range of permissible variable values. Any state variable can trigger events on state changes; when such events occur is determined by a service's implementer.
If a variable triggers an event to indicate a state, that variable is said to be evented. Every input argument to an action is associated with one of the service's state variables, termed the argument's related state variable. One of an action's arguments may be designated as the action's return value. The return value provides the result of the action to the caller. Figure 5 shows a UML class diagram for a UPnP service.
UPnP control points can subscribe to receive indications of state variable changes from a service. When a service detects a change to a state variable, that service notifies any registered control points of that change. For example, a service that renders audio tracks might keep a state variable of the URL of the current track being played. When the track changes, the service sends a state change notification with the new URL to all control points that have registered interest in receiving events from that service.
As the figure illustrates, a control point discovers devices, invokes actions on a device's services, and subscribes to event notifications. A device, on the other hand, responds to invoked actions, sends events when state variables change, and supports a Web page for administrative control (a presentation page in UPnP terminology).
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).
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:
Figure 8 illustrates the steps taken by a UPnP control point application to discover a device's capabilities.
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.
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.
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.
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.
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).