DE60031678T2 - Selektives rahmen und entrahmen von ppp paketen in abhängigkeit der verhandelten optionen auf um und rm schnittstellen - Google Patents

Description

• HINTERGRUND DER ERFINDUNG
• I. Gebiet der Erfindung
• Die vorliegende Erfindung bezieht sich auf das Gebiet der drahtlosen Datendienste. Insbesondere bezieht sich die vorliegende Erfindung auf ein neues und verbessertes Verfahren und System für das Vorsehen von einer drahtlosen Datenkommunikationsprotokollverbindung zwischen einer Terminaleinrichtung (TE2) und einer Interworking-Funktion (IWF), durch eine drahtlose Kommunikationsvorrichtung (MT2).
• II. Beschreibung der verwandten Technik
• Internetworking, d.h. die Verbindung individueller LANs (LAN = local area network) ist sehr schnell sehr beliebt geworden. Die Infrastruktur und assoziierte Protokolle, die im Allgemeinen als das "Internet" bezeichnet werden, sind sehr bekannt geworden und sind weit verbreitet. Das Point-to-Point-Protokoll (PPP) ist eine gewöhnliche Art und Weise, sich mit dem Internet zu verbinden, wie im Stand der Technik wohl bekannt ist, und weiter beschrieben ist in Request for Comment (RFC) 1661, The Point-to-Point-Protocol (PPP), Network Working Group, vom Juli 1994. PPP sieht ein Standardverfahren für das Transportieren von Multi-Protokoll-Datagrammen über Point-to-Point-Verbindungen vor.
• Das PPP beinhaltet drei Hauptkomponenten:
• 1. ein Verfahren für das Einkapseln von Multi-Protokoll-Datagrammen;
• 2. ein Link-Control-Protokoll (LCP) für den Aufbau, die Konfiguration und das Prüfen einer Datenlinkverbindung; und
• 3. eine Familie von Network-Control-Protokollen (NCPs) bzw. Netzwerksteuerprotokollen für den Aufbau und die Konfiguration verschiedener Netzwerkschichtprotokolle.
• 1 stellt ein High-Level- bzw. abstrahiertes Blockdiagramm eines drahtlosen Kommunikationssystems dar, in dem ein Mobilterminal bzw. -endgerät (TE2-Vorrichtung) 102 mit einer IWF 108 über ein drahtloses Kommunikationssystem kommuniziert, welches eine drahtlose Kommunikationsvorrichtung (MT2) 104 und eine Basisstation/Mobilvermittlungsstelle (BS/MSC, MSC = Mobile Switching Center) 106 aufweist. In 1 dient die IWF 108 als ein Zugriffspunkt auf das Internet. Die IWF 108 ist gekoppelt an, und oft gemeinsam angeordnet mit der BS/MSC 106, was eine herkömmliche drahtlose Basisstation sein kann, wie im Stand der Technik bekannt. Die TE2-Vorrichtung 102 ist an die MT2-Vorrichtung 104 gekoppelt, welche in drahtloser Kommunikation mit der BS/MSC 106 und der IWF 108 steht.
• Es gibt viele Protokolle, die Datenkommunikation zwischen der TE2-Vorrichtung 102 und der IWF 108 gestatten. Beispielsweise definiert der Telecommunications Industry Association (TIA)/Electronics Industries Association (EIA) Interim Standard IS-707.5, betitelt "Data Service Options for Wideband Spread Spectrum Systems: Packet Data Services", veröffentlicht im Februar 1998, Anforderungen für die Unterstützung von Paketdatenübertragungsfähigkeit auf TIA/EIA-IS-95-Breitband-Spreizspektrumsystemen, von denen BS/MSC 106 und IWF 108 einen Teil sein können. IS-707.5 sieht auch die Anforderungen für Kommunikationsprotokolle auf den Verbindungen zwischen der TE2-Vorrichtung 102 und der MT2-Vorrichtung 104 vor (die R_m-Schnittstelle), zwischen der MT2-Vorrichtung 104 und der BS/MSC 106 (die U_m-Schnittstelle) und zwischen der BS/MSC 106 und der IWF 108 (die L-Schnittstelle) vor. IS-95 wird definiert in TIA/EIA IS-95, betitelt "Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System", veröffentlicht im Juli 1993.
• Nun mit Bezug auf 2 ist ein Diagramm der Protokollstapel in jeder Einheit des IS-707.5-Relay-Modells gezeigt. 2 entspricht im Groben der Figur 1.4.2.2-1 des IS-707.5. Im ganz linken Teil der Figur ist ein Protokollstapel, gezeigt im herkömmlichen vertikalen Format, der die Protokollstapel zeigt, die auf der TE2-Vorrichtung 102 (z.B. dem Mobilterminal, dem Laptop oder dem Palmtop-Computer) ablaufen. Der TE2-Protokollstapel ist als logisch mit dem Protokollstapel der MT2-Vorrichtung 104 über die R_m-Schnittstelle verbunden dargestellt. Die MT2-Vorrichtung 104 ist als logisch mit dem Protokollstapel der BS/MSC 106 über die U_m-Schnittstelle verbunden dargestellt. Der BS/MSC-106-Protokollstapel ist wiederum als logisch mit dem Protokollstapel der IWF 108 über die L-Schnittstelle verbunden dargestellt.
• Als ein Beispiel des Betriebs der Protokolle der 2 codiert das Point-to-Point-Protocol-Protokoll (PPP_R) 206 Pakete von den Protokollen der höheren Schichten 202, 204 und sendet bzw. überträgt sie über die R_m-Schnittstelle unter Verwendung des EIA-232-Protokolls 208 zu dem EIA-232-kompatiblen Port auf der MT2-Vorrichtung, auf der das EIA-232-Protokoll 210 abläuft. Das EIA-232-Protokoll 210 auf der MT2-Vorrichtung empfängt die Pakete und gibt sie weiter an das PPP_R-Protokoll 205. Das PPP_R-Protokoll 205 entfernt die Rahmen der in PPP-Rahmen gekapselten Pakete und leitet typischerweise, wenn die Datenverbindung aufgebaut ist, die Pakete zum PPP_U-Protokoll 215 weiter, welches die Pakete in PPP-Rahmen rahmt für die Sendung zu einem PPP-Peer-Protokoll (226), das sich in der IWF (108) befindet. Das Radio-Link-Protokoll (RLP) 212 und das IS-95-Protokoll 214, welche beide im Stand der Technik wohl bekannt sind, werden verwendet um die Pakete, welche in PPP-Rahmen eingekapselt sind, zu der BS/MSC 106 über die U_m-Schnittstelle zu übertragen. Das RLP-Protokoll 212 ist definiert in TIA/EIA IS-707-2, betitelt "Data Service Options for Wideband Spread Spectrum Systems: Radio Link Protocol", Februar 1998, und das IS-95-Protokoll ist definiert im oben erwähnten IS-95. Ein komplementäres RLP-Protokoll 216 und IS-95-Protokoll 218 in der BS/MSC 106 leiten die Pakete zu dem Relay-Layer-Protokoll 220 für die Übertragung über die L-Schnittstelle zum Relay-Layer-Protokoll 228 weiter. Das PPP_U-Protokoll 226 entfernt dann die Rahmen der empfangenen Pakete und leitet sie weiter zu den Netzwerkschichtprotokollen 225, die sie wiederum zu den Protokollen der höheren Schichten 221 weiterleiten.
• Das EIA-232-Protokoll ist im TIA/EIA-232-E-Standard definiert, betitelt "Interface Between Data Terminal Equipment and Data Circuit-Terminating Equip ment Employing Serial Binary Data Interchange", veröffentlicht im Oktober 1997.
• Die Relay-Schicht ist definiert in TIA/EIA IS-707.3, betitelt "Data Service Options for Wideband Spread Spectrum Systems: AT Command Processing and the R_m Interface", veröffentlicht im Februar 1998.
• Es sei bemerkt, das anstatt der Verwendung von EIA-232 bei 208 und 210, jedes andere physikalische Point-to-Point-Protokoll (z.B. USB) verwendet werden kann.
• Wie von der obigen Erklärung ersichtlich ist, werden, außer wenn ein Paket, das in der MT2-Vorrichtung empfangen worden ist an ein Protokoll der höheren Schichten, das in der MT2-Vorrichtung abläuft, weitergeleitet werden soll, von Paketen, die in PPP-Rahmen gekapselt sind, die PPP-Rahmen entfernt, nur um erneut in PPP-Rahmen gerahmt zu werden für die nachfolgende Übertragung zu einem PPP-Peer-Protokoll, sogar dann, wenn die Pakete keine weitere Verarbeitung in der MT2-Vorrichtung benötigen. Folglich werden Verarbeitungsressourcen und der Durchsatz negativ beeinflusst durch diese unnötige Rahmenentfernung und das erneute Rahmen von Paketen in PPP-Rahmen.
• Weiter wird aufmerksam gemacht auf das Dokument WO 96/21984, welches ein Paketfunksystem offenbart. Das Paketfunksystem kapselt Datenpakete von externen Datennetzwerken durch ein Point-to-Point-Protokoll PPP und leitet sie durch ein oder mehrere Unternetzwerke zu einem Punkt der das Protokoll der eingekapselten Datenpakete unterstützt. Zusätzlich wird ein besonderes Funkverbindungsprotokoll des Paketfunknetzwerks auf der Funkschnittstelle zwischen einer Mobildatenterminaleinrichtung und einem Supportknoten benötigt. PPP-Pakete werden in Datenpakete des erwähnten Funkverbindungsprotokolls eingekapselt. Der Nachteil der Anordnung ist, dass die Datenpakete von sowohl dem PPP-Protokoll als auch dem Funkverbindungsprotokoll protokollspezifische Steuerfelder enthalten, welche die Übertragungs kapazität der Anwenderinformation reduzieren. Daher wird ein PPP-Paket vor der Einkapselung komprimiert durch Entfernen der unnötigen Steuerfelder. Nachdem es über die Funkschnittstelle übermittelt worden ist, wird das PPP-Paket in sein ursprüngliches Format dekomprimiert.
• Gemäß der vorliegenden Erfindung werden ein Verfahren für das Senden und Empfangen von mindestens einem Rahmen unter Verwendung einer drahtlosen Kommunikationsvorrichtung, wie in Anspruch 1 beschrieben, und eine drahtlose Kommunikationsvorrichtung, wie in Anspruch 6 beschrieben, vorgesehen. Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung sind in den Unteransprüchen beschrieben.
• ZUSAMMENFASSUNG DER ERFINDUNG
• Die vorliegende Erfindung bestimmt, ob ausgewählte Verbindungsoptionen der PPP-LCP-Verbindungsoptionen auf der R_m-Schnittstelle identisch sind zu entsprechenden Verbindungsoptionen auf der U_m-Schnittstelle. Wenn die ausgewählten Verbindungsoptionen der PPP-LCP-Verbindungsoptionen auf den zwei Schnittstellen gleich sind, dann eliminiert die vorliegende Erfindung die unnötige Rahmenentfernung und erneute Rahmung von PPP-Rahmen in der MT2-Vorrichtung. Daher können PPP-Rahmen empfangen und gesendet werden von der MT2-Vorrichtung, ohne eine Rahmenentfernung der PPP-Rahmen, d.h. die PPP-Rahmen werden lediglich weitergeleitet durch die MT2-Vorrichtung. Als ein Ergebnis nimmt der Verarbeitungsbetrag, der von der MT2-Vorrichtung benötigt wird ab, wodurch zusätzliche Verarbeitungsfähigkeit für einen größeren Datendurchsatz vorgesehen wird.
• Wenn die vorliegende Erfindung bestimmt, dass die ausgewählten Verbindungsparameter der PPP-Verbindungsparameter auf den zwei Schnittstellen nicht gleich sind, dann werden die PPP-Rahmen entfernt und erneut gerahmt wie in Systemen des Standes der Technik. Daher werden, wenn die vorliegende Erfindung bestimmt, dass die ausgewählten der PPP- Verbindungsparameter nicht gleich sind, die PPP-Rahmen entfernt und neu gerahmt durch die MT2-Vorrichtung, wie oben beschrieben.
• KURZE BESCHREIBUNG DER ZEICHNUNGEN
• Diese und andere Vorteile werden offensichtlicher aus der detaillierten Beschreibung des bevorzugten Ausführungsbeispiels zusammen mit den folgenden Zeichnungen:
• 1 stellt ein High-Level-Blockdiagramm eines drahtlosen Datenkommunikationssystems dar, in dem sich eine Terminalvorrichtung mit einem Netzwerk, wie beispielsweise dem Internet, über eine drahtlose Kommunikationsvorrichtung verbindet;
• 2 ist ein Diagramm des Protokollstapels jeder Einheit in dem System.
• 3 ist ein Flussdiagramm, das die Verarbeitung zeigt, die auftritt für die Überwachung der PPP-R_m-Schnittstelle und für das Speichern der ausgehandelten Konfigurationsoptionen.
• 4 ist ein Flussdiagramm, das die Verarbeitung zeigt, die auftritt für die Überwachung der PPP-U_m-Schnittstelle und das Speichern der ausgehandelten Konfigurationsoptionen.
• 5 ist ein Flussdiagramm, das einen Prozess zur Bestimmung, ob die MT2-Vorrichtung in einem vollen Netzwerkmodus oder einem Pseudonetzwerkmodus operieren soll, darstellt.
• 6 ist ein Flussdiagramm, das die Verarbeitung zur Bestimmung, ob ein Paket in einem PPP-Rahmen eine Rahmenentfernung benötigt, anzeigt.
• DETAILLIERTE BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS
• Wie im Stand der Technik bekannt, müssen, um Kommunikationen über eine Point-to-Point-Verbindung aufzubauen, Link-Control-Protokoll-Pakete (LCP-Pakete) für den Aufbau, das Konfigurieren und das Prüfen der Datenlinkver bindung über jede PPP-Verbindung ausgetauscht werden, d.h. über R_m- und U_m-Schnittstellen. Alle nicht ausgehandelten Optionen verwenden einen vordefinierten Standardwert, wie spezifiziert durch RFC 1661.
• Wie beschrieben in RFC 1661 weisen die LCP-Pakete ein Configure-Request bzw. eine Konfigurationsanfrage, ein Configure-Ack bzw. eine Konfigurationsbestätigung, ein Configure-Nak bzw. eine Konfigurationsnichtbestätigung und ein Configure-Reject bzw. eine Konfigurationszurückweisung auf. Das Format dieser Pakete ist wohl bekannt und beschrieben in RFC 1661.
• Das Configure-Request-Paket wird verwendet, um die Konfigurationsoptionen auszuhandeln. Alle Konfigurationsoptionen werden immer gleichzeitig ausgehandelt.
• Das Configuration-Ack-Paket wird gesendet, wenn jede Konfigurationsoption in einem empfangenen Configuration-Request-Paket erkennbar ist und alle Werte akzeptabel sind.
• Das Configure-Nak-Paket wird als Antwort auf ein Configure-Request-Paket gesendet, wenn die angeforderten Konfigurationsoptionen erkennbar ist, aber einige ihrer Werte nicht akzeptabel sind. Das Optionen-Feld in dem Configure-Nak-Paket wird nur mit den nicht akzeptablen Konfigurationsoptionen des Configure-Request-Pakets gefüllt. Es sei bemerkt dass alle Konfigurationsoptionen immer gleichzeitig nicht-bestätigt bzw. nak'd werden.
• Das Configure-Reject-Paket wird gesendet, wenn ein empfangenes Configure-Request Konfigurationsoptionen beinhaltet, die nicht erkennbar sind oder nicht akzeptabel für die Aushandlung sind. Das Optionen-Feld des Configure-Reject enthält nur die nicht akzeptablen Konfigurationsoptionen des Configure-Request.
• Das Folgende beinhaltet die wohlbekannten Konfigurationsoptionen. Die ersten sechs Konfigurationsoptionen sind in RFC 1661 beschrieben und definiert für das PPP-LCP-Protokoll, während die siebte Konfigurationsoption im Request for Comment (RFC) 1662, „PPP in HDLC-like Framing", Network Working Group, vom Juli 1994 definiert ist:
• 1. Maximum-Receive-Unit bzw. Maximalempfangseinheit
• 2. Authentication-Protocol bzw. Authentifizierungsprotokoll
• 3. Quality-Protocol bzw. Qualitätsprotokoll
• 4. Magic-Number
• 5. Protocol-Field-Compression bzw. Protokollfeldkomprimierung
• 6. Address-and-Control-Field-Compression bzw. Adress- und Steuerfeldkomprimierung und
• 7. Async-Control-Character-Map bzw. Async-Steuerzeichenabbildung.
• Internet-Protocol-Control-Protokoll (IPCP) ist ein Netzwerksteuerprotokoll, das verantwortlich ist für die Konfiguration, das Aktivieren und das Deaktivieren der Internet-Protocol-(IP)-Module an beiden Enden der IP-Verbindung. Das IPCP ist beschrieben in Request for Comment (RFC) 1332, "The PPP Internet Protocol Control Protocol (IPCP)", G. McGregor, Network Working Group, Mai 1992. IPCP-Konfigurationsoptionen weisen auf:
• 1. IP-Adressen;
• 2. IP-Komprimierungsprotokoll; und
• 3. IP-Adresse.
• Das IPCP verwendet den gleichen Optionsaushandlungsmechanismus wie das Link-Control-Protokoll (LCP).
• Konfigurationsoptionsaushandlungen treten separat für sowohl die R_m-Schnittstelle als auch die U_m-Schnittstelle auf. Wie beschrieben in RFC 1661 enthält das Configuration-Ack-Paket eine Liste von Optionen, welche der Sender bestätigt. Die MT2-Vorrichtung überwacht empfangene und gesendete Configuration-Ack-Pakete über die R_m- und U_m-Schnittstellen und speichert den Wert jeder Option in einer Speichervorrichtung, wie beispielsweise einem Computerspeicher. Alle Konfigurationsoptionen haben Standardwerte, definiert durch RFC 1661, welche verwendet werden, wenn die entsprechende Konfigurationsoption nicht ausgehandelt wird.
• Wenn ausgewählte der Konfigurationsoptionen sowohl der R_m- als auch der U_m-Schnittstellen jeweils gleich sind, werden gewisse Rahmen der PPP-Rahmen, die von der MT2-Vorrichtung über eine der R_m- und U_m-Schnittstellen empfangen wurden, durch die MT2-Vorrichtung über die andere der R_m- und U_m-Schnittstellen gesendet, ohne die PPP-Rahmen zu entfernen durch eine der Schnittstellen PPP_R 205 und PPP_U 215 und ohne erneutes Rahmen der PPP-Rahmen durch die andere der Schnittstellen PPP_R 205 und PPP_U 215. Dies wird als ein "Pseudonetzwerkmodus" bezeichnet. Wenn alle Pakete eine Rahmenentfernung und ein erneutes Rahmen benötigen, wird dies als "voller Netzwerkmodus" bezeichnet.
• 3 zeigt ein Flussdiagramm des Prozesses der Überwachung und Speicherung der ausgehandelten LCP-Konfigurationsoptionen für die R_m-Schnittstelle. Der Prozess wird beispielsweise in Software oder Firmware ausgeführt, die auf einem Prozessor in der MT2-Vorrichtung abläuft.
• Im Schritt S300 werden die gespeicherten Konfigurationsoptionen für die R_m-Schnittstelle, welche in der Speichervorrichtung gespeichert sind, wie beispielsweise in in der MT2-Vorrichtung enthaltendem RAM, auf ihre Standartwerte initialisiert, wie definiert durch RFC 1661. Im Schritt S310 wird ein empfangener oder ein unmittelbar zu sendender Rahmen auf der R_m-Schnittstelle überprüft um zu bestimmen, ob der Rahmen ein LCP-Configuration-Ack-Paket enthält. Falls der Rahmen ein LCP-Configuration-Ack-Paket enthält, wird der Schritt S320 ausgeführt, um die Werte der ausgehandelten Optionen, die in dem Configuration-Ack-Paket enthalten sind, in dem Speicher zu speichern. Daher werden diejenigen Optionen, die erfolgreich ausgehandelt sind in dem Speicher gespeichert und jene Optionen, die nicht ausgehandelt sind haben Standardeinstellungen, die in der Speichervorrichtung gespeichert sind. Falls das empfangene oder das unmittelbar zu sendende Paket kein LCP- Configuration-Ack-Paket ist, ignoriert der Prozess das Paket und wartet auf den nächsten empfangenen oder unmittelbar zu sendenden PPP-Rahmen.
• 4 zeigt ein Flussdiagramm eines Prozesses der Überwachung und des Speicherns der ausgehandelten LCP-Konfigurationsoptionen auf der U_m-Schnittstelle. Der Prozess ist ähnlich zu dem in 3 gezeigten, aber stattdessen werden Pakete die empfangen worden sind oder die unmittelbar über die U_m-Schnittstelle zu senden sind überwacht.
• Im Schritt S400 werden die gespeicherten Konfigurationsoptionen für die U_m-Schnittstelle, die in der Speichervorrichtung, wie beispielsweise RAM der in dem MT2-Gerät enthalten ist, gespeichert sind, auf ihre Standardwerte initialisiert, wie definiert durch RFC 1661. Im Schritt S410 wird ein empfangener oder unmittelbar zu sendender Rahmen auf der U_m-Schnittstelle überprüft um zu bestimmen, ob der Rahmen ein LCP-Configuration-Ack-Paket enthält. Falls der Rahmen ein LCP-Configuration-Ack-Paket enthält, wird der Schritt S420 ausgeführt um die Werte der ausgehandelten Optionen, die in dem Configuration-Ack-Paket enthalten sind, in dem Speicher zu speichern. Somit werden diejenigen Optionen, die erfolgreich ausgehandelt worden sind in dem Speicher gespeichert und jene Optionen, die nicht ausgehandelt worden sind haben Standardeinstellungen, die in der Speichervorrichtung gespeichert sind. Falls der empfangene oder unmittelbar zu sendende Rahmen kein LCP-Configuration-Ack-Paket aufweist, ignoriert der Prozess das Paket und wartet auf den nächsten empfangenen oder unmittelbar zu sendenden PPP-Rahmen.
• 5 ist ein Flussdiagramm für eine Prozedur, welche auf einem Prozessor in der MT2-Vorrichtung ausgeführt wird. Der Schritt S500 bestimmt, ob ein Linkaufbau sowohl auf der U_m-Schnittstelle als auch auf der R_m-Schnittstelle vollständig ist. Dies kann bestimmt werden durch Untersuchung einer Link- bzw. Verbindungszustandsvariablen, die separat für die PPP_R-Verbindung bzw. -Link 205 und die PPP-Verbindung bzw. -Link 215 unterhalten wird. RFC 1661 erklärt die Verbindungszustände, die im Stand der Technik wohl bekannt sind, für die PPP-Verbindung. Der Schritt S500 bestimmt, ob die Verbin dungszustände sowohl der PPP_R-205- als auch der PPP_U-215-Verbindungen in dem Netzwerkzustand sind, was anzeigt, dass die PPP-Verbindungen aufgebaut sind. Falls der Schritt S500 bestimmt, dass beide PPP-Verbindungen aufgebaut sind, dann wird der Schritt S510 ausgeführt um zu bestimmen, ob entsprechende ausgewählte Optionen der LCP-Konfigurationsoptionen auf den R_m- und U_m-Schnittstellen gleich sind. In dem bevorzugten Ausführungsbeispiel weisen die ausgewählten Optionen Protocol-Field-Compression und Address-and-Control-Field-Compression auf. Der Schritt S510 kann jedoch angepasst werden, um jegliche andere Konfigurationsoptionen zu vergleichen. Wenn die entsprechenden ausgewählten Optionen der LCP-Konfigurationsoptionen gleich sind, wird der Schritt S520 ausgeführt um anzuzeigen, dass die MT2-Vorrichtung in einem Pseudonetzwerkmodus ist, anderenfalls wird der Schritt S530 ausgeführt um anzuzeigen, dass die MT2-Vorrichtung in einem vollen Netzwerkmodus ist.
• 6 stellt die Verarbeitung dar, die in der MT2-Vorrichtung ausgeführt wird, wenn PPP-Rahmen auf entweder den R_m- oder den U_m-Schnittstellen empfangen werden, während die PPP-Verbindung aufgebaut ist, d.h. in dem Netzwerkzustand.
• Im Schritt S600 wird eine Überprüfung durchgeführt um zu bestimmen, ob die MT2-Vorrichtung im Pseudonetzwerkmodus oder im vollen Netzwerkmodus operiert. Falls die MT2-Vorrichtung im Pseudonetzwerkmodus operiert, wird Schritt S610 durchgeführt um zu bestimmen, ob der empfangene PPP-Rahmen von entweder den R_m- oder den U_m-Schnittstellen ein LCP- oder ein IPCP-Paket beinhaltet. Wenn der empfangene PPP-Rahmen kein LCP- oder IPCP-Paket aufweist, dann wird Schritt S620 ausgeführt, um das Paket durch die MT2-Vorrichtung zu leiten ohne eine Rahmenentfernung und erneutes Rahmen des Pakets. Mit anderen Worten, wenn der empfangene PPP-Rahmen auf der R_m-Schnittstelle angekommen ist, verursacht Schritt S620, dass der PPP-Rahmen über die U_m-Schnittstelle gesendet wird, ohne Rahmenentfernung des PPP-Rahmens und erneutes Rahmen des PPP-Rahmens. Falls der empfangene PPP-Rahmen über die U_m-Schnittstelle angekommen ist, verursacht Schritt S620, dass der PPP-Rahmen über die R_m-Schnittstelle gesendet wird, ohne Rahmenentfernung und erneutes Rahmen des PPP-Rahmens.
• Falls Schritt S600 bestimmt, dass die MT2-Vorrichtung nicht im Pseudonetzwerkmodus operiert (d.h. die MT2-Vorrichtung operiert im vollen Netzwerkmodus), oder falls Schritt S610 bestimmt, dass der empfangene PPP-Rahmen entweder ein LCP-Paket oder ein IPCP-Paket beinhaltet, dann könnte eine Rahmenentfernung und ein erneutes Rahmens ausgeführt werden. Mit anderen Worten, wenn die MT2-Vorrichtung einen PPP-Rahmen auf der R_m-Schnittstelle empfängt und die MT2 im vollen Netzwerkmodus ist oder die MT2-Vorrichtung in einem Pseudonetzwerkmodus ist, aber entweder ein LCP-Paket oder ein IPCP-Paket in dem PPP-Rahmen enthalten ist, dann wird der Rahmen von dem PPP_R-Protokoll 205 verarbeitet, der den Rahmen des Pakets entfernen wird und das Paket kann schlussendlich zu dem PPP_U-Protokoll 215 weitergeleitet werden, wo es erneut in einen PPP-Rahmen gerahmt wird für die Sendung über die U_m-Schnittstelle. Auf ähnliche Weise wird, wenn die MT2-Vorrichtung einen PPP-Rahmen auf der U_m-Schnittstelle empfängt und die MT2 in einem vollen Netzwerkmodus ist oder die MT2-Vorrichtung in einem Pseudonetzwerkmodus ist, aber entweder ein LCP-Paket oder ein IPCP-Paket in dem PPP-Rahmen enthalten ist, der Rahmen dann von dem PPP-Protokoll 215 verarbeitet, welches den Rahmen des Pakets entfernen wird und das Paket kann schlussendlich zu dem PPP_R-Protokoll 205 geleitet werden, wo es erneut in einen PPP-Rahmen gerahmt wird für die Sendung über die R_m-Schnittstelle.
• Obwohl das bevorzugte Ausführungsbeispiel nur LCP- und IPCP-Pakete zeigt, deren Rahmen in einem Pseudonetzwerkmodus entfernt und die erneut gerahmt werden, kann die Erfindung angepasst werden, um zu bewirken, dass jede spezielle Art von Paket oder überhaupt kein Paket entrahmt bzw. deren Rahmen entfernt wird und erneut in PPP-Rahmen gerahmt werden bzw. wird, während sie sich im Pseudonetzwerkmodus befinden.

Claims (10)

1. Ein Verfahren zum Weiterreichen bzw. -leiten von ankommenden Rahmen, die für den Austausch zwischen einer ersten Vorrichtung und einer zweiten Vorrichtung bestimmt sind, wobei die erste Vorrichtung eine Terminalvorrichtung (102) ist und die zweite Vorrichtung eine Basisstation/Mobilvermittlungsstelle (106) ist, und zwar innerhalb einer drahtlosen Kommunikationsvorrichtung (104) konfiguriert gemäß einem vordefinierten Kommunikationsprotokoll, wobei das Verfahren Folgendes aufweist: Identifizieren von ersten entsprechenden Protokollkonfigurationsoptionen des vordefinierten Kommunikationsprotokolls, wie sie zwischen der ersten Vorrichtung und der drahtlosen Kommunikationsvorrichtung ausgehandelt wurden; Identifizieren von zweiten entsprechenden Protokollkonfigurationsoptionen, wie sie zwischen der drahtlosen Kommunikationsvorrichtung (104) und der zweiten Vorrichtung ausgehandelt wurden; Identifizieren, wann ausgewählte Optionen der ersten und zweiten identifizierten entsprechenden Protokollkonfigurationsoptionen gleich sind; Identifizieren, ob die ankommenden Rahmen ein Paket eines vorbestimmten Typs enthalten; und wenn ausgewählte Optionen der ersten und zweiten identifizierten entsprechenden Konfigurationsoptionen gleich sind und die ankommenden Rahmen ein Paket eines vorbestimmten Typs enthalten, weiterreichen, ansprechend hierauf, der ankommenden Rahmen zwischen den ersten und zweiten Vorrichtungen durch die drahtlose Kommunikationsvorrichtung (104), ohne eine Rahmenentfernung und erneute Rahmung der ankommenden Rahmen auszuführen.
2. Verfahren nach Anspruch 1, wobei das Kommunikationsprotokoll PPP ist.
3. Verfahren nach Anspruch 1, wobei die entsprechenden Protokollkonfigurationsoptionen, die dem entsprechenden Rahmen zugeordnet sind, Async-Control-Character-Map aufweisen.
4. Verfahren nach Anspruch 1, wobei die entsprechenden Protokollkonfigurationsoptionen, die den ankommenden Rahmen zugeordnet sind, Protokoll-Field-Compression aufweisen.
5. Verfahren nach Anspruch 1, wobei die entsprechenden Protokollkonfigurationsoptionen, die dem ankommenden Rahmen zugeordnet sind, Address-and-Control-Field-Compression aufweisen.
6. Eine drahtlose Kommunikationsvorrichtung (104) konfiguriert gemäß einem vordefinierten Kommunikationsprotokoll zum Weiterreichen von ankommenden Rahmen zwischen einer ersten Vorrichtung und einer zweiten Vorrichtung, wobei die erste Vorrichtung eine Terminalvorrichtung (102) und die zweite Vorrichtung eine Basisstation/Mobilvermittlungsstelle (106) ist, wobei die Vorrichtung Folgendes aufweist: Mittel zum Identifizieren von ersten entsprechenden Protokollkonfigurationsoptionen des vordefinierten Kommunikationsprotokolls wie sie zwischen der ersten Vorrichtung (102) und der drahtlosen Kommunikationsvorrichtung (104) ausgehandelt wurden; Mittel zum Identifizieren von zweiten entsprechenden Protokollkonfigurationsoptionen, wie sie zwischen der drahtlosen Kommunikationsvorrichtung (104) und der zweiten Vorrichtung (106) ausgehandelt wurden; Mittel zum Identifizieren, wann ausgewählte Optionen der ersten und zweiten identifizierten entsprechenden Protokollkonfigurationsoptionen gleich sind; Mittel zum Identifizieren, ob die ankommenden Rahmen ein Paket eines vorbestimmten Typs enthalten; und wenn die ausgewählten Optionen der ersten und zweiten identifizierten entsprechenden Konfigurationsoptionen gleich sind und die ankom menden Rahmen ein Paket eines vorbestimmten Typs enthalten, Mittel zum Weiterreichen, ansprechend hierauf, der ankommenden Rahmen zwischen den ersten und zweiten Vorrichtungen ohne eine Rahmenentfernung und ein erneutes Rahmen der ankommenden Rahmen auszuführen.
7. Drahtlose Kommunikationsvorrichtung (104) nach Anspruch 6, wobei das Kommunikationsprotokoll PPP ist.
8. Drahtloses Kommunikationsvorrichtung (104) nach Anspruch 6, wobei die entsprechenden Protokollkonfigurationsoptionen, die den ankommenden Rahmen zugeordnet sind, Async-Control-Character-Map beinhalten.
9. Drahtlose Kommunikationsvorrichtung (104) nach Anspruch 6, wobei die entsprechenden Protokollkonfigurationsoptionen, die den ankommenden Rahmen zugeordnet sind, Protocol-Field-Compression enthalten.
10. Drahtlose Kommunikationsvorrichtung (104) nach Anspruch 6, wobei die entsprechenden Protokollkonfigurationsoptionen, die den ankommenden Rahmen zugeordnet sind, Address-and-Control-Field-Compression enthalten.