Category: Uncategorized

Another week, another Carnival! This week, the Carnival of the Mobilists is hosted by AllAboutIphone.net by Matt Radford. As always, a great compilation of what happened in the mobile blog sphere in the previous 7 days. So don't wait, head over and enjoy!

Do you know Ajit Jaokar and Michael Mace? If not I suggest to head over and check out their blogs (here and here) for great insight into the mobile domain. Or, even better, use the opportunity to meet them in person on the 8th of September at the University of Berkeley, California at the Mobile Web Megatrends Conference on September 8th, 2008. Topics of the conference range from mobile browser evolution, browser offline capabilites, advertising models, the iPhone (of course…), mass market impact with Nokia's S40 6th edition, cloud computing, etc. etc.

Lots of other great speakers, I let the conference's web site speak for itself.

Definitely a conference not to miss if you can make it. Unfortunately my calender is already booked for that date so I won't be able to make it. But good for you since I have one free ticket to give away! First come first served.

In the fixed line world, the basic Session Initiation Protocol (SIP) has become quite popular for offering voice telephony service. Lots of companies such as Vonage, Siptel and DSL providers are making use of it today. So why are we not using SIP in 3.5G and 4G networks as well? I guess there are both policital and technical answers to this question. From a technical point of view there are a few features missing that are essential in wireless networks:

– Voice codecs: Current SIP implementations usually use G.711 voice encoding which produces a 64 kbit/s data stream. Transported over IP the total bandwith requirement per direction is 80 kbit/s. Compared to the effient codecs used in wireless networks today such as 12.2 kbit/s AMR with a similar voice quality this is quite a lot and significantly reduces the number of simultaneous voice calls per cell. The current voice architecture uses a transcoder between the radio network and the core network to restore G.711 compatability. So from a capacity point of view, using G.711 in the radio network is probably not a good idea and would meet the resentment of most operators. So from my point of view we need AMR capable mobile SIP clients and transcoders in the network to reach non AMR capabale (fixed) SIP clients and circuit switched networks. Note that such transcoders are already present in the SIP networks today, usually as media gateways between the SIP world and the classic circuit switched world to which most people are still connected to with their fixed line and mobile phones.

– We need to get rid of NAT and STUN: Most mobile operators use private IP addresses for their customers. This requires Network Address Translation (NAT) which in turn unfortunately requires frequent polling packets to the SIP and STUN (Simple Traversal of UDP through NAT) server. These packets keep the connection to the network open continuously but drain the battery of a mobile device very quickly. The solution to this issue is to use public IP addresses and to ensure that keep alive messages are removed from the SIP implementation as much as possible. With the lack of sufficient public IPv4 addresses this will require IPv6 at some point.

– End to End – Encryption: All SIP clients I use today do not encrypt signalling or the voice call itself. With freely available tools such as Wireshark, calls can easily be traced and recorded. While circuit switched networks are reasonably secured it is difficult to ensure there are no unwanted listeners in the route in public IP networks.

– The missing link: Handover to 2G circuit switched connections when running out of coverage. This one is very difficult to do. Sure there is VCC (Voice Call Countinuity) for IMS but the complexity both in the network and the mobile device is significant. I have to admit I have no easy solution for that.

Are there other essential SIP extensions that you, fellow readers, can think of to enable SIP for mobile networks without going to a full blown IMS implementation?

Good news on the Wi-Fi front: Linksys has launched the WRT610N access point, which simultaneously operates in the 2.4 GHz band for current 802.11b/g devices and in the 5 GHz band for new 802.11n devices that support the so far little used frequency band. Should make the transition to the new frequency band much easier, especially if more vendors do the same in the future and integrate it with DSL modems!

From a technical point of view it's interesting to note that the data sheet says each band has it's own set of three antennas (I guess to support MIMO).

In a report I read today I learnt that WIPI (Wireless Internet Platform for Interoperability), a mobile device runtime environment for applications similar to BREW and JAVA, is mandated by the Korean government to be included on any mobile phone sold in Korea that allows Internet access.

An interesting way to prevent companies such as Nokia, SE, Apple and others to sell their devices in Korea. In the past there were only CDMA based 3G networks available in Korea so this technology dispute was mainly between Korea and the US (hello Qualcomm…). As some Korean operators have now transitioned from CDMA to UMTS the issue now gains a more global dimension.

While these UMTS networks now theoretically enable Nokia, Sony Ericsson, Apple and others to sell their devices in Korea, the WIPI ruling prevents that from happening. But it looks like some operators have become rather unhappy and are asking for lifting the WIPI ruling. Lots of questions poping up here:

• I wonder if there is a black market in Korea for such phones today?
• Not sure if such phones would even be desired at the moment due to the probably missing Korean language integration and also due to the sophistication of LG/Samsung phones.
• Also, I wonder how widely WIPI is used at the moment, is it seen as an integral part by a large user base?
• In case the application environment is very popular I wonder if lifting the WIPI ruling would have an immediate effect if people would not buy devices without it.

Fellow readers in Korea, what do you think?

Recently a friend made me aware that companies should have a BHAG, a Big Hairy Audacious Goal to be successful and to motivate employees! I found this a rather intriguing way of looking at things and this article on Wikipedia gives some details and also some good examples of BHAGs.

BHAGs in the wireless domain I can see today are for example:

• David Wood’s vision of Symbian to become the most widely used operating system in the world.
• Nokia’s mission to become an Internet company.

What about your company? Do you have a BHAG?

Here’s a quick post to point you to the 134th edition of the Carnival of the Mobilists, this week presented over at Mopocket by Justin Oberman. I had a quick look and it seems to be a super big edition this week. Looking forward to read it on my mobile phone while on the way to London with the Eurostar in a couple of hours. So head over and enjoy!

A recent report I read about the future rivalery between HSPA and LTE has made me think about an important difference between the two technologies: Voice. While UMTS / HSPA intrinsically supports voice calls in the radio and core network, LTE requires the IP Multimedia Subsystem (IMS) for voice calls. So what will happen to LTE if IMS doesn’t take off? I know, many in the industry believe even asking such a question is close to heresy but who can promisse today that IMS will be a success?

The trouble with IMS and to some extent with mobile VoIP is not that it’s a young technology, standardization has been going on for many years and books about it are going into their third edition. However, there are still no IMS systems out there today that have come out of the trial phase, and I have yet to see a mobile device with an IMS client which is nicely integrated and simply works. Also, the IMS standard is getting more complicated by the day which doesn’t make life easier. Another main issue with VoIP and consequently IMS is power consumption. I use VoIP over Wifi a lot on my Nokia N95 and can nicely observe how the phone slightly heats up during a long phone call. Also the non-IMS but SIP compliant Nokia VoIP client in the phone, which by the way is nicely integrated, sends keep alive messages to the SIP server in the network several times a minute. This is necessary mainly due to Network Address Translation (NAT). While this doesn’t require a lot of power over Wifi, power consumption skyrockets as soon as I configure VoIP for use over 3G. I can almost watch the power level of the battery drop as the network now constantly keeps a communication channel open to the device. So there are two problems here: VoIP calls cause a much higher processor load during a call, i.e. the VoIP talk time is much shorter than the 2G or 3G talk time and the standby time is significantly reduced. Add to that the missing handover capability to 2G and 3G networks (yes, I know there is VCC in theory) and you have a prefect package for a very bad user experience.

So the big question is if all of these things can be fixed, say over the next 5 years!? I have my doubts…

If not, then LTE has a big problem. Will network operators accept running GSM or HSPA alongside LTE until the problems are fixed? The choice is this and accepting that LTE is for Internet access and some niche VoIP applications on devices such as notebooks or to decide sticking to HSPA(+) until things are fixed.

In case LTE is deployed and LTE – IMS devices are not ready it’s likely that a device can’t be attached to several radio networks simultaneously. So how do you inform a device attached to LTE about an incoming voice call? It looks like the people in standards bodies are looking at different solutions:

– Send a paging message for an incoming circuit switched voice call via LTE to the device. You can do this on the IP layer or on the radio network signalling layer. The device them switches radio technologies and accepts the call.

– Some people have started thinking about extending LTE with a circuit switching emulation. This could be handled on the lower layers of the protocol stack and the software on top would not notice if the call uses GSM, UMTS or LTE. This one is easier said than done because I don’t think this concept will fly without a seamless handover to a 2G or 3G network. If such a solution ever gets into mobile phones, it would make life for IMS even harder. Who would need it then?

Are there any other initiatives I have missed so far to fix the LTE voice issue?

This week I am probably the fastest Carnival of the Mobilists reader, as I was traveling  at 300+ km/h with the high speed train from Avignon to Paris while reading the posts on my Nokia N95 with OperaMini. The carnival this week is about as fast paced as was that train, so make sure to check it out at the Vision Mobile Blog. There’s definitely no better place to find out what happend in the mobile space in the previous seven days. Enjoy!

I’ve observed my network usage over the past couple of days to see how much data I would transmit and receive over the course of a week while traveling. I’ve noted that there is a big difference between PC and mobile device use in terms of uplink/downlink ratio. With the PC, which I mostly use to access my eMail and for web based services, the ratio is about 10:1. The ratio on my N95, however, is close to 1:1 as I upload pictures, blog posts and eMails. Especially picture uploading with Shozu has a major impact on the ratio.

Other statistics say that 90% of the data traffic in mobile networks is from PC’s and I think that also reflects my behavior. As a consequence, the uplink traffic generated by mobile devices is still an order of a magnitude smaller compared to overall downlink data traffic.

With faster uplink speeds becoming available the ratio could change once it becomes feasible to upload high quality video material from mobile devices in a reasonable time. That’s about the only application I can imagine that could have a real impact on uplink use. Until then, however, the uplink will remain rather unused.