1、UNION INTERNATIONALE DES TLCOMMUNICATIONS5)4 4 ) SECTEUR DE LA NORMALISATION (11/93)DES TLCOMMUNICATIONSDE LUIT2 3%!5 .5- 2)15% !6%# ).4 2!4)/.$%3 3%26)#%3 2.)3 !30%#43 . 2!58 %4 modifie Melbourne, 1988et Genve, 1993)1 IntroductionLe modle de rfrence du protocole RNIS (PRM RNIS) a pour but de dcrire
2、 linterconnexion et lchangedinformations y compris linformation dusager et linformation de commande destination, au travers ou lintrieurdun RNIS.Les entits communicantes peuvent tre: des usagers du RNIS; un usager du RNIS et une entit fonctionnelle dun RNIS, par exemple les dispositifs de commande d
3、urseau; un usager du RNIS et une entit fonctionnelle lintrieur ou lextrieur dun RNIS, par exemple ledispositif de stockage dinformation/traitement/messagerie; plusieurs entits fonctionnelles du RNIS, par exemple un dispositif de gestion du rseau et uncommutateur; une entit fonctionnelle du RNIS et u
4、ne entit situe dans un rseau non RNIS ou rattache un rseaunon RNIS.Le but des communications entre ces entits fonctionnelles est dassurer les services de tlcommunication spcifis dansles Recommandations I.211 et I.212, en fournissant les possibilits RNIS dfinies dans la Recommandation I.310. Ontrouve
5、ra ci-aprs quelques exemples de ces possibilits: les connexions commutation de circuits commandes par signalisation par canal smaphore; la commutation par paquets sur les canaux B, D et H; la signalisation entre usagers et systmes particuliers du rseau (par exemple systmes de recherchedinformation t
6、els que le vidotex; base de donnes dexploitation comme lannuaire); la signalisation de bout en bout entre usagers (qui permet, par exemple, de changer de mode decommunication dans une connexion dj tablie); des combinaisons des possibilits ci-dessus, comme la communication multimdia, qui permet dutil
7、isersimultanment plusieurs modes de communication commands par une signalisation commune.Etant donn ces nombreuses possibilits quoffre le RNIS (en termes de flux dinformation et de modes decommunication), il est indispensable de pouvoir les dcrire toutes dans le cadre dun modle commun qui servirait
8、demodle de rfrence. Cela permettrait didentifier immdiatement les lments critiques de larchitecture du protocole etfaciliterait llaboration de protocoles pour le RNIS et de leurs caractristiques associes. Le modle de rfrence nedfinit pas une mise en oeuvre particulire dun RNIS, ni celle dun systme o
9、u quipement intgr ou connect unRNIS.On trouvera dans la prsente Recommandation des exemples dapplication du modle.2 Principes de la modlisation2.1 Relations avec des Recommandations de la srie X.200Le modle de rfrence du protocole RNIS (PRM RNIS) et le modle de rfrence de linterconnexion de systmeso
10、uverts (RM OSI) (reference model of open systems interconnection) pour les applications de lUIT-T dfini par laRecommandation X.200 prsentent des caractristiques communes et des diffrences.Dans le PRM RNIS, tout comme dans le modle de rfrence OSI, les fonctions de communication sont organises encouch
11、es et les relations de ces couches entre elles sont dcrites.2 Recommandation I.320 (11/93)Toutefois, le champ dapplication du modle PRM du RNIS diffre de celui du modle de rfrence OSI.Le PRM RNIS a pour objet de dcrire les flux dinformation portant sur toute la gamme des services de tlcommunica-tion
12、 dfinis dans les Recommandations de la srie I.200. Il sagit des services supports, des tlservices et descomplments de service. Cette description tient ncessairement compte de caractristiques spcifiques au RNIS qui ne setrouvent pas dans dautres types de rseaux. Parmi celles-ci, on peut citer les typ
13、es de communications multiservices quicomprennent des signaux vocaux, vido, des donnes et des communications multimdias.Le champ dapplication du modle de rfrence OSI nest associ aucun type de rseau1)particulier. En ce sens, il estmoins spcifique que le PRM RNIS. De plus, le champ dapplication du mod
14、le de rfrence OSI est li auxcommunications de donnes et il est donc, cet gard, plus spcifique que le PRM RNIS. Par consquent, le modle derfrence OSI a une application importante et limite pour le PRM RNIS, savoir quil est utilis comme modle pourdcrire les communications de donnes entre des systmes o
15、uverts dans un environnement RNIS.Les champs dapplication correspondants de ces deux modles sont illustrs la Figure 1. Lexistence dune intersectioncommune montre que ces modles coexistent et se chevauchent.T1302810-94/d01Systmes ouverts (OSI)nappartenant pas des RNISSystmes non-OSIappartenant des RN
16、ISEnvironnement OSIRgion dapplicabilitdes protocoles OSI lenvironnement des RNISEnvironnement des RNISFIGURE 1/I.320Applicabilit des protocoles OSI ou RNISFIGURE 1/I.320.D01 = 6.5cmCependant, malgr ces diffrences entre champs dapplication, un certain nombre de concepts et la terminologiecorrespondan
17、te, introduits dans les Recommandations X.200 et X.210, sappliquent pleinement au PRM RNIS. Il sagitnotamment du concept de couche, de service de couche (voir la Recommandation X.200) et des notions de primitive deservice, dentit homologue et de protocole dentit homologue (voir la Recommandation X.2
18、10).On utilise dans la prsente Recommandation, dans la mesure o elles sappliquent, les dfinitions des couches 4 7donnes dans la Recommandation X.200 (les principes de disposition en couches sappliquant aux scnarios qui sonthors du domaine de lOSI, comme la tlphonie, ncessitent un complment dtude).En
19、 ce qui concerne la combinaison des couches 1, 2 et 3, on respecte la somme des fonctionnalits telle quelle estdfinie dans la Recommandation X.200 mais on utilise une mthode de description plus souple pour lattribution desfonctionnalits spcifiques aux (sous-)couches spcifiques. Les couches 1 3, tell
20、es quelles sont dcrites dans laRecommandation X.200, sont remplaces par une strate coiffant une couche infrastructure sous-jacente.Une strate est une structure en couches (gnralement deux) prenant en charge au moins lensemble minimal de fonctionssuivant: dans la couche rseau de la strate: routage et
21、 relais, connexion du rseau; dans la couche liaison de donnes de la strate: connexion des liaisons de donnes, mise en squence etautres fonctions damlioration de linfrastructure. Cette couche est conue comme une couchedadaptation, qui adapte les services dinfrastructure aux services de transfert de d
22、onnes du rseau._1)Il convient de noter que le terme rseau dans le RNIS correspond sous-rseau dans la terminologie OSI.Recommandation I.320 (11/93) 3Par ailleurs, pour complter la structure: au niveau de la couche infrastructure: connexions dinfrastructure, identification des connexionsdinfrastructur
23、e. La couche infrastructure peut tre soit la couche physique OSI, soit une connexion rseaudun rseau sous-jacent.La couche infrastructure est la couche la plus basse de la structure. Quand cela est requis pour des besoins demodlisation (telle que la modlisation de rseaux recouverts), la couche infras
24、tructure peut tre reprsente elle-mmecomme une autre strate ayant sa propre structure en couches et coiffant une couche infrastructure dordre infrieur, sous-jacente. Cette procdure rcursive peut tre applique autant de fois quil le faut.Il convient de noter quune strate peut tre une concatnation de so
25、us-rseaux au sens de lOSI.La Figure 2 est la reprsentation graphique des principes de stratification, montrant galement la nature rcursive de lastructure. Il faut noter que le concept de strate sapplique uniquement au niveau de la couche rseau ou au-dessous.123232311T1302820-94/d02StrateFonction de
26、mise en correspondanceCouche infrastructureVue abstraiteVue dtailleFIGURE 2/I.320Principe de la stratificationFIGURE 2/I.320.D02 = 7.5cmLes lments suivants, indispensables au RNIS, doivent tre spcifiquement examins dans le cadre de la prsenteRecommandation: flux dinformation pour le processus de com
27、mande de communications hors bande ou, plus gnralement,flux dinformation entre plusieurs protocoles apparents; flux dinformation pour le choix des caractristiques de connexion; flux dinformation pour la rengociation des caractristiques de connexion des communications; flux dinformation pour la suspe
28、nsion des connexions; flux dinformation pour envoi avec chevauchement; flux dinformation pour communications multimdias; flux dinformation pour connexions asymtriques; flux dinformation pour la gestion du rseau (par exemple passage sur voie de secours et retour sur voienormale) et pour les fonctions
29、 de maintenance (par exemple, les boucles dessai); flux dinformation pour linterfonctionnement de lactivation/dsactivation de lalimentation en nergie; commutation des flux dinformation; nouvelle dfinition de service de couche pour les services autres que la communication de donnes; application des s
30、ystmes autres que des systmes dextrmit, par exemple les points de transfert dusignal et points dinterfonctionnement entre rseaux;4 Recommandation I.320 (11/93) flux dinformation pour les connexions multipoint; flux dinformation pour des applications telles que:i) voix (y compris la conversion loi A/
31、loi m) ;ii) transmission dimages animes;iii) flux dinformation transparent;iv) tlex.2.2 Plan de commande, plan dusager et blocs de protocole Plan PRM Un plan PRM est compos de blocs de protocole de mme type au sein dune certaine strateappartenant deux ou plus de deux systmes connects ayant une relat
32、ion dhomologue homologueclairement dfinie. Bloc de protocole Cest une pile stratifie dentits de protocole avec groupe fonctionnel unique. Bloc de protocole dusager Cest un bloc de protocole dont la tche exclusive est le transfert transparentdes informations dusager. Bloc de protocole de commande Ces
33、t un bloc de protocole ayant la tche exclusive de prendre encharge la signalisation du RNIS.Au moyen des termes dfinis ci-dessus, le plan dusager et le plan de commande peuvent tre dfinis de la maniresuivante: Plan dusager Un plan dusager du modle PRM est constitu de blocs de protocole dusager. Plan
34、 de commande Un plan de commande du modle PRM est constitu de blocs de protocole decommande.La principale raison dtre des protocoles lintrieur du plan dusager est le transfert transparent des informations entreles applications dusager.Le besoin de transparence dun service est donn par la valeur de l
35、attribut intgrit de lunit de donnes de ce service(voir la Recommandation I.140).Dans certains cas, cela signifie que le flot binaire brut (ou le flot brut de chanes binaires dlimites) doit passer sansmodification de lorigine la destination, comme cest gnralement le cas dans la transmission de donnes
36、.Toutefois, dans certains autres cas, ce besoin de transparence nest requis que pour la smantique du flot de bits (ou dechanes binaires) plutt que pour le flot de bits (ou de chanes binaires) proprement dit. Le transfert de signaux vocaux,par exemple, ncessite ventuellement un recodage de linformati
37、on (au moyen de la loi de conversion A/loi m parexemple) de telle manire que le flot binaire soit modifi mais que sa smantique (autrement dit la voix) soit prserve.La principale justification des protocoles mis en oeuvre dans le plan de commande est le transfert dinformations par lacommande des conn
38、exions dans le plan usager, par exemple: commande dune connexion de rseau (comme ltablissement et la libration); commande de plusieurs connexions de rseau pour les appels multimdias; commande de lutilisation dune connexion de rseau dj tablie (par exemple un changement descaractristiques de service p
39、endant une communication comme dans lalternat tlphonie/dbit 64 kbit/ssans restriction); fourniture de complments de service.Outre linformation dusager, toutes informations qui commandent lchange de donnes dans une connexion sansmodifier ltat de cette connexion (par exemple contrle de flux), relvent
40、du plan dusager. Toutes les informations decommande qui entranent une attribution ou une rattribution de ressources par le RNIS relvent du plan de commande.2.3 Signification locale et globaleLe transfert de linformation dans le plan de commande peut avoir une signification locale ou une significatio
41、n globale.a) Signification locale Linformation de commande passe travers une interface particulire (cest-direlinterface de dpart, linterface darrive ou une interface entre deux noeuds de rseau adjacents).b) Signification globale Linformation de commande na pas de signification locale.Recommandation
42、I.320 (11/93) 5A titre dexemple, du point de vue de lusager du RNIS: lensemble du service qui doit tre fourni aux usagers a une signification globale; la commande des ressources mettre en oeuvre linterface usager-rseau a une signification locale;et du point de vue du rseau: lensemble du service qui
43、doit tre fourni par le RNIS (types de connexion RNIS spcifis dans laRecommandation I.340) a une signification globale; le traitement des lments des connexions a une signification locale.Selon leurs spcifications fonctionnelles, les complments de service ont une pertinence locale ou globale. Par exem
44、ple: le rappel automatique sur abonn occup (CCBS) ou la signalisation dusager usager (UUS) (user-to-user signalling) ont une signification globale; lindication dappels en instance a une signification locale.Linformation globale se rpartit en trois catgories:1) linformation est transmise en transpare
45、nce;2) linformation peut tre traite mais reste inchange (par exemple tlservice);3) linformation peut tre modifie (par exemple numro de destination en relation avec les complments deservice de libre appel ou de renvoi dappel.3 Le modleLe modle de rfrence pour le protocole (PRM) (protocol reference mo
46、del) RNIS est reprsent par un bloc deprotocole (voir la Figure 3). Sa description est complte par la notion de signification introduite ci-dessus.Un tel protocole permet de dcrire divers lments situs dans des locaux dusager et dans le RNIS: quipement terminal(TE) (terminal equipment), terminaison de
47、 rseau (NT) (network termination) dautocommutateur priv intgration desservices, terminaison de commutateur (ET) (exchange termination), point de signalisation (SP) (signalling point) et pointde transfert de signalisation (STP) (signalling transfer point), etc.3.1 Bloc de protocole gnriqueLes principes de division en couches sappliquent aux plans de commande et dusager; chaque plan peut ventuellementaccueillir une pile de 7 couches de protocole. La fonction de gestion de plan reprsente la Figure 3 effectue des tchessimilaires celle
