First ‘One Tunnel’ Network Sighted in the Wild

While LTE is in development, loads in 3G networks are increasing and network operators are looking for ways to reduce their costs. One such move seems to be moving to a 'One Tunnel' architecture in which the user data packets bypass one of the packet core nodes, the SGSN.

Instead of tunneling the packets between the mobile device and the Internet through the base station, the RNC, the SGSN and the GGSN, this approach directly connects the RNC and the GGSN. As a consequence, fewer resources are required on the SGSN since it doesn't have to 're-package' the frames from one tunnel into another (hence the feature's name 'One Tunnel'). For details see this blog entry.

Nokia Siemens Networks now reports that network operator '3' in Austria is their first customer for the One Tunnel feature in this podcast that can be found here. I can imagine that they are quite keen to use the feature since Austria is a very competitive market and SIM cards and USB data sticks for 3G Internet access can be bought in every supermarket for next to nothing.

HSDPA Alongside A CS Voice Call

Back a year ago I noticed that an incoming circuit-switched voice call during a 3.5G HSDPA packet-switched data session forced the packet connection to go back to 64 kbit/s dedicated bearer while the call was ongoing. After the call the bearer was upgraded to 384 kbit/s but was only put back on the High Speed Shared Channels once the download was finished. Looks like the software on the network side has advanced a bit in the meantime as I recently noticed that even during a phone call an ongoing download continued at HSDPA speeds. Very nice!

Note: The test a year earlier was performed in the German Vodafone network while my latest observation is from the Orange France network. The RAN vendors might not necessarily be the same and it's even likely that they are not.

Smartphones: Units, Revenue, Profits

Recently, David Wood shared a couple of interesting numbers on his blog on the importance and relation of smartphones compared to 'ordinary' phones. In his post he says that while smartphones only account for 10-15% of sales units, the sales revenue is between 20-25% and profits may even exceed 40%.

So far, I wondered if big mobile manufacturers are mainly working on smarthphones as a way to secure their future by developing new features on these platforms and then work on finding ways of implementing them on cheapter platforms. These numbers, however, suggest that even for their running business, smartphones have a major impact on the bottom line, despite the small unit numbers.

Femtocells and Connected Home Services

Last week I met Thierry Samama in Paris, who is looking after ip.access' pico- and femtocell business in France to discuss a bit about the wireless industry and, of course, about femto cells. I asked him what he thinks about accessing devices at home via a 3G device directly via the femtocell instead of going through an operators core network. It was good to hear that ip.access is actually already working on this and he pointed me to this video in which they demo their connected home services capabilities. The video doesn't give many technical details but the applications shown are just what I had in mind concerning interaction between 3G handsets and devices at home such as a media server, TV set, etc.

The Key To The User's Heart

To me, accessing the home network via the femtocell holds the key for users actually wanting a femtocell at home. An alternative are of course dual mode devices with a Wifi interface. However, without pre-configuration of those devices by the mobile operator, who could of course do that if they wanted to, most people will have difficulties configuring the device to make use of them in the home network. Definitely an advantage for femtocells since no configuration of the mobile is required.

The video doesn't say exactly how local access works and how the applications on the Windows Mobile driven devices access devices and in the home network. UPNP perhaps? Nokia has already made strides in this direction with UPNP, which is part of S60 and Nseries phones which come equipped with a Wifi interface.

Femto In A Bundle

So I think femtos packaged together in a single box with Wifi and DSL/cable access sold by a converged fixed/mobile operator will best sell in a bundle which also includes mobile devices, pre-configured applications on them that can access resources in the home network, a media server at home and some IPTV. So instead of getting a subscription for a DSL line which includes IPTV and fixed line telephony offered these days in many countries, I could very well imagine that the femto that allows local access forms the bridge to the wireless world and removes the need for that extra telephone line. Others like Nokia are likely to take the Wifi/UPNP approach and it will be interesting to see how the different approaches compete with each other.

For more info on Femtos, connected home services, handover, autoconfiguration etc. have a look at ip.access' home page, they've got some good ressources there.

DPI and eMail blocking

The more I use wireless Internet access, the more things I stumble over how network operators use Deep Packet Inspaction (DPI) to 'shape' use to their liking. After having been blind charged for eMail in the past and having seen reports of network operators modifying email signaling exchanges to prevent encryption from kicking in, this time I am blocked from receiving eMails.

My current mobile Internet access via a prepaid SIM from Orange in France contains unlimited Internet access and 10 MB (yes, a mere TEN!) to access my email via POP3 or IMAP. I have no idea how I could have stepped over this limit since I am only days in the monthly subscription cycle and all emails downloaded to the mobile are capped at 15 kb. However, one morning I could no longer poll my mailboxes.

Profimail on my N95 crashes as soon as I attempt to access my mailboxes and the Nokia email client reports that the connection to my email provider has failed. Over a Wifi link, both programs can access my email just fine. So I turned to Wireshark to check what is going on and saw that when connected via Orange, the TCP connection requests on the port numbers reserved for POP3 and IMAP are not discarded, as I would have expected it, but immediately answered with a RST (Reset) packet. Note that this packet must have been originated by the DPI device. Looks like Profimail doesn't handle rejected connections gracefully and decides to exit.

Apart from the technical glitch that this provokes, I don't think Orange is doing itself a favor by just blocking incoming eMail. They should have at least sent me an SMS saying that my monthly transmission volume for email has been exceeded and that I shouldn't be surprised that it has stopped working. They could even use it as an upsell opportunity to open the email gate again for an additional charge after sending a text message with a certain content. I'd be happy to pay even if I don't know how I stepped over the limit. Without this option I am now stuck to the mobile webmail interface of my mailboxes while in France, which is a bit uncomfortable. The average user, however, will just be turned off by such a behavior and will probably turn away from the service entierly.

Also, they should offer a web interface that shows me when an how I have spent 10MB on emails in just a couple of days. I am really puzzled.

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.