Radio Resource Control States and the Tail Timer After the Last Byte

A request that completes in forty milliseconds can hold the radio open for ten seconds. The payload is finished, the socket is idle, and the device still draws power at a level close to active transmission. The reason is that the cellular air interface does not model a data transfer as a transaction. It models a device as being in one of a small number of states, and moving between them costs the network signalling and the device power. The timer that decides when to leave the expensive state is not under the application’s control, and it is measured from the last activity, not from the last request the application cared about.

Understanding the state machine is the difference between a client that pays for one transition per user action and a client that pays for one per request.

Three states and what each one commits

In the LTE radio resource control protocol, a device is either idle or connected. In 5G it may also be inactive. The names matter less than what each state allocates.

An idle device has no radio bearer and no context in the radio access network. It listens to a paging channel at intervals, and nothing else. Its location is known to the core network at the granularity of a tracking area, which may span many cells, so the network pages the whole area when downlink data arrives. Power consumption is low but not zero, because the receiver wakes for every paging occasion.

A connected device has a bearer, a scheduling identity on the shared channel, and a context in the base station. The network knows which cell it is in, so downlink data can be delivered without paging. The cost is that the device must monitor the control channel to know when it is scheduled, and the network must keep per-device state for as long as the connection exists.

Inactive, defined for 5G, is a deliberate middle: the device keeps its access stratum context and the network keeps it too, but the radio link is released and the device pages within a smaller area, a set of cells rather than a whole tracking area. Resuming from inactive is cheaper than a fresh setup because the security context and the bearers are already established. It is an acknowledgement that the binary choice between idle and connected was leaving a large amount of value on the table for bursty traffic.

The inactivity timer is the bill

A connected device that stops sending does not immediately return to idle. The base station keeps the connection for a configured inactivity period, because tearing down and rebuilding is more expensive than waiting, and because the next packet usually arrives soon. The parameter is set by the operator per cell or per subscriber class; values on the order of ten seconds are common, and the range in deployed networks is wide enough that an application cannot assume any particular value.

During that period the device stays connected. If a packet arrives before the timer expires, the connection is reused and no signalling occurs. If the timer expires, the network releases the connection, and the next packet must pay for a new one.

That structure produces a step function in cost. Two requests separated by less than the timer are cheap: the second uses a connection that is already there. Two requests separated by more than the timer are expensive: the second pays a random access exchange and a connection setup exchange, which together are several round trips before the first byte of payload. For a link with a round trip in the tens of milliseconds, the setup alone is on the order of a hundred milliseconds, and it is serialised in front of the request.

The transition is not instantaneous even when it succeeds. Random access requires the device to transmit a preamble and wait for a response, with contention resolution when two devices pick the same preamble. A busy cell makes that wait longer and occasionally requires a retry. This is why a cold request on a cellular link has a latency distribution with a long right tail rather than a fixed overhead.

Paging is the price of being idle

An idle device still has to be reachable, and reachability is provided by paging. The device wakes at every paging occasion, defined by a cycle broadcast in system information. In LTE the cycle is one of 32, 64, 128, or 256 radio frames, each frame being 10 milliseconds, so the device wakes every 320 milliseconds to 2.56 seconds depending on what the cell advertises.

The device computes which frame and which subframe within it are its own from its identity, so different devices in a cell wake at different instants and the paging load is spread. Between its occasions the receiver can be off. This is the dominant reason an idle device lasts days rather than hours, and it is also why the delay before an idle device receives an unsolicited message is bounded by the cycle: the network cannot deliver anything until the device next listens.

In connected state the equivalent mechanism is discontinuous reception. The device monitors the control channel at defined on-durations separated by a configured cycle, so it does not have to decode every subframe. Connected-mode cycles are shorter than paging cycles, because latency matters more once a bearer exists, and the standard allows a long cycle up to 2.56 seconds with a shorter one used while data is flowing.

What the state machine implies for request pacing

The practical consequence is that the cost of a network operation depends on when it happens relative to other operations, not only on how large it is.

A screen that issues six independent requests when it opens pays for one transition and one connection setup, then reuses the connection for the remaining five, provided they are issued close together. The same six requests issued from a timer, one every fifteen seconds, pay six setups. The payload may be identical. The energy and latency difference is an order of magnitude.

This is the reasoning behind batching: collecting requests that can wait, then issuing them in one burst inside a single connection window. The technique is discussed from the energy side in Radio tail energy and the cost of the second request, but the mechanism that makes it work is the one described here — the tail exists, so the marginal request inside the tail is nearly free, and the marginal request after the tail is not.

A rough model of the cost of a sequence of requests is enough to reason about designs:

def radio_cost(times, setup, tail):
    """Cost in 'connection-seconds' for request timestamps (seconds)."""
    cost = 0.0
    end = None                    # when the radio returns to idle
    for t in times:
        if end is None or t > end:
            cost += setup         # cold: a new connection is set up
        end = t + tail            # the timer restarts at each activity
    return cost

The model ignores payload volume and treats the tail as a constant, which is wrong in detail but right in structure: what dominates is the number of cold starts, and that number is decided by spacing.

Prefetching against the timer

Because the setup cost is paid at a transition, an application can choose to pay it before the user asks for anything. Prefetching during a period when the radio is already active, for example while a list is loading, puts the next screen’s data behind the same connection. The cost is bandwidth and server load, and the risk is fetching something the user never opens. The trade is asymmetric on mobile: bytes are cheap relative to transitions, so a prefetch that hits is a large latency win, and a prefetch that misses costs a few kilobytes and no extra state change.

The opposite pattern, polling on a fixed interval, is the worst case for this machine. A sixty-second poll interval is longer than most configured tails, so every poll pays a full setup, and the device is connected for a substantial fraction of each minute regardless of whether anything changed. Push delivery, described in Push notification as a store-and-forward channel, exists largely to convert that pattern into one where the network decides when the device must wake.

Where the model stops matching the network

Three details complicate any design built on this picture.

The first is that the timer is not visible to the device. There is no API that reports the remaining tail, and the value can differ between cells and can be changed by the operator. A client can only infer the state from observed latency: a request that takes a hundred milliseconds longer than its payload justifies was probably cold.

The second is that the device is not always the party that ends the connection. The network releases it on its own schedule, and a device that has been idle for a while may be idle already even if the application believes otherwise. Conversely, a device with an active socket may still see the connection released if the network is congested and needs the resources.

The third is that modern devices run several applications over one modem. The radio state is shared, so an application’s request may find the connection already warm because a different application used it moments earlier, and its own batching decisions may be paying for transitions it did not cause. The state machine is per device, not per socket, which means the marginal cost calculations above are approximate even in principle.

None of this makes the state machine less useful as a design model. It makes it a model of a shared, hidden resource rather than a private one, and the correct response to a hidden shared resource is to minimise the number of times it must be acquired, which is what batching, prefetching, and push all do in different ways.