LTE – A Dictionary of Wireless Acronyms

In case you every now and then come by an LTE acronym you don't
quite understand (e.g. while reading the standards…), here's a great
resource that might help you in the future: As an online addition to
their book on LTE (LTE – The UMTS Long Term Evolution: From Theory to Practice)
Stefania Sesia, Issam Toufik and Matthew Baker have published a
dictionary on LTE acronyms. It's around 100 pages and very useful.
Highly recommended! Have a look at the left of the page, it's a bit
hidden (PDF Download under supplementary material)

Via: LTE Watch

Grameen, Google and MTN start Mobile Services in Uganda

Since I read "less walk more talk" I've become more aware of how mobile communication changes Africa. It's my impression that so far, voice, person to person SMS messaging and some information services again based on SMS (e.g. what are the prices for a certain goods in a certain city) have made the most impact. Also, the "mobile crop insurance" trial I've reported on here is an interesting project. And now, Grameen, Google and MTN have started new services to bring knowledge to rural areas around farming, health tips and trading. Again, based on SMS. Here's a video with some details. And for some more details from the inside perspective, have a look here.

A Netbook, eeeBuntu and Mobility – Part 1

Acer aspire picture Here we go, a long weekend was ahead so I took the opportunity to finally get a netbook for myself and start experimenting with it. After some deliberation, I got an Acer Aspire One 250 with a 3 cell battery and without Bluetooth for €299. Here's my report with my first impressions, how it works with Ubuntu Linux and how easy it is to get 3G connectivity working over a 3G dongle.

First, some specs. The D250 is quipped with a 10.1 inch display, a screen resolution of 1024×600 pixels, a 1.6 GHz Intel Atom processor, 1GB of RAM and a 160GB hard drive.

As I've seen on the original eeePC, Linux runs great on lower performance devices so I was keen to use Linux with this netbook as well. Unfortunately, most netbooks these days seem to be delivered with Windows XP only, so the first exercise was how to get Ubuntu installed without a CD or DVD drive.

Installation

I've seen on the net that eeeBuntu, an adaptation of Ubuntu Linux to the eeePC line of Asus supports the Acer Aspire series as well, so I decided to go for this distribution. To get eeeBuntu installed, the first step is to download the latest CD image from the web page and then install it on a USB memory stick that has a capacity of at least 1GB. Installing the image from Windows requires "unetbootin", a little tool that can be downloaded from the site as well. Once installed on the USB memory stick, the remaining procedure is pretty much straight forward as well. During a restart of the netbook, pressing the F10 key leads to the BIOS configuration menu where the boot device order can be changed to prefer USB media over the built in hard drive. The netbook then boots from the USB stick and enters the installation program. The first and crucial step is to partition the internal hard drive. To my great surprise and pleasure, it is not necessary to delete Windows from the hard drive. Instead, the Ubuntu partition manager allows to reduce the size of the Windows partition to make room for an extra partition for Linux. I evenly split the 160 GB between the two operating systems and I was up and running with both within a couple of minutes. Very nicely done, two thumbs up!

Hardware Compatibility

After booting for the first time, eeeBuntu configures itself for the hardware it finds. Most importantly, the graphics chip and the Wi-Fi were configured correctly and I could use the system right away without tweaking anything. The two devices that were not detected correctly and has since then resisted all attempts to get it working are the built in web cam and the Ethernet card. They work fine under Windows but won't do a thing under eeeBuntu. Still under investigation…

Fist impressions

First Screenshot After using the system for a day now, installing and configuring the desktop and the programs as I would like to have them, I am very impressed by the speed and stability of the system. Programs such as Firefox, Gimp and Openoffice load much faster than on my full size Windows XP notebook. One of the important benchmarks for me is the somewhat power hungry Typepad web editor for my blog. It turns out that it works great on the netbook, only marking text is a bit slow. Seems to be a Firefox issue, however, as the CPU utilisation remains low. Also, the startup time of the system is impressive. After a little less than one minute, the system is up and running. As you can see on the picture on the left, I created this blog post on the netbook to get a feeling for the keyboard. It's slightly smaller than a standard keyboard but after a couple of minutes I can easly and quickly type with 10 fingers with a similar speed as on a standard size keyboard. An absolute must for me!

So much for this post. In part 2, I'll go into the details of how to connect to the Internet with a 3G USB dongle or mobile phone and other things I found usable or not so usable over the first couple of days. Also an important question: How happy would a normob be with Ubuntu compared to Windows XP? To be continued.

Is 1.000 Terabytes a Month a Lot?

Two companies have made some interesting network usage statistics available recently. In the chart in this post, Verizon states that in December 2008, they transferred around 4.000 terabytes of data through their network. Ed Candy of Three in the UK reported 1.000 terabytes for the same month in his presentation during the Forum Oxford Conference. Incredible numbers, but how much is that on a day to day basis?

Let's do some maths. 1.000 divided by 30 days is 33.3 terabytes per day. Further divided by 24 hours of the day, by 60 minutes and 60 seconds, this amounts to around 3.85 GBit/s. During busy hour, traffic on the Internet is around twice the average as per the DE-CIX Traffic statistics shown here. That would bring peak traffic somewhere near 8 Gibt/s.

Let's further divide that number by how many cell sites an operator has. In the case of Vodafone Germany, it's around 13.000, so let's assume Three in the UK has around 8.000 to make the number low. A throughput of 8 Gibt/s divided by 8.000 cell sites is 1 MBit/s. As a cell has usually three sectors, that number has to be divided by 3. Hence, the average sector throughput during busy hour is around 0.3 MBit/s.

That's an average value of course. In conference presentations I have heard that cells in urban areas carry a lot more than the average. That's both good and bad news. The bad news is that capacity limits will appear here sooner. The good news is the number of base stations that have to be upgraded once the capacity of the current buildout is reached by adding a carrier or to add more base station sites is limited.

So the numbers quoted in the presentations seem quite realistic to me and also indicate that there is still quite soom room left to breathe capacity wise.

The Toy Blackberry for Your Kids

Bb-sm I know, toy mobile phones have been around for quite a while to prepare the kids for their first real one… But now, there are even toy Blackberries. See and click on the picture on the left I have taken in the supermarket around the corner. You can never start early enough…

Opera Unite and the Anti-Cloud

Recently, Opera announced the launch of their new "Unite" service, which transforms their web browser into a combined browser / server so users can't only consume content stored on the net but also put their own content such as pictures, videos, etc online without loosing control. Content opened to the net can be for private use outside the home network, it can be shared with friends or with the general public.

I am happy to see Opera going in this direction as I am one of those people who like to keep control over my private data and store them at home rather than on a server somewhere in the cloud while still having access to it no matter where I am. I've recently given a talk on the evolution of mobile networks at the University of Oxford (slides see here) and I think such Anti-Cloud services will be an interesting way for converged fixed/wireless network operators to make money with in the future.

Opera is not the first to think about such services. Nokia for example has launched a prototype of a web server for mobile phones to share content and interact with other people already three years ago and I'm a glowing fan of the concept. The downside of both concepts is that the device which offers the content is not always available, be it because the notebook is not always switched on or because the mobile phone every now and then ends up in places without network coverage or runs out of battery power. This is where I see fixed/wireless network operators come in, as the web server could run on the home gateway (think DSL modem + Wi-Fi + Femto + services) which is always switched-on and always available.

I wouldn't be surprised if Opera would be looking in this direction as well, their browser suite is already today not only available on the PC and mobile phones but also on game consoles etc., so they are definitely not new to embedded devices, development and deployment.

For more thoughts on Unite, here's what Ajit Jaokar over at OpenGardens thinks about it.

There Are Many Places in the Network For Services

So far there are three places where services and applications run/hosted/placed in the network:

  • In the core network of the mobile operator, think voice calls and IMS
  • On the Internet, think web based applications like Google Reader, Yahoo maps, etc, etc.
  • On the device itself, think Microsoft applications on PCs, Java and native applications on mobile devices.

When services and applications are connected, they usually interact with some other part of the network. A web browser for example is only useful because there are web servers on the Internet providing content. Some services and applications are also hybrid. Take Opera Mini for example. The browser is split between a light-weight Java application on the mobile device and a compression proxy somewhere on the net.

And now a fourth place for applications and services is emerging, on femtocells and home gateways. Services under development are automatic multimedia file transfers from/to mobile devices when they enter the femto area, forwarding of messages left by friends on Facebook and elsewhere for when the user returns home, automatic notification of parents when kids have returned home, etc.

Ip.Access is pretty outspoken on the topic and has announced a Femtocell Applications Live Event in London on June 23rd over at ForumOxford.

The Paradox of Open

Yesterday, Ajit Jaokar over at Open Gardens published a thought piece he called "The Paradox of Open: What we can learn on Open from Apple and Microsoft". He argues that despite Apple and Microsoft having closed mobile operating systems they are successful. The conclusion he reached was the following:

"I believe that: A 'closed platform' works provided you have an 'Open ecosystem' BUT an Open platform (open source and / or open standards) without an ecosystem (open or closed) does not work."

An interesting statement I agree with and would like to extend a bit to show further influences:

A couple of days ago I met with a friend who's had an iPod touch for some time now and is a glowing part-time developer. When I asked him why he picked up programming for the iPhone / iPod touch and what he thought about the development environment, he said that:

  • he picked it up because Apple is doing great things
  • because he likes the UI and how easy it makes things for users.
  • the development environment for the iPhone is not so nice with the license you have to get and all the restrictions that are put in place with developer codes, distribution, etc.
  • he only works on it because the product on which the application will run is so great. Otherwise he would not bother.

So I think in the end it doesn't really matter if an OS is open or closed. If it is not liked by users for whatever reason and is not easy to use and there is a better alternative available, then nothing will come of it.

Speaking of ecosystems: I think for a free and open source OS it is much simpler to get an ecosystem in place because the community can help vs. a closed source OS where the burden of fostering an ecosystem lies in the hands of the company that owns it.

A good example is Nokia's Memo platform for their tablet devices. It's for the most part free and open source and yet, only few users have bought one. In my opinion the handling and UI is just nowhere near the iPhone or similar touch devices yet.

In other words: Part of the ecosystem, a part that one can't touch, is the success of the product, its ease of use and in turn how many people use it. So Open alone is not warranting success on its own. In that respect I am not sure if there is a paradox with Open? As always, comments are welcome.

How to Explain the Thoughts Behind BICN

Bicn-stack There are lots of things in this world that don’t make a lot of sense unless you know how they have evolved to their current state. One of those things is the migration of circuit switched telephony to the IP world with the Bearer Independent Core Network concept specified in ITU Q.1901 and introduced in GSM and UMTS starting with 3GPP Release 4.

Here’s my take at it:

With BICN, the circuit matrix of the MSC (Mobile Switching Center) that creates a physical voice circuit between two subscribers is replaced by a media gateway. The media gateway maps the concept of a circuit connection to an IP stream between two parties. The stream is then transmitted together with many other streams over a shared packet switched link, which is for example based on Ethernet.

The Signaling System Number 7 (SS-7) used in the circuit switched world is still used in this architecture but has been changed to some degree. The protocols of this family are used for the following tasks:

  • For the establishment of voice calls
  • For the interaction between different network nodes (e.g. between the switching center and the subscriber database node)
  • For communication between the switching center, the radio network and the mobile device

The main difference with SS-7 over IP is that the lower layer MTP protocols have been replaced by IP, SCTP and M3UA, so the messages can be transported over IP instead of a circuit switched timeslot. The figure on the left shows the MTP based SS-7 protocol stack in comparison to the IP based SS-7 protocol stack.

Above the MTP layers, the ISUP protocol that is used for establishing voice circuits has been replaced by BICC (Bearer Independent Call Control). BICC is very similar to ISUP. Message names are the same and only some parameters have been changed as the messages are now used to control media streams instead of circuit connections.

Protocols for the interaction between different network nodes (e.g. between the voice switch and the subscriber database) such as SCCP, TCAP and MAP have not been altered at all. DTAP (Direct Transfer Application Part), the protocol used for interaction between a mobile device and the switching center for purposes such as authentication, location updates, etc., has also remained unaltered. In other words, applications that use these protocols are not aware if the messages are transported over signaling timeslots of a circuit switched network or over an IP link.

To enable IP based SS-7 nodes to communicate with MTP based nodes in the network, Signaling Gateways are used to translate MTP into IP / SCTP / M3UA. This way, a traditional circuit switched MSC is able to communicate with a subscriber database node that is connected to the network over an IP connection.

And finally, from a mobile point of view, the air interface between the base station and the mobile device also remains unchanged. This means that GSM and UMTS mobiles have no visibility what kind of access or core network technology is used.

Today, both traditional circuit switching and BICN can be found in live networks so knowing only one of them won’t do, at least for the moment. So I’ve decided to coin two terms:

  • Traditional circuit switching”, i.e. the origins of circuit switching with voice calls transported over physical circuits and SS-7 messages being transported over circuit timeslots.
  • Virtual circuit switching over IP”, i.e. a voice channel is transported over an IP stream and the SS-7 protocol is used in a modified form in the IP world.


Traditional circuit switching vs. virtual circuit switching over IP. Do the terms make sense to you?

GPRS Detached, Attached and a PDP Context

Over at Boy Genius Report there's been a post yesterday about how to keep a data connection alive on S60 devices over some time of inactivity. Unfortunately, the conclusions drawn there are technically not quite correct. So, as there is probably some interest in the community of how always-on connections work over GPRS and UMTS from a lower layer point of view, I've put together a summary to show what is really going on.

GPRS Detached

When you power up an S60 mobile for the first time, it is usually configured to only establish what is referred to as a "packet data connection" when needed. The term "packet data connection" however, is grossly misleading. When set this way, the mobile will only attach to the voice part of the network but will not make itself known to the GPRS packet switched side of the network. An S60 device shows this state, referred to as GPRS detached, by showing a little antenna symbol below the signal strength bars at the top left of the screen.

GPRS Attached

Screenshot0055 When the "packet data connection" option is set to "when available", the mobile performs a GPRS attach procedure as soon as it is switched on. This means that the mobile in addition to becoming known to the voice part of the network also becomes known to the GPRS part of the network. An S60 device shows this state to the user by showing two little dashed horizontal arrows below the signal strength bars. If the network supports EDGE, a little E is shown in addition above the arrows. This is shown in the picture on the left. If UMTS is supported, 3G is displayed above the arrows. In this state, and this is the crucial point here, the mobile device is NOT connected to the Internet, i.e. it has no IP address. Hence, the user is not charged and it has nothing to do with always-on connectivity.

So what's the use of this state? Not a lot actually. In the past, it was envisaged that applications from the Internet could trigger an IP connection being established to the mobile device when packets for it are received. However, to the best of my knowledge, no operator has ever made use of this functionality as it is pretty much obsolete due to the real always-on connectivity described just below. It's only real benefits are that the user sees on the display if EDGE is available or not, and that Internet connections are established faster in a subsequent step because the mobile is already registered.

In terms of power consumption, being GPRS attached should not require any more power than if one only attaches to GPRS when establishing an Internet connection if the network operator has configured the network accordingly. In practice, many network operators these days use an interface between the circuit and packet switched part of the network (the Gs interface between the MSC and the SGSN) so the mobile registers only once to the network when it is powered on and not to each part of the network individually. Also, periodic location update timers are set to the same value for the circuit and packet switched part so there is no additional signaling involved for being GPRS attached.

PDP Context Activated

Once an application wants to access the Internet for the first time, an IP address is requested from the network. This procedure is referred to as "PDP (Packet Data Protocol) context activation". Once an IP address has been acquired, the horizontal arrows at the top left of the screen changes from dashed to solid. The IP connection stays in place until one of two things happen. When the user closes an application that has requested an IP connection and no other applications are still running that use the connection as well, the IP address is released and the two arrows go back to their dashed state (GPRS Attached). But until this happens, the IP address remains assigned even if the application doesn't transfer any data. There is no technical limit of how long an IP address can stay assigned without exchanging data, it can persist for days, weeks or years. In practice, however, some (but not all) operators reset all IP connections once every 24h or after some time of inactivity. There are also operators who don't have their network properly configured so it can also happen that the IP connection is dropped when moving through the network and neighbor relationships are not properly set or if a core network component (SGSN or GGSN) malfunctions and is rebooted. However, those are exceptions.

A little Mystery

In the picture on the left there is a second option in that GPRS Attached/Detached configuration menu which is called "Access Point". I am a little bit puzzled what this option could be good for as it doesn't change the behavior of my N95 no matter whether it is set to "none" per default, to an APN or to a profile name.

Summary

The summary of this somewhat long text is that the description in the Boy Genius post is not accurate. The post suggest that by changing these options, the mobile will be switched to an always-on state and that the data connection will be kept. The only thing these options do is toggle between GPRS Detached and GPRS Attached state. The assignment of an IP address (PDP context activation) is a separate procedure, completely independent of these settings.

As a consequence, the "Packet Data Connection" option does not make anything better or worse if one has an unlimited data plan, or if one is billed per kilobyte or by the minute. Since it only speeds up getting an IP address when the first application that uses a connection requests data for the very first time, the setting should be the same for all kinds of data plans: "when available".

For more details, great places to look are the GPRS service description stage 2 (3GPP TS 23.060) or the GPRS introduction Chapter 2 in my book on mobile networks.