ES2384649T3 - Método y sistema para configurar dinámicamente una plantilla de flujo de tráfico - Google Patents

Método y sistema para configurar dinámicamente una plantilla de flujo de tráfico Download PDF

Info

Publication number
ES2384649T3
ES2384649T3 ES07734480T ES07734480T ES2384649T3 ES 2384649 T3 ES2384649 T3 ES 2384649T3 ES 07734480 T ES07734480 T ES 07734480T ES 07734480 T ES07734480 T ES 07734480T ES 2384649 T3 ES2384649 T3 ES 2384649T3
Authority
ES
Spain
Prior art keywords
downlink
packet
tft
network node
packets
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
Application number
ES07734480T
Other languages
English (en)
Inventor
Reiner Ludwig
Niklas Sven Lundin
Petter Johnsen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2384649T3 publication Critical patent/ES2384649T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/22—Manipulation of transport tunnels
    • 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]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un método ubicado en un nodo de red para adaptar dinámicamente una Plantilla de Flujo de Tráfico (TFT) para controlar el encaminamiento de paquetes de datos de flujo descendente desde el nodo de red a un nodo de usuario, de tal manera que el método comprende las etapas de: recibir un paquete de datos de enlace ascendente enviado por un canal portador preferente desde el nodo de usuario, de tal manera que el portador preferente es un portador especial adaptado para transportar paquetes de datos de tráfico de datos preferente; extraer parámetros del paquete de datos de enlace ascendente, de tal manera que los parámetros comprenden al menos la dirección de destino del paquete de datos de enlace ascendente; y definir un subconjunto de filtros de paquetes de enlace descendente, destinados a filtrar paquetes de datos de enlace descendente en función de los parámetros extraídos, de tal modo que el subconjunto de filtros de 10 paquetes de enlace descendente identifica paquetes de datos de enlace descendente que tienen una dirección de fuente que coincide con la dirección de destino del paquete de datos de enlace ascendente; y modificar la TFT en función del subconjunto de filtros de paquetes de enlace descendente, a fin de encaminar los paquetes de enlace descendente identificados, a través del canal portador preferente, hasta el nodo de usuario, así como para encaminar diferentemente los paquetes de datos de enlace descendente que tienen direcciones de fuente que no coinciden con la dirección de destino del paquete de datos de enlace ascendente.

Description

Método y sistema para configurar dinámicamente una plantilla de flujo de tráfico.
SOLICITUDES RELACIONADAS
Esta Solicitud reivindica el derecho de la fecha de presentación de la Solicitud de Patente Provisional norteamericana Número 60/746-529, depositada el 5 de mayo de 2006 con el Número de Publicación WO 2007/129199.
CAMPO TÉCNICO
La presente invención se refiere a la comunicación de datos en redes inalámbricas y en un equipo de usuario. Más particularmente, y no a modo de limitación, la presente invención está encaminada a un sistema y a un método para configurar dinámicamente una Plantilla de Flujo de Tráfico (TFT –“Traffic Flow Template”) en una red de comunicación inalámbrica de conformidad con el Proyecto de Sociedad de Tercera Generación (3GPP –“Third Generation Partnership Project”).
ANTECEDENTES
Los operadores ofrecen habitualmente un servicio de “Acceso a Internet” a través de un denominado portador por defecto. El portador por defecto hace posible la transmisión de paquetes entre un Equipo de Usuario (UE –“User Equipment”) y una pasarela. Puede ser posible la diferenciación por parte del usuario de un portador por defecto; es decir, el nivel de servicio de un portador por defecto de un usuario concreto puede ser de calidad “buena”, “plata” o “bronce”, basándose en unos datos de abonado del usuario con el servicio.
En las redes 2G, la conexión a una red de IP (Protocolo de Internet –“Internet Protocol”) se ofrece a través del uso de portadores tales como un contexto de PDF o un portador de Evolución de Arquitectura de Servicio (SAE – “Service Architecture Evolution”). Un portador es una conexión de punto a punto desde el terminal de usuario hasta la red de IP, proporcionada ya sea por el operador, ya sea por un Proveedor de Servicios de Internet (ISP –“Internet Service Provider”). Para cada portador, es posible especificar un perfil de Calidad de Servicio (QoS –“Quality of Service”). El perfil de QoS contiene parámetros tales como la capacidad de transferencia de pico, la capacidad de
transferencia principal, el retardo y la fiabilidad.
Es también posible activar más de un portador para un usuario dado. Un portador puede ser, bien un portador primario o bien un portador secundario. Un portador primario, o por defecto, tiene una dirección de IP única o exclusiva asignada, en tanto que un portador secundario, o dedicado, tiene la misma dirección de IP que el portador primario si el portador secundario está activado. El portador secundario tiene, normalmente, un perfil de QoS diferente al del portador primario. El portador primario se activa, por lo común, para diferentes Nombres de Punto de Acceso (APNs –“Access Point Names”), mientras que el portador secundario se conecta al mismo APN que el primario.
Un escenario típico en el que se activan un portador primario y un portador secundario, es cuando hay tráfico tanto de UDP como de TCP. Un portador primario con baja fiabilidad puede ser activado para el tráfico de UDP, y puede activarse para el tráfico de TCP un portador secundario con una alta fiabilidad. Otro contexto o escenario es una sesión de transferencia de corrientes de datos multimedia, en la que existe un portador con una elevada capacidad de transferencia para la carga de información útil, y un segundo portador con diferentes características para la señalización.
Cuando se ha establecido para un usuario más de un portador de PDP [Protocolo de Dato en Paquetes –“Packet Data Protocol”], los distintos paquetes pueden ser manejados con diferente QoS y, deben, por lo tanto, colocarse en el portador correcto. El tráfico procedente de un Nodo de Soporte de GPRS [Servicio General de Radio en Paquetes
–“General Packet Radio Service”] de Pasarela (GGSN –“Gateway GPRS Support Node”) y dirigido al UE, se coloca
en el portador correcto mediante el uso de una filtración por paquetes especificada por una Plantilla de Flujo de Tráfico (TFT –“Traffic Flow Template”) (definida por el 3GPP en su Especificación Técnica 23.060). Cada portador puede tener una TFT especificada. Una TFT puede contener hasta ocho filtros de paquetes, y cada filtro de paquetes puede contener atributos tales como un número de protocolo, un acceso o puerta de fuente o de destino, o una dirección de IP de fuente (y más). Si un paquete entra en un portador de enlace descendente, el paquete ha de coincidir con al menos uno de los filtros de paquetes existentes en la TFT.
La Figura 1 es un diagrama de bloques de nivel alto de una configuración de red existente para dirigir tráfico de enlace descendente al contexto de PDP o portador correcto. Un Nodo de Soporte de GPRS de Pasarela (GGSN) 11 recibe paquetes a través de una conexión 12 de ISP. Cuando se ha establecido más de un portador, diferentes paquetes pueden ser manejados con diferentes QoS y el GGSN debe ponerlos en un portador de PDP correcto (por ejemplo, el Contexto1 13 o el Contexto2 14). Los paquetes de enlace descendente se colocan en el portador correcto mediante el uso de la filtración de paquetes especificada por las Plantillas de Flujo de Tráfico (TFTs) 15 y 16 (definidas por el 3GPP en su Especificación Técnica 23.060). Cada TFT está asociada con un portador particular.
Una TFT puede contener hasta 8 filtros de paquetes, y cada filtro de paquetes puede contener atributos tales como un número de protocolo, una puerta de fuente o de destino, o una dirección de IP de fuente (y más). La conexión 12 de ISP proporciona todo el flujo de enlace descendente a cada TFT, y cada TFT determina qué paquetes satisfacen los atributos de filtro para su portador asociado. Un paquete debe coincidir con al menos uno de los filtros de paquetes contenidos en la TFT a fin de entrar en el portador de enlace descendente asociado para su transmisión a la estación móvil (MS –“mobile station”) 17. En caso contrario, el paquete es desechado.
El establecimiento de un contexto de PDP secundario mientras al menos algunos de los filtros requeridos para la conexión no están disponibles, se describe en el documento WO 02/073989. En este documento se propone enviar un mensaje de TFT con un filtro de paquetes válido, aunque no efectivo (simulado), conjuntamente con la petición de activar el contexto de PDP, desde el nodo móvil al nodo de red. Tan pronto como la estación móvil recibe información acerca de un valor de filtro válido, se envía al GGSN una nueva TFT con el valor de filtro correcto.
Surge un problema cuando se intentan configurar las TFTs en el GGSN para el tráfico de paquetes de enlace descendente. Las TFTs se han de configurar manualmente antes de su activación por el contexto, y si las TFTs se establecen de manera que sean estáticas para el contexto, puede haber algunas aplicaciones que tengan un comportamiento que requiera que las TFTs sean más dinámicas. Si las TFTs se establecen de manera que sean demasiado generales (anchas), pueden dejarse entrar los paquetes que no pertenecen al portador, y si las TFTs se han establecido de manera que sean demasiado específicas (estrechas), los paquetes pertenecientes al portador pueden ser rechazados. Dependiendo del tipo de tráfico que fluye, los atributos de los paquetes pueden ser bastante dinámicos, lo que puede conducir a la necesidad de utilizar un filtro de paquetes definido en un sentido amplio.
Será ventajoso disponer de un sistema y de un método para configurar dinámicamente las TFTs, que supere las desventajas de la técnica anterior. La presente invención proporciona tales sistema y método.
SUMARIO
La presente invención proporciona un sistema y un método en los que la Plantilla de Flujo de Tráfico (TFT –“Traffic Flow Template”) se configura en tiempo real, a medida que fluye el tráfico. La invención elimina la difícil tarea de configurar manualmente la TFT previamente al flujo de tráfico, antes de que se determine con qué sistema anfitrión o principal se está comunicando y qué aplicación está en marcha.
En un aspecto, la presente invención está encaminada a un método radicado en un nodo de red y destinado a adaptar dinámicamente una TFT con el fin de controlar el encaminamiento de paquetes de datos de enlace descendente desde el nodo de red hasta un nodo de usuario. El método incluye las etapas de recibir un paquete de datos de enlace ascendente enviado por un canal portador preferente desde el nodo de usuario; extraer del paquete de datos de enlace ascendente parámetros que incluyen al menos la dirección de destino del paquete de datos de enlace ascendente; y definir un subconjunto de filtros de paquetes de enlace descendente para filtrar paquetes de datos de enlace descendente en función de los parámetros extraídos. El subconjunto de filtros de paquetes de enlace descendente identifica paquetes de datos de enlace descendente que tienen una dirección de fuente que coincide con la dirección de destino del paquete de datos de enlace ascendente. La TFT se modifica entonces en función del subconjunto de filtros de paquetes de enlace descendente con el fin de encaminar los paquetes de enlace descendente identificados, a través del canal portador preferente, hasta el nodo de usuario, así como para encaminar de forma diferenciada los paquetes de datos de enlace descendente que tienen direcciones de fuente que no coinciden con la dirección de destino del paquete de datos de enlace ascendente.
En otro aspecto, la presente invención está encaminada a un nodo de red que puede funcionar para adaptar dinámicamente una TFT para controlar el encaminamiento de paquetes de datos de enlace descendente desde el nodo de red hasta un nodo de usuario. El nodo de red incluye medios para recibir un paquete de datos de enlace ascendente enviado por un canal portador preferente desde el nodo de usuario; medios para extraer del paquete de datos de enlace ascendente parámetros que incluyen al menos la dirección de destino del paquete de datos de enlace ascendente; y medios para definir un subconjunto de filtros de paquetes de enlace descendente destinado a filtrar paquetes de datos de enlace descendente en función de los parámetros extraídos. El subconjunto de filtros de paquetes de enlace descendente identifica paquetes de datos de enlace descendente que tienen una dirección de fuente que coincide con la dirección de destino del paquete de datos de enlace ascendente. El nodo de red también incluye medios para modificar la TFT en función del subconjunto de filtros de paquetes de enlace descendente, a fin de encaminar los paquetes de enlace descendente identificados, a través del canal portador preferente, hasta el nodo de usuario, así como para encaminar de forma diferenciada los paquetes de datos de enlace descendente que tienen direcciones de fuente que no coinciden con la dirección de destino del paquete de datos de enlace ascendente.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
En la siguiente sección, se describirá la invención con referencia a realizaciones proporcionadas a modo de ejemplo y que se ilustran en las Figuras, en las cuales:
La Figura 1 es un diagrama de bloques de alto nivel de una configuración de red existente para dirigir el tráfico de enlace descendente al contexto de PDP [Protocolo de Datos en Paquetes –“Packet Data Protocol”]
o portador correcto;
La Figura 2 es un diagrama de bloques de alto nivel que representa un controlador de TFT [Plantilla de Flujo de Tráfico –“Traffic Flow Template”] de acuerdo con una primera realización de la presente invención;
La Figura 3 es un diagrama de bloques de alto nivel que representa un controlador de TFT de acuerdo con una segunda realización de la presente invención; y
La Figura 4 es un diagrama de flujo de una realización del método de la presente invención.
DESCRIPCIÓN DETALLADA
La Figura 2 es un diagrama de bloques de alto nivel que representa un controlador de TFT de acuerdo con una primera realización de la presente invención. En esta realización, una MS [estación móvil –“mobile station”] modificada 21 incluye unos controladores 22 y 23 de TFT, los cuales actúan como Filtros de Paquetes de Enlace Ascendente (ULPFs –“UpLink Packet Filtres”) para los paquetes que entran en el Contexto1 13 y en el Contexto2 14, respectivamente.
Ha de apreciarse que existen diversas formas como puede establecerse un denominado portador preferente. El portador preferente es un portador de propósito especial (o canal lógico, túnel, contexto, etc.) para transportar paquetes pertenecientes, por ejemplo, a una aplicación preferente. Como servicio de suscripción o abono, el portador preferente puede ser preestablecido por el GGSN [Nodo de Soporte de GPRS de Pasarela –“Gateway GPRS Support Node”] cuando la MS se engancha a la red con el encendido. Esta alternativa es la más adecuada
para sistemas de canales compartidos como el HSPA y el LTE. Otra alternativa consiste en establecer el portador preferente como servicio bajo demanda. El usuario (una persona) solicita explícitamente el servicio, por ejemplo, al hacer clic en un enlace existente en el portal del operador, o mediante una llamada al operador por vía telefónica
(“servicio preferente durante 2 horas por X dólares”), lo que desencadena o dispara entonces el GGSN para iniciar
un portador secundario o dedicado correspondiente.
Los controladores 22 y 23 de TFT realizan una filtración sobre parámetros de información predefinidos de los paquetes de tráfico de enlace ascendente y colocan los paquetes que satisfacen los criterios de la aplicación
preferente en el portador preferente. Todas las demás aplicaciones de cliente / homólogo de “Acceso a Internet” se
asocian con el nivel de servicio por defecto. La red puede también dar instrucciones, a través de SIP / SDP, a
aplicaciones de cliente / homólogo de “Acceso por Internet” escogidas para establecer DSCP = “secundario” en
paquetes de enlace ascendente.
Los controladores de TFT también dan cuenta de parámetros de información predefinidos de los paquetes de tráfico de enlace ascendente por medio de señales de control 24 y 25 de TFT a la TFT1 15 y a la TFT2 16 existentes en el GGSN 11. Este mecanismo proporciona la información de configuración requerida por los filtros de paquetes de enlace descendente existentes en la TFT1 y en la TFT2 para colocar los paquetes de enlace descendente preferentes en el portador preferente, al tiempo que se colocan todos los demás paquetes en el portador por defecto. La mayor parte del tráfico de IP es bidireccional, o en ambos sentidos (por ejemplo, datos + confirmaciones de TCP), y el tráfico preferente en ambos sentidos debe ir por el portador preferente. Ha de apreciarse que una descarga de TCP puede verse ralentizada tanto por la congestión en el recorrido o camino de los datos como por la congestión en el camino de las confirmaciones. La presente invención contribuye a eliminar esta congestión al configurar dinámicamente las TFTs con la información de filtración apropiada, de tal manera que los paquetes pueden ser adecuadamente dirigidos incluso en condiciones cambiantes.
En una realización, la dirección de destino de los paquetes de enlace descendente se hace coincidir con la dirección de fuente de los paquetes de enlace ascendente. La dirección de destino de los paquetes de enlace ascendente puede adoptar diversas formas, por ejemplo, simplemente la dirección de IP de destino, o bien la dirección de IP de destino + el número de puerta de destino. En este caso, el GGSN 11 coloca los paquetes de enlace descendente en el mismo portador desde el que se recibió el paquete de enlace ascendente con la dirección coincidente.
Es posible también utilizar controladores de TFT más avanzados. Por ejemplo, un controlador de TFT puede efectuar una filtración sobre cualquier combinación de cambios de encabezamiento de IP, o puede incluso filtrar más allá de los cambios de encabezamiento de IP, por ejemplo, basándose en URLs [Posiciones de Recursos Universales –“Universal Resource Locations”] contenidas en HTTP (es decir, ULPF basada en una inspección profunda de los paquetes).
La Figura 3 es una diagrama de bloques de alto nivel que representa un controlador de TFT de acuerdo con una segunda realización de la presente invención. En esta realización, un GGSN 31 se ha modificado de manera que incluye unos controladores 32 y 33 de TFT. Una vez más, esta realización está basada en el hecho de que la mayor parte del tráfico por Internet tiene un comportamiento simétrico. Es decir, el tráfico tiende a fluir en ambos sentidos entre dos sistemas anfitriones o principales. Por ejemplo, para el tráfico de TCP, habrá siempre CONFIRMACIONES (“ACKs”) fluyendo en el sentido opuesto al de la carga de información útil. Este hecho puede ser utilizado para extraer información del tráfico de enlace ascendente, que se utiliza para configurar las TFTs 15 y 16 existentes en el GGSN para que coincidan con el tráfico de enlace descendente esperado.
Para llevar esto a cabo, se supone que los paquetes que fluyen por el enlace ascendente se han hecho corresponder con el contexto correcto. La invención también es útil cuando un contexto con un ámbito amplio permite que los paquetes que son rechazados por una TFT estrecha fluyan por el enlace descendente, típica de un modo de optimización de esfuerzos.
Los controladores 32 y 33 de TFT incluyen un mecanismo para supervisar el tráfico de enlace ascendente según el contexto, y para extraer del paquete de enlace ascendente todos o parte de los siguientes parámetros de información:
Dirección de destino; Número de protocolo (IPv4);
Encabezamiento siguiente (IPv6);
Puerta de destino;
Puerta de fuente;
Índice de parámetro de seguridad de IP;
Tipo de servicio (IPv4);
Clase de tráfico (IPv6); y
Etiqueta de flujo (IPv6).
La información extraída debe ser ligeramente modificada antes de que pueda utilizarse para determinar las características de un paquete de enlace descendente esperado. La modificación puede ser como sigue:
La dirección de destino debe ser considerada como la dirección de fuente esperada;
La puerta de destino ha de ser considerada como puerta de fuente esperada; y
La puerta de fuente ha de ser considerada como puerta de destino esperada.
Son estos elementos de información que pueden utilizarse como componentes de filtro de paquetes a la hora de configurar los filtros de paquetes en las TFTs 15 y 16.
La Figura 4 es un diagrama de flujo de una realización del método de la presente invención para modificar subconjuntos de filtros para un portador preferente por parte del controlador 32 y 33 de TFT. En la etapa 41, los controladores de TFT extraen los parámetros relevantes antes listados (dirección de fuente y de destino, puerta de fuente y de destino, etc.) de un paquete de enlace ascendente preferente, y modifican los parámetros para que sean utilizados con paquetes de enlace descendente según se ha mostrado en lo anterior. En la etapa 42, os parámetros modificados se copian en un nuevo subconjunto de filtros de paquetes. En la etapa 43, los filtros dinámicos para el portador preferente ubicado en la TFT apropiada (por ejemplo, la TFT1 15) del GGSN 31, se comparan con el nuevo subconjunto de filtros de paquetes con el fin de determinar si los parámetros modificados copiados en el subconjunto de filtros de paquetes desde el paquete de enlace ascendente, están cubiertos por un filtro dinámico existente. Si es así, el método se remite a la etapa 44, en la que la TFT1 devuelve una respuesta al controlador 32 de TFT indicando la existencia del filtro dinámico. Si no es así, el método se traslada a la etapa 45, en la que la TFT1 devuelve un índice al siguiente filtro disponible. En la etapa 46, se configura en la TFT1 un filtro de paquetes.
En la etapa 47, se efectuará una búsqueda de los filtros existentes para determinar si alguno de los filtros existentes puede ser concatenado con el subconjunto de filtros de paquetes que se acaba de construir. Los filtros han de coincidir con la id de protocolo y con tantas como sea posible de las otras etiquetas de filtro. Si ninguno de los filtros existentes puede ser concatenado con el subconjunto de filtros de paquetes que se acaba de construir, el método finaliza en la etapa 48. Sin embargo, si se encuentra un “filtro coincidente”, el método se remite a la etapa 49, en la que el filtro es concatenado con, y almacenado en, el subconjunto de filtros de paquetes. El filtro concatenado contiene los parámetros comunes y los símbolos comodín para los parámetros que difieren dentro de la combinación del filtro coincidente y el subconjunto de filtros de paquetes. En la etapa 50, el filtro de paquetes de la TFT identificado por el índice de filtro, se configura con la información apropiada procedente del subconjunto de filtros de paquetes, ahora modificado, lo que da como resultado una modificación del contexto hacia el GGSN.
En esta forma más simple, el controlador de TFT puede especificar un filtro con las puertas de fuente y de destino esperadas, y con la dirección de fuente y el número de protocolo esperados. Pero, puesto que el número de filtros
Dirección de fuente ID de protocolo Puerta de destino Puerta de fuente
de paquetes está limitado a 8, esta solución limita el número de conexiones también a 8, puesto que se ha establecido una relación de correspondencia entre un filtro de paquetes y una conexión. Cuando se configuran más filtros de paquetes, el controlador de TFT puede tratar de concatenar filtros de paquetes. Los filtros de paquetes con elementos de filtro solapados de acuerdo con la Tabla 1 que se proporciona en lo que sigue, presentan la posibilidad de ser concatenados. La Tabla 1 muestra la ID de protocolo como uno de los parámetros, pero para el tráfico de IPv6, este será el Encabezamiento siguiente.
Tabla 1
Filtro concatenado 1
Filtro concatenado 2 Filtro concatenado 3 Filtro concatenado 4
X
X
X
X
X
X
X
X
X
X
Por ejemplo, esto significará que, si dos filtros de paquetes son idénticos en cuanto a la dirección de fuente de los componentes de filtro, la id de protocolo y la puerta de fuente, pero no coinciden en la puerta de destino, pueden ser concatenados para formar un solo filtro de paquetes con un ámbito más amplio que consta de los componentes de filtro comunes.
Cada filtro de paquetes de la TFT tiene un campo de precedencia de evaluación, que indica la precedencia del filtro de paquetes en comparación con otros filtros de paquetes ubicados en la TFT. El controlador de TFT debe establecer este en un valor alto para los filtros estrechos y en un valor más bajo para los filtros más anchos, a fin de garantizar el correcto tratamiento de los paquetes de enlace descendente. Un filtro estrecho es un filtro con muchos componentes de filtro. Un filtro ancho es un filtro con pocos componentes y, en casos especiales, únicamente se establece la ID de protocolo.
En otra realización, a la hora de utilizar un controlador de TFT, se implementa en la TFT un filtro de paquetes configurado por el usuario, además de los filtros de paquetes creados por el controlador de TFT. El filtro de paquetes configurado por el usuario puede ser utilizado cuando el usuario tiene requisitos especiales para el manejo de los paquetes. Los filtros de paquetes definidos por el usuario pueden ser establecidos en el procedimiento de activación en el contexto de PDP, o bien en el procedimiento de modificación en el contexto de PDP, de acuerdo con la especificación 3GPP 23.060.
La presente invención proporciona la ventaja de que la TFT no necesita ser configurada antes de que fluya el tráfico. La invención también elimina la necesidad de la configuración manual, que es una tarea difícil debido a que el tráfico depende fuertemente de con qué sistema principal se esté comunicando y de qué aplicación esté en marcha.
En realizaciones alternativas, el controlador de TFT puede ser implementado en el GGSN, en la MS, en el dispositivo de accionamiento del equipo terminal (TE –“terminal equipment”) conectado, o en cualquier nodo de red a cuyo través pasen los paquetes de datos entre la MS y el GGSN. Por ejemplo, el controlador de TFT puede ser implementado en una estación de base o en el Nodo de Servicio de GPRS [Servicio General de Radio en Paquetes
–“General Packet Radio Service”] en Servicio (SGSN –“Serving GPRS Service Node”) que da servicio a la MS. El controlador de TFT puede también ser implementado en una Pasarela de Red de Datos en Paquetes (PDN –“Packet Data Network”) según 3GPP o en una Pasarela en Servicio según se define en la Especificación Técnica de 3GPP
23.401 v0.4.1, o en una Pasarela de Datos en Paquetes evolucionada (ePDG –“evolved Packet Data Gateway”) según se define en la Especificación Técnica de 3GPP 23.402 v0.4.0.
La invención no está limitada a los parámetros utilizados en el texto y en el ejemplo, sino que puede incluir otros parámetros obtenidos de los paquetes de filtros. Como se constatará por parte de los expertos de la técnica, los conceptos innovadores descritos en la presente Solicitud pueden ser modificados y variados en todo un extenso abanico de aplicaciones. De acuerdo con ello, el ámbito de la materia objeto patentada no debe estar limitado por ninguna de las enseñanzas específicas proporcionadas a modo de ejemplo y expuestas en lo anterior, sino que, en lugar de ello, se define por las siguientes reivindicaciones.

Claims (17)

  1. REIVINDICACIONES
    1.-Un método ubicado en un nodo de red para adaptar dinámicamente una Plantilla de Flujo de Tráfico (TFT) para controlar el encaminamiento de paquetes de datos de flujo descendente desde el nodo de red a un nodo de usuario, de tal manera que el método comprende las etapas de:
    recibir un paquete de datos de enlace ascendente enviado por un canal portador preferente desde el nodo de usuario, de tal manera que el portador preferente es un portador especial adaptado para transportar paquetes de datos de tráfico de datos preferente;
    extraer parámetros del paquete de datos de enlace ascendente, de tal manera que los parámetros comprenden al menos la dirección de destino del paquete de datos de enlace ascendente; y
    definir un subconjunto de filtros de paquetes de enlace descendente, destinados a filtrar paquetes de datos de enlace descendente en función de los parámetros extraídos, de tal modo que el subconjunto de filtros de paquetes de enlace descendente identifica paquetes de datos de enlace descendente que tienen una dirección de fuente que coincide con la dirección de destino del paquete de datos de enlace ascendente; y
    modificar la TFT en función del subconjunto de filtros de paquetes de enlace descendente, a fin de encaminar los paquetes de enlace descendente identificados, a través del canal portador preferente, hasta el nodo de usuario, así como para encaminar diferentemente los paquetes de datos de enlace descendente que tienen direcciones de fuente que no coinciden con la dirección de destino del paquete de datos de enlace ascendente.
  2. 2.-El método de acuerdo con la reivindicación 1, en el cual la etapa de modificar la TFT incluye las etapas de:
    comparar el subconjunto de filtros de paquetes de enlace descendente con filtros de paquetes de enlace descendente existentes en la TFT para el portador preferente, a fin de determinar si uno de los filtros de paquetes de enlace descendente existentes permite el encaminamiento de los paquetes de enlace descendente identificados a través del canal portador preferente; y
    si no es así, actualizar uno de los filtros de paquetes de enlace descendente existentes en función del subconjunto de filtros de paquetes de enlace descendente, con el fin de permitir el encaminamiento de los paquetes de enlace descendente identificados a través del canal portador preferente.
  3. 3.-El método de acuerdo con la reivindicación 1, en el cual la etapa de modificar la TFT incluye añadir el subconjunto de filtros de paquetes de enlace descendente a la TFT.
  4. 4.-El método de acuerdo con la reivindicación 1, en el cual las etapas de extraer y definir un subconjunto de filtros de paquetes se llevan a cabo por un Controlador de TFT ubicado en el nodo de red.
  5. 5.-El método de acuerdo con la reivindicación 4, de tal manera que el método se lleva a cabo en un Nodo de Soporte de Servicio General de Radio en Paquetes (GPRS) de Pasarela (GGSN).
  6. 6.-El método de acuerdo con la reivindicación 4, de tal manera que el método se lleva a cabo en una Pasarela de Red de Datos en Paquetes (PDN) según 3GPP.
  7. 7.-El método de acuerdo con la reivindicación 4, de tal manera que el método se lleva a cabo en una Pasarela en Servicio según 3GPP.
  8. 8.-El método de acuerdo con la reivindicación 4, de tal manera que el método se lleva a cabo en una Pasarela de Datos en Paquetes evolucionada (ePDG) según 3GPP.
  9. 9.-Un nodo de red que funciona para adaptar dinámicamente una Plantilla de Flujo de Tráfico (TFT) para el control del encaminamiento de paquetes de datos de enlace descendente desde el nodo de red a un nodo de usuario, de tal manera que el nodo de red comprende:
    medios para recibir un paquete de datos de enlace ascendente enviado por un canal portador preferente desde el nodo de usuario, de tal manera que el portador preferente es un portador especial adaptado para transportar paquetes de datos de tráfico de datos preferente;
    medios para extraer parámetros del paquete de datos de enlace ascendente, de tal manera que los parámetros comprenden al menos la dirección de destino del paquete de datos de enlace ascendente; y
    medios para definir un subconjunto de filtros de paquetes de enlace descendente, destinados a filtrar paquetes de datos de enlace descendente en función de los parámetros extraídos, de tal modo que el subconjunto de filtros de paquetes de enlace descendente identifica paquetes de datos de enlace descendente que tienen una dirección de fuente que coincide con la dirección de destino del paquete de datos de enlace ascendente; y
    medios para modificar la TFT en función del subconjunto de filtros de paquetes de enlace descendente, a fin de encaminar los paquetes de enlace descendente identificados, a través del canal portador preferente, hasta el nodo de usuario, así como para encaminar diferentemente los paquetes de datos de enlace descendente que tienen direcciones de fuente que no coinciden con la dirección de destino del paquete de datos de enlace ascendente.
  10. 10.- El nodo de red de acuerdo con la reivindicación 9, en el cual los medios para modificar la TFT incluyen:
    medios para comparar el subconjunto de filtros de paquetes de enlace descendente con filtros de paquetes de enlace descendente existentes en la TFT para el portador preferente, a fin de determinar si uno de los filtros de paquetes de enlace descendente existentes permite el encaminamiento de los paquetes de enlace descendente identificados a través del canal portador preferente; y
    medios que responden a una determinación de que ninguno de los filtros de paquetes de enlace descendente existentes permite el encaminamiento de los paquetes de enlace descendente identificados a través del canal portador preferente, para actualizar uno de los filtros de paquetes de enlace descendente existentes en función del subconjunto de filtros de paquetes de enlace descendente, con el fin de permitir el encaminamiento de los paquetes de enlace descendente identificados a través del canal portador preferente.
  11. 11.-El nodo de red de acuerdo con la reivindicación 9, de tal manera que el nodo de red comprende un Nodo de Soporte de Servicio General de Radio en Paquetes (GPRS) de Pasarela (GGSN).
  12. 12.-El nodo de red de acuerdo con la reivindicación 9, de tal manera que el nodo de red comprende un Nodo de Soporte de Servicio General de Radio en Paquetes (GPRS) en Servicio (SGSN), que da servicio al nodo de usuario.
  13. 13.-El nodo de red de acuerdo con la reivindicación 9, de tal manera que el nodo de red comprende una Pasarela de Red de Datos en Paquetes (PDN) según 3GPP.
  14. 14.-El nodo de red de acuerdo con la reivindicación 9, de tal manera que el nodo de red comprende una Pasarela en Servicio según 3GPP.
  15. 15.-El nodo de red de acuerdo con la reivindicación 9, de tal manera que el nodo de red comprende una Pasarela de Datos en Paquetes evolucionada (ePDG) según 3GPP.
  16. 16.- El nodo de red de acuerdo con la reivindicación 9, de tal manera que el nodo de red comprende una estación de base que da servicio al nodo de usuario.
  17. 17.-Un sistema para adaptar dinámicamente una Plantilla de Flujo de Tráfico (TFT) al control del encaminamiento de paquetes de datos de enlace descendente desde un nodo de red hasta un nodo de usuario, de tal manera que el sistema comprende:
    el nodo de red de acuerdo con una de las reivindicaciones 9 a 16, que se conecta al nodo de usuario y que está configurado para efectuar una filtración sobre parámetros de información predefinidos de paquetes de datos de enlace ascendente, y para colocar paquetes de datos que satisfacen criterios para una aplicación preferente, en un portador preferente.
ES07734480T 2006-05-05 2007-05-04 Método y sistema para configurar dinámicamente una plantilla de flujo de tráfico Active ES2384649T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US74652906P 2006-05-05 2006-05-05
US746529P 2006-05-05
PCT/IB2007/001164 WO2007129199A2 (en) 2006-05-05 2007-05-04 Method and system for dynamically configuring a traffic flow template

Publications (1)

Publication Number Publication Date
ES2384649T3 true ES2384649T3 (es) 2012-07-10

Family

ID=38668141

Family Applications (1)

Application Number Title Priority Date Filing Date
ES07734480T Active ES2384649T3 (es) 2006-05-05 2007-05-04 Método y sistema para configurar dinámicamente una plantilla de flujo de tráfico

Country Status (5)

Country Link
US (1) US8094644B2 (es)
EP (1) EP2025108B1 (es)
AT (1) ATE550906T1 (es)
ES (1) ES2384649T3 (es)
WO (1) WO2007129199A2 (es)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100953453B1 (ko) * 2007-11-27 2010-04-20 한국전자통신연구원 이동단말에서의 상향링크 ｉｐ 패킷 필터링 제어방법
US8599765B2 (en) * 2008-03-21 2013-12-03 Blackberry Limited Evolved packet system quality of service enforcement deactivation handling to prevent unexpected user equipment detach
US20100034083A1 (en) * 2008-08-08 2010-02-11 Qualcomm Incorporated Method and apparatus for packet differentiation in a wireless communication system
WO2010098146A1 (en) 2009-02-27 2010-09-02 Panasonic Corporation Method for a communication node with a plurality of communication interfaces to notify dynamic path setup and associated apparatus thereof
US8891432B2 (en) 2009-03-27 2014-11-18 Panasonic Intellectual Property Corporation Of America Routing method, routing system, mobile node, home agent, and home base station
US8194572B2 (en) * 2009-06-15 2012-06-05 Motorola Mobility, Inc. Method and apparatus for increasing performance of a wireless communication system
CN101932102B (zh) 2009-06-19 2013-01-23 华为技术有限公司 业务承载映射方法及通信设备
CN101631336B (zh) * 2009-08-06 2012-06-06 中兴通讯股份有限公司 用于上行传输流模板的管理方法和装置
US9461848B2 (en) * 2009-10-13 2016-10-04 Nec Corporation Gateway device, mobile communication system, mobile terminal, packet transfer control method, control method of mobile terminal, and non-transitory computer readable medium
EP2502439B1 (en) * 2009-11-16 2013-07-24 Telefonaktiebolaget LM Ericsson (publ) Apparatuses for establishing and carrying out a communications session according to the Internet Protocol
US8891380B2 (en) * 2010-02-26 2014-11-18 Qualcomm Incorporated Systems and methods for synchronizing filter records
US8908636B2 (en) * 2010-06-21 2014-12-09 Qualcomm Incorporated Method and apparatus for QoS context transfer during inter radio access technology handover in a wireless communication system
US8787172B2 (en) 2010-06-21 2014-07-22 Qualcomm Incorporated Method and apparatus for QoS context transfer during inter radio access technology handover in a wireless communication system
US9160707B2 (en) * 2010-10-22 2015-10-13 Telefonaktiebolaget L M Ericsson (Publ) Differentiated handling of network traffic using network address translation
WO2012052569A1 (en) * 2010-10-22 2012-04-26 Telefonaktiebolaget L M 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
WO2013034195A1 (en) * 2011-09-09 2013-03-14 Telefonaktiebolaget L M Ericsson (Publ) Differentiated handling of data traffic with user-class dependent adaptation of network address lookup
BR112015013707A8 (pt) * 2012-12-14 2019-10-08 Ericsson Telefon Ab L M método em uma estação base, estação base, método em um nó de comunicação, e, nó de comunicação para assistir em um estabelecimento de um transmissor auxiliar
FR3011704A1 (fr) * 2013-10-07 2015-04-10 Orange Procede de mise en œuvre d'une session de communication entre une pluralite de terminaux
US20150215840A1 (en) * 2014-01-30 2015-07-30 Intel IP Corporation Systems, methods and devices for application specific routing in dual connectivity
WO2015138265A1 (en) * 2014-03-14 2015-09-17 Intel IP Corporation Method and apparatus to assist network traffic
US10277377B2 (en) 2014-09-09 2019-04-30 International Business Machines Corporation Dynamic quality of service adjustment using device-side analytics
EP3145269A1 (en) * 2015-09-16 2017-03-22 Alcatel Lucent Method, devices and system for a hybrid bearer service
US9980303B2 (en) * 2015-12-18 2018-05-22 Cisco Technology, Inc. Establishing a private network using multi-uplink capable network devices
US10353640B2 (en) * 2016-12-06 2019-07-16 Dell Products L.P. Seamless data migration in a clustered environment

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040151155A1 (en) * 2001-03-14 2004-08-05 Jarkko Jouppi Method for activating a connection in a communications system, mobile station, network element and packet filter
ATE313193T1 (de) * 2001-10-31 2005-12-15 Nokia Corp Eine methode für handhabung von meldungen zwischen einem terminal und einem datennetz
KR100438430B1 (ko) * 2002-01-24 2004-07-03 삼성전자주식회사 이동통신시스템에서 트래픽 플로우 탬플릿 재정렬 장치 및방법
US20050041631A1 (en) * 2003-08-20 2005-02-24 Naveen Aerrabotu Apparatus and method for primary link packet control
US20070160015A1 (en) * 2006-01-09 2007-07-12 Cisco Technology, Inc. Applying one or more session access parameters to one or more data sessions

Also Published As

Publication number Publication date
WO2007129199A2 (en) 2007-11-15
EP2025108B1 (en) 2012-03-21
WO2007129199A3 (en) 2008-12-04
EP2025108A2 (en) 2009-02-18
US8094644B2 (en) 2012-01-10
ATE550906T1 (de) 2012-04-15
US20100008292A1 (en) 2010-01-14

Similar Documents

Publication Publication Date Title
ES2384649T3 (es) Método y sistema para configurar dinámicamente una plantilla de flujo de tráfico
ES2638637T3 (es) Técnicas de gestión del tráfico de red
ES2390582T3 (es) Método y sistema para el servicio de control de velocidad en una red
ES2941246T3 (es) QoS de extremo a extremo cuando se integran redes de acceso distintas de 3GPP de confianza y redes principales de 3GPP
US7782834B2 (en) Routing header based routing in internet protocol (IP)-cellular networks
CA2710887C (en) Policy control and charging (pcc) rules based on mobility protocol
ES2232159T3 (es) Control de calidad de servicio en un sistema de comunicaciones moviles.
JP4444833B2 (ja) 電気通信
ES2612350T3 (es) Red de radio por paquetes y método para la activación de un contexto de protocolo de datos por paquetes
EP2441211B1 (en) Performance monitoring in a communication network
ES2299050T3 (es) Sistema y procedimiento para transmitir datos de paquetes de internet mediante redes de radiocomunicaciones por paquetes.
ES2313903T3 (es) Metodo para optimizar la transmision de datos en un sistema de transmision inalambrica de datos por conmutacion de paquetes.
ES2333801T3 (es) Sistema de telecomunicaciones.
US8611296B2 (en) Method and apparatus for data transfer in a packet-switched network
EP1400136B1 (en) Mapping of packets to pdp contexts in multisession connection
WO2003039170A1 (en) General packet radio service (gprs) tunneling protocol (gtp) signalling message filtering
ES2310358T3 (es) Tunelizacion de paquetes de protocolo de internet entre un nodo de soporte de pasarela y un terminal movil.
ES2536486T3 (es) Procedimiento y aparato para realizar acciones en paquetes en nodos intermedios en una conexión entre un dispositivo de comunicación y un dispositivo de destino en una red objetivo
JP4834133B2 (ja) 電気通信
ES2361183T3 (es) Procedimiento para el control de recursos en elementos de red en una red de telecomunicaciones.
WO2016019985A1 (en) Method computer program product and apparatus for traffic flow differentiation
ES2431577T3 (es) Activación del contexto PDP iniciado por red
ES2527109T3 (es) Dispositivo y procedimiento para la conmutación entre dominios