DE60111823T2 - Verfahren zur vermeidung von ppp-zeitrüberschreitungen während ipcp-verhandlungen - Google Patents

Verfahren zur vermeidung von ppp-zeitrüberschreitungen während ipcp-verhandlungen Download PDF

Info

Publication number
DE60111823T2
DE60111823T2 DE60111823T DE60111823T DE60111823T2 DE 60111823 T2 DE60111823 T2 DE 60111823T2 DE 60111823 T DE60111823 T DE 60111823T DE 60111823 T DE60111823 T DE 60111823T DE 60111823 T2 DE60111823 T2 DE 60111823T2
Authority
DE
Germany
Prior art keywords
address
message
assigned
communication device
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60111823T
Other languages
English (en)
Other versions
DE60111823D1 (de
Inventor
Marcello Lioy
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Application granted granted Critical
Publication of DE60111823D1 publication Critical patent/DE60111823D1/de
Publication of DE60111823T2 publication Critical patent/DE60111823T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5084—Providing for device mobility
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Electrophonic Musical Instruments (AREA)

Description

  • Hintergrund der Erfindung
  • I. Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft im Allgemeinen das Gebiet drahtloser Kommunikationen. Insbesondere betrifft die vorliegende Erfindung ein neues Verfahren zum Vermeiden von Zeitüberschreitungen (time-outs), um IPCP-Adressverhandlungen zu unterstützen.
  • II. Beschreibung des verwandten Standes der Technik
  • Neuere Innovationen in der drahtlosen Kommunikation und in Computerbezogenen Technologien sowie die beispiellose Zunahme von Internet-Teilnehmern haben den Weg für den mobilen Einsatz von Computern gebahnt. Tatsächlich stellt die Popularität des mobilen Computereinsatzes höhere Anforderungen an die aktuelle Internet-Infrastruktur, um mobilen Benutzern mehr Unterstützung zur Verfügung zu stellen. Einen entscheidenden Anteil zum Erfüllen dieser Anforderungen und zum Verfügung stellen der erforderlichen Unterstützung für Benutzer hat die Verwendung einer CDMA(Code Division Multiple Access)-Technologie in drahtlosen Kommunikationssystemen.
  • CDMA ist eine digitale Hochfrequenz(HF)-Kanalisierungstechnik, die in „Telecommunications Industry Association/Electronics Industries Association Interim Standard-95 (TIA/EIA IS-95)" mit dem Titel „MOBILE STATION – BASE STATION COMPATIBILITY STANDARD FOR DUAL-MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEM", veröffentlicht im Juli 1993, definiert wird. Drahtlose Kommunikationssysteme, die diese Technologie einsetzen, weisen Kommunikationssignalen einen eindeutigen Code zu und verteilen bzw. spreizen die Kommunikationssignale über eine gemeinsame (Breitband-) Spreizspektrum-Bandbreite. Solange die empfan gende Vorrichtung in einem CDMA-System den korrekten Code hat, kann sie erfolgreich ihr Kommunikationssignal aus den anderen momentan über dieselbe Bandbreite übertragenen Signale erfassen und auswählen. Die Verwendung von CDMA erzeugt eine Zunahme einer Systemverkehrskapazität, verbessert eine gesamte Anrufqualität und Rauschunterdrückung und liefert einen zuverlässigen Transportmechanismus für Datendienstverkehr.
  • 1 zeigt die grundlegenden Elemente eines derartigen drahtlosen Datenkommunikationssystems 100. Für Fachleute ist offensichtlich, dass diese Elemente und ihre Schnittstellen modifiziert, erweitert oder verschiedenen in dem Stand der Technik bekannten Standards unterzogen werden können, ohne ihren Umfang oder Funktion einzuschränken. Das System 100 ermöglicht einer mobilen Endgeräteinrichtung, die TE2-Vorrichtung 102 (z.B. die Endgeräteinrichtung, wie ein Laptop- oder Palmtop-Computer), mit einer Interworking-Funktion (IWF) 108 zu kommunizieren. Das System 100 umfasst eine drahtlose Kommunikationsvorrichtung, die MT2-Vorrichtung 104 (z.B. ein drahtloses Telefon), und eine Basisstation/Mobil-Vermittlungsstelle (BS/MSC) 106. Die IWF 108 dient als ein Gateway zwischen dem drahtlosen Netzwerk und anderen Netzwerken, wie das öffentliche Fernsprechnetz (PSTN – public switched telephone network) oder leitungsgebundene Paketdatennetze, die einen Internet- oder Intranetzugang liefern. Eine L-Schnittstelle koppelt die IWF 108 an die BS/MSC 106. Oft sind die IWF 108 und die BS/MSC 106 gemeinsam angeordnet. Die TE2-Vorrichtung 102 ist über die Rm-Schnittstelle elektronisch an die MT2-Vorrichtung 104 gekoppelt. Die MT2-Vorrichtung 104 kommuniziert mit BS/MSC 106 über die drahtlose Schnittstelle Um. Die TE2-Vorrichtung 102 und die MT2-Vorrichtung 104 können in einer einzelnen Einheit (z.B. die MTO-Vorrichtung) angeordnet sein oder getrennt sein, wie im Fall einer installierten Mobiltelefoneinheit, in der ein Laptop die TE2-Vorrichtung 102 ist und der Transceiver die MT2-Vorrichtung 104 ist. Es ist wichtig, anzumerken, dass, wie in 2 gezeigt, die Kombination der TE2-Vorrichtung 102 und der MT2-Vorrichtung 104, entweder integriert oder getrennt, im Allgemeinen als eine mobile Station (MS) 103 bezeichnet wird.
  • Eine weitere Unterstützung wird ermöglicht durch Anwenden verschiedener weithin bekannter Protokolle, um verschiedene Aspekte von drahtlosen Kommunikationen zu steuern, zu verwalten oder anderweitig zu erleichtern. Zum Beispiel wurde die Lebensader der Internet-Infrastruktur, das Internetprotokoll (IP), in viele drahtlose Kommunikationsdienste eingegliedert, um Paket-orientierte Dienste aufzunehmen. Das IP-Protokoll spezifiziert das Adressieren und Weiterleiten (routing) von Paketen (Datagrammen) zwischen Host-Computern und ist definiert in „Request For Comment 791 (RFC 791)" mit dem Titel „INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", veröffentlicht September 1981.
  • Das IP-Protokoll ist ein Netzwerkschichtprotokoll, das Daten in IP-Pakete zur Übertragung einkapselt. Eine Adressierungs- und Weiterleitungsinformation wird in dem Header des Pakets angebracht. IP-Header enthalten 32-Bit-Adressen, welche die sendenden und empfangenden Hostrechner identifizieren. Diese Adressen werden von dazwischenliegenden Routern verwendet, um für das Paket einen Pfad durch das Netzwerk zu seinem endgültigen Ziel an der beabsichtigten Adresse zu wählen. Somit ermöglicht das IP-Protokoll Paketen, die von einem beliebigen Internet-Knoten in der Welt stammen, dass sie an jeden anderen beliebigen Internet-Knoten in der Welt geleitet werden.
  • Ein weiteres weithin bekanntes Protokoll, das in drahtlosen Kommunikationssystemen aufgenommen ist, ist das Point-to-Point-Protokoll (PPP), das unter anderem einen Internetzugang ermöglicht. Das PPP wird detailliert beschrieben in „Request for Comments 1661 (RFC 1661)" mit dem Titel „THE POINT-TO-POINT PROTOCOL (PPP)", veröffentlicht Juli 1994.
  • Im Wesentlichen spezifiziert das PPP ein Verfahren zum Transportieren von Multiprotokoll-Datagrammen über Punkt-zu-Punkt-Verbindungen und enthält drei hauptsächliche Komponenten: ein Verfahren zum Einkapseln von Multiprotokoll-Datagrammen; ein Verbindungssteuerungsprotokoll (LCP – link control protocol) zum Einrichten, Konfigurieren und Testen einer Datenverbindung; und eine Familie von Netzsteuerungsprotokollen (NCPs – network control protocols) zum Einrichten und Konfigurieren unterschiedlicher Netzwerkschichtprotokolle.
  • Zum Vorsehen einer Menge von Diensten auf drahtlosen Kommunikationssystemen wurden verschiedene Standards entwickelt, um die drahtlose Datenübertragung zwischen der TE2-Vorrichtung 102 und der IWF 108 zu ermöglichen. Zum Beispiel definiert der Standard TIA/EIA IS-707.5 mit dem Titel „DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES", veröffentlicht Februar 1998, Anforderungen zur Unterstützung einer Fähigkeit zur Paketdatenübertragung auf „TIA/EIA IS-95"-Systemen und spezifiziert eine Gruppe von Paketdatenübertragungsdiensten.
  • Insbesondere liefert der „IS-707.5"-Standard bestimmte Paketdatendienstmodi, die verwendet werden können, um zwischen der TE2-Vorrichtung 102 und der IWF 108 über BS/MSC 106 zu kommunizieren. Dadurch führt IS-707.5 das Netzmodell ein, das einen bestimmten Betriebsmodus liefert. Das Netzmodell stellt die Situation dar, in der eine erste PPP-Verbindung zwischen der TE2-Vorrichtung 102 und der MT2-Vorrichtung 104 aufgebaut wird, und eine zweite PPP-Verbindung, unabhängig von der ersten, zwischen der MT2-Vorrichtung 104 und der IWF 108 aufgebaut wird. Durch dieses Modell wird die MT2-Vorrichtung 104 verantwortlich für das Entfernen von Rahmen aller empfangenen PPP-Pakete und deren erneutes Versehen mit Rahmen, bevor sie diese an ihr endgültiges Ziel weiterleitet, sowie für das Vorsehen einer Mobilitätsverwaltung und einer Netzadressverwaltung.
  • 2 stellt die Protokoll-Stapel (stacks) in jeder Entität des „IS-707.5"-Netzmodells dar. In 2 ganz links ist ein Protokoll-Stapel, der in einem herkömmlichen vertikalen Format gezeigt wird, und die Protokollschichten zeigt, die auf der TE2-Vorrichtung 102 (z.B. das mobile Endgerät, ein Laptop- oder Palmtop-Computer) ablaufen. Der TE2-Protokoll-Stapel wird als über die Schnittstelle Rm logisch verbunden mit dem Protokoll-Stapel der MT2-Vorrichtung 104 dargestellt. Die MT2-Vorrichtung 104 wird als über die Schnittstelle Um logisch verbunden mit dem Protokoll-Stapel der BS/MSC 106 dargestellt. Der Protokoll-Stapel der BS/MSC 106 ist wiederum gezeigt als über die L-Schnittstelle logisch verbunden mit dem Protokoll-Stapel der IWF 108 gezeigt.
  • Zur Veranschaulichung arbeiten die in 2 dargestellten Protokolle wie folgt: die PPP-Schicht auf der zu der Rm-Schnittstelle gehörenden TE2-Vorrichtung 102 (d.h. PPPR 208) codiert Pakete von den oberen Schichtprotokollen 204 und dem Netzschicht- bzw. Netzwerk-IP-Protokoll 206. Die PPPR-Schicht 208 überträgt dann die Pakete über die Rm-Schnittstelle unter Verwendung eines anwendbaren Protokolls, wie zum Beispiel das TIA/EIA-232-F-Protokoll 210, und die Pakete werden von dem TIA/EIA-232-F-kompatiblen Anschluss auf der MT2-Vorrichtung 104 empfangen. Der TIA/EIA-232-F-Standard wird in „INTERFACE BETWEEN DATA TERMINAL EQUIPMENT AND DATA CIRCUIT-TERMINATING EQUIPMENT EMPLOYING SERIAL BINARY DATA INTERCHANGE" definiert, das im Oktober 1997 veröffentlicht wurde. Es ist offensichtlich, dass andere Standards und Protokolle, die Fachleuten bekannt sind, verwendet werden können, um die Übertragung über die Rm-Schnittstelle zu definieren. Zum Beispiel umfassen andere anwendbare Rm-Schnittstellen-Standards „UNIVERSAL SERIAL BUS (USB) SPECIFICATION, Revision 1.1 ", veröffentlicht September 1998, und „BLUETOOTH SPECIFICATION VERSION 1.0A CORE", veröffentlicht Juli 1999.
  • Das TIA/EIA-232-F-Protokoll 212 auf der MT2-Vorrichtung 104 empfängt die Pakete von der TE2-Vorrichtung 102 und leitet sie an die PPPR-Schicht 213 der MT2-Vorrichtung 104 weiter. Die PPPR-Schicht 213 „entrahmt" die in die PPP-Rahmen eingekapselten Pakete und die Schicht 213 überträgt typischerweise, wenn eine Datenverbindung besteht, die Pakete an die PPP-Schicht, die zu der Um-Schnittstelle gehört (d.h. PPPU-Schicht 217). Die PPPU-Schicht 217 formatiert die Pakete in PPP-Rahmen zur Übertragung an einen PPPU-Teilnehmer (peer), der sich in der IWF 108 befindet. Das Funkverbindungsprotokoll (RLP – radio link protocol) 216 und das IS-95-Protokoll 214, die beide im Stand der Technik weithin bekannt sind, werden verwendet, um die Paket-eingekapselten PPP-Rahmen über die Um-Schnittstelle an die BS/MSC 106 zu übertragen. Das RLP-Protokoll 216 ist in dem IS-707.2-Standard mit dem Titel „DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL" definiert, veröffentlicht Februar 1998, und das IS-95-Protokoll ist in dem oben identifizierten IS-95-Standard definiert.
  • Wie oben angemerkt, überträgt das PPPR-Protokoll 213 die Pakete an das PPPU-Protokoll 217, wenn eine Datenverbindung aufgebaut ist. RFC 1661 sieht vor, dass Verbindungssteuerungsprotokoll-Pakete (LCP – link control protocol) über jede PPP-Verbindung (d.h. PPPR und PPPU) ausgetauscht und ausgehandelt werden müssen, um die Datenverbindung aufzubauen, zu konfigurieren und zu testen.
  • Sobald die LCP-Pakete ausgetauscht sind, die Verbindungsoptionen ausgehandelt sind und die Datenverbindung aufgebaut ist, muss eine Netzschichtverbindung zwischen der TE2-Vorrichtung 102 und der IWF 108 aufgebaut werden. Eine derartige Verbindung setzt Protokolle 206, 212, 218, 230 ein, die zum Beispiel das IP-Protokoll umfassen. Die Verhandlung, die Konfiguration, die Aktivierung und die Deaktivierung des IP-Protokolls auf beiden Enden der PPP-Verbindung wird von dem weithin bekannten Internetprotokollsteuerungsprotokoll (IPCP – Internet Protocol Control Protocol) vorgesehen. IPCP ist ein Teil der Familie von Netzsteuerungsprotokollen (NCPs – Network Control Protocols), die in dem PPP-Protokoll eingeschlossen sind, und wird beschrieben in „Request for Comment (RFC) 1332" mit dem Titel „THE PPP INTERNET PROTOCOL CONTROL PROTOCOL (IPCP)", veröffentlicht Mai 1992.
  • Das IPCP-Protokoll setzt die standardmäßigen PPP-Konfigurationsanfrage-(Configure-Request), Konfigurationsbestätigungs-(Configure-Ack) und nega tive Konfigurationsbestätigungsmeldungen (Configure-Nak) ein, um verschiedene Optionen zu verhandeln, einschließlich die Anforderung und Zuweisung von IP-Adressen. IPCP sieht vor, dass ein eine IP-Adresse anfragender Anforderer eine Konfigurationsanfragemeldung erzeugt, die eine bestimmte Adresse enthält. Wenn die bestimmte IP-Adresse akzeptabel ist, wird eine Konfigurationsbestätigungsmeldung von einem Peer an den Anforderer gesendet. Wenn die bestimmte IP-Adresse nicht akzeptabel ist, dann sendet der Peer eine negative Konfigurationsbestätigungsmeldung, die eine vorgeschlagene IP-Adresse enthält. Der Anforderer überträgt dann eine neue Konfigurationsanfragemeldung mit der vorgeschlagenen IP-Adresse und der Peer antwortet mit einer Konfigurationsbestätigungsmeldung.
  • Es ist nur möglich, einzelne IP-Adressen über die PPPU- und PPPR-Verbindungen zuzuweisen, da es in IPCP keinen Mechanismus gibt, um mehr als eine Adresse zuzuweisen. Dies bedeutet, dass die IP-Adresse, die von der IWF über PPPU zugewiesen wird, ferner über PPPR der TE2 zugewiesen werden muss. In dem Netzwerkmodell können IPCP-Adressverhandlungen getrennt sowohl für die Rm-Schnittstelle als auch die Um-Schnittstelle stattfinden. Die MT2-Vorrichtung 104 muss zuerst eine IP-Adresse über die Um-Schnittstelle mit der IWF 108 an einem Ende der PPPU-Verbindung aushandeln, bevor die Adresse der TE2-Vorrichtung 102 an dem anderen Ende der PPPR-Verbindung zugewiesen werden kann.
  • Die Vollendung von IPCP-Adressverhandlungen kann jedoch von Betriebsverzögerungen behindert werden. Zum Beispiel können derartige Verzögerungen auftreten, wenn die Verbindung zwischen der MT2-Vorrichtung 104 und der IWF 108 langsamer ist als die Verbindung zwischen der TE2-Vorrichtung 102 und der MT2-Vorrichtung 104. Somit existiert eine Möglichkeit, dass IPCP-Adressverhandlungen schneller auf der Rm-Verbindung als auf der Um-Verbindung erreicht werden. Die TE2-Vorrichtung 102 kann deshalb eine IP-Adresse von der MT2-Vorrichtung 104 anfordern, die nicht erteilt werden kann, da die MT2-Vorrichtung 104 die erforderlichen Adressverhandlungen auf der Um-Verbindung nicht beendet hat, um eine IP-Adresse von der IWF 108 zu liefern. Obwohl die TE2-Vorrichtung 102 warten kann, bis die MT2-Vorrichtung 104 schließlich eine IP-Adresse liefert, gibt es Implementierungs-spezifische Zeitüberschreitungen (Time-Outs) auf der TE2-Vorrichtung 102, welche die TE2-Vorrichtung 102 veranlassen können, die IP-Adressanfrage und somit PPP-Verhandlungen vollständig abzubrechen.
  • Ein weiteres Beispiel von Betriebsverzögerungen tritt auf, wenn die IWF 108 die IP-Adresse, die letztendlich der TE2-Vorrichtung 102 zugewiesen wird, von einer anderen Entität erlangen muss, bevor sie diese an die MT2-Vorrichtung 104 weitergeben kann. Dadurch kann es mehrere Sekunden dauern, bevor die MT2-Vorrichtung 104 die IP-Adresse empfängt.
  • Als Beispiel soll angemerkt werden, dass einige der auf der TE2-Vorrichtung 102 laufenden Anwendungen es der TE2-Vorrichtung 102 ermöglichen, Konfigurationsanfragemeldungen alle drei Sekunden für drei Versuche zu erzeugen, bevor die TE2-Vorrichtung 102 das Zeitlimit erreicht. In derartigen Fällen bricht, wenn es insgesamt mehr als 9 Sekunden bis zum Empfang einer IP-Adresse dauert, die TE2-Vorrichtung 102 die Adressanfrage ab. Zweifellos kann jedes der beiden oben erwähnten Szenarien Verzögerungen erzeugen, die dazu führen können, dass die TE2-Vorrichtung 102 frühzeitig abbricht.
  • Deswegen ist ein neues Verfahren zur Vermeidung von Time-Outs erforderlich, um IPCP-Adressverhandlungen aufrechtzuerhalten.
  • Zusammenfassung der Erfindung
  • Die vorliegende Erfindung adressiert das oben identifizierte Erfordernis durch Vorsehen eines neuen Verfahrens zur Vermeidung von Time-Outs bzw. Zeitüberschreitungen, um IPCP-Adressverhandlungen aufrechtzuerhalten, wie in den angefügten Ansprüchen dargelegt wird.
  • Verfahren, die zu den Prinzipien der vorliegenden Erfindung konsistent sind, wie hier aufgenommen und ausführlich beschrieben, umfassen eine Kommunikationsvorrichtung, die eine eine IP-Adresse anfordernde Meldung, wie eine Konfigurationsanfragemeldung, von einem Endgerät empfängt, das mit der Kommunikationsvorrichtung verbunden ist. Die Kommunikationsvorrichtung stellt dann fest, ob sie eine zugewiesene IP-Adresse von einem Peer (d.h. IWF) als Antwort auf die IP-Adressanfragemeldung empfangen hat. Als Antwort auf die Feststellung, dass die Kommunikationsvorrichtung die zugewiesene IP-Adresse nicht von der IWF empfangen hat, überträgt die Kommunikationsvorrichtung eine Meldung mit einer beliebigen IP-Adresse, wie eine negative Konfigurationsbestätigungsmeldung an das Endgerät. Die in der Meldung enthaltene beliebige IP-Adresse wird von der Kommunikationsvorrichtung zurückgewiesen, wodurch bei dem Endgerät ausgelöst wird, weiterhin zusätzliche IP-Adressanfragemeldungen zu übertragen, bis die Kommunikationsvorrichtung die zugewiesene IP-Adresse empfangen hat.
  • Kurze Beschreibung der Zeichnungen
  • Die beigefügten Zeichnungen, die in die Spezifikation aufgenommen sind und einen Teil davon darstellen, stellen ein Ausführungsbeispiel der Erfindung dar und erläutern zusammen mit der Beschreibung die Aufgaben, Vorteile und Prinzipien der Erfindung. Bei den Zeichnungen ist
  • 1 eine prinzipielle/schematische Blockdarstellung, die verschiedene Elemente eines drahtlosen Kommunikationssystem darstellt.
  • 2 beschreibt schematisch die Protokoll-Stapel (stacks) eines drahtlosen Kommunikationssystems.
  • 3A ist ein Ablaufdiagramm, das ein Ausführungsbeispiel der Erfindung beschreibt.
  • 3B ist ein Protokollmeldungs-Ablaufdiagramm, das den Betrieb eines Ausführungsbeispiels der Erfindung beschreibt.
  • Detaillierte Beschreibung der bevorzugten Ausführungsbeispiele
  • Die folgende detaillierte Beschreibung der Ausführungsbeispiele der vorliegenden Erfindung bezieht sich auf die beigefügten Zeichnungen, welche diese illustrieren. Andere Ausführungsbeispiele sind möglich und Modifizierungen der Ausführungsbeispiele können gemacht werden, ohne vom Umfang der Erfindung abzuweichen. Folglich soll die folgende detaillierte Beschreibung die Erfindung nicht einschränken. Stattdessen ist der Umfang der Erfindung durch die beigefügten Ansprüche definiert.
  • Es ist für Fachleute offensichtlich, dass ein Ausführungsbeispiel der vorliegenden Erfindung, wie unten beschrieben, in einer Vielfalt von Implementierungen realisiert werden kann, einschließlich der Software, Firmware und Hardware der in den Fig. dargestellten Entitäten (d.h. TE2-Vorrichtung 102, MT2-Vorrichtung 104, BS/MSC 106 und IWF 108). Der tatsächlich verwendete Software-Code oder die Steuerungs-Hardware, um die vorliegende Erfindung zu implementieren, schränkt de vorliegende Erfindung nicht ein. Somit werden der Betrieb und das Verhalten der vorliegenden Erfindung ohne eine spezifische Bezugnahme auf den tatsächlichen Software-Code oder die Hardware-Komponenten beschrieben. Derartige nichtspezifischen Bezugnahmen sind akzeptabel, da es offensichtlich ist, dass ein Fachmann basierend auf der hier gegebenen Beschreibung eine Software und eine Steuerungs-Hardware entwickeln kann, um das Ausführungsbeispiel der vorliegenden Erfindung zu implementieren.
  • 3A ist ein Ablaufdiagramm, das ein Ausführungsbeispiel der vorliegenden Erfindung darstellt und 3B ist ein Protokollmeldungs-Ablaufdiagramm, das den Betrieb eines Ausführungsbeispiels der Erfindung beschreibt. Wie in 3A gezeigt, beginnt die MT2-Vorrichtung 104 in dem Block B305 PPP-Verhandlungen über die Um-Schnittstelle mit der IWF 108.
  • Dieses Ereignis wird durch den Beginn von LCP-Verhandlungen auf der Rm-Schnittstelle ausgelöst, wie in 3B dargestellt (siehe Bezugszeichen A).
  • In dem Block B310 wartet die MT2-Vorrichtung 104, bis sie eine IPCP-Konfigurationsanfragemeldung (Configure-Request-Message) von der TE2-Vorrichtung 102 empfangen hat. Sobald die MT2-Vorrichtung 104 eine Konfigurationsanfragemeldung von der TE2-Vorrichtung 102 empfangen hat, geht die MT2-Vorrichtung 104 weiter zu Block B315.
  • In Block B315 bestimmt die MT2-Vorrichtung 104, ob sie als Antwort auf die Konfigurationsanfragemeldung von der TE2-Vorrichtung 102 eine von der IWF 108 zugewiesene IP-Adresse empfangen hat. Wenn nicht, geht die MT2-Vorrichtung 104 zu Block B320 weiter, wo sie die in der Konfigurationsanfragemeldung enthaltene IP-Adresse zurückweist und eine negative Konfigurationsbestätigungsmeldung (Configure-Nak Message) mit einer beliebigen IP-Adresse überträgt (siehe Bezugszeichen B in 3B). Die beliebige IP-Adresse ist eine Adresse, die von der MT2-Vorrichtung 104 zurückgewiesen werden wird. Nach Übertragung der negativen Konfigurationsbestätigungsmeldung mit der beliebigen IP-Adresse geht die MT2-Vorrichtung 104 zurück zu Block B310, um eine weitere IPCP-Konfigurationsanfragemeldung von der TE2-Vorrichtung 102, mit der beliebigen IP-Adresse, zu erwarten. Da die beliebige IP-Adresse nicht die von der IWF 108 zugewiesene IP-Adresse ist, wird die MT2-Vorrichtung 104 zurück zu Block B320 verwiesen, wo sie wiederum die in der Konfigurationsanfragemeldung enthaltene IP-Adresse zurückweist und eine negative Konfigurationsbestätigungsmeldung mit einer beliebigen IP-Adresse überträgt. Die beliebige Adresse kann dieselbe Adresse sein wie die vorherige Iteration oder eine andere Adresse sein. Die von der Reihe von Blöcken B310–B315–B320 erzeugte Schleife wird wiederholt, bis die MT2-Vorrichtung 104 bestimmt, dass sie eine von der IWF 108 zugewiesene IP-Adresse empfangen hat. Durch in Anspruch nehmen der TE2-Vorrichtung 102 und deren Veranlassen, Konfigurationsanfragemeldungen zu erzeugen, verhindert die MT2-Vorrichtung 104, dass die TE2- Vorrichtung 102 ein Zeitlimit überschreitet, wodurch die IPCP-Adressverhandlungen unterstützt werden. Es wäre auch möglich, eine Verzögerung in die Schleife einzuführen, was die Anzahl der Meldungen reduziert, die zwischen der MT2-Vorrichtung 104 und der TE2-Vorrichtung 102 ausgetauscht werden.
  • Zurück zu Block B315, wenn die MT2-Vorrichtung 104 bestimmt, dass sie eine von der IWF 108 zugewiesene IP-Adresse empfangen hat, geht die MT2-Vorrichtung 104 zu B325 weiter, wo sie eine negative Konfigurationsbestätigungsmeldung, welche die zugewiesene IP-Adresse enthält, an die TE2-Vorrichtung 102 überträgt (siehe Bezugszeichen C). Die MT2-Vorrichtung 104 empfängt dann in Block B330 eine Konfigurationsanfragemeldung mit der zugewiesenen IP-Adresse von der TE2-Vorrichtung 102 (siehe Bezugszeichen D).
  • Die MT2-Vorrichtung 104 geht zu Block B335 weiter, wo sie eine Konfigurationsbestätigungsmeldung an die TE2-Vorrichtung 102 überträgt, um die Konfigurationsanfragemeldung von der TE2-Vorrichtung 102 zu bestätigen (siehe Bezugszeichen E). In Block B340 überträgt die MT2-Vorrichtung 104 dann die IPCP-Optionen, die über die Um-Verbindung mit der IWF 108 verhandelt wurden, an die TE2-Vorrichtung 102 (siehe Bezugszeichen F). Die MT2-Vorrichtung 104 empfängt dann in Block B345 eine Konfigurationsbestätigungsmeldung von der TE2-Vorrichtung 102, welche die Optionen bestätigt, die von der von der IWF 108 zugewiesenen IP-Adresse verwendet werden (siehe Bezugszeichen G). Es sollte angemerkt werden, dass die Prozesse in den Blöcken B340 und B345 nicht unbedingt erforderlich sind, da die MT2-Vorrichtung 104 alle beliebigen IPCP-Werte an die TE2-Vorrichtung 102 senden könnte, da alle Pakete durch die MT2-Vorrichtung 104 mit Rahmen versehen und „entrahmt" werden.
  • Somit ist die Erfindung fähig, Implementierungs-spezifische Zeitüberschreitungen zu vermeiden, indem der TE2-Vorrichtung 102 negative Konfigurationsbestätigungsmeldungen geliefert werden, die beliebige IP-Adressen ent halten, die von der MT2-Vorrichtung 104 zurückgewiesen werden. Die negativen Konfigurationsbestätigungsmeldungen lösen bei der TE2-Vorrichtung 102 ein Erzeugen von Konfigurationsanfragemeldungen aus. Dieses Wechselspiel geht weiter, bis die MT2-Vorrichtung 104 die von der IWF 108 zugewiesene IP-Adresse empfängt und diese IP-Adresse in einer negativen Konfigurationsbestätigungsmeldung an die TE2-Vorrichtung 102 weitergibt. Auf diese Weise wird verhindert, dass die TE2-Vorrichtung 102 aufgrund von Implementierungs-spezifische Zeitüberschreitungen vorzeitig abbricht, und PPP-Verhandlungen werden unterstützt.
  • Die obige Beschreibung der bevorzugten Ausführungsbeispiele der vorliegenden Erfindung liefert eine Darstellung und Erläuterung, erhebt aber keinen Anspruch auf Vollständigkeit und soll die Erfindung nicht auf die konkret offenbarte Form beschränken. Modifizierungen und Variationen sind konsistent mit den obigen Lehren möglich oder können aus der Praxis der Erfindung erlangt werden. Demgemäß ist der Umfang der Erfindung von den Ansprüchen und ihrer Äquivalente definiert.

Claims (32)

  1. Ein Verfahren zum Unterhalten bzw. Beibehalten von IP-Adressverhandlungen in einem drahtlosen Kommunikationsnetzwerk, das das IPCP-Protokoll implementiert, wobei das Verfahren Folgendes aufweist: Empfangen, an einem Kommunikationsgerät, einer Nachricht, die eine IP-Adresse von einem Endgerät, das eine bestimmte Adresse enthält, anfragt, wobei das Endgerät an das Kommunikationsgerät gekoppelt ist; Generieren, in dem Kommunikationsgerät, einer Nachricht, die eine IP-Adresse von dem Kommunikationsnetzwerk anfragt, ansprechend auf die IP-Adressanfragenachricht; und Bestimmen ob das Kommunikationsgerät eine zugewiesene IP-Adresse von dem Kommunikationsnetzwerk empfangen hat, dadurch gekennzeichnet, dass ansprechend auf das Bestimmen, dass das Kommunikationsgerät nicht die erwähnte zugewiesene IP-Adresse empfangen hat, das Kommunikationsgerät wiederholt eine Nachricht mit einer beliebigen IP-Adresse an das Endgerät sendet um zu veranlassen, dass das Endgerät mittels Senden von IP-Adressanfragenachrichten inklusive der erwähnten beliebigen IP-Adresse antwortet, und wobei das Kommunikationsgerät die beliebige IP-Adresse in den IP-Adressanfragenachrichten zurückweist bis das Kommunikationsgerät die zugewiesen IP-Adresse von dem Kommunikationsnetzwerk empfangen hat.
  2. Verfahren nach Anspruch 1, wobei das Generieren Folgendes beinhaltet: Weiterleiten der IP-Adressanfragenachricht von dem Kommunikationsgerät zu einer Interworking-Funktion, die in dem Kommunikationsnetzwerk enthalten ist, und Verhandeln mit der Interworking-Funktion um die zugewiesene Adresse, basierend auf der IP-Adressanfragenachricht, zu sichern bzw. festzuhalten.
  3. Verfahren nach Anspruch 2, wobei das Bestimmen Folgendes aufweist: Ermitteln ob die Interworking-Funktion die zugewiesene IP-Adresse, ansprechend auf die IP-Adressverhandlungen, vorgesehen hat.
  4. Verfahren nach Anspruch 3, wobei ansprechend auf das Bestimmen, dass das Kommunikationsgerät die zugewiesene IP-Adresse empfangen hat, das Kommunikationsgerät eine Nachricht mit der zugewiesenen IP-Adresse an das Endgerät sendet.
  5. Verfahren nach Anspruch 4, wobei ansprechend auf das Senden der zugewiesenen IP-Adressnachricht an das Endgerät, das Kommunikationsgerät eine IP-Adressanfragenachricht mit der zugewiesenen IP-Adresse von dem Endgerät empfängt.
  6. Verfahren nach Anspruch 5, wobei ansprechend auf das Empfangen der IP-Adressanfragenachricht mit der zugewiesenen IP-Adresse von dem Endgerät bzw. Terminalgerät, das Kommunikationsgerät eine Nachricht sendet, die die IP-Adressanfragenachricht an das Endgerät bestätigt.
  7. Verfahren nach Anspruch 6, wobei ansprechend auf das Senden einer Nachricht, mit der die IP-Adresseanfragenachricht an das Endgerät bestätigt wird, das Kommunikationsgerät eine Nachricht mit Konfigurationsoptionen von der Interworking-Funktion sendet.
  8. Verfahren nach Anspruch 7, wobei ansprechend auf das Senden der Nachricht mit Konfigurationsoptionen von der Interworking-Funktion, das Kommunikationsgerät eine Nachricht zum Bestätigen der zugewiesenen IP-Adresse durch das Endgerät an die Interworking-Funktion empfängt.
  9. Verfahren nach Anspruch 8, wobei die IP-Adressanfragenachricht eine IPCP-Konfigurationsanfragenachricht bzw. Configure-Request-Nachricht ist.
  10. Verfahren nach Anspruch 9, wobei die Beliebig-IP-Adressnachricht eine IPCP-Konfigurations- bzw. Configure-Nak-Nachricht ist, die eine IP-Adresse aus einer Vielzahl von Beliebig-IP-Adressen, die das Kommunikationsgerät zurückweisen wird, enthält.
  11. Verfahren nach Anspruch 10, wobei das Ermitteln ob die Interworking-Funktion eine IP-Adresse, ansprechend auf die IP-Adressanfragenachricht zugewiesen hat, bestimmt wird durch Identifizieren, ob das Kommunikationsgerät eine IPCP-Configure-Ack-Nachricht empfangen hat, die eine IP-Adresse von der Interworking-Funktion enthält.
  12. Verfahren nach Anspruch 11, wobei die zugewiesene IP-Adressnachricht eine IPCP-Configure-Nak-Nachricht ist, die die zugewiesene IP-Adresse, vorgesehen durch die Interworking-Funktion, enthält.
  13. Verfahren nach Anspruch 12, wobei die IP-Adressanfragenachricht mit der zugewiesenen IP-Adresse eine IPCP-Configure-Anfragenachricht ist, die die zugewiesene IP-Adresse enthält.
  14. Verfahren nach Anspruch 13, wobei die Nachricht mit der die IP-Adressanfragenachricht mit der zugewiesenen IP-Adresse bestätigt wird, eine IPCP-Configure-Ack-Nachricht ist.
  15. Verfahren nach Anspruch 14, wobei die Nachricht mit der der Empfang der zugewiesenen IP-Adresse an die Interworking-Funktion bestätigt wird, eine IPCP-Configure-Ack-Nachricht ist.
  16. Verfahren nach Anspruch 15, das weiterhin folgenden Schritt aufweist: Einführen einer Verzögerung von vorbestimmter Dauer um die Anzahl von Malen zu reduzieren wie oft das Kommunikationsgerät wiederholt die Beliebig-IP-Adressnachricht sendet und um die Anzahl von Malen zu reduzieren wie oft dies Endgerät mit den IP-Adressanfragenachrichten, die die Beliebig-IP-Adresse enthält, antwortet.
  17. Ein System (100) zum Aufrechterhalten von IP-Adressverhandlungen in einem drahtlosen Kommunikationsnetzwerk, das das IPCP-Protokoll implementiert, wobei das System Folgendes aufweist: ein Terminal bzw. Endgerät (102); und ein Kommunikationsgerät (104), das an das Endgerät (102) gekoppelt ist, wobei das Kommunikationsgerät (104) angepasst ist um eine IP-Adressanfragenachricht von dem Endgerät, das eine bestimmte Adresse enthält, zu empfangen und, ansprechend hierauf, das Kommunikationsgerät (104) angepasst ist um eine IP-Adressanfragenachricht an das Kommunikationsnetzwerk zu senden; wobei das Kommunikationsgerät (104) angepasst ist um zu bestimmen, ob es eine zugewiesene IP-Adresse von dem Kommunikationsnetzwerk empfangen hat und dadurch gekennzeichnet, dass ansprechend auf das Bestimmen, dass das Kommunikationsgerät (104) nicht die zugewiesene IP-Adresse empfangen hat, das Kommunikationsgerät (104) wiederholt angepasst ist um eine Nachricht mit einer beliebigen IP-Adresse an das Endgerät (102) zu senden, um zu veranlassen, dass das Endgerät (102) mittels Senden von IP-Adressanfragenachrichten, die die beliebige IP-Adresse enthalten, antwortet und wobei das Kommunikationsendgerät angepasst ist um die beliebige IP-Adresse in den IP-Adressanfragenachrichten zurückzuweisen bis das Kommunikationsgerät (104) die zugewiesene IP-Adresse von dem Kommunikationsnetzwerk empfangen hat.
  18. System nach Anspruch 17, wobei das drahtlose Kommunikationsnetzwerk eine Interworking-Funktion (108) aufweist und wobei das Kommunikationsgerät (104) angepasst ist um eine IP-Adressanfragenachricht an das Kommunikationsnetzwerk zu senden, und Folgendes beinhaltet: Mittel zum Weiterleiten der IP-Adressanfragenachricht von dem Kommunikationsgerät (104) zu der Interworking-Funktion (108) und Mittel zum Verhandeln mit der Interworking-Funktion (108) um die zugewiesene Adresse, basierend auf der IP-Adressanfragenachricht zu sichern bzw. festzuhalten.
  19. System nach Anspruch 18, wobei das Kommunikationsgerät (104) angepasst ist zum Bestimmen, ob es eine zugewiesene IP-Adresse von dem Kommunikationsnetzwerk empfangen hat, und zwar durch Ermitteln ob die Interworking-Funktion (108) die zugewiesene IP-Adresse ansprechend auf die IP-Adressverhandlungen vorgesehen hat.
  20. System nach Anspruch 19, wobei ansprechend auf das Bestimmen, dass das Kommunikationsgerät (104) die zugewiesene IP-Adresse empfangen hat, das Kommunikationsgerät (104) angepasst ist, um eine Nachricht mit der zugewiesenen IP-Adresse an das Endgerät (102) zu senden.
  21. System nach Anspruch 20, wobei ansprechend auf das Senden der zugewiesenen IP-Adressnachricht an das Endgerät (102), das Kommunikationsgerät (104) angepasst ist, um eine IP-Adressanfragenachricht mit der zugewiesenen IP-Adresse von dem Endgerät (102) zu empfangen.
  22. System nach Anspruch 21, wobei, ansprechend auf das Empfangen der IP-Adressanfragenachricht mit der zugewiesenen IP-Adresse von dem Endgerät (102), das Kommunikationsgerät (104) angepasst ist, eine Nachricht, die die IP-Adressanfragenachricht an das Endgerät (102) bestätigt, zu senden.
  23. System nach Anspruch 22, wobei, ansprechend auf das Senden einer Nachricht, die die IP-Adressanfragenachricht an das Endgerät (102) bestätigt, das Kommunikationsgerät (104) angepasst ist, um eine Nach richt mit Konfigurationsoptionen von der Interworking-Funktion (108) zu senden.
  24. System nach Anspruch 23, wobei, ansprechend auf das Senden der Nachricht mit Konfigurationsoptionen von der Interworking-Funktion (108), das Kommunikationsgerät (104) angepasst ist, um eine Nachricht, die den Empfang der zugewiesenen IP-Adresse durch das Endgerät (102) an die Interworking-Funktion (108) bestätigt, zu empfangen.
  25. System nach Anspruch 24, wobei die IP-Adressanfragenachricht eine IPCP-Configure-Request-Nachricht ist.
  26. System nach Anspruch 25, wobei die Beliebig-IP-Adressnachricht eine IPCP-Configure-Nak-Nachricht ist, die eine einer Vielzahl von beliebigen IP-Adressen, die das Kommunikationsgerät (104) zurückweisen wird, enthält.
  27. System nach Anspruch 26, wobei das Ermitteln ob die Interworking-Funktion (108) eine IP-Adresse entsprechend auf die IP-Adressanfragenachricht zugewiesen hat, stattfindet durch Identifizieren, ob das Kommunikationsgerät (104) eine IPCP-Configure-Ack-Nachricht, die eine IP-Adresse von der Interworking-Funktion (108) enthält, empfangen hat.
  28. System nach Anspruch 27, wobei die zugewiesene IP-Adressnachricht eine IPCP-Configure-Nak-Nachricht ist, die die zugewiesene IP-Adresse, vorgesehen durch die Interworking-Funktion (108) enthält, ist.
  29. System nach Anspruch 28, wobei die IP-Adressanfragenachricht mit der zugewiesenen IP-Adresse eine IPCP-Configure-Anfragenachricht, die die zugewiesene IP-Adresse enthält, ist.
  30. System nach Anspruch 29, wobei die Nachricht, die die IP-Adressanfragenachricht mit der zugewiesenen IP-Adresse bestätigt, eine IPCP-Configure-Ack-Nachricht ist.
  31. System nach Anspruch 30, wobei die Nachricht, mit der der Empfang der zugewiesenen IP-Adresse an die Interworking-Funktion (108) bestätigt wird, eine IPCP-Configure-Ack-Nachricht ist.
  32. System nach Anspruch 31, wobei eine Verzögerung von vorbestimmter Dauer eingeführt wird, um die Anzahl von Malen mit denen das Kommunikationsgerät (104) angepasst ist, die Beliebig-IP-Adressnachricht wiederholt zu senden, zu reduzieren und um die Anzahl von Malen wie oft das Endgerät angepasst ist, um auf die IP-Adressanfragenachricht, die die beliebige IP-Adresse enthält, zu antworten, zu reduzieren.
DE60111823T 2000-01-14 2001-01-12 Verfahren zur vermeidung von ppp-zeitrüberschreitungen während ipcp-verhandlungen Expired - Lifetime DE60111823T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US483351 2000-01-14
US09/483,351 US6775553B1 (en) 2000-01-14 2000-01-14 Method of avoiding PPP time-outs during IPCP negotiations
PCT/US2001/000942 WO2001052499A2 (en) 2000-01-14 2001-01-12 Method of avoiding ppp time-outs during ipcp negotiations

Publications (2)

Publication Number Publication Date
DE60111823D1 DE60111823D1 (de) 2005-08-11
DE60111823T2 true DE60111823T2 (de) 2006-04-20

Family

ID=23919706

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60111823T Expired - Lifetime DE60111823T2 (de) 2000-01-14 2001-01-12 Verfahren zur vermeidung von ppp-zeitrüberschreitungen während ipcp-verhandlungen

Country Status (11)

Country Link
US (2) US6775553B1 (de)
EP (1) EP1247385B1 (de)
JP (1) JP4741145B2 (de)
KR (1) KR100748814B1 (de)
CN (1) CN1183733C (de)
AT (1) ATE299328T1 (de)
AU (1) AU2937501A (de)
CA (1) CA2397619A1 (de)
DE (1) DE60111823T2 (de)
ES (1) ES2244630T3 (de)
WO (1) WO2001052499A2 (de)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6775553B1 (en) * 2000-01-14 2004-08-10 Qualcomm Incorporated Method of avoiding PPP time-outs during IPCP negotiations
US7412528B2 (en) * 2000-01-14 2008-08-12 Qualcomm, Incorporated Avoiding PPP time-outs during IPCP negotiations
FI109950B (fi) * 2000-01-20 2002-10-31 Nokia Corp Osoitteen saanti
US6684256B1 (en) * 2000-01-27 2004-01-27 Utstarcom, Inc. Routing method for mobile wireless nodes having overlapping internet protocol home addresses
US7571308B1 (en) * 2000-06-28 2009-08-04 Microsoft Corporation Method for controlling access to a network by a wireless client
FI112150B (fi) * 2000-07-24 2003-10-31 Stonesoft Oyj Tietoliikenteen ohjausmenetelmä
JP3534185B2 (ja) * 2000-10-27 2004-06-07 日本電気株式会社 無線通信システム及びその通信方法
KR100678231B1 (ko) * 2000-12-20 2007-02-01 삼성전자주식회사 이동통신단말기의 패킷 데이터 처리 장치 및 방법
US20020142765A1 (en) * 2001-03-30 2002-10-03 Rhoads Monte J. Network appliance wireless configuration interface
US7512133B2 (en) * 2001-12-03 2009-03-31 International Business Machines Corporation Method and apparatus for obtaining multiple port addresses by a fibre channel from a network fabric
US20030158959A1 (en) * 2002-02-15 2003-08-21 Jay Jayapalan Establishment of communications using point to point protocols such that duplicate negotiations are avoided
US6973088B2 (en) * 2002-04-03 2005-12-06 Qualcomm Incorporated PPP link negotiation in mobile IP systems
US7590408B2 (en) * 2002-04-03 2009-09-15 Qualcomm Incorporated Systems and methods for early determination of network support for mobile IP
US7342894B2 (en) * 2002-04-03 2008-03-11 Qualcomm Incorporated System and method for transparent Mobile IP registration within PPP negotiation
KR100463820B1 (ko) * 2002-10-01 2004-12-29 에스케이 텔레콤주식회사 무선데이터 초기접속 지연 개선방법
CN1306762C (zh) * 2004-01-18 2007-03-21 中兴通讯股份有限公司 Wlan融合cdma2000用户跨网切换时保持ip地址不变的方法
JP3959402B2 (ja) * 2004-03-19 2007-08-15 株式会社日立コミュニケーションテクノロジー 通信接続装置及び通信端末ならびにこれを用いた通信方法
CN100589374C (zh) * 2004-07-08 2010-02-10 中兴通讯股份有限公司 一种使用点到点协议时防止ip地址泄漏的方法
US7609700B1 (en) * 2005-03-11 2009-10-27 At&T Mobility Ii Llc QoS channels for multimedia services on a general purpose operating system platform using data cards
CN100389616C (zh) * 2005-03-18 2008-05-21 华为技术有限公司 实现交互功能业务数据交互的方法
BRPI0619097A2 (pt) * 2005-12-01 2011-09-13 Qualcomm Inc método e equipamento para suportar credenciais de autenticação diferentes
US20080016248A1 (en) * 2006-07-14 2008-01-17 George Tsirtsis Method and apparatus for time synchronization of parameters
CN101646205B (zh) * 2008-08-05 2014-07-09 华为技术有限公司 移动网络高速接入公网的节点、方法及系统
US8537762B2 (en) * 2009-04-27 2013-09-17 Qualcomm Incorporated System and method for optimally transferring data traffic on networks
US8769367B2 (en) * 2010-01-28 2014-07-01 Mediatek Inc. Apparatus, method, and system for IP address negotiations
US8565160B2 (en) 2011-11-02 2013-10-22 Qualcomm Incorporated Methods and devices for facilitating access terminal registrations
US10271274B2 (en) * 2012-02-03 2019-04-23 Qualcomm Incorporated Devices and methods for facilitating extended time periods for maintaining PPP sessions
WO2014019185A1 (zh) * 2012-08-02 2014-02-06 华为技术有限公司 一种控制和转发解耦下协议处理方法及控制面设备、转发面设备
US9191209B2 (en) * 2013-06-25 2015-11-17 Google Inc. Efficient communication for devices of a home network
US10924450B2 (en) * 2013-12-20 2021-02-16 Telefonaktiebolaget Lm Ericsson (Publ) Allocation of resources during split brain conditions
WO2018210139A1 (zh) * 2017-05-18 2018-11-22 苏州欧普照明有限公司 无线网络节点的配置方法、装置及系统

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6205490B1 (en) * 1995-07-05 2001-03-20 Siemens Aktiengesellschaft System (IWF) for the bidirectional connection of an ELAN and a CLS wide-area network
KR100201902B1 (ko) * 1996-04-04 1999-06-15 류정열 자동차 휠 조타상태 표시장치
US5708655A (en) * 1996-06-14 1998-01-13 Telefonaktiebolaget L M Ericsson Publ Method and apparatus for addressing a wireless communication station with a dynamically-assigned address
KR100260516B1 (ko) * 1997-04-01 2000-07-01 정선종 코드분할 다중접속 이동통신망에서의 비동기통신 데이터발신호 및 착신호 서비스 방법
JP3045985B2 (ja) * 1997-08-07 2000-05-29 インターナショナル・ビジネス・マシーンズ・コーポレイション 接続確立方法、通信方法、状態変化伝達方法、状態変化実行方法、無線装置、無線デバイス、及びコンピュータ
US6061739A (en) * 1997-11-26 2000-05-09 International Business Machines Corp. Network address assignment using physical address resolution protocols
FI105976B (fi) 1998-02-09 2000-10-31 Nokia Networks Oy Matkaviestimen suurinopeuksinen liityntä TCP/IP-verkkoon
US6212563B1 (en) * 1998-10-01 2001-04-03 3Com Corporation Method and system for setting and managing externally provided internet protocol addresses using the dynamic host configuration protocol
US6483822B1 (en) 1999-06-07 2002-11-19 Marcello Lioy Establishing a packet network call between a mobile terminal device and an interworking function
US7412528B2 (en) * 2000-01-14 2008-08-12 Qualcomm, Incorporated Avoiding PPP time-outs during IPCP negotiations
US6775553B1 (en) * 2000-01-14 2004-08-10 Qualcomm Incorporated Method of avoiding PPP time-outs during IPCP negotiations
US6954800B2 (en) * 2000-04-07 2005-10-11 Broadcom Corporation Method of enhancing network transmission on a priority-enabled frame-based communications network
US20020107514A1 (en) * 2000-04-27 2002-08-08 Hooven Michael D. Transmural ablation device with parallel jaws
US7447182B2 (en) * 2001-04-06 2008-11-04 Nortel Networks Limited Discovering an address of a name server
KR100471615B1 (ko) 2001-11-07 2005-03-08 유티스타콤코리아 유한회사 Ｒａｄｉｕｓ 서버를 이용한 인터넷 서비스 프로바이더가입자의 아이피 주소 관리 시스템 및 그 방법
US7342894B2 (en) * 2002-04-03 2008-03-11 Qualcomm Incorporated System and method for transparent Mobile IP registration within PPP negotiation

Also Published As

Publication number Publication date
KR20020082842A (ko) 2002-10-31
EP1247385B1 (de) 2005-07-06
US8086748B2 (en) 2011-12-27
KR100748814B1 (ko) 2007-08-13
CA2397619A1 (en) 2001-07-19
EP1247385A2 (de) 2002-10-09
CN1416635A (zh) 2003-05-07
CN1183733C (zh) 2005-01-05
US20090040988A1 (en) 2009-02-12
ATE299328T1 (de) 2005-07-15
ES2244630T3 (es) 2005-12-16
JP2003520501A (ja) 2003-07-02
WO2001052499A3 (en) 2002-01-24
AU2937501A (en) 2001-07-24
JP4741145B2 (ja) 2011-08-03
DE60111823D1 (de) 2005-08-11
WO2001052499A2 (en) 2001-07-19
US6775553B1 (en) 2004-08-10

Similar Documents

Publication Publication Date Title
DE60111823T2 (de) Verfahren zur vermeidung von ppp-zeitrüberschreitungen während ipcp-verhandlungen
DE60031673T2 (de) Aufbau eines paketnetzrufes zwischen einem mobilen endgerät und einer anpassungsfunktion
DE60032229T2 (de) Automatische ip adressvergabe für mobilfunkendgeräte
DE60109269T2 (de) Universalles Mobil-Telekommunikationssystem (UMTS) Dienstqualität (QoS) zur Unterstützung die Verhandlung des einstellbaren Dienstqualitätes
DE60316751T2 (de) Verfahren zur Bestimmung der Wiederherstellung der RLC Entität während der SRNS Relocation
DE60214144T2 (de) Verfahren und Vorrichtung zur bereitstellung von unterschiedlichen Dienstqualitätsstufen in einer Funkpaketdatendienstverbindung
DE19800772C2 (de) Verfahren und Vorrichtung zur Verbindung mit einem Paketaustauschnetz
EP1282997B1 (de) Verfahren zum umlegen eines tunnels zwischen knoten eines gprs-systems
DE60307604T2 (de) Verfahren und vorrichtung zum durchführen des weiterreichens in einem kommunikationssystem mit unterstützung von mehreren dienstinstanzen
DE69533740T2 (de) TCP/IP-Kopfendekompression in X.25-Netzwerken
DE60216791T2 (de) Adressenübergang und korrelation von nachrichten zwischen netzknoten
DE60037834T2 (de) Mobiles endgerät und ip-netzzugangspunkt
DE60219163T2 (de) Verfahren und vorrichtung zum sanften weiterreichen zwischen basisstationen, die unterschiedliche rahmenformats benutzen
DE19742681C2 (de) GPRS-Teilnehmerauswahl von mehreren Internet-Dienstanbietern
DE69924103T2 (de) Verfahren und netzwerk zur verwaltung von wsp (wireless session protocol) sitzungen
DE60031649T2 (de) Automatisches aufrufen von ip-mobilanmeldung in einem drahtlosen kommunikationsnetz
DE60028862T2 (de) System zum Aufbau einer Datenverbindung in drahtlosen Netzwerken
DE69829346T2 (de) Ein-/Ausgabevorrichtung für ein Peripheriegerät
DE10302788B4 (de) Einrichtung und Verfahren zum Umordnen von TFTs in einem Mobilkommunikationssystem
DE60106457T2 (de) Zuteilung von datenübertragungsbetriebsmitteln bei der paketvermittelten datenübertragung
DE60130247T2 (de) Senden von nachrichten in einem telekommunikationssystem mit einem paketfunknetzwerk
WO2001030042A2 (de) Verfahren zum betreiben eines mobilfunknetzes
DE10039429A1 (de) Verfahren zur Signalübertragung in einem Funk-Kommunikationssystem
DE10105093A1 (de) Paging-Verfahren und -System für ein Funkzugriffsnetz
DE69920570T2 (de) Integriertes Zweite Schicht Zugriffsschema

Legal Events

Date Code Title Description
8364 No opposition during term of opposition