Author: Martin

Ever since the SMS service was launched back then in the mid 1990's, most users around the world only pay for SMS messages they are originating but not for SMS messages they receive. And that is a good thing as users don't have control over incoming SMS messages and whether they want to receive them or not. This has led to the interesting situation that when roaming to other countries, incoming SMS messages are still free, pretty much the only roaming service in GSM that is free.

I am sure some network operators over the years would have really liked to charge for incoming SMS messages to users while they are roaming in another country but perhaps they decided it was not worth the effort of then also providing users with the means to deactivate SMS reception while abroad. Incoming MMS messages are charged when roaming by the way but most if not all phones today have an option not to download incoming MMS messages while roaming.

While this is pretty much the status-quo around the world, North American carriers are a bit different as some (if not all?) have started charging for incoming SMS messages some years ago. In other words if you decide not to take an unlimited texting plan and you get spamed, you pay for it. And it seems that happens more and more often as suggested by this post over at Gigaom. In a part of the world where companies are sued for much less I wonder why that hasn't happened so far!?

Back in 2009 I was musing about a scheme in which the data of heavy users could be dynamically de-prioritized on the cell level if other users are present. This way the quality of experience, i.e. the data rates available to the the majority of users would not suffer as a result of a few users with intensive bandwidth requirements. On the other hand heavy users would still get high data rates while they were alone in the cell.

At the time I was made aware that Ericsson actually had a flavor of such a feature implemented already but even today, I haven't seen it in use so far. When I recently revisited the topic still thinking it was a good idea I noticed that I had perhaps missed a potential side effect of such an approach:

All cells in UMTS and LTE networks use the same channel and thus the signals of different cells interfere with each other. Heavy activity in one cell reduces the data rates available in neighboring cells as the activity in one cell is seen as noise by devices being served by neighboring cells. So in a scenario where a heavy user is pretty much alone in a cell and is thus allowed to transfer data as fast as possible, a user in a neighboring cell especially at the cell edge will have a much lower data rate available than if the heavy user in the other cell would simply be throttled to a much lower speed.

So to be fair to users in neighboring cells the approach would have to be extended to also take traffic in neighboring cells into account. In practice neighboring cells would have to exchange information about their current load. Not impossible to do, but not trivial to implement either.

Help might come from advanced receivers that include inter cell interference cancellation (ICIC) which would reduce the noise rise issue in the scenario describe above and hence make the exchange of load information between cells superfluous. So even while the "dynamically de-prioritzing heavy users on the cell level" scheme still waits for its use in a live network it remains an interesting "Gedankenexperiment" with a couple of new turns and twists added!

Automatic updates of apps and plugins is usually a good thing for most people to stay secure and up to date. However, the mechanism can also be misused to place a cuckoo's egg on your device before you know it. After it would have happened twice to me in recent months if I had not turned auto updates off I thought I'd write a post about it.

The first time it almost happened was when the author of "ReloadEvery", a Firefox plugin I use to reload some pages every couple of minutes so my login would not expire decided to monetize the plugin and included self installing ad-ware in a new version. Fortunately, I had automatic updates disabled and only found out when I wanted to install it on another computer and was warned by the comments on the plugin page of other users. Older versions were still available for download and I could easily adapt an older non-adware version to my current browser version.

The second time it would have happened just recently was with the ShowIP add-on that suddenly started sending out all IP addresses visited to an external service once the latest version got installed. This time I was warned by a Sophos security post. It caused quite a row and for the moment the download page has reverted back to version 1.0 of the add-on. Go grab the add-on and store it on your PC for later re-installation if you use it while you can because it seems the authors may not have understood the real issue people have with this and have announced "improvements" that still send off the ip addresses to an external server but this time using an encrypted connection.

Anyway, the learnings I take away from this are:

a) Only use auto-update for programs you trust (e.g. OS update, Firefox, Thunderbird, etc) but not for add-ons

b) Be very careful what kind of free apps and add-ons you install PCs and mobile devices

c) Disable auto updates of everything else as sometimes you don't really get what you want.

Good luck…

Last year I was by chance on one of those Lufthansa planes that had Internet via satellite connectivity when flying back from the US over Europe. Despite the long round trip times, the overall experience was quite breathtaking. The only thing that can be done to reduce the long round trip delay times is not to use a satellite based but a ground based system. This is a bit difficult over the Atlantic but when flying over land, such a system is quite feasible.

While there are perhaps already existing solutions for ground based Internet solutions for planes, another alternative has been trialled recently: LTE to planes. According to this post and an even more detailed post here (sorry, both in German), Airbus, Alcatel-Lucent and Deutsche Telekom "flew" a trial in November 2011to see how well data could be exchanged between a plane and LTE base stations on the ground, separated around 100 km from each other. The post says that standard LTE equipment was used with antennas only slightly modified to direct the signal towards the the sky instead of to the ground. Speeds of 30 Mbit/s were reached in one direction and 17 Mbit/s in the other. The post is a bit ambiguous in which direction which speed was received but nevertheless that is quite impressive and shows that a cell should have more than enough capacity for the few planes that are its coverage area. At such a distance, the article says, 600 base stations would be required to cover Europe. That is just a handful per country.

But don't get your hopes up to see this in planes anytime soon, though, as there is not even yet a frequency band dedicated for this service.

P.S.: And I really wonder where the antenna was installed on the plane? 🙂

And here's another reason why I like my VPN when using public Wi-Fi: In an interesting blog post over at Justinsomnia the author describes how he recently accessed his own web site via a hotel's Wi-Fi and realizing something was odd about the page. First believing some malware had infected his site, further investigation revealed that it was JavaScript code for ad-purposes being inserted in web pages by the hotel's Wi-Fi ISP. I leave you to draw your own consequences while I switch on my VPN again…

This post is the second part of my NFC overview and focuses on how the technology can be used for mobile payment purposes. As said in the first part, mobile payment via NFC builds on the general NFC technology that is also used for other non-payment applications. There is one major one major addition, however:

As the payment software (e.g. from Visa, Mastercard, American Express, a local transportation company, etc.) and the data identifying the user for the payment process is highly sensitive it must not be accessible from the outside to prevent unauthorized monetary transactions or theft of personal information. Consequently, the payment software and the user data have to be stored in a secure area in the mobile device, the ‘secure element’. One approach is to use the SIM card for this purpose as it is already used as a secure storage element for the user’s mobile network subscriber data. Another approach is to include an independent secure element chip in the mobile phone. The banking industry, for example, requires a secure element that complies to the Globalplatform specifications.

When the user places his mobile device on a point of sales (POS) terminal, the terminal then sends a message identifying which payment applications it is compatible with. The mobile device or the user may then select one of the payment applications stored in the secure element to perform the transaction. For performing a payment, the secure element requires two interfaces, one to the NFC chip to be able to exchange messages with the POS terminal and another one to interact with the user. In other words, there must be an application on the mobile device that can be reached by the secure element based payment software so information such as for example the amount to be paid or a PIN input screen can be shown to the user.

Several companies are involved in this value chain. On the one end there is the bank that issues the payment software and the user identification that is to be stored in the secure element. On the other end is the issuer of the secure element which is the mobile network operator in case the SIM is used as the secure element or the device manufacturer or the user himself in case a dedicated chip is used. A tricky aspect in this regard is how the software and information can be securely transferred between the issuer (e.g. the bank) and the secure element which again depends on who is in control of the secure element. Some types of payments such as for example NFC based entry systems to public transportation systems do not require an interaction with the user at the time the device is brought into contact with the NFC based entry system. This is the case for example, when the user buys a weekly or monthly ticket in advance or pre-pays a certain amount of money that is then automatically deducted when the device is swept over an NFC reader at an entry or exit gate. In such cases, however, an application might be supplied by the public transportation provider that interacts with the software application on the secure element so the user can later on access details on the purchases made, i.e. the trips he has made and the amount of money that was deducted from his account.

It should be noted at this point that there is no standardized process for mobile payments so different banks / card issuers will have their own software stored in the secure element. Also, the payment procedures may be different in different parts of the world, so it is not certain that the NFC payment processes used in Europe will be compatible with those in North America. Very interesting further details on NFC and mobile payment processes can be found in this blog entry over here.

When recently trying out an Android based pad from a major manufacturer I was a bit baffeled that it wouldn't connect in "mass storage" mode to my PC. Instead, the manufacturer wanted me to install a software suite to access the pad's file system. Perhaps this is because the pad has no flash memory slot, just a couple of GB of built in flash. In any case, that was not acceptable at all for me, I don't install software on my PC just to transfer a couple of files. So I started thinking about alternatives and ended up with the Astro File manager and its SMB (Windows file sharing) plug-in to access file systems on Windows and Linux PCs or servers in the network. After sharing the directory that contained the files on the PC and typing in the IP address and the  user name and password of my PC account the file manager on the pad then showed me the files that I could then select and copy over to the local file system over Wi-Fi. Excellent, that's even better than using a cable in the first place!

Near Field Communication (NFC) in mobile devices has been on the agenda for many years now but progress has been very slow. Lately however, there are devices with NFC chips built in comming to the market so I decided it was worth to dig a bit deeper how that works. Getting a single NFC standard accross the industry isn't quite straight forward but some progress has been made in this regard with companies such as Google, Nokia and RIM backing the NFC-Forum based standard for local information exchange and a basis for mobile payment services.

Payment and non-payment (such as receiving a URL from a poster) NFC services rely on the same NFC protocol stack and only differ in how this stack is then made use of by applications on top. I've therefore decided to split up the topic into two posts, with the first describing the basic operation of the NFC protocol stack and how that works with non-payment apps and then in a second post which then describes how NFC can be used for payment purposes.

On the physical layer, NFC uses a carrier frequency of 13.56 MHz to transmit data between two NFC devices via inductive coupling as specified in ISO/IEC 14443. Two transmission modes are specified. The passive mode is used in combination with NFC RFID (Radio Frequency ID) tags that do not have their own power source. In this mode, the originator’s RF field is used as an energy source by the passive RFID tag to return a message. The message is usually short in nature and can for example be an address of a web page (URL) or a business card entry in vCard format.

It is also possible for two active NFC devices to communicate with each other such as two mobile devices or a mobile device and a point of sales (POS) terminal. In active mode, both devices are equal and transmit and send alternatively using their own power source. The practical working distance between two NFC devices is 4 centimeters but much longer ranges can be achieved with high gain antennas. As a consequence, sensitive data exchanges must be encrypted and applications using the communication channel for such information need to authenticate each others to prevent over the air attacks such as eavesdropping, information theft and man-in-the-middle attacks. Supported data rates over the NFC air interface are 106 kbit/s, 202 kbit/s and 424 kbit/s.

The next higher level of the NFC protocol stack defines different message formats. A popular format is the NFC Data Exchange Format (NDEF) defined by the NFC forum. The format defines a general message structure and allows devices to identify what kind of information is contained in the message it has received. The following list gives some examples of message types that can be encoded in an NDEF message:

•    URI (web address, email address)
•    Plain text
•    Smart poster = text + uri
•    Bluetooth and Wi-Fi parameters
•    Business card (vCard format)
•    Signature

Once an NDEF message has been received, a content dispatching system forwards the content of the message to an application that has registered itself for a certain content type. This way, different applications can register themselves for different message types and the dispatching system automatically forwards the message to the application that can handle the particular message type. When several applications register themselves for the same message type a dialogue box is usually presented to the user to choose which application should receive the message. When a web address has been received for example, it could be sent to the web browser while an NDEF message containing a vCard would trigger the address book application that has previously registered itself as a receiver for this kind of content.

Applications on a mobile device can not only receive NFC messages but also transmit them. The address book application for example can be extended to send NFC messages, e.g. an address book entry to the next NFC enabled device that comes in range.

Third party applications can also register themselves as recipients of NDEF messages with a certain content type and can also trigger the transmission of messages themselves. Take Foursquare as an example. The aim of this application is to let users ‘check-in’ at certain locations and share their current location with their friends by various means. The traditional ‘check-in’ procedure uses the GPS receiver in a mobile device to pinpoint the user’s location. The location of the user is then sent to a database in the network to retrieve all places near this location that are registered with Foursquare. The user can then select the place he is visiting. With NFC tags, this process is significantly simplified as the ‘check-in’ is now performed by the user holding his device close to a Foursquare RFID tag. The type of content of the tag is then forwarded to the Foursquare application on the device which then registers the user in the network at the current location. NFC functionality can also be used to exchange information between two Foursquare apps on devices of different users to make friend requests and exchange location lists. This is done by launching the Foursquare applications on both devices and then holding the two devices close together.

So much for now. In part 2, I'll dive a bit into the additions required to use NFC for mobile payment purposes. To come soon…

It's one of those moments in the mobile industry when something happens that is truly a cool first: The first Intel x86 based 'form factor' Android phone is now being sold to end customers as the Xolo X900. For years and years Intel has struggled to put something together that is both fast, power efficient and with the right size. It looks like they've finally made it. Brian Klug over at Anandtech has a full review. He comes to the conclusion that while it's not a leading device yet that blows the rest of the pack out of the water but the performance, size, power consumption and compatability with ARM based Android apps is stunning and competitive. Congrats Intel, after the Wintel marriage broke down with Windows on ARM this shows that it wasn't a one way street!

At some point, hotels with conference capabilities might get it and install a network that doesn't crash when a flock of technophile people arrive and all connect with three devices to the Internet simultaneously via the hotel Wi-Fi. But we aren't quite at that point yet and whenever I am in countries where I can get my hands on SIM cards with enough data allowance (e.g. Germany, Austria, UK)  I offer additional capacity and a stable network to meeting participants (see here, here, here and here for example).

Another possibility is of course to take over the hotel Wi-Fi and fix things yourself, as recently done by a group of IETF engineers before a meeting in Paris at the Hotel Concorde Lafayette. That is of course when things can be fixed in the first place. In many cases it's not only the Wi-Fi but the hotel routers themselves that are overwhelmed by the number of devices suddenly appearing on the network. And if it's not that then it's often the limited uplink capacity that brings everything to a halt. A very interesting story to read, so head over and enjoy.