Telco 2.0™ Research

The Future Of Telecoms And How To Get There

Aligning M2M with Telco 2.0 Strategies

Previous | Next

Summary: A review of Telenor, Jasper Wireless and KPN’s approaches to M2M, examining how M2M strategy needs to fit with an operators’ future broadband business model strategy. (October 2010, Foundation 2.0)

M2M is a major topic of research and activity for Telco 2.0, and we've recently published Enterprise 2.0 - Machine-to-Machine Opening for Business, a report of the M2M session at the last Telco 2.0 Executive Brainstorm, and M2M / Embedded Market Overview, Healthcare Focus, and Strategic Options, our Executive Briefing on the M2M market and the healthcare industry vertical. M2M strategies will also be a major topic at our AMERICAS, EMEA and APAC Executive Brainstorms and Best Practice Live! virtual events. Email or call +44 (0) 207 247 5003 to find out more.

M2M: escaping the cottage industry

The M2M (Machine-to-Machine) market, also known as "Embedded Mobile", has frequently been touted as a major source of future growth for the industry. Verizon Wireless, for example, has set a target of 400% mobile penetration, implying three embedded devices for each individual subscriber. However, it is widely considered that this market is cursed by potential - success always seems to be five years away. At this Spring's Telco 2.0 Executive Brainstorm, delegates described it as being "sub-scale" and a "cottage industry".

Specific technical, operational, and economic issues have driven this initial fragmentation. M2M is characterised by diversity- this is inevitable, as there are thousands of business processes in each of tens of thousands of sub-sectors across the industrial economy. As well as the highly tailored nature of the applications, there is considerable diversity in hardware and software products, and new products will have to coexist with many legacy systems. These many diverse but necessary combinations have provided fertile ground for the separate ‘cottage industries'.

As a result, it is conversely difficult to build scale, despite the large total market size. Also, the high degree of specialisation in each sub-market acts as a barrier to entry. Volume is critical, as typical ARPUs for embedded devices are only a fraction of those we have come to expect from human subscribers. This also implies that efficiency and project execution are extremely important - there is little margin for error.  Finally, with so much specialisation at both the application and device ends of the equation, it is hard to see if and where there is much room for generic functionality in the middle. 

Special Technical and Operational Challenges

The technical problems are challenging. M2M applications are frequently safety-critical, operations-critical, or both. This sets a high bar in terms of availability and reliability. They often have to operate in difficult environments. Information security issues will be problematic and new technologies such as the "Internet of things"/Ubiquitous Computing will make new demands in terms of disclosure that contradict efforts to secure the system. An increasingly common requirement is for embedded devices to communicate directly and to self-organise - in the past, M2M systems have typically used a client-server architecture and guaranteed security by isolating their communications networks from the wider world. The security requirements of a peer-to-peer, internetworked M2M system are qualitatively different to those of traditional Supervisory, Control, and Data Acquisition (SCADA) systems.

One of the reasons for customer interest in self-organising systems is that M2M projects often involve large numbers of endpoints, which may be difficult to access once deployed, and the costs of managing the system can be very high. How are the devices deployed, activated, maintained, and withdrawn? How does the system authenticate them? Can a new device appearing on the scene be automatically detected, authenticated, and connected? A related problem is that devices are commonly integrated in industrial assets that have much longer design lives than typical cellular electronics; computers are typically depreciated over 3 years, but machine tools, vehicles, and other plant may have a design life of 30 years or more.

This implies that the M2M element must be repeatedly upgraded during its lifetime, and if possible, this should happen without a truckroll. (The asset, after all, may be an offshore wind turbine, in which case no-one will be able to visit it without using a helicopter.) This also requires that upgrades can be rolled-back in the event they go wrong.

The Permanent Legacy Environment

We've already noted that there are a great variety of possible device classes and vendors, and that new deployments will have to co-exist with legacy systems. In fact, given the disparity between their upgrade cycles and the design lives of the assets they monitor, it's more accurate to say that these devices will exist in a permanent legacy environment.

Solution: The Importance of System Assurance

Given the complex needs of M2M applications, just providing GPRS connectivity and modules will not be enough. Neither is there any reason to think operators will be better than anyone else at developing industrial process control or management-information systems. However, look again at the issues we've just discussed - they cluster around what might be termed "system assurance". Whatever the application or the vendor, customers will need to be able to activate, deactivate, identify, authenticate, read-out, locate, command, update, and rollback their fleet of embedded devices. It is almost certainly best that device designers decide what interfaces their product will have as extensions to a standard management protocol. This also implies that the common standard will need to include a function to read out what extensions are available on a given device. The

similarities with the well-known SNMP (Simple Network Management Protocol) and with USSD are extensive.

These are the problems we need to solve. Are there technology strategies and business models that operators can use to profit by solving them?

We have encountered a number of examples of how operators and others have answered this question.

Subscribers can click here to read more. Email or call +44 (0) 207 247 5003 to find out more on how to join.