WirelessMoves

After noticing that the Nokia E75 announces SIP AMR-WB capabilities I did some follow up work to see where it is standardized and how universal it is. According to Wikipedia, AMR-WB is specified in ITU G.722.2. Several bit rates are available and what I can see in 3GPP, codec rates up to 12.65 kbit/s are used in wireless. Makes sense as that is a similar maximum bit rate as for EFR (Enhanced Full Rate) or AMR-FR (Adaptive Multi Rate – Full Rate) in GSM and UMTS today, i.e. the same air interface bandwidth is required as for todays codecs.

To be able to use AMR-WB in wireless networks, transcoders need to be deactivated in the network. The features for this are Tandem Free Operation (TFO) and Transcoding Free Operation (TrFO) in GSM and UMTS respectively. For details on those see a blog entry I wrote back in 2006 (!). Interestingly enough, this blog entry is still very popular so it looks like quite a number of people are working on this.

So what about fixed line networks? Here, my picture gets a bit sketchier but I'll try to put the pieces together here. If you have different/additional info, please let me know. The successor to the current cordless digital standard (DECT) is called Cat-iq. Again according to Wikipedia, the wideband voice standard used here G.722 at 64 kbit/s. G.722 is the big brother of G.722.2 and they don't seem to be compatible. Also, it seems that the wideband codec can only be used over an IP link, i.e. the phone must be connected to a SIP VoIP provider. On this thread, Frank-Christian Kroegel mentions that ISDN can also be used for the wideband codec but it seems that is not done in practice yet. And anyway, except for Germany and a few other countries, ISDN is not widely deployed anyway. 

So it looks like wideband voice is going different ways in fixed and mobile networks for the moment. That's a pity but who knows, with fixed and wireless networks operators merging again these days, things might change in the future. I wonder how long it will take to have a wideband voice future besides with Skype?

Recently a friend asked me if it was possible to block sending his caller ID when he uses his mobile phone for all calls in general but define exceptions for calls to friends and family. Sounds complicated but it's actually rather simple. Here's how it can be done with any GSM or UMTS phone: First find the menu entry which lets you select if by default your caller ID is shown or not. For the scenario above, set it to “never show my caller ID” or similar. For your friends that should see your number when you call, go to the phone's phonebook select the relevant entries and add the following code in front of the phone number:

*31#

This tells the phone to inform the network not to apply caller ID blocking for this call. It's a standardized GSM/UMTS supplementary service code so it should work with pretty much any phone. For more of those codes have a look here.

There are two reasons mobile network operators are giving out private IP addresses to mobile users and map the traffic over a Network Address Translation (NAT) gateway to and from the Internet. The first is that IPv4 addresses are a scarce resource and assigning a public IP address to every user would require a huge pool. The second is reason battery drain. As public IPv4 addresses get reassigned, unsolicited packets can arrive at the mobile device for example from file sharing applications that were intended for the previous owner of the IP address, from virus- and other malware programs probing computers for potential weaknesses and from other origins. This phenomenon can be nicely observed in networks that use public IP addresses like Vodafone Spain for example and drain the battery really fast as the air interface is constantly in connected state. NAT keeps those packets from coming in which is good for battery consumption. On the other hand, network address translation renders services running on the mobile device that are waiting for incoming connections useless.

IPv6 can easily fix the later problem as the address space is so huge that each mobile device gets assigned a full 64 bit address space from which a network identifier (the other 64 bit of the address) can then be selected. The network operator is assigned a 32 bit part of the IPv6 address (for details see the German version of the Wikipedia entry on IPv6) which means that almost 4.3 billion devices can be hosted with a single assignment. So will that help with the power consumption problem due to unsolicited packets? If subnets are randomly assigned, then that might just do the trick as spamming such a large address space with unsolicited packets is likely to be quite difficult if not impossible.

IPv6 enthusiasts out there, what do you think?

Happy new Year 2010 to all of you! And not only to you as in Germany, like in many other places around the world it's custom to send a new year message to friends and family by SMS or give them a call right after midnight. Bitcom estimates that in Germany, 300 million SMS messages are sent over the change of the year. Compared to the average of 80 million messages a day, that's quite a spike, which is, from experience, highly concentrated over the first few hours of the day.

So I wondered how long it takes for messages to be delivered during such an extraordinary traffic peak? Between 10 minutes past midnight and 40 minutes past midnight I sent four messages from a 3G phone to a 2G phone. All messages were immediately accepted my the SMSC. The delivery was then deferred for some time. The first messages was delivered within 10 minutes, the following two in about 25 minutes and the fourth took again a bit longer to be delivered. It look like the fireworks takes precedence. So yes, the SMS Service Centers must have been quite busy 🙂

Already back in November 2009, the 5th IMS Workshop organized by Prof. Thomas Magedanz of the Fraunhofer Research Institute FOKUS took place in Berlin. Unfortunately I couldn't attend this year but the good news is that most of the conference slide packages are available on their website after registration. Honestly, I wanted to blog earlier about it but I first wanted to have a look at some of the presentations myself so I could add a personal touch to the post. Not so easy as the conference was packed with exciting presentations so it took me a while before I could find a couple of hours.

Unlike the name of the conference suggests, the presentations were not all about IMS but rather about how the IMS could potentially fit into the ecosystem and how it could potentially provide a link between the telecom and the Internet world. As one presenter pointed out in his presentation, the telecoms world is pretty much on an evolutionary path while applications born in the Internet space are usually done so in a revolutionary way. Without some special glue, the worlds don't fit together very well and a lot of friction is created.

Here's an overview of the conference and workshop streams, each with a number presentations. If it sounds interesting, head over and take a closer look (the link to the presentations is on the top left side of the page):

• Workshop 1: Facing the Technology and Landscape beyond Voice
• Workshop 2: IPTV & Media Convergence
• Workshop 3: Future Internet – What Can We Use Today?
• Workshop 4: NGMN – From Vision To Reality
• Conference Session 1: IMS as a Convergence Platform
• Conference Session 2: Rich Media
• Conference Session 3: Keynote from Henning Schulzrinne: Preventing Congestion Collapse of SIP Servers
• Conference Session 4: NGN and Future Internet

An if that wasn't enough there were even more presentations given during an additional event the day after which was called "NGN Service Delivery Platforms & Service Overlay Networks". Again, the presentation slides can be found online.

Great stuff, I hope I can be there in 2010.

I have to admit that although I like video calls I haven't made one in quite a long time, mostly due to international video calls being prohibitively expensive and some network operators that still bar prepaid customers from receiving video calls. That severely limits my options… Anyway so for Christmas I called family and friends and some of them by now even have video call capable 3G phones. A very nice experience!

Despite many people arguing that video calling is a lost cause I still think it's a great opportunity for mobile network operators to offer a service only they can provide in a truly mobile and (almost) always-on fashion, at least for the moment. Don't get me wrong, I don't want all of my calls to be video calls but sometimes it would be very nice to get a video stream from the other side.

Unfortunately, there are still some significant hurdles to video calling even many years after the launch of 3G networks:

• 3G in-house coverage is still a big issue, especially for video calls. Femtos and UMTS on 900 MHz will help over time.

• As I said above, many network operators still limit video-calling to their post-paid subscribers. I can understand the notion of premium service and all, but after so many years I think it's time to open it up to all subscribers to create a critical mass.

• Pricing

• No interfaces to other video systems that are popular such as Skype

• No advertising around video-calls at all. Quite incredible and I wonder how many people are aware that they could actually make a video-call with their phone.

And while we are at it, it would also be nice to see someone implement features such as voice only at first and adding a video stream later or see-what-I-see on my phone.

Wait a second, some of you might think now, why is a cellular guy like Martin writing about Wi-Fi hotspots? The answer is simple: Along train routes, cellular coverage is often patchy but some train operators (such as Thalys or German Railways) offer Internet access over Wi-Fi with a land- or satellite based backhaul. While that works quite well in practice, there are a number of quite real security risks with non-encrypted public Wi-Fi hotspots: One of them is that all packets transmitted over the air interface can easily be eavesdropped on by another hotspot user with software that is publicly available. While that's not much of a problem for HTTPS encrypted web pages it's those unencrypted web pages using cookies for user authentication that can be easily intercepted and stolen.

The only way to get around this issue is to use a VPN (Virtual Private Network) solution to encrypt all traffic.  Some hotspot providers offer a free client for the purpose. But if you have a computer at home and a fast DSL line with a good uplink, you can also use it as a VPN gateway. All traffic is then encrypted and sent to the PC at home and from there to the Internet. Sounds difficult but it's rather easy to set up. All you need is:

• A Windows XP, Vista or Windows 7 machine to act as the PPTP VPN server. You can find a description of how to set it up here. A Linux server can of course also do the job but I don't have installation instructions at hand.

• A DSL/cable router that can update a dynamic dns server such as dyndns.org. This way, your VPN server can always be found from the Internet no matter how often the IP address of your fixed line connection is changed.

• The router must be able to forward tcp port 1723 to the computer with the VPN server and handle incoming PPTP sessions. Most DSL/cable routers are capable of that these days.

And that's pretty much it to secure your access. Have fun experimenting if you try!

After I have dealt with the most essential IPv6 features for me in parts 1 to 3 (see here, here and here) this part focuses on the bits and pieces that have to fall in place in 3GPP GSM, UMTS and LTE networks to make it work.

First of all, mobile devices need to support IPv6. Some already do, such as Nokia devices running on Symbian/S60.In fact, Nokia supports IPv6 already since 2003 as shown in this IPv6 presentation from way back then…

Next, mobile devices need to be able to get an IPv6 address when they connect to the network. In GSM and UMTS, the PDP context activation request message contains the necessary parameters to request one. In LTE the default/dedicated bearer activation procedures provide similar capabilities. Dual stack devices can ask for an IPv4 and IPv6 address in one request. In addition, IPv6 requires a Router Solictiation message being sent from the UE and a Router Advertisement answer from the GGSN to finalize the IPv6 address creation. This is done over the established user data bearer. More details can be found below.

While in theory, user data is sent transparently back and forth between the mobile device and the gateway to the Internet (the GGSN or the PDN-GW), the base station should perform IP header compression (RoHC). In practice this will become even more important due to the significantly increased size of the IP header due to the 128 bit long IPv6 addresses, especially for voice calls.

At the gateway to the Internet, the GGSN (GSM/UMTS) or the PDN-GW (LTE) must be able to assign IPv6 addresses and provide firewall functionalities for IPv6 based communication. Further, the Home Subscriber Server (HSS) must be updated to support IPv6 parameters on a per user basis. And last, but by far not  least, are the IP Multimedia Subsystem (IMS) network nodes that have to handle IPv6 on the network layer but also inside SIP messages.

All of this has been in the standards for years so there's a fair chance we'll see it in the network sooner or later. Here's a couple of links for further information:

• 3GPP TS 23.221 Rel 8, 'Architectural Requirements', Chapter 5.6 on IP addressing says that the mobile is free to change the host part of the IPv6 address at any time on it's own without updating the PS domain via a mechanism described in RFC 3041.

• 3GPP TS 23.060 describes the PDP context activation procedure for IPv6 in Chapter 9.2.1.1 in Figure 6.1 After the context is active, the UE sends a router solicitation message to the network (the GGSN) which then returns a Router Advertisement message. The information contain in this message is then used by the mobile to construct it's own IPv6 address.

Since I'm not an IPv6 guru, here's a question to all 3GPP IPv6 enthusiasts out there: Have I been missing an important point?

Yes, I like dynamic IP addresses and Network Address Translation because they help to protect my privacy. Google offers great online services, no doubt about it, but I am not willing to give up my privacy for them. Without some countermeasures though, it's difficult to keep Internet companies from collecting data without my consent even though I only use a single online service from Google. So here's a list of things I have put in place to stay as anonymous as possible when surfing the net:

• Whenever I connect to a 3G network I get a new IP address. Good, so I can't be followed via my IP address indefinitely.

• My DSL line is automatically interrupted and reconnected once a day and I get a new IP address each time. Same effect as above.

• I allow cookies in the browser but they are deleted as soon as I close the browser. To me that looks like a good compromise between functionality and privacy as my track runs cold as soon as I close the browser.

• For a few selected sites I've configured permanent cookies. Google is not among them…

• Adblock prevents Google Adsense to follow me around on the web via JavaScript plug-ins on pages.

• I deactivated Flash Cookies in the Macromedia configuration web page.

• On my mobile devices I use Opera Mini. There's a compressions server in the network that can follow me around and I assume they could follow my browing history. Not so nice from a privacy point of view, but at least it's not big G…

• As I use Google Reader on the mobile there's a cookie set by Google which probably allows them to track my searches as well. So I use Bing for searching on the mobile.

What do you think, am I missing something or could I do more? Any big loopholes?

3G is fast but it has a weakness in my eyes that is especially relevant for mobile web
browsing: When browsing to a page after having been idle for a long
time, the radio interface is in idle state and re-establishing a
bearer takes several seconds. In practice that means one has to wait
for the first page for quite some time. But there could be a simple
solution for this: Most of the time when I deactivate the keylock of
my mobile device I perform an online activity right afterwards such
as selecting the web browser and going to a new page. So instead of
waiting with the radio interface channel establishment until I select
the page, the phone could already establish the radio channel when I
unlock the phone. Agreed, if it does that and I do something else
after deactivating the keylock such as looking up something in my
device based calender, some energy and radio interface capacity is
wasted. But I'd be willing to make this compromise.