Expanding the Mobile Service Provider’s Role in M2M


  • Mobile service providers have the technology assets to expand their role in M2M.
  • Services for indirectly connected M2M devices bring new opportunities.
  • Scaling the M2M Service Delivery Platform is a crucial requirement.

Taking an indirect look at M2M

When mobile service providers (MSPs) think about the machine-to-machine (M2M) opportunity, they’re typically considering how they can support directly connected devices. These are M2M devices that have a direct cellular connection — 2G, 3G, and soon Long Term Evolution (LTE) — to the MSP’s network. Research suggests there will be 2 billion directly connected M2M devices by 20201. And MSPs are already working to ensure their networks can support M2M traffic growth.

But research also suggests there will be about 12 billion M2M devices in total by 20202. This number includes the billions of indirectly connected M2M devices — those that will connect to the network through a gateway. The potential for MSPs to generate new revenues and improve their position in the M2M value chain increases if they offer services for both directly connected and indirectly connected M2M devices.

Figure 1 illustrates just 3 of the many applications that will fuel the growth of indirectly connected M2M devices.

Figure 1. Traffic from indirectly connected M2M devices already traverses service providers’ networks.

  • Home automation and energy management: As homes become smarter, it won’t be practical for every sensor and monitor in the house to connect directly to the MSP’s network. Instead, these devices will provide information to a cellular gateway in the home, which will then connect to the MSP’s network.
  • Utility meter monitoring: In urban areas with dense smart meter installations, a gateway provides efficient network access for groups of smart meters to connect to the meter data management repository. This same concept can be applied to support other remotely monitored urban utilities, such as parking meters or street lights.
  • Consumer electronics: Smartphones and tablets will become personal gateways for health and wellness devices such as blood pressure monitors, stethoscopes, pulse monitors and elder-care monitors that can sense when someone falls. They will also be used as communications gateways within vehicles, acting as a central point for downloading entertainment, navigation information and even maintenance information.

Existing technology, new M2M services

From a network technology perspective, providing services beyond connectivity for indirectly connected M2M devices makes sense:

  • Communications from indirectly connected M2M devices already traverse their network. No additional network traffic will be generated by providing support for indirectly connected devices.
  • The gateways that provide the entry point for the indirectly connected devices are already directly connected to service providers’ network assets.
  • MSPs are already upgrading their infrastructure to support M2M traffic. Supporting indirectly connected devices allows them to reuse those infrastructure assets to expand the scope and scale of their M2M offerings.

Figure 2 illustrates which network assets will play the biggest role in supporting services for indirectly connected M2M devices.

Figure 2. Service providers can reuse network assets for indirectly connected M2M devices.

M2M operations services

The M2M Service Delivery Platforms (SDPs) which service providers are deploying to manage directly connected M2M devices typically have no information about the M2M devices behind the gateway. Extending the capabilities in the SDP to include data about indirectly connected M2M devices allows service providers to offer M2M application providers new services, including:

  • Bundled billing across all devices for a particular consumer. For example, MSPs can automatically associate a smartphone with home control applications and sensors and provide a single bill for all devices.
  • Data storage, enhanced security and access control. Storing data from the indirectly connected M2M devices in the SDP means MSPs can authenticate applications trying to access data for a specific device.
  • Rating and charging on a per-application basis. Separating traffic into application-specific flows gives MSPs the flexibility to charge different rates for the different types of application traffic that flow from the gateway into the network.
  • Advanced analytics. Knowledge of associations among indirectly connected M2M devices allows MSPs to correlate and analyze data from all associated devices and sensors.
  • Remote configuration and diagnostics. Device data models allow MSPs to offer remote parameter configuration, service activation, firmware upgrades, device diagnostics and other device management services.
  • Device triggering. MSPs can “wake-up” — or page — indirectly connected M2M devices when an application in the network needs to communicate with the device. The wireless network sends a paging signal for a specific device to the gateway that receives it by monitoring the paging channel on the base station and then the gateway can forward that to the M2M device.

Technical considerations

  • The SDP must be scaled to support very large numbers of M2M devices, their properties and the data processing required for advanced analytics. Scaling may include adding more servers and using the cloud to expand as demands increase.
  • The SDP must be updated with the data models, software and protocols needed to interact with the M2M devices behind the gateway. Data models should include:
  • Device identity
  • Device owner
  • Device status, such as active or asleep
  • Dynamic network address
  • Communications protocol
  • Policies related to the device
  • Applications using the device
  • The SDP must be updated with broader algorithms that can correlate data from different types of devices and sensors to provide more comprehensive analytics.
  • Software must be installed on the gateway to support device triggering. Device triggering is being included in 3GPP standards for cellular devices. With additional software on the gateway, this same mechanism can also be used to trigger specific devices behind gateways.
  • The APIs exposed to the applications in the network or Internet will need to include identifiers for the wide variety of indirectly connected devices that can be located behind a gateway. In some cases, new APIs may be needed.
  • Standards, such as the PD-174 extension to the Broadband Forum’s TR-0693 standard and the OMA-DM Gateway protocol from the Open Mobile Alliance4 forum should be followed when managing M2M devices behind gateways.

Traffic monitoring and QoS services

Offering traffic monitoring and quality of service (QoS) services for the applications and devices that use the gateway helps MSPs play a larger role in monetizing M2M applications. For example, MSPs can use deep packet inspection (DPI) capabilities in the network packet gateway to track the amount of traffic from a particular application or device and identify issues. They can also generate charging record information for each application or device.

DPI engines can identify the application or device generating the IP flow based on the Transmission Control Protocol (TCP) port number, the protocol signature, or even a unique application name. After the flow is identified as belonging to a specific application, policies can be applied to it. These could include:

  • Limiting flow bandwidth
  • Generating flags based on volume
  • Applying charging rules based on the flow

Alternatives to using DPI in the gateway include using flow monitoring and analysis tools, such as the Alcatel-Lucent 9900 Wireless Network Guardian (WNG). The 9900 WNG uses port mirroring to access the data going through the gateway.

Technical considerations

  • Policy and Charging Rules Function (PCRF) filters must be updated to include protocols, such as the Constrained Application Protocol (CoAP), that are used in M2M. Policies can then be applied to those protocol flows.

Network access services

Mobile service providers are already deploying small cells in many urban areas. Because the footprint for small cells is similar to that of a sensor network, they can offer to host the gateway function on the small cells. This is a good example of reusing infrastructure to provide services for indirectly connected M2M devices and sensors.

Deploying gateways on small cells base stations and femtocells in the home allows MSPs to provide network access for devices and sensors that communicate using non-cellular protocols such as ZigBee and 6LoWPAN for low-rate wireless personal area networks (LR-WPANs). This is possible because small cells support communications ranges comparable to that of the sensors.

Technical considerations

  • The small cells vendor must include gateway capabilities on the small cells. This typically involves adding communications technology and software such as Open Services Gateway initiative (OSGi) software.
  • MSPs must ensure that the small cells provide complete coverage for the sensors and devices being managed. This is particularly important in outdoor locations. For example, every parking or utility meter being monitored must have access to at least one small cell with an embedded gateway.

Resource optimization services

When smartphones are used as gateways, there’s an opportunity for MSPs to enhance customer experience by ensuring the M2M applications use the smartphone as efficiently as possible. Potential optimizations include:

  • Eliminating separate secure tunnels and keep-alive messages from each sensor device or application. Instead, common client software should provide the connection to the sensors.
  • Saving battery life by preventing different delay-tolerant devices and applications from communicating asynchronously. Instead, the common client software should aggregate data from the sensors and transmit them all at once to the MSP’s SDP. The SDP can then make the data available to the different applications.
  • Reducing processing and software footprint on the smartphone by using the client software to perform common functions across multiple sensors and applications

Technical considerations

  • Each smartphone must include common client software that manages the communications from the different application sensors.
  • Certification processes for M2M must be updated to specify client software that makes efficient use of gateway resources.

Making the most of M2M

The scenarios presented in this article represent just a few of the possibilities MSPs should consider when looking beyond the most obvious M2M opportunities. As more and more M2M devices are deployed, additional opportunities will emerge.

While the revenue per device for indirectly connected M2M devices may be smaller than for directly connected devices, the sheer number of devices makes the opportunities interesting.
With minimal additional technical effort and risk, MSPs can extend their M2M service offerings beyond the gateway. They can take advantage of existing network assets and M2M investments to provide services for indirectly connected M2M devices.

To contact the author or request additional information, please send an e-mail to


  1. [1] Steve Hilton, “Machine-to-machine device connections: worldwide forecast 2010–2020,” Copyright © Analysys Mason Report, December 2010.
  2. [2] Connected Life. Copyright © GSMA 2011;
  3. [3] Broadband Forum, “PD-174: Remote Management of non TR-069 Devices,” Broadband Forum white paper, 2009.
  4. [4] Gary Jones, “OMA and Machine-to-Machine (M2M) Communication.” Presentation at the Global Standards Collaboration (GSC) Machine-to-Machine Standardization Task Force (MSTF) meeting, hosted by TIA during TIA 2011, Dallas, 2011;