Lorsqu'on s'intéresse à la manière dont un smartphone se connecte à un réseau 5G, l'attention se porte généralement sur des éléments de réseau tels que le gNB, l'AMF, le SMF et l'UPF. L'USIM, bien plus petite, est facile à négliger. En pratique, cependant, l'USIM a également besoin de structures de données dédiées pour prendre en charge des fonctions allant de l'enregistrement 5G et du stockage de l'état de mobilité à la confidentialité de l'identité de l'abonné, aux contextes de sécurité NAS et au contrôle d'accès.

Avec l'introduction de la 5G, le système de fichiers de l'USIM a été étendu en conséquence. Il ne s'agissait pas simplement de stocker quelques paramètres supplémentaires dans la structure SIM existante. De nouveaux répertoires spécifiques à la 5GS, des indicateurs de service et des fichiers EF ont été introduits au sein de l'application USIM afin que l'équipement mobile puisse déterminer quelles capacités 5G sont prises en charge par la carte, quelles données doivent être stockées et où la configuration correspondante doit être lue.

Mémoriser des noms tels que EF5GS3GPPLOCI, EF5GAUTHKEYS et EFSUCI_Calc_Info de manière isolée peut rapidement devenir déroutant. Une approche plus pratique consiste à regrouper ces fichiers selon les problèmes qu'ils traitent : mobilité, sécurité, confidentialité de l'identité de l'abonné, contrôle d'accès et informations de l'opérateur.

Pourquoi l'UICC et le système de fichiers sont importants avant d'examiner les fichiers USIM 5G

La SIM est apparue à l'ère de la 2G et peut être comprise comme un module d'identité d'abonné dans lequel le matériel et l'application étaient étroitement intégrés. Le composant matériel est la puce à circuit intégré, tandis que le côté logiciel comprend le système d'exploitation COS, le système de fichiers et les applications ou services de couche supérieure.

Avec l'introduction de la 3G, l'USIM (Universal Subscriber Identity Module) a séparé plus clairement l'application de la plateforme de carte sur laquelle elle s'exécute. L'UICC est la plateforme sous-jacente de carte à circuit intégré universelle, tandis que l'USIM fonctionne comme une application sur cette plateforme. En d'autres termes, ce que l'on appelle couramment une « carte USIM » est, du point de vue de l'architecture logique, plus précisément décrit comme une application USIM s'exécutant sur une UICC.

Cette distinction est importante car la 5G n'a pas introduit un système de données totalement séparé en dehors de l'USIM. Au lieu de cela, les capacités 5G continuent d'utiliser le modèle de service et de gestion de fichiers existant de l'USIM.

Une grande quantité de données de carte à puce est stockée sous forme de fichiers. La structure logique comprend principalement :

• MF (Master File) : le fichier de niveau supérieur dans le système de fichiers de la carte.

• DF (Dedicated File) : un répertoire dédié utilisé pour organiser une application ou un groupe de données particulier.

• EF (Elementary File) : les fichiers de base qui stockent réellement les données de service, les informations d'état et les paramètres de configuration.

Pour la 5G, un répertoire DF5GS dédié a été ajouté sous l'application USIM pour organiser les fichiers EF liés à la 5GS. La spécification d'application USIM correspondante définit neuf services liés à la 5G et dix fichiers EF correspondants pour cet ensemble de capacités.

Quelles capacités 5G sont ajoutées sous DF5GS ?

La simple présence d'un fichier EF ne signifie pas automatiquement qu'une fonctionnalité doit être utilisée. Un autre fichier important est EFUST (USIM Service Table).

EFUST indique quels services sont pris en charge par l'USIM. La table de services contient 131 services au total, tandis que les services liés à la 5G abordés ici sont numérotés de 122 à 130. Si un service est marqué comme indisponible, l'équipement mobile ne le sélectionnera pas. La configuration réelle du service est définie par l'opérateur.

Ce tableau est plus utile que la mémorisation isolée des noms de fichiers car il montre le modèle de conception de base de l'USIM : indication de capacité de service plus les données EF correspondantes.

Par exemple, lorsque le service 122 est disponible, l'USIM doit fournir les fichiers pertinents pour la gestion de mobilité 5GS. Lorsque le service 123 est disponible, le fichier de clés d'authentification 5G est requis. Lorsque le service 129 est disponible, l'USIM fournit la liste PLMN de l'opérateur 5GS.

D'un point de vue d'ingénierie, EFUST répond à la question « Que prend en charge cette carte ? » et les fichiers EF individuels répondent à la question suivante « Quelles données cette capacité nécessite-t-elle ? ». L'équipement mobile utilise ces deux informations pour déterminer comment la fonction 5G correspondante doit être traitée.

Pourquoi les états de localisation et de sécurité 5G sont-ils stockés séparément pour l'accès 3GPP et non-3GPP ?

L'un des groupes de fichiers les plus simples sous DF5GS concerne la gestion de la mobilité.

EF5GS3GPPLOCI stocke les informations de localisation 5GS pour l'accès 3GPP, notamment :

• 5G-GUTI ;

• le dernier 5G-TAI visité ;

• l'état de mise à jour 5GS.

Le fichier correspondant EF5GSN3GPPLOCI stocke le même type d'informations pour l'accès non-3GPP. Les deux fichiers ont un objectif similaire, mais ils s'appliquent à des types d'accès différents.

Cela montre que l'USIM fait plus que stocker un numéro d'abonné dans un contexte de mobilité 5GS. Elle conserve également une identité temporaire, des données de localisation récentes et un état de mise à jour qui peuvent être utilisés lors de procédures ultérieures.

La même séparation s'applique aux contextes de sécurité NAS. EF5GS3GPPNSC stocke le contexte de sécurité NAS pour l'accès 3GPP, tandis que EF5GSN3GPPNSC stocke le contexte de sécurité NAS correspondant pour l'accès non-3GPP.

Un autre fichier de sécurité dédié est EF5GAUTHKEYS. Lorsque le service 123 d'EFUST est disponible, ce fichier est requis et stocke les clés liées à l'authentification 5G, notamment KAUSF et KSEAF générées par l'équipement mobile.

L'examen de ces fichiers ensemble révèle la logique de conception de l'USIM 5G. Les données ne sont pas simplement regroupées par nom de protocole. Elles sont organisées autour de l'état de fonctionnement réel de l'UE : où il est enregistré, comment il accède au réseau, quel contexte de sécurité est actuellement valide et quelles informations d'authentification peuvent être requises ultérieurement.

Comment le SUCI, le contrôle d'accès et les informations opérateur sont-ils mappés vers des fichiers EF spécifiques ?

En plus des contextes de mobilité et de sécurité, la 5G introduit des exigences de données supplémentaires côté USIM pour la confidentialité de l'identité de l'abonné et le contrôle d'accès. Les capacités liées au SUCI en sont l'un des exemples les plus clairs.

EFSUCI_Calc_Info stocke les informations nécessaires au calcul et à la protection du SUCI. La disponibilité de ce fichier pour l'équipement mobile dépend de la combinaison des services 124 et 125 dans EFUST.

Si le service 124 est disponible et que le service 125 ne l'est pas, le calcul du SUCI est effectué par l'équipement mobile. Dans ce cas, EFSUCI_Calc_Info doit être présent et disponible pour l'équipement mobile.

Si les services 124 et 125 sont tous deux disponibles, le calcul du SUCI est effectué par l'USIM. Dans ce cas, EFSUCI_Calc_Info ne doit pas être disponible pour l'équipement mobile. Si le service 124 lui-même n'est pas disponible, le fichier ne doit pas non plus être exposé à l'équipement mobile.

Les objets de données clés du fichier comprennent :

• Liste des identifiants de schéma de protection : contient les priorités des schémas de protection et l'index de clé.

• Liste des clés publiques du réseau domestique : contient les clés publiques du réseau domestique et les identifiants associés utilisés pour la protection du SUPI.

Un autre fichier utilisé avec le SUCI est EFRouting_Indicator. Il stocke l'indicateur de routage, qui fait partie du SUCI et peut être utilisé pour le routage vers l'AUSF et l'UDM du réseau domestique.

Au-delà de la confidentialité de l'identité de l'abonné, l'USIM peut également participer au contrôle d'accès unifié. EFUAC_AIC stocke la configuration de gestion d'accès, y compris les identités d'accès associées à des services à haute priorité définis. Ces valeurs peuvent être utilisées avec la catégorie d'accès pour prendre en charge le contrôle d'accès pour des services spécifiques.

Pour les informations d'affichage de l'opérateur, EFOPL5G stocke les associations entre les 5G-TAI et les identifiants d'enregistrement de nom de réseau PLMN. Lorsque l'UE s'enregistre auprès d'un PLMN, l'équipement mobile peut utiliser ces associations puis lire les informations de nom d'opérateur correspondantes pour afficher le nom ou l'icône du fournisseur de services.

EFNSI, quant à lui, stocke un SUPI de type identifiant spécifique au réseau. Dans ce cas, le SUPI utilise le format NAI et ne doit pas être un IMSI.

Quel rôle l'USIM joue-t-elle réellement dans un réseau 5G ?

Si l'USIM est considérée uniquement comme une carte d'identité d'abonné, il est difficile d'expliquer pourquoi la 5G nécessite autant de services et de fichiers EF supplémentaires.

Pris ensemble, ces fichiers montrent que l'USIM fournit un ensemble de fonctions de stockage contrôlées par table de services pour les données d'abonné, l'état de l'UE, les informations de sécurité et la politique de l'opérateur.

Elle stocke bien plus que des informations d'identité fixes. Le 5G-GUTI et le dernier TAI visité représentent l'état de mobilité. Le contexte de sécurité NAS et les clés d'authentification 5G représentent l'état de sécurité. Les fichiers liés au SUCI participent à la protection de la confidentialité de l'identité de l'abonné, tandis que l'UAC, le PLMN et le contrôle d'appel de session PDU montrent comment la politique de l'opérateur peut également influencer le comportement de l'UE via l'USIM.

Le service 127 fournit une orientation de l'UE dans le VPLMN basée sur le plan de contrôle et peut être utilisé dans la sélection de PLMN liée à l'itinérance. Le service 128 fournit un contrôle d'appel sur session PDU par l'USIM. Avant l'opération concernée, le terminal peut fournir à l'USIM des informations telles que le type de session PDU, le mode SSC, les capacités 5GSM et les informations de cellule de desserte, puis continuer selon l'instruction renvoyée par la carte.

Cela a également des implications pratiques pour le dépannage. Lors de l'étude de problèmes de compatibilité de terminaux 5G, d'échecs d'enregistrement, de problèmes de confidentialité d'identité d'abonné ou de comportements spécifiques de contrôle d'accès, vérifier uniquement le réseau radio et le cœur 5G peut ne pas suffire. Les ingénieurs peuvent également avoir besoin de vérifier si l'USIM déclare correctement le service correspondant, si l'EF requis existe et si le contenu du fichier correspond à la configuration de l'opérateur.

Une séquence de dépannage pratique est la suivante : vérifier d'abord EFUST pour confirmer la capacité prise en charge, vérifier que l'EF correspondant existe, puis inspecter le contenu de l'EF. C'est souvent plus efficace que de lire chaque fichier lié à la 5G individuellement.

Pour les ingénieurs de terminaux 5G et de réseau cœur, c'est la véritable valeur de la compréhension du système de fichiers de l'USIM. De nombreuses fonctions 5G apparemment séparées aboutissent finalement à une question très concrète : avant que l'UE n'exécute une procédure réseau, quelle capacité l'USIM a-t-elle déclarée et quelles données a-t-elle stockées pour cette fonction ?

FAQ