[go: up one dir, main page]

MXPA06011142A - Metodo y aparato para obtener informacion de servidor en una red inalambrica. - Google Patents

Metodo y aparato para obtener informacion de servidor en una red inalambrica.

Info

Publication number
MXPA06011142A
MXPA06011142A MXPA06011142A MXPA06011142A MXPA06011142A MX PA06011142 A MXPA06011142 A MX PA06011142A MX PA06011142 A MXPA06011142 A MX PA06011142A MX PA06011142 A MXPA06011142 A MX PA06011142A MX PA06011142 A MXPA06011142 A MX PA06011142A
Authority
MX
Mexico
Prior art keywords
location information
server
node
message
address
Prior art date
Application number
MXPA06011142A
Other languages
English (en)
Inventor
Wangjun
Arungundram C Mahendran
Raymond Tah-Sheng Hsu
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
Publication of MXPA06011142A publication Critical patent/MXPA06011142A/es

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4541Directories for service discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5007Internet protocol [IP] addresses
    • H04L61/5014Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • 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/10Architectures or entities
    • H04L65/1045Proxies, e.g. for session initiation protocol [SIP]
    • 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/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • 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/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/51Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • 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/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

En un sistema de comunicaciones en el que un nodo movil busca establecer contacto con un nodo de servidor dentro o fuera de la red local del nodo movil al proporcionarle primeramente la informacion de ubicacion general y el tipo de servidor del nodo de servidor a un servidor de DHCP (Dynamic Host Configuracion Protocol - Protocolo de Configuracion de Huesped Dinamico). El servidor de DHCP compara despues la informacion proporcionada con su registro en almacenamiento para llegar a una direccion de IP (Internet Protocol - Protocolo de Internet) del nodo de servidor buscado. Despues, el servidor de DHCP le envia la direccion de IP al nodo movil, permitiendo asi que el nodo movil accese directamente el nodo de servidor.

Description

diversas redes individuales, llamadas algunas veces LANs (Local Area Networks - Redes de Área Local) o WANs (Wide Area Networks - Redes de Área Ancha) dependiendo del tamaño de las redes. En la Figura 1 se muestran algunas de tales redes 22, 24, 26 y 28 vinculadas a la Internet 20. Dentro de cada una de las redes 22, 24, 26 y 28, puede haber diversas piezas de equipo conectadas y en comunicación unas con otras. Los ejemplos son computadoras, impresoras, y servidores, por nombrar solo unos cuantos. Cada pieza de equipo tiene una dirección única de hardware, comúnmente llamada la dirección de MAC (Media Access Control - Control de Acceso de Medios) . La pieza de equipo con la dirección de MAC (Media Access Control - Control de Acceso de Medios) . La pieza del equipo con la dirección de MAC algunas veces es llamada nodo. Cuando el nodo se comunica más allá de su propia red mediante la Internet 20, se necesita asignarle una dirección de IP necesita al nodo. La asignación de la dirección de IP puede ser manual o automática. La asignación manual de la dirección de IP puede realizarse, por ejemplo, por un administrador de red. Más frecuentemente, la dirección de IP se asigna automáticamente por un servidor llamado servidor de DHCP (Dynamic Host Configuration Protocol - Protocolo de Configuración de Huésped Dinámico) que reside al interior de la red del nodo. Refiriéndose ahora a la Figura 1, como ejemplo, supongamos que un nodo 30 en la red 22 intenta enviarle un paquete de datos a otro nodo 32 en la red 28. Bajo el TCP/IP, cada paquete de datos necesita tener una dirección fuente y una dirección destino. En este caso, la dirección fuente es la dirección del nodo 30 en la red 22. La dirección destino es la dirección del nodo 32 en la red 28. Como otro ejemplo, cuando el nodo 30 en la red 22 intenta recuperar información proveniente del nodo 34 en otra red 24, tal como en una sesión de huésped de web en la que el nodo 34 sirve como huésped de web, el nodo 30 debe proporcionar una dirección de IP apropiada del nodo 34 en la red 24 para tal sesión. La llegada de tecnologías inalámbricas le permite a los nodos desconectarse de su red registrada originalmente a otra red. Por ejemplo, refiriéndose nuevamente a la Figura 1, el nodo 30, en lugar de estar permanentemente cableado a la red 22, puede ser un dispositivo inalámbrico, tal como un PDA (Personal Device Assistant) , un teléfono celular, o una computadora portátil. El nodo inalámbrico 30 puede recorrer más allá del límite de su red local 22. Consecuentemente, por ejemplo, el nodo 30 puede entrar en seguimiento lejos de su red local 22 una red foránea 26. Bajo tal escenario, la dirección de IP original asignada al nodo 30 ya no seria aplicable al nodo 30. Como tal, los paquetes de datos enviados al nodo 30 pueden no ser alcanzables por el nodo 30. El MIP (Mobile Internet Protocol - Protocolo de Internet Móvil) expuesto por el IETF pretende abordar los problemas de movilidad del nodo. De acuerdo con la RFC 2002 publicada por el IETF, se le asigna una "dirección local válida" al nodo 30, abreviado como CoA (Care-of Address") . Bajo la RFC 2002, existen dos tipos de CoA, a saber, el CoA de FA (Dirección local válida de Agente Foráneo) y el CCoA (Dirección local válida Co-Ubicada) . La CoA de FA es en esencia la dirección de un FA (Foreign Agent - Agente Foráneo) (no se muestra) , el cual es un servidor designado en la red foránea donde se encuentra ubicado el nodo 30. La CCoA es una dirección individual pero temporal asignada al nodo 30 por la red foránea. De cualquier manera, en cualquier momento que el nodo 30 se encuentre en un territorio foráneo, el nodo 30 debe registrar la CoA, sea la CoA de FA o la CCoA, con su red local 22, de manera que la red local 22 sepa siempre el paradero del nodo 30. Después del registro, la CoA se almacena en la tabla de direccionamiento mantenida por un servidor designado, llamado el HA (Home Agent - Agente Local) (no se muestra) de la red local 22.
Tomemos un ejemplo ilustrativo. Supongamos que el nodo 30 entra en seguimiento en la red foránea 26. Después de la recepción del anuncio proveniente de la red foránea 26, el nodo conoce la dirección del FA de la red foránea 26. Después, el nodo 30 registra la CoA de FA con la red local 22. Cuando el nodo 30 en la red foránea 26 le envia un paquete de datos al nodo 34 en la red 24, conociendo la dirección del nodo 34 en la red 24, el paquete de datos puede enviarse directamente. Sin embargo, el tráfico inverso puede no ser tan directo. En la ruta inversa de datos, cuando el nodo 34 en la red 24 intenta enviar un paquete de datos al nodo 30, ahora en la red foránea 26, como se mencionó con anterioridad, de conformidad con el TCP/IP, tanto las direcciones fuente como destino deben especificarse en el paquete de datos. En este caso, la dirección de fuente es la dirección de IP del nodo 34 en la red 24. En cuanto a la dirección destino, el nodo 34 conoce solamente la dirección de IP del nodo 30 asignado por su red local 22, llamada la HoA (Home assigned Address - Dirección asignada Local), no la CoA de FA del nodo 30. Consecuentemente, la dirección destino se establecerá en la HoA del nodo 30. Sin embargo, dado que la CoA de FA del nodo 30 se almacena en la HA de la tabla de direccionamiento de la red local 22, cuando el paquete de datos alcanza la red local 22, la HA de la red 22 encapsula el paquete de datos recibido con el CoA de FA almacenado y lo reenvía al nodo 30 en la red foránea 26. El CoA de FA encapsulado sirve como la dirección destino del paquete de datos reenviado. Una vez que la red foránea 26 recibe el paquete de datos redireccionado, la red foránea 26 básicamente despoja el CoA de FA encapsulado y envía el paquete original al nodo móvil 30. Al operar de tal manera, se dice que va a establecerse un túnel de datos virtual entre el nodo 34 en la red 24 y el nodo 30 que busca en la red foránea 26, destinados todos a ser transparentes para los usuarios. Esto a pesar de que en realidad, el túnel virtual involucra de hecho comunicaciones de datos de tres vías. Hasta ahora, aunque el nodo 30 está en seguimiento, es difícil y muy frecuentemente imposible que el nodo 30 ubique otros nodos en otras redes, a pesar de que el nodo 30 sabe exactamente el tipo de datos que desea acceder. Regresando al ejemplo expuesto con anterioridad, el nodo 30 en la red foránea 26 puede enviarle paquetes de datos al nodo 34 en la red 24 debido a que el nodo 30 conoce con bastante antelación la dirección de IP del nodo 34. En realidad, no siempre es el caso. Supongamos que el nodo 30 conoce básicamente el tipo de información a ser accedida. El nodo 30 puede saber incluso la dirección de la red 24 que tiene un servidor que posea información por ser acezada. Sin embargo, el nodo 30 no conoce la dirección de IP exacta del nodo 34 de servidor y consecuentemente se ve en desventaja de alcanzar el nodo 34. Consecuentemente, existe la necesidad de proporcionar un nodo de seguimiento con maneras para acceder convenientemente la información de servidor de acceso ubicada en redes diferentes.
BREVE DESCRIPCIÓN DE LA INVENCIÓN En un sistema de comunicaciones en el que un nodo móvil busca establecer contacto con un nodo de servidor dentro o fuera de la red local, el nodo móvil ubica primeramente un servidor de DHCP (Dynamic Host Configuration Protocol - Protocolo de Configuración de Huésped Dinámico) . Después, el nodo móvil le proporciona la ubicación general y el tipo de servidor del nodo de servidor buscado al servidor de DHCP. El servidor de DHCP compara después la información proporcionada con su registro en almacenamiento y llega a una dirección de IP (Protocolo de Internet) o un FQDN (Fully Qualified Domain ame - Nombre de Dominio Totalmente Calificado) del nodo de servidor buscado. El servidor de DHCP les envía la dirección de IP o el FQDN al nodo móvil permitiéndole al nodo móvil contactar directamente el nodo de servidor. En una primera modalidad, el nodo móvil que entra en seguimiento en una red foránea utiliza una CoA de FA (Dirección local Válida de Agente Foráneo) para comunicarse con el servidor de DHCP y alcanzar el servidor buscado. En una segunda modalidad, el nodo móvil que entra en seguimiento en una red foránea utiliza una CCoA (Dirección local válida Co-Ubicada) para comunicarse con el servidor de DHCP y después de ello con el nodo de servidor buscado. De acuerdo con la invención, un nodo móvil de seguimiento de interfuncionamiento está diseñado para ser capaz de acceder a la información desde cualquier servidor en cualquier red. Estas y otras características y ventajas de la invención serán aparentes para aquellos expertos en la materia a partir de la siguiente descripción detallada, tomada con untamente con los dibujos acompañantes, en los cuales los números de referencia similares se refieren a partes similares.
BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 es un dibujo esquemático de la conexión global de redes; La Figura 2 es un dibujo esquemático que muestra una primera modalidad de la invención; La Figura 3 es un diagrama de flujo que muestra los pasos de acuerdo con la primera modalidad de la invención; La Figura 4 es un dibujo esquemático que muestra una segunda modalidad de la invención; La Figura 5 es un dibujo esquemático de la circuiteria de un nodo móvil de acuerdo con la invención; y La Figura 6 es un dibujo esquemático de la circuiteria de un servidor de configuración de acuerdo con la invención.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La siguiente descripción se presenta para permitirle al experto en la materia realizar y utilizar la invención. Los detalles se exponen en la siguiente descripción para propósitos de explicación. Debe observarse que el experto en la materia se dará cuenta de que la invención puede llevarse a la práctica sin el uso de estos detalles específicos. En otros casos, las estructuras y procesos conocidos no se elaboran con objeto de no oscurecer la descripción de la invención con detalles innecesarios. Consecuentemente, la presente invención no pretende limitarse por las modalidades mostradas, sino que debe abarcar el alcance más amplio consistente con los principios y características descritos en la presente invención . Se hace ahora referencia a la Figura 2 la cual muestra esquemáticamente una primera modalidad de la invención . El sistema general se identifica en términos generales por el número de referencia 40 el cual incluye una red principal 42, tal como una intranet o la Internet. A manera de ejemplo, como se muestra en la Figura 2, conectadas a la red principal 42 se encuentran una HN (Home Net ork - Red Local) y una FN (Foreign Network - Red Foránea) 46. Para propósitos de claridad y brevedad de ilustración, no se muestra específicamente ninguna otra red. En el sistema 40, hay un nodo 48 el cual se registra originalmente con la HN 44 pero es capaz de migrar a otras redes foráneas, tales como la FN 46. A continuación, se necesita definir unos cuantos términos. De acuerdo con las dos versiones convencionales de IP, IPv4 e ???ß, un nodo que es capaz de mover y cambiar la red conectada es llamado "nodo móvil". La red a la cual se conectó originalmente el nodo móvil es llamada "red local". Un nodo que se encuentra presente en la red local y se encarga durante la ausencia del nodo móvil es llamado "agente local". Una red a la cual se encuentra conectado actualmente el nodo móvil es llamada "red foránea". Un nodo que se encuentra presente en la red foránea para ocuparse del nodo móvil mientras se encuentra en la red foránea es llamado "agente foráneo". Algunas veces la red foránea es llamada "red visitada". Se hace ahora referencia a la Figura 2. En la HN 44, diferente a los nodos móviles 48, hay otros nodos dentro del HA 44 pero no se muestra en aras de la claridad. Tales nodos pueden ser computadoras de diversas escalas, impresoras, y cualesquier otros dispositivos que pueden ser móviles o no móviles. Además, en la HN 44, existe un HA (Agente Local) 50 que básicamente es un nodo que tiene la tarea de administrar el tráfico de datos dentro de la HN 44 y también de controlar el tráfico de datos en la HN 44 direcciona entrante y saliente. Además del HA 50, existen otros nodos dedicados dentro de la HN 44 que realizan diferentes tareas. Por ejemplo, existen nodos tales como un controlador 52 de BCMCS (Broadcast Multicast Services - Servicios de Multiemisión de Difusión) , un servidor 54 de DHCP (Dynamic Host Control Protocol - Protocolo de Control de Huésped Dinámico) , un servidor 56 de DNS (Sistema de Nombre de Dominio), y un servidor intermediario 58 de SIP (Protocolo de Inicio de Sesión), por nombrar unos cuantos. El controlador 52 de BCMCS es básicamente un servidor que proporciona información de configuración de emisión y multiemisión a fin de permitir a los usuarios examinar atentamente las sesiones disponibles de emisión o multiemisión cuando sea solicitado por los usuarios. El servidor 54 de DHCP se instala para asignar automáticamente direcciones de IP y otros parámetros de configuración a los nodos en la HN 44 durante el inicio, permitiendo consecuentemente que los nodos en la HN 44 se comuniquen con otros nodos en el sistema 40. El servidor 54 de DHCP también puede proporcionarle información de configuración actualizada a los nodos durante la operación. Algunas veces los paquetes de datos que viajan en el sistema 40 no se especifican con la dirección de IP de 4 octetos utilizaba comúnmente bajo el formato IPv4, o el formato de 16 octetos bajo el IPv6, sino más bien con los nombres de dominio que se expresan en el texto. El DNS 56 básicamente traducen los nombres de dominio expresados en texto en direcciones numéricas de IP que sean legibles por las máquinas en el sistema 40. El servidor intermediario 58 de SIP esencialmente es un direccionador intermediario que desempeña el doble papel de huésped y cliente para redireccionar paquetes de datos a nombre de otros nodos de cliente. De manera similar, por simplicidad y en aras de la explicación, se ilustra la FN 46 siendo substancialmente la misma que la HN 44. Debe observarse que, dependiendo del uso, la FN 46 puede estructurarse de manera muy diferente. Consecuentemente, en este caso, la FN 46 incluye también, entre otras cosas, un controlador 58 de BCMCS, un servidor 60 de DHCP, un DNS 62, y un servidor intermediario 66 de SIP. La coordinación del tráfico de datos dentro y más allá de la FN 46 es administrada por el FA (Agente Foráneo) 66. Suponga que el MN 48 entre el seguimiento en la FN 46. En este ejemplo especifico, el MN 48 desea un videoclip de un evento noticioso proveniente de un servicio de emisión en el cual el usuario del MN 48 es suscriptor. El servicio de emisión puede ser, por ejemplo, un editor u organización de medios que brinda el servicio al público. Para satisfacer la demanda, el servicio de emisión tiene instalados diferentes controladores de BCMCS en muchas redes, tal como la HN 44 y la FN 46. El MN 48 desea acceder sea al controlador 52 de BCMCS en la HN 44 o al controlador 58 de BCMCS en la FN 46, pero prefiere este último debido a que el MN 48 se encuentra ahora en la FN 46 y consecuentemente tiene ventaja de proximidad. En esta modalidad, a fin de controlador de BCMCS, el MN 48 busca la ayuda sea del servidor 54 de DHCP en la HN 44 o el servidor 60 de DHCP en la FN 46. Si el MN 48 conoce la dirección exacta de cualquiera de los servidores de DHCP 54 o 60, el MN 48 puede enviar directamente un mensaje de DHCPINFORM al - - servidor de DHCP 54 o 60. Por otra parte, si el MN 48 no tiene la dirección directa de cualquiera de los servidores de DHCP, el MN 48 puede realizar siempre una emisión limitada al enviar el mensaje de DHCPINFORM a fin de alcanzar un servidor disponible de DHCP. Debe observarse que bajo el IPv6, el mensaje equivalente es llamado INFORMATION REQUEST (SOLICITUD DE INFORMACIÓN) . En esta especificación, en aras de la consistencia y claridad al describir las modalidades, se utiliza la terminología de IPv . Debe observarse que el experto en la materia puede utilizar fácilmente los mensajes equivalentes en ???ß correspondientes a los mensajes en IPv4 para llevar a la práctica la invención. Además, bajo el DHCP promulgado por el IETF, pueden utilizarse diversos tipos de mensajes para comunicarse con el servidor de DHCP. Por ejemplo, durante el inicio, es decir, durante el tiempo en el que el nodo hace una solicitud para que se le asigne una dirección de IP, pueden utilizarse los tipos de mensaje tales como DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, etcétera. Después del inicio, pueden utilizarse los tipos de mensajes tales como DHCPRELEASE, DHCPINFORM, DHCPACK, etcétera. Bajo el DHCP, existen diversas "opciones" en cada tipo de mensaje disponible para los usuarios para propósitos de flexibilidad. Los detalles del DHCP y las opciones - - disponibles se declaran en las RFCs 2131, 2132 y 3315 del IETF . Bajo el DHCP, normalmente se utiliza el mensaje de DHCPINFORM para cambiar los parámetros de red de un nodo ya configurado. En el mensaje de DHCPINFORM, existen las opciones VCI (Vendor Class Identifier - Identificador de Clase de Proveedor) y VSI (Vendor Specific Information -Información Especifica de Proveedor) disponibles como entradas . Las dos opciones de VCI y VSI contienen información especifica para ayudarle a cualquier servidor de DHCP a configurar apropiadamente un nodo de cliente que pueden no ser un nodo ordinario capaz de lograr una configuración rutinaria. En lo sucesivo, el tipo de mensaje de DHCPINFORM se utiliza principalmente para configuraciones de intra-funcionamiento . De acuerdo con la invención, el tipo de mensaje de DHCPINFORM se utiliza para configuraciones entre redes. Primeramente, el MN 48 necesita informarle al huésped de DHCP en cuál red se encuentra ubicado el servidor buscado. El MN 48 puede cumplir este requisito sea proporcionando la dirección de IP o el FQDN (Fully Qualified Domain Ñame - Nombre de Dominio Totalmente Calificado) de la red del servidor buscado. En este caso, dado que los servidores buscados se encuentran ubicados sea en la HN 44 o la FN 46, puede proporcionarse la dirección de IP o el FQDN de la HN 44 o la FN 46 a fin de cumplir esta demanda. Además, el MN 48 necesita también decirle al huésped de DHCP que tipos de servidor está buscando el MN 48. En este caso, es el controlador de BCMCS. Debe observarse que incluso con estas dos piezas básicas de información, el MN 48 aún es incapaz de contactar directamente al servidor buscado debido a que el MN 48 no tiene toda la información necesaria para llegar a una dirección de IP directa alcanzable al servidor buscado. Por ejemplo, el MN 48 no tiene la dirección de MAC fue nombre de dominio del servidor buscado para surgir una dirección de IP utilizable. A fin de cumplir el objetivo anteriormente mencionado, en el mensaje de DHCPINFORM, el MN 48 llena la opción de VCI con la dirección de IP o el FQDN de la red con el servidor que desea el acceso al MN 48. La dirección de IP o el FQDN de la red donde se encuentra el servidor y que tiene el servidor que el MN 48 intenta alcanzar puede extraerse de diversas fuentes. Por ejemplo, si el MN 48 desea el controlador 52 de BCMCS en la HN 44, el MN 48 puede utilizar simplemente su dirección local como la dirección de IP requerida para enviar al servidor de DHCP. Como otra opción, el MN 48 puede utilizar la porción de área de su NAI (Network Access Identifier - Identificador de Acceso de Red) el cual corresponde al nombre de dominio de la dirección local del MN 48. Si el MN 48 desea el controlador 58 de BCMCS en la FN 46, el MN 48 puede extraer la dirección de IP de la FN 46 proveniente de su CoA de FA la cual se encuentra disponible durante el periodo de anuncio por la FN 46 cuando el MN ingresa al territorio de la FN 46 a fin de permitirle al MN 48 registrar la CoA de FA con la HN 44. En cuanto al tipo de servidor que está buscando el MN 48, el MN 48 puede llenar cualquier opción disponible del mensaje de DHCPINFORM. Algunas opciones a manera de ejemplo son la Opción de Direccionador, la Opción de Servidor de Nombre, la Opción de Nombre de Dominio, por nombrar unas cuantas. Como se mencionó con anterioridad, en este ejemplo, el tipo de servidor que desea el MN 48 es un controlador de BCMCS. Como alternativa que, el nombre de IP o el FQDN puede llenarse en la opción de VSI del mensaje de DHCPINFORM, aun que la información de tipo de servidor puede llenarse en las demás opciones disponibles como se mencionó con anterioridad. Aún como otra alternativa, toda la información necesaria, es decir, el nombre de IP o el FQDN y el tipo de servidor buscado, pueden llenarse todos sea en la opción de VCI o en la opción de VSI.
Después de la recepción del mensaje de DHCPINFORM, el huésped de DHCP mapea las dos piezas de información conjuntamente al referirse al propio registro de almacenamiento del huésped de DHCP. Si el huésped de DHCP tuviese un tráfico previo con el servidor buscado, el registro de transacciones con la información buscada podría encontrarse normalmente. Si se encuentra una correspondencia, la dirección de IP del servidor buscado puede reconstruirse y después transmitirse en la opción de VSI en un mensaje de DHCPACK direccionado al MN 48. Por otra parte, si no se encuentra una correspondencia, se le envía un mensaje de DHCPNACK al MN 48. El proceso descrito con anterioridad se ilustra en el diagrama de flujo de la Figura 3. La Figura 4 muestra otra modalidad de la invención. En esta modalidad, la tarea del agente foráneo en una red foránea, tal como el FA 64 en la FN 46 mostrada en la Figura 2, se encuentra distribuida. En cambio, el MN 48 actúa como su propio agente. Cuando el MN 48 entra en seguimiento lejos de la HN 44, el lugar de solicitar una CoA de FA (Dirección local válida de Agente Foráneo) , de acuerdo con el MIP, el MN 48 puede solicitar una CCoA (Dirección local válida Co-übicada) mediante un servidor de DHCP en cualquier red foránea donde se encuentra ubicado el MN 48, tal como la FN 72 mostrada en la Figura 4. Sin embargo, diferentemente a la asignación de la CCoA por la FN 72, el MN 48 realiza toda las funciones de un agente foráneo. Nuevamente, el MN 48 necesita registrar la CCoA con la HN 44. Por ejemplo, para corresponder con una CN (Correspondent Network - Red Correspondiente) 76, el MN 48 envía un paquete de datos con dos capas de direcciones . En la capa exterior, la dirección fuente se establece como la CCoA, y la dirección destino se establece como la HA 50. En la capa interior, la dirección fuente es la HoA (Home assigned Address - Dirección Asignada Local) del MN 48 y la dirección destino es la dirección de la CN 76. Después de la recepción del paquete de datos proveniente del MN 48 en seguimiento, la HA 50 despoja la capa de dirección exterior y reenvía el paquete de datos a la CN 76 con la capa de dirección interior. En la trayectoria de datos inversa, es decir, cuando la CN 76 le envía un paquete de datos al MN 48, el paquete de datos solamente tiene una capa de dirección con la dirección fuente establecida en la CN 76 y la dirección destino establecida en la HoA del MN 48. Después de la recepción del paquete de datos, la HA 50 encapsula el paquete de datos con la CCoA como la dirección destino y le reenvía el paquete de datos al MN 48. El MN 48 realiza la desencapsulación por sí mismo sin pasar por la FA 74.
En esta modalidad, suponga que el MN 48 necesita acceder a un servidor intermediario 78 de SIP. El MN 48 sabe que existe al servidor intermediario de SIP en la CN 76 pero ignora su dirección de IP exacta. El MN 48 necesita primeramente ubicar un servidor de DHCP mediante el contacto directo con, por ejemplo, una de las redes 44, 72, y 76. Alternativamente, un servidor de DHCP puede ubicarse mediante la transmisión limitada, como se explicó con anterioridad. El MN 48 proporciona después la dirección de IP o el nombre de dominio de la CN 76 al servidor de DHCP seleccionado de la manera descrita con anterioridad. Además, el MN 48 le informa al servidor de DHCP seleccionado el tipo de servidor buscado como un servidor intermediario de SIP. El resto de la operación e substancialmente igual que lo descrito en la modalidad anterior. En aras de la claridad y precisión, los detalles operacionales no se repiten detalladamente. La Figura 5 muestra esquemáticamente la parte de la implementacion de hardware de un aparato de nodo móvil derrotado por el número de referencia 80 de acuerdo con la invención. El aparato 80 puede construirse e incorporarse en diversos dispositivos, tales como una computadora portátil, un PDA o un teléfono celular. El aparato 80 comprende un bus central 82 de datos que vincula varios circuitos conjuntamente. Los circuitos incluyen una CPU (Central Processing ünit - Unidad de Central Procesamiento) o un controlador 84, un circuito receptor 86, un circuito transmisor 88, y un circuito 90 de memoria. Los circuitos receptor y transmisor 86 y 88 pueden conectarse con un circuito de RF (Radio Frequency -Frecuencia de Radio) pero no se muestra en el dibujo. El circuito receptor 86 procesa y coloca en memoria temporal las señales recibidas antes de enviarlas al bus 82 de datos. Por otra parte, el circuito transmisor 88 de procesa y coloca en memoria temporal los datos provenientes del bus 82 de datos antes de enviarlos al dispositivo que 80. La CPU/controlador 84 realiza la función de administrar los datos del bus 82 de datos y también la función del procesamiento general de datos, incluyendo la ejecución del contenido de instrucciones del circuito 90 de memoria . El circuito 90 de memoria incluye un conjunto de instrucciones denotadas generalmente por el número de referencia 92. En esta modalidad, las instrucciones incluyen opciones tales como el cliente 94 de MIP, el cliente 96 de SIP, el cliente 98 de DHCP, el cliente 100 de DNS y el cliente 102 de BCMCS, el cliente 104 de ubicación de nodo, por nombrar unos cuantos. En esta modalidad, el circuito 90 de memoria es un circuito de RAM (Random Access Memory - Memoria de Acceso Aleatorio) . Las porciones de instrucciones a manera de ejemplo 94, 96, 98, 100, 102 y 104 son módulos de software. El circuito 90 de memoria puede estar vinculado a otro circuito de memoria (no se muestra) del cual puede ser de tipo volátil o no volátil. Alternativamente, el circuito 90 de memoria puede estar conformado de otros tipos de circuito, tales como un EEPROM (Electrically Erasable Programmable Read Only Memory -Memoria de Sólo Lectura Programable Eléctricamente Borrable) , EPROM (Electrical Programmable Read Only Memory - Memoria de Sólo Lectura Programable Eléctrica) , ROM (Read Only Memory - Memoria de Sólo Lectura) , disco magnético, disco óptico, y otras conocidas en la materia. La Figura 6 muestra esquemáticamente la parte de la implementación del hardware del aparato de DHCP de acuerdo con la invención y se denota por el número de referencia 106. El aparato de DHCP 106 comprende un bus central 108 de datos que vincula diversos circuitos conjuntamente. Los circuitos incluyen una CPÜ (Central Processing Unit) o un controlador 120, un circuito receptor 112, un circuito transmisor 114, un circuito 116 de memoria, y una unidad 130 de almacenamiento de datos. Los circuitos receptor y transmisor 112 y 114 pueden conectarse a un bus de datos de red (no se muestra) con el que se conecta el aparato 106 de DHCP. El circuito receptor 112 procesa y coloca en memoria temporal las señales recibidas provenientes del bus de datos de red (no se muestra) antes del direccionamiento al bus interno 108 de datos. El circuito transmisor 114 procesa y coloca en memoria temporal los datos provenientes del bus 108 de datos antes de enviarlos al aparato 106. La CPü/controlador 120 tiene la tarea de administrar los datos del bus 96 de datos y la función del proceso general de datos, incluyendo la ejecución del contenido de instrucciones del circuito 116 de memoria. El circuito de 116 de memoria incluyen conjunto de instrucciones denotadas generalmente por el número de referencia 118. En esta modalidad, las instrucciones incluyen porciones, entre otras cosas, un huésped 122 de DHCP y un huésped 124 de ubicación de nodo. La unidad 130 de almacenamiento de datos incluye registros de traducción anteriores del dispositivo 106 de DHCP, cuyos registros pueden ser recuperables por la CPU/controlador 120 mediante el bus 108 de datos. El circuito 116 de memoria y la unidad 130 de almacenamiento de datos puede conformarse por tipos de circuito de memoria como se mencionó con anterioridad y no se repiten adicionalmente . Además, el circuito 116 de memoria y la unidad 130 de almacenamiento de datos, a pesar de que se muestran separadamente en la Figura 6, pueden fabricarse como una unidad. Finalmente, en las modalidades se describen unas cuantas redes vinculadas con la red principal. Debe ser aparente que puede involucrarse una multiplicidad de redes. Además, el nodo móvil puede acceder a otros nodos diferentes a los tipos de nodos descritos. Además, cualesquier bloques lógicos, circuitos, y pasos de algoritmo descritos en conexión con las modalidades pueden implementarse en hardware, software, firmware, o combinaciones de los mismos. Los expertos en la materia deben comprender que estos y otros cambios en forma y detalle pueden realizarse en la presente sin aislarse del alcance y espíritu de la invención.

Claims (1)

  1. NOVEDAD DE LA INVENCIÓN Habiéndose descrito la invención como antecedente, se reclama como propiedad lo contenido en las siguientes reivindicaciones: REIVINDICACIONES 1. Un método para obtener información para un nodo de comunicaciones en un sistema de comunicaciones, caracterizado porque comprende: identificar un servidor de configuración; proporcionar información de ubicación general y el tipo de nodo de dicho nodo de comunicaciones en un mensaje de informe; y enviar dicho mensaje de informe a dicho servidor de configuración. 2. El método según la reivindicación 1, caracterizado además porque incluye: recibir proveniente de dicho servidor de configuración un mensaje de reconocimiento que incluye información de ubicación especifica de dichos nodo de comunicaciones; y acceder a dicho nodo de comunicaciones utilizando dicha información de ubicación especifica. 3. El método según la reivindicación 2, caracterizado porque identificar dicho servidor de configuración incluye identificar un servidor de DHCP, proporcionar dicho mensaje de informe incluye proporcionar un mensaje de DHCPINFORM, y recibir dicho mensaje de reconocimiento incluye recibir un mensaje de DHCPACK. 4. El método según la reivindicación 2, caracterizado además porque incluye adquirir una dirección local previo a dicha identificación de dicho servidor de configuración . 5. El método según la reivindicación 4, caracterizado porque la adquisición de dicha dirección local incluye adquirir dicha dirección local seleccionada a partir de un grupo que consiste en una dirección local de agente foráneo y una dirección local co-ubicada. 6. El método según la reivindicación 1, caracterizado además porque incluye transmitir una búsqueda de servidores de configuración disponibles antes de la identificación de dicho servidor de configuración. 7. Un método para acceder un servidor objetivo en una pluralidad de redes en un sistema de comunicaciones que soporta el TCP/IP, caracterizado porque comprende: identificar un servidor de DHCP; proporcionar información de ubicación general de una pluralidad de dichas redes y tipo de servidor de dicho servidor objetivo en un mensaje de informe; enviar dicho mensaje de informe a dicho servidor de DHCP; recibir un mensaje de reconocimiento que incluye información de ubicación especifica de dicho servidor objetivo proveniente de dicho servidor de DHCP; y acceder a dicho servidor objetivo utilizando dicha información de ubicación especifica. 8. El método según la reivindicación 7, caracterizado porque dicha información de ubicación especifica se selecciona a partir de un grupo que consiste en una dirección de IP de dicho servidor objetivo y un nombre de dominio de dicho servidor objetivo. 9. El método según la reivindicación 7, caracterizado además porque incluye adquirir una dirección local (CoA) antes de la identificación de dicho servidor de configuración. 10. El método según la reivindicación 9, caracterizado además porque la adquisición de dicha dirección local incluye adquirir dicha dirección local seleccionada a partir de un grupo que consiste en una dirección local de agente foráneo (CoA de FA) y una dirección local co-ubicada (CCoA) . 11. Un método para obtener información para un nodo de comunicaciones en un sistema de comunicaciones, caracterizado porque comprende: recibir un mensaje de informe que incluye información de ubicación general y el tipo de nodo de dicho nodo de comunicaciones; comparar dicha información de ubicación general y dicho tipo de nodo con un registro almacenado; y generar un mensaje de reconocimiento que incluye información de ubicación especifica de dicho nodo de comunicaciones en dicho sistema de comunicaciones si registro almacenado corresponde con dicha información de ubicación general y dicho tipo de nodo. 12. El método según la reivindicación 11, caracterizado porque recibir dicho mensaje de informe incluye recibir un mensaje de DHCP1NF0RM y en el que generar dicho mensaje de reconocimiento incluye generar un mensaje de DHCPACK. 13. El método según la reivindicación 11, caracterizado porque dicha información de ubicación especifica se selecciona a partir de un grupo que consiste en una dirección de IP de dicho nodo de comunicaciones y un nombre de dominio de dicho nodo de comunicaciones . 14. Un aparato en un sistema de comunicaciones, caracterizado porque comprende: medios para identificar un servidor de configuración; medios para proporcionar información de ubicación general y el tipo de nodo de un nodo de comunicaciones en dicho sistema de comunicaciones en un mensaje de informe; y medios para enviar dicho mensaje de informe a dicho servidor de configuración. 15. El aparato según la reivindicación 14, caracterizado además porque incluye: medios para recibir un mensaje de reconocimiento proveniente de dicho servidor de configuración que incluye información de ubicación especifica de dicho nodo de comunicaciones; y medios para acceder a dicho nodo de comunicaciones utilizando dicha información de ubicación especifica . 16. El método según la reivindicación 14, caracterizado además porque incluye medios para adquirir una dirección local. 17. El método según la reivindicación 16, caracterizado porque dicha dirección local se selecciona a partir de un grupo que consiste en una dirección local de agente foráneo y una dirección local co-ubicada. 18. Un aparato para ubicar un servidor objetivo en una pluralidad de redes en un sistema de comunicaciones que soporta el TCP/IP, caracterizado porque comprende: medios para identificar un servidor de DHCP; medios para proporcionar información de ubicación general de una pluralidad de dichas redes y tipo de servidor de dicho servidor objetivo en un mensaje de informe ; medios para enviarle dicho mensaje de informe a dicho servidor de DHCP; medios para recibir un mensaje de reconocimiento que incluye información de ubicación especifica de dicho servidor objetivo proveniente de dicho servidor de DHCP; y medios para acceder a dicho servidor objetivo utilizando dicha información de ubicación especifica. 19- El aparato según la reivindicación 18, caracterizado porque dicha información de ubicación especifica se selecciona a partir de un grupo que consiste en una dirección de IP de dicho servidor objetivo y un nombre de dominio de dicho servidor objetivo. 20. El método según la reivindicación 19, caracterizado además porque incluye adquirir una dirección local (CoA) para dicho aparato. 21. El método según la reivindicación 20, caracterizado además porque dicha dirección local válida se selecciona a partir del grupo que consiste en una dirección local válida de agente foráneo (FA CoA) y una dirección local válida co-ubicada (CCoA) . 22. Un aparato en un sistema de comunicaciones, caracterizado porque comprende: medios para recibir un mensaje de informe que incluye información de ubicación general y el tipo de nodo de un nodo de comunicaciones; medios para comparar dicha información de ubicación general y dicho tipo de nodo con un registro almacenado; y medios para generar un mensaje de reconocimiento que incluye información de ubicación especifica de dicho nodo de comunicaciones en dicho sistema de comunicaciones si dicho registro almacenado corresponde con dicha información de ubicación general y dicho tipo de nodo. 23. El método según la reivindicación 22, caracterizado porque dicha información de ubicación especifica se selecciona a partir de un grupo que consiste en una dirección de IP de dicho nodo de comunicaciones y un nombre de dominio de dicho nodo de comunicaciones. 24. El método según la reivindicación 22, caracterizado porque dicho mensaje de informe incluye un mensaje de DHCPINFORM y dicho mensaje de reconocimiento incluye un mensaje de DHCPACK 25. Un aparato en un sistema de comunicaciones, caracterizado porque comprende: un circuito de memoria que tiene instrucciones legibles por computadora para identificar un servidor de configuración, proporcionar información de ubicación general y el tipo de nodo de un nodo de comunicaciones en un mensaje de informe, y enviarle dicho mensaje de informe a dicho servidor de configuración; y un circuito de procesador acoplado a dicho circuito de memoria para procesar dichas instrucciones legibles por computadora. 26. El aparato según la reivindicación 25, caracterizado porque dicho circuito de memoria incluye además instrucciones legibles por computadora para recibir proveniente de dicho servidor un mensaje de reconocimiento que incluye información de ubicación especifica de dicho nodo de comunicaciones, y acceder dicho nodo de comunicaciones utilizando dicha información de ubicación específica . 27. Un aparato para ubicar un servidor objetivo en una pluralidad de redes en un sistema de comunicaciones que soporta el TCP/IP, caracterizado porque comprende: un circuito de memoria que tiene instrucciones legibles por computadora para identificar un servidor de DHCP, proporcionar información de ubicación general de una pluralidad de dichas redes y tipo de servidor de dicho servidor objetivo en un mensaje de informe, enviarle dicho mensaje de informe a dicho servidor de DHCP, recibir un mensaje de reconocimiento que incluye información de ubicación específica de dicho servidor objetivo proveniente de dicho servidor de DHCP, y acceder a dicho servidor objetivo utilizando dicha información de ubicación especifica; y un circuito de procesador acoplado a dicho circuito de memoria para procesar dichas instrucciones legibles por computadora. 28. El aparato según la reivindicación 27, caracterizado porque dicha información de ubicación especifica se selecciona a partir del grupo que consiste en una dirección de IP de dicho servidor objetivo y un nombre de dominio de dicho servidor objetivo. 29. Un aparato en un sistema de comunicaciones, caracterizado porque comprende: un circuito de memoria que tiene instrucciones legibles por computadora para recibir un mensaje de informe que incluye información de ubicación general y el tipo de nodo de un nodo de comunicaciones en dicho sistema de comunicaciones, comparar dicha información de ubicación general y dicho tipo de nodo con un registro almacenado, generar un mensaje de reconocimiento que incluye información de ubicación especifica de dicho nodo de comunicaciones en dicho sistema de comunicaciones si dicho registro almacenado corresponde con dicha información de ubicación general y dicho tipo de nodo; y un circuito procesador acoplado a dicho circuito de memoria para procesar dichas instrucciones legibles por computadora . 30. El aparato según la reivindicación 29, caracterizado porque dicha información de ubicación especifica se selecciona a partir del grupo que consiste en una dirección de IP de dicho nodo de comunicaciones y un nombre de dominio de dicho nodo de comunicaciones. 31. El método según la reivindicación 30, caracterizado porque dicho mensaje de informe incluye un mensaje de DHCPINFOR y un mensaje de reconocimiento incluye un menaje de DHCPACK.
MXPA06011142A 2004-03-31 2005-03-31 Metodo y aparato para obtener informacion de servidor en una red inalambrica. MXPA06011142A (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US55879604P 2004-03-31 2004-03-31
US11/095,973 US7720024B2 (en) 2004-03-31 2005-03-30 Method and apparatus for obtaining server information in a wireless network
PCT/US2005/010896 WO2005099230A1 (en) 2004-03-31 2005-03-31 Method and apparatus for obtaining server information in a wireless network

Publications (1)

Publication Number Publication Date
MXPA06011142A true MXPA06011142A (es) 2007-01-25

Family

ID=34964399

Family Applications (1)

Application Number Title Priority Date Filing Date
MXPA06011142A MXPA06011142A (es) 2004-03-31 2005-03-31 Metodo y aparato para obtener informacion de servidor en una red inalambrica.

Country Status (9)

Country Link
US (2) US7720024B2 (es)
EP (2) EP2346229A1 (es)
JP (1) JP4638483B2 (es)
KR (2) KR100884434B1 (es)
CN (2) CN102833245B (es)
BR (1) BRPI0509392A (es)
CA (1) CA2561642A1 (es)
MX (1) MXPA06011142A (es)
WO (1) WO2005099230A1 (es)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8166166B2 (en) 2005-12-15 2012-04-24 International Business Machines Corporation Apparatus system and method for distributing configuration parameter
US20100034130A1 (en) * 2008-08-01 2010-02-11 Tricci So Dynamic Discovery of Multicast Broadcast Services controller and Synchronization in Wireless Communication Systems
WO2010022562A1 (zh) * 2008-08-29 2010-03-04 上海贝尔阿尔卡特股份有限公司 一种向移动节点的本地代理注册的方法和外地代理组
US8516071B2 (en) * 2009-06-03 2013-08-20 Qualcomm Incorporated Systems and methods for creating virtual universal plug-and-play systems
US9155125B1 (en) * 2009-09-16 2015-10-06 Sprint Communications Company L.P. Location validation system and methods
US20120198080A1 (en) * 2010-08-04 2012-08-02 Yang Ju-Ting Method of Performing Multiple Connection and Related Communication Device
WO2012159350A1 (zh) * 2011-07-28 2012-11-29 华为技术有限公司 移动节点、其转交地址获取方法、系统及dhcp服务器
CN102957621A (zh) * 2011-08-31 2013-03-06 上海贝尔股份有限公司 一种基于位置和身份标识分离的通信网络系统及其设备
WO2015051321A1 (en) 2013-10-04 2015-04-09 Opanga Networks, Inc. Conditional pre-delivery of content to a user device
US10771340B2 (en) * 2017-03-16 2020-09-08 Samsung Electronics Co., Ltd. Automatic ethernet storage discovery in hyperscale datacenter environment
US20220345540A1 (en) * 2021-04-26 2022-10-27 Kyocera Document Solutions Inc. Electronic apparatus executing service in response to command from front end apparatus and front end apparatus managing electronic apparatus
US12445832B2 (en) 2023-02-14 2025-10-14 Hewlett Packard Enterprise Development Lp Change-of-authorization synchronization via cloud service

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10247946A (ja) * 1997-03-03 1998-09-14 Nippon Telegr & Teleph Corp <Ntt> ネットワーク接続方式および方法ならびにネームサーバ
JP3641128B2 (ja) * 1998-02-20 2005-04-20 株式会社東芝 移動計算機装置、移動計算機管理装置、移動計算機管理方法及び通信制御方法
JP3740320B2 (ja) * 1999-05-31 2006-02-01 キヤノン株式会社 デバイス検索システム及びデバイス検索方法
JP2001109780A (ja) * 1999-07-30 2001-04-20 Canon Inc 情報処理装置、情報処理システム、情報処理装置の制御方法及び記憶媒体
US7173917B1 (en) * 2000-03-31 2007-02-06 Nortel Networks Limited Unicast agent advertisement based on layer 2 and layer 3 motion detection
DE10120070A1 (de) * 2001-04-24 2002-11-07 Siemens Ag Vorrichtung und Verfahren zum Anpassen der Leitungseigenschaften bei hochbitratigen Datenübertragungen
GB2375022B8 (en) 2001-04-24 2012-05-02 Ip Access Ltd Configuration of Lan Hosts
KR20020091791A (ko) * 2001-05-30 2002-12-06 미츠비시 마테리알 가부시키가이샤 통신시스템 관리서버, 무선서버, 모바일 관리서버,정보관리서버
JP2003162462A (ja) * 2001-11-26 2003-06-06 Toshiba Corp 通信ネットワークシステム
KR100429292B1 (ko) * 2001-12-12 2004-04-29 주식회사 케이티프리텔 이동 아이피 네트워크에서 명시적 멀티캐스트 터널링서비스 방법 및 장치
TW200304298A (en) 2002-02-18 2003-09-16 Centrisoft Corp Software, systems and methods for managing a distributed network
US20030157945A1 (en) 2002-02-21 2003-08-21 Chen An Mei Method and apparatus for delivering server-originated information during a dormant packet data session
JP4043261B2 (ja) 2002-03-15 2008-02-06 沖電気工業株式会社 端末管理装置アドレス取得システム
CN1447234A (zh) 2002-03-27 2003-10-08 株式会社唯红 个人认证装置、销售管理装置
WO2003096588A2 (en) * 2002-04-15 2003-11-20 Flarion Technologies, Inc. Methods and apparatus for extending mobile ip
EP1427235B1 (en) * 2002-12-04 2013-05-15 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Connectivity plane routing
US20060153283A1 (en) 2005-01-13 2006-07-13 Scharf Louis L Interference cancellation in adjoint operators for communication receivers

Also Published As

Publication number Publication date
EP1749391A1 (en) 2007-02-07
WO2005099230A1 (en) 2005-10-20
CN1951087B (zh) 2012-10-10
US8363598B2 (en) 2013-01-29
US20050249223A1 (en) 2005-11-10
JP2007532067A (ja) 2007-11-08
CN102833245A (zh) 2012-12-19
KR20070002079A (ko) 2007-01-04
JP4638483B2 (ja) 2011-02-23
CN1951087A (zh) 2007-04-18
US7720024B2 (en) 2010-05-18
CN102833245B (zh) 2015-06-03
EP2346229A1 (en) 2011-07-20
US20100235477A1 (en) 2010-09-16
BRPI0509392A (pt) 2007-09-18
KR20090006222A (ko) 2009-01-14
EP1749391B1 (en) 2013-09-11
CA2561642A1 (en) 2005-10-20
KR100884434B1 (ko) 2009-02-19

Similar Documents

Publication Publication Date Title
US8363598B2 (en) Method and apparatus for obtaining server information in a wireless network
US8090828B2 (en) Method and apparatus for reusing DHCP addresses in home addresses of mobile IP clients
EP1665714B1 (en) Reachability maintainance of a moving network based on temporary name identifiers
US9307477B1 (en) Apparatus and method for interfacing wireless client device to multiple packet data networks
US8605572B1 (en) Packet data network specific addressing solutions with network-based mobility
JP5905722B2 (ja) 移動体ipのためのシステムおよび方法
US7447162B1 (en) Methods and apparatus for anchoring of mobile nodes using DNS
KR20050060638A (ko) 휴대 인터넷 망에서의 인터넷 프로토콜 주소 관리 장치 및그 방법
KR100976442B1 (ko) 이동 노드와 이를 이용한 ip 이동성 제공 방법
CN101754173A (zh) 分配家乡地址、利用该家乡地址传输报文的方法和系统
KR101125209B1 (ko) 사용자 이동성 관리방법
HK1105259A (en) Method and apparatus for obtaining server information in a wireless network
Chen IDNS: An efficient approach to portability and mobility support
MXPA06002816A (es) Mantenimiento de la alcanzabilidad de una red movil basada en identificadores de nombres temporales