ES2299050T3 - Sistema y procedimiento para transmitir datos de paquetes de internet mediante redes de radiocomunicaciones por paquetes. - Google Patents
Sistema y procedimiento para transmitir datos de paquetes de internet mediante redes de radiocomunicaciones por paquetes. Download PDFInfo
- Publication number
- ES2299050T3 ES2299050T3 ES05759502T ES05759502T ES2299050T3 ES 2299050 T3 ES2299050 T3 ES 2299050T3 ES 05759502 T ES05759502 T ES 05759502T ES 05759502 T ES05759502 T ES 05759502T ES 2299050 T3 ES2299050 T3 ES 2299050T3
- Authority
- ES
- Spain
- Prior art keywords
- address
- internet
- protocol
- internet protocol
- data
- 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
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- 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/74—Address processing for routing
- H04L45/741—Routing in networks with a plurality of addressing schemes, e.g. with both IPv4 and IPv6
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/10—Mapping addresses of different types
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/16—Gateway arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/26—Network addressing or numbering for mobility support
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/005—Data network PoA devices
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Sistema de telecomunicaciones para transmitir datos de paquetes de Internet según un primer protocolo de Internet, por medio de una red de radiocomunicaciones por paquetes (1) que funciona sólo de acuerdo con un segundo protocolo de Internet, comprendiendo el sistema: un equipo de usuario (2) que puede funcionar para solicitar un portador para transmitir datos de protocolo de Internet según el segundo protocolo de Internet, hasta y desde un nodo de soporte de pasarela (3) de la red de radiocomunicaciones por paquetes (1); pudiendo funcionar el nodo de soporte de pasarela (3) para establecer un portador de protocolo de tunelización (14) para transmitir los datos de paquetes de Internet hasta y desde el equipo de usuario (2) a través de la red de radiocomunicaciones por paquetes (1), y pudiendo funcionar el equipo de usuario (2), en combinación con el nodo de soporte de pasarela (3), para; generar una dirección que es compatible con el primer protocolo de Internet, presentando la dirección un componente de identificador de interfaz que comprende un identificador de terminación de túnel del portador de protocolo de tunelización (14) que termina en el nodo de soporte de pasarela (3) de la red de radiocomunicaciones por paquetes (1); y transmitir datos de paquetes de Internet desde y hasta un nodo correspondiente por medio del nodo de soporte de pasarela (3) y el portador establecido (14), utilizando la dirección de protocolo de Internet que es compatible con el primer protocolo de Internet.
Description
Sistema y procedimiento para transmitir datos de
paquetes de Internet mediante redes de radiocomunicaciones por
paquetes.
La presente invención se refiere a un sistema y
a un procedimiento para transmitir datos de paquetes de Internet por
medio de redes de radiocomunicaciones por paquetes, tales como, por
ejemplo, una red que funciona según el Servicio General de
Radiocomunicaciones por paquetes (GPRS).
La tecnología GPRS ha sido diseñada para la
transmisión de paquetes de Internet por medio de una interfaz de
acceso radio. Puede formarse una red GPRS utilizando una red troncal
de Sistema Global para comunicaciones móviles (GSM) o Sistema
Universal de Telecomunicaciones Móviles (UMTS). La tecnología GPRS
presta apoyo para los servicios orientados a paquetes y trata de
aprovechar al máximo los recursos de red y radio para las
transmisiones de datos de paquetes, utilizando, por ejemplo, el
Protocolo Internet (IP). La tecnología GPRS facilita una
arquitectura lógica, que está relacionada con la arquitectura de
paquetes conmutados de un sistema de radio móvil.
La Fuerza de Tarea de Ingeniería de Internet
(IEFT) es el organismo responsable de diseñar protocolos de Internet
para permitir las comunicaciones por medio de Internet. Por
ejemplo, un protocolo de Internet bien establecido es el Protocolo
Internet versión 4 (IPV4) diseñado y normalizado para permitir a los
ordenadores personales el acceso a Internet. La IETF también ha
elaborado otra norma denominada Protocolo Internet versión 6 (IPV6)
que representa un perfeccionamiento con respecto al IPV4, en la
medida en que facilita las comunicaciones móviles e incrementa las
opciones de direccionamiento para el equipo del usuario. Aunque hay
similitudes entre el IPv4 y el IPv6, las redes de
radiocomunicaciones por paquetes establecidas para operar con el
IPv4 esperan obtener paquetes que se ajustan a la norma IPv4 en
lugar de la norma IPv6.
En el documento de la patente publicada
WO1/93540 publicada el 6 de diciembre de 2001, se da a conocer cómo
se forman direcciones IPv6 que comprenden un componente que dispone
por lo menos de una parte del identificador Identificador de Punto
final de tunelización (TEID) como dirección de contexto PDP de una
red GPRS basada en la norma IPv6.
Por consiguiente, la compatibilidad del
protocolo de Internet de la dirección generada viene determinada por
el protocolo de Internet del procedimiento de activación del
contexto PDP.
Según la presente invención, se proporciona un
sistema, un procedimiento, un programa informático y un aparato de
telecomunicaciones para transmitir datos de paquetes de Internet
según un primer protocolo de Internet (IPv6), por medio de una red
de radiocomunicaciones por paquetes que funciona de acuerdo con un
segundo protocolo de Internet (IPv4). El sistema comprende un
equipo de usuario operativo para solicitar un portador para
transmitir datos del protocolo de Internet según el segundo
protocolo de Internet (IPv4), hasta y desde un nodo de soporte de
pasarela de la red de radiocomunicaciones por paquetes. El nodo de
soporte de pasarela es operativo para establecer un portador de
protocolo de tunelización para transmitir los datos de paquetes de
Internet hasta y desde el equipo de usuario, a través de la red de
radiocomunicaciones por paquetes. El equipo de usuario es
operativo, junto con el nodo de soporte de pasarela, para generar
una dirección que es compatible con el primer protocolo de Internet
(IPv6), incluyendo la dirección un identificador de interfaz que
presenta un identificador de terminación de tunelado del portador
de protocolo de tunelización que termina en el nodo de soporte de
pasarela de la red de radiocomunicaciones por paquetes. Los datos de
paquetes de Internet se transmiten hasta y desde un nodo
correspondiente por medio del nodo de soporte de pasarela y el
portador establecido, utilizando la dirección de protocolo de
Internet que es compatible con el primer protocolo de Internet
(IPv6).
Los sistemas según la presente invención están
dispuestos para generar una dirección que es compatible con un
primer protocolo de Internet, que puede utilizarse para transmitir
datos de paquetes de Internet por medio de una red de
radiocomunicaciones por paquetes que está dispuesta para admitir
datos de paquetes de Internet según un segundo protocolo de
Internet. La dirección formada contiene un componente de dirección
de identificador de interfaz, que comprende un identificador de
terminación de tunelado obtenido a partir del portador de datos de
paquetes asignado de la red de radiocomunicaciones por paquetes. El
identificador de terminación de tunelado indica la terminación del
portador de protocolo de tunelización asignado por la red de
radiocomunicaciones por paquetes. El identificador de terminación
de tunelado indica una dirección casi exclusiva dentro de la red de
radiocomunicaciones por paquetes que, por haber sido formada dentro
de una dirección que es compatible con el primer protocolo de
Internet, puede ser utilizada para transmitir datos de paquetes de
Internet por medio de la red de radiocomunicaciones por
paquetes.
La generación de la dirección compatible con el
identificador de terminación de tunelado permite que el nodo de
soporte de pasarela sea operativo, en algunas formas de realización,
para identificar el portador y transmitir los datos de paquetes de
Internet desde el nodo correspondiente hasta el equipo de usuario
por medio de la red de radiocomunicaciones por paquetes, utilizando
el identificador de terminación de tunelado. Es decir, los paquetes
de Internet son encaminados por el nodo de soporte de pasarela desde
el nodo correspondiente hasta el equipo del usuario por medio de la
red de radiocomunicaciones por paquetes, utilizando el identificador
de terminación de tunelado para identificar el portador asignado.
El tunelado por medio de la red de radiocomunicaciones por paquetes
es, por lo tanto, sustancialmente automático. El modelo de flujo
Plantilla de Volumen de Tráfico (TFT) del nodo de soporte de
pasarela, que habitualmente se utiliza para encaminar datos de
paquetes de Internet hacia el equipo del usuario mediante la
dirección de origen, puede ser pasado por alto. Esto se debe al
hecho de que el portador que se ha establecido para transmitir
datos de paquetes de Internet a través de la red de
radiocomunicaciones por paquetes sólo reconoce los paquetes de
Internet según el segundo protocolo de Internet. No obstante, el
nodo correspondiente transmite datos de paquetes de Internet según
el primer protocolo de Internet (IPv6). Entonces, por ejemplo, el
TFT sólo reconocerá las direcciones IPv4. Mediante la identificación
del portador a partir del identificador de terminación de tunelado,
los paquetes de Internet pueden ser encaminados por medio del
portador IPv4, pasando por alto el TFT.
En algunas formas de realización, el
identificador de interfaz puede formarse a partir de una combinación
del identificador de terminación de tunelado de la red de
radiocomunicaciones por paquetes y un identificador de empresa. El
identificador de empresa se utiliza para generar el componente de
dirección del identificador de interfaz. El identificador de
empresa identifica el operador de la red de radiocomunicaciones por
paquetes. En combinación con el identificador de tunelado, puede
conferirse a la dirección compatible una significación global.
Entonces, la dirección puede ser utilizada para construir la
dirección de enlace local del primer protocolo de Internet y, a
continuación, puede ser utilizada por el equipo de usuario para
solicitar aplicaciones y servicios en la red de radiocomunicaciones
por paquetes. Asimismo, la dirección compatible puede ser utilizada
para solicitar una dirección globalmente exclusiva y encaminable que
se genera de acuerdo con el primer protocolo de Internet.
La dirección compatible puede comprender también
un campo que indica si la dirección es una dirección local para la
red de radiocomunicaciones por paquetes o una dirección global. Si
el campo contiene un valor que indica que la dirección es local, el
nodo de soporte de pasarela no permitirá la salida de paquetes de
Internet desde la red de radiocomunicaciones por paquetes. Sin
embargo, aunque el campo comprenda un valor que indica que la
dirección debe considerarse única, la dirección tal vez no sea
globalmente exclusiva. En consecuencia, en algunas formas de
realización, la dirección compatible puede incluir también un
prefijo, que se genera de acuerdo con el primer protocolo de
Internet. El prefijo puede obtenerse de acuerdo con el primer
protocolo de Internet. Esto es debido a que el UE (equipo de
usuario)/nodo puede obtener un prefijo IPv6 sin necesidad de
obtener la dirección IPv6 completa. La dirección compatible que es
una dirección IPv6 se genera con el ID de interfaz que comprende el
ID de empresa y el identificador de terminación de túnel. El prefijo
de primer protocolo de Internet puede obtenerse a partir de un
servidor de asignación de direcciones o de la recepción de los
mensajes de aviso del encaminador según el protocolo Neighbour
Discovery para IP versión 6 (RFC2461).
En otras formas de realización, el componente de
prefijo de la dirección puede ser preasignado de forma estática. Por
consiguiente, el equipo de usuario genera la dirección compatible a
partir del prefijo asignado estáticamente y el identificador de
interfaz, que comprende el identificador de terminación de
tunelado.
Mediante la combinación del identificador de
interfaz formado a partir del identificador de terminación de
tunelado y el identificador de empresa con el prefijo formado de
acuerdo con el primer protocolo de Internet, es posible generar una
dirección globalmente exclusiva que puede ser utilizada para
encaminar datos de paquetes de Internet por medio de la red de
datos por paquetes externa. Esta dirección puede utilizarse para
identificar el equipo de usuario para las aplicaciones de protocolo
de Internet según el primer protocolo de Internet. Por lo tanto, el
equipo de usuario puede acceder a servicios que emplean el primer
protocolo de Internet. En algunas formas de realización, la
dirección compatible generada es una dirección globalmente
exclusiva. En consecuencia, es posible acceder al equipo del
usuario por medio de la red de datos por paquetes externa (IPv6).
En otras formas de realización, la dirección compatible que no es
globalmente exclusiva, sino localmente exclusiva, sólo es accesible
dentro de la red Red Pública del Servicio Móvil Terrestre (PLMN)
utilizando la dirección de enlace local IPv6.
En algunas formas de realización, el primer
protocolo de Internet puede ser el Protocolo Internet versión 6
(IPv6) y el segundo protocolo de Internet puede ser el Protocolo
Internet versión 4 (IPv4). Puede disponerse que la dirección
compatible (es decir, una dirección compatible con el primer
protocolo de Internet) sea globalmente exclusiva, dotando al
identificador de interfaz de un componente de prefijo de dirección
según el primer protocolo de Internet. En algunas formas de
realización, el componente de prefijo es suministrado al equipo del
usuario, siendo generada entonces la dirección compatible con un
prefijo estático. En otras formas de realización, el componente de
prefijo se obtiene dinámicamente, obteniendo un componente de
prefijo IPv6 y generando la dirección compatible a partir del
identificador de interfaz y el componente de prefijo.
Las formas de realización de la presente
invención pueden aportar al equipo de usuario la capacidad para
ejecutar programas de aplicación que requieren la utilización de
comunicaciones de protocolo de Internet según un protocolo de
Internet que emplea una red de sistema de paquetes de radio que ha
sido dispuesta para transmitir paquetes de Internet según un
protocolo de Internet diferente. La red de radiocomunicaciones por
paquetes puede ser, por ejemplo, una red de Servicio General de
Radiocomunicaciones por Paquetes (GPRS).
En las reivindicaciones adjuntas, se definen
otros aspectos y características de la presente invención, haciendo
referencia a las formas de realización descritas a continuación.
A continuación, las formas de realización de la
presente invención se describirán únicamente a título de ejemplo,
haciendo referencia a los dibujos adjuntos, en los que se asignan
números de referencia correspondientes a las partes similares y en
los que:
la Figura 1 es un diagrama de bloques
esquemático de un sistema de telecomunicaciones que comprende una
red GPRS;
la Figura 2 es un diagrama de bloques
esquemático de las partes de la red GPRS que forman un portador de
tunelado para transmitir paquetes de Internet;
la Figura 3a es un diagrama que ilustra un
identificador de punto de terminación de túnel para la transmisión
de datos, y la Figura 3b es el correspondiente diagrama para los
datos de plano de control;
la Figura 4a ilustra esquemáticamente un formato
de dirección para un primer ID de GAT (GAT_ID_I) localmente
exclusivo, y la Figura 4b ilustra esquemáticamente un formato de
dirección para un primer ID de GAT (GAT_ID_I) globalmente
exclusivo;
la Figura 5 ilustra esquemáticamente un formato
de dirección para un segundo ID de GAT (GAT_ID_II);
la Figura 6 ilustra esquemáticamente un formato
de dirección para una dirección IPv6 asignada mediante un mensaje de
activación de contexto PDP;
la Figura 7 ilustra esquemáticamente un formato
de dirección general para el tunelado GTP automático;
la Figura 8a ilustra esquemáticamente un formato
de dirección para una dirección de enlace local para el tunelado GTP
automático, y la Figura 8b ilustra esquemáticamente una
correspondiente dirección para una dirección de sitio local;
la Figura 9 ilustra esquemáticamente un formato
de dirección para una dirección compatible con IPv6 que comprende un
prefijo IPv6 y un segundo ID de GAT (GAT_ID_II);
la Figura 10 es un diagrama de bloques
esquemático de las partes de la red GPRS que sirven para formar un
túnel de portador de acceso radio;
la Figura 11 es un diagrama de bloques
esquemático de las partes de la red GPRS que sirven para formar un
túnel GTP;
la Figura 12 es un diagrama de bloques
esquemático de una versión simplificada del sistema de
telecomunicaciones que aparece en la Figura 1, que ilustra el
tunelado automático;
la Figura 13 es un diagrama de flujo que ilustra
un procedimiento para generar una dirección GAT;
la Figura 14 es un diagrama de flujo que ilustra
un procedimiento para generar una dirección GAT IPv6 globalmente
encaminable;
la Figura 15 es un diagrama de flujo que ilustra
dos opciones para generar identificadores de interfaz de dirección
GAT diferentes;
la Figura 16 es un diagrama de flujo que ilustra
un procedimiento para transmitir por medio de la red GPRS,
utilizando la dirección GAT;
la Figura 17 es un ejemplo de un formato general
de una dirección IPv6;
la Figura 18 es un ejemplo de una dirección IPv6
que presenta un prefijo de subred de n bits;
la Figura 19 es un ejemplo de un identificador
de interfaz en formato EUI-64 modificado;
la Figura 20 es un ejemplo de una dirección IPv6
global de unidifusión;
la Figura 21 es un ejemplo de una dirección IPv6
que presenta una dirección IPv4 integrada;
la Figura 22 es un segundo ejemplo de una
dirección IPv6 que presenta una dirección IPv4 integrada;
la Figura 23 es un ejemplo de una dirección IPv6
de sitio local;
la Figura 24 es un ejemplo de una dirección IPv6
de enlace local; y
la Figura 25 es un diagrama de flujo que ilustra
algunas etapas del procedimiento, que son necesarias para establecer
un portador para paquetes de Internet a través de una red GPRS.
Las formas de realización descritas a
continuación aportan mecanismos para permitir el tráfico IPv6 a
través de una red GPRS/UMTS que se ajusta sólo al IPv4. De este
modo, los operadores 3G son capaces de admitir una red IPv6,
utilizando el UMTS disponible que se ajusta sólo al IPv4,
reduciéndose al mínimo de ese modo los riesgos asociados a la
introducción anticipada del IMS IPv6.
La Figura 1 representa un diagrama de bloques
esquemático de un sistema para transmitir paquetes de Internet
según un primer protocolo de Internet (IPv6), por medio de una red
de sistema de paquetes de radio 1 que ha sido diseñada para
permitir la transmisión de paquetes de Internet según una segunda
norma de protocolo de Internet (IPv4). En la Figura 1, el equipo de
usuario (UE) 2 está dispuesto para contener un programa de
aplicación que presta, por ejemplo, un servicio multimedia al
usuario. El programa de aplicación tal vez necesite, por ejemplo,
acceder a un subsistema multimedia de protocolo Internet (IMS), tal
como el diseñado por el 3GPP para prestar servicios multimedia a los
usuarios utilizando una red troncal UMTS.
En el presente ejemplo, la red del sistema de
paquetes de radio 1 es una red de Servicio General de
Radiocomunicaciones por Paquetes (GPRS). Para simplificar, la
Figura 1 representa los elementos de red GPRS siguientes: el Nodo
de Soporte del servicio GPRS (GGSN) 3, los Nodos de Soporte GPRS de
Tránsito (GGSN) 4, los Controladores de Red de Radio (RNC) 8 y los
Nodos B 10.
La presente técnica se refiere a las
comunicaciones de protocolo de Internet entre un nodo
correspondiente (CN) 12 y un UE 2 conectado a la red GPRS 1. El CN
12 representado en la Figura 1 está conectado a una Red de Datos
por Paquetes (PDN) 15, que a su vez está conectada a la red GPRS.
Para transmitir datos de paquetes de Internet entre el CN y el UE
se establece un portador a través de la red GPRS, como el ilustrado
en la Figura 2.
En la Figura 2, se representa el portador 14
establecido entre el GGSN 3 y el UE 2 para transmitir paquetes de
Internet 5 que presentan una cabecera 7 que contiene una dirección y
unos datos de carga útil 9, hasta y desde el UE 2 y el CN 12.
Generalmente, el GGSN 4 y el SGSN 6 forman parte de una red central
(CN). Para la red central, el portador consiste en un portador de
Protocolo de Tunelización GPRS( (GTP). El controlador de red de
radio RNC 8 y el Nodo B 10 forman parte de una red de radio (RN).
Para la red de radio RN, el portador está constituido por un
portador de protocolo de tunelización RAB (Radio Access Bearer). El
portador está dispuesto para transmitir paquetes de Internet 16
entre el UE y el GGSN. Los paquetes de Internet presentan una
dirección 18 y una carga útil 20.
En el presente ejemplo, el UE 2 ejecuta un
programa de aplicación que requiere el soporte de, por ejemplo, los
servicios IMS. No obstante, el IMS ha sido diseñado y normalizado de
acuerdo con la norma de protocolo Internet IPv6, mientras que la
red GPRS 1 ha sido diseñada para permitir las comunicaciones de
protocolo Internet IPv4. Como se explicará brevemente, según la
presente técnica, se establece un portador para que el UE 2
transmita al CN 12 paquetes de Internet IPv6 por medio de la red
GPRS. Con esta finalidad, la presente técnica es operativa para
generar un protocolo de Internet que puede ser utilizado para la
comunicación por medio del portador 14 que está dispuesto para
permitir las comunicaciones IPv4.
Para dotar al equipo de usuario UE de un
mecanismo que le permita enviar y recibir paquetes de Internet según
el protocolo Internet IPv6 por medio de una red GPRS que funciona
de acuerdo con el protocolo Internet IPv4, se construye una
dirección que puede ser sometida a tunelado automático a través de
la red GPRS. La construcción de dicha dirección se describe en la
sección siguiente. El Anexo 1 contiene información más general
referente a la construcción de direcciones IPv6.
En la presente técnica, se utiliza un
identificador de punto de terminación de túnel de un portador de
protocolo de tunelización GPRS para definir un identificador de
interfaz a partir del cual puede generarse una dirección IPv6 de
enlace local. El identificador de interfaz puede utilizarse para
generar una dirección compatible con IPv6 que puede ser sometida a
tunelado automático a través de la red GPRS y, por este motivo, se
denomina ID de interfaz de Tunelización Automática GPRS (GAT). El
ID de interfaz GAT se define utilizando un identificador de punto
de terminación de túnel de protocolo de tunelización GPRS, según la
especificación técnica TS29.060. En la Figura 3a, se representa la
forma del TEID para la transmisión de datos y, en la Figura 3b, para
los datos de plano de control.
En un primer ejemplo de identificador de
interfaz que puede ser utilizado para generar una dirección que es
compatible con IPv6 de acuerdo con la arquitectura de
direccionamiento IPv6 (RFC2373, Apéndice A), se utiliza el TEID en
combinación con un identificador de empresa. El identificador de
interfaz presenta 64 bits y utiliza un formato IEEE
EUI-64 modificado. El TEID se utiliza para construir
el identificador de interfaz conforme al RFC2373. La dirección se
construye como se representa en las Figuras 4a y 4b, siendo "c"
asignado a company_id, y siendo "g" un campo que confiere la
significación individual/grupal. Existen dos formas de dirección
GAT_ID_I: una dirección IEEE EUI-64 localmente
exclusiva como la representada en la Figura 4a y otra dirección IEEE
EUI-64 globalmente exclusiva como la representada en
la Figura 4b.
En un segundo ejemplo de identificador de
interfaz que puede utilizarse para construir una dirección
compatible con IPv6, se utiliza la dirección IPv4 asignada como
parte de una petición de activación de contexto PDP. En el Anexo 2,
se describen en mayor las asignaciones de portador y dirección IPv4
llevadas a cabo por el GGSN. En el plano de control, el GTP
especifica un protocolo de control y gestión de túnel
(GTP-C) que permite al SGSN proporcionar acceso a
la red de datos por paquetes a un UE. Se utiliza señalización de
plano de control para crear, modificar y suprimir túneles. En el
plano del usuario, el GTP utiliza un mecanismo de tunelado
(GTP-U) para prestar un servicio para transmitir
datos de paquetes del usuario.
El ID de interfaz GAT (GPRS Automatic
Tunnelling) se define como el identificador Tunel Endpoint
Identifier GTP definido en la TS29.060, combinado con el indicador
del Identificador GAT (0xFF, 11111111) seguido de una dirección
IPv4 de 32 bits del UE. Debido a que el ID de GAT es asignado por el
GGSN que gestiona las sesiones con el UE, sólo tiene alcance
local.
El TEID se utiliza como un componente del ID de
interfaz GAT (ID de GAT) en la construcción de la dirección IPv6 de
enlace local, como se ilustra en la Figura 5. En la Figura 5, el
primer octeto del ID de GAT es el tipo de GTP. Para el GTP de datos
(GTP_U), el tipo de GTP es 16 (00010000). Para el GTP de información
de control (GTP_U), el tipo de GTP es 17 (00010001). En este octeto
de tipo de GTP, se define un bit adicional como bit "para indicar
si la dirección IPv4 es privada o pública". El bit "T" se
establece en 1 si la dirección IPv4 es pública y globalmente
exclusiva; en caso contrario, se establece en cero.
Para construir el GAT_ID, es necesario informar
al UE acerca del TEID del portador de GTP que ha sido establecido
por el GGSN. En la activación de contexto PDP "convencional",
el TEID se utiliza localmente dentro del RNC, el SGSN y el GGSN.
Debido a que el UE necesita construir el ID de interfaz mediante el
TEID, es necesario pasar el TEID al UE. En un primer ejemplo, el
TEID se pasa directamente al UE. En este caso, el SGSN puede
decidir pasar uno o los tres pares de TEID (6 en total) al UE,
utilizando el campo PCO (Protocol Configuration Option) del mensaje
de aceptación de activación de contexto PDP.
En un segundo ejemplo, el GGSN utiliza uno de
sus TEID para construir una dirección IPv6 de acuerdo con sus
planes de direccionamiento y, a continuación, pasa dicha dirección
al SGSN en el campo PCO del mensaje de respuesta de creación de
contexto PDP. A su vez, el SGSN pasa esta dirección IPv6 construida
por el GGSN al UE, utilizando el campo PCO del mensaje de aceptación
de activación de contexto PDP.
Los ejemplos de direcciones GAT que pueden
generarse de acuerdo con la presente técnica comprenden la
generación de la dirección GAT a partir de una combinación de una
dirección IPv4 asignada y el TEID y la generación de la dirección
utilizando una dirección EUI-64 modificada con un
TEID de GTP. Estos ejemplos se describen a continuación de forma más
detallada.
Una vez activado satisfactoriamente el contexto
PDP, se asigna una dirección IPv4 al UE. Entonces, dicha dirección
IP puede utilizarse para construir una dirección IPv6 en cualquiera
de los formatos representados en la Figura 6. Los formatos
representados en la Figura 6 también se consideran direcciones IPv6
que empiezan con un 0 binario. Estos formatos son para ser
utilizados por el UE, en caso de que la PDN se base en el IPv4 y sea
necesario un tunelado IPv6 sobre IPv4 a través de la PDN para
alcanzar un dominio IPv6.
Otro ejemplo de dirección es una dirección
EUI-64 modificada, que es una dirección IPv6 de
enlace local de unidifusión construida añadiendo un prefijo de
dirección más el ID de interfaz GAT. En la Figura 7, se representa
una forma general de dirección generada de acuerdo con este ejemplo
de técnica. En este ejemplo, el prefijo (de red) ocupa el resto de
los 8 bytes. En el GAT_ID_I, el prefijo ocupa 8 bytes. En el
GAT_ID_II, el prefijo de red ocupa 6 bytes porque el GAT_ID_II
emplea 10 bytes. Hay dos formatos posibles para el formato de
dirección general representado en la Figura 7, siendo éstos
representados en las Figuras 8a y 8c.
- \bullet Caso I:
- Se provee un prefijo de encaminamiento global más el ID de subred a una dirección global de unidifusión, es decir, los n + m bits son 8 octetos. La obtención de esta dirección se explica en una sección posterior.
- \bullet Caso II:
- Se provee, a una dirección de sitio/enlace local de unidifusión, un formato como el representado en la Figura 8a para una dirección de enlace local y un formato como el representado en la Figura 8b para una dirección de sitio local. De acuerdo con el documento RFC2373, los paquetes IPv6 con direcciones de sitio local o enlace local de origen o destino no deben ser enviados por los encaminadores fuera del sitio. Estas direcciones son para ser utilizadas con finalidades tales como las de configuración automática de direcciones y la autoconfiguración de nodos ("neighbour discovery") o cuando no se dispone de encaminadores.
En el caso de las redes GPRS/UMTS, las dos
direcciones locales de las Figuras 8a y 8b pueden utilizarse en las
comunicaciones intra-PLMN (Public Land Mobile
Network) entre los UE, es decir, los UE homólogos están situados en
la misma PLMN y no se encamina ningún paquete por medio de la
interfaz Gi hacia la PDN externa de la Figura 1.
En la Figura 9, se representa una forma general
de dirección IPv6, que se crea utilizando el GAT_ID_II más un
prefijo IPv6. La ventaja de utilizar el GAT_ID_II es que permite el
tunelado automático de IPv6 sobre IPv4 cuando el protocolo IPv6 no
está disponible, como sucede cuando los paquetes se dirigen hacia
una red de datos por paquetes IPv4 por medio de la interfaz Gi.
Esto es posible debido a que el GAT_ID_II permite el tunelado
automático de IPv6 sobre IPv4, gracias a la integración de una
dirección IPv4 en la dirección IPv6.
Dependiendo de la opción de dirección compatible
con IPv6 generada, el UE tal vez necesite emprender todavía otras
acciones para finalizar la construcción de una dirección global de
unidifusión. Por ejemplo, la dirección puede ser globalmente
exclusiva pero no globalmente encaminable. En estos casos, el UE
puede utilizar direcciones que requieren un prefijo para ser
encaminables o no encaminables globalmente, tal como los que
utilizan las direcciones de sitios/enlaces locales descritas
anteriormente.
Para construir una dirección IPv6 globalmente
encaminable tras recibir la petición de creación de contexto PDP, el
GGSN puede realizar una de las operaciones siguientes:
- \bullet
- Asignar un prefijo (ya sea local o solicitado al DHCP para IPv6) y pasarlo al GGSN y de ahí al UE, utilizando el campo PCO de los mensajes de contexto PDP.
- \bullet
- Construir las direcciones de sitios/enlaces locales indicadas en la Figura 8a y la Figura 8b en representación del UE y utilizarlas para solicitar un prefijo a un DHCP para IPv6. A continuación, el GGSN puede enviar el prefijo más el GAT_ID_I o toda la dirección IPv6 globalmente exclusiva, como se representa en las Figuras 4a y 4b.
- \bullet
- Como alternativa, puede asignarse estáticamente un prefijo al UE, en cuyo caso el UE siempre conoce su prefijo.
- \bullet
- Como alternativa, el UE puede utilizar la dirección de enlace local para escuchar el mensaje de aviso del encaminador que contiene el prefijo (RFC2461, Neighbour Discovery for IP Versión 6).
El túnel GAT consta de dos secciones que son el
túnel RAB (RAB_T) y el túnel GTP (GTP_T). El túnel RAB_T se ilustra
en el diagrama representado en la Figura 10. El túnel RAB_T se halla
entre el UE y el RNC y su tunelado tiene lugar a través de una capa
RLC, hallándose los puntos de terminación de los túneles de las
entidades RLC dentro del UE y el RNC, respectivamente. De hecho, el
RLC es la capa de enlace del paquete IPv6. En este caso, el paquete
IPv6 construido mediante la dirección GAT como dirección IPv6 propia
es la SDU del RLC.
El túnel GTP_T se ilustra en la Figura 11. El
túnel GTP permite el tunelado de paquetes de varios protocolos a
través de la red troncal UMTS/GPRS entre los GNS y entre los SGSS y
la UTRAN. Los SGSN y los GGSN de la red troncal UMTS/GPRS y los RNC
(Radio Network Controllers) de la UTRAN implementan el protocolo
GTP-U. Los SGSN y GGSN en la red troncal UMTS/GPRS
implementan el protocolo GTP-C. No es necesario que
ningún otro sistema sea compatible con el GTP. Los UE UMTS/GPRS
están conectados a un SGSN sin compatibilidad con GTP. En la Figura
11, se ilustra la utilización del túnel GTP_U para el tunelado
automático de paquetes IPv6 que transmiten datos de usuario o
información de control/señalización. Como alternativa, el GTP_T que
emplea el tunelado automático del GTP_C se utiliza para los
paquetes IPv6 que transmiten datos de control/señalización de la
red, y el GTP_T que emplea el GTP_U se utiliza para los paquetes
IPv6 que transmiten datos de
usuario.
usuario.
La Figura 12 ilustra sistemas que funcionan de
acuerdo con la presente técnica. Como se ilustra en la Figura 12,
la presente técnica aporta una disposición por medio de la cual el
portador GPRS/UMTS, que es la capa de enlace del IPv6, puede
transmitir paquetes IPv6 utilizando tramas GPRS/UMTS. Con esta
finalidad, el UE solicita un contexto PDP IPv4, como se describe en
el Anexo 2. El UE puede utilizar una dirección IPv4 estática o
puede obtener mediante asignación una dirección IPv4 como
consecuencia de una activación de contexto PDP satisfactoria.
Entonces, el UE construye la dirección GAT según
la definición descrita en la sección 4 y la asigna a por lo menos
una (y sólo una) interfaz de UE. Esta interfaz con la dirección GAT
se utiliza para enviar paquetes de Internet.
En caso de que el UE construya más de una
dirección GAT utilizando diferentes ID de interfaz GAT, el UE puede
asignar direcciones GAT a varias interfaces, asignándose cada una
solamente a una interfaz. Las direcciones GAT sólo se asignan una
vez a una interfaz, mientras que las interfaces puede tener
asignadas más de una dirección GAT diferente.
Tras la activación de una aplicación IPv6
(basada en TCP o en UDP), se utiliza una dirección GAT y se
selecciona la correspondiente interfaz o interfaces para enviar y
recibir los paquetes IPv6 por medio de dicha interfaz o
interfaces.
El funcionamiento del sistema descrito
anteriormente que está dispuesto para proveer una dirección
compatible con IPv6 a un equipo de usuario se resume con referencia
a los diagramas de flujo de las Figuras 13, 14 y 15. La Figura 13
representa un sumario de un procedimiento general que genera una
dirección compatible que comprende un identificador de interfaz que
puede ser reconocido por la red GPRS, mientras que la Figura 14
ilustra un procedimiento para hacer que la dirección sea globalmente
encaminable suministrando un prefijo de acuerdo con la norma IPv6.
El procedimiento para generar el ID de interfaz GAT ilustrado en la
Figura 13 se resume como se indica a continuación.
- S1:
- El equipo de usuario solicita un portador para transmitir paquetes de Internet a través de la red de radiocomunicaciones por paquetes (red GPRS) enviando una petición de contexto de Protocolo de Datos en Paquetes (PDP) al GGSN. Como parte de la activación de contexto PDP, el GGSN activa un portador a través de la red GPRS que, por supuesto, será un portador que se ajusta a la norma IPv4.
- S2:
- El GGSN recibe la petición de activación de contexto PDP y establece un portador para transmitir datos de paquetes de Internet entre el UE y el GGSN. El portador comprende un portador de protocolo de tunelización de acuerdo con el protocolo de tunelización GPRS (GTP) para realizar el tunelado de paquetes de Internet a través de componentes de red central de la red GPRS. El portador comprende también un portador de acceso de radio (RAB) para realizar el tunelado de datos de paquetes de Internet a través de la red de acceso radio, desde el RNC hasta el UE, por medio de los elementos Nodo B.
- S4:
- Ya sea en el GGSN o bien en el UE, se genera una dirección que comprende un componente de ID de interfaz y un componente de prefijo de dirección.
- S8:
- Por consiguiente, el ID de interfaz se crea a partir del identificador de terminación de tunelado que indica la terminación del portador GTP. La dirección generada adquiere, por lo tanto, una significación local dentro de la red GPRS.
Opcionalmente, para hacer que una dirección sea
globalmente significativa y encaminable por medio de un encaminador
IPv6, es necesario que la dirección obtenga un prefijo IPv6. Este
procedimiento se ilustra en la Figura 14 y se resume tal como se
indica a continuación.
- S10:
- El UE obtiene el componente de prefijo de dirección IPv6. Por ejemplo, el prefijo de dirección IPv6 puede ser asignado estáticamente al UE. Como alternativa, la dirección de enlace local puede generarse con el ID de interfaz que comprende el identificador de terminación de tunelado para solicitar una dirección IPv6 a un servidor DHCP.
- S12:
- Una vez que el UE ha obtenido la dirección IPv6 del servidor DHCP, el UE puede sustituir el prefijo de la dirección IPv6 obtenida añadiendo un prefijo IPv6 a la dirección compatible. Por consiguiente, el UE genera una dirección compatible con IPv6 a partir del ID de interfaz y el prefijo de dirección IPv6.
- S14:
- El UE puede entonces transmitir datos de paquetes de Internet entre el UE y el CN utilizando la dirección compatible con IPv6.
La transmisión de datos de paquetes de Internet
entre el UE y el CN se resume mediante el diagrama de flujo de la
Figura 16 que se describirá en mayor detalle más adelante.
Como se indica con referencia a la etapa S4 de
la Figura 10, la presente técnica puede utilizar diversas opciones
para establecer una dirección compatible con el identificador de
terminación de tunelado. La dirección puede generarse en el GGSN a
partir de los datos de dirección# transmitidos al UE, o puede
generarse en el UE a partir de los datos de dirección transmitidos
desde el GGSN. El diagrama de flujo representado en la Figura 15
ilustra dos opciones para el caso en el que la dirección se genera
dentro del UE. La Figura 15 se resume de la forma indicada a
continuación.
- S14:
- El GGSN suministra al UE datos de dirección (por ejemplo, como parte de la asignación de contexto PDP) en el campo PCO del mensaje de aceptación de contexto PDP. Los datos de dirección se utilizan para generar el ID de interfaz de la dirección compatible.
- S16:
- En el primer ejemplo, el GGSN suministra una dirección IPv4 asignada por el GGSN al UE, con el TEID.
- S18:
- El UE genera el ID de interfaz con el TEID y la dirección IPv4. Por lo tanto, la dirección generada es globalmente exclusiva, aunque ésta necesita el prefijo de dirección IPv6 ilustrado con respecto a la Figura 9 para ser globalmente encaminable por medio de una red IPv6.
- S20:
- Como alternativa, el GGSN suministra un identificador de empresa con el TEID como parte de los datos de dirección transmitidos como parte de la activación de contexto PDP. Entonces, el UE genera el ID de interfaz a partir del TEID y el identificador de empresa.
- S22:
- Como parte de la dirección compatible, la dirección comprende un campo de significación de uso global/local. Si la dirección va a ser utilizada sólo localmente dentro de la red GPRS, el campo de significación se establece en cero. En cambio, si la dirección va a ser utilizada globalmente, es decir, fuera de la red GPRS, el campo de significación se establece en uno.
La Figura 16 ilustra un procedimiento de
transmisión de datos de paquetes de Internet utilizando la dirección
compatible por medio de la red GPRS. La Figura 16 se resume de la
forma indicada a continuación.
- S30:
- El UE transmite paquetes de Internet al CN, utilizando la dirección compatible por medio del túnel de portador de acceso radio y el túnel GTP independientemente de la forma de la dirección de la cabecera de los paquetes de Internet.
- S32:
- En las transmisiones de enlace descendente, el GGSN recibe datos de paquetes de Internet desde el nodo correspondiente CN. Los paquetes de Internet son paquetes IPv6 de Internet. No obstante, puesto que la red GPRS está dispuesta para permitir las comunicaciones IPv4 de Internet, el GGSN habrá establecido un portador IPv4. Como consecuencia de esto, el modelo de flujo de tráfico (TFT) que se utiliza para controlar las comunicaciones de Internet sólo reconocerá una dirección IPv4 como dirección de origen del nodo correspondiente. Es decir, el portador habrá sido establecido con referencia a una dirección IPv4 de origen. Así pues, el GGSN se modifica de tal forma que el procedimiento TFT es pasado por alto y el GGSN identifica el portador adecuado a partir del identificador de terminación de tunelado TEID.
- S36:
- El GGSN determina un portador que es el portador GTP a partir del TEID del ID de interfaz de la dirección compatible del UE, que es la dirección de destino del paquete de Internet. Por lo tanto, el tunelado se convierte en un procedimiento sustancialmente automático.
- S38:
- El GGSN transmite los paquetes de Internet al UE por medio del portador GTP y el portador RAB indicados por el TEID.
En las reivindicaciones adjuntas, se definen
otros aspectos y características diversas de la presente invención.
Es posible realizar diversas modificaciones a las formas de
realización descritas en la presente memoria, sin apartare, por
ello, del alcance de la presente invención. Por ejemplo, aunque las
anteriores formas de realización han sido descritas con referencia
a un primer protocolo de Internet, tal como el IPv6, y un segundo
protocolo de Internet (para la comunicación por medio de la red del
sistema de paquetes de radio), tal como el IPv4, en otras formas de
realización, el primer protocolo puede ser el protocolo IPv4 y el
segundo protocolo (para la comunicación por medio de la red del
sistema de paquetes de radio) puede ser el protocolo IPv6. Pueden
utilizarse además otros protocolos de Internet como primer y segundo
protocolo de Internet.
5. Anexo
1
Estos sistemas de direccionamiento se resumen en
mayor detalle en el documento RFC 3513 "Internet Protocol Version
6 (IPv6) Addressing Architecture".
Las direcciones IPv6 de unidifusión son
compatibles con los prefijos de longitud binaria arbitraria
similares a las direcciones IPv4 calificadas como "direcciones de
encaminamiento sin clases". Existen varios tipos de direcciones
de unidifusión en IPv6, en particular, las direcciones globales de
unidifusión, las direcciones de sitios locales de unidifusión y las
direcciones de enlaces locales de unidifusión. También existen
algunos subtipos de direcciones globales de unidifusión de uso
especial, tales como las direcciones IPv6 con tipos de direcciones
IPv4 integrados o direcciones NSAP codificadas. En el futuro, es
posible que se definan tipos o subtipos de direcciones
adicionales.
Los nodos IPv6 pueden tener un conocimiento
considerable o limitado de la estructura interna de la dirección
IPv6, dependiendo de la función desempeñada por el nodo (por
ejemplo, nodo propiamente dicho o encaminador). En el peor de los
casos, un nodo puede considerar que las direcciones de unidifusión
(incluida la propia) no presentan estructura interna, como se
ilustra en el ejemplo de la Figura 17. Un nodo ligeramente
perfeccionado (pero todavía bastante simple) puede tener
conocimiento además de los prefijos de subred para los enlaces a
los cuales está conectado, pudiendo presentar las diferentes
direcciones diferentes valores para los prefijos de subred que
ocupan los primeros n bits, como se representa en la Figura 18. La
dirección representada en la Figura 10 puede ser utilizada para
construir la dirección IPv6, denominada "dirección GAT", para
el tunelado automático. Los identificadores de interfaz de las
direcciones IPv6 de unidifusión se utilizan para identificar las
interfaces de un enlace. Es necesario que dichos identificadores
sean exclusivos dentro de un prefijo de subred.
Para todas las direcciones de unidifusión,
excepto las que empiezan por el valor binario 000 (las direcciones
que utilizan direcciones IPv4 integradas), es necesario que los ID
de las interfaces sean de 64 bits de longitud y que se hayan
construido con el formato EUI-64 modificado (IEEE,
"Guidelines for 64-bit Global Identifier
(EUI-64) Registration Authority"
http://standards.ieee.org/regauth/oui/tutorial/EUI64.html, marzo de
1997).
Los identificadores de interfaz basados en el
formato EUI-64 modificado pueden presentar un
alcance global cuando se obtienen a partir de un testigo global
(p.ej., una dirección MAC IEEE 802 de 48 bits o un identificador
IEEE EUI-64) o pueden presentar un alcance local
cuando no se dispone de un testigo global (por ejemplo, enlaces en
serie, puntos de terminación de túnel, etc.) o cuando los testigos
globales no son deseables (por ejemplo, testigos temporales para la
confidencialidad).
Los identificadores de interfaz de formato
EUI-64 modificado se generan invirtiendo el bit
"u" (bit universal/local en terminología IEEE
EUI-64) cuando se generan identificadores de
interfaz a partir de identificadores IEEE EUI-64.
En el formato EUI-64 modificado resultante, el bit
"u" se establece en "1" para indicar que el alcance es
global y se establece en "0" para indicar que el alcance es
local. En la Figura 19, se representan los tres primeros octetos en
binario de un identificador IEEE EUI-64. Como se
observa en la Figura 19, la dirección presenta campos escritos en
el orden de bits estándar de Internet, siendo "u" el bit
universal/local, "g" el bit individual/grupal y "c" los
bits de company_id. El documento RFC3513 comprende ejemplos de lo
anterior.
Cuando se carece de identificadores de interfaz
integrados específicos, tales como los enlaces en serie o los
túneles configurados (denominados "enlaces sin
identificadores"), es necesario elegir identificadores de
interfaz que sean exclusivos dentro de un prefijo de subred.
Cuando no se dispone de ningún identificador
integrado en un enlace, el sistema preferido consiste en utilizar un
identificador de interfaz global de otra interfaz o uno que ha sido
asignado al propio nodo.
Cuando no se dispone de ningún identificador de
interfaz global para ser utilizado en el enlace, es necesario crear
un identificador de interfaz de alcance local.
En la Figura 20, se representa un ejemplo de una
dirección IPv6 global de unidifusión.
Para facilitar la transición de IPv4 a IPv6, se
dispone de una técnica para que los nodos y los encaminadores
realicen el tunelado dinámico de paquetes IPv6 a través de una
infraestructura de encaminamiento IPv4. A los nodos IPv6 que
utilizan esta técnica se les asigna una dirección IPv6 de
unidifusión especial con una dirección IPv4 global integrada en los
32 bits de orden inferior. En la Figura 21, se representa un ejemplo
que puede describirse como una "dirección IPv6 compatible con
IPv4".
Existe otro tipo de dirección IPv4 denominada
"dirección IPv6 correlacionada con IPv4" que presenta un
formato de dirección como el ilustrado en la Figura 22, y que puede
utilizarse para representar los nodos IPv4 mediante direcciones
IPv6.
En las Figuras 23 y 24, se ilustran dos tipos de
direcciones de uso local, en particular, una dirección de sitio
local y una dirección de enlace local. Las direcciones de sitios
locales se diseñan para permitir el direccionamiento dentro de un
sitio sin necesidad de disponer de un prefijo global. El formato de
la dirección de sitio local se representa en la Figura 23.
Las direcciones de enlaces locales se diseñan
para permitir el direccionamiento dentro de un único enlace y
permitir la configuración automática de direcciones y la
autoconfiguración de nodos o para permitir el direccionamiento
cuando no se dispone de encaminadores. El formato de la dirección de
sitio local se representa en la Figura 24. Existen otros tipos de
direcciones, tales como las direcciones Anycast, las direcciones de
multidifusión, las direcciones de autodireccionamiento
(loop-back), etc.
6. Anexo
2
El tráfico IP (IPv6 o IPv4) se transporta a
través de la red UMTS (entre el UE y el GGSN) por medio de un
portador UMTS. El portador UMTS se describe como el establecimiento
del contexto PDP (Packet Data Control). El equipo de usuario UE
envía paquetes IPv4 o IPv6 a través de la red UMTS, estableciendo un
contexto PDP IPv4 o un contexto PDP IPv6. Los contextos PDP IPv6
sólo son admitidos en las redes UMTS con capacidad IPv6, en
particular, en los nodos SGSN y GGSN y también en los UE capaces de
admitir funciones relacionadas con IPv6 (encaminamiento, seguridad)
en su pila de protocolos de red.
Una red UMTS que sólo presenta capacidad IPv4
admite únicamente el contexto PDP IPv4, aunque no existe ninguna
diferencia explícita entre los procedimientos de establecimiento de
contexto PDP IPv4 y los procedimientos de establecimiento de
contexto PDP IPv6. En el sumario siguiente, se ilustran las
funciones de gestión y seguridad de las direcciones en la
activación de un contexto PDP haciendo referencia al diagrama de
flujo de la Figura 25. El diagrama de flujo de la Figura 25
representa de manera equivalente el IPv4 para un contexto PDP IPv4 y
el IPv6 para un contexto PDP IPv6 de un sistema UMTS con capacidad
IPv6.
- S90:
- El equipo de usuario UE envía un mensaje de petición de activación de contexto PDP (NSAPI, TI, tipo de PDP, dirección de PDP, nombre de punto de acceso, QoS (calidad de servicio) solicitado, opciones de configuración PDP) al SGSN. El equipo de usuario UE emplea una dirección PDP para indicar si desea utilizar una dirección PDP estática o utilizar una dirección PDP dinámica. El equipo de usuario UE deja la dirección PDP vacía para solicitar una dirección PDP dinámica.
- S92:
- El SGSN confirma la validez de la petición de activación de contexto PDP utilizando el tipo de PDP (opcional), la dirección de PDP (opcional) y el nombre de punto de acceso (opcional) aportados por el equipo de usuario UE y los registros de suscripción del contexto PDP.
Si no puede obtenerse ninguna dirección GGSN o
si el SGSN ha determinado que la petición de activación de contexto
PDP no es válida de acuerdo con las reglas, el SGSN rechaza la
petición de activación de contexto PDP.
Si puede obtenerse una dirección GGSN, el SGSN
crea un TEID para el contexto PDP solicitado. Si el equipo de
usuario UE solicita una dirección dinámica, el SGSN permite que un
GGSN asigne la dirección dinámica. El SGSN puede restringir los
atributos de QoS solicitados dependiendo de sus capacidades y la
carga actual, siendo aplicada dicha restricción de los atributos QoS
de acuerdo con el perfil de QoS suscrito.
El SGSN envía una petición de creación de
contexto PDP (tipo de PDP, dirección de PDP, nombre de punto de
acceso, QoS negociado, TEID, NSAPI, MSISDN, modalidad de selección,
características de cargo, referencia de traza, tipo de traza, ID de
disparador, identidad de OMC, opciones de configuración de PDP) al
GGSN afectado. La dirección PDP se deja en blanco cuando se solicita
una dirección dinámica.
- S94:
- El GGSN crea una nueva entrada en su tabla de contexto PDP y genera un ID de cargo. La nueva entrada permite al GGSN encaminar las PDU PDP entre el SGSN y la red PDP externa, e iniciar los cargos. En la norma 3G TS 32.015 [4], se define cómo el GGSN se encarga de las características de cargo que habrá recibido desde el SGSN. Entonces, el GGSN presenta un mensaje de respuesta de creación de contexto PDP (TEID, dirección de PDP, opciones de configuración de PDP, QoS negociado, ID de cargo y causa) al SGSN. La dirección de PDP se especifica si el GGSN ha asignado una dirección PDP. Si el operador ha configurado el GGSN para utilizar la asignación de direcciones de la PDN externa para el APN solicitado, la dirección PDP deberá establecerse en el valor 0.0.0.0 que indica que la dirección PDP será negociada por el equipo de usuario UE con la PDN externa, una vez terminado el procedimiento de activación de contexto PDP. El GGSN retransmitirá, modificará y supervisará estas negociaciones, siempre y cuando el contexto PDP se halle en el estado ACTIVO, y utilizará el procedimiento de modificación de contexto PDP iniciado por el GGSN para transferir la dirección de PDP utilizada actualmente al SGSN y al equipo de usuario UE. Las opciones de configuración PDP contienen parámetros PDP opcionales que el GGSN puede transferir al equipo de usuario UE. Estos parámetros PDP opcionales pueden ser solicitados por el equipo de usuario UE en el mensaje de petición de activación de contexto PDP, o pueden ser enviados por el GGSN sin haber sido solicitados. Las opciones de configuración PDP se envían de forma transparente a través del SGSN. Los mensajes de creación de contexto PDP se envían a través de la red troncal.
- S96:
- Se establece un portador de acceso radio de acuerdo con la activación de PDP, que incluye la negociación de QoS. A continuación, la petición de contexto PDP se actualiza (S97) del SGSN al GGSN, y el GGSN responde a la actualización (S98).
- S99:
- Si el equipo de usuario UE ha solicitado una dirección dinámica, la dirección PDP recibida desde el GGSN se inserta en el contexto PDP. El SGSN selecciona la prioridad radio y el ID de flujo de paquetes basándose en el QoS negociado, y presenta un mensaje de aceptación de activación de contexto PDP (tipo de PDP, dirección de PDP, TI, QoS negociado, prioridad radio, Id de flujo de paquetes, opciones de configuración de PDP) al equipo de usuario UE. Entonces, el SGSN es capaz de encaminar las PDU PDP entre el GGSN y el equipo de usuario UE y empezar los cargos. El identificador NSAPI (junto con el TI) se utiliza para diferenciar entre contextos PDP secundarios.
[1] RFC 2893
[2] RFC2766 que utiliza SIIT(RFC
2765)
[3] R. Steele, C-C Lee and P.
Gould, "GSM, cdmaOne and 3G Systems", publicado por Wiley
International ISBN 0 471 491853
[4] 3G TS 32.015
[5] 3GPP TS 26.202 V5.1.0
(2002-09)
[6] 3GPP TS 23.107
[7] RFC2461 Neighbor Discovery for IP Versión 6
(IPv6), diciembre 1998
[8] RFC 3513 Internet Protocol Version 6 (IPv6)
Addressing Architecture, abril 2003
[9] RFC3315 Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)
[10] RFC3633 IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) versión 6.
[11] RFC2460 Internet Protocol, Versión 6 (IPv6)
Specifications.
Claims (30)
1. Sistema de telecomunicaciones para transmitir
datos de paquetes de Internet según un primer protocolo de Internet,
por medio de una red de radiocomunicaciones por paquetes (1) que
funciona sólo de acuerdo con un segundo protocolo de Internet,
comprendiendo el sistema:
un equipo de usuario (2) que puede funcionar
para solicitar un portador para transmitir datos de protocolo de
Internet según el segundo protocolo de Internet, hasta y desde un
nodo de soporte de pasarela (3) de la red de radiocomunicaciones por
paquetes (1);
pudiendo funcionar el nodo de soporte de
pasarela (3) para establecer un portador de protocolo de
tunelización (14) para transmitir los datos de paquetes de Internet
hasta y desde el equipo de usuario (2) a través de la red de
radiocomunicaciones por paquetes (1), y pudiendo funcionar el equipo
de usuario (2), en combinación con el nodo de soporte de pasarela
(3), para;
generar una dirección que es compatible con el
primer protocolo de Internet, presentando la dirección un componente
de identificador de interfaz que comprende un identificador de
terminación de túnel del portador de protocolo de tunelización (14)
que termina en el nodo de soporte de pasarela (3) de la red de
radiocomunicaciones por paquetes (1); y
transmitir datos de paquetes de Internet desde y
hasta un nodo correspondiente por medio del nodo de soporte de
pasarela (3) y el portador establecido (14), utilizando la dirección
de protocolo de Internet que es compatible con el primer protocolo
de Internet.
2. Sistema de telecomunicaciones según la
reivindicación 1, en el que el nodo de soporte de pasarela está
dispuesto para identificar el portador para transmitir los datos de
paquetes de Internet desde el nodo correspondiente hasta el equipo
de usuario por medio de la red de datos por paquetes, utilizando el
identificador de terminación de túnel.
3. Sistema de telecomunicaciones según la
reivindicación 1 ó 2, en el que el identificador de interfaz de la
dirección compatible generada por el equipo de usuario en
combinación con el nodo de soporte de pasarela comprende un
identificador de empresa que indica un operador de la red de datos
por paquetes.
4. Sistema de telecomunicaciones según la
reivindicación 1 ó 2, en el que el identificador de interfaz de la
dirección compatible generada por el equipo de usuario en
combinación con el nodo de soporte de pasarela comprende una
dirección de protocolo de Internet según el segundo protocolo de
Internet.
5. Sistema de telecomunicaciones según
cualquiera de las reivindicaciones anteriores, en el que el nodo de
soporte de pasarela puede funcionar para generar la dirección de
protocolo de Internet que es compatible con el primer protocolo de
Internet del nodo de soporte de pasarela, utilizando el
identificador de terminación de túnel, y para transmitir la
dirección de protocolo de Internet al equipo de usuario.
6. Sistema de telecomunicaciones según
cualquiera de las reivindicaciones 1 a 4, en el que el nodo de
soporte de pasarela puede funcionar para:
transmitir al equipo de usuario información que
indica el portador asignado, los datos de dirección, los datos de
dirección que incluyen el identificador de terminación de túnel del
portador de protocolo de tunelización, pudiendo funcionar el equipo
para
generar la dirección de protocolo de Internet
compatible utilizando el identificador de terminación de túnel
suministrado al equipo de usuario como parte de los datos de
dirección.
7. Sistema de telecomunicaciones según la
reivindicación 6, en el que los datos de dirección comprenden una de
entre la dirección del segundo protocolo de Internet, el
identificador de empresa, pudiendo funcionar el equipo de usuario
para generar la dirección compatible con el primer protocolo de
Internet a partir de la dirección del segundo protocolo de Internet
o el identificador de empresa en combinación con el identificador de
terminación de túnel.
8. Sistema de telecomunicaciones según la
reivindicación 6 ó 7, en el que el nodo de soporte de pasarela puede
funcionar para suministrar los datos de dirección como parte de una
petición de activación de contexto de protocolo de datos de
paquetes, comprendiendo los datos de dirección una dirección de
protocolo de Internet según el segundo protocolo de Internet, y
pudiendo funcionar el equipo de usuario para generar la dirección
compatible con el primer protocolo de Internet a partir de la
dirección de protocolo de Internet según el segundo protocolo de
Internet y el identificador de terminación de tunelado.
9. Sistema de telecomunicaciones según la
reivindicación 8, en el que el nodo de soporte de pasarela puede
funcionar para suministrar los datos de dirección que comprenden el
identificador de terminación de túnel, utilizando un campo de opción
de configuración de protocolo de aceptación de contexto de protocolo
de datos de paquetes.
10. Sistema de telecomunicaciones según
cualquiera de las reivindicaciones anteriores, en el que el portador
para transmitir los datos de paquetes de Internet comprende un
portador de acceso radio, siendo transmitidos los datos de paquetes
de Internet de acuerdo con un túnel de portador de acceso radio, y
un portador de protocolo de túnel de red de radiocomunicaciones por
paquetes.
11. Sistema de telecomunicaciones según
cualquiera de las reivindicaciones anteriores, en el que la red de
radiocomunicaciones por paquetes funciona de acuerdo con el Sistema
General de Radiocomunicaciones por Paquetes.
12. Sistema de telecomunicaciones según
cualquiera de las reivindicaciones anteriores, en el que el nodo de
soporte de pasarela puede funcionar en combinación con el equipo de
usuario para generar la dirección compatible, suministrando un
prefijo correspondiente a una dirección según el primer protocolo de
Internet con el identificador de terminación de túnel.
13. Sistema de telecomunicaciones según la
reivindicación 12, en el que el prefijo se suministra al equipo de
usuario, siendo generada la dirección compatible en el equipo del
usuario.
14. Sistema de telecomunicaciones según la
reivindicación 12, en el que el prefijo es obtenido por el nodo de
soporte de pasarela, siendo generada la dirección compatible en el
equipo de usuario o el nodo de soporte de pasarela.
15. Procedimiento para transmitir datos de
paquetes de Internet de acuerdo con un primer protocolo de Internet
hasta y desde un equipo de usuario (2) por medio de una red de
radiocomunicaciones por paquetes (1) que puede funcionar sólo de
acuerdo con un segundo protocolo de Internet, comprendiendo la red
de radiocomunicaciones por paquetes (1) una parte de red central
(CN) y una parte de red de radiocomunicaciones (RN), comprendiendo
el procedimiento las etapas siguientes:
pedir un portador (14) para transmitir datos de
protocolo de Internet según el segundo protocolo de Internet, entre
un nodo de soporte de pasarela (3) de la red de radiocomunicaciones
por paquetes (1) y el equipo de usuario (2);
generar una dirección que sea compatible con el
primer protocolo de Internet, presentando la dirección un componente
de identificador de interfaz que comprende un identificador de
terminación de túnel de un portador de protocolo de tunelización
(14) que termina en un nodo de soporte de pasarela (3) de la parte
de red central (CN) de la red de radiocomunicaciones por paquetes
(1); y
transmitir datos de paquetes de Internet hasta y
desde un nodo correspondiente (12) por medio del nodo de soporte de
pasarela (3), utilizando la dirección de protocolo de Internet que
es compatible con el primer protocolo.
16. Procedimiento de transmisión según la
reivindicación 15, en el que la etapa de transmisión de datos de
paquetes de Internet hasta y desde el nodo correspondiente
comprende:
identificar al portador para transmitir los
datos de paquetes de Internet desde el nodo correspondiente al
equipo de usuario por medio de la red de datos por paquetes,
utilizando el identificador de terminación de túnel.
17. Procedimiento de transmisión de datos de
paquetes de Internet según la reivindicación 15 ó 16, en el que la
etapa de generación de la dirección del protocolo de Internet
comprende:
generar el identificador de interfaz de la
dirección de protocolo de Internet compatible a partir del
identificador de terminación de túnel en combinación con un
identificador de empresa que indica el operador de la red de datos
por paquetes.
18. Procedimiento de transmisión de datos de
paquetes de Internet según la reivindicación 15 ó 16, en el que la
generación de la dirección del protocolo de Internet comprende:
generar el identificador de interfaz de la
dirección de protocolo de Internet compatible a partir del
identificador de terminación de túnel en combinación con una
dirección de protocolo de Internet según el segundo protocolo de
Internet.
19. Procedimiento de transmisión de datos de
paquetes de Internet según cualquiera de las reivindicaciones 15 a
18, en el que la generación de la dirección de protocolo de Internet
comprende:
generar la dirección que es compatible con el
primer protocolo de Internet en el nodo de soporte de pasarela,
utilizando el identificador de terminación de túnel y
transmitir la dirección de protocolo de Internet
al equipo de usuario.
20. Procedimiento de transmisión de datos de
paquetes de Internet según cualquiera de las reivindicaciones 15 a
18, en el que la generación de la dirección de protocolo de Internet
comprende:
\newpage
transmitir al equipo de usuario información que
indica el portador asignado, los datos de dirección y los datos de
dirección que comprenden el identificador de terminación de túnel
del portador del protocolo de tunelización,
transmitir los datos de dirección al equipo de
usuario, siendo generada la dirección de protocolo de Internet
compatible utilizando el identificador de terminación de túnel en el
equipo de usuario.
21. Procedimiento según la reivindicación 20, en
el que los datos de dirección comprenden un elemento de entre una
dirección del segundo protocolo de Internet y el identificador de
empresa, incluyendo los datos de dirección una dirección de
protocolo de internet según el segundo protocolo de internet,
comprendiendo la formación de la dirección compatible con el primer
protocolo de internet:
generar la dirección compatible con el primer
protocolo de Internet, de entre la dirección del protocolo de
Internet según el segundo protocolo de Internet o el identificador
de empresa y el identificador de terminación de tunelado.
22. Procedimiento según la reivindicación 19 ó
20, en el que la transmisión de los datos de dirección
comprende:
proporcionar los datos de dirección como parte
de una petición de activación de contexto de protocolo de datos de
paquetes.
23. Procedimiento según la reivindicación 22, en
el que el hecho de proporcionar los datos de dirección como parte de
la petición de activación de contexto de protocolo de datos de
paquetes comprende:
proporcionar los datos de dirección que
comprenden el identificador de terminación de túnel, utilizando un
campo de opción de configuración de protocolo de la aceptación de
contexto de protocolo de datos de paquetes.
24. Procedimiento según cualquiera de las
reivindicaciones 15 a 23, en el que la red de radiocomunicaciones
por paquetes funciona de acuerdo con el Sistema General de
Radiocomunicaciones por Paquetes.
25. Procedimiento según cualquiera de las
reivindicaciones 15 a 24, que comprende:
proporcionar un prefijo correspondiente a una
dirección según el primer protocolo de Internet, y
generar la dirección compatible a partir del
prefijo y el ID de interfaz que comprende el identificador de
terminación de túnel.
26. Procedimiento según la reivindicación 25, en
el que el prefijo se suministra al equipo de usuario, siendo
generada la dirección compatible en el equipo de usuario.
27. Procedimiento según la reivindicación 25, en
el que el prefijo es obtenido por el nodo de soporte de
pasarela.
28. Programa informático que una vez cargado en
un procesador de datos determina que el procesador de datos ejecute
un procedimiento según cualquiera de las reivindicaciones 15 a
27.
29. Medios que contienen el programa informático
según la reivindicación 28.
30. Aparato para transmitir datos de paquetes de
Internet según un primer protocolo de Internet hasta y desde un
equipo de usuario (2), por medio de una red de radiocomunicaciones
por paquetes (1) que puede funcionar sólo de acuerdo con un segundo
protocolo de Internet, comprendiendo la red de radiocomunicaciones
por paquetes (1) una parte de red central (CN) y una parte de red de
radiocomunicaciones (RN), comprendiendo el aparato:
unos medios para solicitar un portador (14) para
transmitir datos de protocolo de Internet según el segundo protocolo
de Internet entre un nodo de soporte de pasarela (3) de la red de
radiocomunicaciones por paquetes (1) y el equipo de usuario (2);
unos medios para generar una dirección que sea
compatible con el primer protocolo de Internet, presentando la
dirección un componente de identificador de interfaz que comprende
un identificador de terminación de túnel del portador de protocolo
de tunelización (14) que termina en un nodo de soporte de pasarela
(3) de la parte de red central (CN) de la red de radiocomunicaciones
por paquetes (1), y
unos medios para transmitir datos de paquetes de
Internet hasta y desde un nodo correspondiente (12) por medio del
nodo de soporte de pasarela (3), utilizando la dirección de
protocolo de Internet que es compatible con el primer protocolo.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0417097 | 2004-07-30 | ||
| GB0417097A GB2417650A (en) | 2004-07-30 | 2004-07-30 | Tunnelling IPv6 packets over IPv4 packet radio network wherein an IPv6 address including a tunnel end identifier of the IPv4 bearer is formed |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2299050T3 true ES2299050T3 (es) | 2008-05-16 |
Family
ID=32947770
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES05759502T Active ES2299050T3 (es) | 2004-07-30 | 2005-07-11 | Sistema y procedimiento para transmitir datos de paquetes de internet mediante redes de radiocomunicaciones por paquetes. |
Country Status (8)
| Country | Link |
|---|---|
| US (3) | US8179888B2 (es) |
| EP (1) | EP1772030B1 (es) |
| CN (1) | CN101019450B (es) |
| AT (1) | ATE383718T1 (es) |
| DE (1) | DE602005004291T2 (es) |
| ES (1) | ES2299050T3 (es) |
| GB (1) | GB2417650A (es) |
| WO (1) | WO2006010883A1 (es) |
Families Citing this family (40)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007027958A1 (en) * | 2005-08-29 | 2007-03-08 | Junaid Islam | ARCHITECTURE FOR MOBILE IPv6 APPLICATIONS OVER IPv4 |
| WO2007096884A2 (en) | 2006-02-22 | 2007-08-30 | Elad Barkan | Wireless internet system and method |
| US8265073B2 (en) * | 2006-10-10 | 2012-09-11 | Comcast Cable Holdings, Llc. | Method and system which enables subscribers to select videos from websites for on-demand delivery to subscriber televisions via a television network |
| CN101374097B (zh) * | 2007-08-23 | 2010-09-15 | 上海贝尔阿尔卡特股份有限公司 | 控制通信网络中移动节点与异类网络通信的方法及装置 |
| WO2009039318A1 (en) * | 2007-09-18 | 2009-03-26 | Kineto Wireless, Inc. | Method and system for supporting large number of data paths in an integrated communication system |
| JP5088100B2 (ja) * | 2007-11-08 | 2012-12-05 | 日本電気株式会社 | Ｉｐネットワークシステム、そのアクセス制御方法、ｉｐアドレス配布装置、及びｉｐアドレス配布方法 |
| US8902805B2 (en) * | 2008-10-24 | 2014-12-02 | Qualcomm Incorporated | Cell relay packet routing |
| US20100208194A1 (en) * | 2009-02-13 | 2010-08-19 | Amitava Gupta | Variable focus liquid filled lens apparatus |
| US8087778B2 (en) * | 2009-02-13 | 2012-01-03 | Adlens Beacon, Inc. | Variable focus liquid filled lens mechanism |
| US8719337B1 (en) * | 2009-04-27 | 2014-05-06 | Junaid Islam | IPv6 to web architecture |
| US8414121B2 (en) * | 2009-10-13 | 2013-04-09 | Adlens Beacon, Inc. | Non-round fluid filled lens optic |
| US8136942B2 (en) * | 2009-10-14 | 2012-03-20 | Adlens Beacon, Inc. | Aspheric fluid filled lens optic |
| US8596781B2 (en) * | 2009-10-15 | 2013-12-03 | Adlens Beacon, Inc. | Fluid filled lens reservoir system and manufacturing method of the reservoir system |
| US8549117B2 (en) * | 2009-11-05 | 2013-10-01 | Telefonaktiebolaget L M Ericsson (Publ) | Method for address translator traversal in 3GPP networks |
| JP2012034353A (ja) * | 2010-06-28 | 2012-02-16 | Panasonic Corp | ネットワーク通信装置、通信方法および集積回路 |
| US9021108B2 (en) * | 2010-09-27 | 2015-04-28 | Blackberry Limited | Method, system and apparatus for enabling access of a first mobile electronic device to at least one network accessible by a second mobile electronic device |
| PT2628033T (pt) | 2010-10-11 | 2019-04-08 | Adlens Beacon Inc | Reservatório piezoelétrico perimétrico numa lente |
| PT2638417T (pt) | 2010-11-10 | 2017-07-27 | Adlens Beacon Inc | Lentes cheias de fluido e seus sistemas de acionamento |
| CN102892109B (zh) * | 2011-07-21 | 2018-05-11 | 中兴通讯股份有限公司 | 一种实现ip地址属性通知的方法和系统 |
| US9008093B2 (en) | 2012-03-12 | 2015-04-14 | Comcast Cable Communications, Llc | Stateless protocol translation |
| US9535264B2 (en) | 2012-07-13 | 2017-01-03 | Adlens Beacon, Inc. | Fluid lenses, lens blanks, and methods of manufacturing the same |
| JP6164219B2 (ja) * | 2012-09-27 | 2017-07-19 | 日本電気株式会社 | 移動通信システム、制御装置、通信制御方法、及びプログラム |
| EP2910079A1 (en) * | 2012-10-18 | 2015-08-26 | Nokia Solutions and Networks Oy | Intelligent bearer setup configuration control |
| CN104040987B (zh) * | 2012-12-27 | 2017-05-24 | 华为技术有限公司 | 用户面数据传输方法、移动管理网元、演进型基站及系统 |
| CN103179555B (zh) * | 2013-03-22 | 2015-05-06 | 北京优联实科信息科技有限公司 | 3GPP网络中的IPv6地址分配方法 |
| US20160156753A1 (en) * | 2013-04-30 | 2016-06-02 | Nokia Solutions And Networks Oy | Enhanced gprs tunnel protocol tunnel endpoint identifier |
| US9112790B2 (en) | 2013-06-25 | 2015-08-18 | Google Inc. | Fabric network |
| WO2015085521A1 (zh) * | 2013-12-11 | 2015-06-18 | 华为技术有限公司 | 互联网协议地址分配方法和装置 |
| CN103716837B (zh) * | 2013-12-17 | 2017-01-25 | 北京创毅视讯科技有限公司 | 一种选择承载的方法和lte基站 |
| US9614963B2 (en) | 2014-03-26 | 2017-04-04 | Rockwell Automation Technologies, Inc. | Cloud-based global alarm annunciation system for industrial systems |
| US9838476B2 (en) * | 2014-03-26 | 2017-12-05 | Rockwell Automation Technologies, Inc. | On-premise data collection and ingestion using industrial cloud agents |
| US10764255B2 (en) | 2016-09-21 | 2020-09-01 | Rockwell Automation Technologies, Inc. | Secure command execution from a cloud monitoring system to a remote cloud agent |
| US11327473B2 (en) | 2017-07-11 | 2022-05-10 | Rockwell Automation Technologies, Inc. | Dynamically reconfigurable data collection agent for fracking pump asset |
| EP4362434A2 (en) * | 2017-08-11 | 2024-05-01 | Huawei Technologies Co., Ltd. | Pdu type setting method, ue policy setting method, and related entity |
| US10482063B2 (en) | 2017-08-14 | 2019-11-19 | Rockwell Automation Technologies, Inc. | Modular control manifest generator for cloud automation |
| US10416660B2 (en) | 2017-08-31 | 2019-09-17 | Rockwell Automation Technologies, Inc. | Discrete manufacturing hybrid cloud solution architecture |
| US11463399B2 (en) * | 2018-12-15 | 2022-10-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Efficient network address translation (NAT) in cloud networks |
| CN113691643A (zh) * | 2020-12-11 | 2021-11-23 | 浙江十进制网络有限公司 | 一种数据包传输转换方法、互联网络、数据包处理设备 |
| US11870876B2 (en) * | 2021-04-29 | 2024-01-09 | Arris Enterprises Llc | Enhanced DOCSIS packet classification for tunneled traffic having IPV4 and IPV6 rules mixed in a single upstream (US) and/or downstream (DS) traffic classifier |
| US11785658B2 (en) * | 2021-06-24 | 2023-10-10 | Mediatek Inc. | Method and apparatus for performing internet reachability management with aid of indicator |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE60039995D1 (de) * | 1999-09-24 | 2008-10-02 | British Telecomm | Paketnetz-schnittstelle |
| US6708219B1 (en) * | 1999-10-26 | 2004-03-16 | 3Com Corporation | Method and system for dual-network address utilization |
| FI109950B (fi) | 2000-01-20 | 2002-10-31 | Nokia Corp | Osoitteen saanti |
| US7327683B2 (en) * | 2000-03-16 | 2008-02-05 | Sri International | Method and apparatus for disseminating topology information and for discovering new neighboring nodes |
| US20010040895A1 (en) * | 2000-03-16 | 2001-11-15 | Templin Fred Lambert | An IPv6-IPv4 compatibility aggregatable global unicast address format for incremental deployment of IPv6 nodes within IPv4 |
| JP3805255B2 (ja) * | 2000-05-31 | 2006-08-02 | ノキア コーポレイション | 接続の識別を発生する方法及び装置 |
| US7054945B2 (en) | 2001-04-09 | 2006-05-30 | Nokia Corporation | Technique for providing announcements in mobile-originated calls |
| DE60223264T2 (de) * | 2001-08-29 | 2008-08-14 | Research In Motion Ltd., Waterloo | System und verfahren zur adressierung eines mobilen gerätes in einem ip-basierten drahtlosen netzwerk |
| KR100438430B1 (ko) | 2002-01-24 | 2004-07-03 | 삼성전자주식회사 | 이동통신시스템에서 트래픽 플로우 탬플릿 재정렬 장치 및방법 |
| CA2393547A1 (en) * | 2002-07-15 | 2004-01-15 | Hexago Inc. | Method and apparatus for connecting ipv6 devices through an ipv4 network using a tunneling protocol |
| EP1420559A1 (en) * | 2002-11-13 | 2004-05-19 | Thomson Licensing S.A. | Method and device for supporting a 6to4 tunneling protocol across a network address translation mechanism |
| CA2507529C (en) * | 2002-11-27 | 2011-03-08 | Research In Motion Limited | Data transfer from a host server via a tunnel server to a wireless device, and associating a temporary ipv6 address with a temporary ipv4 address for communicating in an ipv4 wireless network with the device |
| US7554991B2 (en) * | 2003-06-27 | 2009-06-30 | Nokia Corporation | Method, system and network element for data transmission using a transition mechanism |
| GB2413464A (en) | 2004-04-21 | 2005-10-26 | Orange Sa | An inter-working unit with a protocol conversion or protocol encapsulation function, for use with dual stack user equipment on a packet radio network |
-
2004
- 2004-07-30 GB GB0417097A patent/GB2417650A/en not_active Withdrawn
-
2005
- 2005-07-11 WO PCT/GB2005/002716 patent/WO2006010883A1/en active Application Filing
- 2005-07-11 EP EP05759502A patent/EP1772030B1/en active Active
- 2005-07-11 ES ES05759502T patent/ES2299050T3/es active Active
- 2005-07-11 CN CN2005800258811A patent/CN101019450B/zh active Active
- 2005-07-11 AT AT05759502T patent/ATE383718T1/de not_active IP Right Cessation
- 2005-07-11 US US11/658,827 patent/US8179888B2/en active Active
- 2005-07-11 DE DE602005004291T patent/DE602005004291T2/de active Active
-
2012
- 2012-05-04 US US13/464,782 patent/US9237058B2/en active Active
-
2015
- 2015-12-09 US US14/964,400 patent/US10200511B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US20120213216A1 (en) | 2012-08-23 |
| EP1772030A1 (en) | 2007-04-11 |
| US10200511B2 (en) | 2019-02-05 |
| ATE383718T1 (de) | 2008-01-15 |
| US9237058B2 (en) | 2016-01-12 |
| US20160094685A1 (en) | 2016-03-31 |
| US8179888B2 (en) | 2012-05-15 |
| GB2417650A (en) | 2006-03-01 |
| DE602005004291D1 (de) | 2008-02-21 |
| CN101019450A (zh) | 2007-08-15 |
| CN101019450B (zh) | 2010-12-01 |
| GB0417097D0 (en) | 2004-09-01 |
| US20090052409A1 (en) | 2009-02-26 |
| EP1772030B1 (en) | 2008-01-09 |
| WO2006010883A1 (en) | 2006-02-02 |
| DE602005004291T2 (de) | 2008-12-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2299050T3 (es) | Sistema y procedimiento para transmitir datos de paquetes de internet mediante redes de radiocomunicaciones por paquetes. | |
| ES2310358T3 (es) | Tunelizacion de paquetes de protocolo de internet entre un nodo de soporte de pasarela y un terminal movil. | |
| US20210250767A1 (en) | Systems and methods for accessing a network | |
| US9743437B2 (en) | Mobile communication system | |
| ES2333801T3 (es) | Sistema de telecomunicaciones. | |
| ES2329956T3 (es) | Seleccion de multiples proveedores de servicio de internet por abonados de gprs. | |
| JP4938834B2 (ja) | アドレス取得 | |
| US8824430B2 (en) | Wireless mobility gateway | |
| JP4970422B2 (ja) | パケット無線ネットワーク及び通信方法 | |
| EP1560378B1 (en) | Wireless mobility gateway | |
| US7554991B2 (en) | Method, system and network element for data transmission using a transition mechanism | |
| JP2004266310A (ja) | Ｗｌａｎ相互接続におけるサービス及びアドレス管理方法 | |
| KR20040039450A (ko) | 네트워크 노드들간의 주소 변환 및 메시지 상관 | |
| JP2008535301A (ja) | パケット無線ネットワーク及び通信方法 | |
| WO2013071819A1 (zh) | 实现身份位置分离、分配接口标识的方法及网元和ue | |
| US8788826B1 (en) | Method and apparatus for dynamically allocating a mobile network prefix to a mobile terminal | |
| WO2021027858A1 (zh) | Rlc信道确定方法和装置 | |
| ES2276889T3 (es) | Metodo y sistema para la itinerancia entre redes de comunicaciones. | |
| KR100636267B1 (ko) | Ｕｍｔｓ 네트워크에서의 ｇｔｐ 터널 관리 방법 | |
| KR20090072574A (ko) | 단말의 주소 자동 설정 방법 및 그를 이용한 인터넷 사용차단 방법 |