DE69837136T2 - Optimierte Leitweglenkung - Google Patents

Optimierte Leitweglenkung Download PDF

Info

Publication number
DE69837136T2
DE69837136T2 DE69837136T DE69837136T DE69837136T2 DE 69837136 T2 DE69837136 T2 DE 69837136T2 DE 69837136 T DE69837136 T DE 69837136T DE 69837136 T DE69837136 T DE 69837136T DE 69837136 T2 DE69837136 T2 DE 69837136T2
Authority
DE
Germany
Prior art keywords
home
server
registration
network
end system
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
DE69837136T
Other languages
English (en)
Other versions
DE69837136D1 (de
Inventor
Mooi Choo Eaton Town Monmouth Chuah
Girish Bartlett Du Page Rai
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.)
Nokia of America Corp
Original Assignee
Lucent Technologies 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 Lucent Technologies Inc filed Critical Lucent Technologies Inc
Publication of DE69837136D1 publication Critical patent/DE69837136D1/de
Application granted granted Critical
Publication of DE69837136T2 publication Critical patent/DE69837136T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/12—Mobility data transfer between location registers or mobility servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/169—Special adaptations of TCP, UDP or IP for interworking of IP based networks with other networks 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/51—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP for resellers, retailers or service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/75—Account location specifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/765—Linked or grouped accounts, e.g. of users or devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/765—Linked or grouped accounts, e.g. of users or devices
    • H04M15/7655—Linked or grouped accounts, e.g. of users or devices shared by technologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/77—Administration or customization aspects; Counter-checking correct charges involving multiple accounts per user
    • H04M15/772—Administration or customization aspects; Counter-checking correct charges involving multiple accounts per user per service, e.g. prepay or post-pay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/77—Administration or customization aspects; Counter-checking correct charges involving multiple accounts per user
    • H04M15/773—Administration or customization aspects; Counter-checking correct charges involving multiple accounts per user per technology, e.g. PSTN or wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0019—Control or signalling for completing the hand-off for data sessions of end-to-end connection adapted for mobile IP [MIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2212/00—Encapsulation of packets
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/32—Involving wireless systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/54—Resellers-retail or service providers billing, e.g. agreements with telephone service operator, activation, charging/recharging of accounts
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/72—Account specifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/72—Account specifications
    • H04M2215/724—Linked accounts
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/72—Account specifications
    • H04M2215/724—Linked accounts
    • H04M2215/725—Shared by technologies, e.g. one account for different access technologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/72—Account specifications
    • H04M2215/724—Linked accounts
    • H04M2215/7254—Multiple accounts per user
    • H04M2215/7263—Multiple accounts per user per service, e.g. prepay and post-pay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/72—Account specifications
    • H04M2215/724—Linked accounts
    • H04M2215/7254—Multiple accounts per user
    • H04M2215/7268—Multiple accounts per user per technology, e.g. PSTN or wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • 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]

Description

  • Allgemeiner Stand der Technik
  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft die Verwaltung von mobilen Endsystemen in einem paketvermittelten Datennetz, das Computerbenutzer unter Verwendung von Diensten virtueller Privatnetze über eine paketvermittelte drahtlose Hochgeschwindigkeitsdatenstrecke mit Fernzugang zum Internet und zu privaten Intranets versieht. Insbesondere betrifft die Erfindung die Optimierung der Leitweglenkung von mobilen Endsystemen zu gewünschten Kommunikationsservern.
  • Beschreibung des Standes der Technik
  • 1 stellt drei Wirtschaftseinheiten und deren Betriebsmittel dar, die in Zusammenarbeit normalerweise einen Internetfernzugang für Benutzercomputer 2 durch Benutzermodems 4 bereitstellen. Die Benutzercomputer 2 und die Modems 4 bilden Endsysteme.
  • Die erste Wirtschaftseinheit ist die Telefongesellschaft (Telco für engl. telephone company), die das normale alte Telefonwählsystem (POTS für engl. plain old telephone system) oder diensteintegrierende Datennetz (ISDN für engl. integrated services data network) besitzt und betreibt. Die Telco stellt die Medien in Form des öffentlichen Telefonwählnetzes (PSTN für engl. public switched telephone network) 6 bereit, über welches Bits (oder Pakete) zwischen Benutzern und den beiden anderen Wirtschaftseinheiten fließen können.
  • Die zweite Wirtschaftseinheit ist der Internetdiensteanbieter (ISP für engl. internet service provider). Der ISP verwendet und verwaltet einen oder mehr Übergabepunkte (POPs für engl. points of presence) 8 in seinem Dienstbereich, an welche Endbenutzer sich für Netzdienst anschließen. Ein ISP richtet normalerweise in jedem größeren Ortsanschlussbereich, in welchem der ISP erwartet, Kunden zu verpflichten, einen POP ein. Der POP wandelt den Nachrichtenverkehr vom PSTN, das von der Telco geführt wird, in eine digitale Form um, damit er über das Intranetbackbone 10 übertragen wird, das dem ISP gehört oder von einem Intranetbackbone-Anbieter wie der MCI, Inc. gemietet ist. Ein ISP mietet normalerweise fraktionale oder komplette T1-Leitungen oder fraktionale oder komplette T3-Leitungen von der Telco zur Verbindungsfähigkeit mit dem PSTN. Die POPs und das ISP-Medien-Datenzentrum 14 sind über das Intranetbackbone durch einen Router 12A miteinander verbunden. Das Datenzentrum beherbergt die Webserver, Mailserver, Abrechnungs- und Registrierungsserver des ISPs und befähigt den ISP, Webinhalte, sowie E-Mail- und Webhosting-Dienste für Endbenutzer bereitzustellen. Zukünftige Mehrwertdienste können durch Einsetzen von zusätzlichen Arten von Servern im Datenzentrum hinzugefügt werden. Der ISP unterhält auch den Router 12A zur Verbindung mit dem öffentlichen Internetbackbone 20. Im aktuellen Modell für Fernzugang haben Endbenutzer Dienstverhältnisse mit ihrer Telco und ihrem ISP und erhalten für gewöhnlich getrennte Rechnungen von beiden. Endbenutzer greifen durch Anwählen des nächstgelegenen POPs und Ausführen eines Kommunikationsprotokolls, das als das Punkt-zu-Punkt-Protokoll oder PPP (für engl. Point-to-point protocol) der Arbeitsgruppe zur Entwicklung und Koordinierung von Internetprotokollen (IETF für engl. Internet Engineering Task Force) bekannt ist, auf den ISP und durch den ISP auf das öffentliche Internet 20 zu.
  • Die dritte Wirtschaftseinheit ist das Privatunternehmen, das aus Geschäftsgründen sein eigenes privates Intranet 18 besitzt und durch den Router 12B betreibt. Firmenangestellte können durch Durchführen von POTS/ISDN-Anrufen (z.B. von Zuhause oder von unterwegs) zum Fernzugangsserver 16 der Firma und Ausführen des IETF-PPP-Protokolls auf das Firmennetz 18 zugreifen. Für den Firmenzugang zahlen Endbenutzer nur die Kosten für die Verbindung mit dem Fernzugangsserver 16 der Firma. Der ISP ist nicht beteiligt. Das Privatunternehmen unterhält den Router 12B, um einen Endbenutzer entweder mit dem firmeneigenen Intranet 18 oder dem öffentlichen Internet 20 oder beiden zu verbinden.
  • Endbenutzer zahlen der Telco die Kosten für Telefonanrufe und die Kosten für eine Telefonleitung zu ihnen nach Hause. Endbenutzer bezahlen auch den ISP für den Zugang zum Netz und den Diensten des ISPs. Die vorliegende Erfindung kommt Drahtlosdiensteanbietern wie Sprint PCS, PrimeCo usw. zugute, und sie kommt auch Internetdiensteanbietern wie AOL, AT&T Worldnet usw. zugute.
  • Heutzutage bieten Internetdiensteanbieter Endbenutzern Internetzugangsdienste, Webinhaltsdienste, E-Mail-Dienste, Contenthosting-Dienste und Roaming an. Aufgrund kleiner Gewinnspannen und in Ermangelung eines Rahmens zur Durchführung einer Marktsegmentierung auf der Basis von Merkmalen und Preisen suchen ISPs nach Mehrwertdiensten zur Verbesserung der Gewinnspannen. Kurzfristig werden Betriebsmittelhersteller imstande sein, den ISPs Lösungen anbieten, damit sie schnelleren Zugang, Vernetzung virtueller Privatnetze (was die Fähigkeit ist, öffentliche Netze sicher als Privatnetze zu verwenden und mit Intranets zu verbinden), Roaming-Konsortien, Push-Techniken und Dienstgüte anbieten können. Längerfristig werden auch Sprachübertragung über Internet und Mobilität angeboten. Die ISPs werden diese Mehrwertdienste verwenden, um der Zwangsjacke kleiner Gewinnspannen zu entrinnen. Viele dieser Mehrwertdienste fallen in die Kategorie von Netzdiensten und können nur durch die Netzinfrastrukturbetriebsmittel angeboten werden. Andere fallen in die Kategorie von Anwendungsdiensten, welche die Unterstützung von der Netzinfrastruktur benötigen, während andere keine Unterstützung von der Netzinfrastruktur benötigen. Dienste wie schnellerer Zugang, Vernetzung virtueller Privatnetze, Roaming, Mobilität, Sprache, Dienstgüte und dienstgütebasierte Abrechnung benötigen alle eine verbesserte Netzinfrastruktur. Die Erfindung, die hier beschrieben wird, stellt diese verbesserten Dienste entweder direkt bereit, oder sie stellt Gabeln bereit, damit diese Dienste als zukünftige Verbesserungen später hinzugefügt werden können. Drahtlosdiensteanbieter werden imstande sein, einen größeren Anteil am Ertragsstrom zu gewinnen. Der ISP wird imstande sein, mehr Dienste mit einer besseren Marktsegmentierung anzubieten.
  • Der Stand der Technik von Interesse, der mit dem erfinderischen Gegenstand in Beziehung steht, ist Folgender:
    EP 0 697 798 , eingereicht am 21. Februar 1996, offenbart eine Verbesserung für ein drahtloses Paketdatenübertragungssystem, indem einem Teilnehmer, der ein mobiles Endsystem (M-ES) (205) verwendet, die Möglichkeit gegeben wird, den Verbindungsnetzbetreiber (IXC) (222 oder 224) auszuwählen, der die Daten während einer bestimmten Kommunikationssitzung über jene Netzwege überträgt, für welche der Teilnehmer die Kosten trägt. Das System ermöglicht es dem Teilnehmer, einen bevorzugten Verbindungsnetzbetreiber in einem optionalen Bevorzugter-IXC-Feld, das einer Begrüßungsnachricht des Endsystems hinzugefügt wird, zu spezifizieren. Während der Registrierungs- und Berechtigungsprozeduren wird in einem Bevorzugter-IXC-Feld, das standardmäßigen Registrierungsprotokollnachrichten hinzugefügt wird, eine Kennung, die dem bevorzugten Verbindungsnetzbetreiber entspricht, zwischen einem versorgenden mobilen Datentransitsystem (MD-IS) (220) und einem Heimat-MD-IS (240) übertragen. Wenn der Teilnehmer in dem Bevorzugter-IXC-Feld einen bevorzugten Verbindungsnetzbetreiber spezifiziert hat, dann wird diesem bevorzugten Verbindungsnetzbetreiber eine höhere Priorität eingeräumt als einem vorgegebenen bevorzugten Verbindungsnetzbetreiber, der ausgewählt wird, wenn der Teilnehmer die Netzdienste abonniert. Jedes MD-IS wird mit einer neuen Datenbank (221, 241) versehen, welche Verbindungsnetzbetreiberkennungen in eine entsprechende Grenzrouteradresse abbildet, die dem bevorzugten Verbindungsnetzbetreiber zugeordnet wird, um Datenpakete über den vom Teilnehmer bevorzugten IXC zu leiten. Demnach ermöglicht das System es, Daten auf einer Pro-Sitzung-Basis sowohl auf Wegen in der Vorwärts- als auch der Rückwärtsrichtung über den vom Teilnehmer bevorzugten Verbindungsnetzbetreiber zu senden.
  • WO 96/21983 offenbart eine protokollabhängige Leitweglenkung von Datenpaketen zwischen einer Mobilstation eines Paketfunknetzes und einem Gesprächspartner (Host), der mit einem externen Netz verbunden ist. Ein Datenpaket eines fremden Protokolls (IPX) wird durch ein Paketfunknetz, das ein zweites Protokoll (X.25) verwendet, als in einem Datenpaket gemäß dem zweiten Protokoll eingekapselt übertragen. Das übertragende Paketfunknetz braucht das Protokoll des übertragenen fremden Datenpakets demnach weder zu verstehen, noch muss es die Inhalte des Datenpakets interpretieren können. Ein Datenpaketnetz ist mit anderen Paketfunknetzen, Datennetzen oder dem Backbone-Netz zwischen Paketdatennetzen über einen Netzübergangsknoten (GPRS GSN) verbunden, welcher das netzinterne Protokoll (X.25) zum dedizierten Paketnetz und das Protokoll jedes Netzes zu anderen Netzen verwendet. Wenn ein Datenpaket über einen Netzübergangsknoten von einem Netz in ein anderes Netz übertragen wird, wird das Datenpaket in einem Paket gemäß dem Protokoll des neuen Netzes eingekapselt. Wenn das eingekapselte Datenpaket in einem Knoten ankommt, welcher das Protokoll des eingekapselten Datenpakets unterstützt, wird die Einkapselung abgestreift, und das Datenpaket wird gemäß dem Protokoll des Datenpakets weitergesendet.
  • KURZDARSTELLUNG DER ERFINDUNG
  • Ein Verfahren und eine Vorrichtung gemäß der vorliegenden Erfindung werden in den unabhängigen Ansprüchen dargelegt, auf welche der Leser nun verwiesen wird. Bevorzugte Merkmale werden in den abhängigen Ansprüchen angeführt.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung wird in der folgenden Beschreibung von bevorzugten Ausführungsforen unter Bezugnahme auf die folgenden Figuren ausführlich beschrieben, wobei:
  • 1 ein Konfigurationsdiagramm einer bekannten Fernzugangsarchitektur durch ein öffentliches Telefonwählnetz ist;
  • 2 ein Konfigurationsdiagramm einer Fernzugangsarchitektur durch ein drahtloses paketvermitteltes Datennetz gemäß der vorliegenden Erfindung ist;
  • 3 eine Endsystemkonfiguration gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht;
  • 4 eine andere Endsystemkonfiguration gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht;
  • 5 eine andere Endsystemkonfiguration gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht;
  • 6 ein Konfigurationsdiagramm von ausgewählten Teilen der Architektur des Netzes von 2 ist, das ein Roaming-Szenarium darstellt;
  • 7 ein Konfigurationsdiagramm einer Basisstation mit lokalen Zugangspunkten ist;
  • 8 ein Konfigurationsdiagramm einer Basisstation mit abgesetzten Zugangspunkten ist;
  • 9 ein Konfigurationsdiagramm einer Basisstation mit abgesetzten Zugangspunkten ist, von welchen einige unter Verwendung einer drahtlosen Trunk-Verbindung angeschlossen sind;
  • 10 ein Diagramm eines Protokollstapels für einen lokalen Zugangspunkt ist;
  • 11 ein Diagramm eines Protokollstapels für einen abgesetzten Zugangspunkt mit einem drahtlosen Trunk ist;
  • 12 ein Diagramm eines Protokollstapels für eine Relaisfunktion in der Basisstation zur Unterstützung von abgesetzten Zugangspunkten mit drahtlosen Trunks ist;
  • 13 ein Diagramm von Protokollstapeln zur Implementierung der Relaisfunktion ist, die in 12 dargestellt ist;
  • 14 ein Diagramm von Protokollstapeln für eine Relaisfunktion in der Basisstation zur Unterstützung von lokalen Zugangspunkten ist;
  • 15 ein Konfigurationsdiagramm von ausgewählten Teilen der Architektur des Netzes von 2 ist, das ein erstes Endsystem, das sich im Heimatnetznetz vom Heimatnetz registrieren lässt, und ein zweites System, das sich im Heimatnetz von einem Fremdnetz unter Verwendung einer Heimatnetzübergangsfunktion für einen Anker registrieren lässt, darstellt;
  • 16 ein Konfigurationsdiagramm von ausgewählten Teilen der Architektur des Netzes von 2 ist, das ein erstes Endsystem, das sich im Heimatnetznetz vom Heimatnetz registrieren lässt, und ein zweites System, das sich im Heimatnetz von einem Fremdnetz unter Verwendung einer versorgenden Netzübergangsfunktion für einen Anker registrieren lässt, darstellt;
  • 17 ein Leiterdiagramm der Aufforderungs- und Antwortnachrichten zum Registrieren in einem Heimatnetz von einem Fremdnetz und Aufbauen, Authentifizieren und Konfigurieren einer Datenstrecke ist;
  • 18 ein Konfigurationsdiagramm von ausgewählten Teilen der Architektur des Netzes von 2 ist, das Registrierungsaufforderungen und -antworten zum Registrieren einer Mobileinheit in einem Heimatnetz vom Heimatnetz darstellt;
  • 19 ein Konfigurationsdiagramm von ausgewählten Teilen der Architektur des Netzes von 2 ist, das Registrierungsaufforderungen und -antworten zum Registrieren einer Mobileinheit in einem Heimatnetz von einem Fremdnetz darstellt;
  • 20 ein Konfigurationsdiagramm von Protokollstapeln ist, das Kommunikationen zwischen einem Endsystem in einem Heimatnetz und einer Netzübergangsfunktion im Heimatnetz darstellt, wobei der Zellenstandort lokale Zugangspunkte aufweist;
  • 21 ein Konfigurationsdiagramm von Protokollstapeln ist, das Kommunikationen zwischen einem Endsystem in einem Heimatnetz und einer Netzübergangsfunktion im Heimatnetz darstellt, wobei der Zellenstandort abgesetzte Zugangspunkte aufweist, die durch einen drahtlosen Trunk mit einem drahtlosen Hub verbunden sind;
  • 22 ein Konfigurationsdiagramm von Protokollstapeln ist, das Kommunikationen zwischen einer Basisstation, die mit einem Gast-Endsystem gekoppelt ist, und einer Heimatnetzübergangsfunktion darstellt;
  • 23 ein Konfigurationsdiagramm von Protokollstapeln ist, das Kommunikationen eines Endsystems in einem Heimatnetz durch eine Netzübergangsfunktion im Heimatnetz mit einem Internetdiensteanbieter darstellt;
  • 24 ein Konfigurationsdiagramm von Protokollstapeln ist, das Kommunikationen zwischen einem Endsystem in einem Fremdnetz und einem Heimatregistrierungsserver in einem Heimatnetz während der Registrierungsphase darstellt;
  • 25 ein Verarbeitungsflussdiagramm ist, das die Verarbeitung von Abrechungsdaten durch das Kundengebührenverrechnungssystem darstellt;
  • 26 und 27 Leiterdiagramme sind, die den Registrierungsprozess für ein Endsystem in einem Heimatnetz beziehungsweise in einem Fremdnetz veranschaulichen;
  • 28 und 29 Protokollstapeldiagramme sind, die eine Endsystemverbindung in einem Heimatnetz darstellen, wobei ein PPP-Protokoll in einer Netzübergangsfunktion des Heimatnetzes endet beziehungsweise das PPP-Protokoll in einem ISP oder einem Intranet endet;
  • 30 und 31 Protokollstapeldiagramme sind, die eine Endsystemverbindung in einem Fremdnetz darstellen, wobei ein PPP-Protokoll in einer Netzübergangsfunktion des Fremdnetzes endet beziehungsweise das PPP-Protokoll in einem ISP oder einem Intranet endet;
  • 32, 33 und 34 Leiterdiagramme sind, die ein lokales Weiterschaltszenarium, ein Mikro-Weiterschaltszenarium beziehungsweise ein Makro-Weiterschaltszenarium veranschaulichen;
  • 35 ein Leiterdiagramm ist, das ein globales Weiterschaltszenarium veranschaulicht, wobei der fremde Registrierungsserver wechselt und wobei die Heimatnetzübergangsfunktion nicht wechselt;
  • 36 ein Leiterdiagramm ist, das ein globales Weiterschaltszenarium veranschaulicht, wobei sowohl der fremde Registrierungsserver als auch die Heimatnetzübergangsfunktion wechseln;
  • 37 und 38 Systemkonfigurationsdiagramme sind, welche mögliche Verbindungen veranschaulichen; und
  • 39 bis 42 verschiedene Weiterschaltszenarien veranschaulichen.
  • AUSFÜHRLICHE BESCHREIBUNG VON BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • Die vorliegende Erfindung versieht Computerbenutzer mit Fernzugang zum Internet und zu privaten Intranets unter Verwendung von Diensten virtueller Privatnetze über eine paketvermittelte drahtlose Hochgeschwindigkeitsdatenstrecke. Diese Benutzer sind imstande, über eine drahtlose Verbindung auf das öffentliche Internet, private Intranets und ihre Internetdiensteanbieter zuzugreifen. Das Netz unterstützt Roaming, das heißt die Fähigkeit, auf das Internet und private Intranets unter Verwendung von Diensten virtueller Privatnetze von überall zuzugreifen, wo die Dienste, die durch die vorliegende Erfindung angeboten werden, verfügbar sind. Das Netz unterstützt auch Weiterschaltungen, das heißt die Fähigkeit, den Anschlusspunkt des Benutzers zum Netz zu wechseln, ohne die PPP-Verbindung zwischen dem PPP-Client und dem PPP-Server zu stören. Das Netz zielt auf Benutzer ab, die horizontale Internet- und Intranetanwendungen ausführen. Diese Anwendungen umfassen elektronische Post, Dateitransfer, browserbasierten WWW-Zugang und andere kommerzielle Anwendungen, die rund um das Internet eingerichtet sind. Da das Netz auf den IETF-Standards basieren wird, ist es möglich, Streaming-Media-Protokolle, wie RTP, und Konferenzprotokolle, wie H.323, über das Netz aus zuführen.
  • Andere Internetfernzugangstechniken, die bereits eingesetzt werden oder in verschiedenen Einsatzstufen sind, umfassen: Drahtleitungseinwahlzugang auf der Basis von POTS und ISDN, XDSL-Zugang, drahtlosen leitungsvermittelten Zugang auf der Basis von GSM/CDMA/TDMA, drahtlosen paketvermittelten Zugang auf der Basis von GSM/CDMA/TDMA, Kabelmodems und satellitenbasierte Systeme. Die vorliegende Erfindung bietet jedoch niedrige Einsatzkosten, Wartungsfreundlichkeit, einen umfassenden Merkmalssatz, Skalierbarkeit, eine Fähigkeit zum sanften Leistungsabfall unter Bedingungen starker Belastung und Unterstützung für verbesserte Netzdienste wie Vernetzung virtueller Privatnetze, Roaming, Mobilität und Dienstgüte zum jeweiligen Nutzen von Benutzern und Diensteanbietern.
  • Was Drahtlosdiensteanbieter betrifft, die ein persönliches Kommunikationssystemsspektrum (PCS für engl. personal communications system) besitzen, so befähigt die vorliegende Erfindung sie, drahtlose paketvermittelte Datenzugriffsdienste anzubieten, die mit den Diensten konkurrieren können, die durch die traditionellen Drahtleitungs-Telcos bereitgestellt werden, die das PSTN besitzen und betreiben. Drahtlosdiensteanbieter können auch beschließen, selbst Internetdiensteanbieter zu werden, in welchem Fall sie das ganze Netz besitzen und betreiben und für Benutzer Ende-zu-Ende-Dienste bereitstellen.
  • Was Internetdiensteanbieter betrifft, so ermöglicht die vorliegende Erfindung es ihnen, die Telcos zu umgehen (vorausgesetzt, sie kaufen oder mieten das Spektrum) und Benutzern direkte Ende-zu-Ende-Dienste anzubieten, vielleicht unter Einsparung von Zugangsgebühren für die Telcos, was in Zukunft noch zunehmen kann, da das Internet wächst, um noch größer zu werden, als es jetzt schon ist.
  • Die vorliegende Erfindung ist flexibel, so dass sie Drahtlosdiensteanbietern zugute kommen kann, die keine Internetdiensteanbieter sind und Endbenutzern nur ISP-, Internet- oder privaten Intranetzugang verschaffen. Die Erfindung kann auch Diensteanbietern zugute kommen, die für Endbenutzer drahtlosen Zugang und Internetdienste bereitstellen. Die Erfindung kann auch Diensteanbietern zugute kommen, die drahtlosen Zugang und Internetdienste bereitstellen, aber auch zulassen, den drahtlosen Abschnitt des Netzes zum Zugang zu anderen ISPs oder zu privaten Intranets zu verwenden.
  • In 2 schließen sich Endsysteme 32 (z.B. basierend auf einem Win 95 Personalcomputer) unter Verwendung von externen oder internen Modems an ein drahtloses Netz 30 an. Diese Modems ermöglichen es Endsystemen, Medienzugriffssteuerungs- oder MAC-Rahmen (MAC für engl. medium access control) über eine Luftverbindung 34 zu senden und zu empfangen. Externe Modems sind über eine drahtgebundene oder drahtlose Verbindung an den PC angeschlossen. Externe Modems sind ortsfest und zum Beispiel ortsgleich mit Richtantennen, die auf dem Dach montiert sind, untergebracht. Externe Modems können unter Verwendung jedes der folgenden Mittel mit dem PC eines Benutzers verbunden werden: 802.3, universeller serieller Bus, paralleler Port, Infrarot oder sogar eine ISM-Funkverbindung. Interne Modems sind vorzugsweise PCMCIA-Karten für Laptops und werden in die Rückwandplatine des Laptops gesteckt. Unter Verwendung von kleinen Allrichtungsantennen senden und empfangen sie MAC-Rahmen über die Luftverbindung.
  • Das Endsystem besteht aus den Betriebsmitteln, die sich am Aufenthaltsort des Teilnehmers befinden. Im Falle einer festen Installation besteht das Endsystem aus einer Dachantenne, Funkkomponenten, Digitalkomponenten und schließlich einem Tischcomputer. Es ist anzunehmen, dass ein Teilnehmer den Tischcomputer bereits besitzt, weshalb das drahtlose System durch Standardschnittstellen mit dem PC verbunden werden muss. 3 bis 5 veranschaulichen verschiedene Optionen für typische feste Installationen des drahtlosen Systems. Jede der Wahlmöglichkeiten, die in diesen Figuren umrissen werden, hat Konsequenzen, die damit verbunden sind und von den Installationskosten, den Betriebsmittelkosten und der praktischen Installation bis hin zu umgebungsbedingten bei der Installation reichen, was im Folgenden erörtert wird.
  • Die Installation, die in 3 dargestellt ist, ist gegenwärtig die billigste. Bei dieser Konfiguration ist nur eine Antenne 21 außen angeordnet, und ein HF-Kabel 22 ist mit dem Funkgerät 23 verbunden. Der Installierer, entweder der bezahlte Fachmann oder der Teilnehmer, muss nur die Antenne 21 auf dem Dach oder auf der Seite des Gebäudes installieren und ein billiges externes Kabel 22 entlang des Gebäudes zu einer Einführstelle hinab lassen, normalerweise durch ein Loch im Eck eines Fensterrahmens oder durch ein Loch in der Wand in der Nähe eines inneren Fußbodens. Das Funkgerät 23 ist extern vom Tischcomputer 24 mit einer PCMCIA-Schnittstelle zum PC 24. Verluste bei langen HF-Kabelverläufen für Benutzer, die sich an entfernten Punkten vom Zugangspunkt befinden, können mit in Reihe geschalteten bidirektionalen HF-Verstärkern kompensiert werden. Benutzer in der Nähe des Zugangspunkts können die zusätzlichen Verluste von langen Kabelverläufen tolerieren, da ihre Ausbreitungsverluste nicht so groß wie bei Benutzern am Rand der Zelle sind.
  • Eine andere Anordnung, die in 4 veranschaulicht ist, bezieht die Integration der Funkelektronik und der Antenne in ein gemeinsames Gerät 25 ein. Die Verbindung mit dem PC 24 wäre durch eine proprietäre Schnittstelle und PCMCIA. Leistung würde dem Gerät von einem Wandtransformator 27 über eine mehrfach verdrillte Doppelleitung 26 zugeführt werden, welche sowohl Leistung als auch digitale Daten befördert. Die Schwierigkeiten beim Konstruieren eines integrierten Geräts umfassen Wetterfestigkeit, Erwärmung und Kühlung, sowie Servertemperaturextreme.
  • Eine andere Anordnung besteht aus einer Außenantenne und einer im Dachgeschoss montierten Teilnehmereinheit. Dies verringert einige der Anforderungen hinsichtlich niedriger Temperatur und Wetterfestigkeit, aber es muss eine Kühlung bereitgestellt werden. Die Teilnehmereinheit wird dann über ein Kabel mit dem PC verbunden.
  • Das letzte und teuerste Mittel, durch welches die digitalen Daten vom Funkgerät zu einem Computer oder mehreren Computern übertragen werden, ist die Verwendung eines ISM-Band-LANs, wie beispielsweise des WaveLANs, wie in 5 dargestellt. Die Antenne 21 befindet sich auf dem Dach, wie bei der vorherigen Installation, und das Funkgerät kann bei der Antenne oder sonst irgendwo angeordnet sein. Eine 802.3 Verbindung verbindet das Funkgerät mit einem Zugangspunkt des drahtlosen LANs. Jedes der abgesetzten Computergeräte innerhalb des Hauses hat nun Zugang zum drahtlosen LAN 28. Idealerweise sollte die Antenne 29 des Zugangspunkts des drahtlosen LANs eine Richtantenne sein, die im Gebäude hoch angeordnet ist und nach unten zeigt, um eine Versorgung für das Haus bereitzustellen, während eine HF-Streuung außerhalb des Hauses minimiert wird. Das Anordnen der Antenne im Dachgeschoss wirft verschiedene Probleme von der Speisung des Geräts im Dachgeschoss bis hin zur Kühlung der LAN-Funkgeräte auf. In der Praxis scheint es, dass eine LAN-Antenne, die irgendwo im Haus angeordnet ist, akzeptabel ist, solange die Längen der LAN-Zugangspunktantennenkabel kurz sind.
  • Es kann eine Notwendigkeit bestehen, Gastteilnehmer zu versorgen, die entscheiden, ihren Laptopcomputer aus ihrem Heimatversorgungsbereich in einen anderen Versorgungsbereich mitzunehmen. Der Laptopbenutzer muss eine Flachplatten-Richtantenne verwenden, welche zu den Zugangspunkten gerichtet ist. Die Ausrichtung des Zugangspunkts ist für die Gewährleistung der Dienstgüte entscheidend. Als Teil der Laptopsoftware bietet ein Ausrichtungsindikator Führung beim Ausrichten der Antenne.
  • Es ist vorgesehen, dass die Antenne ungefähr ½ oder ¾ Inch dick ist und eine Öffnung von ungefähr derselben Größe wie der Laptop (8 ½'' × 11'') aufweist. Einige Mittel zum vorübergehenden Befestigen der Antennenplatte auf der Rückseite des Laptops, wie beispielsweise Klettverschlüsse, sind für den Transport der Antenne zweckmäßig. Sobald der Laptopbenutzer am Aufenthaltsort ankommt, wo der Zugang gewünscht wird, kann die Antenne entweder von der Rückseite des Laptops abgenommen und für die beste Leistung orientiert oder in Bereichen mit sehr starken Signalen am Laptop befestigt gelassen werden. Die Laptopantenne kann mit einem biaxialen Ausrichtungsmechanismus, welcher den Azimut und die Höhe der Antenne ändert, sogar gelenkig mit dem Laptop verbunden werden. Die Antennenplatten unterstützen eine 45° geneigte Doppelpolarisation mit konischen Strahlenformen, um jegliche Ausbreitungseffekte zu eliminieren, welche die Signalqualität beeinflussen können. Da außerdem die Strahlenformen bei Doppelpolarisation konisch sind, sollte die Lage der Antenne auf beiden Seiten die Signalqualität nicht ändern.
  • Eine weiträumige drahtlose Versorgung wird durch Basisstationen 36 bereitgestellt. Die Versorgungsreichweite, der durch die Basisstationen 36 bereitgestellt wird, hängt von Faktoren wie Streckenbilanz, Kapazität und Versorgungsgrad ab. Basisstationen werden durch Drahtlosdiensteanbieter von personenbezogenen Kommunikationsdiensten PCS (für engl. personal communication services) normalerweise in Zellenstandorten installiert. Basisstationen multiplexen den Endsystemverkehr von ihrem Versorgungsbereich über ein Drahtleitungs- oder Mikrowellen-Backhaul-Netz 38 zur Mobilvermittlungseinrichtung (MSC) 40 des Systems.
  • Die Erfindung ist von der MAC- und der (physikalischen) PHY-Schicht der Luftverbindung, sowie der Art des Modems unabhängig. Die Architektur ist auch von der physikalischen Schicht und der Topologie des Backhaul-Netzes 38 unabhängig. Die einzigen Anforderungen für das Backhaul-Netz sind, dass es zum Leiten von Internetprotokoll- oder IP-Paketen zwischen Basisstationen und der MSC mit einer angemessenen Leistung imstande sein muss. An der Mobilvermittlungseinrichtung 40 (MSC 40) beendet eine Paketdaten-IWF oder -Netzübergangsfunktion (IWF für engl. inter-working function) 52 die drahtlosen Protokolle für dieses Netz. Ein IP-Router 42 verbindet die MSC 40 mit dem öffentlichen Internet 44, privaten Intranets 46 oder den Internetdiensteanbietern 46. Abrechnungs- und Verzeichnisserver 48 in der MSC 40 speichern Abrechnungsdaten und Verzeichnisinformationen. Ein Elementverwaltungsserver 50 verwaltet die Betriebsmittel, welche die Basisstationen, die IWFs und die Abrechnungs/Verzeichnisserver umfassen.
  • Der Abrechnungsserver sammelt Abrechnungsdaten für Benutzer und sendet die Daten an das Gebührenverrechnungssystem des Diensteanbieters. Die Schnittstelle, die durch den Abrechnungsserver unterstützt wird, sendet Abrechnungsinformationen im Rechnungsprotokollformat des Amerikanischen Verbunds für Betriebsführung AMA (American Management Association) oder irgendeinem anderen geeigneten Rechnungsformat über eine Transportsteuerungsprotokoll/Internetprotokoll- oder TCP/IP-Übertragung (für engl. transport control protocol/internet protocol) an das Gebührenverrechnungssystem (das in der Figur nicht dargestellt ist).
  • Die Netzinfrastruktur versorgt Endsysteme mit einem PPP- oder Punkt-zu-Punkt-Dienst. Das Netz stellt (1) einen festen drahtlosen Zugang mit Roaming (Einloggen überall da, wo die drahtlose Versorgung verfügbar ist) für Endsysteme und (2) niedrigratige Mobilität und Weiterschaltungen bereit. Wenn ein Endsystem sich bei einem Netz anmeldet, kann es entweder einen festen Dienst (d.h. stationär und ohne Notwendigkeit von Weiterschaltdiensten) oder einen mobilen Dienst (d.h. mit der Notwendigkeit von Weiterschaltdiensten) anfordern. Ein Endsystem, das weder fest noch mobil spezifiziert, wird als den mobilen Dienst spezifizierend angesehen. Die tatsächliche Registrierung des Endsystems ist das Ergebnis einer Verhandlung mit einem Heimatregistrierungsserver auf der Basis der angeforderten Dienstklasse, der Dienstklasse, die vom Benutzer des Endsystems abonniert wurde, und der Dienstmerkmale, die im Netz verfügbar sind.
  • Wenn das Endsystem eine Festdienstregistrierung (d.h. ohne Weiterschaltdienste anzufordern) aushandelt und das Endsystem sich im Heimatnetz befindet, wird eine IWF (Netzübergangsfunktion) in der Basisstation implementiert, um den Verkehr zwischen dem Endbenutzer und einem Kommunikationsserver, wie beispielsweise einem PPP-Server (d.h. mit dem zu verbindenden Punkt, zum Beispiel einem ISP-PPP-Server oder einem PPP-Server des firmeneigenen Intranets oder einem PPP-Server, der durch den Drahtlosdiensteanbieter betrieben wird, um Kunden direkten Zugang zum öffentlichen Internet zu verschaffen), zu vermitteln. Es ist zu erwarten, dass vielleicht 80 % des Nachrichtenverkehrs von dieser Kategorie sein werden, weshalb diese Architektur die IWF-Verarbeitung an die Basisstationen verteilt und eine Nachrichtenverkehrsbehinderung in einer zentralen Mobilvermittlungseinrichtung vermeidet.
  • Wenn das Endsystem einen mobilen Dienst anfordert (von einem Heimatnetz oder einem Fremdnetz) oder wenn das Endsystem einen Roaming-Dienst (d.h. einen Dienst vom Heimatnetz durch ein Fremdnetz) anfordert, werden zwei IWFs eingerichtet: eine versorgende IWF, die normalerweise in der Basisstation des Netzes eingerichtet wird, an welches das Endsystem angeschlossen ist (sei es das Heimatnetz oder ein Fremdnetz), und eine Heimat-IWF, die normalerweise in der Mobilvermittlungseinrichtung MSC des Heimatnetzes eingerichtet wird. Da zu erwarten ist, dass diese Situation nur etwa 20 % des Nachrichtenverkehrs einbezieht, wird die Nachrichtenverkehrsbehinderung um die Mobilvermittlungseinrichtung minimiert. Die versorgende IWF und der drahtlose Hub können ortsgleich im selben Computersatz untergebracht sein oder sie können sogar im selben Computer programmiert sein, so dass kein Tunnel unter Verwendung eines XTunnnel-Protokolls zwischen dem drahtlosen Hub und der versorgenden IWF hergestellt zu werden braucht.
  • Basierend auf den verfügbaren Dienstmerkmalen und der angeforderten Dienstart und Dienstgüte kann eine versorgende IWF in einem Fremdnetz alternativerweise aus Dienstmerkmalen in der fremden MSC gewählt werden. Im Allgemeinen wird die Heimat-IWF zu einem Ankerpunkt, der während der Kommunikationssitzung nicht gewechselt wird, während die versorgende IWF wechseln kann, wenn das Endsystem sich ausreichend bewegt.
  • Die Basisstation weist einen Zugangshub und wenigstens einen Zugangspunkt (sei er abgesetzt oder mit dem Zugangshub ortsgleich untergebracht) auf. Normalerweise versorgt der Zugangshub mehrere Zugangspunkte. Obwohl das Endsystem gemäß den Lehren dieser Erfindung an einen Zugangspunkt durch einen Draht oder ein Kabel angeschlossen werden kann, ist das Endsystem in einer bevorzugten Ausführungsform durch eine drahtlose „Luftverbindung" an den Zugangspunkt angeschlossen, in welchem Fall der Zugangshub zweckmäßig als drahtloser Hub bezeichnet wird. Es versteht sich von selbst, dass, obwohl der Zugangshub die ganze Beschreibung hindurch als „drahtloser Hub" bezeichnet wird, ein Endsystem, das durch einen Draht oder ein Kabel durch einen Zugangspunkt mit einem Zugangshub gekoppelt ist, eine gleichwertige Implementierung ist und durch den Begriff „Zugangshub" berücksichtigt ist.
  • In der Erfindung weist ein Endsystem einen Endbenutzerregistrierungsagenten (z.B. eine Software, die auf einem Computer des Endsystems, seines Modems oder beiden läuft) auf, der mit einem Zugangspunkt und durch den Zugangspunkt mit einem drahtlosen Hub kommuniziert. Der drahtlose Hub weist einen Proxy-Registrierungsagenten (z.B. eine Software, die auf einem Prozessor im drahtlosen Hub läuft) auf, der als ein Proxy für den Endbenutzerregistrierungsagenten fungiert. Ähnliche Konzepte, die zum Beispiel in dem von der IETF vorgeschlagenen Mobile-IP-Standard verwendet werden, werden allgemein als fremder Agent (FA) bezeichnet. Aus diesem Grund wird der Proxy-Registrierungsagent der vorliegenden Erfindung als fremder Agent bezeichnet, und Aspekte des fremden Agenten der vorliegenden Erfindung, die sich vom fremden Agenten des Mobile IPs unterscheiden, sind so, wie sie während dieser Beschreibung dargelegt werden.
  • Bei Verwenden des Proxy-Registrierungsagenten (d.h. des fremden Agenten) in einer Basisstation ist der Benutzerregistrierungsagent eines Endsystems imstande, einen Anschlusspunkt ans Netz zu ermitteln und sich bei einem Registrierungsserver in der MSC (Mobilvermittlungseinrichtung) des Heimatnetzes registrieren zu lassen. Der Heimatregistrierungsserver stellt die Verfügbarkeit jedes der mehreren Netzübergangsfunktionsmodule (IWFs) im Netz (eigentlich Softwaremodule, die auf Prozessoren sowohl in der MSC als auch dem drahtlosen Hub laufen) fest und ordnet dem registrierten Endsystem IWF(s) zu. Für jedes registrierte Endsystem wird ein Tunnel (unter Verwendung des XTunnel-Protokolls) zwischen dem drahtlosen Hub in der Basisstation und einer Netzübergangsfunktion (IWF) in der Mobilvermittlungseinrichtung (MSC) erzeugt, wobei dieser Tunnel PPP-Rahmen zwischen dem Endsystem und der IWF transportiert.
  • Wie hierin verwendet, ist das XTunnel-Protokoll ein Protokoll, das einen In-Folge-Transport von PPP-Datenrahmen mit Flusssteuerung bereitstellt. Dieses Protokoll kann über standardmäßige IP-Netze oder über Punkt-zu-Punkt-Netze oder über vermittelte Netze wie ATM-Datennetze oder Rahmenweiterleitungsdatennetze laufen. Solche Netze können auf T1- oder T3- Verbindungen basieren, oder sie können auf Funkverbindungen, seien sie land- oder weltraumgestützt, basieren. Das XTunnel-Protokoll kann durch Anpassen von Algorithmen vom Schicht-2-Tunnelprotokoll L2TP (für engl. layer 2 tunneling protocol) gebildet werden. In Netzen, die auf Verbindungen basieren, in welchen verlorene Datenpakete gefunden werden können, kann ein Wiederholungssendungsmerkmal eine wünschenswerte Option sein.
  • Der PPP-Partner (d.h. ein Kommunikationsserver) des Endsystems kann in der IWF oder einem firmeneigenen Intranet oder einem ISP-Netz sitzen. Wenn der PPP-Partner in der IWF sitzt, wird ein Endsystem mit einem direkten Internetzugang versehen. Wenn der PPP-Partner in einem Intranet oder ISP sitzt, wird ein Endsystem mit einem Intranetzugang oder einem Zugang zu einem ISP versehen. Um einen Intranet- oder ISP-Zugang zu unterstützen, verwendet die IWF das Schicht-zwei-Tunnelprotokoll (L2TP) zur Verbindung mit dem Intranet- oder ISP-PPP-Server. Vom Gesichtspunkt des Intranet- oder ISP-PPP-Servers sieht die IWF wie ein Netzugangsserver (NAS für engl. network access server) aus. Der PPP-Verkehr zwischen dem Endsystem und der IWF wird durch den fremden Agenten in der Basisstation weitergeleitet.
  • In der Rückwärtsrichtung (Aufwärtsstrecke) werden PPP-Rahmen, die sich vom Endsystem zur IWF fortpflanzen, über die MAC- und Luftverbindung zur Basisstation gesendet. Die Basisstation leitet diese Rahmen unter Verwendung des XTunnel-Protokolls zur IWF in der MSC weiter. Die IWF stellt sie einem PPP-Server zur Verarbeitung zu. Für den Internetzugang kann der PPP-Server in derselben Maschine wie die IWF sein. Für einen ISP- oder Intranetzugang ist der PPP-Server in einem privaten Netz, und die IWF verwendet das Schicht-zwei-Tunnelprotokoll (L2TP) zur Verbindung damit.
  • In der Vorwärtsrichtung (Abwärtsstrecke) werden PPP-Rahmen vom PPP-Server durch die IWF unter Verwendung des XTunnel-Protokolls zur Basisstation weitergeleitet. Die Basisstation enttunnelt Abwärtsstreckenrahmen und leitet sie über die Luftverbindung zum Endsystem weiter, wo sie durch die PPP-Schicht des Endsystems verarbeitet werden.
  • Die Unterstützung der Mobilität umfasst die Unterstützung von Weiterschaltungen. Die MAC-Schicht hilft der Mobilitätsverwaltungssoftware in der Basisstation und dem Endsystem bei der wirksamen Durchführung von Weiterschaltungen. Weiterschaltungen werden von den PPP-Partnerinstanzen und dem L2TP-Tunnel transparent abgewickelt. wenn ein Endsystem sich von einer Basisstation zu einer anderen bewegt, wird ein neuer XTunnel zwischen der neuen Basisstation und der ursprünglichen IWF erzeugt. Der alte XTunnel von der alten Basisstation wird gelöscht. PPP-Rahmen durchlaufen den neuen Weg transparent.
  • Das Netz unterstützt Roaming (d.h., wenn der Endbenutzer sich durch einen fremden Drahtlosdiensteanbieter mit seinem Heimat-Drahtlosdiensteanbieter in Verbindung setzt). Durch Verwenden dieses Merkmals sind Endsysteme imstande, vom Heimatnetz in ein Fremdnetz zu wandern und dennoch versorgt zu werden, vorausgesetzt natürlich, dass der fremde Drahtlosdiensteanbieter und der Heimat-Drahtlosdiensteanbieter des Endsystems eine Dienstvereinbarung haben.
  • In 6 hat sich ein Gast-Endsystem 60 zu einem Aufenthaltsort begeben, an welchem ein fremder Drahtlosdiensteanbieter 62 die Versorgung bereitstellt. Das Gast-Endsystem 60 hat jedoch ein Teilnehmerverhältnis mit dem Heimat-Drahtlosdiensteanbieter 70. In der vorliegenden Erfindung hat der Heimat-Drahtlosdiensteanbieter 70 ein Vertragsverhältnis mit dem fremden Drahtlosdiensteanbieter 62, um Zugangsdienste bereitzustellen. Daher setzt sich das Gast-Endsystem 60 über die Luftverbindung mit der Basisstation 64 des fremden Drahtlosdiensteanbieters 62 in Verbindung. Dann werden Daten vom Gast-Endsystem 60 durch die Basisstation 64 durch die versorgende IWF 66 des fremden Drahtlosdiensteanbieters 62 zur Heimat-IWF 72 des Heimat-Drahtlosdiensteanbieters 70 oder möglicherweise durch die Heimat-IWF 72 des Heimat-Drahtlosdiensteanbieters 70 zum Internetdiensteanbieter 74 weitergeleitet.
  • Eine diensteüberschreitende Anbieterschnittstelle, genannt I-Schnittstelle, wird für Kommunikationen über Drahtlosdiensteanbieter- oder WSP-Grenzen (WSP für engl. wireless service provider) zur Unterstützung von Roaming verwendet. Diese Schnittstelle wird zum Authentifizieren, Registrieren und Transportieren der PPP-Rahmen des Endsystems zwischen dem fremden WSP und dem Heimat-WSP verwendet.
  • PPP-Rahmen in der Aufwärtsstrecken- und in der Abwärtsstreckenrichtung pflanzen sich durch den Heimat-Drahtlosdiensteanbieter (WSP) des Endsystems fort. Alternativerweise laufen PPP-Rahmen vom fremden WSP direkt zum Bestimmungsnetz durch. Die Basisstation im fremden WSP ist der Anschlusspunkt des Endsystems im Fremdnetz. Diese Basisstation sendet (und empfängt) PPP-Rahmen zu (und von) einer versorgenden IWF in der Mobilvermittlungseinrichtung des fremden WSPs. Die versorgende IWF setzt sich unter Verwendung eines Schicht-zwei-Tunnels über die I-Schnittstelle mit der Heimat-IWF in Verbindung, um die PPP-Rahmen des Endsystems in beiden Richtungen zu transportieren. Die versorgende IWF im fremden WSP sammelt Abrechnungsdaten zur Rechnungsprüfung. Die Heimat-IWF im Heimat-WSP sammelt Abrechnungsdaten für die Gebührenverrechnung.
  • Die versorgende IWF im fremden WSP kann mit der Basisstation im selben System verknüpft sein, wodurch die Notwendigkeit des X-Tunnels eliminiert wird.
  • Während der Registrierungsphase stellt ein Registrierungsserver im fremden WSP die Identität des Heimatnetzes des Gast-Endsystems fest. Unter Verwendung dieser Informationen kommuniziert der fremde Registrierungsserver mit dem Heimatregistrierungsserver, um das Endsystem zu authentifizieren und zu registrieren. Diese Registrierungsnachrichten fließen über die I-Schnittstelle. Sobald das Endsystem authentifiziert und registriert wurde, wird unter Verwendung des XTUNNEL-Protokolls ein Schicht-zwei-Tunnel zwischen der Basisstation und der versorgenden IWF erzeugt, und ein anderer Schicht-zwei-Tunnel wird zwischen der versorgenden IWF und der Heimat-IWF über den I-XTunnel erzeugt. Die Heimat-IWF setzt sich wie zuvor unter Verwendung des L2TPs (Schicht-2-Tunnelprotokolls) mit dem PPP-Partner in Verbindung. während der Weiterschaltungen bleibt der Aufenthaltsort der Heimat-IWF und des L2TP-Tunnels fest. Wenn das Endsystem sich von einer Basisstation zu einer anderen Basisstation bewegt, wird ein neuer Tunnel zwischen der neuen Basisstation und der versorgenden IWF erzeugt, und der alte Tunnel zwischen der alten Basisstation und der versorgenden IWF wird gelöscht. Wenn das Endsystem sich weit genug bewegt, so dass eine neue versorgende IWF benötigt wird, wird ein neuer I-XTunnel zwischen der versorgenden IWF und der Heimat-IWF erzeugt. Der alte Tunnel zwischen der alten versorgenden IWF und der Heimat-IWF wird gelöscht.
  • Zur Unterstützung des Roaming unterstützt die I-Schnittstelle die Authentifizierung, Registrierung und Datentransportdienste über Drahtlosdiensteanbietergrenzen. Authentifizierungs- und Registrierungsdienste werden unter Verwendung des IETF Radius-Protokolls unterstützt. Datentransportdienste zum Übertragen von PPP-Rahmen über einen Schicht-zwei-Tunnel werden unter Verwendung des I-XTunnel-Protokolls unterstützt. Dieses Protokoll basiert auf dem IETF L2TP-Protokoll.
  • Wie in dieser Beschreibung verwendet, bezieht sich der Begriff Heimat-IWF auf die IWF im Heimatnetz des Endsystems. Der Begriff versorgende IWF bezieht sich auf die IWF im Fremdnetz, welches das Endsystem vorübergehend versorgt. Ähnlich bezieht sich der Begriff Heimatregistrierungsserver auf den Registrierungsserver im Heimatnetz des Endsystems, und der Begriff fremder Registrierungsserver bezieht sich auf den Registrierungsserver im Fremdnetz, durch welchen sich das Endsystem registrieren lässt, während es wandert.
  • Das Netz unterstützt sowohl eine feste als auch eine dynamische IP-Adresszuordnung für Endsysteme. Es gibt zwei Arten von IP-Adressen, die in Betracht zu ziehen sind. Die erste ist die Identität des Endsystems in seinem Heimatnetz. Diese kann ein strukturierter Benutzername im Format user@domain sein. Diese unterscheidet sich von der Heimat-IP-Adresse, die im Mobile IP verwendet wird. Die zweite Adresse ist die IP-Adresse, die dem Endsystem über das PPP-IPC-Adressprotokoll zugeordnet wird. Das Domänenteilfeld der Heimatadresse wird verwendet, um die Heimatdomäne des Benutzers zu identifizieren, und ist ein voll qualifizierter Domänenname. Das Benutzerteilfeld der Heimatadresse wird verwendet, um den Benutzer in der Heimatdomäne zu identifizieren. Der User-Name wird auf dem Endsystem und in der Teilnehmerdatenbank an der MSC gespeichert, und er wird dem Benutzer zugeordnet, wenn er den Dienst abonniert. Das Domänenteilfeld des User-Name wird während des Roamings verwendet, um Roaming-Verhältnisse und den Heimatregistrierungsserver zum Zwecke der Registrierung und Authentifizierung zu identifizieren. Anstelle des strukturierten Benutzernamens kann eine andere eindeutige Kennung verwendet werden, um das Heimatnetz des Benutzers und der Identität des Benutzers im Heimatnetz zu identifizieren. Diese Kennung wird in der Registrierungsaufforderung durch das Endsystem gesendet.
  • Das PPP-IPCP wird verwendet, um die IP-Adresse für das Endsystem auszuhandeln. Durch Verwenden des IP-Konfigurationsprotokolls IPCP ist das Endsystem imstande, eine feste oder dynamische IP-Adresse auszuhandeln.
  • Obwohl die Verwendung des strukturierten Benutzernamensfeldes und die Nichtverwendung einer IP-Heimatadresse ein Merkmal ist, welches die vorliegende Erfindung gegenüber einem bekannten Mobile IP kennzeichnet, kann das Netz verbessert werden, um auch Endsysteme zu unterstützen, die keinen Benutzernamen und nur eine Nicht-Null-Heimat-IP-Adresse haben, wenn das Mobile IP und seine Verwendung in Verbindung mit PPP-Endsystemen gängig wird. Der PPP-Server kann durch den Diensteanbieter so konfiguriert werden, dass er während der IPCP-Adresszuordnungsphase IP-Adressen zuordnet, welche gleich sind wie die Heimat-IP-Adresse des Endsystems. In diesem Fall sind die Heimatadresse und die durch das IPCP zugeordnete IP-Adresse identisch.
  • In 7 bilden die Basisstation 64 und Luftverbindungen von Endsystemen ein drahtloses Teilnetz 80, das die Luftverbindungen für den Endbenutzerzugang, wenigstens eine Basisstation (z.B. Station 64) und wenigstens ein Backhaul-Netz (z.B. 38 von 2) von der Basisstation zur MSC 40 (2) aufweist. Die Architektur des drahtlosen Teilnetzes von zum Beispiel einer Basisstation mit drei Sektoren weist die folgenden logischen Funktionen auf:
    • 1. Zugangspunktfunktion. Zugangspunkte 82 führen MAC-Schicht-Überbrückungs- und MAC-Schicht-Assoziations- und -Dissoziationsprozeduren durch. Ein Zugangspunkt weist einen Prozessor (vorzugsweise in Form einer kundenanwendungsspezifischen integrierten Schaltung ASIC), eine Verbindung zu einem drahtlosen Hub (vorzugsweise in Form einer Ethernet-Verbindung auf einer Karte oder in die ASIC eingebaut), eine Verbindung zu einer Antenne (vorzugsweise in Form einer Karte mit einem Datenmodulator/demodulator und einem Sender/Empfänger) und die Antenne, an welche das Endsystem gekoppelt ist. Der Prozessor führt eine Software aus, um eine Datenüberbrückungsfunktion und verschiedene andere Funktionen zur Unterstützung von Registrierung und Mobilitätsweiterschaltungen, wie hierin näher beschrieben wird, auszuführen. Siehe Erörterung in Bezug auf 10, 11 und 14. Zugangspunkte (APs für engl. access points) nehmen MAC-Schicht-Rahmen von der Luftverbindung und leiten sie an einen drahtlosen Hub weiter und umgekehrt. Die MAC-Schicht-Assoziations- und – Dissoziationsprozeduren werden durch die APs verwendet, um eine Liste von Endsystem-MAC-Adressen in ihrer MAC-Adressen-Filtertabelle zu führen. Ein AP kann eine MAC-Schicht-Überbrückung nur für Endsysteme durchführen, deren MAC-Adressen in der Tabelle vorhanden sind. Ein Zugangspunkt und sein zugehöriger drahtloser Hub sind normalerweise ortsgleich untergebracht. In seiner einfachsten Form ist nur Zugangspunkt ein Port in einen drahtlosen Hub. Wenn die APs und der drahtlose Hub ortsgleich im selben Zellenstandort untergebracht sind, können sie über eine IEEE 802.3 Verbindung miteinander verbunden werden. Manchmal sind Zugangspunkte abgesetzt vom drahtlosen Hub angeordnet und über eine Weitverkehrsverbindung, wie einen drahtgebundenen T1-Trunk oder auch einen drahtlosen Trunk, angeschlossen. Für Zellen mit mehreren Sektoren werden mehrere Zugangspunkte (d.h. einer pro Sektor) verwendet.
    • 2. Drahtloshubfunktion. Der drahtlose Hub 84 führt Fremdagent- oder FA-Prozeduren, Backhaul-Lastausgleich (z.B. über mehrere T1), Backhaul-Netzanbindungen und die XTunnel-Prozeduren durch. Wenn eine Unterstützung für Dienstgüte (QOS) vorhanden ist, implementiert der drahtlose Hub die Unterstützung für QOS durch Ausführen des XTunnel-Protokolls über Backhauls mit verschiedenen QOS-Attributen. In einem Zellenstandort mit mehreren Sektoren wird eine einzige Drahtloshubfunktion normalerweise durch mehrere Zugangspunkte gemeinsam benutzt. Ein drahtloser Hub weist einen Prozessor, eine Verbindung zu einem oder mehr Zugangspunkten (vorzugsweise in Form einer Ethernet-Verbindung auf einer Karte oder in eine ASIC eingebaut) und eine Verbindung zu einer Backhaul-Leitung auf. Die Backhaul-Leitung ist normalerweise eine T1- oder T3-Kommunikationsleitung, die in der Mobilvermittlungseinrichtung des Drahtlosdiensteanbieters endet. Die Verbindung zur Backhaul-Leitung formatiert Daten in ein bevorzugtes Format, zum Beispiel ein Ethernet-Format, ein Rahmenweiterleitungsformat oder ein ATM-Format. Der Prozessor des drahtlosen Hubs führt eine Software aus, um eine Datenüberbrückung und verschiedene andere Funktionen, wie hierin beschrieben, zu unterstützen. Siehe Erörterung in Bezug auf 12. 13 und 14.
  • Die Basisstationskonstruktion unterstützt die folgenden Arten von Zellarchitekturen:
    • 1. Architektur mit lokalen APs. In einer Architektur mit lokalen APs haben Zugangspunkte eine große (normalerweise >= 2 km) Reichweite. Sie sind im Zellenstandort ortsgleich mit dem drahtlosen Hub untergebracht (4). Zugangspunkte können unter Verwendung eines IEEE 802.3 Netzes mit dem drahtlosen Hub verbunden sein, oder sie können direkt in der Rückwandplatine des drahtlosen Hubs angesteckt sein oder unter Verwendung irgendeines anderen Mechanismus (z.B. universeller serieller Bus, Druckeranschluss, Infrarot usw.) mit dem drahtlosen Hub verbunden sein. Es wird vorausgesetzt, dass die erste Alternative für den Rest dieser Erörterung verwendet wird. Der Zellenstandort kann rundstrahlend oder durch Hinzufügen von mehreren Zugangspunkten und sektorierten Antennen zu einem drahtlosen Hub sektoriert sein.
    • 2. Architektur mit abgesetzten APs. In einer Architektur mit abgesetzten APs weisen Zugangspunkte normalerweise eine sehr kleine Reichweite, normalerweise ungefähr 1 km Radius, auf. Sie sind vom drahtlosen Hub (entweder außen oder innen) abgesetzt angeordnet. Ein T1- oder ein drahtloser Trunk verbindet vorzugsweise Zugangspunkte mit dem Zellenstandort, wo der drahtlose Hub angeordnet ist. Vom Zellenstandort wird normalerweise ein Drahtleitungs-Backhaul oder eine Mikrowellenstrecke zur Verbindung mit der IWF in der MSC verwendet. Wenn ein drahtloses Trunking zwischen dem abgesetzten AP und dem drahtlosen Hub verwendet wird, werden rundstrahlende oder sektorierte Funkgeräte für das Trunking verwendet. Die Geräte für das Trunking zu abgesetzten Zugangspunkten sind vorzugsweise ortsgleich mit dem drahtlosen Hub untergebracht und können unter Verwendung eines IEEE 802.3 Netzes damit verbunden sein, oder sie können direkt in der Rückwandplatine des drahtlosen Hubs angesteckt sein. Diese Geräte werden mit dem Begriff Trunk-AP bezeichnet.
    • 3. Architektur mit gemischten APs. In einer Mischarchitektur muss das drahtlose Teilnetz abgesetzte und lokale Zugangspunkte unterstützen. Abgesetzte Zugangspunkte können zur Lochfüllung und aus anderen Kapazitätsgründen hinzugefügt werden. Wie bereits erwähnt, können T1- oder drahtlose Trunks verwendet werden, um den abgesetzten AP mit dem drahtlosen Hub zu verbinden.
  • 37 und 38 sind Systemkonfigurationsdiagramme, welche mögliche Verbindungen veranschaulichen. Für Fall (i) ist die IWF1 die Anker-IWF und dient als der Heimatagent, während der WH1 als der fremde Agent dient. Ein XTunnel wird zwischen dem WH1 und der IWF1 verwendet, und der Schicht-2-Tunnelprotokoll- oder L2TP-Tunnel wird zwischen der IWF1 und dem PPP-Server verwendet. Für Fall (ii) sind der WH und die versorgende IWF ortsgleich untergebracht. Die IWF1 ist die Anker-IWF und die versorgende IWF IWF2 dient als der fremde Agent. Ein I-XTunnel wird zwischen IWF und IWF2 verwendet, und ein L2TP-Tunnel wird zwischen IWF1 und dem PPP-Server verwendet. Für Fall (iii) ist die versorgende IWF IWF3, und die Anker-IWF ist IWF1. Ein XTunnel wird zwischen WH3 und IWF3 verwendet, ein I-XTunnel wird zwischen IWF3 und IWF1 verwendet, und ein L2TP-Tunnel wird zwischen IWF1 und dem PPP-Server verwendet.
  • 38 veranschaulicht die Hinzufügung eines drahtlosen Abschnitts (Trunk-AP), wobei der Trunk-AP mit dem WH ortsgleich untergebracht sein kann. Für diesen Fall können neben den zuvor beschriebenen drei Möglichkeiten auch die folgenden Möglichkeiten vorkommen. Für Fall (i) ist der Trunk-AP1 der fremde Agent, und IWF1 ist die Anker-IWF. Ein XTunnel wird zwischen dem Trunk-AP1 und der Anker-IWF verwendet, und ein L2TP-Tunnel wird zwischen der Anker-IWF und dem PPP-Server verwendet. Für Fall (ii) ist die versorgende IWF2 der fremde Agent. Ein XTunnel wird zwischen dem Trunk-AP2 und der IWF2 verwendet, ein I-XTunnel wird zwischen der IWF2 und der Anker-IWF1 verwendet, und ein L2TP-Tunnel wird zwischen der Anker-IWF und dem PPP-Server verwendet. Für Fall (iii) ist die versorgende IWF der fremde Agent. Ein XTunnel wird zwischen dem Trunk-AP3 und der IWF3 verwendet, ein I-XTunnel wird zwischen IWF3 und der Anker-IWF1 verwendet, und ein L2TP-Tunnel wird zwischen der Anker-IWF1 und dem PPP-Server verwendet.
  • 39 bis 42 veranschaulichen mehrere Weiterschaltungsszenarien, sowie verschiedene Verbindungen zwischen den Elementen des Systems.
  • 8 stellt eine Zelle mit drei Sektoren dar, die nur lokale APs verwenden. Die Zugangspunkte und der drahtlose Hub sind ortsgleich in der Basisstation untergebracht und mit 802.3 Verbindungen miteinander verbunden.
  • 9 stellt die Architektur mit abgesetzten Zugangspunkten 82 dar, die unter Verwendung von drahtlosen Trunks 86 mit dem drahtlosen Hub 84 verbunden sind. Jeder Trunk-Zugangspunkt in der Basisstation stellt eine drahtlose Punkt-zu-Mehrpunkt-Funkverbindung zu abgesetzten Mikro-Zugangspunkten (R-AP in der Figur) bereit. Die abgesetzten Zugangspunkte stellen einen Luftverbindungsdienst zu Endsystemen bereit. Der drahtlose Hub und die Trunk-Zugangspunkte sind ortsgleich in der Bassstation untergebracht und über 802.3 Verbindungen miteinander verbunden. Diese Figur stellt auch abgesetzte Zugangspunkte 82R dar, die über Punkt-zu-Punkt-T1-Verbindungen mit dem drahtlosen Hub verbunden sind. In diesem Szenarium sind keine Trunk-APs erforderlich.
  • Zur Unterstützung aller zuvor beschriebenen Zellarchitekturen und der verschiedenen Arten von Zugangspunkten, die jede Zelle verwenden könnte, befolgt die Netzarchitektur folgende Regeln:
    • 1. Zugangspunkte fungieren als MAC-Schicht-Brücken. Abgesetzte Zugangspunkte führen eine MAC-Überbrückung zwischen der Luftverbindung zu den Endsystemen und dem drahtlosen oder T1-Trunk zum Zellenstandort durch. Lokale Zugangspunkte führen eine MAC-Überbrückung zwischen der Luftverbindung zu den Endsystemen und dem drahtlosen Hub durch.
    • 2. Trunk-Zugangspunkte fungieren ebenfalls als MAC-Schicht-Brücken. Sie führen eine MAC-Überbrückung zwischen dem Trunk (welcher zu den Zugangspunkten geht) und dem drahtlosen Hub durch.
    • 3. Der drahtlose Hub wird mit allen ortsgleich untergebrachten MAC-Brücken (d.h. lokalen Zugangspunkten oder Trunk-Zugangspunkten) verbunden, wobei anfänglich eine 802.3 Verbindung verwendet wird.
  • Wenn lokale Zugangspunkte oder abgesetzte Zugangspunkte mit T1-Trunks verwendet werden, werden außerdem die folgenden Regeln befolgt:
    • 1. Lokale Zugangspunkte werden mit dem drahtlosen Hub ortsgleich untergebracht und unter Verwendung von 802.3 Punkt-zu-Punkt-Verbindungen oder einem gemeinsam benutzten 802.3 Netz damit verbunden. Abgesetzte Zugangspunkte werden unter Verwendung von Punkt-zu-Punkt-T1-Trunks mit dem drahtlosen Hub verbunden.
    • 2. Die Sektorisierung wird durch Hinzufügen von Zugangspunkten mit sektorierten Antennen zum Zellenstandort unterstützt.
    • 3. Für jeden Zugangspunkt, der mit dem drahtlosen Hub verbunden ist, gibt es einen fremden Agenten, der im drahtlosen Hub läuft, der an der Endsystemregistrierung teilnimmt. MAC-Schicht-Assoziationsprozeduren werden verwendet, um die MAC-Adressen-Filtertabellen der Zugangspunkte auf dem Laufenden zu halten und die MAC-Schicht-Überbrückung wirksam durchzuführen. Der drahtlose Hub nimmt an den MAC-Assoziationsfunktionen teil, so dass nur gültige MAC-Adressen den MAC-Adressen-Filtertabellen der Zugangspunkte hinzugefügt werden.
    • 4. Der drahtlose Hub leitet Rahmen von den Zugangspunkten unter Verwendung des XTunnel-Protokolls zur MSC-IWF und umgekehrt, sofern die IWF nicht mit dem drahtlosen Hub ortsgleich untergebracht ist. Die MAC-Adressen-Filtertabelle wird verwendet, um jene Punkt-Punkt-MAC-Kommunikationsdatenrahmen auszufiltern, deren MAC-Adressen in der Tabelle nicht vorhanden sind. Die APs senden MAC-Rundsenderahmen und MAC-Rahmen, die mit der Endsystemregistrierungsfunktion verbunden sind, stets ungeachtet der Inhalte der MAC-Adressen-Filtertabelle weiter.
    • 5. Lokale Zugangspunkte verwenden das ARP zur Auflösung von MAC-Adressen, um den IP-Verkehr zum drahtlosen Hub zu leiten. Umgekehrt verwendet auch der drahtlose Hub das ARP, um IP-Pakete zu Zugangspunkten zu leiten. Das UDP/IP wird zur Netzverwaltung von Zugangspunkten verwendet.
    • 6. Abgesetzte Zugangspunkte, die über T1 angeschlossen sind, verwenden kein ARP, da die Verbindung eine Punkt-zu-Punkt-Verbindung ist.
    • 7. Die Unterstützung für Weiterschaltungen erfolgt mit Hilfe von der MAC-Schicht.
  • In einer Zellarchitektur, die drahtlose Trunks und Trunk-APs verwendet, werden die folgenden Regeln befolgt
    • 1. Trunk-Zugangspunkte werden ortsgleich mit dem drahtlosen Hub untergebracht und unter Verwendung von 802.3 Punkt-zu-Punkt-Verbindungen oder anderen geeigneten Mitteln damit verbunden.
    • 2. Die Sektorisierung drahtloser Trunks wird durch Hinzufügen von Trunk-Zugangspunkten mit sektorierten Antennen zum Zellenstandort unterstützt.
    • 3. Weiterschaltungen über Backhaul-Sektoren erfolgen unter Verwendung des fremden Agenten im drahtlosen Hub. Für jeden Backhaul-Sektor gibt es einen fremden Agenten, der im drahtlosen Hub läuft.
    • 4. Die Trunk-APs brauchen nicht an den MAC-Schicht-Endsystem-Assoziations- und -Weiterschaltungsprozeduren teilzunehmen. Ihre MAC-Adressen-Filtertabellen werden durch den drahtlosen Hub dynamisch programmiert, wenn Endsysteme sich beim Netz registrieren lassen. Die MAC-Adressen-Filtertabelle wird verwendet, um Punkt-Punkt-MAC-Kommunikationsrahmen auszufiltern. MAC-Rundesenderahmen oder MAC-Rahmen, die Registrierungspakete enthalten, werden stets durchgelassen.
    • 5. Trunk-APs verwenden das ARP zur Auflösung von MAC-Adressen, um den IP-Verkehr zum drahtlosen Hub zu leiten. Umgekehrt verwendet der drahtlose Hub das ARP, um IP-Pakete zu Trunk-APs zu leiten. Das UDP/IP wird zur Netzverwaltung von Trunk-APs verwendet.
    • 6. In einem einzelnen drahtlosen Trunk-Sektor erfolgen MAC-Assoziation und -Weiterschaltungen von einem Zugangspunkt zu einem anderen unter Verwendung der MAC-Schicht mit Unterstützung des fremden Agenten im drahtlosen Hub. Durch Verwenden dieser MAC-Schicht-Prozeduren assoziieren Endsysteme sich mit Zugangspunkten. Wenn Endsysteme sich von einem Zugangspunkt zu einem anderen Zugangspunkt bewegen, verwenden die Zugangspunkte ein MAC-Weiterschaltungsprotokoll, um ihre MAC-Adressen-Filtertabellen zu aktualisieren. Der drahtlose Hub am Zellenstandort unterstützt die Zugangspunkte bei der Durchführung dieser Funktion. Diese Unterstützung umfasst das Weiterleiten von MAC-Schicht-Weiterschaltungsnachrichten (da Zugangspunkte nicht imstande sind, direkt über die MAC-Schicht miteinander zu kommunizieren) und Authentifizieren des Endsystems zur MAC-Schicht-Registrierung und -Weiterschaltung und zur Aktualisierung der MAC-Adressen-Filtertabellen der Zugangspunkte.
    • 7. Der fremde Agent für einen drahtlosen Trunk-Sektor ist für die Weiterleitung von Rahmen von seinem Trunk-AP zur MSC und umgekehrt unter Verwendung des XTunnel-Protokolls verantwortlich. Demnach interessiert sich der fremde Agent für einen Trunk-AP nicht für den Aufenthaltsort des Endsystems in Bezug auf Zugangspunkte innerhalb dieses drahtlosen Trunk-Sektors. In der Abwärtsstreckenrichtung übermittelt er nur Rahmen vom Mobile-IP-Tunnel an den entsprechenden Trunk-AP, welcher eine MAC-Schicht-Überbrückung verwendet, um die Rahmen an alle abgesetzten Zugangspunkte zu senden, die an diesen Backhaul-Sektor angeschlossen sind. Die Zugangspunkte konsultieren ihre MAC-Adressen-Filtertabellen und leiten die MAC-Rahmen entweder über das Zugangsnetz weiter oder löschen die MAC-Rahmen. Wie bereits erwähnt, werden die MAC-Adressen-Filtertabellen unter Verwendung der MAC-Schicht-Assoziations- und -Weiterschaltungsprozeduren auf dem Laufenden gehalten. In der Aufwärtsstreckenrichtung werden MAC-Rahmen durch die Zugangspunkte zur Backhaul-Brücke weitergesendet, welche sie unter Verwendung der 802.3 Verbindung an den fremden Agenten im drahtlosen Hub übermittelt.
    • 8. Das ARP wird nicht zum Senden oder Empfangen von IP-Paketen zu den abgesetzten Zugangspunkten verwendet. Die Trunk-Zugangspunkte stellen die MAC-Adresse des drahtlosen Hubs unter Verwendung von BOOTP-Prozeduren fest. Umgekehrt ist der drahtlose Hub mit der MAC-Adresse von abgesetzten Zugangspunkten konfiguriert. Das UDP/IP wird zur Netzverwaltung von Zugangspunkten und für Endsystem-Assoziations- und -Weiterschaltungsnachrichten verwendet.
  • IEEE 802.3 Srecken im Zellenstandort können durch schnellere Verbindungen ersetzt werden.
  • 10 stellt den Protokollstapel für einen lokalen Zugangspunkt dar. An der Basis des Stapels ist die physikalische Schicht PHY. Die physikalische Schicht PHY überträgt Daten zu und von einem Endsystem über die Luft unter Verwendung von Funkwellen als ein Beispiel.
  • Wenn von einem Endsystem empfangen, empfängt der AP Daten von der physikalischen Schicht und packt sie aus den MAC-Rahmen (der MAC-Schicht) aus. Die Endsystemdatenrahmen werden dann wieder in ein physikalisches Ethernet-Schichtformat (IEEE 802.3 Format) verpackt, wobei sie über die Ethernet-Verbindung zum drahtlosen Hub gesendet werden. Wenn der AP-Prozessor Daten vom drahtlosen Hub über seine Ethernet-Verbindung (d.h. die physikalische Schicht), die Daten, die an ein Endsystem zu übertragen sind, empfängt, verpackt der AP die Daten in ein Medienzugriffssteuerungs- oder MAC-Format und sendet die MAC-Schicht-Daten an seinen Modulator, damit sie unter Verwendung der PHY-Schicht an das Endsystem übertragen werden.
  • In 11 sind die MAC- und die PHY-Schicht zum/vom Endsystem von 10 durch eine MAC und eine PHY für den Trunk zum Zellenstandort für einen abgesetzten Zugangspunkt ersetzt. Konkret wird für einen T1-Trunk vorzugsweise das höhere Datenübertragungssteuerungs- oder HDLC-Protokoll (für engl. high level data link control protocol) über die T1 verwendet.
  • 12 zeigt den Protokollstapel für den drahtlosen Hub, der die Backhaul-Leitung und den Trunk zum abgesetzten Zugangspunkt zusammenschaltet. Der Trunk zu den abgesetzten Zugangspunkten wird nur zur Unterstützung von abgesetzten Zugangspunkten benötigt (im Unterschied zum Ethernet, das mit Zugangspunkten gekoppelt ist). Die MAC- und die PHY-Schicht für den drahtlosen Trunk zu den abgesetzten APs stellen eine Punkt-zu-Mehrpunkt-Verbindung bereit, so dass ein Trunk verwendet werden kann, um mit vielen abgesetzten APs im selben Sektor zu kommunizieren.
  • Der drahtlose Hub schaltet den Trunk zu den abgesetzten APs und die Backhaul-Leitung (z.B. T1 oder T3) zur Mobilvermittlungseinrichtung (MSC) des Netzes zusammen.
  • Der Protokollstapel im drahtlosen Hub implementiert MAC- und PHY-Schichten zur MSC, worüber eine IP-Schicht (Internetprotokoll) implementiert ist, worüber eine universelle Datagrammprotokoll- oder UDP-Schicht (für engl. Universelles Datagrammprotokoll) zur Netzverwaltung implementiert ist (die zusammen als UDP/IP bezeichnet werden), worüber ein XTunnel-Protokoll implementiert ist. Das XTunnel-Protokoll ist ein neues Format, das Aspekte von Mobilität (z.B. wie im Mobile IP) und Aspekte des Schicht-2-Tunnelprotokolls (L2TP) umfasst. Das XTunnel-Protokoll wird verwendet, um vom drahtlosen Hub mit der MSC und zwischen Netzübergangsfunktionen (IWFs) in verschiedenen Netzen oder demselben Netz zu kommunizieren.
  • In 13 ist der Protokollstapel für die Relaisfunktion in der Basisstation zur Unterstützung von abgesetzten Zugangspunkten dargestellt. Die Relaisfunktion weist eine Schnittstelle mit der Backhaul-Leitung (dargestellt als der drahtlose Hub) und eine Schnittstelle mit dem abgesetzten AP (dargestellt als ein Trunk-AP) auf. Vom Gesichtspunkt des drahtlosen Hubs verhält sich der Trunk-AP (dargestellt in 13) eigentlich wie ein AP, der in 10 dargestellt ist. Vorzugsweise werden die Basisstationsprotokollstapel in einen drahtlosen Hub und einen Trunk-AP mit einem Ethernet dazwischen aufgeteilt. In einem drahtlosen Trunk mit N Sektoren gibt es N drahtlose Trunk-APs im Zellenstandort und einen drahtlosen Hub.
  • In 14 ist der Basisstationsprotokollstapel für eine Zellarchitektur dargestellt, die einen lokalen AP verwendet. Die Relaisfunktion weist eine Schnittstelle mit der Backhaul-Leitung (dargestellt als der drahtlose Hub) und eine Luftverbindungsschnittstelle mit dem Endsystem (dargestellt als ein AP) auf. Vom Gesichtspunkt des drahtlosen Hubs verhält sich der AP (dargestellt in 11 und 14) eigentlich wie der Trunk-AP, der in 11 dargestellt ist. Vorzugsweise werden die Basisstationsprotokollstapel in einen drahtlosen Hub und einen Trunk-AP mit einem Ethernet dazwischen aufgeteilt. In einer Zelle mit N Sektoren gibt es N Zugangspunkte und einen einzigen drahtlosen Hub.
  • Das Backhaul-Netz von der Basisstation zur MSC hat die folgenden Attribute:
    • 1. Das Netz ist zum Weiterleiten von IP-Datagrammen zwischen der Basisstation und der MSC imstande.
    • 2. Das Netz ist sicher. Es ist kein öffentliches Netz. Auf dem Netz ist nur Verkehr von zuverlässigen Knoten erlaubt, da das Netz nicht nur zum Transportieren von Endsystemverkehr, sondern auch zum Transportieren von Authentifizierungs-, Abrechnungs-, Registrierungs- und Verwaltungsverkehr verwendet wird.
    • 3. Das Netz weist die notwendigen Leistungscharakteristiken auf.
    • 4. Die Basisstationen unterstützen IP über Ethernet-Verbindungen.
  • In einer typischen Anwendung ist der Diensteanbieter für die Installation und die Wartung des Backhaul-Netzes, auf welchem die Betriebsmittel installiert sind, verantwortlich.
  • Die Basisstationen unterstützen die folgenden Backhaul-Schnittstellen zum Kommunizieren mit der MSC:
    • 1. Die Basisstationen unterstützen IP über PPP mit HDLC-Verbindungen unter Verwendung von Punkt-zu-Punkt-T1- oder fraktionalen T3-Verbindungen.
    • 2. Die Basisstationen unterstützen IP über Rahmenweiterleitung unter Verwendung von T1- oder fraktionalen T3-Verbindungen.
    • 3. Die Basisstationen unterstützen IP über AAL5/ATM unter Verwendung von T1- oder fraktionalen T3-Verbindungen.
  • Da alle der zuvor erwähnten Schnittstellen auf IETF-Standardkapselungen basieren, können handelsübliche Router in der MSC verwendet werden, um die physikalischen Verbindungen des Backhaul-Netzes zu beenden. Höhere Schichten werden durch die verschiedenen Server und andere Prozessoren weitergegeben und verarbeitet.
  • Endsystemregistrierungsprozeduren über die MAC-Schicht werden unterstützt. Im Folgenden werden Endsystemregistrierungsprozeduren auf der MAC-Schicht ignoriert, ausgenommen, sie beeinflussen die Schichten darüber.
  • Endsysteme können sich für einen Dienst auf ihrem Heimatnetz oder von einem Fremdnetz registrieren lassen. In beiden Szenarien verwendet das Endsystem einen fremden Agenten (FA) in der Basisstation, um einen Anschlusspunkt ans Netz zu ermitteln und sich registrieren zu lassen. Im ersteren Fall ist der FA im Heimatnetz des Endsystems. Im letzteren Fall ist der FA in einem Fremdnetz. In jedem Fall verwendet das Netz eine IWF im Heimatnetz des Endsystems als einen Ankerpunkt (d.h. unveränderlich während der ganzen Sitzung trotz Mobilität). PPP-Rahmen zum und vom Endsystem pflanzen sich über den FA in der Basisstation zur IWF im Heimatnetz fort. Wenn das Endsystem zu Hause ist, wird die Heimat-IWF mittels des XTunnel-Protokolls direkt mit der Basisstation verbunden. Es ist zu erwähnen, dass die Heimat-IWF mit der Basisstation auf dieselbe Weise verknüpft werden kann. Wenn das Endsystem wandert, wird eine versorgende IWF im Fremdnetz über eine I-Schnittstelle mit der Heimat-IWF verbunden. Die versorgende IWF leitet Rahmen zwischen der Basisstation und der Heimat-IWF weiter. Es ist zu erwähnen, dass auch die versorgende IWF mit der Basisstation auf dieselbe Weise verknüpft werden kann. von der Heimat-IWF werden Daten unter Verwendung des L2TP-Protokolls an einen PPP-Server, der in derselben IWF sitzen kann, oder an einen getrennten Server gesendet. Der getrennte Server kann einem Privatnetzbetreiber (z.B. ISP oder firmeneigenem Intranet) gehören und von diesem betrieben werden, der vom Drahtlosdiensteanbieter verschieden ist. Für die Dauer der Sitzung bleibt der Aufenthaltsort der Heimat-IWF und des PPP-Servers fest. Wenn das Endsystem sich während der Verbindung bewegt, muss es sich mit einem neuen fremden Agenten neu registrieren lassen. Es werden jedoch weiter dieselbe Heimat-IWF und derselbe PPP-Server verwendet. Ein neuer XTunnel wird zwischen dem neuen FA und der IWF erzeugt, und der alte XTunnel zwischen dem alten fremden Agenten und der IWF wird zerstört.
  • 15 stellt diese Netzkonfiguration für zwei Endsysteme A und B dar, deren beider drahtloses Heimatnetz der Drahtlosdiensteanbieter A (WSP-A) ist. Ein Endsystem wird vom drahtlosen Heimatnetz registriert, und das andere von einem drahtlosen Fremdnetz. Die Heimat-IWF im WSP-A dient als der Ankerpunkt für beide Endsysteme. Für beide Endsysteme werden Daten zur Heimat-IWF weitergeleitet. Die Heimat-IWF setzt sich mit einem Internetdiensteanbieter-PPP-Server in Verbindung, welcher dem ISP-A gehört.
  • Hierbei wird vorausgesetzt, dass beide Endsysteme ein Abonnement beim selben ISP haben. Wenn dies nicht der Fall wäre, dann würde die Heimat-IWF so dargestellt, dass sie auch mit einem anderen ISP verbunden wäre.
  • Innerhalb des Netzes eines Drahtlosdiensteanbieters werden Daten zwischen Basisstationen und der IWF unter Verwendung des XTunnel-Protokolls übertragen. Daten zwischen der IWF und dem PPP-Server werden unter Verwendung des Schicht-2-Tunnelprotokolls (L2TP) übertragen. Daten zwischen der versorgenden IWF und der Heimat-IWF werden unter Verwendung des I-XTunnel-Protokolls übertragen.
  • In einem einfachen Szenarium kann für einen Benutzer in seinem Heimatnetz, der einen festen Dienst anfordert, die Heimat-IWF-Funktion in der Basisstation dynamisch ausgelöst werden. Außerdem kann die versorgende IWF-Funktion für einen Gastbenutzer in der Basisstation aktiviert werden.
  • Stets eine IWF im Heimatnetz zu verwenden, hat seine Vor- und Nachteile. Ein offensichtlicher Vorteil ist Einfachheit. Ein Nachteil ist, dass ständig Daten zu und von einer möglicherweise entfernten Heimat-IWF weitergeleitet werden müssen. Die Alternative ist, sämtliche notwendigen Informationen an die versorgende IWF zu senden, damit sie sich mit dem ISP/Intranet des Endsystems in Verbindung setzen kann, und damit die versorgende IWF Abrechnungsinformationen in Fastechtzeit zurück zum Abrechnungsserver im Heimatnetz senden kann. Diese Funktionalität ist komplexer zu implementieren, aber wirksamer, da sie die Notwendigkeit verringert, Daten über potenziell lange Entfernungen vom Fremdnetz zum Heimatnetz weiterleiten zu müssen.
  • Man betrachte zum Beispiel den Fall eines Benutzers, der von Chicago nach Hongkong wandert. Wenn das Heimatnetz des Benutzers in Chicago ist und der Benutzer sich unter Verwendung eines Drahtlosdienstanbieters in Hongkong registrieren lässt, dann ist in der ersten Konfiguration die Heimat-IWF in Chicago der Ankerpunkt, und alle Daten müssen von Hongkong nach Chicago und umgekehrt weitergeleitet werden. Die Heimat-IWF in Chicago setzt sich mit dem ISP des Benutzers in Chicago in Verbindung. Bei der zweiten Konfiguration wird dem Endsystembenutzer ein ISP in Hongkong zugeordnet. Demnach müssen die Daten nicht ständig zwischen Chicago und Hongkong hin- und hergeleitet werden. In der zweiten Konfiguration dient die versorgende IWF als der Anker und ändert sich für die Dauer der Sitzung nie, selbst wenn das Endsystem sich bewegt. Der Aufenthaltsort des FAs kann sich jedoch infolge einer Endsystembewegung in Hongkong ändern.
  • 16 stellt die zweite Konfiguration dar. In dieser Figur ist WSP-A das Heimatnetz für das Endsystem A und B. Das Endsystem A lässt sich von seinem Heimatnetz unter Verwendung seiner Heimat-IWF als Ankerpunkt registrieren und setzt sich unter Verwendung des ISP-PPP-Servers auch mit seinem ISP-A in Verbindung. Das Endsystem B lässt sich vom Fremdnetz von WSP-B registrieren und verwendet eine versorgende IWF, welche als der Ankerpunkt dient und das Endsystem unter Verwendung des ISP-PPP-Servers mit einem ISP verbindet. In dieser Konfiguration müssen Daten für das Endsystem B nicht vom Fremdnetz zum Heimatnetz und umgekehrt weitergeleitet werden.
  • Damit diese Konfiguration funktioniert, muss es nicht nur Roaming-Vereinbarungen zwischen den fremden und Heimat- Drahtlosdiensteanbietern geben, sondern es muss auch Vereinbarungen zwischen dem fremden Drahtlosdiensteanbieter und dem Internetdiensteanbieter des Endsystems direkt oder durch einen Vermittler geben. In dem zuvor dargelegten Beispiel muss nicht nur der Drahtlosdiensteanbieter in Hongkong eine Geschäftsvereinbarung mit dem Drahtlosdiensteanbieter in Chicago haben, sondern der WSP in Hongkong muss auch eine Geschäftsvereinbarung mit dem Chicagoer ISP des Benutzers und Zugang zum Chicagoer ISP-PPP-Server in Hongkong oder eine Geschäftsvereinbarung mit einem anderen ISP vor Ort in Hongkong haben, der eine Geschäftsvereinbarung für Roaming mit dem Chicagoer ISP des Benutzers hat. Außerdem muss der WSP in Hongkong imstande sein, diese Roaming-Verhältnisse dynamisch zu ermitteln, um eine Benutzer-Authentifizierung und -Abrechnung durchzuführen und die geeigneten Tunnel aufzubauen.
  • Es ist schwierig für diese Unternehmen, die im Internetinfrastrukturgeschäft sind, geeignete Standards in der IETF für all diese Szenarien auszuarbeiten. Demnach ist eine bevorzugte Ausführungsform für die vorliegende Erfindung, die einfachere, potenziell weniger wirksame Konfiguration zu implementieren, wobei die IWF im Heimatnetz stets als der Ankerpunkt verwendet wird. Bei Vorhandensein einer geeigneten Industriestandardisierung von Protokollen für das Internet-Roaming sollte die zweite Konfiguration als gleichwertige oder alternative Ausführungsform betrachtet werden.
  • Ein Endsystem muss sich beim drahtlosen Netz registrieren lassen, bevor es das PPP starten und Daten senden und empfangen kann. Das Endsystem durchläuft zuerst die FA-Ermittlungs- und -Registrierungsphasen. Diese Phasen authentifizieren und registrieren das Endsystem für den Drahtlosdiensteanbieter. Sobald diese Phasen vorüber sind, startet das Endsystem das PPP. Dies umfasst die PPP-Verbindungsherstellungsphase, die PPP-Authentifizierungsphase und die PPP-Netzsteuerungsprotokollphase. Sobald diese Phasen vorüber sind, ist das Endsystem imstande, IP-Pakete unter Verwendung des PPPs zu senden und zu empfangen.
  • Die folgende Erörterung geht davon aus, dass das Endsystem wandert und sich von einem Fremdnetz registrieren lässt. Während der FA-Ermittlungsphase wartet das Endsystem (durch seinen Benutzerregistrierungsagenten) auf eine Ankündigung vom fremden Agenten oder ruft sie bei diesem ab. Der Benutzerregistrierungsagent verwendet Ankündigungsnachrichten, die durch einen nahe gelegenen fremden Agenten gesendet werden, um die Identität des FAs zu ermitteln, und zum Registrieren. Während dieser Phase wählt der Benutzerregistrierungsagent des Endsystems einen FA aus und gibt eine Registrierungsaufforderung an ihn aus. Der FA, der als ein Proxy-Registrierungsagent agiert, übermittelt die Registrierungsaufforderung an seinen Registrierungsserver (den Registrierungsserver im fremden WSP). Der Registrierungsserver verwendet den User-Name aus der Aufforderung des Benutzerregistrierungsagenten, um das Heimatnetz des Endsystems zu bestimmen, und übermittelt die Registrierungsaufforderung zur Authentifizierung an einen Registrierungsserver im Heimatnetz. Nach Empfang der Registrierungsaufforderung, die durch den fremden Registrierungsserver weitergeleitet wurde, authentifiziert der Heimatregistrierungsserver die Identität des fremden Registrierungsservers, und er authentifiziert auch die Identität des Endsystems. Wenn die Authentifizierung und die Registrierung erfolgreich sind, wählt der Heimatregistrierungsserver eine IWF im Heimatnetz aus, um eine I-XTunnel-Verbindung zwischen der Heimat-IWF und der versorgenden IWF (im fremden WSP) zu erzeugen. Die IWF im Heimatnetz dient für die Dauer der PPP-Sitzung als der Ankerpunkt.
  • Sobald die Authentifizierungs- und Registrierungsphasen vorüber sind, werden die verschiedenen PPP-Phasen gestartet. Beim Start des PPPs wird zwischen der Heimat-IWF und dem angeforderten ISP/Intranet-PPP-Server eine L2TP-Verbindung hergestellt. In der PPP-Authentifizierungsphase werden unter Verwendung von PAP oder CHAP PPP-Passwörter ausgetauscht, und der ISP- oder Intranet-PPP-Server authentifiziert unabhängig die Identität des Endsystems.
  • Sobald dies gelingt, wird die PPP-Netzsteuerungsphase gestartet. In dieser Phase wird eine IP-Adresse ausgehandelt und durch den PPP-Server dem Endsystem zugeordnet, und es wird die Verwendung einer TCP/IP-Kopf-Kompression ausgehandelt. Wenn dies abgeschlossen ist, ist das Endsystem imstande, IP-Pakete unter Verwendung des PPPs zu seinem ISP oder einem firmeneigenes Intranet zu senden und zu empfangen.
  • Es ist zu erwähnen dass zwei Authentifizierungsstufen durchgeführt werden. Die Authentifizierung authentifiziert die Identität des Endsystems für den Registrierungsserver im Heimatnetz und die Identitäten des Fremdnetzes und des Heimatnetzes untereinander. Zur Durchführung dieser Funktion übermittelt der fremde Agent die Registrierungsaufforderung des Endsystems zum Beispiel unter Verwendung eines IETF Radius-Protokolls in einem Radius Access-Request- oder Radius-Zugangsanforderungs-Paket an einen Registrierungsserver in seiner lokalen MSC. Durch Verwenden des Domänennamens des Endsystems bestimmt der fremde Registrierungsserver die Identität des Heimatnetzes und des Heimatregistrierungsservers des Endsystems und verkapselt und übermittelt als ein Radius-Proxy agierend die Anforderung an den Heimatregistrierungsserver des Endsystems. Wenn der fremde Registrierungsserver die Identität der Heimat des Endsystems nicht feststellen kann, kann er die Radius-Anforderung optional an einen Registrierungsserver übermitteln, der wie ein Makler agiert (z.B. einer, der einem Konsortium von Drahtlosdiensteanbietern gehört), welcher die Radius Access-Request seinerseits zum Endheimatregistrierungsserver durchreicht. Wenn der lokale Registrierungsserver außerstande ist, die Registrierungsaufforderung lokal oder durch Durchreichen zu versorgen, dann weist er die Registrierungsaufforderung des fremden Agenten ab, und der fremde Agent weist die Registrierungsaufforderung des Endsystems ab. Bei Empfang der Radius Access-Request führt der Heimatregistrierungsserver die erforderliche Authentifizierung der Identitäten des Fremdnetzes und des Endsystems durch. Wenn die Authentifizierung und die Registrierung erfolgreich sind, antwortet der Heimatregistrierungsserver mit einem Radius Access-Response-Radius-Zugangsantwort-Paket an fremden Registrierungsserver, der eine Antwort an den fremden Agenten sendet, so dass ein Umlauf abgeschlossen werden kann. Die Registrierungsaufforderung wird abgewiesen, wenn der Heimatregistrierungsserver aus irgendeinem Grund außerstande ist, zu entsprechen.
  • Die zweite Authentifizierungsstufe überprüft die Identität des Endsystems für den Intranet- oder ISP-PPP-Server. Eine von der Mobilitätsauthentifizierung getrennte PPP-Authentifizierung ermöglicht es, die Infrastrukturbetriebsmittel getrennt vom ISP einzusetzen und zu besitzen.
  • 17 ist ein Leiterdiagramm, das die Registrierungsfolge für ein Gast-Endsystem darstellt. Es wird davon ausgegangen, dass der PPP-Server und die Heimat-IWF im selben Server sind und kein L2TP benötigt wird. Man beachte die Interaktionen mit Abrechnungsservern, um mit der Abrechnung für das zu registrierende Endsystem zu beginnen, sowie mit Verzeichnisservern, um die Identität des Heimatregistrierungsserver zu bestimmen und die Identität des Endsystems zu authentifizieren. Nähere Informationen über Abrechnung, Gebührenverrechnung, Roaming (zwischen Diensteanbietern) und Zahlung werden im Folgenden bereitgestellt.
  • MAC-Schicht-Nachrichten vom Benutzerregistrierungsagenten des Endsystems können verwendet werden, um einen Agent Solicitation oder Agentenabruf einzuleiten. Die MAC-Schicht-Nachrichten sind der Klarheit halber nicht dargestellt.
  • In 17 ruft das Endsystem (Mobileinheit) anfänglich eine Ankündigung ab, und der fremde Agent antwortet mit einer Ankündigung, die das Endsystem mit Informationen über das Netz, zu welchem der fremde Agent gehört, einschließlich einer Gastadresse des fremden Agenten versieht. Alternativerweise kann diese Phase weggelassen werden, und sämtliche Netzankündigungen können durch eine kontinuierlich ausgegebene MAC-Schicht-Bakennachricht erfolgen. In diesem Fall wird davon ausgegangen, dass das Netz ein fremder Drahtlosdiensteanbieter ist. Dann nimmt ein Benutzerregistrierungsagent (im Endsystem) die Informationen über den fremden Agenten (welche den Benutzernamen und andere Sicherheitsnachweise enthalten) und sein Netz in eine Aufforderung auf und sendet die Aufforderung an den fremden Agenten. Der fremde Agent als ein Proxy-Registrierungsagent leitet die Aufforderung an den fremden Registrierungsserver (d.h. den Registrierungsserver für den fremden Drahtlosdiensteanbieter) weiter. Dann greift der fremde Registrierungsserver, der erkennt, dass es sich nicht um das Heimatverzeichnis handelt, auf den fremden Verzeichnisserver mit dem FDD im fremden Drahtlosdiensteanbieter zu, um zu erfahren, wie er die Registrierungsaufforderung zum Heimatregistrierungsserver des Drahtlosdiensteanbieter, zu welchem das Endsystem gehört, leiten soll. Der fremde Registrierungsserver antwortet mit den erforderlichen Übermittlungsnachrichten. Dann kapselt der fremde Registrierungsserver die Registrierungsaufforderung des Endsystems in einer Radius-Zugangsanforderung ein und leitet die eingekapselte Anforderung an den Heimatregistrierungsserver des Drahtlosdiensteanbieters, zu welchem das Endsystem gehört. Der Heimatregistrierungsserver greift auf den Heimatverzeichnisserver mit dem HDD des Heimatregistrierungsservers zu, um wenigstens Authentifizierungsinformationen über den fremden Diensteanbieter zu erfahren. Optional greift der Heimatregistrierungsserver auf das Teilnehmerverzeichnis zu, um detaillierte Teilnehmerdienstprofilinformationen (z.B. abonnierte Dienstgüteoptionen usw.) zu erfahren. Wenn alle Partner authentifiziert sind, sendet der Heimatregistrierungsserver eine IWF-Start-Aufforderung an die Heimat-IWF und den PPP-Server. Die Heimat-IWF und der PPP-Server starten den Heimatabrechnungsserver und senden dann eine IWF-Start-Antwort an den Heimatregistrierungsserver. Der Heimatregistrierungsserver sendet dann eine Radius-Zugangsantwort an den fremden Registrierungsserver. Der fremde Registrierungsserver sendet dann eine IWF-Start-Aufforderung an den Server der versorgenden IWF. Der Server der versorgenden IWF startet den versorgenden Abrechnungsserver und sendet dann eine IWF-Start-Antwort an den fremden Registrierungsserver. Der fremde Registrierungsserver sendet eine Registrierungsantwort an den fremden Agenten, und der fremde Agent leitet die Registrierungsantwort an das Endsystem weiter.
  • Eine Übertragungssteuerungsprotokoll- oder LCP-Konfigurationsaufforderung (LCP für engl. link control protocol) wird vom Endsystem durch den fremden Registrierungsserver an die Heimat-IWF und den PPP-Server gesendet. Die Heimat-IWF und der PPP-Server senden eine LCP-Konfigurationsbestätigung durch den fremden Registrierungsserver an das Endsystem.
  • Ähnlich wird eine Passwortauthentifizierungsprotokoll- oder PAP-Authentifizierungsaufforderung durch die Heimat-IWF und den PPP-Server gesendet und bestätigt.
  • Alternativerweise kann ein Abfrageauthentifizierungsprotokoll (CHAP für engl. challenge authentication protocol) zur Authentifizierung verwendet werden. Beide Protokolle können zur Authentifizierung verwendet werden, oder diese Phase kann übersprungen werden.
  • Ähnlich wird eine IP-Konfiguratonsprotokoll- oder IPCP-Konfigurationsaufforderung durch die Heimat-IWF und den PPP-Server gesendet und bestätigt.
  • Die Verbindung mit dem Endsystem kann aus irgendeinem der folgenden Gründe beendet werden:
    • 1. Vom Benutzer eingeleitete Beendigung. Gemäß diesem Szenarium beendet das Endsystem als Erstes das PPP auf gleitende Weise. Dies umfasst das Beenden des PPP-Netzsteuerungsprotokolls (IPCP), worauf das PPP-Verbindungsprotokoll beendet wird. Sobald dies geschehen ist, lässt sich das Endsystem aus Netzregister löschen, worauf die Funkverbindung mit dem Zugangspunkt beendet wird.
    • 2. Unterbrechung der drahtlosen Verbindung. Dieses Szenarium wird vom Modem erkannt und dem Modemtreiber im Endsystem gemeldet. Die oberen Schichten der Software werden informiert, um die Stapel zu beenden und den Benutzer zu benachrichtigen.
    • 3. Unterbrechung der Verbindung mit dem fremden Agenten. Dieses Szenarium wird vom Mobilitätstreiber im Endsystem erkannt. Nach dem Versuch und Fehlschlag, mit einem (potenziell neuen) fremden Agenten Kontakt neu herzustellen, sendet der Treiber eine entsprechende Mitteilung den Protokollstapel hinauf und signalisiert auch der Modemhardware unten, die drahtlose Verbindung zu beenden.
    • 4. Unterbrechung der Verbindung mit der IWF. Hier gilt im Wesentlichen dasselbe wie für die Unterbrechung mit dem fremden Agenten.
    • 5. Beendigung von PPP durch IWF oder PPP-Server. Dieses Szenarium wird durch die PPP-Software im Endsystem erkannt. Der PPP-Treiber des Endsystems wird von diesem Ereignis unterrichtet. Er leitet eine Löschung aus dem Netzregister ein, worauf die drahtlose Verbindung mit dem Zugangspunkt beendet wird.
  • Endsystemdienstkonfiguration bezieht sich auf das Konzept des Konfigurierens des Netzdienstes für ein Endsystem basierend auf dem Teilnehmerdienstprofil. Das Teilnehmerdienstprofil ist in einem Teilnehmerverzeichnis gespeichert. Das Dienstprofil enthält Informationen, um die Software zu befähigen, den drahtlosen Datendienst für den Teilnehmer kundenspezifisch einzustellen. Es umfasst Informationen, um das Endsystem zu authentifizieren, dem Endsystem zu erlauben, zu wandern, und Verbindungen mit dem Internetdiensteanbieter des Endsystems herzustellen. Vorzugsweise umfassen diese Informationen auch andere Parameter wie Dienstgüte. Zusätzlich zum Teilnehmerverzeichnis werden ein Heimatdomänenverzeichnis (HDD für engl. home domain directory) und ein Fremddomänenverzeichnis (FDD für engl. foreign domain directory) für das Roaming und zur Authentifizierung des fremden und des Heimatregistrierungsservers untereinander verwendet. Das HDD speichert Informationen über das Heimatnetz des Endsystems, und das FDD speichert Informationen über Fremdnetze, die ein Teilnehmer besuchen könnte.
  • 18 zeigt, wie diese Verzeichnisse in die Netzarchitektur abbilden und während der Registrierung für ein Endsystem verwendet werden, das sich zu Hause registrieren lässt. Bei Schritt 0 ruft das Endsystem (Mobileinheit) eine Ankündigung ab und empfängt sie vom fremden Agenten, um das Endsystem mit Informationen über das Netz zu versehen, zu welchem der fremde Agent gehört. In diesem Fall ist das Netz der Heimat-Drahtlosdiensteanbieter. Bei Schritt 1 nimmt der Benutzerregistrierungsagent (im Endsystem) die Informationen über den fremden Agenten, sein Netz und seine Sicherheitsnachweise in eine Aufforderung auf und sendet die Aufforderung an den fremden Agenten. Bei Schritt 2 leitet der fremde Agent als ein Proxy-Registrierungsagent die Aufforderung an den Heimatregistrierungsserver weiter. Bei Schritt 3 greift der Heimatregistrierungsserver auf das HDD des Heimat-Drahtlosdiensteanbieters zu, um wenigstens Authentifizierungsinformationen zu erfahren. Bei Schritt 4 greift der Heimatregistrierungsserver auf das Teilnehmerverzeichnis zu, um detaillierte Teilnehmerdienstprofilinformationen (z.B. abonnierte Dienstgüteoptionen usw.) zu erfahren. Bei Schritt 5 teilt der Heimatregistrierungsserver dem fremden Agenten die Zugangsantwort mit. Bei Schritt 6 und 7 teilt der fremde Agent dem Endsystem (d.h. der Mobileinheit) die Registrierungsantwort mit.
  • 19 stellt die Verzeichnisnutzung für ein Endsystem dar, das sich von einem Fremdnetz registrieren lässt. Bei Schritt 0 ruft das Endsystem (Mobileinheit) eine Ankündigung ab, und der fremde Agent kündigt an, was das Endsystem mit Informationen über das Netz versieht, zu welchem der fremde Agent gehört. In diesem Fall ist das Netz ein fremder Drahtlosdiensteanbieter. Bei Schritt 1 nimmt der Benutzerregistrierungsserver (im Endsystem) die Informationen über den fremden Agenten, sein Netz und seine Sicherheitsnachweise in eine Aufforderung auf und sendet die Aufforderung an den fremden Agenten. Bei Schritt 2 leitet der fremde Agent als ein Proxy-Registrierungsagent die Aufforderung an den fremden Registrierungsserver (d.h. den Registrierungsserver für den fremden Drahtlosdiensteanbieter) weiter. Bei Schritt 3 greift der fremde Registrierungsserver auf das HDD des fremden Drahtlosdiensteanbieters zu, um zu erfahren, zu welchem Netz das Endsystem gehört. Bei Schritt 4 übermittelt der fremde Registrierungsserver die Aufforderung des Endsystems an den Heimatregistrierungsserver des Heimat-Drahtlosdiensteanbieters des Endsystems. Bei Schritt 5 greift der Heimatregistrierungsserver auf das FDD des Heimatregistrierungsservers zu, um wenigstens Authentifizierungsinformationen über den fremden Diensteanbeiter zu erfahren. Bei Schritt 6 greift der Heimatregistrierungsserver auf das Teilnehmerverzeichnis zu, um detaillierte Teilnehmerdienstprofilinformationen (z.B. abonnierte Dienstgüteoptionen usw.) zu erfahren. Bei Schritt 7 teilt der Heimatregistrierungsserver dem fremden Registrierungsserver die Zugangsantwort mit. Bei Schritt 8 übermittelt der fremde Registrierungsserver die Zugangsantwort an den fremden Agenten. Bei Schritt 9 teilt der fremde Agent dem Endsystem (d.h. der Mobileinheit) die Registrierungsantwort mit.
  • Protokollabwicklungsszenarien zum Bearbeiten von Trägerdaten und die zugehörigen Stapel zum Transportieren von Trägerdaten zu und von einem Endsystem, die Protokollstapel für die Zellarchitekturen, die lokale APs (20) und abgesetzte APs (21) verwenden.
  • 20 stellt Protokollstapel zum Abwickeln von Kommunikationen zwischen einem Endsystem (in seinem Heimatnetz) und einer Heimat-IWF für End system@Home dar. 20 zeigt die Protokollabwicklung für eine Zellarchitektur, in welcher der Zugangspunkt und der drahtlose Hub ortsgleich untergebracht sind.
  • 21 zeigt die Protokollabwicklung für eine Zellarchitektur, in welcher der Zugangspunkt abgesetzt vom drahtlosen angeordnet ist. Wie dargestellt, endet das PPP in der IWF, und die Konfiguration stellt einen direkten Internetzugang bereit. Die Konfiguration für den Fall, in dem der PPP-Server von der IWF getrennt ist, wird später beschrieben.
  • In 21 werden PPP-Rahmen für das Endsystem in Funkverbindungsprotokoll- oder RLP-Rahmen (für engl. radio link protocol) eingekapselt, welche am abgesetzten Zugangspunkt zur Kommunikation mit dem Trunk-Zugangspunkt (d.h. einem Zugangspunkt, der physisch in der Nähe des drahtlosen Hubs angeordnet ist) in MAC-Rahmen eingekapselt werden, wobei der abgesetzte Zugangspunkt zum Beispiel durch einen drahtlosen Trunk mit dem Zugangspunkt verbunden ist. Der Zugangspunkt fungiert als eine MAC-Schicht-Brücke und leitet Rahmen von der Luftverbindung an den fremden Agenten im drahtlosen Hub weiter. Der fremde Agent entkapselt die RLP-Rahmen aus den MAC-Rahmen und leitet die RLP-Rahmen unter Verwendung des XTunnel-Protokolls an die IWF weiter. Ein ähnlicher, obgleich umgekehrter Prozess findet bei der Übertragung von Rahmen von der IWF zum Endsystem statt.
  • Wenn das Endsystem sich zu einem anderen fremden Agenten bewegt, dann wird automatisch ein neuer XTunnel zwischen dem neuen fremden Agenten und der IWF erzeugt, damit der PPP-Verkehr dazwischen weiter ohne Unterbrechung fließt.
  • In der Zellarchitektur mit abgesetztem AP (21), die drahtlose Trunks zwischen dem abgesetzten AP und dem Trunk-AP verwendet, kann die Luftverbindung zwischen dem Endsystem und dem Zugangspunkt gegenüber der Frequenz (f2) und der Funktechnik des Trunks auf einer anderen Frequenz (f1) arbeiten und eine andere Funktechnik verwenden.
  • 22 stellt die Protokollstapel für ein Gast-Endsystem dar. Die versorgende IWF verwendet das I-XTunnel-Protokoll zwischen der versorgenden IWF und der Heimat-IWF. Der Rest des Protokollstapels bleibt unverändert und ist nicht dargestellt. Diese Architektur kann durch Einfügen der versorgenden IWF in die Basisstation vereinfacht werden, wodurch das XWD-Protokoll eliminiert wird.
  • Die RLP-Schicht verwendet Folgenummern, um doppelte PPP-Datagramme zu löschen und eine In-Folge-Zustellung von PPP-Datagrammen zwischen dem Endsystem und der IWF bereitzustellen. Sie stellt auch einen konfigurierbaren Keep-alive-Mechanismus bereit, um die Streckenverbindungsfähigkeit zwischen dem Endsystem und IWF zu überwachen. Außerdem stellt die RLP-Schicht in einer alternativen Ausführungsform auch Wiederholungssendungs- und Flusssteuerungsdienste bereit, um die Gesamtbitfehlerrate der Verbindung zwischen dem Endsystem und der IWF zu verringern. Das RLP zwischen dem Endsystem und der IWF wird am Beginn der Sitzung gestartet und bleibt während der ganzen Sitzung und selbst über Weiterschaltungen aktiv.
  • Im Gegensatz zur Spezifikation im Mobile IP RFC (RFC 2003) wird keine IP-in-IP-Kapselung zum Tunneln zwischen dem fremden Agenten und der Heimat-IWF verwendet. Stattdessen wird ein neues Tunnelprotokoll verwendet, das über dem UDP implementiert wird. Dieses Tunnelprotokoll ist eine vereinfachte Version des L2TP-Protokolls. Die Gründe für diese Wahl sind Folgende:
    • 1. Das Kapselungsprotokoll, das in RFC 2003 spezifiziert ist, stellt keine Flusssteuerung oder In-Folge-Zustellung von Paketen bereit. Das gegenwärtig beschriebene Netz benötigt diese Dienste möglicherweise im Tunnel über den Backhaul. Eine Flussteuerung kann erforderlich sein, um die Menge von Wiederholungssendungen über die Luftverbindung aufgrund von Paketverlust infolge von Flusssteuerungsproblemen über das Netz zwischen der Basisstation und der MSC oder aufgrund von Flussteuerungsproblemen in der Basisstation oder der IWF zu verringern.
    • 2. Durch Verwenden eines UDP-basierten Tunnelprotokolls kann die Implementierung auf der Benutzerebene erfolgen und dann aus Leistungsgründen nach seiner Entstörung in den Kernel gesetzt werden.
    • 3. Bei Verwenden von RFC 2003 gibt es keine leichte Möglichkeit, Tunnel unter Berücksichtigung von Dienstgüte und Lastausgleich zu erzeugen. Um die QOS zu berücksichtigen, sollte es möglich sein, Tunnel über Verbindungen aufzubauen, welche die erforderliche QOS bereits vorsehen. Zweitens gibt es bei Verwenden von RFC 2003 keine leichte Möglichkeit, einen Lastausgleich bereitzustellen, um die Trägerverkehrslast über mehrere Verbindungen zwischen der Basisstation und der MSC zu verteilen.
    • 4. Um eine IP-in-IP-Kapselung zu implementieren, wie in RFC 2003 spezifiziert, benötigen die Entwickler Zugang zum IP-Quellcode. In kommerziellen Betriebssystemen ist der Quellcode für den TCP/IP-Stapel im Allgemeinen das Eigentum anderer Gerätehersteller. Der Erwerb des TCP/IP-Stapels von einem Hersteller und die Vornahme von Änderungen an der IP-Schicht, um den Mobile-IP-Tunnelaufbau zu unterstützen, würden von einem Entwickler verlangen, eine abweichende Version des TCP/IP-Stapels zu unterstützen. Dies fügt Kosten und Risiko hinzu.
  • Obwohl zu beachten ist, dass das Tunnelprotokoll zwischen der Basisstation und der IWF nicht standardmäßig ist und dass der Drahtlosdiensteanbieter nicht imstande ist, Betriebsmittel von verschiedenen Herstellern zu kombinieren und anzupassen, ist die Verwendung eines nicht standardmäßigen Tunnelprotokolls innerhalb eines einzelnen Drahtlosdiensteanbieternetzes für Endsysteme und Betriebsmittel von anderen Herstellern transparent.
  • Das neue Tunnelprotokoll basiert auf dem L2TP. Das L2TP an sich ist ein stark belastetes Tunnelprotokoll, so dass das L2TP einen hohen Zusatzaufwand in Verbindung mit der Tunnelerzeugung und Authentifizierung hat. Das neue Tunnelprotokoll der vorliegenden Erfindung hat weniger Zusatzaufwand. Das neue XTunnel- und I-XTunnel-Protokoll kann die folgenden Merkmale aufweisen:
    • 1. Die XTunnel- und I-XTunnel-Erzeugung fügt den Radius Access Request- und Radius Access Response-Nachrichten zwischen der Basisstation und dem Registrierungsserver herstellerspezifische Erweiterungen hinzu. Diese Erweiterungen verhandeln Tunnelparameter und, um den Tunnel zu erzeugen.
    • 2. Der Registrierungsserver ist imstande, die tatsächliche Arbeit des Tunnelaufbaus und der Weiterleitung von Paketen an verschiedene IP-Adressen und daher an einen anderen Server in der MSC delegieren. Dies ermöglicht es dem Registrierungsserver, einen Lastausgleich über mehrere IWF-Server durchzuführen und eine unterschiedliche QOS für verschiedene Benutzer bereitzustellen.
    • 3. Das XTunnel- und I-XTunnel-Protokoll unterstützt Inband-Steuernachrichten zur Tunnelverwaltung. Diese Nachrichten umfassen Echoabfrage/antwort zum Prüfen der Tunnelverbindungsfähigkeit, Trennungs-Anforderung/Antwort/Meldung zum Trennen des Tunnels und Fehlermeldung für Fehlermitteilungen. Diese Nachrichten werden über die Tunnelmedien, zum Beispiel UDP/IP, gesendet.
    • 4. Das XTunnel- und I-XTunnel-Protokoll sendet Nutzdaten über die Tunnelmedien, zum Beispiel UDP/IP. Das XTunnel- und I-XTunnel-Protokoll unterstützt Flusssteuerung und In-Folge-Paketzustellung.
    • 5. Das XTunnel- und I-XTunnel-Protokoll kann über andere Medien als UDP/IP für Dienstgüte implementiert werden.
  • Das Netz unterstützt eine direkte Internetverbindungsfähigkeit, indem das PPP in der Heimat-IWF beendet wird und IP-Pakete von der IWF zum Internet über einen Router weitergeleitet werden, der standardmäßige IP-Leitweglenkungsprotokolle verwendet. Vorzugsweise führt die IWF das RIP aus, und der Router führt ebenfalls das RIP und möglicherweise andere Leitweglenkungsprotokolle wie OSPF aus.
  • Das Netz unterstützt eine erste Konfiguration für einen Drahtlosdiensteanbieter, der auch ein Internetdiensteanbieter ist. In dieser Konfiguration fungiert die Heimat-IWF in der MSC auch als ein PPP-Server. Diese IWF führt auch Internetleitweglenkungsprotokolle wie RIP aus und verwendet einen Router, um sich ans Backbone-Netz des Internetdiensteanbieters anzuschließen.
  • Das Netz unterstützt eine zweite Konfiguration für einen Drahtlosdiensteanbieter, der wünscht, es Endsystemen zu ermöglichen, sich an einen oder mehr Internetdiensteanbieter anzuschließen, weil der WSP entweder selbst kein ISP ist oder weil der WSP Vereinbarungen mit anderen ISPs hat, um Endbenutzern Zugang zu verschaffen. Zum Beispiel kann ein Drahtlosdiensteanbieter sich dafür entscheiden, einem Endbenutzer Zugang anzubieten, und er kann eine Vereinbarung mit einem Fremd-ISP haben, um dem Benutzer, der auch ein Konto beim Fremd-ISP hat, den Zugang zum ISP vom WSP-Netz zu ermöglichen. In dieser Konfiguration läuft der PPP-Server nicht in der Heimat-IWF, die in der MSC installiert ist. Stattdessen wird ein Tunnelprotokoll, wie L2TP (Schicht-zwei-Tunnelprotokoll), zum Zurücktunneln zum PPP-Server des ISPs verwendet. 10 stellt die Protokollstapel für diese Konfiguration für ein Endsystem dar, das zu Hause ist.
  • Der Aufenthaltsort der Heimat-IWF und des ISP-PPP-Servers bleibt während der ganzen PPP-Sitzung fest. Außerdem bleibt der L2TP-Tunnel zwischen der IWF und dem ISP-PPP-Server während der ganzen PPP-Sitzung aufrecht. Die physikalische Strecke zwischen der IWF und dem PPP-Server ist über einen Router, der ein dediziertes T1- oder T3-, ein Rahmenweiterleitungs- oder ein ATM-Netz verwendet. Die tatsächliche Beschaffenheit der physikalischen Strecke ist vom Gesichtspunkt der Architektur nicht wichtig.
  • Diese Konfiguration unterstützt auch den Intranetzugang. Für den Intranetzugang sitzt der PPP-Server im firmeneignen Intranet, und die Heimat-IWF verwendet das L2TP, um zu ihm zu tunneln.
  • Für ein festes Endsystem ist die Protokollabwicklung für den Intranet- oder ISP-Zugang so, wie in 23 dargestellt, mit dem Unterschied, dass das Gast-Endsystem eine versorgende IWF verwendet, um sich mit seiner Heimat-IWF in Verbindung setzen. Die Protokollabwicklung zwischen einer versorgenden IWF und einer Heimat-IWF wurde bereits beschrieben. In 23 kann die Heimat-IWF in den drahtlosen Hub eingefügt werden, wodurch das XTunnel-Protokoll eliminiert wird. Auch die versorgende IWF kann in den drahtlosen Hub eingefügt werden, wodurch das XTunnel-Protokoll eliminiert wird.
  • 24 stellt die Protokollstapel, welche während der Registrierungsphase (Endsystemregistrierung) verwendet werden, für eine Zellarchitektur mit lokalem Zugangspunkt dar. Der Stapel für eine Architektur mit abgesetztem Zugangspunkt ist sehr ähnlich.
  • Das oben dargestellte Szenarium ist für ein Gast-Endsystem. Für ein Endsystem zu Hause gibt es keinen fremden Registrierungsserver auf dem Registrierungsweg.
  • Man beachte den Mobilitätsagenten im Endsystem. Der Mobilitätsagent im Endsystem und der fremde Agent im drahtlosen Hub sind konzeptionell ähnlich dem Mobile IP RFC 2002. Der Mobilitätsagent wickelt Netzfehler unter Verwendung von Zeitüberschreitungen und Wiederholungsversuchen ab. Im Gegensatz zu bekannten Protokollstapeln für Trägerdaten wird kein RLP verwendet. Der fremde Agent und die Registrierungsserver verwenden Radius über UDP/IP zur Kommunikation miteinander, um das Endsystem zu registrieren.
  • Es sind mehrere Sicherheitsaspekte zu berücksichtigen. Der erste, das Authentifizieren der Identitäten des Endsystems und des Fremd/Heimatnetzes während der drahtlosen Registrierungsphase. Der zweite, das Authentifizieren der Identität des Endsystems mit seinem PPP-Server während der PPP-Authentifizierungsphase. Der dritte, die Authentifizierung zum Speichern von Abrechnungsdaten, zum Gebührenerfassen und zum Aktualisieren von Heimatdomäneninformationen. Der vierte, die Verschlüsselung von Trägerverkehr, der zum und vom Endsystem übertragen wird. Der fünfte, die Verschlüsselung zum Austauschen von Rechnungsinformationen über Diensteanbietergrenzen.
  • Es werden gemeinsam benutzte Geheimcodes verwendet, um die Identität von Endsystemen mit ihren Heimatnetzen und die Identität des Heimat- und des Fremdnetzes untereinander während der drahtlosen Registrierung zu authentifizieren.
  • Die Endsystemauthentifizierung verwendet einen gemeinsamen benutzten 128-Bit-Geheimcode, um eine Identitätsmarke für seine Registrierungsaufforderung zu erzeugen. Die Identitätsmarke wird unter Verwendung des bekannten MD5-Message-Digest-Algorithmus, wie im Mobile IP RFC 2002 beschrieben, erzeugt. Alternativerweise kann ein anderer Algorithmus verwendet werden. Der gemeinsam benutzte Geheimcode wird nicht in der Registrierungsaufforderung durch das Endsystem gesendet. Es wird nur die Identitätsmarke gesendet. Bei Empfang der Registrierungsaufforderung vom Endsystem errechnet der Heimatregistrierungsserver die Identitätsmarke über die Registrierungsaufforderungsdaten unter Verwendung des gemeinsam benutzten Geheimcodes neu. Wenn der errechnete Identitätsmarkenwert mit dem Identitätsmarkenwert übereinstimmt, der durch das Endsystem gesendet wurde, erlaubt der Heimatregistrierungsserver, dass der Registrierungsprozess fortgesetzt wird. Wenn die Werte nicht übereinstimmen, protokolliert der Heimatregistrierungsserver das Ereignis, erzeugt einen Sicherheitsverletzungsalarm und eine „nak" (d.h. eine negative Bestätigung) für die Aufforderung.
  • In der Registrierungsantwort macht der Heimatregistrierungsserver dasselbe, das heißt er verwendet den gemeinsam benutzten Geheimcode, um eine Identitätsmarke für die Registrierungsantwort zu erzeugen, die er an das Endsystem sendet. Nach Empfang der Antwort errechnet das Endsystem die Identitätsmarke unter Verwendung des gemeinsam benutzten Geheimcodes neu. Wenn der errechnete Wert nicht mit dem Identitätsmarkenwert übereinstimmt, der durch den Heimatregistrierungsserver in der Antwort gesendet wurde, verwirft das Endsystem die Antwort und versucht es erneut.
  • Diese Netzsicherheitskonzepte sind den Konzepten ähnlich, die im Mobile IP RFC 2002 definiert sind. Gemäß RFC besteht eine Mobilitätssicherheitsvereinbarung zwischen jedem Endsystem und seinem Heimatnetz. Jede Mobilitätssicherheitsvereinbarung definiert eine Sammlung von Sicherheitskontexten. Jeder Sicherheitskontext definiert einen Authentifizierungsalgorithmus, einen Modus, einen Geheimcode (gemeinsam benutzt oder öffentlich-privat), ein Wiederholungsschutzformat und die zu verwendende Art von Verschlüsselung. Im Kontext des vorliegenden Netzes wird der User-Name des Endsystems (anstelle der Mobile-IP-Heimatadresse) verwendet, um die Mobilitätssicherheitsvereinbarung zwischen dem Endsystem und seinem Heimatnetz zu identifizieren. Ein anderer Parameter, genannt Sicherheitsparameterindex (SPI), wird verwendet, um einen Sicherheitskontext innerhalb der Mobilitätssicherheitsvereinbarung auszuwählen. In einer grundlegenden Ausführungsform der Erfindung werden nur der vorgegebene Mobile-IP-Authentifizierungsalgorithmus (MD5-verschlüsselt) und der vorgegebene Modus („Präfix + Suffix") mit gemeinsam benutzten 128-Bit-Geheimcodes unterstützt. Netzbenutzer dürfen mehrere gemeinsam benutzte Geheimcodes mit ihrem Heimatnetz definieren. Der Mechanismus zum Erzeugen von Sicherheitskontexten für Endbenutzer, wobei jedem Sicherheitskontext ein SPI zugeordnet wird, zum Einstellen der Inhalte des Sicherheitskontextes (welcher den gemeinsam benutzten Geheimcode beinhaltet) und zum Modifizieren ihrer Inhalte wird im Folgenden beschrieben. Während der Registrierung wird durch das Endsystem unter Verwendung des MD5-Algorithmus ein 128- Bit-Message-Digest in einem Präfix+Suffix-Modus errechnet. Der gemeinsam benutzte Geheimcode wird als das Präfix und das Suffix für die Daten verwendet, die in der Registrierungsaufforderung zu schützen sind. Die auf diese Weise errechnete Identitätsmarke wird zusammen mit dem SPI und dem User-Name in der Registrierungsaufforderung durch das Endsystem gesendet. Nach Empfang der Registrierungsaufforderung des Endsystems leitet der fremde Registrierungsserver die Aufforderung zusammen mit der Identitätsmarke und dem SPI unverändert an den Heimatregistrierungsserver weiter. Nach Empfang der Registrierungsaufforderung direkt vom Endsystem oder indirekt über einen fremden Registrierungsserver verwendet der Heimatregistrierungsserver den SPI und den User-Name zur Auswahl des Sicherheitskontextes. Der Heimatserver errechnet die Identitätsmarke unter Verwendung des gemeinsam benutzten Geheimcodes neu. Wenn der errechnete Identitätsmarkenwert mit dem Wert der Identitätsmarke übereinstimmt, die in der Aufforderung durch das Endsystem gesendet wurde, ist die Identität des Benutzers erfolgreich authentifiziert. Andernfalls bestätigt der Heimatregistrierungsserver die Registrierungsaufforderung, die durch das Endsystem gesendet wurde, negativ (nak).
  • Die Registrierungsantwort, die durch den Heimatregistrierungsserver an das Endsystem gesendet wird, wird ebenfalls unter Verwendung des zuvor beschriebenen Algorithmus authentifiziert. Der SPI und der errechnete Identitätsmarkenwert werden in der Registrierungsantwortnachricht durch den Heimatserver an das Endsystem übertragen. Nach Empfang der Antwort errechnet das Endsystem die Identitätsmarke neu und, wenn der errechnete Wert mit dem übertragenen Wert nicht übereinstimmt, verwirft es die Antwort und versucht es erneut.
  • Das Endsystem des Benutzers muss für alle Sicherheitskontexte, die der Benutzer mit seinen Registrierungsserver(n) gemeinsam benutzt, mit dem gemeinsam benutzten Geheimcode und den SPIs konfiguriert werden. Diese Konfigurationsinformationen werden für Windows 95-basierte Endsysteme vorzugsweise in einem Win 95-Register gespeichert. Während der Registrierung wird auf diese Informationen zugegriffen, und sie werden für Authentifizierungszwecke verwendet.
  • Im Netz werden durch den fremden Agenten FA Radius-Protokolle verwendet, um das Endsystem zu registrieren und den XTunnel zwischen dem drahtlosen Hub und der Heimat- und der versorgenden IWF für das Endsystem zu konfigurieren. Bei Empfang einer Registrierungsaufforderung vom Endsystem erzeugt der FA ein Radius Access-Request-Paket (Radius-Zugangsanforderungspaket), speichert seine eigenen Attribute ins Paket, kopiert die Registrierungsaufforderungsattribute des Endsystems unverändert in dieses Paket und sendet die verknüpfte Aufforderung an den Registrierungsserver in der MSC.
  • Eine Radius-Authentifizierung erfordert, dass der Radius-Client (in diesem Fall der FA in der Basisstation) und der Radius-Server (in diesem Fall der Registrierungsserver in der MSC) einen Geheimcode für Authentifizierungszwecke gemeinsam benutzen. Dieser gemeinsam benutzte Geheimcode wird auch verwendet, um alle Privatinformationen zu verschlüsseln, die zwischen dem Radius-Client und dem Radius-Server übertragen werden. Der gemeinsam benutzte Geheimcode ist ein konfigurierbarer Parameter. Das Netz folgt den Empfehlungen im Radius RFC und verwendet den gemeinsam benutzten Geheimcode und den MD5-Algorithmus zur Authentifizierung und zur Verschlüsselung, wenn eine Verschlüsselung notwendig ist. Das Radius Access-Request-Paket, das durch den FA gesendet wurde, enthält ein Radius User-Name- oder Radius-Benutzernamen- Attribut (welches durch das Endsystem bereitgestellt wird) und ein Radius User-Password- oder Radius-Benutzerpasswort-Attribut. Der Wert des User-Password-Attributs ist ebenfalls ein konfigurierbarer Wert und wird in der durch das Radius-Protokoll empfohlenen Weise verschlüsselt. Andere netzspezifische Attribute, welche vom Gesichtspunkt des Radius RFC-Standards keine standardmäßigen Attribute sind, werden als herstellerspezifische Radius-Attribute codiert und im Access-Request-Paket gesendet.
  • Die folgenden Attribute werden durch den FA im Radius Access-Request-Paket an seinen Registrierungsserver gesendet.
    • 1. User-Name-Attribut. Dies ist der Benutzername des Endsystems so, wie durch das Endsystem in seiner Registrierungsaufforderung geliefert.
    • 2. User-Password-Attribut. Dieses Benutzerpasswort wird durch die Basisstation/den drahtlosen Hub für den Benutzer geliefert. Es wird so codiert, wie im Radius RFC beschrieben, wobei der Geheimcode verwendet wird, der zwischen der Basisstation und ihrem Registrierungsserver gemeinsam benutzt wird.
    • 3. NAS-Port. Dies ist der Anschluss auf der Basisstation.
    • 4. NAS-IP-Address. Dies st die IP-Adresse der Basisstation.
    • 5. Service-Type. Dies ist ein gerahmter Dienst.
    • 6. Framed Protocol. Dies ist ein PPP-Protokoll.
    • 7. XTunnel Protocol Parameters. Diese Parameter werden durch die Basisstation gesendet, um die Parameter zu spezifizieren, die zum Aufbau des XTunnel-Protokolls für das Endsystem notwendig sind. Dies ist ein herstellerspezifisches Attribut.
    • 8. AP-IP-Address. Dies ist die IP-Adresse des APs, durch welchen der Benutzer sich registrieren lässt. Dies ist ein herstellerspezifisches Attribut.
    • 9. AP-MAC-Address. Dies ist die MAC-Adresse des APs, durch welchen der Benutzer sich registrieren lässt. Dies ist ein herstellerspezifisches Attribut.
    • 10. End systems Registration Request. Die Registrierungsaufforderung vom Endsystem wird unverändert in dieses herstellerspezifische Attribut kopiert.
  • Die folgenden Attribute werden vom Registrierungsserver im Radius Access-Response- oder Radius-Zugangsantwort-Paket an den FA gesendet:
    • 1. Service Type. Dies ist ein gerahmter Dienst.
    • 2. Framed-Protocol. Dies ist ein PPP.
    • 3. XTunnel Protocol Parameters. Diese Parameter werden durch den Registrierungsserver gesendet, um die Parameter zu spezifizieren, die zum Aufbau des XTunnel-Protokolls für das Endsystem notwendig sind. Dies ist ein herstellerspezifisches Attribut.
    • 4. Home Registration Servers Registration Reply. Dieses Attribut wird vom Heimatregistrierungsserver an den FA gesendet. Der FA leitet dieses Attribut in einem Registrierungsantwortpaket unverändert an das Endsystem weiter. Wenn es einen fremden Registrierungsserver auf dem Weg gibt, wird dieses Attribut durch ihn unverändert an den FA weitergeleitet. Es wird als ein herstellerspezifisches Attribut codiert.
  • Um Gast-Endsysteme zu versorgen, werden das Fremdnetz und das Heimatnetz unter Verwendung des Radius-Protokolls zur Authentifizierung und Konfiguration untereinander für Abrechnungs- und Gebührenverrechnungszwecke authentifiziert. Diese Authentifizierung wird zum Zeitpunkt der Endsystemregistrierung durchgeführt. Wie bereits erwähnt, verwendet der Registrierungsserver im Fremdnetz, wenn er eine Registrierungsaufforderung von einem Endsystem empfängt (eingekapselt als ein herstellerspezifisches Attribut in einem Radius Access Request-Paket durch den FA), den User-Name des Endsystems, um die Identität des Heimatregistrierungsservers des Endsystems durch Konsultieren seines Heimatdomänenverzeichnisses HDD zu bestimmen. Die folgenden Informationen sind im Heimatdomänenverzeichnis HDD gespeichert, und auf sie greift der fremde Registrierungsserver zu, um die Registrierungsaufforderung des Endsystems weiterzuleiten:
    • 1. Home Registration Server IP Address. Dies ist die IP-Adresse des Heimatregistrierungsservers, um die Registrierungsaufforderung zu übermitteln.
    • 2. Foreign Registration Server Machine Id. Dies ist Maschinen-ID des fremden Registrierungsservers im vereinfachten E-Mail-Übertragungsprotokoll- oder SMTP-Format (für engl. simplified mail transfer protocol) (z.B. machine@fgdn, wobei machine der Name der fremden Registrierungsservermaschine und fgdn der voll qualifizierte Domänenname der Domäne des fremden Registrierungsservers ist).
    • 3. Tunneling Protocol Parameters. Dies sind Parameter zum Konfigurieren des Tunnels zwischen der versorgenden IWF und der Heimat-IWF für das Endsystem. Diese umfassen das Tunnelprotokoll, das zwischen ihnen zu verwendet ist, und die Parameter zum Konfigurieren des Tunnels.
    • 4. Shared Secret. Dies ist der gemeinsam benutzte Geheimcode, der zur Authentifizierung zwischen dem fremden Registrierungsserver und dem Heimatregistrierungsserver zu verwenden ist. Dieser Geheimcode wird zum Errechnen des Radius User-Password-Attributs im Radius-Paket verwendet, das durch den fremden Registrierungsserver an den Heimatregistrierungsserver gesendet wird. Er wird zwischen den beiden Drahtlosdiensteanbietern definiert.
    • 5. User-Password. Dies ist das Benutzerpasswort, das für das Gast-Endsystem zu verwenden ist. Dieses Benutzerpasswort wird zwischen den beiden Drahtlosdiensteanbietern definiert. Dieses Passwort wird unter Verwendung des gemeinsam benutzten Geheimcodes, wie im Radius RFC beschrieben, verschlüsselt.
    • 6. Accounting Parameters. Dies sind Parameter zum Konfigurieren der Abrechnung für das Endsystem, das sich registrieren lässt. Diese Parameter werden durch den Registrierungsserver zum Konfigurieren der Abrechnung für das Endsystem an seine IWF gesendet.
  • Durch Verwenden dieser Informationen erzeugt der fremde Registrierungsserver eine Radius Access-Request, fügt seine eigenen Registrierungs- und Authentifizierungsinformationen in die Radius Access-Request hinzu, kopiert die Registrierungsinformationen, die durch das Endsystem gesendet wurden, unverändert in die Radius Access-Request und sendet die verknüpfte Anforderung an den Heimatregistrierungsserver.
  • Nach Empfang der Radius Access-Request vom fremden Registrierungsserver (für ein Gast-Endsystem) oder direkt vom FA (für ein Endsystem zu Hause) befragt der Heimatregistrierungsserver seinen eigenen Verzeichnisserver nach den gemeinsam benutzten Geheimcodes, um die Identität des Endsystems und die Identität des fremden Registrierungsservers in einem Roaming-Szenarium durch Neuerrechnen von Identitätsmarken zu überprüfen.
  • Nach einer erfolgreichen Verarbeitung der Anforderung erzeugt der Heimatregistrierungsserver ein Radius Access-Accept- oder Radius-Zugangsgenehmigungs-Antwortpaket und sendet es an den fremden Registrierungsserver, wenn das Endsystem wandert, oder direkt zum FA, von welchem er die Radius Access-Request empfing. Die Antwort enthält das Registrierungsantwortattribut, das der FA an das Endsystem weiterleitet.
  • Wenn die Anforderung nicht erfolgreich verarbeitet werden kann, erzeugt der Heimatregistrierungsserver ein Radius Access-Reject- oder Radius-Zugangsverweigerungs-Antwortpaket und sendet es an den fremden Registrierungsserver, wenn das Endsystem wandert, oder direkt an den FA, von welchem er die Radius Access-Request empfing. Die Antwort enthält das Registrierungsantwortattribut, das der FA an das Endsystem weiterleitet.
  • In einem Roaming-Szenarium wird die Antwort vom Heimatregistrierungsserver durch den fremden Registrierungsserver empfangen. Sie wird durch den fremden Registrierungsserver unter Verwendung des gemeinsam benutzten Geheimcodes authentifiziert. Nach der Authentifizierung verarbeitet der fremde Registrierungsserver die Antwort und erzeugt seinerseits ein Radius-Antwortpaket (Accept oder Reject) zum Versand an den FA. Der fremde Registrierungsserver kopiert das Registrierungsantwortattribut aus dem Radius-Zugangsantwortpaket des Heimatregistrierungsservers unverändert in sein Radius-Antwortpaket. Wenn der FA das Radius Access-Response- oder Radius Access-Reject-Antwortpaket empfängt, erzeugt er unter Verwendung der Registrierungsantwortattribute aus der Radius-Antwort ein Registrierungsantwortpaket und sendet die Antwort an das Endsystem, wodurch die Registrierungsumlauffolge abgeschlossen ist.
  • Die Mobile-IP-Standards spezifizieren, dass ein Wiederholungsschutz für Registrierungen implementiert wird, wobei Zeitstempel oder optional Nonces verwendet werden. Da jedoch ein Wiederholungsschutz, der Zeitstempel verwendet, angemessen synchronisierte Tageszeittakte zwischen den entsprechenden Knoten erfordert, implementiert die vorliegende Erfindung einen Wiederholungsschutz während der Registrierung unter Verwendung von Nonces, auch wenn ein Wiederholungsschutz, der Zeitstempel verwendet, in den Mobile-IP-Standards vorgeschrieben ist und die Verwendung von Nonces optional ist. Es ist jedoch ein Wiederholungsschutz, der Zeitstempel verwendet, als eine alternative Ausführungsform vorgesehen.
  • Das Wiederholungsschutzformat, das zwischen Knoten verwendet wird, wird zusätzlich zu Authentifizierungskontext, Modus, Geheimcode und Verschlüsselungsart im Sicherheitskontext gespeichert.
  • Das Netz unterstützt die Verwendung von PPP-PAP (Passwort-Authentifizierung) und -CHAP (abfrageauthentifiziertes Passwort) zwischen dem Endsystem und seinem PPP-Server. Dies erfolgt unabhängig von den zuvor beschriebenen Registrierungs- und Authentifizierungsmechanismen. Dies ermöglicht es einem privaten Intranet oder einem ISP, die Identität des Benutzers zu überprüfen.
  • Eine Authentifizierung für Abrechnungs- und Verzeichnisdienste wird im Folgenden in Bezug auf die Abrechnungssicherheit beschrieben. Der Zugang zu Verzeichnisservern von Netzbetriebsmitteln in derselben MSC braucht nicht authentifiziert zu werden.
  • Das Netz unterstützt die Verschlüsselung von Trägerdaten, die zwischen dem Endsystem und der Heimat-IWF gesendet werden. Die Endsysteme handeln durch Auswählen des geeigneten Sicherheitskontextes aus, ob eine Verschlüsselung ein oder aus sein soll. Nach Empfang der Registrierungsaufforderung bewilligt der Heimatregistrierungsserver des Endsystems Anforderung einer Verschlüsselung basierend auf dem Sicherheitskontext. Neben dem Speichern von Authentifizierungsalgorithmus, Modus, gemeinsam benutztem Code und Wiederholungsschutzformat wird der Sicherheitskontext auch verwendet, um das zu verwendende Format des Verschlüsselungsalgorithmus zu spezifizieren. Wenn die Verschlüsselung zwischen dem Endsystem und dem Heimatagenten ausgehandelt wird, dann wird der gesamte PPP-Rahmen vor der Kapselung im RLP so verschlüsselt.
  • Die IWF, der Abrechnungsserver und das Gebührenverrechnungssystem sind Teil derselben zuverlässigen Domäne in der MSC. Diese Entitäten sind entweder an dasselbe LAN angeschlossen oder Teil eines zuverlässigen Intranets, das dem Drahtlosdiensteanbieter gehört und von ihm betrieben wird. Die Übertragung von Abrechnungsstatistiken zwischen der IWF und dem Abrechnungsserver und zwischen dem Abrechnungsserver und dem Kundengebührenverrechnungssystem brauchen nicht unter Verwendung von Internet-IP-Sicherheitsprotokollen wie IP-Sec verschlüsselt zu werden.
  • Das Netz macht es schwieriger, den Aufenthaltsort des Endsystems zu überwachen, da es scheint, dass alle PPP-Rahmen, die vom und zum Endsystem gehen, ungeachtet des tatsächlichen Aufenthaltsorts des Endsystemgeräts durch die Heimat-IWF gehen.
  • Die Abrechnungsdaten werden durch die versorgende IWF und die Heimat-IWF im Netz gesammelt. Abrechnungsdaten, die durch die versorgende IWF gesammelt werden, werden an einen Abrechnungsserver in der MSC der versorgenden IWF gesendet. Abrechnungsdaten, die durch die Heimat-IWF gesammelt werden, an einen Abrechnungsserver in der MSC der Heimat-IWF gesendet. Die Abrechnungsdaten, die durch die versorgende IWF gesammelt werden, werden durch den fremden Drahtlosdiensteanbieter zur Rechnungsprüfung und zur Zahlung von Rechnungen über Drahtlosdienteanbietergrenzen verwendet (um Roaming und Mobilität zu unterstützen). Die Abrechnungsdaten, die durch die Heimat-IWF gesammelt werden, werden zur Vergebührung des Endbenutzers und auch zur Zahlung über Drahtlosdiensteanbietergrenzen verwendet, um Roaming und Mobilität abzuwickeln.
  • Da ungeachtet des Aufenthaltsorts des Endsystems und des Aufenthaltsorts des fremden Agenten der gesamte Datenverkehr durch die Heimat-IWF fließt, hat die Heimat-IWF alle Informationen zur Erstellung von Rechnungen für den Kunden und auch Zahlungsinformationen zur Verwendung von Fremdnetzen.
  • Die versorgende IWF und die Heimat-IWF verwenden vorzugsweise das Radius-Abrechnungsprotokoll zum Senden von Abrechnungssätzen für registrierte Endsysteme. Das Radius-Abrechnungsprotokoll ist so, wie in einem IETF RFC-Entwurf dokumentiert. Für die vorliegende Erfindung muss das Protokoll durch Hinzufügen von herstellerspezifischen Attributen für das Netz und durch Hinzufügen einer Kontrollpunktmarkierung zum Radius-Accounting-Protokoll erweitert werden. Kontrollpunktmarkierung in diesem Kontext bezieht sich auf das regelmäßige Aktualisieren von Abrechnungsdaten, um das Risiko eines Verlusts von Abrechnungssätzen zu minimieren.
  • Das Radius-Abrechnungsprotokoll läuft über UDP/IP und verwendet Wiederholungsversuche auf der Basis von Bestätigung und Zeitüberschreitungen. Die Radius-Abrechnungsclients (versorgende IWFs oder Heimat-IWFs) sendet UDP-Abrechnungsanforderungspakete an ihre Abrechnungsserver, welche Bestätigungen an die Abrechnungsclients zurücksenden.
  • Im Netz geben die Abrechnungsclients (die versorgende IWF und die Heimat-IWF) eine Abrechnungsstartanzeige am Beginn der Sitzung des Benutzers und eine Abrechnungsstoppanzeige am Ende der Sitzung des Benutzers aus. In der Mitte der Sitzung geben die Abrechnungsclients Abrechnungskontrollpunktanzeigen aus. Im Gegensatz dazu spezifiziert die Radius-Abrechnungs-RFC keine Abrechnungskontrollpunktanzeige. Die Software der vorliegenden Erfindung erzeugt ein herstellerspezifisches Abrechnungsattribut zu diesem Zweck. Dieses Abrechnungsattribut ist in allen Radius Accounting-Request- oder Radius-Abrechnungsanforderungs-Paketen vorhanden, welche einen Acct-Status-Type von Start (Abrechnungsstartanzeigen) aufweisen. Der Wert dieses Attributs wird verwendet, um an den Abrechnungsserver zu übertragen, ob der Abrechnungssatz ein Kontrollpunktsatz ist oder nicht. Kontrollpunktabrechnungssätze weisen ein Zeitattribut auf und enthalten kumulative Abrechnungsdaten vom Start der Sitzung. Die Häufigkeit des Übertragens von Kontrollpunktpaketen ist in der vorliegenden Erfindung konfigurierbar.
  • Die versorgende IWF und die Heimat-IWF werden durch ihre jeweiligen Registrierungsserver zur Verbindung mit ihren Abrechnungsservern während der Registrierungsphase konfiguriert. Die konfigurierbaren Abrechnungsparameter umfassen die IP-Adresse und den UDP-Port des Abrechnungsservers, die Häufigkeit der Kontrollpunktmarkierung, die Sitzungs-/Mehrfachsitzungs-ID und den gemeinsam benutzten Geheimcode, der zwischen dem Abrechnungsclient und dem Abrechnungsserver zu verwenden ist.
  • Das Netz zeichnet die folgenden Abrechnungsattribute für jedes registrierte Endsystem auf. Diese Abrechnungsattribute werden durch die Abrechnungsclients in Radius-Abrechnungspaketen am Beginn der Sitzung, am Ende der Sitzung und in der Mitte (Kontrollpunkt) ihren Abrechnungsservern gemeldet.
    • 1. User-Name. Dieses Attribut ist wie das zuvor erörterte Radius User-Name-Attribut. Dieses Attribut wird verwendet, um den Benutzer zu identifizieren und ist in allen Abrechnungsberichten vorhanden. Das Format ist „user@domain", wobei domain der voll qualifizierte Domänenname der Heimat des Benutzers ist.
    • 2. NAS-IP-Address. Dieses Attribut ist wie das zuvor erörterte Radius NAS-IP-Address-Attribut. Dieses Asttribut wird verwendet, um die IP-Adresse der Maschine zu identifizieren, welche die Heimat-IWF oder die versorgende IWF ausführt.
    • 3. Radio Port. Dieses Attribut identifiziert den Funkanschluss auf dem Zugangspunkt, der den Benutzer versorgt. Dieses Attribut wird als ein herstellerspezifisches Attribut codiert.
    • 4. Access Point IP Address. Dieses Attribut identifiziert die IP-Adresse des Zugangspunkts, der den Benutzer versorgt. Dieses Attribut wird als ein herstellerspezifisches Attribut codiert.
    • 5. Service Type. Dieses Attribut ist wie das zuvor beschriebene Radius Service-Type-Attribut. Der Wert dieses Attributs ist Framed (gerahmt).
    • 6. Framed Protocol. Dieses Attribut ist wie das zuvor beschriebene Radius Framed-Protocol-Attribut. Der Wert dieses Attributs ist so eingestellt, dass er PPP anzeigt.
    • 7. Accounting Status Type. Dieses Attribut ist wie das zuvor beschriebene Radius Acct-Status-Type-Attribut. Der Wert dieses Attributs kann Start sein, um den Start einer Sitzung des Benutzers mit dem Radius-Client zu markieren, und es kann Stopp sein, um das Ende der Sitzung des Benutzers mit dem Radius-Client zu markieren. Für Abrechnungsclients wird das Acct-Status-Type/Start-Attribut erzeugt, wenn das Endsystem sich registrieren lässt. Das Acct-Status-Type/Stopp-Attribut wird erzeugt, wenn das Endsystem sich aus irgendeinem Grund aus dem Register löschen lässt. Für Kontrollpunkte ist der Wert dieses Attributs ebenfalls Start, und das Accounting Checkpoint- oder Abrechnungskontrollpunkt-Attribut ist ebenfalls vorhanden.
    • 8. Accounting Session Id. Diese ist wie die zuvor beschriebene Radius Acct-Session-ID. In einem Roaming-Szenarium wird diese Sitzungs-ID durch den fremden Registrierungsserver zugeordnet, wenn das Endsystem eine Registrierungsaufforderung ausgibt. Sie wir während der Registrierungsfolge durch den fremden Registrierungsserver an Heimatregistrierungsserver übertragen. Das Heimatnetz und das Fremdnetz kennen beide das Acct-Session-ID-Attribut und sind imstande, dieses Attribut auszugeben, während sie Abrechnungssätze an ihre jeweiligen Abrechnungsserver senden. In einem „Endsystem-zu-Hause"-Szenarium wird dieses Attribut durch den Heimatregistrierungsserver erzeugt. Der Registrierungsserver kommuniziert den Wert dieses Attributs der IWF, welche ihn in allen Abrechnungssätzen ausgibt.
    • 9. Accounting Multi-Session-Id. Diese ist wie die zuvor erörterte Radius Acct-Multi-Session-ID. Diese ID wird durch den Heimatregistrierungsserver zugeordnet, wenn eine Registrierungsaufforderung von einem FA direkt oder über einen fremden Registrierungsserver für ein Endsystem empfangen wird. Sie wird durch den Heimatregistrierungsserver in der Registrierungsantwortnachricht an den fremden Registrierungsserver übertragen. Der oder die Registrierungsserver kommunizieren den Wert dieses Attributs der oder den IWF(s), welche ihn in allen Abrechnungssätzen ausgeben.
  • Bei einer zuverlässigen Mobilität, die der Architektur hinzugefügt wird, wird die ID verwendet, um die Abrechnungssätze von verschiedenen IWFs für dasselbe Endsystem miteinander in Beziehung zu bringen, wenn das Endsystem sich von einer IWF zu einer anderen bewegt. Für Weiterschaltungen über IWF-Grenzen ist die Acct-Session-ID oder Abrechnungssitzungs-ID verschieden für Abrechnungssätze, die von verschiedenen IWFs stammen. Das Acct-Multi-Session-ID- oder Mehrfach-Abrechnungssitzungs-ID-Attribut ist jedoch dasselbe für alle Abrechnungssätze, die von allen IWFs ausgegeben wurden, die den Benutzer versorgten. Da die Sitzungs-ID und die Mehrfachsitzungs-ID sowohl dem Fremdnetz als auch dem Heimatnetz bekannt sind, sind sie imstande, diese Attribute in Abrechnungsberichten an ihre jeweiligen Abrechnungsserver auszugeben. Mit der Sitzungs-ID und der Mehrfachsitzungs-ID sind Gebührenverrechnungssysteme imstande, Abrechnungssätze über IWF-Grenzen im selben Drahtlosdiensteanbieter und sogar über Drahtlosdiensteanbietergrenzen zu korrelieren.
    • 1. Accounting Delay Time (Abrechnungsverzögerungszeit). Siehe Radius Acct-Delay-Time-Attribut.
    • 2-. Accounting Input Octets. Siehe Radius Acct-Input-Octets. Dieses Attribut wird verwendet, um die Anzahl von Oktetten im Auge zu behalten, die durch das Endsystem gesendet werden (eingegeben ins Netz vom Endsystem). Diese Zählung wird verwendet, um nur die PPP-Rahmen zu verfolgen. Die Luftverbindungszusatzaufwand oder irgendein Zusatzaufwand, der durch RLP usw. eingeführt wird, wird nicht gezählt.
    • 3. Accounting Output Octets. Siehe Radius Acct-Output-Octets. Dieses Attribut wird verwendet, um die Anzahl von Oktetten im Auge zu behalten, die an das Endsystem gesendet werden (ausgegeben vom Netz zum Endsystem). Diese Zählung wird verwendet, um nur die PPP-Rahmen zu verfolgen. Der Luftverbindungszusatzaufwand oder irgendein Zusatzaufwand, der durch RLP usw. eingeführt wird, wird nicht gezählt.
    • 4. Accounting Authentic (Abrechnung authentisch). Siehe Radius Acct-Authentic-Attribut. Der Wert dieses Attributs ist in Abhängigkeit davon, ob die versorgende IWF oder die Heimat-IWF den Abrechnungssatz erzeugt, Local oder Remote (abgesetzt).
    • 5. Accounting Session Time. Siehe Radius Acct-Session-Time-Attribut. Dieses Attribut zeigt die Dauer von Zeit an, die der Benutzer versorgt wurde. Wenn durch die versorgende IWF gesendet, verfolgt dieses Attribut die Zeitdauer, die der Benutzer von der versorgenden IWF versorgt wurde. Wenn durch die Heimat-IWF gesendet, verfolgt dieses Attribut die Zeitdauer, die der Benutzer von der Heimat-IWF versorgt wurde.
    • 6. Accounting Input Packets. Siehe Radius Acct-Input-Packets-Attribut. Dieses Attribut zeigt die Anzahl von Paketen an, die vom Endsystem empfangen werden. Für eine versorgende IWF verfolgt dieses Attribut die Anzahl von PPP-Rahmen, die von einem Endsystem in die versorgende IWF eingegeben werden. Für eine Heimat-IWF verfolgt dieses Attribut die Anzahl von PPP-Rahen, die von einem Endsystem in die Heimat-IWF eingegeben werden.
    • 7. Accounting Output Packets. Siehe Radius Acct-Output-Packets-Attribut. Dieses Attribut zeigt die Anzahl von Paketen an, die an das Endsystem gesendet werden. Für eine versorgende IWF verfolgt dieses Attribut die Anzahl von PPP-Rahmen, die von einer versorgenden IWF an ein Endsystem ausgegeben werden. Für eine Heimat-IWF verfolgt dieses Attribut die Anzahl von PPP-Rahen, die von einer Heimat-IWF an ein Endsystem ausgegeben werden.
    • 8. Accounting Terminate Cause. Siehe Radius Acct-Terminate-Cause-Attribut. Dieses Attribut gibt die Ursache dafür an, warum eine Benutzersitzung beendet wurde. Außerdem ist ein spezifischer Ursachencode vorhanden, um zusätzliche Details bereitzustellen. Dieses Attribut ist nur in Abrechnungsberichten am Ende der Sitzung vorhanden.
    • 9. Network Accounting Terminate Cause. Dieses Attribut gibt die Ursache für die Beendigung einer Sitzung detailliert an. Dieses spezifische Attribut wird als ein herstellerspezifisches Attribut codiert und wird nur in einem Radius Accounting-Attribut am Ende der Sitzung gemeldet. Das Radius-Standardattribut Acct-Terminat-Cause ist ebenfalls vorhanden. Dieses Attribut stellt spezifische Ursachencodes bereit, die durch das Acct-Terminate-Cause-Attribut nicht gedeckt werden.
    • 10. Network Air Link Access Protocol. Dieses Attribut gibt das Luftverbindungszugangsprotokoll an, das vom Endsystem verwendet wird. Dieses Attribut wird als herstellerspezifisches Attribut codiert.
    • 11. Network Backhaul Access Protocol. Dieses Attribut gibt das Backhaul-Zugangsprotokoll an, das vom Zugangspunkt verwendet wird, um Daten zum und vom Endsystem zu übertragen. Dieses Attribut wird im herstellerspezifischen Format codiert.
    • 12. Network Agent Machine Name. Dieses Attribut ist der voll qualifizierte Domänenname der Maschine, welche die Heimat-IWF oder die versorgende IWF ausführt. Dieses spezifische Attribut wird im herstellerspezifischen Format codiert.
    • 13. Network Accounting Check-point. Da die Radius-Abrechnungs-RFC kein Kontrollpunktpaket definiert, verwendet die vorliegende Erfindung ein Radius-Abrechnungsstartpaket mit diesem Attribut, um einen Kontrollpunkt zu markieren. Das Nichtvorhandensein dieses Attributs bedeutet ein herkömmliches Abrechnungsstartpaket. Das Vorhandensein dieses Attributs in einem Abrechnungsstartpaket bedeutet ein Abrechnungskontrollpunktpaket. Abrechnungsstopppakete weisen dieses Attribut nicht auf.
  • In einer bevorzugten Ausführungsform müssen jedes Abrechnungspaket und die entsprechende Antwort unter Verwendung des MD5 und eines gemeinsam benutzten Geheimcodes authentifiziert werden. Die IWFs sind mit einem gemeinsam benutzten Geheimcode konfiguriert, der von ihnen während der Kommunikation mit ihrem Radius-Abrechnungsserver zur Authentifizierung verwendet wird. Die gemeinsam benutzten Geheimcodes, die von den IWFs zum Kommunizieren mit ihren Abrechnungsservern verwendet werden, sind im Heimat/Fremddomänenverzeichnis gespeichert, das sich in der MSC befindet. Die gemeinsam benutzten Geheimcodes für Abrechnungssicherheit werden den IWFs durch ihre Registrierungsserver während der Endsystemregistrierungsfolge kommuniziert.
  • Die Abrechnungsserversoftware läuft in einem Computer, der sich in der MSC befindet. Die Funktion des Abrechnungsservers im System ist es, Rohabrechnungsdaten von den Netzelementen (den Heimat- und versorgenden IWFs) zu sammeln, die Daten zu verarbeiten und sie zur Übertragung an das Gebührenverrechnungssystem des Drahtlosdiensteanbieters zu speichern. Der Abrechnungsserver weist kein Gebührenverrechnungssystem auf. Stattdessen weist er eine Unterstützung für einen automatischen oder manuellen Abrechnungsdatenübertragungsmechanismus auf. Bei Verwenden des automatischen Abrechnungsdatenübertragungsmechanismus überträgt der Abrechnungsserver Abrechnungssätze in einem AMA-Rechnungsformat über eine TCP/IP-Übertragung an das Kundengebührenverrechnungssystem. Zu diesem Zweck definiert das System AMA-Rechnungsprotokollformate für Paketdaten. Bei Verwenden des manuellen Übertragungsmechanismus sind Kunden imstande, ein Band zu bilden, um Abrechnungssätze an ihr Gebührenverrechnungssystem zu übertragen. Um das Band zu ihren Spezifikationen zu bilden, werden die Kunden mit Informationen versehen, um auf Abrechnungssätze zuzugreifen, damit sie sie verarbeiten können, bevor sie sie aufs Band schreiben.
  • In 25 werden die Rohabrechnungsdaten, die durch den Abrechnungsserver von den Heimat- oder versorgenden IWFs empfangen werden, verarbeitet und durch den Abrechnungsserver gespeichert. Die Verarbeitung, die durch den Abrechnungsserver erfolgt, umfasst Filterung, Kompression und Korrelation der Rohabrechnungsdaten, die von der IWF empfangen werden. Ein hochverfügbarer Dateiserver, der Aktiv/In-Bereitschaft-Doppelprozessoren und austauschbare RAID-Platten verwendet, wird zum Puffern der Abrechnungsdaten verwendet, während sie den Abrechnungsserver durchqueren.
  • Der Abrechnungsserver verzögert die Verarbeitung der Rohabrechnungsdaten, bis ein Endsystem seine Sitzung beendet hat. Wenn ein Endsystem seine Sitzung beendet, verarbeitet der Abrechnungsserver die Rohabrechnungsdaten, die er für die Sitzung gesammelt hat und speichert einen Abrechnungsauszugssatz in einer SQL-Datenbank. Der Abrechnungsauszugssatz, der in der SQL-Datenbank gespeichert ist, zeigt auf eine ASN.1-codierte Datei. Diese Datei enthält detaillierte Abrechnungsinformationen über die Sitzung des Endsystems. Die Daten, die im Abrechnungsserver gespeichert sind, werden dann durch den Rechnungsdatenübertragungsagenten an das Kundengebührenverrechnungssystem übertragen. Alternativerweise kann der Drahtlosdiensteanbieter die Abrechnungsdaten von der SQL-Datenbank und/oder der ASN.1-codierten Datei über ein Band an das Gebührenverrechnungssystem übertragen. Das Datenbankschema und das Format der ASN.1-codierten Datei werden dokumentiert und den Kunden für diesen Zweck zugänglich gemacht. Wenn das Volumen von verarbeiteten Abrechnungsdaten, die im Abrechnungssystem gespeichert sind, eine Hochwassermarke überschreitet, erzeugt der Abrechnungsserver einen NMS-Alarm. Dieser Alarm wird aufgehoben, wenn das Volumen von Daten, die im Abrechnungsserver gespeichert sind, unter eine Niedrigwassermarke fällt. Die Hoch- und die Niedrigwassermarke zum Erzeugen und Aufheben des Alarm sind konfigurierbar. Der Abrechnungsserver erzeugt einen NMS-Alarm auch, wenn das Alter der gespeicherten Abrechnungsdaten eine konfigurierbare Schwelle überschreitet. Umgekehrt wird der Alarm aufgehoben, wenn das Alter der Abrechnungsdaten unter die Schwelle fällt.
  • Das Teilnehmerverzeichnis wird verwendet, um Informationen über Teilnehmer zu speichern und befindet sich im Heimatnetz. Der Heimatregistrierungsserver konsultiert dieses Verzeichnis während der Registrierungsphase, um ein Endsystem zu authentifizieren und zu registrieren. Für jeden Teilnehmer speichert das Teilnehmerverzeichnis die folgenden Informationen:
    • 1. User-Name (Benutzer-Name). Dieses Feld im Teilnehmerdatensatz ist im SMTP-Format (z.B. user@fgdn), wobei das user-Teilfeld den Teilnehmer in seiner drahtlosen Heimatdomäne und das fgdn-Teilfeld die drahtlose Heimatdomäne des Teilnehmers identifiziert. Dieses Feld wird durch das Endsystem in der Registrierungsaufforderung während der Registrierungsphase gesendet. Dieses Feld wird durch den Drahtlosdiensteanbieter dem Teilnehmer zum Zeitpunkt der Antragstellung für den Netzdienst zugeordnet. Dieses Feld unterscheidet sich von dem Benutzernamenfeld, das im PPP verwendet wird.
    • 2. Mobility Security Association. Dieses Feld im Teilnehmerdatensatz enthält die Mobilitätssicherheitsvereinbarung zwischen dem Teilnehmer und seinem Heimatnetz. Wie bereits erwähnt, besteht eine Mobilitätssicherheitsvereinbarung zwischen jedem Teilnehmer und seinem Heimatregistrierungsserver. Die Mobilitätssicherheitsvereinbarung definiert eine Sammlung von Sicherheitskontexten. Jeder Sicherheitskontext definiert einen Authentifizierungsalgorithmus, einen Authentifizierungsmodus, einen gemeinsam benutzten Geheimcode, ein Wiederholungsschutzformat und eine Verschlüsselungsart (einschließlich ohne Verschlüsselung) zur Verwendung zwischen dem Endsystem und seinem Heimatserver. Während der Registrierung ruft der Heimatregistrierungsserver unter Verwendung des User-Name und des Sicherheitsparameterindexes (SPI), die durch den Endsystem in seiner Registrierungsaufforderung geliefert werden, Informationen über den Sicherheitskontext des Teilnehmers aus dem Teilnehmerverzeichnis ab. Die Informationen im Sicherheitskontext werden zum Erzwingen von Authentifizierung, Verschlüsselung und Wiederholungsschutz während der Sitzung verwendet. Die Mobilitätssicherheitsvereinbarung wird durch den Drahtlosdiensteanbieter zum Zeitpunkt der Antragstellung erzeugt. Es liegt am Drahtlosdiensteanbieter, ob er es dem Teilnehmer entweder durch einen Anruf bei einem Kundendienstrepräsentanten oder, indem er die Teilnehmer auf eine sichere Web-Site zugreifen lässt, gestattet, diese Vereinbarung zu modifizieren. Die Web-Site-Software exportiert Webseiten, welche der Drahtlosdiensteanbieter von einem sicheren Webserver für die Teilnehmer zugänglich macht. Auf diese Weise sind Teilnehmer imstande, neben anderen Teilnehmerinformationen, die der Diensteanbeiter möglicherweise zugänglich macht, auch die Inhalte der Mobilitätssicherheitsvereinbarung einzusehen/zu modifizieren.
    • 3. Modem MAC Address. Dieses Feld enthält die MAC-Adresse des Modems, das dem Teilnehmer gehört. Zusätzlich zum gemeinsam benutzten Geheimcode wird dieses Feld während der Registrierung verwendet, um den Benutzer zu identifizieren. Es ist möglich, eine MAC-Adressen-basierte Authentifizierung auf einer Pro-Benutzer-Basis auszuschalten. Die MAC-Adresse wird dem Heimatregistrierungsserver während der Registrierung kommuniziert.
    • 4. Enable MAC Address Authentication (MAC-Adressen-Authentifizierung Freigeben). Dieses Feld wird verwendet, um festzustellen, ob die MAC-Adressen-basierte Authentifizierung enabled (freigegeben) oder disabled (gesperrt) ist. Wenn enabled, dann überprüft der Heimatregistrierungsserver die MAC-Adresse des zu registrierenden Endsystems mit diesem Feld, um die Identität des Endsystems zu bestätigen. Wenn disabled, dann erfolgt keine Überprüfung.
    • 5. Roaming Enabled Flag (Roaming-Freigegeben-Flagge). Wenn dieses Feld auf enabled gesetzt ist, dann darf das Endsystem zu Fremdnetzen wandern. Wenn dieses Feld disabled ist, dann darf das System nicht zu Fremdnetzen wandern.
    • 6. Roaming Domain List (Roaming-Domänenliste). Dieses Feld ist nur von Bedeutung, wenn das Roaming Enabled Flag auf enabled gesetzt ist. Dieses Feld enthält eine Liste von fremden Domänen, in die das Endsystem wandern darf. Wenn der Inhalt dieser Liste null ist und die Roaming Enabled Flag auf enabled gesetzt ist, darf das Endsystem frei wandern.
    • 7. Service Enable/Disable Flag (Dienst-Freigeben/Sperren-Flagge). Dieses Feld kann durch den Systemadministrator auf disable gesetzt werden, um einen Dienst für einen Teilnehmer zu sperren. Wenn dieses Feld gesperrt ist, dann darf der Teilnehmer sich für den Dienst registrieren lassen. Wenn der Teilnehmer registriert ist und der Wert dieses Feldes auf gesperrt gesetzt ist, dann wird das Endsystem des Teilnehmers durch das Netz unverzüglich getrennt.
    • 8. Internet Service Provider Association (Internetdiensteanbietervereinbarung). Dieses Feld enthält Informationen über den Internetdiensteanbieter des Teilnehmers. Diese Informationen werden durch die IWF während der PPP-Registrierungsphase verwendet, um eine Authentifizierung mit dem Internetdiensteanbieter für das Endsystem durchzuführen, und auch, um einen L2TP-Tunnel zwischen der IWF und dem PPP-Server des Internetdiensteanbieters zu erzeugen. Das Feld enthält die Identität des ISPs des Teilnehmers. Die IWF verwendet diese Informationen, um zum Durchführen der Authentifizierung und des Aufbaus des L2TP-Tiunnels für das Endsystem auf das ISP-Verzeichnis zuzugreifen.
    • 9. Subscriber's Name & Address Information. Dieses Feld enthält Name, Adresse, Telefonnummer, Faxnummer, E-Mail-Adresse usw. des Teilnehmers.
  • Das Heimatdomänenverzeichnis (HDD) wird durch den Registrierungsserver verwendet, um Parameter über das Endsystem abzurufen, um die Registrierung für das Endsystem abzuschließen. Durch Verwenden dieser Informationen bestimmt der Registrierungsserver, ob das Endsystem sich zu Hause registrieren lässt oder ob das Endsystem ein Gast-Endsystem ist. Im ersteren Fall übernimmt der Registrierungsserver die Funktion eines Heimatregistrierungsservers und verfährt mit der Endsystemregistrierung. Im letzteren Fall übernimmt der Registrierungsserver die Funktion eines fremden Registrierungsservers und leitet als Radius-Proxy agierend die Aufforderung zum echten Heimatregistrierungsserver, dessen Identität er aus diesem Verzeichnis erhält. Für ein Gast-Endsystem umfassen die Parameter, die im HDD gespeichert sind, die IP-Adresse des Heimatregistrierungsservers, den heimat-fremdseitig gemeinsam benutzten Geheimcode, die Konfiguration des Tunnels zwischen Heimat- und versorgender IWF usw. Das HDD befindet sich in der MSC.
  • Die folgenden Informationen sind im HDD gespeichert:
    • 1. Home Domain Name (Heimatdomänenname). Dieses Feld wird als Schlüssel beim Absuchen des HDDs nach einem Eintrag verwendet, der mit dem voll qualifizierten Heimatdomänennamen übereinstimmt, der durch das Endsystem in seiner Registrierungsaufforderung geliefert wird.
    • 2. Proxy Registration Request (Proxy-Registrierungsaufforderung). Dieses Feld wird durch den Registrierungsserver verwendet, um festzustellen, ob er als ein fremder Registrierungsserver agieren und die Registrierungsaufforderung des Endsystems zum echten Heimatregistrierungsserver durchreichen soll.
    • 3. Home Registration Server DNS Name (DNS-Name des Heimatregistrierungsservers). Wenn die Proxy-Registrierungsaufforderungs-Flagge auf TRUE (wahr) ist, dann wird dieses Feld verwendet, um auf den DNS-Namen des Heimatregistrierungsservers zuzugreifen. Andernfalls wird dieses Feld ignoriert. Der DNS-Name wird durch den fremden Registrierungsserver in eine IP-Adresse übersetzt. Der fremde Registrierungsserver verwendet die IP-Adresse, um die Registrierungsaufforderung des Endsystems weiterzuleiten.
    • 4. Foreign Domain Name (Fremder Domänenname). Wenn die Proxy-Registrierungsaufforderungs-Flagge auf TRUE (wahr) ist, dann wird dieses Feld verwendet, um den fremden Domänennamen für den Heimatregistrierungsserver des Endsystems zu identifizieren. Andernfalls wird dieses Feld ignoriert. Der fremde Registrierungsserver verwendet diese Informationen, um die Maschinen-ID des fremden Servers im SMTP-Format, zum Beispiel machine@fgdn, zu erzeugen. Diese Maschinen-ID wird durch den fremden Registrierungsserver in der Radius Access-Request oder Radius-Zugangsanforderung an den Heimatregistrierungsserver gesendet.
    • 5. Shared Secret (Gemeinsam benutzter Geheimcode). Wenn die Proxy-Registrierungsaufforderungs-Flagge auf TRUE (wahr) ist, wird der gemeinsam benutzte Geheimcode zwischen dem fremden und dem Heimatregistrierungsserver verwendet, um ihre Identitäten untereinander zu identifizieren. Andernfalls wird das Feld ignoriert.
    • 6. Tunneling Protocol Parameters. Dieses Feld wird zum Speichern von Parametern verwendet, um die Tunnel zur Versorgung des Endsystems zu konfigurieren. Für ein Endsystem zu Hause umfasst es Informationen über Tunnelparameter zwischen der Basisstation und der Heimat-IWF und von der Heimat-IWF zum PPP-Server. Für ein Gast-Endsystem umfasst es Tunnelparameter von der Basisstation zur versorgenden IWF und von der versorgenden IWF zur Heimat-IWF. Für jeden Tunnel enthält dieses Feld wenigstens die Art des zu verwendenden Tunnelprotokolls und irgendwelche tunnelprotokollspezifischen Parameter. Zum Beispiel kann dieses Feld die Kennung für das Tunnelprotokoll L2TP und irgendwelche zusätzlichen Parameter enthalten, die erforderlich sind, um den L2TP-Tunnel zwischen der IWFD und ihrem Partner zu konfigurieren.
    • 7. Accounting Server Association (Abrechnungsserververeinbarung). Dieses Feld wird verwendet, um Informationen zu speichern, die durch die IWF zum Erzeugen von Abrechnungsdaten für das Endsystem benötigt werden. Es enthält den Namen des Abrechnungsprotokolls (z.B. RADIUS), den DNS-Namen des Abrechnungsservers und zusätzliche Parameter, die für das Abrechnungsprotokoll spezifisch sind, wie die UDP-Port-Nummer, den gemeinsam benutzten Geheimcode, den die IWF im Radius Accounting- oder Radius-Abrechnungsprotokoll verwenden muss, die Häufigkeit der Kontrollpunktmarkierung, den Anfangswert zum Erzeugen der Sitzungs-/Mehrfachsitzungs-ID usw. Der DNS-Name des Abrechnungsservers wird in die IP-Adresse des Abrechnungsservers übersetzt, welche an die IWF gesendet wird.
  • Für Drahtlosdiensteanbeiter, die Roaming-Vereinbarungen miteinander haben, wird das HDD zur Authentifizierung und zum Abschluss des Registrierungsprozesses verwendet. Wenn ein Endsystem von seinem Heimatnetz in ein Fremdnetz wandert, konsultiert der fremde Registrierungsserver in diesem Netz das HDD in seiner MSC, um Informationen über die Heimatregistrierung des Besucher-Endsystems zu erhalten und das Heimatnetz zu authentifizieren, bevor er das Besucher-Endsystem versorgt.
  • Die Software für die Heimatdomänenverzeichnisverwaltung stellt vorzugsweise eine HDD-Verwaltungsschnittstelle für Systemadministratoren bereit, die auf einer graphischen Benutzeroberfläche (GUI für engl. graphical user interface) basiert. Durch Verwenden dieser GUI sind Systemadministratoren imstande, die Einträge im HDD einzusehen und zu aktualisieren. Diese GUI ist nicht zur Verwendung durch fremde Drahtlosnetzdiensteanbieter gedacht, um auf der Basis von Roaming-Vereinbarungen Fernaktualisierungen durchzuführen. Sie ist nur zur Verwendung durch zuverlässiges Personal des Heimat-Drahtlosdiensteanbieters bestimmt und arbeitet hinter Firewalls.
  • Das Fremddomänenverzeichnis (FDD) stellt eine Funktionalität bereit, welche die Umkehr des Heimatdomänenverzeichnisses ist. Das FDD wird durch den Heimatregistrierungsserver verwendet, um Parameter über den fremden Registrierungsserver und das Fremdnetz abzurufen, um das fremde Netz zu authentifizieren und einen Tunnel zwischen einer versorgenden IWF und eine Heimat-IWF zu erzeugen. Diese Parameter umfassen den heimat-fremdseitig gemeinsam benutzten Geheimcode, die Konfiguration des Tunnels zwischen Heimat-IWF und versorgender IWF usw. Das FDD befindet sich vorzugsweise in der MSC des Heimatregistrierungsservers. Das FDD wird durch den Heimatregistrierungsserver zum Registrieren von Gast-Endsystemen verwendet.
  • Die folgenden Informationen sind im FDD gespeichert:
    • 1. Foreign Domain Name. Dieses Feld wird als Schlüssel beim Absuchen des FDDs nach einem Eintrag verwendet, der mit dem voll qualifizierten Domänennamen des fremden Registrierungsservers, der die Registrierungsaufforderung weiterleitet, übereinstimmt.
    • 2. Shared Secret. Dies ist der gemeinsam benutzte Geheimcode, der zwischen dem fremden und dem Heimatregistrierungsserver verwendet wird, um sich gegenseitig ihre Identität zu authentifizieren.
    • 3. Home IWF-Serving UWF Tunneling Protocol Parameters. Dieses Feld wird zum Speichern von Parametern verwendet, um den Tunnel zwischen der Heimat-IWF und der versorgenden IWF zu konfigurieren. Dieses Feld enthält wenigstens die Art des zu verwendenden Tunnelprotokolls und irgendwelche tunnelprotokollspezifischen Parameter. Zum Beispiel kann dieses Feld die Kennung für das Tunnelprotokoll L2TP und irgendwelche zusätzlichen Parameter enthalten, die erforderlich sind, um den L2TP-Tunnel zwischen der versorgenden IWF und der Heimat-IWF zu konfigurieren.
    • 4. Accounting Server Association (Abrechnungsserververeinbarung). Dieses Feld wird verwendet, um Informationen zu speichern, die durch die Heimat-IWF zum Erzeugen von Abrechnungsdaten für das Endsystem benötigt werden. Es enthält den Namen des Abrechnungsprotokolls (z.B. RADIUS), den DNS-Namen des Abrechnungsservers und zusätzliche Parameter, die für das Abrechnungsprotokoll spezifisch sind, wie die UDP-Port-Nummer, den gemeinsam benutzten Geheimcode, den die IWF im Radius Accounting-Protokoll verwenden muss, die Häufigkeit der Kontrollpunktmarkierung, den Anfangswert zum Erzeugen der Sitzungs-/Mehrfachsitzungs-ID usw. Der DNS-Name des Abrechnungsservers wird in die IP-Adresse des Abrechnungsservers übersetzt, welche an den fremden Agenten gesendet wird.
  • Für Drahtlosdiensteanbieter, die Roaming-Vereinbarungen miteinander haben, wird das FDD zur Authentifizierung und zum Abschluss des Registrierungsprozesses verwendet. Wenn ein Endsystem von seinem Heimatnetz in ein Fremdnetz wandert, konsultiert der Registrierungsserver im Heimatnetz das FDD in seiner MSC, um Informationen zu erhalten und das Fremdnetz zu authentifizieren, welches das Endsystem versorgt.
  • Die Software für die Fremddomänenverzeichnisverwaltung stellt vorzugsweise eine FDD-Verwaltungsschnittstelle für Systemadministrator bereit, die auf einer graphischen Benutzeroberfläche (GUI) basiert. Durch Verwenden dieser GUI sind Systemadministratoren imstande, die Einträge im FDD einzusehen und zu aktualisieren. Diese GUI ist nicht zur Verwendung durch fremde Drahtlosnetzdiensteanbieter gedacht, um auf der Basis von Roaming-Vereinbarungen Fernaktualisierungen durchzuführen. Sie ist nur zur Verwendung durch zuverlässiges Personal des Heimat-Drahtlosdiensteanbieters bestimmt und arbeitet hinter Firewalls.
  • Das Internetdiensteanbieterverzeichnis (ISPD) wird durch die Heimat-IWF verwendet, um die Verbindungsfähigkeit mit ISPs zu verwalten, die Dienstvereinbarungen mit dem Drahtlosdiensteanbieter haben, damit Teilnehmer unter der Verwendung des Netzes auf ihre ISPs zugreifen können. Für jeden Teilnehmer weist das Teilnehmerverzeichnis einen Eintrag für den ISP des Teilnehmers auf. Dieses Feld zeigt auf einen Eintrag im ISPD. Die Heimat-IWF verwendet diese Informationen, um die Verbindung mit dem ISP für den Teilnehmer aufzubauen.
  • Die Netzarchitektur unterstützt Roaming. Damit ein Roaming zwischen Drahtlosdiensteanbietern funktioniert, muss die Architektur das Aufstellen von Roaming-Vereinbarungen zwischen Drahtlosdiensteanbietern unterstützen. Dies bringt zweierlei mit sich: (1) Aktualisierung von Systemverzeichnissen über Drahtlosdiensteanbieter und (2) Zahlung von Rechnungen zwischen Diensteanbietern.
  • Um Teilnehmern den Zugriff auf Internetdiensteanbieter zu erlauben, unterstützt die Architektur Roaming-Vereinbarungen mit Internetdiensteanbietern. Dies bringt mit sich, dass die Architektur imstande sein muss, Daten an ISP-PPP-Server zu senden und Daten von ISP-PPP-Servern zu empfangen (d.h. die Industriestandardprotokolle wie PPP, L2TP und Radius unterstützen). Es bringt auch mit sich, dass die Architektur Verzeichnisaktualisierungen für den ISP-Zugang bearbeitet und die Zahlung von Rechnungen mit ISPs abwickelt.
  • Wenn Roaming-Vereinbarungen zwischen zwei Drahtlosdiensteanbietern getroffen werden, müssen beide Anbieter ihre Heimat- und Fremddomänenverzeichnisse aktualisieren, um Authentifizierungs- und Registrierungsfunktionen für Endsysteme, die ihre Netze vom anderen Netz besuchen, zu unterstützen. Die Architektur der vorliegenden Ausführungsform unterstützt wenigstens manuelle Verzeichnisaktualisierungen. Wenn eine Roaming-Vereinbarung zwischen zwei Drahtlosdiensteanbietern getroffen wird, dann tauschen die beiden Vereinbarungspartner Informationen zum Bestücken ihrer Heimat- und Fremddomänenverzeichnisse aus. Die tatsächlichen Aktualisierungen der Verzeichnisse erfolgt manuell durch Personal der jeweiligen Diensteanbieter. Wenn später die Informationen in den Heimat- und Fremddomänenverzeichnissen aktualisiert werden müssen, tauschen die beiden Vereinbarungspartner die aktualisierten Informationen aus und wenden dann ihre Aktualisierungen manuell auf die Verzeichnisse an.
  • In einer alternativen Ausführungsform umfasst die Verzeichnisverwaltungssoftware Entwicklungsstandards in der IETF, um ein Roaming zwischen Internetdiensteanbietern zu ermöglichen und ISPs zu befähigen, Roaming-Verhältnisse automatisch zu verwalten und zu ermitteln. Dies macht eine manuelle Verzeichnisverwaltung nicht mehr nötig. Das Netzsystem verbreitet Roaming-Verhältnisse automatisch und ermittelt sie, um Besucher-Endsysteme zu authentifizieren und zu registrieren.
  • Die Netzarchitektur verarbeitet und speichert wenigstens die Abrechnungsdaten und stellt die Daten dem Gebührenverrechnungssystem des Drahtlosdiensteanbieters zur Verfügung. Es liegt am Gebührenverrechnungssystem, die Zahlung von Rechnungen für das Roaming abzuwickeln.
  • In einer alternativen Ausführungsform werden Entwicklungsstandards in der IETF zum Abwickeln der Verteilung von Abrechnungssätzen zwischen Internetdiensteanbietern in die Netzarchitektur aufgenommen, um ISPs zu befähigen, die Zahlung von Rechnungen für Gast-Endsysteme durchzuführen.
  • Die Systemsoftware unterstützt den Zugang zu IPS und privaten Intranets durch Unterstützen des L2TPs zwischen der Heimat-IWF und dem ISP- oder Intranet-PPP-Server der. Das Internetdiensteanbieterverzeichnis enthält Informationen, die für die IWF zum Erzeugen dieser Tunnel nützlich sind. Wenn Zugangsvereinbarungen zwischen dem Drahtlosdiensteanbieter und den Internetdiensteanbietern etabliert sind, wird dieses Verzeichnis durch das Personal des Drahtlosdiensteanbieters manuell aktualisiert. Automatische Aktualisierungen und eine automatische Ermittlung von Zugangsverhältnissen zwischen dem Drahtlosdiensteanbieter und Internetdiensteanbietern sind ins Auge gefasst und werden implementiert, sobald die Internetstandards weiter entwickelt sind. Während der Teilnehmer auf einen Internetdiensteanbieter zugreift, empfängt er zwei Rechnungen – eine vom Drahtlosdiensteanbieter für die Verwendung des drahtlosen Netzes, und die zweite vom Internetdiensteanbieter. Obwohl durch die Software der Mindestausführungsform keine gemeinsame Vergebührung, welche die beiden Arten von Gebühren vereinigt, abgewickelt wird, ist vorgesehen, dass die Software die Internetstandards für Rechnungszahlung, sobald sie weiter entwickelt sind, nutzen wird, damit Teilnehmer eine gemeinsame Rechnung basierend auf Roaming-Vereinbarungen zwischen dem ISP und Drahtlosdiensteanbietern empfangen können.
  • Das System weist ein Elementverwaltungssystem zum Verwalten der Netzelemente auf. Vom Elementverwalter führen Systemadministratoren Konfigurations-, Erfüllungs- und Fehler/Alarmverwaltungsfunktionen aus. Die Elementverwaltungsanwendungen laufen über einem Webbrowser. Bei Verwenden eines Webbrowsers verwalten Systemadministratoren das Netz von überall, von wo sie einen TCP/IP-Zugang haben. Der Elementverwalter führt auch eine Agentenfunktion für einen übergeordneten Verwalter aus. In dieser Funktion exportiert er eine SNMP MIB zur Alarm- und Fehlerüberwachung.
  • Ein übergeordneter SNMP-Verwalter wird über SNMP-Unterbrechungen von Alarmbedingungen unterrichtet. Der übergeordnete SNMP-Verwalter fragt die MIB des Elementverwalters regelmäßig hinsichtlich der Gesundheit und des Status des Netzes ab. Das Systemverwaltungspersonal beim übergeordneten Verwalter ist imstande, eine Bildschirmsymboldarstellung des Netzes und seines aktuellen Alarmzustands einzusehen. Durch Zeigen und Klicken auf das Netzelementsymbol kann das Systemverwaltungspersonal unter Verwendung eines Webbrowsers Elementverwaltungsanwendungen ausführen und genauere Verwaltungsfunktionen durchführen.
  • Innerhalb des Netzes erfolgt die Verwaltung der physikalischen und logischen Netzelemente unter Verwendung einer Kombination des SNMP-Protokolls und internen Verwaltungsanwendungsprogrammierschnittstellen. Anwendungen im Elementverwalter verwenden SNMP- oder andere Verwaltungs-APIs zur Ausführung von Netzverwaltungsfunktionen.
  • Architektonisch weist ein Elementverwaltungssystem zwei verschiedene Sätze von Funktionselementen auf. Der erste Satz von Funktionselementen, welcher die Konfigurationsdatenserver-, Leistungsdatenüberwachungs-, Gesundheits/Statusüberwachungs- und Netzelementwiederherstellungs-Software umfasst, läuft auf einem HA-Server, der mit RAID-Platten ausgestattet ist. Der zweite Satz von Funktionselementen, welcher die Verwaltungsanwendungen umfasst, läuft auf einem dedizierten Nicht-HA-Verwaltungssystem. Selbst wenn das Elementverwaltungssystem betriebsunfähig wird, sind die Netzelemente weiter imstande, zu laufen und Alarme zu melden, und sie sind sogar imstande, sich von Störbedingungen zu regenerieren. Da jedoch alle Verwaltungsanwendungen im Nicht-HA-Elementverwalter ablaufen, sind dann, wenn der Elementverwalter ausfällt, Wiederherstellungsmaßnahmen, die der Intervention von Menschen bedürfen, nicht möglich, bis der Elementverwalter wieder betriebsfähig wird.
  • Die drahtlosen Hubs (WHs) in den Basisstationen gehören normalerweise einem Drahtlosdiensteanbeiter (WSP) und sind über Punkt-zu-Punkt-Verbindungen, Intranets oder das Internet mit dem Registrierungsserver (RS) des WSPs verbunden. Der WSP-Registrierungsserver ist normalerweise ein Softwaremodul, das auf einem Prozessor läuft, um bestimmte Registrierungsfunktionen auszuführen. Netzübergangsfunktionseinheiten (IWF-Einheiten) sind normalerweise Softwaremodule, die auf einem Prozessor laufen, um bestimmte Anbindungsfunktionen auszuführen. Die IWF-Einheiten sind normalerweise über Intranets/WAN mit den Registrierungsservern verbunden, und die IWF-Einheiten gehören normalerweise dem WSP. Die IWF-Einheiten brauchen jedoch nicht innerhalb desselben LANs wie die Registrierungsserver angeordnet zu sein. Normalerweise sind Abrechnungs- und Verzeichnisserver (ebenfalls Softwaremodule, die auf einem Prozessor laufen) über ein LAN im Datenzentrum des Diensteanbieters (z.B. einem Zentrum, das einen oder mehr Prozessoren aufweist und verschiedenen Servern und anderen Softwaremodulen als Host dient) mit den Registrierungsservern verbunden. Der Verkehr vom Endsystem wird dann über einen Router (verbunden mit dem LAN) zum öffentlichen Internet oder zu einem ISP-Intranet geleitet. Der Registrierungsserver, der sich in einem WSP-Fremdnetz befindet, wird als der fremde Registrierungsserver (FRS) bezeichnet, und der Registrierungsserver, der im Heimatnetz des Endsystems (wo die Mobileinheit ihren Dienst erwirbt) angeordnet ist, wird als der Heimatregistrierungsserver (HRS) bezeichnet. Die Netzübergangsfunktionseinheit im Heimatnetz wird als die Heimat-IWF bezeichnet, während die Netzübergangsfunktion im Fremdnetz (d.h. im Netz, das vom Endsystem besucht wird) als die versorgende IWF bezeichnet wird.
  • Für feste drahtlose Dienste (d.h. ein sich nicht bewegendes Endsystem) kann ein Endsystem sich für einen Dienst auf dem Heimatnetz vom Heimatnetz (z.B. Zu-Hause-Dienst) oder von einem Fremdnetz (z.B. einem Roaming-Dienst) registrieren lassen. Das Endsystem empfängt eine Ankündigung, die durch einen Agenten (z.B. einer Agentenfunktion, die in Software implementiert ist) im drahtlosen Hub über den Zugangspunkt gesendet wird. Es ist sowohl eine MAC-Schicht-Registrierung als auch eine Netzschichtregistrierung zu bewerkstelligen. Diese können zur besseren Wirksamkeit miteinander verknüpft werden.
  • Für Endsystem zu Hause (26) wird die Netzschichtregistrierung (wie eine lokale Registrierung) über den drahtlosen Hub, an welchen das Endsystem gerade angeschlossen ist, an den Heimatregistrierungsserver gesendet. Eine IWF im Heimatnetz des Endsystems wird zur Anker- oder Heimat-IWF. Auf diese Weise pflanzen sich PPP-Rahmen von und zum Endsystem über den drahtlosen Hub zur Heimat-IWF im Heimatnetz fort. Wenn das Endsystem zu Hause ist, wird die Heimat-IWF über ein XTunnel-Protokoll mit dem drahtlosen Hub verbunden.
  • For einen drahtlosen Roaming-Dienst (27) stellt der fremde Registrierungsserver während der Registrierungsphase die Identität des Heimatnetzes für das Gast-Endsystem fest. Unter Verwendung dieser Informationen kommuniziert der fremde Registrierungsserver mit dem Heimatregistrierungsserver, um das Endsystem zu authentifizieren und zu registrieren. Der fremde Registrierungsserver ordnet dann eine versorgende IWF zu, und es wird eine I-XTunnel-Protokoll-Verbindung zwischen der Heimat-IWF und der versorgenden IWF für das Gast-Endsystem hergestellt. Die versorgende IWF leitet Rahmen zwischen dem drahtlosen Hub und der Heimat-IWF weiter. Von der Heimat-IWF werden Daten an einen PPP-Server (d.h. Punkt-zu-Punkt-Protokollserver) gesendet, welcher in derselben IWF sitzt. Wenn jedoch die Daten zu einem firmeneigenen Intranet oder einem ISP-Intranet, das seinen eigenen PPP-Server hat, gehen sollen, werden die Daten über das L2TP-Protokoll an den getrennten PPP-Server gesendet. Der getrennte Server gehört normalerweise einem Internetdiensteanbieter, der vom Drahtlosdiensteanbieter verschieden ist, und wird von diesem betrieben. Für die Dauer der Sitzung bleiben die Aufenthaltsorte der Heimat-IWF und des PPP-Servers fest. Die MAC-Schicht-Registrierung kann mit der Netzschichtregistrierung verknüpft werden, um Zusatzaufwand von getrennten Kommunikationen für die MAC-Schicht- und die Netzschichtregistrierung einzusparen; es kann jedoch vorteilhaft sein, diese Registrierungsprozesse nicht zu verknüpfen, damit die WSP-Betriebsmittel mit anderen drahtlosen Netzen, welche nur das IETF Mobile IP unterstützen, zusammenwirken können.
  • Eine Registrierung erstellt drei Tabellen. Eine Tabelle 1 wird jedem Zugangspunkt zugeordnet, und Tabelle 1 identifiziert jede Verbindung (d.h. jedes Endsystem) durch eine Verbindungs-ID (CID für engl. connection ID) und ordnet der Verbindungs-ID eine bestimmte Drahtlosmodem- oder WM-Adresse (WM für engl. wireless modem) (d.h. die Adresse des Endsystems oder das Endsystem) zu. Eine Tabelle 2 wird jedem drahtlosen Hub (WH) zugeordnet, und Tabelle 2 ordnet jeder Verbindung-ID eine entsprechende Drahtlosmodemadresse, einen Zugangspunkt und eine XTunnel-ID (XID) zu. Eine Tabelle 3 wird jeder Netzübergangsfunktion (IWF) zugeordnet, und Tabelle 3 ordnet jeder Verbindungs-ID eine entsprechende Drahtlosmodemadresse, Drahtloshubadresse, XTunnel-ID und einen entsprechenden IP-Port (IP/Port) zu. Die für diese Tabellen beschriebenen Einträge sind so dargestellt, dass sie nur relevante Einträge enthalten, die zur Erörterung der Mobilitätsverwaltung beitragen. In Wirklichkeit gibt es andere wichtige Felder, die ebenfalls aufgenommen werden müssen. Tabelle 1: Verbindungstabelle am AP
    Figure 00980001
    Figure 00990001
    Tabelle 2: Verbindungstabelle am WH
    Figure 00990002
    Tabelle 3: Verbindungstabelle an der IWF
    Figure 00990003
  • Die Protokollstapel für Wähl-Benutzer zu Hause in einem Netz, sowie für Gast-Benutzer sind in 28 bis 31 dargestellt. 28 veranschaulicht Protokollstapel, die für direkten Internetzugang durch ein festes (d.h. sich nicht bewegendes) Endsystem zu Hause verwendet werden, wobei eine PPP-Protokoll-Nachricht in der Heimat-IWF (normalerweise ortsgleich mit dem drahtlosen Hub untergebracht) endet, welche die Nachricht zu und von einem IP-Router und von da zum öffentlichen Internet weiterleitet. 29 veranschaulicht Protokollstapel, die für einen Internetfernzugang (d.h. entweder private Firmennetze oder einen ISP) durch ein festes (d.h. sich nicht bewegendes) Endsystem zu Hause verwendet werden, wobei eine PPP-Protokoll-Nachricht durch die Heimat-IWF (normalerweise ortsgleich mit de drahtlosen Hub untergebracht) zu einem PPP-Server des privaten Firmenintranets oder ISPs weiterleitet. 30 veranschaulicht Protokollstapel, die für direkten Internetzugang durch ein wanderndes, aber festes (d.h. sich nicht bewegendes) oder ein sich bewegendes Endsystem verwendet werden, wobei das PPP-Protokoll in der Heimat-IWF (normalerweise in einer Mobilvermittlungseinrichtung des Heimatnetzes angeordnet) endet, welche die Nachricht zu und von einem IP-Router weiterleitet. Man beachte in 30, wie der Nachrichtenverkehr neben der Heimat-IWF auch eine versorgende IWF (normalerweise ortsgleich mit dem drahtlosen Hub untergebracht) passiert. 31 veranschaulicht Protokollstapel, die für einen Internetfernzugang (d.h. entweder private Firmennetze oder einen ISP) durch ein wanderndes, aber festes (d.h. sich nicht bewegendes) oder ein sich bewegendes Endsystem verwendet werden, wobei eine PPP-Protokoll-Nachricht durch die Heimat-IWF (normalerweise in einer Mobilvermittlungseinrichtung des Heimatnetzes angeordnet) zu einem PPP-Server des privaten Firmenintranets oder ISPs weitergeleitet wird. Man beachte in 31, wie der Nachrichtenverkehr neben der Heimat-IWF auch eine versorgende IWF (normalerweise ortsgleich mit dem drahtlosen Hub untergebracht) passiert. Wenn die versorgende IWF und der drahtlose Hub ortsgleich im selben Computersatz untergebracht oder sogar in denselben Computer programmiert sind, ist es nicht notwendig, einen Tunnel unter Verwendung des XTunnel-Protokolls zwischen der versorgenden IWF und dem drahtlosen Hub aufzubauen.
  • Gleichwertige Varianten dieser Protokollstapel (z.B. kann das RLP für Mobileinheiten zu Hause am drahtlosen Hub statt an der versorgenden IWF oder der Heimat-IWF beendet werden) sind ebenfalls vorgesehen. Wenn die IWF entfernt vom drahtlosen Hub angeordnet ist, und die Pakete potenziell über ein verlustbehaftetes IP-Netz zwischen der IWF und dem drahtlosen Hub übertragen werden können, ist es vorzuziehen, dass das RLP-Protokoll am drahtlosen Hub endet. Eine andere Variante ist, dass der XTunnel zwischen dem drahtlosen Hub und der IWF nicht über dem UDP/IP aufgebaut zu werden braucht. XTunnel können unter Verwendung der Rahmenweiterleitungs/ATM-Verbindungsschicht aufgebaut werden. Die Verwendung von UDP/IP macht es jedoch leichter, die Drahtloshub- und IWF-Software von einem Netz zum anderen zu bewegen.
  • Es können vier Weiterschaltungsszenarien stattfinden, und sie werden folgendermaßen bezeichnet: (i) lokale Mobilität, (ii) Mikromobilität, (iii) Makromobilität und (iv) globale Mobilität. In keinem der vier Szenarien (in einer Ausführungsform der Erfindung) wird eine Leitwegoptimierungsoption berücksichtigt, so dass die Aufenthaltsorte des Heimatregistrierungsservers und des ISP-PPP-Servers sich nicht ändern. In einer anderen Ausführungsform der Erfindung mit Leitwegoptimierung können die ISP-PPP-Server wechseln. Dieser Aspekt wird jedoch im Folgenden erörtert. Außerdem ändern sich die Aufenthaltsorte des fremden Registrierungsservers und IWF in den ersten drei Szenarien nicht.
  • Der vorgeschlagene Mobile-IP-Standard von IETF erfordert, dass ein Endsystem, wann immer es das IP-Teilnetz wechselt, an welches es angeschlossen ist, eine Registrierungsaufforderungsnachricht an dem Heimatagenten in seinem Heimatteilnetz sendet. Diese Nachricht führt eine Gastadresse mit, unter der das Endsystem im neuen Teilnetz erreicht werden kann. Wenn Verkehr zum Beispiel von einem ISP an ein Endsystem gesendet wird, fängt der Heimatagent den Verkehr, der für das Endsystem bestimmt ist, auf und übermittelt den Verkehr dann an die Gastadresse. Die Gastadresse identifiziert einen bestimmten fremden Agenten im fremden Teilnetz. Der fremde Agent eines Endsystems kann im Endsystem selbst oder in einem getrennten Knoten sitzen, der den Verkehr seinerseits an das Endsystem übermittelt (d.h. ein Proxy-Registrierungsagent). Mobile-IP-Weiterschaltungen beziehen den Austausch von Steuernachrichten zwischen dem Agenten eines Endsystems, dem Heimatagenten eines Endsystems und möglicherweise seinen entsprechenden Hosts (CHs für engl. corresponding hosts) ein (bei Leitwegoptimierungsoption).
  • Für den vorgeschlagenen Mobile-IP-Standard von IETF wäre es schwierig, die Latenzzeit- und Skalierbarkeitsziele für alle Bewegungen in einem großen Verbindungsnetz zu erreichen. Die vorliegende hierarchische Mobilitätsverwaltung erreicht jedoch solche Ziele. Für kleine Bewegungen (z.B. einen Wechsel von Zugangspunkten) werden nur MAC-Schicht-Neuregistrierungen benötigt. Für größere Bewegungen werden Netzschicht-Neuregistrierungen durchgeführt. Die vorliegende hierarchische Mobilitätsverwaltung unterscheidet sich von der Flachstruktur, die in dem von der IETF vorgeschlagenen Mobile-IP-Standard verwendet wird, sowie dem Model von versorgender/Anker-Netzübergangsfunktion, das in zellularen Systemen wie CDPD (basierend auf einem Standard, der durch das Forum digitaler Zellen-Paketdaten gefördert wird) verwendet wird.
  • Wie in 32 dargestellt, wickelt die lokale Mobilitätsweiterschaltung Endsystembewegungen (als MN für mobile node, mobiler Knoten, bezeichnet) zwischen APs ab, die zu demselben drahtlosen Hub gehören. Demnach ist nur eine MAC-Schicht-Neuregistrierung erforderlich. Das Endsystem empfängt eine Drahtloshubankündigung von einem neuen AP und antwortet mit einer Registrierungsaufforderung, die an den neuen AP adressiert ist.
  • Der neue AP (d.h. der AP, der die Registrierungsaufforderung vom Endsystem empfängt) erzeugt neue Einträge in seiner Verbindungstabelle und leitet die Registrierungsnachricht an seinen drahtlosen Hub weiter. Bei lokalen Mobilitätsweiterschaltungen ändert sich der drahtlose Hub nicht. Der drahtlose Hub erkennt die Registrierungsaufforderung des Endsystems als eine MAC-Ebene-Registrierungsaufforderung und aktualisiert sie in seiner Verbindungstabelle, um die Verbindung zum neuen AP zu reflektieren. Dann löscht der alte AP den Verbindungseintrag aus seiner Verbindungstabelle. Es gibt wenigstens drei Möglichkeiten, wie der alte AP die alten Einträge löschen kann, nämlich (i) bei Zeitüberschreitung, (ii) bei Empfang einer Kopie der weitergeleiteten MAC-Schicht-Vereinbarungsnachricht vom neuen AP an den drahtlosen Hub (wenn diese Weiterleitungsnachricht eine Rundesendenachricht ist), und (iii) bei Benachrichtigung durch den drahtlosen Hub über die Notwendigkeit, den Eintrag zu löschen.
  • Wie in 33 dargestellt, wickelt die Mikromobilitätsweiterschaltung Endsystembewegungen (als MN für mobile node, mobiler Knoten, bezeichnet) zwischen drahtlosen Hubs ab, die zu demselben Registrierungsserver gehören und wo das Endsystem noch durch die bestehende versorgende IWF versorgt werden kann. Wenn eine Ankündigung von einem neuen drahtlosen Hub (durch einen neuen AP) empfangen wird, sendet das Endsystem eine Nachricht, um den Registrierungsserver zu einer Registrierung aufzufordern. Die Registrierungsaufforderung wird vom neuen AP zum neuen drahtlosen Hub an den Registrierungsserver weitergeleitet.
  • Wenn der Registrierungsserver bestimmt, dass die bestehende IWF noch verwendet werden kann, sendet der Registrierungsserver eine build XTunnel Request- oder XTunnel-Aufbau-Aufforderungsnachricht, um die bestehende IWF aufzufordern, einen XTunnel zum neuen drahtlosen Hub aufzubauen. Später sendet der Registrierungsserver eine tear down XTunnel Request- oder XTunnel-Abbau-Aufforderungsnachricht, um die bestehende IWF aufzufordern, den bestehenden XTunnel mit dem alten drahtlosen Hub abzubauen. Die XTunnel- Aufbau- und die XTunnel-Abbau-Aufforderungsnachrichten können in eine Nachricht verknüpft werden. Ein fremder Registrierungsserver übermittelt die Registrierungsnachricht nicht an den Heimatregistrierungsserver, da es keinen Wechsel von IWF gibt, weder der versorgenden noch der Heimat-IWF, gibt.
  • Nach Empfang einer positiven XTunnel-Aufbau-Antwort und einer positiven XTunnel-Abbau-Antwort von der IWF sendet der Registrierungsserver eine Registrierungsantwort an das Endsystem. Wenn die Registrierungsantwort den neuen drahtlosen Hub erreicht, wird die Verbindungstabelle am neuen drahtlosen Hub aktualisiert, um die Verbindung zum neuen AP zu reflektieren. Der neue AP aktualisiert seine MAC-Filter-Adressentabelle und seine Verbindungstabelle nach Empfang einer Nachricht vom neuen drahtlosen Hub, und die Registrierungsantwort wird an das Endsystem übermittelt.
  • Der Registrierungsserver sendet eine Freigabenachricht an den alten drahtlosen Hub. wenn der alte drahtlose Hub die Freigabenachricht empfängt, aktualisiert er seine Verbindungstabelle und die MAC-Filter-Adressentabelle und die Verbindungstabelle des alten APs.
  • Wie in 34 dargestellt, wickelt die Makromobilitätsweiterschaltung Bewegungen zwischen drahtlosen Hubs ab, die zwar einen Wechsel der versorgenden IWF im Fremdnetz mit sich bringen, aber keinen Wechsel des Registrierungsservers mit sich bringen. Wenn eine Ankündigung von einem neuen drahtlosen Hub (durch einen neuen AP) empfangen wird, sendet das Endsystem eine Nachricht, um den Registrierungsserver zur Netzschichtregistrierung aufzufordern. Die Registrierungsaufforderung wird vom neuen AP zum neuen drahtlosen Hub an den Registrierungsserver weitergeleitet.
  • Der Registrierungsserver erkennt, dass er ein fremder Registrierungsserver ist, wenn das Endsystem nicht zum Netz des gegenwärtigen Registrierungsservers gehört. Dieser fremde Registrierungsserver bestimmt die Identität des Heimatregistrierungsservers durch Verwenden einer Anforderung, vorzugsweise einer Radius Access- oder Radius-Zugangsanforderung (RA-Anforderung) an den Fremdverzeichnisserver (wie ein großer Gelbe Seiten), und er ordnet dann eine geeignete IWF zu, um die versorgende IWF zu sein, und übermittelt eine Registrierungsaufforderung an den Heimatregistrierungsserver, vorzugsweise durch eine Radius Access-Anforderung (RA-Anforderung), um den Heimatregistrierungsserver über die neu ausgewählte IWF zu informieren.
  • Der Heimatregistrierungsserver authentifiziert die Registrierungsaufforderung durch Verwenden einer Anforderung, vorzugsweise einer Radius Access- oder Radius-Zugangsanforderung (RA-Anforderung), an den Heimatverzeichnisserver. Nach dem Authentifizieren der Aufforderung und Bestimmen, dass die bestehende Heimat-IWF noch verwendet werden kann, weist der Heimatregistrierungsserver die Heimat-IWF an, einen neuen I-XTunnel zur neu zugeordneten versorgenden IWF aufzubauen und den bestehende I-XTunnel zur alten versorgenden IWF abzubauen. Nach Empfang einer positiven I-XTunnel-Aufbau-Antwort und einer positiven I-XTunnel-Abbau-Antwort von der Heimat-IWF sendet der Heimatregistrierungsserver eine Registrierungsantwort an den fremden Registrierungsserver.
  • Der fremde Registrierungsserver weist dann die neu zugeordnete IWF an, einen XTunnel zum neuen drahtlosen Hub aufzubauen. Nach Empfang einer positiven XTunnel-Aufbau-Antwort weist der fremde Registrierungsserver die alte IWF an, den XTunnel zum alten drahtlosen Hub abzubauen. Nach Empfang einer positiven XTunnel-Aufbau-Antwort und einer positiven XTunnel-Abbau-Antwort sendet der fremde Registrierungsserver eine Registrierungsantwort an das Endsystem.
  • Wenn die Registrierungsantwort den neuen drahtlosen Hub erreicht, wird die Verbindungstabelle am neuen drahtlosen Hub aktualisiert, um die Verbindung zum neuen AP zu reflektieren. Der neue AP aktualisiert seine MAC-Filter-Adressentabelle und seine Verbindungstabelle nach Empfang einer Nachricht vom neuen drahtlosen Hub, und die Registrierungsantwort wird an das Endsystem weitergeleitet.
  • Der Registrierungsserver sendet eine Freigabenachricht an den alten drahtlosen Hub. Wenn der alte drahtlose Hub die Freigabenachricht empfängt, aktualisiert er seine Verbindungstabelle und die MAC-Filter-Adressentabelle, und der alte AP aktualisiert seine MAC-Filter-Adressentabelle und seine Verbindungstabelle nach Empfang einer Nachricht vom alten drahtlosen Hub.
  • Die globale Mobilitätsweiterschaltung wickelt Bewegungen zwischen drahtlosen Hubs ab, die einen Wechsel des Registrierungsserver mit sich bringen. 35 veranschaulicht eine globale Mobilitätsumschaltung, bei welcher die Heimat-IWF nicht wechselt, und 36 veranschaulicht eine globale Mobilitätsweiterschaltung, bei welcher die Heimat-IWF wechselt. Wenn eine Ankündigung von einem neuen drahtlosen Hub (durch einen neuen AP) in einem Fremdnetz empfangen wird, sendet das Endsystem eine Nachricht, um den fremden Registrierungsserver zu einer Netzuschichtregistrierung aufzufordern. Die Registrierungsaufforderung wird vom neuen AP zum neuen drahtlosen Hub an den neuen fremden Registrierungsserver weitergeleitet.
  • Der Registrierungsserver erkennt, dass er ein fremder Registrierungsserver ist, wenn das Endsystem nicht zum Netz des gegenwärtigen Registrierungsservers gehört. Dieser fremde Registrierungsserver bestimmt die Identität des Heimatregistrierungsservers durch Verwenden einer Anforderung, vorzugsweise einer Radius Access- oder Radius-Zugangsanforderung (RA-Anforderung), an den Fremdverzeichnisserver (wie ein großer Gelbe Seiten), und er ordnet dann eine geeignete IWF zu, um die versorgende IWF zu sein, und übermittelt eine Registrierungsaufforderung an den Heimatregistrierungsserver, vorzugsweise durch eine Radius Access-Anforderung (RA-Anforderung), um den Heimatregistrierungsserver über die neu ausgewählte IWF zu informieren.
  • Der Heimatregistrierungsserver authentifiziert die Registrierungsaufforderung durch Verwenden einer Anforderung, vorzugsweise einer Radius Access- oder Radius-Zugangsanforderung (RA-Anforderung), an den Heimatverzeichnisserver. Nach dem Authentifizieren der Aufforderung und Bestimmen, dass die bestehende Heimat-IWF noch verwendet werden kann (35), weist der Heimatregistrierungsserver die Heimat-IWF an, einen neuen I-XTunnel zur versorgenden IWF, die durch den neuen fremden Registrierungsserver neu zugeordnet wurde, aufzubauen. Der Heimatregistrierungsserver sendet auch eine Nachricht zur Löschung aus dem Register an den alten fremden Registrierungsserver und weist die Heimat-IWF an, den bestehenden I-T-Tunnel zur bestehenden versorgenden IWF des alten Fremdnetzes abzubauen. Nach Empfang einer positiven I-XTunnel-Aufbau-Antwort und einer positiven I-XTunnel-Abbau-Antwort von der Heimat-IWF sendet der Heimatregistrierungsserver eine Registrierungsantwort an den neuen fremden Registrierungsserver.
  • Der neue fremde Registrierungsserver weist dann die neu zugeordnete IWF an, einen XTunnel zum neuen drahtlosen Hub aufzubauen. Nach Empfang einer positiven XTunnel-Aufbau-Antwort sendet der fremde Registrierungsserver eine Registrierungsantwort an das Endsystem. Wenn die Registrierungsantwort den neuen drahtlosen Hub erreicht, wird die Verbindungstabelle am neuen drahtlosen Hub aktualisiert, um die Verbindung zum neuen AP zu reflektieren. Der neue AP aktualisiert seine MAC-Filter-Adressentabelle und seine Verbindungstabelle nach Empfang einer Nachricht vom neuen drahtlosen Hub, und die Registrierungsantwort wird an das Endsystem weitergeleitet.
  • Der alte fremde Registrierungsserver weist die alte IWF an, den XTunnel zum alten drahtlosen Hub abzubauen. Nach Empfang einer positiven XTunnel-Abbau-Antwort oder gleichzeitig mit der XTunnel-Abbau-Aufforderung sendet der alte fremde Registrierungsserver eine Freigabenachricht an den alten drahtlosen Hub. Wenn der alte drahtlose Hub, die Freigabenachricht empfängt, aktualisiert er seine Verbindungstabelle und die MAC-Filter-Adressentabelle, und der alte AP aktualisiert seine MAC-Filter-Adressentabelle und seine Verbindungstabelle nach Empfang einer Nachricht vom alten drahtlosen Hub.
  • Alternativerweise wählt der Heimatregistrierungsserver, sobald der Heimatregistrierungsserver die Registrierungsaufforderung vom neuen fremden Registrierungsserver authentifiziert und bestimmt hat, dass die bestehende Heimat-IWF nicht mehr verwendet werden kann (36), eine neue Heimat-IWF und weist die neue Heimat-IWF an, einen neuen Ebene-2-Tunnelprotokoll-Tunnel (L2TP)-Tunnel) zum gegenwärtigen PPP-Server (z.B. dem PPP-Server in einem verbunden ISP-Intranet) aufzubauen. Dann weist der Heimatregistrierungsserver die alte Heimat-IWF an, ihren L2TP-Tunnelverkehr an die neue Heimat-IWF zu übertragen.
  • Dann weist der Heimatregistrierungsserver die neue Heimat-IWF an, einen neuen I-XTunnel zur versorgenden IWF, die durch den neuen fremden Registrierungsserver neu zugeordnet wurde, aufzubauen. Der Heimatregistrierungsserver sendet auch eine Nachricht zur Löschung aus dem Register an den alten fremden Registrierungsservers und weist die Heimat-IWF an, den bestehenden I-XTunnel zur bestehenden versorgenden IWF des alten Fremdnetzes abzubauen. Nach Empfang einer positiven I-XTunnel-Aufbau-Antwort und einer positiven I-XTunnel-Abbau-Antwort sendet der Heimatregistrierungsserver eine Registrierungsantwort an den neuen fremden Registrierungsserver.
  • Der neue fremde Registrierungsserver weist dann die neu zugeordnete IWF an, einen XTunnel zum neuen drahtlosen Hub aufzubauen. Nach Empfang einer positiven XTunnel-Aufbau-Antwort sendet der fremde Registrierungsserver eine Registrierungsantwort an das Endsystem. Wenn die Registrierungsantwort den neuen drahtlosen Hub erreicht, wird die Verbindungstabelle am neuen drahtlosen Hub aktualisiert, um die Verbindung zum neuen AP zu reflektieren. Der neue AP aktualisiert seine MAC-Filter-Adressentabelle und seine Verbindungstabelle nach Empfang einer Nachricht vom neuen drahtlosen Hub, und die Registrierungsantwort wird an das Endsystem weitergeleitet.
  • Der alte fremde Registrierungsserver weist die alte IWF an, den XTunnel zum alten drahtlosen Hub abzubauen. Nach Empfang einer positiven XTunnel-Abbau-Antwort oder gleichzeitig mit der XTunnel-Abbau-Aufforderung sendet der alte fremde Registrierungsserver eine Freigabenachricht an den alten drahtlosen Hub. Wenn der alte drahtlose Hub die Freigabenachricht empfängt, aktualisiert er seine Verbindungstabelle und die MAC-Filter-Adressentabelle, und der alte AP aktualisiert seine MAC-Filter-Adressentabelle und seine Verbindungstabelle nach Empfang einer Nachricht vom alten drahtlosen Hub.
  • Endsysteme, die gemäß der vorliegenden Erfindung aufgebaut sind, wirken mit Netzen zusammen, die gemäß den vorgeschlagenen Mobile-IP-Standards von IETF aufgebaut sind, und Endsysteme, die gemäß den vorgeschlagenen Mobile-IP-Standards von IETF aufgebaut sind, wirken mit Netzen zusammen, die gemäß der vorliegenden Erfindung aufgebaut sind.
  • Die Hauptunterschiede zwischen der vorliegenden Erfindung und dem IETF Mobile IP (RFC2002, ein Normendokument) sind:
    • (i) Die vorliegende Erfindung verwendet ein hierarchisches Konzept zur Mobilitätsverwaltung statt einer Flachstruktur wie im vorgeschlagenen IETF Mobile-IP-Standard. Eine kleine Mobilität in einem kleinen Bereich führt zu keiner Netzebenenregistrierung. Eine Mikromobilität bringt den Aufbau eines neuen XTunnels und den Abbau eines bestehenden XTunnels mit sich. Eine globale Mobilität bringt wenigstens den Aufbau eines neuen I-XTunnels und den Abbau eines bestehenden I-XTunnels abgesehen vom Aufbau/Abbau des XTunnels mit sich. Die globale Mobilität bringt manchmal auch den Aufbau eines neuen L2TP-Tunnels und die Übertragung des L2TP-Zustands vom bestehenden L2TP-Tunnel auf den neuen L2TP-Tunnel mit sich.
    • (ii) In der vorliegenden Erfindung wird ein Benutzername plus einen Bereich zur Identifizierung eines entfernten Wähl-Benutzers statt einer festen Heimatadresse wie im Falle des vorgeschlagenen IETF Mobil-IP-Standards verwendet.
    • (iii) In der vorliegenden Erfindung werden Registrierungs- und Leitweglenkungsfunktionen durch getrennten Entitäten ausgeführt. Die beiden Funktionen werden im vorgeschlagenen IETF Mobile-IP-Standard durch den Heimatagenten ausgeführt, und beide Funktionen werden im vorgeschlagenen IETF Mobile-IP-Standard durch den fremden Agenten ausgeführt. Im Gegensatz dazu wird in einer Ausführungsform der vorliegenden Erfindung die Registrierung im Registrierungsserver durchgeführt, und Leitweglenkungsfunktionen werden sowohl durch die Heimat- und versorgende IWF als auch den drahtlosen Hub (auch als Zugangshub bezeichnet) ausgeführt.
    • (iv) Die vorliegende Erfindung verwendet drei Tunnel je PPP-Sitzung. Der XTunnel ist mehr wie ein Verbindungsschichttunnel zwischen dem drahtlosen Hub und der versorgenden IWF. Der I-XTunnel zwischen der versorgenden IWF und der Heimat-IWF ist mehr wie der Tunnel zwischen Heimat- und fremden Agenten im vorgeschlagenen IETF Mobile-IP-Standard. Aber er weist auch zusätzliche Fähigkeiten auf, die über jene der durch den Mobile-IP-Standard vorgeschlagenen Tunnel hinausgehen. Der L2TP-Tunnel wird nur verwendet, wenn die Heimat-IWF kein PPP-Server ist. Die Anzahl dieser Tunnel kann durch Verknüpfen einiger Funktionen im selben Knoten, wie zuvor beschrieben, verringert werden.
    • (v) In der vorliegenden Erfindung findet eine drahtlose Registrierung statt, bevor eine PPP-Sitzung beginnt, während im vorgeschlagenen IETF Mobile-IP-Standard eine Mobile-IP-Registrierung stattfindet, nachdem eine PPP-Sitzung in den offenen Zustand eintritt.
    • (vi) In der vorliegenden Erfindung ist die Netzentität, welche die Agentenankündigung (d.h. der drahtlose Hub) ankündigt, nicht auf einer direkten Verbindung zu den Endsystemen, wohingegen für den vorgeschlagenen IETF Mobile-IP-Standard die Agentenankündigung eine TTL von 1 haben muss, was bedeutet, dass die Endsysteme eine direkte Verbindung mit dem fremden Agenten haben. Außerdem ist die Agentenankündigung in der vorliegenden Erfindung keine Erweiterung zu den ICMP-Routerankündigungen wie im vorgeschlagenen IETF Mobile-IP-Standard.
  • Endsysteme in der vorliegenden Erfindung sollten einen Agentenabruf unterstützen. Wenn ein Endsystem in der vorliegenden Erfindung ein Netz besucht, welches den vorgeschlagenen IETF Mobile-IP-Standard unterstützt, wartet es, bis es eine Agentenankündigung hört. Wenn es innerhalb eines annehmbaren Zeitrahmens keine Agentenankündigung empfängt, sendet es einen Agentenabruf rund.
  • In der vorliegenden Erfindung können Netzbetreiber mit anderen Netzen, die den vorgeschlagenen IETF Mobile-IP-Standard unterstützen, derart verhandeln, dass den Endsystemen der vorliegenden Erfindung, die andere Netze zu verwenden wünschen, Heimatadressen zugeordnet werden können. Wenn das Endsystem der vorliegenden Erfindung die Agentenankündigung empfängt, kann es feststellen, dass das Netz, das es besucht, kein Netz gemäß der vorliegenden Erfindung ist, und verwendet infolgedessen die zugeordnete Heimatadresse, um sich registrieren zu lassen.
  • Für Netze, die den vorgeschlagenen IETF Mobile-IP-Standard unterstützen, beginnt die PPP-Sitzung vor der Mobile-IP-Registrierung, und es ist anzunehmen, dass der PPP-Server in solchen Netzen ortsgleich mit dem fremden Agenten untergebracht ist. In einer Ausführungsform wird ein SNAP-Kopf verwendet, um PPP-Rahmen in den MAC-Rahmen der vorliegenden Erfindung einzukapseln (in einer dem Ethernet-Format ähnlichen weise), und der fremde Agent interpretiert dieses Format als ein proprietäres PPP-Format über Ethernet-Kapselung. Demnach können das Endsystem der vorliegenden Erfindung und sein PPP-Partner in einen offenen Zustand eintreten, bevor der fremde Agent eine Agentenankündigung zu übertragen beginnt, und das Endsystem der vorliegenden Erfindung kann sich registrieren lassen.
  • Um Endsystemen, die den vorgeschlagenen IETF Mobile-IP-Standard unterstützen, zu ermöglichen, in Netzen von der Art der vorliegenden Erfindung zu arbeiten, sind solche Mobileinheiten wenigstens imstande, ähnliche MAC-Schicht-Registrierungen durchzuführen. Durch Ausführen des Agentenankündigungsnachrichtformats ähnlich dem Agentenankündigungsnachrichtenformat nach dem vorgeschlagenen IETF Mobile-IP-Standard kann ein Besucher-Endsystem die Agentenankündigung interpretieren und sich mit einem drahtlosen Hub registrieren lassen. In der vorliegenden Erfindung sind Registrierungsaufforderungs- und Registrierungsantwortnachrichten ähnlich den Registrierungsaufforderungs- und Registrierungsantwortnachrichten nach dem vorgeschlagenen IETF Mobile-IP-Standard (ohne irgendwelche unnötige Erweiterungen), derart dass der Rest der Mobilitätsverwaltungsmerkmale der vorliegenden Erfindung für die Besucher-Endsysteme transparent ist.
  • Da Endsysteme, die den vorgeschlagenen IETF Mobile-IP-Standard unterstützen, erwarten, dass eine PPP-Sitzung vor der Mobile-IP-Registrierung beginnt, beginnt ein optionales Merkmal in drahtlosen Hubs der vorliegenden Erfindung PPP-, LCP- und NCP-Pakete nach der MAC-Schicht-Registrierung zu interpretieren.
  • Um zu vermeiden, dass bei Weiterschaltungen Verkehr verloren geht, verwendet die Mobilitätsverwaltung der vorliegenden Erfindung das Schließer-vor-Öffner-Konzept. Für lokale Mobilität wird eine Schließer-vor-Öffner-Verbindung durch Umwandeln der MAC-Schicht-Registrierungsnachricht, die durch den neuen AP zum drahtlosen Hub weitergeleitet wird, in eine Rundesendenachricht erreicht. Auf diese Weise kann der alte AP von der neuen Registrierung hören und Pakete übermitteln, die für das Endsystem bestimmt sind und nicht an den neuen AP übertragen wurden.
  • Für Mikromobilität werden Informationen über den neuen drahtlosen Hub in die XTunnel-Abbau-Nachricht aufgenommen, die zwischen der versorgenden IWF und dem alten WH ausgetauscht wird. Auf diese Weise kann der alte drahtlose Hub bei Hören einer XTunnel-Abbau-Nachricht von der versorgenden IWF gepufferte Pakete übermitteln. Alternativerweise kennt die RLP-Schicht an der IWF die Folgenummer, die durch den alten drahtlosen Hub bis jetzt bestätigt wurde.
  • Gleichzeitig kennt die IWF die aktuelle Sendefolgenummer des letzten Pakets, das an den alten drahtlosen Hub gesendet wurde. Daher kann die IWF jene Pakete, die zwischen diesen beiden Nummern angeordnet sind, an den neuen drahtlosen Hub übermitteln, bevor neuere Pakete an den neuen drahtlosen Hub gesendet werden. Es wird angenommen, dass die RLP-Schicht imstande ist, doppelte Pakete zu filtern. Die zweite Lösung ist der ersten Lösung wahrscheinlich vorzuziehen, da der alte drahtlose Hub möglicherweise nicht imstande ist, direkt mit einem anderen zu kommunizieren.
  • Für Makromobilität kann die alte versorgende IWF zusätzlich zu der Paketübermittlung, die vom alten drahtlosen Hub an den neuen drahtlosen Hub erfolgt, Pakete an die neue versorgende IWF übermitteln. Alles, was zu tun ist, ist die Identität der neuen versorgenden IWF in der I-XTunnel-Abbau-Nachricht an die neue versorgende IWF zu übermitteln. Eine andere Möglichkeit, dasselbe Ergebnis zu erreichen, ist, die Heimat-IWF die fehlenden Pakete an die neue versorgende IWF übermitteln zu lassen, statt die alte versorgende IWF zu ersuchen, dies zu tun, da die Heimat-IWF die I-XTunnel-Folgenummer, die als Letzte durch die alte versorgende IWF bestätigt wurde, und die aktuelle I-XTunnel-Folgenummer, die durch die Heimat-IWF gesendet wurde, kennt.
  • Das Verfahren des Schätzens, wie viel Puffer pro Mobileinheit pro AP pro drahtlosen Hub pro IWF zugewiesen werden sollte, derart dass ein Verkehrsverlust zwischen Weiterschaltungen minimiert werden kann, besteht darin, das Endsystem für den AP für den drahtlosen Hub für die IWF die Paketankunftsrate und die Weiterschaltzeit schätzen zu lassen. Diese Informationen werden an den alten AP des drahtlosen Hubs der IWF weitergegeben, um zu bestimmen, wie viel Verkehr bei Weiterschaltungen jeweils an den neuen AP übertragen werden sollte.
  • Um in der vorliegenden Erfindung eine Leitwegoptimierung zu erreichen, wählt das Endsystem den PPP-Server, der am nächsten zur versorgenden IWF ist. Ohne Leitwegoptimierung können übermäßige Transportverzögerungen und eine übermäßige Benutzung der physikalischen Leitung vorkommen.
  • Zum Beispiel kann ein Endsystem, das ein Abonnement bei einem Heimatnetz in New York City hat, nach Hongkong wandern. Um eine Verbindung zwischen einem ISP in Hongkong herzustellen, müsste das Endsystem eine versorgende IWF, die in einem drahtlosen Hub in Hongkong eingerichtet ist, und eine Heimat-IWF, die im Heimatnetz in New York City eingerichtet ist, aufweisen. Eine Nachricht würde dann vom Endsystem (nach Hongkong gewandert) durch die versorgende IWF (in Hongkong) und durch die Heimat-IWF (in New York City) und zurück zum ISP in Hongkong geleitet werden.
  • Eine bevorzugte Lösung ist, von der versorgenden IWF (in Hongkong) direkt zum ISP in Hongkong durchzuschalten. Die versorgende IWF agiert wie die Heimat-IWF. In dieser Ausführungsform bestehen Roaming-Vereinbarungen zwischen den fremden und de Heimat-Drahtlosanbietern. Außerdem kommunizieren die verschiedenen Abrechnungs/Gebührenverrechnungssysteme automatisch miteinander, derart dass die Rechnungsinformationen gemeinsam benutzt werden. Der Abrechnungs- und Rechnungsinformationsaustausch kann unter Verwendung von solchen Standards wie dem Standard erfolgen, der durch die ROAMOPS-Arbeitsgruppe der IETF vorgeschlagen wird.
  • Die versorgende IWF muss jedoch noch den nächstgelegenen PPP-Server (zum Beispiel den Hongkong-ISP) ermitteln. In der vorliegenden Ausführungsform erfährt der fremde Registrierungsserver von dem Wunsch des Endsystems zur Verbindung mit einem PPP-Server (z.B. einem Hongkong-ISP), wenn er eine Registrierungsaufforderung vom Endsystem empfängt. Wenn der fremde Registrierungsserver bestimmt, dass die versorgende IWF näher zum gewünschten PPP-Server (z.B. dem Hongkong-ISP) ist als die Heimat-IWF, weist der fremde Registrierungsserver die versorgende IWF an, einen L2TP-Tunnel zu ihrem nächstgelegenen PPP-Server herzustellen (im Gegensatz zum PPP-Server, welcher am nächsten zum Heimatregistrierungsserver und zur Heimat-IWF ist). Dann informiert der fremde Registrierungsserver den Heimatregistrierungsserver, dass das Endsystem durch die versorgende IWF und den fremden PPP versorgt wird.
  • In einer alternativen Ausführungsform bestimmt der fremde Registrierungsserver, dass die versorgende IWF näher zum gewünschten PPP-Server (z.B. dem Hongkong-ISP) ist als die Heimat-IWF, wenn er eine Registrierungsaufforderung vom Endsystem empfängt. Der fremde Registrierungsserver leitet die Registrierungsaufforderungsnachricht mit einer angehängten Nachricht, welche Informationen über die versorgende IWF angibt, und einer Mitteilung, dass eine Leitwegoptimierung bevorzugt wird, an den Heimatregistrierungsserver weiter. Gleichzeitig weist der fremde Registrierungsserver die versorgende IWF an, einen L2TP-Tunnel zum PPP-Server herzustellen. Nach Genehmigen der Registrierungsaufforderung weist der Heimatregistrierungsservers die Heimat-IWF an, den L2TP-Zustand an die fremde IWF zu übertragen.
  • Nachdem nun bevorzugte (zur Veranschaulichung dienende und nicht einschränkende) Ausführungsformen einer neuartigen Netzarchitektur mit drahtlosen Endbenutzern, die zu wandern imstande sind, beschrieben wurde, ist zu erwähnen, dass angesichts der zuvor dargelegten Lehren Modifikationen und Variationen durch Fachleute vorgenommen werden können. Zum Beispiel können die Verbindungsstrecken, die hierin beschrieben wurden, auf bekannte Verbindungsprotokolle (z.B. IP, TCP/IP, L2TP, IEEE 802.3 usw.) Bezug nehmen; die Erfindung sieht jedoch andere Verbindungsprotokolle in den Verbindungsstrecken vor, welche dieselben oder ähnliche Datenzustellungsfähigkeiten bereitstellen. Die handelnden Agenten in den zuvor beschriebenen Ausführungsformen können in Form von softwaregesteuerten Prozessoren sein, oder sie können eine andere Form von Steuerungen (z.B. programmierbare Logikanordnungen) sein. Die handelnden Agenten können so gruppiert sein, wie zuvor beschrieben, oder anderweitig gruppiert sein, solange sie sich an die hierin beschriebenen Verbindungslehren halten und den Sicherheits- und Authentifizierungslehren, wie hierin beschrieben, unterwerfen. Außerdem kann ein einziger Zugangspunkt (d.h. drahtloser Hub) oder eine einzige Netzübergangsfunktionseinheit (IWF-Einheit) eine Mehrkanalfähigkeit bereitstellen. Auf diese Weise kann ein einziger Zugangspunkt oder Zugangshub oder eine einzige IWF-Einheit auf den Verkehr von mehreren Endsystemen einwirken und, was hierin als getrennte Zugangspunkte, Zugangshubs oder IWF-Einheiten beschrieben wird, sieht eine Entsprechung mit einem einzigen Mehrkanal-Zugangspunkt, -Zugangshub oder -IWF-Einheit vor.

Claims (10)

  1. Gekoppeltes Datennetz, aufweisend Computer (2) und Modem (4), die mit dem Internet (20) und privaten Intranets (18) über ein öffentliches Telefonwählnetz (6) verbunden sind, das einen Übergabepunkt (8) für einen Internetdiensteanbieter (8) und einen Server (16) für die privaten Intranets (18) versorgt, aufweisend: ein Fremdnetz (62), das eine Basisstation (64) und ein fremde Mobilfunkvermittlungsstelle mit einem versorgenden Registrierungsserver aufweist, wobei die Basisstation einen Zugangshub (84) mit einer versorgenden Netzübergangsfunktion (66) aufweist; ein Heimatnetz (70), das eine Heimatmobilfunkvermittlungsstelle mit einem Heimatregistrierungsserver und einer Heimatnetzübergangsfunktion (72) aufweist; und ein Endsystem (32), das am Heimatnetz angeschlossen und im Fremdnetz tätig ist, wobei das Endsystem einen Endregistrierungsagenten aufweist, um eine Registrierungsaufforderung zu erzeugen, die Registrierungsaufforderung eine Angabe eines gewünschten Kommunikationsnetzes und eines gewünschten PPP-Kommunikationsservers, mit dem das Endsystem eine PPP-Sitzung herstellt, enthält, das Endsystem die Registrierungsaufforderung an den versorgenden Registrierungsserver sendet, der versorgende Registrierungsserver ein erstes Mittel aufweist, das so ausgelegt ist, dass es die Re gistrierungsaufforderung verarbeitet und einen bestmöglichen Leitweg zwischen dem gewünschten PPP-Kommunikationsserver und der Heimatnetzübergangsfunktion oder der versorgenden Netzübergangsfunktion bestimmt, und der versorgende Registrierungsserver ferner ein zweites Mittel aufweist, das so ausgelegt ist, dass es die versorgende Netzübergangsfunktion mit dem gewünschten PPP-Kommunikationsserver verbindet, wenn das erste Modul bestimmt, dass der bestmögliche Leitweg zwischen der versorgenden Netzübergangsfunktion und dem gewünschten PPP-Kommunikationsserver ist.
  2. Datennetz nach Anspruch 1, wobei der versorgende Registrierungsserver ferner ein drittes Mittel aufweist, das so ausgelegt ist, dass es die Registrierungsaufforderung mit einer angehängten Angabe, dass der versorgende Registrierungsserver die versorgende Netzübergangsfunktion und den gewünschten PPP-Kommunikationsserver verbunden hat, an den Heimatregistrierungsserver sendet.
  3. Gekoppeltes Datennetz nach Anspruch 1, wobei das Endsystem am Heimatnetz angeschlossen und im Fremdnetz tätig ist, das Endsystem einen Endregistrierungsagenten aufweist, um eine Registrierungsaufforderung zu erzeugen, die Registrierungsaufforderung eine Angabe eines gewünschten Kommunikationsnetzes und eines gewünschten PPP-Kommunikationsservers enthält, das Endsystem die Registrierungsaufforderung an den versorgenden Registrierungsserver sendet, der versorgende Registrierungsserver ein erstes Mittel aufweist, das so ausgelegt ist, dass es die Registrierungsaufforde rung verarbeitet und einen bestmöglichen Leitweg zwischen dem gewünschten PPP-Kommunikationsserver und der Heimatnetzübergangsfunktion oder der versorgenden Netzübergangsfunktion bestimmt, und der versorgende Registrierungsserver ferner ein zweites Mittel aufweist, das so ausgelegt ist, dass es die Registrierungsaufforderung mit einer ersten angehängten Angabe, dass der versorgende Registrierungsserver bestimmt hat, dass der bestmögliche Leitweg zwischen der versorgenden Netzübergangsfunktion und dem gewünschten PPP-Kommunikationsserver ist, und einer zweiten angehängten Angabe, dass eine Leitwegoptimierung bevorzugt wird, an den Heimatregistrierungsserver sendet.
  4. Datennetz nach Anspruch 3, wobei der versorgende Registrierungsserver ein drittes Mittel aufweist, das so ausgelegt ist, dass es nach dem Senden der Registrierungsaufforderung und der ersten und zweiten angehängten Angaben an den Heimatregistrierungsserver eine Verbindung zwischen der versorgenden Netzübergangsfunktion und dem gewünschten PPP-Kommunikationsserver herstellt.
  5. Datennetz nach Anspruch 4, wobei: der Heimatregistrierungsserver ein viertes Mittel aufweist, das so ausgelegt ist, dass es eine Registrierungsantwort an den versorgenden Registrierungsserver sendet und die Registrierungsantwort eine Angabe dessen enthält, dass die Verbindung zwischen der versorgenden Netzübergangsfunktion und dem gewünschten PPP-Kommunikationsserver zugelassen wird; und der Heimatregistrierungsserver ferner ein fünftes Mittel aufweist, das so ausgelegt ist, dass es die Heimatnetzübergangsfunktion anweist, einen Verbindungszustand an die versorgende Netzübergangsfunktion zu übertragen.
  6. Verfahren zum Optimieren der Leitweglenkung für ein gekoppeltes Datennetz, aufweisend Computer (2) und Modem (4), die mit dem Internet (20) und mit privaten Intranets (18) über ein öffentliches Telefonwählnetz (6) verbunden sind, das einen Übergabepunkt (8) für einen Internetdiensteanbieter (8) und einen Server (16) für die privaten Intranets (18) versorgt, wobei das gekoppelte Datennetz ferner aufweist ein Fremdnetz, das eine Basisstation und eine fremde Mobilfunkvermittlungsstelle mit einem versorgenden Registrierungsserver aufweist, wobei die Basisstation einen Zugangshub mit einer versorgenden Netzübergangsfunktion aufweist, ein Heimatnetz, das eine Heimatmobilfunkvermittlungsstelle mit einem Heimatregistrierungsserver und einer Heimatnetzübergangsfunktion aufweist, und ein Endsystem, das am Heimatnetz angeschlossen ist, gekennzeichnet durch die folgenden Schritte: Tätig sein im Fremdnetz, wobei das Endsystem einen Endregistrierungsagenten aufweist, um eine Regist rierungsaufforderung zu erzeugen, aufweisend die folgenden Schritte: Erzeugen einer Registrierungsaufforderung am Endsystem, wobei die Registrierungsaufforderung eine Angabe eines gewünschten Kommunikationsnetzes und eines gewünschten PPP-Kommunikationsservers enthält; Senden der Registrierungsaufforderung vom Endsystem an den versorgenden Registrierungsserver; Verarbeiten der Registrierungsaufforderung in einem ersten Modul im versorgenden Registrierungsserver, um einen bestmöglichen Leitweg zwischen dem gewünschten PPP-Kommunikationsserver und der Heimatnetzübergangsfunktion oder der versorgenden Netzübergangsfunktion zu bestimmen; Verbinden der versorgenden Netzübergangsfunktion mit dem gewünschten PPP-Kommunikationsserver, wenn das erste Modul bestimmt, dass der bestmögliche Leitweg zwischen der versorgenden Netzübergangsfunktion und dem gewünschten PPP-Kommunikationsserver ist.
  7. Verfahren nach Anspruch 6, welches ferner den folgenden Schritt aufweist: Senden der Registrierungsaufforderung mit einer angehängten Angabe, dass der versorgende Registrierungsserver die versorgende Netzübergangsfunktion und den gewünschten PPP-Kommunikationsserver verbunden hat, an den Heimatregistrierungsserver.
  8. Verfahren nach Anspruch 6 oder Netz nach Anspruch 1 oder 3, wobei: der gewünschte PPP-Kommunikationsserver ein Kommunikationsserver von mehreren Kommunikationsservern im gewünschten Kommunikationsnetz ist; und das erste Modul ein Hilfsmittel aufweist, das so ausgelegt ist, dass es den ausgewählten, den gewünschten PPP-Kommunikationsserver unter den mehreren Kommunikationsservern bestimmt.
  9. Verfahren nach Anspruch 6 oder Netz nach Anspruch 1 oder 3, wobei das Heimatnetz und das Fremdnetz Rechnungsinformationen für das Endsystem gemeinsam benutzen, wenn das Endsystem im Fremdnetz tätig ist.
  10. Verfahren nach Anspruch 6, welches ferner die folgenden Schritte aufweist: Feststellen, ob die versorgende Netzübergangsfunktion oder die Heimatnetzübergangsfunktion näher zum gewünschten PPP-Kommunikationsserver ist; Anweisen der versorgenden Netzübergangsfunktion, eine Verbindung mit dem gewünschten PPP-Kommunikationsserver herzustellen, wenn die versorgende Netzübergangsfunktion näher zum gewünschten PPP-Kommunikationsserver als die Heimatnetzübergangsfunktion ist; und Informieren des Heimatregistrierungsservers, dass das Endsystem durch die versorgende Netzübergangsfunktion und den gewünschten PPP-Kommunikationsserver versorgt wird.
DE69837136T 1997-10-14 1998-10-13 Optimierte Leitweglenkung Expired - Fee Related DE69837136T2 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US6191597P 1997-10-14 1997-10-14
US61915P 1997-10-14
US09/138,683 US6400722B1 (en) 1997-10-14 1998-08-24 Optimum routing system
US138683 1998-08-24

Publications (2)

Publication Number Publication Date
DE69837136D1 DE69837136D1 (de) 2007-04-05
DE69837136T2 true DE69837136T2 (de) 2007-12-06

Family

ID=26741647

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69837136T Expired - Fee Related DE69837136T2 (de) 1997-10-14 1998-10-13 Optimierte Leitweglenkung

Country Status (7)

Country Link
US (1) US6400722B1 (de)
EP (1) EP0917320B1 (de)
JP (1) JPH11275157A (de)
AR (1) AR016409A1 (de)
CA (1) CA2249863C (de)
DE (1) DE69837136T2 (de)
IL (1) IL126528A0 (de)

Families Citing this family (216)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6418324B1 (en) * 1995-06-01 2002-07-09 Padcom, Incorporated Apparatus and method for transparent wireless communication between a remote device and host system
US8606851B2 (en) 1995-06-06 2013-12-10 Wayport, Inc. Method and apparatus for geographic-based communications service
US5835061A (en) 1995-06-06 1998-11-10 Wayport, Inc. Method and apparatus for geographic-based communications service
SE9703327L (sv) * 1997-09-12 1999-03-13 Ericsson Telefon Ab L M Metod och anordning vid datakommunikation
US6577643B1 (en) * 1997-10-14 2003-06-10 Lucent Technologies Inc. Message and communication system in a network
EP0976211B1 (de) * 1998-01-16 2007-02-28 Symbol Technologies, Inc. Infrastruktur für drahtlose lans
US6735631B1 (en) * 1998-02-10 2004-05-11 Sprint Communications Company, L.P. Method and system for networking redirecting
US6496491B2 (en) * 1998-05-08 2002-12-17 Lucent Technologies Inc. Mobile point-to-point protocol
US6862622B2 (en) * 1998-07-10 2005-03-01 Van Drebbel Mariner Llc Transmission control protocol/internet protocol (TCP/IP) packet-centric wireless point to multi-point (PTMP) transmission system architecture
US6640248B1 (en) 1998-07-10 2003-10-28 Malibu Networks, Inc. Application-aware, quality of service (QoS) sensitive, media access control (MAC) layer
US6594246B1 (en) 1998-07-10 2003-07-15 Malibu Networks, Inc. IP-flow identification in a wireless point to multi-point transmission system
US6628629B1 (en) 1998-07-10 2003-09-30 Malibu Networks Reservation based prioritization method for wireless transmission of latency and jitter sensitive IP-flows in a wireless point to multi-point transmission system
US6452915B1 (en) * 1998-07-10 2002-09-17 Malibu Networks, Inc. IP-flow classification in a wireless point to multi-point (PTMP) transmission system
US6680922B1 (en) * 1998-07-10 2004-01-20 Malibu Networks, Inc. Method for the recognition and operation of virtual private networks (VPNs) over a wireless point to multi-point (PtMP) transmission system
US6590885B1 (en) 1998-07-10 2003-07-08 Malibu Networks, Inc. IP-flow characterization in a wireless point to multi-point (PTMP) transmission system
US6360100B1 (en) 1998-09-22 2002-03-19 Qualcomm Incorporated Method for robust handoff in wireless communication system
US8078727B2 (en) 1998-10-09 2011-12-13 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US7136645B2 (en) * 1998-10-09 2006-11-14 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US8060656B2 (en) * 1998-10-09 2011-11-15 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US7778260B2 (en) * 1998-10-09 2010-08-17 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US7293107B1 (en) * 1998-10-09 2007-11-06 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US6731627B1 (en) * 1998-11-17 2004-05-04 Cisco Technology, Inc. Virtual loop carrier system
CA2361726A1 (en) * 1999-02-04 2000-08-10 Apion Telecoms Limited A telecommunications gateway
US6829235B1 (en) * 1999-02-19 2004-12-07 Nokia Networks Oy Telecommunications network with parallel session function
US6560217B1 (en) * 1999-02-25 2003-05-06 3Com Corporation Virtual home agent service using software-replicated home agents
FI108832B (fi) 1999-03-09 2002-03-28 Nokia Corp IP-reitityksen optimointi accessverkossa
US6496511B1 (en) * 1999-05-21 2002-12-17 3Com Corporation Method for preserving preassigned IP addresses in a remote access server
JP3403971B2 (ja) * 1999-06-02 2003-05-06 富士通株式会社 パケット転送装置
US7882247B2 (en) * 1999-06-11 2011-02-01 Netmotion Wireless, Inc. Method and apparatus for providing secure connectivity in mobile and other intermittent computing environments
US6496867B1 (en) * 1999-08-27 2002-12-17 3Com Corporation System and method to negotiate private network addresses for initiating tunneling associations through private and/or public networks
US6785226B1 (en) * 1999-09-01 2004-08-31 Carriercomm, Inc. System and method for data routing over a network
US6526034B1 (en) 1999-09-21 2003-02-25 Tantivy Communications, Inc. Dual mode subscriber unit for short range, high rate and long range, lower rate data communications
US7035214B1 (en) * 1999-09-28 2006-04-25 Nortel Networks Limited System and method for a negative acknowledgement-based transmission control protocol
AU7854100A (en) 1999-10-05 2001-05-10 Nortel Networks Limited Key exchange for network architecture
JP3570310B2 (ja) * 1999-10-05 2004-09-29 日本電気株式会社 無線ｌａｎシステムにおける認証方法と認証装置
US6778517B1 (en) * 1999-10-14 2004-08-17 Bellsouth Intellectual Property Corporation Wireless broadband service
US7333451B1 (en) * 1999-10-18 2008-02-19 Nortel Networks Limited Buffer management for mobile internet protocol
US6721291B1 (en) * 1999-10-19 2004-04-13 Nokia Ip Anycast binding mobile communication method and system
DE19950653B4 (de) 1999-10-21 2020-01-16 Ipcom Gmbh & Co. Kg Verfahren zum Betreiben eines Mobilfunknetzes
US6571221B1 (en) * 1999-11-03 2003-05-27 Wayport, Inc. Network communication service with an improved subscriber model using digital certificates
US6970927B1 (en) 2000-04-18 2005-11-29 Wayport, Inc. Distributed network communication system which provides different network access features
WO2001037517A2 (en) * 1999-11-03 2001-05-25 Wayport, Inc. Distributed network communication system which enables multiple network providers to use a common distributed network infrastructure
WO2001035243A1 (en) * 1999-11-08 2001-05-17 Megaxess, Inc. QUALITY OF SERVICE (QoS) NEGOTIATION PROCEDURE FOR MULTI-TRANSPORT PROTOCOL ACCESS FOR SUPPORTING MULTI-MEDIA APPLICATIONS WITH QoS ASSURANCE
US6647001B1 (en) * 1999-12-06 2003-11-11 At&T Corp. Persistent communication with changing environment
AU1408501A (en) * 1999-12-22 2001-07-03 Tashilon Ltd. Enhanced computer network encryption using downloaded software objects
US6895434B1 (en) * 2000-01-03 2005-05-17 Cisco Technology, Inc. Sharing of NAS information between PoPs
EP1117231A3 (de) * 2000-01-14 2004-03-24 Sony Corporation Informationsverarbeitungsvorrichtung, Verfahren dafür, und Aufnahmemedium
US6781960B1 (en) * 2000-02-16 2004-08-24 Telefonaktiebolaget Lm Ericsson (Publ) Wireless multi-point communication system having automatically-updated sector-based routing capabilities
DE10007012B4 (de) * 2000-02-16 2010-07-01 Ipcom Gmbh & Co. Kg Verfahren zur bidirektionalen Datenübertragung über eine paketorientierte Netzwerkeinrichtung
US7173923B2 (en) * 2000-03-17 2007-02-06 Symbol Technologies, Inc. Security in multiple wireless local area networks
US7173922B2 (en) 2000-03-17 2007-02-06 Symbol Technologies, Inc. Multiple wireless local area networks occupying overlapping physical spaces
US20020022483A1 (en) * 2000-04-18 2002-02-21 Wayport, Inc. Distributed network communication system which allows multiple wireless service providers to share a common network infrastructure
US7814212B1 (en) * 2000-04-28 2010-10-12 Chan Hark C Data delivery system using local and remote communications
WO2002019636A1 (en) * 2000-08-31 2002-03-07 Padcom, Inc. Method and apparatus for routing data over multiple wireless networks
US7209958B2 (en) * 2000-09-14 2007-04-24 Musco Corporation Apparatus, system and method for wide area networking to control sports lighting
FI113319B (fi) * 2000-09-29 2004-03-31 Nokia Corp Palveluita tarjoavan verkkoelementin valitseminen tietoliikenejärjestelmässä
US7548978B2 (en) * 2000-10-03 2009-06-16 At&T Mobility Ii Llc Network access using network identification
US6885847B1 (en) * 2000-10-10 2005-04-26 Symantec Corp. Extension mechanism and technique for enabling low-power end devices to access remote networks using short-range wireless communications means
ATE469522T1 (de) * 2000-10-18 2010-06-15 Ericsson Telefon Ab L M Nahtlose weiterreichung bei mobile ip
US7653743B2 (en) * 2000-11-28 2010-01-26 Microsoft Corporation Protocol for throttling high volume messages
US7047273B2 (en) * 2000-11-28 2006-05-16 Navic Systems, Inc. Load balancing in set top cable box environment
US6980521B1 (en) 2000-11-29 2005-12-27 Cisco Technology, Inc. Method and apparatus for per session load balancing with improved load sharing in a packet switched network
JP3570377B2 (ja) * 2000-12-06 2004-09-29 日本電気株式会社 通信システム及びそれに用いる任意の通信網利用方法
US7917576B1 (en) * 2000-12-14 2011-03-29 At&T Intellectual Property I, L.P. System and method for sending electronic mail in a client-server architecture
US7131140B1 (en) 2000-12-29 2006-10-31 Cisco Technology, Inc. Method for protecting a firewall load balancer from a denial of service attack
GB2371954B (en) * 2001-02-01 2003-02-19 3Com Corp Interface system for wireless node and network node
US6947405B2 (en) * 2001-03-19 2005-09-20 Telefonaktiebolaget Lm Ericsson (Publ) Cellular system with cybercells
US7139833B2 (en) 2001-04-04 2006-11-21 Ipr Licensing, Inc. Proxy mobile node capability for mobile IP
WO2002082730A1 (en) 2001-04-09 2002-10-17 Colubris Networks Inc. Authentication and encryption method and apparatus for a wireless local access network
DE10120772A1 (de) 2001-04-24 2002-11-07 Siemens Ag Heterogenes Mobilfunksystem
US7369529B2 (en) * 2001-05-24 2008-05-06 Qualcomm.Incorporated. Method and apparatus for differentiating point to point protocol session termination points
DE60236879D1 (de) * 2001-05-25 2010-08-12 Symbol Technologies Inc Softwareprotokoll für ein drahtloses netzwerksystem
US7339903B2 (en) * 2001-06-14 2008-03-04 Qualcomm Incorporated Enabling foreign network multicasting for a roaming mobile node, in a foreign network, using a persistent address
US7027400B2 (en) * 2001-06-26 2006-04-11 Flarion Technologies, Inc. Messages and control methods for controlling resource allocation and flow admission control in a mobile communications system
US8000241B2 (en) * 2001-06-26 2011-08-16 Qualcomm Incorporated Methods and apparatus for controlling access link packet flow aggregation and resource allocation in a mobile communications system
US7474650B2 (en) * 2001-06-26 2009-01-06 Qualcomm Incorporated Methods and apparatus for controlling resource allocation where tunneling and access link packet aggregation are used in combination
US8046408B2 (en) * 2001-08-20 2011-10-25 Alcatel Lucent Virtual reality systems and methods
US20030058816A1 (en) * 2001-09-24 2003-03-27 Shearer Daniel D. M. Forwarding communication network and wireless channel allocation method therefor
GB0123057D0 (en) * 2001-09-25 2001-11-14 Red M Communications Ltd Virtual wireless network services
US7457267B1 (en) 2001-10-10 2008-11-25 Qualcomm Incorporated Methods and apparatus for quickly exploiting a new link during hand-off in a wireless network
FI20012339A0 (fi) 2001-11-29 2001-11-29 Stonesoft Corp Palomuurien välillä siirtyvien yhteyksien käsittely
WO2003049462A1 (en) * 2001-12-03 2003-06-12 Nokia Corporation Context filter in a mobile node
FR2833123B1 (fr) * 2001-12-03 2004-01-23 France Telecom Procede de gestion d'une communication avec des moyens de fourniture d'un service a serveurs multiples
US7346032B2 (en) * 2001-12-07 2008-03-18 Qualcomm Incorporated Method and apparatus for effecting handoff between different cellular communications systems
US7221684B1 (en) 2002-01-08 2007-05-22 Cisco Technology, Inc. Increasing network efficiency using packet compression and decompression
AU2003217301A1 (en) * 2002-02-04 2003-09-02 Flarion Technologies, Inc. A method for extending mobile ip and aaa to enable integrated support for local access and roaming access connectivity
US20030193952A1 (en) * 2002-02-04 2003-10-16 O'neill Alan Mobile node handoff methods and apparatus
US8649352B2 (en) * 2002-02-04 2014-02-11 Qualcomm Incorporated Packet forwarding methods for use in handoffs
US7564824B2 (en) * 2002-02-04 2009-07-21 Qualcomm Incorporated Methods and apparatus for aggregating MIP and AAA messages
US7471661B1 (en) * 2002-02-20 2008-12-30 Cisco Technology, Inc. Methods and apparatus for supporting proxy mobile IP registration in a wireless local area network
AU2003230821A1 (en) * 2002-04-08 2003-10-27 Flarion Technologies, Inc. Support of disparate addressing plans and dynamic ha address allocation in mobile ip
KR100442610B1 (ko) * 2002-04-22 2004-08-02 삼성전자주식회사 라디우스 프로토콜의 플로우 제어방법
US7289463B2 (en) * 2002-04-30 2007-10-30 Alcatel Lucent Hierarchical wireless network and an associated method for delivering IP packets to mobile stations
US20030233580A1 (en) * 2002-05-29 2003-12-18 Keeler James D. Authorization and authentication of user access to a distributed network communication system with roaming features
US7305429B2 (en) * 2002-06-10 2007-12-04 Utstarcom, Inc. Method and apparatus for global server load balancing
US7173933B1 (en) 2002-06-10 2007-02-06 Cisco Technology, Inc. System and method for providing source awareness in a network environment
KR100459183B1 (ko) * 2002-06-29 2004-12-03 엘지전자 주식회사 조합 모바일 ｉｐ 시스템 및 그를 이용한 모빌리티 관리방법
US7327705B2 (en) * 2002-07-03 2008-02-05 Massachusetts Institute Of Technology Hybrid wireless network for data collection and distribution
JP2004048334A (ja) * 2002-07-11 2004-02-12 Sony Corp データ転送制御装置、通信端末装置、データ通信システム、および方法、並びにコンピュータ・プログラム
US7286546B2 (en) * 2002-07-31 2007-10-23 Infosys Technologies Ltd. Method and system for providing reliable and fast communications with mobile entities
US7167912B1 (en) * 2002-08-09 2007-01-23 Cisco Technology, Inc. Method and apparatus for detecting failures in network components
US6993333B2 (en) * 2003-10-16 2006-01-31 Flarion Technologies, Inc. Methods and apparatus of improving inter-sector and/or inter-cell handoffs in a multi-carrier wireless communications system
US7639654B2 (en) * 2002-08-29 2009-12-29 Alcatel-Lucent Usa Inc. Method and apparatus for mobile broadband wireless communications
US7130878B2 (en) * 2002-08-30 2006-10-31 The Go Daddy Group, Inc. Systems and methods for domain name registration by proxy
US8775675B2 (en) * 2002-08-30 2014-07-08 Go Daddy Operating Company, LLC Domain name hijack protection
US7869803B2 (en) * 2002-10-15 2011-01-11 Qualcomm Incorporated Profile modification for roaming in a communications environment
US7882346B2 (en) 2002-10-15 2011-02-01 Qualcomm Incorporated Method and apparatus for providing authentication, authorization and accounting to roaming nodes
CN101715194A (zh) * 2002-10-18 2010-05-26 卡耐特无线有限公司 扩展有执照无线通信系统覆盖区域的装置与方法
CN1248461C (zh) * 2002-11-08 2006-03-29 华为技术有限公司 一种无线局域网中对用户签约信息的处理方法
US7133386B2 (en) * 2002-11-18 2006-11-07 Cisco Technology, Inc. Method and system for service portability across disjoint wireless networks
US7079521B2 (en) * 2002-11-18 2006-07-18 Cisco Technology, Inc. Method and system for voice calls in a wireless local area network (WLAN)
WO2004047474A1 (ja) * 2002-11-19 2004-06-03 Ntt Docomo, Inc. 移動通信システム、集線装置、無線基地局、移動局及び通信方法
CA2507529C (en) * 2002-11-27 2011-03-08 Research In Motion Limited Data transfer from a host server via a tunnel server to a wireless device, and associating a temporary ipv6 address with a temporary ipv4 address for communicating in an ipv4 wireless network with the device
US7457289B2 (en) 2002-12-16 2008-11-25 Cisco Technology, Inc. Inter-proxy communication protocol for mobile IP
US7362742B1 (en) 2003-01-28 2008-04-22 Cisco Technology, Inc. Methods and apparatus for synchronizing subnet mapping tables
US7668541B2 (en) 2003-01-31 2010-02-23 Qualcomm Incorporated Enhanced techniques for using core based nodes for state transfer
US6862446B2 (en) * 2003-01-31 2005-03-01 Flarion Technologies, Inc. Methods and apparatus for the utilization of core based nodes for state transfer
JP4295023B2 (ja) * 2003-02-25 2009-07-15 株式会社エヌ・ティ・ティ・ドコモ ネットワークを制御するシステム、装置及び方法
US20040170181A1 (en) * 2003-02-27 2004-09-02 Padcom, Inc. Prioritized alternate port routing
US20040179555A1 (en) * 2003-03-11 2004-09-16 Cisco Technology, Inc. System and method for compressing data in a communications environment
US7535878B2 (en) 2003-03-28 2009-05-19 Intel Corporation Method, apparatus and system for ensuring reliable access to a roaming mobile node
US7284054B2 (en) * 2003-04-11 2007-10-16 Sun Microsystems, Inc. Systems, methods, and articles of manufacture for aligning service containers
US7505432B2 (en) * 2003-04-28 2009-03-17 Cisco Technology, Inc. Methods and apparatus for securing proxy Mobile IP
WO2004098143A1 (de) 2003-04-28 2004-11-11 Chantry Networks Inc. Wireless communication network system and method
EP1634466A4 (de) * 2003-05-28 2011-03-16 Symbol Technologies Inc Verbesserte zellensteuerung für drahtlose netzwerke
ATE378634T1 (de) * 2003-05-28 2007-11-15 Symbol Technologies Inc Backup-zellensteuerung
US7460516B1 (en) 2003-07-30 2008-12-02 Cisco Technology, Inc. System and method for compressing communication flows in a network environment
US7372843B1 (en) 2003-09-23 2008-05-13 Cisco Technology, Inc. System and method for compressing information flows in a network environment
US7756040B1 (en) 2003-10-08 2010-07-13 Cisco Technology, Inc. System and method for relaying information in order to enable services in a network environment
US7734293B2 (en) * 2003-10-29 2010-06-08 Martin Zilliacus Mapping wireless proximity identificator to subscriber identity for hotspot based wireless services for mobile terminals
US7580396B2 (en) 2003-11-05 2009-08-25 Intel Corporation Method, apparatus and system for obtaining and retaining a mobile node home address
US8050275B1 (en) 2003-11-18 2011-11-01 Cisco Technology, Inc. System and method for offering quality of service in a network environment
US20050111380A1 (en) * 2003-11-25 2005-05-26 Farid Adrangi Method, apparatus and system for mobile nodes to dynamically discover configuration information
US20050113109A1 (en) * 2003-11-25 2005-05-26 Farid Adrangi Method, apparatus and system for context-based registrations based on intelligent location detection
US20050111454A1 (en) * 2003-11-25 2005-05-26 Narjala Ranjit S. Method, apparatus and system for intelligently and dynamically routing mobile internet protocol packets
US20050136924A1 (en) * 2003-12-04 2005-06-23 Farid Adrangi Method, apparatus and system for enabling roaming mobile nodes to utilize private home IP addresses
US7047009B2 (en) * 2003-12-05 2006-05-16 Flarion Technologies, Inc. Base station based methods and apparatus for supporting break before make handoffs in a multi-carrier system
US7212821B2 (en) * 2003-12-05 2007-05-01 Qualcomm Incorporated Methods and apparatus for performing handoffs in a multi-carrier wireless communications system
US7733793B1 (en) 2003-12-10 2010-06-08 Cisco Technology, Inc. System and method for suppressing silence data in a network environment
EP1542401B8 (de) * 2003-12-11 2010-09-08 Swisscom AG Netzzugangsvorrichtung für funkbasierte drahtlose lokale Netze
US7457315B1 (en) 2003-12-23 2008-11-25 Cisco Technology, Inc. System and method for compressing information in a communications environment
US7596107B1 (en) 2004-01-26 2009-09-29 Cisco Technology, Inc. System and method for enabling multicast group services in a network environment
US7590070B1 (en) 2004-02-03 2009-09-15 Cisco Technology, Inc. System and method for discretionary multiplexing and compressing in a communications environment
JP2005222261A (ja) * 2004-02-05 2005-08-18 Nec Corp 列車内ネットワーク接続サービス運用方法およびその方法を用いる通信システムならびにサービス運用システム
US7697501B2 (en) 2004-02-06 2010-04-13 Qualcomm Incorporated Methods and apparatus for separating home agent functionality
US7564381B1 (en) 2004-02-16 2009-07-21 Cisco Technology, Inc. System and method for code-based compression in a communications environment
JP2005268936A (ja) * 2004-03-16 2005-09-29 Canon Inc アクセスポイント、ネットワークシステム及びネットワークサービス提供方法
US8300824B1 (en) 2004-04-08 2012-10-30 Cisco Technology, Inc. System and method for encrypting data using a cipher text in a communications environment
US20050261970A1 (en) * 2004-05-21 2005-11-24 Wayport, Inc. Method for providing wireless services
US7599371B1 (en) 2004-06-09 2009-10-06 Cisco Technology, Inc. System and method for optimizing data transport in a communications system
US7020090B2 (en) * 2004-06-21 2006-03-28 Cisco Technology, Inc. System and method for loadbalancing in a network environment using feedback information
US7447188B1 (en) 2004-06-22 2008-11-04 Cisco Technology, Inc. Methods and apparatus for supporting mobile IP proxy registration in a system implementing mulitple VLANs
US7362721B1 (en) 2004-07-28 2008-04-22 Cisco Technology, Inc. System and method for providing fault and error tolerant communications in a network environment
US7764673B1 (en) 2004-08-04 2010-07-27 Cisco Technology, Inc. System and method for implementing a variable size codebook for compression in a communications environment
US7570662B2 (en) * 2004-09-21 2009-08-04 Cisco Technology, Inc. System and method for multiplexing, fragmenting, and interleaving in a communications environment
US7778278B2 (en) * 2005-03-28 2010-08-17 Cisco Technology, Inc. System and method for implementing dynamic suppression and recreation of suppressed data in a communications environment
US7340744B2 (en) * 2005-04-08 2008-03-04 Cisco Technology, Inc. System and method for optimizing sessions and network resources in a loadbalancing environment
US7403501B2 (en) * 2005-05-03 2008-07-22 Cisco Technology, Inc. System and method for implementing suppression in a communications environment
US8059672B2 (en) 2005-05-18 2011-11-15 Sprint Communications Company L.P. Internet communications between wireless base stations and service nodes
KR100711313B1 (ko) 2005-05-20 2007-04-27 에스케이 텔레콤주식회사 이동통신과 휴대인터넷간의 망 연동 방법
US7642936B2 (en) * 2005-05-24 2010-01-05 Cisco Technology, Inc. System and method for determining whether to dynamically suppress data in a communications environment
JP4421517B2 (ja) * 2005-06-07 2010-02-24 株式会社東芝 情報処理サーバ、遠隔操作システムおよび遠隔操作方法
US7477651B2 (en) * 2005-07-01 2009-01-13 Cisco Technology, Inc. System and method for implementing quality of service in a backhaul communications environment
US8009676B2 (en) * 2005-07-26 2011-08-30 Cisco Technology, Inc. Dynamically providing a quality of service for a mobile node
US20070058539A1 (en) * 2005-08-17 2007-03-15 Cisco Technology, Inc. System and method for implementing suppression for asynchronous transfer mode (ATM) adaptation layer 2 (AAL2) traffic in a communications environment
US8982835B2 (en) 2005-09-19 2015-03-17 Qualcomm Incorporated Provision of a move indication to a resource requester
US8983468B2 (en) 2005-12-22 2015-03-17 Qualcomm Incorporated Communications methods and apparatus using physical attachment point identifiers
US9078084B2 (en) 2005-12-22 2015-07-07 Qualcomm Incorporated Method and apparatus for end node assisted neighbor discovery
US8982778B2 (en) 2005-09-19 2015-03-17 Qualcomm Incorporated Packet routing in a wireless communications environment
US8509799B2 (en) 2005-09-19 2013-08-13 Qualcomm Incorporated Provision of QoS treatment based upon multiple requests
US9736752B2 (en) 2005-12-22 2017-08-15 Qualcomm Incorporated Communications methods and apparatus using physical attachment point identifiers which support dual communications links
US9066344B2 (en) 2005-09-19 2015-06-23 Qualcomm Incorporated State synchronization of access routers
US7675851B2 (en) * 2005-11-16 2010-03-09 Cisco Technology, Inc. System and method for synchronizing a back-up device in a communications environment
US7640020B2 (en) * 2005-12-19 2009-12-29 Motorola, Inc. Method and apparatus for assigning backhaul methods
US7929571B2 (en) * 2006-01-12 2011-04-19 Cisco Technology, Inc. System and method for implementing a preemptive retransmit for error recovery in a communications environment
US9083355B2 (en) 2006-02-24 2015-07-14 Qualcomm Incorporated Method and apparatus for end node assisted neighbor discovery
ITTO20060149A1 (it) * 2006-03-01 2007-09-02 Cisco Tech Inc Tecnica per l'instradamento ottimizzato di flussi di dati su una dorsale ip in una rete di computer.
JP4585479B2 (ja) * 2006-03-30 2010-11-24 株式会社東芝 サーバ装置および映像配信方法
US7821986B2 (en) * 2006-05-31 2010-10-26 Cisco Technology, Inc. WLAN infrastructure provided directions and roaming
US9258702B2 (en) * 2006-06-09 2016-02-09 Trapeze Networks, Inc. AP-local dynamic switching
US8818322B2 (en) 2006-06-09 2014-08-26 Trapeze Networks, Inc. Untethered access point mesh system and method
WO2008007375A2 (en) * 2006-07-13 2008-01-17 Designart Networks Ltd Wimax access point network with backhaul technology
US8000238B2 (en) * 2006-08-04 2011-08-16 Cisco Technology, Inc. System and method for detecting and regulating congestion in a communications environment
US7747767B2 (en) * 2006-08-25 2010-06-29 Invensys Systems, Inc. Remote operation of process control equipment over customer supplied network
US7944823B1 (en) 2006-09-01 2011-05-17 Cisco Technology, Inc. System and method for addressing dynamic congestion abatement for GSM suppression/compression
CA2664741A1 (en) * 2006-09-29 2008-04-10 The Dun And Bradstreet Corporation Process and system for automated collection of business information from a business entity's accounting system
US8005116B2 (en) * 2006-11-16 2011-08-23 Cisco Technology, Inc. System and method for mitigating the effects of bit insertion in a communications environment
US9155008B2 (en) 2007-03-26 2015-10-06 Qualcomm Incorporated Apparatus and method of performing a handoff in a communication network
US8830818B2 (en) 2007-06-07 2014-09-09 Qualcomm Incorporated Forward handover under radio link failure
US9094173B2 (en) 2007-06-25 2015-07-28 Qualcomm Incorporated Recovery from handoff error due to false detection of handoff completion signal at access terminal
US8261327B2 (en) 2007-07-12 2012-09-04 Wayport, Inc. Device-specific authorization at distributed locations
US8024634B2 (en) * 2007-08-07 2011-09-20 Cisco Technology, Inc. System and method for implementing a subrate recovery for lost packets in a communications environment
US8761751B2 (en) 2008-03-14 2014-06-24 William J. Johnson System and method for targeting data processing system(s) with data
US8923806B2 (en) 2008-03-14 2014-12-30 William J. Johnson System and method for presenting application data by data processing system(s) in a vicinity
US8600341B2 (en) 2008-03-14 2013-12-03 William J. Johnson System and method for location based exchanges of data facilitating distributed locational applications
US8634796B2 (en) 2008-03-14 2014-01-21 William J. Johnson System and method for location based exchanges of data facilitating distributed location applications
US8566839B2 (en) 2008-03-14 2013-10-22 William J. Johnson System and method for automated content presentation objects
US8639267B2 (en) 2008-03-14 2014-01-28 William J. Johnson System and method for location based exchanges of data facilitating distributed locational applications
US8472920B2 (en) * 2009-01-22 2013-06-25 Belair Networks Inc. System and method for providing wireless networks as a service
JP5189512B2 (ja) * 2009-01-27 2013-04-24 株式会社日立製作所 パケット転送方法及びノード装置
US8681626B1 (en) 2010-02-17 2014-03-25 Sprint Communications Company L.P. Translation of congestion notification indicators in a base station system
US8615241B2 (en) 2010-04-09 2013-12-24 Qualcomm Incorporated Methods and apparatus for facilitating robust forward handover in long term evolution (LTE) communication systems
US8719223B2 (en) 2010-05-06 2014-05-06 Go Daddy Operating Company, LLC Cloud storage solution for reading and writing files
US8522147B2 (en) 2011-09-20 2013-08-27 Go Daddy Operating Company, LLC Methods for verifying person's identity through person's social circle using person's photograph
US8538065B2 (en) 2011-09-20 2013-09-17 Go Daddy Operating Company, LLC Systems for verifying person's identity through person's social circle using person's photograph
CN102395167B (zh) * 2011-11-09 2014-03-05 广州杰赛科技股份有限公司 无线Mesh网络域间切换方法
CA2879180A1 (en) 2012-03-07 2013-09-12 Snap Trends, Inc. Methods and systems of aggregating information of social networks based on geographical locations via a network
US8738604B2 (en) 2012-03-30 2014-05-27 Go Daddy Operating Company, LLC Methods for discovering sensitive information on computer networks
US8738605B2 (en) 2012-03-30 2014-05-27 Go Daddy Operating Company, LLC Systems for discovering sensitive information on computer networks
US9141669B2 (en) 2013-01-22 2015-09-22 Go Daddy Operating Company, LLC Configuring an origin server content delivery using a pulled data list
US9160809B2 (en) 2012-11-26 2015-10-13 Go Daddy Operating Company, LLC DNS overriding-based methods of accelerating content delivery
US9384208B2 (en) 2013-01-22 2016-07-05 Go Daddy Operating Company, LLC Configuring a cached website file removal using a pulled data list
US9438493B2 (en) 2013-01-31 2016-09-06 Go Daddy Operating Company, LLC Monitoring network entities via a central monitoring system
US9477991B2 (en) 2013-08-27 2016-10-25 Snap Trends, Inc. Methods and systems of aggregating information of geographic context regions of social networks based on geographical locations via a network
US9894489B2 (en) 2013-09-30 2018-02-13 William J. Johnson System and method for situational proximity observation alerting privileged recipients
CN104254110A (zh) * 2014-09-19 2014-12-31 广州杰赛科技股份有限公司 一种无线Mesh网络域间切换方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE9304119D0 (sv) * 1993-12-10 1993-12-10 Ericsson Ge Mobile Communicat Apparatuses and mobile stations for providing packet data communication in digital TDMA cellular systems
US5606595A (en) * 1994-08-19 1997-02-25 Lucent Technologies Inc. Equal access to inter-exchange carriers in a mobile wireless packet data communication system
FI98586C (fi) * 1995-01-10 1997-07-10 Nokia Telecommunications Oy Pakettiradiojärjestelmä ja menetelmiä datapaketin reitittämiseksi protokollariippumattomasti pakettiradioverkoissa
US6134316A (en) * 1996-10-18 2000-10-17 Telefonaktiebolaget Lm Ericsson Telecommunications network with relocateability of subscriber number
US6151628A (en) * 1997-07-03 2000-11-21 3Com Corporation Network access methods, including direct wireless to internet access
US6108350A (en) * 1998-03-09 2000-08-22 3Com Corporation Method and apparatus for detecting the protocol used by an end station and negotiating a protocol used by the endpoint
US5983282A (en) * 1998-03-11 1999-11-09 3Com Corporation Method and system for computer network access using cooperating non-dedicated remote access servers
US6118785A (en) * 1998-04-07 2000-09-12 3Com Corporation Point-to-point protocol with a signaling channel
US6094437A (en) * 1998-10-09 2000-07-25 Asc - Advanced Switching Communications Layer two tunneling protocol (L2TP) merging and management

Also Published As

Publication number Publication date
AR016409A1 (es) 2001-07-04
DE69837136D1 (de) 2007-04-05
US6400722B1 (en) 2002-06-04
EP0917320A3 (de) 2005-06-15
JPH11275157A (ja) 1999-10-08
CA2249863A1 (en) 1999-04-14
EP0917320A2 (de) 1999-05-19
CA2249863C (en) 2003-07-01
IL126528A0 (en) 1999-08-17
EP0917320B1 (de) 2007-02-21

Similar Documents

Publication Publication Date Title
DE69837136T2 (de) Optimierte Leitweglenkung
DE69830223T2 (de) Punkt-zu-Punkt Protokoll Einkapselung in einem Ethernet-Rahmen
CA2249817C (en) Message and communication system in network
CA2249836C (en) Accounting system in a network
CA2249862C (en) Registration scheme for network
CA2249837C (en) An efficient mobility management scheme for a wireless internet access system
US6414950B1 (en) Sequence delivery of messages
US6665718B1 (en) Mobility management system
US6393482B1 (en) Inter-working function selection system in a network
DE69434896T2 (de) Zugriffsverfahren auf ein drahtloses lokales ad-hoc Netzwerk über ein zellulares Weitbereichnetzwerk mit Koppelung des LAN-MAC-Paketkopfes.
DE60209858T2 (de) Verfahren und Einrichtung zur Zugriffskontrolle eines mobilen Endgerätes in einem Kommunikationsnetzwerk
US7450940B2 (en) Wireless network communication system and method
DE60121626T2 (de) Zugriffssystem für ein Zugriffsnetzwerk
CN101287289B (zh) WiMAX汇聚子层中的信令传输
DE60308620T2 (de) Roaming-Dienst, der mehrere Anbieter für mobile Datenkommunikation abdeckt
DE202005017283U1 (de) Drahtloses Kommunikationssystem zum Implementieren eines medienunabhängigen Handover zwischen technologisch verschiedenartigen Zugangsnetzen
Rupp Teil 1: Netze und Dienste

Legal Events

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