The Computer Communication Lab (236340) Spring 2005 Universal Plug and Play on Mobile Phone With Qualcomm - Device -

Project Team Submitted by: –Gal –Einav Instructor: Constantine Elster Supervisor: Guy Sela

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

Background 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 Networking Step 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 Networking Step 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 Networking Step 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 Networking Step 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 Networking Step 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 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. 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. The project contains the following modules: 1.utilities 2.upnpdevice 3.parsers 4.headers 5.discovery 6.description 7.Control 8.Eventing

Utilities 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 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. 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 Module This module contains parsers for all kind of received messages. Note: No parsing for xml messages.

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

Discovery 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 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 Module This module performs operations that required for the Control step, i.e. invoking action and querying state variable.

Eventing Module This module performs operations that required for the Eventing step. Note: The implementation supports multi- subscribers.

Modules Relations eventing control discovery utilities upnpdevice headers parsers description

Data Structures STUpnpDevice STSubscriber STSubscriber STSubscriber STService STService STService STStateVarSTStateVar

Demonstration 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 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. 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 seconds later the device removes the subscriber from the subscribers list and stop sending him event messages.

Demo 2 1.The control point waits for alive calls 2.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.