ES2244630T3 - Procedimiento para evitar tiempos de espera ppp durante negociaciones ipcp. - Google Patents
Procedimiento para evitar tiempos de espera ppp durante negociaciones ipcp.Info
- Publication number
- ES2244630T3 ES2244630T3 ES01942488T ES01942488T ES2244630T3 ES 2244630 T3 ES2244630 T3 ES 2244630T3 ES 01942488 T ES01942488 T ES 01942488T ES 01942488 T ES01942488 T ES 01942488T ES 2244630 T3 ES2244630 T3 ES 2244630T3
- Authority
- ES
- Spain
- Prior art keywords
- address
- message
- assigned
- communication device
- communication
- 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.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims abstract description 32
- OYYYPYWQLRODNN-UHFFFAOYSA-N [hydroxy(3-methylbut-3-enoxy)phosphoryl]methylphosphonic acid Chemical compound CC(=C)CCOP(O)(=O)CP(O)(O)=O OYYYPYWQLRODNN-UHFFFAOYSA-N 0.000 title claims abstract 18
- 238000004891 communication Methods 0.000 claims abstract description 82
- 230000004044 response Effects 0.000 claims abstract description 17
- 238000012790 confirmation Methods 0.000 claims description 25
- 230000005540 biological transmission Effects 0.000 claims description 12
- 238000012795 verification Methods 0.000 claims 3
- 238000012423 maintenance Methods 0.000 description 4
- 230000001934 delay Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 238000001228 spectrum Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002028 premature Effects 0.000 description 2
- 238000012216 screening Methods 0.000 description 2
- 241000408659 Darpa Species 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000013497 data interchange Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- VJYFKVYYMZPMAB-UHFFFAOYSA-N ethoprophos Chemical compound CCCSP(=O)(OCC)SCCC VJYFKVYYMZPMAB-UHFFFAOYSA-N 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 239000000543 intermediate Substances 0.000 description 1
- PWPJGUXAGUPAHP-UHFFFAOYSA-N lufenuron Chemical compound C1=C(Cl)C(OC(F)(F)C(C(F)(F)F)F)=CC(Cl)=C1NC(=O)NC(=O)C1=C(F)C=CC=C1F PWPJGUXAGUPAHP-UHFFFAOYSA-N 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 230000007723 transport mechanism Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
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
- 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
- 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]
-
- 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/50—Address allocation
- H04L61/5007—Internet protocol [IP] addresses
-
- 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/5084—Providing for device mobility
-
- 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/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
-
- 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/163—In-band adaptation of TCP data exchange; In-band control procedures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
-
- 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/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Databases & Information Systems (AREA)
- Quality & Reliability (AREA)
- Mobile Radio Communication Systems (AREA)
- Small-Scale Networks (AREA)
- Electrophonic Musical Instruments (AREA)
Abstract
Procedimiento para mantener negociaciones de direcciones IP en una red de comunicación inalámbrica que implementa el protocolo IPCP, que comprende: la recepción, en un dispositivo de comunicación, de un mensaje en el que se solicita una dirección IP a un dispositivo terminal que contiene una dirección particular, estando acoplado dicho dispositivo terminal a dicho dispositivo de comunicación; la generación, en dicho dispositivo de comunicación, de un mensaje en el que se solicita una dirección IP a dicha red de comunicación en respuesta a dicho mensaje de solicitud de dirección IP; y la determinación de la recepción o no por dicho dispositivo de comunicación de una dirección IP asignada desde dicha red de comunicación, caracterizado porque cuando se determina que dicho dispositivo de comunicación no ha recibido dicha dirección IP asignada, dicho dispositivo de comunicación transmite repetidamente un mensaje con una dirección IP arbitraria a dicho dispositivo terminal para que dicho dispositivo terminal responda transmitiendo mensajes de solicitud de dirección IP que incluyen dicha dirección IP arbitraria, y dicho dispositivo de comunicación rechaza dicha dirección IP de dichos mensajes de solicitud de dirección IP hasta que recibe dicha dirección IP asignada desde dicha red de comunicación.
Description
Procedimiento para evitar tiempos de espera PPP
durante negociaciones IPCP.
La presente invención se refiere en general al
campo de las comunicaciones inalámbricas. Más particularmente, la
presente invención se refiere a un nuevo procedimiento para evitar
tiempos de espera y permitir el mantenimiento de negociaciones de
direcciones IPCP.
Las recientes innovaciones en la comunicación
inalámbrica y las tecnologías informáticas, así como el crecimiento
inaudito del número de abonados a Internet, han preparado el
terreno para la informática móvil. En realidad, el éxito de la
informática móvil ha impuesto grandes exigencias a la
infraestructura actual de Internet para proporcionar más atención a
los usuarios móviles. Una parte crucial del cumplimiento de estas
exigencias y de la provisión a los usuarios de la atención
necesaria es la utilización de la tecnología de acceso múltiple por
división del código (CDMA) en los sistemas de comunicación
inalámbrica.
La técnica CDMA es una técnica de subdivisión en
canales de radiofrecuencia (RF) digital que se define en la regla
de la Telecommunications Industry Association/Electronics
Industries Association Interim Standard-95
(TIA/
EIA IS-95), titulada "MOBILE STATION-BASE STATION COMPATIBILITY STANDARD FOR DUAL-MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEM", publicada en julio de 1993. Los sistemas de comunicación inalámbrica que emplean esta tecnología asignan un código exclusivo a las señales de comunicación y distribuyen estas señales de comunicación a través de un ancho de banda de espectro ensanchado (banda ancha) común. Siempre que el aparato receptor de un sistema CDMA presente el código correcto, éste podrá detectar y seleccionar de forma satisfactoria su señal de comunicación del resto de señales transmitidas simultáneamente a través del mismo ancho de banda. La utilización de la técnica CDMA incrementa la capacidad de tráfico del sistema, mejora la calidad global de las llamadas, reduce el ruido y proporciona un mecanismo de transporte fiable para el tráfico de servicios de datos.
EIA IS-95), titulada "MOBILE STATION-BASE STATION COMPATIBILITY STANDARD FOR DUAL-MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEM", publicada en julio de 1993. Los sistemas de comunicación inalámbrica que emplean esta tecnología asignan un código exclusivo a las señales de comunicación y distribuyen estas señales de comunicación a través de un ancho de banda de espectro ensanchado (banda ancha) común. Siempre que el aparato receptor de un sistema CDMA presente el código correcto, éste podrá detectar y seleccionar de forma satisfactoria su señal de comunicación del resto de señales transmitidas simultáneamente a través del mismo ancho de banda. La utilización de la técnica CDMA incrementa la capacidad de tráfico del sistema, mejora la calidad global de las llamadas, reduce el ruido y proporciona un mecanismo de transporte fiable para el tráfico de servicios de datos.
La Figura 1 ilustra los elementos básicos de
dicho sistema de comunicación inalámbrica de datos 100. Como
deducirán fácilmente las personas medianamente expertas en la
materia, estos elementos, y sus interfaces, pueden modificarse,
aumentarse o someterse a diversas reglas técnicas conocidas dentro
de la técnica, sin limitar ni su alcance ni su funcionamiento. El
sistema 100 permite, a un equipo terminal móvil, el dispositivo TE2
102 (por ejemplo, un equipo terminal como un ordenador portátil o
de bolsillo), comunicarse con una función de interfuncionamiento
(IWF) 108. El sistema 100 incluye un dispositivo de comunicación
inalámbrica, un dispositivo MT2 104 (por ejemplo, un teléfono
inalámbrico) y una estación base/centro de conmutación móvil
(BS/MSC) 106. La IWF 108 se utiliza como pasarela entre la red
inalámbrica y otras redes, tales como la red telefónica pública
conmutada o las redes alámbricas de transmisión de datos por
paquetes que proporcionan acceso basado en Internet o Intranet. La
IWF 108 y la BS/MSC 106 se acoplan mutuamente mediante una interfaz
L. A menudo, la IWF 108 y la BS/MSC 106 ocupan el mismo
emplazamiento. El dispositivo TE2 102 se acopla electrónicamente al
dispositivo MT2 104 por medio de la interfaz R_{m}. El
dispositivo MT2 104 se comunica con la BS/MSC 106 por medio de la
interfaz inalámbrica U_{m}. El dispositivo TE2 102 y el
dispositivo MT2 104 pueden integrarse en una sola unidad (por
ejemplo, en un dispositivo MT0) o pueden separarse, como en el caso
de una unidad telefónica móvil instalada, en el que el dispositivo
TE2 102 es un ordenador portátil y el dispositivo MT2 104 es el
transceptor. Es importante observar que, como se indica en la Figura
2, la combinación del dispositivo TE2 102 y el dispositivo MT2 104,
ya estén integrados o separados, se denomina en general estación
móvil (MS) 103.
Es posible proporcionar otro tipo de asistencia
aplicando diversos protocolos conocidos para controlar, gestionar o
facilitar de cualquier otra manera diferentes aspectos de las
comunicaciones inalámbricas. Por ejemplo, la parte vital de la
infraestructura de Internet, el protocolo Internet (IP), ha sido
introducida en numerosos servicios de comunicación inalámbrica para
adaptarse a los servicios orientados a paquetes. Como se define en
la regla Request For Comment 791 (RFC 791), titulada "INTERNET
PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION" y
publicada en septiembre de 1981, el protocolo IP especifica el
direccionamiento y el encaminamiento de los paquetes (datagramas)
entre los ordenadores principales.
El protocolo IP es un protocolo de capa de red
que encapsula datos en paquetes IP para la transmisión. La
información de direccionamiento y de encaminamiento se adjunta a la
cabecera del paquete. Las cabeceras IP contienen direcciones de 32
bits que identifican las máquinas emisoras y las máquinas
receptoras. Estas direcciones son utilizadas por encaminadores
intermedios para seleccionar una trayectoria a través de la red
hasta el destino final del paquete en la dirección deseada. Por lo
tanto, el protocolo IP permite a los paquetes que se originan en
cualquier nodo Internet del mundo encaminarse hacia cualquier otro
nodo Internet del mundo.
Otro protocolo muy conocido incorporado en los
sistemas de comunicaciones inalámbricas es el protocolo punto a
punto (PPP), que proporciona, inter alia, el acceso a
Internet. El protocolo PPP se describe en detalle en Request for
Comments 1661 (RFC 1661), titulado "THE
POINT-TO-POINT PROTOCOL (PPP)"
publicada en julio de 1994.
En esencia, el protocolo PPP indica un
procedimiento para transportar datagramas multiprotocolo a través de
enlaces punto a punto y contiene tres componentes principales: un
procedimiento para encapsular datagramas multiprotocolo, un
protocolo de control de enlace (LCP) para establecer, configurar y
comprobar una conexión de enlace de datos, y una familia de
protocolos de control de red (NCP) para establecer y configurar
diferentes protocolos de la capa de red.
En un intento de proporcionar un nodo de
servicios en los sistemas de comunicación inalámbrica, se han
diseñado diversas reglas técnicas para adaptarse a la transmisión
inalámbrica de datos entre el dispositivo TE2 102 y la IWF 108. Por
ejemplo, la regla TIA/EIA IS-707.5, titulada
"DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: PACKET
DATA SERVICES", publicada en febrero de 1998, define los
requisitos para tener la capacidad de transmisión de datos por
paquetes en los sistemas TIA/EIA IS-95 e indica un
conjunto de servicios portadores de datos por paquetes.
En particular, la regla IS-707.5
proporciona ciertas modalidades de servicios de datos por paquetes
que pueden utilizarse para comunicarse entre el dispositivo TE2 102
y la IWF 108 por medio de la BS/MSC 106. La regla
IS-707.5 introduce el modelo de red que proporciona
una modalidad específica de funcionamiento. El modelo de red
representa una situación en la que se establece un primer enlace
PPP entre el dispositivo TE2 102 y el dispositivo MT2 104, y se
establece un segundo enlace PPP, independiente del primero, entre el
dispositivo MT2 104 y la IWF 108. En este modelo, el dispositivo
MT2 104 es el encargado de llevar a cabo el destramado de los
paquetes PPP recibidos y el nuevo tramado de éstos antes de
enviarlos a su destino final, así como de proporcionar la gestión de
la movilidad y la gestión de las direcciones de red.
La Figura 2 ilustra las pilas de protocolos de
cada entidad del modelo de red IS-707.5. En el
extremo izquierdo de la Figura 2, se ilustra una pila de protocolos,
representada en formato vertical convencional, en la que pueden
observarse las capas de protocolos que se ejecutan en el
dispositivo TE2 102 (por ejemplo, el terminal móvil o el ordenador
portátil o de bolsillo). La pila de protocolos TE2 ilustrada está
conectada lógicamente a la pila de protocolos del dispositivo MT2
104 a través de la interfaz R_{m}. El dispositivo MT2 104
ilustrado está conectado lógicamente a la pila de protocolos de la
BS/MSC 106 a través de la interfaz U_{m}. A su vez, la pila de
protocolos de la BS/MSC 106 ilustrada está conectada lógicamente a
la pila de protocolos de la IWF 108 a través de la interfaz L.
A título ilustrativo, los protocolos
representados en la Figura 2 funcionan de la forma indicada a
continuación. La capa PPP del dispositivo TE2 102 asociado a la
interfaz R_{m} (es decir, PPP_{R} 208) codifica los paquetes de
los protocolos de capa superior 204 y del protocolo IP de la capa
de red 206. Entonces, la capa PPP_{R} 208 transmite los paquetes
a través de la interfaz R_{m} mediante un protocolo aplicable, tal
como el protocolo TIA/EIA 232-F 210, y los paquetes
son recibidos por la puerta compatible con TIA/EIA
232-F del dispositivo MT2 104. La regla
TIA/EIA-232-F se define en el
documento "INTERFACE BETWEEN DATA TERMINAL EQUIPMENT AND DATA
CIRCUIT-TERMINATING EQUIPMENT EMPLOYING SERIAL
BINARY DATA INTERCHANGE", publicado en octubre de 1997. Debe
sobrentenderse que es posible utilizar otras reglas o protocolos
conocidos por las personas medianamente expertas en la materia para
definir la transmisión a través de la interfaz R_{m}. Por
ejemplo, entre las otras reglas de interfaz R_{m} aplicables se
incluye "UNIVERSAL SERIAL BUS (USB) SPECIFICATION, Revision
1.1", publicada en septiembre de 1998, y "BLUETOOTH
SPECIFICATION VERSION 1.0 CORE", publicada en julio de 1999.
El protocolo TIA/EIA 232-F 212
del dispositivo MT2 104 recibe los paquetes del dispositivo TE2 102
y los pasa a la capa PPP_{R} 213 del dispositivo MT2 104. La capa
PPP_{R} 213 lleva a cabo el destramado de los paquetes
encapsulados en las tramas PPP y, habitualmente, cuando se ha
establecido una conexión de datos, la capa 213 transfiere los
paquetes a la capa PPP asociada a la interfaz U_{m} (es decir, la
capa PPP_{U} 217). La capa PPP_{U} 217 formatea los paquetes en
tramas PPP para la transmisión a otro par PPP_{U} situado en la
IWF 108. El protocolo de enlace de radio (RLP) 216 y el protocolo
IS-95 214, ambos de los cuales son muy conocidos en
el ámbito de la técnica, se utilizan para transmitir las tramas PPP
de paquetes encapsulados a la BS/MSC 106 a través de la interfaz
U_{m}. El protocolo RLP 216 se define en la regla
IS-707.2, titulada "DATA SERVICE OPTIONS FOR
WIDEBAND SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL", publicada
en febrero de 1998, y el protocolo IS-95 se define
en la regla IS-95 indicada.
Como se ha mencionado anteriormente, el protocolo
PPP_{R} 213 transfiere los paquetes al protocolo PPP_{U} 217
cuando se establece una conexión de enlace de datos. La regla RFC
1661 estipula que los paquetes de protocolo de control de enlace
(LCP) deben ser intercambiados y negociados a través de cada enlace
PPP (es decir, PPP_{R} y PPP_{U}) para establecer, configurar y
comprobar la conexión del enlace de datos.
Una vez intercambiados los paquetes LCP,
negociadas las opciones de enlace y establecida la conexión del
enlace de datos, deberá establecerse una conexión de capa de red
entre el dispositivo TE2 102 y la IWF 108. Dicha conexión emplea los
protocolos 206, 212, 218 y 230 que incluyen, por ejemplo, el
protocolo IP. La negociación, la configuración, la habilitación y
la inhabilitación del protocolo IP en ambos extremos de los enlaces
PPP vienen proporcionadas por el conocido protocolo de control de
protocolo de Internet (IPCP). El IPCP forma parte de una familia de
protocolos de control de red (NCP) incluida en el protocolo PPP y
descrita en la regla Request for Comment (RFC) 1332, titulada "THE
PPP INTERNET PROTOCOL CONTROL PROTOCOL (IPCP)" publicada en mayo
de 1992.
El protocolo IPCP emplea los mensajes PPP
estándar de solicitud de configuración, confirmación de
configuración y confirmación negativa de configuración para
negociar diversas opciones, incluidas la solicitud y la designación
de direcciones IP. El protocolo IPCP estipula que el solicitante de
una dirección IP genera un mensaje de solicitud de configuración
que contiene una dirección particular. Si la dirección IP particular
es aceptable, un dispositivo del mismo nivel (su "igual" o
peer) envía un mensaje de confirmación de configuración al
solicitante. Si la dirección IP particular no es aceptable, entonces
el igual envía un mensaje de confirmación negativa de configuración
que contiene una dirección IP recomendada. Entonces, el solicitante
transmite un nuevo mensaje de solicitud de configuración con la
dirección IP recomendada y el igual responde con un mensaje de
confirmación de configuración.
Sólo se pueden asignar direcciones IP
individuales a través de los enlaces PPP_{U} y PPP_{R}, puesto
que no existe ningún mecanismo en IPCP para asignar más de una
dirección. Esto significa que la dirección IP que se asigna desde
la IWF a través de PPP_{U} debe asignarse además al dispositivo
TE2 a través de PPP_{R}. En el modelo de red, las negociaciones
de direcciones IPCP pueden efectuarse por separado en la interfaz
R_{m} y la interfaz U_{m}. Así pues, el dispositivo MT2 104
debe negociar primero una dirección IP a través de la interfaz
U_{m} con la IWF 108 situada en un extremo del enlace PPP_{U}
para poder asignar la dirección al dispositivo TE2 102 situado en
el otro extremo del enlace PPP_{R}.
La consumación de las negociaciones de
direcciones IPCP puede verse obstruida, no obstante, por retardos
operativos. Dichos retardos pueden producirse, por ejemplo, cuando
el enlace entre el dispositivo MT2 104 y la IWF 108 es más lento que
el enlace entre el dispositivo TE2 102 y el dispositivo MT2 104.
Así pues, existe la posibilidad de que las negociaciones de
direcciones IPCP se culminen más rápidamente en el enlace R_{m}
que en el enlace U_{m}. El dispositivo TE2 102 puede, por lo
tanto, solicitar una dirección IP al dispositivo MT2 104, que no
podrá ser concedida, puesto que el dispositivo MT2 104 todavía no
ha finalizado las negociaciones de dirección necesarias en el enlace
U_{m} para suministrar una dirección IP desde la IWF 108. Aunque
el dispositivo TE2 102 es capaz de esperar a que el dispositivo MT2
104 le proporcione finalmente una dirección IP, existen tiempos de
espera específicos para cada implementación del dispositivo TE2 102
que pueden determinar que el dispositivo TE2 102 cancele la
petición de dirección IP y, en consecuencia, el conjunto de las
negociaciones PPP.
Otro ejemplo de retardo operativo se produce
cuando la IWF 108 necesita obtener la dirección IP, que finalmente
será asignada al dispositivo TE2 102, desde otra entidad para poder
pasarla al dispositivo MT2 104. Por este motivo, la dirección IP
puede tardar varios segundos en llegar al dispositivo MT2 104.
A título de ejemplo, debe observarse que algunas
aplicaciones que se ejecutan en el dispositivo TE2 102 permiten al
dispositivo TE2 102 generar mensajes de solicitud de configuración
cada 3 segundos para 3 intentos antes de que el TE2 102 experimente
una tiempo de espera. En tales casos, si la recepción de una
dirección IP lleva más de un total de 9 segundos, el dispositivo
TE2 102 cancela la petición de dirección. Es evidente que, en
cualquiera de las dos situaciones indicadas anteriormente, se pueden
generar retardos que pueden determinar que el dispositivo TE2 102
efectúe una cancelación prematura.
Por consiguiente, se plantea la necesidad de
disponer de un nuevo procedimiento para evitar los tiempos de
espera y que permita mantener las negociaciones de direcciones
IPCP.
La presente invención hace frente a la necesidad
indicada anteriormente proporcionando un procedimiento nuevo para
evitar los tiempos de espera y permitir el mantenimiento de las
negociaciones ICPC, según las reivindicaciones adjuntas.
Los procedimientos coherentes con los principios
de la presente invención, que adoptan las formas de realización
descritas aquí, incluyen un dispositivo de comunicación que recibe
un mensaje en el que se solicita una dirección IP, tal como un
mensaje de solicitud de configuración, desde un dispositivo
terminal que está acoplado al dispositivo de comunicación. A
continuación, el dispositivo de comunicación determina si ha
recibido una dirección IP asignada desde un igual (por ejemplo, una
IWF) en respuesta al mensaje de solicitud de dirección IP. Cuando
se determina que el dispositivo de comunicación no ha recibido la
dirección IP asignada desde la IWF, el dispositivo de comunicación
transmite un mensaje con una dirección IP arbitraria, tal como un
mensaje de confirmación negativa de configuración, al dispositivo
terminal. La dirección IP arbitraria contenida en el mensaje será
rechazada por el dispositivo de comunicación, hecho que determina
que el dispositivo terminal continúe transmitiendo mensajes de
solicitud de dirección IP adicionales hasta que el dispositivo de
comunicación haya recibido la dirección IP asignada.
Los dibujos adjuntos, que se incorporan a esta
memoria y forman parte de la misma, ilustran una forma de
realización de la presente invención y, junto con la descripción,
explican los objetivos, las ventajas y los principios de la presente
invención.
La Figura 1 es un diagrama de bloques de nivel
alto que representa diversos elementos de un sistema de
comunicación inalámbrica.
La Figura 2 describe de forma esquemática las
pilas de protocolos de un sistema de comunicación inalámbrica.
La Figura 3A es un diagrama de flujo que describe
una forma de realización de la presente invención.
La Figura 3B es un diagrama de flujo
protocolo-mensaje que describe el funcionamiento de
una forma de realización de la presente invención.
La siguiente descripción detallada de las formas
de realización de la presente invención se refiere a los dibujos
adjuntos que las ilustran. Se pueden crear otras formas de
realización y efectuar modificaciones a éstas sin apartarse del
alcance de la presente invención. Por consiguiente, la siguiente
descripción detallada no pretende limitar la presente invención;
antes bien, el alcance de ésta viene delimitado por las
reivindicaciones adjuntas.
Como comprenderán las personas medianamente
expertas en la materia, la forma de realización de la presente
invención, descrita más adelante, puede realizarse en una
diversidad de implementaciones, incluido el software, el firmware y
el hardware de las entidades ilustradas en las Figuras (es decir,
el dispositivo TE2 102, el dispositivo MT2 104, la BS/MSC 106 y la
IWF 108). El código de software o el hardware de control concreto
utilizado para implementar la presente invención no pretenden
limitar la presente invención. Por lo tanto, el funcionamiento y el
comportamiento de la presente invención serán descritos sin
referencia particular al código de software o componentes de
hardware particulares. Dichas referencias no específicas se
consideran aceptables, ya que se sobrentiende que las personas
medianamente expertas en la materia serán capaces de diseñar el
software y el hardware de control para implementar la forma de
realización de la presente invención basándose en la descripción
proporcionada aquí.
La Figura 3A es un diagrama de flujo que ilustra
una forma de realización de la presente invención y la Figura 3B es
un diagrama de flujo protocolo-mensaje# que describe
el funcionamiento de una forma de realización de la presente
invención. Como se indica en la Figura 3A, el dispositivo MT2 104,
en el bloque B305, comienza las negociaciones PPP a través de la
interfaz U_{m} con la IWF 108. Este evento es desencadenado por
el inicio de negociaciones LCP en la interfaz R_{m}, como se
ilustra en la Figura 3B (véase referencia A).
En el bloque B310, el dispositivo MT2 104 espera
a recibir un mensaje de solicitud de configuración IPCP desde el
dispositivo TE2 102. Una vez que el dispositivo MT2 104 ha recibido
un mensaje de solicitud de configuración desde el dispositivo TE2
102, el dispositivo MT2 140 continúa con el bloque B315.
En el bloque B315, el dispositivo MT2 104
determina si ha recibido una dirección IP, asignada por la IWF 108,
en respuesta al mensaje de solicitud de configuración del
dispositivo TE2 102. De no ser así, el dispositivo MT2 104 continúa
por el bloque B320, en el que rechaza la dirección IP contenida en
el mensaje de solicitud de configuración, y transmite un mensaje de
confirmación negativa de configuración con una dirección IP
arbitraria (véase referencia B en la Figura 3B). La dirección IP
arbitraria es una dirección que será rechazada por el dispositivo
MT2 104. Una vez transmitido el mensaje de confirmación negativa de
configuración con la dirección IP arbitraria, el dispositivo MT2 104
retrocede hasta el bloque B310 para esperar otro mensaje de
solicitud de configuración IPCP del dispositivo TE2 102, con la
dirección IP arbitraria. Debido a que la dirección IP arbitraria no
es la dirección IP asignada por la IWF 108, el dispositivo MT2 104
es dirigido de nuevo hacia el bloque B320 donde, una vez más,
rechaza la dirección IP contenida en el mensaje de solicitud de
configuración y transmite un mensaje de confirmación negativa de
configuración con una dirección IP arbitraria. La dirección
arbitraria puede ser la misma dirección de la iteración anterior o
puede ser una dirección diferente. El bucle creado por la serie de
bloques B310-B315-B320 se repite
hasta que el dispositivo MT2 104 determina que ha recibido una
dirección IP asignada por la IWF 108. Destinando y activando el
dispositivo TE2 102 para la generación de mensajes de solicitud de
configuración, el dispositivo MT2 104 impide que el dispositivo TE2
102 experimente tiempos de espera, permitiendo de ese modo el
mantenimiento de las negociaciones de direcciones IPCP. Asimismo,
es posible introducir un retardo en el bucle para reducir el número
de mensajes intercambiados entre el dispositivo MT2 104 y el
dispositivo TE2 102.
Haciendo referencia de nuevo al bloque B315, si
el dispositivo MT2 104 determina que ha recibido una dirección IP
asignada por la IWF 108, el dispositivo MT2 104 continúa por el
bloque B325, en el que transmite un mensaje de confirmación negativa
de configuración que contiene la dirección IP asignada al
dispositivo TE2 102 (véase referencia C). A continuación, el
dispositivo MT2 104 recibe, en el bloque B330, un mensaje de
solicitud de configuración con la dirección IP asignada desde el
dispositivo TE2 102 (véase referencia D).
El dispositivo MT2 104 prosigue con el bloque
B335, en el que transmite un mensaje de confirmación de
configuración al dispositivo TE2 102 para confirmar el mensaje de
solicitud de configuración del dispositivo TE2 102 (véase referencia
E). A continuación, en el bloque B340, el dispositivo MT2 104
transmite las opciones IPCP negociadas a través del enlace U_{m}
con la IWF 108 al dispositivo TE2 102 (véase referencia F).
Entonces, el dispositivo MT2 104 recibe, en el bloque B345, un
mensaje de confirmación de configuración desde el dispositivo TE2
104, en el que se confirman las opciones que están siendo utilizadas
por la dirección IP asignada por la IWF 108 (véase referencia G).
Debe observarse que los procesos de los bloques B340 y B345 no son
estrictamente necesarios, puesto que el dispositivo MT2 104 podría
enviar cualquier valor IPCP arbitrario al dispositivo TE2 102, dado
que todos los paquetes son sometidos a tramado y destramado a
través del dispositivo MT2 104.
Por lo tanto, con esta forma de realización es
posible evitar los tiempos de espera específicos de las
implementaciones, proporcionando al dispositivo TE2 102 mensajes de
confirmación negativa de configuración, que contienen direcciones IP
arbitrarias que serán rechazadas por el dispositivo MT2 104. Los
mensajes de confirmación negativa de configuración provocan la
generación de mensajes de solicitud de configuración por parte del
dispositivo TE2 102. Esta interacción se mantiene hasta que el
dispositivo MT2 104 recibe la dirección IP asignada por la IWF 108
y envía esta dirección IP al dispositivo TE2 102 en un mensaje de
confirmación negativa de configuración. De este modo, se impide que
el dispositivo TE2 102 efectúe una cancelación prematura debido a
los tiempos de espera específicos de las implementaciones, y se
permite el mantenimiento de las negociaciones PPP.
La descripción anterior de las formas de
realización preferidas de la presente invención es ilustrativa y
descriptiva y no pretende ser exhaustiva ni limitar la presente
invención a la forma precisa dada a conocer. La presente invención
admite modificaciones y variantes coherentes con la descripción
anterior o ideadas tras poner en práctica la presente invención. En
consecuencia, el alcance de la presente invención viene delimitado
por las reivindicaciones y sus equivalentes.
Claims (32)
1. Procedimiento para mantener negociaciones de
direcciones IP en una red de comunicación inalámbrica que implementa
el protocolo IPCP, que comprende:
la recepción, en un dispositivo de comunicación,
de un mensaje en el que se solicita una dirección IP a un
dispositivo terminal que contiene una dirección particular, estando
acoplado dicho dispositivo terminal a dicho dispositivo de
comunicación;
la generación, en dicho dispositivo de
comunicación, de un mensaje en el que se solicita una dirección IP
a dicha red de comunicación en respuesta a dicho mensaje de
solicitud de dirección IP; y
la determinación de la recepción o no por dicho
dispositivo de comunicación de una dirección IP asignada desde
dicha red de comunicación,
caracterizado porque
cuando se determina que dicho dispositivo de
comunicación no ha recibido dicha dirección IP asignada, dicho
dispositivo de comunicación transmite repetidamente un mensaje con
una dirección IP arbitraria a dicho dispositivo terminal para que
dicho dispositivo terminal responda transmitiendo mensajes de
solicitud de dirección IP que incluyen dicha dirección IP
arbitraria, y dicho dispositivo de comunicación rechaza dicha
dirección IP de dichos mensajes de solicitud de dirección IP hasta
que recibe dicha dirección IP asignada desde dicha red de
comunica-
ción.
ción.
2. Procedimiento según la reivindicación 1, en el
que dicha generación incluye:
el envío de dicho mensaje de solicitud de
dirección IP desde dicho dispositivo de comunicación hasta una
función de interfuncionamiento incluida en dicha red de
comunicación, y
la negociación con dicha función de
interfuncionamiento para obtener dicha dirección asignada basándose
en dicho mensaje de solicitud de dirección IP.
3. Procedimiento según la reivindicación 2, en el
que dicha determinación incluye:
la verificación de la provisión o no por dicha
función de interfuncionamiento de dicha dirección IP asignada en
respuesta a dichas negociaciones de dirección IP.
4. Procedimiento según la reivindicación 3, en el
que cuando se determina que dicho dispositivo de comunicación ha
recibido dicha dirección IP asignada, dicho dispositivo de
comunicación transmite un mensaje con dicha dirección IP asignada a
dicho dispositivo terminal.
5. Procedimiento según la reivindicación 4, en el
que, en respuesta a la transmisión de dicho mensaje de dirección IP
asignada a dicho dispositivo terminal, dicho dispositivo de
comunicación recibe un mensaje de solicitud de dirección IP con
dicha dirección IP asignada desde dicho dispositivo terminal.
6. Procedimiento según la reivindicación 5, en el
que, en respuesta a la recepción de dicho mensaje de solicitud de
dirección IP con dicha dirección IP asignada desde dicho
dispositivo terminal, dicho dispositivo de comunicación transmite un
mensaje en el que se confirma dicho mensaje de solicitud de
dirección IP a dicho dispositivo terminal.
7. Procedimiento según la reivindicación 6, en el
que, en respuesta a la transmisión de un mensaje en el que se
confirma dicho mensaje de solicitud de dirección IP a dicho
dispositivo terminal, dicho dispositivo de comunicación transmite un
mensaje con opciones de configuración de dicha función de
interfuncionamiento.
8. Procedimiento según la reivindicación 7, en el
que, en respuesta a la transmisión de dicho mensaje con opciones de
configuración de dicha función de interfuncionamiento, dicho
dispositivo de comunicación recibe un mensaje en el que se confirma
la recepción de dicha dirección IP asignada por dicho dispositivo
terminal a dicha función de interfuncionamiento.
9. Procedimiento según la reivindicación 8, en el
que dicho mensaje de solicitud de dirección IP es un mensaje de
solicitud de configuración IPCP.
10. Procedimiento según la reivindicación 9, en
el que dicho mensaje de dirección IP arbitraria es un mensaje de
confirmación negativa de configuración IPCP que contiene una de las
direcciones IP arbitrarias de una pluralidad, que será rechazada por
dicho dispositivo de comunicación.
11. Procedimiento según la reivindicación 10, en
el que dicha verificación de la asignación o no por dicha función de
interfuncionamiento de una dirección IP en respuesta a dicho
mensaje de solicitud de dirección IP se lleva a cabo determinando si
dicho dispositivo de comunicación ha recibido un mensaje de
confirmación de configuración IPCP que contiene una dirección IP
desde dicha función de interfuncionamiento.
12. Procedimiento según la reivindicación 11, en
el que dicho mensaje de dirección IP asignada es un mensaje de
confirmación negativa de configuración IPCP que contiene dicha
dirección IP asignada proporcionada por dicha función de
interfuncionamiento.
13. Procedimiento según la reivindicación 12, en
el que dicho mensaje de solicitud de dirección IP con dicha
dirección IP asignada es un mensaje de solicitud de configuración
IPCP que contiene dicha dirección IP asignada.
14. Procedimiento según la reivindicación 13, en
el que dicho mensaje en el que se confirma dicho mensaje de
solicitud de dirección IP con dicha dirección IP asignada es un
mensaje de confirmación de configuración IPCP.
15. Procedimiento según la reivindicación 14, en
el que dicho mensaje en el que se confirma dicha recepción de dicha
dirección IP asignada a dicha función de interfuncionamiento es un
mensaje de confirmación de configuración IPCP.
16. Procedimiento según la reivindicación 15, que
incluye además la introducción de un retardo de una duración
predeterminada para reducir el número de veces que dicho
dispositivo de comunicación transmite repetidamente dicho mensaje de
dirección IP arbitraria, y el número de veces que dicho dispositivo
terminal responde con dichos mensajes de solicitud de dirección IP
que contienen dicha dirección IP arbitraria.
17. Sistema (100) para mantener negociaciones de
direcciones IP en una red de comunicación inalámbrica que implementa
el protocolo IPCP, que comprende:
un dispositivo terminal (102) y
un dispositivo de comunicación (104) acoplado a
dicho dispositivo terminal (102), estando adaptado dicho
dispositivo de comunicación (104) para recibir un mensaje de
solicitud de dirección IP de dicho dispositivo terminal (102) que
contiene una dirección particular y, en respuesta, dicho
dispositivo de comunicación (104) está adaptado para transmitir un
mensaje de solicitud de dirección IP a dicha red de
comunicación;
en el que dicho dispositivo de comunicación (104)
está adaptado para determinar si ha recibido una dirección IP
asignada desde dicha red de comunicación, y está
caracterizado porque
si se determina que dicho dispositivo de
comunicación (104) no ha recibido dicha dirección IP asignada,
dicho dispositivo de comunicación (104) está adaptado para
transmitir repetidamente un mensaje con una dirección IP arbitraria
a dicho dispositivo terminal (102), hecho que determina la
transmisión por dicho dispositivo terminal (102) de mensajes de
solicitud de dirección IP que incluyen dicha dirección IP
arbitraria, y dicho dispositivo de comunicación está adaptado para
rechazar dicha dirección IP arbitraria de dichos mensajes de
solicitud de dirección IP hasta que dicho dispositivo de
comunicación (104) reciba dicha dirección IP asignada desde dicha
red de comunicación.
18. Sistema según la reivindicación 17, en el que
dicha red de comunicación inalámbrica comprende una función de
interfuncionamiento (108) y dicho dispositivo de comunicación (104)
adaptado para transmitir un mensaje de solicitud de dirección IP a
dicha red de comunicación incluye:
medios para enviar dicho mensaje de solicitud de
dirección IP desde dicho dispositivo de comunicación (104) hasta
dicha función de interfuncionamiento (108), y
medios para negociar con dicha función de
interfuncionamiento (108) y obtener dicha dirección asignada
basándose en dicho mensaje de solicitud de dirección IP.
19. Sistema según la reivindicación 18, en el que
dicho dispositivo de comunicación (104) está adaptado para
determinar si ha recibido una dirección IP asignada desde dicha red
de comunicación, verificando si dicha función de interfuncionamiento
(108) ha proporcionado dicha dirección IP asignada en respuesta a
dichas negociaciones de dirección IP.
20. Sistema según la reivindicación 19, en el
que, cuando se determina que dicho dispositivo de comunicación (104)
ha recibido dicha dirección IP asignada, dicho dispositivo de
comunicación (104) está adaptado para transmitir un mensaje con
dicha dirección IP asignada a dicho dispositivo terminal (102).
21. Sistema según la reivindicación 20, en el
que, en respuesta a la transmisión de dicho mensaje de dirección IP
asignada a dicho dispositivo terminal (102) dicho dispositivo de
comunicación (104) está adaptado para recibir un mensaje de
solicitud de dirección IP con dicha dirección IP asignada desde
dicho dispositivo terminal
(102).
(102).
22. Sistema según la reivindicación 21, en el
que, en respuesta a la recepción de dicho mensaje de solicitud de
dirección IP con dicha dirección IP asignada desde dicho
dispositivo terminal (102), dicho dispositivo de comunicación (104)
está adaptado para transmitir un mensaje en el que se confirma
dicho mensaje de solicitud de dirección IP a dicho dispositivo
terminal (102).
23. Sistema según la reivindicación 22, en el
que, en respuesta a la transmisión de un mensaje que confirma dicho
mensaje de solicitud de dirección IP a dicho dispositivo terminal
(102), dicho dispositivo de comunicación (104) está adaptado para
transmitir un mensaje con opciones de configuración de dicha
función de interfuncionamiento (108).
24. Sistema según la reivindicación 23, en el
que, en respuesta a la transmisión de dicho mensaje con opciones de
configuración de dicha función de interfuncionamiento (108), dicho
dispositivo de comunicación (104) está adaptado para recibir un
mensaje que confirma la recepción de dicha dirección IP asignada
por dicho dispositivo terminal (102) a dicha función de
interfuncionamiento (108).
25. Sistema según la reivindicación 24, en el que
dicho mensaje de solicitud de dirección IP es un mensaje de
solicitud de configuración IPCP.
26. Sistema según la reivindicación 25, en el que
dicho mensaje de dirección IP arbitraria es un mensaje de
confirmación negativa de configuración IPCP que contiene una
dirección IP arbitraria de una pluralidad, que será rechazada por
dicho dispositivo de comunicación (104).
27. Sistema según la reivindicación 26, en el que
dicha verificación de la asignación o no por dicha función de
interfuncionamiento (108) de una dirección IP en respuesta a dicho
mensaje de solicitud de dirección IP se lleva a cabo determinando si
dicho dispositivo de comunicación (104) ha recibido un mensaje de
confirmación de configuración IPCP que contiene una dirección IP
desde dicha función de interfuncionamiento (108).
28. Sistema según la reivindicación 27, en el que
dicho mensaje de dirección IP asignada es un mensaje de confirmación
negativa de configuración IPCP que contiene dicha dirección IP
asignada proporcionada por dicha función de interfuncionamiento
(108).
29. Sistema según la reivindicación 28, en el que
dicho mensaje de solicitud de dirección IP con dicha dirección IP
asignada es un mensaje de solicitud de configuración IPCP que
contiene dicha dirección IP asignada.
30. Sistema según la reivindicación 29, en el que
dicho mensaje en el que se confirma dicho mensaje de solicitud de
dirección IP con dicha dirección IP asignada es un mensaje de
confirmación de configuración IPCP.
31. Sistema según la reivindicación 30, en el que
dicho mensaje en el que se confirma dicha recepción de dicha
dirección IP asignada a dicha función de interfuncionamiento (108)
es un mensaje de confirmación de configuración IPCP.
32. Sistema según la reivindicación 31, en el que
se introduce un retardo de una duración predeterminada para reducir
el número de veces que dicho dispositivo de comunicación (104) está
adaptado para transmitir repetidamente dicho mensaje de dirección
IP arbitraria, y el número de veces que dicho dispositivo terminal
está adaptado para responder con dichos mensajes de solicitud de
dirección IP que contienen dicha dirección IP arbitraria.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US483351 | 2000-01-14 | ||
| US09/483,351 US6775553B1 (en) | 2000-01-14 | 2000-01-14 | Method of avoiding PPP time-outs during IPCP negotiations |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2244630T3 true ES2244630T3 (es) | 2005-12-16 |
Family
ID=23919706
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES01942488T Expired - Lifetime ES2244630T3 (es) | 2000-01-14 | 2001-01-12 | Procedimiento para evitar tiempos de espera ppp durante negociaciones ipcp. |
Country Status (11)
| Country | Link |
|---|---|
| US (2) | US6775553B1 (es) |
| EP (1) | EP1247385B1 (es) |
| JP (1) | JP4741145B2 (es) |
| KR (1) | KR100748814B1 (es) |
| CN (1) | CN1183733C (es) |
| AT (1) | ATE299328T1 (es) |
| AU (1) | AU2937501A (es) |
| CA (1) | CA2397619A1 (es) |
| DE (1) | DE60111823T2 (es) |
| ES (1) | ES2244630T3 (es) |
| WO (1) | WO2001052499A2 (es) |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7412528B2 (en) * | 2000-01-14 | 2008-08-12 | Qualcomm, Incorporated | Avoiding PPP time-outs during IPCP negotiations |
| US6775553B1 (en) * | 2000-01-14 | 2004-08-10 | Qualcomm Incorporated | Method of avoiding PPP time-outs during IPCP negotiations |
| FI109950B (fi) | 2000-01-20 | 2002-10-31 | Nokia Corp | Osoitteen saanti |
| US6684256B1 (en) * | 2000-01-27 | 2004-01-27 | Utstarcom, Inc. | Routing method for mobile wireless nodes having overlapping internet protocol home addresses |
| US7571308B1 (en) * | 2000-06-28 | 2009-08-04 | Microsoft Corporation | Method for controlling access to a network by a wireless client |
| FI112150B (fi) * | 2000-07-24 | 2003-10-31 | Stonesoft Oyj | Tietoliikenteen ohjausmenetelmä |
| JP3534185B2 (ja) * | 2000-10-27 | 2004-06-07 | 日本電気株式会社 | 無線通信システム及びその通信方法 |
| KR100678231B1 (ko) * | 2000-12-20 | 2007-02-01 | 삼성전자주식회사 | 이동통신단말기의 패킷 데이터 처리 장치 및 방법 |
| US20020142765A1 (en) * | 2001-03-30 | 2002-10-03 | Rhoads Monte J. | Network appliance wireless configuration interface |
| US7512133B2 (en) * | 2001-12-03 | 2009-03-31 | International Business Machines Corporation | Method and apparatus for obtaining multiple port addresses by a fibre channel from a network fabric |
| US20030158959A1 (en) * | 2002-02-15 | 2003-08-21 | Jay Jayapalan | Establishment of communications using point to point protocols such that duplicate negotiations are avoided |
| US7590408B2 (en) * | 2002-04-03 | 2009-09-15 | Qualcomm Incorporated | Systems and methods for early determination of network support for mobile IP |
| US7342894B2 (en) | 2002-04-03 | 2008-03-11 | Qualcomm Incorporated | System and method for transparent Mobile IP registration within PPP negotiation |
| US6973088B2 (en) * | 2002-04-03 | 2005-12-06 | Qualcomm Incorporated | PPP link negotiation in mobile IP systems |
| KR100463820B1 (ko) * | 2002-10-01 | 2004-12-29 | 에스케이 텔레콤주식회사 | 무선데이터 초기접속 지연 개선방법 |
| CN1306762C (zh) * | 2004-01-18 | 2007-03-21 | 中兴通讯股份有限公司 | Wlan融合cdma2000用户跨网切换时保持ip地址不变的方法 |
| JP3959402B2 (ja) * | 2004-03-19 | 2007-08-15 | 株式会社日立コミュニケーションテクノロジー | 通信接続装置及び通信端末ならびにこれを用いた通信方法 |
| CN100589374C (zh) * | 2004-07-08 | 2010-02-10 | 中兴通讯股份有限公司 | 一种使用点到点协议时防止ip地址泄漏的方法 |
| US7609700B1 (en) * | 2005-03-11 | 2009-10-27 | At&T Mobility Ii Llc | QoS channels for multimedia services on a general purpose operating system platform using data cards |
| CN100389616C (zh) * | 2005-03-18 | 2008-05-21 | 华为技术有限公司 | 实现交互功能业务数据交互的方法 |
| KR101019943B1 (ko) | 2005-12-01 | 2011-03-09 | 퀄컴 인코포레이티드 | 상이한 인증 인증서들을 지원하는 방법 및 장치 |
| US20080016248A1 (en) * | 2006-07-14 | 2008-01-17 | George Tsirtsis | Method and apparatus for time synchronization of parameters |
| CN101646205B (zh) * | 2008-08-05 | 2014-07-09 | 华为技术有限公司 | 移动网络高速接入公网的节点、方法及系统 |
| US8537762B2 (en) | 2009-04-27 | 2013-09-17 | Qualcomm Incorporated | System and method for optimally transferring data traffic on networks |
| US8769367B2 (en) * | 2010-01-28 | 2014-07-01 | Mediatek Inc. | Apparatus, method, and system for IP address negotiations |
| US8971885B2 (en) | 2011-11-02 | 2015-03-03 | Qualcomm Incorporated | Methods and devices for facilitating access terminal registrations |
| US10271274B2 (en) * | 2012-02-03 | 2019-04-23 | Qualcomm Incorporated | Devices and methods for facilitating extended time periods for maintaining PPP sessions |
| EP2879461B1 (en) * | 2012-08-02 | 2019-01-09 | Huawei Technologies Co., Ltd. | Protocol processing method under control and data forwarding decoupling |
| US9191209B2 (en) * | 2013-06-25 | 2015-11-17 | Google Inc. | Efficient communication for devices of a home network |
| WO2015090451A1 (en) * | 2013-12-20 | 2015-06-25 | Telefonaktiebolaget L M Ericsson (Publ) | Allocation of resources during split brain conditions |
| WO2018210139A1 (zh) * | 2017-05-18 | 2018-11-22 | 苏州欧普照明有限公司 | 无线网络节点的配置方法、装置及系统 |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6205490B1 (en) * | 1995-07-05 | 2001-03-20 | Siemens Aktiengesellschaft | System (IWF) for the bidirectional connection of an ELAN and a CLS wide-area network |
| KR100201902B1 (ko) * | 1996-04-04 | 1999-06-15 | 류정열 | 자동차 휠 조타상태 표시장치 |
| US5708655A (en) * | 1996-06-14 | 1998-01-13 | Telefonaktiebolaget L M Ericsson Publ | Method and apparatus for addressing a wireless communication station with a dynamically-assigned address |
| KR100260516B1 (ko) * | 1997-04-01 | 2000-07-01 | 정선종 | 코드분할 다중접속 이동통신망에서의 비동기통신 데이터발신호 및 착신호 서비스 방법 |
| JP3045985B2 (ja) * | 1997-08-07 | 2000-05-29 | インターナショナル・ビジネス・マシーンズ・コーポレイション | 接続確立方法、通信方法、状態変化伝達方法、状態変化実行方法、無線装置、無線デバイス、及びコンピュータ |
| US6061739A (en) * | 1997-11-26 | 2000-05-09 | International Business Machines Corp. | Network address assignment using physical address resolution protocols |
| FI105976B (fi) | 1998-02-09 | 2000-10-31 | Nokia Networks Oy | Matkaviestimen suurinopeuksinen liityntä TCP/IP-verkkoon |
| US6212563B1 (en) * | 1998-10-01 | 2001-04-03 | 3Com Corporation | Method and system for setting and managing externally provided internet protocol addresses using the dynamic host configuration protocol |
| US6483822B1 (en) | 1999-06-07 | 2002-11-19 | Marcello Lioy | Establishing a packet network call between a mobile terminal device and an interworking function |
| US6775553B1 (en) * | 2000-01-14 | 2004-08-10 | Qualcomm Incorporated | Method of avoiding PPP time-outs during IPCP negotiations |
| US7412528B2 (en) * | 2000-01-14 | 2008-08-12 | Qualcomm, Incorporated | Avoiding PPP time-outs during IPCP negotiations |
| US6988236B2 (en) * | 2000-04-07 | 2006-01-17 | Broadcom Corporation | Method for selecting frame encoding parameters in a frame-based communications network |
| US20020107514A1 (en) * | 2000-04-27 | 2002-08-08 | Hooven Michael D. | Transmural ablation device with parallel jaws |
| US7447182B2 (en) * | 2001-04-06 | 2008-11-04 | Nortel Networks Limited | Discovering an address of a name server |
| KR100471615B1 (ko) | 2001-11-07 | 2005-03-08 | 유티스타콤코리아 유한회사 | Ｒａｄｉｕｓ 서버를 이용한 인터넷 서비스 프로바이더가입자의 아이피 주소 관리 시스템 및 그 방법 |
| US7342894B2 (en) * | 2002-04-03 | 2008-03-11 | Qualcomm Incorporated | System and method for transparent Mobile IP registration within PPP negotiation |
-
2000
- 2000-01-14 US US09/483,351 patent/US6775553B1/en not_active Expired - Lifetime
-
2001
- 2001-01-12 KR KR1020027009047A patent/KR100748814B1/ko not_active Expired - Fee Related
- 2001-01-12 CN CNB018062989A patent/CN1183733C/zh not_active Expired - Fee Related
- 2001-01-12 WO PCT/US2001/000942 patent/WO2001052499A2/en not_active Ceased
- 2001-01-12 JP JP2001552598A patent/JP4741145B2/ja not_active Expired - Fee Related
- 2001-01-12 EP EP01942488A patent/EP1247385B1/en not_active Expired - Lifetime
- 2001-01-12 AU AU29375/01A patent/AU2937501A/en not_active Abandoned
- 2001-01-12 ES ES01942488T patent/ES2244630T3/es not_active Expired - Lifetime
- 2001-01-12 CA CA002397619A patent/CA2397619A1/en not_active Abandoned
- 2001-01-12 DE DE60111823T patent/DE60111823T2/de not_active Expired - Lifetime
- 2001-01-12 AT AT01942488T patent/ATE299328T1/de not_active IP Right Cessation
-
2008
- 2008-06-20 US US12/143,112 patent/US8086748B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US8086748B2 (en) | 2011-12-27 |
| KR20020082842A (ko) | 2002-10-31 |
| EP1247385A2 (en) | 2002-10-09 |
| EP1247385B1 (en) | 2005-07-06 |
| WO2001052499A2 (en) | 2001-07-19 |
| DE60111823T2 (de) | 2006-04-20 |
| DE60111823D1 (de) | 2005-08-11 |
| JP2003520501A (ja) | 2003-07-02 |
| US20090040988A1 (en) | 2009-02-12 |
| CN1416635A (zh) | 2003-05-07 |
| CA2397619A1 (en) | 2001-07-19 |
| ATE299328T1 (de) | 2005-07-15 |
| JP4741145B2 (ja) | 2011-08-03 |
| US6775553B1 (en) | 2004-08-10 |
| CN1183733C (zh) | 2005-01-05 |
| AU2937501A (en) | 2001-07-24 |
| KR100748814B1 (ko) | 2007-08-13 |
| WO2001052499A3 (en) | 2002-01-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2244630T3 (es) | Procedimiento para evitar tiempos de espera ppp durante negociaciones ipcp. | |
| CN110035042B (zh) | 一种数据传输方法及装置 | |
| ES2273665T3 (es) | Invocacion automatica de un registro ip movil en una red de comunicacion inalambrica. | |
| ES2226336T3 (es) | Metodo y dispositivo para configurar un enlace. | |
| ES2550031T3 (es) | Arquitecturas de MAC de comunicaciones inalámbricas utilizando múltiples capas físicas | |
| US6539030B1 (en) | Method and apparatus for providing configurable layers and protocols in a communications system | |
| ES2927063T3 (es) | Intercambio de mensajes para dispositivos ponibles | |
| CN110475267A (zh) | 一种配置方法、数据传输方法和装置 | |
| CN1744547B (zh) | 无线网络中的软垂直切换方法 | |
| WO2020164596A1 (zh) | 一种数据传输方法及装置 | |
| EP3402307B1 (en) | Method, protocol stack, terminal, and network device for establishing communication link | |
| RU2304854C2 (ru) | Способ определения согласованных вариантов конфигурации для линии радиосвязи, использующей сетевую модель | |
| CN113727368B (zh) | 一种通信方法及装置 | |
| US11470661B2 (en) | Backhaul channel management for IAB networks | |
| US20240214874A1 (en) | Communication method, apparatus, and system | |
| ES2341457T3 (es) | Mantenimiento y aplicacion selectiva de compresion del ppp en un sistema de comunicacion inalambrica. | |
| JP3889602B2 (ja) | 基地局とアクセスネットワークコントローラとの間の無線リンクを確立する方法 | |
| ES2264217T3 (es) | Negociacion de compresion de datos en un sistema de telecomunicaciones. | |
| CN112470544A (zh) | 终端装置、基站装置以及方法 | |
| CN117121627A (zh) | 一种无线通信方法及装置、终端设备 | |
| EP4213536A1 (en) | Communication method and related device | |
| CN112040565B (zh) | 移动通信系统、方法及装置 | |
| CN111698731B (zh) | 协议实体建立、数据缓存方法及其装置、设备、存储介质 | |
| JP3959402B2 (ja) | 通信接続装置及び通信端末ならびにこれを用いた通信方法 | |
| KR20220070494A (ko) | 통신 방법, 장치 및 시스템 |