WirelessMoves

A year ago I was musing over the fact that despite there being quite a number of phones today that can do SIP over Wi-Fi, non are Wide Band AMR capable for superior sound quality. Quite a waste as without network based transcoders between the two parties there's no legacy technology to overcome and implementation is straight forward. Looks like Nokia might have changed that without making a big fuss about it:

When I recently traced the Wi-Fi SIP interaction of my new Nokia E75 (for details how this is done see here), I noticed that it announces that it's WB-AMR capable in a SIP invite message. A closer look at Forum Nokia confirmed this. Unfortunately I am missing a counterpart to try it out with but that might just be a matter of time. While my SIP provider Sipgate puts a proxy in the speech path of every call, it is capable of different codecs, as I've seen both G.711 and AMR run over it. So with a bit of luck, WB-AMR might work as well. I'll keep you posted. In the meantime, here's the E75's Session Description part of the Invite message:

Session Initiation Protocol
    Request-Line: INVITE sip:+xxxxxxxxxxxxx@sipgate.de SIP/2.0
    Message Header
    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): xxxxx xxxxx xxxxx IN IP4 192.168.xxx.xxx
            Session Name (s): –
            Connection Information (c): IN IP4 192.168.xxx.xxx
            Time Description, active time (t): 0 0
            Media Description, name and address (m): audio 49152 RTP/AVP 100 96 0 8 97 18 98 13
            Media Attribute (a): sendrecv
            Media Attribute (a): rtpmap:100 AMR-WB/16000
            Media Attribute (a): ptime:20
            Media Attribute (a): maxptime:200
            Media Attribute (a): fmtp:100 mode-change-period=2; mode-change-neighbor=1
            Media Attribute (a): rtpmap:96 AMR/8000
            Media Attribute (a): fmtp:96 mode-set=0,1,2,3,4,5,6,7; mode-change-neighbor=1
            Media Attribute (a): rtpmap:0 PCMU/8000
            Media Attribute (a): rtpmap:8 PCMA/8000
            Media Attribute (a): rtpmap:97 iLBC/8000
            Media Attribute (a): rtpmap:18 G729/8000
            Media Attribute (a): fmtp:18 annexb=no
            Media Attribute (a): rtpmap:98 telephone-event/8000
            Media Attribute (a): fmtp:98 0-15
            Media Attribute (a): rtpmap:13 CN/8000

Dual Carrier HSDPA is in the 3GPP standards for some time now and in the mid-term we'll probably see it deployed. So where to go with HSPA next? Well, 3GPP RAN discusses 4 Carrier HSDPA spread over different frequency bands. That's for 3GPP Release 10 I suppose. The report from the recent RAN#59 meeting gives some interesting details in chapter 5.4:

• Adjacent and non-adjacent 5 MHz carriers in a single band (e.g. 2.1 GHz)

• Use of several bands. Band combinations suggested: I and VIII (2.1 GHz + 900 MHz, Europe), II and IV (1900 + 1700, US), I and V (2.1 GHz, Europe + 850 US [???])

• MIMO support depending on the capabilities of the UE in a band. This is an interesting as with this sentence it is assumed that a future UE could support MIMO only in some of the bands it supports.

Obviously that's a big new challenge for UE chip designers. While today the mobile can select an operating band and a suitable front-end, using several bands simultaneously will require the parallel use of hardware components. A tricky thing.  Comments from the RF community on this are greatly appreciated.

Nothings written into stone yet (eh, into the standards I mean) but this is where things are likely to go.

Oh, and I learnt of a new company name: Alcatel-Lucent Shanghai Bell. An interesting combination!

Today follows part 3 of my IPv6 crash course. You can find the first two parts here and here.

ARP Becomes Neighbor Detection

To translate layer 3 IP addresses into layer 2 MAC addresses, the Address Resolution Protocol (ARP) was used in IPv4. In IPv6 a similar mechanism is used and referred to as Neighbor Detection (ND). In addition the good practice in IPv4 networks to check if an IP address that was assigned is already used by someone else by sending an ARP message prior to using the IP address is now a feature in IPv6.

DHCPv6 and DNSv6

As discussed in the previous post, the IP auto-configuration functionality does not supply a DNS address to the host during startup so it can't translate domain names into IP addresses. Therefore, DHCPv6 is likely the means to get this information, potentially together with the IP address of the default gateway and further IP addresses for the interface.

The current DNS service also gets an IPv6 counterpart because it has to deliver IPv6 addresses for a request. While in DNSv4 an 'A' record query is used to translate a domain name to an IP address, DNSv6 uses AAAA records. The four 'A's stem from the fact that an IPv6 address has four times the size compared to an IPv4 address.

Routing

Routing pretty much works as in IPv4 but has been simplified as the network and host part is fixed in IPv6 compared to net masks of different lengths and classless inter domain routing (CIDR) in IPv4. 

Tunneling IPv6 over IPv4 and Vice Versa

Needless to say that IPv4 and IPv6 can coexist on the same interface. In most cases, however, networks only offer IPv4 today. To access IPv6 hosts from an IPv4 only network today, IPv6 over IPv4 tunnels can be used for the purpose. There are several different variants but I won't go into the details here.

IPv6 only networks could also exist in the future as well. Should it be necessary for a node in such a network to reach an IPv4 host, IPv4 over IPv6 tunnels exist as well.

Summary

So that's my crash course overview of IPv6 for now. Agreed, this is very very simplified but I think those are the main concepts you need to get your head around from an end device's point of view. Next stop: How IPv6 is integrated in 3GPP.

This week saw a number of interesting press announcements on first voice over LTE calls: First was the VOLGA forum who announced the first voice call between two LTE networks, one in Bonn Germany with a Kineto VOLGA Access Controller and the other one in Stuttgart, Germany where Alcatel-Lucent runs a LTE trial network on their campus. A great accomplishment given that the specifications were put together in record time and only released recently. It's not that surprising, though, as VOLGA is based on the already existing GAN (Generic Access Network) 3GPP standard that is used by a number of wireless network operators to offer Voice over Wi-Fi at home.

Next was Nokia Siemens networks who announced that they've done their first LTE voice call with the recently established One Voice Profile that describes which bits and pieces of the IP Multimedia Subsystem (IMS) should be used for voice calls over LTE. Also hardly surprising since IMS standards exist for many years now and IMS voice calls have been made with prototype devices over 3G and other IP based networks. So I guess this announcement was mainly a reaction to the VOLGA announcement.

So this was step one which now has to be followed by the most difficult step: integration. On the mobile side I am sure integrators of both systems can't wait to get an LTE smartphone into their hands. So far, only USB LTE sticks have been announced and here voice functionality is not of prime importance. But once LTE mobile devices such as smartphones become available we'll see who can integrate their solution better, quicker and, foremost, seamlessly with 2G and 3G circuit switched calling. After all, it should be absolutely transparent for the user over which air interface the mobile establishes the voice call. IMS based solutions have struggled for years to pull this off, so let's see, maybe the One Voice Profile will help to unite the supporters of IMS around a single set of features. For VOLGA, things might be a bit simpler as it re-uses much of what has already been developed for GAN and already implemented and used in a range of mobile devices today.

Perhaps even more challenging is the integration on the network side for IMS One Voice. While a standalone IMS system is quickly installed (relatively speaking), it's the interworking with the cirucit switched infrastructure to enable seamless handovers when running out of LTE coverage that makes life difficult. Also it is important that a user can be reached by the same means (i.e. same phone number) no matter whether he/she is currently connected to the IMS over 3G or 4G or just reachable via 2G and the circuit switched infrastructure. IMS Centralized Services (ICS) and Single Radio Voice Call Continuity (SR-VCC) have been specified in 3GPP for the purpose and I've reported and linked to the specs here. Specifications are one thing, complexity quite another. On the complexity scale, ICS and SR-VCC are at the upper end of the scale and require software updates in the circuit switched infrastructure.

For VOLGA, things are a bit simpler. No modifications in the existing infrastructure are necessary and only a single gateway node, the VOLGA Access Network Controller (VANC), is required for a full implementation. To the circuit switched Mobile Switching Center, the VANC just looks like a 2G Base Station Controller or a 3G Radio Network Controller. For the LTE side the VANC is just a server on an IP network. Pretty much a straight forward thing to do.

Both initiatives good luck on their way forward and I hope that once I hold the first LTE smarthphone in my hand I won't be thrown back to GSM for voice calls.

A number of sources have reported this week about a recent performance measurement study that puts 3G downlink speeds of Verizon and AT&T in a region between 245 – 645 kbit/s and uplink speeds between 106 – 305 kbit/s. Unfortunately I don't have a copy of the study to look at the details but official publications usually do not downplay performance. Having said this, these numbers are really puzzling to me because they are so far away from what I experience in 3G networks all over Europe.

Here are a number of specific examples: In Germany, I consistently get 3 MBit/s and beyond in several networks if coverage is good, no matter the location and time of day. Peak speeds are beyond 6 Mbit/s with my HSDPA Category 8 stick. And with HSUPA my uplink speeds are also well over 300 kbit/s. And this is by far not an exception, I've had similar experiences in other countries as well including Austria, where mobile broadband Internet access is very cheap and usage is accordingly.

And I am not alone with such numbers. Once a year, German telecommunication magazine “Connect” performs a test drive through all of Germany to measure voice quality in wireless networks, call drop rates and data throughput speeds. And they don't do it from a stationary location but from a driving car. And even under those conditions, they get average (!) 3G speeds in all German HSPA enabled networks of beyond 2 Mbit/s.

So why are the numbers so low in the US? It's not the technology and it can't be the iPhone either because almost everyone these days has one over here as well. So whether it's cell sizes that are to big, not enough carriers used, non-optimized radio engineering, insufficient backhaul capacity, core network congestion, etc., etc. it's difficult to tell from the outside. But there is ample proof that it can be done differently while still making a profit.

While doing some background research on LTE voice capacity I noticed there's a feature I haven't yet seen called Uplink TTI Bundling. At first the feature name reminded me of the packet bundling that is done in Wi-Fi, which concatenates several packets into one transmission burst thereby saving a lot of air interface overhead. TTI (Transmit Time Interval) Bundling, however, is quite the opposite as I found out when I had a closer look.

The purpose of TTI Bundling is to improve cell edge coverage and in-house reception for voice. When the base station detects that the mobile can't increase it's transmission power and reception is getting worse it can instruct the device to activate TTI bundling and send the same packet but with different error detection and correction bits in 2, 3 or even 4 consecutive transmit time intervals. The advantage over sending the packet in a single TTI and then detecting that it wasn't received correctly which in turn would lead to one or more retransmissions is that it saves a lot of signaling overhead. Latency is also reduced as no waiting time is required between the retransmissions. In case the bundle is not received correctly, it is repeated in the same way as an ordinary transmission of a packet. Holma and Toskala anticipate a 4dB cell edge gain for VoIP with this feature which is quite a lot. For details how the feature is implemented have a look at 3GPP TS 36.321.

… then have a look here.

It's good to prepare early for the Mobile World Congress in Barcelona in February 2010 as prices rise exponentially every year the closer it is to the beginning of the event. My plane tickets and the hotel are booked and I'm already today looking forward to the most intensive week in mobile of the year.

One of the events to attend is definitely the Mobile Premier Awards, organized by Rudy de Waele.

This year, the competition for the best mobile startups will have the following categories:

• MPA in Innovation – The best grassroots startup innovation chosen by their peers in partnership with MobileMonday. The MobileMonday chapters will vote for their local most innovative startup. An international jury of the most recognized mobile industry experts will select the 20 finalists from all the local chapter nominees to pitch at the event in Barcelona in front of investors, operators, media companies, peer entrepreneurs, and press and influential bloggers.

• MPA in Marketing – The best startup in Mobile Marketing

• MPA in Entertainment – The best startup in Mobile Entertainment
  in partnership with the Mobile Entertainment Forum

• MPA in User Experience – The best startup in Mobile User Experience
  in partnership with MEX.

• MPA in Social Change – The best startup using mobile for social change
  in partnership with MobileActive.org

• MPA in Female Entrepreneurship – The best woman-lead mobile startup
  in partnership with Women 2.0 and the Women in Mobile Data Association

So if you are a startup and want to participate, now's your chance to sign up!

One of the things learnt from todays UMTS air interface is that saving power during times when no data is transmitted is of foremost importance in the day and age of always-on applications and infrequent transmission of small quantities of data. Current HSPA networks are not really refined for this yet but help is on the way with a feature pack referred to as Continuous Packet Connectivity. See here, here and here for details. With LTE, power saving mechanisms are built in from day one. One of the most important of those will be Discontinuous Reception (DRX) while in Connected State, which I'll shortly describe in this post.

The general idea of this functionality is to allow the mobile device to periodically switch off its receiver for some time before it has to listen again to the control channel to see if the network has new data for the device. On and off times can be configured dynamically down to the sub-frame level (1ms) depending on the device's activity. Switching off the transciever for some time has a negative impact on latency so a two stage approach has been implemented.

When the network configures DRX for a device it defines the value for a timer that starts running after each data block has been sent. If new data is sent the timer is restarted. If still no data was sent when the timer expires the device enteres DRX mode with an (optional) short DRX cycle. This means it will go to sleep and wake up in a short pattern. If new data comes in it can thus be delivered quite quickly because the device only sleeps for short periods. The short DRX cycle mode also has a configurable timer attached and once it expires, i.e. no data was received during the short cycle mode the device implicitly enters the long DRX cycle which is much more power efficient but further increases latency time.

Final Note: Connected Mode DRX should not be mixed up with DRX in idle mode which the mobile is set into after a prolonged time of air interface inactivity. It's also known as paging DRX, i.e. the time the mobile device can go to sleep between two paging messages which could contain a command for the mobile to wake up again and change back to Connected state. This DRX is much less fine grained and measured in hundreds of milliseconds or even seconds.