Category: Uncategorized

Putting cell towers in place is one thing, optimizing their coverage quite another. Today, a lot of planning is required in advance to make sure all required neighboring cell information and handover parameters are available, antennas are installed and configured with the correct angle in order not to create too much interference in the coverage area of neighboring cells, etc. etc. With adding yet another radio layer with LTE, things are not getting any easier if everything has to be done by hand and later-on check and refined with drive tests. Furthermore, networks are never static as new cells added, as frequency plans change, etc., so frequent quality checks like drive tests are required.

To reduce the amount of work required, 3GPP is working on a standard for LTE to be a bit more self-organizing, self-correcting and reporting issues that can't be fixed automatically to maintenance. A number of papers have been written to cover the current state in 3GPP on this topic, for example by Nomor back in 2008 (see here) and by 3G Americas recently (see here). In the 3GPP archives, the following technical report might be of interest to you on which the subsequent standardization is based on:

3GPP TR 36.902: Self-configuring and self-optimizing network (SON) use cases and solutions

With 3GPP Release 9, time has come to put things into Technical Specification (TS) documents. These can be found in the 3GPP 32-series starting with TS 32.500. Here's a list (no exhaustive) of documents that sound especially interesting:

• 3GPP TS 32.500: "Telecommunication management; Self-Organizing Networks (SON); Concepts and requirements"

• 3GPP TS 32.501 and 36.502: "Self-Configuration of Network Elements; Concepts and Integration Reference Point (IRP) Requirements" and "Information Service (IS)"

• 3GPP TS 32.503: A CORBA framework for SON

• 3GPP TS 32.511: Automatic Neighbour Relation (ANR) management

• 3GPP TS 32.521, 32.522, 32.523: SON stage 1, stage 2 and stage 3

• 3GPP TS 32.541, 32.542, 32.543: Self Healing stage 1, stage 2 and stage 3

Quite an impressive list and the whitepapers mentioned above list the following features that are thought of in 3GPP:

• Self-configuration: Retrieve basic operation parameters from a centralized configuration server when the cell is first activated.

• Automatic Neighbor Relation (ANR): Mobile devices can report cells to the base station they are currently served by that are not in the neighbor list. This information can then be used by the network to automatically establish neighbor relationships for handovers.

• Coverage and Capacity Optimization: Interference between cells due to too much overlap ov the coverage area and the opposite, coverage holes, are one of the main enemies of every network planner. Such conditions are usually detected with drive tests. Here SON aims to use mobile device and base station measurements to detect these issues. While interference can potentially be reduced automatically, unintended coverage holes can sometimes only be fixed with additional base stations. In such a case the equipment could at least notify the network operator.

• Energy Saving: Reduce transmission power in case it is not needed, automatic shutdown and re-initialization of femtocells when the user arrives in or leaves the coverage area of the femto.

• Physical Cell ID configuration: This is a very short id that mobile devices can read without decoding the full broadcast channel. Only 504 IDs are available so they are not unique. Therefore, an auto-configuration is highly desirable. Again, the mobile is required to report to the network which cells it sees for the configuration process.

• Handover optimization: By analyzing the failure causes of handovers, coverage holes or wrong handover decisions can be detected and changed.

• Load Balancing: If a cell already experiences high load from many users, send users at the cell edge to nearby cells.

• Random Access Channel Optimization: The random access channel (RACH) is needed for the initial communication between non synchronized mobile devices and the network. Depending on the load, the number of resources dedicated to the RACH can be changed dynamically.

Quite a list! Interesting though that for the moment, all actions pretty much focus on LTE only. Lots of potential therefore for the future to extend SON functionality to the interworking with GSM and UMTS networks. In that regard I wonder if in the future network vendors will manage to offer an integrated SON an general management functionality for GSM, UMTS and LTE.

Ideally in a world where base stations are (auto-) software configurable on the fly for whatever air interface technologies are required at a certain place at a certain time. Advanced multi-mode base stations, but that's another topic…

Just a little note today on the availability of ITU standards. While I don't need them often, every now and then they are a great help to find the answer to some really nitty gritty circuit switched telecommunication network questions, both fixed and mobile. Most of them are available from the ITU web page. Not quite as open as 3GPP standards, i.e. the latest updates and additions seem to require some form of registration and/or payment, but for most purposes it should do.

A couple of days ago I wrote about the slow startup time of UMTS during mobile web browsing when the air interface connection is in disconnected state. Looks like my idea of establishing radio bearers early for example when unlocking the phone is not necessary as a couple of enhancements are already foreseen to address this issue:

The first feature is the Cell- and URA-PCH Radio Resource Control (RRC) states. Already defined in the very early stages of the UMTS development they are still not used by most operators today. The major difference to going to RRC disconnected during a prolonged time of inactivity is that all logical radio bearers remain allocated and also the logical signaling link from the Radio Network Controller to the SGSN in the core network remains in place.  So instead of going through the procedures for RRC establishment, authentication, ciphering, radio bearer setup and radio bearer reconfiguration for high speed, the mobile device simply goes back to Cell-FACH state by sending a data packet. And from there, a radio bearer reconfiguration takes the link back to the high speed channels.

So instead of over two seconds, the procedure takes from the disconnected state today, the time necessary to get out of Cell- or URA-PCH state to the high speed channel should be similar to the time it takes from Cell-FACH to high speed today, which is less than a second. That's very close to the times already achieved with the good old GPRS/EDGE air interface. There might be an impact on power consumption with the Cell- and URA-PCH states. However, like in idle state, only the paging channel needs to be observed so this is likely to be a small trade-off.

The second feature is the Enhanced Cell-FACH state that is part of the Continuous Packet Connectivity feature which I've reported on here, here and here. That should reduce the time even further as the radio connection doesn't have to make a detour over a dedicated channel.

All very nice, now it just has to come!

A quick note to myself today that might be helpful for you as well on LTE System Information Messages. SI's have existed since the days of GSM (and probably before) and inform mobile devices about all important parameters of how to access the network and how to find neighboring cells. Here's an overview of those that have been defined for LTE so far. For details see 3GPP TS 36.331 Chapter 6.3. Compared to GSM and UMTS, the amount of parameters inside seems quite a bit less bloated:

• Master Information Block: Most essential parameters

• SIB 1: Cell access related parameters and scheduling

• SIB 2: Common and shared channel configuration

• SIB 3: Parameters required for intra-frequency cell reselections

• SIB 4: Information on intra-frequency neighboring cells

• SIB 5: Information inter-frequency neighboring cells

• SIB 6: Information for reselection to UMTS (UTRAN) cells if no suitable LTE cell is available

• SIB 7:  Information for reselection to GSM (GERAN) cells if no suitable LTE or UMTS cell is available

• SIB 8: Information for reselection to CDMA2000 systems (mostly for North America)

• SIB 9: Home eNodeB name – for future LTE femtocell applications

• SIB 10 + 11: ETWS (Earthquake and Tsunami Warning System) information

• SIB 12: Commercial Mobile Alerting System (CMAS) information. Never heard about this before!?

After noticing that the Nokia E75 announces SIP AMR-WB capabilities I did some follow up work to see where it is standardized and how universal it is. According to Wikipedia, AMR-WB is specified in ITU G.722.2. Several bit rates are available and what I can see in 3GPP, codec rates up to 12.65 kbit/s are used in wireless. Makes sense as that is a similar maximum bit rate as for EFR (Enhanced Full Rate) or AMR-FR (Adaptive Multi Rate – Full Rate) in GSM and UMTS today, i.e. the same air interface bandwidth is required as for todays codecs.

To be able to use AMR-WB in wireless networks, transcoders need to be deactivated in the network. The features for this are Tandem Free Operation (TFO) and Transcoding Free Operation (TrFO) in GSM and UMTS respectively. For details on those see a blog entry I wrote back in 2006 (!). Interestingly enough, this blog entry is still very popular so it looks like quite a number of people are working on this.

So what about fixed line networks? Here, my picture gets a bit sketchier but I'll try to put the pieces together here. If you have different/additional info, please let me know. The successor to the current cordless digital standard (DECT) is called Cat-iq. Again according to Wikipedia, the wideband voice standard used here G.722 at 64 kbit/s. G.722 is the big brother of G.722.2 and they don't seem to be compatible. Also, it seems that the wideband codec can only be used over an IP link, i.e. the phone must be connected to a SIP VoIP provider. On this thread, Frank-Christian Kroegel mentions that ISDN can also be used for the wideband codec but it seems that is not done in practice yet. And anyway, except for Germany and a few other countries, ISDN is not widely deployed anyway. 

So it looks like wideband voice is going different ways in fixed and mobile networks for the moment. That's a pity but who knows, with fixed and wireless networks operators merging again these days, things might change in the future. I wonder how long it will take to have a wideband voice future besides with Skype?

Recently a friend asked me if it was possible to block sending his caller ID when he uses his mobile phone for all calls in general but define exceptions for calls to friends and family. Sounds complicated but it's actually rather simple. Here's how it can be done with any GSM or UMTS phone: First find the menu entry which lets you select if by default your caller ID is shown or not. For the scenario above, set it to “never show my caller ID” or similar. For your friends that should see your number when you call, go to the phone's phonebook select the relevant entries and add the following code in front of the phone number:

*31#

This tells the phone to inform the network not to apply caller ID blocking for this call. It's a standardized GSM/UMTS supplementary service code so it should work with pretty much any phone. For more of those codes have a look here.

There are two reasons mobile network operators are giving out private IP addresses to mobile users and map the traffic over a Network Address Translation (NAT) gateway to and from the Internet. The first is that IPv4 addresses are a scarce resource and assigning a public IP address to every user would require a huge pool. The second is reason battery drain. As public IPv4 addresses get reassigned, unsolicited packets can arrive at the mobile device for example from file sharing applications that were intended for the previous owner of the IP address, from virus- and other malware programs probing computers for potential weaknesses and from other origins. This phenomenon can be nicely observed in networks that use public IP addresses like Vodafone Spain for example and drain the battery really fast as the air interface is constantly in connected state. NAT keeps those packets from coming in which is good for battery consumption. On the other hand, network address translation renders services running on the mobile device that are waiting for incoming connections useless.

IPv6 can easily fix the later problem as the address space is so huge that each mobile device gets assigned a full 64 bit address space from which a network identifier (the other 64 bit of the address) can then be selected. The network operator is assigned a 32 bit part of the IPv6 address (for details see the German version of the Wikipedia entry on IPv6) which means that almost 4.3 billion devices can be hosted with a single assignment. So will that help with the power consumption problem due to unsolicited packets? If subnets are randomly assigned, then that might just do the trick as spamming such a large address space with unsolicited packets is likely to be quite difficult if not impossible.

IPv6 enthusiasts out there, what do you think?

Happy new Year 2010 to all of you! And not only to you as in Germany, like in many other places around the world it's custom to send a new year message to friends and family by SMS or give them a call right after midnight. Bitcom estimates that in Germany, 300 million SMS messages are sent over the change of the year. Compared to the average of 80 million messages a day, that's quite a spike, which is, from experience, highly concentrated over the first few hours of the day.

So I wondered how long it takes for messages to be delivered during such an extraordinary traffic peak? Between 10 minutes past midnight and 40 minutes past midnight I sent four messages from a 3G phone to a 2G phone. All messages were immediately accepted my the SMSC. The delivery was then deferred for some time. The first messages was delivered within 10 minutes, the following two in about 25 minutes and the fourth took again a bit longer to be delivered. It look like the fireworks takes precedence. So yes, the SMS Service Centers must have been quite busy 🙂

Already back in November 2009, the 5th IMS Workshop organized by Prof. Thomas Magedanz of the Fraunhofer Research Institute FOKUS took place in Berlin. Unfortunately I couldn't attend this year but the good news is that most of the conference slide packages are available on their website after registration. Honestly, I wanted to blog earlier about it but I first wanted to have a look at some of the presentations myself so I could add a personal touch to the post. Not so easy as the conference was packed with exciting presentations so it took me a while before I could find a couple of hours.

Unlike the name of the conference suggests, the presentations were not all about IMS but rather about how the IMS could potentially fit into the ecosystem and how it could potentially provide a link between the telecom and the Internet world. As one presenter pointed out in his presentation, the telecoms world is pretty much on an evolutionary path while applications born in the Internet space are usually done so in a revolutionary way. Without some special glue, the worlds don't fit together very well and a lot of friction is created.

Here's an overview of the conference and workshop streams, each with a number presentations. If it sounds interesting, head over and take a closer look (the link to the presentations is on the top left side of the page):

• Workshop 1: Facing the Technology and Landscape beyond Voice
• Workshop 2: IPTV & Media Convergence
• Workshop 3: Future Internet – What Can We Use Today?
• Workshop 4: NGMN – From Vision To Reality
• Conference Session 1: IMS as a Convergence Platform
• Conference Session 2: Rich Media
• Conference Session 3: Keynote from Henning Schulzrinne: Preventing Congestion Collapse of SIP Servers
• Conference Session 4: NGN and Future Internet

An if that wasn't enough there were even more presentations given during an additional event the day after which was called "NGN Service Delivery Platforms & Service Overlay Networks". Again, the presentation slides can be found online.

Great stuff, I hope I can be there in 2010.

I have to admit that although I like video calls I haven't made one in quite a long time, mostly due to international video calls being prohibitively expensive and some network operators that still bar prepaid customers from receiving video calls. That severely limits my options… Anyway so for Christmas I called family and friends and some of them by now even have video call capable 3G phones. A very nice experience!

Despite many people arguing that video calling is a lost cause I still think it's a great opportunity for mobile network operators to offer a service only they can provide in a truly mobile and (almost) always-on fashion, at least for the moment. Don't get me wrong, I don't want all of my calls to be video calls but sometimes it would be very nice to get a video stream from the other side.

Unfortunately, there are still some significant hurdles to video calling even many years after the launch of 3G networks:

• 3G in-house coverage is still a big issue, especially for video calls. Femtos and UMTS on 900 MHz will help over time.

• As I said above, many network operators still limit video-calling to their post-paid subscribers. I can understand the notion of premium service and all, but after so many years I think it's time to open it up to all subscribers to create a critical mass.

• Pricing

• No interfaces to other video systems that are popular such as Skype

• No advertising around video-calls at all. Quite incredible and I wonder how many people are aware that they could actually make a video-call with their phone.

And while we are at it, it would also be nice to see someone implement features such as voice only at first and adding a video stream later or see-what-I-see on my phone.