18% of Voice Calls Handled in Swedish 3G Networks Now

Two more facts caught my eye in the 2007 market report of the Swedish Telecommunication Authority:

3G Network use for Voice Calls

18% of mobile voice calls (3 billion minutes) where handled by 3G networks, while the remaining 82% must consequently have been handled by GSM networks. Not a huge number yet but it shows the subscriber base is slowly moving to 3G handsets.

Decreasing overall use of Circuit Switched Telephony

The second number is even more astounding: The number of fixed and mobile telephone minutes decreased from 60.000 million minutes in 2001 to just 45.000 million minutes in 2007. The major factor for this is that dialup internet connectivity are being replaced by DSL. Another factor, but minor is the decreasing use of voice telephony due to the adoption of other forms of communications. Mobile minutes are increasing which means fixed line minutes are falling fast.

My SIP Calls Are Proxied – And I Don’t Like it

I recently wanted to check out a couple of things concerning the SIP client on my Nokia phone when I stumbled over something I was not prepared for. In theory, the voice path between two SIP devices is supposed to be direct, i.e. one device sends the speech packets directly to the other device. In my case however, the SIP INVITE messages were always changed by the SIP Proxy to route the speech path packets through a media proxy in the network. I was quite perplexed.

Why would my SIP provider do that? Is someone spying on me? Is the government taping into my calls? Yes, maybe I am a bit paranoid, but this is not the way it is supposed to be. I ran a lot of different scenarios to see if the behavior changed like using different accounts, different SIP clients and different network configurations. However, no matter what I did, the INVITE message sent out and the INVITE message received on the other end were different and the speech path was relayed via a media proxy of my provider.

The Explanation

In the end, I contacted my SIP provider and asked them what was going on, not really expecting that I would get a qualified response. To my big surprise, I got a competent answer from one of the engineers explaining that they've had lots of trouble with Network Address Translation (NAT) in the past and have thus decided to route any call through one of their servers as soon as a NAT was detected in the transmission path. Calls from SIP clients without NAT in the way, he said, would not be routed that way. O.k. I thought, then let's test that, I believe it when I see it.

It's not that simple to set something up without a NAT in the IPv4 address space these days, specifically not behind DSL lines. However, with some VPN tunnels I finally managed to get a setup in which both SIP clients were not NATed. And sure enough, no media proxy in the speech path anymore. O.k. great, so I am not spied on, what a relief.

Open Questions

However, a couple of questions remain. Why all this fuss about "Simple Traversal of UDP over NATs" (STUN) when in the end the SIP proxy detects the NAT situation and deploys a countermeasure without the help of STUN? Is it really that unreliable? Also, sending practically all SIP to SIP calls through a media proxy must require a lot of resources in terms of bandwidth and computing power from my SIP provider for which he is not reimbursed since SIP to SIP calls are free of charge.

Lawful Intercept

This brings me to lawful interception of VoIP calls. Depending on the country you live in there are more or less strict laws in place these days that require that VoIP providers must be able to target all calls going through their system, which obviously includes direct SIP to SIP calls. The only way to do that, without the target knowing that somebody is listening in, is to route all calls through a media proxy. Bitcom, the German association representing the Internet industry is pushing very hard against this, saying that it is not practicable to proxy every call. Seems that that is not quite in line with what is already done anyway to get around NAT issues. A lot of hot air for nothing?

Summary

One way or the other, I don't like my calls being sent through a media proxy no matter for what reason. It's time IPv6 is finally marching in to rid us of NATs. If by the time law mandates commercial providers to media proxying all calls it might be time for my own Asterisk SIP server at home so at least "internal" calls are not proxied. Also, such a solution would provide for security and encryption of the call, both not supported by my SIP provider today.

But then, for those who really want to be sure nobody is listening in, they have to buy a pair of these or these.

I Can Now Detect over 25 Wifi Networks At My Flat!

25 wifisA year ago, I reported that I could receive a stunning 13 Wifi networks at my flat. Since then, the number has risen even further! When I checked this time, I was able to detect over 25 access points, not counting secondary SSIDs of some access points and those networks that could be received but not decoded correctly due to their weak signal strength. Channel 11 is a hot place with over 10 access points sending out their signals in this area. A place in the spectrum definitely to be avoided as at least one access point sends a continuous high bitrate broadcast, probably a TV or video stream. The screenshot on the left, taken with WiSpy/Chanalyzer, shows the distribution of the networks on the different channels an how strong they can be received. My own network is the red curve on the left on channel 1, with at least three or four additional networks using the same channel. However, compared to what's going on at channel 11, this spot in the spectrum can be considered as being almost calm.

An IMS Wireshark Trace

Thanks to the guys at Fraunhofer FOKUS in Berlin, IMS has moved from theory to at least a bit of practice for me as I reported in THIS BLOG ENTRY. As a little souvenir, I got the (Wireshark) pcap trace for an IMS voice call from many different interfaces including interactions between the IMS core and the network layer. Traces a great, one can learn a great deal of how the system works by looking at who says what to whom. Since I got the permission to share the trace I thought I'd post it here since I am sure some of you would like to have a look, too.

Most packets will decode nicely with a standard Wireshark installation, only the router interaction to allow more bandwidth for the connection requires additional DIAMETER xml descriptions. These have to be put into the /wireshark/diameter directory and the dictionary.xml file in the same directory has to be extended as follows:

At the beginning of the file put the following xml descriptions into the already existing list:

<!ENTITY TGPPRx SYSTEM "TGPPRx.xml">
<!ENTITY TGPPGx SYSTEM "TGPPGx.xml">

Afterwards, put the following instructions at the end of the file to load them.

&TGPPRx;
&TGPPGx;
</dictionary>

Final step: Open Wireshark, go to 'edit, 'preferences', 'protocols', select DIAMETER and add ports 4868 and 5868 to the default port 3868.

Have fun!

Download BobcallsAliceandtoomuchBW.pcap

Download TGPPGx.xml

Download TGPPRx.xml

SIP and AMR

Amr
Another post on SIP, yes I am doing a lot of experimenting around it these days. While we don't have AMR-Wideband yet on Nokia phones, one experiment has at least confirmed that for Nokia SIP to SIP device calls, the bandwidth efficient AMR (Adaptive Multi Rate) codec is used instead of the default G.711 codec. The figure on the left shows how this looks like in Wireshark. While the bandwidth requirement of G.711 is 2 x 85.6 kbit/s (uplink + downlink), AMR brings the transmission bandwidth, including Ethernet, IP, UDP and RDP header down to 2x 34.4 kbit/s. The codec rate itself is only 12.2 kbit/s, so 2/3 of the required bandwidth goes into packetization header overhead. While not much can be done about that in most parts of the network, Robust Header Compression (ROHC) in future wireless radio networks can reduce the overhead from 54 bytes down to just a few, thus making SIP calls almost as efficient as current wireless circuit switched calls.

Network Based Packet Modification

By now I guess you must have heard of Deep Packet Inspection (DPI), a method of looking at each IP packet passing through a gateway router for the purposes of making statistics or to shape the traffic of users depending on the content of the packet.  A recent article in Heise News now describes what kind of other features such gateways seem to have built in these days. The report states that wireless network operator of O2 (Telefonica) had “accidentally” activated a feature for some time that did not only look inside the packets but also modified their content to prevent email being sent over an encrypted connection.

It’s easier than it sounds: Most email programs encrypt the connection, if they activate it at all, if the SMTP email server tells them at connection establishment that encryption is available. To this end, the server includes a “250 – STARTTLS” notification in the startup information exchange. To prevent the email client from activating encryption, the network based router simply overwrote this string with “250-XXXXXXXA”.

If the email program is configured to use optional encryption, the email is transferred without establishment of a secure connection and the user does not notice anything at all. The email transfer only fails if the email program is set to require transport encryption, which for example, has to be set manually in Thunderbird and is thus not used very often. In this case the user gets an error message which is how the whole story was uncovered. The same approach also works to stop encryption being activated between SMTP servers exchanging email allowing to look into email transfers between any two SMTP servers such a router sits in between.

Clearly this kind of packet inspection and modification does not serve traffic shaping purposes…

Mobile Broadband Use in Sweden – Interesting Statistics

I have never been to Sweden before, but judging from Ram Krishnan's report on his blog and the pages on Sweden on the prepaid wireless internet wiki, it seems the situation there concerning mobile broadband use is similar as in Austria: Affordable prices and prepaid SIMs that make it easy to go online with a 3G USB stick have made the mobile broadband market surge in the past 18 months. Ram quotes from the 2007 Swedish Telecommunications Market Report of the National Post and Telecom Agency (PTS), available in English here, on the uptake of mobile Internet access in Sweden. Here's my interpretation of the facts and figures:

Only 1% use mobile broadband as their only Internet access

If you have some time, take a look at diagram 8 in the report and Chapter 5 in general, there are some very interesting facts: The diagram shows that at the end of 2007 there were about 375.000 mobile broadband users, up from only 90.000 a year earlier. That compares to about 3 million DSL users and a population of around 10 million. The report says on page 39 that of 2.000 people questioned, only 40 said that they used the 3G dongle at home to complement another access method and only 20 (i.e. = 1%) said that the 3G dongle was their only Internet connectivity at home. So these numbers clearly point out that 3G Internet access is currently used mainly as a supplement to fixed line Internet connectivity. The report also says that since this is a relatively new phenomenon and that it remains to be seen if 3G will remain mainly an add-on to fixed line connectivity at home or if it will seriously start to compete with DSL.

500MB on average per user per month

Diagram 8 says that 375.000 users generated a traffic of 2.200 Terabyte (in the whole of 2007 ?). If you do the maths that amounts to (2.200.000 GByte / 375.000 users / 12 months = 493 MBytes / month.

How Close Are We To Saturation?

So how much is this in practice, how close are we to network saturation? I guess that's quite easy to say for someone who has access to the data of mobile operators. But I don't have that, so let's do a little extrapolating to get an idea of where we might be here with a bunch of assumptions: Let's say the number of people covered by a single 3G base station is roughly the same as a 2G base station, 2000 people. 375.000 broadband users compared to a population of 10 million is 3.75% of the population. Let's double that value to 7% to account for unequal 3G network distribution. 7% of 2000 people are 140 people per cell with a 3G card. Let's say the base stations usually have 3 sectors, and each sector gives an average throughput of 2 MBit/s. That's 6 MBit/s in total. Let's say busy hour accounts for 10% of the daily traffic of 500 MB * 140 people / 30 days / 10 = 233 MB/hour/base station. The capacity of the base station is 6 MBit/s * 60 seconds * 60 minutes / 8 bytes = 2700 MB/hour (minus the capacity used for voice calls).

The above calculation brings us at less than 10% of total available capacity of a base station today. But the input parameters used are highly speculative so the number could easily be half of that our it could be double. If anyone has a different opinion, please let me know.

How Much Traffic Growth in 2008 And Beyond?

This of course opens up the big question of how the growth will continue. When taking the 2006 numbers from the report, an average user consumed 200.000 GByte / 90.000 users / 12 months = 185 MByte / month, i.e. less than half of that of 2007. So this year's traffic and that of the following years will depend on:

  • How many additional users can be signed up
  • Do these users have the same usage patterns as the users today, or more, or less? Potentially, falling prices could attract users with less usage and only very occasional use but also other groups with little money but high Youtube desire.

I think the numbers are hard to predict since the user behavior and clientele will change. While I think that at this point Generation Youtube is not yet on a 3G stick, I wonder what will happen once they do?

The report references a forecast for 2008,
which reports another 140.000 3G USB sticks have been sold in the first
quarter 2008 and which expects 600.000 users by the end of 2008, an
increase of 40% over 2007. This is impressive but definitely a slowdown over the growth observed between 2006/07.

If we stick to the numbers above, we should still be way clear of the capacity limit for 2008. Same for the year after if another 300.000 subscribers are added. If the amount of traffic per user grows by a factor of two in that time frame and the network stays the same, data traffic would grow to 933 MB/base station/h in 2010, still clear of the capacity limit.

Once the limit of current deployments are reached, operators have a number of options:

  • Deploy a second carrier frequency
  • Densify the network, i.e. install more macro, micro or pico base stations to reduce the coverage per site and thus the number of users per base station
  • Work on DSL/mobile broadband conversion and offer interesting packages to users to offload traffic from the mobile network. This of course only helps if people start using wireless broadband as an alternative to DSL. This doesn't seem to be the case so far.

Anyway, one thing is for sure: In countries where broadband wireless access is priced attractively, base stations are no longer just stitting around idling and producing only heat.

An IMS Morning at FOKUS in Berlin

Fokus_logo_en-2
Some encounters are interesting, fun, inspiring and enlightening on top. The recent meeting I had with Dragos Vingarzan, Alberto Diez and Bogdan Harjoc of Fraunhofer FOKUS NGNI can certainly be counted among them. For those of you who have not come accross FOKUS before, they are a German research institute under the roof of the Fraunhofer Gesellschaft and their group is working on IMS related topics. Here's a short roundup of what I've seen and what we discussed, which might be interesting to those of you working on any kind of IMS topic:

Over the years they have put together an impressive IMS setup. Not only have they developed an extensible IMS client, an IMS core network for testing purposes comprising all elements from the various CSCF's, an HSS, presence server, etc., etc., but they have built lots of tools around it from application server toolkits to stress test utilities. Also, they've put their setup to good use and developed a number of stunning IMS application prototypes. On top, their lab and software is open for any company wishing to test their components, devices or IMS backend software in an end to end system. HP, Ericsson, Nokia, Tektronix and many others are making frequent use of it.

Want to play around with an IMS core at home and have a look at the code? No problem, they offer their open source IMS core as a Vmware package that is ready to run with a Vmware player right from your PC.

Not only did I see my first real IMS VoIP call including policy interactions between the IMS network and a core network router, for which I was kindly provided with the pcap trace for some follow up investigations, but I was also shown a stunning combined IMS VoIP/Instant Messaging/Sharing/Collaboration application and a utility called SIPNuke that can easily simulate 10.000 SIP messages a second on an off the shelf notebook to make that IMS core or application server sweat.

Ims_ws_08_logo
If you want to see it for yourself you can do so on the 6th to the 7th November during the 4th International FOKUS IMS Workshop in Berlin. Here's the link for further information and registration. 

Thanks Dragos, Alberto and Bogdan, it has been an exciting visit! I'll put some more detailed thoughs on the demos I've seen in one of the next blog entries.

Breakthrough for VoIP with Wideband Codecs?

I recently wondered why we are still using narrow band speech codecs for VoIP calls between two SIP devices. There were a number of interesting answers and as always the issue is multi-faceted. However, it seems that wideband codec capable devices are now appearing on the market and SIP phones such as the Siemens Gigaset 6XX are actually advertised with superior voice quality between two 'High Definition Sound Performance' (HDSP) phones these days. Here's a link to a web page that demonstrates the difference between today's voice quality and the wideband codec used by Siemens.

While it is difficult (but not impossible) to introduce wideband codecs in fixed and wireless circuit switched networks (e.g. due to the required tandem/transcoder free operation) things are pretty much straight forward in IP based networks. Here, devices negotiate the speech codec to be used directly and no interworking-, transcoding- and digitizing functions are required beyond the user's device that would force the use of a specific speech codec.

Let's hope we don't have to go through many years of fragmentation
where each vendor implements his own set of wideband codecs,
incompatible with those of the competition. But in the end I can very well imagine that  wideband
codecs are the missing piece to bring a real breakthrough for
VoIP. So far, VoIP offers little to nothing beyond circuit switched telephony to the average user. With wideband codecs, however, I am sure most people will start convincing others to switch once they've been on a wideband conversation with someone.

For true success, an important additional requirement is that VoIP providers connect their registrar servers with each other to avoid the call being routed into the circuit switched national network first before being thrown back into the VoIP domain. When this happens, there is no transparent VoIP connection in place and consequently the smallest common denomitator, today's G.711 narrow band voice codec, is used for the call.

Well, maybe it's not so straight forward after all… As always, theory and practice…