Sie sind auf Seite 1von 36

Union internationale des tlcommunications

UIT-T

Y.2261

SECTEUR DE LA NORMALISATION
DES TLCOMMUNICATIONS
DE L'UIT

(09/2006)

SRIE Y: INFRASTRUCTURE MONDIALE DE


L'INFORMATION, PROTOCOLE INTERNET ET
RSEAUX DE PROCHAINE GNRATION
Rseaux de prochaine gnration Aspects relatifs aux
services: interoprabilit des services et rseaux dans les
rseaux de prochaine gnration

Evolution des RTPC/RNIS vers les rseaux de


prochaine gnration

Recommandation UIT-T Y.2261

RECOMMANDATIONS UIT-T DE LA SRIE Y


INFRASTRUCTURE MONDIALE DE L'INFORMATION, PROTOCOLE INTERNET ET RSEAUX DE
PROCHAINE GNRATION
INFRASTRUCTURE MONDIALE DE L'INFORMATION
Gnralits
Services, applications et intergiciels
Aspects rseau
Interfaces et protocoles
Numrotage, adressage et dnomination
Gestion, exploitation et maintenance
Scurit
Performances
ASPECTS RELATIFS AU PROTOCOLE INTERNET
Gnralits
Services et applications
Architecture, accs, capacits de rseau et gestion des ressources
Transport
Interfonctionnement
Qualit de service et performances de rseau
Signalisation
Gestion, exploitation et maintenance
Taxation
RSEAUX DE PROCHAINE GNRATION
Cadre gnral et modles architecturaux fonctionnels
Qualit de service et performances
Aspects relatifs aux services: capacits et architecture des services
Aspects relatifs aux services: interoprabilit des services et rseaux dans les rseaux de
prochaine gnration
Numrotage, nommage et adressage
Gestion de rseau
Architectures et protocoles de commande de rseau
Scurit
Mobilit gnralise
Pour plus de dtails, voir la Liste des Recommandations de l'UIT-T.

Y.100Y.199
Y.200Y.299
Y.300Y.399
Y.400Y.499
Y.500Y.599
Y.600Y.699
Y.700Y.799
Y.800Y.899
Y.1000Y.1099
Y.1100Y.1199
Y.1200Y.1299
Y.1300Y.1399
Y.1400Y.1499
Y.1500Y.1599
Y.1600Y.1699
Y.1700Y.1799
Y.1800Y.1899
Y.2000Y.2099
Y.2100Y.2199
Y.2200Y.2249
Y.2250Y.2299
Y.2300Y.2399
Y.2400Y.2499
Y.2500Y.2599
Y.2700Y.2799
Y.2800Y.2899

Recommandation UIT-T Y.2261


Evolution des RTPC/RNIS vers les rseaux de prochaine gnration

Rsum
La prsente Recommandation dcrit les principaux aspects de l'volution des RTPC/RNIS vers les
rseaux de prochaine gnration (NGN, next generation network). Elle dcrit l'volution fonde sur
un sous-systme multimdia IP (IMS, IP multimedia sub-system) et celle fonde sur un serveur
d'appel (CS, call server). Elle porte essentiellement sur l'volution des parties de transport des
RTPC/RNIS vers les NGN. Des scnarios d'volution sont prsents dans des appendices.

Source
La Recommandation UIT-T Y.2261 a t approuve le 13 septembre 2006 par la Commission
d'tudes 13 (2005-2008) de l'UIT-T selon la procdure dfinie dans la Recommandation UIT-T A.8.

Mots cls
Evolution, NGN, passerelle d'accs, rseau d'accs, RNIS, RTPC, serveur d'appel, serveur
d'application.

Rec. UIT-T Y.2261 (09/2006)

AVANT-PROPOS
L'UIT (Union internationale des tlcommunications) est une institution spcialise des Nations Unies dans
le domaine des tlcommunications. L'UIT-T (Secteur de la normalisation des tlcommunications) est un
organe permanent de l'UIT. Il est charg de l'tude des questions techniques, d'exploitation et de tarification,
et met ce sujet des Recommandations en vue de la normalisation des tlcommunications l'chelle
mondiale.
L'Assemble mondiale de normalisation des tlcommunications (AMNT), qui se runit tous les quatre ans,
dtermine les thmes d'tude traiter par les Commissions d'tudes de l'UIT-T, lesquelles laborent en retour
des Recommandations sur ces thmes.
L'approbation des Recommandations par les Membres de l'UIT-T s'effectue selon la procdure dfinie dans
la Rsolution 1 de l'AMNT.
Dans certains secteurs des technologies de l'information qui correspondent la sphre de comptence de
l'UIT-T, les normes ncessaires se prparent en collaboration avec l'ISO et la CEI.

NOTE
Dans la prsente Recommandation, l'expression "Administration" est utilise pour dsigner de faon abrge
aussi bien une administration de tlcommunications qu'une exploitation reconnue.
Le respect de cette Recommandation se fait titre volontaire. Cependant, il se peut que la Recommandation
contienne certaines dispositions obligatoires (pour assurer, par exemple, l'interoprabilit et l'applicabilit) et
considre que la Recommandation est respecte lorsque toutes ces dispositions sont observes. Le futur
d'obligation et les autres moyens d'expression de l'obligation comme le verbe "devoir" ainsi que leurs formes
ngatives servent noncer des prescriptions. L'utilisation de ces formes ne signifie pas qu'il est obligatoire
de respecter la Recommandation.

DROITS DE PROPRIT INTELLECTUELLE


L'UIT attire l'attention sur la possibilit que l'application ou la mise en uvre de la prsente
Recommandation puisse donner lieu l'utilisation d'un droit de proprit intellectuelle. L'UIT ne prend pas
position en ce qui concerne l'existence, la validit ou l'applicabilit des droits de proprit intellectuelle,
qu'ils soient revendiqus par un membre de l'UIT ou par une tierce partie trangre la procdure
d'laboration des Recommandations.
A la date d'approbation de la prsente Recommandation, l'UIT n'avait pas t avise de l'existence d'une
proprit intellectuelle protge par des brevets acqurir pour mettre en uvre la prsente
Recommandation. Toutefois, comme il ne s'agit peut-tre pas de renseignements les plus rcents, il est
vivement recommand aux dveloppeurs de consulter la base de donnes des brevets du TSB sous
http://www.itu.int/ITU-T/ipr/.

UIT 2007
Tous droits rservs. Aucune partie de cette publication ne peut tre reproduite, par quelque procd que ce
soit, sans l'accord crit pralable de l'UIT.

ii

Rec. UIT-T Y.2261 (09/2006)

TABLE DES MATIRES


Page
1

Domaine d'application ..................................................................................................

Rfrences normatives..................................................................................................

Dfinitions ....................................................................................................................

Abrviations..................................................................................................................

Conventions ..................................................................................................................

Evolution des RTPC/RNIS vers les NGN ....................................................................

Aspects examiner lors de l'volution vers un NGN...................................................


7.1
Transport.........................................................................................................
7.2
Signalisation et commande.............................................................................
7.3
Gestion............................................................................................................
7.4
Services...........................................................................................................
7.5
Gestion, exploitation et maintenance (OAM, operation, administration
and maintenance) ...........................................................................................
7.6
Nommage, numrotage et adressage ..............................................................
7.7
Comptabilit, taxation et facturation ..............................................................
7.8
Interfonctionnement .......................................................................................
7.9
Routage d'appel ..............................................................................................

6
6
6
6
7

Exigences des organismes de rglementation nationaux concernant les services........

10

Tlcommunications d'urgence dans un NGN .............................................................

10

10

Aspects de l'volution lis la scurit ........................................................................

11

Appendice I Exemples de scnarios d'volution de rseaux.................................................


I.1
Evolution du rseau central ............................................................................
I.2
Evolution du rseau d'accs............................................................................
I.3
Scnarios de signalisation et de commande ...................................................
I.4
Scnarios de gestion .......................................................................................
I.5
Scnarios d'volution des services .................................................................

12
12
18
20
21
21

Appendice II Exemples d'volution des services du RTPC/RNIS........................................

26

Appendice III Scnarios d'volution pour le systme de facturation....................................

27

BIBLIOGRAPHIE ...................................................................................................................

28

Rec. UIT-T Y.2261 (09/2006)

iii

7
8
8
9
9

Recommandation UIT-T Y.2261


Evolution des RTPC/RNIS vers les rseaux de prochaine gnration
1

Domaine d'application

Parmi les rseaux de tlcommunication, les rseaux tlphoniques publics commuts et les rseaux
numriques intgration des services (RTPC/RNIS) sont considrs comme tant de bons candidats
pour l'volution vers les rseaux de prochaine gnration (NGN, next generation network) [Y.2001]
et [Y.2011]. Les RTPC/RNIS tant largement dploys et utiliss, il convient d'envisager l'volution
vers les NGN tape par tape.
La prsente Recommandation dcrit diffrentes possibilits d'volution des RTPC/RNIS vers les
NGN. Elle dcrit la fois l'volution fonde sur un sous-systme multimdia IP (IMS, IP
multimedia sub-system) et celle fonde sur un serveur d'appel (CS, call server). Elle porte sur les
aspects prendre en considration, savoir l'volution des parties de transport, de gestion, de
signalisation et de commande des RTPC/RNIS vers les NGN. Des scnarios d'volution sont par
ailleurs dcrits dans le prsent document.
Les Administrations pourront exiger que les oprateurs et les fournisseurs de services tiennent
compte de la rglementation nationale et des orientations gnrales nationales lors de la mise en
uvre de la prsente Recommandation.
2

Rfrences normatives

La prsente Recommandation se rfre certaines dispositions des Recommandations UIT-T et


textes suivants qui, de ce fait, en sont partie intgrante. Les versions indiques taient en vigueur au
moment de la publication de la prsente Recommandation. Toute Recommandation ou tout texte
tant sujet rvision, les utilisateurs de la prsente Recommandation sont invits se reporter, si
possible, aux versions les plus rcentes des rfrences normatives suivantes. La liste des
Recommandations de l'UIT-T en vigueur est rgulirement publie. La rfrence un document
figurant dans la prsente Recommandation ne donne pas ce document, en tant que tel, le statut
d'une Recommandation.
[G.964]

Recommandation UIT-T G.964 (2001), Interfaces V au commutateur local


numrique Interface V5.1 (base sur la hirarchie 2048 kbit/s) pour la prise en
charge du rseau d'accs.

[G.965]

Recommandation UIT-T G.965 (2001), Interfaces V au commutateur numrique


local Interface V5.2 (base sur la hirarchie 2048 kbit/s) pour la prise en
charge du rseau d'accs.

[I.610]

Recommandation UIT-T I.610 (1999), Principes et fonctions d'exploitation et de


maintenance du RNIS large bande.

[M.3010]

Recommandation UIT-T M.3010 (2000), Principes du rseau de gestion des


tlcommunications.

[M.3400]

Recommandation UIT-T M.3400 (2000), Fonctions de gestion du rseau de gestion


des tlcommunications.

[Q.310-Q.332] Recommandation UIT-T Q.310-Q.332 (1988), Spcifications du systme de


signalisation R1.
[Q.400-Q.490] Recommandation UIT-T Q.400-Q.490 (1988), Spcifications du systme de
signalisation R2.

Rec. UIT-T Y.2261 (09/2006)

[Q.931]

Recommandation UIT-T Q.931 (1998), Spcification de la couche 3 de l'interface


utilisateur-rseau RNIS pour la commande de l'appel de base.

[Q.1741.3]

Recommandation UIT-T Q.1741.3 (2003), Rfrences IMT-2000 la version 5 du


rseau central UMTS issu du GSM.

[Q.1912.5]

Recommandation UIT-T Q.1912.5 (2004), Interfonctionnement entre le protocole


d'ouverture de session (SIP) et le protocole de commande d'appel indpendante du
support ou le sous-systme utilisateur du RNIS.

[X.462]

Recommandation UIT-T X.462 (1996), Technologies de l'information Gestion


des systmes de messagerie: information de journalisation.

[Y.1411]

Recommandation UIT-T Y.1411 (2003), Interfonctionnement des rseaux ATM et


MPLS Interfonctionnement dans le plan utilisateur en mode cellule.

[Y.1541]

Recommandation UIT-T Y.1541 (2006), Objectifs de performances de rseau pour


les services en mode IP.

[Y.1710]

Recommandation UIT-T Y.1710 (2002), Prescriptions relatives la fonctionnalit


d'exploitation et de maintenance pour les rseaux MPLS.

[Y.2001]

Recommandation UIT-T Y.2001 (2004), Aperu gnral des rseaux de prochaine


gnration.

[Y.2011]

Recommandation UIT-T Y.2011 (2004), Principes gnraux et modle de


rfrence gnral pour les rseaux de prochaine gnration.

[Y.2271]

Recommandation UIT-T Y.2271 (2006), Emulation des RTPC/RNIS serveur


d'appels.

[TS 122 115]

ETSI TS 122 115 v6.7.0 (2006), Digital cellular telecommunications system


(Phase 2+); Universal Mobile Telecommunications System (UMTS); Service
aspects; Charging and billing.

Dfinitions

La prsente Recommandation utilise ou dfinit les termes suivants:


NOTE Dans le prsent paragraphe, la notation [aaa] immdiatement aprs un terme indique l'origine de la
dfinition de ce terme.

3.1
passerelle d'accs (AG, access gateway): dispositif permettant aux utilisateurs finals
disposant de divers accs (par exemple RTPC, RNIS, V5.x) de se raccorder au nud en mode
paquet du NGN.
NOTE La passerelle d'accs peut tre intgre un nud d'accs, qui dessert galement d'autres interfaces
d'accs (par exemple xDSL, LAN). Ces nuds d'accs sont galement appels nuds d'accs multiservices
(MSAN, multi-service access node).

3.2

rseau d'accs (AN, access network): voir la Rec. UIT-T G.964 [G.964].

3.3

comptabilit: voir la Rec. UIT-T X.462 [X.462].

3.4
application: ensemble structur de capacits, qui constituent une fonctionnalit valeur
ajoute accepte par un ou plusieurs services, pouvant tre pris en charge par une interface API.
3.5
serveur d'application (AS, application server) [Y.2271]: dispositif qui interagit avec le
serveur d'appel et le serveur de profil d'utilisateur pour assurer l'excution des services.
3.6

facturation: voir la Rec. UIT-T Q.1741.3 [Q.1741.3].

Rec. UIT-T Y.2261 (09/2006)

3.7
serveur d'appel (CS, call server) [Y.2271]: lment central d'une mulation de
RTPC/RNIS fonde sur un serveur d'appel, charg de la commande d'appel, du contrle des
ressources mdias, du routage d'appel, de l'authentification du profil d'utilisateur et de l'abonn, de
l'autorisation et de la comptabilit. Suivant son rle, le serveur d'appel pourra avoir un
comportement diffrent, auquel cas le rle est prcis, par exemple "serveur d'appel d'accs",
"serveur d'appel d'chappement", "serveur d'appel IMS", "serveur d'appel de routage" ou "serveur
d'appel passerelle".
3.8

taxation: voir la Rec. UIT-T Q.1741.3 [Q.1741.3].

3.9
volution vers les NGN: processus dans lequel la totalit ou une partie des rseaux
existants est remplace ou mise niveau afin de comporter les composants de NGN correspondants
offrant une fonctionnalit analogue ou meilleure, tout en essayant de conserver les services fournis
par le rseau d'origine et d'ajouter ventuellement de nouvelles capacits.
3.10
passerelle: dispositif qui interconnecte diffrents rseaux et qui procde la traduction
ncessaire entre les protocoles utiliss dans ces rseaux.
3.11
serveur de mdia (MS, media server) [Y.2271]: lment de rseau assurant la fonction de
traitement des ressources mdias pour les services de tlcommunication dans les NGN.
3.12
module distant d'accs de l'utilisateur (RUAM, remote user access module): dispositif
qui est situ physiquement l'extrmit de lignes d'abonn et qui convertit les signaux analogiques
en signaux numriques. Le module RUAM est situ physiquement distance du central local.
3.13
passerelle de signalisation (SG, signalling gateway): dispositif qui assure la conversion de
signalisation de commande d'appel hors bande entre un NGN et d'autres rseaux (par exemple entre
un serveur d'appel d'un NGN et un point STP ou SSP d'un rseau utilisant la signalisation SS7).
3.14
passerelle de mdia de jonction (TMG, trunking media gateway): dispositif qui assure
l'interface entre les nuds en mode paquet du NGN et les nuds commutation de circuit (par
exemple central de transit, central local, central international) du RTPC/RNIS pour le trafic support.
La passerelle TMG assure l'ventuelle conversion ncessaire du trafic support.
3.15
module d'accs de l'utilisateur (UAM, user access module): dispositif qui est situ
physiquement l'extrmit de lignes d'abonn et qui convertit les signaux analogiques en signaux
numriques. Le module UAM est situ au mme endroit qu'un central local, auquel il est raccord.
4

Abrviations

La prsente Recommandation utilise les abrviations suivantes:


ACS

serveur d'appel d'accs (access call server)

AG

passerelle d'accs (access gateway)

AN

rseau d'accs (access network)

API

interface de programmation d'application (application programming interface)

AS

serveur d'application (application server)

ATM

mode de transfert asynchrone (asynchronous transfer mode)

BCS

serveur d'appel d'chappement (breakout call server)

BICC

commande d'appel indpendante du support (bearer independent call control)

CAS

signalisation canal par canal (channel associated signalling)

CCS

signalisation par canal smaphore (common channel signalling)

CDR

relev d'appel (call detail record)


Rec. UIT-T Y.2261 (09/2006)

CL

central local

CS

serveur d'appel (call server)

CT

contenu de tlcommunication (content of telecommunication)

DSL

ligne d'abonn numrique (digital subscriber line)

DSLAM

multiplexeur d'accs de ligne d'abonn numrique (digital subscriber line access


multiplexer)

DSS1

systme de signalisation numrique n 1 (digital signalling system no. 1)

DTMF

numrotation multifrquence deux tonalits (dual tone multi frequency)

ETS

service de tlcommunication d'urgence (emergency telecommunications service)

FTTC

fibre jusqu'au point de concentration (fibre-to-the-curb)

FTTH

fibre jusqu'au domicile (fibre-to-the-home)

GCS

serveur d'appel passerelle (gateway call server)

ICS

serveur d'appel IMS (IMS call server)

IMS

sous-systme multimdia IP (IP multimedia subsystem)

INAP

sous-systme application du rseau intelligent (intelligent network application part)

IP

protocole Internet (Internet protocol)

IRI

informations lies aux interceptions (intercept-related information)

IVR

rponse vocale interactive (interactive voice response)

LEA

organismes d'application des lois (law enforcement agencies)

MS

serveur de mdia (media server)

MSAN

nud d'accs multiservice (multi-service access node)

NGN

rseau de prochaine gnration (next generation network)

OSS

systme d'assistance l'exploitation (operations support system)

PBX

autocommutateur priv (private branch exchange)

PSAP

point de rponse pour la scurit du public (public safety answering point)

QS

qualit de service

RCP

rseau commutation par paquets

RCS

serveur d'appel de routage (routing call server)

RI

rseau intelligent

RMTP

rseau mobile terrestre public

RNIS

rseau numrique intgration des services

RNIS-BE

RNIS bande troite

RTC

service ordinaire

RTPC

rseau tlphonique public commut

RUAM

module distant d'accs de l'utilisateur (remote user access module)

SCE

environnement de cration de services (service creation environment)

SCP

point de commande de service (service control point)

Rec. UIT-T Y.2261 (09/2006)

SG

passerelle de signalisation (signalling gateway)

SIP

protocole d'ouverture de session (session initiation protocol)

SS7

systme de signalisation n 7

SSF

fonction de commutation de service (service switching function)

SSP

point de commutation de service (service switching point)

STP

point de transfert de signalisation (signalling transfer point)

TDR

tlcommunications pour les secours en cas de catastrophe (telecommunications for


disaster relief)

TE

central de transit (transit exchange)

TMG

passerelle de mdia de jonction (trunking media gateway)

TVIP

tlvision IP

UAM

module d'accs de l'utilisateur (user access module)

URI

identificateur uniforme de ressource (uniform resource identifier)

VoD

vido la demande (video on demand)

VoIP

tlphonie IP (voice over IP)

xDSL

ligne d'abonn numrique x (x digital subscriber line)

Conventions

Aucune.
6

Evolution des RTPC/RNIS vers les NGN

Les RTPC/RNIS sont de bons candidats pour l'volution vers les NGN et, en tant que tels, il
convient d'examiner avec soin tous les aspects et de prendre des mesures appropries.
D'une manire gnrale, un RTPC/RNIS comporte les entits suivantes, chacune ayant une ou
plusieurs fonctionnalits:

transport (rseau d'accs plus rseau central): module d'accs de l'utilisateur (UAM),
module distant d'accs de l'utilisateur (RUAM), rseau d'accs (AN) via l'interface V5.1/2
[G.964] et [G.965] raccorde aux commutateurs dans le rseau central et commutateurs
dans le rseau central proprement dits;

commande et signalisation: centraux principaux;

gestion: gestion des centraux;

service: centraux principaux et rseau auxiliaire (par exemple RI).


Dans un RTPC/RNIS, la plupart des fonctionnalits sont situes dans un mme central et peuvent
utiliser des protocoles propritaires, alors que dans un NGN, les fonctionnalits peuvent tre
rparties dans plusieurs lments. Les paragraphes qui suivent dcrivent en dtail les tapes de
l'volution d'un RTPC/RNIS vers un NGN.

Rec. UIT-T Y.2261 (09/2006)

Aspects examiner lors de l'volution vers un NGN

Pour l'volution d'un RTPC/RNIS vers un NGN, il faut examiner les aspects dcrits dans les
paragraphes qui suivent.
7.1

Transport

Le transport est une partie importante de n'importe quel rseau. Il regroupe des fonctions lies:

aux quipements locaux des abonns (par exemple terminaux, autocommutateurs privs,
routeurs);

aux quipements du rseau d'accs (par exemple modules de terminaison de ligne,


concentrateurs distants ou locaux, multiplexeurs);

aux quipements du rseau central (par exemple centraux locaux, installations de


transmission, centraux de transit et centraux internationaux).
Il convient d'examiner tous les aspects lis au transport qui peuvent tre affects par l'volution vers
un NGN.
7.1.1

Fourniture de lignes loues

La fourniture de lignes loues est propre au rseau.


7.2

Signalisation et commande

Un RTPC/RNIS utilise des systmes de signalisation tels que le systme de signalisation de ligne
analogique, les systmes de signalisation canal par canal (CAS) comme le systme R1
[Q.310-Q.332] ou le systme R2 [Q.400-Q.490] et les systmes de signalisation par canal
smaphore (CCS) comme le systme SS7 ou le systme DSS1 [Q.931]. Tous ces systmes de
signalisation sont destins aux rseaux commutation de circuit. Comme le transport dans un NGN
est fond sur les paquets (et que l'appel et le support sont dcoupls), d'autres types appropris de
signalisation (par exemple BICC, SIP-I [Q.1912.5], etc.) peuvent tre requis. Par ailleurs, la
fonction de signalisation et la fonction de commande d'appel peuvent rsider dans plus d'un lment
de NGN.
Comme les NGN doivent fonctionner avec des RTPC/RNIS et avec d'autres rseaux,
l'interfonctionnement entre les systmes de signalisation des NGN et les systmes de signalisation
des rseaux traditionnels est obligatoire.
Les aspects lis la signalisation dans les rseaux d'entreprise de prochaine gnration doivent
rester indpendants de la signalisation dans le rseau d'accs ou dans le rseau central des NGN.
Les aspects lis la signalisation dans le rseau d'accs devraient en outre tre indpendants des
aspects lis la signalisation dans le rseau central afin de pouvoir procder par tapes en ce qui
concerne l'volution vers les NGN.
7.3

Gestion

La gestion de RTPC/RNIS comporte des activits lies au rseau d'change central, au rseau
d'accs, au rseau intelligent ainsi qu'au systme d'assistance l'exploitation (OSS, operations
support system). Les Recommandations UIT-T [M.3400] et [M.3010] noncent les principes de
gestion des RTPC/RNIS.
Le systme de gestion de NGN comporte trois plans: le plan de gestion du rseau, le plan de
commande du rseau et le plan de gestion des services. Chacun de ces trois plans implmente les
fonctions de gestion correspondantes dans chaque couche du modle stratifi de NGN. Il faut
dfinir des interfaces normalises entre ces plans mais cela sort du cadre de la prsente
Recommandation.

Rec. UIT-T Y.2261 (09/2006)

Pour l'volution des systmes de gestion (autrement dit exploitation, administration et gestion) de
RTPC/RNIS, des tapes intermdiaires doivent pouvoir tre prises en charge pour l'volution du
RTPC/RNIS vers un NGN. On pourra trouver davantage de dtails dans les documents lis la
gestion de NGN.
7.4

Services

Les services de RTPC/RNIS qui sont traditionnellement fournis par les centraux de RTPC/RNIS
peuvent tre assurs par des serveurs d'application (AS) de NGN. Certains services peuvent aussi
tre implments dans un serveur d'appel (CS) [Y.2271].
La totalit ou une partie des services existants devraient tre assurs par le NGN. Toutefois, il n'est
pas garanti que tous les services soient assurs en cas de simulation de RTPC/RNIS.
Il est prvu d'utiliser les terminaux existants au moyen d'une adaptation au NGN afin de prendre en
charge les services existants.
La coopration entre les serveurs d'application et les serveurs d'appel est ncessaire pour pouvoir
fournir certains services.
Dans le cas d'une concatnation de plusieurs NGN, il devrait tre possible d'accder aux services
depuis le NGN distant.
L'Appendice II donne un exemple d'volution de services de RTPC/RNIS.
7.4.1

Services support

Lors de l'volution d'un RTPC/RNIS vers un NGN, il convient d'assurer la continuit des services
support.
La simulation de RTPC/RNIS prsente une fonctionnalit qui est analogue mais qui n'est pas
identique aux services support existants du RNIS-BE.
L'mulation de RTPC/RNIS doit pouvoir assurer tous les services support offerts par le
RTPC/RNIS. Toutefois, il n'est pas ncessaire que le NGN prenne en charge tous les services
support du RNIS-BE identifis dans les Recommandations UIT-T de la srie I.230.
L'utilisation du NGN pour raccorder des RTPC/RNIS doit tre transparente pour tous les services
support.
Le NGN devrait offrir une qualit de service gale ou suprieure pour les services supports du
RTPC/RNIS.
7.4.2

Services complmentaires

Lors de l'volution d'un RTPC/RNIS vers un NGN, il convient d'assurer la continuit des services
complmentaires dans la mesure du possible. L'mulation de RTPC/RNIS doit prendre en charge
tous les services complmentaires offerts par le RTPC/RNIS. La simulation de RTPC/RNIS
prsente une fonctionnalit qui est analogue mais qui n'est pas identique aux services existants du
RTPC/RNIS. Il n'est pas ncessaire que le NGN prenne en charge tous les services complmentaires
du RNIS identifis dans les Recommandations UIT-T de la srie I.250. L'utilisation du NGN pour
raccorder des RTPC/RNIS doit tre transparente pour les services complmentaires.
7.5

Gestion, exploitation et maintenance (OAM, operation, administration and


maintenance)

La fonctionnalit OAM sert vrifier la performance du rseau et rduire les dpenses


d'exploitation en minimalisant les interruptions de service, la dgradation des services et la dure
des pannes. La fonctionnalit OAM et les objectifs associs sont dcrits pour les rseaux
traditionnels et les rseaux IP dans les Recommandations UIT-T [I.610] et [Y.1710] ainsi que dans
plusieurs autres Recommandations portant sur toutes les couches et les strates.
Rec. UIT-T Y.2261 (09/2006)

Lors de l'volution d'un RTPC/RNIS vers un NGN, il faut au minimum prvoir la capacit de
dtecter les drangements, dfauts et pannes (par exemple les paquets perdus, errons ou mal
insrs). Il convient en outre de prvoir des mcanismes permettant d'indiquer l'tat de connectivit
et de surveiller la performance.
Comme l'volution concerne plusieurs rseaux, il est ncessaire de dterminer et de signaler quel
fournisseur de rseau ou de services est responsable du dfaut afin de pouvoir prendre la mesure qui
s'impose.
7.6

Nommage, numrotage et adressage

Les plans de nommage, numrotage et adressage de NGN conformes la Rec. UIT-T [Y.2001]
doivent pouvoir interfonctionner avec le plan de numrotage E.164 existant.
Au cours du processus d'volution d'un RTPC/RNIS vers un NGN, il convient de veiller ce que la
souverainet des tats Membres de l'UIT vis--vis des plans de numrotage, de nommage,
d'adressage et d'identification associs aux indicatifs de pays soit intgralement maintenue. Il
convient aussi, au minimum, de prendre en charge les plans d'adressage IP Internet comportant des
identificateurs uniformes de ressources de tlphone E.164 (URI TEL), par exemple
tl: +98 765 4321, et/ou des identificateurs uniformes de ressources SIP (URI SIP), par exemple
sip:my.name@company.org.
Pour tout cela, il convient de faire en sorte que les services fournis aux utilisateurs finals ne soient
pas affects.
7.7

Comptabilit, taxation et facturation

Il est communment accept que la mise en place de NGN entranera des modifications des
procdures existantes de "comptabilit, taxation et facturation". Toutefois, ces modifications ne
seront pas immdiates. Pendant la priode de transition, il pourra tre ncessaire de maintenir les
procdures existantes dans la mesure du possible.
L'volution des rseaux existants vers les NGN entranera aussi le remplacement des sources
existantes de production de donnes de comptabilit. Les nouveaux modles oprationnels
correspondant aux services de NGN pourront comporter un plus grand nombre de rles
oprationnels en matire de taxation.
Les aspects suivants lis la comptabilit pourront donc tre affects:
a)
contenu informationnel;
b)
interfaces d'autres systmes;
c)
format des donnes;
d)
scurit des donnes, savoir protection, scurit de transmission et confidentialit des
donnes.
7.7.1

Considrations

Le NGN doit prendre en charge la fois la taxation en diffr et la taxation en temps rel. Pour
l'volution vers un NGN, il faut tenir compte des facteurs suivants. Toutefois, cette liste n'est pas
exhaustive.

Contenu informationnel les informations contenues dans les relevs d'appel (CDR, call
detail record) doivent tre cohrentes avec les informations dj fournies dans le
RTPC/RNIS. Il convient notamment de fournir les donnes suivantes:
identification de l'appelant et/ou de l'appel;
date et heure de l'vnement;
type du service ou de l'vnement;
8

Rec. UIT-T Y.2261 (09/2006)

dure de l'appel ou de la session.


Il faut aussi fournir de nouvelles informations, propres au NGN, par exemple:
largeur de bande;
QS;
type de mdia.
Sources de donnes:
serveur d'appel;
serveur de mdia;
passerelle d'accs;
passerelle de mdia de jonction;
serveur d'application.
Spcifications du format des donnes:
complexit de codage optimale;
commodit de la collecte des donnes et de l'laboration des relevs;
taille optimale pour les donnes;
stockage efficace des donnes.
Interfaces vers d'autres systmes:
pour les mthodes de collecte en temps rel ou globale des donnes de comptabilit;
pour la taxation en temps rel ou en diffr;
pour d'autres services comme l'indication de taxation et la limite de crdit.

On trouvera davantage d'informations dans d'autres Recommandations UIT-T ou dans la norme


[TS 122 115].
7.8

Interfonctionnement

L'interfonctionnement tel que dfini dans la rfrence [Y.1411] sert exprimer des interactions
entre des rseaux, entre des systmes d'extrmit ou entre des parties de rseau ou de systme
d'extrmit, afin de dfinir une entit fonctionnelle capable de prendre en charge des
tlcommunications de bout en bout. Pour l'volution d'un RTPC/RNIS vers un NGN, il convient de
tenir compte de ce qui suit:

capacit d'interfonctionnement avec des rseaux fonds ou non sur un sous-systme IMS
(par exemple autres RTPC/RNIS, rseaux IP publics (NGN, Internet, etc.));

capacit d'interfonctionnement entre domaines, entre zones ou entre rseaux;

prise en charge de l'authentification et de l'autorisation;

capacit de raliser le contrle d'admission d'appel;

capacit de prendre en charge les paramtres de performance de rseau dfinis dans la


rfrence [Y.1541];

prise en charge de la comptabilit, de la taxation et de la facturation.


NOTE La liste ci-dessus n'est pas exhaustive.

7.9

Routage d'appel

Lorsqu'un NGN coexiste avec un RTPC/RNIS, le plan de routage devrait permettre aux exploitants
de contrler o leur trafic entre dans le NGN et o il en sort. Les exploitants pourront ainsi
optimiser l'utilisation de leurs ressources de rseau et viter de prvoir des points
d'interfonctionnement multiples entre le NGN et le RTPC/RNIS le long du trajet de mdia.
Rec. UIT-T Y.2261 (09/2006)

Exigences des organismes de rglementation nationaux concernant les services

Lorsque la rglementation ou la lgislation nationale ou rgionale l'exige, un fournisseur de services


de NGN doit:

fournir le service tlphonique de base avec une qualit et une disponibilit gales ou
suprieures celles offertes par le RTPC/RNIS existant;

permettre une taxation et une comptabilit prcises;

prendre en charge la portabilit de numro;

permettre l'utilisateur de choisir l'exploitant pour les appels locaux et pour les appels
longue distance;

assurer la disponibilit du service de renseignement concernant l'annuaire pour les


utilisateurs du RTPC/RNIS et du NGN;

prendre en charge les tlcommunications d'urgence comme indiqu au 9;

prendre en charge des capacits et procdures de retour la normale aprs une catastrophe;

prendre en charge tous les utilisateurs, y compris les handicaps. Il convient de prendre en
charge au moins les mmes capacits que le RTPC/RNIS existant. Le NGN offre la
possibilit de prendre en charge des capacits plus volues, par exemple des capacits de
rseau pour la synthse vocale;

assurer le respect de la vie prive des utilisateurs et la confidentialit de leurs informations;

prvoir des mcanismes prenant en charge l'interception lgale et la surveillance de divers


types de mdia de tlcommunication (signaux vocaux, donnes, signaux vido, courriel,
messagerie, etc.). Un fournisseur de rseau peut tre amen prvoir ce type de mcanisme
pour permettre aux organismes d'application des lois (LEA, law enforcement agencies)
d'accder au contenu de tlcommunication (CT) et aux informations lies aux
interceptions (IRI, intercept-related information) et ce, afin de respecter les dispositions
prises par les administrations ainsi que les traits internationaux;

assurer l'interoprabilit entre le NGN et les autres rseaux (par exemple RTPC/RNIS et
RMTP).
La liste des services requis dans les systmes de tlcommunication publics dans chaque pays est
fonde sur la rglementation nationale. La prsente Recommandation ne porte pas sur les
dispositions dtailles des rglementations nationales.
9

Tlcommunications d'urgence dans un NGN

Il est souhaitable qu'un NGN:

permette de prendre en charge des mcanismes de priorit pour les tlcommunications


d'urgence dans les services multimdias (par exemple voix, donnes et image). Les
tlcommunications d'urgence incluent:
a) des tlcommunications entre deux individus;
b) des tlcommunications entre un individu et une autorit, savoir les appels destins
des fournisseurs de services d'urgence;
c) des tlcommunications entre deux autorits, savoir les tlcommunications pour les
secours en cas de catastrophe (TDR, telecommunications for disaster relief);
d) des tlcommunications entre une autorit et un individu;

prenne en charge les appels destins des fournisseurs de services d'urgence, qui peuvent
tre gratuits pour l'appelant. Ces appels devraient inclure des informations sur la marche
suivre pour permettre aux services d'urgence de rappeler l'appelant. Ces informations,
parmi lesquelles devrait au moins figurer une information prcise de localisation de
10

Rec. UIT-T Y.2261 (09/2006)

10

l'appelant au moment du lancement de l'appel, devront par exemple tre communiques aux
centres d'intervention en cas d'urgence, pour acheminer l'appel au point de rponse pour la
scurit du public (PSAP, public safety answering point) que l'utilisateur soit fixe, mobile
ou nomade. Une information prcise de localisation peut tre une adresse postale, des
coordonnes gographiques ou toute autre information (par exemple un indicateur de
cellule). Il faut fournir la fois des informations concernant le rseau et des informations
concernant l'emplacement de l'utilisateur, si ces informations sont disponibles;
garantisse que la prsentation d'identification de la ligne appelante (ou l'information
quivalente dans le sous-systme IMS) ne soit pas supprime pour un appel, une ligne ou
une identit donn, pour les appels destination d'un numro d'urgence;
conserve son intgrit, dans la mesure du possible, afin de prendre en charge les
tlcommunications critiques (par exemple prise en charge des tlcommunications TDR
dans une situation de crise).
Aspects de l'volution lis la scurit

Le NGN doit offrir au moins le mme niveau de scurit que celui offert dans le RTPC/RNIS
existant. Au fur et mesure de l'volution du RTPC/RNIS vers le NGN, de nouvelles
proccupations et de nouvelles menaces, inconnues dans le RTPC/RNIS, peuvent tre rencontres.
Par consquent, des mesures additionnelles peuvent tre requises pour garantir au moins le niveau
de scurit existant.
Pour rpondre cette exigence, il faut tenir de diffrentes dimensions de scurit, qui dpendent de
la mthode d'accs:

authentification;

non-rpudiation;

confidentialit des donnes;

scurit des tlcommunications;

intgrit des donnes;

disponibilit;

respect de la vie prive.


Les moyens de scurit mis en place dans le NGN peuvent servir scuriser les scnarios de
simulation ou d'mulation de RTPC/RNIS. La liste complte des exigences de scurit pour les
NGN sort du cadre de la prsente Recommandation.

Rec. UIT-T Y.2261 (09/2006)

11

Appendice I
Exemples de scnarios d'volution de rseaux
Tous les scnarios d'volution vers les NGN reposent sur la sparation des fonctionnalits de
transport, de commande, de service et de gestion.
Les scnarios d'volution comportent une ou plusieurs tapes, suivant l'ampleur de l'implmentation
de ces sparations.
Des scnarios possibles d'volution du RTPC/RNIS sont prsents dans les paragraphes qui suivent.
I.1

Evolution du rseau central

I.1.1

Evolution fonde sur un serveur d'appel

I.1.1.1

Gnralits

Le serveur d'appel est l'lment central d'une mulation de RTPC/RNIS. Il est charg de la
commande d'appel, de la commande de passerelle, du contrle des ressources mdias, du routage,
de l'authentification du profil d'utilisateur et de l'abonn, de l'autorisation et de la comptabilit. Le
serveur d'appel peut assurer le service de base et les services complmentaires du RTPC/RNIS, et
peut assurer des services valeur ajoute par le biais d'une interaction avec un point de commande
de service (SCP, service control point) externe et/ou un serveur d'application dans la couche
service/application. Une implmentation de serveur d'appel entirement conforme n'a besoin
d'implmenter que certaines des composantes indiques ici, mme s'il est possible de combiner
plusieurs fonctions dans une mme entit.
Un serveur d'appel peut remplir un ou plusieurs des rles suivants [Y.2271]:

serveur d'appel d'accs (ACS, access server call) pour implmenter des fonctions de
commande de passerelle d'accs et de contrle des ressources mdias, permettant ainsi
d'assurer le service de base et les services complmentaires du RTPC/RNIS;

serveur d'appel d'chappement (BCS, breakout call server) pour implmenter des
fonctions d'interfonctionnement afin d'assurer une interconnexion avec les RTPC/RNIS;

serveur d'appel IMS (ICS, IMS call server) pour assurer l'interoprabilit entre les
composantes d'mulation de RTPC/RNIS et les composantes multimdias IP dans un mme
domaine de NGN;

serveur d'appel passerelle (GCS, gateway call server) pour assurer l'interoprabilit entre
diffrents domaines de NGN provenant de diffrents fournisseurs de service;

serveur d'appel de routage (RCS, routing call server) pour assurer la fonction de routage
entre serveurs d'appel.
I.1.1.2

Regroupement de centraux locaux et distants pour l'volution vers un NGN

En vue de l'volution du RTPC/RNIS vers un rseau commutation de paquets (RCP), on peut,


dans une premire tape de prparation, supprimer certains centraux locaux (CL) et transfrer toutes
leurs fonctionnalits (commande, comptabilit, etc.) vers les autres centraux locaux. Les modules
UAM, les autocommutateurs privs (PBX) et les rseaux d'accs (AN) affects sont raccords aux
autres centraux locaux, les modules UAM affects devenant alors des modules RUAM. La
Figure I.1 montre cette tape de prparation.

12

Rec. UIT-T Y.2261 (09/2006)

Figure I.1/Y.2261 Prparation pour l'volution vers un NGN


I.1.1.3

Scnario 1 RTPC/RNIS et RCP coexistent au dpart

Dans l'approche initiale la plus probable pour l'volution du RTPC/RNIS vers un RCP, le
RTPC/RNIS coexistera avec le RCP pendant une priode de transition, comme indiqu sur la
Figure I.2. Ce scnario comporte deux tapes, comme expliqu ci-dessous.
Etape 1
Dans cette tape, certains centraux locaux (CL) sont remplacs par des passerelles d'accs (AG).
Les fonctions qui au dpart taient remplies par les centraux locaux supprims le sont dsormais par
des passerelles d'accs et un serveur d'appel (CS). En outre, certains lments d'accs (modules
UAM, modules RUAM et autocommutateurs privs (PBX) par exemple), qui au dpart taient
raccords aux centraux locaux supprims, sont dsormais raccords directement des passerelles
d'accs. D'autres passerelles d'accs (AG) peuvent aussi tre dployes pour prendre en charge de
nouveaux abonns qui se raccordent directement ces passerelles. Des passerelles TMG et SG sont
dployes pour assurer l'interconnexion entre le RCP et les centraux de transit (TE) du rseau
traditionnel ainsi que les RTPC/RNIS d'autres oprateurs. Les passerelles AG et TMG sont toutes
commandes par le serveur d'appel (CS).
Etape 2
Dans cette tape, les centraux locaux (CL) restants sont remplacs par des passerelles d'accs (AG)
et les centraux de transit (TE) sont supprims et leurs fonctions de commande sont ralises par le
serveur d'appel (CS). Des passerelles TMG et SG sont dployes pour assurer l'interconnexion entre
le RCP et les RTPC/RNIS d'autres oprateurs. Les passerelles AG et TMG sont toutes commandes
par le serveur d'appel (CS).

Rec. UIT-T Y.2261 (09/2006)

13

Figure I.2/Y.2261 Ralisation du scnario 1


I.1.1.4

Scnario 2 Utilisation immdiate du RCP, au dpart via des passerelles SG et


TMG

Dans ce scnario, le RTPC/RNIS est immdiatement remplac par un RCP. Les centraux locaux
(CL) sont d'abord raccords des passerelles SG et TMG, avant d'tre limins par la suite. Les
deux tapes sont indiques sur la Figure I.3 et expliques ci-dessous.

14

Rec. UIT-T Y.2261 (09/2006)

Etape 1
Dans cette tape, le RTPC/RNIS est remplac par un RCP et les fonctions des centraux de transit
(TE) sont ralises par des passerelles TMG et SG sous la commande du serveur d'appel (CS). Les
centraux locaux (CL) sont raccords au RCP via les passerelles TMG et SG. Des passerelles TMG
et SG sont galement dployes pour assurer l'interconnexion entre le RCP et les RTPC/RNIS
d'autres oprateurs.
Etape 2
Dans cette tape, les centraux locaux (CL) et certains lments d'accs (modules UAM et RUAM
par exemple) sont supprims et leurs fonctions sont remplies par des passerelles d'accs (AG) et le
serveur d'appel (CS). Les autocommutateurs privs (PBX) sont raccords directement des
passerelles d'accs (AG). Les rseaux d'accs (AN) sont soit remplacs par des passerelles d'accs
(AG) soit raccords des passerelles d'accs (AG). Des passerelles TMG et SG sont dployes pour
assurer l'interconnexion entre le RCP et les RTPC/RNIS d'autres oprateurs. Les passerelles AG et
TMG sont toutes commandes par le serveur d'appel (CS).

Rec. UIT-T Y.2261 (09/2006)

15

Figure I.3/Y.2261 Ralisation du scnario 2


I.1.1.5

Scnario 3 Approche en une seule tape

Dans ce scnario, le RTPC/RNIS est remplac par un RCP en une seule tape, comme indiqu sur
la Figure I.4. Les centraux locaux (CL) sont remplacs par des passerelles d'accs (AG) et leurs
fonctions sont rparties entre les passerelles d'accs (AG) et le serveur d'appel (CS). Plus
prcisment, les fonctions de commande d'appel et de comptabilit sont toutes transfres au
serveur d'appel (CS). Tous les lments d'accs (modules UAM, modules RUAM et
autocommutateurs privs (PBX) par exemple) sont raccords des passerelles d'accs (AG). Les
rseaux d'accs (AN) sont soit remplacs par des passerelles d'accs (AG) soit raccords au RCP
par le biais de passerelles d'accs (AG). Des passerelles TMG sous la commande du serveur d'appel,

16

Rec. UIT-T Y.2261 (09/2006)

et des passerelles de signalisation (SG), sont dployes pour remplacer les fonctions des centraux de
transit (TE) et assurer l'interconnexion entre le RCP et les RTPC/RNIS d'autres oprateurs.

Figure I.4/Y.2261 Ralisation du scnario 3


Le Tableau I.1 ci-dessous donne les lments de rseau intervenant dans l'volution d'un
RTPC/RNIS.
Tableau I.1/Y.2261 Elments de rseau intervenant dans
l'volution d'un RTPC/RNIS

Scnario 1
Scnario 2
Scnario 3
X:

applicable

inutile

ACS

BCS

ICS

GCS

RCS

AG

TMG

SG

Etape 1

Etape 2

Etape 1

Etape 2

Etape 1

Rec. UIT-T Y.2261 (09/2006)

17

I.1.2

Evolution fonde sur un sous-systme IMS

La Figure I.5 reprsente un scnario dans lequel le RTPC/RNIS volue directement vers une
architecture de rseau central RCP fonde sur un sous-systme IMS. Les utilisateurs finals accdent
au rseau en utilisant un quipement d'utilisateur NGN ou un quipement d'utilisateur traditionnel
raccord via une passerelle d'accs (AG). Des passerelles TMG et SG sont dployes pour assurer
l'interconnexion entre le NGN et les RTPC/RNIS d'autres oprateurs.

Figure I.5/Y.2261 Evolution d'un RTPC/RNIS vers un NGN,


fonde sur un sous-systme IMS
I.1.3

Rseaux simultans fonds sur un serveur d'appel et sur un sous-systme IMS

Un rseau fond sur un serveur d'appel et un rseau fond sur un sous-systme IMS peuvent tre
implments simultanment lorsqu'un fournisseur de services existant dploie un rseau spar
fond sur un sous-systme IMS pour les nouveaux services et prend en charge les autres services
dans le cadre d'une approche fonde sur un serveur d'appel (CS). L'interfonctionnement de ces deux
types de rseau doit tre assur, ce qui est possible en cas d'utilisation du protocole SIP, mais cela
sort du cadre de la prsente Recommandation.
I.2

Evolution du rseau d'accs

I.2.1

Evolution d'un rseau d'accs xDSL vers un NGN

L'volution d'un rseau d'accs (AN) est dcrite en trois tapes possibles.
Etape 1
Les interfaces traditionnelles AN/UAM sont les suivantes: RTC, RNIS et V5.1/2 [G.964] et
[G.965]. Ces interfaces permettent aux abonns de se raccorder au rseau central RTPC/RNIS via
un central local (CL).
18

Rec. UIT-T Y.2261 (09/2006)

Les abonns au tlphone traditionnel peuvent aussi avoir accs des services large bande grce,
par exemple, une ligne xDSL (voir [G.995.1]). Dans ce cas, l'quipement local d'abonn est un
modem xDSL et l'quipement du fournisseur de services est un multiplexeur d'accs de ligne
d'abonn numrique (DSLAM, digital subscriber line access multiplexer). Comme les interfaces
xDSL permettent aux abonns de se raccorder l'Internet, elles peuvent tre utilises pour permettre
aux abonns de se raccorder un NGN.
Le rseau d'accs (AN), associ un autre domaine d'abonn via une interface V5.x [G.964] et
[G.965], peut tre laiss comme indiqu sur la figure ou il peut tre remplac compltement par une
passerelle d'accs (AG) raccorde directement au NGN.
Etape 2
Le modem xDSL prend en charge les quipements d'abonn traditionnels et peut leur offrir un accs
large bande au NGN. Les utilisateurs IP peuvent aussi utiliser l'interface xDSL pour le transport
vers le NGN. Pour l'interface xDSL, on peut utiliser le protocole Ethernet, permettant de transmettre
des services et des flux de donnes large bande (par exemple VoD, TVIP, VoIP et Internet).
Etape 3
Dans cette tape, les systmes d'extrmit traditionnels sont remplacs par des systmes d'extrmit
NGN et les lignes en cuivre paires torsades sont remplaces par des fibres optiques, soit des
fibres jusqu'au point de concentration (FTTC, fibre-to-the-curb) soit des fibres jusqu'au domicile
(FTTH, fibre-to-the-home), pour augmenter la vitesse de transmission. Pour ce support de
transmission, on peut utiliser le protocole Ethernet.

Rec. UIT-T Y.2261 (09/2006)

19

Figure I.6/Y.2261 Evolution d'un rseau d'accs xDSL vers un NGN


I.3

Scnarios de signalisation et de commande

Pour l'volution de la signalisation dans le rseau central, on donne l'exemple d'un scnario
comportant trois tapes.
Etape 1
Dans cette tape, les fonctions de signalisation sont transfres des centraux de transit (TE) vers des
units indpendantes crant un rseau maill (partiel ou complet) de points STP.

20

Rec. UIT-T Y.2261 (09/2006)

Etape 2
Dans cette tape, les points STP sont transforms en passerelles de signalisation (SG) et sont placs
la limite entre le RTPC/RNIS et le NGN. Il y a alors coexistence entre le rseau traditionnel et le
NGN.
Etape 3
Dans cette tape, tous les centraux locaux (CL) et centraux de transit (TE) sont remplacs par le
NGN.

Figure I.7/Y.2261 Ralisation d'un scnario d'volution de la signalisation


I.4

Scnarios de gestion

Pour l'volution du systme de gestion du RTPC/RNIS, il existe plusieurs possibilits. Dans l'un des
scnarios, le RTPC/RNIS volue vers un NGN mais le systme de gestion du RTPC/RNIS est
utilis pour grer le nouveau NGN. Dans un autre scnario, un systme de gestion de NGN, qui gre
un NGN, gre aussi un RTPC/RNIS. Il ne s'agit pas de la liste complte des scnarios possibles.
I.5

Scnarios d'volution des services

Les scnarios d'volution des services de RI dans le RTPC/RNIS peuvent par exemple tre les
suivants:
I.5.1

Scnario 1

Dans ce scnario, les services de RI existants sont rutiliss dans le NGN grce l'implmentation
de la fonction SSF dans le serveur d'appel (CS). Il existe la fois un RTPC/RNIS et un NGN.
Rec. UIT-T Y.2261 (09/2006)

21

Figure I.8/Y.2261 Ralisation du scnario 1


I.5.2

Scnario 2

Un exemple de point SCP intgr au serveur d'application (AS) est reprsent dans la Figure I.9.
Dans ce modle de rseautage, le point SCP est intgr au serveur d'application. La sous-couche de
communication est une couche de communication uniforme, qui peut assurer la connexion entre le
point SSP, le serveur d'appel (CS), le point SCP et le serveur d'application. Les services crs par
l'environnement de cration de services (SCE, service creation environment) dans le RI peuvent
tre chargs directement dans le module SCP du serveur d'application (AS). Les nouveaux services
labors au moyen d'interfaces ouvertes (telles que les interfaces API Parlay) peuvent tre assurs
partir du module d'application. Le module SCP et le module d'application peuvent tre raccords
par le biais de la sous-couche d'interface de service aux systmes d'exploitation et de maintenance
ainsi qu'aux systmes externes (par exemple centre de facturation, centre de gestion de rseau,
systme de comptabilit).

22

Rec. UIT-T Y.2261 (09/2006)

Figure I.9/Y.2261 Le point SCP est intgr en totalit au serveur d'application


I.5.3

Scnario 3

Dans ce scnario (voir Figure I.10), pour fournir des services valeur ajoute dans le RTPC/RNIS,
on utilise un dispositif IVR pour le traitement des annonces et des signaux multifrquence deux
tonalits (DTMF, dual-tone multi-frequency). Pour fournir ces services valeur ajoute dans le
NGN, on utilise un serveur de mdia (MS) pour le traitement des annonces et des signaux DTMF
via une interface IP.

Rec. UIT-T Y.2261 (09/2006)

23

Figure I.10/Y.2261 Ralisation du scnario 3


I.5.4

Scnario 4

Ce scnario (voir la Figure I.11) comporte deux tapes, excutes l'une aprs l'autre.
Etape 1
C'est une tape dans laquelle les services de RI traditionnels sont assurs partir d'un point SCP et
les nouveaux services valeur ajoute sont implments dans un serveur d'application (AS). Au
cours de l'volution du rseau, la fonction de dclenchement de service peut tre ralise via un
serveur d'appel (CS) ou un sous-systme IMS, qui se raccorde au point SCP via une interface INAP
et qui se raccorde simultanment au serveur d'application (AS) via une interface SIP.
Etape 2
Lorsque l'volution vers le NGN est termine, tous les services valeur ajoute seront assurs par le
serveur d'application (AS).

24

Rec. UIT-T Y.2261 (09/2006)

Figure I.11/Y.2261 Ralisation du scnario 4

Rec. UIT-T Y.2261 (09/2006)

25

Appendice II
Exemples d'volution des services du RTPC/RNIS
Le prsent appendice illustre l'exemple suivant d'volution des services du RTPC/RNIS (voir
Figure II.1:

implmentation de la fonction SSF du RI dans la couche de commande (grce l'utilisation


d'une interface ouverte, le protocole INAP permet de traiter les lments de rseau RI
comme des lments de la couche des services de NGN);

duplication ou implmentation de la logique de service issue du RTPC/RNIS dans la


couche des services de NGN (serveur d'application AS). La logique de service est spare
de la commande;

inclusion du point SCP du RI dans la couche des services de NGN communication


SSP-SCP via le rseau par paquets IP NGN;

environnement SCE commun tous les lments de la couche des services de NGN tape
facultative.
Pour la sparation de la fonction de service au cours de l'volution du RTPC/RNIS, le traitement
des services ralis dans le central local peut simplement tre transfr dans un central de transit par
le biais d'une configuration des donnes. Seuls les centraux de transit sont mis niveau
conformment aux tapes dcrites ci-dessus. De cette faon, la collecte des informations au niveau
du centre de facturation devient aussi plus simple, car tous les services convergent vers les centraux
de transit. Ainsi, seules les informations issues des centraux de transit ont tre collectes et pas les
informations issues de tous les centraux locaux.

Figure II.1/Y.2261 Evolution des services du RTPC/RNIS vers le NGN

26

Rec. UIT-T Y.2261 (09/2006)

Appendice III
Scnarios d'volution pour le systme de facturation
Les trois scnarios suivants (voir la Figure III.1) sont envisags dans le cadre de l'volution vers le
NGN. Le choix du scnario et son droulement dpendent du fournisseur de services.
L'entit de mdiation (MED) permet de transfrer les relevs d'appel (CDR) du RTPC/RNIS au
systme de facturation du NGN ou du NGN au systme de facturation du RTPC/RNIS, aux fins de
traitement.
Scnario 1
Dans ce scnario, on considre que le systme de facturation du NGN gre la fois le RTPC/RNIS
et le NGN. Dans ce cas, tous les aspects de comptabilit sont affects.
Scnario 2
Dans ce scnario, un nouveau systme de facturation est labor pour le NGN tout en gardant le
systme de facturation existant du RTPC/RNIS. Dans ce cas, tous les aspects de comptabilit
doivent tre pris en considration pour le NGN.
Scnario 3
Dans ce scnario, on considre que le systme de facturation traditionnel gre la fois le
RTPC/RNIS et le NGN. Dans ce cas, tous les aspects de comptabilit sont affects.

Figure III.1/Y.2261 Scnarios d'volution pour le systme de facturation

Rec. UIT-T Y.2261 (09/2006)

27

BIBLIOGRAPHIE
[G.995.1]

28

Recommandation UIT-T G.995.1 (2001), Aperu gnral des Recommandations


relatives aux lignes d'abonn numrique.

Rec. UIT-T Y.2261 (09/2006)

SRIES DES RECOMMANDATIONS UIT-T


Srie A

Organisation du travail de l'UIT-T

Srie D

Principes gnraux de tarification

Srie E

Exploitation gnrale du rseau, service tlphonique, exploitation des services et facteurs


humains

Srie F

Services de tlcommunication non tlphoniques

Srie G

Systmes et supports de transmission, systmes et rseaux numriques

Srie H

Systmes audiovisuels et multimdias

Srie I

Rseau numrique intgration de services

Srie J

Rseaux cbls et transmission des signaux radiophoniques, tlvisuels et autres signaux


multimdias

Srie K

Protection contre les perturbations

Srie L

Construction, installation et protection des cbles et autres lments des installations extrieures

Srie M

Gestion des tlcommunications y compris le RGT et maintenance des rseaux

Srie N

Maintenance: circuits internationaux de transmission radiophonique et tlvisuelle

Srie O

Spcifications des appareils de mesure

Srie P

Qualit de transmission tlphonique, installations tlphoniques et rseaux locaux

Srie Q

Commutation et signalisation

Srie R

Transmission tlgraphique

Srie S

Equipements terminaux de tlgraphie

Srie T

Terminaux des services tlmatiques

Srie U

Commutation tlgraphique

Srie V

Communications de donnes sur le rseau tlphonique

Srie X

Rseaux de donnes, communication entre systmes ouverts et scurit

Srie Y

Infrastructure mondiale de l'information, protocole Internet et rseaux de prochaine


gnration

Srie Z

Langages et aspects gnraux logiciels des systmes de tlcommunication

Imprim en Suisse
Genve, 2007

Das könnte Ihnen auch gefallen