FR2882879A1 - Procede de traitement de la qualite de service d'un canal de transport et noeud de gestion pour sa mise en oeuvre - Google Patents
Procede de traitement de la qualite de service d'un canal de transport et noeud de gestion pour sa mise en oeuvre Download PDFInfo
- Publication number
- FR2882879A1 FR2882879A1 FR0502177A FR0502177A FR2882879A1 FR 2882879 A1 FR2882879 A1 FR 2882879A1 FR 0502177 A FR0502177 A FR 0502177A FR 0502177 A FR0502177 A FR 0502177A FR 2882879 A1 FR2882879 A1 FR 2882879A1
- Authority
- FR
- France
- Prior art keywords
- signaling
- channel
- quality
- management node
- activated
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/824—Applicable to portable or mobile terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/11—Identifying congestion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2416—Real-time traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
- H04L47/2433—Allocation of priorities to traffic types
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/245—Traffic characterised by specific attributes, e.g. priority or QoS using preemption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
- H04L47/745—Reaction in network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
- H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/08—Upper layer protocols
- H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Databases & Information Systems (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Procédé de traitement de la qualité de service d'un canal de transport de données de signalisation dans un réseau de transmission en mode paquet comprenant au moins un noeud de gestion (4), dans lequel, pour un canal de transport de données, le noeud de gestion (4)- reçoit un profil de qualité de service associé audit canal, contenant un paramètre (SI) d'indication de signalisation,- détecte (E2) si, dans le profil de qualité de service, le paramètre d'indication de signalisation est activé afin de déterminer s'il s'agit d'un canal de transport de données de signalisation, et- si tel est le cas, traite le canal de transport de données de signalisation de façon prioritaire par rapport à tout autre canal de transport de données média lors de l'exécution d'au moins un mécanisme de traitement de qualité de service appliqué au canal de transport de données de signalisation.
Description
L'invention concerne un procédé de traitement de la qualité de service
d'un canal de transport de données, tel qu'un contexte PDP (Packet Data Protocol), pour le transport de données de signalisation, et un noeud de gestion pour la mise en oeuvre de ce procédé.
L'IMS (IP Multimedia Subsystem) est un sous-système du système UMTS (Universal Mobile Telecommunication System), introduit en UMTS Release 5, ayant vocation à permettre l'établissement dynamique et le contrôle de sessions multimédia entre au moins deux équipements (par exemple entre deux terminaux d'utilisateur ou entre un terminal d'utilisateur et un serveur d'application).
L'établissement d'une session multimédia (par exemple audio, vidéo et/ou textuelles) entre deux équipements, par exemple deux terminaux mobiles, respectivement appelant et appelé, dans l'IMS s'effectue en deux temps: 1. Contexte PDP primaire de signalisation L'équipement appelant active une première session de signalisation, appelée contexte PDP primaire de signalisation. Pendant cette session de signalisation, les équipements appelant et appelé échangent des données de signalisation afin de négocier les caractéristiques de l'appel (notamment les types de codage supportés).
2. Contexte PDP secondaire de transport de données Après la phase de négociation des caractéristiques de l'appel, l'équipement appelant active une seconde session, appelée contexte PDP secondaire de transport de données média, destinée au transport de données relatives à l'appel proprement dit. Il peut par exemple s'agir d'une session de transport de données vidéo et audio, d'une consultation d'un serveur multimédia ou d'une simple session de voix sur IP.
Par le terme "données média", on entend désigner les données propres à une communication, notamment des données audio, vidéo et/ou textuelles, distinctes des données de signalisation déjà échangées dans le contexte PDP primaire.
Lors de l'activation d'un contexte PDP (de transport de données de signalisation ou de données média) à l'initiative d'un équipement, le réseau d'accès radio de l'UMTS (UTRAN), et plus particulièrement le RNC (Radio Network Controler) d'attache de l'équipement, alloue à celui-ci des ressources réseau en activant un canal de communication, couramment appelé un "RAB" (Radio Access Bearer Parameters), au niveau du réseau d'accès radio. Le RAB est défini par un ensemble de paramètres de qualité de service correspondant globalement à ceux du profil de qualité de service du contexte PDP activé.
Par la suite, on utilisera le terme "canal de transport de données" pour désigner aussi bien un contexte PDP qu'un RAB.
L'activation de tout canal, qu'il s'agisse d'un contexte PDP ou d'un RAB, pour le transport de données de signalisation ou pour le transport de données média, nécessite de négocier au préalable les paramètres de qualité de service liés à ce canal.
La présente invention concerne plus particulièrement l'activation d'un canal de signalisation (c'est-à-dire d'un canal de transport de données de signalisation) et la négociation des paramètres de qualité de service et la priorisation au niveau transport d'un tel canal.
Il est primordial que l'activation du contexte PDP primaire de signalisation, au cours duquel sont négociés les paramètres de signalisation pour le contexte PDP secondaire de transport de données média liées à l'appel, s'effectue correctement, sans quoi ce contexte secondaire ne peut être activé. Il devrait donc être traité de façon prioritaire. Pour cela, le standard 3GPP (3rd Generation Partnership Project) a introduit un paramètre SI (Signalling Indication) indiquant si les paquets qui seront transmis dans le contexte PDP appartiennent ou non à de la signalisation, selon qu'il est associé à la valeur "Yes" ou "No". Ce paramètre SI fait partie de l'ensemble des paramètres spécifiant la qualité de service demandés par un équipement souhaitant ouvrir un contexte PDP. Lorsqu'un équipement souhaite ouvrir un contexte PDP de signalisation, il indique: "SI = Yes".
Le standard 3GPP préconise d'utiliser le paramètre de qualité de service THP (Traffic Handling Priority) lorsque le paramètre SI=YES. Ce paramètre THP, lié à la classe de trafic "Interactive", permet de différentier les sessions interactives les unes par rapport aux autres sur le plan de la qualité de service. Chaque session interactive est associée à un paramètre THP pouvant prendre la valeur 1, 2 ou 3, la valeur 1 correspondant au niveau de priorité le plus élevé. Entre d'autres termes, la norme suggère, lorsque le paramètre SI est activé (SI =Yes), de fixer la valeur du paramètre THP à 1. Le contexte PDP de signalisation profite ainsi du niveau de priorité dû à la valeur 1 du paramètre THP. Cependant, si lors de l'activation d'un nouveau contexte PDP primaire de signalisation, des contextes PDP correspondant à des sessions interactives, ayant un paramètre THP valant 1, sont déjà activés ou en cours d'activation, le réseau traite de la même manière les contextes PDP activés correspondant aux sessions interactives en cours et le contexte PDP de signalisation.
La présente invention vise donc à proposer un procédé de traitement de la qualité de service d'un canal de transport de données dans un réseau de transmission en mode paquet comprenant au moins un noeud de gestion, dans lequel, pour un canal de transport de données, le noeud de gestion reçoit un profil de qualité de service associé à ce canal, contenant un paramètre (SI) d'indication de signalisation, tel qu'il permette d'améliorer le traitement prioritaire des paquets de données contenant de la signalisation.
Ce problème est résolu par le fait que le noeud de gestion -détecte si, dans le profil de qualité de service, le paramètre d'indication de signalisation est activé afin de déterminer s'il s'agit d'un canal de transport de données de signalisation, et - si tel est le cas, traite le canal de transport de données de signalisation de façon prioritaire par rapport à tout autre canal de transport de données média lors de l'exécution d'au moins un mécanisme de traitement de qualité de service appliqué au canal de transport de données de signalisation.
On notera que, par le terme "noeud de gestion", on entend désigner un noeud du réseau dont le rôle est de gérer le trafic de flux de données. Il s'agit notamment, mais non limitativement: pour l'UMTS, des RNC, SGSN et GGSN - pour le GPRS, des BSC, SGSN et GGSN et - pour tout autre système de téléphonie mobile, de routeurs, ou noeuds, aptes à gérer le trafic de flux de paquets.
L'invention consiste donc d'abord à différentier le traitement du canal de signalisation avec un niveau de priorité différent de celui de tout autre canal de transport de données média, pendant le processus d'activation du canal de signalisation et/ou sur un canal de signalisation établi. Par exemple, le noeud de gestion peut traiter le canal de signalisation de façon prioritaire par rapport à tout autre canal pour le transport de données média: - lors de l'exécution d'un contrôle d'admission du canal de signalisation en cours d'activation, - lorsqu'il fait de la préemption (en cours ou après activation du canal) et/ou - lorsqu'il fait de l'allocation de ressources différentiées (en cours ou après activation du canal).
Avantageusement, pour traiter de façon prioritaire le canal de signalisation à activer, le noeud de gestion modifie, dans le profil de qualité de service demandé, au moins l'un des paramètres du groupe comprenant la classe de trafic et tout paramètre définissant une priorité relative du canal de signalisation pour l'allocation de ressources et/ou la préemption, afin d'augmenter le niveau de priorité du canal de signalisation à activer.
Comme paramètre définissant une priorité relative du canal de signalisation pour l'allocation de ressources et/ou la préemption, on peut utiliser, à titre d'exemples non limitatifs: - le paramètre ARP (Allocation Retention Priority), - le paramètre THP (Traffic Handling Priority) ou encore - un paramètre dérivé de plusieurs attributs de qualité de service tels qu'un attribut relatif au niveau de priorité de l'abonné, par exemple l'ARP, un attribut relatif au niveau de priorité du service utilisé, par exemple la classe de trafic.
Grâce à une telle modification du profil de qualité de service du canal de signalisation, celui est traité de façon prioritaire non seulement par le noeud ayant modifié le profil, mais également par les autres noeuds du réseau ayant pour rôle de faire transiter les données véhiculées par ce canal, sans que cela nécessite de modifier intrinsèquement ces autres noeuds.
Avantageusement encore, le noeud de gestion modifie, dans le profil de qualité de service demandé, au moins un paramètre de débit à travers le canal afin d'optimiser 5 l'utilisation des ressources réseau.
La quantité de données véhiculée dans un canal de signalisation est relativement peu élevée par rapport à celle véhiculée dans un canal de transport de données média. L'invention permet donc de diminuer le ou les débits spécifiés dans le profil de qualité de service demandé afin de diminuer le débit alloué au canal de signalisation et ainsi optimiser l'utilisation des ressources réseau.
Dans une variante avantageuse de l'invention, le noeud de gestion marque les paquets de données de signalisation véhiculés par ledit canal de signalisation de manière à ce que le réseau assure un traitement prioritaire desdits paquets lors de leur transport.
Grâce à cela, le canal de signalisation est traité de façon prioritaire au niveau transport (c'est-à-dire après son activation), lors du transport des paquets de données de signalisation. Le marquage des paquets de données de signalisation permet aux autres noeuds du réseau destinés à faire transiter ces paquets dans le réseau de détecter automatiquement leur niveau de priorité et de les traiter en conséquence, sans utiliser ni le paramètre SI, ni le paramètre THP.
On notera ici que, dans le cas d'un réseau comportant plusieurs noeuds de gestion, par exemple un réseau UMTS comportant des RNC, SGSN et GGSN, le profil de qualité de service du canal de signalisation peut être modifié, au niveau contrôle, par un premier noeud, par exemple par le SGSN, alors qu'au niveau transport, les paquets de signalisation peuvent être marqués par un second noeud, par exemple le RNC qui, en premier, reçoit les données de signalisation et a pour rôle de les retransmettre dans le réseau, au travers d'un lien W, sous la forme de paquets.
De préférence, le noeud de gestion marque les paquets de données de signalisation véhiculés par ledit canal de signalisation à l'aide d'un champ DSCP (DiffServ Code Point).
Au niveau transport, le réseau utilise le mécanisme Diffserv, défini par l'IETF (Internet Ingineering Task Force), pour différentier les traitements de qualité de service appliqués aux paquets de données transportés par les différents contextes PDP de transport de données. Chaque paquet de données a, dans son en-tête, un champ DSCP "DiffServ Code Point" pouvant prendre différentes valeurs codées sur six bits. A chaque valeur de DSCP correspond un comportement appelé "Diffserv PHB" (Per Hop Behavior) au niveau des noeuds du réseau tout au long du trajet du paquet. Le comportement "EF" (Expedited Forwarding), correspondant à la valeur "101110" du champ DSCP, assure un service prioritaire avec faible délai, faible gigue (At entre différents paquets pour traverser un noeud ou un réseau) et faible perte de paquets. L'association "GSMA" (GSM Association) propose de marquer les paquets des flux de la classe de trafic "conversationnelle" avec le champ DSCP correspondant au comportement EF afin de les rendre prioritaires par rapport aux flux appartenant aux autres classes de trafic. Il est donc particulièrement intéressant de détourner l'utilisation de ce champ DSCP pour rendre les flux de signalisation plus prioritaires, par exemple en attribuant aux champs DSCP de ces flux la valeur "101110" correspondant au comportement "EF". Grâce à cela, les flux de signalisation deviennent aussi prioritaires que les flux conversationnels.
Un deuxième aspect de l'invention concerne un noeud de gestion pour un 20 réseau de transmission en mode paquet, comprenant des moyens de détection d'un canal de signalisation, agencés pour déterminer si, dans un profil de qualité de service associé à un canal de transport de données, un paramètre d'indication de signalisation (SI) est activé afin de détecter s'il s'agit d'un canal de signalisation, des moyens pour commander le noeud de façon à ce qu'il traite ledit canal de signalisation de façon prioritaire par rapport à tout autre canal pour le transport de données média lors de l'exécution d'au moins un mécanisme de traitement de qualité de service appliqué au canal de signalisation.
Un troisième aspect de l'invention concerne un réseau de transmission en mode paquet, comprenant au moins un noeud tel que défini ci-dessus.
Un quatrième aspect de l'invention concerne un module logiciel de traitement d'un canal de signalisation, pour un noeud de gestion d'un réseau de transmission en mode paquet, comprenant des instructions logicielles aptes à commander l'exécution des étapes du procédé précédemment défini par le noeud de gestion.
L'invention sera mieux comprise à l'aide de la description suivante d'un mode de réalisation particulier du procédé de l'invention, ainsi que des noeuds de gestion et du module logiciel pour la mise en oeuvre de ce procédé, en référence aux dessins annexés sur lesquels: - la figure 1 représente un schéma simplifié de l'architecture du système IMS et du réseau UMTS, - les figures 2A et 2B représentent les différentes étapes du processus d'activation d'un contexte PDP; - la figure 3 représente un schéma bloc fonctionnel d'un noeud de gestion du réseau et -la figure 4 représente un tableau de correspondance entre des paramètres de qualité de service UMTS, des comportements Diffserv et des valeurs DSCP.
Sur la figure 1, on a représenté un réseau mobile de communication en mode paquet, correspondant en l'espèce au domaine PS (Packet Switched domain), que l'on appellera par la suite "domaine paquet", du réseau coeur UMTS, et le sous-système multimédia IP (IMS). Le domaine paquet du réseau coeur UMTS comprend - un noeud SGSN (Serving GPRS Support Node) jouant le rôle de localisation de l'abonné dans une zone de localisation, appelée RA (Routing Area) et de gestion du lien de communication avec le réseau d'accès. Le SGSN stocke le profil de chaque abonné et effectue un contrôle des ressources réseaux demandées par chaque abonné, et - un noeud GGSN (Gateway GPRS Support Node) jouant le rôle de passerelle entre le réseau UMTS et les réseaux à commutation de paquets extérieurs (l'Internet public, un intranet privé, etc.).
Le réseau d'accès de l'UMTS, appelé UTRAN (UMTS Terrestrial Radio Access Network), constituant la partie radio du réseau UMTS, comprend -des équipements de transmission radio, appelés NodeB, auxquels les terminaux d'utilisateur, également appelé UE (User Equipment), se connectent, et des contrôleurs RNC (Radio Network Controller), chaque RNC contrôlant une pluralité de NodeB.
Sur la figure 2, on a représenté une chaîne de transmission comprenant un UE 1, un NodeB 2,un RNC 3, un SGSN 4 et un GGSN 5.
Comme cela a déjà été explicité, l'établissement d'une session de communication entre l'UE 1 et un autre UE (ou un serveur d'application AS) dans l'IMS s'effectue en deux temps: l'UE 1 active - d'abord un contexte PDP primaire de signalisation pour échanger avec l'autre UE des données de signalisation (codec supporté, type de données média échangées, etc.) puis un contexte PDP secondaire pour le transport des données média (vidéo, audio et/ou textuelles par exemple) propres à la session de 20 communication multimédia ou simple média.
Le processus d'activation et de marquage du contexte PDP primaire de signalisation va maintenant être décrit en référence à la figure 2.
É Activation du contexte PDP de signalisation Etape El: L'UE 1 envoie à son SGSN 4 d'attache une demande d'activation d'un contexte PDP primaire SM Activate PDP Context Request - avec un profil de qualité de service demandé par UE1, couramment appelé profil QoS (Quality of Service) , comprenant un ensemble de paramètres de qualité de service, définis dans le standard 3GPP, tels que notamment: - la classe de trafic (Conversational, Streaming, Interactive ou Background) indiquant le type de trafic souhaité, - le paramètre THP (Traffic Handling Priority), pour la classe de trafic "Interactive", pouvant prendre la valeur 1, 2 ou 3 et permettant de prioriser les flux de la classe de trafic "Interactive" les uns par rapport aux autres, - le débit garanti sur lien montant, définissant le débit minimum pour le trafic temps réel sur lien montant, pour les classes de trafic "Conversational" et "Streaming", et - le débit garanti sur lien descendant, définissant le débit minimum pour le trafic temps réel sur lien descendant, pour les classes de trafic "Conversational" et "Streaming", - les débits maximums, sur liens montant et descendant, définissant le débit maximum sur les liens montant et descendant, pour toutes les classes de trafic (Conversational, Streaming, Interactive et Background), et - le paramètre SI (Signalling Indication), prenant la valeur "Yes" ou "No", indiquant si le contexte PDP véhicule des données de signalisation ou non.
Le contexte PDP primaire à activer étant un contexte PDP de signalisation, le paramètre SI du profil QoS demandé est activé (SI = Yes) . L'UE 1 indique ainsi que le contexte PDP à activer véhiculera du trafic de signalisation.
Etape E2: Cette étape est divisée en trois sous-étapes.
Sous-étape E2.1: Ajout du paramètre ARP dans le profil QoS demandé Le SGSN 4 reçoit la demande d'activation d'un contexte PDP primaire, en provenance de l'UE 1. Il consulte alors le profil de l'abonné UE1 dans la base de données HLR (Home Location Register), contenant les informations relatives aux abonnés gérés par l'opérateur, en extrait la valeur du paramètre ARP (Allocation/Retention Priority) souscrite par l'abonné et l'ajoute au profil de qualité de service demandé par l'UEI.
Sous-étape E2.2: Modification du profil QoS demandé Le SGSN 4 détecte si, dans le profil de qualité de service demandé par UE1, le paramètre SI est activé (SI = Yes) afin de déterminer s'il s'agit d'un contexte PDP de signalisation. Cela étant le cas, il modifie, si besoin, dans le profil QoS demandé, au moins l'un des deux paramètres "classe de trafic" et "ARP", de manière à augmenter le niveau de priorité du contexte PDP de signalisation à activer. Dans l'exemple particulier de la description, le SGSN 4 modifie la classe de trafic en lui affectant la valeur "Conversational" et le paramètre ARP en lui affectant la valeur 1. Le contexte PDP de signalisation bénéficie ainsi de la priorité due aux contextes PDP de type "Conversational" ayant un niveau de priorité de l'ARP valant 1.
Si la classe de trafic demandée à l'origine par UE1 n'est ni "Conversational", ni "Streaming", le profil QoS demandé par UE1 et reçu par le SGSN 4 ne contient pas de débits garantis. Dans ce cas, après avoir changé la classe de trafic en "Conversational", le SGSN 4 ajoute dans le profil QoS demandé les débits garantis sur lien montant et sur lien descendant. Les valeurs de ces débits garantis sont fixées de façon à optimiser l'utilisation des ressources réseaux. Si le profil QoS demandé par UE1 et reçu par le SGSN 4 contient déjà des débits garantis sur lien montant et sur lien descendant, le SGSN 4 les diminue pour optimiser l'utilisation des ressources réseaux. Les flux de signalisation ne nécessitant que peu de ressources réseaux, il est inutile de leur allouer des débits trop importants. A titre d'exemple non limitatif, si les débits garantis demandés à l'origine sont de 384 kbits/sec, le SGSN 4 les diminue à 32 ou à 64 kbits/sec, de manière à utiliser de façon optimale les ressources du réseau.
Le SGSN 4 diminue également les débits maximums (sur liens montant et descendant) contenus dans le profil QoS demandé par UE1 et reçu par le SGSN 4.
Sous-étape E2.3: Application des mécanismes de traitement de la QoS Le SGSN 4 traite le contexte PDP de signalisation à activer de façon prioritaire par rapport à tout autre contexte PDP (en cours d'activation ou déjà activé) pour le transport de données média lors de l'exécution d'un premier mécanisme de traitement de la qualité de service, à savoir le contrôle d'admission, appliqué au contexte PDP de signalisation à activer.
Le SGSN 4 traite également le contexte PDP de signalisation à activer de façon prioritaire par rapport à tout autre contexte PDP pour le transport de données média lors de l'exécution des deux autres mécanismes suivants de traitement de la qualité de service appliqués au contexte PDP à activer: - la préemption de ressources et - l'allocation de ressources différentiées.
Le mécanisme de préemption consiste, pour le SGSN 4, en cas de congestion, à préempter les ressources d'un ou de plusieurs contexte(s) PDP de transport de données média, déjà activé(s), pour les allouer au contexte PDP de signalisation à activer.
Le mécanisme d'allocation de ressources différentiées consiste, pour le SGSN 4, à optimiser l'utilisation des ressources réseaux lors de l'allocation de ressources au contexte PDP de signalisation. Comme déjà explicité plus haut, les contextes PDP de signalisation véhiculent une quantité relativement faible de données par rapport aux contextes PDP de transport de données média (déjà activés ou en cours d'activation).
Etape E3: Le SGSN 4 envoie la demande d'activation d'un contexte PDP au 20 GGSN 5 Create PDP Context Request - avec le profil de qualité de service demandé par l'UE 1 puis modifié par le SGSN 4.
Etape E4: Sur réception de la demande d'activation du contexte PDP, le GGSN 5 applique les mécanismes de traitement de qualité de service contrôle d'admission, préemption et allocation de ressources différentiées en tenant compte du profil de qualité de service modifié (classe de trafic "Conversational", ARP = 1, débits garantis réduits et/ou débits maximum réduits).
Etape E5: Le GGSN 5 envoie au SGSN 4 une réponse positive à la demande d'activation du contexte PDP de signalisation Create PDP Context Response, 30 comprenant le profil de QoS négocié pour ce contexte.
Etape E6: Le SGSN reçoit l'accord du GGSN pour activer le contexte PDP de signalisation, avec le profil de QoS négocié. On rappelle ici que, suite à la modification du profil QoS demandé par le SGSN 4 à l'étape E2. 2, le paramètre ARP vaut 1. Le SGSN 4 décline l'ARP en quatre sous-paramètres de la manière suivante: - Niveau de priorité = 1 (priorité haute) Vulnérabilité à la préemption = NO - Capacité de préemption = YES - Mise en file d'attente autorisée = NO Etape E7: Le SGSN 4 envoie au RNC 3 une demande d'allocation de RAB (Radio Access Bearer) RAB AssReq avec une liste d'attributs de qualité de service associés au RAB correspondant globalement aux paramètres de qualité de service demandés à l'origine par l'UE 1 puis modifiés par le SGSN 4.
Etape E8: Le RNC 3 reçoit la demande d'allocation de RAB avec la liste d'attributs de qualité de service comprenant le paramètre SI = Yes et les autres paramètres de qualité de service, demandés par l'UE 1 et éventuellement modifiés par le SGSN 4 et le GGSN 5.
Comme à l'étape E2, le RNC 3 détermine que le RAB demandé est prévu pour transporter des données de signalisation, par détection du paramètre SI = Yes dans la liste d'attributs de qualité de service requis. Il traite alors le RAB de signalisation à activer de façon prioritaire par rapport à tout autre RAB (en cours d'activation ou déjà activé) pour le transport de données média lors de l'exécution du mécanisme de contrôle d'admission du RAB de signalisation à activer. Le RNC 3 calcule les ressources nécessaires pour l'activation de ce nouveau RAB de signalisation et le traite de façon prioritaire par rapport à tout autre RAB pour le transport de données média lors de l'exécution des mécanismes de préemption de ressources et d'allocation de ressources différentiées.
Etape E9: Le RNC 3 notifie au SGSN l'acceptation de la demande d'allocation d'un RAB, par l'envoi du message RAB AssRes.
Etape E10: Après établissement du RAB, le SGSN 4 envoie à l'UE 1 un message SM Activate PDP Context Accept indiquant que l'activation du contexte PDP de signalisation est acceptée.
Après l'étape E10, le contexte PDP primaire de signalisation est activé et véhicule des données de signalisation entre l'UE 1 et l'autre UE (ou le serveur d'application AS) avec lequel l'UE 1 souhaitait établir une session multimédia dans l'IMS.
É Marquage du contexte PDP de signalisation Après activation du contexte PDP de signalisation, sur détection du paramètre SI activé (SI = Yes), les données de signalisation sont marquées par un noeud du réseau. Le marquage est effectué dans le champ DSCP ici par attribution de la valeur "101110" correspondant au comportement EF. Grâce à cela, les données de signalisation sont traitées avec le niveau de priorité le plus élevé. Ce marquage est ici réalisé par le RNC 3 d'attache de UE 1, dans le sens montant du lien vis-à-vis de l'UEI, et par le RNC d'attache de l'autre UE, dans le sens descendant du lien vis-à-vis de l'UE1. Lors du transport de ces données dans le réseau, chacun des autres noeud de gestion (SGSN et GGSN) détermine qu'il s'agit de données de signalisation par détection du paramètre SI activé (SI = Yes) et vérifie alors que le champ DSCP de ces données de signalisation a bien la valeur "101110" correspondant au comportement EF.
Chaque noeud de gestion du réseau (RNC, SGSN et GGSN) est en fait agencé pour, lorsqu'il reçoit des données: - déterminer s'il s'agit de données de signalisation par détection du paramètre SI activé (SI = Yes) -si tel est le cas, vérifier le champ DSCP de ces données.
o si ce champ a une valeur autre que celle correspondant au comportement EF ("101110"), modifier le champ DSCP en lui attribuant la valeur correspondant au comportement EF ("101110").
o sinon, ne pas le modifier.
D'une manière générale, le noeud marquant des données de signalisation avec le champ DSCP "101110" correspondant au comportement EF est de préférence le noeud du réseau qui, en premier, reçoit ces données et a pour rôle de les retransmettre vers le réseau au travers d'un lien IP et, par conséquent, sous la forme d'un paquet IP.
Ainsi, les paquets sont traités avec un niveau de priorité élevé dès le début de leur transport dans le réseau. Toutefois, on pourrait envisager que ce marquage soit effectué par un autre noeud, par exemple le SGSN.
Le champ DSCP des paquets de signalisation ayant la valeur "101110" correspondant au comportement EF, les noeuds de gestion du réseau traitent ces paquets avec une priorité haute, due aux flux de la classe de trafic "Conversational" bien qu'il ne s'agisse pas d'un tel type de flux mais d'un simple flux de signalisation.
Lorsque les conditions de trafic changent, les noeuds de gestion du réseau (RNC, SGSN et/ou GGSN) peuvent être amenés à effectuer de la préemption de ressources et/ou de l'allocation de ressources différentiées en modifiant ainsi les ressources respectives attribuées aux différents contextes PDP ouverts. Lors de l'application de ces mécanismes de traitement de qualitéde service, les noeuds traitent le contexte PDP de signalisation activé de façon prioritaire par rapport à tout autre contexte PDP (en cours d'activation ou déjà activé) pour le transport de données média, comme à l'étape E2.3.
On va maintenant décrire le noeud de gestion SGSN 4, en référence à la figure 3. Par souci de clarté, seuls les éléments du noeud 4 liés à l'invention vont être explicités.
Le noeud 4 comprend un module 40 de traitement d'un canal de transport de données de signalisation. Il s'agit d'un module logiciel comprenant des instructions logicielles pour commander l'exécution par le noeud des étapes du procédé précédemment décrit. Plus précisément, le module 40 comprend les éléments suivants: - une brique 41 de détection d'un canal de signalisation, celui-ci étant associé à un profil de qualité de service, une brique de commande 42 destinée à commander un traitement prioritaire d'un canal de signalisation par rapport à tout autre canal de transport de données média, lors de l'application de différents mécanismes de traitement de qualité de service, - une brique 43 de modification du profil de qualité de service d'un canal de signalisation et une brique 44 de marquage des paquets de données de signalisation véhiculés par un canal de signalisation, agencée pour vérifier le marquage des paquets de données de signalisation et, si besoin, effectuer ce marquage, de manière à ce que le réseau assure un traitement prioritaire de ces paquets lors de leur transport.
La brique 41 est agencée pour déterminer si, dans le profil de qualité de service d'un canal de transport de données (en cours d'activation ou déjà activé), le paramètre SI d'indication de signalisation est activé (SI = Yes), afin de détecter s'il s'agit d'un canal de signalisation.
La brique de commande 42 est agencée pour commander le noeud 4 de manière à ce qu'il traite un canal de signalisation (en cours d'activation ou déjà activé) de façon prioritaire par rapport à tout autre canal de transport de données média lors de l'application des différents mécanismes de traitement de qualité de service, en l'espèce le contrôle d'admission, la préemption de ressources et l'allocation de ressources différentiée.
La brique 43 de modification du profil de qualité de service d'un canal de signalisation est agencée pour - modifier au moins l'un des deux paramètres de classe de trafic et d'ARP de manière à augmenter le niveau de priorité du canal de signalisation, - ajouter des débits garantis sur liens montant et descendant au profil QoS, si besoin, ou modifier les débits garantis sur liens montant et descendant déjà présents dans le profil QoS, ainsi que les débits maximums sur liens montant et descendant du canal de signalisation afin d'optimiser l'utilisation des ressources réseaux.
On rappelle que, dans l'exemple particulier de la description, la brique 43 est agencée pour, si besoin, modifier la classe de trafic en lui affectant le valeur "Conversational" et l'ARP en lui affectant la valeur 1, ajouter ou réduire les débits garantis (sur liens montant et descendant) et réduire les débits maximums (sur liens montant et descendant).
La brique 43 pourrait être agencé pour modifier d'autres paramètres du profil de qualité de service du canal de signalisation.
La brique de marquage 44 est agencée pour, sur réception de données de signalisation (celles-ci ayant détectées par la brique 41), vérifier le champ DSCP dans les données de signalisation o si le champ DSCP a une valeur autre que celle correspondant au comportement EF ("101110"), modifier le champ DSCP en lui attribuant la valeur correspondant au comportement EF ("101110").
o sinon, ne pas le modifier.
Dans l'exemple particulier précédemment décrit, le marquage des données de signalisation par le champ DSCP "101110" est effectué par les RNC 3. Les autres noeuds du réseau (SGSN 4 et GGSN 5) se contentant de vérifier le marquage.
Dans l'exemple particulier de la description, les autres noeuds du réseau (RNC 3 et GGSN 5) intègrent également un module logiciel 40 de traitement de canaux de transport de données de signalisation, comportant les briques logicielles 41 (détection d'un canal de signalisation), 42 (commande), 43 (modification du profil QoS) et 44 (marquage). On pourrait également envisager que certains noeuds ne possèdent que certaines de ces briques logicielles. Par exemple, les RNC 3 et GGSN 5 pourraient ne pas intégrer la brique 43 de modification du profil QoS, dans la mesure où les SGSN l'intègre.
Claims (1)
18 REVENDICATIONS
1. Procédé de traitement de la qualité de service d'un canal de transport de données de signalisation dans un réseau de transmission en mode paquet comprenant au moins un noeud de gestion (4), dans lequel, pour un canal de transport de données, le noeud de gestion (4) reçoit un profil de qualité de service associé audit canal, contenant un paramètre (SI) d'indication de signalisation, caractérisé par le fait que le noeud de gestion (4) détecte (E2) si, dans le profil de qualité de service, le paramètre d'indication de signalisation est activé afin de déterminer s'il s'agit d'un lo canal de transport de données de signalisation, et - si tel est le cas, traite le canal de transport de données de signalisation de façon prioritaire par rapport à tout autre canal de transport de données média lors de l'exécution d'au moins un mécanisme de traitement de qualité de service appliqué au canal de transport de données de signalisation.
2. Procédé selon la revendication 1, dans lequel, pour traiter de façon prioritaire le canal de signalisation à activer, le noeud de gestion (4) modifie (E2), dans le profil de qualité de service demandé, au moins l'un des paramètres du groupe comprenant la classe de trafic et tout paramètre définissant une priorité relative du canal de signalisation pour l'allocation de ressources et/ou la préemption, afin d'augmenter le niveau de priorité du canal de signalisation à activer.
3. Procédé selon l'une des revendications 1 et 2, dans lequel le noeud de gestion (4) modifie, dans le profil de qualité de service demandé, au moins un paramètre de débit à travers le canal afin d'optimiser l'utilisation des ressources réseaux.
4. Procédé selon l'une des revendications 1 à 3, dans lequel le noeud de gestion (4) marque les paquets de données de signalisation véhiculés par ledit canal de signalisation de manière à ce que le réseau assure un traitement prioritaire desdits paquets lors de leur transport.
5. Procédé selon la revendication 4, dans lequel, le noeud de gestion (4) marque les paquets de données de signalisation véhiculés par ledit canal de 5 signalisation à l'aide d'un champ DSCP (DiffServ Code Point).
6. Procédé selon l'une des revendications 4 et 5, dans lequel, dans le cas où le réseau comprend une pluralité de noeuds de gestion, le noeud qui marque les paquets de données de signalisation est celui qui, en premier, reçoit ces données et a pour rôle de les retransmettre vers le réseau à travers un lien W. 7. Procédé selon l'une des revendications 1 à 6, dans lequel, lors de l'activation du canal, le noeud de gestion (4) traite (E2) le canal de signalisation à activer de façon prioritaire par rapport à tout autre canal pour le transport de données média lors de l'exécution d'un mécanisme de contrôle d'admission du canal de signalisation à activer.
8. Procédé selon la revendication 7, dans lequel le noeud de gestion (4) traite (E2) le canal de signalisation à activer de façon prioritaire par rapport à tout autre canal pour le transport de données média lors de l'exécution de l'un au moins des deux mécanismes de traitement de qualité de service suivants: - le mécanisme d'allocation de ressources différentiées et - le mécanisme de préemption de ressources d'un autre canal au profit dudit canal de signalisation en cas de congestion.
9. Noeud de gestion pour un réseau de transmission en mode paquet, comprenant - des moyens (41) de détection d'un canal de signalisation, agencés pour déterminer si, dans un profil de qualité de service associé à un canal de transport de données, un paramètre d'indication de signalisation (SI) est activé afin de détecter s'il s'agit d'un canal de signalisation, des moyens (42) pour commander le noeud de façon à ce qu'il traite ledit canal de signalisation de façon prioritaire par rapport à tout autre canal pour le transport de données média lors de l'exécution d'au moins un mécanisme de traitement de qualité de service appliqué au canal de signalisation.
10. Noeud de gestion selon la revendication 9, comprenant des moyens (43) de modification du profil de qualité de service dudit canal de signalisation, agencés pour modifier au moins l'un des paramètres du groupe comprenant la classe de trafic et tout paramètre définissant une priorité relative du canal de signalisation pour l'allocation de ressources et/ou la préemption, afin d'augmenter le niveau de priorité du canal de signalisation à activer.
11. Noeud de gestion selon l'une des revendications 9 et 10, dans lequel les moyens (43) de modification du profil de qualité de service sont agencés pour modifier, dans le profil de qualité de service demandé, au moins un débit à travers le canal afin d'optimiser l'utilisation des ressources réseau.
12. Noeud de gestion selon l'une des revendications 9 à 11, comprenant des moyens (44) de marquage, agencés pour marquer les paquets de données de signalisation de manière à ce que le réseau assure un traitement prioritaire desdits paquets lors de leur transport.
13. Noeud de gestion selon la revendication 12, dans lequel les moyens de marquage sont agencés pour marquer les paquets de données de signalisation à l'aide d'un champ DSCP (DiffServ Code Point).
14. Réseau de transmission en mode paquet, comprenant au moins un noeud
selon l'une des revendications 9 à 13.
15. Module logiciel (40) de traitement de données, pour un noeud de gestion d'un réseau de transmission en mode paquet, comprenant des instructions logicielles pour commander l'exécution par le noeud des étapes du procédé selon l'une des revendications 1 à 8.
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0502177A FR2882879A1 (fr) | 2005-03-03 | 2005-03-03 | Procede de traitement de la qualite de service d'un canal de transport et noeud de gestion pour sa mise en oeuvre |
| US11/885,683 US7796559B2 (en) | 2005-03-03 | 2006-03-03 | Method for processing quality of service of a data transport channel |
| CNA200680001301XA CN101069451A (zh) | 2005-03-03 | 2006-03-03 | 用于处理数据传输信道的服务质量的方法 |
| EP06726216A EP1854323A1 (fr) | 2005-03-03 | 2006-03-03 | Procede de traitement de la qualite de service d'un canal de transport de donnees |
| PCT/FR2006/050192 WO2006092541A1 (fr) | 2005-03-03 | 2006-03-03 | Procede de traitement de la qualite de service d'un canal de transport de donnees |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0502177A FR2882879A1 (fr) | 2005-03-03 | 2005-03-03 | Procede de traitement de la qualite de service d'un canal de transport et noeud de gestion pour sa mise en oeuvre |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2882879A1 true FR2882879A1 (fr) | 2006-09-08 |
Family
ID=34954662
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0502177A Withdrawn FR2882879A1 (fr) | 2005-03-03 | 2005-03-03 | Procede de traitement de la qualite de service d'un canal de transport et noeud de gestion pour sa mise en oeuvre |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US7796559B2 (fr) |
| EP (1) | EP1854323A1 (fr) |
| CN (1) | CN101069451A (fr) |
| FR (1) | FR2882879A1 (fr) |
| WO (1) | WO2006092541A1 (fr) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7957276B2 (en) * | 2005-04-28 | 2011-06-07 | Telcordia Licensing Company, Llc | Call admission control and preemption control over a secure tactical network |
| US8660555B2 (en) * | 2006-11-03 | 2014-02-25 | Core Wireless Licensing S.A.R.L. | Quality of service mechanism |
| US20110222406A1 (en) * | 2008-11-11 | 2011-09-15 | Fredrik Persson | Method And Device For Enabling Indication Of Congestion In A Telecommunications Network |
| WO2011026264A1 (fr) * | 2009-09-01 | 2011-03-10 | 华为技术有限公司 | Procédé et appareil de détection de performances multiservices dans un tunnel |
| CN103686747B (zh) * | 2012-09-21 | 2018-10-12 | 中兴通讯股份有限公司 | 一种次级系统在数据库中进行注册的方法及设备及系统 |
| EP2930993A1 (fr) * | 2014-04-09 | 2015-10-14 | Telefonaktiebolaget L M Ericsson (PUBL) | Détermination de priorité pour la signalisation |
| CN104125221B (zh) * | 2014-07-17 | 2017-05-24 | 东北大学 | Ims终端设备多软终端资源共享和应用协同装置及方法 |
| US20230038198A1 (en) * | 2021-08-03 | 2023-02-09 | At&T Intellectual Property I, L.P. | Dynamic wireless network throughput adjustment |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020114305A1 (en) * | 2001-02-09 | 2002-08-22 | Johnson Oyama | Signaling quality of service class for use in multimedia communicatations |
| WO2003081843A1 (fr) * | 2002-03-27 | 2003-10-02 | Telefonaktiebolaget Lm Ericsson (Publ) | Facturation dans un reseau de communication |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7298697B2 (en) * | 2000-04-10 | 2007-11-20 | Nokia Corporation | Setting a communication channel |
| US7209439B2 (en) * | 2001-03-20 | 2007-04-24 | Mci, Llc | Pool-based resource management in a data network |
| US20040184432A1 (en) * | 2003-03-19 | 2004-09-23 | Ralitsa Gateva | Method for controlling streaming services |
| EP1763971B1 (fr) * | 2004-07-05 | 2009-12-09 | TELEFONAKTIEBOLAGET LM ERICSSON (publ) | Mecanisme de liaison pour la gestion de la qualite de service dans un reseau de communication |
| US20080068995A1 (en) * | 2004-07-05 | 2008-03-20 | Robert Skog | Devices and Methods for Push Message Initiated Service |
| US20060114855A1 (en) * | 2004-11-30 | 2006-06-01 | Haihong Zheng | Quality of service (QOS) signaling for a wireless network |
-
2005
- 2005-03-03 FR FR0502177A patent/FR2882879A1/fr not_active Withdrawn
-
2006
- 2006-03-03 US US11/885,683 patent/US7796559B2/en not_active Expired - Fee Related
- 2006-03-03 CN CNA200680001301XA patent/CN101069451A/zh active Pending
- 2006-03-03 EP EP06726216A patent/EP1854323A1/fr not_active Withdrawn
- 2006-03-03 WO PCT/FR2006/050192 patent/WO2006092541A1/fr active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020114305A1 (en) * | 2001-02-09 | 2002-08-22 | Johnson Oyama | Signaling quality of service class for use in multimedia communicatations |
| WO2003081843A1 (fr) * | 2002-03-27 | 2003-10-02 | Telefonaktiebolaget Lm Ericsson (Publ) | Facturation dans un reseau de communication |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1854323A1 (fr) | 2007-11-14 |
| US20080279108A1 (en) | 2008-11-13 |
| CN101069451A (zh) | 2007-11-07 |
| WO2006092541A1 (fr) | 2006-09-08 |
| US7796559B2 (en) | 2010-09-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1792447B1 (fr) | Procede de preemption pour la gestion des ressources radio dans un reseau de communication mobile | |
| US8719895B1 (en) | Determining a policy output for a communication session | |
| EP1767033B1 (fr) | Procede de gestion des ressources radio dans un reseau d'acces radio de type utran | |
| FR2882879A1 (fr) | Procede de traitement de la qualite de service d'un canal de transport et noeud de gestion pour sa mise en oeuvre | |
| EP1665661B1 (fr) | Procede de differenciation de la qualite de service dans les reseaux de communication mobile en mode paquets | |
| JP4838320B2 (ja) | データパケットの伝送におけるサービス品質を指定する方法および装置 | |
| CA2658620C (fr) | Allocation d'une ressource qos predictive pour l'etablissement rapide d'une session | |
| US20040218607A1 (en) | Handling traffic flows in a mobile communications network | |
| EP1241910A1 (fr) | Procédé pour le contrôle de session d'appel multimedia dans un système cellulaire de radiocommunications mobiles | |
| CA2658619C (fr) | Groupage de signaux de communication a des fins d'efficacite | |
| JP2007151187A (ja) | Ｐｄｐコンテクストエラー取り扱い方法 | |
| FR2825561A1 (fr) | Procede de transmission de paquets ip a travers un systeme cellulaire de radiocommunication, et equipements du systeme cellulaire pour la mise en oeuvre de ce procede | |
| US20110305240A1 (en) | Call admission and preemption for multiple bit-rate applications | |
| EP3216181B1 (fr) | Procede de controle des politiques de trafic depuis un module de securite dans un terminal mobile | |
| EP1443779B1 (fr) | Procédé pour la gestion de la qualité de service dans un système de radiocommunications mobiles | |
| EP3162026B1 (fr) | Procédé d'autorisation d'établissement d'un flux pair à pair dans un réseau de télécommunications mobiles | |
| FR2896645A1 (fr) | Procede de gestion de la qualite de service, entite de gestion, point d'attachement, terminal mobile et programmes d'ordinateur correspondants | |
| WO2018078293A1 (fr) | Système pour hiérarchiser les applications informatiques mises en œuvre par un groupe d'utilisateurs | |
| WO2023104724A1 (fr) | Procédé d'émission d'un flux de données dans un réseau de communications, procédé de traitement d'un flux de données, procédé de contrôle du traitement d'un flux de données, dispositifs, équipement terminal, entité d'exécution, entité de contrôle, système et programmes d'ordinateur correspondants. | |
| WO2003075521A1 (fr) | Reseau de communication de paquets de donnees | |
| FR3014281A1 (fr) | Equipement de passerelle d'acces de mobiles a internet | |
| FR2843519A1 (fr) | Gestion differenciee du trafic non-umts au sein d'un reseau d'acces umts |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20061130 |