ECM – EPS Connection Management

Posté le 6 mai 2015 by flaunay - 9 831 vues

La connexion ECM (EPS Connection Management) a pour but de mettre en oeuvre des ressources physique (SRB – Signaling Radio Bearer) et des ressources réseaux (S1 bearer) entre l’UE et le MME : La ressource physique génère des supports radios entre l’UE et l’eNb alors que les ressources réseaux génèrent des supports (bearer) entre l’eNb et le MME. Cela permet donc de créer une connexion entre l’UE et le MME (connexion NAS) comme le rappelle la figure ci-dessous (extrait article)

Les procédures de gestion de connexions sont réalisés lors des procédures suivantes :

Procédure d’accès aléatoire
Procédure d’enregistrement LTE
Procédure d’établissement de connexion pour le plan usage
Procédure de libération de connexion

L’état de l’ECM permet aussi de déterminer si l’UE est localisé à l’eNb près ou sur un zone nommée Tracking Area. Pour cela, l’ECM décrit l’existence ou non d’une connexion NAS, c’est à dire une connexion entre l’UE et l’EMM selon l’un des deux états suivants :

ECM-Idle
ECM-Connected.

I) Les états ECM

ECM_idle : L’UE est dans l’état ECM_idle lorsqu’aucune connexion de signalisation NAS existent entre l’UE et le MME, c’est à dire pas de connexion sur l’interface S1_MME. Dans l’état ECM_idle, l’UE est localisé sur une Tracking Area.

Lorsque l’UE est dans l’état ECM_idle, sa mobilité est gouvernée par la procédure de sélection/resélection de cellules comme indiquée dans la norme 3GPP TS36.304. Dans ce cas, l’UE peut toujours être enregistré et localisé au niveau du MME (donc l’UE est EMM_ENREGISTERED) mais la connexion de signalisation est perdue (ECM_idle).

ECM_Connected : Dans cet état, une connexion NAS est établie entre l’UE et le MME. L’UE est localisé au niveau de l’eNb.

Ainsi, quand l’UE doit transmettre des paquets, l’UE envoie au MME un Service Request pour passer dans l’état ECM_Connected.

II) Les états ECM et EMM

A priori les états ECM et EMM sont indépendants l’un de l’autre, par exemple la transition de l’état EMM-REGISTERED vers EMM-DEREGISTERED peut se réaliser quelque soit l’état ECM de l’UE ou du MME. Cela signifie que l’UE peut faire une demande de détachement dans le mode ECM_idle ou ECM_Connected.

Lorsque l’UE libère la signalisation, ce dernier va dans l’état ECM_idle, mais il reste dans l’état EMM_REGISTERED.

Cependant, certaines transitions nécessitent un état particulier de l’ECM. A titre d’exemple, la transition EMM-Deregistered vers l’EMM-registered se réalise soit pendant la demande d’enregistrement (LTE Attach) soit au cours de la procédure TAU. Dans ce cas, l’UE passe simultanément dans l’état ECM-Connected State..

En combinant maintenant l’état EMM de l’UE, on peut différencier trois premiers cas :

EMM-REGISTERED et ECM_idle

L’UE est localisé dans un zone TA, l’UE étant enregistré possède l’identifiant S-TMSI mais n’a plus de connexion avec le réseau, dans ce cas, l’UE

1 – Peut réaliser une mise à jour de sa localisation.

1-1) Le TAU est déclenché lorsque le TA mesuré par le téléphone est différent du précédent TA ou déclenché périodiquement à la fin du timer T3412.

1-2) Cela permet de maintenir l’enregistrement de l’UE et d’être toujours localisé par l’EPC (notamment en cas de paging). L’UE envoie ainsi une notification à l’EPC pour l’informer de sa présence.

2 – Est à l’écoute de Paging

EMM-DEREGISTERED et ECM_idle

L’UE n’est pas localisé par le réseau, et doit s’attacher avec l’identifiant IMSI.

EMM-REGISTERED et ECM_Connected

L’UE est localisé à la cellule près, il y a des échanges de signalisation entre l’UE et le MME et des échanges de données entre l’UE et le SGW.

Sur la figure suivante, on présente les états de transitions entre les états ECM et EMM.

IMSI, TMSI, GUMMEI, GUTI

Posté le 6 mai 2015 by flaunay - 34 401 vues

Dans l’article précédent, nous avons étudié une approche simplifiée de l’enregistrement de l’UE au niveau du MME. Lors de l’attachement, l’UE et le réseau s’authentifie mutuellement. Au cours de cette procédure, l’authentification s’appuie sur l’IMSI contenu dans l’UICC et le HSS.

Une fois l’UE authentifié, le réseau suit la mobilité du terminal en communiquant avec ce dernier par le TMSI.

Nous allons dans cet article précisé le sens et le rôle de chacun de ces termes. L’article s’appuie sur la spécification ETSI 3GPP TS 23.003 V10.1.0 (2011-03).

I – Identification du client mobile sur le réseau (GSM/GPRS/UMTS/LTE)

Un numéro d’identifiant unique (IMSI – International Mobile Subscriber Identity) est attribué à chaque mobile ayant accès au réseau cellulaire. Ce numéro est valable pour le réseau GSM/UMTS et EPS.

L’IMSI est composé de trois parties :

MCC : Mobile Country Code permet de désigner le pays dans lequel est situé l’opérateur.
MNC : Mobile Network Code permet de spécifier l’opérateur dans un pays
MSIN : Mobile Subscriber Identification Number, identifie de manière unique un client de l’opérateur.

Figure 1 : Identification d’un utilisateur : IMSI

Lorsque l’UE se connecte, le réseau l’identifie à partir du numéro IMSI. L’IMSI n’est enregistré qu’à deux endroits : Dans la carte SIM/USIM et au niveau du HLR/HSS. Ce dernier est donc transmis après cryptage vers la station de base. Cependant, pour éviter le décryptage de ce numéro, le réseau alloue à chaque UE un numéro temporaire : TMSI (Temporary Mobile Subscriber Identities).

II – Identification du client mobile via le Temporary IMSI

Les équipements de localisation du réseau doivent être en mesure de mettre en relation le TMSI du mobile avec l’IMSI. Le TMSI est sauvegardé au niveau des équipements réseaux VLR, SGSN, MME et sur la carte SIM. L’échange se fait donc avec l’identifiant TMSI au lieu de l’IMSI. Le TMSI sera modifié quand l’UE ne sera plus géré par le même équipement réseau (VLR/SGSN ou MME). Mail le TMSI peut aussi être modifié de façon périodique. Le TMSI n’est donc pas sauvegardé au niveau du HLR/HSS.

La valeur du TMSI est codée sur 4 octets, seule la combinaison constituée de 32 bits à ‘1’ est interdite (cette valeur indique que le TMSI n’est pas disponible). Le rôle du TMSI est donc de contacter le mobile lors de la procédure de paging afin d’établir une signalisation NAS entre le coeur réseau et l’UE.

Avec le GSM, le MS était repéré par le TMSI pour les services de phonie, puis avec l’arrivé du GPRS, un nouvel identifiant temporaire, nommé P-TMSI était alloué aux MS. Avec la 4G, les téléphone possèdent un nouvel identifiant nommé M-TMSI (MME TMSI).

III – Globally Unique Temporary Identifier

Le GUTI (Globally Unique Temporary Identifier) est assigné à l ‘UE par le MME lors de la première demande d’attachement de l’UE.

L’objectif du GUTI est de fournir une identité unique à l’UE sans dévoiler l’identification confidentielle, privée et unique de la carte SIM (IMSI). Le GUTI est composé de deux identifiants, le GUMMEI (Globally Unique Mobility Management Entity Identifier) qui identifie de manière unique le MME parmi tous les MME sur lequel l’UE est inscrit et le M-TMSI qui identifie de manière unique l’UE parmi tous les autres UE gérés par le MME.

Ainsi, lorsque l’UE envoie le GUTI à l’eNb, ce dernier utilise le GUTI pour identifier ver quel MME la requête doit être transmise. En effet, un eNb peut être connecté à plusieurs MME (pour faire un partage de charge).

Si l’UE était initialement enregistré sur le réseau 3G ce dernier possède un identifiant P-TMSI. Supposons qu’après une sélection de cellule l’UE s’attache au réseau 4G, alors au cours de la procédure TAU, le MME qui va dorénavant gérer l’UE contacte le SGSN pour demander le profile de l’UE (Adresse IP, PDP context). De manière identique, lorsque l’UE quitte le réseau 4G vers le 3G, le GUTI est transmis et le SGSN lors du RAU (Routing Area Update).

La figure ci-dessous décrit la manière d’écrire le GUMMEI et le GUTI : Le GUMMEI est construit à partir du code pays (MCC), du code opérateur (MNC) et du MMEI (Mobility Management Entity Identifier). Le MMEI représente une MME compris dans un groupe de MME, il est ainsi constitué du MMEGI (Mobility Management Entity Group ID) et de MMEC (MME Code).

En rajoutant le M-TMSI au GUMMEI, on obtient le GUTI.

Figure 2 : GUTI – Decomposition en plusieurs champs

Pour résumer, voici les identifiants permettant de caractériser de manière unique un mobile au niveau du MME d’un opérateur dans un pays précis.

Figure 3 : Détail du GUTI

A partir des différents identifiants énumérés ci-dessus, la norme définit d’autres attributs comme :

MME Identifier composé du MMEGI et MMEC
S-TMSI composé du MMEC et du M-TMSI

Figure 4 MMEI et S-TMSO

Le S-TMSI est exploité dans le cadre de la procédude de Paging. Comme le montre la figure précédente, le S-TMSI est construit à partir du MMEC et du M-TMSI. Par conséquent, lorsque l’UE est enregistré, le S-TMSI est déduit du GUTI à partir des 40 derniers bits du GUTI.

Questions : Quels sont les équipements de l’opérateur qui ont connaissance du TMSI?

EMM Procédure – Initial Attach

Posté le 5 mai 2015 by flaunay - 13 433 vues

Au cours de l’article précédent, nous nous étions intéressés aux états EMM de l’UE et du MME. Nous avons notamment vu que le protocole EMM réalise les fonctions suivantes : L’attachement et le détachement, l’authentification, la mise à jour de la localisation de l’UE et la mise en place d’une connexion sécurisée entre l’UE et le MME pour échanger de la signalisation NAS.

La procédure d’attachement (enregistrement) est initiée par le téléphone afin que ce dernier puisse accéder au réseau 4G, mais de surcroît la procédure d’attachement est couplé avec la création de contexte pour établir un support (bearer) par défaut . En effet, contrairement à l’UMTS, la procédure d’enregistrement permet d’établir un bearer DATA (sur le plan usager), nommé default bearer.

Cette procédure est donc la première procédure établie par l’UE (ayant un abonnement 4G) lorsque l’utilisateur allume son téléphone. Cependant, sur cette première phase, plusieurs scénarios peuvent se produire :

L’UE était déjà attaché sur le réseau et s’enregistre sur le même MME que précédemment
L’UE était déjà attaché sur le réseau mais s’enregistre sur un autre MME par rapport à l’attachement précédent
L’UE s’attache pour la première fois au réseau

Comment un téléphone s’identifie t’il auprès du réseau cellulaire? La réponse est assez simple, l’UE doit envoyer son identifiant IMSI ou GUTI, tout dépend du scénario ci-dessus. Nous allons illustrer ces scénarios sur une première présentation simplifiée de l’attachement initiale.

Nous verrons prochainement le call flow détaillé sur la procédure d’enregistrement après avoir étudié le protocole RRC. Cela sera donc étudié dans un autre article. Dans cet article nous nous concentrons sur les procédures EMM.

I) Initial Attach – Attachement Initale

L’enregistrement initial est déclenché à l’allumage de l’UE. Suite à cette procédure, l’UE est enregistré sur un ensemble de zones de TA, zones indiquées par le MME dans le message EMM Attach Accept.

Comme la procédure d’enregistrement initie également une connexion sur le plan usager, l’UE peut recevoir et transmettre des sessions. C’est au cours de cette phase que l’UE obtient une adresse IP (soit IPv4 avec un NAT au niveau du PGW, soit IPv6). Le context bearer est sauvegardé au niveau du PGW. Cela signifie qu’il n’y a plus de bearer entre le SGW et le PGW (ni sur le plan usager, ni sur le plan contrôle), seul le contexte est sauvegardé au niveau du PGW. Si un appel arrive pour l’UE, le PGW contacte le MME pour positionner l’UE et construit le bearer sans avoir besoin d’authentifier à nouveau l’UE. Le réseau réduit ainsi la latence pour l’utilisateur.

Au cours de la procédure d’enregistrement, l’UE indique dans le message NAS Attach Request (transmis à l’eNb) les informations suivantes :

Identifiant temporaire GUTI s’il existe ou l’IMSI sinon
Le dernier TA visité s’il existe
…

Ces informations permettent donc de définir quel scénario d’attachement va être réalisé.

Cas 1 : L’UE fait une demande d’attachement avec son IMSI.

Dans la suite, l’UE possède un GUTI (attribué par un MME lors de son dernier attachement). A partir du GUTI, on connait l’adresse du précédent MME (GUMMEI). La procédure est la suivante : Le MME sur lequel l’UE fait sa demande d’attachement (qui peut être le même que celui sur lequel il était attaché) va demander à l’ancien MME de lui transférer le contexte de l’UE via le message IDENTIFICATION REQUEST. L’ancien MME répond par IDENTIFICATION RESPONSE

Cas 2 : Le contexte de l’UE n’est plus sauvegardé dans le précédent MME

Le précédent MME n’ayant pas le contexte répond par un message d’erreur. Le nouveau MME va alors demander à l’UE de lui fournir l’IMSI comme identifiant (EMM Identity Request)

Cas 3 : Le contexte de l’UE est sauvegardé

Le précédent MME envoie le contexte au MME. Le contexte contient l’IMSI de l’UE et les clés K_asme, ainsi que les clés de chiffrement et d’intégrité NAS. Un message de vérification des clés (Clé d’intégrité NAS et de chiffrement) s’effectue entre le MME et l’UE par l’envoi du message EMM SECURITY MODE.

Ainsi, pour le cas 1 et le cas 2, l’identification via l’IMSI permet de lancer une procédure d’authentification : le MME demande au HSS de fournir un numéro aléatoire RAND, le sceau d’identification du mobile et un sceau d’identification du réseau et une clé Kasme. Une fois authentifié, il est nécessaire d’activer la sécurité de la signalisation en dérivant de la clé Kasme trois clés, CK_nas, IK_nas et K_eNb.

Pour le cas 3, le MME récupère le contexte.

Une fois la mise en sécurité effectuée, le MME récupère le profil de l’utilisateur du HSS (APN, QoS de l’utilisateur et AMBR) et le HSS sauvegarde l’adresse du MME qui gère l’UE

La création du bearer par défaut s’effectue ensuite.

Lorsque le MME a récolté ces dernières informations, il sélectionne le SGW et déclenche la création de contexte au niveau du SGW, lequel demande la création de contexte vers le PGW. Le PGW peut valider ou refuser la création du contexte en fonction de la réponse du PCRF.

II) Call Flow simplifié

Nous allons présenter un call flow simplifié permettant à un UE de s’enregistrer sur le réseau de son opérateur. Rappelons avant tout l’architecture du réseau afin de présenter les différentes interfaces existantes entre les équipements.

Le call Flow est extrait d’une formation EFORT, lequel détaille dans ce document le rôle du HSS. DIAMETER est un protocole sur lequel s’appuie le coeur de réseau pour permettre :

l’authentification des UE
l’autorisation de l’accès au réseau et aux services
la taxation des services.

Lorsque l’UE s’allume, voici l’échange de trames entre l’UE et le réseau permettant l’enregistrement de l’UE au niveau du réseau.

L’ attachement au réseau EPS correspond à :

L’authentification de l’UE
Rappatriement du profil souscrit par le client au niveau du MME qui gère l’UE
La création d’un default bearer permanent correspondant à une connectivité permanente IP.

Lorsque l’UE s’allume, il procède dans un premier temps à la recherche d’information sur la cellule dans laquelle il est situé (synchronisation et récupération des informations de la cellule, le tout étant émis périodiquement par le eNb). Une fois cette étape passé :

1. L’UE fait la demande d’enregistrement en émettant la requête Attach a destination du MME. Le protocole de signalisation d’accès appelé EMM (EPS Mobility Management Protocol est porté par DIAMETER (Signalisation réseau).

2. Le MME envoie un message DIAMETER AIR (Authentication Information Request) au HSS sur l’interface S6a. C’est par ce message que le MME demande au HSS de fournir un vecteur d’authentification de l’UE. L’UE étant défini par son identifiant IMSI, cet identifiant est transmis dans la requête DIAMETER. Le HSS fait une requête dans sa base de données afin de trouver la clé K correspondant à l’IMSI. Il tire ensuite un numéro aléatoire RAND et calcule le sceau du mobile RES, le sceau du réseau AUTN et la clé Kasme à partir de laquelle le MME va construire une clé de chiffrement NAS (CKnas), une clé d’intégrité NAS (IKnas) et une clé de chiffrement pour l’eNb (KeNb). Par conséquent, le HSS renvoie au MME par le message AIA (Authentication Information Answer) les paramètres suivants : RAND, RES, AUTN et Kasme (3GPP TS 35.206).

3. Le MME envoie à l’UE un requete d’authentification. Cette requête est émise par le protocole EMM. Via le message EMM Authentification Request, le MME transmet le nombre aléatoire RAND et le sceau d’authentifcation du réseau AUTN à l’UE. Ces deux paramètres sont transférées vers la carte USIM, laquelle calcule le résultat XRES (obtenu à partir du rand et de sa clé privé), vérifie le sceau d’authentification du réseau, et calcule la clé Kasme.

Si la valeur calculée par l’UE est identique au sceau AUTN, alors l’UE considère le réseau comme le réseau de confiance.

L’UE retourne sa réponse XRES au MME afin que celui-ci vérifie le résultat d’authentification RES obtenu par le HSS avec le résultat XRES calculé par l’UE. Si les résultats sont identiques, cela signifie que les clés privées sont les mêmes et par conséquent la double authentification est validée (AKA).

4. L’abonné (la carte USIM) est authentifiée, mais pas le terminal. Le MME demande à l’UE de lui fournir son IMEI.

5. A partir de la réponse obtenue, le MME interroge l’EIR pour savoir si le terminal fait ou ne fait pas partie de la liste des équipements interdits (black list). L’interface DIAMETER S13 est utilisée entre le MME et l’EIR.

6. Si l’UE et l’USIM sont authentifiés, le MME délivre une requête Update Location Request (adresse MME sous forme de hostname, IMSI) au HSS via l’inteface S6. Sur cette même interface, le HSS acquitte la mise à jour de localisation par une réponse Update Location Answer au MME qui contient les données de souscription EPS de l ’UE incluant la liste de tous les APNs que l’UE est en droit d’accéder, une indication sur l’APN par défaut, et les paramètres de QoS associés à chaque APN. Si le HSS rejette la procédure de mise à jour de localisation, alors le MME rejette la demande d’attachement de l’UE.

7. Le MME établit le premier default bearer pour l ’UE.

8. Le MME retourne à l’UE une réponse EMM Attach Accept informant l’UE qu’il est accepté par le réseau. Cette réponse permet à l’UE de connaître l’APN qui a été activé et l‘adresse IP du PGW assignée à l’UE pour cet APN

NB : Les étapes 2 et 3 correspondent à l’authentification EPS, nommée EPS AKA. Cela consiste (en attente d’un article décrivant la procédure complète) :

authentifier l’UE de la part du réseau
authentifier le réseau de la part de l’UE (pour garantir que le réseau est bien celui de son opérateur et non un réseau tiers malveillant)
créer un contexte de sécurité pour le calcul de clé de chiffrement.

EMM – EPS Mobility Management

Posté le 10 mars 2015 by flaunay - 7 641 vues

Les réseaux mobiles doivent être perçus comme une extension du réseau fixe : Les difficultés des réseaux cellulaires vis-à-vis des réseaux classiques sont d’une part la gestion de la mobilité et d’autre part, pallier à l’affaiblissement dynamique des liens radios.

Afin de conserver le fonctionnement du réseau Ethernet de type résidentiel, l’idée de l’EMM est de gérer la mobilité des utilisateurs pour rendre cette mobilité transparente au niveau du cœur réseau.

Protocole EMM

Le protocole EMM gère la mobilité de chaque UE, l’EMM permet :

L’Enregistrement de l’abonné sur le réseau – Attach
La mise à jour de sa localisation – Tracking area update TAU

Il y a 3 types de procédures pour l’EMM :

Les procédures communes permettant :
- l’authentification des UE (mécanismes AKA)
- la réallocation d’identifiant NAS – GUTI
Les procédures spécifiques pour la demande d’attachement ou de détachement au réseau, ainsi que la mise à jour de sa localisation
Les procédures de gestion de session, autrement dit des procédures de signalisation ou de connexion NAS sécurisée

Les procédures spécifiques sont déclenchées par l’UE , les procédures communes sont déclenchées par le MME alors que les procédures de gestion de session peuvent être soit à l’origine de l’UE (MO) soit du MME (MT).

Les états EMM pour l’UE et pour le MME

Comme nous l’avons vu dans l’article précédent, il y a 2 états d’enregistrement pour l’EMM:

Pour passer de l’état EMM-Deregistered vers L’EMM-Registered, le mobile doit faire une demande d’attachement (ATTACH), et inversement la demande de détachement (DETACH) permet de passer de l’EMM Registered vers l’EMM Deregistered.

Etudions maintenant le contenu de ces états :

EMM-Registered :

Dans cet état, le MME connait la localisation du mobile soit au niveau de l’eNB soit au niveau de la zone de TA (Tracking Area). Dans cet état, le mobile effectue des Mises à jour de sa localisation (TAU : Tracking Area Update), il répond au Paging, et il effectue des procédures de requête de service (Service Request) pour transmettre des données en Uplink.

EMM-Deregistered :

Dans cet état, le MME ne possède pas d’information de localisation du mobile, ce qui n’empèche pas au MME de conserver actif des contextes de l’UE afin d’éviter de refaire la procédure d’authentifacation (AKA) lors de l’attachement. Lors des procédures de TAU et/ou d’attachement, l’UE passe dans l’état EMM-Registered.

Pour l’UE

EMM_DEREGISTERED : L’UE n’a aucun contexte EMM avec le MME, il est détaché du réseau ou non localisé. Il sort de ce contexte lorsqu’une procédure d’enregistrement est effectuée
EMM_REGISTERED : L’UE est connecté au réseau et partage un contexte EMM avec le MME

Pour le MME

Protocoles NAS et Protocoles AS

Posté le 25 janvier 2015 by flaunay - 12 438 vues

Je vous propose de commencer l’année 2015 par une description fonctionnelle du réseau cellulaire 3G/4G, en reprenant le concept des strates nommées strates d’accès et strates de non accès. Les strates représentent les procédures d’échanges d’information à la fois des informations de signalisations et des informations usagers (payload ou données utiles) entre l’UE et le cœur réseau

AS : Acces Stratum

La strate d’accès fait références aux protocoles relatifs à l’accès radio qui permettent de gérer l’échange d’information (pour rappel signalisation et données) entre l’UE et coeur réseau de l’opérateur. L’AS fait référence aux couches basses de la pile protocolaire OSI.

NAS : Non Acces Stratum

Le NAS (strate de non accès) représente un ensemble de protocoles qui s’établit entre l’UE et le réseau coeur. Le NAS permet l’échange d’information de contrôle ou de données quelque soit l’accès radio. Le NAS s’appuie donc sur l’AS pour transporter ses données.

On peut donc, dans le cadre du réseau 3G, représenter schématiquement les strates d’accès comme suit (figure 1) :

Figure 1 : Représentation schématique NAS/AS

Les rôles de la Strate d’Accès

Les principales fonctions liées au réseau d’accès (UTRAN Universal Terrestrial Radio Access Network) sont les suivantes

Gestion des ressources radio
Handover
Chiffrement/Compression

Les rôles de la Non Strate d’Accès

La couche NAS a deux rôles essentiels (figure 2):

Gestion des sessions (et des appels pour la 3G)
Gestion de la mobilité.

Pour la 3G : La gestion des sessions se découpent en deux sous-couches :

la sous couche de gestion des appels téléphoniques nommées Call Control –CC– uniquement pour le réseau 3G (puisque le réseau 4G n’est qu’un réseau IP). Cette sous-couche ne concerne que la gestion des appels en commutation de circuits, c’est à dire l’établissement, le maintien et la libération des appels du domaine circuit
la sous couche de gestion des sessions pour l’établissement et le relâchement des sessions (donc du domaine paquet).

La mobilité pour la NAS est la gestion de l’authentification, de mise à jour de la localisation et de l’attachement au réseau. Il s’agit du protocole MM : Mobility Management pour la commutation de circuit et GMM GPRS Mobility Management pour la partie commutation de paquets.

Figure 2: Représentation couches AS/NAS 3G

Pour le LTE, les protocoles se nomment (figure 3):

ESM : EPS Session Management
EMM : EPS Mobility Management.

Figure 3: Représentation couches AS/NAS 4G

Les rôles de la Strate d’Accès

La strate d’accès regroupe donc les couches basses : RRC, PDCP, RLC, MAC et Phy. Les messages NAS, entre l’UE et le Nb ou eNb sont encapsulé dans les messages RRC.

Nous verrons le rôle de ces couches dans un autre article.

Le blog reprend vie

Posté le 24 janvier 2015 by flaunay - 3 160 vues

Répondre

Bonne année à tous, et bonne nouvelle avec l’écriture de nouveaux articles sur le blog.

Pourquoi un si long silence?

Je devais préparer plusieurs nouvelles formations et le contenu est maintenant finalisé (enfin presque). Ces formations sont les suivantes :

Asterisk et FreePBX : Les services avancées en téléphonie, mise en place de Trunk SIP entre Asterisk et avec le MiVoice 5000 (Anciennement Aastra 5000) et mise en place de l’outil SipP pour tester les communications
La fibre Optique et son déploiement. Du Schéma Directeur Territorial d’Aménagement Numérique à la FFTH. Mise en place d’une colonne montante dans un immeuble, les supports en FO.
Finalisation du cours sur la 4G avec Travaux Pratiques via le drive Test NEMO
IMS et test de la plate-forme OPENIMS (en cours).

Je vous propose de vous livrer mon cours sur la 4G découpé en différents articles. Je vais donc détailler les protocoles et l’architecture 4G, en m’appuyant sur des mesures de traces et en explicitant avec des calls-flows les différents interactions entre les équipements du réseau cellulaires.

Sur ce, bonne année 2015, et bonne lecture

Panne chez SFR – Rappel d’une autre panne en 2012

Posté le 24 juillet 2014 by flaunay - 4 236 vues

Le 6 juillet 2012, Orange était affecté par une panne nationale, l’équioement en défaut avait été identifié : le HLR/HSS lors de la mise à jour de ce dernier via Alcatel Lucent. Se référer à l’article : http://4glte.over-blog.com/article-panne-chez-orange-107869233.htm

Dans cet article, un ensemble d’hypothèse avait été faite pour lancer des pistes sur les pannes possible.

Aujourd’hui, jeudi 24 juillet, SFR fait façe à une panne nationale, les résultats de l’enquète incrime à nouveau la mise à jour du (d’un?) HLR par Alcatel Lucent,.

On peut alors se poser la question sur les procédures de mises à jour du HLR et pourquoi l’équipe Alcatel-Lucent est prise à défaut 2 ans près sur la mise à jour du HLR, d’autant plus que chaque HLR dispose d’un système de backup comme solution de secours. C’est ce qui avait d’ailleurs été fait en 2012 par Orange : Le logiciel NG HLR (Lew Generation HLR) avait été mis à jour la veille. Vers 17h30, le réseau a rebasculer sur des bases non mises à jour mais sans effet et pourtant, il s’agissait bien de l’équipement défectueux. Le NG-HLR contient une base de données définissant le type d’abonnement de tous les clients de l’opérateur et qui contient aussi la localisation des abonnés. Ces éléments sont stockés dans la partie Back End du NG-HLR et mise à jour chaque fois qu’un client se déplace dans une nouvelle zone de localisation (LAC). La mémoire de cette base de données était saturée. Pour résoudre ce problème, il a néanmoins fallu d’un grande concertation entre Orange et Alcatal Lucentet un travail remarquable de toutes les équipes.

Malgré l’analogie entre ces deux pannes, est ce la même panne?

Orange avait publié une vidéo didactique présentant la panne : http://www.dailymotion.com/video/xs4bs8_resolution-de-l-incident-reseau-le-deroule-en-details_tech

A priori il y a deux ans la panne touchait tous les abonnés, hors l’opérateur possède plusieurs HLR. Pour SFR, un ensemble de clients sont affectés (les nouveaux clients 3G et 4G). Un HLR peut on être incriminé par contre en 2012, un seul HLR ne pouvait pas être responsable de la panne des 26 millions de clients. Une autre hypothèse était de supposer que le HLR en question était le V-HLR, un HLR virtualisé jouant le rôle d’administration et d’interconnexion des HLR. Mais, cela n’a pas été évoqué ni par Orange, ni par Alcatel.

Pour anecdote, le site Presse-citron terminait l’article en relatant la vidéo par cette conclusion « Reste à savoir si Orange et ses concurrents sauront tirer toutes les conséquences de ce dysfonctionnement pour faire en sorte que cela n’arrive plus. »

LTE-Advanced (4G+) sera prochainement commercialisé

Posté le 12 mai 2014 by flaunay - 3 169 vues

Répondre

LTE-Advanced

Le LTE-Advanced, dénommé aussi LTE-A, a été défini dans la R10 (démarré en octobre 2009) et prévoyait une augmentation du débit en utilisant plusieurs porteuses (agrégation de porteuses). En 2013, les équipementiers expérimentaient les premiers smartphones (cf article S4-LTE-A) et depuis quelques mois les opérateurs Français (notamment Bouygues, Orange et Free) expérimente le LTE-A.

L’idée à déjà été exploitée en 3G avec la dénomination Dual Carrier et s’appuie sur le fait que le débit dépend de la bande de fréquence utilisée : Plus la bande est importante, plus le débit est élevé.

Concernant le LTE, celui-ci exploite une bande de 20 MHz au maximum ce qui permet d’avoir un débit de 150 Mbit/s. En agrégeant 5 porteuses, la bande totale atteint 100 MHz, le débit peut donc être 5 fois plus élevé. En augmentant le nombre d’antennes (MIMO) au niveau de l’émetteur et du récepteur et en améliorant la modulation radio (jusqu’à 256 QAM) lorsque les conditions radios sont excellentes (smartphone proche de l’antenne), le débit peut dépasser le Gbps.

Le LTE-A est défini pour atteindre des débits descendants de 1 Gbps. Son successeur, Le LTE-B, selon Huawei pourrait atteindre plusieurs dizaines de Gbps.

Expérimentation en France de la 4G+

En février, Bouygues dégainait en annonçant le réseau 4G sur Bordeaux et Lyon à partir de Juin 2014 en profitant du re-farming pour avoir la bande suffisante. Orange répliquait en annonçant l’expérimentation du LTE-A sur Bordeaux (pour un débit de 300 Mbps et une bande de 2*20 MHz).

Pour profiter du LTE-A, il faudra un nouvel abonnement (en augmentant la volumétrie de votre abonnement) mais également un smartphone compatible (évolution logicielle)

Free a utilisé un drone pour expérimenter la couverture en 4G+. Cela rappelle l’expérimentation Globalstar et Iridium avec des satellites en basses altitudes (LEO), enfin lisez bien la note du bas d’article (et regardez la date de publication).

Après ce coup de buzz de ZDnet (qui publie de très bons articles), retenez l’arrivée de la 4G+ pour Bouygues et Orange en Juin 2014, et SFR à partir de septembre.

Technologie de transport de la voix en 4G : CSFB (part 2)

Posté le 20 mars 2014 by flaunay - 7 624 vues

Gestion de la mobilité entre le réeau 2G/3G et LTE

Comme nous l’avons entrevu dans le précédent article, un réseau doit en permanence savoir localiser un mobile afin de fournir les services à l’ayant droit. La procédure de localisation se nomme « Mobility Management », c’est-à-dire Gestion de la mobilité.

Pour terminer un appel via la fonction CS Fallback, le domain CS doit connaitre la position du mobile en se référant à la localisation fournie par le réseau LTE, c’est-à-dire en se basant sur l’aire d’enregistrement du mobile indiquée par le MME. Le MME a donc la charge d’informer la VLR de la zone de localisation du mobile sur le réseau 4G.

Le cœur de réseau 3G possède déjà la fonction permettant de gérer simultanément la mobilité sur le réseau en commutation de circuit (CS) et en commutation de paquets(PS), chaque mobile étant géré sur une zone nommée LA (Location Area) pour la partie CS et RA (Routage Area) pour la partie PS.

Afin de réduire le trafic de signalisation sur les réseaux mobiles 2G/3G et 4G, l’enregistrement de localisation du mobile sur le réseau SGSN par la VLR est ré-utilisé par la technologie CS FallBack : Concernant les informations de localisation du mobile sur le réseau 4G (TA : Tracking Area), le MSC/VLR exploite donc la même logique que pour le réseau PS en 3G, c’est-à-dire la VLR demande les données d’enregistrement du mobile sur le réseau 4G et les exploite de manière identiques aux données d’enregistrement de localisation fournies par les requêtes venant du SGSN.

Cela permet d’une part d’éviter une mise à jour trop fastidieuse des MSC pour prendre en compte les requêtes de localisation sur le réseau 4G pour la voix.

Il faut également se rappeler qu’un terminal sur le réseau 4G ne peut être sur le réseau 2G/3G en même temps. Ceci implique que le MME, qui contient la zone d’enregistrement du mobile sur le réseau LTE (TA) doit être en mesure d’identifier vers quel VLR il doit envoyer ses messages de gestion de mobilité. Le MME contient donc une base de données de localisation permettant d’avoir la correspondance entre la zone de localisation du réseau 4G (TA) avec la zone de localisation du mobile sur la VLR (LA). Cette base de données permet donc de déterminer quel MSC/VLR doit être contacté pour l’enregistrement de la localisation du mobile.

La figure 2 détaille l’échange d’information entre le MME et la VLR : La VLR a identifié le MME sur lequel était géré le mobile et le MME connait la VLR et le LA associé à la position du mobile si ce dernier est sur le réseau 3G CS. A l’inverse, la VLR connait l’équipement MME associé.

Figure 2 : Mise à jour des données de localization sur la VLR et le MME

Si nous reprenons la figure précédente, le call flow est le suivant :

L’UE envoie une requête Tracking Area Update (TAU) vers le MME indiquant la position actuelle (TA) du mobile
Le MME accomplie la mise à jour de la position du mobile vers le HSS via une procédure Location Update
Le MME exploite la base de correspondance TA/LA pour identifier d’une part la zone de localisation LA du mobile correspondant au réseau de CS 2G/3G et la VLR correspondant, c’est-à-dire celui qui gère cette zone (LA). Via l’interface SGs, le MME envoie une requête LAU (Location Area Update) au MSC/VLR avec la valeur du LA correspondante.
La VLR qui reçoit la demande de mise à jour de localisation enregistre la correspondance de l’identité du MME ayant fait la requête de mise à jour (comme c’est le cas avec le SGSN) et l’identité unique du mobile (IMSI). Cela permet au VLR de savoir sur quel MME (comme c’est le cas avec le SGSN) le UE est actuellement connecté, ce qui est nécessaire pour un appel à destination d’un mobile connecté sur le réseau 4G.
La VLR lance une procédure d’enregistrement vers le HSS permettant à ce dernier de savoir sur quel VLR est maintenant enregistré le UE, et informe le MME du numéro TMSI affecté au mobile (Temporary Mobile Subscriber Identity).
Le MME informe le mobile de son identité TMSI et de sa localisation LA.

Technologie de transport de la voix en 4G : CSFB

Posté le 14 mars 2014 by flaunay - 12 964 vues

CSFB : Circuit Switched FallBack

Le réseau cœur déployé pour la 4G (nommé EPC : Evolved Packet Core) a été conçu pour s’interconnecter aux réseaux IP comme le LAN, la 3G, et évidemment le LTE.

Le principe du CS FallBack est assez simple : Lorsqu’un terminal mobile reçoit un appel téléphonique (Voix), il est informé via le message de Paging que le réseau auquel il doit accéder est le réseau de Commutation de Circuit (CS). Par conséquent, si le mobile était attaché sur le réseau 4G, il bascule vers le réseau 3G, et le mobile envoie une réponse d’acquittement vers le cœur de réseau en commutation de circuit (CS-Core). A partir de ce moment, toute la signalisation pour la session d’appel téléphonique est prise en charge par le réseau 3G. La figure 1 rappelle l’architecture des deux réseaux : CS sur le réseau 3G et PS sur le réseau 4G (EPC)

Figure 1 : Coeur Réseau 2G/3G et 4G

Pour que le Coeur de réseau 4G (EPC : Evolved Packet Core) soit compatible avec la technologie CSFB, il est nécessaire que ce dernier puisse communiquer avec le cœur de réseau en commutation de circuit CS-Core du réseau 2G/3G. En effet, le MME (mobility Management Entity) doit pouvoir contacter le MSC (Mobile Switch Center) et la VLR afin de donner procuration au réseau 2G/3G de la gestion de la mobilité. L’interface utilisée se nomme SG, et fait référence, en reprenant son rôle, à l’interface Gs existante entre le SGSN et le MSC dans le réseau 3G.

Lorsque l’appel est accepté, la technologie CSFB utilise à nouveau l’interface SG pour informer le réseau LTE de l’acceptation de l’appel. L’acquittement est donc transmis par le réseau en Commutation de Circuit (CS) vers le réseau LTE en empruntant l’interface SG.

Frédéric Launay

Les réseaux de mobiles 4G et 5G