11. T_Exception 7.

T_Null & Authorize

Termination_Attempt

18 T_Abandon
Term._Attempt_Authorized
12
8. Select_Facility &
13
Present_Call
T_Called_Party_Busy

14 9. T_Alerting
T_No_Answer

T_Answer
15
10. T_Active 17
T_Disconnect

T_Mid_Call 16

Figure 6 - TBCSM : états de connexion demandée

3 Normalisation et modèle conceptuel du réseau intelligent.

3.1. Un modèle conceptuel pour faire des normes

Pour créer des normes, les concepteurs du réseau intelligent ont imaginé un modèle dit "modèle conceptuel"
(Intelligent Network Conceptual Model INCM) destiné à représenter un ensemble de sujets devant être
normalisés. Il est décrit par la recommandation UIT-T Q.1201.
Le modèle conceptuel du RI n’est pas un modèle utilisable pour une réalisation d'équipement. Il est constitué
de quatre "plans" où chaque plan représente un type de sujet nécessitant d’être normalisé.

service1 service2 Plan service

SF1 SFn
SF2

global service logic

GSL1
BCP POI SIB1
SIB2 GSL2
POR SIBn GSLn Plan fonctionnel global

FE1 FE2 Plan fonctionnel réparti

F EF
E F EF
A E
EF A EF

Plan Physique
PE2
P2 PEn
P1
PE1 FE1
FE2
Pn

Figure 7 - Le modèle conceptuel du Réseau Intelligent

Les plans 1 et 2 (plan service et plan fonctionnel global) ont une nature différente des plans 3 et 4 (plan
fonctionnel réparti et plan physique). Les plans 1 et 2 sont concernés par la définition des services :

7
 le plan des services (Service Plane) donne des règles à respecter lorsque l’on invente un service.
le plan fonctionnel global (Global Functional Plane) donne une méthode formelle de description non
ambigüe d’un service.
Les plans 3 et 4 sont concernés par la réalisation d’un environnement fonctionnel et matériel capable
d’exécuter tout type de service pourvu qu’il soit défini en conformité avec les méthodes spécifiées dans les
plans 1 et 2.
le plan fonctionnel réparti (Distributed Functional Plane) définit une architecture fonctionnelle
d’exécution de service, c'est-à-dire des fonctions logicielles constituant un environnement d’exécution de
tout type de service défini en conformité avec les méthodes spécifiées dans les plans 1 et 2.
le plan physique (Physical Plane) indique comment répartir les fonctions du plan fonctionnel réparti dans
des machines physiques. Nous verrons que plusieurs scénarios peuvent être mis en œuvre à ce point de
vue

3.2. Des ensembles successifs de fonctionnalités

La normalisation ITU-T a prévu différentes étapes pour la spécification du réseau intelligent, appelées
"ensembles de capacités" (capability sets ou CS).
La norme de l’INCS1 (Intelligent Network Capability Set 1) est publiée en 1992. L’INCS1 est en réalité la
seule norme du réseau intelligent qui se trouve entièrement implémentée par les industriels.
Il avait été prévu qu’un nouvel ensemble de capacités serait publié tous les 2 ans. A ce rythme nous devrions
en être, à l’écriture de ces lignes, au CS7 ! En fait les normes du CS2 ont finalement été publiées en 1998 et ne
seront sans doute jamais implémentées dans la totalité des fonctions prévues. Il existe aujourd’hui des normes
INCS3 et INCS4, très peu différentes des normes INCS2 et qui ne font pas l’objet d’implémentation industrielles.
Le CS1 (capability set 1) regroupe l'ensemble des fonctionnalités de la première étape : Il précise la structure
précise des quatre plans fondamentaux du réseau intelligent avec en particulier :
les types de services à mettre en oeuvre (services de type « A »)
les différentes entités de chacun des plans du modèle.
les protocoles de communication entre les entités fonctionnelles.

Les normes UIT-T du réseau sont référencées selon la nomenclature Q.12XY avec les valeurs de X et Y
indiquée par le tableau de la figure 8 :

X Y
00 Général
10 CS1 1 - Principes, Introduction
20 CS2 2 – Plan Service (pas très défini pour CS1)
30 CS3 3 – Plan fonctionnel global
40 CS4 4 – Plan fonctionnel réparti
50 CS5 5 – Plan Physique
60 CS6 6 – réservé pour utilisation future
70 CS7 7 - réservé pour utilisation future
80 CS8 8 – Spécifications d’interface
90 Vocabulaire 9 – Guides utilisateurs du réseau intelligent

Figure 8 – Nomenclature des normes du Réseau Intelligent

Avec cette nomenclature, il est très facile de déterminer le numéro de la norme applicable à une
problématique de réseau intelligent. Par exemple la norme du plan fonctionnel réparti de L’IN CS2 est
référencée Q1224 (X=2 pour CS2 ; Y=4 pour plan fonctionnel réparti)
Nous recommandons la lecture des guides utilisateurs. Par exemple le document Q1219 (Guide utilisateur de
INCS1) est un excellent document explicatif des méthodes du réseau intelligent.
Aujourd’hui, bien que ces normes soient toujours la référence pour le réseau intelligent, ce sont maintenant
les normes ETSI qui font autorité, au niveau mondial, en matière de Réseau intelligent. Les normes ETSI sont
essentiellement des reprises des normes UIT avec quelques modifications mineures, surtout au niveau du
protocole de signalisation INAP. C’est ainsi que la norme ETS 300 374-1 (Sept 1994) définit INAP pour le CS-1
auquel on se réfère souvent sous le nom de "ETSICORE INAP". Cette norme spécifie les interactions entre la
SSF, la SCF et la SRF. Initialement les interactions avec la SDF n’y sont pas définies. Elle comporte quelques

8
simplifications par rapport à la norme UIT-T Q.1214 (plusieurs opérations sont remplacées par InitialDP et
EventReportBCSM).

3.3. Le plan service Q1212

Le problème auquel s’adresse la spécification Q1212 du plan service est la description des services tels qu'ils
peuvent être vus par un usager du service (Réseau privé virtuel, Numéro vert, télécommunications universelles
personnelles, etc.). Cette vue ne contient aucune information concernant la mise en œuvre des services dans le
réseau. Les services offerts par le RI sont décrits à l'utilisateur comme une composition de services plus
élémentaires appelés "fonctionnalités de services" (Services Features). Les fonctionnalités de services peuvent
être, par exemple, la mise en attente des appels, les annonces personnalisées, etc.
La normalisation définit deux types de services, ceux de type « A » et ceux de type « B ». Les services de
type « A » sont définis par la formule : "single ended, single point of Control, single medium". "Single ended"
signifie qu'ils ne font intervenir qu’une seule patte dans un seul modèle d’appel des différents modèles d’appels
mis en œuvre dans la communication (voir figure 4). "Single point of control" signifie que ces services ne font
intervenir qu’une seule plate forme de service. "Single medium" signifie que la communication n’est pas
multimédia. Nous dirions aujourd’hui qu'un service de type A n’agit que sur une session ne mettant en œuvre
qu’un seul media.
La liste des fonctionnalités de service définie par IN CS1 est donnée par le tableau de la figure :

Abbreviated Dialing (ABD) Customized Recorded Announcement (CRA)

Attendant (ATT) Customized ringing (CRG)
Authentication (AUTC) Destinating User Prompter (DUP)
Authorization Code (AUTZ) Follow-Me Diversion (FMD)
Automatic Call Back (ACB) Mass Calling (MAS)
Call Distribution (CD) Meet-Me Conference (MMC)
Call Forwarding (CF) Multi-way Calling (MWC)
Call Forwarding on Busy (CFC) Off-Net Access (OFA)
Call Gapping (GAP) Off-Net Calling (ONC)
Call Hold with Announcement (CHA) One Number (ONE)
Call Limiter (LIM) Origin Dependent Routing (ODR)

Figure 9 – Fonctionnalités de service de l’INCS1

En se basant sur ces fonctionnalités de service, la norme du plan service donne une liste de services
réalisables selon la technologie INCS1. Le but n’est naturellement pas d’imposer une liste fermée de services en
disant : voila les services de l’INCS1, mais de donn er des exemples de ce qui peut être réalisé avec la
technologie, étant entendu que d’autres peuvent concevoir des services originaux à condition de suivre les
mêmes règles.
La liste de services ainsi définis est indiquée par le tableau de la figure 10

AAB Automatic Alternative DCR Destination Call Routing SPL Split Charging
Billing
ABD Abbreviated Dialling ou FMD Follow-Me-Diversion VOT Televoting
Numérotation Abrégée
ACC Account Card Calling FPH Freephone ou Numéro Vert TCS Terminating Call Screening
CCC Credit Card Calling ou appel MAS Mass Calling UDR User Defined Routing
par carte de crédit
CF Call Forwarding ou Transfert MCI Malicious Call Identification UAN Universal Access Number
d'appel
CCBS Completion of Call to Busy PRM Premium Rate UPT Universal Personnal
Suscriber Telecommunication
CON Conference Calling SEC Security Screening VPN Virtual Private Network ou
Réseau Privé Virtuel
CRD Call Rerouting Distribution SCF Selective Call Forward on
busy / not answer

Figure 10 –Services de l’INCS1

9
 Parmi ces services beaucoup sont très anciens et ne servent que d’exemples pour montrer que la nouvelle
technologie peut également les prendre en compte. Parmi ces services anciens qui existaient déjà dans le réseau
téléphonique nous pouvons citer ABD Numérotation Abrégée, CF Transfert d'appel, CON Conférence, MCI
Identification des appels malveillants.
Par contre de nouveaux services extrêmement innovants apparaissent :
FPH Libre appel ou Numéro Vert (numéros 800). Pour ces appels la facturation est à la charge de l'abonné
demandé. Nous avons déjà dit qu’il s’agit de LA killer application des réseaux intelligents en Amérique.
SEC Security Screening également très utilisé en Amérique par les professions sensibles (avocats, juristes,
médecins) qui souhaitent que les personnes qui les appellent donne un code.
VPN Réseau Privé Virtuel qui constitue une offre majeure des opérateurs pour les entreprises. Les abonnés
de ce service, qui peuvent être raccordés sur des commutateurs publics différents et même appartenant à des
opérateurs différents, communiquent entre eux avec une numérotation abrégée et bénéficient des mêmes facilités
que s'ils étaient raccordés derrière un même PABX. Ce service est une extension de la facilité « CO-Centrex » à
des abonnés répartis sur plusieurs commutateurs publics.
CCC Appel par carte de crédit. Ce service permet d'appeler depuis n'importe quelle ligne en mettant la
facturation à la charge du propriétaire de la carte
UPT La télécommunication personnelle universelle. Ce service dé-corrèle complètement le numéro d'abonné
du poste de téléphone utilisé. Comme pour l'appel à carte de crédit l'abonné au service UPT peut appeler de
n'importe quel poste, mais il peut aussi recevoir ses appels sur n'importe quel poste à condition de s'être déclaré
utilisateur de ce poste par un appel particulier

3.4. Le plan fonctionnel global Q1213

Le plan service indique la ligne à suivre pour concevoir un service. Le plan fonctionnel global donne une
méthode formelle pour décrire le service de manière non ambigüe. Selon cette méthode le service est décrit par
un enchaînement logique d’éléments de description (ou composants) formels réutilisables (éléments de
description indépendants du service) appelés Service Independent Building Blocks SIB. Par exemple le schéma
de la figure 11 décrit le fonctionnement du service AAB (Automatic Alternative Billing).

MATCH
Translate Charge

2 3 4 7 8 Traitement substitutif
User Verify Screen NO MATCH
Interaction
5 GSL
User
Interaction

1 6 9
Appel normal
POI
POI Basic Call Process POR POR
Address Clear Call Proceed
Analysed with New Data

Figure 11 – Description formelle du service AAB

Sur ce schéma nous voyons que l’appel normal s’appelle le BCP (Basic Call Process) et que le service réseau
intelligent ou traitement substitutif démarre à un point de débranchement de l’appel normal appelé Point Of
Initialization POI et qu’il est décrit comme une suite de SIB. Il y a un ou plusieurs points de retour possibles vers
l’appel normal appelés Points Of Return POR. La suite de SIB obéit à la Logique Globale de Service (Global
Service Logic GSL).

Un SIB n’est pas un programme, c’est une description formelle d’activités agissant sur des données. Les SIB
définissent une activité complète avec un point de départ logique et un ou plusieurs points d'arrivées logiques.

10
Les SIB sont définis d'une manière totalement indépendante de toute architecture spécifique du plan fonctionnel
réparti ou du plan physique. Les SIB doivent théoriquement être réutilisables d’un service à l’autre et permettre
de décrire tout service ou toute fonctionnalité de service.
Un schéma générique d'un module SIB est représenté sur la figure 12. Ce schéma montre que les SIB
utilisent deux types de données :
les données d'instance d'appel (CID=Call Instance Data), données de contrôle spécifiques de l’instance
d’appel et effacées à la fin de l’appel, qui sont fournies au SIB par le traitement d'appel (numéro
d'identification d'appel, état des ressources disponibles, etc.)
les paramètres statiques de paramétrage (gestion) du service valable pour tous les appels. Ces paramètres de
gestion sont appelés "données de support de service" (SSD=Service Support Data).

SSD
CID FP (Service Support Data)
(CID Field Pointer)

Début Fin 1
SIB Fin 2
Fin f

CID in CID out

(Call Instance data)

Figure 12 –Service Independant Building Bloc SIB

Treize SIB ont été définies pour le CS1 :

Algorithm (applique un algorithme mathématique à une donnée en entréeeffectue des calculs sur des
chiffres reçus)
Charge (détermine la taxation de l'appel en partie ou totalement effectuée dans le RI
Compare (compare une valeur à une valeur de référence spécifiée)
Distribution (répartit les appels vers différentes fins logiques, selon un algorithme déterminé par
l'utilisateur)
Limit (restreint le nombre d'appels associés à un service RI, via des paramètres spécifiés par l'utilisateur)
Log (consigne en détail les informations relatives à chaque appel dans un fichier, pour une utilisation par
des services de gestion (par exemple statistiques, etc.))
Queue (assure les traitements indispensables à la mise en file d'attente d'un appel (passage facultatif
d’annonces au demandeur en attente, retrait et transmission des appels de la file d'attente lorsque des
ressources se libèrent)
Screen (compare une valeur à celles d'une liste située dans une base de données, pour déterminer si elle en
fait partie. Par exemple : filtrage de numérotations)
Service Data Management (permet au service de rechercher et éventuellement de modifier des données
d'utilisateur situées dans une base de données)
Status Notification (•permet de se renseigner sur l'état des ressources du réseau. Par exemple pour le rappel
automatique sur occupation)
Translate (produit au niveau de la SDF des informations de sortie à partir d'informations d'entrée, en
fonction de différents paramètres. Par exemple traduit un numéro d’appel générique (800 pizza) en numéro
spécifique)
User Interaction (permet à la SCF de diriger la connexion d'un utilisateur vers une ressource spécialisée, de
diffuser une annonce et, dans certains cas, de collecter l'information provenant d'un utilisateur : envoi de
Tonalités, de Messages parlés vers l'usager, réception de chiffres)
Verification (évalue si l’information reçue est syntaxiquement conforme à la forme attendue de cette
information) A ces 13 SIB nous devons ajouter le BCP considéré également comme une SIB.

11
3.5. Le plan fonctionnel réparti Q1214

3.5.1 Environnement d?exécution de service

Le plan service et le plan fonctionnel global étaient concernés par la définition des services. Le plan
fonctionnel réparti (Distributed Functional Plane) définit une architecture fonctionnelle d’exécution de service,
c'est-à-dire des fonctions logicielles appelées "entités fonctionnelles" (FE) constituant un environnement
d’exécution de tout type de service défini en conformité avec les méthodes spécifiées dans les plans supérieurs.
Dans d’anciennes normes, on parlait de SLEE (Service Logic Execution Environment)
Une entité fonctionnelle (FE) est un groupe spécifique de fonctions localisées dans un même emplacement et
constituant un sous-ensemble de toutes les fonctions nécessaires à la fourniture d'un service. Du point de vue de
la répartition des Entités Fonctionnelles dans les Entités Physiques (du plan physique), il est à noter que :
une entité fonctionnelle correspond entièrement à une entité physique spécifique et ne peut donc être
répartie sur plusieurs entités physiques
des entités fonctionnelles différentes peuvent par contre être regroupées sur une même entité physique
toute interaction de deux entités fonctionnelles qui communiquent entre elles est appelée « flux
d'information ». Les relations entre entités fonctionnelles sont donc définies par des flux d'information qui
sont normalisés

SMAF
gestion
SMF
signalisation
SCEF
media

SCF SDF

SRF

SSF SSF
CCAF CCF CCF CCF CCAF

Figure 13 – Architecture fonctionnelle du réseau intelligent

L’architecture fonctionnelle d’exécution de service du réseau intelligent est indiquée sur la figure 13. Dans ce
diagramme, on trouve deux types d'entités fonctionnelles : celles qui sont relatives à l'exécution des services et
celles relatives à la création et la gestion des services. Les fonctions relatives à l'exécution des services sont les
suivantes :
la Call Control Agent Function (CCAF) représente le traitement d’appel d’un PABX RNIS qui traite la
signalisation avec la CCF et qui assure une exploitation de type PABX à l’utilisateur.
la fonction de contrôle d'appel (CCF pour Call Control function). Il s'agit du logiciel de traitement d'appel
des commutateurs.
la fonction de commutation de service (SSF pour Service Switching Function) est la fonction qui détecte que
les critères de débranchement vers un service substitutif sont vérifiés. Cette entité assure l'ensemble des
fonctions nécessaires à l'interaction avec les entités CCF et SCF en particulier la détection des points de
déclenchement du service (d'appels à la SCF) et l'interprétation des commandes de la SCF
la fonction de commande de service (SCF pour Service Control Function) réalise le traitement d'appel
substitutif pour les demandes de services RI. Elle dispose de la logique et de la capacité nécessaires au
traitement des services RI.

12
 la fonction données de service (SDF pour Service Data Function) regroupe les données utilisateurs et réseau
auxquelles la SCF doit accéder en temps réel pour l'exécution d'un service RI.
la fonction ressource spécialisée (SRF pour Service Resource Function) est la fonction de contrôle des
ressources spécialisées (essentiellement des serveurs vocaux) nécessaires à l'exécution des services assurés
par le RI (réception de chiffres, passerelles,...).

Les fonctions relatives à la gestion / création des services sont les suivantes :
la fonction gestion de services (SMF pour Service Management Function) permet l'installation puis
l’exploitation et la surveillance de services RI
la fonction agent d'accès de service (SMAF pour Service Management Access Function) assure l'interface
entre le personnel chargé de la gestion de services et l'entité SMF
la fonction environnement de création de services (SCEF pour Service Creation Environment Function)
permet de définir, créer et tester des services assurés par le RI puis de les transférer dans l'entité SMF

3.5.2 Triggers et Evénements

En plus de l’architecture fonctionnelle d’exécution de service, la norme Q1214 du plan fonctionnel réparti
décrit le mécanisme de substitution de service. Cette description contient donc le modèle d’appel et les graphes
d’état OBCSM et TBCSM des pattes ou connexions demandeuses et demandées que nous avons déjà examiné au
paragraphe 2, nous n’y revenons donc pas. Nous insisterons par contre sur le rôle des DP (Detection Points). Les
DP sont les opportunités de déclencher l’appel à un service réseau intelligent. En effet, normalement les DP sont
"armés" par la gestion, préalablement à l’existence de toute instance de service. Lorsque le programme de
traitement d’appel normal rencontre un DP armé, l’appel au service est déclenché. De tels DP armés par la
gestion sont dits "statiques" dans la norme et nommés "Trigger points".
Au contraire, il est possible, au cours du déroulement d’une instance de service, d’aller armer
"dynamiquement" un DP pour que le traitement d’appel puisse le rencontrer plus tard et renvoyer l’information à
la SCF. De tels DP armés "à la volée" au cours de l’instance de service sont dits "dynamiques" dans la norme et
nommés "Event points" ou "Evénements". Par ce mécanisme nous voyons que les DP constituent également des
événements supervisables au cours du déroulement d’un service. Il y a deux commandes dans la signalisation
INAP qui implémentent cette possibilité : La commande "RequestReportBCSMEvent" permet à la SCF de
demander à la SSF de superviser le passage par un DP déterminé en "l’armant dynamiquement". Lorsque le
traitement passe par un tel DP "armé dynamiquement", il notifiera cet "événement" à la SCF avec l’opération
"EventReportBCSM".

3.5.3 La signalisation INAP

En plus la norme du plan fonctionnel réparti décrit la signalisation INAP (Intelligent Network Application
Part) permettant aux deux partenaires SCF et SSF d’invoquer des opérations dans l’entité distante. Comme nous
l’avons déjà mentionné, la référence qui fait foi actuellement pour l’INAP est la norme de l’INAP produite par
l’ETSI, souvent appelée ETSI Core INAP. Cette norme référencée ETS 300 374-1 (Sept 1994) définit INAP
pour le CS-1, elle quelques simplifications par rapport à L’INAP Q.1214 de l’UIT.

Il y a 29 opérations ETSI Core INAP :dont nous donnons maintenant la liste et une brève description. Cette
liste est très intéressante parce qu’au fond, c’est la liste des 29 choses qu’un commutateur sait faire. En
comparaison, un routeur du réseau internet, machine strictement stateless, ne sait rien faire de tout cela et par
conséquent l’internet ne peut pas être un réseau intelligent ! La norme les classe par ordre alphabétique, nous
préférons ici les classer par types de fonctionnalités
Débranchement du service normal et retour au service normalInitial DP procedure. C’est l’opération qui
déclenche tout! Cette opération est envoyée par la SSF lorsque les critères d’armement sont vérifiés et qu’il
faut donc faire appel à une SCF pour recevoir les instructions nécessaires à l’exécution du service substitutif.
2) Continue procedure. C’est l’opération qui normalement termine le service! Elle demande à la SSF de
reprendre le traitement d’appel normal au point de l’appel où elle avait auparavant suspendu ce traitement
pour attendre des instructions de la SCF. Le traitement d’appel reprend alors son cours normal sans autres
substitutions de données ou d’actions de la part de la SCF.
3) Cancel procedure. Cette opération permet d’annuler une demande de service à une SCF
Demandes de supervisions d?événements et notifications d?occurrence de ces écénements
4) RequestReportBCSMEvent. La SCF demande à la SSF de superviser le passage par un DP déterminé. Ce
passage constituera un événement.
5) Event Report BCSM procedure. Lorsque le traitement d’appel passé par un DP indiquant un événement
dont la supervision a été demandée par une opération RequestReportBCSMEvent la SSF transmet la
notification de l’événement à la SSF. L’opération RequestReportBCSMEvent peut demander la supervision

13
 de plus d’un événement. Chaque événement détecté produira une notification séparée sous forme d’un
EventReportBCSM pour chacun d’eux.

Appels vers des destinations finales

6) Collect Information procedure. Cette operation demande au commutateur de récupérer les informations de
traitement d’appel composées par l’abonné. Elle ne fait pas appel à une SRF.
7) Connect procedure. Cette opération permet de demander à la SSF de connecter l’appel à une destination
déterminée.
8) Initiate Call Attempt procedure. La SCF demande à la SSF de créer un nouvel appel vers une nouvelle
destination.
9) Call Information Request procedure. La SCF demande à la SSF des informations sur un appel en cours.
10) Call Information Report procedure. La SSF répond à la SCF suite à une demande d’informations sur un
appel en cours
11) Release Call procedure. Cette opération permet à la SCF de demander à la SSF le relâchement d’un appel,
à n’importe quel moment de l’appel et pour tous les partenaires de l’appel.

Connexions à des serveurs vocaux, pilotage des serveurs vocaux

12) Connect To Resource procedure. Connexion d’un utilisateur à une SRF.
Establish Temporary Connection procedure. Cette opération permet de demander à la SSF de connecter
l’appel à une SRF (Serveur vocal) dans le cas où la SRF est adressable séparément de la SSF.
14) Play Announcement procedure. Envoi de tonalités ou d’annonces vocales à un utilisateur analogique ou
d’informations alphabétiques à un utilisateur RNIS.
15) Prompt And Collect User Information procedure. Interaction entre un serveur vocal et un utilisateur pour
récupérer des informations
16) Disconnect Forward Connection procedure. Cette opération permet de demander à la SSF de déconnecter
l’appel d’une SRF (Serveur vocal) qui aurait été connectée précédemment
17) Specialized Resource Report procedure. Réponse de la SRF à la SCF pour indiquer qu’une annonce
demandée est terminée.

Mise en place de taxations

18) Apply charging procedure. La SCF demande la mise en place d’une taxation dans la SSF.
19) ApplyChargingReport procedure. La SSF renvoie à la [Link] informations de taxation demandées.
20) Request Notification Charging Event procedure. Demande de supervision d’un événement en vue de
tarification
21) Event Notification Charging procedure. Notification d’un événement en vue de tarification.
22) Send Charging Information procedure. La SCF demande à la SSF d’envoyer des signaux de taxe, par
example des impusions de taxe sur une ligne d’abonné.
23) Furnish Charging Information procedure. La SCF demande à la SSF de générer un ticket de taxe pour
tarification off-line ultérieure.

Contrôle de service
24) Activity Test procedure. Opération utilisée par une SSF pour verifier que sa relation avec une SSF donnée
est bien toujours active
25) Activate Service Filtering procedure. La SCF donne des instructions à la SSF pour traiter certains appels
d’une manière spécifique sans plus d’instructions de la part de la SCF.
Service Filtering Response procedure. Dans le cas où un filtrage de service a été demandé par la SCF,
cette opération permet de renvoyer le contenu de compteurs spécifiés dans la demande de filtrage à la
[Link] Request Instructions procedure. Une SCF qui se rend compte qu’il n’y a pas de serveurs
vocaux (resources spéciales) joignables directement depuis le commutateur d’initialisation du service
redirige l’appel (par une opération Establish temporary connection) vers un autre commutateur duquel on
peut se connecter au serveur vocal. La SSF de cet autre commutateur (Assist SSF) demande des instructions
à la SCF avec l’opération Assist Request Instructions procedure.
28) Reset Timer procedure. Il existe une temporisation dans la SSF pour limiter la durée d’une instance de
service. Par cette opération, la SCF peut relancer la temporisation si elle s’aperçoit qu’elle risque de
déclencher.
29) Call Gap procedure. Cette operation institue un contrôle de flux entre la SCF et la SCF : la SCF demande à
la SSF de diminuer le taux de demandes de service par unité de temps.
3.6. Le plan physique Q1215

14
 Le plan physique du modèle conceptuel du réseau intelligent décrit des scénarios pour implanter les
différentes entités fonctionnelles du plan fonctionnel réparti dans des machines physiques. Le plan physique
correspond donc à l'architecture matérielle d'un réseau structuré en RI. La norme impose de respecter les règles
suivantes :
la même entité physique (machine) peut inclure plusieurs fonctions (entités fonctionnelles)
une entité fonctionnelle ne peut pas être répartie dans plusieurs machines
il est possible d’inclure une même fonction dans des machines de types différents

Le scénario le plus simple, très souvent retenu, consiste à faire correspondre une machine à une fonction.
Dans ce cas la machine est identifié par le même nom que la fonction qu’elle embarque en remplaçant la lettre F
(Fonction) par la lettre P (Point). Il y a une exception notable à cette règle pour la machine embarquant la SRF
(en général un serveur vocal). Il est convenu d’appeler cette machine un "IP" (Intelligent Peripheral). La figure
14 décrit ce scénario.

SMAP SMP
gestion
signalisation
SMAF SMF
médias

SCP SCF SDF SDP

RESEAU DE SIGNALISATION SS7

IP
SRF SSF
SSF
CCF CCF

SSP SSP

Figure 14 – Le scénario le plus simple d’architecture physique du réseau intelligent

Nous indiquons les diverses entités physiques PE (machines) que nous obtenons dans le cas de ce scénario.
Le Commutateur d'Accès au Service (SSP pour Service switching Point) est l'un des commutateurs du réseau
téléphonique, vers lequel l'appel de type RI est acheminé. En général les SSP sont des centres de transit. On peut
penser qu'à terme une majorité des commutateurs du réseau seront des SSP.
Le Point de Contrôle de Service (Service Control Point ou SCP) contient les programmes qui exécutent la
logique du service réseau intelligent. Typiquement, un SCP est composé d'une SCF et éventuellement d'une SDF.
Le SCP est connecté aux SSP via le réseau sémaphore et le protocole de signalisation INAP et peut aussi être
connecté à des IP
Le Point de Données de Service (Service Data Point ou SDP) contient les données utilisées par les
programmes de logique de service pour assurer les services. Typiquement, un SDP contient une SDF et
communique avec des SCP, SMP voire d'autre SDP,
Le périphérique intelligent (Intelligent Peripheral ou IP) contient des ressources matérielles spéciales
nécessaires aux services. Ce sont souvent des Organes Serveurs Vocaux OSV qui permettent d'envoyer des
indications vocales aux usagers d'un service. Typiquement, un IP est composé d'une SRF et est relié à un SSP.
Un IP peut par exemple être un générateur de tonalité, ou une passerelle d'audioconférence.
Le point de gestion de service (Service Management Point ou SMP) effectue les commandes de gestion, c’est
à dire de création de paramétrage, d’exploitation et de supervision des services. Typiquement un SMP contient
une SMF et éventuellement une SMAF. Il peut accéder à toutes les autres entités physiques,
Le point d'accès à la gestion de service (Service Management Access Point ou SMAP) permet aux
concepteurs ou aux exploitants de services d'accéder au SMP.

15
 Le point d'environnement de création de service (Service Creation Environment Point ou SCEP) sert à définir,
élaborer, valider les services RI et à les introduire via le SMP dans les autres machines.
Le scénario que nous venons de décrire est le plus simple. Il existe d’autres scénarios de positionnement des
entités fonctionnelles d’exécution de service dans des machines. Lorsqu’un service obtient un grand succès il
faut équiper dans le réseau de nombreuses plates-formes. Quand on en vient à mettre pratiquement une plate-
forme par commutateur le recours au réseau sémaphore n’est plus nécessaire. Un simple réseau local à haut débit
permet de relier la plate-forme de service au commutateur comme indiqué sur la figure 15. Cette plate-forme de
service locale, qui contient la SCF et la SDF est appelée Adjunct (AD).

SDF AD SDF AD

SCF SCF

SSF SSF
CCF CCF

SSP SSP

Figure 15 – Traitement de service par Adjuncts

Dans le scénario le plus simple ou dans le scénario avec des adjuncts, les appels ne sont jamais routés vers les
plate-formes de services. Ces plates-formes n’interviennent qu’au niveau de la signalisation. Il existe un autre
scénario où l’on décide de réorienter tous les appels qui invoquent un service donné vers un commutateur
spécialisé, qui embarque la fonction de contrôle de service SCF et la SDF dans la propre unité de contrôle du
commutateur. Ce commutateur spécialisé que l’on appelle un Service Node (SN) peut aussi contenir dans son
équipement une SRF. Tous les échanges avec un SN se font donc par l’intermédiaire de circuits du plan
utilisateur.

SDF

SN SCF SRF

SSF
CCF

SSF SSF
CCF CCF

SSP SSP

Figure 16 – Traitement de service par Service Node

Enfin nous pouvons trouver des commutateurs privés PABX ou publics disposant pour un groupe d’abonnés
d’une exploitation privée (CO Centrex) qui embarquent la totalité des fonctions : CCAF, CCF, SSF, SCF, SDF,
SRF. Ces commutateurs tout à fait particuliers s’appellent des "Service Switching and Control Points SSCP".

16
 SDF

SCF SRF

SSF SSF
CCAFF CCF CCF

SSCP SSP

Figure 17 – Traitement de service par SSCP

4 Exemple du déroulement d?un service IN-CS1

Pour illustrer les mécanismes que nous venons de décrire nous prenons l’exemple du service libre appel.
Le but du service est de rendre l'appel gratuit pour l'appelant et de faire supporter la taxation de l’appel au
demandé, abonné au service. Les fonctionnalités de services utilisée pour ce service sont l'appel inversé et la
traduction du numéro 0800.

succès
Traduction Taxation succès
erreur erreur

@ analysée Libération d’appel Passer à de nouvelles données

BCP

Figure 18 – Service Libre Appel. Description dans le plan fonctionnel global

La figure 18 donne la description du service dans le plan fonctionnel global. Les SIB utilisées sont la SIB
traduction (pour traduire le numéro en un numéro routable) et la SIB Taxation (chargé de la tarification de
l'appel).
La SIB traduction : Elle reçoit en CID (Call Instance Data) le numéro de l'appelant et le numéro de l'appelé
0800 PQMCDU (il n'a pas de signification routable). En SSD (Service Support Data), elle reçoit des
données à caractère permanent pour ce service, il s'agit ici de la correspondance 0800 PQMCDU numéro
routable.
La SIB Taxation : Elle reçoit en CID des consignes pour savoir qui s’occupe de la tarification. Cela peut être
le commutateur lui même ou éventuellement la SCF, selon les types d’équipements en place. D’autre part, la
SIB reçoit en SSD le tarif à appliquer et le numéro de l’abonné.

La figure 19 indique les premières étapes pour l’invocation du service : Le traitement d’appel natif du
commutateur se déroule en passant par les PIC de l’OBCSM et du TBCSM. Les services libres appels sont
caractérisés par une numérotation 0800 PQMCDU. La patte de contrôle du service est la patte demandeuse, et
c’est l’OBCSM qui est concerné par le service Libre Appel. La gestion du service a armé le DP3 "Analysed
Information" pour le critère "préfixe = 0800". A l’arrivée dans ce DP, le traitement d ’appel CCF envoie un
trigger request à la SSF et se suspend en attendant la réponse. La SSF, constatant que le critère "préfixe = 0800"
est satisfait, émet la commande "Initial DP" vers la SCF. Cette commande comporte comme paramètre la clé du
service c’est à dire l’indicateur du service libre appel "0800 "

17
 CCF SSF SCF
OBCSM Critères de déclenchement

DP3
Analysed_Information
Type de déclencheur DP3,
VerticalServiceCode VerticalServiceCode
Critère:0800XXXXXX 0800XXXXXX

Invocation du service Initial DP

Libre appel (CallID, verticalServiceCode,0800,
FPH, calling,called)

Figure 19 – Service Libre Appel. Invocation du service

La SCF démarre la logique de service et les étapes sont maintenant indiquées sur la figure 20. Il faut tout
d’abord solliciter la base de donnée pour assurer la traduction du numéro 0800 PQMCDU non routable en un
numéro physique vers lequel l’appel sera routé par la suite. La SCF interroge donc la base de donnée SDF qui
renvoie un numéro routable dans le réseau téléphonique et un numéro d’imputation pour la facturation de l’appel.
La SCF met en place la facturation à la charge du numéro demandé en envoyant la commande INAP Send
Charging Info à la SSF puis demande à la SCF de continuer l’appel vers le numéro demandé avec la commande
Connect. Un trigger notification parvient au CCF en réponse au premier trigger request. Le CCF est alors
capable d’acheminer l’appel

CCF SSF SCF SDF

OBCSM Critères de déclenchement

Initial DP

Seach (File,called)
SIB
Translate
Search result

Send Charging Information SIB

(Numéro d’appelé) Charge

Connect (Numéro d’appelé)

Connect (Numéro d’appelé)

PIC 3

Figure 20 – Service Libre Appel. Exécution du service

En même temps que l’envoi du connect dans la traduction du numéro, la SCF peut envoyer un request report
BCSM Event (DP Answer et DP Disconnect) pour mettre en place la supervision de la réponse du demandé et de
la libération, dans le cas où la taxation est effectuée par la SCF

18