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
Links
- 230000006854 communication Effects 0.000 title claims abstract description 55
- 238000004891 communication Methods 0.000 title claims abstract description 55
- 238000000034 method Methods 0.000 title claims abstract description 45
- 230000002146 bilateral effect Effects 0.000 title description 2
- IRLPACMLTUPBCL-KQYNXXCUSA-N 5'-adenylyl sulfate Chemical compound C1=NC=2C(N)=NC=NC=2N1[C@@H]1O[C@H](COP(O)(=O)OS(O)(=O)=O)[C@@H](O)[C@H]1O IRLPACMLTUPBCL-KQYNXXCUSA-N 0.000 claims abstract 7
- 238000005314 correlation function Methods 0.000 claims description 8
- 230000002457 bidirectional effect Effects 0.000 claims description 7
- 230000007175 bidirectional communication Effects 0.000 claims description 6
- 230000006870 function Effects 0.000 claims description 6
- 238000013507 mapping Methods 0.000 claims description 3
- 150000002500 ions Chemical class 0.000 abstract 1
- 238000007726 management method Methods 0.000 description 48
- 239000008186 active pharmaceutical agent Substances 0.000 description 46
- 230000007246 mechanism Effects 0.000 description 20
- 238000005516 engineering process Methods 0.000 description 11
- 238000010586 diagram Methods 0.000 description 10
- 238000012546 transfer Methods 0.000 description 9
- 238000006243 chemical reaction Methods 0.000 description 7
- 230000000875 corresponding effect Effects 0.000 description 7
- 230000001419 dependent effect Effects 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 239000000969 carrier Substances 0.000 description 2
- 230000002596 correlated effect Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 235000008694 Humulus lupulus Nutrition 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
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.
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.
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.
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.
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.
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.
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.
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.
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
\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.
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.
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)
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 |
AU2002321558A1 (en) * | 2001-08-24 | 2003-03-10 | British Telecommunications Public Limited Company | Apparatus and method of coordinating network events |
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 |
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 |
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 |
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 |
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 |
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 | 엘지전자 주식회사 | Nat를 갖는 망에서의 sip 서비스 방법 |
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 |
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 |
US7580915B2 (en) * | 2004-12-14 | 2009-08-25 | Sap Ag | Socket-like communication API for C |
US7689989B2 (en) * | 2004-12-28 | 2010-03-30 | Sap Ag | Thread monitoring using shared memory |
US7552153B2 (en) * | 2004-12-28 | 2009-06-23 | Sap Ag | Virtual machine monitoring using shared memory |
US20060143389A1 (en) * | 2004-12-28 | 2006-06-29 | Frank Kilian | Main concept for common cache management |
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 |
US7562138B2 (en) * | 2004-12-28 | 2009-07-14 | Sap | Shared memory based monitoring for application servers |
US7523196B2 (en) * | 2004-12-28 | 2009-04-21 | Sap Ag | Session 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 |
US8670316B2 (en) * | 2006-12-28 | 2014-03-11 | Telecom Italia S.P.A. | Method and apparatus to control application messages between 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 |
EP2294848B1 (en) | 2008-04-02 | 2016-03-09 | Vodafone Group PLC | Telecommunications network |
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 | 华为终端有限公司 | 数据连接的建立方法、服务端及移动终端 |
CN107436850B (zh) * | 2015-09-21 | 2022-04-29 | 华为技术有限公司 | 计算机系统和计算机系统中端点设备访问的方法 |
CN112042159B (zh) * | 2018-02-28 | 2024-01-16 | 诺基亚技术有限公司 | 将3gpp网络透明集成到tsn工业网络中 |
Family Cites Families (53)
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 |
US6134432A (en) * | 1997-06-17 | 2000-10-17 | Bulletin.Net, 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 |
US6675208B1 (en) * | 1997-10-14 | 2004-01-06 | Lucent Technologies Inc. | Registration scheme for network |
US6377982B1 (en) * | 1997-10-14 | 2002-04-23 | Lucent Technologies Inc. | Accounting system in a 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 |
US20020091855A1 (en) * | 2000-02-02 | 2002-07-11 | Yechiam Yemini | Method and apparatus for dynamically addressing and routing in a data 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 |
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 |
US6996628B2 (en) * | 2000-04-12 | 2006-02-07 | Corente, Inc. | Methods and systems for managing virtual addresses for virtual networks |
US6631416B2 (en) * | 2000-04-12 | 2003-10-07 | Openreach Inc. | Methods and systems for enabling a tunnel between two computers on a network |
US7085854B2 (en) * | 2000-04-12 | 2006-08-01 | Corente, Inc. | Methods and systems for enabling communication between a processor and a network operations center |
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 |
AU2001284644A1 (en) * | 2000-08-16 | 2002-02-25 | 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 |
-
2002
- 2002-06-10 AU AU2002345633A patent/AU2002345633A1/en not_active Abandoned
- 2002-06-10 CN CNA028140311A patent/CN1528081A/zh active Pending
- 2002-06-10 JP JP2003504622A patent/JP2004533190A/ja not_active Withdrawn
- 2002-06-10 US US10/167,240 patent/US20030028671A1/en not_active Abandoned
- 2002-06-10 DE DE60211897T patent/DE60211897T2/de not_active Expired - Fee Related
- 2002-06-10 AT AT02744283T patent/ATE328436T1/de not_active IP Right Cessation
- 2002-06-10 EP EP02744283A patent/EP1400093B1/en not_active Expired - Lifetime
- 2002-06-10 ES ES02744283T patent/ES2263791T3/es not_active Expired - Lifetime
- 2002-06-10 KR KR10-2003-7016044A patent/KR20040034612A/ko not_active Application Discontinuation
- 2002-06-10 WO PCT/US2002/018485 patent/WO2002102012A2/en active IP Right Grant
Also Published As
Publication number | Publication date |
---|---|
WO2002102012A3 (en) | 2003-04-03 |
CN1528081A (zh) | 2004-09-08 |
ATE328436T1 (de) | 2006-06-15 |
WO2002102012A2 (en) | 2002-12-19 |
EP1400093B1 (en) | 2006-05-31 |
US20030028671A1 (en) | 2003-02-06 |
EP1400093A2 (en) | 2004-03-24 |
KR20040034612A (ko) | 2004-04-28 |
DE60211897D1 (de) | 2006-07-06 |
JP2004533190A (ja) | 2004-10-28 |
DE60211897T2 (de) | 2006-10-19 |
AU2002345633A1 (en) | 2002-12-23 |
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转发方法与装置 |