Memoire - Conception D'une API Pour L'echange de SMS Basée Sur Le Protocole SMPP 3.4

±ǯ
±
±
±±
°ǣ
±
ǯ
ǯ

͵ǤͶ

̵
̵ǯ

±±ͳ͹±ʹͲͳʹǣ

±

±ǣ ǡÁ±
ǣ ǡ
±ǣ ǡÁ±
ǣ ±±ǡÁ±
ǡ
ǡ

̵ǣ±±

±ǯ
±
±
±±
°ǣ
±
ǯ
ǯ

͵ǤͶ

̵
̵ǯ

±±ͳ͹±ʹͲͳʹǣ

±

±ǣ ǡÁ±
ǣ ǡ
±ǣ ǡÁ±
ǣ ±±ǡÁ±
ǡ
ǡ

̵ǣ±±

Ǽǡǡ
ǯǯǽǤ
(Proverbes 2 : 10)
A nos chers parents,

qui ont toujours cru en chacun d’entre nous et qui ont mis à notre disposition tous les
moyens nécessaires pour que nous réussissons dans nos études.
A nos frères et sœurs,

pour toute leur aide et leur soutien.
Qu'ils trouvent ici l'expression de notre amour fraternel.
A toute notre famille,

Nos sincères remerciements pour leur soutien indéfectible.
C’est grâce à vos prières et vos services que nous avons pu atteindre le but que nous nous
sommes fixé.
A tous nos amis,

Le chemin fut long et rude mais vous étiez toujours là pour nous. Merci infiniment !

4

Les travaux de recherche nécessaires à l’élaboration du présent ouvrage n’auraient

pas été menés à bon terme sans la bienveillance de Dieu qui nous a donné la santé, la
force, et le courage durant leur réalisation.
Tout notre respect à M. RANDRIANARY Philipe, Directeur de l’Ecole Supérieure

Polytechnique d’Antananarivo.
Nous exprimons une vive reconnaissance au Dr RAKOTOMANANA Charles

Rodin, Président du jury.
Vous, qui malgré la pluralité de vos occupations socioprofessionnelles, avez accepté de
consacrer une partie de votre précieux temps au jugement de ce travail.
Nous exprimons également toute notre gratitude aux membres du jury, notamment,
Dr RANARIJAONA Jean Désiré, M. RAMELINA Lala Arimonjy et M.
ANDRIAMANALINA William, qui ont su apprécier ce travail.
La pertinence de vos critiques et suggestions nous a permis de finaliser convenablement
notre mémoire.
C’est avec un grand plaisir que nous adressons nos sincères remerciements à
l’égard de nos encadreurs pédagogique et professionnel : Dr ANDRIAMANOHISOA
Hery Zo et M. RABEKORIANA Rado, qui n’ont ménagé aucun effort pour la bonne
réussite de ce travail.
Nos sincères remerciements à l’endroit des corps enseignant et administratif de

l’ESPA et de la filière Génie Industriel, pour la richesse de votre enseignement.
Nous réservons une pensée au regretté M. RANDRIAMANANTENA Edmond

Nicaise, qui a facilité notre introduction dans la société Orange Madagascar.
Nous tenons également à remercier toute l’équipe d’Orange Madagascar pour leur
accueil.
Nous ne terminerons pas sans avoir exprimé nos remerciements envers toutes les
personnes qui, de près ou de loin, et sous quelle forme que ce soit, ont apporté leur aide
inestimable et qui nous ont permis d’atteindre nos objectifs.

5

INTRODUCTION GENERALE ...................................................................................... 11
CHAPITRE I : CONTEXTE DU PROJET, OBJECTIFS, DEMARCHE ET LIMITES . 13

1.1. CONTEXTE....................................................................................................... 13
1.2. OBJECTIF GENERAL ...................................................................................... 13
1.3. OBJECTIFS SPECIFIQUES ............................................................................. 13
1.4. RESULTAT ATTENDU ................................................................................... 14
1.5. DEMARCHE ..................................................................................................... 14
1.6. LIMITES DES API ETUDIEES ........................................................................ 15
CHAPITRE II : GENERALITES SUR LE RESEAU GSM ET SES COMPOSANTS .. 17
2.1. DEFINITION ET HISTORIQUE ...................................................................... 17
2.2. ARCHITECTURE DU RESEAU GSM ............................................................ 17
2.3. SERVEUR DE MESSAGE COURT (SMSC)................................................... 23
2.4. SERVICE DE MESSAGE COURT SMS (SHORT MESSAGE SERVICE) ... 26
CHAPITRE III : PROTOCOLE SMPP 3.4 ...................................................................... 33
3.1. DEFINITION GENERALE DU PROTOCOLE................................................ 33
3.2. DEFINITION DU PROTOCOLE SMPP 3.4 .................................................... 33
3.3. PDU (PACKET DATA UNIT) .......................................................................... 35
3.4. DESCRIPTION DU PDU .................................................................................. 36
3.5. TYPES DE SESSION POSSIBLE DANS LE PROTOCOLE SMPP ............... 39
CHAPITRE IV : DOMAINE CONCEPTUEL DU PROJET........................................... 48
4.1. APPLICATION PROGRAMMING INTERFACE(API) .................................. 48
4.2. ESME : EXTERNAL SHORT MESSAGE ENTITY........................................ 48
4.3. PASSERELLE SMS .......................................................................................... 48
4.4. METHODE DE REALISATION ...................................................................... 57
4.5. MISE EN ŒUVRE DES TESTS ET ETUDE DE CAS .................................... 58
4.6. MISE EN ŒUVRE DE LA CONCEPTION DE L’API .................................... 68
4.7. DEFINITION DES MODULES POUR L’IMPLEMENTATION DE L’API .. 86
CONCLUSION GENERALE .......................................................................................... 90

6

Figure 1 : Architecture du réseau GSM……………………………………………….. 22

Figure 2 : Les entités participantes à l’acheminement des SMS……………………… 24
Figure 3 : Eléments de base du service SMS…………………………………………. 26
Figure 4: SMS-MO…………………………………………………………………… 28
Figure 5: SMS-MT…………………………………………………………………… 29
Figure 6 : Contexte de SMPP dans le réseau GSM…………………………………... 33
Figure 7 : Exemple typique d’une session bind_transmitter………………………….. 40
Figure 8 : Etat de session open………………………………………………………... 41
Figure 9 : Etat de session TX…………………………………………………………. 41
Figure 10 : Etat de session RX…………………………………………………………. 42
Figure 11 : Etat de session TRX………………………………………………………... 42
Figure 12 : Séquence atypique d’une opération outbind……………………………….. 44
Figure 13 : Architecture TCP/IP………………………………………………………... 46
Figure 14 : Contexte de la passerelle SMS……………………………………………... 48
Figure 15 : Principe de lecture et d’écriture au niveau du socket……………………… 53
Figure 16 : Passage du java.io à java.nio……………………………………………….. 54
Figure 17 : Principe de lecture et d’écriture au niveau du socket en utilisant java.nio… 55
Figure 18 : Illustration de la méthode de réalisation…………………………………… 56
Figure 19 : Aperçu du fichier de configuration de Kannel pour fakeSMSC…………… 60
Figure 20 : Résultat du test de connexion avec fakeSMSC……………………………. 62
Figure 21 : Fichier de configuration de Kannel avec logica…………………………… 64
Figure 22 : Résultat du test de connexion avec fakeSMSC connecté à logica………… 66
Figure 23 : Diagramme hiérarchique des classes de la construction des dates………… 68
Figure 24 : Diagramme hiérarchique des différentes versions…………………………. 69
Figure 25 : Diagramme d’interaction des classes PDU, PDUHeader, PDUBody……… 74
Figure 26 : Diagramme hiérarchique des classes héritant de PDUBody.………………. 75
Figure 27 : Diagramme hiérarchique des classes héritant de PDUHeader……………... 75
Figure 28 : Diagramme de classes des différentes sessions……………………………. 81
Figure 29 : Illustration d’un paquet de PDU bind receiver…………………………….. 82
Figure 30 : Illustration d’un paquet de PDU unbind créée par une tâche……………… 83
Figure 31 : Représentation d’un paquet PDU à envoyer lors d’une session outbound… 84
Figure 32 : Illustration des participants………………………………………………… 85
Figure 33 : Illustration du diagramme de séquence……………………………………. 88
7

Tableau 1: Liste d’exemples de PDU…………………………………………………. 34

Tableau 2 : Format général du PDU…………………………………………………… 35
Tableau 3 : Caractéristiques des différents PDU………………………………………. 70
Tableau 4 : Liste des différentes sessions et leurs caractéristiques…………………….. 79
8

API: Application Programming interface
BSC: Base station controller
BTS: Base transceiver station
DOD: Department of Defense
DNS: Domain Name Service
DARPA: Defense Advanced Research Project Agency
EMI: External Machine Interface
ESME: External Short Message Entity
FTP: File transport Protocol
GMSC: Gateway Mobile Switching Center
GSM: Global Standard For Mobile
HLR: Home Location Register
HTTP: Hyper Text Transfer Protocol
IMSI: International Mobile Subscriber Identity
IP: Internet Protocol
IWMSC: Interworking Mobile Switching Center
LAN: Local Area Network
MMS: Multimedia Messaging Service
MSISDN: Mobile Station ISDN Number
MSC: Mobile Switching Center
NSS: Network Sub System
OAM: Opération d'Administration et de Maintenance
OIS: Open Interface Specification
OMC: Operation and maintenance Center
OSI: Open System Interconnection
9
OSS: Operation Sub System
OTA: Over The Air
PDU: Protocol Data Unit
PIN: Personal Identification Number
RSS: Radio Sub System
SIM: Subscriber Identity Module
SMS: Short Message Service
SMPP: Short Message Peer to Peer
SMSC: Short Message Service Center
SMTP: Simple Mail Transfer Protocol
TCP: Transmission Control Protocol
TCP/IP: Transfer Control Protocol/Internet Protocol
UDP : User Datagramme Protocol
VLR : Visitor Location Register
10

A l’heure actuelle, la technologie de la téléphonie mobile a connu une rapide

évolution par rapport au développement remarquable du domaine de la technologie de la
télécommunication et de l’information. Avec ces progrès, il y a un fort rapprochement
entre l’informatique et la technologie de la télécommunication.
Pareillement, le type de service basé sur le message court (SMS) connait

récemment un très grand développement qu’il intéresse aujourd’hui les grandes sociétés,
divers organismes et les opérateurs mobile eux même. Les échanges de service, tels que
le service d’alerte utilisé par la banque pour informer ses clients de l’état de leur compte,
les publicités envoyées par les sociétés pour fidéliser la clientèle, les quiz téléphonique et
divers jeux par SMS, peuvent désormais se réaliser à distance grâce au système de
message court. Diverses applications tels que le système de facturation, la gestion de
l’abonnement, ont également pris une place très importante dans le monde actuel de
l’informatique et de la télécommunication.
Vu l’augmentation des besoins des utilisateurs du service SMS et l’évolution du

développement d’application à base de message court dans le domaine industriel comme
dans le domaine commercial, l’opérateur téléphonique mobile veut actuellement
améliorer leurs offres tout en minimisant les dépenses ; c’est-à-dire, offrir aux utilisateurs
de nouvelles offres sans avoir à augmenter le coût des services.
La connexion aux différentes plateformes du service citées ci-dessus est devenue

possible grâce à l’existence de plusieurs protocoles, notamment les protocoles de pile
SS7, le protocole TCP/IP et le protocole SMPP pour l’envoi de SMS.
Dans cette optique, ce travail de fin d’études se base sur la création d’une API pour
permettre à des applications ou entités externes au réseau mobile d’échanger des
messages courts, en implémentant le protocole SMPP.
L’élaboration de cette API va ainsi permettre le développement de différentes
applications pour l’envoi et la réception d’un SMS en utilisant la nouvelle bibliothèque
11
java.nio. Cette dernière est intéressante dans la mesure où elle offre des méthodes
beaucoup plus efficace et rapide par rapport à l’ancienne entrée/sortie java.io.
Le défi est de produire un outil fiable pour la création de ce type d’application étant
donné que très peu, voire aucune publication n’aborde à ce jour ce sujet.
Ce qui amène à l’élaboration du présent travail qui sera présentée en trois (04)
grands chapitres :
• Le premier chapitre mettra en exergue le contexte, les objectifs et les problèmes

relatifs à la réalisation du projet ;
• Le deuxième sera consacré aux généralités sur le réseau GSM avec un aperçu de
l’historique du service de message court ;
• Le troisième sera basé sur l’étude approfondie protocole SMPP ;
• Le quatrième et dernier chapitre se portera sur le domaine conceptuel du projet.
12
ǣ ǡ ǡ

ͳǤͳǤ
En vue de la préparation du mémoire de fin d’étude dans la filière Génie Industriel,

nous avons effectué un stage au sein de la société Orange Madagascar. Le stage a duré
trois (03) mois et a été orienté autour de la « Création d’une API pour l’échange de SMS
basé sur le protocole SMPP 3.4 ».
Des études et des analyses des différentes techniques d’envoi de SMS qui suit la
spécification définie par le protocole SMPP ont été ainsi effectuées. Ces études se sont
surtout focalisées sur les techniques de mise en œuvre du projet auxquelles l’utilisation
nécessite moins de financement, tout en considérant toutefois la facilité de réutilisation.
ͳǤʹǤ

Le projet étudié consiste à créer une API basée sur le protocole SMPP. L’API est
un outil qui va permettre au programmeur de créer des applications basées sur l’échange
de SMS. L’application sera capable de communiquer avec des serveurs de message court
(SMSC) : d’envoyer et de recevoir des SMS selon leur choix.
En outre, ce projet va permettre au développeur voulant programmer des

applications d’échange de SMS implémentant le protocole SMPP, d’élaborer des
serveurs ou des passerelles SMS (SMSGateway) plus puissant et qui gère beaucoup plus
de connexion avec plusieurs clients sans utiliser un espace mémoire important.
ͳǤ͵Ǥ
Les objectifs spécifiques du présent travail sont basés sur les points suivants :
• Création de tous les PDU qui fera l’objet de base de l’échange lors d’une
session SMPP décrit dans le protocole SMPP 3.4 ;
13
• Conception et programmation des modules pour assurer la transmission de ces
PDU à travers le réseau tout en considérant la connexion physique TCP/IP ;
• Création et programmation du module gérant l’évènement qui pourra se

produira lors d’une session SMPP, que ce soit au niveau du serveur
(SMSgateway) ou au niveau des applications (ESME) ;
• Gestion des files d’attente et de l’échange dans le cas d’une connexion

multiple client (connexion Synchrone ou Asynchrone) ;
• Création d’une application pour envoi et réception de SMS et aussi d’un

simple SMSgateway qui va se servir d’un SMSC pour le test.
ͳǤͶǤ
Le principal résultat attendu à l’issue de ce projet est de pouvoir mettre à jour

l’implémentation du protocole SMPP dans l’API, que ce soit au niveau des entrée/sortie
ou au niveau de la connexion réseau.
ͳǤͷǤ
Les étapes suivies pour la réalisation de ce travail ont été les suivantes :
• Etape 1 : Imprégnation de la base de télécommunications

Cette étape est consacrée à l’étude des bases de la télécommunication, en
particulier du réseau GSM et du service SMS.
• Etape 2 : Etude approfondie du protocole SMPP
Le but est de comprendre la spécification dictée par le protocole SMPP
(version 3.4) et les points de sécurité à considérer lors de l’implémentation sur
réseau Internet.
• Etape 3 : Etude et test de quelques exemples de simulateur de SMSC et de

passerelle SMS.
14
Cette partie a pour but d’étudier de près quelques exemples de simulateurs,
notamment Kannel, SmscLogica, SmppSim, OpenSmpp, pour mieux
comprendre le fonctionnement de l’envoi d’un SMS par l’intermédiaire d’une
passerelle SMS.
Il est toutefois important de noter que l’étude s’est plus focalisée sur Kannel et
SMSClogica qui sont les produits utilisés par la société Orange Madagascar.
• Etape 4 : Elaboration de l’API proprement dite.
ͳǤ͸Ǥ
• De nos jours, il existe plusieurs technologies et protocole permettant d’envoyer

et de recevoir des messages courts à partir d’une application. Pour que cela soit
possible, il est nécessaire de se connecter à un serveur de message court
(SMSC) d’un opérateur mobile.
Mais pour ce faire, il faut obligatoirement passer par une passerelle SMS, du
type Kannel, passerelle utilisée par la société ORANGE Madagascar. Kannel
permet de router les messages reçus par le SMSC vers un ou plusieurs
destinataires.
L’utilisation de Kannel a, en effet, posé quelques problèmes au niveau du
traitement des flux de communication et de la connectivité avec le serveur http.
Lorsqu’elle est hors service, il y a des risques de pertes de requêtes ou de flux
de données, notamment lors de multiples envois utilisant la passerelle ;
• Le routage des messages doit toujours passer par un nœud de Kannel. Ainsi,
pour pouvoir effectuer plusieurs envois, il est toujours nécessaire d’avoir à
disposition plusieurs nœuds, même si cela pourrait avoir des répercussions sur
la rapidité et la fiabilité du service ;
• Le cadre du projet se limite sur l’élaboration et le développement de l’API et la

programmation d’un prototype qui sert d’interface sécurisée pour l’échange de
SMS à travers le réseau internet.
15

Bref, l’objectif de ce travail est de trouver une solution afin de pallier aux différents
problèmes suscités ; de gérer le Queuing et de diminuer les nœuds ; et si possible, éviter
d’utiliser Kannel afin de mieux gérer le flux de communication.
16
ǣ

Un travail de recherche a été effectué avant la construction de l’API pour

l’échange de SMS via Internet suite à la constatation des problèmes de transmission et de
saturation qui seront présentés dans ce qui suit.
ʹǤͳǤ
Défini comme un système global pour la communication mobile ou General

System for Mobile (GSM) en anglais, le GSM est un standard européen qui fixe les
options techniques pour la communication mobile. Cette norme est devenue la référence
mondiale pour le système radio mobile depuis son adoption en Europe et dans nombreux
pays par le Groupe Spécial Mobile (GSM) en 1987.
Le GSM possède une meilleure ressource grâce à ses trois bandes de fréquence 900
MHz, 1800 MHz pour la norme européenne et 1900 MHz pour la norme américaine et
canadienne. Grâce à l’évolution de la technologie, de nos jours, le GSM autorise la
transmission des données numériques de faible volume comme le SMS et des messages
multimédias MMS.
ʹǤʹǤ

L’accès aux réseaux GSM demande la mise en place de plusieurs éléments

techniques de base dont l’architecture est divisée en trois sous-systèmes : le sous-système
radio, le sous-système réseau et le sous-système opérationnel ou d’exploitation.
• Le sous-système radio (RSS) assure les transmissions et gère la ressource

radio. Il est essentiellement composé par des antennes BTS et contrôleurs
d’antennes BSC.
• Le sous-système réseau (NSS) est essentiellement constitué de centre de

commutation mobile(MSC), d’enregistreur, de localisation des visiteurs (VLR)
17
et d’enregistreur de localisation nominal (HLR). Ce système comprend
l'ensemble des fonctions nécessaires à l'établissement des appels et à la
mobilité.
• Le sous-système d'exploitation (Operation Sub System permet l’administration

et la maintenance du réseau à savoir l’équipement principal appelé OMC ou
Operation and Maintenance Center.
ʹǤʹǤͳǤ Ǧ°
Le sous-système radio a pour fonction de gérer la transmission radio à l’aide des

éléments constituants suivants :
• Le MS : la station mobile
• Le BTS : la station de base
• Le BSC : le contrôleur de station de base
Ǥ ȋȌ
Le premier élément du réseau est le téléphone, c’est-à-dire le poste téléphonique

mobile de l’abonné appelé également Mobile Station (MS) dans le vocabulaire GSM.
Dans ce cas, le MS est capable d’envoyer et de recevoir des SMS. Le téléphone et la
carte SIM sont les éléments auxquels un utilisateur a directement accès. Ces deux
éléments suffisent à réaliser l'ensemble des fonctionnalités nécessaires à la
communication et à la gestion des déplacements. La principale fonction de la carte SIM
est de contenir et de gérer une série d'informations. Elle se comporte donc comme une
mini-base de données.
L'identification d'un mobile s'effectue exclusivement au moyen de la carte SIM.

En effet, elle contient des données spécifiques comme le code PIN et d'autres
caractéristiques de l'abonné, de l'environnement radio et de l'environnement de
l'utilisateur.
18
L'identification d'un utilisateur est réalisée par un numéro unique IMSI différent du
numéro de téléphone connu de l'utilisateur MSISDN, tous deux étant incrustés dans la
carte SIM.
Ǥ
Le système de radiotéléphonie mobile GSM utilise les ondes radio électriques pour
assurer la liaison entre le terminal et le réseau téléphonique. Cette liaison radio doit être
de bonne qualité, ce qui demande la mise en place d’un ensemble de station de base
(BTS). C’est l’équipement central d’un site GSM. Elle assure la transmission radio, gère
la modulation et la démodulation ; et effectue le codage et correction d’erreur. Le BTS
implémente l’interface de communication air avec tous les MS activés sous l’espace de
couverture. Il est formé par un ensemble d’émetteurs récepteurs câblés entre eux et qui
est connecté aux antennes. En d’autre terme, c'est la station de base qui fait le relais entre
le mobile et le sous-système réseau.
Comme le multiplexage temporel est limité à huit intervalles de temps, une station
de base peut gérer tout au plus huit connexions simultanées par cellule. Elle réalise les
fonctions de la couche physique et de la couche liaison de données. Dans le langage
commun, cet ensemble est aussi appelée TRx/TRe.
Ǥ Ø

Le contrôleur de station de base est l’organe qui gère la communication à une ou

plusieurs stations de base. Il fournit un ensemble de fonctions pour gérer la connexion du
BTS sous son contrôle.
Son premier rôle est de gérer les ressources radio. Lors d’une connexion, il réalise
une première concentration de circuit vers le MSC.
Dans ce cas, il se comporte comme un concentrateur de circuit qui commute et
transfert les données tout en prenant compte des mesures effectuées par les BTS afin de
pouvoir réguler la puissance du mobile et celle de la station de base.
19
Le BTS décide de l’exécution du Handover, c’est-à-dire des transferts
intercellulaires et transmet les informations sur la nouvelle localisation de l’abonné au
registre de location des visiteurs ou VLR. En effet, le contrôleur de station de base est
l’organe intelligent du sous-système radio.
ʹǤʹǤʹǤ Ǧ°±
Si le sous-système radio gère l’accès radio, le sous-système réseau (NSS) a pour

fonction de contrôler et d’analyser les informations contenues dans des bases de données
qui sont nécessaires à l’établissement de connexion en utilisant diverses fonctions
comme le chiffrement, l’authentification ou roaming.
Les éléments constitutifs du sous-système réseau sont :
• Le MSC ou centre de commutation mobile ;

• Le HLR ou enregistreur de localisation nominal ;
• Le AUC ou centre d’authentification.
Ǥ

Dans le réseau GSM, il peut y avoir un ou plusieurs MSC qui couvre une certaine
zone géographique et de base de données techniques. Son rôle est de vérifier les
autorisations de chaque demande et de savoir où il doit-être envoyé avant de les déléguer
au SMSC dans le cas d’un envoi de SMS par exemple.
Il est également responsable de l'acheminement des communications dans le réseau

et assure l'interconnexion entre le réseau de téléphone cellulaire et le réseau fixe
traditionnel.
Le MSC génère toutes les informations de taxation et gère la complexité des
connexions due aux déplacements réalisés pendant la communication.
20
En effet, le MSC opère les mises à jour des différentes bases de l’enregistreur de
localisation des visiteurs (VLR), de l’enregistreur de localisation nominale (HLR) ;
alloue les fréquences et registre la localisation des abonnés visiteurs.
En général, les centres de commutation mobile servant de passerelle GMSC sont

placés aux périphéries du réseau de l’opérateur facilitant ainsi une interconnexion entre
réseaux d’opérateurs.
Ǥ ǯȋȌ
L’enregistreur de localisation Nominal ou Home Location Register représente la

liste des services et appels autorisés pour chaque utilisateur. Il contient une base de
données très importante pour la téléphonie mobile. Cette base renferme toutes les
informations relatives aux abonnés : le type d'abonnement, la clé d'authentification, les
services souscrits, le numéro de l'abonné, etc. Il contient des données dynamiques telles
que la position de l’abonné et l’état de son terminal, qu’il soit éteint, allumé, en
communication ou libre).
Dans un réseau GSM, il existe au moins un HLR qui dispose d’un accès rapide
pour garantir un temps de connexion aussi court que possible.
Ǥ ǯȋȌ
Le centre d’authentification Authentification Center gère les clés et le chiffrement

des communications. Lorsqu'un abonné passe une communication, l'opérateur doit
s'assurer qu'il ne s'agit pas d'un usurpateur.
C’est le centre d'authentification qui remplit cette fonction de protection des

communications. En principe, on peut distinguer trois niveaux de protection :
1. La carte SIM qui interdit l’accès au réseau à une utilisation non enregistrée ;
2. Le chiffrement de la communication qui empêche l’écoute de celle-ci ;
3. La protection de l’identité de l’abonné.
21
Ǥ ǯ
L’enregistreur de localisation des visiteurs (VLR) est une base de données

dynamique qui ne contient que les informations qui lui sont transmises par le HLR. Ces
données contiennent les informations de localisation de chaque utilisateur qui seront
transmises à une autre VLR quand l’abonné se déplace dans une autre zone de
couverture. Il s’agit donc de vérifier les caractéristiques d’un abonné, de transférer les
informations sur sa localisation dans le réseau au cours d’une communication dans la
zone de couverture du centre de communication mobile auquel il est rattaché.
Ǥ ǯ ± ±

ȋȌ
L'enregistreur d'identification d'équipement EIR permet d'interdire l'accès au réseau

GSM à des terminaux non autorisés, il constitue une base de données des terminaux.
ʹǤʹǤ͵Ǥ Ǧ°ǯ
Le sous-système d’exploitation OSS est le sous-système entièrement dédié à la

gestion de la sécurité et à la maintenance du réseau, ainsi qu’à toutes les différentes
opérations d’administration commerciale.
L’OSS comprend le OMC qui est le principal centre de maintenance et

d’administration du réseau.
22
hŵ
ďŝƐ
Figure 1 : Architecture du réseau GSM
Légende :
¾ Interface Um : interface air ou radio utilisée pour le transport du trafic et

des données de signalisation entre le Station Mobile(MS) et le BTS.
¾ Interface Abis : interface entre le BTS et le MSC pour le transport de
données de signalisation et le trafic.
¾ Interface A : canal de communication entre le sous-système radio et le
sous-système réseau, il se situe entre le BSC et MSC
ʹǤ͵Ǥ
ȋȌ
Le service SMS requiert une plateforme appelée SMSC qui est connecté à un
Switch par le biais du protocole SS7. Le SMSC est un serveur qui utilise le protocole
GSM pour communiquer avec les MSC et les HLR dans le réseau mobile. Son
identification dans le réseau se fait par le numéro de téléphone afin que le MSC puisse lui
transmettre le message à envoyer.
23
En effet, le SMSC est une partie du réseau de télécommunication GSM qui permet
la gestion de transfert de message court SMS. il permet également à des entités
extérieures ESME de s’y intégrer via Internet. Autrement dit, c’est une plateforme
d’enregistrement et de transfert de message court qui assure le stockage et le trafic des
SMS sur le réseau GSM. Le SMSC définit la date de validité des messages courts dans
une base de données qui peut être de type MySQL, Informix ou autre.
En réalité, quand un SMS est envoyé par un abonné vers un autre, le téléphone
transmet d’abord le message vers le SMSC qui se charge de le stocker, puis de le délivrer
quand le terminal de destination est présent sur le réseau. Dans ce cas, le SMSC
fonctionne en mode store and forward.
Pour certains cas, comme dans l’application OTA, le SMSC joue le rôle d’une
passerelle de communication entre le réseau IP et le réseau mobile. Afin de pouvoir
envoyer des SMS vers des numéros de destination MSISDN, un serveur peut accéder au
SMSC grâce à une connexion internet TCP.
Le SMSC possède une variété de protocole permettant aux entités non mobile
d’envoyer des messages aux entités mobiles : le protocole SMTP et le protocole HTTP
pour, respectivement, l’échange de courrier électronique et l’Internet ; le protocole
SMPP, EMI SEMA ou OIS pour les applications externes de message cours ESME. Ces
protocoles utilisent le protocole TCP/IP ou X25 comme porteur.
Le SMSC peut donc être relié à des passerelles d’accès parmi lesquelles celles des
éditeurs de services ESME et les systèmes d’opération, maintenance et d’administration
qui sont définis ci-après.
• Les passerelles d'accès au système d’éditeur de service ESME qui permet aux
entités extérieures non mobiles de se connecter avec le SMSC ;
• Le système de facturation qui aide l'opérateur à charger les comptes de ses

abonnés pour l'utilisation de ses services ;
24
• Les systèmes d'OAM qui aident les opérateurs à lancer et à configurer le
SMSC en service dans un réseau ;
• Le système prépayé.
A noter que les interfaces ESME sont des applications externes non mobiles
qui peuvent se connecter avec le SMSC.
En principe, il existe au moins un SMSC par réseau GSM. Ce serveur est un

équipement comportant deux interfaces :
• Une interface réseau qui est la partie matérielle et la seconde interface qui est
la partie logicielle de l’équipement ;
• La partie logicielle est constituée d’un système d’exploitation ou

environnement. Ils communiquent avec le GMCS et HLR.
La figure suivante présente les différents éléments traversés par le SMS lors d’un
envoi à partir d’une application externe dans le réseau GSM.
Figure 2 : Entités participants à l’acheminement des SMS
25
ʹǤͶǤ
ȋ
Ȍ
ʹǤͶǤͳǤ
Le service de message court est apparu en Europe en 1991 dans le monde de

l’application mobile sans fil. Le standard européen pour l’application mobile ou GSM a
inclut ce système de message. Ce service est devenu un phénomène mondial depuis
l’année 1992. Depuis cet évènement, le SMS était devenu très pratique dans la mesure où
c’est l’un des moyens les plus efficaces pour passer l’information sans déranger la
personne destinataire. En outre, lors d'un évènement important (ex : nouvel an, coupe du
monde) entraînant de nombreux appels d'abonnés reliés à une même cellule, la
communication vocale devient de plus en plus difficile alors que les SMS sont acheminés
correctement.
Dans ce sens, le SMS est considéré comme le moyen de communication le plus

pratique.
ʹǤͶǤʹǤ ±
En anglais, l’abréviation SMS se traduit comme Short Message Service. C’est un

service qui permet la transmission de message texte ou alphanumérique entre entité
mobile et d’autre entité. En effet, la technologie des messages courts permet à un
utilisateur de composer un message textuel à partir de son terminal mobile et de l'envoyer
à un ou à plusieurs destinataires possédant également un téléphone radio mobile ou à une
application externe. En d’autre terme, c’est un service qui permet aux entités mobiles ou
non mobiles, d’envoyer ou de recevoir des petits messages texte dans un réseau
communément appelé « texto ».
En général, le petit message comporte au plus 160 caractères et peut varier en

fonction du système de codage et du réseau.
26
ʹǤͶǤ͵Ǥ
La figure 3 ci-dessous présente les entités qui constituent un service SMS

généralement et qui sont définies comme les suivantes :
• Le SMS-GMSC (Gateway MSC for Short Messsage):

Il a pour fonction de recevoir un SMS venant du SMSC et demander au HLR
la localisation de la station mobile destinataire, et de délivrer le SMS au MSC
auquel est rattaché MS destinataire.
• Le SMS-IWMSC :
Interworking MSC for Short Message Service est l’entité capable de recevoir
le message court d’un MSC et de le soumettre à un SMSC.
• Le SMSCShort Message Service Center :

Une fonction qui est responsable du stockage et relayage des SMS.
• Le SME Short Message Entité.
Une entité extérieure au réseau GSM pouvant envoyer ou de recevoir des SMS,
ceci pourrait être une application ou des serveurs spécialisés.
Figure 3 : Eléments de base du service SMS
27
ʹǤͶǤͶǤ
Il y a trois classes de SMS :
• Les messages venant d’un mobile ou SMS-MO, MO pour « Mobile

Originating »: l’abonné envoie un message.
9 Premièrement, le SMS envoyé atteint le centre des messages courts
SMSC. Ceci passe successivement par les équipements BTS, BSC,
MSC/VLR avant de rejoindre l’IWMSC qui se charge de le router vers le
SMSC approprié. Si à ce niveau le texto est bien reçu, un acquittement de
bonne réception est envoyé au MSC/VLR, qui à son tour l'envoie au
mobile.
• Les messages arrivant à un mobile ou SMS-MT, MT pour « Mobile

Terminating » : l’abonné reçoit un message.
9 Le SMSC envoie d'abord une requête de localisation au HLR qui indique
le MSC/VLR au niveau duquel il est enregistré. S'il est accessible, le
SMSC le lui délivre. Après avoir reçu le texto, le mobile renvoie au
SMSC un acquittement de réception par le biais du MSC/VLR.
• Les messages en diffusion ou message broadcast :

9 L’opérateur envoie le même message vers tous les abonnés.
Ǥ ǦȋȌ
Il dénote la capacité du réseau à transférer un message d’un MS vers un SMSC.

La figure 4 présente le cheminement logique du message court quand la station mobile
est l’émetteur SMS-MO.
28
Figure 4: SMS-MO
¾ Les séquences SMS MO :
1. L’émetteur remet le message court à son MSC/VLR de rattachement

(VMSC/VLR, Visited MSC/VLR) à travers la demande SMS-SUBMIT.
2. Le MSC émet un message MAP-SEND-INFO-FOR-MO-SMS à son VLR

pour lui demander le numéro de téléphone (MSISDN, Mobile Station ISDN
Number) de l’émetteur et pour vérifier qu’aucune restriction n’est imposée à
cet émetteur.
3. Le VLR retourne alors une réponse MAP-SEND-INFO-FOR-SMS-ack.
4. Si la réponse est positive, le MSC émet le message MAP-MO-FORWARD-

SHORT-MESSAGE à la fonction SMS-IWMSC à travers le réseau SS7. Ce
message contient l’adresse du SMSC, les numéros MSISDN de l’émetteur et
du destinataire, et le message court. Le message court est donc véhiculé dans
une transaction MAP.
5. La fonction SMS-IWMSC le retransmet à son tour au SMSC. Le SMSC

stocke le message et les adresses dans sa mémoire.
29
6. Le SMSC retourne une réponse (rapport de livraison) au SMS-IWMSC.
7. Ce rapport est inclus dans le message MAP-MO-FORWARD-SHORT-

MESSAGE-ack retourné par le SMS-IWMSC au MSC.
8. Le MSC retourne à l’émetteur un message SMS-STATUS-REPORT.
Ǥ ǦȋȌ
Ce service dénote la capacité du réseau à transmettre un message soumis par le

SMSC vers un MS.
La figure ci-dessous illustre le cheminement logique du SMS-MT.
Figure 5 : SMS-MT
¾ Les séquences de SMS-MT :
1. La fonction SMS-GMSC reçoit un message court du SMSC.
2. Cette fonction demande des informations de routage du message au HLR à

travers la requête MAP-SEND-ROUTING-INFO-FOR-SM.
30
Les informations obtenues lui permettent de relayer le message au MSC
approprié (MSC auquel est rattachée la station mobile destinataire).Cette
requête contient notamment le numéro MSISDN du destinataire.
3. Le HLR utilise ce numéro pour rechercher les informations de routage qu’il

retourne au SMS-GMSC à travers la réponse MAP-SEND-ROUTING-INFO-
FOR-SM-ack. Cette réponse contient l’IMSI du destinataire et l’adresse du
MSC de rattachement.
4. Le SMS-GMSC délivre le message court au MSC à travers une requête

MAP-MT-FORWARD-SHORT-MESSAGE.
5. Le MSC émet la requête MAP-SEND-INFO-FOR-MT-SMS à son VLR en

vue d’obtenir des informations relatives au destinataire. Le paramètre passé
dans cette requête est l’IMSI du destinataire.
6. A partir de l’IMSI fourni par le MSC, le VLR identifie la zone de localisation

(LA, Location Area) du mobile destinataire. Le VLR lance alors une
procédure de paging.
7. (MAP_PAGE), technique consistant à effectuer une recherche sur l’ensemble

de la zone où est susceptible de se trouver le mobile demandé. Si le VLR ne
connaît pas l’identité du destinataire, un message MAP-SEARCH-FOR-
SUBSCRIBER est alors émis afin de lancer la procédure de paging sur toutes
les LA dépendant du MSC. Dans l’exemple montré à la figure
L’identification du mobile destinataire est supposée connue. La procédure de
paging est initiée par le VLR mais effectuée par le MSC.
8. Le MSC effectue la procédure de paging sur la zone de localisation du

destinataire.
9. La station mobile destinataire répond positivement.
31
10. Le VLR retourne une réponse MAP-SEND-INFO-FOR-MT-SMS-ack au
MSC, autorisant ce dernier à relayer le message court à la station mobile
destinataire.
11. Le MSC achemine le message court au destinataire via le message SMS-

DELIVER et reçoit un acquittement SMS-STATUS-REPORT.
12. Le MSC inclut ce rapport dans la réponse MAP-MT-FORWARD-SHORT-

MESSAGE-ack retourné au SMS-GMSC.
13. Le SMS-GMSC passe le rapport au SMSC.
Ǥ
Le déroulement de l’envoi d’un SMS peut s’expliquer de la manière suivante :
Lors de l’envoi d’un SMS par un client (SMS-MO),le terminal mobile du client
code le message et l’envoie vers un MSC tout en y ajoutant deux informations
supplémentaires :
• le numéro du destinataire
• le numéro du SMSC à utiliser.
Ce dernier est stocké dans le terminal et permet au MSC de relayer le message vers
le SMSC en question. Dans le cas où le message ne peut pas être délivré au SMSC, le
réseau envoie un message d’acquittement négatif. Dans le cas contraire, le SMSC tente
d’envoyer le message vers le terminal du destinataire (SMS-MT) avec l’aide du MSC. Si
lors de l’envoi, la tentative échoue, comme par exemple le terminal mobile du
destinataire est éteint, le message est stocké par le SMSC et d’autres tentatives seront
effectuées à intervalles réguliers.
32
ǣ͵ǤͶ
Le protocole SMPP v3.4 a été créé par le groupe « SMS Standard Organization »
et publié le 12 octobre 1999. Il contient 169 pages.
Malgré quelques tentatives de mise à jour, à l’instar du SMPP v5.0, aucune autre version
du protocole n’a été aussi vulgarisée que le protocole SMPP v3.4. Ce dernier est
désormais devenu et considéré comme la seule et unique norme utilisée dans le monde
depuis la dissolution du groupe créateur.
Il est à noter que les définitions et les données ci-après fournissent, de manière
succincte, une explication des éléments indispensables à connaître concernant le
protocole.
͵ǤͳǤ

Dans le domaine de l’informatique, le protocole est défini comme un document

spécifiant « l’ensemble des règles définissant le mode de communication entre deux
ordinateurs »1.
͵ǤʹǤ ͵ǤͶ
Le protocole SMPP ou Short Message Peer to Peer est un standard désigné pour
établir une interface de communication plus flexible pour le transfert de message entre
des centres de messagerie comme le SMSC et l’ESME. Ce protocole est un protocole
ouvert défini par SMS forum.
Du point de vue technique, c’est un protocole binaire de niveau 7 qui s’appuie sur
le protocole X25 et TCP/IP. Comme mentionné précédemment, c’est un protocole
standard qui facilite l’échange de données entre des centres de message comme SMSC
ou autre système d’application SMS. Le protocole est basé sur l’échange de requête et
réponse PDU entre un ESME et SMSC.

1
Définition Larousse
33
C’est-à-dire que le protocole SMPP définit principalement un ensemble
d’opérations et les PDU qui lui sont associés pour l’échange d’information et la
communication.
Il définit également les données qu’un ESME peut échanger avec le SMSC pendant
une opération SMPP. Toutes opérations SMPP consistent donc à des échanges de requête
PDU à laquelle est associé le PDU réponse correspondant. L’entité receveur doit alors
envoyer une réponse en retour, la seule exception est l’alert_notification qui ne possède
pas de réponse qui lui correspond.
Dans ce protocole, l’échange peut se faire soit au niveau du SMSC par le biais d’un
envoi de message vers un service qui se traduit par un envoi de requête SMPP depuis le
SMSC vers le service, soit au niveau du service qui envoie une requête SMPP vers le
SMSC. A noter qu’il est possible pour un service d’envoyer ou de recevoir plusieurs
SMS avant de recevoir ou envoyer des acquittements via le SMPP.
Le schéma fonctionnel typique de cette communication est que l’application se

connecte sur le SMSC et les échanges de paquets SMPP peuvent commencer dans un
sens comme dans l’autre. En terme de langage réseau, ces paquets sont appelés : « Packet
Data Unit ou PDU ».
Figure 6 : Contexte de SMPP dans le réseau GSM
34
En principe, le protocole SMPP est composé d’environ une trentaine d’opérations
et à chacune d’elle est associé un PDU. Ils sont composés d’un en-tête (Header) suivi
d’un corps (body) dont le contenu dépend de l’opération à exécuter. Les opérations
implémentées par les PDU sont de types connexion, déconnexion, envoi de SMS, envoi
en masse, réception de SMS, acquittement, etc. À chaque requête doit correspondre un
acquittement.
Le tableau ci-dessous montre quelques exemples de requête PDU avec les réponses
correspondant͗

ESME to ESME SMSC to ESME
bind_transciever bind_transciever_resp
bind_transmitter bind_transmitter_resp
bind_receiver bind_receiver_resp
submit_sm submit_sm_resp
enquiry_link enquiry_link_resp
deliver_sm deliver_sm
Unbind unbind_resp
Tableau 1: liste d’exemples de PDU
͵Ǥ͵Ǥ ȋȌ
En général, le PDU est défini par une entête ou header suivi d’un corps ou body.
L'entête SMPP est un élément obligatoire pour chaque PDUSMPP et doit toujours être
présent. Le corps du PDU est une partie optionnelle et peut ne pas être inclus dans
chaque PDU.
35
Le tableau suivant illustre le format général du PDU dans le protocole SMPP :
PDU
PDU Body
PDU Header (obligatoire)
(optionnel)
Command Command Command Sequence
length id status number
Tableau 2 : format général du PDU
͵ǤͶǤ
͵ǤͶǤͳǤ
Constitué par les paramètres suivants :
• Command_length :
C’est un entier en 4 octets qui definit la longueur totale en octet d’un Packet PDU
incluant le command_length lui-même. C’est-à-dire le nombre total d’octets
contenus dans un PDU représenté en Big indian.
• Command_id :
C’est un entier en 4octets servant d’une identifiant qui est unique pour un PDU
particulier (ex : submit_sm,query_sm etc).
- Pour la requête PDU le command_id est dans le rang de 0x00000000 à
0x000001FF.
- Pour le PDU réponse, ce command_id est dans le rang de 0x80000000 à
0x800001FF.
36
• Command_status :
Le champ command_status est un champ qui indique le succèsou l’échec d’une

requête PDU. Ce champ est seulement defini dans leréponse PDU et doit avoir une
valeur NULLE dans les requêtes.
• Sequence_number :
C’est le numéro de séquence assigné à chaque requête et réponsePDU envoyé pour

assurer un échange asynchrone de ces PDUs.
Ce numéro de séquence est assigné à chaque PDU envoyé par l’émetteur et doit
être conservé pour le PDU réponse approprié.
Dans un PDU, ce champ est présenté par un entier en 4 octets dans le rang de
0x00000001 à 0x7FFFFF.
͵ǤͶǤʹǤ
Le body d’un PDU est aussi constitué des paramètres obligatoire et des paramètres
optionnels.
• Les paramètres obligatoires :
Ce sont des paramètres qui sont obligatoirement définie selon le type de PDU
indiqué par le champ command_id ( ex bind_transmitter).
• Les paramètres optionnels :
C’est une liste de paramètres pouvant être inclus ou non dans le PDU body et qui
correspondent au command_id du PDU spécifié (ex : submit_sm).
Dans ce qui suit, le tableau présente le flux de PDU lors d’un échange de requêtes.
Il faut noter que tous les paramètres mentionnés dans ces exemples sont décrits dans
l’annexe selon le Protocole SMPP.
37
͵ǤͶǤ͵Ǥ
• bind_transmitter :
a. Voici un exemple de requête PDU de type bind_transmitter
¾ Paquet du PDU:
000000028000000020000000000000001596F75724C6F67696E0050617373776F72640
00000000000
¾ Descriptions :
Ͳ 00000002: command_id = bind_transmitter

Ͳ 596F75724C6F67696E00: le system_id (le loging ou l’identificateur de
l’utilisateur qui définit par l’entité envoyeur) = "user"
Ͳ 50617373776F726400: password (le mot de passe de l’utilisateur)
Réponse positive au bind_transmitter (bind_transmitter_resp)

Il est à noter que la réponse à un PDU est envoyée si la requête a été acceptée par le
SMSC.
b. Voici un exemple de flux de réponses PDU dans le cas où la réponse à la

requête est positive :
¾ Paquet du PDU :
0000001E8000000200000000000000014E455453495A455F46525F303100
Les opérations SMPP :

¾ Descriptions :
Ͳ 80000002: command_id = bind_transmitter_resp

Ͳ 00000000: command_status = ESME_ROK (pas d’erreur)
38
Ͳ 4E455453495A455F46525F303100 : system_id (identiificateur de l’entité) ex
« JMGateway »
c. Voici un exemple de flux de réponses PDU dans le cas où la réponse à la

requête est négative :
Réponse négative au bind_transmitter (bind_transmitter_resp)
¾ Paquet du PDU :
00000010800000010000000D00000001
¾ Description :
Ͳ 80000001: command_id = bind_receiver_resp

Ͳ 0000000D: command_status = ESME_RBINDFAIL (la requête bind à échoué)
͵ǤͷǤ
Il y a trois types de session possible dans l’implémentation du protocole SMPP,

ceci dépend du choix de l’utilisateur mais aussi en fonction des besoins :
• Une session de type transmitter (TX) qui ne permet à l’application que

d’envoyer des messages au SMSC. Cette connexion est utilisée pour les
notifications ou les services d’alertes.
• Une session de type receiver (RX) qui permet à l’application de recevoir

uniquement des SMS.
• Une session de type mixte ou tranceiver (TRX) qui permet de faire les deux
opérations recevoir et envoyer.
39
En général, une session SMPP est initiée par un ESME qui établit en premier lieu
une connexion réseau (TCP/IP ou X25) avec le SMSC et ensuite effectue une opération
bind (requête PDU) pour ouvrir une session SMPP. En effet, un ESME souhaitant
recevoir ou envoyer des messages doit établir :
• Deux connexions réseaux et deux sessions SMPP type transmitter et receiver.
• Une seule connexion réseau et une session SMPP de type transceiver.
Pendant une session SMPP, le ESME peut effectuer une série de requête SMPP et
recevoir les réponses appropriées à chaque demande de la part du SMSC. Il en est de
même pour un SMSC, qui peut aussi envoyer des requêtes SMPP à l’ESME qui devra
répondre en conséquence.
͵ǤͷǤͳǤ
Un ESME souhaitant envoyer du SMS à un SMSC doit se connecter comme un

ESME transmitter ou transceiver. Dans ce cas, il peut envoyer des PDU à savoir :
• submit_sm
• deliver_sm
De plus, il est possible pour un ESME d’effectuer les opérations suivantes en

utilisant les identifiants renvoyés par le SMSC :
• cancel_sm: annuler la délivrance du message envoyé précédemment

• replace_sm: remplacer le précédent message envoyé
• query_sm: demander au SMSC le statut du précédent message
Le SMSC, à son tour, doit renvoyer les PDU réponses correspondant à laquelle sera
inclus un unique identificateur de message et aussi le statut qui informe le ESME si le
message envoyé est valide ou non (c’est-à-dire accepté par le SMSC pour être délivré).
40
Dans le cas où le message est non valide, le SMSC renvoie un code d’erreur. Pour
plus d’information sur les codes d’erreur (ref SMPP protocol).
Les PDU réponses correspondants sont :
• submit_sm_resp
• data_sm_resp
• query_sm_resp
• cancel_sm_resp
• replace_sm_resp
La figure ci-après présente une session de type transmitter pour l’envoi de SMS
d’un ESME vers un SMSC.
Figure 7 : Exemple typique d’une session bind_transmitter
41
͵ǤͷǤʹǤ
La session SMPP peut être définie par ses états qui sont :
¾ L’état OPEN :
Une entité extérieure établit une connexion réseau avec un SMSC mais n’a pas
encore envoyé une requête bind.
ESME SMSC
Connexion réseau
Figure 8 : Etat de session open
¾ L’état BOUND_TX :
Un ESME connecté à un SMSC a fait une demande de connexion de type

transmitter. Ceci en envoyant une requête bind_transmitter et a reçu une réponse de la
part du SMSC qui autorise sa requête pour transmettre du message.
L’ESME pourrait remplacer, annuler ou demander l’état du message

précédemment envoyé.
ESME SMSC
Connexion réseau
Bind_transmitter
Bind_transmitter_resp
Figure 9 : Etat de session TX
42
¾ L’état BOUND_RX :
Un ESME est connecté à un SMSC a effectué un demande de connexion de type

receiver en envoyant une requête bind_receiver et recevant une réponse de la part du
SMSC qui autorise sa requête de connexion pour pouvoir recevoir de message (par
exemple un accusé de réception).
ESME SMSC
Connexion réseau
Outbind
Bind_receiver
Bind_receiver_resp
Figure 10 : Etat de session RX
¾ L’état BOUND_TRX :
Un ESME est connecté à un SMSC. Il effectue une demande de connexion de type

transceiver en envoyant une requête bind_transceiver et reçoit la réponse correspondante
(bind_transceiver_resp) de la part du SMSC qui autorise sa demande de connexion pour
envoyer et recevoir de SMS.
ESME SMSC
Connexion réseau
Bind_tranceiver
Bind_tranceiver_resp
Figure 11 : Etat de session TRX
43
¾ CLOSED (Déconnecté) :
Un ESME ou un SMSC a fermé la connexion réseau. Cet état est typiquement dû à

l’envoi d’un PDU unbind par lequel la fin de session peut être demandée. L’état closed
peut aussi être le résultat d’une erreur de communication concernant la connexion réseau.
Par exemple le délai d’attente de connexion dépassé.
¾ OutBound :
Le but de l’opération Outbind est de permettre à un SMSC d’initier une session

SMPP. Une telle opération est typiquement applicable dans le cas où le SMSC a un
message court en attente pour être délivré.
L’opération est donc initiée par le SMSC en effectuant en premier lieu une
connexion réseau avec l’ESME. Dès que la connexion réseau est établie, le SMSC envoie
un PDU Outbind à l’ESME à laquelle ce dernier doit répondre par un bind_receiver qui
sera aussi répondu par le SMSC en émettant un bind_receiver_resp.
Si l’ESME n’accepte pas l’opération en raison d’un system_id ou pasword

incorrect, il doit se déconnecter du réseau.
Au moment où une session SMPP est établie, les caractéristiques de cette session
est parfaitement identique à celle d’une session receiver normale.
44
La figure suivante illustre le concept d’un outbind dans le cas où il est utilisé pour
demander à l’ESME d’exécuter une opération bind afin de recevoir les messages en
attente.
Figure 12 : Séquence atypique d’une opération outbind
͵ǤͷǤ͵Ǥ ±Ȁ
La connexion à un réseau nécessite l’implantation de protocole comme le X25 et le

TCP/IP. Ce projet mettra l’accent sur le TCP/IP qui est l’un des protocoles le plus utilisé
dans les réseaux informatiques.
Ǥ ±Ȁ
Au début, le TCP/IP a été développé par la défense Américaine Defense Advanced

Research Project Agency ou DARPA. Le but était d’interconnecter plusieurs réseaux
différents afin de l’utiliser pour des raisons militaires. Au milieu des années70, le DOD
l’a normalisé, et c’est devenu le standard pour le réseau Internet et réseau Local(LAN).
Par définition, le TCP/IP est un protocole utilisé sur le réseau Internet pour
transmettre des données entre deux machines. C’est comme un langage universel
permettant la communication entre deux machines qu’importe leur système
d’exploitation
45
Ǥ Ȁ
Le standard TCP/IP à une architecture suit le modèle conceptuel en couches appelé

modèle DOD. Ce modèle prend l’approche modulaire du modèle OSI mais contient
uniquement 4 couches qui sont :
¾ La couche application
Une couche qui contient tous le protocole haut niveau comme le TELNET pour le
terminal virtuel FTP pour le transfert de fichier le SMTP pour le transfert de courrier
électronique, le HTTP pour le web le DNS pour le service de nommage etc.
¾ La couche transport
C’est la couche qui assure la communication de bout en bout entre entités et

l’acheminement des données ainsi que le mécanisme permettant de connaitre l’état de la
transmission.
Cette couche a deux (02) protocoles de livraison d’information qui est indépendant
du réseau emprunté :
• Le TCP qui assure le contrôle de flux

• L’UDP qui correspond au service IP de multiplexé.
¾ La couche Internet
La couche internet sert d’une couche d’interconnexion basée sur le mode non
connecté. Elle est chargée de fournir le datagramme ou le paquet.
¾ La couche accès réseau
C’est la couche qui spécifie la forme sous laquelle les données doivent être
acheminées indépendamment au réseau utilisé.
46
La figure suivante illustre ce concept TCP/IP et son architecture.
Modèle de référence OSI Modèle TCP/IP (Internet)
Figure 13 : Architecture TCP/IP
L’architecture est basée sur les deux protocoles de base IP et TCP. En effet, le
TCP/IP est un ensemble de règles de communication sur Internet est basé sur la notion
d’adressage IP. Afin de pouvoir acheminer le paquet de données, une adresse IP est
fournie à chaque machine du réseau.
Ǥ ±Ȁ
• La transmission de données se fait par paquet appelé message au niveau de la

couche application.
• Au niveau de la couche transport, le message est encapsulé sous forme de

segment, c’est-à-dire découpé en morceau avant l’envoi.
• Une fois encapsulé dans la couche Internet, le message prend le nom du

Datagramme.
• Enfin, au niveau de la couche accès réseau, il y a la trame.
47
ǣ
ͶǤͳǤ

ȋȌ
Techniquement, un API est un ensemble de méthode ou de fonction ainsi que des

classes ou procédure fourni au programmeur (bibliothèque ou librairie) et qui est
indispensable à l’interopérabilité entre les composants d’un logiciel on d’un programme
informatique. En d’autre terme, l’interface de programmation est à une interface fournie
par un programme informatique qui permet l’interaction entre des programmes.
ͶǤʹǤ ǣ

L’ESME est la désignation des applications externes aux réseaux GSM qui sont capables
de communiquer avec des serveurs SMS. L’ESME a la capacité de se connecter à un SMSC en
effectuant une opération bind, d’envoyer et de recevoir des messages et de clore la connexion par
le biais l’opération unbind.
Il faut noter qu’en principe, ces applications sont des programmes installés sur
l’ordinateur.
ͶǤ͵Ǥ
ͶǤ͵ǤͳǤ
Une passerelle est un outil d’interconnexion qui permet d’interconnecter deux

systèmes avec des architectures différentes ou de protocoles différents. La passerelle
permet de décortiquer les paquets envoyés par le protocole émetteur et de le transcrire
par l’équivalent pour le protocole récepteur.
48
Figure 14 : Contexte de la passerelle SMS
ͶǤ͵ǤʹǤ
La difficulté rencontrée avec les passerelles est la compatibilité entre deux SMSC
qui sont gérés avec des protocoles qui leurs sont propres et qui dépendent du
fournisseur : c’est l’une des problèmes majeurs des messageries SMS.
Afin de pallier à ce problème, pour relier deux SMSC, il faut utiliser une passerelle
entre les deux SMSC qui agit comme un convertisseur.
Plusieurs passerelles sont proposées par les fabricants sur le marché mais il existe
un moyen d’employer Kannel.
ͶǤ͵Ǥ͵Ǥ ±±ǯ±

±͵ǤͶ
Vu l’évolution sur le domaine des applications SMS, il existe plusieurs interfaces

de programmation d’application (API) qui permet de se connecter à un SMSC utilisant le
protocole SMPP.
49
A titre d’exemple :
• API développé par logica Mobile Network Limited ;

• Passerelle SMPP Kannel ;
• GSMPP, etc.
Ǥ
La libraire SMPP de logica est une API développée par sourceforge. Elle est l’une
des plus utilisées dans le monde commercial car son accès est libre sur Internet.
Par ailleurs, l’API de logica - dont la version 1.1 a été publiée le 28 novembre 2001
- est un ensemble de classe pour permettre d’établir la communication avec un SMSC
utilisant le protocole SMPP.
Toutes les classes de cette bibliothèque sont développées avec le langage de

programmation java2 et implémentent la version 3.4 du protocole SMPP.
Logica est composé de :
¾ Trois (03) paquetages :

• Le paquetage com.logica.PDU qui est la bibliothèque de classe
représentant tous les paquets d’échanges.
• Le paquetage com.logica.debug
• Le paquetage com.logica.util
¾ 16 classes qui permettent de définir toutes les opérations possibles et

nécessaires pour l’envoi et la réception des messages, y compris la gestion des
erreurs et la gestion de la connexion réseau.

2
Le langage Java est un langage de programmation orienté objet très puissant grâce à la présence d’une
bibliothèque très riche. Pour la programmation réseau, java offre des possibilités de développement
d’applications fiables, rapides et réutilisables, mais aussi portable sur plusieurs systèmes d’exploitation
comme Unix, GNUlinux, Windows etc. C’est grâce à cette portabilité qui définit la valeur du programme
en java que les programmeurs actuels s’y sont beaucoup plus intéressés.
50
Pour la gestion des entrée et sortie, le concepteur de cette API a utilisé la
bibliothèque java.io qui est le paquetage fournissant les classes et les méthodes pour les
entrée et sortie en java.
Pour une meilleure compréhension de la librairie, les concepteurs de cette API ont mis à
disposition le simulateur SMSC Simulator de logica.
C’est l’application pour tester les opérations SMPP, c’est-à-dire l’échange de message entre une
application et un SMSC sans avoir à se connecter à un vrai SMSC (ex. SMSC de Orange). SMSC
simulator se comporte comme un vrai SMSC avec une interface SMPP. L’application ou l’ESME
peut se connecter, envoyer de message et se déconnecter à ce simulateur.
Toutefois, aucun SMS ne sera envoyé réellement. Toutes les réponses seront seulement
fournies par le simulateur. De plus, le simulateur peut supporter plusieurs clients connectés en
même temps.
Ǥ
Pour qu’une application puisse envoyer et recevoir des messages courts, elle a
toujours besoin de se connecter à un SMSC d’un opérateur de réseau mobile via Internet.
Si par exemple une école ou un établissement d’enseignement veut informer les étudiants
du résultat de l’examen avec l’aide du service de message court(SMS), la principale
recommandation est de se connecter et d’envoyer le message à partir d’un SMSC d’un
opérateur mobile (ex : Orange).
En principe, cette opération nécessite l’implémentation du protocole SMPP, mais

l’implémentation du protocole est une chose très délicate et demande beaucoup de temps.
De plus, l’opérateur mobile ne permettra jamais à une application d’effectuer cette
connexion par raison de sécurité. Donc, le moyen le plus simple est d’utiliser une
passerelle SMS. Plusieurs passerelles sont proposées à cet effet par les fabricants sur le
marché mais dans le cas de cette étude, la passerelle SMS utilisée est Kannel.
A noter que ce dernier est un logiciel libre, écrit en langage C et mise sous licence
freeBSD par la compagnie finlandaise Wapit ltd en 1999.
51
Kannel fournit une passerelle mixte SMS et WAP. Elle permet également de gérer
le push, le pull ou pull-push SMS, c'est-à-dire respectivement, l'envoi des messages aux
entités extérieures, la réception d'un SMS ou la réception de requête, puis l'envoi de la
réponse après traitement à partir de la plateforme.
Le traitement de la requête se fait au niveau de l'application, puis l'envoi de la

réponse via le SMSC de rattachement à l'abonné demandeur.
Dans la mesure où la passerelle est reliée à plusieurs SMSC, une configuration
appropriée se chargera du routage du SMS-MT vers le SMSC concerné.
Donc, l'éditeur de service ne sera pas obligé de maîtriser le protocole d’interfaçage au
SMSC mais il est obligé de le déterminer.
Kannel est composé de trois (03) blocs :
• le bearerbox : c’est le noyau de Kannel, il sert de le lien avec le réseau

téléphonique et les autres parties du Kannel. Le bearerboxest chargé de
transférer les messages vers l’un des blocs concernés.
• le SMS box : il reçoit les SMS de la part du bearerbox ; analyse le message

obtenu et en extraitles mots clés et les paramètres. Il peut égalementenvoyer
des données vers le bearerbox qui va le transférer vers le SMSC.
• le WAP box : l’intercommunication correcte entre ces trois blocs confère à

Kannel sa stabilité. De plus, ces différents blocs échangent à intervalles
réguliers et d’une façon permanente des messages de signalisation.
ͶǤ͵ǤͶǤ
Ǥ ǣ
Comme vu précédemment, Kannel est un logiciel libre (open source) qui peut
fonctionner comme une passerelle SMS et comme un client SMPP capable d’envoyer et
de recevoir des SMS.
52
Pour les sociétés, son utilisation est nécessaire pour diminuer le coût des services et les
dépenses.
Cependant, Kannel présente quelques problèmes relatifs à sa mise en place avec

d’autres systèmes comme le SMSC de logica.
Dans l’étude et le test effectués avec l’API de logica qui se sert d’un serveur de
message court et Kannel comme client SMPP (ESME), les points suivants ont été
constatés :
• Kannel dégage un problème sur le traitement de flux pour communiquer

indépendamment avec d’autres équipements qui sont reliés à son interface.
• Kannel présente des soucis au niveau de la connectivité avec le serveur http.
• Le système de Kannel ne peut pas supporter un nombre important de requête.

Il y a des risques de perte de requête quand le système est hors service.
En outre, Kannel ne peut pas gérer plusieurs clients quand il est utilisée en tant que
passerelle.
Ǥ ȋȌǣ
Du côté programmation et développement, le concepteur de cette bibliothèque a

utilisé la librairie java.io pour gérer les données d’entrée/sortie et la librairie java.net
pour la gestion de connexion réseau.
Du point de vue global, java.io traite par défaut les données en mode flux et les
entrée/sortie en mode bloquant, c’est-à-dire qu’il traite les données octet par octet.
A titre d’exemple, pour la Socket en Java, les opérations de lecture et d’écriture

sont bloquantes par défaut. Le thread lançant une opération de lecture ou d’écriture sur
Socket sera bloqué sur cet appel tant que l’opération ne sera pas terminée.
53
Tant qu’il n’y a rien à lire sur le socket ou qu’il n’y a pas d’espace disponible pour
écrire dessus, le thread sera bloqué. Il sera aussi débloqué en cas d’exception dû à un
timeout par exemple (cf. figure ci-dessous).
Figure 15 : Principe de lecture et d’écriture au niveau du socket
En observant cette séquence, dans le cas d’une connexion à multiples clients, la

création d’un thread 3 pour chaque client est évidente même si cette méthode rend le
système trop lent puisqu’elle consomme beaucoup plus de ressource système.

3
Un thread, appelé aussi processus léger ou activité, est un fil d'instructions (un chemin d’exécution) à
l'intérieur d'un processus. Définition dans Multithreading
54
ͶǤ͵ǤͷǤ ±±
Les API proposées en open source sont jusqu’ici conçues à partir de la librairie
java.io. De par les limites exposées ci-dessus, la solution la plus efficace pour résoudre
ces problèmes est de concevoir une API construite autour de la nouvelle librairie
java.nio.
JM
Logica JSMPP
Gateway
Java.io Java.nio
Figure 16 : Passage du java.io à java.nio
¾ Pourquoi Java.nio ?
Le nouveau paquetage d’entrée/sortie de java.nio est une API disponible depuis la

version 1.4 du JDK et permet essentiellement de réaliser des traitements non-bloquants
sur les entrées-sorties. NIO est en fait l’acronyme de New IO et vient en supplément de
l’API java.io existante. Java nio confère une rapidité et fiabilité des opérations
d’entrée/sortie sans avoir à écrire des codes natifs.
Le plus important est qu’elle fournit un système, le selector, pour écouter les
évènements sur les sockets. La ou les sockets sont enregistrées dans le selector en
précisant l’opération comme la lecture, l’écriture ou l’acceptation d’une demande de
connexion sur un socket défini.
Sur chaque appel à select (), le sélecteur créera une liste des Channel pour lesquels
une opération est prête à être réalisée. Le serveur doit toujours attendre qu’il y ait des
opérations disponibles sur ses sockets clients, mais la grande différence par rapport à
l’ancien est que le serveur attend une fois pour l’ensemble de ses clients au lieu
d’attendre pour un client.
55
En effet, ce système est une grande solution pour éviter le blocage sur le mode de
lecture et d’écriture au niveau du socket.
Par comparaison à l’exemple lecture/écriture sur socket de java.io, techniquement,

pendant que le thread utilisant java.io attend un client, un thread utilisant java.nio pourra
traiter d’autres clients.
Voici une illustration de cette théorie.
Figure 17 : Principe de lecture et d’écriture au niveau du socket en utilisant java.nio
Pour traiter les requêtes en parallèle avec l’API java.io, il suffit de multiplier le
nombre de thread avec un thread par client. Dans ce cas, il n’y aura pas d’attente non
plus. Malheureusement, les threads ne peuvent pas être multipliés indéfiniment sans qu’il
n’y ait d’impact sur l’espace mémoire.
56
Or, le cadre concurrentiel doit supporter le maximum possible de client. Avec un
faible nombre de threads (1 par CPU), la consommation de mémoire est aussi inférieure,
ce qui implique que NIO est devenu une évidence pour tous.
ͶǤͶǤ
Il existe plusieurs techniques pour réaliser un projet informatique, le choix dépend

du type de projet, du temps désigné pour terminer le projet aussi de la complexité du
travail.
Dans le cadre du présent projet, le chronogramme suivant a été suivi :
Analyse et Conception Implémentatio Test et

études de cas globale n du système qualification
Mise en
application
Figure 18 : Illustration de la méthode de réalisation
ͶǤͶǤͳǤ ±
Cette phase consiste à l’identification des besoins et à la mise en revue de tous les
systèmes existants, enfin à, l’étude de chaque composant qui va constituer le système.
ͶǤͶǤʹǤ
La conception globale concerne le choix des outils et matériels nécessaires àla

réalisation du projet, d’une part ; et la présentation d’une architecture en définissant tous
les modules entrant en jeu, d’autre part.
57
ͶǤͶǤ͵Ǥ ±°
Tous les modules sont codés conformément au cahier de charge et au protocole.

Ces modules sont ensuite testés indépendamment avant de les assembler pour créer
l’unité.
ͶǤͶǤͶǤ
Si l’élaboration du système est achevée, cette phase consiste à tester le système

dans la condition normale d’utilisation. C’est la fin du développement du système.
ͶǤͶǤͷǤ
Cette phase dépend de la qualification du système créé, c’est la mise en service

effective de la version finale du produit.
Dans le cadre de ce projet, la première phase est d’étudier le mode de transaction

du message entre Kannel et le simulateur de logica (SMSC simulator).
ͶǤͷǤ _
En premier lieu, pour comprendre le principe Kannel est utilisée comme un client
SMPP, et l’interface de logica comme un serveur SMS qui doit répondre à toutes les
requêtes envoyées à travers Kannel.
Avant de connecter Kannel avec logica, la transmission de SMS a été d’abord

testée avec un SMSC virtuel de Kannel appelé fakeSMSC pour savoir si tous les modules
de Kannel sont fonctionnels. Pour cela, le fichier de configuration Kannel.conf a été
configuré pour autoriser la connexion avec le fakeSMSC.
58
Ci-dessous un aperçu du test effectué.
ͶǤͷǤͳǤ
1. Démarrer le SMSbox et le bearerbox dans une invite de commande tout

en tapant « start_services ».
2. Ouvrir une autre invite de commande pour lancer le fakeSMSC. Il faut

préciser que pour envoyer des SMS, il faut respecter quelques syntaxes
ou format.
fakesmsc [-H host] [-r port] [-i interval] [-m max] <msg>
Par exemple, >>fakesmsc –r 10000 –i 0.1 –m 5 “0325645589
032859512 textnop”
Le fakeSMSC dispose de plusieurs fonctions :
Ͳ HOST : représente l’adresse du serveur défini au niveau du fichier de

configuration du serveur Kannel ;
Ͳ PORT : représente le port défini dans le fichier de configuration ;
Ͳ Intervall : représente l’intervalle de temps en seconde pour une
génération de message.
Ͳ MAX : le nombre maximal de message envoyé en une fois. Par défaut,
écrit « -1 » et qui veut dire que l’envoi du message est illimité.
Ͳ <msg> : défini par deux numéros arbitraires étant donné qu’il s’agit d’une
simulation, puis suivi du message à délivrer.
Un message peut également être envoyé à partir d’une page Internet en tapant par
exemple ce code :
http://127.0.0.1:13013/cgi-
bin/sendsms?username=tester&password=foobar&from=0331276055&to=03312
76045&text=attendre.
59
Le résultat qui devra s’afficher à la réception sera « attendre ». Le message peut
être envoyé à plusieurs destinataires en y ajoutant les numéros précédés de « + » dans la
partie receiver.
N.B : A noter que plusieurs fakeSMSC peuvent être configurés en spécifiant des ports
différents propres à chaque fakeSMSC. Son numéro et son id sont à préciser afin de les
différencier.
60
Voici une présentation du fichier de configuration 4 pour se connecter à un
fakeSMSC.
ηKZ
Ğ
ηdŚĞƌĞŝƐŽŶůǇŽŶĞĐŽƌĞŐƌŽƵƉĂŶĚŝƚƐĞƚƐĂůůďĂƐŝĐƐĞƚƚŝŶŐƐ
ηŽĨƚŚĞďĞĂƌĞƌďŽǆ;ĂŶĚƐǇƐƚĞŵͿ͘zŽƵƐŚŽƵůĚƚĂŬĞĞǆƚƌĂŶŽƚĞƐŽŶ

ηĐŽŶĨŝŐƵƌĂƚŝŽŶǀĂƌŝĂďůĞƐůŝŬĞΖƐƚŽƌĞͲĨŝůĞΖ;ŽƌΖƐƚŽƌĞͲĚŝƌΖͿ͕
ηΖĂĚŵŝŶͲĂůůŽǁͲŝƉΖĂŶĚΖĂĐĐĞƐƐ͘ůŽŐΖ
ŐƌŽƵƉсĐŽƌĞ

ĂĚŵŝŶͲƉŽƌƚсϭϯϬϬϬ
ƐŵƐďŽǆͲƉŽƌƚсϭϯϬϬϭ

ηǁĂƉďŽǆͲƉŽƌƚсϭϯϬϬϮ
ĂĚŵŝŶͲƉĂƐƐǁŽƌĚсďĂƌ

ηƐƚĂƚƵƐͲƉĂƐƐǁŽƌĚс
ĂĚŵŝŶͲĚĞŶǇͲŝƉсΗϭϮϳ͘Ϭ͘Ϭ͘ϭ͖Ύ͘Ύ͘Ύ͘ΎΗ

ĂĚŵŝŶͲĂůůŽǁͲŝƉсΗΎ͘Ύ͘Ύ͘ΎΗ
ůŽŐͲĨŝůĞсΗͰWƌŽŐƌĂŵ&ŝůĞƐͰ<ĂŶŶĞůϭ͘ϰ͘ϯͰŬĂŶŶĞů͘ůŽŐΗ
ůŽŐͲůĞǀĞůсϬ

ďŽǆͲĚĞŶǇͲŝƉсΗΎ͘Ύ͘Ύ͘ΎΗ
ďŽǆͲĂůůŽǁͲŝƉсΗϭϮϳ͘Ϭ͘Ϭ͘ϭ͖Ύ͘Ύ͘Ύ͘ΎΗ

ƵŶŝĨŝĞĚͲƉƌĞĨŝǆсΗнϮϮϴ͕ϬϬϮϮϴ͕Ϭ͖н͕ϬϬΗ
ĂĐĐĞƐƐͲůŽŐсΗ͗ͰWƌŽŐƌĂŵ&ŝůĞƐͰ<ĂŶŶĞůϭ͘ϰ͘ϯͰŬĂŶŶĞů͘ůŽŐΗ

ƐƚŽƌĞͲĨŝůĞсΗͰWƌŽŐƌĂŵ&ŝůĞƐͰ<ĂŶŶĞůϭ͘ϰ͘ϯͰƐƚŽƌĞΗ
ǁŚŝƚĞͲůŝƐƚсΗŚƚƚƉ͗ͬͬůŽĐĂůŚŽƐƚͬǁŚŝƚĞůŝƐƚ͘ƚǆƚΗ
ηƐƐůͲƐĞƌǀĞƌͲĐĞƌƚͲĨŝůĞсΗĐĞƌƚ͘ƉĞŵΗ

ηƐƐůͲƐĞƌǀĞƌͲŬĞǇͲĨŝůĞсΗŬĞǇ͘ƉĞŵΗ
ηƐƐůͲĐĞƌƚŬĞǇͲĨŝůĞсΗŵǇĐĞƌƚĂŶĚƉƌŝǀŬĞǇĨŝůĞ͘ƉĞŵΗ

ηͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲ

η^D^KEEd/KE^
η

η^D^ĐŽŶŶĞĐƚŝŽŶƐĂƌĞĐƌĞĂƚĞĚŝŶďĞĂƌĞƌďŽǆĂŶĚƚŚĞǇŚĂŶĚůĞ^D^ƐƉĞĐŝĨŝĐ
ηƉƌŽƚŽĐŽůĂŶĚŵĞƐƐĂŐĞƌĞůǇŝŶŐ͘zŽƵŶĞĞĚƚŚĞƐĞƚŽĂĐƚƵĂůůǇƌĞĐĞŝǀĞĂŶĚƐĞŶĚ
ηŵĞƐƐĂŐĞƐƚŽŚĂŶĚƐĞƚ͕ďƵƚĐĂŶƵƐĞ'^DŵŽĚĞŵƐĂƐǀŝƌƚƵĂů^D^Ɛ

ηdŚŝƐŝƐĂĨĂŬĞƐŵƐĐĐŽŶŶĞĐƚŝŽŶ͕ͺŽŶůǇͺƵƐĞĚƚŽƚĞƐƚƚŚĞƐǇƐƚĞŵĂŶĚƐĞƌǀŝĐĞƐ͘

η/ƚƌĞĂůůǇĐĂŶŶŽƚƌĞůĂǇŵĞƐƐĂŐĞƐƚŽĂĐƚƵĂůŚĂŶĚƐĞƚƐ͊
ŐƌŽƵƉсƐŵƐĐ

ƐŵƐĐсĨĂŬĞ
ƐŵƐĐͲŝĚс&<

ƉŽƌƚсϭϬϬϬϬ
ĐŽŶŶĞĐƚͲĂůůŽǁͲŝƉсϭϮϳ͘Ϭ͘Ϭ͘ϭ

η^D^Ky^dhW
η^ŵƐďŽǆ;ĞƐͿĚŽŚŝŐŚĞƌͲůĞǀĞů^D^ŚĂŶĚůŝŶŐĂĨƚĞƌƚŚĞǇŚĂǀĞďĞĞŶƌĞĐĞŝǀĞĚĨƌŽŵ

η^D^ĐĞŶƚĞƌƐďǇďĞĂƌĞƌďŽǆ͕ŽƌďĞĨŽƌĞƚŚĞǇĂƌĞŐŝǀĞŶƚŽďĞĂƌĞƌďŽǆĨŽƌĚĞůŝǀĞƌǇ
ŐƌŽƵƉсƐŵƐďŽǆ

ďĞĂƌĞƌďŽǆͲŚŽƐƚсϭϮϳ͘Ϭ͘Ϭ͘ϭ
ƐĞŶĚƐŵƐͲƉŽƌƚсϭϯϬϭϯ
ηŐůŽďĂůͲƐĞŶĚĞƌсϭϮϯϰϱϲ
ηƐĞŶĚƐŵƐͲĐŚĂƌƐсΗϭϮϯϰϱϲϳϴϵΗ

ηůŽŐͲĨŝůĞсΗͬƚŵƉͬƐŵƐďŽǆ͘ůŽŐΗ
ůŽŐͲĨŝůĞсΗͰWƌŽŐƌĂŵ&ŝůĞƐͰ<ĂŶŶĞůϭ͘ϰ͘ϯͰƐŵƐďŽǆ͘ůŽŐΗ
ĂĐĐĞƐƐͲůŽŐсΗͰWƌŽŐƌĂŵ&ŝůĞƐͰ<ĂŶŶĞůϭ͘ϰ͘ϯͰůŽŐƐΗηǁŚŝƚĞͲůŝƐƚсhZ>
ηůŽŐͲůĞǀĞůсϬ
ηĂĐĐĞƐƐͲůŽŐсΗͬƚŵƉͬĂĐĐĞƐƐ͘ůŽŐΗ

4
En informatique, un fichier de configuration contient des informations de configuration utilisées par un
programme informatique pour adapter ou personnaliser son fonctionnement. Définition wikipédia
61

ŐƌŽƵƉсƐŵƐͲƐĞƌǀŝĐĞ
ŬĞǇǁŽƌĚсĚĞĨĂƵůƚ
ƚĞǆƚсΗEŽƐĞƌǀŝĐĞƐƉĞĐŝĨŝĞĚΗ

tWKy^dhW
ηŐƌŽƵƉсǁĂƉďŽǆ
ηďĞĂƌĞƌďŽǆͲŚŽƐƚсϭϮϳ͘Ϭ͘Ϭ͘ϭ
ηůŽŐͲĨŝůĞсΗͬƚŵƉͬǁĂƉďŽǆ͘ůŽŐΗ
ηůŽŐͲůĞǀĞůсϬ
ƐǇƐůŽŐͲůĞǀĞůсŶŽŶĞ
ηĂĐĐĞƐƐͲůŽŐсΗͬƚŵƉͬǁĂƉĂĐĐĞƐƐ͘ůŽŐΗ

ηÊͲ^D^h^Z^
ηdŚĞƐĞƵƐĞƌƐĂƌĞƵƐĞĚǁŚĞŶ<ĂŶŶĞůƐŵƐďŽǆƐĞŶĚƐŵƐŝŶƚĞƌĨĂĐĞŝƐƵƐĞĚƚŽ
ηƐĞŶĚWh^,ƐŵƐŵĞƐƐĂŐĞƐ͕ŝ͘Ğ͘ĐĂůůŝŶŐhZ>ůŝŬĞ
ηŚƚƚƉ͗ͬͬŬĂŶŶĞů͘ŵĂĐŚŝŶĞ͗ϭϯϬϭϯͬĐŐŝͲďŝŶͬƐĞŶĚƐŵƐ͍ƵƐĞƌŶĂŵĞсƚĞƐƚĞƌΘƉĂƐƐǁŽƌĚсĨŽŽďĂƌ͘͘͘
ŐƌŽƵƉсƐĞŶĚƐŵƐͲƵƐĞƌ
ƵƐĞƌŶĂŵĞсƚĞƐƚĞƌ
ƉĂƐƐǁŽƌĚсĨŽŽďĂƌ
ƵƐĞƌͲĚĞŶǇͲŝƉсΗΎ͘Ύ͘Ύ͘ΎΗ
ƵƐĞƌͲĂůůŽǁͲŝƉсΗΎ͘Ύ͘Ύ͘ΎΗĨĂŬĞĚͲƐĞŶĚĞƌсϭ
ŽŵŝƚͲĞŵƉƚǇсϭ
ĨŽƌĐĞĚͲƐŵƐĐсƐŵƐĐͲŝĚ
ŐƌŽƵƉсƐŵƐͲƐĞƌǀŝĐĞ͘ŬĞǇǁŽƌĚсŚĞƵƌĞ
ηŚĞĂĚĞƌсŬƌŚͺƐƚŐ
ĨŽŽƚĞƌсŵĞƌĐŝ
ĂĐĐĞƉƚĞĚͲƐŵƐĐсƐŵƐĐ
ĨĂŬĞĚͺƐĞŶĚĞƌсϭϬϬ
ŽŵŝƚͲĞŵƉƚǇсϭ
ηƵƐĞƌͲĚĞŶǇͲŝƉсΗΗ
ηƵƐĞƌͲĂůůŽǁͲŝƉсΗΗ
η^Zs/^
η
ηdŚĞƐĞĂƌĞΖƌĞƐƉŽŶƐĞƐΖƚŽƐŵƐWh>>ŵĞƐƐĂŐĞƐ͕ŝ͘Ğ͘ŵĞƐƐĂŐĞƐĂƌƌŝǀŝŶŐĨƌŽŵ
ηŚĂŶĚƐĞƚƐ͘dŚĞƌĞƐƉŽŶƐĞŝƐďĂƐĞĚŽŶŵĞƐƐĂŐĞĐŽŶƚĞŶƚ͘KŶůǇŽŶĞƐŵƐͲƐĞƌǀŝĐĞŝƐ
ηĂƉƉůŝĞĚ͕ƵƐŝŶŐƚŚĞĨŝƌƐƚŽŶĞƚŽŵĂƚĐŚ͘

ŬĞǇǁŽƌĚсŶŽƉ
ƚĞǆƚсΗzŽƵĂƐŬĞĚŶŽƚŚŝŶŐĂŶĚ/ĚŝĚŝƚ͊Η

ηdŚĞƌĞƐŚŽƵůĚďĞĂůǁĂǇƐĂΖĚĞĨĂƵůƚΖƐĞƌǀŝĐĞ͘dŚŝƐƐĞƌǀŝĐĞŝƐƵƐĞĚǁŚĞŶŶŽ
ηŽƚŚĞƌΖƐŵƐͲƐĞƌǀŝĐĞΖŝƐĂƉƉůŝĞĚ͘

ƚĞǆƚсΗEŽƐĞƌǀŝĐĞƐƉĞĐŝĨŝĞĚΗ
Figure 19 : Aperçu du fichier de configuration de Kannel pour fakeSMSC

62
Ǥ ±
¾ Résultat du test de connexion avec fakeSMSC
Figure 20 : Résultat du test de connexion avec fakeSMSC
La syntaxe utilisée pour le test est : fakeSMSC –r 10000 –i 3.5 –m 4 « 0320565454

0325698754 text attendre ».
Ͳ 0320565454 : numéro de l’envoyeur

Ͳ 0325698754 : numéro du destinataire
Ͳ 10000 : port utilisé
Ͳ 3,5 (s) : intervalle de temps entre la génération du message
Ͳ 4 : nombre de message maximal à envoyer
Ͳ « attendre » : message à envoyer
Ǥ
D’après la figure 20, le résultat obtenu est conforme au résultat attendu.
63
ͶǤͷǤʹǤ °
Ǥ Ǥ
Dans un premier temps, logica et le fichier de configuration de Kannel ont été

configurés pour un mode de connexion à un SMSC.
Ǥ
Comme précisé dans les fichiers configurés ci-dessus, le numéro de port à 5019 a
été spécifié. L’utilitaire « apache ant 1.8.2 » a été utilisé pour la compilation et la
création d’un jarfile (sources logica) à utiliser lors de la simulation.
Lors de l’exécution, les mêmes manipulations qu’avec SMSC ont été reprises et les
résultats sont les mêmes.
64
Voici une présentation du fichier de configuration pour ce test.
KZ
η
ηdŚĞƌĞŝƐŽŶůǇŽŶĞĐŽƌĞŐƌŽƵƉĂŶĚŝƚƐĞƚƐĂůůďĂƐŝĐƐĞƚƚŝŶŐƐ
ηŽĨƚŚĞďĞĂƌĞƌďŽǆ;ĂŶĚƐǇƐƚĞŵͿ͘zŽƵƐŚŽƵůĚƚĂŬĞĞǆƚƌĂŶŽƚĞƐŽŶ
ηĐŽŶĨŝŐƵƌĂƚŝŽŶǀĂƌŝĂďůĞƐůŝŬĞΖƐƚŽƌĞͲĨŝůĞΖ;ŽƌΖƐƚŽƌĞͲĚŝƌΖͿ͕
ηΖĂĚŵŝŶͲĂůůŽǁͲŝƉΖĂŶĚΖĂĐĐĞƐƐ͘ůŽŐΖ

ŐƌŽƵƉсĐŽƌĞ
ĂĚŵŝŶͲƉŽƌƚсϭϯϬϬϬ
ƐŵƐďŽǆͲƉŽƌƚсϭϯϬϬϭ
ĂĚŵŝŶͲƉĂƐƐǁŽƌĚсďĂƌ
ĚůƌͲƐƚŽƌĂŐĞсŝŶƚĞƌŶĂů
ηƐƚĂƚƵƐͲƉĂƐƐǁŽƌĚсĨŽŽ
ηĂĚŵŝŶͲĚĞŶǇͲŝƉсΗΗ
ηĂĚŵŝŶͲĂůůŽǁͲŝƉсΗΗ
ůŽŐͲĨŝůĞсΗͬĚĂƚĂͬŽƌĂŶŐĞͬŐĂƚĞǁĂǇͲϭ͘ϰ͘ϯͬůŽŐƐͬďĞĂƌĞƌ͘ůŽŐΗ
ďŽǆͲĚĞŶǇͲŝƉсΗΎ͘Ύ͘Ύ͘ΎΗ
ďŽǆͲĂůůŽǁͲŝƉсΗϭϮϳ͘Ϭ͘Ϭ͘ϭΗ
ηƵŶŝĨŝĞĚͲƉƌĞĨŝǆсΗнϯϱϴ͕ϬϬϯϱϴ͕Ϭ͖н͕ϬϬΗ
ĂĐĐĞƐƐͲůŽŐсΗͬĚĂƚĂͬŽƌĂŶŐĞͬŐĂƚĞǁĂǇͲϭ͘ϰ͘ϯͬůŽŐƐͬĂĐĐĞƐƐ͘ůŽŐΗ
ƐƚŽƌĞͲƚǇƉĞсƐƉŽŽů
ƐƚŽƌĞͲůŽĐĂƚŝŽŶсΗͬĚĂƚĂͬŽƌĂŶŐĞͬŐĂƚĞǁĂǇͲϭ͘ϰ͘ϯͬƐƚŽƌĞΗ
ƐƚŽƌĞͲĚƵŵƉͲĨƌĞƋсϯϬ
ηĚůƌͲƐƚŽƌĂŐĞсŵǇƐƋů
ƐŵƐͲƌĞƐĞŶĚͲƌĞƚƌǇсϱ
ηƐƐůͲƐĞƌǀĞƌͲĐĞƌƚͲĨŝůĞсΗĐĞƌƚ͘ƉĞŵΗ
ηƐƐůͲƐĞƌǀĞƌͲŬĞǇͲĨŝůĞсΗŬĞǇ͘ƉĞŵΗ
ηƐƐůͲĐĞƌƚŬĞǇͲĨŝůĞсΗŵǇĐĞƌƚĂŶĚƉƌŝǀŬĞǇĨŝůĞ͘ƉĞŵΗ

η^D^KEEd/KE^
η
η^D^ĐŽŶŶĞĐƚŝŽŶƐĂƌĞĐƌĞĂƚĞĚŝŶďĞĂƌĞƌďŽǆĂŶĚƚŚĞǇŚĂŶĚůĞ^D^ƐƉĞĐŝĨŝĐ
ηƉƌŽƚŽĐŽůĂŶĚŵĞƐƐĂŐĞƌĞůǇŝŶŐ͘zŽƵŶĞĞĚƚŚĞƐĞƚŽĂĐƚƵĂůůǇƌĞĐĞŝǀĞĂŶĚƐĞŶĚ
ηŵĞƐƐĂŐĞƐƚŽŚĂŶĚƐĞƚ͕ďƵƚĐĂŶƵƐĞ'^DŵŽĚĞŵƐĂƐǀŝƌƚƵĂů^D^Ɛ
ηdŚŝƐŝƐĂĨĂŬĞƐŵƐĐĐŽŶŶĞĐƚŝŽŶ͕ͺŽŶůǇͺƵƐĞĚƚŽƚĞƐƚƚŚĞƐǇƐƚĞŵĂŶĚƐĞƌǀŝĐĞƐ͘
η/ƚƌĞĂůůǇĐĂŶŶŽƚƌĞůĂǇŵĞƐƐĂŐĞƐƚŽĂĐƚƵĂůŚĂŶĚƐĞƚƐ͊

ŐƌŽƵƉсƐŵƐĐ
ƐŵƐĐсƐŵƉƉ
ƐŵƐĐͲŝĚс>ŽŐŝĐĂ
ŚŽƐƚсϭϮϳ͘Ϭ͘Ϭ͘ϭ
ƉŽƌƚсϱϬϭϵ
ƐŵƐĐͲƵƐĞƌŶĂŵĞсƵƐĞƌϭ
ƐŵƐĐͲƉĂƐƐǁŽƌĚсƉĂƐƐǁŽƌĚϭ
ƐǇƐƚĞŵͲƚǇƉĞсΗ>ŽŐŝĐĂΗ
ƚƌĂŶƐĐĞŝǀĞƌͲŵŽĚĞсƚƌƵĞ

η^D^Ky^dhW
η
η^ŵƐďŽǆ;ĞƐͿĚŽŚŝŐŚĞƌͲůĞǀĞů^D^ŚĂŶĚůŝŶŐĂĨƚĞƌƚŚĞǇŚĂǀĞďĞĞŶƌĞĐĞŝǀĞĚĨƌŽŵ
η^D^ĐĞŶƚĞƌƐďǇďĞĂƌĞƌďŽǆ͕ŽƌďĞĨŽƌĞƚŚĞǇĂƌĞŐŝǀĞŶƚŽďĞĂƌĞƌďŽǆĨŽƌĚĞůŝǀĞƌǇ

ŐƌŽƵƉсƐŵƐďŽǆ
ďĞĂƌĞƌďŽǆͲŚŽƐƚсϭϮϳ͘Ϭ͘Ϭ͘ϭ
ƐĞŶĚƐŵƐͲƉŽƌƚсϭϯϬϭϯ
ηŐůŽďĂůͲƐĞŶĚĞƌсϭϯϬϭϯ
ηƐĞŶĚƐŵƐͲĐŚĂƌƐсΗϬϭϮϯϰϱϲϳϴϵнͲΗ
ηǁŚŝƚĞͲůŝƐƚͲƌĞŐĞǆсΔ;΀͗н͗΁Ϯϲϭ΀ϬͲϵ΁΀ϬͲϵ΁΀ϬͲϵ΁΀ϬͲϵ΁΀ϬͲϵ΁ͿΨ
ůŽŐͲĨŝůĞсΗͬĚĂƚĂͬŽƌĂŶŐĞͬŐĂƚĞǁĂǇͲϭ͘ϰ͘ϯͬůŽŐƐͬƐŵƐďŽǆ͘ůŽŐΗ
ĂĐĐĞƐƐͲůŽŐсΗͬĚĂƚĂͬŽƌĂŶŐĞͬŐĂƚĞǁĂǇͲϭ͘ϰ͘ϯͬůŽŐƐͬĂĐĐĞƐƐ͘ůŽŐΗ
ŵŽͲƌĞĐŽĚĞсƚƌƵĞ

ηÊͲ^D^h^Z^
η
65

ÊͲ^D^h^Z^
η
ηƐĞŶĚWh^,ƐŵƐŵĞƐƐĂŐĞƐ͕ŝ͘Ğ͘ĐĂůůŝŶŐhZ>ůŝŬĞ
ηŚƚƚƉ͗ͬͬŬĂŶŶĞů͘ŵĂĐŚŝŶĞ͗ϭϯϬϭϯͬĐŐŝͲďŝŶͬƐĞŶĚƐŵƐ͍ƵƐĞƌŶĂŵĞсƚĞƐƚĞƌΘƉĂƐƐǁŽƌĚсĨŽŽďĂƌ͘͘͘

ƵƐĞƌŶĂŵĞсƚĞƐƚĞƌ
ƉĂƐƐǁŽƌĚсĨŽŽďĂƌ
ηƵƐĞƌͲĚĞŶǇͲŝƉсΗΗ
ηƵƐĞƌͲĂůůŽǁͲŝƉсΗϭϮϳ͘Ϭ͘Ϭ͘ϭ͕ϭϵϮ͘ϭϲϴ͘ϭϱ͘ϱϵ͕ϭϵϮ͘ϭϲϴ͘Ϯϯ͘ϭϰϰΗ

ƵƐĞƌŶĂŵĞс
ƉĂƐƐǁŽƌĚс

η^Zs/^
η
ηdŚĞƐĞĂƌĞΖƌĞƐƉŽŶƐĞƐΖƚŽƐŵƐWh>>ŵĞƐƐĂŐĞƐ͕ŝ͘Ğ͘ŵĞƐƐĂŐĞƐĂƌƌŝǀŝŶŐĨƌŽŵ
ηŚĂŶĚƐĞƚƐ͘dŚĞƌĞƐƉŽŶƐĞŝƐďĂƐĞĚŽŶŵĞƐƐĂŐĞĐŽŶƚĞŶƚ͘KŶůǇŽŶĞƐŵƐͲƐĞƌǀŝĐĞŝƐ
ηĂƉƉůŝĞĚ͕ƵƐŝŶŐƚŚĞĨŝƌƐƚŽŶĞƚŽŵĂƚĐŚ͘

ŬĞǇǁŽƌĚсŶŽƉ
ƚĞǆƚсΗzŽƵĂƐŬĞĚŶŽƚŚŝŶŐĂŶĚ/ĚŝĚŝƚ͊Η

ηdŚĞƌĞƐŚŽƵůĚďĞĂůǁĂǇƐĂΖĚĞĨĂƵůƚΖƐĞƌǀŝĐĞ͘dŚŝƐƐĞƌǀŝĐĞŝƐƵƐĞĚǁŚĞŶŶŽ
ηŽƚŚĞƌΖƐŵƐͲƐĞƌǀŝĐĞΖŝƐĂƉƉůŝĞĚ͘

ηŐƌŽƵƉсƐŵƐͲƐĞƌǀŝĐĞ
ηŬĞǇǁŽƌĚсĚĞĨĂƵůƚ
ηƚĞǆƚсΗEŽƐĞƌǀŝĐĞƐƉĞĐŝĨŝĞĚΗ
ηƚĞǆƚсΗΗ

ηͲͲͲ,ŽŶŽƌĠĞƚDŝƌŝũĂͲͲͲ
ŐĞƚͲƵƌůсΗŚƚƚƉ͗ͬͬϭϮϳ͘Ϭ͘Ϭ͘ϭ͗ϲϬϴϬͬƐĞƌǀůĞƚϭͬ^ƚŽƌĞ^ŵƐ͍ŝĚсй/ΘĨƌŽŵсйƉΘƚŽсйWΘƚĞǆƚсйĂΘƐŵƐĐсйŝΗ
ĂĐĐĞƉƚͲǆͲŬĂŶŶĞůͲŚĞĂĚĞƌƐсƚƌƵĞ
ŵĂǆͲŵĞƐƐĂŐĞƐсϬ
ĐŽŶĐĂƚĞŶĂƚŝŽŶсƚƌƵĞ
Figure 21 : Fichier de configuration de Kannel avec logica

66
Ǥ ±

Deux (02) fakeSMSC et un SMSCsim de logica ont été utilisés afin d’effectuer le
test.
Pour chaque fakeSMSC, chaque numéro de port a été spécifié. Un essai d’envoi de
SMS via un fakeSMSC vers le logica a été effectué. Et le résultat montre les limites de
Kannel car si le SMS est envoyé deux fois, le message peut arriver à destination mais de
façon aléatoire ; c'est-à-dire qu’il peut envoyer un SMS au logica et un autre revient vers
le fakeSMSC ; ou par exemple, les deux SMS peuvent être reçus sur les fakeSMSC ou
l’inverse.
Ǥ ±
¾ Résultat du test de connexion avec fakeSMSC
Figure 22 : Résultat du test de connexion avec fakeSMSC connecté à logica
Ǥ
L’interconnexion des deux passerelles Kannel et logica a été réalisée avec

succès car le message envoyé a été bien transmis.
67

En conclusion, Kannel ne peut pas gérer plusieurs clients en même temps.

Les différents types d’envoi de SMS à travers le serveur Kannel et l’utilisation de
fakeSMSC ont été observés ; et le fonctionnement de SMSCsim de logica a été étudié. Le
serveur Kannel présente plusieurs fonctionnalités décrites dans le guide d’utilisateur mais
les possibilités offertes par la fonctionnalité des simulateurs utilisés n’ont pas toutes été
exploitées.
L’impossibilité pour Kannel de gérer plusieurs clients en même temps provoque

quelques problèmes en terme d’envoi de SMS.
ͶǤ͸Ǥ _ǯ
La conception de l’API est la base du présente mémoire. Cette phase est la plus
longue et difficile, parce que il faut maitriser la spécification du protocole SMPP.
Pour cette partie, la version 3.4 a été utilisée comme la version par défaut du protocole.
La phase de conception globale est divisée en tache :
1. Développement et programmation des PDU conformément au protocole ;
2. Programmation des modules qui sont utiles pour la conception des PDU, par
exemple, le module pour encodage et décodage de caractère, les modules de
conversion de type de traitement entier en octet par exemple ;
3. Programmation des différents modules qui entrent en jeu lors d’une session
SMPP ;
4. Pro.
68
ͶǤ͸ǤͳǤ ±

• Construction de la classe Data dans le but de stocker toutes les données

spécifiées dans le protocole SMPP 3.4 et qui peuvent être renvoyées grâce à
différentes méthodes statiques ;
• Construction des différentes classes pour la conversion de chaque type de

données en série d’octet et la reconversion d’octet en d’autres types ;
• Construction de la classe SMMPconfigureDate qui définit l’initialisation de

chaque date employée par les PDU (par exemple la période de validité d’un
message). Elle propose plusieurs méthodes pour permettre de convertir une
date en une variable de type String ;
• Construction d’une classe nommée ShortMessage qui prend en compte une

variable de type String et qui permet d’effectuer l’encodage du message dans
un style de codage spécifique. Elle renvoie une suite d’octet contenue dans un
tableau.
Pour illustrer les idées avancées ci-dessus, voici le diagramme de classe de la

construction des dates.
Figure 23 : Diagramme hiérarchique des classes de la construction des dates*
*Les informations détaillées sur les classes illustrées sur ce diagramme sont données en annexes
4 et 5.

69
ͶǤ͸ǤʹǤ
La classe ProtocolVersion est une classe abstraite qui permet de définir et de

vérifier les informations contenues dans le PDU par rapport à la version du protocole
SMPP utilisé par l’application.
La classe Version33 et la classe Version34 dérivent de celle-ci.
Voici le diagramme hiérarchique de classe pour illustrer ces propos :
Figure 24 : Diagramme hiérarchique des différentes versions*
6, 7 et 8.
ͶǤ͸Ǥ͵Ǥ
Ǥ
La classe PDU est une classe contenant un entête (PDUHeader) et un corps

(PDUbody). Dans cette classe, le paquet est stocké dans un ByteBuffer. Il définit deux
méthodes : l’une qui permet de retourner une série d’octet contenue dans un Bytebuffer
et l’autre permet d’entrer dans un Bytebuffer une série d’octet selon la spécification du
protocole.
70
Ǥ
C’est une classe contenant tous les éléments constituant l’entête du PDU.
Les paramètres à considérer sont :
• La longueur totale du PDU ;

• Le paramètre identificateur du PDU ;
• Le code d’erreur ;
• Le numéro de séquence qui est propre au PDU et qui permet à posteriori
d’identifier son acquittement.
Le PDUHeader présente plusieurs méthodes d’entrée et de sortie pour les éléments

ci-dessus (exemple : setCommandLength() pour entrer la valeur de la longueur totale du
PDU et getCommandLength() pour obtenir cette valeur).
Ǥ
C’est la classe qui représente le corps du PDU. Elle est abstraite et contient toutes
les informations utiles possibles et définies par la spécification du protocole SMPP.
Cette classe met à la disposition de chaque programmeur des méthodes pouvant
retourner les valeurs de chaque paramètre (exemple : la méthode getSystem_id() pour
avoir l’identifiant du ESME et du SMSC).
Ǥ ±
PDU DESCRIPTION FONCTION
C’est une requête

• Contient un entête et un
employée par un ESME
corps
bind_transmitter pour demander une session
• Le code d’erreur ne peut
transmitter (session pour
prendre que la valeur nulle
seulement l’envoi de SMS)
71
• Si le code d’erreur est nul,
C’est une réponse à la
il est composé d’un
requête transmitter qu’un
PDUHeader et d’un
SMSC doit renvoyer après
Bind_transmitter_resp PDUBody
avoir reçu et traité cette
• Si le code d’erreur est non
requête.
nul alors il n’y a que le
PDUHeader
• Contient un PDUHeader et employée par un ESME
Bind_receiver un PDUBody. pour demander une session
• Le code d’erreur ne peut receiver (session pour
prendre que la valeur nulle seulement la réception de
SMS)
• Si le code d’erreur est nul
alors il est composé d’un C’est une réponse à la
PDUHeader et d’un requête receiver qu’un
Bind_receiver_resp PDUBody SMSC doit renvoyer après
• Si le code d’erreur est non avoir reçu et traité cette
nul alors il n’y a que le requête
PDUHeader
• Contient un PDUHeader et
employée par un ESME
un PDUBody.
Bind_transceiver pour demander une session
• Le code d’erreur ne peut
transceiver (session pour la
prendre que la valeur nulle
réception et envoi de SMS)
alors il est composé d’un C’est une réponse à la
PDUHeader et d’un requête receiver qu’un
Bind_transceiver_resp PDUBody SMSC doit renvoyer après
• Si le code d’erreur est non avoir reçu et traité cette
nul alors il n’y a que le requête
PDUHeader
Requête envoyée par un
• Contient un PDUHeader et
SMSC pour notifier le
un PDUBody
outbind ESME d’effectuer un
• Son code d’erreur est
bind_receiver quand il y a
obligatoirement de valeur
des SMS en attente pour
nulle
être délivrés
• C’est un PDU qui ne Requête envoyée par un
Unbind contient qu’un PDUHeader SMSC ou un ESME pour
• Le code d’erreur est nul clore une session.
72
Réponse correspondant à
• Ne contient qu’un
Unbind_resp l’acceptation de fermeture
PDUHeader
de session.
PDU qui contient le
• Doit contenir un
message à envoyer à un
Submit_sm PDUHeader et PDUBody
SMSC
• Code d’erreur doit être nul

alors il contient un
Réponse correspondant à la
PDUHeader et un
réception ou l’échec de
Submit_sm_resp PDUBody
l’envoi d’un SMS
• Si le code d’erreur est non
nul alors il ne contient
qu’un PDUHeader
• Doit contenir un PDU qui contient le
Deliver_sm PDUHeader et PDUBody message à délivrer à un
• Code d’erreur doit être nul ESME
• Il contient un PDUHeader Réponse correspondant à la
Deliver_sm_resp et un PDUBody réception ou à l’échec de
• Le paramètre contenu dans l’envoi d’un SMS
son corps doit être nul
• Doit contenir un
PDU pour envoi d’un SMS
Submit_multi_sm PDUHeader et PDUBody
à plusieurs destinataires
• Code d’erreur doit être nul
Réponse envoyée par le
• Il contient un PDUHeader
SMSC pour signifier à
Submit_multi_sm_resp et un PDUbody
l’ESME le nombre d’échec
•
lors de l’envoi des SMS.
Requête envoyée au SMSC
pour demander le
• Doit contenir un remplacement d’un SMS
Replace_sm PDUHeader et PDUBody avec un autre en lui
• Code d’erreur doit être nul donnant un identificateur
du message correspondant
PDUHeader
Réponse du SMSC lors
• Son code d’erreur indique
Replace_sm_resp d’une demande de
la raison de l’échec s’il
remplacement
n’est pas nul.
73
• Contient un PDUHeader et Requête pour signifier au
Cancel_SM un PDUBody SMSC d’annuler les SMS
• Code d’erreur doit être nul envoyés
Réponse du SMSC lors
PDUHeader
Cancel_SM_resp d’une demande
• Son code d’erreur indique
d’annulation de la part
la raison de l’échec s’il
d’un ESME
n’est pas nul.
• Doit contenir un Requête envoyer au SMSC
Query_sm PDUHeader et PDUBody pour demander si l’envoi
• Code d’erreur doit être nul d’un sms e été un succès
• Doit contenir un Réponse du SMSC pour
Query_sm_resp PDUHeader et PDUBody informer l’ESME si le
• Code d’erreur indique la message a été bien pris en
situation du message compte
Requête utilisée pour
l’envoi de SMS que ce soit
• Contient PDUHeader et
du coté SMSC ou ESME
Data_sm PDUBody
C’est une PDU qui est
• Le code d’erreur est nul
l’alternative de submit_sm
et submit_multi
• Contient PDUHeader et
Réponse correspondante
Data_sm_resp PDUBody
adata_sm
Requête envoyée par un
• Contient seulement un
ESME ou un SMSC pour
enquire_link Header
vérifier si la connexion est
toujours établie
• Contient seulement un
Enquire_link_resp Header Réponse correspondant à
• Le code d’erreur doit être enquire_link
nul
• Contient un body et un
Requête envoyée pour
Header
Alert_notification envoyer un accusé de
• Le code d’erreur est
réception
toujours nul
• Un PDU qui contient Réponse envoyée par
Generic_nack seulement un Header l’ESME ou le SMSC si le
• Le code d’erreur ne doit PDUHeader d’une requête
jamais être nul est invalide
Tableau 3 : Caractéristiques des différents PDU
74
Ǥ
Les diagrammes de classes montrent la structure interne d'un système et fournissent

une représentation abstraite des objets qui vont interagir pour réaliser les cas d'utilisation.
Voici le diagramme d’interaction des classes PDU, PDUHeader, PDUBody
Figure 25 : Diagramme d’interaction des classes PDU, PDUHeader, PDUBody*

9, 10 et 11.
75
Voici le diagramme hiérarchique des classes héritant de PDUBody
Figure 26 : Diagramme hiérarchique des classes héritant de PDUBody*

*Les informations détaillées sur les classes illustrées sur ce diagramme sont données en annexe 15.
Voici le diagramme hiérarchique des classes héritant de PDUHeader
Figure 27 : Diagramme hiérarchique des classes héritant de PDUHeader*

76
ͶǤ͸ǤͶǤ

Une session est l’échange de PDU entre deux entités qui sont l’ESME et un SMSC
après l’établissement d’une connexion TCP/IP. Chaque session est définie par plusieurs
états et permet ainsi de lister les requêtes PDU qui peuvent être envoyées et reçues
jusqu’à sa fermeture.
Il y a plusieurs types d’état à savoir :
• « OUTBOUND » permet de caractériser l’acte du SMSC qui initie une

requête pour faire part à l’ESME de la présence de SMS à délivrer. Il
permet l’envoi d’un outbind par le SMSC vers l’ESME. Si cette opération
échoue, l’ESME ferme la connexion physique qui le relie avec le SMSC.
L’ESME ferme la connexion s’il ne reconnait pas le SMSC qui lui envoie
cette requête.
• « OPEN » est l’un des états de la session. Pendant celui-ci, l’ESME

envoie et fait part au SMSC ce qu’il attend de leur communication.
L’ESME envoie à cet effet une opération de bind.
• « BOUND_TX » est l’un des états qui définit le statut et la raison d’être
de la session. Il définit que l’ESME va effectuer un envoi de message à
l’encontre du SMSC. Cet état se termine lorsque l’un des deux entités
initie une opération de type unbind.
• La session « BOUND_RX » est l’un des états qui définit le statut et la

raison d’être de la session. Il définit que l’ESME va attendre pour la
réception de message délivré par le SMSC. Cet état se termine lorsque
l’une des deux entités initie une opération de type unbind.
• La session « BOUND_TRX » est un état qui prend en compte l’envoi et

la réception des messages.
77
C’est une alternative mise en place pour éviter l’ouverture de deux
sessions différentes pour gérer l’envoi et la réception de message. Il prend
en compte tous les types de requêtes gérées et permises par l’état
« BOUND_TX » et l’état « BOUND_RX ».
• « CLOSED » est l’état où les deux entités tentent la fermeture de

connexion.
Dans cette optique, la construction de la session même se fera en plusieurs phases :
Ǥ

• La classe SessionState est une classe qui énumère les différents types
d’états pris par une session et met à la disposition des méthodes qui
retournent des boolean pour signifier qu’une session est dans un état où il
peut recevoir ou transmettre un message.
Exemple d’instanciation : SessionState state= SessionState.OPEN ;
• La classe BindType qui présente les éventuels types de « bind » existants

et permet d’obtenir les valeurs correspondantes à chaque bind. Il permet
de connaitre la commande id correspondant lorsque le type est défini.
Exemple d’instanciation : BindTypetype= BindType.BIND_TRX ;
• Présentation des deux classes ci-dessus (cf. Annexe 9).
Ǥ

Les tâches sont les traitements de requête ou de réponse qui doivent et peuvent être
réalisées pour un état explicité. Dans cette API, il existe 17 classes qui sont utiles pour
les traitements des requêtes pendant une session entre deux entités. (ex :
Submit_Task,Receive_Task).
78
Les tâches envoient une notification à une session où elle est instanciée dans le but
de donner le résultat des opérations comme la construction d’une requête à envoyer ou le
traitement d’un PDU reçu. Elle permet de mémoriser des messages reçus ou extraire des
messages à envoyer d’une liste.
Ici, cette liste est représentée par une classe appelée Reference.
La classe Reference n’est autre qu’une classe qui permet d’enregistrer différents
paramètres qui sont employés ou extraits dans un PDU, et qui sont utiles pour une entité
(ESME ou SMSC).
Ǥ
Cette classe permet la classification d’une session en plusieurs sortes de session

définie par leur état. C'est-à-dire, il n’est plus considéré qu’une session gère plusieurs
états différents jusqu’à la clôture de celle-ci : OPEN, BOUND, CLOSED,
OUTBOUND ; mais chaque état génère un type de session approprié.
Par exemple, la classe qui hérite de celle-ci est la classe

SESSION_CLIENT_OUTBOUND.
En conclusion, une session SMPP est divisé en quatre sessions bien distinctes. Pour
qu’une session SMPP soit complète, il faut que chaque type de session soit effectué.
Voici les cas de figures qui peuvent se présenter lors d’une session SMPP :
• Session_Open puis Session.BOUND puis Session.Closed.

• Session_OUTBOUND puis Session_OPEN puis Session_BOUND et
enfin Session_CLOSED.
A noter qu’à chacune de ces cas de figure, si une demande des sessions n’est pas
valide ou comporte un problème, la Session_CLOSED peut être tout de suite appelée
pour initier une demande de fermeture de la session SMPP.
79
Ǥ ±
±
TYPE DE SESSION ETAT PROPRE CARACTERISTIQUES

SESSION_CLIENT_OUTBOUND OUTBOUND Cette classe gère les requêtes
envoyées à l’ESME par le SMSC
pour s’authentifier afin de délivrer
des messages
SESSION_SERVER_OUTBOUND OUTBOUND Cette classe permet de générer une
requête pour s’authentifier auprès
d’un ESME
SESSION_CLIENT_OPEN OPEN Cette classe permet d’envoyer des
requêtes et de recevoir des
réponses afin de décrire le type
d’opération à effectuer lors du
prochain type de session
SESSION_SERVER_OPEN OPEN Cette classe permet d’envoyer des
réponses et de recevoir des
requêtes afin de décrire le type
d’opération à effectuer lors du
prochain type de session
SESSION_SERVER_BOUND_RX BOUND_RX Cette classe permet de traiter des
réponses et d’envoyer des requêtes
pour l’envoi de message à un
ESME
SESSION_CLIENT_BOUND_RX BOUND_RX Cette classe permet de traiter des
requêtes provenant d’un SMSC et
de répondre de manière
appropriée.
SESSION_SERVER_BOUND_TX BOUND_TX Cette classe permet de traiter des
requêtes provenant d’un EME et
de répondre de manière
appropriée.
80
TYPE DE SESSION ETAT PROPRE CARACTERISTIQUES
SESSION_CLIENT_BOUND_TX BOUND_TX Cette classe permet de traiter des
réponses et d’envoyer des requêtes
pour l’envoi de message à un
SMSC
SESSION_SERVER_BOUND_TRX BOUND_TRX Cette classe permet de gérer
l’envoi et la réception de message
avec un ESME
SESSION_CLIENT_BOUND_TRX BOUND_TRX Cette classe permet de gérer
l’envoi et la réception de message
avec un SMSC
SESSION_SERVER_CLOSED CLOSED Cette classe permet de gérer la
déconnexion ou la fermeture de
connexion avec un ESME
SESSION_CLIENT_CLOSED CLOSED Cette classe permet de gérer la
déconnexion ou la fermeture de
connexion avec un SMSC
Tableau 4 : Liste des différentes sessions et leurs caractéristiques
81
Ǥ
Figure 28 : Diagramme de classes des différentes sessions*

82
ͶǤ͸ǤͷǤ
A la fin de la conception de l’API, 90 classes ont été programmées et 12400 lignes

de code ont été écrites.
ͶǤ͸Ǥ͸Ǥ
Compte tenu de la quantité trop importante des classes, quelques tests permettant
de démontrer la pertinence des résultats obtenus seront exposés dans cet ouvrage.
Ǥ
¾ Démarche :
Afin de comprendre la construction d’un paquet PDU qui représente un bind

receiver, une classe test, qui permet d’entrer les différents paramètres nécessaires pour
définir un bind receiver, a été créée. Un objet PDU contenant les informations liées à ce
dernier a été ensuite construit. Enfin, les différents paramètres entrés et le paquet
correspondant ont été affichés dans une invite de commande.
¾ Résultat :
Figure 29 : Illustration d’un paquet de PDU bind receiver
83
Le paquet suivant a été obtenu :
000280001000000014d4952494a4103138373847570424f524e45034580
- 0001 : commande id d’un bind receiver

- 4d4952494a410 : système id de l’ESME
- 3138373847570 : password de l’ESME
¾ Discussion :
De par ces valeurs, les résultats obtenus à partir des classes pour construire les
PDU sont exacts.
Ǥ °
¾ Démarche :
Une classe test, qui permet l’instanciation d’une tache afin de construire d’une
requête UNBIND pour la fermeture de session entre deux entités, a été créée. Cette classe
ne prend en paramètre que le numéro de séquence pour construire tout le paquet.
¾ Résultat :
Figure 30 : Illustration d’un paquet de PDU unbind créée par une tâche
84
Le paquet obtenu est :
00010000600000006
- 0006 : commande id qui caractérise un unbind.

- 0006 : numéro de séquence entré
¾ Discussion :
Les taches construites dans cette API fonctionnent normalement et peuvent être
immédiatement utilisées et appliquées dans un programme.
Ǥ °
¾ Démarche :
Une classe test, qui permet l’instanciation d’une session outbound pour définir et
régir les requêtes sortant de cette session, a été créée.
Le résultat attendu est la construction d’un pdu de type outbind.
¾ Résultat :
Figure 31 : Représentation d’un paquet PDU à envoyer lors d’une session outbound
85
Le paquet obtenu est :
0001e000b000000014d4952494a4103138706f74640
- 4d4952494a410 : le system id de la passerelle

- 3138706f74640 : le mot de passe de la passerelle
¾ Discussion :
Les taches construites dans cette API fonctionnent normalement et peuvent être
immédiatement utilisées et appliquées dans un programme.
ͶǤ͹Ǥ ǯǯ
ͶǤ͹ǤͳǤ
JMgatewayi OS
nitiator operation
opération Session Dispatcher
Figure 32 : Illustration des participants
Ǥ

C’est une entité appartenant à l’application qui initie l’Opération. Il

enregistre une session et un Dispatcher avec l’OS operation qui le notifie lorsque
l’opération est complète.
86
Ǥ
L’interface Session est utilisée. Elle est implémentée par l’application pour notifier
si une Opération est complète.
Ǥ
Operation est utilisée pour exécuter des requêtes (par exemple une opération entrée
sortie et l’opération sur le timer) en faveur de l’application.
Quand l’application invoque une opération, les opérations sont exécutées sans l’emprunt
du thread de contrôle de l’application. Cependant, du point de vue en perspective de
l’application, les opérations sont exécutées de manière asynchrone.
Quand ces opérations sont complètes, l’OS opération délègue les notifications au
Dispatcher.
Ǥ
Ce composant est typiquement implémenté par le système opérant. Les opérations

sont exécutées par l’OS operation.
Ǥ
Cet élément est responsable de rappeler la session de l’application lorsque des

opérations sont complètes. Quand une OS_operation termine une opération qui est initiée
de manière asynchrone, le dispatcher effectue un rappel à son avantage.
Il y a plusieurs démarches à effectuer pour toute Opération. A un certain niveau
d’abstraction, l’application initie l’opération de manière asynchrone et est notifiée quand
les opérations sont effectuées. La figure 32 présente l’interaction qui doit être exécutée
entre les participants.
87
Ǥ ±
¾ Le JMGateway initie les opérations
Pour effectuer les opérations asynchrones, l’application commence l’opération sur

l’OS_operation. Par exemple, un serveur pourrait demander au système opérant de
transmettre un paquet à travers le réseau en utilisant une connexion particulière au
socket. Pour demander une telle opération, le serveur doit spécifier le paquet à envoyer et
le réseau à utiliser. De plus, le serveur doit spécifier la Session à notifier quand
l’opération est complète et le Dispatcher qui exécute le rappel dès que le fichier est
transmis.
¾ L’OS_operation effectue l’opération
Quand l’application invoque les opérations sur l’OS_operation, elle les exécute de
manière asynchrone avec le respect des autres opérations d’une autre application. Les
systèmes moderne comme Solaris et Windows NT offre des sous-systèmes
d’entrée/sortie asynchrone avec le noyau.
¾ L’OS operation notifie le Dispatcher
Quand les opérations sont complètes, l’OS_operation récupère la Session et le

Dispatcher qui sont spécifiés à l’initiation de l’opération. L’OS_operation passe alors au
dispatcher les résultats de l’opération et aussi la session à notifier.
Par exemple, si un paquet était transmis de manière asynchrone, l’OS_operation pourrait
reporter le statut de finition (envoi réussi ou échec de l’envoi), de même que le nombre
d’octet écrit sur la connexion réseau.
¾ Le dispatcher notifie l’application
Le JMGateway notifie le dispatcher de l’arrivée d’un paquet de données puis le

dispatcher passe en revue la liste de session disponible et recherche la session
propriétaire dudit paquet ; enfin, il vérifie si un autre paquet est disponible pour lecture.
88
Voici le diagramme de séquence correspondante :
JMGateway OS_operation operation dispatcher session
enregistre (opération, session, dispatcher)

Initiation
opération
Exécution exécute
de
dispatch
Opération
terminée
Notifier la notification
session
Figure 33 : Illustration du diagramme de séquence

89

De nos jours, les applications à base de SMS est un sujet d’actualité qui peut offrir
des services à valeur ajoutée aux clients et aux opérateurs mobiles.
A partir de la conception d’une API pour l’échange de SMS basée sur le protocole SMPP
3.4, objet même de la présente étude, le programmeur peut désormais créer des
applications ayant la possibilité de communiquer avec un SMSC ou créer une passerelle
SMS, tout en utilisant une API créée à partir de la nouvelle bibliothèque java.nio.
Toutefois, il est important de noter que l’implémentation considérée comporte des
irrégularités au niveau de la phase de test.
La réalisation de ce projet a été bénéfique car cela a permis le développement de

nouvelles connaissances dans le domaine de la télécommunication. La conception de
cette API a également offert l’opportunité de mieux approfondir et de maîtriser la
programmation orientée objet ainsi que la création des programmes événementiels en
java.
Les principales difficultés rencontrées dans la réalisation de cette étude se situent

au niveau de la création de la classe session et de l’agencement des opérations entre
chaque module, car plusieurs paramètres doivent être considérés dans la gestion des
événements dont la réalisation requiert beaucoup plus de temps.
Mais en poussant la réflexion plus loin et en mettant l’accent sur l’étude des gestions
d’événements en utilisant le proactor pattern, une meilleure performance de l’application
pourrait être obtenue.
90

1. Arnaud Henry LABORDÈRE, Vincent JONACK, « SMS and MMS Interworking
in Mobil Network »
2. Cédric DE MOULIN, Marc VAN DROOGENBROECK, « Principe de base du

fonctionnement du réseau GSM »
3. Ron HITCHENS, « Java™ NIO », Edition O’Reilly, 2002, 312 p.
4. Xavier LAGRANGE, Philippe GODLEWSKI, Sami TABBANE, « Réseaux

GSM », Hermes Science
91

1. www.opensmpp.logica.com
2. www.smppapi.sourceforge.net
3. Open source and SMS gateway www.kannel.org
4. SMPP v.3.4 – http://www.smsforum.net
5. SMPP - http://en.wikipedia.org/wiki/Short_message_peer-to-peer_protocol
6. GSM 03.38 - http://en.wikipedia.org/wiki/SMS#GSM
7. Signaling System 7 (SS7) : http://www.iec.org/online/tutorials/ss7/
8. SS7 Tutorial : http://www.pt.com/tutorials/ss7/index.html
9. [SMPP3.4] SMPP protocol specificationsv3.4 SMPP Forum: http://www.smpp.org
10. [GSM23038] Alphabets and language specific information 3GPP TS 23.038

http://www.3gpp.org
11. [GSM23040] Technical realization of the Short Message Service(SMS) 3GPP TS

23.040 - http://www.3gpp.org - v5.0.0 (release 5)
12. [UCS UCS-2. ISO/IEC 10646 encoding form: Universal Character Set coded in 2
octets - http://www.unicode.org
92

93
!!"#" $%
&'()"*+"(*,+-*"!*./!0)'/!*+"(*") )(*+"(*("(('/!( (,"0'.'""(
, 1*&"*(2,,*345
Required SMPP Issued by Issued by

SMPP PDU Name
Session State ESME SMSC
bind_transmitter OPEN Yes No
bind_transmitter_resp OPEN No Yes
bind_receiver OPEN Yes No
bind_receiver_resp OPEN No Yes
bind_transceiver OPEN Yes No
bind_transceiver_resp OPEN No Yes
outbind OPEN No Yes
unbind BOUND_TX Yes Yes
BOUND_RX Yes Yes
BOUND_TRX Yes Yes
unbind_resp BOUND_TX Yes Yes
BOUND_RX Yes Yes
BOUND_TRX Yes Yes
submit_sm BOUND_TX Yes No
BOUND_TRX Yes No
submit_sm_resp BOUND_TX No Yes
BOUND_TRX No Yes
submit_sm_multi BOUND_TX Yes No
BOUND_TRX Yes No
submit_sm_multi_resp BOUND_TX No Yes
BOUND_TRX No Yes
data_sm BOUND_TX Yes Yes
BOUND_RX Yes Yes
BOUND_TRX Yes Yes
data_sm_resp BOUND_TX Yes Yes
BOUND_RX Yes Yes
BOUND_TRX Yes Yes
deliver_sm BOUND_RX No Yes
BOUND_TRX No Yes
deliver_sm_resp BOUND_RX Yes No
BOUND_TRX Yes No
query_sm BOUND_TX Yes No
BOUND_TRX Yes No
query_sm_resp BOUND_TX No Yes
BOUND_TRX No Yes
Required SMPP Issued by Issued by
SMPP PDU Name
Session State ESME SMSC
cancel_sm BOUND_TX Yes No
BOUND_TRX Yes No
cancel_sm_resp BOUND_TX No Yes
BOUND_TRX No Yes
replace_sm BOUND_TX Yes No
replace_sm_resp BOUND_TX No Yes
enquire_link BOUND_TX Yes Yes
BOUND_RX Yes Yes
BOUND_TRX Yes Yes
enquire_link_resp BOUND_TX Yes Yes
BOUND_RX Yes Yes
BOUND_TRX Yes Yes
alert_notification BOUND_RX No Yes
BOUND_TRX No Yes
generic_nack BOUND_TX Yes Yes
BOUND_RX Yes Yes
BOUND_TRX Yes Yes
!!"#"*6 %
"#"2,&"*+" (7!) #"*+"*,+-*(-'8 !)*&"*(2,,*345
!"#$%&' ()*+#, *
Size
Field Name Type Description Ref.
octets
command_length 4 Integer Set to overall length of PDU. 5.1.1

H
E command_id 4 Integer submit_sm 5.1.2
A
D command_status 4 Integer Not used. 5.1.3
E Set to NULL.
R sequence_number 4 Integer Set to a Unique sequence 5.1.4
number. The associated
submit_sm_resp PDU will
echo this sequence number.
service_type Var. C- The service_type parameter 5.2.11
max Octet can be used to indicate the
6 String SMS Application service
associated with the message.
M Specifying the service_type
A allows the ESME to
N • avail of enhanced
D messaging services such as
A “replace by service” type
T
• to control the teleservice
O
used on the air interface.
R
Y Set to NULL for default
SMSC settings.
P
A source_addr_ton 1 Integer Type of Number for source 5.2.5
R address.
A If not known, set to NULL
M (Unknown).
E source_addr_npi 1 Integer Numbering Plan Indicator for 5.2.6
T source address.
E If not known, set to NULL
R (Unknown).
S
source_addr Var. C- Address of SME which 5.2.8
max Octet originated this message.
21 String If not known, set to NULL
(Unknown).
command_id 4 Integer submit_sm 5.1.2
command_status 4 Integer Not used. 5.1.3
Set to NULL.
sequence_number 4 Integer Set to a Unique sequence 5.1.4
number. The associated
submit_sm_resp PDU will
echo this sequence number.
service_type Var. C- The service_type parameter 5.2.11
max Octet can be used to indicate the
6 String SMS Application service
associated with the message.
M Specifying the service_type
A allows the ESME to
N • avail of enhanced
D messaging services such as
A “replace by service” type
T
• to control the teleservice
O
used on the air interface.
R
Y Set to NULL for default
SMSC settings.
P
A source_addr_ton 1 Integer Type of Number for source 5.2.5
R address.
A If not known, set to NULL
M (Unknown).
E source_addr_npi 1 Integer Numbering Plan Indicator for 5.2.6
T source address.
E If not known, set to NULL
R (Unknown).
S
source_addr Var. C- Address of SME which 5.2.8
max Octet originated this message.
21 String If not known, set to NULL
(Unknown).
sm_length 1 Integer Length in octets of the 5.2.21
short_message user data.
short_message Var. Octet Up to 254 octets of short 5.2.22
0-254 String message user data.
The exact physical limit for
short_message size may vary
according to the underlying
network.
Applications which need to

send messages longer than
254 octets should use the
message_payload parameter.
In this case the sm_length
field should be set to zero.
Note:
The short message data
should be inserted in either
the short_message or
message_payload fields.
Both fields must not be used
simultaneously.
OPTIONAL PARAMETERS for SUBMIT_SM
Optional Parameter Name Type Description Ref.
user_message_reference TLV ESME assigned message 5.3.2.17

reference number.
source_port TLV Indicates the application port 5.3.2.20
number associated with the
source address of the
message. This parameter
O should be present for WAP
P applications.
T source_addr_subunit TLV The subcomponent in the 5.3.2.2
I destination device which
O created the user data.
N
A destination_port TLV Indicates the application port 5.3.2.21
L number associated with the
destination address of the
P message. This parameter
A should be present for WAP
R applications.
A
dest_addr_subunit TLV The subcomponent in the 5.3.2.1
M
destination device for which
E
the user data is intended.
T
E sar_msg_ref_num TLV The reference number for a 5.3.2.22
R particular concatenated short
S message.
sar_total_segments TLV Indicates the total number of 5.3.2.23
short messages within the
concatenated short message.
sar_segment_seqnum TLV Indicates the sequence 5.3.2.24
number of a particular short
message fragment within the
concatenated short message.
more_messages_to_send TLV Indicates that there are more 5.3.2.34
messages to follow for the
destination SME.
payload_type TLV defines the type of payload 5.3.2.10
(e.g. WDP, WCMP, etc.).
callback_num_atag TLV Associates a displayable 5.3.2.38

alphanumeric tag with the
callback number.
If this parameter is present
and there are multiple
instances of the callback_num
parameter then this parameter
must occur an equal number
of instances and the order of
occurrence determines the
O particular callback_num_atag
P which corresponds to a
T particular callback_num.
I
O source_subaddress TLV The subaddress of the 5.3.2.15
N message originator.
A dest_subaddress TLV The subaddress of the 5.3.2.16
L message destination.
P user_response_code TLV A user response code. The 5.3.2.18

A actual response codes are
R implementation specific.
A
display_time TLV Provides the receiving MS 5.3.2.26
M
with a display time associated
E
with the message.
T
E sms_signal TLV Indicates the alerting 5.3.2.40
R mechanism when the message
S is received by an MS.
ms_validity TLV Indicates validity information 5.3.2.27
for this message to the
recipient MS.
ms_msg_wait_facilities TLV This parameter controls the 5.3.2.13
indication and specifies the
message type (of the message
associated with the MWI) at
the mobile station.
number_of_messages TLV Indicates the number of 5.3.2.39
messages stored in a mail box
alert_on_msg_delivery TLV Request an MS alert signal be 5.3.2.41
invoked on message delivery.
language_indicator TLV Indicates the language of an 5.3.2.19
alphanumeric text message.
O its_reply_type TLV The MS user’s reply method 5.3.2.42

P to an SMS delivery message
T received from the network is
I indicated and controlled by
O this parameter.
N
A its_session_info TLV Session control information 5.3.2.43
L for Interactive Teleservice.
ussd_service_op TLV This parameter is used to 5.3.2.44
P identify the required USSD
A Service type when interfacing
R to a USSD system.
A
M
E
T
E
R
S
!!"#"*3 %
"#"2,&"*+"*(7!) #"*+"*,+-*1"(,/!("
!"#$%&' ()*+#, *,-& .
Size
Field Name Type Description Ref.
octets
H
E
A command_id 4 Integer submit_sm_resp 5.1.2
D
E command_status 4 Integer Indicates outcome of 5.1.3
R submit_sm request.
sequence_number 4 Integer Set to sequence number of 5.1.4
original submit_sm PDU.
message_id Var. C- This field contains the SMSC 5.2.23
B max Octet message ID of the submitted
O 9 3365 String message. It may be used at a
D later stage to query the status
Y of a message, cancel or
replace the message.
!!"#" 5%
1",1"("!) )'/! +"*& *0& ((" (2,,09:;<=>?@A<9:+@AB
!!"#" C%
1",1"("!) )'/!*+"*& *0& (("*(DEBF>GB+BG<HB?I)<JB
!!"#" K% 1",1"("!) )'/!*+"*& *0& (("*,?9A9D9G8B?L<9:
!!"#" M% 1",1"("!) )'/!*+"*& *0& (("*8B?L<9:33
!!"#" N% 1",1"("!) )'/!*+"*& *0& (("*8B?L<9:35
!!"#" O% 1",1"("!) )'/!*+"*& *0& (("*,+-
!!"#" $P% 1",1"("!) )'/!*+"*& *0& ((" ,+-QB@FB?
!!"#" $$%*1",1"("!) )'/!*+"*& *0& (("*,+-R9FI
!!"#" $6%
1",1"("!) )'/!*+"(*0& (("(*R<:F)ISB*BA (BLL<9:(A@AB
!!"#" $3%
1",1"("!) )'/!*+"*& *0& (("*R'!+*) (T
!!"#" $%&
'"('")"!* *+,!-."-/ -0/ ))"-)1(()233456)27827
!!"#" $9&
'"('")"!* *+,!-.")-"#"1(/")-."-/ -0/ ))"- :)*' +*"-:+!.
'"(,!)"--"*-."-/;<!"-."-0")-0/ ))")-=+//")
!!"#" $>&
'"('")"!* *+,!- .")- 0/ ))")- 0 !0"/?)1?'")(- "*
@"!"'+0?! 0A
!!"#" $B&
'"('")"!* *+,!- .")- 0/ ))")- )"))+,!?)"'C"'?:,<!.?*#- "*
)"))+,!?0/+"!*?:,<!.?'#
!!"#" $D&
0,."-),<'0"-(,<'-/"-*")*-."-0'" *+,!-.;<!-(.<
!"#$%&'()(*+ #*,-
"./0 1&10(22&3$4(%45678#$9 +:;414 )4$&<
"./0 1&2%(% 1&)# :&!( +&=>%$ +?&@A&($?2B<
9 +:C;414 )4$ $414 )4$&D&+4E&9 +:C;414 )4$=B-
F,&,,,,,,,,,,,,,,,&GHI;GG&6G>&6JHHGG>&6G&567&9J6K&6LH>&7H&J9MGI
9NH6&;G3GNOG;&,,,,,,,,,,,,,,&,F
FF&GHI;GG&67&PJQNH&6G PRG>SG
$414 )4$*24%>T2%4!C :=USN;NMLUB-
>T2%4!*#.%*"$ +%0+=U&UB-
>T2%4!*#.%*"$ +%0+=UGHI;GG&67&PJQNH&6G&PRG>SG&V&UW$414 )4$*?4%>T2%4!C :=BB-
FF&GHI;GG&67&SJI&6G&5L>>G&6G&PRG>SG
$414 )4$*24%5(22E#$:=UXYZYQ[UB-
>T2%4!*#.%*"$ +%0+=U&UB-
>T2%4!*#.%*"$ +%0+=UGHI;GG&67&PJQNH&6G&PRG>SG&V&UW$414 )4$*?4%5(22E#$:=BB-
FF&GHI;GG&PG&IK5G&6G&PRG>SG
$414 )4$*24%>T2%4!C%T"4=U9J;HGUB-
FF&6G8NHNINJH&6G&PL&OG;>NJH&67&5;JIJ3JPG&7INPN>G&5L;&PRG>SG
$414 )4$*24%N+%4$\(14C)4$2 #+=6(%(*>S55CO]^B-
$414 )4$*24%IJH=6(%(*Q>SCIJHCLP5_LH7SG;N3B-
$414 )4$*24%H5N=6(%(*Q>SCH5NCHLINJHLPB-
$414 )4$*24%L::$422C$(+?4=6(%(*68PICL66;C;LHQGB-
F,&,,,,,,,,&IG>I&GHOJN&GI&;G3G5INJH&,,,,,,,,,,,&,F
FF&3JH>I;73INJH&67&9788G;&3JHIGHLHI&PG&3J;5>&67&567
$414 )4$*1#+2%$.1%9#:T=B-
FF&NH>ILH3NLINJH&6R7H&J9MGI&567
567&":.D&+4E&567=$414 )4$`XB-
>T2%4!*#.%*"$ +%0+=U&UB-
FF&;GHOJN&PL&PJHQ7G7;&67&567&3;GG
>T2%4!*#.%*"$ +%0+=U&PJHQ7G7;&67&567&3;GG&G>I&GQLPG&L&V
UW":.*?4%567>%$4(!=B*$4!( + +?=BB-
FF&JH&5;GH6&PG&5La7GI&6G&567&3;GG&6LH>&7H&9788G;&5J7;&PRL88N3_G;&GI
5J7;&J9>G;OG;&PG&;G>7PILI
9T%49.\\4$&/.\XD&":.*?4%567>%$4(!=B-
>T2%4!*#.%*"$ +%0+=U UB-
>T2%4!*#.%*"$ +%0+=U&,,,,,,,,,,,,,,&PG&5La7GI&6G&567&3;GG&5J7;&7HG
;Ga7GIG&6G 9NH6&;G3GNOG;&,,,,,,,,,,,,,,UB-
>T2%4!*#.%*"$ +%0+=U&UB-
Eb 04=/.\X*b(2;4!( + +?=BB<
>T2%4!*#.%*"$ +%=N+%4?4$*%#_4c>%$ +?=/.\X*?4%=BBB-
>T2%4!*#.%*"$ +%0+=U&UB-
d
!!"#" $E&
0,."-),<'0"-(,<'-/"-*")*-."-0'" *+,!-.;<!"-* 0F"
!"#$%&'()(*+ #*9T%49.\\4$-
"./0 1&10(22&I42%7H9NH6IL>e<
"./0 1&2%(% 1&)# :&!( +=>%$ +?&@A&($?2B<
567&$42.0%D&+.00-
FF&NH>ILH3NLINJH&6R7HG&IL3_G&5J7;&PL&3;GLINJH&6R7HG&;Ga7GIG&6G&567
6G&IK5G&7H9NH6
7H9NH6CI(2f&%(2fD&+4E&7H9NH6CI(2f=gB-
>T2%4!*#.%*"$ +%0+=U&7H9NH6&IL>e&JH&5;J3G>>&UB-
>T2%4!*#.%*"$ +%0+=U&UB-
\=%(2f* 28 + 2b4:=BB<
>T2%4!*#.%*"$ +%0+=U&3JH>I;73I&5L3eGI&567&8NHN>_G6&UB-
$42.0%D&%(2f*?4%;4h.42%=B-
>T2%4!*#.%*"$ +%0+=U&UB-
FF&;G375G;LINJH&67&5La7GI&3JH>I;7NI&5L;&3GIIG&IL3_G
9T%49.\\4$&/.\D&$42.0%*?4%567>%$4(!=B-
>T2%4!*#.%*"$ +%0+=U&UB-
>T2%4!*#.%*"$ +%0+=U&L88N3_LQG&67&5L3eGI&3JH>I;7NI&5L;&3GIIG&IL3_G&UB-
>T2%4!*#.%*"$ +%0+=U&UB-
Eb 04=/.\*b(2;4!( + +?=BB<
>T2%4!*#.%*"$ +%=N+%4?4$*%#_4c>%$ +?=/.\*?4%=BBB-
>T2%4!*#.%*"$ +%0+=U UB-
d
!!"#" GH&
0,."-),<'0"-(,<'-/"-*")*-."-)+1</ *+,!-.;<!"-)"))+,!
!"#$%&'()(*+ #*9T%49.\\4$-
"./0 1&10(22&IG>IC>G>>NJHCJ7I9J7H6<
"./0 1&2%(% 1&)# :&!( +=&>%$ +?&@A&($?2B<
FF&NH>ILH3NLINJH&6R7H&J9MGI&6G&IK5G&;G8G;GH3G&a7N&3JHINGHI&PG>
NH8J;SLINJH>&HG3G>>LN;G>&5J7;&NHNING;&7HG&>G>>NJH&6G&IK5G&J7I9J7H6
;4\4$4+14&$4\4$4+14&D&+4E&;4\4$4+14=B-
$4\4$4+14*24%C2T2%4!C :C>S>3=USN;NMLUB-
$4\4$4+14*24%C"(22E#$:C>S>3=UXY"#%:UB-
FF&NH>ILH3NLINJH&67&6NI&>G>>NJH&J7I9J7H6&5J7;&GIL9PN;&7HG
3JHHGiNJH&LOG3&7H&G>SG&5J7;&PL&6GPNO;LH3G&6R7H&SG>>LQG
>S55>422 #+>4$)4$&#.%/#.+:D&+4E&>G>>NJHC>G;OG;CJ7I9J7H6=$4\4$4+14B-
>T2%4!*#.%*"$ +%0+=U&UB-
FF&L88N3_LQG&6G&PL&>NI7LINJH&NHNINLPG&6G&PL&>G>>NJH
>T2%4!*#.%*"$ +%0+=UL88N3_LQG&6G&PL&>NI7LINJH&NHNINLPG&6G&PL&>G>>NJH&V
UW#.%/#.+:*4+h. $4L1% ) %T=BB-
>T2%4!*#.%*"$ +%0+=U&UB-
FF&3JH>I;73INJH&67&567&5L;&7HG&IL3_G&NH>ILH3NG;&6LH>&PL&>G>>NJH&GI
PL&;GIJ7;HG
567&":.D&#.%/#.+:*?4%;4h.42%=B-
9T%49.\\4$&/.\D&":.*?4%567>%$4(!=B-
FF&L88N3_LQG&67&5La7GI&567&a7N&G>I&L7IJ;N>G&L&GI;G&GHOJKG&6LH>&7HG
>G>>NJH&L&PRGILI&J7I9J7H6
>T2%4!*#.%*"$ +%0+=UUB-
>T2%4!*#.%*"$ +%0+=U&L88N3_LQG&67&5La7GI&6R7H&J7I9NH6&UB-
>T2%4!*#.%*"$ +%0+=UUB-
Eb 04=/.\*b(2;4!( + +?=BB<
>T2%4!*#.%*"$ +%=N+%4?4$*%#_4c>%$ +?=/.\*?4%=BBB-
>T2%4!*#.%*"$ +%0+=UUB-
>T2%4!*#.%*"$ +%0+=UUB-
>T2%4!*#.%*"$ +%0+=U&L88N3_LQG&6G&PL&>NI7LINJH&L5;G>&I;LNIGSGHI&6G&PL
>G>>NJH&V&UW#.%/#.+:*4+h. $4L1% ) %T=BB-
>T2%4!*#.%*"$ +%0+=UUB-
>T2%4!*#.%*"$ +%0+=U&PL&>G>>NJH&G>I&5;GI&L&GHOJKG; PG&5La7GI&3N&6G>>7>&UB-
d

DEDICACES ...................................................................................................................... 4
REMERCIEMENTS........................................................................................................... 5
SOMMAIRE ....................................................................................................................... 6
LISTE DES FIGURES ....................................................................................................... 7

LISTE DES TABLEAUX .................................................................................................. 8
LISTE DES ABREVIATIONS .......................................................................................... 9
INTRODUCTION GENERALE ...................................................................................... 11
CHAPITRE I : CONTEXTE DU PROJET, OBJECTIFS, DEMARCHE ET LIMITES . 13

1.1. CONTEXTE....................................................................................................... 13
1.2. OBJECTIF GENERAL ...................................................................................... 13
1.3. OBJECTIFS SPECIFIQUES ............................................................................. 13
1.4. RESULTAT ATTENDU ................................................................................... 14
1.5. DEMARCHE ..................................................................................................... 14
1.6. LIMITES DES API ETUDIEES ........................................................................ 15
CONCLUSION PARTIELLE....................................................................................... 16
CHAPITRE II : GENERALITES SUR LE RESEAU GSM ET SES COMPOSANTS .. 17

2.1. DEFINITION ET HISTORIQUE ...................................................................... 17
2.2. ARCHITECTURE DU RESEAU GSM ............................................................ 17
2.2.1. Le sous-système radio................................................................................. 18
a. La station mobile(MS).................................................................................... 18
b. La station de base ou Base Transceiver Station ............................................. 19
c. Le contrôleur de station de base ou Base Station Controler........................... 19
2.2.2. Le sous-système réseau............................................................................... 20
a. Le centre de commutation mobile ou Mobile Switching Center.................... 20
b. L’enregistreur de localisation Nominal (HLR) .............................................. 21
c. Le centre d’authentification (AUC) ............................................................... 21
d. L’enregistreur de localisation VLR ................................................................ 22
e. L’enregistreur des identités des équipements EIR (Equipement Identity
Register) ................................................................................................................. 22
2.2.3. Le sous-système d’exploitation OSS .......................................................... 22
2.3. SERVEUR DE MESSAGE COURT (SMSC)................................................... 23
2.4. SERVICE DE MESSAGE COURT SMS (SHORT MESSAGE SERVICE) ... 26
2.4.1. Historique ................................................................................................... 26
2.4.2. Définition et description du service SMS ................................................... 26
2.4.3. Architecture du service SMS point à point ................................................. 27
2.4.4. Fonctionnement du SMS point à point ....................................................... 28
a. Le SM-MO (Short Message mobil Originated) ............................................. 28
b. Service SM-MT (Short Message Mobile Transmitted) .................................. 30
c. Explication...................................................................................................... 32
CHAPITRE III : PROTOCOLE SMPP 3.4 ...................................................................... 33

3.1. DEFINITION GENERALE DU PROTOCOLE................................................ 33
3.2. DEFINITION DU PROTOCOLE SMPP 3.4 .................................................... 33
3.3. PDU (PACKET DATA UNIT) .......................................................................... 35
3.4. DESCRIPTION DU PDU .................................................................................. 36
3.4.1. PDU Header ................................................................................................ 36
3.4.2. PDU Body................................................................................................... 37
3.4.3. Exemples de paquet de PDU ...................................................................... 38
3.5. TYPES DE SESSION POSSIBLE DANS LE PROTOCOLE SMPP ............... 39
3.5.1. Principe ....................................................................................................... 40
3.5.2. Etats de session SMPP ................................................................................ 42
3.5.3. La connexion au réseau TCP/IP ................................................................. 45
a. Historique et définition du TCP/IP ................................................................. 45
b. Architecture TCP/IP ....................................................................................... 46
c. Mode de transmission de donnée dans le TCP/IP .......................................... 47
CHAPITRE IV : DOMAINE CONCEPTUEL DU PROJET........................................... 48

4.1. APPLICATION PROGRAMMING INTERFACE(API) .................................. 48
4.2. ESME : EXTERNAL SHORT MESSAGE ENTITY........................................ 48
4.3. PASSERELLE SMS .......................................................................................... 48
4.3.1. Notion de passerelle .................................................................................... 48
4.3.2. Aperçu sur les passerelles SMS .................................................................. 49
4.3.3. Aperçu de quelques API dédiées à l’échange de SMS implémentant le
protocole SMPP 3.4 ................................................................................................... 49
a. La librairie SMPP de logica ........................................................................... 50
b. Aperçu sur la passerelle SMS Kannel ............................................................ 51
4.3.4. Analyse de Kannel et de logica .................................................................. 52
a. Kannel : limites et faiblesses .......................................................................... 52
b. API (logica) : limites et faiblesses .................................................................. 53
4.3.5. Solution préconisée ..................................................................................... 55
4.4. METHODE DE REALISATION ...................................................................... 57
4.4.1. Analyse et étude de cas ............................................................................... 57
4.4.2. Conception globale ..................................................................................... 57
4.4.3. Implémentation du système ........................................................................ 58
4.4.4. Test et qualification .................................................................................... 58
4.4.5. Mise en application ..................................................................................... 58
4.5. MISE EN ŒUVRE DES TESTS ET ETUDE DE CAS .................................... 58
4.5.1. Premier test ................................................................................................. 59
a. Résultat du test ............................................................................................... 63
b. Discussion ...................................................................................................... 63
4.5.2. Deuxième test ............................................................................................. 64
a. Connexion de Kannel avec le SMSC de logica. ............................................. 64
b. Configuration de logica .................................................................................. 64
c. Utilisation de plusieurs SMSC connectés au serveur Kannel ........................ 67
d. Résultat du test ............................................................................................... 67
e. Discussion ...................................................................................................... 67
CONCLUSION PARTIELLE....................................................................................... 68
4.6. MISE EN ŒUVRE DE LA CONCEPTION DE L’API .................................... 68
4.6.1. Construction des outils nécessaires à la construction de chaque PDU ....... 69
4.6.2. Construction de la classe ProtocolVersion ................................................. 70
4.6.3. Construction des PDU ................................................................................ 70
a. La classe PDU ................................................................................................ 70
b. La classe PDUHeader ..................................................................................... 71
c. La classe PDUBody........................................................................................ 71
d. Tableau récapitulatif des PDU à construire .................................................... 71
e. Diagramme de classes pour la construction des PDU .................................... 75
4.6.4. Construction des classes pour la construction de chaque session............... 77
a. Construction de la classe SessionState et de la classe BindType ................... 78
b. Construction des tâches correspondant à chaque type de PDU...................... 78
c. Construction de la classe abstraite SMPPSessionServer ................................ 79
d. Tableau indicatif des différents types de session existant dans cette API et
leurs caractéristiques .............................................................................................. 80
e. Diagramme de classes correspondant............................................................. 82
4.6.5. Statistiques .................................................................................................. 83
4.6.6. Tests ............................................................................................................ 83
a. Premier test ..................................................................................................... 83
b. Deuxième test ................................................................................................. 84
c. Troisième test ................................................................................................. 85
4.7. DEFINITION DES MODULES POUR L’IMPLEMENTATION DE L’API .. 86
4.7.1. La structure et les participants .................................................................... 86
a. JMGatewayinitiator ........................................................................................ 86
b. Session ............................................................................................................ 87
c. Operation ........................................................................................................ 87
d. OS operation ................................................................................................... 87
e. Dispatcher ....................................................................................................... 87
f. Explication de la séquence ............................................................................. 88
CONCLUSION GENERALE .......................................................................................... 90
BIBLIOGRAPHIE ............................................................................................................ 91
WEBOGRAPHIE ............................................................................................................. 92
ANNEXES ........................................................................................................................ 93
TABLE DES MATIERES ................................................................................................ 94

±ǯ
±
±
±±
°ǣ
±

MEMOIRE DE FIN D’ETUDES
DIPLOME D’INGENIEUR EN GENIE INDUSTRIEL
Auteurs : Année de publication :
• RAKOTOMIZAO Harifidy Mirija 2012
• RAKOTONIRINA Honoré
Nombre de pages : 90 Nombre de figures : 33 Nombre de tableaux : 04
RESUME
A l’heure actuelle, le grand public et les opérateurs de téléphonie mobile sont devenus très familier
avec le service de message court. Le rapprochement entre la télécommunication et l’informatique ne
cesse d’évoluer. Cette évolution a permis aux opérateurs d’offrir à leurs clients des services à valeur
ajoutée fondée sur la technologie SMS.
Dans ce contexte, le présent travail consiste à la création d’une API pour permettre la programmation
des applications capable d’envoyer ou de recevoir des messages courts en implémentant le protocole
SMPP.
La réalisation du projet est basée sur l’utilisation de la nouvelle librairie d’entrée/sortie java.nio, suite
à la constatation de quelques problèmes sur le traitement de flux et de la gestion de connexion
multiple clients au niveau des API. A noter que cette dernière implémente l’ancien paquetage java.io.
La seule difficulté réside dans la mise en œuvre effective du projet qui requiert beaucoup de temps et
une bonne connaissance du domaine de programmation orienté objet ; et plus essentiellement une
compréhension de la spécification d’implémentation définie par le protocole SMPP.
ABTRACT
At the present time, people and the mobile network operators themselves have become very familiar
with the shorts message service. The merger process between telecommunication and computing is
developing unceasingly. This evolution enables the mobile operators to offer to their customers worth
added services based on SMS technology. Therefore, the present work consists of creating an
Application Programming Interface (API) for creating applications that is able to send and receive
shorts messages, by implementing the SMPP protocol. The project is based on the use of the new
input / output of the java library. Finding some problems in the stream processing and management
of multiple client connection in some existing API that implements the old package java.io. The
implementation of this project requires lots of time and needs good knowledge of object-oriented
programming and fundamentally the understanding of the specification defined by the SMPP
protocol implementation.
Mots clés : SMS, SMSC, API, PDU, PDUHeader, PDUBody, Java.nio, Java.io, Protocol SMPP
3.4, Kannel, logica…

Memoire - Conception D'une API Pour L'echange de SMS Basée Sur Le Protocole SMPP 3.4

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire - Conception D'une API Pour L'echange de SMS Basée Sur Le Protocole SMPP 3.4

Transféré par

Droits d'auteur :

Formats disponibles

±ǯ

A nos chers parents,

A nos frères et sœurs,

A toute notre famille,

A tous nos amis,

Les travaux de recherche nécessaires à l’élaboration du présent ouvrage n’auraient

Tout notre respect à M. RANDRIANARY Philipe, Directeur de l’Ecole Supérieure

Nous exprimons une vive reconnaissance au Dr RAKOTOMANANA Charles

Nos sincères remerciements à l’endroit des corps enseignant et administratif de

Nous réservons une pensée au regretté M. RANDRIAMANANTENA Edmond

INTRODUCTION GENERALE ...................................................................................... 11

CHAPITRE I : CONTEXTE DU PROJET, OBJECTIFS, DEMARCHE ET LIMITES . 13

CONCLUSION GENERALE .......................................................................................... 90

Figure 1 : Architecture du réseau GSM……………………………………………….. 22

Tableau 1: Liste d’exemples de PDU…………………………………………………. 34

API: Application Programming interface

BSC: Base station controller

BTS: Base transceiver station

DOD: Department of Defense

DNS: Domain Name Service

DARPA: Defense Advanced Research Project Agency

EMI: External Machine Interface

ESME: External Short Message Entity

FTP: File transport Protocol

GMSC: Gateway Mobile Switching Center

GSM: Global Standard For Mobile

HLR: Home Location Register

HTTP: Hyper Text Transfer Protocol

IMSI: International Mobile Subscriber Identity

IP: Internet Protocol

IWMSC: Interworking Mobile Switching Center

LAN: Local Area Network

MMS: Multimedia Messaging Service

MSISDN: Mobile Station ISDN Number

MSC: Mobile Switching Center

NSS: Network Sub System

OAM: Opération d'Administration et de Maintenance

OIS: Open Interface Specification

OMC: Operation and maintenance Center

OSI: Open System Interconnection

OTA: Over The Air

PDU: Protocol Data Unit

PIN: Personal Identification Number

RSS: Radio Sub System

SIM: Subscriber Identity Module

SMS: Short Message Service

SMPP: Short Message Peer to Peer

SMSC: Short Message Service Center

SMTP: Simple Mail Transfer Protocol

TCP: Transmission Control Protocol

TCP/IP: Transfer Control Protocol/Internet Protocol

UDP : User Datagramme Protocol

VLR : Visitor Location Register

A l’heure actuelle, la technologie de la téléphonie mobile a connu une rapide

Pareillement, le type de service basé sur le message court (SMS) connait

Vu l’augmentation des besoins des utilisateurs du service SMS et l’évolution du

La connexion aux différentes plateformes du service citées ci-dessus est devenue

• Le premier chapitre mettra en exergue le contexte, les objectifs et les problèmes

• Le troisième sera basé sur l’étude approfondie protocole SMPP ;

• Le quatrième et dernier chapitre se portera sur le domaine conceptuel du projet.

En vue de la préparation du mémoire de fin d’étude dans la filière Génie Industriel,

En outre, ce projet va permettre au développeur voulant programmer des

ͳǤ͵Ǥ    

±ǯ

ͳǤ͵Ǥ

ͳǤ͸Ǥ

ʹǤͳǤ

ʹǤʹǤ

Ǥ Ø

Ǥ ǯ ± ±