Update OSGi Residential Expert Group

COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved

OSGi Alliance Residential Expert GroupCurrent ActivitiesDecember 6, 2012OSGi Users‘-Forum Germany Meeting, Cologne


OSGi Alliance Technical Process

• Requirements are documented in a Request for Proposal (RFP)• Application Domain

• Problem Description

• Use Cases

• Requirements

• Once the RFP is completed there will be a voting in the Requirements Committee

• If approved, the EG will work on solution that is documented in Request for Comments (RFC)

• The RFC will be the base for the actual specification • Each specification comes with a reference implementation and test

cases

10.04.23Page 2


Current Activities

• Requirements Collection for the new specification • RFP 142 – ZigBee API (completed and approved)• RFP 147 – Device Abstraction Layer• RFP 149 – USB DeviceCategory• RFP 153 – Resource Monitoring and Management• RFP 154 – Network Interface Information Service

10.04.23Page 3


RFP 142

ZigBee API

Page 4


RFP 142 – ZigBee API

• Problem Description• OSGi Applications communicating with ZigBee devices are supposed to call the API of the

driver provided by the vendor. This API is vendor proprietary and causes the following problems:

• Application developers need to know which vendor's ZigBee hardware is used with the target residential gateway in advance before developing their applications

• An application which was developed for a certain environment may not work in other environments.

• Use Cases• ZigBee Device Control by locally installed OSGi applications

• ZigBee Device Control through USB Dongle

• ZigBee Device Control through standard ZigBee Device Gateways

• ZigBee Gateway with IP networks

• Network Refreshment

10.04.23Page 5


RFP 149

USB DeviceCategory

Page 6


RFP 149 – USB DeviceCategory

• Problem Description• The Device Access Specification declares that the device category for specific devices

must be defined outside of itself. The lack of device category for USB devices causes the following problems:

• The developer of a refining driver bundle, which registers a Driver service at its activation, cannot design and implement Driver#attach(ServiceReference) method without knowledge of service properties set to the Device service registered by an USB base driver

• The developer of a refining driver bundle, which registers a Driver service at its activation, cannot design and implement Driver#match(ServiceReference) method without knowledge of service properties set to the Device service registered by an USB base driver and without the definition of match values to be returned.

• Use Case• Attaching ZigBee USB Dongle to a Home Gateway

10.04.23Page 7


RFP 153

Resource Monitoring and Management

Page 8


RFP 153 – Resource Monitoring and Management (1)

• Problem Description• OSGi defines no standardized mechanism to detect and react on failures, shortage of

resources and misbehaving services or bundles. A flexible framework is needed that allows dynamic provisioning of modules to:

• Collect Information about the normal, intended states of the monitored entities

• Monitor arbritary resources and ask services for their health status

• Evaluate the serverity of deviations of the currently monitored state from intended state

• Take Decisions and perform actions to recover the intended state

• Control/monitor the success of the actions taken

10.04.23Page 9


RFP 153 – Resource Monitoring and Management (2)

• Use Cases• A management entity wants to be notified if the overall framework consumption of a certain

resource reaches a defined level, e.g. memory or threads.

• A bundle defines its needs in terms of a special resource (e.g. availability of certain TCP/IP ports) and wants to be notified, as soon as those resources become available.

• An accounting component wants to monitor consumption of resources for a bundle (or a set of bundles) as base for billing towards the bundle vendor.

• A management entity defines maximum allowed resources for a certain bundle (or set of bundles) and wants to be notified if the limits are exceeded. It then invokes a special interface on the bundle to allow a “self-healing”. The success of this “therapy” itself is monitored and if necessary the cycle starts again.

• A premium service should have higher priority when resources are distributed than best-effort-services.

• A bundle defines its resource requirements for normal operation and wants to be notified, if those ranges are exceeded, because this indicates some potential error conditions that the bundle needs to be aware of and could handle.

• Sets of bundles that make up one application are handled together, i.e. one bundle acts on behalf of all bundles belonging to the application.

10.04.23Page 10


RFP 154

Network Interface Information Service

Page 11


Network Interface Information Service

• Problem Description• Obtaining IP network information can be done via standard Java APIs, however• There is no function which sends a notification when the information of network interface (i.e. IP

address) changed during runtime• There is no function which can obtain the subnet mask of the network interface. • Bundles need to implement Operating System specific features to obtain IP network information

• Use Case 1• The TR-069 protocol adapter bundle needs to communicate with an Auto Configuration Server (ACS). The ACS

needs to know IP address of the Residential Gateway to send UDP packet to protocol adapter bundle for connection request. In this case, the bundle has to send the IP address to ACS when the bundle is started or the IP address is changed.

• Use Case 2• When Http Service bundle is available, at least, one http server is probably run. In case that the http server needs to

be assigned to the specific network interface, Http Service bundle has to know the information of network interface. In addition, Http Service bundle needs to know changing IP address of the network interface to manage http servers.

10.04.23Page 12


OSGi Device Abstraction Layer

RFP 147

Entry Point to All Devices

Page 13


Device Abstraction Layer – Covers All Device Protocols

• API applicable for all relevant device protocols

• General device data model

• Access to common device properties

• Access to the device states

• Access to device meta info

• Device operations

• Management operations

• Data operations

10.04.23Page 14


Device Abstraction Layer – Protocol Independent 1/3

• API solving common problems with device access

• Avoiding protocol specific behavior

• Avoiding application workarounds

• Avoiding custom device abstractions

• Avoiding uncontrolled dependencies

10.04.23Page 15



Without DAL: Complex implementations, multiple dependencies

10.04.23Page 16



Introducing Device Abstraction Layer: Single point of contact, giving protocol independence

10.04.23Page 17


Device Abstraction Layer – Security

• Access control based on user and application permissions

• Fine-grained security control

• Full flexibility of OSGi security model

• Security features available in the device protocols

10.04.23Page 18


Device Abstraction Layer – Notification

• A notification mechanism is needed for:

• Device state monitoring

• Device data model monitoring

• Device operations monitoring

10.04.23Page 19


Device Abstraction Layer – Extension

• Extension points for new protocols

• Dynamic extension points

• Protocol independent

• Available at runtime

10.04.23Page 20


REG Time Plan

• Completing Requirements Collection by Dec. 2012• RFCs should be ready by Q2 2013• Initial Specifications ready by Q3 2013• Final Specifications ready by Q4 2013• Specification Release Q1 2014

10.04.23Page 21

Technology

Update OSGi Residential Expert Group