LABBASSI Mustapha

Cycle de formation des ingénieurs en Télécommunications
Option :
Réseaux et services mobiles
Rapport de Projet de …n d’études
Thème :
Développement d’un prototype de service mobile :
Gestionnaire d’absence
Réalisé par :
Mustapha LABASSI
Encadrants :
M. Mourad LAHMADI Alcatel-Lucent Tunisie

Pr. Sami TABBANE Sup’Com
Travail proposé et réalisé en collaboration avec :
Année universitaire : 2006/2007

Dédicace
A ma famille
i
Avant propos
Le présent travail constitue un projet de …n d’études pour l’obtention du diplôme

national d’ingénieur en télécommunications de l’Ecole Supérieure des Communications
de Tunis (Sup’Com).
Réalisé au de sein de l’espace partenariat d’Alcatel-Lucent Tunisie, ce projet s’inscrit

dans le cadre du programme "Value Added Reality Center" destiné à élargir l’o¤re de
services à valeur ajoutée de cette entreprise, en encourageant des stagiaires à proposer
et à concevoir des services mobiles novateurs.
ii
Table des matières
Avant Propos ii
Table des matières iii
Table des …gures iv
Liste des tableaux v
Liste des abréviations vi
Introduction générale 1
I Présentation du service 2
1 Idée du service 3
1.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Description des di¤érentes fonctionnalités du service . . . . . . . . . . . 3
1.2.1 Filtrage des appels entrants . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Noti…cation d’absence prolongée . . . . . . . . . . . . . . . . . . 4
1.2.3 Journal des connexions . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Intérêt du service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Cible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Possibilités d’extension . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Etude de marché 8
2.1 Intérêt des opérateurs téléphoniques pour les Services à Valeur Ajoutée 8
2.2 Volume et taille du marché . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Estimation de la part de marché à atteindre . . . . . . . . . . . . . . . 10
2.3.1 Données du marché européen . . . . . . . . . . . . . . . . . . . 10
2.3.2 Analyse et extrapolation . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Etat du marché . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Analyse de la demande . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
II Etude d’une architecture pour le service 14

3 Etude de l’existant 15
3.1 Description du service PRBT . . . . . . . . . . . . . . . . . . . . . . . 15
iii
TABLE DES MATIÈRES
3.2 En quoi le PRBT peut nous être utile ? . . . . . . . . . . . . . . . . . . 15

3.2.1 Structure de la solution PRBT . . . . . . . . . . . . . . . . . . 16
3.2.2 Quel rôle joue le SCP dans la solution ? . . . . . . . . . . . . . . 18
3.3 Conclusion de l’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Architecture fonctionnelle du service 20

4.1 Content Management System . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Network Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1 IN Based Con…guration . . . . . . . . . . . . . . . . . . . . . . 22
4.2.2 Service Node Based con…guration . . . . . . . . . . . . . . . . . 25
4.2.3 Choix de la solution . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
III Conception du service 30

5 Conception de l’application 31
5.1 Identi…cation des acteurs de l’application . . . . . . . . . . . . . . . . . 31
5.2 Spéci…cation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.2 Besoins non-fonctionnels . . . . . . . . . . . . . . . . . . . . . . 33
5.3 Organisation en paquetages . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3.1 Description des liens entre paquetages . . . . . . . . . . . . . . 34
5.4 Diagrammes des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 35
5.4.1 Cas d’utilisation du paquetage "Network Adaptation Module" . 35
5.4.2 Cas d’utilisation du paquetage "Noti…cation Module" . . . . . . 36
5.4.3 Cas d’utilisation du paquetage "User Module" . . . . . . . . . . 37
5.4.4 Cas d’utilisation du paquetage "HLR-MD Module" . . . . . . . 40
5.5 Diagrammes des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5.1 Diagramme des classes du paquetage "User Module" . . . . . . 41
5.5.2 Diagramme des classes du paquetage "Network Adaptation Mo-
dule" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.5.3 Diagramme des classes du paquetage "Noti…cation Module" . . 43
5.5.4 Diagramme des classes du paquetage "HLR-MD Module" . . . . 44
5.6 Diagrammes d’interaction . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.6.1 Diagramme d’interaction décrivant les étapes de création d’un
nouveau compte . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.6.2 Diagramme d’interaction décrivant les étapes de personnalisation
du pro…l utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.6.3 Diagramme d’interaction décrivant la gestion du service . . . . . 46
5.6.4 Diagramme d’interaction décrivant le fonctionnement du service 47
5.6.5 Diagramme d’interaction décrivant les étapes de consultation du
journal de connexion par l’abonné . . . . . . . . . . . . . . . . . 48
5.7 Description de la base de données . . . . . . . . . . . . . . . . . . . . . 49
5.7.1 Contenu des tables de la base de données . . . . . . . . . . . . . 49
5.7.2 Description des tables de la base de données . . . . . . . . . . . 49
5.7.3 Gestionnaire de base de données . . . . . . . . . . . . . . . . . . 50
iv
TABLE DES MATIÈRES
6 Conception d’une plateforme de simulation du service 51

6.1 Rôle de la plateforme de simulation . . . . . . . . . . . . . . . . . . . . 51
6.2 Organisation du service intégré à la plateforme de simulation . . . . . . 52
6.3 Architecture de la plateforme de simulation . . . . . . . . . . . . . . . . 52
6.4 Fonctionnement de la plateforme de simulation . . . . . . . . . . . . . . 53
6.4.1 Interface du simulateur . . . . . . . . . . . . . . . . . . . . . . . 55
7 Réalisation 59
7.1 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.1.1 Outils de conception . . . . . . . . . . . . . . . . . . . . . . . . 59
7.1.2 Environnement d’implémentation . . . . . . . . . . . . . . . . . 59
7.2 Aperçu du travail accompli . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2.1 Page d’inscription . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2.2 Page de connexion . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2.3 Panneau de con…guration . . . . . . . . . . . . . . . . . . . . . 60
7.2.4 Page « Mes MMS Post Card » . . . . . . . . . . . . . . . . . . 62
7.2.5 Page « Ajouter un MMS Post Card » . . . . . . . . . . . . . . 62
7.2.6 Page « Mes groupes de contacts » . . . . . . . . . . . . . . . . 62
7.2.7 Page « Ajouter un groupe de contact » . . . . . . . . . . . . . . 64
7.2.8 Page « Mes contacts » . . . . . . . . . . . . . . . . . . . . . . . 64
7.2.9 Page « Ajouter un contact » . . . . . . . . . . . . . . . . . . . 64
Conclusion 66
Bibliographie 67
v
Table des …gures
1.1 Schéma descriptif de l’option "Filtrage des appels entrants" . . . . . . . 4

1.2 Schéma descriptif de l’option "noti…cation d’absence" . . . . . . . . . . 5
1.3 Schéma descriptif de l’option "Journal des connexions" . . . . . . . . . 5
1.4 Schéma descriptif du service global . . . . . . . . . . . . . . . . . . . . 6
2.1 Evolution annuelle du nombre des abonnés de la téléphonie mobile en

Tunisie (source : Instance Nationale des Télécommunications) . . . . . 9
3.1 Principe de fonctionnement du service PRBT . . . . . . . . . . . . . . 15

3.2 Architecture du service PRBT . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Récupération de l’identi…ant EMID du …chier RBT à lancer . . . . . . 17
3.4 Rôle du SCP dans la gestion de l’appel . . . . . . . . . . . . . . . . . . 18
4.1 Architecture de la solution proposée . . . . . . . . . . . . . . . . . . . . 20

4.2 Architecture de la solution IN BASED . . . . . . . . . . . . . . . . . . 22
4.3 Processus de déclenchement IN BASED (pour le premier cas) . . . . . 23
4.4 Processus de déclenchement IN BASED (pour le deuxième cas) . . . . 24
4.5 Architecture de la solution "Service Node Based" . . . . . . . . . . . . 26
4.6 Processus de déclenchement Service Node BASED (pour le premier cas) 26
4.7 Processus de déclenchement Service Node BASED (pour le deuxième cas) 27
5.1 Dé…nition des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Diagramme de paquetage général . . . . . . . . . . . . . . . . . . . . . 34
5.3 Diagramme des cas d’utilisation du paquetage "Network Adaptation Mo-
dule" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Diagramme des cas d’utilisation du paquetage "Noti…cation Module" . 36
5.5 Diagramme de cas d’utilisation du paquetage "User Module" . . . . . . 37
5.6 Diagramme de cas d’utilisation du paquetage "HLR-MD Module" . . . 40
5.7 Diagramme des classes du paquetage "User Module" . . . . . . . . . . 42
5.8 Diagramme des classes du paquetage "Network Adaptation Module" . . 43
5.9 Diagramme des classes du paquetage "Noti…cation Module" . . . . . . 43
5.10 Diagramme des classes du paquetage "HLR-MD Module" . . . . . . . . 44
5.11 Diagramme d’interaction décrivant les étapes de création d’un compte . 45
5.12 Diagramme d’interaction décrivant les étapes de personnalisation du pro-
…l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.13 Diagramme d’interaction décrivant la gestion du service . . . . . . . . . 47
5.14 Diagramme d’interaction décrivant le fonctionnement du service . . . . 48
5.15 Diagramme d’interaction décrivant les étapes de consultation du journal
de connexion par l’abonné . . . . . . . . . . . . . . . . . . . . . . . . . 49
vi
TABLE DES FIGURES
5.16 Diagramme de la base de données du service . . . . . . . . . . . . . . . 50
6.1 Architecture du service intégré à une plateforme de simulation . . . . . 52

6.2 Structure de plateforme de simulation . . . . . . . . . . . . . . . . . . . 53
6.3 Fonctionnement de la plateforme de simulation dans le 1er cas de …gure 54
6.4 Fonctionnement de la plateforme de simulation dans le 2ème cas de …gure 55
6.5 Aperçu de la page de saisie des paramètres d’entrée . . . . . . . . . . . 56
6.6 Aperçu de la page d’a¢ chage du rapport de simulation (1er cas) . . . . 57
6.7 Aperçu de la page d’a¢ chage du rapport de simulation (2ème cas) . . . 58
7.1 Aperçu de la page d’inscription au service . . . . . . . . . . . . . . . . 60

7.2 Aperçu de la page de connexion au compte de con…guration . . . . . . 61
7.3 Aperçu du panneau de con…guration . . . . . . . . . . . . . . . . . . . 61
7.4 Aperçu du panneau de con…guration des MMS Post Card . . . . . . . . 62
7.5 Aperçu de la page d’ajout d’un nouvel MMS Post Card . . . . . . . . . 63
7.6 Aperçu du panneau de con…guration des groupes de contacts . . . . . . 63
7.7 Aperçu de la page d’ajout d’un nouveau groupe de contact . . . . . . . 64
7.8 Aperçu du panneau de con…guration des contacts . . . . . . . . . . . . 65
7.9 Aperçu de la page d’ajout d’un nouveau contact . . . . . . . . . . . . . 65
vii
Liste des tableaux
2.1 Principaux indicateurs de Tunisiana (source : Orascom Télécom) . . . . 9

2.2 Volume global du marché cible . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Pourcentage et répartition des Roamers dans une population européenne
(source : Commission Européenne) . . . . . . . . . . . . . . . . . . . . 11
2.4 Classements des services de données par ordre de préférence (source :
Circle Research for the GSMA) . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Description des blocs de service . . . . . . . . . . . . . . . . . . . . . . 21
5.1 Identi…cation et description des acteurs . . . . . . . . . . . . . . . . . . 32

5.2 Description des classes du paquetage "User Module " . . . . . . . . . . 41
5.3 Description des classes du paquetage "Network Adaptation Module" . . 43
5.4 Description des classes du paquetage "Noti…cation Module" . . . . . . 44
5.5 Description des classes du paquetage "HLR-MD Module" . . . . . . . . 44
viii
Liste des abréviations
ARPU : Average Revenue Per User

CMS : Content Management System
G-MSC : Gateway - Mobile Switching Center
GPRS : General Packet Radio Service
GSL : Global Service Logic
GSM : Global System for Mobile Communications
HLR : Home Location Register
HLR-MD : Home Location Register - Mediation Device
IDE : Integrated Development Environment
IVR : Interactive Voice Response
JSP : Java Server Pages
JVM : Java Virtual Machine
MMS : Multimedia Messaging Service
NAP : Network Adaptation Platform
PRBT : Personal Ring Back Tone
SCF : Service Control Function
SCP : Service Control Point
SGBD : Système de Gestion de Base de Données
SMS : Short Message Service
SQL : Structured Query Language
SS7 : Signaling System 7
SSP : Service Switching Point
TCP/IP : Transmission Control Protocol / Internet Protocol
UML : Uni…ed Modeling Language
UMTS : Universal Mobile Telecommunication System
VIP : Very Important Person
WAP : Wireless Application Protocol
ix
Introduction générale
Le pragmatisme de l’abonné à la téléphonie mobile vis-à-vis des nouvelles technolo-

gies de communication fait qu’aujourd’hui le service MMS n’est toujours pas parvenu à
être associé à une valeur d’usage supérieure à d’autres services de communication plus
courants. Un constat qui a pour e¤et d’amener les opérateurs de téléphonie mobile à
miser sur le MMS en tant que base pour d’autres services à valeur ajoutée.
C’est donc dans ce cadre que s’inscrit le présent projet de …n d’études puisqu’il
s’agit de proposer et de développer un prototype de service mobile inédit exploitant
les ressources du service MMS et destiné par la suite à l’appréciation d’opérateurs de
téléphonie mobile à la recherche de services innovants.
L’idée du service retenu par mon encadreur à Alcatel-Lucent est partie d’une évi-
dence : Les abonnés en partance pour l’étranger n’ont pas nécessairement le ré‡exe
d’emporter avec eux leur portable pour une éventuelle utilisation en mode "Roaming".
En e¤et, les tarifs pratiqués pour le "Roaming International" n’incitent guère les usa-
gers à y avoir systématiquement recours pendant leurs séjours à l’étranger, d’autant
plus que la tari…cation intervient en émission et en réception d’appel.
Le service proposé dans ce mémoire ambitionne donc d’encourager les réfractaires à
adopter le "Roaming International" en proposant un ensemble de fonctionnalités utiles
et séduisantes destinées à permettre à l’abonné de gérer de manière e¢ cace son crédit
en mode "Roaming" et d’organiser une éventuelle absence prolongée.
En plus du fort sentiment d’une parfaite maîtrise du niveau de consommation qu’il
confère à l’abonné, ce service permettra à l’opérateur qui le propose de réduire consi-
dérablement le manque à gagner dû à la réticence des consommateurs vis-à-vis du
"Roaming International".
Comme le démontrera ce rapport, le travail e¤ectué au cours de ce projet, est orga-
nisé en trois grandes parties :
Une première partie « Description du service » consacrée à la présentation du service
et à la description détaillée de l’ensemble des fonctionnalités envisagées. Cette partie
comprend également une étude de marché destinée à véri…er le potentiel de rentabilité
du service.
Une deuxième partie intitulée « Etude d’une architecture pour le service » dans
laquelle sont proposées deux con…gurations possibles pour l’architecture du service.
Une troisième et dernière partie intitulée « Conception du service » trace les étapes
de modélisation et de conception de l’application chargée de la gestion et de l’exécution
du service.
1
Première partie
Présentation du service
2
Chapitre 1
Idée du service
1.1 Problématique
Il est souvent admis que chaque fois que l’on se trouve à l’étranger, la tentation
est grande de lésiner sur l’utilisation de son téléphone portable en raison des coûts du
"Roaming International" parfois très élevés que ce soit en émission ou en réception
d’appel.
En tenant compte de ce comportement qui tend à se généraliser, il est facile d’imagi-

ner dès lors l’agacement des correspondants, ignorant l’absence de la personne contactée,
devant l’insupportable attente d’une réponse.
Il serait alors utile de trouver un moyen qui permettrait à l’abonné "Roamer" de

mieux gérer son solde en lui o¤rant la possibilité de …ltrer les appels non importants.
En outre, la solution devra fournir au client "Roamer" le moyen d’informer les

correspondants "…ltrés", qui tentent d’entrer en contact avec lui (par SMS ou par appel
vocal), de son absence par l’envoi automatique d’une carte postale sous forme de MMS
contenant des informations telles que : une photo de la ville visitée, l’objet de son
absence, la date de son retour. . .
Un tel service permettra donc à l’abonné qui n’a pas forcément eu le temps de préve-
nir tout son entourage de son absence, de le faire de manière courtoise et personnalisée,
tout en maîtrisant sa facture téléphonique en mode "Roaming". Il s’agit donc d’un
moyen permettant d’organiser l’absence d’un client en lui évitant d’avoir à répondre à
l’ensemble de ses correspondants.
1.2 Description des di¤érentes fonctionnalités du

service
Le service que nous nous proposons de développer dans ce projet est un gestionnaire
d’absence capable d’organiser l’absence d’un abonné grâce à un ensemble de fonction-
nalités.
3
CHAPITRE 1. IDÉE DU SERVICE
Les fonctionnalités que nous envisageons pour ce service portent, comme nous al-
lons le décrire ci-après, sur un …ltrage des appels entrants, une noti…cation d’absence
prolongée et un journal des connexions.
1.2.1 Filtrage des appels entrants

L’abonné a la possibilité de con…gurer (via une interface WEB ou WAP) une liste
de numéros VIP. Ces numéros VIP sont autorisés à entrer en contact avec l’abonné au
service, à condition bien sûr que son téléphone soit allumé. Les numéros qui n’appar-
tiennent pas à cette liste seront …ltrés (bloqués) et les informations associées (numéro
d’appel, heure d’appel, date. . . ) seront enregistrés au niveau du journal des connexions.
Appelant
non-VIP
Traitement
Abonné
Réception Tentative
Client
Appel VIP de contact
SERVICE
Activation Tentative
filtrage de contact
Appelant
VIP
Fig. 1.1 –Schéma descriptif de l’option "Filtrage des appels entrants"
L’option de …ltrage peut être très utile si l’abonné, se trouvant en mode Roaming
international, choisit de ne recevoir qu’une catégorie d’appels (par exemple : appels
familiaux, appels professionnels. . . ). De cette manière, l’abonné gère plus e¢ cacement
son budget dans la mesure où il n’est plus obligé de répondre aux appels qu’il juge
non-importants.
Dans notre service, la fonction de …ltrage est automatiquement activée pour tous
les appels entrants. A l’abonné ensuite de sélectionner les numéros VIP qu’il accepte
de recevoir.
1.2.2 Noti…cation d’absence prolongée

Nous avons imaginé cette fonctionnalité dans le but de permettre à l’abonné (télé-
phone allumé ou éteint) d’informer tous ceux qui tentent de le contacter (par simple
appel vocal ou SMS) de son absence prolongée par l’envoi d’une carte postale sous forme
de MMS contenant des informations utiles du type : durée du séjour, destination, objet
du séjour, date de retour, photos de la ville visitée. . .
4
L’envoi a lieu lorsqu’un utilisateur, n’appartenant pas à la liste VIP, tente un appel.
L’appel est alors tout de suite interrompu (bloqué) et un signal d’indisponibilité est
alors émis.
Etapes du processus (processus illustré par la …gure 1.2) :
1. Activation du service+paramétrage (insertion du contenu du message MMS)
2. Tentative d’appel
3. Appel interrompu+Emission d’un signal d’indisponibilité+Envoi du MMS
4. Réception du MMS Post Card
(3)
(2)
Abonné (1) Appelant
Tentative de
Client « Je suis à Paris pour contact
mon PFE,
L’ambiance est géniale, SERVICE
je serai de retour (4)
le 10/06/2007 »
Fig. 1.2 –Schéma descriptif de l’option "noti…cation d’absence"
La noti…cation d’absence prolongée est une fonctionnalité utile puisque l’abonné

arrive à prévenir son entourage de son absence sans avoir à répondre à tous les appels
qu’il reçoit ou mieux encore, être obligé de raccrocher évitant ainsi de prendre le risque
d’agacer son correspondant.
1.2.3 Journal des connexions

Le journal des connexions s’inspire d’un service lancé récemment par Tunisiana
(Missed Call Alert).
Abonné ASMA
Tentative
Client de contact
Consultation Tentative
configuration
HTTP SERVICE de contact ALI
Tentative
de contact
BOB
Fig. 1.3 –Schéma descriptif de l’option "Journal des connexions"
5
Cette fonctionnalité sert à permettre à l’abonné au service de consulter le journal

des appels bloqués ou SMS manqués. De cette façon, l’abonné, malgré son absence
(réelle ou simulée), peut consulter les numéros des personnes qui ont tenté de le joindre
et qui ont reçu sa carte postale MMS.
Le journal de connexions permet donc à l’abonné d’être informé des appels bloqués
pour qu’il puisse, s’il le désire, recontacter les appelants "…ltrés" à son retour au pays.
Il est à noter qu’il est prévu que la consultation se fasse via une interface WEB.
Nous pouvons résumer toutes ces fonctionnalités grâce au schéma de la …gure 1.4.
N’appartient pas à
la liste VIP
Tentative
de contact
Abonné Carte postale

Client
Réception
de l’appelant VIP
SERVICE
Consultation Appelant VIP

HTTP
configuration Appel vers le client
Fig. 1.4 –Schéma descriptif du service global
1.3 Intérêt du service

Un service comme celui-ci permet à l’utilisateur abonné de :
– maîtriser sa facture téléphonique (en mode Roaming international)
– prévenir son entourage de manière courtoise et personnalisée de son absence pro-
longée
– …ltrer les appels importants
1.4 Cible
– Les abonnés entre 18 et 55 ans (plus grande part de marché)
6
– Les abonnés équipés de terminaux compatibles GPRS

– Hommes d’a¤aire, touristes, voyageurs réguliers, étudiants à l’étranger. . .
1.5 Possibilités d’extension

Il est possible d’adapter notre service à d’autres cas d’utilisation : "En voyage",
"En cours", "Au travail", "Occupé". . . De cette façon, l’abonné qui ne désire pas être
dérangé a la possibilité d’adapter le service à ses besoins immédiats.
7
Chapitre 2
Etude de marché
L’étude de marché est une étape indispensable dans le processus de création d’un
service mobile puisqu’elle va nous permettre d’a¢ ner notre idée du service et véri…er
qu’elle correspond à une véritable opportunité.
Il est donc important de bien identi…er les besoins et les attentes des consommateurs
a…n de ne pas gaspiller inutilement du temps et de l’argent dans la conception d’un
service ne satisfaisant pas les objectifs souhaités. Car il est primordial de véri…er que
les clients escomptés existent réellement (qu’il y a des besoins identi…és à satisfaire,
qu’actuellement ces besoins ne sont pas ou mal satisfaits et que ces futurs clients sont
su¢ samment nombreux).
L’étude de marché que nous nous proposons de mener consistera donc à rechercher
les informations permettant d’acquérir une bonne connaissance de l’environnement, de
la concurrence, et de l’o¤re et de la demande. Pour ce faire, nous adopterons la démarche
décrite dans [1] et [2].
Les résultats de cette étude de marché vont donc nous permettre de valider ou
d’invalider la mise en marché du service.
2.1 Intérêt des opérateurs téléphoniques pour les

Services à Valeur Ajoutée
Avec près de 7,5 millions d’abonnés répartis entre les deux opérateurs Tunisie Télé-
com et Tunisiana, le marché tunisien de la téléphonie mobile pourrait, comme l’atteste
la Figure 2.1, plafonner en attendant l’arrivée de l’UMTS.
Grâce à cette évolution, la densité téléphonique globale (…xe et mobile) atteint au-
jourd’hui 84,47 lignes pour 100 habitants. Il est donc facile d’imaginer que les résultats
des opérateurs téléphoniques ne devraient plus dépendre des services de base (appels vo-
caux et SMS) mais seraient davantage conditionnés par l’attractivité des futurs services
qui seront proposés aux abonnés.
Ainsi, comme le con…rme l’analyse publiée dans [3], un opérateur qui souhaite ac-
croître ses revenus d’abonnés ARPU1 a intérêt à miser sur l’élargissement de sa gamme
de produits et services à valeur ajoutée.
1
ARPU : Average Revenue Per User
8
CHAPITRE 2. ETUDE DE MARCHÉ
8000000
7000000
6000000
Nombre d'abonnés
5000000
4000000
3000000
2000000
1000000
0
2000 2001 2002 2003 2004 2005 2006
Fig. 2.1 –Evolution annuelle du nombre des abonnés de la téléphonie mobile en Tunisie
(source : Instance Nationale des Télécommunications)
Nombre d’abonnés 3 100 000

Part de marché 46,5 %
ARPU 13,3 $ US
Services à valeur ajoutée SMSWeb2SMS
SMS2Email
Info Services
Email Noti…cation
Voice Mail
Limited list of calls
Personal Ring Back Tone
Data
Tab. 2.1 –Principaux indicateurs de Tunisiana (source : Orascom Télécom)
Le service que nous nous proposons de développer au cours de ce projet sera vraisem-
blablement vendu à Tunisiana qui est un partenaire privilégié d’Alcatel-Lucent Tunisie.
Ainsi, nous allons exploiter, au cours de notre étude de marché, les indicateurs et les
di¤érentes informations rendues publiques par Tunisiana.
Comme le montre le tableau 2.1, Tunisiana dispose déjà d’un large éventail de ser-
vices à valeur ajouté, ce qui illustre la volonté de Tunisiana à essayer d’o¤rir à ses
abonnés des services inédits et innovants.
Ce constat nous encourage donc à croire que notre service a des chances d’intéresser
Tunisiana qui cherche des services capables d’exercer un e¤et positif sur son image de
marque.
9
Segment de marché Volume (estimé)

Etudiants tunisiens à l’étranger 13000
Voyageurs tunisiens / par an 1 700 000
Total 1 713 000
Tab. 2.2 –Volume global du marché cible
2.2 Volume et taille du marché

Le service que nous nous proposons de développer au cours de ce projet, se destine
principalement aux utilisateurs qui voyagent régulièrement pour des périodes plus ou
moins longues et dont l’utilisation du téléphone portable en mode "Roaming Interna-
tional" constitue une charge …nancière lourde.
A première vue, le service "Gestionnaire d’absence" pourrait très bien répondre aux
besoins des :
– Etudiants à l’étranger
– Voyageurs réguliers (hommes d’a¤aires, cadres. . . )
– Touristes occasionnels
En identi…ant de cette manière les consommateurs potentiels, nous pouvons procéder

à une segmentation du marché qui nous permettra par la suite d’évaluer le volume du
marché cible et d’anticiper les possibilités d’utilisation du service.
Des informations collectées auprès d’organismes compétents (O¢ ce National du

Tourisme, Ministère de l’enseignement supérieur, O¢ ce des Tunisiens à l’Etranger)
nous ont permis d’établir le tableau 2.2.
Ce tableau estime le volume du marché global à 1713000 consommateurs. Or le

marché visé est toujours plus petit que le marché global car il est impensable que
notre service puisse capturer tout le marché. Nous devons donc e¤ectuer une étude qui
permettra d’estimer raisonnablement la part du marché que nous pouvons atteindre.
2.3 Estimation de la part de marché à atteindre

Comme il n’existe pas à ce jour d’études rendues publiques permettant d’estimer
le nombre d’abonnés tunisiens ayant recours au "Roaming International". Il est par
conséquent di¢ cile d’évaluer et de quanti…er notre marché cible.
Nous allons donc essayer d’exploiter des données disponibles en Europe et tenter une
extrapolation à l’échelle de la Tunisie. Nous appliquons bien évidemment l’hypothèse
que l’analyse de notre marché cible serait semblable au marché européen mais en tenant
compte de certaines réalités propre au marché tunisien.
2.3.1 Données du marché européen

Une étude publiée dans [4] par la Commission Européenne et destinée à évaluer
le marché européen du "Roaming International" a révélé que 8 européens sur 10 sont
10
abonnés à la téléphonie mobile, ce qui représente donc 395 millions d’abonnés répartis
à travers les 27 Etats membres de l’Union.
L’étude montre aussi que 36% des abonnés européens ont recours à l’itinérance ce
qui devrait représenter une population de 147 millions d’utilisateurs. Parmi ces abonnés
itinérants, 110 millions ont recours au "Roaming International" lors de déplacements
professionnels et 37 millions l’utilisent en tant que touristes.
Toutes ces valeurs peuvent être résumées dans le tableau 2.3.
% des abonnés Usage professionnel Usage touristique
Population de Roamers 36 % 74,8 % 25,2 %
Tab. 2.3 – Pourcentage et répartition des Roamers dans une population européenne
(source : Commission Européenne)
Avant de tenter une estimation du nombre de Roamers tunisiens à partir des données
enregistrées en Europe, nous devons tenir compte de certaines spéci…cités socioécono-
miques, comme par exemple, le niveau de vie des deux populations étudiées, leur mode
de vie, leur pouvoir d’achat.
2.3.2 Analyse et extrapolation

Intéressons-nous tout d’abord aux données relatives aux habitudes des populations
européennes par rapport aux déplacements vers l’étranger.
Une étude réalisée en 2004 par Eurostat2 révèle que 43,1% des européens ont e¤ectué
au moins un séjour de 4 nuitées ou plus à l’étranger. Si nous associons ce chi¤re au taux
de pénétration de la téléphonie mobile en Europe (80%) et au fait que 36% des abonnés
ont recours au "Roaming International", nous pouvons supposer que 85% des abonnés
au mobile, qui voyagent, ont recours à l’itinérance inter-pays.
L’indicateur que nous allons maintenant considérer est l’ARPU. En e¤et, l’ARPU va
nous permettre de comparer les habitudes de consommation des populations étudiées.
D’après IDATE3 , l’ARPU moyen européen en 2005 s’élève à 36 $ US alors que
l’ARPU moyen enregistré par l’opérateur Tunisiana ne s’élève qu’à 13,3 $ US.
Cette di¤érence de revenus nous montre clairement que l’abonné tunisien consomme
beaucoup moins que son homologue européen. Ceci est probablement l’e¤et du faible
pouvoir d’achat de l’abonné tunisien comparé à un abonné européen.
De ce constat, nous pouvons présumer que la capacité des abonnés tunisiens à
consommer en mode « Roaming International » est assez limitée. Ce qui nous incite à
croire que tous les abonnés tunisiens ne sont pas disposés à utiliser leur téléphones lors
d’un déplacement vers l’étranger.
Ainsi, si, en s’appuyant sur cette analyse, nous devions nous risquer à estimer le pour-
centage des abonnés tunisiens à recourir au Roaming au cours d’un voyage à l’étranger,
il se situerait entre 50 et 60 %.
2
Eurostat : European Statistical Date Support
3
IDATE : Institut de l’Audiovisuel et des Télécommunications en Europe
11
2.4 Etat du marché

Il est important d’être conscient que des éléments techniques peuvent constituer
un frein au succès de notre service. En e¤et, nous devons, au cours de cette étude,
nous assurer que la cible est correctement équipée pour recevoir convenablement notre
service.
Selon une étude du groupe allemand d’étude de marché, GFK, la vente des télé-
phones portables a connu, en Tunisie, une importante progression durant l’année 2006.
Selon GKF, il s’est vendu, rien qu’en 2006, 1 700 000 portables, soit une progression
de 15 %. Les abonnés tunisiens privilégient les appareils sophistiqués munis d’un écran
couleurs ou d’un appareil photo. Les portables munis d’un écran couleurs représentent
73% et ceux dotés d’un appareil photo 32% des ventes. Bien entendu, ces chi¤res ne
concernent que les revendeurs du circuit o¢ ciel et ne tiennent pas compte du marché
parallèle.
Dans la mesure où les consommateurs ciblés voyagent régulièrement, nous pouvons

alors supposer qu’ils sont en mesure de s’o¤rir des terminaux su¢ samment évolués pour
accueillir correctement notre service.
2.5 Analyse de la demande

Dans cette partie, nous allons tenter de déterminer les attentes des segments de
marché que nous voulons cibler et connaître les attentes des clients par rapport à notre
service.
Service Rang
SMS 1
E-mail 2
MMS 3
Noti…cation via SMS/MMS 4
Messagerie instantanée 5
Navigation Web 6
Tab. 2.4 –Classements des services de données par ordre de préférence (source : Circle
Research for the GSMA)
Si nous nous référons au classement (Tab. 2.4) des services de données les plus
populaires, obtenu grâce à une étude réalisée sur une population de 3061 abonnés à
travers le monde, nous pouvons remarquer que la catégorie à laquelle appartient notre
service se situe à la 4ème place. Ce classement prouve qu’il existe une réelle attente des
abonnés.
Comme nous l’avons déjà indiqué dans la partie précédente, notre service cible en
priorité les abonnés qui partent régulièrement à l’étranger et qui lésinent sur l’utilisation
du téléphone portable en raison des coûts élevés du "Roaming International".
Il existe deux types de comportements propres à ce segment d’abonnés :
12
– Ceux qui utilisent leur téléphone seulement en cas d’urgence.

– Ceux qui préfèrent laisser leur téléphone chez eux.
A partir de cette distinction, nous pouvons facilement imaginer que le béné…ce

dégagé par l’opérateur à partir du service "Roaming" peut être considéré comme faible
voire même négligeable.
Notre service se propose donc d’inciter ces utilisateurs réticents à utiliser leurs té-
léphones portables à l’étranger et ce, en mettant à leur disposition un ensemble de
fonctionnalités leur permettant de mieux maîtriser leur consommation grâce à l’option
de …ltrage d’appel et de faciliter leur départ à travers l’option de noti…cation d’absence
personnalisée.
Une manière donc de réconcilier les abonnés avec le recours au "Roaming Interna-
tional" en cas de déplacement.
Pour ce qui est des besoins des étudiants tunisiens à l’étranger, les besoins révélés
sont d’un autre genre, puisque leur absence souvent très longue ne leur permet pas du
tout d’utiliser leur ligne "tunisienne" en mode Roaming préférant l’utilisation d’une
ligne téléphonique locale, moins coûteuse.
A ce segment d’abonnés, nous pouvons répondre à leurs besoins en insistant sur

l’option "Noti…cation d’absence prolongée" car ces abonnés pourraient avoir besoin de
prévenir leurs contacts de leur absence et de leur transmettre un numéro de téléphone
qui leur permettrait d’être joints.
2.6 Conclusion
L’analyse des résultats et données collectées au cours de cette étude de marché a
permis d’aboutir à une estimation révélant un potentiel de marché favorable au déploie-
ment du service "Gestionnaire d’absence".
En e¤et, le cadre que nous venons d’identi…er montre qu’il existe bel et bien une
demande, certes latente, mais une demande qui peut être satisfaite par l’ensemble des
fonctionnalités que nous avons imaginées pour notre service. D’autant plus que l’opé-
rateur de téléphonie mobile qui proposera notre service, n’aura pas à sou¤rir d’un
environnement concurrentiel rude en raison du caractère inédit du service.
Les résultats de cette étude renforcent donc l’idée que le service "Gestionnaire d’ab-
sence" constitue une véritable opportunité.
13
Deuxième partie
Etude d’une architecture pour le

service
14
Chapitre 3
Etude de l’existant
A…n de mieux cerner nos besoins et découvrir les techniques utilisées dans des ser-
vices similaires au nôtre, nous allons procéder à une étude sur le service SAMMA3NI1 ,
plus connu sous l’appellation technique : PRBT (Personal Ring Back Tone).
3.1 Description du service PRBT

Le service PRBT est un service mobile à valeur ajoutée qui permet de remplacer la
traditionnelle tonalité d’attente, lors d’un établissement d’appel, par une musique ou
par n’importe quel autre e¤et sonore choisi par l’utilisateur abonné au service.
Ring Back Tone :

Musique, Son...
Réseaux Alerte
GSM/RTC
+ Solution
Tentative
Appelant Appelé
d’appel
« abonné au PRBT »
Fig. 3.1 –Principe de fonctionnement du service PRBT
Ce service, conçu dans le but de divertir les appelants, a connu un succès fulgurant
dans les pays asiatiques, où il a réussi à générer des revenus importants. Ce service est
aujourd’hui en phase de di¤usion à travers le monde.
3.2 En quoi le PRBT peut nous être utile ?

Le point commun entre le PRBT et notre service réside dans le fait que la plateforme
de service doit être avertie qu’une tentative d’appel vers un abonné au service PRBT
est en cours, pour pouvoir lancer le …chier RBT2 qui convient.
1
Lancé en Janvier 2007 par Tunisiana, SAMMA3NI permet aux abonnés au service de programmer
une tonalité personnalisée que leurs interlocuteurs entendront au lieu de la sonnerie habituelle
2
C’est un …chier musical qui remplace la tonalité d’attente pour l’appelant
15
CHAPITRE 3. ETUDE DE L’EXISTANT
Domaine de l’opérateur
G-MSC INAP SCP

SSP
HLR
ISUP
SMS HTTP CMS
Éléments dédiés au service
Fig. 3.2 –Architecture du service PRBT
Même chose pour notre service, puisque notre plateforme de service a besoin d’être
prévenue qu’un appel destiné à un client est en cours pour pouvoir juger si l’appelant
doit être "bloqué" et noti…é par MMS de l’absence de son correspondant. A défaut, le
service n’a aucun moyen de savoir si des tentatives d’appels vers des abonnés au service
sont en cours.
Il s’agit donc de déterminer la technique utilisée dans le système PRBT pour détecter
l’évènement déclencheur du service.
3.2.1 Structure de la solution PRBT

La solution PRBT telle que décrite dans [8], a été conçue de manière à ce qu’elle
puisse être entièrement intégrée aux di¤érents environnements des opérateurs de télé-
phonie mobile avec un minimum d’e¤ort.
Pour ce faire, une attention particulière a été accordée pour permettre un maximum
de ‡exibilité permettant l’adaptation du système PRBT aux infrastructures existantes.
Sur la …gure 3.2 sont représentés tous les acteurs impliqués de près ou de loin dans
l’exécution du service. Comme il est possible de le noter, la solution PRBT implique
aussi bien des éléments appartenant au domaine de l’opérateur que des éléments spé-
cialement conçus pour le service. Toutefois, l’intervention au niveau du domaine de
l’opérateur ne touche que le SCP, dans la mesure où le HLR et le SSP ne sont que des
acteurs passifs.
Ainsi, nous pouvons considérer que les principaux blocs sont :

– SCP (Service Control Point) : bloc situé chez l’opérateur de service
– SMS (Sound Management System) : bloc exclusivement dédié au service
– CMS (Content Management Server) : bloc exclusivement dédié au service
Ces trois blocs seront détaillés ci-après.
16
3.2.1.1 SCP (Service Control Point)

Dans la solution illustrée par la …gure 3.2, le SCP est utilisé dans le but de per-
mettre le contrôle et le traitement de l’appel entre Appelant/Appelé et le SMS (Sound
Management System). On dit que le SCP assure le LEG management.
C’est grâce au SSP3 , que les tentatives d’appels émis vers les abonnés au service
sont détectées. En e¤et, lorsqu’un appel vers un abonné au service est détecté, le SSP
interrompt le routage de l’appel en cours et donne la main au SCP pour que celui-ci
pilote le processus en transmettant vers les autres acteurs les instructions à exécuter.
3.2.1.2 SMS (Sound Management System)

Il s’agit d’un ensemble de serveurs connectés au MSC à travers le canal de signali-
sation SS7 et connectés au CMS via une connexion TCP/IP.
Le SMS occupe une place importante dans la solution du système PRBT, puisqu’il
a pour rôle de gérer la lecture des …chiers RBT.
Parmi les tâches assurées par le SMS :

– Le stockage des …chiers RBT sélectionnés par les abonnés.
– L’envoi de requêtes en direction du CMS pour récupérer l’information concernant
la musique à lancer (conformément au souhait de l’abonné).
– Le lancement et la lecture des …chiers RBT
– L’attente de l’ordre de libération de la connexion avec l’appelant, provenant du
SSP.
Récupération Base de
ToneQuery du EMID données
Server « abonnés »
(CallingNb,CalledNb,EMID)
CMS
XML(PRBT-Data-
XML(PRBT-Data-
Req(CallingNb,CalledNb,
Resp(CallingNb,CalledNb,transid))
transid))
SMS
Fig. 3.3 –Récupération de l’identi…ant EMID du …chier RBT à lancer
Un examen attentif de la …gure 3.3, ci-haut placée, nous éclaire sur la méthode et les
moyens permettant au SMS d’obtenir à partir du CMS, l’identi…ant EMID du …chier
RBT à exécuter, relatif au couple (CallingNb, CalledNb).
3
Service Switching Point : Le SSP, qui est en fait un commutateur, e¤ectue toutes les fonctions de
commutation nécessaires et fournit l’accès aux capacités du "Réseau Intelligent".
17
3.2.1.3 CMS (Content Management Server)

Le CMS correspond au module de la solution PRBT chargé d’assurer l’accès au
contenu (…chiers RBT personnalisés) des abonnés et la gestion de leurs pro…ls. Pour ce
faire, il est doté d’un accès WEB et IVR4 .
Parmi les tâches assurées par le CMS, on cite :

– Stockage et gestion du contenu
– Facturation
– Noti…cation de l’abonné sur l’état du service
3.2.2 Quel rôle joue le SCP dans la solution ?

D’après la con…guration de la solution, nous pouvons constater que le SCP est
le cerveau du système. Il sert à gérer le processus de lancement du service à travers
la gestion des Legs. En e¤et, comme l’indique la …gure 3.4, le SCP pilote les étapes
d’établissement de l’appel de A vers B et intègre le SMS dans la procédure pour qu’il
puisse exécuter la sonnerie qui convient.
Appelant A
LEG=1
SCP LEG=2 Appelé B
SSP
LEG=3
SMS
CMS
Fig. 3.4 –Rôle du SCP dans la gestion de l’appel
3.3 Conclusion de l’étude

Nous pouvons donc à partir du service PRBT nous inspirer de certaines de ses
techniques relatives à l’accès au "Réseau Intelligent" pour la détection des tentatives
d’appel et au schéma d’interaction entre le SMS et le CMS permettant l’accès aux
données utilisateurs en fonction du couple (CallingNb, CalledNb).
4
Interactive Voice Response : système de réponse automatique personnalisable permettant d’obtenir
des informations ou de générer des actions en pressant des touches sur le téléphone
18
A ce stade de notre étude, nous pouvons prétendre avoir les moyens d’imaginer une
solution dont l’architecture est capable d’exécuter toutes les fonctionnalités attendues
de notre service.
19
Chapitre 4
Architecture fonctionnelle du
service
Avant d’entamer la conception du service, il est primordial de ré‡échir à une archi-

tecture globale pour la solution que nous envisageons d’adopter.
La plateforme de service que nous nous proposons de construire a besoin d’être

connectée au réseau GSM par le G-MSC pour intervenir lorsqu’un appel vers un abonné
est détecté, et ouverte à Internet pour permettre la con…guration du service et la gestion
des pro…ls utilisateurs.
Pour ce faire, l’architecture correspondante devra comprendre deux blocs indépen-

dants assurant chacun une partie des opérations nécessaires à l’exécution du service.
Network Adaptation ISUP v2 SS7

INAP v3
(IN/SCP, Leg Management, Call Control)
SSP
G-MSC
Billing Content Management

HTML/XML HLR-MD
System System
HTTP
MM7
P
SM
TT
PP
H
In
WAP MMS SMS

te
r
ne
Gateway Center Center

t
Fig. 4.1 –Architecture de la solution proposée
En résumé, nous pouvons constater que le principe de fonctionnement de l’archi-

tecture, proposée dans la …gure 4.1, se base sur la communication entre deux blocs de
20
CHAPITRE 4. ARCHITECTURE FONCTIONNELLE DU SERVICE
Blocs de service Rôle

Content Management Gestion des pro…ls utilisateurs
System Gestion des MMS Post Card
Interfaçage avec le MMS Center
Interfaçage avec le Billing System
Network Adaptation Interception des appels entrants et lancement du service
Accès aux ressources du "Réseau Intelligent"
Gestion du "Leg Management"
Gestion des "Call Control"
Tab. 4.1 –Description des blocs de service
service principaux (Ces blocs de service sont détaillés dans le tableau 4.1).
4.1 Content Management System

En utilisant notre service, un abonné doit pouvoir con…gurer, gérer et personnaliser
son compte en fonction de ses besoins. Parmi les fonctionnalités qu’un abonné au service
devrait pouvoir gérer, nous pouvons citer :
– Activation et désactivation du service
– Gestion des MMS à envoyer
– Gestion des groupes de contacts
– Gestion de la liste VIP
Nous devons donc imaginer un module qui puisse gérer à la fois le contenu (pro…ls
des utilisateurs, contenu des MMS associés. . . ) et être accessible via une interface WEB
et WAP.
D’où l’intérêt de recourir au CMS, un système de gestion de contenu capable de

gérer à la fois les contenus des abonnés ainsi que le contenu du fournisseur de service.
Le CMS que nous avons imaginé pour notre service est en réalité un ensemble de
serveurs capables de supporter :
– une application serveur J2EE destinée à héberger notre application CMS.
– un serveur WEB Apache
4.2 Network Adaptation

La Network Adaptation constitue la partie la plus sensible du service puisqu’elle
assure l’intégration du service dans le réseau présent chez l’opérateur hébergeant le
service.
D’après la description du service que nous avons faite au chapitre 1, nous avons
vu que pour s’exécuter, le service avait besoin d’intercepter la tentative d’appel d’un
éventuel appelant. Le rôle essentiel du composant Network Adaptation sera donc de
récupérer les informations nécessaires au déclenchement du service et de gérer le "Call
Control" permettant de faire intervenir les acteurs impliqués dans le service dans le
processus d’exécution.
21
Pour ce faire, deux con…gurations sont possibles :

– IN Based Con…guration
– Service Node Based Con…guration
4.2.1 IN Based Con…guration

Dans notre service, nous avons besoin de détecter certains événements intervenant
dans le traitement d’un appel entre un appelant et un abonné au service. Or, selon
[9] et [10], ces événements peuvent être visibles par le "Réseau Intelligent" à l’aide des
Detection Point (DP) placés à des endroits précis dans le traitement d’appel. Et étant
donné que le "Réseau Intelligent" possède une entité intelligente capable de contrôler
et superviser les services pré-implémentés (…ltrage d’appel, numéro vert, renvoi d’ap-
pel, etc), il devient alors intéressant d’exploiter les fonctionnalités déjà o¤ertes par le
"Réseau Intelligent" pour exécuter notre service.
Pour ce faire, nous aurons seulement à établir notre propre logique de service qui
va servir à organiser et piloter les di¤érents traitements nécessaires.
Dans cette con…guration, c’est le SCP qui assure la Network Adaptation.
4.2.1.1 Détails de l’architecture IN Based
G-MSC MMS
SSP
Center
HLR Interface MM7
INAP ISUP
MMS
SCP CMS
Gateway
Fig. 4.2 –Architecture de la solution IN BASED
Rôle du SCP : L’entité fonctionnelle qui va contenir la logique de service et contrôler

son exécution n’est autre que la SCF (Service Control Function), fonction assurée par
le SCP (Service Control Point).
Dans cette con…guration, le SCP joue le rôle de "maître" alors que les SSP et CMS
sont les "esclaves" qui se contentent d’exécuter les ordres du SCP.
Le SCP nous sera donc d’une grande utilité puisqu’il sera possible conformément à
une logique globale de service (GSL) de lancer le service et d’exécuter les opérations
associées telles que le …ltrage VIP et les traitements d’appel (Call Control), et ce grâce
à sa capacité à in‡uencer le traitement d’appel en interagissant avec les autres entités
du réseau.
22
4.2.1.2 Etapes du processus : La logique globale de service GSL

Pour mieux comprendre de quelle manière est organisée la con…guration IN Based,
nous allons détailler les étapes de notre logique de service.
La logique GSL de notre service devra tenir compte de deux cas de …gure possibles :
– un premier cas où l’appelant A appartient à la liste VIP établie par l’abonné B :
le service doit permettre l’acheminement de l’appel de A vers B.
– un deuxième cas où l’appelant A n’appartient pas à la liste VIP : l’appel est
abandonné et l’appelant reçoit un MMS Post Card contenant le message enregistré
par B.
(2)
(1) (3)
G-MSC (10) HLR
Calling « A » (13)
(4) (11) (12)

(5)
SCP (8) SSP (14)
(9)
(16) V-MSC
(6) (7)
15 15
MMS
CMS
Gateway
Called « B »
Fig. 4.3 –Processus de déclenchement IN BASED (pour le premier cas)
1er cas : L’appelant A appartient à la liste VIP de l’abonné B

1. « A » émet une tentative d’appel vers un abonné au service « B » . L’appel est
routé vers le G-MSC de l’opérateur de l’abonné « B » .
2. le G-MSC interroge le HLR pour récupérer des informations sur l’appelé « B »
permettant l’établissement d’une connexion.
3. le HLR transmet vers le G-MSC les informations demandées.
4. le G-MSC (SSP), en apprenant que « B » est abonné au service grâce à la don-
née contenue dans le "Service Key", décide d’arrêter tout traitement relatif à cet
appel et demande des instructions au SCP après lui avoir transmis les informa-
tions clés : (ServiceKey, EventTypeBCSM=TermAttemptAuthorized, CalledNb,
CallingNB).
5. le SCP analyse les informations reçues et détermine grâce à la donnée "Service-
Key" la logique de service à exécuter. Conformément à la logique GSL correspon-
dant au service, le SCP donne l’ordre au SSP d’interroger la CMS sur le statut
de l’appelant « B » .
23
6. le SSP transmet vers la CMS le couple (CallingNB, CalledNB) et attend sa ré-

ponse.
7. la CMS analyse les données reçues et détermine que l’appelant « A » appartient
à une liste VIP de « B » et qu’il est donc autorisé à entrer en contact avec lui.
La CMS retourne, par la suite, vers le SSP le résultat des traitements e¤ectués.
8. le SSP transmet vers le SCP la réponse du CMS et attend les instructions.
9. le SCP analyse les données reçues et demande donc au SSP de reprendre le trai-
tement de l’appel à partir du Detection Point depuis lequel il était suspendu
(Continue With Existing Data).
De l’étape 10 à l’étape 16 : Acheminement de l’appel vers l’abonné « B »
(1)
(2)
G-MSC (3)
HLR
(11)
Calling « A »
(4)
(5)
SSP (9) SCP
(10)
(9) (9) (6) (8)
MMS (8) CMS

Gateway (7)
Fig. 4.4 –Processus de déclenchement IN BASED (pour le deuxième cas)
2ème cas : L’appelant « A » n’appartient pas à la liste VIP de l’abonné B

2. le G-MSC interroge le HLR a…n de récupérer des informations sur l’appelé «B»
4. le G-MSC (SSP), en apprenant que « B » est abonné au service grâce à la donnée
contenue dans le "Service Key", décide d’arrêter tout traitement relatif à cet appel
et demande des instructions au SCP après lui avoir transmis les informations clés :
(ServiceKey, EventTypeBCSM=TermAttemptAuthorized, CalledNb, CallingNb).
5. le SCP analyse les informations reçues et détermine la logique de service à exécu-
ter. Conformément à la logique GSL correspondant au service, le SCP demande
au G-MSC de transmettre les informations (CalledNb, CallingNb) vers le CMS à
travers la création d’une connexion (Initiate Call Attempt) en direction du CMS.
(l’adresse logique du CMS est fournie par le SCP).
6. le SSP (G-MSC) transmet vers la CMS le couple (CallingNB, CalledNB) et attend
sa réponse.
24
7. la CMS analyse les données reçues en interrogeant la base de données et détermine

que l’appelant « A » n’est pas autorisé à entrer en contact avec l’abonné « B » .
8. la CMS retourne, par la suite, vers le SSP le résultat des traitements e¤ectués et
transmet, en même temps, vers le MMS Gateway l’ordre d’envoyer vers l’utilisa-
teur « A » un MMS Post Card.
9. le SSP transmet vers le SCP la réponse du CMS et attend les instructions. Le
MMS Gateway crée le MMS et l’envoie vers « A » .
10. le SCP analyse les données reçues et demande donc au SSP de jouer un message
vocal de type « Accès non autorisé » informant que le destinataire est indispo-
nible.
11. l’appelant « A » entend un message l’informant que l’abonné « B » est indispo-
nible.
Remarque : Nous pouvons constater que dans ce cas de …gure, nous n’avons pas eu
besoin de faire intervenir l’abonné « B » dans le processus d’exécution du service.
4.2.1.3 Analyse et commentaires sur la con…guration IN Based

La solution IN Based fait en sorte que toutes les opérations relatives au déclen-
chement du service et au "Call Control" soient entièrement assurées par le "Réseau
Intelligent". Cette con…guration débarrasse le CMS de cette responsabilité, lui permet-
tant ainsi de se consacrer à la gestion de contenu.
Le seul inconvénient est que cette solution exige un accès au "Réseau Intelligent"
pour pouvoir implémenter la logique de service au niveau du SCP. Cet accès n’est pas
toujours autorisé par les opérateurs.
4.2.2 Service Node Based con…guration

La con…guration Service Node Based est similaire à la con…guration IN Based ex-
cepté le fait que le processus "Call Control" est géré par un Service Node (semblable
au Service Node utilisé dans [8]) qui est dans notre cas le CMS.
Il est à noter qu’en con…gurant le CMS comme un Service Node responsable du "Call
Control", nous aurons besoin d’une nouvelle fonctionnalité permettant la création de
"Multi-Leg" entre le CMS et d’autres entités.
Cette méthode de Network Adaptation prévoit donc d’installer au niveau du CMS

un module de "Leg Management".
4.2.2.1 Détails de l’architecture Service Node Based

Comme l’indique la …gure 4.5, la con…guration Service Node Based permet d’avoir
une plateforme unique o¤rant en même temps les fonctionnalités du Network Adap-
tation et du Content Management System (CMS). Pour ce faire, il su¢ ra d’intégrer
au CMS un module de "Leg Management" qui lui permettra d’assurer, en plus de ses
fonctionnalités de base (gestion du contenu), les mêmes tâches que pourrait faire un
SCP dans une con…guration IN Based.
25
G-MSC MMS
SSP Center
HLR Interface MM7
ISUP
Module MMS
CMS Gateway
Fig. 4.5 –Architecture de la solution "Service Node Based"
Cette méthode prévoit d’interfacer la plateforme de service (CMS) au réseau cœur

(et plus particulièrement au G-MSC) via le protocole ISUP.
4.2.2.2 Etapes du processus

Comme pour la con…guration IN Based, nous avons besoin de voir de quelle manière
sont organisées les étapes relatives à la con…guration Service Node Based. Pour ce faire,
nous allons détailler les étapes correspondantes aux deux cas de …gure que nous avons
précédemment identi…és :
(2)
(1) (3)
G-MSC (8) HLR
Calling « A » (11)
(9)(10)
SSP (12)
(14)
V-MSC
(4) (7)
13 13
(5) Module (15)
LEG 1 CMS LEG 2

(6) Called « B »
Fig. 4.6 –Processus de déclenchement Service Node BASED (pour le premier cas)
1er cas : L’appelant « A » appartient à la liste VIP de l’abonné B

26

contenue dans le "Service Key", décide d’arrêter tout traitement relatif à cet
événement et redirige l’appel vers le "Leg Management Module" situé au niveau
du CMS.
5. la liaison entre l’appelant « A » et le CMS est désormais établie (création du
LEG1).
6. le CMS reçoit l’appel ainsi que le couple (CalledNb, CallingNb) et véri…e si le
CallingNb appartient ou non à la liste de …ltrage VIP (dans ce cas-ci, « A »
appartient à la liste VIP). Le "Leg Management Module" décide d’acheminer
l’appel de « A » .
7. jusqu’à 14 : établissement de la liaison entre le CMS et l’abonné « B » (création
du LEG2).
15. l’abonné « B » décroche son téléphone et la liaison entre « B » et « A » est
établie avec un e¤et trombone (l’appel transite par le CMS durant toute la durée
de la communication).
Remarques : Dans ce cas-ci, nous pouvons très facilement remarquer l’existence d’un
"Tromboning E¤ect" lors de l’acheminement de l’appel de « A » vers « B » .
(2)
(1) G-MSC (3)
HLR
Calling « A »
SSP
(7) (7) (4)
MMS (6)
Module
Gateway CMS (5)
Fig. 4.7 –Processus de déclenchement Service Node BASED (pour le deuxième cas)
2ème cas : L’appelant « A » n’appartient pas à la liste VIP de l’abonné B

27

contenue dans le "Service Key", décide d’arrêter tout traitement relatif à cet appel
et le redirige vers le "Leg Management Module" situé au niveau du CMS.
5. le CMS reçoit l’appel ainsi que le couple (CalledNb, CallingNb) et véri…e si le
CallingNb appartient ou non à la liste de …ltrage VIP (dans ce cas-ci, « A »
n’appartient pas à la liste VIP). Le "Leg Management Module" suspend l’appel
de « A » ensuite le CMS interroge ensuite sa base de données a…n de récupérer
les informations (contenu du MMS à envoyer vers « A » ) associées au couple
(CalledNb, CallingNb).
6. le CMS transmet les informations vers le MMS Gateway qui se charge de créer le
MMS Post Card à envoyer à l’utilisateur « A » .
7. le MMS Gateway crée le MMS et l’envoie vers l’utilisateur « A » .
4.2.2.3 Analyse et commentaires sur la con…guration Service Node Based

L’avantage d’utiliser la con…guration Service Node Based se situe dans le fait que le
"Leg Management" (Call Control) est "délocalisé" vers le Service Node (ici le CMS),
ce qui nous évite d’avoir à intervenir au niveau du réseau de l’opérateur car l’implé-
mentation de cette méthode est indépendante des capacités et de la con…guration du
réseau.
On peut donc dire que cette solution est appropriée pour un déploiement rapide.
En revanche, ce que nous pourrions reprocher à cette méthode, c’est sa tendance
à générer une importante charge au niveau des ressources utilisées et ce à cause du
"Tromboning E¤ect" qui se produit lorsque l’appelant appartient à la liste VIP de
l’abonné, car le CMS est obligé à ce moment là d’acheminer l’appel vers l’abonné tout
en étant incapable de se libérer du processus.
Il est donc facile d’imaginer qu’une telle solution aura un coût très élevé si nous
visons un déploiement large.
Il existe néanmoins des solutions au "Tromboning E¤ect" mais celles-ci ne sont pas
toujours applicables à tous le réseaux d’opérateurs.
4.2.3 Choix de la solution

Pour pouvoir choisir entre les deux solutions de con…guration possibles, nous devons
tenir compte de certains facteurs stratégique et technique tels que :
– Contraintes technologiques (accès au réseau, environnement existant, outils dis-
ponibles. . . )
– Objectifs du projet
– Prévision de tra…c Data (nombre d’abonnés)
En analysant l’ensemble de ces facteurs, nous avons …ni par opter pour une architec-
ture de service basée sur la con…guration IN Based. C’est en e¤et cette con…guration qui
nous semble la plus intéressante et la plus appropriée dans la mesure où notre objectif
premier consiste à concevoir un prototype de service qui puisse donner aux opérateurs
intéressés une idée précise du fonctionnement de notre service dans un environnement
très proche de la réalité.
28
4.3 Conclusion
Au cours de ce chapitre, nous sommes parvenus à proposer deux con…gurations
possibles pour l’architecture de notre plateforme de service. Ces deux con…gurations
(IN Based et Service Node Based) sont le résultat d’une étude approfondie du service
PRBT qui partage quelques similarités avec notre service.
Ensuite, nous avons tenté de détailler pour chaque con…guration, les logiques de
service de manière à illustrer les di¤érents cas de …gure que notre plateforme pourrait
rencontrer.
Maintenant que nous avons traité le bloc responsable de l’adaptation au réseau, il

ne nous reste plus qu’à travailler sur la conception de l’application destinée à gérer le
CMS.
29
Troisième partie
Conception du service
30
Chapitre 5
Conception de l’application
Maintenant que nous avons dé…ni une architecture pour notre plateforme de service
(voir chapitre 4), nous allons au cours de ce chapitre nous intéresser à la conception de
l’application qui va assurer le rôle de CMS. Pour ce faire, nous allons réaliser une étude
complète destinée à identi…er toutes les tâches à exécuter et proposer un prototype
d’application capable de satisfaire les besoins exprimés. Nous respecterons au cours de
notre étude, la méthodologie indiquée dans [11] et [12].
5.1 Identi…cation des acteurs de l’application

Les acteurs sont les entités externes à l’application et qui interagissent avec elle.
Les acteurs vont donc nous permettre de cerner les di¤érentes interfaces que notre
application va devoir o¤rir à son environnement.
Network Adaptation Platform

(IN Based/ Service Node Based)
CMS HLR
Mediation
Application Device
Abonné
au service
MMS
Center
Fig. 5.1 –Dé…nition des acteurs
Il importe de ne pas confondre, ici, acteurs et utilisateurs de l’application. Car les

acteurs sont plus que les simples utilisateurs humains du système. D’une part parce que
les acteurs incluent les utilisateurs humains mais aussi les autres systèmes informatiques
et hardware qui interagissent avec l’application.
31
CHAPITRE 5. CONCEPTION DE L’APPLICATION
Acteurs Description
L’abonné au service - utilisateur inscrit au service
Network Adaptation - intercepter et transmettre les évènements qui
Platform concernent un abonné au service
- attendre la réponse de l’application
MMS Center - recevoir les demandes d’envoi de cartes postales.
- transmettre vers l’application un accusé de réception.
HLR Mediation Device - enregistrer un OSS Mark au niveau du HLR
pour signaler l’activation du service
- envoyer une réponse pour con…rmer que le HLR
a bien enregistré l’information
Tab. 5.1 –Identi…cation et description des acteurs
D’après la …gure 5.1, l’application que nous proposons de développer se situe au

niveau du CMS. Notre application se doit donc d’assurer la gestion du contenu fourni par
les abonnés ainsi que l’interfaçage avec les di¤érentes entités impliquées dans l’exécution
du service.
L’absence du Billing System dans le schéma de la …gure 5.1 est due au fait que
le prototype que nous allons concevoir est destiné en priorité à être utilisé pour des
démonstrations en présence de clients d’Alcatel-Lucent Tunisie.
5.2 Spéci…cation des besoins

5.2.1 Besoins fonctionnels
Il s’agit ici de recenser les besoins fonctionnels dont devraient béné…cier les di¤érents
acteurs du service. Pour ce faire, nous allons essayer d’identi…er les besoins fonctionnels
de chaque acteur séparément :
5.2.1.1 Les besoins fonctionnels de l’abonné au service

– Inscription/Désinscription : l’application doit permettre à n’importe quel utilisa-
teur abonné au réseau de s’inscrire au service et de se désinscrire.
– Con…guration du compte utilisateur : l’application doit permettre à l’abonné de
con…gurer son pro…l (enregistrement du contenu du MMS Post Card, gestion des
groupes de contacts, et ce, à travers une interface WEB ou WAP).
– Filtrage des appels entrants : l’application doit permettre à l’abonné de choisir
les numéros des utilisateurs VIP qui peuvent entrer en contact avec lui (malgré
son absence simulée).
– Activation/Désactivation : un abonné doit pouvoir à tout moment activer ou
désactiver son service par l’envoi d’un SMS contenant les mots clés (RUN NOTI-
FICATION, STOP NOTIFICATION) ou bien via une interface WEB.
– Consultation du journal des connexions : l’application doit fournir à l’abonné
l’historique de tous les appels « bloqués » par le service ou SMS manqués.
32
5.2.1.2 Les besoins fonctionnels de la Network Adaptation Platform

– Transmettre à l’application tout évènement concernant un abonné au service.
– Recevoir la réponse de l’application relative à l’événement transmis.
5.2.1.3 Les besoins fonctionnels du MMS Center

– Recevoir les demandes d’envoi de MMS Post Card.
– Transmettre vers l’application la con…rmation que les MMS ont bien été envoyés.
5.2.1.4 Les besoins fonctionnels du HLR Mediation Device

– Recevoir et exécuter les requêtes d’activation ou de désactivation du service, au
niveau du HLR
– Transmettre vers l’application une réponse de con…rmation
5.2.2 Besoins non-fonctionnels

Les besoins non fonctionnels spéci…ent les propriétés du système telles que les
contraintes d’environnement et d’implémentation, les performances requises et la qualité
exigée.
– Possibilité de récupération : Le système doit avoir la capacité de se remettre en

fonction et de rétablir son niveau de service tout en restaurant les informations
a¤ectées lors de la défaillance. L’autre facteur à considérer est l’e¤ort et le temps
nécessaires pour le faire. L’idéal serait d’avoir une copie du SGBD qui serait mise
à jour de façon quotidienne à des moments précis de la journée. Pour l’application
en tant que telle, une copie de sauvegarde sera gardée sur un support physique
tel qu’un CD-ROM, ainsi si le serveur CMS tombe en panne, l’application peut
redémarrer à partir d’un autre serveur.
– Le service doit empêcher tout accès non-autorisé (accidentel ou délibéré) au sys-
tème et aux données. Des précautions doivent été prises à cet égard telles que les
mots de passe.
– Sécurité : Un pare-feu sera utilisé permettant le passage sélectif des ‡ux d’infor-
mation entre le serveur et le réseau public, et la neutralisation des tentatives de
pénétration non autorisée en provenance du réseau public.
– Disponibilité : Le service doit être disponible en tout temps.
– Simplicité d’utilisation : Etant donné que notre application est destinée au grand
public, il est essentiel de veiller à ce que l’accès au service soit facile. L’e¤ort
nécessaire pour l’utilisation et la con…guration du service par un abonné est pro-
bablement le critère le plus important pour lui.
– Flexibilité maximale : Pour assurer la ‡exibilité de la plateforme de service, il est
important d’adopter une implémentation modulaire claire et simpli…ée permettant
l’extensibilité et la maintenabilité de l’application.
– Adaptation des MMS Post Card aux terminaux
– Déploiement rapide et simple.
– Ouverture à Internet : a…n de permettre l’inscription, l’activation et la con…gura-
tion à travers une interface WEB ou WAP.
– Accès au "réseau intelligent"
33
5.3 Organisation en paquetages

La complexité de l’application ajoutée au recensement de plusieurs niveaux séman-
tiques de besoins exprimés par les acteurs identi…és au début de ce chapitre, nous incite
à décomposer l’application du CMS en 4 paquetages principaux :
Network Adaptation
Module
Alerte
HLR MD Lance User Module Déclenche Notification

Module Module
Fig. 5.2 –Diagramme de paquetage général
– User Module : ce paquetage comprend les fonctions qui vont assurer le lien
entre l’utilisateur "abonné" et le service. C’est-à-dire que c’est à travers le "User
Module" que l’abonné va pouvoir s’inscrire et gérer son pro…l.
– Network Adaptation Module : ce module va permettre à notre application de

rester à l’écoute des évènements qui concernent les abonnés au service. Ce module
joue en quelque sorte un rôle d’interfaçage entre le CMS et la Network Adapta-
tion Platform. A travers ce module, la Network Adaptation Platform transmet les
informations relatives aux évènements détectés pour que le CMS puisse retour-
ner un résultat sur les traitements e¤ectués sur les évènements et enregistrer ces
évènements dans les journaux de connexion des abonnés impliqués.
– Noti…cation Module : ce module va assurer l’envoi des noti…cations vers les

appelants non VIP. La noti…cation est de type MMS.
– Module HLR Mediation Device : ce module va gérer l’interfaçage de l’appli-

cation avec le HLR MD qui communique avec le HLR de l’opérateur pour pouvoir
agir sur l’état du service de chaque abonné. En e¤et, si un abonné décide d’activer
le service, le module HLR-MD devra ajouter un OSS Mark parmi les données de
l’abonné dans le HLR. De cette manière, le service se met en action à chaque
tentative d’appel vers un abonné au service.
5.3.1 Description des liens entre paquetages

En accédant au "User Module", un abonné au service a la possibilité de gérer et
personnaliser son compte. Une fois le service personnalisé, l’abonné peut activer son
service. Pour ce faire, le "User Module" lance le "HLR MD Module" a…n que celui-ci
34
accède au HLR pour y inscrire un OSS Mark destiné à lancer le service à chaque fois
qu’un appel est émis vers l’abonné.
Nous avons prévu le lien entre le "User Module" et le "Network Adaptation Module"
a…n que la Network Adaptation Platform puisse avertir le système qu’une tentative
d’appel est en cours. Cette alerte permettra au "User Module" de traiter l’information
et lancer le processus qui convient.
Dans le cas où un appelant VIP est détecté, le "User Module" transmet vers le
"Noti…cation Module" l’ordre d’envoyer un MMS Post Card pour noti…er l’absence de
l’abonné.
5.4 Diagrammes des cas d’utilisation

Les diagrammes de cas d’utilisation sont un moyen d’exprimer les besoins des di¤é-
rents acteurs vis-à-vis du système. Les cas d’utilisation vont donc nous o¤rir une vision
orientée utilisateur des besoins à satisfaire au contraire d’une vision informatique.
A…n de pouvoir recenser tous les cas d’utilisation possibles, nous allons procéder à
une analyse des besoins, paquetage par paquetage.
5.4.1 Cas d’utilisation du paquetage "Network Adaptation Mo-

dule"
5.4.1.1 Recensement des cas d’utilisation
Network
Adaptation Module
attendre une transmettre

include
réponse évènement
Network
Adaptation
Platform
Fig. 5.3 –Diagramme des cas d’utilisation du paquetage "Network Adaptation Module"
Grâce à ce paquetage, l’application CMS devrait pouvoir communiquer avec la Net-

work Adaptation Platform a…n de récupérer les informations relatives aux évènements
en cours pour pouvoir procéder aux traitements adéquats. Il est donc évident que ce
paquetage fasse intervenir comme acteur la Network Adaptation Platform.
5.4.1.2 Description textuelle des cas d’utilisation
35
Nom du cas : transmettre évènement

Objectif : La Network Adaptation Platform transmet tout évènement
relatif aux abonnés au service, vers l’application.
Acteurs : Network Adaptation Platform
Pré-condition : aucune
Nom du cas : attendre une réponse

Objectif : Après avoir transmis les évènements détectés, l’application
CMS doit retourner au Network Adaptation Platform
une réponse (IsVIP=1, IsVIP=0) qui lui permettra d’e¤ectuer
les traitements adéquats
Acteurs : Network Adaptation Platform
5.4.2 Cas d’utilisation du paquetage "Noti…cation Module"

5.4.2.1 Recensement des cas d’utilisation
Notification
Module
recevoir
l’ordre d’envoi
transmettre
accusé de
MMS réception
Center
Fig. 5.4 –Diagramme des cas d’utilisation du paquetage "Noti…cation Module"
Grâce à ce paquetage, l’application CMS devrait pouvoir communiquer avec le MMS

Center de l’opérateur a…n de lui transmettre les ordres d’envoi de noti…cation MMS vers
les appelants identi…és comme étant non-VIP. Ce paquetage fera donc intervenir comme
acteur le MMS Center.
36
Nom du cas : recevoir l’ordre d’envoi

Objectif : L’application transmet vers le MMS Center les informations per-
mettant de noti…er l’appelant non-VIP
Acteurs : MMS Center
Nom du cas : transmettre un accusé de réception

Objectif : Le MMS Center doit retourner vers l’application un accusé de
réception
Acteurs : MMS Center
5.4.3 Cas d’utilisation du paquetage "User Module"

5.4.3.1 Recensement des cas d’utilisation du paquetage "User Module"
Au niveau de ce paquetage, l’abonné con…gure son pro…l en fonction de ses besoins.
Après inscription et authenti…cation, l’abonné accède à une interface qui liste tous
les paramètres de con…guration et les fonctionnalités o¤ertes par le service. Via cette
interface, l’application doit permettre à l’abonné de :
– Activer et désactiver le service
– Enregistrer et modi…er les cartes postales à envoyer
– Ajouter et supprimer des groupes de contacts
– Ajouter et supprimer des numéros des contacts
– Sélectionner et désélectionner des groupes VIP
– Associer à chaque groupe de contact le MMS Post Card approprié
User Module
gérer l'état du
service
include
consulter le
journal include
s'authentifier
include
se désinscrire
du service include gérer les post-
card
extend
Abonné gérer son
au service profil extend gérer les associer à un
extend
extend contacts groupe
s'inscrire au
service gérer les
associer
groupes de extend
Post-Card
contacts
Fig. 5.5 –Diagramme de cas d’utilisation du paquetage "User Module"
37
Nom du cas : s’inscrire au service

Objectif : Un utilisateur doit pouvoir s’inscrire pour s’abonner au service
Acteurs : Abonné
Pré-condition : Aucune
Nom du cas : se désinscrire du service

Objectif : Un utilisateur doit pouvoir se désinscrire du service à tout mo-
ment
Acteurs : Abonné
Pré-condition : L’utilisateur doit s’authenti…er d’abord
Nom du cas : S’authenti…er

Objectif : Un abonné doit s’authenti…er avant d’accéder au compte utilisa-
teur pour paramétrer son pro…l
Acteurs : Abonné
Pré-condition : L’utilisateur doit posséder un compte
38
Nom du cas : Gérer son pro…l

Objectif : L’abonné a la possibilité de gérer son pro…l et ce, en paramétrant
les di¤érentes fonctionnalités disponibles
Acteurs : Abonné
Nom du cas : Gérer l’état du service

Objectif : L’abonné doit pouvoir activer ou désactiver à tout moment le
service sans pour autant se désabonner du service
Acteurs : Abonné
Nom du cas : Gérer les Post Card

Objectif : L’abonné a la possibilité d’ajouter, de supprimer ou de modi…er
le contenu des MMS Post Card à envoyer. Les MMS Post Card
doivent pouvoir contenir du texte et une image uploadée par
l’abonné
Acteurs : Abonné
Nom du cas : Gérer les groupes de contact

Objectif : L’abonné a la possibilité de créer, supprimer ou modi…er des
groupes de contacts et de leur associer un MMS Post Card
Acteurs : Abonné
Nom du cas : Gérer les contacts

Objectif : L’abonné a la possibilité d’ajouter ou de supprimer des contacts
et de les a¤ecter à un groupe de contact
Acteurs : Abonné
Nom du cas : Consulter le journal des connexions

Objectif : L’abonné doit pouvoir consulter à tout moment le journal des
tentatives d’appel bloquées
Acteurs : Abonné
39
5.4.4 Cas d’utilisation du paquetage "HLR-MD Module"

5.4.4.1 Recensement des cas d’utilisation du paquetage "HLR-MD Mo-
dule"
Le paquetage HLR-MD Module permet à l’application CMS de communiquer avec
le HLR-MD qui est chargé d’inscrire ou d’e¤acer les OSS Mark parmi les informations
relatives aux abonnés au niveau du HLR.
Le paquetage intervient donc chaque fois que l’application a besoin d’agir sur l’état
du service d’un abonné donné.
Ce paquetage fera donc intervenir comme acteur le HLR-MD et l’abonné.
HLR-MD
Module
ajouter/
gérer état du inclure supprimer OSS
service Mark
transmettre
confirmation HLR
Abonné MD
Fig. 5.6 –Diagramme de cas d’utilisation du paquetage "HLR-MD Module"
Nom du cas : Gérer état du service

Objectif :
Acteurs : Abonné
Nom du cas : Ajouter/supprimer OSS Mark

Objectif : En fonction de l’état du service commandé, le HLR-MD doit
ajouter ou bien supprimer un OSS Mark parmi les informations
de l’abonné contenues dans le HLR.
Acteurs : HLR-MD
40
Nom du cas : Transmettre con…rmation

Objectif : L’application doit avoir la con…rmation que l’opération comman-
dée a bien été exécutée
Acteurs : HLR-MD
5.5 Diagrammes des classes

D’après [11], le diagramme de classes est le diagramme le plus important de la
modélisation orientée objet. Alors que les diagrammes de cas d’utilisation montrent le
système du point de vue des acteurs, le diagramme de classes en montre la structure
interne. Il permet ainsi de fournir une représentation abstraite des objets de l’application
qui vont interagir ensemble pour réaliser les cas d’utilisation.
Dans cette partie, nous allons établir les diagrammes de classes paquetage par pa-
quetage.
5.5.1 Diagramme des classes du paquetage "User Module"

Les diagrammes de cas d’utilisation précédemment établis ont permis l’établissement
de tous les scénarios possibles entre l’abonné et l’interface de con…guration. De cette
manière, nous avons pu identi…er et organiser les classes nécessaires à la con…guration
et à la personnalisation des pro…ls des utilisateurs.
Nom de la classe Description

Subscriber Cette classe permet l’inscription et l’authenti…cation de l’abonné
UserMMSPostCard Cette classe permet la gestion des MMS Post Card (Ajout, Mo-
di…cation, Suppression. . . )
UserGroup Cette classe permet la gestion des groupes de contacts (Ajout,
Modi…cation, Suppression. . . )
UserContact Cette classe permet de gérer les contacts de l’abonné (Ajout,
Modi…cation, Suppression. . . )
EtatService Cette classe est responsable de la gestion de l’état du service.
Elle implémente les méthodes d’initialisation, d’activation et de
désactivation du service.
Journal Cette classe enregistre les évènements (appels bloqués) qui
concernent les abonnés au service. De cette manière, un abonné
a les moyens de consulter l’historique des appels.
Tab. 5.2 –Description des classes du paquetage "User Module "
Le diagramme de classe résultant est donné par la …gure 5.7.
41
Subscriber
Journal Name : String EtatService
CalledNb MobileNumber : Long Etat : Boolean
MailAddress : String UserNb
CréerJournal() Password : String
Enregistrer() 1 1 1 1 CréerEtat()
Consulter() CréerAbonné() Activer()
EffacerJournal() VérifierForm() Desactiver()
Authentifier()
1
1 1
0..n
UserGroup 0..n
UserMMSPostCard 0..n
GroupName : String
Message : String UserContact
GroupNumber : Integer
Image : Object
StatutVIP : Boolean ContactNumber : Long
Sound : Object
Pseudo : Single
CréerGroupe()
CréerMMS() 0..1 0..n 1 0..n
ModifierGroupe() CréerContact()
ModifierMMS()
Supprimer Groupe() ModifierContact()
SupprimerMMS()
NouveauContact() SupprimerContact()
NouveauGroupe()
AssocierContact()
AssocierGroupe()
SetVIP()
Fig. 5.7 –Diagramme des classes du paquetage "User Module"
5.5.2 Diagramme des classes du paquetage "Network Adapta-

tion Module"
Comme nous le savons déjà, la Network Adaptation Platform est la partie de l’ar-
chitecture du service qui permet au système de communiquer avec le réseau de l’opé-
rateur et d’intercepter les tentatives de contact vers des abonnés au service. Sauf que
le traitement des données interceptées (CalledNb, CallingNb) s’e¤ectue au niveau de
l’application CMS qui véri…e s’il s’agit d’un contact VIP ou non, et en fonction du
résultat de ce traitement, informe la Network Adaptation Platform, pour que celle-ci
détermine la démarche à suivre (bloquer l’appel ou acheminer l’appel).
Il est donc facile d’imaginer que l’application doit être capable d’être à l’écoute de
la Network Adaptation Platform, d’extraire les données reçues, d’interroger la base de
données pour déterminer le statut du contact et retourner le résultat de la requête vers
la Network Adaptation Platform.
42

NAP La classe "NAP" reste à l’écoute de la Network Adaptation
Platform, intercepte les tentatives de contact à destination
d’abonnés au service, interroge la base de données pour iden-
ti…er le statut de l’appelant et retourner une réponse vers la
Network Adaptation Platform.
Tab. 5.3 –Description des classes du paquetage "Network Adaptation Module"
Le diagramme de classe résultant de cette analyse est donné par la …gure 5.8.
NAP
Ecouter()
ExtraireInfo()
InterrogerBase()
TraiterInfo()
Fig. 5.8 –Diagramme des classes du paquetage "Network Adaptation Module"
5.5.3 Diagramme des classes du paquetage "Noti…cation Mo-

dule"
Dans le cas où un appelant non-VIP est identi…é, l’application doit lancer la pro-
cédure de noti…cation par MMS. Pour ce faire, une seule classe "noti…cation" qui im-
plémente les méthodes Notify(), RecevoirOrdre() et ObtenirContenuMMS() su¢ t. La
classe "Noti…cation" joue, en quelque sorte, le rôle d’interface entre l’application et le
MMS Center.
Notification
Notifier()
RecevoirOrdre()
ObtenirContenuMMS()
Fig. 5.9 –Diagramme des classes du paquetage "Noti…cation Module"
43

Noti…cation La classe "Noti…cation" implémente les méthodes qui per-
mettent de générer les MMS Post Card à envoyer aux ap-
pelants identi…és comme étant non-VIP.
Tab. 5.4 –Description des classes du paquetage "Noti…cation Module"
5.5.4 Diagramme des classes du paquetage "HLR-MD Mo-

dule"
Dans le cas où un abonné au service déciderait d’agir sur l’état du service (Activa-
tion/Désactivation). Sa requête sera traitée par le paquetage "HLR-MD Module" qui
communique directement avec le HLR pour lancer l’opération adéquate. Pour se faire,
une seule classe "HLR-MD" su¢ t.
HLR-MD
InscrireMark()
EffacerMark()
Fig. 5.10 –Diagramme des classes du paquetage "HLR-MD Module"

HLR-MD La classe "HLR-MD" a pour fonction de communiquer avec
le HLR a…n d’y inscrire ou e¤acer un OSS Mark parmi les
informations d’un abonné donné.
Tab. 5.5 –Description des classes du paquetage "HLR-MD Module"
5.6 Diagrammes d’interaction

Les diagrammes d’interaction permettent d’établir un lien entre les diagrammes
de cas d’utilisation et les diagrammes de classes car ils montrent comment nos objets
communiquent pour réaliser les fonctionnalités attendues.
Comme nous avons pu le voir dans le paragraphe « Spéci…cation des besoins » , le

paquetage "User Module" est capable d’assurer de nombreuses fonctionnalités. Ainsi,
a…n d’établir les diagrammes d’interaction de manière claire, nous allons partager les
diagrammes du paquetage "User Module" en petits groupes de cas d’utilisation.
Il est à noter que les digrammes d’interactions conduisent immédiatement au code.
5.6.1 Diagramme d’interaction décrivant les étapes de créa-

tion d’un nouveau compte
44
Ali : EtatAli : JournalAli :

: Utilisateur
Subscriber EtatService Journal
CréerAbonné( ) VérifierForm( )
CréerEtat( )
CréerJournal( )
Fig. 5.11 –Diagramme d’interaction décrivant les étapes de création d’un compte
Lorsqu’un utilisateur tente de s’abonner au service, une instance de la classe "Sub-

scriber" est alors créée. La création d’une instance de la classe "Subscriber" crée et
initialise à son tour deux nouvelles instances : une instance de la classe "EtatService"
et une instance de la classe "Journal".
5.6.2 Diagramme d’interaction décrivant les étapes de person-

nalisation du pro…l utilisateur
Le pro…l d’un abonné comprend un certain nombre de paramètres. Sur le diagramme
5.12, nous pouvons remarquer que la personnalisation du pro…l respecte un ordre bien
précis. L’abonné doit d’abord commencer par ajouter les MMS Post Card. C’est seule-
ment après avoir créé les MMS Post Card qu’il sera possible d’ajouter les groupes de
contacts. Cette condition s’explique par le fait qu’un groupe de contact doit être obli-
gatoirement associé à un MMS. Une fois les groupes con…gurés, l’abonné peut alors
ajouter un liste de contacts, chaque contact étant associé à un groupe de contact.
45
Ali : MMS1 : Groupe1 : Contact1 :

: Utilisateur
Subscriber UserMMSPost... UserGroup UserContact
Authentifier(numéro, password)
CréerMMS(message,image)
NouveauGroupe(nom) CréerGroupe(nom)
AssocierGroupe( )
NouveauContact(NuméroContact) CréerContact(NuméroContact)
AssocierContact( )
SetVIP( )
Fig. 5.12 –Diagramme d’interaction décrivant les étapes de personnalisation du pro…l
5.6.3 Diagramme d’interaction décrivant la gestion du service

La gestion du service fait intervenir les paquetages "User Module" et "HLR-MD
Module".
L’activation et la désactivation du service a lieu en deux temps : Lorsqu’un abonné

au service décide de changer l’état du service ( Activer(), Desactiver() ), l’instance de la
classe "EtatService" associé sollicite la classe "HLR-MD" pour entrer en contact avec
le HLR. En fonction de la requête reçue, la classe "HLR-MD" communique au HLR les
ordres à exécuter.
46
Ali : Subscriber EtatAli : EtatService : HLR-MD
Activer( ) InscrireMark( )
Desactiver( ) EffacerMark( )
Fig. 5.13 –Diagramme d’interaction décrivant la gestion du service
5.6.4 Diagramme d’interaction décrivant le fonctionnement du

service
Pour que l’application puisse savoir quand et à qui elle doit lancer une noti…cation
MMS, elle doit en premier lieu rester à l’écoute de la Network Adaptation Platform.
Cette tâche est assurée par la classe "NAP" du paquetage "Network Adaptation Mo-
dule".
Lorsqu’une tentative de contact est détectée, "NAP" tente d’extraire les informa-
tions utiles pour qu’elle puisse interroger la base de donnée et déterminer le statut de
l’appelant. Ce n’est qu’en fonction du résultat obtenu à partir de la base de données,
qu’il sera alors possible pour le SCP d’exécuter la logique de service appropriée.
Dans le cas où une noti…cation MMS s’impose (StatutVIP=0), l’ordre d’envoi est
transmis vers la classe "Noti…cation" du paquetage "Noti…cation Module" qui, grâce
aux informations associées, interroge la base pour obtenir le contenu du MMS Post
Card à envoyer et lancer la procédure d’envoi grâce à la méthode Notify().
47
: NAP JournalAli : Journal : Notification
Ecouter( )
Ecouter les
évènements Enregistrer
en cours l'évènement
ExtraireInfo( ) pour le journal
des connexions
Enregistrer( )
Déterminer
le statut de
l'appelant
InterrogerBase( )
Retourner vers la
RetournerReponse( ) NAP la valeur
IsVIP du
traitement
RecevoirOrdre( ) ObtenirContenuMMS( )
Seulement
lorsque l'appelant Notifier( )
détecté n'est pas
VIP
Fig. 5.14 –Diagramme d’interaction décrivant le fonctionnement du service
5.6.5 Diagramme d’interaction décrivant les étapes de consul-

tation du journal de connexion par l’abonné
Un utilisateur abonné au service doit pouvoir s’il le souhaite, consulter l’historique
des appels bloqués par le service. La consultation du journal fait intervenir la classe
"Journal" qui, comme nous l’avons vu dans le paragraphe précédent, enregistre les
évènements détectés par la Network Adaptation Platform, pour les convertir en journal
consultable par l’abonné.
48
Ali : AliJournal :
: Utilisateur
Subscriber Journal
Authentifier(numéro, password)
Consulter( )
Fig. 5.15 –Diagramme d’interaction décrivant les étapes de consultation du journal de

connexion par l’abonné
5.7 Description de la base de données

La base de données que nous allons utiliser pour notre service sera conçue selon le
modèle relationnel. Ce choix se justi…e par le fait que le modèle relationnel est idéal pour
notre service puisqu’il est capable de stocker une quantité importante de données dans
des tables accessibles via une requête depuis les di¤érents paquetages de l’application
que nous avons identi…és précédemment.
L’avantage d’adopter un SGBD relationnel réside dans sa simplicité d’usage et la

possibilité de combiner facilement le contenu de plusieurs tables possédant des champs
communs. Cette dernière caractéristique sera largement exploitée lorsque nous aurons
besoin d’extraire les informations spéci…ques à un abonné.
5.7.1 Contenu des tables de la base de données

– subscriber (NumAbonne, NomAbonne, PrenomAbonne, AdrMail, Password, etat)
– usermms (mmsid, NumAbonne, titre, message, urlimage)
– usergroup (groupid, NumAbonne, nomgroup, mmsid, statut)
– usercontact (contactid, NumAbonne, NomContact, NumContact, groupid)
5.7.2 Description des tables de la base de données

subscriber : la table "subscriber" contient l’ensemble des informations relatives aux
abonnés inscrits au service. Chaque abonné est identi…é par l’attribut "NumAbonne" où
est stocké son numéro de téléphone. "NumAbonne" sera considéré comme clé primaire.
usermms : la table "usermms" enregistre les MMS Post Card créés par les abonnés.
Chaque abonné possède ses propres MMS Post Card personnalisés, c’est donc pour
cette raison que "NumAbonne" est inclus parmi les attributs de la table "usermms".
49
subscriber
(0,n) (0,n)
CIF (0,n) CIF
CIF
possède possède possède
(1,1) (1,1)
(1,1)
usercontact CIF usergroup CIF usermms
est associé à est associé à
(1,1) (0,n) (1,1) (0,n)
Fig. 5.16 –Diagramme de la base de données du service
usergroup : la table "usergroup" inscrit les groupes de contacts enregistrés par les
abonnés. Comme pour la table "usermms", "NumAbonne" …gure parmi les attributs de
la table "usergroup" car chaque groupe de contacts inscrit est la propriété d’un abonné
unique.
usercontact : la table "usercontact" contient l’ensemble des informations (numéro

de téléphone du contact, nom du contact..) relatives aux contacts enregistrés par les
abonnés au service. Un contact ne sera pas identi…é par son numéro de téléphone mais
par l’attribut "contactid" qui généré indépendamment a…n que l’abonné puisse s’il
le souhaite recti…er le numéro de téléphone d’un contact tout en gardant les autres
informations inchangées.
5.7.3 Gestionnaire de base de données

Le gestionnaire que nous avons adopté pour concevoir notre base de données rela-
tionnelle n’est autre que MySQL.
MySQL est un serveur de base de données relationnelle SQL très apprécié par les
développeurs puisqu’il répond très bien aux exigences de …abilité.
50
Chapitre 6
Conception d’une plateforme de

simulation du service
Comme nous l’avons déjà expliqué, le service que nous nous proposons de concevoir
nécessite l’accès à certains équipements dont nous ne disposons pas et qui ne sont
disponibles que chez des opérateurs de téléphonie mobile. Or, l’implémentation de la
partie Network Adaptation Platform n’est possible qu’en ayant accès au SCP et au
HLR.
De plus, nous avons besoin de tester notre service pour une éventuelle démonstration
en présence de clients intéressés par l’acquisition d’un tel service à valeur ajoutée.
Nous allons donc tenter de concevoir une plateforme de simulation spécialement

imaginée pour permettre une démonstration des fonctionnalités du service.
6.1 Rôle de la plateforme de simulation

La plateforme de simulation, dont nous avons besoin, devra simuler quelques unes
des fonctions du "Réseau Intelligent". En d’autres termes, la plateforme de simulation
devrait assurer les fonctions habituellement e¤ectuées par la NAP. La plateforme de
simulation aura donc à simuler un appel émis à destination d’un abonné au service. La
simulation de cet appel déclenchera le service conformément aux instructions contenues
dans la Logique de Service implémentée au niveau du SCP.
Les principales fonctions attendues de notre plateforme de simulation sont :
– Simuler un appel émis à destination d’un abonné au service
– Simuler les traitements réalisés au cours de l’établissement de l’appel en faisant

interagir les éléments du Réseau Intelligent, à savoir, le SCP et le SSP
– Communiquer avec la CMS Application
Néanmoins notre plateforme de simulation ne devra pas se contenter d’exécuter les

fonctions de base du NAP, elle devra aussi prendre en charge le MMS Center pour la
noti…cation par MMS Post Card, si la CMS Application en donne l’ordre.
51
CHAPITRE 6. CONCEPTION D’UNE PLATEFORME DE SIMULATION DU
SERVICE
6.2 Organisation du service intégré à la plateforme

de simulation
Initialement la CMS Application communique avec la Network Adaptation Platform,
mais cette dernière sera remplacée par la plateforme de simulation. Par conséquent, la
CMS Application sera intégrée à la plateforme de simulation comme illustré dans la
…gure 6.1.
CMS Application
Plateforme de simulation
Appelant fictif
Fig. 6.1 –Architecture du service intégré à une plateforme de simulation
6.3 Architecture de la plateforme de simulation

Concrètement, la plateforme de simulation comprend plusieurs modules, chacun
censé exécuter les fonctions de base d’un SSP (switch), d’un SCP, d’un HLR et d’un
MMS-Center.
En observant la structure décrite par la …gure 6.2, nous pouvons remarquer que
certains paquetages de la CMS Application communiquent avec quelques unes des enti-
tés du simulateur. Nous devons donc veiller à reproduire les messages qui peuvent être
échangés pendant l’exécution du service.
Une telle architecture a pour but de reproduire et décrire …dèlement les interactions
qui ont lieu entre les entités SSP, SCP et HLR de la Network Adaptation Plateform.
Nous pourrons ainsi suivre pas à pas l’exécution du service conformément à la logique
de service que nous aurons implémentée au niveau du SCP.
Mais avant d’aller plus loin, nous devons commencer par identi…er tous les événe-
ments ainsi que les messages réellement échangés au niveau de la Network Adaptation
Platform au cours de l’exécution du service, pour que notre plateforme de simulation
puisse se comporter de la même manière.
– Un appel …ctif est émis vers un abonné au service. Cet appel est déclenché à l’aide
de 2 variables d’entrée (CalledNB, CallingNB) saisies à travers une interface WEB.
– Le SSP qui est l’entité du G-MSC responsable du traitement des services, reçoit le
couple (CalledNB, CallingNB). Le G-MSC interroge le HLR a…n de récupérer les
informations nécessaires à l’acheminement de l’appel vers l’utilisateur "appelé"
(CalledNB).
52
SERVICE
Abonné
Client
CMS Application
User Module
Notification Network Adaptation HLR-MD

Module Module Module
MMS
SCP SSP
Center
Network Adaptation HLR
Appelant
fictif
Fig. 6.2 –Structure de plateforme de simulation
– Le HLR retourne vers le SSP une réponse indiquant si l’utilisateur "appelé" (Cal-
ledNB) est abonné ou non à un service. Dans le cas où "l’appelé" est abonné à un
service, le SSP interrompt instantanément l’appel, informe le SCP de la situation
et attend les instructions.
– Le SCP lance le service approprié et transmet au SCP les opérations de Call
Control à exécuter.
– Le SCP interroge la CMS Application dans le but de déterminer le statut de
l’appelant (CallinNB). Cette information est nécessaire pour que le SCP puisse
lancer les opérations appropriées.
6.4 Fonctionnement de la plateforme de simulation

Maintenant que nous avons identi…é les messages que doivent s’échanger les enti-
tés du Network Adaptation Platform, nous pouvons détailler le fonctionnement de la
plateforme de simulation.
Dans la partie qui va suivre, nous n’allons pas nous intéresser aux traitements de la
CMS Application, nous allons uniquement étudier les opérations exécutées au niveau
de la plateforme de simulation lorsque le service est sollicité.
Commençons d’abord par traiter séparément les deux cas de …gure que nous avons
53
SERVICE
identi…é lors de l’étude fonctionnelle réalisée dans le chapitre 1, à savoir, les deux cas
où l’appelant appartient ou non à la liste VIP.
CMS Application
(4) (8) (1) (12)
(5)
(6) (7) (3)
MMS
(10)
SCP (9)
SSP
Center
(11)
HLR
(2)
Appel Fictif=Input (CalledNB,CallingNB)
Fig. 6.3 –Fonctionnement de la plateforme de simulation dans le 1er cas de …gure
1er cas de …gure : l’appelant n’est pas autorisé à entrer en contact avec
l’abonné :
1. Lorsqu’un utilisateur s’abonne au service et décide, via une interface WEB, d’ac-
tiver le service, sa requête est traitée par le paquetage HLR-MD Module de la
CMS Application qui communique avec le HLR, situé au niveau de la plateforme
de simulation, a…n d’inscrire un OSS Mark parmi les données de l’utilisateur, pour
indiquer que l’utilisateur est abonné au service.
2. Pour simuler un appel émis par un utilisateur (identi…é par CallingNB) vers un uti-
lisateur abonné au service (identi…é par CalledNB), nous allons remplacer l’appel
par la saisie, via une interface WEB, d’un couple de variables d’entrée (CallingNB,
CalledNB).
3. Le SSP reçoit le couple (CalledNB, CallingNB) et démarre la procédure d’éta-
blissement de l’appel. Pour ce faire, il commence par interroger le HLR a…n de
récupérer les données de localisation de l’abonné CalledNB. Le SSP apprend que
CalledNB est abonné à un service.
4. Le SSP suspend la procédure d’établissement de l’appel.
5. Le SSP transmet vers le SCP un message détaillant la situation et attend de
recevoir les instructions.
6. Le SCP détermine en fonction des informations reçues quelle logique de service
doit être lancée. Une fois la logique de service identi…ée, le SCP peut piloter le
service et transmettre ses instructions aux entités impliquées.
7. Le SCP transmet au SSP ses premières instructions.
8. Le SSP exécute les ordres du SCP et entre en contact avec la CMS Application
a…n de connaître le statut de l’appelant CallingNB.
9. Une fois le statut de CallingNB reçu, le SSP transmet l’information au SCP qui
va pouvoir l’interpréter.
10. Le SCP interprète les informations reçues et détermine les opérations à exécuter.
54
SERVICE
11. Le SCP ordonne au SSP d’abandonner dé…nitivement l’appel. Ce dernier exécute

l’ordre de mettre …n à la tentative d’appel.
12. A cet instant, la CMS Application devrait prendre la relève en générant le MMS
Post Card à envoyer vers CallingNB.
2ème cas de …gure : l’appelant est autorisé à entrer en contact avec l’abonné :
Pour le 2ème cas de …gure, c’est-à-dire celui où l’appelant est autorisé à entrer en
contact avec l’abonné au service, nous pouvons remarquer que les 7 premières étapes
sont identiques au 1er cas de …gure. Nous allons donc décrire le fonctionnement de la
plateforme de simulation seulement à partir de l’étape 8.
CMS Application
(4) (8) (1)
(5)
(3) MMS
(6) (7)
(10)
SCP (9) SSP
(12) Center
(11) HLR
(2)
Appel Fictif=Input (CalledNB,CallingNB)
Fig. 6.4 –Fonctionnement de la plateforme de simulation dans le 2ème cas de …gure
8. Le SSP exécute les ordres du SCP et entre en contact avec la CMS Application a…n
de connaître le statut de l’appelant CallingNB (dans ce cas de …gure, l’appelant
est VIP)
9. Une fois le statut de CallingNB reçu, le SSP transmet l’information au SCP qui
va pouvoir l’interpréter.
10. Le SCP interprète les informations reçues et déduit que l’appel doit être acheminé
normalement vers l’abonné au service.
11. Le SCP ordonne au SSP de poursuivre l’appel.
12. Le SSP exécute l’ordre de poursuivre le processus d’établissement d’appel.
A partir de l’étape 12, nous pouvons considérer que l’appel est en cours d’établisse-
ment.
6.4.1 Interface du simulateur

Pour pouvoir simuler notre service, nous avons prévu une interface WEB à travers
laquelle nous pouvons saisir les paramètres d’entrée et déterminer les résultats de la
simulation.
55
SERVICE
Fig. 6.5 –Aperçu de la page de saisie des paramètres d’entrée
6.4.1.1 Saisie des paramètres de simulation

Comme il est possible de le véri…er sur le …gure 5, les paramètres dont le simulateur
a besoin pour lancer le service ne sont autres que :
– Numéro de l’appelant : il s’agit ici de saisir le numéro CallingNB de l’utilisateur
désirant émettre un appel
– Numéro de l’appelé : il s’agit ici de saisir le numéro CalledNB d’un utilisateur
inscrit au service "Gestionnaire d’absence".
En cliquant sur le bouton "Lancer", le simulateur se met en route pour exécuter

les opérations de traitement du service et a¢ cher par la suite un rapport détaillant les
événements enregistrés au cours de l’exécution du service.
6.4.1.2 A¢ chage du rapport de simulation

La simulation s’achève par la génération d’un rapport de simulation détaillant les
résultats des di¤érentes étapes.
En fonction du numéro de l’appelant saisi, nous pouvons obtenir di¤érentes réponses

du simulateur. Ci-dessous, sont exposés deux rapports de simulation détaillant deux cas
de …gure classiques : (un appelant VIP et un appelant non-VIP).
Le rapport de la …gure 6.6 montre les premiers traitements e¤ectués au niveau de

la Network Adaptation Platform, suivis du traitement …nal ordonné par le SCP. Dans
ce cas-ci, le SCP ordonne la poursuite de l’acheminement de l’appel et ce, après avoir
56
SERVICE
Fig. 6.6 –Aperçu de la page d’a¢ chage du rapport de simulation (1er cas)
identi…é l’appelant comme étant autorisé à entrer en contact avec le correspondant

abonné au service.
Dans le rapport de la …gure 6.7, nous pouvons constater que le SCP donne l’ordre
d’abandonner l’appel et ce, après avoir identi…é l’appelant comme étant non autorisé à
entrer en contact avec le correspondant abonné au service.
La dernière étape décrit le processus d’envoi du MMS Post Card. Cette étape est
assurée par la CMS Application.
57
SERVICE
Fig. 6.7 –Aperçu de la page d’a¢ chage du rapport de simulation (2ème cas)
58
Chapitre 7
Réalisation
Dans ce chapitre, nous nous proposons de présenter les outils logiciels employés
au cours des di¤érentes phases de conception et d’implémentation du service. Et pour
mieux comprendre le mode de fonctionnement du service du point de vue de l’abonné,
des captures d’écran seront présentées. Ces captures d’écran sont l’illustration des fonc-
tionnalités du service que nous avons imaginées lors du 1er chapitre.
7.1 Environnement logiciel

Le choix de l’environnement logiciel est capital si nous voulons garantir le bon
fonctionnement du service.
Dans cette partie, nous présentons les logiciels utilisés pour la réalisation de ce
service. Les di¤érents logiciels sont regroupés par catégories :
7.1.1 Outils de conception

Conception UML
– Rational Rose Enterprise Edition Release Version 2001
– Microsoft O¢ ce Visio 2003
Conception de la base de données

– Microsoft O¢ ce Visio 2003
7.1.2 Environnement d’implémentation

Environnement de développement JAVA
– Version de la JVM : 1.5.0_07
– IDE : Borland JBuilder 2006 Enterprise
Environnement de développement WEB

– Version du serveur : Apache Tomcat/5.0.28
– Langage de développement WEB : JSP (Java Server Page)
– Base de données : MySQL 4.1.9
59
CHAPITRE 7. RÉALISATION
Système d’exploitation
– Windows XP SP2
7.2 Aperçu du travail accompli

Dans cette partie, nous exposons quelques captures d’écran censées permettre une
bonne compréhension du travail réalisé.
7.2.1 Page d’inscription
Fig. 7.1 –Aperçu de la page d’inscription au service
La page d’inscription contient un formulaire d’inscription comprenant des champs

de saisie destinés à permettre au système de récupérer des informations sur l’abonné
telles que : le nom, le numéro de téléphone, l’adresse mail et le mot de passe.
7.2.2 Page de connexion

Cette page, illustrée par la …gure 7.2, va permettre au système d’identi…er et authen-
ti…er un utilisateur abonné avant de lui ouvrir l’accès au compte de con…guration. Cette
restriction est primordiale si nous voulons garantir la sécurité des données utilisateur.
7.2.3 Panneau de con…guration

Une fois authenti…é, l’abonné accède à un menu listant les di¤érents paramètres de
service qu’il est possible de personnaliser. Cette page permet donc de guider l’abonné
pendant la procédure de con…guration.
60
Fig. 7.2 –Aperçu de la page de connexion au compte de con…guration
Fig. 7.3 –Aperçu du panneau de con…guration
61
7.2.4 Page « Mes MMS Post Card »
Fig. 7.4 –Aperçu du panneau de con…guration des MMS Post Card
Au niveau de cette page (…gure 7.4), l’abonné a la possibilité de consulter la liste

des MMS Post Card déjà enregistrés. De cette manière, l’abonné a la possibilité de
sélectionner les MMS qu’il désire supprimer ou modi…er, ou tout simplement d’ajouter
un nouveau MMS Post Card.
7.2.5 Page « Ajouter un MMS Post Card »

Au niveau de cette page (…gure 7.5), l’abonné doit remplir les champs « Titre » ,
« Message » et « image » . En cliquant sur « Insérer l’enregistrement » , le nouveau
MMS est enregistré au niveau de la base de données et l’abonné retourne à la page «
Mes MMS Post Card » .
7.2.6 Page « Mes groupes de contacts »

Comme pour la page « Mes MMS Post Card » , l’abonné a la possibilité de consulter,
sur cette page, l’ensemble des groupes de contacts qu’il a créé et de sélectionner les
groupes à modi…er ou supprimer.
62
Fig. 7.5 –Aperçu de la page d’ajout d’un nouvel MMS Post Card
Fig. 7.6 –Aperçu du panneau de con…guration des groupes de contacts
63
7.2.7 Page « Ajouter un groupe de contact »
Fig. 7.7 –Aperçu de la page d’ajout d’un nouveau groupe de contact
Sur cette page, l’abonné doit remplir le champ « Nom du groupe » , sélectionner
parmi la liste des MMS disponibles le MMS associé au groupe et dé…nir le statut VIP
du groupe.
7.2.8 Page « Mes contacts »

Sur cette page, est a¢ chée la liste des contacts de l’abonné et des groupes de contacts
auxquels ils sont a¤ectés. L’abonné a ainsi la possibilité de modi…er ou supprimer ses
contacts enregistrés et éventuellement en ajouter de nouveaux.
7.2.9 Page « Ajouter un contact »

Sur cette page, l’abonné doit remplir les champs « Nom du contact » et « Numéro
de téléphone » et ensuite sélectionner parmi la liste des groupes de contacts enregistrés
le groupe auquel il doit être a¤ecté.
64
Fig. 7.8 –Aperçu du panneau de con…guration des contacts
Fig. 7.9 –Aperçu de la page d’ajout d’un nouveau contact
65
Conclusion
Ce mémoire rapporte le travail que j’ai réalisé au cours de mon stage de …n d’études
au sein de l’espace partenariat de la société Alcatel-Lucent Tunisie et portant sur le dé-
veloppement d’un prototype de service mobile assurant la gestion de l’absence prolongée
d’abonnés localisés à l’étranger.
Ce projet s’inscrit dans le cadre du programme "Value Added Reality Center" d’Al-
catel, visant à lui permettre d’élargir son o¤re de services à valeur ajoutée. L’enjeu était
donc de proposer un service encore inédit capable de répondre à un besoin exprimé par
une ou plusieurs catégories d’abonnés et susceptible d’intéresser les opérateurs de télé-
phonie mobile à la recherche de services innovants.
J’ai ainsi pu grâce à ce projet m’impliquer dans les di¤érentes phases de création
d’un service mobile à valeur ajoutée, à savoir, l’exploration et l’identi…cation d’une op-
portunité de service, l’étude du potentiel de rentabilité, la détermination de la faisabilité
technique et en…n le développement d’un prototype destiné à être utilisé lors de démons-
trations en présence de représentants d’opérateurs de téléphonie mobile intéressés par
l’acquisition d’un service à fort potentiel commercial.
Tout au long de ce projet, j’ai eu l’occasion de mettre en pratique mes connaissances

acquises au sein de Sup’Com et j’ai également eu l’opportunité de travailler avec de
nouveaux outils et méthodologies.
Il reste qu’il serait intéressant, au cours de travaux d’amélioration et de développe-

ment futurs, de ré‡échir à de nouvelles con…gurations au niveau de la "Network Adap-
tation" dont l’implémentation et l’intégration seraient indépendantes de l’infrastructure
existante mais surtout moins coûteuse. De plus, il serait judicieux d’essayer d’imaginer
pour notre service de nouvelles fonctionnalités utiles et auxquelles nous n’avons pas
pensé. De cette manière, nous pouvons mieux garantir le succès commercial immédiat
et futur de notre service.
Pour conclure, ce stage a été pour moi l’occasion de travailler dans une entreprise
mondialement réputée pour son savoir faire et a donc été pour moi d’un grand béné…ce
en matière d’acquis techniques.
66
Bibliographie
[1] Elizabeth Vinay, Réaliser votre étude de marché, Chapitre 2, Editions APCE, 2005
[2] Centre local de développement de Québec, Guide : Etude de marché, CLD de

Québec, Août 2005
[3] Carole Manero, Le marché mondial des services mobiles, IDATE NEWS N 292; 8
Décembre 2003
[4] Philippe Bautier, Télécommunications dans l’UE, Communiqués de presse d’Eu-

rostat sur Internet, 7 Février 2005
[5] Union internationale des télécommunications, Rapport sur le développement des

télécommunications dans le monde, Indicateurs d’accès à la société de l’informa-
tion, Récapitulatif, Décembre 2003
[6] Orascom Telecom, Investor presentation, Mars 2007
[7] François-Carlos Bovagnet, Les vacances des Européens, Eurostat, 2006
[8] ALCATEL, 8693 Personalised Ring Back Tone (Release 2.1), Product Description,
Janvier 2006.
[9] Simon Znaty, Le Réseau Intelligent : Principes, Services et Architecture, Editions

EFORT, 2006
[10] Claude Rigault, L’intelligence dans les réseaux …xes et mobiles, Notes de cours,
2005
[11] Pierre Gérard, UML 2, Modélisation Orientée Objet de Systèmes Logiciels, Support
de cours, IUT Villetaneuse, Université de Paris 13, 2007
[12] Laurent Audibert, UML 2.0, Notes de cours, IUT Villetaneuse, Université de Paris
13, 2006
[13] Olivier Capuozzo, Cas d’utilisation, une introduction, Notes de cours, Avril 2004
[14] Serge Tahé, Introduction à la programmation WEB en JAVA, Servlets et pages

JSP, Support de cours, Septembre 2002
67
BIBLIOGRAPHIE
[15] Mickaël Baron, Java pour le développement d’applications WEB : J2EE, JSP 2.0,
Tutorial, 2006
[16] Don Doherty, Michelle M.Manning, Teach yourself Borland JBuilder 2 in 21 days,
Sams Publishing, 1998
68

LABBASSI Mustapha

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

LABBASSI Mustapha

Transféré par

Droits d'auteur :

Formats disponibles

Cycle de formation des ingénieurs en Télécommunications

Rapport de Projet de …n d’études

M. Mourad LAHMADI Alcatel-Lucent Tunisie

Travail proposé et réalisé en collaboration avec :

Année universitaire : 2006/2007

Le présent travail constitue un projet de …n d’études pour l’obtention du diplôme

Réalisé au de sein de l’espace partenariat d’Alcatel-Lucent Tunisie, ce projet s’inscrit

Table des matières iii

Table des …gures iv

Liste des tableaux v

Liste des abréviations vi

II Etude d’une architecture pour le service 14

3.2 En quoi le PRBT peut nous être utile ? . . . . . . . . . . . . . . . . . . 15

4 Architecture fonctionnelle du service 20

III Conception du service 30

6 Conception d’une plateforme de simulation du service 51

1.1 Schéma descriptif de l’option "Filtrage des appels entrants" . . . . . . . 4

2.1 Evolution annuelle du nombre des abonnés de la téléphonie mobile en

3.1 Principe de fonctionnement du service PRBT . . . . . . . . . . . . . . 15

4.1 Architecture de la solution proposée . . . . . . . . . . . . . . . . . . . . 20

5.1 Dé…nition des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.16 Diagramme de la base de données du service . . . . . . . . . . . . . . . 50

6.1 Architecture du service intégré à une plateforme de simulation . . . . . 52

7.1 Aperçu de la page d’inscription au service . . . . . . . . . . . . . . . . 60

2.1 Principaux indicateurs de Tunisiana (source : Orascom Télécom) . . . . 9

4.1 Description des blocs de service . . . . . . . . . . . . . . . . . . . . . . 21

5.1 Identi…cation et description des acteurs . . . . . . . . . . . . . . . . . . 32

ARPU : Average Revenue Per User

Le pragmatisme de l’abonné à la téléphonie mobile vis-à-vis des nouvelles technolo-

En tenant compte de ce comportement qui tend à se généraliser, il est facile d’imagi-

Il serait alors utile de trouver un moyen qui permettrait à l’abonné "Roamer" de

En outre, la solution devra fournir au client "Roamer" le moyen d’informer les

1.2 Description des di¤érentes fonctionnalités du

1.2.1 Filtrage des appels entrants

Fig. 1.1 –Schéma descriptif de l’option "Filtrage des appels entrants"

1.2.2 Noti…cation d’absence prolongée

Fig. 1.2 –Schéma descriptif de l’option "noti…cation d’absence"

La noti…cation d’absence prolongée est une fonctionnalité utile puisque l’abonné

1.2.3 Journal des connexions

Fig. 1.3 –Schéma descriptif de l’option "Journal des connexions"

Cette fonctionnalité sert à permettre à l’abonné au service de consulter le journal

Abonné Carte postale

Consultation Appelant VIP

Fig. 1.4 –Schéma descriptif du service global

1.3 Intérêt du service

– Les abonnés équipés de terminaux compatibles GPRS

1.5 Possibilités d’extension

2.1 Intérêt des opérateurs téléphoniques pour les

Nombre d’abonnés 3 100 000

Tab. 2.1 –Principaux indicateurs de Tunisiana (source : Orascom Télécom)

Segment de marché Volume (estimé)

Tab. 2.2 –Volume global du marché cible

2.2 Volume et taille du marché

En identi…ant de cette manière les consommateurs potentiels, nous pouvons procéder

Des informations collectées auprès d’organismes compétents (O¢ ce National du

Ce tableau estime le volume du marché global à 1713000 consommateurs. Or le

2.3 Estimation de la part de marché à atteindre

2.3.1 Données du marché européen

2.3.2 Analyse et extrapolation

2.4 Etat du marché

Dans la mesure où les consommateurs ciblés voyagent régulièrement, nous pouvons

2.5 Analyse de la demande

Il existe deux types de comportements propres à ce segment d’abonnés :