1. Possible Solution of Interworking between oneM2M and OSGi
Group Name:
Source: <name>, <company>, < >
Meeting Date:
Agenda Item:

2. Summary of Discussion on OSGi in oneM2M TP#23
Huawei introduced the idea of the interworking between oneM2M and OSGi, 7 technical areas for cooperation are identified through discussion, as follows:
Service Layer API (oneM2M WI-0020)
WI-0043 and TR-0022 Continuation of HGI Activities
Deliver AE as a OSGi bundle on to nodes.
Deliver implementation of resource to CSE
Action Triggering(WI-0035)
Hot Deployment of oneM2M components (CSEs)
Interworking between oneM2M and OSGi as side-by-side platforms
Items 1,3,4,5 and 6 were proposed by NTT (Hiroyuki Maeomichi).
Item 2 was proposed by Orange (Patricia Martigne).
Item 7 was proposed by Huawei.

3. Possible Interworking Solutions
1 Service Layer API
Provide a oneM2M resource accessing interface among oneM2M entity bundles within a OSGi framework.
Apply to develop a oneM2M device based on OSGi framework. AE
Bundle
Mca
CSE
Bundle
Mca AE
Bundle
Distributed OSGi Framework
Common Protocol Binding Service 2
Provide a protocol binding service interface for oneM2M entity bundles to register resources which can accessed by external oneM2M entities over a communication protocol with resource URI.
Apply to oneM2M device developed based on OSGi framework to communicate with external oneM2M device.
Protocol Binding Service
Bundle
Mca/Mcc
Over
communication protocol
AE/CSE AE
Bundle
Mca
CSE
Bundle
Distributed OSGi Framework

4. Possible Interworking Solutions
3 Interworking Proxy Entity Service
oneM2M
IPE
Service
Bundle
Mca/Mcc
Over
communication protocol
AE/CSE
Provide a oneM2M Interworking Proxy Entity service interface to register OSGi standard service which can accessed by external oneM2M AE/CSE over a communication protocol with resource URI.
Apply to OSGi device developed based on OSGi standard service interface to communicate with external oneM2M device.
OSGi Standard Service
Bundle
OSGi Framework
Device Abstract Model Mapping 4
TV1
Mapping
Provide a mapping guide or method between oneM2M home domain information model and OSGi device service interface.
Apply to build oneM2M device based on OSGi framework.
TV 1
Function interface 1
Function interface n …
Firmware
version
Software Version
volume
Power … …
Firmware
version
Software Version
volume …
Power
Property
Module
Property
Functions
OSGi Device Abstract Layer
oneM2M Home Domain Information Model

5. Service Layer API – Define Mcc & Mca between OSGi bundles
Service Registry
Register Service A
(Create Resource A)
Get Service A
(Access Resource A)
oneM2M Device Implemented with OSGi Framework:
Bundles are oneM2M entities;
Services are oneM2M resources;
Mca & Mcc reference points are abstracted as service operations;
Bundle X
(AE1)
Bundle Y
(AE2)
OSGi Framework
Table : Mapping Rules between oneM2M Resource and OSGi Service
Define oneM2M Resource as OSGi Standard Service Interface:
Registering oneM2M resource as OSGi services can share oneM2M resources among OSGi bundles.
Standardizing oneM2M resource interface can avoid the inconsistent definitions between the owner and users of resources, decouple them.
Each oneM2M resource can consist of oneM2M base common attributes and resource specific attributes.
oneM2M
OSGi
Create resource
Register service
Retrieve resource
Get service
Update resource
Call Service Object method
Delete resource
Unregister service
Notification
Event Listerner

6. Protocol Adapter Layer
Common Protocol Binding Service Interface – General method for exposing internal oneM2M resource to external
Defining oneM2M resource as OSGi service implement the Mca & Mcc reference point among OSGi bundles
Protocol Binding provides Mca & Mcc reference point over a communication protocol, like MQTT, Http
Table : Common Protocol Binding Service Structure
oneM2M Resource Service
Layer Name
Functions
Interface
Provides Following Standard Interface :
registerResource: register oneM2M resource service object with a resource URI
unRegisterResource: unregister a resource URI
Service Layer
Restore mapping relationship between URI and oneM2M resource service object
Convert the resource operation (CRUDN) into service object accessing and operation
Subscribe resource service object event with Event Admin Service interface, forward event to external subscriber
Protocol Adapter Layer
Based on definition of oneM2M protocol binding:
Parse message into primitive structure
Construct message from primitive structure
Implement communication protocol Interface
Interface
Service Interface
Service Layer
External Subscribe Proxy
URI – Resource
Mapping
Resource
Service
Accessing
Protocol Adapter Layer
Primitive Parsing
Protocol Communication Implementation
Communication
Protocol
OSGi is to define Common Protocol Binding Service Interface and its Functions, not to implement service functions.
Different protocols are only different in Protocol Adapter Layer.
External oneM2M Device
Refer to Http Service specification in OSGi residential specification -

7. Protocol Adapter Layer
Interworking Proxy Entity Service Interface – Non-oneM2M Devices Interoperate with oneM2M Devices
Define a Interworking Proxy Service, to register OSGi standard service object with a resource URI to expose it to external oneM2M device
Table : IPE Service Structure
OSGi Standard Service
Layer Name
Functions
Interface
Provides Following Standard Interface :
registerResource: register OSGi standard service object (like Device Service) with a resource URI
unRegisterResource: unregister a resource URI
Service Layer
Restore mapping relationship between URI and OSGi standard service object
Convert the oneM2M resource operation (CRUDN) into OSGi Standard Service object accessing and operation
Need implementing the mapping between oneM2M resource and OSGi standard services
Subscribe resource service object event with Event Admin Service interface, forward event to external subscriber
Protocol Adapter Layer
Based on definition of oneM2M protocol binding:
Parse message into primitive structure
Construct message from primitive structure
Implement communication protocol Interface
Interface
Service Interface
Service Layer
OSGi
Standard
Service
Accessing
External Subscribe Proxy
URI – Resource
Mapping
Protocol Adapter Layer
Primitive Parsing
Protocol Communication Implementation
Communication
Protocol
The architecture is similar to Common Protocol Binding Service.
Protocol Adapter is implemented based on oneM2M protocol binding standard, same as Common Protocol Binding Service.
External oneM2M Device
Refer to Http Service specification in OSGi residential specification -

8. OSGi Device Abstraction Functions
Abstract Device Model Mapping – Use OSGi Device Service Interface Implement oneM2M Home Appliances Information Model
OSGi Device Structure example
oneM2M Device Structure example
TV1
Function interface 1
TV 1
Abstract device structure designs are basically the same.
Function interface n …
Firmware
version
Software Version
volume
Power
Firmware
version
Software Version
volume …
Power … …
Property
Functions
Property
Module
Consist of Device and Device Function Service interface, associated with the same device id.
Represent as resource structure, device properties and module class are all sub-resource of device.
oneM2M Module Class
OSGi Device Abstraction Functions
Name
Date Type
Data Type
buttonSwitch
boolean
BooleanControl
keypad
integer
MultiLevelControl
lock
string
Custom Function
String …
oneM2M Module Class focus on the business
OSGi Device Abstraction Functions Layer focus on the software implementation
oneM2M home domain information model can be implemented with OSGi device interface
Refer to Device Abstract Layer specification in OSGi residential specification -

9. Thanks for your listening! Q & A

10. oneM2M – Resource Oriented Network
oneM2M Resource Overview:
All entities in the oneM2M System, such as AEs, CSEs, data, etc. are represented as resources, transferred and manipulated using CRUD operations, stored in the CSE with which it is registered.
A resource structure is specified as a representation of such resources, it can contain child resource(s) and attribute(s). Resource and child resource are linked with the attribute parentID of child resource.
Each resource is uniquely addressable.
Infrastructure Node (IN)
Mca
Resource Addressing:
An address of a resource is a string of characters used to uniquely identify the targeted resource within the scope of a request to access the resources.
The goal of M2M addressing is to reach the CSE with which the target resource is registered.
As shown in the figure, IN-AE wants to access ASN-AE, the URI should be IN-CSE/MN-CSE/ASE-CSE/ASE-AE.
IN -AE
IN -AE
Mca
IN - CSE
Mcc
Application Service Node
(ASN)
Middle Node (MN)
ASN -AE
MN -AE
Mca
Mcc
Mca
ASN - CSE
MN - CSE
Refer to Resource Management specification in oneM2M TS

11. OSGi – Service Oriented Framework
OSGi Framework Overview:
OSGi provides a distributed, modular, service-oriented Java framework.
The Framework defines a unit of modularization, called a bundle.
A bundle is comprised of Java classes and other resources, which together can provide functions to end users.
Bundles collaborate with each others though service model.
Service registry accepts any object as a service. Registering Java objects under standard interfaces can decouple the implementer from the client code. OSGi specification defines a large number of standard services, such us device service, event admin service.
Service Layer Overview:
A bundle publishes a service by registering a service object with the Framework service registry.
The service properties are intended to provide information about the service. Properties hold information as key/value pairs.
A bundle can use a service object and call its methods by obtaining the service object.
A service listener will be called with the service event when a service object has been registered or modified or is in process of unregistering.
Refer to Service Layer specification in OSGi core specification -

12. OSGi – Service Operation Code Example
public interface HelloService {
public String sayHello();
Define a interface
public class HelloServiceImpl implements HelloService{
public String sayHello() {
return "Say Hello";
Define a class implements the interface
public class HelloServiceTracker extends ServiceTracker {
public HelloServiceTracker(BundleContext context) {
super(context, HelloService.class.getName(),null); }
public Object addingService(ServiceReference reference) { ……
return super.addingService(reference);
public void removedService(ServiceReference reference, Object service) {
super.removedService(reference, service);
Define a service tracker class, declare it is used for tracking class HelloService in its construct function
public class HelloServiceActivator implements BundleActivator {
public void start(BundleContext context) {
HelloService helloService = new HelloServiceImpl();
helloServiceRegistration = context.registerService(HelloService.class
.getName(), helloService, null);
Create a HelloService object, and register this object as a service
public class Activator implements BundleActivator {
public void start(BundleContext context) {
helloServiceTracker= new HelloServiceTracker(context);
helloServiceTracker.open();
HelloService helloService=(HelloService)helloServiceTracker.getService();
System.out.println(helloService.sayHello());
Create a HelloServiceTracker object, obtain the helloService object by calling getService method
Code example refer to:

13. Define oneM2M Resource as OSGi Service interface
OSGi Service Definition
oneM2M Resource Universal Attributes
public interface oneM2MResource {
public int getResourceType();
public String getrResourceID();
public void setResourceName(String resourceName);
public String getParentID();
public Date getCreateionTime();
public Date getLastModifiedTime();
public String[] getLabels(); }
Define oneM2M Resource as OSGi Standard Service Interface:
Registering oneM2M resource as OSGi services can share oneM2M resources among OSGi bundles.
Standardizing oneM2M resource interface can avoid the inconsistent definitions between the owner and users of resources, decouple them.

14. Resource Interface = Common Resource Interface + Specific Resource Type Interface
public interface oneM2MResource
public interface oneM2MCseBase {
public int getCseType();
public String getCseID();
public int[] getSupportedResourceType();
public String[] getPointOfAccess();
public String getNodeLink();
public String getNotificationCongestionPolicy();
… … }
Every oneM2M resource can consist of oneM2M base common attributes and resource specific attributes.

15. Example of Using OSGi Service to Represent oneM2M Resource
Service Registry
Register Service A
(Create Resource)
Get Service A
(Access Resource)
Example of Resource Accessing within OSGi framework:
Bundle X register Service A object which is implemented the oneM2MResource interface as Resource A.
Bundle Y obtain Service A object from OSGi Service Registry by specifying the oneM2MResource interface and service properties.
Bundle Y operate resource A by calling the method of Service A object.
Bundle X
Bundle Y
OSGi Framework
Operation (CRUDN) Mapping between oneM2M Resource and OSGi Service:
Create resource – Register service
Retrieve resource – Get service
Update resource – Call service property set method
Delete resource – Unregister service
Notification – Service Event Listener
public class oneM2MCSEBase implements implements oneM2MCseBase, oneM2MResource{
reg = context.registerService(interfaceNameArray, oneM2MCSEBaseA, null);
oneM2MCSEBaseReference=context.getServiceReference(oneM2MCSEBase.class.getName());
oneM2MCSEBaseA=(oneM2MCSEBase)context.getService(oneM2MCSEBaseReference);
oneM2MCSEBaseA.setResourceName(newResourceName);
reg.unregister();
public class oneM2MCSEBaseTracker extends ServiceTracker {
public oneM2MCSEBaseTracker(BundleContext context) {
super(context, oneM2MCSEBase.class.getName(),null);

16. Service Layer API vs. Protocol Binding
Physically separate located
Physically co-located
Interaction Model :
Communication Protocol Binding
Interaction Model :
Service Layer API AE AE
REST, MQTT, CoAP
API call
CSE
CSE
Difference between Service Layer API and Protocol Binding:
Communication between physically separate devices needs to be carried through communication protocols, like HTTP, MQTT and CoAP.
Interoperation between physically co-located programs can directly call the program interface of each other, to be more efficient and protocol independent.
As a distributed framework, even bundles of one OSGi device deployed on different physical devices can interoperate through service registry. Standard oneM2M Resource Interface in OSGi is so called Service Layer API within OSGi framework.
Protocol Binding can be a solution for OSGi system to communicate with other devices (build with other framework or not within one OSGi framework).
Refer to oneM2M TS 004 Service Layer Core Protocol specification - Service_Layer_Core_Protocol-V1_0_1.ZIP

17. Introduction to oneM2M Http Protocol Binding
HTTP Protocol Binding Design Principle:
To assume AE has the capability of HTTP Client, and CSE has the capability of both HTTP Client and Server.
Single request primitive is mapped to single HTTP request message, and single response primitive is mapped to single HTTP response message.
The HTTP 'Method' is mapped to the oneM2M Operation parameter of the request primitive.
The Scope of HTTP Protocol Binding:
Binding oneM2M Protocol primitive types to HTTP method.
Binding oneM2M response status codes (successful/unsuccessful) to HTTP response codes.
Binding oneM2M RESTful resources to HTTP resources.
Protocol Binding provide a method to transfer resource accessing/operation message over a specific communication protocol.
Refer to oneM2M TS 009 Http Protocol Binding specification -

18. Example of Http Protocol Binding Procedure
Message Procedure over Http Protocol:
ASE-AE post a Http request to URL /ASN-CSEID, parameter X-M2M-NM = cont1 is carried in message body.
ASN-CSE receive the Http request, process the request – create a resource locally.
ASN-CSE response an answer message with a return code 201 which means resource created.
Refer to oneM2M TS 009 Http Protocol Binding specification -

19. Introduction to OSGi Http Service Specification
OSGi Http Service Specification Overview:
HttpService is not to define how to use Java to implement the Http protocol, but assume that it is listening to a port on one machine.
HttpService interface provides registerServlet method for bundle developers to register a Servlet object to this service with a URI.
When HttpService receives a request, it analyses the URL, and call the method of the servlet object which registered with this URI.
All Servlet objects and resource registrations share the same name- space.
Implementations of this service can support other protocols if these protocols can conform to the semantics of the javax.servlet API.
Servlet myServlet = new HttpServlet() {
public void init( ServletConfig config ) {
… … }
public void doGet(
HttpServletRequest req,
HttpServletResponse rsp ) };
getHttpService().registerServlet(
"/servletAlias",
myServlet,
initparams,
null // use default context );
// myServlet has been registered
// and its init method has been called. Remote
// requests are now handled and forwarded to
// the servlet.
...
getHttpService().unregister("/servletAlias");
// myServlet has been unregistered and its
// destroy method has been called
Example of Http Service:
Create a Servlet object myServlet.
Register object myServlet to HttpService with URI ‘/servletAlias’.
Send a Get message to URL HttpServiceBindingAddress/servletAlias, then the method doGet of object myServlet is called.
HttpService provide users with access to services on the Internet by registering the servlet object to it.
Refer to Http Service specification in OSGi residential specification -