<<  Page 2 of 3  >>

Advertisement

The UPnP Device Architecture

UPnP is built upon existing protocols and formats including HTTP, XML, SOAP, the Document Object Model, and IP multicast. Those elements are used together to define a framework to enable the definition, discovery, and control of network devices.

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:

• Addressing: The device joins the network, acquiring a unique address that entities can use to communicate with the device
  
• Description: The device summarizes its services and capabilities in a standard format
  
• Discovery: The device is found by control points that learn about the device's capabilities by retrieving a device description
  
• Control: The device handles requests from control points
  
• Eventing: The device notifies registered control points of internal state changes
  
• Presentation: The device provides an HTML-based administrative interface to allow for direct manipulation and monitoring of the device
  

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.

Figure 2 - The 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.

Figure 3 - HTTPMU and HTTPU protocol stack

Devices

A UPnP device can be thought of as a logical container with a unique type. Each UPnP device may offer any number of services, each service with its own unique service type. By itself, a device does nothing more than provide self-describing information such as the manufacturer, model name, and serial number. A device's services provide the real functionality.

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.

Figure 4 - Class diagram: the UPnP Device

Services

Each service in a UPnP device may contain any number of actions, each action having a set of input parameters and an optional return value. Each action also has a name and an optional set of arguments. Each argument has a name, a value, and a direction. The direction may be either input or output (but not both), depending on whether the argument is passed into the action or is returned from the action to the caller. Each action may also have a return value that provides the result of the action.

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.

Figure 5 - Class diagram: the 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.

Control Points

A control point is a network entity that invokes a device's functionality. In client/server computing terms, the control point is the client and the device is the server. Control points invoke actions on services, providing any required input parameters and receiving any output parameters and possibly a return value. Figure 6 shows a control point invoking an action on a UPnP-enabled device that implements a single UPnP device type containing two services.

Figure 6 - A control point invoking an action on a 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).

<<  Page 2 of 3  >>

Spontaneous Networking | Jini Community News | Discuss | Print | Email | First Page | Previous | Next