1. Implementation and validation of UPnP in 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
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

2. Overview Background Services Universal Plug ‘n Play
Prototype & Results
Open ends and conclusions
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

3. Background Home networking User requirements for consumer equipment
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
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

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
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

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
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

6. Service, issues Using the service both parties on equal footing
Control: from client to service
Eventing: service to client(s)
both parties on equal footing
Efficiency
in setting up & using
0 Addressing & naming
1 Discovery & advertisement
2 Description
3 Control
4 Eventing
5 Presentation
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

7. Overview Background Services Universal Plug ‘n Play
Prototype & Results
Open ends and conclusions
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

8. Application(HTTP,SMTP)
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
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

9. Middleware and interoperability
Interoperability concerns both
interface
protocol
(see e.g. Distributed Systems, principles & paradigms, Tanenbaum & van Steen)
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

10. UPnP at work Two roles: device & control point
Device: service container
Root device: can
contain other
devices
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

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: :1900
CACHE-CONTROL: max-age = seconds until advertisement expires
LOCATION: URL for UPnP description for root device
NT: search target
NTS: ssdp:alive
USN: advertisement UUID
M-SEARCH * HTTP/1.1
HOST: :1900
MAN: “ssdp:discover”
MX: seconds to delay response
ST: search target
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

12. Operation, in brief Responses are uni-cast, but UDP
HTTP/ OK
CACHE-CONTROL: max-age = seconds until advertisement expires
LOCATION: URL for UPnP description for root device
ST: search target
USN: advertisement UUID
<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:tvdevice:1</deviceType>
<friendlyName>UPnP Television Emulator</friendlyName>
<manufacturer>TV Manufacturer Name</manufacturer>
<manufacturerURL>
<modelDescription>UPnP Television Device Emulator 1.0</modelDescription>
<modelName>TVEmulator</modelName>
<modelNumber>1.0</modelNumber>
<modelURL>
<serialNumber> </serialNumber>
<UDN>uuid:Upnp-TVEmulator-1_ </UDN>
<UPC> </UPC>
………………..
POST path of control URL HTTP/1.1 HOST: host of control URL:port of control URL CONTENT-TYPE: text/xml; charset="utf-8" SOAPACTION: "urn:schemas-upnp-org:service:serviceType:v#actionName"
<s:Envelope xmlns:s="     s:encodingStyle="   <s:Body>   <u:actionName xmlns:u="urn:schemas-upnp-org:service:serviceType:v">       <argumentName>in arg value</argumentName>       other in args and their values (if any) go here     </u:actionName>   </s:Body> </s:Envelope>
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
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

13. Overview Background Services Universal Plug ‘n Play
Prototype & Results
Open ends and conclusions
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

14. UPnP API prototype
Evaluate the use, trying it for several sample applications
ease of use (device builder’s perspective)
identify shortcomings, improvements
Evaluate performance properties
scalability
size
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

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
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

16. UPnP architecture (defn’d by forum)
UPnP Vendor Defined
UPnP Forum Working Committee Defined
UPnP Device Architecture Defined
SOAP
(Control)
HTTP
SSDP
GENA
SSDP
HTTPMU
(Discovery)
HTTPU
(Discovery)
HTTP
(Description)
GENA
(Events)
UDP
TCP IP
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

17. Our prototype 24-Nov-18 Johan J. Lukkien, j.j.lukkien@tue.nl
Eindhoven University of Technology , System Architecture and Networking

18. Device overview 24-Nov-18 Johan J. Lukkien, j.j.lukkien@tue.nl
Eindhoven University of Technology , System Architecture and Networking

19. Control point overview
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

20. Examples Build a TV remote control Control a coffee maker 24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

21. Screenshot 24-Nov-18 Johan J. Lukkien, j.j.lukkien@tue.nl
Eindhoven University of Technology , System Architecture and Networking

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)
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

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-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

24. Conclusion (3/3)
Want to use it for controlling two parties to cooperate
control point
device: source
device: sink
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking

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
24-Nov-18
Johan J. Lukkien,
Eindhoven University of Technology , System Architecture and Networking