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, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking

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

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, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking

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, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking

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, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking

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, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking

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

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, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking

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

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

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.250: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: 239.255.255.250:1900 MAN: “ssdp:discover” MX: seconds to delay response ST: search target 24-Nov-18 Johan J. Lukkien, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking

Operation, in brief Responses are uni-cast, but UDP 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 <?xml version="1.0"?> <root xmlns="urn:schemas-upnp-org:device-1-0"> <specVersion> <major>1</major> <minor>0</minor> </specVersion> <URLBase>http://192.168.0.4:5431</URLBase> <device> <deviceType>urn:schemas-upnp-org:device:tvdevice:1</deviceType> <friendlyName>UPnP Television Emulator</friendlyName> <manufacturer>TV Manufacturer Name</manufacturer> <manufacturerURL>http://www.manufacturer.com</manufacturerURL> <modelDescription>UPnP Television Device Emulator 1.0</modelDescription> <modelName>TVEmulator</modelName> <modelNumber>1.0</modelNumber> <modelURL>http://www.manufacturer.com/TVEmulator/</modelURL> <serialNumber>123456789001</serialNumber> <UDN>uuid:Upnp-TVEmulator-1_0-1234567890001</UDN> <UPC>123456789</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="http://schemas.xmlsoap.org/soap/envelope/"     s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">   <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, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking

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

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, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking

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, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking

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, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking

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

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

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

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

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

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, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking

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, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking

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, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking

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, j.j.lukkien@tue.nl Eindhoven University of Technology , System Architecture and Networking