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!

Orange sells Prepaid 3G Sticks at Paris Airport

Automatic mobile store 2 I had an interesting surprise when I passed through Paris airport recently. Orange (France Telecom) has put a vending machine in the airport hall where people can buy prepaid SIM cards with different kind of phones and also prepaid 3G Internet access together with a 3G stick.

The Internet offer with the 3G stick (locked to the network operator I suppose) is around 30 Euros. Oddly enough from an outsiders view, usage is paid by time and not by volume. 2h are included in the starter pack.

Unfortunately, prices for further online time are very unattractive. 3 euros buy 20 minute of online access, an hour costs 8 euros and 6 hours cost 25 euros. Online activities can be interrupted and all but the smallest pass are valid for using during a timeframe of one month. Compare that to the 1GB for 15 euros offer which is valid for a year from A1 in Austria. Quite a difference.

Smartphones: Units, Revenue, Profits – Update

Back in October 2008, I wrote about a blog post of David Wood, who is part of the Symbian leadership team, where he said that while smartphones only account for 10-15% of sales units, the sales revenue is between 20-25% and profits may even exceed 40%. Now Moco News reported similar numbers being given by Deutsche Bank analyst Brian Modoff in an article in the Wall Street Journal.

His numbers are as follows:

  • Apple and RIM together only have 3% of the mobile phone market share but make 35% of the total profits.
  • Nokia manufactured 46% of the mobile phones sold last year (I heard 38% somewhere else) and made 55% of the profits. Note: It would have been interesting to see the split in profits between their smartphones and the rest of the phones they produce. Do they give these numbers in their quarterly reports?

That makes me wonder why there is so much profit in smartphones vs. the rest!? Granted, their price is much higher than that of ordinary phones and thus if the profit percentage is similar, the profit per device is also higher. However, that can't explain it all. Less competition then maybe? Also a bit doubtful as the smartphone market seems to be quite competitive with manufacturers like Nokia, Apple, RIM, HTC (G-phone, WinMob), etc. vying for market share. What do you think?

Please don’t use your Typekey ID for Comments

Every now and then I get an interesting comment for which a typekey id was used as a commenter id instead of an e-mail address. While that is perfectly all right in theory it unfortunately doesn't allow me in practice to reply to you by e-mail in addition to leaving a comment of my own below the poast. That's a bit unfortunate as most people probably won't check back on the blog to see if I have left a response. Therefore, dear readers, please put an e-mail address in the id section of the post if you would like to receive a response in case I have any 🙂 The e-mail address is only shown to me so there is no need to worry about spam. Thanks!

Linux 3G Dashboard from Vodafone Betavine

Screenshot-Vodafone Mobile Connect Here's a quick update on my experience with my netbook, Ubuntu and 3G connectivity. As reported previously, the 3G connectivity manager built into Ubuntu works (most of the time) but doesn't have some important administrative functions included such as network and network type selection and some general observational functions such as current network name and signal strength indications.

At least the later functions are included in the Linux 3G Dashboard from Vodafone Betavine, which works great with my Huawei E220 USB 3G stick. The screenshot on the left shows how signal strength and the network name is displayed in the lower left corner of the dashboard. Nicely done!

What's still missing is a network selection dialogue and to be able to lock the USB stick to 3G, which sometimes helps to stay connected in bad signal conditions. It would be nice to see this in a future version. Also, having the possibility to select a different connection profile on the main screen would also be nice, especially for people (like me) who travel a lot.

To install the dashboard go to this Vodafone Betavine project page, and download and install all packages from the download section.

Always-On LTE Roaming

I've been thinking a bit about LTE and international roaming lately and just realized that mobile network operators need to come up with a new billing scheme compared to current systems. Here's why:

2G and 3G devices only request the establishment of a data bearer (a PDP context in 3GPP talk, or getting an IP address in Internet talk) when an application requests it for the first time. Thus, from a billing point of view, nothing is charged until that point. With LTE, however, the device gets an IP address right when the device registers with the network after startup. In effect, the 2G / 3G packet call becomes history with LTE. While in the home network this can probably be managed quite well from a billing point of view, I wonder how network operators will proceed for roaming. After all, most users will probably not be too happy to be charged just for switching on their device.

For LTE USB dongles, this might not be a problem as the user can decide whether to plug it in or not. For notebooks with a built-in LTE modem, however, or an LTE capable smartphone, things are different. A user of an LTE capable smartphone probably wants to use it abroad as well, even if it is only for voice calls and the offline organizer functionalities without being charged if he doesn't actively use the Internet. I wonder how this will be solved in practice!?

I could imagine several solutions:

  • The device detects the roaming scenario and asks the user whether to attach to LTE and get an IP address and warns the user that this might be a chargeable event.
  • The device detects the roaming scenario and doesn't attach to the LTE network. Instead, a 2G or 3G network is selected where getting an IP address right away is not required. The question then is how the user could trigger this later-on. In case of a smartphone it could wait till an application tries to access the Internet and then reselect to LTE once the connection is established. That won't work for LTE capable notbooks, though, as there are always applications crying for IP connectivity…
  • The home network detects that the user is roaming and blocks initial access to the Internet. Then, via a web based landing page, the network informs the user that different rates will apply if he proceeds. The problem with this approach is that the user has to open the web browser first before his other applications can get access to the Internet.
  • A certain amount of data traffic while roaming  is already included in the subscription. When going beyond this amount, access is blocked until the user is informed (e.g. via SMS or a landing page) that further Internet access will be billed separately and the user has given his consent.

Hm, it all doesn't sound convincing yet. Better ideas, anyone?