ES2673604T3 - Técnicas para gestionar tráfico de red - Google Patents
Técnicas para gestionar tráfico de red Download PDFInfo
- Publication number
- ES2673604T3 ES2673604T3 ES15202169.7T ES15202169T ES2673604T3 ES 2673604 T3 ES2673604 T3 ES 2673604T3 ES 15202169 T ES15202169 T ES 15202169T ES 2673604 T3 ES2673604 T3 ES 2673604T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- packet
- service
- identifier
- filter
- 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.)
- Active
Links
Classifications
-
- 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
- H04W28/0252—Traffic management, e.g. flow control or congestion control per individual bearer or channel
- H04W28/0263—Traffic management, e.g. flow control or congestion control per individual bearer or channel involving mapping traffic to individual bearers or channels, e.g. traffic flow template [TFT]
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R19/00—Wheel guards; Radiator guards, e.g. grilles; Obstruction removers; Fittings damping bouncing force in collisions
- B60R19/02—Bumpers, i.e. impact receiving or absorbing members for protecting vehicles or fending off blows from other vehicles or objects
- B60R19/04—Bumpers, i.e. impact receiving or absorbing members for protecting vehicles or fending off blows from other vehicles or objects formed from more than one section in a side-by-side arrangement
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R19/00—Wheel guards; Radiator guards, e.g. grilles; Obstruction removers; Fittings damping bouncing force in collisions
- B60R19/02—Bumpers, i.e. impact receiving or absorbing members for protecting vehicles or fending off blows from other vehicles or objects
- B60R19/18—Bumpers, i.e. impact receiving or absorbing members for protecting vehicles or fending off blows from other vehicles or objects characterised by the cross-section; Means within the bumper to absorb impact
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R19/00—Wheel guards; Radiator guards, e.g. grilles; Obstruction removers; Fittings damping bouncing force in collisions
- B60R19/02—Bumpers, i.e. impact receiving or absorbing members for protecting vehicles or fending off blows from other vehicles or objects
- B60R19/24—Arrangements for mounting bumpers on vehicles
- B60R19/26—Arrangements for mounting bumpers on vehicles comprising yieldable mounting means
- B60R19/34—Arrangements for mounting bumpers on vehicles comprising yieldable mounting means destroyed upon impact, e.g. one-shot type
-
- 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/20—Traffic policing
-
- 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/43—Assembling or disassembling of packets, e.g. segmentation and reassembly [SAR]
- H04L47/431—Assembling or disassembling of packets, e.g. segmentation and reassembly [SAR] using padding or de-padding
-
- 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
- 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/18—Negotiating wireless communication parameters
- H04W28/22—Negotiating communication rate
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mechanical Engineering (AREA)
- Databases & Information Systems (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Monitoring And Testing Of Exchanges (AREA)
Abstract
Un procedimiento de gestión de tráfico de red, que comprende: - recibir datos de inspección de paquetes que indican el tráfico de datos relacionado con el servicio de un usuario específico y/o un servicio específico; - determinar un filtro de paquetes (72, 74) en base a dichos datos de inspección de paquetes, en el que dicho filtro de paquetes (72, 74) está configurado para filtrar el tráfico de datos en base a un identificador incluido en los paquetes de datos de dicho tráfico de datos relacionados con el servicio en respuesta a la inspección de paquetes; y - configurar el filtro de paquetes (72, 74) en una pasarela (26).
Description
5
10
15
20
25
30
35
40
45
50
DESCRIPCION
Técnicas para gestionar tráfico de red Sector técnico
La presente invención se refiere a técnicas para gestionar tráfico de red Antecedentes
En las redes de comunicación móvil es conocido el dirigir tráfico de red relacionado con un servicio específico a una portadora con una cierta calidad de servicio (QoS, quality of service). A este respecto, se considera que una portadora es un trayecto o contexto de transmisión de información, de características definidas, por ejemplo la capacidad, el retardo y/o la tasa de bits erróneos. Habitualmente, se establecerán una serie de portadoras entre una pasarela de una red de comunicación móvil y un equipo de usuario, por ejemplo un teléfono móvil u otro tipo de terminal móvil. Una portadora puede transportar tráfico de datos de enlace descendente (DL) en el sentido de la red al equipo de usuario, y puede transportar tráfico de datos en el sentido del enlace ascendente (UL) desde el equipo de usuario a la red. En la pasarela y en el equipo de usuario el tráfico de datos, que incluye una serie de paquetes de datos de IP (IP: "Internet Protocol", protocolo de internet) se puede filtrar utilizando filtros de paquetes de 5-tuplas de IP, dirigiendo de ese modo los paquetes de datos de IP a una portadora deseada.
Específicamente, se desea dirigir el tráfico de datos relativo a un servicio específico, por ejemplo TV móvil, a una portadora que ofrece una cierta QoS. Para este propósito, el tráfico de datos de DL puede estar sujeto a inspección de paquetes para identificar paquetes de datos relacionados con un servicio específico. Cuando se detectan paquetes de datos de un servicio predefinido, esto se puede señalizar a un controlador de políticas. El controlador de políticas puede generar a continuación filtros de paquetes correspondientes y señalizar estos filtros de paquetes a la pasarela. La pasarela utiliza a continuación los filtros de paquetes recibidos para encaminar los paquetes de datos a una portadora deseada. La portadora tiene habitualmente una clase de QoS que ha sido escogida por el operador de red para el servicio específico. En este proceso, puede haber asimismo señalización al equipo de usuario, por ejemplo para establecer una portadora e indicar filtros de paquetes de UL al equipo de usuario, que se deberían utilizar para encaminar tráfico de datos de UL sobre la portadora.
Sin embargo, la solución conocida puede tener problemas porque un servicio puede abrir o cerrar frecuentemente flujos de paquetes de IP asociados con el mismo servicio, por ejemplo tal como realizan ciertas aplicaciones de compartición de archivos entre pares. En este caso, el resultado sería una señalización considerable para establecer los filtros de paquetes con el fin de encaminar los paquetes de datos sobre la portadora deseada. Además, el encaminamiento de tráfico de datos de DL utilizando filtros de paquetes basados en 5-tuplas de IP requiere considerables recursos de procesamiento en la pasarela. Asimismo, en algunos casos puede ser difícil o imposible para una función de inspección de paquetes describir suficientemente flujos de paquetes de IP asociados con un servicio específico y señalizar esto al controlador de políticas. Por ejemplo, éste puede ser el caso si los flujos de paquetes de IP están cifrados o si el servicio está asociado con una gran cantidad de flujos de paquetes de IP, por ejemplo en el caso de ciertas aplicaciones de compartición de archivos entre pares.
Por consiguiente, existe una necesidad de técnicas potentes y eficientes para gestionar tráfico de red, que permitan asignar tráfico de datos de un servicio específico a un nivel deseado de QoS.
En el documento 3GPP TS 23.203 V7.5.0, se describe un diseño de políticas y control de cobros que utiliza filtros de paquetes que funcionan en base a la 5-tupla de IP y, opcionalmente, también otros parámetros.
En el documento WO 2007/087828, se describe un filtro de paquetes instalado en un equipo de usuario. El filtro de paquetes funciona en base a la identificación del nivel de encaminamiento incluida en el paquete de datos, que puede ser la 5-tupla de IP o subconjuntos de la misma. Además, se describe el filtrado de paquetes en base a otros parámetros, por ejemplo, un Punto de Código de Servicios Diferenciados.
En el documento US 2007/0081499 A1 esto se describe para generar filtros de paquetes de enlace ascendente en base a filtros de paquetes de enlace descendente “replicando” los filtros de paquetes de enlace descendente.
Compendio
De acuerdo con las realizaciones de la invención, se da a conocer un procedimiento según la reivindicación 1 y un componente de red según la reivindicación 10. Las reivindicaciones dependientes definen realizaciones adicionales de la invención.
Breve descripción de los dibujos
La figura 1 muestra esquemáticamente un entorno de comunicación móvil en el que se pueden aplicar conceptos según las realizaciones de la invención a la gestión de tráfico de datos de DL.
5
10
15
20
25
30
35
40
45
50
55
La figura 2 muestra esquemáticamente un ejemplo de un paquete de datos tal como se utiliza en una realización de la invención.
La figura 3 muestra esquemáticamente otro ejemplo de un paquete de datos tal como se utiliza en una realización de la invención.
La figura 4 muestra esquemáticamente un campo de información en una sección de cabecera de paquetes de datos.
La figura 5 muestra un diagrama de flujo para ilustrar un procedimiento de gestión de tráfico de datos de DL, de acuerdo con una realización de la invención.
La figura 6 muestra esquemáticamente un entorno de comunicación móvil en el que se pueden aplicar conceptos según las realizaciones de la presente invención a la gestión de tráfico de datos de UL.
La figura 7 muestra esquemáticamente un identificador y un identificador complementario en paquetes de datos.
La figura 8 muestra un diagrama de flujo para ilustrar un procedimiento de gestión de tráfico de datos de UL según una realización de la invención.
Descripción detallada de realizaciones
En lo que sigue, se explicará la invención en mayor detalle haciendo referencia a realizaciones a modo de ejemplo y a los dibujos adjuntos. Las realizaciones mostradas se refieren a gestionar tráfico de datos en una red de comunicación móvil, por ejemplo de acuerdo con las especificaciones de 3GPP (Third Generation Partnership Project, proyecto de asociación de tercera generación). Sin embargo, se debe entender que los conceptos que se describen en la presente memoria pueden ser aplicados asimismo a otros tipos de redes de comunicaciones. En relación con las figuras 1 a 5, se describirán conceptos para gestionar tráfico de datos de DL, es decir hacia un equipo de usuario. En relación con las figuras 6 a 8, se describirán conceptos para gestionar tráfico de datos de UL, es decir desde un equipo de usuario. Por lo tanto, los conceptos de gestión de tráfico de datos de DL y los conceptos de gestión de tráfico de datos de UL se describirán por separado. No obstante, se debe entender que estos conceptos pueden ser aplicados independientemente o en combinación.
La figura 1 muestra esquemáticamente un entorno de comunicación móvil en el que el tráfico de datos de DL se gestiona de acuerdo con una realización de la invención.
El entorno de red incluye un equipo de usuario 10, que se puede denominar asimismo un terminal, y una serie de componentes de red 22, 24, 26, 30, 100. Entre estos componentes de red, hay una red de acceso radio (RAN, Radio Access Network) 22. La RAN está basada en cierto tipo o tipos de tecnología de acceso radio, por ejemplo GSM (Global System for Mobile communications, sistema global para comunicaciones móviles), EDGE (Enhanced Data Rate for GSM Evolution, velocidad de datos mejorada para evolución de GSM) o UMTS (Universal Mobile Telecommunications System, sistema universal de telecomunicaciones móviles). Aunque la RAN 22 se muestra como un único nodo, se debe entender que la RAN 22 puede estar formada de hecho por una serie de componentes, que no se explican más en la presente memoria. La RAN 22 está acoplada a un nodo de transporte 24, que a su vez está acoplado a una pasarela 26. En este caso, se debe entender que alternativamente puede estar acoplado más de un nodo de transporte 24 entre la RAN 22 y la pasarela 26, o que la RAN 22 puede estar acoplada directamente a la pasarela 26. La pasarela 26 puede ser un nodo de soporte GPRS pasarela (GGSN, Gateway GPRS Support Node) que proporciona una conexión de servicios basados en GPRS (GPRS: "General Packet Radio Service", servicio general de paquetes por radio) a uno o varias redes de datos de paquetes externas. La pasarela 26 puede ser asimismo una pasarela de evolución de la arquitectura de sistema (sAe GW, System Architecture Evolution Gateway) según las especificaciones 3GPP.
Además, la red de comunicación móvil incluye un controlador de políticas 30, que está implementado como una función de políticas y reglas de cobro (PCRf, Policy and Charging Rules Function) según las especificaciones 3GPP, y un inspector de paquetes 100. El controlador de políticas puede estar implementado mediante hardware dedicado o como una función de software ejecutada por un procesador. El inspector de paquetes 100 puede estar implementado mediante hardware dedicado o como una función de software ejecutada por un procesador. El inspector de paquetes 100 puede estar configurado para implementar una inspección de paquetes profunda (DPI, Deep Packet inspection), que puede estar basada en examinar tanto una sección de cabecera como una sección de datos de un paquete de datos. Además, la inspección puede estar basada asimismo en la obtención de medidas heurísticas tales como el tiempo entre llegadas de paquetes, los patrones de envío y el tamaño de los paquetes. Dicha heurística se puede aplicar incluso en caso de cifrado. Las secciones de cabecera y las secciones de datos se pueden examinar en diferentes capas de protocolo, por ejemplo en la capa de aplicación o en capas inferiores, para identificar diferentes servicios y protocolos. La inspección se puede llevar a cabo asimismo con respecto a señalización de control relativa a sesiones. Sin embargo, se pueden implementar asimismo otros tipos de procesos de inspección de paquetes, por ejemplo basados simplemente en una inspección de una sección de cabecera.
La pasarela 26, el controlador de políticas 30 y el inspector de paquetes 100 se consideran habitualmente componentes de una red central.
5
10
15
20
25
30
35
40
45
50
55
60
El controlador de políticas 30 comunica con el inspector de paquetes 100 por medio del trayecto de señalización 5. El trayecto de señalización 5 se puede implementar utilizando la interfaz de Rx o la interfaz de Gx, según las especificaciones 3GPP. Además, el controlador de políticas 30 comunica con la pasarela 26 por medio de un trayecto de señalización 6, que se puede implementar utilizando la interfaz Gx según las especificaciones 3GPP.
El controlador de políticas 30 está acoplado además a una base de datos de suscripciones 32 y a una base de datos de políticas de servicio 34 por medio de un trayecto de señalización 8, por ejemplo implementado utilizando una interfaz Sp según las especificaciones 3GPP. Por lo tanto, el controlador de políticas 30 puede recibir datos de políticas relativos a un usuario específico y/o relativos a un servicio específico disponible en la red de comunicación móvil, por ejemplo TV móvil.
El controlador de políticas 30 proporciona por lo tanto interfaces para soportar los trayectos de señalización 5, 6, 8.
Tal como se muestra además, el tráfico de datos relacionado con el servicio, entre la red y el equipo de usuario 10 se lleva a cabo mediante una serie de portadoras 52, 54. El tráfico de datos relacionado con el servicio pertenece habitualmente a una o varias aplicaciones cliente/par 12 ejecutándose en el equipo de usuario 10. Las portadoras 52, 54 se establecen entre el equipo de usuario 10 y la pasarela 26. Las portadoras 52, 54 transportan tráfico de datos tanto en el sentido de DL como en el sentido de UL, es decir se puede considerar asimismo que se están formadas por una portadora de DL y una portadora de UL. Para soportar comunicación bidireccional sobre las portadoras 52, 54, el equipo de usuario 10 está dotado de una estructura de transceptor, es decir tanto de un receptor 14 para recibir paquetes de datos entrantes desde las portadoras 52, 54 como de un transmisor 16 para enviar paquetes de datos salientes sobre las portadoras 52, 54. Las portadoras 52, 54 pueden incluir una portadora por defecto, establecida en general para ofrecer servicios basados en paquetes al equipo de usuario 10, y una o varias portadoras dedicadas 54 que pueden tener un nivel de QoS diferente, por ejemplo un nivel de QoS mayor, que la portadora por defecto. Cada portadora 52, 54 puede estar asociada con un correspondiente perfil de QoS. Los parámetros del perfil de QoS pueden ser un identificador de clase de QoS (QCI, QoS class ), una prioridad de asignación/retención (ARP, allocation/retention priority), una tasa de bits máxima (MBR, maximum bit rate) y/o una tasa de bits garantizada (GBR, guaranteed bit rate). Por consiguiente, cada portadora 52, 54 puede estar asociada con una correspondiente clase de QoS.
En el equipo de usuario 10, los paquetes de datos son encaminados a una portadora deseada 52, 54 utilizando filtros de paquetes de UL 62, 64 configurados correspondientemente. En la pasarela 26, los paquetes de datos son encaminados a las portadoras deseadas 52, 54 utilizando filtros de paquetes de DL 72, 74 configurados correspondientemente. Se pueden señalizar parámetros del perfil de QoS desde el controlador de políticas 30 a la pasarela 26 utilizando el trayecto de señalización 6. Análogamente, los filtros de paquetes de DL 72, 74 para su utilización en la pasarela 26 se pueden señalizar desde el controlador de políticas 30 a la pasarela 26 por medio del trayecto de señalización 6. En relación con los filtros de paquetes de UL 62, 64 utilizados en el equipo de usuario 10, éstos se pueden señalizar desde el controlador de políticas 30 por medio de la pasarela 26. Sin embargo, en otras realizaciones, tal como se explicará en mayor detalle en relación con las figuras 6 a 8, los filtros de paquetes de UL 62, 64 se pueden generar asimismo en respuesta a la recepción de tráfico de datos en el equipo de usuario 10.
En la red de comunicación móvil que se muestra en la figura 1, el tráfico de datos de DL del equipo de usuario 10 pasa por el inspector de paquetes 100 antes de ser recibido por la pasarela 26. El inspector de paquetes 100 identifica paquetes de datos pertenecientes a uno o varios servicios predefinidos y/o pertenecientes a un usuario específico. Esto se puede conseguir en base a los datos de control de inspección de paquetes recibidos desde el controlador de políticas 30. Si se identifican paquetes de datos pertenecientes a un servicio predefinido específico, el inspector de paquetes 100 proporciona una indicación respectiva al controlador de políticas 30 enviando datos de inspección de paquetes. Además, el inspector de paquetes 100 incluye una función de marcado 120, que incluye un identificador en el paquete de datos inspeccionado. La función de marcado 120 puede ser implementada por un hardware dedicado o como una función de software que se ejecuta en un procesador. El identificador se selecciona de acuerdo con el servicio identificado al que pertenece el paquete de datos. Por ejemplo, los paquetes de datos que pertenecen a un cierto servicio de compartición de archivos pueden recibir un primer identificador, y los paquetes de datos que pertenecen a un cierto servicio de transferencia continua de multimedia pueden recibir un segundo identificador. Incluir el identificador en los paquetes de datos, o marcar los paquetes de datos, se consigue por lo tanto en base al resultado de la inspección de paquetes o puede incluso formar parte del proceso de inspección de paquetes. El identificador se puede incluir en los paquetes de datos configurando un campo de información en una sección de cabecera del paquete de datos, por ejemplo configurando un punto de código de servicios diferenciados (DSCP, differentiated services code point) específico. El mapeo de un servicio específico a un correspondiente identificador puede ser controlado dinámicamente por el controlador de políticas 30 utilizando los datos de control de la inspección de paquetes. De este modo, el mapeo entre un servicio específico y un identificador correspondiente se puede controlar dinámicamente en base a datos de políticas. Por ejemplo, el mapeo podría variar en función de la hora del día o del día de la semana.
En base a los datos de inspección de paquetes recibidos del inspector de paquetes 100 y en base a los datos de políticas, el controlador de políticas 30 controla la selección y/o la configuración de los filtros de paquetes de DL 72, 74 utilizados en la pasarela 26 para encaminar paquetes de datos a portadoras deseadas 52, 54. Para este propósito, el controlador de políticas 30 incluye un generador 35 de filtros. El generador de filtros puede estar
5
10
15
20
25
30
35
40
45
50
55
implementado mediante hardware dedicado o como una función de software ejecutada por un procesador. El generador de filtros 35 puede construir los filtros de paquetes de DL, seleccionar filtros de paquetes de DL preconfigurados a partir de una lista y/o configurar filtros de paquetes de DL seleccionados. Los filtros de paquetes de DL 72, 74 filtran el tráfico de datos de DL en base al identificador que ha sido incluido en los paquetes de datos por el inspector de paquetes 100. Esto permite un proceso de filtrado muy eficiente y fiable, dado que los filtros de paquetes de DL 72, 74 tienen únicamente que tener en cuenta el identificador incluido por el inspector de paquetes 100. Por ejemplo, si el identificador es un DSCP en la sección de cabecera de los paquetes de datos, los filtros de paquetes de DL 72, 74 necesitan tan sólo analizar el campo de información de DSCP en la sección de cabecera de los paquetes de datos. De este modo, el tráfico de datos que pertenece a un servicio específico puede ser encaminado dinámicamente a una portadora deseada 52, 54 con una clase de QoS correspondiente.
En lo que sigue, se explicarán en mayor detalle conceptos de marcado de paquetes de datos inspeccionados, haciendo referencia a tipos de paquetes de datos a modo de ejemplo.
La figura 2 muestra esquemáticamente paquetes de datos de IP del tipo IP versión 4. Tal como se muestra, una sección de cabecera de los paquetes de datos incluye varios campos de información, que se denominan "Versión", "IHL (IP Header Length, longitud de cabecera de IP)", "Servicios diferenciados", "Longitud total", "Identificación", "Indicadores", "Desplazamiento de fragmento", "Tiempo de vida", "Protocolo", "Suma de comprobación de cabecera", "Dirección de origen", "Dirección de destino", "Opciones" y "Relleno". Se definen detalles relativos a estos campos en la especificación RFC 791. El campo de información denominado "Servicios diferenciados" se define en la especificación RFC 2475. Además, la sección de cabecera de un paquete de datos de IP incluirá asimismo campos de información que se denominan "Puerto de origen" y "Puerto de destino". Se definen campos de información correspondientes, por ejemplo, mediante el protocolo de control de transporte (TCP, Transport Control Protocol) definido en la especificación RFC 793 y el protocolo de datagramas de usuario (UDP, User Datagram Protocol) que se define en la especificación RFC 768.
A continuación de la sección de cabecera, están dispuestos habitualmente paquetes de datos de IP en una sección de datos, en la que pueden estar incluidos diferentes tipos de tráfico de datos de carga útil.
La figura 3 muestra esquemáticamente paquetes de datos de IP de acuerdo con el tipo de IP versión 6. De nuevo, la sección de cabecera incluye una serie de campos de información, que se denominan "Versión", "Servicios diferenciados", "Etiqueta de flujo", "Longitud de carga útil", "Siguiente cabecera", "Límite de saltos", "Dirección de origen" y "Dirección de destino". Esta estructura de la sección de cabecera se define en la especificación RFC 2460. Además, la sección de cabecera puede comprender asimismo campos de información denominados "Puerto de origen" y "Puerto de destino", por ejemplo tal como se define mediante TCP o UDP. De nuevo, la sección de cabecera estará seguida habitualmente por una sección de datos que puede llevar varios tipos de datos de carga útil.
Para los objetivos de la presente descripción, se explicarán en mayor detalle solamente los campos de información denominados "Servicios diferenciados", "Dirección de origen", "Dirección de destino", "Puerto de origen" y "Puerto de destino". En relación con los otros campos de información, se pueden extraer explicaciones adicionales de las especificaciones RFC mencionadas anteriormente.
El campo de información "Dirección de origen" indica la dirección IP desde la que se origina un paquete de datos. Análogamente, el campo de información "Dirección de destino" indica la dirección IP a la que está destinado el paquete de datos. En IP versión 4, la dirección de origen y la dirección de destino son valores de 32 bits. En IP versión 6, la dirección de origen y la dirección de destino son valores de 128 bits.
El campo de información "Puerto de origen" indica un número de puerto en el origen del paquete de datos, mientras que el campo de información "Puerto de destino" indica un número de puerto en el punto de destino del paquete de datos.
En base a la dirección de origen, a la dirección de destino, al puerto de origen y al puerto de destino, un flujo de paquetes IP se puede definir como un flujo de paquetes IP entre un primer punto extremo definido por la dirección de origen y el puerto de origen, y un segundo punto extremo definido por la dirección de destino y el puerto de destino. Una entidad que incluye la dirección de origen, la dirección de destino, el puerto de origen, el puerto de destino y un identificador de protocolo se denomina asimismo una "5-tupla de IP".
El campo de información "Servicios diferenciados" está incluido tanto en los paquetes de datos de IP versión 4 como en los paquetes de datos de IP versión 6. Tal como se define en la especificación RFC 2474, el campo de información "Servicios diferenciados" es un valor de 8 bits. La estructura de este campo de información se muestra esquemáticamente en la figura 4.
Tal como se muestra en la figura 4, se utilizan seis bits del campo de información, es decir los bits 0 a 5, para definir el Punto de código de servicios diferenciados (DSCP). Los otros dos bits nos utilizan. Utilizando el DSCP, se puede controlar el envío de paquetes de datos mediante nodos de red. Para paquetes de datos que pertenecen a diferentes tipos de servicios se pueden seleccionar procedimientos de transmisión diferentes. Los DSCP pueden estar estandarizados. Además, está disponible una amplia gama de DSCP no estandarizados.
5
10
15
20
25
30
35
40
45
50
55
En lo que sigue, se describirá en mayor detalle un proceso de gestión de tráfico de datos de DL, de acuerdo con una realización de la invención. Esto se llevará a cabo haciendo referencia al entorno de red de comunicación móvil que se muestra en la figura 1.
Tal como se ha mencionado anteriormente, la red de comunicación móvil puede soportar una serie de clases de QoS asociadas con diferentes portadoras. Las clases de QoS se pueden identificar mediante un QCI correspondiente. Para marcar paquetes de datos identificados de un servicio específico en el inspector de paquetes 100, se define un DSCP dedicado, por ejemplo a partir de la gama de DSCP no estandarizados. Como resultado, puede haber un DSCP dedicado por cada portadora.
Además, se define una tabla de mapeo que mapea cada servicio a detectar por el inspector de paquetes 100 a un DSCP dedicado. Por lo tanto, pueden ser utilizados diferentes DSCP dedicados para marcar paquetes de datos pertenecientes a diferentes servicios. Sin embargo, es posible asimismo que se marquen paquetes de datos de diferentes servicios con el mismo DSCP, por ejemplo si estos servicios deberían ser asignados a la misma clase de QoS. Esta tabla de mapeo puede estar mantenida por el controlador de políticas 30 y además ser comunicada al inspector de paquetes 100, por ejemplo utilizando el trayecto de señalización 5. Alternativamente, el inspector de paquetes 100 puede asimismo configurarse de manera estática con la tabla de mapeo. Si la tabla de mapeo en el inspector de paquetes 100 es configurable dinámicamente mediante el controlador de políticas 30, es posible asimismo reconfigurar la tabla de mapeo en base a datos de políticas. Por ejemplo, la tabla de mapeo se podría reconfigurar en función de la hora del día o en función del día de la semana.
Si el inspector de paquetes 100 detecta un flujo de paquetes IP perteneciente a un servicio predefinido, esto se señaliza al controlador de políticas 30 en los datos de inspección de paquetes. Además, la función de marcado 120 del inspector de paquetes 100 marca los paquetes de datos pertenecientes al servicio con el DSCP que se ha definido en la tabla de mapeo. Para otros paquetes de datos, es decir paquetes de datos que no están identificados como pertenecientes a un servicio predefinido, se puede configurar un DSCP por defecto. Por ejemplo, el DSCP por defecto puede ser cero. Como alternativa, se puede omitir la configuración de un DSCP para paquetes de datos que no estén identificados como pertenecientes a un servicio predefinido. En los datos de inspección de paquetes, el inspector de paquetes 100 puede asimismo señalizar un identificador de servicio al controlador de políticas 30. Por medio del identificador de servicio, el servicio identificado y/o el DSCP utilizado para marcar los correspondientes paquetes de datos se pueden señalizar al controlador de políticas 30. La activación, basada en frecuencias o en eventos, de señalización hacia el controlador de políticas 30 se puede seleccionar adecuadamente.
En respuesta a los datos de inspección de paquetes, el controlador de políticas 30 determina un filtro de paquetes de DL que funciona en base al DSCP utilizado para el marcado de paquetes de datos del servicio identificado. De acuerdo con una realización, el filtro de paquetes de DL puede funcionar sustancialmente sólo en base al DSCP utilizado para marcar los paquetes de datos. El filtro de paquetes de DL se señaliza a la pasarela 26.
Utilizando el filtro de paquetes de DL, la pasarela 26 encamina a continuación los paquetes de datos de DL que están marcados con el DSCP, a la portadora correspondiente 52, 54. Ésta puede ser una portadora 52, 54 ya existente. Si la portadora no existe, ésta se puede establecer a la recepción de la señalización desde el controlador de políticas 30. Es decir, si está establecida ya una portadora 52, 54 que tiene la clase de QoS asociada con el DSCP, el filtro de paquetes de DL encaminará los paquetes de datos filtrados a esta portadora ya existente. Si no existe dicha portadora, se establecerá una portadora de la clase de QoS asociada con el DSCP, a la recepción de la señalización de filtro de paquetes de DL desde el controlador de políticas 30.
La figura 5 muestra un diagrama de flujo para ilustrar esquemáticamente un procedimiento 200 de gestión de tráfico de datos de DL, de acuerdo con los conceptos mencionados anteriormente.
En la etapa 210, se reciben datos de inspección de paquetes, por ejemplo en el controlador de políticas 30. Los datos de inspección de paquetes recibidos pueden incluir un identificador de servicio que indica un servicio al que pertenecen los paquetes de datos identificados. Además, los datos de inspección de paquetes pueden indicar un identificador que se utiliza para marcar los paquetes de datos en respuesta a la inspección de paquetes, por ejemplo un DSCP dedicado.
En la etapa 220, se reciben datos de políticas. Los datos de políticas pueden incluir políticas generales definidas por un operador de una red de comunicación móvil sobre cómo gestionar paquetes de datos de un servicio específico, o pueden estar relacionados con el usuario, es decir, definir cómo gestionar paquetes de datos de un servicio específico y un usuario específico. Los datos de políticas pueden distinguir asimismo entre diferentes grupos de abonados o pueden definir una cuota de volumen de un usuario, abonado, grupo de abonados o servicio. Específicamente, los datos de políticas pueden indicar qué clase de calidad de servicio se debería proporcionar a paquetes de datos pertenecientes a un servicio específico. Esta información puede variar dinámicamente, por ejemplo en base a la hora del día, al día de la semana, o a la cuota de volumen utilizada.
En la etapa 230, se determina el filtro de paquetes de DL en base a los datos de inspección de paquetes y a los datos de políticas. En particular, se determina un filtro de paquetes de DL que funciona en base a un identificador incluido en los paquetes de datos en respuesta al proceso de inspección de paquetes. El filtro de paquetes de DL se
5
10
15
20
25
30
35
40
45
50
55
60
utiliza a continuación para encaminar los paquetes de datos marcados a una portadora que tiene la clase de QoS deseada. Para este propósito, el filtro de paquetes de DL determinado se puede señalizar desde un controlador de políticas, por ejemplo el controlador de políticas 30, a una pasarela, por ejemplo la pasarela 26.
La figura 6 muestra esquemáticamente un entorno de comunicación móvil en el que el tráfico de datos de UL se gestiona de acuerdo con una realización de la invención. El entorno de comunicación móvil de la figura 6 es similar en general al de la figura 1, y los componentes similares se han indicado con signos de referencia similares. Para más detalles, se hace referencia a las explicaciones correspondientes en relación con la figura 1.
De acuerdo con los conceptos que se muestran en la figura 6, la información de los paquetes de datos de DL se utiliza en el equipo de usuario 10 para formar reglas locales para encaminar paquetes de datos de UL. En este caso, se debe observar que en un escenario de comunicación móvil, el flujo de paquetes de datos de IP es habitualmente bidireccional. Incluso si el transporte de datos de carga útil se produce solamente en un sentido, por ejemplo en base a paquetes TCP, el flujo de paquetes de IP incluirá asimismo habitualmente paquetes de control, por ejemplo paquetes de acuse de recibo TCP, transmitidos en el sentido opuesto. Además, las direcciones IP de origen y de destino, y los números de puerto de un flujo de paquetes IP son habitualmente simétricos, es decir el punto extremo de destino (identificado por una dirección IP y un número de puerto) en un sentido es el mismo que el punto extremo de origen (identificado por dirección IP y número de puerto) en el sentido opuesto, y viceversa. Debido a la simetría, los paquetes del mismo flujo de paquetes de IP que fluyen en sentidos opuestos tendrán identificadores de dirección "complementarios", e identificadores de puerto "complementarios", lo que significa que el identificador de origen en un sentido es el mismo que el identificador de destino en el sentido contrario.
De acuerdo con los conceptos de gestión de tráfico de datos de UL que se explican a continuación, se supondrá que el tráfico de datos de DL está ya mapeado a clases de QoS y portadoras correspondientes. Esto se puede conseguir de acuerdo con los conceptos explicados anteriormente en relación con la figura 1. Es decir, el entorno de comunicación móvil de la figura 6 podría incluir asimismo el inspector de paquetes 100 y funcionalidades asociadas para gestionar tráfico de datos de DL según se ha explicado en relación con la figura 1. No obstante, se debe entender que son aplicables asimismo otros conceptos de mapeo de tráfico de datos de DL a clases de QoS y portadoras.
Tal como se muestra en la figura 6, el equipo de usuario 10 incluye además una función de réplica 220. La función de réplica 220 puede ser implementada por un hardware dedicado o como una función de software que se ejecuta en un procesador. La función de réplica 220 está configurada para detectar paquetes de datos entrantes que
incluyen un primer identificador y paquetes de datos salientes que incluyen un segundo identificador que es
complementario con respecto al primer identificador. En el identificador complementario, un identificador de punto extremo de destino, por ejemplo dirección IP de destino y/o puerto de destino, es el mismo que un identificador del punto extremo de origen, por ejemplo dirección IP de origen y/o puerto de origen, en el identificador. Cada uno del primer y el segundo identificadores pueden ser una 5-tupla de IP. La función de réplica 220 controla los filtros de paquetes de UL 62, 64, que están basados en 5-tuplas de IP, de tal modo que los paquetes de datos salientes que tienen el segundo identificador complementario son encaminados a la misma portadora desde la que se reciben los paquetes de datos entrantes que tienen el primer identificador. De este modo, no es necesaria ninguna señalización explícita entre la pasarela 26 y el equipo de usuario 10 para seleccionar o configurar los filtros de paquetes de UL 62, 64. Si la función réplica 220 detecta que se ha mapeado un nuevo flujo de paquetes de IP sobre una portadora
52, 54 o que se ha establecido una nueva portadora 52, 54, la función réplica 220 generará automáticamente un
correspondiente filtro de paquetes de UL 62, 64. Si se identifican paquetes de datos en el sentido de DL mediante una 5-tupla de IP específica, el filtro de paquetes de UL 62, 64 estará configurado para encaminar paquetes de datos salientes que llevan una 5-tupla de IP complementaria, a la misma portadora desde la que se reciben los paquetes de datos entrantes.
La estructura de un identificador y un identificador complementario, que están basados en la 5-tupla de IP, se muestra en la figura 7. Sin embargo, se debe entender que son asimismo posibles otros tipos de identificadores e identificadores complementarios. En general, el identificador complementario indica el origen identificado en el identificador de un paquete de datos entrante como el destino de un paquete de datos saliente.
Tal como se muestra en la figura 7, un identificador en la base de la 5-tupla de IP puede incluir una dirección de origen A, una dirección de destino B, un puerto de origen C, un puerto de destino D y un identificador de protocolo X. El correspondiente identificador complementario tendrá entonces una dirección de origen B, una dirección de destino A, un puerto de origen D, un puerto de destino C y un identificador de protocolo X. En otras palabras, en el identificador complementario la dirección de origen y la dirección de destino están intercambiadas en comparación con el identificador. Análogamente, en el identificador complementario, el puerto de origen y el puerto de destino están intercambiados en comparación con el identificador. El identificador de protocolo permanece invariable. En otras realizaciones, pueden ser utilizados diferentes tipos de identificador e identificador complementario, por ejemplo en base a solamente una parte de la 5-tupla de IP. Por ejemplo, en el identificador complementario, se podrían intercambiar solamente la dirección de origen y la dirección de destino, en comparación con el identificador.
En lo que sigue, se explicará en mayor detalle un proceso de gestión de paquetes de datos de UL de acuerdo con una realización de la invención, haciendo referencia a las estructuras que se muestran en la figura 6.
5
10
15
20
25
30
35
40
45
50
55
60
Inicialmente, los paquetes de datos de UL relacionados con un servicio específico pueden ser transmitidos desde el equipo de usuario 10 a la pasarela 26 sobre una portadora arbitraria, por ejemplo sobre la portadora por defecto. Entonces, el correspondiente flujo de paquetes IP incluirá asimismo paquetes de datos transmitidos en el sentido de DL. Estos paquetes de datos serán mapeados a una clase de QoS deseada y la portadora correspondiente 52, 54, por ejemplo utilizando los conceptos que se han explicado en relación con la figura 1. Este proceso puede involucrar asimismo el establecimiento de una nueva portadora asociada con la clase de QoS deseada.
La función de réplica 220 en el equipo de usuario 10 detecta a continuación los paquetes de datos entrantes que se reciben de esta portadora 52, 54 y genera un filtro de paquetes de UL "replicado" 62, 64, que funciona en la base de una 5-tupla de IP que es complementaria a una 5-tupla de IP de los paquetes de datos entrantes recibidos. En este caso, se debe entender que pueden estar presentes diferentes flujos de paquetes IP en una única portadora 52, 54, y que múltiples filtros de paquetes de UL 62, 64 pueden encaminar paquetes de datos salientes sobre la misma portadora 52, 54. Si hay un nuevo flujo de paquetes IP con paquetes de datos entrantes sobre una portadora 52, 54 o se establece una nueva portadora, se generará un correspondiente filtro de paquetes de datos de UL nuevo 62, 64.
Cuando se aplican los conceptos mencionados anteriormente, el equipo de usuario 10 puede recibir una funcionalidad para indicar a la red de comunicación móvil que soporta la función de réplica 220. Por ejemplo, esto se podría incluir en señalización de gestión de sesiones, por ejemplo durante un procedimiento de acoplamiento entre el equipo de usuario 10 y la red central. A modo de ejemplo, se podría añadir un elemento de información al proceso de señalización, en el que el equipo de usuario 10 puede indicar que soporta a la función de réplica 220. La figura 6 muestra esquemáticamente un correspondiente trayecto de señal 2 que se extiende desde el equipo de usuario 10. En este caso, se debe entender que el trayecto de señalización 2 se representa esquemáticamente extendiéndose desde el equipo de usuario 10 directamente a un nodo de red específico, por ejemplo al controlador de políticas 30 mostrado, pero habitualmente puede estar implementado a través de otros nodos de red. Por ejemplo, en una red de comunicación UMTS, el trayecto de señalización 2 se podría extender desde el equipo de usuario 10 hasta un nodo de soporte GPRS de servicio (SGSN, Serving GPRS Support Node). En una red de comunicación de evolución a largo plazo/evolución de arquitectura de servicio (SAE/LTE, Long Term Evolution/Service Architecture Evolution), el trayecto de señalización 2 se podría extender desde el equipo de usuario 10 hasta una entidad de gestión móvil (MME, Mobile Management Entity). Desde estos nodos de red, la información de señalización puede a continuación ser transmitida o distribuida otros nodos de red, por ejemplo al controlador de políticas 30.
En algunas realizaciones, la información de que el equipo de usuario 10 soporta la función de réplica 220 puede ser distribuida asimismo entre nodos de la red central, por ejemplo al controlador de políticas 30 o a un nodo que soporta una función de inspección de paquetes, por ejemplo el inspector de paquetes 100 que se muestra en la figura 1. Para este propósito, se puede reutilizar la interfaz Gx o la interfaz Rx según las especificaciones 3GPP.
De acuerdo con algunas realizaciones, se puede disponer otro trayecto de señalización 4 desde la red de comunicación móvil hasta el equipo de usuario 10. Utilizando este trayecto de señalización 4, puede ser posible activar o desactivar la función de réplica 220 para cada portadora. Esto puede ser útil si no todas las aplicaciones o servicios requieren la activación de esta función. Por ejemplo, en algunos casos la 5-tupla de IP en los paquetes de datos de un servicio se puede definir estadísticamente y se puede utilizar un correspondiente filtro de paquetes de UL estático 62, 64 en el equipo de usuario 10. De nuevo, se debe entender que el trayecto de señalización 4 se representa esquemáticamente extendiéndose hasta el equipo de usuario 10 directamente desde un nodo de red específico, por ejemplo desde el controlador de políticas 30 mostrado, pero habitualmente puede estar implementado a través de otros nodos de red. Por ejemplo, en una red de comunicación UMTS, el trayecto de señalización 2 se podría extender desde un nodo de soporte GPRS de servicio (SGSN, Serving GPRS Support Node) hasta el equipo de usuario 10. En una red de comunicación de evolución a largo plazo/evolución de arquitectura de servicio (SAE/LTE), el trayecto de señalización 2 se podría extender desde una entidad de gestión móvil (MME) hasta el equipo de usuario 10. A su vez, estos nodos de red pueden recibir la información de señalización desde otros nodos de la red, por ejemplo el controlador de políticas 30.
En algunas realizaciones, la red de comunicación móvil puede señalizar al equipo de usuario 10 si debería o no aplicarse la función de réplica 220, por ejemplo utilizando procedimientos estándar de establecimiento o modificación de portadoras, tal como se define en las especificaciones 3GPP. Se podría añadir un correspondiente elemento de información para este propósito, a los procedimientos estandarizados de establecimiento o modificación de portadoras. En estos casos, la señalización desde el equipo de usuario 10 a la red de comunicación móvil indicando que está soportada la función de réplica 220 se podría implementar asimismo en función de cada portadora. Es decir, la correspondiente señalización podría especificar el soporte de la función de réplica 220 para una nueva portadora o podría modificar la información de soporte para una portadora ya establecida.
La figura 8 muestra un diagrama de flujo que ilustra un procedimiento 300 para gestionar tráfico de datos de UL, de acuerdo con los conceptos mencionados en lo anterior.
En la etapa 310, se reciben desde una portadora paquetes de datos entrantes con un primer identificador. Tal como se ha explicado anteriormente, la portadora puede estar asociada con una clase de QoS correspondiente, y el primer identificador puede ser una 5-tupla de IP.
5
10
15
20
25
30
En la etapa 320, se detectan paquetes de datos salientes con un segundo identificador, complementario. Esto se puede conseguir generando o configurando un filtro de paquetes de UL "replicado" que funciona sobre la base de una 5-tupla de IP que es complementaria a la 5-tupla de IP de los paquetes de datos entrantes recibidos de la portadora.
En la etapa 330, se encaminan paquetes de datos salientes con el segundo identificador a la misma portadora desde la que se reciben los paquetes de datos entrantes con el primer identificador. De nuevo, esto se puede conseguir seleccionando o configurando un correspondiente filtro de paquetes de UL "replicado", por ejemplo actuando sobre la base del identificador complementario o una parte del mismo.
De acuerdo con los conceptos que se han explicado anteriormente, es posible mapear dinámicamente tráfico de datos relacionado con el servicio a una clase de QoS deseada, por ejemplo en base a datos de políticas específicos del usuario y/o en base a datos de políticas específicos del servicio. Además, este mapeo podría depender de la hora del día, del día de la semana o de otros parámetros. Se pueden definir por lo tanto diversas políticas diferentes en los datos de políticas para controlar el mapeo del tráfico de datos relacionado con el servicio a una clase de QoS. Una de dichas políticas puede ser incluso bloquear el tráfico de datos relativo a un servicio específico en la pasarela.
Además, el control de la QoS en base a los datos de políticas se puede conseguir de manera eficiente, sin requerir demasiada señalización sobre interfaces de la red central o al equipo de usuario. Cuando se combinan los conceptos de gestión de tráfico de datos de DL que se han explicado en relación con las figuras 1 a 5, con los conceptos de gestión de tráfico de datos de UL que se han explicado en relación con las figuras 6 a 8, se obtiene una solución eficiente que permite la gestión tanto de tráfico de datos de DL como de tráfico de datos de UL.
Además, los conceptos que se han descrito anteriormente no dependen del establecimiento de portadoras que no son necesarias. Por el contrario, las portadoras se pueden establecer cuando se necesitan, utilizando por lo tanto de manera eficiente los recursos de red disponibles.
Se debe entender que los conceptos que se han explicado anteriormente son tan sólo a modo de ejemplo y susceptibles de diversas modificaciones. Por ejemplo, los nodos de red que se muestran en las figuras 1 y 6 no tienen que implementarse como nodos independientes, sino que se pueden integrar en un único componente de red. Por ejemplo, el inspector de paquetes 100 podría asimismo estar integrado en la pasarela 26. Los conceptos se pueden aplicar en varios tipos de redes de comunicación móvil. Finalmente, se debe observar que la solución para la gestión de tráfico de datos de UL explicada en relación con las figuras 6 a 8 no se limita a la gestión de tráfico de datos de UL procedente de un equipo de usuario. Por el contrario, estos conceptos se pueden aplicar en general a todas las situaciones en las que ya están mapeados paquetes de datos entrantes a una portadora específica y existen correspondientes paquetes de datos salientes.
Claims (11)
- 5101520253035REIVINDICACIONES1. Un procedimiento de gestión de tráfico de red, que comprende:- recibir datos de inspección de paquetes que indican el tráfico de datos relacionado con el servicio de un usuario específico y/o un servicio específico;- determinar un filtro de paquetes (72, 74) en base a dichos datos de inspección de paquetes, en el que dicho filtro de paquetes (72, 74) está configurado para filtrar el tráfico de datos en base a un identificador incluido en los paquetes de datos de dicho tráfico de datos relacionados con el servicio en respuesta a la inspección de paquetes; y- configurar el filtro de paquetes (72, 74) en una pasarela (26).
- 2. El procedimiento según la reivindicación precedente, en el que los datos de inspección de paquetes incluyen un identificador de servicio que indica el servicio al que pertenecen los paquetes de datos de dicho tráfico relacionado con el servicio.
- 3. El procedimiento según cualquier reivindicación precedente, en el que los datos de inspección de paquetes indican el identificador que se incluye en los paquetes de datos de dicho tráfico de datos relacionado con el servicio.
- 4. El procedimiento según cualquier reivindicación precedente, en el que dicho identificador es un campo de Punto de Código de Servicios Diferenciados en una sección de cabecera de los paquetes de datos.
- 5. El procedimiento según cualquier reivindicación precedente,en el que el identificador se asocia con una portadora (52, 54) que tiene una clase específica de Calidad de Servicio, yen donde dicho filtro de paquetes (72, 74) está configurado para encaminar paquetes de datos con el identificador a la portadora (52, 54) asociada.
- 6. El procedimiento según cualquier reivindicación precedente, que comprende:- enviar datos de control de inspección de paquetes mapeando dicho servicio específico a dicho identificador
- 7. El procedimiento según la reivindicación 6, en el que dicho mapeo se define en una tabla de mapeo.
- 8. El procedimiento según la reivindicación 6 o 7, en el que el mapeo varía en función de la hora del día o del día de la semana.
- 9. El procedimiento según cualquier reivindicación precedente, que comprende:- enviar dicho filtro de paquetes (72, 74) determinado a una pasarela (26).
- 10. Un componente de red, que comprende:- una interfaz (5) de datos de inspección de paquetes configurada para recibir datos de inspección de paquetes que indican el tráfico de datos relacionado con el servicio de un usuario específico y/o un servicio específico;- un generador de filtros (35) configurado para determinar un filtro de paquetes en base a dichos datos de inspección de paquetes, en donde dicho filtro de paquetes está configurado para filtrar el tráfico de datos en base a un identificador incluido en los paquetes de datos de dicho tráfico de datos relacionado con el servicio en respuesta a la inspección de paquetes; y- una interfaz para la configuración del filtro de paquetes (72, 74) en una pasarela (26).
- 11. El componente de red según la reivindicación 10,en el que el componente de red está configurado para implementar el procedimiento según una cualquiera de las reivindicaciones 1 a 9.
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP14170345.4A EP2773147B1 (en) | 2009-04-02 | 2009-04-02 | Techniques for handling network traffic |
PCT/EP2009/053946 WO2010112077A1 (en) | 2009-04-02 | 2009-04-02 | Techniques for handling network traffic |
EP09779247.7A EP2415216B1 (en) | 2009-04-02 | 2009-04-02 | Techniques for handling network traffic |
EP15202169.7A EP3051872B1 (en) | 2009-04-02 | 2009-04-02 | Techniques for handling network traffic |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2673604T3 true ES2673604T3 (es) | 2018-06-25 |
Family
ID=41581016
Family Applications (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES12169143.0T Active ES2638637T3 (es) | 2009-04-02 | 2009-04-02 | Técnicas de gestión del tráfico de red |
ES15202169.7T Active ES2673604T3 (es) | 2009-04-02 | 2009-04-02 | Técnicas para gestionar tráfico de red |
ES19176134T Active ES2810873T3 (es) | 2009-04-02 | 2009-04-02 | Técnicas de gestión del tráfico de red |
ES17174284T Active ES2758190T3 (es) | 2009-04-02 | 2009-04-02 | Técnicas de gestión del tráfico de red |
ES14170345.4T Active ES2567558T3 (es) | 2009-04-02 | 2009-04-02 | Técnicas para gestionar tráfico de red |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES12169143.0T Active ES2638637T3 (es) | 2009-04-02 | 2009-04-02 | Técnicas de gestión del tráfico de red |
Family Applications After (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES19176134T Active ES2810873T3 (es) | 2009-04-02 | 2009-04-02 | Técnicas de gestión del tráfico de red |
ES17174284T Active ES2758190T3 (es) | 2009-04-02 | 2009-04-02 | Técnicas de gestión del tráfico de red |
ES14170345.4T Active ES2567558T3 (es) | 2009-04-02 | 2009-04-02 | Técnicas para gestionar tráfico de red |
Country Status (8)
Country | Link |
---|---|
US (4) | US9979661B2 (es) |
EP (6) | EP2493134B1 (es) |
JP (1) | JP5639638B2 (es) |
CN (1) | CN102804705B (es) |
DK (4) | DK2493134T3 (es) |
ES (5) | ES2638637T3 (es) |
PL (3) | PL3562205T3 (es) |
WO (1) | WO2010112077A1 (es) |
Families Citing this family (38)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5639638B2 (ja) * | 2009-04-02 | 2014-12-10 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | ネットワークトラヒックを処理するための技術 |
US20100260098A1 (en) | 2009-04-10 | 2010-10-14 | Qualcomm Incorporated | Header compression for ip relay nodes |
US20120281536A1 (en) * | 2009-06-12 | 2012-11-08 | Cygnus Broadband, Inc. | Systems and methods for detection for prioritizing and scheduling packets in a communication network |
US8665724B2 (en) | 2009-06-12 | 2014-03-04 | Cygnus Broadband, Inc. | Systems and methods for prioritizing and scheduling packets in a communication network |
US8400916B2 (en) * | 2010-06-28 | 2013-03-19 | Alcatel Lucent | Method of authorizing AF sessions using external subscriber database |
CN103004155B (zh) | 2010-07-29 | 2015-11-25 | 瑞典爱立信有限公司 | 处理经固定接入的网络业务 |
CN102348244B (zh) * | 2010-08-03 | 2014-11-05 | 华为技术有限公司 | 蜂窝通信系统、终端在小区间切换的方法及宏基站 |
US8982888B2 (en) | 2010-10-18 | 2015-03-17 | Motorola Solutions, Inc. | Service data flow detection in a conforming 3GPP access network having a packet modification function |
US9313797B2 (en) | 2010-10-22 | 2016-04-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Mobile-access information based adaptation of network address lookup for differentiated handling of data traffic |
WO2012052568A1 (en) * | 2010-10-22 | 2012-04-26 | Telefonaktiebolaget L M Ericsson (Publ) | Accelerated content delivery |
CN103918241B (zh) * | 2011-03-04 | 2017-05-24 | 交互数字专利控股公司 | 用于分组过滤的方法和wtru |
US8612541B2 (en) * | 2011-04-29 | 2013-12-17 | Blue Coat Systems, Inc. | Method and apparatus for multi-tenant policy management in a network device |
EP2981034A1 (en) * | 2011-06-28 | 2016-02-03 | Interdigital Patent Holdings, Inc. | Managing data mobility policies |
JP5812373B2 (ja) * | 2011-07-01 | 2015-11-11 | ▲ホア▼▲ウェイ▼技術有限公司 | ベアラ処理のための方法及び装置 |
EP2730057B1 (en) * | 2011-07-08 | 2015-09-02 | Telefonaktiebolaget L M Ericsson (publ) | Bearer control on the basis of probing |
CN102883457B (zh) | 2011-07-15 | 2016-06-22 | 华为技术有限公司 | 保证上行服务质量的方法、基站及用户设备 |
WO2013016843A1 (en) * | 2011-08-02 | 2013-02-07 | Telefonaktiebolaget L M Ericsson (Publ) | Implementation of packet data service in a mobile communication network |
WO2013017176A1 (en) * | 2011-08-04 | 2013-02-07 | Telefonaktiebolaget L M Ericsson (Publ) | Providing content related quality of service in packet switched communication network |
US8861438B2 (en) * | 2011-11-15 | 2014-10-14 | Motorola Solutions, Inc. | Preserving user-differentiated quality of service for mobile virtual private network communications made using a shared connection point |
CA2768483C (en) * | 2011-12-30 | 2019-08-20 | Sandvine Incorporated Ulc | Systems and methods for managing quality of service |
CA2867577C (en) * | 2012-03-20 | 2019-07-02 | Raytheon Company | Routing a data packet in a communication network |
WO2013174422A1 (en) * | 2012-05-23 | 2013-11-28 | Nokia Siemens Networks Oy | Methods, computer program products and apparatuses enabling symmetric bearer enforcement |
WO2014197521A1 (en) | 2013-06-03 | 2014-12-11 | Seven Networks, Inc. | Blocking/unblocking algorithms for signaling optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols |
EP3050255A1 (en) * | 2013-09-27 | 2016-08-03 | Telefonaktiebolaget LM Ericsson (publ) | Methods, devices and computer programs for providing a service or service component requiring a specific packet-forwarding treatment |
CN104754657A (zh) * | 2013-12-30 | 2015-07-01 | 中兴通讯股份有限公司 | 策略控制方法、策略执行以及下发装置 |
US9521679B2 (en) * | 2014-03-06 | 2016-12-13 | Cisco Technology, Inc. | Systems and methods for implementing reflective EPS bearers to ensure uplink quality of service |
US9537789B2 (en) | 2014-10-31 | 2017-01-03 | Raytheon Company | Resource allocating in a network |
CN106162754B (zh) * | 2015-04-07 | 2020-03-24 | 中国移动通信集团公司 | 一种业务流的识别方法、装置及系统 |
US10405330B2 (en) * | 2015-06-09 | 2019-09-03 | Intel Corporation | System and method for dynamic marking for internet protocol bearer splitting |
CN107005537B (zh) * | 2015-10-28 | 2020-10-16 | 华为技术有限公司 | 一种承载处理方法、系统及相关装置 |
US10897425B2 (en) | 2016-01-19 | 2021-01-19 | Deutsche Telekom Ag | Method for handling communication between a telecommunications network and a user equipment |
CN107396401A (zh) * | 2016-05-17 | 2017-11-24 | 中兴通讯股份有限公司 | 数据发送方法及装置 |
US10470076B2 (en) | 2016-08-24 | 2019-11-05 | Telefonaktiebolaget Lm Ericsson (Publ) | Wireless device and methods therein for mapping data packets to radio bearers in a wireless communications network |
PT3520549T (pt) | 2016-09-29 | 2021-02-02 | Nokia Technologies Oy | Comutação de portadora de rádio em acesso de rádio |
US10764211B2 (en) * | 2018-10-19 | 2020-09-01 | Avago Technologies International Sales Pte. Limited | Flexible switch logic |
JP7207707B2 (ja) * | 2018-11-19 | 2023-01-18 | 国立研究開発法人情報通信研究機構 | 無線通信システム |
CN112272123B (zh) * | 2020-10-16 | 2022-04-15 | 北京锐安科技有限公司 | 网络流量分析方法、系统、装置、电子设备和存储介质 |
GB202205881D0 (en) | 2022-04-22 | 2022-06-08 | Net Ai Tech Ltd | Methods |
Family Cites Families (68)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6591299B2 (en) | 1997-11-25 | 2003-07-08 | Packeteer, Inc. | Method for automatically classifying traffic with enhanced hierarchy in a packet communications network |
US6862622B2 (en) | 1998-07-10 | 2005-03-01 | Van Drebbel Mariner Llc | Transmission control protocol/internet protocol (TCP/IP) packet-centric wireless point to multi-point (PTMP) transmission system architecture |
US6286052B1 (en) | 1998-12-04 | 2001-09-04 | Cisco Technology, Inc. | Method and apparatus for identifying network data traffic flows and for applying quality of service treatments to the flows |
US20110286331A1 (en) * | 1999-08-24 | 2011-11-24 | Gogo Llc | Differentiated Services Code Point Mirroring For Wireless Communications |
JP2002033764A (ja) | 2000-07-14 | 2002-01-31 | Fujitsu Ltd | 通信サービス提供システム、並びに通信サービス提供システムにおいて使用される移動端末装置、アドレスサーバ装置、およびルータ装置 |
US7050396B1 (en) | 2000-11-30 | 2006-05-23 | Cisco Technology, Inc. | Method and apparatus for automatically establishing bi-directional differentiated services treatment of flows in a network |
JP2002215481A (ja) | 2001-01-18 | 2002-08-02 | Nippon Telegr & Teleph Corp <Ntt> | Webアクセス制御方法およびシステム |
US20020133617A1 (en) | 2001-03-16 | 2002-09-19 | Davies Elwyn B. | Allocating traffic between a plurality of paths in a communications network |
US7272651B1 (en) * | 2001-08-28 | 2007-09-18 | Cisco Technology, Inc. | RSVP transmitter proxy |
JP2003209573A (ja) | 2002-01-10 | 2003-07-25 | Fujitsu Ltd | 通信装置及び中継装置 |
US7283468B1 (en) | 2002-03-15 | 2007-10-16 | Packeteer, Inc. | Method and system for controlling network traffic within the same connection with different packet tags by varying the policies applied to a connection |
US7177275B2 (en) | 2002-07-26 | 2007-02-13 | Kenneth Stanwood | Scheduling method and system for communication systems that offer multiple classes of service |
US7701963B2 (en) | 2002-10-15 | 2010-04-20 | Qualcomm Incorporated | Method and apparatus for the use of micro-tunnels in a communications system |
US7383048B2 (en) * | 2002-12-04 | 2008-06-03 | Nokia Corporation | Transmission of data packets by a node |
JP4520705B2 (ja) | 2003-04-11 | 2010-08-11 | パナソニック株式会社 | 通信システム及び通信方法 |
US7684432B2 (en) | 2003-05-15 | 2010-03-23 | At&T Intellectual Property I, L.P. | Methods of providing data services over data networks and related data networks, data service providers, routing gateways and computer program products |
US8521889B2 (en) | 2003-05-15 | 2013-08-27 | At&T Intellectual Property I, L.P. | Methods, systems, and computer program products for modifying bandwidth and/or quality of service for a user session in a network |
WO2004107134A2 (en) | 2003-05-28 | 2004-12-09 | Caymas Systems, Inc. | Method and system for identifying bidirectional packet flow |
JP3880554B2 (ja) * | 2003-07-18 | 2007-02-14 | 松下電器産業株式会社 | 空間分割多重アクセス方式ワイヤレス媒体アクセスコントローラ |
JP4575439B2 (ja) | 2004-04-28 | 2010-11-04 | テクノバス, インコーポレイテッド | イーサネット(登録商標)受動光ネットワークにおけるl3−アウェアスイッチングの方法と装置 |
US7979072B2 (en) | 2004-06-04 | 2011-07-12 | Nortel Networks Limited | Method and system for soft handoff in mobile broadband systems |
US7889646B2 (en) | 2004-08-06 | 2011-02-15 | At&T Intellectual Property I, L.P. | Methods, systems, and computer program products for managing admission control in a regional/access network based on user preferences |
US7339913B2 (en) | 2004-08-17 | 2008-03-04 | Intel Corporation | Method and system of network management and service provisioning for broadband wireless networks |
US7447220B2 (en) | 2004-10-07 | 2008-11-04 | Santera Systems, Llc | Methods and systems for packet classification with improved memory utilization in a media gateway |
JP4151643B2 (ja) * | 2004-11-16 | 2008-09-17 | セイコーエプソン株式会社 | 色変換行列作成装置、色変換行列作成プログラム及び画像表示装置 |
US8069265B2 (en) | 2005-01-10 | 2011-11-29 | Broadcom Corporation | Method and system for network rotameter station and service |
GB2425912A (en) * | 2005-05-04 | 2006-11-08 | Psytechnics Ltd | Packet filtering |
US20070081499A1 (en) * | 2005-10-12 | 2007-04-12 | Petter Johnsen | Packet data protocol context utilization |
KR100668661B1 (ko) | 2005-10-19 | 2007-01-16 | 한국전자통신연구원 | 휴대 인터넷 시스템에서 트랜스포트 연결 식별자의생성/변경 방법 및 그를 위한 단말기 |
US20070104132A1 (en) | 2005-11-07 | 2007-05-10 | Bala Rajagopalan | Techniques capable of providing efficient scheduling of packet data traffic in wireless data networks |
US7733780B2 (en) | 2005-12-07 | 2010-06-08 | Electronics And Telecommunications Research Institute | Method for managing service bandwidth by customer port and EPON system using the same |
CN101401382B (zh) * | 2006-01-10 | 2012-03-21 | 艾利森电话股份有限公司 | 用于在传输中过滤数据分组的方法和装置 |
PL1982475T3 (pl) * | 2006-02-05 | 2010-05-31 | Ericsson Telefon Ab L M | Sposób i urządzenia do instalowania filtrów pakietów w transmisji danych |
CN101438256B (zh) | 2006-03-07 | 2011-12-21 | 索尼株式会社 | 信息处理设备、信息通信系统、信息处理方法 |
US8634399B2 (en) | 2006-04-12 | 2014-01-21 | Qualcomm Incorporated | Uplink and bi-directional traffic classification for wireless communication |
JP5181472B2 (ja) | 2006-04-21 | 2013-04-10 | 日本電気株式会社 | 通信制御方法 |
US7966648B2 (en) | 2006-05-01 | 2011-06-21 | Qualcomm Incorporated | Dynamic quality of service pre-authorization in a communications environment |
US8228798B2 (en) * | 2006-06-28 | 2012-07-24 | Cisco Technology, Inc. | QoS-aware service flow mapping in mobile wireless all IP networks |
US9143585B2 (en) | 2006-07-07 | 2015-09-22 | Wi-Lan Inc. | Method and system for generic multiprotocol convergence over wireless air interface |
US20080089324A1 (en) * | 2006-10-13 | 2008-04-17 | Cisco Technology, Inc | Indicating or remarking of a dscp for rtp of a flow (call) to and from a server |
US8660555B2 (en) | 2006-11-03 | 2014-02-25 | Core Wireless Licensing S.A.R.L. | Quality of service mechanism |
CN101637051B (zh) | 2007-01-11 | 2012-10-31 | 高通股份有限公司 | 在无线通信系统中使用dtx和drx |
WO2008102442A1 (ja) | 2007-02-21 | 2008-08-28 | Panasonic Corporation | 通信システムおよびアクセスゲートウェイ装置 |
GB0705787D0 (en) | 2007-03-26 | 2007-05-02 | Vodafone Plc | Telecommunications networks |
JP4867806B2 (ja) | 2007-06-15 | 2012-02-01 | 株式会社日立製作所 | 通信システム、サーバ、制御装置および通信装置 |
EP2048847A1 (en) * | 2007-10-08 | 2009-04-15 | Nokia Siemens Networks Oy | Methods, apparatuses, system, and related computer program product for policy control |
KR100953453B1 (ko) | 2007-11-27 | 2010-04-20 | 한국전자통신연구원 | 이동단말에서의 상향링크 ip 패킷 필터링 제어방법 |
US9059871B2 (en) * | 2007-12-27 | 2015-06-16 | Redknee Inc. | Policy-based communication system and method |
US8532036B2 (en) * | 2008-03-18 | 2013-09-10 | Clearwire Ip Holdings Llc | System and method for providing voice over internet protocol quality of service support in a wireless communication network |
CA2712480C (en) * | 2008-03-20 | 2015-06-16 | Redknee Inc. | Metering of telecommunication services |
US8264965B2 (en) * | 2008-03-21 | 2012-09-11 | Alcatel Lucent | In-band DPI application awareness propagation enhancements |
US8589541B2 (en) | 2009-01-28 | 2013-11-19 | Headwater Partners I Llc | Device-assisted services for protecting network capacity |
US7673355B2 (en) * | 2008-07-17 | 2010-03-09 | Fischer Matthew D | Rapid multi-action rescue sled |
US8005087B2 (en) | 2008-09-16 | 2011-08-23 | Alcatel Lucent | Application-level processing for default LTE bearer |
US20100115072A1 (en) * | 2008-10-03 | 2010-05-06 | Qualcomm, Incorporated | NON-NETWORK INITIATED QUALITY OF SERVICE (QoS) |
US8902805B2 (en) | 2008-10-24 | 2014-12-02 | Qualcomm Incorporated | Cell relay packet routing |
US8325638B2 (en) | 2008-12-09 | 2012-12-04 | Qualcomm Incorporated | Performing packet flow optimization with policy and charging control |
JP5298203B2 (ja) | 2008-12-10 | 2013-09-25 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | Nat経由のデータセッションのポリシー及び課金制御のための制御セッションのトークンベースの相関 |
JP5173786B2 (ja) | 2008-12-22 | 2013-04-03 | 株式会社日立製作所 | 無線基地局装置および無線通信システム |
EP2368343A4 (en) | 2008-12-23 | 2012-06-13 | Ericsson Telefon Ab L M | METHOD AND ARRANGEMENT FOR ENABLING USER TRAFFIC CLASSIFICATION CONFIGURATION |
JP5127729B2 (ja) | 2009-01-13 | 2013-01-23 | 三菱電機株式会社 | パケット中継方法及びゲートウェイ装置 |
US8745191B2 (en) * | 2009-01-28 | 2014-06-03 | Headwater Partners I Llc | System and method for providing user notifications |
JP5639638B2 (ja) * | 2009-04-02 | 2014-12-10 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | ネットワークトラヒックを処理するための技術 |
US8867486B2 (en) | 2009-04-17 | 2014-10-21 | Qualcomm Incorporated | Wireless data communications employing IP flow mobility |
EP2422577B1 (en) | 2009-04-23 | 2015-03-25 | Telefonaktiebolaget LM Ericsson (publ) | Local ip access through a femto base station |
WO2011008877A1 (en) * | 2009-07-14 | 2011-01-20 | Sta-Rite Industries, Llc | Livewell fill valve |
CN103004155B (zh) | 2010-07-29 | 2015-11-25 | 瑞典爱立信有限公司 | 处理经固定接入的网络业务 |
US9252972B1 (en) | 2012-12-20 | 2016-02-02 | Juniper Networks, Inc. | Policy control using software defined network (SDN) protocol |
-
2009
- 2009-04-02 JP JP2012502466A patent/JP5639638B2/ja active Active
- 2009-04-02 PL PL19176134T patent/PL3562205T3/pl unknown
- 2009-04-02 DK DK12169143.0T patent/DK2493134T3/da active
- 2009-04-02 EP EP12169143.0A patent/EP2493134B1/en active Active
- 2009-04-02 EP EP15202169.7A patent/EP3051872B1/en active Active
- 2009-04-02 DK DK19176134.5T patent/DK3562205T3/da active
- 2009-04-02 EP EP19176134.5A patent/EP3562205B1/en active Active
- 2009-04-02 ES ES12169143.0T patent/ES2638637T3/es active Active
- 2009-04-02 PL PL17174284T patent/PL3236690T3/pl unknown
- 2009-04-02 WO PCT/EP2009/053946 patent/WO2010112077A1/en active Application Filing
- 2009-04-02 DK DK17174284T patent/DK3236690T3/da active
- 2009-04-02 US US13/262,423 patent/US9979661B2/en active Active
- 2009-04-02 EP EP09779247.7A patent/EP2415216B1/en active Active
- 2009-04-02 PL PL12169143T patent/PL2493134T3/pl unknown
- 2009-04-02 EP EP17174284.4A patent/EP3236690B1/en active Active
- 2009-04-02 ES ES15202169.7T patent/ES2673604T3/es active Active
- 2009-04-02 EP EP14170345.4A patent/EP2773147B1/en active Active
- 2009-04-02 ES ES19176134T patent/ES2810873T3/es active Active
- 2009-04-02 ES ES17174284T patent/ES2758190T3/es active Active
- 2009-04-02 ES ES14170345.4T patent/ES2567558T3/es active Active
- 2009-04-02 CN CN200980159661.6A patent/CN102804705B/zh active Active
- 2009-04-02 DK DK15202169.7T patent/DK3051872T3/en active
-
2014
- 2014-12-15 US US14/570,007 patent/US10511536B2/en active Active
-
2018
- 2018-06-28 US US16/021,515 patent/US10582411B2/en active Active
-
2019
- 2019-12-17 US US16/717,179 patent/US11317314B2/en active Active
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2673604T3 (es) | Técnicas para gestionar tráfico de red | |
ES2941246T3 (es) | QoS de extremo a extremo cuando se integran redes de acceso distintas de 3GPP de confianza y redes principales de 3GPP | |
JP5514305B2 (ja) | 通信ネットワークにおける性能測定 | |
BR112019015657B1 (pt) | Método para executar qualidade de serviço (qos) reflexiva em sistema de comunicação sem fio e um dispositivo para o mesmo | |
ES2526199T3 (es) | Correlación que implica cambio inter sistema entre diferentes tipos de portadores radio | |
CN110099370B (zh) | 服务层南向接口和服务质量 | |
ES2742425T3 (es) | Manejo del tráfico de red a través de un acceso fijo | |
US9877258B2 (en) | Method and device for transferring data traffic | |
JP6115961B2 (ja) | ネットワークトラヒックを処理するための技術 | |
JP2019505123A (ja) | 電気通信ネットワークとユーザ機器との間の通信を処理するための方法 | |
ES2956946T3 (es) | Procedimiento de referenciación de recursos locales en la política de selección de rutas del UE en redes móviles | |
CN105357774B (zh) | 针对改进服务质量处理的电信方法、协议和设备 |