The Computer Communication The Computer Communication Lab (236340)Lab (236340)Spring 2005Spring 2005

Universal Plug and Play on Universal Plug and Play on Mobile PhoneMobile Phone

With Qualcomm With Qualcomm - Device -- Device -

Project TeamProject Team

• Submitted by: – Gal Zach sgalzach@t2.technion.ac.il– Einav Bar-Ner seinavba@t2.technion.ac.il

• Instructor: Constantine Elster

• Supervisor: Guy Sela

Project GoalProject Goal

Port the UPNP technology and develop a discovery protocol on Qualcomm mobile phones.

BackgroundBackground

• UPnP is 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, a small business, public spaces, or devices attached to the Internet.

• The UPnP Device Architecture defines the protocols for communication between control points and devices. In order to establish a UPnP connection the following steps have to be performed: discovery, description, control, eventing, and presentation. These steps will be discusses in detail later. UPnP uses an extended protocol stack to execute those steps.

Steps in UPnP NetworkingSteps in UPnP NetworkingStep 1 – DiscoveryStep 1 – Discovery

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 fundamental exchange in both cases is a discovery message containing a few essential specifics about the device or one of its services, e.g., its type, identifier, and a pointer to more detailed information.

Steps in UPnP NetworkingSteps in UPnP NetworkingStep 2 – DescriptionStep 2 – Description

The information supplied in the discovery step is not enough for the control point to learn about the device and its capabilities, or to interact with it. The control point uses the URL, provided in the discovery step, to retrieve the required information. The UPnP description for a device is partitioned into two: a device description describing the physical and logical containers, and one or more service descriptions describing the capabilities exposed by the device. In order to retrieve the service/device's description, the control point issues an HTTP GET request to the URL in the discovery message, and the device returns its description in the body of an HTTP response

Steps in UPnP NetworkingSteps in UPnP NetworkingStep 3 – ControlStep 3 – Control

After getting the information about the device and its services, the control point can ask those services to invoke actions. When an action is completed (or failed), the service returns the action's results or errors. In case of a non-evented variable (will be explained in step 4 – eventing), the control point can poll the service for the variable's value.

Steps in UPnP NetworkingSteps in UPnP NetworkingStep 4 – EventingStep 4 – Eventing

• A UPnP service description includes a list of actions the service responds to and a list of variables that model the state of the service at run time. If one or more of these state variables are changed during the service's run time, the service publishes updates, and a control point may subscribe to receive this information.

• Some state variables may change value too rapidly or may contain very large values. For this, or other reasons, a service may designate one or more state variables as non-evented and never send event messages to subscribers. To determine the current value for such non-evented variables, control points must poll the service explicitly.

Steps in UPnP NetworkingSteps in UPnP NetworkingStep 5 – PresentationStep 5 – Presentation

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, allow a user to control the device and/or view device status.

Project DescriptionProject Description

The current implementation contains the root device and one service that has one action.

The service is a calculator and its action calculates the cosinus of an angle. The service’s state variable determines whether the calculation is performed in degrees or radians. The service changes the state variable frequently.

Project Description – Cont.Project Description – Cont.

Note:

The implementation does not perform multicast transmissions (although defined in the protocol) since it is not supported in the Brew simulator.

Project Description – Cont.Project Description – Cont.

The project contains the following modules:1. utilities

2. upnpdevice

3. parsers

4. headers

5. discovery

6. description

7. Control

8. Eventing

Utilities ModuleUtilities Module

This module contains general functions that do not depend on the device’s structures.

Examples:• Printing to the simulator’s screen.• Common conversions.

Upnpdevice ModuleUpnpdevice Module

This module contains the basic steps for initializing and cleaning up the system, and the basic operations for communicating over the network.

It contains the following structures:1. STUpnpDevice – This is the structure required by the

Brew simulator for keeping the global variables. There is only one instance of this structure.Main members:

• Socket to listen on TCP incoming messages.• Socket to listen on UDP incoming messages.• Socket to send alive calls. • List of subscribers.

Upnpdevice Module – Cont.Upnpdevice Module – Cont.

• List of services.

2. STSubscriber –Defines a subscriber. Main members:• Subscription ID.• IP and port to send events.• The service id the subscriber is subscribed to.• Pointer to the STUpnpDevice structure.• Event key – the number of events sent to the subscriber.

3. STUserSession – Defines a session. Main members:• Pointer to the STUpnpDevice structure.• Pointer to the socket.• Pointer to the message buffer.

4. STService – Defines a service. Main members:• Service id.• IP and port the service is listening on.• State variable name and value. (Should be )

Parsers ModuleParsers Module

This module contains parsers for all kind of received messages.

Note:

No parsing for xml messages.

Headers ModuleHeaders Module

This module contains functions to build the different packets of the protocol.

Discovery ModuleDiscovery Module

This module performs all operations that required for the Discovery step, i.e. send alive calls, responses to m-search, and byebye messages.

Description ModuleDescription Module

This module performs operations that required for the Description step.

Note:

In the current implementation the description files of the device and service exist in the project directory and are loaded from there.

Control ModuleControl Module

This module performs operations that required for the Control step, i.e. invoking action and querying state variable.

Eventing ModuleEventing Module

This module performs operations that required for the Eventing step.

Note:

The implementation supports multi-subscribers.

Modules Relations Modules Relations

eventingeventing

controlcontrol

discoverydiscovery

utilitiesutilities

upnpdeviceupnpdevice

headersheaders

parsersparsers

descriptiondescription

Data StructuresData Structures

STUpnpDeviceSTUpnpDevice

STSubscriberSTSubscriber

STSubscriberSTSubscriber

STSubscriberSTSubscriber

STServiceSTService

STServiceSTService

STServiceSTService

STStateVarSTStateVarSTStateVarSTStateVar

DemonstrationDemonstration

The demonstration uses a control point stub and contains 2 demos.

Each message that the control point receives from the device is written into a file corresponding to the type of the message.

Messages from the same type are concatenated to the same file.

Demo 1Demo 1

1. The control point waits for alive calls.2. The device starts and automatically sends alive

messages every minute.3. The device receives m-search message and sends

response.4. The device receives request for the device description

and sends the device description to the control point.5. The device receives request for the service description

and sends the service description to the control point.6. The device receives request to invoke action and

sends the result to the control point.

Demo 1 – Cont.Demo 1 – Cont.

7. The device receives query of state variable and sends the response to the control point.

8. The device receives subscription request for 20 seconds. Update with SID = 1.

9. The device sends event messages to the subscriber every 15 seconds.

10. After 10 seconds the device receives re-subscription request from the same subscriber for 40 seconds. The device continue sending event messages to the subscriber.

11. 40 seconds later the device removes the subscriber from the subscribers list and stop sending him event messages.

Demo 2Demo 2

1. The control point waits for alive calls2. The device sends alive messages every minute.3. The device receives subscription request for 60 seconds. Update

with SID = 2. 4. The device receives subscription request for 60 seconds. Update

with SID = 3.5. Both subscribers receive event messages.6. After 20 seconds the device receives un-subscribe message from

the subscriber with SID = 2. The device removes this subscriber from the subscribers list and stop sending him event messages.

7. After 60 seconds the device removes the subscriber with SID = 3 from the subscribers list and stop sending him event messages.

8. The device sends byebye message to the control point and disconnect.