ES2263791T3 - Metodo, medio de memoria, red de ordenadores y dispositivo para la comunicacion de datos en modo bilateral con dispositivos radioelectricos. - Google Patents

Metodo, medio de memoria, red de ordenadores y dispositivo para la comunicacion de datos en modo bilateral con dispositivos radioelectricos.

Info

Publication number
ES2263791T3
ES2263791T3 ES02744283T ES02744283T ES2263791T3 ES 2263791 T3 ES2263791 T3 ES 2263791T3 ES 02744283 T ES02744283 T ES 02744283T ES 02744283 T ES02744283 T ES 02744283T ES 2263791 T3 ES2263791 T3 ES 2263791T3
Authority
ES
Spain
Prior art keywords
address
network
radio
public
proxy
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
ES02744283T
Other languages
English (en)
Inventor
Samir Narendra Mehta
Mazin Ramadan
Geoffrey S. Heller
Vineet R. Sharma
Markus L. Jansen
Edward L. Gow
Ngochan T. Nguyen
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.)
Motorola Mobility LLC
Original Assignee
4thPass 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 4thPass Inc filed Critical 4thPass Inc
Application granted granted Critical
Publication of ES2263791T3 publication Critical patent/ES2263791T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2514—Translation of Internet protocol [IP] addresses between local and global 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/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2567—NAT traversal for reachability, e.g. inquiring the address of a correspondent behind a NAT server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2575—NAT traversal using address mapping retrieval, e.g. simple traversal of user datagram protocol through session traversal utilities for NAT [STUN]
    • 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/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • 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/45—Network directories; Name-to-address mapping
    • H04L61/4557—Directories for hybrid networks, e.g. including telephone numbers
    • 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/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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/5038—Address allocation for local use, e.g. in LAN or USB networks, or in a controller area network [CAN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • 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
    • 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/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Radar Systems Or Details Thereof (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Un método para ser utilizado en una red de ordenadores (210), que está conectada a una red de comunicaciones radioeléctricas (230) a través de un sistema Proxy de gestión de direcciones, AMPS (220), en el que la red de comunicaciones radioeléctricas sirve para la conexión a un dispositivo radioeléctrico (240) que tenga un identificador único asociado (601) a la red de ordenadores a través de un canal de comunicación bidireccional, utilizando una dirección de la red privada (602) de la red de comunicaciones radioeléctricas, en el que el sistema Proxy (220) de gestión de direcciones tiene una dirección de red publica (631) de la red de ordenadores y la red de ordenadores sirviendo para conectar un dispositivo cableado (201, 202, 203) a la red radioeléctrica, utilizando una dirección de red pública (631) de la red de ordenadores, que comprende: bajo el control del dispositivo cableado (201, 202, 203), utilizar la dirección de red pública (631) del sistema Proxy de gestión de direcciones (220),enviando (501) una petición al sistema Proxy de gestión de direcciones para una indicación de una dirección de red pública (631) de la red de ordenadores, para utilizarla para la comunicación con el dispositivo radioeléctrico, indicando la petición el identificador único (601) asociado con el dispositivo radioeléctrico (240); bajo el control del sistema Proxy de gestión de direcciones (220), recibir la petición de la indicación de la dirección de la red pública (631); determinar dinámicamente (702) una dirección de red pública (631) de una pluralidad de direcciones de la red publica disponibles de la red de ordenadores (210); asociar (704) la dirección (631) de la red pública determinada con la dirección (602) de la red privada del dispositivo radioeléctrico (240) que corresponda al identificador (601) único indicado; y enviar (502) otra indicación de la dirección (631) de la red pública determinada al dispositivo cableado; y bajo el control del dispositivo cableado (201, 202, 203), recibir (801) la dirección (631) de la red pública indicada; y enviar (806) datos al dispositivo radioeléctrico (240) utilizando la dirección de la red publica indicada (631), de forma tal que el dispositivo cableado (201, 202, 203) se de cuenta que el dispositivo cableado está en comunicación directamente con el dispositivo radioeléctrico.

Description

Método, medio de memoria, red de ordenadores y dispositivo para la comunicación de datos en modo bilateral con dispositivos radioeléctricos.
Antecedentes de la invención Campo de la invención
La presente invención está relacionada con los métodos y sistemas para iniciar la comunicación con dispositivos radioeléctricos, y en particular con los métodos y sistemas para iniciar la comunicación con un dispositivo en una red privada de un dispositivo en una red pública para conseguir la conectividad virtual de extremo a extremo.
Información de los antecedentes
La necesidad de conectar los ordenadores interconectados en red, conjuntamente con otras redes de ordenadores, ha llegado a ser importante en forma creciente, ya que nuestra sociedad se esfuerza por conseguir la comunicación de negocios y por razones personales a un nivel internacional. Esta necesidad ha promovido a que la comunidad técnica haya diseñado formas para interconectar dispositivos en distintas redes físicas, de forma que los dispositivos en redes heterogéneas u homogéneas puedan comunicarse entre sí de una forma uniforme (o estándar). Dicha tecnología de la interconexión se denomina con frecuencia como "interconexión de redes", "interconexiones de redes", o sencillamente "inter-redes". Una implementación de la interconexión de redes globales es la red Internet (con la primera letra en mayúscula para distinguirla de "inter-redes" en general), tal como se desarrolló originalmente por ARPA, NSF, etc., para los fines educaciones y de gobierno. La red de Internet, en su versión ampliada actual, existe como una infraestructura compleja de redes principales que conectan con las redes alrededor del mundo. Otras redes (locales, regionales, privadas, o públicas) se encuentran conectadas a la red principal de Internet por los medios de pasarelas o enrutadores (conocidos también como servidores de pasarelas, sistemas de pasarelas, servidores de enrutadores, y sistemas de enrutadores). Para los fines de este documento, el término "enrutador" ó "pasarela", utilizados solos o para modificar otro nombre, se utilizan de forma intercambiable, y se referirán en general a cualquier equipamiento o a un software, subsistema, sistema, o código que sea capaz de transferir un paquete de datos (a cualquier nivel de la red o de transferencia de datos físicos) entre dos o más máquinas homogéneas o heterogéneas, sistemas, o subsistemas, sin tener en cuenta una pasarela/enrutador en particular o servicio similar. En el entorno de Internet, la presencia de un enrutador o pasarela indica típicamente la capacidad de enrutar un datagrama de Internet a otro enrutador o máquina. Las máquinas que tienen por fin la ejecución de aplicaciones se refieren en general a la utilizando de terminología de interconexión de redes como "servidores" o "máquinas servidoras"; para los fines en este caso, un enrutador/pasarela puede una función de una máquina servidora o bien puede ser un dispositivo independiente.
En el entorno de Internet, las distintas redes y dispositivos se comunican utilizando protocolos de redes estándar y modelos, tales como TCP/IP (ó bien UDP/IP). Aunque para el fin de este documento, se supondrá que el lector está familiarizado con los conceptos de la interconexión de redes, protocolos y estándares, se proporciona un sumario breve en este documento para facilidad de utilización. Puede obtenerse información amplia de los antecedentes de la interconexión de redes, inter-redes, Internet, y términos relacionados y tecnología en el libro "Redes de ordenadores", de Tanenbaum A., Prentice-Hall, Nueva York, 3ª edición, 1996, y en el libro ``Interconexión de redes con TCP/IP, Principios, Protocolos y Arquitecturas, de Corner D., Prentice-Hall, Nueva York, 4ª edición, 2000.
Los sistemas TCP/IP y UDP/IP (o con frecuencia denominados como "UDP") se refieren a una combinación de la capa de transporte popular y a un protocolo de la capa de redes (se encuentran disponibles otros protocolos también en cada una de estas capas). El término "IP" en TCP/IP se refiere al "Protocolo de Internet", y es un protocolo de la capa de redes que define la forma de organización y de representación de los datos (el formato y significado de los datagramas) y las transacciones de comunicaciones utilizadas para enrutar las mismas. El término TCP ("Protocolo de control de transmisión") y UDP ("protocolo del datagrama de usuario"), que son ambos protocolos de la capa de transporte que pueden implementarse en la parte superior de un protocolo IP, soportan la base de la conexión y la transferencia de los datos sin conexiones, respectivamente. La transferencia de datos basándose en conexiones implica que un dispositivo fuente y de destino solicita una conexión, y que envía entonces los datos entre sí, a través de la conexión "virtual" de una forma que está secuenciada (y que típicamente incluye mecanismos de acuse de recibo). El término "virtual" en este caso implica que aunque la conexión no está necesariamente cableada físicamente, la conexión aparece que proporciona un conducto directo entre una fuente (solicitante) y un destino (receptor). Los datos circulan realmente a través de capas de protocolo inferiores para ser transmitidos eventualmente a través de un medio físico. La transferencia de datos sin conexión implique la fuente envía un datagrama al destino, pero no asegura la entrega o bien que los datos lleguen en un orden en particular.
El protocolo IP define también un mecanismo de direccionamiento de red uniforme, de forma que las máquinas que implementan los protocolos que utilizan el sistema IP, tal como TCP ó UDP, son capaces de especificar las fuentes y los destinos para sus transferencias de datos. El mecanismo de direccionamiento de la red especifica una dirección abstracta y un protocolo de unión para la correlación de la dirección abstracta con una dirección de hardware físico. Para los fines de esta descripción, el mecanismo de direccionamiento de la red uniforme se denominará genéricamente como una "dirección IP". Las direcciones IP están escritas con frecuencia con una notación "decimal con puntos", la cual especifica una dirección tal como "w.x.y.z" (por ejemplo, en una dirección de 32 bits, cada letra designa un byte de información). Por ejemplo, una dirección IP tal como "192.251.0.1" puede especificar un equipo servidor en la red "192", subred "251", y el dominio "0". Utilizando el sistema IP, se reservan típicamente una gama de direcciones para el uso de redes privadas, y las direcciones IP restantes se reservan para otros usos o para las direcciones públicas (enrutables, las cuales se asigna por una organización de una autoridad. Las múltiples redes privadas pueden asignar las mismas direcciones IP (enrutables) internamente (actualmente la entidad Internet Corporation for Assigned Names and Numbers, ICANN), pero utilizan las direcciones IP publicas exclusivas para conectarse a Internet. Por ejemplo, en las redes de Clase B (las cuales utilizan convenciones de direccionamiento basadas en clases, permiten hasta 254 equipos servidores cada una), las direcciones privadas pueden variar desde 192.168.0.0 hasta 192.168.255.0. Las convenciones de direccionamiento son bien conocidas por los técnicos especializados en el arte, y se suponen como conocidas por el lector. Para los fines de esta solicitud, una dirección IP se comprende que tendrá sentido en un entorno de interconexión de redes en particular, aunque puede referirse a una dirección IP de Internet.
Una red que soporte IP puede conectarse a otra red basada en TCP/IP o en UDP/IP o en Internet, mediante el suministro de un enrutador que envíe los datos a otro enrutador o equipo servidor basándose en una dirección IP. El enrutador (o servidor/servicio de enrutamiento) contiene típicamente una tabla de enrutamiento, la cual determina la maquina a la cual se envía un datagrama (y opcionalmente a que puerto), dada una dirección IP de destino. La dirección IP identifica exclusivamente un equipo enrutador/servidor, y en una red TCP/IP típica, puede correlacionarse con un nombre de una cadena que identifique, por ejemplo, un equipo en particular como parte de un dominio grande. (Aunque se denomina aquí con frecuencia como red basada en TCP/IP, pero tal como reconocerá el técnico especializado en el arte, la red puede estar basada también en UDP (sin conexiones), y pudiendo soportar otro sistema de gestión de la sesión).
En una (inter)red TCP/IP típica, los equipos están organizados de acuerdo con una jerarquía de nombres. Una de dichas jerarquías es el denominado Sistema de Nombres de Dominios ("DNS"), el cual especifica la forma en que un equipo en particular está conectado a los demás. (El término DNS se utiliza algunas veces parad identificar también a un servidor o servicio que implemente el protocolo DNS). Por ejemplo, la cadena "iniciales_equipo, 4paso.proveedor_servicio.com" puede utilizarse para especificar un equipo que le pertenezca a Vd. y conectado a la LAN de la compañía 4paso, el cual a su vez esté conectado a una WAN (red de área amplia) del proveedor_servicio. Las denominaciones TCP/IP y UDP/IP definen herramientas/librerías para el sistema del cliente a utilizar para determinar una dirección IP (dirección lógica de Internet) dado un nombre de cadena de un enrutador/equipo en particular. Una de tales herramientas puede denominarse como consulta DNS, e incluye por ejemplo un API denominado "ConseguirServidorPorNombre". La cadena ConseguirServidorPorNombre devuelve una dirección IP dada una cadena. El equipo servidor que implementa el DNS estándar para una organización, red o subred en particular se denomina aquí como sencillamente un DNS, aunque los servicios DNS pueden suministrarse conjuntamente con otros servicios de interconexión de las redes en un único equipo físico.
La figura 1 es un diagrama de bloques a modo de ejemplo de una comunicación básica de Internet, para enviar un paquete de datos utilizando el sistema TCP/IP o UDP/IP. En la figura 1, el equipo servidor 101 se muestra conectado a Internet 110 a través del cable 102. Se muestran otros dispositivos cableados, tal como los equipos servidores 140 y 141, conectados a una red privada 130 (o pública), que podría ser por ejemplo una red de área local (LAN). Los dispositivos en la red 130 se comunican a través de Internet 110 por medio de un equipo adicional, un enrutador 121, el cual se muestra conectado a través de un cable (por ejemplo, una línea telefónica). El servidor DNS 120 se muestra conectado también a través de un cable, a Internet 110. En la operación típica básica de dispositivo fuente (servidor) 110, al intentar enviar un paquete de datos al dispositivo 140 (a través de TCP o UDP), se ejecuta primeramente una consulta DNS para obtener una dirección IP que corresponda a un nombre de cadena que representa el dispositivo 140. Por ejemplo, para enviar datos a "iniciales_equipo.4paso.servicio_proveedor.com", DNS 120, puede corresponder a un servidor DNS del "4paso.com". Este servidor conoce como localizar los equipos en su "dominio", por ejemplo, las "iniciales_máquina", y pudiendo recuperar sus direcciones IP públicas correspondientes. Al determinar la dirección IP correcta (pública), la DNS 120 retorna esta dirección al dispositivo fuente 101. El dispositivo fuente 101 puede abrir una conexión TCP para comunicar con el dispositivo de destino 140, o sencillamente enviar paquetes por UDP o bien otro protocolo sin conexión, utilizando la dirección IP pública devuelta. El documento EP-A-1003315 expone un método en una red de ordenadores de acuerdo con la parte del preámbulo de la reivindicación 1.
Breve sumario de la invención
La presente invención está definida exclusivamente por las reivindicaciones independientes 1, 13-17. Las reivindicaciones dependientes están relacionadas con las realizaciones preferidas.
Las realizaciones de la presente invención proporcionan el ordenador y las realizaciones de la presente invención proporcionan los métodos basados en ordenadores y redes, y sistemas para la comunicación bidireccional de dos vías, con dispositivos radioeléctricos, utilizando protocolos basados en conexiones o protocolos sin conexiones, tales como por ejemplo, TCP/IP y UDP/IP. Las realizaciones a modo de ejemplo proporcionan Sistemas Proxy de Gestión de Direcciones ("APMS"), los cuales habilitan a los dispositivos y sistemas conectados a una red pública, tal como Internet, para poder iniciar la comunicación y enviar datos a los dispositivos radioeléctricos conectados a una red radioeléctrica privada, sin exponer las direcciones privadas no enrutables de estos dispositivos radioeléctricos. El sistema AMPS asigna una dirección de red pública (enrutable) para la utilización temporal mediante un dispositivo de consulta en una red pública externa, para comunicar con un dispositivo radioeléctrico en una red radioeléctrica privada. En una realización se mantiene un conjunto de direcciones públicas, por ejemplo unas direcciones IP públicas, mediante el sistema AMPS, y asignadas dinámicamente a dispositivos de redes radioeléctricas, según se precise. La correlación de una dirección pública temporal con respecto a la dirección privada de un dispositivo radioeléctrico se mantiene y se actualiza en forma transparente mediante el AMPS, utilizando tablas y otras estructuras de datos de correlación.
En una realización, el sistema AMPS comprende uno o más servidores modificados DNS/AP, uno o más Proxy/
Enrutadores de Direcciones, un Servidor de Datos de Gestión de Direcciones, uno o más Depósitos de Datos de Gestión de Direcciones, y opcionalmente un equilibrador de cargas. El servidor DNS/API del AMPS recibe una petición desde un dispositivo en una red pública para un dispositivo radioeléctrico en particular, y retorna una dirección pública temporal apropiada, la cual está correlacionada con la dirección privada del dispositivo radioeléctrica. La dirección pública es utilizable entonces por el dispositivo de la red pública externa, para enviar datos al dispositivo radioeléctrico. La dirección pública temporal, por ejemplo, es una dirección asociada con uno de los Proxy/Enrutadores de Direcciones, los cuales están conectados a la red pública externa, y teniendo acceso a las direcciones privadas en la red radioeléctrica privada. En algunos casos, el dispositivo en la red pública que desee enviar datos al dispositivo radioeléctrico, utiliza un protocolo basado en conexiones, tal como TCP/IP para enviar los datos. En otros casos, el dispositivo utiliza un protocolo sin conexiones, tal como el sistema UDP (UDP/IP) para enviar los datos.
De acuerdo con una solución, el sistema AMPS proporciona un servidor DNS modificado que cambia lo que devuelve como el resultado de una llamada a una función de consulta DNS estándar, tal como ConseguirServidorPorNombre. En otra solución, el AMPS implementa un API especializado para un dispositivo en una red pública, a utilizar para consultar una dirección pública de un dispositivo radioeléctrico asignado. Utilizando una implementación API especializada en conjunción con el Protocolo de Internet, el AMPS puede correlacionar la dirección privada con respecto a direcciones que comprendan direcciones IP solamente, o puede correlacionar con un par (dirección IP, puerto). Esta última implementación puede extenderse a la utilidad de un espacio de direcciones públicas en particular.
Las técnicas AMPS pueden ser utilizadas mediante un dispositivo cableado en una red privada o pública, y mediante un dispositivo radioeléctrica en dicha red, actuando la capacidad de un dispositivo fuente, en tanto que el dispositivo esté conectado a una red pública que pueda direccionar o ser direccionado por el sistema AMPS. Así pues, los mecanismos AMPS pueden ser utilizados por dispositivos en distintas redes radioeléctricas para comunicarse entre sí. Además de ello, el mecanismo AMPS puede ser utilizado con otras inter-redes, tales como las redes ATM, y con protocolos de transferencia de datos distintos al sistema TCP/IP o UDP.
Para asegurar un grado mayor de seguridad, de acuerdo con una realización, el AMPS mantiene el parámetro del Tiempo de Vida (TTL) con cada correlación de direcciones. De esta forma, una vez que el valor TTL indique que haya concluido la correlación, el AMP puede destruir la correlación, y también cualquier conexión. Además de ello, en algunas realizaciones, el AMPS inserta también un sello del instante de la hora en sus propias tablas de correlación. Después de un cierto periodo de tiempo límite basándose en el sello de la hora, el AMPS puede destruir la correlación, forzando por tanto una nueva correlación para iniciarse sobre una base periódica.
Breve descripción de los dibujos
La figura 1 es un diagrama de bloques a modo de ejemplo de una comunicación básica por Internet, para enviar un paquete de datos utilizando el sistema TCP/IP o UDP/IP.
La figura 2 es un diagrama de bloques de un Sistema de Proxy de Gestión de Direcciones, utilizado en una comunicación bidireccional con un dispositivo radioeléctrico.
La figura 3 es un diagrama de bloques a modo de ejemplo, de los componentes de de un Sistema de Proxy de Gestión de Direcciones.
La figura 4 es un diagrama de bloques a modo de ejemplo de un sistema de ordenadores de propósito general, para la puesta en marcha de las realizaciones del Sistema de Proxy de Gestión de Direcciones.
La figura 5 es un diagrama de flujo a modo de ejemplo del proceso ejecutado por un dispositivo en una red pública para enviar datos a un dispositivo radioeléctrico localizado en una red radioeléctrica, utilizando el Sistema de Proxy de Gestión de Direcciones.
La figura 6 es un diagrama de bloques a modo de ejemplo de las tablas del depósito de datos del Sistema Proxy de Gestión de Direcciones, utilizadas para soportar las rutinas de los servidores DNS/API y los Proxy/Enrutadores de Direcciones.
La figura 7 es un diagrama de flujo a modo de ejemplo de una rutina de ejemplo provista por el servidor DNS/API del Sistema Proxy de Gestión de Direcciones para retornar una dirección pública que corresponda a un identificador exclusivo asignado.
La figura 8 es un diagrama de flujo a modo de ejemplo de una rutina de ejemplo dentro del Proxy/Enrutador de Direcciones de un Sistema de Proxy de Gestión de Direcciones que recibe datos.
Descripción detallada de la invención
Las realizaciones de la presente invención proporcionan métodos y sistemas basados en ordenadores y basados en redes, para una comunicación bidireccional de dos vías, con dispositivos radioeléctricos que utilizan protocolos basados en conexiones y sin conexiones, tales como por ejemplo, TCP/IP y UDP/IP. Las realizaciones del ejemplo proporcionan un Sistema de Proxy de Gestión de Direcciones ("AMPS", el cual permite que dispositivos y sistemas conectados a Internet pública, tal como Internet, puedan iniciar la comunicación, y poder enviar datos a dispositivos radioeléctricos conectados a una red radioeléctrica privada, sin exponer las direcciones privadas enrutables de estos dispositivos radioeléctricos.
En los sistemas existentes, la comunicación de datos (comunicación en un canal de datos) entre un dispositivo radioeléctrico que está conectado a una red radioeléctrica privada, y un dispositivo cableado conectado a una red cableada pública (por ejemplo, Internet), puede iniciarse solamente por el dispositivo radioeléctrico. Algunos portadores han asignado direcciones IP públicas fijas a los dispositivos radioeléctricos; sin embargo, los dispositivos radioeléctricos necesitan tener programas cliente (por ejemplo, una pila UDP) con capacidad de recepción y de gestión de los paquetes de comunicación entrantes. Además de ello, estos dispositivos radioeléctricos son entonces parte de una red radioeléctrica pública y no de una red radioeléctrica privada. Puesto que las direcciones IP públicas han llegado a ser un producto escaso y muy costoso de mantener en una red de millones de dispositivos, los portadores no pueden con sentido práctico tener una dirección IP pública fija para cada dispositivo de su red. (Aunque el movimiento hacia IPv6 permitirá más direcciones, las definiciones de IPv4 actual son limitadas, y siendo alto el numero potencial de los usuarios radioeléctricos abonados a los grandes portadores. En algunas zonas del mundo, el esquema de direcciones públicas actual es incluso más limitado). Además de ello, dicha capacidad de direccionamiento expondría a cada dispositivo a mayores riesgos de seguridad, porque cada dispositivo mencionado es parte de una red accesible pública, y llegaría a ser difícil implementar y reforzar las medidas de seguridad. Así pues, la asignación de direcciones IP privadas a los dispositivos es lo preferido en las redes radioeléctricas existentes, con respecto a la asignación de direcciones IP fijas públicas a los dispositivos. Cuando las redes radioeléctricas son privadas, las asignaciones (o direcciones) de los dispositivos radioeléctricos se ocultan intencionalmente con respecto a la visión pública mediante la infraestructura del sistema del portador (o del operador, tal como de se denomina en algunos países).
Los sistemas radioeléctricos en las redes privadas utilizan técnicas similares a la tecnología de Traducción de Direcciones de Red (NAT), para enviar datos desde un dispositivo radioeléctrico al mundo de las interconexiones de redes públicas. En una infraestructura de un operador típico que utilice una red privada, el dispositivo radioeléctrico se "registra" por sí mismo en la infraestructura del operador cuando se enciende (o en otras circunstancias, cuando el dispositivo intenta iniciar los servicios de datos). El operador asigna dinámicamente el dispositivo radioeléctrico una dirección no enrutable transitoria para la dirección IP pública, que se almacena en una base de datos del operador interno, y que se gestiona por los servicios del operador tal como un servidor RADIUS.
El trayecto en curso tomado por los datos al ser enviados desde un dispositivo radioeléctrico en una red privada a Internet (o viceversa) depende en gran parte a la infraestructura de la red, de la tecnología del operador y del propietario. Aunque han emergido varios estándares, estos son muy diversos en su naturaleza. En una red GPRS, por ejemplo, el SGSN (nodo de GPRS de servicio) gestiona la comunicación con los dispositivos radioeléctricos; mientras que el SGSN opera con un GGSN (Nodo GPRS de pasarela), para conectar con la red de Internet. Sin importar la red móvil utilizada, la comunicación de datos entre un dispositivo radioeléctrico e Internet incluye varios elementos de la red tal como GGSN (o elementos similares, basándose en GPRS, GSM, CDMA o cualquier otra red, servidores DNS, enrutadores y pasarelas.
Existen instalaciones limitadas para enviar mensajes en secuencia desde un dispositivo cableado en una red pública a un dispositivo móvil en una red radioeléctrica (con una dirección privada), dependiente de nuevo del operador y de la tecnología de la red. El protocolo SMS (sistema de mensajes cortos) define un formato de tales mensajes, pero no proporciona ninguna guía para la estructura subyacente o transferencia de datos. Además de ello, dichos mensajes son de una longitud fija (muy corta), y utilizan un canal especializado para enviar la información de control (un canal de señalización) y no un canal de datos.
En consecuencia, no existen mecanismos para configurar un canal de comunicación bidireccional, para comunicarse con los dispositivos radioeléctricos que estén conectados a través de una red privada a la infraestructura del operador, utilizando un esquema de direccionamiento estándar. Tampoco existe un mecanismo para iniciar la comunicación con dicho dispositivo radioeléctrico desde un dispositivo conectado a una red pública. Así pues, las realizaciones de los sistemas existentes no son capaces de soportar ninguna clase del empuje programático de datos a los dispositivos radioeléctricos desde los dispositivos cableados que residen externamente a la estructura del operador. Además de ello, los mensajes enviados desde el dispositivo radioeléctrico a un dispositivo en una red pública (o cableada) no pueden ser respondido directamente por el dispositivo cableado, porque la dirección del dispositivo radioeléctrico contenido en el mensaje no puede ser ya válida. Además de ello, no es posible utilizar estos sistemas para proporcionar el aprovisionamiento radioeléctrico de aplicaciones y enviar otros códigos a un dispositivo radioeléctrico desde un dispositivo externo a la infraestructura del operador. El aprovisionamiento radioeléctrico y las técnicas relacionadas para el aprovisionamiento dinámico y la descarga de aplicaciones a los dispositivos radioeléctricos se exponen con detalle en el documento WO-0244892, titulado "Método y Sistema para Mantener y Distribuir Aplicaciones Radioeléctricas", publicado con fecha 6.6.2002. Así pues, es altamente deseable un mecanismo para permitir que un dispositivo externo con una dirección IP pública pueda iniciar una comunicación bidireccional con un dispositivo radioeléctrico.
El Sistema de Proxy de Gestión de Direcciones consigue la comunicación bidireccional iniciada en dos vías, mediante la implementación de un servidor DNS modificado, y atendiendo como un proxy/enrutador para los dispositivos en la red radioeléctrica privada, conforme hacen de interfaz con el mundo de la interconexión de redes cableadas públicas. En resumen, se mantiene un grupo abierto de direcciones públicas y se distribuye dinámicamente entre los dispositivos radioeléctricos activos, según sea preciso por el sistema AMPS. La figura 2 es un diagrama de bloques de un Sistema de Proxy de Gestión de Direcciones a modo de ejemplo utilizado en la comunicación bidireccional con un dispositivo radioeléctrico. El término "bidireccional" tal como se utiliza aquí significa que los trayectos de los datos y las comunicaciones pueden fluir en cualquier dirección entre dos sistemas de puntos extremos. La figura 2 muestra los dispositivos cableados 201, 202, y 203 conectados a la red pública 210. El técnico especializado en el arte reconocerá que estos dispositivos podrían ser conectados a otra red privada o pública, la cual se conectaría entonces mediante uno o más dispositivos cableados a la red pública 210, consiguiente por tanto la funcionalidad tal como se ha expuesto aquí. Cualquier variación proporciona una funcionalidad equivalente, y se encuentra contemplada explícitamente y que es supuestamente parte de la presente invención. En la parte radioeléctrica, los AMPS 220, actuando en su capacidad como un Proxy(y enrutador) para los dispositivos radioeléctricos, se muestran ambos conectados a través de cable a la red pública 210, y a través de elementos de la infraestructura del operador estándar (no mostrados) a la red radioeléctrica 230. Se supone que el lector tiene un conocimiento operativo de los elementos de una estructura del operador, y los mecanismos básicos para enrutar y mecanismos para convertir los paquetes de una red cableada a una red radioeléctrica. Pueden utilizar una tecnología analógica o digital, y pueden requerir conversiones de protocolos con el fin de enviar datos físicos y transmitirlos, por ejemplo, a través de un satélite, y finalmente al dispositivo radioeléctrico. La información de los antecedentes detallados sobre la tecnología radioeléctrica y los mecanismos de enrutado radioeléctrico se encuentra descrita en el libro "Comunicaciones y Redes Radioeléctricas", de Stallings, W., Prentice-Hall, N.J., 2002. En la figura 2, el dispositivo radioeléctrico 240 se muestra conectado a través de varios elementos radioeléctricos (no mostrados) a la red radioeléctrica 230.
Durante el funcionamiento, cuando un dispositivo cableado tal como el dispositivo cableado 201, desea enviar datos al dispositivo radioeléctrico 240, el dispositivo cableado necesita primeramente determinar la localización de la dirección del dispositivo radioeléctrico 240 en la red pública 210. No obstante, tal como puede observarse en la figura 2, el dispositivo radioeléctrico 240 no está conectado directamente a la red pública 210. Así pues, el dispositivo cableado tiene que utilizar el Sistema Proxy de Gestión de Direcciones 220, para determinar una dirección enrutable (pública), a la cual poder enviar los datos destinados para el dispositivo radioeléctrico 240. Para llevar a cabo esta tarea, el dispositivo radioeléctrico 201 ejecuta una consulta (por ejemplo, una consulta DNS modificada), para localizar una dirección pública enrutable que corresponda al dispositivo radioeléctrico 240. El Sistema Proxy de Gestión de Direcciones 220 recibe la consulta y determina y asigna una dirección pública (enrutable) desde un depósito de direcciones, cuya dirección pueda ser utilizada como dirección de destino para los paquetes de datos dirigidos al dispositivo radioeléctrico 240. Se observará que aunque se muestra aquí como una consulta DNA, el Sistema Proxy de Gestión de Direcciones, tal como se describirá más adelante, modifica la implementación de la consulta DNS para gestionar la tecnología del dispositivo radioeléctrico, y/o proporciona una alternativa API para determinar una dirección enrutable adecuada. Una vez que el Sistema Proxy de Gestión de Direcciones haya devuelto una dirección enrutable al dispositivo radioeléctrico 201, el dispositivo cableado 201 podrá enviar datos a dicha dirección. El Sistema Proxy de Gestión de Direcciones 220 recibe los datos, convierte los formatos y protocolos, etc., según sea necesario, y envía los datos convertidos a través de la red radioeléctrica 230 al dispositivo radioeléctrico 240.
La figura 3 es un diagrama de bloques a modo de ejemplo de los componentes de un Sistema Proxy de Gestión de Direcciones a modo de ejemplo en una realización, en donde el Sistema Proxy de Gestión de Direcciones (AMPS) comprende uno o más servidores modificados DNS/API 302, uno o más Proxy/Enrutadores de Direcciones 305, un Servidor de Datos de Gestión de Direcciones 303, que gestiona una base de datos o bien otros depósitos tales como el Deposito de Datos de Gestiona de Direcciones 304, y opcionalmente un equilibrador de cargas 301. Los servidores DNS/API 302 están conectados individualmente a la red pública 310 o bien están conectados al equilibrador de cargas 301, el cual a su vez está conectado a la red pública 310. De forma similar, cada Proxy/Enrutador de Direcciones 310 está conectado también a la red pública 310, a través de la dirección enrutable (pública) a la cual se enviaron los datos de la red externa 310, destinados para los dispositivos radioeléctricos. Los servidores DNS/API 302 son implementaciones modificadas de un servidor DNS para añadir necesariamente una funcionalidad para comunicarse con los dispositivos radioeléctricos, o bien son servidores que implementan una o más API especializadas, tal como se describirá más adelante. Los servidores DNS/API 302 se utilizan el Servidor de Datos de Gestión de Direcciones 303 para ayudar a correlacionar un identificador exclusivo (por ejemplo, un nombre de cadena) para un dispositivo radioeléctrico de una dirección pública en una red pública 310. El depósito de direcciones públicas se mantiene también por el Servidor de Datos de Gestión de Direcciones 303 y el Depósito de Datos 304. El servidor de Datos de Gestión de Direcciones 303 y el Depósito de Datos de Gestión de Direcciones 304 pueden ser implementados utilizando la tecnología de la base de datos existente, por ejemplo la tecnología ODBC, o bien pueden implementarse como una estructura tal como un sencillo fichero de texto. El técnico especializado en el arte observará que pueden utilizarse cualesquiera realización para almacenar un conjunto de tablas, datos, listas o correlaciones. Cada Proxy/Enrutador de Direcciones 305 puede utilizar también el Servidor de Datos de Direcciones 303, o equivalente, para crear y actualizar una serie de tablas de enrutado que se utilicen para asignar direcciones públicas a los dispositivos radioeléctricos, según sea necesario, y para actualizar las distintas correlaciones entre las direcciones públicas y las direcciones no enrutables (privadas) de los dispositivos radioeléctricos. Las tablas y correlaciones que se mantengan en nombre de los servidores 302 de las DNS/API y los Proxy/Enrutadores de Direcciones 305 por el Servidor de Datos de Gestión de Direcciones 303 se encuentran descritas más adelante con referencia a la figura 6.
Aunque las técnicas de los AMPS son aplicables en general a cualquier dispositivo cableado en comunicación con un dispositivo radioeléctrico, la frase "red pública" (o "red cableada") se utiliza generalmente para implicar cualquier tipo de entorno interconectado, incluyendo una red pública o un núcleo de la red que se encuentre en la línea conectada a una o más redes privadas o públicas. Además de ello, aunque los ejemplos aquí descritos se refieren frecuentemente a Internet, el técnico especializado en el arte observará que los conceptos y las invenciones descritos son aplicables a otras formas y realizaciones de la interconexión de las redes, incluyendo por ejemplo las redes del tipo ATM. Así pues, las técnicas de la presente invención pueden ser utilizadas también por un dispositivo en una primera red radioeléctrica, para comunicarse con otro dispositivo radioeléctrico en una segunda red, en donde cada dispositivo termina la comunicación con el Proxy/Enrutador de Direcciones de la otra red. Este escenario es factible porque cada red radioeléctrica (o la infraestructura del operador) está conectada a un Proxy/Enrutador que está también conectado (a través de una dirección pública) a una red pública. Además de ello, aunque la red pública se denomina también como una red cableada, el técnico especializado en el arte observará que podrá ser implementada cualquier red que exponga direcciones enrutables (públicas). Así pues, una red radioeléctrica con dirección pública exclusiva (y enrutable) podrá utilizar también las técnicas de la presente invención, para ejecutar la comunicación bidireccional. Así mismo, el técnico especializado en el arte observará que los términos tales como un dispositivo radioeléctrico, teléfono, móvil de mano, etc., se utilizan de forma intercambiable, para indicar cualquier tipo de dispositivo radioeléctrico que sea capaz de operar con los AMPS. Además de ello, los términos pueden tener significados alternativos que pueden o no mencionarse explícitamente, y que un técnico especializado en el arte observará que todas las mencionadas variaciones tiene por objeto su inclusión.
Las realizaciones a modo de ejemplo aquí descritas proporcionan aplicaciones, herramientas, estructuras de datos y demás soportes para implementar las correlaciones de direcciones privadas a públicas, en una o más redes cableadas o radioeléctricas, a utilizar para la comunicación bidireccional. El técnico especializado en el arte observará que pueden utilizarse otras realizaciones de los métodos y sistemas de la presente invención para muchos otros fines, incluyendo el suministro de información y/o datos o códigos desde una red pública, tal como Internet a un dispositivo radioeléctrico. Además de ello, aunque esta descripción se refiere principalmente a los "datos" tal como son enviados a través de las redes, el técnico especializado en el arte observará que todos los tipos de datos pueden ser comunicados utilizando las técnicas aquí descritas, incluyendo aunque sin limitación, el texto, gráficos, audio, y vídeo.
Así mismo, en la siguiente descripción, se envían numerosos detalles específicos, tales como los formatos de los datos y los sistemas de la presente invención. El técnico especializado en el arte observará, no obstante, que la presente invención puede llevarse a la práctica también sin algunos de los detalles específicos aquí descritos, o con otros detalles específicos, tales como los cambios con respecto al orden del flujo de los códigos.
La figura 4 es un ejemplo de un diagrama de bloques de un sistema de ordenadores de propósito general para realizar las realizaciones del Sistema Proxy de Gestión de Direcciones. El sistema de ordenadores de propósito general 400 puede comprender uno o más sistemas de ordenadores servidores y/o clientes y puede abarcar localizaciones distribuidas. Además de ello, cada bloque puede representar uno o más bloques mencionados, según sea lo apropiado para una realización específica o bien pueden combinarse con otros bloques. Los distintos bloques del Sistema Proxy de Gestión de Direcciones 410 pueden residir físicamente en uno o más ordenadores, los cuales utilicen mecanismos de comunicación de interprocesos estándar, para comunicarse entre sí. En la realización mostrada, el sistema de ordenadores 400 comprende una memoria de ordenador 01 ("memoria"), una pantalla 402, una Unidad de Procesamiento Central 403 ("CPU"), y los dispositivos 404 de Entrada/Salida. El Sistema Proxy de Gestión de Direcciones 410 se muestra como residente en la memoria 401. Los componentes del Sistema Proxy de Gestión de Direcciones 410 se ejecuta preferiblemente en la CPU 403, y gestiona la correlación de direcciones de los dispositivos radioeléctricos en una red radioeléctrica, según lo descrito en las figuras anteriores, para permitir que otros sistemas cableados se comuniquen con los dispositivos radioeléctricos.
Otro código descargado 405 y potencialmente otros depósitos de datos pueden residir también en la memoria 410, y se ejecutan preferiblemente también en una o más CPU 403. En una realización típica, los AMPS 410 incluyen uno o más servidores DNS/API 411, uno o más Proxy/Enrutadores 412 de Direcciones, un Servidor de Datos 413 de Gestión de Direcciones, y los Depósitos 414 de Datos de Gestión de Direcciones. Tal como se ha descrito anteriormente, los AMPS pueden incluir depósitos de datos y componentes, tales como un equilibrador de cargas, dependiendo de la implementación en particular.
En un ejemplo conocido, los componentes de los AMPS 410 se implementan mediante la modificación de la tecnología basada en UDP existente, tal como los servidores DNS y enrutadores, los cuales están implementados típicamente en los sistemas Linux/Unix escritos en el lenguaje C de programación. Las interfaces de programación para los servidores DNS/API 411 y los Proxy/Enrutadores de Direcciones 412 pueden estar disponibles por los medios estándar, tal como a través de los lenguajes de programación C, C^{++}, C#, y API Java, tal como XML, o a través de servidores de páginas WEB que los soporten. El Servidor de Datos de Gestión de Direcciones 413 y los Depósitos de Datos de Gestión de Direcciones 414 están implementados preferiblemente por razones de escalabilidad como un sistema de base de datos en lugar de un fichero de texto, y pueden implementarse utilizando un sistema de gestión de bases de datos SQUODBC. Los servidores DNS/API 411 y los Proxy/Enrutadores de Direcciones 412 están implementados típicamente utilizando Linux, UNIX, o bien otros ordenadores basados en Unix o similares a Unix.
El técnico especializado en el arte reconocerá que los AMPS 410 pueden implementarse en un entorno distribuido, que esté compuesto por sistemas y redes múltiples, incluso heterogéneas, de ordenadores. Por ejemplo, en una realización, los servidores DNS/API 411, los componentes 412 del Proxy/Enrutador de Direcciones, y los Servidores de Datos de Gestión de Direcciones 413, con sus depósitos de datos 414, están todos localizados en sistemas de ordenadores físicamente distintos. En otra realización, los distintos componentes de los AMPS 410 están alojados cada uno en un ordenador servidor independiente, y pueden localizarse remotamente desde las tablas que están almacenadas en el depósito 414 de datos de gestión de direcciones. Además de ello, bajo ciertos escenarios, el sistema AMPS completo 410 puede estar alojado dentro de una infraestructura del operador, e integrado completamente en la misma. Se contemplan distintas configuraciones y lugares y datos, con las técnicas de la presente invención. En las realizaciones a modo de ejemplo, estos componentes pueden ejecutarse de forma concurrente y asincrónicamente; así pues, los componentes pueden comunicarse utilizando las técnicas bien conocidas de transferencia de mensajes. El técnico especializado en el arte observará que también están soportadas las realizaciones síncronas equivalentes por la implementación del sistema AMPS
Existen varias soluciones de la implementación para los componentes del Sistema Proxy de Gestión de Direcciones, habiéndose descrito aquí tres de las mismas. El técnico especializado en el arte observará que las distintas soluciones y combinaciones son posibles. Todas estas soluciones asignan una dirección de red pública (enrutable) para el uso temporal mediante un dispositivo cableado, para comunicarse con un dispositivo radioeléctrico. En una realización, se mantiene y se asigna un depósito de direcciones públicas, por ejemplo, direcciones IP públicas, en forma dinámica a unos dispositivos de redes radioeléctricas según sea preciso. Por ejemplo, un bloque de direcciones de redes de Internet de Clase B típicas, permite aproximadamente 65000 conexiones simultáneas para los dispositivos radioeléctricos. Aunque este numero pueda parecer grande a primera vista, cuando se considera el numero de teléfonos celulares, por ejemplo, conectados a un operador, esté numero puede ser totalmente limitativo.
La primera solución proporciona una correlación de direcciones públicas para un dispositivo radioeléctrico, y lo hace disponible utilizando un protocolo UDP. Otra ventaja de esta solución es que facilita el tráfico basado en UDP a los dispositivos radioeléctricos a través de la conexión radioeléctrica, y permite que el dispositivo conectado a la parte pública de la conexión pueda iniciar la conexión. No obstante, un inconveniente es que el protocolo UDP estándar precisa de la modificación o de añadir una llamada API extra, de forma que el dispositivo consultante pueda identificar el dispositivo radioeléctrico de destino. Estas modificaciones son necesarias porque el protocolo UDP puede soportar solo la designación de una dirección IP, y no proporciona medios alternativos de la identificación exclusiva de un dispositivo (tal como una cadena similar al protocolo TCP/IP. Puesto que es deseable ocultar esta dirección (privada), la llamada UDP estándar para enviar los datos puede no ser suficiente.
La segunda solución utilizada para implementar el sistema AMPS soporta la comunicación bidireccional total a través de las conexiones de punto a punto establecidas, por ejemplo, utilizando el protocolo TCP/IP. (Se observará que estas mismas técnicas soportan también la comunicación bidireccional UCP sin conexiones). La segunda solución puede ser implementada mediante el suministro de una implementación modificada de una función UDP o TCP/IP estándar "ConseguirServidorPorNombre". El API ConseguirServidorPorNombre permite que una designación de cadena identifique el dispositivo designado y devuelva una estructura de datos de direcciones IP. Alternativamente, para incrementar el nivel de seguridad provisto, el sistema AMPS puede implementar un API especializado, para devolver una dirección pública asignada dinámicamente, que corresponda al dispositivo radioeléctrico solicitado. Un inconveniente de la solución API especializada es que el dispositivo en la red pública (o bien otro dispositivo que desee obtener una conexión con el dispositivo radioeléctrico) requiere incluir un código especializado en la solicitud en el dispositivo de consulta.
La tercera solución es similar a la segunda solución, pero proporciona un número mayor de conexiones simultáneas potenciales, utilizando el concepto de "puerto". Utilizando esta solución, en lugar de devolver solo una dirección de servidor en la red cableada que corresponda al dispositivo radioeléctrico (dirección pública de un Proxy/Enruta-
dor de Direcciones), el sistema AMPS devuelve también una designación de puerto en particular del servidor (Proxy/
Endurador de Direcciones). Los puertos y su implementación son bien conocidos en el arte, y en general corresponden a las colas implementadas por el ordenador que reciba los datos, para efectuar el seguimiento de los mensajes destinados a distintos lugares. Los ordenadores que reciben los mensajes de envío de datos a los distintos destinos están basados en las designaciones de los puertos en el mensaje, en caso necesario, en forma secuencial y de acuse de recibo según la base de los puertos.
Los puertos se utilizan típicamente para abrir múltiples canales en una única dirección física y extender potencialmente una única dirección física a otras 65000 conexiones aproximadamente. Esto permite al sistema AMPS utilizar las direcciones IP Clase C, por ejemplo, las cuales son típicamente más económicas y más disponibles que los demás tipos de direcciones, para conseguir aproximadamente 16 millones de conexiones simultáneas a los dispositivos radioeléctricos (utilizando un sistema basado en UNIX). El técnico especializado en el arte observará que el número de puertos disponibles y su implementación en particular es dependiente del sistema operativo y que correlaciona directamente con el número de bits utilizados para especificar la dilección de los puertos.
El protocolo UDP (así como también el TCP/IP) soporta normalmente una abstracción de los puertos; no obstante, la consulta DNS estándar utilizada con los sistemas UDP y TCP/IP (por ejemplo, ConseguirServidorPorNombre) no permite la devolución de una designación del puerto y deja el control de la designación del puerto al dispositivo de consulta, en lugar del enrutador de recepción. Así pues, de acuerdo con la tercera solución para implementar los puertos AMPS, los puertos están especificados preferiblemente por el Proxy/Enrutador de Direcciones, utilizando un API especializado, y retornando al dispositivo de consulta con la designación del ordenador servidor.
En una realización, puede utilizarse una interfaz de lenguaje de programas, tal como XML, en lugar de un API especializado (interfaz de código) para hacer de interfaz con una función de correlación de direcciones especializadas. Al utilizar XML, el servidor DNS/API acepta las llamadas API como post-eventos XM, y devuelve las respuestas formateadas XML. Se contempla también un soporte similar para invocar esta función de correlación, utilizando otros modelos de lenguajes y/o otros lenguajes de programación, y operando con técnicas de la presente invención. La interfaz del tipo XML minimiza el costo a un dispositivo de consulta de la integración de un API en su software.
Además de ello, al utilizar un API especializado, el dispositivo de consulta puede enviar datos adicionales al dispositivo radioeléctrico privado sin precisar de ningún esfuerzo adicional de codificación. Por ejemplo, el código de facturación orientado a la facturación del dispositivo radioeléctrico para el tipo de conexión que se establezca con el dispositivo cableado puede ser enviado al dispositivo radioeléctrico utilizando esta técnica. Un ejemplo del mecanismo del código de facturación a modo de ejemplo es el expuesto en la solicitud de patente de los EE.UU. número 10/085981, titula como "Método y Sistema para la Facturación basada en la Transmisión de Aplicaciones", registrada el 26 de Febrero de 2002.
Existen varias razones relacionadas con la seguridad que pueden también indicar un deseo de utilizar un API especializado en lugar del API de ConseguirPorNombre estándar de UDP y TCP/IP. Estas razones de seguridad pueden indicar el deseo de utilizar el mecanismo basado en los puertos, que requiere también un API especializado. En primer lugar, cualquier comunicación bidireccional que utilice el API "ConseguirServidorPorNombre" y el protocolo del enrutador es susceptible de ataques de denegación del servicio (DOS) asociados con dicho nombre del servidor. Los ataques DOS pueden tener lugar como resultado de uno o más ordenadores que especifiquen el mismo ConseguirServidorPorNombre con el mismo perímetro de entrada simultáneamente con el fin de cerrar la posibilidad de que estén disponibles unas direcciones públicas suficientes. La transferencia de la zona DNS tiene lugar, por ejemplo, cuando un DNS transfiere una consulta DNS para uno o más servidores DNS, con el fin de encontrar un nombre de servidor solicitado. Un escenario típico incluye múltiples saltos DNS de país en país. La idea de los ataques del servidor de la zona DNS es captura información sobre un servidor DNS en particular, mediante la inserción de código malicioso, como un servidor DNS malicioso e impersonalizar la dirección de destino. En tercer lugar, la desatención a la duración de una conexión puede hacer que los datos sean disponibles a dispositivos de consulta no autorizados. Específicamente, puesto que se establece una correlación entre el dispositivo publico y el dispositivo radioeléctrico, el dispositivo publico puede asumir que existe la correlación con una duración más larga de lo real, y concluye potencialmente (maliciosamente o no) de comunicarse con el dispositivo erróneo. Esto podría tener lugar porque algunas implementaciones del servidor DNS ignoran los ajustes de Tiempo de Vida. Teniendo una implementación de servidor DNS modificada, implementando o no el API ConseguirServidorPorNombre, o un API especializado, se evita este problema mediante la permanencia de las características de la correlación establecida entre las direcciones privada y las públicas.
Las figuras 5-8 describen varias realizaciones a modo de ejemplo de las rutinas específicas implementadas por los servidores DNS/API y el sistema de Proxy/Enrutadores de Direcciones, para conseguir la funcionalidad descrita con referencia a las figura 2 y 3. La figura 5 es un diagrama de flujo a modo de ejemplo del proceso ejecutado por un dispositivo en una red pública, para enviar datos a un dispositivo radioeléctrico situado en una red radioeléctrica privada para el dispositivo radioeléctrico designado del sistema AMPS. Tal como se ha descrito anteriormente, un mecanismo para recuperar dicha dirección es que el AMPS implemente una interfaz modificada para los servicios DNS, tal como una rutina modificada de ConseguirServidorPorNombre. Por ejemplo, puede invocarse una rutina de ConseguirServidorPorNombre para especificar una designación exclusiva del dispositivo radioeléctrico, en forma de una cadena. La cadena "nombrepersona.telefono.wsp.com" es una cadena de ejemplo que indica un dispositivo radioeléctrico que corresponde a una persona mediante el nombre de "persona", con un número de teléfono de "teléfono", situada en un sitio WEB del proveedor de servicios radioeléctricos, que se abrevia como "wsp.com". (Por ejemplo, susan.ph2065551212.sprint.com, puede referirse a una persona Susan, con el numero de teléfono 2065551212, en una red sprint). Otro mecanismo que puede ser implementado por el AMPS es proporcionar un API independiente (especializado), tal como "ConseguirProxyIP", el cual devuelva una indicación de una dirección pública (enrutable) que corresponda a un dispositivo radioeléctrico designado. Utilizando un API independiente es útil por razones de seguridad; por ejemplo, llega a ser más difícil para un dispositivo solitario el interceptar la dirección enrutable mediante un engaño. Otra razón es controlar el formato real de la información de la dirección devuelta, de forma que sea capaz de proporcionar una designación del puerto además de una dirección del servidor del Proxy/Enrutador de Direcciones. La implementación de ConseguirServidorPorNombre, o un API especializado, tal como ConseguirProxyIP, se expone con más detalles más adelante con respecto a la figura 7.
En la etapa 502, una vez que la dirección pública para el dispositivo radioeléctrico haya sido devuelta por el AMPS, el dispositivo fuente extrae de la información de la dirección indicada un lugar de la dirección real (IPdatos.ip), el parámetro Tiempo de Vida (IPdatos.TTL), y opcionalmente, en caso aplicable, una designación del puerto (IPdatos.puerto) por ejemplo, cuando no se utilice el API ConseguirServidorPorNombre estándar. En la etapa 503, cuando el dispositivo fuente desea ejecutar la comunicación basada en la conexión con el dispositivo radioeléctrico, abre una conexión tal como con un conector. En la etapa 504, el dispositivo cableado determina si el parámetro de Tiempo de Vida ha concluido o no, y en caso afirmativo, retornar a la etapa 501, para solicitar una dirección distinta, o bien continuar en la etapa 505. El parámetro de Tiempo de Vida se utiliza por el AMPS para asegurar que una dirección pública para un dispositivo radioeléctrico (el cual puede estar o no conectado a la red radioeléctrica y encendido), no se sobrepase de un periodo de utilidad para dicho dispositivo radioeléctrico. En algunas realizaciones, se utiliza un parámetro TTL muy corto, para impedir interrupciones de la seguridad en las cuales el dispositivo cableado pueda monitorizar actividad en una dirección pública en particular, y utilizar después dicha dirección para otros fines. En la etapa 505, el dispositivo cableado envía un paquete de datos (a través de la conexión o no) al dispositivo radioeléctrico. Se supone, aunque no se muestra, que el dispositivo cableado y el dispositivo radioeléctrico se comunican utilizando las llamadas estándar especificadas en el protocolo de transferencia que se estén utilizando, por ejemplo UDP o TCP/IP. En la etapa 506, si se completa la transacción de datos, entonces el dispositivo cableado se ejecuta o se retorna para comprobar el parámetro TTL en la etapa 504, con el fin de enviar más datos.
La Tabla 1 a continuación contiene pseudocódigos que describen una implementación a modo de ejemplo de cómo un dispositivo público (o consultante) puede utilizar una consulta modificada de ConseguirServidorPorNombre, según lo descrito en la figura 5, para obtener una dirección pública que corresponda con un usuario identificado por el numero de teléfono "2065551212", utilizando el Sistema Proxy de Gestión de Direcciones. Desde la perspectiva del dispositivo público, las llamadas estándar de UDP y TCP/IP se invocan de una forma estándar.
TABLA 1
1
La Tabla 2 más adelante muestra los pseudocódigos que describen una implementación a modo de ejemplo del mecanismo API especializado descrito en la figura 5, tal como se usa por un dispositivo público (consultor) para obtener una dirección pública del usuario identificado por el mismo numero de teléfono. En la Tabla 2, el dispositivo público llama a un API especializado, ConseguirProxyIP, para conseguir una estructura de datos que contenga la información necesaria que incluya la dirección pública asignada del Proxy/Servidor de Direcciones. Posteriormente, el dispositivo público puede utilizar las mismas técnicas (UDP estándar o protocolo TPC/IP) para enviar los datos.
\vskip1.000000\baselineskip
TABLA 2
2
3 
\vskip1.000000\baselineskip
La figura 6 es un diagrama de bloques a modo de ejemplo de algunas tablas de depósitos de datos del Sistema Proxy de Gestión de Datos, utilizadas para soportar rutinas de los servidores DNS/API y los Proxy/Enrutadores de Direcciones. En una realización, el Depósito de Datos de Gestión de Direcciones comprende tres tablas; un identificador exclusivo (ID único) para la tabla de direcciones privadas 610, una tabla 630 de direcciones publicas-privadas, y una dirección pública para la tabla 620 del ordenador Proxy/Enrutador. Aunque se muestran las tres tablas, el técnico especializado en el arte observará que estas tablas podrían contener otros datos, y que pueden organizarse de forma diferente, incluyendo un número distinto de tablas, y con distintas columnas o campos. Además de ello, puede utilizarse cualquier técnica para almacenar una tabla o lista de datos. Para soportar las realizaciones que correlacionan una dirección del servidor más un designador de puertos a un dispositivo radioeléctrico, las tablas se encuentran modificadas en la forma correspondiente.
La tabla 610 de ID únicas correlaciona los nombres de cadenas exclusivas de los dispositivo radioeléctricos con las direcciones de la red radioeléctrica privadas que hayan sido asignadas típicamente por una estructura del operador. En algunas realizaciones, la infraestructura del operador asigna dinámicamente, utilizando métodos similares a un protocolo DHCP, una dirección de red radioeléctrica privada cuando el dispositivo radioeléctrico se registra por si mismo en la infraestructura del operador al encenderse. Así pues, la tabla 610 de ID únicas puede rellenarse de forma dispersa o crear entradas dinámicamente y siendo después suprimidas dinámicamente como registrador de dispositivos y siendo des-registradas con el sistema de la infraestructura del operador.
La tabla 630 de direcciones públicas-privadas comprende varios campos/columnas que incluyen la dirección de la red pública 631, una dirección 602 de la red privada (radioeléctrica), una bandera 632 que especifica si la dirección pública almacenada en el campo 631 está libre o ya está utilizada, el parámetro de Tiempo de Vida (TTL) 633, y otros datos 634 de conexión. En una realización, los servidores DNS/API de la tabla 630 de consultas AMPS determinan una dirección de red pública que corresponde a una dirección de red radioeléctrica privada designada, o para asignar una dirección de red pública no utilizada (según lo indicado en el campo 632), y correlacionar la dirección pública no usada determinada a una dirección de red privada almacenada en el campo 602.
La dirección pública para la tabla 620 del ordenador Proxy/Enrutador comprende un campo 631 de dirección de red pública, y una indicación de un ordenador 621 de Proxy/Enrutador de funcionamiento. Mediante el mantenimiento de dicha correlación, el sistema AMPS es capaz de sustituir los ordenadores Proxy/Enrutadores por otros ordenadores Proxy/Enrutadores, para proporcionar un alto grado de robustez. Cada ordenador Proxy/Enrutador tiene un conjunto preconfigurado de direcciones de red pública, tal como las configuradas típicamente por las tarjetas de red insertadas en el ordenador enrutador de direcciones. Estas direcciones están asignadas de una forma estándar a través de una compra previa o bien obteniéndolas a partir de una autoridad de autorización de direcciones, normalmente la Corporación de Nombres y Números Asignados (ICANN). Cuando un ordenador se inserta para su uso en el sistema AMPS, las indicaciones de estas direcciones se almacenan en el campo 631.
En una realización, se observa también en la tabla 630 un sello de la hora de la correlación entre una dirección de red pública y una dirección privada. Después de un tiempo limite definido, basado en el sello de la hora, el Servidor de Datos de Gestión de Direcciones envía una petición al Proxy/Enrutador de Direcciones asociado con la correlación para des-correlacionar la correlación de la dirección de pública a privada, y poder actualizar la tabla de correlaciones 630, retornando por tanto la dirección pública asociada al depósito general de direcciones de redes publicas no utilizadas.
La figura 7 es un diagrama de flujo a modo de ejemplo de una rutina de ejemplo provista por un servidor DNS/API del Sistema Proxy de Gestión de Direcciones para devolver una dirección pública que corresponda a un identificador único designado. En esencia, esa rutina implementa una consulta DNS o una capacidad de consulta similar a DNS para el sistema AMPS utilizando una interfaz de ConseguirServidorPorNombre o un API especializado, por ejemplo un ConseguirProxyIP, tal como se describe con referencia a la figura 5. En resumen, la rutina asigna dinámicamente un ordenador Proxy/Enrutador de Direcciones para asociarlo con el dispositivo radioeléctrico y devolviendo la dirección pública de dicho ordenador (junto con un parámetro TTL y potencialmente otros parámetros). Específicamente, en la etapa 701, la rutina determina la dirección privada (no enrutable) del dispositivo radioeléctrico designado por un parámetro de cadena que haya pasado como entrada en la rutina. Por ejemplo, el parámetro de cadena puede utilizar campos tales como "UnicoIDnombreservidor.dominio.tld", que especifica una jerarquía típica de persona/servicio en un ordenador denominado "nombreservidor" en un dominio tal como la red de la compañía en un dominio de nivel superior, tal como "org.", "com.", "edu.", etc. El técnico especializado en el arte observará que podrían utilizarse muchas otras designaciones del parámetro de cadena. Un mecanismo para implementar esta rutina es solicitar información del Depósito de Datos de Gestión de Direcciones. En una realización, el depósito de datos almacena una tabla que correlaciona los ID únicos con las direcciones de la red privada (véase la Tabla 610 en la figura 6). Preferiblemente, cualquier mecanismo que se utilice por el AMPS almacena estos datos de una forma segura, con el fin de mantener privadas las direcciones de la red radioeléctrica. En la etapa 702, las rutinas recuperan la dirección de la red pública que correspondan a la dirección de la red radioeléctrica privada del dispositivo designado, si alguien haya sido asignado ya por el AMPS a dicho dispositivo y que todavía sea válido. En una realización, el depósito general de datos almacena esta información de correlación entre la dirección la dirección de red radioeléctrica privada y la dirección de la red pública (véase por ejemplo la tabla 630 en la figura 6). En caso de que una dirección de red pública no haya sido asignada o no sea válida, entonces la rutina provoca una nueva dirección de red pública a asignar y asociando la dirección publica nueva con la dirección de la red radioeléctrica privada. Las tablas apropiadas en el depósito general de datos se actualizan entonces. En la etapa 703, la rutina determina el ordenador Proxy/Enrutador de Direcciones que esté asociado con la dirección de red pública asignada (por ejemplo utilizando la tabla 620 en la figura 6). En la etapa 704, la rutina envía una petición al ordenador Proxy/Enrutador determinado, para actualizar sus tablas de enrutamiento para correlacionar la dirección de red publica determinada con la dirección de red radioeléctrica privada. En la etapa 705, la rutina actualiza la información en el deposito general de datos para incluir cualesquiera otra información relacionada de conexión (por ejemplo, el campo 634 en la Tabla 630 en la Figura 6), e indica el parámetro de Tiempo de Vida (TTL) para la asociación de la dirección pública-privada (por ejemplo, el campo 633 en la Tabla 630 en la Figura 6). Una vez que se hayan actualizado todas las tablas en el ordenador Proxy/Enrutador y el depósito general de datos, el servidor DNS/API retorna la dirección de red pública determinada del ordenador Proxy/Enrutador de Direcciones asociado. Tal como se ha descrito anteriormente, la dirección pública puede ser un par (nombreServidor, puerto) al utilizar una implementación basada en los puertos.
La figura 8 es un diagrama de flujo a modo de ejemplo, de una rutina de ejemplo dentro de un Proxy/Enrutador de Direcciones, de un Sistema Proxy de Gestión de Direcciones que recibe datos. Esta rutina está implementada por un Proxy/Enrutador de Direcciones para recibir datos desde dispositivos cableados utilizando el protocolo correspondiente (por ejemplo, TCP/IP, UDO/IP, etc.). (Los datos se envían a un Proxy/Enrutador de Direcciones en particular porque la dirección publica (enrutable) de dicho Proxy/Enrutador de Direcciones fue retornado a un dispositivo fuente de peticiones en respuesta a una consulta del servidor DNS/API del sistema AMPS). El Proxy/Enrutador es responsable de cualquier conversión de los datos necesarios para enviar datos desde la red cableada a la red radioeléctrica (si por ejemplo la infraestructura del operador desea dicha conversión a ejecutar a este nivel). El Proxy/Enrutador es también responsable del envío de los datos a través de la red radioeléctrica a la dirección radioeléctrica privada del dispositivo radioeléctrico que corresponda a la dirección pública utilizada para invocar el Proxy/Enrutador.
Específicamente, en la etapa 801, la rutina determina (por ejemplo, desde el Deposito General de Datos de Gestión de Direcciones) la dirección radioeléctrica privada que corresponda a la dirección pública invocada, y el parámetro TTL asociado con esta correlación. Estos valores pueden obtenerse, por ejemplo, a partir de la tabla 630 de direcciones publicas-privadas de la figura 6. En la etapa 802, la rutina determina si el valor del parámetro TTL determinado indica que la correlación ha concluido, y en caso afirmativo, devolver un error, o bien continuar en la etapa 803. En la etapa 803, la rutina determina el formato requerido por el dispositivo de objetivo (el formato de la red radioeléctrica). En la etapa 804, la rutina determina si es necesaria cualquier conversión del protocolo, y en caso afirmativo continuar en la etapa 805 o continuar en la etapa 806. Se observará que la conversión del protocolo para una red radioeléctrica específica tal como la de conversión de los datos a un paquete "HTTP" puede ejecutarse por el Proxy/Enrutador, o bien puede ejecutarse por algún otro componente dentro de la infraestructura del operador. El técnico especializado en el arte observará que estas son etapas de ejemplo, y que pueden añadirse o bien omitirse el distinto formateo o la distintas rutinas de conversión del protocolo como específicas al entorno en la etapa 806, en donde la rutina del Proxy/Enrutador de Direcciones envía el paquete de datos (que haya sido formateado y cuyo protocolo se convierte si fuera necesario), a la dirección privada asociada determinada del dispositivo radioeléctrico, y retornando después.
El técnico especializado en el arte observará que los métodos y sistemas para establecer la comunicación bidireccional aquí expuesta son aplicables a otros tipos de redes públicas y protocolos distintos a los de Internet, TCP/IP, y UDP, o incluso una pluralidad de tales redes. Por ejemplo, las correlaciones de dirección privada a dirección pública pueden ser suministradas también para redes ATM a los dispositivos de conexión en una red ATM con un dispositivo radioeléctrico. El técnico especializado en el arte observará también que los métodos y sistemas aquí expuestos son aplicables a distintos protocolos, medios de comunicación (ópticos, radioeléctricos, cable, etc.) y dispositivos radioeléctricos (tal como móviles radioeléctricos de mano, organizadores electrónicos, ayudantes digitales personales (PDA, ordenadores de correo portátiles, máquinas de juegos, buscapersonas, dispositivos de navegación tales como los receptores GPS, etc.) a distintos dispositivos cableados (tales como kioscos, ordenadores personales, ordenadores principales), y a dispositivos radioeléctricos que tengan capacidades de conexión radioeléctricas, por ejemplo, correo electrónico radioeléctrico o dispositivos PDA que puedan conectarse a una estación de conexionado para los fines de sincronización.

Claims (18)

1. Un método para ser utilizado en una red de ordenadores (210), que está conectada a una red de comunicaciones radioeléctricas (230) a través de un sistema Proxy de gestión de direcciones, AMPS (220), en el que la red de comunicaciones radioeléctricas sirve para la conexión a un dispositivo radioeléctrico (240) que tenga un identificador único asociado (601) a la red de ordenadores a través de un canal de comunicación bidireccional, utilizando una dirección de la red privada (602) de la red de comunicaciones radioeléctricas, en el que el sistema Proxy (220) de gestión de direcciones tiene una dirección de red publica (631) de la red de ordenadores y la red de ordenadores sirviendo para conectar un dispositivo cableado (201, 202, 203) a la red radioeléctrica, utilizando una dirección de red pública (631) de la red de ordenadores, que comprende:
bajo el control del dispositivo cableado (201, 202, 203),
utilizar la dirección de red pública (631) del sistema Proxy de gestión de direcciones (220), enviando (501) una petición al sistema Proxy de gestión de direcciones para una indicación de una dirección de red pública (631) de la red de ordenadores, para utilizarla para la comunicación con el dispositivo radioeléctrico, indicando la petición el identificador único (601) asociado con el dispositivo radioeléctrico (240);
bajo el control del sistema Proxy de gestión de direcciones (220),
recibir la petición de la indicación de la dirección de la red pública (631);
determinar dinámicamente (702) una dirección de red pública (631) de una pluralidad de direcciones de la red publica disponibles de la red de ordenadores (210);
asociar (704) la dirección (631) de la red pública determinada con la dirección (602) de la red privada del dispositivo radioeléctrico (240) que corresponda al identificador (601) único indicado; y
enviar (502) otra indicación de la dirección (631) de la red pública determinada al dispositivo cableado; y
bajo el control del dispositivo cableado (201, 202, 203),
recibir (801) la dirección (631) de la red pública indicada; y
enviar (806) datos al dispositivo radioeléctrico (240) utilizando la dirección de la red publica indicada (631), de forma tal que el dispositivo cableado (201, 202, 203) se de cuenta que el dispositivo cableado está en comunicación directamente con el dispositivo radioeléctrico (240);
caracterizado porque:
la dirección de la red pública contiene una especificación de una dirección, siendo la dirección una dirección IP y un par de puertos;
en el que la dirección de la red publica indicada se recibe como resultado de una petición por el dispositivo cableado a una función de correlación de la dirección especializada dentro del AMPS de la red de ordenadores, en donde las funciones de correlación de la dirección especializada utiliza un servicio de nombre de dominio modificado; DNS, que soporta al menos uno de los estándares UDP y TCP/IP.
2. El método de la reivindicación 1, que comprende además bajo el control del sistema Proxy de gestión de direcciones (220):
recibir los datos enviados desde el dispositivo cableado (201, 202, 203);
determinar la dirección de la red privada (602) que esté asociada con la dirección de red pública indicada (631); y
enrutar (505) los datos recibidos a la dirección de red privada a través de la red de comunicación radioeléctrica de una forma que sea transparente con el dispositivo cableado.
3. El método de la reivindicación 1, en el que la red de ordenadores (210) es Internet y en donde cada dirección de red pública está especificada de acuerdo con las convenciones de direccionamiento del Protocolo de Internet.
4. El método de la reivindicación 1, en el que la red de ordenadores es una red ATM.
5. El método de la reivindicación 1, en el que la dirección de red publica indicada (631) es la dirección de red pública del sistema de Proxy de gestión de direcciones (220), en el que los datos enviados desde el dispositivo cableado (201, 202, 203) incluye el identificador único del dispositivo radioeléctrico (240), y en donde el sistema Proxy de gestión
de direcciones almacena y envía los datos al dispositivo radioeléctrico identificado con el identificador único indicado.
6. El método de la reivindicación 1, en el que la función de correlación de direcciones especializada es un APL personalizado.
7. El método de la reivindicación 1, en el que la función de correlación de direcciones especializada soporte una interfaz XML.
8. El método de la reivindicación 1, que comprende además:
bajo el control del dispositivo radioeléctrico, enviar los datos al dispositivo cableado utilizando la red pública del dispositivo cableado (201, 202, 203), ejecutando por tanto una comunicación bidireccional.
9. El método de la reivindicación 1, en el que se establece una conexión de extremo a extremo virtual entre el dispositivo cableado (201, 202, 203) y el dispositivo radioeléctrico (240).
10. El método de la reivindicación 1, que comprende además:
asociar la dirección de red publica determinada (631) con un periodo de tiempo limite de terminación; y
destruir la asociación entre la dirección de red pública determinada y la dirección privada del dispositivo radioeléctrico cunado haya concluido el periodo de tiempo limite de terminación.
11. El método de la reivindicación 1, en el que el periodo de tiempo limite de terminación está especificado como datos de Tiempo de Vida (TTL).
12. El método de la reivindicación 1, en el que el identificador único es al menos un nombre de persona y un numero de teléfono, un numero MSISDN, y un número IMSI.
13. Un medio de memoria legible por ordenador que contiene instrucciones para controlar un procesador en un sistema de ordenadores, para establecer un canal de comunicación bidireccional entre un dispositivo cableado conectado a un entorno de red de ordenadores, utilizando una dirección de red publica (631), y un dispositivo radioeléctrico conectado a una red de comunicaciones radioeléctricas, y teniendo una dirección de red privada para ejecutar el método de una de las reivindicaciones 1-12.
14. Una red de comunicaciones que comprende:
un dispositivo radioeléctrico (240), conectado a una red de comunicaciones radioeléctrica utilizando una dirección de red privada (602) de la red de comunicaciones radioeléctricas, teniendo el dispositivo radioeléctrico un identificador único asociado (631) de la red de ordenadores que está estructura para:
solicitar una indicación de una dirección de red publica (631) de la red de ordenadores a utilizar para la comunicación con el dispositivo radioeléctrico (240), en el que la petición indica el identificador único asociado con el dispositivo radioeléctrico, recibiendo la dirección de red pública indicada (631), y
enviar datos al dispositivo radioeléctrico (240), utilizando la dirección de red publica indicada (631), de forma tal que el dispositivo cableado se comunique por los medios de un canal de comunicación bidireccional directamente con el dispositivo radioeléctrico, utilizando una conexión de extremo a extremo virtual; y
un sistema Proxy de gestión de direcciones (220) conectado a la red de ordenadores, utilizando una dirección de red pública de la red de ordenadores, que esta estructurado para:
recibir la petición del dispositivo cableado (201, 202, 203);
determinar dinámicamente una dirección de red pública (631) de una pluralidad de direcciones de red publica disponibles de la red de ordenadores,
asociar la dirección de red publica determinada (631) con la dirección de red privada (602) del dispositivo radioeléctrico (240) que corresponda al identificador único indicado (601), y
enviar una indicación de la dirección de red pública determinada (631) al dispositivo cableado,
caracterizada porque:
la dirección de red pública contiene una especificación de una dirección, siendo la dirección una dirección IP y un par de puertos;
en el que la dirección de red publica es recibida como resultado de una petición por el dispositivo cableado a una función de correlación de direcciones especializada dentro del AMPS de la red de ordenadores, en el que la función de correlación de la dirección especificada utiliza el servicio de nombres de dominio modificado, DNS, que soporta al menos uno de los estándares UDP y TCP/IP.
15. Un método en una red de ordenadores para la comunicación con un dispositivo radioeléctrico (240), en el que la red de ordenadores y el dispositivo radioeléctrico están interconectados a través de un sistema Proxy de gestión de direcciones, AMPS (220), para establecer un canal de comunicación bidireccional, utilizando una dirección de red privada (602) del dispositivo radioeléctrico, teniendo el dispositivo radioeléctrico (240) un identificador único asociado (601) que no es la dirección de red privada, en donde el sistema Proxy de gestión de direcciones (220) está conectado a la red de ordenadores utilizando una dirección de red publica (631) de la red de ordenadores, que comprende:
un dispositivo radioeléctrico que solicita del sistema Proxy de gestión de direcciones (220) una dirección de red pública (631), que corresponde al identificador único (601) asociado con el dispositivo radioeléctrico (240);
recibir una indicación de la dirección de red pública (631) del dispositivo radioeléctrico; y
enviar datos a la dirección de red publica indicada (631);
caracterizado porque:
en el que la dirección de red publica es recibida como resultado de una petición por el dispositivo cableado a una función de correlación de direcciones especializada dentro del AMPS de la red de ordenadores, en el que la función de correlación de la dirección especificada utiliza el servicio de nombres de dominio modificado, DNS, que soporta al menos uno de los estándares UDP y TCP/IP.
16. Un medio de memoria legible por ordenador, que contiene instrucciones para ejecutar el método de la reivindicación 15.
17. Un dispositivo cableado (201, 202, 203) que está conectado a una red de ordenadores, utilizando una dirección de red pública (631) de la red de ordenadores, en el que la red de ordenadores está conectada a un sistema Proxy de gestión de direcciones, AMPS (220), utilizando una dirección de red pública (631) de la red de ordenadores, en el que el sistema Proxy de gestión de direcciones (220) sirve para conectar un dispositivo radioeléctrico (240) a la red de ordenadores, utilizando una dirección de red privada (602), teniendo el dispositivo radioeléctrico (240) un identificador (601) que no es la dirección de red privada, que comprende:
un módulo de códigos de comunicaciones que está estructurado para:
solicitar al sistema Proxy de gestión de direcciones (220) una dirección de red pública (631) que corresponda al identificador único (601) asociado con la red de ordenadores, al dispositivo radioeléctrico (240), utilizando una dirección de red privada (602);
recibir una indicación de la dirección de red pública (631) del dispositivo radioeléctrico (240); y
enviar datos a la dirección de red pública indicada (631).
caracterizado porque:
la red de red pública contiene una especificación de una dirección, siendo al dirección una dirección IP y un par de puertos,
en el que la dirección de red publica indicada se recibe como resultado de una petición por el dispositivo cableado a función de correlación de direcciones especializada, utilizando un servicio de nombres de dominio modificado, DNS, que soporta al menos uno de los estándares UDP y TCP/IP.
18. El dispositivo de la reivindicación 1, en el que el módulo del código de comunicaciones implementa al menos uno de los sistemas UDP y TCP/IP de comunicación con el dispositivo radioeléctrico.
ES02744283T 2001-06-08 2002-06-10 Metodo, medio de memoria, red de ordenadores y dispositivo para la comunicacion de datos en modo bilateral con dispositivos radioelectricos. Expired - Lifetime ES2263791T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US29690201P 2001-06-08 2001-06-08
US296902P 2001-06-08

Publications (1)

Publication Number Publication Date
ES2263791T3 true ES2263791T3 (es) 2006-12-16

Family

ID=23144044

Family Applications (1)

Application Number Title Priority Date Filing Date
ES02744283T Expired - Lifetime ES2263791T3 (es) 2001-06-08 2002-06-10 Metodo, medio de memoria, red de ordenadores y dispositivo para la comunicacion de datos en modo bilateral con dispositivos radioelectricos.

Country Status (10)

Country Link
US (1) US20030028671A1 (es)
EP (1) EP1400093B1 (es)
JP (1) JP2004533190A (es)
KR (1) KR20040034612A (es)
CN (1) CN1528081A (es)
AT (1) ATE328436T1 (es)
AU (1) AU2002345633A1 (es)
DE (1) DE60211897T2 (es)
ES (1) ES2263791T3 (es)
WO (1) WO2002102012A2 (es)

Families Citing this family (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6725264B1 (en) * 2000-02-17 2004-04-20 Cisco Technology, Inc. Apparatus and method for redirection of network management messages in a cluster of network devices
US7092390B2 (en) * 2000-09-07 2006-08-15 Sbc Technology Resources, Inc. Internal substitution bi-level addressing for compatible public networks
CN100481094C (zh) * 2001-08-24 2009-04-22 英国电讯有限公司 协调网络事件的装置和方法
US7187921B1 (en) * 2001-12-10 2007-03-06 Bellsouth Intellectual Property Corporation Apparatus, system and method for forwarding data sent to a wireless device to another address
US7069336B2 (en) * 2002-02-01 2006-06-27 Time Warner Cable Policy based routing system and method for caching and VPN tunneling
US7298750B2 (en) 2002-07-31 2007-11-20 At&T Knowledge Ventures, L.P. Enhancement of resource reservation protocol enabling short-cut internet protocol connections over a switched network
US7272145B2 (en) 2002-07-31 2007-09-18 At&T Knowledge Ventures, L.P. Resource reservation protocol based guaranteed quality of service internet protocol connections over a switched network through proxy signaling
US7065092B2 (en) * 2002-07-31 2006-06-20 Sbc Properties, L.P. Resource reservation protocol based guaranteed quality of service internet protocol (IP) connections over a switched network using newly assigned IP addresses
US7301951B2 (en) * 2002-07-31 2007-11-27 At&T Knowledge Ventures, L.P. Resource reservation protocol based guaranteed quality of service internet protocol connections over a switched network
US7379971B2 (en) * 2002-11-19 2008-05-27 Microsoft Corporation Time-to-disconnect enforcement when communicating with wireless devices that have transient network addresses
US20040103153A1 (en) * 2002-11-21 2004-05-27 Chang Tsung-Yen Dean Apparatus and method for providing smart network appliances
KR100511479B1 (ko) * 2002-12-27 2005-08-31 엘지전자 주식회사 Ｎａｔ를 갖는 망에서의 ｓｉｐ 서비스 방법
US20040260801A1 (en) * 2003-02-12 2004-12-23 Actiontec Electronics, Inc. Apparatus and methods for monitoring and controlling network activity using mobile communications devices
US20040158630A1 (en) * 2003-02-12 2004-08-12 Chang Tsung-Yen Dean Monitoring and controlling network activity in real-time
US7926104B1 (en) * 2003-04-16 2011-04-12 Verizon Corporate Services Group Inc. Methods and systems for network attack detection and prevention through redirection
US7447203B2 (en) 2003-07-29 2008-11-04 At&T Intellectual Property I, L.P. Broadband access for virtual private networks
US7739394B2 (en) * 2003-07-29 2010-06-15 At&T Intellectual Property I, L.P. Bi-level addressing for internet protocol broadband access
US7944947B2 (en) * 2003-09-05 2011-05-17 Nokia Corporation Providing address information for reaching a wireless terminal
US20050076141A1 (en) * 2003-09-19 2005-04-07 Williams Aidan Michael Use of an autoconfigured namespace for automatic protocol proxying
US20050210508A1 (en) * 2004-03-19 2005-09-22 Lau Vincent W System and method for managing time-go-live information of media content
GB2418321A (en) * 2004-09-17 2006-03-22 Compal Communications Inc Method for establishing a socket connection between a client and a mobile station through a wireless network
US20060168225A1 (en) * 2004-10-29 2006-07-27 John Gunning Network and a distributed electronic commerce system using the network
US7580915B2 (en) * 2004-12-14 2009-08-25 Sap Ag Socket-like communication API for C
US7593930B2 (en) * 2004-12-14 2009-09-22 Sap Ag Fast channel architecture
US7600217B2 (en) * 2004-12-14 2009-10-06 Sap Ag Socket-like communication API for Java
US7523196B2 (en) * 2004-12-28 2009-04-21 Sap Ag Session monitoring using shared memory
US20060143389A1 (en) * 2004-12-28 2006-06-29 Frank Kilian Main concept for common cache management
US7562138B2 (en) * 2004-12-28 2009-07-14 Sap Shared memory based monitoring for application servers
US7539821B2 (en) * 2004-12-28 2009-05-26 Sap Ag First in first out eviction implementation
US7886294B2 (en) * 2004-12-28 2011-02-08 Sap Ag Virtual machine monitoring
US7552153B2 (en) * 2004-12-28 2009-06-23 Sap Ag Virtual machine monitoring using shared memory
US7689989B2 (en) * 2004-12-28 2010-03-30 Sap Ag Thread monitoring using shared memory
US20060143256A1 (en) * 2004-12-28 2006-06-29 Galin Galchev Cache region concept
US20060153118A1 (en) * 2005-01-11 2006-07-13 International Business Machines Corporation System and method for wireless ip address capacity optimization
US7436814B2 (en) * 2005-04-22 2008-10-14 Cisco Technology, Inc. Selecting transport addresses to route streams between endpoints
US7516277B2 (en) * 2005-04-28 2009-04-07 Sap Ag Cache monitoring using shared memory
US20070160034A1 (en) * 2006-01-06 2007-07-12 D.S.P. Group Ltd Dual-protocol dual port telephone and method to connect another dual-protocol dual port telephone via IP network directly and without installation
US8612556B2 (en) * 2006-05-03 2013-12-17 Comcast Cable Holdings, Llc Method of provisioning network elements
US20080069101A1 (en) * 2006-09-15 2008-03-20 Nokia Corporation System and method of routing packets
US8462628B2 (en) * 2006-12-20 2013-06-11 Integrated Device Technology, Inc. Method of improving over protocol-required scheduling tables while maintaining same
WO2008080416A1 (en) * 2006-12-28 2008-07-10 Telecom Italia S.P.A. Method and apparatus to control application messages between a client and a server having a private network address
US8311042B2 (en) * 2007-06-15 2012-11-13 Mformation System and method for automatic detection and reporting of the mapping between device identity and network address in wireless networks
US7724707B2 (en) 2007-06-26 2010-05-25 Motorola, Inc. Network for a cellular communication system and a method of operation therefor
SE0702582L (sv) * 2007-11-15 2009-05-16 Klap Worldwide Corp Ltd Nätverk för kommunikation
US9455924B2 (en) 2008-01-02 2016-09-27 Media Network Services As Device and system for selective forwarding
CN102138347B (zh) 2008-04-02 2015-04-22 沃达方集团有限公司 电信网络
US8509235B2 (en) * 2008-07-30 2013-08-13 Blue Coat Systems, Inc. Layer-2 packet return in proxy-router communication protocol environments
US8196155B2 (en) * 2008-10-08 2012-06-05 Oracle International Corporation XML-based event driven interface for OPC data access
US8073934B1 (en) * 2008-10-20 2011-12-06 Amazon Technologies, Inc. Automated load balancing architecture
US7987255B2 (en) * 2008-11-07 2011-07-26 Oracle America, Inc. Distributed denial of service congestion recovery using split horizon DNS
US7924832B2 (en) * 2008-11-13 2011-04-12 Blue Coat Systems, Inc. Facilitating transition of network operations from IP version 4 to IP version 6
US8578055B2 (en) * 2009-07-09 2013-11-05 International Business Machines Corporation Propogation of DNS server IP addresses in a private network
US8103795B2 (en) * 2009-07-09 2012-01-24 International Business Machines Corporation TCP/IP host name resolution on a private network
US8140669B2 (en) * 2009-08-31 2012-03-20 International Business Machines Corporation Resolving hostnames on a private network with a public internet server
US8902743B2 (en) * 2010-06-28 2014-12-02 Microsoft Corporation Distributed and scalable network address translation
US20120131162A1 (en) * 2010-11-24 2012-05-24 Brandt Mark S Using a web service to delete dns records in a server hosting system
CN101986608B (zh) * 2010-12-13 2012-08-15 武汉大学 一种异构覆盖网络负载均衡程度的评价方法
US9015021B2 (en) * 2011-10-25 2015-04-21 Cellco Partnership Multiple client simulator for push engine
CN104639564A (zh) * 2015-03-03 2015-05-20 北京极科极客科技有限公司 一种udp协议的代理方法
US10567518B2 (en) * 2015-06-26 2020-02-18 Western Digital Technologies, Inc. Automatic discovery and onboarding of electronic devices
CN106487864B (zh) * 2015-09-02 2019-09-27 华为终端有限公司 数据连接的建立方法、服务端及移动终端
ES2726302T3 (es) * 2015-09-21 2019-10-03 Huawei Tech Co Ltd Sistema informático y procedimiento para acceder a un dispositivo de punto extremo del mismo
US11632810B2 (en) 2018-02-28 2023-04-18 Nokia Technologies Oy Transparent integration of 3GPP network into TSN based industrial network

Family Cites Families (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5634010A (en) * 1994-10-21 1997-05-27 Modulus Technologies, Inc. Managing and distributing data objects of different types between computers connected to a network
US6244758B1 (en) * 1994-11-15 2001-06-12 Absolute Software Corp. Apparatus and method for monitoring electronic devices via a global network
US6625652B1 (en) * 1995-01-19 2003-09-23 The Fantastic Corporation System and method for host list pruning
US6418324B1 (en) * 1995-06-01 2002-07-09 Padcom, Incorporated Apparatus and method for transparent wireless communication between a remote device and host system
US5812786A (en) * 1995-06-21 1998-09-22 Bell Atlantic Network Services, Inc. Variable rate and variable mode transmission system
US6041041A (en) * 1997-04-15 2000-03-21 Ramanathan; Srinivas Method and system for managing data service systems
WO1998058476A1 (en) * 1997-06-17 1998-12-23 Telecom Wireless Solutions, Inc. System and process for allowing wireless messaging
FI104668B (fi) * 1997-07-14 2000-04-14 Nokia Networks Oy Liittymäpalvelun toteuttaminen
US6023724A (en) * 1997-09-26 2000-02-08 3Com Corporation Apparatus and methods for use therein for an ISDN LAN modem that displays fault information to local hosts through interception of host DNS request messages
US6665718B1 (en) * 1997-10-14 2003-12-16 Lucent Technologies Inc. Mobility management system
US6377982B1 (en) * 1997-10-14 2002-04-23 Lucent Technologies Inc. Accounting system in a network
US6675208B1 (en) * 1997-10-14 2004-01-06 Lucent Technologies Inc. Registration scheme for network
JPH11122301A (ja) * 1997-10-20 1999-04-30 Fujitsu Ltd アドレス変換接続装置
GB2332288A (en) * 1997-12-10 1999-06-16 Northern Telecom Ltd agent enabling technology
JP3966598B2 (ja) * 1998-03-04 2007-08-29 富士通株式会社 サーバ選択システム
US6233618B1 (en) * 1998-03-31 2001-05-15 Content Advisor, Inc. Access control of networked data
US6345304B1 (en) * 1998-04-01 2002-02-05 Xerox Corporation Obtaining network addresses from identifiers
US6058431A (en) * 1998-04-23 2000-05-02 Lucent Technologies Remote Access Business Unit System and method for network address translation as an external service in the access server of a service provider
US6011844A (en) * 1998-06-19 2000-01-04 Callnet Communications Point-of-presence call center management system
US6401128B1 (en) * 1998-08-07 2002-06-04 Brocade Communiations Systems, Inc. System and method for sending and receiving frames between a public device and a private device
US6421732B1 (en) * 1998-08-27 2002-07-16 Ip Dynamics, Inc. Ipnet gateway
US6317831B1 (en) * 1998-09-21 2001-11-13 Openwave Systems Inc. Method and apparatus for establishing a secure connection over a one-way data path
US6622157B1 (en) * 1998-09-28 2003-09-16 Certeon, Inc. Extending network services using mobile agents
JP3327225B2 (ja) * 1998-10-29 2002-09-24 三菱マテリアル株式会社 ネットワークアドレス変換装置およびその記録媒体
US6502135B1 (en) * 1998-10-30 2002-12-31 Science Applications International Corporation Agile network protocol for secure communications with assured system availability
US6161008A (en) * 1998-11-23 2000-12-12 Nortel Networks Limited Personal mobility and communication termination for users operating in a plurality of heterogeneous networks
US6657991B1 (en) * 1998-12-21 2003-12-02 3Com Corporation Method and system for provisioning network addresses in a data-over-cable system
US6452920B1 (en) * 1998-12-30 2002-09-17 Telefonaktiebolaget Lm Ericsson Mobile terminating L2TP using mobile IP data
JP2000270007A (ja) * 1999-03-12 2000-09-29 Sony Corp ネットワークシステム、ネットワークサーバ及び端末装置
US6731642B1 (en) * 1999-05-03 2004-05-04 3Com Corporation Internet telephony using network address translation
US6769000B1 (en) * 1999-09-08 2004-07-27 Nortel Networks Limited Unified directory services architecture for an IP mobility architecture framework
US7934251B2 (en) * 1999-12-02 2011-04-26 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US20040220926A1 (en) * 2000-01-03 2004-11-04 Interactual Technologies, Inc., A California Cpr[P Personalization services for entities from multiple sources
US20020163889A1 (en) * 2000-02-02 2002-11-07 Yechiam Yemini Method and apparatus for providing services on a dynamically addressed network
US6714545B1 (en) * 2000-03-03 2004-03-30 Qwest Communications International, Inc. VDSL data network, service and management architecture
US6948003B1 (en) * 2000-03-15 2005-09-20 Ensim Corporation Enabling a service provider to provide intranet services
US6754709B1 (en) * 2000-03-29 2004-06-22 Microsoft Corporation Application programming interface and generalized network address translator for intelligent transparent application gateway processes
US7085854B2 (en) * 2000-04-12 2006-08-01 Corente, Inc. Methods and systems for enabling communication between a processor and a network operations center
US6631416B2 (en) * 2000-04-12 2003-10-07 Openreach Inc. Methods and systems for enabling a tunnel between two computers on a network
US6996628B2 (en) * 2000-04-12 2006-02-07 Corente, Inc. Methods and systems for managing virtual addresses for virtual networks
US7181542B2 (en) * 2000-04-12 2007-02-20 Corente, Inc. Method and system for managing and configuring virtual private networks
US7181766B2 (en) * 2000-04-12 2007-02-20 Corente, Inc. Methods and system for providing network services using at least one processor interfacing a base network
US6829654B1 (en) * 2000-06-23 2004-12-07 Cloudshield Technologies, Inc. Apparatus and method for virtual edge placement of web sites
US6772210B1 (en) * 2000-07-05 2004-08-03 Nortel Networks Limited Method and apparatus for exchanging communications between telephone number based devices in an internet protocol environment
US6910074B1 (en) * 2000-07-24 2005-06-21 Nortel Networks Limited System and method for service session management in an IP centric distributed network
WO2002015051A1 (en) * 2000-08-16 2002-02-21 Verisign, Inc. A numeric/voice name internet access architecture and methodology
US20020101859A1 (en) * 2000-09-12 2002-08-01 Maclean Ian B. Communicating between nodes in different wireless networks
KR20020027807A (ko) * 2000-10-05 2002-04-15 이종석 인터넷을 이용한 전화서비스 방법
US20020078153A1 (en) * 2000-11-02 2002-06-20 Chit Chung Providing secure, instantaneous, directory-integrated, multiparty, communications services
US20020087722A1 (en) * 2000-12-29 2002-07-04 Ragula Systems D/B/A/ Fatpipe Networks Domain name resolution making IP address selections in response to connection status when multiple connections are present
US7164883B2 (en) * 2001-02-14 2007-01-16 Motorola. Inc. Method and system for modeling and managing terrain, buildings, and infrastructure
US20020138622A1 (en) * 2001-03-21 2002-09-26 Motorola, Inc. Apparatus and method of using long lived addresses in a private network for push messaging to mobile devices
US20060020688A1 (en) * 2001-05-14 2006-01-26 At&T Corp. System having generalized client-server computing

Also Published As

Publication number Publication date
EP1400093A2 (en) 2004-03-24
WO2002102012A3 (en) 2003-04-03
DE60211897D1 (de) 2006-07-06
JP2004533190A (ja) 2004-10-28
WO2002102012A2 (en) 2002-12-19
DE60211897T2 (de) 2006-10-19
US20030028671A1 (en) 2003-02-06
ATE328436T1 (de) 2006-06-15
EP1400093B1 (en) 2006-05-31
CN1528081A (zh) 2004-09-08
AU2002345633A1 (en) 2002-12-23
KR20040034612A (ko) 2004-04-28

Similar Documents

Publication Publication Date Title
ES2263791T3 (es) Metodo, medio de memoria, red de ordenadores y dispositivo para la comunicacion de datos en modo bilateral con dispositivos radioelectricos.
EP2253124B1 (en) Method and apparatus for communication of data packets between local networks
US8908685B2 (en) Routing using global address pairs
JP4030373B2 (ja) 移動端末のアドレッシング方法
US6055236A (en) Method and system for locating network services with distributed network address translation
US7032242B1 (en) Method and system for distributed network address translation with network security features
EP1400092B1 (en) Network address translation of incoming sip connections
AU2009304186B2 (en) NAT traversal method and apparatus
US20040184456A1 (en) Packet-oriented data communications between mobile and fixed data networks
US9031074B2 (en) Method and apparatus for packet call setup
EP1059791A2 (en) Apparatus, and associated method, for identifying data with an address
US8612557B2 (en) Method for establishing connection between user-network of other technology and domain name system proxy server for controlling the same
EP1159815A1 (en) Method and system for distributed network address translation with network security features
EP1187426B1 (en) Method for using a unique IP address in a private IP address domain
NO338516B1 (no) Tilveiebringelse av en tjeneste til flere separat styrte nettverk
JP2001016255A (ja) ネットワーク間通信方法及びその装置
US20060031514A1 (en) Initiating communication sessions from a first computer network to a second computer network
CN101355568B (zh) 一种静态pat支持绑定路由器接口的方法及系统
KR102185665B1 (ko) All-IP 환경에서 IPv6 주소 기반의 통신을 위한 사용자 식별 서버, 단말, 방법, 및 기록 매체
JP4191180B2 (ja) 通信支援装置、システム、通信方法及びコンピュータプログラム
JP3893978B2 (ja) 通信装置
KR100705508B1 (ko) 인터넷 프로토콜의 통합 주소 관리 장치
CN117834585A (zh) 基于端口绑定的多业务通道dns转发方法与装置