Symbian vs. Memo? – Some Thoughts

This week, the Financial Times Deutschland ran an article that Nokia is about to "change its strategy" ("Strategiewende") concerning their use of smartphone operating systems, that "they are loosing faith" in Symbian ("verliert Vertrauen") and are about to "abolish" ("verwerfen") Symbian in favor of Maemo.

Tough words which are immediately followed by the statement that in the future, Nokia will equip "many" of its new phones with Maemo. To me that doesn't quite sound like abolishment or loosing faith but more like continuing the path of working on more than one operating system.

The article only cites internal sources so it's difficult to verify the claim or the spin of the article. Other news websites have picked up the story (e.g. here, here and here) but I don't quite believe it yet.

Here's how I see things:

Something is going on behind the scenes at Nokia concerning their smartphones and I am not quite sure what it is. The innovation in the smartphone sector Nokia has so long driven with their Nseries range has notably slowed down. I have my Nokia N95 for almost 18 months now, and I am still waiting for a successor. Neither an iPhone nor the N97, that has just started shipping recently, are what I'm looking for. From that point of view, the speculation is understandable.

But the latest Maemo device, the N810, was released in the same timeframe as the N95, back in 2007. So Nokia has definitely not really pushed that OS with new hardware either. There are rumors of a new Maemo device to be released shortly, but I don't think that this is a change of strategy or loosing faith in Symbian.

The FTD article says Symbian is old, has 20 million lines of code by now and is difficult to extend. I would hold against it that Maemo, which is based on Linux, has probably similar complexity and Linux itself is not much younger either. But it's open source and well known by programmers which are two formidable advantages over Symbian. Symbian is going open source, too. How much that will draw programmers to it, however, still remains to be seen.

An advantage of Symbian over Maemo is it's integration of 2G and 3G network stacks, something Maemo does't have for any hardware with which it was released so far. On the other hand that seems to be something that can be overcome, as shown by Google's Android, which is based on Linux as well. 

Also, a change from Symbian to Maemo would not solve Nokia's challenges concerning platform popularity and an encompassing ecosystem such as a popular web store, synchronization to web services or to a PC, etc. These aspects have nothing to do with the operating system running on the mobile device itself.

The article further says that Nokia is loosing smartphone market share. After many years with little competition, I'd say this is not really surprising with strong competition coming from several directions now such as RIM, Apple and Google. That's not something that could be fixed by changing to another operating system.

But market share is not everything. I'd rather have a smaller market share of a big market than a big market share of a small market. I don't have the numbers here, so maybe someone can help me out with this, but I think there's a fair chance that with all the attention of companies with good products other than Nokia on the smartphone sector, the number of smartphones sold are probably increasing.

So without further facts I can't quite go along with the message of the FTD article that Symbian is going to be ditched. What do you think?

Vodafone and Petabytes

Another interesting number popped up on the Internet recently. Here, Teltarif quotes Georg Benzer, Chief Network Officer for Vodafone/Arcor in Germany, saying that Vodafone/Arcor (I assume he means both their DSL and mobile network Germany) transport 1.5 petabyte a day. No more details were given and there is only one more source on the net reporting the same number. But nevertheless, let's play around with this number a bit.

The 3UK CTO recently reported that at the end of 2008, they transferred around 1.000 terabytes (=1 petabyte) a month through their wireless network in the UK. Let's say most of that traffic was generated by 3G dongles. The exact 3G dongle subscriber number of 3UK is not known, I estimate it at around half a million at the end of 2008. That means every subscriber consumed about 1.000 terabytes / 500.000 subscribers = 2 GB of data a month.

Now lets say the 1.5 petabyte a day or 45 petabyte a month in the Arcor/Vodafone network were consumed by both fixed and mobile subscribers. Let's say Vodafone Germany has 2 million 3G dongle users (just an assumption, approximated from the 3UK number, no source for this) then out of the 45 petabyte, 4 petabyte would come from mobile subscribers. That means 41 petabytes are used by fixed DSL subscribers.

The number of fixed DSL subscribers of Vodafone/Arcor Germany is reported to be around 3 million. That makes 41 petabytes / 3 million subscribers = 13.6 gigabytes per subscriber per month on average. Note that both the 2GB above and the 13.6 GB are average values and there's no telling from those numbers how many users are at both ends of that figure (i.e. how many use much less and how many use much more).

Many of Arcor/Vodafone's DSL subscribers also use their DSL line for
VoIP (with a POTS to VoIP converter at home). That traffic should not
be counted either as it doesn't leave the network, at least not as IP packets. Let's say the average subscribers uses the fixed line phone
for 5 hours a month. VoIP produces 2*80 kbit/s (uplink + downlink) = 160 kbit/s of data
traffic = 72 MB per hour or 360 MB for 5 hours. Not very much compared to the 13.6 GB per month which are just reduced down to 13.3 GB per month.

A raw comparison of the two numbers would indicate that DSL subscribers are transferring 7 times more data through their connection than wireless subscribers. But I think that is a bit too simple a view. Most wireless subscribers are likely to also have a DSL line at home and fixed and mobile use might be different. Further, DSL lines at home are often shared with family members and several devices while a 3G dongle is mostly used by a single person with only one device at a time. Also, since most wireless offers have bandwidth caps, heavy users are much more likely to use a DSL line rather than a wireless modem, thus further distorting the direct comparison.

So despite the two numbers not being directly comparable they nevertheless give an interesting indication that mobile use is is not that far away from fixed line use.

Nokia Energy Profiler V1.2 now with 3G State Analysis Mode

A while back I reported on the Nokia Energy Profiler, a very useful utility from Nokia for S60 phones to measure power consumption. From the power consumption one can then deduct in which radio state the mobile is and how long it is kept there by the network during inactivity before a more power conserving state is selected. For details, see here. Now, Nokia has released V1.2 of the utility, which has a dedicated screen for showing the 3G radio states.

It's a bit hidden, though. First, it has to be activated in the preferences. Second, during recording only 0,1, 4 or 8 "CH" are shown. Not sure what "CH" means. Anyone? Anyway, 0 and 1 represents the Idle state, 4 the Cell-FACH state and 8 the Cell-DCH state (in HSDPA mode). The states are shown by stopping the recording and then using the 4-way navigation key to scroll back. In this mode, the application shows how long the mobile was in each state while you scroll back to the left.

I've tested the application in the T-Mobile network in Germany and the Orange network in France. T-Mobile keeps the connection in Cell-DCH state for around 20-25 seconds, including the (Opera Mini) page download time, which is around 2-3 seconds. The Cell-FACH state is keept quite long, somewhere between 1.5 and 2 minutes, before the connection is put into Idle state. In the Orange network, Cell-DCH state is kept for 10-15 seconds, and Cell-FACH state for around 30 seconds. A bit better for battery consumption one might argue, but T-Mobile's settings are better for the browsing experience if one remains on a page for more than 30 seconds.

Wi-Fi Sharing – The French Way

There is an interesting development in France concerning Wi-Fi sharing that I haven't seen anywhere else so far:

Fixed line network operators are now offering to their customers to share their DSL Internet connection over Wi-Fi with others in a number of ways:

  • FON is officially endorsed by SFR. They have upgraded the software of their customer based and operator managed DSL/Wi-Fi routers for the purpose.
  • SFR and Free now allow subscriber the use of DSL/Wi-Fi routers of other subscribers unless a customer specifically disables it.

While it is nice to be able to use someone else's Wi-Fi while being out and about there are two issues which are not addressed by this:

  • I am aware of FON for a number of years now but I have never seen one when I needed access. The number of FON hotspots might be impressive, but the range of the Wi-Fi signal is just too limited.
  • I imagine the same applies to the Wi-Fi sharing for French subscribers. As there is no way to ensure that one will find a suitable hotspot one can use for free the usability in practice is quite limited.

On the other hand, many locals might prefer such a kind of nomadity over 3G at the moment, as prices for 3G Internet access are still very high compared to other countries in Europe. With a bit of luck, though, that won't last forever. And once we have a situation like in Austria and other countries, where 50 euros buy you an unlocked 3G USB stick and a reasonable amount of data, I can't imagine that many people will go through the hassle of looking out for a suitable Wi-fi hotspot when it's much easier to just get connected over 3G.

This shows a bit of a dilemma with a future off-loading 3G traffic to Wi-Fi hotspots which might be a good thing in case we get a situation where cellular networks become too crowded: Today, users need to figure out themselves if there is a Wi-Fi hotspot close by and then use it instead of 3G. No way the majority will do that unless there is a severe price pressure or the 3G network is so loaded that the speed is not acceptable anymore.

So what is needed to make this work is an automatic means for a device to automatically use the network operator supplied Wi-Fi when found and to change back to 3G, seamlessly of course, when the user moves on. Not an easy task. In that regard, Femtos might be a better solution as they give extra capacity with a similar range without the hassle of installing software for network switching on mobile devices.

So in the end I think it's likely that we'll see a triumvirate with Wi-Fi and Femtos at home, Femtos in public hotspots, Wi-Fi in public hotspots for locals and travelers without a 3G subscription and 3G cellular for the general coverage.

Push and Pull, Keep-Alive and Wastefulness

O.k., here are some follow-up thoughts after my previous post on background applications that generate keep-alive IP packets which have a negative effect on radio interface efficiency. The “efficiency” issue here is that the ratio between the amount of data transferred and air interface radio signaling is very unfavorable for small bursts of data, especially in cellular broadband networks such as UMTS. So Dan asks in a comment to the post why mobile e-mail (push or pull) could be counted in the “wasteful” category. All right, here we go, this is my take on it:

There are two kinds of mobile e-mail delivery:

The first is push e-mail to mobiles, such as on the Blackberry. Here the server is likely to only communicate with the mobile device when there is an e-mail to deliver. I haven't tested it personally yet so I don't make a definite statement here. But I assume even if some keep-alive messaging is necessary, for example in cases when no e-mails are delivered for some time, it should not be that much. Also, IMAP push which is supported by more and more phones these days should also not generate keep-alive messaging.

Second is pull e-mail, which I use for example as I don't like the IMAP (push) implementation of my e-mail program. My polling timer is set to 10 minutes, so my N95 checks for e-mail 6 times per hour. Definitely more wasteful than push if there are less than 6 e-mail per hour. In case you receive more e-mails per hour however, it can even be more efficient than push.

So is mobile e-mail wasting air interface resources? I guess that depends on the definition. If the definition is that an application is wasteful that only transfers little data per radio bearer setup, then I guess the answer is yes. But then, small screen web browsing, like for example with Opera Mini, would have to be categorized as quite wasteful, too. Many pages I view are compressed to less than 20 kB. Ouch, that hurts, as it's one of my favorite applications…

So my own definition of “wasteful” would be:

Exchange of IP packets for frequent keep-alive messaging that do not contain data.

That excludes e-mail push, Opera Mini use and, depending on configuration and number of emails per hour, e-mail pull.

That still leaves us with a lot of other applications, especially when connecting the PC to the cellular network, that keep babbling away and provoke lots of bearer reconfigurations. But as I said in the previous post on this topic: For battery driven devices, always-on applications are quite likely to be optimized over time to talk less to increase the battery lifetime.

A Netbook, eeeBuntu and Mobility – Part 3

I've had my new netbook for about a month now (see here and here) so it's time now for an update on how things turned out. I was a bit skeptical at first whether I would keep Ubuntu Linux on the machine or revert back to the original Windows XP. A month later, I am pretty much convinced that Ubuntu is the right thing for me on the machine.

One of the most important things for me with is the startup time of the operating system and the applications. In both categories, Ubuntu does extremely well. Booting the system takes just around 60 seconds. Going to suspend mode and waking up again just takes 6 seconds. That's almost instantaneous and helps a lot if you just want do something quickly, like looking something up on Wikipedia for example.

The applications I use most are Firefox, Thunderbird, Open Office, GIMP, Pidgin (for IM) and Skype. Even when compared to my full notebook with Windows XP, most of them launch much quicker. Sometimes I even catch myself thinking that the netbook is faster than the notebook…

Some things especially noteworthy I haven't mentioned so far:

  • No drivers are needed for 3G phones or USB sticks. Both my Nokia N95 phone and the Huawei E220 3G USB stick worked right away. Not quite perfect as reported in part two, but it's a huge plus not having to install third party software, which often does more harm than good.
  • HP went out of their way to produce Linux drivers for their multifunction printers. The package is called HPLib and makes using my printer / scanner / fax over Wi-Fi very easy. I even dare say the software is much quicker than the PC version, especially the scanning part. No waiting for the next dialog box, no long program startup times, the scanner just jumps into action when the scan button is pressed. Conversion to JPEG and PDF works out of the box, too, very nice!

But where there is light, there is shadow, too. Here are the things that required under the hood tweaking to get it working:

  • The fixed line Ethernet chip was not detected automatically so I had to install the driver manually. It's not very complicated but for the average user compiling a driver is not a straight forward thing.
  • There seems to be a WPA2 problem with the Wi-Fi driver as I get lots of packet retransmissions. I've tried with several access points but the result is always the same. When going back to WPA encryption, everything is fine. I've searched the forums but haven't found anyone reporting this. Under Windows XP, WPA2 is working fine so it seems to be a driver issue.
  • The built-in video camera made some problems. I got it working for a while but it stopped once I've experimented with the screen resolution of the external VGA port and a second monitor. It seems the graphics driver can't handle advanced functions with a higher screen resolution. Also, desktop effects like windows zooming in and out when they are minimized only worked with the lower resolution. Getting the effects back requires manual intervention in the xorg.conf file as described here.
  • Automatic suspend when closing the lid did not work at first. Even worse, the processor utilization went to 100% and the netbook kept running. The root cause seems to have been a BIOS issue. After upgrading the Bios of my Acer Aspire One D250 to V1.07, suspend when closing the lid now works.

So even though it required some tweaking I've got a fully functional Ubuntu netbook now and I am very happy with the performance.

LTE CS Fallback (CSFB) Issues Around SMS

While doing some research on CS Fallback (CSFB), the method currently favored by 3GPP to bring voice and SMS to LTE, I came across this discussion paper (SP-090429) initiated by Vodafone, China Mobile, Alcatel-Lucent, CATT, Huawei, Starent and ZTE. In the paper, the authors point to a number of issues with CSFB concerning SMS delivery and think about an LTE native implementation of SMS. According to the SA#44 meeting report, it looks like there was a heated discussion over it but no real agreement was reached on how to move forward.

A quick CSFB intro before moving forward: In its core, what CSFB does is to establish a signaling channel between a circuit switched MSC and the LTE core network. This way, mobiles currently attached to the packet switched LTE network can be informed about incoming circuit switched voice calls and SMS messages. In the case of voice calls, the mobile jumps back to 2G or 3G coverage and accepts the call. SMS messages can be directly delivered over the signaling link so no fallback is necessary. In that respect, CS fallback is not quite the right description for that part of the functionality.

The main issue with CSFB apart from having to fall back to a legacy technology for a core application is the increased call establishment time due to the fallback. It has been estimated that even in the best fallback case, this adds at least 1.5 seconds to the process. In many practical cases, it's likely to be longer. As call establishment times in mobile networks are already significantly longer than in fixed line networks, adding yet another source of delay is very undesirable.

In addition to this issue, the document lists a number of other issues, especially around SMS. Here are some examples:

  • Availability at launch: There is no guarantee that CSFB will be available at the launch of LTE as at least one circuit switched component, the Mobile Switching Center (MSC) has to be enhanced to support the new signaling interface (called SGs).
  • Roaming: It's not guaranteed that CSFB will be available in a foreign LTE network the mobile roams into when the user travels to another country.
  • Deferred Delivery: When an SMS can't be delivered immediately, like for example when the user has temporarily no coverage, an SMS waiting flag is set in the network. When the mobile is back in the network, the MSC is aware of the waiting message and delivers it. Unfortunately, this mechanism is not available with CSFB as the Mobility Management Entity (MME) in the LTE network does not inform the MSC that the mobile is back.
  • LBS: Location services based on SMS and Cell-ID interrogation are not possible with CSFB as LTE cell-id's can't be used in the circuit switched part of the network.
  • Resource Use: For SMS delivery the MME and the MSC are involved in addition to the SMSC. From a resource point of view, to many network nodes are used.
  • Specification Issues: It looks like there are some gaps in the current CSFB specification. One of them concerns SMS delivery during an ongoing fallback procedure due to an incoming call just before the SMS is delivered. Another, potentially even more significant issue, is concatenated SMS delivery, which is also still missing in the specification.
  • Test Scenarios: And finally, the current test plan for early LTE implementation does not include CSFB SMS test scenarios yet.

Quite a list of issues. While some can probably be fixed in short order, others are likely to be a bit more tricky. In combination with roaming and the EU mandate to inform users of roaming charges, hot-billing info, activation / deactivation of features and many other applications using SMS, it's clear that something has to be done to fix the issues. If native SMS over LTE is the solution, well, we'll see. Given the result of the discussions in the meeting report, this solution doesn't seem very likely to me.

Radio Signaling Load of Background IP Applications

Here's a link to an interesting post on Mobile Europe on the impact of IP applications running in the background on wireless networks. In short, the message is that despite instant messengers, e-mail applications and other connected programs running in the background require relatively little bandwidth, they nevertheless have a significant impact on the overall radio link capacity. So why is that, a reader recently asked me?

Let's make a practical example: On my Nokia N95, I use the VoIP client over Wi-Fi a lot. The client works in the background and every now and then communicates with the SIP VoIP server in the network to let it know that it is still there and to keep the channel open for incoming messages. This requires very little bandwidth as there are only few messages sent, from an IP point of view, about 2 a minute. For the full details, have a look at this earlier post.

From a 3G cellular radio network perspective, however, things look a lot different. There are two possibilities: The network could keep the radio link to the mobile device open all the time. This, however, would drain the mobile's battery very quickly as the mobile constantly has to monitor the link for incoming data. Further, this would waste a lot of bandwidth, since a full air interface connection requires a frequent exchange of radio link quality messages between the mobile and the base station. In other words, there is lots of overhead monitoring and signaling going on while no data is transferred.

The other option, usually used today, is to set the mobile device into a lesser activity state. In practice that means that in case little activity is detected by the network, channels are used which are not as efficient, but do not require constant radio link quality measurement reports and dedicated channel resources. That's already a bit more efficient but still consumes a lot of energy on the mobile side. For details see my earlier post on the "FACH power consumption problem". Some networks, which are configured well, detect that only little data is transferred and keep that state. Other networks immediately jump to the full channel right away when data is exchanged again which requires lots of radio link signaling. Further, in UMTS, the channel switching is organized by the Radio Network Controller and not in the base station itself thus putting quite a high burden on a centralized network element.

So what does this mean in practice? In networks today, a single base station covers around 2000 mobile devices. Not a problem today, as with traditional wireless voice, there is no ongoing signaling between the device and the network while there is no call. With non-wireless optimized VoIP however, as described before, there are 2 messages exchanged per minute per device plus potentially further radio interface signaling for channel switching and radio link measurements. In other words, such background IP packets have a higher radio link capacity impact than their size suggests compared to big IP packets that are part of a time limited high bandwidth data flow, e.g. while transferring a web page.

Now multiply that background traffic by 2000 devices per base station (assuming for a moment a pure IP world, non optimized) and you get 66 messages a second that need to be transmitted. Many of these require state changes, thus creating additional signaling in the network. Add to that IM, e-mail, etc., and the number will rise further.

Now why is this different to fixed line networks? There are two reasons: First, in fixed line DSL networks, there is usually only a single household behind a DSL line with only a few devices creating background noise. Second, in fixed networks no additional overhead is required for managing a shared transmission resource, i.e. the air interface. In other words, a small packet just takes that amount of bandwidth on the cable, no less, no more.

To be clear: I am not saying this is a problem for wireless networks (yet), it's just a lot more traffic in the background than what there used to be and it requires more bandwidth on the air interface than their size suggests. Also, standards are addressing this change of application behavior, for example with UMTS enhancements such as Continuous Packet Connectivity, or in LTE with transferring the radio state management from a centralized network element directly into the base station.

In any case I guess we'll see such always-on applications over time to be optimized for mobile use, i.e. more push than poll and less keep-alive signaling. But that's probably not done to please network operators or to increase overall network capacity but to reduce power consumption on the mobile devices.

No more ‘3 Like Home’ International Roaming with 3UK

Back in 2007, network operator '3' in the UK announced that they are no longer asking for roaming charges for voice or data between their networks worldwide. A great offer even though the times I tried, their interconnection was hopelessly overburdened. Looks like the offer is no more as they 3UK has started introducing international roaming charges again since July. A great pity… Strangely though, '3 Like Home' is still offered by 3 Austria!?

The Battery is Part of the Mobile Experience

Extended battery This might seem obvious to most but I just realized these days how important the battery is for the mobile experience. I recently bought a netbook (see here and here) and while most experiences are positive, a battery lifetime of only 2 hours just doesn't do for me in many cases especially when I am traveling. Even if it is enough, connecting the netbook back to the mains all the time for recharging is also a hassle. So I bought an extension battery pack which gives me 6 hours of autonomy in addition to the 2 hours of the standard battery. An incomparable experience! Now even while traveling for a whole day, sitting in the train, waiting at the airport and on the plane, I don't have to worry about the netbook running out of power. Very nice!