Réseaux Intelligents

La conception des Réseaux Intelligents (RI) était la première étape vers des réseaux riches en fonctionnalités. Les premiers standards sont apparus dans les années 90. L'ob- jectif essentiel des RI était de séparer la commutation qui se fait au niveau des commu- tateurs réseaux du traitement de la logique d'appel qui s'exécute dans une plate-forme de services. Dans cette section, nous commençons par décrire les dimensions archi- tecturale et fonctionnelle de cette approche (voir Sous-Section 3.1.1.1). Ensuite, nous

POI Basic Call Process POR (ex. Proceed with New Data)

POR (ex. Clear Call)

SIB1 SIB4 SIB2 SIB5 SIB3 Traitement Substitutif GSL Appel de base

Fig. 3.1: Plan fonctionnel global des Réseaux Intelligents.

discutons ses principaux dés (voir Sous-Section 3.1.1.2).

3.1.1.1 Description architecturale et fonctionnelle des RI

Les RI ont été décrits selon plusieurs approches. La première considère le concept des RI comme un dispositif supplémentaire à l'architecture de commutation existante. Dans ce cas, les RI sont vus comme une collection de serveurs qui exécutent des fonc- tions spéciales de contrôle. La deuxième approche ne voit pas les RI comme un ensemble de n÷uds ; elle les considère plutôt comme une architecture de logiciels qui exécutent des services. An d'homogénéiser les diérents points de vue, l'ITU (International Te- lecommunications Union) standardise un modèle conceptuel, noté INCM (Intelligent Network Conceptual Model). Ce dernier réconcilie les approches physiques et logiques de l'architecture des RI. Pour ce faire, l'INCM est répati sur quatre plans de vision [28][40][52] : le plan de services, le plan fonctionnel global, le plan fonctionnel distribué et le plan physique.

Le plan de services est le plan supérieur de l'INCM. Il décrit, selon le point de vue de l'utilisateur, des services par un ensemble de caractéristiques, nommées Service Elements Features, sans préciser comment ces services sont implémentés dans le réseau. En eet, chaque caractéristique est vue comme une fonctionnalité réutilisable. L'idée clé des RI est donc de standardiser un ensemble de fonctionnalités (ex. Call forwarding, Authentication, Call limiter, etc.) qui seront réutilisées par les opérateurs de réseaux an de composer leurs services.

Le deuxième plan dans l'INCM est le plan fonctionnel global. Il s'interface, au niveau architectural, juste au dessous du plan de services an d'ajouter la vision des fournis- seurs de services. En eet, le plan fonctionnel global décrit le service par une séquence de composants réutilisables, nommés SIBs (Service Independent Building Blocks). Ces derniers ne sont pas des programmes, mais plutôt des descriptions formelles d'activités agissant sur des données (ex. le numéro appelé, la Black list, etc.). Cette séquence de SIBs obéit à la logique globale de service, notée GSL (Global Service Logic), et repré- sente le traitement substitutif exécuté par le RI par rapport à l'appel normal, noté BCP (Basic Call Process). Pour atteindre ce but, chaque SIB est muni d'un point logique d'initialisation, noté POI (Point of Initialization), et de plusieurs points logiques de

retour, notés POR (Points of Return). Par conséquent, comme le montre la Figure 3.1, lors d'un processus d'appel normal, BCP est interrompu par un processus substitutif. Ce dernier est déclenché par un POI (ex. Adresse analysée, Pas de réponse, etc.), puis exécuté par une séquence de SIBs selon une logique GSL bien déterminée. Une fois ce processus terminé, le service rend le contrôle au BCP. Le retour à l'appel normal pourra se faire par plusieurs types de POR (ex. Termine l'appel, Continue avec de nouvelles données, etc.). D'après les standards des RI, il y a 20 SIBs qui sont dénis : algorithm, authenticate, charge, compare, distribution, log call information, queue, screen, service data management, service lter, translate, user interaction, verify, BCP, BCUP, split, join, initiate service process, end, message handler.

D'après la standardisation CS-2 (Capability Sets - 2 ), le processus de service sub- stitutif n'est plus limité à une seule séquence de SIBs. En eet, lors de l'exécution d'un service RI, plusieurs processus peuvent être déclenchés en parallèle et peuvent ainsi communiquer par des messages. De plus, CS-2 améliore le concept de SIB en dénis- sant un modèle récursif pour la création de services. Ce modèle classie les SIBs sur diérents niveaux de granularité. Pour ce faire, il diérencie une opération SIB d'un SIB de haut niveau. La première représente une opération de base qui ne peut pas être décomposée en d'autres composants. Quand au SIB de haut niveau, noté HLSIB (High- Level SIB), il est décomposable en un ensemble d'opérations SIB, des SIBs normaux ainsi que d'autres HLSIBs.

Le troisième plan selon l'INCM est le plan fonctionnel réparti. Il s'interface, au ni- veau architectural, juste au dessous du plan fonctionnel global, an de donner une vision plus réelle du réseau. En eet, le plan fonctionnel réparti dénit un ensemble d'entités fonctionnelles qui servent à l'exécution de tout type de service déni en conformité avec les méthodes spéciées dans les plans supérieurs. Le plan fonctionnel décompose les entités fonctionnelles en deux parties : celles qui permettent l'exécution des services RI et celles qui assurent la création et la gestion des services RI.

Nous citons ci-dessous quelques fonctions relatives à l'exécution des services RI :

 CCAF (Call Control Agent Function) : elle représente l'accès d'un utilisateur aux processus d'appel et de service. Elle supporte l'accès à des interfaces existantes comme les lignes téléphoniques analogiques, l'appel vers un réseau numérique à intégration de services, etc.

 CCF (Call Control Function) : elle contrôle l'état d'un appel. Par exemple, elle lance une alerte pour une ligne occupée.

 SSF (Service Switching Function) : Elle vérie si les critères de débranchement vers un service substitutif sont vériés. Elle initialise ainsi la logique globale de services et interprète les commandes de la SCF.

 SCF (Service Control Function) : elle exécute le traitement substitutif et contrôle sa logique de services.

 SDF (Service Data Function) : elle représente la base de données que doit utilisée la SCF en temps réel an d'exécuter un service RI.

 SRF (Specialized Resource Function) : elle contrôle des ressources spécialisées (essentiellement des serveurs vocaux) nécessaires à l'exécution des services RI. Nous citons ci-dessous quelques fonctions relatives à la gestion des services RI :

 SMF (Service Management Function) : elle assure toutes les fonctions de ges- tion des services, comme l'installation des services RI, ajouter ou supprimer des abonnés, etc.

 SMAF (Service Management Access Function) : elle assure une interface d'accès (ex. Internet) entre le personnel chargé de la gestion de services et la SMF.

 SCEF (Service Creation Environment Function) : elle permet de dénir, créer et tester des services RI puis de les transférer vers la SMF.

Le dernier plan de l'INCM est le plan physique. Il permet d'allouer des machines physiques pour les diérentes entités fonctionnelles du plan fonctionnel réparti. Le plan physique correspond donc à l'architecture matérielle d'un réseau structuré en RI. 3.1.1.2 Dés des RI

La technologie réseau intelligent était la première tentative à introduire la notion de services. Pourtant, elle n'a pas pu poursuivre son avancement pour plusieurs raisons. Premièrement, cette technologie a rendu intelligent le processus d'appel, mais elle a eu du mal à s'exprimer dans des nouveaux environnements où la compréhension et la maîtrise des nouveaux concepts sont primordiales. Par exemple, la communauté des développeurs a mal interagit avec cet avancement technologique. Le deuxième problème des RI correspond à l'utilisation non adéquate du SIB. En eet, un SIB, selon le plan fonctionnel global, est un automate qui exécute une opération logique dans la logique de services. Donc, c'est l'opérateur et non pas l'opérande (la donnée) dans cette opération. En outre, selon son nom qui porte à confusion, les Service Independent Building Blocks ne sont pas des Blocks au sens composants de services, mais plutôt des descriptifs qui aident à la construction (Building) des blocks de services. Vu que la majorité des industriels ont mal compris ce principe des SIBs, ils ont mis en cause la réutilisation d'un même SIB dans plusieurs services diérents et ils ont considéré ainsi que le nombre de SIBs normalisés était limité. Pour cela, chacun a commencé à dénir ces propres SIBs ce qui a mené au bout d'un an à réaliser 90 SIBs. Cette liberté de création non normalisée a abouti à des implémentations RI propriétaires qui nécessitent un coût et un eort très élevés pour garantir leur interopérabilité. Enn, à l'aide des SIBs, les RI ont pu décrire l'enchaînement logique et ils l'ont associé à un ensemble de services au niveau applicatif. Cependant, la mauvaise dénition des éléments de services au niveau du plan service, et la manque de normalisation des règles de composition de services et de structure ont causé des problèmes d'interaction et de portabilité des composants, et par conséquent des nouvelles défaillances pour l'approche RI.