FR 2825561 A1 20021206 FR 0107254 A 20010601 PROCEDE DE TRANSMISSION DE PAQUETS IP A TRAVERS UN SYSTEME CELLULAIRE DE RADIOCOMMUNICATION' ET EQUIPEMENTS DU SYSTEME CELLULAIRE POUR LA MISE EN _UVRE DE CE PROCEDE La présente invention concerne les techniques de signalisation visant à procurer une certaine qualité de service (QoS, "Quality of Service") des réscaux de transmission de paquets tels que l'lnternet. L'invention concerne en particulier les réseaux fonctionnant selon le protocole IP ("Internet Protocol", voir "Request For Comments" (RFC) 791 publiée en septembre 1981 par l'lnternet Engineering Task Force (IETF)). On sait que les réseaux IP acheminent les données sous forme de paquets ou datagrammes selon un mécanisme dit de meilleur effort ("best effort"). Plusieurs enrichissements du protocole IP dans la couche réseau du modèle OSI ont été proposés afin de pouvoir fournir une plus grande qualité de service à certains flux d'information. Certaines de ces techniques ("Diffserv", voir RFC 2474 et 2475 publiées en décembre 1998 par l'IETF) utilisent un marquage spécifique des paquets en périphérie du réseau, notamment à l'aide du champ TOS ("Type of service") de l'en-tête IP. Les routeurs internes du réseau ne différencient pas les flux en termes de qualité de service, mais seulement les classes de paquets définies par les marquages. L'invention se rapporte plutôt aux techniques ("Intserv", voir RFC 1633 publiée en juin 1994 par l'IETF) qui opèrent des réservations de ressources au niveau des routeurs sur la base des flux traités qui peuvent être identifiés par les adresses IP source et destination, et des numéros de ports du protocole de couche transport. L'invention vise plus spécifiquement celles de ces techniques qui opèrent des réservations dynamiques de ressources. L'exemple le plus courant en est le protocole RSVP ("Resource reSerVation Protocol", voir RFC 2205 publiée en septembre 1997 par l'IETF). Les ressources faisant l'objet de telles réservations dynamiques - 2 dépendent des implémentations spécifiques du protocole. Elles peuvent correspondre par exemple à des portions de bande passante, ou encore à des portions de mémoires tampons de paquets. La réservation de telles ressources nécessite des procédures de signalisation pour établir et maintenir des états dans les routeurs rencontrés le long du chemin des paquets dans le réseau. Ces procédures comportent la transmission de datagrammes spécifiques le long du chemin. Le routage des paquets intervient ensuite en tenant compte des états ainsi établis et maintenus. La RFC 2746, "RSVP Operation over IP Tunnels", publiée en janvier2000 par l'IETF décrit comment mettre en _uvre RSVP dans des tunnels IP portant du trafic IP (voir aussi EP-A-1 035 688). Ce trafic IP est sous forme de datagrammes d'une couche IP interne, ou couche IP applicative. Le "tunnel" est formé entre deux routeurs de cette couche externe, o ces datagrammes sont encapsulés dans des datagrammes d'une couche IP externe, ou couche IP de transport, mettant en communication ces deux routeurs (cette couche externe est vue comme appartenant au niveau 2 du modèle OSI depuis la couche interne). Les documents ci-dessus décrivent comment associer des sessions RSVP de la couche interne à des sessions RSVP de la couche externe en réponse à la détection de datagrammes de signalisation de la couche externe par les routeurs d'extrémité du tunnel. Le mécanisme de la RFC2746 repose sur une observation des datagrammes de la couche interne aux deux extrémités du tunnel et sur des échanges d'information spécifiques entre les routeurs situés à ces extrémités. Il est inapplicable lorsque l'une des extrémités du tunnel n'est pas capable d'analyser l'en-tête des datagrammes IP de la couche interne. Or il existe des architectures de réseaux qui utilisent des tunnels IP pour transporter du trafic IP sans que les extrémités de ces tunnels aient systématiquement la faculté d'analyser le trafic IP. Le mécanisme précité est alors mis en défaut. Ce cas de figure se rencontre notamment dans des architectures de réseaux cellulaires de radiocommunication permettant un accès sans fil aux réseaux de paquets, notamment de type IP (Intranet ou Internet). Certains réseaux cellulaires de seconde génération (GSM, "Global system for Mobile communications") comportent maintenant un service de transmission de paquets appelé GPRS ("General Packet Radio Service"). Les systèmes cellulaires de troisième génération, notamment l'UMTS ("Universal Mobile Telecommunications System"), sont conçus dans l'optique du multimédia, et incorporent donc de tels services de transmission de paquets. Jo Ces systèmes cellulaires comportent d'une part un c_ur de réseau ("core network") qui assure les fonctions de communication et de gestion des utiiisateurs, et d'autre part un ou plusieurs réseaux d'accès radio qui fournissent les liaisons entre l'infrastructure et les terminaux radio. Dans les systèmes précités (GPRS, UMTS), le c_ur du réseau est basé sur la technologie IP. Il en résulte que lorsqu'un terminal échange des données sous forme de datagrammes IP, ces données font l'objet d'une double encapsulation IP dans le c_ur du réseau. Une couche IP interne met en communication le terminal radio avec le réseau de paquets (Internet ou Intranet). Un commutateur de c_ur de réseau, appelé GGSN ("Gateway GPRS support Node") constitue le routeur de périphérie du réseau de paquets avec lequel le terminal échange ses datagrammes IP en un seul bond de la couche IP interne. Dans le c_ur de réseau, ces datagrammes IP sont incorporés à des unités de données d'un protocole tunnel GTP ("GPRS Tunnelling Protocol", voir spécification technique 3GPPTS 29.060, version 3.8.0 publiée en mars 2001 par le 3GPP (3rd Generation Partnership Project)), elles-mêmes encapsulées dans des datagrammes d'une couche IP externe mettant en communication le GGSN avec le commutateur de desserte du terminal appelé SGSN ("Serving GPRS Support Node"). Le tunnel IP/GTP/IP s'étend du GGSN au SGSN. L'une de ses extrémités (le SGSN) ne possède pas les fonctionnalités d'un routeur de la couche IP interne. Notamment il ne possède pas la capacité du GGSN d'analyser l'entête et éventuellement une partie des données des datagrammes de la couche IP interne. Dans un scénario typique, un service "Intserv" tel que RSVP est fourni entre un terminal et un autre terminal ou serveur distant relié au réseau de paquets (Internet ou Intranet). Les datagrammes de signalisation sont ainsi traités par les routeurs de la couche IP interne qui peuvent réserver les ressources requises si elles sont disponibles. Un maillon faible de cette chane peut être la couche IP externe entre le GGSN et le SGSN, qui applique généralement un mécanisme de "best effort". Il peut en effet exister entre le 0 GGSN et le SGSN un réseau maille comprenant des routeurs en nombre important. Comme le SGSN ne comporte pas cette fonctionnalité d'anaiyse de l'en-tête des datagrammes IP de la couche IP interne, le mécanisme de la RFC 2746 n'est pas applicable dans le tunnel. Procurer aux SGSN une capacité d'analyse des champs de données ("payload") des datagrammes de la couche IP externe à la seule fin d'y détecter d'éventuels paquets de signalisation RSVP de la couche IP interne serait une solution très complexe et coûteuse, étant noté que ces paquets RSVP ne représente qu'une fraction très faible du trafic total. Par conséquent, le mécanisme de relais de signalisation RSVP proposés par la RFC 2746 et EP-A-1 035 688 ne peuvent être appliqués aux réseaux cellulaires. Ainsi, le trafic existant dans le c_ur de réseau, y compris le trafic qui se contente largement du service "best effort", peut contrarier la fourniture de la qualité de service requise pour un flux RSVP. Ceci diminue la capacité de l'opérateur cellulaire à offrir à ses clients des services "Intserv" à réservation dynamique. Un but de la présente invention est de pallier l'inconvénient ci-dessus. La présente invention concerne un procédé de transmission de paquets selon un premier réseau IP à travers un système cellulaire de radiocommunication ayant des équipements reliés entre eux par l'intermédiaire d'un second réscau IP. Ces équipements comportent au moins un routeur passerelle ayant une première interface pour échanger des premiers paquets selon le premier réseau IP et une seconde interface pour échanger des seconds paquets selon le second réseau IP. Ces équipements comprennent aussi au moins un n_ud de commutation ayant une première interface avec un réseau d'accès radio procurant des liaisons avec des terminaux radio et une seconde interface pour échanger des seconds paquets selon le second réseau IP. Certains au moins des terminaux radio comportent des moyens de communication selon le premier réseau IP à travers le système cellulaire, le routeur-passerelle constituant, dans le premier réseau IP, un routeur de périphérie qui échange des premiers paquets avec lesdits terminaux en un seul bond du premier réseau IP. Chacun de ces premiers paquets échangés est encapsulé dans au moins une unité de données d'un protocole tunnel mis en _uvre entre les secondes interfaces d'un routeur-passerelle et d'un n_ud de commutation, ladite unité de données incluant une identité de tunnel et étant elle-même encapsulée dans au moins un second paquet. Le procédé de transmission comprend les étapes suivantes: - détecter des premiers paquets portant des informations de signalisation concernant une première session d'un protocole de réservation dynamique de ressources dans le premier réseau IP relative à un flux applicatif de premiers paquets entre un terminal radio et une unité distante reliée au premier réseau IP; - en réponse à la détection de certains au moins des premiers paquets de signalisation, associer une seconde session d'un protocole de réservation dynamique de ressources dans le second réseau IP à une identité de tunnel incluse dans les unités de données dans lesquelles sont encapsulés les premiers paquets du flux applicatif, ladite seconde session étant relative à un flux de seconds paquets dans lesquels lesdites unités de données sont encapsulées entre un routeur-passerelle et un n_ud de commutation; et - transmettre des seconds paquets de signalisation dans le second réseau IP pour établir eVou mettre à jour des paramètres de la seconde session associée à ladite identité de tunnel. - 6 Pour réaliser une réservation cobérente de ressources entre les deux réseaux IP, la seconde session de protocole de réservation dynamique de ressources mise en _uvre dans le second réseau IP est avantageusement déterminée en fonction des caractéristiques de la première session de protocole de réservation dynamique de ressources mise en _uvre dans le premier réseau IP. Pour ce faire, I'association de la seconde session à ladite identité de tunnel comprend l'affectation à la seconde session de paramètres de qualité de service sélectionnés en fonction de paramètres de qualité de service affectés à la première session et obtenus à partir des premiers paquets de signalisation détectés. Dans un mode de mise en _uvre particulier, le protocole de réservation dynamique de ressources dans chacun des deux réseaux IP est RSVP. Selon le mode de fonctionnement connu du protocole RSVP, une session de ce protocole est initialisée dans le premier réseau IP par un paquet de signalisation formant un message PATH émis par la source du flux applicatif en direction de l'unité distante destinataire. En réponse, cette unité distante retourne vers la source un paquet de signalisation formant un message RESV. Ce message RESV notifie la disponibilité de ressources suffisantes dans chacun des éléments de transmission situés sur le chemin entre l'unité destinataire et le routeur qui le traite par rapport à la qualité de service demandée par le message PATH Il est propagé jusqu'à la source qui commence à transmettre les paquets du flux si les ressources adéquates ont pu être réservées tout au long du chemin. L'étape de détection des premiers paquets de signalisation est de préférence exécutée au niveau de la première interface du routeurpasserelle. Les premiers paquets de signalisation en réponse auxquels on associe la seconde session à l'identité de tunnel sont typiquement les messages RESV du protocole RSVP. Le flux applicatif de premiers paquets peut être un flux descendant, depuis l'unité distante reliée au premier réseau IP vers un terminal radio, ou un - 7 flux montant, depuis un terminal radio vers l'unité distante relice au premier réseau IP. Dans le cas d'un flux applicatif descendant, en réponse à la détection du message RESV, le routeur-passerelle associe la seconde session de protocole de réservation dynamique de ressources dans le second réseau IP à l'identité de tunnel incluse dans les unités de données dans lesquelles sont encapsulés les premiers paquets du flux applicatif. Le routeurpasserelle émet alors un paquet de signalisation portant un message PATH du protocole RSVP sur le second réseau IP à destination du n_ud de commutation. Une réservation dynamique de ressources, entre le routeurpasserelle et le n_ud de commutation, est alors opérée dans le second réscau IP, indépendamment du premier réseau IP, en suivant la procédure standard de protocole RSVP. Dans le cas d'un flux applicatif montant, I'émission du message PATH du protocole RSVP dans le second réseau IP est effectuée par le n_ud de commutation en direction du routeur-passerelle. Pour cela, en réponse à la détection de certains au moins des premiers paquets de signalisation au niveau de la première interface du routeur-passerelle, ce routeurpasserelle transmet d'abord au n_ud de commutation, par l'intermédiaire du second réseau IP, un message de contrôle. Ce message de contrôle relève d'un plan de contrôle du protocole tunnel et désigne l'identité de tunnel incluse dans les unités de données dans lesquelles sont encapsulés les premiers paquets du flux applicatif. Ce message de contrôle contient aussi certains au moins des paramètres de qualité de service de la première session de protocole de réservation dynamique de ressources dans le premier réseau IP. En réponse à la détection de ce message de contrôle, le n_ud de commutation associe alors la seconde session de protocole RSVP interne au second réseau IP à l'identité de tunnel désignce dans ce message de contrôle. Il émet alors, sur le second réseau IP, à destination du routeurpasserelle, un paquet de signalisation portant un message PATH correspondant à cette seconde session de protocole RSVP. La réservation dynamique de ressources IP, entre le n_ud de commutation et le routeurpasserelle, est alors opérée - 8 dans le second réseau, indépendamment du premier réseau IP, selon la procédure standard de protocole RSVP. Ainsi, selon l'invention, dans les deux cas d'un flux applicatif descendant ou montant, la réservation de ressources dans le premier réseau IP donne lieu à une réservation de ressources dans le second réseau IP. Si cette réservation échoue, la transmission suivant le second réseau IP pourra être en mode " best effort ". Une session globale homogène de réservation de ressources est par conséquent établie sur les deux réseaux IP. Dans certains systèmes cellulaires, d'autres éléments de transmission du réseau d'accès radio sont aussi reliés aux n_uds de commutation précédents par un autre réseau IP. Ces autres éléments de transmission sont notamment des organes de contrôle pourvus d'interfaces de réseau communiquant avec la première interface d'accès d'au moins un n_ud de commutation par l'intermédiaire d'un troisième réseau IP. Une partie au moins du protocole tunnel existant entre le routeur-passerelle et le n_ud de commutation est mise en _uvre entre les interfaces de réseau desUits organes de contrôle et la première interface d'accès du n_ud de commutation. De préférence, le procédé de transmission de paquets selon l'invention comprend alors, en réponse à l'association à une identité de tunnel d'une seconde session relative à un flux de seconds paquets dans lesquels des unités de données du protocole tunnel sont encapsulées entre un routeur- passerelle et un n_ud de commutation, I'association à ladite identité de tunnel d'une troisième session d'un protocole de réservation dynamique de ressources dans le troisième réseau IP, pour transporter entre le n_ud de commutation et un organe de contrôle du réseau d'accès radio des paquets IP dans lesquels lesUites unités de données sont encapsulées. Pour un flux applicatif descendant, le n_ud de commutation associe à ladite identité de tunnel une troisième session de protocole de réservation dynamique de ressources. Des troisièmes paquets de signalisation sont alors échangés dans le troisième réseau IP pour établir eVou mettre à jour des paramètres de cette troisième session. Dans le cas de réservation dynamique de ressources dans le troisième réseau IP selon le protocole RSVP, il émet alors, sur le troisième réseau IP, un message PATH correspondant à cette troisième session de protocole RSVP. La réservation dynamique de ressources IP, entre l'organe de contrôle et le n_ud de commutation, est alors opérée dans le troisième réseau, indépendamment des premier et second réseaux, selon la procédure RSVP standard. Pour un flux applicatif montant, I'association à ladite identité de tunnel d'une troisième session de protocole de réservation dynamique de ressources est effectuée par l'organe de contrôle. Pour cela, en réponse à la réception par le n_ud de commutation du premier message de contrôle émis par le routeur- passerelle, le n_ud de commutation transmet, en direction de l'organe de contrôle, un second message de contrôle désignant l'identité du tunnel incluse dans les unités de données dans lesquelles sont encapsulés les premiers paquets du flux applicatif. Ce second message de contrôle reprend au moins une partie des données contenues dans le premier message de contrôle. Par ailleurs, il relève d'un protocole de communication spécifique entre le n_ud de commutation et l'organe de contrôle. La troisième session RSVP dans le troisième réseau IP est alors initialisée par l'organe de contrôle en émettant un message PATH à destination du n_ud de commutation. Un autre aspect de la présente invention se rapporte à un système cellulaire de radiocommunication comprenant des équipements de réseau agencés pour mettre en _uvre un procédé tel que défini ci-dessus, ainsi que certains de ces équipements. L'invention vise ainsi un routeur-passerelle ayant une première interface pour échanger des premiers paquets selon un premier réseau IP et une seconde interface pour échanger des seconds paquets selon un second réseau I P. et constituant un routeur de périphérie du premier réseau I P. agencé pour échanger des premiers paquets avec des terminaux radio en un seul bond du premier réseau IP. Chacun de ces premiers paquets échangés est encapsulé dans au moins une unité de données d'un protocole tunnel mis en - 10 _uvre entre ladite seconde interface et un n_ud de commutation, ladite unité de données incluant une identité de tunnel et étant elle-même encapsulée dans au moins un second paquet échangé selon le second réseau IP. Ce routeur passerelle selon l'invention comprend: - des moyens pour détecter sur la première interface des premiers paquets portant des informations de signalisation concernant une première session d'un protocole de réservation dynamique de ressources dans le premier réseau IP relative à un flux applicatif de premiers paquets entre un terminal radio et une unité distante reliée au premier réscau IP; - des moyens pour, en réponse à la détection de certains au moins des premiers paquets de signalisation, associer une seconde session d'un protocole de réservation dynamique de ressources dans le second réseau IP à une identité de tunnel incluse dans les unités de données dans lesquelles sont encapsulés les premiers paquets du flux applicatif, ladite seconde session étant relative à un flux de seconds paquets dans lesquels lesdites unités de données sont encapsulées entre ladite seconde interface et un n_ud de commutation; des moyens pour transmettre des seconds paquets de signalisation dans le second réseau IP pour établir eVou mettre à jour des paramètres de la seconde session associée à ladite identité de tunnel. Selon un autre aspect, I'invention propose un n_ud de commutation de c_ur de réscau de système cellulaire de radiocommunication, comprenant une première interface avec un réseau d'accès radio procurant des liaisons avec des terminaux radio et une seconde interface pour échanger des paquets selon un réseau IP avec au moins un routeur-passerelle, lesdits paquets portant des unités de donnces d'un protocole tunnel supporté par la seconde interface, chaque unité de données incluant une identité de tunnel et des données constituant soit un message de contrôle si l'unité de données relève d'un plan de contrôle du protocole tunnel, soit des données d'utilisateur si I'unité de données relève d'un plan d'utilisateur du protocole tunnel. Ce n_ud de commutation selon l'invention comprend en outre des moyens pour, en réponse à la réception depuis un routeur-passerelle d'une unité de données spécifique du protocole tunnel relevant du plan de contrôle, associer une - 11 session d'un protocole de réservation dynamique de ressources dans ledit réscau IP à une identité de tunnel désignée dans le message de contrôle de ladite unité de donnces spécifique et transmettre audit routeur- passerelle au moins un paquet de signalisation dans le réseau IP pour établir eVou mettre à jour des paramètres de la session associée à l'identité de tunnel désignée dans le message de contrôle, ladite session étant relative à un flux de paquets dans lequel sont encapsulées des unités de données du protocole tunnel relevant du plan d'utilisateur et comportant l'identité de tunnel désignée dans le message de contrôle. L'invention propose enfin un contrôleur de réseau radio de système cellulaire de radiocommunication, comprenant une première interface de communication avec des terminaux radio et une seconde interface pour échanger des paquets selon un réseau IP avec au moins un n_ud de commutation, lesdits paquets portant des unités de données d'utilisateur d'un protocole tunnel supporté par la seconde interface, chaque unité de données d'utilisateur incluant une identité de tunnel. Ce contrôleur de réseau radio comprend en outre des moyens pour, en réponse à la réception depuis un n_ud de commutation d'un message de contrôle désignant une identité de tunnel, associer une session d'un protocole de réservation dynamique de ressources dans ledit réseau IP à l'identité de tunnel désignée dans le message de contrôle et transmettre audit n_ud de commutation au moins un paquet de signalisation dans le réscau IP pour établir eVou mettre à jour des paramètres de la session associée à l'identité de tunnel désignée dans le message de contrôle, ladite session étant relative à un flux de paquets dans lequel sont encapsulées des unités de données du protocole tunnel comportant l'identité de tunnel désignée dans le message de contrôle. D'autres particularités et avantages de la présente invention apparatront dans la description ci-après d'exemples de mise en oeuvre non limitatifs, en référence aux dessins annexés, dans lesquels: - la figure 1 est un schéma général d'une architecture de système de communication à laquelle l'invention peut s'appliquer; - 12 - les figures 2 et 3 sont des schémas illustrant des piles de protocoles de communication mis en _uvre dans des entités du système de la figure 1, dans le cas de systèmes cellulaires de seconde et de troisième génération, respectivement; - la figure4 est un diagramme illustrant différents messages échangés pour gérer un flux RSVP descendant dans un procédé selon l'invention mis en _uvre dans un réseau cellulaire de deuxième génération relié à un réseau IP; - la figure 5 est un diagramme semblable à celui de la figure 4 dans le cas d'un flux RSVP montant; - les figures 6 et 7 sont des diagrammes respectivement semblables à ceux des figures 4 et 5 dans une mise en _uvre du procédé selon l'invention dans un réseau cellulaire de troisième génération relié à un réseau IP. Le système de communication représenté schématiquement sur la figure 1 comporte une partie fixe 10 et un système cellulaire de communication 20. La partie fixe 10 comporte un réseau IP 12, par exemple Internet ou Intranet. Ce réseau 12 fonctionne classiquement selon le protocole IP (voir la RFC 791 de l'IETF pour la version 4, et la RFC 2460 de l'IETF pour la version 6). Des unités distantes 11 (serveurs IP ou terminaux) sont connectées au réseau IP 12. Le système cellulaire de radiocommunication20 est classiquement divisé en un c_ur de réseau 21 ("Core Network"), comprenant des commutateurs de paquets interconnectés, et un réseau d'accès 22 fournissant les liens radio avec les terminaux radio mobiles 23. Dans l'exemple représenté, le système cellulaire de radiocommunication 20 combine des éléments de seconde génération (GSM) et des éléments de troisième génération (UMTS). Dans le GSM, le réseau d'accès 22, appelé BSS ("Base Station Sub-system"), se compose de stations de base (BTS) 24 distribuées sur la zone de couverture pour communiquer par radio avec les terminaux mobiles 23, et de contrôleurs de stations de base (BSC) 25 reliés au c_ur de réseau 21. Dans le cas de l'UMTS, le réseau - 13 d'accès 22, appelé RNS ("Radio Network System"), se compose de stations de base (BTS) 26 et d'organes de contrôle de réseau radio (RNC) 27 reliés au cceur de réseau 21. Les n_ubs de commutation du c_ur de réscau 21 sont appelés GSN ("GPRS Support Node"). Les n_uds de commutation 30, 31 reliés au réseau d'accès 22 sont appelés SGSN ("Serving GSN") et jouent le rôle de commutateur de desserte du terminal mobile23. D'autres n_uds de commutation 32 du c_ur de réseau 21, appelés GGSN ("Gateway GSN"), sont des routeurs-passerelles connectés au réscau IP 12. Ces GGSN 32 sont reliés aux SGSN 30, 31 pour permettre aux terminaux mobiles 23 d'accéder au réseau IP 12. Sur la figure 1, on a représenté plusieurs GGSN 32, qui peuvent correspondre à des routeurs-passerelles gérés par des fournisseurs appelés ISP ("Internet Service Provider") différents. Les figures 2 et 3 sont des illustrations des protocoles pouvant être mises en _uvre dans des communications en mode paquet entre un terminal mobile 23 et une unité distante 11. Cette unité distante 11 est accessible à travers un ou plusieurs routeurs IP appartenant au réseau IP 12. Dans les deux cas, les protocoles employés sont les mêmes dans la partie fixe 10 ainsi qu'à l'interface Gn entre le GGSN 32 et les SGSN 30, 31. Dans le réseau IP 12, au dessus des couches 1 et2 du modèle OSI (L1, L2), IP est utilisé comme protocole de réseau. La même couche IP 100 est présente dans les terminaux mobiles 23 lorsqu'ils accèdent au réseau IP 12. Cet accès peut se faire lors de sessions TCP ("Transmission Control Protocol", RFC 793 de l'IETF), ou par échange de datagrammes UDP ( applicatifs. Les protocoles utilisés dans le système de radiocommunication 20 sont décrits, pour la deuxième génération (figure 2), dans les Recommandations GSM 03.60, 03.64, 08.16 et 09.61 publiées par l'ETSI ("European Telecommunications Standards Institute"), et pour la troisième génération (figure 3) dans les spécifications 3G TS 25.301 et 3G TS 25.410 publiées par le 3GPP. - 14 Au niveau de l'lnterface "Gn", des couches IP 200 et UDP supplémentaires, ainsi qu'une couche du protocole GTP, sont présentes entre la couche 2 et la couche IP 100 correspondant à celle du terminal mobile 23. Dans le réseau UMTS de troisième génération, des couches IP 200', UDP et GTP supplémentaires sont également présentes à l'interface "lu" entre le SGSN 31 et le RNC27. Le réseau IP sur lequel est mise en _uvre la couche IP 200' pour les échanges entre le RNC et le SGSN s'appuie sur un protocole d'adaptation ML 5 en couche liaison. ll peut être le même réseau IP que celui servant aux échanges SGSN/GGSN, ou un réseau distinct. Dans le o cas du GPRS (figure 2), le SGSN 30 communique selon d'autres protocoles avec le BSC 25 et le terminal mobile 23. Le GGSN 32 situé à l'interface entre le c_ur de réseau cellulaire 21 et le réseau IP 12 comprend donc un routeur de la couche iP 100 commune au réseau IP 12 et au terminal mobile 23. Selon cette couche IP interne 100, la transmission entre un GGSN et un terminal mobile s'effectue en un seul bond, le GGSN formant un routeur de périphérie. Les SGSN 30, 31, quant à eux, ne possèdent pas cette couche IP 100, et n'ont par conséquent pas accès aux paquets transmis entre l'unité distante 11 et le terminal mobile 23, selon le réscau IP 12 via les GGSN 32. Par contre les SGSN 30, 31 possèdent en commun avec les GGSN 32 la seconde couche IP 200, ainsi que les couches de protocole GTP et UDP. On suppose ici que le réseau IP 12 et le réseau IP support du c_ur de réseau sont tous deux équipés pour mettre en _uvre le protocole RSVP. Pour la transmission entre le GGSN et le SGSN, les paquets IP de la couche 100 sont encapsulés dans des unités de données du protocole GTP. La transmission d'unités de données par le niveau de protocole GTP est réalisée par allocation d'un tunnel, dit tunnel GTP, à une communication. Cette allocation préalable à la transmission des données procède par la création d'un contexte PDP ("Packet Data Protocol"), qui attribue à ce tunnel GTP un identifiant appelé TEID ("Tunnel Endpoint Identifier"). - 15 Pour être transmises dans le cceur de réseau 21, les unités de données GTP sont encapsulées dans des paquets UDP/IP de la couche 200. Ces derniers paquets IP sont transmis sur le réseau IP support entre le GGSN 32 et le SGSN 30, 31. Dans le cas d'un système cellulaire de troisième génération, une transmission IP peut intervenir aussi entre le SGSN 31 et le RNC 27. Les figures 4 et 5 illustrent une manière de traiter des flux RSVP de la couche 100 dans un réseau GPRS utilisant des protocoles selon la figure 2. On suppose que le cceur de réseau 21 prend déjà en compte, de façon connue en soi (voir la spécification 3GPP TS 29.060 précitée), un contexte PDP pour le terminal mobile concerné 23, ce contexte PDP incluant notamment un identifiant de tunnel GTP entre le GGSN et le SGSN (TEID). Pour un flux applicatif faisant l'objet d'une session de réservation dynamique RSVP, la procédure de cette réservation est effectuée de façon 1s classique entre l'unité distante11 et le terminal mobile23, comme spécifié dans la RFC 2205. Pour cela, la source du flux applicatif, c'està-dire l'unité distante 11 pour un flux applicatif descendant (figure 4), ou le terminal mobile23 pour un flux applicatif montant (figure 5), émet en direction du destinataire un message PATH de la couche IP 100. Sur les figures 4 et 5, la référence 102 désigne les messages échangés pour l'établissement ou le maintien de ces sessions RSVP au niveau de la couche IP 100. Le message PATH, outre l'adresse IP et le numéro de port UDP de la source du flux applicatif (FilterSpec), contient des données (FlowSpec) décrivant la qualité de service demandée pour le flux applicatif. 2s En réponse à ce message PATH, le destinataire du flux applicatif retourne en direction de la source un message RESV de la couche IP 100. Ce message RESV est relayé par tous les éléments de transmission du destinataire à la source, et indique la disponibilité de ressources suffisantes dans chacun de ces éléments par rapport à la requête du message PATH, en confirmant que ces ressources ont été dûment réservées. Le GGSN 32 procède aussi aux réservations requises lorsqu'il reçoit ce message RESV au - 16 niveau de son interface avec la couche IP interne 100. En réponse à la détection par le GGSN de ces messages 102, et en particulier du message RESV, des actions sont accomplies dans le cadre d'une session RSVP de la couche IP externe 200 entre le GGSN et le SGSN. Sur les figures 4 et 5, la référence 202 désigne les messages échangés pour l'établissement ou le maintien de ces sessions RSVP au niveau de la couche IP 200. Lorsque l'échange PATH/RESV détecté dans la couche interne 100 se rapporte à l'établissement d'une nouvelle session RSVP, il en est de même dans la couche externe 200. De même, lorsque l'échange PATH/RESV détecté dans la couche interne 100 se rapporte à la mise à jour d'une session RSVP existante, ce sont également des messages de mise à jour qui sont échangés dans la couche externe 200. Pour un flux applicatif descendant (figure4), tout en poursuivant la procédure RSVP au niveau de la couche IP 100, le GGSN 32 associe au TEID du tunnel GTP alloué au terminal 23 (d'après son contexte PDP) une seconde session RSVP portée par la couche IP 200. Pour identifier les datagrammes IP relevant de cette seconde session RSVP, les paramètres FilterSpec de cette seconde session RSVP comprennent l'adresse IP du GGSN 32 dans le réseau IP de la couche externe 200, ainsi qu'un numéro de port UDP ailoué à cette session par le GGSN. Cette allocation du numéro de port UDP est effectuée par le GGSN lors de la détection du premier message RESV relatif au flux applicatif, ce qui réalise la première association avec le TEID correspondant. Ensuite, I'association consiste pour le GGSN à récupérer en mémoire le couple Q5 TEID/port UDP approprié sur la base des paramètres FilterSpec spécifiés pour la session RSVP de la couche interne 100. Les paramètres de qualité de service FlowSpec de la seconde session RSVP portée par la couche IP200 sont déterminés d'après ceux de la première session RSVP portée par la couche IP 100 et éventuellement d'après le contexte PDP. - 17 Ayant détecté le message RESV de la couche externe 100 et effectué l'association requise avec le tunnel GTP et la seconde session, le GGSN émet à destination du SGSN un message PATH consistant en un paquet IP de la couche 200 contenant les paramètres requis conformément aux spécifications RSVP. Lorsque les ressources demandées ont pu être réservées par le SGSN et par tout routeur de la couche 200 éventuellement présent entre le SGSN et le GGSN, ce dernier reçoit le message RESV issu du SGSN. Il peut alors faire passer le trafic du flux applicatif dans le tunnel GTP/RSVP établi vers le SGSN (référence 103 sur la figure4). Le flux o applicatif à qualité de service bénéficie donc de la réservation de ressources entre le GGSN 32 et le SGSN 30 au niveau de la couche IP 200, contribuant à la qualité du service global délivré. On limite notamment les risques de voir la première session, établie pour le flux applicatif dans la couche 100, compromise à cause d'une transmission "best effort" dans le c_ur de réseau 21. Pour un flux applicatif montant (figure 5), le GGSN 32 ne peut pas envoyer le message PATH vers le SGSN puisque les données du flux circuleront en sens inverse. Il communique au SGSN 30 I'identifiant TEID du tunnel GTP à travers lequel il re,coit les paquets montants qui contiennent I'adresse IP source indiquce dans les paramètres FilterSpec. Cet identifiant TEID est trouvé dans l'en-tête GTP des unités de données dans lesquelles sont encapsulés les paquets montants du flux concerné. Pour communiquer le TEID au SGSN, on peut utiliser un message spécifique 203 du plan de contrôle GTP-C du protocole GTP. Ce message de contrôle 203 peut être signalé par une valeur spécifique placée dans le champ de type de message ("message-type") de l'en-tête GTP (voir spécification technique 3GPP TS 29.060, v8.3.0, paragraphe 7.1). Pour définir les paramètres de qualité de service propres à la session RSVP de la couche externe 200, ce message de contrôle 203 peut avoir des champs prévus pour véhiculer les paramètres FlowSpec de la session RSVP de la couche IP 100, que le GGSN obtient dans ia signalisation PATH/RESV. - 18 Pour ce sens montant du flux applicatif, selon l'invention, le SGSN30 réalise alors l'association entre le TEID du tunnel GTP et la seconde session RSVP portée par la couche IP 200. Le SGSN détermine les paramètres pertinents de cette seconde session de la même manière que celle suivie par le GGSN32 dans le cas d'un flux applicatif descendant: la première fois, il alloue un numéro de port source UDP pour distinguer la nouvelle session tunnel, et il émet un message PATH avec des paramètres FlowSpec déterminés d'après ceux de la première session RSVP qui ont été indiqués par le GGSN dans le message 203 et éventuellement d'après le contexte PDP. Pour les mises à jour d'une session existante, le SGSN récupère en mémoire l'association TEID/port UDP pour générer le message PATH dans la couche IP 200. La seconde session RSVP est alors poursuivie de façon standard entre le SGSN30 et le GGSN32. De même que pour le sens descendant de transmission du flux applicatif, si l'initiation de la session RSVP au niveau de la couche IP 100 a abouti à un bilan positif des ressources disponibles dans tous les éléments de transmission intermédiaires entre le terminal mobile 23 et l'unité distante 11, la transmission 103 du flux applicatif est débutée avec le niveau de qualité de service demandé. Cette transmission 103 bénéficie en outre, selon l'invention, de la réservation de ressources entre le SGSN30 et le GGSN32 au niveau de la couche IP 200, contribuant à la qualité du service global délivré. Dans le cas o la première session RSVP échoue après ia réception du message RESV par le GGSN32, et o ce GGSN32 a déjà initié ia session RSVP tunnel, le GGSN32 doit interrompre cette dernière au niveau de la couche IP 200. Cette interruption est initiée par le GGSN32 lorsqu'il détecte sur son interface avec la couche IP 100 le message RESV-ERROR d'échac de la première session RSVP. Pour un flux applicatif descendant, il retrouve les paramètres de la session RSVP et émet un paquet de signalisation portant un message de type RESV-ERROR en direction du SGSN30. Pour un flux applicatif montant, le GGSN32 renvoie au SGSN30 un paquet de signalisation portant un message de type PATH-ERROR (on peut aussi prévoir un autre - 19 message spécifique GTP-C). Le procèdé précédemment décrit est applicable de la même manière entre le GGSN 32 et le SGSN 31 dans un système cellulaire de troisième génération (figure 3). Dans ce cas, on peut aller plus loin en réalisant aussi des sessions RSVP entre le SGSN 31 et le RNC 27 lorsque celui-ci communique aussi avec le SGSN suivant les protocoles IP et GTP à travers l'interface Klu". Pour un flux applicatif descendant, selon la figure 6, la session RSVP est étendue au tunnel GTP existant entre le SGSN 31 et le RNC27. Le SGSN 31 reçoit de la part du GGSN 32 un message PATH de la couche IP 200 relatif à la seconde session RSVP de la manière décrite précédemment. Il poursuit alors de façon standard la procédure RSVP 202 au niveau de la couche IP 200. Simultanément le SGSN 31 réalise une autre association entre l'identifiant TEID du tunnel GTP et une troisième session RSVP. Cette autre association est réalisée de façon analogue à la première association effectuée par le GGSN 32. Le SGSN 31 identifie les paramètres de cette troisième session RSVP d'après ceux de la seconde session RSVP contenus dans le message PATH reçu par ce SGSN relativement à cette seconde session, et éventuellement d'après le contexte PDP. Cette troisième session RSVP est portée par la couche IP 200' et est poursuivie normalement entre le SGSN 31 et le RNC 27 par la circulation des messages 202' indiqués sur la figure 6. Pour un flux applicatif montant, selon la figure 7, le SGSN 31 reçoit le message spécifique GTP-C 203 de la part du GGSN 32 de la manière décrite précédemment. ll procède alors à l'initialisation de la session RSVP au niveau de la couche IP 200. Le message 203 contient l'identifiant TEID du tunnel GTP à travers lequel il reçoit les paquets montants. A son tour le SGSN 31 émet un message spécifique 203' à destination du RNC 27, afin de lui retransmettre l'identifiant TEID. Ce message de contrôle 203' est porté par la couche IP 200', et peut par exemple relever du protocole RANAP ("Radio Access Network Application Part", voir la spécification technique 3G TS 25.413, version 3.2.0 publice en juin 200 par le 3GPP) utilisé à l'interface "lu" entre le SGSN 31 et le - 20 RNC 27. Il reprend au moins une partie des paramètres du message de contrôle 203. Le RNC 27 effectue alors une autre association entre ce TEID et une troisième session RSVP. Pour ce faire, il procède de la même façon que le SGSN 31 pour la seconde session RSVP. Cette troisième session RSVP est établie dans la couche IP 200' et poursuivie normalement entre ce RNC 27 et le SGSN 31 par la circulation des messages 202' indiqués sur la figure 7. - 21 R E V E N D I C A T I O N S 1. Procédé de transmission de paquets selon un premier réseau IP (12) à travers un système cellulaire de radiocommunication (20) ayant des équipements reliés entre eux par l'intermédiaire d'un second réseau IP, lesdits équipements comportant au moins un routeur-passerelle (32) ayant une première interface pour échanger des premiers paquets selon le premier réseau IP et une seconde interface pour échanger des seconds paquets selon le second réseau IP, et au moins un n_ud de commutation (30, 31) ayant une première interface avec un réseau d'accès radio (22) procurant des liaisons avec des terminaux radio (23) et une seconde interface pour échanger des seconds paquets selon le second réseau IP, dans lequel certains au moins des terminaux radio comportent des moyens de communication selon le premier réseau IP à travers le système cellulaire, le routeur-passerelle constituant, dans le premier réseau IP, un routeur de périphérie qui échange des premiers paquets avec lesdits terminaux en un seul bond du premier réseau IP, chacun desdits premiers paquets échangés étant encapsulé dans au moins une unité de données d'un protocole tunnel mis en _uvre entre les secondes interfaces d' un routeurpasserelle et d'un n_ud de commutation, ladite un ité de don nées incluant une identité de tunnel et étant elle-même encapsulée dans au moins un second paquet, le procédé comprenant les étapes suivantes: - détecter des premiers paquets portant des informations de signalisation concernant une première session d'un protocole de réservation dynamique de ressources dans le premier réseau IP relative à un flux applicatif de premiers paquets entre un terminal radio et une unité distante reliée au premier réseau IP; - en réponse à la détection de certains au moins des premiers paquets de signalisation, associer une seconde session d'un protocole de réservation dynamique de ressources dans le second réseau IP à une identité de tunnel incluse dans les unités de données dans lesquelles sont encapsulés les premiers paquets du flux applicatif, ladite seconde session étant relative à un flux de seconds paquets dans lesquels - 22 lesdites unités de données sont encapsulées entre un routeur-passerelle et un n_ud de commutation; et - transmettre des seconds paquets de signalisation dans le second réseau IP pour établir et/ou mettre à jour des paramètres de la seconde session associée à ladite identité de tunnel. 2. Procédé selon la revendication 1, dans lequel l'association de la seco nde session à l ad ite id entité de tu n ne l com prend l 'affectati on à lad ite seconde session de paramètres de qualité de service sélectionnés en fonction de paramètres de qualité de service affectés à la première session et obtenus à partir des premiers paquets de signalisation détectés. 3. Procédé selon la revendication 1 ou la revendication 2, dans lequel le protocole de réservation dynamique de ressources est RSVP. 4. Procédé selon la revendication 3, dans lequel les premiers paquets de signalisation en réponse auxquels on associe la seconde session à l'identité de tunnel portent des messages RESV du protocole RSVP. 5. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'étape de détection des premiers paquets de signalisation est exécutée au niveau de la première interface du routeur-passerelle (32). 6. Procédé selon la revendication 5, dans lequel ledit flux applicatif de premiers paquets est un flux descendant, depuis l'unité distante (11) relice au premier réseau I P ( 1 2) vers le terminal radio (23). 7. Procédé selon les revendications 4 et 6, dans lequel, en réponse à la détection du message RESV, le routeur-passerelle (32) associe la seconde session à l'identité de tunnel incluse dans les unités de données dans lesquelles sont encapsulés les premiers paquets du flux applicatif et émet un message PATH du protocole RSVP sur le second réseau IP à destination du nceud de commutation (30, 31). - 23 8. Procédé selon la revendication 5, dans lequel ledit flux applicatif de premiers paquets est un flux montant, depuis le terminal radio (23) vers l'unité distante (11) relice au premier réseau IP (12). 9. Procédé selon la revendication 8, comprenant l'étape suivante en réponse à la détection de certains au moins des premiers paquets de signalisation au niveau de la première interface du routeur-passerelle: transmission du routeur-passerelle (32) au n_ud de commutation (30, 31), par l'intermédiaire du second réseau IP, d'un message de contrôle relevant d'un plan de contrôle du protocole tunnel et désignant Jo l'identité de tunnel incluse dans les unités de données dans lesquelles sont encapsulés les premiers paquets du flux applicatif, et dans lequel l'association de la seconde session à l'identité de tunnel désignée dans le message de contrôle est effectuée par ledit n_ud de commatation (30, 31). 10. Procédé selon la revendication 9, dans lequel le message de contrôle désignant l'identité de tunnel contient aussi au moins certains des paramètres de qualité de service de la première session de protocole de réservation dynamique de ressources dans le premier réseau IP. 11. Procédé selon les revendications 4 et 10, dans lequel, en réponse à la détection dudit message de contrôle, le n_ud de commutation (30, 31) associe la seconde session à l'identité de tunnel désignée et émet un message PATH du protocole RSVP sur le second réseau IP à destination du routeur passerelle (32). 12. Procédé selon l'une quelconque des revendications précédentes, dans lequel le réseau d'accès radio (22) comprend des organes de contrôle (27) pourvus d'interfaces de réseau communiquant avec la première interface d'accès d'au moins un n_ud de commutation (31) par l'intermédiaire d'un troisième réseau IP, une partie au moins dudit protocole tunnel étant mise en _uvre entre les interfaces de réseau desdits organes de contrôle et la première interface d'accès du n_ud de commutation, et dans lequel, en réponse à l'association à une identité de tunnel - 24 d'une seconde session relative à un flux de seconds paquets dans lesquels des unités de donnces du protocole tunnel sont encapsulées entre un routeur passerelle (32) et un n_ud de commutation, on associe à ladite identité de tunnel une troisième session d'un protocole de réservation dynamique de ressources dans le troisième réseau IP, pour transporter entre le n_ud de commutation et un organe de contrôle (27) du réseau d'accès radio des paquets IP dans lesquels lesdites unités de données sont encapsulées. 13. Système cellulaire de radiocommunication (20) comprenant des équipements de réscau agencés pour mettre en _uvre un procédé selon l'une quelconque des revendications précédentes. 14. Routeur-passerelle ayant une première interface pour échanger des premiers paquets selon un premier réseau IP (12) et une seconde interface pour échanger des seconds paquets selon un second réseau IP, le routeur passerelle constituant un routeur de périphérie du premier réseau IP, agencé pour échanger des premiers paquets avec des terminaux radio (23) en un seul bond du premier réseau IP, chacun desUits premiers paquets échangés étant encapsulé dans au moins une unité de données d'un protocole tunnel mis en _uvre entre ladite seconde interface et un n_ud de commutation (30, 31), ladite unité de données incluant une identité de tunnel et étant elle-même encapsulée dans au moins un second paquet échangé selon le second réseau IP, le routeur-passerelle (32) comprenant: - des moyens pour détecter sur la première interface des premiers paquets portant des informations de signalisation concernant une première session d'un protocole de réservation dynamique de ressources dans le premier réseau IP relative à un flux applicatif de premiers paquets entre un terminai radio et une unité distante reliée au premier réseau IP; - des moyens pour, en réponse à la détection de certains au moins des premiers paquets de signalisation, associer une seconde session d'un protocole de réservation dynamique de ressources dans le second réseau IP à une identité de tunnel incluse dans les unités de données dans lesquelles sont encapsulés les premiers paquets du flux applicatif, ladite seconde session étant relative à un flux de seconds paquets dans - 25 lesquels lesdites unités de données sont encapsulées entre ladite seconde interface et un nceud de commutation; - des moyens pour transmettre des seconds paquets de signalisation dans le second réseau IP pour établir eVou mettre à jour des paramètres de la seconde session associée à ladite identité de tunnel. 15. Routeur-passerelle selon la revendication 14, dans lequel le protocole de réservation dynamique de ressources est RSVP. 16. Routeur-passerelle selon la revendication 15, dans lequel lesdits premiers paquets de signalisation portent des messages RESV du protocole 1 0 RSVP. 17. Routeur-passerelle selon l'une quelconque des revendications 14 à 16, dans lequel ledit flux applicatif de premiers paquets est un flux descendant, depuis une unité distante (11) reliée au premier réseau IP (12) vers le terminal radio (23), et dans lequel les moyens pour associer la seconde session à I'identité de tunnel comprennent des moyens pour inclure un numéro de port UDP alloué au flux applicatif dans des paramètres de la seconde session. 18. Routeur-passerelle selon la revendication 17, dans lequel les moyens pour transmettre des seconds paquets de signalisation comprennent des moyens d'émission d'un message PATH du protocole RSVP sur le second réseau IP à destination dudit n_ud de commutation (30, 31). 19. Routeur-passerelle selon la revendication 14, dans lequel ledit flux applicatif de premiers paquets est un flux montant, depuis le terminal radio (23) vers l'unité distante (11) reliée au premier réseau IP (12), et dans lequel les moyens pour associer la seconde session à l'identité de tunnel comprennent des moyens pour transmettre au n_ud de commutation (30, 31), par l'intermédiaire du second réseau IP, un message de contrôle relevant d'un plan de contrôle du protocole tunnel et désignant l'identité de tunnel incluse dans les unités de données dans lesquelles sont encapsulés les premiers paquets du flux applicatif. 20. Routeur-passerelle selon la revendication 19, dans lequel le - 26 message de contrôle désignant l'identité de tunnel contient en outre au moins certains des paramètres de qualité de service de la première session de protocole de réservation dynamique de ressources dans le premier réseau IP. 21. N_ud de commutation de c_ur de réseau de système cellulaire de radiocommunication pour la mise en ceuvre d'un procédé selon l'une quelconque des revendications 9 à 11, comprenant une première interface avec un réseau d'accès radio (22) procurant des liaisons avec des terminaux radio (23) et une seconde interface pour échanger des paquets selon un réseau IP avec au moins un routeur-passerelle (32), lesdits paquets portant des unités de données d'un protocole tunnel supporté par la seconde interface, chaque unité de données incluant une identité de tunnel et des donnces constituant soit un message de contrôle si l'unité de données relève d'un plan de contrôle du protocole tunnel, soit des données d'utilisateur si l'unité de données relève d'un plan d'utilisateur du protocole tunnel, le n_ud de commutation (30, 31) comprenant en outre des moyens pour, en réponse à la réception depuis un routeur-passerelle d'une unité de données spécifique du protocole tunnel relevant du plan de contrôle, associer une session d'un protocole de réservation dynamique de ressources dans ledit réseau IP à une identité de tunnel désignée dans le message de contrôle de ladite unité de données spécifique et transmettre audit routeur-passerelle au moins un paquet de signalisation dans le réseau I P pour établir eVou mettre à jour des paramètres de la session associée à l'identité de tunnel désignée dans le message de contrôle, ladite session étant relative à un flux de paquets dans lequel sont encapsulées des unités de données du protocole tunnel relevant du plan d'utilisateur et comportant l'identité de tunnel désignée dans le message de contrôle. 22. N_ud de commutation selon la revendication 21, dans lequel les moyens pour transmettre ledit paquet de signalisation sont agencés pour inclure dans ledit paquet des paramètres de qualité de service contenus dans le message de contrôle. 23. N_ud de commutation selon la revendication 21 ou 22, dans lequel ledit paquet de signalisation porte un message PATH du protocole RSVP. - 27 24. N_ud de commutation selon l'une quelconque des revendications 21 à 23, dans lequel la première interface supporte le protocole IP et le plan d'utilisateur du protocole tunnel pour communiquer avec des organes de contrôle (27) du réseau d'accès radio (22), le n_ud de commutation (30, 31) comprenant en outre des moyens pour, en réponse à l'association à une identité de tunnel d'une session relative à un flux de paquets dans lesquels des unités de données du protocole tunnel relevant du plan d'utilisateur et comportant une identité de tunnel sont encapsulées entre le n_ud de commutation et un routeur-passerelle (32), associer à ladite identité de tunnel une autre session d'un protocole de réservation dynamique de ressources, pour transporter entre le n_ud de commutation et un organe de contrôle (27) du réseau d'accès radio des paquets IP dans lesquels lesdites unités de données sont encapsulées. 25. Contrôleur de réseau radio de système cellulaire de radiocommunication pour la mise en _uvre d'un procédé selon la revendication 12, comprenant une première interface de communication avec des terminaux radio (23) et une seconde interface pour échanger des paquets selon un réseau IP avec au moins un n_ud de commutation (30, 31), lesdits paquets portant des unités de données d'utilisateur d'un protocole tunnel supporté par la seconde interface, chaque unité de données d'utilisateur incluant une identité de tunnel, le contrôleur de réseau radio (27) comprenant en outre des moyens pour, en réponse à la réception depuis un n_ud de commutation d'un message de contrôle désignant une identité de tunnel, associer une session d'un protocole de réservation dynamique de ressources dans ledit réseau IP à l'identité de tunnel désignée dans le message de contrôle et transmettre audit n_ud de commutation au moins un paquet de signalisation dans le réseau IP pour établir eVou mettre à jour des paramètres de la session associée à l'identité de tunnel désignée dans le message de contrôle, ladite session étant relative à un flux de paquets dans lequel sont encapsulées des unités de données du protocole tunnel comportant l'identité de tunnel désignée dans le message de contrôle. - 28 26. Contrôleur de réseau radio selon la revendication 25, dans lequel les moyens pour transmettre ledit paquet de signalisation sont agencés pour inclure dans ledit paquet des paramètres de qualité de service contenus dans le message de contrôle. 27. Contrôleur de réscau radio selon la revendication 25 ou 26, dans lequel ledit paquet de signalisation porte un message PATH du protocole