As a "radio" man, I'm quite interested in how applications and mobile device operating systems communicate with the part of the device responsible for the cellular data connectivity not only in terms of transmitting and receiving user data packets but also how to connectivity to the cellular network is controlled. Here's how it works in Android:
Application Layer
For application layer programs in the Dalvik Virtual Machine, information about the current state of the cellular network can be obtained via the android.telephony package. In the package there are a number of classes with methods to query the current type of network (e.g. GSM, UMTS), information on the current cell such as the cell ID for GSM or the primary scrambling code (PSC) for UMTS cells, signal strength and quality and also detailed information about neighboring cells found, including signal strength and quality.
Another package of interest in this regard is android.net. This package contains classes and methods to discover the type of connectivity (e.g. WiFi or cellular), own IP and DNS server information. In other words, an application can find out a lot of technical information from the physical layer up to the IP stack.
Operating System
From an operating system point of view the radio layer information has to be retrieved from the piece of hardware that is responsible for cellular connectivity. This is done via an abstraction library, the Radio Interface Layer (RIL) that offers a hardware independent interface to the operating system and higher layers to query such information and receive unsolicited information from the radio chip about events such as cell changes.
On the other end, the RIL communicates with the radio chip via a non-standardized interface with Google giving a reference implementation based on well known Hayes AT-commands (more on that below). Here's a link with some more infos on what vendors have to do if they want to customize the radio hardware facing side of the RIL. Over this interface, pretty much anything about the radio can be controlled, including retrieving and modifying information stored in files on the SIM card. This link contains an interesting AT-command log traced while a circuit switched call was established. Further details about the at commands can be found in 3GPP TS 27.007
Hardware
Remains the question of where the radio stack is running on a mobile device. In some mobiles a dedicated chip is used while in others, a single chip is used that contains both the processor(s) for the radio stack and the processor(s) for the application layer, i.e. the processors that Android runs on. The radio processor(s) and the application processor(s) run independently from each other.
In the case of the first Android device, the HTC Dream, also known as the G1, a Qualcomm MSM7201A system on a chip is used as per the Wikipedia entry for the device. That's of course an old and slow chipset platform compared to the dual-core application processors running at GHz speeds in 2011, but that doesn't really matter from a radio/application separation point of view. On the Wikipedia page for the chip it is stated that than an ARM11 core is used for the application processor, while an ARM9 core is used for the radio stack. In other words, the RIL described above runs on the ARM11 core and communicates via an interface to the ARM9 core that executes the radio stack independently, asynchronously and in real time from the application processor.
That separation comes in very handy from an Android development point of view because apart from the RIL, the 2G/3G radio code is completely independent and is even running on a different hardware unit or even on a different chip. Android and the radio OS can thus evolve completely separately from each other. If you look at it from the radio stack of things, it couldn't care less which application OS is running on the other processor, it just delivers its services to Android, Symbian, WP7 or any other OS sitting next door.
This separation is very similar to a scenario in which a 3G USB dongle is used as a modem and a notebook or netbook that runs the operating system (Windows, Linux, Mac OS). Between the 3G dongle (the radio) and the notebook (the application processor), USB is used as the interface. And if you dig a bit deeper, the afore mentioned AT commands are used to initiate and tear down IP connections (PDP contexts) and to control the radio in general (e.g. manual network selection, report of signal strengths, etc.). The RIL in Android in other words is doing something very similar as the PPP daemon in Linux or the dial-up network support in Windows.
And finally, here are two links that show how this is implemented on the circuit board. The first one shows the solution described above, i.e. radio processor and application processor in the same chip in the case of the G1. In the case of the Nokia N8, radio processor and application processor are implemented in two separate chips (Texas Instruments baseband processor and Samsung Application processor) as shown and described here. The Nokia N95 has a similar separation with TI providing both the radio and the application processor chips as shown here. The hardware diagram shows this very nicely.
Terrifc article. Very clear.
I’m looking into EAP-SIM/AKA authentication for smartphones on WiFi networks. Curiously, almost none of the Android devices in the market are able to support the SIM challenge necessary for EAP-SIM/AKA.
There’s a thread here: http://code.google.com/p/android/issues/detail?id=9329
The only device that can seems to be the Galaxy Tab. The “WiFi Calling” apps on UMA/GAN Android devices obviously can access SIM credentials, but these are special builds. (And still do not support EAP-SIM/AKA).
I understand this is temporary situation that results from it not having been a priority for manufacturers. Anyone have any insight into progress on this front?
Interesting topic. In terms of the chipsets I think separating the apps core and radio modem makes a lot of sense especially for higher end phones. However the single chip solution has it’s advantages – likely it can save some space on the board, the interface between the apps and radio core is internal so it’s less complicated than mix-matching the two; and likely it’ll save some cost and development time for the phone manufacture. Perhaps good for low-mid tier phones. If the device is designed to support high end features, and sometimes if the OS does support multitasking, then it’s going to be a lot higher requirement for the apps core – consider the scenario when the baseband modem dumps xxMbps data (from LTE/HSPA+ etc) to the apps core, and if there’re other things going on simultaneously such as high definition video/audio, gaming, music playback etc, then it’s certainty going to push the apps core to its boiling limit. In this case some manufactures may want to have the flexibility to choose a more powerful apps processor. However depending on the solution, some glue logics may have to be put in between the two in case some functionalities don’t work together directly. Pros and cons for both; depending on the manufacture I guess.