Over-the-air programming — Wikipédia

Pour les articles homonymes, voir Ota.

Cet article ne cite pas suffisamment ses sources (septembre 2014).

Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».

En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?

L’over-the-air (ou OTA) est une mise à jour d'un système intégré qui est fourni via un réseau sans fil, tel que le Wi-Fi, un réseau cellulaire ou via protocole radio. Ces systèmes embarqués comprennent les téléphones portables, les tablettes, les décodeurs, les véhicules et les équipements de télécommunications. Les mises à jour via OTA pour les véhicules et les appareils Internet des objets peuvent également être appelés firmware over-the-air (ou FOTA). Divers composants peuvent être mis à jour par OTA, y compris le système d'exploitation de l'appareil, les applications, les paramètres de configuration, des mémoires ou des paramètres tels que les clés de chiffrement.

L'over the air (abrégé OTA) est une technologie de communication permettant d’accéder aux données d’une carte SIM à distance. Elle permet par exemple à un opérateur de réseau mobile de mettre à jour le contenu ou d'introduire un nouveau service sur tout un lot de cartes SIM de manière rapide, efficace et peu coûteuse. Par extension ce sigle désigne aussi les technologies permettant de distribuer et d'installer de nouvelles versions de firmware, des paramètres de configuration ^[1]ou de nouvelles données dans un équipement mobile : téléphone, smartphone ou tablette par exemple.

L’OTA repose sur une architecture comprenant une interface de soumission de commandes, hébergée chez l’opérateur, et une carte à puce chez l'utilisateur. Via l’interface, la commande est envoyée à une passerelle OTA qui se charge alors de la convertir en un SMS (et en codes USSD^{[pourquoi ?]}) avant de l’envoyer à la carte SIM. Cette interface de soumission de commandes peut être un backoffice conçu par l’opérateur ou une simple page web accessible aux abonnés, leur permettant d’effectuer des mises à jour sur leur carte SIM ou leur téléphone mobile. Le canal SMS est utilisé car il est standardisé, mais on peut aussi passer par les canaux CSD, GPRS ou les canaux de donnée des terminaux compatibles UMTS (3G).

L’enjeu principal et la difficulté résident dans la gestion des transactions entre la passerelle OTA et la carte à puce. Chaque opérateur peut concevoir des procédures à cet effet. Cependant, une norme standard a été définie par le 3GPP^[Quoi ?] afin de garantir une interopérabilité, sous forme de la norme GSM 03.48.

La norme GSM 03.48, dont la première version a été publiée en 2003, décrit assez exhaustivement une transaction OTA de manière générale, la structure des données qui transitent au cours de la transaction et l’implémentation de l’OTA via les SMS. Une dernière partie est consacrée à la description des commandes OTA ainsi qu’à la présentation de quelques commandes en guise d’exemple.

Une transaction OTA fait intervenir quatre grandes entités :

• une sending application (SA) : c’est toute application capable d’émettre une commande OTA. Il peut par exemple s’agir d’une application résidant dans la carte SIM ou simplement d’une interface applicative résidant chez l’opérateur ;
• une receiving application (RA) : c’est l’application destinataire de la commande OTA. Il peut donc aussi s'agir d'une application résidant dans la carte SIM ou simplement d’une interface applicative résidant chez l’opérateur ;
• une sending entity (SE) : elle se charge de convertir les commandes envoyées par le SA et ajoute les paramètres de sécurité nécessaires à un envoi en toute sécurité sur le réseau. Il peut s’agir par exemple d’un SMS-SC (jouant le rôle de passerelle OTA) ou d’une simple carte SIM qui envoie des commandes ;
• une receiving entity (RE) : c’est cette entité qui reçoit les paquets sécurisés provenant du SE. Il se charge donc de les reconstituer et d’enlever toutes les en-têtes de sécurité précédemment ajoutées afin de permettre l’exploitation de la donnée.

Entre les quatre entités précédemment citées transitent deux types de données :

• application message (AM) : c’est un paquet de données sans paramètres de sécurité ni en-tête produit par un SA. C’est d’ailleurs le seul type de paquet manipulable par ce dernier. Il peut aussi être reçu par un RA de la part d’un RE pour exploitation ;
• secured packet (SP) : à la réception d’un AM, le SE y ajoute des paramètres de sécurité (command ou response header) ainsi que des indications précises sur ces paramètres (SPI pour security parameter indicator) pour ainsi former un paquet sécurisé appelé secured packet :
  • secured command packet (SCP) : c’est un SP résultant d’une commande émise par un SA (à travers un AM) et traitée par un SE (ajout d’un Command Header) ;
  • secured response packet (SRP) : c’est un SP envoyé par un RE en réponse à une commande venant d’être traitée par le RA. Un SRP est constitué d’un en-tête (response header) et, facultativement, de certaines données fournies par le RA à titre informatif sur la commande venant d’être exécutée.

Un application message (AM) est produit par les sending application (SA) et envoyé au sending entity (SE). Ce dernier y ajoute le command header (CH) qui contient l’ensemble des paramètres de sécurité, généré suivant des indications fournies par le SA dans AM. À partir de ce moment l’ensemble AM + CH et appelé secured command packet (SCP) et c’est justement ce paquet qui est envoyé sur le réseau.

Le receiving entity (RE) est à la réception du SCP et se charge alors d’enlever les en-têtes de sécurité (command header) et de transmettre l’AM ainsi reconstitué au receiving application. Le RE est aussi tenu de créer un secured response packet (SRP) si celui-ci est exigé par le SE. Le SRP sera constitué d’un response header (RH) et d’une partie facultative constituée de données fournies par le RA et sera sécurisé suivant les paramètres contenus dans le CH.

Dans le secteur automobile le terme over-the-air update est traduit par mise à jour à distance^[2].

La mise à jour à distance est définie comme suit:

« toute méthode permettant d’effectuer des transferts de données sans fil au lieu d’utiliser un câble ou une autre connexion locale »

— Règlement CEE-ONU 156

L'over-the-air permet de télécharger des fonctions comme l’avertissement de zones de danger pour la navigation GPS ou la mise à jour cartographique^[3].

Ford a équipé d'over-the-air la Mustang Mach-E^[5].

Volkswagen a introduit l'over-the-air dans les véhicules ID-3 et ID-4^[6].

BMW utilise l'over-the-air pour réaliser des ventes additionnelles^[7].

Volvo a utilisé l'over-the-air pour mettre à jour le logiciel de chargement de sa batterie sur la Volvo XC40^[8]. Volvo projette également d'utiliser la mise à jour logicielle over-the-air pour réduire les collisions, réduire les blessures non mortelles et réduire les blessures mortelles^[9].

Toyota a équipé sa Lexus LS et sa Mirai avec la technologie over-the-air^[10]

Mercedes-Benz depuis 2013 aux États-Unis a utilisé l'over-the-air pour mettre à jour 12 millions des mises à jour^[11].

Renault a la fonction over-the-air dans la Renault Megane 2021^[12]

Fiat Chrysler Automobiles utilise la technologie over-the-air pour diffuser une mise-à-jour qui redémarre continuellement le calculateur de divertissement^[13].

Dans le secteur automobile, l'over-the-air est réglementé par le règlement CEE-ONU n° 156 relatif à l'homologation des véhicules en ce qui concerne les mises à jour logicielles et le système de gestion des mises à jour logicielles^[14].

En 2021, une mise à jour over-the-air (OTA) de la Polestar 2 permet de déverrouiller le véhicule depuis un smartphone et de surveiller la charge de la batterie^[15].

En 2021, des poids-lourds de MAN peuvent télécharger une mise à jour du système de navigation par satellite pour éviter des routes incompatibles, notamment pour la hauteur des ponts^[16].

En 2021, des Volkswagen ID 3 et ID 4 peuvent être mises à jour avec le logiciel ID Software 2.3 qui contient des améliorations de différentes fonctions comme la vision nocturne^[17].

• Portail de l’informatique
• Portail des télécommunications