Author: Martin

Dual-SIM phones have been around for many years and I first looked at the concept back in 2008. You can defend yourself against patchy network coverage with them, you can use them to evade high interconnect charges in some countries, and you can use them if you travel between different countries and need to be reachable with a national number to people in different countries. So far I've never picked one up though as they were either produced by small Asian companies of unknown origin or came with a very dumb phone operating system. But lately, Samsung for example has started offering Dual-SIM phones based on Android and now things have become even more interesting for me. Late in 2011, the Galaxy Y Duos (a.k.a. the GT-S6102) was announced and is now available on the market. Time to pick one up, even more so as it only cost €138 including the 19% sales tax!

To describe how dual-SIM works in practice with this device I've decided to split up the description in three parts. In the first post I'll focus on the dual-SIM capability for voice calls and SMS. The second part then deals with dual-SIM capability for Internet connectivity. In part 3 I'll then focus on how Android works on a sub-150 Euro phone.

Trying to figure out how dual-SIM works in practice from sources on the web proved to be difficult. There are a number of articles describing the feature but each misses some points that are important to me or even makes wrong statements. Also, the user manual that can be downloaded from Samsung's website doesn't give much insight. So I decided to cover the territory in more detail here.

Dual Standby – Two Transceiver Chains

On this particular model the two SIM card slots are below the battery. Good enough for my purposes as I have no need to exchange the SIM cards regularly. When powering-on the device the PIN code for both SIM cards are requested, one after another. Once entered, both SIM cards register in a network. Read carefully, the sentence says 'a' network, because each SIM card can register to a different network. This requires to independent transceiver chains because registering to two independent networks requires to listen to different signals on different frequencies simultaneously which can't be done with a single transceiver chain. One transceiver chain is 2G/3G (GSM/UMTS) capable while the second one is 2G (GSM) only.

Individual Network Settings for Each SIM Card

Which SIM card is used for which chain can be configured in the the "mobile networks" settings in the Android configuration menu. While standard Android phones have just one list of settings such as whether packet data is used in the home network, if packet data is allowed while roaming, which APN is used, which type of network to attach to and which network operator to use, this phone has two tabs in this menu as shown in the picture below which lets the user configure all these values for each SIM card independently.

Two SIMs, Two Different Networks, One Chain is 2G/3G

Selecting which SIM card is used for the 2G/3G chain and which one for the 2G-only chain is hidden behind the "Use only 2G network option". If activated for one SIM card the option is automatically deactivated in the options on the second tab for the other SIM card. In other words, it is not possible to set both transceiver chains to 2G-only mode. The 2G/3G chain always remains in this mode. Some reviews have come to the conclusion that this means that one transceiver chain is 2G-only while the other is 3G-only. This is not correct, however. If the network operator of the SIM card configured for the 2G/3G chain does not have a 3G network, both transceiver chains use a 2G network and it can be different ones. I tried it, it works fine so we can put that rumor to rest. Why the interface does not allow to configure both chains for 2G-only mode is a beyond me though.

Which chipset is actually used in the phone is a bit of a mystery. Samsung doesn't say but there are some sources on the web that point to Broadcom's 21553 System on a Chip (SoC) that includes baseband(s), CPU and GPU. Have a look at the data sheets here and here which point to that chip and some background info about the dual-SIM capability of the Soc here and some general information from Broadcom here which unfortunately doesn't mention the dual-SIM capability.

Outgoing Phone Calls and SMS

Once both chains have connected to a network, two independent signal strength indicators are shown in the Android status bar at the top of the screen. In the status pull down menu, the network name of each network is shown ('Telekom.de' and 'O2 – de' in the first picture above) and the user can select from which SIM card to originate phone calls and SMS messages. The number of the SIM card used for outgoing calls and SMS messages is then also shown in the status bar in a blue box ('1' or '2'). Also the background wallpaper can be set to change depending on which SIM card is selected for outgoing activity which gives another visual indication to the user. Neat! Selecting the SIM card via the status pull down menu is possible at any time even while an SMS message or phone number has already been typed in.

Some dual-SIM phones I have seen in the past offer two 'green' buttons in the phone application so the user can select which SIM to use for an outgoing call this way. On the Galaxy Y Duos, however, this is not the case, the SIM card selection for outgoing activity is only possible via the status pull down menu. While that looked like an unhappy implementation to me at first I came to the conclusion that this is actually a good implementation for a usage scenario in which outgoing communication usually uses the same SIM card. In the phone log and in the SMS application, Android has been modified to always show which phone call and which SMS used which SIM card by showing a small blue logo with '1' or '2' inside that looks the same as the blue logo in the status menu. That's neat so you can always find out later which SIM card you have used for what should you be in doubt.

Incoming Phone Calls and SMS

Incoming communication while no phone call is in progress works via both SIM cards. This shows that the device is really connected to both networks simultaneously. Calls for SIM card one are shown with a little blue '1' logo while the call is alerted and later on in the log. Calls for SIM card two are shown with a blue logo that has a '2' inside. During a call, calls or SMS messages arriving via the other SIM card are not delivered as the device does not react to the paging. After a few seconds the caller is either forwarded to the voice mail system or to an announcement that the user is currently not reachable. Note that this is different from a call forwarding or announcement because the user is busy. SMS messages are queued in the SMS service center and a periodic retry ensures their delivery once the call on the other SIM card has finished. This might not happen immediately though depending on the retry period of the SMS service center. For details see this post from last year on 'SMS Delivery After Loss of Signal'.

Network Selection

While each SIM card per default searches for the home network or a roaming network automatically, it is possible to perform a manual network search on a per SIM basis and select a different network when roaming. The function is not implemented correctly though, as after a reboot, automatic network selection is activated again. Something to improve in the next software version.

Summary

After a couple of days using the phone I am still impressed. The baseband stack and Android OS implementation is very stable and all test calls and SMS messages to both SIM cards were delivered. Except for the "2G only" setting described above which is a bit misleading the dual SIM card approach was nicely integrated into Android on the device. 5-thumbs up!

I'll finish for today although I'm sure you are interested in the Internet access side of things as well. Coming up soon here…

Two interesting numbers for discussions revolving around the future of SMS and traditional mobile voice telephony:

In 2011, 55 billion SMS messages were sent in Germany (population 82 million), up from 41 billion messages the year before. That's a stunning 30% increase! Not exactly a downward trend from a quantitative point of view, despite the growing competition from mobile instant messaging services.

Traditional mobile voice telephony is also not on the decline, despite the ever growing number of non-voice communication methods. In the course of 2011, 107 billion outgoing voice minutes were logged in Germany, up from 102 billion a year earlier. That compares to 191 billion outgoing voice minutes over fixed line networks (down from 195 billion minutes the year before).

For details have a look here and here (sorry, both sources in German)

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…