Johan J. Lukkien, [e-mail]

1
Implementation and validation of UPnPin a home
networking environment

• T. Tranmanh
• L.M.G. Feijs
• J.J. Lukkien
• Eindhoven University of Technology
• The Netherlands
• IASTED, CITT, November 18-20, 2002
• St. Thomas, Virgin Islands

2
Overview

• Background
• Services
• Universal Plug n Play
• Prototype Results
• Open ends and conclusions

3
Background

• Home networking
• many networking standards
• little or no common backbone
• diverse application domains
• domotica, data, A/V
• User requirements for consumer equipment
• absolutely automatic configuration
• no, or at most once, user intervention
• zero config
• integration!
• logical cooperations should work
• increase in dynamic, mobile equipment

4
Service, definition

• Service provided functionality in terms of
  actions, (autonomous) responses and state changes
  of an object as well as the properties of
  sequences of these events.
• In home automatic!

Services
5
Service, issues

• Difference between device and service
• device contains services
• Addressing naming
• intentional name type
• address how to reach the service or its
  containing device
• Advertisement and discovery
• centralized or distributed
• Description
• exactly what it is and how to use it

6
Service, issues

• Using the service
• Control from client to service
• Eventing service to client(s)
• both parties on equal footing
• Efficiency
• in setting up using

7
Overview

• Background
• Services
• Universal Plug n Play
• Prototype Results
• Open ends and conclusions

8
Universal Plug n Play

• Place in the protocol stack middleware

Application
Application(HTTP,SMTP)
UPnP API
Transport(TCP,UDP)
HTTP (extension)
UPnP
Network(IP)
Link(Ethernet,PPP)
Physical
9
Middleware and interoperability

• Interoperability concerns both
• interface
• protocol
• (see e.g. Distributed Systems, principles
  paradigms, Tanenbaum van Steen)

10
UPnP at work

• Two roles device control point
• Device service container
• Root device can
• contain other
• devices

11
Operation, in brief

• Upon joining the network, a device obtains an IP
  address
• DHCP or auto-IP
• is in fact unimportant to UPnP core
• though determines some performance
  characteristics
• A device multicasts its services
• Simple Service Discovery Protocol
• uses GENA messages with HTTP multicast
• (General Event Notification Architecture)
• A control point multicasts service requests
• same protocol

NOTIFY HTTP/1.1 HOST 239.255.255.2501900 CACHE
-CONTROL max-age seconds until advertisement
expires LOCATION URL for UPnP description for
root device NT search target NTS
ssdpalive USN advertisement UUID
M-SEARCH HTTP/1.1 HOST 239.255.255.2501900 MAN
ssdpdiscover MX seconds to delay
response ST search target
12
Operation, in brief
HTTP/1.1 200 OK CACHE-CONTROL max-age seconds
until advertisement expires LOCATION URL for
UPnP description for root device ST search
target USN advertisement UUID
lt?xml version"1.0"?gt ltroot xmlns"urnschemas-up
np-orgdevice-1-0"gt ltspecVersiongt
ltmajorgt1lt/majorgt ltminorgt0lt/minorgt
lt/specVersiongt ltURLBasegthttp//192.168.0.45431lt
/URLBasegt ltdevicegt ltdeviceTypegturnschemas-u
pnp-orgdevicetvdevice1lt/deviceTypegt
ltfriendlyNamegtUPnP Television Emulatorlt/friendlyNa
megt ltmanufacturergtTV Manufacturer
Namelt/manufacturergt ltmanufacturerURLgthttp//ww
w.manufacturer.comlt/manufacturerURLgt
ltmodelDescriptiongtUPnP Television Device Emulator
1.0lt/modelDescriptiongt ltmodelNamegtTVEmulatorlt/
modelNamegt ltmodelNumbergt1.0lt/modelNumbergt
ltmodelURLgthttp//www.manufacturer.com/TVEmulator/lt
/modelURLgt ltserialNumbergt123456789001lt/serialN
umbergt ltUDNgtuuidUpnp-TVEmulator-1_0-123456789
0001lt/UDNgt ltUPCgt123456789lt/UPCgt ..

• Responses are uni-cast, but UDP
• Control point obtains device description
• in XML, through an embedded HTTP server
• description contains, in fact, service interfaces
  and state variables
• Control messages are sent using SOAP
• HTTP messages
• Event messages are sent using GENA
• HTTP messages

POST path of control URL HTTP/1.1HOST host of
control URLport of control URLCONTENT-TYPE
text/xml charset"utf-8"SOAPACTION
"urnschemas-upnp-orgserviceserviceTypevaction
Name" ltsEnvelope xmlnss"http//schemas.xmlsoa
p.org/soap/envelope/"    sencodingStyle"http//
schemas.xmlsoap.org/soap/encoding/"gt  ltsBodygt 
ltuactionName xmlnsu"urnschemas-upnp-orgservic
eserviceTypev"gt      ltargumentNamegtin arg
valuelt/argumentNamegt      other in args and
their values (if any) go here   
lt/uactionNamegt  lt/sBodygtlt/sEnvelopegt
13
Overview

• Background
• Services
• Universal Plug n Play
• Prototype Results
• Open ends and conclusions

14
UPnP API prototype

• Evaluate the use, trying it for several sample
  applications
• ease of use (device builders perspective)
• identify shortcomings, improvements
• Evaluate performance properties
• scalability
• size

15
Performance questions

• How often do devices join and leave a network?
• once per day, several per hour or minute?
• a whole bunch joining at once?
• How frequent are control notification messages?
• constant streams? once per minute, hour?
• bursts? (emulated multicast)
• Round trip requirements?
• e.g. user interface

16
UPnP architecture (defnd by forum)
UPnP Vendor Defined
UPnP Forum Working Committee Defined
UPnP Device Architecture Defined
HTTP
SOAP (Control)
SSDP
GENA
SSDP
HTTPMU (Discovery)
HTTPU (Discovery)
HTTP (Description)
GENA (Events)
UDP
TCP
IP
17
Our prototype
18
Device overview
19
Control point overview
20
Examples

• Build a TV remote control
• Control a coffee maker

21
Screenshot
22
Conclusion (1/3)

• Full functionality in 85.7K compiled Java code
• Naming IP address
• addresses the NIC, not the device
• IP address may be moving target
• multicasting is limited
• Scaling
• service discovery linear in number of terminals
• number of listeners
• multicasting overhead linear
• http overhead per message unacceptable (/- 100
  ms)

23
Conclusion (2/3)

• Easy to build control device points
• Easy to integrate non-UPnP devices
• Focus on data exchange
• neutral w.r.t. API, language
• however, portability requires API standardization
• simple-advanced implementations possible
• Searching
• you need to know what you are looking for
• More services of same type faster discovery

24
Conclusion (3/3)

• Want to use it for controlling two parties to
  cooperate

control point
device source
device sink
25
Embedded intelligence

• Intelligence stack
• For adding intelligent behavior, a layer
  supporting access and discovery is needed
• first, connecting users and machines
• then, connecting machines
• The perspective is machines interpreting the
  information
• rule base
• onthologies
• Ingredients self-description, self-model