Etude des protocoles GSM - Freesudriaesme.free.fr/archives/TP GSM/tp-gsm.pdf · Les premières données sont relatives au Routing Label ( DPC, OPC, SLS ), c'est-à-dire à l'acheminement

Département Signaux et Télécommunications

Etude des protocoles GSMCompte rendu du TP

Auteurs :

Sébastien Chardon, Fabien Delavier, Arnaud Lafouresse3BR - IRT04

Encadrés par : Vincent Babot

le 14/02/2007

Table des matières

Introduction 3

1 Etude de la localisation complète d'un abonné mobile 41.1 Quelle est la pile de protocoles mise en oeuvre lorsque le mobile se présente au

réseau pour la première fois ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Quels types d'informations ces protocoles transportent-ils ? En déduire leur ni-

veau dans le modèle OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.1 Niveau MTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.2 Niveau SCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.3 Le niveau BSSAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Comment l'abonné mobile se présente-t-il ? Pourquoi n'utilise-t-il pas son MSISDN? 61.4 Sait-on où il est localisé ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 Est-il reconnu par le réseau ? Quel est le rôle du TMSI ? . . . . . . . . . . . . . 71.6 Quelle identité doit indiquer l'abonné pour être reconnu ? . . . . . . . . . . . . 81.7 Comment se fait l'authenti�cation ? Quelles entités sont sollicitées dans cette

opération ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.8 Quel protocole est utilisé entre le VLR et le HLR? Pourquoi un échange d'in-

formations est-il nécessaire entre ces deux entités ? . . . . . . . . . . . . . . . . 101.9 Comment le VLR demande-t-il des informations sur l'abonné ? . . . . . . . . . 101.10 Quel numéro de téléphone faut-il composer pour appeler cet abonné mobile ? . 121.11 De quels services dispose celui-ci ? . . . . . . . . . . . . . . . . . . . . . . . . . . 121.12 Pourquoi réallouer un TMSI alors que l'abonné en possède déjà un ? . . . . . . 141.13 Décrivez la procédure de relâchement de la connexion ? Quels sont les niveaux

concernés ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.14 Représentez les di�érentes étapes de la localisation sur un schéma montrant les

interactions entre les entités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Interrogation d'un service supplémentaire 172.1 Comment se présente l'abonné ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2 Quelles sont les étapes de l'appel communes aux questions I et II . . . . . . . . 172.3 Que demande l'abonné au réseau ? . . . . . . . . . . . . . . . . . . . . . . . . . 182.4 Pourquoi y a-t-il un dialogue entre le VLR et le HLR? . . . . . . . . . . . . . . 192.5 Quelles sont les informations fournies par le HLR? . . . . . . . . . . . . . . . . 20

2

page 3 sur 34 Table des matières

2.6 Représentez l'ensemble des échanges sur un graphique . . . . . . . . . . . . . . 21

3 Tentative d'appel à partir d'un poste mobile barré en émission 223.1 Y a-t-il une di�érence entre demande de service et appel réel ? . . . . . . . . . . 223.2 Détaillez le message SETUP. Comparez-le à celui d'une communication RNIS . 233.3 Pourquoi l'appel n'aboutit-il pas ? Quelle entité est responsable du rejet ? . . . 243.4 Représentez l'ensemble des échanges sur un graphique . . . . . . . . . . . . . . 25

4 Appel émanant d'un abonné mobile 274.1 Identités des abonnés concernés . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Envoi d'un IDENTITY REQUEST . . . . . . . . . . . . . . . . . . . . . . . . . 284.3 Rôle du message ASSIGNMENT REQUEST . . . . . . . . . . . . . . . . . . . 284.4 HLR inactif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.5 In�uence du message CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . . 294.6 Libération de l'appel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Appel à destination d'un abonné mobile 315.1 Identités des abonnés concernés . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2 Rôle du HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3 Rôle du MSRN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.4 Message envoyé par le VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.5 Mécanismes de sécurité lors du PAGING RESPONSE . . . . . . . . . . . . . . 335.6 Représentation des échanges de signalisation . . . . . . . . . . . . . . . . . . . . 33

2006-2007 TP GSM - Groupe IRT04 ESME Sudria - 3BR

page 4 sur 34 Introduction

Introduction

Le document ici présent synthétise le TP GSM, au cours duquel nous avons analysé destraces GSM dans de multiples cas d'utilisation :

� recherche de la localisation d'un mobile,� utilisation d'un service,� appels échoués,� appels entrants et sortants.


page 5 sur 34 Etude de la localisation complète d'un abonné mobile

Partie 1Etude de la localisation complète d'un

abonné mobile

1.1 Quelle est la pile de protocoles mise en oeuvre lorsque le

mobile se présente au réseau pour la première fois ?

Le premier message envoyé par le mobile est un Connection Request, la liste des couchesest la suivante :

ProtocolesNiveau Haut BSSMAP DTAP

BSSAPNiveau SCCPNiveau Bas MTP

1.2 Quels types d'informations ces protocoles transportent-ils ?

En déduire leur niveau dans le modèle OSI

1.2.1 Niveau MTP

Les di�érents champs de la partie MTP donnent des indications sur la trame MSU trans-mise vers le réseau :

� FSN et BSN : indiquent le numéro de la trame envoyée dans un sens ou dans l'autrede la communication

� FIB et BIB : permettent de gérer le mécanisme d'acquittement de trame� LI : nombre d'octets d'information utile (données utilisées dans les couches supérieures)� SIO : qui permet d'indiquer à quel sous-système utilisateur on s'adresse (ici SCCP)



Tous ces champs sont donc au service de la �abilisation de la communication. On en déduitque cette couche MTP correspond à la couche Liaison du modèle OSI, c'est-à-dire le niveauMTP-2 du modèle SS7.

1.2.2 Niveau SCCP

Les premières données sont relatives au Routing Label ( DPC, OPC, SLS ), c'est-à-direà l'acheminement du message dans le réseau :

1 Destination Point Code : 0- 0-4

2 Originating Point Code : 0- 1-3

3 Signalling link selection : 15

Ensuite est indiqué le type de message SCCP, ici on a a�aire à un Connection Request :

1 Message type : 01h = CR

En�n on retrouve la partie Message Information avec :� La partie �xe obligatoire qui nous indique notamment que la connexion est en modeconnecté de base (classe 2) :

1 --- Connection Request ---

2 Source Local Reference : 329566

3 --- Protocol Class ---

4 Protocol Class : 2 = Class 2 - Basic

5 connection-oriented class

6 Spare : 0000....

� La partie variable obligatoire qui nous fournit des informations détaillées sur les adressesd'émetteur et de récepteur :

1 Pointer to Mandatory Parameters : 2

2 Pointer to Optional Parameters : 4

3 Length : 2

4 --- Called Party Address ---

5 ...

6 --- Calling Party Address ---

7 ...

On en déduit que ce niveau SCCP correspond à la couche 3 du modèle OSI, la couche ré-seau (bien que la gestion de la connexion fasse parti plutôt de la couche transport du modèleOSI).



1.2.3 Le niveau BSSAP

Au niveau BSSAP on distingue les protocoles BSSMAP et DTAP.

� Le protocole BSSMAP fournit de nombreuses informations qui ont trait à la gestion desressources radio (paramètres de la cellule radio) :

1 --- Cell Identifier ---

2 Spare : 0000....

3 Cell identification discriminator : 0

4 Mobile Country Code Digits : 208

5 Spare : 1111...

6 Mobile Network Code Digits : 01

7 Location Area Code : 768

8 Cell Identifier Value : 925

9 Information Element Id : 17h

Cette sous-couche BSSMAP complète donc la couche 3 du modèle OSI en fournissantles informations nécessaires à l'acheminement du message.

� Le niveau DTAP nous fournit des données relatives à la classeMobility Management(MM) dont l'objectif est ici de faire une mise à jour de localisation de l'abonné :

1 === Dtap ===

2 Protocol Discriminator : 5h = MM

3 Skip indicator : 0

4 Message Type : 08h = Location updating

5 request

Pour que le réseau GSM puisse reconnaître ce nouvel entrant, la couche MM rappelleles informations de localisation et d'identi�cation :

1 ...

2 --- Location area identification ---

3 ...

4 --- Mobile identity ---

5 ...

Ce niveau DTAP fait donc lui aussi parti de la couche Réseau du modèle OSI puisqu'ils'occupe toujours de l'identi�cation sur le réseau comme pourrait le faire IP.

1.3 Comment l'abonné mobile se présente-t-il ? Pourquoi n'utilise-

t-il pas son MSISDN?

Le mobile se présente au réseau avec son TMSI. La première trame CR fournit dans sacouche MM l'ancien TMSI du mobile :

1 Location updating request 208 01 0300

2 TMSI 04DFB248



Le MSISDN correspond au numéro de téléphone de l'abonné. Il n'est donc pas possible,pour des raisons de sécurité, que le mobile s'authenti�e avec ce numéro. Sinon il serait trèsfacile à une personne voulant pro�ter du réseau de se faire passer pour un autre abonné, uni-quement en connaissant son numéro de téléphone.

Le vrai numéro d'identité (unique) est le numéro IMSI présent à la fois sur le HLR etsur la puce du mobile. Pour tout MSISDN correspond un numéro IMSI. Ceci permet plus de�exibilité car en cas de vol ou en cas de changement d'opérateur il est facile de changer l'IMSItout en gardant le même MSISDN, ceci de manière transparente pour l'usager.

1.4 Sait-on où il est localisé ?

On sait où le mobile est localisé car la trame CR nous indique à deux reprises les informa-tions nécessaires suivantes :

� Pays : France (MCC = Mobile Country Code)� Opérateur : Orange (MNC = Mobile Network Code)� 300h = identi�cation de la zone contenant la cellule� ...La première fois, la localisation est indiquée dans la couche BSSMAP et elle sert à la BSC

pour gérer la transmission radio :

1 --- Cell Identifier ---

2 Spare : 0000....

3 Cell identification discriminator : 0

4 Mobile Country Code Digits : 208

5 Mobile Network Code Digits : 01

6 Location Area Code : 768

7 Cell Identifier Value : 925

La deuxième fois, c'est la couche DTAP qui fournit les informations de localisation quisont cette fois ci destinées au MSC et à la couche MM :

1 --- Location area identification ---

2 MCC digit : 208

3 MNC digit : 01

4 Location area identification : 0300h

1.5 Est-il reconnu par le réseau ? Quel est le rôle du TMSI ?

Tout d'abord, il faut di�érencier la connexion du mobile au réseau GSM avec l'identi�cationdu mobile sur le réseau ; ces deux échanges n'agissent pas aux même niveaux, la connexions'établit au niveau SCCP et l'identi�cation est gérée au niveau supérieur BSSAP.L'abonné se connecte avec succès au MSC puisque les messages RC et CC se succèdent sansproblèmes.Par contre, la première identi�cation est un échec. En e�et, le troisème MSU envoyé au mobile



contient un message du type Identity Request. Le mobile n'est donc pas reconnu et le MSClui demande de s'identi�er :

1 LU3 FromRCP BSSAP 00:20.477

2 ...

3 === Dtap ===

4 Message Type : 18h = Identity request

5 --- Identity request ---

6 Location area identification : 0300h

7 --- Identity type ---

8 Type of identity : .....001 = IMSI

Le rôle du TMSI est de remplacer l'IMSI pour assurer l'anonymat de l'usager mobile. En e�et,le TMSI est temporaire et est unique seulement sur le MSC considéré.

1.6 Quelle identité doit indiquer l'abonné pour être reconnu ?

En théorie, TMSI et IMSI ont pour but d'identi�er le mobile. Cependant, la première foisque le mobile se présente au réseau, il est nécessaire d'envoyer l'IMSI au MSC pour que lemobile soit clairement identi�é. Ensuite seulement sera a�ecté un numéro TMSI qui remplaceral'IMSI lors des échanges.Dans notre cas, le mobile répond à la requête du MSC avec le message suivant :

1 LU3 ToRCP BSSAP 00:20.897 MSU nSCCP 0- 0-4 0- 1-3 15

2 DT1 Identity response IMSI 208011000000002

Le mobile a donc comme IMSI : 208011000000002

1.7 Comment se fait l'authenti�cation ? Quelles entités sont sol-

licitées dans cette opération ?

En théorie :

Lorsque l'usager mobile envoit son numéro IMSI, il est identi�é au niveau du HLR del'opérateur. Ensuite, le HLR consulte l'AUC (centre d'authenti�cation) pour lancer la phased'authenti�cation :

� L'AUC sélectionne une clé Ki (à chaque IMSI correspond dans l'AUC une clé de cryptageKi) et récupère un nombre aléatoire RAND.

� A partir de l'algorithme A3 et des données Ki et RAND, l'AUC calcule un nombreSRES.

� De son côté, le mobile récupère le RAND généré par l'AUC et fait la même opérationen utilisant le Ki et l'algorithme A3 enregistrés dans la puce.

� Le Mobile envoie son résultat SRES au NSS et il est confronté au SRES fourni parl'AUC.



� Si les SRES sont identiques le mobile est correctement authenti�é, autrement le mobilese voit bloquer l'accès au réseau GSM.

� Si l'authenti�cation aboutit positivement, le mobile et l'AUC calculent une clé de chi�re-ment Kc qui sera utilisée lors des échanges de données. Pour calculer Kc, ils ré-utilisentla clé Ki et le RAND avec l'algorithme A8.

Dans notre cas :

Valeur du nombre aléatoire (16x8bits = 128 bits) envoyé par le NSS au mobile :

1 --- Authentication parameter RAND ---

2 RAND value : 11100011b
















Réponse du Mobile, le SRES calculé (32bits) :

1 --- Authentication parameter SRES ---

2 SRES value : 11100011b




L'authenti�cation se déroule avec succès puisque par la suite le HLR fournit les informationsde l'abonné au VLR, VLR qui correspond au MSC où se trouve le mobile.



1.8 Quel protocole est utilisé entre le VLR et le HLR? Pourquoi

un échange d'informations est-il nécessaire entre ces deux

entités ?

La couche protocolaire particulière utilisée entre le VLR et le HLR est TCAP. Pour chaqueéchange entre le VLR et le HLR, la structure de la trame MSU est la suivante :

1 LU3 ToRCP MAP 00:21.723

2 === Message Transfer Part ===

3 ...

4 Service Information Octet : 83h = nSCCP

5 === Signalling Connection Control Part ===

6 ...

7 --- DATA Parameter ---

8 === Transaction Capabilities Appl. Part ===

9 ...

Donc, on retrouve trois niveaux de la pile de protocoles du système Sémaphore 7 :� TCAP� SCCP� MTPPar rapport aux trames précédentes, une nouvelle couche apparaît, c'est la couche TCAP.

Ceci reste logique puisque TCAP est une véritable boîte à outils pour échanger avec les basesde données comme les VLR et le HLR.

Les échanges entre VLR et HLR sont importants puisque les VLRs suivent les déplacementsde l'abonné et indiquent en même temps au HLR tout changement de VLR. Ainsi le HLRsait à n'importe quel moment sur quel MSC se situe l'abonné et le MSC peut indiquer grâceà son VLR sur quelle cellule se trouve l'abonné. En même temps, le VLR récupère sur le HLRles informations de l'abonné permettant d'assurer la communication (numéro IMSI, servicesautorisés, paramètres de chi�rement ...).

1.9 Comment le VLR demande-t-il des informations sur l'abonné ?

Le VLR débute la demande d'informations sur l'abonné à partir du moment où il envoiel'IMSI au HLR pour lancer l'authenti�cation :

1 LU3 FromRCP MAP 00:20.931 MSU nSCCP 0- 18-3 0-100-2 6 UDT HLR

2 0-100-2 VLR BEGIN ORIG TID: A45C3D6D INVOKE INVOKE ID: 128 Send

3 parameters IMSI: 208011000000002F Request authentification set

A partir de ce moment, le HLR peut calculer le SRES et le confronter ensuite avec celuicalculé par le mobile. Une fois l'authenti�cation con�rmée, le VLR du MSC reçoit du HLRles informations importantes de l'abonné :

1 LU3 ToRCP MAP 00:21.723 MSU nSCCP 0-100-2 0- 18-3 12

2 UDT VLR 0- 18-3 HLR CONTINUE ORIG TID: 170000DC



3 DEST TID: A45C3D6E INVOKE INVOKE ID: 128

4 Insert subscriber data ADDRESS: 33607100002F

5 serviceGranted Telephony

6 Emergency calls

7 Short message MT/PP

8 Short message MO/PP

9 Automatic Facsimile Group 3

10 SS-DATA Speech transmission

11 SS-DATA Facsimile

12

13 LU3 ToRCP MAP 00:21.735 Error: ASN.1 SEQUENCE is shorter than length

14 indicates

15 Error: ASN.1 SEQUENCE is shorter than length indicates

16 MSU nSCCP 0-100-2 0- 18-3 12 UDT VLR 0- 18-3 HLR CONTINUE

17 ORIG TID: 170000DC DEST TID: A45C3D6E INVOKE INVOKE ID: 129 Insert

18 subscriber data Facsimile

Le VLR acquitte ensuite la bonne réception des informations des deux trames précédentes :

1 LU3 FromRCP MAP 00:21.763 MSU nSCCP 0- 18-3 0-100-2 14

2 UDT HLR 0-100-2 VLR CONTINUE

3 ORIG TID: A45C3D6E

4 DEST TID: 170000DC

5 RET RESULT INVOKE ID: 128

6

7 LU3 FromRCP MAP 00:21.775 MSU nSCCP 0- 18-3 0-100-2 14

8 UDT HLR 0-100-2 VLR CONTINUE

9 ORIG TID: A45C3D6E

10 DEST TID: 170000DC

11 RET RESULT INVOKE ID: 129

En�n, le HLR indique au VLR que l'échange est terminé et il envoie un message pourcon�rmer la �n des échanges d'informations :


2 UDT VLR 0- 18-3 HLR END DEST TID: A45C3D6E

3 RET RESULT INVOKE ID: 128 Update location

Résumé de l'échange d'informations entre le VLR et le HLR :

Ordre Emetteur Destinataire Numéro de requête Requête1 VLR HLR 128 Send parameter2 HLR VLR 128 Insert subscriber data3 HLR VLR 129 Insert subscriber data4 VLR HLR 128 Result5 VLR HLR 129 Result6 HLR VLR 128 Update Location



1.10 Quel numéro de téléphone faut-il composer pour appeler

cet abonné mobile ?

Le numéro de l'abonné est fourni lors de la première réponse du HLR au VLR :


2 UDT VLR 0- 18-3 HLR CONTINUE

3 ORIG TID: 170000DC DEST TID: A45C3D6E

4 INVOKE INVOKE ID: 128

5 Insert subscriber data ADDRESS: 33607100002F ...

Le numéro de téléphone ( appellé Insert subscriber data ADDRESS) vaut donc : 06 07100002.

1.11 De quels services dispose celui-ci ?

Le HLR indique que l'abonné dispose des services suivants :

1 --- TeleserviceList ---

2 TeleserviceCode : 00010001b = Telephony ( La telephonie )

3 TeleserviceCode : 00010010b = Emergency calls ( Appels d'urgence )

4 TeleserviceCode : 00100001b = Short message MT/PP ( SMS sortants )

5 TeleserviceCode : 00100010b = Short message MO/PP ( SMS entrants )

6 TeleserviceCode : 01100010b = Automatic Facsimile Group 3 (fax

7 automatique en emission et en reception)

L'abonné peut potentiellement avoir accès à plusieurs services supplémentaires.

Pour le transfert d'appel ou de fax lorsque le destinataire est occupé, le service n'est pasdisponible :

1 --- ForwardingInfo ---

2 ...

3 SS-Code : 00101001b = Call forw. om mobile subscr. busy

4 TeleserviceCode : 00010000b = Speech transmission

5 Activation indicator : .......0 = Not Active

6 Registration indicator : ......0. = Not Registered

7 Provision indicator : .....1.. = Provisioned

8

9 TeleserviceCode : 01100000b = Facsimile




13 ...

Le transfert d'appel est activé lorsque le destinataire de répond pas. Par contre ce service n'estpas activé pour le fax :



1 SS-Code : 00101010b = Call forwarding on no reply


3 Activation indicator : .......0 = Active

4 Registration indicator : ......0. = Registered


6





11 ...

Le transfert d'appel pour un destinataire non atteignable n'est pas disponible à la fois pourles appels et les faxs :

1 SS-Code : 00101011b = Call forw. on subscr. not reachable





6





11 ...

En�n, le blocage des appels sortants n'est pas activé mais par contre le blocage des SMSsortants est lui activé :

1 --- Call barring information ---

2 ...

3 SS-Code : 10010010b = Barring of all outgoing calls

4





9

10 TeleserviceCode : 00100000b = Short message services






Pour �nir, le service d'avertissement sonore pour indiquer d'un second appel (call waiting)lors d'une communication est activé :

1 -- SS-Data ---

2 ...

3 SS-Code : 01000001b = Call waiting




Pour résumer, parmi les services supplémentaires on trouve :� Le transfert des appels reçus (lorsque l'abonné ne répond pas) vers le numéro : 06 07100004.

� Le blocage des envois de SMS� L'avertissement sonore pour indiquer d'un second appel (call waiting) lors d'une com-munication.

1.12 Pourquoi réallouer un TMSI alors que l'abonné en possède

déjà un ?

La première raison souvent évoquée pour justi�er d'un changement de TMSI est l'ano-nymat du mobile. En e�et, si l'adresse du mobile change régulièrement, il devient di�cile àune personne "sni�ant" le réseau d'identi�er le mobile. Ceci permet notamment de minimisertoute usurpation d'identité.La deuxième raison du changement de TMSI est d'assurer l'unicité de l'adresse du mobile surréseau dans lequel il se trouve. Or, les TMSI ne sont uniques que dans le MSC auquel ils sontrattachés. De ce fait, lorqu'il faut changer de MSC, il faut de nouveau demander un numéroTMSI et se faire enregistrer dans le nouveau VLR.

La réa�ectation du TMSI s'est opérée vers la �n de la séquence de localisation, avant queles ressources soient relâchées :

1 LU3 FromRCP BSSAP 00:22.091 MSU nSCCP 0- 1-3 0- 0-4 15

2 DT1 TMSI reallocation command 208 01 0300 TMSI 04DFB24A

1.13 Décrivez la procédure de relâchement de la connexion ?

Quels sont les niveaux concernés ?

Entre le BSC et le MSC, Le relâchement de la connexion s'e�ectue en deux temps et àdeux niveaux :

� Relâchement de niveau Liaison, niveau 2 :Le MSC envoie au BSC unClear Command qui entraîne un relâchement des ressourcesradio :



1 LU3 FromRCP BSSAP 00:22.569 MSU nSCCP

2 0- 1-3 0- 0-4 15 DT1

3 Clear Command Call control

4 LU3 ToRCP BSSAP 00:22.613 MSU nSCCP

5 0- 0-4 0- 1-3 15 DT1

6 Clear Complete

� Relâchement de niveau Réseau, niveau 3 :Le MSC envoie au BSC un Release Command qui a pour objectif de mettre un termeà la connexion mise en place au niveau SCCP. De ce fait, cette deuxième commandepermet de libérer le canal sémaphore utilisé entre le BSC et le MSC :

1 LU3 FromRCP BSSAP 00:22.627 MSU nSCCP

2 - 1-3 0- 0-4 15 RLSD

3 LU3 ToRCP BSSAP 00:22.647 MSU nSCCP

4 - 0-4 0- 1-3 15 RLC

1.14 Représentez les di�érentes étapes de la localisation sur un

schéma montrant les interactions entre les entités



Fig. 1.1 � Di�érentes étapes de la localisation


page 18 sur 34 Interrogation d'un service supplémentaire

Partie 2Interrogation d'un service supplémentaire

2.1 Comment se présente l'abonné ?

L'abonné va se présenter grâce à la couche BSSAP, auprès du RCP. Pour cela il envoieson TMSI, dernière clé temporaire utilisée, et son LAI, zone de localisation actuelle du mobile.

Voici la trame envoyée :

1 LU3 ToRCP

2 BSSAP 00:18.756 MSU nSCCP 4h Bh 0 CR BSSAP Bh BSSAP

3 Complete Layer 3 Information

4 CELL ID 208 01 768 925

5 CM service_request

6 TMSI 04DFB24A

Détail de la trame précédente :� Ligne 1 : Montre que le message va du mobile vers le RCP (ToRCP) c'est-à-dire versle MSC.

� Ligne 2 : Niveau SCCP. (CR signi�e Connection Request)� Ligne 4 : Indique la location du mobile (LAI)� Ligne 5 : CM (Connnexion Management, sous couche du niveau DTAP) indique quele mobile tente d'interroger un service.

� Ligne 6 : TMSI du mobile

2.2 Quelles sont les étapes de l'appel communes aux questions

I et II

Ce cas est di�érent du cas précédent. En e�et on remarque qu'il n'y a pas de demanded'identi�cation du mobile (Identity Request), le MSC ne demande pas au mobile de lui redon-ner son numéro IMSI. Ceci veut dire que ce mobile est déjà identi�é auprès du VLR grâce àsa clé temporaire TMSI. Il n'y a donc pas d'informations échangées entre le VLR et le HLR(pour l'identi�cation).



Détail de la connexion de niveau SCCP :

1 [...] CR BSSAP CELL ID 208 01 768 925 CM service_request TMSI 04DFB24A

2 [...] CC BSSAP

Comme dans la partie 1, la connexion de niveau 3 se passe sans problèmes. On remarqueque le mobile envoie de la même façon que précédemment (lors du CR) l'ensemble des infor-mations que requiert la MSC : TMSI, LAI (localisation).

Cependant, contrairement à la partie 1, le MSC valide directement l'identi�cation du mobilesans envoyer de message Identity Request après le message CC. Le mobile passe directementen phase d'authenti�cation (cf. ligne 2 suivante) :

1 LU3 FromRCP BSSAP 00:18.773 MSU

2 SCCP Bh 4h 4 CC BSSAP

3 LU3 FromRCP BSSAP 00:18.789 MSU

4 SCCP Bh 4h 4 DT1 Authentication request

Le reste des opérations se déroulent de la même manière que dans le cas précédent :

1 [...] Authentication request

2 [...] Authentication response

3

4 [...] Cipher Mode Command

5 [...] Cipher Mode Complete

6

7 [...] Clear Command Call control

8 [...] Clear Complete

9 [...] RLSD

10 [...] RLC

� Lignes 1 et 2 : Demande d'authenti�cation du mobile demandée par le réseau (envoidu RAND), et réponse du mobile (SRES).

� Lignes 4 et 5 : Passage dans le mode Cipher, les transmissions entre le mobile et leréseau vont maintenant être cryptées.

� Ligne 7 et 8 : Demande et con�rmation de la libération des ressources Radio.� Ligne 9 et 10 : Demande et con�rmation du relâchement des canaux de signalisation.

2.3 Que demande l'abonné au réseau ?

Première trame envoyée par le mobile au réseau :

1 LU3 ToRCP

2 BSSAP 00:18.756 MSU nSCCP 4h Bh 0 CR BSSAP Bh BSSAP

3 Complete Layer 3 Information

4 CELL ID 208 01 768 925

5 CM service_request

6 TMSI 04DFB24A



Au moment de son identi�cation, le mobile fait la demande du service souhaité. Ici larequête est CM service_request. Celle-ci demande au système l'ouverture d'une connexionpour activer un nouveau service (cf. ligne 4 suivante). Le réseau véri�era la liste des servicesautorisés pour cet abonné.

1 Message Type : 24h = CM service_request

2 --- CM service request ---

3 --- CM service type ---

4 Service type : ....1000 = supplementary service activation

5 Length : 2

2.4 Pourquoi y a-t-il un dialogue entre le VLR et le HLR?

On remarque que 3 messages vont circuler entre le VLR et le HLR. Un premier étant unerequête venant du VLR vers le HLR, le second correspond à la réponse du HLR, et en�n ledernier est l'acquittement du VLR a�n de relâcher les ressources de communication entre leVLR et le HLR :

1 LU3 FromRCP

2 MAP 00:19.946 MSU nSCCP 0- 18-3 0-100-2 15 UDT

3 HLR 0-100-2 VLR

4 BEGIN ORIG TID: C45C2173 INVOKE

5 INVOKE ID: 80

6 Begin subscriber activity IMSI: 208011000000002F INVOKE

7 INVOKE ID: 0

8 Interrogate SS

9

10 LU3 ToRCP

11 MAP 00:19.997 MSU nSCCP 0-100-2 0- 18-3 3 UDT

12 VLR 0- 18-3 HLR

13 END DEST TID: C45C2173 RET RESULT

14 INVOKE ID: 0

15 Interrogate SS SS-DATA Speech transmission SS-DATA Facsimile

16

17 LU3 FromRCP

18 BSSAP 00:20.021 MSU nSCCP Bh 4h 4 DT1

19 Release complete

20 normal call clearing RET RESULT

21 INVOKE ID: 0

22 Interrogate SS SS-DATA SS-DATA

Cette échange d'information va permettre au VLR d'en savoir plus à propos de l'abonnéet de ses droits. Il va dans ce cas demander s'il a le droit au nouveau service demandé.



Cette requête n'est pas toujours utile. En e�et, si le VLR connait déjà l'abonné et qu'il adéjà e�ectué une telle requête, il conserve l'ensemble des informations dans sa base de donnéeslocale.

Dans cette transaction, on remarque que le VLR demande les informations sur les servicessupplémentaires grâce à Interrogate SS.

2.5 Quelles sont les informations fournies par le HLR?

Grâce à la seconde requête vu dans la question précédente, le HLR va répondre à la ques-tion Interrogate SS posée par le VLR. Le HLR va alors lui donner la liste des servicessupplémentaires qu'a droit l'abonné en question. Comme on peut le remarquer, l'utilisateura en e�et droit à deux sous services supplémentaires. Un de ces services correspond à la voix(SS-DATA Speech transmission) et le second aux fax (SS-DATA Facsimile).

1 === Mobile Application Part (Phase 2) ===

2 Operation Code : 14 = Interrogate SS

3 --- ForwardingFeatureList ---

Réponse du HLR à la question Interrogate SS...

1 --- SS-Data ---


3 --- SS-Status ---




7 Unused : 00000...

8 --- ForwardedToNumber ---

9 Numbering plan : ....0001 = ISDN/Telephony Number Plan

10 Nature of address : .001.... = international number

11 Extension indicator : 1.......

12 Address signals : 33146211068F

Premier service : Transfert d'appel vers le numéro de type téléphonie �xe 01.46.21.10.68.

1 --- SS-Data ---


3 --- SS-Status ---




7 Unused : 00000...



8 --- ForwardedToNumber ---

9 Numbering plan : ....0001 = ISDN/Telephony Number Plan

10 Nature of address : .001.... = international number

11 Extension indicator : 1.......


Second service : Transfert des fax vers le numéro 01.46.21.10.68.

2.6 Représentez l'ensemble des échanges sur un graphique

Fig. 2.1 � Di�érentes étapes de la véri�cation de services supplémentaires


page 23 sur 34 Tentative d'appel à partir d'un poste mobile barré en émission

Partie 3Tentative d'appel à partir d'un poste mobile

barré en émission

3.1 Y a-t-il une di�érence entre demande de service et appel

réel ?

Le début de la transaction est identique au cas précédent. En e�et, on retrouve les 3 étapessuivantes :

� Connexion au réseau au niveau 3 (CR et CC) avec envoi du TMSI pour l'identi�cation.� Authenti�cation du mobile (réception du RAND et envoi du SRES)� Passage en mode crypté (Cipher Mode).

Les 3 étapes en question apparaissent de la manière suivante :

1 [...] BSSAP Bh BSSAP Complete Layer 3 Information CELL ID 208 01 768 925

2 CM service_request TMSI 04DFB24A

3 [...] BSSAP

4

5 [...] Authentication request

6 [...] Authentication response

7

8 [...] Cipher Mode Command

9 [...] Cipher Mode Complete

On remarque ensuite les di�érences. Le RCP demande une authenti�cation plus détailléeau mobile : notament son IMEI (Internationnal Mobile Equipment Identity). Cet identi�antest un numéro correspondant au mobile. Celui-ci permet d'identi�er de manière unique unterminal mobile.

1 [...] Identity request



En détail on voit la requête précisemment à propos du IMEI :


2 [...]



5 Spare : ....0...

6 Type of identity : .....010 = IMEI

Le téléphone portable devrait ensuite envoyer son identi�ant demandé au réseau. Cet iden-ti�ant va permettre au système de savoir si le mobile étudié est un terminal volé. L'opérateurdispose d'une base de données contenant l'ensemble des terminaux considérés comme volés oubloqués. Cette base est appelé EIR (Equipment Identity Register).

Avant qu'il n'ait le temps de répondre à la demande d'IMEI, la demande d'appel del'abonné va être rejeté par le réseau :

1 [...] Setup CLD P NUMB 0146211068

2 [...] Release complete normal, unspecified INVOKE INVOKE ID: 0 Notify SS

La �n des transactions se terminent comme les cas précédents (libération des ressourcesradio puis libération des canaux physiques).

1 [...] Clear Command Call control

2 [...] Clear Complete

3 [...] RLSD

4 [...] RLC

3.2 Détaillez le message SETUP. Comparez-le à celui d'une

communication RNIS

Trame simple du message SETUP :

1 LU3 ToRCP BSSAP 00:45.528 MSU nSCCP 4h Bh 15 DT1 Setup CLD P NUMB 0146211068

Version détaillée :

1 === Dtap ===

2 Message Type : 05h = Setup

3 --- Setup ---

4 --- Bearer capability ---

5 Information transfer capability : .....000 = speech

6 Transfer mode : ....0... = circuit mode

7 Coding standard : ...0.... = GSM standardized coding



8 Radio channel requirement : .01..... = full rate support only

9 mobile station

10 Ext : 1.......

11 --- Called party number ---

12 Numbering plan identification : ....0001 = ISDN/telephony

13 numbering plan

14 Type of number : .000.... = unknown

15 Ext : 1.......

16 Number digit : 0146211068

Ce message SETUP permet l'initialisation de l'appel sortant. Nous voyons dans cette trameque le numéro est 01.46.21.10.68. Le mobile dans ce cas appel vers un téléphone �xe.

La première partie de la trame vu au dessus (Bearer capability) donne les informationssur les ressources (débit) demandé par le téléphone a�n de réaliser le service qu'il demande(si cette demande est acceptée). La seconde partie donne les informations concernant l'appelen lui même (ligne �xe et son numéro).

� Ligne 5 : Service type voix (speech).� Ligne 7 : Utilisation de la technologie GSM� Ligne 8 : Codage de la voix : FR (Full Rate) seulement supporté par le mobile� Ligne 12 : Appel vers un téléphone �xe� Ligne 16 : Numéro à appeler (01.46.21.10.68)

On peut remarquer la di�érence avec le réseau RNIS. En e�et ici le numéro de l'appeléest envoyé en une seule fois, en entier. Alors que sur le réseau �xe, le numéro est envoyé etanalysé chi�re par chi�re.

3.3 Pourquoi l'appel n'aboutit-il pas ? Quelle entité est respon-

sable du rejet ?

1 LU3 FromRCP

2 BSSAP 00:45.561 MSU nSCCP Bh 4h 15 DT1

3 Release complete

4 normal, unspecified

5 INVOKE INVOKE ID: 0

6 Notify SS

Dans cette trame, on remarque que le réseau envoie au mobile qu'il n'a pas le droit auservice demandé. Sa requête est donc annulée. Ici son appel sortant n'aboutira pas.

Voici en détail la réponse du réseau :

1 === Supplementary Services Operations ===

2 Operation Code : 16 = Notify SS



3 --- Argument ---

4 SS-Code : 10010001b

5 --- SS-Status ---

6 [...]

7 Provision indicator : .......1 = Provisioned


9 Activation indicator : .....1.. = Active

10 Unused : 00010...

Le réseau envoie une "noti�cation sur un service supplémentaire". Le SS-Code présenté icinous renseigne sur cette noti�cation : Appel sortant interdit (comme indiqué à la ligne 8, leservice est NOT REGISTERED.

Dans notre cas, c'est le VLR qui est responsable du rejet. En e�et il connait déjà l'ensembledes services auxquels l'abonné a droit. Il avait récupéré cette liste à partir du HLR lors de lapremière connexion du téléphone.

3.4 Représentez l'ensemble des échanges sur un graphique



Fig. 3.1 � Description de la tentative d'appel


page 28 sur 34 Appel émanant d'un abonné mobile

Partie 4Appel émanant d'un abonné mobile

4.1 Identités des abonnés concernés

La trame SETUP envoyée par le mobile pour lancer l'appel nous renseigne sur l'appelé :

1 LU3 ToRCP BSSAP 00:29.122

2

3 [...]

4

5 --- Called party number ---

6 Numbering plan identification : ....0001 = ISDN/telephony

7 Type of number : .000.... = unknown

8 Ext : 1.......

9 Number digit : 0146211068

Donc, le numéro de téléphone (MSISDN) appelé est le 01 46 21 10 68 (ligne 9).Lors du CR, le mobile de l'appelant nous fournit son TMSI :


2

3 [...]

4


6 Type of identity : .....100 = TMSI

7 Odd / Even indicator : ....0... = even

8 Filler : 1111....

9 Data : 04DFB24Ah

L'indenti�ant temporaire de l'appelant sur le VLR (le TMSI) est 04DFB24A (ligne 9).En�n, l'abonné mobile peut aussi se faire identi�er par le numéro IMEI de son mobile qui estunique. Cette information, nous est donnée lorsque le mobile de l'appelant répond au IdentityRequest du MSC :


2



3 [...]

4



7 Odd / Even indicator : ....1... = odd

8 Identity Digits : 442502190222680

L'identi�ant du téléphone portable de l'appelant (l'IMEI) est 442502190222680 (ligne 8).

4.2 Envoi d'un IDENTITY REQUEST

Le réseau fait la demande de l'IMEI de l'appelant par le biais de la requête suivante :


2

3 [...]

4


6 --- Spare Half Octet ---

7 Spare : 0000....


9 Spare : ....0...


Le RCP demande l'IMEI (identi�ant du téléphone) de l'appelant. Cet identi�ant propre àchaque téléphone permet de connaître les caractéristiques du téléphone (et ainsi les servicesutilisables sur ce téléphone). L'IMEI permet aussi de savoir si le téléphone a été volé ousi il peut potentiellement entraîner des bogues (l'opérateur pourra prendre des mesures enconséquence).

4.3 Rôle du message ASSIGNMENT REQUEST

Le MSC envoie un message ASSIGNMENT REQUEST au BSC pour allouer un canal devoix (TCH).


2

3 [...]

4

5 === BSS Mobile Application Part 2 ===

6 Message Type : 01h = Assignment Request

7 --- Assignment Request ---

8 Information Element Id : 0Bh

9 Length : 03h

10 --- Channel type ---

11 Spare : 0



12 Speech or data indicator : 1 = Speech

13 Channel rate and type : 8 = Full rate TCH channel B

14 Speech enc. /Data rate : 1 = GSM speech algorithm ve


16 Length : 02h

17 --- Layer 3 Header Information ---

18 Spare : 0000....

19 Protocol Discriminator : ....0110 = Radio resources

20 Spare : 0000....

21 TI Flag : ....0... = The message is s

22 TI Value : .....000 = TI Value 0


24 Length : 1

Lors de la requête, diverses informations sur la nature (TCH) et les caractéristiques du canalsont communiquées.

4.4 HLR inactif

Ici, le téléphone portable est déjà identi�é. Or, lorsque l'identi�cation d'un utilisateur este�ectuée, les informations nécessaires le concernant et qui sont contenues dans le HLR sontstockées temporairement dans le VLR (qui, dans le cas des équipements Alcatel, fait partieintégrante du RCP). Il est donc logique que le HLR ne soit plus solicité.

4.5 In�uence du message CONNECT

1 LU3 FromRCP BSSAP 00:34.636 MSU nSCCP 0- 1-3 0- 0-4 7 DT1 Connect

Le message CONNECT n'a pas d'incidence sur les ressources radio prises par la communi-cation (et aucun champ ne permet d'a�rmer le contraire dans les logs). Les ressources radiosont prises lors de l'ASSIGNMENT REQUEST.

Le message CONNECT se contente de signaler que l'appelé a décroché son combiné.

4.6 Libération de l'appel



Fig. 4.1 � Description de la libÃ©ration d'appel


page 32 sur 34 Appel à destination d'un abonné mobile

Partie 5Appel à destination d'un abonné mobile

5.1 Identités des abonnés concernés


2

3 [...]

4

5 --- IMSI ---

6 Type Identity : .....001 = IMSI

7 Odd/Even : ....1... = odd



10 Length : 4

11 --- TMSI ---

12 TMSI : 04DFB24Ah

13 Information Element Id : 1Ah

14 Length : 6

L'identi�ant temporaire (TMSI) du téléphone mobile appelé est le 04DFB24A. Le numérode sa carte SIM (IMSI) est le 208011000000002.


2

3 [...]

4



7 Odd / Even indicator : ....1... = odd


L'identiant du téléphone portable de l'appelant (l'IMEI) est le 442502190222680.

1 LU3 ToRCP MAP 00:12.012

2



3 [...]

4


Le numéro du mobile appelé est le 06 89 00 00 41.

1 LU3 FromRCP MAP 00:12.043

2

3 [...]

4


Le numéro du téléphone appelant est le 01 43 37 80 00.

5.2 Rôle du HLR

Dans cet appel, l'appelant est un téléphone �xe (du réseau RTCP), qui appelle un numérode téléphone mobile. Le HLR permet donc ici d'accéder à plusieurs informations de l'abonnémobile :

� L'identi�ant de l'utilisateur (son IMSI)� L'adresse du VLR utilisé par l'abonné (ce qui permet ensuite d'avoir la localisation)� Les services disponibles chez l'abonné

Ainsi, on va pouvoir localiser l'abonné, ce qui permettra par la suite de réaliser l'appel.

5.3 Rôle du MSRN

Le MSRN (Mobile Subscriber Roaming Number) est un identi�ant temporaire attribué aumobile pour recevoir un appel, et dépendant de la zone de localisation où se trouve le mobile.Il est donc dé�ni et stocké sur le VLR. Le MSRN permet donc au MSC de l'abonné appelant(ici un GMSC) de connaître la localisation du mobile (a�n de router l'appel) :

1 LU3 ToRCP MAP 00:12.012 MSU nSCCP 0-100-2 0- 18-3 5 UDT VLR

2 0- 18-3 HLR BEGIN ORIG TID: 170000F8 INVOKE INVOKE ID: 128 Provide

3 roaming number IMSI: 208011000000002F 00001E55

4 LU3 FromRCP MAP 00:12.043 MSU nSCCP 0- 18-3 0-100-2 14 UDT HLR

5 0-100-2 VLR END DEST TID: 170000F8 RET RESULT INVOKE ID: 128 Provide

6 roaming number

Lorsqu'un MSC reccoit une demande d'appel qui nécessite un routage vers un autre MSC, iltransmet le numéro appelé au HLR (qui connait le VLR utilisé). Le HLR demande donc leMSRN au VLR, puis il le retransmet au MSC (de l'abonné appelant). Ainsi, l'appel sera routédu MSC de l'appelant (ici un GMSC) au MSC de l'abonné appelé.

Remarque : ensuite, le MSC de l'abonné appelé utilisera le TMSI pour router l'appel.



5.4 Message envoyé par le VLR

1 LU3 FromRCP BSSAP 00:12.324 MSU nSCCP Bh 4h 12 UDT BSSAP

2 4h BSSAP Paging IMSI 208011000000002 TMSI: 04DFB24A CELLID LST 208

3 01 768

4 LU3 ToRCP BSSAP 00:14.034 MSU nSCCP 4h Bh 10 CR BSSAP Bh

5 BSSAP Complete Layer 3 Information CELL ID 208 01 768 925 Paging

6 response TMSI 04DFB24A

Le VLR recherche le mobile à contacter (PAGING), en demandant sa présence exacte à tousles mobiles disponibles dans la zone de localisation. Pour dé�nir le mobile recheré, il envoieson IMSI et TMSI.

Le mobile qui s'est reconnu renvoie un PAGING RESPONSE au VLR : il con�rme ainsisa présence.

La zone de localisation (Location Area) contient un ensemble de cellules. Le VLR ne connaîtdonc pas la localisation précise du mobile.

5.5 Mécanismes de sécurité lors du PAGING RESPONSE

1 LU3 FromRCP BSSAP 00:14.060 MSU nSCCP Bh 4h 10 DT1

2 Authentication request

3 LU3 ToRCP BSSAP 00:14.713 MSU nSCCP 4h Bh 10 DT1

4 Authentication response


6 Cipher Mode Command


8 Cipher Mode Complete


10 Identity request


12 Setup CLG P NUMB


14 Identity response IMEI 442502190222680

15 LU3 ToRCP BSSAP 00:15.418 MSU nSCCP 4h Bh 10 DT1 Call confirmed

Dès réception du PAGING RESPONSE, les mécanismes de sécurité mis en oeuvre sont simi-laires à ceux utilisés lorsque c'est le téléphone mobile qui appelle lui-même :

� Authentication : authenti�cation permettant le calcul de la clé de cryptage� Cipher mode : activation du cryptage des données� Identity : véri�cation de la validité de l'abonnement (via l'IMEI)

5.6 Représentation des échanges de signalisation



Fig. 5.1 � Description des échanges entre BSS et NSS


Documents

Etude des protocoles GSM - Freesudriaesme.free.fr/archives/TP GSM/tp-gsm.pdf · Les premières données sont relatives au Routing Label ( DPC, OPC, SLS ), c'est-à-dire à l'acheminement