ARCHITECTURES DE SERVICES

AVANCÉES
LES RÉSEAUX NGN

3ème Télécoms (I3C) Mohamed ESCHEIKH

 ISUP
2

 ISUP: protocole de signalisation n°7 qui fournit les fonctions de signalisation

nécessaires à la prise en charge des connexions dans les réseaux à
commutation de circuits nationaux et internationaux : établissement / libération de
circuits et supervision (blocage / déblocage / interrogation / réinitialisation) de
circuits.
 ISUP peut être utilisé dans des réseaux RNIS, des réseaux analogiques ou
encore des réseaux mixtes analogiques / numériques.
 ISUP supporte un ensemble de services complémentaires qui enrichissent l’appel
de base
 Procédure d’établissement d’appel
3
 Procédure de libération d’appel initiée
par l’appelant
4
 Services complémentaires ISUP
5

 Ces services sont pris en charge par le CAA (commutateur d ’accès) avec ISUP :
 Signal d'appel (CW, Call Waiting)
 Transfert de communication (CT, Call Transfer)
 Présentation d'identification de la ligne appelante (CLIP, Calling Line Identification
Presentation)
 restriction de la présentation de la ligne appelante (CLIR, CLIP Restriction)
 Communication conférence (CONF, Conference)
 Mise en garde (HOLD)
 Rappel automatique sur occupation (CCBS, Completion of Calls to Busy Subscriber)
 Renvoi d ’appel inconditionnel (CFU, Call Forwarding Unconditional)
 Renvoi d ’appel sur occupation (CFB, Call Forwarding Busy)
 Renvoi d ’appel inconditionnel sur non-réponse (CFNR, Call Forwarding No Reply)
 ISUP
6
 CAP (CAMEL Application Part)
7

 CAMEL (Customized Applications for Mobile network Enhanced Logic) reprend

les principes de base du Réseau Intelligent (cf. tutoriel EFORT Réseau
Intelligent) en y apportant une dimension mobile.
 La mise en œuvre des fonctionnalités CAMEL dans les réseaux mobiles permet
de proposer en itinérance des services en mode prépayé, réseau privé virtuel,
et des services de numéros courts (accès à la messagerie vocale, au service
clientèle)
 MAP
8

 Le protocole MAP (Mobile Application Part) régit l’ensemble des échanges

entre équipements du réseau mobile (NSS, Network Subsystem).
 Il offre les fonctions de signalisation nécessaires à un service de communication
voix ou données dans un réseau mobile.
 Il a principalement trait à toutes les fonctions qui permettent à un mobile d’être
itinérant. Il s’appuie sur la pile de protocole SS7 qui garantit un transport
fiable.
 Le protocole MAP concerne les dialogues entre différentes entités du réseau
mobile notamment, MSC/VLR, MSC Server, SGSN, HLR, EIR, SMSC, etc.
Enregistrement du mobile au domaine circuit
9
 Handover inter-MSC
10
 Routage d’un appel entrant à un mobile
11
 Envoi d'un SMS à un destinataire joignable
12
 Appel entrant vers un abonné en roaming
international ayant souscrit au service prepaid
13
 Appel entrant vers un abonné en roaming
international ayant souscrit au service prepaid
14

 Considérons un appel entrant à destination d’un abonné Orange France ayant souscrit au service prepaid et
actuellement en roaming à Londres:
 1. Un abonné fixe numérote "0608905223"; l'appel est acheminé via le protocole ISUP (message ISUP
IAM) vers le GMSC le plus proche du Class 5 Switch auquel est rattaché l’appelant. Ce GMSC appartient
à l’opérateur Orange France auquel le destinataire est abonné.
 2. Le GMSC interroge le HLR (requête MAP-Send-Routing-Information) contenant l’enregistrement de
l’usager mobile destinataire, pour connaître la localisation du mobile. Le HLR vérifie si l’usager appelé est
dans un réseau visité ou dans son réseau nominal. Grâce au Global Title (adresse SS7) du MSC/VLR
auquel est rattaché l’appelé (cette information est présente dans le profil de l’appelé), le HLR peut
déterminé si l’usager est dans un réseau visité. Si tel est le cas, le HLR vérifie s’il existe un T-CSI
concernant cet usager, et le retourne au GMSC. Si par contre l’usager est dans son réseau nominal, alors
le HLR retourne un MSRN au GMSC..
 3. Le HLR ne retourne pas le MSRN comme attendu par le GMSC mais il retourne le T-CSI dans une
réponse MAP-Send-Routing-Information-ack. Ce T-CSI indique qu’il faut invoquer le service prepaid
depuis le DP12 Terminating_Attempt_Authorised.
 4. Le gsmSSF émet un flux d’information Initial DP au gsmSCF pour activer le service prepaid.
 Appel entrant vers un abonné en roaming
international ayant souscrit au service prepaid
15

 5. Puisque le crédit de l’usager est positif, le gsmSCF retourne le flux d’information Continue demandant au
gsmSSF d’établir l’appel vers la destination ainsi que le flux d’information RequestReportBCSMEvent pour
demander à l'entité gsmSSF de surveiller les événements début de communication et fin de
communication, i.e., T-Answer et TDisconnect.
 6. Le GMSC renvoie une requête MAP-Send-Routing-Information au HLR contenant le paramètre
"suppress T-CSI". Ce paramètre permet d’indiquer au HLR de ne pas retourner une seconde fois le T-CSI.
 7. Le HLR doit retourner un numéro de MSRN (numéro de réacheminement) que le HLR va demander au
VLR à travers la requête MAP-Provide-Roaming-Number.
 8. Le VLR fournit au HLR un numéro de MSRN de la forme +44 20 7258 6880 (réponse MAP
Provide_Roaming_Number_ack).
 9. Le HLR retourne le numéro de MSRN au GMSC (réponse MAP-Send-RoutingInformation-ack). La
première partie de ce numéro est utilisée pour joindre, à travers le RTCP international, le MSC où se trouve
actuellement le mobile. Dans notre exemple, c'est le préfixe +44 20 72 du MSRN qui permet de joindre le
MSC où est localisé le mobile.
 Appel entrant vers un abonné en roaming
international ayant souscrit au service prepaid
16

 10. Le GMSC relaye le message ISUP IAM au MSC concerné (celui auquel est rattaché le mobile
destinataire) via le RTCP. Le numéro de destination dans le message ISUP IAM est le MSRN.
 11. Le VLR gérant la zone de couverture radio de ce MSC retrouve, par le MSRN, l'identité du mobile
demandé. Par une opération de "Paging", sur toutes les BTS de la zone de localisation, le BSC (à la
demande du VLR), appelle le demandé par son TMSI. Le mobile "en veille" ainsi appelé se signale dans la
cellule qu'il occupe.
 12. Le MSC retourne un message ISUP ACM.
 13. L’appelé décroche ; le MSC retourne un message ISUP ANM.
 14. Le gsmSSF notifie par un flux d’information Event Report BCSM l’événement début de communication.
Le gsmSCF commence à décrémenter le crédit de l’usager.
 15. Si l’appelant ou l’appelé raccroche, le gsmSSF notifie par le flux d’information Event Report BCSM, la fin
de communication afin que le gsmSCF arrête de décrémenter le crédit de l’usager.
 USSD
17

 Les services Unstructured supplementary service data (USSD) permettent aux opérateurs
d’offrir des services de texte conversationnels aux usagers mobiles (2G et 3G).
 Services USSD initiés par le mobile : Cette catégorie de services USSD est initiée en
introduisant une commande USSD avec le clavier de son mobile.
 *#147# Permet d ’obtenir le dernier numéro d ’appelant.
 Services USSD initiés par le réseau : Le HLR ou le VLR peuvent à tout moment initier une
session de service USSD avec le mobile (le mobile est toujours le destinataire des sessions
initiées par le réseau). Le réseau inclut un code de service USSD au message USSD envoyé
au mobile. Le mobile exécute alors le service USSD requis. Il n’y a pas de rangée de valeur
particulière puisque le mobile est toujours le destinataire. Parmi les services USSD proposés
par Orange France figurent :
 #123# (Orange suivi conso)
Service USSD de recharge de compte prépayé
18
 BSSAP
19

 BSS Application Part (BSSAP) est un protocole du système de signalisation 7 utilisé par le
centre de commutation mobile (MSC) et le sous-système de station de base (BSS) pour
communiquer entre eux à l'aide de messages de signalisation pris en charge par le MTP et les
services orientés connexion du SCCP . Pour chaque équipement mobile actif, une connexion
de signalisation est utilisée par le BSSAP ayant au moins une transaction active pour le
transfert de messages.
 BSSAP fournit deux types de fonctions:
 La partie d'application mobile BSS (BSSMAP) prend en charge les procédures destinées à
faciliter la communication entre le MSC et le BSS en ce qui concerne la gestion des
ressources et le contrôle de transfert.
 La partie d'application de transfert direct (DTAP) est utilisée pour le transfert de ces
messages qui doivent se rendre directement à un équipement mobile à partir du MSC en
transmettant toute interprétation par le BSS. Ces messages concernent généralement la
gestion de la mobilité (MM) ou la gestion des appels (CM).
 BSSAP
20
21

SIGTRAN: Transport de la Signalisation 

sur IP
Concepts, Principes et Architectures
 SIGTRAN (Signaling Transport over IP)
22

SIGTRAN (Signaling Transport over IP) est un groupe de travail à l’IETF qui traite
la problématique du transport de la signalisation téléphonique sur IP. SIGTRAN
définit :
 Un protocole de transport commun appelé SCTP (Stream Control
Transmission Protocol) qui assure le transport fiable de la signalisation sur IP
 Des couches d’adaptation qui supportent des primitives spécifiques requises
par des protocoles de signalisation spécifiques tels que ISUP, Q.931, BSSAP,
INAP, MAP, CAP, etc.
 Couches adaptation de l’architecture
SIGTRAN
23

L’architecture SIGTRAN avec ses couches adaptation :

 IUA pour le transport de la signalisation RNIS, V5UA pour le transport de la
signalisation V5
 et M2UA,M2PA, M3UA, SUA pour l’acheminement de la signalisation SS7

 SIGTRAN définit un protocole de transport fiable appelé SCTP ainsi qu’un

ensemble de modules d’adaptation permettant de transporter des protocoles
de signalisation téléphonique sur IP.
 Actuellement six couches sont définies :
 Adaptations SIGTRAN
24

 La couche d’adaptation IUA (ISDN User Adaptation) est définie pour le

transport de messages Q.931 (signalisation RNIS) entre un Signaling Gateway
(SG) et un Media Gateway Controller (MGC). En fait, cette adaptation émule
pour la couche cliente (Q.931)
 une interface Q.921 et s’appuie sur le service SCTP. Le scénario typique
d’usage de cette adaptation est le Réseau NGN qui interface des PABX.
 La couche d’adaptation M2UA (MTP 2 User Adaptation) assure le transport de
paquets MTP3 entre un SG et un MGC. Elle fournit une interface MTP 2 à la
couche cliente (i.e., MTP3) et s’appuie sur le service SCTP. Cette adaptation
peut être utilisée dans le contexte NGN ou des commutateurs d’accès du RTC
s’interfacent au NGN avec un mode de signalisation SS7 associé.
 La couche d’adaptation M2PA (MTP 2 Peer to Peer Adaptation) assure le
transport de paquets MTP3 entre deux SGs ou deux IP SPs (IP Signaling
Point). Elle fournit une interface MTP 2 à la couche cliente (i.e., MTP3) et
s’appuie sur le service SCTP.
 Adaptations SIGTRAN
25

 La couche d’adaptation M3UA (MTP 3 UA) assure l’acheminement de messages ISUP

ou SCCP entre un SG et un MGC en fournissant une interface MTP3 à la couche
supérieure (e.g., ISUP, SCCP). M3UA peut aussi fonctionner en mode IP SP –IP SP
permettant ainsi à un MSC Server et un HLR disposant d’une connectivité SIGTRAN
dans le monde mobile de partager une association SCTP directement entre eux.
 La couche d’adaptation SUA (SCCP UA) offre une interface SCCP (e.g., TCAP) entre
un SG et une base de données IP ou entre un SG et un MGC. Le mode IP SP – IP SP
est aussi supporté, notamment intéressant pour le monde mobile ou de nombreuses
application SS7 utilisent les services SCCP (e.g., MAP, INAP, CAP, TCAP).
 La couche d’adaptation V5UA (V5.2 UA) est définie pour le transport de messages V5.2
entre un SG et un MGC. En fait, cette adaptation émule pour la couche cliente V5.2 une
interface LAPV5 et s’appuie sur le service SCTP. Le scénario d’usage de cette
adaptation est le Réseau NGN qui interface des lignes d’abonné analogique ou RNIS.
 Modes de fonctionnement des adaptations
SIGTRAN
26

 Les adaptations SIGTRAN fonctionnent soit en mode symétrique, soit en mode asymétrique,
soit supportent les deux modes. IUA, V5UA et M2UA ne fonctionnent qu’en mode
asymétrique. M2PA ne supporte que le mode symétrique. M3UA et SUA peuvent opérer
selon les deux modes.
 IUA : SG AS (Asymétrique)
 V5UA : SG AS (Asymétrique)
 M2UA : SG AS (Asymétrique)
 M2PA : IPSP IPSP (Symétrique)
 M3UA : SG AS (Asymétrique)
IPSP IPSP (Symétrique)
 SUA : SG AS (Asymétrique)
 IPSP IPSP (Symétrique)
 Adaptations SIGTRAN
27
 Scénario d’usage IUA (1)
28

Transport de la signalisation Q.931 par IUA

 Scénario d’usage M2UA dans le contexte
NGN Fixe
29

Transport de la signalisation ISUP/MTP3 par M2UA

 Scénario d’usage M2UA dans le contexte
NGN Mobile
30
 Transport de la signalisation V5.2 par V5UA
31
 Transport de la signalisation ISUP/MTP3
par M3UA
32
 M3UA en mode symétrique
33
 Utilisation de l’entité IP STP
34
 Scénario d’usage SUA en mode
asymétrique dans le contexte NGN Mobile
35
 Scénario d’usage SUA en mode
symétrique dans le contexte NGN Mobile
36
 Utilisation de l’entité SUA Relay
37
38

Architecture de services
avancées
 Introduction
39

 L’industrie des télécommunications cherche à orienter sa technologie de manière à aider

les opérateurs à demeurer compétitifs dans un environnement caractérisé par la
concurrence et la déréglementation accrues.
 Les réseaux NGN, avec leur architecture répartie, exploitent pleinement des technologies
de pointe pour offrir de nouveaux services sophistiqués et augmenter les recettes des
opérateurs tout en réduisant leurs dépenses d’investissement et leurs coûts
d’exploitation.
 L’évolution d’un réseau existant vers cette nouvelle structure nécessitera une stratégie de
migration progressive visant à réduire au minimum les dépenses d’investissement
pendant la phase de transition, tout en tirant parti très tôt des avantages qu’elle présente.
 Toute démarche entreprise lors de cette étape de transition devra simplifier l’évolution du
réseau vers l’architecture NGN à commutation de paquets. Pendant plusieurs années
encore, les services de commutation traditionnels vont devoir coexister avec des
éléments de réseau mettant en œuvre de nouvelles technologies.
 Les facteurs de mutation vers le NGN
40

 Facteurs de changement issus du marché

 Rester compétitif, exige que l’on demeure vigilant sur les coûts et sur
l’innovation.
 En d’autres termes, il faut absolument fournir un nombre croissant de
services divers au niveau ou en dessous des calculs de coûts marginaux, et
continuer à innover afin d’engendrer de nouvelles sources de revenus pour
remplacer celles qui sont en déclin.
 À l’avenir, l’avantage compétitif majeur des opérateurs historiques
résidera dans leur couverture nationale et dans l’éventail des
applications qui y seront offertes.
 Fournir une nouvelle application à un utilisateur à un coût marginal plus
faible que celui des autres opérateurs est certainement un élément clé
de différenciation.
 Pourquoi Le NGN ?
41

 Le trafic de données prend rapidement le pas sur le trafic vocal et la tendance

est nettement à l’augmentation en bande passante pour les données..
 Les opérateurs possédant les deux types de réseaux (réseau voix et réseau de
données) utilisent cet argument pour commencer à les unifier.
 Pour les opérateurs, l’accès et le transport ne sont plus assez lucratifs et, pour
rester compétitif, il leur faudra donc offrir aux usagers toute une gamme de
services utiles, faciles à utiliser et rémunérateurs.
 Par conséquent, les NGN seront axés sur les services, et fourniront tous les
moyens nécessaires pour en offrir de nouveaux et adapter les existants pour
augmenter les recettes.
 Les opérateurs entrants (ADSL) pourront envisager d’investir dans une solution
d’emblée NGN. Pour un opérateur établi, l’important est de définir les conditions
de migration de leur réseau téléphonique commuté actuel vers le NGN.
 Types de NGN
42

 Le Class 4 NGN permet :

 Le remplacement des centres de transit téléphoniques (Class 4
Switch)
 La croissance du trafic téléphonique en transit
 Le Class 5 NGN permet :
 Le remplacement des centres téléphoniques d’accès (Class5
Switch)
 La croissance du trafic téléphonique à l’accès
 La voix sur DSL/ Voix sur le câble
 Le Multimedia NGN permet d’offrir des services multimédia à
des usagers disposant d’un accès large bande tel que xDSL,
câble, WiFi/WiMax, EDGE/UMTS, LTE
 Architecture NGN
43

 Couche Terminal :contient l’ensemble des terminaux permettant à l’utilisateur d’établir et

recevoir des appels.
 Couche Accès : Elle relie les usagers au réseau et regroupe leur trafic. Elle contient les
éléments de réseau existant chez l’opérateur à l’accès tels que les commutateurs
téléphoniques d’accès, les PABX, les boucles locales, lesBTS/BSC, Les NodeB/RNC,
etc.
 Couche Transport : Elle transporte le trafic à destination. La couche transport utilise la
technologie IP (Internet Protocol). L’offre NGN des constructeurs s’appuie aujourd’hui sur
une couche de transport basées sur ATM directement ou IP.
 Couche Adaptation : Elle conditionne le trafic pour son transport sur le réseau. Par
exemple, le trafic vocal est conditionné en paquets IP. Cette couche contient des
passerelles (MGW) permettant l’interfonctionnement entre la couche d’accès et la couche
de transport.
 Architecture NGN
44

 Couche Contrôle :Elle assure l’intelligence d’appel. Cette couche décide quel
service un usager va recevoir. Elle contrôle aussi d’autres éléments de réseau des
couches inférieures, leur indiquant quel traitement faire subir au trafic. Elle contient
des contrôleurs d’appels appelés Media Gateway Controllers (MGC) puisqu’ils
pilotent les MGWs de la couche d’adaptation.
 Couche Application : Elle fournit des services à valeur ajoutée par le biais de
serveurs d’[Link] le MGC peut s’interfacer avec ces serveurs pour
invoquer des services.
 La Gestion est transversale à l’ensemble des couches. Chaque couche possède sa
propre gestion. Ainsi les éléments d’une couche donnée sont vendus avec le
système de gestion qui permet à l’opérateur de superviser, gérer et exploiter ces
éléments.
 Architecture NGN
Avantage
45

 Grâce au NGN, l’opérateur dispose d’un réseau multiservice permettant

d’interfacer n’importe quel type d’accès L’opérateur n’aura plus à terme qu’à
exploiter un seul réseau multiservice.
 Elle utilise le transport IP
 C’est une topologie ouverte qui peut transporter aussi bien les services
téléphoniques que les services de multimédia (vidéo, données temps réel).
 Elle dissocie la partie support du réseau de la partie contrôle, leur
permettant d’évoluer séparément et brisant la structure de communication
monolithique. En effet, la couche transport peut être modifiée sans impact sur
les couches contrôle et application.
 Elle utilise des interfaces ouvertes entre tous les éléments, permettant à
l’opérateur d ’acheter les meilleurs produits pour chaque partie de son réseau.
 Exemple d’architecture NGN Téléphonie
46
 Protocoles de contrôle MGCP MEGACO vs
protocoles de signalisation (BICC, SIP-T)
47
 Exemple d’architecture multimédia
48
 Domaine CS dans l’UMTS Release 3/4
49
 Signalling Gateway entre l’accès Radio
et le domaine CS de l’UMTS 4
50
 Signalling Gateway entre RTC et le
domaine CS de l’UMTS 4
51
 Contrôle d’appel NGN mobile
Etablissement d’appel Mobile Fixe
52
 Connectivité mise en œuvre dans les CS-
MGWs et dans le réseau IP
53
 Contrôle d’appel NGN mobile
Libération d’appel Mobile Fixe
54
 Contrôle d’appel NGN mobile
Etablissement d’appel Fixe Mobile
55
 NGN: Définition
56

 Un réseau de transport en mode paquet permettant la

convergence des réseaux Voix/données et Fixe/Mobile ; ces
réseaux permettront de fournir des services multimédia
accessibles depuis différents réseaux d’accès.
 NGN: définition
57

 Le NGN offre des services multimédia en s’appuyant sur un réseau support mutualisé et
caractérisé par plusieurs éléments essentiels:
 Un cœur de réseau unique et mutualisé pour les différents types d’accès et de
services.
 Une architecture de cœur de réseau en 3 couches : Transport, Contrôle et Services.
 Une évolution du transport en mode paquet avec une convergence progressive vers IP.
 Des interfaces ouvertes et normalisées entre chaque couche, et notamment au niveau
des couches Contrôle et Services afin de permettre la réalisation de services indépendants
du réseau.
 Le support d’applications multiples, multimédia, temps réel, en mobilité totale,
adaptables à l’utilisateur et aux capacités des réseaux d’accès et des terminaux.
 NGN
58

 Nécessité d’associer à IP des protocoles garantissant la qualité de service.

 Pour les constructeurs issus des réseaux de données,: mise en œuvre
d’un transport IP, avec des classes de services (mécanisme DiffServ)
associé au protocole MPLS, nativement conçus pour fonctionner avec IP;
l’évolution de la solution IP/MPLS sera apportée, par le protocole G-MPLS
qui simplifie la gestion du réseau de transport.
 Les nouveaux acteurs positionnés exclusivement sur des équipements
insistent particulièrement sur le fait que l’essentiel pour une solution de
réseau NGN est de migrer la signalisation sur IP natif, le transport du
trafic IP lui-même pouvant être réalisé sur IP.
 NGN, une vision plus ou moins
homogène chez les constructeurs
59

 L’évolution du cœur de réseau vers une architecture en couches séparées

(transport, contrôle, services).
 Le concept majeur des NGN est bien l’évolution « tout IP », la séparation
en couches n’étant qu’une étape, ou une nécessité pour optimiser les
réseaux.
 Les réseaux NGN permettent de développer plus rapidement et de fournir plus
aisément de nouveaux services multimédia à haut débit et simples d’usage
incluant la donnée, la voix et la vidéo indépendamment du réseau d'accès.
 Cependant, deux modèles complémentaires se dégagent quant à la
fourniture de services :
 l’un « orienté softswitch » (i.e. s’appuyant fortement sur les fonctions de la couche
Contrôle) plutôt supporté par les acteurs télécoms,
 et l’autre orienté « services web » (i.e. plus distribué) promu par les acteurs issus du
monde Internet.
 Principe général d’architecture NGN
60
 Architecture physique d’un cœur NGN :
Vers un réseau de Transport IP, multiservices et haut débit
61
 Les réseaux de transport actuels
62

Structure en couches actuelle utilisée dans les réseaux

WAN, RAN et MAN
 Evolutions dans les réseaux de
transmission actuels
63

 Dans un réseau de transmission les différents niveaux de desserte

géographique sont:
 Le LAN (Local Area Network) qui concerne un immeuble, un groupement
d’immeubles ou un campus.
 La boucle locale, qui permet d’atteindre le client, dite aussi « réseau d’accès ».
 Le MAN (Metropolitan, Area Network) qui dessert un quartier ou une ville.
 Le RAN (Regional Area Network) qui couvre une communauté urbaine ou une
région.
 Le WAN (Wide Area Network) qui parcourt un pays ou un continent.
 Les réseaux de transmission longue
distance (WAN) et régionaux (RAN)
64

 Caractéristiques:
 Le multiplexage TDM s’est imposé largement dans tous les réseaux WAN et surtout
RAN des opérateurs. Ce multiplexage nécessite de hiérarchiser les débits au sein du
réseau. hiérarchies SDH et PDH ont été normalisées au niveau européen. Cette
hiérarchie offre des débits granulaires de 2 Mbit/s (dans les MANs) à 10 Gbit/s (dans les
WANs).
 Avec l’apparition de la technologie POS (Packet Over SDH/Sonet), les réseaux SDH
peuvent véhiculer de manière isolée des conduits de trafic circuit et paquet. Le SDH n’a
donc pas vocation à disparaître à court terme.
 Le multiplexage WDM s’est imposé dans les réseaux WAN de longue distance. Cette
technique multiplexe des longueurs d’onde différentes. Elle permet d’obtenir des débits
très élevés de l’ordre du Tbit/s. Ce multiplexage est le plus souvent réservé à des
réseaux continentaux ou intercontinentaux.
 Les réseaux de transmission métropolitains
(MAN)
65

 le médium physique: la fibre optique est largement utilisée, mais

l’utilisation de la paire de cuivre analogue aux paires de cuivre
aboutissant à n’importe quelle habitation) et du câble coaxial est de
plus en plus visible.
 le multiplexage: PDH permet des débits granulaires allant de 64 kbit/s
à 565 Mbit/s.
 Apparition de la technique Ethernet qui permet des débits
hiérarchisés de 10 Mbit/s, 100 Mbit/s, 1 Gbit/s et 10 Gbit/s sur des
distances de plus en plus grandes.
 Inadéquation entre les hiérarchies PDH
et SDH, et la commutation de paquets
66

 les hiérarchies numériques fondées sur le multiplexage TDM sont

adaptées pour un réseau de commutation de circuits qui n’en est
maintenant plus le seul utilisateur du fait de la croissance du trafic de
données.
Evolutions dans les réseaux de commutation
de paquets actuels
67

Les réseaux de commutation de paquets, plusieurs tendances se dégagent :

 La commutation IP, commutation de paquets en mode datagramme, est
devenue la technique universelle à l’interconnexion de réseaux de
commutation différents. De plus, elle se positionne maintenant en tant que
commutation « à part entière », c’est-à-dire qu’elle ne se réduit plus exclusivement
à l’interconnexion de réseaux, mais elle peut aussi jouer le rôle d’une technique de
commutation de paquets de bout en bout.
 Extension de l’usage de la commutation de niveau 2, la généralisation de la
commutation de paquets en mode « circuit virtuel » (commutations ATM, FR et
MPLS) au détriment de la commutation de paquets en mode « datagramme »
(ou commutation IP
 La commutation en mode circuit virtuel est plus rapide (elle permet d’offrir une
qualité de service au niveau réseau), plus souple dans la gestion des liens
(pour créer un VPN, par exemple) et dans le « traffic engineering », càd la
gestion de la BP et de l’acheminement du trafic sous contrainte.
 Exemples de commutation dans un
réseau de données
68
Les tendances des réseaux de transport
NGN
69

 TDM est plus lourde que WDM

 Fonctionne en mode « trame » et oblige à des opérations de multiplexage et de
démultiplexage assez lentes ;
 un réseau de transmission TDM est plus difficile à administrer.
 TDM permet d’atteindre des débits limités de l’ordre du Gbit/s
 WDM
 permet d’associer à chaque flux provenant d’un lien une longueur d’onde.
 évite les mécanismes fastidieux du TDM et apporte la souplesse du brassage
de signaux optiques.,
 Avec WDM, le Tbit/s est facilement atteint.
 Les tendances des réseaux de transport
NGN
70

Plusieurs évolutions liées à l’optique et au WDM se dégagent pour les réseaux de

transmission :
• Dans les WANs WDM est largement majoritaire.
• Dans les RANs ou les MANs, WDM y est encore peu présente. Cependant, avec
la baisse de prix et l’apparition de brasseurs et multiplexeurs WDM performants,
l’apparition progressive du multiplexage WDM dans ces zones est prévue.
• Le développement du multiplexage dit CWDM (Coarse Wavelength Division
Multiplexing), technologie WDM simplifiée permettant le multiplexage d’un nombre
restreint de longueur d’ondes (mais néanmoins suffisant pour un usage
métropolitain).
Ex. : 4 longueurs d’onde et ayant pour elle l’atout d’une complexité moindre, donc de
prix très inférieurs au DWDM, va dans ce sens.
 La technique Ethernet sur fibre optique
71

 Se développe dans les MAN, voire WAN, notamment à travers le

standard Gigabit Ethernet et 10 Gigabit Ethernet, qui offre des débits de
l’ordre de plusieurs Gbit/s.
 La modulation DWDM devrait favoriser le développement d’Ethernet pour ces
usages, car elle permet le transport de l'Ethernet sur de longues distances et
à un débit très élevé.
 Le protocole MPLS, qui se généralise dans les réseaux WAN, est transparent
aux protocoles LAN et apporte une flexibilité de gestion de la bande
passante, ce qui en fait un support efficace pour les services d’interconnexion
de LAN de manière transparente.
 Commutation : vers le MPLS puis le GMPLS
72

Principaux avantages de la commutation MPLS :

 L’architecture MPLS s’appuie sur une commutation de paquets en mode «
circuit virtuel ». ce type de commutation est plus rapide qu’une commutation
de paquets en mode « datagramme » de type IP avec une séquence des trames
MPLS respectée.
 L’architecture MPLS a été taillée sur mesure à la topologie d’adressage IP. Un
plan contrôle permet de gérer les circuits virtuels de manière logicielle,
sans administration manuelle lourde. La commutation MPLS est la plus adaptée
au transport des paquets IP.
 Ce passage à la commutation MPLS se fait de plusieurs manières, selon la
nature de la base technique de commutation initialement installée chez l’opérateur :.
 L’opérateur peut déployer directement ou progressivement de nouveaux
commutateurs MPLS natifs indépendants. C’est a priori la solution cible.
Exemple d’un réseau de commutation IP/MPLS
73
 Les fonctions offertes par MPLS
74

 La qualité de service
 la norme Diffserv (Differentiated Services) a défini un ensemble de niveaux de qualité de
service qui permettent de mettre tous les acteurs d’un réseau (opérateurs, fournisseurs
d’accès, utilisateurs, etc.) d’accord sur des niveaux de service communs. Au niveau du
transport, cela se traduit par l’application à un des champs d’une trame MPLS de ces
valeurs de qualité de service, qui définissent alors les trames prioritaires et le traitement
adapté à ces trames par un commutateur MPLS. De plus, la commutation MPLS
permet un contrôle de congestion beaucoup plus fin que la commutation IP classique.
 L’ingénierie de trafic
 MPLS rend possible une ingénierie de trafic performante (optimisation de la capacité
disponible en transmission et commutation), qui n’est pas possible actuellement en
commutation IP.
 La diffusion
 La commutation MPLS permet facilement de créer des services de diffusion par la
création de circuits virtuels MPLS de point à multipoint associés à une @ IP de diffusion.
 Les fonctions offertes par MPLS
75

 La sécurité
 Le fait que la commutation MPLS utilise des circuits virtuels garantit la sécurité.
De plus, sur un réseau public, IPsec garantit lui aussi la sécurité. Cette évolution
se fera car le protocole IPsec, situé juste en-dessous du protocole IP, permet
une gestion souple de la sécurité pour tout type d’applications.
 Le plan de contrôle – création de circuits virtuels
 MPLS définit un plan « contrôle » et un plan « usager ». Le plan usager fonde la
commutation MPLS classique.
 Le plan contrôle utilise des protocoles de signalisation qui permettent de
configurer, de façon dynamique, des circuits virtuels. La possibilité technique de
leur création est spécifiée dans la norme à travers le protocole de signalisation
RSVP (Ressource ReserVation Protocol). Associé aux mécanismes Diffserv,
la signalisation RSVP permet de créer « à la demande » des circuits virtuels
et de leur associer un niveau de qualité de service.
 Plan de contrôle
76

 Ce plan contrôle permet à l’opérateur, de créer dynamiquement et de

manière logicielle des circuits virtuels « par défaut » entre routeurs externes
au réseau MPLS.
 Cette souplesse, que l’on ne trouve pas dans la commutation ATM,
facilite grandement l’évolution de la configuration physique du réseau
(interconnexion à un autre réseau ou ajout d’un nouveau client par
exemple).
 Du MPLS au GMPLS
77

 Généralisation du plan de contrôle à tous les nœuds du réseau, incluant les

nœuds de transmission
 Cette idée permettrait de configurer les circuits virtuels entre commutateurs MPLS,
mais aussi de configurer (ou de reconfigurer) les liens entre des nœuds de
multiplexage TDM ou WDM.
 Un réseau de Transmission, composé de brasseurs et de multiplexeurs TDM
ou WDM se configurerait alors « sous le contrôle » du plan contrôle MPLS.
 Du MPLS au GMPLS
78

Structure en couches d’un réseau NGN WAN ou

RAN fondé sur une solution GMPLS / WDM
 Exemple de reconfiguration d’un réseau de transmission
WDM sous le contrôle d’un réseau de commutation GMPLS
79

Cette solution apporte une grande souplesse de gestion et une grande

évolutivité du réseau de transport, qui s’adapte au profil de son trafic actuel et
futur, tant au niveau de la commutation (MPLS), qu’au niveau de la transmission.
 Commutation IP : migration d’IPv4 à IPv6
80

 La commutation IP actuelle (IPv4)

 Le protocole IP a connu plusieurs versions successives au cours de sa
normalisation et la version qui est utilisée dans le monde entier est la
version 4 (on parle de protocole IPv4). L’en-tête d’un datagramme IPv4
contient peu d’informations ; entre autres, il contient :
 Les adresses source et destination ;
 Un champ ToS (Type of Service) qui est utilisé par des mécanismes
de qualité de service.
 les évolutions clé D’IPv4 à IPv6
81

Les principales améliorations sont les suivantes :

 L’amélioration du champ ToS - renommée CoS pour Classe of Service – dans
l’en-tête du datagramme et l’ajout d’un champ identifiant de flux.
 L’intégration par défaut du protocole de sécurité IPsec.

 IPsec fournit un service de sécurité à la couche transport (et donc à toutes les
applications).
 Une nouvelle définition des adresses de diffusion, ainsi que l’intégration par
défaut et l’amélioration des mécanismes de traitement de ces adresses au niveau
des commutateurs. Cette fonction sera particulièrement favorable aux nouveaux
services multimédia de diffusion de contenu.
 L’intégration par défaut et l’amélioration du protocole de mobilité Mobile IP qui
permet la mobilité, via l’utilisation d’une adresse IP temporaIre associé à l’adresse
IP fixe du mobile et d’un mécanisme d’encapsulation.
 Conclusion
82

Plusieurs tendances autour des réseaux de transport des opérateurs :

 L’extension de l’usage de la commutation optique, et du multiplexage en
longueur d’onde (DWDM, CWDM) dans les réseaux de transmission
étendus, y compris métropolitains, au détriment du multiplexage TDM.
 L’apparition de commutateurs Ethernet dans les réseaux longue distance
métropolitains, voire nationaux ou internationaux. Ces commutateurs permettent
une connectivité de « bout en bout» en Ethernet ;
 Au niveau du réseau de commutation les tendances suivantes qui se dégagent :
 Une tendance vers une commutation MPLS seule
 A plus long terme l’apparition du GMPLS (MPLS sur WDM). Au niveau d’un éventuel
plan de contrôle du réseau global de transport, le GMPLS propose une solution
audacieuse, mariant le contrôle des réseaux de commutation et de transmission.
 En synthèse
83

Evolutions clé au niveau Transport, dans le cadre des NGN, sont :

 l’évolution globale vers des technologies de transmission et de transport haut
débit, en mode paquet, avec une qualité de service adaptée
 la séparation des fonctions Transport et Contrôle du coeur de réseau. En
effet, la notion de réseau de transport, au sens NGN, est plus large qu’au
sens traditionnel. Elle inclut l’apparition des fonctions Media Gateway et
Signalling Gateway, qui effectuent la conversion et l’acheminement du
trafic et de la signalisation sous le contrôle des serveurs d’appel.
 Evolution des entités et protocoles du
cœur de réseau NGN
84

Principe général des équipements actifs du cœur de réseau NGN :

1. Remplacement des commutateurs traditionnels par deux types d’équipements
distincts :
 d’une part des serveurs de contrôle d’appel dits Softswitch ou Media
Gateway Controller (correspondant schématiquement aux ressources
processeur et mémoire des commutateurs voix traditionnels),
 et d’autre part des équipements de médiation et de routage dits Media
Gateway (correspondant schématiquement aux cartes d’interfaces et de
signalisation et aux matrices de commutation des commutateurs voix
traditionnels), qui s’appuient sur le réseau de transport mutualisé NGN.
2. Apparition de nouveaux protocoles de contrôle d’appel et de signalisation entre
ces équipements (de serveur à serveur, et de serveur à Media Gateway)
 Architecture simplifiée des NGN
85
Entités fonctionnelles du cœur de réseau NGN
86

MG: située au niveau du transport des flux média entre le réseau RTC et les réseaux en mode
paquet, ou entre le cœur de réseau NGN et les réseaux d’accès. Elle a pour rôle :
 Le codage et la mise en paquets du flux média reçu du RTC et vice-versa (conversion du
trafic TDM IP).
 La transmission, suivant les instructions du MGC, des flux média reçus de part et d'autre.
SG: a pour rôle de convertir la signalisation échangée entre le réseau NGN et le réseau
externe interconnecté selon un format compréhensible par les équipements chargés de la
traiter, mais sans l’interpréter (ce rôle étant dévolu au Media Gateway Controller).
Notamment, elle assure l’adaptation de la signalisation par rapport au protocole de
transport utilisé (ex. : adaptation TDM IP). Cette fonction est souvent implémentée
physiquement dans le même équipement que la MG, d’où le fait que ce dernier terme
est parfois employé abusivement pour recouvrir les deux fonctions MG + SG.
 Importance du rôle des Gateways
87

 Les Gateways ont un rôle essentiel : elles assurent non seulement

l’acheminement du trafic, mais aussi l’interfonctionnement avec les
réseaux externes et avec les divers réseaux d’accès en réalisant :
 la conversion du trafic (entité fonctionnelle MG),
 la conversion de la signalisation associée (entité fonctionnelle SG).
 Entités fonctionnelles du cœur de réseau NGN
88

Le serveur d’appel ou MGC

Dans un réseau NGN, c’est le MGC qui possède « l'intelligence ». Il gère :
 L’échange des messages de signalisation transmise de part et d'autre avec les passerelles
de signalisation, et l’interprétation de cette signalisation.
 Le traitement des appels : dialogue avec les terminaux H.323, SIP voire MGCP,
communication avec les serveurs d’application pour la fourniture des services.
 Le choix du MG de sortie selon l‘@ destinataire, le type d'appel, la charge réseau
 La réservation des ressources dans le MG et le contrôle des connexions internes au MG
(commande des MG).
Dans l’architecture des réseaux NGN, le serveur d’appel, aussi appelé
Softswitch ou Media Gateway Controller (MGC) est le nœud central qui
supporte l’intelligence de communication.
 Modularité des implémentations physiques
89

 La MG et le MGC sont des entités fonctionnelles et peuvent donc être

intégrées dans un même équipement mais aussi être des éléments indépendants ;
c’est le grand avantage apporté par la dissociation des couches Contrôle et
Transport.
 La MG et la SG sont aussi des entités fonctionnelles séparées, cependant
elles sont souvent implémentées dans le même équipement.
 Sur le plan de la localisation géographique des équipements, les Media
Gateways peuvent être par exemple réparties au plus près du trafic
(interconnexions, points de concentration vers les réseaux d’accès), et les serveurs
d’appels peuvent être groupés sur un ou deux sites centraux.
 Les deux types d’équipements communiqueront alors via le réseau de transport IP
et le protocole de commande de Media Gateway.
 Modularité des implémentations physiques
90

 Le dimensionnement des gateways et des serveurs est aussi indépendant :

 si les gateways sont avant tout dimensionnées en fonction de la capacité de trafic à écouler,
 les serveurs sont, eux, dimensionnés en fonction de la charge de traitement de communications
à supporter (établissement de connexions, activité de mobilité des utilisateurs, etc.).
 La décomposition des fonctions du coeur de réseau en couches et entités
fonctionnelles indépendantes rend les constructeurs et les opérateurs plus
libres sur l’implémentation physique de ces fonctions dans les divers
équipements, et leur localisation géographique. Elle permet aussi d’optimiser
les ressources, les différentes entités étant partagées, mais pouvant être
dimensionnées séparément.
 Les familles de protocoles d’un réseau NGN
91

 La convergence des réseaux voix/données ainsi que le fait d’utiliser un

réseau en mode paquet pour transporter des flux multimédia « temps
réel », a nécessité l’adaptation de la couche Contrôle.
 En effet ces réseaux en mode paquet étaient généralement utilisés
comme réseau de transport mais n’offraient pas de services permettant
la gestion des appels et des communications multimédia.
 Cette évolution a conduit à l’apparition de nouveaux protocoles,
principalement concernant la gestion des flux multimédia, au sein
de la couche Contrôle.
Contrôle d’appel : deux protocoles candidats
H.323 vs SIP
92

Historiquement, la recommandation H.323 de l’UIT est devenue le standard de

base pour les communications voix sur les réseaux en mode paquet.
Pratiquement tous les PC possèdent par défaut un terminal H.323 (Ex. :
logiciel NetMeeting de Microsoft).

Inconvénient: H.323 est relativement pauvre au niveau des services offerts

en comparaison de la téléphonie classique. La plupart des fournisseurs a
donc développé des protocoles propriétaires permettant d’offrir les services
standards « en téléphonie », ce qui limite l’interopérabilité entre les
équipements. De plus de nouveaux protocoles, apparus ces dernières
années (ex : SIP, MGCP) semblent plus appropriés et sont soutenus par de
nombreux constructeurs.
 Le protocole historique : H.323
93

La recommandation H.323 de l’UIT décrit les procédures pour les communications

audio et vidéo point à point ou multipoint sur des réseaux en mode paquet.
C’est une adaptation des procédures de vidéoconférence sur RNIS (H.320) aux
réseaux sans garantie de service.
Plusieurs entités sont nécessaires à la réalisation d’un service de communication
multimédia sur des réseaux de données :
Autorité de régulation des télécommunications
 Les terminaux H.323 sont des systèmes multimédia (téléphone, PC)
 Le gatekeeper gère les terminaux H.323 (identification et traduction d’adresses) et
les établissements d’appels
 La passerelle H.323 permet d’interfacer le réseau IP avec le RTC
L’unité de contrôle MCU (Multipoint Controller Unit) gère les connexions
multipoint (ex. : appels de conférence). Il se décompose en un Multipoint Controller
(MC), affecté à la signalisation, et un Multipoint Processor (MP), dédié à la
transmission proprement dite.
 Protocoles de contrôle
94

 Les protocoles de contrôle d’appel permettant l’établissement, généralement

à l’initiative d’un utilisateur, d’une communication entre deux terminaux ou entre un
terminal et un serveur ; les deux principaux H.323, norme de l’UIT et SIP,
standard développé à l’IETF.
 Les protocoles de commande de MG qui sont issus de la séparation entre les
couches Transport et Contrôle et permet au Softswitch ou MGC de gérer les
passerelles de transport ou MG. MGCP de l’IETF et H.248/MEGACO, développé
conjointement par l’UIT et l’IETF, sont les protocoles prédominants.
 Les protocoles de signalisation entre les serveurs de contrôle (ou MGC)
permettant la gestion du plan contrôle:
 au niveau du coeur de réseau avec des protocoles tels que BICC (Bearer Independant
Call Control), SIP-T (SIP pour la téléphonie) et H.323.
 à l’interconnexion avec SS7, via des SG via SIGTRAN. De plus, l’interconnexion de ces
réseaux de données avec les réseaux existants de téléphonie (TDM avec SS7) a
nécessité le développement de protocoles dédiés à l’interconnexion des réseaux et
au transport de SS7 sur des réseaux en mode paquet.
 Architecture H.323
95
 Les terminaux H.323
96

Ce sont des systèmes d’audio (Téléphone IP, PC) ou de vidéo conférence utilisés pour
communiquer en temps réel. Le standard H.323 requiert que chaque terminal supporte un
certain nombre de fonctions et de codeurs qui ont été définis par l’ITU, tels que :
 H.225, qui effectue la signalisation des appels et la synchronisation.
 H.245, qui échange des capacités entre les terminaux,
 la négociation de canal et le contrôle de flux « média » entre les terminaux H.323.
 Q.931, qui est un protocole de signalisation pour établir et clore les appels.
 RAS (Registration/Admission/Status) Channel, qui est utilisé par les terminaux pour
communiquer avec le gatekeeper.
 RTP/RTCP : utilisé pour transporter les données « temps réel » sur un réseau IP. .
Les terminaux H.323 peuvent aussi avoir des fonctionnalités supplémentaires, tels que
des codeurs audio/vidéo, le protocole T.120 pour la data-conférence et des fonctionnalités de
qualité de service. Cependant, la multiplicité des options rend difficile
l’interopérabilité des différents terminaux H.323.
 Gatekeeper
97

Equipement optionnel dans un système H.323 qui fournit un service de

contrôle d’appel pour les terminaux H.323.
Plusieurs gatekeepers peuvent être présents sur un réseau et
communiquer les uns avec les autres.
Le gatekeeper est séparé des autres terminaux, cependant il peut être
physiquement implémenté avec un terminal, une gateway ou un autre élément
du réseau non-H323.
 Services du Gatekeeper
98

 Traduction d’adresse : Le gatekeeper fait la traduction de l’alias H.323

en une adresse de transport (adresse IP + port) Cela est effectué grâce à
une table qui est rafraîchie par les messages d’enregistrement (Registration
message).
 Contrôle d’admission : Le gatekeeper autorise l’accès au réseau par
les messages H.225 (ARQ/ACF/ARJ). Ce contrôle peut être basé sur
l’autorisation d’appel, la bande passante disponible ou d’autres critères fixés
par l’administrateur.
 Gestion de zone : Le gatekeeper doit garantir tous les services pour les
terminaux enregistrés.
 Contrôle de bande passante : Le gatekeeper peut refuser
l’établissement d’un appel pour cause de limitation de bande passante.
 Services du Gatekeeper
99

 Signalisation de contrôle d’appel : Le gatekeeper peut choisir de faire

la signalisation d’appel avec le terminal par lui-même ou de rediriger le
terminal pour qu’il établisse un « canal » de signalisation directement avec
l’autre terminal. De cette façon, cela permet d’éviter au gatekeeper de gérer
les appels H.225.
 Autorisation d’appel : Par l’intermédiaire de la signalisation H.225, le
gatekeeper peut accepter ou refuser une demande d’appel émise par un
terminal.
 Gestion des appels : Le gatekeeper peut recenser les appels en cours
dans la zone qu’il gère et connaître l’état dans lequel les différents appels
se trouvent.
 Gateway
100

 gère l’interconnexion entre le réseau IP et le réseau téléphonique

classique ;
 fournit une traduction entre des formats de transmission aussi bien de
signalisation que de flux multimédia.
 établit et termine les appels aussi bien du côté du réseau IP que du côté du
réseau téléphonique.
 peut aussi effectuer le transcodage entre les formats audio, vidéo ou data.
 possède les mêmes fonctionnalités qu’un terminal H.323 sur le réseau IP,
et aussi celles d’un terminal téléphonique sur le réseau de téléphonie.
 Les gatekeepers différencient les terminaux standards des passerelles par
l’intermédiaire des messages d’enregistrement envoyés par les terminaux
H.323.
 Adressage H.323
101

Adresse réseau
Chaque élément H.323 doit avoir au moins une @ réseau. Cette adresse identifie chaque
élément sur le réseau. Cette adresse est spécifique au réseau dans lequel il est localisé.
Adresse alias
Chaque terminal peut aussi être associé à une ou plusieurs @. Ces adresses « alias » peuvent
être du type E.164, noms alphanumériques (H.323 ID) ou d’autres formats définis dans la
norme H.225.0. Cependant chaque « @ alias » doit être unique dans une zone (gérée par
un gatekeeper).
 Quand il n’y a pas de gatekeeper sur le réseau, le terminal appelant joint l’appelé
directement à son @ « transport » par l’intermédiaire du canal de signalisation. S’il y a un
gatekeeper dans la zone, l’appelant cherche à contacter l’appelé via de son @ alias. Cette
demande est faite auprès du gatekeeper qui traduit, lui-même, l’@ alias en @ « transport ».
Enregistrement d’un terminal H.323
Par le processus d’enregistrement, le terminal H.323 se joint à une zone gérée par un
gatekeeper, auquel il transmet son adresse « transport » et son adresse « alias ». Ces
requêtes d’enregistrement sont transmises au gatekeeper par le protocole RAS.
 H.323 version 2
102

 La version 2 de H.323 (1998)

apporte des améliorations à la
version précédente notamment au
niveau de l’établissement d’appel.
Cette méthode, appelée FastStart,
établit une communication média
en un aller-retour.
 Cette évolution permet une
connexion similaire à celle d’un
appel téléphonique classique, à
l’opposé de la procédure très
longue de la version initiale de
H.323.

Etablissement d’appel en mode « FastStart »

 H.323 version 2
103

 H.323v2 permet aussi d’utiliser de nouveaux types d’adresses telles que

les adresses
 email et les URLs sous lesquelles les terminaux peuvent s’enregistrer.
 De nouvelles fonctionnalités ont été ajoutées à H.245, ce qui permet
d’utiliser un panel d’outils média plus important.
 Il est aussi possible d’utiliser des paramètres de qualité de service
(RSVP) lorsque que les flux média sont initiés.
 H.323 versions 3 et 4
104

 H.323 v3 a apporté des améliorations, principalement concernant l’interconnexion

avec RTC et l’extensibilité du protocole pour un réseau de grande taille.
 La version 4, dernière version de H.323 finalisée en 2000, apporte des
améliorations importantes concernant principalement deux points :
 Les services supplémentaires
 La décomposition des gateways en deux éléments distincts : la MG et le
MGC ; ce dernier commandant les MG via le protocole H.248.
 La version 4 de H.323 permet une dissociation des couches Transport et
Contrôle : c’est une mutation de la norme H.323
 vers les NGN. Cela apporte au protocole H.323 la capacité d’être
 utilisable sur des réseaux opérateurs, alors qu’il avait été conçu
 À l’origine pour des réseaux locaux.
 H323: Communications multi-utilisateurs
105

 Les communications multi-utilisateurs sont mises en oeuvre en établissant

les communications des différents utilisateurs avec le MCU, chargé de
centraliser et de synchroniser les flux puis de les retransmettre à chaque
participant.
 H323: Services supplémentaires
106

 Une famille de recommandations a été développée pour les services

supplémentaires. H.450.1, H.450.2 et H.450.3 sont basés sur le protocole
QSIG qui est utilisé pour les PBX.
 Les services initiaux qui ont été définis sont le transfert d’appel (H.450.2) et
le renvoi d’appel (H.450.3).
 D’autres services ont été normalisés :
 les appels en attente (H.450.4), le « parquage d’appels » (H.450.5), le
signal d’appel (H.450.6), le service d’identification (H.450.8), le renvoi
d’appel (H.450.9), la tarification d’appel (H.450.10), le service d’intrusion
(H.450.11)
 FAX sur H.323
 Deux terminaux H.323 (version 2) peuvent échanger des fax en utilisant TCP
ou UDP par l’intermédiaire de la norme T.38.
 Le protocole alternatif :
SIP- Session Initiation Protocol
107

 Le protocole SIP (RFC 2543), de l’IETF, est un protocole de signalisation

pour l’établissement d’appel et de conférences temps réel sur des
réseaux IP.
 Proposé comme standard à l’IETF en 1999, SIP est rapidement apparu
comme une alternative à H.323. Ainsi, dans ses dernières versions de
système d’exploitation, Microsoft propose un client SIP.
 Chaque communication doit pouvoir inclure différents types de données
telles que l’audio et la vidéo.
 SIP est indépendant du protocole de transport utilisé. Il utilise le
protocole SDP (Session Description Protocol) pour la description des
communications média.
 Etablissement d’appel SIP directement
de terminal à terminal
108

 Un client SIP peut contacter un autre terminal SIP en envoyant une requête « Invite ».
 Ce message « Invite » contient assez d’informations pour permettre au terminal appelé
d’établir une communication média avec l’appelant.
 Ces informations listent les différents types de média que l’appelant peut recevoir et envoyer,
ainsi que l’@ transport (@ IP et port) sur laquelle l’appelé pourra établir la connexion média
utilisant RTP. Le terminal appelé doit alors indiquer qu’il accepte la demande.
 Comme la requête était une invitation, l’acceptation du demandé (OK message) contient
aussi ses capacités ainsi que l’adresse sur laquelle il attend les données média. L’appelant
conclut cet échange pour un message ACK.
 Une communication média peut donc être établie en un aller-retour et demi ce qui permet un
établissement de connexion très rapide par rapport à H.323 v1 (6 à 7 aller-retour) mais
comparable à la méthode FastStart de H.323 v2.
 Les terminaux SIP peuvent utiliser UDP ou TCP comme protocole de transport.
 Initiation d’un appel avec le protocole SIP
109
 Architecture du protocole SIP
110

 L'architecture de SIP est basée sur des relations client/serveur.

 Les principales composantes sont
 le terminal (User Agent),
 le Proxy Server,
 le Redirect Server
 et le Registrar.
 Les terminaux
 sont considérés comme clients lorsqu'ils effectuent une requête, et
comme des serveurs lorsqu'ils y répondent.
 peuvent communiquer directement entre eux ou par l'intermédiaire
d'autres serveurs. Les serveurs SIP intermédiaires peuvent se
comporter comme proxy serveur ou serveur de redirection (redirect
server).
 Architecture du protocole SIP
111

 Proxy server:
 joue le rôle de serveur d’un côté (réception de requête) et de client de l’autre
(envoi de requête).
 peut transmettre une requête, sans changement, à la destination finale ou
éventuellement modifier certains paramètres.
 renseigne le champ « via » à chaque fois qu’une requête passe par lui afin que la
réponse puisse prendre le même chemin au retour ; ce qui ne serait pas possible avec
UDP.
 Redirect server:
 répond à une requête SIP « Invite ».
 établit la correspondance entre l’adresse SIP du terminal appelé et la ou les @
où il pourra effectivement être joignable.
 n’est pas chargé d’accepter les appels ni d’émettre des requêtes.
 ne fait que répondre aux requêtes émises par des terminaux SIP appelants.
 Architecture du protocole SIP
112

Exemples :
 Réponse 300 l’URL SIP peut être contactée à différentes adresses

 (ex :sip :robert_gsm@[Link], sip :robert_home@[Link])

 Réponse 301 l’URL SIP ne peut plus être contactée à cette adresse mais à la
nouvelle adresse indiquée
 Réponse 302 redirection du client vers une adresse mais de façon provisoire.

Registrar server
Un registrar est un serveur qui traite les requêtes « Register » et peut aussi avoir la
fonction de proxy. Sa fonction est de connaître l’endroit où se trouve un
usager et de fournir cette information au proxy et au redirect server. En effet pour
pouvoir joindre un usager à partir d’une @ SIP, il faut faire une correspondance
avec une @ IP qui peut être variable (mobilité IP) : c’est le rôle du registrar.
 Enregistrement d’un terminal SIP
113
 Localisation d’un usager
114

 La localisation physique d’un usager s’effectue en deux étapes. L’URL SIP

permet à l’usager appelant de localiser le SIP server. Celui-ci sera la
destination du message « Invite » initial. Soit le serveur connaît l’adresse
physique de l’usager appelé et il permettra l’établissement d’une connexion,
soit il redirige la requête vers un autre lieu où il sait que l’appelé pourra être
joint.
 Le fait que l’URL SIP pointe sur un serveur et non sur l’usager terminal
donne à ce dernier une plus grande mobilité. Cela permet aussi de
soulager le serveur DNS qui n’a qu’à connaître l’adresse du serveur et
non de tous les terminaux reliés au serveur.
 Session Description Protocol (SDP)
115

 Le protocole SDP (RFC 2237)

 protocole qui décrit les sessions audio, vidéo et multimédia.
 utilise des caractères ASCII et donne les informations nécessaires à
l’établissement d’une communication multimédia telles que l’identité de l’initiateur de la
session, la bande passante disponible, les codeurs utilisés.
 Adressage SIP
116

 Les adresses URL utilisées par le protocole SIP sont similaires à celles
du Web où la forme ressemble à une adresse email de la forme
user@host.
 Les URL SIP peuvent prendre différentes formes :
 Martin@[Link] qui est l’adresse du PC de Martin dans le domaine arcome.
 0146124200@[Link] ; user=phone qui correspond à l’adresse d’un téléphone
accessible par une passerelle.
 guest312@[Link] qui est l’adresse d’un utilisateur nomade connecté sur le
LAN d’Arcome.
 Initiation d’un appel avec SIP
117
 Communications multi-utilisateurs SIP
118

 Peuvent être initiées, par SIP, en utilisant le mode multicast ou en

établissant les communications des différents utilisateurs avec un
serveur (équivalent du MCU en H.323) chargé de centraliser et de
synchroniser les flux puis de le retransmettre à chaque participant.
 Comparaison de SIP et H.323
119
 Comparaison de SIP et H.323
120

 H.323 est issu d’une adaptation des protocoles RTC au réseau en mode
paquet.
 SIP
 a l’avantage d’utiliser nativement des protocoles utilisés sur les réseaux IP (il
est basé sur des technologies issues du monde de l’Internet), ce qui permet
une diffusion plus grande, pour le développement d’applications et de services.
 a été choisi comme protocole de contrôle d’appel pour la voix sur IP dans la
release R5 de la norme UMTS.
 a aussi été retenu par Microsoft comme protocole d’établissement d’appel pour
ses serveurs et ses terminaux.
 protocole de contrôle d’appel sur lequel s’appuie l’architecture « Web services
» qui est l’un des deux modèles de services. Cependant, les services proposés
par SIP ne sont pas encore à un niveau suffisant pour offrir les services de
téléphonie classique ; l’ajout de ces nouvelles fonctionnalités alourdira le
protocole.
 Comparaison de SIP et H.323
121

 H.323 et SIP bien que issus de contextes très différents ils permettront
d’offrir de nouveaux services (mobilité, service multimédia multi-terminaux),
en plus de ceux déjà existants sur les réseaux classiques.
 La plupart des constructeurs propose les deux solutions mais semble
privilégier la convergence vers SIP.
Gestion de la QoS de bout en bout avec SIP
122
ou H.323 : protocoles RTP et RTCP

 Les protocoles RTP et RTCP garantissent la qualité des communications

multimédia en mode paquet (gestion et contrôle des flux temps réel).
Pouvant être mis en œuvre au-dessus d’IP, ils sont utilisés par les deux
protocoles de contrôle d’appel SIP et H.323.
 UDP est préféré à TCP pour les transmissions « temps réel »
 RTP
123

 RTP fournit des services tels que le séquencement temporel, la détection des
pertes, la sécurité et l’identification du contenu. Ce protocole a été défini pour
diffuser aussi bien en mode multicast qu’en mode unicast.
 Il peut donc aussi bien être utilisé pour le transport unidirectionnel (broadcast) de
vidéo sur demande que pour la téléphonie sur IP.
 RTP est utilisé en association avec le protocole de contrôle RTCP qui fournit
les informations nécessaires sur la qualité de transmission des données et
sur les participants aux sessions multimédia.
 Cependant RTP ne fournit pas de lui-même les mécanismes nécessaires à la
gestion des informations « temps réel ». Pour cela, les couches protocolaires
inférieures doivent mettre en oeuvre des solutions nécessaires à ces données
sensibles au délai.
 Fonctionnement de RTP (Real time
Transport Protocol)
124

 Les paquets envoyés sur un réseau IP ont une gigue et un délai de transmission
imprévisibles. Cependant les applications multimédia requièrent des
caractéristiques appropriées à la transmission et la gestion des applications dites «
temps réel ».
 RTP fournit, pour chaque paquet, un marquage temporel, un numéro de
séquence et d’autres paramètres permettant d’offrir un transport, de bout en
bout, des données « temps réel » sur un réseau en mode paquet.
 Le marquage temporel
(« timestamping »)
125

 Est l’information la plus importante pour les applications « temps réel ».

L’émetteur envoie un marqueur temporel qui donne l’instant où le premier
octet du paquet a été traité.
 A l’arrivée, le récepteur utilise le marqueur temporel pour reconstruire le flux
multimédia de sorte qu’il puisse être correctement présenté, dans un délai
approprié, à l’utilisateur final. Cependant, ce n’est pas RTP lui-même qui
gère la synchronisation des paquets, il fournit simplement les outils.
 La synchronisation est effectuée au niveau de la couche applicative.
Comme UDP ne fournit pas forcément les paquets dans l’ordre dans lequel
ils ont été émis, les numéros de séquence sont utilisés pour ordonner
les paquets à l’arrivée. Ils sont aussi utilisés pour la détection des
paquets perdus.
 L’identifiant du type de données
(« payload type identifier »)
126

 Spécifie le format des données contenues dans le paquet.

 La connaissance de cette information permet à l’application réceptrice de
savoir comment gérer les données utiles du paquet.
 Les différents types de données sont définies dans la RFC 1890.
 A un instant donné, l’émetteur de flux RTP ne peut envoyer qu’un type de
données, cependant il est possible d’en changer lors d’une transmission, du
fait , par exemple, d’une congestion réseau.
 RTP donne aussi un identifiant de l’émetteur permettant au récepteur de
connaître la provenance des données.
 Session RTP
127

 Les paquets RTP et RTCP sont généralement transportés sur UDP/IP,

 Pour débuter une session RTP, l’application définit une paire particulière
d’adresses transport (adresse IP et port UDP) de destination.
 Dans une session multimédia, chaque média est transporté sur une
session RTP différente pour laquelle sont émis des paquets de
contrôle (RTCP).
 Ainsi l’audio et la vidéo sont transportés sur des sessions différentes,
ce qui permet à l’utilisateur final de choisir le média qu’il désire recevoir.
 RTP/RTCP dans la suite de protocole
pour services multimédia
128
 Fonctionnement de RTCP
129

RTCP est un protocole défini pour être utilisé en addition de RTP. Il est
standardisé par la RFC1889 et RFC 1890.
Dans une session RTP, chaque participant envoie périodiquement des paquets
RTCP donnant des informations sur la qualité de la transmission.
 Types de paquets de contrôle RTCP
130

Il existe 5 types de paquets pour transporter cette information de contrôle :

RR: « receiver report ». Les rapports des récepteurs sont envoyés par les terminaux qui ne sont pas des
participants actifs à la communication. Ils contiennent des informations sur les données reçues, dont le
numéro du dernier paquet reçu, la valeur moyenne de la gigue et le « marqueur » temporel qui permettra de
calculer le délai de transmission entre l’émetteur et le récepteur.
• SR: « sender report ». Les rapports des émetteurs sont émis par les terminaux actifs. En plus des
informations données par le « receiver report », ils donnent des informations concernant la synchronisation
inter-média, le nombre de paquets et d’octets émis.
• SDES: « source description items ». Contient des informations décrivant la source émettrice.
• BYE: indique la fin de la participation d’un participant à une session.
• APP: fonction utilisée par des applications spécifiques.
Grâce à ces données, RTCP fournit des informations pour les services de gestion de la QoS et contrôle
de congestion de niveaux supérieurs.
 Types de paquets de contrôle RTCP
131

La gestion de QoS de bout en bout impacte toutes les couches d’un réseau NGN,
depuis les terminaux jusqu’aux applications, en passant par les protocoles de
gestion de niveau intermédiaire (situés entre les couches Contrôle et Service)
comme RTP et RTCP.
 Contrôle des “Media Gateways” : deux
protocoles candidats
132

 La nécessité d’interconnecter les réseaux de téléphonie classique aux

NGN, ainsi que la flexibilité apportée par la séparation des couches
Transport et Contrôle ont conduit à la distinction des fonctions de Media
Gateway (MG) et de Media Gateway Controller (MGC).
 Il a donc été nécessaire de développer un protocole permettant aux MGC
de piloter les MG.
 Le protocole de commande de passerelle
l'interface MGC-MG
133

Permet la communication entre la MG et le MGC : c’est le canal de communication utilisé pour

coordonner le plan Contrôle et le plan Transport. Les principales fonctions de ce canal
sont :
 La réservation des ressources de la MG par le MGC nécessaire pour satisfaire les demandes
reçues par les messages de signalisation.
 Le traitement des connexions dans la MG par le MGC.
 La modification des paramètres internes de la MG.
 La remontée par la MG des réponses aux actions demandées par le MGC.
 La notification par le MG d’événements survenus au niveau média (détection DTMF...).
 Le contrôle du lien MG-MGC (sécurité du lien, basculement vers un autre MGC ou MG…).
 Le protocole de commande de passerelle
l'interface MGC-MG
134

 Ces nouveaux protocoles sont apparus en 1998 avec le IPDC et le SGCP qui ont
rapidement fusionner en MGCP.
 L’IETF créa dans le même temps un groupe de travail appelé MEGACO (MEdia
GAteway COntrol) pour standardiser un protocole pour l’interface MGC-MG.
 Finalement, l’UIT et l’IETF décidèrent en 1999 de collaborer sur un protocole
commun nommé H.248 pour l’UIT et MEGACO pour l’IETF.
 Le protocole historique : MGCP
135

Le Media Gateway Control Protocol (MGCP, RFC 2705), protocole défini par l’IETF,
a été conçu pour des réseaux de téléphonie IP utilisant des passerelles
VoIP. Il gère la communication entre les MG et les MGC. Ce protocole traite la
signalisation et le contrôle des appels, d’une part, et les flux média d’autre part.
Les différents éléments qui utilisent MGCP sont :
• La SG qui réalise l’interface entre le réseau de téléphonie (signalisation SS7)
et le réseau IP. Elle termine les connexions des couches basses de SS7 et
transmet les messages ISUP à la MGC.
• Le MGC ou Call Agent qui opère l’enregistrement, la gestion et les contrôles
des ressources des MG. Elle coordonne
l’établissement, le contrôle et la fin des flux média qui transitent par la MG.
• La MG qui est le point d’entrée ou de sortie des flux média à l’interface avec
les réseaux IP et téléphoniques. Elle effectue la conversion des médias entre le
mode circuit (téléphonique) en le mode paquet (IP).
 Le protocole alternatif : MEGACO/H.248
136

 MEGACO complète les travaux sur le protocole MGCP au sein de l’IETF. Depuis
1999, l’UIT et l’IETF travaillent conjointement sur le développement de MEGACO/
H.248 ; c’est un standard permettant la communication entre les MGC et les MG. Il
est dérivé de MGCP et possède des améliorations par rapport à celui-ci :
 Support de services multimédia et de vidéoconférence
 Possibilité d’utiliser UDP ou TCP
 Utilise le codage en mode texte ou binaire
 Première version de H.248 a été adoptée en juin 2000 (RFC 3015 de l’IETF).
 L’implémentation de H.248 permet une grande modularité ; en effet, ce protocole
est étendu par des « packages » répondant à des besoins spécifiques. Ce
système permet de couvrir un nombre très important d’applications, mais
complique aussi grandement les interfonctionnements d’équipements
d’origine différente. Ainsi un constructeur peut implémenter, suivant ses besoins,
tel ou tel « package » qui ne sera pas obligatoirement choisi par un autre
constructeur.
 Positionnement de MGCP et
H.248/MEGACO dans les NGN
137
 Comparaison de MGCP et
MEGACO/H.248
138

 Actuellement les solutions de commande de passerelle utilisent le plus

fréquemment le protocole MGCP.
 Il semble que la mise en place de H.248 pousse les acteurs à
converger à moyen terme vers ce protocole : c’est en effet le seul
protocole ayant le statut de norme puisqu’il est reconnu non
seulement à l’IETF (MEGACO) mais aussi à l’UIT (H.248).
 Il est donc encore difficile de savoir lequel de MGCP ou H.248 sera «
LE » protocole de commande de Media Gateway, ou plus exactement si
(et quand) H.248 parviendra à s’imposer comme le standard.
 Relation entre MGCP, H.248, SIP et H.323
139

Protocole de commande impliqués dans les NGN

MGCP et H.248 sont des protocoles complémentaires à SIP et H.323. Ils sont
définis spécialement comme un protocole interne entre MGCs et MGs.
Les MGCs gèrent le traitement des appels du réseau IP en communiquant avec
les éléments de signalisation IP (gatekeeper H.323 ou serveur SIP), souvent co-
localisés avec le MGC, et le réseau téléphonique via une passerelle de
signalisation.
Transport de la signalisation SS7 sur réseaux
IP : le protocole SCTP (SIGTRAN)
140

 SIGTRAN: Transport des messages de signalisation SS7 et RNIS sur des

réseaux IP. SIGTRAN définit le protocole de contrôle entre :
 Les SG, qui reçoivent la signalisation SS7 sur TDM, et la convertissent en SS7
sur IP.
 Les MGC, qui interprètent la signalisation SS7 sur IP.
 Et les « signalling points » du réseau IP (serveurs de contrôle d’appel).
 Ce protocole utilise une nouvelle couche de transport appelée Stream Control
Transmission Protocol (SCTP) permettant de pallier les défauts du protocole TCP
pour la gestion des messages de signalisation.
 Associé à des couches d’adaptation spécifiques à chaque protocole de
signalisation d’origine (généralement SS7), le protocole SCTP doit permettre
de transporter les messages de signalisation de façon transparente sur des
réseaux IP.
 Objectifs de SIGTRAN
141

Les couches d’adaptation définies par SIGTRAN ont toutes des objectifs communs :
 Le transport des protocoles de signalisation des couches supérieures, basé sur un
transport IP fiable.
 La garantie d’une offre de services équivalente à celle proposée par les
interfaces des réseaux RTC.
 La transparence du transport de la signalisation sur un réseau IP : l’utilisateur final
ne se rend pas compte de la nature du réseau de transport.
 La possibilité de pouvoir supprimer dès que possible les couches basses du
protocole SS7.
 SIGTRAN a déjà défini plusieurs couches d’adaptation :
 La couche d’adaptation M2UA qui fournit le service MTP2 dans une relation client/serveur telle que
la communication entre SG et MGC.
 La couche d’adaptation M2PA qui fournit le service MTP2 dans une relation « peer to peer » telle
que la communication entre SG et SG.
 La couche d’adaptation M3UA qui fournit le service MTP3 dans une relationclient/serveur ou « peer
to peer » .
 Architecture SIGTRAN
142

Couche d’adaptation M2UA fournie par SIGTRAN

 Protocoles candidats pour la signalisation
« de transit » entre serveurs d’appel
143

 Les opérateurs de télécommunications, voyant la montée en puissance du trafic de

données, ont émis le souhait de pouvoir utiliser des solutions de signalisation de
transit pour les réseaux en mode paquet.
 Pour cela, il était nécessaire de définir un protocole permettant la communication
entre MGC (Media Gateway Controller). Ce protocole ne remet pas en cause les
protocoles de commande de passerelles, mais au contraire, permet d’élargir le
domaine d’action des protocoles tels que MGCP ou H.248/MEGACO.
 Trois protocoles sont candidats pour cette utilisation : BICC, H.323 et SIP-T.
 Bearer Independent Call Control (BICC)
144

Objectif: la gestion de la communication entre serveurs d'appel,

indépendamment du type de support, permettant aux opérateurs de
réaliser une migration de leurs réseaux RTC/RNIS vers des réseaux en
mode paquet.
En vue, donc, d’une migration des réseaux téléphoniques (SS7) vers une
architecture NGN, une recommandation de l’UIT, le protocole BICC, doit
étendre l’ISUP. En effet BICC est en grande partie issu de l’ISUP ; les
recommandations font d’ailleurs directement référence à l’ISUP, quant à
sa définition mais aussi pour l’interopérabilité avec H.323.
 Bearer Independent Call Control (BICC)
145

Version1: BICC CS1 (BICC Capability Set 1) définit le transport de signalisation sur
un réseau ATM en tant que réseau de transit.
Version2:BICC CS2, élargit son rayon d’action et les capacités. Il permet :
 L’utilisation d’un réseau IP comme réseau de transit. Il s’agit de « tunnelling » de messages
de signalisation par BICC sur un réseau de transport IP, de passerelle à passerelle (SG), donc
transparent pour les MGC du réseau IP.
 L’interfonctionnement avec les réseaux H.323:La version de BICC (CS3) porte
principalement sur le réseau d’accès et l’interfonctionnement avec SIP.
Le protocole BICC est compatible avec les protocoles de contrôle d’appel SIP et
H.323 qu’avec un transport en mode IP ou ATM. C’est donc un candidat
potentiel sérieux qui prend a priori en compte toutes les configurations de réseau
(tendance « données » ou « télécoms »).
 Protocole H.323 entre Media Gateway
Controller
146

Sur des réseaux IP

Dans les réseaux IP, la norme H.323 utilise les standards H.225 et H.245 pour
la gestion des commandes d’appel. A l’origine, ces canaux de signalisation
étaient créés entre le terminal H.323 (téléphone ou passerelle H.323/ RNIS)
et le serveur d’appel H.323.
L’évolution de la norme H.323, par la possibilité de communiquer entre
serveurs d’appel H.323 et par la séparation en éléments distincts des
fonctions MG et MGC, a quelque peu modifié la norme.
Il est établi que la signalisation des appels et la synchronisation (H.225) se
passent entre MGC ; par contre le protocole utilisé pour l’échange des
capacités entre les terminaux, la négociation de canal et le contrôle de flux
média entre les terminaux H.323 (H.245) peut s’effectuer entre MG ou
MGC.
 Interfonctionnement de H.323 avec les
protocoles SS7
147

Interconnexion avec des réseaux SS7 (ISUP)

 L’interfonctionnement de H.323 avec le protocole ISUP a été défini
récemment (annexe C de H.246).
 Il établi la correspondance entre les messages ISUP et H.323 pour les appels IP-
RTC et RTC-IP, ainsi que l’interaction de certains services téléphoniques (ex :
mise en attente d’appel, restriction et autorisation de divulgation de l’identifiant de
l’appelant…).
 Interfonctionnement de H.323 avec les
protocoles SS7
148

Encapsulation ISUP dans H.323

 Dans le cas où le réseau IP est utilisé comme réseau de transit, il ne semble
pas pertinent de réaliser deux interconnexions (H.323/ISUP puis ISUP/H.323)
avec une perte d’information (H.323 est basé sur Q.931, protocole d’accès et non
de transit).
 La transmission des messages ISUP, de manière transparente sur le réseau
IP est la solution plus pertinente.
 Une première ébauche de solution est proposée dans la version 4 de H.323
par encapsulation des messages ISUP dans H.225.
 Protocole SIP entre MGC : SIP-T
149

 L’Internet Draft SIP-T (SIP pour la téléphonie) de l’IETF définit la gestion de

la téléphonie par le protocole SIP ainsi que l’interconnexion avec le RTC :
cependant uniquement avec le protocole SS7 ISUP. SIP-T préconise :
 l’encapsulation des messages ISUP à l’intérieur de messages SIP,
permettant la transmission de façon transparente de la signalisation ISUP dans
le cas de transit par un réseau IP.
 le renseignement de l’en-tête du message SIP par les informations
contenues dans le message ISUP, permettant d’acheminer le message
correctement à travers le réseau IP et de terminer les appels sur un terminal SIP.
 Protocole de signalisation entre MGC
150

A moyen/long terme concernant le choix du protocole de contrôle d’appel (plutôt SIP au

détriment de H.323) et au vu du support important de BICC dans le domaine télécoms,
le choix du protocole de signalisation entre serveurs d’appel NGN se fera
vraisemblablement entre BICC et SIP-T.

Trois protocoles BICC, SIP-T et H.323

sont en concurrence.
 Cohabitation des réseaux existants et NGN
151

 Il semble que les réseaux actuels persisteront pour une période relativement
longue et donc que la coexistence des réseaux actuels et NGN sera
effective pendant plusieurs années, voire décennies.

Interconnexion de réseaux
 Exemple d’architecture de système
152
global NGN : l’UMTS

 Dans le domaine des réseaux mobiles, le système UMTS, dans sa

deuxième phase, évolue dans sa globalité vers une architecture type
NGN, tant sur le plan de l’architecture physique que pour le choix des
protocoles.
 UMTS release 99 : l’héritage du GSM/GPRS
153

L’architecture UMTS telle que décrite dans la release 99 du 3GPP s’appuie sur une nouvelle interface radio,
l’UTRA, et une évolution des coeurs de réseau GSM et GPRS (adaptation des équipements existants
ou nouveaux équipements) pour gérer les flux des domaines circuit et paquet.
Dans l’architecture UMTS R99 :
 Les interfaces de l’UTRA avec le cœur de réseau sont basées sur un transport ATM (AAL2 pour
la voix, AAL5 pour les données).
 Le transport dans le coeur de réseau peut ensuite être effectué (au choix de l’opérateur) soit en
ATM pour l’ensemble des flux, soit en ATM puis TDM pour les flux circuit et en IP pour les flux
paquet. La signalisation à l’interface avec l’UTRA est transportée soit dans des circuits virtuels ATM,
soit avec le protocole de transport de SS7 sur IP SIGTRAN.
 Les appels multimédia sont supportés, mais de manière transparente. En effet, les messages de
signalisation multimédia sont transportés de manière transparente dans une connexion circuit ou dans
un contexte PDP (tunnel GTP entre SGSN et GGSN), ce qui évite d’introduire des fonctions multimédia
dans les équipements GSM et GPRS, limitant les impacts aux terminaux et à l’ajout de serveurs
multimédia (gatekeepers). Les protocoles de contrôle d’appel multimédia retenus sont H.323 pour le
domaine paquet et H.324-M pour le domaine circuit, choix plus conforme à la maturité actuelle des
protocoles (par rapport à SIP). Cependant, le transport de la signalisation multimédia étant transparent,
SIP pourrait a priori être supporté de la même manière.
 UMTS release 99 : l’héritage du GSM/GPRS
154

 La R99 prépare donc l’évolution vers la solution cible tout IP en

introduisant dès les débuts de l’UMTS un transport convergent des flux voix et
données.
 Les versions ultérieures de la norme UMTS intègrent une évolution encore plus
nette vers une architecture de type NGN.
 La release R4 (ex-R99) est la première étape vers un cœur de réseau tout IP, et
la release R5 finalise cette évolution.
UMTS releases R4/R5 : l’évolution vers le tout
IP multimédia avec une architecture NGN
155

 R4 propose une architecture résolument novatrice afin d’évoluer vers le

tout IP multimédia.
 Suite aux discussions techniques au sein du 3GPP et afin de prendre en
compte la maturité des produits et solutions nouvelles, les évolutions de
l’UMTS prévues dans cette version ont été échelonnées dans le temps et
réparties sur deux versions successives, rebaptisées R4 et R5.
 UMTS Release R4 : séparation des
couches transport et contrôle
156

 Conformément à l’un des concepts de base des NGN, la version R4 de la norme

UMTS prévoit une évolution optionnelle du domaine circuit, sous la forme d’une
restructuration fonctionnelle des MSC pour introduire une séparation des
couches Transport (Media Gateway) et Contrôle d’appel (MSC server).
 Le MSC server a les mêmes caractéristiques qu’un MGC, avec en complément
des fonctions spécifiques mobile. Il est ainsi en mesure de dialoguer avec les
autres MSC server en utilisant le protocole BICC ou SIP-T selon que le
protocole de transport utilisé est ATM ou IP, mais conserve notamment des
liens de signalisation utilisant le protocole MAP avec les HLR.
 La signalisation de commande entre MSC server et MGW utilise le protocole
H.248 avec des extensions spécifiées par le 3GPP.
 Cette signalisation peut être transportée en utilisant le protocole MTP3b si le
transport s’appuie sur une couche ATM, ou SIGTRAN (SCTP) si le transport
s’appuie sur IP.
 Architecture domaine circuit UMTS
Release R4
157

3GPP (2001): la séparation des couches transport et contrôle dans le domaine

paquet (équipements SGSN et GGSN) permet à certains constructeurs de proposer
des variantes d’implémentation. Le protocole H.248 est alors pressenti, de manière
similaire au domaine circuit, pour assurer la signalisation entre les serveurs paquet et
les MGW.
 UMTS Release R5 : ajout du domaine
IP multimédia
158

 La release R5 introduit un nouveau domaine, l’IMS, s’appuyant sur les services

du domaine paquet pour fournir des services de communications convergents
(voix sur IP, données, multimédia…) en IP natif.
 Ainsi, les communications multimédia ne sont plus supportées de manière
transparente mais deviennent le mode de communication cible de l’UMTS.
 Ce n’est que pour des raisons de compatibilité avec les réseaux GSM/GPRS et
UMTS R’99 et avec les terminaux non IP multimédia que le domaine circuit (MSC
servers et MGW associées) est maintenu.
 Le coeur de réseau UMTS IP multimédia utilise le protocole SIP pour gérer les
sessions IP multimédia, et le protocole IP pour le transport du trafic et de la
signalisation associés. Il supporte l’interfonctionnement avec les réseaux voix et
données IP fixes et mobile existants, y compris Internet.
 Protocoles de contrôle d’appel
159

 Le choix du protocole de contrôle d’appel pour les appels VoIP et multimédia a

fait l’objet de longues discussions, mais SIP a fini par s’imposer au 3GPP grâce
à son caractère IP natif et son apparente simplicité comparé à H.323.
 Le protocole SIP de l’IETF doit cependant être enrichi pour prendre en
compte certaines évolutions spécifiées par le 3GPP pour un usage dans
le coeur de réseau UMTS, notamment concernant les spécificités liées à la
gestion de la mobilité.
 Architecture de référence Release 5
160
(3GPP TR 23.821)
 Contrôle d’appel et gestion de la
signalisation
161

 Pour assurer le contrôle

d’appel et la gestion de la
signalisation dans ce
nouveau domaine, de
nouvelles entités sont
ajoutées, ou des
équipements existants
sont modifiés.
 Caractéristiques de UMTS R5
162

 Gestion de la mobilité: le HSS UMTS est chargé de la mise à jour du profil utilisateur, et
peut intégrer ou coopérer avec des entités standards dans le monde IP, comme un serveur
distant d’authentification et d’autorisation (RADIUS) ou un serveur gérant la résolution
d’adresse et l’allocation dynamique d’adresse IP (fonctions DNS et DHCP).
 Le transport IP se généralise progressivement à l’ensemble du réseau, et IPv6 est
introduit dans le coeur de réseau :
 Les interfaces de transport en sortie de l’UTRA, qui étaient de type ATM en R99,
évoluent en IP en R5 (l’évolution du transport en IP au sein de l’UTRA et sur la voie
radio étant prévue pour des étapes ultérieures de la norme).
 Le protocole de transport spécifié pour le domaine paquet est IP (entre RNC,
SGSN et GGSN), avec support des options IPv4 et IPv6.
 Au sein du domaine IP Multimédia (éléments IP multimédia du cœur de réseau + équipements
terminaux associés), la norme spécifie l’utilisation exclusive d’IPv6, et un usage optimal d’IPv6
doit être fait.
 Interopérabilité IPv4/IPv6 : les équipements terminaux IP multimédia doivent pouvoir
accéder à des applications IPv4 et IPv6, et le coeur de réseau doit assurer si nécessaire
l’interopérabilité entre son transport IPv6 et un réseau IPv4 externe.
 Conclusion
163

 Signalisation de contrôle d’appel : SIP vs H.323

 SIP: choisi pour sa simplicité et son utilisation des technologies et format « web ».
 H.323: est identifié comme un protocole plus lourd que SIP, notamment pour la gestion du
transit. Il fut, historiquement, le premier standard disponible.
 Signalisation de commande des Media Gateways : Megaco/H.248 vs MGCP
 Megaco/H.248 :semble être la cible identifiée par la plupart des acteurs. Mais du fait de la
plus grande maturité des offres (du moins pour certains constructeurs), MGCP pourrait être
largement utilisé à court terme.
 Signalisation de transit : BICC vs SIP-T
 BICC prévu initialement pour le transport de la signalisation entre serveurs de contrôle sur
ATM, et SIP-T sur IP. Les deux protocoles évoluent en fait pour supporter les deux modes
de transport. Il est possible que le consensus qui se dessine autour de SIP pour le contrôle
d’appel bénéficie à terme à SIP-T.
 Conclusion (2)
164

 Solutions « call server » globales ou spécialisées :

 Les deux solutions existent. Les petites sociétés nouvelles développant des
softswitch semblent privilégier des solutions « call server » spécialisées, avec
séparation des fonctions call agent (gestion de l’interface avec le réseau tiers,
pilotage des media gateways) et des fonctions spécifiquement Class IV (contrôle
d’appel de niveau transit) ou Class V (contrôle d’appel de niveau accès).
 Conclusion (2)
165

Signalling gateway séparée, ou intégrée :

La fonction Signalling Gateway peut être implémentée de différentes manières:
 Implémentée sur un équipement dédié, ce qui nécessite notamment une gestion des
interconnexions spécifique (signalisation quasi-associée : acheminement séparé du
trafic et de la signalisation). Ce type d’architecture est encore mal connu des
opérateurs téléphoniques classiques.
 Intégrée dans les Media Gateways, auquel cas le trafic et la signalisation aboutissent
physiquement sur le même équipement.
 Intégrée dans les serveurs d’appel (avec en général transit via les Media Gateways),
ce qui aboutit à une architecture physique similaire au cas précédent.
 Conclusion (3)
166

 Concernant les réseaux mobiles, ils semblent prendre en compte

l'évolution vers les NGN de manière plus explicite en termes de
Normalisation .
 La maturité des offres de produits fait que les premiers déploiements
NGN s'effectuent plutôt dans le domaine des réseaux et services fixes.
167

Les Services : des plates-formes unifiées

et des interfaces ouvertes
 Les Services : des plates-formes unifiées
et des interfaces ouvertes
168

 L’apparition des nouveaux réseaux d’accès, tels que l’UMTS, le GPRS, l’xDSL,
l’Ethernet longue distance, les réseaux câblés, et la multiplication des terminaux
communicants (téléphone mobile GPRS/ UMTS, PDA,…) et la convergence des
cœurs de réseaux, poussent à une transformation de l’architecture des plates-
formes de services.
 Services multi-réseaux et multi-terminaux
169

La nécessité d’offrir des services multi-réseaux et multi-terminaux a conduit à la

définition de nouveaux concepts et fonctions :
 La portabilité et l’adaptabilité des applications qui permet de fournir les
services sur différents terminaux tout en gardant son environnement
personnalisé (portail, Virtual Home Environment…)
 Pour offrir ces services, adaptables et « portables », il est nécessaire de
déployer de nouveaux protocoles et de nouvelles rchitectures qui feront le
lien entre les plates-formes de services et les utilisateurs connectés aux
réseaux NGN. Ces nouveaux outils (architectures et protocoles) doivent être
utilisables dans des contextes très divers et seront donc des outils ouverts et
convergents permettant de simplifier les communications entre terminaux et
entre terminaux et serveurs d’applications.
Modèles d’architecture de la couche Services
170

 Une architecture centrée sur le « Softswitch », basée sur l’interface de services

normalisée du modèle OSA/Parlay.
 Ce modèle est plutôt adapté pour des services de type « télécoms »
nécessitant une coopération forte du réseau de contrôle d’appel (serveurs,
bases de données).
 Un modèle orienté « Web Services », basé sur les technologies et des
protocoles issus du monde Internet (XML, SOAP) avec une architecture
distribuée plus adaptée à la fourniture de services en mode transparent sur IP,
avec une coopération forte du terminal.
 Alors que le modèle « web services » s’appuie explicitement sur le protocole de
contrôle d’appel SIP, le modèle OSA est a priori indépendant du protocole de
contrôle d’appel retenu, mais semble plus souvent évoqué dans un contexte
d’utilisation de SIP que de H.323.
 VHE « Virtual Home Environment »
171

Concept d’environnement de services personnalisés (Personal Service

Environment ou PSE) défini par le 3GPP dans le cadre de la normalisation de
l’UMTS. Il comprend :
 la personnalisation des services pour des utilisateurs de profils différents
 la portabilité de l’environnement personnalisé de services (PSE) à travers
divers réseaux d’accès (fixe, mobile, IP) et sur des terminaux de natures
différentes.
Ainsi les utilisateurs pourront accéder à leurs services et leur environnement
personnalisé quels que soient le réseau et le terminal qu’ils utilisent. Pour cela la
création des services est basée sur des outils standardisés comme les
interfaces OSA/Parlay, les protocoles CAMEL, MExE, JAVA, CORBA.
 Le modèle VHE
172

 Dans son principe, Dans son principe, le modèle VHE n’a rien de
spécifique aux réseaux mobiles.
 Donc il pourrait être aisément transposé au domaine des réseaux fixes,
domaine qui est d’ailleurs inclus dans le champ d’application de VHE
(hormis les outils CAMEL et MexE, qui sont spécifiques mobile).
 Le modèle OSA/Parlay
173

L’architecture OSA (Open Service Access) propose une interface

standardisée, par les API (Application Programming Interface), pour les
applications en vue d’utiliser les capacités du réseaux sans avoir besoin de
connaître les technologies utilisées.
 objectif : de cacher la complexité des réseaux aux plateformes de services.
 Architecture d’un réseau avec l’interface
OSA
174
 Le modèle OSA
175

 Le modèle OSA est donc partagé et soutenu par un nombre important

d’organisations issues du monde des télécommunications mobiles et
fixes (3GPP, ETSI, Parlay Group) ou transverses aux mondes télécoms et
Internet (JAIN).
 3GPP / OSA
176

 Le 3GPP (3rd Generation Partnership Project) est le fruit d’une collaboration de

plusieurs organismes de standardisation ainsi que la plupart des constructeurs
ayant pour objectif de définir un ensemble de spécifications techniques pour les
systèmes mobiles de 3ème génération.
 En particulier, le 3GPP demande la définition d’une architecture permettant d’offrir
le concept VHE (Virtual Home Environment) ; il a identifié le modèle OSA comme
un des outils nécessaires à la mise en place du concept VHE.
 Le groupe Parlay
177

 Le groupe Parlay est un forum ouvert ayant pour objectif de définir les
spécifications d’une API pour le modèle OSA.
 Cette interface doit permettre aux différents acteurs, opérateurs, programmeurs
et fournisseurs de services, de développer des applications multi-technologies et
multi-réseaux : c’est le lien entre les services et les réseaux.
 L’API permet de supporter les services d’une tierce partie (ASP), en définissant
une infrastructure gérant les échanges sécurisés entre clients et serveurs.
 JAIN (Java APIs for Interoperable Networks)
178

 L’objectif de JAIN Initiative est de créer un ensemble ouvert, depuis les fournisseurs
de services tiers, en passant par les opérateurs et les constructeurs, jusqu’aux fabricants
de terminaux et aux clients finaux. Cet ensemble est défini pour être distribué depuis
n’importe quel protocole et « middleware » tels que RMI (Remote Method
Invocation), CORBA (Common Object Request Broker Architecture) et DCOM
(Distributed Common Object Model).
 L’architecture JAIN s’appuie sur les développements du langage de programmation
JAVA.
 Le service de contrôle d’appel de JAIN est basé sur celui défini par le groupe « Parlay ».
Ainsi, la technologie Java et l’architecture JAIN servent d’outils pour les
réalisations des éléments du modèle OSA.
 L’architecture JAIN Initiative
179

L’architecture JAIN Initiative s’articule autour de deux axes :

 Les spécifications des « Protocol API » qui définissent l’interface avec les
protocoles de signalisation des réseaux fixes, mobiles et IP. Ce sont les API
TCAP, ISUP, MAP, INAP, MGCP, SIP, H.323, MEGACO, ENUM, SDP, …
 Les spécifications des « Applications API » en charge de la définition des API
nécessaires à la création de service, avec l’aide de Java, pour tous les
protocoles couverts par les « Protocol API ». Ce sont les API permettant de gérer
l’interface avec les systèmes de contrôle d’appel mais aussi de développer des
services tels que la gestion de la présence et de la disponibilité, la gestion de la
fourniture de services, la gestion des utilisateurs ou la création d’environnement
utilisateurs.
 Positionnement des API JAIN dans
l’architecture OSA/Parlay
180
 L’architecture du modèle OSA/Parlay
181

La spécification OSA/Parlay définit une architecture permettant aux applications

de services d’utiliser les ressources du réseau telles que le contrôle d’appel, la
gestion de conférence, les informations de localisation.
 Interface standardisée ouverte OSA/Parlay :
 est le lien des plates-formes de services avec la couche Contrôle pour la
signalisation (et avec la couche Transport pour le trafic) et facilite l’accès au
réseau pour les applications de services.
 offre des outils nécessaires au bon fonctionnement des services, tels que la
gestion de la sécurité (authentification, autorisation), des utilisateurs (profil, état) et le
contrôle d’appel.
 Fonctions de la « passerelle »
OSA/Parlay
182

 Le « Framework », responsable du contrôle d’accès au service et de la

gestion des ressources attribuées à ces services.
 Les « SCS » ou « Service Capability Servers » qui fournissent l’interface
vers les applications. Chaque SCS est vu par les applications comme un
ou plusieurs SCF.
 Les « SCF » ou « Service Capability Features » qui adaptent les services
aux capacités du réseau accessible par l’API OSA/Parlay.
 L’interface OSA/Parlay (source API group)
183
 L’interface OSA
184

 Trois types d’interfaces qui composent l’API OSA :

 Les interfaces entre les applications et le « Framework » qui fournit les
fonctionnalités de base (ex : authentification, autorisation) pour accéder aux
fonctionnalités des réseaux.
 Les interfaces entre les applications et les SCF, qui sont les outils
nécessaires aux utilisateurs pour accéder, via l’interface OSA, aux services
délivrés par des tiers.
 Les interfaces entre le « Framework » et les SCF qui offre la possibilité de
gérer les environnements d’équipements provenant de constructeurs
différents.
 Framework
185

 L’un des SCS de l’interface Parlay/OSA est appelé le « Framework ». Il est

indispensable au bon fonctionnement des services car il gère :
 Les fonctions d’authentification des applications pour accéder au réseau.
 Les fonctions d’autorisation pour les applications à utiliser certains SCF et données
clients, et, pour les clients, à utiliser une application (vérification d’inscription).
 Les fonctions de découverte des SCF, permettant aux applications d’obtenir des
informations sur les SCF accessibles.
 La gestion d’établissement de services pour les applications qui doivent accepter
«en ligne » le contrat d’offre de services.
 La gestion de l’intégrité des services : gestion de la qualité du service rendu.
 La gestion de l’enregistrement des SCF.
 SCF
186

 Les SCF sont l’interface entre les services et le réseau et donc les utilisateurs.
 Les fonctionnalités des SCF sont donc focalisées sur la gestion des utilisateurs
et des sessions d’accès aux services.
 Exemples de SCF définies
187

 L’interaction avec l’utilisateur pour obtenir des informations sur celui-ci, lui transmettre
des messages écrits ou vocaux.
 La localisation et les caractéristiques de l’utilisateur final
 Le traitement des caractéristiques du terminal utilisé
 Le contrôle des sessions avec l’utilisateur
 La gestion de l’accès à la messagerie
 La gestion de la qualité de service
 La gestion des comptes client
 L’évolution du contrôle d’appel multimédia
 Le service de présence
 La recherche des capacités réseaux
 La gestion des profils des usagers
 Les « WEB SERVICES » :
Une architecture alternative au modèle OSA/Parlay
188

 Le modèle de fourniture de services « OSA/Parlay »: orienté vers l’architecture centrée sur les Softswitches.
 « Web Services »: un autre modèle pour les réseaux NGN basé sur une architecture et des protocoles
orientés « web », définit un modèle beaucoup plus distribué.
 En l’an 2000, le W3C (World Wide Web Consortium) a créé le « XML Protocol Activity » pour standardiser un
protocole de communication inter-applications basé sur XML. En 2002, sous l’impulsion notamment de
Microsoft, IBM, Sun et Oracle, l’action de ce groupe a été étendue à l’ensemble des aspects des « Web
services » et IP et s’appelle désormais le « Web Services Activity ».
 Un « Web service » est une interface ouverte qui décrit un ensemble d’opérations qui sont accessibles
dans le réseau en utilisant un format standard de messages XML.
 La description du « Web service » définit l’ensemble des interactions avec le service, incluant le format des
messages, les protocoles de transport et de localisation. Cette interface permet d’implémenter les services
indépendamment des plates-formes logicielles et matérielles sur lesquelles ils sont installés et des
langages dans lesquels ils ont été écrits. Alors que le « Web » permet une interaction entre un utilisateur et
un programme, les « Web services » permettent d’établir un moyen de communications entre
programmes.
 Architecture du modèle « Web services »
189
 Accès aux « Web services »
190

 L’accès à ces « Web services » peut s’effectuer directement dans une

simple session client/serveur, cependant il semble que l’on s’oriente vers un
accès aux services à travers des portails qui seront chargés des fonctions
d’authentification des clients, des recensements des services et de
facturation de services.
 Pour offrir une réelle interaction entre programmes, les « web services »
sont basés sur des standards existants ou émergents, tels que HTTP, XML
(Extensible Markup Language), SOAP (Simple Object Access Protocol),
WSDL (Web Services Description Language) et UDDI (Universal
Description, Discovery and Integration).
 Web services
191

 Ce modèle de fourniture de services est fortement associé au protocole

SIP. En effet, il est indispensable, pour accéder aux « Web services »,
d’établir une « session » client/serveur : c’est le rôle du protocole de
commande d’appel, SIP.
 Exemple : les Web Services .NET (de Microsoft), Websphere (d’IBM) et
J2EE (de Sun)
 Solution « web services » .NET de
Microsoft
192

 La stratégie .NET de Microsoft a pour objectif de créer un architecture orientée vers

les « web services ». Cela inclut :
 Les serveurs sur lesquels repose l’infrastructure.
 Les « Web services », architecture permettant l’accès formaté à
l’information multimédia et à la création d’applications web.
 Les outils permettant la création des « web services » (Visual Studio .NET)
 Les briques de « base » : authentification (Passport .NET), gestion du
calendrier, de la messagerie unifiée. Par exemple, l’offre .NET Passport décline
la notion d’accès en mobilité / depuis n’importe quel réseau aux services et aux
contenus Internet. Elle est aussi liée au développement croissant des services
de type e-commerce. Elle inclut des services de connexion unique sécurisée, de
portefeuille électronique, de contrôle de confidentialité des données transmises.
 Solution « web services » de IBM:
Websphere
193

 Le WebSphere Telecom Application Server d’IBM est une plate-forme de

création et de développement de services pour les NGN, indépendante des
réseaux et des solutions de transport, qui s’appuie sur la technologie Java (API
JAIN).
 Des interfaces de « selfprovisioning » de services peuvent être développées via
la solution Websphere Studio. La solution s’intègre aux réseaux téléphoniques,
ainsi qu’aux autres plates-formes de la suite Websphere d’IBM (Commerce
Suite, Voice Server…).
 Solutions « Web services » de Sun Microsystems :
J2EE (Java 2 Enterprise Edition).
194

 Cette plate-forme permet de développer des applications d’entreprises

distribuées et portables dans différents environnements, basées sur des
composants standards et modulaires.
 Elle s’appuie notamment sur les technologies Java, Corba et XML.
 OSA et Web Services
195

 Contrairement au modèle OSA, le modèle Web Services est déjà mis en

application par de grands industriels du domaine logiciel (bien que
cette mise en œuvre se limite à l’accès Internet).
 Cela s’explique par l’architecture-même de ce modèle de services qui sont
distribués, donc relativement indépendants du réseau et exécutables de
manière transparente avec un niveau d’ouverture faible des réseaux.
 Les protocoles utilisés pour les « Web
services »
196

 Les « Web Services » reposent sur des protocoles qui forment la

couche d’adaptation pour la fourniture des services. Il s’agit de
protocoles utilisant le format XML :
 SOAP (Simple Object Access Protocol): qui définit la structure du
message XML utilisé par les services Web pour dialoguer entre-eux et
automatiser ce dialogue.
 WSDL qui est un format de description des composants (c'est-à-dire
des services eux-mêmes) invocables par le biais de messages XML au
format SOAP. Il permet de reconnaître les schémas XML utilisés et
d'établir une connexion entre consommateur et fournisseur.
 UDDI qui s'appuie lui-même sur des services Web pour proposer un
annuaire mondial d'entreprises. Il fournit ainsi un outil pour communiquer
tout type de coordonnées (adresse géographique, numéro de téléphone,
fax, adresse de site, etc.)
Suite de protocoles impliqués dans l’implémentation
des « Web services »(source IBM)
197
 SOAP (1)
198

SOAP est un protocole pour l’échange d’informations dans un environnement

décentralisé et distribué, comme Internet par exemple. Il a été pris en compte
comme note par le W3C. SOAP permet l’invocation de méthodes, de services, de
composants et d’objets sur des serveurs distants. SOAP peut normalement
fonctionner sur de nombreux protocoles mais il opère particulièrement bien avec
le protocole HTTP.
SOAP repose sur l’utilisation combinée de :
 XML pour la structuration des requêtes et des réponses, représentant les
paramètres des méthodes, les valeurs de retours et les éventuelles erreurs liées
aux traitements.
 HTTP comme mécanisme d’invocation de méthodes. Pour ce faire, il repose sur
un jeu réduit de paramètres précisés dans les en-têtes HTTP, facilitant le filtrage
 SOAP (2)
199

Il est donc basé sur l’utilisation de XML pour structurer la nature d’un échange
dont on peut distinguer :
 Une enveloppe, qui propose un « framework » visant à décrire ce qui est
présent dans un message (la requête) et la façon dont il doit être traité.
 Un ensemble de règles de codage permettant de décrire les instances des
types de données liées à l’application.
 Une convention pour représenter les appels aux procédures distantes
réalisant le traitement et les réponses.
De plus, SOAP est un protocole basé sur du texte. Basé sur HTTP et étant
orienté ASCII, il pose moins de problèmes d’intégration avec les
équipements de sécurité.
 Exemple de service fourni par les
protocoles SIP et SOAP (source Ubiquity)
200
 Exemple de service fourni par les
protocoles SIP et SOAP (source Ubiquity)
201

 L’exemple ci-dessus donne une illustration des services possibles en associant le

protocole d’établissement de communication SIP à SOAP :
 Un utilisateur envoie un message à Martin. Cependant ce message en anglais «
Hello World » doit être traduit pour être compris.
 Pour cela, il suffit d’ajouter au message SIP, un en-tête « translate = en_fr », qui
sera alors interprété par le serveur SIP/SOAP. Celui-ci envoie alors une requête
SOAP à un serveur Web qui sera capable d’exécuter la méthode «
xmethodsBabelFish » pour effectuer la traduction du message.
 Ce serveur Web, retournera un message SOAP contenant le message à
émettre au destinataire. Celui-ci recevant le message traduit en français, d’une
manière transparente.
 WSDL
(Web Services Description Language)
202

 WSDL est un format XML de présentation. Un document WSDL définit les

services comme un ensemble de ports (points du réseau).
 Pour cela WSDL utilise plusieurs éléments permettant de définir les
services offerts sur le réseau.
 WSDL permet les descriptions des « ports » de services,
indépendamment du format des messages et des protocoles de
réseaux utilisés.
 UDDI
(Universal Description, Discovery, and Integration)
203

 Lancé par IBM, Ariba et Microsoft, le projet UDDI (Universal Description, Discovery,
and Integration) n'est pas vraiment un standard pour les Web Services.
 En fait, UDDI s'appuie lui-même sur des services Web pour proposer un
annuaire mondial d'entreprises.
 Il fournit ainsi un outil applicatif pour communiquer tout type de coordonnées
(adresse géographique, numéro de téléphone, fax, adresse de site, etc.), mais
également la référence des spécifications permettant de faire dialoguer entre-eux
les Web Services ou les places de marché.
 Les spécifications UDDI sont en cours de finalisation.
 Bien que ce type d’annuaire puisse gérer notamment des numéros d’appel et
adresses diverses, il s’agit d’une fonction d’annuaire de niveau applicatif, et non de
niveau réseau. Ce mécanisme n’est donc pas directement lié à des mécanismes
d’adressage « réseau » comme l’adressage SIP ou ENUM ou les fonctions DNS.
 Comparaison des modèles OSA/Parlay et
« Web Services »
204

 Les deux modèles, OSA/Parlay et « Web Services », ont un même objectif

: permettre un accès personnalisé aux services multimédia adaptés au
terminal utilisé.
 Pour cela, il est nécessaire d’utiliser une couche d’adaptation permettant de
gérer l’interface entre les applications fournissant les services et les
ressources réseaux : c’est l’interface API OSA/Parlay pour le modèle OSA
et une suite de protocole, SOAP, WSDL et UDDI, pour les « Web Services ».
 OSA/Parlay/ « Web Services » :
Deux modèles de services NGN diffèrent dans leur
architecture (1)
205

 Le modèle OSA/Parlay (3GPP, Parlay, JAIN) est orienté vers une architecture basée
sur un softswitch, qui, étant le noeud central de la couche contrôle, est le passage
obligatoire pour accéder aux services, via l’interface OSA/Parlay.

 Le modèle OSA/Parlay semble donc plutôt adapté aux services fortement

dépendants de fonctions de la couche Contrôle du réseau (ex. : demande
d’information sur la localisation, ou sur les caractéristiques du terminal…).

 Le modèle « Web Services » préconisé par le W3C est, comme son nom l’indique,
basé sur des technologies « Web » dont l’architecture est distribuée. L’initiation des
sessions est prise en charge par le protocole SIP (Session Initiation Protocol). La
couche d’adaptation, nécessaire pour l’accès aux services, est prise en charge par
un ensemble de protocole « web », tels que XML, SOAP, WSDL et UDDI.
 OSA/Parlay/ « Web Services » :
Deux modèles de services NGN diffèrent dans leur
architecture (2)
206

 Le modèle « web services » est, lui, plutôt adapté aux services

relativement transparents au réseau (communication « universelle »
entre terminal et serveur, ou entre terminaux, ou entre serveurs, une fois la
connexion réseau établie entre les deux entités).
 Il s’appuie sur des concepts déjà anciens d’informatique distribuée.
Son introduction impacte essentiellement la couche Services et dans
une moindre mesure les terminaux, mais peu le réseau.
 C’est ce qui explique qu’il est déjà mis en œuvre dans le domaine
Internet, et pourra aisément être élargi aux autres domaines.
 OSA/Parlay/ « Web Services » :
Deux modèles de services NGN diffèrent dans leur
architecture (3)
207

 A priori, ces deux modèles ne sont pas concurrents mais complémentaires.

On peut en effet imaginer des applications mixtes basées sur le modèle «
web services » mais faisant appel pour certains services à des requêtes de type
OSA/Parlay.
 Le modèle OSA sera par ailleurs plus long et difficile à mettre en œuvre du
fait de sa forte dépendance du réseau. Il devrait avoir vocation à se
développer avec l’essor des réseaux et services UMTS.
 Exemples de services offerts
208

Les NGN offrent les capacités, en termes d’infrastructure, de protocole et de

gestion, de créer et de déployer de nouveaux services multimédia sur des
réseaux en mode paquet.
La grande diversité des services est due aux multiples possibilités offertes par les
réseaux NGN en termes de :
 support multimédia (données, texte, audio, visuel).
 mode de communication, Unicast (communication point à point),
Multicast (communication point-multipoint), Broadcast (diffusion).
 mobilité (services disponibles partout et tout le temps).
 portabilité sur les différents terminaux.
 Exemples de services offerts
209

 De plus, la notion de personnalisation et d’adaptation de services aux

utilisateurs est très présente dans le concept de fourniture de services par
les réseaux NGN.
 Plusieurs éléments-clés communs ressortent, comme l’importance des
bases de données (notamment pour la gestion de personnalisation des
contenus, des paiements, de la localisation…), et la généralisation du
fonctionnement transactionnel et temps réel.
 La messagerie unifiée
210

 C’est le premier exemple de convergence et d’accès à l‘information à

partir des différents moyens d’accès.

 Le principe est de centraliser tous les types de messages, vocaux

(téléphoniques), écrits (email, SMS), multimédia sur un serveur ; ce dernier
ayant la charge de fournir un accès aux messages adapté au type du terminal
de l’utilisateur.
 Ainsi un email peut être traduit en message vocal par une passerelle « text-to-
speech » ou inversement un message vocal sera traduit en mode texte.
 L’évolution du rôle des services
211
intelligents (IN) dans les NGN

 Plusieurs évolutions des protocoles de services de réseau intelligents

sont prévues par les normes afin de prendre en compte les évolutions
vers les services de données d’une part, et d’autre part afin d’assurer
une meilleure interopérabilité des services IN entre réseaux.
 Illustration avec le cas des services IN
mobiles
212

 Les spécifications du groupe CAMEL (appartenant à la GSM

Association), qui normalisent l’interfonctionnement des services IN entre
réseaux mobiles différents comportent plusieurs phases.
 La phase 2 inclut des évolutions pour prendre en compte la facturation
temps réel en fonction des services, et enrichit les critères de
déclenchement de services ainsi que les services eux-mêmes.
 La phase 3 ajoute des fonctions liées à la localisation et à la gestion de la
mobilité, à la gestion des données utilisateur, au support des services de
transmission de données paquet GPRS et du SMS-MO.
NB : En UMTS, CAMEL fait partie intégrante du concept de Virtual Home
Environment (VHE), au même titre que les technologies Mobile station
Execution Environment (MExE) and SIM Application Toolkit (SAT).
 Limites de l’IN dans le NGN (1)
213

 Dans un environnement multi-réseaux qui caractérise les NGN, l’IN, qui se

voulait un outil permettant une création de services simple et une
interopérabilité forte de ces services entre réseaux, n’a pas fait ses
preuves sur ces deux points. En effet :
 l’environnement de création de services reste spécifique à chaque
constructeur, et complexe à appréhender pour un « non-initié », ce qui a
limité la portée des développements aux opérateurs, en relation étroite avec
leur fournisseur.
 Il existe à ce jour très peu de cas de mise en oeuvre d’interfonctionnement de
services IN entre réseaux, du fait de sa complexité de mise en oeuvre et des
protocoles spécifiques sur lesquels l’IN s’appuie (ex. : cas des réseaux
mobiles s’appuyant sur le protocole CAP issu des spécifications CAMEL,
mais aussi cas des réseaux fixes s’appuyant sur le protocole INAP).
 Limites de l’IN dans le NGN (2)
214

 Plusieurs constructeurs ont même identifié l’IN comme « non

 pertinent dans le cadre des NGN », arguant que leur utilisation dans le
cadre des NGN se limitera progressivement à leur consultation comme « bases
de données ».
 Dans le modèle NGN OSA, les plates-formes IN ne sont d’ailleurs pas
identifiées comme des plates-formes de services à part entière, mais
comme des « service capability servers » (serveurs « réseau » sur lesquels
les plates-formes de services s’appuient pour l’exécution des services).
 Outils nécessaires à la fourniture de ces
services
215

 Les différents services évoqués ci-dessus offrent la capacité de

communiquer et d’accéder à des contenus multimédia. Cependant, pour
offrir ces services, il est nécessaire de présenter :
 Au client, des garanties (confidentialité, sécurité),
 Aux fournisseurs de services, des outils permettant la gestion des services
(facturation, authentification, gestion des paiements).
 Pour les clients, la confidentialité et la sécurité, sont gérés par des
mécanismes de cryptage au niveau du réseau de transport IP (IPsec), ou
par des protocoles applicatifs (SSL, TLS).
 Pour les fournisseurs des services, les outils des gestion des services sont
fournis par les modèles « OSA/Parlay » et « Web services ».
 Langages et protocoles convergents de
développement de services et contenus
216

 Les deux modèles de fournitures de services « OSA/Parlay » et « Web

services », s’appuient sur des outils leur permettant d’offrir ces interfaces
pour standardiser et adapter la fourniture des services.
 Ce sont des langages tels que JAVA (OSA/Parlay, Web services), XML
(Web services) et des protocoles tels que CORBA (OSA/Parlay) sur
lesquels reposent les différents éléments des interfaces.
 Ces trois types de langages sont déjà largement utilisés dans le domaine de
l’informatique industrielle et d’Internet, et leur extension au domaine
télécoms (mobile en particulier) est en cours.
 JAVA
217

 Il s’agit d’un langage créé en 1991 par Sun Microsystem dans le but initial de
développer des logiciels embarqués pour contrôler des appareils électroniques et
leur permettre de communiquer entre eux. Ce langage devait permettre de créer
des applications sûres et exécutables sous diverses plates-formes (Windows,
Macintosh, …) sans modification des applications. Depuis 1995, JAVA a connu un
très grand succès et est intégré dans la plupart des navigateurs et sur la
plupart des plates-formes.
 JAVA est orienté objet, JAVA peut s’exécuter sous n'importe quelle plate-forme,
pour autant que celle-ci intègre un interpréteur JAVA (programme ou logiciel
comprenant le langage ; le navigateur Web peut en être un).
 JAVA est utilisé pour la création des API JAIN de l’architecture OSA mais aussi
pour les « Web Services ». Il s’agit donc d’un point de convergence entre ces
deux modèles de services.
 JAVA
218

 JAVA est un langage à la fois compilé et interprété. La compilation du JAVA

produit un fichier en langage intermédiaire entre le binaire et le code saisi. Ce
fichier sera en suite interprété par une "machine virtuelle", fonctionnant, elle,
dans un environnement particulier. On appelle donc communément de telles
machines virtuelles "interpréteur JAVA« . Le langage JAVA permet de produire
2 types de programmes :
 Les Applications qui s'exécutent directement dans l’environnement
graphique de l’ordinateur où il est lancé.
 Les Applets qui sont des applications fonctionnant sur les
navigateurs. Ils sont introduits dans une page HTML et exécutés à
distance sur le terminal, via un navigateur Web.
 XML (eXtensible Markup Language)
219

 XML est un ensemble de règles pour la conception de formats texte

permettant de structurer des données. Il a été développé par le XML
Working Group sous la tutelle du World Wide Web Consortium (W3C)
dès 1996. Depuis 1998, les spécifications XML1.0 sont reconnues comme
recommandation par le W3C.
 Alors que HTML est un langage à part entière, XML peut être considéré
comme un méta-langage permettant de définir d'autres langages.
Comme HTML, XML utilise les balises seulement pour délimiter les
éléments de données et laisse l'entière interprétation des données à
l'application qui les lit. En d'autres termes, un "<p>" dans un fichier XML,
peut être un prix, un paramètre, une personne…
 Intérêt de XML
220

L’intérêt de XML réside dans sa capacité à pouvoir décrire n'importe quel domaine de données
grâce à son extensibilité. Il va permettre de structurer, poser le vocabulaire et la syntaxe des
données qu'il va contenir.
XML se caractérise par les points suivants :
 Lisibilité : pas besoin de connaître le métier pour appréhender le contenu d'un document
XML
 Extensibilité
 Une structure arborescente : cette structure de base permet de modéliser des contenus
hiérarchisés (par exemple afin d’afficher plus ou moins de contenus en fonction des capacités
du terminal utilisé)
 Universel et portable : les différents jeux de caractères sont pris en compte
 Déployable : il peut être facilement distribué par n'importe quel protocole à même de
transporter du texte, comme HTTP
 Intérêt de XML
221

 Un des domaines les plus prometteurs de XML est l'échange de données ou

documents entre sites distants ou applications différentes, en utilisant XML
comme un format pivot garant des données échangées malgré la possible
hétérogénéité des bases de données ou logiciels mis en jeux.
 De fait XML est le format standard utilisé par les protocoles
implémentés dans les « Web Services ».
 CORBA
(Common Object Request Broker Architecture)
222

 La norme CORBA est née dans les années 1990 du besoin de faire
communiquer ensemble des applications en environnement hétérogène
(plusieurs systèmes et plusieurs langages).
 C'est la solution apportée par l'OMG (Object Management Group) au besoin
d'interopérabilité face à la prolifération des machines et des logiciels
disponibles sur le marché.
 CORBA 1.1 définit l'IDL (Interface Definition Language) et les API
(Application Programming Interface) qui permettent l'interaction des objets
client-serveur, à l'aide de l'ORB (Object Request Broker).
 CORBA 2.0 finalisée en 1995, définit un plus dans l'interopérabilité en spécifiant
comment des ORB différentes peuvent collaborer.
 CORBA
(Common Object Request Broker Architecture)
223

CORBA représente les spécifications de l'ORB (Object Request Broker), qui est l'entité
principale par laquelle toutes les commandes vont transiter, ou vont être adressées.
L'ORB est un middleware, qui établit la relation client-serveur entre des objets. En utilisant
un ORB, un client peut de façon transparente invoquer une méthode sur un objet serveur,
qui peut être sur la même machine ou, au travers d'un réseau, sur une machine distante.
L'ORB est responsable de trouver l'objet qui implémente cette requête, de lui passer les
paramètres, puis d'invoquer la méthode, et enfin de retourner le résultat.
En faisant cela, l'ORB fournit l'interopérabilité entre des applications situées sur
différentes machines dans un environnement distribué hétérogène, et interconnecte
des systèmes d'objets multiples.
L'ORB fournit la flexibilité, il permet au programmeur de choisir l’OS, l'environnement
d'exécution, et même le langage de programmation à utiliser pour chaque composant d'un
système en construction. CORBA est la brique de base sur lequel est implémentée
l’interface OSA/Parlay.
 Conclusion
224

Le modèle OSA/Parlay, basé sur l’interface de services normalisée du

modèle OSA/Parlay préconisé par le 3GPP, a fédéré un grand nombre de
constructeurs télécoms et d’opérateurs historiques. En effet,
l’architecture, centrée sur le Softswitch permet l’évolution des réseaux
télécoms actuels.
• Le modèle préconisé par le W3C, les « Web services », est, pour sa part,
avancé et déjà mis en oeuvre par les acteurs venant du monde Internet
et informatique. Cette approche est basée sur les technologies et des
protocoles (XML, SOAP) issus du monde Internet avec une architecture
distribuée. Il est à noter que le protocole de contrôle d’appel utilisé dans
cette architecture est le protocole SIP.
 Conclusion
225

 l’approche OSA/Parlay est incontournable pour les acteurs télécoms établis évoluant
vers les NGN.
 l’approche des « Web services » est moins complexe à implémenter et donc plus
accessible à des fournisseurs de services tiers que l’interface OSA/Parlay.
 les deux approches sont complémentaires, un services pouvant tout à fait être mixte
(service « Web services » ayant recours à des requêtes OSA au cours de son exécution).
 elles ont au moins un point de convergence : l’utilisation de JAVA.
 La messagerie instantanée
226

 Permet de dialoguer en temps réel, à plusieurs, sur un terminal IP

(généralement un PC) ayant accès à Internet via une interface texte.
 Cependant, il est nécessaire d’installer sur son terminal un logiciel propriétaire
permettant de se connecter à un fournisseur d’accès ; il n’est alors possible de
communiquer qu’avec les utilisateurs souscrivant au même service.
 L’évolution des réseaux devrait permettre la standardisation de cette application
et la communication entre tous (ouverture du service) à partir de n’importe quel
terminal.
 C’est l’évolution du service SMS, par l’apport de l’interactivité et du multimédia
(MMS).
 La diffusion de contenus multimédia
227

Regroupe deux activités :

 l’une focalisée sur la mise en forme des contenus multimédia,

 l’autre centrée sur l’agrégation de ces divers contenus via des portails.

Les outils technologiques, tels que le multimédia streaming (gestion d’un flux
multimédia en termes de bande passante, de synchronisation des données) et le
protocole multicast (diffusion point-multipoint), permettent de fournir un
service de diffusion de contenu aux utilisateurs finaux. Cependant il ne sera pas
possible de penser à la diffusion de vidéo haute définition sur réseau paquet tant
que les réseaux d’accès ne pourront pas fournir des débits de plusieurs dizaines
de Mbit/s par utilisateur.
 Les services fournis par des tiers ou ASP
(Application Service Providers)
228

 Les NGN, par l’évolution et l’ouverture des réseaux, doivent favoriser

l’évolution de l’utilisation des services considérés comme « classiques ».
 Ainsi l’utilisation des logiciels, la messagerie peuvent être gérés par un
fournisseur de service à travers le réseau.
 Ce mode de fourniture de services permet une flexibilité beaucoup plus
importante et une réduction de coûts grâce à l’externalisation.
 L’évolution du rôle des services
intelligents (IN) dans les NGN
229

 Plusieurs évolutions des protocoles de services de réseau intelligents

sont prévues par les normes afin de prendre en compte les évolutions
vers les services de données d’une part, et d’autre part afin d’assurer
une meilleure interopérabilité des services IN entre réseaux.
 Illustration avec le cas des services IN
mobiles
230

 Les spécifications du groupe CAMEL (appartenant à la GSM

Association), qui normalisent l’interfonctionnement des services IN entre
réseaux mobiles différents comportent plusieurs phases.
 La phase 2 inclut des évolutions pour prendre en compte la facturation
temps réel en fonction des services, et enrichit les critères de
déclenchement de services ainsi que les services eux-mêmes.
 La phase 3 ajoute des fonctions liées à la localisation et à la gestion de la
mobilité, à la gestion des données utilisateur, au support des services de
transmission de données paquet GPRS et du SMS-MO.
 NB : En UMTS, CAMEL fait partie intégrante du concept de Virtual Home
Environment (VHE), au même titre que les technologies Mobile station
Execution Environment (MExE) and SIM Application Toolkit (SAT).
231
 Principe d’architecture d’un cœur de
réseau NGN
232
 Principe d’architecture d’un cœur de
réseau NGN
233

 L’importance relative entre l’évolution « tout IP » et la séparation du

réseau en couches diffère selon les acteurs.
 Mais une majorité s’accordent à dire que le concept majeur des
NGN est bien l’évolution « tout IP », la séparation en couches
n’étant qu’une étape, ou une nécessité pour optimiser les réseaux.
 Principe d’architecture d’un cœur de
réseau NGN
234

 Afin de garantir l’interfonctionnement et la qualité de service (et en particulier la

non régression des services téléphoniques par rapport a leur gestion en mode
circuit), la mise en œuvre des réseaux NGN devra également s’accompagner :
 d’une réflexion globale sur l’évolution des concept de numérotation
d’adressage et de nommage et l’harmonisation des processus d’attribution
et de gestion de ces ressources, le tout dans une optique de convergence
téléphonie / données (vers IP) et de convergence fixe vers mobile.
 De la mise en œuvre de mécanismes de qualité de service standardisés de
bout en- bout, D’efforts minimisant les risques de blocage de l’ouverture des
réseaux à des fournisseurs de services tiers du fait des impacts techniques et
organisationnels liés à la nécessaire interconnexion des équipements mais
aussi des systèmes d’information des partenaires.
 La couche d’accès, un moteur pour
l’introduction des NGN
235

 La multiplication et les évolutions des réseaux d’accès sont identifiées

comme un élément déclencheur majeur - et un moteur essentiel -
de l’évolution des réseaux vers les NGN.
 Si l’on analyse les évolutions majeures apportées par ces différentes
technologies d’accès, la tendance actuelle est à :
 la multiplication des technologies d’accès,
 l’évolution vers le haut débit,
 des technologies de transport multi-services en mode paquet (IP, ou plus
fréquemment ATM),
 la convergence fixe/mobile, avec la prise en compte du nomadisme du fait
de l’essor des réseaux d’accès mobiles et des réseaux locaux sans fil.
 La Couche d’accès, un moteur pour
l’introduction des NGN
236

 Bien que ne pouvant pas être qualifiées de NGN, les nouvelles technologies
d’accès haut débit sont une composante connexe très importante car elles
influeront sur la rapidité d’introduction et les modalités techniques détaillées
de mise en œuvre des cœurs de réseau NGN, notamment concernant le
choix du protocole de transport de cœur de réseau.
 Réseau de transport
237

L’objectif de ces différentes évolutions du réseau de transport est de répondre à

quatre impératifs pour le transport convergent des flux IP multimédia dans un
réseau NGN :
 l’adéquation aux nouveaux besoins de services,
 le support des très haut débit,
 la garantie de qualité de service, surtout concernant les flux temps réel (voix, vidéo…),
 la gestion optimisée du réseau de transport.
Pour répondre à ces problématiques, une évolution s’amorce vers des réseaux
convergents utilisant des technologies de transmission et de transport haut
débit, en mode paquet, avec une qualité de service adaptée aux différents
services.
 Réseau de transport
238

 De plus, l’architecture NGN définit la séparation des fonctions Transport et

Contrôle du coeur de réseau.
 En effet, la notion de réseau de transport, au sens NGN, inclut, en complément
des liaisons physiques et de l’infrastructure « passive » de transport, l’apparition
des fonctions MG et SG, qui effectuent la conversion et l’acheminement du trafic
et de la signalisation sous le contrôle des serveurs d’appel.
 Réseau de transport
239

Plusieurs tendances peuvent être observées autour des réseaux de transport :

 L’extension de l’usage de la commutation optique et du multiplexage en
longueur d’onde (DWDM, CWDM) dans les réseaux de transmission
étendus, y compris métropolitains, au détriment du multiplexage TDM.
 L’apparition de commutateurs Ethernet dans les réseaux métropolitains,
voire nationaux ou internationaux. Ces commutateurs permettent une
connectivité de « bout en bout» en Ethernet.
 Au niveau du réseau de commutation pour le transport du trafic IP, on peut
anticiper la diffusion progressive des commutateurs MPLS, avec les
tendances suivantes qui se dégagent :
 une tendance forte vers une commutation MPLS seule.
 à plus long terme l’apparition du GMPLS (MPLS sur WDM) offrira une
 Réseau de transport
240

La Commutation NGN : séparation des couches Transport et Contrôle

La mise en œuvre de l’architecture NGN au niveau de la couche contrôle se
traduit techniquement par :

1. Le remplacement des commutateurs traditionnels par deux types

d’équipements distincts :
2. L’apparition de nouveaux protocoles
1. Le remplacement des commutateurs traditionnels
par deux types d’équipements distincts :
241

 d’une part des serveurs de contrôle d’appel dits Softswitch ou Media Gateway
Controller assurant le contrôle des communications et des ressources des
autres équipements de la couche contrôle,
 et d’autre part des équipements de médiation et de routage dits Media Gateways
qui assurent non seulement l’acheminement du trafic, mais aussi
l’interfonctionnement avec les réseaux externes et avec les divers réseaux
d’accès en réalisant la conversion du trafic (entité fonctionnelle Media Gateway)
et la conversion de la signalisation associée (entité fonctionnelle Signalling
Gateway).
2. L’apparition de nouveaux protocoles de contrôle d’appel et
de signalisation entre ces équipements (de serveur à serveur,
et de serveur à Media Gateway)
242

 Signalisation de contrôle d’appel : SIP vs H.323

 Signalisation de commande des Media Gateways : Megaco/H.248 vs MGCP
 Megaco/H.248 semble être la cible identifiée par la plupart des acteurs, mais du
fait de la plus grande maturité des offres (du moins pour certains constructeurs),
MGCP pourrait être largement utilisé à court terme.
 Signalisation de transit : BICC vs SIP-T
 BICC était prévu initialement pour le transport de la signalisation entre serveurs
de contrôle sur ATM, et SIP-T sur IP. Les deux protocoles évoluent en fait pour
supporter les deux modes de transport. Il est possible que le consensus qui se
dessine autour de SIP pour le contrôle d’appel bénéficie à terme à SIP-T.
 Protocole d’adaptation : SIGTRAN (SIGnalling TRANsport)
 SIGTRAN utilise une nouvelle couche de transport appelée Stream Control
Transmission Protocol (SCTP), à la place de TCP, pour transmettre la
signalisation SS7 d’une façon transparente sur les réseaux IP.
 La Couche Services des NGN
243

 L’évolution des réseaux, aussi bien au niveau de la couche Transport que de la couche
Contrôle, permet le développement de nouveaux services.
 Les réseaux d’accès haut débit, la gestion de la mobilité, la géolocalisation et la
personnalisation sont autant d’outils disponibles pour la création de services multimédia
encore plus interactifs et adaptables au type de terminal utilisé et aux besoins des
utilisateurs.
 Pour fournir ces services modulables, il est nécessaire, face à la multiplication des réseaux
d’accès et des terminaux communicants, de définir une nouvelle architecture d’accès
aux services.
 Deux modèles issus d’approches différentes, mais complémentaires, émergent : une
architecture « OSA/Parlay » et un modèle « Web Services ». Tous deux sont basés sur
des protocoles et des interfaces ouvertes et standardisés facilitant l’émergence des
fournisseurs tiers de services, mais aussi l’interopérabilité entre les solutions.
 La Couche Services des NGN
244

 Le modèle OSA/Parlay, basé sur l’interface de services normalisée du

modèle OSA/Parlay préconisé par le 3GPP, a fédéré un grand nombre de
constructeurs télécoms et d’opérateurs historiques.
 En effet, l’architecture, centrée sur le Softswitch, permet l’évolution des
réseaux télécoms actuels. Ce modèle est plus adapté aux services nécessitant
une forte coopération des serveurs d’appel et bases de données du coeur de
réseau (ex. : services téléphoniques, géolocalisation…)
 La Couche Services des NGN
245

 Le modèle préconisé par le W3C, les « Web services », est, pour sa part,
avancé et déjà mis en oeuvre par les acteurs venant du monde Internet et
informatique.
 Cette approche est basée sur les technologies et des protocoles (XML, SOAP)
issus du monde Internet avec une architecture distribuée.
 Le protocole de contrôle d’appel utilisé dans cette architecture est le protocole
SIP. Ce modèle est plus adapté auxservices réalisés de manière transparente
après établissement d’une connexion IP.
 La Couche Services des NGN
246

 La relative jeunesse de ces modèles ne permet pas de se prononcer

formellement sur le succès de l’un ou/et l’autre des modèles. Il ressort
cependant que :
 l’approche OSA/Parlay est incontournable pour les acteurs
télécoms établis évoluant vers les NGN. Mais le succès du modèle
OSA se confirmera (ou s’infirmera) vraiment avec l’essor desréseaux et
services UMTS.
 l’approche des « Web services » est moins complexe à implémenter
et donc plus accessible à des fournisseurs de services tiers que
l’interface OSA/Parlay. La preuve en est l’existence à ce jour des
premiers services issus de ce modèle.
 La Couche Services des NGN
247

 les deux approches sont complémentaires, un services pouvant tout à

fait être mixte (service « Web services » ayant recours à des requêtes OSA
au cours de son exécution).
 l’objectif d’une telle architecture est aussi l’ouverture des plates-
formes et des interfaces à des nouveaux acteurs.
 C’est, au vu de nombreux exemples, l’unique solution pour avoir un
marché dynamique, ouvert et viable. La question essentielle est donc de
savoir si les acteurs établis désirent réellement ouvrir leurs
infrastructures à des acteurs tiers, qui seraient dans le même temps
des concurrents potentiels.
 Les terminaux au cœur de la migration
vers les NGN
248

 L’évolution des terminaux fixes ou mobiles n’est pas neutre dans le contexte des NGN.
 En effet, les réseaux et services de nouvelle génération ne pourront prendre forme qu’à
travers la disponibilité et l’adoption effective de nouvelles familles de terminaux capables
de les supporter et de les rendre attractifs.
 Les terminaux doivent donc nécessairement :
 En premier lieu, s’adapter au support des nouveaux services spécifiés par les opérateurs et
fournisseurs de services (point non spécifique aux NGN).
 Dans un second plan, intégrer les évolutions des protocoles de contrôle d’appel des coeurs
de réseaux NGN. Ainsi, d’une manière générale, les terminaux seront amenés à évoluer vers :
 Le support de services multimédia.
 Le déport d’une partie de l’intelligence de service qui permet une architecture de services
distribuée et plus efficace.
 La gestion de fonctions nouvelles telles que le nomadisme ou la géolocalisation pour les
terminaux mobiles.
 L’utilisation des nouveaux protocoles de contrôle d’appel utilisés pour dialoguer avec les
plates-formes de services et avec les autres terminaux. A terme une part importante des
terminaux seront vraisemblablement nativement IP multimédia.
 Migration vers les NGN : diversité des
approches et facteurs de choix
249

Il existe à tous les niveaux d’un réseau NGN des diversités d’implémentation
possibles. Les principaux facteurs qui influenceront ces choix sont :
 L’avancement et la convergence des travaux de normalisation autour des architectures et
protocoles NGN.
 La maturité et le coût des produits NGN par rapport à leurs équivalents d’ancienne
génération et par rapport aux dites normes. Les offres de produits NGN sont récentes, et
ces deux aspects sont donc amenés à évoluer rapidement.
 L’infrastructure existante des opérateurs et fournisseurs de services, qui influera sur les
choix de ces derniers tant du point de vue technique qu’économique, ainsi que leurs
prévisions d’évolution d’activités vis-à-vis de leurs clients et de leurs partenaires.
 Les avantages attendus de la migration vers les NGN, les risques potentiels associés et le
contexte économique et réglementaire dans lequel se situent les prises de décisions de
ces acteurs.
 Positionnement d’une partie des
organisations de normalisation
250
251

Evolution des Réseaux Cellulaires

 Architecture de base GSM
252
 Architecture de base GSM
253

BTS PSTN
Abis TRAU
...
.. .
< ^>
A
.. BTS BSC MSC/VLR HLR

EIR
SS7 Network
 BTS, BSC, MSC
254

BTS BSC MSC

 Gestion Radio transmission/ reception
(modulation/demodulation, equalisation,
 Gestion de ressource Radio : Gestion des communications
interleaving ...)
allocation de canaux, traitement des entre les mobiles et le réseau.
 Gestion de la couche Physique (TDMA mesures BTS,contrôle de puissance  Gestion de Handover.
transmission, SFH (slow frequency hoping), des BTS et MS , handover ...  Interconnexion avec le réseau
codage, chiffrement ...) fixe (à commutation).
 Gestion des Interfaces : avec le  Gestion des visiteurs avec le
 Gestion de la couche Liaison (LAPDm) MSC (rassembler les trafics vers VLR.
 Qualité du signal reçu et mesures de MSC) et avec les BTSs. Fonction GMSC (Gateway MSC):
puissance. Passerelle pour les appels
entrant/Sortant du vers le réseau
externe.
 HLR, VLR
255

 HLR (Home Location Register) Base de données des Abonnés:

 Données d’abonnement: IMSI (International Mobile Subscriber Identity) ,
MSISDN, type d’abonnement (restrictions, services supplementaires, ...)
 Information de Localisation : numéro VLR mobile.

 VLR (Visitor Location Register)

 Données : IMSI, MSISDN (Mobile Subscriber Integrated Services Digital
Network), TMSI (Temporary Mobile Subscriber Identity), MSRN (Mobile Station
Roaming Number), type de d’abonnement, aire de localisation, ...
 Plateforme de réseaux Intelligents (CAMEL)
dans les réseaux GSM
256

IN Plate-form

BTS PSTN
Abis TRAU
...
.. .
< ^>
A
.. BTS BSC MSC/VLR HLR

EIR
SS7 Network
 Introduction de GPRS dans un réseau
GSM
257

IN Plate-form

BTS PSTN
Abis TRAU
...
.. .
< ^>
A
.. BTS BSC MSC/VLR HLR

PCU
Gr
Gb Gs

G r, G d, G f
SGSN Gn SS7 Network EIR
Gf

GPRS
Border backbone Service WAP,
Gateway Gc plate-form WWW,
...

Router
GGSN Internet LAN
PDN
Inter-operator
GPRS backbone
 EDGE
258

IN Plate-form

BTS PSTN
Abis TRAU
...
.. .
< ^>
A
.. BTS BSC MSC/VLR HLR

PCU
Gr
Gb Gs

G r, G d, G f
SGSN Gn SS7 Network EIR
Gf

GPRS
Border backbone Service WAP,
Gateway Gc plate-form WWW,
...

Router
GGSN Internet LAN
PDN
Inter-operator
GPRS backbone
 Introduction à UMTS
259

Node B Iub

UE RNC
Iu
Iub
Node B
UMTS Core
Network
UMTS Radio Access Network

GPRS/EDGE Radio
Access Network NSS
Internet

GPRS core network

 Principales CaractéristiquesUMTS R99
260

Services
OSA (Open Systems Architecture), USSD (Unstructured
Supplementary Service Data), MMS, LCS (cell level),
streaming, GSM services (SMS-PtP/CB), SMS, VHE

UMTS Core
UTRAN Network
New radio access system
(WCDMA-based): higher Camel, GPRS-based core network with
bitrates, HO with GSM improvements (security, GTP, …)

UE
EMS, MMS, MExE (Mobile Execution
Environment, terminals classified by classmark),
SAT (SIM Application Toolkit, interoperability
between all USIM and UE), VHE
 Caractéristiques UMTS R4
261

Services
Authentication algorithm, VHE and OSA evolutions, LCS
support in circuit and packet domains (OTDOA and A-GPS)

UTRAN UMTS Core

Network
New TDD access mode, evolution of UTRAN
transport (IP introduction), radio interface Packet transport improvement in the
improvement (e.g. UTRA repeaters ), RAN core network, TrFO (Transcoder
improvements (e.g. overhead compression) Free Operation), Tandem Free
between 2G and 3G

UE
MExE release 4, MMS r4, SMS/EMS
improvements, Terminal Local Model-USAT Local
(allows USIM applications to access other devices
with Bluetooth),
 UMTS R99/R4 et GSM/GPRS
262

CS PSTN/
VLR

GSM VMSC GMSC ISDN

Radio
IP/ATM
Core CAMEL HLR

Network(s)

GPRS
VLR
Public
UMTS
Radio GGSN IP
SGSN
PS
 Caractéristiques UMTS R5
263
Services
IMS (VoIP, chatt, jeux, white shared board, flexible billing, …),
OSA improvements (VAS offered by third parties, VHE easier),
Extended streaming (optimisation, 2 and 3D graphics, MIDI
audio, …)
UTRAN UMTS Core
Network
HSDPA (bitrates between 1 and 5 Mb/s),
Smart antennas, IP transport in UTRAN (IP- SIP (call control), End-to-end QoS
RAN) with DiffServ introduction, improvements, IuFlex (traffic load
sharing between core nodes
UE
Wideband AMR (wider bandwidth for voice), GTT
(Global Text Telephony, real time text
communication), LCS improvements with A-GPS,
MMS/EMS improvements
 Introduction à IMS
264

IP Multimedia
System
UMTS Radio Access Network

UMTS Core
Network

GPRS/EDGE Radio
Access Network NSS
Internet

GPRS core network

 UMTS R6 Features
265

Services
MBMS (multimedia broadcast service), IMS phase 2
(independant access from the radio access UMTS, GERAN,
WLAN), Presence and Instant Messaging, Push-To-Talk

UMTS Core
UTRAN Network
Infrastructure sharing, QoS/IP, ... WLAN (loose coupling) with AAA
function reuse, access with USIM

UE
SES (Speech Enhanced Services): distributed voice
recognition, MIMO (multiple antennas in the
terminals), Terminal management (configuration,
performances, downloading)
 Caractéristiques UMTS et sous-systèmes
de provision de services
266

Developpement de services
Introduction de IMS
IP Multimedia Service multimedia IP avec intégration de
IP composants hardware et software

VHE
Portabilité du cadre utilisateur (User
Personnalisation Virtual Home
Environment framework portability)

Développement de services par des

Provision par une OSA
Open Service Access
applications externes et fournisseurs
tierce personne
de contenus (content providers)

MeXE Adaptation du service au terminal

Lié au Terminal Mobile eXecution utilisateur selon ses caractéristiques,
Environment partage de tâche avec le réseau
 IMS - IP Multimedia Service
▪ Caracteristiques de QoS: Différenciation de voix et vidéo associée avec une session
multimedia (streaming, IM, etc.)
Principes ▪ Séparation des plan IP données et contrôle de session (SIP)
▪ Indépendant du réseau d’accés
IMS pour réseaux mobiles GPRS, EDGE, IMS étendu aux réseaux fixes large bande
UMTS & CDMA2000 services (xDSL, WLAN, cable, …)
R5
Non temps réel IP multimedia plate- R6 Supporte la convergence de services sur les
formes d’applications
réseaux fixes et mobiles (conversion CS trafic VoIP)
basées sur les specifications IETF
▪Introduction de services multimedia avec gestion de QoS
Avantages ▪Integration avec d’autres réseaux (WLANs, fixed, CDMA2000, …)
▪Facturation flexible : facturation / service, connectivité, QoS, temps, destination
 Implémentation de +ieurs équipments, softwares, interfaces, protocoles, qui peuvent favoriser
l’intégration, problèmes d’interfonctionnement et d’optimisation
Ex.:S-CSCF (Call Status Control Function); SIP AS (SIP Application Server); OSA
Inconvénients SCS (Service Capability Server); IM-SSF (Inter-working Module); CSE (Camel Service
Environment); HSS (Home Subscriber Server)
 Securité et QoS avec interconnexion Internet
 Composants et interactions entre IMS et
les autres réseaux
268

IMS
Application
Servers Session Media
RAN (SIP, OSA, CAMEL) Control Control
ISUP
SIP
PCM
PSTN
RNC
Media
Media
User Gateway
Gateway SIP
Data
AMR Packet
network
Packet Support Backbone IP Packet
Node
Gateway
Core packet
 VHE - Virtual Home Environment
• PSE (Personal Service Environment) portabilité entre réseux et terminaux: modes d’interaction
utilisateurs – services, gestion d’abonnements multiples (pro/perso), terminaux et préférences
multiples selon la localisation.
Principes • Mêmes caractéristiques toujours disponibles pour l’utilisateur: interface et services
personnalisés, quelque soit le réseau et le terminal.
• Independance relativement au réseau (roaming) et au terminal
Applications

VAB Customer Care Calender multiparty Multimedia Delivery

Virtual Address Book service application service
Assure à l’utilisateur: Gestion de calendriers
Utilise plusieurs types
tutorial (enseignement) de Coordination entre
de terminaux pour
interactif, détection de utilisateurs distants: Adaptation de la vidéo au
acccéder et mettre à collection de réponses, terminal utilisateur
problèmes et proposition
jour les données détermination de dates
de solutions assistance, de meeting, …
utilisateurs
on-line, …
 OSA - Open Service Access
▪ Introduction de SCF (Service Capability Features) pour fournir des applications
avec caractéristiques de service: contrôle d’appel, localisation d’utilisateur,…
Principes ▪ Accés aux caractéristiques réseau utilisées par les développeurs d’application
pour développer ou améliorer des services

VPN, téléconférence, LBS Applications implementées

Applications
dans un ou plusieurs serveurs d’application
▪ Introduction de services par une tierce partie via des interfaces et des
Avantages applications standardisées
▪ Convivaliser l’ introduction d’applications et de services de providers
▪ Supervision des services et des contenus par l’operateur
Inconvénients ▪ Gestion de QoS par des fournisseurs externes pour les services
offerts
 MExE - Mobile Execution Environment
▪Environment d’execution Standardisé pour les mobiles
▪ Négociation des caractéristiques entre UE et serveur MExE durant l’initiation
du service ou dynamiquement
Principes ▪ Execution d’applications de service dans l’UE ou dans le serveur MExE
▪ MExE definit les différents besoins technologiques (classmarks) pour
supporter différents terminaux (Classmark 1: environment WAP, Classmark 2:
PersonalJava, Classmark 3 : environment J2ME CLDC MIDP)

Avantages ▪ Adaptation des services aux terminaux utilisateurs

▪ Définition, standardisation et implementation de ces classes
Inconvénients
de terminaux
 Evolution des services dans les réseaux
UMTS R99/R4/R5/R6
Release Services
R99 MMS, streaming, LCS (cell), MExE, SAT, VHE,
R4 TrFO, VHE, OSA, LCS in PS and CS,
R5 VoD, IMS, HSDPA, Wideband AMR, GTT
R6 MBMS, IMS phase 2
Evolution des services (voix et services interpersonels) Voix/Videotelephonie
Voix/Videotelephonie IM/Presence
Messagerie
Voix Messagerie Instantannée /Presence Messaging
Voix
SMS/MMS Rich Call Services RCS
Videotelephonie
Messaging LCS
GTT
 Problèmes de QoS dans UMTS

Guarantie de QoS dans CS mais pas dans IP: problèmes de QoS

similaires dans UMTS comme dans n’importe quel réseau IP
Fourniture de QoS dans IP ?

 définition impérative de fonction de gestion de QoS de bout en bout

 Pas de spécifications 3GPP pour la QoS dans PS et dans IMS
 Le choix d’Implementation dépend des préférences de l’operateur, du
réseau, du modèle de service, des fournisseurs d’équipments, …
 Ressources négociées entre operateurs via DiffServ, DSCP aux
extrèmités réseau
 Provisionnement de la QoS dans UMTS

Réseau ▪ RSVP, overprovisionning, DiffServ/ IntServ, MPLS

▪ Dans R5, définition de 5 scénarios de signalisation pour une QoS de bout en bout:
coeur - 3 avec interfonctionnement PDP/DiffServ,
- 2 avec signalisation RSVP
Accès
CAC - Call Admission Control Contrôle charge/Congestion
Radio
• RNC: supervise, détecte et gère les situations de
• RNC: admettre ou rejeter de nouveaux utilisateurs congestion durant les connexions
RAB (Radio Access Bearers) selon la charge du
réseau, priorités utilisateurs et disponibilité des des • Réduction de charge via des mécanismes
ressources d’attente, en retardant les paquets de trafic best
effort
• Utilisé à l’accès de UE réseau : reconfiguration RAB
ou allocation et HO selon les évenements • Mécanismes non standardisés, designés par les
vendeurs d’équipments et optimisés par les
• UL interference du canal et DL puissance opérateurs
correspondante
• Principes: CAC basé sur le niveau d’interference ,
sur la politique d’admission/facteur de charge, etc.
 Conclusion
275

▪ UMTS introduit:
 Un environnement pour développer et fournir des services: large
bande, flexibles, personnalisés, accessibles de l’extérieur, ouvert sur
Internet, … avec des technologies Internet and PC correspondantes.
Services Riches et large bande
Mais:
Plus de complexité (conception, planification, intégration, déploiement,
sécurité, optimisation, exploitation).