Cellular IoT – Network Friendly Devices and GSMA TS.34

Local network technologies like WLAN have a distributed coordination function, i.e. every device decides for itself when it wants to transmit on a common channel and have backoff and repetition features with random and increasing delays to get out of situations when more than one device transmits at the same time. Another helpful thing in local networks is that there are usually just a limited number of devices so distributing control instead of having a centralized controller usually works well. In cellular networks, things are quite a bit different and sometimes mobile devices don’t act very friendly when their communication request is rejected and start bombarding the network with connection requests that are promptly rejected again if the reason for rejecting them persists. Especially in the world of IoT, unfriendly devices can become a problem quite quickly. Time to do something about that…

The Problem

In practice, cellular base stations deal with thousands of devices and control is centralized. If a device wants to transmit data it has to use the random access channel to ask for transmission/reception opportunities from the cell and is then assigned opportunities to send and receive data based on the amount of data, free capacity in the cell, number of other devices competing for the shared spectrum, quality of service requirements, etc. etc. Also, the network can reject communication requests, for example, if the device has no network subscription, when the cell is overloaded, temporary network failures, etc. etc. All of this is standardized in 3GPP including reject cause values to inform mobile devices of why their communication request has been rejected.

Unfortunately there is a real gap in 3GPP specifications when it comes to the device behavior for the different reject causes. In recent years, backoff timers have been specified for a few reject causes but by and large no behavior is specified for most reject causes. In practice this has led to devices that keep banging against the network despite getting reject causes that make it quite clear that it’s useless to send another request.

While in some cases this is already a problem today it would become even worse with the Internet of Things as the number of devices in the network might rise significantly. It looks like help from 3GPP did not come so a number of network operators have pooled their resources in the GSM-Association (GSMA) and have come up with a set of ‘IoT Device Connection Efficiency Guidelines’ in document TS.34. The document contains an interesting section on how to prevent devices from repeating useless and harmful communication requests.

The Solution

Have a look at chapter 7.1 on “Network Friendliness” that describes what they have in mind. The idea behind network friendly devices is that in case an attach is rejected by the network, the radio module prevents the application layer from repeating the request in short successions. 7 delay timers can be used to increase the backoff time between each communication attempt to up to one and a half hours between attempts. A random element was put in as well to avoid that many devices send their requests simultaneously, e.g. after a power outage when many devices are restarting simultaneously. Further, TS.34 specifies how and where the backoff timers are stored on the SIM card.

I really like the idea because I have seen what happens when mobile devices start running wild and request an IMS default bearer and repeat the exercise every second if they are rejected. Let’s hope the GSMA has enough influence on device manufacturers to encourage them to implement TS.34.

One thought on “Cellular IoT – Network Friendly Devices and GSMA TS.34”

  1. That seems good, I have always wondered why ethernet based systems have had back-off well defined since the very early days, but in many cases 3GPP systems haven’t though of this – I too have seen this cause issues which could have been solved, or at least minimised, with a decent retry timer mechanism – in the best case the time could be specified by the network based on needs, much like an automatic call gapping mechanism in voice networks.

Comments are closed.