Hi Ruwan, Yes, I strongly agree with you and optimally the implementation should be done with a generic approach. If we can add OMA-DM support to the CDMF, it will be able to serve any device type that follows OMA DM standards regardless of the vendor. Also, it's good to consider the *OMA Lightweight M2M protocol* [1], a client-server specification to provide machine to machine service which can be really useful in IoT device management.
[1] - OMA LightweightM2M v1.0 <http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-lightweightm2m-v1-0> Thank you. On Tue, Mar 22, 2016 at 10:21 PM, Ruwan Yatawara <[email protected]> wrote: > Hi Dileesha, > > I believe when implementing this we should not make it Android specific. > That way we can make use of this in the IOT world as well. > > There is huge potential in this protocol being used for Monitoring/Remote > Command Pushing/Firmware Update across the entire spectrum of IOT Devices. > > Thanks and Regards, > > Ruwan Yatawara > > Senior Software Engineer, > WSO2 Inc. > > email : [email protected] > mobile : +94 77 9110413 > blog : http://ruwansrants.blogspot.com/ > www: :http://wso2.com > > > On Mon, Sep 21, 2015 at 4:22 PM, Dileesha Rajapakse <[email protected]> > wrote: > >> Yes. The Protocol is SyncML. >> >> >> http://technical.openmobilealliance.org/Technical/release_program/docs/Common/V1_2_2-20090724-A/OMA-TS-SyncML-RepPro-V1_2_2-20090724-A.pdf >> >> On Mon, Sep 21, 2015 at 4:16 PM, Dulitha Wijewantha <[email protected]> >> wrote: >> >>> >>> >>> On Monday, September 21, 2015, Dileesha Rajapakse <[email protected]> >>> wrote: >>> >>>> *Android OMA-DM Standardization* >>>> >>>> *OVERVIEW* >>>> >>>> As per the current architecture of the Android Component of the WSO2 >>>> MDM framework, Android mobile devices are managed using a custom built >>>> client application installed on the device. Server to Client communication >>>> is done over HTTP and the devices are provisioned periodically through a >>>> polling mechanism. *OMA-DM* is a standard device management protocol >>>> which has been adopted by several device manufacturers. This thread is a >>>> study on standardization of the current Android MDM implementation using to >>>> use OMA-DM Standards and Protocols. >>>> >>>> *GOALS* >>>> >>>> - Standardize current Android implementation using OMA-DM >>>> Specification. >>>> >>>> *What is OMA-DM?* >>>> >>>> - *Open Mobile Alliance* (OMA) is a non-profit organization. >>>> - Delivers Open Specifications for creating interoperable services. >>>> - The *Device Management (DM) Working Group (WG)* specifies >>>> protocols and mechanisms to achieve the management of mobile devices, >>>> services access and software on connected devices. >>>> - Current stable version is *v1.3* [1]. >>>> >>>> *Why OMA-DM?* >>>> >>>> - Managing devices with OMA DM version 1.2 allows two-way async >>>> communication between the server and client. >>>> - Ease of managing devices through *Management Objects*. >>>> - Can easily manage converged and multi-mode devices on any >>>> network, including devices that do not have a SIM card, as well as >>>> resource >>>> constrained devices. This extensibility is one of the key benefits of >>>> OMA >>>> DM, making it ideal for M2M communication scenarios. >>>> >>>> >>>> Another advantage managing Android through OMA-DM as I see is - if >>> someone wants to write a custom android client for our server. They can >>> easily do it by building it against OMA-DM spec. A potential scenarios are >>> TVs, Cars and a Android laptops. >>> >>>> *OMA-DM Device Management Technology* >>>> >>>> - The OMA DM specifications [2] define the protocols and the >>>> mechanisms allowing an OMA DM Server to deliver configuration >>>> parameters to >>>> an OMA DM Client. >>>> >>>> Is this done using XML payloads? >>> >>>> >>>> - This is done using a defined set of *“DM Commands”* for various >>>> management scenarios. >>>> - These are executed inside a well-defined and secure environment >>>> (the *“DM Session”*). >>>> >>>> >>>> - The *OMA DM Client* exposes the device internal data to the *OMA >>>> DM Server* in the form of a hierarchic tree known as the *“DM Tree”* >>>> . >>>> - A *Management Tree* is a mechanism by which the management >>>> client interacts with the device, e.g. by storing and retrieving values >>>> from it and by manipulating the properties of it, for example the access >>>> control lists. >>>> - It is made up of different building blocks (or sub-trees) called >>>> *Management >>>> Objects*. >>>> - A *Management Object* is is a subtree of the Management Tree >>>> which is intended to be a (possibly singleton) collection of *Nodes* >>>> which are related in some way. >>>> - Management Objects provide specific functionality in the >>>> management of devices. >>>> - The management of a device feature consists of the management of >>>> the DM Tree, which virtualizes the device features and functionalities. >>>> >>>> >>>> - The OMA DM Working Groups specified a number of Management >>>> Objects implementing specific management functions. >>>> >>>> >>>> - There are several Management Objects which have been specified to >>>> support additional functionalities [3]: >>>> - *Software Management *(OMA DM SCOMO) allowing not only the >>>> installation and the removal of applications on the mobile, but also >>>> the >>>> retrieval of the inventory of software components already installed >>>> on the >>>> device >>>> - *Diagnostics and Monitoring *(OMA DM DiagMon MO), which >>>> enables remote diagnostic, for example to query the device for >>>> memory and >>>> battery status or to collect radio measures and QoS parameters, and >>>> remote >>>> monitoring, by defining trap and reports >>>> - *Connectivity* (OMA DM ConnMO), which allows the configuration >>>> of bearers and proxies >>>> - *Device Capabilities *(OMA DM DCMO), which allows a Management >>>> Authority to remotely enable and disable device peripherals like >>>> cameras, >>>> Bluetooth, USB, etc >>>> - *Lock and Wipe *(OMA DM LAWMO), which allows to remotely lock >>>> and/or wipe the device, for instance when the device is stolen or >>>> sold, or >>>> when personal or enterprise data are compromised >>>> - *Browser* (OMA DM BMO), which allows remote management of >>>> browser favorites and settings >>>> - *Virtualization* (OMA DM VirMO), which enables remote >>>> management of virtual machines running on the device (expected for >>>> 3Q 2013) >>>> - *Management Policy *(OMA DM Management Policy MO), which >>>> allows the deployment on the device of policies which the DM Client >>>> can >>>> execute and enforce independently: if some events happen, then >>>> perform some >>>> operations (expected for 2Q 2014) >>>> >>>> OMA DM WG also specified *Gateway* functionality (OMA DM GwMO v1.0), >>>> which allows an OMA DM Server to manage devices that: >>>> >>>> - are not directly accessible, for example, because they are >>>> deployed behind a firewall >>>> - can be clustered in a group, for instance when they are deployed >>>> in a very large number (like sensors), using fan out mechanisms >>>> - support other Management protocols than OMA DM >>>> >>>> I will keep updating this mail thread as I move forward. >>>> >>>> [1] - >>>> http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/dm-v1-3 >>>> >>>> [2] - >>>> http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases >>>> >>>> [3] - >>>> http://openmobilealliance.org/about-oma/work-program/device-management/ >>>> -- >>>> Dileesha Rajapakse >>>> *Intern - Engineering* >>>> Mobile : +94 (0) 772 555 933 >>>> Tel : +94 112 741 505 >>>> [email protected] >>>> >>> >>> >>> -- >>> Dulitha Wijewantha (Chan) >>> Software Engineer - Mobile Development >>> WSO2 Inc >>> Lean.Enterprise.Middleware >>> * ~Email [email protected] <[email protected]>* >>> * ~Mobile +94712112165 <%2B94712112165>* >>> * ~Website dulitha.me <http://dulitha.me>* >>> * ~Twitter @dulitharw <https://twitter.com/dulitharw>* >>> *~Github @dulichan <https://github.com/dulichan>* >>> *~SO @chan <http://stackoverflow.com/users/813471/chan>* >>> >>> >> >> >> -- >> Dileesha Rajapakse >> *Intern - Engineering* >> Mobile : +94 (0) 772 555 933 >> Tel : +94 112 741 505 >> [email protected] >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dileesha Rajapakse *Intern - Engineering* Mobile : +94 (0) 772 555 933 Tel : +94 112 741 505 [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
