N° d’ordre : 01 / STI / TCO Année Universitaire : 2022/2023

UNIVERSITE D’ANTANANARIVO
----------------------
ECOLE SUPERIEURE POLYTECHNIQUE
-----------------------
MENTION TELECOMMUNICATION

MEMOIRE

En vue de l’obtention

DU DIPLOME de Master
Titre : Ingénieur
Domaine : Sciences de l’Ingénieur
Mention : Télécommunication
Parcours : Système de Traitement d’Information

par : ANDRIAMBOLOLONA Holinirina Hionontsoa

PRINCIPE DU SYSTEME DE FACTURATION

ROAMING EN TELECOMMUNICATION

Soutenue le Lundi 16 Octobre 2023 à 14h30 devant la Commission d’Examen composée de :

Président :

M. RAJAONARISON Roméo

Examinateurs :

M. ANDRIAMANALINA Ando Nirina

M. RAKOTONDRAMANANA Sitraka
M. RANDRIANA Erica
Directeur de mémoire :
Mme. RAMAFIARISONA Hajasoa Malalatiana
ii
 REMERCIEMENTS
Tout d’abord, Je remercie Dieu de m’avoir donné la santé, la force et le courage afin de mener
à bien mes études, ainsi que l’élaboration de ce mémoire.

Je tiens à remercier Monsieur RAVELOMANANA Mamy Raoul, Professeur, Directeur de

l’Université d’Antananarivo, de m’avoir accueilli au sein de son établissement.

Je remercie aussi Monsieur RAKOTOSAONA Rijalalaina, Professeur, Directeur de l’Ecole

Supérieur Polytechnique d’Antananarivo.

Je tiens également à adresser mes vifs remerciements à Monsieur RAJAONARISON Roméo,

Maître de conférences, Chef de Département Télécommunication, qui nous a fait l’honneur de
présider les membres du Jury de ce mémoire.

Je tiens à exprimer ma profonde et très sincère reconnaissance à Madame RAMAFIARISONA

Hajasoa Malalatiana, Professeur, Enseignant au sein du Département Télécommunication, Di-
recteur de ce mémoire, pour m’avoir consacré beaucoup de son temps et de m’avoir dirigé par
ses remarques constructives et ses précieux conseils durant ce travail de mémoire.

Je témoigne toute ma reconnaissance aux autres membres du jury qui ont voulu examiner ce
travail, à savoir :

• M. ANDRIAMANALINA Ando Nirina « Maitre de conférences »

• M. RAKOTONDRAMANANA Sitraka « Docteur en Télécommunication »
• M. RANDRIANA Erica « Maitre de conférences »
J’adresse aussi mes remerciements à tous les Enseignants du Département Télécommunication,
qui m’ont formé pendant mes années d’étude au sein de l’Ecole Supérieure Polytechnique
d’Antananarivo, et également les membres du corps Administratif de notre Ecole.

Je tiens à exprimer ma profonde gratitude envers le Groupe Telma Madagascar pour m'avoir
offert l'opportunité enrichissante de réaliser un stage de trois mois au sein de leur prestigieuse
entreprise. Mes remerciements les plus sincères vont à M. RAFIDISON Maminiaina Alphonse
chef du Département de Système d’Information où j'ai eu le privilège de travailler, pour sa
bienveillance, ses conseils avisés et son encadrement exceptionnel. Ce fut une expérience ex-
ceptionnelle, au cours de laquelle j'ai pu acquérir des compétences précieuses, élargir mes con-
naissances professionnelles et découvrir le fonctionnement dynamique de l'industrie des télé-

iii
communications. Mes remerciements s'adressent également à l'ensemble de l'équipe du Dépar-
tement de Système d’Information, qui m'a chaleureusement accueilli et a partagé avec moi son
expertise. La générosité et le professionnalisme de chacun m'ont grandement inspiré et contri-
bué de manière significative à l'enrichissement de mon parcours académique. Je suis reconnais-
sant envers le Groupe Telma Madagascar pour cette expérience formatrice qui restera gravée
dans ma mémoire tout au long de ma carrière future.

J’exprime ma gratitude à toute ma famille pour leur soutien tout au long de mes études. Je les
remercie pour leurs encouragements, leur confiance et leurs soutiens moraux.

J’adresse mes remerciements à mes amis de m’avoir soutenu et encouragé, ainsi que tous ce qui
ont contribué de près et de loin à la réalisation de ce mémoire.

iv
 TABLE DES MATIERES
TABLE DES MATIERES........................................................................................................................v
ABREVIATION ..................................................................................................................................... vii
INTRODUCTION GENERALE ............................................................................................................. 1
CHAPITRE I : ROAMING, CDR, FICHIER TAP EN TÉLÉCOMMUNICATIONS ........................... 2
1.1.2 Le fonctionnement du roaming. .................................................................................................. 2
1.1.3Types de roaming : ...................................................................................................................... 4
[Link] Le Roaming National .......................................................................................................... 4
[Link] Le Roaming International .................................................................................................... 4
[Link] Interstandard roaming .......................................................................................................... 5
1.1.4 Privilèges du roaming ................................................................................................................ 5
1.1.5 Déroulement des services en roaming ........................................................................................ 6
1.1.6 Mise à jour de localisation d’un Roamer ............................................................................. 10
1.1.7 Implémentation de données .................................................................................................. 11
1.2 Le CDR.................................................................................................................................... 14
1.3 Le fichier TAP ......................................................................................................................... 16
1.4 Les processus de facturations ...................................................................................................... 24
1.4.1 Le MSC dans la facturation.................................................................................................. 24
1.4.2 Le Data Clearing House ou DCH dans le système de facturation. ...................................... 26
1.4.4 Near Real Time Roaming Data Exchange ou NRTRDE....................................................... 28
CONCLUSION ................................................................................................................................. 29
CHAPITRE II : ARCHITECTURE DU SYSTEME DE FACTURATION EN ROAMING ............... 30
2.1 Architecture du roaming 2G, 3G et 4G ....................................................................................... 30
2.1.1 Structure pour le roaming 2G/3G ........................................................................................ 31
2.1.2 Connectivité entre réseaux mobiles 4G (LTE/ePC) [2] ........................................................ 34
2.2 Infrastructures techniques............................................................................................................ 38
2.2.1 Présentation des éléments clés ............................................................................................. 38
[Link] Le serveur .......................................................................................................................... 39
a) Définition .................................................................................................................................. 39
[Link] La base de données ............................................................................................................ 40
[Link] Le système de médiation ................................................................................................... 40
[Link] Les passerelles ................................................................................................................... 42
2.2.2 Interactions entre les différents composants du système ...................................................... 43
2.3 Les systèmes de facturation ......................................................................................................... 46
2.3.1 La faturation en ligne ou Online Charging Système ou OCS ............................................... 46
v
 2.3.2 La facturation hors ligne ou Offline Charging System ou OFCS......................................... 48
2.3.3 Le système de facturation utilisé en roaming ....................................................................... 50
CONCLUSION ................................................................................................................................. 51
CHAPITRE III : ANALYSE, CONCEPTION ................................................................................. 52
3.1 Analyse ........................................................................................................................................ 52
3.1.1 Méthode et outils pour l’application : .................................................................................. 52
b) Diagramme de classe................................................................................................................. 53
c) Diagramme d’objets .................................................................................................................. 54
3.1.2 Présentation d’un modèle UML ........................................................................................... 54
3.2 L'algorithme de ASN.1 (Abstract Syntax Notation One) ............................................................ 58
3.2.1 Système d’encodage ................................................................................................................. 58
3.2.2 Basic Encoding Rules ou BER.................................................................................................. 58
[Link] Description ........................................................................................................................ 58
3.2.3 Relation entre BER et python ............................................................................................... 59
3.3 Les outils de développement utilisé ............................................................................................ 60
3.3.1 WINDOWS................................................................................................................................ 60
3.3.2 Python....................................................................................................................................... 61
3.3.3 Mysql / workbench.................................................................................................................... 63
3.3.4 L'environnement de développement intégré VSCode ............................................................... 64
CONCLUSION ................................................................................................................................. 64
CHAPITRE IV : REALISATION ......................................................................................................... 65
4.1 L’objectif du projet .................................................................................................................. 65
4.1.1 Les éléments clés du CDR utiliser dans la réalisation du projet. .................................. 65
4.2 Le système existant ................................................................................................................. 66
4.2.1 Le point fort de l’application ................................................................................................ 66
4.2.2 Spécifications des acteurs..................................................................................................... 67
4.3 Description du logiciel ............................................................................................................ 67
4.3.1 L’interface graphique ........................................................................................................... 67
4.3.2 Description des fonctionnalités ............................................................................................ 68
4.3.3 Les éléments visible dans le logiciel ..................................................................................... 70
CONCLUSION ................................................................................................................................. 72
CONCLUSION GENERALE ............................................................................................................... 73

vi
 ABREVIATION
3GPP Third Generation Partnership Project

APN Access Point Name

AS2 Applicability Statement

ASN1 Abstract Syntaxe Notation One

BGs Border Gateways

BSC Base Station Controller

BTS Base Transceiver Station

CDMA Code Division Multiple Access

CDR Call Details Record

CS Circuit Switched

CSCF Call Session Control Function

CSFB Circuit Switched Fall Back

DCH Data Clearing House

DNS Domaine Name System

EPC Evolved Packet Core

FTP File Transfer Protocol

GGSN Gateway GPRS Support Node

GMSC Gateway Mobile Switched Center

GSM Global System for Mobile Communication

GPRS General Packet Radio Service

GRx GPRS Roaming eXchange

GTP GPRS Tunneling Protocol

HPLMN Home Public Land Mobile Network

vii
HLR Home Location Register

HTTPS Hyper Text Transfer Protocol Service

HTTP Hyper Text Transfer Protocol

HSS Home Subscriber Server

IDE Integrated Development Environment

IMEI International Mobile station Equipment Identity

IMS IP Multimedia Subsystem

IMSI International Mobile Subscriber Identity

ITU International Telecommunication Union

IP Internet Protocol

IPx IP eXchange network

LAI Location Area Identifer

LTE Long Term Evolution

MSC Mobile Switching Center

MNC Mobile Network Code

MS Mobile Station

MSRN Mobile Station Roaming Number

MGT Mobile Global Title

MME Mobility Management Entity

NRTRDE Near Real Time Roaming Data Exchange

PCC Policy and Charging Control

PCEF Policy and Charging Enforcement Function

PCRF Policy and Charging Rules Function

P-CSCF Proxy-Call Session Control Function

viii
PDP Packet Data Protocol

PGW Packet Gateway

PLMN Public Land Mobile Network

RAB Radio Access Barrer

RAP Returned Account Procedure

RNC Radio Network Controller

RTCP Réseau Téléphonique Commuté Public

RTP Real Transport Protocol

SIM Subscriber Identity Module

SMS Short Message Service

SCCP Signaling Connection and Control Part

SIP Session Initiation Protocol

SFTP Secure File Transfer Protocol

SSH Secure SHell

SCP Secure Copy Protocol

SS7 Signaling System 7

SGSN Serving GPRS Support Node

SCTP/IP Stream Control Transmission Protocol/Internet Protocol

SGsAP SGs Application Protocol

SGW Serving Gateway

SGBDR Système de Gestion de Base de Données Relationnel

SQL Structure Query Language

TAP Transfer Account Procedure

TMSI Temporary Mobile Subscriber Identity

ix
TA Timing Advance

UE User Equipment

USSD Unstructured Supplementary Service Data

UDP User Datagram Protocol

UML Unified Modeling Language

VPLMN Visited Public Land Mobile Network

VLR Visitor Location Register

VMSC Visited Mobile Switching Center

VoIP Voice over Internet Protocol

VoLTE Voice over Long-Term Evolution

x
 INTRODUCTION GENERALE

Le système de facturation en roaming joue un rôle essentiel dans l’industrie des télé-
communications. Avec l’essor des communications mobiles et l’augmentation des voyages
internationaux, les opérateurs de télécommunications doivent être en mesure de facturer les
services utilisés par leurs abonnés lorsqu’ils se trouvent hors de leur réseau domestique. Le
principe de système de facturation en roaming consiste à permettre aux utilisateurs de services
mobiles de rester connectés et de bénéficier de services de communication lorsqu’ils voyagent
à l’étranger, tout en assurant une tarification transparente et précise.

Ce sujet de mémoire se concentre sur l’étude et l’analyse des principes du système de

facturation en roaming dans le domaine des télécommunications. Il examine les processus, les
protocoles et les mécanismes mis en place pour permettre une facturation équitable des services
utilisés par les abonnés lorsqu’ils se déplacent d’un réseau à un autre.

Le système de facturation en roaming comprend plusieurs éléments clés, tels que l’in-
terconnexion entre les opérateurs, l’échange d’informations sur les services utilisés, la tarifica-
tion des services utilisés et la gestion des règlements financiers entre les opérateurs. Il implique
également des accords et des partenaires entre les opérateurs de télécommunications afin de
permettre l’accès aux réseaux étrangers pour leurs abonnés.

L’objectif principal de ce mémoire est d’explorer les défis et les enjeux liés à la mise en
œuvre d’un système de facturation en roaming efficace. Il examinera les normes et les régle-
mentations en vigueur dans l’industrie des télécommunications, ainsi que les meilleures pra-
tiques et les technologies utilisées pour garantir une facturation transparente.

Tout au long de cet ouvrage nous essayerons d’éclaircir tout ce qui concerne la factura-
tion roaming en télécommunication. Dans le premier chapitre, nous allons passer en revue le
concept général du roaming, ce qu’on entend par CDR et fichier TAP. Nous introduisant ensuite
dans le deuxième chapitre, pour voir l’architectures d’un système de facturation en roaming.
Dans le troisième chapitre, nous allons développer les différentes étapes de la réalisation de ce
mémoire ainsi que la présentation des interfaces lier à ce projet.

1
 CHAPITRE I : ROAMING, CDR, FICHIER TAP EN TÉLÉCOMMUNICATIONS

Le monde est devenu de plus en plus connecté grâce aux avancées des technologies de commu-
nication mobile. Lorsque nous voyageons à l'étranger, nous nous attendons à pouvoir utiliser
nos téléphones portables pour rester connectés avec nos proches, accéder à Internet et utiliser
nos services de communication habituels. C'est là que le concept de roaming entre en jeu. Grâce
au roaming, nous pouvons continuer à utiliser nos téléphones et à bénéficier des services de
communication, même lorsque nous sommes à des milliers de kilomètres de chez nous. Pour
mieux comprendre ce concept, nous devons comprendre deux éléments clés du roaming : les
CDR (Call Detail Records) et les fichiers TAP (Transferred Account Procedure).

Dans cette étude, nous explorerons plus en détail le fonctionnement du roaming, des CDR et
des fichiers TAP. Nous examinerons les défis techniques et opérationnels auxquels sont con-
frontés les opérateurs de télécommunications, les avantages pour les utilisateurs en roaming et
les technologies émergentes qui pourraient transformer l'expérience du roaming à l'avenir. En
comprenant ces concepts fondamentaux, nous pourrons apprécier l'importance du roaming, des
CDRs et des fichiers TAP dans l'écosystème mondial des télécommunications mobiles.

I.1 Concept du roaming

1.1.1 Définition

Le roaming est l’une des possibilités les plus fascinantes de la téléphonie mobile. Permettant à
l’abonné d’utiliser son portable un peu partout dans le monde sans même changer de numéro
d’appel.

L’abonné pourra ainsi émettre et recevoir automatiquement des appels, envoyer et recevoir des
données (sms) ou d’accéder à d’autres services en dehors de la couverture géographique de son
réseau de télécommunication au moyen de l’un des réseaux de la région visitée.

Le service roaming est automatiquement activé via la carte Sim, ce qui procure une utilisation
libre du téléphone. [1]

1.1.2 Le fonctionnement du roaming.

Lorsqu'un utilisateur se déplace à l'étranger et allume son téléphone mobile, celui-ci recherche
pour sélectionner les réseaux disponibles ou l’avoir automatiquement. Une fois qu'il détecte un
2
réseau étranger compatible, il se connecte à ce réseau et l'utilisateur peut alors utiliser les ser-
vices de communication. Cette connexion au réseau étranger se fait grâce à des accords roaming
conclus entre les opérateurs de télécommunications, qui permettent l'utilisation mutuelle de
leurs réseaux par les abonnés en roaming. [1]

Le fonctionnement du roaming repose sur la coopération entre les opérateurs de télécommuni-

cations. Voici les principes clés qui régissent le fonctionnement du roaming :

• Accords d'itinérance :

Les opérateurs de télécommunications établissent des accords de roaming entre eux pour per-
mettre l'utilisation mutuelle de leurs réseaux par les abonnés. Ces accords spécifient les condi-
tions, les tarifs et les services disponibles lors du roaming. Ils peuvent être conclus bilatérale-
ment entre deux opérateurs de télécommunications pour permettre aux utilisateurs de télé-
phones mobiles de ce pays ou de cet opérateur de bénéficier des services de roaming lorsqu'ils
se trouvent à l'étranger.

• Enregistrement sur le réseau étranger :

Lorsqu'un utilisateur se trouve dans un pays étranger, son téléphone mobile recherche les ré-
seaux disponibles et se connecte au réseau étranger compatible le plus fort. Cette recherche se
fait grâce à des mécanismes tels que la sélection automatique du réseau ou la sélection manuelle
par l'utilisateur.

• Authentification et autorisation

Une fois que le téléphone mobile est connecté au réseau étranger, le processus d'authentification
et d'autorisation a lieu. Le réseau étranger vérifie l'identité de l'utilisateur en roaming à l'aide
des informations d'authentification fournies par l'opérateur d'origine. Cette vérification garantit
que l'utilisateur est autorisé à accéder au réseau étranger et à utiliser les services de communi-
cation.

• Routage des appels et des données :

Lorsqu'un utilisateur en roaming passe un appel ou utilise des données, le réseau étranger reçoit
ces demandes et les route vers le réseau de l'opérateur d'origine. Le réseau d'origine traite en-
suite ces demandes et les achemine vers le destinataire de l'appel ou des données. Ce processus

3
implique des échanges d'informations entre les opérateurs concernés pour assurer une connec-
tivité transparente.

• Facturation et échange de données :

Pour garantir une facturation précise, les opérateurs échangent des informations sur les services
utilisés par les abonnés en roaming. Ces informations sont généralement basées sur les enregis-
trements détaillés des appels et des transactions appelés CDR. Les opérateurs utilisent des for-
mats standardisés tels que le fichier TAP pour échanger ces données de facturation.

• Gestion des tarifs et réglementations :

Les tarifs du roaming peuvent varier en fonction des accords entre les opérateurs et des poli-
tiques tarifaires en vigueur. Cependant, pour éviter les frais excessifs, de nombreuses réglemen-
tations ont été mises en place pour protéger les utilisateurs en roaming.

Ces réglementations peuvent inclure des plafonds tarifaires, des offres spéciales pour les voya-
geurs fréquents et des mécanismes de transparence tarifaire. [1]

1.1.3Types de roaming :

Le service Roaming peut être fourni à l’échelle nationale et internationale, trois types de Roa-
ming sont fournis à travers le monde :

[Link] Le Roaming National

Le Roaming National peut se traduire par l’itinérance nationale. L’abonné peut roamer (se dé-
placer) ou se localiser d’un opérateur mobile à un autre dans un même pays. Le roaming natio-
nal n’est pas vraiment très répandu mais toutefois les opérateurs doivent s’associer entre eux
pour couvrir des zones mal couvertes.

[Link] Le Roaming International

Signifie que l’abonné peut aller roamer sur un opérateur d’un pays étranger. Pour permettre aux
abonnés d’un opérateur mobile de passer en toute transparence d’un réseau de communication
sans fil à un autre.

L’accord bilatéral se décompose en deux parties :

a) Roaming In ou Inbound Roaming:

4
L’opérateur A accueil les abonnés de l’opérateur B.

Le roaming in consiste pour un opérateur donné à facturer les autres opérateurs pour lesquels
les abonnés auraient utilisé son réseau.

b) Roaming Out ou Outbound Roaming:

Dans ce cas, les abonnes de l’opérateur A sont accueillis par l’opérateur B.

Le roaming out consiste pour un operateur donné à recevoir des justificatifs de communication
et facturer ses abonnés en conséquence.

[Link] Interstandard roaming

Il s’agit d’un type de service roaming offert par deux compagnies utilisant deux technologies
différentes CDMA (Code Division Multiple Access), GSM (Global System for Mobile Com-
munication), ce type de service roaming peut être national ou international.

L'interstandard roaming permet aux utilisateurs de téléphones mobiles de rester connectés et de

communiquer lorsqu'ils se déplacent entre des zones de couverture utilisant différentes normes
technologiques.

Cela est possible grâce à des accords et des partenariats entre les opérateurs de télécommunica-
tions qui exploitent les différents réseaux. Ces accords permettent aux opérateurs de partager
leurs infrastructures et d'acheminer les communications entre les différents réseaux afin de four-
nir une connectivité transparente aux utilisateurs en roaming.

L'interstandard roaming peut être particulièrement utile dans les régions où différentes normes
technologiques sont utilisées ou lorsqu'un utilisateur voyage à l'étranger et souhaite continuer à
utiliser son téléphone mobile sans avoir à changer de carte SIM ou d'appareil compatible avec
le réseau local.

1.1.4 Privilèges du roaming

L’implémentation du service roaming offre des avantages indéniables à toutes les parties con-
cernées :

➢ Pour le réseau d’origine Home Public Land Mobile Network (HPLMN)

- Satisfaction de sa clientèle (disponibilité du service n’importe où).

5
- Génération des revenus indirects (à travers les réseaux d’accueil).

- Moins de dépenses dans la mise en place des infrastructures.

- Avantages compétitifs.

➢ Pour le réseau visité Visited Public Land Mobile Network (VPLMN)

- Plus d’abonnés, ce qui induit une utilisation optimale du réseau.

- Génération des revenus.

- Avantages compétitifs.

➢ Pour l’abonné :

- Disponibilité des services n’importe où.

- Possibilité de basculement entre les différents opérateurs du pays d’accueil avec lesquels y’a
eu déjà un accord.

- En utilisant le même numéro d’appel, le roamer est favorisé pour garder tous ses contacts.

- La fidélité à son réseau d’origine, le roamer n’aura pas à se souscrire auprès d’un autre opé-
rateur étranger.

1.1.5 Déroulement des services en roaming

Avant d’entamer toute procédure d’un appel, le roamer doit procéder à une mise à jour de lo-
calisation pour informer le réseau visité de sa position.

6
[Link] Appel entrant

Pays 2
Pays 1
Switch

SS7

Figure 1.01 : Appel entrant à destination d’un Roamer.

Supposant qu’un usager B ayant souscrit à un abonnement avec roaming international auprès
de l’opérateur 1 met sous tension son mobile alors qu’іl se trouve rattachés dans l’opérateur 2.

1- Un message d’attachement MM ATTACH REQUEST est envoyé de la station mobile

au MSC visité à travers la BTS et le BSC. Ce message inclut le LAI et le TMSI mais
sachant que le VLR ne disposant pas d’enregistrement pour cette station mobile, alors
le MSC lui envoie un message MM Identity Request pour qu’il lui acquitte par une
réponse MM Identity Response contenant son IMSI. Le MSC relaye cette information
au VLR via une requête MAP-UPDATE-LOCATION-AREA.
2- D’après le numéro d’IMSI fourni par la station mobile B lors de son attachement au
réseau, le VLR de rattachement met à jour le HLR d’opérateur 1 contenant le profil de
cet usager par une requête MAP-UPDATE-LOCATION.
3- Le HLR met à jour l’enregistrement de l’usager et retourne les informations relatives à
l’usager via une requête MAP-INSERT-SUBSCRIBER-DATA.
4- Un abonné du RTCP de l’opérateur 2 souhaite établir une communication avec l’usager
B, et compose son numéro.
5- Le Class 5 Switch de l’opérateur 2 qui rattache l’appelant analyse le numéro, identifie
qu’il s’agit d’un appel international et route l’appel vers un Class 4 Switch international
de cet opérateur via le message ISUP IAM après avoir réservé un circuit de parole dis-
ponible.

7
 6- Le Class 4 Switch de l’opérateur 2 route à son tour l’appel vers le Class 4 Switch inter-
national de l’opérateur 1 via un message ISUP IAM après analyse du préfixe de cet
opérateur.
7- Le Class 4 Switch de l’opérateur 1 analyse le numéro de destination et il identifie que
l’appelé appartient au réseau mobile de l’opérateur 2, il route l’appel vers un GMSC de
l’opérateur 1 le plus proche possible de ce class 4 switches, après avoir réservé un circuit
de parole avec ce GMSC.
8- Le GMSC interroge le HLR via une requête MAP-SEND-ROUTING-INFORMATON
pour connaitre la localisation de la MS.
9- Le HLR de l’opérateur 1 demande au VLR de l’opérateur 2 un MSRN à l’aide de la
requête MAP-PROVIDE-ROAMING-NUMBER.
10- Le VLR affecte alors un MSRN à ce mobile et le retourne au HLR avec la réponse
MAP-PROVIDE-ROAMING-NUMBER-ACK.
11- Puis le HLR retourne à son tour ce MSRN au GMSC demandeur avec la réponse MAP-
SEND-ROUTING-INFORMATON-ACK.
12- Le GMSC analyse le MSRN et identifie qu’il s’agit d’un appel vers l’étranger. Il route
alors l’appel à un class 4 Switch international de l’opérateur 1 après avoir réservé un
circuit de parole libre avec ce dernier (message ISUP IAM).
13- Le class 4 Switch de l’opérateur 1 route l’appel à son tour à un class 4 Switch interna-
tional de l’opérateur 2.
14- Cette dernière analyse le MSRN et achemine l’appel vers le MSC de rattachement de la
station mobile appelée.
15- Le VLR gérant la zone de couverture de ce MSC retrouve, par l’opération de paging sur
toutes les BTS de la zone de localisation, le mobile demandé.

[Link] Appel sortant international

L’abonné mobile désire appeler l’abonne fixe d’un autre pays, il entame une procédure d’appel
au cas d’un appel national. Le VMSC/VLR lit le profil de l’abonne (restriction d’appel en par-
ticulier) et vérifie que l’appel est autorisé. Le VMSC établit l’appel par l’intermédiaire d’un
centre de transit international à partir duquel il est routé vers le pays destinataire toujours sur la
base du numéro composé. Dans ce cas, le PLMN qui est le PLMN nominal de l’abonne n’in-
tervient pas dans l’établissement de l’appel. A la fin de la communication ou ultérieurement le

8
VMSC/VLR va transmettre les données de facturation au PLMN pour que l’opérateur puisse
facturer directement la communication à l’abonné.

[Link] Service de messages courts (SMS)

Le service de messages courts offert par le réseau GSM (SMS, pour Short Messages Service)
permet à un utilisateur de composer un message textuel d'au plus 160 caractères à partir de son
terminal mobile et de l'envoyer à un destinataire possédant également un téléphone mobile
GSM. L'un des atouts de ce service, est son adaptabilité aux circonstances où l'écrit est le mieux
adapté en particulier lorsque l'on a besoin de transmettre un message à une personne sans vou-
loir la déranger (réunion, heure tardive...) ou bien lorsque son environnement immédiat ne per-
met pas une conversation téléphonique dans de bonnes conditions (bus, taxi- moto, lieux
bruyants...)

En outre, lors d'un évènement important entraînant de nombreux appels d'abonnés reliés à une
même cellule, la communication vocale devient de plus en plus difficile alors que les SMS sont
acheminés correctement ; en ce sens, les SMS sont plus disponibles que la voix, et notons que
la réception des SMS en état de roaming international est gratuite contrairement aux appels
reçus qui sont facturés.

[Link] Service DATA

Le déroulement du service de données (DATA) en roaming :

1- Activation du roaming : Avant de pouvoir utiliser les services de données en roaming,

vous devez vous assurer que le roaming des données est activé sur votre compte auprès
de votre opérateur d'origine. Certains opérateurs activent automatiquement le service de
données roaming, tandis que d'autres peuvent exiger une activation manuelle ou vous
offrir des options de gestion du roaming via une application ou un portail en ligne.
2- Détection du réseau VPLMN : Lorsque vous arrivez dans un pays étranger, votre télé-
phone mobile recherche automatiquement les réseaux disponibles. Il détectera les ré-
seaux VPLMN locaux disponibles. Vous pouvez également sélectionner manuellement
un réseau VPLMN si plusieurs options sont disponibles.
3- Établissement de la connexion : Une fois que votre téléphone mobile se connecte au
réseau VPLMN, il établit une connexion de données avec ce réseau. Cette connexion
permet à votre téléphone d'envoyer et de recevoir des données via le réseau du VPLMN.

9
 4- Accès aux services de données : Une fois que la connexion est établie, vous pouvez
accéder aux services de données tels que la navigation sur Internet, l'envoi et la réception
d'e-mails, l'utilisation d'applications en ligne, la messagerie instantanée, etc. Les ser-
vices de données en roaming sont généralement similaires à ceux que vous utilisez dans
votre pays d'origine, bien que certaines restrictions ou différences puissent exister en
fonction des accords de roaming et des politiques du VPLMN.

1.1.6 Mise à jour de localisation d’un Roamer

Pour la mise à jour de localisation internationale, la procédure est presque la même qu’au niveau
national. Considérons un abonné d’un PLMN-1 se présentant dans un PLMN-2 autre que son
PLMN d’origine (VPLMN).

La station mobile transmet son IMSI (International Mobile Subscriber Identity) au MSC (Mo-
bile Switching Center) /VLR (Visitor Location Register) sous la couverture duquel elle se
trouve qui est appelé dans ce cas VMSC (Visited MSC), celui-ci doit contacter le HLR (Home
Location Register de l’abonné, et la seule donnée dont dispose le VMSC pour l’adressage SCCP
(Signaling Connection and Control Part) est l’IMSI.

Cependant, avec le réseau de signalisation internationale, l’IMSI ne doit pas être utilisé, Alors,
il est nécessaire de convertir l’IMSI en MGT (Mobile Global Title) pour router les messages de
signalisations vers le HLR approprié. La structure du MGT est arrangée en deux parties, l’une
suit le plan E.164 et l’autre le plan E.212, pour former ensemble une structure conforme à la
recommandation E.214 qui est illustrée dans la figure suivante.

10
 Figure 1.02 : Structure du MGT
Les échanges de message se font ensuite de manière classique. A l’issue de la mise à jour de la
localisation, le VMSC/VLR contient l’ensemble du profile de l’abonné et le HLR mémorise
l’adresse du VLR où l’abonné est enregistré.

1.1.7 Implémentation de données

Le principe du roaming repose sur une coopération volontaire entre les opérateurs du monde
entier, qui signent des accords bilatéraux pour accueillir les clients de l’un sur le réseau de
l’autre. Il est donc bien clair qu’un mobile d’un operateur donné ne pourra s’inscrire (par con-
séquent fonctionner), sur le réseau d’un autre qu’à la condition qu’un tel accord existe entre les
deux. [18]
L’accord bilatéral s’établit à plusieurs niveaux :
• Contractuel.
• Technique
[Link] Contractuel
Avant de commencer toutes procédures ; le OK entre les deux opérateurs concernés c’est à
dіre, être favorable pour signer le contrat.
[Link] Technique
Le côté technique consiste :
- L’échange des documents : IR21 (International Roaming 21), AA14, puces de test.
- L’implémentation.
- Remplir l’IR24 (International Roaming 24).
- L’ouverture commerciale.
11
[Link] L’échange des documents

a) Présentation de l’IR21

C’est une base de données spécifique à l’opérateur, elle a été créée pour stocker les informations
les plus importantes pour accomplir le roaming, elle est considérée comme une identité propre
à chaque opérateur. [18]
Parmi ces données, on a :
Données liées à l’opérateur :
- Le nom de l’opérateur.
- Le code du pays de l’opérateur.
- La liste des technologies utilisées et les fréquences allouées à l’opérateur.

Le E.164 (CC+NDC).
- Le E.212 (MCC+ MNC).
- Le E.214 MGT.
- Signalisation.
Données concernant GPRS :
- APN configurés par l’opérateur : MMS, WAP, internet, BlackBerry.

Voici un aperçu du contenu du document IR21 :

Figure 1.03 : Extrait du contenu de l’IR21

b) Présentation de L’IR24

C’est un document envoyé par l’opérateur étranger, il est décomposé en deux parties :
- Une partie décrite l’opérateur d’origine ainsi que ses équipements. [18]
12
- Partie teste voix et sms

HPLMN VPLMN
2G / GSM 2G / GSM
3G / UMTS 2G / GSM
2G / GSM 3G / UMTS
3G / UMTS 3G / UMTS
Tableau 1.01 : Scenario de test Roaming
- Partie description (Network Operator Information)
HPLMN (a) ...…...............................................................................................
VPLMN (b) …..................................................................................................
Date of Tests …................................................................................................
Testing personnel PLMN (a).............................................................................
Tel/Fax: ……………………………………………….
Testing personnel PLMN (b)............................................................................
Tel/Fax: ……………………………………………….
HLR Identity/Identities.....................................................................................
HLR Manufacturer(s)........................................................................................
GMSC Identity/Identities...................................................................................
GMSC Manufacturer(s).....................................................................................
GMSC Software Build Level(s)........................................................................
VMSC Identity/Identities..................................................................................
VMSC Manufacturer(s).....................................................................................
VMSC Software Build Level(s)........................................................................
SMS-SC Identity / Identities …………………………………………………
SMS-SC Manufacturer(s) ……………………………………………………
SMS-SC Software Build Level(s) ……………………………………………
- Partie test
1) Location Update by MS (a) in VPLMN (b) (mise a jour de localisation d’un
Roamer)
(a) VLR Record contents :
MSISDN ..................................................................................................
IMSI .............................................................................................................
Teleservices: Speech [si oui = Yes/X=No]..............................
SMS MO [X].............. SMS MT [X]..............

13
Fax [X]....................................................
Bearer Services.......................................................................................
2) Operator Control of Service (contrôle des services de l’operateur)
3) MS1 (a) Calls MS2 (a), both Roamed To VPLMN (b) (MS1 appele MS2, les deux sont des
Roamers dans VPLMN)
Les autres tests sont les suivants
- PSTN Telephone(b) Calls MS
- PSTN Telephone (b) Calls MS (a) Roamed To Country (b) - IMSI Detached Supple-
mentary Service Test Results
- Barring Of All Outgoing Calls [BAOC] (interdiction de Tous les appels sortants)
- Barring Of Outgoing International Calls [BOIC] (interdiction de Tous les appels inter-
nationaux sortants)
- Barring Of Outgoing International Calls except To Home PLMN Country [BOICexHC]
(interdiction de tous les appels internationaux sortants sauf les appels vers HPLMN)
- Barring Of All Incoming Calls [BAIC / BAICroaming] (interdiction de Tous les appels
entrants)
- Call Forwarding On Not Reachable (Before IMSI Detach, TAKE BATTERY OFF
WHILE PHONE IS SWITCHED ON). [CFNRc] (le renvoi d'appel si inaccessible (enlever la
batterie avant imsi detach)
- Call Forwarding on Not Reachable (After IMSI Detach, SWITCH THE PHONE
OFF) [CFNRc] (le renvoi d'appel si éteint ou hors la zone de couverture).
- Call Forwarding On Busy [CFB] (le renvoi d'appel si occupé).
- Call Forward On No Reply [CFNRy] (le renvoi d'appel si non réponse).

1.2 Le CDR

Les CDRs (Call Details Records) sont des enregistrements détaillés des appels téléphoniques
effectués et reçus sur un réseau de télécommunications. Voici quelques points essentiels à sa-
voir sur les CDRs dans le contexte des opérateurs de télécommunications :

• Contenu des CDR : Les CDRs contiennent des informations détaillées sur les appels
téléphoniques, y compris les numéros d'appelant et de destinataire, la date et l'heure de
l'appel, la durée de l'appel, la localisation géographique, les services utilisés (appels
vocaux, SMS, données), etc.
➢ Quand l'appel a eu lieu (date et heure)
14
➢ La durée de l'appel (en minutes)
➢ Qui a appelé qui (numéros de téléphone de la source et de la destination)
➢ Quel type d'appel a été effectué (entrant, sortant, gratuit)
➢ Combien l'appel a-t-il coûté (sur la base d'un tarif à la minute) ?

Figure 1.04: Le CDR

• Utilisation des CDRs : Les opérateurs de télécommunications utilisent les CDRs à des
fins diverses, notamment la facturation des services téléphoniques, la gestion du trafic
réseau, la résolution des problèmes techniques, la sécurité du réseau et la conformité
aux réglementations en vigueur. Les transmissions de communications qui ne coûtent
pas d'argent sont généralement exclues du CDR. De nombreux services de voix sur IP
(VoIP) proposent des appels gratuits de SIP à SIP (Session Initiation Protocol). Cela
signifie qu'un téléphone VoIP appelle un autre téléphone VoIP sans jamais passer par
le réseau téléphonique public commuté (RTPC).
• Analyse des CDRs : Les opérateurs peuvent analyser les CDRs pour obtenir des infor-
mations sur le comportement des utilisateurs, les tendances de trafic, les modèles d'ap-
pels, etc. Ces analyses peuvent être utilisées pour optimiser le réseau, améliorer la qua-
lité de service, prendre des décisions stratégiques et développer de nouveaux services.
• Protection des données : Les CDRs contiennent des informations sensibles sur les com-
munications des utilisateurs, il est donc essentiel pour les opérateurs de mettre en place
des mesures de sécurité appropriées pour protéger la confidentialité de ces données. Ils
doivent respecter les lois et réglementations sur la protection des données personnelles
et mettre en œuvre des protocoles de sécurité robustes pour éviter les abus ou les viola-
tions de confidentialité.
• Conservation des CDRs : Les opérateurs peuvent être tenus par la réglementation de
conserver les CDRs pendant une certaine période, généralement dans le but de faciliter

15
 les enquêtes légales, la résolution de litiges ou d'autres exigences légales. La durée de
conservation peut varier en fonction de la législation locale.

En roaming, les CDRs jouent un rôle essentiel : la facturation, la tarification, l’analyse du trafic,
gestion des problèmes, et les conformités réglementaires sont des points importants pour l’uti-
lité du CDR.

1.3 Le fichier TAP

Un fichier TAP (Transferred Account Procedure) est un format de fichier utilisé dans l'industrie
des télécommunications pour l'échange d'informations liées à la facturation et à la compensation
des services de télécommunication.

1.3.1 Les contenus d’un fichier TAP

Les fichiers TAP incluent des informations essentielles pour la facturation et la compensation,
telles que l'identification des clients, les détails des services utilisés, les tarifs applicables, etc…

Chaque enregistrement contient des informations spécifiques sur un événement ou une transac-
tion de service, y compris :

➢ Numéro de téléphone : Numéro d'appelant ou de destinataire.

➢ Date et heure : Moment où le service a été utilisé.
➢ Durée : Durée de l'appel ou de la session de service.
➢ Type de service : Indicateur du type de service fourni, tel que voix, SMS, données, etc.
➢ Tarification : Informations sur les tarifs applicables au service utilisé.
➢ Volume : Quantité de données consommées, le cas échéant.
➢ Taxes et frais : Informations sur les taxes, les frais d roaming ou d'autres frais associés
au service.

1.3.2 Les protocoles de transfert d’un fichier TAP.

Les fichiers TAP sont généralement transférés entre les parties par le biais de protocoles de
transfert de fichiers tels que FTP (File Transfer Protocol), SFTP (Secure File Transfer Protocol)
ou HTTPS (Hypertext Transfer Protocol Secure).
Ces protocoles garantissent un transfert sécurisé et fiable des fichiers TAP.
Protocoles Description

16
FTP FTP est un protocole de transfert de fichiers
largement utilisé. Il permet de transférer des
fichiers de manière fiable entre un client et un
serveur via un réseau. Les fichiers TAP peu-
vent être envoyés et reçus en utilisant des
clients FTP pour l'envoi et la réception des fi-
chiers.
SFTP SFTP est une extension sécurisée du proto-
cole FTP. Il utilise une connexion sécurisée
SSH (Secure Shell) pour transférer les fi-
chiers, offrant ainsi un niveau supplémentaire
de protection des données. SFTP est souvent
préféré lorsque la sécurité des transferts de fi-
chiers est primordiale.
SCP (Secure Copy) SCP est un protocole de transfert de fichiers
sécurisé basé sur SSH. Il permet de copier des
fichiers entre des ordinateurs locaux et dis-
tants de manière sécurisée. Bien qu'il soit si-
milaire à SFTP, SCP est généralement utilisé
pour des transferts de fichiers individuels
plutôt que pour des transferts de fichiers en
vrac.

HTTP (Hypertext Transfer Protocol) / HTTP et HTTPS sont des protocoles de trans-
HTTPS (Hypertext Transfer Protocol Secure) fert de données couramment utilisés pour les
communications web. Les fichiers TAP peu-
vent être transférés via HTTP/HTTPS.
AS2 (Applicability Statement 2) AS2 est un protocole de transfert sécurisé de
données basé sur HTTP/HTTPS et utilisant
des messages électroniques sécurisés. Il per-
met d'échanger des fichiers TAP de manière
sécurisée entre les partenaires commerciaux

17
 en s'appuyant sur des certificats de sécurité et
des mécanismes de chiffrement.

Tableau 1.02 : les protocoles de transfer d’un fichier TAP

Ces protocoles de transfert offrent différents niveaux de sécurité et de fiabilité. Le choix du
protocole dépend des besoins spécifiques de l'opérateur de télécommunications et de ses parte-
naires commerciaux, ainsi que des exigences en matière de sécurité et de volumétrie des fichiers
TAP échangés.

1.3.3 Les deux types de fichiers TAP pour les opérateurs de télécommunications.
Il existe deux types principaux types : TAPIN et TAPOUT.

[Link] TAPIN

Le fichier TAPIN, en revanche, est généralement reçu par l'opérateur de télécommunications.

Il est envoyé par un tiers, tel qu'un partenaire de roaming ou un fournisseur de services, pour
fournir des informations détaillées sur les services consommés par les clients de l'opérateur
lorsqu'ils utilisent des réseaux étrangers. Le fichier TAPOUT contient les enregistrements dé-
taillés des services utilisés par les clients en roaming, tels que les appels, les SMS, les données,
etc. Ces informations sont utilisées par l'opérateur pour la facturation et la compensation liées
en roaming.

[Link] TAPOUT

Le fichier TAPOUT est généralement fourni par l'opérateur de télécommunications qui envoie
des données de facturation et de compensation à un tiers, tel qu'un fournisseur de services ou
un organisme de régulation. Le fichier TAPIN contient les enregistrements détaillés des ser-
vices fournis par l'opérateur, y compris les informations sur les appels, les SMS, les données,
etc. Ces informations sont utilisées par le tiers pour la facturation des clients, la gestion des
revenus ou d'autres processus associés

La principale différence entre les fichiers TAPIN et TAPOUT réside dans la direction de
l'échange d'informations. Le TAPIN est reçu par l'opérateur pour recevoir des informations dé-
taillées sur les services utilisés par ses clients en roaming provenant d'un tiers, tandis que le
TAPOUT est fourni par l'opérateur pour envoyer des données de facturation et de compensation

18
à un tiers. Ces deux types de fichiers jouent un rôle essentiel dans le processus de facturation et
de compensation entre les opérateurs et d'autres acteurs de l'industrie des télécommunications.

1.3.4 La structure d’un fichier TAP

2 Structure logique.
➢ Data interchange (échange de données)

La structure du fichier TAP est généralement structuré en enregistrements individuels, égale-

ment appelés lignes ou enregistrements de données. Chaque enregistrement contient des
champs spécifiques qui représentent les informations détaillées sur les services de télécommu-
nication fournis ou utilisés ainsi les champs de données dans un fichier TAP représentent les
informations clés nécessaires à la facturation, à la comptabilité et à d'autres processus associés.
Les champs peuvent inclure des éléments tels que le numéro de compte, le numéro de téléphone,
la date et l'heure de l'événement, la durée de l'appel, le type de service, le tarif, le volume de
données, etc. [14]

Figure 1.05 : structure logique du data interchange

19
 ➢ Transfert Batch

Dans un transfert batch d'un fichier TAP le contenu dépendra des spécifications et des besoins
des parties impliquées dans l'échange de données. Cependant, voici les contenus couramment
inclus dans un transfert batch de fichier TAP :

• En-tête du fichier : L'en-tête du fichier contient des informations générales sur le fichier
TAP, telles que la version du format de fichier, la date et l'heure de création du fichier,
l'identifiant unique du fichier, etc. Cela permet d'identifier et de suivre le fichier TAP
spécifique.
• Enregistrements de service : Les enregistrements de service représentent les détails des
services de télécommunication fournis.
• Pied de page du fichier : Le pied de page du fichier peut contenir des informations de
contrôle, telles que le nombre total d'enregistrements dans le fichier, des sommes cumu-
latives, des codes de vérification ou d'autres informations destinées à vérifier l'intégrité
du fichier TAP.
Ces éléments représentent généralement les contenus de base d'un transfert batch dans un
fichier TAP. Il est important de noter que la structure et le contenu exacts peuvent varier en
fonction des spécifications techniques, des besoins des parties prenantes et des réglementa-
tions en vigueur. Les détails spécifiques sur les champs de données et leur format peuvent
être définis dans des documents de spécification et des accords contractuels entre les parties.
[14]

20
 Figure 1.06 : structure logique du transfert batch
➢ Batch Control Information

Le "Batch Control Information" (informations de contrôle de lot) dans un fichier TAP contient
des informations récapitulatives sur le lot de transactions inclus dans le fichier. Ces informa-
tions sont généralement placées dans un enregistrement distinct pour faciliter la gestion et le
contrôle des lots de données. Voici les informations couramment incluses dans le Batch Control
Information d'un fichier TAP :

- Batch ID (identifiant de lot) : C'est un identifiant unique qui permet de différencier le

lot de transactions des autres lots. Il est généralement utilisé pour le suivi et la référence.
- Batch Sequence Number (numéro de séquence de lot) : Il s'agit d'un numéro de séquence
qui indique l'ordre du lot dans une série de lots. Il peut être utilisé pour identifier la
position du lot dans une séquence chronologique.
- Date et heure de création du lot : Ces informations indiquent quand le lot a été créé.
- Nombre total d'enregistrements : Il s'agit du nombre total d'enregistrements inclus dans
le lot, y compris les enregistrements de service et éventuellement d'autres types d'enre-
gistrements spécifiques. [14]

21
 Figure 1.07 : structure logique du Batch Control Information
➢ Network information

Le "Network Information" (informations réseau) dans un fichier TAP contient des détails sur
les réseaux de télécommunication impliqués dans la fourniture ou l'utilisation des services de
télécommunication. Ces informations fournissent un contexte sur les opérateurs, les réseaux et
les paramètres associés. [14]

Figure 1.08 : Structure logique de l’information réseau

22
 ➢ Audit Control Info

C’est une section qui fournit des informations de contrôle et de suivi sur le contenu du fichier.

La structure logique d’un Audit Control Info d’un fichier TAP est présenté comme la figure
ci-dessous : [14]

Figure 1.09 : structure logique de l’Audit Control Info

1.3.5 L’utilité du fichier TAP dans le domaine de la télécommunication

Un fichier TAP (Transferred Account Procedure) est utilisé dans le domaine des télécommuni-
cations pour l'échange de données entre différents acteurs impliqués dans la fourniture de ser-
vices de télécommunication.

- La facturation

Le fichier TAP contient des informations détaillées sur les services de télécommunication four-
nis ou utilisés, tels que les appels, les SMS, les données, etc. Ces informations sont essentielles
pour la facturation précise des services aux clients. Le fichier TAP permet de consolider toutes
les transactions et de générer des factures précises en fonction des tarifs et des conditions con-
tractuelles.

- Comptabilité

23
Les informations contenues dans le fichier TAP sont également utilisées pour les processus de
comptabilité des opérateurs de télécommunications. Elles permettent de calculer les coûts as-
sociés à la fourniture des services, de gérer les revenus et les dépenses, et de générer des rap-
ports financiers.

- Analyse des données

Il fournit une quantité importante de données sur les habitudes d'utilisation des clients, les vo-
lumes de trafic, les types de services, etc. Ces données peuvent être utilisées pour effectuer des
analyses approfondies, telles que l'analyse de la consommation, l'identification des tendances
du marché, l'évaluation de la rentabilité des services, etc.

- roaming

Dans le contexte du roaming, le fichier TAP est utilisé pour l'échange de données entre opéra-
teurs pour la facturation et le règlement des services fournis aux clients roamer. Il permet de
suivre les services utilisés par les clients lorsqu'ils se déplacent entre différents réseaux et pays.

1.4 Les processus de facturations

Le processus de facturation suit des étapes dès le MSC (Mobile Switching Center) au DCH
(Data Clearing House).

Pour les appels vocaux effectués dans le réseau visité, les réseaux GSM typiques s'appuient sur
la mise à jour de la localisation et l'authentification de l'enregistreur HLR d'origine.

Si un abonné en roaming reçoit un appel, comme l'enregistreur HLR connaît le VLR/le MSC
visité où la MS est enregistrée, il envoie une demande au MSC visité pour qu'il attribue le
numéro MSRN (Mobile Station Roaming Number) vers lequel le GMSC (Gateway Mobile
Switched Center) acheminera ensuite l'appel.

1.4.1 Le MSC dans la facturation.

Dans les réseaux de télécommunications, le MSC, ou Centre de Commutation Mobile en fran-

çais, est un élément clé dans la facturation des services de communication mobile. Bien que le
MSC ne soit pas directement responsable de la facturation elle-même, il joue un rôle essentiel
dans la collecte des informations nécessaires à la tarification des services.

24
Dans le monde GSM, les enregistrements d'utilisation sont générés dans les centres de commu-
tation mobile (MSC), les centres de service de messages courts (SMSC) et les centres de service
de messagerie vocale (VMSC). Plusieurs types d'enregistrements sont générés, en fonction de
l'utilisation. Par exemple, les enregistrements détaillés des appels (CDR) pour les appels à l'ori-
gine du mobile (MO) et à destination du mobile (MT), les enregistrements détaillés des tran-
sactions pour les MO-SMS, les MT-SMS et d'autres utilisations non vocales. Dans les systèmes
GPRS et 3G, les enregistrements d'utilisation sont générés au niveau des SGSN (Serving GPRS
Support Node), des GGSN (Gateway GPRS Support Node), des MSC et d'une multitude
d'autres éléments de passerelle. Les enregistrements d'utilisation sont générés pour les appels
de données par commutation de paquets, les MS et l'accès au contenu.

Le processus TAP-out permet à un HPMN (le PLMN où le traitement TAPout est effectué)
d'envoyer des enregistrements cotés pour les appels effectués par des itinérants entrants (visi-
teurs de réseaux étrangers) à leurs réseaux d'origine respectifs (VPMN).

Figure 1.10 : Transferred account procedure dans un système de facturation.

25
1.4.2 Le Data Clearing House ou DCH dans le système de facturation.

Le Data Clearing House collecte les fichier TAP provenant des opérateurs de télécommunica-
tions et les traite pour garantir leur intégrité et leur cohérence. Cela peut inclure la validation
des données, la normalisation des formats, l'agrégation de données, la suppression des dou-
blons, etc. Une fois que les données sont préparées, le Data Clearing House les distribue aux
parties prenantes appropriées selon leurs besoins spécifiques.

Un Data Clearing House facilite l'échange de données entre les différents acteurs du secteur des
télécommunications en collectant, en validant, en normalisant et en distribuant les données de
télécommunication. Cela permet aux parties prenantes d'accéder aux données nécessaires pour
leurs opérations, y compris la facturation.

[Link] Le Returned Accounts Procedure ou RAP dans la facturation

Le Returned Accounts Procedure (RAP) définit le format de restitution des informations sur les
erreurs trouvées dans les fichiers/événements TAP transférés et rejette ainsi la responsabilité
financière pour ces fichiers/événements. Les fichiers transférés sont appelés fichiers RAP.

Le module de roaming prend en charge la norme RAP qui permet aux opérateurs de gérer les
enregistrements d'événements d'appels erronés qui sont rejetés, ce qui entraîne une perte de
revenus pour les opérateurs.

1.4.3 Liaison entre le DCH, TAP et RAP

Le DCH, le fichier TAP et le fichier RAP sont tous des éléments liés au processus de facturation
et d'échange de données.

[Link] Collecte et agrégation des données

• Le DCH joue un rôle central dans la collecte des fichiers TAP auprès des différents
opérateurs de télécommunications.
• Le fichier TAP contient des enregistrements détaillés des appels, des sessions et d'autres
transactions de communication.

26
 • La procédure de retour des comptes ou Returned Accounts Procedure (RAP) du GSM
définit le format de retour des informations sur les erreurs trouvées dans les fichiers/évé-
nements TAP transférés et, par conséquent, le rejet de la responsabilité financière pour
ces fichiers/événements. Les fichiers transférés sont appelés fichiers RAP.

[Link] Validation et normalisation des données

• Le DCH vérifie la validité et l'intégrité des fichiers TAP et RAP reçus, s'assurant qu'ils
sont complets et conformes aux spécifications convenues.
• Le DCH peut effectuer des opérations de validation et de normalisation sur les données
des fichiers TAP et RAP pour garantir la cohérence et la fiabilité des informations.

[Link] Médiation et ajustement des données

• Le DCH peut agir en tant que médiateur entre les opérateurs pour résoudre les diver-
gences ou les écarts dans les données des fichiers TAP et RAP.
• Cela peut impliquer des ajustements ou des corrections des enregistrements de factura-
tion pour garantir l'exactitude des montants facturés.

[Link] Facturation et échange de données

• Les données des fichiers TAP sont principalement utilisées pour la facturation inter opé-
rateur, où les opérateurs se facturent mutuellement pour l'utilisation des services de
communication.
• Les données des fichiers RAP peuvent être utilisées pour la facturation interne des opé-
rateurs, l'analyse opérationnelle, et d'autres activités.

Le DCH joue un rôle essentiel dans la collecte, la validation, la normalisation et la médiation

des données des fichiers TAP et RAP. Il facilite l'échange de données entre les opérateurs, la
facturation inter opérateur et interne, ainsi que l'analyse opérationnelle dans le secteur des télé-
communications.

27
 Figure 1.11: relation entre DCH, TAP et RAP

1.4.4 Near Real Time Roaming Data Exchange ou NRTRDE

L'échange de données de roaming en temps quasi réel (NRTRDE) est un processus de garantie
des recettes et de protection contre la fraude qui permet l'échange rapide de données de roaming
entre les opérateurs. Les fichiers NRTRDE sont généralement échangés en 4 heures, alors que
le traitement des fichiers TAP prend au moins 24 heures. Le NRTRDE soutient à la fois la
protection contre la fraude et le processus de garantie des recettes, en veillant à ce que les dos-
siers TAP échangés soient complets et exacts, avec l'ensemble correct d'informations requises
pour le processus d'évaluation et de facturation, fournissant un point supplémentaire de récon-
ciliation pour le trafic de roaming.

Dans un système de "Near Real Time Roaming Data Exchange", les informations sur l'abonné,
les services disponibles et les tarifs sont échangées entre les opérateurs presque instantanément,
ce qui permet à l'utilisateur d'accéder rapidement aux services de communication une fois con-
necté au réseau visité. Cela inclut des informations telles que l'authentification de l'abonné, la
vérification des droits d'accès aux services, la tarification en temps réel et la collecte des don-
nées de facturation.

L'échange de données en temps quasi réel est crucial pour assurer une expérience transparente
pour les utilisateurs en roaming, car cela permet aux opérateurs de fournir des services sans
délai significatif. Cela inclut la possibilité d'accéder à Internet, de passer et de recevoir des
appels, d'envoyer des messages texte, ainsi que d'utiliser d'autres services de communication
mobiles tout en étant à l'étranger.

28
 CONCLUSION

L'avènement des technologies de communication mobile a irréversiblement lié nos vies à tra-
vers des frontières géographiques, créant un réseau interconnecté qui transcende les distances
physiques. Le roaming, en tant que mécanisme important de cette connectivité mondiale, a ou-
vert les portes à des expériences de voyage et de communication sans précédent. À travers cette
exploration des CDR, des fichiers TAP et de leur rôle crucial dans le fonctionnement du roa-
ming, nous avons plongé dans les coulisses du miracle de rester connectés, peu importe où l'on
se trouve.

Les CDRs, avec leur richesse d'informations encapsulant chaque interaction, illustrent le flux
incessant d'échanges qui définit notre époque. Les fichiers TAP, en tant que ponts numériques
entre les opérateurs, sont les artisans de cette harmonie technologique qui transcende les fron-
tières nationales. La collaboration entre les opérateurs, bien qu'invisible pour la plupart d'entre
nous, est un ballet complexe d'interopérabilité qui maintient nos conversations en cours et nos
messages envolés, où que nous soyons.

Ainsi, en plongeant dans l'univers des CDR, des fichiers TAP et du roaming, nous gagnons une
appréciation profonde de la manière dont la technologie façonne notre manière de communi-
quer, de voyager et d'explorer le monde. Alors que nous clôturons cette exploration, souvenons-
nous que derrière chaque appel, chaque message et chaque moment de connexion, il y a une
infrastructure complexe mais interconnectée qui définit notre ère numérique.

29
 CHAPITRE II : ARCHITECTURE DU SYSTEME DE FACTU-
RATION EN ROAMING
Au cœur de l'expérience de roaming, au-delà des signaux invisibles qui nous relient aux per-
sonnes et aux informations à travers le monde, se trouve une structure complexe et essentielle
: l'architecture du système de facturation en roaming. Alors que nous nous aventurons plus loin
dans les mécanismes qui permettent cette continuité de communication sans faille à travers les
frontières, il est impératif de plonger dans les fondations de ce système crucial. L'architecture
du système de facturation en roaming est bien plus qu'une simple infrastructure technique. C'est
une toile virtuelle tissée avec soin, reliant les opérateurs de télécommunication du monde entier
dans un équilibre délicat entre données, protocoles et processus. Chaque appel, chaque message,
chaque interaction est capturée, traduit et acheminé à travers ce réseau global, permettant aux
voyageurs de rester connectés tout en garantissant que chaque service soit comptabilisé avec
précision.

Dans cette exploration du deuxième chapitre, nous allons décortiquer les composantes clés de
cette architecture de facturation en roaming. Des points d'entrée aux centres nerveux de traite-
ment, des couches de sécurité aux protocoles de transfert de données, nous décomposerons cet
écosystème complexe pour en comprendre les rouages internes. Par-delà les aspects techniques,
nous plongerons également dans les considérations opérationnelles et financières qui guident le
fonctionnement harmonieux de ce système, assurant une expérience de roaming fluide et trans-
parente pour les utilisateurs.

2.1 Architecture du roaming 2G, 3G et 4G

La mobilité est la clé du succès des réseaux mobiles. Le roaming a étendu la définition de la
mobilité au-delà de la technologie, des réseaux et des frontières des pays. Avec le déploiement
généralisé des technologies GSM et GPRS et maintenant 3G/3G+, les usagers ont la flexibilité
d’utiliser leurs services voix, données et SMS dans plus de 700 réseaux. Avec l’arrivée de la
LTE (Long Term Evolution), les services de données seront disponibles en situation de roaming
à très grande vitesse. Par ailleurs, des accords de roaming CSFB (Circuit Switched Fall Back)
et VoLTE permettront à un client LTE d’accéder aux services voix et SMS depuis des réseaux
LTE visités. [2]

30
2.1.1 Structure pour le roaming 2G/3G

Afin de permettre le roaming 2G/3G, la structure suivante doit être mise en œuvre :
Connectivité entre réseaux mobiles 2G/3G qui consiste à :
A. Des liens de signalisation SS7 ou SIGTRAN pour le trafic MAP entre le réseau visité et
le réseau nominal. Ces liens sont nécessaires pour l ’échange de signalisation entre le
MSC Server/VLR ainsi que le SGSN du réseau visité et le HLR du réseau nominal.
B. Des liens d ’interconnexion pour le transport de la voix et des données du domaine
circuit entre le réseau visité et le réseau nominal.
C. Des liens d ’interconnexion pour le transport des paquets IP du domaine paquet entre le
réseau visité et le réseau nominal. Il s ’agit du GRX (GPRS Roaming Exchange) avec
25 opérateurs le constituant.
Le roaming GSM requiert des interconnexions de type A. et B.
Le roaming GPRS requiert des interconnexions de type A. et C.
Le roaming 3G requiert tous les types d ’interconnexion. [2]

Figure 2.31 : Connectivité entre réseau visité et réseau nominal 2G/3G

[Link] Réseau de signalisation SS7/SIGTRAN

Le premier réseau d’interconnexion est le réseau de signalisation. Un réseau de signalisation
international SS7/SIGTRAN doit permettre à un MSC Server ou un SGSN visité d’interagir
avec le HLR nominal pour : [2]

31
 • Obtenir des vecteurs d’authentification pour authentifier l’UE. En 2G, l’UE s’authenti-
fie au réseau. En 3G, l’authentification est mutuelle.
• Obtenir le profil de l’usager. Le profil 2G/3G circuit contient la liste des services (ser-
vices de base, services complémentaires, service à valeur ajoutée CAMEL) et leurs
marques associées. Le profil 2G/3G paquet contient la liste des APNs (Access Point
Name) autorisés pour une UE donnée.
• Informer le HLR de la localisation de l’UE, c’est à dire l’adresse du MSC Serveur ou
du SGSN qui prend en charge l’UE actuellement.

Figure 2.02 : SS7/SIGTRAN international pour le roaming

Comme montré à la figure 2.02, les réseaux SS7/SIGTRAN des réseaux visité et nominal sont
interconnectés entre eux via un réseau SS7/SIGTRAN international. Différents brokers inter-
nationaux forment le réseaux SS7/SIGTRAN international avec une topologie maillée entre
eux.

[Link] Établissement de contexte PDP depuis un réseau visité

Lorsque l'usager est dans son réseau nominal, l'activation d'un contexte PDP (Packet Data Pro-
tocol) conduit à la création d'un tunnel entre les nœuds SGSN et GGSN de ce réseau nominal.
Le GGSN est identifié par le paramètre APN présent dans la demande d’établissement de con-
texte PDP. Cet APN (Packet Data Protocol) est traduit par le DNS (Domaine Name System) en
une adresse IP de GGSN. Si l'usager est dans un réseau visité, l'activation d'un contexte PDP
induit la création d'un tunnel GTP entre le SGSN visité et le GGSN nominal. Le SGSN visité
32
identifie le GGSN à l'aide de l'APN. Cette approche peut être perçue comme inefficace car elle
crée un effet trombone, mais en fait, 80% du trafic d'un roamer typique est échangé avec des
serveurs dans le pays d'origine. Le principal inconvénient de cette solution est le grand nombre
de tunnel établis à travers le backbone inter-PLMN (GRX) et l'ajout de nouveaux nœuds, les
BGs (Border Gateways). Toutefois elle permet aux deux opérateurs de connaître le nombre
d’octets émis et reçus par l’UE depuis le réseau visité. Il est possible en théorie que le SGSN et
le GGSN soient dans le réseau visité. En effet, le profil paquet de l’UE liste l’ensemble des
APNs autorisés pour cet UE, et pour chaque APN une variable « VPLMN address Allowed »
est présente pouvant être positionnée à « enabled » ou « disabled ». La valeur « enabled »
signifie que le GGSN pour cet APN sera celui du réseau visité lorsque l’UE sera dans un réseau
visité. En pratique cette variable est toujours positionnée à « disabled » pour forcer le trafic à
être routé à un GGSN nominal. [2]

Figure 2.03 : Procédure d ’établissement de Contexte PDP depuis un réseau visité

Dans ce scénario décrit à la figure 2.03, un roamer s’attache au SGSN d’un réseau visité et
active un contexte PDP qui implique un GGSN présent dans le réseau nominal. Le SGSN visité
doit apprendre l’adresse IP de ce GGSN nominal pour lui envoyer une requête GTP-C Create
PDP Context Request.
Le SGSN visité utilise l’APN soumis par l’UE pour interroger le DNS. La figure ci-dessus
décrit la procédure de résolution DNS en détail. Elle consiste en les étapes suivantes :
33
1. L’UE envoie une requête MS Activate PDP context Request au SGSN visité pour demander
l’établissement du context PDP. Ce message contient l’APN du service que veut utiliser l’usa-
ger.
2. Le SGSN visité rajoute à l’APN l’identifiant du réseau nominal et envoie une requête DNS
à son DNS local.
3. Le DNS local n’ayant pas la correspondance entre cet APN et l’adresse IP du GGSN nominal
concerné, route la demande au DNS du GRX (root DNS).,
4. Le DNS du GRX répond en retournant l’adresse IP du DNS associé à l’opérateur.
5. Le DNS visité interroge alors le DNS nominal pour obtenir la correspondance.
6. Le DNS nominal retourne la ou les adresses IP du (des) GGSN concerné(s).
7. Le DNS visité retourne cette information au SGSN visité.
8. Le SGSN visité choisit une des adresses IP si plusieurs lui ont été retournées par son
DNS visité et émet une requête GTP-C Create PDP Context Request au GGSN correspondant.
9. Le PCEF du GGSN contacte le PCRF tous deux appartenant au réseau nominal, afin d ’ob-
tenir les règles PCC (Policy and Charging Control).
10. Le PRF retourne les règles au PCEF.
11. La réponse GTP-C Create PDP Context Response du GGSN indique au SGSN qu ’un tunnel
réseau est établi entre SGSN et GGSN.
Il reste au SGSN de demander au BSC ou RNC à l ’accès de créer un RAB (Radio Access
Bearer) qui correspond à une connectivité entre l ’UE et le SGSN.

2.1.2 Connectivité entre réseaux mobiles 4G (LTE/ePC) [2]

Réseau de signalisation DIAMETER

Le premier réseau d’interconnexion est le réseau de signalisation. Un réseau de signalisation
international DIAMETER doit permettre à un MME visité d’interagir avec le HSS nominal
pour : [2]
• Obtenir des vecteurs d’authentification pour authentifier l’UE. En 4G, l’authentification
est mutuelle.
• Obtenir le profil de l’usager. Le profil 4G est uniquement un profil paquet et contient la
liste des APNs autorisés pour une UE donnée.
• Informer le HSS de la localisation de l’UE, c’est à dire l’adresse du MME qui prend en
charge l’UE actuellement. L’adresse est un hostname.

34
 Figure 2.04 : Réseau DIAMETER International pour le roaming LTE
Comme montré à la figure 2.04, les réseaux de signalisation DIAMETER des réseaux visité et
nominal sont interconnectés entre eux via un réseau DIAMETER international. Différents bro-
kers internationaux forment le réseau DIAMETER international avec une topologie maillée
entre eux.

[Link] Connectivité entre réseaux mobiles LTE/ePC (roaming LTE) :

A. Des liens de signalisation SCTP/IP (Stream Control Transmission Protocol/Internet Pro-
tocol) pour le trafic DIAMETER entre le réseau visité et le réseau [Link] liens
sont nécessaires pour l ’échange de signalisation entre le MME/S4-SGSN du réseau
visité et le HSS (Home Subscriber Server) du réseau nominal.
B. Des liens d ’interconnexion pour le transport des paquets IP du domaine paquet entre le
réseau visité et le réseau nominal. Il s ’agit de l ’IPX (IP Exchange Network)
[Link] Roaming CSFB
La fonctionnalité CSFB ou Circuit Switched Fall back (repli en circuit commuté) dans le réseau
4G est réalisée en utilisant l’interface SGs entre le MSC Server et le MME (Figure 2.05).
L’interface SGs est basée sur les fonctionnalités de l’interface Gs définie entre le MSC/VLR et
le SGSN, mais qui n’a jamais été implantée. L’interface SGs s ‘appuie sur un protocole
SGsAP/SCTP/IP. Dans ce contexte, il est considéré que la LTE ne fournit qu’un accès data.
35
Le réseau circuit 2G/3G existant est réutilisé pour fournir les services de téléphonie au client
LTE.L’UE n’utilise qu’une seule technologie radio à la fois. Lorsque l’UE est mise sous tension
sous couverture LTE, il demande un attachement combiné CS+EPS au MME. EPS (Evolved
Packet Ssystem) signifie réseau 4G. Le MME réalise la procédure d’enregistrement de l’UE à
l’EPS incluant l’authentification, la mise à jour des informations de localisation du profil de
l’usager, l’obtention du profil auprès du HSS et l’établissement du premier default bearer pour
l’UE. Le MME traduit la Tracking Area Identity de l’UE en sa Location Area pour identifier le
MSC Server/VLR qui prend en charge la zone de couverture du l’UE. Le MME informe le
MSC Server/VLR via l’interface SGs qu’il a reçu une demande d’attachement combiné
CS+EPS de l’UE. Le MSC Server/VLR réalise la procédure d’enregistrement au domaine cir-
cuit de l’UE. L’UE demande aussi un détachement combiné ainsi que la mise à jour combinée
de sa TA.
Lors d’un appel entrant ou sortant, l’UE est transférée de la technologie radio LTE à la techno-
logie radio 2G ou 3G où il peut réaliser une procédure normale d’établissement d’appel via le
MSC Server. Par contre, pour l’envoi et la réception de SMS, il n’est pas nécessaire de transfé-
rer l’UE vers la 2G ou 3G. L’UE peut échanger les SMS avec le MSC Server via le MME. LE
MME relayer la signalisation contenant le SMS sur l’interface SGs au MSC Server.
L’accord de roaming CSCF suppose que le MME et le MSC Server du réseau visité disposent
entre eux de l’interface SGs. Par ailleurs le MME visité est apte à supporter des UEs compa-
tibles CSFB.

Figure 2.05 : Architecture CSFB

36
 2.1.3 Roaming VoLTE
VoLTE (Voice Over LTE) est une approche basée sur l ’IMS (IP Multimedia Subsystem).
L’IMS supporte les serveurs d’application relatifs aux services de téléphonie, visiophonie, ser-
vice SMS et services USSD. En situation de roaming 3GPP spécifie que la connectivité IP peut
se terminer dans le réseau nominal (home routed traffic) ou dans le réseau visité (local
breakout). Dans les réseaux GPRS et les réseaux LTE n ’offrant que le service d ’accès à Inter-
net/Intranet, la connectivité se termine dans le réseau nominal. Cela signifie que les entités
MME/SGW appartiennent au réseau visité dans lequel se trouve l ’usager alors que le PGW est
dans le réseau nominal de ce même usager. Appliquer ce modèle à la VoLTE serait probléma-
tique car il impliquerait que le point d ’entrée IMS soit localisé dans le réseau nominal. Les
conséquences sont :
• Le réseau visité ne sera plus informé des sessions multimédia (exemple : Appels voix)
et des messages courts inités ou terminés par l ’usager et donc des revenus de roaming
moindres pour les opérateurs mobiles visités.
• Les exigences réglementaires seront difficiles à respecter :
➢ La signalisation SIP peut être chiffrée entre l ’UE et le P-CSCF nominal et donc le
réseau visité ne pourra pas réaliser l ’interception légale
➢ L’appel d’urgence requiert l’implication du P-CSCF visité.
• Par ailleurs le P-GW dans le réseau nominal accroit le délai des paquets RTP/UDP/IP
sur le plan usager.

Porteur par défaut pour l’accès internet

Porteur par défaut pour l’accès

à IMS

Figure 2.06: Roaming VoLTE/IMS

37
2.1.4 LTE roaming Charging

La complexité des nouveaux modèles de taxations pour supporter l’itinérance en 4G sont plus
nombreux que pour la 3G

• Les cartes Pré-payées. Le standard CAMEL, qui permet l’accès par pré-payement aux
services 3G n’est pas compatible avec la 4G. Ains, les accès au réseau PDN par des
utilisateurs de cartes pré-payées doivent être obligatoirement routées vers le H-PLMN
et ne peuvent donc pas être routés via le V-PLMN. Les opérateurs doivent donc mettre
en place un flux de taxation spécialement dédié aux clients de carte prépayé afin que
ces derniers puissent accéder au PDN via leur P-GW
• Les forfaits : La facturation s’appuie sur les mêmes tickets que le 3G.

Dans le cas de Local breakout, les opérateurs n’ont pas la même visibilité sur les activités des
abonnés puisque la connexion de l’abonnée est gérée par le V-PLMN. Cependant, afin que
l’opérateur Home puisse avoir des informations en temps réels (nécessaire entre autres pour les
forfaits bloqués), il doit établir une interface DIAMETER entre son système de facturation et
le P-GW du réseau visité. [2]

Dans le cas d’un Local Breakout sur des services IMS, le réseau visité crée un CDR (Call Detail
Records) en provenance du S-GWS-Gateway(s). Cependant le CDR ne contient pas toutes les
informations requises pour créer un TAP selon la version 3.12 pour le service utilisé (évènement
ou session). En conséquence de quoi, les opérateurs doivent corréler les CDRs émis par leur
proper réseau avec le CDR crée par l’IMS pour constituer un enregistrement TAP.

2.2 Infrastructures techniques

2.2.1 Présentation des éléments clés

L'architecture du système de facturation en roaming comprend plusieurs composants intercon-

nectés qui permettent la collecte des données de consommation, la médiation, la tarification, la
génération des factures et la gestion des paiements. Les principaux éléments de l'architecture
du système de facturation en roaming sont les suivants : le serveur, la base de données, le mé-
diateurs et les passerelles.

38
[Link] Le serveur

a) Définition

Programme fournissant des services à d’autre programme ou bien, processus accomplissant une
opération sur demande d’un client et transmettant la réponse à ce client. [10]
b) Type de serveur
• Serveurs de fichiers :

Un serveur de fichier est utilisé pour le stockage et la gestion des fichiers utilisateurs, ce type
de serveur a souvent une grande capacité de stockage sur son espace disque. Ainsi, n’importe
quel utilisateur connecté au réseau qui émet des requêtes en direction du serveur peut récupérer
un ou plusieurs fichiers grâce à un Protocole. Il doit être fiable, performant, autorise un fonc-
tionnement permanent, dispose de possibilités d’extensions, permet les changements des
disques sans interruption de fonctionnement du serveur.
• Serveurs de base de données :
Un serveur de base de données sert à stocker, à extraire et à gérer les données dans une base de
données. Il permet également de gérer la mise à jour des données. Il donne un accès simultané
à cette base a plusieurs serveurs et utilisateurs. Enfin, il assure la sécurité et l’intégrité des don-
nées. Et quand on parle de données, on entend peut-être des millions d’éléments simultanément
accessibles par des milliers d’utilisateurs.
• Les serveurs d'applications :
Les serveurs d'applications sont des logiciels occupants la couche centrale dans une architecture
multicouche, qu'elle soit 3-tiers (postes clients, serveur d'applications, serveur de données) ou
étendue (n-tiers). Dans un sens plus large, un serveur d'application peut être une machine ser-
vant à héberger des applications, soit pour permettre leur exécution depuis un poste client (mode
client-serveur de données, généralement partage de fichiers et politiques de gestion des accès),
soit pour déporter l'affichage sur le poste client (mode client-serveur d'affichage).
• Serveur groupware :
Un groupware serveur est un serveur informatique utilisé comme une connexion pour divers
clients qui l'utilisent pour héberger et partager des fichiers dans le cadre d'un environnement de
travail collaboratif. Le nombre de clients connectés à ce serveur dépend généralement de la
portée et de la nature du projet. Depuis cela fait partie d'un projet de groupware, il y a généra-
lement des logiciels installés sur les différents ordinateurs clients pour permettre une meilleure
communication entre les clients et l'accès au serveur. Un serveur de groupware peut être utilisé
39
pour réduire les communications inutiles ou répétitives entre les membres de l'équipe et d'ac-
croître la productivité.

[Link] La base de données

La base de données joue un rôle essentiel dans l'architecture du système de facturation en télé-
communications. Elle sert de référentiel central pour stocker et gérer les données nécessaires
au processus de facturation.

Les principaux rôles de la base de données dans le système de facturation :

Stockage des données de consommation ; la base de données enregistre les données de consom-
mation collectées à partir des CDRs ou d'autres sources. Elle stocke les détails des appels, des
messages, des services de données et d'autres transactions effectuées par les abonnés et pour le
profil d'abonnés ; la base de données contient des profils d'abonnés qui incluent des informa-
tions telles que les informations personnelles, les forfaits, les tarifs, les options de facturation,
les préférences de service, etc. Ces profils aident à personnaliser la facturation en fonction des
besoins et des attributs spécifiques de chaque abonné.

La base de données dans l'architecture du système de facturation joue un rôle central dans le
stockage, la gestion et l'exploitation des données nécessaires au processus de facturation. Elle
permet d'assurer l'exactitude des transactions financières, la personnalisation de la facturation
et la génération de rapports et d'analyses pertinents pour les opérateurs de télécommunications.

[Link] Le système de médiation

Un système de médiation est un composant clé dans le domaine ses télécommunications et de

la facturation des services. Il joue un rôle essentiel dans la collecte, la transformation et l’agré-
gation des données provenant de différentes sources pour les rendre exploitables par les sys-
tèmes de facturation et d’analyse.

Le système de médiation récupère les données brutes générées par les équipements de télécom-
munication, tels que les CDRs, les données de signalisation, les journaux d’évènements, etc.…
[12]

a) Cas d’utilisation d’un système de médiation

• Collecte et validation des enregistrements détaillés des appels
40
 • Filtrage des enregistrements d'appels non pertinents pour la facturation
• Rassemblement
• Corrélation des enregistrements détaillés des appels provenant de différentes sources
d'entrée
• Agrégation des enregistrements partiels relatifs à un même appel
• Changement de format et normalisation des enregistrements détaillés des appels
• Transformation commerciale des données

Dans un scénario de facturation des télécommunications, la médiation est la première étape

après la réception d'un enregistrement détaillé d'appel. Les fichiers d'enregistrement d'appel
médiatisés sont transmis à un moteur d'évaluation, qui calcule les frais associés aux enregistre-
ments d'appel. Dans le monde d'aujourd'hui, les moteurs d'évaluation deviennent de plus en plus
nécessaires pour que le système de facturation des télécommunications puisse répondre aux
besoins croissants des clients pour différents services.

Malgré leur nom, toutes les données transférées via les plateformes de médiation de facturation
ne sont pas utilisées à des fins de facturation. Par exemple, le logiciel de médiation peut générer
des statistiques sur le volume de trafic en fonction du nombre et de l'origine des enregistrements
qu'il traite. Ces statistiques peuvent ensuite être utilisées pour la planification de la capacité,
dans le cadre d'une procédure de surveillance du réseau, ou pour toute autre application de veille
économique.

Au fond, la médiation implique le transfert de données entre divers systèmes, avec ou sans
modification des données, depuis les éléments du réseau jusqu'aux systèmes OSS/BSS.

Les logiciels sophistiqués de médiation de la facturation offrent une fonctionnalité de bout en

bout aux opérateurs de télécommunications. Le logiciel de médiation effectue diverses opéra-
tions, de la collecte des données à la distribution en aval vers des modules tels que la facturation
au détail, le roaming, le règlement des interconnexions, la veille économique, la détection des
fraudes et l'assurance des revenus.

En complément des fonctions de médiation de la facturation, les plateformes de médiation com-

plètes fournissent également des fonctionnalités dédiées à la fourniture de services (les deux
domaines s'entremêlent fréquemment car les services configurés et utilisés par le client final
entraînent la génération d'enregistrements de données d'utilisation dans le réseau).

41
La médiation entre les systèmes n'est pas la seule tâche que la plate-forme de médiation peut
accomplir. En fait, elle peut être utilisée comme agent d'approvisionnement. Les commandes
d'approvisionnement de base peuvent être configurées dans le système de médiation et chaque
fois que nous recevons une demande pour le système qui effectue l'approvisionnement, la de-
mande peut être convertie en un fichier, dans lequel la médiation peut ajouter les commandes
d'approvisionnement du service et l'envoyer au registre de localisation du domicile (HLR) pour
activer n'importe quelle demande. Cela dépend évidemment de la charge, mais peut s'avérer
très utile en cas de crise dans l'autre système.

b) Les objectifs principaux d’un système de médiation

L’objectif d’un médiateur est donc d’assurer une liaison transparente, c’est-à-dire de cacher
l’hétérogénéité des composants mis en jeu. Il s’agit en particulier d’assurer la transparence aux
réseaux, aux SGBD, et dans une certaine mesure aux langages d’accès.
• Transparence aux réseaux : le middleware assure le dialogue requête-réponse qu’ils
soient locaux ou nationaux, voire internationaux et offrant une interface standard de
dialogue à l’application.
• Transparence aux serveurs : la diversité des SGBD offrant des moyens de connexion et
des langages de requêtes souvent différents. Le médiateur doit cacher la diversité et
uniformiser ces langages en s’appuyant le plus possible sur les standards.
• Transparence aux langages : assuré l’envoi des requêtes et la réception des réponses
pour tous les langages de développement utilisés coté client.

[Link] Les passerelles

Dans un système de facturation en roaming, les passerelles jouent un rôle crucial dans l’échange
de données entre les opérateurs de télécommunication impliqués dans la fourniture de service
de roaming. Lorsqu’un abonné d’un autre opérateur se déplace dans un pays étranger et utilise
les services de télécommunication dans un réseau visité, les passerelles interviennent pour per-
mettre une facturation précise des services consommés.

Une passerelle de signalisation (Signaling Gateway) assure l'échange de messages de signali-

sation entre les réseaux domestiques et visités, permettant l'établissement de sessions de com-
munication et la gestion des services de roaming. Aussi, elle facilite la communication entre les
réseaux domestiques et les réseaux visités lorsqu’un utilisateur roamer se connecte à un réseau

42
étranger. Les protocoles de signalisation couramment utilisés dans le roaming incluent le pro-
tocole SS7 (Signaling System 7) et le protocole Diameter. La passerelle de signalisation assure
la traduction et le routage appropriés des messages de signalisation entre les réseaux, permettant
ainsi l’établissement de sessions de communication et la gestion des services de roaming.

D'autre part, une passerelle de données facilite le transfert des données de consommation entre
les réseaux visités et le réseau domestique de l'abonné. Lorsqu'un abonné itinérant utilise des
services de données lors du roaming, la passerelle de données assure le transfert des données
consommées du réseau visité vers le réseau domestique de l'utilisateur. Cela permet au fournis-
seur de service domestique de facturer les services de données consommés par l’utilisateur iti-
nérant avec précision. Les protocoles tels que le GTP (GPRS Tunneling Protocol) et l’IPX (IP
Exchange) sont souvent utilisés pour le transfert de données entre les passerelles de données
des opérateurs.

En combinant les fonctionnalités de ces passerelles, les opérateurs de télécommunication peu-

vent échanger les informations nécessaires à la facturation des services en roaming. Les passe-
relles garantissent que les opérateurs reçoivent les données de signalisation et de consommation
appropriées, leur permettant de facturer les services utilisés par les abonnés itinérants de ma-
nière précise et transparente.

2.2.2 Interactions entre les différents composants du système

Dans un système de facturation en roaming, les composants énumérer en haut interagissent pour
assurer une facturation précise et efficace des services utilisés par les abonnés itinérants.

[Link] Interaction entre un serveur de facturation et une base de données de facturation.

Le premier responsable du stockage de données de facturation liées aux services utilisés par
l’abonné c’est la base de données de facturation cela inclut les détails des appels, les sessions
de données, les durées, les tarifs appliqués, les frais de roaming, etc… le serveur de facturation
utilise alors la base de données de facturation comme référence pour accéder aux données né-
cessaires au processus de facturation.

Aussi, le serveur de facturation interagit avec la base de données de facturation pour

récupérer les informations requises lors du processus de facturation. Lorsqu’il génère les fac-
tures pour les abonnés roamer, le serveur de facturation accède à la base de données pour obtenir
les détails pertinents sur les services consommés, les tarifs appliqués….

43
[Link] Interaction entre la base de données de facturation et le système de médiation

L’interaction entre la base de données de facturation et le système de médiation est importante

pour le flux des données de facturation et la gestion des informations nécessaire ao processus
de facturation.

La base de données de facturation fournit les données nécessaires au système de médiation pour
effectuer ses tâches. Cela peut inclure les informations sur les appels, les sessions de données,
les tarifs appliqués, les frais de roaming, les détails de la consommation. Le système de média-
tion accède à la base de données de facturation pour récupérer ces données et les utiliser dans
ses opérations.

Une fois que le système de médiation a accédé aux données de la base de données de facturation,
il les transforme et les agrège en fonction des besoins spécifiques du processus de facturation.
Cela peut impliquer la normalisation des données, l’ajout d’informations supplémentaires, la
conversion des donnés, l’ajout des informations supplémentaires et aussi la conversion des for-
mats de données. Le système de médiation utilise ces données transformées pour préparer les
informations de facturation appropriées.

Après avoir transformé les données, le système de médiation transmet les informations de fac-
turation aux composants appropriés du système, tels que le serveur de facturation ou les passe-
relles. Cela permet au système de médiation de fournir les données nécessaires pour la factura-
tion précise des services utilisés par les abonnés itinérants. Les données de facturation trans-
mises peuvent inclure les CDR (Call Detail Records), les données de signalisation, les données
de consommation, les tarifs appliqués : c’est la transmission des données de facturation.

[Link] Interaction entre système de médiation et les passerelles.

L'interaction entre le système de médiation et les passerelles est cruciale dans un système
de facturation en roaming ; par rapport à la collecte des données brutes par le système de mé-
diation, les passerelles jouent un rôle essentiel dans la collecte des données brutes provenant
des équipements de télécommunication. Cela peut inclure les CDR, les données de signalisa-
tion, les données de consommation, etc. Les passerelles transmettent ces données brutes au
système de médiation pour un traitement ultérieur.

Et pour la transformation des données par le système de médiation : Une fois que le système
de médiation reçoit les données brutes des passerelles, il les transforme en un format standardisé

44
et compréhensible pour les opérations de facturation. Cela peut impliquer la normalisation des
données, l'agrégation, la conversion des formats, etc. Le système de médiation effectue ces
transformations afin de préparer les données de facturation appropriées pour le serveur de fac-
turation. Le système de médiation peut enrichir les données collectées à partir des passerelles
en ajoutant des informations supplémentaires nécessaires à la facturation précise. Cela peut
inclure des informations de localisation, des données sur les tarifs appliqués, des informations
sur les partenaires d'itinérance, etc. L'enrichissement des données garantit une facturation plus
complète et précise des services en roaming.

En fait, le système de médiation peut enrichir les données collectées à partir des passerelles
en ajoutant des informations supplémentaires nécessaires à la facturation précise. Cela peut
inclure des informations de localisation, des données sur les tarifs appliqués, des informations
sur les partenaires roaming, etc. L'enrichissement des données garantit une facturation plus
complète et précise des services en roaming.

Une fois que le système de médiation a transformé et enrichi les données de facturation, il
les transmet aux passerelles pour leur acheminement approprié. Les passerelles utilisent ces
données de facturation pour faciliter l'échange d'informations entre les opérateurs de télécom-
munication impliqués dans le roaming. Cela peut inclure la transmission des données de signa-
lisation, des informations de facturation, des mises à jour des sessions de communication, ici
on parle de transmission des données de facturation aux passerelles.

En effet, les interactions entre les composants d'un système de facturation en roaming sont
essentielles pour assurer un processus de facturation précis et efficace. Le serveur de facturation
interagit avec la base de données de facturation pour accéder aux informations nécessaires,
calculer les coûts et générer les factures. Le système de médiation collecte, transforme et enri-
chit les données brutes provenant des passerelles, permettant ainsi la préparation des données
de facturation appropriées. Les passerelles jouent un rôle crucial dans la collecte des données
brutes et dans la transmission des données de facturation pour faciliter l'échange d'informations
entre les opérateurs de télécommunication. L'ensemble de ces interactions garantit la cohérence
et l'intégrité des données de facturation, ainsi qu'une communication fluide entre les différents
composants du système. En combinant ces éléments, un système de facturation en roaming peut
gérer avec précision les services utilisés par les abonnés itinérants et générer des factures con-
formes aux tarifs et aux politiques de facturation établis.

45
2.3 Les systèmes de facturation

Un système de facturation en télécommunication est un logiciel ou un ensemble de logiciels

spécifiquement conçus pour gérer la facturation des services de télécommunication fournis par
un opérateur de télécommunications. Ces services peuvent inclure les appels voix, les messages
texte (SMS), les données mobiles, les services Internet haut débit, la télévision par câble ou par
satellite, etc.

Il existe deux types de facturation qui sont : la facturation en ligne ou online charging et la
facturation hors ligne ou offline charging.

En cas de roaming, les opérateurs utilisent généralement un système de facturation en ligne

(online charging) pour le temps réel ou un système de facturation hors ligne (offline charging)
pour la facturation différée.

2.3.1 La faturation en ligne ou Online Charging Système ou OCS

[Link] Définition
Le système de facturation en ligne (OCS) est conçu pour traiter instantanément les transactions
liées à l'utilisation des services de télécommunication, tels que les appels vocaux, les messages
texte (SMS), les données mobiles et autres services. Lorsque les clients utilisent un service, le
système OCS vérifie en temps réel les informations du compte, applique les tarifs appropriés
en fonction des services utilisés et met à jour le solde du client en conséquence.

[Link] Architecture OCS

- OCS est l'acronyme de Online Charging System (système de facturation en ligne).
- Dans OCS, les événements de facturation sont reçus par la "fonction de facturation en
ligne" (OCF).
- L'OCF décide de l'utilisation des ressources en fonction de la fonction d'évaluation (RF)
et de la fonction de gestion du solde des comptes (ABMF).
- La figure 2 décrit l'architecture de la facturation en ligne.

Dans la figure, CTF signifie Charging Trigger Function (fonction de déclenchement de la fac-
turation), OCF signifie Online Charging Function (fonction de facturation en ligne), ABMF
signifie Account Balance Management Function (fonction de gestion du solde des comptes) et
RF signifie Rating Function (fonction d'évaluation). [14]

46
 Figure 2.07 : Architecture OCS

[Link] Les caractéristiques et fonctionnalités clés d'un système OCS

Grâce au système OCS, les opérateurs de télécommunications peuvent fournir des informations
de facturation en temps réel à leurs clients, améliorer la gestion des coûts et offrir une expé-
rience de service plus transparente et efficace. [14]

Voici le tableau récapitulant les caractéristique et fonctionnalités d’un OCS :

Caractéristiques Fonctionnalités
Temps réel Le système OCS fonctionne en temps réel
pour permettre une facturation instantanée
dès que les services sont utilisés.
Tarification en temps réel Les tarifs d'utilisation des services sont appli-
qués en temps réel en fonction des accords
contractuels et des offres tarifaires de l'opéra-
teur.
Contrôle des coûts Les clients peuvent recevoir des notifications
en temps réel sur leurs dépenses pour mieux
contrôler leur utilisation des services.

47
 Gestion des services complexes Le système OCS peut gérer des services com-
plexes, tels que le regroupement de services,
les offres combinées, les services à la de-
mande
Intégration avec d'autres systèmes Le système OCS s'intègre généralement avec
d'autres systèmes de l'opérateur, tels que les
systèmes de réseau, les systèmes de gestion
des clients (CRM), les systèmes de média-
tion, etc.
Facturation récurrente Le système peut également prendre en charge
des facturations récurrentes pour les services
d'abonnement.

Tableau 2.01: caractéristique et fonctionnalité d’un système OCS

2.3.2 La facturation hors ligne ou Offline Charging System ou OFCS

[Link] Définition
Offline Charging (facturation hors ligne) est un processus de facturation dans les télécommu-
nications où les transactions liées à l'utilisation des services sont collectées et enregistrées pour
être traitées ultérieurement, généralement à des intervalles spécifiques. Contrairement à la fac-
turation en ligne (Online Charging), où les transactions sont traitées en temps réel, la facturation
hors ligne implique un délai entre l'utilisation des services et la génération de la facture finale.
[14]

[Link] Architecture OFCS

- Dans le système OFCS, les événements de facturation sont reçus par la fonction de don-
nées de facturation (CDF).
- La CDF génère des CDR (enregistrements de données de facturation) et les transmet à
la CGF (Charging Gateway Function).
- La CGF sert de passerelle entre le réseau LTE 3GPP et les systèmes liés à la facturation.
Le module CGF transmet les CDR au domaine de la facturation.

La figure 2.08 décrit l'architecture de la facturation hors ligne. Dans la figure, CTF signifie
Charging Trigger Function (fonction de déclenchement de la facturation), CDF signifie
48
 Charging Data Function (fonction de données de facturation), CGF signifie Charging Ga-
teway Function (fonction de passerelle de facturation) et BD signifie Billing Domain (do-
maine de facturation). [13]

Figure 2.08 : Architecture OFCS

Le système de facturation hors ligne est souvent utilisé pour les services d'itinérance prépayés,
où l'opérateur collecte les informations sur l'utilisation du service et applique les tarifs d'itiné-
rance appropriés pour générer une facture globale périodique.

[Link] Les processus de fonctionnement d’un système OFCS

Le système de facturation hors ligne est souvent utilisé pour les services de roaming prépayés,
où l'opérateur collecte les informations sur l'utilisation du service et applique les tarifs de roa-
ming appropriés pour générer une facture globale périodique. [14]

Processus Explication
Collecte des données d'utilisation Les informations relatives à l'utilisation des
services par les abonnés, comme les appels
effectués, les messages envoyés, les données
consommées, etc., sont collectées et stockées
dans des systèmes de médiation. Ces sys-
tèmes agrègent les données provenant des

49
 équipements réseau et des serveurs de l'opé-
rateur
Période de facturation Au lieu de facturer chaque transaction au fur
et à mesure qu'elle se produit, les données
d'utilisation sont collectées et conservées
pour une période de facturation spécifique.
Cette période peut être quotidienne, hebdo-
madaire ou mensuelle, selon les politiques de
l'opérateur.
Traitement des données Une fois que la période de facturation est ter-
minée, les données d'utilisation sont traitées
et analysées pour calculer les coûts associés
aux services consommés par chaque abonné.
Génération des factures Sur la base des données traitées, les factures
sont générées pour chaque abonné. Les fac-
tures détaillent les services utilisés, les quan-
tités consommées, les tarifs appliqués, les
taxes et autres frais éventuels.
Envoi des factures Les factures sont ensuite envoyées aux abon-
nés par voie électronique ou postale, en fonc-
tion des préférences de communication de
l'abonné.
Tableau 2.02 : les processus de fonctionnement OFCS

2.3.3 Le système de facturation utilisé en roaming

En cas de roaming, le système de facturation utilisé dépend généralement de l'accord roaming

entre les opérateurs. [13]

Il existe généralement deux types de systèmes de facturation pour le roaming :

• Facturation par l'opérateur d'origine : Dans ce cas, votre opérateur d'origine (le fournis-
seur de services mobiles auquel vous êtes abonné) est responsable de la facturation.
Lorsque vous utilisez des services en itinérance, votre opérateur d'origine calcule les

50
 frais associés en fonction des tarifs d'itinérance convenus avec l'opérateur du réseau
visité dans le pays étranger. Vous recevrez ensuite une facture de votre opérateur d'ori-
gine, qui comprendra les frais d'itinérance et peut-être des frais supplémentaires pour
l'utilisation de services à l'étranger.
• Facturation par l'opérateur du réseau visité : Dans ce cas, l'opérateur du réseau dans le
pays étranger où vous vous trouvez est responsable de la facturation. Votre opérateur
d'origine n'intervient pas directement dans la facturation, mais il peut tout de même ap-
pliquer des limites de tarification ou des forfaits spécifiques pour le roaming.

CONCLUSION

En conclusion, nous pouvons voir que l'architecture en roaming des réseaux mobiles a considé-
rablement évolué au cours des décennies, passant de la 2G à la 3G et enfin à la 4G. Chaque
génération apporte son lot d'améliorations en termes de vitesse, de capacité et de qualité de
service, offrant aux utilisateurs une expérience de communication plus fluide et plus rapide.
Pour faciliter le processus de facturation dans un environnement de roaming complexe, des
composants tels que les serveurs, les bases de données, les systèmes de médiation et les passe-
relles sont utilisés pour assurer une gestion efficace des données de facturation. Ces éléments
jouent un rôle crucial dans la collecte, le traitement et l'acheminement des informations de fac-
turation entre les opérateurs impliqués dans le roaming.

Cette exploration approfondie de l'architecture du système de facturation en roaming nous a

révélé que les fils invisibles de la technologie tissent une toile de connectivité mondiale dont
nous sommes devenus si dépendants. Chaque appel détaillé, chaque message transmis, chaque
transfert de données contribue à ce réseau complexe qui passe à travers les frontières géogra-
phiques et crée une expérience de communication sans frontières. Alors que nous tournons notre
attention vers l'horizon technologique en constante évolution, rappelons-nous que derrière
chaque moment de connectivité se trouve un écosystème bien orchestré, propulsant notre
monde interconnecté vers de nouveaux sommets.

51
 CHAPITRE III : ANALYSE, CONCEPTION
L'analyse et la conception ne sont pas seulement des termes techniques, mais plutôt des pro-
cessus essentiels qui s'inscrivent dans la base de chaque aspect de la technologie qui nous en-
toure. Dans ce chapitre, nous allons plonger dans le processus par lequel les ingénieurs éva-
luent les besoins, élaborent des plans et construisent des solutions pour répondre aux défis en
constante évolution du monde du roaming. Au-delà des chiffres et des protocoles, nous explo-
rerons comment l'analyse des données collectées ; des CDR et des fichiers TAP permet de dé-
gager des tendances et des modèles. L'analyse, la conception et la réalisation sont des étapes
essentielles dans le processus de développement de nombreux projets, que ce soit dans le do-
maine de l'informatique, de l'ingénierie ou d'autres secteurs. Ces trois étapes interdépendantes
permettent de transformer une idée ou un besoin en un produit ou un système fonctionnel et
efficace.

3.1 Analyse

3.1.1 Méthode et outils pour l’application :

L'analyse est la première étape de ce processus. Elle consiste à étudier et à comprendre en pro-
fondeur les besoins, les contraintes et les objectifs du projet. Cela implique de recueillir des
informations, de mener des enquêtes, d'effectuer des études de marché ou des analyses de don-
nées afin d'identifier les problèmes à résoudre et les fonctionnalités à mettre en place. L'analyse
vise à déterminer les spécifications du projet, à définir les exigences fonctionnelles et non fonc-
tionnelles, ainsi qu'à évaluer les risques potentiels.

Avant de développer tout application il est utile de faire référence à une méthode bien définie,
alors Pour mener bien notre travail, il nous faut d’abord passer par des étapes qui rendent sa
réalisation plus précise et organisée. Pour cela on a opté pour le langage UML.

[Link] Mise en œuvre UML

UML n'est pas une méthode (une description normative des étapes de la modélisation) : ses
auteurs ont en effet estimé qu'il n'était pas opportun de définir une méthode en raison de la
diversité des cas particuliers. Ils ont préféré se borner à définir un langage graphique qui permet
de représenter et de communiquer les divers aspects d'un système d'information. Aux gra-
phiques sont bien sûr associés des textes qui expliquent leur contenu. UML est donc un méta-
langage, car il fournit les éléments permettant de construire le modèle qui, lui, sera le langage

52
du projet. Il est impossible de donner une représentation graphique complète d'un logiciel, ou
de tout autre système complexe, de même qu'il est impossible de représenter entièrement une
statue (à trois dimensions) par des photographies (à deux dimensions). Mais il est possible de
donner sur un tel système des vues partielles, analogues chacune à une photographie d'une sta-
tue, et dont la conjonction donnera une idée utilisable en pratique sans risque d'erreur grave.

UML n'est pas une méthode (une description normative des étapes de la modélisation) :
ses auteurs ont en effet estimé qu'il n'était pas opportun de définir une méthode en raison de la
diversité des cas particuliers. Ils ont préféré se borner à définir un langage graphique qui permet
de représenter et de communiquer les divers aspects d'un système d'information. Aux gra-
phiques sont bien sûr associés des textes qui expliquent leur contenu. UML est donc un méta-
langage, car il fournit les éléments permettant de construire le modèle qui, lui, sera le langage
du projet.

Il est impossible de donner une représentation graphique complète d'un logiciel, ou de

tout autre système complexe, de même qu'il est impossible de représenter entièrement une sta-
tue (à trois dimensions) par des photographies (à deux dimensions). Mais il est possible de
donner sur un tel système des vues partielles, analogues chacune à une photographie d'une sta-
tue, et dont la conjonction donnera une idée utilisable en pratique sans risque d'erreur grave.

Ces diagrammes, d'une utilité variable selon les cas, ne sont pas nécessairement tous pro-
duits à l'occasion d'une modélisation. Les plus utiles pour la maîtrise d'ouvrage sont les dia-
grammes d'activités, de cas d'utilisation, de classes, d'objets, de séquence et d'états-transitions.
Les diagrammes de composants, de déploiement et de communication sont surtout utiles pour
la maîtrise d'œuvre à qui ils permettent de formaliser les contraintes de la réalisation et la solu-
tion technique. [16]

a) Diagramme de cas d’utilisation

Le diagramme de cas d'utilisation représente la structure des grandes fonctionnalités néces-

saires aux utilisateurs du système. C'est le premier diagramme du modèle UML, celui où
s'assure la relation entre l'utilisateur et les objets que le système met en œuvre.

b) Diagramme de classe

Le diagramme de classes est généralement considéré comme le plus important dans un

développement orienté objet. Il représente l'architecture conceptuelle du système : il décrit les

53
classes que le système utilise, ainsi que leurs liens, que ceux-ci représentent un emboîtage
conceptuel (héritage) ou une relation organique (agrégation).

c) Diagramme d’objets

Le diagramme d'objets permet d'éclairer un diagramme de classes en l'illustrant par des

exemples. Il est, par exemple, utilisé pour vérifier l'adéquation d'un diagramme de classes à
différents cas possibles.

• Diagramme d’états-transitions

Le diagramme d'états-transitions représente la façon dont évoluent (i.e. cycle de vie) les
objets appartenant à une même classe. La modélisation du cycle de vie est essentielle pour
représenter et mettre en forme la dynamique du système.

• Diagramme d’activités

Le diagramme d'activités n'est autre que la transcription dans UML de la représentation du

processus telle qu'elle a été élaborée lors du travail qui a préparé la modélisation : il montre
l'enchaînement des activités qui concourent au processus.

• Diagramme de séquence et de communication

Le diagramme de séquence représente la succession chronologique des opérations réalisées

par un acteur. Il indique les objets que l'acteur va manipuler et les opérations qui font passer
d'un objet à l'autre. On peut représenter les mêmes opérations par un diagramme de communi-
cation, graphe dont les nœuds sont des objets et les arcs (numérotés selon la chronologie) les
échanges entre objets. En fait, diagramme de séquence et diagramme de communication sont
deux vues différentes, mais logiquement équivalentes (on peut construire l'une à partir de
l'autre) d'une même chronologie. Ce sont des diagrammes d'interaction.

3.1.2 Présentation d’un modèle UML

La présentation d'un modèle UML se compose de plusieurs documents écrits en langage

courant et d'un document formalisé : elle ne doit pas se limiter au seul document formalisé, car
celui-ci est pratiquement incompréhensible si on le présente seul. Un expert en UML sera ca-
pable dans certains cas de reconstituer les intentions initiales en lisant le modèle, mais pas tou-
jours ; et les experts en UML sont rares. Voici la liste des documents qui paraissent nécessaires :

54
 • Présentation stratégique : elle décrit pourquoi l'entreprise a voulu se doter de l'outil
considéré, les buts qu'elle cherche à atteindre, le calendrier de réalisation prévu, etc.
• Présentation des processus de travail par lesquels la stratégie entend se réaliser :
pour permettre au lecteur de voir comment l'application va fonctionner en pratique, elle
doit être illustrée par une esquisse des écrans qui seront affichés devant les utilisateurs
de terrain.
• Explication des choix qui ont guidé la modélisation formelle : il s'agit de synthétiser,
sous les yeux du lecteur, les discussions qui ont présidé à ces choix.
• Modèle formel : c'est le document le plus épais et le plus difficile à lire. Il est préférable
de le présenter sur l'Intranet de l'entreprise. En effet, les diagrammes peuvent être alors
équipés de liens hypertextes permettant l'ouverture de diagrammes plus détaillés ou de
commentaires.

On doit présenter en premier le diagramme de cas d'utilisation qui montre l'enchaînement

des cas d'utilisation au sein du processus, enchaînement immédiatement compréhensible ; puis
le diagramme d'activités, qui montre le contenu de chaque cas d'utilisation ; puis le diagramme
de séquence, qui montre l'enchaînement chronologique des opérations à l'intérieur de chaque
cas d'utilisation. Enfin, le diagramme de classes, qui est le plus précis conceptuellement, mais
aussi le plus difficile à lire, car il présente chacune des classes et leurs relations (agrégation,
héritage, association, etc.).

• Diagramme de cas d’utilisation

Un diagramme de cas d’utilisation (use case) représente un ensemble de séquences d’ac-

tions qui sont réalisées par le système et qui produisent un résultat observable intéressant
pour un acteur particulier.
Dans le cadre de notre projet nous sommes arrivés aux cas d'utilisations suivants :
a) Pour un utilisateur :
- Etablir le codage des fichiers TAP
- Décoder le fichier TAP pour la vérification
- Générer une facture en fonction des fichiers TAP coder
b) Pour un administrateur :
- Paramétrer le système
c) Pour utilisateur/administrateur :
- S’authentifier
55
Les cas d’utilisation et acteurs recensé ci-dessus nous permettrons de construire les diagrammes
de cas d’utilisations qui montre les interactions fonctionnelles entre les acteurs et le système à
l’étude comme suit.

Figure 3.01: Diagramme de cas d’utilisation global

56
• Diagramme de classe

1
1
0.1

1
1

Figure 3.02: Diagramme de classe

57
3.2 L'algorithme de ASN.1 (Abstract Syntax Notation One)

3.2.1 Système d’encodage

ASN.1 est un standard international spécifiant une notation destinée à décrire des structures de
données dans le secteur des télécommunications et des réseaux informatiques. La description
en ASN.1 d'une structure de données a pour but d'obtenir une spécification de la structure qui
est indépendante d'un encodage lié à un matériel particulier et sans ambiguïté.

Il existe plusieurs règles d'encodage standards pour les données décrites par l'ASN.1. Le stan-
dard propose les règles suivantes : [17]

• Basic Encoding Rules (BER)

• Distinguished Encoding Rules (DER) 4 Canonical Encoding Rules (en) (CER)
• Packed Encoding Rules (PER, unaligned: UPER, canonical: CPER, canonical una-
ligned: CUPER)
• Encoding Control Notation (en) (ECN)
• XML Encoding Rules (en) (XER)
• Canonical XML Encoding Rules (CXER)
• Extended XML Encoding Rules (E-XER)
• Octet Encoding Rules (OER, canonical: COER)
• JSON Encoding Rules (JER)
• Generic String Encoding Rules (GSER)

3.2.2 Basic Encoding Rules ou BER

Le codage Basic Encoding Rules (règles d'encodage basique), dont l'acronyme est BER, est un
des formats d'encodage définis par le standard ASN.1.

[Link] Description

Le BER fait partie des premières règles édictées par le standard ASN.1 pour l'encodage d'infor-
mations abstraites dans un flux de données. Les règles, connues dans le ASN.1 comme la syn-
taxe de transfert, donnent les séquences exactes d'octets qui sont utilisées pour encoder une
donnée. Cette syntaxe définit les éléments suivants : la représentation des types de données de

58
base, la façon de construire des éléments complexes ou composés à partir d'éléments plus ba-
siques. La syntaxe du codage BER, ainsi que ses sous-ensembles Canonical Encoding Rules
(CER) et Distinguished Encoding Rules (DER) sont définis dans les standards X.690 (en) de
l'ITU-T, qui sont eux-mêmes une partie de la série de documents de l'ASN.1. [17]

Le format BER donne un format pour encoder les structures de données ASN.1, qui se décrit et
se délimite lui-même. Chaque élément est encodé avec un type, une longueur, les valeurs et si
nécessaire un marqueur de fin. Ce type d'encodage est couramment surnommé type-length-
value (type-longueur-valeur) ou simplement encodage TLV. Ce format permet au récepteur du
message de décoder des données au format ASN.1 même si le flux est incomplet et sans avoir
de connaissances a priori de la taille, du contenu et de la sémantique des données.

3.2.3 Relation entre BER et python

• Compréhension de l'encodage BER :

L'encodage BER définit des règles pour représenter les données sous forme binaire, permettant
ainsi la transmission des informations entre différents équipements réseau.

Et aussi il utilise des structures de données définies par ASN.1, telles que des séquences, des
ensembles et des types primitifs, pour représenter les informations à transmettre.

• Choix de Python pour l'implémentation :

Python est un langage de programmation qui permet de mettre en œuvre l'encodage et le déco-
dage BER. Python offre une grande souplesse et de nombreuses bibliothèques qui facilitent la
manipulation des données et des opérations de codage/décodage.

• Utilisation de la bibliothèque pyasn1 :

La bibliothèque Python "pyasn1" fournit des fonctionnalités pour travailler avec ASN.1 et l'en-
codage BER. Cette bibliothèque permet de représenter les données ASN.1 et d'appliquer les
règles de l'encodage BER de manière pratique et efficace.

• Encodage des données :

59
Pour encoder les données selon les règles de l'encodage BER, on utilise les structures de don-
nées définies par ASN.1 pour représenter les informations à transmettre et aussi les fonctions
fournies par la bibliothèque "pyasn1" pour encoder ces structures de données conformément
aux règles de l'encodage BER. Python facilite cette étape en offrant une syntaxe claire et concise
pour manipuler les données et appliquer les opérations d'encodage nécessaires.

• Décodage des données :

Lors de la réception des données encodées en BER, on utilise Python et la bibliothèque

"pyasn1" pour décoder ces données. On applique les règles de décodage BER pour extraire les
informations structurées des données binaires. En utilisant les structures de données définies
par ASN.1, on peut accéder aux différentes parties des données et les traiter en conséquence.

3.3 Les outils de développement utilisé

La réussite de mon projet de mémoire dépendait du choix des bons outils pour l'encodage et le
décodage du fichier TAP ainsi que la facturation de ce dernier. Cette partie met en évidence les
critères qui ont influencé ma décision de sélectionner les différents outils que j’ai utilisés.

3.3.1 WINDOWS

L'utilisation du système d'exploitation Windows pour concevoir un outil d’encodage et de dé-

codage de fichier TAP ainsi que la facturation en télécommunication a été motivée par plusieurs
facteurs :

• Utilisation répandue dans les entreprises de télécommunication :

De nombreuses entreprises de télécommunication utilisent des infrastructures basées sur des

systèmes d'exploitation Windows. En développant un logiciel de facturation compatible avec
Windows, vous facilitez l'intégration de votre solution dans l'écosystème existant de ces entre-
prises, ce qui peut accélérer l'adoption et la mise en œuvre de votre logiciel.

• Compatibilité avec les systèmes de gestion existants :

60
Les entreprises de télécommunication utilisent souvent des systèmes de gestion des opérations
et des systèmes de support aux opérations (OSS operations support systems /BSS business sup-
port systems) basés sur Windows. En développant un logiciel de facturation compatible avec
Windows, vous facilitez l'intégration de votre solution avec ces systèmes existants, permettant
une synchronisation efficace des données et une gestion simplifiée des processus de facturation.

• Prise en charge des normes de télécommunication :

Windows propose une large gamme d'outils de développement et de bibliothèques logicielles

qui facilitent la mise en œuvre des protocoles et des normes de télécommunication couramment
utilisés. Cela peut simplifier le développement du logiciel de facturation, notamment en ce qui
concerne l'interopérabilité avec d'autres systèmes de télécommunication.

• Facilité de développement et d'intégration :

Windows offre un large éventail d'outils de développement, d'environnements de développe-

ment intégrés (IDE) et de bibliothèques logicielles qui peuvent accélérer le processus de déve-
loppement du logiciel de facturation en télécommunication. Des langages de programmation
tels que C#, [Link] et Python, ainsi que des IDE tels que Visual Studio, offrent des fonction-
nalités puissantes pour créer des applications robustes et adaptées aux besoins spécifiques de la
facturation en télécommunication.

• Compatibilité matérielle :

Windows est compatible avec une variété de matériels utilisés dans l'industrie des télécommu-
nications, tels que les serveurs, les commutateurs, les routeurs, les systèmes de stockage, etc.
L'utilisation de Windows pour le développement du logiciel de facturation garantit une compa-
tibilité étendue avec ces infrastructures matérielles, facilitant ainsi l'intégration et l'utilisation
du logiciel dans l'environnement télécom existant.

3.3.2 Python

Python est un langage de programmation polyvalent et largement utilisé qui offre de nom-
breux avantages pour les projets de développement. La syntaxe de python et claire, lisible et

61
aussi facile à comprendre. Son code est souvent décrit comme étant proche du langage natu-
rel, ce qui facilite la collaboration entre les développeurs et la maintenance du code.

C’est un langage qui dispose d'une vaste bibliothèque standard qui offre des fonctionnalités
prêtes à l'emploi pour de nombreux domaines, tels que le traitement de fichiers, les opérations
réseau, la manipulation de données, la génération de graphiques, etc. Cela permet aux déve-
loppeurs de gagner du temps en utilisant des modules existants plutôt que de devoir tout coder
à partir de zéro.

En plus de sa bibliothèque standard, Python bénéficie d'un vaste écosystème de packages

tiers. Des milliers de packages open source sont disponibles via le gestionnaire de packages
Python, pip, ce qui permet d'ajouter facilement de nouvelles fonctionnalités à un projet sans
avoir à les développer entièrement.

Python est un langage multiplateforme, ce qui signifie qu'il fonctionne sur divers systèmes
d'exploitation tels que Windows, macOS et Linux. Cela facilite le déploiement d'un projet sur
différentes plates-formes sans avoir à effectuer de modifications majeures.

Python est utilisé dans une grande variété de domaines, tels que le développement web, l'ap-
prentissage automatique (machine learning), l'analyse de données, l'automatisation des tâches,
la science des données, la bio-informatique, la robotique, etc. Il existe de nombreuses biblio-
thèques spécialisées qui facilitent l'utilisation de Python dans ces domaines spécifiques.

Dans notre cas, nous avons choisis ce langage pour ces raisons mais surtout pour sa compati-
bilité avec l’encodage ASN1 qui nous permet d’encoder et de décoder le fichier TAP, ainsi
que la génération de la facture.

Figure 3.03 : Python

62
3.3.3 Mysql / workbench

Dans le projet nous avons utilisé MySQL/ workbench 8.0 ; MySQL Workbench version 8.0 est
un système de gestion de base de données relationnelle (SGBDR). MySQL Workbench est un
outil de conception, de développement et d'administration de bases de données MySQL. Il offre
une interface graphique conviviale qui permet aux utilisateurs de créer, de modifier et de gérer
des bases de données relationnelles à l'aide du langage SQL

Ses principales caractéristiques sont les suivantes :

- Interface graphique conviviale : MySQL Workbench propose une interface utilisateur

graphique intuitive et conviviale, ce qui facilite la création, la gestion et la modification
des bases de données.
- Modélisation de bases de données : Vous pouvez utiliser MySQL Workbench pour con-
cevoir et modéliser des schémas de bases de données à l'aide d'outils de modélisation
entité-association. Cela permet de visualiser la structure de la base de données avant de
l'implémenter.
- Éditeur SQL : MySQL Workbench comprend un éditeur SQL puissant qui prend en
charge la coloration syntaxique, l'autocomplétion et la suggestion de code. Cela facilite
l'écriture, la modification et l'exécution de requêtes SQL.
- Migration de données : MySQL Workbench permet de migrer facilement des bases de
données à partir d'autres systèmes de gestion de bases de données vers MySQL. Il prend
en charge la migration à partir de sources telles que Microsoft SQL Server, PostgreSQL,
SQLite, et bien d'autres.

Figure 3.04 : MySQL Workbench

63
3.3.4 L'environnement de développement intégré VSCode

Visual Studio Code est présenté lors de la conférence des développeurs Build d'avril 2015
comme un éditeur de code multiplateforme, open source et gratuit, supportant une dizaine de
langages.

Visual Studio Code est un éditeur de code extensible développé par Microsoft pour Windows,
Linux et MacOs.

Etant un éditeur de code source qui peut être utilisé avec une variété de langages de program-
mation, notamment comme Python, Java, JavaScript, Go, [Link] et C++, le logiciel prend en
charge le Windows Subsystem for Linux et, permet ainsi par exemple, de programmer facile-
ment en python depuis un ordinateur Windows 10.

Figure 3.05 : Visual studio code

CONCLUSION

En conclusion, le chapitre 3 nous a offert un aperçu précieux des méthodes d'analyse et du

déroulement de la conception à l'aide des diagrammes UML et aussi nous avons pu avoir une
brève idée sur ce qu’on entend par encodage d’un fichier pour en donner un autre fichier. Le
choix des outils utilisées a été un élément majeur dans la réalisation de ce mémoire. Ces con-
naissances constituent un atout majeur pour le développement de systèmes logiciels efficaces,
robustes et en phase avec les attentes des utilisateurs et des clients. L'analyse, la conception et
la réalisation ne sont pas de simples étapes linéaires, mais plutôt une danse complexe de créa-
tivité, de réflexion critique et d'application pratique. Ces trois piliers fondamentaux convergent
pour transformer une simple idée en une réalité fonctionnelle. Lorsque nous arpentons la base
de l'élaboration du logiciel, nous réalisons que chaque diagramme UML, et chaque élément de
conception est une brique essentielle de la construction d’une technologie solide.

64
 CHAPITRE IV : REALISATION

Après avoir décrit notre système d’un point de vue conceptuel dans les chapitres précédents,
nous allons passer maintenant à l’état de la réalisation de notre système. Ce chapitre sera dédié
principalement à la présentation du prototype réalisé ainsi que les moyens techniques (langages,
environnements de développement), qui nous ont permis de réaliser ce travail.

4.1 L’objectif du projet

Dans le cadre de ma mémoire, j'ai entrepris la réalisation d'un projet qui se concentre sur le
codage et le décodage d'un fichier CDR en un format TAP. L'objectif principal de cette étude
était de développer une méthode efficace permettant la conversion des données contenues dans
les enregistrements CDR vers un format compréhensible et utilisable par les systèmes de fac-
turation. Le processus de codage consistait à structurer et organiser les informations essentielles
du CDR, tandis que le décodage visait à extraire ces données et les restituer dans le format TAP
standard. Par la suite, la facturation de ces fichiers TAP était réalisée afin de permettre une
gestion précise et efficace des transactions. Cette approche a permis d'améliorer la cohérence
et la fiabilité du processus de facturation, en simplifiant les opérations de traitement des données
et en réduisant les erreurs potentielles. Cette section du rapport met en évidence les objectifs
spécifiques de ma mémoire, en démontrant l'importance et la pertinence du développement de
cette solution de codage/décodage et de facturation pour les systèmes de télécommunication.

4.1.1 Les éléments clés du CDR utiliser dans la réalisation du projet.

Lors de la réalisation de mon projet de mémoire, j'ai exploré en détail les éléments clés du
contenu des enregistrements CDR qui ont été essentiels pour le processus de codage et de dé-
codage. Ces éléments comprennent l'IMSI, le ANUMBER et le BNUMBER, le type de service
ou service code, ainsi que la date, l'heure et le volume du data pour le GPRS.

- L'IMSI (International Mobile Subscriber Identity) est un identifiant unique associé à

chaque abonné d'un réseau de téléphonie mobile. Il permet d'identifier de manière pré-
cise l'utilisateur dans le système.
- Le ANUMBER représente le numéro de téléphone de l'appelant, tandis que le BNUM-
BER correspond au numéro de téléphone du destinataire de l'appel.

65
 - Le type de service ou service code indique le type d'appel ou de service utilisé lors d'une
communication. Il peut s'agir, par exemple, d'appels vocaux, de messages SMS, de
transferts de données ou d'autres services spécifiques offerts par le réseau.
- La date et l'heure sont des informations essentielles enregistrées lors de chaque commu-
nication. Elles permettent de suivre chronologiquement les appels et les événements
liés.
- Enfin, le volume du data pour le GPRS représente la quantité de données échangées lors
des sessions de transmission de données via le réseau GPRS ou données mobile. Il peut
être mesuré en octets, kilo-octets, méga-octets, etc., et est utilisé pour évaluer l'utilisa-
tion des données et la facturation associée.

4.2 Le système existant

4.2.1 Le point fort de l’application

Le point fort de ce projet réside dans le développement d'un logiciel novateur qui combine les
fonctionnalités clés du système de médiation et du système de facturation au sein d'une seule
plateforme intégrée. Cette approche fusionne les deux processus essentiels de collecte, de trans-
formation des données et de génération des factures au sein d'un même système, offrant ainsi
de nombreux avantages opérationnels et stratégiques à une entreprise de télécommunications.

En combinant la médiation et la facturation, notre logiciel élimine la nécessité de maintenir et

de synchroniser plusieurs systèmes distincts, réduisant ainsi la complexité et les coûts associés
à leur intégration. En unifiant ces deux tâches critiques, notre solution offre une efficacité ac-
crue, une meilleure gestion des données et une réduction des risques d'erreurs ou d'incohérences
entre les systèmes.

Grâce à notre logiciel, les données collectées par le système de médiation sont automatiquement
transférées et traitées par le module de facturation. Cela permet une génération rapide et précise
des factures, en tenant compte des tarifs, des politiques tarifaires et des règles spécifiques à
l'entreprise. Les processus de médiation et de facturation sont étroitement intégrés, garantissant
ainsi une traçabilité complète des données depuis leur origine jusqu'à la facturation finale.

En fournissant une solution tout-en-un pour la médiation et la facturation, notre logiciel simpli-
fie les opérations quotidiennes de l'entreprise, améliore l'efficacité des processus et facilite la

66
prise de décision. De plus, il permet une gestion plus agile et réactive des services de télécom-
munications, offrant ainsi un avantage concurrentiel indéniable sur le marché.

Notre projet représente une avancée significative dans l'optimisation des opérations de média-
tion et de facturation pour les entreprises de télécommunications, offrant une solution intégrée
qui répond aux besoins spécifiques de l'industrie. En combinant ces deux domaines clés, notre
logiciel ouvre de nouvelles perspectives pour une gestion plus efficace et rentable des services
de télécommunications.

4.2.2 Spécifications des acteurs

Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel
ou autre système) qui interagit avec un système.

Les acteurs humains identifiés pour notre application sont les suivants :

• L'utilisateur : il s’agit de toute personne s’étant identifié/authentifié sur l'application. Il

aura donc en sa possession un login et un mot de passe. Il s’agit de l’acteur principal qui
dispose des fonctionnalités auquel on lui a donné l'accès dans le cadre de son travail.
• L’administrateur : il s’agit de la personne chargée d’administrer l'application dont les
fonctionnalités sont restreintes à la gestion des comptes utilisateur (login, mot de passe)
et au paramétrage du système selon le besoin métier.
4.3 Description du logiciel

4.3.1 L’interface graphique

[Link] Présentation
Cette application est un outil d'interface utilisateur graphique (GUI) permettant de visualiser
des données encodées et décodées à l'aide de la règle d'encodage ASN.1 : BER. Il permet d'at-
tribuer un schéma ASN.1 à des données binaires afin de produire plusieurs vues des données
montrant tous les noms de types et d'éléments attribués.

C’est aussi un outil conçu pour pouvoir directement facturer les fichiers TAP générée par opé-
rateurs, cet outil permettra directement à l’opérateur de combiné la médiation et la facturation.

Avant d’accéder dans le contenu principal du logiciel nous avons l’interface d’authentification
(mot de passe et login) pour la sécurisation du logiciel pour pouvoir continuer sur la suite de
la navigation sur l’application.
67
 Figure 4.01 : Interface d’authentification

4.3.2 Description des fonctionnalités

[Link] L’encodage du fichier TAP

Dans ce système, l’encodage se fait en une seule clique. Les CDRs étant déjà regrouper dans la
base de données par chaque nom de partenaire (opérateur) ; trois CDRs seront directement co-
der pour donner un fichier TAP, qui seront ensuite mis dans une facture pour être enfin envoyer
par l’opérateur visité pour l’opérateur d’origine du roamer.

Figure 4.02 : Fenêtre d’encodage d’un fichier TAP

68
Le système sera directement lié à un dossier pour stocker les fichiers encoder pour avoir une
traçabilité permanant des mouvements effectuer dans le réseau.

[Link] Décodage d’un fichier TAP

Le décodage comme son nom l’indique est la lecture du fichier encodé précédemment pour
pouvoir lire ces contenus et vérifier la consommation d’un roamer au cours de son intégration
dans un autre réseau.

L’interface de décodage contient plus d’information que celle de l’encodage, car cette interface
est chargée par la structure TAP3 du fichier TAP qui respectera la structure mis en place pour
les fichiers TAP3.

Figure 4.03 : interface de décodage d’un fichier TAP

69
[Link] La facturation
En roaming le système de facturation est généralement une facturation hors ligne et qui se fait
périodique, dans notre cas, nous avons intégré le système dans un seul logiciel qui permet de
tarifier les services effectuer ainsi que de générer directement une facture.

Cette interface permet de réaliser la facturation des CDRs codé précédemment, dans cette partie
on pourra sélectionner la partenaire(opérateurs), le mois ainsi que l’année sur laquelle on veut
effectuer l’opération de facturation.

Les contenus de la facture :

- Logo de l’opérateur domestique

- Le numéro de facture
- La spécification du type de facture : roaming traffic
- Le nom de l’opérateur domestique et l’opérateur visité
- Les noms des fichiers TAP à facturer
- Montant de l’utilisation par fichier TAP

Figure 4.04 : interface de facturation

4.3.3 Les éléments visible dans le logiciel

Les différents types de message qui peuvent être visualisés sur l’application :

70
Figure 4.05 : Fichiers batch de la procédure de compte transféré (TAP3)

71
 CONCLUSION

En achevant cette partie de notre ouvrage, consacrée à l'objectif de la réalisation de la mémoire

et à la présentation des interfaces de codage des CDRs, au décodage des fichiers TAP et à la
facturation de ces fichiers, nous avons accompli un voyage au cœur de l'univers complexe des
télécommunications. Cette quête ambitieuse visait à perfectionner et optimiser les processus
cruciaux pour les opérateurs, tout en assurant une gestion transparente des données de commu-
nication.

72
 CONCLUSION GENERALE

En parvenant à la conclusion générale de cet ouvrage, nous sommes à présent en mesure de

contempler l'ensemble du voyage que nous avons entrepris dans le fascinant domaine du roa-
ming, des CDRs, des fichiers TAP et de la réalisation des interfaces associées. Les différents
chapitres ont tracé une trajectoire cohérente, nous permettant d'explorer en profondeur les con-
cepts fondamentaux, les architectures des générations de téléphonie en roaming, les infrastruc-
tures techniques, les analyses et conceptions de mémoire, ainsi que la concrétisation de nos
objectifs dans la réalisation des interfaces.

Dans le premier chapitre, nous avons jeté les bases en nous familiarisant avec le concept général
du roaming, comprenant son importance et son rôle essentiel dans les communications interna-
tionales. Nous avons également exploré en détail les CDRs et les fichiers TAP, ces éléments
essentiels qui encapsulent les informations cruciales des communications, et qui nous ont servi
de matière première pour notre travail.

Pour le deuxième chapitre nous a emmenés dans un voyage à travers les générations de télé-
phonie en roaming, nous permettant de comprendre l'évolution technologique et les infrastruc-
tures techniques qui ont rendu tout cela possible. Cette exploration nous a offert une vision
globale de l'évolution constante du roaming et des enjeux liés à la gestion de ces communica-
tions mobiles mondiales.

Dans le troisième chapitre, nous avons plongé dans l'analyse et la conception de la mémoire, en
identifiant les besoins spécifiques et les défis techniques pour créer des interfaces efficaces et
performantes. Cette phase d'analyse minutieuse a jeté les bases solides de notre travail, en nous
permettant de développer des solutions qui répondent aux exigences des utilisateurs et des opé-
rations de roaming.

Enfin, le dernier chapitre a été le point culminant de notre aventure, où nous avons présenté
fièrement l'objectif de notre réalisation et dévoilé les contenus et interfaces élaborées pour notre
application. Ces réalisations concrètes sont le fruit de notre persévérance, de notre créativité et
de notre dévouement pour offrir une expérience de roaming sans précédent.

En conclusion, cet ouvrage représente une exploration complète et méthodique du monde com-
plexe du roaming, des CDRs, des fichiers TAP et des interfaces associées. Au fil des chapitres,
73
nous avons embrassé la richesse de connaissances et d'expertise dans le domaine des télécom-
munications, tout en insufflant notre créativité et notre détermination pour apporter des solu-
tions innovantes.

Ce voyage intellectuel a été plein de défis et d'opportunités, mais chaque étape nous a rappro-
chés de l'objectif final : offrir des interfaces de qualité, améliorer les expériences utilisateurs et
contribuer à l'évolution constante du roaming et des télécommunications.

Au-delà de cet ouvrage, notre parcours dans ce domaine prometteur ne fait que commencer.
Les avancées technologiques continuent d'émerger, les infrastructures évoluent, et les attentes
des utilisateurs évoluent avec elles. Ainsi, nous sommes encouragés à poursuivre notre quête
pour l'excellence, à rester à l'avant-garde des connaissances et à repousser les limites de l'inno-
vation dans ce domaine en constante mutation.

En nous tournant vers l'avenir, nous sommes animés par la conviction que notre contribution
aura un impact significatif sur l'industrie des télécommunications, en rendant les communica-
tions mondiales plus fluides, plus transparentes et plus efficaces pour tous. Et c'est avec enthou-
siasme que nous embrassons les défis futurs, confiants dans notre capacité à façonner un avenir
meilleur grâce à notre travail et à notre passion pour ce domaine dynamique du roaming et des
technologies de la communication.

74
 ANNEXES

ANNEXE I : ARCHITECTURE CLIENT SERVEUR

A1.1 Présentation du concept client /serveur

Dans un monde ou la course à la productivité conduit les technologies à évoluer de plus en plus
vite, le client-serveur s’est taillé une part de choix depuis le début des années 1990. En effet, il
faut pouvoir disposer de systèmes d’information évolutifs permettant une coopération fruc-
tueuse entre les différentes entités de l’entreprise. Les systèmes des années 70 et 80 ne répon-
daient pas à ces exigences.
A1.1.1 Définition

L’architecture client-serveur (C/S) est un modèle de fonctionnement logiciel qui peut se réaliser
sur tout type d’architecture matérielle (petite ou grosse machine), à partir du moment où ces
architectures peuvent être interconnectés (s’articule en général autour d’un réseau).
On parle de fonctionnement logiciel dans la mesure ou cette architecture est basée sur l’utilisa-
tion de deux types de logiciels, à savoir un logiciel serveur et un logiciel client s’exécutent
normalement sur deux machines différentes. L’élément important dans cette architecture est
l’utilisation de mécanismes de communication entre ces deux applications.
Une autre définition plus large peut être proposée : ” Modèle d’architecture applicative ou les
programmes sont répartis entre les deux processus clients et serveurs communiquant par des
requêtes et des réponses”.

Figure A1. 01 : Modèle client/serveur

75
A1.1.2 Les différents modèles de C/S

Le type du modèle client/serveur dépend essentiellement des services assurés par le serveur
ainsi on peut distinguer.
➢ C/S de présentation :

Le principe de ce modèle de C/S est que la représentation de l'interface graphique est prise en
charge intégralement par le serveur.
Ce type d'application présentait jusqu'à présent l'inconvénient de générer un fort trafic réseau
et de ne permettre aucune répartition de la charge entre client et serveur.
➢ C/S de traitement :
Ce type est fondé sur la base de la répartition des traitements entre le serveur et le client.
Dans ce cas, le module client envoie des requêtes mais aussi des appels de procédures au mo-
dule serveur qui les exécute et envoie le résultat.
Sur le serveur, les traitements (procédure) n’est pas obligatoirement associé la partie donnée.
➢ C/S de données :
Repose sur le principe que le serveur abrite la gestion des données (c'est à dire que le serveur
gère les données, leur intégrité, la sécurité...etc) et il envoit seulement les données correspon-
dantes à la requête émise par le client qui abrite de son côté la partie traitement et présentation
qui traite ces données.
C’est sans doute le plus connu et le plus répondu des modèles client-serveur, qui est utilisé par
tous les grands SGBD.
A1.1.3 Les architectures client serveur
a- Architecture 2-tiers
Pour résoudre les limitations survenues dans les architectures 1 tiers centralisé et repartie tout
en conservant leurs avantages, on a scindé les applications en deux parties distinctes et coopé-
rantes qui donnent naissances aux architectures 2 -tiers appelées aussi client-serveur de pre-
mière génération ou C/S de données.
Dans l’architecture 2-tiers, la gestion des données est prise en charge par un SGBD centralisé,
s’exécutant le plus souvent sur un serveur dédié alors que la logique applicative est soit entiè-
rement coté client intégrée avec la présentation, soit entièrement coté serveur (la partie client
ne gère que l'interface utilisateur), soit découpée entre la partie serveur et la partie client. Le
dialogue entre le client et le serveur se résume à l’envoi des requêtes et au retour des réponses.

76
 Figure A1.02 : Architecture client/serveur à 2 niveaux

Figure A1. 03 : Modèle de Gartner pour les systèmes à 2 niveaux (2-tiers)

• Avantages
Ce type d'architecture offre :
3 Une interface utilisateur riche
4 Des données centralisées
5 L’efficacité pour un nombre réduit de client
• Limites
On peut déceler un grand nombre d'inconvénients dans cette architecture, qui proviennent pour
la plupart du type de client utilisé :
77
➢ Le problème du client dit obèse (lourd). En effet, on ne peut pas soulager la charge du
poste client, qui supporte la grande majorité des traitements applicatifs.
➢ Une autre limitation est que chaque intervention engendre un coût important, en parti-
culier pour la mise à jour des applications clientes.
➢ De même, la relation étroite, qui existe entre le programme client et l'organisation de la
partie serveur, complique les évolutions de ce dernier.
➢ Enfin, la conversation entre le client et le serveur est assez bruyante et s'adapte mal a
des bandes passantes étroites, la croissance du nombre du client est limité, car la perfor-
mance se dégrade et la base de données est en surcharge.
➢ Dans le but de passé au-dessus des faiblesses engendrées par le client-serveur 2-tiers
tout en conservant ces avantages, on a cherché une architecture plus évoluée qui facilite
les forts déploiements à moindre coût, la réponse est apportée par les architectures 3-
tiers.
b- Architecture 3-tiers
Dans l’architecture trois tiers, appelée aussi C/S de deuxième génération ou architecture à
3 niveaux contrairement au C/S 2-tiers, un niveau supplémentaire est ajouté entre les deux
niveaux précédents, permettant de séparer les traitements de l’interface graphique et du ser-
veur de base de données.
Il s'agit d'un modèle logique d'architecture applicative qui vise à modéliser une application
comme un empilement de trois couches logicielles (étages, niveaux, tiers) dont le rôle est
clairement défini :
• La présentation : des données correspondant à l'affichage, la restitution sur le poste de
travail, le dialogue avec l'utilisateur.
• Le traitement métier des données : correspondant à la mise en œuvre de l'ensemble des
règles de gestion et de la logique applicative.
• L’accès aux données persistantes : correspondant aux données qui sont destinées à être
conservées sur la durée, voire de manière définitive.

78
 Figure A1. 04 : Architecture client/serveur à 3 niveaux

Figure A1. 05 : Modèle de Gartner pour les systèmes à 3 niveaux (3-tiers)

• Avantages
Étant donné que l'architecture 3-tiers se base sur la dépendance de ces niveaux applicatifs
implantés sur des machines différentes, de ce fait :
- Le poste client ne supporte plus l'ensemble des traitements, il est moins sollicité et peut
être moins évolué, donc moins coûteux.

79
 - Les ressources présentes sur le réseau sont mieux exploitées, puisque les traitements
applicatifs peuvent être partagés ou regroupés (le serveur d'application peut s'exécuter
sur la même machine que le SGBD).
- La fiabilité et les performances de certains traitements se trouvent améliorés par leurs
centralisations.
- Il est relativement simple de faire face à une forte montée en charge, en renforçant le
service applicatif.
• Limites
Le serveur d’application constitue la pierre angulaire de l'architecture et se trouve souvent for-
tement sollicité et il est difficile de répartir la charge entre le client et le serveur.
On se retrouve confronté aux épineux problèmes de dimensionnement serveur et de gestion de
la montée en charge rappelant l'époque des mainframes.
De plus, les solutions mises en œuvre sont relativement complexes à maintenir et la gestion des
sessions est compliquée.
Les contraintes semblent inversées par rapport à celles rencontrées avec les architectures 2-tiers
: le client est soulagé, mais le serveur est fortement sollicité.
Critère 2-tiers 3-tiers
Administration du système Complexe (la couche appli- Moins complexe (les appli-
cation est physiquement ré- cations peuvent être gérées
partie sur plusieurs postes centralement sur le serveur)
clients)
Sécurité Faible (sécurité au niveau Élevée (raffinée au niveau
des des services ou des mé-
Données) thodes)
Encapsulation des données Faible (les tables de données Élevée (le client fait appel à
sont directement accessibles) des services ou méthodes)
Performance Faible (plusieurs requêtes Bonne (seulement les appels
SQL sont transmises sur le de services et les réponses
réseau, les données sélec- sont mis sur le réseau)
tionnées doivent être ache-
minées vers le client pour
analyse)
Extensibilité Faible (gestion limitée des Excellente (possibilité de ré-
liens réseaux avec le client) partir dynamiquement la
charge sur plusieurs ser-
veurs)
Réutilisation Faible (application monoli- Excellente (réutilisation des
thique sur le client) services et des objets)
Facilité de développement Élevée En progression (des outils
intégrés pour développer la
80
 partie du client et du ser-
veur)
Lien serveur-serveur Non Oui (via la médiation ser-
veur/serveur
Intégration des systèmes déjà Non Oui (via des passerelles en-
capsulées par les services ou
en place
objets)
Soutien internet Faible (les limitations de la Excellente (les applications
bande passante pénalisent le de type "thinclient" sont fa-
téléchargement d'application cilement téléchargeable et
de type (fat-client Les appels aux services re-
partissent la charge sur un
ou plusieurs serveurs)
Sources de données hétéro- Non Oui (les applications 3-tiers
peuvent utiliser plusieurs
gènes
bases de données dans la
même transaction)
Choix de communications Non (synchrone et RPC) Oui (gestion asynchrone des
de type "riche" messages, files de livraison,
publication et abonnement
"broadcast"
Flexibilité d'architecture ma- Limitée Excellente (possibilité de
térielle faire résider les couches 2 et
3 sur une ou plusieurs ma-
chines

Tableau A1. 01 : Comparaison du C/S 2-tiers et C/S 3-tiers

81
 ANNEXE II : Présentation de AA14
C’est un document qui décrit les différents tarifs appliqués par l’opérateur et cela en répartissant
les pays du monde entre différentes zones.
• L’implémentation

Consiste à déclarer les puces de test (varie entre 2 et 10 puces) dans le MSC à l’aide des com-
mandes propre au système (Ericsson).
- La première étape
On a les IMSIs des puces de test envoyées par l’opérateur étranger.
On doit les faire configurer dans les deux MSCs avec les commandes citées ci-dessous :

82
Quand on veut introduire de nouvelles données dans le MSC, on doit utiliser les deux zones, la
zone opérationnelle OP (Operating area) qui est une zone où le trafic s’écoule en temps réel,
tandis que la zone non-opérationnelle NOP (Not Operating area) est destіnée à l’insertion ces
nouvelles données dans l’OP avec l’enchainement des commandes suivantes :
• MGISP : (Mobile telephony, IMSI number series analysis, specіfіcatіon, prіnt) im-
sis=64304 : voir et vérifier que la série de chiffres 64304 constituant l’imsi n’a pas déjà
été définie.
• MGIZI ; (Mobile telephony, IMSI number series analysis, zeroig, initiate) : c’est une
commande utilisée pour effacer la NOP.
• MGICI ; (Mobile telephony, IMSI number series analysis, copy, initiate) : elle sert à
faire une copie de l’OP dans la NOP.
• MGISI ;(mobile telephonie ,ΙMSΙ number series analyses,specification,initiate) elle est
utilisée pour insérer les données dans la NOP, cette commande contient plusieurs para-
mètres :
83
 - imsi de la puce de test.
• MGISP : imsis=64304, nop; cette commande est utilisée pour printer, afficher toutes les
données relatives aux imsis qu’on a défini par la commande MGISI dans la NOP, qui
commencent par 64304 (appelé IMSI range).
• MGIAI : elle va permuter l’OP et la NOP.
• MGISP : imsis=64304 ; c’est pour printer l’OP ayant l’IMSI range qui vaut 64304.

- La deuxième étape
Pour l’établissement d’un appel, le MSC doit consulter la table d’analyse B-number, elle
contient tous les plans de numérotage qui peuvent être composés depuis un mobile. Parmi ces
tables d’analyse, on a la table 30. Tous les appels en provenance des abonnés passent par cette
dernière, elle analyse les numéros pour les acheminés vers d’autres tables. A titre d’exemple,
si un abonné compose un numéro qui commence par 00 ou (+), le numéro sera routé de la table
30 vers une autre table d’analyse 32, celle-ci possède tous les numéros au format international
(tous les country code des pays).
En plus des appels sortants, on a les appels entrants ; pour qu’ils puissent aboutir, le MSC
doit fournir un MSRN qui va être configuré dans la table 8 qui est dédiée aux MSRNs des
roamers.

84
Comme pour le cas précédent, on va utiliser l’OP et la NOP pour insérer ces changements dans
les tables d’analyse, en utilisant les mêmes commandes sauf qu’ici on va les appliquer sur les
tables d’analyse B-number.

• ANBSP (Analys іs, B-number, spécification, prіnt):b=32-258; printer le CC= 258 dans
la table b= 32, qui est bien sur défini dans tous les MSCs de Mobilis.
• ANBSP:8-258; printer la table 8.
• ANBZI; effacer la NOP.
• ANBCI ; copier l’OP dans la NOP.
• ANBSI:b=8-258; on va définir dans la table 8 le country code 258, cette commande
utilise les paramètres suivants :
- bnt (B-Number Type) : bnt = 1; indique que le numéro est au format international.
- d=6-140, est un dіscrіmіnateur, la table 6 représente la table des cba.
- rc (Routing Case) : indique la destination des appels. Pour rc = 250, les appels sont derіgés
vers l’international ; pour le MSC NOV, rc = 12 ; cette route va acheminer les appels vers le
GMSC.
- cc (Charging Case) : cc = 16 ; il prend en charge le côté facturation des appels, indique la
route vers le service billing.
-l (Length): l=7-20; la longueur des MSISDN varie entre 7 et 20 chiffres.
- a = 489; l’adresse du bіllіng.
• ANBSP:b=8-258, nop; printer la NOP.
85
 • ANBAI ; activation et permutation de l’OP et la NOP.
- La troisième étape
Tous les messages MAP échangés entre le HLR et les différents nœuds du réseau tel que le
GMSC, le VLR…, utilisent le SCCP. Pour que le SCCP puisse transférer ces messages, il s’ap-
puie sur le GT (Global Title) qui détermine l’adresse du nœud correspondant dans le réseau
SS7.
Pour cela, on doit définir le GT analysis dans tous les MSCs et les HLRs.

• C7GSI (CC
ӀTT7, Global Tіtle Serіes, Ӏntіate): cette commande utilise les paramètres suivants:
- ns : (ns=258) il correspond au country code du pays.
- na : (na= 4) l’adersse est au format international.
- np
(Numbering Plan) : il définit le plan de numérotage de l’adresse si :
*np= 1 :
le numéro utilisé est suivant le plan de numérotage E.164.
*np= 7 : le numéro est suivant la recommandation E.214.
- tt (Translation Type): par défaut le tt vaut toujours zéro.
- gtrc (Global Title Routing Case) : (gtrc= 1) c’est la route désignée pour envoyer les messages
signalisation SCCP vers d’autres nœuds.

86
La commande C7GSI avec le paramètre np= 7, est utilisée pour autoriser la mise à jour de
localisation.
La commande C7GSI avec le paramètre np= 1, est fourni pour toutes les autres communications
entre le HLR et le VLR.

87
 BIBLIOGRAPHIE

[1] ITU-D/Regulatory-Market-Documents Roaming-Guide-F.F

[2] [Link] ROAMING 2G, 3G et 4G : Principes, Architecture et Service

[3] [Link]/Frederic-Launay/tag/tap/
[4] roaming-in-wireless-networks/transferred-account-procedures-billing-and-settlement
[5] [Link]/website/serveur-informatique
[6] [Link]/index/passerelle-telecommunications
[7] Roaming-Documents Université de Montréal, 2016
[8] TD 57 TAP3 Processing Solutions and Services
[9] Call Detail Record (CDR) SIERRA LEONNE
[10] L’itinérance ou le roaming Séverin N'Datien Guibessongui
[11] Le serveur informatique Ajay Chowdhury
[12] La médiation - Le manuel relatif au règlement des conflits FREDERIC LAUNEY

[13] MEDILEH Saci, « Online Charging Systèm » UNIVERSITE KASDI MERBAH

OUARGLA, 2009.

[14] DE ROUCY DE FLACOURT Maxime, « ARCHITECTURES 3GPP D’UNE SYS-

TEME DE FACTURATION » 2011

[15] STEVE-TAP3-Editor-V3.11.11-Release-Notes(A4)

[16] RAVONIMANANTSOA Manda Vy cours « Merise et base de données » Cours Li-

cence 2 Département Télécommunication, ESPA, AU : 2019-2020.

[17] ASN.1 Communication entre systèmes hétérogènes Olivier Dubuisson

[18] GSM Association Roaming Database, Structure and Updating Procedures Version 9.1

88
 FICHE DE RENSEIGNEMENTS

Nom : ANDRIAMBOLOLONA
Prénom : Holinirina Hionontsoa
Adresse de l’auteur : III V 8 ac Ter E Anosizato Est
Téléphone : 038 72 303 09
E-mail : hionontsoa12@[Link]

Titre du mémoire : « PRINCIPE DU SYSTEME DE FACTURATION ROAMING EN

TELECOMMUNICATION »

Nombres de pages : 92

Nombres de figures : 27

Nombres de tableaux : 04

Directeur de mémoire :

Nom : RAMAFIARISONA

Prénoms : Hajasoa Malalatiana

Grade : Professeur

E-mail : mhramafiarisona@[Link]

Téléphone : 034 16 542 48

89
 RESUME

Actuellement, il y a plusieurs fournisseurs de système de facturation, dont chaque entreprise de

télécommunication choisi le principe et fonctionnement qui lui convient. Plusieurs normes et
principes devraient être suivi par ces derniers pour répondre aux qualifications et qualités de
service attendu par les entreprises de télécommunications ou opérateurs.
Le concept de facturation en roaming repose sur le traitement des CDRs et les échanges de
fichiers TAP d’un opérateur à un autre. La qualité de traitement des fichiers CDRs et fichier
TAP est un point clé pour assurer la fidélisation d’une entreprise par rapport à son système de
facturation. Tout au long de ce mémoire, on a pu voir la conception d’une application permet-
tant de combiner la médiation et la facturation pour un opérateurs téléphonique.

Mots clés : Roaming, CDRs, fichier TAP, médiation, facturation, opérateurs.

ABSTRACT
At present, there are several suppliers of billing systems, with each telecom company choosing
the principle and operation that suits it best. Several standards and principles should be followed
by the latter to meet the qualifications and quality of service expected by telecoms companies
or operators.
The roaming billing concept is based on the processing of CDRs and the exchange of TAP files
from one operator to another. The quality of processing of CDRs and TAP files is a key point
in ensuring a company's loyalty to its billing system. Throughout this dissertation, we have seen
the design of an application combining mediation and billing for a telephone operator.

Key words: Roaming, CDRs, TAP file, mediation, billing, operators.

90