WirelessMoves

It's 2014 and there is no doubt that LTE on Band 3 (1800 MHz) has become very successful and the Global mobile Supplier's Association (GSA) even states that "1800 MHz [is the] Prime Band for LTE Deployments Worldwide". When looking back 5 years to 2009/2010 when first network operators began deploying LTE networks, this was far from certain.

Quite the contrary, deploying LTE in 1800 MHz was seen by many I talked to at the time as a bit of a gamble. At the time, the general thinking, for example in Germany, was more focused on 800 MHz (band 20) and 2600 MHz (band 7) deployments. But as the GSA's statement shows, that the gamble has paid out. Range is said to be much better compared to band 7 so operators who went for this band in auctions or could re-farm it from spectrum they already had for GSM have an interesting advantage today over those who need to use the 2600 MHz band to increase their transmission speeds beyond the capabilities of their 10 MHz channels in the 800 MHz band.

To me, an interesting reminder that the future is far from predictable…

Here's the number game of the day: When I recently installed Ubuntu on a PC I noticed that the complete package that installs everything from the OS to the Office Suite has a size of 1.1 GB. When looking at firmware images of current smartphones I was quite surprised that the images are at least the same size or are even bigger!

If you want to see for yourself, search for "<smartphone name> stock firmware image" on the net and see for yourself. Incredible, there's as much software on mobile devices now as there is on PCs!

A lot of it must be crap- and bloatware, though, because Cyanogen firmware images have a size of around 250 MB. Add to that around 100 MB for a number of Google apps that need to be installed separately and you are still only at about a third of a manufacturer's stock firmware image size.

Whenever I make a hotel reservation these days I can't help but wondering how good their Wi-Fi actually is or if it works at all. Most of the time I don't care because I can use my mobile data allowance anywhere in Europe these days. Outside of Europe, however, it's a different story as it's more expensive so I still do care. Recently I came across HotelWifiTest, a website that focuses on data rates of hotel Wi-Fis based on hotel guests using the site's speed tester. Sounds like an interesting concept and it's promised good speeds for the next hotel I'm going to visit. So let's see…

With LTE-Advanced Carrier Aggregation being deployed in 2014 it recently struck me that there's a big difference in deployed capacity between LTE and UMTS now. Most network operators have had two 5 MHz carriers deployed for quite a number of years now in busy areas. In some countries, some carriers have more spectrum and have thus deployed three 5 MHz carriers. I'd say that's rather the exception, though. On the LTE side, carriers with enough spectrum have deployed two 20 MHz carriers in busy areas and can easily extend that with additional spectrum in their possession as required. That's also a bit of an exception and I estimate that most carriers have deployed between 10 and 30 MHz today. In other words it's 15 MHz UMTS compared to 40 MHz LTE. Quite a difference and the gap is widening.

To secure my fixed and mobile data transfers I've been using OpenVPN for many years know. With fixed and mobile networks becoming faster I have to continuously improve my setup as well to make maximum use of the available speed at the access. At the moment, my limit at the server side is 30 Mbit/s while at the access side, my Wi-Fi to VPN Gateway's limit is 10 Mbit/s. Time to change that.

A quick recap of what happened so far: Earlier this year I moved from an OpenVPN server on an OpenWRT Wi-Fi Router to an OpenVPN Server running on a Raspberry. At the time my VDSL uplink of 5 Mbit/s was the limit. With that limit removed the next limit was the processing capacity of the RaspberryPi which limited the tunnel to 10 Mbit/s. The logical next step was to move to a BananaPi who's limit with OpenVPN is around 30 Mbit/s.

In many cases I was still limited to 10 Mbit/s, however, as I was using a Raspberry Pi as a Wi-Fi / VPN Client Gateway to tunnel the data traffic of many Wi-Fi devices through a single tunnel. For details see this blog entry and the Wiki and Code for this project on Github. To move beyond the 10 Mbit/s, I had to upgrade the hardware on this side to a BananaPi as well. The process is almost straight forward because I run Lubuntu 14.04 on the BananaPi which, like Raspian running on the BananaPi, is based on Debian Wheezy. With a few adaptations the script I put together for the RasbperryPi also runs on the BananaPi and converts it to an OpenVPN client gateway in a couple of minutes.

While I expected to see a throughput of 30 Mbit/s, the link between the two BananaPi levels out at 'only' around 20 Mbit/s as shown in the screenshot on the left. I haven't yet found out why this is the case as on both devices, processor load is around 65%, so there are ample reserves left to go faster. For the moment I ran out of ideas what it could be. However, doubling the speed with this step is not too bad either.

Just a quick post today because I struck me today what a wide difference in size there is today between network operators. On the high end of the scale there are network operator organizations that serve countries with a population of over a billion, i.e. 1000 million people and have a significant market share. And on the other end of the spectrum there are countries, yes, independent countries, with just half a million inhabitants in Europe, i.e. countries that are much smaller than even only a single mid-sized city in bigger countries.

In other words, even if one of the network operators in such a country is dominant, it doesn't have more than a view hundred thousand subscribers. Between 1000 million and less than a million are 3 orders of magnitude! Breathtaking that the way mobile networks are built and operated works on both ends of the spectrum and that there doesn't necessarily seem to be a sweet spot at some point in between for an ideal network and organization size.

A few weeks ago I've reported about my stellar speed experience with fiber connectivity in Paris with downlink and uplink speeds of 264 Mbit/s and 48 Mbit/s respectively. Today, I've got a follow up with a couple of pictures and technical background information.

Fiber and Copper in the Apartment

Let's start at the end of the fiber. The first pictures shows two boxes stacked on top of each other. The bigger one below is a standard Wi-Fi access point with router functionality which is connected to the small box via an Ethernet cable. The small box is a fiber to copper converter. The green cable going into the small box is the fiber cable. The small box gets pretty warm so it's save to assume it takes more than the 2.5 Watts of a Raspberry Pi…

The second picture is a close-up of the of the fiber to copper converter, the Optical Network Terminal (ONT). The Ethernet cable on the left is connected to the bigger Wi-Fi network box shown in the first picture. The optical cable with the green connector on the right goes to the next box in the apartment shown in picture 3. As no power is delivered to this box it must be a passive component that connects the more sturdy optical cable coming into the apartment to the more flexible optical cable with the green connectors.

And that's it as far as the equipment in the apartment is concerned. The fourth picture shows how the optical cable gets into the apartment via a crudely drilled hole that was filled with some glue afterward. Not quite a work of art to say the least.

Yes, it's GPON!

So what kind of fiber technology is used for this line? The model number on the fiber to copper converter on picture 2 (I-010G-Q) gives the first clue that Google translates into a number of interesting links to follow. The most interesting one is to lafibre.info which contains lots of pictures of how the outdoor part of fiber networks are installed in France. The Google search for the model number also led me to a pretty interesting document from Alcatel Lucent which details their Gigabit Passive Optical Network (GPON) components and network setups on 250+ pages. So there we go, the I-010G-Q is part of a GPON installation. 2.4 Gbit/s in the downlink and 1.2 Gbit/s in the uplink direction that is shared between all installations behind one fiber strand that is split close to an apartment building into separate strands, one for each customer.

From an evolution point of view the document's 2010 creation date is also interesting. In other words GPON is well in it's 4th year of deployment now and has come nowhere near capacity issues so far. And it's unlikely to happen anytime soon, i.e. there's no immediate need to beef up the specs to make it even faster. The challenge with GPON rather is, that optical cables need to go into buildings and from there to apartments to deliver speeds in the Gbit/s range. And that certainly comes at a price.

The hot LTE topic of 2014 that made it into live networks certainly is Carrier Aggregation (CA). Agreed, there aren't too many devices that support CA at the end of 2014 but that's going to change soon. In the US, quite a number of carriers have deployed 10 + 10 MHz Carrier Aggregation to play catch up with the 20 MHz carriers used in Europe already.  In Europe, network operators will use 10 MHz + 20 MHz aggregations and some even 20  + 20 MHz for a stunning theoretical peak data rate of 300 Mbit/s. So where do we go from here? Obviously, aggregating 3 bands is the next logical step.

And it seems 3GPP is quite prepared for it. Have a look at this page which has an impressive list of all sorts of LTE carrier aggregation combinations and also shows for each in which 3GPP spec version it was introduced in the specification.

For Europe, especially the 3A_7A_20A combination (20 + 20 + 10 MHz) is interesting as there are network operators that have spectrum in each of these bands. Peak data rates with 50 MHz of downlink spectrum, which some network operators actually own, would be 375 Mbit/s.

For North America, there are literally dozens of potential combinations listed. Not sure which ones might actually be used. But I suspect it will be difficult to come up with 50 MHz of total aggregated bandwidth in this region, so Europe will continue to have an edge when it comes to speed.

I use smartphone Wi-Fi tethering every day to connect my notebook to the Internet. This mostly works out of the box. There are, however a tiny number of smartphones with which I have problems While the notebook connects just fine, ping times are very long and erratic as shown in the screenshot on the left and there's almost no data throughput. I took me a long time to figure out what the issue was but at some point I realized that I only had the problems with a few particular devices when my notebook was not connected to the charger. Ah, may of you might say now, then it has something to do with power saving modes!

And indeed it has. Per default, Ubuntu activates power save mode in the Wi-Fi chip when running on battery and deactivates it as soon as the notebook is connected to the mains again. While power save mode slightly increases ping times it otherwise has no negative effects with 99% of the smartphones I try, except for the few it wreaks total havoc on.

Fortunately, there's a simple way to disable power save mode. A simple "sudo iwconfig wlan0 power off" from a shell instantly fixes the problem. The "iwconfig" command without any parameters then shows that power save mode was switched off desite running on battery:

wlan2     IEEE 802.11bgn  ESSID:"martins-i-spot"  
          Mode:Managed  Frequency:2.462 GHz  Access Point: xx:xx  
          Bit Rate=57.8 Mb/s   Tx-Power=16 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=70/70  Signal level=-38 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:90   Missed beacon:0

While this is a good short term fix, Wi-Fi power management is activated again after rebooting or after sleep mode. To permanently disable Wi-Fi power save mode, a script that contains the command can be added in the power management configuration directory:

cd /etc/pm/power.d/
sudo touch wireless
sudo chmod 755 wireless
sudo nano wireless

And then paste the following two lines inside:

#!/bin/bash
/sbin/iwconfig wlan0 power off

That's it. Just one more thing perhaps: Use "ifconfig" to check if your Wi-Fi adapter is "wlan0" or if the OS has at some point assigned another name to it and adapt the command accordingly.

 

While most networks still use the Radio Bearer "Release with Rediredirect" method to switch from LTE to 3G when necessary, some networks have started using a real LTE to 3G packet handover procedure that significantly reduces the outage time of the data bearer. So far so good. The problem with this is that once a device is on the 3G layer there's no way for it today to get back to LTE until no data is transmitted anymore and the connection is put into Idle or Cell/URA-PCH state. This is especially problematic if a mobile device is used via tethering in combination with notebooks and other devices that send data all time as the switch back to LTE then never happens. Perhaps the time has come now to change this?

Before I go on explaining why the time might have come for this to change it's perhaps a good idea to have a quick look at the problem of a 3G to LTE handover. While active in UMTS, the mobile's transceiver is active all the time so it can't look on other channels and bands for a better radio technology. The only way to do this is for the network to schedule transmission gaps (the famous UMTS compressed mode) and to instruct the mobile device to look for LTE cells during those transmission and reception gaps. Obviously such a radio reconfiguration has a significant drawback: The data rate goes down. This is perhaps ok if an LTE signal is found but not very desirable if there is no LTE coverage to be found for some time. This is the reason why network operators have so far shied away from it. After all, 3G is quite a good technology for Internet access as well.

These days, LTE has become a lot better than UMTS, however, and when I look at network coverage maps there aren't a lot of places in many networks where 3G is deployed but LTE is not. In other words, if the unfortunate event occurs and the mobile is sent to 3G due to a lack of LTE network coverage, chances are very high that the user will be back in LTE coverage quite quickly. Therefore I think that with the LTE network coverage there is today it would make sense to think about 3G to LTE handovers.

P.S.: And it's not that changes from a slower RAT to a faster RAT while transferring data is unknown. This works great from GSM to UMTS for example. As GSM/GPRS uses timeslots, a mobile device has ample time even without network support to search for UMTS even while data is transferred. The same mechanism also works to switch from GPRS to LTE during a data transfer but so far only few mobile devices have implemented this. Fortunately first devices are now showing up that can do GPRS to LTE reselections during packet data transfer. So when I'm connected while being in a train I at least end up on LTE again if things get so bad for some time that my connectivity ends up on the GSM layer.