SRVCC – Single Radio Voice Call Continuity – Suite

Nous allons maintenant étudier le mécanisme SRVCC et ses évolutions eSRVCC et rSRVCC en illustrant le concept par une approche pratique.

On suppose que l’UE1 souhaite contacter l’UE2. L’UE1 est sur un réseau 4G, vis à vis du réseau IMS, qui est le réseau home, l’UE1 est dans un réseau visité.

L’UE1 souhaite appeler l’UE2. L’UE1 est compatible avec le mécanisme SRVCC et l’appel est évidemment contrôlé par le réseau IMS. Ainsi, après un échange de signalisation SIP, après avoir construit les bearers, l’appel s’effectue. L’UE1 se déplace dans le réseau visité et s’éloigne du eNB, la puissance reçue s’affaiblit.

  1. L’eNb décide alors de mettre en oeuvre le mécanisme SRVCC en envoyant une requête au MME
  2. A partir de cette requete, le MME transmet la demande au MSC afin que ce dernier alloue les ressources au niveau du domaine CS autrement dit avec le RNC puis le Nb.
  3. Le MSC demande la création d’une connexion avec le SCC AS dans l’objectif de transférer la voix (paquet IP) du réseau LTE vers le réseau 3G donc pour transférer la session du PGW vers le MSC.

SRVCC

A ce stade, pour le mécanisme SRVCC définit dans la R8, la procédure est la suivante :

  • Le SCC demande à l’UE2 de changer la destination de ses messages SIP de l’UE1 vers le MSC.

En parallèle,

  • Le MSC informe le MME de la réservation de ressource dans le domaine CS.

A partir de ce moment, le MME peut demander à l’UE1 de basculer vers le réseau 3G (Handover). Après le Handover, la signalisation SIP est transmise du SCC vers le MSC, le SCC est le point d’ancrage pour la signalisation, et le média pour la voix est envoyé de l’UE2 vers le MSC. L’UE2 est donc le point d’ancrage pour le média.

Or, la modification de l’adresse IP de destination (UE1 vers MSC) pour le média de la voix provoque de nombreuses pertes de paquets et une latence puisque toutes les entités du réseau IMS de l’UE2 et l’UE2 doivent modifier leur chemin de requêtes SIP

En simplifiant la figure avec les entités concernés, le chemin de signalisation et d’appel est représenté par la figure ci-dessous.

SRVCC_fig4

eSRVCC

Le principal défaut  du SRVCC est le suivant : Lorsqu’un HandOver affecte l’UE1 dans son réseau visité (ou en roaming), cela impacte les messages SIP et RTP de l’UE2. Le mécanisme eSRVCC consiste à rajouter des points d’ancrage au niveau du réseau visité de l’UE1 afin que tout handover de l’UE1 soit transparent pour l’UE2.

Ainsi, au niveau du eSRVCC, 2 nouvelles entités ont été rajoutées pour avoir un point d’ancrage dans le réseau visité à savoir :

  • ATCF : Point d’ancrage pour la signalisation
  • ATGW : Point d’ancrage pour le média

SRVCC_fig5

 

 

 

 

 

 

SRVCC – Single Radio Voice Call Continuity

Lorsque le réseau VoLTE sera déployé (2ème semestre 2015), l’opérateur devra garantir la continuité d’appel en réalisant

  • un HandOver entre le réseau 4G et le réseau 2G/3G (nommé IRAT Handover) tant pour l’appel téléphonique (passage de la voix du domaine PS vers le domaine CS) que pour les sessions Data
  • un Transfert de session au niveau du cœur réseau entre le MME et le MSC. L’appel est géré par le réseau IMS, et plus précisément pour les mobiles compatibles SRVCC  (Single Radio Voice Call Continuity), le point d’ancrage de l’appel est réalisé par un serveur d’application nommé SCC AS (Service Centralization and Continuity).

SRVCC_fig3

Nous allons dans un premier temps décrire les notions  Single Radio  et Voice Call Continuity (SCC AS). Le SCC AS est un serveur d’application IMS, cette solution se diffère donc du CSFB pour lequel l’IMS n’est pas mis en place.

SCC AS

Avec le déploiement de l’IMS, lorsque le mobile émet ou reçoit un appel, la requête SIP INVITE est transmise jusqu’au S-CSCF. L’exécution de la tâche qui est associée (renvoi de la requête vers un AS) dépend des règles de souscription de l’abonné et la tâche qui est réalisée est obtenue en appliquant l’événement (par exemple un appel) à la liste de règles définie à travers les paramètres du filtre iFC (initial Filter Criteria). Si le mobile n’est pas compatible au mécanisme SRVCC ou si ce dernier n’est pas déployé, l’appel sera transmis au Serveur d’application Téléphonie (TAS  : Téléphony Application Server). Dans cet article, le cas qui nous intéresse est le mécanisme SRVCC on suppose donc que la technologie est déployée et que le  mobile est compatible, dans ce cas, l’appel sera dirigé vers un serveur qui sera considéré comme le serveur d’ancrage dans le réseau IMS. Ce dernier se nomme SCC AS avec la particularité suivante :

  • Si l’UE est à l’origine de l’appel, l’appel sera transmis d’abord au SCC AS avant d’être traité par le TAS.
  • Si l’UE est à destination de l’appel, l’appel sera transmis au TAS qui le transfère au SCC AS.

SRVCC_fig1

ICS : IMS Centralized Service.

Single Radio ou Dual Transfer Mode

La solution CSFB que nous avons étudiée est un mécanisme transitoire permettant, au téléphone en mode 4G initiant un appel, de passer du réseau LTE (PS) au réseau 2G/3G (CS). Dans le cas ou le téléphone migre vers le réseau 3G, les sessions Data en commutation de paquets peut à la fois gérer les services datas et la voix (VoHSPA).

Dans le cas de la migration vers la 2G, les sessions Datas seront suspendues jusqu’à la fin de l’appel téléphonique en CS c’est à dire jusqu’à ce que l’UE revienne sur le réseau 4G, sauf si l’UE 2G supporte le Dual Transfer Mode (DTM) qui permet à la fois la voix et la Data.

SRVCC : Single Radio Voice Continuity Call

L’arrivée de la VoLTE est concomitante avec le déploiement du réseau 4G de l’opérateur, il est donc nécessaire de pouvoir basculer l’appel en VoLTE sur le réseau IMS vers le réseau traditionnel en cas de perte de couverture 4G, tout en garantissant la QoS.

C’est le rôle du mécanisme SRVCC que de basculer l’appel du mode PS 4G vers le mode CS 2G/3G. Cela impacte le MSC car ce dernier doit gérer l’appel de l’UE vers le point d’ancrage IMS.  Le MSC est renommé « MSC Server enhanced for SRVCC ». La méthode présentée est à la fois compatible pour la VoLTE et la VoHSPA.

NB : Il y a deux mécanismes SRVCC, le premier SRVCC vers le GERAN/UTRAN que nous abordons ici et proposé  par le 3GPP, le second permet de basculer vers le réseau CDMA et est proposé par le 3GPP2.

Les entités impactées par ce mécanisme (SRVCC – R10) sont :

  • UE
  • MSC
  • eNb
  • MME
  • P-CSCF
  • HSS

avec l’ajout de deux autres entités lors de la R10 :

  • ATCF : Point d’ancrage de la signalisation SIP
  • ATGW : Sous le contrôle de l’entité ATCF

SRVCC_fig2

Le MME dans cette procédure doit être en mesure :

  • Séparer le flux Data (PS) du flux Voix (géré par le mode CS après basculement)
  • Gérer le handover des bearers PS non voix avec la cellule cible
  • Initier la procédure de handover SRVCC (en s’appuyant sur le QCI=1)

Une nouvelle interface, nommée Sv, est créée entre le MSC et le MME. Cette interface permet au MME de :

  • demander au MSC de réserver des ressources radios au niveau de l’interface d’accès radio CS (BTS ou Noeud B). Le MSC est donc responsable de la réservation de ressource pour la continuité d’appel
  • donner l’adresse du SCC AS au MSC afin que ce dernier émette une demande d’appel de la part de l’UE.

Procédure

Au cours de l’attachement au réseau, le MME récupère le STN-SR (Session Transfer Number for SR-VCC) de la part du HSS. Il s’agit d’un numéro au format téléphonique répondant à la spécification E.164. C’est cette adresse que le MME transmet au MSC afin que ce dernier puisse émettre un appel et créer un acheminement entre l’UE et le point d’ancrage IMS.

En effet, l’objectif du SRVCC est de transférer l’appel PS vers le mode CS, or l’appel est géré par le réseau IMS, et plus précisément par un serveur d’application nommé SCC (Service Centralization and Continuity). Le MSC quant à lui a besoin d’un numéro d’appel ou de commutation pour réaliser la jonction avec le réseau IMS. Le STN-SR est envoyé du MME au MSC via l’interface Sv.

SRVCC

Le MSC initie une requête SIP vers l’IMS via le numéro STN-SR. Le SCC-AS reçoit la requête INVITE avec le STN-SR avec le message de demande de transfert d’une session active. C’est au SCC AS de gérer ce transfert de session.

Sur le call flow suivant, on retrouve les deux étapes du SRVCC

  • un HandOver
  • un Transfert de session

SRVCC_callflow

Dans un prochain article, nous détaillerons la procédure.

Gestion de l’itinérance (Part 4) : VoLTE

Roaming LTE

VOLTE (prononce volti:) fait référence à plusieurs technologies pour délivrer des communications en temps réels par paquets IP. Le VOLTE permet de fournir des services existants comme la voix et les SMS sur le réseau LTE. Le standard IR.92 proposé par le GSMA s’appuie sur une partie de l’architecture IMS. L’IMS, pour résumer, est une plate-forme standardisée pour délivrer des services multimédias sur un support IP.

L’itinérance sur le réseau IMS (IMS Roaming) est spécifiée dans le document GSMA IR.65, faisant lui-même référence au document 3GPP 32 221. Nous allons utiliser ces documents pour écrire cet article.

Dans le cas du roaming LTE, on suppose l’interconnexion entre deux opérateurs assurées par un réseau de transport qualifié IPX.

La signalisation (par exemple TAU : Location Update du terminal par le protocole Diameter) et le roaming de données (Applications IP encapsulées dans un tunnel GTP) sont échangées entre l’opérateur A (Home – Opérateur nominal) vers l’opérateur B (Visited) via IPX.

IPX_2

Figure 1 : Roaming entre 2 réseaux LTE via un fournisseur de service IPX

Le fournisseur de service IP, nommé IPX est connecté aux réseaux des opérateurs LTE via une passerelle de bordure (BG). Dans la norme GSMA (IR.65), l’IPX se nomme InterService Provider.

Dans le cadre du VoLTE, la téléphonie est prise en charge par le réseau IMS (IP Multimédia Subsystem).  Pour un UE, dans son réseau nominal ou un réseau visité, il y a trois possibilité de se connecter à un serveur IMS comme le présente la figure 2

Volte_roaming_IP_domain

Figure 2 :Domaines d’adressages IP vers le réseau PS et IMS

Un UE souhaitant accéder au sous-système IMS nécessite une adresse IP. Une fois l’adresse octroyée, il est possible de connecter le P-GW/GGSN du réseau visité ou du réseau nominal au serveur IMS. Lorsque l’UE est sur un réseau visité, pour des raisons d’efficacité (lien direct notamment en roaming) il peut être préférable de connecter l’UE au réseau IMS du réseau visité comme le montre la figure 1 ou de passer par le réseau IMS du réseau nominal (Figure 2).

Il faut bien noter que l’accès au réseau visité IMS (l’accès au Proxy du réseau IMS, nommé P-CSCF) est directement connecté au PGW du réseau visité.

Volte_roaming1

Figure 3 : L’UE accède au réseau IMS du réseau visité via le PGW du réseau visité

Dans le cas ou l’IMS exploité est dans le réseau de l’opérateur nominal, l’UE a une connectivité IP sur le réseau visité mais toutes les fonctionnalités IMS sont fournies par l’opérateur nominal (Home Network).

Volte_roaming_IMS_Home_PGW_visite

Figure 4: L’UE accède au réseau IMS du réseau nominal via le PGW du réseau visité

La différence est la suivante, l’UE est virtuellement présent sur le réseau de l’opérateur nominal . Il faut bien noter que l’accès au réseau IMS du réseau home (l’accès au Proxy du réseau IMS, nommé P-CSCF) est directement connecté au PGW du réseau visité.

Enfin, dans le troisième cas de figure (figure 5), le réseau IMS utilisé est celui de l’opérateur nominal, comme c’était le cas précédemment sur la figure 4, mais en passant par le PGW du réseau nominal

Volte_roaming_IP_IMS_home_PGW_home

Figure 5 : L’UE accède au réseau IMS du réseau visité via le PGW du réseau visité

Pour bien comprendre la différence, il est nécessaire de décrire le réseau IMS, et les équipements de la couche de contrôle (CSCF).

Pour simplifier et finir cet article sur le roaming, nous allons illustrer le roaming LTE par la figure 6 ci-dessous qui montre les différents types de roaming qui est une autre représentation de la figure 2.

Volte_roaming

Figure 6 :Domaines d’adressages IP vers le réseau PS et IMS

Cette figure suppose un réseau Full IMS avec la gestion de la QoS via un opérateur tiers.

Or, le déploiement du VoLTE est une finalité en soi, en réalité à ce jour différentes techniques sont mises en œuvre pour contourner la VoIP sur le réseau LTE.

En effet, si l’objectif principal est de promouvoir l’utilisation du réseau de commutation de paquets (réseau IP) pour fournir des services multimédias (communication téléphoniques ou visiophonie) avec la même qualité de service que celle offerte par la commutation de circuit et sans coupure. La difficulté est donc double : le maintien de la QoE (Quality Of Experience), et l’interconnexion pour le service de la voix entre un réseau tout IP (LTE) et un réseau 2G ou 3G (commutation de circuit). Durant cette transition de la 4G, diverses alternatives sont proposées pour la transmission de la voix :

  • CSFB : Circuit Switch FallBack
  • SRVCC : Single Radio Voice Call Continuity  permet l’interconnexion entre le réseau à commutation de paquets (PS) et commutation de circuit (CS) sans incidence sur la QoE
  • VOLTE

Nous verrons également ces procédures dans une autre série d’articles publiés prochainement.