WirelessMoves

Over the last few years, apps on smartphones such as Facebook, WhatsApp, etc. have become hugely successful, especially among teens and twens. While I was one of the few just 5 years ago who used the mobile Internet on my daily train tips there are now only few without a smartphone in their hand or a notebook on their lap. In other words, use of mobile devices has significantly changed during that time, away from voice and SMS towards Internet based applications. Prepaid tariffs, however, have not, at least not until recently.

No matter to which network operator I turn in Germany, most prepaid tariffs are a bundle of included voice minutes, SMS messages and a few hundred MB or a GB or two for Internet access. Many people today, however, do not need endless amounts of voice minutes and SMS, they are communicating mostly via the Internet. In effect they need to pay for something they don't use. But now things are changing. In the last couple of weeks I have seen two offers that let prepaid subscribers chose the number of voice minutes, SMS and the amount of data traffic per month independently of each other. The number of voice minutes and SMS can even be set to 0 and then paid by the minute or by SMS instead.

An interesting offer for many customers and I would not be surprised to see the number of mobile voice minutes not only declining in fixed line networks but also in mobile now as we are way beyond peak telephony by now.

Last week I attended a meeting for a couple of days in a hotel which had good network coverage for Internet connectivity from my network operator of choice. However, it was 3G and not LTE. Not that it was slow, by far not, I could easily reach speeds above 15 Mbit/s when downloading files. By now, however, 3G coverage feels somehow strange and outdated once one is used to that LTE logo on the display. If I wouldn't have seen the network type indicator on the phone I probably would not have noticed at all so it's only a psychological effect. I found that quite interesting as I still remember the day I bought my first UMTS phone 11 years ago and the day UMTS came to my home town which were breakthrough moments for my mobile Internet usage. Time flies.

Back in July this year I had a post on a GSMA and 3GPP initiative to think about a simpler VoLTE roaming approach. Instead of the quite complicated VoLTE roaming with local breakout, some members of the two fora openly pushed for for a much simpler solution called S8 Home Routing (S8HR). For the details have a look at my previous post. There are surprisingly few public documents that can be found on the web even today which leads me to believe that it’s not really a very popular topic amongst network operators. Japanese network operator NTT Docomo certainly doesn’t belong to those delaying a standard based on S8HR and perhaps they are even tired of waiting for an emerging industry standard as they have announced that they will launch their S8HR VoLTE roaming with KT in South Korea TODAY.

That’s quite NTT Docomo like. Already in the days of 3G, they had a UMTS network up and running well before anyone else. They suffered a bit later on as their network wasn’t quite compatible with the final 3GPP standards so they had to evolve their equipment over time. When LTE was first launched they were again one of the very early adopters. The same goes for VoLTE, they launched their service already back in mid-2014. And now they are pushing the state of the art again with VoLTE roaming.

Fortunately, VoLTE S8HR in it’s very basic form requires no support from the roaming network as all signaling and even the voice data packets are tunneled back to the home network. On mobile devices, however, some things need to be modified. Today, mobile devices deactivate VoLTE when not in their home network which is the first thing that has to change.

In addition, the following things need to be considered on the mobile side:

• IMS registration should work like in the home network, no things to change.

• When establishing a call, forget about preconditions and dedicated bearer establishment.

• For emergency calls just fall back to 2G and 3G even if it is done differently in the home network.

• There is no SR-VCC support to hand-over an ongoing call to 2G or 3G when running out of LTE coverage as the roaming is not aware of an ongoing VoLTE call (it’s all home routed…). There are no modifications for this on the mobile devices side, as this is controlled by the network. In case of roaming, the SR-VCC command will simply not come and the call will drop. As I mentioned in my previous post, that’s a pity but the competition can’t do this either. On the other hand, in countries with good LTE coverage such as South Korea there should be little need for SR-VCC anyway.

If you can think of any other things that have to change on mobile devices to make S8HR VoLTE roaming work, please leave a comment, I’d be quite interested.

In the home IMS network, quite a number of changes were probably required. Roaming calls are likely to be charged differently so the components involved in call charging were probably dapted. That shouldn’t have been much of a challenge though. Somewhat more effort was likely spent on the IMS call establishment logic. In the home network, dedicated LTE bearers are established to ensure constant bandwidth and priority for voice packets on the radio interface and in the network which requires interaction between the IMS and the network infrastructure. As the IMS system in the home network can’t interact with the network components of the visited network, the IMS call flow for roaming calls needs to be modified. Compared to the VoLTE local breakout solution that requires such an international interaction, such changes are pretty much a no-brainer.

Kudos to Docomo for racing ahead, it’s another way to make others follow.

While most features of Prosody and Conversations for XMPP messaging are straight forward there is one feature that is very popular in other IM systems that requires a bit of manual tweaking to set-up: Pictures in Group Chats.

To be able to post pictures that are shown automatically in a group chat in Conversations, the server needs to support XMPP extension XEP-363, "HTTP File Upload". If you have a Prosdoy server at home a corresponding module can be added without too much difficulty. I haven't seen widespread support on public servers yet, with Jabber.at being a notable exception. If you know of others supporting the feature, please consider leaving a comment below. If you are with a public server you can check in Conversations if it is supported by going to "Manage Accounts", clicking on the account that is active at the moment, go to the "…" in the top right corner menu and select "Server Info". That brings up a list that shows which XMPP features are supported by the server. The screenshot on the left shows the features supported by my server, with XEP-363 being the important one for pictures in group chats.

To install the http_upload module in Prosody, have a look here. Once done and Prosody is restarted, support will be indicated in Prosody in the "Server Info" overview. After that there is one more hurdle to be overcome. As it could be potentially dangerous to automatically load in a message stream, Conversations restricts this to pictures that are sent via HTTP links from known contacts. For pictures received from other contacts, only the URL from which they can be downloaded is shown. A long-press on the URL will then download the picture on demand. By default, chat groups created in Conversations are anonymous so even if you know others communicating in a group, Conversations can't identify them and hence only the link shows up. So to see pictures in a chat group instead of links, the group needs to be set into "non-anonymous" mode before participants are added. In this regard, security is a bit in the way of usability I'm afraid.

One other thing is important to remember: As group chats are not end-to-end encrypted (yet), pictures are uploaded to the XMPP server and are stored there in the clear. TLS still protects the conversation so nobody can eavesdrop in a public and open Wi-Fi hotspot. That's probably enough for most people but one should be aware of the fact and always remember that an unencrypted copy is stored for a while on the server. But from what I hear a solution is already in the works.

Already back in August there have been reports that mobile network consolidation has also reached Italy with the proposed merger of Wind and 3-Italy. This would, like in many other countries in Europe over the last few years, reduce the number of independent networks from four down to three. It is a regrettable trend as there are many signs that three network operators with physical infrastructure competing with each other is too little competition. An interesting example of this is France, where the emergence of Free as a fourth mobile network operator back in 2011/12 has significantly heated up competition and reduced prices that were at a very high base compared to most other countries in Europe. Which makes me muse if Free was the last 4th mobile network operator to start operation in a European country in the wake of a wave of consolidation moves in other parts of Europe!?

A couple of days ago, Skype suffered a global outage which made it to a couple of tech news websites and thus caught the attention of the nerd community for about a millisecond or so. Once service was restored, however, it wasn't even newsworthy to report. Global outage and nobody cares?

I use Skype quite regularly so I also noticed that the service was down and in the process trying to get it working again I managed that the Skype app threw away my super long super secure Skype password and I had to spend at least 5 minutes to get it back up working again. Couldn't have happened with a SIM card approach I thought.

But how come nobody really complained about an almost day-long global outage? That doesn't necessarily speak for Skype's popularity. I think the reaction would have been quite different if Facebook or WhatsApp would have been globally down for the same amount of time. That doesn't bode well for Skype's owner Microsoft…

The other thought I had was that in the 'good old days' the worst that could have happened and actually did happen very seldom were local outages of the communication system when a local exchange or the long distance link to it went down for some reason. But that was pretty much it, everything was distributed and even a failure of a long haul transport exchange wouldn't have brought down the network in a whole country, let alone cause a global outage. But these days are long gone, today systems are built for global service and despite of redundancy and fail-safe mechanisms occasionally fail massively on a global level.

Something is wrong with that approach, the Internet was build with survivability in mind, not for centralized services, control or management that cause global outages. But while a couple of decades ago, a whole building was necessary to house a local exchange, a couple of rows of server racks are now sufficient for central control of a nation's telephony system. Sure, that's a lot cheaper than owning, maintaining and powering buildings and equipment in each town to keep the telephone system running but in terms of reliability it is a nightmare. It's time to find a middle ground!

When the XMPP protocol for instant messaging was first created one and a half decades ago the protocol could rightly assume stable Internet connectivity on the client side. Few if any people at the time thought about mobile networks and users moving around, loosing network coverage every now and then or suddenly changing IP addresses. As a result, XMPP in its original flavor doesn't deal with such scenarios very gracefully and drops messages that are in flight during such events.  Fortunately, XMPP did not stand still and there's a fix for this.

The fix is called "stream management" and has been specified in XMPP extension XEP-198. What stream management basically does is message buffering on the server side and requiring an acknowledgement of the client before the message is discarded. In practice, the stream management implementation on my Prosody server at home can easily correct for client side "coverage holes" of well beyond 5 minutes. Works like a charm. Out of the box, stream management is deactivated in Prosody, but it can easily be switched on by downloading and copying "mod_smacks" to Prosody's module directory and then activating it in the config file. The Prosody website has all the necessary details here. A must have feature for mobile clients, no doubt.

R&D and marketing are usually a couple of steps ahead of what's really deployed in live LTE networks so I thought I'd write a post today and the state of the art I can currently see in live networks and relate that to a number of recent press releases about new features and what I think we will realistically see next in networks.

From what I can see, the state of the art in live LTE networks is a maximum theoretical downlink speed of 300 Mbit/s. In some countries like Germany, this is achieved by bundling two 20 MHz downlink carriers for a combined 40 MHz channel. According to this post over at Gigaohm a network operator in Korea achieves similar speeds by combining 3 carriers, one with 20 MHz and two with 10 MHz. So while that requires more sophisticated devices the end result is the same. Network operators in the US probably do carrier aggregation as well these days but since they mostly use 10 MHz channels, with some exceptions, they are not quite reaching those theoretical speeds yet.

So, what are the next steps? Like in Korea, network operators in other parts of the world also have spectrum in more than two frequency bands so it is likely that 3 carrier aggregation (3CA) will be used in other parts of the world to go beyond the theoretical 300 MBit/s, soon. In Europe for example, some network operators could bundle resources in the 800, 900, 1800, 2100 and 2600 MHz band as recent spectrum auctions have left them with ample resources for now to expand their services in the frequency domain. Bundling 3 carriers with 10, 20 and 20 MHz would result in a theoretical top speed of 375 Mbit/s and should somebody be lucky enough to have three 20 MHz carriers, it would result in 450 Mbit/s.

On the mobile device side, most devices sold today are not carrier aggregation capable. This is still the domain of the high end devices such as the Galaxy S6. This is likely to change, however, and I expect that in 18 months from now, 2CA will be the status quo.

In the meantime, high end devices will have gone to 3CA. Qualcomm has recently announced an LTE Category 12 downlink modem that can bundle 3 carriers in downlink which also supports 256QAM modulation for an additional speed boost to the 64QAM currently used close to the base station. Instead of 450 Mbit/s, a theoretical top speed of 600 Mbit/s is thus possible when combining three 20 MHz carriers. Few network operators, however, are likely to have three carriers with such a bandwidth available. Also, 256QAM is only reachable very very close to the base station so I wouldn't count on it making a lot of a difference in real live. For me the most interesting part of the announcement is that the chipset will also support LTE Carrier Aggregation in the Uplink direction. So far, Uplink speeds even in networks using 20 MHz carriers are limited to 16QAM and a single carrier which results in a theoretical peak of 50 Mbit/s. The new Qualcomm modem will support 64QAM in uplink direction and bundling two 20 MHz carriers for a theoretical uplink speed of 150 Mbit/s, which makes it a LTE category 13 uplink device.

While the numbers are certainly impressive, I don't think I need 600 Mbit/s in the downlink on a mobile device anytime soon. As usage of networks increases, however, the main benefit I see of the various advances in LTE carrier aggregation is that more advanced devices will be able to send and receive data over a broader channel, which is important as networks are filling up. It would of course also be possible to make non-carrier aggregation devices hand-over to other frequency bands if a carrier is already highly loaded. However, measuring the availability of other carriers is a non trivial task as well so going the full mile isn't much of an additional trouble.

I've been running Prosdody, an XMPP messaging server on one of my Raspberry Pi's for ages now, mostly for desktop instant messaging and testing mobile messaging clients every now and then. Yes, I could use a public XMPP server but why should I if I can host it myself, too? It's easy to install from the Debian package archive and easy to configure. Now that I've found 'Conversations' a fantastic mobile messaging app, I wanted to upgrade Prosody to take advantage off a number of new features such as for example handling of temporary absence of clients due to network coverage holes which are not part of the version contained in the Debian archive. It turned out that the upgrade process is rather simple.

Instead of first de-installing the Debian archive version (0.8) and using Prosody's package repository to install the latest Prosody version (currently 0.9.8) from scratch one can go ahead and directly configure to use the external repository and install the latest version over the existing one. It only takes a few commands which are described here generically. For Debian on a Raspberry Pi they look like this:

sudo apt-get install software-properties-common python-software-properties
sudo add-apt-repository "deb http://packages.prosody.im/debian wheezy main"
wget https://prosody.im/files/prosody-debian-packages.key -O- | sudo apt-key add –
sudo apt-get update
sudo apt-get install prosody

Before doing so, I saved the configuration file from /etc/prosody to be able to restore it later. There are only few changes between the old and new configuration file so once the upgrade process was finished I renamed the new configuration file, put my old one back in place, added the new parameters to my own configuration file and restarted the server with 'sudo service prosody restart'. The whole process takes 10 minutes at most so it's not much trouble at all.

If you are installing Prosody for the first time you can of course skip copying the configuration file and instead configure it from scratch. Only a few parameters need to be filled in and the configuration file is well documented. Once done, the only other thing that needs to be done for a new installation is to create user accounts as documented here.