What happened to 3GPP’s Earthquake and Tsunami Warning System?

Over the weekend, I wanted to take a closer look at the 3GPP Earthquake and Tsunami Warning System (ETWS) for GSM, UTMS and LTE. I was expecting to find proper stage 1, 2 and 3 documents in place by now so implementations could follow soon. It turns that of the three documents, only stage 1 (3GPP TS 22.168) has made it so far into Release 8. However, it seems that the specification might have been withdrawn at SP-43 in Biarritz in March 2009. 

The same applies for the stage 2 documentation 3GPP TS 23.168, it's current state is "withdrawn". There is a pointer to Technical Report (not a specification!) TR 23.828 which gives an overview of the different options analyzed and the proposal at the end to go for solution 5. Solution 5 would be to send a first warning to the mobiles via a special paging message with further details right afterwards in a cell broadcast message. For GSM mobiles already engaged in a voice call, the BTS would create a special SMS and sent it over the slow associated signaling channel while the call is in progress. In UMTS, paging messages can also be received during a call. What's not mentioned is how mobiles currently having a GPRS TBF established would receive the notification as there is no associated circuit switched signaling channel and pagings would not be received over the paging channel. But for the moment, that is beside the pont, since both stage 1 and stage 2 of the specification was withdrawn.

However, there is a link to 3GPP TS 22.268, a stage 1 specification for a much more generalized public warning system (PWS). No stage 2 specification exists so far, so this one is also at the beginning. It's an interesting document as it shows how much time there is to warn the public about an earthquake or a tsunami. Very challenging!

I am a bit puzzled!? Looks like ETWS was already quite well on it's way but now seems to be suddenly stopped? Did it fall short of the requirements? If you know more, please leave a comment below.

LTE: Default vs. Dedicated Bearer

One of the big changes brought about by LTE is that when the mobile device connects to the network it also implicitly gets an IP address. This is called "Default EPS Bearer Activation". What seems to be a trivial change at first is actually a whole new way of thinking compared GSM and UMTS.

In 2G and 3G systems, the mobile registers to the network first and in order to get an IP address, a "PDP context activation procedure" has to follow. This is also what is known as establishing a "packet call". I never very much liked the term "packet call" which was probably created because of the still mainly circuit switched thinking at the time. So with the default bearer activated right from the start, the "packet call" and all the legacy behind it has become history.

To build on the default bearer there is also a procedure in LTE called "Dedicated EPS Bearer Activation" which is initiated for the network. But what is it needed for, most people ask at first, the mobile already has an IP address!? True, the mobile already has an IP address but the default bearer comes without any quality of service guarantees. For VoIP, IMS, VoLGA and other real time streaming applications, it would be good to have some QoS, especially on the air interface. This ensures that the base station and other network components deliver IP packets for those applications with a higher priority. Also on the mobile side, such IP packets should get a higher priority than other packets, especially when the bandwidth is limited. And that's what is done with a dedicated bearer.

In the network, the dedicated bearer is connected to a Traffic Flow Template (TFT), a concept that already exists in GSM and UMTS. In this template, think of it as a list of ip addresses and tcp/udp port combinations, describes which IP packets should be given a higher priority. The TFT is also forwarded to the mobile during the dedicated bearer activation and it helps the protocol stack to put the IP packets to or from a specific TCP/UDP port and/or IP addresses into a special QoS queue that is treated with a higher priority.

No need for the mobile to have an extra IP address for this higher priority traffic, as the protocol stack uses the Traffic Flow Template information to decide what to do with each IP packet. In other words for those who are familiar with GSM and UMTS, a dedicated bearer activation is pretty similar to a Secondary PDP context activation in 2G and 3G that can be used by the IMS for example to ensure real time data is delivered promptly.

For the details have a look at 3GPP TS 24.301, chapter 6.4 and table 8.3.3.1 a bit further down for the message details.

Finding Dormant Cells

Having stayed a bit outside of Barcelona for a couple of days before the Mobile World Congress back in February, I ran across a phenomenon again that I call the "Dormant Cell" issue. While a "dormant" cell seems to be up and running for both the mobile devices and the RAN control center, it is somehow locked up internally and is not functioning properly. In my case outside Barcelona it was a UMTS cell and the signalling to establish an Internet connection worked just fine. However, subsequent data transfers did not work at all. A kilometer or so away things worked again as the mobile selected a different base station.

One would think operators would detect such cells quite quickly and reset them. However, it seems that in practice cells sometimes do not send alarms to the operation center so the personnel is oblivious to the issue. In my case the situation remained that way over three days. Now try to report such a behavior to the operator's first line support staff…

To catch such issues, some operators run statistical counter analysis like for example to compare daily data transmission volume per cell. If suddenly a cell shows abnormally low values the analysis program generates an alarm so the network operation center can take a closer look. Unfortunately, not everyone seems to do that or at least not very often, like the operator of the network I used in Spain.

Agreed, it's quite a number crunching effort when you have several thousands of cells in your network and requires a big database to compare current counter values against those measured in the past. But benefits of such analysis go far beyond just finding dormant cells. This way, it's also possible, to give just one example, to follow rising use of certain cells in your network and to predict when it will run out of capacity. That way the network can be upgraded before the cell runs into saturation. The principle does not only apply for Internet access but also for voice calls.

I picked the Barcelona incident to start the post but quite frankly, it is not the first time I've seen such behavior and not only in a single country. Looks like this is a general phenomenon experienced not only with a single RAN vendor.

The Making of the N97

O.k., I'll play along with Nokia marketing for the N97 today for three reasons:

  • I can't wait for the N97 to be launched so I can finally get one after months and months of waiting.
  • I hope they made good use of the time and have a usable firmware version by now.
  • I like the N97 "making of" video embedded below. O.k., it's marketing, but well done and it reflects my passion for mobile communication.

Nuff said, here's the video, switch to HD, full screen and enjoy!

Telecom and the Green Planet

Greentv Over at TelcomTV, a video series has been started on the impact of the Information and Telecommunication Industry on CO2 emissions, energy consumption and how to reduce the impact as we go forward. One episode is published per week together with lots of background information. A very interesting project sponsored by Ericsson and Juniper and I'll be surely watching it over the coming weeks. There's also an RSS feed on the page so you don't have to remember going back to the page once a week for the latest update.

When Do We Stop Writing On Our Hands?

Recently, I observed somebody in the city with an iPhone how he was reading something on the screen copying some of the content, maybe a phone number, with a pen onto the skin of his hand. Wow, we've really come far, we have smartphones, we have big screens, we have touch, but people still need to use a pen to write something on their hand or on a piece of paper in order to remember it!? That doesn't seem right.

But it's not only iPhones, I am doing the same every now and then with my Nokia phone, too, because sometimes it's either not possible or too complicated to copy and paste data from one application to another, e.g. from the web browser straight into an e-mail or into the notes application.

Examples:

  • I can't copy text from a web page from Opera Mini into an e-mail. Same with links. If I want to do that I have to click on the link first so the page is loaded, pretend to save it as a bookmark, mark the URL in the new window and hit the copy button. Then I have to cancel the bookmarking action, go the the e-mail program and insert it. Not impossible but way to complicated.
  • The other way around is equally difficult: I can't directly start Opera Mini from an eMail when I click on a link. This always starts the built in browser and not Opera Mini. So to circumvent the problem I click on reply in the e-mail program, scroll down to the link, mark and copy it, open Opera Mini and past the URL. Again, way too complicated.
  • Now try it for yourself and copy/paste a phone number from the address book to the 3rd party e-mail program on your phone…

On the PC, these tasks are much easier to accomplish. So how hard can it be to make this work in a more convenient way on smartphones, too?

Book Review: LTE and the Evolution to 4G Wireless

Book-moray-final It seems my blog is one of the few places on the web where you can find reviews on books about wireless technology. So today, I want to continue with a great book from Moray Rumney about "LTE and the Evolution to 4G Wireless".

I've known Moray for a while now and his down to earth view on where the wireless industry is moving, or rather to where it should be moving, have had an impact on my own thinking over time and I am very grateful for that. Therefore I am especially pleased that Moray has completed his work on the book.

The book title already tells a lot of what the book is about and after a long bus ride through the English countryside and a couple of plane trips I am now halfway through and have learnt so much already that it is difficult to put it down. Expect a couple of blog posts on some very technical topics based on what I have found in the book soon.

In the first part of the book a solid introduction is given on LTE starting with the ideas behind the air interface, the new physical layer including a close look at the physics behind it, the channel structure, radio resource signaling, higher layer signaling, the new core network, etc. etc. Very impressive and much much more readable than the standard documents! For those with appetite for more, each chapter lists the standard documents it is based on. Invaluable pointers!

The second part of the book then focuses on design and verification challenges and conformance testing. I have to admit my knowledge about the physical layer does not go much farther than understanding the basic concepts so I always wondered how first mobiles and base stations can be developed without each other and tested against the standard. So even though the second part of the book is though for me to read due to my limited knowledge in that domain it is nevertheless very worthwhile as my understanding and feeling for the technology grows with every page.

The final chapter of the book then discusses LTE-Advanced and the potential improvements that could be made on LTE, a system that is not yet even rolled out. Beyond only listing potential areas of work, Moray also explains where the difficulties and pitfalls lie in extending a system that already pushes the limits quite far today.

With all the details included in the book it's difficult to do it alone. The co-author lists is the most extensive I have seen so far, it's over 30 names and short-bios. So expect ultra-precise knowledge on each topic!

By now it's probably obvious that I can fully recommend the book. In case you give it a go, have fun reading it!

Multitasking on the Bicycle

As a tech-savvy person I used to carry a lot of gadgets when going on a bicycle ride for fun: A mobile phone, a photo camera, a paper map, a GPS, an MP3 player and a PDA to surf the Internet and to check my e-mail. Yes, I know what you want to say now, that was a couple of years ago (but not too many ago when you think about it) and today, all these devices have shrunken into a single smartphone.

It's a strange feeling, my backpack is now almost empty with only my N95, the sun glasses, the door key and some money in it. And who knows, the door key and the money might just be included in the mobile phone in a couple of years as well with an RFID chip for mobile payment and a Bluetooth solution to open my apartment door.

It's amazing how many things the phone now does simultaneously while being in my pocket:

  • It runs the MP3 and podcast player so I am entertained while enjoying the ride
  • The camera application is always ready and while I take a picture, all other applications keep running in the background
  • Nokia Sports Tracker runs in the background and uses the GPS chip to record the trip and upload my position in real time to the Internet. Once back home the program looks for pictures I have taken during the ride and the songs I have listened to and uploads them as well. For example, here's the data from the bike trip I reflect on in this post.
  • I've uploaded some of the pictures I have taken in full resolution to Flickr with the help of Shozu on the phone, which also accesses the GPS information to geo-tag the pictures. To save cost, I've configured Shozu to only upload the pictures when it detects my Wi-Fi network at home. No manual intervention necessary.
  • In the pictures you might have noticed a little camouflaged box. That's a geocache which I found with the help of a Geocaching application using the GPS chip in the phone. An interesting and healthy hide and seek game and sometimes motivation not to stay at home sticking my nose into books or working on new projects.
  • In case I get lost, I can fire up Nokia Maps which also uses the GPS chip. Note that all programs can access the location data simultaneously. Very nice!
  • Needless to say that my e-mail program (Profimail) was also running in the background to alert me of incoming mail.
  • And for the quick information fix, Opera Mini is by default always lingerning in the background. Very helpful to get quick information from Wikipedia, often replacing the tourist guide on paper.
  • And everyone of course takes for granted that incoming voice calls and text messages are also treated. That's two separate tasks running in the background as well.

With all of these things running, the impact on the battery is quite significant. After four or five hours the battery is empty. So for longer trips, that spare battery adds a couple of grams to the weight of the backpack. Acceptable I would say.

So what else could be improved in the future? While the N95 8GB already has quite a big screen, I think I am ready now for the higher resolution and size of the screen of the N97. Hello Nokia, how long do we still have to wait? Also, the touch screen should be great for some applications like the built in web browser, which in itself can still be improved. There are still some pages I don't go to on the mobile because they take too long to load because the processor is not powerful enough to render them as quickly as on the PC. A higher capacity battery at the same size and weight of today would obviously also be good. On the software side I am waiting for that geo-info application that lets me take a picture of something, combines it with the GPS coordinates, goes to the Internet and comes back with a Wikipedia entry on it. Nokia's CTO has mused about such a program in the past but so far I haven't seen one.

So, what's missing for you when you take your smartphone for a walk or a bike ride?

Twitter for Instant Presentation Feedback

During the recent Future Technology Conference at the University of Oxford, I found a new personal application for Twitter:

Quite a number of people including me were twittering during the conference and either used a notebook or smartphone to virtually comment on the presentations and to seek the opinion of others. After my own presentation and Q&A session I noticed that the twittering during my session resulted in excellent feedback on my own presentation and served as a good starting point to engage people afterwards in the real world to continue the discussion.

Cool stuff!

Verizon’s first Draft Specification for LTE Devices

Unstrung has an interesting pointer to Verizon's first draft spec (v0.9) which details what they want devices to be capable of to allow them on their future LTE network. While they are mainly referring to relevant 3GPP specification documents, there are some nuggets of information in there that took my attention:

  • The 700 MHz band they intend to use seems to be band 13 in 3GPP talk. I wonder if that encompasses the complete 700 MHz band in the US or just a part for it!? In other words, will band 13 devices also be usable in other LTE networks (e.g. that of AT&T)? According to this post on Gigaohm, the total bandwidth of the 700 MHz that was auctioned off was 18 MHz per direction (uplink/downlink), so the answer is probably yes.
  • The channel bandwidth they will use: 10 MHz (double that of HSPA today but short of the theoretically possible 20 MHz as per the standard. Again, by looking at the link above, that's obvious because that's all there is available.
  • Devices must have RF connectors for testing purposes for all antennas. Haven't seen that in years on mobile devices. RF designers will have fun…
  • Devices will be assigned an IPv6 address when attaching to the network. IPv4 addresses shall be requested by the device if an application requests an IPv4 connection. The IPv4 address shall be released once no applications are executed on the device that require it. Interesting requirement, looks like an IPv4 address is not initially assigned to the mobile device by the network. This should not be a big deal, S60 for example already has a dual IPv4/IPv6 stack today.
  • Mobile device timer for moving from Connected to Idle state: The document says that the LTE standards say that the move from Connected to Idle state (on the radio layer, this has nothing to do with the IP address assignment) is controlled by the network. The standard leaves it open for the mobile to also initiate such a state change, for example if the device detects (by whatever means) that no applications currently wants to send and receive data. At this point, however, Verizon does not mandate devices to implement this. An interesting side note: Today, HSPA only knows a network initiated state change in the standards. In practice, however, there seem to be some devices that also trigger it from the devices side with a bit of an unorthodox signalling message exchange. Looks like standards people have learnt from that and included this feature in the LTE specs from day one.
  • No mention is made of dual mode CDMA/LTE capabilities. I wonder if that means that they expect that first devices will be LTE only? That wouldn't make a lot of sense to me. I can't imagine people would be very happy using a CDMA USB dongle and a separate LTE dongle, depending on where they are.
  • Verizon expects that first devices are data only, no voice capabilities. A pity, but who knows, they might yet discover the benefits of VOLGA.

Note that the current version is only a draft, there are still many unfinished chapters.