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

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.

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

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

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

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 - https://osgi.org/download/r6/osgi.residential-6.0.0.pdf

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 - https://osgi.org/download/r6/osgi.residential-6.0.0.pdf

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 - https://osgi.org/download/r6/osgi.residential-6.0.0.pdf

Thanks for your listening! Q & A

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 001 - http://www.etsi.org/deliver/etsi_ts/118100_118199/118101/01.01.00_60/ts_118101v010100p.pdf

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 - https://osgi.org/download/r6/osgi.core-6.0.0.pdf

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: http://www.tuicool.com/articles/B7RZRf

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.

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.

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);

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 - http://onem2m.org/images/files/deliverables/TS-0004- Service_Layer_Core_Protocol-V1_0_1.ZIP

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 - http://www.etsi.org/deliver/etsi_ts/118100_118199/118109/01.01.00_60/ts_118109v010100p.pdf

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 - http://www.etsi.org/deliver/etsi_ts/118100_118199/118109/01.01.00_60/ts_118109v010100p.pdf

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 - https://osgi.org/download/r6/osgi.residential-6.0.0.pdf