EP1516500A1 - Procede pour supporter du trafic temps reel dans un systeme de radiocommunications mobiles - Google Patents

Abstract

Procédé pour supporter du trafic temps réel dans un système de radiocommunications mobiles comportant un réseau d'accès radio et un coeur de réseau, procédé dans lequel du trafic temps réel supporté en mode paquet dans le coeur de réseau est supporté dans le réseau d'accès radio au moyen d'une allocation de canaux dédiés.

Description

PROCEDE POUR SUPPORTER DU TRAFIC TEMPS REEL DANS UN SYSTEME DE RADIOCOMMUNICATIONS MOBILES

La présente invention concerne d'une manière générale les systèmes de radiocommunications mobiles. D'une manière générale, ces systèmes font l'objet de normalisation, et pour plus d'informations on pourra se référer aux normes correspondantes, publiées par les organismes de normalisation correspondants.

D'une manière générale, dans ces systèmes, on peut distinguer différents types de services, en fonction de la qualité de service requise. Notamment, on peut distinguer des services temps réel, correspondant à du trafic sensible aux délais de transfert (tel que notamment la voix, ou encore du trafic à flux continu ou « streaming »), et des services non temps réel, correspondant à du trafic non sensible aux délais de transfert (tel que notamment le transfert de données).

D'une manière générale, dans ces systèmes, on peut aussi distinguer différents types de services, selon les techniques utilisées pour les supporter. On peut ainsi distinguer les services en mode circuit et les services en mode paquet. En mode circuit, le trafic est transporté dans des ressources ou canaux dédiés alloués en permanence à un utilisateur pour la durée d'un appel. En mode paquet, le trafic est transporté dans des ressources ou canaux partagés entre plusieurs utilisateurs. Le mode circuit permet ainsi de garantir les délais de transfert pour chaque utilisateur , mais ne permet pas une utilisation efficace ' des ressources disponibles pour l'ensemble des utilisateurs. Au contraire, le mode paquet permet une utilisation efficace de l'ensemble des ressources disponibles, mais ne permet pas de garantir les délais de transfert. Le mode circuit et le mode paquet se différencient non seulement par des techniques différentes d'allocation de ressources, mais aussi par des architectures de protocoles différentes.

Les systèmes de deuxième génération, de type GSM (« Global System for Mobile communications ») ont plutôt été conçus initialement pour supporter du trafic temps réel (essentiellement de la voix) en mode circuit. Des fonctionnalités supplémentaires ont ensuite été introduites dans ces systèmes, correspondant à la fonctionnalité GPRS (« General Packet Radio Service »), pour leur permettre de supporter du trafic non temps réel en mode paquet. L'architecture générale des systèmes de radiocommunications mobiles est rappelée sur la figure 1 , elle comporte essentiellement : un réseau d'accès radio 1 , ou RAN (pour « Radio Access Network »), un cœur de réseau 4, ou CN (pour « Core Network »). Dans cette architecture générale, le RAN est formé de stations de base 2 et de contrôleurs de stations de base 3. Il est en relation d'une part avec des terminaux mobiles via une interface 6 appelée aussi interface radio, et d'autre part avec le CN 4 via une interface 7. Le CN 4 est en relation avec des réseaux extérieurs, non illustrés spécifiquement, tels que PSTN (« Public Switched Téléphone Network »), PDN (« Packet data Network »), ...etc.

L'architecture générale des systèmes de deuxième génération de type GSM est rappelée sur la figure 2. Dans ces systèmes, le RAN est appelé BSS ("Base Station Subsystem"), les stations de base sont appelées BTS ("Base Transceiver Station"), les contrôleurs de stations de base sont appelés BSC ("Base Station Controller"), et les terminaux mobiles sont appelés MS (« Mobile Station »). Les fonctionnalités propres aux services en mode paquet sont en général supportées par une entité particulière appelée PCU (« Packet Control Unit »), non illustrée spécifiquement, prévue en général dans le BSS.

Dans les systèmes de deuxième génération de type GSM, le CN comporte: - pour le mode circuit, des entités de type 2G-MSC (où 2G est utilisé pour

« 2^nd Génération » et MSC est utilisé pour « Mobile Switching Center »), pour le mode paquet, des entités de type 2G-SGSN (où 2G est utilisé pour « 2^nd Génération » et SGSN est utilisé pour « Serving GPRS Support Node»). Ainsi, dans les systèmes de deuxième génération de type GSM, l'interface 7 comporte une interface appelée interface « A » vers les entités de type 2G-MSC, et une interface appelée interface « Gb » vers les entités de type 2G-SGSN.

Les systèmes de type GERAN (« GSM EDGE Radio Access Network », où EDGE est utilisé pour « Enhanced Data rates for GSM Evolution ») correspondent à des évolutions des systèmes de type GSM, visant à offrir des services de troisième génération, aussi bien pour des applications temps réel que pour des applications non temps réel. Le but est notamment de pouvoir supporter des services de type IMS (« IP Multimedia Sub-system »,où IP est utilisé pour « Internet Protocol »). Pour cela, il a initialement été proposé d'aligner les services offerts par les systèmes de type GERAN sur ceux offerts par les systèmes de troisième génération de type UMTS (« Universal Mobile Télécommunication System ») en connectant des BSS de type GERAN au CN 3G via les interfaces lu, lesdites interfaces étant utilisées pour connecter l'UTRAN (pour « UMTS Terrestrial Radio Access Network) au CN 3G.

L'architecture des systèmes de troisième génération de type UMTS est rappelé sur la figure 3. Dans ces sytèmes, le RAN est appelé UTRAN , les stations de base sont appelées Node B, les contrôleurs de stations de base sont appelés RNC

(« Radio Network Controller »), et les terminaux mobiles sont appelés UE (« User Equipnnent »).

Dans les sytèmes de troisième génération de type UMTS, le CN comporte: pour le mode circuit, des entités de type 3G-MSC (où 3G est utilisé pour « 3^rd Génération » et MSC est utilisé pour « Mobile Switching Center »), pour le mode paquet, des entités de type 3G-SGSN (où 3G est utilisé pour « 3"* Génération » et SGSN est utilisé pour « Serving GPRS Support

Node»). Ainsi, dans les systèmes de troisième génération de type UMTS, l'interface 7 comporte une interface appelée interface « lu-CS » vers les entités de type 3G-MSC, et une interface appelée interface « lu-PS » vers les entités de type 3G-SGSN. L'architecture initialement proposée pour les sytèmes de type GSM/GERAN est rappelée sur la figure 4. Il a ainsi été proposé d'introduire dans les systèmes de type GSM/GERAN, en plus des interfaces « A » et « Gb » existantes, une interface de type « lu-CS » vers des entités de type 3G-MSC et une interface de type « lu-PS » vers des entités de type 3G-SGSN. Cependant, il est maintenant reconnu qu'une telle approche nécessite des adaptations complexes et coûteuses, notamment dans les protocoles radio de couches 2 et 3.

C'est pourquoi une autre approche a maintenant été proposée, qui consiste à supporter les mêmes services que ceux supportés au moyen des interfaces « lu- CS », « lu-PS » mais au moyen des interfaces existantes « A », « Gb ». Le but est notamment de pouvoir supporter des services de type IMS (« IP Multimedia Sub- system » ) via l'interface « Gb ». Pour mémoire, aujourd'hui l'interface « Gb » est seulement capable de supporter des services non temps réel (éventuellement du trafic à flux continu ou « streaming »), et des services temps réel peuvent seulement être supportés via l'interface « A ».

D'une manière générale, cette dernière approche inclut les améliorations suivantes, en vue de faire évoluer le mode dit « A/Gb » vers un mode dit « A/Gb+ »: - flux de données multiples et en parallèle entre BSS et MS, transfert intercellulaire (ou « handover ») pour des services temps réel en mode paquet, support de services temps réel par la partie radio (ou RAN), support de services temps réel par la partie réseau (ou CN), - support de services IMS, amélioration des mécanismes de sécurité. Jusqu'à présent, la seule proposition pour le support de services temps réel en mode paquet sur l'interface « Gb » a été de prévoir un transfert intercellulaire ou « handover » pour les services en mode paquet. On rappelle que les procédures de transfert intercellulaire ou « handover » sont propres au mode circuit. Selon ces procédures, des ressources sont réservées dans une nouvelle cellule alors qu'une station mobile est encore connectée à une ancienne cellule, ce qui permet, au prix d'une certaine complexité, de garantir les délais de transfert. Au contraire, les procédures de re-sélection de cellule sont propres au mode paquet. Selon ces procédures, des ressources ne sont allouées à une station mobile dans une nouvelle cellule que lorsque la station mobile est connectée à la nouvelle cellule, ce qui simplifie les procédures mais ne garantit pas les délais de transfert.

La proposition mentionnée ci-dessus permet d'introduire pour le mode paquet des mécanismes similaires à ceux utilisés dans les procédures de transfert intercellulaire ou « handover » pour le mode circuit. De plus, des procédures ont été proposées pour permettre à une station mobile de reporter régulièrement des mesures radio au réseau en vue de permettre à ce dernier de sélectionner une nouvelle cellule, comme dans le mode circuit. Pour cela, une nouvelle combinaison de canaux sur l'interface radio a été proposée, notamment dans le document « Tdoc G2-020553, Agenda Item 5.3, 3GPP TSG GERAN WG2 Sophia-Antipolis, France, 27-31 May 2002 ». Cette nouvelle combinaison consiste en un canal alloué pour un transfert de données en mode paquet, ou canal PDTCH (« Packet Data Transfer Channel ») et en un canal de signalisation dédié en mode circuit ou canal SACCH (« Slow Associated Control Channel »), ce dernier canal étant utilisé pour un tel report de mesures radio de la station mobile vers le réseau.

Ainsi que l'a observé le demandeur, une telle proposition a notamment les inconvénients suivants: la station de base BTS et la station mobile MS doivent supporter une nouvelle combinaison de canaux, l'entité PCU (dans laquelle sont mises en œuvre les fonctionnalités propres au mode paquet) doit traiter des reports de mesures et implémenter des algorithmes de transfert intercellulaire ou « handover», - une nouvelle procédure doit être introduite sur l'interface radio pour supporter cette nouvelle combinaison, des problèmes se posent au niveau de l'architecture de ces systèmes puisque le SACCH utiliserait un protocole de type LAPDm (« Link Access Protocol for the Dm channel ») comme protocole de couche 2 alors que le canal de signalisation associé au canal PDTCH, ou canal PACCH

(« Packet Associated Control Channel »), utilise un protocole de type RLC/MAC, ces deux protocoles se terminant dans des nœuds de réseau différents (BTS pour LAPDm, PCU pour RLC/MAC). Par ailleurs, le canal PDTCH est un canal uni-directionnel alors que les services temps réel tendent à requérir des canaux bi-directionnels. Même pour du trafic à flux continu ou « streaming », qui est prinicipalement une application unidirectionnelle, il semble difficile d'allouer le sens retour à d'autres utilisateurs, puisque ces utilisateurs généreraient très vraisemblablement du trafic dans l'autre direction, d'où une préemption de resources pour du trafic de « streaming » d'une manière inacceptable.

La présente invention a notamment pour but de proposer une autre approche pour le support de services temps réel sur une interface de type « Gb », permettant notamment d'éviter tout ou partie des inconvénients mentionnés précédemment, ou encore nécessitant très peu d'adaptations par rapport aux architectures existantes.

Un des objets de la présente invention est un procédé pour supporter du trafic temps réel dans un système de radiocommunications mobiles, tel que défini dans les revendications. Un autre objet de la présente invention est un équipement de réseau d'accès radio pour système de radiocommunications mobiles, comportant des moyens pour mettre en œuvre un tel procédé.

Un autre objet de la présente invention est un équipement de cœur de réseau pour système de radiocommunications mobiles, comportant des moyens pour mettre en œuvre un tel procédé.

Un autre objet de la présente invention est une station mobile pour système de radiocommunications mobiles, comportant des moyens pour mettre en œuvre un tel procédé. D'autres objets et caractéristiques de la présente invention apparaîtront à la lecture de la description suivante d'un exemple de réalisation, faite en relation avec les dessins ci-annexés dans lesquels: la figure 1 est un schéma destiné à rappeler l'architecture générale d'un système de radiocommunications mobiles, - la figure 2 est un schéma destiné à rappeler l'architecture générale d'un système de deuxième génération de type GSM, la figure 3 est un schéma destiné à rappeler l'architecture générale d'un système de troisième génération de type UMTS, la figure 4 est un schéma destiné à rappeler une architecture générale proposée initialement pour un système de type GERAN, les figures 5a et 5b sont des schémas destinés à illustrer, par comparaison, l'évolution proposée par la présente invention pour l'architecture générale d'un système de type GERAN, la figure 6 est un schéma destiné à illustrer un exemple de mise en œuvre d'un procédé suivant l'invention.

La présente invention suggère d'utiliser les canaux et protocoles radio existants, utilisés pour les services temps réel lorsque ceux-ci sont relayés via le MSC. Au lieu d'utiliser des canaux partagés (ou « shared channels ») pour échanger des unités de données ou PDUs (« Packet Data unit ») de/vers le SGSN, l'idée est d'utiliser des canaux dédiés (ou « dedicated channels »). Si des services temps réel et non temps réel doivent être supportés simultanément, les procédures DTM (« Dual Transfer Mode ») existantes peuvent être utilisées pour contrôler l'établissement et le relâchement des différents flux de données. On rappelle brièvement que la fonctionnalité DTM est une fonctionnalité permettant de supporter simultanément les deux types de services (en mode circuit et en mode paquet), pour les stations mobiles pouvant supporter simultanément ces deux types de services, en prévoyant une coordination par le BSS des ressources nécessaires à chacun des modes. Pour une description détaillée de cette fonctionnalité, on pourra aussi se référer aux spécifications correspondantes publiées par les organismes de normalisation.

L'évolution proposée selon l'invention peut être illustrée par comparaison des figures 5a et 5b. Les équipements illustrés sur les figures 5a et 5b sont ceux déjà présentés en relation avec la figure 2, à savoir BTS, BSC, MSC (ou 2G-MSC), SGSN (ou 2G-SGSN) ; de plus, la connexion entre un MSC et un réseau extérieur de type PSTN, via une entité de type G-MSC (« Gateway-MSC ») a été illustrée sur les figures 5a et 5b; de même la connexion entre un SGSN et un réseau extérieur de type PDN, via une entité de type GGSN (« Gateway GPRS Support Node») a été illustrée. Les interfaces « Abis » entre BTS et BSC, « Gn » entre SGSN et GGSN, et « Gi » entre GGSN et PDN ont également été illustrées. Le but étant notamment de pouvoir supporter des services de type IMS, dans la figure 5b, PDN a été remplacé par IMS.

La figure 5a correspond à une architecture classique, dans laquelle les services temps réel relayés via un MSC sont transportés via des canaux dédiés sur l'interface radio.

La figure 5b correspond à une architecture selon l'invention, dans laquelle les services temps réel relayés via un SGSN sont transportés via des canaux dédiés sur l'interface radio.

Dans l'architecture GSM existante, il est prévu deux types d'unités pour traiter les deux types d'appels, en mode circuit et en mode paquet. Ces deux types d'unités peuvent ou non être intégrées physiquement dans un même équipement.

L'unité chargée de traiter les appels en mode paquet, ou PCU (« Packet Control

Unit ») est en général prévue dans le BSS.

Ainsi, généralement, il y a dans le BSS une unité connectée à l'interface « A » et qui traite les appels en mode circuit, et une autre unité connectée à l'interface « Gb » et qui traite les appels en mode paquet. Les appels en mode circuit sont transportés au moyen de canaux dédiés, c'est-à-dire alloués en permanence pour la durée de l'appel, alors que les appels en mode paquet sont transportés au moyen de canaux partagés, c'est-à-dire partagés avec d'autres utilisateurs.

L'invention propose de supporter des services temps réel dans l'unité connectée à l'interface « Gb » à travers les fonctions suivantes : - support de re-localisation de lien « Gb » lorsque la station mobile change de cellule et lorsque la nouvelle cellule est contrôlée par un BSS différent du BSS contrôlant l'ancienne cellule, et lorsqu'une session temps réel est en cours à travers l'interface « Gb », support de procédure de PFC (« Packet Flow Context ») pour négocier les paramètres de QoS avec le SGSN lors d'une activation/modification de contexte PDP,

Lorsqu'un PFC est créé/modifié pour un flux de données temps réel, l'unité connectée à l'interface « Gb » déclenche l'établissement/modification d'un canal dédié, - les unités de données temps réel reçues de/vers l'interface »Gb » sont transportées sur l'interface radio au moyen de canaux dédiés, lorsqu'un « handover » est requis, les procédures et mécanismes existants définis pour les canaux dédiés sont utilisés ; la seule différence est que le MSC n'est pas informé ; au lieu de cela, l'unité connectée à l'interface « Gb » est informée, et assure si nécessaire une re-localisation de lien « Gb ». Avant de décrire un exemple de mise en œuvre de la présente invention, on rappelle tout d'abord les protocoles ou procédures propres aux systèmes en mode paquet, ou aux architectures de type IMS, dans la mesure où ils peuvent être utiles à la description de cet exemple.

Selon l'architecture en couches utilisée pour décrire les systèmes en mode paquet, notamment de type GSM/GPRS, on distingue, sur l'interface radio entre MS et BSS: une première couche, ou couche physique, - une deuxième couche, ou couche liaison, elle-même divisée en plusieurs couches: par ordre de niveaux croissants, MAC (pour « Médium Access Control » en anglais), RLC (pour « Radio Link Control » en anglais) et LLC (pour « Logical Link Control » en anglais). De même, on distingue, sur l'interface « Gb » entre BSS et SGSN: une première couche, ou couche physique, une deuxième couche, ou couche liaison, elle-même divisée en plusieurs couches : par ordre de niveaux croissants, « Frame Relay » (en anglais), BSSGP (pour « BSS GPRS Protocol» en anglais), et LLC (pour « Logical

Link Control » en anglais).

Des trames appelées trames LLC (ou « LLC frames » en anglais) sont formées, dans la couche LLC, à partir d'unités de données reçues d'un niveau supérieur, ou couche réseau, via une couche d'adaptation ou SNDCP (« Subnetwork Dépendent Convergence Protocol »). Dans les trames LLC ces unités de données sont appelées unités de données LLC-PDU (pour « LLC-Protocol Data Units »).

Les unités de données LLC-PDU sont ensuite segmentées dans la couche RLC/MAC, de manière à former des blocs appelés blocs de données RLC (ou « RLC data blocks »). Les blocs de données RLC sont ensuite mis au format requis pour transmission sur l'interface radio, dans la couche physique.

En outre, des protocoles de signalisation sont prévus, notamment pour la gestion des ressources radio ou RR (« Radio Resource Management »), la gestion de la mobilité ou MM (« Mobility Management»), la gestion de session ou SM (« Session Management»), le contrôle de lien logique ou LL (« Logical Link Control »), ...etc. On rappelle aussi que, selon le protocole de gestion de ressources radio, différents modes sont possibles pour une station mobile, en mode paquet : un mode dit « packet transfer mode », dans lequel des ressources sont allouées temporairement, lorsque des données sont effectivement à transmettre au cours d'une communication, ces ressources formant un canal virtuel temporaire ou TBF (« Temporary Block Flow ») permettant un transfert de données entre station mobile et réseau, pour un sens de transmission donné, un mode dit « packet idle mode », dans lequel aucun TBF n'est établi.

Par opposition, en mode circuit, le mode dans lequel des ressources sont allouées à une station mobile est appelé « dedicated mode », ces ressources étant alors des ressources dédiées allouées à la station mobile pour la durée de la communication. Dans le cas où à la fois des ressources dédiées et des ressources partagées sont allouées à la station mobile en même temps, ladite station mobile se trouve en « dual transfer mode ».

A sa mise en marche, une station mobile est aussi dite en mode veille, ou « idle mode ». En outre, selon le protocole de gestion de mobilité, on définit une procédure dite d' « attachement GPRS » (ou « GPRS Attach»), permettant à une station mobile de passer du mode « idle mode » à un mode dit « attaché GPRS » (ou « GPRS attached »), dans lequel elle peut accéder à des services GPRS. On définit aussi la procédure inverse de « GPRS Detach ». Une station mobile en mode veille et non attachée GPRS communique avec le réseau par l'intermédiaire d'échanges de signalisation sur des canaux appelés CCCH (« Common Control CHannel »). Une station mobile attachée GPRS et en mode « packet idle mode » communique avec le réseau par l'intermédiaire d'échanges de signalisation sur des canaux appelés PCCCH (« Packet Common Control CHannel ») si de tels canaux sont prévus dans la cellule considérée, sinon par les canaux CCCH. Une station mobile attachée GPRS et dans le mode « packet transfer mode » communique avec le réseau par l'intermédiaire d'échanges de signalisation sur des canaux appelés PDCH (« Packet Data Channel »).

On rappelle que le canal de données PDCH inclut un canal de trafic ou PDTCH (« Packet Data Trafic Channel »), et un canal de signalisation ou PACCH (« Packet Associated Control CHannel »).

On rappelle aussi que le canal CCCH inclut lui-même un certain nombre de canaux tels que notamment un canal PCH (« Paging CHannel »). De même le canal PCCCH inclut lui-même un certain nombre de canaux tels que notamment un canal PPCH (« Packet Paging CHannel »).

On rappelle aussi que lorsqu'une session doit être établie dans un système tel que le GPRS, une procédure d'activation contextuelle de protocole de données en mode paquet (ou PDP, pour « Packet Data Protocol ») doit être lancée. Le contexte de PDP (ou « PDP context ») contient les informations nécessaires au transfert des données entre MS et GGSN (informations de routage, profil de QoS, ...etc.).

On rappelle aussi que dans une architecture de type IMS, une signalisation relative au contrôle de session d'appel multimédia a jusqu'à présent été définie pour des technologies de type UMTS. Une telle signalisation comporte ainsi typiquement l'établissement d'une connexion RRC entre une station mobile et un RAN, suivi de l'établissement d'une porteuse UMTS pour transporter la signalisation relative au protocole SIP. Le protocole RRC, pour « Radio Resource Control » est défini dans la norme 3GPP TS 25.331 . Le protocole SIP (« Session Initiation Protocol ») ainsi que le protocole SDP (« Session Description Protocol ») qui lui est lié ont été définis par l'IETF (« Internet Engineering Task Force ») qui est l'organisme de normalisation pour le protocole Internet, ou IP (pour « Internet Protocol »).

Les principales étapes d'une telle signalisation sont les suivantes, notées SI , S2, S3. Pour simplifier, on ne considère ici qu'un des trois segments en lesquels se décompose le contrôle de session d'appel, en l'occurrence le segment qui va de l'UE appelant à son S-CSCF, les deux autres segments étant le segment qui va de l'UE appelé à son S-CSCF, et le segment qui relie les S-CSCF de l'UE appelant et de l'UE appelé. On rappelle que les entités S-CSCF (« Serving-Call Session Control Function ») et P-CSCF (« Proxy-Call Session Control Function ») sont des entités du réseau de cœur, en charge du contrôle de sessions d'appels multimédia.

L'étape SI correspond essentiellement à une étape préliminaire à l'établissement de session.

L'étape SI utilise une procédure dite d'activation de contexte de protocole de données en mode paquet, ou contexte PDP (ou « PDP Context», pour « Packet Data Protocol Context»), nécessaire au transport de signalisation de contrôle de session multimédia. On rappelle qu'un contexte PDP comporte un ensemble de paramètres de porteuse UMTS, tels que notamment des paramètres de qualité de service, ou QoS (pour « Quality of Service »), ...etc. Cette étape sera suivie ultérieurement d'une autre procédure d'activation de contexte PDP, nécessaire au transport des données liées à la session multimédia elle-même. Ces deux contextes PDP concernant la même adresse IP, l'étape SI sera aussi appelée procédure d'activation de contexte PDP primaire.

L'étape SI comporte elle-même essentiellement les étapes suivantes. Dans une étape SU , une requête d'activation de contexte PDP est transmise de l'UE au RAN, avec les paramètres correspondants de qualité de service de bout en bout (ou « end-to-end QoS ») pour la porteuse UMTS de signalisation de niveau SIP. Dans une étape SI 2, le 3G-SGSN commande l'établissement d'une porteuse d'accès radio (ou RAB, ou « Radio Access Bearer ») de sorte qu'un support soit disponible entre UE et 3G-SGSN, répondant aux contraintes de qualité de service. Lorsque le RAN reçoit une telle requête, après un contrôle d'admission d'appel, il établit une porteuse radio (ou RB, ou « Radio Bearer ») sur l'interface radio (étape SI 3) et une porteuse lu (ou « lu bearer ») sur l'interface « lu ». L'établissement du RAB peut alors être confirmé (étape SI 4) et le contexte PDP activé (étape SI 5), après négociation avec le 3G-GGSN (étape S1 6, SI 7).

L'étape S2 correspond essentiellement à l'établissement de la session multimédia au niveau du protocole SIP. Cette étape inclut une négociation permettant de déterminer les caractéristiques pour la session en cours d'établissement. Cette négociation inclut notamment une négociation de codées, permettant de déterminer une liste ou ensemble de codées capables d'être supportés en commun par les deux parties à l'appel et autorisés par tous les noeuds de réseau intermédiaires, pour cette session.

On rappelle que les codées déterminent, aussi bien dans les stations mobiles que dans le réseau d'accès radio (notamment dans les stations de base) ainsi que dans le coeur de réseau, comment réaliser le codage source et le codage canal nécessaires notamment à la transmission sur l'interface radio. Par exemple, pour le codage de parole, dans un système de type GSM, il existe différents types de codées: plein débit (ou FR, pour "Full Rate"), plein débit amélioré (ou EFR, pour "Enhanced Full Rate"), demi-débit (ou HR, pour "Half Rate"), ou encore AMR (pour "Adaptive Multi- Rate coding"), ce dernier étant particulièrement intéressant en ce qu'il permet d'optimiser la qualité de service (en l'occurrence en sélectionnant à chaque instant, en fonction des conditions de transmission rencontrées, une combinaison optimale d'un codage source donné et d'un codage canal donné). Deux types de codée AMR existent : le codée à bande étroite « Narrowband AMR » et le codée à bande large « Wideband AMR ». Un codée de type « Wideband AMR » offre une qualité de service encore meilleure mais nécessite des débits radio plus importants. Le cas de parole n'est bien sûr qu'un exemple des différentes composantes, ou différents flux de média, formant une session multimédia. L'étape S2 comporte essentiellement les étapes suivantes. Une fois qu'un

RB a été établi pour la signalisation SIP (au moyen de l'étape précédente SI ), une première tâche consiste pour le client SIP à découvrir son P-CSCF. Ensuite, il devra se déclarer et s'enregistrer auprès de son S-CSCF, ce qui fera appel à d'autres entités de coeur de réseau. Enfin, lors d'un établissement de session, une requête appelée « SIP Invite » est envoyée à la partie appelée via les entités P-CSCF et S-CSCF. Ce message contient un datagramme SDP qui indique pour chaque flux de média que l'UE appelant souhaite établir, un certain nombre de paramètres de média tels que : type de média, combinaison d'attributs de QoS, liste de codées capables d'être supportés pour cette session, ...etc. Les entités P-CSCF et S-CSCF associées à la partie appelante puis à la partie appelée effectuent alors un contrôle de service (selon des critères propres au réseau) sur ces paramètres. La partie appelée détermine alors entre autre sa propre liste de codées capables d'être supportés pour cette session, puis une liste de codées capables d'être supportés en commun par les deux parties, appelante et appelée, et retourne alors cette dernière liste à la partie appelante. La partie appelante détermine alors quels flux de média devraient être utilisés pour cette session, et quels codées, dans cette liste, devraient être utilisés pour cette session. L'étape S3 correspond essentiellement à une fin d'établissement de session, et comporte une étape d'allocation de ressource, à partir des caractéristiques de flux de média (en terme d'attributs de QoS, de codée négocié, etc) ainsi déterminées dans l'étape S2.

L'étape S3 utilise aussi une procédure d'activation de contexte PDP, appelée aussi procédure d'activation de contexte PDP secondaire (pour la distinguer de la procédure d'activation de contexte primaire utilisée dans l'étape SI ). L'étape S3 est semblable à l'étape SI , à ceci près que les paramètres de porteuse UMTS à établir correspondent maintenant aux besoins déterminés dans l'étape S2. L'étape S3 comporte elle-même des étapes qui sont semblables à celles de la l'étape SI , et qui pour cette raison ne seront pas re-décrites.

L'étape S3 comporte ainsi l'établissement d'un RAB pour ce contexte PDP secondaire. Lorsque ce RAB est établi, le RAN effectue un contrôle d'admission et accepte ou rejette l'appel.

On rappelle par ailleurs que, d'une manière générale, dans ces systèmes, il est nécessaire de prévoir une gestion de la qualité de service (ou QoS, pour « Quality of Service ») de manière à satisfaire les besoins des utilisateurs, en tenant compte d'une différenciation des applications et des utilisateurs, et tout en utilisant aussi efficacement que possible les ressources de transmission disponibles. D'une manière générale, chaque service est défini par des paramètres ou attributs de qualité de service (tels que le débit binaire garanti, le délai de transfert, ...etc.), l'ensemble de ces paramètres ou attributs formant un profil de qualité de service. Pour le GPRS, la gestion de la qualité de service a fait l'objet d'améliorations entre les versions R97 et R99 de la norme.

Dans la version R97 de la norme, seuls des services non temps réel peuvent être offerts aux utilisateurs. Ainsi, dans le sens montant, la station mobile peut indiquer des paramètres de QoS quand elle requiert l'établissement d'un TBF (pour « Temporary Block Flow ») dans le sens montant, en utilisant une procédure d'accès dite en deux phases. Dans le sens descendant, chaque LLC PDU reçue du SGSN contient un élément d'information appelé « QoS Profile Information Elément », donnant des informations limitées sur la qualité de service. Ces paramètres peuvent être utilisés par le BSS pour effectuer dans une certaine mesure une différenciation de services.

Dans la version R99 de la norme, une nouvelle procédure, ou procédure de création de « BSS Packet Flow Context» a été introduite, définie notamment dans les spécifications 3GPP TS 23.060 et 3GPP TS 08.18. Cette procédure autorise la négociation entre le SGSN et le BSS de tous les paramètres de QoS à offrir pour le transfert de toute LLC- PDU se rapportant au PFC (« Packet Flow Context ») ainsi créé. Le SGSN peut aggréger le transfert de LLC-PDUs correspondant à plusieurs contextes PDP donnés (ou « PDP Context », où PDP est utilisé pour « Packet Data Protocol ») dans un même PFC. Ceci est possible si les PDP Contexts aggrégés ont des contraintes de qualité de service proches. Les paramètres de QoS ainsi négociés sont ceux définis dans la version R99 et contiennent beaucoup plus d'informations que le profil de QoS défini dans la version R97. Ils contiennent en particulier toutes les variables nécessaires pour la définition d'un service temps réel.

Le contexte de PDP (ou « PDP context ») créé lors de l'établissement d'une session de données contient les informations nécessaires au transfert des données entre MS et GGSN (informations de routage, profil de QoS, ...etc.). Lorsqu'il active un contexte PDP, si la fonctionnalité PFC est implémentée dans le BSS et le SGSN, ce dernier peut requérir des paramètres de QoS du BSS qui peut négocier tout ou partie de ces paramètres en fonction de sa charge et de ses capacités. Ceci signifie que les données associées à un contexte PDP et donc à une QoS donnée sont bien identifiées non seulement dans le cœur de réseau CN mais aussi dans le réseau d'accès radio RAN. Ceci permet d'assurer que la QoS offerte pour le contexte PDP est négociée entre tous les nœuds de réseau, et il devient ainsi possible de garantir certains attributs de qualité de service. Il est ainsi possible d'obtenir qu'un débit binaire garanti ou un délai de transfert maximum soit offert, ce qui permet d'offrir des services temps réel.

Pour supporter des applications temps réel il est nécessaire que le BSS soit capable d'offrir le débit requis et aussi de transférer les LLC PDUs reçues dans les limites du délai de transfert maximum. Pour cela, il est nécessaire qu'il y ait aussi peu que possible de mise en file d'attente dans le BSS (on rappelle que la mise en file d'attente est propre au transfert utilisé dans les systèmes en mode paquet), et que les interruptions de transfert (dues notamment aux re-sélections de cellule, comme rappelé précédemment) soient aussi courtes que possible. Ceci requiert que le BSS connaisse toujours les spécifications de QoS pour le transfert de telles données, ou en d'autres termes qu'il dispose d'un contexte contenant des informations de profil de QoS associées.

Selon la procédure de création de « BSS Packet Flow Context», telle que spécifiée notamment dans le document 3GPP TS 23.060, le SGSN peut à tout moment requérir la création d'un contexte appelé « BSS Packet Flow Context » (ou PFC), notamment lors de l'activation d'un contexte PDP.

La figure 6 est un schéma destiné à illustrer un exemple de mise en œuvre d'un procédé suivant l'invention.

On notera que la présente invention couvre aussi bien le cas d'un appel reçu par la station mobile (ou « MT Call », pour « Mobile Terminating Call ») que le cas d'un appel émis par la station mobile (ou « MO Call », pour « Mobile Originating Call ») à travers le domaine paquet (ou « PS domain »). Une étape dans ces différents scénarios est l'établissement d'un canal dédié, sur création d'un PFC. Les spécifications 3GPP concernant l'IMS (23.228 et 24.228) définissent les différents flux pour l'établissement d'appel, et le but n'est pas ici de les rappeler. Dans tous les scénarios, une étape importante qui constitue plus particulièrement un des objets de la présente invention est l'étape de réservation de ressources. Dans le cas d'établissement de session MO, ceci se produit entre l'envoi des messages « Final SDP » et « Resource Réservation successful» . Dans le cas d'établissement de session MT, ceci se produit après que le message « Final SDP » ait été reçu de la partie appelante.

On suppose qu'un contexte PDP pour la signalisation SIP est établi et que le MS est dans le mode « Packet Idle Mode », lorsqu'une réservation de ressources est effectuée (si un TBF est en cours, alors le premier établissement de TBF ne sera pas effectué) .

Les étapes suivantes peuvent être mises en œuvre:

(1 ) Le MS déclenche une activation de contexte PDP secondaire pour le flux de média, dont les paramètres de QoS ont été négociés au niveau SIP. Pour cela, le

MS requiert un TBF montant (ou UL TBF, pour « Uplink TBF ») sur des canaux partagés.

(2) Lorsque le SGSN reçoit le message «ACTIVATE PDP CONTEXT REQUEST du MS, il créé le contexte PDP dans le SGSN et envoie alors un message CREATE BSS PFC sur l'interface Gb, afin de demander au BSS de réserver les ressources radio nécessaires pour le flux de média temps-réel.

(3) La QoS requise indique des caractéristiques de temps-réel. Il est ici proposé d'autoriser le BSS à allouer des ressources dédiées. Deux méthodes ou procédures sont proposées dans le cas où le BSS peut allouer de telles ressources en correspondance avec la QoS requise: ré-utiliser autant que possible les techniques existantes en envoyant un « paging » au MS, ou introduire un nouveau message d'allocation. On peut noter qu'à ce stade le MS est nécessairement dans l'état GMM READY puisqu'une LLC PDU dans le sens montant vient d'être envoyée, contenant le message ACTIVATE PDP CONTEXT REQUEST. (3a) Dans une première procédure, le BSS génère un « paging » vers le MS.

Dans l'état actuel de la norme pour le mode A /Gb, un MS peut recevoir un « CS paging » (ou « paging » pour services en mode circuit) seulement si ce « CS paging » est reçu du MSC. Il est ici proposé que le BSS génère un « paging » pour des services temps-réel après avoir reçu une requête du SGSN. Suivant l'état radio du MS, le message de « paging » peut être envoyé soit sur des canaux de contrôle communs soit sur le PACCH d'un TBF en cours. Ceci serait similaire à un « CS paging », avec l'exception qu'une indication serait présente pour indiquer que ce « paging » vient du domaine PS (« Packet Switched ») ou mode paquet. Si un ou plusieurs TBF étaient en cours, le MS retournera aux canaux de contrôle communs et initiera une procédure d'accès aléatoire (« random access ») en demandant des ressources dédiées (une autre option consisterait en une amélioration des procédures de DTM (« Dual Transfer Mode ») de manière à autoriser le MS à initier un accès dédié à travers le PACCH d'un TBF en cours). Le BSS allouera alors des ressources dédiées et le MS établira le lien de signalisation de couche 2.

Il est aussi proposé de demander à la station mobile MS d'envoyer un message GPRS INFORMATION contenant l'identifiant TLLI (« Temporary Logical Link Identifier ») propre à la station mobile MS. Ce message peut aussi contenir une trame LLC vide superposée (« piggybacked » en anglais) au message SABM. Le TLLI sera renvoyé au BSS, de sorte que le BSS peut associer la connexion nouvellement établie à la requête reçue dans le message CREATE BSS PFC. Dans le cas où les ressources allouées ne correspondent pas à la QoS requise, un « handover » intracellulaire peut être effectué pour allouer des ressources en correspondance avec la requête reçue du SGSN (ou en correspondance avec la QoS négociée avec le SGSN) si de telles ressources sont disponibles. Le message GPRS INFORMATION peut être envoyé sur le canal dédié DCCH (« Dedicated Control Channel ») une fois établi. On note que tout autre message contenant le TLLI du MS peut être utilisé.

(3b) Dans une seconde procédure, on alloue directement au MS des resources dédiées : un nouveau message pourrait être introduit, évitant le besoin d'avoir à envoyer un « paging » au MS. Le BSS allouerait alors directement les ressources dédiées, à travers un nouveau message envoyé sur les canaux de contrôle communs (MS dans le mode « Packet Idle Mode ») ou sur le PACCH d'un TBF en cors (MS dans le mode « Packet Transfer Mode »). Le MS activera alors les nouvelles ressources (éventuellement en basculant vers le mode « RR Dual Transfer Mode » si un ou plsieurs TBF étaient en cours) et établira le lien de signalisation de couche 2. Comme dans la première procédure, le MS enverra un message GPRS INFORMATION contenant le TLLI, qui sera renvoyé au BSS . Dans ce cas, les ressources allouées devraient être en correspondance avec la QoS requise. (4) Le BSS envoie alors un acquittement au SGSN pour la création du PFC. Il est à noter que dans le cas où le BSS ne pourrait allouer des ressources permettant de réaliser la QoS requise, il peut tout d'abord essayer de négocier les paramètres de QoS, et si la négociation réussit, il peut alors effectuer l'établissement des canaux dédiés.

(5) L'activation de contexte PDP est alors terminée (à travers l'établissement d'un TBF, ou en utilisant le message GPRS INFORMATION, ou en utilisant un TBF existant s'il est toujours en cours),

(6) L'établissement de l'appel peut alors être terminé au niveau SIP.

Lorsque la session a commencé, les PDU temps-réel sont routées comme suit: dans le sens réseau vers MS : GGSN -> SGSN (Interface « Gn »), SGSN ->BSC (interface « Gb ») , BSC- BTS (Interface Abis), BTS -» MS

(Interface radio) dans le sens MS vers réseau : MS -> BTS (Interface radio), BTS -> BSC

(Interface « Abis »), BSC - SGSN (Interface « Gb »), SGSN ^•» GGSN

(Interface « Gn ») Sur les interfaces « Gb » et « Gn » les PDUs sont routées comme des paquets. Sur les interfaces « Abis » et radio, les PDUs sont transportées sur des canaux dédiés.

Pendant le flux temps réel, les mesures radio reportées sont envoyés du MS au BSS sur le SACCH existant. Sur la base de ces mesures radio reportées, le BSS peut effectuer des « handovers » en utilisant les mécanismes existants. Sur la figure 6 : l'étape 61 indique que l'établissement d'un appel est en cours pour un flux de média temps réel, le « Final SDP » vient d'être envoyé (dans le cas MO) ou reçu (dans le cas MT), - l'étape 62 indique qu"un contexte PDP secondaire est créé dans le

SGSN, l'étape 63 indique que le BSS a reçu une requête « PFC Création Request » pour un flux temps réel, il établit des ressources dédiées, l'étape 64 indique que le MS active les ressources dédiées allouées, - l'étape 65 indique qu'un fonctionnement en multi-trame est maintenant établi, la contention est résolue, et le BSS connaît le TLLI de la nouvelle connexion. Un « handover » est effectué si nécessaire, l'étape 66 indique que l'établissement d'appel SIP peut alors se produire, l'option correspondant à la première procédure indiquée plus haut a été notée 67 - l'option correspondant à la seconde procédure indiquée plus haut a été notée 68. Les différents messages notés sur la figure 6 : (P)RACH, PACKET UPUNK ASSIGNMENT, ACTIVATE PDP CONTEXT REQUEST (secondary PDP context), CREATE BSS PFC, CS PAGING (from the PS domain), IMMEDIATE ASSIGNMENT, SABM + GPRS INFORMATION, UA + GPRS INFORMATION, CREATE BSS PFC ACK , ACTIVATE PDP CONTEXT ACCEPT, ont été soit rappelés soit définis précédemment. Eventuellement, pour plus d'informations sur les messages ou procédures existants on pourra se reporter aux spécifications correspondantes, pour ces systèmes).

On notera que l'exemple ainsi décrit ne constitue qu'un des exemples possibles de mise en œuvre de l'invention. On comprendra qu'il n'est pas possible de décrire ici tous les exemples de mise en œuvre possibles, et que la présente invention est bien sûr d'application générale, et n'est pas limitée à cet exemple particulier.

Un des avantages de l'invention est que les procédures ou protocoles existants sont ré-utilisés. Notamment, il n'y a pas besoin d'introduire une nouvelle combinaison de canal, ni un « handover » de TBF. Les impacts sur une station mobile selon la version R99 de la norme supportant le mode DTM (« Dual Transfer Mode ») sont réduits à un minimum (le contexte PDP pour lequel un canal dédié est alloué doit être indiqué à la station mobile). Il n'y a pas besoin de définir une nouvelle couche de protocole au-dessus de la couche RLC/MAC puisque la couche RR au-dessus de

LAPDm peut être ré-utilisée. Toute la signalisation peut être effectuée à travers les canaux existants SACCH et FACCH. Ceci n'empêche pas d'améliorer les procédures

DTM existantes pour supporter des « handovers » simultanés de trafic temps réel transporté dans des canaux dédiés et de trafic non temps réel transporté dans des canaux partagés. Notamment l'invention permet d'introduire un support pour des services IMS dans le mode « A/Gb » du réseau GERAN à un coût minimum.

Claims

REVENDICATIONS

1 . Procédé pour supporter du trafic temps réel dans un système de radiocommunications mobiles comportant un réseau d'accès radio et un cœur de réseau, procédé dans lequel du trafic en temps réel supporté en mode paquet dans le coeur de réseau est supporté dans le réseau d'accès radio au moyen d'une allocation de canaux dédiés.

2. Procédé selon la revendication 1 , dans lequel ladite allocation de canaux dédiés est effectuée à la création d'un contexte de flux paquet (PFC).

3. Procédé selon la revendication 2, dans lequel ledit contexte de flux paquet est crée dans le réseau d'accès radio.

4. Procédé selon la revendication 3, dans lequel ledit contexte de flux paquet contient des paramètres de QoS à offrir par le réseau d'accès radio et négociés avec le cœur de réseau.

5. Procédé selon l'une des revendications 1 à 4, dans lequel ledit trafic temps réel correspond à au moins un flux de média d'une session multimédia.

6. Procédé selon l'une des revendications 1 à 5, dans lequel ladite allocation de canaux dédiés utilise une procédure d'allocation comportant un « paging » suivi d'un accès au réseau.

7. Procédé selon l'une des revendications 1 à 5, dans lequel ladite allocation de canaux dédiés utilise une procédure d'allocation directe.

8. Procédé selon l'une des revendications 1 à 7, dans lequel : une station mobile à laquelle des canaux dédiés ont ainsi été alloués transmet au réseau des informations relatives à son identité, sur la base de ces informations, le réseau associe un contexte de flux paquet à cette station mobile, et , le cas échéant, une ré-allocation de canaux dédiés est effectuée en vue de satisfaire la qualité de service requise pour cette station mobile.

9. Equipement de réseau d'accès radio pour système de radiocommunications mobiles, comportant des moyens pour mettre en œuvre un procédé selon l'une des revendications 1 à 8.

10. Equipement de cœur de réseau pour système de radiocommunications mobiles, comportant des moyens pour mettre en œuvre un procédé selon l'une des revendications 1 à 8.

1 1 . Station mobile pour système de radiocommunications mobiles, comportant des moyens pour mettre en œuvre un procédé selon l'une des revendications 1 à 8.