ES2310358T3 - Tunelizacion de paquetes de protocolo de internet entre un nodo de soporte de pasarela y un terminal movil. - Google Patents
Tunelizacion de paquetes de protocolo de internet entre un nodo de soporte de pasarela y un terminal movil. Download PDFInfo
- Publication number
- ES2310358T3 ES2310358T3 ES05752109T ES05752109T ES2310358T3 ES 2310358 T3 ES2310358 T3 ES 2310358T3 ES 05752109 T ES05752109 T ES 05752109T ES 05752109 T ES05752109 T ES 05752109T ES 2310358 T3 ES2310358 T3 ES 2310358T3
- 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
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/26—Network addressing or numbering for mobility support
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- 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
- 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
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5007—Internet protocol [IP] addresses
- H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
-
- 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/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/08—Mobility data transfer
- H04W8/085—Mobility data transfer involving hierarchical organized mobility servers, e.g. hierarchical mobile IP [HMIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
- H04W80/045—Network layer protocols, e.g. mobile IP [Internet Protocol] involving different protocol versions, e.g. MIPv4 and MIPv6
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/04—Large scale networks; Deep hierarchical networks
-
- 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
- H04W92/00—Interfaces specially adapted for wireless communication networks
- H04W92/02—Inter-networking arrangements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
Abstract
Sistema de telecomunicaciones para comunicar datos por paquetes de internet según un primer protocolo de internet a través de una red de radiocomunicaciones por paquetes (1) que se puede hacer funcionar de acuerdo con un segundo protocolo de internet, comprendiendo el sistema un equipo de usuario (2) que se puede hacer funcionar para solicitar un portador con vistas a comunicar datos de protocolo de internet de acuerdo con el segundo protocolo de internet hacia y desde un nodo de soporte de pasarela (3) de la red de radiocomunicaciones por paquetes, pudiéndose hacer funcionar el nodo de soporte de pasarela (3) para establecer un portador de protocolo de tunelización con vistas a comunicar los datos por paquetes de internet hacia y desde el equipo de usuario (2) a través de la red de radiocomunicaciones por paquetes (1), en el que el equipo de usuario (2) se puede hacer funcionar en combinación con el nodo de soporte de pasarela (3) para formar una dirección local de enlace que comprende un identificador de interfaz que incluye un identificador de extremo de tunelización del portador de protocolo de tunelización que finaliza en el nodo de soporte de pasarela de la parte de red central de la red de radiocomunicaciones por paquetes, un componente de dirección que identifica la dirección como local para la red de radiocomunicaciones por paquetes según el primer protocolo de internet, para comunicar una solicitud de una dirección de protocolo de internet según el primer protocolo de internet a un servidor de asignación de direcciones (7) usando la dirección local de enlace, para recibir una dirección de protocolo de internet asignada, según el primer protocolo de internet, y para comunicarse usando la dirección de protocolo de internet asignada, en el que el equipo de usuario se puede hacer funcionar para informar al nodo de soporte de pasarela de que los datos por paquetes de internet se van a comunicar usando la dirección asignada, estando las direcciones de origen y de destino de los datos por paquetes de internet en concordancia con el primer protocolo de internet, pudiéndose hacer funcionar el nodo de soporte de pasarela para adaptar una plantilla de flujo de tráfico de manera que identifique el portador establecido, a partir de una dirección de origen que está en concordancia con el primer protocolo de internet.
Description
Tunelización de paquetes de protocolo de
internet entre un nodo de soporte de pasarela y un terminal
móvil.
La presente invención se refiere a un sistema y
a métodos para comunicar datos por paquetes de internet a través de
redes de radiocomunicaciones por paquetes, tales como, por ejemplo,
una red que funcione según el Servicio General de
Radiocomunicaciones por Paquetes (GPRS).
El GPRS se ha desarrollado para comunicar
paquetes de internet a través de una interfaz de acceso de
radiocomunicaciones. Una red GPRS se puede formar usando una red
troncal del Sistema Global para Móviles (GSM) o del Sistema de
Telecomunicaciones Móviles Universales (UMTS). El GPRS proporciona
soporte para servicios orientados a paquetes e intenta optimizar
recursos de las redes y de radiocomunicaciones para comunicaciones
de datos por paquetes tales como, por ejemplo, el Protocolo de
Internet (IP). El GPRS proporciona una arquitectura lógica, la cual
está relacionada con la arquitectura por conmutación de circuitos de
un sistema de radiocomunicaciones móviles.
El Grupo de Trabajo de Ingeniería de Internet
(IETF) es un organismo que es responsable del desarrollo de
protocolos de internet para facilitar comunicaciones a través de
internet. Por ejemplo, uno de los protocolos de internet bien
establecidos es el protocolo de internet versión 4 (IPv4) que se ha
desarrollado y normalizado para que los ordenadores personales
accedan a internet. El IETF ha desarrollado también otra norma
conocida como protocolo de internet versión 6 (IPv6) que proporciona
una mejora con respecto al IPv4 en el sentido de facilitar
comunicaciones móviles y opciones de direccionamiento incrementadas
para equipos de usuario. Aunque entre el IPv4 y el IPv6 existen
similitudes, una red de radiocomunicaciones por paquetes que se haya
establecido para soportar el IPv4 esperará paquetes de internet
según el IPv4 y no el IPv6.
La solicitud de patente internacional
WO-A-2004/049668 da a conocer un
sistema para enviar "información no solicitada (push)"
desde entidades de redes IPv4 hacia dispositivos inalámbricos que
tienen una dirección IPv6 permanente aunque están funcionando en una
red inalámbrica IPv4. Una "red de servicio" IPv6 intermedia
proporciona un punto de entrada para entidades de redes IPv4 con
vistas a establecer una conexión con el dispositivo de
comunicaciones inalámbricas IPv6, y un módulo de fondo (back
end) que controla la conexión entre el dispositivo de
comunicaciones inalámbricas IPv6 que funciona en una red inalámbrica
IPv4. La red de servicio IPv6 proporciona una funcionalidad de
tunelización y encaminamiento, de manera que se soportan conexiones
entre dispositivos IPv6 inalámbricos y redes IPv4 externas.
La solicitud de patente internacional
WO-A-03/109973 da a conocer un
esquema que permite el envío de información no solicitada hacia un
dispositivo de comunicaciones inalámbricas en una red inalámbrica
usando una dirección IPv6 para establecer la conexión. La ventaja
mencionada del esquema es que, si una red inalámbrica existente
implementa el IPv6 como mecanismo de direccionamiento, los
proveedores de servicios con envío de información no solicitada no
necesitarán cambiar ni eliminar ningún equipo o sistema para seguir
siendo compatibles. El esquema da a conocer un "proxy de envío de
información no solicitada (push proxy)" que arbitra entre
dispositivos inalámbricos IPv6 en las redes inalámbricas y
proveedores de servicios con envío de información no solicitada que
usan el direccionamiento IPv6. Una vez que se han resuelto las
cuestiones de direccionamiento y encaminamiento, a continuación el
esquema permite el establecimiento de conexiones por túneles basados
en IPv4.
Según la presente invención, se proporciona un
sistema de telecomunicaciones para comunicar datos por paquetes de
internet según un primer protocolo de internet (IPv6) a través de
una red de radiocomunicaciones por paquetes que puede funcionar de
acuerdo con un segundo protocolo de internet (IPv4). El sistema
comprende un equipo de usuario que puede funcionar para solicitar
un portador con vistas a comunicar datos de protocolo de internet
de acuerdo con el segundo protocolo de internet (IPv4) hacia y desde
un nodo de soporte de pasarela de la red de radiocomunicaciones por
paquetes. El nodo de soporte de pasarela se puede hacer funcionar
para establecer un portador de protocolo de tunelización con vistas
a comunicar los datos por paquetes de internet hacia y desde el
equipo de usuario pasando por las redes de radiocomunicaciones por
paquetes. El equipo de usuario se puede hacer funcionar en
combinación con el nodo de soporte de pasarela para formar una
dirección local de enlace. La dirección local de enlace comprende
un identificador de interfaz que incluye un identificador de
extremo de tunelización del portador del protocolo de tunelización
que finaliza en un nodo de soporte de pasarela de la parte de red
central de la red de radiocomunicaciones por paquetes. La dirección
local del enlace incluye también un componente de dirección que
identifica la dirección como local para la red de
radiocomunicaciones por paquetes según el primer protocolo de
internet. El equipo de usuario se puede hacer funcionar en
combinación con el nodo de soporte de pasarela para comunicar una
solicitud de una dirección de protocolo de internet, según el
primer protocolo de internet, a un servidor de asignación de
direcciones usando la dirección local del enlace. El equipo de
usuario se puede hacer funcionar en combinación con el nodo de
soporte de pasarela para recibir una dirección de protocolo de
internet asignada, según el primer protocolo de internet, y para
comunicarse con el equipo de usuario usando la dirección de
protocolo de internet asignada. El equipo de usuario se puede hacer
funcionar además para informar al nodo de soporte de pasarela de que
los datos por paquetes de internet se van a comunicar usando la
dirección asignada, estando las direcciones de origen y de destino
de los datos por paquetes de internet en concordancia con el primer
protocolo de internet, pudiéndose hacer funcionar el nodo de soporte
de pasarela para adaptar una plantilla de flujo de tráfico con
vistas a identificar el portador establecido a partir de una
dirección de origen que está en concordancia con el primer protocolo
de internet.
Las formas de realización de la presente
invención proporcionan unos medios para generar una dirección local
de enlace que se puede encaminar según el primer protocolo de
internet hacia un servidor. Como tal, la dirección local de enlace
se puede usar para adquirir una dirección de protocolo de internet a
partir de un servidor de asignación de direcciones según el primer
protocolo de internet. De este modo, la dirección adquirida se puede
usar para comunicar datos de protocolo de internet, sustituyendo la
dirección local de enlace con la dirección adquirida del equipo de
usuario.
El equipo de usuario se puede hacer funcionar
para informar al nodo de soporte de pasarela de que los datos por
paquetes de internet se van a comunicar usando la dirección
asignada, estando las direcciones de origen y de destino de los
datos por paquetes de internet en concordancia con el primer
protocolo de internet. El nodo de soporte de pasarela se puede
hacer funcionar para adaptar una plantilla de flujo de tráfico (TFT)
con vistas a identificar el portador establecido a partir de una
dirección de origen de un nodo corresponsal, que está en
concordancia con la dirección del primer protocolo de internet. Tal
como es sabido por los expertos en la materia, la plantilla del
flujo de tráfico (TFT) dentro del nodo de soporte de pasarela
realiza una función de vigilancia del uso de recursos en la red de
radiocomunicaciones por paquetes, y de encaminamiento de paquetes
de internet recibidos, a través de un portador adecuado. Según las
normativas existentes, por ejemplo, la normativa GPRS definida por
el Proyecto de Asociación de Tercera Generación (3GPP), el nodo de
soporte de pasarela se define de manera que tiene una función TFT.
El TFT encamina datos por paquetes de internet hacia el equipo de
usuario a través de la red de radiocomunicaciones por paquetes según
una dirección de origen de los datos por paquetes de internet
recibidos desde una red de datos por paquetes a la que está
conectada la red de radiocomunicaciones por paquetes. Las redes
GPRS existentes, que están dispuestas para soportar comunicaciones
por protocolo de internet de acuerdo con un segundo protocolo de
internet, por ejemplo, el IPv4, no reconocerán datos por paquetes
de internet según el primer protocolo de internet, por ejemplo, el
IPv6. Por lo tanto, los primeros paquetes de internet serían
rechazados. Esto es debido a que el portador establecido por el
nodo de soporte de pasarela para comunicar paquetes de internet será
un portador de acuerdo con el segundo protocolo de internet. Por lo
tanto, el TFT esperaría una dirección del segundo protocolo de
internet como dirección de origen. Formas de realización de la
presente invención incluyen un nodo de soporte de pasarela
modificado al cual el equipo de usuario le puede ordenar que adapte
el TFT para aceptar una dirección de origen de un nodo corresponsal
que sea una dirección de protocolo de internet según el primer
protocolo de internet. Por lo tanto, el TFT puede encaminar datos
por paquetes de internet hacia el equipo de usuario usando la
dirección de origen del nodo corresponsal, que es una dirección
según el primer protocolo de internet.
En algunas formas de realización, el primer
protocolo de internet puede ser el Protocolo de Internet Versión 6
(IPv6), y el segundo protocolo de internet puede ser el Protocolo de
Internet Versión 4 (IPv4).
Las formas de realización de la presente
invención pueden proporcionar unos medios para que un equipo de
usuario ejecute programas de aplicación que requieren el uso de
comunicaciones por el protocolo de internet IPv6 para acceder a
servicios que usan una red de un sistema de radiocomunicaciones por
paquetes que se ha dispuesto para comunicar paquetes de internet
según un protocolo de internet diferente (IPv4). La red de
radiocomunicaciones por paquetes puede ser, por ejemplo, una red
GPRS.
Otros diversos aspectos y características de la
presente invención se definen en las reivindicaciones adjuntas junta
con las formas de realización que se describen a continuación.
A continuación se describirán formas de
realización de la presente invención, únicamente a título de
ejemplo, haciendo referencia a los dibujos adjuntos en los que las
partes equivalentes están designadas por referencias numéricas
correspondientes, y en los que:
la Figura 1 es un diagrama de bloques
esquemático de un sistema de telecomunicaciones que incluye una red
GPRS;
la Figura 2 es un diagrama de bloques
esquemático de partes de la red GPRS que forman un portador de
tunelización para comunicar paquetes de internet;
la Figura 3a es un diagrama que ilustra un
identificador de punto extremo de túnel para la transmisión de
datos, y la Figura 3b es un diagrama correspondiente para datos del
plano de control;
la Figura 4a ilustra esquemáticamente un formato
de dirección para una primera GAT ID localmente exclusiva
(GAT_ID_I), y la Figura 4b ilustra esquemáticamente un formato y
dirección para una primera GAT ID globalmente exclusiva
(GAT_ID_I);
la Figura 5 ilustra esquemáticamente un formato
de dirección general para la tunelización GTP;
la Figura 6 ilustra esquemáticamente un formato
de dirección para una dirección local de enlace correspondiente a
una tunelización automática GTP;
la Figura 7 es un diagrama de flujo que ilustra
un proceso para formar una dirección local de enlace y para
comunicar paquetes de internet IPv6 desde el UE a un nodo
corresponsal;
la Figura 8 es un diagrama de flujo que ilustra
un proceso para formar la dirección local de enlace en el proceso de
la Figura 7;
la Figura 9 es un ejemplo de un formato general
de una dirección IPv6;
la Figura 10 es un ejemplo de una dirección IPv6
que muestra un prefijo de subred de n bits;
la Figura 11 es un ejemplo de un identificador
de interfaz de formato EUI-64 modificado;
la Figura 12 es un ejemplo de una dirección IPv6
global de unidifusión;
la Figura 13 es un ejemplo de una dirección IPv6
que tiene una dirección IPv4 incorporada;
la Figura 14 es un segundo ejemplo de una
dirección IPv6 que tiene una dirección IPv4 incorporada;
la Figura 15 es un ejemplo de una dirección IPv6
local de sitio;
la Figura 16 es un ejemplo de una dirección IPv6
local de enlace; y
la Figura 17 es un diagrama de flujo que ilustra
algunas de las etapas del proceso, que son necesarias para
establecer un portador para paquetes de internet que pasan por una
red GPRS.
Las formas de realización que se describen a
continuación proporcionan mecanismos para soportar un tráfico IPv6 a
través de una red GPRS/UMTS de solamente IPv4. De este modo, un
operador 3G puede soportar una red IPv6 usando su UMTS de solo IPv4,
existente, y por lo tanto se minimizan los riesgos asociados a una
introducción prematura del IMS IPv6.
La Figura 1 proporciona un diagrama de bloques
esquemático de un sistema para comunicar paquetes de internet según
un primer protocolo de internet (IPv6), a través de una red 1 de un
sistema de radiocomunicaciones por paquetes que se ha desarrollado
para soportar la comunicación de paquetes de internet de acuerdo con
la normativa de un segundo protocolo de internet (IPv4). En la
Figura 1, un equipo de usuario (UE) 2, está dispuesto para alojar
un programa de aplicación que proporciona, por ejemplo, un servicio
multimedia a un usuario. El programa de aplicación puede requerir,
por ejemplo, un acceso a un subsistema multimedia de protocolo de
internet (IMS) tal como el correspondiente desarrollado por el 3GPP
para proporcionar servicios multimedia a usuarios usando una red
troncal UMTS.
Para el presente ejemplo, la red 1 del sistema
de radiocomunicaciones por paquetes es una red del Servicio General
de Radiocomunicaciones por Paquetes (GPRS). En aras de una mayor
simplicidad, la Figura 1 muestra elementos de una red GPRS los
cuales son un Nodo de Servicio de Pasarela GPRS (GGSN) 3, Nodos de
Soporte de Servicio GPRS (SGSN) 4, Controladores de Redes de
Radiocomunicaciones (RNC) 8 y elementos de Nodo B 10.
La presente técnica trata sobre comunicaciones
por protocolos de internet entre un nodo corresponsal (CN) 12 y un
UE 2 incorporado a la red GPRS 1. El CN 12 se muestra en la Figura 1
de manera que está incorporado a una Red de Datos por Paquetes (PDN)
15, que está conectada a la red GPRS. Para comunicar datos por
paquetes de internet entre el CN y el UE se establece un portador a
través de la red GPRS tal como se ilustra en la Figura 2.
En la Figura 2, se establece un portador 14
entre el GGSN 3 y el UE 2 para comunicar paquetes de internet 5, que
tienen un encabezamiento 7 que contiene datos de dirección y carga
útil 9, hacia y desde el UE 2 y el CN 12. En general, el GGSN 4 y el
SGSN 6 forman parte de una red central, CN. Para la red central, el
portador se forma por medio de un portador del Protocolo de
Tunelización GPRS (GTP). El controlador de red de
radiocomunicaciones RNC 8 y el Nodo B 10 forman parte de una red de
radiocomunicaciones RN. Para la red de radiocomunicaciones RN, el
portador se forma a partir de un portador del protocolo de
tunelización Portador de Acceso de Radiocomunicaciones (RAB). El
portador está dispuesto para comunicar paquetes de internet 16 entre
el UE y el GGSN. Los paquetes de internet tienen una dirección 18 y
una carga útil 20.
Para el presente ejemplo, el UE 2 está
ejecutando un programa de aplicación, que requiere el soporte de,
por ejemplo, servicios IMS. No obstante, el IMS se ha desarrollado y
normalizado según la normativa del protocolo de internet IPv6,
mientras que la red GPRS 1 se ha desarrollado para soportar
comunicaciones en el protocolo de internet IPv4. Tal como se
explicará en breve, según la presente técnica, se establece un
portador para el UE 2 con vistas a transportar paquetes de internet
IPv6, a través de la red GPRS, hacia el CN 12. Con este fin, la
presente técnica está dispuesta para generar una dirección local del
enlace la cual se puede usar a continuación para adquirir, a través
del portador 14, una dirección IPv6 que se puede usar a continuación
para comunicar paquetes de internet a través de la red GPRS. Tal
como se muestra en la Figura 2, la dirección IPv6 se adquiere a
partir de un servidor de asignación de direcciones 17. El servidor
de asignación de direcciones 17 puede ser un servidor DHCP, el cual
es un servidor de asignación de direcciones sin control de estados
anteriores, conocido para los expertos en la materia.
Según la presente técnica, el UE informa al GGSN
sobre la dirección adquirida de manera que el GGSN puede modificar
su funcionamiento para encaminar paquetes de internet de acuerdo con
una dirección IPv6. Esto es gracias a una Plantilla de Flujo de
Tráfico (TFT) 19 que es responsable del encaminamiento de los
paquetes de internet de enlace descendente (del CN al UE), a través
del portador adecuado, mediante la identificación de este portador
adecuado usando la dirección de origen de los paquetes de internet.
La TFT 19 se puede establecer para reconocer bien una dirección IPv6
ó bien una dirección IPv4. Por lo tanto, una vez que el UE ha
adquirido la dirección IPv6 a partir del servidor de asignación de
direcciones 17, el UE informa a la TFT en el GGSN 3, de que la
dirección de origen con la que se va a identificar el portador
establecido será una dirección IPv6.
Para proporcionar una disposición con la que el
equipo de usuario UE pueda construir una dirección, a la que se hace
referencia como dirección local del enlace, con vistas a adquirir
una dirección IPv6, se requiere un identificador de punto extremo de
tunelización (TEID). La construcción de la dirección se explica en
la siguiente sección. En el Anexo 1 se proporciona más información
general referente a la construcción de direcciones IPv6.
La presente técnica utiliza un identificador de
punto extremo de túnel de un portador de protocolo de tunelización
GPRS para definir un identificador de interfaz a partir del cual se
puede formar una dirección local de enlace IPv6. El identificador de
interfaz se puede usar para formar una dirección compatible con el
IPv6 la cual puede ser tunelizada automáticamente por la red GPRS y
por lo tanto se le hace referencia como ID de Interfaz de
Tunelización Automática GPRS (GAT). El ID de interfaz GAT se define
usando un Identificador de Punto Extremo de Túnel del Protocolo de
Tunelización GPRS que se define según la (TS29.060). En la Figura 3a
se muestra la forma del TEID para transmisión de datos y en la
Figura 3b para datos del plano de control.
Uno de los ejemplos de un identificador de
interfaz que se puede usar para formar una dirección, que sea
compatible con el IPv6 según la Arquitectura de Direccionamiento
IPv6 (RFC2373, Apéndice A), usa el TEID en combinación con un
identificador de empresa. El identificador de interfaz tiene 64 bits
y usa un formato EUI 64 IEEE Modificado. El TEID se usa para
construir el Identificador de interfaz conforme a la RFC2373. La
dirección se construye tal como se muestra en las Figuras 4a y 4b,
en las que "c" se asigna a la id_empresa, y "g" es un
campo que proporciona el significado individual/grupo. Existen dos
formas de dirección GAT_ID_I, una es una dirección
EUI-64 IEEE exclusiva local tal como se muestra en
la Figura 4a, y la otra es una dirección EUI-64 IEEE
globalmente exclusiva tal como se muestra en la Figura 4b.
Para construir el ID de interfaz, al UE se le
debe informar sobre el TEID del portador GTP que es establecido por
el GGSN. En una Activación de Contexto PDP "convencional", el
TEID se utiliza para uso local dentro del RNC, el SGSN y el GGSN.
Debido a la necesidad por parte del UE, de construir el ID de
interfaz usando el TEID, dicho TEID necesita ser trasladado a los
UE. En un primer ejemplo, el TEID se traslada al UE directamente. En
este caso, el SGSN puede escoger el traslado de uno o la totalidad
de los tres pares de TEID (6 en total) hacia el UE usando el campo
Opción de Configuración de Protocolo (PCO) en la Aceptación de
Activación de Contexto PDP.
En un segundo ejemplo, el GGSN usa uno de sus
TEID para construir una dirección local de enlace IPv6 según sus
políticas de direccionamiento, y a continuación la traslada al SGSN
en el campo PCO del Mensaje de Respuesta de Creación de Contexto
PDP. A su vez, el SGSN, traslada esta dirección IPv6 construida por
el GGSN hacia el UE usando el campo PCO del mensaje Aceptación de
Activación de Contexto PDP.
En la Figura 6 se muestra un ejemplo más
específico de una dirección local de enlace. Según la RFC2373, un
paquete IPv6 con direcciones de origen o de destino locales del
sitio o locales del enlace no debe ser reenviado por encaminadores
fuera del sitio. Estas direcciones están destinadas a ser usadas con
fines tales como la configuración automática de direcciones, el
descubrimiento de vecinos, o cuando no hay presentes encaminadores.
La dirección de la Figura 6 se puede usar para comunicaciones dentro
de una Red Pública Terrestre de Servicios Móviles (PLMN) entre
equipos UE, es decir, las entidades pares UE están ubicadas en la
misma PLMN y no se encaminan paquetes hacia fuera, a través de la
interfaz Gi con la PDN de la Figura 1.
Según la presente técnica, el sistema de
telecomunicaciones ilustrado en las Figuras 1 y 2 funciona de manera
que proporciona una dirección local de enlace, y usa la dirección
local de enlace para adquirir una dirección IPv6. Las operaciones
realizadas por el UE y el GGSN se resumen por medio de los diagramas
de flujo mostrados en las Figuras 7, 8 y 9. La Figura 7 proporciona
una ilustración de un funcionamiento general del sistema, con el que
el UE adquiere una dirección IPv6, y el GGSN adapta la TFT para que
reconozca la dirección compatible con el IPv6. La Figura 7 se resume
de la manera siguiente:
S101: El UE solicita un portador de la red GPRS
usando una solicitud de activación de contexto del protocolo de
datos por paquetes (PDP).
S102: A continuación el GGSN recibe las
solicitudes de activación de contexto PDP, y establece un portador
que incluye un portador del Protocolo de Tunelización GPRS (GTP) a
través de la parte de red central, y un Portador de Acceso de
Radiocomunicaciones (RAB) a través de la parte de Red de
Radiocomunicaciones.
S104: A continuación, bien el GGSN ó bien el UE
forman una dirección local de enlace, que incluye un componente de
dirección de ID de interfaz. El componente de ID de interfaz incluye
un identificador de extremo de tunelización (TEID) que identifica el
extremo del portador GTP ya que el portador finaliza en el GGSN.
S106: A continuación, el UE usa la dirección
local de enlace para solicitar una dirección IPv6, por ejemplo, de
un servidor DHCPv6.
S108: El servidor DHCPv6 asigna al UE una
dirección IPv6, y devuelve la dirección IPv6 al UE.
S110: El UE informa al GGSN de que la
comunicación se efectuará en concordancia con el protocolo de
internet IPv6. De este modo, el GGSN debería identificar el portador
asignado, a partir de una dirección de origen IPv6.
S112: El UE inicia una Modificación de Contexto
PDP para modificar la TFT en el GGSN con vistas a que el portador
reconozca una dirección de origen IPv6 del CN. De este modo, la TFT
identifica el portador para comunicar datos por paquetes de internet
hacia el UE basándose en una dirección de origen que es una
dirección de origen IPv6.
El diagrama de flujo de la Figura 8 resume un
ejemplo de un proceso de formación de la dirección local de enlace
según se ha identificado en la etapa S104 de la Figura 7. La Figura
8 se resume de la manera siguiente:
S120: El GGSN proporciona al UE datos de
dirección en el campo PCO de una asignación de contexto PDP. Los
datos de dirección incluyen el identificador de extremo de
tunelización y un identificador de empresa.
S122: A continuación, el UE forma un componente
de ID de interfaz de la dirección local de enlace
(GAT-I) a partir del identificador de tunelización y
del identificador de empresa.
S124: A continuación, el UE forma la dirección
local del enlace a partir del ID de interfaz y un componente de
dirección que indica que la dirección es una dirección local. El
componente de dirección tiene un primer campo de 10 bits con un
patrón predeterminado según una normativa del protocolo de internet
IPv6, y un segundo campo de 54 bits, los cuales se fijan todos a
cero.
S106 a S112: Seguidamente, el procesado avanza
tal como se muestra en la Figura 7.
A continuación, el UE puede usar la dirección
IPv6 para comunicarse a través de los portadores de tunelización GTP
y RAB asignados. Para comunicaciones de enlace ascendente (del UE al
CN), al GGSN no le preocupa la versión del protocolo de internet.
Para comunicaciones de enlace descendente, al GGSN se le notifica
que la sesión de comunicaciones es una sesión IPv6, y que, por lo
tanto, los paquetes de internet recibidos desde el CN deberían ser
encaminados por el portador adecuado, el cual se identifica a partir
de la dirección de origen IPv6 del CN.
En las reivindicaciones adjuntas se definen
otros diversos aspectos y características de la presente invención.
Sobre las formas de realización descritas en el presente documento
se pueden aplicar varias modificaciones sin desviarse con respecto
al alcance de la presente invención. Por ejemplo, aunque las formas
de realización anteriores se han descrito para un primer protocolo
de internet como el IPv6, y el segundo protocolo de internet
(comunicación a través de la red del sistema de radiocomunicaciones
por paquetes) como el IPv4, en otras formas de realización el primer
protocolo puede ser el IPv4 y el segundo protocolo (para la
comunicación a través de la red del sistema de radiocomunicaciones
por paquetes) puede ser el IPv6. Además, se pueden usar otros
protocolos de internet para el primer y el segundo protocolos de
internet.
4. Anexo
1
Estos esquemas de direccionamiento se resumen
más detalladamente en la RFC 3513 "Internet Protocol Version 6
(IPv6) Addressing Architecture".
Las direcciones de unidifusión IPv6 son
consistentes con prefijos de longitud arbitraria de bits similares a
las direcciones IPv4 bajo Encaminamiento sin Clases. Existen varios
tipos de direcciones de unidifusión en el IPv6, en particular, de
unidifusión global, de unidifusión locales de sitio, y de
unidifusión locales de enlace. Existen además algunos subtipos de
unidifusión global de aplicación especial, tales como direcciones
IPv6 con tipos de dirección IPv4 incorporados o direcciones NSAP
codificadas. En el futuro se pueden definir tipos o subtipos de
dirección adicionales.
Los nodos IPv6 pueden tener un conocimiento
considerable o reducido de la estructura interna de la dirección
IPv6, dependiendo del papel que juegue el nodo (por ejemplo,
anfitrión con respecto a encaminador). Como mínimo, un nodo puede
considerar que la dirección de unidifusión (incluyendo la suya
propia) no tiene ninguna estructura interna. En la Figura 9 se
muestra un ejemplo de esto. Un anfitrión ligeramente sofisticado
(aunque todavía bastante sencillo) puede tener conocimiento
adicionalmente de un(os) prefijo(s) de subred para
el(los) enlace(s) al(a los) que está conectado,
en donde direcciones diferentes pueden tener valores diferentes para
el(los) prefijo(s) de subred que ocupa los primeros n
bits, tal como se muestra en la Figura 10. La dirección mostrada en
la Figura 10 se puede usar para construir la dirección IPv6,
denominada dirección GAT, para la tunelización automática. Los
identificadores de interfaz en direcciones de unidifusión IPv6 se
usan para identificar interfaces en un enlace. Se requiere que los
mismos sean únicos dentro de un prefijo de subred.
Para todas las direcciones de unidifusión,
excepto las que comienzan con el valor binario 000 (las direcciones
que usan direcciones IPv4 incorporadas), se requiere que los ID de
interfaz tengan una longitud de 64 bits y que se construyan en 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 tener un ámbito
global cuando se obtienen a partir de un testigo global (por
ejemplo, identificadores MAC de 48 bits IEEE 802 o
EUI-64 IEEE) o pueden tener un ámbito local cuando
no hay disponible un testigo global (por ejemplo, enlaces serie,
puntos extremo de túneles, etcétera) o cuando los testigos globales
no sean deseables (por ejemplo, testigos temporales por
priva-
cidad).
cidad).
Los identificadores de interfaz del formato
EUI-64 modificados se forman invirtiendo el bit
"u" (bit universal/local en la terminología
EUI-64 IEEE) cuando se forma el identificador de
interfaz a partir de identificadores EUI-64 IEEE. En
el formato resultante EUI-64 Modificado, el bit
"u" se fija a "1" para indicar el ámbito global, y el
mismo se fija a "0" para indicar el ámbito local. En la Figura
11 se muestran los primeros tres octetos en binario de un
identificador EUI-64 IEEE. Tal como se muestra en la
Figura 11, la dirección tiene campos escritos en el orden de bits
normalizado de Internet, en donde "u" es el bit
universal/local, "g" es el bit individual/grupo, y "c" son
los bits del id_empresa. En la RFC3513 se proporcionan ejemplos.
Cuando no hay disponible ningún identificador de
interfaz incorporado específico tal como en los enlaces serie o los
túneles configurados (a los mismos se les denomina enlaces sin
identificadores), se deben seleccionar identificadores de interfaz
que sean únicos dentro de un prefijo de subred.
Cuando no hay disponible ningún identificador
incorporado en un enlace, el planteamiento preferido consiste en
usar un identificador de interfaz global de otra interfaz o uno que
esté asignado al propio nodo.
Cuando no hay disponible un identificador de
interfaz global para ser usado en el enlace, es necesario crear un
identificador de interfaz de ámbito local.
En la Figura 12 se muestra un ejemplo de una
dirección de unidifusión IPv6 global.
Para facilitar la transición del IPv4 al IPv6,
se usa una técnica para que los anfitriones y los encaminadores
tunelicen dinámicamente paquetes IPv6 a través de una
infraestructura de encaminamiento IPv4. A los nodos IPv6 que usan
esta técnica se les asigna una dirección de unidifusión IPv6
especial con una dirección IPv4 global incorporada en los 32 bits de
orden inferior. En la Figura 13 se muestra un ejemplo que se puede
describir como "dirección IPv6 compatible con el IPv4".
Otro tipo de dirección IPv4 es el denominado
"dirección IPv6 con correspondencia a IPv4" que tiene un
formato de dirección tal como se ilustra en la Figura 14. El mismo
se puede usar para representar los nodos IPv4 que usando direcciones
IPv6.
En las Figuras 15 y 16 se ilustran dos tipos de
direcciones de uso local. Las mismas son una dirección local de
sitio y una dirección local de enlace. Las direcciones locales de
sitio están diseñadas para el direccionamiento dentro de un sitio
sin necesidad de un prefijo global. En la Figura 15 se muestra el
formato de la dirección local de sitio.
La dirección local de enlace está diseñada para
el direccionamiento en un enlace individual con vistas a la
configuración automática de direcciones, el descubrimiento de
vecinos, o cuando no hay presentes encaminadores. En la Figura 16 se
muestra el formato de la dirección local de sitio. Existen otros
tipos de dirección tales como la dirección
Any-cast, la dirección multidifusión, la
dirección de bucle de retorno, etcétera.
5. Anexo
2
El tráfico IP (IPv6 ó IPv4) se transporta a
través de la red UMTS (entre el UE y el GGSN) mediante un portador
UMTS. Un portador UMTS se describe como el establecimiento de un
Contexto PDP (Protocolo de Datos por Paquetes). Un equipo de usuario
UE envía paquetes IPv4 ó IPv6 a través de la red UMTS estableciendo
un Contexto PDP IPv4 ó un Contexto PDP IPv6. Los Contextos PDP IPv6
son soportados solamente en una red UMTS con capacidad IPv6,
específicamente en el SGSN y GGSN así como en un UE capaz de
soportar las funciones asociadas al IP6 (encaminamiento, seguridad)
en su pila de protocolos de la red.
Una red UMTS de solamente IPv4 soportará
únicamente un Contexto PDP IPv4, aunque no existe ninguna diferencia
explícita entre los procedimientos de establecimiento para el
Contexto PDP IPv4 y el Contexto PDP IPv6. En el siguiente resumen se
resaltan la gestión de direcciones y la seguridad dentro de una
activación de Contexto PDP, haciendo referencia a un diagrama de
flujo de la Figura 17. El diagrama de flujo de la Figura 17
representa de forma equivalente el IPv4 para un Contexto PDP IPv4 y
el IPv6 para un Contexto PDP IPv6 para un UMTS con capacidad
IPv6.
S90: El equipo de usuario UE envía al SGSN un
mensaje de Solicitud de Activación de Contexto PDP (NSAPI, TI, Tipo
PDP, Dirección PDP, Nombre de Punto de Acceso, QoS Solicitada,
Opciones de Configuración PDP). El equipo de usuario UE usa una
dirección PDP para indicar si requiere el uso de una dirección PDP
estática o si requiere el uso de 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 valida la Solicitud de Activación
de Contexto PDP usando el Tipo PDP (opcional), la Dirección PDP
(opcional), y el Nombre de Punto de Acceso (opcional) proporcionados
por el equipo de usuario UE y los registros de suscripción de
contexto PDP.
Si no se puede obtener ninguna dirección GGSN ó
si el SGSN ha determinado que la Solicitud de Activación de Contexto
PDP no es válida según las reglas, el SGSN rechaza la solicitud de
activación de contexto PDP.
Si se puede obtener 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 deja que un GGSN
asigne la dirección dinámica. El SGSN puede restringir los atributos
QoS solicitados teniendo en cuenta sus capacidades y la carga
actual, y restringirá los atributos QoS solicitados según el perfil
QoS suscrito.
El SGSN envía al GGSN afectado un mensaje
Solicitud de Creación de Contexto PDP (Tipo PDP, Dirección PDP,
Nombre de Punto de Acceso, QoS Negociada, TEID, NSAPI, MSISDN, Modo
de Selección, Características de Tarificación, Referencia de
Rastreo, Tipo de Rastreo, Id de Activación, Identidad OMC, Opciones
de Configuración PDP). La dirección PDP estará vacía si se solicita
una dirección dinámica.
S94: El GGSN crea una entrada nueva en su tabla
de contexto PDP y genera una Id de Tarificación. La entrada nueva
permite que el GGSN encamine unidades PDU PDP entre el SGSN y la red
PDP externa, y que comience a tarificar. La manera en la que el GGSN
gestiona las Características de Tarificación que puede haber
recibido desde el SGSN se define en 3G TS 32.015 [4]. A
continuación, el GGSN devuelve al SGSN un mensaje Respuesta de
Creación de Contexto PDP (TEID, Dirección PDP, Opciones de
Configuración PDP, QoS Negociada, Id de Tarificación, y Motivo). La
Dirección PDP se incluye si el GGSN asignó una dirección PDP. Si el
GGSN ha sido configurado por el operador para usar una Asignación de
Direcciones PDN Externas para el APN solicitado, la Dirección PDP se
fijará a 0.0.0.0, lo cual indica que la dirección PDP será negociada
por el equipo de usuario UE con la PDN externa después de
completarse el procedimiento de Activación de Contexto PDP. El GGSN
retransmitirá, modificará y monitorizará estas negociaciones siempre
que el contexto PDP esté en estado ACTIVO, y usará el procedimiento
Modificación de Contexto PDP Iniciado por el GGSN para transferir la
dirección PDP usada actualmente hacia el SGSN y el equipo de
usuario UE. Las Opciones de Configuración PDP contienen parámetros
PDP opcionales que pueden ser transferidos por el GGSN hacia el
equipo de usuario UE. Estos parámetros PDP opcionales pueden ser
solicitados por el equipo de usuario UE en el mensaje Solicitud de
Activación de Contexto PDP, o pueden ser enviados, sin solicitud
previa, por el GGSN. Las Opciones de Configuración PDP se envían de
forma transparente a través del SGSN. Los mensajes Creación de
Contexto PDP se envían a través de la red troncal.
S 96: Se establece un portador de acceso de
radiocomunicaciones en concordancia con la activación PDP,
incluyendo la negociación de la QoS. A continuación, la solicitud de
contexto PDP se actualiza (S97) desde el SGSN al GGSN, y el GGSN
responde a la actualización (S98).
\newpage
S 99: 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 Prioridad de
Radiocomunicaciones e Id de Flujo de Paquetes basándose en la QoS
Negociada, y devuelve al equipo de usuario UE un mensaje Aceptación
de Activación de Contexto PDP (Tipo PDP, Dirección PDP, TI, QoS
Negociada, Prioridad de Radiocomunicaciones, Id de Flujo de
Paquetes, Opciones de Configuración PDP). En este momento, el SGSN
puede encaminar unidades PDU PDP entre el GGSN y el equipo de
usuario UE, y comenzar a tarificar. El NSAPI (junto con el TI) se
usa para distinguir Contextos PDP secundarios.
[1] RFC 2893
[2] RFC2766 usando SIIT (RFC 2765))
[3] R. Steele, C-C
Lee y P. Gould, "GSM, cdmaOne and 3G Systems",
publicado por Wiley International ISBN
0 471 491853
0 471 491853
[4] 3G TS 32.015
[2] 3GPP TS 26.202 V5.1.0
(2002-09)
[3] 3GPP TS 23.107
Claims (21)
1. Sistema de telecomunicaciones para comunicar
datos por paquetes de internet según un primer protocolo de internet
a través de una red de radiocomunicaciones por paquetes (1) que se
puede hacer funcionar de acuerdo con un segundo protocolo de
internet, comprendiendo el sistema
un equipo de usuario (2) que se puede hacer
funcionar para solicitar un portador con vistas a comunicar datos de
protocolo de internet de acuerdo con el segundo protocolo de
internet hacia y desde un nodo de soporte de pasarela (3) de la red
de radiocomunicaciones por paquetes,
pudiéndose hacer funcionar el nodo de soporte de
pasarela (3) para establecer un portador de protocolo de
tunelización con vistas a comunicar los datos por paquetes de
internet hacia y desde el equipo de usuario (2) a través de la red
de radiocomunicaciones por paquetes (1), en el que el equipo de
usuario (2) se puede hacer funcionar en combinación con el nodo de
soporte de pasarela (3)
para formar una dirección local de enlace que
comprende
un identificador de interfaz que incluye un
identificador de extremo de tunelización del portador de protocolo
de tunelización que finaliza en el nodo de soporte de pasarela de la
parte de red central de la red de radiocomunicaciones por
paquetes,
un componente de dirección que identifica la
dirección como local para la red de radiocomunicaciones por paquetes
según el primer protocolo de internet,
para comunicar una solicitud de una dirección de
protocolo de internet según el primer protocolo de internet a un
servidor de asignación de direcciones (7) usando la dirección local
de enlace,
para recibir una dirección de protocolo de
internet asignada, según el primer protocolo de internet, y
para comunicarse usando la dirección de
protocolo de internet asignada,
en el que el equipo de usuario se puede hacer
funcionar
para informar al nodo de soporte de pasarela de
que los datos por paquetes de internet se van a comunicar usando la
dirección asignada, estando las direcciones de origen y de destino
de los datos por paquetes de internet en concordancia con el primer
protocolo de internet, pudiéndose hacer funcionar el nodo de soporte
de pasarela
para adaptar una plantilla de flujo de tráfico
de manera que identifique el portador establecido, a partir de una
dirección de origen que está en concordancia con el primer protocolo
de internet.
2. Sistema de telecomunicaciones según la
reivindicación 1, en el que el equipo de usuario se puede hacer
funcionar en combinación con el nodo de soporte de pasarela
para sustituir la dirección local de enlace con
la dirección asignada que cumple con el primer protocolo de
internet, y
para usar la dirección asignada como dirección
de origen para comunicar datos por paquetes de internet a un nodo
corresponsal.
3. Sistema de telecomunicaciones según la
reivindicación 1 ó 2, en el que el identificador de interfaz de la
dirección local de enlace formada por el equipo de usuario en
combinación con el nodo de soporte de pasarela incluye un
identificador de empresa indicativo de un operador de la red de
radiocomunicaciones por paquetes.
4. Sistema de telecomunicaciones según
cualquiera de las reivindicaciones anteriores, en el que el
componente de dirección local de la dirección local de enlace
incluye un campo, que indica que la dirección es una dirección local
de enlace según el primer protocolo de internet.
5. Sistema de telecomunicaciones según la
reivindicación 4, en el que el componente de dirección local incluye
un primer campo de diez bits que tiene un valor que indica que la
dirección se puede reenviar a encaminadores y un segundo campo de 45
bits que se fijan a cero.
6. Sistema de telecomunicaciones según
cualquiera de las reivindicaciones anteriores, en el que el nodo de
soporte de pasarela se puede hacer funcionar para formar la
dirección local de enlace en el nodo de soporte de pasarela usando
el identificador de extremo de tunelización, y para comunicar la
dirección de protocolo de internet al equipo de usuario.
7. Sistema de telecomunicaciones según
cualquiera de las reivindicaciones 1 a 5, en el que el nodo de
soporte de pasarela se puede hacer funcionar
para comunicar al equipo de usuario información
que identifica el portador asignado, datos de dirección, incluyendo
los datos de dirección el identificador de extremo de tunelización
del portador del protocolo de tunelización, pudiéndose hacer
funcionar el equipo de usuario
para formar la dirección local de enlace usando
el identificador de extremo de tunelización proporcionado al equipo
de usuario como parte de los datos de dirección.
8. Sistema de telecomunicaciones según la
reivindicación 7, en el que los datos de dirección incluyen el
identificador de empresa, pudiéndose hacer funcionar el equipo de
usuario para formar la dirección local de enlace según el primer
protocolo de internet a partir del identificador de empresa en
combinación con el identificador de extremo de tunelización.
9. Sistema de telecomunicaciones según la
reivindicación 8, en el que el nodo de soporte de pasarela se puede
hacer funcionar para proporcionar los datos de dirección que
incluyen el identificador de extremo de tunelización usando un campo
de opción de configuración de protocolo de la aceptación del
contexto del protocolo de datos por paquetes.
10. Sistema de telecomunicaciones según
cualquiera de las reivindicaciones anteriores, en el que la red de
radiocomunicaciones por paquetes funciona según el Servicio General
de Radiocomunicaciones por Paquetes.
11. Método de comunicación de datos por paquetes
de internet según un primer protocolo de internet, a través de una
red de radiocomunicaciones por paquetes (1) que se puede hacer
funcionar de acuerdo con un segundo protocolo de internet,
comprendiendo el método
solicitar un portador con vistas a comunicar
datos de protocolo de internet entre un nodo de soporte de pasarela
(3) de la red de radiocomunicaciones por paquetes (1) y un equipo de
usuario (2),
establecer un portador de protocolo de
tunelización con vistas a comunicar los datos por paquetes de
internet hacia y desde el equipo de usuario (2) a través de la red
de datos por paquetes (1),
formar una dirección local de enlace que
comprende
un identificador de interfaz que incluye un
identificador de extremo de tunelización del portador de protocolo
de tunelización que finaliza en un nodo de soporte de pasarela de la
parte de red central de la red de radiocomunicaciones por paquetes
(1), y
un componente de dirección que identifica la
dirección como local para la red de radiocomunicaciones por paquetes
(1) según el primer protocolo de internet,
comunicar una solicitud de una dirección de
protocolo de internet según el primer protocolo de internet a un
servidor de asignación de direcciones (17) usando la dirección local
de enlace,
recibir una dirección de protocolo de internet
asignada, según el primer protocolo de internet,
realizar la comunicación usando la dirección de
protocolo de internet asignada, e
informar al nodo de soporte de pasarela de que
los datos por paquetes de internet se van a comunicar usando la
dirección asignada, estando la dirección de origen y una dirección
de destino de los datos por paquetes de internet en concordancia con
el primer protocolo de internet, y
adaptar una plantilla de flujo de tráfico de
manera que identifique el portador establecido, a partir de una
dirección de origen que está en concordancia con el primer protocolo
de internet.
12. Método según la reivindicación 11, en el
que la formación de la dirección de protocolo de internet usando la
dirección asignada comprende
sustituir la dirección local de enlace con la
dirección asignada que cumple con el primer protocolo de internet,
y
usar la dirección asignada como dirección de
origen para comunicar datos por paquetes de internet a un nodo
corresponsal.
13. Método según la reivindicación 11, 12 ó 13,
en el que la formación de la dirección local de enlace incluye
formar el identificador de interfaz de la
dirección local de enlace con un identificador de empresa indicativo
de un operador de la red de datos por paquetes.
14. Método según cualquiera de las
reivindicaciones 11 a 13, en el que la formación de la dirección
local de enlace incluye
formar el componente de dirección local de la
dirección local de enlace con un campo, que indica que la dirección
es una dirección local de enlace según el primer protocolo de
internet.
15. Método según la reivindicación 14, en el que
la formación del componente de dirección local comprende
formar el componente de dirección local de
enlace con un primer campo de diez bits que tiene un valor que
indica que la dirección se puede reenviar a encaminadores y un
segundo campo de 45 bits que se fijan a cero.
16. Método según cualquiera de las
reivindicaciones 11 a 15, que comprende
comunicar al equipo de usuario información que
identifica el portador asignado, datos de dirección, incluyendo los
datos de dirección el identificador de extremo de tunelización del
portador del protocolo de tunelización, y
formar la dirección local de enlace usando el
identificador de extremo de tunelización proporcionado al equipo de
usuario como parte de los datos de dirección.
17. Método según la reivindicación 16, en el que
los datos de dirección incluyen el identificador de empresa,
comprendiendo la formación de la dirección local de enlace
formar la dirección local de enlace a partir del
identificador de empresa en combinación con el identificador de
extremo de tunelización.
18. Método según la reivindicación 17, en el que
la provisión de los datos de dirección comprende
usar un campo de opciones de configuración de
protocolo de la aceptación del contexto del protocolo de datos por
paquetes para proporcionar los datos de dirección que incluyen el
identificador de extremo de tunelización.
19. Método según cualquiera de las
reivindicaciones 11 a 18, en el que la red de radiocomunicaciones
por paquetes funciona según el Servicio General de
Radiocomunicaciones por Paquetes.
20. Soporte portador de un programa de ordenador
que proporciona instrucciones ejecutables por ordenador que, cuando
se cargan en un ordenador, consiguen que el ordenador realice el
método según cualquiera de las reivindicaciones 11 a 19.
21. Aparato para comunicar datos por paquetes de
internet según un primer protocolo de internet, a través de una red
de radiocomunicaciones por paquetes (1) que se puede hacer funcionar
de acuerdo con un segundo protocolo de internet, comprendiendo el
aparato
unos medios para solicitar un portador con
vistas a comunicar datos de 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 establecer un portador de
protocolo de tunelización con vistas a comunicar los datos por
paquetes de internet hacia y desde el equipo de usuario (2) a través
de la red de datos por paquetes (1),
unos medios para formar una dirección local de
enlace que comprende
unos medios de identificador de interfaz que
incluyen un identificador de extremo de tunelización del portador de
protocolo de tunelización que finaliza en el nodo de soporte de
pasarela (3) de la parte de red central de la red de
radiocomunicaciones por paquetes (1), y
unos medios de componente de dirección que están
adaptados para identificar la dirección como local para la red de
radiocomunicaciones por paquetes (1) según el primer protocolo de
internet,
unos medios para comunicar una solicitud de una
dirección de protocolo de internet según el primer protocolo de
internet a un servidor de asignación de direcciones (7) usando la
dirección local de enlace,
unos medios para recibir una dirección de
protocolo de internet asignada, según el primer protocolo de
internet,
unos medios para comunicarse usando la dirección
de protocolo de internet asignada, e
informar al nodo de soporte de pasarela de que
los datos por paquetes de internet se van a comunicar usando la
dirección asignada, estando la dirección de origen y una dirección
de destino de los datos por paquetes de internet en concordancia con
el primer protocolo de internet, y
adaptar una plantilla de flujo de tráfico para
identificar el portador establecido, a partir de una dirección de
origen que está en concordancia con el primer protocolo de
internet.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0417117A GB2416958A (en) | 2004-07-30 | 2004-07-30 | Communicating internet packet data over a packet radio network |
| GB0417117 | 2004-07-30 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2310358T3 true ES2310358T3 (es) | 2009-01-01 |
Family
ID=32947785
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES05752109T Active ES2310358T3 (es) | 2004-07-30 | 2005-06-10 | Tunelizacion de paquetes de protocolo de internet entre un nodo de soporte de pasarela y un terminal movil. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7860073B2 (es) |
| EP (1) | EP1771978B1 (es) |
| CN (1) | CN101019383B (es) |
| AT (1) | ATE400122T1 (es) |
| DE (1) | DE602005007906D1 (es) |
| ES (1) | ES2310358T3 (es) |
| GB (1) | GB2416958A (es) |
| WO (1) | WO2006010876A1 (es) |
Families Citing this family (18)
| 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 |
| EP1993238A4 (en) * | 2006-03-06 | 2009-07-29 | Huawei Tech Co Ltd | DEVICE AND METHOD AND SYSTEM FOR OBTAINING THE IPV6 ADDRESS |
| WO2008096910A1 (en) * | 2007-02-04 | 2008-08-14 | Ki-Hyung Kim | Address assignment method and transmission method of mobile of mobile nodes for hierarchical routing in lowpans |
| WO2008120276A1 (ja) * | 2007-03-29 | 2008-10-09 | Fujitsu Limited | 通信システム、通信システムにおける通信方法、及び中継装置 |
| CN101330425B (zh) * | 2007-06-19 | 2011-03-02 | 中兴通讯股份有限公司 | Sgsn到服务网关的隧道的建立方法 |
| CN101374160B (zh) * | 2007-08-21 | 2012-08-22 | 华为技术有限公司 | 分组网络中分配用户地址的方法、装置及系统 |
| CN101183936B (zh) * | 2007-12-04 | 2011-04-20 | 中兴通讯股份有限公司 | 一种因特网密钥交换中IPv6身份载荷交换的方法 |
| CN101646205B (zh) * | 2008-08-05 | 2014-07-09 | 华为技术有限公司 | 移动网络高速接入公网的节点、方法及系统 |
| US8837395B2 (en) | 2008-12-19 | 2014-09-16 | Optis Cellular Technology, Llc | Method and entity for conveying data units |
| KR101091300B1 (ko) * | 2009-08-21 | 2011-12-07 | 엘지전자 주식회사 | 이동통신 네트워크 내에서 제어 평면（Ｃｏｎｔｒｏｌ Ｐｌａｎｅ） 을 담당하는 서버 및 ＬＩＰＡ（Ｌｏｃａｌ ＩＰ Ａｃｃｅｓｓ） 서비스를 제어하는 방법 |
| WO2011057655A1 (en) * | 2009-11-16 | 2011-05-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Devices for variable traffic flow templates |
| CN102299973A (zh) * | 2010-06-23 | 2011-12-28 | 中兴通讯股份有限公司 | 在分流网络中实现地址分配的方法和装置 |
| US9204336B2 (en) * | 2010-08-17 | 2015-12-01 | Telefonaktiebolaget L M Ericsson (Publ) | Technique of processing network traffic that has been sent on a tunnel |
| US9621458B2 (en) * | 2012-02-21 | 2017-04-11 | Qualcomm Incorporated | Internet routing over a service-oriented architecture bus |
| US9350814B2 (en) | 2012-02-21 | 2016-05-24 | Qualcomm Incorporated | Internet protocol connectivity over a service-oriented architecture bus |
| US10230534B2 (en) * | 2013-05-31 | 2019-03-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Service layer control aware control signalling in a communication network |
| US10516648B2 (en) * | 2018-01-29 | 2019-12-24 | Hewlett Packard Enterprise Development Lp | Address translation |
| CN112291151B (zh) * | 2020-11-18 | 2022-07-12 | 迈普通信技术股份有限公司 | 一种报文转发方法、装置、网络设备及存储介质 |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
| EP1290858B1 (en) * | 2000-05-31 | 2009-04-22 | Nokia Corporation | Method and apparatus for generating a connection identification |
| 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 |
| US7443859B2 (en) * | 2001-12-18 | 2008-10-28 | Nokia Corporation | Method and apparatus for address allocation in GPRS networks that facilitates end-to-end security |
| US20040006641A1 (en) * | 2002-07-02 | 2004-01-08 | Nischal Abrol | Use of multi-format encapsulated internet protocol messages in a wireless telephony network |
| 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 |
| DE60234479D1 (de) | 2002-11-27 | 2009-12-31 | Research In Motion Ltd | Zuweisen einer temporären IPv6-Adresse zu einer temporären IPv4-Adresse, um in einem IPv4-Netzwerk mit einem schnurlosen Gerät zu kommunizieren |
| US6865184B2 (en) * | 2003-03-10 | 2005-03-08 | Cisco Technology, Inc. | Arrangement for traversing an IPv4 network by IPv6 mobile nodes |
| US7554991B2 (en) * | 2003-06-27 | 2009-06-30 | Nokia Corporation | Method, system and network element for data transmission using a transition mechanism |
| CN100334858C (zh) * | 2003-07-14 | 2007-08-29 | 中国科学院计算技术研究所 | 一种利用双重隧道机制穿透nat的方法 |
| CN100379219C (zh) * | 2003-07-23 | 2008-04-02 | 中国科学院计算技术研究所 | 利用nat-pt和客户/服务器模式实现ip网络终端通信方法 |
| 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 GB0417117A patent/GB2416958A/en not_active Withdrawn
-
2005
- 2005-06-10 DE DE602005007906T patent/DE602005007906D1/de active Active
- 2005-06-10 WO PCT/GB2005/002313 patent/WO2006010876A1/en active Search and Examination
- 2005-06-10 CN CN2005800249070A patent/CN101019383B/zh active Active
- 2005-06-10 EP EP05752109A patent/EP1771978B1/en active Active
- 2005-06-10 AT AT05752109T patent/ATE400122T1/de not_active IP Right Cessation
- 2005-06-10 US US11/658,778 patent/US7860073B2/en active Active
- 2005-06-10 ES ES05752109T patent/ES2310358T3/es active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US20090073919A1 (en) | 2009-03-19 |
| GB0417117D0 (en) | 2004-09-01 |
| EP1771978B1 (en) | 2008-07-02 |
| GB2416958A (en) | 2006-02-08 |
| DE602005007906D1 (de) | 2008-08-14 |
| EP1771978A1 (en) | 2007-04-11 |
| ATE400122T1 (de) | 2008-07-15 |
| CN101019383A (zh) | 2007-08-15 |
| WO2006010876A1 (en) | 2006-02-02 |
| US7860073B2 (en) | 2010-12-28 |
| CN101019383B (zh) | 2010-08-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2310358T3 (es) | Tunelizacion de paquetes de protocolo de internet entre un nodo de soporte de pasarela y un terminal movil. | |
| ES2299050T3 (es) | Sistema y procedimiento para transmitir datos de paquetes de internet mediante redes de radiocomunicaciones por paquetes. | |
| ES2333801T3 (es) | Sistema de telecomunicaciones. | |
| JP5384934B2 (ja) | パケット無線ネットワーク及び通信方法 | |
| JP4970422B2 (ja) | パケット無線ネットワーク及び通信方法 | |
| JP4270888B2 (ja) | Ｗｌａｎ相互接続におけるサービス及びアドレス管理方法 | |
| EP1560378B1 (en) | Wireless mobility gateway | |
| US7554991B2 (en) | Method, system and network element for data transmission using a transition mechanism | |
| US9872321B2 (en) | Method and apparatus for establishing and using PDN connections | |
| ES2297798T3 (es) | Metodo para una pasarela de seleccion de un canal para transferir paquetes de datos. | |
| US20160380962A1 (en) | Wireless access gateway | |
| WO2012126291A1 (zh) | 一种数据路由方法及系统 | |
| US20170041247A1 (en) | Wireless access gateway | |
| JP4802238B2 (ja) | ローカルネットワーク相互接続における移動端末に対してネットワークに基づくトンネルを設定する方法 |