Une Ingénierie d’Architecture pour une évolution trans-génération aux NGNs

Services à commutation de circuits

Nous entendons par un service à commutation de circuit tout service visant à mettre en relation deux ou plusieurs interlocuteurs en vue d’échange d’informations parlées. Le support de transmission de la conversation (bearer) étant un réseau à commutation de circuits, même si le réseau de transmission de la signalisation est un réseau à commutation de paquets. Le réseau téléphonique traditionnel a été l’un des premiers réseaux téléphoniques modernes supportant le service de téléphonie où la logique du service et le traitement d’appel étaient câblés sur les commutateurs. Ce réseau a évolué vers un réseau où la logique du service a été programmable et non câblée sur les commutateurs , les fonctions de traitement d’appels sont mises en liaison à travers un réseau de signalisation, séparant ainsi la logique du traitement d’appel et le réseau de signalisation du réseau de commutation, nommé « réseau sémaphore ». Les nouveaux besoins en terme de rapidité de déploiement de nouveaux services à moindre coût et par n’importe quelle organisation (opérateur ou fournisseurs de service) a mené à la séparation de la notion de service du transport et à la naissance des réseaux intelligents .

Plain Old Telephone Service (POTS/PSTN)

Un des premiers services de télécommunication existant (avant les années 60) est le service de téléphonie traditionnel (Plain Old Telephone Service ou RTC), mixant les flux voix et signalisations dans le même circuit , supportant ainsi tout le service téléphonique par le réseau. Les abonnés sont reliés à un système de commutation d’appels.
Un système de commutation est composé de :
une unité de contrôle : L’unité de contrôle est un composant matériel (câblé) exécutant la logique du service et donc qui fait le traitement d’appel. commutateur de données.
Les systèmes de commutation d’appels sont reliés entre eux full mesh afin d’assurer la connectivité physique entre les abonnés distants. Le service téléphonique POTS était supporté complètement par le réseau téléphonique, en l’occurrence, par les systèmes de commutations. De ce fait, la logique du service était câblée sur les systèmes de commutation. Typiquement, le service et le support étaient liés. Cinq fonctions caractérisaient la logique du service de téléphonie traditionnel, tous câblés sur le commutateur: Présélection, Traduction, Sélection, Taxation et Supervision. L’inconvénient majeur du réseau POTS est que les services et la logique de service étaient câblés dans les systèmes de commutation. De ce fait, l’ajout de nouveaux services fut très difficile. C’est là que les systèmes à base de programmes de contrôles stockés (SPC) ont vu le jour.

Réseaux à programmes de contrôle stockés (SPC)

Comme le service et la logique du service étaient câblés dans le système de commutation, le développement de nouveaux services comme le transfert d’appel et la mise en attente était très coûteux nécessitant le remplacement de tous les systèmes de commutation existants. Les systèmes à base de SPC (Stored Program Control), que nous présentons dans cette section, furent, de ce fait, une avancée technologique importante.
En effet, au milieu des années 1960, les programmes de contrôle stockés (Stored Program Control: SPC) sont introduits pour la fourniture du service téléphonique. SCP est un terme large désignant un commutateur où l’Unité de Contrôle est programmable (non câblée).
Il y a quatre éléments de base dans le système de commutation SPC : la matrice de commutation, la zone d’appel, la zone de programme et le processeur central. A chaque détection d’un nouvel appel, le processeur de contrôle instancie le programme de traitement d’appel à partir de la « zone programme » et ouvre une zone mémoire pour recevoir le numéro d’appel . Il y a autant d’instanciations simultanées et de zone mémoires d’appel que d’appels simultanés. SCP fut une avancée technologique majeure car la logique du service n’est plus câblée sur les commutateurs mais programmable . Par conséquent, il a été plus facile d’introduire de nouveaux services (reconfigurer les services). En effet, ils ont permis de palier le problème d’incorporation de la logique du service dans l’équipement de commutation directement. Néanmoins, le concept de la logique de service n’était pas « décorrélé » du service lui-même. Il était donc toujours aussi difficile d’introduire de nouveaux services à cause de la dépendance entre le service et la logique du service.

La Qualité de Service

Définition de la QoS

La QoS est une notion très usitée et très focale actuellement sur le monde des réseaux de télécommunication. Cette notion offre aux différents acteurs contractants, une manière d’inclure des clauses supplémentaires dans leurs accords, ou de formaliser plus en détail les prestations attendues ou fournies. Cependant, les notions de QoS restent confuses et génèrent de multiples définitions. Cette rançon est due aux énormes enjeux économiques qu’elle laisse entre apercevoir chaque domaine proposant sa propre vision.
chaque constructeur/ « implémenteur » avance ses mécanismes de QoS, ou son implémentation de ces mécanismes. De plus, chaque niveau : réseau, service, etc. propose une vision différente de la QoS. Cet ensemble de définitions rend difficile son étude et sa compréhension.
Parmi toutes ces définitions, celle que nous trouvons la plus globale est celle de la norme E800 : «La QoS se réfère à l’effet global produit par l’exécution (qualité de fonctionnement) d’un service qui détermine le degré de satisfaction de l’usager du service».
D’après cette définition, l’usager final d’un service est le centre de la problématique. Ce qui nous permet de préciser que tout service est le résultat d’un contrat de prestation (explicite ou implicite) par un fournisseur au profit d’un usager. Mais comment caractériser cette QoS? Et avons-nous un moyen cohérent et homogène d’évaluer le degré de satisfaction de l’usager d’un service donné?

Caractérisation de la QoS : le modèle DFDC

Le but de ce paragraphe est d’identifier, à travers les caractéristiques d’un service donné, des critères cohérents et homogènes pour traduire le comportement de ce service. En effet, lorsqu’un utilisateur fait appel à un service donné, il désire que ce service réponde à ces besoins de la manière la plus transparente possible. Nous avons défini trois classes de transparences : temporelle, spatiale et sémantique :
Transparence temporelle : Cette transparence implique que le service doit être capable de traiter les informations à chaque fois que l’utilisateur de ce dernier en produit et aussi longtemps que dure leur génération, le service ne doit pas changer la relation temporelle intrinsèque aux informations générées, c’est-à-dire maintenir le comportement de la source.
Afin de traduire cette transparence, nous avons défini deux critères : Disponibilité qui traduit la première caractéristique, et Délai qui traduit la deuxième.
Transparence spatiale :Cette transparence implique que le service doit traiter les informations générés par l’utilisateur instantanément quelque soit leur volume. Nous traduisons cette transparence à travers le critère de Capacité.
Transparence sémantique :Cette transparence implique que le traitement des informations générées par l’utilisateur se fasse sans les altérer. Nous traduisons cette transparence à travers le critère de Fiabilité. A partir de ces définitions, nous constatons que la Qualité de Service traduit les caractéristiques non-fonctionnelles de tout service, et non pas la meilleure qualité, caractérisant, ainsi, tout service de manière unifiée et homogène.

Modèle d’Ingénierie d’Architecture

A partir des définitions et modélisations que nous avons définies dans le paragraphe précédent, nous pouvons dans ce paragraphe introduire notre concept baptisé : Ingénierie d’Architecture. L’ingénierie d’architecture désigne l’assemblage dynamique des composants d’une architecture à des fins de QoS de bout en bout. Son objectif principal est d’assurer l’adéquation entre les besoins des utilisateurs et l’exploitation du réseau de l’opérateur pour une QoS de bout en bout, tout en tenant compte des contraintes de l’existant afin d’avoir une architecture flexible plutôt que plusieurs architectures (piles protocolaires) rigides.
Nous entendons par architecture la structure d’ensemble, c’est-à-dire, les règles de consistance d’un système (équipements, réseau, service, usagers) d’intégration de ses composants et de leur coopération, qui permettent d’atteindre un double objectif : optimisation et efficacité.
La modélisation proposée pour l’Ingénierie d’Architecture d’un réseau (opérateur, ISP, etc.) est une superposition de couches architecturales englobant différents niveaux en fonction du service à fournir . A chacune d’elles est associée un réseau autonome, une vue abstraite d’un ensemble de nœuds et de liens capables de traiter les problèmes inhérents à son champ de responsabilités (respect du contrat de QoS horizontale) . La façon dont le service de niveau N est rendu au niveau supérieur reste invisible, c’est-à-dire que le service est vu par le niveau supérieur comme un élément indivisible et autonome.
Pour traiter l’ingénierie d’architecture, nous avons retenu les quatre niveaux suivants: équipements, réseau, service et usager. Ces quatre niveaux identifient au mieux les différents acteurs de la chaîne de QoS de bout en bout. Cette QoS, comme expliquée précédemment, est impactée par: les choix de superpositions des blocs architecturaux, le respect du contrat de QoS confié à chaque niveau.
Ces deux points constituent les composantes de base de l’ingénierie d’architecture. Nous attribuons au premier point des capacités de Cohabitation et au deuxième point celles de Coopération .

Ingénierie d’Architecture : les verrous et les clés

Plusieurs contraintes doivent être surmontées pour mettre en œuvre l’Ingénierie d’Architecture. Ces contraintes peuvent être résumées grossièrement en trois points : prendre en compte l’hétérogénéité de l’architecture , maintenir la consistance de l’architecture  et la réduction du temps de réaction de l’architecture .

Hétérogénéité des niveaux architecturaux

Verrou :Le premier verrou à lever est la prise en compte des différents niveaux architecturaux d’un système. La nature des différents niveaux architecturaux d’une architecture est typiquement hétérogène (nœuds et liens de natures différentes), pour le réseau on a une visibilité sur les routeurs et les flux agrégés traversant ce réseau, le niveau service quant à lui représente les éléments de service (composants logiciels distribués) et les flux applicatifs, le niveau utilisateur représente les communautés virtuelles et les besoins utilisateur (requêtes utilisateur/fournisseur). Clé :Afin de gérer cette hétérogénéité de manière transparente, nous devons : Avoir un même modèle de chaque composant dans le réseau pour ne retenir que la représentation commune de ces composants, cette image définit le comportement générique de chaque composant. Pouvoir découvrir chaque composant de manière automatisée.

Consistance et cohérence de l’architecture

Verrou :Le deuxième verrou est la préservation de l’intégrité de la structure d’ensemble. Il s’agit de palier les états inconsistants résultant des échecs et des inefficacités opérationnels lors du processus de déclinaison, comme par exemple, mauvais choix du protocole de transport sous jacent, paramétrage non optimal du classifieur, contradictions fonctionnelles entre les niveaux architecturaux, etc. Une organisation non efficace peut, non seulement, générer une dégradation de la QoS perçue de bout en bout, mais aussi occasionner une panne intermittente du système (nœuds de service, routeur, etc.).
Clé :Afin de gérer cette inconsistance, on doit : Etablir et représenter les règles de consistance d’une organisation, Avoir un feedback sur le déroulement du processus d’organisation, Contrôler/Surveiller le système pour avoir une traçabilité complète et ainsi localiser les points d’inconsistance. Restaurer les états de configuration précédents en cas d’erreur ou d’inconsistance.

Réduction du temps de réaction de l’architecture

Verrou :Le troisième verrou qui est en même temps un objectif à atteindre est la réduction du temps de réaction d’une architecture aux changements internes nécessitant une réorganisation du système. Le processus d’organisation d’une architecture nécessite la structuration des changements (configuration, activation, désactivation, etc.) dans plusieurs éléments hétérogènes. Par exemple, la migration d’un nœud de service nécessite la réorganisation des mécanismes de QoS sous-jacents de façon à ce qu’ils soient activés dans le nœud réseau le plus proche géographiquement du nouveau nœud de service pour maintenir la QoS de bout en bout.
Clé :Afin d’atteindre cet objectif, on doit: Pouvoir découvrir les composants architecturaux (les nœuds), Avoir un retour sur les changements survenant sur l’état du système, Contrôler/Surveiller le système pour avoir une traçabilité complète et ainsi localiser les points de dysfonctionnement. Réagir au plus près du dysfonctionnement, Répondre aux changements de manière événementielle.

Table des matières

INTRODUCTION GENERALE 
CONTEXTE D’ETUDE
PROBLEMATIQUE
CONTRIBUTIONS
CADRE DE TRAVAIL
PLAN DU DOCUMENT
PARTIE I EVOLUTION DE LA QOS DES RESEAUX ET SERVICES DE TELECOMMUNICATION 
INTRODUCTION 
CHAPITRE 1  :EVOLUTION DES RESEAUX ET SERVICES DE TELECOMMUNICATION 
1.1. Services à commutation de circuits
1.1.1 Plain Old Telephone Service (POTS/PSTN)
1.1.2 Réseaux à programmes de contrôle stockés (SPC)
1.1.3 Réseaux à canaux de signalisation commune (Réseaux Sémaphore)
1.1.4 Réseaux intelligents (IN)
1.2. Services à commutation de paquets
1.2.1. Le réseau X.25
1.2.2. FrameRelay
1.2.3. Internet Protocol (IP)
1.2.4. Asynchronous Tranfer Mode (ATM)
1.2.5. MultiProtocol Label Switching (MPLS)
1.3 Conclusion
CHAPITRE 2  :LA QOS DANS LES RESEAUX ET SERVICES DE TELECOMMUNICATION : SUPPORTS EXISTANTS
2.1 Solutions de niveau réseau
2.1.1 Propositions verticales
2.1.2 Propositions horizontales
2.2 Solutions de niveau service/application
2.2.1 Propositions verticales
2.2.2 Propositions horizontales
2.3 Conclusion
CHAPITRE 3  :ANALYSE ET DISCUSSION 
3.1 Support de QoS de bout en bout
3.1.1 Quel bout en bout ?
3.1.2 Interaction verticale
3.2 Temps et coût de déploiement
3.3 Evolutivité
3.4 Synthèse
PARTIE II A LA RECHERCHE D’UNE SOLUTION
INTRODUCTION 
CHAPITRE 4  :L’INGENIERIE D’ARCHITECTURE 
4.1 La Qualité de Service
4.1.1 Définition de la QoS
4.1.2 Caractérisation de la QoS : le modèle DFDC
4.1.3 Evaluation pertinente de la QoS
4.2 Modèle abstrait de service
4.2.1 Le modèle N/L/R
4.2.2 Niveaux de visibilité
4.3 Modèle d’Ingénierie d’Architecture
4.3.1 Cohabitation
4.3.2 Coopération
4.4 Ingénierie d’Architecture : les verrous et les clés
4.4.1 Hétérogénéité des niveaux architecturaux
4.4.2 Consistance et cohérence de l’architecture
4.4.3 Réduction du temps de réaction de l’architecture
4.5 Conclusion
CHAPITRE 5  :DE L’INGENIERIE D’ARCHITECTURE AU PILOTE ORGANISATIONNEL (PORG) 
5.1 Caractéristiques de POrg
5.1.1 Généricité
5.1.2 Distributivité
5.1.3 Réactivité événementielle
5.2 Le modèle Organisationnel
5.2.1 Composants de POrg
5.2.2 Rôles de POrg
5.2.3 Emplacement des agents POrg
5.2.4 Maintien de la QoS horizontale
5.3 Le modèle fonctionnel
5.3.1 Acteurs
5.3.2 Les fonctions de POrg
5.3.3 Processus d’évaluation de la QoS
5.3.4 Scénarii de Déclinaison/Agrégation
5.4 Modèle architectural
5.4.1 Modules d’interaction
5.4.2 Noyau du Pilote Organisationnel
5.5 Conclusion
PARTIE III SIMULATIONS ET EXPERIMENTATIONS AU SERVICE DE L’INGENIERIE D’ARCHITECTURE 
INTRODUCTION 
CHAPITRE 6  :EXTRACTION DES REGLES D’INGENIERIE 
6.1 La plate-forme QoS (intégration verticale) : Les contrats (contexte DiffServ)
6.1.1 Les outils utilisés
6.1.2 La plate-forme matérielle
6.1.3 Extraction des règles d’ingénierie
6.2 La plate-forme QoS (intégration verticale): Les choix
6.2.1 Les outils utilisés
6.2.2 La plate-forme matérielle
6.2.3 Extraction des règles d’ingénierie
6.3 La plate-forme BGP : Intégration horizontale
6.3.1 Les outils utilisés
6.3.2 La plate-forme expérimentale
6.3.3 Extraction des règles d’ingénierie
CHAPITRE 7  :LA PLATE-FORME PILOTE ORGANISATIONNEL 
7.1 Implémentation du simulateur Path-Based Clustering
7.1.1 Environnement de développement
7.1.2 Description du simulateur
7.1.3 Performances de PBC
7.2 Cas d’Utilisations
7.2.1 Le Cas d’Utilisation « Analyse_Messages »
7.2.2 Le Cas d’Utilisation « DB Interact »
7.2.3 Le Cas d’Utilisation « PO Interact »
CONCLUSION GENERALE ET PERSPECTIVES 
CONCLUSION
PERSPECTIVES
PUBLICATIONS
REFERENCES
PARTIE IV ANNEXES 
ANNEXE A CLASSIFICATION DES TECHNIQUES DE CLUSTERING 
A.1 Le schéma de clustering : Hiérarchique vs. Partitionnement
A.1.1 Le clustering hiérarchique
A.1.2 Le clustering par partition (Partitional clustering)
A.2 La construction des clusters : Agglomération vs. Division
A.2.1 L’appartenance d’un élément à un cluster : Exclusive vs. Floue
A.2.2 Prise en compte des éléments à clusteriser : incrémental vs. Non incrémental
ANNEXE B LES PROTOCOLES DE COMMUNICATION : VERS LE MODELE DE COMMUNICATION DE PORG
B.1 Les filtres
B.1.1 Flux de Gestion
B.1.2 Flux de signalisation
B.1.3 Flux Usager
B.2 Classification des protocoles de communications
B.2.1 Protocoles de gestion
B.2.2 Protocoles de control
B.2.3 Protocoles de données

Télécharger le rapport complet