Category: Uncategorized

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?

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

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.

It's great when two high speed technologies come together: High speed trains running at over 300 km/h and high speed Internet access. Thalys, whose trains travel between Paris, Brussels, Amsterdam and Cologne has equipped all of their trains with satellite, Wi-Fi, UMTS and GPRS based high speed Internet access, accessible to passengers via standard Wi-Fi. When I recently traveled on one of those trains, I could hardly wait to get on board to test and use the system.

The picture on the left shows the satellite antenna installation on top of one of the coaches. It looks a bit odd on the otherwise very streamlined train but the round shape probably keeps the additional drag to a minimum. Nevertheless, I'd be interested in finding out how much extra energy is necessary to  push the train beyond 300 km/h due to that.

At 7 a.m. in the morning, throughput in both uplink and downlink between Paris and Brussels was tremendous. Speedtest.net reported downlink speeds of more than 10 MBit/s and more than 3 MBit/s in uplink direction! While the link dropped a number of times on the trip to Brussels it was only for a few seconds each so that was probably only apparent to an attentive observer like me running a data trickle in the background to detect just such occurrences. However, the outages were short enough that it didn't affect streaming applications once enough data was buffered. Watching a Youtube video, full screen and in HD quality worked just fine.

As all data is transferred via a satellite in a geostationary orbit, round trip delay times were in the region of 650 ms. While voice calls and even Skype video calls work well over the system the delay can be felt in the conversation. Loading a graphics intensive web page works quite well and fast but it feels a bit sluggish for a moment after clicking on a link or entering a web address before the download of the page starts. This is again due to the very high round trip delay time compared to other systems such as ADSL with a round trip delay time of 50 ms, or the 120 ms over a 3G connection. Having said all that, the experience is still great, especially taking into account that the countryside is passing by at 300+ km/h when looking out of the window while that HD video is streamed over the satellite.

The satellite connection has one real several imitation: In Europe, the geostationary satellite hangs close to the horizon, so it is not always possible during the trip to keep the connection. In such cases a ground based backup is used. In the Brussels main station, for example, Wi-Fi is (probably) used. Downlink speeds came close to 16 MBit/s and round trip delay times were lower than 50 ms. The tunnels around Brussels were covered as well, although I was not sure exactly what technology was used. In other places, especially in the hilly terrain between Belgium and Germany, the satellite connection doesn't work too well either, probably because the train winds its way through narrow valleys and many tunnels. GPRS and UMTS network in that region seem to be patchy at best so the experience on that part of the track wasn't too great.

In between I should also mention that I didn't find any services that were blocked. VoIP worked well, IM worked well and my IPSec based VPN also worked fine over the system.

In the evening I made the same trip in the other direction. It seems a lot more people were using the system in the evening as speeds were much slower than in the early morning. While I could still reach fantastic transmission peaks of 3 MBit/s in downlink and more than 1 MBit/s in uplink, I experienced continuous high packet loss and frequent connection outages in the range of minutes even on the flat terrain between Brussels and Paris. The bad weather and heavy rain might also have had something to do with it, it's difficult to tell from a single ride.

Summary:

Of course I had my expectations before trying the system. In most cases I found it to be much faster than I expected. Especially the main applications such as web browsing, e-mail and VPN tunneling to the company network worked fine. The system has its limitations in hilly areas and cities when there is no direct line of sight to the satellite. While the system automatically switches to GPRS or UMTS in such cases, it didn't work particularly well in many of those places areas, as they were probably not covered very well. It can work much better over 3G as I have experienced here. Overall, however, I was very impressed with the system and I think it's a great service!

…I was asked today. A clear opinion here: Yes and no.

Yes: When I reviewed some of the future chipsets for my recent book it was clear we are moving to processor speeds beyond 600 Mhz, built in camera hardware units of those chipsets supported resolutions of 10-12 megapixels and a touch panel interface was also part of the unit.

No: Such specs tell you nothing about the form factor of a future device. Examples: Just knowing that there is a touch interface tells you nothing of how usable the interface will be. A chip spec doesn't tell you the physical characteristics of the device, e.g. like will it have a hardware QWERTZ keypad, etc. Also, there are usually supporting chips around the chipset like GPS, motion sensors, compass, etc. How they are mixed and matched is not on the datasheet either.

One interesting domain I haven't yet too much looked into is the specs for the radio front end chips. This info would be very interesting to get an insight which technologies (GSM, UMTS, LTE, CDMA) can be supported in future devices, and, equally important, which frequency bands can be handled with a single front end chip. If you have some good references here, please consider leaving a comment.

A non-technical blog entry today addressing the question many have asked me before: Why am I running this blog?

Obviously, I like to write and I like to share stuff I have learnt or that I think about with other people. My thinking and learning, however, is not self contained, i.e. I don't just sit down in seclusion and wait for that light bulb over my head to light up. I am inspired by things I see, read and experience.

It's great, for example, to have full access to 3GPP standards, to the meeting reports, to the change requests, in short, to everything that goes on in standardization. If there's a doubt, these documents clear things up.

It's also the blogs out there on wireless topics that keep me thinking. By reading them, I challenge my thinking and end up with lots of "yes, and" or "yes, but" or "yes and what if" questions which lead to new insights, ideas, and often to new questions.

It's the people I meet at conferences such as ForumOxford, the Mobile World Congress, Mobile Mondays and others which equally challenge my thinking and give me new ideas, direct or indirect.

And last but not least, it's the books on mobile topics and which I sometimes review on this blog. All together, it's my personal open innovation.

So by writing this blog, I do not only have to clearly think things through before and while I write them down, but it's also about giving something back to the community from which I profit. So, thanks very much for reading this blog and especilly for your comments, both agreeing and disagreeing, they are a vital part of the process as well!

Verizon recently announced Gemalto and G&D as their partner for SIM cards and remote provisioning for their LTE rollout. Remote provisioning of SIM cards (e.g. change the list of preferred network operators, network name, etc.) has become pretty much common over the past couple of years but there might be a twist with Verizon and LTE:

Today, remote provisioning of SIM cards is done via SMS. When such special SMS messages are received by the mobile device it automatically forwards them to the SIM card for execution without interaction with the user. What I am not quite sure is how that will work over LTE, because SMS over LTE is not standardized. Of course it would be possible to use the "3GPP CS fallback" feature to 2G GSM or 3G UMTS to receive the SMS messages. However, in Verizon's case that might not be possible for two reasons:

• Their legacy system is based on CDMA, which does not have SIM cards. Hence, the CDMA part of a mobile phone might not have the necessary standardized software to forward those data SMSes to the SIM card.

• The current LTE specs of Verizon say nothing that LTE terminals have to have a CDMA part.

So I am not quite sure how over the air provisioning will work in practice in Verizon's case!? Has there been something standardized in LTE or CDMA for "native" remote provisioning of SIM cards? If you have more info, I'd be happy to hear from you!

In today's 3G networks, voice calls are often in the so called “soft handover state”, which means that the radio network controller sends and receives the data for a voice call to and from several base stations simultaneously. The mobile then receives the voice call data stream from all three cells simultaneously and combines the received signals. While this wastes some bandwidth on the backhaul, these soft handovers often help to reach mobiles at the cell edge, which receive one or more cells with a similar strength.

For HSPA data transmissions, however, the soft handover is not used as the base stations autonomously decide when to schedule data on the air interface and thus, it is pretty difficult to synchronize the transmission over the air interface of several cells. In LTE, such a direct cooperation between cells is also not foreseen for the moment, even though there might be some benefits for mobiles at the cell edge. For LTE Advanced, however, people seem to have started thinking about it again. Instead of sending the same data stream over two or more cells, however, they are thinking about a cooperative MIMO scheme, i.e. each base station sends a different data stream and the mobile then analyses each data stream separately. The result would be a higher throughput for that mobile.

As Moray Rumney points out in his recent book, though, such a cooperative MIMO scheme would be quite challenging to implement in the network. First, it would put quite a demand on backhaul capacity and second, data would have to be exchanged between the base station with a delay of a millisecond or less. O.k., it is still some years away and technology advances, but I tend to agree with him, that's quite challenging to do. What do you think?

Lately I get the impression fewer people use clamshell phones than in the past. Even in the US it seems to me that when I was last there I saw more people with Blackberries running around and happily typing away on the keyboard than people still using a clamshell phone. So why? Could it be that the clamshell format is great for voice calls, i.e. quite sexy to open it up, but does not lend itself very well to text or web based applications? The smaller screen of the clamshell vs. sliders and the act of opening up the phone to check for messages, send a quick sms, e-mail or surf the web might just be that tiny little bit too much these days!? What do you think, what are your observations?

Recently, I had an email conversation with a reader and he sent me a list of mobile phones he had in the past. Interesting memories coming up. I doubt my list is equally long but I think it is time to make my own so I won't forget. Here we go:

• I started with a Bosch 738 (I am German, the French will get the irony)
• A Siemens S25 (my first color phone)
• A Ericsson T39 (my first GPRS phone (!), could only do static assignment, only worked in one network)
• A Siemens S45i (GPRS worked well after a couple of software upgrades)
• A Siemens S55 (browser, color screen, a couple of hundred KB of flash memory with file system!)
• A Sony-Ericsson V800 (my first UMTS phone)
• A Nokia 6630 (only used as a modem at the time)
• A Nokia 6680 (First phone on which I discovered the power of S60)
  
• A Nokia N70 (Natural evolution from the 6680)
• A Nokia N93 (Bought because of the camera and the twist) 
• A Motorola V3xx (initially used as an HSPA modem, today also as backup phone)
• A Nokia N800 Internet tablet (o.k. not quite a mobile phone)
• A Nokia N95 (my main phone today in 2009, bought because, well, because of everything 🙂
• A Nokia N82
• A Nokia 5000 (low end with color screen, used as phone and to test apps on an entry level platform)

And in addition:

• I had a Palm 3, and two HP PDA's, discontinued to use them when I bought the N70, as I could do all the calendar stuff, etc. on the mobile phone
• A Sierra Wireless 850 1.8 MBit/s cat 12 HSDPA PC-card modem
• 2x Huawei E220 3G USB dongles (3.6 MBit/s cat 6 HSDPA) for Internet access. In use today. They might be a bit clunky by today's standards, but they just work in all networks I have used so far, which can't be said of other 3G sticks I tried.

There we go, the list is already longer than I thought 🙂

Over the past days there have been reports in the press that Vodafone Germany will trial LTE in the 800 MHz digital dividend band to collect experience how this frequency band can be used for rural broadband Internet coverage. The reports also mentioned that a TV station (the WDR) will also take part in the trial. A TV station?

Why, I wondered at first, as all but Unstrung did not go into the details of why a TV station is part of the trial. So, according to Unstrung, the TV station is part of the trial as they are interested, or a bit worried, that using spectrum in the 800 MHz band for broadband Internet could have an impact on their TV broadcasts in an adjacent band. Further, wireless microphones are using the digital dividend band today and it seems it is not quite clear of what can be done about that in the future (see here and here).

So the outcome of this part of the trial will be quite important to figure out if or how all of the 72 MHz foreseen to be assigned in the 800 MHz band for mobile broadband systems can be used without generating too much interference for TV broadcasts. An interesting topic to follow.