Chapitre

1:

La

facturation

prpaye

dans

les

rseaux

de

tlcommunications

Introduction.................................................................................................2
1.1. Gnralits sur la facturation prpaye et la facturation
postpaye...................................................................................................2
1.1.1. Scnario dappel postpay.......................................................2
1.1.2. Scnario dappel prpay.........................................................3
1.2. La facturation prpaye dans un rseau tlphonique fixe
filaire...........................................................................................................4
1.3. Les services prpays mobiles......................................................7
1.3.1. L'approche Wireless Intelligent Network .......................8
1.3.1.1. Emission dun appel avec lapproche WIN.....................8
1.3.1.2. Rception dun appel avec lapproche WIN.................10
1.3.1.3. Recharge dun compte prpay dans lapproche WIN
..............................................................................................................11
1.3.2. L'approche Service Node ..................................................13
1.3.3. L'approche Hot Billing ......................................................15
1.3.3.1. Initialisation du service prpay et mission dun
appel dans lapproche Hot Billing ..........................................16
1.3.3.2. Consultation du solde et recharge dun compte dans
lapproche Hot Billing ...............................................................18
1.3.4. L'approche Handset-Based ...............................................19
1.3.4.1. Contraintes lies la carte SIM.....................................19

Page 1

1.3.4.2. Emission dun appel prpay dans lapproche

Handset-Based ............................................................................21
1.3.4.3. Recharge dun compte prpay dans lapproche
Handset-Based ............................................................................23
Conclusion..................................................................................................24

Introduction
Dans ce chapitre, nous tudierons de faon gnrale les diffrents
systmes

de

facturation

prpaye

utiliss

dans

les

rseaux

de

tlcommunications. Nous prsenterons galement leurs principes de

fonctionnement et soulignerons leurs faiblesses et forces.

1.1. Gnralits sur la facturation prpaye et la facturation

postpaye
La plupart des oprateurs de tlcommunications offrent deux options
leurs clients pour le paiement des services fournis : loption prpaye et
loption postpaye. Un client qui souscrit loption prpaye est qualifi de
client prpay alors quun client qui souscrit loption postpaye est
qualifi de client postpay.
Il existe plusieurs diffrences entre ces deux types de clients parmi
lesquelles nous pouvons citer :
Le mode de paiement des services : cest le facteur le plus
important qui diffrencie les deux types de clients. Les clients
prpays paient pour les services offerts lavance, avant mme
Page 2

dutiliser ces services. A loppos, les clients postpays utilisent

dabord les services offerts par les oprateurs durant une certaine
priode (gnralement un mois). Cest la fin de cette priode que
ces clients reoivent une facture, correspondant leur utilisation,
payer dans un dlai donn.
La facturation des services : La facturation des services
prpays impose des contraintes temps rel. En effet, chaque client
prpay dispose dun compte dont le montant doit tre vrifi avant
dautoriser laccs au service. De mme, au fur et mesure que le
client utilise le service, il doit tre factur et le compte doit tre mis
jour. Par contre, la facturation des services postpays nimpose
pas des contraintes temps rel. Le client peut tre factur bien
aprs lutilisation du service.
Du point de vue des clients, les services postpays ont le dsavantage de
ncessiter des signatures de contrats avec les oprateurs (mobile prepaid
phone services). De plus, les clients narrivent pas contrler leur
consommation. Les services prpays rsolvent ce problme en permettant
aux clients daccder immdiatement aux services sans tablir de contrat.
De mme puisque les clients peuvent consulter les soldes de leurs
comptes, ils arrivent mieux contrler leurs dpenses.
Du point de vue des oprateurs, les services postpays comportent des
risques de crances non recouvres alors quavec les services prpays, les
oprateurs sont srs de rentrer dans leurs fonds avant mme lutilisation
des services.
Toutes ces raisons amnent les oprateurs prfrer et mettre en place
des systmes de facturation prpaye malgr les contraintes temps rel
imposes par ces derniers.

Page 3

Pour mieux comprendre la diffrence entre la facturation prpaye et la

facturation postpaye, nous prsentons ci-dessous deux scnarios dappel
tlphonique : celui dun client postpay et celui dun client prpay.
1.1.1. Scnario dappel postpay
Les lments du rseau (les commutateurs) produisent des comptes
rendus dutilisation (UDR : Usage Detail Record) ou des comptes rendus
dappels (CDR : Call Detail Record), qui contiennent les informations
ncessaires pour facturer le client. Le format dun CDR / UDR est dfini
par loprateur et peut contenir :
Le numro de lappelant
Le numro du destinataire
La date et lheure du dbut de lappel
La dure de lappel
Le type dappel : MOC (Mobile Originating Call) pour indiquer que
cest lappelant qui sera factur pour lappel et MTC (Mobile
Terminating Call) pour indiquer que cest le numro recevant lappel
qui sera factur.
Le CDR / UDR est ensuite envoy au systme de facturation postpaye
(Billing System) qui le convertit dans un format comprhensible. Le CDR /
UDR converti est ensuite associ au compte du client qui doit tre factur
et le tarif souscrit par ce client est appliqu lappel ou au service.
Les CDRs / UDRs auxquels les tarifs ont t appliqus sont ensuite
stocks dans une base de donnes puis la date de fin du cycle de
facturation (fin du mois), une facture finale est produite, tenant compte
des taxes, des remises, puis elle est envoye au client.
Le client paie ensuite la facture et le systme de facturation postpaye
(billing system) est mis jour avec les dtails du paiement. La figure
suivante rsume le scnario de facturation postpaye.

Page 4

Figure 1.1 : Scnario de facturation postpaye

1.1.2. Scnario dappel prpay

Les tapes dun scenario dappel prpay sont les suivantes:
Lorsquun client du RTC (Rseau Tlphonique Commut) effectue
un appel, la passerelle de commutation prpaye rcupre le numro
de tlphone de lappelant et envoie les donnes de son compte au
systme de facturation en temps rel.
Le systme de facturation en temps rel utilise ces informations
pour authentifier lutilisateur, calculer le solde restant dans son
compte en utilisant la table des tarifs et pour calculer galement la
dure maximale dappel allouable au client. Cette dernire donne
est envoye la passerelle prpaye.
La passerelle tablit lappel.
Durant lappel, la passerelle contrle lappel de telle sorte que
lutilisateur nexcde pas la dure maximale dappel allouable.
A la fin de lappel, la passerelle envoie la dure relle de lappel au
systme de facturation prpaye, qui ensuite calcule le cot rel de
lappel et met jour le solde du compte du client.

Page 5

La figure suivante illustre le scnario de facturation prpaye :

Figure 1.2: Scnario de facturation prpaye

1.2. Facturation prpaye dans les rseaux mobiles de troisime

gnration (3G)
A lorigine, les rseaux

mobiles de deuxime gnration (2G) taient

conus pour offrir uniquement les services de voix par commutation de

circuits et le service de messages courts (SMS : Short Message Service).
Les

systmes

prpays

utiliss

pour

facturer

ces

services

sont

implments suivant quatre (04) techniques ou approches (mobile prepaid

phone services) :
Service Node
Intelligent Network (IN)
Handset-Based

Page 6

 Hot Billing
Dans les rseaux mobiles de troisime gnration (3G), les systmes
prpays conus avec lapproche IN (Intelligent Network) sont les plus
utiliss. Ainsi, le protocole CAMEL (Customized Application for the
Mobile Network Enhanced Logic), un standard de lapproche IN, est utilis
dans le rseau UMTS (Universal Mobile Telecommunications System).
Quant aux rseaux CDMA2000, ils utilisent le WIN (Wireless Intelligent
Network). Notons que le protocole CAMEL prend galement en charge la
facturation des services de commutation de paquets offerts via le GPRS
(General Packet Radio Service) alors que le WIN ne prend en charge que
la facturation prpaye des services de commutation de circuits. La
facturation prpaye des services IP offerts via le rseau de commutation
de paquets du CDMA2000 (wireless IP network) est ralise grce au
protocole RADIUS (Remote Authentication Dial In User Service).
Cependant, RADIUS ne permet dimplmenter que de simples tarifs
linaires qui sont soit bass sur le volume de donnes ou la dure dune
session (Sate of the art ). De mme, CAMEL offre des possibilits assez
rudimentaires pour la facturation prpaye des services IP offerts via le
GPRS. Il est, par exemple, incapable de facturer un service sur la base de
son contenu.
Pour outrepasser les limites lies la facturation prpaye des services IP
dans les rseaux mobiles 3G, la 3GPP (Third Generation Partnership
Project) a introduit lIMS (Internet Protocol Multimedia Subsystem) dans
la Release 5 de lUMTS (Sate of the art ). LIMS joue un rle central
dans la fourniture des services mutimdias bass sur le protocole IP. Afin
dassurer la facturation prpaye de ces services, la 3GPP a galement
dfini lOCS (Online Charging System), qui sera vu de manire plus
approfondie dans le chapitre 3.

Page 7

1.3. Facturation prpaye dans les rseaux IP

1.3.1. Processus AAA
On ne saurait parler de la facturation dans un rseau IP sans aborder de
faon gnrale les processus dauthentification, dautorisation et de
comptabilit. Ces processus sont le plus souvent connus et regroups sous
le terme AAA (Authentication, Authorization, and Accounting) et
sont dune importance capitale dans un rseau IP bien quils ne soient pas
tellement visibles par les utilisateurs finaux.
L'importance des processus AAA rside dans le fait qu'ils fournissent la
protection et le contrle requis pour accder un rseau. Par consquent,
ils offrent l'administrateur du rseau la possibilit de facturer
l'utilisateur final pour les services utiliss.
Avant daller plus loin, dfinissons les diffrentes terminologies :
Authentication (authentification) : Cest le fait de vrifier lidentit
dune entit.
Authorization (autorisation) : Cest le fait de dterminer si une entit
demandant une ressource peut avoir accs celle-ci (par exemple laccs
au rseau ou une certaine quantit de bande passante).
Accounting (comptabilit) : Cest le fait de collecter des informations
relatives lutilisation des ressources des fins de planification de
capacit, daudit, et de facturation.

Page 8

Tous ces concepts sont intimement lis. Par exemple, il nest pas possible
denregistrer lutilisation dune ressource lorsque lentit utilisant ladite
ressource nest pas encore identifie. Par consquent, pour grer les
donnes lies lutilisation dune ressource, lentit doit dabord tre
authentifie.

1.3.2. RADIUS
Dans les rseaux IP, le protocole RADIUS et son extension pour la
comptabilit (journalisation des accs) sont les protocoles les plus
rpandus, utiliss pour grer lauthentification, lautorisation, et la
comptabilit (AAA).
Le protocole RADIUS a t dfini par lIETF (Internet Engineering Task
Force). Dvelopp suivant larchitecture client-serveur, il est gnralement
utilis dans les serveurs daccs au rseau (NAS : Network Access Server)
tels que les points daccs sans fil et les passerelles VoIP (Voice over IP).
Dans larchitecture de ce protocole, le client RADIUS (le NAS) est charg
denvoyer les informations de lutilisateur au serveur RADIUS, et
deffectuer ensuite certaines actions sur la base de la rponse reue. Le
serveur RADIUS reoit les demandes de connexion de lutilisateur,
lauthentifie, puis renvoie toutes les informations de configuration
ncessaires au client RADIUS pour la fourniture du service.
La figure 1.3 prsente larchitecture du protocole RADIUS.

Page 9

Figure 1.3: Architecture de RADIUS

Le protocole RADIUS a subi des volutions travers le dveloppement de
plusieurs extensions grce au groupe de travail RADEXT (RADIUS
Extensions) de lIETF. Leurs travaux ont conduit la conception dune
extension pour la facturation prpaye (A. Lior, 2005).
Toutefois, le protocole RADIUS prsente des limitations. Pour venir bout
de ces limitations, un groupe de travail de lIETF a, paralllement au
RADEXT, rflchi dfinir un successeur du protocole RADIUS. Leurs
travaux ont conduit au protocole de base DIAMETER et son extension
CCA (Credit Control Application) pour prendre en charge la facturation
prpaye(H. Hakala, 2005).
1.3.3. DIAMETER CCA
Le protocole DIAMETER est une volution de RADIUS, qui offre plus de
flexibilit et permet deffectuer les oprations AAA dans les rseaux IP
offrant des services multimdias. Il intgre les capacits de fail-over1 et
assure le transport scuris via les protocoles TCP (Transmission Control
Protocol)

et

SCTP

(Stream

Control

Transmission

Protocol).

Son

architecture modulaire offre un protocole de base flexible, permettant

dajouter des extensions spcifiques certaines applications.
Tout comme le protocole RADIUS, DIAMETER fonctionne suivant
larchitecture client-serveur. Le client et le serveur interagissent travers
lchange des messages de requte et de rponse DIAMETER. Un agent
relai DIAMETER peut tre utilis pour acheminer les messages vers la
destination approprie.
La figure 1.4 prsente larchitecture du protocole DIAMETER.

1 Le fail-over (basculement en franais) est la procdure par laquelle, un systme transfre

automatiquement le contrle un systme alternatif en cas de dtection de panne.

Page 10

Figure 1.4: Architecture de DIAMETER

DIAMETER CCA (DIAMETER Credit Control Application) est une
extension de DIAMETER utilise pour implmenter le contrle de crdit
(CC : Credit Control) en temps rel pour les services de type session ou
vnement. Les standards dfinissent une architecture de contrle de
crdit constitue de serveurs de contrle de crdit (serveurs CC) et de
clients de contrle de crdit (clients CC). Gnralement, le serveur CC fait
partie dun serveur AAA alors que le client CC est situ au niveau de la
passerelle qui permet daccder aux services.
Le serveur CC est charg de dterminer les units accorder pour un
service demand, en accdant au compte de lutilisateur et en appliquant
les tarifs. Les units dtermines peuvent tre montaires ou non
montaires (volume de donnes par exemple). Le client CC se charge de
surveiller les units accordes par le serveur CC et met en place des
alarmes au niveau des lments de mesure du trafic (metering
components). Ces alarmes ne sont rien dautre que des seuils des units
accordes et sont dclenches lorsque les units sont puises.
La figure 1.5 prsente larchitecture de DIAMETER CCA avec un lment
de mesure du trafic.

Figure 1.5: Architecture de DIAMETER CCA

Page 11

Conclusion
Dans ce chapitre, nous avons abord les gnralits sur la facturation
prpaye et la facturation postpaye. Ensuite nous avons pass en revue
les diffrents protocoles et systmes utiliss pour la facturation prpaye
dans les rseaux mobiles et les rseaux IP.
Le prochain chapitre abordera les systmes mis en place par Bnin
Tlcoms SA pour la facturation de ses services IP.

Bibliographie
Yi-Bing Lin; Ming-Feng Chang; Herman Chung-Hwa Rao. Mobile prepaid
phone services. IEEE Personal Communications, Volume 7, Issue 3 (June
2000), pp. 614
3GPP2 X.S0011-006-C. CDMA2000 Wireless IP Network Standard:
Prepaid Packet
Data Service. Version 2.0, July 2005
A. Lior, P. Yegani et al. PrePaid Extensions to Remote Authentication
Dial-In User Service (RADIUS).draft-lior-radius-prepaid-extensions09.txt, October 2005
H. Hakala, et al. DIAMETER Credit-Control Application. IETF RFC
4006, August 2005

Page 12