Le Réseau Intelligent :

1 - ce qui est fait actuellement

Fernando Jorge Bade


Le Réseau Intelligent (RI)
est un concept général
d'architecture de commande
des réseaux destiné à
permettre l'introduction
rapide de nouveaux services
en réorganisant de façon
centralisée les fonctions
élémentaires de transport
de l'information (parole,
données, images).
Le Réseau Intelligent :
1 - ce qui est fait actuellement (*)
Le titre du forum “Le Réseau Intelligent,
de la numérisation à l’informatisation des
réseaux” est un peu trompeur car il peut
faire croire que la technique de “Réseau
Intelligent” concerne toutes les évolutions
des réseaux de télécommunications.
S’il est vrai que les réseaux deviennent
de plus en plus complexes, de plus en plus
intelligents, la technique de “Réseau
Intelligent” ne recouvre en fait que
l’architecture des réseaux. Cette technique
ne traite donc pas directement des
techniques de transport, des applications
de gestion des réseaux, ou des services.
Le “Réseau Intelligent” (RI) est un concept
qui n’a rien à voir avec l’intelligence
artificielle ou les réseaux neuronaux.
L’expression “Réseau Intelligent” est en fait
apparue dans le domaine d’architecture
de réseau, et en particulier pour
les réseaux téléphoniques commutés [1].
Cette expression recouvre un certain
nombre de propositions de changement
d’architecture qui visent à permettre
une plus grande facilité d’introduction
de nouveaux services, et donc rendant
le réseau plus sophistiqué, plus “intelligent”.
L’article commence par un résumé des
motivations historiques ayant amené
l’introduction du RI, suivie d’une partie
présentant les grands principes du RI,
selon l’état de l’art de la normalisation.
Ensuite, les parties suivantes traiteront
des sujets techniques de manière plus
approfondie, traitant respectivement :
n du domaine couvert par la “première
phase” du RI, du point de vue des services,
n de l’architecture fonctionnelle du RI,
n des deux types d’interfaces du RI,
l’interface de programmation et l’interface
de commande des ressources.
A chaque fois, les points qui nécessitent
des compléments d’études seront indiqués.
Enfin, la dernière partie traitera des
évolutions possibles de l’architecture
du RI, vers une architecture plus intégrée,
mettant en réseau tout type d’informations
(paroles, données, supervision, gestion...).
L’objectif de cet article est donc d’identifier
et de récapituler l’ensemble des études
qui pourraient être menées pour le RI.
Pour en faciliter la lecture, certaines par-
ties plus techniques, qui peuvent aider
à la compréhension, ont été rajoutées
en petits caractères.
Motivations
historiques pour
le Réseau Intelligent
Les concepts du Réseau Intelligent sont
apparus dans le cadre des études sur
le RTC (Réseau Téléphonique Commuté).
Le RTC est un système réparti
“fruste”
Le RTC est en effet composé de nœuds
(les commutateurs) s’échangeant
un ensemble minimum d’informations au
moyen de protocoles de communication
rustiques (appelés système de signalisation)
basés la plupart du temps sur l’émission
de fréquences. L’utilisation de protocoles
de données plus évolués (le protocole
“numéro 7”) commence à peine. En gros,
cela se borne à l’échange d’une dizaine
de chiffres (le numéro téléphonique de
l’appelé et, pour les réseaux un peu plus
évolués, le numéro de l’appelant).
L’ensemble des données du réseau doit
être géré localement au niveau de chaque
commutateur. La complexité modérée
des données permet aux opérateurs de
maintenir tant bien que mal la cohérence
de l’ensemble, notamment au niveau
des tables de routage.
Le RTC est composé de systèmes
hétérogènes
Le RTC est composé de systèmes
hétérogènes, provenant de fabricants
différents et utilisant des technologies
différentes (électromécanique, électronique
spatial, électronique numérique de première
génération, de seconde génération...).
Cette coexistence de technologies provient
de la durée de vie de ces systèmes
qui est particulièrement longue, souvent
de l’ordre d’une vingtaine d’années, voire
plus. Ceci est bien plus long que les
systèmes informatiques. Ces systèmes
sont en plus coûteux car ils sont très
complexes, impliquant de gros logiciels.
Manque de flexibilité
du RTC
Toutes ces raisons ont fait et font toujours
qu’il est difficile d’introduire dans le réseau
de nouveaux services comme le “numéro
vert” (un numéro spécifique permettant
d’appeler gratuitement, à la charge de
l’appelé). D’une part, le numéro vert doit
être traduit en numéro de destination
réelle par le réseau. Pour cela, il faut
disposer d’informations de traduction
qu’il faut donc stocker dans tous
les commutateurs, ce qui est difficile
(en général il y en a un millier dans un réseau
comme celui de France Télécom ou
de British Telecom). De plus, la mise à
jour de ces données sur tous les
commutateurs s’avère difficile pour assurer
la synchronisation et la cohérence.
D’autre part, pour chaque fournisseur,
les systèmes doivent être modifiés dans
le cadre de paliers logiciels dont le contenu
est limité par la taille des équipes de
développement des fournisseurs.
Typiquement, il y a dans le RTC une nouvelle
version logicielle tous les 18 mois/24 mois.
Il n’est souvent pas possible d’incorporer
un nouveau service dans le palier logiciel
immédiat, étant donné toutes les évolutions
prévues. Il est alors nécessaire de laisser
passer un, voire plusieurs paliers logiciels.
En tenant compte des délais de
développement, ceci montre que
l’introduction de nouveaux services dans
un tel cadre nécessite plusieurs années,
ce qui est de moins en moins acceptable
dans un environnement concurrentiel.
Solution initiale :
centraliser “l’intelligence”
Les premières solutions (américaines)
ont été d’introduire des bases de données
centralisées. En quelque sorte, ce fut
dans le réseau la première tentative
de définition d’une interface indépendante
des systèmes (mis à part les “systèmes
de signalisation” mentionnés plus haut).
Tous les fournisseurs de systèmes furent
priés de permettre l’accès aux bases
de données.
Mais, très vite, cette approche fut considérée
comme insuffisante, car il y avait toujours
le délai de développement de logiciel dans
les commutateurs qui freinait l’introduction
de nouveaux services.
Aussi, naturellement, il fut décidé
de centraliser la logique des services
grâce à une interface de commande des
commutateurs, interface plus ou moins
indépendante des commutateurs. A cette
interface seraient alors connectés des
processeurs contenant à la fois la logique
et les données du service. C’est ainsi
que sont nés les principes du Réseau
Intelligent.
Ces idées ont été appliquées au départ aux Etats-Unis
[2], bien avant le démantèlement d’AT&T (“MaBell”)
qui a eu lieu début 1984. A peu près à ce moment,
le Japon [3] et la France ont commencé à appliquer
ces idées avec des réseaux “PréIntelligents”.
Ce n’est que vers 1988 que les idées sur le RI ont
pris vraiment corps dans le monde. Aux Etats-Unis,
le phénomène s’est produit à l’instigation de Bellcore,
la filiale commune de recherche des sept “Baby Bell”
issus du démantèlement d’AT&T. En effet, AT&T s’était
réservé les services de type RI (appel gratuit 800,
appel par carte de crédit...) générateurs de profits
importants (le chiffre d’affaires se chiffre à plusieurs
milliards de dollars par service). Les “Baby Bell” étaient
donc fortement motivés à fournir ces services.
De même, et à la même époque en Europe, les pays
qui n’offraient pas ces services ont considéré le RI
comme un moyen leur permettant de rattraper
leur retard.
Principes généraux
du Réseau Intelligent
Ce qui suit fait le point sur l’état de l’art
de la compréhension de ce que recouvre
le RI. Le contenu est basé sur les
recommandations approuvées par l’UIT-T
(ex CCITT, organisme de normalisation
pour les télécommunications) en 1992 [4].
Définition du RI
Le terme Réseau Intelligent (RI) est utilisé
pour décrire un concept d’architecture
qui est destiné à être appliqué à tous
les réseaux de télécommunications.
Le RI a pour objectif de faciliter l’introduction
de nouveaux services (des exemples seront
explicités plus loin : les Télécommunications
Personnelles Universelles ou TPU, le
Réseau Privé Virtuel ou RPV, le libre appel...)
en se basant sur plus de flexibilités et
des fonctionnalités nouvelles.
Le terme “service” doit être interprété
dans un sens restrictif : ce sont des
services réseau (de télécommunications),
construits sur des services basiques
de transport d’informations tels que
le transport de la parole, de données ou
d’images vidéo. Cela ne couvre donc pas
la mise en œuvre de ressources physiques
pour les services de transport d’information.
Le lecteur doit bien se garder de confondre
cette approche restrictive du RI avec
le concept plus général lié à l’approche
“serveur-client”, souvent utilisé en
informatique.
Les objectifs du RI
Les objectifs principaux du RI sont :
n de faciliter l’introduction et la modification
de nouveaux services, avec une réduction
importante des délais de développement
associés,
n en même temps, de réduire les coûts
de développement,
n enfin, d’introduire dans le réseau des
fonctions plus sophistiquées, par exemple
pour permettre à l’usager de gérer et
de modifier ses propres données.
L’UIT-T décrit les moyens qui permettent
“de faciliter l’introduction de nouveaux
services” :
n l’architecture doit être indépendante de
la mise en œuvre des services. Cela veut
dire que la mise en œuvre de nouveaux
services ne doit pas impliquer une
modification de l’architecture, ce qui
serait alors coûteux ;
n l’architecture doit être indépendante
de la mise en œuvre du réseau. Cela veut
dire que l’architecture ne dépend pas
de la configuration physique du réseau ni
des systèmes spécifiques des fournisseurs.
L’objectif est de permettre à un opérateur
de réseau de choisir le matériel adéquat
et de ne pas être obligé de redévelopper
un service en cas de changement de
configuration du réseau.
Le champ d’application
du RI
En ce qui concerne les types de services
pouvant être mis en œuvre par le RI,
l’UIT-T indique que le RI doit permettre
une large variété de services utilisant
les moyens de transport existant et à venir
(par exemple ceux qui sont définis dans
le contexte du “large bande” qui concerne
les hauts débits). En fait, il est possible
de distinguer deux types de services :
les services liés au traitement d’appel
(tels que le parcage d’appel, ou
les services de traduction d’adresse
pour l’acheminement des appels) et
les services de gestion de services RI
(tels que la personnalisation du service
par un usager qui peut changer son profil
de service par exemple en modifiant son
numéro de transfert d’appel, ou tels que
la fourniture de statistiques, ou encore
tels que la facturation). La première série
de recommandations de l’UIT-T a traité
en détail les services liés au traitement
d’appel. Beaucoup reste à faire pour
les services de gestion.
De plus, l’ambition est de pouvoir appliquer
les principes de l’architecture du RI à
tout type de réseau. Cela comprend
en particulier : les réseaux téléphoniques
commutés, les réseaux mobiles, les réseaux
de données, les réseaux à bande large.
Ce champ est tout à fait ambitieux. Pour
l’instant, seuls le RTC et (mais de façon
restreinte) le RNIS bande étroite ont été
pris en compte par l’UIT-T. L’application
du RI à d’autres types de réseau de
télécommunication doit être étudiée, car
une architecture unifiée est importante
pour permettre l’interconnexion
des réseaux, et offrir des services sur
plusieurs réseaux (multimédia...).
Les principes
d’architecture
Le RI comporte deux types d’interface
(figure 1), parfois appelés interface A et
interface B. Le premier type d’interface
(interface A) concerne des interfaces de
programmation, qui permettent au réseau
de devenir une sorte de plate-forme
indépendante des services. Il est alors
possible d’introduire des services plus
rapidement sans devoir modifier cette
plate-forme. Le deuxième type d’interface
concerne des interfaces de commande
de ressources (interface B), qui permettent
de contrôler les ressources physiques
de systèmes des divers fournisseurs.
L’existence d’interfaces standards de
contrôle des ressources permet de réduire
les coûts de développement puisqu’un seul
développement commun est nécessaire
pour tous les fournisseurs.
Figure 1 - Principes de l’architecture du RI.
[4] UIT-T. - Recommandations des séries Q120x et Q121x,
- Avril 1992, Genève.
La première phase
du Réseau Intelligent
Dans un premier temps, par souci
d’efficacité, l’UIT-T a restreint son champ
d’application à une liste de services. Cela
ne veut pas dire que seuls ces services
pourront être fournis sur le RI, mais plutôt
que tout services nécessitant les mêmes
capacités pourront être fournis.
L’architecture en découlant a été appelée
CS1 (Capability Set 1). Il est important
de mener des études concernant l’évolution
de cette architecture avec un élargissement
du champ d’application vers les étapes
ultérieures... A terme, une architecture cible
long terme (LTA ou Long Term Architecture)
a aussi été identifiée (voir plus loin, chapitre
“Evolution du Réseau Intelligent”).
Quelques exemples typiques de services :
n le libre appel (“numéro vert” en France,
“800” aux Etats-Unis) : ce service permet
d’inverser la taxation, l’usager qui reçoit
les appels acceptant de prendre en charge
les appels. Ce service permet à un usager
desservi par un tel service d’avoir une ou
plusieurs installations qui peuvent être
atteintes à partir de la totalité ou d’une partie
du pays, à partir de l’étranger si besoin
est, au moyen d’un numéro spécifique
libre appel (05PQMCDU en France,
1 800 xxxxxxx aux Etats-Unis...) ;
n le Réseau Privé Virtuel (RPV) :
ce service permet de construire un réseau
privé en utilisant les ressources du réseau
public. Les lignes des usagers, connectées
physiquement à différents commutateurs,
sont regroupées pour constituer un PABX
virtuel, avec des fonctionnalités PABX
telles qu’un plan de numérotage privé,
le transfert d’appel, la mise en garde...
n les Télécommunications Personnelles
Universelles (TPU) : c’est un service de
mobilité qui permet à son abonné d’utiliser
les services de communications au moyen
d’un unique numéro personnel. Ce numéro
personnel est indépendant du réseau.
Il permet de recevoir des appels de tout
type, éventuellement à travers de multiples
réseaux, pour n’importe quel type d’accès
(fixe, privé, portable ou mobile), et ceci
quelque soit la localisation géographique,
mais dans la limite des capacités L’architecture
fonctionnelles du terminal et des réseaux
traversés.
fonctionnelle du
Dans le futur, un voyageur aura un PC Réseau Intelligent
portable intégrant des fonctions de
téléphonie (fax, téléphone). Dès son arrivée
L’architecture fonctionnelle du RI est définie
dans sa chambre d’hôtel, il sera connecté
très simplement par l’identification d’un
automatiquement par voie radio à sa ligne
certain nombre de fonctions (figure 2),
téléphonique et à son système informatique
qui peuvent physiquement être mises en
habituel. Il pourra alors consulter sa
œuvre sur le même système ou sur des
messagerie électronique, travailler
systèmes séparés. Il y a plusieurs types
normalement comme au bureau, recevoir
de fonctions :
les appels téléphoniques etc...
Ce service, peut-être le service fondamental n les fonctions de transport temps réel
classiques (terminal, commutateur de
de communication dans le futur, nécessite
rattachement, commutateur de transit),
des études pour une unification des diverses
architectures de réseau, comme par n les fonctions temps réel nouvelles
pour le RI (d’une part en adaptant
exemple les réseaux privés, et pour
le commutateur, qui est alors appelé CAS
une interconnexion des réseaux du point
ou Commutateur d’Accès aux Services,
de vue du service offert. Pour l’instant,
d’autre part, les nouvelles ressources aussi
seule une version restreinte du TPU peut
appelées PI ou Périphérique Intelligent),
être offerte par l’architecture CS1 du RI.
n les fonctions de commande du RI
(logique du service, appelée PCS ou Point
Ces définitions ne sont pas standards et montrent
simplement le type de services que le RI peut fournir. de Commande de Services, et Base de
Chaque service possède d'ailleurs de nombreuses données),
variantes et parfois plusieurs définitions différentes
n les fonctions de gestion du RI (gestion
(la définition du RPV donnée en exemple ne correspond
de la logique et des données, accès par
pas à ce qui est fait en France ; l’UIT-T donne trois
les utilisateurs, création des services).
définitions différentes du RVP).
Figure 2 - L’architecture fonctionnelle du RI.
Les nouvelles fonctions nécessitent bien
sûr des études complémentaires :
n l’adaptation des nœuds du réseau
(commutateurs) doit pouvoir se faire pour
tout type de transport (données, large
bande...). Seul pour l’instant le cas du RTC
a été étudié ;
n l’introduction de nouveaux types de
ressources (autre que la “commutation”
avec les Périphériques Intelligents),
comme par exemple la reconnaissance
de la parole, la messagerie vocale,
les convertisseurs de protocoles, doit
se faire selon les mêmes principes pour
que la “logique” puisse commander toutes
les ressources. Les principes de commande
des ressources doivent donc être
approfondis ;
n les fonctions de commande du RI
se rapprochent en fait d’ordinateurs temps
réel commandant les ressources du réseau.
Le problème essentiel est de définir une
interface de programmation, et de
s’interconnecter plus facilement aux
fonctions de gestion ;
n les fonctions de gestion qui sont
fonctionnellement les plus complexes, et
qui doivent coopérer avec les applications
informatiques, ce qui est loin d’être évident.
L’architecture fonctionnelle du RI a été définie au
début de la Recommandation Q1214, à l’aide d’entités
fonctionnelles (EFs) selon la méthodologie Q65 de
l’UIT-T [5]. Les “EFs” peuvent être allouées sur différents
systèmes physiques selon divers scénarios
(Recommandation Q1215).
Le modèle fonctionnel du RI comporte les “EFs”
suivantes (figure 3) :
n CCAF ou Call Control Agent Function : fournit à
l’usager l’accès au réseau. Cette fonction est
une fonction de base du traitement d’appel indépendant
du RI, définie dans les recommandations du livre bleu
de l’UIT-T. Elle peut être localisée dans un commutateur
ou dans certains terminaux sophistiqués tels que
les PABX ;
n CCF ou Call Control Function : fonction qui fournit
les capacités de base pour la connexion du niveau
des services de transport (parole...) (à ne pas
confondre avec le niveau transport des 7 couches
OSI pour les protocoles). Cette fonction est une fonction
de base à laquelle a été rajoutée la fonction de
déclenchement qui permet de traiter les critères pour
savoir si l’appel est du ressort du RI. Cette fonction
est toujours située dans un commutateur soit local,
c’est-à-dire comportant des connexions aux usagers,
soit de transit ;
Figure 3
L’architecture
fonctionnelle du RI
avec les sigles
des Entités
Fonctionnelles.
n SSF ou Service Switching Function : cette entité est
toujours associée à un CCF. Elle permet de converser
avec la logique de service qui va commander
les ressources de commutation. Cette fonction est
fondamentale au RI, car elle fournit une interface
indépendante des services. Par nature, cette fonction
est toujours localisée avec le CCF dans un commutateur
appelé CAS (Commutateur d’Accès aux Services) ou
SSP en anglais (Service Switching Point) ;
n SCF ou Service Control Function : cette entité
fonctionnelle permet d’appeler les fonctions de
commande du commutateur. C’est cette fonction
qui contient les logiques de services. En général,
elle est localisée séparément du CCF, sur une machine
séparé appelée PCS (point de commande de service
ou SCP en anglais). Mais, si les contraintes de
performance l’impose, cette fonction peut être localisée
dans le commutateur pour éviter les délais de
transmission (la transmission se faisant pour le RI du
RTC sur le réseau sémaphore avec des protocoles
numéro sept). Le SCF peut interagir avec d’autres
“EFs” pour accéder à d’autres logiques ou pour
obtenir des informations supplémentaires ;
n SDF ou Service Data Function : cette entité contient
les données associées à l’usager, ainsi que
des données internes au réseau. Ces données peuvent
être accédées en temps réel par le SCF lors de
l’exécution d’un service. Le SDF peut être
physiquement placé avec le SCF ou placé dans
une base de données distante ;
n SRF ou Specialized Resource Function : cette entité
recouvre tout type de ressources spécialisées autres
que les ressources de connexion qui sont dans
un commutateur (par exemple : récepteur clavier,
émetteur d’annonces, ponts de conférence...).
Le SRF est habituellement localisé sur une machine
distincte appelée “Périphérique Intelligent” différent
des commutateurs. En effet, il est en général inutile
de mettre ces ressources au niveau de chaque
commutateur. Dans certains cas cependant
(par exemple les générateurs de tonalité, utilisés
systématiquement pour tous les appels), le SRF sera
localisé dans le commutateur ;
n SCEF ou Service Creation Environment Function :
cette entité est une des plus importantes
de l’architecture du RI. Elle permet de spécifier
(développer), de tester et de déployer des services
sur le RI. Elle s’appuie donc sur l’existence d’interfaces
de programmation. L’utilisation de cette entité
permet de développer la logique de service,
les structures des données du service et
les informations associées aux critères de
déclenchement dans le commutateur ;
n SMAF ou Service Management Access Function :
cette entité fournit une interface entre le SMF et
les gestionnaires de service qui peuvent faire partie
du personnel d’un opérateur ou être un usager ;
n SMF ou Service Management Function :
cette fonction permet de déployer et d’exploiter
un service sur le RI. En particulier, elle a la
responsabilité de déployer les diverses instances
de SCF et de SDF dans le réseau, et de maintenir
la cohérence globale. A ce titre, le SMF contient
en fait la base de données de référence du service.
Des informations statistiques ou de taxation peuvent
être reçues des SCF, informations qui pourront être
mises à disposition des gestionnaires de services,
après un traitement éventuel, à travers le SMAF.
Inversement, les modifications de données demandées
par le SMAF seront répercutées par le SMF vers
les SDF. De plus, le SMF est aussi responsable de la
gestion de tous les éléments du réseau (commutateurs,
périphériques intelligents) pour les aspects spécifiques
du RI. A ce titre, le SMF est en fait relié à tous les
“EFs” (sauf le CCAF).
[5] UIT-T, I130, Q65, Recommandations du livre bleu.

L’interface de
programmation
L’interface de programmation est
évidemment nécessaire pour permettre
un développement rapide des services [6].
Les études à mener concernent
la définition du contenu des interfaces
de programmation aussi bien pour
les services de type traitement d’appel
que pour les services de gestion.
Pour chacune de ces interfaces, il faut
aussi définir la forme physique de l’interface
(langage...). Enfin, il s’agit de mettre en
œuvre ces interfaces sur les systèmes
du réseau. Bien sûr, ces interfaces
de programmation ne peuvent être utilisées
que si les outils logiciels associés sont
développés. L’UIT-T n’a pas véritablement
approfondi ce domaine. Cependant, il a
défini une interface de programmation
logique de haut niveau, logique dans
la mesure où les fonctionnalités de base
sont décrites, qu’il est possible de décrire
leurs combinaisons, mais que ni la forme
réelle de ces fonctionnalités (langage,
paramètres, structures de données...)
ni leur mise en œuvre n’ont été définies.
Il est donc essentiel que cette l’interface
de programmation soit étudiée pour tous
les aspects liés à l’introduction ou à la
modification des services. En particulier,
les fonctions de gestion, qui prennent une
complexité de plus en plus grande, devraient
avoir une interface de programmation.
Cette interface de programmation logique est - User information : permet d’envoyer ou de recevoir,
composée des “SIB” (Service Independent Building Block). et plus généralement d’interagir avec un usager.
Ces “SIB” seront utilisés pour le développement
des services, en définissant au-dessus de l’interface de
Ces “SIB” ne concernent pas le domaine de la gestion.
L’identification des “M-SIB” (M comme Management)
programmation la logique de service ou est un point d’étude particulièrement important pour
service logic (SL). Les “SIB” ont été définis selon les le futur, les services de gestion devenant de plus en
principes suivants : plus complexes.
n le réseau est considéré comme un système
virtuel unique. Aussi, la description d’un service à ce Une fois que le GSL a été spécifié, il doit alors être
niveau est appelée Global Service Logic (GSL) ; transformé (mais l’UIT-T ne dit pas comment, par
n le comportement du réseau est modélisé par exemple au moyen de transformations automatiques)
le BCP (Basic Call Process). Le BCP comporte les POI en logique distribuée, les Distributed Service Logic
(Points Of Initiation) qui permettent de choisir à quel ou DSL. Un GSL est traduit en plusieurs DSL,
moment du traitement d’appel normal et selon quels un DSL par entité fonctionnelle de l’architecture
critères le réseau doit appeler le GSL. Le GSL va fonctionnelle du RI.
alors “commander” le réseau. Le BCP comporte aussi Les “EFs” qui peuvent abriter l’interface de
les POR (Points Of Return) qui sont les points où le programmation sont le SCF, le SDF, le SMF et le
GSL peut “rendre la main” au réseau. Bien entendu, SMAF (ce point n’est pas encore tout à fait clair).
étant donné que le GSL se substitue au réseau entre Les DSL sont des morceaux de logique ayant
le POI et le POR, il est nécessaire que le GSL donne une connaissance de la répartition fonctionnelle
des commandes qui soient en cohérence avec le du réseau. Ensuite les DSL doivent de nouveau être
déroulement normal du réseau. Par exemple, il n’est traduits en programmes physiques (au moyen de
pas possible de demander des informations à compilations et d’éditions de liens, selon les divers
un usager alors que le réseau est en train d’établir systèmes physiques impliqués) en tenant compte de
l’appel vers cet usager. Il faut attendre que la la configuration réelle du réseau.
connexion soit établie. On pourrait comparer l’appel
Il faut noter que l’UIT-T a aussi identifié la possibilité
au GSL à un appel distant de procédure (Remote
pour les usagers de “composer à la carte” des
Procedure Call), mais l’appel au GSL n’est pas de
services à partir d’autres services, appelés alors
même nature car il peut y avoir plusieurs POR pour un
Service Feature. Par exemple le service de filtrage
POI, et il peut y avoir plusieurs interactions ou requêtes
à l’arrivée peut être combiné avec un service
réseau/GSL entre le POR et le POI (par exemple pour
de transfert d’appel, permettant ainsi de ne recevoir
gérer les divers événements du traitement d’appel) ;
que certains appels et de transférer les autres
n l'hypothèse est que les GSL sont décrits par
un enchaînement linéaire de “SIB”, impliquant donc
à sa secrétaire. L’usager a alors l’impression de créer
son propre service. Ce type de possibilité n’est pas
une approche algorithmique et interdisant le
destiné à être standardisé, car chaque opérateur
parallélisme lors d’une instance d’exécution de GSL.
de réseau pourra offrir des variantes. En fait,
Une approche différente telle que l’approche objet
l’usager a choisit un sous-ensemble de l’ensemble
aurait pu être utilisée, mais ceci fut considéré comme
des Service Features qui ont été développés
relevant de l’architecture à plus long terme.
normalement avec l’interface de programmation et
des GSL. L’usager n’a pas définis un GSL, mais
Exemples de “SIB” son profil de service qui est en fait des données.
- Charge : cette brique définit les procédures de taxation Cette procédure est souvent appelée “personnalisation”.
d’un appel en sus ou à la place de la taxation normale
du réseau.
- Compare : donne trois résultats possibles (plus grand,
plus petit, égal).
- Limit : limite le nombre d’appels à un service (ce “SIB”
a donc un contrôle global sur toutes les instances
du GSL).
- Log Call Information : permet de stocker des
informations sur l’appel en cours.
- Queue : permet de parquer l’appel en attendant que
l’appelé soit libre.
- Screen : permet de vérifier la présence d’un identifiant
dans une liste.
- Service Data Management : permet de lire, de créer,
de rajouter ou de supprimer des données (nota : ceci
peut d’ailleurs être temps réel).
- Status notification : permet de connaître l’état ou le
changement d’état de certaines ressources du réseau.
- Translate : traduit des données en entrée selon
des critères applicatifs.
[6] “Créer des services pour le Réseau Intelligent”,
G. Brégant, P. Razol, B. Rommel, congrès DNAC 1992.

L’interface
de commande des
ressources
Les études sur l’interface de commande
des ressources concernent les interfaces
physiques entre “l’intelligence” du réseau
(la logique et les données du réseau) et
les ressources (commutateurs et nouveau
type de ressources). Le point essentiel est
d’assurer une certaine stabilité dans cette
interface : l’introduction d’un nouveau
service ne devrait pas modifier cette
interface, sinon il faudrait modifier
les commutateurs ce qui serait très lourd.
Du point de vue des études, il faut donc
bien définir une vision sur les ressources
qui seront susceptibles d’être introduites
dans le réseau, et faire un exercice
important de modélisation pour garantir
la stabilité de l’interface de commande
des ressources.
n Problèmes identifiés : l’interface de commande En particulier, la définition des états de l’automate
des ressources concerne les relations entre a fait l’objet d’âpres discussions, car chaque
le SCF et le SSF, le SCF et le SRF. La spécification
des interfaces associées n’a pas été une tâche
constructeur devait veiller à ce que son système
puisse émuler ces états. Ce premier modèle
évidente pour plusieurs raisons :
- d'une part, il s’agit d’un problème technique difficile
concerne le CCF et montre les modifications à faire
dans les logiciels actuels des commutateurs.
puisqu’il faut définir une interface générique utilisable Ensuite, il a fallu modéliser le logiciel supplémentaire
pour tous les services de CS1. Il ne faut surtout pas (le SSF en fait), pour montrer que le SSF peut aussi
que l’introduction d’un service RI implique la modification être mis en œuvre. Ceci a aussi été fait avec un seul
de cette interface. En effet, une telle modification automate à états finis. Des études sont encore
doit se faire dans la logique des paliers logiciels nécessaires à ce niveau, car il a été montré que
des commutateurs et est donc très longue à mettre plusieurs automates étaient nécessaires, au moins
en œuvre ; un par usager impliqué dans l’appel, pour permettre
- d’autre part, il s’agit de montrer un modèle de mise une sorte de parallélisme dans l’exécution du SSF.
en œuvre de la fonction SSF, pour démontrer que
n Exemples d’interactions entre le SSF et le SCF,
la réalisation d’une telle fonction est possible. Cette
et le SRF et le SCF : pour plus de détails, le lecteur
démonstration doit prendre en compte le fait que
pourra lire la dernière section de la Recommandation
le réseau est hétérogène, et que différents systèmes
Q1214. La Recommandation Q1218 donne une
peuvent mettre en oeuvre la fonction SSF.
description plus formelle de l’interface entre le SSF et
n Principes du travail de spécification : un travail le SCF en ASN1. Enfin, la Recommandation Q1219
de modélisation des ressources et en particulier donne des conseils d’utilisation de cette interface.
du commutateur a donc été nécessaire, à la fois pour
bien identifier comment les ressources pouvaient être Quelques exemples :
utilisées (et donc définir une interface générique - Initial Request Instructions : le SSF commence
de commande de ressources), et pour montrer que un dialogue de supervision avec le SCF. Le SSF est
le SSF peut être mis en œuvre. alors sous la commande du SCF.
Dès le départ, la question de l’utilisation d’une - Play Announcement : le SCF demande au SRF
approche objet pour la modélisation s’est posée. d’émettre des annonces vers l’usager.
Mais, peut-être par manque de familiarité avec une - Prompt and Collect : le SCF demande au SRF de
telle technique chez les constructeurs, il a été décidé collecter des informations de l’usager au moyen
de prendre une approche classique. On ne peut pas d’un guidage adéquat.
donc dire que le RI soit basé sur une approche objet. - Connect : le SCF demande au SSF de connecter
Cependant, lors du travail de modélisation, l’usager demandeur vers une destination que le SCF
l’identification de certains objets importants a pu être donne en paramètre dans la commande.
faite. Par exemple, il a été possible d’identifier - ApplyCharging : le SCF demande au SSF d’appliquer
les “legs” qui représentent un demi-appel (la partie certaines règles de taxation pour cet appel.
du chemin de parole du commutateur vers un usager) - Monitor : le SCF demande au SSF de superviser
et les “Call” qui représentent la connexion entre 2 ou certains événements et de lui signaler quand un
plusieurs usagers. Un “call” est donc en fait constitué des événements survient.
d’au moins deux “legs” qui ont été connectés - Event Notification : le SSF signale au SCF qu’un
préalablement. Les opérations sur ces objets ont certain événement s’est produit.
même été définies en Europe [7]. Mais, cette approche
n’a pas été adoptée au niveau de l’UIT-T. Cependant,
cette approche sera vraisemblablement adoptée
dans le cadre d’une architecture à plus long terme.
Le principe a donc été de modéliser le comportement
des commutateurs actuels lors du traitement d’appel
basique par un automate à états finis, appelé BCSM
(Basic Call State Machine). Chaque transition, avant
d’être effectuée, fait alors l’objet d’un traitement
supplémentaire pour vérifier s’il ne faut pas interrompre
le traitement et demander des instructions au SCF.
Pour cela, le commutateur possède des informations
(la table de déclenchement) sur les critères
qui peuvent par exemple concerner le contexte
de l’appel (le demandé est occupé...) ou des valeurs
de paramètres (c’est un numéro vert commençant
par 05). Dès qu’un critère est vérifié, il faut interrompre
le traitement d’appel et accéder au PCS indiqué par
la table de déclenchement. Ce modèle a été l’objet
de beaucoup de discussions pour qu’il soit accepté
par tous les constructeurs de commutateurs.
[7] ETSI draft technical report, “Intelligent network:
framework”, ETSI DIR/NA-6001, September 90.
Evolution du
Réseau Intelligent
Une première version du RI, CS1, a donc
été définie. Le travail sur le RI est loin
d’être achevé. Par exemple nous avons
déjà vu que la gestion du RI demande
à être approfondie sérieusement,
notamment en liaison avec les travaux
sur le RGT (Réseau de Gestion de
Télécommunications ou TMN). Mais, il est
possible de distinguer deux domaines
particulièrement importants dans le RI où
il faut mener des études supplémentaires :
n l’interaction entre services, problème
crucial à résoudre pour que les services
fonctionnent correctement,
n l’architecture à plus long terme, pour
tenir compte à la fois des aspects temps
réel, gestion et applications informatiques
associées dans un réseau.
L’interaction
entre services
Il s’agit d’un problème crucial à résoudre
lors de la création de services. En effet,
les services ne peuvent pas être définis
indépendamment les uns des autres. En
fait, il faut toujours spécifier comment un
service donné peut être couplé avec tous
les autres services existants.
Par exemple, un appel libre-appel peut
interagir avec le service de transfert
d’appel. En effet, supposons que l’usager
soit à la fois abonné aux deux services.
Il est donc possible de l’appeler par
un numéro vert. Mais si l’usager a activé
un transfert d’appel pour les appels
qui lui arrivent, faut-il transférer les appels
numéro vert ? Dans l’affirmative, il faut
décider qui va prendre en charge la partie
transférée. Il est donc essentiel que
le créateur de service spécifie comment
son service interagit avec les autres
services existants, à l’aide d’outils logiciels
adéquats.
D’autre part, l’architecture doit posséder
un certain nombre de mécanismes
de résolution d’interaction entre services
(pour résoudre les cas éventuels de
blocage, par exemple avec des algorithmes
de priorité). Le lecteur pourra se référer L’approche orientée objet est une
à [8] pour plus d’informations. des voies prometteuses qui est explorée
actuellement. D’autre part, il est important
L’évolution vers de définir les mécanismes associés
de gestion de données, car les données
une architecture cible imposent des contraintes sur les dialogues
à plus long terme entre applications (il faut bien s’échanger
des informations), et car il faut assurer
Nous avons vu que le travail d’architecture une cohérence globale au niveau
est tout à fait incomplet, puisque du réseau. Le Projet-CNET “SERENITE” a
les aspects gestion n’ont pas vraiment été d’ailleurs exploré cette voie (voir l’article
approfondis. Une architecture plus globale suivant de Jean-Bernard Stéfani [10])
est donc nécessaire pour traiter des
Naturellement, il est nécessaire d’aboutir
aspects gestion du RI, et aussi de l’inter-
à des résultats normalisés pour ce type
connexion aux applications informatiques
de travaux, afin de faciliter le travail des
des opérateurs (telles que la facturation
ou l’affectation des ressources). Il faut constructeurs. Ceci a donc été inscrit
dans le programme d’études de l’UIT-T
aussi permettre l’interconnexion de plusieurs
(LTA, Long Term Architecture).
réseaux. Un besoin essentiel est d’abord
de faciliter l’interconnexion des applications
Pour mieux comprendre les besoins, le lecteur
(de gestion, informatique...). Par exemple,
pourra lire l’article [9]. Cette architecture cible,
il faut toujours s’interconnecter à souvent appelée TINA (Telecommunication Information
une application de facturation ou à Networking Architecture), fait l’objet de nombreuses
une application de supervision du trafic études actuellement. Le lecteur pourra se référer
du réseau. aux articles publiés dans les trois colloques TINA
(en 1990 au Lake Mohonk, Etats-Unis, en 1991
D’autre part, il faut assurer une flexibilité à Chantilly, France, et en 1992 à Narita, Japon, ou
de modification ou d’introduction de en 1992 à ISS92 ,Yokohama, Japon.
nouvelles applications, à tous les niveaux,
- que ce soit au niveau temps réel,
par exemple pour introduire une nouvelle
technologie de transport (par exemple,
le large bande),
- que ce soit au niveau de la commande
du réseau, par exemple pour introduire
la mobilité,
- que ce soit au niveau de la gestion,
par exemple pour permettre à un usager
de modifier certaines données de son
service,
- que ce soit au niveau des applications
informatiques, par exemple pour facturer
un nouveau service,
- que ce soit enfin au niveau des terminaux,
par exemple pour “présenter” à un client,
avec de la valeur ajoutée, les informations
fournies par le réseau (statistiques...).
[8] “Some requirements and techniques for
service interaction in an IN”, J. Muller, P. Razol,
E. Bac, TINA, Chantilly 1991.
[9] “The Intelligent Network in France”, P. Collet,
R. Kung, IEEE communications magazine, février
1992.
[10] “Le Réseau Intelligent : vers l’architecture long
terme SERENITE”, J.B. Stéfani, Forum RI, octobre 1993.
Conclusion
Cet article a décrit le Réseau Intelligent,
domaine d’études de plus en plus important
pour les télécommunications. Les travaux
ne font que commencer, et l’évolution
dépendra des résultats de recherche sur
l’évolution de l’architecture des réseaux.
Les points importants d’études qui ont été
identifiés sont les suivants :
n la définition de l’évolution de la première
phase du RI : ce travail court terme doit
essentiellement tenir compte de la
stratégie d’évolution du réseau ;
n la modélisation des ressources
du réseau : ce travail est important pour
que les nouvelles ressources physiques
(les “périphériques intelligents”) du réseau
se conforment à certains principes,
qui permettent à l’intelligence du réseau
de les commander. L’idée est de ne pas
modifier (ou au minimum) les ressources
de réseau quand un nouveau service
est introduit ;
n l’interface de programmation
du réseau, notamment pour la gestion
du réseau : ce travail est nécessaire pour
faciliter l’introduction des services ;
n le RI et la gestion du réseau :
la gestion a toujours été étudiée “après
coup”. Or la gestion est de plus en plus
complexe, et la valeur ajoutée se situe
de plus en plus au niveau des fonctions
de gestion offertes au client ;
n l’application du RI à d’autres types
de réseau que le RTC, particulièrement
important pour un service comme le TPU
(Télécommunications Personnelles
Universelles) : ce service qui sera
probablement le service du début
du 21e siècle, devra fonctionner sur le RI.
Il s’agit donc d’assurer la prise en compte
des besoins du TPU dans le RI ;
n la compréhension et la résolution
des problèmes d’interaction entre services.
Ce problème peut être un des grands
obstacles du RI car, au fur et à mesure
que le nombre de services augmente,
il devient de plus en plus difficile d’introduire
un nouveau service, du fait de l’interaction
du nouveau service avec tous les services
existants. Il s’agit de bien analyser le type
de service à introduire avec le RI (travail
par exemple sur la typologie des services),
et de trouver des solutions ad hoc pour
résoudre les problèmes d’interaction ;
n l’architecture long terme du RI, dont
l’objectif est d’offrir une flexibilité à tous
les niveaux (temps réel, gestion du réseau,
applications informatiques et terminaux).
L’approche orientée objet, associée à
des études sur la gestion de données,
est l’une des voies étudiées. Le succès
d’une telle approche n’est possible
que s’il y a accord au niveau mondial
(normalisation...).
Les quatre premiers points doivent être
résolus (partiellement) pour le court terme,
tandis que tous les points, sauf le premier,
concernent le long terme.
Pour en savoir plus, le lecteur pourra, en plus
des articles du présent congrès et des références
déjà citées, consulter les articles des congrès
ISS 90 (Stockholm), ISS 92 (Yokohama), ICIN 89 et
92 (Bordeaux), les numéros spéciaux RI de l’IEEE
Communication Magazine de décembre 1988,
février 1992 et mars 1993.