Breaking the Radio Silence with VoIP

In cellular networks, the primary rule for voice telephony is efficiency, efficiency, efficiency. Translated into practice, this means that the mobile device patiently waits till it receives a paging for an incoming call or until the user wants to establish an outgoing call. In the time between, there is complete radio silence, except for occasional short signaling exchanges once every few hours to confirm to the network that the device is still switched on. With always on mobile Internet devices, this is going to change significantly, as the following example shows:

In previous blog entries, I've described how well the SIP VoIP client works on the Nokia N95. It blends in very nicely with the rest of the phone's functionality and I can't tell the difference between a cellular call and a VoIP call over Wifi. On the radio layer, however, things could not be more different.

While the cellular telephony application remains silent while no call is ongoing, the VoIP part remains quite active on the IP layer. Per minute, there are at least 10 message exchanged between the mobile and the network for various reasons such as keeping communication ports open on NAT firewalls. While it doesn't seem to be an issue for battery capacity, as there is still ample capacity left in the evening despite being logged into the SIP server over Wifi all day,  it does have implications for cellular networks once VoIP is used there, too. While not all messages exchanged over Wifi will appear in cellular networks, at least 6 of those 10 are relevant for that scenario as well.

Today, each cell serves about 2000 users. For the network, this is not a problem since most mobiles are dormant. In a world where most mobile devices are IP enabled and use a standard SIP VoIP client, 2000 x 6 (or even more) message exchanges per minute means 12,000 message exchanges per minute over a single cell for more or less nothing.

To stay with the SIP VoIP example, here's an overview of what I traced with my Wifi Tracer during a typical 60 seconds time interval while the SIP client is running and the phone is connected to a Wifi network:

• At 7 seconds into the minute, the N95 wakes up because it receives a notification from the access point that an IP packet has arrived. It sends 'power save poll' management frame and receives an IP packet from the STUN server or the SIP server. In total, the mobile transmits 4 frames and receives 4 frames during this message exchange (including acknowledgments at the MAC layer).

• At 11 seconds into the minute, The N95 decides to return the polling gesture and sends 1 packet to the STUN server and 1 packet to the SIP server. The STUN server sends a confirmation. Afterwards, the mobile enters the Wifi sleep state and informs the network with a corresponding management frame. In total, the mobile transmits 4 frames and receives 3 frames.

• At 12 seconds into the minute, the mobile has to turn on it's transmitter again because there is some data waiting again. It sends a poll frame and receives an ARP broadcast as the access point queries all IP addresses in the subnet. The mobile answers the ARP request and goes back to sleep. In total, the mobile transmits 7 frames and receives 6 frames.

• At 16 seconds into the minute, the mobile feels a sudden urge to check that the MAC address of the router is still valid. This is as unnecessary as the ARP request from the router at 12 seconds, but it's happening at least once a minute. The mobile transmits 2 frames and receives 2 frames.

• At 22 seconds into the minute, a keep alive frame is received from the SIP or STUN server. I stop counting frames at this point.

• At 34 seconds into the minute, the router runs another ARP request for all IP addresses in the subnet.

• At 35 seconds, the SIP/STUN server sends a keep-alive frame.

• At 37 seconds, the mobile returns the favor.

• At 46 seconds, the mobile returns to sleep state and signals this to the Wifi Access Point.

• At 49 seconds, the SIP/STUN server sends a keep alive frame.

• Silence until 4 seconds into the next minute.

And now imagine you have a push eMail client and Instant messenger running, which will create even more traffic and 2000 other mobiles in the cell doing the same.

Standards bodies seem to have become aware of this issue, at least to some degree and have started to specify radio interface enhancements to counter the challenge. In case of UMTS and HSPA, the following come to mind:

• The Continuous Packet Connectivity (CPC) feature set
• Enhanced Cell-FACH
• To some degree: IMS, which probably doesn't need the polling as there is no NATing
• And finally: More use of IPv6, which reduces the need for NATing

I am not sure how LTE and WiMAX handle such very low speed but persistent message exchanges on the MAC layer. If anyone can give me pointers to that, I'd really appreciate.

Comments

[Stefan Constantinescu]

i've said it once, i'll say it again, we need to move past this NAT pile up mess and just switch to IPv6.