contributions aux environnements de développement de services de télécoms dans le contexte de...
TRANSCRIPT
République du SénégalUn Peuple - Un But - Une Foi
Université Cheikh Anta Diop de Dakar
Ecole Supérieure Polytechnique
Groupe de Formation DoctoraleLaboratoire d’Informatique, Réseaux et Télécommunications
Mémoire de Master Recherche
Contributions aux environnements de développement deservices 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 sauraitaboutir. 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 conditionsexceptionnelles 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 BambaMbacké ;
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 cedocument.
iii
Table des matières
Dédicace i
Remerciements ii
Résumé ix
Abstract x
1 Présentation du sujet 11.1 Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Le SMS dans le réseau GSM 42.1 Architecture GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 La pile de protocole SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Le SMS Protocol Data Unit (PDU) . . . . . . . . . . . . . . . . . . . . . . 62.4 Encodage des messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Transmission de message en GSM . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.1 Mobile Originated (MO) SMS, transmission avec succès . . . . . . . 92.5.2 Transmission réussie d’un SMS vers un MS . . . . . . . . . . . . . . 112.5.3 Echec de transmission du sms . . . . . . . . . . . . . . . . . . . . . 122.5.4 Alerte au SMSC quand un abonné devient disponible . . . . . . . . 13
3 Gestion de la voix sur LTE 143.1 L’IP Multimedia Subsystem (IMS) . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1 Architecture du réseau IMS . . . . . . . . . . . . . . . . . . . . . . 143.1.2 La fourniture de services dans l’IMS . . . . . . . . . . . . . . . . . . 15
3.1.2.1 L’identité IMS . . . . . . . . . . . . . . . . . . . . . . . . 153.1.2.2 Profil d’usager et profil de service . . . . . . . . . . . . . . 16
iv
3.1.2.3 Le déclenchement des services (iFC et SPT) . . . . . . . . 173.1.3 Les serveurs d’applications . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Long Term Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.1 Architecture Evolved Packet System (EPS) . . . . . . . . . . . . . . 193.2.2 Entités du réseau EPS . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2.1 Entité eNodeB . . . . . . . . . . . . . . . . . . . . . . . . 203.2.2.2 Entité MME (Mobility Management Entity) . . . . . . . . 203.2.2.3 Entité Serving GW (Serving Gateway) . . . . . . . . . . . 203.2.2.4 Entité PDN GW (Packet Data Network Gateway) . . . . 203.2.2.5 Entité HSS (Home Subscriber Server) . . . . . . . . . . . 213.2.2.6 Entité PCRF (Policy & Charging Rules Function) . . . . . 21
3.2.3 Default et Dedicated bearers . . . . . . . . . . . . . . . . . . . . . . 213.3 La voix sur LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.1 Le Circuit Switched FallBack (CSFB) . . . . . . . . . . . . . . . . . 233.3.2 La voix avec l’IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.3 La fonction SRVCC . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.4 Solutions de sms dans VoLTE . . . . . . . . . . . . . . . . . . . . . 25
3.3.4.1 SMS avec les interfaces SGs . . . . . . . . . . . . . . . . . 253.3.4.2 SMS avec l’IP-SM-GW . . . . . . . . . . . . . . . . . . . . 25
4 Le SMS dans le réseau IMS 274.1 Le service de messagerie dans l’IMS . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1 Les messages de type "page-mode" . . . . . . . . . . . . . . . . . . . 274.1.2 Les messages de type "session-mode" . . . . . . . . . . . . . . . . . 284.1.3 Pile de protocole pour l’envoie de message . . . . . . . . . . . . . . 29
4.2 Interconnexion entre le domaine circuit et le réseau IMS . . . . . . . . . . 294.2.1 Les interfaces du IP-SM-GW . . . . . . . . . . . . . . . . . . . . . . 294.2.2 Fonctionnalités du IP-SM-GW . . . . . . . . . . . . . . . . . . . . . 304.2.3 Fonctionnalités du HSS . . . . . . . . . . . . . . . . . . . . . . . . . 304.2.4 Enregistrement de l’UE à l’IMS et mise à jour de sa joignabilité . . 314.2.5 Envoi de SMS via l’IMS . . . . . . . . . . . . . . . . . . . . . . . . 324.2.6 Réception de SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.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 375.1 Les APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.1 JAIN SLEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.1.1.1 Java APIs for Integrated Networks (JAIN) . . . . . . . . . 375.1.1.2 Définition et architecture du JAIN SLEE . . . . . . . . . . 38
v
5.1.2 OSA/Parlay et Parlay X . . . . . . . . . . . . . . . . . . . . . . . . 395.1.3 SIP Servlet (JSR 289) . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Environnements de développement et de création de services . . . . . . . . 445.2.1 Serveurs d’application . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.1.1 Mobicents JAIN SLEE . . . . . . . . . . . . . . . . . . . . 445.2.1.2 OpenCloud Rhino SDK . . . . . . . . . . . . . . . . . . . 455.2.1.3 Mobicents SIP SERVLET et SailFin . . . . . . . . . . . . 45
5.2.2 Serveurs multimédia . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2.2.1 Mobicents Media Server . . . . . . . . . . . . . . . . . . . 465.2.2.2 SIP Express Media Server . . . . . . . . . . . . . . . . . . 46
5.2.3 IDE Eclipse et le plugin Mobicents EclipSLEE . . . . . . . . . . . . 475.3 OpenIMSCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.4 Kamailio IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6 Scénarios de tests et de simulations 496.1 Les SIP UA et les rôles SM-over-IP sender/receiver . . . . . . . . . . . . . 496.2 L’enregistrement à trois partie (Third Party Registration) . . . . . . . . . 506.3 Les interfaces du HSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.4 Scénario alternatifs expérimentés . . . . . . . . . . . . . . . . . . . . . . . 51
6.4.1 L’ESL de FreeSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . 516.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 . . . . . . . . . . . . . . . . . . . . . . 42.2 Protocole implémenté pour le SMS . . . . . . . . . . . . . . . . . . . . . . 52.3 Types de messages SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 PDU d’un SMS-DELIVER en GSM . . . . . . . . . . . . . . . . . . . . . . 72.5 Concaténation de sms compressés . . . . . . . . . . . . . . . . . . . . . . . 82.6 TP-User-Data pour GSM 7 bit non compressé . . . . . . . . . . . . . . . . 82.7 Processus de segmentation de sms . . . . . . . . . . . . . . . . . . . . . . . 92.8 Message envoyé avec succès par un mobile . . . . . . . . . . . . . . . . . . 102.9 L’évolution du PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.10 Transmission réussie d’un SMS vers un MS . . . . . . . . . . . . . . . . . . 112.11 Echec de transmission du sms . . . . . . . . . . . . . . . . . . . . . . . . . 122.12 Retransmission d’un sms après échec . . . . . . . . . . . . . . . . . . . . . 13
3.1 Architecture du cœur de réseau IMS . . . . . . . . . . . . . . . . . . . . . 153.2 Identification dans l’IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Profil de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4 Architecture EPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.5 Default et dedicated bearers . . . . . . . . . . . . . . . . . . . . . . . . . . 223.6 VoLTE avec CSFB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.7 VoLTE avec IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.8 SMS avec l’IP-SM-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1 Structure d’un message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2 Exemple de message INVITE . . . . . . . . . . . . . . . . . . . . . . . . . 284.3 Message MSRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.4 Pile de protocole IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.5 Architecture avec IP-SM-GW . . . . . . . . . . . . . . . . . . . . . . . . . 304.6 Enregistrement de l’UE à l’IMS et mise à jour . . . . . . . . . . . . . . . . 324.7 Envoi d’un SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.8 Contenu du message SMS-SUBMIT encapsulé dans une requête SIP MES-
SAGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.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 livraisondes SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1 Architecture JSLEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Les Interfaces Parlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.3 La solution Parlay des fournisseurs de télécommunication . . . . . . . . . . 425.4 La solution Parlay des fournisseurs indépendants . . . . . . . . . . . . . . . 435.5 Architecture de l’OpenIMSCore . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1 Requête REGISTER avec le client IMSDroid . . . . . . . . . . . . . . . . . 496.2 Architecture avec FreeSwitch ESL . . . . . . . . . . . . . . . . . . . . . . . 516.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 innovantssans se soucier du débit en l’occurrence dans le domaine de l’éducation, de la santé etautres.
L’architecture de service basée sur l’IMS que la 4G a hérité de la VoLTE ouvre lavoie 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 lesservices pour les utilisateurs.
Partant de l’exemple du SMS, notre travail fait le point sur le passage des réseaux2G/3G au réseau LTE. Nous étudions ensuite ces architectures et environnements deservices 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 offertespar 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 flownamely in the field of education, health and others.
The service architecture based on IMS as 4G inherited the VoLTE paves the way fordevelopment of these IP Multimedia services. This service architecture revolutionizes howto 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/3Gnetworks 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 andtheir limitations from the perspective of contribution to these new architectures and newenvironments.
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 afind’augmenter les débits des technologies existantes. Ainsi dans sa Release 8 et 9, le débitdescendant de la LTE est de 300 Mbits/s et son débit montant est de 75 Mbits/s [1]. Dansla version LTE-Advanced le débit descendant est de 3000 Mbits/s et le débit montantest de 1500 Mbits/s [1]. Avec ces débits énormes, la LTE initialement prévue pour letéléchargement et le chargement de données suscita chez les opérateurs le besoin de fourniraux utilisateurs d’autres services attractifs avec une qualité de service très élevée à savoirles 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 nousobligent à repenser nos façons de concevoir ces services.
1.2 Contexte
Avec le lancement imminent de VoLTE (Voice over LTE), la transition vers la 4Gré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 formerchange.Quelques unes des préoccupations des chercheurs dans l’enseignement à distance, à savoircomment 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 decollaboration basées sur la messagerie instantanée [4].Le service sms longtemps utilisé comme service à valeur ajouté dans beaucoup de domainesemble é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 desservices 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écomset exposant des API pour les développeurs. Avec cette architecture de service, certainesfonctions 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 architecturea é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/3Get vice-versa.
1.3 Problématique
Les nouvelles architectures de réseau de communication reposent sur une distinctionet une indépendance entre les niveaux transport, contrôle et application, ainsi que sur unré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 endes serveurs d’application AS (Application Server) et serveurs de média IP (IP MS, IPMedia 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 desserveurs d’application ? Quels sont les spécifications qui ont été définies ? Quels seront lesenvironnements 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’ajoutele 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 smsainsi que les spécifications de développement et d’exécution de services dans les réseauxconvergents.La passerelle IP-SM-GW sera étudiée comme cas de transition entre les réseaux tout-IPet 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 lesréseaux 2G/3G sera étudié, le chapitre 3 traitera de la gestion de la voix dans LTE afinde 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 simulationsfaites dans le cadre de l’implémentation du serveur d’application IP-SM-GW et commenteles résultats obtenus. Viendra enfin la conclusion qui récapitulera le travail effectué dansle 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éspour permettre à des lignes fixes ou des téléphones mobiles d’échanger des messages textecourts.
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 (ShortMessage 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éseaufixe,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 physiquementintégré dans la même machine que le MSC (Mobile Switching Center). Un numéro E.164lui 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 lacharge 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 (VisitingMSC) destinataire et de retourner l’erreur appropriée s’il y en a. Il notifiera également leHLR (Home Location Register) du status du message envoyé.
Pour atteindre le SMSC, le réseau mobile doit envoyer le message du VMSC au MSCqui abrite le SMSC. Ce MSC est appelé SMS-IWMSC (SMS-Interworking MSC). Il peutrecevoir 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. Cellesqui interviennent durant les transactions (Mobility Management [MM], Radio Resource[RR], Link Access Protocol sur le canal Dm [LAPDm]) et la couche physique sont aussirepré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 mobileet dans le SME (Short Message Entity). Sa fonction est de générer et d’interpréterles messages ;
— Le SM-TL (Short Message Transfer Layer) : c’est la couche de transport pour l’envoiet la réception de message entre le terminal mobile et le SMSC. Il assure l’encodageet 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 à traversdifférents équipements utilisant le "Store and Forward". Les protocoles définis dansle GSM 2 pour cette couche sont :
— SM-RP (Short Message Relay Protocol) : il est utilisé entre le mobile et leVMSC/VLR. Il gère le référencement et l’adressage ;
— MAP (Mobile Application Protocol) : il est utilisé entre le VMSC/VLR et leSMS-IWMSC ;
5
— Le protocole entre SMS-GMSC/SMS-IWMSC et le SMSC n’est pas défini dansles spécifications GSM.
— CM (Connection Management) : le SM-CP (Short Message Control Protocol) estutilisé entre le mobile et le VMSC/VLR. Il transmet le SM et protège contre lespertes 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 latransmission).
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érentesfaçons de coder et de structurer l’information. Le PDU contient le SCA (Service CenterAddress) et le TPDU (Transfer Protocol Data Unit). Ces six types peuvent être différenciéspar la le champ MTI (Message Type Indicator) [10].
Quand une requête SMS-SUBMIT ou SMS-COMMAND est envoyée, le SMSC répondavec un SMS-SUBMIT-REPORT au SME pour lui notifier qu’il accepte de délivrer lemessage. 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é deré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. Ilcontient la date à laquelle le SMSC a reçu le message. Il peut contenir des paramètresoptionnels comme l’identification du protocole, le schéma de codage, la taille de ladonnée et la donnée elle-même. Il contient aussi le TP-MR (Message Reference), unparamètre qui l’identifie de façon unique ;
— SMS-COMMAND : il est utilisé pour transmettre une commande du mobile auSMSC. Il contient un paramètre qui l’identifie de façon unique, le TP-MR (MessageReference). Ce type de message permet au mobile de demander le statut d’un smsou 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éceptionpositif ou négatif en réponse à un SMS-SUBMIT ou un SMS-COMMAND. Dans lecas 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 à laquellele SMSC a reçu le message (SMS-SUBMIT ou SMS-COMMAND). Celle valeur estunique. 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. Ilcontient une indication sur le fait que le message est une partie d’une concaténationde messages : l’adresse du SME émetteur, l’encodage utilisé, la date à laquelle lemessage a été reçu par le SMSC, la taille de la donnée utilisateur et le message ensoi. Il contient le TP-SCTS ;
— SMS-DELIVER-REPORT : il est émis par le mobile comme un accusé de réceptionpositif 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 estenvoyé au SMSC ;
— SMS-STATUS-REPORT : il est émis par le SMSC pour informer du statut final d’unSMS-SUBMIT et d’un SMS-COMMAND. Il contient le TP-MR et le TP- SCTSpermettant au mobile émetteur de faire le lien entre le SMS-STATUS-REPORT dumessage 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 destinataireaura 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 que134 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écouleque la taille maximale du message concaténé est de 34170 octets (255*134 octets). Si lemessage est compressé, l’algorithme de Huffman est souvent utilisé en GSM. Ainsi cesbits incluent aussi un en-tête de compression CH (Compression Header) et des bits de finde compression à la fin CF (Compression Footer) comme sur la figure 5. Le CH définit letype 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 "UserData". Le UDHL (User Data Header Length) donne le nombre de bit du "User DataHeader".
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 laconcaté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 lesbits IEIDL-2 qui identifient les messages appartenant à la même séquence, un bit quidonne le nombre total de subdivision du sms original (valeur maximale FF), et enfin unbit 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. Lemessage envoyé par l’abonné est encodé par l’entité de transport du mobile en 140 octetsen 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 estappelé RP-DATA (Relay Protocol-DATA). Ce paquet est encapsulé en PDU CP (ControlProtocol 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 leSM-CP et ses couches basses.
9
Figure 2.8 – Message envoyé avec succès par un mobile
Comme décrit sur la figure 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çudu 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, lemobile 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 SMSCva stocker le message jusqu’à ce que le SME soit joignable de nouveau. Cependant lemessage est supprimé après un temps si le SME demeure toujours injoignable. Ce délaipeut être spécifié par le mobile au niveau de la couche transport. En conclusion, le mobilene reçoit que la confirmation concernant la réception du sms par le SMSC. Lorsque leSME 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 ajoutel’adresse du SMSC au PDU. Il interroge ensuite le HLR pour localiser le mobile et envoie lemessage 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 (figure 2.11), le SMSC tente de l’envoyer au SME destina-taire suivant le scénario de la figure 2.10. Cependant si l’abonné n’est pas présent dansle réseau il ne pourra pas répondre au message "Paging" envoyé par le VMSC. Aprèsun certain temps, le VMSC se rend compte que l’abonné n’est pas connecté et envoieun MAP_FORWARD_SHORT_MESSAGE_nack pour en informer le SMS-GMSC. LeSMS-GMSC va donc informer le HLR qui met à jour sa liste de message en attente. Ilinformera 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 notifie le HLR en utilisant unmessage MAP_READY_FOR_SM. Ce dernier envoie un messageMAP_ALERT_SERVICE_CENTRE au SMS-IWMSC qui à son tour alerte le SMSC.Le SMSC procède donc à l’envoi du sms (figure 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 lesservices 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 pouvoiraccéder aux plateformes de services, l’utilisateur doit s’authentifier auprès de l’opérateur.Pour cela le HSS (Home Subscriber Server) assure les fonctions d’authentification, de loca-lisation, de proxy SIP. Les CSCF (Call Session Control Function) contrôle l’ouverture dessessions 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’interconnecteravec des réseaux RTC (Réseau Téléphonique Commuté) ainsi que le MRFC (MultimediaResource 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 couchesfonctionnelles.
— La couche "Access" permet l’interopérabilité entre les différents médias d’accès etl’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’établissementdes appels ;
— La couche "Service" met à disposition, pour la couche application, un ensembled’API implémentant le protocole SIP ;
— La couche "Application" fourni l’ensemble des applications disponibles dans unearchitecture 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 leréseau de l’opérateur, il identifie la souscription de l’utilisateur. Elle concerne plusparticulièrement l’opérateur. Cette identité est importante durant l’authentificationdu terminal car elle est envoyée durant chaque phase d’enregistrement.
— L’identité publique IMPU (IP Multimedia Public Identity) qui permet d’identifierl’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 suitede caractère permettant d’identifier une ressource physique ou abstraite. Il existe deuxtypes d’URI utilisés dans l’IMS :
— Tel URI : il ressemble à un numéro de téléphone. Il peut être soit global (unique defaç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 :[email protected] : sip :[email protected]
Un numéro GSM qui doit être traduit pour un usage en IMS aura la forme : [email protected].
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’usagerconsiste 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 adressetéléphonique ou d’une URI SIP,
16
— zéro ou une instance de la classe Core Network Service Authorization indiquant lesdifférents médias pouvant être utilisés pour les sessions établies avec ces identitéspubliques,
— un ensemble (0 à N) de critères de filtrage (iFC, initial Filter Criteria). Un critère defiltrage 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 ensembled’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 duprofil 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’interfaceCx 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 despoints dans la signalisation SIP sur lesquels des conditions (Filter Criteria) peuvent êtreplacées. Les points de déclenchement suivants sont définis :
— Request-URI : identifie la ressource adressée par la requête (exemple : sip :[email protected])
— 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 enregistrementinitial 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’unheader 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 lecorps 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é. Sila requête SIP vérifie le critère de filtrage, l’entité S-CSCF achemine la requête SIP auserveur d’application correspondant (i.e., AS SIP, IM-SSF, OSA SCS). Une priorité estaffecté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 lesutilisateurs 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/outélécharger les données de l’utilisateur. Les serveurs d’application offrent des API commeOSA/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ébitmaximum descendant instantané (du réseau au terminal) de 100 Mbit/s en considérantune allocation de bande de fréquence de 20 MHz pour le sens descendant et un débitmaximum montant instantané (du terminal au réseau) de 50 Mbit/s en considérant aussiune 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 PacketCore) est le nom du réseau cœur évolué. EPC est un réseau cœur paquet tout IP. Ala différence des réseaux 2G et 3G où l’on distinguait les domaines de commutation decircuit (CS, Circuit Switched) et de commutation de paquet (PS, Packet Switched) dansle réseau cœur, le nouveau réseau ne possède qu’un domaine paquet appelé EPC.Tousles services devront être oferts sur IP y compris ceux qui étaient auparavant offerts parle domaine circuit tels que la voix, la visiophonie, le SMS, ainsi que tous les services deté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 ladifférence de l’UTRAN 3G où sont présentes les entités Node B et RNC, l’architectureE-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. Unenouvelle interface X2 a été définie entre eNodeBs adjacents. Son rôle est de minimiserla perte de paquets lors de la mobilité de l’usager en mode ACTIF (handover). Lorsquel’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érerles paquets entrants vers l’ancien eNodeB tant que le nouvel eNodeB n’a pas informé leréseau qu’il faut lui relayer les paquets entrants pour cet UE. Pendant ce temps l’ancieneNodeB 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 leré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 (incluantpaging), de la sélection du Serving GW et du PDN GW. C’est au MME de sélectionner leServing GW et le PDN GW qui serviront à mettre en œuvre le Default Bearer (le canalde 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 auPDN GW et achemine les paquets entrants à l’usager via le réseau d’accès. Il réalise parailleurs les fonctions d’interception légale et de comptabilité par usager pour la taxationinter-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 externestels 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 fluxde 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éseauxGSM, GPRS, 3G, LTE et IMS. A la différence de la 2G et de la 3G où l’interface vers leHLR est supportée par le protocole MAP (protocole du monde SS7), l’interface S6 s’appuiesur le protocole DIAMETER (protocole du monde IP). Le HSS est une base de données quiest utilisée simultanément par les réseaux 2G, 3G, LTE/SAE et IMS appartenant au mêmeopé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 permettentau PDN-GW de différencier les flux de données de service et de les taxer de façonappropriée. Par exemple, si l’usager fait transiter sur son default bearer des fluxWAP et des flux de streaming, il sera possible au PDN GW de distinguer ces deuxflux et de taxer le flux WAP sur la base du volume alors que le flux de streamingsera 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’usagerdemande l’établissement d’une session IMS, un message SIP sera envoyé au P-CSCFqui dialoguera avec le PCRF pour lui indiquer la QoS requise par l’usager pour cettesession. Le PCRF dialogue alors avec le PDN-GW pour créer le dedicated bearercorrespondant.
3.2.3 Default et Dedicated bearers
Le MME crée pour le compte de l’usager un default bearer au moment du rattachementau réseau. Supposons qu’il s’agisse du default bearer utilisé pour l’accès au PDN (PacketData Network) Internet, alors celui-ci est maintenu tant que l’usager est rattaché auréseau mobile. L’APN correspondante est présent dans le profil de l’usager qui est fournipar le HSS au MME. Si l’usager nécessite d’accéder à un autre PDN (exemple : réseauIP supportant l’IMS), alors son terminal devra établir un default bearer additionnel enutilisant 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 fourniepar le PDN GW au mobile. Si l’usager émet un message SIP sur son default bearer IMSau P-CSCF (call server de l’IMS), ce dernier demande au PCEF du PDN GW via lePCRF de réserver un dedicated bearer. Ce dedicated bearer est caractérisé par une QoScompatible par rapport au trafic à transporter. Le dedicated bearer a une durée de viequi correspond à celle de la session multimédia pour laquelle il a été établi (e.g., sessionde voix sur IP). Un dedicated bearer est toujours associé à un default bearer. Il partagela même adresse IP que le default bearer, mais une QoS qui est différente. Plusieursdedicated bearers peuvent être associés au même default bearer. Le principe de dedicatedbearer s’applique aussi dans le cas de l’accès Internet. En parallèle du default bearerInternet, un dedicated bearer peut être établi, par exemple, pour le transport du fluxSkype (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) (figure3.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 auxré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éseaude 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 lecœur de réseau en commutation de circuit. A partir de ce moment, toute la signalisationpour 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 latechnologie CSFB, il est nécessaire que ce dernier puisse communiquer avec le cœur deréseau en commutation de circuit CS-Core du réseau 2G/3G. En effet, le MME (mobilityManagement Entity) doit pouvoir contacter le MSC (Mobile Switch Center) et la VLRafin de donner procuration au réseau 2G/3G de la gestion de la mobilité. L’interfaceutilisée se nomme SG [14].
Lorsque l’appel est accepté, la technologie CSFB utilise à nouveau l’interface SG pourinformer le réseau LTE de l’acceptation de l’appel. L’acquittement est donc transmis parle réseau en Commutation de Circuit (CS) vers le réseau LTE en empruntant l’interfaceSG.
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éphoniquetransfé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 desession (la communication téléphonique).
Le réseau IMS traite la signalisation téléphonique SIP. Il effectue le routage de lasignalisation téléphonique et fournit les compléments de service téléphonique (comme letransfert 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 desannonces.
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 quiassurent 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 3Gen 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) estune 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 etde la voix.
La fonction SRVCC est en fait un sous-ensemble de la fonction ICS (IMS CentralizedServices) qui définit un contrôle unique de la signalisation téléphonique basé uniquementsur les mécanismes de l’IMS. Elle s’applique aux réseaux de mobiles quel que soit le modePS 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 duLTE. Le protocole utilisé pour connecter un MME à un MSC se nomme SGsAP et celuiutilisé pour le transfert des messages de signalisation est le Stream Control TransmissionProtocol (SCTP) [14].
SMS sur SGS est indépendant du CSFB ; ce qui signifie qu’il ne déclenche pas lechangement d’interface radio vers UTRAN ou GERAN . La gestion du SMS sur SGS estobligatoire pour les UE , MME et MSC qui implémentent la CSFB. Toutefois, les entitésqui 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 estgéré via une entité nommée IP-SM-GW (figure 3.8). L’IP-SM-GW est un AS SIP dansle 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). Afin 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 servicesUSSD, le réseaux IMS (IP Multimedia Subsystem) fut recommandé par la GSMA (GSMAssociation) [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 messagessont 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 typeSIP 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 notification. L’UAC (User Agent Client)envoie le message SIP au proxy qui le transfert au UAS (User Agent Server) qui enverraun 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 sessionavant l’échange de message instantanée (figure 19) entre les utilisateurs. C’est pourquoi aulieu du RTP (Real-time Transport Protocol) un autre protocole nommé MSRP (MessageSession Relay Protocol) est utilisé. MSRP fonctionne avec les protocoles de transport quiassurent 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 fluxmé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 (MobileApplication Part) et LTE-EPC pour l’IMS se fait via la passerelle IP-SM-GW (IP-ShortMessage-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 IMSet le domaine circuit. Il offre la possibilité pour les utilisateurs de s’enregistrer, processusau 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 leMAP ;
— 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 MAPpour 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érifie si les adresses del’é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 traduirele 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 pourchaque 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’estpas disponible. Il doit informer le SMSC lorsque l’utilisateur se connecte afin qu’ilenvoie le message à nouveau ;
— Envoie un message de notification au IP-SM-GW quand l’utilisateur se connecteaprè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 traitementdes 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 Criteriapour l’AS IP-SM-GW inclut une information de service qui contient sous forme debody le MSISDN appartement à “sip :[email protected]”.
— Requête REGISTER (S-CSCF à l’IP-SM-GW). Ce flux de signalisation relaie larequê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 200OK 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èsdu S-CSCF pour être notifié lors du changement d’état de l’usager (i.e., l’UE estdé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êteNOTIFY à l’IP-SM-GW. La notification indique que l’UE est enregistré et que lademande 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 OKau S-CSCF.
— MAP : AnyTimeModification. L’IP-SM-GW émet une requête afin d’informer leHLR/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’usagerdans 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 utilisantune requête SIP MESSAGE. Cette requête sert d’enveloppe SIP pour l’envoi d’unSMS tel qu’il aurait été émis via un accès 2G/3G. Le message SMS-SUBMIT contienttrois informations essentielles (figure 4.8) : Global Title (GT) du SMSC, MSISDNdu 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 usagersqui n’ont pas souscrit au service SMS disposent d’un iFC dans leur profil de serviceafin 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 audestinataire.
— 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 basedes données de souscription. Tout « barring » de SMS est réalisé par l’IP-SM-GWcomme l’aurait réalisé un MSC/VLR ou un SGSN. Si le résultat de l’autorisationest 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 (SCAddress) 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é dansune 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 usagerenregistré dans le monde IMS avec une adresse sip : [email protected] associée à un numérode téléphone tel :+221776814199. Ces 2 IMPUs sont présentées dans le même profil deservice. 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 SMSafin 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 messagecourt sous forme de message SMS-DELIVER, puis l’envoie au S-CSCF qui prenden 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 leS-CSCF à l’IP-SMS-GW
— L ’UE acquitte le message SMS-DELIVER par un message SMS-DELIVER-REPORTencapsulé dans une requête SIP MESSAGE afin d’être délivré à l ’IP-SM-GW viale 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 sanon joignabilité
La figure 4.10 montre un usager se désenregistrant du réseau IMS. L’entité IP-SM-GWinforme le HLR/HSS de cet événement [18].
— Le désenregistrement de l’UE consiste en une requête REGISTER dont le champExpires est positionné à 0.
— Requête NOTIFY (S-CSCF à IP-SM-GW). Le S-CSCF émet une première requêteNOTIFY à 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éponse200 OK au S-CSCF.
— Requête MAP : AnyTimeModification. L’entité IP-SM-GW émet une requête auHLR/HSS afin de l’informer que l’usager avec le MSISDN « +22125555 » n’est plusdisponible pour recevoir des SMS via l’IP-SM-GW.
— Réponse MAP : AnyTimeModification. Le HLR/HSS acquitte la réception de larequête correspondante.
35
Figure 4.10 – L’IP-SM-GW indique au HSS l’indisponibilité de l’IMPU pour la livraisondes 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 unréseau IMS via l’entité IP-SM-GW et justifie aussi le détail que nous avons fourni surla gestion du sms dans le domaine circuit. L’entitité IP-SM-GW est bien une passerelleentre les messages SIP et les messages de type MAP.
36
Chapitre 5
APIs et environnements dedéveloppement des serveursd’application
5.1 Les APIs
Les solutions orientées API désignent les approches qui se focalisent sur la définitiond’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éveloppementdes applications. Dans ce chapitre, sont décrites les architectures qui ciblent les servicesde télécommunications dans les NGN, à savoir, les architectures JAIN (Java APIs forIntegrated 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 aussibien sur les réseaux en mode paquet que sur les réseaux en mode circuit. Conçu pour laplate-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 principede 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 concernela couche protocole, JAIN a normalisé les interfaces permettant l’accès aux protocolesde 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 protocolesprovenant 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 lacouche application. Il faut noter que JAIN définit uniquement les APIs (interfaces) desprotocoles. 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 duNational 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 deservices et sur l’environnement d’exécution (JSCE/SLEE, JAIN Service Creation/ServiceLogic Execution Environment). En effet JAIN définit un modèle d’appel indépendant desprotocoles de signalisation des différents réseaux. L’objectif poursuivi est de masquer lesparticularités des protocoles en offrant aux applications un modèle d’appel uniforme. Lesentité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 procureune abstraction par rapport à ce qui l’entoure. Nous détaillerons son fonctionnement etses principes dans le paragraphe sur l’environnement SLEE. JSCE est un environnementde développement de services fonctionnant dans un SLEE. JSCE permet de créer desmodules de services qui peuvent être assemblés pour former de nouveaux services. JAINdéfinit donc des APIs de bas niveau pour l’abstraction des protocoles et des APIs de hautniveau pour l’abstraction du traitement des appels. Cette architecture présente néanmoinsune 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 standardJava 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 detélécommunications. L’architecture JSLEE définit aussi le contrat entre les composantset leur conteneur à l’exécution. JAIN a une architecture qui lui confère une indépendancevis-à-vis des protocoles de communication d’où sa prise en charge d’un grand nombrede protocoles par ses adaptateurs. Les adaptateurs sont à l’extérieur de l’environnementSLEE. Ils ont une fonction importante qui est la traduction des messages des protocolesen événements consommés par la SLEE. Pour la création de service, JAIN SLEE définit leconcept Service Building Block (SBB) qui est un composant atomique réutilisable et quisouscrit 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 del’application. Un ou plusieurs SBBs forme un service. Les adaptateurs décrits plus hautsont appelés des Resource Adaptors dans la terminologie JSLEE. L’architecture JSLEEest 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 quireposent 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 langagesde 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éristiquesessentielles qui la distinguent de la solution JAIN. Ces caractéristiques sont :
— La fourniture d’interfaces standards et indépendantes de toute technologie et delangage de programmation ;
— L’offre d’un cadre permettant l’accès sécurisé des fournisseurs situés à l’extérieur dudomaine 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 queles 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 ModelingLanguage) 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’applicationcliente, 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 interfacecouvre les fonctions de commande des services. L’application cliente contient la logique duservice global à offrir. Le bloc service offre l’ensemble des capacités que les ressources duré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’interfaceutilisateur est nommée « interface d’application » (Application Interface) ; celle relativeau 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 dela sécurité d’accès, la gestion de l’intégrité, la gestion de la souscription et la découvertedes services. En d’autres termes, le framework assiste les applications dans leur accès etdans 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 permetl’enregistrement par la gestion des capacités nouvellement déployées. Elle offre aussi desfonctions 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’interfaceN°5.Ces deux interfaces autorisent également le déploiement de capacités développées par desparties 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 couvertespar les spécifications PARLAY.Les interfaces N°1 et N°2 sont mises en œuvre par un Parlay Gateway dans les solutionsdes constructeurs. Le Parlay Gateway assure la traduction entre les interfaces Parlay etles protocoles de télécommunication pour utiliser les interfaces offertes par les éléments deréseau. Parmi ces protocoles figurent INAP, CAP, MAP, ISUP, SIP et H.323. Le ParlayGateway est considéré par les constructeurs de télécommunication tels qu’ALCATEL ouERICSSON, 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 ailleursune interface IT aux serveurs d’application contenant les applications Parlay. Parmi lesinterfaces 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). Denouveaux 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 avecles éléments de réseau à travers des protocoles standards. Parmi ces fournisseurs figurentInfitel, 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 avecdes langages de programmation tels que JAVA, C++, HTML, XML, etc. Par ailleurs, leserveur d’application est un client Parlay qui peut invoquer des méthodes publiées par leframework 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 289pour la version 1.1 . La spécification des SIP Servlets définit une approche basée sur lesconteneurs, semblables aux Servlet HTTP, pour développer des applications SIP. UneSIP Servlet est donc un composant d’application JAVA géré par un conteneur de SIPservlet. SIP Servlet ne traite que la signalisation SIP. Le conteneur de Servlet peut êtreune extension d’un serveur d’application qui fournit les services réseau afin de traiter lesrequêtes et réponses SIP.
Le conteneur doit aussi prendre en charge les retransmissions. Contrairement auxServlet HTTP, les SIP Servlet sont asynchrones. Elles s’intègrent parfaitement dans unenvironnement 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 SIPdans des applications J2EE. Par exemple, une application web donnant accès au répertoiretéléphonique des employés et qui leur permet d’initier des appels VoIP depuis l’interfaceWeb. Une SIP Servlet peut prendre en charge les appels VoIP et une HTTP Servlet gèreles interactions au niveau de l’interface web. Comme les servlets HTTP, chaque servletSIP étend une classe javax.servlet.sip.SipServlet de base. Tous les messages arrivent par laméthode service que l’on peut surcharger. Toutefois, en l’absence de mappage un à un desrequêtes aux réponses dans le protocole SIP, la pratique conseillée consiste à développerles méthodes doRequest ou doResponse à la place.Dans ce cas, il est important d’appelerla méthode développée pour terminer le traitement. Chaque méthode de requête devantêtre prise en charge par les spécifications, dispose d’une méthode doxxx comme HTTP.
Dans le protocole HTTP, les méthodes telles que doGet et doPost existent pour lesrequêtes GET et POST. Pour le protocole SIP, les méthodes doInvite, doAck, doOp-tions, doBye, doCancel, doRegister, doSubscribe, doNotify, doMessage, doInfo et doPrackexistent pour chaque méthode de requête SIP.
Contrairement à une servlet HTTP, les servlets SIP disposent de méthodes pour chaquetype 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 deJSLEE est beaucoup plus longue que celle de SIP Servlet.
5.2 Environnements de développement et de créationde services
Un environnement de création de service est généralement une collection d’outils decré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 onpeut développer un service.
5.2.1.1 Mobicents JAIN SLEE
JSLEE Mobicents est la seule implémentation open source de JSLEE certifiée JSLEE1.1 ; elle fait partie de la suite Mobicents Communication Plateform. Mobicents JSLEEest 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 etle contrôle des applications SLEE de manière simple. JSLEE Mobicents offre un ensemblede 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éveloppementd’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 : unepropriétaire et l’autre communautaire à but éducatif. OpenCloud a réalisé un plug-innommé Rhino Visual Service Architect pour l’IDE Eclipse qui sert à développer sanspresque écrire du code source. Ce plugin met à disposition des « boîtes » standard quel’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 plateformesur laquelle on peut développer et déployer des services SIP portables de même que desservices convergents JEE. Il peut être déployé soit sur un serveur d’application JBoss ouun serveur Tomcat. Le conteneur fournit un support pour l’interface Sh par le biais desfonctionnalités qui peuvent être importées depuis le serveur Mobicents Diameter. Cetteinterface permettra de développer des services nécessitant un accès à la base de donnéesHSS. Le serveur Mobicents Diameter fournit les interfaces Cx et Dx ainsi que le CreditControl 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 SailFinsont déployés sur un serveur Java dénommé GlassFish. SailFin fournit un support natifpour SIP et possède une interface Sh pour interagir avec un HSS. En plus, il fournit lesinterfaces 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 transcodagepour 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 communicationMobicents. Elle est diffusée sous une license LGPL 2.1. Il s’agit d’un serveur média opensource développé dans le langage de programmation Java et prend en charge à la fois lesinterfaces IP et traditionnelles TDM. Ainsi, il peut agir comme un serveur multimédiaou une passerelle multimédia. Mobicents Media Server fournit une interface SIP qu’elleutilise pour mettre en œuvre l’interface Mr avec le S-CSCF. Il définit aussi plusieursprotocoles de contrôle d’appel pour contrôler les processeurs multimédia. Au nombre de cesprotocoles, il y a : MGCP, MEGACO, MSCML et la JSR 309. MEGACO est un protocolede l’IETF pour contrôler les serveurs de média et compatible avec H.248. MSCML ouMedia Control Server Markup Language qui est également un protocole IETF définissantun langage de balisage qui peut être utilisé en conjonction avec SIP pour contrôler unserveur 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 lacomplexité de l’appel sous-jacent des protocoles de contrôle pour le développeur. CetteAPI fonctionne uniquement avec les serveurs de médias conformes JSR 309. MobicentsMedia Server prend en charge les codecs audio G.711a, G.711u, GSM, G.729 et speex ; enplus du codec H.261 pour la vidéo. Il possède aussi un moteur Text-To-Speech et prenden 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 pourles services VoIP basés sur le protocole SIP. Il est publié sous une double licence : GPLversion 2 et une licence propriétaire. SEMS n’est pas autonome et nécessite pour sonfonctionnement 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 desservices 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 ajoutentdes fonctionnalités supplémentaires. Une API de base reposant sur C ++ est disponiblepour étendre les capacités du serveur, mais les développeurs peuvent également utiliser uninterpré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 messagerievocale et la conférence. Pour ce faire, SEMS supporte les codecs audio G.711a, G.711uiLBC, 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éalisationde logiciel, englobant les activités de codage logiciel proprement dites (avec notammentun 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. Lemodule Mobicents EclipSLEE facilite la création d’applications conformes aux standardsSLEE. 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 BuldingBlocks, Ressource Adaptors.
5.3 OpenIMSCore
L’OpenIMSCore (figure 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 coeurdes architectures IMS/NGN comme spécifié par le 3GPP, le 3GPP2, l’ETSI TISPAN et lePacketCable intiative. Les outils utilisés dans le développement sont tous des outils opensource (ex. le SIP Express Router (SER) et MySQL).Né du domaine de la Recherche & Developpement, le projet OpenIMSCore, initié parl’institut de recherche allemand FOKUS a pour but de combler le vide dans le mondeopen source de l’IMS. Il a aussi pour but de fournir une implémentation de référence dunoyau IMS pour tester cette technologie et mettre en œuvre des concepts qui entourentl’IMS dans le cadre des travaux de recherche. A travers ce projet, tous les développeurspotentiels 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 , serveurd’enregistrement, serveur de localisation, Serveur de redirection ; distribué sous licenceGPL , 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 etnotification 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 version4 des extensions lui ont été ajoutées afin d’implémenter les serveurs P-CSCF, I-CSCF etS-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é effectués avec les plateformeset environnements existants à savoir OpenImsCore, Mobicents, Eclipse. Les tests consitenten 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 leparamè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 messagesbinaires sont IMSDroid (figure 6.1) un client disponible pour smartphone android et leclient 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 auformat 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écificationdu 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 dansle domaine IMS. Comme pour les autres invocations le mécanisme est basé sur un InitialFilter Criteria, celui-ci étant lié au message SIP REGISTER. De cette façon, l’IP-SM-GWpeut é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 leurtransmettre des messages en attente lorsqu’ils se connectent à nouveau. L’implémentationdu 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 transfertde messages courts, le rapport du status de livraison d’un sms et les messages d’alerteentre le SMS-SC et le HSS, le SMS-GMSC et le IP-SM-GW. Avec cette interface le HSSdoit :
— vérifier si l’utilisateur identifié par le MSISDN est connue ; sinon le HSS doit retour-ner un code ExperimentalResult-Code ayant pour valeurDIAMETER_ERROR_USER_UNKNOWN.
— vérifier si un abonnement SMS MT Téléservice existe ; sinon le HSS doit retournerun code ExperimentalResult-Code ayant pour valeurDIAMETER_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 valeurDIAMETER_SERVICE_ERROR_BARRED.
— vérifier si un ou plusieurs noeuds de service sont enregistrés pour recevoir des SMSMT ; autrement, le HSS doit retourner un code ExperimentalResult-Code ayantpour valeurDIAMETER_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 lesadresses 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 avonsexpé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ôlede FreeSwitch depuis des applications externes. Ces dernières peuvent être écrits danstous les langages et exécutés sur tout système d’exploitation. L’ESL est écrit en C et ades 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 (figure 6.2) qui fait office 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 partd’envoyer le sms à l’utilisateur connecté ou qui vient de se connecter et qui a un messageen 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 serveurd’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 jouele rôle de passerelle sms. Dans le rôle de passelle sms, à chaque fois qu’un message deprésence de type "online" est reçu, l’IP-SM-GW envoie une requête au HSS afin de savoirsi l’abonné qui vient de se connecter n’a aucun message stocké. Si l’abonné en a, il les luienvoie. 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 dedéveloppement et d’exécution de services. Avec l’introduction de l’IMS dans la 4G pourfournir 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/Parlayet les SIP Servlets. A travers l’étude des plateformes disponibles actuellement nous avonspu relever l’existence des environnements comme OpemIMSCore pour l’émulation d’uncœ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 IMSdisponibles actuellement ne supportent pas l’envoie de sms sur IP selon la spécification3GPP TS 24.247 [21], les messages sont donc envoyés en texte clair au lieu du formatRP-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 dansl’architecture du LTE avec un serveur XMPP afin d’exploiter la messagerie instantanéeet la présence de l’abonné pour n’enregistrer les SMS que lorsque ce dernier n’est pas enligne. Cela permettra de ne pas utiliser nécessairement le mode "store and forward" descentres sms pour mieux optimiser le réseau. Nous mènerons d’autres travaux dans le butde développer des simulateurs de centre SMS pour avoir des environnements de tests opensource.
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, Sept2015.
[3] S. O. S. M. F. Landry T. Yelome, Samba. Ndiaye, “Contribution to sms managementover 4g network in distance education context,” IEEE, 2015.
[4] G. M. A. B. M. C. L. N. Samuel OUYA, Kokou GAGLO, “Proposal of a collaborativesoftware development platform for the virtual universities : the virtual university ofthe senegal (uvs) experience,” 2015.
[5] P. M. D. F. M. Y. S. C. L. N. Samuel OUYA, Khalifa SYLLA, “Impact of integratingwebrtc 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 internetconnection context,” 2015.
[7] 3GPP, “Single Radio Voice Call Continuity (SRVCC) ; Stage 2,” TS 23.216, 3rdGeneration 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, 3rdGeneration 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 interworkingwith Open Mobile Alliance (OMA) Converged IP Messaging (CPM),” TS 23.824,3rd Generation Partnership Project (3GPP), 2010. Release 10 V10.0.0.
[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 GenerationPartnership 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 interworkingwith Open Mobile Alliance (OMA) Converged IP Messaging (CPM),” TS 24.247,3rd Generation Partnership Project (3GPP), 2015. Release 13 V13.0.0.
55
Sigles et abréviations
3GPP 3rd Generation Partnership ProjectAS Application ServerCSCF Call Session Control FunctionCSFB Circuit Switched FallBackEMS Enhanced Messaging ServiceeNodeB Evolved Node BEPS Evolved Packet SystemHLR Home Location RegisterHSS Home Subscriber ServerIEI Information Element IdentifieriFC initial Filter CriteriaIMPI IP Multimedia Public IdentityIMPU IMS Public User IdentitiesIMS IP Multimedia SubsystemIP-SM-GW IP Short Message GatewayLTE Long-Term EvolutionMGCF Media Gateway Control FunctionMGW Media GatewayMME Mobility Management EntityMO Mobile OriginatedMRFC Multimedia Resource Function ControllerMSC Mobile Switching CenterMSRP Message Session Relay ProtocolOSA Open Service AccessPCRF Policy & Charging Rules FunctionRP-DATA Relay Protocol-DATARTP Real-time Transport ProtocolSCA Service Center AddressSIP Session Initiation ProtocolSME Short Message EntitySMS Short Message ServiceSMS-GMSC SMS Gateway MSCSMS-IWMSC SMS-Interworking MSCSMSC SMS CenterSPT Service Point TriggersSRVCC Single Radio Voice Call ContinuityUDH User Data HeaderUSSD Unstructured Supplementary Service DataVoLTE Voice over LTE
56