WirelessMoves

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.

This post is the continuation of my crash course on IPv6. You might want to check out part 1 here before continuing.

Auto-Configuration, Local Addresses and Router Advertisements

IPv6 has auto-configuration functionality built that doesn't require a configuration server in the network as in IPv4. When the stack is started, the first thing it does is generate a local IP address that starts with fe80 as described above. Marc Blanchet describes how the 64 bit host part of the IP address are generated from the 48 bit MAC address of the adapter or a random number. I couldn't observe that on my Windows Vista machine, however, they might go for the random number and not the MAC address.

Another new functionality in IPv6 are router advertisements. This way, devices in the network automatically learn of routers in the network and which other networks can be reached via them. A router can also define itself as a default gateway. If a node finds a default gateway it will send all packets not destined for the local network to the default gateway router.

As link local addresses can't be used to communicate with hosts outside the local network, routers also advertise the information required for a host to automatically configure a global IP address that can be used to communicate with hosts on the other side of this router. As a consequence, interfaces of a host configured for IPv6 usually have at least two IP addresses: A link local address and a a global unicast address. This is different to IPv4 where each interface usually has only one IP address. A side note: While a single IP address per interface is the default in IPv4 it's still possible to configure several IP addresses on an interface with different subnet masks and gateways. This, however it the exception rather than the norm.

Since subnets have 2^64 addressable hosts, routing on layer 3 in branch networks such as companies is no longer necessary. In practice, however, some logical and physical separation on layer 3 might be desired. For this, local IP addresses can be on-net and off-net. In case a local address is off-net a node sends packets to a bridge device.

One thing that is not auto-configured is the DNS (Domain Name System) server's IP address. This server is required to translate a domain name (e.g. www.wirelessmoves.com) into an IP address. That's a pity because in practice this means that auto-configuration is incomplete and the DNS server's IP address has to be acquired by some other means, typically via DHCP. More on that in the next post.

There we go, this is the end of part 2, more coming up in the next post.

Yes, I am a great fan of Opera Mini and I'm delighted to report that they are moving forward and have made a beta of version 5 for download. It looks like Opera has updated the user interface primarily for touch displays and it indeed looks much sleeker than the previous versions. Well done indeed, I like the looks of the new user interface very much!

However, there are a couple of changes that I don't like a lot which I think Opera should think about again:

First, the beta 2 needlessly deteriorates the browsing experience on non-touch devices and I happen to use one of those (with a Nokia E75). First, the current beta no longer seems to allow scrolling through a page with the 4-way key, only the keypad (2, 4, 6 and 8) can be used. That's really a let down since the 4-way key is much more conveniently located for the thumb than than the keypad on most devices.

Second point: The vertical scrollbar is hidden after a couple of seconds which makes it difficult to judge of how much more text there is further down until you scroll down some more. Once could argue that it's good enough to see how much of the page is left when scrolling but for me it doesn't quite work like that.

And third: I really had trouble finding the menu entry for synchronizing my bookmarks. Equally, it took me ages to find out how to change the shortcuts that can be reached via the # key or, if you have a touch device, via the pictures on the main screen. Touch device users would have probably found it much quicker as it's normal to just touch a shortcut icon with the finger, keep it pressed and wait until a context menu pops-up. When navigating by keys that's not really obvious.

All these things are simple to fix and I hope Opera makes those little adjustments before releasing the final version. And just in case they don't, I'll tuck away a copy of Opera Mini 4 in case I need to reinstall it.

Thanks to IntoMobile and Stefan Constantinescu, saw it there first!

IPv6 has been 'just around the corner' for many years now but hasn't really surfaced so far. For LTE, Verizon currently plans to make IPv6 mandatory and IPv4 optional, which will probably mean in practice that the first thing most devices will do is to get an IPv4 address. One way or the other, however, IPv6 will show up one day and I've been wanting to have a look at it for many years now. So I decided to picked up "Migrating to IPv6" from Marc Blanchet to do a little crash course.

The book is quite massive and you could probably spend weeks absorbing all the details. For my purposes, however, getting the basics is just enough for now so I know how things work in general compared to IPv4. So I skimmed through the chapters relevant for me and here are the most important details which will be important to remember:

128 Bit Addresses

The first big thing that most people know about IPv6 is that the IP addresses are getting longer to fix the issue with v4 addresses slowly running out these days. While IPv4 had 32 bit addresses (e.g. 10.124.30.2), IPv6 uses 128 bit addresses and uses a different notation (e.g. 3ffe:20e3:4000:abcd:0102:9988:7766:0001) which looks quite different and complicated at first if you are accustomed to IPv4 addresses. Addresses starting with fe80are link local addresses, i.e. they are not routed beyond the local network borders. IP addresses starting with 2000 to 3fff are global unicast addresses that can be used to reach any server worldwide that is connected to the IPv6 Internet.

In IPv4 there's a subnet mask that defines which part of the IP address describes the network part and which part identifies the hosts in a network. This is necessary to have the flexibility to be able to address both small and large local networks despite the limited address range. In IPv6, things are much more static and simple, a luxury of the 128 bit address range. A local network always gets the lower 64 bits assigned to address hosts. Wow, that's twice as much as all of the current IPv4 32 bit address space. The upper 64 bits are used for routing. Out of those, 48 bits are used for global routing and 16 bits are used within ISPs to serve their clients. With 16 bits, each ISP can serve 65535 clients that can then each have 2^64 hosts. That should last for a while. What is known as a subnet mask in IPv4 becomes the network prefix in IPv6 which is (almost) always 64 bits as described above.

The downside of 128 bit addresses is that the IPv6 header is significantly longer than the original IPv4 header. IP header compression will therefore become very important in wireless networks to minimize the waste of bandwidth.

Optional Headers

Many IPv4 header fields are not always used today and for IPv6 it was decided to move them into optional extension headers. If there's a need for them, they are appended, otherwise they are left off. ICMP for example (see below) is put into an extension header.

That's it for part 1. More in part 2 which is coming up soon.

I like CTOs who have a vision that goes beyond what might or might not be possible in the immediate future. One of those is definitely my ex-boss John Roese who's come up with two blog posts on how the future of communications could/should look like (see here and here). His approach is interesting: Let's stop thinking about how the technology we have today enables us to communicate. Rather, take a step back an think about how it should be or how you would like it to be without regard as to how that could be implemented with today's or tomorrow's technology you might be aware of. Two truly thought provoking blog entries, highly recommended!

A technical post today – Here's some background info on how users are scheduled on the LTE air interface:

Dynamic Scheduling

In most cases, scheduling will be fully dynamic. In downlink direction resources are assigned when data is available. For data to be sent in the uplink, the mobile dynamically requests transmission opportunities whenever data arrives in the mobile's uplink buffer. Information about data being sent in downlink direction and uplink transmission opportunities are carried in the radio layer control channel which is sent at the beginning of each sub-frame.

Semi-Persistent Scheduling

While dynamic scheduling is great for bursty, infrequent and bandwidth consuming data transmissions (e.g. web surfing, video streaming, emails) it is less suited for real time streaming applications such as voice calls. Here, data is sent in short bursts while at regular intervals. If the data rate of the stream is very low, as is the case for voice calls, the overhead of the scheduling messages is very high as only little data is sent for each scheduling message. 

The solution for this is semi-persistent scheduling. Instead of scheduling each uplink or downlink transmission, a transmission pattern is defined instead of single opportunities. This significantly reduces the scheduling assignment overhead.

During silence periods todays wireless voice codecs stop transmitting voice data and only send silence description information with much longer time intervals in between. During those silence times the persistent scheduling can be switched-off which is probably why it's called semi-persistent scheduling. In the uplink, the semi-persistent grant scheme is implicitly canceled if no data is sent for a network configured number of empty uplink transmission opportunities (see 3GPP TS 36.321, chapter 5.10). In downlink direction, semi-persistent scheduling is canceled with an RRC message.

The logical question that follows now is how the network can figure out when and for which packets to use semi-persistent scheduling. The answer is QCI and dedicated bearers. More about that in a follow up post.