Getting Ready for M2M Traffic Growth


  • Signaling traffic will be the main bottleneck, as M2M transactions increase
  • Application-level management can enhance traffic control and efficiency
  • A new network element, the M2M server, could enforce policies for network usage

As machine-to-machine (M2M) (a.k.a. Internet of Things) communication takes off, wireless network operators need to establish methods for handling an explosion of signaling traffic.

Use of machine-to-machine (M2M) communications is growing significantly, and wireless networks are playing a larger role. While these developments are still in their early stages, network operators must consider how to handle the enormous increases in signaling traffic generated by M2M applications. In particular, they need new ways to meet each M2M application’s requirements and service level agreements (SLAs) — while protecting the network and making more efficient use of available resources.

One effective approach is to combine three levels of traffic management. Access and network level of traffic management can be addressed with mechanisms in the RAN and the core network respectively, while application-level management provides the optimal point for preventing network congestion. In an ideal application-level management solution, a new network element or gateway that lies on the boundary between the applications and the network would help network operators prioritize traffic from different M2M applications and enforce network usage policies ensuring customer satisfaction.

Looking ahead: Key M2M traffic issues

Network operators need to consider how the following issues could affect performance and cost efficiency.

Escalating traffic volumes
Eventually, billions of devices — such as sensors, consumer electronic devices, smartphones, PDAs and computers — will generate billions of M2M transactions. For example:

  • Price information will be pushed to smart meters in a demand-response system.
  • Push notifications will be sent to connected devices, letting a client application know about new information available in the network.

The scale of these transactions will go beyond anything today’s largest network operators have experienced.

New signaling demands
Signaling traffic will be the primary bottleneck as M2M communications increase. Alcatel-Lucent Bell Labs traffic modeling studies support this by comparing network capacity against projected traffic demand across multiple dimensions (such as signaling processing load on the radio network controller, air-interface access channel capacity, data volume and memory requirement for maintaining session contexts). The limiting factor is likely to be the number of session set-ups and tear-downs. For the specific traffic model and network deployment considered in the study, it is seen that up to 67 percent of computing resources in the radio network controller is consumed by M2M applications. Access channel capacity does not appear to pose a problem, nor does data volume.

Inefficient use of resources
Today, developers often disregard the network when writing applications. They communicate to their devices with no knowledge of the device status or network status — which includes key information on the location of the device, its wake-up times, who has authorized access and which parts of the network are congested. The consequences of such an uncontrolled approach are magnified as the number of new applications proliferates.

This “network-blind” approach results in inefficient application behaviors that increase resource consumption in both the network and the device. For example:

  • Push notifications are sent to a large number of devices within a small time window, creating huge spikes in signaling load.
  • Devices send frequent “keep alive” messages just to ensure the network address translation (NAT) port remains open.
  • Devices ping the network every few minutes when unable to connect to the application server.

New traffic management methods

Clearly, network operators cannot simply rely on “well-behaved” applications to avoid network congestion. They need to exercise new, more effective traffic control methods while maintaining customer satisfaction.

Three complementary levels of control
Current methods for addressing unexpected application behavior on wireless networks are limited to overload prevention. A more efficient approach would operate at three complementary levels. Overload protection mechanisms at the RAN and core network would prevent flawed applications from abusing the network, while application-level management would enable more efficient use of network resources. More specifically:

  • Application-level management – offers the ideal vantage point for M2M traffic management, by allowing network operators to take diverse application requirements into consideration.
  • RAN signaling overload control – focuses on communication between a device and the access network. If these transactions overload the network, the RAN can broadcast a message to block further access until the overload condition is resolved.
  • Core network overload control – provides another level of overload control. If the first access network node is not a bottleneck but the core network is, then the access network can be instructed to block further accesses for M2M service requests.

A closer look at application-level management

More efficient scheduling
If water meters, electricity meters, POS and home security devices are all served by the same RAN, each application could submit its requested access time window. Based on these requirements and network status information, such as busy-hour data, a network-aware M2M server could then determine a schedule for meeting application requirements while maintaining efficient use of network resources. For example:

  • Water meters – 1:00 a.m. – 2:00 a.m. in increments of minutes
  • Gas meters – 3:00 a.m. – 4:00 a.m.
  • Home security devices – open

The application level is the most ideal point for managing traffic, because it gives network operators an opportunity to prioritize M2M transactions. That is, some applications, such as smart meters and vending machines, have very flexible communication requirements. For other applications, such as security systems and health care, response times may be critical. Prioritizing these transactions allows real-time responses when necessary, while using the flexibility of other applications to optimize usage of network resources.

An ideal application-level solution would also eliminate current inefficiencies in M2M communications by:

  • Greatly reducing the need for application-level keep-alive messages
  • Using network services to wake up devices, instead of SMS
  • Providing DNS updates from the network, rather than the device
  • Eliminating duplicate security tunneling through network operator security
  • Offering application layer group authentication and registration for devices that can also communicate locally through another interface

A network-aware M2M server
To enable prioritization of transactions, an M2M solution must increase network awareness of M2M application requirements and then enforce policies for network usage. This solution needs a new network element, an M2M server that can provide network-aware, advanced connectivity services for applications to connect to their devices as shown in Figure 1.

Figure 1: Conceptual view of the M2M server

The gateway element should be located on the boundary between a wireless network and the Internet network used by application servers to communicate to a device. There, the M2M server can maintain sessions to application servers on one side, and to devices on the other side, as shown in Figure 2. In other words, it acts as a bridge, bringing information from the application server to appropriate devices.

Figure 2: M2M server in the network

The role of policies
With the M2M server in place, application servers can make requests to exchange information (or messages) from specific devices according to appropriate policy information. The policy guidelines are preconfigured or sent with other information. They identify, for example, when a message must be delivered and whether acknowledgement is needed.

The gateway element then schedules delivery of this information, after taking the following steps:

  • Checking policies that define which application servers are allowed to exchange information with the devices
  • Ensuring the device adheres to policies that define location-specific restrictions
  • Obtaining network congestion information from the network for optimal scheduling of communication with devices
  • Choosing the best method for waking a sleeping device, based on the level of urgency
  • Using battery status information to determine when to establish communication

The M2M server can explicitly provide APIs to the M2M applications to perform these functions. Or it can act as a proxy that is transparent to the application.

Handling push messages
When messages are pushed from the device to the application server, the M2M server notifies the device when the application server is ready to receive the information. An application’s repeated requests to connect to the network can be filtered and rejected — until notification from the M2M server is obtained. With this approach, the network is protected without modification to the device application.

Industry focus on solutions

The telecommunications industry is already focused on creating solutions that will help network operators address tremendous growth in M2M traffic. Standards for overload control in the RAN and core network are under consideration by telecommunications standards bodies, to which Alcatel-Lucent contributes significantly. And new network elements, such as the proposed M2M server, are in development by Alcatel-Lucent. We’ll be sharing more here on Alcatel-Lucent TechZine and on our M2M page as development progresses.

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