My Personal Signaling Load

With the rising use of the mobile Internet, the amount of signaling required to set-up and maintain radio bearers is changing. While in pre-mobile Internet times, radio and core networks were mainly dealing with location updates and signaling due to SMS and voice calls, always-on smartphones are used quite differently.  Lets do a little comparison:

Someone who's only two applications that require network interaction are SMS messages and voice calls might have the following signaling pattern:

• 4 radio bearer setups a day for incoming SMS messages
• 4 radio bearer setups a day for outgoing SMS messages
• 2 outgoing voice calls (some with handovers, which increase signaling load)
• 2 incoming voice calls (some with handovers, which increase signaling load)
• 5 location updates a day (periodic and some triggered because the user as he moves)
• no routing area updates since the mobile is only attached to the circuit switched side of the network
• These numbers are obviously for someone who doesn't move a lot and who is, by today's definition, someone with a low usage. The young generation often sends and receives my more SMS messages a day.

Personally, my CS messaging load is a bit different. I send and receive fewer SMS messages as I mostly use e-mail for text messaging as my friends are distributed throughout the world and these exchanges are usually also not required to be had in real time. But I usually make and receive more than two calls. I try to minimize calls when moving as I find it impolite to talk on the phone while on a public transport and also prefer some privacy when calling.  But for the calls I do make while on public transport I am glad handovers exist.

But now lets go to the packet switched side and see how things are here:

• I am always-on and receive about 4 e-mails per hour. In other words, there are 4 signaling evens per hour or about 4 * 15 hours (per day) = 60 events per day for this application alone. That easily surpasses all my CS signaling
• While on public transportation I often use the time to read my favorite blogs and browse my favorite news web sites. Let's say I browse on 30 pages a day and read each long enough for the radio link to go back to idle. In other words, 30 signaling events.
• While I am moving the radio link has to be maintained and handed over to neighboring cells which creates quite a significant amount of signaling, especially with my 'old' N95 that doesn't have fast dormancy and hence the network needs to work more to maintain the established but not really required radio bearer after background push/pull requests.
• Also during quick breaks I try to catch a news bite or two to know what's going on in the world. Lets say that's an extra 10 signaling events per day.
• No instant messaging or other push applications are running in the background but more and more people are doing that these days, too.

In total that's easily 100 signaling events on the PS side per day. Compared to the 15 signaling events on the CS side for voice and SMS, that's quite a difference, not only for the network but also for the mobile, i.e. the impact on the battery charging interval is significant.

Comments

[lou]

It shouldnt be surprising you use much more signaling in the PS domain since you use the PS domain much more.

Then there is signaling and there is signaling. One thing is moving from cell-pch to cell-dch to get/send ps data (very little sign), another is idle to dch to get sms or calls (alot of it). If anything the ps domain is always more signaling efficient because the dormant states like fach and pch allow transition to full service with much less signaling. Of course this is only the case if fch/pch timers are adequate and u dont get sent to idle after 10 secs of PS inactivity.

On the issue of the fast dormancy i disagree with ur assessment-as i think it is a bad idea. More and more apps use push, so the phone has no real idea when it is the time to go to idle. Furthermore it makes it impossible for operators to tune their NW via fach-pch timers, and you wil get a race to release so that battery stats are better than competitors. Leave the radio resource management to the RAN, it is better that way when no one really knows what will happen at the app layer

[Dan]

A quick note - Fast Dormancy is far more damaging than not, in terms of signaling cost since in most situations it doesn't respect the radio characteristics - in your example Fast Dormancy would make it even worse.

[Martin]

Hi Dan and Lou,

I respectfully beg to differ. From an overall system engineering point of view that takes the requirements of the mobile device and the user experience on all devices into account, it is a most beneficial feature. I have laid out my reasoning in detail here: http://tinyurl.com/2e6dxkt

Cheers,
Martin

[Dan]

Well having to deal with a live network in both GSM and UMTS I can see the implications of fast dormancy played out for real - I can assure you it is not a happy marriage :)

The article you linked was good - but I find no mention for example of relative cost (in terms of load) comparing establishments versus switching (for one example) - and bear in mind any costs saving in terms of either power or resource is likely to be outstripped by the increase volume of signaling.

The main issue if the whilst fast dormancy is perhaps an efficient way to a degree of optimising performance (though FACH tuning or TAC aware systems liable to be better) they are used in conjunction with highly "chatty" smart devices, so efficiency's are often masked or even swamped to a negative result.

[Dan]

part b ;)

I find it questionable that the battery savings in devices such as the iPhone or Android systems are anything like the claims, very little data shows a comparison in a real life situation (often showing power draw against FACH / IDLE / URA in a quasi realistic setting).

I could debate this for hours as it has become something of a passion in work and life but I have to go, but will leave you with this thought - the impact to RNC's of higher number of simultaneous connecting devices (one of the key implications of FAST dormant "smart" devices), when in most vendor minds (and models) the exact opposite ie a mobile broadband setup was expected - and what that means for areas such as RANAP control, etc

[Filippo]

Interesting debate: I wonder if anyone has got an idea of what the ratio of the signalling of PS control plane and that of applications is... such as number of application signallig messages vs one PDP context. I would expect around 10:1 from what I see from Gn interfaces.