Skip to content

8 février 2011 | Rédigé par Ju

4

Le RIL (Radio Interface Layer) Android

Lorsqu’on code une application Android (un apk), on ne sait pas forcément ce qu’il se passe derrière. Il peut être intéressant de se pencher sur l’architecture globale Android pour mieux comprendre ce qu’il se passe derrière l’API fournie par le SDK (enfin c’est mon idée).

Les mobiles Android, sont comme la plupart des smartphones d’aujourd’hui composés généralement d’au moins 2 cœurs, 1 pour l’Application (Linux et Android) et 1 pour le Modem (ou Baseband ou encore Radio).

Petit rappel sur les Telecoms :
Le Modem (2G/3G/LTE) est composé de plusieurs couches protocolaires définies par les standards 3GPP (3rd Generation Partnership Project).
C’est lui qui s’attache au réseau, gère les appels (entrants/sortants), les SMS, la connexion de données du mobile (PDP), la carte SIM etc…

Généralement, un Modem est composé comme suit :

Les différentes couches sont:

  1. AT (ou MMI) : c’est la couche en contact avec le monde extérieur, c’est par ici qu’arrivent les actions utilisateurs (passer un appel, lire un contact, etc.)
  2. Abstraction Layer : elle est en charge de transcrire les commandes AT ou les actions utilisateurs gérées par la MMI en commandes NAS
  3. NAS : Pour Non-Access Stratum, elle est constituée des modules CM (connection management), MM (mobility management), CC (call control), SS, SMS, SM etc.
  4. AS : Pour Access Stratum, elle est la tour de contrôle du Modem, elle gère la cellule courante, les mesures des cellules voisines, le passage d’une technologie à l’autre (2G-3G et inversement) durant un appel (handover) ou non (cell change), etc. Elle est composée de modules tels que RR, RLC, MAC
  5. L1 : Pour Layer 1, c’est la couche basse qui gère les canaux physiques et pilote la radio.

Généralement, les Modems seuls (la plupart des téléphones mobiles) sont pilotés par la MMI (Man Machine Interface), ou IHM, c’est en gros ce que voit l’utilisateur (icônes, menus, boutons…)

Vous l’aurez compris, avec les smartphones, c’est à ce niveau qu’Android intervient, c’est la MMI. Bien entendu, Android ne se cantonne pas qu’à ca. Il gère au travers du système Linux, le multimédia, les périphériques (Wifi, Bluetooth, Camera…), la batterie, le filesystem (SDCARD, …) , etc.

Pour piloter le Modem, et dans le but d’offrir l’interface la plus étendue possible (applicable au plus grands nombre de Modems existants), Google a décidé d’utiliser les commandes AT.

Les commandes AT sont des commandes ASCII définies par les standards 3GPP (27.007 et 27.005 pour les SMS) permettant de piloter un modem.

Voici le principe général d’une commande AT (site) :

Sur les smartphones Android, l’Application (Linux Android) envoie les commandes AT pour piloter le Modem. Les fournisseurs ont donc mis en place des moyens d’envoyer ces commandes d’un OS à l’autre. D’autres fournisseurs, se sont passés des commandes AT et envoient directement des commandes de la couche « Abstraction Layer » depuis l’Application (on perd alors toute portabilité sur d’autres Modems). Bref, je ne rentrerai pas dans le détail, car la discussion pourrait être longue…

En résumé, nous avons d’une part, un Modem piloté par commandes AT et d’autre part, Android qui doit piloter ce Modem. C’est a ce moment qu’intervient le RIL (Radio interface Layer).

Le principe du RIL n’est pas nouveau, il existait déjà avec Windows Mobile. Et son utilité reste assez simple, transformer les requêtes Android (appelées RIL_REQUEST) en commandes AT.

Le RIL est un démon écrit en C, Android s’y connecte par le biais du RILJ (pour RIL java) au travers d’une socket où les objets sont (dé)sérialisés pour y être transportés.

Le RIL écrit ensuite les commandes AT sur une socket ou tout autre port (tty, …) et elles sont alors convoyées jusqu’au Modem, ce dernier renvoie alors le retour des commandes sur le port ouvert.

Voici un schéma permettant de mieux comprendre le principe général :

Prenons un exemple concret, l’appel sortant (ou MO Call).

Lorsque l’utilisateur presse le « bouton vert », la requête passe au travers du Framework pour arriver jusqu’au RILJ par la méthode dial qui va alors préparer une RIL_REQUEST_DIAL et fournir les paramètres nécessaires pour passer l’appel (numéro et présentation du numéro appelant).

Voici le code de la méthode dial RIL.java

public void
dial (String address, int clirMode, Message result) {
 RILRequest rr = RILRequest.obtain(RIL_REQUEST_DIAL, result);
 
 rr.mp.writeString(address);
 rr.mp.writeInt(clirMode);
 
 if (RILJ_LOGD) riljLog(rr.serialString() + "> " + requestToString(rr.mRequest));
 
 send(rr);
}

Cette requête est ensuite reçue par le RIL (Google a fourni le reference-ril.c pour exemple), qui transforme cette requête en commande ATD :

static void requestDial(void *data, size_t datalen, RIL_Token t)
{
RIL_Dial *p_dial;
char *cmd;
const char *clir;
int ret;
 
p_dial = (RIL_Dial *)data;
 
switch (p_dial->clir) {
  case 1: clir = "I"; break;  /*invocation*/
  case 2: clir = "i"; break;  /*suppression*/
        default:
  case 0: clir = ""; break;   /*subscription default*/
}
 
asprintf(&cmd, "ATD%s%s;", p_dial->address, clir);
 
ret = at_send_command(cmd, NULL);
 
free(cmd);
 
/* success or failure is ignored by the upper layer here.
       it will call GET_CURRENT_CALLS and determine success that way */
RIL_onRequestComplete(t, RIL_E_SUCCESS, NULL, 0);
}

Pour un appel au 0612345678, le Modem va recevoir ATD0612345678;

Le RIL passe ensuite en mode lecture, en attente de réception de la réponse finale qui peut être OK, NO CARRIER si l’appel n’a pas été établie ou +CME ERROR: xx lorsqu’une erreur est survenue (xx code de l’erreur).

Une fois la réponse traitée, il (le RIL) envoie au Framework (RILJ) la RIL_RESPONSE avec les paramètres (si besoin).

Le RIL dépile ensuite les autres requêtes (envoie de SMS, activation des données, mesure du signal, etc.) et les exécute une à une. L’information de l’appel remonte quant à elle jusqu’au Dialer par le biais des interfaces.

Note: le seul bémol de cette architecture, c’est que, par défaut, le RIL empile les requêtes à destination du Modem. Alors qu’avec quelques modifications, on pourrait ouvrir plusieurs canaux AT (car les Modems le supportent) et exécuter des requêtes en parallèle pour gagner en efficacité. Mais tout cela reste du ressort des constructeurs.

Découvrez d'autre articles de la catégorie Tutoriels Android

Encore un peu de lecture :

4 Commentaires Poster un commentaire
  1. Stephane
    6 mai 2011

    Intéressant l’histoire de commande AT, est-ce les mêmes que les commandes AT des modems analogiques. Car dans mno job cela peut m’intéresser. En effet, j’ai des appareils de mesures distant et les données sont transmisent via une ligne de téléphone normale et un modem vers un ordinateur de bureau. Le truc qui serait sympa c’est que mes appareils de mesures puissent me transmettre directement les valeurs sur le mobil si ce dernier peut lire les données du modem analogique.
    Est-ce possible, sur un autre forum il semblerait que non, mais il n’y avait pas de tuto qui parlait et montrait les commande AT cmd1 …

  2. Alfanor
    21 mai 2011

    Article très intéressant, par contre, j’aimerais savoir une chose, le second processeur peut-il directement commander le micro et donc envoyer les données audio (la voix en l’occurrence) vers celui-ci ou bien envoie t-il les données vers le premier processeur ? Dans ce second cas, où est-ce que ce transfert de données entre les deux processeurs a-t-il lieu ?

  3. Ju
    23 mai 2011

    @Stephane:
    Oui, ce sont les mêmes commandes AT que pour les modems analogiques, elles peuvent être standards (définies par les organismes comme le 3GPP) ou encore internes (définies par les fournisseurs pour leurs propres besoins).

    @Alfanor:
    En général Android/Linux prend en charge les périphériques (Micro, Bluetooth, GPS etc.) via son kernel. Pour ce qui est de l’échange de données entre les 2 processeurs, il est basé sur des mécanismes bas niveau (kernel/modem) tels que des drivers séries (SPI, HSI, uart) ou encore des mécanismes de mémoire partagée. Mais ces implémentations dépendent, des besoins, ainsi que des choix d’implémentation des fournisseurs.
    Mais au final le principe reste le même, lorsque tu parles dans le micro, les trames audio sont encodées, transmises au modem qui les encodent à nouveau (RLC/MAC) avant de les envoyer sur « l’air » et inversement lorsque c’est ton interlocuteur qui parle.
    Le principe s’applique aussi pour les données IP ou encore la vidéo-téléphonie.

    A+

  4. y
    4 fév 2013

    comment, à partir d’une application android ,puis-je récupérer les mesures radio du réseau GSM comme AT+CCED ? ( merci)

Une question, une suggestion, une opinion? Partagez ce que vous pensez, laissez un commentaire.

(obligatoire)
(obligatoire)

Note: Votre adresse email ne sera jamais publiée.

Suivez les réponses aux commentaires