6 Réseau Intelligent et Réseau Mobile : CAMEL

La normalisation des réseaux mobiles en technologie GSM étant assurée par l’ETSI, cet organisme de
normalisation s’est rapidement intéressé à l’introduction des normes du RI dans les réseaux mobiles. La
motivation principale était l’introduction du service de téléphones mobiles "prépayé". Instruit par le retour
d’expérience des normes de l’IN-CS1, l’ETSI a voulu introduire un certain nombre de simplifications et des
fonctionnalités spécifiques aux réseaux mobiles, rendant la technologie ainsi définie légèrement différente de
celle du réseau intelligent sur le réseau fixe. Pour cette raison l’ETSI a choisi un autre nom pour cette nouvelle
technologie pourtant très proche de celle du RI et l’a dénommée CAMEL pour "Customized Applications for
Mobile Enhanced Logic".
Pour comprendre les différences entre le réseau intelligent sur réseau fixe et le réseau intelligent sur réseau
mobile nous présentons sur la figure 35 la configuration d’un réseau fixe et sur la figure 36 la configuration d’un
réseau mobile GSM. Dans ces figures nous distinguons :
des fonctions d’accès : raccordement physique de l’abonné au réseau et stockage dans une base de donnée
de son profil (ses droits, les services qu’il a souscrit, son nom (numéro d’annuaire) et son adresse (numéro
d’équipement))
des fonctions de transport : traitement d’appel établissant la mise en relation avec l’abonné distant (appel) et
la mise en continuité des ressources de transmission (connexion)
des fonctions d’intelligence : services substitutif au traitement d’appel

Accès Jonctions Transport Intelligence

d’accès
RCX
JL PSTN
CSN
TE

INAP
Profil CCF SSF SCF

Figure 35 – Réseau intelligent sur réseau fixe

Nous voyons sur la figure 35 que dans le réseau fixe, le raccordement physique de l’abonné se fait par une
ligne constituée d’une paire torsadée de fils de cuivre. Cette ligne après passage par divers répartiteurs se termine
sur un circuit appelé Joncteur de Ligne (JL) localisé sur une carte d’abonné. Typiquement, une carte d’abonné
embarque 16 ou 32 joncteurs de ligne. Les cartes d’abonné sont localisées dans des équipements appelés
Concentrateurs Satellites Numériques CSN dont le rôle est de connecter l’abonné qui décroche à une jonction
d’accès (canal de transmission entre le concentrateur et la matrice ou Réseau de Connexion du commutateur
RCX). Le nombre de jonctions d’accès est très inférieur au nombre d’abonnés, c’est pourquoi l’on parle de
concentrateur. Typiquement un concentrateur qui sert 1000 abonnés n’est équipé que de 150 jonctions d’accès (il
est typique que sur 1000 abonnés, il ne puisse y en avoir plus que 150 qui puissent appeler à la fois).
Dans le réseau fixe, il y a une notion de commutateur de rattachement. La base de donnée contenant le profil
de l’abonné est donc localisée dans l’unité de contrôle du commutateur, et le traitement d’appel (CCF) n’a donc
besoin d’aucune signalisation pour récupérer le profil (Originating Translation) ou faire une traduction
nom/adresse (Terminating Translation).

Nous voyons maintenant sur la figure 36 que dans le réseau mobile, le raccordement physique de l’abonné se
fait par radio numérique. L’équivalent du joncteur de ligne est un émetteur/récepteur radio appelé Base Station
Transceiver BTS raccordé à l’équivalent d’un concentrateur appelé Base Station Controller BSC.
Dans le réseau mobile, il n’y a plus de notion de commutateur de rattachement. Un abonné peut se porter
présent sur n’importe quel commutateur du réseau. La base de donnée contenant le profil de l’abonné ne peut
donc plus être locale à un commutateur, elle est forcément centralisée et s’appelle Home Location Register HLR.
Pour un abonné d’un réseau mobile, il n’y a qu’une seule HLR. Typiquement une HLR contient les profils d’une
tranche de 5000000 abonnés.
Lorsqu’un abonné se présente (se logue) sur un central du réseau mobile (appelé Mobile Switching Center
MSC) ce dernier doit donc récupérer le profil de la HLR et y mettre à jour la localisation. Nous appelons cette
opération la "Session d’accès". Comme la HLR est distante, la session d’accès nécessite une signalisation

28
d’accès appelée MAP (Mobile Application Part). Pour ne pas multiplier les échanges avec la HLR, le central
visité stocke le profil de l’abonné dans une base de donnée secondaire co-localisée avec lui appelée VLR (Visitor
Location Register).

Accès Transport Intelligence

MSC
BTS PSTN
BSC

MS

Camel
CAP
HLR VLR BCF SSF SCF
MAP MAP

Figure 36 – Réseau intelligent sur réseau mobile

6.1 CAMEL phase 1

Comme pour le RI, le développement des spécifications de CAMEL était prévu par étapes successives
appelées ici "phases". La première norme CAMEL est donc qualifiée de " CAMEL-phase1". Cette norme est en
fait extrêmement limitée, n’introduisant que le sous ensemble de fonctions de l’IN-CS1 strictement nécessaires
pour réaliser le service prépayé. Il se trouve que le prépayé s’est révélé être une "Killer Application" du fait qu’il
évite les surprises de facturation en fin de mois. Dans beaucoup de pays, en particulier dans les pays en
développement, ce sont les services prépayés qui deviennent majoritaires. C'est ainsi que nous nous orientons
maintenant vers le GPRS prépayé, merveille de technologie puisqu'il combine à la fois le réseau mobile, les
réseaux Data, la signalisation du mobile et la signalisation du réseau intelligent. (CAMEL-phase3)

Accès Visité Accès Home T ran sp ort In telligen ce

CAMEL
MAP HLR CAP
SCF

Marques CAMEL

VLR

SSF
BTS
BSC MSC MSC

MS

Figure 37 – Principe de CAMEL

Le principe de fonctionnement de CAMEL phase 1 est indiqué sur la figure 37. Lorsqu’un abonné allume son
poste mobile dans son réseau home, ou dans un réseau visité, la VLR locale interroge sa HLR home pour obtenir
les données d’authentification. Une fois cette authentification réussie la VLR met à jour la localisation de
l’abonné mobile (MAP_Update_Location), puis reçoit le profil de cet abonné (MAP_Insert_Subscriber_data). Le

29
profil de l’abonné, contient, en plus des indications sur les services auxquels il a droit, des informations appelées
O-CSI (Originating Camel Subscriber Information) et un T-CSI (Terminating Camel Subscriber Information).
Ces informations sont en fait l’identification des DP qu’il faut aller armer dans la SSF du MSC visité pour que
les services de cet abonné puissent être déclenchés. Autrement dit, la grande différence entre le Réseau
Intelligent et CAMEL c’est qu’en RI, les DP ou Trigger Points sont armés par la gestion à la création du service,
alors qu’en CAMEL les DP sont armés par la signalisation MAP de la session d’accès.
Chaque marque contient les champs suivants :
La clé du service (Service Key) [0..231-1]
Le type du TDP-R [DP2/DP12]
l ?adresse du gsmSCP (gsmSCP Address)[format E164 : préfixe national (‘A1’) ou international (‘91’) + 15
chiffre max. ]
Le comportement par défaut du gsmSSP, si absence ou erreur de dialogue avec le gsmSCP (Default Call
Handling) [REL/CONT]
Le comportement si le VLR visité ne supporte pas CAMEL (version MAP < v3 ou option CAMEL non
affirmée) [REL/CONT]
Le comportement si le GMSC ne supporte pas CAMEL (version MAP < v3 ou option CAMEL non
affirmée) [REL/CONT]
l ’indicateur de demande de localisation de l ’abonné [Y/N]
l ’indicateur de demande d ’état de l ’abonné [Y/N]

Par la suite, quand l’abonné fait un appel, le mécanisme de substitution de l’appel normal par un traitement
substitutif est strictement semblable à celui du réseau intelligent. Cependant en CAMEL phase 1 les opérateurs
étaient très précautionneux quant à la possibilité pour une plate-forme de service ne leur appartenant pas d’aller
piloter leurs propres commutateurs (cas d’un abonné étranger en roaming). Par précaution, ils ont donc prévu un
ensemble de capacités pour CAMEL phase 1 beaucoup plus réduit que les capacités de IN-CS1. En fait ils n’ont
retenu de IN-CS1 que le minimum de capacités strictement nécessaire à la réalisation du service prépayé.
Pour ce faire, comme le montre la figure 38, l’architecture d’exécution de service du plan fonctionnel réparti
a été allégée par la suppression des serveurs vocaux ou autres ressources spécialisées.

MAP
Home Network gsmSCF
HLR
CSE

MAP CAP CAP

MAP

gsmSSF VLR gsmSSF

MS
incoming line GMSC VMSC
Roaming leg

MO call -Outgoing leg

Forwarded leg or Forwarding leg

Interrogating Network Visited Network

Figure 38– Plan fonctionnel réparti de CAMEL phase 1

Les modèles d’appels O-BCSM et T-BCSM ont été considérablement simplifiés, avec un nombre de DP et de
PIC très réduits. Nous voyons sur la figure 39 que dans l’O-BCSM, le PIC 1 O_Null & Authorise origination
attempt et le PIC 2 Collect_Info de l’IN-CS1 on été fusionnés en CAMEL en un seul PIC O_Null & Authorise-
origination Attempt Collect Info et les PICs 3 Analyse Information et 4 Routing & Alerting de l’IN-CS1 on été
fusionnés en CAMEL en un seul PIC Analyse, Routing&Alerting. Pareillement, dans le T-BCSM les PICs 8
Select Facility & Present Call et 9 T_Alerting ont été fusionnés en un seul PIC Terninal-Call-Handling . Des 10

30
DP de l’ O-BCSM de l’IN-CS1, il n’en reste que 3 et des 8 DP du T-BCSM de l’IN-CS1, il n’en reste également
que 3.

O-Null&Authorise- T-Null T-Exeption

origination-Attempt-
Collect-Info

Terminating-
Collected-Info Attemp-
DP TDP-R DP TDP-R
Analyse, Terninal-Call-
Routing&Alerting

O-Disconnect O-Answer O-Disconnect T-Answer

EDP-R/N DP EDP-R EDP- DP EDP-R
DP 9 O-Active DP T-Active

O-BCSM T-BCSM

Figure 39– O-BCSM et T-BCSM de CAMEL phase 1

La signalisation INAP de l’IN-CS1 s’est également trouvée modifiée, pour s’appeler maintenant CAP
(CAMEL Application Part). Les 29 commandes de INAP-CS1 sont maintenant réduites à 6 commandes, avec
cependant un ajout de 4 nouvelles commandes. Il est normal d’ailleurs qu’il y ait moins de commandes puisqu’il
n’y a plus de ressources spéciales et donc plus besoin de commandes pour les piloter. Nous donnons maintenant
les commandes de CAP Phase 1:
Il y a 6 commandes issues de INAP-CS1
Initial DP : Généré par la gsmSSF lorsqu’un point de déclenchement a été détecté dans un DP du BCSM,
pour demander des instructions à la gsmSCF. structuré principalement en : Called Party Number, Calling
Party Number, Event Type BCSM, IMSI, Location Information
Connect : Pour demander à la gsmSSF de poursuivre le traitement de l’appel et le router vers une
destination particulière.
Continue : Pour la poursuite par la gsmSSF de l’appel là où il a été suspendu, sans modifier les données
associées. Pas d’élément d’information
Release Call : Arrêt par la gsmSCF d’un appel quel que soit sa phase courante. IE : Cause de l’arrêt
Request Report BCSM Event : Demande à la gsmSSF de notifier un événement du BCSM. IE : type de
l’événement
Event Report BCSM
Il y 4 nouvelles commandes, spécifiques des réseaux mobiles :
Activity Test : Pour vérifier l’existence continue d’une relation entre la gsmSCF et la gsmSSF.
Activity Test Response
Any Time Interrogation Request Pour obtenir de la HLR des infos concernant l’abonné : Adresse de la
gsmSCF, Informations demandées (état, localisation), Identitification de l’abonné (IMSI, MSISDN)
Any Time Interrogation Response

Update-Location_Invoke(IMSI, VLR-Number, LMSI)

VLR HLR
Insert-Subscriber-Data-invoque (PLMN-specific SS-4, O-Bcsm-TD-
Point : Collected-info)
Insert-Subscriber-Data-Result (Phase 1)

Update-Location_Result(HLR-Number)

Figure 40– CAMEL phase 1 : armement des DP dans le MSC visité

31
 Pour illustrer le fonctionnement de CAMEL, la figure 40 nous montre les échanges permettant de charger les
marques CAMEL au moment de l’allumage du poste mobile (session d’accès) et donc d’armer les DP dans ce
MSC.
La figure 41 nous montre les échanges lorsqu’un téléphone prépayé émet un appel. Nous voyons que les DP
"réponse"et "raccrochage" sont armés dynamiquement par la signalisation CAP, en cours de session. A la
réponse de la personne appelée, une commande Event Report BCSM entame la décrémentation du solde de
l’abonné demandeur dans la plate-forme de service. Au raccrochage, une autre commande Event Report BCSM
arrête cette décrémentation.

VMSC gsmSCP

Initial-DP(Service Key, Calling Party Number, Location Number, Event Type Bcsm,
IMSI, Age Of Location Information , Location Area Code , Call Reference Number,
MSC Address, Called Party BCD Number)
Request Report BCSMEvent (O-answer, Notify-and-continue, O-disconnect, Notify-
and-continue, Leg1)

Continue()
Event Report BCSM (O-answer, Notification)

Event Report BCSM (O-disconnect, Notification)

Figure 41– CAMEL phase 1 : appel prépayé

6.2 Camel phase 2

Nous voyons que la norme CAMEL phase 1 est extrêmement limitée, reflétant l’extrême prudence au début
des opérateurs vis à vis de CAMEL.

Home Network gsmSCF

HLR
CSE
CAP CAP

gsmSSF VLR gsmSSF

incoming line Roaming M
MSC VMSC S

Forward leg CAP MO call -Outgoing leg

or Forwarding leg
CAP
Interogating Network CAP
Visited Network

gsmSRF

Figure 42– Plan fonctionnel réparti de CAMEL phase 2

Mais il se trouve que le succès du service prépayé s’est révélé phénoménal. Dans beaucoup de pays, en
particulier dans les pays en développement, ce sont les services prépayés qui sont prédominants (les 3 quarts des

32
abonnés mobiles dans certains pays !) du fait qu’ils évitent les surprises en fin de mois. D’ailleurs certains pays
proposent maintenant le prépayé dans le réseau fixe !
Enhardis par ce succès les opérateurs ont donc étudié une deuxième phase de CAMEL dont les objectifs
correspondaient à obtenir sur les réseaux mobiles les mêmes possibilités d’offre de service que sur les réseaux
fixes avec IN-CS1. Pour ce faire, comme le montre la figure 42, l’architecture d’exécution de service du plan
fonctionnel réparti a été rétablie en conformité celle de IN-CS1 en réintroduisant les fonctions de ressources
spécialisées : gsmSRF.
Les modèles d’appels O-BCSM et T-BCSM ont été considérablement renforcés avec un nombre de DP
augmenté, ce qui donne plus d’occasion de déclencher des services. Toutefois il n’a pas été jugé utile de
réaugmenter le nombre de PICs pour revenir aux PICs se l’IN-CS1.

10 O_Null &Authorize Termination_ O_Exception

Attempt_Collect_Info
O Abandon

Collected Info
2 Route_Select_Fai
llure
4
O Busy
Analyse, Routing_ 5
& Alerting O_No_Answer
6

7 O_Answer
9
O_Active
O Disconnect

Figure 43– Plan fonctionnel réparti de CAMEL phase 2 : O-BCSM

Nous voyons sur les figures 43 et 44 que dans l’O-BCSM et le T_BCSM plusieurs DP de l’IN-CS1 sont
réintégrés :
Occupation : O/T_Busy
non-réponse : O/T_No_Answer
échec de l’appel : Route_Select_Failure

18 T_Null T Exception
T Abandon

Terminating Attempt
12
T Busy
13
Terminating Call Handling T_No_Answer
14

15 T Answer
17 T Active
T Disconnect

Figure 44 – Plan fonctionnel réparti de CAMEL phase 2 : T-BCSM

33
 La signalisation CAP phase 2 est maintenant tout à fait semblable à l’INAP-CS1. Nous retrouvons 29
commandes habituelles plus les commandes spécifiques de la mobilité. En particulier nous retrouvons nos
commandes d’un périphérique intelligent pour les diffusion de message et de tonalité et la récupération de
numéros composés par le client. Nous donnons dans le tableau de la figure 45 les principales commandes de
CAP phase 2

Initial DP Furnish Charging Information

Continue Send Charging Information
Cancel Reset Timer

Request Report BCSM Event Activity test

Event Report BCSM Activity Test Ack
Any Time Interrogation Request
Any Time Interrogation Ack
Activity test

Connect to Resource Begin Subscriber Activity

Disconnect Forward Connexion Unstructured SS Request
Apply Charging Unstructured SS Notify
Play announcement Process Unstructured SS Data Ack
Prompt and Collect User Information Process Unstructured SS Request Ack
Specialized Resource Report

Connect
Call Information request
Call Information Report
Release Call

Figure 45 – Commandes CAP phase 2

Messages USSD (Unstructured Supplementary Service Data)

Il s’agit d’une facilité du GSM qui présente certaines similarités avec les SMS dans la mesure où les deux
types de messages sont transmis sur les canaux de signalisation du GSM. Au contraire du SMS les USSD
nécessitent l’établissement d’une session qui reste ouverte jusqu’à ce que l’un des partenaires de la session la
relâche. Les messages USSD sont des messages texte d’une longueur maximale de 182 caractères. Ils sont très
pratiques pour la communication de mobile à mobile en temps réel.
Nous pouvons voir que CAP phase 2 possède des commandes pour utiliser les messages USSD. Initiées par
la station mobile ils permettent à l’usager de modifier des données dans le serveur Camel.
Une application courante utilise cette facilité pour recharger le crédit d’un téléphone prépayé.
Initiées par la gsmSCF les commandes de messages USSD permettent au serveur d’envoyer au client des
informations spécifiques aux services, par exemple de faire un push du crédit restant après chaque appel.

6.3 Camel phase 3

Camel phase 2, comme IN-CS1, ne concerne que des services déclenchés à partir de sessions voix.
L’introduction de la norme GPRS dans les réseaux mobiles GSM introduit la possibilité de réaliser des sessions
data à partir de la station mobile transformant ainsi le réseau mobile en véritable réseau à intégration de service.
La figure 46 indique les principes utilisés avec le GPRS. Si le client ouvre une session data depuis sa station
mobile MS, les données sont transportées dans un intervalle de temps des trames radio et sont aiguillées par la
BSC vers un routeur Stateful appelé Serving GPRS Support Node SGSN. Nous disons que ce routeur est Stateful
car il est doté d’un logiciel d’établissement (et relâchement) de sessions contrairement à un routeur classique.
Nous avons donc deux réseau de transport séparés : un réseau de transport circuit aussi appelé CSN (Circuit
Switched Network) pour les sessions voix et un réseau de transport paquet aussi appelé PDN (Packet Data
Network) pour les sessions data.
La possibilité de déclencher des services à partir des sessions voix reste identique à ce qui pouvait se faire en
CAMAL phase 2 : La session d’accès permet toujours de charger les marques CAMEL dans la VLR puis
d’armer à partir de ces marques les DP correspondant dans le MSC.

34
 Cependant un réseau GPRS offre également la possibilité de réaliser des sessions data. Dans cette
architecture, les MSC ne sont pas concernés par les sessions data. Il faut donc qu’il y ait des DP dans le logiciel
d’établissement de sessions du SGSN.

Accès Transport Intelligence

MSC
BTS CSN
BSC

MS

Camel
MAP
CAP
HLR VLR CCF SSF SCF
MAP

MAP
CAP
Context

SGSN PDN

Figure 46 – GPRS et services réseau intelligent

En réalité, les traitements du SGSN sont modélisés par deux automates :

Un automate modélisant la session d’accès, appelé GPRS Attach
Un automate modélisant les sessions data, appelé PDP Context (Packet Data Protocol Context)

Detached

Attach Request

Detach AD_Exception
User or network
Initiated detach

Attach
Attached

Intra SGSN Routing Inter SGSN Routing

area update area update

Change of Position GPRS Session

Figure 47 – GPRS : automate GPRS Attach

35
 L’existence de ces deux automates séparés est extrêmement intéressante pour la fourniture de services
puisqu’elle permet de déclencher des services soit au moment où on allume son poste ou on l’éteint, soit à
chaque session de transfert de données.

L’automate GPRS Attach est représenté sur la Figure 47. Il a 3 PICs : Detached, Attached et AD_Exception.
Il y a également 3 DP, Le DP Attach à l’entrée du PIC Attach, le DP Detach à la sortie du PIC Attach et un DP
Change of Position pour une sortie provisoire du PIC Attach. Ces 3 DP constituent autant d’occasions de
déclencher des services data au moment où l’on allume ou l’on éteint son terminal mobile ou encore où l’on
exécute un handover (changement de position).
L’automate PDP context est mis en œuvre à chaque nouvelle session data. Chacun de ses DP permet de
déclencher un service sur une session data. Il est représenté sur la Figure 48. Il a 5 PICs : Idle,
PDP_Context_Setup, PDP_Context_Established, Change of position context et C_Exception. Il y a 4 DP, Le DP
PDP_Context_Establishing à l’entrée du PIC PDP_Context_Setup, le DP PDP_Context_Established_Ack à
l’entrée du PIC PDP_Context_Established, le DP PDP_ContextDisconnected à la sortie du PIC
PDP_Context_Established et enfin un DP Change of Position context à l’entrée du PIC Change of position
context.

Idle

PDP Context
setup request

PDP Context Est.

PDP context
PDP_Context_Setup C_Exception
disc.
PDP Context setup
Req. Ack

User or network PDP Context Est. Ack.

initiated disc.
PDP_Context_
Established

Routing area update

Change of Position Context

Change of position
context Routing area update

Figure 48 – GPRS : automate PDP Context

Comme indiqué sur la figure 46, les DP de ces deux automates sont armés depuis la HLR par la signalisation
MAP qui charge un profil CAMEL data dans le SGSN avec les marques CAMEL correspondant aux services de
l’abonné.
La Signalisation CAP phase 3 contient des commandes CAP entre la SCF et le SGSN. Ces commandes sont
indiquées dans le tableau ci-dessous

Activity Test GPRS Ack
Apply Charging Report GPRS
Entity Released GPRS
Event Report GPRS
Initial DP GPRS
Activity Test GPRS
Apply Charging GPRS Event Report GPRS Ack
Apply Charging Report GPRS Ack Furnish Charging Information GPRS
Cancel GPRS Release GPRS
Connect GPRS Request Report GPRS Event
Continue GPRS Reset Timer GPRS
Entity Released GPRS Ack Send Charging Information GPRS

36