Category: Uncategorized

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.

I've been running my 802.11n capable Fritzbox only on the older and slower 11g standard so far due to the lack of a notebook or other equipment being able to do anything faster . Also, with a sub 10 MBit/s DSL connection you don't really need more anyway. But now with a new notebook and a 25 MBit/s VDSL line to be installed, things have changed. So it's time now to do some performance measurements.

Here's the baseline: The Wi-Fi access point is in an adjacent room from the office and iPerf gives me a 802.11g throughput of around 21 MBit/s both in the office and also when I move close to the access point. The iperf server was running on a computer connected by Ethernet cable to the access point. That's pretty much the top speed for this version for the standard that can be reached in practice. On the client side I was using a notebook with an Intel 5100 AGN wireless chipset.

When both the iperf server and client machines were connected to the access point via an Ethernet cable, tops speeds reached 90 MBit/s, that's about the top speed of a 100 MBit/s twisted pair Ethernet connector. That's important to remember.

Next, I switched on the 802.11n capability in the Wi-Fi access point and switched to WPA2 encryption as the somewhat older access point chipset only runs 11n which this encryption. I also configured it for a 40 MHz channel, which is twice as wide as the channel used by the older 802.11g standard. 

For the first test, I operated the access point in the standard 2.4 GHz band. Tops speeds were around 70 MBit/s, again both in the office and close to the router in uplink and downlink direction. During the transmission, the status window on the notebook showed a link speed of 135 – 150 MBit/s. At this point I thought that was not too bad.

For the next test I switched to the 5.8 GHz band as it's supposed to be less crowded and the neighbor search on the access point showed no other base stations in sight. Close to the access point I was also able to get 70 MBit/s. In the office, however, the top speed dropped down to only 30 MBit/s!? So either the higher frequency range couldn't handle the wall and additional distance, or the antennas in the notebook or access point were not optimized for this frequency band. O.k., I'll stick to the 2.4 GHz band then.

For a final test, I restricted the channel bandwidth to 20 MHz and I expected to see half of the 70 MBit/s I've seen earlier. To my surprise I still got 58 MBit/s out of the channel. So either the neighboring access points were interfering more with the 40 MHz wide channel or the access point can't really keep up with the transmission rate due to ciphering or other computationally extensive tasks and the air interface would have been capable of much more with the 40 MHz channel.

Another interesting number is the data rate generated by the TCP acks in the return direction. Running a 70 MBit/s TCP data flow in one direction requires a bandwidth of more than 1 MBit/s for the acknowledgments. That's quite something! That compares to a bandwidth requirement of around 400 kbit/s for the 21 MBit/s I got out of the baseline configuration.

One thing I couldn't quite figure out where frequent throughput drops. Suddenly during a transmission, the throughput would drop down to just 2-3 MBit/s for tens of seconds and then just as suddenly things went back to normal. During those times I started a download over my 3 MBit/s DSL line to see if the throughput increases but I couldn't really see that. So either the notebook or the access point seems to have a problem. I'll get an access point with a new chipset soon and I hope I won't see this again. The second picture on the left shows the behavior in more detail.

And one final number to contemplate: Over the course of only one and a half hours I transferred over 20 gigabytes of data. Not too difficult at those speeds.

While the measured speeds are already quite impressive I expect that things can go even faster especially in a 40 MHz carrier with newer chipsets. I'll keep you posted.

When the UMTS licenses were auctioned in Europe back in 2000, new and old network operators in some countries spent enormous amounts of money in license auctions. In Germany for example, the record sum of 50 billion euros was paid by six companies. These days there's a new round coming up or has already taken place for frequencies in the 2.6 GHz band, foreseen to be the main band for the launch of LTE. Interestingly enough, they were sold pretty cheaply in Nordic countries. According to IntoMobile, Finland just sold the licenses for 3.8 million euros. Norway and Sweden's process is already over as well and the proceedings brought 25 and 230 million euros respectively.

I don't know much about the terms and conditions of these auctions but it looks like this time around, things were a bit more realistic. Even when taking the 230 million euros paid in Sweden and adapt it to the number of people living in Germany, it would still 'only' have been 2 billion euros. A tiny fraction of the 50 billion for the UMTS licenses. I hope all players in other countries are as sensible when it comes to new spectrum auctions. After all, have you seen where those 50 billion euros went in Germany after the auction?

The air interface is the scarcest resource of a mobile network and the industry is therefore not only looking to improve peak data rates but also to improve efficiency under everyday conditions. Voice calls are and probably will remain for quite some time to come the most popular mobile service so reducing the overall amount of spectrum required for it to have more room for bandwidth intensive applications is an appealing goal.

Holma and Toskala's book on LTE I reviewed recently has an interesting analysis of this topic. The results sound quite amazing to me so I thought I'd share them with you. In their chapter on VoIP they compare the air interface efficiency of GSM, UMTS, HSPA and LTE and here are some of the highlights:

Voice over GSM, UMTS and HSPA is circuit switched in nature in their study. Therefore they have the advantage that there is little overhead incurred by the different layers of the IP protocol stack. GSM voice capacity was calculated for the Enhanced Full Rate (EFR) and Adaptive Multi Rate (AMR) codecs mostly used in today's GSM network. It's not straight forward to calculate how many voice calls fit into 1 MHz, as adjacent GSM base stations have to use different channels to avoid interference. Due to the modulation, directly adjacent channels can't be used and interference is countered by using hopping carriers, i.e. the transmission frequency is changed for each frame. Taking all these and other things into account they come to the conclusion that there can be around 4 EFR calls per MHz or 8 AMR calls. Quite a difference already.

The same calculation for UMTS and HSPA is probably a bit simpler as all base stations use the same frequency. Interference from neighboring base stations are part of the design and limit the available bandwidth in neighboring cells.  The more load in a cell, the more interference in neighboring cells and the less capacity there. With a simulation of a real life scenario Homa and Toskala estimate the voice capacity per MHz of UMTS of around 12 calls and of HSPA of around 24 (both AMR 12.2). Note that voice over HSPA is not yet deployed in life networks as it's a relatively new feature. For details have a look here.

And now over to LTE. Like for the other technologies, the authors have taken lots of layer 1, 2 and 3 mechanisms into account like for example what's the efficiency of using a 1 ms TTI for a single 20 ms voice frame,  how buffering several voice packets and then sending them together impacts performance and latency, different voice codecs, dynamic vs. persistent scheduling, use of signaling resources, etc. etc. The surprising result, at least to me, is that voice capacity is even higher as for HSPA and they estimate it to be 50 parallel calls per MHz for AMR 12.2 and over 80 parallel calls per MHz with AMR 5.9.

Summary

The numbers are stunning and offer interesting opportunities in the future. According to these numbers LTE is 10 times more efficient to transport voice calls than the current GSM deployment. That is, of course, if the voice calls are controlled by the operator and all optimizations used for the calculation are put into the game. For over-the-top VoIP, that's hardly going to be the case.

I've been playing around a bit with some devices lately with 'full web browsers' (again). However, no matter how hard I try to convince myself that this is the way forward, I'm still drawn back to OperaMini on my N95. Especially when traveling to work each day by train, Opera Mini loads compressed web pages much faster than browsers that download the full pages, especially in spots where only 2G coverage is available. Also, navigating on pages with hardware keys by pressing number keys to scroll up and down is much faster than moving a finger over the touchscreen. It might not look as nice and it takes a bit to learn the key combinations but it is much more convenient and it only takes one hand to browse the web.