In this blog, I have tried my
best to impart an overview of different Device Management solutions, its
features and Protocols used.
Managing a device means
monitoring and controlling the device. If you look @ the telecom network, there
are multiple devices to be managed. In the Radio Access side, Base station,
Gateway controllers, Routers, Switches etc.. and in Core Network side, you will have a
AAA/HLR, DNS, DHCP Servers, SIP server etc.. (Again that depends on the
technology type). Generally operators will use OSS/NMS/EMS applications to
manage these. Now leaving apart these fixed devices, what about small but important devices such as CPE, Smart
phones, tablets etc. Though these also fall under the devices umbrella it is
important to categorize the devices here. Let’s be specific these falls under
mobile device category, so let’s focus on Mobile Device Management (MDM) and
not bother about fixed devices which will be managed by NMS.
As per Wikipedia,
MDM functionality typically includes over-the-air distribution of applications, data and configuration settings for all types of mobile devices, including mobile phones, smart phones, tablet computers, ruggedized mobile computers, mobile printers, mobile POS devices, etc. This applies to both company-owned and employee-owned (BYOD) devices across the enterprise or mobile devices owned by consumers.
MDM functionality typically includes over-the-air distribution of applications, data and configuration settings for all types of mobile devices, including mobile phones, smart phones, tablet computers, ruggedized mobile computers, mobile printers, mobile POS devices, etc. This applies to both company-owned and employee-owned (BYOD) devices across the enterprise or mobile devices owned by consumers.
When you look @ the typical
architecture of MDM solution, it will be something like this
How it works?
Generally there will be a Device Management server (DMS) whose job is to manage the Mobile device. There will be a client/Agent running in the mobile device. DMS will communicate over the air to the mobile devices using any one of the common protocol mentioned below.
Generally there will be a Device Management server (DMS) whose job is to manage the Mobile device. There will be a client/Agent running in the mobile device. DMS will communicate over the air to the mobile devices using any one of the common protocol mentioned below.
- The Open Mobile Alliance (OMA) specified a platform-independent device management protocol called OMA Device Management. The specification meets the common definitions of an open standard, meaning the specification is freely available and implementable. It is supported by several mobile devices, such as PDAs and mobile phones.
- Smart message is text SMS- provisioning protocol (ringtones, calendar entries but service settings also supported like: ftp, telnet, SMSC number, email settings, etc...)
- OMA Client Provisioning is a binary SMS- service settings provisioning protocol.
- Nokia-Ericsson OTA is binary SMS-based service settings provisioning protocol, designed mainly for older Nokia and Ericsson mobile phones.
Common
solution: OMA DM
What it does?
DMS’s main activities are mentioned as follows:
DMS’s main activities are mentioned as follows:
- It shall ensure that end-users benefit from plug and play data services for whatever device they are using.
- Automatic discovery of devices and adding it in the DMS Topology management (of course, there will be no physical/logical links with other devices)
- Management services such as Software Management (Updating Antivirus), Inventory management (Equipment related details), Security management (Authentication and Authorization). This is applicable including BYOD (Bring your own device)
- Other features which would benefit the end user using their mobile devices.
To
conclude, it is not a “single size fits all “solution, it really depends
on the mobile user’s requirements, your DMS should be developed.
Ok, now let’s stroke something on CPE
WAN management also.
If OMA DM is the recommended standard
for Mobile device management, then why can’t we use TR-069?
TR-069 (Technical Report 069) is a Broadband Forum (formerly known as DSL Forum) technical specification entitled CPE WAN Management Protocol (CWMP). It defines an application layer protocol for remote management of end-user
devices. As a bidirectional SOAP/HTTP-based protocol, it provides the communication
between customer-premises equipment (CPE) and
Auto Configuration Servers (ACS). It includes both a safe auto configuration
and the control of other CPE management functions within an integrated
framework. The protocol addressed the growing number of different Internet access devices such as modems, routers, gateways, set-top boxes, and VoIP-phones for the end-users. The TR-069 standard was
developed for automatic configuration of these devices with Auto Configuration
Servers (ACS).
In my understanding, TR-069 will suit perfectly for a CPE WAN
management, it has the following architecture.
It has also the following features:
- Service activation and reconfiguration
- Remote Subscriber Support
- Firmware and Configuration Management
- Diagnostics and monitoring
Ok then, why can’t I use SNMP for managing a CPE?
Of course, yes there seems to be no drawback for using SNMP.
When you compare SNMP with TR-069. TR-069 seems to have many
advantages for CPE WAN Management than SNMP such as
- TR-069 standard is easy to understand and implement than SNMP, you need to use OIDs in SNMP where as you have user friendly attribute names in TR-069.
- Using ACS server, you can manage multi vendor CPE devices using TR-069, whereas for SNMP you need different vendor MIBs implementation which will be a tedious stuff.
