REMERCIEMENTS - EC2LT

Mémoire de fin de cycle Licence 2011-2012 

AWADA Hapsita Hassan 

REMERCIEMENTS 

Avant toutes choses je tiens à rendre grâce à ALLAH Dieu le Tout Puissant, le Tout 

Miséricordieux, le Très Miséricordieux de nous avoir donné patience et courage durant ces 

longues années d’études. 

J’adresse mes sincères remerciements à : 

Tous les enseignants de l’EC2LT qui ont su nous donné une formation didactique et 

appréciable durant toute notre formation. 

Notre professeur Encadreur Docteur Samuel OUYA qui nous a ouvert les portes de 

l’EC2LT et accueillis. Pour sa disponibilité, rigueur et recommandations, ce travail est 

pour nous l’occasion de témoigner notre profonde gratitude. 

Mr Tariq DJIBALENE pour son aide, et ses conseils durant l’élaboration du travail 

Mr Boussougo Wilner Junior pour sa disponibilité et ses conseils 

Mr James Gaglo pour son appui et ses conseils 

Mr Jean DIOKH 

Mr GOUDIABY Lamine, un père pour moi 

Tonton Moussa ALI Moussa 

Mes amies Mariam Djamila SABIT Philipe, Hadjé Atimé Mahamat SANDA 

Mon frère Khalid Hussein Ali et toute sa famille 

Arafa MAHAYADINE SALAH et toute sa famille 

Mme Aicha Kounta, son mari et ses enfants 

A la promotion 2011-2012 

Toutes les personnes qui de près ou de loin ont contribué à la réalisation de ce 

mémoire 

Etude et Conception d’une solution de SMS Banking 

1



AVANT-PROPOS 

L’Ecole Centrale des Logiciels Libres et des Télécommunications (EC2LT) de Dakar 

propose un diplôme de Licence de niveau BAC+3 adapté aux secteurs des 

Télécommunications et des technologies en réseaux permettant d’acquérir une double 

compétence en réseaux et en télécommunications : le Diplôme de Licence en Réseaux et 

Télécommunications 

La formation s’étale sur trois ans. L’enseignement comporte des cours théoriques et pratiques 

ainsi qu’un stage de fin de formation de trois(3) à quatre(4) mois en entreprise ou dans un 

laboratoire. A la fin de ce stage, l’étudiant est tenu présenter devant un membre du jury un 

projet de mémoire. C’est dans cette optique que ce présent travail dont le sujet s’intitule 

« Etude et Conception d’une solution SMS Banking » a été réalisé au sein du département 

Etude de l’Entreprise RTN (Réseaux et Techniques Numériques) 

Cette société œuvre principalement dans les domaines de la gestion des projets de 

Télécommunications Réseaux et Informatiques basé sur les logiciels libres ayant trait aux 

études, conception, réalisations et planifications. 

Je tiens au terme de ce travail exprimer l’honneur qui m’est fait par les membres du jury en 

acceptant de juger mon travail. 


2



Résumé 

Le SMS Banking est une solution de services à valeurs ajoutées permettant aux clients 

d’une banque de pouvoir effectuer certaines opérations bancaires concernant son compte tel 

que consulter le solde, virement … via le Service de Message Court SMS d’un opérateur de 

réseau mobile et grâce à un simple téléphone mobile. 

Les plateformes intégrantes de ces services à valeurs ajoutées ont une partie connectée au 

réseau mobile via une pile de protocole(SS7) et l’autre partie au réseau IP. Le développement 

d’applications mobiles basées sur le SMS nécessite la mise en place d’une passerelle SMS 

permettant l’interconnexion des deux réseaux (Télécommunications et Informatique). 

Kannel est un logiciel Open Source. C’est une passerelle SMS qui peut recevoir les SMS du 

réseau GSM et les transmettre à un autre réseau (informatique). Elle supporte plusieurs types 

permettant d’interconnecter les SMSC entre eux ou le réseau GSM avec un autre réseau (IP par 

exemple). La passerelle Kannel permet donc de mettre en place des services à valeurs ajoutées. 

Abstract 

SMS Banking is a solution of value added services enables bank customers to perform 

some banking on his account as check your balance, transfer ... via the Short Message Service 

SMS from a mobile network operator and with a simple mobile phone. 

These platforms integral value added services are part connected to the mobile network 

via a protocol stack (SS7) and the other party to the IP network. The development of mobile 

applications based on SMS requires the implementation of an SMS gateway enabling 

interconnection of the two networks (telecommunications and IT). 

Kannel is open source software. This is an SMS gateway that can receive SMS GSM 

network and send them to another network (computer). It supports several types to interconnect 

them the SMSC or GSM network with another network (e.g. IP). Kannel gateway makes it 

possible to develop value-added services. 


3



TABLES DES MATIERES 

SIGLES ET ABREVIATIONS ............................................................................................8 

TABLES ET FIGURES...................................................................................................... 10 

INTRODUCTION .............................................................................................................. 12 

1.CONTEXTE GENERAL DU PROJET ............................................................................ 14 

1.1. Présentation de l’Entreprise Réseaux et Techniques Numériques ............................ 14 

1.1.1. Mission de RTN .............................................................................................. 14 

1.1.2. Domaine d’activité .......................................................................................... 14 

1.2.1. Problématique ................................................................................................. 15 

1.2.2. Objectifs .......................................................................................................... 16 

1.3. GENERALITES SUR LE MOBILE BANKING .................................................... 16 

1.3.1. La banque à distance ....................................................................................... 16 

1.4. Le mobile Banking ................................................................................................. 17 

1.4.1. Définition ........................................................................................................ 17 

1.4.2. Quelques technologies autour du mobile Banking............................................ 18 

1.4.2.1. Le STK Banking ...................................................................................... 18 

1.4.2.2. Le WAP Banking ..................................................................................... 19 

1.4.2.3. L’USSD Banking : ................................................................................... 20 

1.4.2.4. Le SMS Banking :.................................................................................... 20 

2. LE RESEAU GSM ........................................................................................................... 22 

2.1 Présentation ............................................................................................................ 22 

2.2 Architecture physique ............................................................................................. 22 

2.3 Les interfaces de communications .......................................................................... 24 

2.4 Architecture logique ............................................................................................... 25 

2.5 Architecture des protocoles au sein du réseau GSM :.............................................. 26 

2.6 Le Réseau de signalisation SS7 .............................................................................. 28 


4



3. LE CENTRE DE SERVICE DE MESSAGERIE COURT : SMSC................................. 30 

3.1 Présentation ............................................................................................................ 30 

3.2 Architecture............................................................................................................ 30 

3.2.1 Les interfaces .................................................................................................. 31 

3.2.1.1 L’interface de l’unité de signalisation (SIU)................................................. 31 

3.2.1.2 Le système OAM ......................................................................................... 31 

3.2.1.3 Le système de facturation............................................................................. 31 

3.3 Les entités externes de message court : ESME ........................................................ 32 

3.4 Qualité de service d’un SMSC ................................................................................ 33 

3.4.1 La gestion des messages :................................................................................ 33 

3.4.1.1 Les messages MO ........................................................................................ 33 

3.4.1.2 Les messages MT ........................................................................................ 34 

3.4.2 Mécanisme d’acquittements ............................................................................ 34 

3.4.3 Mécanisme de contrôle de surcharge : quelques concepts ................................ 35 

3.4.3.1 Anti-spamming ............................................................................................ 35 

3.4.3.2 Regulation de la sortie ................................................................................. 35 

3.4.3.3 La protection de l’entrée .............................................................................. 35 

3.4.4 Mécanisme de transaction :.............................................................................. 35 

3.5 Mise en œuvre du simulateur SMSC : SMPPsim .................................................... 38 

3.5.1 Présentation ..................................................................................................... 38 

3.5.2 Installation et configuration :........................................................................... 38 

3.5.3 Démarrage de SMPPsim :................................................................................ 39 

3.5.4 L’interface utilisateur : .................................................................................... 39 

4 . LE SMS AU SEIN DU RESEAU GSM .......................................................................... 41 

4.1 Présentation ............................................................................................................ 41 

4.2 Les entités de base du service SMS......................................................................... 41 

4.3 Les différents types de SMS : ................................................................................. 42 

4.3.1 Service SM-MO (Short Message Mobile Originated) ...................................... 42 

4.3.2 Service SM-MT (Short Message Mobile Terminated)...................................... 43 

4.4 Les principaux protocoles de communication ......................................................... 45 

4.4.1 Le protocole MAP ........................................................................................... 45 

4.4.2 Le protocole SMPP ......................................................................................... 46 


5



4.4.2.1 Presentation du protocol SMPP .................................................................... 47 

4.4.2.2 Description d'une session SMPP : ................................................................ 48 

5. LA PASSERELLE SMS : KANNEL................................................................................ 50 

5.1 C’est quoi une passerelle ?...................................................................................... 50 

5.2 Présentation de kannel ............................................................................................ 50 

5.3 Architecture de kannel ............................................................................................ 51 

5.4 La passerelle SMS .................................................................................................. 52 

5.5 La passerelle WAP ................................................................................................. 53 

5.6 Sécurité .................................................................................................................. 55 

5.7 Installation et configuration de kannel] ................................................................... 55 

5.7.1 Installation de kannel ....................................................................................... 55 

5.7.2 Configuration de kannel .................................................................................. 56 

1.4.3. Démarrage de la passerelle : ............................................................................ 61 

ANALYSE ET CONCEPTION DE LA SOLUTION SMS BANKING ................................ 63 

6.1 Architecture et fonctionnement ............................................................................... 63 

6.2 Exposé du problème ............................................................................................... 64 

6.3 Fonctionnalités du système SMS Banking .............................................................. 65 

6.3.1 Services d’informations à la demande .............................................................. 65 

6.3.2 Services de notification événementielle ........................................................... 65 

6.3.3 Services de notification périodiques ................................................................ 66 

6.3.4 Gestion des clients ........................................................................................... 66 

6.3.5 Gestion de la facturation .................................................................................. 66 

6.3.6 Gestion des SMS ............................................................................................. 66 

6.3.7 Etats et statisques ............................................................................................ 67 

6.3.8 Sécurité ........................................................................................................... 67 

6.4 Choix des techniques et outils utilisés ..................................................................... 67 

6.4.1 Le langage UML ............................................................................................. 67 

6.4.2 Le langage SQL .............................................................................................. 68 

6.4.3 Le langage PHP ............................................................................................... 69 

6.4.4 Merise ............................................................................................................. 69 

6.4.5 MySQL ........................................................................................................... 69 


6



6.5 Conception du Système .......................................................................................... 70 

6.5.1 Modélisation du système ................................................................................. 70 

6.5.2 Conception de la base de données .................................................................... 80 

6.6 Perspectives............................................................................................................ 84 

CONCLUSION ................................................................................................................... 85 

REFERENCES BIBLIOGRAPHIQUES .......................................................................... 87 

ANNEXES .......................................................................................................................... 89 


7



SIGLES ET ABREVIATIONS 

Nous Présentons ici certains sigles et abréviations utilisés dans le mémoire 

Abréviations Description 

SMS Short Message Service 

SGBD Système de Gestion de Base de Données 

GSM Global System for Mobile Communication 

SVA Services à Valeurs Ajoutées 

WAP Wireless Application Protocol 

STK Sim Toolkit 

HTTP HyperText Transfert Protocol 

BSS Base Station Sub-system 

NSS Network and Switching Sub-system 

OSS Opération Support Sub-system 

BTS Base Transceiver Station 

MS Mobile Station 

HLR Home Location Register 

VLR Visitor Location Register 

AUC Authentication Center 

OMC Opération and Maintenance Center 

OMC/R Opération and Maintenance Center/ Radio 

OMC/S Opération and Maintenance Center/ System 

OSI Open System Interconnexion 

LAPDm Link Access Protocol on D Mobile Channel 

SS7 System Signaling 7 

TCH Trafic Channel 

LAPD Link Access Protocol on D Channel 

MTP Message Transfert Part 

RR Radio Ressources 

MM Mobility Management 

CM Connection Management 

CC Call Control 

SS 

Supplementary Service 

SCCP Signaling Connection Control Part 

BSSAP BSS Application Part 

CSS Common Channel Signaling 

SMSC Short Message Service Center 

SMPP Short Message Peer to Peer 

ESME External Short Messaging Entity 

EMI External Machine Interface 

SUI Signaling Interface Unit 

STP Signaling Transfert Points 


8



SM MO Short Message Mobile Originated 

SM MT Short Message Mobile Transmit 

MAP Mobile Application Part 

PDU Protocol Data Unit 

UML Unified Modeling Langage 

SQL Structured Query Langage 

MCD Modèle Conceptuel de Données 

MLD Modèle Logique de Données 

EC2LT Ecole Centrale des Logiciels Libres et Télécommunications 

RTN Réseaux et Techniques Numériques 


9



TABLES ET FIGURES 

Liste des figures 

Figure 1.1 : Architecture D’une application WAP ............................................................ 19 

Figure 1.2 : Architecture d’une application USSD............................................................ 20 

Figure 1.3 : Architecture d’une application SMS ............................................................. 21 

Figure 2.1 : Architecture Générale d’un réseau GSM ...................................................... 22 

Figure 2.2 : Architecture des protocoles GSM .................................................................. 27 

Figure 3.1 : Le SMSC et GSM ........................................................................................... 31 

Figure 3.2 : Interfaces récepteur ESME ............................................................................ 32 

Figure 3.3 : Interface émetteur ESME .............................................................................. 32 

Figure 3.4 : Envoi d’un Message Court d’origine Mobile vers le SMSC ......................... 34 

Figure 3.5 : Envoi d’un message court du SMSC vers le mobile destinataire .................. 34 

Figure 3.6 : Processus d’envoi du message court d’un MO vers MT ............................... 37 

Figure 3.7 : Interface utilisateur SMPPSim ...................................................................... 40 

Figure 3.8 : Interface d’envoi d’un message de type MO ................................................. 40 

Figure 4.1 : Entités de bases du SMS ................................................................................. 41 

Figure 4.2 : Schéma détaillé de l’envoi d’un Message de type MO .................................. 43 

Figure 4.3 : Schéma détaillé d’envoi d’un message de type MT ....................................... 45 

Figure 4.4 : Le protocole SMPP ......................................................................................... 47 

Figure 4.5 : Types de messages SMPP .............................................................................. 48 

Figure 5.1 : Architecture de kannel ................................................................................... 51 

Figure 5.2 : Les modules de kannel .................................................................................... 52 

Figure 5.3 : Position logique de la passerelle SMS entre un mobile et un serveur de 

contenu. ............................................................................................................................... 53 

Figure5.4 : Position logique de la passerelle WAP entre un téléphone et un serveur de 

contenus. ............................................................................................................................. 54 

Figure 5.6 : Configuration du group core de kannel ......................................................... 56 

Figure 5.7 : Configuration du groupe SMSC pour le protocole SMPP ............................ 57 

Figure 5.8 : Configuration du groupe SMSC pour un modem GSM ............................... 57 


10



Figure 5.9 : Configuration du groupe smsbox ................................................................... 57 

Figure 5.10 : Configuration du group sendsms-user ......................................................... 57 

Figure 5.11 : Configuration du groupe sms-service .......................................................... 58 

Figure 5.12 : Configuration du group modem ................................................................... 59 

Figure 6.1 : Architecture de la solution SMS Banking ...................................................... 63 

Figure 6.3 :Diagramme des cas d’utilisations préliminaires des services à la demande de 

l’utilisateur .......................................................................................................................... 73 

Figure 6.4: Diagramme des cas d’utilisations préliminaires d’envoi de messages sous 

forme d’alertes .................................................................................................................... 73 

Figure 6.5 : Diagramme de cas d’utilisation pour une demande de solde ........................ 74 

Figure 6.6 : Diagramme de séquence système du scenario nominal de consultation de 

solde..................................................................................................................................... 77 

Figure 6.7 : Diagramme de cas d’activité de la demande de la consultation de solde ...... 77 

Figure 6.8 : Diagramme de cas d’utilisation de notification de crédit sur un compte ..... 78 

Figure 6.9 : Diagramme de séquence du scenario nominal de notification de crédit sur 

un compte ............................................................................................................................ 80 

Figure 6.10 : Diagramme de cas d’activité de notification de crédit sur un compte ........ 80 

Figure 6.11 : Le modèle Conceptuel de Données ............................................................... 81 

Figure 6.12 : le modèle Logique de données ...................................................................... 82 

Figure 6.13 : Le dictionnaire de données ........................................................................... 83 

Liste des tables 

Tableau 2.1 : Les principales interfaces de communications GSM .................................. 25 

Tableau 5.1 : Paramètres pour les services dans kannel ................................................... 58 


11



INTRODUCTION 

La révolution en matière des Nouvelles Technologies de l’information et de la 

communication donne lieu à la fusion de deux domaines qui autrefois étaient totalement 

séparés : l’informatique et la télécommunication. Cette fusion a permis la mise en place de ce 

que l’on appelle les services à valeurs ajoutées. Cependant les plateformes intégrant des 

services à valeurs ajoutées sont d’un côté connectées au réseau télécom via les protocoles de 

la pile SS7 et d’un autre coté au réseau IP permettant le développement et déploiement 

rapides d’applications. 

Le SMS Banking est une solution de services à valeurs ajoutées permettant aux utilisateurs 

d’effectuer certaines opérations bancaires via leur téléphone mobile en utilisant le service 

SMS du réseau d’opérateur. 

Dans de nombreux pays en Afrique où l’accès à l’internet est hors de prix et guère fiable, le 

SMS est devenu le moyen de communication le plus simple et accessible à tous même dans 

les zones les plus reculées. C’est ainsi les services bancaires via le téléphone mobile 

connaissent un véritable succès dans ce continent. Grace à la croissance massive de 

l’utilisation du téléphone portable, ce système se multiplie un peu partout en Afrique. C’est 

ainsi que la mise en place d’une telle application est très importante pour les opérateurs des 

réseaux mobiles, les fournisseurs de services et également aux institutions telles que les 

banques… 

Le présent mémoire dont le thème s’intitule « Etude et Conception d’une Solution de SMS 

Banking » comporte six(6) chapitres dont le 1 er Chapitre «Contexte Générale du projet » met 

le projet dans son contexte par la présentation de la structure d’accueil, des objectifs , de la 

problématique à résoudre et des différents technologies s’articulant autour du sujet » ; le 

second chapitre « Le réseau GSM » présente les différents éléments techniques d’un réseau 

d’opérateur mobile ;le troisième « Le centre de service de messagerie court : SMSC » 

présente les principaux composants d’un SMSC et son fonctionnement ,le quatrième « Le 


12



SMS au sein du Réseau GSM »,situe la place d’un SMSC dans l’architecture d’un réseau 

mobile , le cinquième « La passerelle SMS : KANNEL » fait une étude détaillée sur un 

serveur SMS kannel chargé de l’envoi et la réception des SMS du réseau GSM vers le réseau 

IP et vice versa. Enfin le dernier chapitre(6) «Analyse et Conception de la solution SMS 

Banking » présente la méthodologie suivie pour réaliser le projet, la spécification des besoins 

et des fonctionnalités du système. 

Notre travail sera achevé par une conclusion générale qui va résumer nos objectifs et les 

limites de notre réalisation tout en évoquant les améliorations envisageables. 


13



Chapitre 1 

CONTEXTE GENERAL DU PROJET 

Ce chapitre fera l’objet dans un premier temps de la présentation de la structure 

Réseaux et Techniques Numériques et définit également le contexte de notre sujet, sa 

problématique ainsi que ses objectifs et en second lieu présenter quelques technologies autour 

du mobile Banking. 

1.1. Présentation de l’Entreprise Réseaux et Techniques Numériques 

Réseaux et Techniques Numériques (R.T.N) est une société dirigée par une équipe de 

professionnels qualifiés, spécialisée en logiciels libres et centrée sur les services 

informatiques, techniques numériques et télécommunications. 

La société offre une large gamme de formations se basant sur des supports de cours, 

fruits de recherches approfondies. Ces supports testés et avérés permettent aux apprenants 

d’être aussitôt opérationnels. 

1.1.1. Mission de RTN 

La mission de RTN vise à accroître la compétitivité de ses clients par la valorisation 

des composantes informatiques, logicielles et réseaux constituants le système d'information de 

ces derniers. Cela leur confère des gains importants en produisant plus et mieux à budget 

réduit, grâce à l’exploitation de la puissance des logiciels libres existants et ceci, sans rupture 

des cycles d'exploitation de service de ces entreprises et sans remise en cause 

organisationnelle. Leur principal objectif est de conseiller et de former le personnel des 

entreprises qui veulent disposer des logiciels libres et adaptés à leurs besoins minimisant ainsi 

les coûts d' investissements en réseaux informatiques tout en leur apportant une sécurité 

avancée. 

1.1.2. Domaine d’activité 


14



La société RTN offre une palette de services dans le domaine de la technologie de 

l’information et de la communication. Les services de RTN sont orientées Open Source et 

réalisées selon les besoins et l'exploration des opportunités d'entreprise. Elles répondent par 

conséquent aux problèmes réels. 

RTN met également un accent sur le développement des services à valeurs ajoutées, et 

l’interconnexion des réseaux Linux et Windows, participant ainsi à la cohabitation et 

l’harmonisation des réseaux hétérogènes Linux-Windows. 

RTN intervient également dans les domaines suivants : 

 

Conseils et orientations professionnelles pour la gestion d’un réseau d’entreprise 

dynamique; 

 

 

Encadrement et accompagnement des personnels des entreprises; 

Mise à niveau du personnel des entreprises sur les technologies de l’information et de 

la communication ; 

RTN dispense aussi un éventail de formations dont la liste non exhaustive est la suivante : 

 

 

 

 

 

 

 

Certification Linux Professional Institute (LPI) 

Téléphonie sur IP avec le protocole SIP 

Téléphonie sur IP avec le protocole H323 

Mise en place de la ToIP avec l’IPBX open source Asterisk (SIP, SCCP, UNISTIM) 

Mise en place de la ToIP avec le Call Manager de Cisco 

Messagerie collaborative 

Les services réseaux 

1.2.Le sujet 

1.2.1. Problématique 

Consulter ses comptes à tout moment, effectuer un virement sans se déplacer, 

consulter à temps réel l’état de son compte, voilà qui confère un confort et un gain de temps 

des plus appréciables. La banque à distance est un service bancaire récent et une réalité. Elle 

tend à se développer de plus en plus, dans la mesure où elle répond à certaines attentes : celle 

de ne pas se déplacer et celle de ne pas faire la queue au guichet d’une banque dont les heures 

d’ouverture s’accordent généralement mal avec les disponibilités des clients. 


15



Avant il y avait les services bancaires via internet permettant aussi l’accès aux services 

bancaires à distance mais la plus grande limite de cette technique est l’exigence d’un PC et 

d’une connexion internet. C’est ainsi que la solution SMS Banking réduit tout le besoin du 

client à un téléphone mobile. 

La solution SMS Banking est une solution de service à valeurs ajoutées innovante des réseaux 

GSM permettant une bonne communication avec les clients (institutions financières ou 

coopérative bancaires) désirant accéder aux services bancaires sans qu’il ne soient obligés de 

se déplacer jusqu’à l’agence bancaire. Cependant, les NTIC en tant qu’outils de 

développement offre des moyens et techniques pour la mise en œuvre d’une telle application. 

Quels sont ces moyens et comment exploiter pour la mise en œuvre d’une telle solution ? 

Ce projet nous permettra de toucher le monde des télécommunications, les réseaux 

informatiques, les protocoles de transport, les langages de programmations. 

1.2.2. Objectifs 

Les objectifs du présent mémoire sont les suivants: 

‣ Etude et fonctionnement du SMS au sein du réseau GSM ; 

‣ Montrer la grande place qu’occupent les logiciels libres dans la mise en place des 

services à valeurs ajoutées en télécommunications; 

‣ Etude détaillée du réseau cœur d’un opérateur pour le développement des services à 

valeurs ajoutés; 

‣ Etude détaillée d’une passerelle SMS pour la mise en œuvre des services au sein d’un 

réseau d’opérateur téléphonique; 

‣ Développer des compétences en applications mobiles. 

1.3.GENERALITES SUR LE MOBILE BANKING 

1.3.1. La banque à distance 


16



La révolution technologique en matière d’information et de communication a permis 

de nouvelles formes de distribution de services bancaires tel que la banque à distance et a 

poussé les établissements financiers à une stratégie de distribution multi canal. 

-Le guichet automatique 

- L’Internet Banking 

-Le Fax Banking 

-Le WAP Banking 

-Le SMS Banking 

La banque à distance ou encore le E-Banking (banque électronique) peut être défini 

comme toute activité bancaire destinée à un client se déroulant à partir d’un point de service 

électronique tel qu’un téléphone, un ordinateur, un distributeur automatique de billet (DAP), 

un distributeur automatique de banque(GAB) en utilisant un système de télécommunication 

tel que le réseau téléphonique ,l’internet…[W1] 

1.4.Le mobile Banking 

1.4.1. Définition 

Le Mobile Banking Comme défini par Pousttchi & Schuring 2004 est la réalisation des 

opérations de gestion d’un compte bancaire via les réseaux de téléphonie mobile avec 

des outils mobiles (Téléphone portable, PDA). [B1] 

Les différents services bancaires offerts par une banque peuvent être classées selon la nature 

PULL ou PUSH. 

«Push» c'est quand la banque envoie des informations au client par exemple vos banques 

envoie une alerte lorsque votre solde du compte passe en dessous d'un seuil. 

«Pull» est lorsque le client demande explicitement un service ou information à la banque, par 

exemple demande des cinq dernières déclarations. 

Les banques offrent via le mobile pour la plupart des services bancaires suivant : 

informations sur le compte : 

- Mini-déclarations et la vérification de l'histoire compte 

- Alertes sur l'activité du compte ou le passage des seuils fixés 


17



- L'accès à vos relevés de carte 

les paiements et transfert : 

-transfert de fonds d’un compte à un autre 

-transfert de fonds nationaux et internationaux 

-rechargement par mobile 

-le traitement des paiements commerciaux 

 

alertes et notifications 

 

informations générales tels que les mises à jours, les nouvelles… 

1.4.2. Quelques technologies autour du mobile Banking 

1.4.2.1. Le STK Banking 

Le STK-BANKING se définit comme étant un service permettant aux clients d`un 

opérateur de téléphonie mobile d'accéder aux informations de leurs comptes bancaires via une 

application logée sur la carte SIM. La mise sur pied d'un tel service nécessite que l'opérateur 

de téléphonie signe des contrats avec diverses banques et travaille en étroite collaboration 

avec celles afin de mettre sur pied les différents composants de la plateforme. [W2] 

Les principaux composants du STK-BANKING sont : 

- Un terminal mobile GSM, doté d'une carte SIM Toolkit dans laquelle est installée 

l'application cliente. Cette application propose les différents services (demande de 

soldes, demande d'historique, demande de chéquier, etc.) aux clients via une IHM et 

sous forme de menu. Mais avant d'y accéder, l'utilisateur doit au préalable 

s'authentifier. En général, les paramètres d'authentification sont attribuer au client lors 

de son abonnement au service Toutes les communications entre le terminal mobile et 

les systèmes d'information de la banque se font via des messages courts cryptés. 

- L'application serveur assurant la fonction de passerelle entre le terminal mobile et les 

sources d'information (base de données des différentes banques). Cette application 

effectue tous les traitements sur la base de données de la banque et renvoie les 

résultats au client. Elle peut être hébergée soit chez les sources d'informations 

(banques) qui souhaitent protéger leurs données clientèles (numéros de comptes 

bancaires...) ou parce qu'elles sont reliées à plusieurs opérateurs de téléphonie mobile; 

soit chez les opérateurs qui souhaitent offrir des services spécifiques à leurs abonnés 


18



dans des domaines applicatifs trop variés pour placer une plate-forme chez chaque 

fournisseur d'information ; soit chez un tiers hébergeur de l'opérateur. 

1.4.2.2. Le WAP Banking 

Le WAP-BANKING se définit comme étant un service permettant aux clients d`un opérateur 

de téléphonie mobile d'accéder aux informations de leurs comptes bancaires via une 

application logée sur un serveur web. [W3] 

Tout comme pour le Web, les applications WAP sont conçues dans une approche client - 

serveur. Le terminal mobile incorpore un navigateur léger qui communique avec un serveur 

WAP. Les ressources des terminaux mobiles actuels étant limitées, le traitement des données 

est principalement assuré côté serveur. Ainsi pour la mise en œuvre d'un service WAP- 

BANKING, nous avons besoin de : 

- Un serveur Web disposant de contenu au format WAP. Ce serveur héberge 

l'application permettant au client de faire ses différentes demandes (demande de solde, 

demande d'historique, etc.) en direction de la banque ; 

- la passerelle ou serveur WAP : elle est chargée de convertir les données reçues en 

paquets conformes au protocole HTTP pour pouvoir dialoguer avec des serveurs Web 

et vice-versa ; 

- Le réseau de l'opérateur ; 

- L’utilisation par le client d'un terminal WAP c'est à dire qui héberge un navigateur 

WAP. Le terminal n'a d'utilité, vis à vis du WAP, que par l'existence de son navigateur 

WAP. Le navigateur se charge en effet de décoder les informations transmises par la 

passerelle WAP. 

Figure 1.1 : Architecture D’une application WAP 


19



1.4.2.3. L’USSD Banking : 

L’USSD pour Unstructured Supplementary Data Service qui peut se traduire par « 

Service supplémentaire pour données non structurées » est une fonctionnalité des téléphones 

GSM ou 3G. Il est généralement associé aux services de téléphonie de type temps réel ou de 

messagerie instantanée. Il n'y a aucune possibilité d'enregistrement et de transfert qui sont une 

caractéristique des messages courts SMS (autrement dit, un SMSC n'est pas présent sur le 

circuit de traitement). Les temps de réponse pour des services interactifs basés USSD sont 

généralement plus rapides que ceux utilisés pour SMS. [W4] 

Ce protocole de communication peut être utilisé pour de nombreux processus bancaires 

mobiles tels que les demande de solde, transfert d'argent, paiement de factures… 

Figure 1.2 : Architecture d’une application USSD 

1.4.2.4. Le SMS Banking : 

SMS (Short Messaging Service) permet aux utilisateurs d'envoyer et de recevoir des 

messages textes sur un téléphone mobile. Chaque message peut comporter jusqu'à 160 

caractères et est envoyé à des utilisateurs de réseaux d'opérateurs différents. Tous les 

téléphones portables aujourd’hui supportent le SMS. En effet, le SMS est devenu un 

phénomène mondial, avec des milliards de messages textes envoyés dans le monde chaque 

semaine. Le SMS Banking est une application bancaire permettant aux clients d’une banque 

ou coopérative bancaire d’avoir l’état de leur compte via leur téléphone portable en utilisant le 

service SMS de l’opérateur d’un réseau mobile. 


20



Figure 1.3 : Architecture d’une application SMS 

Pour développer des applications SMS, il est nécessaire de connaitre les différents 

éléments techniques d’un réseau d’opérateur mobile afin de mettre en place les services 

bancaires. Ceci fera l’objet de notre étude en ce qui concerne le fonctionnement d’un réseau 

GSM dans le prochain chapitre. 


21



Chapitre 2 

2. LE RESEAU GSM 

2.1 Présentation 

Le GSM (Global System for Mobile Communication), est un système cellulaire et 

numérique de télécommunication mobile. Il a été accepté et a vite gagné des parts de marché 

telles qu’aujourd’hui plus de 180 pays ont adopté cette norme et plus d’un milliard 

d’utilisateurs sont équipés d’une solution GSM. [B2] 

2.2 Architecture physique 

Un réseau GSM est constitué de trois principaux sous-systèmes: 

-le sous-système Radio BSS (Base Station Sub-system) 

-le sous-système Réseau NSS (Network and Switching Sub-system) 

-le sous-système d’exploitation OSS (Opération Support Sub-system) 

Figure 2.1 : Architecture Générale d’un réseau GSM 

Le sous-système radio BSS (Base Station Sub-system) 

Sa fonction principale est la gestion de l'attribution des ressources radio, indépendamment des 

abonnés, de leur identité ou de leur communication. On distingue dans le BSS : 


22



-La station de base BTS (Base Transceiver Station) 

Elle permet le dialogue avec le mobile sur l'interface Air (aussi appelée interface Radio ou 

interface Um). Ses principales fonctions sont : 

-Contrôle de la couche physique (couche 1 de l'interface radio) : transmission de la parole et 

des données… 

-Mesure des interférences sur les canaux non alloués à des communications (idle channels). 

-Mesure sur la liaison montante (uplink), servant à l'algorithme de décision du handover. 

-Calcul du Timing Advance (avance de temps) pour la synchronisation temporelle, selon la 

distance qui sépare la BTS du mobile. 

-Détection des demandes d'accès des mobiles reçus sur le canal de contrôle commun 

(RACH). 

-Détection des messages de handover access (HO ACCESS). 

-Le contrôleur de station de base BSC (Base Station Controller) 

Il assure le contrôle d'une ou de plusieurs BTS. La plupart des fonctions intelligentes de BSS 

sont implantées à son niveau, notamment les fonctions de gestion des ressources 

radioélectriques : l'allocation des canaux, la gestion de la configuration des canaux, le 

traitement des mesures et la décision de handover intra BSC. 

Le sous-système réseau NSS (Network Station Sub-system) 

Il assure principalement les fonctions de commutation et de routage. C'est donc lui qui permet 

l'accès au réseau public RTCP ou RNIS. En plus des fonctions indispensables de 

commutation, on y retrouve les fonctions de gestion de la mobilité, de la sécurité et de la 

confidentialité qui sont implantées dans la norme GSM. Il comprend : 

-Le MSC (Mobile Services Switching Center) 

C'est la partie centrale du NSS. Il prend en charge l'établissement des communications de et 

vers les abonnés GSM. Du fait de la mobilité, l'implantation de la seule fonction de 

commutation n'est pas suffisante. Le MSC gère la mobilité et les fréquences et enregistre la 

localisation des abonnés visiteurs (base de données VLR). 


23



-Le HLR (Home Location Register) est une base de données contenant :les informations 

relatives aux abonnés (données statiques : numéro d’appel, type abonnement, données 

dynamiques : état du terminal, localisation, … 

Un HLR est une référence pour tout le réseau. Il dialogue en permanence avec tous les VLR. 

Elle contient toutes les informations relatives à l'abonnement et aux droits d'accès. D'autre 

part, le HLR est une base de données de localisation. Il mémorise pour chaque abonné le VLR 

où il est enregistré. 

-Le VLR (Visitor Location Register) est une base de données locale. 

En général il y a un VLR par commutateur mobile MSC. Il Contient les informations relatives 

aux abonnés présents dans la zone associée. Il est mis à jour à chaque changement de cellule 

d’un abonné. C'est la base de données qui gère les abonnés présents dans une certaine zone 

géographique. Ces informations sont une copie de l'original conservé dans le HLR. 

-L'AuC (Authentication Center) 

Il mémorise pour chaque abonné une clé secrète utilisée pour authentifier les demandes de 

services et pour le chiffrement des communications. Un AuC est en général associé à chaque 

HLR. 

Le sous-système opérationnel OSS (Operating Sub-System) 

Il assure la gestion et la supervision du réseau. C'est la fonction dont l'implémentation est 

laissée avec le plus de liberté dans la norme GSM. La supervision du réseau intervient à de 

nombreux niveaux tels que la détection de pannes, la mise en service de sites, modification de 

paramétrage, réalisation de statistiques. 

Dans les OMC (Opération and Maintenance Center), on distingue l'OMC/R (Radio) 

qui est relié à toutes les entités du BSS, à travers les BSC, l'OMC/S (System) qui est relié au 

sous-système NSS à travers les MSC. Enfin l'OMC/M (Maintenance) contrôle l'OMC/R et 

l'OMC/S. 

2.3 Les interfaces de communications 

particulières. 

Une interface est le lien entre 2 entités du réseau, sur lequel transitent des informations 


24



Les interfaces au sein du réseau GSM sont désignées par des lettres de A à H. Ils sont 

utilisés pour la transmission du trafic (parole ou données) et pour les informations de 

signalisation. Dans le réseau GSM, les données de signalisation sont séparées des données de 

trafic. Toutes les liaisons entre les équipements sont des liaisons numériques sauf la liaison 

entre BTS et MS qui est une liaison audionumérique. 

Tableau 2.1 : Les principales interfaces de communications GSM 

Interface 

Description 

UM 

interface Air ou radio assure la communication entre BTS et MS et s’appuie 

sur le protocole LAPDm (Link Access Protocol on the D mobile Channel). 

Abis 

s’occupe de la communication entre BTS et BSC et s’appuie sur le 

protocole LAPD. 

A Entre BSC et MSC, il s’appuie sur le protocole sémaphore N°7 

B 

Entre MSC et VLR 

C 

Entre MSC et HLR 

D 

ente VLR et HLR/AuC 

E 

Entre MSC et MSC 

F 

Entre MSC et EIR 

G 

Entre VLR et VLR 

2.4 Architecture logique 

Le réseau GSM dispose de plusieurs types de canaux de transmission: 

- le canal de la voix : la voix est encodée et transmise numériquement par le réseau GSM : 

c'est le canal de téléphonie classique; 

-le canal des données: les données (issues d'un PC relié au téléphone mobile) sont encodées 

de manière différente de la voix et transmises par le réseau GSM. Les données et la voix sont 

transmises sur les mêmes canaux logiques de trafic (TCH, pour Trafic Channel) ; 

- le canal de signalisation (canal sémaphore SS7) : les messages courts transitent sur ce canal. 

Un tel canal est désigné par SDCCH, pour Stand-alone Dedicated Control Channel ; 

Les canaux logiques de trafic (TCH) permettent de transmettre la parole à 5,6 ou 13 kbit/s ou 

des données jusqu'à 12 kbit/s. Par contre les canaux logiques de signalisation (SDCCH) 

n'autorisent qu'un débit de 800 bits/s. 

De plus, à ces 2 types de canaux logiques, il est nécessaire d'associer un canal logique de 

contrôle des paramètres physiques de la liaison (SACCH, pour Slow Associated Control 


25



Channel). Ces 3 types de canaux logiques (et bien d'autres encore…) sont ensuite multiplexés 

dans des canaux physiques. 

Un canal physique est constitué de l'association d'une fréquence porteuse et d'un intervalle de 

temps dans une trame multiplexée dans le temps (TDMA, pour Time Division Multiple 

Access). Un canal physique peut supporter soit un TCH et le SACCH associé, soit huit canaux 

de signalisation SDCCH et leurs SACCH associés. 

Le réseau GSM reste conçu à la base pour transmettre le trafic vocal ainsi l'un des facteurs 

limite d'un réseau GSM est par conséquent son incapacité à transmettre des données avec une 

qualité de service acceptable. 

2.5 Architecture des protocoles au sein du réseau GSM : 

Le réseau GSM est défini à partir de couches de protocoles utilisées au niveau de différentes 

interfaces : 

-interface UM (entre le MSC et la BTS) 

-interface Abis (entre la BTS et le BSC) 

-interface A (entre le BSC et le MSC) 

Les interfaces ainsi que les protocoles qu’elles utilisent sont normalisés. 


26



Figure 2.2 : Architecture des protocoles GSM 

La structuration en couche suit le modèle OSI pour les trois premières couches : 

-la couche physique : comprend toutes les procédures nécessaires pour le transport des 

informations sur le support physique (codage, modulation…) 

-la couche liaison de données : fiabilise la transmission entre deux entités du réseau 

directement connectés entre elles (trame…) 

-la couche réseau : assure le dialogue entre toutes les entités du réseau via les messages de 

signalisation 

Couche 1: physique 

-définit l’ensemble des moyens de transmission et de réception physiques de l’information 

-sur l’interface Abis (BTS-BSC), la transmission est numérique, le plus souvent sur des voies 

64 kbps 

-sur l’interface radio Um (MS-BTS), elle est plus complexe du fait des opérations à effectuer : 

codage correcteur d’erreurs, multiplexage des canaux logiques, mesures radio… 

Couche 2: liaison de données 

-il a pour objectif de fiabiliser la transmission entre deux équipement par un protocole 

-les protocoles adoptés comportent un mécanisme d’acquittement et de retransmission (ARQ, 

Automatic Repeat Request) 

-la liaison entre la BTS et le BSC est gérée par le LAPD (Link Access Protocol on the D 

Channel) utilisé dans le réseau de données RNIS 

-entre la MS et la BTS, une version modifiée du LAPD est utilisée : le LAPDm 

Sur les interfaces UM et A, on utilise respectivement le LAPDm spécifique au GSM (Link 

Acces Protocol for D Channel modified) et le MTP niveau 2 du système de signalisation ss7 

Couche 3 : réseau 


27



Cette couche établit, maintient et libère les circuits de parole ou de données impliqués dans 

une communication. Elle comporte trois sous couches 

 

 

RR (Radio Ressources) : gère l’ensemble des aspects purement radio 

MM (Mobility Management) : prend en charge la localisation, l’authentification et 

l’allocation du TIMSI (Tempory Mobile Subscriber Identity : identité temporaire 

utilisée pour identifier le mobile dans le réseau auprès du MSC) 

CM (Connection Management) : 

Cette dernière est divisée en 3 sous couches 

- CC (Call Control) : traite la gestion des connexions de circuits avec le destinataire 

-SMS (Short Message Service) : assure la transmission et la réception de message courts 

-SS (Suplementary Services) : gère les services supplémentaires (renvoi d’appel, facturation 

(indication du montant), restriction d’appel (interdiction des appels sortants, 

internationaux…)…) 

Les messages des sous couches CM et MM transitent dans le BSS sans être pris en compte par 

la BTS et le BSC. 

L’interface A utilise les protocoles suivants : 

-le protocole MTP (Message Transfert Part) qui est divisé en trois niveau (MTP1, MTP2, 

MTP3) proches des trois premières couches du modèle OSI (couche physique, couche liaison 

de données, couche réseau). Son but est de permettre le transport et la distribution fiable des 

informations de signalisation à travers le réseau et aussi de régir aux pannes afin d’assurer 

continuellement la transmission 

Le protocole SCCP (Signaling Connection Control Part) permet de transporter les 

informations de signalisation avec ou sans connexion 

Le BSSAP (BSS Application Part) comprend deux types de protocole : le BSSMAP et le 

DTAP 

2.6 Le Réseau de signalisation SS7 


28



Les réseaux téléphoniques plus particulièrement le réseau GSM utilise des techniques 

numériques pour la transmission et l’échange de la voix et données. Cependant les nouveaux 

services offerts tel que le SMS nécessite un échange de signalisation sans établissement réelle 

d’un circuit de communication. C’est ainsi qu’il a fallu séparer la signalisation de la 

transmission et faire passer les messages de signalisation sur des liaisons spécifiques : 

« signalisation par canal sémaphore » (CSS Common Channel Signaling). [W5] 

Il est composé de : 

- Routeurs de paquets appelés points de transfert sémaphores (STP, Signaling Transfert 

Point) ; 

- Equipements terminaux appelé Point sémaphore (SP, Signaling Point) 

- Des bases de données. 

Le réseau sémaphore n°7(SS7) a pour but d’acheminer des informations de contrôle entre 

les éléments d’un réseau de télécommunication, tels que les centraux téléphoniques, les bases 

de données et les serveurs. Le réseau sémaphore SS7 est la clé pour l’introduction de services 

à valeur ajoutée. 

Pour mettre en place ce service de messages courts, l'opérateur doit prévoir un ou 

plusieurs serveurs dédiés et reliés au réseau. On appelle ce serveur le Short Message Service 

Centre (SMSC). Son rôle est de récupérer les messages envoyés afin de les redistribuer aux 

destinataires lorsque ceux-ci sont connectés au réseau. Dans le cas contraire, il stocke ces 

messages. Lorsque le mobile du destinataire peut être de nouveau localisé, le réseau notifie le 

SMSC qui est alors en mesure de relayer le message. Pour transmettre un message à un 

mobile, le SMSC utilise les services du MSC ou SGSN auquel est rattaché le destinataire. La 

livraison du message court est donc garantie même lorsque le terminal mobile est indisponible 

(lorsqu’il est éteint ou hors d’une zone de couverture radio) grâce à la fonction store-andforward 

du SMSC. Le chapitre suivant fera l’objet de l’étude d’un SMSC pour les services à 

valeurs ajoutés. 


29



Chapitre 3 

3. LE CENTRE DE SERVICE DE MESSAGERIE COURT : SMSC 


Le SMSC pour Short Message service Center ou Centre de service des messages court permet 

de gérer le transfert de message(SMS) entre téléphones mobiles. En effet, quand un abonné 

envoie un SMS vers un autre, le téléphone transmet en réalité le SMS vers le SMSC. Le 

SMSC stocke le message puis le transmet au destinataire lorsque celui-ci est présent sur le 

réseau (mobile allumé). Le SMSC fonctionne sur le mode « Store et Forward ». Il existe 

cependant un SMSC par réseau GSM. Les protocoles les plus utilisés pour la communication 

entre serveurs et SMSC en TCP/IP sont : sont SMPP (Short Message Peer to Peer) et CMG 

EMI (il y a aussi Nokia CIMD, Sema, CMPP). [B3] 

3.2 Architecture 

Le SMSC peut être relié à différentes entités externes. Il est relié au réseau mobile à travers 

l’interface de l’unité de signalisation (Signaling Interface Unit, SIU) où est implémenté le 

GMSC. Les protocoles les plus utilisés pour se connecter à l’entité externe des messages 

courts (External Short Messaging Entity – ESME): 

- SMPP (Short Message Peer to Peer) 

-EMI (External Machine Interface) 

Le SMSC se relie également aux systèmes suivants: 

- Système de facturation. 

- Systèmes d’opération, d’administration et de maintenance (OAM). 

- Système prépayé. 


30



Figure 3.1 : Le SMSC et GSM 

Le SMSC est composé de : 

-d’un système d’opération : Solaris ou linux 

-d’une base de donnée spécifique avec son serveur : il peut être par exemple de type MySQL 

-l’application SMSC 

3.2.1 Les interfaces 

3.2.1.1 L’interface de l’unité de signalisation (SIU) 

Le SMSC communique avec le reste du réseau mobile en utilisant le protocole GSM « 

Mobile Application Part » (MAP) à travers le SS7. Il peut communiquer directement 

avec les centres de commutation mobile (MSC) et le « Home Location Register » 

(HLR) afin d'envoyer et de recevoir les messages courts aux appareils mobiles. 

Il peut également communiquer avec ces éléments par le « Signaling Transfer Points » 

(STP). 

3.2.1.2 Le système OAM 

Il est formé d’un certain nombre d’interfaces qui fonctionnent le système d'opération, 

d'administration, et de maintenance (OAM). Elles permettent à un opérateur de lancer, 

configurer, et surveiller le SMSC en service dans un réseau réel. 

3.2.1.3 Le système de facturation 

Le SMSC fournit une interface de facturation qui aide l'opérateur à charger ses abonnés 

pour l'utilisation du service de message court. 


31



3.3 Les entités externes de message court : ESME 

Les interfaces ESME permettent à des applications externes non-mobiles de se connecter avec 

le SMSC. Les opérateurs et les fournisseurs de service utilisent les connections de l’entité 

externe des messages courts pour fournir aux abonnés mobiles une variété de services, 

tels qu'envoyer des mises à jour de nouvelles, des e-mails de notification, des logos, des 

sonneries, etc.… 

Chaque interface utilise un émetteur pour transmettre des messages et un récepteur pour 

recevoir des messages du SMSC. Tous les deux peuvent être sur la même connexion 

(transceiver) ou chacun utilise une connexion différente (émetteur et/ou récepteur). 

‣ Le récepteur 

Le récepteur manipule tout le trafic des messages venant du SMSC vers le ESME. 

Figure 3.2 : Interfaces récepteur ESME 

‣ L’émetteur 

Le serveur émetteur ESME reçoit tous les messages à diffuser du client ESME et les 

envoie au SMSC. 

‣ Les files d’attente de l’ESME 

Figure 3.3 : Interface émetteur ESME 

Le SMSC peut supporter 2 méthodes pour faire passer les messages au récepteur ESME : 

-La base de données 


32



Cette méthode assure qu'aucun message n'est perdu en cas de problèmes : les messages sont 

stockés dans la base de données pour être délivrés au récepteur ESME correspondant. 

Ceci est convenable dans le cas des applications à bas trafic. 

-Les Files d’attente 

Cette méthode s’est avérée utile pour des applications en temps réel (comme les 

applications vote), où un nombre énorme de messages devraient être manipulés dans une 

période très courte. Elle est rapide et elle allège le système de la charge inutile sur la base de 

données. 

3.4 Qualité de service d’un SMSC 

La qualité de service désigne la capacité d’un service à répondre par ses caractéristiques aux 

différents besoins de ses utilisateurs. 

3.4.1 La gestion des messages : 

Le réseau GSM définit plusieurs types de messages mais seulement 2 d’entre eux nous 

intéresse : 

- Message court d’origine mobile, envoyé vers le SMSC(MO) 

- Message court, envoyé par le SMSC, vers un destinataire mobile(MT) 

3.4.1.1 Les messages MO 

Le mobile d’origine écrit le SMS et l’envoie vers le mobile destinataire. Le GMSC reçoit le 

message envoyé et le transmet au SMSC. Celui-ci enregistre le SMS dans sa base de 

données pour l’envoyer après au mobile destinataire. Un acquittement sera créé pour 

informer le mobile d’origine que le message est reçu par le SMSC. Si le MO ne reçoit 

l’acquittement avant six secondes, le mobile affiche une erreur de transmission par 

défaut. 


33



Figure 3.4 : Envoi d’un Message Court d’origine Mobile vers le SMSC 

3.4.1.2 Les messages MT 

Le SMSC, ayant stocké le message reçu dans sa base de données, commence l’opération de 

transmission vers le destinataire. L’émetteur envoie le message vers le GMSC, qui, à son 

tour, l’envoie vers le mobile destinataire à travers les canaux de signalisation. Alors le 

mobile récepteur envoie un acquittement vers le SMSC pour confirmer qu’il a bien 

reçu le message. Ayant reçu l’acquittement, le SMSC efface le message de sa base de 

données pour laisser la place aux autres SMS. 

Figure 3.5 : Envoi d’un message court du SMSC vers le mobile destinataire 

3.4.2 Mécanisme d’acquittements 

Il est possible de demander à être informé de la remise correcte ou de la non-remise d’un SMS 

par un mécanisme d’acquittements. 

Le réseau peut ainsi délivrer des acquittements permettant de suivre le cheminement du SMS 

expédié : 


34



- Acquittement de réception par le réseau : message en transit. 

- Acquittement de remise au destinataire : message reçu par le mobile destinataire. 

- Avis d’erreur lorsque le SMS n’a pu être transmis au destinataire lors d’un essai du réseau : 

message en erreur, sera réexpédié. 

- Avis de non remise définitif à la fin du cycle de tentatives d’expédition ou à l’expiration de 

la durée de vie du SMS : message non remis. 

3.4.3 Mécanisme de contrôle de surcharge : 

quelques concepts 

3.4.3.1 Anti-spamming 

Pour diminuer la charge du trafic, le SMSC est muni d’un système « anti-spamming ». Ce 

système connu dans le monde des courriers électroniques, limite le nombre des 

messages envoyés à un seul destinataire et bloque ainsi tous les messages qui excèdent cette 

limite. 

3.4.3.2 Regulation de la sortie 

Le SMSC est muni d’un régulateur de sortie qui empêche de surcharger les liens de 

signalisation. Cette régulation dépend du type de message envoyé : les acquittements 

auront une priorité sur d’autres types de messages. 

3.4.3.3 La protection de l’entrée 

S'il y a un trafic de MO que le SMSC ne peut pas manipuler, les messages sont stockés dans 

une file d’attente jusqu'à une certaine limite. Quand la file d'attente se remplit, les 

messages supplémentaires entrants sont rejetés. Ceci assure que le SMSC fonctionne à sa 

capacité maximale. 

3.4.4 Mécanisme de transaction : 

Le SMSC contient plusieurs processus et des dizaines de files d’attente qui entrent en jeu lors 

de transmission de chaque message destinataire. Lorsqu’on envoie un message vers le mobile 

destinataire, le message subit l’une des transactions suivantes : 

- MO – MT 

- MO – MO-ack 


35



- MT – MT-ack 

MO-MT 

Le message envoyé du MO vers MT subit consécutivement les actions suivantes: 

1. Le mobile envoie le message court vers le GMSC. 

2. Le GMSC capte le message et l’envoie vers le SMSC. 

3. Le « SMSC RX Process » reçoit le SMS et le stocke dans la première file d’attente « RX 

MO Queue ». 

4. Le message attend son tour dans la queue des messages reçus. La discipline de 

service de cette file d’attente est FIFO, c'est-à-dire les messages accèdent au service 

dans l’ordre de leurs arrivées. 

5. Le « SMSC RX MO Process » lit le SM de sa queue, l’analyse et le remet dans une 

deuxième file d’attente « Messages Queue » 

6. Il attend son tour de nouveau dans cette dernière file où la discipline est toujours FIFO. 

7. Le processus principal « SMSC Main Process » lit le SM, le décompose de nouveau 

pour le mettre après dans une dernière file d’attente « TX Queue». 

8. Stocké dans la dernière file d’attente, le message subit une attente finale dans la queue 

d’émetteur. 

9. L’émetteur prend le message de sa queue et l’envoie vers le GMSC. L’émetteur est 

muni d’un régulateur configurable de trafic qui peut régler le nombre des messages 

envoyés vers le GMSC. 

10. Ce dernier utilise les canaux de signalisation de nouveau pour délivrer le message au 

destinataire. 

Durant tout son trajet, le SMS subit 3 attentes consécutives dans 3 types de files d’attente dans 

le SMSC : 

1. « RX MO Queue » 


36



2. « Messages Queue » 

3. « TX Queue » 

Figure 3.6 : Processus d’envoi du message court d’un MO vers MT 

MO – MO-ack 

Comme déjà expliqué, le mobile d’origine doit obligatoirement recevoir un acquittement de 

son message durant un temps bien déterminé pour ne pas afficher une erreur de 

transmission. Les actions suivantes seront concernées par ce type de transaction. 

1. Le mobile envoie le message court vers le GMSC. 


3. Le « SMSC RX Process » reçoit le SM et le stocke dans la première file d’attente « RX 

MO Queue ». 

4. Le message attend son tour dans la queue des messages reçus. La discipline de 

service de cette file d’attente est FIFO, c'est-à-dire les messages accèdent au service 

dans l’ordre de leurs arrivées. 

5. Le « SMSC RX MO Process » lit le SM de sa queue, l’analyse et le remet dans une 

deuxième file d’attente spécifique pour les acquittements« MO Ack Queue » 

6. L’acquittement attend son tour dans cette dernière file où la discipline est toujours FIFO. 

7. L’émetteur prend le message de sa queue et l’envoie vers le GMSC. 

8. Le GMSC, à son tour, l’envoie vers le mobile d’origine. 


37



Dans ce cas, le message passe par 2 files d’attente : 

1. « RX MO Queue » 

2. « MO Ack Queue » 

MT – MT-ack 

Le SMSC doit recevoir un acquittement de la part du mobile destinataire pour pouvoir 

effacer le message de sa base de données et laisser par suite de la place pour d’autres 

messages. Les actions suivantes seront le sujet ce type de messages. 

1. Ayant reçu le message, le destinataire crée l’acquittement MT-ack et l’envoie vers le 

GMSC. 


3. Le « SMSC RX Process » reçoit le SM et le stocke dans la seule file d’attente pour 

ce type de message « RX MT Queue ». 

4. L’acquittement attend son tour dans cette file où la discipline de service est FIFO. 

5. Et Finalement, le « SMSC RX MT Process » le prend, le vérifie et efface le SMS 

correspondant de sa base de données. 

L’acquittement MT-ACK passe par une seule file d’attente qui est la « RX MT Queue ». 

L’analyse de ce type de message est très important afin d’améliorer la performance du 

SMSC, car le SMS ne sera jamais effacé de la base de données avant la réception du MT-ack. 

Par suite le système ne peut pas le remplacer par un nouveau message. 

3.5 Mise en œuvre du simulateur SMSC : SMPPsim 

3.5.1 Présentation 

SMPPsim est un outil de test destiné à être utilisé par les développeurs d'applications SMS. Il 

simule un SMSC (Short Message Service Centre), qui dispose d'une interface SMPP qui peut 

être utilisé par des applications logicielles pour envoyer et recevoir des messages texte SMS. 

SMPPsim est gratuit, open source et utilisé par des milliers d'utilisateurs partout dans le 

monde. 

3.5.2 Installation et configuration : 


38



-Télécharger le paquet SMPPsim.tar.gz : http://www.seleniumsoftware.com 

-Décompressez-le dans un répertoire. La racine contient le fichier startsmppsim.sh qui permet 

de lancer le simulateur. Le répertoire conf contient le fichier smppsim.props qui permet de 

configurer le simulateur. Il y a de nombreuses options, les principales étant : 

#Le port d’ecoute SMPP 

SMPP_PORT=2775 

#login et mot de passe pour les accès SMPP 

SYSTEM_ID=smppclient 

PASSWORD=password 

#le port d’écoute du serveur web pour l’administration et la simulation 

#d’envoi à partir d’un terminal 

HTTP_PORT=88 

Pour démarrer le SMSC on tape la commande comme suit : 

3.5.3 Démarrage de SMPPsim : 

./startsmppsim.sh (Voir Annexe 5) 

3.5.4 L’interface utilisateur : 

SMPPsim possède une interface utilisateur basée sur le Web qui fournit des informations 

détaillées sur les PDU envoyés et reçus. Pour l’accès à l'interface utilisateur, on spécifie 

d’abord le port dans le fichier de configuration via le paramètre HTTP_PORT. 

L'adresse suivante permet d’accéder à l'interface utilisateur SMPPsim : http://localhost:88 

Les captures d’interfaces utilisateurs : 

La page d’accueil : 


39



MO Injection page : 

Figure 3.7 : Interface utilisateur SMPPSim 

Figure 3.8 : Interface d’envoi d’un message de type MO 

Dans ce chapitre nous avons exposé les principaux éléments d’un Centre de Service de 

Messagerie Court et étudier son fonctionnement. Ce composant technique nécessaire au 

traitement des messages courts est très important dans la mise en place des services à valeurs 

ajoutée au sein d’un réseau mobile. Dans le prochain chapitre, nous allons voir quels sont les 

différents types de SMS gérés par le SMSC, étudier le fonctionnement du service de message 

court et les principaux protocoles pour la mise en œuvre du service SMS. 


40



Chapitre 4 

4 . LE SMS AU SEIN DU RESEAU GSM 


Le SMS pour Short Message Service est le service de message court offert par le réseau GSM 

permettant de composer un message textuel d’au plus de 160 caractères à partir de son 

téléphone mobile. Ces messages émis et reçus sont véhiculés par le réseau de signalisation 

sémaphore n°7 (SS7). Ils sont soit transmis directement au terminal destinataire du message 

(si celui-ci est allumé), soient stockés dans le serveur de message courts (SMSC, pour SMS 

Center) par lequel ils transitent. 

Les messages courts ne circulent pas dans les mêmes canaux logiques que la voix ou les 

données si bien qu'il est possible pour un utilisateur en communication téléphonique (avec un 

autre correspondant) de recevoir des messages courts simultanément. [W7] 

4.2 Les entités de base du service SMS 

Figure 4.1 : Entités de bases du SMS 

• Gateway MSC For Short Message Service (SMS-GMSC) : Il s’agit d’une fonction capable 

d’une part de recevoir un message court d’une entité SMSC et d’interroger le HLR afin de 

déterminer la localisation de la station mobile destinataire et d’autre part de délivrer le 

message court au MSC auquel est rattachée cette station mobile destinataire. Ce MSC de 

rattachement est aussi appelé VMSC (Visited MSC). 


41



• Interworking MSC For Short Message Service (SMS-IWMSC) : Il s’agit d’une fonction 

capable de recevoir un message court d’un MSC et de le soumettre à un SMSC. 

• Short Message Service Centre (SMSC) : Cette fonction est responsable du stockage 

/relayage d’un message court. 

• Short Message Entity (SME) est une entité extérieure au réseau GSM pouvant émettre/ 

recevoir des messages courts. Il s‘agit d’un serveur spécialisé ou d’un micro-ordinateur. 

Le SMSC comporte une interface coté réseau GSM reposant sur le protocole de signalisation 

MAP et une interface coté ESME utilisant le protocole SMPP. Les messages MAP sont 

transportés par le réseau SS7. 

4.3 Les différents types de SMS : 

Le service message consiste en deux types de services de base : 

SM MO (Short Message Mobile Originated): c’est le type de sms envoyé par un 

utilisateur mobile vers le SMSC 

SM MT (Short Message Mobile Terminated): c’est le type de sms envoyé par le smsc 

vers l’utilisateur mobile 

4.3.1 Service SM-MO (Short Message 

Mobile Originated) 

Avec le service SM-MO, la station mobile envoie un message court au SMSC 

Lorsque l'utilisateur mobile souhaite envoyer un message court, il doit indiquer l’adresse du 

destinataire et l’adresse du SMSC. 

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. 


42



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. 

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. 

Figure 4.2 : Schéma détaillé de l’envoi d’un Message de type MO 

4.3.2 Service SM-MT (Short Message 

Mobile Terminated) 

Avec le service SM MT, une station mobile reçoit un message court du SMSC. L’émetteur du 

message peut être une autre station mobile ou toute entité externe au réseau (ex :ESME). 

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, informations qui 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. 


43



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(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 de 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. 

7. Le MSC effectue la procédure de paging sur la zone de localisation du destinataire. 

8. La station mobile destinataire répond positivement. 

9. 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. 

10. Le MSC achemine le message court au destinataire via le message SMS-DELIVER et 

reçoit un acquittement SMS-STATUS-REPORT. 

11. Le MSC inclut ce rapport dans la réponse MAP-MT-FORWARD-SHORT-MESSAGEack 

retourné au SMS-GMSC. 

12. Le SMS-GMSC passe le rapport au SMSC. 


44



Figure 4.3 : Schéma détaillé d’envoi d’un message de type MT 

Si la station mobile destinataire est hors tension, la réponse retournée par le HLR (3) indique 

cette cause. Par ailleurs le HLR introduit le numéro MSISDN du destinataire dans un fichier 

de données des messages en attente (MWD File, Message Waiting Data File). MWD consiste 

en une liste d’adresses de SMSC ayant des messages en attente de livraison à la station mobile 

destinataire. 

Lorsque la station mobile destinataire est mise sous tension, elle se rattache (IMSI Attach) 

auprès d'un MSC/VLR visité. Ce dernier en informe à son tour le HLR correspondant. Si le 

numéro MSISDN de la station mobile qui s’est rattaché est présent dans le fichier de données 

des messages en attente, le HLR envoie une notification MAP-ALERT-SERVICE-CENTER 

au SMS-GMSC pour lui demander d’informer le SMSC de la présence du destinataire ; le 

SMSC relance alors complètement la procédure SM-MT (Figure 4.3). 

4.4 Les principaux protocoles de communication 

4.4.1 Le protocole MAP 

Le protocole MAP (Mobile Application Part) régit l’ensemble des échanges entre 

équipements du réseau mobile (NSS, Network Subsystem). Il offre les fonctions de 

signalisation nécessaires à un service de communication voix ou données dans un réseau 

mobile. Il s’appuie sur la pile de protocole SS7 qui garantit un transport fiable. Le protocole 

MAP concerne les dialogues entre différentes entités du réseau mobile notamment, 

MSC/VLR, MSC Server, SGSN, HLR, EIR, SMSC, etc. Le service SMS s'appuie sur le 

protocole MAP. MAP permet le transport du SMS du MSC de l'émetteur au SMSC, 


45



l'interrogation du SMSC au HLR pour identifier le MSC du destinataire, puis le transport du 

SMS du SMSC au MSC du destinataire. [W7] 

Les messages MAP relatifs au service SMS sont : 

MAP-SEND-ROUTING-INFO-FOR-SMS: Ce service est utilisé entre le SMSC et le HLR 

afin que le SMSC obtienne l’information de routage lui permettant d’acheminer le message 

court au MSC, MSC Server ou SGSN auquel est rattaché le destinataire. 

MAP-MT-FORWARD-SHORT-MESSAGE : Ce service est utilisé entre le SMSC et le 

MSC, MSC Server ou SGSN afin de délivrer le message court. 

MAP-REPORT-SM-DELIVERY-STATUS : Ce service est utilisé entre le SMSC et le 

HLR. Il permet de positionner les données MWD (Message Waiting Data) dans le HLR 

lorsque le message n’a pas pu être délivré au destinataire ou d’informer le HLR du transfert 

avec succès du SMS. Ce service est invoqué par le SMSC. 

MAP-READY-FOR-SM : Ce service est utilisé entre le VLR et le HLR ou entre le SGSN et 

le HLR. Le VLR ou le SGSN utilise le service soit parce que le mobile a de nouveau une 

mémoire disponible pour recevoir des SMS soit parce que le mobile a de nouveau un contact 

radio avec le MSC ou SGSN alors que le fanion Message Waiting est positionné au niveau du 

VLR ou du SGSN. 

MAP-ALERT-SERVICE-CENTRE : Ce service est utilisé entre le HLR et le SMSC. Le 

HLR initie ce service si le HLR détecte qu’un usager, dont le MSISDN est dans le fichier 

Message Waiting Data, est de nouveau joignable ou si le mobile a de nouveau de la mémoire 

disponible pour recevoir le SMS. 

MAP-INFORM-SERVICE-CENTRE : Ce service est utilisé entre le HLR et le SMSC afin 

que le HLR informe le SMSC que son adresse SS7 (titre global) est stockée dans le fichier 

Message Waiting Data. 

4.4.2 Le protocole SMPP 

Les protocoles les plus utilisés pour la communication entre les serveurs et les SMSC dans un 

réseau TCP/IP sont : SMPP et EMI. On peut trouver d’autre protocoles utilisées par un SMSC 

mais nous ne rentrerons pas en détails, nous allons nous limité sur le protocole SMPP qui est 

le plus utilisé par les opérateurs téléphoniques. 


46



4.4.2.1 Presentation du protocol SMPP 

Le protocole « Short Message Peer to Peer » (SMPP) est un protocole binaire de niveau 7 

conçu pour fournir une interface flexible de transmissions des messages courts SMS entre le 

SMSC (Centre de service de message courts) et un système SMS d'application comme 

un serveur WAP Proxy Server, Email Gateway ou autre type de Message Gateway. En 

employant le protocole SMPP, un système d'application SMS appelé « External Short 

Message Entity » ou ESME, peut amorcer une connexion sur la couche application avec un 

SMSC sur une connexion TCP/IP ou X.25 et peut permettre l'envoi et la réception de SMS 

depuis et vers un SMSC. [W8] 

Figure 4.4 : Le protocole SMPP 

Le protocole SMPP est basé sur l'échange de requêtes et réponses PDU (Protocol Data Unit) 

entre l’ESME et le SMSC sur un réseau TCP/IP sous-jacent ou une connexion réseau X.25. 

Les messages échangés entre un ESME et un SMSC via SMPP sont de 3 types : 

· ESME Transceiver : Message envoyé de l'ESME (Emission) au SMSC et du SMSC à 

l'ESME (Réception). 

· ESME Transmitter : Message envoyé de l'ESME (Emission) au SMSC. 

· ESME Receiver : Message envoyé du SMSC à l'ESME (Réception). [B4] 


47



Figure 4.5: Types de messages SMPP 

Le schéma de fonctionnement typique d’une application est le suivant : l’application se 

connecte sur le SMSC et les échanges de paquets SMPP (Packet Data Unit) peuvent 

commencer dans un sens comme dans l’autre. 

Les paquets TCP entre le ESME et le SMSC sont appelés PDU (Protocol Data Unit). Les 

types suivant de PDU sont utilisés dans les connexions SMPP 

-Session Management PDU : s’occupe de la connexion, du maintien et de la déconnexion 

d’une session 

-Message Submission PDU : envoi des messages vers un téléphone mobile 

-Message Deliver PDU : s’occupe de la livraison des messages au client SMPP(ESME) 

-Ancillary Operation PDU : requête d’annulation et de remplacement des messages. 

Lors des échanges SMPP, un système ID pour l’authentification et l’identification est utilisé 

pour la connexion entre un client ESME et SMSC : 

Submit_sm: utiliser pour l’envoi des messages à partir du client vers le SMSC(MT). Ce 

paquet contient les informations concernant l’expéditeur, le destinataire et le corps du 

message. 

Deliver_sm : ce paquet est utilisé lors de la livraison d’un message au client(MO). Il contient 

les informations sur l’expéditeur du message et le corps du message. 

Query_sm : ce paquet est utile pour les rapports de livraisons 

Enquire_link : vérifie l’état de la connexion d’une session 

Unbind : utilisé pour mettre fin à une session et déconnecter la connexion TCP/IP 

4.4.2.2 Description d'une session SMPP : 

Une session SMPP entre un SMSC et un ESME est initiée par l'ESME qui établit en premier 

une connexion réseau avec le SMSC et ensuite édite une requête de connexion SMPP pour 

ouvrir une session SMPP. 

La session SMPP peut être définie par ces différents états : 


48



OPEN : Un ESME a établi une connexion avec le SMSC mais n'a pas encore publié sa 

requête. 

BOUND_TX : Un ESME connecté a fait une demande de connexion (ESME Transmitter) en 

publiant un bind_transmitter et reçoit une réponse de la part du SMSC qui autorise sa requête 

de connexion. Un ESME relié comme un Transmitter peut envoyer des SMS à un SMSC qui 

ensuite vont être envoyés à un portable ou un autre ESME. 

BOUND_RX : Un ESME connecté fait une demande de connexion (ESME Receiver) en 

publiant un bind_receiver et reçoit une réponse de la part du SMSC qui autorise sa requête de 

connexion. Un ESME relié comme un Receiver peut recevoir des SMS d'un SMSC (l'origine 

d'envoi de message peut être un portable, un autre ESME ou SMSC). 

BOUND_TRX : Un ESME connecté fait une demande de connexion comme un ESME 

Transceiver en publiant un bind_transceiver et reçoit une réponse de la part du SMSC qui 

autorise sa requête de connexion. Un ESME relié comme un Transceiver supporte toutes les 

opérations supportées par un ESME Transmitter et un ESME Receiver. 

ESME connecté comme transceiver peut envoyer les SMS vers un SMSC. Les SMS sont 

ensuite envoyés vers un portable ou vers un autre ESME. Egalement, dans ce cas, l'ESME 

peut recevoir un SMS provenant d'un portable, d'un autre ESME ou de SMSC lui-même. 

CLOSED : L'ESME est déconnecté du SMSC et la connexion réseau est fermée. Le SMSC 

est alors déconnecté de l'ESME. 

Pour mettre en place des services basés sur le SMS il est nécessaire d’avoir une 

passerelle sms capable de relayer les messages du réseau GSM vers le réseau IP .Ceci fera 

l’objet de notre étude sur la passerelle SMS Kannel dans le chapitre suivant 


49



Chapitre 5 

5. LA PASSERELLE SMS : KANNEL 

5.1 C’est quoi une passerelle ? 

Une passerelle est un outil qui permet de passer d’un système à un autre. Elle permet 

d’interconnecter des systèmes informatiques ayant des architectures différents ou des 

protocoles différents. 

L'une des difficultés de la messagerie SMS est que les SMSCs sont gérés par des 

protocoles de communication propriétaires. En d'autres termes, il n'a pas existé de 

normalisation à proprement parlé, par exemple, un SMSC de type NOKIA qui a une interface 

géré par le protocole CIMD ne saurait échanger directement avec un SMSC d'un autre réseau 

opérateur dont l'interface est géré par le protocole EMI. Pour pallier à ce problème, une 

passerelle SMS est placée entre ces deux SMSCs. 

En effet, la passerelle SMS agit comme un convertisseur de protocoles entre non 

seulement des SMSCs, mais aussi avec des dispositifs du protocole TCP/IP. Il en existe une 

multitude dont certaines sont propriétaires (Alligata, Ozeki SMS, Wapme, Jataayu SMS 

gateway.), tandis que d'autres sont libres (Kannel, Gammu, ...). La multitude de protocoles de 

communication avec les SMSCs, que la solution « Kannel » prend en compte, en même temps 

que sa fonction de serveur SMS, sans oublier la qualité et la stabilité des solutions libres en 

général, pour ne citer que ceux-là, sont quelques-unes des raisons qui nous ont conduites à 

porter notre choix sur elle. 

5.2 Présentation de kannel 

Kannel est une passerelle SMS et WAP open source et gratuit. Kannel est 

actuellement disponible pour les systèmes Linux (Redhat et Debian). Lancé en mars 1999, 

le projet est à l’initiative de la compagnie Finlandaise WAPIT. Kannel a été reconnue en 

mars 2001 lorsqu’il a été certifié par WAP Forum en tant que première passerelle WAP 1.1 


50



dans le monde. C'est un outil très intéressant pour développer des applications en 

collaboration avec le serveur Apache. [W9] 

5.3 Architecture de kannel 

La passerelle possède trois interfaces chacune ne pouvant communiquer qu’avec un 

type d’équipement spécifique : 

- Les centres SMS (SMSC), utilisant divers protocoles. 

- Les serveurs HTTP, pour les contenus WAP et SMS. 

- Les terminaux WAP, implémentant la pile de protocole WAP. 

Figure 5.1 : Architecture de kannel 

Kannel est conçu pour pouvoir communiquer avec plusieurs SMSC utilisant des 

protocoles différents. 

Chaque compte SMSC est acheté auprès d’un opérateur mobile. A chaque compte correspond 

aussi un numéro vers lequel sont acheminés les messages destinés au compte et 

apparaît comme le numéro expéditeur lorsqu’un message est envoyé à partir de ce compte 

(n’empêche que certaines connections permettent à l’usager de spécifier lui-même le numéro 

de l’expéditeur). 

Kannel divise ses différentes fonctions selon trois processus appelés « boxes » basé 

essentiellement sur le type d’équipement externe avec lequel il veut dialoguer. : 

- Le bearerbox implémentant le niveau porteur du WAP (couche WDP).Il permet entre autre 

la connexion aux différents SMSC. 


51



- Le smsbox implémentant l’essentiel des fonctionnalités de la passerelle SMS. Il reçoit 

les messages texte depuis le bearerbox et les interprètes comme des requêtes vers des services 

et y répond en utilisant le chemin approprié. 

- Le wapbox qui implémente la pile de protocole WAP et le WAP Push (protocole de 

niveau applicatif).Quand 

le wapbox est utilisé pour le « pushing », il est appelé PPG 

(Push Proxy Gateway). L’autre moyen d’envoi de donnée étant le « pulling » [B5] 

Figure 5.2 : Les modules de kannel 

Notons qu’il n’est possible de mettre en place qu’un seul bearerbox tandis qu’il est 

possible de disposer de plusieurs wapbox et de smsbox. Disposer de plusieurs wapbox et 

smsbox peut s’avérer bénéfique surtout lorsque la charge est très importante. 

5.4 La passerelle SMS 

Le SMS (Short Messaging Service) est un moyen d’envoi de messages courts (160 

caractères) à partir d’un mobile GSM vers un autre. Il permet, en plus de l’envoi de texte 

simple, d’envoyer des contenus avancés comme 

les logos d’opérateurs, les sonneries 

d’appels, les cartes d’affaires et les configurations de mobiles. 

Les services SMS sont des services 

initiés par des messages SMS envoyés à partir d’un 

mobile GSM vers un numéro de téléphone (le plus souvent court) et ses services 

répondent 

souvent aux requêtes qui leurs sont adressées en retournant un contenu. 

Pour solliciter un service, un mobile GSM envoie un message SMS à un numéro court, cette 

dernière pointe vers un centre SMS précis. Le centre SMS envoie le message à son 

destinataire en utilisant un protocole spécifique. Par exemple un centre SMS Nokia utilise le 

protocole CIMD. 


52



En pratique chaque SMSC utilise un protocole qui lui est propre, une passerelle SMS est 

utilisée pour rendre possible la connexion entre différents SMSCs. Le grand apport de Kannel 

est de translater chaque protocole SMSC vers le protocole HTTP, ce qui simplifie le 

déploiement des services. 

Figure 5.3 : Position logique de la passerelle SMS entre un mobile et un serveur 

de contenu. 

Une passerelle SMS peut aussi être utilisée pour relayer les messages SMS du réseau 

GSM vers un autre type de réseau. Kannel fonctionne comme une passerelle SMS, 

pouvant communiquer avec plusieurs types de SMSC et routant les messages qu’il reçoit 

vers des fournisseurs de contenus, sous forme de requêtes HTTP. Ces 

fournisseurs de 

contenus répondent à la requête et la réponse est retournée au mobile avec la connexion 

au SMSC requis et le protocole requis. 

En plus du fait de servir les SMS-MO (provenant du mobile), Kannel fonctionne aussi 

comme une passerelle « push », les fournisseurs de contenus peuvent demander à 

Kannel d’envoyer des messages aux terminaux. Kannel va alors déterminer le bon SMSC 

vers lequel transiter le message en utilisant 

encore le protocole requis. De ce fait les 

fournisseurs de contenus n’auront pas à connaître un protocole SMSC mais juste 

l’interface de Kannel vers laquelle ils enverront le message. 

5.5 La passerelle WAP 

Le WAP (Wireless Application Protocol) est une collection de divers langages, 

outils et une infrastructure pour mettre en application des services pour des téléphones 

portables. Le WAP permet de mettre en application des services semblables au World Wide 

Web. Cependant, le WAP n'apporte pas la teneur existante de l'Internet directement au 

téléphone. Il y a trop de problèmes techniques et autres pour que ceci ne se fasse 

correctement. Le problème principal est que le contenu d'Internet est principalement sous 

forme de pages de HTML, et ils sont écrits de telle façon qu'ils exigent les raccordements 


53



rapides, les unités de traitement rapides, les grandes mémoires, les grands écrans, la 

sortie audio et souvent également les mécanismes assez efficaces d'entrée. 

En plus, les téléphones portables ont des processeurs très lents, la mémoire très petite, 

la largeur de bande insondable et intermittente, et les mécanismes extrêmement maladroits 

d'entrée. La plupart des pages existantes de HTML ne fonctionne pas sur des téléphones 

mobiles, et ne le feront jamais. 

WAP définit un langage complètement nouveau le Wireless Markup Language 

(WML), qui est plus simple et beaucoup plus strictement définie que le HTML. Il définit 

également un langage de script, WMLScript, que tous les navigateurs doivent avoir pour le 

supporter. Pour rendre des choses encore plus simples pour les téléphones, il définit même 

son propre format à mémoire d'image (Wireless Bitmap, ou WBMP). 

Le HTTP est également trop inefficace pour l'usage sans fil. Cependant, en 

employant un format binaire et compressé sémantiquement semblable il est possible de 

ramener les frais généraux de protocole à quelques octets par demande, au lieu des 

centaines habituelles d’octets. Ainsi, WAP définit une nouvelle pile de protocole à employer. 

Cependant, pour rendre des choses plus simples également pour les personnes mettant en 

application réellement les services, WAP présente un passage entre les téléphones et les 

serveurs fournissant le contenu aux téléphones. 

Figure5.4 : Position logique de la passerelle WAP entre un téléphone et un serveur de 

contenus. 

La passerelle WAP communique avec le 

téléphone en utilisant une pile de 

protocole WAP, et traduit les demandes qu'il reçoit en HTTP normal. Ainsi les fournisseurs 

de contenu peuvent utiliser tous les serveurs de HTTP et utiliser le savoir-faire existant 

au sujet de l'exécution et de l'administration de service de HTTP. 


54



En plus des traductions de protocole, la passerelle compresse également les pages 

WML dans une forme plus compacte, pour sauver la largeur de bande Over-The-Air et pour 

réduire plus loin les conditions de traitement du téléphone. Il compile également des 

programmes de WMLScript dans un format bytecode. Les dernières caractéristiques du 

WAP définissent 

quelques conversions additionnelles que Kannel commence à mettre en 

application. Kannel n'est pas simplement une passerelle WAP. Il fonctionne également 

comme passerelle SMS. Bien que le WAP soit la technologie chaude et techniquement 

supérieure, les téléphones SMS existent en grand nombre et les services SMS sont ainsi 

tout à fait utiles. Par conséquent, Kannel fonctionne simultanément comme passerelle WAP et 

SMS. 

5.6 Sécurité 

En ce qui concerne l'accès à distance au bearerbox kannel utilise SSL pour les 

transactions sécurisées entre le bearerbox et les smsbox et wapbox auxquels il est connecté. 

L’administration à distance peut également être assurée grâce à une connexion sécurisée. 

L’accès des utilisateurs à la passerelle peut être entièrement sécurisé et contrôler en 

spécifiant des utilisateurs avec mot de passe dans le fichier de configuration. De ce fait tout 

utilisateur décidant d'envoyer un SMS, par exemple, devra au préalable s'identifier. 

5.7 Installation et configuration de kannel] 

5.7.1 Installation de kannel 

Préréquis : 

-compilateur: gcc-c++ 

-Bibliothèque offrant le support XML et HTML : libxml2 libxml2 

-GNU bison 

-GNU autoconf 

-GNU make. 

Le code source de kannel pour le téléchargement est disponible sur le site: 

http://www.kannel.org/download/1.4.1/gateway-1.4.1.tar.gz 

- Décompresser le fichier dans le répertoire /usr/local/ 


55



tar -xvzf gateway-1.4.1.tar.gz -C /usr/local/ 

- Se positionner sur le répertoire /usr/local/gateway-1.4.1/ et compiler kannel en 

lançant les commandes: 

./configure 

make 

- installer kannel 

make install 

5.7.2 Configuration de kannel 

Le fichier de configuration de kannel est structuré en groupes suivant les fonctions à assigner 

à kannel. 

Chaque groupe comporte des variables et sont séparés par des lignes vides, chaque variable 

est définie sur une ligne. 

Pour configurer KANNEL comme passerelle SMS, les groupes suivants doivent être 

configurés : 

« Core » qui est le noyau de KANNEL il contient les variables nécessaires pour 

l'administration. 

Exemple : 

Figure 5.6 : Configuration du group core de kannel 

« Smsc » qui contient les variables de connexion aux SMSC ou aux modems. 

Exemple : 

‣ Variables de connexions à un SMSC : 


56



Figure 5.7 : Configuration du groupe SMSC pour le protocolSMPP 

‣ Variable de connexion à un modem : 

Figure 5.8 : Configuration du groupe SMSC pour un modem GSM 

« Smsbox » qui gère les files d'envoi et de réception de SMS 

Exemple : 

Figure 5.9 : Configuration du groupe smsbox 

« sendsms-user » qui contient les variables d'un client http 

Exemple : 

Figure 5.10 : Configuration du group sendsms-user 


57



« sms-service » pour la réception des SMS venant du SMSC ou du modem, servant à 

paramétrer un service. 

Exemples : 

Figure 5.11 : Configuration du groupe sms-service 

Le %p représente le numéro de téléphone de l’expéditeur 

Le %r représente le texte qui se trouve dans le message sans le mot clé 

Le %b représente le texte en binaire 

Le %t représente l’heure et la date d’envoi du message 

Le %i représente le type de SMSC auquel est rattachée la passerelle 

Le %k représente le mot clé du service 

Tableau 5.1 : Paramètres pour les services dans kannel 

Paramètres Description 

%s représente les caractères encodés au niveau de l’URL. Par exemple le «+ » 

devant le numéro de téléphone devient %2B 

%S se comporte comme le %s 

%a représente tout le contenu du message 

%T représente le temps où le message à été envoyé sous format UNIX 

Timestamp 

%p représente le numéro de téléphone du destinataire 

%q transforme le ‘00’ devant l’indicatif du numéro de téléphone de l’expéditeur 


58



en ‘+’ 

%Q se comporte comme le %q mais s’applique sur le numéro du destinataire 

%I représente l’ID du sms 

%d représente l’accusé de réception 

%R représente le contenu de tout l’URL 

%n représente l’utilisateur de Kannel qui envoi le message à travers l’URL 

%f donne le nombre de sms que le SMSC à envoyé au niveau du modem GSM. 

Cette valeur est utilisée que si on utilise un modem GSM. 

Dans le cas où on utilise un modem GSM (voir annexe 4), on doit cependant spécifié le 

group modem qui permet de définir le type de modem à utiliser : 

Exemple : 

Figure 5.12 : Configuration du group modem 

NB : On peut avoir plusieurs groupes pour chaque type sauf pour « core ». 

Le fichier de configuration de kannel se trouve à l’annexe1 

Syntaxe d’envoi d’un sms via l’URL : 

http://localhost:13013/cgi-bin/sendsms? 

username=foo&password=bar&to=0123456&text=Hello+world 

1.4.2.5.Les accusés de réception Kannel: 

Un accusé de réception désigne une procédure certifiant la réception d’un message. 

Les accusés de réception sont supportés par défaut en interne, ce qui signifie qu’ils sont 

stockés dans la mémoire du processus bearerbox. Cette situation est problématique s’il y’a 

problème au niveau du bearerbox. Par conséquent, on peut utiliser les lieux de stockage 

externes DLR, à savoir une base de données MySQL par exemple. [W9] 

Voici les types de moteurs de stockage pour les accusés de réceptions supportés par kannel : 


59



Stockage interne dans kannel : 

Dans le bearerbox en interne : 

C’est le lieu par défaut pour le traitement des accusés de réceptions et ne nécessite aucune 

configuration particulière à faire. Pour autorisé kannel à l’utiliser, on spécifie le paramètre 

dlr-storage = internal dans le group ‘core’ 

Dans une base de donnée externe : MySQL 

Pour stocker les informations concernant les accusés de réception dans une base de donnée de 

type MySQL il faut spécifier la directive dlr-storage = mysql au niveau du groupe ‘core’. En 

plus de cela on doit définir un group dlr-db qui spécifie les champs de table pour le stockage 

des accusés de réceptions et un autre group mysql-connection qui définit la connexion au 

serveur MySQL. 

Un exemple de fichier de configuration se trouve dans le répertoire /doc/examples/ de kannel. 

Le nom de ce fichier est dlr-mysql.conf 

Les principaux variables utiles sont : 

group = mysql-connection 

la variable de connexion mysql 

id = mydlr 

l’identifiant de connexion 

host = localhost 

l’adresse du serveur mysql 

mysql-username = foo 

l’utilisateur du serveur mysql 

mysql-password = bar 

le mot de passé du serveur mysql 

database = dlr 

le nom de la base de donnée 

max-connections = 1 

group = dlr-db 

id = mydlr 

table = dlr 

field-smsc = smsc 


60



field-timestamp = ts 

field-destination = destination 

field-source = source 

field-service = service 

field-url = url 

field-mask = mask 

field-status = status 

field-boxc-id = boxc 

Le groupe dlr-db spécifie la table et les champs de tables qui seront crées au niveau de la base de 

donnée. 

Le principe est le même pour les autres types de base d donnée et leurs fichier de 

configuration se trouve aussi dans le même répertoire /doc/examples/ de kannel. 

Puisque l’option de connexion à une base de donnée n’est pas prise en compte par défaut dans 

kannel, il suffit lors de la compilation exécuter la commande comme suit : 

. /configure -with-mysql -with-mysql-dir = [répertoire] 

Le répertoire à préciser est celui dans lequel est localisée la librairie MySQL. 

Les autres types de base de données pour le stockage des accusés de réception sont : 

- LibSDB DLR storage 

- Oracle 8i/9i DLR storage 

- PostgreSQL DLR storage 

1.4.3. Démarrage de la passerelle : 

Pour démarrer il faut procéder comme suit: 

-Démarrer d'abord le bearerbox: bearebox /etc/kannel.conf (Voir annexe 3) 

-Démarrer ensuite le smsbox : smsbox /etc/kannel.conf (Voir annexe 3) 

Pour arrêter le tout, appuyer sur Ctrl+c sur la fenêtre du bearerbox. 


61



Dans le prochain chapitre nous allons passer à l’étude de notre système SMS Banking 

en commençant par l’analyser afin de délimiter les fonctionnalités du système et proposer 

par la suite une solution de conception en vue de le déployer plus tard. 


62



Chapitre 6 

ANALYSE ET CONCEPTION DE LA SOLUTION SMS BANKING 

6.1 Architecture et fonctionnement 

Figure 6.1 : Architecture de la solution SMS Banking 

L’architecture de notre système est composée d’un serveur SMS Banking et d’une 

passerelle SMS assurant ainsi l’envoi et la réception des SMS via le réseau GSM. Le serveur 

SMS Banking est relié au Serveur contenant les informations bancaires via le réseau TCP/IP ; 

-le client mobile est muni d’un téléphone portable et d’une carte Sim opérationnelle ; 

-le réseau GSM est chargé de transporter tous les SMS du client vers le système et du système 

vers le client ; 

-pour toute requête de type PULL venant du client, la passerelle SMS est chargé de la 

réception du SMS puis le système analyse sa syntaxe à l’aide des programmes avant 

d’interroger la banque ; 


63



-pour les requêtes de type PUSH, elles sont déclenchés automatiquement à l’aide des 

programmes qui interrogent la base de données de la banque. 

-l’administrateur du système doit s’authentifier à travers une interface homme/machine pour 

accéder au système ; 

Les composants du système SMS Banking communiquent entre eux par le biais des 

protocoles HTTP et HTTPS. 

6.2 Exposé du problème 

Un client X souhaite souscrire au service SMS BANKING. La condition est de disposer d’un 

ou plusieurs numéros de téléphone mobile et d’un ou plusieurs comptes bancaires. Il se 

présente à l’agence bancaire pour l’abonnement à ce service; ce dernier lui fait signé un 

contrat qui comprend la date de signature, la date de début, la date d’expiration, le numéro de 

compte du client (un contrat par compte), ainsi que les services auxquels il souhaiterait 

bénéficier (pour chaque compte). L’agence bancaire est caractérisée par son nom, son code 

(code agence) et son numéro de téléphone. Le compte client est caractérisé par son type, le 

code agence et son solde. Le client dispose d’un ID, d’un nom, d’un prénom, d’un ou 

plusieurs numéros de téléphone. Lors de la signature du contrat un code avec lequel le client 

pourra accéder aux services lui est attribué un code (alphanumérique sur 4 positions). Chaque 

service est caractérisé par son mot clé, son état actif ou inactif, le modèle de message de 

réponse et est associé à un contrat. Or le système BANKING comprend deux types d’envoi de 

SMS : l’envoi en mode PULL et l’envoi en mode PUSH. Au niveau de l’envoi en mode 

PULL (dans le cas où le message est envoyé à l’initiative du client), le système devra 

effectuer quelques traitements préliminaires (authentification du client, validité du contrat, 

vérification des souscriptions) avant toute opération. C’est ainsi que lorsque qu’il reçoit un 

SMS en provenance du client, il l’enregistre d’abord au niveau de la base de donnée ensuite il 

effectue une vérification du numéro de téléphone, puis du code client si c’est bon il récupère 

le mot clé du service et vérifie si le client est bel et bien inscrit à ce service ainsi que la 

validité de son contrat (si son contrat n’est pas expiré). Si tout est OK, le système ira 

récupérer les informations concernant le service demandé, formate le message à renvoyer (en 

fonction des données relatives à ce client), l’enregistre au niveau de la base de données puis 

envoi le SMS. Au niveau de l’envoi en mode PUSH (la banque envoi un SMS comme alerte 

au client selon une périodicité paramétrée par la banque), le système récupère les informations 

au niveau de la banque, vérifie aussi si client est bel et bien inscrit au service 


64



(stratégiquement, la banque force les clients à souscrire à certains services surtout de pub mais 

gratuitement), formate le message et puis l’envoi. Tous les messages envoyés et reçus sont 

enregistrés au niveau d’une table de la base de données. Ces messages sont caractérisés soit 

par le type PULL ou PUSH. 

Une interface d’administration (voir annexe 5) est offerte au gestionnaire de l'application afin 

de paramétrer l'application, de consulter les statistiques d'envoi/réception, de vérifier les 

chargements de fichiers envoyés par la banque … 

6.3 Fonctionnalités du système SMS Banking 

Pour la mise en œuvre de la solution SMS BANKING, il faudrait recenser les différentes 

fonctionnalités du système. [W10] 

Quels sont les services qui seront proposés aux clients ? 

6.3.1 Services d’informations à la demande 

Grâce à ces fonctionnalités les clients peuvent à tout moment demander de recevoir des 

informations par SMS sur leur téléphone mobile. Pour cela le client envoie un SMS contenant 

un mot clé spécifique au service dont il veut avoir accès auquel il ajoute un code personnel 

qui lui est attribué par la banque. Ces différents services peuvent être : 

• Demande de solde, 

• Demande historique (quatre dernières transactions sur un compte par exemple), 

• Demande de chéquier 

• Demande de virement. 

Exemple: pour consulter son solde, il va simplement envoyer un SMS depuis son téléphone 

contenant : 

6.3.2 Services de notification événementielle 

Ces fonctionnalités permettent aux clients de recevoir des informations sur leurs téléphones 

mobiles lorsqu'un évènement se produit ou une condition est satisfaite. Ces différents services 

sont : 

• Notification par SMS après virement d'un salaire, 

• Notification par SMS après un débit sur un compte, 


65



• Notification par SMS pour toutes les transactions effectuées sur le compte, 

• Notification par SMS après crédit sur un compte, 

• Notifications/Information promotionnelles, 

• Notification par SMS après dépassement de seuil minimal, 

• Notification par SMS après dépassement de seuil maximal. 

6.3.3 Services de notification périodiques 

Ces fonctionnalités permettent aux clients de recevoir périodiquement des informations 

concernant le solde de leurs comptes : 

• Mensuelle : le client reçoit son solde tous les 1 er du mois par exemple, 

• Hebdomadaire : le client reçoit son solde chaque lundi par exemple, 

• Quotidienne : le client reçoit son solde tous les jours. 

6.3.4 Gestion des clients 

L'application SMS BANKING devra être capable de gérer des milliers de numéro de compte, 

numéro de téléphone, services choisis (solde, alertes virements de salaire, alertes dépôts, 

historiques...), paramétrage d'envoi de l'information pour chaque client, seuils personnalisés,... 

• importation automatique des comptes des clients inscrits à SMS BANKING de la base 

de données bancaire vers la base de données de SMS BANKING, 

• activation et désactivation des comptes clients aux différents services, 

• possibilité de définir les règles de diffusion des alertes, 

• consultation en temps réel des comptes à partir des options multicritères de recherche. 

6.3.5 Gestion de la facturation 

L’application SMS BANKING donnera à la banque ou la coopérative bancaire la liberté de 

définir sa politique tarifaire adéquate (facturation mensuelle ou facturation par SMS envoyé 

au client) et de paramétrer la facturation pour chaque client. 

6.3.6 Gestion des SMS 

L'application devra offrir la possibilité de : 

• consulter à tout moment tous les messages reçus par le système, 

• consulter à tout moment de tous les messages émis par le système, 


66



• rechercher tous les SMS envoyés ou reçus par un client, 

• rechercher tous les SMS reçu ou envoyé par le système pendant une période, 

• rechercher les SMS entrant et sortant par service. 

6.3.7 Etats et statisques 

Des états pourront être extraits de l'application et imprimés ou enregistrés. 

• possibilité de tirer des statistiques individuelles sur les SMS des clients, 

• possibilité de tirer des statistiques sur les SMS pour une période donnée (SM envoyés, 

reçus) et les grouper par service. 

6.3.8 Sécurité 

Pour les besoins de sécurité, chaque client de SMS BANKING doit avoir un code d’accès 

personnel qu'il devra intégrer à tous ses SMS. De plus, en vue de renforcer la sécurité, les 

SMS ne sont traités que lorsque le numéro de téléphone du client et le code d’accès sont 

justes. 

6.4 Choix des techniques et outils utilisés 

6.4.1 Le langage UML 

Le langage UML (Unified Modeling Language, ou langage de modélisation 

unifié), utilisé quotidiennement est un langage graphique standard qui permet la modélisation 

des données. Cette technique propose des outils de concept et de modélisation des Systèmes 

d’Information. La modélisation proposée par le langage UML utilise divers types de 

diagrammes spécifiques qui sont repartis en deux groupes : [B6] 

-structure du système 

-diagramme de cas d’utilisation 

-diagramme de classe 

-diagramme d’objet 

-diagramme de composants 


67



-diagramme des paquetages 

-diagramme de déploiement 

-diagramme de structure composite 

-comportement du système 

-diagramme d’état de transition 

-diagramme d’activité 

-diagramme de séquence 

-diagramme de collaboration 

-diagramme de vue globale des interactions 

-diagramme de temps 

Pour notre cas, nous allons utiliser quelques-uns de ces diagrammes pour modéliser notre 

système. 

6.4.2 Le langage SQL 

Le langage SQL (Structured Query Language) peut être considéré comme le 

langage d’accès normalisé aux bases de données. Le succès du langage SQL est dû 

essentiellement à sa simplicité et au fait qu’il s’appuie sur le schéma conceptuel pour énoncer 

des requêtes en laissant le SGBD responsable de la stratégie d’exécution. [W11] 

Le langage SQL comporte : 

‣ une partie sur la définition des données : le langage de définition des données 

(LDD) qui permet de définir des relations, des vues externes et des contraintes 

d’intégrité; 

‣ une partie sur les requêtes : le langage de manipulation des données (LMD) qui 

permet d’interroger une base de données sous forme déclarative sans se préoccuper de 

l’organisation physique des données; 

‣ une partie sur le contrôle des données : le langage de contrôle des données (LCD) 

qui permet de contrôler la sécurité et les accès aux données. 


68



6.4.3 Le langage PHP 

PHP est un langage qui permet de développer des applications Web dynamiques 

puissantes. Ses avantages résident dans son indépendance de la plateforme. En effet, il existe 

pour les différentes versions de Windows, Unix et Linux. De plus, c'est un langage de script 

embarqué dans les pages HTML et traité par le serveur. PHP permet de construire 

dynamiquement des pages HTML contenant des résultats de calcul ou de requêtes SQL 

adressées à un système de gestion de bases de données.[B7] 

6.4.4 Merise 

Merise est une méthode de conception, de développement et de réalisation des 

projets informatiques. Son but est la séparation des données et des traitements à effectuer en 

plusieurs modèles conceptuels et physiques. Elle date de 1978-1979, et est créée suite à une 

consultation lancée en 1977 par le ministère de l'industrie français dans le but de choisir des 

sociétés de conseil en informatique afin de définir une méthode de conception de systèmes 

d'information. 

Elle est la méthode la plus utilisée pour concevoir les bases de données relationnelles tout en 

offrant des modèles qui séparent les données et les traitements qui permettent de structurer 

d’une façon claire les entités et les relations entre ces entités. Pour décrire notre base de 

donnée nous allons nous limité sur deux modèles à savoir le MCD et le MLD. [W12] 

6.4.5 MySQL 

Le Système de Gestion de Bases de Données utilisé pour la gestion et le 

stockage des données dans le cadre de la mise en œuvre du prototype final est MySQL dans sa 

version 5.1. Le logiciel MySQL est un serveur de base de données SQL très rapide, 

multithread, multi utilisateurs et robuste. Il est destiné aux missions stratégiques, aux 

systèmes de production à forte charge, et à l'intégration dans des logiciels déployés à grande 

échelle. MySQL est une marque déposée de MySQL AB. 

Les principaux concurrents de MySQL sont : PostgreSQL, MICROSOFT SQL SERVER, 

et Oracle. Ainsi, le choix de ce Serveur de Bases de Données a été particulièrement orienté 

par un certain nombre d'avantages qu'il offre aux développeurs. En effet, par rapport aux 


69



autres SGBD cités, MySQL est un logiciel intégrant un haut degré de portabilité, de sécurité 

et constitue un système de sauvegarde assez évolué avec utilisation optimale de ressources. 

[B8] 

6.5 Conception du Système 

6.5.1 Modélisation du système 

Acteur 

6.5.1.1 Quelques définitions et concepts : 

Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel 

ou autre système) qui interagit directement avec le système étudié. Un acteur peut consulter 

et/ou modifier directement l’état du système, en émettant et/ou en recevant des messages 

susceptibles d’être porteurs de données. [B9] 

Comment les identifier ? 

Les acteurs candidats sont systématiquement : 

• les utilisateurs humains directs : faites donc en sorte d’identifier tous les profils possibles, 

sans oublier l’administrateur, l’opérateur de maintenance, etc. 

• les autres systèmes connexes qui interagissent aussi directement avec le système étudié, 

souvent par le biais de protocoles bidirectionnels. 

Comment les représenter ? 

La représentation graphique standard de l’acteur en UML est l’icône appelée stick man, avec 

le nom de l’acteur sous le dessin. On peut également représenter un acteur sous la forme 

rectangulaire d’une classe, avec le mot-clé . Une troisième représentation 

(intermédiaire entre les deux premières) est également possible avec certains outils,comme 

cela est indiqué ci-après. 


70



Cas d’utilisation 

Un cas d'utilisation représente l'image d'une fonctionnalité du système. Il est déclenché par un 

acteur, qui est une entité externe au système et nécessite que ce dernier lui rende service. Il 

s'agit donc d'une représentation du système tel que perçu par les différents utilisateurs. 

Chaque cas d’utilisation spécifie un comportement attendu du système considéré comme un 

tout, sans imposer le mode de réalisation de ce comportement. Il permet de décrire ce que le 

futur système devra faire, sans spécifier comment il le fera. 

Un scénario de cas d'utilisation est le déroulement d'un cas d'utilisation. Il permet 

d'échafauder toutes les hypothèses relatives au cas d'utilisation. Il est caractérisé par : 

une pré-condition : c'est la condition à remplir avant que le scénario ne soit 

déclenché ; 

une post-condition : c'est la condition que doit vérifier le système à la fin du scénario ; 

le scénario nominal : qui représente le déroulement du cas d'utilisation de la meilleure 

des façons possibles, c'est-à-dire qu'aucun facteur ne nuit à son déroulement ; 

Enchainements d’Erreur : il s'agit du déroulement d'un cas d'utilisation lorsqu'une 

erreur s'est produite suite au non-respect d'une contrainte. 

‣ Identification des acteurs du système sms banking 

-le client mobile (acteur externe au système) 

-l’administrateur du système 

-les API sms banking +la base de donnée de la banque (parce que c’est elle qui va alimenter la 

base de donnée du système sms banking grâce à des applications et des programmes) qu’on va 

nommer logiciel bancaire ; 

‣ Identification des cas d’utilisations 

Nous allons présenter ici quelques cas d'utilisation du Système SMS Banking : 

Authentification au système : pour accéder au système SMS Banking 

via une interface 

homme/machine, l’administration doit se connecter en grâce à ses identifiants login et mot de 

passe 


71



Consultation du solde du compte : avec son téléphone mobile, le client envoie un SMS 

contenant le mot clé du service suivi du code d’accès du client. Si toutes les conditions sont 

vérifiées, le client reçoit en retour un SMS dans lequel se trouve le solde de son compte. 

Consultation des historiques de compte : ce cas d'utilisation permet au client de consulter 

les 4 derniers historiques de son compte par exemple en utilisant son téléphone mobile. Un 

SMS avec cet historique lui est envoyé 

Demande de chéquier : il s'agit ici pour le client de faire la demande d'un nouveau chéquier 

en utilisant un SMS. Un SMS lui est renvoyé pour confirmer que la demande a été prise en 

compte. 

Demande de virement vers un autre compte : ce cas d'utilisation permet au client de faire la 

demande de transfert d'argent vers un compte autre que le sien en utilisant un SMS. Un SMS 

lui est renvoyé pour confirmer le virement 

Notification de débit sur un compte : ce cas d'utilisation permet au système d'informer le 

client lorsque son compte est touché en débit. Un SMS lui est envoyé avec le montant débité. 

Notification de crédit sur un compte : ce cas d'utilisation permet au système d'informer le 

client lorsque son compte est touché en crédit. Un SMS lui est envoyé avec le montant 

crédité. 

Notification de virement de salaire sur un compte : il s'agit ici pour le système d'alerter le 

client lorsque son compte est touché en débit. Un SMS lui est envoyé avec le montant viré. 

Notification périodique de solde d'un compte : grâce à ce cas d'utilisation le système 

informe le client quotidiennement, hebdomadairement ou mensuellement du solde de son 

compte. Un SMS lui est envoyé avec le montant du solde suivant la périodicité qu'il a choisie. 

‣ Réalisations de diagrammes d’utilisations 

Le service sms banking propose deux(2) types d’envoi de sms : 

-l’envoi en mode pull : message envoyé à l’initiative du client pour bénéficier des services 

sms banking 


72



Figure 6.3 : Diagramme des cas d’utilisations préliminaires des services à la demande de 

l’utilisateur 

-l’envoi en mode push : la banque envoi des SMS sous forme d’alerte au client mobile 

Figure 6.4: Diagramme des cas d’utilisations préliminaires d’envoi de messages sous 

forme d’alertes 

‣ Description textuelle du cas d’utilisations : 

Cette étape consiste à décrire les différents cas d’utilisation dans les deux types d’envoi de 

SMS ; nous allons présenter quelques exemples de cas d’utilisation : 

Demandes de type PULL : 


73



-Demande de consultation de solde : 

Figure 6.5 : Diagramme de cas d’utilisation pour une demande de solde 

a-sommaire d’identification : 

Titre : Demande de consultation de solde 

Résumé : ce cas d’utilisation donne la possibilité au client disposant d’un numéro de 

téléphone mobile fonctionnel de consulter le solde de son compte 

Acteurs : Client mobile, logiciel bancaire 

Date de création : 25-08-2012 Date de mise à jour : 

Version : 

Responsable : Hapsita Awada Hassan 

b-description des scenarios : 

Pré conditions : disposer d’un téléphone mobile fonctionnel, le réseau opérationnel 

Scenario nominal : 

1) Le client envoi un SMS au niveau de la passerelle connectée au système SMS Banking 

2) Le système reçoit le SMS, vérifie sa syntaxe puis le stocke au niveau de la base de 

données du système SMS Banking 

3) Le système vérifie le numéro de téléphone du client 


74



4) Le système vérifie le code du client 

5) Le système récupère le mot clé du service puis vérifie si le client est effectivement bel 

et bien inscrit au service demande de solde 

6) Le système vérifie si le délai du contrat du client n’est pas expiré 

7) Le système récupère ensuite le solde du client au niveau de la banque 

8) Le système formate le message à envoyer au client 

9) Le système envoi le SMS au client. Ce SMS contient le solde du client 

10) Le système enregistre le SMS (sortant) dans la base de données 

Enchainements d’Erreurs : 

E1) Le système s’aperçoit que la syntaxe du SMS est mauvaise : 

L’enchainement E1 démarre au point 2 du scénario nominal 

3) Le système formate le message à envoyer au client. Ce message est un message d’erreur 

de syntaxe SMS 

4) Le système marque le message comme erroné 

Le scenario nominal se poursuit au point 8 

E2) Le système s’aperçoit que le numéro de téléphone du client n’est pas valide : 

L’enchainement E2 démarre au point 3 du scenario nominal 


de numéro de téléphone non valide 



E3) Le système s’aperçoit que le code du client est invalide : 



de code non valide 

6) Le système marque le message comme erroné. 


75



Le scenario nominal se poursuit au point 8. 

E4) Le système s’aperçoit que le client n’est pas inscrit au service de consultation de solde : 



de non inscription au service 


Le scenario nominal se poursuit au point 8. 

E5) Le système s’aperçoit que le contrat du client est expiré : 



d’expiration de contrat 



Post conditions : Le système envoi une réponse au client contenant le solde de son compte. 

‣ Description graphique du cas d’utilisations : 


76



Figure 6.6 : Diagramme de séquence système du scenario nominal de consultation de 

solde 

Figure 6.7 : Diagramme de cas d’activité de la demande de la consultation de solde 

Demande de type PUSH : 


77



Le but est d’informer le client par SMS concernant les mouvements, les informations de son 

compte. Les cas d’utilisation des tous les types d’alertes se comportent de la même manière. 

Le principe est l’envoi d’un SMS automatiquement par le système. Nous allons présenter un 

exemple de cas d’utilisation 

-Notification crédit sur un compte: 

Figure 6.8 : Diagramme de cas d’utilisation de notification de sur un compte 

a-sommaire d’identification : 

Titre : Notification de crédit sur un compte 

Résumé : ce cas d’utilisation permet de notifier le client lorsque son compte est crédité 

Acteurs : Client mobile, logiciel bancaire 

Date de création : 25-08-2012 Date de mise à jour 

Version : 

Responsable : Hapsita Awada 

b-description des scenarios : 

Pré conditions : disposer d’un téléphone mobile fonctionnel, le réseau opérationnel 

Scenario nominal : 

1) Le logiciel bancaire effectue un nouvel enregistrement dans la base de données de 

SMS Banking 

2) Le système récupère le nouvel enregistrement et vérifie s’il s’agit d’un crédit sur un 

compte 

3) Le système vérifie si le client est bel et bien inscrit au service 

4) Le système vérifie si son contrat n’est pas expiré 


78



5) Le système formate le message à envoyer au client avec montant crédité 

6) Le système recherche le numéro de téléphone du client 

7) Le système envoie le SMS « de notification de crédit du compte » au client 

8) Le système enregistre le message à envoyer au client dans la table représentant les 

messages sortants 

Enchainements d’Erreurs : 

E1) Le système s’aperçoit que le client n'est pas inscrit à ce service. L’enchainement E1 

démarre au point 3 du scénario nominal. 

4) Le système effectue une mise à jour de l’enregistrement avec le statut « client non inscrit 

au service alerte crédit sur un compte » 

Le scenario nominal s’arrête au point 3 

E2) Le système détecte que le contrat du client n’est pas valide 

L’enchainement E2 démarre au 4 du scenario nominal. 

Le système effectue une mise à jour de l’enregistrement avec le statut « contrat du client 

expiré » 

Le scenario nominal s’arrête au point 4 

E3) Le système n'arrive pas à envoyer le SMS. L’enchainement E3 démarre au point 8 du 

scenario nominal 

Le système met à jour la table concernant les messages sortants avec un statut permettant 

d'identifier la source d'erreur. Le SMS sera renvoyé plus tard. 

Dans ce cas, le scénario nominal reprendra au point 8. 

Post conditions : Le système envoi un SMS avec le montant crédité du client 

‣ Description graphique du cas d’utilisations : 


79



Figure 6.9 : Diagramme de séquence du scenario nominal de notification de crédit sur 

un compte 

Figure 6.10 : Diagramme de cas d’activité de notification de crédit sur compte 

6.5.2 Conception de la base de données 

6.5.2.1 Le Modèle Conceptuel de données 

Le modèle conceptuel de données est une représentation statique du système d’information de 

l’entreprise qui met en évidence sa sémantique. Il a pour but d'écrire de façon formelle les données 

qui seront utilisées par le système d'information. Il s'agit donc d'une représentation des données 


80



facilement compréhensible. Le formalisme adopté par la méthode Merise pour réaliser cette 

description est basé sur les concepts 'entité-association'. 

Dans ce contexte on définit : 

- Propriété : c'est une information élémentaire, caractéristique d’une entité. 

- Entité : c'est la représentation d'un élément matériel ou immatériel ayant un rôle dans le système 

que l'on désire décrire. Chaque entité est composée de propriétés permettant de la décrire. 

- Association : c'est un lien sémantique entre plusieurs entités. 

- Identifiant : c'est un ensemble de propriétés (une ou plusieurs) permettant de désigner une et une 

seule entité. 

- Cardinalités : c'est un couple de valeurs qui exprime le nombre minimal et maximal de fois qu'un 

élément d'entité peut exister dans les éléments de l'association. Elles permettent de caractériser le 

lien qui existe entre une entité et la relation à laquelle elle est reliée. 

Le MCD (Figure 6.11) réalisé avec l'outil Analyse SI est composé des entités suivantes : 

Figure 6.11 : Le modèle Conceptuel de Données 


81



6.5.2.2 Le Modèle logique de donnée 

Figure 6.12 : le modèle Logique de données 

Le modèle logique de données donne une vue de la structure de la base de données et est obtenu à 

partir du MCD en respectant les règles suivantes : 

- Toute entité devient une relation, autrement dit elle devient une table de la base de données et 

l'identifiant de l'entité constitue la clé primaire de la table. 

- Une association 'un à plusieurs' implique l’intégration de la clé de la table relative à la classe 

portant la cardinalité 'un ' dans la table relative à la classe portant la cardinalité 'plusieurs'. 

- Une association 'plusieurs à plusieurs' implique la création d’une nouvelle table ayant comme clé la 

concaténation des deux tables relatives aux classes associées. 

Le dictionnaire de données : 

Le dictionnaire de données décrit les propriétés des entités 


82



Figure 6.13 : Le dictionnaire de données 

6.5.2.3 Réplication de la base de données et 

répartition de charges 

MySQL supporte la réplication interne. Un serveur sert de maître, et les autres serveurs 

servent d'esclaves. Chaque esclave, après connexion réussie au serveur maître, indique au 

maître le point qu'il avait atteint depuis la fin de la dernière réplication, puis rattrape les 

dernières modifications qui ont eu lieu, puis se met en attente des prochains événements en 

provenance du maître. 

Un esclave peut aussi servir de maître à son tour, pour réaliser une chaîne de réplication. 

Notez que lorsque vous utilisez la réplication, toutes les modifications de tables sont 

répliquées, et doivent intervenir sur le serveur maître. Sinon, vous devez être prudents dans 

vos interventions, pour ne pas créer de conflits entre les modifications de tables sur le maître 

et celles qui interviennent sur l'esclave. [W13] 

La réplication permet de renforcer la robustesse, la vitesse et l'administration du serveur : 


83



La robustesse est augmentée par la configuration maître/esclave. Dans le cas où un 

problème survient sur le maître, vous pouvez utiliser un esclave comme serveur de 

secours. 

L'accélération provient de la répartition de la charge de traitement des requêtes clients 

entre le maître et les esclaves, permettant un meilleur temps de réponse. Les 

requêtes SELECT par exemple peuvent être envoyées aux esclaves pour réduire la 

charge du maître. Les requêtes de modifications des données sont envoyées au maître, 

qui les transmettra aux esclaves. Cette stratégie de répartition de charge est efficace si 

les lectures sont plus nombreuses que les écritures, ce qui est la situation la plus 

courante. 

Un autre avantage de la réplication est que vous pouvez faire des sauvegardes nonbloquantes 

de vos données sur l'esclave et non plus sur le serveur principal : ce dernier 

n'est pas perturbé. 

6.6 Perspectives 

Pour notre solution SMS Banking nous envisageons ; 

Faire une étude de déploiement du système SMS Banking 

Faire une étude de performance du serveur qui hébergera notre application 

Développer tous les services bancaires possibles 

Améliorer l’interface d’administration 

Proposer une solution de sécurité pour d’éventuelles vulnérabilités 


84



CONCLUSION 

Ce projet de fin d’étude s’intitule « Etude et Conception d’une solution de SMS 

Banking ». L’objectif était de proposer une conception pour la mise en place des services 

bancaires disponibles via le téléphone mobile et grace au service SMS du réseau GSM. 

Le SMS Banking est un sujet d’actualité utilisant le service SMS pour offrir des services à 

valeurs ajoutées aux clients. En réalité ce système permettra, entre autre aux clients d’une 

banque de bénéficier de certains opérations bancaires ou services à distance par un simple 

SMS. Cependant pour que le système soit opérationnel il faudrait un partenariat avec les 

institutions financières ou coopérative bancaires et les opérateurs de téléphonie mobile. 

Ainsi nous avons donc étudier le système dans sa généralité, quels sont les principaux outils 

nécessaires ? Nous avons donc simuler un SMSC. Nous avons mis en place un serveur SMS 

pour l’envoi et la réception des messages PULL et PUSH. Nous avons fait une liaiason entre 

le serveur SMS et le SMSC. Nous avons concu notre base de donnée pour interagir avec 

kannel. Cette base de donnée contient toutes les données concernant le sytème(clients, 

messages récus,messages envoyés, services disponibles…).Nous avons développer un 

exemple de service « Consultation de solde » pour expliquer le fonctionnment de notre 

système concu ainsi qu’une interface d’administration. Plus tard nous envisageons réaliser et 

déployer le sytème en tenant compte des insuffisances observées, des options supplémentaires 

et des contraintes afin de disposer d’une application complète de solution de SMS Banking. 

C’est ainsi pour mener à bien l’étude du projet il a fallu adopter une certaine démarche ; en 

premier lieu éffectuer une phase bibliographique afin de connaitre le mieux possible les 

différents outils et/ou moyens insdispensables pour le développement de notre application. 

En second lieu nous avons spécifié le système pour en dicerner les fonctionnalités et enfin 

nous avons procédé à sa conception ainsi qu’aux différents choix tehnologiques. 

Ce projet peut évoluer en intégrant une nouvelle plateforme encore récente celle de l’USSD. 


85



Enfin ce travail n’a été que source de bénéfices malgré quelques difficultés rencontrés, l’étude 

a exigé un minimum de connaissances des réseaux informatiques et télécommunications et 

aussi des outils de dévéllopement indispensables à la conception du système. Il s’agit de la 

modelisation avec le langage UML et Mérise pour la bases de données. La maitrise du 

système linux a été egalement très importante ainsi que la langue anglaise car bon nombre de 

documents que nous avons eu à utiliser sont en anglais donc cette langue s’est avérée 

indispensable. 


86



REFERENCES BIBLIOGRAPHIQUES 

Liste des ouvrages 

[B1]: BOUTEKDJIRET IMEN et MEZRAGUE ZINA, 2008-2009. Conception et 

réalisation d’une solution de SMS Banking pour TRUST BANK ALGERIA 

[B2]: GSM TECHNOLOGY FOR ENGINEERS, Copyright 2002 AIRCOM 

International Ltd 

[B3] : Qualité de service d'un centre de service de messagerie GSM (SMSC) Par 

Youssef Haddad 

[B4] : Short Message Peer-to-Peer Protocol Specification Version 5.0 

[B5] : Jean François Diokel DIOKH, 2006-2007. Services à valeurs ajoutées et outils 

open sources 

[B6]: UML 2 pour les développeurs, Xavier Blanc, Isabelle MOUNIER, Editions 

Eyrolles 

[B7] : Sécurité PHP 5 et MySQL de D.Seqguy, P.Gamache 

[B8] : Sécurité PHP 5 et MySQL de D.Seqguy, P.Gamache 

[B9]: [Pascal roques1] Pascal Roques, UML 2 par la pratique, 6ème édition, Eyrolles, 

Paris, 2002. 

[B10]: Conception de base de données avec UML, Gylles ROY 

Sites WEB 

[W1]: http://en.wikipedia.org/wiki/Mobile_banking 

[W2]: http://jaaayyy.chez.com/html/Radiomobiles/stage/SVA.html 

[W3]: http://fr.wikipedia.org/wiki/Protocole_WAP 

[W4]: http://searchnetworking.techtarget.com/definition/USSD 

[W5]: http://www/efort.com (SS7_efort) 

[W6]: http://www/efort.com (SMS_efort) 

[W7]: http://www/efort.com (MAP_efort) 


87



[W9]: http://www.kannel.org/download/1.4.3/userguide-1.4.3/userguide.html 

[W10]: http://fr.scribd.com/doc/82359560/32/III-Capture-des-besoins-fonctionnels 

[W11]: http://www.commentcamarche.net/contents/sql/sqlintro.php3 

[W12]: http://fr.scribd.com/doc/8474587/la-methode-merise 

[W13]: http://dev.mysql.com/doc/refman/5.0/fr/replication.html 

[W14]http://en.wikipedia.org/wiki/SIM_Application_Toolkit 

[W16]http://en.wikipedia.org/wiki/SMS_banking 

[W8]:http://www.activexperts.com/mobile-messaging-component/smppspecifications/overview/ 

[W15]www.memoireonline.com/.../m_Implementation-dun-portail-SMS--base-dulogiciel-KANNEL3.htm 

[W17]http://www.unixgarden.com/index.php/gnu-linux-magazine/developpement-deservices-sms 

[W18]http://fr.wikipedia.org/wiki/SMPP 


88



ANNEXES 

Annexe 1 : Fichier de configuration de kannel 

# 

# THIS IS A SAMPLE CONFIGURATION FOR KANNEL 

# 

# For any modifications to this file, see Kannel User Guide 

# If that does not help, send email to users@kannel.org 

# 

group = core 

admin-port = 13000 

admin-password = bar 

smsbox-port = 13001 

#status-password = foo 

#admin-deny-ip = "" 

#admin-allow-ip = "" 

#log-file = "/tmp/kannel.log" 

#log-level = 0 

#access-log = "access.log" 

#http-proxy-host = "127.0.0.1" 

#http-proxy-port = 8080 

#http-proxy-exceptions = "127.0.0.1" 

#http-proxy-username = "user" 

#http-proxy-password = "password" 

#ssl-certkey-file = "mycertandprivkeyfile.pem" 


89



# SMSC CONNECTIONS - GLOBAL FIELDS 

#group = smsc 

#smsc = 

#smsc-id = ID 

#denied-smsc-id = "X;Y" 

#allowed-smsc-id = "Z" 

#preferred-smsc-id = "W" 

#allowed-prefix = "040;050" 

#denied-prefix = "060;070" 

#alt-charset = 

# SMSC SMPP 

group = smsc 

smsc = smpp 

smsc-id = SMPPSim 

preferred-smsc-id = SMPPSim 

host = 192.168.1.105 

port = 2775 

transceiver-mode = true 

receive-port = 0 

smsc-username = smppclient1 

smsc-password = password 

system-type = "" 

address-range = "" 

msg-id-type = 0x01 

alt-charset = "ISO-8859-1" 

interface-version = 34 

wait-ack-expire = 0x02 


90



# SMSC GSM 

#group = smsc 

#smsc = at 

#modemtype = huawei 

#device = /dev/ttyUSB1 

#my-number = 771669574 

#pin = 2345 

#validityperiod = 167 

# SMSC HTTP 

#group = smsc 

#smsc = http 

#system-type = kannel 

#send-url = 

#port = 

#connect-allow-ip = 

#username = 

#password = 

# SMSBOX SETUP 

group = smsbox 

bearerbox-host = localhost 

sendsms-port = 13013 

sendsms-chars = "0123456789 +-" 

global-sender = 12345 

log-file = "/tmp/smsbox.log" 

#log-level = 0 

access-log = "access.log" 


91



#white-list = 

#black-list = 

#reply-couldnotfetch = 

#reply-couldnotrepresent = 

#reply-requestfailed = 

#reply-emptymessage = 

# SEND-SMS USERS 

group = sendsms-user 

username = tester 

password = foobar 

#user-deny-ip = "" 

#user-allow-ip = "" 

# this sender is for Kannel relay testing (http_smsc) 

group = sendsms-user 

username = kannel 

password = rL4y 

user-deny-ip = "*.*.*.*" 

user-allow-ip = "127.0.0.1" 

#name = service_kannel 

#forced-smsc = ID 

#default-smsc = ID 

#faked-sended = 

#max-messages = 1 

#concatenation = 1 

#split-chars = 

#split-suffix = 

#omit-empty = 

#header = 


92



#footer = 

#allowed-prefix = 

#denied-prefix = 

#white-list = 

#black-list = 

# SMS SERVICES 

#group = sms-service 

#name = nothing 

#keyword = nop 

#aliases = "noppy;niente" 

#text = "You asked nothing and I did it!" 

#get-url = "http://" 

#post-url = "http://" 

#file = "/tmp/" 

#accepted-smsc = ID 

#allowed-prefix = 

#denied-prefix = 

#catch-all = false 

#send-sender = false 

#strip-keyword = false 

#faked-sender = 

#max-messages = 1 

#accept-x-kannel-headers = false 

#assume-plain-text = false 

#concatenation = false 

#split-chars = 

#split-suffix = "+" 

#omit-empty = true 


93



#header = 

#footer = 

#prefix = 

#suffix = 

#white-list = 

#black-list = 

# SMS SERVICE GET-URL EXAMPLE 


#keyword = relay 

#get-url = "http://localhost/service?phone=%p&text=%r&binary=%b&smsc=$i&time=%t 

group = sms-service 

keyword = solde 

catch-all = true 

get-url = 

"http://localhost/projet/service.php?phone=%p&sms=%a&text=%r&binary=%b&smsc=$i&tim 

e=%t&keyword=%k" 

accept-x-kannel-headers = true 

# SMS SERVICE black-list 


#keyword = black-list 

#text = "You are not alowed to use this service, Go away!" 

# SMS SERVICE Default 

# there should be default always 


keyword = ec2lt 

text = "Bonjour Hapsita" 

#get-url = 

"http://localhost/projet/service.php?phone=%p&text=%r&binary=%b&smsc=$i&time=%t" 

# SMS SERVICE Default 

# there should be default always 


94




#keyword = solde 

#catch-all = true 

#get-url = 

"http://localhost/projet/service.php?phone=%p&sms=%a&text=%r&binary=%b&smsc=$i&tim 

e=%t&keyword=%k" 

#accept-x-kannel-headers = true 


keyword = cmd 

exec = /usr/bin/eject 

group = modems 

id = huawei 

name = "huawei e1552" 

detect-string = "Huawei" 

init-string = "AT+CNMI=2,1,0,0,0" 

message-storage = "ME" 

speed = 9600 

Annexe2 : Démarrage de Kannel 

Le bearerbox 


95



Le smsbox 

Annexe 3 : Exemples de modems GSM 


96



Annexe 4 : Démarrage de SMPPSim 

Annexe 5 : Exemples d’Interface d’administration de SMS Banking 


97



Annexe 6 : Capture de trame smpp avec wireshark 


98




99

REMERCIEMENTS - EC2LT

Create successful ePaper yourself

Delete template?

Save as template?