SNMP, as the first standardized attempt of designing a device management protocol, allowed telcos to manage their core devices remotely without sending technicians to the premises. The second wave of device management protocols came with TR-069, where the focus was put on a massive scale. Now, with growing importance ofIoTprojects, new access technologies for CPEs and more and more manufacturers emerging in the market we can see an evolution towards the third wave which seems to be a new approach to device management in the telco industry: certification & interoperability.
Before, a standard approach for telcos regarding device management could be described asliving la vida loca. They purchased devices that were suited for particular needs or launched projects that would work here and now—without thinking in the global scale. Then, after a couple of years they realised that they own 15+ different models of devices from different manufacturers, each managed in a bit different way. When the situation became unbearable they were pushed to get one umbrella solution for device management to take control of theseaugean stables.Implementation projects were difficult and long, discussions with manufacturers to solve problems with interoperability had to be reinitiated, and part of vendors were already out of business or device models were already obsolete and without support.
Nowadays, we can safely say that telcos learned their lesson. Starting new projects, they begin with standard and interoperability program, then they choosedevice management platform, and only then do they start procurement discussions with potentially interested device vendors.
The strategic process can be described in three steps. First telco operators choose the standard technology that would overlook the projects in the whole organization. Whether it will beLwM2Mfor IoT projects orTR-069for home gateways is a side issue—the important thing is that the standard is open, recognized worldwide and with good security and extension models.
Then the company has to decide what it wants to achieve through the project, what parameters are obligatory, how security/authorization should be done, or if non-standard extensions are required. Often it is the telco that purchases a client SDK, customized for the scope of the project with porting services done by client’s vendor.
As the third step telcos are setting up the interoperability program. They set up a set of interop tests in a device management platform that check conformity to the protocol itself and the project requirements (which includes: services, performance, stability, security, connectivity, and more). Device manufacturers that would like to sell equipment to the telco have to pass these tests—telcos make purchasing decisions based on conformity reports automatically generated for each device. It is not a rare practice for telcos to resort to forcing manufacturers to use a predefined independent client SDK, to assure that implementation of the standard is correct.
After this process, launching a new project is pretty straightforward. All the devices can be sent to customers on Day 1, time to market is reduced a lot, and costs of further maintenance are minimal thanks to interoperability done beforehand.
As surprising as it may sound, interoperability is becoming the number one factor for decision makers and stakeholders in telecommunications companies.
For telcos, the freedom of choosing a deployment scenario is really important. Nowadays, times of installing software on bare metal are mostly gone. The majority of telcos have their system kept in virtualized environment. With growing importance of agile deployments using containers (such as Docker) the early adopters in telcos are already asking for installations using Container Orchestration methods (such asKubernetes). It is a fact that telcos are mostly conservative when it comes to letting data out of their own data center (sometimes there are even law regulations concerning such ‘data leakage’), but it is also true that telcos start looking more friendly on private cloud-based installations) that help to reduce growing maintenance costs of hardware and data center. Some of the operators even decide to go for a full SaaS mode for smaller projects to benefit from pay-as-you-grow strategy with zero initial costs of infrastructure.
A device management platform has to be also easily scalable in case the number of devices grows to millions. Proven scalability with different LoadBalancers, strong High Availability structure, and possibility to easily extend installation for more VMs/PODs definitely form a key criterion for a deployment architect when deciding on the architecture of a project.
No device management platform is an isolated island in the telco landscape. The platform is always integrated with various existing platforms (like CRM, BSS, OSS, Customer Portal). Integration is usually a 2-way communication to both send data from devices to 3rd party systems and also enrich device data with other data (such as info about data plans and customers used in call center departments). An exposed full REST API with documentation compliant with swagger/OAS3 standards, reflecting all the methods available in the GUI, is a must for any device management platform. This is the most important criterion for a development team in a telco company.
It is a cliché to say that a device management platform has to be both easy to use and powerful at the same time. While it is rather impossible to take a swim and not get wet, it is also hard not to understand a telco’s need to have an easy-to-use yet at the same time powerful and flexible system for device management. A device management platform is not the only system operators in telco will use. Usually they have numerous systems open when they have to perform an action. Even though system implementation does not come without trainings and manuals, we cannot expect employees to remember everything in such broad a landscape of systems. Platforms, at least for call center departments, have to be easy to understand and user-friendly for operators to quickly respond to Customer’s needs.
On the other hand, system administrators need to manage deployments on a massive scale and need the system to reflect all the business logic within flexible workflows that cover all the scenarios that might occur. Unfortunately very often a solution has different, separate or customized views for various user types.
That being said, easy-to-adopt and easy-to-achieve goals are the most important criteria for end users and system admins.
The world of device management is constantly changing and evolving. With different devices, different scenarios and different roles that telcos nowadays have, a platform has to also adapt to different criteria of various departments that altogether conclude the final decision on what to choose in terms of device management.