Docstoc

upnp

Document Sample
upnp Powered By Docstoc
					The Computer Communication
       Lab (236340)
       Spring 2005
    Universal Plug and Play on
          Mobile Phone
         With Qualcomm
            - Device -
             Project 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 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
discovery                         parsers




description         upnpdevice



                                  utilities

control



                                  headers


eventing
          Data Structures
                  STUpnpDevice



STSubscriber                         STService


STSubscriber                         STService


STSubscriber                         STService




               STStateVar        STStateVar
            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.
11.   40 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.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:2/16/2012
language:
pages:28