+1 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 Tue, Mar 22, 2016 at 11:20 PM, Dileesha Rajapakse <[email protected]> wrote: > 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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
