The Nokia 6300i and VoIP over Wifi

Back in April this year, Nokia announced the 6300i that comes with Wifi and VoIP (but no 3G support). At the time, it was not quite certain from the press release what kind of VoIP the phone would offer. Now that the mobile is available, the user guide gives further details on page 30. The word SIP is never used but based on the configuration information, it certainly looks like SIP like on the Nseries phones and not like UMA. For UMA, the 6300i seems to have a brother, the 6301. Together with Firmware Over the Air (FOTA) update capability, and Opera Mini coming pre-installed, it looks like Nokia has started an interesting test balloon in the sub 200 euro category (Amazon Germany has it for 179 euros, taxes and shipping included!). I'd really like to try the VoIP implementation. I wonder if it is as good as that of the N95? Or maybe even better?

LTE Air Interface Primer

It's good to see whitepapers coming out from different companies taking a closer look at LTE. Lots of interesting material can be found at Agilent's LTE Network Testing web page. I especially like the LTE (Air Interface) introduction webcast and the LTE System Overview whitepaper.

Although I am already aware of many things discussed in the paper, its always good to read about things from an author that looks at the topic from a different perspective. Here are a few of the things I found outstanding (for me personally) in the whitepaper:

Good Air Interface Graphics: The paper has some awesome graphics on how the physical channels map onto the different sub-carriers (or more precisely resource blocks). It's interesting to note that the control channels can take up to 30% of the cell capacity in case lots of devices require to be scheduled (e.g. Figure 23). That's quite a lot of capacity wasted for signaling. I guess we have to wait and see if in practice that much signaling capacity is really required.

Fractional Frequency Re-use: To improve cell edge performance the paper mentions the use of only a fraction of the sub-carriers to be broadcast at higher power levels. I've written about this quite some time ago and it's good to finally see some papers who are going into this direction as well.

BCCH: Broadcast once every 10ms (one frame) around the center frequency.

HARQ ACK/NACK: Contains intereresting details on where, when and how the acknowledgments are sent in uplink and downlink direction.

Nokia N79 and N85 UMTS Band Options

It’s good to see Nokia presenting two new Nseries models yesterday. While I leave it to others to report on all the multimedia details, I was intrigued that both devices support several UMTS frequency bands, a first for Nseries devices.

The N85 has the most wide ranging UMTS band support. According to the datasheet, there will be two versions: The first one supports UMTS in the 900/1900/2100 MHz and is thus clearly targeted at Europe and the starting deployments of UMTS in the 900 MHz band in addition to the 2100 MHz band. The 1900 MHz band is at least partly usable in the US, where AT&T has deployed UMTS in some cities. The second version supports 850/1900/2100 and is probably mainly targeted at the US since AT&T uses both frequencies. Too bad it doesn’t support all four bands, it would make a great world band phone that way.

But despite the support of three UMTS bands there are some combinations which don’t work so well: For Australia, both models are needed since Telstra uses the 850 MHz band for 3G and Optus deploys 3G in the 900 and 2100 MHz bands. So should both operators sell the phone in the future they will each sell a different version.

Some people in Europe might actaully prefer the US version of the phone as there are only few places where 3G is deployed in the 900 MHz band yet and they might thus benefit more from the 850 MHz band when roaming in the US (e.g. with an AT&T prepaid card for Internet access). Bizare… Also interesting is that T-Mobile US won’t be able to sell the phone since it doesn’t support the AWS 1700/2100 MHz band.

The N79 seems to support 900/2100 MHz for now, so clearly targeted at Euope and potentially Optus in Australia. I wouldn’t be surprised though to see a 850/2100 MHz version soon.

Well done, Nokia, it was really time to add multi band 3G suport to Nseries, especially for roamers like me!

CS Voice (And Other Services) over LTE

I've been speculating recently how voice calls could work in next generation 3GPP LTE networks. The politically and technically foreseen way is IMS, the IP Multimedia Subsystem, and a service platform running on top of IMS such as the IMS Centralized Services (ICS). ICS is quite promising as it includes a solution to bring GSM only handsets without any IMS extensions into an overall voice solution and can hand-over voice calls from LTE to GSM when leaving the coverage area. The major drawback of ICS is its complexity and its anyone's guess when we will see this in mobile devices for the general public.

In the meantime, there has been some support in 3GPP to investigate a different solution: How to extend the current circuit switched voice service of GSM to LTE. In 3GPP a number of companies started writing some proposals, which were gathered in 3GPP TR 23.879. In this paper, the main proposal is to connect the Media Gateway part of the Circuit Switched Mobile Switching Center (MSC) to the packet core and give the the MSC Server direct access to the Mobility Management (MME) Entity of the Access Gateway to the LTE Radio network.

This approach completely circumvents the IMS and reuses all upper signaling protocols already known from GSM. Only the lower protocol layers are replaced by TCP/IP. For the voice call itself, all higher layers of the voice transmission protocol are foreseen in the technical report to be kept, while the lower layers would be replaced by TCP/UDP/RTP between the mobile device and the MSC's media gateway.

Handovers would be supported via the interface between the LTE Access Gateway and the evolved MSC (eMSC). When the base station signals that a handover to a 2G GSM cell is required, the Access Gateway informs the evolved MSC via this interface of the handover and the intended target cell. The eMSC can then prepare a circuit switched channel in the 2G or 3G network and respond to the LTE Access Gateway with the necessary details which are then given to the mobile device by the base station in the handover command.

From a development point of view such an approach is much simpler than installing a full IMS system and put ICS on top. Also, all services available today, including SMS, are instantly available, without any further development.

Here are the main developments that I think would be required for such a solution:

  • Mobile device: The stack for voice telephony must be enhanced to put the signaling and voice data a packet switched connection while the device is attached to LTE. Also, the handover code must be enhance to not only support 2G to 2G, 3G to 2G, 2G to 3G handovers but also 4G to 2G or 3G and vice versa.
  • LTE Base station: The software needs a small enhancement to transparently forward the CS handover information it receives from the Access Gateway to the mobile device.
  • LTE Access Gateway: The MME in the Access Gateway needs to be enhanced to report a handover to the eMSC and to wait with the handover until the eMSC gives the go-ahead. Also, it would have to forward a transparent data container with information about the resources allocated in the circuit switched network to the mobile device.
  • MSC: Would have to be enhanced to communicate via DTAP over IP (instead of ATM, IuCS, BSSMAP and BSSAP) and to perform handovers from 4G to 3G or 2G and vice versa. Further, instead of assigning circuit switched traffic channels it would have to interact with the packet core to assign the correct QoS attributes which will ensure a smooth call and sets the scene for the MME to signal a 2G handover to the eMSC.

For further details, including how to deal with roaming subscribers, have a look at the technical report.

All in all, I would say that the enhancements required for 4G handovers are far less complicated than those required at the time to implement 3G to 2G handovers when UMTS was specified. 

From a technical point of view, this architecture has the drawback that voice calls to mobile clients would continue to use a protocol other than SIP, which is the dominant protocol in the fixed line VoIP world. The MSC and the Media Gateway would in effect act as a signaling protocol converter and, in case the call is handed over to a circuit switched 2G connection, as a voice codec transcoding function. Considering the comparatively small enhancements required in the handset and the newtork compared to a full IMS/ICS solution, this architectural imperfection could well be worth it.

From an IMS/ICS point of view the proposed solution looks of course "stone age". It would only support voice calls, i.e. no multimedia sessions, would not support several devices per account, no sessions, no instant messaging, you name it, just pure and simple voice and SMS (but with all the supplementary services that have been developed over the past 30 years!).

BUT: Due to its handover capabilities to 2G GSM and and seamless use over 2G, 3G and 4G networks, it might be the killer VoIP solution for operators to beat Internet based VoIP services (think Skype, etc) which are also pushing into wireless networks and devices today.

Strangely enough, the current work plan lists the technical report as "moved to Release 9" (look for "FS on CS Domain Services over evolved PS access"). I am not sure what that means but it sounds like it didn't meet the love of enough companies represented in 3GPP.

Nokia Research Center on Impact of Keep-Alive Messaging on Power Consumption

With always on applications (think mobile eMail, IM, VoIP, etc.) on wireless devices, power consumption inevitably increases due to the constant exchange of TCP and UDP keep-alive messages to keep NAT firewalls open. Gone are the days in which wireless devices only communicated when there was really something to say. Pasi Eronen of the Nokia Research Center has taken a closer look at the issue and has measured and compared the impact of keep-alive messaging in 2G, 3G, 3.5G and Wifi networks. In the second part of the paper, Pasi then takes a look at how current VPN
security products could be enhanced to avoid frequent UDP keep-alive
messaging and thus increase the operating time of mobile devices. An interesting read, highly recommended!

Some of the findings:

  • NAT timeouts for UDP are anywhere between 30 and 180 seconds
  • NAT timeouts for TCP is anywhere between 30 and 60 minutes
  • Sending a keep-alive packet every 20s increases power consumption by a factor of 10 and more
  • The paper suggests that VPN products use a TCP connection to reestablish the UDP connection used for encrypted packets after a long timeout instead of sending frequent UDP keep-alives. Works well as long as no IM or VoIP client uses the VPN tunnel.

O2 Germany Doesn’t Care About APNs Anymore

Teltarif reported recently that O2 Germany have now configured their packet core to accept any kind of Access Point Name (APN) configuration of the mobile to activate a default Internet connection. According to O2 this will make it easier for customers to use the mobile Internet as configuring the mobile is simplified.

However, the article also mentions the bad side of this move: In the past, a non- or wrongly configured APN prevented accidental use. Now if the user forgets to lock his mobile before tugging it away in his pocket and that "@" key gets pressed, O2 happily starts charging. It already happened to me a couple of times under different circumstances. Especially nice when you are abroad…

So despite their probably good intentions I am a bit sceptical that this is a good move for consumers. From my point of view it's not the APN configuration that keeps people from trying the mobile Internet but the inadequate standard pricing many operators still have in place.

Being Really Always-On

Screenshot0041_2_really_always_on
Most of the time, I am almost always-on with one device or another, which means the device has an IP address only for the time I use an application. A couple of hours is usually the longest time since once I come home, my Wifi network takes over and my N95 starts using the home network. In the past, I have tried how long I could stay online with the mobile before the connection with the wireless network (the PDP context) is dropped. And there are many reasons for "packet call drops": Mobile resets, application crashes, network resets, network not configured correctly for Inter-SGSN routing area updates, you name it. So there are many causes for the connection to drop at some point and to be reestablished. So beyond a couple of hours to a day was usually the max. These days, things have much improved. In my latest test, I've been always-on with my N95 for almost 5 days. Take a look at the picture on the left. The last screenshot I took shows the packet data connection online counter at 4 days 19 hours and 47 minutes. That's what I call really always online 🙂 BTW: The network under test was that of T-Mobile Germany. Let's see if they can keep up this reliability once they roll in new equipment…

IMS Centralized Services (ICS)

Interesting to see which 3GPP Release 8 work items around the IP Multimedia Subsystem (IMS) are bearing fruit these days. While in Release 7, the hot application specifications for IMS services were Multi Media Telephony (MMTel) and device centric Voice Call Continuity (VCC), work in Release 8 seems to have to have shifted towards IMS Centralized Services (ICS) and a network centric Voice Call Continuity.

As the name implies, ICS offers centralized services, which means an IMS Application Server for ICS manages sessions for a user in several respects:

Multiple Devices – Several devices can be associated to the same user account and can be active simultaneously. Incoming media sessions can then be forwarded to one, several or all of these devices. Devices can be switched during ongoing sessions.

Including GSM mobiles – ICS has been designed not only to work with IP/IMS devices but also with "legacy" GSM  phones without any special software on board. When mobiles are switched on the MSC server communicates with the ICS Application Server (the Service Centralization and Continuity Application Server SCC AS) on behalf of the mobile. This is done either directly, in case the MSC server has been enhanced to act as an IMS client for the mobile, or via an Intelligent Network (IN) node that communicates with the MSC Server via CAP (CAMEL Application Part). The later one is probably preferred by many suppliers since IN nodes and CAP are used today for many applications such as prepaid billing. This has the advantage that the MSC software does not have to be extended for ICS.

Managing Supplementary Services – The ICS offers a standardized way of implementing services such as call forwarding, barring, hold, resume, 3-way calling.

Combination of Different Types of Media– ICS is not limited to voice telephony. Video calling, picture sharing and other media streams can be added or removed from a session at any time. 

Handover to 2G – And finally, the 3GPP ICS working group has also thought about how to hand over the voice portion of a session to a circuit switched bearer when the mobile reaches the limit of the broadband wireless networks. Currently, handovers from LTE are supported to GSM and 1xCDMA (hello Verizon!). Unlike the previous Voice Call Continuity (VCC) specification which requires the handover decision to be made by the mobile, the ICS handover to a circuit switched channel is network initiated and controlled. The advantage of network control is that the device does not have to be attached to two different radio networks simultaneously. This is important since like GSM/UMTS mobiles today, future LTE mobiles will also not be able to connect to two cellular network technologies simultaneously. From my point of view this network centric Single Radio Voice Call Continuity (SR VCC) approach is a major step towards solving the LTE voice gap. I'll describe the details in a future post.

For further information, here are links to the three main ICS specifications:

And for some more general background reading, here are some more resources:

Moving To A 2 SIM Strategy

In the past I have usually used at least one SIM card for voice telephony and a separate one for Internet access. I never liked this approach very much and always looked for ways to combine the two. These days, combined voice and data offers on a single SIM have improved so I've been using my Nokia N95 for voice telephony, Internet access directly form the phone and as a modem for notebook Internet access over the past couple of weeks now. Interestingly enough, it turns out that the combined SIM is not as convenient as I always thought.

There are a number of reasons:

  • When a voice call comes I have the option to remove the cable from the phone or to have my movement restricted by the cable while being on the phone. Both feel uncomfortable as I don't want to loose the Internet connection while I am on the phone but also often don't want to remain in front of the computer.
  • During phone calls, the connection is often handed over from the 3G network to 2G network. This cuts the Internet connection since most GSM networks are still not Dual Transfer Mode (DTM) capable. This can be fixed by locking the phone into 3G only mode. This has the disadvantage, however, that I have to reset the network mode later when I am on the move again as 3G network coverage is still not in all places where 2G coverage can be found.
  • Unlike others, Nokia mobiles still don't charge over the USB cable. Thus, the battery drains very quickly if no power socket is available, which is usually the case at airports and other public places. 

Bluetooth might be an alternative for the USB cable. The power cable would still be required but that can be disconnected easly for a phone call. For now, version 2.x with it's theoretical top speed of around 2-3 MBit/s is still fast enough for most HSPA connections. With HSPA speeds continuously rising, that won't hold for much longer.