DE60211897T2 - Verfahren, Speichermedium, Netwerk und Apparat für eine biderektional initierte Datenkommunikation mit einer drahtlosen Einrichtung - Google Patents

Verfahren, Speichermedium, Netwerk und Apparat für eine biderektional initierte Datenkommunikation mit einer drahtlosen Einrichtung Download PDF

Info

Publication number
DE60211897T2
DE60211897T2 DE60211897T DE60211897T DE60211897T2 DE 60211897 T2 DE60211897 T2 DE 60211897T2 DE 60211897 T DE60211897 T DE 60211897T DE 60211897 T DE60211897 T DE 60211897T DE 60211897 T2 DE60211897 T2 DE 60211897T2
Authority
DE
Germany
Prior art keywords
address
network
public
wireless device
public network
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 - Fee Related
Application number
DE60211897T
Other languages
English (en)
Other versions
DE60211897D1 (de
Inventor
Samir Narendra Sammamish MEHTA
Mazin Seattle RAMADAN
Geoffrey S. Seattle HELLER
Vineet R. Renton SHARMA
Markus L. Renton JANSEN
L. Edward Seattle GOW
Ngochan T. Seattle NGUYEN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
4TH PASS Inc SEATTLE
Motorola Mobility LLC
Original Assignee
4TH PASS Inc SEATTLE
4thPass Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 4TH PASS Inc SEATTLE, 4thPass Inc filed Critical 4TH PASS Inc SEATTLE
Application granted granted Critical
Publication of DE60211897D1 publication Critical patent/DE60211897D1/de
Publication of DE60211897T2 publication Critical patent/DE60211897T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

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

Landscapes

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

Description

  • HINTERGRUND DER ERFINDUNG
  • Erfindungsgebiet
  • Die vorliegende Erfindung betrifft Verfahren und Systeme zum Herstellen einer Verbindung mit Drahtlos-Vorrichtungen und insbesondere Verfahren und Systeme zum Herstellen einer Verbindung mit einer Vorrichtung in einem privaten Netzwerk von einer Vorrichtung in einem öffentlichen Netzwerk aus, um eine virtuelle Ende-Zu-Ende-Verbindung herzustellen.
  • Hintergrundinformationen
  • Die Notwendigkeit der Verbindung vernetzter Computer mit anderen Computernetzwerken ist zunehmend wichtiger geworden, da unsere globale Gesellschaft aus geschäftlichen und persönlichen Gründen danach strebt, international zu kommunizieren. Diese Notwendigkeit hat Fachkreise veranlasst, sich Möglichkeiten zu überlegen, wie Vorrichtungen auf unterschiedlichen physikalischen Netzen miteinander verbunden werden, so dass verschiedene und gleiche Netzwerke einheitlich (oder standardmäßig) miteinander kommunizieren können. Eine solche Verbindungstechnologie wird oft auch als „Internetworking", „Internetworks" oder einfach „Internets" bezeichnet. Eine derartige globale Internetworking-Implementierung ist das Internet, wie es ursprünglich von der ARPA, NSF usw. für Bildungs- und staatliche Zwecke entwickelt worden ist. Das Internet in seiner gegenwärtig erweiterten Version existiert als eine komplexe Infrastruktur aus Netzwerk-Backbones, die an Netzwerke in der ganzen Welt angeschlossen sind. Andere (lokale, regionale, private oder öffentliche) Netzwerke sind über Gateways oder Router (ebenfalls bekannt als Gateway-Server, Gateway-Systeme, Router-Server und Router-Systeme) mit dem Internet-Backbone verbunden. Bei dem vorliegenden Dokument können die Begriffe „Router" oder „Gateway" für sich allein oder zur Modifizierung eines anderen Substantivs austauschbar verwendet werden und bezeichnen im Allgemeinen jegliche Hardware oder Software, Teilsysteme, Systeme oder Codes, mit denen ein Datenpaket (auf einer beliebigen Ebene des Netzwerks bzw. des physikalischen Datentransfers) zwischen zwei oder mehreren homogenen oder heterogenen Maschinen, Systemen oder Teilsystemen ungeachtet des speziellen Gateways/Routers oder Dienstes übertragen werden kann. In der Internet-Umgebung zeigt das Vorliegen eines Routers oder Gateways meist eine Fähigkeit an, ein Internet-Datagramm zu einem anderen Router oder einer anderen Maschine zu leiten. Maschinen, auf denen Anwendungen laufen sollen, werden in der Netzwerkterminologie als „Host" oder „Host-Maschinen" bezeichnet, wobei im vorliegenden Fall ein Router/Gateway eine Funktion einer Host-Maschine oder einer separate Vorrichtung sein kann.
  • Im Internet kommunizieren die einzelnen Netzwerke und Vorrichtungen mit Hilfe von Standard-Netzwerkprotokollen und -Modellen, z. B. TCP/IP (oder UDP/IP). Wenngleich angenommen wird, dass der Leser des vorliegenden Dokuments mit Netzwerkkonzepten, -protokollen und -standards vertraut ist, wird zum leichteren Verständnis hier eine kurze Zusammenfassung gegeben. Ausführliche Hintergrundinformationen über das Internetworking, Internets, das Internet und damit zusammenhängende Begriffe und dazugehörige Technologien findet man in Tanenbaum, A. Computer Networks, Prenctice-Hall, N. J. 3. Auflage, 1996, und in Comer, D. Internetworking with TCP/IP, Principles, Protocols, and Architectures, Prentice Hall, N.J. 4. Auflage, 2000.
  • TCP/IP und UDP/IP (oft als „UDP" bezeichnet) bezieht sich auf Kombinationen aus einer populären Transportschicht und Netzwerkschicht-Protokollen, die man üblicherweise in Internetworking-Umgebungen vorfindet (auf jeder dieser Schichten stehen ebenfalls andere Protokolle zur Verfügung). Das „IP" in TCP/IP steht für „Internet Protocol", wobei es sich um ein Netzwerkschicht-Protokoll handelt, welches festlegt, wie Daten organisiert und dargestellt werden (das Format und die Bedeutung von Datagrammen), und die Kommunikations-Transaktionen, die zum Routen von selbigen verwendet werden. TCP („Transmission Control Protocol") und UDP („User Datagram Protocol"), bei denen es sich jeweils um Transportschichtprotokolle handelt, die zusätzlich zu einem IP-Protokoll implementiert werden können, unterstützen die verbindungsbasierte bzw. die verbindungslose Datenübertragung. Unter einer verbindungsbasierten Datenübertragung versteht man, dass eine Quellen- und eine Zielvorrichtung eine Verbindung anfordern und anschließend über die „virtuelle" Verbindung nacheinander Daten zueinander senden (typischerweise umfassen sie Handshake-Mechanismen). Mit dem Begriff „virtuell" ist hier gemeint, dass, wenngleich die Verbindung nicht unbedingt verdrahtet sein muss, die Verbindung dennoch eine direkte Leitung zwischen einer Quelle (Anforderer) und einem Ziel (Empfänger) bereitzustellen scheint. Die Daten strömen dabei durch die unteren Protokollschichten, so dass sie letztendlich über ein physikalisches Übertragsmedium übertragen werden. Die verbindungslose Datenübertragung impliziert, dass die Quelle ein Datagramm zum Ziel sendet, jedoch nicht sicherstellt, dass die Daten in einer bestimmten Reihenfolge geliefert werden bzw. ankommen.
  • Des Weiteren definiert das IP-Protokoll einen einheitlichen Netzwerkadressier-Mechanismus, so dass Maschinen, die Protokolle implementieren, welche IP verwenden, z. B. TCP oder UDP, in der Lage sind, Quellen und Ziele für ihre Datenübertragungen anzubieten. Der Netzwerkadressier-Mechanismus gibt eine abstrakte Adresse und ein Bindungsprotokoll zum Abbilden der abstrakten Adresse auf eine physikalische Hardware-Adresse an. Bei der vorliegenden Beschreibung wird der einheitliche Netzwerkadressier-Mechanismus im Allgemeinen als „IP-Adresse" bezeichnet. Oft werden IP-Adressen in der „gepunkteten Dezimal-Notation" geschrieben, die eine Adresse als „w.x.y.z" angibt (z. B. kennzeichnet in einer 32-Bit-Adresse jeder Buchstabe ein Byte an Informationen). So kann beispielsweise eine IP-Adresse wie „192.251.0.1" eine Host-Maschine im Netzwerk „192", Teilnetz „251 ", Domain „0" angeben. Bei Verwendung von IP sind im typischen Fall eine Reihe von Adressen für die private Netzwerknutzung und die übrigen IP-Adressen entweder für andere Verwendungszwecke oder für öffentliche (routable) Adressen reserviert, die von einer Genehmigungsorganisation zugeordnet werden. Mehrere private Netzwerke können intern die gleichen (non-routable) IP-Adressen zuordnen (gegenwärtig die Internet Corporation for Assigned Names and Numbers), müssen jedoch einheitliche IP-Adressen verwenden, um sich an das Internet anzuschließen. Z. B. können in Netzwerken der Klasse B (die mit Hilfe von klassenbasierten Adressabkommen jeweils bis zu 254 Host-Maschinen zulassen) private Adressen von 192.168.0.0 bis 192.168.255.0 reichen. Adressierabkommen sind den Fachleuten auf diesem Gebiet hinlänglich bekannt sind, und folglich wird davon ausgegangen, dass sie auch dem Leser der vorliegenden Schrift bekannt sind. Bei der vorliegenden Anmeldung wird davon ausgegangen, dass eine IP-Adresse eine beliebige Adresse ist, die in einer besonderen Internet-Working-Umgebung sinnvoll ist (und definiert ist), obwohl auch auf Beispiele verwiesen werden kann, die die Internet-IP-Adressierung anwenden. Ein Netzwerk, welches IP unterstützt, kann mit einem anderen TCP/IP-basierten oder UDP/IP-basierten Internet oder dem Internet verbunden werden, indem ein Router geschaffen wird, der auf der Grundlage einer IP-Adresse Daten zu einem anderen Router oder einer anderen Host-Maschine schickt. Im typischen Fall enthält der Router (oder Router-Server/Dienst) eine Routing-Tabelle, die festlegt, zu welcher Maschine (und optional zu welchem Port) ein Datagramm angesichts einer bestimmten Ziel-IP-Adresse gesendet wird. Die IP-Adresse identifiziert einen Router/eine Host-Maschine eindeutig und kann in einem typischen TCP/IP-Netzwerk auf einen String-Namen abgebildet werden, der z. B. eine spezielle Maschine als Teil eines größeren Domains identifiziert. (Wenngleich hier oft auf ein TCP/IP-basiertes Netzwerk Bezug genommen wird, liegt es für Fachleute auf der Hand, dass es sich bei dem Netzwerk auch um ein UDP-basiertes (verbindungsloses) handeln kann und ein anderes Sitzungsverwaltungssystem unterstützen kann.)
  • In einem typischen TCP/IP-(Inter)network sind die Maschinen entsprechend einer Namensgebungshierarchie angeordnet. Eine solche Hierarchie ist das Domain Name System („DNS"), welches angibt, wie eine spezielle Maschine mit den anderen verbunden ist. (Der Begriff DNS wird mitunter auch dazu verwendet, einen Server oder Dienst zu identifizieren, der das DNS-Protokoll implementiert.) Z. B. kann der String (die Zeichenkette) „initials_machine.4thpass.service_provider.com„ dazu verwendet werden, eine Maschine anzugeben, die Ihnen gehört und an das LAN der 4th Pass Company angeschlossen ist, welches wiederum an das WAN (Wide Area Network) eines Service Providers angeschlossen ist. TCP/IP und UDP/IP definieren Tools/Bibliotheken für Client-Systeme, mit denen von einem String-Namen eines speziellen Routers/einer Maschine eine IP-Adresse (eine logische Adresse in einem Internet) ermittelt wird. Ein derartiges Tool wird auch als DNS-Abfrage bezeichnet und enthält beispielsweise eine API mit dem Namen „GetHostByName". GetHostByName gibt für einen String eine IP-Adresse zurück. In der vorliegenden Beschreibung wird eine Server-Maschine, die den DNS-Standard für eine spezielle Organisation, ein Netzwerk oder ein Teilnetzwerk implementiert, einfach als DNS bezeichnet, wenngleich DNS-Dienste auch mit anderen Netzwerkdiensten zusammen auf ein und derselben physikalischen Maschine bereitgestellt werden können.
  • 1 ist ein Beispiel-Blockdiagramm der grundlegenden Internet-Kommunikation zum Senden eines Datenpakets mit Hilfe von TCP/IP oder UDP/IP. In 1 ist eine Host-Maschine 101 über eine Leitung 102 an das Internet 110 angeschlossen. Andere verdrahtete Vorrichtungen, z. B. die Host-Maschinen 140 und 141, sind in der Abbildung an ein privates (oder öffentliches) Netzwerk 130 angeschlossen, bei dem es sich beispielsweise um ein lokales Netzwerk (LAN) handeln könnte. Die Vorrichtungen im Netzwerk 130 kommunizieren über das Internet 110 mit Hilfe einer zusätzlichen Maschine, eines Routers 121, der in der Abbildung über einen Draht angeschlossen ist (z. B. eine Telefonleitung). Ein DNS-Server 120 ist ebenfalls über eine Leitung an das Internet 110 angeschlossen. In einer typischen Grundoperation führt die Quellenvorrichtung (Host-Maschine 101), mit der ein Datenpaket zur Vorrichtung 140 (über TCP oder UDP) gesendet werden soll, zuerst eine DNS-Abfrage aus, um eine IP-Adresse zu erhalten, wel che einem String-Namen entspricht, der die Vorrichtung 140 repräsentiert. Um beispielsweise Daten zu „initials_machine.4thpass.service_provider.com" zu senden, kann das DNS 120 einem DNS-Server für „4thpass.com" entsprechen. Der Server weiß, wie er Maschinen in seiner Domain" lokalisiert, z. B. die „initials_machine", und kann diese entsprechende öffentliche IP-Adressen abrufen. Nach dem Ermitteln der korrekten (öffentlichen) IP-Adresse gibt das DNS 120 diese Adresse an die Quellenvorrichtung 101 zurück. Die Qellenvorrichtung 101 kann entweder eine TCP-Verbindung herstellen, um mit der Zielvorrichtung 140 zu kommunizieren, oder einfach Pakete über UDP oder ein anderes verbindungsloses Protokoll unter Zuhilfenahme der zurückgeschickten öffentlichen IP-Adresse zu senden.
  • EP-A-1003315 legt ein Verfahren in einem Computer-Netzwerk entsprechend dem einleitenden Teil von Anspruch 1 offen.
  • KURZE ZUSAMMENFASSUNG DER ERFINDUNG
  • Die vorliegende Erfindung wird ausschließlich durch die unabhängigen Ansprüche 1, 13–17 definiert. Die abhängigen Ansprüche beziehen sich auf bevorzugte Ausführungsformen.
  • Ausführungsformen der vorliegenden Erfindung schaffen computer- und netzwerkbasierte Systeme für eine in zwei Richtungen initiierte bidirektionale Kommunikation mit Drahtlos-Vorrichtungen unter Zuhilfenahme von verbindungsbasierten oder verbindungslosen Protokollen, beispielsweise TCP/IP und UDP/IP. Beispiel-Ausführungsformen schaffen ein Adressverwaltungs-Proxysystem („Address Management Proxy System – AMPS"), welches an ein öffentliches Internets-Netzwerk, z. B. das Internet, angeschlossene Vorrichtungen und Systeme in die Lage versetzt, eine Verbindung mit an ein privates drahtloses Netzwerk angeschlossenen Drahtlos-Vorrichtungen herzustellen, um Daten an selbige zu senden, ohne die nicht non-routable privaten Adressen dieser Drahtlos-Vorrichtungen offen zu legen. Das AMPS ordnet mit Hilfe einer Anforderungsvorrichtung für die temporäre Nutzung eine öffentliche (routable) Netzwerkadresse in einem externen öffentlichen Netzwerk zu, um mit einer Drahtlos-Vorrichtung in einem privaten Drahtlos-Netzwerk zu kommunizieren. Bei einer Ausführungsform wird ein Pool öffentlicher Adressen, z. B. öffentliche IP-Adressen, von dem AMPS verwaltet und den Vorrichtungen des Drahtlos-Netzwerks nach Bedarf dynamisch zugeordnet. Das Abbilden einer temporären öffentlichen Adresse auf die private Adresse einer Drahtlos-Vorrichtung wird von dem AMPS mit Hilfe von Routing-Tabellen und anderen Abbildungs-Datenstrukturen gepflegt und transparent aktualisiert.
  • Bei einer Ausführungsform umfasst das AMPS einen oder mehrere modifizierte DNS/API-Server, einen oder mehrere Adress-Proxy/Router, einen Adressverwaltungs-Datenserver, einen oder mehrere Adressverwaltungs-Daten-Repository und wahlweise eine Lastenausgleichseinrichtung. Der DNS'/API-Server des AMPS empfängt eine Anforderung von einer Vorrichtung in einem öffentlichen Netzwerk im Hinblick auf eine spezielle Drahtlos-Vorrichtung und gibt eine entsprechende temporäre öffentliche Adresse aus und zurück, die intern auf die private Adresse der Drahtlos-Vorrichtung abgebildet wird. Anschließend kann die öffentliche Adresse von der Vorrichtung in dem externen öffentlichen Netzwerk dazu verwendet werden, Daten zu der Drahtlos-Vorrichtung zu senden. Die temporäre öffentliche Adresse ist beispielsweise eine Adresse, die mit einem der Adress-Proxy/Router verknüpft ist, die mit dem externen öffentlichen Netzwerk verbunden sind und Zugang zu den privaten Adressen im privaten Drahtlos-Netzwerk haben. In einigen Fällen verwendet die Vorrichtung im öffentlichen Netzwerk, die Daten an die Drahtlos-Vorrichtung senden möchte, ein verbindungsbasiertes Protokoll, z. B. TCP/IP, um Daten zu senden. In anderen Fällen verwendet die Vorrichtung ein verbindungsloses Protokoll, z. B. UDP (UDP/IP), um die Daten zu senden.
  • Gemäß einer Herangehensweise erzeugt das AMPS einen modifizierten DNS-Server, der das, was als Ergebnis eines Anrufs zurückgeführt wird, in eine standardmäßige DNS-Abfragefunktion ändert, z. B. GetHostByName. Bei einem anderen Ansatz implementiert das AMPS eine spezielle API für eine Vorrichtung in einem öffentlichen Netzwerk, welche für die Abfrage einer öffentlichen Adresse einer bestimmten Drahtlos-Vorrichtung verwendet wird. Mit Hilfe der speziellen API-Implementierung, zusammen mit dem Internet-Protokoll, kann das AMPS private Adressen auf Adressen abbilden, die lediglich IP-Adressen umfassen, oder kann sie als ein Paar aus IP-Adresse und Port abbilden. Durch letztere Implementierung kann sich der Nutzwert eines speziellen öffentlichen Adressraumes vergrößern.
  • Die AMPS-Verfahren können von einer verdrahteten Vorrichtung in einem privaten oder öffentlichen Netzwerk oder von einer Drahtlos-Vorrichtung in einen derartigen Netzwerk verwendet werden, die in der Eigenschaft als Quellenvorrichtung wirksam wird, solange die Vorrichtung an ein öffentliches Netzwerk angeschlossen ist, welches das AMPS adressieren kann und von selbigem adressiert werden kann. Folglich können die AMPS-Mechanismen von Vorrichtungen in verschiedenen privaten, Drahtlos-Netzwerken genutzt werden, um miteinander zu kommunizieren. Darüber hinaus können die AMPS-Mechanismen mit anderen Internetworks verwendet werden, z. B. ATM-Netzwerken, und mit anderen Datenübertragungsprotokollen als dem TCP/IP oder UDP.
  • Um eine größere Sicherheit zu gewährleisten, behält das AMPS nach einer Ausführungsform bei jeder Adressabbildung einen Time-to-Live-Parameter (TTL) bei. Somit kann das AMPS immer dann, wenn der TTL-Wert anzeigt, dass die Abbildung beendet ist, die Abbildung vernichten und ebenso jegliche Verbindung. Weiterhin setzt das AMPS in einigen Ausführungsformen einen Zeitstempel in eine ihrer eigenen Abbildungstabellen. Nachdem eine gewisse Zeitspanne, ausgehend von dem Zeitstempel, abgelaufen ist, kann das AMPS die Abbildung vernichten, wodurch periodisch das Initiieren einer neuen Abbildung erzwungen wird.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Beispiel-Blockdiagramm für ein grundlegendes Internet bzw. eine Internet-Verbindung, um ein Datenpaket mit Hilfe von TCP/IP oder UDP/IP zu senden.
  • 2 ist ein Blockdiagramm eines Beispiel-Adressverwaltungs-Proxysystems, welches bei der bidirektionalen Kommunikation mit einer Drahtlos-Vorrichtung verwendet wird.
  • 3 ist ein Beispiel-Blockdiagramm von Komponenten eines Beispiel-Adressverwaltungs-Proxysystems.
  • 4 ist ein Beispiel-Blockdiagramm eines allgemeinen Computersystems zur Anwendung von Ausführungsformen des Adressverwaltungs-Proxysystems.
  • 5 ist ein Beispiel-Flussdiagramm des Prozesses, der von einer Vorrichtung in einem öffentlichen Netzwerk ausgeführt wird, um Daten mit Hilfe des Adressverwaltungs-Proxysystems zu einer Drahtlos-Vorrichtung zu senden, die sich in einem privaten Drahtlos-Netzwerk befindet.
  • 6 ist ein Beispiel-Blockdiagramm einiger Daten-Repository-Tabellen des Adressverwaltungs-Proxysystems, mit denen Routinen der DNS'/API-Server und der Adress-Proxy/Router unterstützt werden.
  • 7 ist ein Beispiel-Flussdiagramm einer Beispielroutine, die von einem DNS'/API-Server des Adressverwaltungs-Proxysystems erzeugt wird, um eine öffentliche Adresse zurückzugeben, die einem bestimmten eindeutigen Identifier entspricht.
  • 8 ist ein Beispiel-Flussdiagramm einer Beispielroutine innerhalb eines Adress-Proxys/Routers eines Beispiel-Adressverwaltungs-Proxysystems, welche Daten empfängt.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Ausführungsformen der vorliegenden Erfindung erzeugen computer- und netzwerkbasierte Verfahren und Systeme für eine in beide Richtungen initiierte, bidirektionale Kommunikation mit Drahtlos-Vorrichtungen unter Verwendung verbindungsbasierter oder verbindungsloser Protokolle, z. B. TCP/IP und UDP/IP. Beispiel-Ausführungsformen erzeugen ein Adressverwaltungs-Proxysystem („AMPS"), welches Vorrichtungen und Systeme, die an ein öffentliches Internet angeschlossen sind, z. B. das Internet, um eine Kommunikation mit Drahtlos-Vorrichtungen herzustellen, die an ein privates drahtloses Netzwerk angeschlossen sind, und Daten an sie zu senden, ohne die non-routable privaten Adressen dieser Drahtlos-Vorrichtungen offen zu legen.
  • Bei vorhandenen Systemen kann die Datenkommunikation (Kommunikation auf einem Datenkanal) zwischen einer Drahtlos-Vorrichtung, die an ein privates Drahtlos-Netzwerk angeschlossen ist, und einer verdrahteten Vorrichtung, die an öffentliches verdrahtetes Netzwerk angeschlossen ist (z. B. das Internet), lediglich von der Drahtlos-Vorrichtung hergestellt werden. Einige Netzbetreiber haben Drahtlos-Vorrichtungen feststehende öffentliche IP-Adressen zugeordnet, allerdings benötigen dann die Drahtlos-Vorrichtungen die Fähigkeit von Client-Programmen (z. B. ein UDP-Stapel), mit der eingehende Kommunikationspakete empfangen und bearbeitet werden können. Darüber hinaus sind diese Drahtlos-Vorrichtungen dann Teil eines öffentlichen Drahtlos-Netzwerkes und nicht eines privaten Drahtlos-Netzwerkes. Da öffentliche IP-Adressen immer rarer werden und es gegenwärtig immer teurer wird, Dienste für ein Netzwerk aus mehreren Millionen Vorrichtungen bereitzustellen, können Netzbetreiber praktisch nicht darauf zählen, für jede Vorrichtung im Netzwerk eine feststehende öffentliche IP-Adresse zu haben. (Wenngleich die Verschiebung hin zu IPv6 mehr Adressen zulassen wird, sind die gegenwärtigen Definitionen von IPv4 begrenzt, und die potenzielle Anzahl von Drahtlos-Nutzern, die größere Netzbetreiber abonnieren, ist sehr groß. In einigen Regionen der Welt ist das aktuelle öffentliche Adresszuordnungsschema noch stärker eingegrenzt.) Darüber hinaus würde diese Adressierbarkeit jede Vorrichtung weiteren Sicherheitsrisikos aussetzen, da jede dieser Vorrichtungen Teil eines öffentlich zugänglichen Netzwerkes ist und es immer schwieriger wird, Sicherheitsmaßnahmen einzuführen und zu vollstrecken. Daher wird in vorhandenen Drahtlos-Netzwerken das Zuordnen privater IP-Adressen zu den Vorrichtungen dem Zuordnen feststehender öffentlicher IP-Adressen zu den Vorrichtungen bevorzugt. Wenn die Drahtlos-Netzwerke privat sind, werden die Orte (Adressen) der Drahtlos-Vorrichtungen absichtlich durch die Infrastruktur eines Netzbetreibersystems (in einigen Ländern als Operator bezeichnet,) der öffentlichen Betrachtung vorenthalten.
  • Drahtlos-Systeme in privaten Netzwerken nutzen ähnliche Verfahren wie die Technologie der Network Address Translation (NAT), um Daten von einer Drahtlos-Vorrichtung zu der öffentlichen Netzwerkwelt zu senden. Bei einer typischen Netzbetreiber-Infrastruktur, die ein privates Netzwerk nutzt, „registriert sich" eine Drahtlos-Vorrichtung selbst bei der Netzbetreiber-Infrastruktur, wenn sie eingeschaltet wird (oder unter anderen Umständen, wenn die Vorrichtung versucht, Datenleistungen in Gang zu setzen). Mit Hilfe eines DHCP-Servers (oder DHCP-artigen Servers) ordnet der Netzbetreiber der Drahtlos-Vorrichtung dynamisch eine private non-routable Adresse zu. Die Information über die Abbildung der vorübergehenden privaten IP-Adresse auf die öffentliche IP-Adresse der Vorrichtung ist in einer internen Datenbank des Netzbetreibers gespeichert und wird von Netzbetreiberdiensten verwaltet, wie z. B. von einem RADIUS-Server.
  • Der tatsächliche Pfad, der von Daten zurückgelegt wird, wenn sie von einer Drahtlos-Vorrichtung in einem privaten Netzwerk zum Internet (oder umgekehrt) gesendet werden, ist sehr stark von der Infrastruktur des Netzwerkes und von dessen Technologie abhängig und proprietär. In einem GPRS-Netzwerk z. B. verwaltet ein SGSN (Service GPRS Node) die Kommunikation mit Drahtlos-Vorrichtungen; während das SGSN mit einem GGSN (Gateway GPRS Node) verbunden ist, so dass die Verbindung zum Internet-Netzwerk hergestellt wird. Ungeachtet des verwendeten mobilen Netzwerks gehört zu der Datenkommunikation zwischen einer Drahtlos-Vorrichtung und dem Internet eine Vielzahl verschiedener Netzwerkelemente wie GGSN (oder ähnliche Elemente) auf der Basis von GPRS, GSM, CDMA oder einem anderen Netzwerk), DNS-Server, Router und Gateways.
  • Begrenzte Möglichkeiten existieren für das Senden von Kurznachrichten von einer verdrahteten Vorrichtung in einem öffentlichen Netzwerk zu einer mobilen Vorrichtung in einem Drahtlos-Netzwerk (mit einer privaten Adresse), wiederum abhängig von dem Netzbetreiber und der Netzwerktechnologie. Das SMS-(Short Message System)-Protokoll definiert ein Format für derartige Nachrichten, bietet jedoch keinerlei Hinweis auf die zugrunde liegenden Strukturen oder die Datenübertragung. Darüber hinaus haben derartige Nachrichten eine feststehende (sehr geringe) Länge und nutzen einen besonderen Kanal zum Senden der Steuerinformationen (ein Signalkanal), und nicht einen Datenkanal.
  • Demzufolge gibt es keinen vorhandenen Mechanismus für das Erstellen eines bidirektionalen Kommunikationskanals für die Kommunikation mit Drahtlos-Vorrichtungen, die unter Verwendung eines Standard-Adressierschemas über ein privates Netzwerk mit der Netzbetreiber-Infrastruktur verbunden sind. Außerdem gibt es keinen Mechanismus zum In-Gang-Setzen der Kommunikation mit einer derartigen Drahtlos-Vorrichtung von einer Vorrichtung aus, die an ein öffentliches Netzwerk angeschlossen ist. Somit können Aus führungsformen vorhandener Systeme keinerlei programmatischen „Schub" von Daten von verdrahteten Vorrichtungen, die sich außerhalb der Infrastruktur eines Netzbetreibers befinden, zu Drahtlos-Vorrichtungen unterstützen. Des Weiteren kann auf die Nachricht, die von der Drahtlos-Vorrichtung zu einer Vorrichtung in einem öffentlichen (auch verdrahteten) Netzwerk gesendet werden, von der verdrahteten Vorrichtung nicht direkt geantwortet werden, da die Adresse der Drahtlos-Vorrichtung, die in der Nachricht enthalten ist, möglicherweise nicht mehr gültig ist. Zudem ist es nicht möglich, mit diesem System Drahtlos-Anwendungen bereitzustellen und einen anderen Code von einer Vorrichtung außerhalb der Netzbetreiber-Infrastruktur zu einer Drahtlos-Vorrichtung zu senden. Die Drahtlos-Bereitstellung und dazugehörige Verfahren zum dynamischen Erzeugen und Downloaden von Anwendungen auf Drahtlos-Vorrichtungen sind genauer in der Schrift WO 02 448 92 mit dem Titel „Method and System for Maintaining and Distributing Wireless Applications", veröffentlicht am 6.6.2002, erörtert. Folglich ist ein Mechanismus, der es einer externen Vorrichtung mit einer öffentlichen IP-Adresse ermöglicht, eine bidirektionale Kommunikation mit einer Drahtlos-Vorrichtung herzustellen, höchst erwünscht. Das Adressverwaltungs-Proxysystem erreicht die in zwei Richtungen initiierte bidirektionale Kommunikation durch Implementierung eines modifizierten DNS-Servers, der als Proxy/Router für Vorrichtungen im privaten Drahtlos-Netzwerk dient, wenn sie eine Schnittstelle zu der öffentlichen verdrahteten Internetwelt bilden. Zusammenfassend lässt sich sagen, dass vom AMPS ein Pool öffentlicher Adressen aufrechterhalten und je nach Bedarf zwischen aktiven Drahtlos-Vorrichtungen dynamisch verteilt wird.
  • 2 ist ein Blockdiagramm eines Beispiel-Adressverwaltungs-Proxysystems, das in der bidirektionalen Kommunikation mit einer Drahtlos-Vorrichtung verwendet wird. Unter dem Begriff „bidirektional" ist in vorliegender Beschreibung zu verstehen, dass die Datenpfade und die Kommunikation zwischen zwei Endpunkt-Systemen in beide Richtungen verlaufen können. 2 zeigt die Drahtlos-Vorrichtungen 201, 202 und 203, die an das öffentliche Netzwerk 210 angeschlossen sind. Fachleuten ist klar, dass diese Vorrichtungen auch an ein anderes privates oder öffentliches Netzwerk angeschlossen sein könnten, welches dann wiederum über eine oder mehrere verdrahtete Vorrichtungen mit dem öffentlichen Netzwerk 210 verbunden sind, und noch immer die hier erörterte Funktionalität erreichen könnten. Jede dieser Varianten stellt eine äquivalente Funktionalität dar und wird explizit bedacht und als Teil der Erfindung betrachtet. Auf der Drahtlosseite ist das AMPS 220, das in seiner Eigenschaft als Proxy (und Router) für Drahtlos-Vorrichtungen agiert, sowohl über die Verdrahtung mit dem öffentlichen Netzwerk 210 als auch über standardmäßige Netzbetreiber-Infrastrukturelemente (nicht abgebildet) an das Drahtlos-Netzwerk 230 angeschlossen dargestellt. Es wird davon ausgegangen, dass der Leser über Grundkenntnisse der Elemente einer Netzbetreiber-Infrastruktur und die grundlegenden Mechanismen zum Routing sowie zum Umwandeln von Paketen aus einem verdrahteten Netzwerk in ein Drahtlos-Netzwerk hat. Hierbei kann eine analoge oder eine digitale Technologie zur Anwendung kommen und Protokollumwandlungen erforderlich machen, um die physikalischen Daten z. B. über einen Satelliten letztendlich zu den Drahtlos-Vorrichtungen zu senden und zu übertragen. Detaillierte Hintergrundinformationen über die Drahtlos-Technologie und Drahtlos-Routing-Mechanismen sind in Stallings, W. Wireless Communications and Networks, Prentice Hall, N. J., 2002 beschrieben. In 2 ist die Drahtlos-Vorrichtung 240 über verschiedene Drahtlos-Elemente (nicht abgebildet) an das Drahtlos-Netzwerk 230 angeschlossen.
  • Wenn eine verdrahtete Vorrichtung, wie z. B. die verdrahtete Vorrichtung 201, während des Betriebs Daten zu einer Drahtlos-Vorrichtung 240 senden möchte, muss sie zuerst eine Position einer routable Adresse der Drahtlos-Vorrichtung 240 im öffentlichen Netzwerk 210 ermitteln. Allerdings ist aus 2 ersichtlich, dass die Drahtlos-Vorrichtung 240 nicht direkt mit dem öffentlichen Netzwerk 210 verbunden ist. Daher muss die verdrahtete Vorrichtung das Adressverwaltungs-Proxysystem 220 nutzen, um eine routable (öffentliche) Adresse festzulegen, zu der die für die Drahtlos-Vorrichtung 240 bestimmten Daten gesendet werden. Dazu führt die verdrahtete Vorrichtung 201 eine Abfrage (z. B. eine modifizierte DNS-Abfrage) durch, um so eine routable öffentliche Adresse zu finden, die der Drahtlos-Vorrichtung 240 entspricht. Das Adressverwaltungs-Proxysystem 220 empfängt die Abfrage und legt eine öffentliche (routable) Adresse aus einem Adressenpool fest und ordnet diese zu, wobei diese Adresse als Zieladresse für Datenpakete verwendet werden kann, die zu der Drahtlos-Vorrichtung 240 gelangen sollen. Man sollte beachten, dass das Adressverwaltungs-Proxysystem, wenngleich hier als DNA-Abfrage dargestellt, wie im Weiteren beschrieben die DNS-Abfrage-Implementierung modifiziert, um die Drahtlos-Vorrichtungstechnologie zu nutzen und/oder eine alternative API zu erzeugen, mit der eine geeignete routable Adresse festgelegt wird. Nachdem das Adressverwaltungs-Proxysystem 220 eine routable Adresse an die verdrahtete Vorrichtung 201 zurückgegeben hat, kann die verdrahtete Vorrichtung 201 Daten zu jener Adresse senden. Das Adressverwaltungs-Proxysystem 220 empfängt die Daten, wandelt Format und Protokolle usw. nach Bedarf um und sendet die konvertierten Daten über das Drahtlos-Netzwerk 230 zu der Drahtlos-Vorrichtung 240.
  • 3 ist ein Beispiel-Blockdiagramm von Komponenten eines Beispiel-Adressverwaltungs-Proxysystems. Bei einer Ausführungsform umfasst das Adressverwaltungs- Proxysystem (AMPS) einen oder mehrere modifizierte DNS'/API-Server 302, einen oder mehrere Adress-Proxy/Router 305, einen Adressverwaltungs-Datenserver 303, der eine Datenbank oder andere Repositories, z. B. das Adressverwaltungs-Daten-Repository 304 verwaltet, und optional eine Lastenausgleichseinrichtung 301. Die DNS'/API-Server 302 sind entweder einzeln an ein öffentliches Netzwerk 310 angeschlossen oder mit der Lastenausgleichseinrichtung 301 verbunden, die wiederum an das öffentliche Netzwerk 310 angeschlossen ist. Genauso ist auch jeder Adress-Proxy/Router 305 mit dem öffentlichen Netzwerk 310 verbunden, und zwar über die routable (öffentliche) Adresse, zu der die von dem externen Netzwerk 310 für die Drahtlos-Vorrichtungen bestimmten Daten gesendet werden. Die DNS'/API-Server 302 sind entweder modifizierte Implementierungen eines DNS-Servers, um eine Funktionalität hinzuzufügen, die für die Kommunikation mit Drahtlos-Vorrichtungen notwendig ist, oder sie sind Server, die eine oder mehrere spezielle APIs implementieren, wie nachstehend beschrieben wird. Die DNS'/API-Server 302 nutzen den Adressverwaltungs-Datenserver 303 beim Abbilden eines eindeutigen Identifiers (z. B. String-Name) für eine Drahtlos-Vorrichtung auf eine öffentliche Adresse im öffentlichen Netzwerk 310. Der Pool öffentlicher Adressen wird auch von dem Adressverwaltungs-Datenserver 303 und dem Daten-Repository 304 verwaltet. Der Adressverwaltungs-Datenserver 303 und der Adressverwaltungs-Daten-Repository 304 können mit Hilfe der vorhandenen Datenbanktechnologie, z. B. ODBC-Technologie, implementiert sein, oder als eine Struktur, wie eine einfache Textdatei. Fachleuten ist klar, dass jede Ausführungsform zum Speichern einer Gruppe von Tabellen, Daten, Listen oder Abbildungen verwendet werden kann. Des Weiteren verwendet jeder Adress-Proxy/Router 305 den Adressverwaltungs-Datenserver 303 oder ein Äquivalent von ihm, um eine Serie von Routing-Tabellen zu erzeugen und zu aktualisieren, die je nach Bedarf zum Zuordnen öffentlicher Adressen zu den Drahtlos-Vorrichtungen und zum Aktualisieren der verschiedenen Abbildungen zwischen den öffentlichen Adressen und den non-routable (privaten) Adressen der Drahtlos-Vorrichtungen verwendet werden. Die Tabellen und Abbildungen, die im Namen der DNS'/API-Server 203 und der Adress-Proxy/Router 305 von dem Adressverwaltungs-Datenserver 303 gehalten werden, werden nachstehend anhand von 6 beschrieben.
  • Obwohl die Verfahren des AMPS allgemein auf jede verdrahtete Vorrichtung anwendbar sind, die mit einer Drahtlos-Vorrichtung kommuniziert, ist unter dem Ausdrucköffentliches Netzwerk" (oder "verdrahtetes Netzwerk") jede Art einer durch ein Internet verbundenen Umgebung einschließlich eines öffentlichen Netzwerks oder eines Backbones zu verstehen, der sich irgendwo auf der Leitungsstrecke befindet und an eines oder mehre re private oder öffentliche Netzwerke angeschlossen ist. Obwohl bei den hier beschriebenen Beispielen oft auf das Internet Bezug genommen wird, erkennen Fachleute, dass die beschriebenen Konzepte und Erfindungen auf andere Formen und Ausführungsformen des Internetworking, einschließlich von Beispielen bei ATM-Netzwerken, ebenso anwendbar sind. Folglich können die erfindungsgemäßen Verfahren auch von einer Vorrichtung in einem ersten Drahtlos-Netzwerk genutzt werden, die mit einer anderen Drahtlos-Vorrichtung in einem zweiten Netzwerk kommunizieren will – schließlich kommuniziert jede Vorrichtung mit dem Adress-Proxy/Router des anderen Netzwerks. Dieses Szenario ist denkbar, da jedes Drahtlos-Netzwerk (oder dessen Netzbetreiber-Infrastruktur) an einen Proxy/Router angeschlossen ist, der ebenfalls (über eine öffentliche Adresse) mit einem öffentlichen Netzwerk verbunden ist. Wengleich zudem ein öffentliches Netzwerk hier mitunter auch als verdrahtetes Netzwerk bezeichnet wird, liegt es für Fachleute auf der Hand, dass jedes Netzwerk mit routable (öffentlichen) Adressen impliziert sein kann. Folglich kann auch ein Drahtlos-Netzwerk mit einer eindeutigen öffentlichen (und routable) Adresse erfindungsgemäße Verfahren zum Ausführen der bidirektionalen Kommunikation nutzen. Ebenso ist es Fachleuten klar, dass Begriffe wie beispielsweise Drahtlos-Vorrichtung, Telefon, Taschencomputer, usw. austauschbar verwendet werden und jede Art Drahtlos-Vorrichtung angeben, die mit dem AMPS arbeiten kann. Weiterhin können Begriffe auch eine unterschiedliche Schreibweise haben oder explizit Erwähnung finden oder auch nicht, wobei Fachleute erkennen, dass all diese Varianten der Begriffe mit einbezogen sein sollen.
  • Die hier beschriebenen Beispiel-Ausführungsformen stellen Anwendungen, Tools, Datenstrukturen und andere Unterstützungseinrichtungen da, mit denen Abbildungen privater Adressen über eines oder mehrere verdrahtete oder Drahtlos-Netzwerke für die bidirektionale Kommunikation auf öffentliche Adressen implementiert werden. Weiterhin ist es Fachleuten klar, dass andere Ausführungsformen der erfindungsgemäßen Verfahren und Systeme für viele weitere Zwecke zum Einsatz kommen können, wozu auch das Verschieben von Informationen und/oder Daten oder Codes von einem öffentlichen Netzwerk wie dem Internet zu einer Drahtlos-Vorrichtung gehört. Obwohl sich diese Beschreibung vorrangig auf "Daten" bezieht, die über die Netzwerke versendet werden, liegt es für Fachleute außerdem auf der Hand, das sämtliche Datenarten mit Hilfe der hier beschriebenen Verfahren übertragen werden können, unter anderem Text, Grafiken, Audio- und Videoelemente.
  • In der nachfolgenden Beschreibung sind zahlreiche spezielle Details angegeben, z. B. Datenformate und Codesequenzen, usw., die ein tief greifendes Verständnis der erfin dungsgemäßen Verfahren und Systeme bieten sollen. Natürlich wissen Fachleute, dass die vorliegende Erfindung auch ohne einige der beschriebenen speziellen Details oder mit anderen speziellen Details, z. B. Änderungen in der Reihenfolge des Code-Flusses, in die Praxis umgesetzt werden können.
  • 4 ist ein Beispiel-Blockdiagramm eines allgemeinen Computersystems für die Umsetzung von Ausführungsformen des Adressverwaltungs-Proxysystems. Das allgemeine Computersystem 400 kann einen oder mehrere Server- und/oder Client-Computersysteme umfassen, die verschiedene Standorte überspannen. Weiterhin kann jeder Block einen oder mehrere solche Blöcke repräsentieren, wenn dies für eine spezielle Ausführungsform angemessen ist, oder mit anderen Blöcken kombiniert werden. Die einzelnen Blöcke des Adressverwaltungs-Proxysystems 410 können sich physisch auf einer oder mehreren Maschinen befinden, die zum Kommunizieren miteinander standardmäßige Interprozess-Kommunikationsmechanismen anwenden. Bei der abgebildeten Ausführungsform umfasst das Computersystem 400 einen Computerspeicher („Speicher") 401, eine Anzeige 402, eine zentrale Verarbeitungseinheit („CPU") 403 sowie Eingabe-/Ausgabevorrichtungen 404. In der Abbildung ist das Adressverwaltungs-Proxysystem 410 im Speicher 401 untergebracht. Die Komponenten des Adressverwaltungs-Proxysystem 410 laufen vorzugsweise auf der CPU 403 und verwalten die Adressabbildung von Drahtlos-Vorrichtungen in einem Drahtlos-Netzwerk, wie in den vorigen Figu- ren beschrieben, damit andere verdrahtete Systeme mit den Drahtlos-Vorrichtungen kommunizieren können. In dem Speicher 410 befinden sich außerdem weitere herunter geladene Codes 405 und möglicherweise weitere Daten-Repositories, die vorzugsweise auf einem oder mehreren CPUs 403 laufen. Bei einer typischen Ausführungsform enthält das AMPS 410 einen oder mehrere DNS'/API-Server 411, einen oder mehrere Adress-Proxy/Router 412, einen Adressverwaltungs-Datenserver 413 und Adressverwaltungs-Daten-Repositories 414. Wie bereits zuvor beschrieben, kann das AMPS je nach der speziellen Implementierung auch weitere Daten-Repositories und Komponenten enthalten, z. B. eine Lastenausgleichseinrichtung.
  • Bei einer Beispiel-Ausführungsform werden die Komponenten des AMPS 410 durch Modifizierung einer vorhandenen UDP-basierten Technologie z. B. als DNS-Server und Router implementiert, die im typischen Fall auf Linux/Unix-Systemen implementiert sind, die in der C-Programmiersprache geschrieben sind. Programmierschnittstellen zu den DNS'/API-Servern 411 und Adress-Proxys/Routern 412 können standardmäßig z. B. über C, C++, C# und Java API sowie durch Datenschreibsprachen, z. B. XML, oder über Web-Server zur Verfügung gestellt werden, welche diese unterstützen. Zwecks Skalier barkeit sind Adressverwaltungs-Datenserver 413 und die Adressverwaltungs-Daten-Repositories 414 vorzugsweise als Datenbanksystem implementiert und nicht als eine Textdatei, und können mit Hilfe eines SQL-ODBC-Datenbankverwaltungssystems implementiert werden. Die DNS'/API-Server 411 und Adress-Proxys/Router 412 werden typischerweise mit Hilfe von Linux, UNIX oder anderen Unix-basierten oder Unix-artigen Menschen implementiert.
  • Fachleute erkennen, dass das AMPS 410 in einer verteilten Umgebung implementiert sein kann, die aus mehreren, sogar heterogenen Computersystemen und Netzwerken bestehen kann. Z. B. befinden sich bei einer Ausführungsform die DNS'/API-Server 411, die Adress-Proxy/Router-Komponenten 412 und die Adressverwaltungs-Datenserver 413 mit ihren Daten-Repositories 414 sämtlich in physisch unterschiedlichen Computersystemen. Bei einer anderen Ausführungsform sind verschiedene Komponenten des AMPS 410 jeweils auf einer separaten Servermaschine untergebracht und können entfernt von den Tabellen angeordnet sein, die in dem Adressverwaltungs-Daten-Repository 414 gespeichert sind. Darüber hinaus kann unter bestimmten Bedingungen das gesamte AMPS-System 410 innerhalb einer Netzbetreiber-Infrastruktur enthalten und vollständig darin eingeschlossen sein. Für die Anwendung der erfindungsgemäßen Verfahren sind unterschiedliche Konfigurationen und Anordnungen von Programmen und Daten denkbar. Bei Beispiel-Ausführungsformen können diese Komponenten gleichzeitig oder asynchron laufen, folglich können die Komponenten mit Hilfe hinlänglich bekannter Nachrichten-Weiterleitungsverfahren miteinander kommunizieren. Fachleute erkennen ebenfalls, dass äquivalente Synchronausführungen ebenfalls von einer AMPS-Implementierung unterstützt werden. Weiterhin könnten auch andere Schritte für jede Routine implementiert werden und auch in anderer Reihenfolge und in anderen Routinen, solange die Funktionen des AMPS erfüllt werden.
  • Für die Komponenten des Adressverwaltungs-Proxysystems gibt es verschiedene Implementierungsansätze, von denen hier drei beschrieben werden. Fachleuten ist klar, dass auch verschiedene andere Ansätze und Kombinationen möglich sind. Alle drei Ansätze ordnen für die temporäre Nutzung durch eine verdrahtete Vorrichtung für die Kommunikation mit einer Drahtlos-Vorrichtung eine öffentliche (routable) Netzwerdadresse zu. Bei einer Ausführungsform wird ein Pool öffentlicher Adressen, z. B. öffentliche IP-Adressen, gepflegt und den Vorrichtungen des Drahtlos-Netzwerks nach Bedarf dynamisch zugeordnet. Z. B. ermöglicht ein typischer Internet-Netzwerkadressenblock der Klasse B etwa 65000 gleichzeitige Verbindungen zu Drahtlos-Vorrichtungen. Wenngleich diese Anzahl auf den ersten Blick groß erscheint, so ist sie dennoch recht begrenzt, wenn man bedenkt, wie viele Handy und tragbare Geräte es gibt, die mit einem Netzbetreiber verbunden sind.
  • Die erste Herangehensweise schafft die Abbildung einer öffentlichen Adresse für eine Drahtlos-Vorrichtung und stellt sie mit Hilfe eines UDP-Protokolls zur Verfügung. Hierbei handelt es sich um einen Speicher-Weiterleitungs-Ansatz. Ein Vorteil dieses Ansatzes besteht darin, dass er den UDP-basierten Verkehr zu Drahtlos-Vorrichtungen über eine Drahtlos-Verbindung erleichtert und es einer an die öffentliche Seite der Verbindung angeschlossenen Vorrichtung ermöglicht, eine Verbindung herzustellen. Allerdings liegt ein Nachteil darin, dass entweder das standardmäßige UDP-Protokoll modifiziert werden muss oder ein zusätzlicher API-Anruf hinzugefügt wird, damit die anfordernde Vorrichtung die gewünschte Drahtlos-Vorrichtung identifizieren kann. Diese Modifizierungen sind notwendig, da das UDP-Protokoll lediglich die Bezeichnung einer IP-Adresse unterstützt und keine alternative Einrichtung für das eindeutige Identifizieren einer Vorrichtung bietet (wie z. B. ein String wie bei dem TCP/IP-Protokoll). Da es wünschenswert ist, diese (private) Adresse zu verbergen, reicht der standardmäßige UDP-Anruf zum Senden der Daten nicht aus.
  • Der zweite Ansatz zum Implementieren des AMPS unterstützt die vollständige bidirektionale Kommunikation über Punkt-Zu-Punkt-Verbindungen, die z. B. mit Hilfe des TCP/IP-Protokolls aufgebaut werden. (Es ist anzumerken, dass die gleichen Verfahren ebenfalls verbindungslose direktionale UDP-Kommunikationen unterstützen.) Der zweite Ansatz kann durch Schaffung einer modifizierten Implementierung einer standardmäßigen UDP- oder TCP/IP-Funktion implementiert werden, „GetHostByName". Die GetHostByName-API ermöglicht es einer String-Bezeichnung, die angegebene Vorrichtung zu identifizieren, und gibt eine IP-Adressdatenstruktur aus. Als Alternative dazu kann das AMPS zum Erhöhen des Sicherheitsniveaus eine spezielle API implementieren, um die dynamisch zugeordnete öffentliche Adresse zurückzugeben, die (jetzt) der angeforderten Drahtlos-Vorrichtung entspricht. Ein Nachteil dieses speziellen API-Ansatzes besteht darin, dass die Vorrichtung am öffentlichen Netzwerk (oder eine andere Vorrichtung, die eine Verbindung mit der Drahtlos-Vorrichtung erzielen möchte) einen speziellen Code in der Anwendung auf der anfordernden Vorrichtung aufweisen muss.
  • Die dritte Herangehensweise ist der zweiten ähnlich, ermöglicht jedoch mit Hilfe eines „Port"-Konzepts mehr gleichzeitig mögliche Verbindungen. Bei diesem Ansatz gibt das AMPS nicht nur eine Host-Adresse auf dem verdrahteten Netzwerk zurück, die der Drahtlos-Vorrichtung entspricht (eine öffentliche Adresse eines Adress-Proxys/Routers), sondern auch eine spezielle Port-Bezeichnung an der Host-Maschine (Adress- Proxy/Router). Ports und deren Implementierung sind auf dem Fachgebiet hinlänglich bekannt und entsprechen im Allgemeinen Warteschlangen, die von der Maschine implementiert werden, welche die Daten empfängt, um die für die verschiedenen Orte vorgesehenen Nachrichten zu verfolgen. Die Maschinen, die die Daten empfangen, leiten die Nachrichten ausgehend von den Port-Bezeichnungen in der Nachricht zu den verschiedenen Zielen weiter und wickeln auf Port-Basis die Folgeverarbeitung und das Handshaking ab.
  • Ports werden meist dazu verwendet, mehrere virtuelle Kanäle an einer einzigen physikalischen Adresse zu öffnen und potenziell eine einzige physikalische Adresse für weitere etwas 65000 Verbindungen zu erweitern. Dadurch wird es einem AMPS ermöglicht, beispielsweise IP-Adressen der Klasse C zu verwenden, die im typischen Fall viel kostengünstiger und leichter zu erhalten sind als andere Arten von Adressen, um etwa 16 Millionen gleichzeitige Verbindungen zu Drahtlos-Vorrichtungen (mit Hilfe eines UNIX-basierten Systems) zu erreichen. Für Fachleute liegt es auf der Hand, dass die Anzahl der verfügbaren Ports und deren jeweilige Implementierung von dem Betriebssystem abhängig ist und in direkter Korrelation zu der Anzahl der Bits steht, die eine Port-Adresse angeben.
  • Das UDP- (genauso wie das TCP/IP)-Protokoll unterstützt gegenwärtig eine Port-Abstraktion; allerdings gestattet die standardmäßige DNS-Abfrage, die bei UDP- und TCP/IP-Systemen (z. B. GetHostByName) zur Anwendung kommt, nicht die Rückmeldung einer Port-Bezeichnung und überlässt die Steuerung der Port-Bezeichnung der anfordernden Vorrichtung und nicht dem empfangenden Router. Folglich werden entsprechend dem dritten Ansatz zum Implementieren des AMPS Ports vorzugsweise von dem Adress-Proxy/Router mit Hilfe einer speziellen API angegeben und mit der Bezeichnung der Host-Maschine an die anfordernde Vorrichtung zurückgegeben.
  • Bei einer Ausführungsform kann eine Schreibsprachenschnittstelle, z. B. XML, anstelle einer speziellen API (Code-Schnittstelle) verwendet werden, um eine Schnittstelle zu einer speziellen Adress-Abbildungsfunktion zu bilden. Bei Verwendung des XML akzeptiert der DNS'/API-Server API-Anrufe als XML-Sendevorgänge und gibt formatierte SML-Antworten zurück. Ähnliche Unterstützung zum Aufrufen dieser Abbildungsfunktion mit Hilfe anderer Sprachmodelle und/oder anderer Programmiersprachen ist ebenfalls denkbar und funktioniert mit dem erfindungsgemäßen Verfahren. Eine XML-Schnittstelle minimiert die Kosten für die Integration einer API in die Software der anfordernden Vorrichtung.
  • Bei Verwendung einer speziellen API kann die anfordernde Vorrichtung darüber hinaus zusätzliche Daten zu der privaten Drahtlos-Vorrichtung verschieben, ohne dass dazu weitere Codieranstrengungen erforderlich sind. Z. B. kann ein Abrechnungscode, der auf die Abrechnung der Drahtlos-Vorrichtung für die Art der Verbindung ausgerichtet ist, die mit der verdrahteten Vorrichtung hergestellt wird, mit Hilfe dieses Verfahrens zu der Drahtlos-Vorrichtung verschoben werden. Ein Beispiel für einen Abrechnungscode-Mechanismus ist in der US-Patentanmeldung Nr. 10/085,981 mit dem Titel „Method and System for Transmission-Based Billing of Applications" mit Einreichungsdatum vom 26.02.2002 erörtert.
  • Es gibt zahlreiche Sicherheitsgründe, die ebenfalls das Versenden einer speziellen API anstelle der standardmäßigen GetHostByName-API des UDP- und TCP/IP-Protokolls nahe legen. Zu diesen Sicherheitsgründen kann der Wunsch gehören, den portbasierten Mechanismus zu verwenden, der ebenfalls eine spezielle API benötigt. Zuerst einmal ist jede bidirektionale Kommunikation, die die „GetHostByName"-API und ein Router-Protokoll verwendet, anfällig für die Dienstverweigerungsattacken (Denial of Service Attacks – DOS), die mit jenem Host-Namen verknüpft sind. DOS-Attacken können auftreten, wenn eine oder mehrere Maschinen gleichzeitig denselben GetHostByName mit demselben Eingabeparameter angeben, wodurch ausgeschlossen wird, dass genug öffentliche Adressen (Adressen von Proxy/Router-Maschinen) zur Verfügung stehen. Zweitens macht die Verwendung der GetHostByName- (oder jeder anderen standardmäßigen) API das AMPS ebenfalls anfällig für Sicherheitsattacken im Ergebnis einer DNS-Zonenübertragung. Eine DNS-Zonenübertragung findet beispielsweise statt, wenn ein DNS eine DNS-Abfrage an einen oder mehrere andere DNS-Server überträgt, um den angeforderten Host-Namen zu finden. Ein typisches Szenario umfasst mehrere DNS-Sprünge von Land zu Land. Die Idee hinter DNS-Zonenserverattacken besteht darin, Informationen auf einem speziellen DNS-Server zu erfassen, indem ein bösartiger Code als bösartiger DNS-Server eingefügt und die Zieladresse simuliert wird. Und Drittens kann auch die Unaufmerksamkeit im Hinblick auf die Dauer einer Verbindung Daten für nicht berechtigte Anforderungs-Vorrichtungen verfügbar machen. Da eine Abbildung zwischen der öffentlichen Vorrichtung und einer Drahtlos-Vorrichtung hergestellt wird, kann speziell die öffentliche Vorrichtung annehmen, dass die Abbildung nicht weiter besteht, und tatsächlich oder potenziell (böswillig oder nicht) mit der falschen Vorrichtung kommunizieren. Dies würde erfolgen, da einige DNS-Serverimplementierungen „Time-to-Live"-Einstellungen ignorieren. Mit einer modifizierten DNS-Serverimplementierung, ob nun die standardmäßige GetHostByName-API oder eine spezielle API, wird dieses Prob lem verhindert, indem an den TTL-Eigenschaften der hergestellten Abbildung zwischen der privaten und öffentlichen Adresse festgehalten wird.
  • Die 5–8 beschreiben verschiedene Beispiel-Ausführungsformen der speziellen Routinen, die von den DNS'/API-Servern und den Adress-Proxys/Routern implementiert werden, um die anhand der 2 und 3 beschriebene Funktionalität zu erreichen. 5 ist ein Beispiel-Flussdiagramm des Prozesses, der von einer Vorrichtung in einem öffentlichen Netzwerk ausgeführt wird, um mit Hilfe des Adressverwaltungs-Proxysystems Daten zu einer Drahtlos-Vorrichtung in einem privaten Drahtlos-Netzwerk zu senden. In Schritt 501 fordert die Quellen-Vorrichtung (z. B. verdrahtete Vorrichtung) eine öffentliche (routable) Adresse für die festgelegte Drahtlos-Vorrichtung von dem AMPS an. Wie oben beschrieben, besteht ein Mechanismus zum Abrufen einer solchen Adresse darin, dass das AMPS eine modifizierte Schnittstelle für DNS-Dienste implementiert, z. B. als eine modifizierte GetHostByName-Routine. Z. B. kann eine GetHostByName-Routine aufgerufen werden, um eine eindeutige Bezeichnung für eine Drahtlos-Vorrichtung in Form eines Strings anzugeben. Der String „personname.phone.wsp.com" ist ein Beispiel-String, der eine Drahtlos-Vorrichtung angibt, die einer Person mit dem Namen „person" entspricht, welche eine Telefonnummer „phone" hat und sich auf der Webseite eines Drahtlos-Service-Providers (DNS) mit der Abkürzung „wsp.com" befindet. (Z. B. kann sich susan.ph.2065551212.sprint.com auf eine Person, Susan, mit der Telefonnummer 2065551212 auf einem Netzwerk Sprint beziehen.) Ein anderer Mechanismus, der von dem AMPS implementiert werden kann, besteht in der Bereitstellung einer separaten (speziellen) API, z. B. „GetProxyIP", die einen Hinweis auf eine öffentliche (routable) Adresse zurückgibt, welche der angegebenen Drahtlos-Vorrichtung entspricht. Die Verwendung einer separaten API ist aus Sicherheitsgründen sinnvoll. Z. B. wird es schwieriger für eine kriminelle Vorrichtung, die routable Adresse durch Spoofing abzufangen. Ein weiterer Grund besteht darin, das tatsächliche Format der zurückgegebenen Adressinformationen zu steuern, um beispielsweise in der Lage zu sein, eine Port-Bezeichnung zusätzlich zu einer Host-Adresse des Adress-Proxys/Routers zur Verfügung zu stellen. Die Implementierung sowohl einer GetHostByName-API oder einer speziellen API, z. B. GetProxyIP, wird nachstehend anhand von 7 näher erläutert.
  • In Schritt 502 extrahiert die Quellenvorrichtung, nachdem die öffentliche für die Drahtlos-Vorrichtung von dem AMPS zurückgeführt wurde, aus den angegebenen Adressinformationen eine aktuelle Adressenangabe (IPdata.ip), einen Time-to-Live-Parameter (IPdata.TTL) und wahlweise gegebenenfalls eine Port-Kennzeichnung (IPdata.port), z. B. wenn die standardmäßige GetHostByName-API nicht verwendet wird. Wenn die Quel lenvorrichtung eine verbindungsbasierte Datenübertragung mit der Drahtlos-Vorrichtung ausführen will, öffnet sie in Schritt 503 eine Verbindung, z. B. über einen Steckdosenanschluss. In Schritt 504 stellt die verdrahtete Vorrichtung fest, ob der Time-to-Live-Parameter angibt, dass die zurückgegebene öffentliche Adresse der Drahtlos-Vorrichtung ungültig geworden ist, und falls dies der Fall ist, kehrt sie zu Schritt 501 zurück, um eine andere Adresse anzufordern, ansonsten geht sie weiter zu Schritt 505. Der Time-to-Live-Parameter wird von dem AMP verwendet um sicherzustellen, dass eine öffentliche Adresse für eine Drahtlos-Vorrichtung (die entweder ständig an das Drahtlos-Netzwerk angeschlossen und eingeschaltet ist oder nicht) nicht über eine Periode hinaus reicht, die für jene Drahtlos-Vorrichtung sinnvoll wäre. Bei einigen Ausführungsformen wird ein sehr kurzer TTL-Parameter verwendet, um Sicherheitsverstöße zu verhindern, bei denen eine verdrahtete Vorrichtung imstande ist, die Aktivität an einer speziellen öffentlichen Adresse zu überwachen und diese Adresse anschließend für andere Zwecke zu nutzen. In Schritt 505 sendet die verdrahtete Vorrichtung ein Datenpaket (über eine Verbindung oder nicht) zu der Drahtlos-Vorrichtung. Es wird davon ausgegangen, jedoch nicht dargestellt, dass die verdrahtete Vorrichtung und die Drahtlos-Vorrichtung mit Hilfe der standardmäßigen Anrufe kommunizieren, die in dem verwendeten Übertragungsprotokoll angegeben sind, z. B. UDP oder TCP/IP. Wenn die Datenübertragung abgeschlossen ist, ist die verdrahtete Vorrichtung dann in Schritt 506 fertig, ansonsten kehrt sie zwecks Überprüfung des TTL-Parameters zu Schritt 504 zurück, um weitere Daten zu senden. Die nachstehende Tabelle 1 enthält einen Pseudo-Code, der mit Hilfe eines Beispiels für eine Implementierung beschreibt, wie eine öffentliche (Anforderer-)Vorrichtung eine modifizierte GetHostByName-Abfrage wie in 5 nutzen kann, um eine öffentliche Adresse zu erhalten, die einem Nutzer entspricht, der mit Hilfe des Adressverwaltungs-Proxysystems unter der Telefonnummer „2065551212" identifiziert worden ist. Aus der Sicht der öffentlichen Vorrichtung werden standardmäßige UDP- und TCP/IP-Anrufer standardmäßig aufgerufen.
  • TABELLE 1
    Figure 00210001
  • Die unten stehende Tabelle 2 enthält einen Pseudo-Code, der eine Beispiel-Implementierung eines speziellen Apis-Mechanismus aus 5 beschreibt, welcher von einer öffentlichen (Anforderer)-Vorrichtung zum Erhalt einer öffentlichen Adresse eines Nutzers verwendet wird, der über die gleiche Telefonnummer identifiziert wird. In Tabelle 2 ruft die öffentliche Vorrichtung eine spezielle API, GetProxyIP an, um eine Datenstruktur zu erhalten, die die benötigten Informationen einschließlich der zugeordneten öffentlichen Adresse des Adress-Proxys/Servers enthält. Anschließend kann die öffentliche Vorrichtung die gleichen Verfahren (standardmäßiges UDP- oder TCP/IP-Protokoll) zum Versenden der Daten anwenden.
  • TABELLE 2
    Figure 00210002
  • Figure 00220001
  • 6 ist ein Beispiel-Blockdiagramm einiger Daten-Repository-Tabellen des Adressverwaltungs-Proxysystems, die zur Unterstützung von Routinen der DNS'/API-Server und der Adress-Proxys/Router verwendet werden. Bei einer Ausführungsform umfasst das Adressverwaltungs-Daten-Repository drei Tabellen: eine Tabelle 610 für eindeutige Kennungen (eindeutige ID) für private Adressen, eine Tabelle 630 für öffentlich-private Adressen und eine Tabelle 620 für eine öffentliche Adresse zu einer Proxy/Router-Maschine. Wenngleich drei Tabellen abgebildet sind, erkennen Fachleute, dass diese Tabellen auch andere Daten enthalten und anders aufgebaut sein könnten, dazu gehört auch eine andere Anzahl von Tabellen mit anderen Spalten oder Feldern. Darüber hinaus kann jedes beliebige Verfahren zum Speichern einer Tabelle oder Datenliste verwendet werden. Zum Unterstützen von Ausführungsformen, die eine Host-Adresse plus einen Port-Bezeichner für eine Drahtlos-Vorrichtung abbilden, werden die Tabellen entsprechend modifiziert.
  • Die eindeutige ID-Tabelle 610 bildet eindeutige String-Namen von Drahtlos-Vorrichtungen zu privaten Drahtlos-Netzwerkadressen ab, die im typischen Fall von der Infrastruktur eines Netzbetreibers zugeordnet wurden. In einigen Ausführungsformen ordnet die Netzbetreiber-Infrastruktur mit Hilfe von Verfahren, die einem DHCP-Protokoll ähnlich sind, dynamisch private Drahtlos-Netzwerkadressen zu, wenn sich die Drahtlos-Vorrichtung nach dem Einschalten selbst bei der Netzbetreiber-Infrastruktur registriert. Somit kann die Tabelle 610 der eindeutigen IDs nur mäßig gefüllt werden bzw. Einträge werden dynamisch erzeugt und anschließend dynamisch gelöscht, wenn sich Vorrichtungen bei dem System der Netzbetreiber-Infrastruktur anmelden und abmelden.
  • Die Tabelle 630 der öffentlich-privaten Adressen umfasst mehrere Felder/Spalten, unter anderem für eine öffentliche Netzwerkadresse 631, eine private (Drahtlos)-Netzwerkadresse 602, ein Flag 632, das angibt, ob die in dem Feld 631 gespeicherte öffentliche Adresse frei ist oder bereits genutzt wird, einen Time-to-Live(TTL)-Parameter 633 und andere Verbindungsdaten 634. Bei einer Ausführungsform fragen die DNS'/API-Server des AMPS die Tabelle 630 ab, um eine öffentliche Netzwerkadresse zu ermitteln, die einer bestimmten privaten Drahtlos-Netzwerkadresse entspricht, oder um eine ungenutzte öffentliche Netzwerkadresse (wie im Feld 632 angegeben) zuzuordnen und die ermittelte ungenutzte öffentliche Adresse auf eine private Netzwerkadresse abzubilden, die im Feld 602 gespeichert ist.
  • Die Tabelle 620 der öffentlichen Adressen zu der Proxy/Router-Maschine umfasst ein öffentliches Netzwerk-Adressfeld 631 und einen Hinweis auf eine funktionierende Proxy/Router-Maschine 621. Durch eine solche Abbildung ist das AMPS in der Lage, Proxy/Router-Maschinen durch andere Proxy/Router-Maschinen zu ersetzen und so eine größere Robustheit zu gewährleisten. Jede Proxy/Router-Maschine hat einen vorkonfigurierten Satz öffentlicher Netzwerkadressen, die meist von Netzwerkkarten konfiguriert werden, die in die Proxy/Router-Maschine eingesetzt werden. Diese Adressen werden standardmäßig beim vorherigen Kauf zugeordnet oder von einer Adressgenehmigungsbehörde erteilt, gegenwärtig ist dies die Internet Corporation for Assigned Names and Numbers (ICANN). Wenn eine Maschine zur Verwendung in das AMPS eingefügt wird, werden die Hinweise auf diese Adressen in dem Feld 631 gespeichert.
  • Bei einer Ausführungsform wird in Tabelle 630 weiterhin ein Zeitstempel des Abbildens zwischen einer öffentlichen Netzwerkadresse und einer privaten Adresse vermerkt. Nachdem ausgehend von diesem Zeitstempel eine bestimmte Frist abgelaufen ist, sendet der Adressverwaltungs-Datenserver eine Anforderung an den Adress-Proxy/Router, der mit diesem Abbildungsvorgang verknüpft ist, um die Abbildung der öffentlich-privaten Adresse rückgängig zu machen, und aktualisiert die Abbildungstabelle 630, wodurch die dazugehörige öffentliche Adresse an den Pool ungenutzter öffentlicher Netzwerkadressen zurückgegeben wird.
  • 7 ist ein Beispiel-Flussdiagramm einer Beispiel-Routine, die von einem DNS'/API-Server des Adressverwaltungs-Proxysystems bereitgestellt wird, um eine öffentliche Adresse zurückzugeben, die einer bestimmten eindeutigen Kennung entspricht. Im Grunde implementiert diese Routine eine DNS-Abfrage oder eine DNS-artige Abfragefunktionali tät für das AMPS mit Hilfe einer modifizierten GetHostByName-Schnittstelle oder einer speziellen API, z. B. GetProxyIP, die anhand von 5 beschrieben wurde. Zusammenfassend lässt sich sagen, dass die Routine dynamisch eine geeignete Adress-Proxy/Router-Maschine zuordnet, die mit der Drahtlos-Vorrichtung verknüpft ist, und die öffentliche Adresse jener Maschine (zusammen mit einem TTL-Parameter und potenziell weiteren Parametern) zurückgibt. Speziell in Schritt 701 ermittelt die Routine die private (non-routable) Adresse der Drahtlos-Vorrichtung, die von einem String-Parameter gekennzeichnet ist, der als Eingabe in die Routine gelangt. Z. B. kann der String-Parameter Felder verwenden, wie beispielsweise „uniquelD.hostname.domain.tld", das eine typische Person/Dienst-Hierarchie in einer Maschine angibt, die den Namen „hostname" auf einer Domain, z. B. einem Computernetzwerk auf der obersten Domain, z. B. „org", „com", „edu", usw. Für Fachleute liegt es auf der Hand, dass auch viele andere String-Parameter-Bezeichnungen verwendet werden könnten. Ein Mechanismus zum Implementieren dieser Routine besteht in der Abfrage von Informationen aus dem Adressverwaltungs-Daten-Repository. Bei einer Ausführungsform speichert das Daten-Repository eine Tabelle, die eindeutige IDs auf private Netzwerkadressen abbildet (siehe Tabelle 610 aus 6). Vorzugsweise speichert jener Mechanismus, der von dem AMPS-System zum Einsatz gebracht wird, diese Daten sicher, um die Adressen des Drahtlos-Netzwerks geheim zu halten. In Schritt 702 fragt die Routine die Adresse des öffentlichen Netzwerks ab, die der Adresse des privaten Drahtlos-Netzwerks der bestimmten Vorrichtung entspricht, falls dieser Vorrichtung von dem AMPS bereits eine zugeordnet wurde und noch gültig ist. Bei einer Ausführungsform speichert das Daten-Repository diese Abbildungsinformationen zwischen dem privaten Drahtlos-Netzwerk und der Adresse des öffentlichen Netzwerks (siehe z. B. Tabelle 630 in 6). Wenn noch keine öffentliche Netzwerkadresse zugeordnet worden oder keine gültige vorhanden ist, veranlasst die Routine, dass eine neue öffentliche Netzwerkadresse zugeordnet und die neue öffentliche Adresse mit der Adresse des privaten Drahtlos-Netzwerks verknüpft wird. Anschließend werden die entsprechenden Tabellen in dem Daten-Repository aktualisiert. In Schritt 703 ermittelt die Routine die Adress-Proxy/Router-Maschine, die mit der zugeordneten öffentlichen Netzwerkadresse verknüpft ist (z. B. mit Hilfe der Tabelle 620 in 6). In Schritt 704 sendet die Routine eine Anforderung an die ermittelte Proxy/Router-Maschine, die Routing-Tabellen zu aktualisieren, um die ermittelte Netzwerkadresse auf die private Drahtlos-Netzwerkadresse abzubilden. In Schritt 705 aktualisiert die Routine die Informationen in dem Daten-Repository und schließt alle weiteren verbindungsbezogenen Informationen ein (z. B. Feld 634 in Tabelle 630 aus 6) und gibt einen Time- to-Live(TTL)-Parameter für die Verknüpfung der öffentlichen mit der privaten Adresse an (z. B. Feld 633 in Tabelle 630 aus 6). Nachdem sämtliche Tabellen sowohl im Proxy/Router als auch im Daten-Repository aktualisiert worden sind, gibt der DNS'/API-Server die ermittelte öffentliche Netzwerkadresse der verknüpften Adress-Proxy/Router-Maschine zurück. Wie bereits beschrieben, kann es sich bei der öffentlichen Adresse um ein Paar (Host-Name, Port) handeln, wenn eine portbasierte Implementierung zum Einsatz kommt.
  • 8 ist ein Beispiel-Flussdiagramm einer Beispiel-Routine innerhalb eines Adress-Proxys/Routers eines Beispiel-Adressverwaltungs-Proxysystems, welches Daten empfängt. Diese Routine wird in einem Adress-Proxy/Router implementiert, so dass Daten mit Hilfe der relevanten Protokolle (z. B. TCP/IP, UDP/IP, usw.) von den verdrahteten Vorrichtungen empfangen werden. (Daten werden zu einem speziellen Adress-Proxy/Router gesendet, da die öffentliche (routable) Adresse jenes Adress-Proxys/Routers als Reaktion auf eine Abfrage des DNS'/API-Servers des AMPS an die anfordernde/Quellen-Vorrichtung zurückgegeben wurde. Der Proxy/Router ist verantwortlich für alle Konvertierungen von Daten, die notwendig sind, um Daten von dem verdrahteten Netzwerk zu dem Drahtlos-Netzwerk zu senden (wenn beispielsweise die Netzbetreiber-Infrastruktur eine Konvertierung auf dieser Ebene wünscht). Der Proxy/Router ist ebenfalls verantwortlich für das Weiterleiten der Daten über das Drahtlos-Netzwerk zu der privaten Drahtlos-Adresse der Drahtlos-Vorrichtung, die der öffentlichen Adresse entspricht, die zum Aufrufen des Proxys/Routers verwendet wurde.
  • Konkret ermittelt die Routine in Schritt 801 (z. B. aus dem Adressverwaltungs-Daten-Repository) die private Drahtlos-Adresse, die der aufgerufenen öffentlichen Adresse und dem TTL-Parameter dieser Abbildung entspricht. Diese Werte können beispielsweise aus der Tabelle 630 der öffentlich-privaten Adresse aus 6 erhalten werden. In Schritt 802 stellt die Routine fest, ob der Wert des ermittelten TTL-Parameters angibt, dass die Abbildung bereits beendet ist, und falls dies der Fall ist, wird ein Fehler ausgegeben, ansonsten geht es weiter zu Schritt 803. In Schritt 803 bestimmt die Routine das von der Zielvorrichtung geforderte Format (das Drahtlos-Netzwerkformat). In Schritt 804 bestimmt die Routine, ob eine Protokoll-Konvertierung notwendig ist, und falls ja, geht sie weiter zu Schritt 805, ansonsten zu Schritt 806. Es sei angemerkt, dass die Protokoll-Konvertierung für eine spezielles Drahtlos-Netzwerk, z. B. das Konvertieren der Daten in ein „HTTP"-Paket mit Hilfe des Proxys/Routers erfolgen kann oder durch eine andere Komponente innerhalb der Netzbetreiber-Infrastruktur. Fachleuten ist klar, dass dieses Beispielschritte sind und dass verschiedene Formatierungen oder andere Protokollkon vertierungsroutinen je nach der speziellen Umgebung hinzugefügt oder weggelassen werden können. In Schritt 806 sendet die Adress-Proxy/Router-Routine das Datenpaket (das formatiert worden ist und dessen Protokoll gegebenenfalls konvertiert wurde) an die ermittelte verknüpfte private Adresse der Drahtlos-Vorrichtung und kehrt wieder zurück. Für Fachleute ist es offensichtlich, dass die hier erörterten Verfahren und Systeme zur Herstellung einer bidirektionalen Kommunikation auch auf andere Arten öffentlicher Netzwerke und Protokolle als das Internet, TCP/IP und UDP anwendbar sind oder sogar auf eine Vielzahl derartiger Netzwerke. Z. B. können Abbildungen privater Adressen auf öffentliche Adressen für ATM-Netzwerke geschaffen werden, um die Vorrichtungen in einem ATM-Netzwerk mit einer Drahtlos-Vorrichtung zu verbinden. Für Fachleute liegt es ebenfalls auf der Hand, dass die hier erörterten Verfahren und Systeme auf andere Protokolle, Kommunikationsmedien (optische, Kabel-, drahtlose, usw.) und Drahtlos-Vorrichtungen (z. B. Drahtlos-Handgeräte, elektronische Organizer, persönliche digitale Assistenten, tragbare E-Mail-Geräte, Spielgeräte, Pager, Navigationsvorrichtungen, z. B. GPS-Empfänger, usw.) anwendbar sind, genauso wie auf andere verdrahtete Vorrichtungen (Kiosks, Personalcomputer, Großrechner) und Drahtlos-Vorrichtungen mit verdrahteten Verbindungsfunktionen, z. B. Drahtlos-E-Mail- oder PDA-Vorrichtungen, die zum Synchronisieren an eine Docking-Station angeschlossen werden.

Claims (18)

  1. Verfahren zum Einsatz in einem Computer-Netzwerk (210), das mit einem Drahtlos-Kommunikationsnetzwerk (230) über ein Adressverwaltungs-Proxysystem (220) verbunden ist, wobei das Drahtlos-Kommunikationsnetzwerk dazu dient, eine Drahtlos-Vorrichtung (240), die eine mit ihr verknüpfte eindeutige Kennung (601) hat, mit dem Computer-Netzwerk über einen bidirektionalen Kommunikationskanal unter Verwendung einer privaten Netzwerkadresse (602) des Drahtlos-Kommunikationsnetzwerks zu verbinden, das Adressverwaltungs-Proxysystem (220) eine öffentliche Netzwerkadresse (631) des Computer-Netzwerks hat und das Computer-Netzwerk dazu dient, eine verdrahtete Vorrichtung (201, 202, 203) mit dem Drahtlos-Netzwerk unter Verwendung einer öffentlichen Netzwerkadresse (631) des Computer-Netzwerks zu verbinden, wobei es umfasst: gesteuert von der verdrahteten Vorrichtung (201, 202, 203), unter Verwendung der öffentlichen Netzwerkadresse (631) des Adressverwaltungs-Proxysystems (220), Senden (501) einer Anforderung einer Anzeige einer öffentlichen Netzwerkadresse (631) des Computer-Netzwerks zur Verwendungzur Kommunikation mit der Drahtlos-Vorrichtung an das Adressverwaltungs-Proxysystem, wobei die Anforderung die mit der Drahtlos-Vorrichtung (240) verknüpfte eindeutige Kennung (601) anzeigt; gesteuert von dem Adressverwaltungs-Proxysystem (220), Empfangen der Anforderung der Anzeige der öffentlichen Netzwerkadresse (631); dynamisches Bestimmen (702) einer öffentlichen Netzwerkadresse (631) aus einer Vielzahl verfügbarer öffentlicher Netzwerkadressen des Computer-Netzwerks (210); Verknüpfen (704) der bestimmten öffentlichen Netzwerkadresse (631) mit der privaten Netzwerkadresse (602) der Drahtlos-Vorrichtung (240), die der angezeigten eindeutigen Kennung (601) entspricht; und Weiterleiten (502) einer Anzeige der bestimmten öffentlichen Netzwerkadresse (631) zu der verdrahteten Vorrichtung; und gesteuert von der verdrahteten Vorrichtung (201, 202, 203), Empfangen (801) der angezeigten öffentlichen Netzwerkadresse (631); und Senden (806) von Daten zu der Drahtlos-Vorrichtung (240) unter Verwendung der anzeigten öffentlichen Netzwerkadresse (631), so dass die verdrahtete Vorrichtung (201, 202, 203) registriert, dass die verdrahtete Vorrichtung direkt mit der Drahtlos-Vorrichtung (240) kommuniziert; dadurch gekennzeichnet, dass die öffentliche Netzwerkadresse eine Angabe einer Adresse enthält, wobei die Adresse eine IP-Adresse und ein Port-Paar ist; wobei die angezeigte öffentliche Netzwerkadresse als Ergebnis einer Anforderung durch die verdrahtete Vorrichtung an eine spezialisierte Adresszuordnungsfunktion in dem Adressverwaltungs-Proxysystem des Computer-Netzwerks empfangen wird und die spezialisierte Adresszuordnungsfunktion einen modifizierten Domain Name Service (DNS) verwendet, der wenigstens dem UDP- oder dem TCP/IP-Standard entspricht.
  2. Verfahren nach Anspruch 1, das des Weiteren gesteuert von dem Adressverwaltungs-Proxysystem (220) umfasst: Empfangen der von der verdrahteten Vorrichtung (201, 202, 203) gesendeten Daten; Bestimmen der privaten Netzwerkadresse (602), die mit der angezeigten öffentlichen Netzwerkadresse (631) verknüpft ist; und Leiten (505) der Daten zu der privaten Netzwerkadresse über das Drahtlos-Kommunikationsnetzwerk so, dass dies für die verdrahtete Vorrichtung transparent ist.
  3. Verfahren nach Anspruch 1, wobei das Computer-Netzwerk (210) das Internet ist und jede öffentliche Netzwerkadresse entsprechend Adressier-Konventionen des Internet Protocol angegeben ist.
  4. Verfahren nach Anspruch 1, wobei das Computer-Netzwerk ein ATM-Netzwerk ist.
  5. Verfahren nach Anspruch 1, wobei die angezeigte öffentliche Netzwerkadresse (631) die öffentliche Netzwerkadresse des Adressverwaltungs-Proxysystems (220) ist, Daten, die von der verdrahteten Vorrichtung (201, 202, 203) gesendet werden, die eindeutige Kennung der Drahtlos-Vorrichtung (240) einschließen und das Adressverwaltungs-Proxysystem die Daten speichert und zu der Drahtlos-Vorrichtung weiterleiten, die mit der angezeigten eindeutigen Kennung identifiziert wird.
  6. Verfahren nach Anspruch 1, wobei die spezialisierte Adresszuordnungsfunktion eine angepasste API ist.
  7. Verfahren nach Anspruch 1, wobei die spezialisierte Adresszuordnungsfunktion eine XML-Schnittstelle unterstützt.
  8. Verfahren nach Anspruch 1, das des Weiteren umfasst: gesteuert von der Drahtlos-Vorrichtung Senden von Daten zu der verdrahteten Vorrichtung unter Verwendung der öffentlichen Netzwerkadresse der verdrahteten Vorrichtung (201, 202, 203), um so bidirektionale Kommunikation durchzuführen.
  9. Verfahren nach Anspruch 1, wobei eine virtuelle Ende-zu-Ende-Verbindung zwischen der verdrahteten Vorrichtung (201, 202, 203) und der Drahtlos-Vorrichtung (240) hergestellt wird.
  10. Verfahren nach Anspruch 1, das des Weiteren umfasst: Verknüpfen der bestimmten öffentlichen Netzwerkadresse (631) mit einer Ablaufperiode; und Zerstören der Verknüpfung zwischen der bestimmten öffentlichen Netzwerkadresse und der privaten Adresse der Drahtlos-Vorrichtung, wenn die Ablaufperiode abgelaufen ist.
  11. Verfahren nach Anspruch 1, wobei die Ablaufperiode als TTL (Time-to-Live)-Daten angegeben ist.
  12. Verfahren nach Anspruch 1, wobei die eindeutige Kennung wenigstens der Name und die Telefonnummer einer Person, eine MSISDN-Nummer oder eine IMSI-Nummer ist.
  13. Computerlesbares Speichermedium, das Befehle zum Steuern eines Prozessors in einem Computersystem zum Einrichten eines bidirektionalen Kommunikationskanals zwischen einer verdrahteten Vorrichtung, die mit einer Computer-Netzwerkumgebung unter Verwendung einer öffentlichen Netzwerkadresse (631) verbunden ist, und einer Drahtlos-Vorrichtung enthält, die mit einem Drahtlos-Kommunikationsnetzwerk verbunden ist und eine private Netzwerkadresse hat, um das Verfahren nach einem der Ansprüche 1–12 durchzuführen.
  14. Kommunikationsnetzwerk, das umfasst: eine Drahtlos-Vorrichtung (240), die mit einem Drahtlos-Kommunikationsnetzwerk unter Verwendung einer privaten Netzwerkadresse (602) des Drahtlos-Kommunikationsnetzwerks verbunden ist, wobei die Drahtlos-Vorrichtung eine mit ihr verknüpfte eindeutige Kennung (601) hat; eine verdrahtete Vorrichtung (201, 202, 203), die mit einem Computer-Netzwerk unter Verwendung einer öffentlichen Netzwerkadresse (631) des Computer-Netzwerks verbunden ist, das so strukturiert ist, dass es eine Anzeige einer öffentlichen Netzwerkadresse (631) des Computer-Netzwerks zur Verwendung zur Kommunikation mit der Drahtlos-Vorrichtung (240) anfordert, wobei die Anforderung die mit der Drahtlos-Vorrichtung verknüpfte eindeutige Kennung anzeigt, die angezeigte öffentliche Netzwerkadresse (631) empfängt, und Daten unter Verwendung der öffentlichen Netzwerkadresse (631) zu der Drahtlos-Vorrichtung (240) sendet, so dass die verdrahtete Vorrichtung mittels eines bidirektionalen Kommunikationskanals unter Verwendung einer virtuellen Ende-zu-Ende-Verbindung direkt mit der Drahtlos-Vorrichtung kommuniziert; und ein Adressverwaltungs-Proxysystem (220), das mit dem Computer-Netzwerk unter Verwendung einer öffentlichen Netzwerkadresse des Computer-Netzwerks verbunden und so strukturiert ist, dass es: die Anforderung von der verdrahteten Vorrichtung (201, 202, 203) empfängt, dynamisch eine öffentliche Netzwerkadresse (631) aus einer Vielzahl verfügbarer öffentlicher Netzwerkadressen des Computer-Netzwerks bestimmt, die bestimmte öffentliche Netzwerkadresse (631) mit der privaten Netzwerkadresse (602) der Drahtlos-Vorrichtung (240) verknüpft, die der angezeigten eindeutigen Kennung (601) entspricht, und eine Anzeige der bestimmten öffentlichen Netzwerkadresse (631) zu der verdrahteten Vorrichtung weiterleitet, dadurch gekennzeichnet, dass die öffentliche Netzwerkadresse eine Angabe einer Adresse enthält, wobei die Adresse eine IP-Adresse und ein Port-Paar ist, wobei die angezeigte öffentliche Netzwerkadresse als Ergebnis einer Anforderung durch die verdrahtete Vorrichtung an eine spezialisierte Adresszuordnungsfunktion in dem Adressverwaltungs-Proxysystem des Computer-Netzwerks empfangen wird und die spezialisierte Adresszuordnungsfunktion einen modifizierten Domain Name Service (DNS) verwendet, der wenigstens dem UDP- oder dem TCP/IP-Standard entspricht.
  15. Verfahren in einem Computer-Netzwerk zum Kommunizieren mit einer Drahtlos-Vorrichtung (240), wobei das Computer-Netzwerk und die Drahtlos-Vorrichtung über ein Adressverwaltungs-Proxysystem (220) verbunden sind, um einen bidirektionalen Kommunikationskanal unter Verwendung einer privaten Netzwerkadresse (602) der Drahtlos-Vorrichtung einzurichten, die Drahtlos-Vorrichtung (240) eine mit ihr verknüpfte eindeutige Kennung (601) hat, die nicht die private Netzwerkadresse ist, und das Adressverwaltungs-Proxysystem (220) mit dem Computer-Netzwerk unter Verwendung einer öffentlichen Netzwerkadresse (631) des Computer-Netzwerks verbunden ist, wobei es umfasst: Anfordern einer öffentlichen Netzwerkadresse (631), die der mit der Drahtlos-Vorrichtung (240) verknüpften eindeutigen Kennung (601) entspricht, von dem Adressverwaltungs-Proxysystem (220) durch eine Drahtlos-Vorrichtung; Empfangen einer Anzeige der öffentlichen Netzwerkadresse (631) der Drahtlos-Vorrichtung; und Senden von Daten zu der angezeigten öffentlichen Netzwerkadresse (631), dadurch gekennzeichnet, dass die öffentliche Netzwerkadresse eine Angabe einer Adresse enthält, wobei die Adresse eine IP-Adresse und ein Port-Paar ist, wobei die angezeigte öffentliche Netzwerkadresse als Ergebnis der Anforderung durch die verdrahtete Vorrichtung an eine spezialisierte Adresszuordnungsfunktion in dem Adressverwaltungs-Proxysystem des Computer-Netzwerks empfangen wird und die spezialisierte Adress-Mapping-Funktion einen modifizierten Domain Name Service (DNS) verwendet, der wenigstens dem UDP- oder dem TCP/IP-Standard entspricht.
  16. Computerlesbares Speichermedium, das Befehle zum Durchführen des Verfahrens nach Anspruch 15 enthält.
  17. Verdrahtete Vorrichtung (201, 202, 203), die mit einem Computer-Netzwerk unter Verwendung einer öffentlichen Netzwerkadresse (631) des Computer-Netzwerks verbunden ist, wobei das Computer-Netzwerk unter Verwendung einer öffentlichen Netzwerkadresse (631) des Computer-Netzwerks mit einem Adressverwaltungs-Proxysystem (220) verbunden ist, das Adressverwaltungs-Proxysystem (220) dazu dient, eine Drahtlos-Vorrichtung (240) unter Verwendung einer privaten Netzwerkadresse (602) mit dem Computer-Netzwerk zu verbinden und die Drahtlos-Vorrichtung (240) eine mit ihr verknüpfte eindeutige Kennung (601) hat, die nicht die private Netzwerkadresse ist, wobei sie umfasst: ein Kommunikationscode-Modul, das so strukturiert ist, dass es von dem Adressverwaltungs-Proxysystem (220) unter Verwendung einer privaten Netzwerkadresse (602) eine öffentliche Netzwerkadresse (631) anfordert, die der mit dem Computer-Netzwerk verknüpften eindeutigen Kennung (601) der Drahtlos-Vorrichtung (240) entspricht; eine Anzeige der öffentlichen Netzwerkadresse (631) der Drahtlos-Vorrichtung (240) empfängt; und Daten zu der angezeigten öffentlichen Netzwerkadresse (631) sendet, dadurch gekennzeichnet, dass die öffentliche Netzwerkadresse eine Angabe einer Adresse enthält, wobei die Adresse eine IP-Adresse und ein Port-Paar ist, wobei die angezeigte öffentliche Netzwerkadresse als Ergebnis der Anforderung durch die verdrahtete Vorrichtung an eine spezialisierte Adresszuordnungsfunktion in dem Adressverwaltungs-Proxysystem des Computer-Netzwerks empfangen wird und die spezialisierte Adresszuordnungsfunktion einen modifizierten Domain Name Service (DNS) verwendet, der wenigstens dem UDP- oder dem TCP/IP-Standard entspricht.
  18. Vorrichtung nach Anspruch 1, wobei das Kommunikationscode-Modul wenigstens eine UDP- oder eine TCP/IP-Kommunikation mit der Drahtlos-Vorrichtung implementiert.
DE60211897T 2001-06-08 2002-06-10 Verfahren, Speichermedium, Netwerk und Apparat für eine biderektional initierte Datenkommunikation mit einer drahtlosen Einrichtung Expired - Fee Related DE60211897T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US29690201P 2001-06-08 2001-06-08
US296902P 2001-06-08
PCT/US2002/018485 WO2002102012A2 (en) 2001-06-08 2002-06-10 Method and system for two-way initiated data communication with wireless devices

Publications (2)

Publication Number Publication Date
DE60211897D1 DE60211897D1 (de) 2006-07-06
DE60211897T2 true DE60211897T2 (de) 2006-10-19

Family

ID=23144044

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60211897T Expired - Fee Related DE60211897T2 (de) 2001-06-08 2002-06-10 Verfahren, Speichermedium, Netwerk und Apparat für eine biderektional initierte Datenkommunikation mit einer drahtlosen Einrichtung

Country Status (10)

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

Families Citing this family (65)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6725264B1 (en) * 2000-02-17 2004-04-20 Cisco Technology, Inc. Apparatus and method for redirection of network management messages in a cluster of network devices
US7092390B2 (en) * 2000-09-07 2006-08-15 Sbc Technology Resources, Inc. Internal substitution bi-level addressing for compatible public networks
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
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
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
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
US7379971B2 (en) * 2002-11-19 2008-05-27 Microsoft Corporation Time-to-disconnect enforcement when communicating with wireless devices that have transient network addresses
US20040103153A1 (en) * 2002-11-21 2004-05-27 Chang Tsung-Yen Dean Apparatus and method for providing smart network appliances
KR100511479B1 (ko) * 2002-12-27 2005-08-31 엘지전자 주식회사 Ｎａｔ를 갖는 망에서의 ｓｉｐ 서비스 방법
US20040260801A1 (en) * 2003-02-12 2004-12-23 Actiontec Electronics, Inc. Apparatus and methods for monitoring and controlling network activity using mobile communications devices
US20040158630A1 (en) * 2003-02-12 2004-08-12 Chang Tsung-Yen Dean Monitoring and controlling network activity in real-time
US7926104B1 (en) * 2003-04-16 2011-04-12 Verizon Corporate Services Group Inc. Methods and systems for network attack detection and prevention through redirection
US7447203B2 (en) 2003-07-29 2008-11-04 At&T Intellectual Property I, L.P. Broadband access for virtual private networks
US7739394B2 (en) * 2003-07-29 2010-06-15 At&T Intellectual Property I, L.P. Bi-level addressing for internet protocol broadband access
US7944947B2 (en) * 2003-09-05 2011-05-17 Nokia Corporation Providing address information for reaching a wireless terminal
US20050076141A1 (en) * 2003-09-19 2005-04-07 Williams Aidan Michael Use of an autoconfigured namespace for automatic protocol proxying
US20050210508A1 (en) * 2004-03-19 2005-09-22 Lau Vincent W System and method for managing time-go-live information of media content
GB2418321A (en) * 2004-09-17 2006-03-22 Compal Communications Inc Method for establishing a socket connection between a client and a mobile station through a wireless network
US20060168225A1 (en) * 2004-10-29 2006-07-27 John Gunning Network and a distributed electronic commerce system using the network
US7600217B2 (en) * 2004-12-14 2009-10-06 Sap Ag Socket-like communication API for Java
US7593930B2 (en) * 2004-12-14 2009-09-22 Sap Ag Fast channel architecture
US7580915B2 (en) * 2004-12-14 2009-08-25 Sap Ag Socket-like communication API for C
US7886294B2 (en) * 2004-12-28 2011-02-08 Sap Ag Virtual machine monitoring
US7552153B2 (en) * 2004-12-28 2009-06-23 Sap Ag Virtual machine monitoring using shared memory
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
US20060143389A1 (en) * 2004-12-28 2006-06-29 Frank Kilian Main concept for common cache management
US7689989B2 (en) * 2004-12-28 2010-03-30 Sap Ag Thread monitoring using shared memory
US7539821B2 (en) * 2004-12-28 2009-05-26 Sap Ag First in first out eviction implementation
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
EP2105003B1 (de) * 2006-12-28 2018-02-21 Telecom Italia S.p.A. Verfahren und vorrichtung zur steuerung von anwendungsnachrichten zwischen einem client und einem server mit einer privaten netzwerkadresse
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
AU2009233540B2 (en) * 2008-04-02 2014-03-20 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 华为终端有限公司 数据连接的建立方法、服务端及移动终端
ES2726302T3 (es) * 2015-09-21 2019-10-03 Huawei Tech Co Ltd Sistema informático y procedimiento para acceder a un dispositivo de punto extremo del mismo
EP3759878B1 (de) 2018-02-28 2025-09-17 Nokia Technologies Oy Transparente integration eines 3gpp-netzwerks in einem tsn-basierten industriellen netzwerk
US20220038955A1 (en) * 2020-07-31 2022-02-03 Qualcomm Incorporated Api-controlled pdcp out-of-order control and delivery for downlink traffic
US20240396992A1 (en) * 2023-05-25 2024-11-28 First Orion Corp. Pre-call management of call enhancement services for in-network branded calling delivery

Family Cites Families (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5634010A (en) * 1994-10-21 1997-05-27 Modulus Technologies, Inc. Managing and distributing data objects of different types between computers connected to a network
US6244758B1 (en) * 1994-11-15 2001-06-12 Absolute Software Corp. Apparatus and method for monitoring electronic devices via a global network
US6625652B1 (en) * 1995-01-19 2003-09-23 The Fantastic Corporation System and method for host list pruning
US6418324B1 (en) * 1995-06-01 2002-07-09 Padcom, Incorporated Apparatus and method for transparent wireless communication between a remote device and host system
US5812786A (en) * 1995-06-21 1998-09-22 Bell Atlantic Network Services, Inc. Variable rate and variable mode transmission system
US6041041A (en) * 1997-04-15 2000-03-21 Ramanathan; Srinivas Method and system for managing data service systems
US6178331B1 (en) * 1997-06-17 2001-01-23 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
US6377982B1 (en) * 1997-10-14 2002-04-23 Lucent Technologies Inc. Accounting system in a network
US6675208B1 (en) * 1997-10-14 2004-01-06 Lucent Technologies Inc. Registration scheme for network
US6665718B1 (en) * 1997-10-14 2003-12-16 Lucent Technologies Inc. Mobility management system
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
US20020028656A1 (en) * 2000-02-02 2002-03-07 Yechiam Yemini Method and apparatus for providing forwarding and replication services on a dynamically addressed network
US6714545B1 (en) * 2000-03-03 2004-03-30 Qwest Communications International, Inc. VDSL data network, service and management architecture
US6948003B1 (en) * 2000-03-15 2005-09-20 Ensim Corporation Enabling a service provider to provide intranet services
US6754709B1 (en) * 2000-03-29 2004-06-22 Microsoft Corporation Application programming interface and generalized network address translator for intelligent transparent application gateway processes
US6996628B2 (en) * 2000-04-12 2006-02-07 Corente, Inc. Methods and systems for managing virtual addresses for virtual networks
US7181542B2 (en) * 2000-04-12 2007-02-20 Corente, Inc. Method and system for managing and configuring virtual private networks
US7181766B2 (en) * 2000-04-12 2007-02-20 Corente, Inc. Methods and system for providing network services using at least one processor interfacing a base network
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
US7536639B2 (en) * 2000-08-16 2009-05-19 Verisign, Inc. Numeric/voice name Internet access architecture and methodology
US20020101859A1 (en) * 2000-09-12 2002-08-01 Maclean Ian B. Communicating between nodes in different wireless networks
KR20020027807A (ko) * 2000-10-05 2002-04-15 이종석 인터넷을 이용한 전화서비스 방법
US20020078153A1 (en) * 2000-11-02 2002-06-20 Chit Chung Providing secure, instantaneous, directory-integrated, multiparty, communications services
US20020087722A1 (en) * 2000-12-29 2002-07-04 Ragula Systems D/B/A/ Fatpipe Networks Domain name resolution making IP address selections in response to connection status when multiple connections are present
US7164883B2 (en) * 2001-02-14 2007-01-16 Motorola. Inc. Method and system for modeling and managing terrain, buildings, and infrastructure
US20020138622A1 (en) * 2001-03-21 2002-09-26 Motorola, Inc. Apparatus and method of using long lived addresses in a private network for push messaging to mobile devices
US20060020688A1 (en) * 2001-05-14 2006-01-26 At&T Corp. System having generalized client-server computing

Also Published As

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

Similar Documents

Publication Publication Date Title
DE60211897T2 (de) Verfahren, Speichermedium, Netwerk und Apparat für eine biderektional initierte Datenkommunikation mit einer drahtlosen Einrichtung
DE60320042T2 (de) Verfahren und system zur zentralen zuweisung von adressen und portnummern
DE10392494B4 (de) Mechanismen zum Bereitstellen von Verbindbarkeit zwischen Netzen unterschiedlicher Adressbereiche
DE60214590T2 (de) Verfahren und vorrichtung zur steuerung der informationsverteilung zu mobilstationen
DE60219169T2 (de) System und Verfahren zum schieben von Daten von einer Informationsquelle zu einem mobilen Endgerät beinhalten die Transcodierung der Daten
DE60219133T2 (de) Besucherportal zur Unterstützung von Datenkommunikation von umherstreifenden mobilen Endgeräten
DE60221843T2 (de) Verfahren und vorrichtung zum auflösen einer geräteidentifikation zu einer internetadresse via domänennamenserver
DE602004007301T2 (de) Adressierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten
DE60207100T2 (de) Geheimhalten des aufenthaltsortes in kommunikationsnetzwerken
DE60116736T2 (de) System und verfahren zur benutzung einer ip-addresse als identifizierung eines drahtlosen endgerätes
DE60204528T2 (de) Auflösen von virtuellen Netzwerknamen
US8090843B2 (en) Creating a public identity for an entity on a network
DE60033162T2 (de) Erleichterung der datenübertragung
DE69935138T2 (de) System und Verfahren zur Optimierung der Leistung und der Verfügbarkeit eines DHCP Dienstes
DE102014201188A1 (de) Hybride Unicast-/Multicast-DNS-basierte Dienstermittlung
DE60132232T2 (de) Servicefähige technologie
DE60320105T2 (de) Verbindung von mobilen netzknoten der nächsten generation über netzwerke früherer generation zu netzwerken nächster generation
CN1756259B (zh) 因特网协议网络中使用网络地址翻译的方法和系统
DE602005000017T2 (de) Kommunikationsvorrichtung, Verfahren und Programm zur Namenauflösung
DE60211270T2 (de) Vorrichtung und Verfahren zur Erbringung von Rechnernetzwerken
DE102004021321B4 (de) Verfahren und Einheit zum Ermitteln nutzbarer Dienste
DE10354877B4 (de) Verfahren zur Herstellung einer Verbindung zwischen einem Dienstanforderer (Client) und einem Dienstanbieter (Server) in einem dezentralen Mobilfunknetz
DE60126725T2 (de) Adressierungsverfahren in einem Satelliten Zugriff- oder Infrastruktur- netzwerk für Datenübertragung in einem nicht geschaltetem Modus
DE602006000868T2 (de) Verfahren und System zur Einsparung von Batterieenergie in drahtlosen Geräten operierend in einem lokalen drahtlosen Netzwerk
DE60004197T2 (de) Packetumleiteinrichtung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee