DE60030527T2

DE60030527T2 - Rpcu (radio port control unit) und entsprechendes verfahren

Info

Publication number: DE60030527T2
Application number: DE60030527T
Authority: DE
Inventors: MA/254/RL96 Bo c/o HRL Laboratories Malibu RYU; Yongguang Moorpark Zhang
Original assignee: Hughes Electronics Corp
Current assignee: DirecTV Group Inc
Priority date: 1999-02-26
Filing date: 2000-02-23
Publication date: 2007-05-16
Anticipated expiration: 2020-02-24
Also published as: EP1103151A2; CA2329790C; EP1725054B1; CA2329790A1; WO2000051370A2; US6847633B1; JP2005027334A; WO2000051370A3; DE60030527D1; EP1725054A2; JP2002538689A; JP3616333B2; EP1725054A3; EP1103151B1

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Die vorliegende Erfindung betrifft Systeme und Verfahren zum Bereitstellen mobiler Zellenkommunikation und insbesondere ein Verfahren und ein System für Internetdienste in einem mobilen Zellenkommunikationsnetzwerk.
2. Beschreibung des betroffenen Standes der Technik
Ein System zur Verwaltung von IP Diensten in einem PACS Packet-Netzwerk ist bekannt aus dem Aufsatz „Managing IP services over a PACS packet network", Bo Ryu et al., IEEE Network, Vol. 12, No. 4, 1. Juli 1998–31. August 1998, Seiten 4–10, XP 002142781, USA.
Herkömmlicherweise wurden zellulare mobile und drahtlose Kommunikationssysteme für Sprachdienste entworfen und gebaut. Mit dem explosionsartigen Wachsen von Internetanwendungen und Nutzern gibt es eine wachsende Nachfrage nach Internetdiensten für mobile Nutzer basierend auf den existierenden zellularen Systemen. Sprachkommunikation ist gekennzeichnet als verbindungsorientiert, vermittelt, eine konstante Bitrate aufweisend und mit geringer Toleranz gegenüber Verlust und Jitter. Im Gegensatz dazu sind Internetdienste wie folgt gekennzeichnet: Verbindungslose Kommunikation, paketvermittelt, gebündelte Verkehrsmuster, Gruppenunterscheidungen mehrerer Klassen von Diensten und sehr häufig eine Best-Effort- und verlusttolerante Kommunikation. Zusätzlich wünschen einige Internetanwendungen eine sehr viel höhere und häufig On-demand-Bandbreite, wie beispielsweise Videokonferenzanwendungen, die variable Bitratencodierung nutzen. Soweit bleibt die Entwicklung von kostengünstigen Netzwerkarchitekturen und notwendigen Systemkomponenten, um diese unterschiedlichen Anforderungen eines Internetdienstes als Zugabe zu der existierenden Infrastruktur von sprachorientierten zellularen Netzwerken ein schwer umzusetzendes Ziel. Eine packet- und leitungsvermittelte Kommunikation in einem mobilen Kommunikations-Netzwerk is bspw. in WO98/27698 A1 offenbart.
1 ist eine Darstellung eines PACS (Personal Access Communication System, persönliches Zugangskommunikationssystem) 100. Das PACS ist ein aufkommender, kostengünstiger low-tier PCS-Standard für zellulare drahtlose Dienste in dicht bevölkerten Gebieten. Der PACS-Standard definiert zwei Datenkommunikationsmodi (Leitungs-Modus (circuit-mode) und Paket-Modus).
In einem PACS-Netzwerk 100 erhalten die Benutzer Dienste über Teilnehmereinheits(SU)-Vorrichtungen 102. SUs 102 kommunizieren mit Funkanschlüssen (radio ports; RPs) über eine zeitgemultiplexte (Time Division Multiple Access) (TDMA) Aufwärtsverbindung mit Mehrfach-Zugriff und eine zeitgemultiplexte (TDM) Abwärtsverbindung. Der Einfluss der RPs 104, der durch deren Übertragungs- und Empfangsreichweite definiert wird, und der der SUs 102 definieren eine Zelle 112.
Nahe beieinanderliegende RPs 104 werden über eine Funkanschlusssteuerungseinheit (RPCU; Radio Port Control Unit) 106 gesteuert, die den gesamten Verkehr von den RPs 104 konzentriert und ihn in ein Backbone-Sprach- oder Datennetzwerk führt. Die Benutzerautorisierung und andere betroffene Funktionen werden von einem Zugangsmanager (AM; Access Manager) 108 und einem Signalisierungsnetzwerk 110 bereitgestellt.
Der PACS-Standard-Paket-Modus-Datendienst dient als grundlegender Baustein zur Implementierung und zur Verwaltung von IP-Diensten in der Internetdienstearchitektur der vorliegenden Erfindung.
Der Paket-Modus-Datendienst des PACS, bekannt als PACS Packet Channel (PPC), liefert dem Nutzer eine variable Bandbreite, eine asynchrone Bandbreite auf Anforderung und einen asymmetrischen Datendienst mit Datenraten bis zu 256000 Bytes pro Sekunde (Kbps). Er basiert auf einer Frequenz-Duplex-TDMA-Aufwärtsverbindungs- und TDM-Abwärtsverbindungs-physischen PACS-Schnittstelle, die sowohl dem Leitungsmodus als auch dem Paket-Modus-Dienst gemeinsam ist. Aufwärtsverbindung betrifft die Richtung von dem SU 102 zu der RPCU 106, und Abwärtsverbindung von der RPCU 106 zu der SU 102. Die hohe Datenrate und variable Bandbreitennatur des PPC ist gut geeignet für Multimedia und für die stoßartige Natur von Internetverkehr. PPC unterstützt das dynamische Teilen von Bandbreite mit den PACS-Leitungs-Modus-Diensten (Sprache, Leitungsmodusdaten, etc.) und ermöglicht dem PPC, die ansonsten freie Bandbreite zu benutzen.
2A ist ein Diagramm, das eine Darstellung der PPC-Schichten bzw. Ebenen zeigt. Das PPC besteht aus drei Schichten: einer physischen PACS-Schicht 202, einer Datenverbindungsschicht (DL) 204 und einer Sicherheitsschicht (SL) 206. Die physische PACS-Schicht führt eine Codierung der TDMA-Aufwärtsverbindung und der TDM-Abwärtsverbindung aus. Sowohl die Aufwärtsverbindungs-TDMA und die Abwärtsverbindungs-TDM-Blöcke sind 2,5 Millisekunden lang. Jeder Block besteht aus 8 Schlitzen und jeder Schlitz ist 10 Bytes lang. Die Aufgabe der PPC-DL-Schicht 204 besteht darin, einen zuverlässigen und verbindungslosen Kommunikationsdienst der SL-Schicht 206 bereitzustellen, die eine Zugangssteuerung (MAC), eine Fragmentierung und Segmentierung und eine Fehlererfassung und Korrektur enthält. Die Hauptfunktionen der SL-Schicht 206 sind die Handgeräteregistrierung, die Benutzerauthentifizierung und die Datenverschlüsselung.
2B zeigt die PACS-Standard-Kapselungs- und Rahmungsprozedur. Zuerst kopiert der PPC jedes Netzwerk-Schicht-Paket 210 in ein SL-Paket 212 mit einem Header 214 und einer Prüfsumme 216 mit einer optionalen Nutzlastverschlüsselung, um ein Abhören über Funk zu verhindern. Es kapselt dann jedes SL-Paket 212 in ein DL-Paket 218 mit einem passenden Header 220 und einer Prüfsumme 222 ein. Jedes DL-Paket 218 wird in ein oder mehrere DL-Fragmente 224 aufgetrennt und schließ lich wird jedes DL-Fragment 224 in DL-Segmente 276 aufgeteilt. Die Fragmentierung ist für die Mediumzugangsfunktion hoher Ebene – der PPC muss eine Schlitznummer (aus 8 Schlitzen) für jedes DL-Fragment 224 zuordnen und alle Segmente eines Fragments 224 müssen in dem gleichen Schlitz übertragen werden. Die Segmentierung dient dazu, die TDM/TDMA-Funkverbindungsstruktur anzupassen, die in 2C gezeigt ist.
Bei der Abwärtsverbindungsfragmentierung ist die maximale Fragmentgröße 576 Bytes an Daten. Ein größeres Paket muss fragmentiert werden, aber jedes Fragment kann in unterschiedlichen Schlitzen parallel übertragen werden. Aufwärtsverbindungsfragmente können 256 Segmente lang sein, deshalb werden alle Aufwärtsverbindungs-DL-Pakete 218 in einem einzelnen Fragment gesendet.
2D und 2E sind Diagramme, die das Einkapseln von Aufwärtsverbindungs- und Abwärtsverbindungsnachrichten in größerem Detail darstellen.
3 ist ein Diagramm der funktionalen Architektur des PPC. Eine konkurrierende Anforderungs bzw. Contention-Funktion (CF) 302 führt die kleine Teilmenge von DL-Medium-Zugangs- und Bestätigungsprozeduren aus, die sehr zeitkritisch sind. Eine Paketdaten-Steuerungseinheit (PDCU) 304 handhabt den Rest der DL- und SL-Funktionen. Die CF 302 ist in dem RP 104 und der PDCU 304 ist typischerweise in dem RPCU 304 implementiert.
Jedes Paket-Modus SU 102 besitzt eine Teilnehmeridentität (SubID). Die SubID wird nur benutzt, um einen Benutzer während der Registrierung zu authentifizieren. Zusätzlich hat jede aktive SU 102 auch einen vorübergehenden Identifikator, der LPTID (Local Packet Terminal Identifier) genannt wird. Der LPTID ist eine Einbyte-Integer-Zahl, die die Quell-/Ziel-SU 102 in jedem Aufwärtsverbindungs/Abwärtsverbindungsschlitz über die drahtlose Verbindung spezifiziert. Jedes Mal, wenn eine SU 102 in eine Zelle 112 gelangt (beim Kaltstart oder beim Roaming), wird ihr eine eindeutige LPTID so lange zugeordnet, wie sie in der Zelle 112 verbleibt. Eine LPTID ist nur in der aktuellen Zelle 112 gültig, und ein SU 102 kann einen unterschiedlichen LPTID-Wert in einer anderen Zelle 112 haben. LPTIDs werden von dem PACS-Netzwerk 100 nach einer erfolgreichen Registrierung zugeordnet und werden neu zugeordnet nach jeder Verbindungsumschaltung (hand-off). Wenn sich die SU 102 in eine benachbarte Zelle bewegt, wird die alte LPTID nicht mehr benutzt werden, und eine neue LPTID muss in der neuen Zelle 112 zugeteilt werden. Die LPTID ist folglich von vorübergehender Natur. Die Tabelle 1 nachfolgend zeigt das aktuelle Belegungsschema für LPTID, wie es im Standard definiert ist.
Nach einer erfolgreichen Registrierung wird jeder aktiven SU 102 eine Datalink- bzw. Datenverbindungsschicht-Adresse zur Benutzung in der aktuellen Zelle 112 zugewiesen. Die Datenverbindungsschicht-Adresse ist eine Einbyte-Integer-Zahl, die LPTID genannt wird (Local Package Terminal ID).
Wann immer eine SU 102 in das Netzwerk gelangt, wird eine PPC-Registrierung ausgeführt. Zwei Hauptaufgaben der PPC-Registrierung sind die Authentifizie rung und die LPTID-Zuweisung. Zu Beginn der Registrierung sendet die SU 102 eine Registrierungsanforderungsnachricht (PACKET_REG_REQ), die ihre SubID (unter Annahme keiner Benutzeranonymität) umfasst. Die AM 108 authentifiziert dann die SU 102, indem diese SubID benutzt wird. Sobald die Authentifizierung erfolgreich ist, weist die PDCU 304 eine neue LPTID zu und sendet die Registrierungsbestätigungsnachricht (PACKET_REG_ACK) mit dieser LPTID zurück an die SU 102. Ab diesem Zeitpunkt identifiziert die SU 102 Daten, die für sie bestimmt sind, durch die LPTID, bis sie sich vom Netzwerk abmeldet oder in eine andere Zelle 112 gelangt.
Eine Zellenverbindungsumschaltung ist als automatischer Verbindungstransfer (ALT; Automatic Link Transfer) bekannt. ALT findet statt, wenn die SU 102 die Grenze der Funk-Zelle 112 überschreitet. Er beginnt, wenn ein SU 102 die Verschlechterung des aktuellen physischen Kanals detektiert und einen anderen physischen Kanal findet, der eine ausreichende hohe Qualität besitzt. Die SU 102 sendet dann eine ALT-Anforderungsnachricht an den neuen RP 102. Sobald die Anforderung akzeptiert ist, erhält die SU 102 eine ALT-Ausführungsnachricht zurück und eine neue LPTID für die neue Zelle 112. Abhängig davon, ob die zwei Kanäle mit der gleichen RPCU 106 verknüpft sind oder nicht, kann ALT in zwei Kategorien aufgeteilt werden: eine Intra-RPCU ALT, wenn die SU 102 sich in eine benachbarte Zelle in dem gleichen RPCU 106 bewegt, und eine Inter-RPCU ALT, wenn sich die SU 102 zu einer anderen RPCU 106 bewegt.
Bislang hat sich PACS 100 hauptsächlich als ein Sprachnetzwerk entwickelt. Obgleich der Standard zwei Datenkommunikationsmodi definiert (Leitungsmodus und Paketmodus), wird eine Internetdiensteunterstützung in einem PACS-Netzwerk 100 nicht angesprochen. Internetzugang könnte über den Leitungsmodus-Datendienst bereitgestellt werden, wo Benutzer eine Punkt-zu-Punkt-Protokoll(PPP)-Verbindung zu einem Internet-Service-Provider (ISP) über einen dedizierten PACS-Kanal aufbauen. Aufgrund der festen Bandbreite ist jedoch dieser Zugangstyp nicht skalierbar und für Internet-Anwendungen nicht effizient.
Was benötigt wird ist eine Netzwerkarchitektur und ein Satz von Design-Richtlinien, um eine nahtlose Integration zellularer Netzwerke in das globale Internet zu erreichen, indem mobile und Gruppen-IP-Dienste (Multicast-IP-Services) in zellularen Netzwerken unterstützt werden. Die vorliegende Erfindung erfüllt dieses Bedürfnis.
ZUSAMMENFASSUNG DER ERFINDUNG
Um die Bedürfnisse und Anforderungen, wie sie zuvor ausgeführt wurden, zu erfüllen, offenbart die vorliegende Erfindung einen Radio-Port-Controller-Einheit wie in Anspruch 1 definiert und das entsprechende Verfahren, wie es in Anspruch 9 definiert ist. Sie erweitert das PACS-Sprachnetzwerk mit IP-Routern und Backbone-Verbindungen, um eine Verbindung zum Internet oder einem Intranet zu schaffen. Ferner, obgleich nicht in der vorliegenden Erfindung beansprucht, wird eine Mobile-IP in den Leitungsumschaltmechanismus eingebaut, um ein Roaming innerhalb eines PACS-Netzwerks sowie eine globale Mobilität zwischen PACS-Netzwerken und dem Rest des Internets/Intranets zu unterstützen. Die Beschreibung offenbart auch, obgleich in der vorliegenden Erfindung nicht beansprucht, die Verwendung von nativen PACS-Multicast und Gruppenmanagement-Schemata, um dynamisches IP-Multicast und eine Multicast-Backbone(MBone)-Konnektivität zu unterstützen.
Diese Merkmale integrieren sich nahtlos in existierende PACS-Netzwerke im globalen Internet und stellen einen standardkonformen IP-Dienst mit globaler Mobilitätsunterstützung bereit. Das System ermöglicht es einem PACS-Benutzer, einen Internetzugang drahtlos zu erhalten, indem eine Prototyp-Paket-Modus-SU verwendet wird, die mit einem mobilen Personal Computer (PC) verbunden ist. Die meisten IP-Anwendungen können ablaufen, als ob der mobile Personal Computer ein fester Internet-Host wäre.
Die vorliegende Erfindung definiert ein Verfahren und eine Vorrichtung zur Kommunikation von Information, insbesondere Information, die von und zu einem Internet-Host übertragen wird. Die Vorrichtung umfasst eine Radio-Port-Controller- Einheit, die einen Router und einen Stub (engl.: stub) aufweist. Der Router ist kommunikativ verbunden, um Nachrichten von und zu einem Internet-Host zu empfangen und zu senden, und ist kommunikativ verbunden mit einem Packet-Weiterleitungs-Modul, das Nachrichten von einer SU annimmt und SU-adressierte Nachrichten an das Packet-Weiterleitungs-Modul in einem ersten Daten-Übertragungs-Protokoll liefert. Der Stub ist verbunden zwischen einem Router-Anschluß und dem Packet-Weiterleitungs-Modul, um Nachrichten aus dem zweiten Daten-Übertragungs-Protokoll in das erste Daten-Übertragungs-Protokoll zu übersetzen.
Das Verfahren umfasst die entsprechenden Schritte.
Die vorliegende Erfindung führt zu (1) einer PACS-Systemarchitektur, die einen drahtlosen Internet- und Intranetzugang bereitstellt, indem das Sprachnetzwerk mit IP-Routern und Backbone-Verbindungen zur Verbindung mit dem Internet erweitert wird; (2) einem vereinfachten RPCU-Design für eine leichte Dienstewartung und Migration zu zukünftigen IP-Standards, wie IPv6.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Es wird nun auf die Zeichnungen Bezug genommen, in denen gleiche Bezugszeichen entsprechende Teile durchgängig bezeichnen:
1 ist eine Darstellung eines Personal Access Communication Systems (PACS);
2A ist ein Diagramm, das eine Darstellung der PACS-Paket-Kanal-Schichten zeigt; und
2B ist ein Diagramm, das die PACS-Standard-Einkapselung und Rahmung darstellt;
2C ist ein Diagramm der TDM/TDMA-Sendeverbindungsstruktur des PACS;
2D und 2E sind Diagramme, die die eingekapselten Aufwärtsverbindungs- und Abwärtsverbindungsnachrichten in größerem Detail darstellen;
3 ist ein Diagramm der funktionalen Architektur des PPC;
4 ist ein Diagramm der PACS-Internet-Services-Architektur (PISA);
5A ist ein Blockdiagramm einer Ausführungsform der Radioanschluss-Steuerungseinheit (RPCU);
5B ist ein Blockdiagramm einer anderen Ausführungsform der RPCU, die einen kommerziellen Standard-IP-Router verwendet;
6A und 6B sind Flussdiagramme, die beispielhafte Operationen zeigen, die bei der Ausführung der vorliegenden Erfindung verwendet werden;
7A–7D sind Diagramme, die die Registrierung, die Intra-RPCU-Leitungsumschaltung, die Inter-RPCU-Umschaltung und die Abmeldung zeigen;
8A ist ein Diagramm, das den Nachrichtenaustausch während einer normalen Mobile-IP-Registrierung zeigt;
8B ist ein Diagramm, das die Mobile-IP-Registrierung in der PISA zeigt;
9A und 9B sind Diagramme, die die Multicast-Registrierung in der PISA zeigen; und
10 und 11 sind Diagramme, die zeigen, wie unterschiedliche Fragmentierungsstrategien die Leistung beeinflussen.
DETAILLIERTE BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
In der nachfolgenden Beschreibung wird Bezug genommen auf die begleitenden Zeichnungen, die Teil der Beschreibung bilden und in denen illustrativ mehrere Ausführungsformen der vorliegenden Erfindung gezeigt sind. Es versteht sich, dass andere Ausführungsformen verwendet werden können und strukturelle Änderungen vorgenommen werden können, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
PACS-Internet-Service-Architektur
4 ist ein Diagramm, das die PACS-Internet-Service- bzw. Dienste-Architektur (PISA) zeigt. Die PACS-Internet-Services-Architektur 400 umfasst das existierende PACS-Sprachnetzwerk 100 und erweitert es mit einem neuen Datennetzwerk, das PPN (PACS Paket-Netzwerke) 416 genannt wird. Das Teilnetz 418 ist die Basis-Teil-Netzwerkeinheit, um drahtlos Paketdaten an SUs 102 zu liefern. Ein IP-Teilnetz 418 umfasst eine oder mehrere Zellen 112, eine Basisstation oder RP 104 pro Zelle 112 und einen RPCU 106, der alle Zellen mit einem drahtlosen Backbone-Zwischenverbindungsnetzwerk verbindet. Die RPCU 106 wirkt ebenfalls als Netzwerk-Gateway und Multicast-Server für das Teilnetz 418.
Jede RPCU 106 steht in Kommunikation mit einem Internet-Protokoll(IP)-Router 410. PPN 416 ist ein Zwischennetzwerk, das alle IP-Teilnetze 418 über die IP-Router 410 und die Backbone-Verbindungen 420 verbindet. Grenz-Gateways (GW) 412 verbinden unterschiedliche PPNs 416 (von unterschiedlichen PACS-Netzwerk-Operatoren) und das globale Internet 414. Jedes GW 412 umfasst ebenfalls eine Firewall und andere Sicherheitsfunktionen, um die PACS-Netzwerkeinrichtungen und PACS-Nutzer zu schützen. In der PISA 400 bildet ein mobiler Personal Computer (PC) mit der Paket-Modus SU 102 einen legitimierten Host in dem Internet/Intranet mit einer eindeutigen IP-Adresse. Die SUs 102 sind Netzwerkvorrichtungen, die den mobilen Host mit einer drahtlosen Netzwerkschnittstelle zu dem Internet über das PACS-Netzwerk versehen. Das PPN 416 wird ein großes IP-Netzwerk.
Wenn ein Benutzer sich bei dem PACS-IP-Dienst durch einen Netzwerkoperator einschreibt, wird der SU 102 eine permanente IP-Adresse von einem "Heim"-Netzwerk zugeteilt. Wenn der Benutzer einen Personal Computer mit der SU 102 verbindet, wird der PC diese IP-Adresse als seine Host-Adresse für den Zugang in das Internet benutzen. In diesem Zusammenhang ist das Heim-Netzwerk ein IP-Teilnetzwerk 18, das von einem RPCU 106 bedient wird, das der Benutzer am häufigsten benutzen wird. Der Netzwerkoperator zeichnet die permanente IP-Adresse mit seiner Datenbank auf, die später von AMs 108 durchsucht werden kann. Für jedes SU-adressierte IP-Datagramm, das zu dieser IP-Adresse gesendet wird, ist das PPN 416 zum Weiterleiten des Pakets in das "Heim"-Teilnetz 418 verantwortlich. Die entsprechende RPCU 106 liefert dann dieses an die Ziel-SU 102, wenn sich der Benutzer momentan innerhalb des Heim-IP-Teilnetzes 418 befindet. Ausgehende IP-Datagramme von der SU 102 (SU-ausgegeben) werden von der RPCU 106 an einen IP-Router weitergeleitet. Das Unicast-Weiterleiten im PPN 416 gewährleistet die richtige Auslieferung über das PPN 416 und das Internet. Die Handhabung von Fällen, bei denen eine SU 102 sich außerhalb des Heim-IP-Teilnetzes 418 bewegt, werden später in dieser Offenbarung diskutiert.
Aus dem Blickwinkel des IP-Netzwerks verhält sich die RPCU 106 und deren RPs 104 als eine intelligente Verbindungs-Schicht-Router/Brücke zwischen dem IP-Router 410 und allen IP-Hosts (SUs 102). Diese Architektur verbirgt die PACS-spezifischen Details gegenüber dem IP-Router 410, so dass man kommerziell erhältliche Standardprodukte (COTS; commercial off the shelf) verwenden kann. Die Verbindung zwischen RPCU 106 und dem IP-Router 410 kann ein beliebiges Datennetzwerk sein, wie beispielsweise Ethernet oder Frame Relay. Da viele Router mehrere IP-Teilnetze 418 unterstützen, ist es leicht, einen IP-Router 410 mit mehreren RCPUs 106 zu verbinden, nämlich ein RPCU 106 pro Router-Anschluss.
Diese Netzwerkarchitektur unterscheidet sich wesentlich von einem herkömmlichen Telekommunikationsnetzwerk. Während allgemein angenommen wird, dass eine Autonomous transfer mode(ATM)-Kommunikation das Backbone des drahtlosen Telekommunikationsnetzwerks der dritten Generation sein wird, ist ein IP-Netzwerk eine bessere Wahl. ATM ist nachweislich ineffizient bei der Unterstützung von Übertragungssteuerungsprotokoll/Internetprotokoll(TCP/IP)-Anwendungen und die Extraschicht ist nicht notwendig. Ein IP-basiertes Intranet kostet weniger im Hinblick auf die Installation und die Verwaltung. Ferner würde die Mobile-Verwaltung sowohl in den IP als auch in den ATM-Schichten auszuführen sein. Während die ATM-Mobilität in der Forschung ist, ist Mobile-IP durch die Internet Community standardisiert und ist in einer Vielzahl von kommerziellen Produkten unterstützt. Die Multicast-Mechanismen bei Mobile-IP sind ebenfalls überlegen.
Die Hauptfunktion der RPCU in der PISA 400 besteht darin, IP-Datagramme SUs 102 zu liefern und von diesen zu erhalten. Die RPCUs 106 dienen der Basisnetzwerk-Schicht als Datenverbindungs-Schicht-Interfacefunktionen: Adressauflösung, Einrahmung und Medienzugang.
5 ist ein Blockdiagramm einer Ausführungsform der RPCU 106 und der zugehörigen Systemelemente. Eine Schlüsselkomponente der RPCU ist das Paketweiterleitungsmodul (PFM) 402, das eine Netzwerkschicht-zu-Datenverbindungsschicht-Adress-Umsetzung implementiert. Ein Netzwerkschichtmodul, wie beispielsweise ein IP-Router-Weiterleitungsfunktionsmodul 532 handhabt ein Weiterleiten zwischen den PACS-Benutzern und dem Backbone-Netzwerk.
Die PISA 400 benutzt die LPTID als Datenverbindungsschicht-Adresse. Um SU-adressierte Daten, wie beispielsweise ein IP-Datagramm, in Abwärtsverbindungsrichtung zu liefern, koordiniert das PFM 402 eine oder mehrere Paketdatensteuerungseinheiten PDCUs 304, um die LPTIDs zu verwalten. Dies deshalb, weil das PFM 402 wissen muss, welche Zelle 112 (und zugehörige RP 104) der Empfänger des SU's 102 hat und welche LPTID zu benutzen ist. Somit hält das PFM 402 eine Abbildung zwischen der IP-Adresse und dem Tuple (RP-Identifikation, LPTID) für jede SU 102 aufrecht. Bei einer Ausführungsform wird diese Abbildung als eine Tabelle gespeichert, die (Unicast)-Adressauflösungstabelle (ART 404) bezeichnet wird (der Multicast-Fall wird später in dieser Offenbarung diskutiert). Die ART 404 wird während der Benutzerregistrierung, ALT und der Abmeldung aktualisiert. Sobald ein Eintrag gefunden ist, leitet das PFM 402 den RP-Identifizierer und die LPTID-Information zusammen mit dem IP-Datagramm an die entsprechende PDCU 304, die mit der RP 104 verknüpft ist, die die Zelle 112 bedient, in der sich die SU 102 befindet.
Das IP-Weiterleiten von SU-gesendeten Daten in Aufwärtsverbindungsrichtung (SU 102 zu RPCU 106) wird wie folgt implementiert. Die PDCU 304 empfängt Segmente von der RP 104, die die Zelle 112 bedient, in der sich die SU 102 befindet, und sammelt die Datenverbindungsnutzlast. Wenn die PDCU 304 ein vollständiges IP-Datagramm empfangen hat, gibt es das Datagramm an das PFM 402. Das PFM 402 überprüft, ob das Datagramm an eine andere SU 102 in dem gleichen Teilnetz 418 gerichtet ist. Falls das Datagramm an eine andere SU 102 dem gleichen Teilnetz 418 gerichtet bzw. adressiert ist, leitet dann das PFM 402 die Nachricht weiter, indem die gleiche Prozedur wie zuvor beschrieben verwendet wird. Falls nicht, leitet das PFM 402 das IP-Datagramm an das Routing-Modul 532 zur Verbreitung über eine Datenverbindungsvorrichtung 518 zu dem PPN-Backbone.
Das IP-Routing-Modul 532 in der RPCU 106 sendet und empfängt Nachrichten zu bzw. von einem Internet-Host über eine Datenverbindungsvorrichtung 518 für das PPN-Netzwerk 416. Das IP-Routing-Modul 532 kann Schnittstellen mit verschiedenen Typen von Datenverbindungsvorrichtungen 518 haben, und wählt die geeignete Datenverbindungsvorrichtung 518 basierend auf der Verbindungstechnologie aus, die in dem PPN-Backbone verwendet wird. Das IP-Routing-Modul 532 kommuniziert die Nachrichten, die über die Datenverbindungsvorrichtung 518 empfangen wurden, zu der PACS-Vorrichtung 536 über einen IP-Router-Anschluss 534.
5B ist ein Blockdiagramm, das eine andere Ausführungsform der RPCU 106 zeigt. Bei dieser Ausführungsform benutzt die RPCU 106 einen modularen Weg, der zwei physisch getrennte Hardware-Einheiten umfasst: Einen kommerziell erhältlichen Standard(COTS)-IP-Router 538 und eine PACS-Vorrichtung 536.
Viele COTS-IP-Router 538 unterstützen mehrere Verbindungen mit unterschiedlichen Datenübertragungsprotokollen (beispielsweise Ethernet oder Frame Relay), und die Daten, die der PACS-Vorrichtung 536 über den IP-Router-Anschluss 534 verfügbar gemacht werden, können jedem dieser Protokolle entsprechen. Gleichzeitig wird die PACS-Vorrichtung 536 allgemein nicht mit jedem allgemeinen Datenübertragungsprotokoll übereinstimmen. Folglich werden Leitungen bzw. Stubs 530 zwischen dem IP-Router-Anschluss 534 und dem Paketweiterleitungsmodul 402 vorgesehen. Diese Stubs 534 führen die notwendige Übersetzung aus, um Nachrichten aus dem Datenübertragungsprotokoll, das dem IP-Router-Anschluss 534 angeboten wird, und das Protokoll, das von der PACS-Vorrichtung 536 benötigt wird, umzuwandeln. Der Stub 534 kann durch eine allgemeine Local Area Network-Vorrichtung (LAN) implementiert werden. Ferner kann der Stub 534 zwei Stub-Elemente aufweisen, wobei eines in der PACS-Vorrichtung 536 enthalten ist. In jedem Fall leitet die Stub-Vorrichtung 534 Datenpakete zu und von dem Paketweiterleitungsmodul 402 weiter und führt jede Protokoll und/oder Sprachübersetzung aus, die erforderlich ist.
Ein Vorteil dieses modularen Wegs besteht darin, dass Änderungen an einer Vorrichtung die andere nicht beeinflussen, was eine schnelle und einfache Upgrademöglichkeit bietet. Beispielsweise beeinflussen Verbesserungen der Mobile-IP-Protokolle nur den COTS-IP-Router 538, während Veränderungen der PACS-Vorrichtung 536 den COTS-IP-Router 538 nicht beeinflussen. Im Ergebnis können neue Dienste und Funktionen leichter eingerichtet werden. Die Benutzung des COTS-IP-Routers 538 macht die Notwendigkeit der Datenverbindungsvorrichtung 518 überflüssig.
Zusätzlich zu der Sicherheitsschicht umfasst die SU 102 ein PPC-Modul 506, das den gleichen Basisnetzwerk-Schicht-zu-Datenverbindungs-Schicht-Schnittstellenfunktionen dient wie die PDCU 304 und die CF 302 einschließlich der Rahmung bzw. Blockbildung und dem Medienzugang. Die Adressauflösung ist jedoch nicht mehr erforderlich, da die Kommunikation mit irgendeinem anderen Host immer über RPCU 106 erfolgt.
Die SU 102 umfasst ebenfalls eine PACS physische Schichtfunktion (PLF) 504, die Datenpakete mit der RP 104 empfängt und sendet, einen PACS-Paket-Kanal (PPC) 506, der die empfangenen Datenpakete in Nachrichten zusammensetzt, ein Internet-Protokoll-Modul 508, das Nachrichten in das Internet-Protokoll übersetzt.
6A und 6B sind Flussdiagramme, die die vorherigen Operationen darstellen. Zuerst wird ein SU-adressiertes Datenpaket mit einer IP-Adresse, die mit einer SU 102 verknüpft ist, empfangen, wie in Block 602 gezeigt. Dann wird das SU-adressierte Datenpaket von dem Router 532-Protokoll am Router-Anschluss 534 in ein Protokoll übersetzt, das von dem PFM 402 benutzt wird, wie in Block 604 gezeigt. Dann wird das SU-adressierte Datenpaket analysiert 606, um zu bestimmen, ob eine ARQ-Nachricht erforderlich ist. Falls die Nachricht verlustsensitiv ist, ist eine ARQ-Nachricht erforderlich, und falls die Nachricht verzögerungssensitiv ist, ist keine ARQ-Nachricht erforderlich. Als Nächstes wird die RP 104, die den SU 102 bedient, aus der Abbildungstabelle zwischen der IP-Adresse des SU-adressierten Datenpakets und der RP 104, die die SU bedient, identifiziert, wobei diese Abbildung in der ART 404 gespeichert ist. Dann kapselt und rahmt die PDCU 304 das SU-adressierte Datenpaket, um Datensegmente 226 zu erzeugen, wie in Block 614 gezeigt. Diese Datensegmente 226 werden dann an die RPs 104 weitergeleitet, die die SU 102 bedienen, wo sie an die SU 102 gesendet werden, wie in Blöcken 616 und 618 gezeigt.
7A–7D sind Diagramme, die die Registrierung bzw. Anmeldung, die Intra-RPCU 106-Umschaltung, die Inter-RPCU 106-Umschaltung (engl.: handoff) und die Abmeldung zeigen.
Wann immer eine SU 102 in die PISA 400 gelangt, wird eine Paketdaten-Diensteregistrierung bzw. Anmeldung ausgeführt. Dies erfolgt durch Senden einer Registrierungsnachricht an die RPCU 106 direkt nachdem ein physischer Kanal erhalten wurde. Die Registrierungsnachricht enthält die dauernde Identifikation SubID des SUs 102. Die RPCU 106 leitet diese an die AM 108 zur Benutzerauthentifizierung und Autorisierung weiter. Am Ende der Registrierung bzw. Anmeldung erhält die AM 108 die permanente IP-Adresse der SU 102, die während der Dienstebestellung aufgezeichnet wurde und gibt sie an das PFM 402 zurück. Danach wird die PDCU 304 eine LPTID von dem RP 104 zugeteilt bekommen, und das PFM 402 trägt dann die IP-Adresse in die RP-Identifikations- und LPTID-Abbildungstabelle in der ART 404 ein.
7A ist ein Diagramm, das die SU 102-Registrierung zeigt. Wann immer eine SU 102 in das Netzwerk 100 gelangt, führt es eine PPC-Registrierung aus. Dies wird erreicht durch Senden einer Registrierungsnachricht an die RPCU direkt nachdem es einen physischen Kanal erhalten hat. Zwei Hauptaufgaben der PPC-Registrierung sind die Authentifizierung und die Autorisierung und die LPTID-Zuordnung.
Zu Beginn der Registrierung sendet die SU 102 eine Registrierungsanforderungsnachricht (PACKET_REG_REQ; Registration Request Message) 702, die die SubID (unter der Annahme, dass keine Benutzeranonymität vorhanden ist), enthält, an die PDCU 304 in der RPCU 106, die die SubID an den AM 108 weiterleitet. AM 108 authentifiziert dann die SU 102, indem die SubID benutzt wird. Sobald die Authentifizierung erfolgreich ist, sucht der AM 108 die permanente IP-Adresse der SU 102, die während der Dienstebestellung aufgezeichnet wurde, und gibt sie zurück an die PDCU 304. Die PDCU 304 weist eine neue LPTID zu und sendet eine Registrierungsbestätigungsnachricht (PACKET_REG_ACK; Registration Acknowledgement Message) 704 mit dieser LPTID zurück an die SU 102. Von da an identifiziert die SU 102 an sie bestimmte Daten durch die LPTID, bis sie sich von dem Netzwerk 100 abmeldet oder sich in eine andere Zelle 112 bewegt.
Handoff- bzw. Umschalt- und Mobilitätsverwaltung
7B–7C sind Diagramme, die ein SU 102-Handoff (Umschalten) zeigen. In einem PACS-System 100 wird ein Handoff als Automatic Link Transfer bzw. automa tische Verbindungsübertragung (ALT) bezeichnet. Ein ALT findet statt, wenn die SU 102 die Grenzen der Funk-Zelle 112 überschreitet. Ein ALT beginnt, wenn eine SU 102 die Verschlechterung des aktuellen physischen Kanals erfasst und einen anderen physischen Kanal mit einer ausreichend hohen Qualität findet. Die SU 102 sendet dann eine ALT-Anforderungsnachricht 406 an die neue RP 104, die mit einer neuen PDCU 304B verknüpft ist (die PDCU 304, die mit der neuen Zelle 112 verknüpft ist).
Sobald die Anforderung akzeptiert ist, weist die neue PDCU 304 eine neue LPTID zu und die SU 102 erhält eine ALT-Ausführungsnachricht 408 zurück und eine neue LPTID für die neue Zelle 112.
Abhängig davon, ob die zwei Kanäle mit der gleichen RPCU 106 verknüpft sind oder nicht, kann ALT in zwei Kategorien aufgeteilt werden: Intea-RPCU-ALT, das in 7B gezeigt ist, wenn die SU 102 sich in eine benachbarte Zelle 112 in der gleichen RPCU 106 bewegt, und Inter-RPCU-ALT, das in 6D gezeigt ist, wenn die SU 102 sich in eine andere RPCU 106 bewegt. Die neue PDCU 304 bestimmt, ob es eine Intra-RPCU oder eine Inter-RPCU ist, indem das vollständige Anschluss-ID (alte RP) Feld in der PACKET_REG_REQ untersucht wird, das die RP 104 und die RPCU 106-Adressen enthält.
Im Intra-RPCU-Fall, der in 7B gezeigt ist, weist die neue PDCU 304 das PFM 420 an, den geeigneten Eintrag in der ART 404, das für das PFM 402 zugänglich ist, zu modifizieren, um anzuzeigen, dass die SU 102 eine neue LPTID zugewiesen bekommen hat. Das PFM 420 weist dann die alte PDCU 304A an, die zuvor vergebene LPTID freizugeben.
Im Inter-RPCU-Fall, der in 7C gezeigt ist, zeigt die neue AM 108B der neuen RPCU die alte AM 108A der Inter-RPCU ALT an. Die alte AM 108A weist dann die alte PFM 420A an, den IP-Eintrag zu löschen, und weist die alte PDCU 304A an, die in der vorhergehenden Zelle zugewiesene LPTID freizugeben.
7D ist ein Diagramm, das den SU 102 Abmeldungsvorgang zeigt. Nach einer Abmeldungsnachricht (PACKET_REG_REQ) 710, die von der SU 102 gesendet wird und von der PDCU 304 empfangen wird, wird eine Autorisierungsanforderung von der PDCU 304 an das AM 108 gesendet. Das AM 108 gibt eine IP-Adresse für die SU 102 an die PDCU 304 zurück. Die PDCU 304 gibt dann die LPTID frei und weist die PFM 402 an, die IP-Adresse zu löschen.
Wenn eine SU 102 ALT ausführt zusätzlich zu der physischen Kanalübertragungsprozedur und der ALT-Prozedur, wie zuvor beschrieben, muss das PPN 416 eine richtige Weiterleitung in das Backbone für nachfolgende IP-Datagramme, die für die SU 102 bestimmt sind, gewährleisten. Während des Intra-RPCU ALT, da die SU 102 bei der gleichen RPCU 106 und in dem gleichen IP-Teilnetz 418 bleibt, gibt es keine Auswirkung beim Weiterleiten im PPN 416. Innerhalb RPCU 106 aktualisiert das PFM 402 die ART 404 und ersetzt den entsprechenden Eintrag mit einem neuen, der die neue RP 104 Nummer und die LPTID enthält. Für ein Inter-RPCU ALT ist der Prozess jedoch komplizierter, da nicht nur die ART-Tabellen 404 sowohl in der alten als auch der neuen RPCU 106 aktualisiert werden müssen, sondern das Weiterleiten in PPN 416 muss ebenfalls verändert werden, so dass nachfolgende IP-Datagramme die neue RPCU 106 stattdessen erreichen werden. Dies wird erreicht durch Aufnahme von Mobile-IP in das PISA 400.
Mobile-IP ist ein Standard-Internet-Mechanismus, der die Auslieferung von IP-Datagrammen an einen mobilen Host ermöglicht, ohne den aktuellen Zugangspunkt in das Internet des mobilen Hosts zu berücksichtigen. Um Mobile-IP zu benutzen, wird ein Agent (HA) und ein Weiterleitungsagent (FA) in dem IP-Routing-Modul 532, das mit der RPCU 106 verknüpft ist, implementiert, und eine Mobile-IP Client Software wird auf dem mobilen PC betrieben. Vorzugsweise kann ein COTS IP Router 538, der eine Mobile-IP eingebaut hat, für das IP-Routing-Modul 532 ersetzt werden.
Die vorliegende Beschreibung umfasst auch einen Mechanismus zur Verbesserung der Sendeverbindungseffizienz, wenn Mobile-IP in PACS verwendet wird. Normalerweise verlässt sich die Mobile-IP Client Software auf „Agent Advertisement" – eine periodische Broadcast bzw. Rundsendenachricht von jedem FA – um den Wechsel des IP-Teilnetztes 418 durch Hand-Off zu erfassen.
8A zeigt Nachrichtenaustausch während der normalen Mobile-IP-Registrierung. Der Einsatz der gleichen Mechanismen in PACS hat zwei Probleme. Erstens vergeuden Advertisement-Nachrichten wertvolle Sendeverbindungs-Bandbreite, wenn es keine Hand-Off oder Registrierungsaktivitäten gibt. Zweitens zwingt es die SU 102 dazu, zu warten, bis die nächste Advertisement-Nachricht ankommt, was zu unnötig langen Registrierungszeiten oder Hand-Off-Latenz führt. Um dies zu überwinden und um gleichzeitig den Mobile-IP-Standard einzuhalten, umfasst die PISA 400 einen Mobile-IP Assist Agent (MIAA) 512 in der RPCU 106.
8B zeigt eine Nachricht, die während der Mobile_IP-Registrierung in der PISA 400 ausgetauscht wurde. Nachdem die RPCU 106 das Inter-RPCU ALT oder einen frischen Registrierungsvorgang beendet hat, sendet der MIAA 512 sofort eine Agent Advertisement Nachricht an die neue SU 102 (On-Demand Advertisement; Advertisement auf Anforderung). Die PDCU 304 kann diese Nachricht Huckepack in der Registrierungsantwortnachricht (PACKET_REG_ACK) mitnehmen. Dieses „Huckepack" („Piggyback") ist eine Erweiterung zu dem PACS-Standard, bei dem nur die PACKET_REG_REQ-Nachrichten-Netzwerkschicht Pakete Huckepack nehmen können.
Das Ergebnis ist eine Einsparung von einem Umlauf zwischen SU 102 und RPCU 106. Da ferner jede Mobile-IP Hand-Off-Aktivität im PACS einer PACS-Registrierung oder einem Inter-RPCU ALT vorausgeht, wird die periodische Agent Advertisement unnötig. Somit kann die periodische Mobile-IP Agent Advertisement an jedem FA sicher abgeschaltet werden.
Multicasting
Zugangsnetzwerke müssen ebenfalls eine Kommunikation von einem Teilnehmer zu vielen oder von vielen zu vielen Gruppen unterstützen, was als Multicasting bekannt ist. Beim IP-Multicast besitzt jede Gruppe eine global eindeutige Internet-Adresse, die als IP-Multicast-Adresse bezeichnet wird, und um alle Gruppenmitglieder zu erreichen, werden Multicast-Datagramme zu der IP-Multicast-Adresse anstelle zu der einzelnen Host-Adresse gesendet.
Ein herkömmliches teilnetzweites Gruppierungs-/Adressierungsschema auf Verbindungsebene ist nicht auf eine PACS-Architektur anwendbar, da Multicast oder Broadcast auf jede Zelle alleine begrenzt ist (was ein Bewegen des SU 102 zwischen Zellen nicht erlauben würde), und da die PACS-Architektur einen sehr begrenzten Bereich von Adressen auf Verbindungsebene besitzt.
Um dieses Problem zu überwinden, definiert die vorliegende Beschreibung ein zellenweites Gruppierungs-/Adressierungsschema, bei dem jede Zelle 112 ihre eigenen Gruppen und Adressen unabhängig von anderen Zelle 112 verwaltet. Die Abbildung globaler Multicast-Adressen auf lokale Gruppenadressen wird ausgeführt durch eine dynamische Abbildung der globalen Multicast-Adresse auf einen Vektor von Gruppenadressen, deren jede einer Zelle in dem IP-Teilnetz 418 entspricht. Dies implementiert eine selektive Multicast-Fähigkeit, bei der die RPCU 106 Pakete nur an Zellen weiterleitet, die Mitglieder haben, und nicht an alle Zelle 112 ohne Unterscheidung. Dies gibt jedem PACS-Benutzer die Fähigkeit, sich einer Multicast-Gruppe im Internet anzuschließen und Multicast-Verkehr von irgendeiner Quelle zu empfangen.
IP-Multicast-Unterstützung in der PISA 400 umfasst das Multicast-Routing in dem PPN 416 und das lokale Multicast-Weiterleiten innerhalb jedes RPCU-Teilnetzes 418. Multicast-Routing in PPN 416 wird effizient erreicht durch Anpassen der Multicast-Routing-Protokolle, die im Internet/MBone benutzt werden. MBone ist eine Sammlung von Seiten im Internet, die das IP-Multicast-Protokoll unterstützen und live Audio- und Video-Telekonferenz u.Ä. erlauben. Lokales Multicast-Weiterleiten erfordert zusätzliche Funktionen im RPCU 106, wie nachfolgend beschrieben wird.
Ein grundlegendes Erfordernis für PACS-Multicast ist ein Multicast-Adressschema auf Verbindungsebene (Link-Level). Das herkömmliche teilnetzweite Verbindungsschicht-Adressierungsschema (bspw. Ethernet) ist nicht in PACS anwendbar, da PACS einen limitierten Verbindungsschicht-Adressraum (LPTID) im Vergleich zu den Klasse D IP-Adressen besitzt, und weil ein PACS-Teilnetz 418 in viele Zellen 112 partitioniert ist, wobei jede LPTIDs unabhängig verwaltet. Wenn Multicast-Pakete ein RPCU 106 erreichen, dass Gruppenmitglieder bedient, muss ein PACS-spezifischer Multicast-Mechanismus diese nur an die Mitglieder liefern, die an der Multicast-Gruppe Interesse haben. Dies erfordert, dass die lokalen mobilen Hosts in der Lage sind, zellweit Multicast-Gruppen sich anzuschließen und zu empfangen, indem zellweite Gruppenadressen verwendet werden, die den zellweiten Gruppen zugeordnet sind.
Die PISA 400 erfüllt diese Erfordernisse mit einem zellweiten Schema, bei dem jede Zelle zellspezifische Gruppen unabhängig verwaltet. Die Verbindungs-Schichtadresse (LPTID) für eine IP-Multicast-Gruppe ist eine PACS „Gruppen"-Adresse mit Bezug auf jede Zelle 112 des Teilnetzes 418. Ferner muss Multicast im PACS selektiv sein in dem Sinne, dass RPCU 106 nur eine Kopie an jede Zelle weiterleitet, die Mitglieder hat, und nicht ziellos an alle Zellen.
Unterschiedliche Verfahren können in jeder Zelle 112 eingesetzt werden, um Multicast über die Sendeschnittstelle zu verteilen. Ein Lösungsweg besteht in einem „Multicast-Unicast"-Weg, bei dem Pakete dupliziert werden und als getrennte Nachrichten zu jeder einzelnen SU 102 geliefert werden, die Mitglied der Gruppe ist. Ein anderer Lösungsweg ist ein „PACS Broadcast", bei dem Multicast-Daten in den Broadcast-Schlitzen (mit LPTID) an jede SU 102 in den Zellen getragen wird, und jede SU 102 muss diese verarbeiten und Pakete aus uninteressanten Gruppen herausfiltern. Unglücklicherweise ist, obgleich der Multi-Unicast-Lösungsweg ein einfacher Lösungsweg ist, der typischerweise der am wenigsten effiziente, da Multicast zu mehreren Unicasts wird. Dies negiert den Vorteil von Multicast und verschwendet wertvolle Sendeverbindungsressourcen. Der Broadcast-Lösungsweg verschwendet Central Processing Unit (CPU) und Batterieleistung der SUs 102, die nicht Mitglieder der jeweiligen Gruppe sind. Da der Leistungsverbrauch der SU 102 von großer Wichtigkeit ist, ist diese Alternative nicht attraktiv.
Um sich dem Bedürfnis nach Multicast-Kommunikation ohne die zuvor beschriebenen Nachteile zu widmen, verwendet die vorliegende Beschreibung ein erweitertes PPC (PACS Packet Channel) verwendet, um eine Multicast-Fähigkeit bei der Sendeverbindungsschlitzbelegung zu erlauben. Normalerweise wird jeder Abwärtsverbindungsschlitz (mit Ausnahme für Steuerungsnachrichten) mit einer LPTID verknüpft, die die eindeutige Ziel SU 102 spezifiziert. Die PISA 400 modifiziert die PPC, so dass bestimmte Sendeverbindungsschlitze für eine Multicast-Gruppe markiert werden können und verbessert die SU 102 durch die Fähigkeit, nicht nur diese Schlitze zu empfangen, die der SU 102 zugeordnet sind, sondern auch andere Schlitze, die für bestimmte Gruppen markiert sind. Auf diese Weise können alle Mitglieder der Gruppe und nur das Mitglied die Verarbeitung der Schlitze abtasten und Multicast-Daten empfangen, ohne die Notwendigkeit für eine Duplizierung oder für die Verwendung von Broadcast.
Um dies zu erreichen, erweitert die PISA 400 den Begriff des LPTID, um PACS zellweite Multicast-Gruppen zu umfassen. Dieses Adressierungsschema verwendet einen lokalen Multicast-Identifizierer, wie bspw. eine „Multicast" LPTID (m-LPTID), falls er einer PACS-Multicast-Gruppe anstelle einer bestimmten SU 102 zugeordnet ist. Wenn RPCU 106 ein Multicast-Datagramm sendet, benutzt es das entsprechende m-LPTID in der Abwärtsverbindung. SU 102 kann dessen Empfangs-Interface (oder PLF 504) auf eine Liste von LPTIDs setzen ... die eindeutige LPTID, die zugewiesen wird, wenn SU eine Zelle betritt und sich anmeldet und optional eine oder mehrere m-LPTIDs. Die m-LPTID-Belegung ist dynamisch, da das m-LPTID den gleichen Adressraum mit der normalen oder Unicast-LPTIDs teilt. Die Belegung ist unterschiedlich gegenüber (Unicast) LPTID in zweierlei Hinsicht. Erstens wird ein m-LPTID von vielen SUs 102 in der gleichen Gruppe geteilt, so dass es nur belegt wird, wenn das erste Gruppenmitglied in einer Zelle die Aufnahme in die Gruppe anfordert. Nachfolgende Anforderungen von SUs 102 werden mit der gleichen m-LPTID verknüpft. In ähnlicher Weise wird eine m-LPTID nur freigegeben, wenn alle Mitglieder die Gruppe in dieser Zelle 112 verlassen. Zweitens kann eine m-LPTID für mehr als eine Multicast-Gruppe gleichzeitig wiederverwendet werden. Dies deshalb, weil die Anzahl verfügbarer m-LPTIDs allgemein viel kleiner ist als die möglichen IP-Multicast-Adressen. Jede Zelle kann mindestens 238 LPTIDs sowohl für Unicast als auch Multicast besitzen, aber der Klasse D IP-Multicast-Adressraum enthält zusammen 2²⁸ Adressen. Während es unwahrscheinlich ist, mehr als zwei Dutzend aktive PACS-Nutzer in einer PACS-Mikrozelle zu haben, kann jeder Benutzer so vielen Multicast-Gruppen wie gewünschte, beitreten. Dies zwingt die PPC dazu, mit mehr als 238 unterschiedlichen Multicast-Gruppen in jeder Zelle fertig zu werden. Unter diesen Umständen kann es sein, dass m-LPTIDs wiederverwendet werden müssen und mehrere Multicast-Adressen auf eine m-LPTID abgebildet werden. Falls dies der Fall ist, wird die SU 102 das Datagramm rekonstruieren, das über diese m-LPTID empfangen wurde und wird das Datagramm unberücksichtigt lassen bzw. streichen, falls es nicht länger einer Gruppe angehört, an der SU 102 Teilnehmer ist.
Das Abbilden einer IP-Multicast-Adresse auf eine oder mehrere PACS zellweiten Gruppenadressen, eine pro Zelle, wird in einer Multicast-Adress-Abbildungstabelle (MAMT) 514 eines PFM 402 gespeichert, wobei auf die Tabelle zugegriffen wird und die durch das PFM 402 verwaltet wird. Multicast-Einträge können alternativ zusammen mit Unicast-Adress-Abbildungsinformation in der ART 404 gespeichert werden. Ein MAMT 514 Eintrag enthält nun eine Liste von globalen Multicast-Adressen G, RP Zellnummern, m-LPTID, M_List). Jeder Multicast-Eintrag bedeutet, dass die IP-Multicast-Adresse G eine entsprechende PACS-Gruppe mit der m-LPTID aufweist, die dieser in der Zelle 112 zugewiesen ist. M_List enthält die Netzwerkschichtadressen (wie bspw. die IP-Adressen) aller Mitglieder dieser Gruppe. Das Vorhandensein eines Eintrags mit der Zellnummer I mit m-LPTID = A und einer globalen Adresse G bedeutet, dass es zumindest eine SU 102 in einer Zelle I gibt, die teilnimmt an der globalen Multicast G und dass die zellweite Gruppenadresse für G A ist.
Wenn ein Multicast-Paket mit der Adresse G von PFM 402 von PPN 416 und dem IP-Router 410 empfangen wird, sucht das PFM 402 in der MAMT 514 nach Einträgen mit G. Dies liefert Zellidentifizierer für alle RPs 104, die Mitglieder haben, die an der Gruppe G teilnehmen, und die entsprechenden m-LPTIDs. Falls ein einzelner Eintrag gefunden wird, leitet das PFM 402 das Paket an die entsprechende Zelle 112 und das PDCU 304 mit der m-LPTID weiter, die aus dem Eintrag gefunden wird. Falls mehrere Einträge gefunden werden (die anzeigen, dass es mehr als eine Zelle mit Mitgliedern G gibt) repliziert PFM 402 das empfangene Paket und leitet eine Kopie an jede Zelle 122 über das PDCU 304 weiter, das mit der Zelle 122 verknüpft ist, die aus der Abbildung in der MAMT 514 gefunden wird. Falls kein Eintrag gefunden wird, lässt PFM 402 einfach dieses Paket fallen. Diese Weiterleitungsprozedur wird angewendet sowohl wenn das Paket von dem Netzwerk Backbone (ein SU-adressiertes Paket) kommt als auch wenn das Paket von einer SU (SU-abstammendes Paket) kommt. Wenn eine SU 102 ein Multicast SU-abstammendes Paket sendet, empfängt es RP 104 und leitet das Paket über PDCU 304 an PFM 402 weiter. PFM 402 dupliziert dann das Paket, falls notwendig, und leitet es entsprechend der MAMT 514 an alle Zellen 112 weiter, die Mitglieder haben, einschließlich der Zelle 112, aus der das Paket stammt.
9A und 9B sind Diagramme, die die Multicast-Registrierungs- bzw. Anmeldungsprozedur zeigen. Hier wird der PACS-Standard mit einem neuen Typ von PACS-Registrierungsnachricht (PACKET_REG_REQ) geändert, die „Multicast-Registrierung" genannt wird. Wenn ein mobiler PC sich an eine IP-Multicast-Gruppe G anschließen will, entweder zum ersten Mal oder auf Grund einer ALT-Operation, überprüft zunächst die SU die SU MAMT 516, um sicherzustellen, dass kein Eintrag mit der IP-Multicast-Gruppe G existiert. Falls keine existiert, erzeugt die SU 102 eine Registrierungs-Anforderungsnachricht (PACKET_REG_REQ) und sendet diese, die die angeforderte IP-Multicast-Adresse G und einen Terminalidentifizierer für SU 102 enthält.
Die PDCU 304 arbeitet dann mit dem AM 108 zusammen, um die Anforderung zu authentifizieren und den Multicast-Dienst zu autorisieren. Sobald authentifiziert, antwortet das AM 108 mit einer Antwort, die eine Teilnehmereinheit-Internetprotokoll(IP)-Adresse hat. Die PDCU 304 frägt dann an bei einem Gruppen verifizierungsmodul 522 in dem PFM 402 nach G, um zu bestimmen, ob die angeforderte Gruppe G in der Zelle 112 der SU 102 bereits existiert. Dies deshalb, weil die angeforderte Gruppe G eine neue Gruppe in der Zelle sein kann oder die angeforderte Gruppe G bereits ein anderes Mitglied enthält und unterschiedliche Registrierungsoperationen in jedem dieser Fälle erforderlich sind.
Falls die angeforderte Gruppe nicht existiert, wird eine neue m-LPTID von dem PDCU 304 Belegungsmodul 520 belegt. Dann wird die neue m-LPTID an das PFM 402 gesendet, wo es der neuen Multicast-Gruppe durch das Zuweisungsmodul 524 zugewiesen wird und auf die IP-Multicast-Adresse G durch das Belegungsmodul 520 abgebildet wird. Ein entsprechender Eintrag der vorhergehenden Information wird dann in der MAMT 514 gespeichert. Wie hier beschrieben, ist eine begrenzte Anzahl von LPTIDs zur Auswahl in jeder Zelle 112 verfügbar. Die zugewiesene m-LPTID kann von einer Gruppe von LPTIDs ausgewählt werden, die für Multicast-Verwendung reserviert sind. Alternativ kann die m-LPTID aus den verfügbaren LPTIDs auf einer First-come-first-serve(wer zuerst kommt, wird zuerst bedient)-Basis ausgewählt werden. LPTIDs können ebenfalls wiederverwendet werden (zwischen Gruppen geteilt werden), aber dies erfordert, dass die SUs 102 unerwünschte Nachrichten ausfiltern.
Falls die angeforderte Gruppe momentan existiert, hat G bereits eine m-LPTID zugewiesen und der entsprechende Eintrag existiert. In diesem Fall sucht das PFM 402 die m-PTID aus der ART 404 und fügt die IP-Adresse der SU 102 der ART 404 hinzu. In beiden Fällen gibt die RPCU 106 die m-LPTID-Nummer an die SU 102 in einer (PACKET_REG_ACK) Nachricht zurück.
Wie zuvor beschrieben, wenn eine SU 102 Mitglied einer Multicast-Gruppe wird, wird ihr die m-LPTID für die Gruppe zugewiesen, an der sie Interesse hat. Nachdem sie die m-LPTID für die Gruppe empfangen hat, muss sie die m-LPTID einer SU Multicast-Adressabbildungstabelle (MAMT) 516 in der SU 102 hinzufügen. Die SU MAMT 516 muss nicht ein Duplikat von MAMT 514 in der RPCU 106 sein, da die SU 102 nur die Gruppen überwachen muss, der sie beitritt.
PACS Multicast-Handoff- bzw. -Umschaltung umfasst zwei Prozesse während ALT. Zuerst, nachdem eine SU 102 ALT ausführt, muss sie wieder in all den IP-Multicast-Gruppen Mitglied werden, denen sie in der vorhergehenden Zelle beigetreten ist, da die PACS Multicast zellspezifisch ist. Zweitens, falls es Inter-RPCU ALT ist, aktualisiert die alte RPCU 106 deren MAMT 514, indem dieser Benutzer aus allen Gruppen entfernt wird, denen er beigetreten ist.
Um die Benutzung der Sendeverbindungsbandbreite effizient zu nutzen, wird eine explizite Multicast-Abmeldung angepasst. Da der aktuelle PACS-Standard nur einen einzelnen Typ von Abmeldung definiert, wird ein neuer Typ von Abmeldung für Multicst erzeugt: „Multicast-Abmeldung". Ein PACS-Nutzer führt die Multicast-Abmeldung nur aus, falls er eine Multicast-Gruppe verlässt, der er in der gleichen Zelle beigetreten ist (das heißt, nicht als Ergebnis von ALT), aber er ist weiterhin mit dem Netzwerk verbunden. Falls dieser Benutzer das Netzwerk dauerhaft verlässt, führt die SU 102 die normale Abmeldung aus, während der RPCU 106 die SU 102 aus allen Gruppen in der MAMT 514 entfernt.
Wenn der mobile PC anfordert, eine IP-Multicast-Gruppe zu verlassen, sendet SU 102 eine Multicast-Abmeldungsnachricht, um RPCU 106 zu informieren. Die Multicast-Abmeldungsnachricht umfasst die IP-Adresse von SU 102, die Gruppenadresse und m-LPTID, die auf diese Gruppenadresse abgebildet ist. Während der Multicast-Abmeldung überprüft RPCU 106, um zu sehen, ob SU 102 das einzige Mitglied der Multicast-Gruppe ist. Dies wird erreicht, indem PFM 402 die MAMT 514 nach der entsprechenden m-LPTID und der Gruppenadressen G durchsucht. In dem Fall gibt RPCU 106 die m-LPTID frei und entfernt das entsprechende Tuple aus dem entsprechenden Eintrag in der MAMT 514. Anderenfalls entfernt das PFM 402 nur die IP-Adresse für die SU 102 aus der MAMT 514.
Die SU 102 muss keine Abmeldung ausführen, wenn sie sich in eine andere Zelle 112 bewegt. Da die Anzahl von m-LPTIDs begrenzt ist, ergibt sich dadurch das Problem, die SU 102 als Gruppenbenutzer in der vorhergehenden Zelle 112 zu entfernen, falls sie Mitglied einer Multicast-Gruppe war. Dies wird gehandhabt, indem ein PACS-Mechanismus verwendet wird, der SU 102-Inaktivität erfasst. Wenn eine SU 102 keine Nachricht während einer spezifischen Zeitperiode (ein maximaler Inaktivitätsintervallparameter) an ein RP 104 sendet, der eine Zelle 112 bedient, erzeugt die SU 102 ein Paket mit keinen Daten (PACKET_NULL) und sendet dieses. Dies kann intern von der SU 102 implementiert werden oder durch einen Befehl, der von der RP 104 gesendet wird. Falls keine Daten von der SU 102 ankommen während dem maximalen Inaktivitätsintervall wird angenommen, dass die SU 102 offline gegangen ist oder ein ALT ausgeführt hat. In diesem Fall weist ein Handoff-Modul in der RPCU 106 die PFM 402 an, den Benutzer aus dem entsprechenden Eintrag in der ART 404 (oder der MAMT 514) zu entfernen.
IP-Multicast benutzt ein Gruppenmitgliedsprotokoll (IGMP), um zu bestimmen, ob es ein Mitglied einer bestimmten Gruppe in dem Teilnetz 418 gibt. Internet-Router benutzen diese Information, um zu bestimmen, ob Verkehr für eine Multicast-Gruppe zu dem Teilnetz 418 geliefert werden soll oder nicht. In der PISA 400 sendet der IP-Router 410 eine periodische IGMP-Mitgliedschaftanfragenachricht an die Verbindung, die mit der RPCU 106 verbunden ist, und erwartet zumindest, dass ein Mitglied mit IGMP-Berichtnachrichten antwortet.
Normalerweise werden IGMP-Anfragenachrichten an alle Multicast-fähigen Hosts in dem Teilnetz 418 gesendet. Wenn ein Mitglied antwortet, werden die Antwortnachrichten ebenfalls per Multicast an die Gruppe gesendet, um Antworten von anderen Mitgliedern zu unterdrücken (da eine Antwort pro Gruppe ausreichend ist). Indem jedoch das gleiche Schema in der PISA 400 verwendet wird, würde dies zu einem unnötigen Overhead führen, da die RPCU 106 bereits die Multicast-Abbildungsinformation in ihrem MAMT 514 hält. Für jede Multicast-Adresse, die einen Eintrag in MAMT 514 hat, muss es zumindest ein Mitglied in diesem RPCU 106-Teilnetz 418 geben. Deshalb implementiert RPCU 106 ein IGMP-Unterstützungsmodul (nicht gezeigt), um alle IGMP-Anfragen von dem IP-Router 410 zu unterbrechen, um mit IGMP-Berichten zu antworten, die vom MAMT 514 erzeugt werden. Dieses PISA 400-Gruppenmitgliedschaftsschema unterstützt nahtlos die IGMP-Version 2. Wenn eine neue Multicast-Gruppe der MAMT 514 hinzugefügt wird, sendet RPCU einen Mitgliedschaftsbericht an den IP-Router 410, und wenn eine Multicast-Gruppe aus der MAMT 514 entfernt wird, sendet RPCU 106 eine explizite Entfernungsnachricht.
Qualität der Dienste-Unterstützung
Die Qualität der Dienste(QoS/Quality of Service)-Unterstützung in drahtlosen Netzwerken ist wichtig, aber schwierig zu erreichen. Dies liegt hauptsächlich an der nicht vorhersehbaren Natur der Qualität drahtloser Verbindungen. Unterschiedliche Ebenen von Diensten können jedoch in PACS durch Verwendung unterschiedlicher Fragmentschemata, Paketterminierung (klassenbasierte Warteschlangen oder gewichtete Kosten-Warteschlangen) und ARQ erreicht werden. Das Ziel besteht darin, mehrere Ebenen von Diensten und Ausgewogenheit innerhalb jeder Diensteklasse zu unterstützen, indem mehrere Paketverwerfungs- und -verzögerungspräferenzen in der Abwärtsverbindung implementiert werden.
PPC-Funktionen honorieren das Type-of-Service(TOS)-Feld, das in jedem IP-Datagramm definiert ist. Das Feld definiert den Parametertyp, der zu optimieren ist, wenn dieses Datagramm ausgeliefert wird, wie bspw.: Minimierung der Verzögerung, Maximierung des Durchsatzes, oder Maximierung der Zuverlässigkeit. PDCU 304 überprüft jeden IP-Datagramm-Header nach diesem TOS-Feld. Basierend auf dem TOS-Wert, trifft PDCU die passenden Wahlen bei der IP-Weiterleitung.
Die erste Wahl ist die Abwärtsverbindungsfragmentierung. Während das Abwärtsverbindungs-DL-Paket in DL-Fragmente geteilt werden muss, gibt es verschiedene Strategien, die eingesetzt werden können, um dies zu erreichen. Der normale Fall ist der der „Minimumfragmentierung", bei dem die Fragmentierung immer ein Vielfaches von 576 Bytes (maximale Fragmentgröße) ist. Minimale Fragmentierung erzeugt eine minimale Anzahl von Fragmenten, so dass es zu einem maximalen Durchsatz führt, da der Overhead (Fragmentierungs-Header, etc.) geringer ist. Eine andere Strategie besteht in der „Maximumfragmentierung". Da jedes DL-Fragment in einem separaten Schlitz gesendet werden kann, kann ein DL-Paket in 8 kleinere Fragmente pro paralleler Auslieferung aufgeteilt werden. Die Fragmente sind kleiner, so dass das gesamte Paket früher ankommen kann und die Verzögerung minimiert wird.
10 und 11 sind Diagramme, die darstellen, wie unterschiedliche Fragmentierungsstrategien die Leistung beeinflussen. Die Daten werden über eine numerische Analyse unter idealen Bedingungen erhalten: Alle Schlitze sind von vorhergehenden Übertragungen befreit, kein Fehler tritt in der Funkverbindung auf, keine Neu- bzw. Wiederübertragung und keine Mediumzugangsverzögerung. Ein anderer PACS-Protokoll-Overhead wird ebenfalls ignoriert, wie bspw. Steuerungsnachrichten, Systeminformation, Bestätigungen, MAC sowie Überblock-Header.
10 zeigt die Funkverbindungsausbreitungsverzögerung einer Funktion einer IP-Paketgröße, die minimale Verzögerung darstellt. Im Maximumfragmentierungsfall werden die Pakete nahezu gleichmäßig unter 2, 4 oder 8 Schlitzen aufgeteilt (sind PACS-Fragmentierungsregeln unterworfen).
11 zeigt den normalisierten Durchsatz (die Größe des IP-Datagramms dividiert durch die gesamte Rohbandbreite), der zum Ausliefern des Pakets verwendet wird. Der Overhead ist Rahmungs- bzw. Blockbildungs-Overhead, der Fragment- und Segment-Headers, DL- und SL-Prüfsummen sowie Padding umfasst, um minimale Fragmentgröße zu erfüllen.
Diese Diagramme zeigen an, dass die Verzögerung signifikant reduziert werden kann mit weniger als 10/Rahmungs-Overhead-Anstieg. Deshalb ist es leicht, unterschiedliche Ebenen von Diensten zu erreichen, indem die Anzahl von Fragmenten für jeden Dienst manipuliert wird und diese über mehrere Schlitze parallel gesendet werden. Nichtsdestotrotz wird die aktuelle Verzögerung und der Paketverlust durch die Lastfluktuation beeinflusst werden, das heißt, einige Schlitze können mehr Segmente in der Warteschlange haben als andere. Deshalb muss der Fragmentie rungsalgorithmus die Warteschlangenlänge berücksichtigen, so dass die Warteschlangenverzögerung und der Paketverlust die End-zu-End-Qualität des Dienstes nicht beeinflusst.
Ein anderes Schema, das verwendet werden kann, um verschiedene Ebenen von Diensten über die Abwärtsverbindung zu erreichen, ist ARQ. Der PACS-Standard erlaubt, dass PDCU 304 selektiv ACK für jedes DL-Paket 218 freigibt oder sperrt. Für IP-Datagramme mit geringer Verwerfungspriorität setzt bspw. PDCU 304 das „ACK-erforderlich" Bit in dem DL-Paket-Header 220. Damit wird die SU 102 alle richtig empfangenen Segmente bestätigen und es PDCU 304 ermöglichen, fehlende oder fehlerhafte Segmente selektiv neu zu übertragen. Dieses Schema wird nachfolgend weiter beschrieben.
Der aktuelle PACS-Paketmodusdienst definiert zwei Automatic Repeat re-Qest(ARQ; automatische Wiederholungsanforderung)-Schemata für die Fehlerkorrektur auf PACS-Ebene. Eines dieser Schemata wird für die Aufwärtsverbindung verwendet (von SU 102 zu RP 104) und das andere für die Abwärtsverbindung (von RP 104 zu SU 102). Wie aktuell definiert, ist das Aufwärtsverbindungs-ARQ verpflichtend und das Abwärtsverbindungs-ARQ wird auf einer Paket-zu-Paket-Basis gewählt.
Die PISA 400 modifiziert diese Architektur auf zwei Arten. Erstens sind in der PISA 400 die Aufwärtsverbindungs-ARQs nicht verpflichtend, sondern werden auf einer Paket-zu-Paket-Basis gewählt. Zweitens wird das ARQ sowohl für die Aufwärtsverbindung als auch die Abwärtsverbindung für den verlustsensitiven Verkehr (wie Web-Verkehr) aktiviert und für verzögerungssensitiven Verkehr (wie Internet, Video und Audio) abgeschaltet. Dies verhindert, dass die Drahtlosbandbreite vergeudet wird, indem Pakete neu übertragen werden, die keine fehlerfreie Übertragung über eine PACS-Funkverbindung benötigen, was zu einer Erhöhung der effektiven Kapazität führt.
Entsprechend dem vorher Gesagten umfasst das PFM 402 ein Datennutzlastanalysemodul 526. Das Datennutzlastanalysemodul 526 bestimmt, ob die SU-adressierte Datennutzlast eine verlustsensitive Nachricht oder eine verzögerungssensitive Nachricht ist. Bei einer Ausführungsform wird dies erreicht, indem bestimmt wird, ob die SU-adressierte Datennutzlast einem Transfersteuerungsprotokoll (TCP) entspricht oder ob sie einem User-Datagrammprotokoll (UDP) entspricht.
Im Abwärtsverbindungsfall, wenn das PFM 402 die Ziel-IP-Adresse des Datenpakets überprüft, wird ebenfalls bestimmt, ob die Datennutzlast des Pakets TCP oder UDP entspricht, indem in den IP-Paket-Header geschaut wird. Im Falle von TCP und einem passenden Eintrag, der in ART 404 gefunden wird, benachrichtigt das PFM-PDCU-Interface-Modul 528 das entsprechende PDCU 304, um ein ACK-erforderlich-Bit in dem DL-Header 220 auf Eins (1) zu setzen, was anzeigt, dass ein ARQ von SU 102 angefordert wird. Falls das Datenpaket UDP entspricht, benachrichtigt das PFM-PDCU-Interface-Modul 528 die zugehörige PDCU 304, um das ACK-erforderlich-Bit in dem DL-Header 220 auf Null (0) zu setzen und damit anzuzeigen, dass ein ARQ nicht erforderlich ist.
Im Aufwärtsverbindungsfall setzt eine Sicherheitsschicht in den höheren Schichten 510 der SU 102 das ACK-erforderlich-Bit auf Null (0) oder Eins (1), abhängig davon, ob das Paket TCP oder UDP ist. Beim Empfang von Datenpaketen mit dem ACK-erforderlich-Bit von Null, sendet die PDCU 304 an RPCU 106 nicht den Übertragungsstatus des Pakets auf der Abwärtsverbindung rund (was ansonsten erforderlich wäre entsprechend dem aktuellen PACS-Standard).
Die vorhergehende Beschreibung der bevorzugten Ausführungsform der Erfindung wurde zum Zwecke der Darstellung und Beschreibung präsentiert. Es ist nicht daran gedacht, dass sie erschöpfend ist oder die Erfindung auf die genau offenbarte Form beschränkt. Viele Modifikationen und Variationen sind im Lichte der vorhergehenden Lehre möglich.
Bspw., obgleich sich die vorhergehende Beschreibung hauptsächlich auf ein TDMA-Multizellennetzwerk zu erläuternden Zwecken fokussiert hat, sind die Prinzipien der vorliegenden Erfindung ebenfalls auf Code Division Multiple Access (CDMA) und GSM (Global system for Mobile Communications)-Systeme anwendbar, sowie das zukünftige Mobile Wireless Netwok der dritten Generation.
Es ist beabsichtigt, dass der Umfang der Erfindung nicht durch diese detaillierte Beschreibung beschränkt ist, sondern vielmehr durch die angehängten Ansprüche. Die vorherige Spezifikation, die Beispiele und Daten liefern eine vollständige Beschreibung der Herstellung und der Benutzung des Zusammenwirkens der Erfindung. Da sich viele Ausführungsformen der Erfindung ergeben ohne den Rahmen der Erfindung zu verlassen, liegt die Erfindung in den nachfolgend angehängten Ansprüchen.

Claims

Radioportcontroller-Einheit (106) mit: einem Paket-Weiterleitungsmodul (402), das eine Zuordnungstabelle zwischen der Netzwerkschichtadresse und den Datenverbindungsschicht-Identifizierungszeichen für jede Teilnehmereinheit (SU, 102) aufrechterhält; und einem Router (538), der kommunizierend mit einem Internet-Host verbunden ist, um Nachrichten zu senden und zu empfangen, und der kommunizierend verbunden ist mit dem Paket-Weiterleitungsmodul (402), um von der SU-stammende Nachrichten anzunehmen und SU-adressierte Nachrichten an das Paket-Weiterleitungsmodul (402) in einem ersten Datenübertragungsprotokoll bereitzustellen; gekennzeichnet durch einen Stub (530), der zwischen einem Anschluss (534) des Router (538) und dem Paket-Weiterleitungsmodul (402) gekoppelt ist, um Nachrichten von dem ersten Datenübertragungsprotokoll in ein zweites Datenübertragungsprotokoll zu übersetzen und um Nachrichten von dem zweiten Datenübertragungsprotokoll in das erste Datenübertragungsprotokoll zu übersetzen.
Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass das erste Datenübertragungsprotokoll ein Ethernet-Protokoll ist.
Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass der Router (532) kommunizierend mit dem Paket-Weiterleitungsmodul (402) über ein lokales Netzwerk verbunden ist.
Vorrichtung nach Anspruch 3, dadurch gekennzeichnet, dass der Router (538) völlig getrennt von dem Paket-Weiterleitungsmodul (402) ist.
Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass der Router (538) einen Router-Anschluss (534) aufweist, um die gesendeten und empfangenen Nachrichten über den Router-Anschluss (534) zu kommunizieren, eine Paket-Datensteuerungseinheit (304) aufweist, die konfiguriert ist, um ein SU-adressiertes Datenpaket in Datensegmente für die Übertragung an die Teilnehmereinheit (102) einzukapseln und einzurahmen und um Datensegmente, die von der Teilnehmereinheit empfangen wurden, zu von der SU-stammende Pakete zusammenzusetzen; und das Paket-Weiterleitungsmodul (402) kommunizierend mit der Paket-Datensteuerungseinheit (304) und dem Router (538) verbunden ist, wobei das Paket-Weiterleitungsmodul konfiguriert ist, um die von der SU-stammenden Datenpakete von der Paket-Datensteuerungseinheit an den Router (538) weiterzuleiten, und um das SU-adressierte Datenpaket von dem Router (538) zu der Paket-Datensteuerungseinheit weiterzuleiten.
Vorrichtung nach Anspruch 5, dadurch gekennzeichnet, dass der Router (538) die gesendeten und empfangenen Nachrichten über den Router-Anschluss (534) entsprechend einem ersten Datenübertragungsprotokoll kommuniziert, und das Paket-Weiterleitungsmodul (402), das von der SU-stammende Datenpaket von der Paket-Datensteuerungseinheit (304) an den Router (538) weiterleitet und das SU-adressierte Datenpaket von dem Router zu der Paket-Datensteuerungseinheit entsprechend einem zweiten Datenübertragungsprotokoll weiterleitet.
Vorrichtung nach Anspruch 1, gekennzeichnet durch: Mittel zum Empfangen eines Datenpakets mit einer Daten-Nutzlast; Mittel zum Bestimmen, ob die Daten-Nutzlast eine verlustempfindliche Nachricht oder eine verzögerungsempfindliche Nachricht ist; Mittel zum Konfigurieren des Datenpakets, um anzuzeigen, dass eine Bestätigungsnachricht erforderlich ist, falls die Daten-Nutzlast eine verlustempfindliche Nachricht ist, und zum Konfigurieren des Datenpakets, um anzuzeigen, dass eine Bestätigungsnachricht nicht erforderlich ist, wenn die Daten-Nutzlast eine verzögerungsempfindliche Nachricht ist; und Mittel zum Übertragen des Datenpakets.
Vorrichtung nach Anspruch 7, dadurch gekennzeichnet, dass das Mittel zum Bestimmen, ob die Daten-Nutzlast eine verlustempfindliche Nachricht oder eine verzögerungsempfindliche Nachricht ist, ein Mittel zum Bestimmen umfasst, ob die Daten-Nutzlast einem Übertragungsprotokoll oder einem Nutzer-Datagrammprotokoll entspricht.
Verfahren zum Kommunizieren von Informationen von einem Internet-Host an eine Teilnehmereinheit (SU, 102), die von zumindest einem einer Vielzahl von Radioports (104) bedient wird, wobei das Verfahren die Schritte aufweist: Empfangen eines SU-adressierten Datenpakets mit einer IP-Adresse, die mit der Teilnehmereinheit (102) verknüpft ist, in einem Router (538), wobei das SU-adressierte Datenpaket in einem ersten Datenübertragungsprotokoll bereitgestellt wird; Liefern des SU-adressierten Datenpakets an einen Stub (530), der zwischen einem Router (538) Anschluss (534) und einem Paket-Weiterleitungsmodul (402) vorgesehen ist; Übersetzen in dem Stub (530) des SU-adressierten Datenpakets aus dem ersten Datenübertragungsprotokoll in ein zweites Datenübertragungsprotokoll; Liefern des übersetzten SU-adressierten Datenpakets an das Paket-Weiterleitungsmodul (402); Aufrechterhalten in dem Paket-Weiterleitungsmodul (402) einer Zuordnungstabelle zwischen der Netzwerkschichtadresse und den Datenverbindungsschicht-Identifizierungszeichen für jede Teilnehmereinheit; Identifizieren der Teilnehmereinheit (102) und des Radioports (104), der die SU bedient, aus der Abbildungstabelle zwischen der IP-Adresse des SU-adressierten Datenpakets, einem eindeutigen dynamisch zugewiesenen Radioport-Teilnehmereinheit-Identifizierungszeichen, und dem Radioport, der die Teilnehmereinheit bedient; Einkapseln und Rahmen des SU-adressierten Datenpakets, um Datensegmente zu erzeugen; Weiterleiten der Datensegmente an den Radioport (104), der die Teilnehmereinheit (102) bedient, und Übertragen der Datensegmente von dem Radioport (104) an die Teilnehmereinheit (102).
Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass das erste Datenübertragungsprotokoll ein Ethernet-Protokoll ist.
Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass das SU-adressierte Datenpaket eine SU-adressierte Daten-Nutzlast umfasst und das Verfahren ferner die Schritte aufweist: Bestimmen, ob die SU-adressierte Daten-Nutzlast eine verlustempfindliche Nachricht oder eine verzögerungsempfindliche Nachricht ist; Konfigurieren des eingekapselten und gerahmten SU-adressierten Datenpakets, um anzuzeigen, dass eine Bestätigung benötigt wird, wenn die SU-adressierte Daten-Nutzlast eine verlustempfindliche Nachricht ist, und Konfigurieren des eingekapselten und gerahmten SU-adressierten Datenpakets, um anzuzeigen, dass eine Bestätigungsnachricht nicht benötigt wird, wenn die SU-adressierte Daten-Nutzlast eine verzögerungsempfindliche Nachricht ist.
Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass der Schritt des Bestimmens, ob die SU-adressierte Daten-Nutzlast eine verlustempfindliche Nachricht oder eine verzögerungsempfindliche Nachricht ist, den Schritt aufweist: Bestimmen, ob die SU-adressierte Daten-Nutzlast einem Übertragungssteuerungsprotokoll (TCP) oder einem Benutzer-Datagrammprotokoll (UDP) entspricht.
Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass das SU-adressierte Datenpaket einen Paketkopf aufweist, und der Schritt des Bestimmens, ob die SU-adressierte Daten-Nutzlast dem Übertragungssteuerungsprotokoll oder dem Benutzer-Datagrammprotokoll entspricht, den Schritt des Überprüfens des Paketkopfs umfasst.
Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass das eingekapselte und gerahmte SU-adressierte Datenpaket einen Datenverbindungspaketkopf aufweist, und der Schritt des Konfigurierens des eingekapselten und gerahmten SU-adressierten Datenpakets, um anzuzeigen, dass eine Bestätigungsnachricht benötigt wird, wenn die SU-adressierte Daten-Nutzlast dem Übertragungssteuerungsprotokoll entspricht, und des Konfigurierens des eingekapselten und gerahmten SU-adressierten Datenpakets, um anzuzeigen, dass eine Bestätigungsnachricht nicht benötigt wird, wenn die Daten-Nutzlast dem Benutzer-Datagrammprotokoll entspricht, den Schritt aufweist: Setzen eines Bestätigungsbits in dem Datenverbindungspaketkopf.