Update OSGi Residential Expert Group

OSGi Alliance Residential Expert Group
Current Activities
December 6, 2012
OSGi Users‘-Forum Germany Meeting, Cologne

COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved

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

Page 2 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved 09.12.12

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


RFP 142

ZigBee API

Page 4 COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved

RFP 142 – ZigBee API

• 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


RFP 149

USB DeviceCategory


RFP 149 – USB DeviceCategory

• 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


RFP 153

Resource Monitoring and Management


RFP 153 – Resource Monitoring and Management (1)

• 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


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.


RFP 154

Network Interface Information Service


Network Interface Information Service

• 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.


OSGi Device Abstraction Layer

RFP 147

Entry Point to All Devices


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


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



Without DAL:
Complex implementations, multiple dependencies



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


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


Device Abstraction Layer – Notification

• A notification mechanism is needed for:
• Device state monitoring
• Device data model monitoring
• Device operations monitoring


Device Abstraction Layer – Extension

• Extension points for new protocols
• Dynamic extension points
• Protocol independent
• Available at runtime


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


Update OSGi Residential Expert Group

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (14)

Similar to Update OSGi Residential Expert Group

Similar to Update OSGi Residential Expert Group (20)

Recently uploaded

Recently uploaded (20)

Update OSGi Residential Expert Group