ES2251389T3 - Procedimiento y aparato para evitar la perdida de datos durante una renegociacion ppp en una interfaz um. - Google Patents

Procedimiento y aparato para evitar la perdida de datos durante una renegociacion ppp en una interfaz um.

Info

Publication number
ES2251389T3
ES2251389T3 ES00948711T ES00948711T ES2251389T3 ES 2251389 T3 ES2251389 T3 ES 2251389T3 ES 00948711 T ES00948711 T ES 00948711T ES 00948711 T ES00948711 T ES 00948711T ES 2251389 T3 ES2251389 T3 ES 2251389T3
Authority
ES
Spain
Prior art keywords
interface
communication device
wireless communication
ppp
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.)
Expired - Lifetime
Application number
ES00948711T
Other languages
English (en)
Inventor
Nischal Abrol
Marcello Lioy
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Application granted granted Critical
Publication of ES2251389T3 publication Critical patent/ES2251389T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/10Flow control between communication endpoints
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W92/00Interfaces specially adapted for wireless communication networks
    • H04W92/04Interfaces between hierarchically different network devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Abstract

Procedimiento para prevenir la pérdida de datos durante una renegociación PPP en una interfaz Um inalámbrica, comprendiendo dicho procedimiento: ¿ determinar, en un dispositivo de comunicación inalámbrica (MT2, 104), si dicha renegociación PPP se está llevando a cabo en dicha interfaz Um; y ¿ ejercer (S320, S550) el control del flujo de datos que van a transmitirse desde un dispositivo de terminal móvil (TE2, 102) hasta dicho dispositivo de comunicación inalámbrica (MT2, 104), a través de una interfaz Rm, cuando en dicha etapa de determinación se determina que dicha renegociación PPP se está llevando a cabo en dicha interfaz Um.

Description

Procedimiento y aparato para evitar la pérdida de datos durante una renegociación PPP en una interfaz U_{m}.
Antecedentes de la invención I. Campo de la invención
La presente invención se refiere al campo de los servicios inalámbricos de datos. Más particularmente, la presente invención se refiere a un procedimiento y un sistema novedoso y mejorado para prevenir la pérdida de datos durante una renegociación de protocolo punto a punto (PPP), a través de una interfaz U_{m}, entre un dispositivo de comunicación inalámbrica (MT2) y una estación base/centro de conmutación móvil (BS/MSC).
II. Descripción de la técnica relacionada
El funcionamiento entre redes, es decir, la conexión de redes de área local individuales (LAN), ha adquirido gran popularidad en poco tiempo. La infraestructura y los protocolos asociados, denominados comúnmente "Internet", son muy conocidos y ampliamente utilizados. Un protocolo muy conocido para proporcionar acceso a Internet es el protocolo punto a punto (PPP) que proporciona un procedimiento normalizado para transportar datagramas multiprotocolo a través de un enlace punto a punto, descrito en el documento "Request for Comment (RFC) 1661", W. Simpson Editor, presentado en julio de 1994.
El protocolo PPP incluye tres componentes principales:
1.
un procedimiento para encapsular datagramas multiprotocolo;
2.
un protocolo de control de enlace (LCP) para establecer, configurar y comprobar una conexión de enlace de datos y
3.
una familia de protocolos de control de red (NCP) para establecer y configurar diferentes protocolos de capa de red.
La Figura 1 ilustra un diagrama de bloques de alto nivel de un sistema de comunicación inalámbrica de datos, en el que un terminal móvil (TE2) 102 se comunica con una función de interfuncionamiento (IWF) 108, por medio de un sistema de comunicación inalámbrica que incluye un dispositivo de comunicación inalámbrica (MT2) 104 y una estación base/centro de conmutación móvil (BS/MSC) 106. En la Figura 1, la IWF 108 constituye el punto de acceso a Internet. La IWF 108 se acopla con la BS/MSC 106 (que puede ser una estación base inalámbrica convencional como las conocidas en la técnica) y a menudo presenta el mismo emplazamiento que ésta. El dispositivo TE2 102 se acopla al dispositivo MT2 104, que establece comunicaciones inalámbricas con la BS/MSC 106 y la IWF 108.
Existen muchos protocolos que permiten la transmisión de datos entre el dispositivo TE2 102 y la IWF 108. Por ejemplo, la regla provisional IS-707.5 de Telecommunications Industry Association (TIA)/Electronics Industries Association (EIA), titulada "Data Service Options for Wideband Spread Spectrum Systems: Packet Data Services", publicada en febrero de 1998, define los requisitos para admitir la capacidad de transmisión de datos en paquetes en los sistemas de espectro ensanchado de banda ancha TIA/EIA IS-95, de los cuales la BS/MSC 106 y la IWF 108 pueden formar parte. La regla IS-707.5 indica también los requisitos para los protocolos de comunicación de los enlaces entre el dispositivo TE2 102 y el dispositivo MT2 104 (la interfaz R_{m}), entre el dispositivo MT2 104 y la BS/MSC 106 (la interfaz U_{m}) y entre la BS/MSC 106 y la IWF 108 (la interfaz L).
Haciendo referencia a la Figura 2, se representa un diagrama de las pilas de protocolos de cada entidad del modelo de transmisión IS-707.5. La Figura 2 corresponde aproximadamente a la Figura 1.4.2.2-1 de la regla IS-707.5. En el lado izquierdo de la Figura, se representa una pila de protocolos, en el formato vertical convencional, en la que se muestran las capas de protocolo que se ejecutan en el dispositivo TE2 102 (p. ej., el terminal móvil o un ordenador portátil o de bolsillo). La pila de protocolos del dispositivo 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}. La pila de protocolos de la BS/MSC 106 ilustrada, a su vez, está conectada lógicamente a la pila de protocolos de la IWF 108 a través de la interfaz L.
Como ejemplo del funcionamiento de los protocolos de la Fig. 2, el protocolo punto a punto (PPP_{R}) 206 codifica los paquetes de los protocolos de capa superior 202, 204 y los transmite, a través de la interfaz R_{m} y mediante el protocolo EIA-232 208, a la puerta compatible con la regla EIA-232 del dispositivo MT2 que ejecuta el protocolo EIA-232 210. Aparte del protocolo EIA-232, pueden utilizarse otros protocolos (por ejemplo, el protocolo USB/IrDA/Bluetooth). El protocolo EIA-232 210 del dispositivo MT2 recibe los paquetes y los pasa al protocolo PPP_{R} 205. El protocolo PPP_{R} 205 efectúa el destramado de los paquetes encapsulados en tramas PPP y, habitualmente, cuando se ha establecido una conexión de datos, pasa los paquetes al protocolo PPP_{U} 215 que efectúa el tramado de los paquetes en tramas PPP para la transmisión a su par PPP situado en la IWF (108). El protocolo de enlace de radio (RLP) 212 y el protocolo IS-95 214, ambos de los cuales son muy conocidos en la técnica, se utilizan para transmitir a la BS/MSC 106 los paquetes, que se encapsulan en tramas PPP, a través de la interfaz U_{m}. El RLP consiste en realidad en una familia de protocolos de enlace de radio. El protocolo RLP 212 se define en la regla IS-707.2, titulada "Data Service Options for Wideband Spread Spectrum Systems: Radio Link Protocol", febrero de 1998, y el protocolo IS-95 se define en la regla IS-95 mencionada anteriormente. El protocolo RLP 216 y el protocolo IS-95 218 complementarios de la BS/MSC 106 pasan los paquetes al protocolo de capa de transporte 220 para la transmisión, a través de la interfaz L, al protocolo de la capa de transporte 228. A continuación, el protocolo PPP_{U} 226 efectúa el destramado de los paquetes recibidos y los pasa a los protocolos de la capa de red 225 que, a su vez, los pasan a los protocolos de capa superior 221. Como bien saben los expertos en la materia, en lugar del protocolo RLP, es posible utilizar el protocolo RLP2, definido en la regla provisional IS-707A.8 de Telecommunications Industry Association (TIA)/Electronics Industries Association (EIA), titulada "Data Service Options for Spread Spectrum Systems: Radio Link Protocol Type 2", publicada en abril de 1999. Otros protocolos RLP que pueden utilizarse son el protocolo RLP3 y el protocolo RLP para CDMA2000.
Como se describe en el documento RFC 1661, los paquetes LCP comprenden una petición de configuración, un ACK (acuse de recibo) de configuración, un NAK (acuse de recibo negativo) de configuración y un rechazo de configuración. El formato de estos paquetes es muy conocido y se describe en el documento RFC 1661.
El paquete de petición de configuración se utiliza para negociar las opciones de configuración. Todas las opciones de configuración se negocian siempre de forma simultánea.
El paquete de ACK de configuración se transmite si todas las opciones de configuración del paquete de petición de configuración recibido son reconocibles y todos los valores son aceptables.
El paquete de NAK de configuración se envía en respuesta a un paquete de petición de configuración, cuando las opciones de configuración solicitadas son reconocibles, pero algunos de los valores no son aceptables. El campo Opciones del paquete de NAK de configuración se rellena sólo con las opciones de configuración inaceptables del paquete de petición de configuración. Debe observarse que siempre se efectúa un NAK simultáneo de todas las opciones de configuración.
El paquete de rechazo de configuración se envía cuando la petición de configuración recibida incluye opciones de configuración que no son reconocibles o que no son aceptables para la negociación. El campo Opciones de rechazo de configuración contiene sólo las opciones de configuración inaceptables de petición de configuración.
La lista siguiente comprende las conocidas opciones de configuración descritas en el documento RFC 1661 y definidas para el protocolo PPP LCP:
1. Unidad máxima de recepción
2. Protocolo de autenticación
3. Protocolo de calidad
4. Número mágico
5. Compresión del campo Protocolo
6. Compresión de los campos Dirección y Control.
El protocolo de control de protocolo Internet (IPCP) es un protocolo de control de red encargado de configurar, habilitar e inhabilitar módulos de protocolo Internet (IP) en ambos extremos del enlace PPP. El protocolo IPCP se describe en el documento RFC (Request for Comment) 1332, titulado "The PPP Internet Protocol Control Protocol (IPCP)", de G. McGregor Merit, mayo de 1992. Las opciones de configuración IPCP incluyen:
1. Direcciones IP
2. Protocolo de compresión IP
3. Dirección IP
El protocolo IPCP utiliza el mismo mecanismo de negociación de opciones que el protocolo de control de enlace (LCP).
Las negociaciones de opciones de configuración LCP e IPCP tienen lugar por separado para la interfaz R_{m} y la interfaz U_{m}. Es decir, la negociación de opciones de configuración LCP o IPCP a través de una de las interfaces R_{m} o U_{m} es independiente de la negociación de opciones de configuración LCP o IPCP a través de la otra de las interfaces R_{m} o U_{m}. Por consiguiente, el dispositivo de comunicación inalámbrica (MT2) debe negociar por separado las opciones de configuración a través de las interfaces R_{m} y U_{m}. Debido a que el dispositivo de comunicación inalámbrica (MT2) es móvil, el dispositivo de comunicación inalámbrica (MT2) puede desplazarse hasta un área que es servida por una IWF 108 diferente. Cuando sucede esto, se produce una transferencia, en el que el dispositivo MT2 cambia a una nueva IWF 108 desde la cual recibirá el servicio. Cuando se produce una transferencia, los enlaces LCP e IPCP deben renegociarse a través de la interfaz U_{m}, de la forma indicada más arriba. Debido a que la negociación PPP para las interfaces R_{m} y U_{m} es independiente, sólo es necesario que la renegociación PPP tenga lugar en la interfaz U_{m}.
Durante la renegociación PPP de la interfaz U_{m}, los datos no pueden transferirse a través de la interfaz U_{m}, no obstante, el dispositivo TE2 puede continuar enviando datos al dispositivo MT2 a través de la interfaz R_{m}. De esta forma, el dispositivo MT2 puede recibir datos a través de la interfaz R_{m}, aunque es incapaz de enviar los datos a través de la interfaz U_{m}. Si la renegociación PPP se prolonga durante mucho tiempo, el dispositivo MT2 se verá incapaz de procesar los datos que reciba a través de la interfaz R_{m} y se producirá una pérdida de datos.
Sumario de la invención
Una primera forma de realización de la presente invención consiste en un procedimiento y un dispositivo de comunicación inalámbrica (MT2) 104 capaces de controlar el flujo de los datos que se van a enviar desde el dispositivo TE2 102, a través de la interfaz R_{m}, cuando se está llevando a cabo la renegociación PPP a través de la interfaz U_{m}. El control del flujo puede ser ejercido por el dispositivo MT2 104 por medio de la manipulación de la señalización eléctrica de una interfaz física entre el dispositivo MT2 104 y el dispositivo TE2 102 o utilizando el control de flujo software XON/XOFF.
Una segunda forma de realización de la presente invención consiste en un procedimiento y un dispositivo de comunicación inalámbrica (MT2) 104 para almacenar temporalmente los datos recibidos desde el dispositivo TE2 102 en el dispositivo MT2 104 durante la renegociación PPP de la interfaz U_{m}.
Una tercera forma de realización de la presente invención consiste en un procedimiento y un dispositivo de comunicación inalámbrica (MT2) 104 para almacenar temporalmente los datos en el dispositivo MT2 104 cuando se está llevando a cabo la renegociación PPP de la interfaz U_{m}. Cuando en la memoria tampón queda una cantidad de espacio libre inferior a un umbral predeterminado, el dispositivo MT2 104 ejerce el control del flujo para el dispositivo TE2 102. Cuando no se está llevando a cabo la renegociación PPP de la interfaz U_{m}, el control del flujo del dispositivo TE2 102 a través de la interfaz R_{m} es inhabilitado, lo cual permite el flujo de datos desde el dispositivo TE2 102 hasta el dispositivo MT2 104.
Por consiguiente, la presente invención proporciona un dispositivo de comunicación inalámbrica mejorado y un procedimiento mejorado para prevenir la pérdida de datos durante la renegociación PPP.
Breve descripción de los dibujos
Estas y otras ventajas se pondrán de manifiesto a partir de la siguiente descripción detallada de las formas de realización preferidas, considerada conjuntamente con los dibujos adjuntos:
la Figura 1 ilustra un diagrama de bloques de alto nivel de un sistema de comunicación inalámbrica de datos, en el que un dispositivo terminal se conecta a una red, tal como Internet, por medio de un dispositivo de comunicación inalámbrica;
la Figura 2 es un diagrama de las pilas de protocolos de cada entidad;
la Figura 3 es un diagrama de flujo de una primera forma de realización de la presente invención, en el que se representa el procesamiento que se produce cuando el dispositivo MT2 detecta que el estado de la interfaz U_{m} PPP ha cambiado;
la Figura 4 es un diagrama de flujo de una segunda forma de realización de la presente invención, en el que se representa el procesamiento que se produce cuando el dispositivo MT2 detecta que el estado de la interfaz U_{m} PPP ha cambiado; y
la Figura 5 es un diagrama de flujo de una variante de la segunda forma de realización, que representa el procesamiento que se produce para el control del flujo de un dispositivo TE2, basado en la cantidad de espacio libre disponible en la memoria tampón.
Descripción detallada de las formas de realización preferidas
Como bien se sabe en la técnica, para establecer las comunicaciones entre un enlace punto a punto (PPP), es necesario intercambiar paquetes del protocolo de control de enlace (LCP) a través de cada enlace PPP (es decir, las interfaces R_{m} y U_{m}) para establecer, configurar y comprobar la conexión del enlace de datos. Para las opciones no negociadas, se utiliza un valor por omisión predefinido especificado en el documento RFC 1661.
Del mismo modo, es necesario intercambiar paquetes IPCP a través de las interfaces R_{m} y U_{m} para negociar y configurar las opciones de configuración IPCP. Para las opciones no negociadas, se utiliza un valor por omisión predefinido especificado en el documento RFC 1332.
Como se describe en los documentos RFC 1661 y RFC 1332, los paquetes LCP y los paquetes IPCP comprenden una petición de configuración, una ACK de configuración, una NAK de configuración y un rechazo de configuración. El formato de estos paquetes es muy conocido y se describe en los documentos RFC 1661 y RFC 1332.
Las negociaciones de opciones de configuración pueden producirse por separado en la interfaz R_{m} y la interfaz U_{m}. Como se describe en los documentos RFC 1661 y RFC 1332, el paquete de petición de configuración contiene una lista de las opciones que se solicitan y el paquete de ACK de configuración contiene una lista de las opciones que son confirmadas por el emisor.
Debido a que el dispositivo de comunicación inalámbrica (MT2) 104 habitualmente es móvil, las comunicaciones entre el dispositivo MT2 104 y la IWF 108 se traspasarán a otra IWF 108 adecuada, dependiendo de la ubicación actual del dispositivo MT2 móvil. Las técnicas de transferencia son muy conocidas en el ámbito de la técnica. Cuando se produce una transferencia, la interfaz U_{m} PPP debe ser renegociada. Es decir, las opciones de configuración LCP e IPCP deben ser renegociadas. Durante la renegociación, no es posible enviar datos a través de la interfaz U_{m}. No obstante, debido a que la negociación de la interfaz U_{m} es independiente de la interfaz R_{m}, no es necesario someter la interfaz R_{m} a negociación después de una transferencia. Como consecuencia de esto, el dispositivo TE2 102 puede continuar enviando datos al dispositivo MT2 104, mientras que el dispositivo MT2 104 no puede enviar datos a través de la interfaz U_{m}, debido a que el dispositivo MT2 está ocupado con la renegociación PPP. Si la renegociación se prolonga durante demasiado tiempo mientras el dispositivo TE2 102 continúa enviando datos al dispositivo MT2 104 a través de la interfaz R_{m}, al final se produce una pérdida de datos.
La Figura 3 ilustra el procesamiento realizado en una primera forma de realización de la presente invención. El procesamiento puede ser implementado por medio de firmware o software, por ejemplo.
En la etapa S310, se comprueba el estado de la interfaz U_{m} PPP para determinar si se está llevando a cabo una renegociación. De ser así, en la etapa S320, se habilita el control del flujo en la interfaz R_{m} PPP, de tal forma que el dispositivo TE2 102 no podrá enviar datos al dispositivo MT2 104. El control del flujo puede realizarse, por ejemplo, mediante la desactivación por el dispositivo MT2 104 de la señal "Libre para envío" en una interfaz RS232 para el dispositivo TE2 102. Como bien se sabe en la técnica, un dispositivo tal como el TE2 102 no puede enviar datos a través de la interfaz RS232 cuando la señal Libre para envío está desactivada.
Si en la etapa 310, se determina que no se está llevando a cabo una renegociación en la interfaz U_{m} PPP, en la etapa S330, se inhabilita el control del flujo, es decir, no se ejerce el control del flujo de los datos originados en el dispositivo TE2 102. Esto puede realizarse, por ejemplo, mediante la activación por el dispositivo MT2 104 de la señal Libre para envío en una interfaz RS232 para el dispositivo TE2 102. Como bien se sabe en la técnica, un dispositivo tal como el TE2 102 sólo puede enviar datos a través de la interfaz RS232 cuando la señal Listo para envío está activada.
Una vez realizada cualquiera de las etapas S320 ó S330, el procesamiento normal continúa. En la Figura 4, se ilustra otra forma de realización de la presente invención. La etapa S410 se realiza para determinar si se está llevando a cabo una renegociación en la interfaz U_{m} PPP. De ser así, en la etapa S420, los datos recibidos a través de la interfaz R_{m} desde el dispositivo TE2 102 se almacenan en memoria tampón.
Si en la etapa S410 se determina que no se está llevando a cabo una renegociación a través de la interfaz U_{m} PPP, en la etapa S430, los datos recibidos desde la interfaz R_{m} no se almacenan en memoria tampón, sino que, en su lugar, se procesan para la subsiguiente transmisión a través de la interfaz U_{m} PPP. Además, en la etapa S430, los datos que ya se han recibido desde la interfaz R_{m} PPP y se han almacenado en la memoria tampón se retiran de la cola de la memoria tampón y se procesan para la subsiguiente transmisión a través de la interfaz U_{m} PPP.
Una vez realizadas cualquiera de las etapas S420 ó S430, el procesamiento normal continúa.
Sin el control del flujo del dispositivo TE2 102, en la forma de realización de la Figura 4, tal vez lo único que se consiga es retardar la pérdida de datos. Si la renegociación de la interfaz U_{m} PPP se prolonga el tiempo suficiente para que el espacio de la memoria tampón del dispositivo MT2 104 se agote, se producirá una pérdida de datos.
La Figura 5 representa una variante de la forma de realización de la Figura 4, que, además de realizar el procesamiento de la Figura 4, incluye también la determinación de la cantidad de espacio disponible en la memoria tampón y el correspondiente control del flujo. La etapa S510 se realiza para determinar si se está llevando a cabo una renegociación en la interfaz U_{m} PPP. De ser así, en la etapa S520, los datos recibidos a través de la interfaz R_{m} desde el dispositivo TE2 102 se almacenan en la memoria tampón.
En la etapa S530, se determina la cantidad de espacio libre de la memoria tampón. En la etapa S540, la cantidad de espacio libre de la memoria tampón se compara con un umbral. Si la cantidad de espacio libre de la memoria tampón es inferior al umbral, en la etapa S550, se habilita el control del flujo del dispositivo TE2 102 a través de la interfaz R_{m}, y el procesamiento vuelve a la etapa S510 para determinar si todavía se está llevando a cabo la renegociación en la interfaz U_{m} PPP.
Si en la etapa S540 se determina que la cantidad de espacio libre de la memoria tampón es superior o igual al umbral, el control del flujo no se habilita y el procesamiento vuelve a la etapa S510 para determinar si todavía se está llevando a cabo la renegociación en la interfaz U_{m} PPP.
Si en la etapa S510 se determina que no se está llevando a cabo una renegociación de la interfaz U_{m} PPP, en la etapa S560, se procesan los datos que se almacenaron previamente en la memoria tampón durante una renegociación de la interfaz U_{m} PPP. A continuación, se realiza la etapa S570 para asegurar que el control del flujo esté inhabilitado, y el procesamiento normal continúa.
El valor preferido del umbral depende de la implementación de hardware y software, y se tienen en cuenta factores que incluyen, pero no se limitan a, el tamaño de la memoria, la velocidad del procesador, la velocidad de transmisión de datos y la carga máxima de tráfico esperada, por ejemplo.
Aunque la presente invención se ha descrito haciendo referencia a las formas de realización que actualmente se consideran preferidas, debe sobreentenderse que la presente invención no se limita a las formas de realización dadas a conocer sino que, por el contrario, pretende abarcar diversas modificaciones y disposiciones equivalentes incluidas en el alcance de las reivindicaciones adjuntas.

Claims (16)

1. Procedimiento para prevenir la pérdida de datos durante una renegociación PPP en una interfaz U_{m} inalámbrica, comprendiendo dicho procedimiento:
\bullet
determinar, en un dispositivo de comunicación inalámbrica (MT2, 104), si dicha renegociación PPP se está llevando a cabo en dicha interfaz U_{m}; y
\bullet
ejercer (S320, S550) el control del flujo de datos que van a transmitirse desde un dispositivo de terminal móvil (TE2, 102) hasta dicho dispositivo de comunicación inalámbrica (MT2, 104), a través de una interfaz R_{m}, cuando en dicha etapa de determinación se determina que dicha renegociación PPP se está llevando a cabo en dicha interfaz U_{m}.
2. Procedimiento según la reivindicación 1, en el que dicha etapa de ejecución del control del flujo (S320) comprende:
\bullet
la utilización de señalización eléctrica en una interfaz de nivel físico entre dicho terminal móvil (TE2, 102) y dicho dispositivo de comunicación inalámbrica (MT2, 104) para ejercer dicho control del flujo.
3. Procedimiento según la reivindicación 2, en el que dicha señalización eléctrica comprende desactivar una señal Libre para envío en una interfaz RS232.
4. Procedimiento según la reivindicación 1, que comprende además:
\bullet
la inhabilitación de dicho control de flujo de dichos datos que se van a transmitir desde dicho terminal móvil (TE2, 102) hasta dicho dispositivo de comunicación inalámbrica (MT2, 104), a través de dicha interfaz R_{m}, cuando en dicha etapa de determinación se determina que dicha renegociación PPP no se está llevando a cabo en dicha interfaz U_{m}.
5. Procedimiento según la reivindicación 1, en el que dicha etapa de ejecución del control de flujo comprende:
\bullet
el almacenamiento temporal (S520), en dicho dispositivo de comunicación inalámbrica (MT2, 104), de los datos recibidos desde dicho terminal móvil (TE2, 102), a través de una interfaz R_{m}, cuando en dicha etapa de determinación se determina que dicha renegociación PPP se está llevando a cabo en dicha interfaz U_{m};
\bullet
la determinación (S540) de si la cantidad de espacio libre de la memoria tampón de dicho dispositivo de comunicación inalámbrica (MT2, 104) es inferior a un umbral predeterminado, y
\bullet
ejercer (S550) el control del flujo de los datos que se van a transmitir desde dicho terminal móvil (TE2, 102) hasta dicho dispositivo de comunicación inalámbrica (MT2, 104), a través de dicha interfaz R_{m}, cuando se determina que dicha cantidad de espacio libre de la memoria tampón es inferior a dicho umbral predeterminado.
6. Procedimiento según la reivindicación 5, en el que dicha etapa de ejecución del control de flujo comprende:
\bullet
la utilización de señalización eléctrica en una interfaz de nivel físico entre dicho terminal móvil (TE2, 102) y dicho dispositivo de comunicación inalámbrica (MT2, 104) para ejercer dicho control de flujo.
7. Procedimiento según la reivindicación 6, en el que dicha etapa de utilización de dicha señalización eléctrica comprende desactivar una señal Libre para envío en una interfaz RS232.
8. Procedimiento según la reivindicación 5, que comprende además:
\bullet
la inhabilitación (S570) de dicho control del flujo cuando en dicha etapa de determinación se determina que dicha renegociación PPP no se está llevando a cabo.
9. Dispositivo de comunicación inalámbrica (MT2, 104) dispuesto para conectarse a un terminal móvil (TE2, 102) a través de una interfaz R_{m}, y a una estación base/centro de conmutación móvil a través de una interfaz U_{m} inalámbrica, comprendiendo dicho dispositivo de comunicación inalámbrica (MT2, 104):
\bullet
medios para determinar si se está llevando a cabo una renegociación PPP en dicha interfaz U_{m}; y
\bullet
medios para ejercer el control del flujo de datos que se van a transmitir desde dicho terminal móvil (TE2, 102) hasta dicho dispositivo de comunicación inalámbrica (MT2, 104), a través de dicha interfaz R_{m}, cuando dichos medios de determinación determinan que dicha renegociación PPP se está llevando a cabo en dicha interfaz U_{m}.
10. Dispositivo de comunicación inalámbrica (MT2, 104) según la reivindicación 9, en el que dichos medios para ejercer el control del flujo de datos comprenden:
\bullet
medios para utilizar señalización eléctrica en una interfaz de nivel físico entre dicho dispositivo TE2 y dicho dispositivo de comunicación inalámbrica (MT2, 104) para ejercer dicho control de flujo.
11. Dispositivo de comunicación inalámbrica (MT2, 104) según la reivindicación 10, en el que dichos medios para utilizar señalización eléctrica comprenden medios para desactivar una señal Libre para envío en una interfaz RS232.
12. Dispositivo de comunicación inalámbrica (MT2, 104) según la reivindicación 9, que comprende además:
\bullet
medios para inhabilitar dicho control del flujo de dichos datos que se van a transmitir desde dicho dispositivo TE2 hasta dicho dispositivo de comunicación inalámbrica (MT2, 104), a través de dicha interfaz R_{m}, cuando dichos medios para determinar determinan que dicha renegociación PPP no se está llevando a cabo en dicha interfaz U_{m}.
13. Dispositivo de comunicación inalámbrica (MT2, 104) según la reivindicación 9, en el que dichos medios para ejercer el control del flujo comprenden además:
\bullet
medios para almacenar en memoria tampón los datos recibidos desde dicho terminal móvil (TE2, 102), a través de dicha interfaz R_{m}, cuando dichos medios para determinar determinan que dicha renegociación PPP se está llevando a cabo en dicha interfaz U_{m};
\bullet
medios para determinar si la cantidad de espacio libre de la memoria tampón del dispositivo de comunicación inalámbrica (MT2, 104) es inferior a un umbral predeterminado; y
\bullet
medios para ejercer el control del flujo de los datos que se van a transmitir desde dicho terminal móvil (TE2, 102) hasta dicho dispositivo de comunicación inalámbrica (MT2, 104), a través de dicha interfaz R_{m}, cuando dichos medios para determinar determinan que dicha cantidad de espacio libre de la memoria tampón es inferior a dicho umbral predeterminado.
14. Dispositivo de comunicación inalámbrica (MT2, 104) según la reivindicación 13, en el que dichos medios para ejercer el control del flujo de datos comprenden:
\bullet
medios para utilizar señalización eléctrica en una interfaz de nivel físico entre dicho terminal móvil (TE2, 102) y dicho dispositivo de comunicación inalámbrica (MT2, 104), para ejercer dicho control del flujo.
15. Dispositivo de comunicación inalámbrica (MT2, 104) según la reivindicación 14, en el que dichos medios para utilizar dicha señalización eléctrica comprenden medios para desactivar una señal Listo para envío en una interfaz RS232.
16. Dispositivo de comunicación inalámbrica (MT2, 104) según la reivindicación 13, que comprende además:
\bullet
medios para inhabilitar dicho control del flujo cuando dichos medios de determinación determinan que dicha renegociación PPP no se está llevando a cabo.
ES00948711T 1999-07-14 2000-07-14 Procedimiento y aparato para evitar la perdida de datos durante una renegociacion ppp en una interfaz um. Expired - Lifetime ES2251389T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US353108 1999-07-14
US09/353,108 US6463034B1 (en) 1999-07-14 1999-07-14 Method and apparatus for avoiding data loss during a PPP renegotiation on a Um interface

Publications (1)

Publication Number Publication Date
ES2251389T3 true ES2251389T3 (es) 2006-05-01

Family

ID=23387793

Family Applications (1)

Application Number Title Priority Date Filing Date
ES00948711T Expired - Lifetime ES2251389T3 (es) 1999-07-14 2000-07-14 Procedimiento y aparato para evitar la perdida de datos durante una renegociacion ppp en una interfaz um.

Country Status (16)

Country Link
US (1) US6463034B1 (es)
EP (1) EP1192825B1 (es)
JP (1) JP4680455B2 (es)
KR (1) KR100763082B1 (es)
CN (1) CN1168338C (es)
AT (1) ATE311731T1 (es)
AU (1) AU6217500A (es)
BR (1) BR0012376A (es)
CA (1) CA2379126C (es)
DE (1) DE60024453T2 (es)
ES (1) ES2251389T3 (es)
HK (1) HK1047375B (es)
IL (2) IL147577A0 (es)
MX (1) MXPA02000448A (es)
TW (1) TW494693B (es)
WO (1) WO2001005175A1 (es)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7656271B2 (en) 2002-01-09 2010-02-02 I.D. Systems, Inc. System and method for managing a remotely located asset
US7356494B2 (en) 1999-05-19 2008-04-08 I.D. Systems, Inc. Robust wireless communications system architecture and asset management applications performed thereon
AU5588000A (en) 1999-05-19 2000-12-05 Id Systems, Inc. Fully automated vehicle rental system
EP1109359A3 (en) * 1999-12-18 2003-04-02 Roke Manor Research Limited Congestion control for internet access
KR100612004B1 (ko) * 2000-04-06 2006-08-11 삼성전자주식회사 Bluetooth 무선 통신을 지원하는 통신장치에서의 수신 데이터 처리 방법
US6909714B2 (en) * 2001-07-03 2005-06-21 Qualcomm Incorporated Method and apparatus for determining configuration options negotiated for a communications link employing a network model
US7430602B2 (en) * 2002-12-20 2008-09-30 Qualcomm Incorporated Dynamically provisioned mobile station and method therefor
US7786844B2 (en) 2005-03-01 2010-08-31 I.D. Systems, Inc. Mobile portal for RFID applications
MX2007010584A (es) 2005-03-01 2008-03-19 I D Systems Inc Portal movil para aplicaciones rfid.
US7385947B2 (en) * 2005-05-04 2008-06-10 Nokia Corporation Low-cost radio access network enabling local switching
US7616566B2 (en) * 2006-04-28 2009-11-10 Samsung Electroncis Co., Ltd Data flow control apparatus and method of mobile terminal for reverse communication from high speed communication device to wireless network
JP4652276B2 (ja) * 2006-05-17 2011-03-16 富士通株式会社 通信システム及びそれに用いられる管理装置並びに中継装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI955944A (fi) * 1995-12-11 1997-06-12 Nokia Telecommunications Oy Nopeussovitusmenetelmä ja nopeussovitin
FI101332B1 (fi) * 1995-12-18 1998-05-29 Nokia Telecommunications Oy Epäjatkuvalähetys monikanavaisessa suurinopeuksisessa datasiirrossa
FI100567B (fi) * 1996-01-08 1997-12-31 Nokia Telecommunications Oy Verkkosovitin ja datansiirtomenetelmä matkaviestinverkossa
US5956651A (en) 1996-09-30 1999-09-21 Qualcomm Incorporated Cellular telephone interface system for AMPS and CDMA data services
JPH10178462A (ja) * 1996-12-19 1998-06-30 Toshiba Corp 無線データ通信システム
KR100260516B1 (ko) * 1997-04-01 2000-07-01 정선종 코드분할 다중접속 이동통신망에서의 비동기통신 데이터발신호 및 착신호 서비스 방법
KR19990001580A (ko) * 1997-06-16 1999-01-15 양승택 Cdma 이동통신망을 이용한 g3 팩스 서비스 방법
US6230024B1 (en) * 1998-05-12 2001-05-08 Nortel Networks Limited Voice to digital fax transmission
US6665537B1 (en) * 1999-01-21 2003-12-16 Qualcomm, Incorporated Automatic invocation of mobile IP registration in a wireless communication network

Also Published As

Publication number Publication date
MXPA02000448A (es) 2002-07-30
DE60024453T2 (de) 2006-08-24
WO2001005175A1 (en) 2001-01-18
EP1192825A1 (en) 2002-04-03
JP4680455B2 (ja) 2011-05-11
KR20020037029A (ko) 2002-05-17
US6463034B1 (en) 2002-10-08
CN1168338C (zh) 2004-09-22
DE60024453D1 (de) 2006-01-05
CA2379126A1 (en) 2001-01-18
EP1192825B1 (en) 2005-11-30
KR100763082B1 (ko) 2007-10-04
HK1047375B (zh) 2005-05-13
HK1047375A1 (en) 2003-02-14
ATE311731T1 (de) 2005-12-15
TW494693B (en) 2002-07-11
CA2379126C (en) 2008-03-11
AU6217500A (en) 2001-01-30
JP2003527770A (ja) 2003-09-16
BR0012376A (pt) 2003-07-01
IL147577A (en) 2007-05-15
CN1373974A (zh) 2002-10-09
IL147577A0 (en) 2002-08-14

Similar Documents

Publication Publication Date Title
JP3967548B2 (ja) リンク構成方法および装置
ES2342139T3 (es) Soporte de movilidad ip utilizando un registro de proxi de nodo movil.
ES2251389T3 (es) Procedimiento y aparato para evitar la perdida de datos durante una renegociacion ppp en una interfaz um.
ES2254154T3 (es) Establecimiento simultaneo de un protocolo punto a punto en interfaces um y rm.
ES2244630T3 (es) Procedimiento para evitar tiempos de espera ppp durante negociaciones ipcp.
ES2569604T3 (es) Sistema de comunicación, dispositivo de transmisión y método de comunicación
ES2344758T3 (es) Optimizacion de indicador de longitud.
WO2016173076A1 (zh) 一种数据中转传输方法、系统和具备中继功能的ue
ES2273714T3 (es) Entramado y desentramado selectivo de paquetes ppp en funcion de opciones negociadas de interfaces um y rm.
ES2341457T3 (es) Mantenimiento y aplicacion selectiva de compresion del ppp en un sistema de comunicacion inalambrica.
ES2271754T3 (es) Procedimiento de recepcion de paquetes de datos para su utilizacion en un terminal movil.
Bhagwat et al. Bluesky: A cordless networking solution for palmtop computers
KR20080083084A (ko) 무선 네트워크에서의 통신방법, 무선 네트워크에서스테이션의 통신방법 및 스테이션
MXPA01008593A (es) Disposicion simultanea de ppp sobre una interfaz de um y rm