Brevet FR2840758A1 — publié le 20031212

PROCEDE POUR SUPPORTER DU TRAFIC TEMPS REEL DANS UN SYSTEME DE RADIOCOMMUNICATIONS MOBILES La presente invention concerne d'une maniere generale les systemes de radiocommunications mobiles. D'une maniere genera le. ces systemes font ['objet de norma lisation, et pour plus d'informations on pourra se referer aux normes correspondantes, publiees par les organismes de normalisation correspondants. D'une maniere generale, dans ces systemes, on peut distinguer differents types de services, en fonction de la qualite de service requise. Notamment, on peut distinguer des services temps reel, correspondant a du trafic sensible aux delais de transfert (tel que notamment la voix, ou encore du trafic a flux continu ou ), et des services non temps reel, correspondant a du trafic non sensible aux delais de transfert (tel que notamment le transfert de donnees). D'une maniere generale, dans ces systemes, on peut aussi distinguer differents types de services, selon les techniques utilisees pour les supporter. On peut ainsi distinguer les services en mode circuit et les services en mode paquet. En mode circuit, le trafic est transporte dans des ressources ou canaux dedies alloues en permanence a un utilisateur pour la duree d'un appel. En mode paquet, le trafic est transporte dans des ressources ou canaux partages entre plusieurs utilisateurs. Le mode circuit permet ainsi de garantir les delais de transfert pour chaque utilisateur, mais ne permet pas une utilisation efficace des ressources disponibles pour ['ensemble des utilisateurs. Au contraire, le mode paquet permet une utilisation efficace de ['ensemble des ressources disponibles, mais ne permet pas de garantir les delais de transfert. Le mode circuit et le mode paquet se differencient non seulement par des techniques differentes d'allocation de ressources, mais aussi par des architectures de protocoles differentes. Les systemes de deuxieme generation, de type GSM ( ) ont plutot ete concus initialement pour supporter du trafic temps reel (essentiellement de la voix) en mode circuit. Des fonctionnalites supplementaires ont ensuite ete introduites dans ces systemes, correspondant a la fonctionnalite GPRS ( >), pour leur permettre de supporter du trafic non temps reel en mode paquet. 1 04782/MA/NMND F:\Salle\F1 04782\PREMDEP\FIT\projetbr.doc L'architecture generale des systemes de radiocommunications mobiles est rappelee sur la figure 1, elle comporte essentiellement: - un reseau d'acces radio 1, ou RAN (pour >J. - un ccaur de reseau 4, ou CN (pour >). Dans cette architecture generale, le RAN est forme de stations de base 2 et de controleurs de stations de base 3. II est en relation d'une part avec des terminaux mobiles via une interface 6 appelee aussi interface radio, et d'autre part avec le CN 4 via une interface 7. Le CN 4 est en relation avec des reseaux exterieurs, non illustres specifiquement, tels que PSTN ( ), PDN ( ),...etc. L'architecture generate des systemes de deuxieme generation de type GSM est rappelee sur la figure 2. Dans ces systemes, le RAN est appele BSS ("Base Station Subsystem"), les stations de base vent appelees BTS ("Base Transceiver Station"), les controleurs de stations de base vent appeles BSC ("Base Station Controller"), et les terminaux mobiles vent appeles MS ( ). Les fonctionnalites propres aux services en mode paquet vent en general supportees par une entite particuliere appelee PCU ( ), non illustree specifiquement, prevue en general dans le BSS. Dans les systemes de deuxieme generation de type GSM, le CN comporte: pour le mode circuit, des entites de type 2G-MSC (ou 2G est utilise pour > et MSC est utilise pour ) , - pour le mode paquet, des entites de type 2G-SGSN (ou 2G est utilise pour , et SGSN est utilise pour ). Ainsi, dans les systemes de deuxieme generation de type GSM, I'interface 7 comporte une interface appelee interface > vers les entites de type 2G-MSC, et une interface appelee interface > vers les entites de type 2G-SGSN. Les systemes de type GERAN ( >, ou EDGE est utilise pour ) correspondent a des evolutions des systemes de type GSM, visant a offrir des services de troisieme generation, aussi bien pour des applications temps reel que pour des applications non temps reel. Le but est notamment de pouvoir supporter des services de type IMS ( >,ou IP est utilise pour >). 104782/MA/NMND F:\Salle\F104782\PREMDEP\Fll\projetbr.doc Pour cela, il a initialement ete propose d'aligner les services offerts par les systemes de type GERAN sur ceux offerts par les systemes de troisieme generation de type UMTS ( >) en connectant des BSS de type GERAN au CN 3G via les interfaces lu, lesdites interfaces etant utilisees pour connecter l'UTRAN (pour ), et les terminaux mobiles vent appeles UE ( Equipment >). Dans les sytemes de troisieme generation de type UMTS, le CN comporte: pour le mode circuit, des entites de type 3G-MSC (ou 3G est utilise pour et MSC est utilise pour ) , - pour le mode paquet, des entites de type 3G-SGSN (ou 3G est utilise pour > et SGSN est utilise pour ). Ainsi, dans les systemes de troisieme generation de type UMTS, I'interface 7 comporte une interface appelee interface > vers les entites de type 3G-MSC, et une interface appelee interface > vers les entites de type 3G-SGSN. L'architecture initialement proposee pour les sytemes de type GSM/GERAN est rappelee sur la figure 4. II a ainsi ete propose diintroduire dans les systemes de type GSM/GERAN, en plus des interfaces > et > existantes, une interface de type vers des entites de type 3GMSC et une interface de type des entites de type 3G-SGSN. Cependant, il est maintenant reconnu qu'une telle approche necessite des adaptations complexes et couteuses, notamment dans les protocoles radio de couches 2 et 3. C'est pourquoi une autre approche a maintenant ete proposee, qui consiste a supporter les memes services que ceux supportes au moyen des interfaces Nu CS >>, ' mais au moyen des interfaces existantes >, . Le but est notamment de pouvoir supporter des services de type IMS ( system >>) via ['interface . Pour memoire, aujourd'hui ['interface > est seulement capable de supporter des services non temps reel (eventuellement du trafic 1 04782/MA/NMND F:\Salle\F1 04782\PREMDEP\Fll\projetbr.doc a flux continu ou ), et des services temps reel peuvent seulement etre supportes via ['interface . D' une ma niere g enerale, cette derriere a pproche i ncl ut les a meliorations suivantes, en vue de faire evoluer le mode dit > vers un mode dit : - flux de donnees multiples et en parallele entre BSS et MS, - transfert intercellulaire (ou ) pour des services temps reel en mode paquet, - support de services temps reel par la partie radio (ou RAN), - support de services temps reel par la partie reseau (ou CN), - support de services IMS, - amelioration des mecanismes de securite. Jusqu'a present, la seule proposition pour le support de services temps reel en mode paquet sur ['interface > a ete de prevoir un transfert intercellulaire ou > pour les services en mode paquet. On rappelle que les procedures de transfert interceilulaire ou > vent propres au mode circuit. Selon ces procedures, des ressources vent reservees dans une nouvelle cellule alors qu'une station mobile est encore connectee a une ancienne cellule, ce qui permet, au prix d'une certaine complexite, de garantir les delais de transfert. Au contraire, les procedures de re-selection de cellule vent propres au mode paquet. Selon ces procedures, des ressources ne vent allouees a une station mobile dans une nouvelle cellule que lorsque la station mobile est connectee a la nouvelle cellule, ce qui simplifie les procedures mais ne garantit pas les delais de transfert. La proposition mentionnee ci-dessus permet d'introduire pour le mode paquet des mecanismes similaires a ceux utilises dans les procedures de transfert intercellulaire ou > pour ie mode circuit. De plus, des procedures ont ete proposees pour permettre a une station mobile de reporter regulierement des mesures radio au reseau en vue de permettre a ce dernier de selectionner une nouvelle cell ule, comme dans le mode circuit. Pour cela, une nouvel le combinaison de canaux sur ['interface radio a ete proposee, notamment dans le document . Cette nouvelle combinaison consiste en un canal alloue pour un transfert de donnees en mode paquet, ou canal PDTCH ( ) et en un canal de signalisation dedie en mode circuit ou canal SACCH 1 04782/MA/NMND F:\Salle\F1 04782\PREMDEP\FlI\projetbr.doc ( ), ce dernier canal eta nt utilise pour un tel report de mesures radio de la station mobile vers le reseau. Ainsi q ue l'a observe le demandeur, une tel le proposition a notamment les inconvenients suivants: - la station de base BTS et la station mobile MS doivent supporter une nouvelle combinaison de canaux, - I'entite PCU (dans laquelle vent mises en ceuvre les fonctionnalites propres au mode paquet) doit traiter des reports de mesures et implementer des algorithmes de transfert intercellulaire ou >, - une nouvelle procedure doit etre introduite sur ['interface radio pour supporter cette nouvelle combinaison, - des problemes se posent au niveau de ['architecture de ces systemes puisque le SACCH utiliserait un protocole de type LAPDm ( ) comme protocole de couche 2 alors que le canal de signalisation associe au canal PDTCH, ou canal PACCH ( ), utilise un protocole de type RLC/MAC, ces deux protocoles se terminant dans des nceuds de reseau differents (BTS pour LAPDm, PCU pour RLC/MAC). Par ailleurs, le canal PDTCH est un canal uni-directionnel alors que les services temps reel tendent a requerir des canaux bi-directionnels. Meme pour du trafic a flux continu ou >, qui est prinicipalement une application uni- directionnelle, il semble difficile d'allouer le sens retour a d'autres utilisateurs, puisque ces utilisateurs genereraient tres vraisemblablement du trafic dans l'autre direction, d'ou une preemption de resources pour du trafic de > d'une maniere inacceptable. La presente invention a notamment pour but de proposer une autre approche pour le support de services temps reel sur une interface de type >, permettant notamment d'eviter tout ou partie des inconvenients mentionnes precedemment, ou encore necessitant tres peu d'adaptations par rapport aux architectures existantes. Un des objets de la presente invention est un procede pour supporter du trafic temps reel dans un systeme de radiocommunications mobiles comportant un reseau d'acces radio et un cceur de reseau, ce procede eta nt essentiellement tel que 1 04782/MA/NMND F:\Salle\F1 04782\PREMDEP\FIT\projetbr doc du trafic temps reel supporte en mode paquet dans le coeur de reseau est supporte en mode circuit dans le reseau d'acces radio. Suiva nt une autre caracteristiq ue, led it support de trafic temps reel en mode circuit dans le reseau d'acces radio inclut une allocation de canaux dedies, ladite allocation de canaux dedies etant effectuee a la creation d'un contexte de flux paquet (PFC). Suivant une autre caracteristique, ledit contexte de flux paquet est cree dans le reseau d'acces radio. Suivant une autre caracteristique, ledit contexte de flux paquet contient des parametres de QoS a offrir par le reseau d'acces radio et negocies avec le cceur de reseau. Suivant une autre caracteristique, ledit trafic temps reel correspond a au moins un flux de media diune session multimedia. Suivant une autre caracteristique, ladite allocation de canaux dedies utilise une procedure d'allocation comportant un > suivi d'un acces au reseau. Suivant une autre caracteristique, ladite allocation de canaux dedies utilise une procedure d'allocation directe. Suivant une autre caracteristique: - une station mobile a laquelle des canaux dedies ont ainsi ete alloues transmet au reseau des informations relatives a son identite, - sur la base de ces informations, le reseau associe un contexte de flux paquet a cette station mobile, et, le cas echeant, une re-allocation de canaux dedies est effectuee en vue de satisfaire la qualite de service requise pour cette station mobile. Un autre objet de la presente invention est un equipement de reseau d'acces radio pour systeme de radiocommunications mobiles, comportant des moyens pour mettre en couvre un tel procede. Un autre objet de la presente invention est un equipement de ccour de reseau pour systeme de radiocommunications mobiles, comportant des moyens pour mettre en ceuvre un tel procede. Un autre objet de la presente invention est une station mobile pour systeme de radiocommunications mobiles, comportant des moyens pour mettre en couvre un tel procede. 104 782/MA/NMN D F:\Sal le\F 104 782\PREMD EP\FI1\proj etbr. doc D'autres objets et caracteristiques de la presente invention appara'^tront a la lecture de la description suivante d'un exemple de realisation, faite en relation avec les dessins ci-annexes dans lesquels: - la figure l est un schema destine a rappeler ['architecture generale d'un systeme de radiocommunications mobiles, - la figure 2 est un schema destine a rappeler ['architecture generale d'un systeme de deuxieme generation de type GSM, - la figure 3 est un schema destine a rappeler ['architecture generale d'un systeme de troisieme generation de type UMTS, - la figure 4 est un schema destine a rappeler une architecture generale proposee initialement pour un systeme de type GERAN, - les figures 5a et 5b vent des schemas destines a illustrer, par comparaison, I'evolution proposee par la presente invention pour ['architecture generale d'un systeme de type GERAN, - la figure 6 est un schema destine a illustrer un exemple de mise en ceuvre d'un procede suivant ['invention. La presente invention suggere d'utiliser les canaux et protocoles radio existants, utilises pour les services temps reel lorsque ceux-ci vent relayes via le MSC. Au lieu diutiliser des canaux partages (ou a shared channels >>) pour echanger des unites de donnees ou PDUs (a Packet Data unit >>) de/vers le SGSN, I'idee est d'utiliser des canaux dedies (ou a dedicated channels >>) . Si des services temps reel et non temps reel doivent etre supportes simultanement, les procedures DTM (a Dual Transfer Mode >>) existantes peuvent etre utilisees pour controler ltetablissement et le reldchement des differents flux de donnees. On rappel le brievement q ue la fonctionnalite DTM est une fonctionnalite permettant de supporter simultanement les deux types de services (en mode circuit et en mode paquet), pour les stations mobiles pouvant supporter simultanement ces deux types de services, en prevoyant une coordination par le BSS des ressources necessaires a chacun des modes. Pour une description detaillee de cette fonctionnalite, on pourra aussi se referer aux specifications correspondantes publiees par les organismes de normalisation. L'evolution proposee selon ['invention peut etre il l ustree pa r com pa raison des figures 5a et 5b. Les equipements illustres sur les figures 5a et 5b vent ceux deja 1 04782/MA/NMND F:\Salle\F1 04782\PREbADEP\FIT\projetbr.doc presentes en relation avec la figure 2, a savoir BTS, BSC, MSC (ou 2G-MSC), SGSN (ou 2G-SGSN); de plus, la connexion entre un MSC et un reseau exterieur de type PSTN, via une entite de type G-MSC ( ) a ete illustree sur les figures a et 5b; de meme la connexion entre un SGSN et un reseau exterieur de type PDN, via une entite de type GGSN ( ) a ete illustree. Les interfaces > entre BTS et BSC, > entre SGSN et GGSN, et > entre GGSN et PDN ont egalement ete illustrees. Le but etant notamment de pouvoir supporter des services de type IMS, dans la figure 5b, PDN a ete remplace par IMS. La figure 5a correspond a une architecture classique, dans laquelle les services temps reel relayes via un MSC vent transportes via des canaux dedies sur ['interface radio. La figure 5b correspond a une architecture selon ['invention, dans laquelle les services temps reel relayes via un SGSN vent transportes via des canaux dedies sur ['interface radio. Dans ['architecture GSM existante, il est prevu deux types d'unites pour traiter les deux types d'appels, en mode circuit et en mode paquet. Ces deux types d'unites peuvent ou non Gtre integrees physiquement dans un meme equipement. L'unite chargee de traiter les appels en mode paquet, ou PCU ( Unit >) est en general prevue dans le BSS. Ainsi, genera lement, il y a da ns le BSS une unite con nectee a ['i nterface > et qui traite les appels en mode circuit, et une autre unite connectee a ['interface > et qui traite les appels en mode paquet. Les appels en mode circuit vent transportes au moyen de canaux dedies, c'est-a-dire alloues en permanence pour la duree de l'appel, alors que les appels en mode paquet vent transportes au moyen de canaux partages, ctest-a-dire partages avec d'autres utilisateurs. L'invention propose de supporter des services temps reel dans ['unite connectee a ['interface > a travers les fonctions suivantes: support de re-localisation de lien ' lorsque la station mobile change de cellule et lorsque la nouvelle cellule est controlee par un BSS different du BSS controlant l'ancienne cellule, et lorsqu'une session temps reel est en cours a travers ['interface >, 104782/MA/NtAND F \Solle\F104782\PREMDEP\FIT\projelbr.doc - support de procedure de PFC ( ) pour negocier les parametres de QoS avec le SGSN lors d'une activation/modification de contexte PDP, - Lorsqu'un PFC est cree/modifie pour un flux de donnees temps reel, I'unite connectee a ['interface > declenche l'etablissement/modification d'un canal dedie, - les unites de donnees temps reel recues de/vers ['interface >>Gb >> vent transportees sur ['interface radio au moyen de canaux dedies, lorsqutun > est requis, les procedures et mecanismes existants definis pour les canaux dedies vent utilises; la seule difference est que le MSC n'est pas informe; au lieu de cela, I'unite connectee a ['interface > est informee, et assure si necessaire une re-localisation de lien >. Avant de decrire un exemple de mise en couvre de la presente invention, on rappelle tout d'abord les protocoles ou procedures propres aux systemes en mode paquet, ou aux architectures de type IMS, dans la mesure ou ils peuvent etre utiles a la description de cet exemple. Selon ['architecture en couches utilisee pour decrire les systemes en mode paquet, notamment de type GSM/GPRS, on distingue, sur ['interface radio entre MS et BSS: - une premiere couche, ou couche physique, - une deuxieme couche, ou couche liaison, elle-meme divisee en plusieurs couches: par ordre de niveaux croissants, MAC (pour > en anglais), RLC (pour > en anglais) et LLC (pour > en anglais). De meme, on distingue, sur ['interface > entre BSS et SGSN: - une premiere couche, ou couche physique, - une deuxieme couche, ou couche liaison, elle-meme divisee en plusieurs couches: par ordre de niveaux croissants, > (en anglais), BSSGP (pour > en anglais), et LLC (pour Link Control >> en anglais). Des frames appelees frames LLC (ou > en anglais) vent formees, dans la couche LLC, a partir d'unites de donnees rec,ues d'un niveau 104782/MA/NMND F:\Sa11e\F104782\PREMDEP\Fll\projetbr.doc superieur, ou couche reseau, via une couche d'adaptation ou SNDCP ( ). Dans les frames LLC ces unites de donnees vent appelees unites de donnees LLC-PDU (pour ). Les unites de donnees LLC-PDU vent ensuite segmentees dans la couche RLC/MAC, de maniere a former des blocs appeles blocs de donnees RLC (ou ). Les blocs de donnees RLC vent ensuite mis au format requis pour transmission sur ['interface radio, dans la couche physique. En outre, des protocoles de signalisation vent prevus, notamment pour la gestion des ressources radio ou RR ( ), la gestion de la mobilite ou MM ( ), la gestion de session ou SM ( Managemenh>), le contrGle de lien logique ou LL ( ) ,...etc. On rappelle aussi que, selon le protocole de gestion de ressources radio, differents modes vent possibles pour une station mobile, en mode paquet: un mode dit >, dans loquel des ressources vent allouees temporairement, lorsque des donnees vent effectivement a transmettre au cours d'une communication, ces ressources formant un canal virtuel temporaire ou TBF ( ) permettant un transfert de donnees entre station mobile et reseau, pour un sens de transmission donne, - un mode dit >, dans lequel aucun TBF ntest etabli. Par opposition, en mode circuit, le mode dans lequel des ressources vent allouees a une station mobile est appele >, ces ressources etant alors des ressources dediees allouees a la station mobile pour lo duree de la communication. Dans le cas ou a la fois des ressources dediees et des ressources partagees vent allouees a la station mobile en meme temps, ladite station mobile se trouve en a dual transfer mode >. A sa mise en marche, une station mobile est aussi cite en mode veille, ou . En outre, selon le protocole de gestion de mobilite, on definit une procedure cite d" > (ou ), permettant a une station mobile de passer du mode > a un mode dit > (ou ), dans lequel elle peut acceder a des services GPRS. On definit aussi la procedure inverse de . 104782/MA/NMND F \Salle\F104782\PREMDEP\FlI\projellr.doc Une station mobile en mode veille et non attachee GPRS communique avec le reseau par l'intermediaire d'echanges de signalisation sur des canaux appeles CCCH ( >). Une station mobile attachee GPRS et en mode > communique avec le reseau par l'intermediaire d'echanges de signalisation sur des canaux appeles PCCCH ( ) si de tels ca na ux vent prevus da ns la cell ule consideree, sinon par les canaux CCCH. Une station mobile attachee GPRS et dans le mode > communique avec le reseau par l'intermediaire d'echanges de signalisation sur des canaux appeles PDCH ( ). On rappelle que le canal de donnees PDCH inclut un canal de trafic ou PDTCH ( ), et un canal de signalisation ou PACCH ( ). On rappelle aussi que le canal CCCH inclut lui-meme un certain nombre de canaux tels que notamment un canal PCH ( ). De meme le canal PCCCH inclut lui-meme un certain nombre de canaux tels que notamment un canal PPCH ( ). On rappelle aussi que lorsqu'une session doit Gtre etablie dans un systeme tel que le GPRS, une procedure d'activation contextuelle de protocole de donnees en mode paquet (ou PDP, pour ) doit etre lancee. Le contexte de PDP (ou ) contient les informations necessaires au transfert des donnees 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 controle de session d'appel multimedia a jusqu'a present ete definie pour des technologies de type UMTS. Une tel le signalisation comporte ainsi typiquement I'etablissement d'une connexion RRC entre une station mobile et un RAN, suivi de l'etablissement d'une porteuse UMTS pour transporter la signalisation relative au protocole SIP. Le protocole RRC, pour > est defini dans la norme 3GPP TS 25.331. Le protocole SIP ( ) ainsi que le protocole SDP ( ) qui lui est iie ont ete definis par l'IETF ( ) qui est l'organisme de normalisation pour le protocole Internet, ou IP (pour ). Les principales etapes d'une telle signalisation vent les suivantes, notees S1, S2, S3. Pour simplifier, on ne considere ici qu'un des trots segments en lesquels se 1 04782/MA/NMND F:\Salle\F1 04782\PREMDEP\FIT\projetbr.doc decompose le contrble de session d'appel, en ['occurrence le segment qui va de l'UE appelant a son S-CSCF, les deux autres segments etant le segment qui va de l'UE appele a son S-CSCF, et le segment qui relic les S-CSCF de l'UE appelant et de l'UE appele. On rappelle que les entites S-CSCF ( ) et P-CSCF ( ) vent des entites du reseau de cceur, en charge du contrble de sessions d'appels multimedia. L'etape S1 correspond essentiellement a une etape preliminaire a l'etablissement de session. L'etape S1 utilise une procedure cite d'activation de contexte de protocole de donnees en mode paquet, ou contexte PDP (ou >, pour ), necessaire au transport de signalisation de contrble de session multimedia. On rappelle qu'un contexte PDP comporte un ensemble de parametres de porteuse UMTS, tels que notamment des parametres de qualite de service, ou QoS (pour >),...etc. Cette etape sera suivie ulterieurement d'une autre procedure d'activation de contexte PDP, necessaire au transport des donnees liees a la session multimedia elle-mame. Ces deux contextes PDP concernant la mame adresse IP, I'etape S1 sera aussi appelee procedure d'activation de contexte PDP primaire. L'etape S1 comporte elle-mOme essentiellement les etapes suivantes. Dans une etape S11, une requdte d'activation de contexte PDP est transmise de l'UE au RAN, avec les parametres correspondants de qualite de service de bout en bout (ou ) pour la porteuse UMTS de signalisation de niveau SIP. Dans une etape S12, le 3G-SGSN commande l'etablissement d'une porteuse d'acces radio (ou RAB, ou >) de sorte qutun support soit disponible entre UE et 3G-SGSN, repondant aux contraintes de qualite de service. Lorsque le RAN recoit une telle requbte, apres un controle d'admission d'appel, il etablit uneporteuse radio (ou RB, ou ) sur ['interface radio (etape S13) et une porteuse lu (ou >) sur ['interface . L'etablissement du RAB peut alors btre confirme (etape S14) et le contexte PDP active (etape S15), apres negociation avec le 3G-GGSN (etape S16, S17). L'etape S2 correspond essentiellement a l'etablissement de la session multimedia au niveau du protocole SIP. Cette etape inclut une negociation permettant de determiner les caracteristiques pour la session en cours d'etablissement. Cette 1 04782/MA/NMND F:\Salle\F1 04782\PREMDEP\Fll\projetbr.doc negociation inclut notamment une negociation de codecs, permettant de determiner une liste ou ensemble de codecs capables d'etre supportes en commun par les deux parties a l'appel et autorises par tous les noeuds de reseau intermediaires, pour cette session. On rappelle que les codecs determinant, aussi bien dans les stations mobiles que dans le reseau d'acces radio (notamment dans les stations de base) ainsi que dans le cocur de reseau, comment realiser le codage source et le codage canal necessaires notamment a la transmission sur ['interface radio. Par exemple, pour le codage de parole, dans un systeme de type GSM, il existe differents types de codecs: plein debit (ou FR, pour "Full Rate"), plein debit ameliore (ou EFR, pour "Enhanced Full Rate"), demi-debit (ou HR, pour "Half Rate"), ou encore AMR (pour "Adaptive Multi Rate coding"), ce dernier etant particulierement interessant en ce qu'il permet d'optimiser la qualite de service (en ['occurrence en selectionnant a chaque instant, en fonction des conditions de transmission rencontrees, une combinaison optimale d'un codage source donne et diun codage canal donne). Deux types de codec AMR existent: le codec a bande etroite > et le codec a bande large . Un codec de type > offre une qualite de service encore meilleure mais necessite des debits radio plus importants. Le cas de parole n'est bien sur qu'un exemple des differentes composantes, ou differents flux de media, formant une session multimedia. L'etape S2 comporte essentiellement les etapes suivantes. Une fois qu'un RB a ete etabli pour la signalisation SIP (au moyen de l'etape precedente S1), une premiere tOche consiste pour le client SIP a decouvrir son PCSCF. Ensuite, il devra se declarer et stenregistrer aupres de son S-CSCF, ce qui fera appel a d'autres entites de coeur de reseau. Enfin, lors d'un etablissement de session, une requete appelee est envoyee a la partie appelee via les entites P-CSCF et S-CSCF. Ce message contient un datagramme SDP qui indique pour chaque flux de media que l'UE appelant souhaite etablir, un certain nombre de parametres de media tels que: type de media, combinaison d'attributs de QoS, liste de codecs capables d'etre supportes pour cette session,...etc. Les entites P-CSCF et S-CSCF associees a la partie appelante puis a la partie appelee effectuent alors un controle de service (selon des criteres propres au reseau) sur ces parametres. La partie appelee determine alors entre autre sa propre liste de codecs capables d'etre supportes pour 1 04782/MA/NMND F \Salle\F1 04782\PREMDEP\FIT\projetbr.doc cette session, puis une liste de codecs capables d'etre supportes en commun par les deux parties, appelante et appelee, et retourne alors cette derriere liste a la partie appelante. La partie appelante determine alors quels flux de media devraient etre utilises pour cette session, et quels codecs, dans cette liste, devraient etre utilises pour cette session. L'etape S3 correspond essentiellement a une fin d'etablissement de session, et comporte une etape d'allocation de ressource, a partir des caracteristiques de flux de media (en terme d'attributs de QoS, de codec negocie, etc) ainsi determinees dans l'etape S2. L'etape S3 utilise aussi une procedure d'activation de contexte PDP, appelee aussi procedure d'activation de contexte PDP secondaire (pour la distinguer de la procedure d'activation de contexte primaire utilisee dans l'etape S1). L'etape S3 est semblable a l'etape Sl, a ceci pres que les parametres de porteuse UMTS a etablir correspondent maintenant aux besoins determines dans l'etape S2. L'etape S3 comporte elle-meme des eta pes qui vent semblables a celles de la l'etape Sl, et qui pour cette raison ne seront pas re-decrites. L'etape S3 comporte ainsi l'etablissement d'un RAB pour ce contexte PDP secondaire. Lorsque ce RAB est etabli, le RAN effectue un controle d'admission et accepte ou rejette l'appel. On rappelle par ailleurs que, d'une maniere generale, dans ces systemes, il est necessaire de prevoir une gestion de la qualite de service (ou QoS, pour >) de maniere a satisfaire les besoins des utilisateurs, en tenant compte d'une differenciation des applications et des utilisateurs, et tout en utilisant aussi efficacement que possible les ressources de transmission disponibles. D'une maniere generale, chaque service est defini par des parametres ou attributs de qualite de service (tels que le debit binaire garanti, le delai de transfert, etc.), I'ensemble de ces parametres ou attributs formant un profil de qualite de service. Pour le GPRS, la gestion de la qualite de service a fait ['objet d'ameliorations entre les versions R97 et R99 de la norme. Dans la version R97 de la norme, seuls des services non temps reel peuvent etre offerts aux utilisateurs. Ainsi, dans le sens montant, la station mobile peut indiquer des parametres de QoS quand elle requiert l'etablissement d'un TBF (pour 1 04782/MA/NMND F:\Salle\F1 04782\PREMDEP\Fll\projetbr.doc ) dans le sens montant, en utilisant une procedure d'acces cite en deux phases. Dans le sens descendant, chaque LLC PDU recue du SGSN contient un element d'information appele >, donnant des informations limitees sur la qualite de service. Ces parametres peuvent btre utilises par le BSS pour effectuer dans une certaine mesure une differenciation de services. Dans la version R99 de la norme, une nouvelle procedure, ou procedure de creation de > a ete introduite, definie notamment dans les specifications 3GPP TS 23.060 et 3GPP TS 08.18. Cette procedure autorise la negociation entre le SGSN et le BSS de tous les parametres de QoS a offrir pour le transfert de toute LLC- PDU se rapportant au PFC ( ) ainsi cree. Le SGSN peut aggreger le transfert de LLC-PDUs correspondant a plusieurs contextes PDP donnes (ou >, ou PDP est utilise pour ) dans un meme PFC. Ceci est possible si les PDP Contexts aggreges ont des contraintes de qualite de service proches. Les parametres de QoS ainsi negocies vent ceux definis dans la version R99 et contiennent beaucoup plus d'informations que le profil de QoS defini dans la version R97. Ils contiennent en particulier toutes les variables necessaires pour la definition d'un service temps reel. Le contexte de PDP (ou ) cree lors de l'etablissement d'une session de donnees contient les informations necessaires au transfert des donnees entre MS et GGSN (informations de routage, profil de QoS,...etc.). Lorsqu'il active un contexte PDP, si la fonctionnalite PFC est implementee dans le BSS et le SGSN, ce dernier peut requerir des parametres de QoS du BSS qui peut negocier tout ou partie de ces parametres en fonction de sa charge et de ses capacites. Ceci signifie que les donnees associees a un contexte PDP et done a une QoS donnee vent bien identifiees non seulement da ns le ccour de reseau CN ma is a ussi da ns le reseau d'acces radio RAN. Ceci permet d'assurer que la QoS offerte pour le contexte PDP est negociee entre tous les nocuds de reseau, et il devient ainsi possible de garantir certains attributs de qualite de service. II est ainsi possible d'obtenir qu'un debit binaire garanti ou un delai de transfert maximum soit offest, ce qui permet d'offrir des services temps reel. Pour supporter des applications temps reel il est necessaire que le BSS soit capable d'offrir le debit requis et aussi de transferer les LLC PDUs rec,ues dans les 1 04782/MA/NMND F \Salle\F1 04782\PREMDEP\FlI\projetbr. doc limites du delai de transfert maximum. Pour cela, il est necessaire 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 utilise dans les systemes en mode paquet), et que les interruptions de transfert (dues notamment aux re-selections de cellule, comme rappele precedemment) soient aussi courses que possible. Ceci requiert que le BSS connaisse toujours les specifications de QoS pour le transfert de telles donnees, ou en d'autres termes qu'il dispose d'un contexte contenant des informations de profil de QoS associees. Selon la procedure de creation de , telle que specifiee notamment dans le document 3GPP TS 23.060, le SGSN peut a tout moment requerir la creation d'un contexte appele > (ou PFC), notamment lors de ['activation d'un contexte PDP. La figure 6 est un schema destine o illustrer un exemple de mise en ceuvre d'un procede suivant ['invention. On notera que la presente invention couvre aussi bien le cas d'un appel rec,u par la station mobile (ou >, pour ) que le cas d'un appel emis par la station mobile (ou ', pour ) o travers le domaine paquet (ou ). Une etape dons ces differents scenarios est l'etablissement d'un canal dedie, sur creation d'un PFC. Les specifications 3GPP concernant l'IMS (23.228 et 24.228) definissent les differents flux pour l'etablissement d'appel, et le but n'est pas ici de les rappeler. Dans tous les scenarios, une etape importante qui constitue plus particulierement un des objets de la presente invention est l'etape de reservation de ressources. Dans le cas d'etablissement de session MO, ceci se produit entre l'envoi des messages > et >. Dans le cas d'etablissement de session MT, ceci se produit apres que le message > ait ete recu de la partie appelante. On suppose qu'un contexte PDP pour la signalisation SIP est etabli et que le MS est dans le mode >, lorsqu'une reservation de ressources est effectuee (si un TBF est en cours, alors le premier etablissement de TBF ne sera pas effectue). Les etapes suivantes peuvent etre mises en couvre: 1 04782/MA/NMND F:\Salle\F1 04782\PREMDEP\FIT\projetbr.doc 1 7 (1) Le MS declenche une activation de contexte PDP secondaire pour le flux de media, dont les parametres de QoS ont ete negocies au niveau SIP. Pour cela, le MS requiert un TBF montant (ou UL TBF, pour ) sur des canaux partages. (2) Lorsque le SGSN rec,oit le message necessaires pour le flux de media tamps-reel. (3) La QoS requise indique des caracteristiques de tamps-reel. II est ici propose d'autoriser le BSS a allouer des ressources dediees. Deux methodes ou procedures vent proposees dans le cas ou le BSS peut allouer de telles ressources en correspondance avec la QoS requise: re-utiliser autant que possible les techniques existantes en envoyant un a paging >' au MS, ou introduire un nouveau message d'allocation. On peut noter qu'a ce stade le MS est necessairement dans l'etat GMM READY puisqu'une LLC PDU dans le sens montant vient d'etre envoyee, contenant le message ACTIVATE PDP CONTEXT REQUEST. (3a) Dans une premiere procedure, le BSS genere un > vers le MS. Dans l'etat actuel de la norme pour le mode A /Gb, un MS peut recevoir un > (ou > pour services en mode circuit) seulement si ce > est recu du MSC. II est ici propose que le BSS genere un > pour des services tamps-reel apres avoir rec,u une requdie du SGSN. Suivant l'etat radio du MS, le message de ' peut etre envoye soit sur des canaux de controle commune soit sur le PACCH d'un TBF en cours. Ceci serait similaire a un >, avec ['exception qu'une indication serait presente pour indiquer que ce ' vient du domaine PS ( ) ou mode paquet. Si un ou plusieurs TBF etaient en cours, le MS retournera aux canaux de controle commune et initiera une procedure d'acces aleatoire ( ) en demandant des ressources dediees (une autre option consisterait en une amelioration des procedures de DTM ( ) de maniere a autoriser le MS a initier un acces dedie a travers le PACCH d'un TBF en cours). Le BSS allouera alors des ressources dediees et le MS etablira le lien de signalisation de couche 2. II est aussi propose de demander a la station mobile MS d'envoyer un message GPRS INFORMATION contenant l'identifiant TLLI ( ) propre a la station mobile MS. Ce message peut aussi contenir une frame LLC vice superposee ( ' en anglais) au message SABM. Le TLLI sera renvoye au BSS, de sorte que le BSS peut associer la connexion nouvellement etablie a la requbte rec,ue dans le message CREATE BSS PFC. Dans le cas ou les ressources a l l ouees ne correspondent pas a la QoS req uise, u n > intra- cellulaire peut Gtre effectue pour allouer des ressources en correspondance avec la requete rec,ue du SGSN (ou en correspondance avec la QoS negociee avec le SGSN) si de telles ressources vent disponibles. Le message GPRS INFORMATION peut Gtre envoye sur le canal dedie DCCH ( ) une fois etabli. On note que tout autre message contenant le TLLI du MS peut gtre utilise. (3b) Dans une seconde procedure, on alloue directement au MS des resources dediees: un nouveau message pourrait etre introduit, evitant le besoin d'avoir a envoyer un > au MS. Le BSS allouerait alors directement les ressources dediees, a travers un nouveau message envoye sur les canaux de controle commune (MS dans le mode ) ou sur le PACCH d'un TBF en cors (MS dans le mode ). Le MS activera alors les nouvelles ressources (eventuellement en basculant vers le mode ' si un ou plsieurs TBF etaient en cours) et etablira le lien de signalisation de couche 2. Comme dans la premiere procedure, le MS enverra un message GPRS INFORMATION contenant le TLLI, qui sera renvoye au BSS. Dans ce cas, les ressources allouees devraient etre en correspondance avec la QoS requise. (4) Le BSS envoie alors un acquittement au SGSN pour la creation du PFC. II est a noter que dans le cas ou le BSS ne pourrait allouer des ressources permettant de realiser la QoS requise, il peut tout d'abord essayer de negocier les parametres de QoS, et si la negociation reussit, il peut aiors effectuer l'etablissement des canaux dedies. (5) L'activation de contexte PDP est alors terminee (a travers l'etablissement d'un TBF, ou en utilisant le message GPRS INFORMATION, ou en utilisant un TBF existant s'il est tou jours en cours), (6) L'etablissement de l'appel peut alors Gtre termine au niveau SIP. Lorsque la session a commence, les PDU tamps-reel vent routees comme suit: 1 04782/MA/NMND F:\Salle\F1 04782\PREMDEP\FIT\projetbr.doc - dans le sens reseau vers MS: GGSN SGSN (Interface ), SGSN BSC (interface >), BSC BTS (Interface Abis), BTS MS (Interface radio) - dans le sens MS vers reseau: MS BTS (Interface radio), BTS BSC (Interface ), BSC SGSN (Interface ), SGSN GGSN (Interface ) Sur les interfaces > et > les PDUs vent routees comme des paquets. Sur les interfaces > et radio, les PDUs vent transportees sur des canaux dedies. Pendant le flux temps reel, les mesures radio reportees vent envoyes du MS au BSS sur le SACCH existant. Sur la base de ces mesures radio reportees, le BSS peut effectuer des > en utilisant les mecanismes existants. Sur la figure 6: - I'etape 61 indique que l'etablissement d'un appel est en cours pour un flux de media temps reel, le vient d'etre envoye (dans le cas MO) ou recu (dans le cas MT), - I'etape 62 indique qu"un contexte PDP secondaire est cree dans le SGSN, - I'etape 63 indique que le BSS a recu une requete pour un flux temps reel, il etablit des ressources dediees, - I'etape 64 indique que le MS active les ressources dediees allouees, - I'etape 65 indique qu'un fonctionnement en multi-frame est maintenant etabli, la contention est resolue, et le BSS conna^'t le TLLI de la nouvelle connexion. Un > est effectue si necessaire, - I'etape 66 indique que ltetablissement d'appel SIP peut alors se produire, - I'option correspondant a la premiere procedure indiquee plus haut a ete notee 67 I'option correspondant a la seconde procedure indiquee plus haut a ete notee 63. Les differents messages notes sur la figure 6: (P)RACH, PACKET UPLINK ASSIGNMENT, ACTIVATE PDP CONTEXT REQUEST (secondary PDP context), CREATE BSS PFC, CS PAGING (from the PS domain), IMMEDIATE ASSIGNMENT, SABM + 1 04782/MA/NMND F:\Salle\F1 04782\PREMDEP\FIT\projetbr.doc GPRS INFORMATION, UA + GPRS INFORMATION, CREATE BSS PFC ACK, ACTIVATE PDP CONTEXT ACCEPT, ont ete soit rappeles soit definis precedemment. Eventuellement, pour plus d'informations sur les messages ou procedures existants on pourra se reporter aux specifications correspondantes, pour ces systemes). On notera que l'exemple ainsi decrit ne constitue qu'un des exemples possibles de mise en ceuvre de ['invention. On comprendra qu'il n'est pas possible de decrire ici tous les exemples de mise en ceuvre possibles, et que la presente invention est bien su r d'a pplication genera le. et n'est pas limitee a cet exemple particulier. Un des avantages de ['invention est que les procedures ou protocoles existants vent re- utilises. Notamment, il n'y a pas besoin d'introduire une nouvelle combinaison de canal, ni un ) vent reduits a un minimum (le contexte PDP pour lequel un canal dedie est alloue doit etre indique a la station mobile). II n'y a pas besoin de definir une nouvelle couche de protocole au-dessus de la couche RLC/MAC puisque la couche RR au-dessus de LAPDm peut etre re- utilisee. Toute la signalisation peut etre effectuee a travers les canaux existants SACCH et FACCH. Ceci n'empeche pas d'ameliorer les procedures DTM existantes pour supporter des , simultanes de trafic temps reel transporte dans des canaux dedies et de trafic non temps reel transporte dans des canaux partages. Notamment ['invention permet d'introduire un support pour des services IMS dans le mode ' du reseau GERAN a un cout minimum. 1 04782/MA/NMND F:\Salle\F1 04782\PREMDEP\FIT\projetbr.doc REVENDICATIONS 1. Procede pour supporter du trafic temps reel dans un systeme de radiocommunications mobiles comportant un reseau d'acces radio et un ccour de reseau, procede dans loquel du trafic en temps reel supporte en mode paquet dans le coeur de reseau est supporte en mode circuit dans le reseau d'acces radio. 2. Procede selon la revendication 1, dans lequel ledit support de trafic temps reel en mode circuit dans le reseau d'acces radio inclut une allocation de canaux dedies, ladite allocation de canaux dedies etant effectuee a la creation d'un contexte de flux paquet (PFC). 3. Procede selon la revendication 2, dans lequel ledit contexte de flux paquet est cree dans le reseau d'acces radio. 4. Procede selon la revend ication 3, da ns leq uel led it contexte de fl ux paq uet contient des parametres de QoS a offrir par le reseau d'acces radio et negocies avec le ccour de reseau. 5. Procede selon l'une des revendications 1 a 4, dans lequel ledit trafic temps reel correspond a au moins un flux de media d'une session multimedia. 6. Procede selon l'une des revendications 1 a 5, dans lequel ladite allocation de canaux dedies utilise une procedure d'allocation comportant un > suivi diun acces au reseau. 7. Procede selon l'une des revendications 1 a 5, dans lequel ladite allocation de canaux dedies utilise une procedure d'allocation directe. 8. Procede selon l'une des revendications 1 a 7, dans lequel: - une station mobile a laquelle des canaux dedies ont ainsi ete alloues transmet au reseau des informations relatives b son identite, - sur la base de ces informations, le reseau associe un contexte de flux paquet a cette station mobile, et, le cas echeant, une re-allocation de canaux dedies est effectuee en vue de satisfaire la qualite de service requise pour cette station mobile. 9. Equipement de reseau d'acces radio pour systeme de radiocommunications mobiles, comportant des moyens pour mettre en ceuvre un procede selon l'une des revendications 1 a 8. 1 04782/MA/NND F:\Srlle\F1 04782\PREDEP\FIT\projetbr.doc l O. Equipement de cover de reseau pour systems de radiocommunications mobiles, comportant des moyens pour mettre en Louvre un procede selon Dune des revendications 1 a 8. 11. Station mobile pour systeme de radiocommunications mobiles, comportant ties moyens pour mettre en ocuvre un precede selon Rune des revendications l a B.