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!

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!