Welcome to BBTECH Lab

Technical Note for Developing Embedded Media Devices, Set-Top-Boxes, Broadband TV, DVR, etc.

[DLNA][1]UPnP Technical Basic

[DLNA][1]UPnP Technical Basic

I. What is UPnP Technology

Refer to [UPnP™ Device Architecture 1.1]

Plug and Play (PnP) means that you can connect a device or insert a card into your computer and it is automatically recognized and configured to work in your system.

Figure 1. Universal Plug and Play UPnP

UPnP extends this simplicity to include the entire network, enabling discovery and control devices, including networked devices and services, such as network-attached printers, internet gateway.

  • A device can dynamically join a network, obtain an IP address.
  • Convey its capabilities, and learn about the presence and capabilities of other devices.
  • All automatically; truly enabling zero configuration networks.

The UPnP technology was promoted by the UPnP Forum, http://www.upnp-ic.org.

UPnP™ technology defines an architecture for pervasive peer-to-peer network connectivity of intelligent appliances, wireless devices, and PCs of all form factors. It is designed to bring easy-to-use, flexible, standards-based connectivity to ad-hoc or unmanaged networks whether in the home, in a small business, public spaces, or attached to the Internet.

UPnP technology provides a distributed, open networking architecture that leverages TCP/IP and Web technologies to enable seamless proximity networking in addition to control and data transfer among networked devices.

UPnP technology provides a distributed, open networking architecture that leverages TCP/IP and Web technologies to enable seamless proximity networking in addition to control and data transfer among networked devices.

The UPnP Device Architecture (UDA) is more than just a simple extension of the plug and play peripheral model. It is designed to support zero-configuration, “invisible” networking, and automatic discovery for a breadth of device categories from a wide range of vendors. This means a device can dynamically join a network, obtain an IP address, convey its capabilities, and learn about the presence and capabilities of other devices. Finally, a device can leave a network smoothly and automatically without leaving any unwanted state behind.

UPnP architecture include Internet protocols:

  • IP
  • TCP
  • UDP
  • HTTP
  • XML

What is “universal” about UPnP technology? No device drivers; common protocols are used instead. UPnP networking is media independent. UPnP devices can be implemented using any programming language, and on any operating system. The UPnP architecture does not specify or constrain the design of an API for applications; OS vendors may create APIs that suit their customers’ needs.

UPnP Protocol Stack

Figure 2. UPnP Protocol Stack
  • UPnP vendor-specific information about their devices.
  • Vendor content is supplemented by information defined by UPnP Forum working committees.
  • The Simple Service Discovery Protocol (SSDP) is delivered via either multicast or unicast UDP.
  • Multicast events are delivered ia multicast UDP.
  • The General Event Notification Architecture (GENA) is delivered via HTTP.

UPnP network components as below

Figure 3. UPnP Network Components
  • Two general classifications of devices are defined by the UPnP architecture: controlled devices (or simply “devices”), and control points.
    • A controlled device functions in the roles of a server, responding to requests from control points.
    • Both control points and controlled devices can be implemented on a variety of platforms including personal computers and embedded systems.
    • Multiple devices, control points, or both may be operational on the same network endpoint simultaneously.
  • Device
    • Advertise when added to UPnP network.
    • Refresh advertisements.
    • Cancel advertisements when removed.
  • Control Points is a controller capable of discovering and controlling other devices.
    • Finds interesting device.
    • Retrieve the device description and get a list of associated services.
    • Retrieve service descriptions for interesting services.
    • Invoke actions to control the service.
    • Subscribe to the service’s event source. Anytime the state of the service changes, the event server will send an event to the control point.
    • Interacts with a device with sequences of commands and events.
Figure 4. UPnP Control Point
  • The smallest unit of control in an UPnP network is a service. A service exposes actions and models its state with state variables. It consists of a state table, a control server and an event server.
    • The state table models the state of the service through state variables and updates them when the state changes.
    • The control server receives action requests (such as set_time), executes them, updates the state table and returns responses.
    • The event server publishes events to interested subscribers anytime the state of the service changes.

Figure 5. Example a simple UPnP Network (Control Point/ Media Render/ Media Server)

II. How UPnP Works

UPnP is being phased over a number of steps as below

Figure 6. UPnP Phases

0 Addressing/ Control points and devices get IP addresses: Using DHCP (, or AutoIP).

1 Discovery/ Control point finds interesting device: When a device is added to the network, the UPnP discovery protocol allows that device to advertise its services to control points on the network. Similarly, when a control point is added to the network, the UPnP discovery protocol allows that control point to search for devices of interest on the network. The section on Discovery below explains how devices advertise, how control points search, and contains details about the format of discovery messages.

2 Description/ Control point learns about device capabilities: After a control point has discovered a device, the control point still knows very little about the device. For the control point to learn more about the device and its capabilities, or to interact with the device, the control point must retrieve the device’s description from the URL provided by the device in the discovery message. Devices may contain other logical devices, as well as functional units, or services. The UPnP description for a device is expressed in XML and includes vendor-specific manufacturer information like the model name and number, the serial number, the manufacturer name, URLs to vendor-specific Web sites, etc.

For each service, the description includes a list of the commands, or actions, to which the service responds, and parameters, or arguments for each action; the description for a service also includes a list of variables; these variables model the state of the service at run time, and are described in terms of their data type, range, and event characteristics.

3 Control/ Control point invokes actions on device: After a control point has retrieved a description of the device, the control point can send actions to a device’s services. To do this, a control point sends a suitable control message to the control URL for the service (provided in the device description). Control messages are also expressed in XML using the Simple Object Access Protocol (SOAP).

4 Eventing/ Control point listens to state changes of device: A UPnP description for a service includes a list of actions the service responds to and a list of variables that model the state of the service at run time. The service publishes updates when these variables change, and a control point may subscribe to receive this information. The service publishes updates by sending event messages. Event messages contain the names of one or more state variables and the current value of those variables. These messages are also expressed in XML. A special initial event message is sent when a control point first subscribes; this event message contains the names and values for all evented variables and allows the subscriber to initialize its model of the state of the service.

Through multicast eventing is inherently unreliable since it is based on UDP, control points can listen to state changes in services without subscription.

5 Presentation/ Control point interacts with a device with sequences of commands and events: If a device has a URL for presentation, then the control point can retrieve a page from this URL, load the page into a browser, and depending on the capabilities of the page, and allow a user to control the device and/or view device status.

2.1 Step 0: Addressing

The foundation for UPnP networking is the TCP/IP protocol suite and the key to this suite is addressing.

Each device must have a Dynamic Host Configuration Protocol (DHCP) client and search for a DHCP server when the device is first connected to the network.

If a DHCP server is available, the device or control point MUST use the IP address assigned to it. Others, the device or control point MUST use Auto IP to get an address. Auto IP defines how a device or control point intelligently chooses an IP address from a set of reserved addresses and is able to move easily between managed and unmanaged networks.

If during the DHCP transaction, the device or control point obtains a domain name, e.g., through a DNS server or via DNS forwarding, the device or control point should use that name in subsequent network operations; otherwise, the device or control point should use its IP address.

2.2 Step 1: Discovery

Once devices are attached to the network and addressed appropriately, discovery can take place.

When a device is added to the network, SSDP allows that device to advertise its services to control points on the network.

When a control point is added to the network, SSDP allows that control point to search for devices of interest on the network.

The fundamental exchange in both cases is a discovery message containing a few, essential specifics about the device or one of its services, for example its type, identifier, and a pointer to its XML device description document.

3.2.1 MULTICAST

UPnP uses multicast to discover UPnP devices on the same network.

Sender

  • Just join & sending packet by using a multicast ip.

Receiver

  • In order to receive the multicast packet, IGMP protocol must be used.
  • IGMP is used between router & receiver.
  • You can check the joined multicast address.

for understanding in more detail, let see an example as below

Figure 7. Flow of Multicast Example

This is the receiver:

/* Start Including Header Files */
#include 
#include 
#include 
#include 
#include 
#include 
/* End Including Headers */

struct sockaddr_in    localSock;
struct ip_mreq        group;
int                   sd;
int                   datalen;
char                  databuf[1024];
int main (int argc, char *argv[])
{
    /*
    * Create a datagram socket on which to receive.
    *
    */
    sd = socket(AF_INET, SOCK_DGRAM, 0);
    if (sd < 0)
    {
        perror("opening datagram socket");
        exit(1);
    }
    /*
    * Enable SO_REUSEADDR to allow multiple instances of this
    * application to receive copies of the multicast datagrams.
    *
    */
    {
        int reuse=1;

        if (setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, (char *)&reuse, sizeof(reuse)) < 0)
        {
            perror("setting SO_REUSEADDR");
            close(sd);
            exit(1);
        }
    }

    /*
     * Bind to the proper port number with the IP address
     * specified as INADDR_ANY.
     *
     */
    memset((char *) &localSock, 0, sizeof(localSock));
    localSock.sin_family = AF_INET;
    localSock.sin_port = htons(1900);;
    localSock.sin_addr.s_addr  = INADDR_ANY;

    if (bind(sd, (struct sockaddr*)&localSock, sizeof(localSock)))
    {
        perror("binding datagram socket");
        close(sd);
        exit(1);
    }


    /*
    * Join the multicast group 239.255.255.250 on the local 192.168.0.35
    * interface.  Note that this IP_ADD_MEMBERSHIP option must be
    * called for each local interface over which the multicast
    * datagrams are to be received.
    *
    */
    group.imr_multiaddr.s_addr = inet_addr("239.255.255.250");
    group.imr_interface.s_addr = inet_addr("192.168.0.32");
    if (setsockopt(sd, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char *)&group, sizeof(group)) < 0)
    {
        perror("adding multicast group");
        close(sd);
        exit(1);
    }

    /*
     * Read from the socket.
     */
    while(1)
    {
        datalen = sizeof(databuf);
        if (read(sd, databuf, datalen) < 0)
        {
            perror("reading datagram message");
            close(sd);
            exit(1);
        }
        else
        {
            printf("%s\n", databuf);
        }
    }

    return 0;
}

/*********************** End of File ******************************/
Figure 8. Example Receiver on Computer 3
Figure 9. Packet sender on Computer 1, sending packet “hello” to multicast group: 239.255.255.0
Figure 10. Wireshark on Computer 2 captures data packet received by packet sender on Computer 1 (192.168.0.32)
Figure 11. Wireshark on Computer 2 (192.168.0.32) checks the joining multicast group of Receiver that is running on Computer 3 (192.168.0.35)
bamboo@vietnam:~/work/DLNA/upnp$ ./Receiver
hello
Figure 12. Receiver print result on Computer 3 (192.168.0.35)

2.3 Step 2: Description

2.4 Step 3: Control

2.5 Step 4: Eventing

2.6 Step 5: Presentation

bbtechlab