Architecture Du Sous-Système Multimédia IP: 2.1 Exigences Architecturales

Traduit de Anglais vers Français - www.onlinedoctranslator.
com
2
Architecture du sous-système
multimédia IP
Ce chapitre présente au lecteur le sous-système multimédia (IMS) du protocole Internet (IP). La

section 2.1 explique les concepts architecturaux de base : par exemple, nous expliquons
pourquoi les porteurs sont séparés et pourquoi le modèle de contrôle à domicile a été
sélectionné. La section 2.2 donne un large aperçu de l'architecture IMS, y compris une
introduction aux différentes entités de réseau et aux principales fonctionnalités. La section 2.3
va plus loin et montre comment les entités sont connectées et quels protocoles sont utilisés
entre elles ; il décrit également leurs relations avec d'autres domaines : réseaux IP, UMTS et CS
CN.
2.1 Exigences architecturales
Il existe un ensemble d'exigences de base qui guident la manière dont l'architecture IMS a
été créée et dont elle devrait évoluer à l'avenir. Cette section couvre les exigences les plus
importantes. Les exigences IMS de l'étape 1 du projet de partenariat de troisième
génération (3GPP) sont documentées dans [3GPP TS 22.228].
2.1.1 Connectivité IP
Une exigence fondamentale est qu'un client doit disposer d'une connectivité IP pour accéder
aux services IMS. De plus, il est nécessaire d'utiliser IPv6 [3GPP TS 23.221].
La connectivité IP peut être obtenue à partir du réseau domestique ou du réseau
visité. La partie la plus à gauche de la figure 2.1 présente une option dans laquelle
l'équipement utilisateur (UE) a obtenu une adresse IP d'un réseau visité. Dans le réseau
UMTS (Universal Mobile Telecommunications System), cela signifie que l'accès radio
12 Le SMI
SMI SMI
SMI SMI SMI

IP
connectivité
Autre réseau
Autre réseau
Réseau visité
Réseau visité
IP IP IP
connectivité connectivité connectivité
Trafic de signalisation
Signalisation et trafic du plan utilisateur
Trafic du plan utilisateur
Illustration 2.1Options de connectivité IMS lorsqu'un utilisateur est en itinérance.
(RAN), Serving GPRS Support Node (SGSN) et Gateway GPRS Support Node (GGSN) sont
situés dans le réseau visité lorsqu'un utilisateur est en itinérance dans le réseau visité. La
partie la plus à droite de la figure 2.1 présente une option dans laquelle un UE a obtenu
une adresse IP du réseau domestique. Dans le réseau UMTS, cela signifie que le RAN et le
SGSN sont situés dans le réseau visité lorsqu'un utilisateur est en itinérance dans le
réseau visité. Évidemment, lorsqu'un utilisateur se trouve dans le réseau domestique,
tous les éléments nécessaires se trouvent dans le réseau domestique et la connectivité IP
est obtenue dans ce réseau.
Il est important de noter qu'un utilisateur peut se déplacer et obtenir une connectivité IP à partir
du réseau domestique, comme indiqué sur la figure. Cela permettrait aux utilisateurs d'utiliser de
nouveaux services IMS sophistiqués même lorsqu'ils sont en itinérance dans une zone qui n'a pas de
réseau IMS mais fournit une connectivité IP. En théorie, il est possible de déployer un réseau IMS dans
une seule zone/pays et d'utiliser, par exemple, l'itinérance GPRS (General Packet Radio Service) pour
connecter les clients au réseau domestique. En pratique, cela ne se produirait pas car l'efficacité du
routage ne serait pas suffisamment élevée. Envisagez d'acheminer les paquets vocaux RTP (Real Time
Transport Protocol) des États-Unis vers l'Europe, puis de les renvoyer aux États-Unis. Cependant, ce
modèle de déploiement est important lorsque les opérateurs montent en puissance des réseaux IMS
ou, dans une première phase, lorsqu'ils proposent des services multimédias en temps non réel ou
quasi réel.
2.1.2 Indépendance d'accès
L'IMS est conçu pour être indépendant de l'accès afin que les services IMS puissent être fournis sur
n'importe quel réseau de connectivité IP (par exemple, GPRS, WLAN, accès à large bande x-Digital
Architecture du sous-système multimédia IP 13
Ligne d'abonné). Malheureusement, les spécifications IMS de la version 5 contiennent certaines

fonctionnalités spécifiques au GPRS. Dans la version 6 (par exemple, GPRS), les problèmes spécifiques
à l'accès seront séparés de la description du noyau IMS. Le 3GPP utilise le terme « réseau d'accès à
connectivité IP » pour désigner l'ensemble d'entités et d'interfaces de réseau qui fournit la
connectivité de transport IP sous-jacente entre l'UE et les entités IMS. Dans ce livre, nous utilisons le
GPRS comme exemple.
2.1.3 Garantir la qualité de service pour les services multimédia IP
Sur l'Internet public, les retards ont tendance à être élevés et variables, les paquets arrivent
dans le désordre et certains paquets sont perdus ou rejetés. Ce ne sera plus le cas avec l'IMS.
Les réseaux d'accès et de transport sous-jacents ainsi que l'IMS fournissent une qualité de
service (QoS) de bout en bout.
Via l'IMS, l'UE négocie ses capacités et exprime ses exigences QoS lors d'une
procédure d'établissement ou de modification de session SIP (Session Initiation Protocol).
L'UE est capable de négocier des paramètres tels que :
. Type de média, sens du trafic.
. Débit binaire du type de média, taille des paquets, fréquence de transport des paquets.
. Utilisation de la charge utile RTP pour les types de médias.
. Adaptation de la bande passante.
Après avoir négocié les paramètres au niveau de l'application, les UE réservent des ressources
appropriées à partir du réseau d'accès. Lorsque la qualité de service de bout en bout est créée, les UE
encodent et mettent en paquets des types de médias individuels avec un protocole approprié (par
exemple, RTP) et envoient ces paquets de médias au réseau d'accès et de transport en utilisant un
protocole de couche de transport (par exemple, TCP ou UDP ) sur IP. Il est supposé que les opérateurs
négocient des accords de niveau de service pour garantir la qualité de service requise dans la dorsale
d'interconnexion. Dans le cas de l'UTMS, les opérateurs pourraient utiliser la dorsale GPRS Roaming
Exchange.
2.1.4 Contrôle de la politique IP pour garantir une utilisation correcte des ressources multimédias
Le contrôle de la politique IP signifie la capacité d'autoriser et de contrôler l'utilisation du trafic

support destiné aux supports IMS, sur la base des paramètres de signalisation au niveau de la
session IMS. Cela nécessite une interaction entre le réseau d'accès à la connectivité IP et l'IMS.
Les moyens d'établissement d'interaction peuvent être divisés en trois catégories différentes
[3GPP TS 22.228, 23.207, 23.228] :
14 Le SMI
. L'élément de contrôle de politique est capable de vérifier que les valeurs négociées dans la signalisation SIP
sont utilisées lors de l'activation des supports pour le trafic multimédia. Cela permet à un opérateur de vérifier
que ses ressources de support ne sont pas utilisées à mauvais escient (par exemple, l'adresse IP source et de
destination et la bande passante au niveau du support sont exactement les mêmes que celles utilisées dans
l'établissement de session SIP).
. L'élément de contrôle de politique est capable d'appliquer le moment où le trafic multimédia entre les
points d'extrémité d'une session SIP démarre ou s'arrête. Cela permet d'empêcher l'utilisation du
support tant que l'établissement de la session n'est pas terminé et permet au trafic de démarrer/
s'arrêter en synchronisation avec le démarrage/l'arrêt de la taxation d'une session dans l'IMS.
. L'élément de contrôle de politique est capable de recevoir des notifications lorsque le

service de réseau d'accès à connectivité IP a modifié, suspendu ou libéré le ou les
supports d'un utilisateur associé à une session. Cela permet à IMS de libérer la
session en cours car, par exemple, l'utilisateur n'est plus dans la zone de couverture.
Le contrôle de la politique est décrit plus en détail au paragraphe 3.9.
2.1.5 Communication sécurisée
La sécurité est une exigence fondamentale dans tout système de télécommunication et l'IMS ne fait pas
exception. L'IMS fournit au moins un niveau de sécurité similaire à celui des réseaux GPRS et à commutation
de circuits correspondants : par exemple, l'IMS garantit que les utilisateurs sont authentifiés avant de pouvoir
commencer à utiliser les services, et les utilisateurs peuvent demander la confidentialité lorsqu'ils sont
engagés dans une session. La section 3.6 discutera des fonctionnalités de sécurité plus en détail.
2.1.6 Modalités de tarification
Du point de vue d'un opérateur ou d'un fournisseur de services, la possibilité de facturer les
utilisateurs est indispensable dans tout réseau. L'architecture IMS permet d'utiliser différents
modèles de charge. Cela comprend, par exemple, la capacité de facturer uniquement l'appelant
ou de facturer à la fois l'appelant et l'appelé sur la base des ressources utilisées au niveau du
transport. Dans ce dernier cas, l'appelant pourrait être facturé entièrement sur la session au
niveau IMS : c'est-à-dire qu'il est possible d'utiliser différents schémas de taxation au niveau du
transport et au niveau IMS. Cependant, un opérateur peut être intéressé par la corrélation des
informations de tarification générées aux niveaux de tarification du transport et de l'IMS
(service et contenu). Cette capacité est fournie si un opérateur utilise un point de référence de
contrôle de politique. Le mécanisme de corrélation de facturation est décrit plus en détail au
paragraphe 3.10.
Étant donné que les sessions IMS peuvent inclure plusieurs composants multimédias (par
exemple, audio et vidéo), il est nécessaire que l'IMS fournisse un moyen de facturation par
composant multimédia. Cela donnerait la possibilité de facturer l'appelé s'il ajoute un nouveau
composant multimédia dans une session. Il est également requis que différents réseaux IMS
puissent échanger des informations sur la tarification à appliquer à une session en cours [3GPP
TS 22.101, TR 23.815].
L'architecture IMS prend en charge les capacités de facturation en ligne et hors ligne. La
facturation en ligne est un processus de facturation dans lequel les informations de facturation
peuvent affecter en temps réel le service rendu et interagissent donc directement avec le contrôle de
session/service. En pratique, un opérateur pourrait vérifier le compte de l'utilisateur avant de
permettre à l'utilisateur d'engager une session et d'arrêter une session lorsque tous les crédits sont
consommés. Les services prépayés sont des applications qui nécessitent des capacités de recharge en
ligne. La facturation hors ligne est un processus de facturation dans lequel les informations de
facturation n'affectent pas en temps réel le service rendu. Il s'agit du modèle traditionnel dans lequel
les informations de facturation sont collectées sur une période donnée et, à la fin de la période,
l'opérateur envoie une facture au client.
2.1.7 Prise en charge de l'itinérance
Du point de vue de l'utilisateur, il est important d'avoir accès à ses services quelle que soit sa situation géographique. La fonctionnalité d'itinérance
permet d'utiliser des services même si l'utilisateur ne se trouve pas géographiquement dans la zone de service du réseau domestique. La section 2.1.1 a
déjà décrit deux cas d'itinérance : à savoir l'itinérance GPRS et l'itinérance IMS. En plus de ces deux, il existe un boîtier d'itinérance à commutation de
circuit IMS (CS). L'itinérance GPRS signifie la capacité d'accéder à l'IMS lorsque le réseau visité fournit le RAN et le SGSN et que le réseau domestique
fournit le GGSN et l'IMS. Le modèle d'itinérance IMS fait référence à une configuration de réseau dans laquelle le réseau visité fournit la connectivité IP
(par exemple, RAN, SGSN, GGSN) et le point d'entrée IMS (c'est-à-dire, P-CSCF) et le réseau domestique fournit le reste des fonctionnalités IMS. Le
principal avantage de ce modèle d'itinérance par rapport au modèle d'itinérance GPRS est l'utilisation optimale des ressources du plan utilisateur.
L'itinérance entre l'IMS et le domaine CS CN fait référence à l'itinérance interdomaine entre l'IMS et le CS. Lorsqu'un utilisateur n'est pas enregistré ou
accessible dans un domaine, une session peut être acheminée vers l'autre domaine. Il est important de noter que le domaine CS CN et le domaine IMS
ont leurs propres services et ne peuvent pas être utilisés à partir d'un autre domaine. Certains services sont similaires et disponibles dans les deux
domaines (par exemple, la voix sur IP dans l'IMS et la téléphonie vocale dans le CSCN). La figure 2.2 montre différents cas d'itinérance IMS/CS. Lorsqu'un
utilisateur n'est pas enregistré ou accessible dans un domaine, une session peut être acheminée vers l'autre domaine. Il est important de noter que le
domaine CS CN et le domaine IMS ont leurs propres services et ne peuvent pas être utilisés à partir d'un autre domaine. Certains services sont similaires
et disponibles dans les deux domaines (par exemple, la voix sur IP dans l'IMS et la téléphonie vocale dans le CSCN). La figure 2.2 montre différents cas
d'itinérance IMS/CS. Lorsqu'un utilisateur n'est pas enregistré ou accessible dans un domaine, une session peut être acheminée vers l'autre domaine. Il
est important de noter que le domaine CS CN et le domaine IMS ont leurs propres services et ne peuvent pas être utilisés à partir d'un autre domaine.
Certains services sont similaires et disponibles dans les deux domaines (par exemple, la voix sur IP dans l'IMS et la téléphonie vocale dans le CSCN). La
figure 2.2 montre différents cas d'itinérance IMS/CS.

16 Le SMI
Détaché dans le CS
Services IMS
CS SMI Mise en place de session

Configurer les appels Configurer les appels
Abonné dans le domaine

Prestations pour
CS. Gestion de la mobilité et
état non enregistré/non
joignable dans IMS
Services CS
SMI CS Configurer les appels
Mise en place de session Configurer les appels
Illustration 2.2Alternatives d'itinérance IMS/CS.
2.1.8 Interfonctionnement avec d'autres réseaux
Il est évident que l'IMS n'est pas déployé dans le monde entier en même temps. De plus, les gens
peuvent ne pas être en mesure de changer de terminal ou d'abonnement très rapidement. Cela
soulèvera la question de pouvoir joindre les gens quel que soit le type de terminaux dont ils disposent
ou leur lieu de résidence. Pour être une technologie et une architecture de réseau de communication
nouvelles et performantes, l'IMS doit pouvoir se connecter à autant d'utilisateurs que possible. Par
conséquent, l'IMS prend en charge la communication avec les utilisateurs PSTN, ISDN, mobiles et
Internet. De plus, il sera possible de prendre en charge des sessions avec des applications Internet qui
ont été développées en dehors de la communauté 3GPP [3GPP TS 22.228].
2.1.9 Modèle de contrôle des services
Dans les réseaux mobiles 2G, le contrôle du service visité est en cours d'utilisation. Cela signifie que,
lorsqu'un utilisateur est en itinérance, une entité du réseau visité fournit des services et contrôle le
trafic pour l'utilisateur. Cette entité en 2G est appelée centre de commutation de service mobile visité.
Au début de la version 5, les modèles de contrôle des visites et des services à domicile étaient pris en
charge. La prise en charge de deux modèles aurait exigé que chaque problème ait plus d'une
solution ; de plus, cela réduirait le nombre de solutions d'architecture optimales, car des solutions
simples peuvent ne pas convenir aux deux modèles. La prise en charge des deux modèles aurait
signifié des extensions supplémentaires pour Internet Engineering
des protocoles du groupe de travail (IETF) et a augmenté le travail impliqué dans les
flux d'enregistrement et de session. Le contrôle du service visité a été abandonné car
il s'agissait d'une solution complexe et n'apportait pas de plus-value notable par
rapport au contrôle du service à domicile. Au contraire, le contrôle du service visité
impose certaines limitations. Cela nécessite une relation multiple et des modèles
d'itinérance entre les opérateurs. Le développement des services est plus lent car le
réseau visité et le réseau domestique devraient prendre en charge des services
similaires, sinon les utilisateurs itinérants subiraient des dégradations de service. De
plus, le nombre de points de référence interopérateurs augmente, ce qui nécessite
des solutions compliquées (par exemple, en termes de sécurité et de tarification). Par
conséquent, le contrôle du service à domicile a été sélectionné ;
2.1.10 Développement des services
L'importance d'avoir une plate-forme de service évolutive et la possibilité de lancer rapidement de

nouveaux services signifient que l'ancienne méthode consistant à normaliser des ensembles complets
de téléservices, d'applications et de services supplémentaires n'est plus acceptable. Par conséquent, le
3GPP normalise les capacités de service et non les services eux-mêmes [3GPP TS 22.101].
L'architecture IMS devrait en fait inclure un cadre de service qui fournit les capacités nécessaires pour
prendre en charge la parole, la vidéo, le multimédia, la messagerie, le partage de fichiers, le transfert
de données, les jeux et les services complémentaires de base au sein de l'IMS. La section 3.12 décrit
plus en détail le fonctionnement du contrôle du service IMS et les chapitres 23 à 25 expliquent plus en
détail comment les services de présence, de messagerie et de conférence sont proposés.
2.1.11 Conception en couches
3GPP a décidé d'utiliser une approche en couches pour la conception architecturale. Cela signifie que
les services de transport et de support sont séparés du réseau de signalisation IMS et des services de
gestion de session. D'autres services sont exécutés au-dessus du réseau de signalisation IMS. La
figure 2.3 montre la conception.
Dans certains cas, il peut être impossible de faire la distinction entre les
fonctionnalités des couches supérieure et inférieure. L'approche en couches vise une
dépendance minimale entre les couches. Un avantage est qu'il facilite l'ajout ultérieur de
nouveaux réseaux d'accès au système. L'accès au réseau local sans fil (WLAN) à l'IMS, dans
la version 6 du 3GPP, testera la qualité de la superposition. D'autres accès peuvent suivre
(par exemple, haut débit fixe).
L'approche en couches augmente l'importance de la couche d'application. Lorsque les
applications sont isolées et que des fonctionnalités communes peuvent être fournies par le réseau
IMS sous-jacent, les mêmes applications peuvent s'exécuter sur l'UE en utilisant divers types d'accès.
18 Le SMI
Application
avion
COMME COMME COMME
BGCF
CSCF
Contrôle SEC Externe
SSS
avion IP
réseaux
MRFC MGCF SGW
MRFP
Utilisateur
RTPC/
Externe
avion CS
SGSN GGSN IM-MGW réseaux
COURU
Légende: Wi-Fi,
Trafic de signalisation uniquement
ADSL
Trafic utilisateur
câble, etc...
Les connexions de trafic utilisateur à AS ne
sont pas affichées
Figure 2.3IMS et architecture en couches.
2.2 Description des entités et fonctionnalités liées au SGI
Cette section traite des entités IMS et des fonctionnalités clés. Ces entités peuvent être
grossièrement classées en six grandes catégories : gestion de session et famille de routage
(CSCF), bases de données (HSS, SLF), éléments d'interfonctionnement (BGCF, MGCF, IM-MGW,
SGW), services (serveur d'application, MRFC, MRFP) , entités de support (THIG, SEG, PDF) et
facturation. Il est important de comprendre que les normes IMS sont établies de manière à ce
que la fonctionnalité interne des entités du réseau ne soit pas spécifiée en détail. Par exemple,
le serveur d'abonné domestique (HSS) contient trois fonctions internes : la fonctionnalité IMS,
les fonctions nécessaires pour le domaine CS et les fonctions nécessaires pour le domaine PS.
Les normes 3GPP ne décrivent pas comment la fonctionnalité IMS interagit avec les fonctions
conçues pour la commutation par paquets (PS) ; plutôt, ils décrivent les points de référence
entre les entités et les fonctionnalités prises en charge aux points de référence (par exemple,
comment le CSCF obtient-il les données utilisateur du HSS). Différents points de référence
seront décrits dans la section 2.3. De plus, les fonctions GPRS (General Packet Radio Service)
sont décrites à la fin de cette section.
2.2.1 Proxy-CSCF
La fonction de contrôle de session Proxy-Call (P-CSCF) est le premier point de contact pour les
utilisateurs au sein de l'IMS. Tout le trafic de signalisation SIP depuis ou vers l'UE passe par le P-
CSCF. Comme le nom de l'entité l'indique, le P-CSCF se comporte comme un mandataire tel que
défini dans la [RFC3261]. Cela signifie que le P-CSCF valide la demande, la transmet aux
destinations sélectionnées et traite et transmet la réponse. De plus, le P-CSCF peut se
comporter comme un agent utilisateur (UA) tel que défini dans la [RFC3261]. Le rôle UA est
nécessaire pour libérer des sessions dans des conditions anormales (par exemple, lorsqu'une
perte de support est détectée conformément à la politique locale basée sur le service - voir la
section 3.9) et pour générer des transactions SIP indépendantes, comme expliqué dans la
section 5.12.6, qui traite de inscription. Il peut y avoir un ou plusieurs P-CSCF dans le réseau
d'un opérateur. Les fonctions exécutées par le P-CSCF sont [3GPP TS 23.
. Pour transmettre les demandes SIP REGISTER au CSCF interrogateur (I-CSCF) sur la base
d'un nom de domaine de rattachement fourni par l'UE dans la demande. La section 5.5
donne une description détaillée des actions que la P-CSCF doit entreprendre avant de
transmettre la demande SIP REGISTER (par exemple, pour résoudre une adresse de la CSCF
ou pour faire savoir qu'une demande REGISTER n'a pas été reçue avec une association de
sécurité) .
. Transférer les requêtes SIP et les réponses reçues par l'UE au Serving-CSCF (S-CSCF). Le Chapitre
6 donne une description détaillée des actions que la P-CSCF doit entreprendre avant de
transmettre une demande ou une réponse non-REGISTER (par exemple, pour vérifier que
l'identité de l'utilisateur utilisée est valide).
. Pour transmettre les demandes et les réponses SIP à l'UE. Le chapitre 6 donne une description
détaillée des actions que la P-CSCF doit entreprendre avant de transmettre les messages SIP à
l'UE (par exemple, pour compresser le message).
. Pour détecter les demandes d'établissement de session d'urgence. Dans la version 5, le P-

CSCF renvoie un message d'erreur SIP, 380, indiquant que l'UE doit essayer le CSCN à la
place. Le travail est en cours dans la version 6 et le comportement de la P-CSCF va changer
de telle manière que la P-CSCF sélectionnera une S-CSCF pour gérer une session d'urgence.
La sélection est nécessaire car, dans les cas d'itinérance IMS, le S-CSCF attribué se trouve
dans le réseau domestique et le S-CSCF domestique est incapable d'acheminer la demande
vers un centre d'urgence correct.
. Pour envoyer des informations relatives à la comptabilité à la fonction de collecte de facturation

(CCF).
. Pour assurer la protection de l'intégrité de la signalisation SIP et maintenir une

association de sécurité entre l'UE et le P-CSCF. La protection de l'intégrité est assurée
au moyen d'Internet Protocol Security (IPsec) Encapsulating Security Payload (ESP).
20 Le SMI
La version 6 est également capable de fournir une protection de la confidentialité. La section 3.6
explique comment la sécurité IMS est conçue et les protocoles de sécurité sont abordés au
chapitre 18.
. Pour décompresser et compresser les messages SIP de l'UE. Le P-CSCF prend en

charge la compression basée sur trois RFC : [RFC3320], [RFC3485] et [RFC3486]. Les
sections 3.16 et 6.4 et le chapitre 19 décrivent l'utilisation de la compression SIP plus
en détail [3GPP TS 24.229].
. Pour souscrire un package d'événement d'enregistrement auprès du registraire de l'utilisateur (S-CSCF).

Cela est nécessaire pour télécharger les identités d'utilisateurs publics implicitement enregistrées et
pour obtenir des notifications sur les événements de désenregistrement initiés par le réseau. La section
5.12.6 décrit un paquet d'événements d'enregistrement et la section 3.14 montre comment fonctionne
l'enregistrement implicite et la section 5.14.3 nous en dit plus sur les désenregistrements initiés par le
réseau.
. Pour exécuter la police des médias. Le P-CSCF est capable de vérifier le contenu de la charge utile
du protocole de description de session (SDP) et de vérifier s'il contient des types de média ou des
codecs, qui ne sont pas autorisés pour un utilisateur. Lorsque le SDP proposé ne correspond pas
à la politique de l'opérateur, le P-CSCF rejette la demande et envoie un message d'erreur SIP,
488, à l'UE. Un opérateur peut souhaiter utiliser cette fonctionnalité pour les utilisateurs
itinérants en raison de restrictions de bande passante.
. Pour maintenir les minuteurs de session. La version 5 ne permet pas à un proxy avec état de
connaître l'état des sessions. La version 6 corrige cette lacune en introduisant des
temporisateurs de session. Il permet au P-CSCF de détecter et de libérer les ressources utilisées
par les sessions suspendues.
. Pour interagir avec la fonction de décision politique (PDF). Le PDF est responsable de la
mise en œuvre de la politique locale basée sur les services (SBLP). Dans la version 5, le PDF
est une entité logique du P-CSCF, et dans la version 6, le PDF est une fonction autonome.
2.2.2 Fonction de décision de politique
La fonction de décision de politique (PDF) est chargée de prendre des décisions politiques sur la base
des informations relatives à la session et aux médias obtenues à partir du P-CSCF. Il agit comme un
point de décision politique pour le contrôle SBLP. Les fonctionnalités de point de décision politique
suivantes pour SBLP sont identifiées :
. Pour stocker les informations relatives à la session et aux médias (adresses IP, numéros de port, bandes
passantes, etc.).
. Pour générer un jeton d'autorisation qui identifie le PDF et la session.
. Fournir une décision d'autorisation en fonction de la session stockée et des informations liées au
support lors de la réception d'une demande d'autorisation de support provenant du GGSN.
. Pour mettre à jour la décision d'autorisation lors des modifications de session qui modifient les
informations relatives à la session et aux médias.
. La possibilité de révoquer la décision d'autorisation à tout moment.
. La capacité de permettre l'utilisation d'un support autorisé (par exemple, le protocole Packet
Data Protocol, ou PDP, contexte).
. La capacité d'empêcher l'utilisation d'un support autorisé (par exemple, le contexte PDP)
tout en maintenant l'autorisation.
. Pour informer le P-CSCF lorsque le support (par exemple, le contexte PDP) est perdu ou modifié.
Une indication de modification n'est donnée que lorsque le support est mis à niveau ou déclassé
de ou vers 0 kbit/s.
. Pour transmettre un identifiant de facturation IMS au GGSN et pour transmettre un identifiant de

facturation GPRS au P-CSCF.
2.2.3 Interrogation-CSCF
Interrogating-CSCF (I-CSCF) est un point de contact au sein du réseau d'un opérateur pour
toutes les connexions destinées à un abonné de cet opérateur de réseau. Il peut y avoir
plusieurs I-CSCF au sein du réseau d'un opérateur. Les fonctions assurées par l'I-CSCF
sont :
. Pour contacter le HSS pour obtenir le nom du S-CSCF qui dessert un utilisateur.
. Attribuer un S-CSCF en fonction des capacités reçues du HSS. Une S-CSCF est
attribuée si aucune S-CSCF n'est attribuée. Cette procédure est décrite plus en détail
dans la section 3.8.
. Pour transmettre les demandes ou les réponses SIP au S-CSCF.
. Transmettre les informations relatives à la comptabilité au CCF.
. Pour fournir une fonctionnalité de masquage. L'I-CSCF peut contenir une fonctionnalité
appelée passerelle inter-réseaux de masquage de topologie (THIG). THIG pourrait être
utilisé pour masquer la configuration, la capacité et la topologie du réseau à l'extérieur du
réseau d'un opérateur.
22 Le SMI
2.2.4 Servir-CSCF
Le Serving-CSCF (S-CSCF) est le cerveau de l'IMS ; il est situé dans le réseau domestique. Il
exécute des services de contrôle de session et d'enregistrement pour les UE. Pendant que l'UE
est engagée dans une session, la S-CSCF maintient un état de session et interagit avec les
plates-formes de service et les fonctions de facturation selon les besoins de l'opérateur de
réseau pour la prise en charge des services. Il peut y avoir plusieurs S-CSCF, et les S-CSCF
peuvent avoir différentes fonctionnalités au sein du réseau d'un opérateur. Plus précisément,
les fonctions assurées par le S-CSCF sont :
. Gérer les demandes d'enregistrement en agissant en tant que bureau d'enregistrement tel que
défini dans la [RFC3261]. Le S-CSCF connaît l'adresse IP de l'UE et le P-CSCF que l'UE utilise
comme point d'entrée IMS.
. Pour authentifier les utilisateurs au moyen du schéma IMS Authentication and Key
Agreement (AKA). L'IMS AKA réalise une authentification mutuelle entre l'UE et le
réseau domestique.
. Pour télécharger des informations sur l'utilisateur et des données relatives au service à partir du HSS lors de
l'inscription ou lors du traitement d'une demande adressée à un utilisateur non enregistré.
. Pour acheminer le trafic se terminant par le mobile vers le P-CSCF et pour acheminer le
trafic provenant du mobile vers l'I-CSCF, la fonction de contrôle de la passerelle de
répartition (BGCF) ou le serveur d'application (AS).
. Pour effectuer le contrôle de session. Le S-CSCF peut agir comme un serveur proxy et UA comme
défini dans [RFC3261].
. Pour interagir avec les plateformes de services. L'interaction signifie la capacité de décider quand
une demande ou une réponse doit être acheminée vers un AS spécifique pour un traitement
ultérieur.
. Pour traduire un numéro E.164 en un identifiant de ressource universel (URI) SIP à l'aide
d'un mécanisme de traduction de système de noms de domaine (DNS) avec le format
spécifié dans [Draft-ietf-enum-rfc2916bis]. Cette traduction est nécessaire car le routage de
la signalisation SIP dans IMS utilise uniquement les URI SIP.
. Superviser les minuteurs d'enregistrement et être en mesure de désenregistrer les utilisateurs en cas de besoin.
. Pour sélectionner un centre d'urgence lorsque l'opérateur prend en charge les sessions d'urgence IMS.
Il s'agit d'une fonctionnalité de la version 6.
. Pour exécuter la police des médias. Le S-CSCF est capable de vérifier le contenu de la charge utile
SDP et de vérifier s'il contient des types de média ou des codecs, qui ne sont pas autorisés pour
un utilisateur. Lorsque le SDP proposé ne correspond pas à la politique de l'opérateur ou à
l'abonnement de l'utilisateur, le S-CSCF rejette la demande et envoie une erreur SIP
message, 488. La section 3.11 montre comment les informations sur la politique des médias peuvent être
incluses dans le profil de l'utilisateur.
. Pour maintenir les minuteurs de session. La version 5 ne permet pas à un proxy avec état de
connaître l'état des sessions. La version 6 corrige cette lacune en introduisant des
temporisateurs de session. Il permet au S-CSCF de détecter et de libérer les ressources utilisées
par les sessions suspendues.
. Pour envoyer des informations relatives à la comptabilité au CCF à des fins de facturation
hors ligne et au système de facturation en ligne (OCS) à des fins de facturation en ligne.
2.2.5 Serveur d'abonné domestique
Le serveur d'abonné domestique (HSS) est le principal stockage de données pour toutes les données relatives aux
abonnés et aux services de l'IMS. Les principales données stockées dans le HSS comprennent les identités des
utilisateurs, les informations d'enregistrement, les paramètres d'accès et les informations de déclenchement de
service [3GPP TS 23.002].
Les identités d'utilisateur se composent de deux types : les identités d'utilisateur privées et publiques.
L'identité d'utilisateur privée est une identité d'utilisateur attribuée par l'opérateur de réseau domestique et
utilisée à des fins telles que l'enregistrement et l'autorisation, tandis que l'identité d'utilisateur publique est
l'identité que d'autres utilisateurs peuvent utiliser pour demander une communication avec l'utilisateur final.
Les paramètres d'accès IMS sont utilisés pour configurer des sessions et incluent des paramètres tels que
l'authentification de l'utilisateur, l'autorisation d'itinérance et les noms S-CSCF attribués. Les informations de
déclenchement de service permettent l'exécution du service SIP. Le HSS fournit également des exigences
spécifiques à l'utilisateur pour les capacités S-CSCF. Cette information est utilisée par l'I-CSCF pour
sélectionner la S-CSCF la plus appropriée pour un utilisateur.
En plus des fonctions liées à la fonctionnalité IMS, le HSS contient le sous-ensemble
de la fonctionnalité de registre de localisation nominal et de centre d'authentification
(HLR/AUC) requise par le domaine PS et le domaine CS. La structure du HSS est illustrée à
la figure 2.4. La communication entre les différentes fonctions HSS n'est pas normalisée.
La fonctionnalité HLR est nécessaire pour assurer la prise en charge des entités du domaine PS, telles
que SGSN et GGSN. Cela permet aux abonnés d'accéder aux services du domaine PS. De la même manière, le
HLR prend en charge les entités de domaine CS telles que les serveurs MSC/MSC. Cela permet aux abonnés
d'accéder aux services du domaine CS et prend en charge l'itinérance vers les réseaux du domaine CS GSM/
UMTS.
L'AUC stocke une clé secrète pour chaque abonné mobile, qui est utilisée pour générer des
données de sécurité dynamiques pour chaque abonné mobile. Les données sont utilisées pour
l'authentification mutuelle de l'identité internationale de l'abonné mobile (IMSI) et du réseau.
Les données de sécurité sont également utilisées pour assurer la protection de l'intégrité et le
chiffrement de la communication sur le trajet radio entre l'UE et le réseau.
24 Le SMI
HLR/ASC Multimédia IP
fonctionnalité pour CS Fonctionnalité
HLR/ASC
fonctionnalité pour PS SSS
Graphique 2.4Structure du SHS.
Il peut y avoir plus d'un HSS dans un réseau domestique en fonction du nombre
d'abonnés mobiles, de la capacité des équipements et de l'organisation du réseau. Il
existe plusieurs points de référence entre le HSS et les autres entités du réseau.
2.2.6 Fonction Localisateur d'abonnement
La fonction de localisation d'abonnement (SLF) est utilisée comme mécanisme de

résolution qui permet à l'I-CSCF, au S-CSCF et à l'AS de trouver l'adresse du HSS qui
contient les données d'abonné pour une identité d'utilisateur donnée lorsque plusieurs
HSS adressables séparément ont été déployés par l'opérateur du réseau.
2.2.7 Contrôleur de fonction de ressource multimédia
Le contrôleur de fonction de ressource multimédia (MRFC) est nécessaire pour prendre en charge les
services liés au support, tels que la conférence, les annonces à un utilisateur ou le transcodage du
support. Le MRFC interprète la signalisation SIP reçue via S-CSCF et utilise les instructions du
protocole de contrôle de passerelle multimédia (MEGACO) pour contrôler le processeur de fonction de
ressource multimédia (MRFP). Le MRFC est en mesure d'envoyer des informations comptables au CCF
et à l'OCS. Le chapitre 25 montre comment le MRFC est utilisé dans les services de conférence.
2.2.8 Processeur de fonction de ressource multimédia
Le processeur de fonction de ressource multimédia (MRFP) fournit des ressources de

plan utilisateur qui sont demandées et instruites par le MRFC. Le MRFP remplit les
fonctions suivantes :
. Mélange de flux multimédias entrants (par exemple, pour plusieurs parties).
. Source de flux multimédia (pour les annonces multimédia).

. Traitement de flux multimédia (par exemple, transcodage audio, analyse multimédia) [3GPP TS
23.228, TS 23.002].
2.2.9 Serveur d'applications
En gardant à l'esprit la conception en couches, les serveurs d'applications (AS) ne sont pas de pures
entités IMS ; ce sont plutôt des fonctions au-dessus d'IMS. Cependant, les AS sont décrits ici comme
faisant partie des fonctions IMS parce que les AS sont des entités qui fournissent des services
multimédias à valeur ajoutée dans l'IMS.
Un AS réside dans le réseau domestique de l'utilisateur ou dans un emplacement tiers. Le
tiers désigne ici un réseau ou un AS autonome. Les fonctions principales de l'AS sont :
. La possibilité de traiter et d'impacter une session SIP entrante reçue de

l'IMS.
. La capacité d'émettre des requêtes SIP.
. La capacité d'envoyer des informations comptables au CCF et à l'OCS.
Les services offerts ne se limitent pas uniquement aux services basés sur SIP puisqu'un opérateur est
en mesure d'offrir l'accès à des services basés sur l'environnement de service (CSE) d'applications
personnalisées pour la logique améliorée du réseau mobile (CAMEL) et l'architecture de service
ouverte (OSA) pour son IMS abonnés [3GPP TS 23.228]. Par conséquent, '' AS '' est le terme utilisé de
manière générique pour capturer le comportement du SIP AS, du serveur de capacité de service OSA
(SCS) et de la fonction de commutation de service multimédia IP CAMEL (IM-SSF).
En utilisant l'OSA, un opérateur peut utiliser des fonctionnalités de capacité de service telles que
le contrôle des appels, l'interaction de l'utilisateur, le statut de l'utilisateur, le contrôle de la session de
données, les capacités du terminal, la gestion des comptes, la facturation et la gestion des politiques
pour développer des services [3GPP TS 29.198]. Un avantage supplémentaire du cadre OSA est qu'il
peut être utilisé comme un mécanisme normalisé pour fournir des AS tiers de manière sécurisée à
l'IMS, car l'OSA lui-même contient des fonctionnalités d'accès initial, d'authentification, d'autorisation,
d'enregistrement et de découverte (le S -CSCF ne fournit pas de fonctionnalité d'authentification et de
sécurité pour l'accès direct sécurisé de tiers à l'IMS). Etant donné que la prise en charge des services
OSA dépend du choix de l'opérateur, il n'est pas judicieux sur le plan architectural de prendre en
charge les protocoles et fonctionnalités OSA dans plusieurs entités. Donc, OSA SCS est utilisé pour
terminer la signalisation SIP du S-CSCF. Le SCS OSA utilise une interface de programme d'application
(API) OSA pour communiquer avec un serveur d'application OSA réel.
La fonction IM-SSF a été introduite dans l'architecture IMS pour prendre en charge les
services hérités qui sont développés dans l'environnement de service CAMEL (CSE). Il héberge
les fonctionnalités du réseau CAMEL (trigger detection points, CAMEL Service Switching
26 Le SMI
Service de chameau
OSA COMME
environnement
API OSA CASQUETTE
SIP COMME AOS SCS GI-SSF COMME
siroter siroter
S-CSCF
Graphique 2.5Relation entre différents types d'AS.
Finite State Machine, etc.) et interfonctionne avec l'interface CAMEL Application Part
(CAP).
Un SIP AS est un serveur basé sur SIP qui héberge une large gamme de services multimédias à
valeur ajoutée. Un SIP AS peut être utilisé pour fournir des services de présence, de messagerie et de
conférence. Les différentes fonctions des serveurs SIP sont décrites plus en détail dans les sections 8.3
et 3.12.4, dans le cadre de la fourniture de services.
La figure 2.5 montre comment différentes fonctions sont connectées. Du point de vue du
S-CSCF SIP AS, le serveur de capacité de service OSA et l'IM-SSF présentent le même
comportement de point de référence.
Un AS peut être dédié à un seul service et un utilisateur peut avoir plus d'un service, il peut
donc y avoir un ou plusieurs AS par abonné. De plus, il peut y avoir un ou plusieurs AS
impliqués dans une même session. Par exemple, un opérateur pourrait avoir un AS pour
contrôler le trafic d'arrivée vers un utilisateur en fonction des préférences de l'utilisateur (par
exemple, rediriger toutes les sessions multimédia entrantes vers un répondeur entre 17 h et 7
h) et un autre AS pour adapter le contenu des messages instantanés en fonction aux capacités
de l'UE (taille de l'écran, nombre de couleurs, etc.).
2.2.10 Fonction de contrôle de la passerelle de dérivation
La fonction de contrôle de la passerelle d'évasion (BGCF) est chargée de choisir où se

produit une évasion vers le domaine CS. Le résultat d'un processus de sélection peut être
soit une percée dans le même réseau où se trouve la BGCF, soit un autre réseau. Si
l'évasion se produit dans le même réseau, le BGCF sélectionne une fonction de contrôle
de passerelle multimédia (MGCF) pour gérer une session plus loin. Si l'évasion a lieu dans
un autre réseau, alors le BGCF transfère une session à un autre BGCF dans un réseau
sélectionné [3GPP TS 23.228]. Les règles de sélection réelles ne sont pas spécifiées. De
plus, la BGCF est en mesure de rapporter des informations sur les comptes au CCF et de
collecter des informations statistiques. L'interfonctionnement IMS et CS est décrit au
paragraphe 3.13.
2.2.11 Fonction de contrôle de la passerelle média
La fonction de contrôle de la passerelle multimédia (MGCF) est une passerelle qui permet la
communication entre les utilisateurs IMS et CS. Toute la signalisation de contrôle d'appel entrant des
utilisateurs CS est destinée au MGCF qui effectue la conversion de protocole entre le sous-système
utilisateur RNIS (ISUP) ou le contrôle d'appel indépendant du support (BICC) et les protocoles SIP et
transmet la session à IMS. De la même manière, toutes les sessions générées par IMS vers les
utilisateurs CS traversent MGCF. MGCF contrôle également les canaux multimédias dans l'entité de
plan utilisateur associée, la passerelle multimédia IMS CIMS-MGW. En outre, MGCF est en mesure de
communiquer des informations sur les comptes au CCF. L'interfonctionnement IMS et CS est décrit au
paragraphe 3.13.
2.2.12 Fonction de passerelle multimédia du sous-système multimédia IP
La passerelle multimédia IMS (IMS-MGW) fournit la liaison du plan utilisateur entre

les réseaux CS (PSTN, GSM) et l'IMS. Il termine les canaux porteurs du réseau CS et
les flux multimédias du réseau dorsal (par exemple, les flux RTP dans un réseau IP ou
les connexions AAL2/ATM dans un dorsal ATM), exécute la conversion entre ces
terminaisons et effectue le transcodage et le traitement du signal pour le plan
utilisateur si nécessaire. De plus, l'IMS-MGW est capable de fournir des tonalités et
des annonces aux utilisateurs CS. L'IMS-MGW est contrôlé par le MGCF.
2.2.13 Passerelle de signalisation
Une passerelle de signalisation (SGW) est utilisée pour interconnecter différents réseaux de
signalisation, tels que les réseaux de signalisation basés sur SCTP/IP et les réseaux de signalisation
SS7. Le SGW effectue la conversion de signalisation (dans les deux sens) au niveau du transport entre
le transport de signalisation basé sur le système de signalisation n° 7 (SS7) et le transport de
signalisation basé sur IP (c'est-à-dire entre Sigtran SCTP/IP et SS7 MTP). La SGW n'interprète pas les
messages de la couche application (par exemple, BICC, ISUP). Dans la Figure 2.6 ISUP est représenté,
mais BICC pourrait également être représenté.
2.2.14 Passerelle de sécurité
Pour protéger le trafic du plan de contrôle entre les domaines de sécurité, le trafic passera par
une passerelle de sécurité (SEG) avant d'entrer ou de sortir du domaine de sécurité. Le domaine
de sécurité fait référence à un réseau géré par une seule autorité administrative. En règle
générale, cela coïncide avec les frontières de l'opérateur. Le SEG est placé à la frontière de
28 Le SMI
siroter EST EN PLACE EST EN PLACE
TCP/ M3UA M3UA MTP3 MTP3

UDP
SCTP MTP2 MTP2 MTP2
IP IP IP L1 L1
MGCF SGW CS
Figure 2.6Conversion de signalisation dans le SGW.
le domaine de sécurité et il applique la politique de sécurité d'un domaine de sécurité envers les
autres SEG dans le domaine de sécurité de destination. L'opérateur de réseau peut avoir plus
d'un SEG dans son réseau afin d'éviter un point de défaillance unique ou pour des raisons de
performances. Le SEG peut être défini pour une interaction vers toutes les destinations de
domaine de sécurité accessibles ou il peut être défini pour seulement un sous-ensemble des
destinations accessibles [3GPP TS 33.203]. Le concept derrière un domaine de sécurité est décrit
plus en détail dans la section 3.6.3.
2.2.15 Entités de taxation
Les différentes entités de tarification et les points de référence correspondants seront décrits
séparément dans la section 3.10.
2.2.16 Entités GPRS
2.2.16.1 Nœud de support GPRS desservant
Le nœud de support GPRS de service (SGSN) relie le RAN au réseau central de paquets. Il
est chargé d'exécuter à la fois les fonctions de commande et de gestion du trafic pour le
domaine PS. La partie contrôle contient deux fonctions principales : la gestion de la
mobilité et la gestion des sessions. La gestion de la mobilité traite de l'emplacement et de
l'état de l'UE et authentifie à la fois l'abonné et l'UE. La partie contrôle de la gestion de
session traite du contrôle d'admission de connexion et de tout changement dans les
connexions de données existantes. Il supervise également les services et les ressources
du réseau 3G. La gestion du trafic est la partie de la gestion de session qui est exécutée.
Le SGSN agit comme une passerelle pour la tunnellisation des données utilisateur : en
d'autres termes, il relaie le trafic utilisateur entre l'UE et le GGSN. Dans le cadre de cette
fonction, le SGSN garantit également que les connexions reçoivent la QoS appropriée. En
outre,
2.2.16.2 Nœud de prise en charge de la passerelle GPRS
Le nœud de support GPRS de passerelle (GGSN) assure l'interfonctionnement avec des réseaux
de données par paquets externes. La fonction principale du GGSN est de connecter l'UE aux
réseaux de données externes, où résident les applications et les services basés sur IP. Le réseau
de données externe pourrait être l'IMS ou Internet, par exemple. En d'autres termes, le GGSN
achemine les paquets IP contenant la signalisation SIP de l'UE vers le P-CSCF et vice versa. De
plus, le GGSN prend en charge l'acheminement des paquets IP de média IMS vers le réseau de
destination (par exemple, vers le GGSN dans le réseau de destination). Le service
d'interfonctionnement fourni est réalisé sous forme de points d'accès qui se rapportent aux
différents réseaux que l'abonné souhaite connecter. Dans la plupart des cas, l'IMS a son propre
point d'accès. Lorsque l'UE active un support (contexte PDP) vers un point d'accès (IMS), le
GGSN alloue une adresse IP dynamique à l'UE. Cette adresse IP allouée est utilisée dans
l'enregistrement IMS et lorsque l'UE initie une session en tant qu'adresse de contact de l'UE. De
plus, le GGSN contrôle et supervise l'utilisation du contexte PDP pour le trafic multimédia IMS et
génère des informations de facturation.
2.3 Points de référence IMS
Cette section explique comment les entités de réseau décrites précédemment sont connectées les
unes aux autres et quel protocole est utilisé ; de plus, l'architecture IMS est représentée (Figure 2.7).
Vous trouverez également un aperçu des points de référence basés sur SIP (c'est-à-dire, où SIP est
utilisé et quelles sont les principales procédures). Cependant, vous vous rendrez compte que le niveau
de description des points de référence basés sur SIP n'est pas aussi profond que celui des points de
référence basés sur Diameter. La raison de cette division est que plusieurs chapitres de ce livre sont
consacrés aux procédures SIP et SDP où ces descriptions sont données en détail.
Par souci de clarté, il est impossible de tout inclure dans un seul chiffre ; alors,
veuillez noter ce qui suit :
. La figure 2.7 ne montre pas les fonctions ou les points de référence liés à la tarification (voir la
section 3.10 pour plus de détails).
. La figure ne montre pas les différents types d'AS (voir la section 2.2.9 pour plus de
détails).
. La figure ne montre pas les connexions du plan utilisateur entre les différents
réseaux IMS et l'AS.
. La figure ne montre pas le SEG aux points de référence Mm, Mk, Mw.
. La ligne pointillée entre les entités indique un lien direct.

30 Le SMI
Dh
IP coaccès à la nnectivité m réseau

Utah
Ch, Si
COMME SSS SLLF
SAI
Cx DX
jeje--CSCF
Mm
IPm
IP
Mw
je suiseeddentre autresentre autres
GM
mtutuçajejetm
réseaux
réseaux
UE P--SCC F S--SCC F MRFC
M Mw
Gq mg Mi OtthheerrjeSMI nne
Aller Mj Mk etdeuxoorrkkss
GGSN PDF MGCF BGCF

Député Mo
SGSN Mn
Mo SGW
COURU
jeJE SUIS--MGW
Mo CSdDoommunundansdans
MRFP
Figure 2.7Architecture IMS.
. ISC, Cx, Dx, Mm, Mw se terminent à la fois au Serving-CSCF (S-CSCF) et au I-

CSCF.
2.3.1 Point de référence Gm
Le point de référence Gm connecte l'UE à l'IMS. Il est utilisé pour transporter tous les messages
de signalisation SIP entre l'UE et l'IMS. L'homologue IMS est P-CSCF. Les procédures du point de
référence Gm peuvent être divisées en trois catégories principales : enregistrement, contrôle de
session et transactions :
. Dans la procédure d'enregistrement, l'UE utilise le point de référence Gm pour envoyer une
demande d'enregistrement avec une indication des mécanismes de sécurité pris en charge au P-
CSCF. Pendant le processus d'enregistrement, l'UE échange les paramètres nécessaires pour
s'authentifier lui-même et le réseau, obtient des identités d'utilisateur enregistrées implicites,
négocie les paramètres nécessaires pour une association de sécurité avec le P-CSCF et démarre
éventuellement la compression SIP. De plus, le point de référence Gm est utilisé pour informer
l'UE si un désenregistrement initié par le réseau ou une réauthentification initiée par le réseau se
produit.
. Les procédures de contrôle de session contiennent des mécanismes à la fois pour les sessions lancées
par le mobile et pour les sessions terminées par le mobile. Dans les sessions d'origine mobile, le point
de référence Gm est utilisé pour transmettre les demandes de l'UE au P-CSCF. Dans
Pour les sessions terminées par un mobile, le point de référence Gm est utilisé pour transmettre
la demande du P-CSCF à l'UE.
. Les procédures de transaction sont utilisées pour envoyer des demandes autonomes (par exemple,
MESSAGE) et pour recevoir toutes les réponses (par exemple, 200 OK) à cette demande via le point de
référence Gm. La différence entre les procédures de transaction et les procédures de contrôle de
session est qu'un dialogue n'est pas créé.
2.3.2 Point de référence Mw
Le point de référence Gm relie l'UE à l'IMS (c'est-à-dire à P-CSCF). Ensuite, un point de référence
basé sur SIP entre différents CSCF est nécessaire. Ce point de référence est appelé Mw. Les
procédures du point de référence Mw peuvent être divisées en trois catégories principales :
enregistrement, contrôle de session et transaction :
. Dans la procédure d'enregistrement, la P-CSCF utilise le point de référence Mw pour

transmettre une demande d'enregistrement de l'UE à l'I-CSCF. L'I-CSCF utilise ensuite
le point de référence Mw pour transmettre la demande au S-CSCF. Enfin, la réponse
du S-CSCF revient par le point de référence Mw. En outre, le S-CSCF utilise le point de
référence Mw dans les procédures de désenregistrement initiées par le réseau pour
informer l'UE du désenregistrement initié par le réseau et de la réauthentification
initiée par le réseau afin d'informer le P-CSCF qu'il doit libérer des ressources
concernant un objet particulier. utilisateur.
. Les procédures de contrôle de session contiennent des mécanismes à la fois pour les sessions
lancées par le mobile et pour les sessions terminées par le mobile. Dans les sessions d'origine
mobile, le point de référence Mw est utilisé pour transmettre les demandes à la fois de la P-CSCF
à la S-CSCF et de la S-CSCF à l'I-CSCF. Dans les sessions terminées par un mobile, le point de
référence Mw est utilisé pour transmettre des demandes à la fois de l'I-CSCF à la S-CSCF et de la
S-CSCF à la P-CSCF. Ce point de référence est également utilisé pour les libérations de session
initiées par le réseau : par exemple, le P-CSCF pourrait initier une libération de session vers le S-
CSCF s'il reçoit une indication du PDF indiquant que le ou les supports multimédias sont perdus.
De plus, les informations relatives à la taxation sont transmises via le point de référence Mw.
. Les procédures de transaction sont utilisées pour transmettre une demande autonome (par exemple,
MESSAGE) et pour recevoir toutes les réponses (par exemple, 200 OK) à cette demande via le point de
référence Mw. Comme déjà indiqué, la différence entre les procédures de transaction et les procédures
de contrôle de session est qu'un dialogue n'est pas créé.
32 Le SMI
2.3.3 Point de référence du contrôle du service IMS
Dans l'architecture IMS, les AS sont des entités qui hébergent et exécutent des services, tels que
la présence, la messagerie et le transfert de session. Par conséquent, il doit y avoir un point de
référence pour envoyer et recevoir des messages SIP entre le CSCF et un AS. Ce point de
référence est appelé point de référence IMS Service Control (ISC) et le protocole sélectionné est
SIP. Les procédures ISC peuvent être divisées en deux catégories principales : le routage de la
requête SIP initiale vers un AS et les requêtes SIP initiées par l'AS :
. Lorsque le S-CSCF reçoit une requête SIP initiale, il l'analyse. Sur la base de l'analyse,
la S-CSCF peut décider d'acheminer la demande vers un AS pour un traitement
ultérieur. L'AS peut terminer, rediriger ou mandater la demande provenant de la S-
CSCF.
. Un AS peut initier une demande (par exemple, au nom d'un utilisateur).
. Le concept de contrôle de service est décrit en détail dans la section 3.12.
2.3.4 Point de référence Cx
Les données d'abonné et de service sont stockées de manière permanente dans le HSS. Ces données
centralisées doivent être utilisées par l'I-CSCF et la S-CSCF lorsque l'utilisateur s'enregistre ou reçoit
des sessions. Il doit donc y avoir un point de référence entre le SSS et le CSCF. Ce point de référence
est appelé le point de référence Cx et le protocole sélectionné est Diameter. Les procédures peuvent
être divisées en trois catégories principales : la gestion de l'emplacement, le traitement des données
des utilisateurs et l'authentification des utilisateurs. Généralement, les descriptions ne couvrent que
les cas réussis - ceux qui échouent ne sont pas couverts ici. L'élément d'information de résultat
pourrait être utilisé pour transporter des informations sur la raison pour laquelle une demande
échoue. Si une erreur se produit, un message de réponse ne contiendra aucun autre élément
d'information dans la plupart des cas.
2.3.4.1 Procédures de gestion de localisation
Les procédures de gestion de l'emplacement peuvent être subdivisées en deux groupes : enregistrement et
désenregistrement, et récupération de l'emplacement.
Procédures d'inscription et de désinscription entre I-CSCF et HSS
Lorsque l'I-CSCF reçoit une demande SIP REGISTER du P-CSCF via le point de référence Mw, il
invoque une requête d'état d'enregistrement de l'utilisateur ou, comme cela est connu dans les
normes, une commande User-Authorization-Request (UAR). Cette commande contient :
. Identité d'utilisateur privée : l'identité permettant d'identifier de manière unique l'utilisateur du point de
vue du réseau. Il identifie l'abonnement et corrige les données d'authentification (voir la section 3.4.1.1
pour plus de détails sur l'identité de l'utilisateur privé).
. Identité de l'utilisateur public — l'identité à enregistrer (voir Section 3.4.1.2 pour plus de détails
sur l'identité de l'utilisateur public).
. Identificateur de réseau visité—identifie le réseau IMS visité dans le cas de l'itinérance IMS. Sur la
base de cet identifiant, le HSS est en mesure d'appliquer des restrictions d'itinérance.
. Informations de routage : contient l'adresse du HSS si l'I-CSCF en a connaissance. Si

l'I-CSCF ne connaît pas l'adresse du HSS, il contient alors le domaine de destination
(c'est-à-dire que le SLF est utilisé pour résoudre un HSS correct).
. Type d'autorisation—trois valeurs possibles pour le type d'élément d'information

d'autorisation sont définies :
e REGISTRATION—il est inclus lorsque la valeur d'expiration dans la demande

REGISTER n'est pas égale à zéro.
e REGISTRATION_CAPABILITIES - il est inclus lorsque la valeur d'expiration dans la

demande REGISTER n'est pas égale à zéro et que l'I-CSCF interroge explicitement les
capacités S-CSCF (par exemple, lorsqu'un S-CSCF précédemment donné ne répond
pas).
e DE-REGISTRATION—il est inclus lorsque la valeur d'expiration dans la

demande REGISTER est égale à zéro.
Après avoir reçu la commande UAR, le HSS envoie une commande User-
Authorization-Answer (UAA). Il contient:
. Résultat — informe du résultat de la commande UAR.
. Nom S-CSCF et/ou capacités S-CSCF (si la commande UAR n'échoue pas en raison, par
exemple, des identités privées et publiques reçues dans la demande n'appartenant pas au
même utilisateur) en fonction de l'état d'enregistrement actuel de l'utilisateur.
Les capacités S-CSCF sont renvoyées si l'utilisateur n'a pas encore de nom S-CSCF attribué
dans le HSS ou si l'I-CSCF demande explicitement des capacités S-CSCF. Sinon, le nom S-
CSCF est renvoyé. Lorsque les capacités sont renvoyées, l'I-CSCF doit effectuer la sélection
de S-CSCF comme décrit au paragraphe 3.8.
Procédures d'enregistrement et de désenregistrement entre S-CSCF et HSS
Nous avons expliqué ci-dessus comment I-CSCF trouve un S-CSCF qui servira à l'utilisateur.
Ceci fait, l'I-CSCF transmet une demande SIP REGISTER à la S-CSCF. Quand le
34 Le SMI
S-CSCF reçoit la demande SIP REGISTER de l'I-CSCF, il utilise une commande Server-
Assignment-Request (SAR) pour communiquer avec le HSS. La commande SAR est utilisée
pour informer le HSS du S-CSCF qui servira l'utilisateur lorsque la valeur d'expiration n'est
pas égale à zéro. De même, si la valeur d'expiration est égale à zéro, alors la commande
SAR est utilisée pour informer que le S-CSCF ne dessert plus un utilisateur. Une condition
préalable à l'envoi de la commande SAR est que l'utilisateur a été authentifié avec succès
par le S-CSCF. La commande SAR contient :
. Identité de l'utilisateur privé—voir la commande UAR.
. Identité de l'utilisateur public—l'identité à enregistrer/désenregistrer (voir Section

3.4.1.2 pour plus de détails sur l'identité de l'utilisateur public).
. Informations de routage — contient l'adresse du HSS si le S-CSCF en a

connaissance. Si le S-CSCF ne connaît pas l'adresse du HSS, alors il contient le
domaine de destination.
. Nom S-CSCF : contient l'URI SIP du S-CSCF.
. Type d'affectation de serveur : le type d'affectation de serveur contient des informations sur la raison pour
laquelle cette opération est exécutée (par exemple, en raison d'un enregistrement, d'un réenregistrement,
d'une session avec un utilisateur non enregistré, d'un désenregistrement initié par l'utilisateur ou initié par S-
CSCF et d'un échec d'authentification).
. Données utilisateur déjà disponibles : indique au HSS si oui ou non le S-CSCF possède
déjà la partie du profil utilisateur dont il a besoin pour servir l'utilisateur.
. Type de demande de données utilisateur : indique si le S-CSCF souhaite télécharger un

profil complet, enregistré ou non enregistré.
Après avoir reçu la commande SAR, le HSS répondra par une commande Server-
Assignment-Answer (SAA). Il contient:
. Résultat — informe du résultat de la commande SAR.
. Profil utilisateur—basé sur les valeurs définies de Type d'attribution de serveur et Données
utilisateur déjà disponibles dans la commande SAR, le profil utilisateur est envoyé (le profil
utilisateur est expliqué à la section 3.11).
. Informations de charge—contient les adresses des fonctions de charge. Il s'agit d'un

élément d'information facultatif.
Les sections précédentes ont décrit comment les procédures d'enregistrement et de désenregistrement
initiées par l'utilisateur (initiées par l'utilisateur ou initiées par S-CSCF) sont traitées sur le point de référence
Cx. Des opérations supplémentaires sont toujours nécessaires pour provoquer le désenregistrement initié
par le réseau (par exemple, en raison d'un UE volé ou lorsqu'un abonnement est résilié). Dans ce cas, c'est le
HSS qui démarre le désenregistrement initié par le réseau en utilisant un
commande appelée Registration-Termination-Request (RTR). La commande RTR

contient :
vue du réseau. Il identifie l'abonnement et les données d'authentification correctes (voir la section
3.4.1.1 pour plus de détails sur l'identité de l'utilisateur privé).
. Identité de l'utilisateur public—une ou plusieurs identités à désenregistrer (voir Section

3.4.1.2 pour plus de détails sur l'identité de l'utilisateur public).
. Informations de routage : contient le nom du S-CSCF qui dessert l'utilisateur.
. Raison du désenregistrement — contient un code de raison qui détermine le comportement de

S-CSCF et inclut éventuellement un message textuel à afficher à l'utilisateur.
La commande RTR est acquittée par une commande Enregistrement-Termination-Réponse (RTA), qui
indique simplement le résultat de l'opération. Notez qu'il est possible de désenregistrer l'identité de
l'utilisateur public en une seule fois en envoyant uniquement l'identité de l'utilisateur privé.
Procédures de récupération de position
Précédemment, nous avons décrit comment l'I-CSCF utilise une requête d'état d'enregistrement
d'utilisateur (commande UAR) pour trouver le S-CSCF lorsqu'il reçoit une demande SIP
REGISTER. En conséquence, il doit y avoir une procédure pour trouver le S-CSCF lorsqu'une
méthode SIP est différente de REGISTER. La procédure requise consiste à utiliser une
commande Location-Info-Request (LIR). Cette demande contient :
. Identité de l'utilisateur public : contient l'identité du champ URI de demande d'une

méthode SIP.
. Informations de routage : contient l'adresse du HSS si l'I-CSCF en a connaissance.

Si l'I-CSCF ne connaît pas l'adresse du HSS, alors il contient le domaine de
destination.
Le HSS répond par une commande Location-Info-Answer (LIA). La réponse

contient :
. Résultat : informe du résultat de la commande LIR.
. Le nom S-CSCF ou les capacités S-CSCF - ces dernières sont renvoyées si

l'utilisateur n'a pas le nom S-CSCF attribué, sinon l'URI SIP du S-CSCF est
renvoyé.
36 Le SMI
2.3.4.2 Procédures de traitement des données utilisateur
Pendant le processus d'enregistrement, les données relatives à l'utilisateur et au service seront

téléchargées du HSS vers le S-CSCF via le point de référence Cx à l'aide des commandes SAR et
SAA comme décrit précédemment. Cependant, il est possible que ces données soient modifiées
ultérieurement lorsque le S-CSCF sert encore un utilisateur. Pour mettre à jour les données
dans le S-CSCF, le HSS lance une commande Push-Profile-Request (PPR). Cette demande
contient :
. Identité de l'utilisateur privé — l'identité permettant d'identifier de manière unique l'utilisateur du point
de vue du réseau (voir la section 3.4.1.1 pour plus de détails sur l'identité de l'utilisateur privé).
. Informations de routage : contient le nom du S-CSCF qui dessert l'utilisateur.
. Données utilisateur—contient le profil utilisateur mis à jour (le profil utilisateur est expliqué dans la
section 3.11).
La mise à jour a lieu immédiatement après le changement à une exception près : lorsque le S-
CSCF sert un utilisateur non enregistré ou que le S-CSCF est conservé pour un utilisateur non
enregistré comme décrit dans la section 3.8.5 et qu'il y a un changement dans la partie
enregistrée de l'utilisateur profil, le HSS n'enverra pas de commande PPR. La commande PPR
est acquittée par une commande Push-Profile-Answer (PPA), qui indique simplement le résultat
de l'opération.
2.3.4.3 Procédures d'authentification
L'authentification des utilisateurs IMS repose sur un secret partagé préconfiguré. Les secrets
partagés et les numéros de séquence sont stockés dans le module d'identité des services
multimédia IP (ISIM) dans l'UE et dans le HSS du réseau. Étant donné que S-CSCF prend en
charge l'autorisation de l'utilisateur, il existe un besoin de transférer des données de sécurité
via le point de référence Cx. Lorsque le S-CSCF doit authentifier un utilisateur, il envoie une
commande MAR (Multimedia-Auth-Request) au HSS. Cette demande contient :
. Nom S-CSCF : contient l'URI SIP du S-CSCF.
. Informations de routage—contient l'adresse du HSS si l'I-CSCF est au courant

Tableau 2.1Commandes Cx.
Nom de commande But Source d'abréviation Destination
Utilisateur-autorisation-demande/réponse Les commandes User-Authorization-Request/Answer (UAR/ RAU I-CSCF SSS

UAA) sont utilisées entre l'I-CSCF et le HSS pendant
l'enregistrement SIP pour récupérer le nom S-CSCF ou les SAU SSS I-CSCF
capacités S-CSCF pour la sélection S-CSCF et pendant le
désenregistrement SIP pour récupérer S- Nom CSCF lorsque la
méthode SIP est REGISTER
Serveur-Affectation-Demande/Réponse Les commandes Server-Assignment-Request/Answer (SAR/SAA) DAS S-CSCF SSS

sont utilisées entre le S-CSCF et le HSS pour mettre à jour le nom
du S-CSCF sur le HSS et pour télécharger les données de profil ASA SSS X-CSCF
utilisateur sur le S-CSCF
Location-Info-Demande/Réponse Les commandes Location-Info-Request/Answer (LIR/LIA) LIR I-CSCF SSS

sont utilisées entre l'I-CSCF et le HSS pendant la
configuration de la session SIP pour obtenir le nom du S- LIA SSS I-CSCF
CSCF qui dessert l'utilisateur ou les capacités du S-CSCF
pour Sélection S-CSCF
Multimédia-Auth-Requête/Réponse Les commandes MAR/MAA (Multimedia-Auth-Request/Answer) MAR S-CSCF SSS

sont utilisées entre le S-CSCF et le HSS pour échanger des
informations afin de prendre en charge l'authentification entre MAA SSS S-CSCF
l'utilisateur final et le réseau IMS domestique.
Inscription-Résiliation-Demande/ Les commandes Registration-Termination-Request/Answer (RTR/ RTR SSS S-CSCF

Réponse RTA) sont utilisées entre le S-CSCF et le HSS lorsque le HSS
désenregistre administrativement une ou plusieurs des identités ATR S-CSCF SSS
publiques de l'utilisateur.
Push-Profile-Demande/Réponse Les commandes Push-Profile-Request/Answer (PPR/PPA) sont utilisées RPP SSS S-CSCF
entre le HSS et le S-CSCF lorsque les données du profil utilisateur sont
modifiées par une opération de gestion dans le HSS et que les données APP S-CSCF SSS
doivent être mises à jour dans le S-CSCF
38 Le SMI
de celui-ci. Si l'I-CSCF ne connaît pas l'adresse du HSS, alors il contient le

domaine de destination.
. Nombre d'éléments d'authentification : informations sur le nombre de vecteurs

d'authentification que le S-CSCF souhaite télécharger simultanément. Plusieurs vecteurs
d'authentification peuvent être téléchargés (par exemple, si un opérateur souhaite ré-
authentifier tous les ré-enregistrements).
. Données d'authentification—comprend le schéma d'authentification (par exemple, Digest-

AKAv1-MD5) et les informations d'authentification en cas d'échec de la synchronisation.
Le HSS répond par une commande Multimedia-Auth-Answer (MAA). La réponse

contient :
. Résultat — informe du résultat de la commande MAR.
. Nombre d'éléments d'authentification : contient les vecteurs d'authentification.
. Données d'authentification—comprend un vecteur d'authentification, qui comprend un

schéma d'authentification (par exemple, Digest-AKAv1-MD5), des informations
d'authentification (le défi d'authentification RAND et le jeton AUTN), des informations
d'autorisation (réponse attendue ou XRES), une clé d'intégrité et , éventuellement, une clé
de confidentialité. De plus, il contient un numéro d'élément, qui indique l'ordre dans lequel
les vecteurs d'authentification doivent être consommés lorsque plusieurs vecteurs sont
renvoyés.
2.3.5 Point de référence Dx
Lorsque plusieurs HSS adressables séparément ont été déployés dans un réseau, ni
l'I-CSCF ni la S-CSCF ne savent quel HSS ils doivent contacter. Cependant, ils doivent
d'abord contacter le SLF. A cet effet, le point de référence Dx a été introduit. Le point
de référence Dx est toujours utilisé conjointement avec le point de référence Cx. Le
protocole utilisé dans ce point de référence est basé sur DIAMETER. Sa fonctionnalité
est mise en œuvre au moyen du mécanisme de routage fourni par un agent de
redirection DIAMETER amélioré.
Pour obtenir une adresse HSS, l'I-CSCF ou le S-CSCF envoie au SLF le Cx
FSL
3. Rediriger vers
2. LIR
SSS #2
1. INVITER 6. INVITEZ
I-CSCF S-CSCF
4. RIL 5. LIA
SSS #1 SSS #2 SSS #3

Illustration 2.8Résolution HSS utilisant le SLF.
demandes destinées au SSS. A la réception de l'adresse HSS de la SLF, l'I-CSCF ou la S-

CSCF enverra les requêtes Cx au HSS. La figure 2.8 montre comment la SLF est
utilisée pour trouver un HSS correct lorsque l'I-CSCF reçoit une demande INVITE et
que trois HSS ont été déployés.
2.3.6 Point de référence Sh
Un AS (SIP AS ou OSA SCS) peut avoir besoin de données utilisateur ou avoir besoin de savoir à
quel S-CSCF envoyer une requête SIP. Ce type d'information est stocké dans le HSS. Par
conséquent, il doit y avoir un point de référence entre le HSS et l'AS. Ce point de référence est
appelé le point de référence Sh et le protocole est DIAMETER. Les procédures sont divisées en
deux grandes catégories : traitement des données et abonnement/notification. Le HSS tient à
jour une liste des AS autorisés à obtenir ou à stocker des données.
2.3.6.1 Traitement des données
Les procédures de traitement des données offrent la possibilité de récupérer les données des utilisateurs à
partir du HSS. Ces données utilisateur peuvent contenir des données liées au service (transparentes ou non),
des informations d'enregistrement, des identités, des critères de filtrage initiaux, le nom S-CSCF servant
l'utilisateur, les adresses des fonctions de facturation et même des informations de localisation des domaines
CS et PS. Les données transparentes sont comprises syntaxiquement mais pas sémantiquement par le HSS.
Ce sont des données qu'un AS peut stocker dans le HSS pour prendre en charge sa logique de service. Au
contraire, les données non transparentes sont comprises à la fois syntaxiquement et sémantiquement par le
HSS. L'AS utilise la commande User-Data-Request (UDR) pour demander des données. La demande contient :
. Identité de l'utilisateur — comprend l'identité de l'utilisateur public de l'utilisateur qui a besoin des données
(voir la section 3.4.1.2 pour plus de détails sur l'identité de l'utilisateur public).
40 Le SMI
. Identité AS—identifie l'AS demandeur. Ces informations sont utilisées pour

vérifier si l'AS est autorisé à extraire des données du HSS.
. Domaine demandé—indique le domaine d'accès pour lequel certaines données sont

demandées. Deux valeurs sont spécifiées : le domaine CS et le domaine PS.
. Données demandées—utilisées pour indiquer le type de données demandées. Les valeurs

suivantes sont définies :
e RepositoryData—contient les données transparentes stockées pour l'utilisateur.
e PublicIdentifiers : liste des identités publiques de l'utilisateur.
e IMSUserState—informations sur l'état actuel de l'utilisateur dans IMS,

défini comme REGISTERED, NOT_REGISTERED,
AUTHENTICATION_PENDING et REGISTERED_UNREG_SERVICES.
e S-CSCFName : nom du S-CSCF qui dessert l'utilisateur.
e InitialFilterCriteria - contient les informations de déclenchement pertinentes pour un

service qui a un impact sur l'AS demandeur (voir les sections 3.11.1.3 et 3.12 pour plus
d'informations).
e LocationInformation—consiste en des informations de localisation sur l'utilisateur dans le

domaine demandé (par exemple, l'identification globale de la cellule).
e UserState : informations sur l'état actuel de l'utilisateur dans le domaine

demandé.
e ChargingInformation—contient les adresses des fonctions de charge.
. Emplacement actuel : indique si le HSS doit effectuer une procédure de récupération de

l'emplacement.
. Indication de service—valeur unique au sein du réseau de l'opérateur pour identifier les données
transparentes.
. AS Name : l'identité utilisée avec d'autres valeurs pour identifier le bon

InitialFilterCriteria.
Le HSS répond avec la User-Data-Answer (UDA). La réponse contient :
. Le résultat informe du résultat de la commande UDR.
. Les données demandées.
L'AS peut mettre à jour les données transparentes dans le HSS à l'aide de la commande Profile-
Update-Request (PUR), qui contient :
. Identité de l'utilisateur—inclut l'identité publique de l'utilisateur qui a demandé les données (voir
la section 3.4.1.2 pour plus de détails sur l'identité de l'utilisateur public).
. Identité AS—identifie l'AS demandeur. Ces informations sont utilisées pour

vérifier si l'AS est autorisé à extraire des données du HSS.
. Données—contient les données à mettre à jour.
La commande PUR est acquittée par une commande Profile-Update-Answer (PUA),

qui indique simplement le résultat de l'opération.
2.3.6.2 Abonnement/Notification
Les procédures d'abonnement/notification permettent à l'AS d'obtenir une notification lorsque des données
particulières pour un utilisateur spécifique sont mises à jour dans le HSS. L'AS envoie une commande
Subscribe-Notifications-Request (SNR) pour recevoir une notification lorsque les données d'un utilisateur
indiquées dans la commande SNR sont modifiées dans le HSS :
. Identité de l'utilisateur—inclut l'identité publique de l'utilisateur qui demande la modification des

données.
. Données demandées—contient la référence aux données pour lesquelles des notifications de

changement sont requises. Les valeurs possibles sont affichées dans le cadre de la commande
UDR (RepositoryData, PublicIdentifiers, etc.).
. Type de demande d'abonnement : indique si l'AS souhaite effectuer une opération

d'abonnement (lance des notifications) ou de désabonnement (arrête les notifications).
. Indication de service—valeur unique au sein du réseau de l'opérateur pour identifier les données
transparentes qui nécessitent la modification des données.
. Identité du serveur d'applications — identifie l'AS demandeur. Ces informations sont

utilisées pour vérifier si l'AS est autorisé à extraire des données du HSS.
. Nom du serveur d'applications : identité utilisée avec d'autres valeurs pour identifier les
critères de filtrage initiaux corrects requis pour la modification des données.
Le HSS accuse réception de la demande d'abonnement par une commande Subscribe-

Notifications-Answer (SNA), qui indique simplement le résultat de l'opération.
Si l'AS a envoyé la commande SNR et demandé une notification avec le type de
demande d'abonnement, le HSS envoie une commande Push-Notification-Request (PNR) à
l'AS lorsque les données particulières ont changé. Il contient les informations suivantes :
42 Le SMI
. Identité de l'utilisateur—inclut une identité publique de l'utilisateur pour lequel les données ont été
modifiées ;
. Données demandées—contient les données modifiées.
La commande PNR est acquittée par une commande Push-Notification-Answer

(PNA), qui indique simplement le résultat de l'opération.
Tableau 2.2Commandes Sh.
Nom de commande But Abréviation Source Destination
Données d'utilisateur- Les commandes User-Data- UDR COMME SSS

Demande/Réponse Request/Answer (UDR/UDA) sont
utilisé pour fournir les données d'utilisateur UDA SSS COMME
d'un utilisateur particulier
Profil-Mise à jour- Les commandes Profile-Update- PUR COMME SSS

Demande/Réponse Request/Answer (PUR/PUA) sont
utilisé pour mettre à jour les données PUA SSS COMME
transparentes dans le HSS
S'abonner- Les commandes Subscribe-Notifications- SNR COMME SSS

Notifications- Request/Answer sont utilisées pour
Demande/Réponse souscrire/annuler un abonnement aux SNA SSS COMME
données de l'utilisateur pour lesquelles

des notifications de changement sont
requises
Notification push- Les commandes Push-Notification- PNR SSS COMME
Demande/Réponse Request/ Answer sont utilisées pour

envoyer les données modifiées à l'AS ANP COMME SSS
2.3.7 Point de référence Si
Lorsque l'AS est un CAMEL AS (IM-SSF), il utilise le point de référence Si pour

communiquer avec le HSS. Le point de référence Si est utilisé pour transporter les
informations d'abonnement CAMEL, y compris les déclencheurs, du HSS vers l'IM-SSF. Le
protocole utilisé est Mobile Application Part (MAP).
2.3.8 Point de référence Dh
Lorsque plusieurs HSS adressables séparément ont été déployés dans le réseau,
l'AS ne peut pas savoir quel HSS il doit contacter. Cependant, l'AS doit
contactez d'abord le SLF. À cette fin, le point de référence Dh a été introduit dans la
version 6. Dans la version 5, le HSS correct est découvert à l'aide de moyens propriétaires.
Le point de référence Dh est toujours utilisé conjointement avec le point de référence Sh.
Le protocole utilisé dans ce point de référence est basé sur DIAMETER. Sa fonctionnalité
est mise en œuvre au moyen du mécanisme de routage fourni par un agent de redirection
DIAMETER amélioré.
Pour obtenir une adresse HSS, l'AS envoie au SLF la requête Sh destinée au
HSS. Dès réception de l'adresse HSS de la SLF, l'AS enverra la requête Sh au HSS.
2.3.9 Point de référence mm
Pour communiquer avec d'autres réseaux IP multimédia, un point de référence entre

l'IMS et d'autres réseaux IP multimédia est nécessaire. Le point de référence Mm permet
à I-CSCF de recevoir une demande de session d'un autre serveur ou terminal SIP. De
même, le S-CSCF utilise le point de référence Mm pour transmettre les demandes
provenant de l'IMS UE à d'autres réseaux multimédias. Au moment de la rédaction,
aucune spécification détaillée du point de référence Mm n'a été fournie. Cependant, il est
très probable que le protocole soit SIP.
2.3.10 Point de référence Mg
Le point de référence Mg relie la fonction de bord CS, MGCF, à l'IMS (c'est-à-dire à l'I-CSCF). Ce
point de référence permet à MGCF de transmettre la signalisation de session entrante du
domaine CS à l'I-CSCF. Le protocole utilisé pour le point de référence Mg est SIP. MGCF est
responsable de la conversion de la signalisation ISUP entrante en SIP.
2.3.11 Point de référence Mi
Lorsque le S-CSCF découvre qu'une session doit être acheminée vers le domaine CS, il utilise le
point de référence Mi pour transmettre la session à BGCF. Le protocole utilisé pour le point de
référence Mi est SIP. Le § 3.13 contient d'autres détails sur l'interfonctionnement IMS–CS.
2.3.12 Point de référence Mj
Lorsque BGCF reçoit une signalisation de session via le point de référence Mi, il sélectionne le
domaine CS dans lequel l'évasion doit se produire. Si l'évasion se produit dans le même réseau,
il transmet la session à MGCF via le point de référence Mj. Le protocole utilisé
44 Le SMI
pour le point de référence Mj est SIP. Le § 3.13 contient d'autres détails sur
l'interfonctionnement IMS–CS.
2.3.13 Point de référence Mk
Lorsque BGCF reçoit une signalisation de session via le point de référence Mk, il
sélectionne le domaine CS dans lequel l'évasion doit se produire. Si l'évasion se produit
dans un autre réseau, il transmet la session à BGCF dans l'autre réseau via le point de
référence Mk. Le protocole utilisé pour le point de référence Mk est SIP. Le § 3.13 contient
d'autres détails sur l'interfonctionnement IMS–CS.
2.3.14 Point de référence Ut
Le point de référence Ut est le point de référence entre l'UE et l'AS. Il permet aux utilisateurs de
gérer et de configurer en toute sécurité leurs informations relatives aux services réseau
hébergées sur un AS. Les utilisateurs peuvent utiliser le point de référence Ut pour créer des
identités de service public (PSI), telles qu'une liste de ressources, et gérer les stratégies
d'autorisation utilisées par le service. Des exemples de services qui utilisent le point de
référence Ut sont la présence et la conférence. L'AS peut avoir besoin d'assurer la sécurité du
point de référence Ut.
HTTP est le protocole de données choisi pour le point de référence Ut. Tout
protocole choisi pour une application qui utilise le point de référence Ut doit être
basé sur HTTP. Ce point de référence est normalisé dans la version 6.
2.3.15 M. point de référence
Lorsque le S-CSCF a besoin d'activer des services liés au support, il transmet la signalisation SIP
au MRFC via le point de référence Mr. La fonctionnalité du point de référence Mr n'est pas
entièrement normalisée : par exemple, il n'est pas spécifié comment le S-CSCF informe le MRFC
de diffuser une annonce spécifique. Le protocole utilisé dans le point de référence Mr est SIP.
2.3.16 Point de référence MP
Lorsque le MRFC a besoin de contrôler des flux de média (par exemple, pour créer des connexions pour le
média de conférence ou pour arrêter le média dans le MRFP), il utilise le point de référence Mp. Ce
point de référence est entièrement conforme aux normes H.248. Cependant, les services IMS peuvent
nécessiter des extensions. Ce point de référence doit être normalisé dans la version 6.
2.3.17 Aller au point de référence
Il est dans l'intérêt des opérateurs de s'assurer que la qualité de service et les adresses de
source et de destination du trafic média IMS prévu correspondent aux valeurs négociées au
niveau IMS. Cela nécessite une communication entre l'IMS (plan de contrôle) et le réseau GPRS
(plan utilisateur). Le point de référence Go a été initialement défini à cet effet. Plus tard, la
corrélation de charge a été ajoutée en tant que fonctionnalité supplémentaire. Le protocole
utilisé est le protocole Common Open Policy Service (COPS). Les procédures Go peuvent être
divisées en deux catégories principales :
. Autorisation des médias - en ce qui concerne l'accès, le point d'application de la politique (PEP)
(par exemple, GGSN) utilise le point de référence Go pour demander si une activation de support
demandée peut être acceptée à partir du PDF qui agit comme un point de décision politique. Le
PEP utilise également le point de référence Go pour notifier au point de décision de politique les
modifications de support nécessaires et les libérations de support (par exemple, le contexte
PDP). En ce qui concerne l'IMS, le PDF utilise le point de référence Go pour indiquer explicitement
quand un support peut ou ne peut pas être utilisé ; il peut également demander au PEP d'initier
une libération de support. L'autorisation des médias est expliquée en détail dans le contexte du
SBLP à la section 3.9.
. Corrélation de facturation - via le point de référence Go, l'IMS est capable de transmettre un
identifiant de facturation IMS (ICID) au réseau GPRS (plan utilisateur). De manière similaire, le
réseau d'accès est capable de transmettre un identifiant de facturation GPRS à l'IMS. Avec cette
procédure, il est possible de fusionner ultérieurement les informations de facturation GPRS et
IMS dans un système de facturation. Ce concept est expliqué plus en détail à la section 3.10.
2.3.18 Point de référence Gq
Lorsqu'un PDF autonome est déployé, le point de référence Gq est utilisé pour transporter
les informations de configuration de la politique entre la fonction d'application et le PDF.
Le terme ''fonction d'application'' est utilisé car il est prévu qu'un PDF puisse autoriser un
trafic autre que le trafic IMS. Dans le cas de l'IMS, la P-CSCF joue le rôle d'une fonction
d'application. Ce point de référence est normalisé dans la version 6.
Le P-CSCF envoie des informations de politique au PDF sur chaque message SIP qui inclut une
charge utile SDP. Cela garantit que le PDF transmet les informations appropriées pour effectuer
l'autorisation de support pour tous les scénarios de configuration de session IMS possibles. Le
Tableau 2.3Résumé des points de référence.
Nom de la référence Entités impliquées But Protocole

indiquer
GM UE, P-CSCF Ce point de référence est utilisé pour échanger des messages entre l'UE et siroter
les CSCF
Mw P-CSCF, I-CSCF, S-CSCF Ce point de référence est utilisé pour échanger des messages entre les CSCF siroter
SAI S-CSCF, I-CSCF, COMME Ce point de référence est utilisé pour échanger des messages entre siroter
CSCF et AS
Cx I-CSCF, S-CSCF, HSS Ce point de référence est utilisé pour communiquer entre I- Diamètre
CSCF/S-CSCF et HSS
DX I-CSCF, S-CSCF, SLF Ce point de référence est utilisé par I-CSCF/S-CSCF pour trouver un HSS Diamètre
correct dans un environnement multi-HSS
Sh SIP AS, OSA SCS, HSS Ce point de référence est utilisé pour échanger des informations Diamètre
entre SIP AS/OSA SCS et HSS
Si GI-SSF, HSS Ce point de référence est utilisé pour échanger des informations CARTE
entre IM-SSF et HSS
Dh SIP AS, OSA, SCF, IM-SSF, Ce point de référence est utilisé par AS pour trouver un HSS correct dans un Diamètre
HSS environnement multi-HSS
Mm I-CSCF, S-CSCF, réseau IP Ce point de référence sera utilisé pour l'échange de messages Non spécifié
externe entre IMS et les réseaux IP externes
mg MGCF ! I-CSCF MGCF convertit la signalisation ISUP en signalisation SIP et transmet la siroter
signalisation SIP à I-CSCF
Mi S-CSCF ! BGCF Ce point de référence est utilisé pour échanger des messages siroter
entre S-CSCF et BGCF
Mj BGCF ! MGCF Ce point de référence est utilisé pour échanger des messages siroter
entre BGCF et MGCF dans le même réseau IMS
Mk BGCF ! BGCF Ce point de référence est utilisé pour échanger des messages entre siroter
BGCF dans différents réseaux IMS
M S-CSCF, MRFC Ce point de référence est utilisé pour échanger des messages siroter
entre S-CSCF et MRFC
Député MRFC, MRFP Ce point de référence est utilisé pour échanger des messages H.248
entre MRFC et MRFP
Mn MGCF, IM-MGW Ce point de référence permet de contrôler les ressources du plan utilisateur H.248
Utah UE, AS (SIP AS, OSA SCS, IM- Ce point de référence permet à l'UE de gérer les informations relatives à ses HTTP
SSF) services
Aller PDF, GGSN Ce point de référence permet aux opérateurs de contrôler la QoS dans un plan COPS
utilisateur et d'échanger des informations de corrélation de facturation entre le
réseau IMS et GPRS
Gq P-CSCF, PDF Ce point de référence est utilisé pour échanger des informations relatives Diamètre
aux décisions politiques entre P-CSCF et PDF
48 Le SMI
Le concept d'autorisation des médias est expliqué en détail dans la section 3.9. Le P-CSCF
fournit les informations suivantes au PDF pour chaque composant multimédia [3GPP TS
29.207] :
. Adresse IP de destination et numéro de port de destination.
. ID du protocole de transport (par exemple, RTP).
. Informations sur la direction du support (envoyer, recevoir, envoyer et recevoir).
. Direction de la source (côté origine ou arrivée).
. Indication du groupe auquel appartient le composant multimédia.
. Informations de type média (audio, vidéo, etc.).
. Paramètres de bande passante.
. Indication de bifurcation/non-bifurcation.
De plus, le P-CSCF transmet un ICID au PDF lorsque l'ICID est reçu dans la
signalisation SIP ou généré dans le P-CSCF.
De même, le PDF envoie un jeton d'autorisation et un identifiant de facturation
GPRS (GCID) au P-CSCF. La section 3.9 explique plus en détail quand un jeton
d'autorisation est généré et quand le PDF reçoit le GCID du GGSN.
Au moment de la rédaction, la normalisation du point de référence Gq était en cours et, par
conséquent, il est sujet à d'autres modifications.

Architecture Du Sous-Système Multimédia IP: 2.1 Exigences Architecturales

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Architecture Du Sous-Système Multimédia IP: 2.1 Exigences Architecturales

Transféré par

Droits d'auteur :

Formats disponibles

Traduit de Anglais vers Français - www.onlinedoctranslator.

Ce chapitre présente au lecteur le sous-système multimédia (IMS) du protocole Internet (IP). La

2.1 Exigences architecturales

SMI SMI SMI

Signalisation et trafic du plan utilisateur

Trafic du plan utilisateur

Illustration 2.1Options de connectivité IMS lorsqu'un utilisateur est en itinérance.

2.1.2 Indépendance d'accès

Ligne d'abonné). Malheureusement, les spécifications IMS de la version 5 contiennent certaines

2.1.3 Garantir la qualité de service pour les services multimédia IP

. Type de média, sens du trafic.

. Utilisation de la charge utile RTP pour les types de médias.

. Adaptation de la bande passante.

Le contrôle de la politique IP signifie la capacité d'autoriser et de contrôler l'utilisation du trafic

. L'élément de contrôle de politique est capable de recevoir des notifications lorsque le

Le contrôle de la politique est décrit plus en détail au paragraphe 3.9.

2.1.5 Communication sécurisée

2.1.6 Modalités de tarification

2.1.7 Prise en charge de l'itinérance

figure 2.2 montre différents cas d'itinérance IMS/CS.

CS SMI Mise en place de session

Abonné dans le domaine

SMI CS Configurer les appels

Mise en place de session Configurer les appels

Illustration 2.2Alternatives d'itinérance IMS/CS.

2.1.8 Interfonctionnement avec d'autres réseaux

2.1.9 Modèle de contrôle des services

2.1.10 Développement des services

L'importance d'avoir une plate-forme de service évolutive et la possibilité de lancer rapidement de

2.1.11 Conception en couches

Figure 2.3IMS et architecture en couches.

2.2 Description des entités et fonctionnalités liées au SGI

. Pour détecter les demandes d'établissement de session d'urgence. Dans la version 5, le P-

. Pour envoyer des informations relatives à la comptabilité à la fonction de collecte de facturation

. Pour assurer la protection de l'intégrité de la signalisation SIP et maintenir une

. Pour décompresser et compresser les messages SIP de l'UE. Le P-CSCF prend en

. Pour souscrire un package d'événement d'enregistrement auprès du registraire de l'utilisateur (S-CSCF).

2.2.2 Fonction de décision de politique

. Pour générer un jeton d'autorisation qui identifie le PDF et la session.

. La possibilité de révoquer la décision d'autorisation à tout moment.

. Pour transmettre un identifiant de facturation IMS au GGSN et pour transmettre un identifiant de

. Pour transmettre les demandes ou les réponses SIP au S-CSCF.

. Transmettre les informations relatives à la comptabilité au CCF.

2.2.5 Serveur d'abonné domestique

Graphique 2.4Structure du SHS.

2.2.6 Fonction Localisateur d'abonnement

La fonction de localisation d'abonnement (SLF) est utilisée comme mécanisme de

2.2.7 Contrôleur de fonction de ressource multimédia

2.2.8 Processeur de fonction de ressource multimédia

Le processeur de fonction de ressource multimédia (MRFP) fournit des ressources de

. Mélange de flux multimédias entrants (par exemple, pour plusieurs parties).

. Source de flux multimédia (pour les annonces multimédia).

2.2.9 Serveur d'applications

. La possibilité de traiter et d'impacter une session SIP entrante reçue de

. La capacité d'émettre des requêtes SIP.

. La capacité d'envoyer des informations comptables au CCF et à l'OCS.

API OSA CASQUETTE

SIP COMME AOS SCS GI-SSF COMME

Graphique 2.5Relation entre différents types d'AS.

2.2.10 Fonction de contrôle de la passerelle de dérivation

La fonction de contrôle de la passerelle d'évasion (BGCF) est chargée de choisir où se

2.2.11 Fonction de contrôle de la passerelle média

2.2.12 Fonction de passerelle multimédia du sous-système multimédia IP