E N D
1. Update Management of Devices in Home Networks Based on OSGi Thorsten Dobelmann
Hochschule der Medien Stgt.
31st May 2005
2. Agenda Home Networks – Technology Overview
Update Management – What and Why?
Requirements
Research – Current Solutions
Repair Service Scenario
Residential Gateway: Integration
OSGi as Residential Gateway Middleware
Prototype
Demonstration
3. Introduction – Home Network & Technologies
4. Update Management – Characteristics More and more often, functionality is determined by device software or firmware
Device software is platform-dependent to a high degree
Increasing functionality, increasing speed of change
Increasing complexity and error-proneness
Fix bugs or extend functionality, maintain devices
Large number of devices, highly distributed
5. Update Management – Requirements Simply: Equip specific device with appropriate software or firmware in an automated manner
Little or no interaction by the end user
Independent of underlying device types and data transfer technologies
Based on open standards or integration of different platforms4Interoperability
6. Research – Current Solutions Cable Modems: DOCSIS standard, update via TFTP
Set Top Boxes: SSU standard (DVB), transferred together with TV data via cable, installed automatically and remotely
Automotive: Wireless and encrypted transfer of software packages, received by car in question, driver asked to install
Smartphones: OMA-DM (SyncML-DM), determine the appropriate software and install it remotely „over the air“ (FOTA).
Other device types: No initiatives identified (exception: CHAIN)
No device type or technology overlapping initiative
7. Repair Service Scenario – Overview
8. Repair Service Scenario – Main Components Service Provider: determines matching software image for specific device, has to offer access to a software service to other components via a WAN
Software Repository: database or file server holding the images
Device: needs to be updateable and offer remote updating, needs to deliver information about the device: manufacturer, model, serial number and software version
Residential Gateway: 4next
9. Residential Gateway Acts as a central control point
Offers physical interfaces to devices or networks
Provides integration for various technologies
Offers middleware as a software platform, extendable by software building blocks
Software components responsible for communication with devices, allows for cooperation among different systems4Chosen software platform: OSGi
10. OSGi – Key Components Java-based runtime environment for software components4platform-independent and portable
Services: Software components defined by interfaces, access only via interfaces
Bundles: Deployment format of OSGi software components;life cycle can be controlled: install, uninstall, update, start, stop, remote installation
Service Registry: “Service Database“, advertise services and retrieve services
Reduced memory consumption: different applications in same JVM(code sharing)
11. OSGi – Device Access Base Driver: discovers (new) devices, adds devices service to the registry
Device Service: represents a specific device, allows access to the device.
Refinement Driver: refine existing device services
Device Manager
12. OSGi – Import / Export
13. Prototype – Flow Repair Service Agent (RSA) accesses Residential Gateway (RGW)
RGW determines available devices, and gathers information about them (serial, software version...), displays them in a list
RSA selects a device
RGW retrieves update information from Service Provider (SP)based on device information
RGW displays available updates for device
RSA selects an update
RGW downloads update image and stores it temporarily
RGW transfers the update image to the device
14. Prototype – Device Preferably self-organizing technologies (“zero configuration“), therefore:
Device simulation (washing machine) is UPnP-enabled
There is no UPnP-standardized update service4self-defined!
Defined service to retrieve current software version and to initiate and transfer update image
15. Prototype – GUI HTML pages
Based on servlets stored on the OSGi platform of the Residential Gateway
Access services of the OSGi platform to accomplish their tasks4later
16. Prototype – Service Provider Service Provider is implemented as a Web Service
Web Service offers access to update information and update images themselves
Based on SOAP
Information and images stored in simple (MySQL) database
17. Prototype – Residential Gateway (1) Update Service is defined to handle the control flow
Therefore: definition of adequate interfaces of the service
Interfaces are defined technology-independent 4Technology Integration
Integration of several technologies:Interfaces have to be implemented for each possible technology
Here: 2 implementations (UPnP)
Update Service uses other implemented OSGi-services:to access the service provider, to access the devices, to transfer files
18. Prototype – Residential Gateway (2)
19. Demonstration Demonstration of the prototype using 2 technologies:UPnP &SDUPP (self-defined: Simple Dobelmann Update Protocol)
20. Summary & Outlook OSGi suitable to handle protocol diversity & provide integration
Open issues:
Only small part of devices & protocols support remote software updates
Needed device information
Security!! (Restricted Access, Secure Transfer)
A lot is still vague: e.g. device information needed
Joint efforts needed by manufacturers, standard organisations and potential service providers, to agree on open issues
Outlook: Dynamically finding service providers (JXTA vs. UDDI),running an OSGi platform on a router
Still takes a long time until ready for the market...!?