***
E C O L E P O L Y T E C H N I Q U E D’ A B O M E Y - C A L A V I (E P A C)
DEPARTEMENT DE GENIE INFORMATIQUE ET TELECOMMUNICATION
Option : Réseaux Informatiques et Internet
PROJET DE FIN DE FORMATION POUR L’OBTENTION DU
DIPLÔME D’INGENIEUR DE CONCEPTION THEME :
PROPOSITION D’UNE ARCHITECTURE DE TRANSFERT DES MESSAGES COURTS DES RESEAUX
DE TELEPHONIE MOBILE BASEE SUR LES PROTOCOLES SMPP ET HTTP
Réalisé par : DOSSA M. Jean-Boris C.
Sous la supervision de :
Dr. DOSSOU Michel, Maître de mémoire, enseignant à L’EPAC
Lieutenant ALAHASSA Bidossessi, Co-maître de mémoire, enseignant à l’EPAC
Année Académique : 2012-2013 6ième Promotion
SOMMAIRE
SOMMAIRE ... I DEDICACES ... II REMERCIEMENTS ... III LISTE DES TABLEAUX ... VI LISTE DES FIGURES ... VII RESUME ... IX ABSTRACT ... X
INTRODUCTION GENERALE ... 1
1. CONTEXTE, JUSTIFICATION ET PROBLEMATIQUE ... 2
2. OBJECTIFS ... 3
PREMIERE PARTIE : SYNTHESE BIBLIOGRAPHIQUE ... 5
CHAPITRE1.PRESENTATIONDUSMS ... 6
CHAPITRE2.TRANSFERTDESMESSAGESCOURTSENTREDIFFERENTSRESEAUXMOBILES ... 18
DEUXIEME PARTIE : APPROCHE METHODOLOGIUE ...29
CHAPITRE3.MODELISATIOND’UNSERVEURDEDIEALATRANSMISSIONDESMESSAGESCOURTSENTRE DIFFERENTSRESEAUXMOBILES. ... 30
CHAPITRE4.PRESENTATIONDEL’ARCHITECTUREPROPOSEE. ... 41
TROISIEME PARTIE : SIMULATION ET DISCUSSION ...50
CHAPITRE5.ENVIRONNEMENTDESIMULATION ... 51
CHAPITRE6.TESTSETRESULTATS ... 57
CONCLUSION GENERALE ET PERSPECTIVES ...65
REFERENCES BIBLIOGRAPHIQUES ...67
ANNEXES ...70
ANNEXEA:LES PARAMETRES DES TPDU DU PROTOCOLE SMS... 71
ANNEXEB:LES PDU DU PROTOCOLE SMPP ... 76
ANNEXEC:LE PROTOCOLE HTTP ... 80
ANNEXED:LES COMMANDES D’ADMINISTRATION DU SIMULATEUR DU SMS-IWS. ... 84
DEDICACES
Je dédie ce travail :
- A mes parents Théodore DOSSA et Solange ADANDJEHOUNDE.
Trouvez en ce mémoire l’expression de ma gratitude pour tous vos efforts effectués dans le cadre de mon éducation et de ma formation. Vous avez su placer en l’éducation de vos enfants, la plus grande priorité qui soit ! Puisse l’Eternel vous en savoir gré et vous accorde longue vie ;
- A mon frère Leconte DOSSA et ma sœur Sandrine DOSSA. Vos soutiens ont été pour moi source de force et d’espoir;
REMERCIEMENTS
Louanges à toi Seigneur, l’unique DIEU de l’univers, pour ta grâce et ta miséricorde le long de mes études.
Je remercie tous ceux qui de près ou de loin ont contribué à la réalisation de ce travail.
Mes remerciements vont particulièrement à l’endroit de :
- Professeur Félicien AVLESSI, Directeur de l’Ecole Polytechnique d’Abomey-Calavi (EPAC) ;
- Dr. Marc ASSOGBA, Chef du département de génie informatique et télécommunications de l’EPAC ;
- Dr. Michel DOSSOU, mon maître de mémoire, pour avoir accepté de suivre ce travail ;
- Lieutenant Bidossessi ALAHASSA, mon Co-maître de mémoire, pour les apports, les conseils et l’intérêt accordé à ce travail;
- Tous les enseignants de l’EPAC, en particulier Dr. Hyacinthe ABOUDJA, Dr. Léopold DJOGBE, Feu Dr. Sèmiyou ADEDJOUMA pour la qualité de leurs enseignements ;
- Mr. Ben Cheikh HAIDARA, Directeur général de Moov-Bénin, pour m’avoir accordé le stage professionnel de six mois dans le cadre de ce mémoire ;
- Ing. Ghislaine DONTE, ma tutrice de stage, pour ses précieux apports et conseils dans l’élaboration de ce travail ;
- Tous mes amis et promotionnaires de L’EPAC, en particulier Briand, Boris, Edouard, Florentio, Martial, Maxime, Oscar, Razidath, Sédar et Sidikou qui ont été pour moi comme des frères et sœurs durant toute ma formation.
LISTE DES SIGLES ET ABREVIATIONS
B
BSC: Base Station Controller E
ESME: External Short Message Entity
G
GMSC: Gateway Mobile Switching Center
GSM: Global System for Mobile Communication
GSMA: GSM Association H
HLR: Home Location Register HTTP: Hypertext Transfer Protocol I
IWMSC: Interworking Mobile Switching Center
J
JSON: JavaScript Object Notation M
MAP : Mobile Application Part
MCC: Mobile Country Code MNC: Mobile Network Code MSC: Mobile Switching Center MSISDN: Mobile Subscriber ISDN P
PDU: Protocol Data Unit S
SIGTRAN: Signaling Transport over IP
SIM: Subscriber Identity Module SME: Short Message Entity
SMPP: Short Message Peer-to-Peer Protocol.
SMS: Short Message Service
SMSC: Short Message Service Center
SMS-IWS: Short Message Service- Interworking Web Server
SS7: Signaling System 7 SSL: Secured Socket Layer T
TPDU: Transfer Protocol Data Unit V
VLR: Visited Location Register X
XMPP: Extensible Message and Presence Protocol
LISTE DES TABLEAUX
Tableau 1.1 : Principaux protocoles de communication sur l’interface IP d’un SMSC [12] ... 10
Tableau 3.1 : Les principaux paramètres des requêtes Deliver_SM et Submit_SM échangées entre le SMSC et le SMS-IWS ... 35
Tableau 3.2 : Paramètres des objets JSON représentant les messages courts échangés par deux SMS- IWS ... 37
Tableau 3.3 : Usage fait par le SMS-IWS des codes de retour HTTP ... 38
Tableau 3.4 : Exemple de table de routage d’un SMS-IWS ... 39
Tableau 5.1 : Outils utilisés pour concevoir le simulateur du SMS-IWS ... 55
Tableau 6.1 Présentation des machines utilisées pour le test de performance ... 62
Tableau A.1 : Les paramètres des TPDU du protocole SMS [12] ... 72
Tableau B.1 : Récapitulatif des PDU du protocole SMPP [15] ... 77
Tableau D.1 : Les commandes du simulateur du SMS-IWS ... 84
LISTE DES FIGURES
Figure 1.1 : Présentation du SMSC et des nœuds utilisés par le SMS (adapté de [2]) ...9
Figure 1.2 : Illustration d’un SM MO (adapté de [12]) ... 11
Figure 1.3 : Illustration d’un SM MT (adapté de [12]) ... 12
Figure 2.1. Illustration du SMS Peering (adapté de [17]) ... 19
Figure 2.2 : Illustration du SMS Hubbing (adapté de [17]) ... 19
Figure 2.3 : Diagramme de séquence du transfert d’un message court entre différents réseaux défini par la spécification 23.040 (adapté de [1]) ... 21
Figure 2.4 : Diagramme de séquence de transmission d’un message court défini dans le rapport 23.840 (adapté de ... 23
Figure 2.5 : Diagramme de séquence de transmission d’un message court dans un modèle de SMS Hubbing utilisant le protocole MAP ... 25
Figure 2.6 : Diagramme de séquence de transmission d’un message court dans un modèle de SMS Hubbing utilisant le protocole SMPP ... 26
Figure 3.1 : Positionnement du SMS-IWS dans les réseaux mobiles ... 33
Figure 3.2 : Rôles des interfaces du SMS-IWS. ... 34
Figure 3.3 : Exemple d’objet JSON représentant un message court ... 36
Figure 4.1 : Diagramme de séquence du transfert d’un message court dans l’architecture proposée 45 Figure 4.2 : Extrait du diagramme de séquence du transfert d’un message court dans le cas du destinataire en roaming. ... 46
Figure 4.3 : Extrait du diagramme de séquence du transfert d’un message court dans le cas de l’émetteur en roaming. ... 47
Figure 5.1 : Interface graphique de SMPPSIM ... 54
Figure 5.2 : Interface graphique du simulateur de SMSC conçu ... 54
Figure 6.1 : Configuration des machines pour le test de fonctionnalité ... 58
Figure 6.2 : Liste des messages envoyés par le simulateur de SMSC du réseau émetteur ... 59
Figure 6.4 : Capture du trafic réseau lors du test de fonctionnalité ... 60 Figure 6.5 : Fichiers de logs du SMS-IWS du réseau émetteur après le test de fonctionnalité ... 61 Figure 6.6 : Fichiers de logs du SMS-IWS du réseau de destination après le test de fonctionnalité .... 61 Figure 6.7 : Résultats du test de performance ... 63 Figure B.1 : Exemple de communication entre un ESME et un SMSC en mode Transceiver [15] ... 76
RESUME
Les principales architectures d’interconnexion permettant le transfert de messages courts entre différents opérateurs de téléphonie mobile ont été définies par la 3GPP et le GSMA. Leur utilisation entraine pour les opérateurs mobiles plusieurs problèmes dont les plus importants sont le besoin de nombreuses interconnexions directes et la dépendance d’un Hub pour le transfert des messages. Afin de contribuer à la résolution de ces problèmes, nous avons proposé une architecture, basée sur les protocoles HTTP et SMPP.
Cette architecture introduit dans chaque réseau mobile un nouveau nœud appelé SMS-IWS, qui implémente ces deux protocoles, et qui se charge de l’échange de messages courts avec d’autres réseaux mobiles. Les tests effectués ont permis de vérifier que l’architecture que nous proposons est réalisable et permet d’obtenir d’aussi bonnes performances que celles qui existent.
Mots clés : messages courts, opérateurs de téléphonie mobile, architectures d’interconnexion, protocoles, nœud.
ABSTRACT
The main architectures for SMS Interworking have been defined by 3GPP and GSMA. Their usage implies for mobile operators numerous problems, the most important being the need for a great number of direct interconnection or the dependency on a Carrier. To contribute in solving these problems, we have proposed an architecture based on HTTP and SMPP protocols. This architecture introduces in each mobile network a new node called SMS-IWS, which implements these protocols and is responsible for short messages exchange with other mobile networks. The tests performed proved that the architecture we proposed is feasible and provides as good performance as existing ones.
Keywords: short message, mobile network, interconnection architectures, protocols, node.
INTRODUCTION GENERALE
Les réseaux de téléphonie mobile, de par les services qu’ils offrent et leur facilité d’accès, constituent un des moyens de communication les plus utilisés aujourd’hui. Le SMS (Short Message Service1) a largement contribué à l’adoption massive desdits réseaux. En effet, le nombre de messages courts échangés en moyenne par seconde en 2010 à travers le monde est estimé à 200000 [8].
L’acheminement de bout en bout des messages courts a souvent suscité l’intérêt des acteurs du monde de la téléphonie mobile. Initialement conçu comme un service propre à chaque opérateur, le service de messages courts a vite évolué et a nécessité une interopérabilité entre différents réseaux mobiles [7]. Ainsi, pour permettre le transfert des messages entre différents opérateurs, les organismes de normalisation des réseaux mobiles ont défini des architectures à adopter. Ces architectures définissent les différents nœuds2 qui interviennent dans le transfert des messages courts et les protocoles de communication qu’ils utilisent. Toutefois, les principales architectures utilisées aujourd’hui restent sujettes à plusieurs problèmes qui pourraient s’expliquer par les protocoles de communication sur lesquels elles se basent.
Le présent projet d’étude vise donc à concevoir une nouvelle architecture pour le transfert des messages courts entre différents opérateurs, basée sur les protocoles SMPP (Short Message Peer-to-Peer Protocol) et HTTP (HyperText Transfer Protocol). Cette architecture pourrait constituer une alternative à celles existantes, tout en conservant leurs principaux avantages.
1. CONTEXTE, JUSTIFICATION ET PROBLEMATIQUE
Le transfert d’un message court nécessite l’action de plusieurs nœuds des réseaux mobiles et l’usage de protocoles spécifiques de communication entre ces nœuds. Dans le cas où l’émetteur et le destinataire du message ne sont pas du même opérateur, ce transfert nécessite que les nœuds des réseaux concernés communiquent entre eux, et donc que ces réseaux soient interconnectés.
Les principales architectures d’interconnexion pour le transfert des messages courts entre différents opérateurs sont définies par deux grands organismes de normalisation : la 3GPP (3rd Generation Partnership Project) et le GSMA (GSM Association). Les architectures de la 3GPP, bien qu’étant les premières définies ne sont, dans la pratique, presque plus utilisées. Les principales raisons qui expliquent cet état de fait sont le modèle sur lequel se basent ces architectures (modèle de SMS Peering, voir section 2.1), et le fait qu’elles requièrent des opérateurs mobiles l’échange directe de requêtes MAP (Mobile Application Part, voir sections 1.3.2 et 2.2.3). Pour pallier ces difficultés, le GSMA a proposé d’autres architectures basées sur un autre modèle appelé SMS Hubbing. Dans ce modèle, un opérateur tiers généralement appelé Hub ou Carrier interconnecte un grand nombre d’opérateurs mobiles et assure la transmission des messages courts entre ces derniers. Toutefois, bien que les architectures du GSMA règlent les principaux problèmes que posent celles de la 3GPP, leur grande dépendance du Carrier est aussi source de plusieurs problèmes pour les opérateurs mobiles (voir section 2.3.3).
Par ailleurs, la percée récente du réseau Internet a introduit de nouvelles approches pour les services de messagerie en générale. Les services de messagerie instantanée, de plus en plus utilisés, constituent de grands concurrents au SMS. Ces services peuvent en effet supporter d’importants trafics et permettent l’échange de messages dans des délais relativement identiques à ceux du SMS et à des coûts moindres voire inexistants. Un exemple palpable est l’annonce des administrateurs du logiciel de messagerie
WhatsApp, sur leur site web1 en juin 2013, d’un record atteint de 27 milliards de messages échangés en moyenne par jour. Les grandes capacités de ces services de messagerie pourraient s’expliquer par la simplicité des architectures qui les sous-tendent et par le fait qu’ils soient basés sur des protocoles plus adaptés à l’ère d’Internet, et dont l’implémentation est relativement simple et revient peu chère.
Ainsi, il devient possible de repenser les architectures utilisées dans le cadre du SMS, notamment les architectures d’interconnexion pour le transfert de messages entre différents opérateurs. Il serait en particulier intéressant de proposer une architecture pouvant permettre au SMS de bénéficier des progrès faits en termes d’utilisation d’Internet, et se basant sur les protocoles qui permettent le grand succès des services de messagerie instantanée. Une telle architecture pourrait notamment tirer profit du fait que bon nombre de réseaux mobiles sont fournisseurs d’accès Internet et disposent donc de facto d’un canal pour le transfert de messages courts et d’un débit important.
C’est dans ce cadre que s’inscrit le présent projet d’étude. Il vise à utiliser des protocoles pouvant tirer profit de l’évolution d’Internet (SMPP et HTTP), pour proposer une architecture qui règle les problèmes que posent les architectures existantes pour le transfert de messages courts entre différents réseaux mobiles.
2. OBJECTIFS
L’objectif général visé par ce travail est la conception d’une architecture pour le transfert des messages courts entre différents réseaux mobiles utilisant les protocoles SMPP et HTTP. De façon spécifique il s’agira de :
- Présenter et expliquer le service de messages courts (SMS).
- Présenter les architectures existantes pour le transfert des messages courts entre différents opérateurs.
- Proposer une nouvelle architecture se basant sur les protocoles SMPP et HTTP.
- Evaluer les performances de l’architecture proposée.
- Comparer l’architecture proposée avec celles existantes.
- Evaluer les changements pour passer des architectures actuelles à celle proposée.
PREMIERE PARTIE : SYNTHESE BIBLIOGRAPHIQUE
Cette partie vise à présenter d’une part le service de messages courts, et d’autre part les architectures utilisées pour le transfert de messages courts
entre différents opérateurs de téléphonie mobile.
CHAPITRE 1. PRESENTATION DU SMS
1.1. Définition
Le SMS (Short Message Service) est un service basique des réseaux de téléphonie mobile permettant le transfert de messages textes de taille limitée, vers et par des terminaux mobiles [2]. Introduit par la norme GSM1 (Global System for Mobile communications) entre la fin des années 1980 et le début des années 1990, le SMS a largement contribué au succès mondial des réseaux de téléphonie mobile [6]. Ce succès a permis au SMS de se répandre à d’autres familles de réseaux telles que les réseaux IS.412 et les réseaux de téléphonie fixe [7].
Par extension, le terme SMS désigne également le message court qui est échangé par les abonnés des opérateurs mobiles. Il est donc courant de parler d’envoi, de réception, de transfert ou d’échange de SMS. Ce message court peut contenir au maximum 160 caractères. Toutefois, il est possible d’envoyer des messages contenant au-delà de cette taille limite en concaténant plusieurs messages courts (voir section 1.3.1.3).
Le SMS existe également sous une autre variante appelée SMS Broadcast (par opposition au SMS point à point). Ce service permet l’envoi d’un message court d’un émetteur, vers un grand nombre de terminaux mobiles. Il est surtout utilisé par les opérateurs mobiles pour la diffusion d’informations générales. Le présent travail ne s’intéresse toutefois pas à cette variante du SMS.
1- C'est une norme numérique de réseaux mobiles de 2ème génération. Le terme GSM est également souvent utilisé pour désigner une famille de réseaux de téléphonie mobile comprenant notamment le GPRS, l’EDGE etc.
2- IS-41 ou encore ANSI-41: Il s’agit de la norme standard de réseaux utilisée dans les pays nord-américains.
Elle est semblable en certains points à la norme GSM, mais diffère de peu aussi bien dans les nœuds que dans les protocoles utilisés.
1.2. Les concepts relatifs au SMS
Le SMS repose sur un certain nombre de notions et d’entités des réseaux mobiles qu’il importe de comprendre pour le cerner.
1.2.1. Short Message Entity (SME)
Un SME (Short Message Entity) est une entité extérieure au réseau mobile capable d’émettre et de recevoir des messages courts [2]. Les SME sont en général regroupés en deux catégories : les stations mobiles et les ESME (External Short Message Entity).
Les stations mobiles regroupent les équipements tels que les téléphones, les micro-ordinateurs, les équipements électroniques dotés de modems GSM etc. Le terme ESME quant à lui désigne une application externe au réseau mobile qui se connecte au SMSC (Short Message Service Center) pour envoyer et recevoir des messages courts. Ces applications se connectent au SMSC via une connexion TCP/IP ou X.25 et sont le plus souvent utilisées pour les services à valeur ajoutée.
1.2.2. Short Message Service Center (SMSC)
Le SMSC (Short Message Service Center) encore appelé SMS-SC1 est un nœud des réseaux mobiles dédié au SMS. Il assure les fonctions de stockage et de relai des messages courts et peut intervenir dans leur facturation.
Lorsqu’un SME envoie un message, celui-ci est nécessairement transmis à un SMSC. Lorsque l’émetteur du message est une station mobile, il identifie le SMSC grâce à un numéro renseigné dans sa carte SIM (Subscriber Identity Module) appelé adresse de centre de messagerie. Cette adresse est modifiable, mais toutefois, la plupart des opérateurs vérifient à la réception d’un message court si l’émetteur est bien de leur réseau avant de le délivrer [7]. Le SMSC se charge alors de délivrer le message court à son destinataire. Si ce dernier n’est
pas disponible en ce moment, le SMSC stocke le message et réessaie de le délivrer soit avec une fréquence définie, soit lorsque cet abonné est de nouveau disponible, dépendamment des capacités techniques de l’opérateur [10].
Pour assurer ses fonctions, le SMSC communique avec plusieurs nœuds du réseau [2]:
Le MSC (Mobile Switching Center) : C’est un équipement des réseaux mobiles en charge de la commutation de circuit et du routage du trafic (voix, signalisation etc.). Il intervient à divers niveaux dans le transfert d’un message court. En premier, le MSC du réseau émetteur reçoit le message court des équipements de son sous-système radio et le délivre à son SMSC. Egalement, un message court est délivré à son destinataire par le MSC de son réseau.
Le HLR (Home Location Register) : C’est une base de données centrale des réseaux mobiles qui contient les informations de chaque abonné, les services qui lui sont accessibles et des informations relatives à sa localisation. Il permet au SMSC de connaître le MSC de rattachement1 du destinataire d’un message court.
La communication avec ces deux nœuds se fait grâce à deux autres nœuds dont le SMSC peut lui-même dans des cas assurer les fonctions :
Le SMS-IWMSC (SMS-Interworking Mobile Switching Center) : Il s’agit d’un nœud capable de recevoir un message court d’un MSC et de le transférer au SMSC de son réseau de destination [2]. Il est presque toujours intégré au SMSC.
Le SMS-GMSC (SMS-Gateway Mobile Switching Center) : Il s’agit d’un nœud capable de recevoir un message court d’un SMSC, d’interroger un HLR pour récupérer les informations de routage du message, et de le transférer au MSC de rattachement de son destinataire [2]. Dans
1- En général un opérateur mobile possède plusieurs MSC. Toutefois, à un instant donné, un abonné est dans la zone de couverture d’un unique MSC. On parle dans ce cas de MSC de rattachement de l’abonné.
certains réseaux, cette fonction est assurée par le GMSC1 (Gateway Mobile Switching Center) de l’opérateur. Il peut également être intégré au SMSC.
Figure 1.1 : Présentation du SMSC et des nœuds utilisés par le SMS2 (adapté de [2])
Pour communiquer avec un ESME, un SMSC possède généralement une interface IP. Les protocoles de communication sur cette interface les plus répandus sont indiqués dans le tableau 1.1.
1- Le GMSC est un nœud des réseaux mobiles en charge du routage du trafic hors du réseau. Il permet donc aux nœuds d’un réseau de dialoguer avec des nœuds d’un autre réseau.
2- Le BSC (Base Station Controller) présent sur cette figure est un nœud du sous-système radio des réseaux
Tableau 1.1 : Principaux protocoles de communication sur l’interface IP d’un SMSC [12]
Protocole Structure propriétaire/créatrice
Short Message Peer-to-peer Protocol (SMPP)
SMS Forum/LOGICA Universal Computer Protocol (UCP) LogicaCMG
Computer Interface to Message Distribution (CIMD)
Nokia
Open Interface Specification (OIS) Sema Group
1.2.3. Notions de SM MO et de SM MT
Le transfert d’un message court entre deux stations mobiles est constitué de deux étapes. La première étape est celle où le message est transféré de la station mobile émettrice vers le SMSC de son opérateur. Cette étape est désignée par le terme SM MO (Short Message Mobile Originated). De façon plus exacte, un SM MO désigne la capacité d’un réseau mobile à recevoir un message court d’un abonné et à y répondre soit par un accusé de réception, soit par une notification d’échec [2]. Un SM MO lui-même est constitué de deux grandes étapes : une première où le message court est transféré de la station mobile vers le MSC via l’interface radio de l’opérateur, et une seconde où le message est transféré du MSC vers le SMSC. Les échanges entre les différents nœuds lors de la seconde étape utilisent le protocole MAP (Mobile Application Part, voir section 1.3.2). Il est également courant d’utiliser le terme SM MO pour désigner le message court lui-même qui est transféré de la station mobile vers le SMSC. L’élément clé dans le routage d’un SM MO est le numéro du SMSC du réseau émetteur.
IWMSC MSC
BSC SMSC
MAP_MO_Forward_
Short_Message Transfert de la
station mobile vers le MSC via l’interface radio
Transfert du message
Transfert du MSC vers le SMSC 1
2
Figure 1.2 : Illustration d’un SM MO (adapté de [12])
La deuxième étape du transfert d’un message court, que l’on désigne par le terme SM MT (Short Message Mobile Terminated), est celle où le message est transféré du SMSC vers son destinataire. Plus exactement, un SM MT désigne la capacité d’un réseau mobile à délivrer un message court à une station mobile et à obtenir en retour un accusé de réception ou une notification d’échec [2]. Un SM MT est composé de trois grandes parties. Dans la première, le SMSC, via le SMS-GMSC (ou un simple GMSC), obtient du HLR le MSC de rattachement du destinataire du message court. Il transfère ensuite ce message au MSC toujours via le GMSC. Ces deux étapes utilisent également le protocole MAP (voir section 1.3.2). La dernière étape d’un SM MT est celle où le message court est transmis à son destinataire via l’interface radio de l’opérateur de destination L’élément clé permettant le routage d’un SM MT est le numéro du destinataire du message.
MSC SMSC
GMSC
BSC HLR
MAP_MT_Forward Short_Message
Transfert du message
MAP_SEND_
ROUTING_INFO _FOR_SM
Transfert du MSC vers le mobile via l’interface radio Obtention du MSC
de rattachement du destinataire du message court
1
2 Transfert du Message court
au MSC
3
Figure 1.3 : Illustration d’un SM MT (adapté de [12])
Il faut cependant noter que les étapes présentées dans cette section peuvent changer en fonction de l’architecture utilisée. Dans le cas par exemple où l’émetteur et le destinataire du message ne sont pas du même opérateur, certaines architectures font intervenir lors du SM MT les SMSC des deux opérateurs concernés (voire section 2.2.2).
1.3. Les protocoles utilisés par le SMS
Le SMS se base sur différents protocoles qui interviennent à des niveaux bien précis dans la transmission d’un message. Ces protocoles définissent pour certains les commandes utilisées par les SME et le SMSC pour communiquer, et pour d’autres les différentes requêtes que s’échangent les nœuds du réseau pendant la transmission d’un message court.
1.3.1. Le protocole SMS
Les caractéristiques de base du SMS et les moyens qu’utilisent les stations mobiles et le SMSC pour communiquer lors du transfert d’un
message court sont définis dans le protocole SMS. Ce protocole définit entre autres les caractéristiques du message court lui-même (taille maximale, encodage etc.), les commandes que s’échangent la station mobile et le SMSC lors du transfert du message, les supports de transmission utilisés etc.
1.3.1.1. Les TPDU du protocole SMS
Le protocole SMS définit des commandes spéciales appelées TPDU (Transfert Protocol Data Unit) échangées entre un SMSC et un SME pour le transfert des messages courts. Les différents TPDU définis sont [12]:
SUBMIT : cette unité de protocole permet le transfert d’un message du SME d’origine vers le SMSC.
SUBMIT-REPORT : cette unité de protocole est retournée par le SMSC au SME source du message.
DELIVER: cette unité de protocole est utilisée par le SMSC pour délivrer un message à un SME.
DELIVER-REPORT : cette unité de protocole est retournée par le SME au SMSC lorsqu’il reçoit un message.
COMMAND : cette unité de protocole est utilisée par un SME pour interagir avec le SMSC. L’interaction peut consister en l’annulation, la modification d’un message précédemment envoyé etc., dépendamment des paramètres de la requête.
STATUS-REPORT : cette unité de protocole est utilisée par le SMSC pour connaître le statut d’une requête SUBMIT ou COMMAND précédemment envoyée.
Les paramètres de chacune de ces commandes sont présentés dans l’annexe A.
1.3.1.2. Encodage des messages courts
Un message court peut contenir jusqu’à 140 octets de données. Ainsi, le nombre maximal de caractères contenus dépend de l’encodage choisi. Un
L’encodage le plus fréquent est l’alphabet GSM par défaut. Les caractères de cet alphabet sont codés sur 7 bits, permettant ainsi au message de contenir jusqu’à 160 caractères. Un message court peut également être codé sur 8 bits ou utiliser l’encodage UCS21 qui utilise 16 bits pour le codage des caractères.
Cet encodage est nécessaire lorsque le message contient des caractères complexes tels que ceux de la langue chinoise ou arabe. L’encodage utilisé est renseigné dans le paramètre TP-DCS (Transfer Parameter- Data Coding Scheme) du message court (voir Annexe A).
1.3.1.3. Concaténation de messages courts
Bien que l’encodage utilisé limite la contenance en données d’un message court, il est possible de former des messages plus longs en concaténant deux ou plusieurs messages. Un message concaténé est envoyé à travers le réseau comme s’il s’agissait de plusieurs différents messages, et est réassemblé de façon transparente une fois chez son destinataire [10]. Trois paramètres du TPDU initié par la station mobile permettent la reconstitution du message court (voir Annexe A) :
Le paramètre TP-MMS (Transfer Parameter - More Message to Send) indique pour chacun des messages unitaires, hormis le dernier, que d’autres messages courts restent à être transférés.
Le paramètre TP-MN (Transfer Parameter - Message Number) indique la position de chaque message unitaire dans le message concaténé.
Le paramètre TP-MR (Transfer Parameter - Message Reference) indique le numéro de référence du message, et est donc le même pour chacun des messages unitaires.
1- UCS2 : est un encodage de la famille Unicode sur 16 bits très proche de l’encodage UTF-16. Il est utilisé presqu’exclusivement dans le domaine des télécommunications.
1.3.2. Le protocole MAP
Le protocole MAP (Mobile Application Part) est un protocole de la pile SS71 (Signalling System 7), utilisé pour l’échange de signalisation entre les nœuds des réseaux de téléphonie mobile. Dans le cas particulier du SMS, ce protocole permet au SMSC de communiquer avec le MSC et le HLR. La liste des requêtes MAP utilisées dans le cadre du SMS et leur rôle est la suivante [4] :
MAP-SEND-ROUTING-INFO-FOR-SM : Cette requête est utilisée par le SMSC du réseau émetteur pour connaître le MSC de rattachement du destinataire du message.
MAP-MO-FORWARD-SHORT-MESSAGE : Cette requête est utilisée par le MSC pour transférer un message court au SMSC lorsqu’il le reçoit.
MAP-MT-FORWARD-SHORT-MESSAGE : Cette requête est utilisée par le SMSC pour transférer le message court au MSC du réseau de destination.
MAP-REPORT-SM-DELIVERY-STATUS : Cette requête est utilisée par le SMSC pour avertir le HLR de messages en attente d’être délivrés.
MAP-READY-FOR-SM : Cette requête est utilisée par le VLR2 (Visited Location Register) pour informer le HLR que le destinataire du message est de nouveau disponible ou qu’il peut de nouveau recevoir des messages.
MAP-ALERT-SERVICE-CENTRE : Cette requête est utilisée par le HLR pour indiquer au SMSC qu’un abonné est de nouveau joignable.
2- SS7 (Signalling System 7) est un ensemble de protocoles utilisés en téléphonie fixe et en téléphonie mobile.
Les trois premières requêtes mentionnées ci-haut interviennent toujours lors du transfert d’un message court. Quant aux trois dernières, elles sont nécessaires pour les cas où le destinataire du message n’est pas joignable pendant le transfert. Elles permettent donc que le message court lui soit délivré dès qu’il est de nouveau disponible.
1.3.3. Le protocole SMPP
Le protocole SMPP est un protocole libre de transfert de messages courts qui permet à des entités n’appartenant pas au réseau de communiquer avec le SMSC [15]. Il est le plus utilisé parmi les protocoles que peuvent utiliser un ESME pour interagir avec un SMSC, et est implémenté par la quasi-totalité des SMSC [15]. SMPP est un protocole en mode connecté utilisant un réseau TCP/IP ou X.25.
Le protocole SMPP définit un ensemble de commandes que l’ESME et le SMSC utilisent pour échanger des informations. Ces commandes sont appelées PDU (Protocol Data Unit). Les PDU sont regroupés en paires (requête et réponse associée). Ils permettent par exemple à l’ESME d’initier une session de communication avec le SMSC, d’envoyer un message court via le SMSC, de recevoir du SMSC un message court, de supprimer ou de modifier un message précédemment envoyé etc. Certaines de ces commandes ne peuvent être initiées que par le SMSC et d’autres par l’ESME. L’ensemble des PDU et leur rôle est présenté dans l’annexe B.
Une communication par SMPP nécessite la création d’une session entre l’ESME et le SMSC. Généralement la session est créée par l’ESME. Toutefois le SMSC est également en mesure de la créer. La session peut être d’un des trois types suivants :
TRANSMITTER: L’ESME n’est en mesure que d’envoyer des messages courts vers le SMSC. Il ne peut en recevoir.
RECEIVER: L’ESME n’est en mesure que de recevoir des messages courts du SMSC. Il ne peut en envoyer.
TRANSCEIVER: L’ESME peut à la fois transmettre et recevoir des messages du SMSC.
A la fin des échanges l’ESME peut fermer la session et se déconnecter du SMSC. Toutefois, le SMSC peut lui aussi mettre fin à une session SMPP.
Conclusion partielle
Ce chapitre a introduit le concept de SMS en tant que service. Par ailleurs il présente les différents nœuds du réseau qui interviennent dans la transmission des messages courts ainsi que les protocoles de communication utilisés par ces différents nœuds. Le prochain chapitre quant à lui présente les moyens mis en œuvre pour que les messages courts puissent être transmis entre différents réseaux mobiles.
CHAPITRE 2. TRANSFERT DES MESSAGES COURTS ENTRE DIFFERENTS RESEAUX MOBILES
La quasi-totalité des opérateurs mobiles permettent à ce jour à leurs abonnés d’envoyer des messages courts vers les abonnés d’autres opérateurs mobiles [6]. Les principales architectures permettant le transfert de messages courts entre ces opérateurs sont définies dans les documents de deux grands organismes de normalisation : la 3GPP et le GSMA. Ce chapitre présente les architectures définies par ces organismes et expose les problèmes qui leur sont liés.
2.1. Les modèles utilisés pour le transfert de messages entre différents opérateurs
Pour permettre le transfert de messages courts entre leurs abonnés, les opérateurs de téléphonie mobile doivent en premier lieu adopter des modèles d’interconnexion. La notion de modèle d’interconnexion définit le type de connexion que réalisent les opérateurs pour assurer le transfert de messages courts entre leurs abonnés. Il peut donc s’agir d’une connexion directe, d’une connexion par le biais d’un opérateur tiers etc. Le modèle d’interconnexion choisi peut ou non influencer l’architecture de transfert des messages entre différents opérateurs. En effet, certaines architectures ne sont possibles que pour certains modèles.
Deux grands modèles d’interconnexions se distinguent : Le SMS Peering et le SMS Hubbing [16]. Dans le premier modèle, les opérateurs concernés déploient eux-mêmes les infrastructures physiques et logicielles nécessaires pour le transfert de messages courts entre leurs abonnés. Ils gèrent également les aspects juridiques et les éventuels contentieux qui pourraient survenir. Le SMS Hubbing par contre fait intervenir un opérateur tiers souvent appelé SMS Carrier ou SMS Hub. Cet opérateur dispose en général d’un réseau connecté à un grand nombre d’opérateurs, et se charge de délivrer les messages entre
les abonnés de ces opérateurs. Ce dernier modèle est aujourd’hui le plus répandu.
Figure 2.1. Illustration du SMS Peering (adapté de [17])
Figure 2.2 : Illustration du SMS Hubbing (adapté de [17])
Opérateur 1 Opérateur 2
Opérateur 3 Transfert de messages courts
Transfert de messages courts
Transfert de messages courts
Opérateur 1 Opérateur 2
Opérateur 3
Transfert de messages courts Transfert de
messages courts
Transfert de messages courts
SMS Carrier /Hub
2.2. Les architectures définies par la 3GPP pour le transfert des messages courts entre différents opérateurs.
La 3GPP décrit dans ses documents officiels deux architectures d’interconnexion pour le transfert des messages courts entre différents opérateurs. La spécification 23.040, qui décrit de façon générale le transfert des messages courts entre deux stations mobiles, qu’elles soient ou non du même opérateur, propose implicitement une architecture d’interconnexion pour le transfert des messages courts entre différents opérateurs. Le rapport 23.840 quant à lui expose dans un premier temps les problèmes liés à l’architecture définie dans la spécification 23.040 et propose ensuite une architecture qui pallie lesdits problèmes. Il est important de noter que les architectures de la 3GPP impliquent l’adoption systématique du SMS Peering comme modèle d’interconnexion.
2.2.1. L’architecture définie par la spécification 23.040
La spécification 23.040 propose une architecture d’interconnexion unique pour le transfert des messages courts, que l’émetteur et le destinataire du message soient du même opérateur ou pas. La particularité de cette architecture est que le message court est transmis à son destinataire par le SMSC du réseau émetteur, (le message n’est jamais transmis au SMSC du réseau de destination). Dans le cas où le message est correctement transmis, les différentes étapes de cette transmission et les informations échangées par les différents nœuds sont présentées dans la figure 2.3 et peuvent être décrites comme suit:
- Etape 1 : le SMSC du réseau émetteur transfère le message court au GMSC de son réseau pour que celui-ci l’achemine hors du réseau.
- Etapes 2 et 3 : Le GMSC du réseau émetteur envoie au HLR du réseau de destination, la requête MAP_SEND_ROUTING_INFO_
FOR_SM pour connaître le MSC de rattachement du destinataire du message. Le HLR envoie au GMSC en réponse une commande de type
MAP_SEND_ROUTING_INFO_FOR_SM_ack. Cette réponse contient les informations requises par le GMSC.
- Etape 4 : Le GMSC encapsule les informations du message court dans la requête MAP_MT_FORWARD_Short_Message et l’envoie au MSC du réseau de destination.
- Etapes 5, 6 et 7: Le MSC transmet le message à son destinataire et acquitte ensuite la requête du GMSC par la commande MAP_MT_
FORWARD_Short_Message_ack.
- Etape 8 : Le GMSC répond à la requête initiale de transfert de message court du SMSC.
Figure 2.3 : Diagramme de séquence du transfert d’un message court entre différents réseaux défini par la spécification 23.040 (adapté de [1])
SMSC HLR GMSC
MS MSC
Transfert du message
Transfert du message
Acquittement du transfert
Acquittement du transfert Réseau émetteur Réseau de destination
MAP_SRI_FOR_SM
MAP_SRI_FOR_SM_ack
MAP_MT_Forward_Short_Message_ack MAP_MT_Forward_Short_Message
1 2
3
4 5
6
7
8
2.2.2. L’architecture définie par le rapport 23.840
Le rapport 23.840 de la 3GPP propose une alternative à l’architecture proposée dans la spécification 23.040. Dans l’architecture qui y est proposée, la différence majeure réside dans le nœud qui transmet le message court à son destinataire. En effet, le message n’est plus transmis au MSC du réseau de destination par le SMSC du réseau d’origine mais par un nœud du réseau de destination désigné par le terme routeur SMS. Dans la pratique, cette fonction est presque toujours assurée par le SMSC du réseau de destination.
Cette modification dans le transfert des messages courts entre différents réseaux est généralement désignée par le terme SMS Home Routing [6].
Le transfert du message peut se faire en mode transparent ou en mode non transparent. La différence entre ces deux modes se situe dans les instants où le routeur SMS répond à la requête du réseau émetteur. Ainsi, en mode transparent, un retour positif ne sera fait au réseau émetteur que lorsque le message aura été effectivement transmis à son destinataire. Par contre, en mode non transparent, un retour positif sera fait au réseau émetteur dès que le message est transmis au routeur SMS.
Les différentes étapes de la transmission du message court en mode transparent peuvent être décrites comme suit (voir figure 2.3) :
- Etape 1 : Le SMSC du réseau émetteur transfère le message court à son GMSC pour qu’il soit acheminé hors du réseau.
- Etape 2 : Le GMSC du réseau émetteur envoie au HLR du réseau de destination, la requête MAP_SEND_ROUTING_INFO_FOR_SM pour connaître le MSC de rattachement du destinataire du message.
- Etapes 3, 4 et 5 : Le HLR du réseau de destination renvoie la requête précédente au routeur SMS, et ce dernier la lui renvoie à son tour, pour qu’il lui réponde. Ceci permet au routeur SMS de connaître le MSC de rattachement du destinataire du message et donc d’être capable de délivrer le message court.
- Etape 6 : Le routeur SMS envoie au GMSC une commande de type MAP_SEND_ROUTING_INFO_FOR_SM_ack. Il répond ainsi à la requête que ce dernier avait préalablement envoyée au HLR.
- Etape 7: Le GMSC encapsule le message court dans la requête MAP_MT_FORWARD_Short_Message et l’envoie au routeur SMS.
- Etape 8: Le routeur SMS transmet cette dernière requête au MSC de rattachement du destinataire.
- Etape 9: Le MSC délivre le message court à son destinataire.
- Etapes 10,11, 12 et 13: Les différentes requêtes sont acquittées dans l’ordre.
Figure 2.4 : Diagramme de séquence de transmission d’un message court défini dans le rapport 23.840 (adapté de [1])
SMSC GMSC
HLR MS MSC
Transfert du message
Transfert du message
Acquittement du transfert
Acquittement du transfert Réseau émetteur Réseau de destination
MAP_SRI_FOR_SM
MAP_SRI_FOR_SM_ack
MAP_MT_Forward_Short_Message_ack MAP_MT_Forward_Short_Message
1 2
9
Routeur SMS
MAP_SRI_FOR_SM
MAP_SRI_FOR_SM
MAP_SRI_FOR_SM_ack
MAP_MT_Forward_
Short_Message
MAP_MT_Forward_
Short_Message_ack
3
4
5
6
7 8
10 11
12
13
2.2.3. Analyse des architectures de la 3GPP
Bien que la 3GPP soit le principal organisme en charge des spécifications relatives au SMS, et que ses architectures soient les premières à être définies, elles restent dans la pratique très peu utilisées [6]. Plusieurs raisons expliquent cet état de fait. En particulier, l’architecture de la spécification 23.040 pose aux opérateurs de téléphonie mobile plusieurs problèmes relatés dans le rapport 23.840. Un de ces problèmes qui s’est tôt fait sentir est le cas où le destinataire du message est en roaming. En effet, le message ne peut être transmis dans ce cas que si le réseau émetteur et le réseau de roaming ont eux aussi des accords pour le transfert de messages courts. Un autre problème important qui a été soulevé est l’incapacité pour le réseau de destination de filtrer les messages courts qu’il reçoit vu que cette opération n’est aisément faisable qu’au niveau de son SMSC et que le message court n’est jamais transmis à ce dernier.
Deux autres grandes raisons expliquent le fait que les architectures de la 3GPP soient très peu utilisées. La première est le fait que ces architectures se basent sur un modèle de SMS Peering et requièrent donc une interconnexion directe entre les opérateurs mobiles. La deuxième raison qui explique la faible utilisation des architectures de la 3GPP est le fait que la plupart des opérateurs mobiles sont réticents à l’idée de communiquer de façon directe avec d’autres opérateurs au travers de requêtes MAP1 [6].
Cependant, les architectures définies par la 3GPP restent des architectures de base dont se sont inspirées beaucoup d’autres architectures.
2.3. Les architectures définies par le GSMA
En plus des architectures recommandées par la 3GPP pour le transfert de messages courts entre différents opérateurs, d’autres architectures de
1- Cela est surtout dû au fait que le protocole MAP est utilisé pour la signalisation de l’ensemble des services fournis par les opérateurs mobiles (voix, USSD, données). Une mauvaise utilisation de ce protocole pourrait donc avoir de grandes conséquences.
références sont proposées par le GSMA dans la spécification IR.75. Il importe toutefois de noter que les architectures recommandées par cet organisme se focalisent sur le modèle de SMS Hubbing.
2.3.1. Architecture pour le SMS Hubbing utilisant le protocole MAP
Le GSMA définit dans la spécification IR.75 une architecture basée sur le protocole MAP et inspirée de l’architecture définie par la 3GPP dans la spécification 23.040. La différence essentielle que propose le GSMA est l’introduction de deux nœuds (vHLR et vMSC) au niveau du SMS Hub.
Figure 2.5 : Diagramme de séquence de transmission d’un message court dans un modèle de SMS Hubbing utilisant le protocole MAP [5]
Ces nœuds servent d’interfaces entre les nœuds des opérateurs impliqués dans le transfert du message court. Ainsi les nœuds du réseau émetteur ne communiquent plus avec ceux du réseau de destination mais plutôt avec ceux
Réseau émetteur Hub Réseau de destination
vHLR MAP_SRI_FOR_SM
MAP_SRI_FOR_SM MAP_SRI_FOR_SM_ack MAP_SRI_FOR_SM_ack
SMSC
SMSC
HLR
HLR
vMSC MAP_MT_Forward
short_message SMSC
MAP_MT_Forward short_message
MSC
MAP_MT_Forward short_message_ack
MSC MAP_MT_Forward
short_message_ack SMSC
du Hub et vice-versa. Cette modification permet de contourner la réticence des opérateurs mobiles à communiquer entre eux aux travers de requêtes MAP.
2.3.2. Architecture pour le SMS Hubbing utilisant le protocole SMPP
Le GSMA propose également dans la spécification IR.75 une architecture de transfert des messages courts pour le SMS Hubbing qui s’appuie sur l’utilisation du protocole SMPP. Dans cette architecture, Le Hub établit une session SMPP avec plusieurs opérateurs mobiles et peut recevoir ou délivrer des messages à ces opérateurs. Pour transférer le message au Hub, le réseau émetteur utilise la requête SMPP Deliver_SM. Pour transférer à son tour le message court au réseau de destination, le Hub utilise la requête SMPP Submit_SM.
Figure 2.6 : Diagramme de séquence de transmission d’un message court dans un modèle de SMS Hubbing utilisant le protocole SMPP [5]
Il est important de noter comment les opérateurs mobiles sont identifiés dans cette architecture. En effet, pour que l’architecture courante soit possible, les PDU SMPP utilisés (Deliver_SM et Submit_SM) doivent nécessairement contenir deux paramètres qui sont par défaut optionnels : les
Réseau émetteur Hub Réseau de destination
SMSC
SMSC
SMSC
SMSC Deliver_SM
Submit_SM
Submit_SM_Resp
Deliver_SM_Resp
paramètres source_subaddress et dest_subaddress. Ces paramètres doivent respectivement contenir les codes d’identifications1 du réseau émetteur et du réseau de destination du message court. Ceci permet au réseau destination de connaître le réseau émetteur et de faire d’éventuelles vérifications.
2.3.3. Analyse des architectures définies par le GSMA
Les architectures définies par le GSMA sont aujourd’hui les plus récurrentes. En effet, étant conçues pour un modèle de SMS Hubbing, ces architectures permettent aux opérateurs de n’établir qu’une unique connexion avec le Hub et ainsi de délivrer et de recevoir les messages d’un grand nombre d’opérateurs. Cependant, la dépendance des opérateurs mobiles au Hub pour le transfert des messages courts a également beaucoup d’inconvénients. Les principaux problèmes observés sont les suivants :
Les pannes techniques du Hub : Dans le cas où l’opérateur servant de Hub est confronté à une panne, la transmission de messages courts entre tous les réseaux qu’il interconnecte peut être compromise.
Les problèmes de sécurité : Par une intrusion dans le système de l’opérateur servant de Hub, il est possible de récupérer les messages courts d’un grand nombre d’opérateurs.
Aspect financier : Les opérateurs mobiles versent d’important frais aux Hubs pour le transfert des messages courts vers d’autres réseaux [6].
Ces frais sont d’autant plus importants que le GSMA ne propose explicitement pas d’architecture pour le SMS Home Routing. Ceci a conduit beaucoup de fournisseur de Hub à introduire cette fonctionnalité additive, augmentant ainsi les frais à payer par les opérateurs mobiles.
Conclusion partielle
Ce chapitre a présenté les différents modèles d’interconnexion et les différentes architectures de transmission des messages courts entre différents opérateurs mobiles recommandés par les principaux organismes de normalisation. Il permet donc d’appréhender les forces et les faiblesses des solutions existantes. Le prochain chapitre présentera un serveur modélisé pour mieux assurer la transmission de messages courts entre différents opérateurs.
DEUXIEME PARTIE : APPROCHE METHODOLOGIUE
Cette partie vise à présenter de façon concrète l’architecture que nous proposons pour le transfert des messages courts entre différents réseaux de
téléphonie mobile.
CHAPITRE 3. MODELISATION D’UN SERVEUR DEDIE A LA TRANSMISSION DES MESSAGES COURTS ENTRE DIFFERENTS RESEAUX MOBILES.
Les progrès récents faits en matière d’Internet ont fait ressortir la capacité de plusieurs autres protocoles dans le domaine des services de messageries. Des protocoles tels que HTTP et XMPP1 (Extensible Messaging and Presence Protocol) ont permis un fulgurant essor de nouveaux services de messagerie, désormais grands concurrents du SMS [9]. Ceci nous a donc conduits à l’idée de réutiliser un de ces protocoles, notamment le protocole HTTP, et de l’associer au protocole SMPP pour concevoir une nouvelle architecture de transfert des messages courts entre différents opérateurs de téléphonie mobile.
L’architecture que nous proposons repose sur l’introduction d’un nouveau nœud, propre à chaque opérateur et dédié au transfert des messages courts entre réseaux mobiles. Ce chapitre présente les composantes et le fonctionnement interne dudit serveur.
3.1. Description du serveur
Le serveur proposé dans notre architecture pour le transfert des messages courts entre différents opérateurs mobiles, possède des interfaces, des règles de routages et des règles de sécurité bien définies. Cette section propose en premier lieu une désignation dudit serveur, et décrit ensuite son fonctionnement.
3.1.1. Désignation du serveur
Du fait des fonctionnalités qu’il assure d’une part, et du fait qu’il se base sur le protocole HTTP pour assurer l’échange effectif des messages courts
3- Il s’agit d’un ensemble de protocoles dédiés aux services de messagerie instantanée.
d’autre part, nous avons désigné le serveur modélisé dans ce chapitre par le terme SMS-IWS (Short Message Service-Interworking1 Web Server). Cette abréviation sera donc utilisée dans la suite du document pour désigner ledit serveur.
3.1.2. Rôle et principe de fonctionnement du SMS-IWS
Le SMS-IWS est un serveur qui a pour rôle d’assurer le transfert des messages courts entre différents opérateurs de téléphonie mobile. Il est donc nécessaire dans l’architecture que nous proposons qu’il soit présent chez chaque opérateur mobile (voir figure 3.1). Le SMS-IWS d’un opérateur, communique au travers de ces interfaces logiques, d’une part avec le SMSC du réseau auquel il appartient, et d’autre part avec les SMS-IWS d’autres opérateurs. Il intervient aussi bien dans le transfert des messages courts entrants que dans celui des messages courts sortants2. Il possède deux interfaces logiques de communication : une interface SMPP et une interface HTTP. Les fonctions de chacune de ces interfaces sont présentées dans la section 3.2.
3.1.3. Justification des choix faits pour la modélisation du SMS-IWS.
Le choix de concevoir un nouveau serveur pour le transfert de messages courts entre différents opérateurs, et d’utiliser les protocoles SMPP et HTTP pour son fonctionnement est motivé par plusieurs raisons. Les plus importantes peuvent être expliquées comme suit :
- Ne pas modifier le fonctionnement des nœuds existants du réseau : Ce choix avait également été fait par la 3GPP lorsqu’elle introduisait
1- SMS Interworking est un terme générique anglais utilisé pour désigner la capacité de réseaux mobiles différents à échanger des messages courts.
2- Un message court sortant est un message envoyé par un abonné du réseau courant vers un abonné
l’architecture du rapport 23.840 [1]. En effet, du fait du coût très élevé des nœuds des réseaux de téléphonie mobile, il est important en proposant une architecture d’introduire le moins de fonctionnalités que ces derniers ne soient déjà en mesure de réaliser.
Le choix que nous avons fait pour cela est d’utiliser d’une part le protocole SMPP qui est déjà implémenté par la quasi-totalité des SMSC, et de déléguer les nouvelles fonctionnalités inhérentes à notre architecture au SMS-IWS.
- Simplifier la conception du SMS-IWS : Le choix des protocoles SMPP et HTTP confère au SMS-IWS une véritable aisance en terme de conception. En effet, une force de ces deux protocoles est qu’ils disposent de documentations suffisamment riches et accessibles. En outre, SMPP et HTTP étant tous deux basés sur TCP/IP, un ordinateur disposant d’une carte Ethernet1 est suffisant pour concevoir un SMS-IWS.
- Obtenir de bonnes performances : SMPP et HTTP sont des protocoles qui permettent d’obtenir des performances que nous jugeons suffisantes pour le service requis. Aussi, la séparation des deux interfaces permet d’optimiser de plusieurs façons le fonctionnement du SMS-IWS. Un opérateur peut par exemple posséder plusieurs SMS-IWS, séparer les interfaces HTTP et les faire fonctionner en Cluster2 etc.
- Réutiliser la large bande passante des opérateurs de téléphonie mobiles : Etant pour la plupart fournisseur d’accès Internet, les opérateurs mobiles disposent d’une large bande passante et peuvent donc s’en servir pour le fonctionnement du SMS-IWS.
1- Ce n’est par exemple pas le cas des nœuds tels que le MSC, le SMSC ou le HLR qui le plus souvent nécessitent également des cartes TDM (E1 le plus souvent).
2- Mise en commun de plusieurs serveurs exécutant la même tâche dans le but d’en accroître les performances ou la tolérance aux pannes.
Figure 3.1 : Positionnement du SMS-IWS dans les réseaux mobiles
3.2. Les interfaces de communication du SMS-IWS
Chacune des interfaces du SMS-IWS joue un rôle spécifique dans son fonctionnement. De plus ces interfaces communiquent entre elles, et s’échangent des informations aussi bien pour le transfert des messages courts entrants que celui des messages courts sortants (voir figure 3.2).
Figure 3.2 : Rôles des interfaces du SMS-IWS.
3.2.1. Interface SMPP
L’interface SMPP d’un SMS-IWS lui permet de communiquer avec le SMSC de l’opérateur mobile qui le possède. La session établie entre ces deux serveurs est de type TRANSCEIVER.
Pour délivrer un message court dont le destinataire n’est pas de son réseau, le SMSC le transfère au SMS-IWS de son réseau. Ce transfert se fait grâce à une requête SMPP de type Deliver_SM (voir figure 3.2). Cette requête contient plusieurs paramètres dont les plus importants sont renseignés dans
Interface SMPP Interface HTTP
SMPP Deliver_SM
SMPP Submit_SM
SMS-IWS SMSC
Internet Requête
HTTP (POST)
Requête HTTP (POST) message court
sortant
message court entrant
-- Extraction des informations contenues dans la requête:
Deliver_SM (MSISDN des abonnés, MCC et MNC des deux réseaux, encodage etc.
-- Formation d'un objet de format JSON correspondant au message court.
-- Selection de l'adresse HTTP du réseau de destination dans la table de routage.
-- Etablissement d'une session SSL et transfert sécurisé du message court.
-- Réception d'un objet JSON correspondant à un message court.
-- Extraction des informations contenues dans l'objet:
Deliver_SM (MSISDN des abonnés, MCC et MNC des deux réseaux, encodage etc.
-- Formation d'une requête Submit_SM a partir des informations extraites de l'objet JSON reçu.
-- Transfert de la requête Submit_SM formée au SMSC
le tableau 3.1. Dans le cas des messages courts entrants, l’interface SMPP du SMS-IWS exploite les informations reçues sur l’interface HTTP, et forme une requête SMPP de type Submit_SM qu’elle envoie au SMSC (voir figure 3.2). Le tableau 3.1 indique également les paramètres de cette requête.
Tableau 3.1 : Les principaux paramètres des requêtes Deliver_SM et Submit_SM échangées entre le SMSC et le SMS-
IWS
Paramètre de la requête Information contenue Usage de l’information sequence_number Numéro de séquence du
message court.
Permet d’identifier de façon unique ce message
source_addr MSISDN de l’émetteur du message court.
Il s’agit du numéro qui sera affiché comme numéro d’émetteur du message court à sa réception.
destination_addr MSISDN du récepteur du message court.
Il s’agit du numéro du destinataire.
short_message Contenu du message court.
Ce paramètre contient le contenu du message qui sera affiché au destinataire.
source_subadress MCC et MNC de
l’opérateur de l’émetteur du message court.
Permet au réseau de destination de connaître le réseau de provenance du message court.
dest_subadress MCC et MNC de
l’opérateur du récepteur du message court.
Permet au SMS-IWS de router le message vers le bon réseau.
data_coding Encodage du message court.
