Contributions aux environnements de développement de services de télécoms dans le contexte de réseaux mobiles full IP haut débit.

République du Sénégal
Un Peuple - Un But - Une Foi
Université Cheikh Anta Diop de Dakar
Ecole Supérieure Polytechnique
Groupe de Formation Doctorale
Laboratoire d’Informatique, Réseaux et Télécommunications
Mémoire de Master Recherche
Contributions aux environnements de développement de
services de télécoms dans le contexte de réseaux mobiles
full IP haut débit.
Pour l’obtention du Diplôme de :
Master Recherche Science de l’Ingenieur
Option : Informatique, Modélisation et Simulation des Systèmes Complexes
Présenté et soutenu par : Sous la direction de :
Kokou GAGLO Dr Samuel OUYA
Année Académique 2014 - 2015

Dédicace
A mon épouse Marie Noëlle Hemesse FAYE.
i

Remerciements
Je voudrais avant toutes choses rendre grâce à l’Eternel sans qui ce travail ne saurait
aboutir. Que son Saint Nom soit glorifié pour les siècles sans fin.
J’adresse également mes sincères remerciements :
A mon épouse Marie Noëlle Hemesse FAYE ;
A mon employeur People Input qui a pu me trouver un créneau et des conditions
exceptionnelles pour que je puisse effectuer cette formation ;
A son Excellence Isaac Jogues GAGLO, Evêque d’Aneho (TOGO) ;
A mon père, Feu Jean Marie Koffi GAGLO ;
A ma mère Patience Ayéwa LODONOU ;
A mon frère Espoir GAGLO ;
A ma famille, GAGLO, LODONOU, EKLU, KOUTOGLO, FAYE,NDOUR, NGING ;
A toute la Communauté Arbre de Vie Divine de Dakar ;
Aux Soeurs Aimée de Jésus DAMAWUZAN, Marie Delphine KALI et Gildas PLA-
KOO ;
A tous mes collègues de People Input ;
A tous mes collègues de classe de Master recherche ;
A tous mes encadrants Dr Samuel Ouya, Dr Gervais Mendy et Dr Ahmath Bamba
Mbacké ;
ii

A tous mes enseignants et tout le personnel administratif de l’ESP (Ecole doctorale) ;
A toutes les personnes qui de près ou de loin, ont contribué à la réalisation de ce
document.
iii

Table des matières
Dédicace i
Remerciements ii
Résumé ix
Abstract x
1 Présentation du sujet 1
1.1 Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Le SMS dans le réseau GSM 4
2.1 Architecture GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 La pile de protocole SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Le SMS Protocol Data Unit (PDU) . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Encodage des messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Transmission de message en GSM . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.1 Mobile Originated (MO) SMS, transmission avec succès . . . . . . . 9
2.5.2 Transmission réussie d’un SMS vers un MS . . . . . . . . . . . . . . 11
2.5.3 Echec de transmission du sms . . . . . . . . . . . . . . . . . . . . . 12
2.5.4 Alerte au SMSC quand un abonné devient disponible . . . . . . . . 13
3 Gestion de la voix sur LTE 14
3.1 L’IP Multimedia Subsystem (IMS) . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1 Architecture du réseau IMS . . . . . . . . . . . . . . . . . . . . . . 14
3.1.2 La fourniture de services dans l’IMS . . . . . . . . . . . . . . . . . . 15
3.1.2.1 L’identité IMS . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2.2 Proﬁl d’usager et proﬁl de service . . . . . . . . . . . . . . 16
iv

3.1.2.3 Le déclenchement des services (iFC et SPT) . . . . . . . . 17
3.1.3 Les serveurs d’applications . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Long Term Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1 Architecture Evolved Packet System (EPS) . . . . . . . . . . . . . . 19
3.2.2 Entités du réseau EPS . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2.1 Entité eNodeB . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2.2 Entité MME (Mobility Management Entity) . . . . . . . . 20
3.2.2.3 Entité Serving GW (Serving Gateway) . . . . . . . . . . . 20
3.2.2.4 Entité PDN GW (Packet Data Network Gateway) . . . . 20
3.2.2.5 Entité HSS (Home Subscriber Server) . . . . . . . . . . . 21
3.2.2.6 Entité PCRF (Policy & Charging Rules Function) . . . . . 21
3.2.3 Default et Dedicated bearers . . . . . . . . . . . . . . . . . . . . . . 21
3.3 La voix sur LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.1 Le Circuit Switched FallBack (CSFB) . . . . . . . . . . . . . . . . . 23
3.3.2 La voix avec l’IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.3 La fonction SRVCC . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.4 Solutions de sms dans VoLTE . . . . . . . . . . . . . . . . . . . . . 25
3.3.4.1 SMS avec les interfaces SGs . . . . . . . . . . . . . . . . . 25
3.3.4.2 SMS avec l’IP-SM-GW . . . . . . . . . . . . . . . . . . . . 25
4 Le SMS dans le réseau IMS 27
4.1 Le service de messagerie dans l’IMS . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1 Les messages de type "page-mode" . . . . . . . . . . . . . . . . . . . 27
4.1.2 Les messages de type "session-mode" . . . . . . . . . . . . . . . . . 28
4.1.3 Pile de protocole pour l’envoie de message . . . . . . . . . . . . . . 29
4.2 Interconnexion entre le domaine circuit et le réseau IMS . . . . . . . . . . 29
4.2.1 Les interfaces du IP-SM-GW . . . . . . . . . . . . . . . . . . . . . . 29
4.2.2 Fonctionnalités du IP-SM-GW . . . . . . . . . . . . . . . . . . . . . 30
4.2.3 Fonctionnalités du HSS . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.4 Enregistrement de l’UE à l’IMS et mise à jour de sa joignabilité . . 31
4.2.5 Envoi de SMS via l’IMS . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.6 Réception de SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.7 Désenregistrement de l’UE à l’IMS et mise à jour de sa non joignabilité 35
5 APIs et environnements de développement des serveurs d’application 37
5.1 Les APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.1 JAIN SLEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.1.1 Java APIs for Integrated Networks (JAIN) . . . . . . . . . 37
5.1.1.2 Déﬁnition et architecture du JAIN SLEE . . . . . . . . . . 38
v

5.1.2 OSA/Parlay et Parlay X . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.3 SIP Servlet (JSR 289) . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Environnements de développement et de création de services . . . . . . . . 44
5.2.1 Serveurs d’application . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.1.1 Mobicents JAIN SLEE . . . . . . . . . . . . . . . . . . . . 44
5.2.1.2 OpenCloud Rhino SDK . . . . . . . . . . . . . . . . . . . 45
5.2.1.3 Mobicents SIP SERVLET et SailFin . . . . . . . . . . . . 45
5.2.2 Serveurs multimédia . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.2.1 Mobicents Media Server . . . . . . . . . . . . . . . . . . . 46
5.2.2.2 SIP Express Media Server . . . . . . . . . . . . . . . . . . 46
5.2.3 IDE Eclipse et le plugin Mobicents EclipSLEE . . . . . . . . . . . . 47
5.3 OpenIMSCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4 Kamailio IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6 Scénarios de tests et de simulations 49
6.1 Les SIP UA et les rôles SM-over-IP sender/receiver . . . . . . . . . . . . . 49
6.2 L’enregistrement à trois partie (Third Party Registration) . . . . . . . . . 50
6.3 Les interfaces du HSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.4 Scénario alternatifs expérimentés . . . . . . . . . . . . . . . . . . . . . . . 51
6.4.1 L’ESL de FreeSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.4.2 L’IP-SM-GW comme AS de présence . . . . . . . . . . . . . . . . . 52
Conclusion et Perspectives 53
vi

Table des figures
2.1 Architecture du SMS dans le GSM . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Protocole implémenté pour le SMS . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Types de messages SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 PDU d’un SMS-DELIVER en GSM . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Concaténation de sms compressés . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 TP-User-Data pour GSM 7 bit non compressé . . . . . . . . . . . . . . . . 8
2.7 Processus de segmentation de sms . . . . . . . . . . . . . . . . . . . . . . . 9
2.8 Message envoyé avec succès par un mobile . . . . . . . . . . . . . . . . . . 10
2.9 L’évolution du PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.10 Transmission réussie d’un SMS vers un MS . . . . . . . . . . . . . . . . . . 11
2.11 Echec de transmission du sms . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.12 Retransmission d’un sms après échec . . . . . . . . . . . . . . . . . . . . . 13
3.1 Architecture du cœur de réseau IMS . . . . . . . . . . . . . . . . . . . . . 15
3.2 Identification dans l’IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Profil de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Architecture EPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 Default et dedicated bearers . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6 VoLTE avec CSFB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7 VoLTE avec IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.8 SMS avec l’IP-SM-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1 Structure d’un message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Exemple de message INVITE . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Message MSRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Pile de protocole IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 Architecture avec IP-SM-GW . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6 Enregistrement de l’UE à l’IMS et mise à jour . . . . . . . . . . . . . . . . 32
4.7 Envoi d’un SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.8 Contenu du message SMS-SUBMIT encapsulé dans une requête SIP MES-
SAGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.9 Livraison de SMS réussie via l’IMS . . . . . . . . . . . . . . . . . . . . . . 35
vii

4.10 L’IP-SM-GW indique au HSS l’indisponibilité de l’IMPU pour la livraison
des SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1 Architecture JSLEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Les Interfaces Parlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3 La solution Parlay des fournisseurs de télécommunication . . . . . . . . . . 42
5.4 La solution Parlay des fournisseurs indépendants . . . . . . . . . . . . . . . 43
5.5 Architecture de l’OpenIMSCore . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1 Requête REGISTER avec le client IMSDroid . . . . . . . . . . . . . . . . . 49
6.2 Architecture avec FreeSwitch ESL . . . . . . . . . . . . . . . . . . . . . . . 51
6.3 IP-SM-GW comme AS de présence . . . . . . . . . . . . . . . . . . . . . . 52
viii

Résumé
Grâce à la 4G, les opérateurs ont la possibilité de fournir plus de services innovants
sans se soucier du débit en l’occurrence dans le domaine de l’éducation, de la santé et
autres.
L’architecture de service basée sur l’IMS que la 4G a hérité de la VoLTE ouvre la
voie au développement de ces services IP Multimédia. Cette architecture de service révo-
lutionne ainsi la manière d’implémenter des services dans les réseaux mobiles.
L’évolution des réseaux mobiles vers la 4G nécessite de faire l’état de l’art des nou-
velles architectures et nouveaux environnements de développement afin de concevoir les
services pour les utilisateurs.
Partant de l’exemple du SMS, notre travail fait le point sur le passage des réseaux
2G/3G au réseau LTE. Nous étudions ensuite ces architectures et environnements de
services introduits par l’IMS ainsi que les différents outils de simulation disponibles ac-
tuellement.
Enfin, nous simulons la passerelle IP-SM-GW afin d’étudier les fonctionnalités offertes
par ces outils et leurs limites dans une perspective de contribution à ces nouvelles archi-
tectures et nouveaux environnements.
Mots clés—VoLTE ; IMS ; IP-SM-GW ; 2G ; 3G ; 4G ; développement ; SIP ; MAP ;
services
ix

Abstract
With 4G, operators are able to provide more innovative services regardless of the flow
namely in the field of education, health and others.
The service architecture based on IMS as 4G inherited the VoLTE paves the way for
development of these IP Multimedia services. This service architecture revolutionizes how
to implement services in mobile networks.
The evolution of mobile networks to 4G requires making the state of the art new ar-
chitectures and new development environments to design services for users.
Using the example of SMS, our work provides an update on the transition from 2G/3G
networks to LTE. We then study these architectures and services introduced by IMS en-
vironments and different simulation tools currently available.
Finally, we simulate the IP-SM-GW to study the features offered by these tools and
their limitations from the perspective of contribution to these new architectures and new
environments.
Keywords—VoLTE ; IMS ; IP-SM-GW ; 2G ; 3G ; 4G ; developement ; SIP ; MAP ;
services
x

Chapitre 1
Présentation du sujet
1.1 Introduction générale
La LTE (Long Term Evolution), technologie basée sur du tout IP, a été définie afin
d’augmenter les débits des technologies existantes. Ainsi dans sa Release 8 et 9, le débit
descendant de la LTE est de 300 Mbits/s et son débit montant est de 75 Mbits/s [1]. Dans
la version LTE-Advanced le débit descendant est de 3000 Mbits/s et le débit montant
est de 1500 Mbits/s [1]. Avec ces débits énormes, la LTE initialement prévue pour le
téléchargement et le chargement de données suscita chez les opérateurs le besoin de fournir
aux utilisateurs d’autres services attractifs avec une qualité de service très élevée à savoir
les appels audio de haute définition, les appels vidéo, la télévision sur IP (IPTV) ect.
Dans ce contexte de convergence des réseaux mobiles vers le monde Internet, les en-
vironnements et paradigmes de développement des services télécoms ont évolué et nous
obligent à repenser nos façons de concevoir ces services.
1.2 Contexte
Avec le lancement imminent de VoLTE (Voice over LTE), la transition vers la 4G
réseau tout-IP est bien en cours. Cette transition génère de nouveaux besoins en ser-
vices. C’est ainsi que dans certains domaines comme l’enseignement, la manière de former
change.
Quelques unes des préoccupations des chercheurs dans l’enseignement à distance, à savoir
comment réduire les effets de la séparation des acteurs et comment former les appre-
nants dans le domaine des STEM (Science, Technology, Engineering, and Mathematics)
à distance, trouvent leurs réponses dans l’utilisation du sms [2, 3] et des plateformes de
collaboration basées sur la messagerie instantanée [4].
Le service sms longtemps utilisé comme service à valeur ajouté dans beaucoup de domaine
semble évoluer vers des systèmes de tchat avec l’avènement du tout-IP. Cette évolution
1

vers le domaine IP a également permis à certains chercheurs de préconiser l’usage des
services basés sur de l’IMS (IP Multimedia Subsystem), du Webrtc [5, 6] ou encore l’in-
tégration du Webrtc dans l’IMS.
Le 3GPP (3rd Generation Partnership Project) conscient de cet engouement pour les ser-
vices IP préconise une architecture de services faisant abstraction des fonctions télécoms
et exposant des API pour les développeurs. Avec cette architecture de service, certaines
fonctions télécoms peuvent être désormais implémentées en tant que AS (serveur d’appli-
cation) , c’est le cas du SRVCC (Single Radio Voice Call Continuity) [7]. Cette architecture
a également rendu possible l’ajout , dans les réseaux IMS, d’un serveur d’application fai-
sant office de passerelle entre les sms envoyés/reçus du domaine IP vers les réseaux 2G/3G
et vice-versa.
1.3 Problématique
Les nouvelles architectures de réseau de communication reposent sur une distinction
et une indépendance entre les niveaux transport, contrôle et application, ainsi que sur un
réseau de transport IP mutualisé pour tous les services [8].
L’opérateur peut se positionner grâce à sa couche contrôle en tant qu’agrégateur de ser-
vices offerts par l’opérateur lui-même ou par des tiers. La couche application consiste en
des serveurs d’application AS (Application Server) et serveurs de média IP (IP MS, IP
Media Server) [9].
Les environnements de développement de services de télécoms se doivent donc d’évoluer.
Comment se fera donc l’implémentation de ces services et fonctions télécoms qui sont des
serveurs d’application ? Quels sont les spécifications qui ont été définies ? Quels seront les
environnements et orientations des développeurs de services dans les réseaux IP multimé-
dia ?
A cette évolution d’architecture, d’environnement de développement de services s’ajoute
le problème de la transition entre les réseaux existants et les réseaux tout-IP.
1.4 Objectifs
L’objectif de ce mémoire est de faire l’état de l’art sur les propositions des centres sms
ainsi que les spécifications de développement et d’exécution de services dans les réseaux
convergents.
La passerelle IP-SM-GW sera étudiée comme cas de transition entre les réseaux tout-IP
et les réseaux 2G/3G.
Les possibilités de contribution aux nouvelles architectures et services télécoms seront
également identifiées au terme de ce travail.
2

1.5 Plan
La suite du mémoire sera organisée comme suit : dans le chapitre 2 le SMS dans les
réseaux 2G/3G sera étudié, le chapitre 3 traitera de la gestion de la voix dans LTE afin
de décrire les solutions d’envoie/réception de SMS proposées dans LTE.
L’étude du SMS dans le réseau IMS est faite dans le chapitre 4.
Le chapitre 5 quand à lui expose les plateformes et environnements permettant le dévelop-
pement de serveurs d’application dans le réseau IMS puis le chapitre 6 liste les simulations
faites dans le cadre de l’implémentation du serveur d’application IP-SM-GW et commente
les résultats obtenus. Viendra enfin la conclusion qui récapitulera le travail effectué dans
le mémoire et proposera les perspectives retenues pour la suite de ce travail.
3

Chapitre 2
Le SMS dans le réseau GSM
Le SMS (Short Message Service) utilise les protocoles de communication standardisés
pour permettre à des lignes ﬁxes ou des téléphones mobiles d’échanger des messages texte
courts.
2.1 Architecture GSM
Figure 2.1 – Architecture du SMS dans le GSM
L’équipement capable d’envoyer et de recevoir les SMS se nomme le SME (Short
Message Entity).
Pour la transmission des SMS dans le GSM, un centre de messagerie appelé SMSC
(SMS Center) ou SC (Service Center) doit être implémenté. Il peut se situer dans le réseau
ﬁxe,ou dans le téléphone mobile ou encore dans le MSC [10].
Malgré que le SMSC n’appartienne pas au réseau GSM, il peut être physiquement
intégré dans la même machine que le MSC (Mobile Switching Center). Un numéro E.164
lui est attribué dans le plan de numérotation dans le réseau mobile.
La communication entre le SMSC et le mobile se déroule via le MSC. Ce dernier a la
charge de router tous les appels dans une zone géographique donnée.
4

Le SMS-GMSC (SMS Gateway MSC) a pour rôle de router les SMS au VMSC (Visiting
MSC) destinataire et de retourner l’erreur appropriée s’il y en a. Il notifiera également le
HLR (Home Location Register) du status du message envoyé.
Pour atteindre le SMSC, le réseau mobile doit envoyer le message du VMSC au MSC
qui abrite le SMSC. Ce MSC est appelé SMS-IWMSC (SMS-Interworking MSC). Il peut
recevoir un message du réseau mobile et l’envoyer au MSC destinataire.
2.2 La pile de protocole SMS
Figure 2.2 – Protocole implémenté pour le SMS
La figure 2.2 montre les couches du protocole utilisées pour transmettre un SMS. Celles
qui interviennent durant les transactions (Mobility Management [MM], Radio Resource
[RR], Link Access Protocol sur le canal Dm [LAPDm]) et la couche physique sont aussi
représentées. Les quatre couches impliquées dans la transmission du SMS sont :
— Le SM-AL (Short Message Application Layer) : il est présent dans le terminal mobile
et dans le SME (Short Message Entity). Sa fonction est de générer et d’interpréter
les messages ;
— Le SM-TL (Short Message Transfer Layer) : c’est la couche de transport pour l’envoi
et la réception de message entre le terminal mobile et le SMSC. Il assure l’encodage
et ajoute un "timestamp" de la date de réception du message par le serveur ;
— Le SM-RL (Short Message Relay Layer) : il permet le transfert de messages à travers
différents équipements utilisant le "Store and Forward". Les protocoles définis dans
le GSM 2 pour cette couche sont :
— SM-RP (Short Message Relay Protocol) : il est utilisé entre le mobile et le
VMSC/VLR. Il gère le référencement et l’adressage ;
— MAP (Mobile Application Protocol) : il est utilisé entre le VMSC/VLR et le
SMS-IWMSC ;
5

— Le protocole entre SMS-GMSC/SMS-IWMSC et le SMSC n’est pas défini dans
les spécifications GSM.
— CM (Connection Management) : le SM-CP (Short Message Control Protocol) est
utilisé entre le mobile et le VMSC/VLR. Il transmet le SM et protège contre les
pertes causées par le changement de canal dédié (c’est un besoin car pour le chan-
gement de canal dédié le LAPDm en demande un nouveau mais ne sécurise pas la
transmission).
2.3 Le SMS Protocol Data Unit (PDU)
Au niveau de la couche SM-TL, il y a six types de PDU représentant les différentes
façons de coder et de structurer l’information. Le PDU contient le SCA (Service Center
Address) et le TPDU (Transfer Protocol Data Unit). Ces six types peuvent être différenciés
par la le champ MTI (Message Type Indicator) [10].
Quand une requête SMS-SUBMIT ou SMS-COMMAND est envoyée, le SMSC répond
avec un SMS-SUBMIT-REPORT au SME pour lui notifier qu’il accepte de délivrer le
message. Le SMSC tente alors de délivrer le message au destinataire dès qu’il est connecté
au réseau. Lorsque le message est délivré, à la demande de l’émetteur, un accusé de
réception est retourné.
Figure 2.3 – Types de messages SMS
Les différentes requêtes et réponses sont :
— SMS-SUBMIT : est utilisé pour transmettre un message du mobile au SMSC. Il
contient la date à laquelle le SMSC a reçu le message. Il peut contenir des paramètres
optionnels comme l’identification du protocole, le schéma de codage, la taille de la
donnée et la donnée elle-même. Il contient aussi le TP-MR (Message Reference), un
paramètre qui l’identifie de façon unique ;
— SMS-COMMAND : il est utilisé pour transmettre une commande du mobile au
SMSC. Il contient un paramètre qui l’identifie de façon unique, le TP-MR (Message
Reference). Ce type de message permet au mobile de demander le statut d’un sms
ou de le supprimer au niveau du SMSC. Cette commande peut aussi être utilisée
6

pour obtenir les informations (MSISDN et IMSI) sur un abonné. Un SMS-STATUS-
REPORT est reçu en réponse à cette commande [10] ;
— SMS-SUBMIT-REPORT : il est émis par le SMSC comme un accusé de réception
positif ou négatif en réponse à un SMS-SUBMIT ou un SMS-COMMAND. Dans le
cas d’un échec il contient un champ décrivant la raison de l’échec. Il contient le TP-
SCTS (Service-Centre-Time-Stamp), un paramètre qui identifie la date à laquelle
le SMSC a reçu le message (SMS-SUBMIT ou SMS-COMMAND). Celle valeur est
unique. Même si des messages ont été envoyés simultanément, pour assurer l’unicité,
le SMSC modifie cette valeur à l’enregistrement ;
— SMS-DELIVER : il est utilisé pour transmettre un message du SMSC au mobile. Il
contient une indication sur le fait que le message est une partie d’une concaténation
de messages : l’adresse du SME émetteur, l’encodage utilisé, la date à laquelle le
message a été reçu par le SMSC, la taille de la donnée utilisateur et le message en
soi. Il contient le TP-SCTS ;
— SMS-DELIVER-REPORT : il est émis par le mobile comme un accusé de réception
positif ou négatif en réponse à un SMS-DELIVER ou un SMS-STATUS-REPORT.
Dans le cas d’un échec, il contient un champ décrivant la raison de l’échec. Il est
envoyé au SMSC ;
— SMS-STATUS-REPORT : il est émis par le SMSC pour informer du statut final d’un
SMS-SUBMIT et d’un SMS-COMMAND. Il contient le TP-MR et le TP- SCTS
permettant au mobile émetteur de faire le lien entre le SMS-STATUS-REPORT du
message qu’il avait envoyé.
Figure 2.4 – PDU d’un SMS-DELIVER en GSM
2.4 Encodage des messages
Les messages de plus de 160 caractères sont segmentés par le réseau. Le destinataire
aura donc besoin de rassembler les morceaux. Pour que la concaténation soit possible un
7

en-tête est ajouté au PDU (Protocol Data Unit) du sms. Cet en-tête est appelée UDH
(User Data Header). Cet en-tête occupe 6 octets, ce qui veut dire qu’il n’en reste plus que
134 pour les caractères sms dans l’encodage GSM 7 bits.
Le nombre maximum de sms qui peut être concaténé de la sorte est de 255. Il en découle
que la taille maximale du message concaténé est de 34170 octets (255*134 octets). Si le
message est compressé, l’algorithme de Huffman est souvent utilisé en GSM. Ainsi ces
bits incluent aussi un en-tête de compression CH (Compression Header) et des bits de fin
de compression à la fin CF (Compression Footer) comme sur la figure 5. Le CH définit le
type de compression utilisé et le CF indique la fin des données compressées [11].
Figure 2.5 – Concaténation de sms compressés
Le TP-User-Data pour l’encodage GSM 7 bit non compressé est décrit à la figure 2.6.
Figure 2.6 – TP-User-Data pour GSM 7 bit non compressé
Le TP-UDL (Transfer Protocol User Data Length) représente la taille totale du "User
Data". Le UDHL (User Data Header Length) donne le nombre de bit du "User Data
Header".
Le IEI (Information Element Identifier) est un champ utilisé pour le contrôle du sms,
pour l’EMS (Enhanced Messaging Service) et le contenu du EMS. Quand il s’agit de la
concaténation, il peut prendre deux valeurs : 00 ou 08. Il est suivi par un champ IEIDL
8

(IEI Data Length) qui donne le nombre de bits du IEID (IEI Data). L’IEID contient les
bits IEIDL-2 qui identifient les messages appartenant à la même séquence, un bit qui
donne le nombre total de subdivision du sms original (valeur maximale FF), et enfin un
bit qui indique le numéro du message courant.
La figure 2.7 montre l’exemple d’un segment de message
Figure 2.7 – Processus de segmentation de sms
2.5 Transmission de message en GSM
2.5.1 Mobile Originated (MO) SMS, transmission avec succès
La figure 2.8 représente le diagramme de transmission d’un sms par un mobile. Le
message envoyé par l’abonné est encodé par l’entité de transport du mobile en 140 octets
en ajoutant l’adresse du récepteur découlant de la couche TL-PDU (Transfer Layer PDU).
A la couche relais, l’adresse du SMSC est ajoutée au TL-PDU. Le nouveau paquet est
appelé RP-DATA (Relay Protocol-DATA). Ce paquet est encapsulé en PDU CP (Control
Protocol level PDU) mais à cette étape, aucune information importante n’est ajoutée.
Ce paquet est appelé PDU CP-DATA et est transporté à travers le VMSC/VLR par le
SM-CP et ses couches basses.
9

Figure 2.8 – Message envoyé avec succès par un mobile
Comme décrit sur la ﬁgure 2.9, le VMSC/VLR décapsule le PDU CP-DATA pour trou-
ver le numéro du SMSC, puis remplace le PDU par un MAP_FORWARD_SHORT_MESSAGE
. Le SMS-IWMSC va transférer le message MAP au SMSC puis envoyer un accusé de ré-
ception.
Figure 2.9 – L’évolution du PDU
Le SMSC stocke le message et les adresses, et accuse réception du message au SMS-
IWMSC. Le SMS-IWMSC peut maintenant à son tour accuser réception du paquet reçu
du VMCS/VLR. Le VMCS/VLR formate l’accusé de réception en un message PDU RP-
10

ACK puis l’encapsule en PDU CP-DATA avant de l’envoier au mobile. Pour terminer, le
mobile accuse réception à son tour de ce PDU.
Le SMSC enverra le sms au SME. Si ce dernier n’est pas connecté au réseau, le SMSC
va stocker le message jusqu’à ce que le SME soit joignable de nouveau. Cependant le
message est supprimé après un temps si le SME demeure toujours injoignable. Ce délai
peut être spéciﬁé par le mobile au niveau de la couche transport. En conclusion, le mobile
ne reçoit que la conﬁrmation concernant la réception du sms par le SMSC. Lorsque le
SME reçoit le sms qui lui est destiné, il peut accuser réception du message.
2.5.2 Transmission réussie d’un SMS vers un MS
Figure 2.10 – Transmission réussie d’un SMS vers un MS
Le SMSC crée un TL PDU qui contient le message, l’adresse du SME et la date à
laquelle le message a été reçu. Il envoie le PDU au SMS-GMSC. Le SMS-GMSC ajoute
l’adresse du SMSC au PDU. Il interroge ensuite le HLR pour localiser le mobile et envoie le
message par l’intermédiaire du VMSC/VLR en utilisant le MAP_FORWARD_SHORT_MESSAGE.
Les mêmes protocoles cités à la section 2.5.1 sont utilisés durant le transfert du message.
11

2.5.3 Echec de transmission du sms
Figure 2.11 – Echec de transmission du sms
Après réception du sms (ﬁgure 2.11), le SMSC tente de l’envoyer au SME destina-
taire suivant le scénario de la ﬁgure 2.10. Cependant si l’abonné n’est pas présent dans
le réseau il ne pourra pas répondre au message "Paging" envoyé par le VMSC. Après
un certain temps, le VMSC se rend compte que l’abonné n’est pas connecté et envoie
un MAP_FORWARD_SHORT_MESSAGE_nack pour en informer le SMS-GMSC. Le
SMS-GMSC va donc informer le HLR qui met à jour sa liste de message en attente. Il
informera ensuite le SMSC de l’échec de l’envoi.
12

2.5.4 Alerte au SMSC quand un abonné devient disponible
Figure 2.12 – Retransmission d’un sms après échec
Quand le récepteur se connecte au réseau, le VLR notiﬁe le HLR en utilisant un
message MAP_READY_FOR_SM. Ce dernier envoie un message
MAP_ALERT_SERVICE_CENTRE au SMS-IWMSC qui à son tour alerte le SMSC.
Le SMSC procède donc à l’envoi du sms (ﬁgure 2.10).
13

Chapitre 3
Gestion de la voix sur LTE
Le but de la VoLTE est d’émuler via l’architecture IMS les services du domaine circuit,
à savoir, la voix et ses services complémentaires, la visiophonie, le service SMS et les
services USSD (Unstructured Supplementary Service Data).
3.1 L’IP Multimedia Subsystem (IMS)
3.1.1 Architecture du réseau IMS
L’IMS est une architecture centralisée divisée en plusieurs couches. Avant de pouvoir
accéder aux plateformes de services, l’utilisateur doit s’authentiﬁer auprès de l’opérateur.
Pour cela le HSS (Home Subscriber Server) assure les fonctions d’authentiﬁcation, de loca-
lisation, de proxy SIP. Les CSCF (Call Session Control Function) contrôle l’ouverture des
sessions SIP et l’établissement des appels. On y trouve aussi les MGW (Media Gateway)
et les MGCF (Media Gateway Control Function) qui vont permettre de s’interconnecter
avec des réseaux RTC (Réseau Téléphonique Commuté) ainsi que le MRFC (Multimedia
Resource Function Controller) qui contrôle les ressources utilisées par le client.
14

Figure 3.1 – Architecture du cœur de réseau IMS
Comme indiqué sur la figure 3.1, l’architecture IMS est découpée en quatre couches
fonctionnelles.
— La couche "Access" permet l’interopérabilité entre les différents médias d’accès et
l’architecture IMS ;
— La couche "Session Control" gère toutes les sessions SIP établies à travers l’architec-
ture IMS. Elle contrôle en particulier, l’ouverture des sessions SIP et l’établissement
des appels ;
— La couche "Service" met à disposition, pour la couche application, un ensemble
d’API implémentant le protocole SIP ;
— La couche "Application" fourni l’ensemble des applications disponibles dans une
architecture IMS telle que la présence, la visio-conférence, etc.
3.1.2 La fourniture de services dans l’IMS
3.1.2.1 L’identité IMS
Une souscription IMS contient deux types d’informations (figure 3.2) :
15

Figure 3.2 – Identification dans l’IMS
— L’identité privée IMPI (IP Multimedia Private Identity) qui est unique dans le
réseau de l’opérateur, il identifie la souscription de l’utilisateur. Elle concerne plus
particulièrement l’opérateur. Cette identité est importante durant l’authentification
du terminal car elle est envoyée durant chaque phase d’enregistrement.
— L’identité publique IMPU (IP Multimedia Public Identity) qui permet d’identifier
l’utilisateur associé à la souscription. Un utilisateur peut avoir plusieurs IMPU.
L’identité publique a la forme d’un URI (Uniform Resource Identifier) qui est une suite
de caractère permettant d’identifier une ressource physique ou abstraite. Il existe deux
types d’URI utilisés dans l’IMS :
— Tel URI : il ressemble à un numéro de téléphone. Il peut être soit global (unique de
façon global) ou soit local (spécifique à un contexte local).
Exemple :
— global : +221776814199
— local : tel :1234567 ;phone-context=+358-555
— SIP URI : sa forme générale est sip :user :password@host :port ;uri-parameters ?headers.
Il est plus utilisé sous la forme sip :user@host.
Exemple : sip :kokou@lirt.sn
Un numéro GSM qui doit être traduit pour un usage en IMS aura la forme : 776814199@lirt.sn.
3.1.2.2 Profil d’usager et profil de service
A chaque usager IMS est associé un profil d’usager dans le HSS. Un profil d’usager
consiste en un ensemble de profils de service. Un profil de service contient (Figure 3.3) :
— une ou plusieurs IMPUs (IMS Public User Identities) ayant la forme d’une adresse
téléphonique ou d’une URI SIP,
16

— zéro ou une instance de la classe Core Network Service Authorization indiquant les
différents médias pouvant être utilisés pour les sessions établies avec ces identités
publiques,
— un ensemble (0 à N) de critères de filtrage (iFC, initial Filter Criteria). Un critère de
filtrage est une information statique correspondant à une souscription d’un usager
à un service du domaine IMS,
— un ensemble (0 à N) de "Shared iFC set". Un "Shared iFC Set" pointe sur un ensemble
d’iFC administrés localement et stockés sur le S-CSCF. Un "Shared iFC Set" peut
être partagé par plusieurs profils de service, permettant de minimiser la taille du
profil de l’usager.
Figure 3.3 – Profil de service
Le profil de service est obtenu par l’entité S-CSCF auprès du HSS à travers l’interface
Cx lorsque l’usager s’enregistre au sous-système IMS.
3.1.2.3 Le déclenchement des services (iFC et SPT)
Des points de déclenchement de service appelés Service Point Triggers (SPTs) sont des
points dans la signalisation SIP sur lesquels des conditions (Filter Criteria) peuvent être
placées. Les points de déclenchement suivants sont définis :
— Request-URI : identifie la ressource adressée par la requête (exemple : sip :confe-
rence@lirt.sn)
— Initial method : Toute méthode initiale SIP connue ou inconnue (e.g. REGISTER,
INVITE, SUBSCRIBE, MESSAGE) ;
— Registration type : indique si la requête REGISTER représente un enregistrement
initial ou un ré-enregistrement ou encore une annulation d’enregistrement.
— SIP header : présence ou absence d’un header connu ou inconnu ; ou contenu d’un
header connu ou inconnu. La valeur du contenu est une chaîne de caractères inter-
prétée comme une expression régulière.
17

— Session case : Sens de la requête SIP tel que "originating" ou "terminating_registered"
pour un usager enregistré ou "terminating_unregistered" pour un usager non enre-
gistré
— Session Description : Définit un SPT pour le contenu de tout champ SDP dans le
corps d’une méthode SIP.
Lorsqu’une entité S-CSCF reçoit une requête SIP concernant un usager donné, elle
évalue les critères de filtrage associés à cet usager un à un selon leur ordre de priorité. Si
la requête SIP vérifie le critère de filtrage, l’entité S-CSCF achemine la requête SIP au
serveur d’application correspondant (i.e., AS SIP, IM-SSF, OSA SCS). Une priorité est
affectée à chaque Filter Criteria afin de permettre au S-CSCF de les traiter dans l’ordre.
3.1.3 Les serveurs d’applications
Les serveurs d’applications hébergent et exécutent essentiellement des services pour les
utilisateurs et effectuent la fonction de serveurs d’applications SIP. En d’autres termes,
selon le service véritable, le serveur d’application peut fonctionner dans les modes sui-
vants :
— le mode Proxy SIP
— le mode UA SIP
— le mode serveur de redirection SIP
— le mode B2BUA (Back to Back User Agent - concaténation de deux UA)
Les serveurs d’applications assurent aussi l’interface avec l’HSS pour transférer et/ou
télécharger les données de l’utilisateur. Les serveurs d’application offrent des API comme
OSA/Parlay (Open Service Access), SIP servlet, JAIN API (Java Service Logic and Exe-
cution Environment) pour l’exécution des applications.
18

3.2 Long Term Evolution
3.2.1 Architecture Evolved Packet System (EPS)
Figure 3.4 – Architecture EPS
La figure 3.4 décrit l’architecture EPS avec son LTE et son cœur de réseau ePC.
L’accès LTE est caractérisé par un débit sur l’interface radio : 100 Mbit/s descen-
dant et 50 Mbit/s montant. L ’interface radio E-UTRAN doit pouvoir supporter un débit
maximum descendant instantané (du réseau au terminal) de 100 Mbit/s en considérant
une allocation de bande de fréquence de 20 MHz pour le sens descendant et un débit
maximum montant instantané (du terminal au réseau) de 50 Mbit/s en considérant aussi
une allocation de bande de fréquence de 20 MHz. Les technologies utilisées sont OFDMA
(Orthogonal Frequency Division Multiple Access) pour le sens descendant et SC-FDMA
(Single Carrier - Frequency Division Multiple Access) pour le sens montant[13].
SAE (System Architecture Evolution) est le nom du projet, EPC (Evolved Packet
Core) est le nom du réseau cœur évolué. EPC est un réseau cœur paquet tout IP. A
la différence des réseaux 2G et 3G où l’on distinguait les domaines de commutation de
circuit (CS, Circuit Switched) et de commutation de paquet (PS, Packet Switched) dans
le réseau cœur, le nouveau réseau ne possède qu’un domaine paquet appelé EPC.Tous
les services devront être oferts sur IP y compris ceux qui étaient auparavant offerts par
le domaine circuit tels que la voix, la visiophonie, le SMS, ainsi que tous les services de
téléphonie[13].
19

3.2.2 Entités du réseau EPS
L’EPS (Evolved packet System) représente l’ensemble du réseau à savoir LTE et SAE.
3.2.2.1 Entité eNodeB
L’eNodeB est responsable de la transmission et de la réception radio avec l’UE. A la
différence de l’UTRAN 3G où sont présentes les entités Node B et RNC, l’architecture
E-UTRAN ne présente que des eNodeB. Les fonctions supportées par le RNC ont été
réparties entre l’eNodeB et les entités du réseau cœur MME/Serving GW. L’eNodeB dis-
pose d’une interface S1 avec le réseau cœur. L’interface S1 consiste en S1-C (S1-Contrôle)
entre l’eNodeB et le MME et S1-U (S1-Usager) entre l’eNodeB et le Serving GW. Une
nouvelle interface X2 a été définie entre eNodeBs adjacents. Son rôle est de minimiser
la perte de paquets lors de la mobilité de l’usager en mode ACTIF (handover). Lorsque
l’usager se déplace en mode ACTIF d’un eNodeB à un autre eNodeB, de nouvelles res-
sources sont allouées sur le nouvel eNodeB pour l’UE ; or le réseau continue à transférer
les paquets entrants vers l’ancien eNodeB tant que le nouvel eNodeB n’a pas informé le
réseau qu’il faut lui relayer les paquets entrants pour cet UE. Pendant ce temps l’ancien
eNodeB relaie les paquets entrants sur l’interface X2 au nouvel eNodeB qui les remet à
l’UE.
3.2.2.2 Entité MME (Mobility Management Entity)
Le MME (Mobility Management Entity) est le nœud responsable du contrôle dans le
réseau EPC (Evolved Packet Core). Il est responsable de l’enregistrement des mobiles,
de leur authentification, de leur joignabilité lorsqu’ils sont dans l’état de repos (incluant
paging), de la sélection du Serving GW et du PDN GW. C’est au MME de sélectionner le
Serving GW et le PDN GW qui serviront à mettre en œuvre le Default Bearer (le canal
de communication permanent) au moment du rattachement du mobile au réseau.
3.2.2.3 Entité Serving GW (Serving Gateway)
Le SGW (Serving GW, passerelle de service) route les paquets sortants de l’usager au
PDN GW et achemine les paquets entrants à l’usager via le réseau d’accès. Il réalise par
ailleurs les fonctions d’interception légale et de comptabilité par usager pour la taxation
inter-opérateurs.
3.2.2.4 Entité PDN GW (Packet Data Network Gateway)
Le PGW (PDN GW, passerelle PDN) fournit la connectivité vers les réseaux externes
tels qu’Internet et Intranets. Il réalise les procédures d’allocation d’adresse IP au mobile,
20

d ’interception légale ainsi que de contrôle (gating, QoS control) et de taxation des flux
de service montants et descendants.
3.2.2.5 Entité HSS (Home Subscriber Server)
Avec la technologie LTE, le HLR est réutilisé et renommé Home Subscriber Server
(HSS). Le HSS est un HLR évolué et contient l’information de souscription pour les réseaux
GSM, GPRS, 3G, LTE et IMS. A la différence de la 2G et de la 3G où l’interface vers le
HLR est supportée par le protocole MAP (protocole du monde SS7), l’interface S6 s’appuie
sur le protocole DIAMETER (protocole du monde IP). Le HSS est une base de données qui
est utilisée simultanément par les réseaux 2G, 3G, LTE/SAE et IMS appartenant au même
opérateur. Il supporte donc les protocoles MAP (2G, 3G) et DIAMETER (LTE/SAE,
IMS).
3.2.2.6 Entité PCRF (Policy & Charging Rules Function)
L’entité PCRF réalise deux fonctions :
— Elle fournit au PDN-GW les règles de taxation lorsqu’un default bearer ou un dedi-
cated bearer est activé ou modifié pour l’usager. Ces règles de taxation permettent
au PDN-GW de différencier les flux de données de service et de les taxer de façon
appropriée. Par exemple, si l’usager fait transiter sur son default bearer des flux
WAP et des flux de streaming, il sera possible au PDN GW de distinguer ces deux
flux et de taxer le flux WAP sur la base du volume alors que le flux de streaming
sera taxé sur la base de la durée.
— Elle permet de demander au PDN GW d’établir, de modifier et de libérer des de-
dicated bearer sur la based de QoS souhaitée par l’usager. Par exemple, Si l’usager
demande l’établissement d’une session IMS, un message SIP sera envoyé au P-CSCF
qui dialoguera avec le PCRF pour lui indiquer la QoS requise par l’usager pour cette
session. Le PCRF dialogue alors avec le PDN-GW pour créer le dedicated bearer
correspondant.
3.2.3 Default et Dedicated bearers
Le MME crée pour le compte de l’usager un default bearer au moment du rattachement
au réseau. Supposons qu’il s’agisse du default bearer utilisé pour l’accès au PDN (Packet
Data Network) Internet, alors celui-ci est maintenu tant que l’usager est rattaché au
réseau mobile. L’APN correspondante est présent dans le profil de l’usager qui est fourni
par le HSS au MME. Si l’usager nécessite d’accéder à un autre PDN (exemple : réseau
IP supportant l’IMS), alors son terminal devra établir un default bearer additionnel en
utilisant une autre APN. Ce default bearer additionnel est maintenu tant que l’usager a
21

besoin d’accéder au PDN correspondant. Pour chaque APN, une adresse IP est fournie
par le PDN GW au mobile. Si l’usager émet un message SIP sur son default bearer IMS
au P-CSCF (call server de l’IMS), ce dernier demande au PCEF du PDN GW via le
PCRF de réserver un dedicated bearer. Ce dedicated bearer est caractérisé par une QoS
compatible par rapport au trafic à transporter. Le dedicated bearer a une durée de vie
qui correspond à celle de la session multimédia pour laquelle il a été établi (e.g., session
de voix sur IP). Un dedicated bearer est toujours associé à un default bearer. Il partage
la même adresse IP que le default bearer, mais une QoS qui est différente. Plusieurs
dedicated bearers peuvent être associés au même default bearer. Le principe de dedicated
bearer s’applique aussi dans le cas de l’accès Internet. En parallèle du default bearer
Internet, un dedicated bearer peut être établi, par exemple, pour le transport du flux
Skype (QoS conversationnelle), ou pour le transport des commandes d’un jeu sur Internet
(QoS Interactive), ou encore pour le transport d’un flux youtube (QoS streaming) (figure
3.5)
Figure 3.5 – Default et dedicated bearers
3.3 La voix sur LTE
Le réseau cœur (EPC) déployé pour la 4G a été conçu pour s’interconnecter aux
réseaux IP comme le LAN, la 3G, et évidemment le LTE. Diverses solutions ont été
proposées pour la voix sur LTE.
22

3.3.1 Le Circuit Switched FallBack (CSFB)
Avec le CS FallBack 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. Par conséquent, si le mobile était attaché sur le réseau 4G,
il bascule vers le réseau 2G/3G, et le mobile envoie une réponse d’acquittement vers le
cœur de réseau en commutation de circuit. A partir de ce moment, toute la signalisation
pour la session d’appel téléphonique est prise en charge par le réseau 2G/3G (figure 3.6).
Figure 3.6 – VoLTE avec CSFB
Pour que le cœur 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 [14].
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.
23

3.3.2 La voix avec l’IMS
Figure 3.7 – VoLTE avec IMS
Dans l’architecture avec un réseau IMS (figure 3.7), la signalisation téléphonique
transférée par le réseau 4G se base sur le protocole SIP (Session Information Protocol),
qui définit deux procédures de base : l’enregistrement du mobile et l’établissement de
session (la communication téléphonique).
Le réseau IMS traite la signalisation téléphonique SIP. Il effectue le routage de la
signalisation téléphonique et fournit les compléments de service téléphonique (comme le
transfert d’appel).
Il permet également le traitement spécifique de la voix pour offrir des services par-
ticuliers comme par exemple la conférence, la messagerie vocale ou la génération des
annonces.
La communication téléphonique peut être établie entre deux mobiles 4G. La signalisa-
tion téléphonique est traitée par les entités IMS de l’opérateur nominal de chaque mobile.
La voix est directement transférée entre les réseaux EPS.
La communication téléphonique peut également être établie entre un mobile et un ter-
minal connecté au réseau téléphonique fixe PSTN (Public Switched Telephone Network)
ou mobile PLMN (Public Land Mobile Network). Le réseau IMS fournit les entités qui
assurent la conversion des protocoles pour l’interconnexion avec ces réseaux
24

3.3.3 La fonction SRVCC
Si le mobile perd la couverture radioélectrique 4G, la communication téléphonique
établie sur le réseau EPS dans le mode PS doit être transférée vers le réseau 2G ou 3G
en mode CS (Circuit Service).
La communication téléphonique doit être maintenue lorsque le mobile est transféré
vers le réseau 2G/3G. Le mécanisme SRVCC (Single Radio Voice Call Continuity) est
une fonction particulière du réseau IMS qui assure ce maintien en cas de handover inter-
système PS-CS. Il assure pour cela l’ancrage des flux de la signalisation téléphonique et
de la voix.
La fonction SRVCC est en fait un sous-ensemble de la fonction ICS (IMS Centralized
Services) qui définit un contrôle unique de la signalisation téléphonique basé uniquement
sur les mécanismes de l’IMS. Elle s’applique aux réseaux de mobiles quel que soit le mode
PS ou CS utilisé pour mettre en place le support de la voix.
3.3.4 Solutions de sms dans VoLTE
3.3.4.1 SMS avec les interfaces SGs
SMS over SGs est un mécanisme pour transmettre des SMS via l’interface radio du
LTE. Le protocole utilisé pour connecter un MME à un MSC se nomme SGsAP et celui
utilisé pour le transfert des messages de signalisation est le Stream Control Transmission
Protocol (SCTP) [14].
SMS sur SGS est indépendant du CSFB ; ce qui signifie qu’il ne déclenche pas le
changement d’interface radio vers UTRAN ou GERAN . La gestion du SMS sur SGS est
obligatoire pour les UE , MME et MSC qui implémentent la CSFB. Toutefois, les entités
qui supportent le SMS sur SGs ne sont pas obligés d’implémenter le CS Fallback.
3.3.4.2 SMS avec l’IP-SM-GW
Dans une architecture de VoLTE avec IMS pour gérer la voix, le service de sms est
géré via une entité nommée IP-SM-GW (figure 3.8). L’IP-SM-GW est un AS SIP dans
le réseau IMS qui permet l’interfonctionnement entre le monde IMS et le SMSC [15].
25

Figure 3.8 – SMS avec l’IP-SM-GW
26

Chapitre 4
Le SMS dans le réseau IMS
L’EPS est constitué du réseau d’accès LTE et du réseau cœur paquet appelé EPC
(Evolved Packet Core). L’EPS est un réseau d’accès large bande connecté au monde IP
(Internet / Intranet). Aﬁn de fournir aux abonnés LTE les services du domaine circuit, à
savoir, la voix et ses services complémentaires, la visiophonie, le service SMS et les services
USSD, le réseaux IMS (IP Multimedia Subsystem) fut recommandé par la GSMA (GSM
Association) [16].
4.1 Le service de messagerie dans l’IMS
L’IMS permet l’envoie de message de 200 octets avec accusé de réception. Les messages
sont envoyés entre les utilisateurs en temps réel. [11]
4.1.1 Les messages de type "page-mode"
Un message de type "page-mode" est similaire à un SMS. C’est un message de type
SIP MESSAGE, il n’est pas lié au message précédent et n’a pas besoin de réponse. Il peut
être un texte échangé entre deux abonnés ou une notiﬁcation. L’UAC (User Agent Client)
envoie le message SIP au proxy qui le transfert au UAS (User Agent Server) qui enverra
un message 200 OK comme accusé de réception.
27

Figure 4.1 – Structure d’un message
4.1.2 Les messages de type "session-mode"
Avec ce mode une requête SIP INVITE (figure 4.2) est utilisée pour établir une session
avant l’échange de message instantanée (figure 19) entre les utilisateurs. C’est pourquoi au
lieu du RTP (Real-time Transport Protocol) un autre protocole nommé MSRP (Message
Session Relay Protocol) est utilisé. MSRP fonctionne avec les protocoles de transport qui
assurent le contrôle de congestion de bout en bout, tel que le TCP.
Figure 4.2 – Exemple de message INVITE
Les messages MSRP (figure 4.3) sont envoyés après l’établissement de la session.
28

Figure 4.3 – Message MSRP
4.1.3 Pile de protocole pour l’envoie de message
Le contrôle de session est effectué par le protocole SIP et SDP, tandis que les flux
média sont transmis en utilisant le protocole RTP ou MSRP.
Figure 4.4 – Pile de protocole IMS
4.2 Interconnexion entre le domaine circuit et le ré-
seau IMS
L’interconnexion avec le domaine circuit (GSM ou UMTS) basé sur du MAP (Mobile
Application Part) et LTE-EPC pour l’IMS se fait via la passerelle IP-SM-GW (IP-Short
Message-Gateway) pour l’envoie de SMS [15].
4.2.1 Les interfaces du IP-SM-GW
Comme illustré sur la figure 4.5, le IP-SM-GW se place entre le cœur du réseau IMS
et le domaine circuit. Il offre la possibilité pour les utilisateurs de s’enregistrer, processus
au cours duquel ils précisent leurs possibilités d’envoyer/recevoir des SMS sur IP.
29

Figure 4.5 – Architecture avec IP-SM-GW
4.2.2 Fonctionnalités du IP-SM-GW
Les fonctionnalités générales du IP-SM-GW sont [17] :
— Décider à quel domaine le message doit être transmis : CS (Circuit Switch), PS
(Packet Switch) ou IMS ;
— Rend transparent le passage du domaine IP vers le domaine circuit
— le SMS-GMSC le voit comme un MSC ou un SGSN connecté à travers le MAP ;
— le SMS-IW-MSC le voit comme un MSC ou un SGSN connecté à travers le
MAP ;
— Répond avec son adresse aux requêtes de routage de message court venant du HSS ;
— Lors d’un envoie de message dans le domaine circuit, il se connecte au HSS via MAP
pour trouver l’adresse du MSC/SGSN concerné ;
— Garde une corrélation entre le MSISDN/IMSI et l’adresse du S-CSCF associé ;
— Lors d’un envoi de message dans le domaine circuit, il vériﬁe si les adresses de
l’émetteur et du récepteur sont correctes au niveau des en-têtes SIP ;
— Quand un message est envoyé du domaine circuit vers le domaine IP, il doit traduire
le MSISDN/IMSI en TEL URI (si disponible) ou en SIP URI ;
— Il se présente comme un serveur d’application vis à vis du cœur IMS ;
— Il lit et interprète depuis le HSS les étiquettes disponibles pour recevoir des SMS.
4.2.3 Fonctionnalités du HSS
Les fonctionnalités générales du HSS sont [17] :
— Connaitre pour chaque abonné les adresses correspondants à son IP-SM-GW ;
— Avoir des étiquettes qui indiquent l’enregistrement au niveau du IP-SM-GW pour
chaque souscription ;
30

— Répondre aux requêtes de routage de message provenant du IP-SM-GW avec l’adresse
(IMSI) du MSC/SGSN ;
— Sauvegarder l’adresse du SMSC émetteur du message reçu quand l’utilisateur n’est
pas disponible. Il doit informer le SMSC lorsque l’utilisateur se connecte afin qu’il
envoie le message à nouveau ;
— Envoie un message de notification au IP-SM-GW quand l’utilisateur se connecte
après un échec d’envoie antérieur ;
— Accepte le statuts d’envoi de message IP-SM-GW au lieu du SMS-GMSC.
4.2.4 Enregistrement de l’UE à l’IMS et mise à jour de sa joi-
gnabilité
La figure 4.6 montre le flux de signalisation de l’enregistrement pour le traitement
des SMS.
— L’usager s’enregistre avec succès à l’IMS
— Le S-CSCF analyse la requête REGISTER et identifie qu’il y a correspondance avec
un initial filter criteria (iFC). Le S-CSCF émet une requête REGISTER (third-
party REGISTER) au serveur d’application IP-SM-GW. L’Initial Filter Criteria
pour l’AS IP-SM-GW inclut une information de service qui contient sous forme de
body le MSISDN appartement à “sip :kokougaglo@lirt.sn”.
— Requête REGISTER (S-CSCF à l’IP-SM-GW). Ce flux de signalisation relaie la
requête REGISTER du S-CSCF à l’AS IP-SM-GW.
— Réponse 200 OK (IP-SM-GW à S-CSCF). L’IP-SM-GW retourne la réponse 200
OK au S-CSCF indiquant le succès de l’enregistrement.
— Requête SUBSCRIBE (IP-SM-GW à S-CSCF). L’AS IP-SM-GW souscrit auprès
du S-CSCF pour être notifié lors du changement d’état de l’usager (i.e., l’UE est
désenregistré).
— Réponse 200 OK (S-CSCF à IP-SM-GW). Le S-CSCF retourne une réponse 200 OK
à l’AS IP-SM-GW.
— Requête NOTIFY (S-CSCF à IP-SM-GW). Le S-CSCF émet une première requête
NOTIFY à l’IP-SM-GW. La notification indique que l’UE est enregistré et que la
demande de souscription de l’IP-SM-GW est active.
— Réponse 200 OK (IP-SM-GW à S-CSCF). IP-SM-GW émet une réponse 200 OK
au S-CSCF.
— MAP : AnyTimeModification. L’IP-SM-GW émet une requête afin d’informer le
HLR/HSS que l’usager avec le MSISDN « +22125555 » est prêt à recevoir des mes-
sages courts via l’IP-SM-GW. La variable IP-SM-GW Number du profil de l’usager
dans le HLR contient le Global Title (GT) de l’AS IP-SM-GW ;
31

— Réponse MAP : AnyTimeModification. Le HLR/HSS acquitte la requête.
Figure 4.6 – Enregistrement de l’UE à l’IMS et mise à jour
4.2.5 Envoi de SMS via l’IMS
La figure 4.7 décrit l’envoi de SMS sur IP [18].
— L’UE soumet un message SMS (SMS-SUBMIT, SC Address) au S-CSCF en utilisant
une requête SIP MESSAGE. Cette requête sert d’enveloppe SIP pour l’envoi d’un
SMS tel qu’il aurait été émis via un accès 2G/3G. Le message SMS-SUBMIT contient
trois informations essentielles (figure 4.8) : Global Title (GT) du SMSC, MSISDN
du destinataire du SMS, et le texte.
— Le S-CSCF relaie le message (SMS-SUBMIT, SC Address) à l’entité IP-SM-GW
(AS) suite au déclenchement d’un iFC (Initial Filter Criteria). L’iFC correspond à
une marque de service dans le profil de service de l’émetteur du SMS. Les usagers
qui n’ont pas souscrit au service SMS disposent d’un iFC dans leur profil de service
afin de filtrer/bloquer les SMS.
— IP-SM-GW (AS) acquitte la requête SIP avec une réponse SIP 202 Accepted signi-
fiant que la requête MESSAGE a bien été reçue, mais n’a pas encore été délivrée au
destinataire.
— La réponse 200 Accepted est routée par le S-CSCF à l’UE émetteur.
32

— L’entité IP-SM-GW réalise la procédure d’autorisation du service SMS sur la base
des données de souscription. Tout « barring » de SMS est réalisé par l’IP-SM-GW
comme l’aurait réalisé un MSC/VLR ou un SGSN. Si le résultat de l’autorisation
est négatif alors l’IP-SM-GW ne doit pas relayer le message court et doit retourner
à l’UE émetteur un code de réponse négatif. Sinon, l’IP-SM-GW extrait le mes-
sage SMS (SMS-SUBMIT) de la requête SIP MESSAGE et le relaie au SMSC (SC
Address) en utilisant le protocole MAP (MAP-MO-FORWARD-SM.Req).
— Le SMSC retourne un acquittement au message MAP-MO-FORWARD-SM.Req à
l’ IPSM-GW.
— IP-SM-GW (AS) émet un message SUBMIT-REPORT au S-CSCF, encapsulé dans
une requête SIP MESSAGE à destination de l’UE.
— Le S-CSCF émet le SUBMIT-REPORT dans une requête SIP MESSAGE à l’UE.
— L’UE acquitte le message SUBMIT-REPORT.
— Le S-CSCF relaie l’acquittement à l’IP-SM-GW (AS).
Figure 4.7 – Envoi d’un SMS
33

Figure 4.8 – Contenu du message SMS-SUBMIT encapsulé dans une requête SIP MES-
SAGE
4.2.6 Réception de SMS
La figure 4.9 décrit la réception de SMS sur IP. Le scénario concerne un usager
enregistré dans le monde IMS avec une adresse sip : james@lirt.sn associée à un numéro
de téléphone tel :+221776814199. Ces 2 IMPUs sont présentées dans le même profil de
service. L’usager dispose d’un UE ayant la capacité SMS. L’IP-SM-GW AS est informé
de l’enregistrement de l’UE [18].
— Le SMSC de l’émetteur du SMS interroge le HLR/HSS de la destination du SMS
afin d’identifier le GT (Global Title) du nœud auquel le SMS doit être délivré.
— Le HLR retourne le GT de l’IP-SMS-GW.
— Le SMSC émet la requête MAP-MT-FORWARD-SM à l’IP-SMS-GW.
— L’IP-SMS-GW sait que l’UE est enregistré dans le domaine IMS. Il traduit le mes-
sage MAP reçu du SMSC en une requête SIP MESSAGE contenant le message
court sous forme de message SMS-DELIVER, puis l’envoie au S-CSCF qui prend
en charge l’UE destinataire.
— Le S-CSCF route la requête SIP MESSAGE à l’UE
— L’UE l’acquitte via une réponse 200 OK. La réponse 200 OK est relayée par le
S-CSCF à l’IP-SMS-GW
— L ’UE acquitte le message SMS-DELIVER par un message SMS-DELIVER-REPORT
encapsulé dans une requête SIP MESSAGE afin d’être délivré à l ’IP-SM-GW via
le SCSCF.
— L’IP-SM-GW acquitte la réception de la requête SIP MESSAGE contenant le SMS-
DELIVER-REPORT par une réponse 200 OK.
— L’IP-SMS-GW retourne un acquittement de livraison de SMS au SMSC via le pro-
tocole MAP.
34

Figure 4.9 – Livraison de SMS réussie via l’IMS
4.2.7 Désenregistrement de l’UE à l’IMS et mise à jour de sa
non joignabilité
La figure 4.10 montre un usager se désenregistrant du réseau IMS. L’entité IP-SM-GW
informe le HLR/HSS de cet événement [18].
— Le désenregistrement de l’UE consiste en une requête REGISTER dont le champ
Expires est positionné à 0.
— Requête NOTIFY (S-CSCF à IP-SM-GW). Le S-CSCF émet une première requête
NOTIFY à l’entité IP-SM-GW. La notification indique que l’IMPU n’est plus enre-
gistrée pour recevoir des SMS.
— Réponse 200 OK (IP-SM-GW à S-CSCF). L’entité IP-SM-GW émet une réponse
200 OK au S-CSCF.
— Requête MAP : AnyTimeModification. L’entité IP-SM-GW émet une requête au
HLR/HSS afin de l’informer que l’usager avec le MSISDN « +22125555 » n’est plus
disponible pour recevoir des SMS via l’IP-SM-GW.
— Réponse MAP : AnyTimeModification. Le HLR/HSS acquitte la réception de la
requête correspondante.
35

Figure 4.10 – L’IP-SM-GW indique au HSS l’indisponibilité de l’IMPU pour la livraison
des SMS
Le HSS est mis à jour par l’IP-SM-GW AS avec les données suivantes :
— UE Not Reachable via IP-SM-GW Flag (UNRI)
— UE Not Reachable via IP-SM-GW Reason (UNRR)
Ce chapitre nous a permis de comprendre le processus de gestion du sms dans un
réseau IMS via l’entité IP-SM-GW et justiﬁe aussi le détail que nous avons fourni sur
la gestion du sms dans le domaine circuit. L’entitité IP-SM-GW est bien une passerelle
entre les messages SIP et les messages de type MAP.
36

Chapitre 5
APIs et environnements de
développement des serveurs
d’application
5.1 Les APIs
Les solutions orientées API désignent les approches qui se focalisent sur la définition
d’interfaces de haut niveau pour la programmation de services de télécommunication.
Ces interfaces permettent d’abstraire les ressources et de faciliter ainsi le développement
des applications. Dans ce chapitre, sont décrites les architectures qui ciblent les services
de télécommunications dans les NGN, à savoir, les architectures JAIN (Java APIs for
Integrated Networks) et l’architecture PARLAY/OSA du groupe PARLAY/.
5.1.1 JAIN SLEE
5.1.1.1 Java APIs for Integrated Networks (JAIN)
JAIN (Java APIs for Integrated Networks) est un ensemble d’interfaces de program-
mation qui fournit un cadre complet pour le développement des services s’exécutant aussi
bien sur les réseaux en mode paquet que sur les réseaux en mode circuit. Conçu pour la
plate-forme Java, cet ensemble d’interfaces vise à assurer la portabilité des services et à
répondre aux besoins de convergence des réseaux. Le cadre JAIN repose sur le principe
de séparation entre la programmation des services et celle du réseau. Ainsi, il se définit
à travers deux couches : la couche application et la couche protocole. En ce qui concerne
la couche protocole, JAIN a normalisé les interfaces permettant l’accès aux protocoles
de signalisation de différents types de réseaux. Ces protocoles sont : TCAP, ISUP,INAP,
MAP, H.323, SIP et MGCP. Ainsi, il offre la possibilité d’utiliser des piles de protocoles
provenant de plusieurs constructeurs sans influencer le développement des services. Cette
37

solution apporte une portabilité maximum des composants développés au niveau de la
couche application. Il faut noter que JAIN définit uniquement les APIs (interfaces) des
protocoles. En effet, l’implémentation d’une interface donnée se traduit par le développe-
ment d’un adaptateur spécifique pour chaque pile de protocole propre à un constructeur.
Au compte de ces implémentations, on peut citer la célèbre pile de protocole JAIN SIP du
National Institute of Standards and Technology (NIST). La couche application met l’em-
phase sur les APIs liées à la commande des appels (JCC, JAIN Call Control), la création de
services et sur l’environnement d’exécution (JSCE/SLEE, JAIN Service Creation/Service
Logic Execution Environment). En effet JAIN définit un modèle d’appel indépendant des
protocoles de signalisation des différents réseaux. L’objectif poursuivi est de masquer les
particularités des protocoles en offrant aux applications un modèle d’appel uniforme. Les
entités de la couche application peuvent accéder aux adaptateurs de la couche protocole à
travers les APIs définies à cet effet. JSLEE est un environnement d’exécution qui procure
une abstraction par rapport à ce qui l’entoure. Nous détaillerons son fonctionnement et
ses principes dans le paragraphe sur l’environnement SLEE. JSCE est un environnement
de développement de services fonctionnant dans un SLEE. JSCE permet de créer des
modules de services qui peuvent être assemblés pour former de nouveaux services. JAIN
définit donc des APIs de bas niveau pour l’abstraction des protocoles et des APIs de haut
niveau pour l’abstraction du traitement des appels. Cette architecture présente néanmoins
une limite que constitue sa forte dépendance de la plateforme Java.
5.1.1.2 Définition et architecture du JAIN SLEE
Un SLEE est un environnement d’exécution de services. JAIN SLEE est un standard
Java décrit à travers la JSR 240 qui définit un modèle de développement basé sur les
événements, le cycle de vie d’une application et des outils de gestion pour des services de
télécommunications. L’architecture JSLEE définit aussi le contrat entre les composants
et leur conteneur à l’exécution. JAIN a une architecture qui lui confère une indépendance
vis-à-vis des protocoles de communication d’où sa prise en charge d’un grand nombre
de protocoles par ses adaptateurs. Les adaptateurs sont à l’extérieur de l’environnement
SLEE. Ils ont une fonction importante qui est la traduction des messages des protocoles
en événements consommés par la SLEE. Pour la création de service, JAIN SLEE définit le
concept Service Building Block (SBB) qui est un composant atomique réutilisable et qui
souscrit auprès du routeur d’événements (à l’intérieur de la SLEE) pour recevoir certains
événements et produire des réponses à ces événements. Le SBB exécute la logique de
l’application. Un ou plusieurs SBBs forme un service. Les adaptateurs décrits plus haut
sont appelés des Resource Adaptors dans la terminologie JSLEE. L’architecture JSLEE
est décrite par la figure 5.1.
38

Figure 5.1 – Architecture JSLEE
5.1.2 OSA/Parlay et Parlay X
L’objectif de ce groupe est de spécifier un ensemble d’interfaces ouvertes (API) per-
mettant aux opérateurs ainsi qu’aux fournisseurs tiers de construire des applications qui
reposent sur la commande en temps réel des ressources des systèmes de télécommunication.
Les interfaces spécifiées par PARLAY sont indépendantes des technologies et des langages
de programmation ; elles comprennent des définitions de méthodes, d’évènements, de pa-
ramètres et de leur sémantique. L’architecture PARLAY possède trois caractéristiques
essentielles qui la distinguent de la solution JAIN. Ces caractéristiques sont :
— La fourniture d’interfaces standards et indépendantes de toute technologie et de
langage de programmation ;
— L’offre d’un cadre permettant l’accès sécurisé des fournisseurs situés à l’extérieur du
domaine administratif de l’opérateur qui contrôle le système de télécommunications
— La prise en compte, en plus de la téléphonie, d’une large gamme de services, tels que
les services de localisation, les services de messagerie,les services multimédia, etc.
Les APIs publiées par PARLAY sont spécifiées en langage UML (Unified Modeling
Language) et sont organisées en paquetages d’une manière hiérarchique. Quant à l’archi-
tecture, elle est définie à travers six blocs conceptuels, à savoir, le service, l’application
cliente, le cadre d’utilitaires (framework ) et les fonctions d’administration liées à chacun
39

de ces blocs (figure 5.2).
Figure 5.2 – Les Interfaces Parlay
L’interface N°1 se positionne entre l’application cliente et le service. Cette interface
couvre les fonctions de commande des services. L’application cliente contient la logique du
service global à offrir. Le bloc service offre l’ensemble des capacités que les ressources du
réseau sont capables de fournir. De la même façon que pour JAIN, l’interface N°1 se défi-
nit par un couple d’interfaces : l’interface utilisateur et l’interface fournisseur. L’interface
utilisateur est nommée « interface d’application » (Application Interface) ; celle relative
au fournisseur est appelée « interface de service » (Service Interface). Contrairement à
JAIN, l’architecture PARLAY ne propose pas d’interfaces de protocoles.
L’interface N°2 définit les interactions entre l’application cliente et le bloc utilitaire (frame-
work). En effet, le framework offre l’ensemble des fonctionnalités nécessaires à la sécurité
et à la gestion des interfaces de service. Les fonctionnalités offertes couvrent la gestion de
la sécurité d’accès, la gestion de l’intégrité, la gestion de la souscription et la découverte
des services. En d’autres termes, le framework assiste les applications dans leur accès et
dans l’utilisation des capacités offertes par le bloc service.
Les interfaces 3 et 5 sont utilisées par les développeurs de services. L’interface N°5 permet
l’enregistrement par la gestion des capacités nouvellement déployées. Elle offre aussi des
fonctions de gestion d’intégrité utilisables par les administrateurs des services. L’interface
40

N°3 permet de réaliser d’une manière automatique les fonctions offertes par l’interface
N°5.
Ces deux interfaces autorisent également le déploiement de capacités développées par des
parties tierces.
Enfin, les interfaces N°4 et N°6 permettent de supporter de manière normalisée l’accès à
des fonctions de gestion pour l’administration des services et des utilitaires. En revanche,
la gestion interne de ces derniers ainsi que la gestion des applications ne sont pas couvertes
par les spécifications PARLAY.
Les interfaces N°1 et N°2 sont mises en œuvre par un Parlay Gateway dans les solutions
des constructeurs. Le Parlay Gateway assure la traduction entre les interfaces Parlay et
les protocoles de télécommunication pour utiliser les interfaces offertes par les éléments de
réseau. Parmi ces protocoles figurent INAP, CAP, MAP, ISUP, SIP et H.323. Le Parlay
Gateway est considéré par les constructeurs de télécommunication tels qu’ALCATEL ou
ERICSSON, comme une application présente sur leur offre SCP Réseau Intelligent (Fi-
gure 5.4). Le SCP dispose de tous les protocoles cités ci-dessus, pour interagir avec les
éléments de réseaux GSM, RTCP et NGN. L’application Parlay Gateway offre par ailleurs
une interface IT aux serveurs d’application contenant les applications Parlay. Parmi les
interfaces IT possibles figurent CORBA (Common Object Request Broker Architecture),
Java RMI (Remote Method Invocation), HTTP (HyperText Transport Protocol), SOAP
(Simple Object Access Protocol) et DCOM (Distributed Object Component Model). De
nouveaux fournisseurs proposent des Parlay Gateways indépendants (Figure 5). Ces four-
nisseurs ne vendent pas d’équipements de télécommunication et leur produit Parlay Ga-
teway est conçu à partir de piles (stack) protocolaires permettant la communication avec
les éléments de réseau à travers des protocoles standards. Parmi ces fournisseurs figurent
Infitel, Aepona, IpGen et Incomit.
41

Figure 5.3 – La solution Parlay des fournisseurs de télécommunication
L’autre composant important de l’architecture Parlay est le serveur d’application (Ap-
plication Server). Ce dernier fournit un environnement de création de service standard avec
des langages de programmation tels que JAVA, C++, HTML, XML, etc. Par ailleurs, le
serveur d’application est un client Parlay qui peut invoquer des méthodes publiées par le
framework et les services Parlay (interfaces N°1 et N°2).
42

Figure 5.4 – La solution Parlay des fournisseurs indépendants
5.1.3 SIP Servlet (JSR 289)
Les SIP Servlets sont définis dans la JSR 116 dans leur version 1 et dans la JSR 289
pour la version 1.1 . La spécification des SIP Servlets définit une approche basée sur les
conteneurs, semblables aux Servlet HTTP, pour développer des applications SIP. Une
SIP Servlet est donc un composant d’application JAVA géré par un conteneur de SIP
servlet. SIP Servlet ne traite que la signalisation SIP. Le conteneur de Servlet peut être
une extension d’un serveur d’application qui fournit les services réseau afin de traiter les
requêtes et réponses SIP.
Le conteneur doit aussi prendre en charge les retransmissions. Contrairement aux
Servlet HTTP, les SIP Servlet sont asynchrones. Elles s’intègrent parfaitement dans un
environnement J2EE et peuvent donc avoir accès à ses composants (Enterprise Java Bean,
43

Http Servlet, webservices, Java Server Face). Ainsi, on peut créer des applications conver-
gentes. Une application convergente est une application qui intègre les fonctionnalités SIP
dans des applications J2EE. Par exemple, une application web donnant accès au répertoire
téléphonique des employés et qui leur permet d’initier des appels VoIP depuis l’interface
Web. Une SIP Servlet peut prendre en charge les appels VoIP et une HTTP Servlet gère
les interactions au niveau de l’interface web. Comme les servlets HTTP, chaque servlet
SIP étend une classe javax.servlet.sip.SipServlet de base. Tous les messages arrivent par la
méthode service que l’on peut surcharger. Toutefois, en l’absence de mappage un à un des
requêtes aux réponses dans le protocole SIP, la pratique conseillée consiste à développer
les méthodes doRequest ou doResponse à la place.Dans ce cas, il est important d’appeler
la méthode développée pour terminer le traitement. Chaque méthode de requête devant
être prise en charge par les spéciﬁcations, dispose d’une méthode doxxx comme HTTP.
Dans le protocole HTTP, les méthodes telles que doGet et doPost existent pour les
requêtes GET et POST. Pour le protocole SIP, les méthodes doInvite, doAck, doOp-
tions, doBye, doCancel, doRegister, doSubscribe, doNotify, doMessage, doInfo et doPrack
existent pour chaque méthode de requête SIP.
Contrairement à une servlet HTTP, les servlets SIP disposent de méthodes pour chaque
type de réponse pris en charge. Ainsi, les servlets SIP comprennent les réponses doProvi-
sionalResponse, doSuccessResponse, doRedirectResponse et doErrorResponse.
Le modèle de programmation des SIP Servlet étant proche de celui de HTTP Servlet,
il est facile pour un développeur JEE de s’y familiariser. La courbe d’apprentissage de
JSLEE est beaucoup plus longue que celle de SIP Servlet.
5.2 Environnements de développement et de création
de services
Un environnement de création de service est généralement une collection d’outils de
création de services et de ressources pour déployer et tester des applications.
5.2.1 Serveurs d’application
Les serveurs d’applications décrits ci-dessous concernent les serveurs sur lesquels on
peut développer un service.
5.2.1.1 Mobicents JAIN SLEE
JSLEE Mobicents est la seule implémentation open source de JSLEE certiﬁée JSLEE
1.1 ; elle fait partie de la suite Mobicents Communication Plateform. Mobicents JSLEE
est déployé sur un serveur JEE JBOSS. JSLEE Mobicents propose aussi un déploiement
44

facile des applications. Il offre également une console JMX qui permet la configuration et
le contrôle des applications SLEE de manière simple. JSLEE Mobicents offre un ensemble
de Resource Adaptors. Parmi eux nous citons entre autre :
— JAIN SIP
— SMPP
— MAP
— XMPP
— XCAP Client
— Diameter Sh Server
5.2.1.2 OpenCloud Rhino SDK
OpenCloud Rhino SLEE est un serveur d’application qui supporte le développement
d’applications de télécommunication. C’est une plateforme Java conforme à la spécifica-
tion JSLEE 1.1 tout comme Mobicents SLEE. Rhino SLEE a une double licence : une
propriétaire et l’autre communautaire à but éducatif. OpenCloud a réalisé un plug-in
nommé Rhino Visual Service Architect pour l’IDE Eclipse qui sert à développer sans
presque écrire du code source. Ce plugin met à disposition des « boîtes » standard que
l’on configure selon ses besoins. C’est un outil graphique qui génère le code Java corres-
pondant au modèle SLEE. Le développeur se concentre sur la définition des machines à
états finis de son application.
5.2.1.3 Mobicents SIP SERVLET et SailFin
Mobicents SIP Servlet est un sous projet de la plateforme de communication Mobi-
cents. C’est un conteneur de servlet compatible avec la JSR 289 et offre une plateforme
sur laquelle on peut développer et déployer des services SIP portables de même que des
services convergents JEE. Il peut être déployé soit sur un serveur d’application JBoss ou
un serveur Tomcat. Le conteneur fournit un support pour l’interface Sh par le biais des
fonctionnalités qui peuvent être importées depuis le serveur Mobicents Diameter. Cette
interface permettra de développer des services nécessitant un accès à la base de données
HSS. Le serveur Mobicents Diameter fournit les interfaces Cx et Dx ainsi que le Credit
Control Application. Cette dernière est une application IETF qui utilise le protocole Dia-
meter pour implémenter le contrôle de crédit en temps réel.
SailFin est un conteneur de Servlet SIP au même titre que Mobicents SIP Servlet. Sail-
Fin est un produit de la firme Oracle. Les servlets développés avec le framework SailFin
sont déployés sur un serveur Java dénommé GlassFish. SailFin fournit un support natif
pour SIP et possède une interface Sh pour interagir avec un HSS. En plus, il fournit les
interfaces Ro et Rf qui sont nécessaire pour gérer la facturation.
45

5.2.2 Serveurs multimédia
Ce sont les serveurs qui traitent les flux multimédia et gèrent parfois le transcodage
pour adapter une session aux codecs supportés par un participant de la dite session.
5.2.2.1 Mobicents Media Server
Mobicents Media Server est la composante média de la plateforme de communication
Mobicents. Elle est diffusée sous une license LGPL 2.1. Il s’agit d’un serveur média open
source développé dans le langage de programmation Java et prend en charge à la fois les
interfaces IP et traditionnelles TDM. Ainsi, il peut agir comme un serveur multimédia
ou une passerelle multimédia. Mobicents Media Server fournit une interface SIP qu’elle
utilise pour mettre en œuvre l’interface Mr avec le S-CSCF. Il définit aussi plusieurs
protocoles de contrôle d’appel pour contrôler les processeurs multimédia. Au nombre de ces
protocoles, il y a : MGCP, MEGACO, MSCML et la JSR 309. MEGACO est un protocole
de l’IETF pour contrôler les serveurs de média et compatible avec H.248. MSCML ou
Media Control Server Markup Language qui est également un protocole IETF définissant
un langage de balisage qui peut être utilisé en conjonction avec SIP pour contrôler un
serveur multimédia. MSCML est généralement utilisé pour les services de conférence.
JSR309 définit une API de contrôle de média, générique et facile à utiliser qui cache la
complexité de l’appel sous-jacent des protocoles de contrôle pour le développeur. Cette
API fonctionne uniquement avec les serveurs de médias conformes JSR 309. Mobicents
Media Server prend en charge les codecs audio G.711a, G.711u, GSM, G.729 et speex ; en
plus du codec H.261 pour la vidéo. Il possède aussi un moteur Text-To-Speech et prend
en charge le DTMF.
5.2.2.2 SIP Express Media Server
SIP Express Media Server (SEMS) est une plateforme de médias et d’application pour
les services VoIP basés sur le protocole SIP. Il est publié sous une double licence : GPL
version 2 et une licence propriétaire. SEMS n’est pas autonome et nécessite pour son
fonctionnement d’être en conjonction avec un serveur SIP. Etant un projet de iptel.org,
SEMS est souvent utilisé avec le serveur SIP Sip Express Router(SER) pour fournir des
services de multimédia. SEMS est basé sur une conception modulaire qui définit les fonc-
tionnalités de base et supporte l’insertion de modules sous forme de plugin qui ajoutent
des fonctionnalités supplémentaires. Une API de base reposant sur C ++ est disponible
pour étendre les capacités du serveur, mais les développeurs peuvent également utiliser un
interpréteur Python embarqué pour ajouter des extensions sous forme de scripts Python.
SEMS fournit les services multimédia de base tels que la lecture d’annonces, la messagerie
vocale et la conférence. Pour ce faire, SEMS supporte les codecs audio G.711a, G.711u
iLBC, GSM et Speex.
46

5.2.3 IDE Eclipse et le plugin Mobicents EclipSLEE
Eclipse IDE (Integrated Development Environment) est un IDE dédié au développe-
ment de logiciels basés sur Java (bien que d’autres langages soient supportés également
(C/C++, python,php, ruby, etc.). Il s’agit d’un projet de la Fondation Eclipse visant à
développer tout un environnement de développement libre, extensible, universel et polyva-
lent. Son objectif est de produire et fournir divers outils gravitant autour de la réalisation
de logiciel, englobant les activités de codage logiciel proprement dites (avec notamment
un environnement de développement intégré) mais aussi de modélisation, de conception,
de test, de reporting, etc. Son environnement de développement notamment vise à la gé-
néricité pour lui permettre de supporter n’importe quel langage de programmation. Le
module Mobicents EclipSLEE facilite la création d’applications conformes aux standards
SLEE. Il sert aussi à compiler et déployer directement l’application dans le serveur Mo-
bicents JSLEE. Sa fonction principale est de guider dans le développement et d’aider à
créer les modèles de bases et les composants tels que les événements, les Service Bulding
Blocks, Ressource Adaptors.
5.3 OpenIMSCore
L’OpenIMSCore (ﬁgure 5.5) est une implémentation des Call Session Control Func-
tions (CSCFs) et du HSS (Home Subscriber Server), qui forment ensemble le réseau coeur
des architectures IMS/NGN comme spéciﬁé par le 3GPP, le 3GPP2, l’ETSI TISPAN et le
PacketCable intiative. Les outils utilisés dans le développement sont tous des outils open
source (ex. le SIP Express Router (SER) et MySQL).
Né du domaine de la Recherche & Developpement, le projet OpenIMSCore, initié par
l’institut de recherche allemand FOKUS a pour but de combler le vide dans le monde
open source de l’IMS. Il a aussi pour but de fournir une implémentation de référence du
noyau IMS pour tester cette technologie et mettre en œuvre des concepts qui entourent
l’IMS dans le cadre des travaux de recherche. A travers ce projet, tous les développeurs
potentiels des services IMS devrait avoir une interface complète de contrôle IMS, conforme
à 3GPP, ce qui va leur permettre de s’en servir pour développer et tester leurs services.
Cependant, aussi au niveau de la couche accès, l’OpenIMSCore, vise à susciter le dévelop-
pement de composants et concepts qui relient le noyau IMS aux divers réseaux d’accès.
47

Figure 5.5 – Architecture de l’OpenIMSCore
5.4 Kamailio IMS
Kamailio (ancien OpenSER ) est un Serveur proxy, serveur d’application SIP , serveur
d’enregistrement, serveur de localisation, Serveur de redirection ; distribué sous licence
GPL , capable de gérer des milliers d’appels par seconde. Il est caractérisé par la Com-
munication sécurisée via TLS pour la VoIP (voix, vidéo), la messagerie instantanée et
notification de présence, le routage, l’équilibrage de charge, la comptabilité, l’authentifi-
cation et l’autorisation avec MySQL, postgrès, Oracle, Radius, LDAP. Depuis la version
4 des extensions lui ont été ajoutées afin d’implémenter les serveurs P-CSCF, I-CSCF et
S-CSCF. Le E-CSCF et le HSS ne sont pas implémentés.
48

Chapitre 6
Scénarios de tests et de simulations
Ce chapitre résume tous les scénarios de tests qui ont été eﬀectués avec les plateformes
et environnements existants à savoir OpenImsCore, Mobicents, Eclipse. Les tests consitent
en la création d’un AS IP-SM-GW.
6.1 Les SIP UA et les rôles SM-over-IP sender/receiver
Lors de l’envoi de la requête REGISTER, le client IMS doit indiquer sa capacité
à recevoir des sms traditionnels (format RP-DATA) via le réseau IMS en incluant le
paramètre "+g.3gpp.smsip" dans l’en-tête Contact [19].
Les clients IMS supportant actuellement l’envoie et la réception de ce type de messages
binaires sont IMSDroid (ﬁgure 6.1) un client disponible pour smartphone android et le
client Boghe IMS Client de Doubango Telecom .
Figure 6.1 – Requête REGISTER avec le client IMSDroid
Il faut cependant noter que les sms envoyés par ce client IMSDroid sont toujours au
format text/plain et non RP-DATA.
Le client UCT IMS Client quand à lui ne supporte pas le sms over IP.
49

6.2 L’enregistrement à trois partie (Third Party Re-
gistration)
Le paragraphe 4.2.4 décrit le "Third Party Registration" requis dans la spécification
du sms over IP. Dans cette architecture l’IP-SM-GW reçoit un message REGISTER pro-
venant du S-CSCF chaque fois que les utilisateurs s’enregistrent ou se désenregistrent dans
le domaine IMS. Comme pour les autres invocations le mécanisme est basé sur un Initial
Filter Criteria, celui-ci étant lié au message SIP REGISTER. De cette façon, l’IP-SM-GW
peut également très facilement avoir l’adresse du S-CSCF alloué à l’utilisateur. L’IP-SM-
GW peut donc procéder à l’enregistrement des messages des utilisateurs absents ou leur
transmettre des messages en attente lorsqu’ils se connectent à nouveau. L’implémentation
du S-CSCF d’OpenIMSCore ne dispose de cette fonctionnalité.
6.3 Les interfaces du HSS
L’interface S6c permet la récupération des informations de routage pour le transfert
de messages courts, le rapport du status de livraison d’un sms et les messages d’alerte
entre le SMS-SC et le HSS, le SMS-GMSC et le IP-SM-GW. Avec cette interface le HSS
doit :
— vérifier si l’utilisateur identifié par le MSISDN est connue ; sinon le HSS doit retour-
ner un code ExperimentalResult-Code ayant pour valeur
DIAMETER_ERROR_USER_UNKNOWN.
— vérifier si un abonnement SMS MT Téléservice existe ; sinon le HSS doit retourner
un code ExperimentalResult-Code ayant pour valeur
DIAMETER_ERROR_SERVICE_NOT_SUBSCRIBED.
— vérifier si l’utilisateur n’a pas interdition de recevoir des messages SMS MT ; autre-
ment, le HSS doit retourner un un code ExperimentalResult-Code ayant pour valeur
DIAMETER_SERVICE_ERROR_BARRED.
— vérifier si un ou plusieurs noeuds de service sont enregistrés pour recevoir des SMS
MT ; autrement, le HSS doit retourner un code ExperimentalResult-Code ayant
pour valeur
DIAMETER_ERROR_ABSENT_USER.
— doit retourner une réponse avec le code Result-Code ayant pour valeur DIAME-
TER_SUCCESSFUL à la requête "Send Routing Info for SM" qui doit contenir les
adresses des noeuds de service qui ont été enregistré pour les MT SMS.
Le HSS installé avec OpenIMSCore n’implémente que les interfaces Sh et Cx.
50

6.4 Scénario alternatifs expérimentés
Le but de l’enregistrement en trois parties est d’enregistrer l’abonné auprès du IP-SM-
GW et de permettre à ce dernier de souscrire aux messages de présence de l’utilisateur.
Le S-CSCF de simulation ne supportant pas le "Third Party Registration" , nous avons
expérimenté le module ESL (Event Socket Library) du SoftSwitch FreeSwitch puis l’im-
plémentation d’un serveur de présence dans l’IP-SM-GW.
6.4.1 L’ESL de FreeSwitch
Figure 6.2 – Architecture avec FreeSwitch ESL
L’ "Event Socket Library" ou ESL, est une bibliothèque qui vise à faciliter le contrôle
de FreeSwitch depuis des applications externes. Ces dernières peuvent être écrits dans
tous les langages et exécutés sur tout système d’exploitation. L’ESL est écrit en C et a
des interfaces pour de nombreuses langues : Perl, Python, PHP, Lua, Ruby, C# et Java.
Une application ESL a accès à toutes les commandes API exportés par FreeSwitch [20].
Dans l’architecture avec l’ESL que nous avons expérimentée, le S-CSCF s’occupe de l’en-
registrement classique de l’utilisateur et via des iFC ; transfère les requêtes de type SUB-
SCRIBE,NOTIFY,PUBLISH au serveur FreeSwitch (ﬁgure 6.2) qui fait oﬃce de serveur
51

de présence. A travers l’interface ESL de FreeSwitch notre HSS est notifié lorsqu’un uti-
lisateur change de status (connecté,déconnecté). Ceci permet au IP-SM-GW d’une part
d’envoyer le sms à l’utilisateur connecté ou qui vient de se connecter et qui a un message
en attente et d’autre part de sauvegarder le sms si l’utilisateur n’est pas en ligne.
6.4.2 L’IP-SM-GW comme AS de présence
Figure 6.3 – IP-SM-GW comme AS de présence
Dans cette configuration, le S-CSCF transfère tous les messages de présence au serveur
d’application IP-SM-GW. Ce dernier traite ,en amont, les messages de type SUBSCRIBE,
NOTIFY, PUBLISH comme un serveur de présence classique (figure 6.3) et en aval joue
le rôle de passerelle sms. Dans le rôle de passelle sms, à chaque fois qu’un message de
présence de type "online" est reçu, l’IP-SM-GW envoie une requête au HSS afin de savoir
si l’abonné qui vient de se connecter n’a aucun message stocké. Si l’abonné en a, il les lui
envoie. Si c’est un status "offline" il stocke ses messages au niveau du HSS.
52

Conclusion et Perspectives
Les objectifs de nos travaux de recherche étaient de faire l’état de l’art sur les pro-
positions des centres sms dans les réseaux convergents ainsi que les spécifications de
développement et d’exécution de services. Avec l’introduction de l’IMS dans la 4G pour
fournir les services multimédia, une couche de serveur d’application a été ajoutée et per-
met développer des services.
Les API pour le développements des services IMS sont le JAIN SLEE, l’OSA/Parlay
et les SIP Servlets. A travers l’étude des plateformes disponibles actuellement nous avons
pu relever l’existence des environnements comme OpemIMSCore pour l’émulation d’un
cœur de réseau IMS, mobicents comme serveur d’application SIP.
Les simulations d’un IP-SM-GW nous ont permis de noter que tous les clients IMS
disponibles actuellement ne supportent pas l’envoie de sms sur IP selon la spécification
3GPP TS 24.247 [21], les messages sont donc envoyés en texte clair au lieu du format
RP-DATA. Le HSS du simulateur OpenIms Core ne supporte pas actuellement l’enregis-
trement à trois parties et n’a pas l’interfaces MAP S6 pour une liaison avec IP-SM-GW.
Dans les travaux à venir nous étudierons la possibilité d’envoi/réception de sms dans
l’architecture du LTE avec un serveur XMPP afin d’exploiter la messagerie instantanée
et la présence de l’abonné pour n’enregistrer les SMS que lorsque ce dernier n’est pas en
ligne. Cela permettra de ne pas utiliser nécessairement le mode "store and forward" des
centres sms pour mieux optimiser le réseau. Nous mènerons d’autres travaux dans le but
de développer des simulateurs de centre SMS pour avoir des environnements de tests open
source.
53

Bibliographie
[1] E. H. Bouguen, Yannick and F.-X. Wolff, LTE et les Réseaux 4G. Paris : Eyrolles,
2012.
[2] S. Ouya, A. Dahirou Gueye, K. Sy, M. Niane, and C. Lishou, “Contribution to re-
ducing the effects of geographical separation between actors of virtual universities :
Proposal of an ip-smsc integrating value-added services solutions,” in Interactive Col-
laborative Learning (ICL), 2015 International Conference on, pp. 1145–1150, Sept
2015.
[3] S. O. S. M. F. Landry T. Yelome, Samba. Ndiaye, “Contribution to sms management
over 4g network in distance education context,” IEEE, 2015.
[4] G. M. A. B. M. C. L. N. Samuel OUYA, Kokou GAGLO, “Proposal of a collaborative
software development platform for the virtual universities : the virtual university of
the senegal (uvs) experience,” 2015.
[5] P. M. D. F. M. Y. S. C. L. N. Samuel OUYA, Khalifa SYLLA, “Impact of integrating
webrtc in universities’ e-learning platforms,” 2015.
[6] A. B. M. G. M. I. N. Samuel OUYA, Cheikhane SEYED, “Webrtc platform pro-
position as a support to the educational system of universities in a limited internet
connection context,” 2015.
[7] 3GPP, “Single Radio Voice Call Continuity (SRVCC) ; Stage 2,” TS 23.216, 3rd
Generation Partnership Project (3GPP), 2015. Release 13 V13.1.0.
[8] E. Bertin, Architecture des services de communication dans un contexte de conver-
gence. PhD thesis, Ecole Doctorale EDITE, 2009.
[9] EFORT, “Réseaux et services de télécommunication concepts, principes et architec-
tures,” 2010.
[10] 3GPP, “Technical Specification Group Core Network and Terminals,” TS 23.040, 3rd
Generation Partnership Project (3GPP), 2015. Release 13 V13.0.0.
[11] A. M. X. L. Diana-Minodora Ciuraru, Lavinia Hilohi, “Sms over lte : services, archi-
tecture and protocols,” HAL, vol. hal-00814264, no. 13218, p. 62, 2013.
[12] EFORT, “Voix sur lte (volte).impacts sur l’accès lte,” 2013.
[13] EFORT, “Lte + sae = eps. principes et architecture,” 2009.
54

[14] 3GPP, “Circuit Switched (CS) fallback in Evolved Packet System (EPS),” TS 23.272,
3rd Generation Partnership Project (3GPP), 2015. Release 13 V13.2.0.
[15] 3GPP, “IP-Short-Message-Gateway (IP-SM-GW) enhancements for interworking
with Open Mobile Alliance (OMA) Converged IP Messaging (CPM),” TS 23.824,
[16] GSMA, “VoLTE Service Description and Implementation Guide (Version 2.0),”
FCM 01, GSM Association (GSMA), 2014.
[17] 3GPP, “Support of Short Message Service (SMS) over generic 3GPP Internet Protocol
(IP) access, Stage 2,” TS 23.204, 3rd Generation Partnership Project (3GPP), 2015.
Release 13 V13.0.0.
[18] E. et FORmations en Télécommunications Service et Réseaux de Télécommnunica-
tion (EFORT), “Sms sur ip via l’ims : Principes, architecture et service,” dec 2015.
[19] 3GPP, “Support of SMS over IP networks ; Stage 3,” TS 23.041, 3rd Generation
Partnership Project (3GPP), 2015. Release 13 V13.0.0.
[20] “Freeswitch esl (event socket library),” 2016.
[21] 3GPP, “IP-Short-Message-Gateway (IP-SM-GW) enhancements for interworking
with Open Mobile Alliance (OMA) Converged IP Messaging (CPM),” TS 24.247,
55

Sigles et abréviations
3GPP 3rd Generation Partnership Project
AS Application Server
CSCF Call Session Control Function
CSFB Circuit Switched FallBack
EMS Enhanced Messaging Service
eNodeB Evolved Node B
EPS Evolved Packet System
HLR Home Location Register
HSS Home Subscriber Server
IEI Information Element Identiﬁer
iFC initial Filter Criteria
IMPI IP Multimedia Public Identity
IMPU IMS Public User Identities
IMS IP Multimedia Subsystem
IP-SM-GW IP Short Message Gateway
LTE Long-Term Evolution
MGCF Media Gateway Control Function
MGW Media Gateway
MME Mobility Management Entity
MO Mobile Originated
MRFC Multimedia Resource Function Controller
MSC Mobile Switching Center
MSRP Message Session Relay Protocol
OSA Open Service Access
PCRF Policy & Charging Rules Function
RP-DATA Relay Protocol-DATA
RTP Real-time Transport Protocol
SCA Service Center Address
SIP Session Initiation Protocol
SME Short Message Entity
SMS Short Message Service
SMS-GMSC SMS Gateway MSC
SMS-IWMSC SMS-Interworking MSC
SMSC SMS Center
SPT Service Point Triggers
SRVCC Single Radio Voice Call Continuity
UDH User Data Header
USSD Unstructured Supplementary Service Data
VoLTE Voice over LTE
56

Contributions aux environnements de développement de services de télécoms dans le contexte de réseaux mobiles full IP haut débit.

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Contributions aux environnements de développement de services de télécoms dans le contexte de réseaux mobiles full IP haut débit.

Similar to Contributions aux environnements de développement de services de télécoms dans le contexte de réseaux mobiles full IP haut débit. (20)

More from Kokou Gaglo

More from Kokou Gaglo (7)

Contributions aux environnements de développement de services de télécoms dans le contexte de réseaux mobiles full IP haut débit.