Author: Martin

Lately I had some issues with the Internet connectivity being a bit slow and while working the issue I discovered an unrelated but also interesting thing: When using Firefox and other applications on Ubuntu (10.04 in my case) the DNS resolver always queries for an IPv6 address for a domain name first (AAAA record). Only once a (negative) answer gets back to the system does the resolver ask for the IPv4 address (A record). This is strange for two reasons: First, I don't have any network interface on which IPv6 is enabled so even if the resolver returns an IPv6 address, the application couldn't do anything with it. And second, the vast majority of the servers I contact don't have an IPv6 address yet. So why slow me down that much by asking for an IPv6 address in the first place? Why not only ask for it if no IPv4 address is found? A bit of a mystery to me. But here's a simple fix for it in Firefox: Type in about:config in the address bar, search for network.dns.disableIPv6 and set it to true. That at least fixes things for Firefox and saves you a needless DNS query for each domain. Same kludge works for Thunderbird as well.

Back in 2009 I wrote a post on SMS Forwarding and that I'd really like to have this feature to reduce the number of devices I carry with me. I did find an application then that I still use but it runs on the phone that forwards the SMS and not in the network, so not an ideal solution for me.

The issue with SMS forwarding by the network is the way SMS works in cross network and roaming scenarios. Let's say you are subscriber of network A roaming abroad in network B. Now a person who subscribes to network C wants to send you an SMS. The SMS architecture as initially designed would forward the SMS directly from network C to network B, so you're home network operator (A) never sees the SMS and hence can't forward it.

But lately I've become aware of a solution called SMS Home Routing, described in 3GPP TR 23.840 and some further background is given on Wikipedia. Not specifically built for this very purpose it could nevertheless be used by network operators as a basis for offering enhanced SMS services such as SMS forwarding. Very interesting! The TR was written in 2007 so there has been some time now for developments and deployments. From the outside, it's pretty difficult to tell, however, if the solution has found traction in the market.

A cryptic title today but here’s the thought: When looking at the UMTS landscape today, most networks are still 3GPP Release 6, i.e. HSDPA somewhere around 7.2 MBit/s and HSUPA 2 MBit/s. Agreed, there are some early deployments of Release 7 HSPA+ 21 MBit/s HSDPA to be found but these are not yet the norm. In contrast, 3GPP currently works on 3GPP Release 10 and some are already thinking ahead to Release 11. In other words, there’s a gap of 4 release cycles between theory and practice. In number of years, current networks trail the specification by around 5 years as according to the 3GPP website, work on Release 6 was complete in March 2005. So think about that when you hear or read something about features that have been specified lately.

SMS is a pretty resilient service as messages are first stored on a server and then delivery is attempted. When the mobile is switched-off when an SMS is to be delivered, the network is aware of the fact and the message is stored right away. But what about mobiles leaving the coverage area for a while? If they later-on “re-surface” again in the same location area and the periodic location update timer has not yet expired, no communication takes place with the network. So how long does it take in this case before a stored SMS is delivered?

The only way the SMS can be delivered in a timely fashion in such scenarios is that the network periodically retries to deliver the SMS. The periodicity is not standardized so it depends on the network operator how quickly another delivery attempt is made. In the network I used for testing, the retry period must be in the order of around 2-3 minutes when the mobile only leaves the coverage area for a few of minutes. Specifically, I tested “out of coverage times” from 5-12 minutes.

At some point the periodicity is increased. When I put the mobile out of coverage for around 50 minutes, it took about 10 minutes after regaining coverage before the SMS was delivered. Still, a pretty good value in my opinion.

This post is a quick follow up to a previous post on LTE smartphones at CES. In the post I came to the conclusion that unlike for CDMA operators, it doesn’t make a lot of sense for GSM/UMTS operators to go for LTE smartphones until they have a solid voice over LTE implementation. By solid, I mean good quality, a fast call setup time, proper integration into the UI of the smartphone and handover to GSM/UMTS when running out of LTE coverage.

There are several solutions such as CS fallback, which I think won’t be acceptable due to the increase in call setup time, IMS VoLTE which requires a complex core network addition and is nowhere on the horizon and of course Voice over LTE via GAN, or VoLGA for short. VoLGA is based on the 3GPP Generic Access Network (GAN) extension that replaces the GSM or UMTS radio network with IP over Wi-Fi. The solution has been deployed by a number of network operators for several years now and although it hasn’t found much traction it could be the very key to LTE on smartphones in the 3GPP world.

With recent announcements of GAN now being available on Android phones and some network operators shipping and upgrading such phones, that’s the best starting point you could possibly wish for as a GSM/UMTS operator planning to go for LTE.

Think about it, let a smartphone maker put an LTE chip into a GSM/UMTS smartphone in a similar way as is now happening for CDMA smartphones. However, instead of having two radios active at the same time, put the Android GAN Client on the device that uses Wi-Fi or LTE as an IP network to connect back to the operator’s core network to offer voice, SMS, etc.

That way, with next to no effort at all, GSM/UMTS network operators using GAN today and thus already having a GAN gateway in place will be able to offer LTE smartphones with proper voice service once they launch LTE. A bit of extra effort is required to make the handover to GSM/UMTS of an ongoing voice call. But really, that’s a piece of cake compared to making other solutions work. So who are those network operators being Voice over LTE ready, whether they have already considered it or not? According to smart-wi-fi.com that’s Orange France, T-Mobile US, Rogers, Cincinnati Bell, TeliaSonera and Orange UK.

The list is not very long but that doesn’t matter a lot. Practically all GSM/UMTS network operators that are not on the list can quickly get smartphones with LTE and voice service as well and hit the ground running. What they need in addition is a GAN / VANC controller in the core network and the experience to run GAN / VoLGA. But those network operators mentioned above are proof that it’s working.

Here’s a thought concerning mobile power consumption in UMTS networks: In the uplink transmission direction, the power required to send data to the network depends on the amount of noise present in the channel. The more noise, i.e. the more other users are transmitting data to the cell at the same time, the higher the required power to send your data. That means that if there is a lot of activity from other people in the neighborhood, your own battery consumption increases when you transfer data yourself.  That doesn’t necessarily mean this has a significant impact on autonomy time but it should be measurable. Also, it should be taken into account that other factors have a similar or even bigger impact on uplink power requirements, e.g. if coverage is weak at the location where a mobile device is most of the time. But the idea remains: It’s not only you that decides how much power your device uses for communicating with the network.

At the recent CES a number of companies seem to have shown the first CDMA/LTE smartphones to be launched at some point later in the year. From a telecoms point of view the interesting thing is how these phones will do voice calls while connected to an LTE network. The issue here is that LTE doesn’t have a built in voice service like GSM and UMTS. While most of the press mostly commented around the design, screen size, processor and other features, this topic was completely overlooked.

Steve, over at the Voice over LTE blog, however, comes up with some interesting answers on how voice service is implemented. According to his post, these LTE phones will be connected to LTE and the CDMA network simultaneously so IP based traffic can use the LTE network while voice calls and text messages can be handled simultaneously by the CDMA network.

From a 3GPP GSM/UMTS engineer’s point of view this is, well, lets say, outmost sub-optimal. In the world of GSM and UMTS a lot of care is taken that voice calls and data sessions can move seamlessly between the two technologies. Ongoing calls will be handed over between the technologies when running out of UMTS coverage, for example, and the IP address and session contexts will also be preserved when hopping between the two radio networks. Voice and IP services even run concurrently, something that doesn’t work in the CDMA world at all. For LTE, the same mechanisms have been standardized for IP sessions and a number of different solutions exist to hand over ongoing LTE voice calls to GSM and UMTS.

So why are those phones not using these solutions? For one thing, they are designed for CDMA 2.5 / 3G network operators and from what I can tell they can’t use CS fallback, because that’s specified for fallback to GSM and UMTS only (please correct me if I’m wrong here). Also, Voice over LTE via GAN (VOLGA) is not an option for them as it is based on GSM and UMTS technology. That leaves them with VoLTE, which is an IMS solution with a specified feature set. Talked about in the industry for pretty much a decade it’s still nowhere to be seen and the announcement of dual-active-radio phones for LTE indicates that showtime for that technology won’t be anytime soon. Hence, their move to dual-active-radio phones.

Apart from the opinion of a 3GPP engineer, is a dual-active-radio device a solution that the customer could like? After all, the customer isn’t interested in sleek designs under the hood, but whether the device works well or not. So from my point of view, I as a customer want my smartphone to do two major things: It has to provide me with a highly reliable voice service anytime, anywhere and it has to provide me with a fast and reliable Internet connectivity for my IP based applications such as email, web browsing, Twitter, etc. etc.

So the question is, will those dual-active-radio phones provide that? From what I can tell the answer is yes, with some restrictions. The first one is the potentially higher power requirements to keep two radios listening to two networks at the same time. However, if I get a full day of use out of the device then I, as a user, don’t care to how many networks the device is connected to simultaneously. If those devices can do that is something yet to be seen. Secondly, voice service. Yes, the CDMA network layer provides that and as the radio is turned on all the time, my voice service in terms of availability and call setup time should be in the same ballpark as current 2G/3G phones. Furthermore, I wonder if the first generation of the CDMA/LTE networks and the devices themselves can switch the IP context  between the different networks. If not, then applications will loose their connection to the network every time a switch between LTE and CDMA is done for data services.

Loosing the IP context between CDMA and LTE might come in as a big argument against such a solution. But is it really an issue? Today, most smartphones can use both 3G and Wi-Fi for internet connectivity and automatically switch between the two radio technologies. Here, IP connectivity is also lost and applications have to re-connect to their server on the Internet each time the switch it made. Not very pretty from a design point of view but it seems to work in practice already today without anyone loudly complaining.

Oh, yes, and before I receive some comments on the Skype implementation on the phones that was reported, yes, I’ve seen that, too and I very much like it as an added goodie. However, I’d never rely on it as my main telephony service for a number of reasons. The most important one is that I often make calls while moving and often implicitly use, what I  think is the network operators biggest asset, the capability to hand over ongoing calls from 3G to 2G.

I find the thought around Wi-Fi very interesting. In effect, if the IP context can’t be taken over from LTE to CDMA, then the LTE network can be seen to do the same thing Wi-Fi already does today in 3G phones. So instead of having only a Wi-Fi chip, LTE smartphones have an LTE chip in addition that can also provide IP connectivity. And that, I think, is a crucial point in the discussion and way of thinking of whether it’s a good idea to have dual-active-radio LTE phones, which in fact will be triple-active-radio phones, as Wi-Fi is switched on all the time as well.

So the final train of thought for this post is whether this approach could and should work in the GSM and UMTS world as well!? Let’s first look at the “should”. From what I can tell, CDMA operators are keen on launching LTE because they depend on it as an upgrade path from their CDMA network technology that is not evolving anymore and is capable, from what I hear, to deliver around 1.5 MBit/s but not much more. Also, from a capacity point of view, it’s much more limited to what’s currently going on in UTMS networks. On the UMTS front, there’s a healthy evolution program in place. Many networks are already upgraded for speeds up to 7.2 or 14.4 MBit/s in the downlink, with 21 MBit/s in the downlink and dual-carrier 42 MBit/s on the way to reality. Also, network capacity keeps rising with more advanced devices coming to the market all the time that make better use of the resources, use of several carriers and densification of the network, all while preserving backwards compatibility with GSM and concurrent voice and IP based operation. So why go for the compromises of a GSM/UTMS/LTE phone that has to have two radios switched on at the same time? You can have it all on the evolution of UMTS for smartphones, while LTE is being used for non-voice devices such as netbooks, LTE USB sticks, pad computers, etc. For me, a GSM/UMTS/LTE phone only makes sense once voice over LTE works as good as voice over GSM/UMTS, including, and that’s most important, handover to GSM and UMTS. As an operator, anything less doesn’t cut it, Skype and others are here today. Whether an operator bets on IMS VoLTE or VOLGA, or a combination of both will be sorted out by competition.

And finally for today the “could” part. Running GSM/UMTS and LTE separately at the same time is going to be a bit of an engineering challenge. As per design, a single SIM card can only supply the credentials to be active in one radio network at the same time. So to be active in GSM and LTE at the same time would require two IMSIs (International Mobile Subscriber Identities). You can’t do that with standard SIM cards today. Of course one could think about solutions such as one SIM card having two IMSIs and two secret keys but why work on this when the real issue is to have Voice on LTE with seamless interworking with GSM and UMTS?

In summary, I think the answer for CDMA networks is to have dual-active-radio CDMA / LTE phones until they’ve got the voice question solved as they don’t have many other alternatives to evolve their networks and live with the downsides for the moment. For UMTS network operators, I think the equation is different as the strong evolution path of UMTS and using LTE for non-voice centric devices makes dual-active-radio designs not very attractive.

For those who travel the world a lot and don't have endlessly deep pockets, finding ways to economize spending for international calls and getting Internet access on the move is essential. Over the years I learnt a lot of tricks and at some point started the Prepaid Wireless Internet Wiki to share my information on getting local SIM cards for Internet access. The site has been quite successful and in the meantime many people contribute. 

But local SIM cards are only one piece of the puzzle. There are lots of other things one can do besides and on top of this but I never had the courage to write all that stuff down. Now Andrew Grill over at London Calling has done it and it's a great guide in 2 parts (here and here) on how to save on communication costs when traveling. Very well done, I don't have much to ad to it, except perhaps rebtel.com which I use frequently to make International calls from my mobile phone while in my home country.

O.k., the winter chaos in Europe has gotten to me as well and I was stuck in various places waiting for planes and trains like many others. So while the situation was far from comfortable I noticed that being connected and being able to get information from online sources not only proved to be entertaining and useful, as I could get some work done while waiting but also helped to keep my mood up. Here are some things I noticed:

Congestion: In airport lounges, free Wi-Fi is sometimes provided, but it is usually quite congested and slow due to many people using it at once. Good when one has a 3G dongle and can make oneself independent from the rest.

Flight Status: Flight status reports are not accurate at all, neither online nor at the airport. It's interesting to observe that a flight status on airport information displays and also online is marked as "on schedule" until just one hour before departure when it then suddenly changes to indicate a two hour delay. I wonder why this is done that way as airlines do know better!?

In my case for example, the plane that would take me to Frankfurt was coming from Frankfurt in the first place. Online, the delay for that plane was visible while for the outgoing leg the flight status remained "on schedule". Most people have better things to do than to spend time at the airport when a delay of several hours that is clearly predictable would allow them to do something else in the city. So perhaps the airlines want you at the airport so they can judge who shows up for a flight and who doesn't!? In the age of email, twitter, instant messengers and other methods to stay connected, even automatically, it's an archaic way of organization.

Abnormal situations also reveal how flight status displays at airports are working. The system used at Istanbul airport, for example, is not updated in real-time at all. For my flight, which was 3 hours late, somebody forgot to update the system so at the "theoretically correct time" the display showed "boarding" and then "final call". Very nice, except there was no plane at the gate to board and no ground personnel to inform people of what was going on. Quite a confusion. Once the theoretical time for "final call" was over the display went blank, still no plane and still no ground crew at the gate. You can imagine the confusion. Unless, of course, the online information on your mobile device from your airline tells you the real story.

Getting a Hotel at Midnight: And the best use of mobile Internet connectivity is when you are stuck at the airport, figure out from the online schedule of the train company that the last train home has just left despite a massive delay and you start wondering how and where you'll spend the night. Hundreds of people are around you with the same problem and the picture of camp beds in a big hall springs to mind. But your online hotel reservation system tells you that there are many hotel rooms close to the airport still available. It could be just as fake as the online schedule displays but a call to one of the hotels quickly revealed that rooms were indeed still available. Interestingly enough, the hotels shown did not take advantage of the situation but offered the standard rates per room. Much better than spending the night at the airport.

Stay in bed longer: And finally, the next morning your mobile is your best friend when it tells you that the train you want to take home is either on time or delayed, so you know it's worth getting out of bed or if there is no real rush to get up.

Entertainment and connectivity: And all the while it also plays your favourite music, keeps you informed about what's going on in the rest of the world and you can call people back home and wished your travels were as quick and easy as that of those electrons and waves that carry your voice through the maze we call a telecommunication network.

Are you already back from vacation? If so, you might want to have a look at the program of the Mobilware 2011 conference being held in London this year from the 22nd to the 24th of June. As you'll see in the scope and topics overview below it's about advances in communication middleware, mobile operating systems, networking protocols and applications. So just my thing 🙂

The call for paper ends February the 1st, so if you have an interesting paper to propose, you have a couple of weeks from now to send your proposal. It would be great to see you there!

Conference Scope

The advances in wireless communication technologies and the proliferation of mobile devices have enabled the realization of intelligent environments for people to communicate with each other, interact with information-processing devices, and receive a wide range of mobile wireless services through various types of networks and systems everywhere, anytime. A key enabler of these pervasive and ubiquitous connectivity environments is the advancement of software technology in various communication sectors, ranging from communication middleware and operating systems to networking protocols and applications.

Topics

The conference solicits original technical papers, not previously published and not currently under review for publication elsewhere. Topics of interest include but are not limited to:

• New middleware concepts for mobile devices
• Cross platform application development
• Open terminal and network APIs
• End-to-end architectures for seamless service provisioning and deployment
• Integration of heterogeneous wired and wireless networks and frequency bands
• Interworking of mobile applications in mobile cloud environments
• QoS awareness, adaptation, and fault-tolerance of mobile services
• Opportunistic and delay-tolerant mobile and wireless networking
• Location-aware and context-aware networking and computing
• Energy-efficient applications and services and OS air interface management
• Mobility and handoff management
• Location and tracking supports and services
• Human-computer interface and portable 3D graphics for mobile devices
• Novel applications and communication protocols for wireless sensor networks, vehicular networks, and home networks
• Modeling, simulation, and performance evaluation of mobile wireless systems and services
• Trustworthiness, security, and privacy of mobile and wireless systems