-
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
-
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.
-
1 ist
eine Darstellung eines PACS (Personal Access Communication System,
persönliches
Zugangskommunikationssystem) 100. Ein PACS-Netzwerk ist
beispielsweise in dem Aufsatz "Managing
IP services over a PACS Packet Network" von Bo Ryu et al., IEEE Network, Vol.
12, Nr. 4, 1. Juli 1998, Seiten 4–10, XP002142781 offenbart.
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ärts verbindungs- 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 Segmentie rung 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 Authentifizierung
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 ein neues Verfahren und eine Funkanschluss-Steuerungseinheit
für ein
PACS-Netzwerk. Sie erweitert das PACS-Sprachnetzwerk mit IP-Routern
und Backbone-Verbindungen, um eine Verbindung zum Internet oder
einem Intranet zu schaffen. Ferner 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 vorliegende Erfindung offenbart auch 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.
-
Der
Benutzer und der mobile PC können
Roaming innerhalb des PACS-drahtlosen Netzwerks ausführen oder
können
sich zwischen PACS-Netzwerken und außerhalb dem Internet bewegen,
indem Mobile-IP verwendet wird. IP-Multicast und MBone-Anwendungen
werden ebenfalls nahtlos und effizient unterstützt, indem natives PACS-Multicast
verwendet wird.
-
Die
vorliegende Erfindung offenbart auch ein Verfahren und eine Vorrichtung,
um die Funktionalität
einer Vorrichtung zu erweitern, die Paketweiterleitungsmodul genannt
wird und in der RPCU implementiert ist, und deren betroffenen Elemente,
um eine effiziente Kommunikation von einem Ort zu vielen (Multicast)
unter den PACS-Benutzern innerhalb eines PACS-Funk-Netzwerks zu
erzielen. Ein Systementwurf und eine Architektur für eine SU,
die Multicast unterstützt,
ist ebenfalls offenbart. Die Mechanismen, die dem Paketweiterleitungsmodul
und der SU hinzugefügt
werden, liefern (1) eine dynamische Abbildung zwischen einer globalen Multicast-Adresse
und lokalen PACS-Gruppenadressen, (2) selektive Multicast zu Weiterleitungsmulticastpakete
nur für
Zellen, die zumindest ein Gruppenelement besitzen, und (3) eine
effiziente Gruppenmitgliedsverwaltung.
-
Die
Multicast-Erweiterung liefert verschiedene Vorteile gegenüber aktuellen
Systemen. Erstens liefert es nur eine einzelne Kopie eines Multicast-Pakets
an die PACS-Gruppenmitglieder. Zweitens überträgt es kein Multicast-Paket
an Zellen, die kein Gruppenmitglied haben, so dass Sendezeit gespart
wird. Da die Implementierung von PACS-Multicast exakt eine Kopie
von Daten pro Zelle nur an jene PACS-Nutzer liefert, die Mitglied der Gruppe
sind, ist die Benutzung der PACS-Bandbreite optimal und der Leistungsverbrauch
der PACS-Benutzer, die nicht Mitglied der Gruppe sind, wird nicht
verschwendet (da sie keine Multicast-Daten verarbeiten). Drittens
kann jedes Netzwerk Schicht-Multicast-Schema (wie das IP-Multicast
und das CDPD-Multicast) nahtlos unterstützt werden. Schließlich hält die Erweiterung
die Gruppenmitgliedschaft effizient und genau aufrecht.
-
Die
vorliegende Erfindung definiert ein Verfahren und eine Vorrichtung
zum Multicasting von Daten. Das Verfahren ist in Anspruch 1 definiert.
-
Die
Vorrichtung ist eine Funkanschluss-Steuerungseinheit (Radio Port
Controller Unit) wie in Anspruch 8 definiert.
-
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; (3) der Verwendung eines nativen PACS-Multicast, um
dynamische IP-Multicast und Multicast-Backbone(MBone)-Konnektivität effizient
zu unterstützen;
und (4) zu einer Optimierung und zur Eingliederung von Mobile-IP
in PACS-Leitungsumschaltmechanismen, um ein Roaming innerhalb eines
PACS-Netzwerks sowie einer globalen Mobilität zwischen PACS-Netzwerken
und dem Internet effizient zu unterstützen.
-
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-Nach richt 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. automatische 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: Intra-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 Erfindung 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, wird 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 228 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 fragt dann an bei einem Gruppenverifizierungsmodul 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 Diensteunterstü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 gewich tete 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 vor 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 Fragmentierungsalgorithmus 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 Network
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.
