DE60034193T2 - Datenumsetzungsgeräte und -verfahren - Google Patents

Datenumsetzungsgeräte und -verfahren Download PDF

Info

Publication number
DE60034193T2
DE60034193T2 DE60034193T DE60034193T DE60034193T2 DE 60034193 T2 DE60034193 T2 DE 60034193T2 DE 60034193 T DE60034193 T DE 60034193T DE 60034193 T DE60034193 T DE 60034193T DE 60034193 T2 DE60034193 T2 DE 60034193T2
Authority
DE
Germany
Prior art keywords
data
packet
dte
octet
ppp
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
DE60034193T
Other languages
English (en)
Other versions
DE60034193D1 (de
Inventor
Keizaburo Yokosuka-shi Sasaki
Hiroyuki Yokohama-shi Hattori
Noriko Yokosuka-shi Niizato
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.)
NTT Docomo Inc
Original Assignee
NTT Docomo 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
Priority claimed from JP26686299A external-priority patent/JP3689279B2/ja
Priority claimed from JP2000118620A external-priority patent/JP3793393B2/ja
Application filed by NTT Docomo Inc filed Critical NTT Docomo Inc
Publication of DE60034193D1 publication Critical patent/DE60034193D1/de
Application granted granted Critical
Publication of DE60034193T2 publication Critical patent/DE60034193T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/03Protocol definition or specification 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Description

  • Die Erfindung bezieht sich auf eine Datenumsetzungsvorrichtung, ein Signal, ein Datenumsetzungsverfahren, eine DCE ("Data Circuitterminating Equipment": Datenleitung-Abschlusseinrichtung bzw. Datenübertragungseinrichtung), ein Gateway bzw. einen Netzübergang und eine Kommunikationsvorrichtung. Genauer gesagt bezieht sich die Erfindung auf eine Datenumsetzungsvorrichtung, usw. zum Verhindern einer Oktett-/Bit-Einfügung in einem Abschnitt, der keine Oktett-Einfügung oder Bit-Einfügung (was hierin nachstehend als "Oktett-/Bit-Einfügung" bezeichnet wird) erfordert, während einer Kommunikation auf der Grundlage von PPP ("Point-to-Point Protocol": Punkt-zu-Punkt-Protokoll). Die Erfindung bezieht sich weiterhin auf eine Kommunikationsvorrichtung, die ein Steuerpaket auf der Kommunikationsverbindung reduziert.
  • PPP liegt als ein Sicherungsschichtprotokoll des OSI-Referenzmodells vor. PPP ist ein Bit-/Byte-synchrones und ein asynchrones Verbindungssteuerprotokoll über eine serielle Leitung bzw. Schaltung. PPP ist in RFC ("Request for Comments") 1661 und RFC 1662 von der IETF ("Internet Engineering Task Force") spezifiziert.
  • 1 ist eine Darstellung, die eine PPP-Rahmenkonfiguration (Rahmenformat) zeigt. Der PPP-Rahmen umfasst ein Flag- bzw. Markierungszeichenfeld, ein Adressfeld, ein Steuerfeld, ein Protokollfeld, ein Informationsfeld und ein FCS-Feld. Die Anzahl von Bytes von jeweiligen Feldern beträgt 1 Byte für das Flag- bzw.
  • Markierungszeichenfeld, 1 Byte für das Adressfeld, 1 Byte für das Steuerfeld, 1 oder 2 Bytes für das Protokollfeld und 2 oder 4 Bytes für das FCS-Feld. Das Adressfeld und das Steuerfeld können mitunter durch eine Aus- bzw. Verhandlung von LCP-("Link Control Protocol": Verbindungssteuerprotokoll) ACFC ("Address and Control Field Compression": Adress- und Steuerfeld-Komprimierung) komprimiert werden. Weiterhin kann das Protokollfeld mitunter durch eine LCPPFC-("Protocol Field Compression": Protokollfeldkomprimierung) Aus- bzw. Verhandlung komprimiert werden. Des Weiteren kann das FCS-("Frame Check Sequence": Rahmenprüfsequenz) Feld mitunter durch eine LCPFCS-Aus- bzw. Verhandlung komprimiert werden.
  • 2 ist eine Darstellung, die ein Beispiel einer Kommunikation zwischen DTEs ("Data Terminal Equipment": Datenendeinrichtung) über ein Kommunikationsnetzwerk und ein PSTN ("Public Switched Telephone Network": Telefonnetz) zeigt. Gemäß 2 bilden eine Vermittlung 8 und ein Netzübergang 10 ein Kommunikationsnetzwerk 5. DTE 2 und DTE 14 führen eine Kommunikation über DCE 4, Vermittlung 8, Netzübergang 10 und PSTN 12 durch. Das Kommunikationsnetzwerk 5 kann zum Beispiel ein Mobilkommunikationsnetzwerk sein und DCE 4 kann zum Beispiel eine Mobilstation sein.
  • In diesem Fall wird angenommen, dass eine Datenkommunikation zwischen DTE 2 und DTE 14 auf der Grundlage von PPP durchgeführt wird. Vordem wurde, wenn ein Datensignal von DTE 2 zu DTE 14 übertragen wird, das Datensignal nach Durchführung einer Oktett-/Bit-Einfügung an DTE 2 übertragen. Ferner wurde an dem empfangenen Datensignal an DTE 14 eine Oktettlöschung oder eine Bitlöschung (was hierin nachstehend als "Oktett-/Bit- Löschung" bezeichnet wird) durchgeführt. Andererseits wurde, wenn ein Datensignal von DTE 14 zu DTE 2 übertragen wird, an DTE 14 eine Oktett-/Bit-Einfügung durchgeführt, und an DTE 2 eine Oktett-/Bit-Löschung.
  • Ferner wird ebenso angenommen, dass zwischen DTE 2 und einem bestimmten Punkt (Punkt zum Abschluss von PPP) in dem Netzwerk nur eine Datenkommunikation auf der Grundlage von PPP durchgeführt wird. Als der bestimmte Punkt in dem Netzwerk wird zum Beispiel die Vermittlung 8, der Netzübergang 10 oder dergleichen betrachtet. Hier wird eine Beschreibung für einen Fall vorgenommen, bei dem der Netzübergang 10 der Abschlusspunkt ist. In der Vergangenheit wurde, wenn ein Datensignal von DTE 2 zu DTE 14 übertragen wird, an DTE 2 eine Oktett-/Bit-Einfügung durchgeführt, an Netzübergang 10 eine Oktett-/Bit-Löschung an dem empfangenen Datensignal durchgeführt, und dann das Datensignal zu DTE 14 übertragen. Andererseits wurde, wenn ein Datensignal von DTE 14 zu DTE 2 übertragen wird, an Netzübergang 10 eine Oktett-/Bit-Einfügung durchgeführt und an DTE 2 eine Oktett-/Bit-Löschung durchgeführt.
  • Bei einer Datenkommunikation basierend auf PPP gemäß dem Stand der Technik wird jedoch selbst in einem Abschnitt, der keine Oktett-/Bit-Einfügung erfordert, ein Datensignal in dem Oktett-/Bit-Einfügungszustand übertragen und empfangen. Es wird zum Beispiel angenommen, dass eine Oktett-/Bit-Einfügung in dem Abschnitt zwischen DCE 4 und Netzübergang 10 gemäß 2 unnötig ist, wobei jedoch gemäß dem Stand der Technik selbst in diesem Abschnitt eine Oktett-/Bit-Einfügung vorgenommen wurde. Wenn eine Oktett-/Bit-Einfügung vorgenommen wird, wird eine Datenübertragungsmenge erhöht und wird ein Durchsatz verschlechtert. Oktetteinfügung bedeutet zum Beispiel, dass spezielle Daten mit 1 Byte mit einem 1 Byte-Escape-Zeichen (1 Byte) Escapeverarbeitet werden, um Daten mit 2 Bytes zu bilden (was nachstehend unter Bezugnahme auf 9 näher beschrieben ist). Ferner wird Biteinfügung unter Verwendung eines Beispiels beschrieben, wenn ein Flag- bzw. Markierungszeichen ("01111110" in binärer Notation) von einem anderen Datenteil zu unterscheiden ist, wobei bei einer Biteinfügung bei Daten mit Ausnahme das Flag- bzw. Markierungszeichens, wenn fünf "1s" aufeinander folgen, nach den Daten eine "0" eingefügt wird.
  • Im Übrigen wird PPP ("Point-to-Point Protocol") häufig als ein DTE-Sicherungsschichtprotokoll verwendet, das zum Zweck einer Verbindung mit einem Internet/Intranet über ein öffentliches Kommunikationsnetzwerk oder ein privates Kommunikationsnetzwerk verwendet wird.
  • PPP ermöglicht eine Übermittlung von verschiedenen Netzwerkprotokollen wie etwa IP (Internet-Protokoll), Appletalk und dergleichen. Die PPP-Spezifikationen sind als RFC ("Request For Comments") von der IETF ("Internet Engineering Task Force") spezifiziert.
  • 17 ist eine Darstellung, die ein Kommunikationsbeispiel zeigt. Bei dem Beispiel von 17 führen eine DTE (Datenendeinrichtung) 52 und eine DTE 60 eine Kommunikation über eine DCE (Datenleitung-Abschlusseinrichtung) 54, ein Netzwerk 56 und eine DCE 58 durch. Hierbei können die DCE 54 und die DCE 58 zum Beispiel Mobilstationen (tragbare Telefone) sein.
  • 18 zeigt ein PPP-Rahmenformat. Ein Flag stellt einen Beginn oder ein Ende von PPP dar und wird zum Identifizieren einer Rahmenaufteilung bzw. -partition verwendet. Ein Adressfeld bildet Informationen, die eine Adresse von diesem PPP-Rahmen darstellen, für die im Allgemeinen ein fester Wert verwendet wird. Ein Steuerfeld bildet Informationen, die zum Identifizieren eines Rahmentyps verwendet werden, für den im Allgemeinen ein fester Wert verwendet wird. Ein Protokollfeld wird zum Identifizieren des Protokolls eines in dem Informationsfeld enthaltenen Pakets verwendet, und ein in dem Protokollfeld angezeigtes Protokollpaket ist in dem Informationsfeld enthalten. FCS (Rahmenprüfsequenz) wird verwendet, um eine Fehlererkennung von dem Adressfeld bis zu dem Informationsfeld durchzuführen.
  • 19 zeigt einen PPP-Verfahrensablauf. PPP geht in eine Verbindungsaufbauphase über, wenn eine physikalische Schicht in einer Verbindungsunterbrechungsphase einsetzt. In der Verbindungsaufbauphase wird ein Verbindungseinstellvorgang von LCP (Verbindungssteuerprotokoll) durchgeführt, nachdem ein LCP-Verbindungsaufbau in eine Verifikationsphase übergeht, in der je nach Bedarf ein Verifikationsvorgang durchgeführt wird. Ist eine Verifikation erfolgreich, geht PPP in eine Netzwerkschichtprotokollphase über, in der ein NCP-Verbindungseinstellvorgang entsprechend jedem Netzwerkprotokoll durchgeführt wird. Wenn jede NCP-Verbindung aufgebaut ist, wird ein Paket von einem Netzwerkprotokoll entsprechend jedem NCP übermittelbar. Ferner geht PPP durch eine Kommunikationsendeanforderung oder dergleichen in eine Verbindungsendephase über. LCP weist an, ein Endeanforderungspaket zu übertragen, wenn dessen Identifikationspaket empfangen wird, so dass eine PPP-Verbindung beendet und die physikalische Schicht getrennt wird. Ferner wird eine Beendigung der PPP-Verbindung an die Netzwerkschicht gemeldet. Wird die physikalische Schicht getrennt, kehrt PPP in die Verbindungsunterbrechungsphase zurück.
  • Gemäß 20 ist eine LCP- oder NCP-Verbindungsaufbauabfolge gezeigt. Hierbei besteht eine Verbindungsaufbaubedingung darin, dass Knoten A und Knoten B jeweilige Einstellidentifikationspakte übertragen und empfangen. In jeweiligen Paketen wird ID für eine Entsprechung von einem Einstellanforderungspaket mit einem Antwortpaket (Einstellidentifikationspaket, Einstellverneinungspaket oder Einstellzurückweisungspaket) verwendet, und ein in dem Anforderungspaket empfangener ID-Wert ist in dem ID-Wert des Antwortpakets enthalten. Wird ein Einstellanforderungspaket übertragen, kann eine Option (Opt_A~G) bezeichnet werden.
  • Wenn alle Optionen, die in dem Einstellanforderungspaket enthalten sind, erkannt werden können und diese Werte tolerierbar bzw. zulässig sind, akzeptiert eine Empfangsseite des Einstellanforderungspakets alle Optionen, die in dem Einstellanforderungspaket enthalten sind, in dem Einstellidentifikationspaket, und übt sie eine Antwort bzw. Reaktion aus.
  • Wenn in Optionen, die in dem Einstellanforderungspaket enthalten sind, eine nicht erkennbare Option vorhanden ist, führt die Einstellanforderungspaket-Empfangsseite in dem Einstellzurückweisungspaket eine Antwort durch, die die nicht erkennbare Option enthält.
  • Wenn alle Optionen erkennbar sind, die in dem Einstellanforderungspaket enthalten sind, jedoch nicht tolerierbare bzw. unzulässige Optionswerte existieren, bindet die Einstellanforderungspaket-Empfangsseite in dem Einstellverneinungspaket nur Optionen mit nicht tolerierbaren bzw, unzulässigen Werten ein, ändert jedoch diese Optionen in tolerierbare bzw. zulässige Werte und übt eine Antwort bzw. Reaktion aus. Wenn Optionen abgesehen von denjenigen, die in dem Einstellanforderungspaket enthalten sind, an der Einstellanforderungspaket-Sendeseite anzufordern sind, können diese Optionen ferner ebenfalls an das Paket angefügt werden.
  • Wird ein Einstellzurückweisungspaket empfangen, werden solche zurückgewiesenen Optionen entfernt, und überträgt die Einstellanforderungspaket-Sendeseite dann das Einstellanforderungspaket erneut.
  • Wird ein Einstellverneinungspaket empfangen, wird von der Einstellanforderungspaket-Sendeseite ein Einstellanforderungspaket mit Optionswerten übertragen, die auf diejenigen geändert sind, die in dem Einstellverneinungspaket enthalten sind. Wenn in den Optionen des Einstellverneinungspakets eine Vielzahl von Werten existiert, wird jedoch einer von diesen ausgewählt.
  • Unter Bezugnahme auf 20 wird ein Beispiel eines Verhandlungsverfahrensablaufs bis zu einem LCP- oder NCP-Verbindungsaufbau beschrieben.
    • (a) Ein Einstellanforderungs-(Konfigurationsanforderungs-)Paket wurde von Knoten A an Knoten B übertragen, ist jedoch bei der Übertragung auf halbem Weg verloren gegangen.
    • (b) Knoten A hat das Einstellanforderungspaket erneut übertragen, weil eine bestimmte Zeitdauer lang kein Antwortpaket auf das Einstellanforderungspaket von (a) empfangen wird. Zu diesem Zeitpunkt wurde nur der ID-Wert auf einen Wert eingestellt, der von dem Einstellungsanforderungspaket von (a) abweicht.
    • (c) Ein Einstellanforderungspaket wurde von Knoten B an Knoten A übertragen, ist jedoch bei der Übertragung auf halbem Weg verloren gegangen.
    • (d) Knoten B hat, weil Optionen Opt_C, Opt_D und Opt_E in dem Einstellanforderungspaket von (b) nicht erkannt werden können, eine Antwort, die diese Optionen enthält, in dem Einstellzurückweisungs-(Konfigurationszurückweisungs-)Paket ausgeübt.
    • (e) Knoten A hat Optionen Opt_C, Opt_D und Opt_E in dem empfangenen Einstellzurückweisungspaket von (d) entfernt, den ID-Wert geändert und dann ein Einstellanforderungspaket übertragen.
    • (f) Knoten B hat, weil alle Optionen in dem empfangenen Einstallanforderungspaket von (e) erkennbar waren und diese Werte alle tolerierbar bzw. zulässig sind, in dem Einstellidentifikations-(Konfigurations-ack-(Bestätigung)) Paket eine Antwort ausgeübt, die alle Optionen in dem Einstellanforderungspaket enthält.
    • (g) Knoten B hat, weil eine bestimmte Zeitdauer lang kein Antwortpaket auf das Einstellanforderungspaket von (c) empfangen wird, erneut das Einstellanforderungspaket mit dem gleichen Format wie das Einstellanforderungspaket von (c) übertragen.
    • (h) Knoten A hat, weil Option Opt_G in dem Einstellanforderungspaket von (g) nicht erkannt werden kann, in dem Einstellzurückweisungspaket eine Antwort ausgeübt, die diese Option enthält.
    • (i) Knoten B hat die Option Opt_G in dem empfangenen Einstellzurückweisungspaket von (h) entfernt, den ID-Wert geändert und das Einstellanforderungspaket übertragen.
    • (j) Knoten A hat, weil Wert w2 der Option Opt_A in dem Einstellanforderungspaket von (i) tolerierbar ist, jedoch Wert z1 der Option Opt_F nicht tolerierbar ist und es tolerierbar ist, wenn der Wert z2 ist, in dem Einstellverneinungs-(Konfigurations-nak-(negative Bestätigung)) Paket den Wert von Opt_F auf z2 geändert und dieses übertragen.
    • (k) Knoten B hat Option Opt_F in dem empfangenen Einstellverneinungspaket von (j) geändert und das Einstellanforderungspaket übertragen.
    • (l) Knoten A hat, weil in dem empfangenen Einstellanforderungspaket von (k) alle Optionen erkannt werden können und diese Werte alle tolerierbar sind, in dem Einstellidentifikationspaket eine Antwort ausgeübt, die alle Optionen in dem Einstellanforderungspaket enthält.
  • Gemäß 21 ist ein Beispiel einer LCP-Verbindungstrennungsabfolge gezeigt.
    • (a) Knoten A hat ein Endeanforderungs-(Abschlussanforderungs-)Paket übertragen, um eine Verbindungsfreigabe anzufordern.
    • (b) Auf Empfang des Endeanforderungspakets hat Knoten B das Endeidentifikations-(Abschluss-ack-)Paket übertragen. Knoten A, der das Endeidentifiktionspaket empfängt, ist in einen Verbindungsschlusszustand übergegangen.
    • (c) Nachdem er eine bestimmte Zeit lang seit der Endeidentifikationspaket-Übertragung gewartet hat, hat Knoten B ein Endeanforderungspaket übertragen.
    • (d) Auf Empfang des Endeanforderungspakets hat Knoten A das Endeidentifikationspaket übertragen, die physikalische Schicht getrennt, und ist in die Verbindungsunterbrechungsphase übergegangen. Der Knoten B, der das Endeidentifikationspaket empfängt, ist in einen Verbindungsschlusszustand übergegangen, hat die physikalische Schicht getrennt, und ist in die Verbindungsunterbrechungsphase übergegangen.
  • 22 zeigt ein Beispiel einer Aufrechterhaltungsabfolge unter Verwendung eines LCP-Echoanforderungs-/-antwortpakets.
  • Das LCP-Echoanforderungs-/-antwortpaket wird während eines LCP-Verbindungsaufbaus verwendet und kann zur Bestimmung verwendet werden, ob die Verbindung beibehalten wird oder nicht.
    • (a) Knoten A hat ein LCP-Echoanforderungspaket übertragen, um zu bestätigen, ob eine LCP-Verbindung aufrechterhalten wird oder nicht.
    • (b) Auf Empfang des LCP-Echoanforderungspakets hat Knoten B ein LCP-Echoantwort-(Echorückmeldungs-)Paket übertragen, um zu antworten, dass die Verbindung aufrechterhalten wird.
    • (c) Knoten B hat ein LCP-Echoanforderungspaket übertragen, um zu bestätigen, ob eine LCP-Verbindung aufrechterhalten wird oder nicht.
    • (d) Auf Empfang des LCP-Echoanforderungspakets hat Knoten A ein LCP-Echoantwortpaket übertragen, um zu antworten, dass die Verbindung aufrechterhalten wird.
  • Als eine der Eigenschaften einer Paketkommunikation existiert, da die Kommunikationsleitung nur verwendet wird, wenn Daten erzeugt werden, ein Kommunikationsknoten, in dem eine Anwendung eines Kommunikationsgebührensystems basierend auf der Datenmenge möglich ist. Als ein Erfordernis in einem solchen Kommunikationsknoten ist es wünschenswert, dass keine Kommunikationsgebühr gefordert wird, wenn keine zu kommunizierenden Nutzerdaten existieren, das heißt, die Kommunikationsleitung tatsächlich nicht verwendet wird.
  • Wird PPP als DTE-Sicherungsschichtprotokoll in einem Kommunikationsknoten verwendet, der ein Kommunikationstarifsystem basierend auf der Datenmenge anwendet, hat es in der Vergangenheit durch Übermittlung von PPP-Steuerpaketen zu der Kommunikationsanfangszeit und der Kommunikationsendzeit, eines LCP-Echoanforderungs-/-antwortpakets zur periodischen Vorname einer Fortbestandsbetätigung einer PPP-Verbindung und dergleichen Probleme gegeben, dass aus Sicht des Nutzers ein zusätzlicher Kommunikationstarif erforderlich ist, und dass aus Sicht des Kommunikationsunternehmens Kommunikationskosten und Kommunikationsverkehrsmenge zum Ansteigen neigen.
  • Der Artikel von Doshi et al: "A Simple Data Link Protocol for High-Speed Packet Networks", Bell Labs Technical Journal, Wiley, CA, US, Vol. 4, Nr. 1, 1999, Seiten 85 bis 104 (D1) offenbart ein Protokoll zur Rahmenbildung von asynchronen Protokolldateneinheiten über einen universellen Punkt-zu-Punkt-Kommunikationskanal unter Verwendung eines einfachen Datenverbindungsprotokolls (SDL). Das SDL-Rahmenformat kann einen Längenindikator zum Bezeichnen der Länge des Informationsfeldes in Bytes enthalten. Der Artikel stellt die Probleme bei einem Rahmenbildungsmechanismus einer Datenverbindungssteuerung hoher Ebene (HDLC) heraus, bei dem Protokolldateneinheiten mit Hilfe eines speziellen Bitmusters oder Flag bzw. Markierungszeichens abgegrenzt werden, aber fährt damit fort, ein SDL-Protokoll als ein alternatives Rahmenbildungsprotokoll vorzuschlagen.
  • Es ist daher eine Aufgabe der Erfindung, eine Oktett-/Bit-Einfügung in einem Abschnitt, der keine Oktett-/Bit-Einfügung erfordert, während einer Datenkommunikation basierend auf PPP zu verhindern, so dass eine Datenübertragungsmenge reduziert wird, wodurch der Durchsatz verbessert wird.
  • Eine weitere Aufgabe der Erfindung besteht darin, das Steuerpaket auf der Kommunikationsleitung zu reduzieren. Mit dieser Konfiguration können eine Reduktion von Kommunikationsgebühr/Kommunikationskosten und eine mit der Kommunikationsverkehrsmengenreduktion in Zusammenhang stehende Erhöhung der Teilnehmerkapazität erreicht werden.
  • Gemäß einem ersten Aspekt der Erfindung ist ein Datenumsetzungsverfahren in einer dritten Kommunikationsvorrichtung bereitgestellt, die sich zwischen einer ersten Kommunikationsvorrichtung und einer zweiten Kommunikationsvorrichtung befindet, die eine Datenkommunikation mit der ersten Kommunikationsvorrichtung basierend auf PPP durchführt, wobei das Datenumsetzungsverfahren aufweist:
    einen Empfangsschritt zum Empfangen von ersten Daten von der ersten Kommunikationsvorrichtung;
    einen Datenumsetzungsschritt zum Umsetzen der ersten Daten in zweite Daten; und
    einen Übertragungsschritt zum Übertragen der zweiten Daten in Richtung der zweiten Komunikationsvorrichtung,
    wobei die ersten Daten Daten mit Oktett-Einfügung oder Bit-Einfügung sind und die zweiten Daten Daten ohne Oktett-Einfügung und ohne Bit-Einfügung sind, und
    die Daten ohne Oktett-Einfügung und ohne Bit-Einfügung eine Rahmenkonfiguration aufweisen, bei der zusätzliche Informationen einschließlich Informationen zum Identifizieren einer Rahmenaufteilung zu einer PPP-Rahmenkonfiguration hinzugefügt sind, oder eine Rahmenkonfiguration aufweisen, bei der zusätzliche Informationen einschließlich Informationen zum Identifizieren einer Rahmenaufteilung zu einer Rahmenkonfiguration mit Flag-Löschung gegenüber einer PPP-Rahmenkonfiguration hinzugefügt sind, und
    die Informationen zum Identifizieren eine Rahmenlänge darstellen.
  • Mit der vorstehenden Konfiguration wird während einer PPP-basierten Kommunikation in einem Abschnitt, der eine Oktett-/Bit-Einfügung nicht erfordert, keine Oktett-/Bit-Einfügung durchgeführt, so dass eine Datenübertragungsmenge reduziert wird, wodurch der Durchsatz verbessert wird. Kann die Datenübertragungsmenge reduziert werden, können die Nutzer mit verschiedenen Diensten zu niedrigen Kosten ausgestattet werden.
  • Ferner kann ein Steuerpaket auf der Kommunikationsleitung reduziert werden.
  • Die vorstehenden und weitere Aufgaben, Wirkungen, Merkmale und Vorteile der Erfindung werden aus der folgenden Beschreibung von Ausführungsbeispielen von dieser in Verbindung mit der zugehörigen Zeichnung deutlicher.
  • 1 ist eine Darstellung, die einen PPP-Rahmenaufbau zeigt;
  • 2 ist eine Darstellung, die ein Beispiel einer Kommunikation zwischen DTEs über ein Kommunikationsnetzwerk und ein PSTN zeigt;
  • 3 ist eine Darstellung, die ein Beispiel eines verbesserten Rahmenaufbaus gemäß einem ersten Ausführungsbeispiel der Erfindung zeigt;
  • 4 ist eine Darstellung zur Erläuterung einer Datenkommunikation zwischen DTE 2 und DTE 14;
  • 5 ist eine Darstellung, die ein Aufbaubeispiel einer ersten Datenumsetzungsvorrichtung zeigt;
  • 6 ist eine Darstellung, die ein Aufbaubeispiel einer zweiten Datenumsetzungsvorrichtung zeigt;
  • 7 ist eine Darstellung, die ein Verhandlungsverarbeitungsbeispiel zeigt, wenn Daten in DTE 2 erzeugt werden;
  • 8 ist eine Darstellung, die ein Verarbeitungsbeispiel von DTE 2 und DCE 4 zeigt, wenn Daten von DTE 2 zu DTE 14 übermittelt werden;
  • 9 ist eine Darstellung, die ein praktisches Beispiel einer Oktett-Einfügungsverarbeitung zeigt, die in DTE 2 durchgeführt wird;
  • 10 ist eine Darstellung, die ein praktisches Beispiel einer Oktett-Löschungsverarbeitung zeigt, die in DCE 4 durchgeführt wird;
  • 11 ist eine Darstellung, die ein Verarbeitungsbeispiel von DTE 2 und DCE 4 zeigt, wenn Daten von DTE 14 zu DTE 2 übermittelt werden;
  • 12 ist eine Darstellung, die ein praktisches Beispiel einer Oktett-Einfügungsverarbeitung zeigt, die in DCE 4 durchgeführt wird;
  • 13 ist eine Darstellung, die ein praktisches Beispiel einer Oktett-Löschungsverarbeitung zeigt, die in DTE 2 durchgeführt wird;
  • 14 ist eine Darstellung zur Erläuterung einer Datenkommunikation zwischen DTE 2 und Netzübergang 10;
  • 15 ist eine Darstellung zur Erläuterung einer Bit-Einfügung;
  • 16 ist eine Darstellung zur Erläuterung einer in DCE durchgeführten Verarbeitung;
  • 17 ist eine Darstellung, die ein Kommunikationsbeispiel zeigt;
  • 18 ist eine Erläuterungsdarstellung, die einen Feldaufbau eines PPP-Rahmens zeigt;
  • 19 ist eine Erläuterungsdarstellung, die einen Überblick eines PPP-Verfahrensablaufs zeigt;
  • 20 ist ein Ablaufdiagramm, das ein Beispiel einer PPP-Verbindungsaufbauabfolge zeigt;
  • 21 ist ein Ablaufdiagramm, das ein Beispiel einer PPP-Verbindungstrennungsabfolge zeigt;
  • 22 ist ein Ablaufdiagramm, das einen PPP-Aufrechterhaltungsbetrieb zeigt;
  • 23 ist ein Ablaufdiagramm, wenn die Erfindung auf das Verbindungsaufbauabfolgebeispiel gemäß 20 angewandt wird;
  • 24 ist ein Ablaufdiagramm, wenn die Erfindung auf das Verbindungstrennungsabfolgebeispiel gemäß 21 angewandt wird; und
  • 25 ist ein Ablaufdiagramm, wenn die Erfindung auf das Aufrechterhaltungsabfolgebeispiel gemäß 22 angewandt wird.
  • Im Folgenden werden unter Bezugnahme auf die Zeichnung Ausführungsbeispiele der Erfindung ausführlich beschrieben.
  • Bei dem ersten und dem zweiten Ausführungsbeispiel wird ein Beispiel einer Kommunikation zwischen DTEs über das Kommunikationsnetzwerk und PSTN beschrieben, die gemäß 2 gezeigt sind.
  • [Erstes Ausführungsbeispiel]
  • Bei dem ersten Ausführungsbeispiel der Erfindung wird eine Datenkommunikation zwischen DTE 2 und DTE 14 auf der Grundlage von PPP durchgeführt.
  • 3 ist eine Darstellung, die ein Beispiel eines verbesserten PPP-Rahmenaufbaus gemäß dem vorliegenden Ausführungsbeispiel zeigt. Der verbesserte PPP-Rahmen umfasst ein Zusatzinformationsfeld, ein Adressfeld, ein Steuerungsfeld, ein Protokollfeld, ein Informationsfeld und ein FCS-Feld. Das heißt, der Rahmen weist einen Rahmenaufbau auf, bei dem zusätzliche Informationen zu einem Rahmenaufbau hinzugefügt sind, wobei das Flag bzw. Markierungszeichen aus dem PPP-Rahmenaufbau gelöscht ist. Die zusätzlichen Informationen umfassen Identifikationsinformationen zum Identifizieren einer Rahmenaufteilung bzw. -partition. Bei dem vorliegenden Ausführungsbeispiel wird eine Rahmenlänge (Anzahl von Bytes des Rahmens) als die Identifikationsinformation verwendet.
  • Ferner kann auch ein Rahmenaufbau verwendet werden, wobei zu dem Rahmenaufbau gemäß 3 ein Flag bzw. Markierungszeichen hinzugefügt ist. Das heißt, es ist auch möglich, dass keine Löschung das Flag bzw. Markierungszeichens aus dem PPP-Rahmenaufbau vorgenommen wird, sondern lediglich die Zusatzinformationen hinzugefügt werden.
  • 4 ist eine Darstellung zur Erläuterung einer Datenkommunikation zwischen DTE 2 und DTE 14. Wird ein Datensignal von DTE 2 zu DTE 14 übertragen, wird in DTE 2 eine Oktett-Einfügung zu den Daten wie bei dem Stand der Technik durchgeführt, und wird dann das Ergebnis übertragen. In DCE 4 wird eine spezielle Verarbeitung (wobei diese Verarbeitung nachstehend beschrieben ist) durchgeführt, bei der die Daten mit dem PPP-Rahmenaufbau und einer Oktett-Einfügung in Daten umgesetzt bzw. gewandelt werden, die einen verbesserten Rahmenaufbau aufweisen (3) und keine Oktett-Einfügung aufweisen. In dem Netzübergang bzw. Gateway 10 (der gemäß 4 mit NW bezeichnet ist) wird eine spezielle Verarbeitung durchgeführt, wodurch die Daten mit dem verbesserten PPP-Rahmenaufbau und ohne Oktett-Einfügung in Daten umgesetzt bzw. gewandelt werden, die den PPP-Rahmenaufbau aufweisen und eine Oktett-Einfügung aufweisen. Nach der Datenumsetzung überträgt der Netzübergang 10 das die umgesetzten Daten enthaltende Signal an DTE 14. Dann wird wie gemäß dem Stand der Technik in DTE 14 eine Oktett-Löschung durchgeführt.
  • Wird andererseits ein Datensignal von DTE 14 zu DTE 2 übertragen, wird in DTE 14 eine Oktett-Einfügung zu den Daten wie bei dem Stand der Technik durchgeführt, und werden die Daten übertragen. In dem Netzübergang bzw. Gateway 10 wird eine spezielle Verarbeitung durchgeführt, bei der die Daten mit dem PPP-Rahmenaufbau und einer Oktett-Einfügung in Daten umgesetzt bzw. gewandelt werden, die einen verbesserten Rahmenaufbau aufweisen und keine Oktett-Einfügung aufweisen. In DCE 4 wird eine spezielle Verarbeitung durchgeführt, wodurch die Daten mit dem verbesserten PPP-Rahmenaufbau und ohne Oktett-Einfügung in Daten umgesetzt bzw. gewandelt werden, die den PPP-Rahmenaufbau aufweisen und eine Oktett-Einfügung aufweisen. Dann wird wie gemäß dem Stand der Technik in DTE 2 eine Oktett-Löschung durchgeführt.
  • Wie vorstehend beschrieben wird zwischen DTE 4 und Netzübergang 10 ein Signal übertragen, das Daten enthält, die den gemäß 3 gezeigten verbesserten PPP-Rahmenaufbau aufweisen und keine Oktett-Einfügung aufweisen. Mit diesem Verfahren wird eine Datenübertragungsmenge reduziert und der Durchsatz verbessert.
  • In DCE 4 und Netzübergang 10 sind eine erste Datenumsetzungsvorrichtung 20 und eine zweite Datenumsetzungsvorrichtung 30 vorhanden, um die vorstehende spezielle Verarbeitung durchzuführen.
  • 5 ist eine Darstellung, die ein Aufbaubeispiel der ersten Datenumsetzungsvorrichtung zeigt. Die erste Datenumsetzungsvorrichtung 20 umfasst ein Flag-Löschungsbauteil 22, ein Oktett-Löschungsbauteil 24 und ein Zusatzinformation-Hinzufügungsbauteil 26. Wird ein Rahmenaufbau verwendet, bei dem zwischen DCE 4 und Netzübergang 10 zu dem Rahmenaufbau gemäß 3 ein Flag hinzugefügt ist (verbleibt), ist das Flag-Löschungsbauteil 22 nicht erforderlich.
  • 6 ist eine Darstellung, die ein Aufbaubeispiel der zweiten Datenumsetzungsvorrichtung zeigt. Die zweite Datenumsetzungsvorrichtung 30 umfasst ein Zusatzinformation-Löschungsbauteil 32, ein Oktett-Einfügungsbauteil 34 und ein Flag-Hinzufügungsbauteil 36. Wird ein Rahmenaufbau verwendet, bei dem zwischen DCE 4 und Netzübergang 10 zu dem Rahmenaufbau gemäß 3 ein Flag hinzugefügt ist, ist das Flag-Hinzufügungsbauteil 36 nicht erforderlich.
  • 7 ist eine Darstellung, die ein Aus- bzw. Verhandlungsverarbeitungsbeispiel zeigt, wenn Daten in DTE 2 erzeugt werden. DTE 2 überträgt, wenn Daten erzeugt werden, zum Aufbau einer PPP-Verbindung eine LCP-Verbindungseinstellanforderung an einen PPP-Abschluss (DTE 14) ((1) gemäß 7). Der PPP-Abschluss ist DTE 14, kann jedoch Netzübergang 10 oder dergleichen sein. Ein Fall, bei dem der PPP-Abschluss Netzübergang 10 ist, ist bei einem zweiten Ausführungsbeispiel der Erfindung beschrieben. DCE 4 überwacht eine Antwort von LCP und, wenn in der Antwort von der Seite von DTE 14 ACCM ("Async Control Character Map": Async-Steuerzeichenkarte) enthalten ist, speichert sie diese, empfängt sie einen PPP-Rahmen von der Seite der DTE 14 und setzt sie diese bei Übertragung an die Seite von DTE 2 für eine Oktett-Einfügungsverarbeitung ein (7(2)). In der Netzwerkschichtprotokollphase nach der Verifikationsphase (wobei diese ausgelassen werden kann) wird in NCP (Netzwerksteuerprotokoll) eine Verhandlung dessen durchgeführt, was für das Netzwerkschichtprotokoll (zum Beispiel IP (Internet-Protokoll)) verwendet wird (7(3)). Als Ergebnis hiervon wird ein Netzwerkschichtpaket verwendbar. Bei dem vorliegenden Ausführungsbeispiel wird IP als Netzwerkschichtprotokoll verwendet, es kann jedoch ein anderes Protokoll verwendet werden. Danach wird eine Datenübermittelung unter Verwendung eines IP-Pakets durchgeführt (7(4)). Eine Verhandlungsverarbeitung kann, wenn Daten in DTE 14 erzeugt werden, ebenfalls durch die vorstehend beschriebene gleiche Verhandlungsverarbeitung durchgeführt werden.
  • 8 ist eine Darstellung, die ein Verarbeitungsbeispiel von DTE 2 und DCE 4 zeigt, wenn Daten von DTE 2 zu DTE 14 übertragen werden. In DTE 2 werden von der Netzwerkschicht (NW-Schicht) empfangene Daten mit einem Adress-(A), einem Steuerungs-(C), einem Protokoll-(P) und einem FCS-Feld versehen, wird eine Oktett-Einfügungsverarbeitung gemäß LCP-Verhandlung durchgeführt (8(1)), und wird nach Hinzufügung eines Flag-(F) Feldes eine Datenübermittlung durchgeführt. Da hier bei der Oktett-Einfügung eine Verarbeitung einer Aufstockung von 1 Byte auf 2 Bytes durchgeführt wird, sind die Daten nach einer Oktett-Einfügung größer als die ursprünglichen Daten. Vor einer Vollendung einer Verhandlung wird ferner eine Standard-Oktett-Einfügung durchgeführt.
  • In DCE 4 wird durch das Flag-Löschungsbauteil 22 aus von DTE 2 empfangenen Daten ein Datenanteil, der von einem Flag eingefasst ist, entfernt bzw. entnommen (Flag wird gelöscht). In dem Oktett-Löschungsbauteil 24 wird an dem herausgenommenen Datenanteil eine Oktett-Löschungsverarbeitung durchgeführt, die ziemlich das Gegenteil der von DTE 2 durchgeführten Oktett-Einfügungsverarbeitung ist (8(2)). In dem Zusatzinformation-Hinzufügungsbauteil 26 werden zusätzliche Informationen einschließlich Identifikationsinformationen zum Identifizieren der Aufteilung bzw. Partition von diesem 1 Rahmen (Informationen zum Erkennung von diesem 1 Rahmen) hinzugefügt (8(3)). Bei dem vorliegenden Ausführungsbeispiel werden nur Identifikationsinformationen als die zusätzlichen Informationen hinzugefügt. Ferner wird eine Rahmenlänge als die Identifikationsinformation verwendet. Die mit den zusätzlichen Informationen versehenen Daten werden in Richtung von DTE 14 übermittelt.
  • Bei einem Rahmenaufbau, bei dem ein Flag zwischen DCE 4 und Netzübergang 10 in dem Rahmenaufbau gemäß 3 hinzugefügt ist (verbleibt), wird keine Flag-Löschung durch das Flag-Löschungsbauteil 22 durchgeführt.
  • 9 ist eine Darstellung, die ein praktisches Beispiel einer in DTE 2 durchgeführten Oktett-Einfügungsverarbeitung zeigt. Gemäß 9 ist eine Oktett-Einfügungsverarbeitung unter Verwendung eines Beispiels eines Falls gezeigt, bei dem von 00h bis 1Fh (h bezeichnet eine hexadezimale Notation) alle mit einem Escape-Zeichen (7Dh) mittels LCP-Verhandlung Escapeverarbeitet werden. Zusätzlich zu 00h bis 1Fh wird eine Escape-Verarbeitung auch für Escape-Zeichen (7Dh) und Flag-Wert (7Eh) durchgeführt. Bei dem vorliegenden Ausführungsbeispiel wird eine Escape-Verarbeitung durch Hinzufügung eines Escape-Zeichens (7Dh) vor Sachdaten und durch Antivalenzbildung von Sachdaten mit 20h durchgeführt. Wenn zum Beispiel eine Oktett-Einfügungsverarbeitung auf Daten 00h durchgeführt wird, werden Daten 7D20h gebildet. Wenn eine solche Okett-Verarbeitung durchgeführt wird, werden die ursprünglichen Daten mit 1 Byte zu Daten mit 2 Bytes.
  • 10 ist eine Darstellung, die ein praktisches Beispiel einer in DCE 4 durchgeführten Oktett-Löschungsverarbeitung zeigt. Bei der Oktett-Löschungsverarbeitung wird ziemlich die gegenteilige Verarbeitung zu der in DTE 2 durchgeführte Oktett-Einfügungsverarbeitung durchgeführt.
  • 11 ist eine Darstellung, die ein Verarbeitungsbeispiel von DTE 2 und DCE 4 zeigt, wenn Daten von DTE 14 zu DTE 2 übertragen werden. In DCE 4 wird in dem Zusatzinformation-Löschungsbauteil 32 ein Datenanteil abgesehen von den Zusatzinformationen der empfangenen Daten herausgenommen (Zusatzdaten werden gelöscht) (11(1)). In dem Oktett-Löschungsbauteil 34 wird auf den herausgenommenen Daten eine Oktett-Einfügung gemäß einem von LCP durchgeführten ACCM-Verhandlungsergebnis durchgeführt (11(2)), und wird nach Hinzufügung eines Flag in einem Flag-Hinzufügungsbauteil 36 eine Datenübermittlung durchgeführt. Da eine Oktett-Einfügung hier eine Verarbeitung zur Veränderung von 1 Byte in 2 Bytes durchführt, sind die Daten nach Oktett-Einfügung größer als die ursprünglichen Daten. Vor Vollendung einer Verhandlung wird ferner eine Standard-Oktett-Einfügung durchgeführt.
  • Bei Verwendung eines Rahmenaufbaus, bei dem zwischen DCE 4 und Netzübergang 10 ein Flag zu dem Rahmenaufbau gemäß 3 hinzugefügt ist (verbleibt), ist das Flag-Löschungsbauteil 36 nicht erforderlich.
  • In DTE 2 wird wie in der Vergangenheit eine Oktett-Löschungsverarbeitung gemäß dem von LCP durchgeführten ACCM-Verhandlungsergebnis durchgeführt (11(3)).
  • 12 ist eine Darstellung, die ein praktisches Beispiel einer in DCE 4 durchgeführten Oktett-Einfügungsverarbeitung zeigt. Die in DCE 4 durchgeführte Oktett-Einfügungsverarbeitung ist die gleiche wie die in DTE 2 durchgeführte Oktett-Einfügungsverarbeitung (9).
  • 13 ist eine Darstellung, die ein praktisches Beispiel einer in DTE 2 durchgeführten Oktett-Löschungsverarbeitung. In der Oktett-Löschungsverarbeitung wird ziemlich die gegenteilige Verarbeitung zu der in DCE 4 durchgeführten Oktett-Einfügungsverarbeitung durchgeführt.
  • Die Verarbeitung (Oktett-Einfügungsverarbeitung oder dergleichen), die in Netzübergang 10 durchgeführt wird, wenn Daten von DTE 2 zu DTE 14 übermittelt werden, ist die gleiche wie die Verarbeitung, die in DCE 4 durchgeführt wird (11 und 12), wenn Daten von DTE 14 zu DTE 2 übermittelt werden.
  • Ferner ist die Verarbeitung (Oktett-Löschungsverarbeitung oder dergleichen), die in Netzübergang 10 durchgeführt wird, wenn Daten von DTE 14 zu DTE 2 übermittelt werden, die gleiche wie die Verarbeitung, die in DCE 4 durchgeführt wird (8 und 10), wenn Daten von DTE 2 zu DTE 14 übermittelt werden.
  • 16 ist eine Darstellung zur Erläuterung einer in DCE durchgeführten Verarbeitung.
  • Als Codes im LCP-Format gibt es LCP-Echoanforderung (Code: 09h) und LCP-Verwerfungsanforderung (Code: 0Bh).
  • Wenn eine (zum Beispiel DTE 2) von zwei Vorrichtungen, die eine Datenkommunikation gemäß PPP durchführen, eine LCP-Echoanforderung empfängt, die an die andere (zum Beispiel DTE 14) übertragen wird, wird in DCE 4 eine LCP-Echoantwort (Code: 0Ah) an die andere Vorrichtung übertragen. Dies verhindert eine Übertragung einer LCP-Echoanforderung an die andere Vorrichtung (die in der Vergangenheit übertragen wurde), wodurch die Datenübertragungsmenge reduziert wird.
  • Wenn des Weiteren eine von zwei Vorrichtungen, die eine Datenübertragung gemäß PPP durchführen, eine LCP-Verwerfungsanforderung empfängt, wie an die andere übertragen wird, wird in DCE 4 die LCP- Verwerfungsanforderung verworfen (gelöscht). Dies verhindert eine Übertragung einer LCP-Verwerfungsanforderung an die andere Vorrichtung (die in der Vergangenheit übertragen wurde), wodurch die Datenübertragungsmenge reduziert wird.
  • Wenn eine (zum Beispiel DTE 14) von zwei Vorrichtungen, die eine Datenkommunikation gemäß PPP durchführen, eine LCP-Echoanforderung empfängt, die an die andere (zum Beispiel DTE 2) übertragen wird, wird in Netzübergang 10 gleichermaßen eine LCP-Echoantwort an die Vorrichtung übertragen. Dies verhindert eine Übertragung einer LCP-Echoanforderung an die andere Vorrichtung (die in der Vergangenheit übertragen wurde), wodurch die Datenübertragungsmenge reduziert wird.
  • Wenn eine von zwei Vorrichtungen, die eine Datenübertragung gemäß PPP durchführen, eine LCP-Verwerfungsanforderung empfängt, die an die andere übertragen wird, wird in Netzübergang 10 ferner die LCP-Verwerfungsanforderung verworfen (gelöscht). Dies verhindert eine Übertragung einer LCP-Verwerfungsanforderung an die andere Vorrichtung (die in der Vergangenheit übertragen wurde), wodurch die Datenübertragungsmenge reduziert wird.
  • Bei dem vorliegenden Ausführungsbeispiel umfassen DCE 4 und Netzübergang 10 die erste Datenumsetzungsvorrichtung 20 und die zweite Datenumsetzungsvorrichtung 30, es ist jedoch auch möglich, dass zum Beispiel nur die erste Datenumsetzungsvorrichtung 20 in DCE 4 bereitgestellt ist und Netzübergang 10 nur mit der zweiten Datenumsetzungsvorrichtung 30 versehen ist, um so einen PPP-Rahmenaufbau zu verwenden, der nur zur Verwendung bei einer einseitigen Datenkommunikation verbessert ist.
  • Des Weiteren wird bei dem vorliegenden Ausführungsbeispiel eine spezielle Verarbeitung (Oktett-Einfügung, -Löschung oder dergleichen) in Netzübergang 10 durchgeführt, wobei diese Verarbeitung jedoch alternativ zum Beispiel in der Vermittlung 8 durchgeführt werden kann.
  • [Zweites Ausführungsbeispiel]
  • Bei dem zweiten Ausführungsbeispiel der Erfindung wird eine Datenkommunikation zwischen DTE 2 und Netzübergang 10 gemäß PPP durchgeführt.
  • 14 ist eine Darstellung zur Erläuterung einer Datenkommunikation zwischen DTE 2 und Netzübergang 10. Der Netzübergang 10 und DTE 14 sind mit einer dedizierten Leitung verbunden. Bei dem vorliegenden Ausführungsbeispiel wird eine Verhandlungsverarbeitung (7) zwischen DTE 2 und Netzübergang 10 durchgeführt.
  • Wird ein Datensignal von DTE 2 zu DTE 14 übertragen, wird in DTE 2 an den Daten wie in der Vergangenheit eine Oktett-Einfügung durchgeführt und das Ergebnis übertragen. In DCE 4 wird die gleiche Verarbeitung wie bei dem ersten Ausführungsbeispiel durchgeführt, so dass Daten mit PPP-Rahmenaufbau und Oktett-Einfügung in Daten umgesetzt bzw. gewandelt werden, die einen verbesserten PPP-Rahmenaufbau (3) aufweisen und keine Oktett-Einfügung aufweisen.
  • Netzübergang 10 (der gemäß 14 als NW bezeichnet ist) setzt Daten mit verbessertem PPP-Rahmenaufbau und ohne Oktett-Einfügung in Daten um, die einen anderen Sicherungsschichtprotokoll-Rahmenaufbau als PPP aufweisen. Die Datenumsetzung kann genauso wie in dem Fall einer Umsetzung von Daten mit PPP-Rahmenaufbau in Daten mit einem Rahmenaufbau eines anderen Sicherungsschichtprotokolls als PPP durchgeführt werden. In dem verbesserten PPP-Rahmenaufbau befindet sich anstelle des Flag eine Identifikationsinformation zum Identifizieren einer Rahmenaufteilung bzw. -partition. Nach der Datenumsetzung überträgt Netzübergang 10 ein Signal, das die umgesetzten Daten enthält, an DTE 14.
  • Wird ein Datensignal andererseits DTE 14 zu DTE 2 übertragen, werden die Daten mit einem anderen Sicherungsschichtprotokoll-Rahmenaufbau als PPP in Netzübergang 10 in Daten umgesetzt bzw. gewandelt, die einen verbesserten Rahmenaufbau aufweisen und keine Oktett-Einfügung aufweisen. Die Datenumsetzung kann genauso wie in dem Fall einer Umsetzung von Daten mit einem anderen Sicherungsschichtprotokoll-Rahmenaufbau als PPP in Daten mit einem PPP-Rahmenaufbau durchgeführt werden. Nach der Datenumsetzung überträgt Netzübergang 10 das Signal, das die umgesetzten Daten enthält, an DCE 4.
  • In DCE 4 wird die gleiche Verarbeitung wie bei dem ersten Ausführungsbeispiel durchgeführt, so dass Daten mit einem verbesserten PPP-Rahmenaufbau und ohne Oktett-Einfügung in Daten umgesetzt bzw. gewandelt werden, die einen PPP-Rahmenaufbau aufweisen und eine Oktett-Einfügung aufweisen. Danach wird in DTE 2 genauso wie in der Vergangenheit eine Oktett-Löschung durchgeführt.
  • Wie vorstehend beschrieben wird zwischen DCE 4 und Netzübergang 10 ein Signal übertragen, das Daten enthält, die einen verbesserten PPP-Rahmenaufbau und keine Oktett-Einfügung aufweisen, wie gemäß 3 gezeigt. Mit diesem Betrieb wird eine Datenübertragungsmenge reduziert und der Durchsatz verbessert.
  • Ebenfalls bei dem vorliegenden Ausführungsbeispiel kann wie bei dem ersten Ausführungsbeispiel ein PPP-Rahmenaufbau verwendet werden, der nur zur Verwendung bei einer einseitigen Datenkommunikation verbessert ist.
  • Bei dem vorliegenden Ausführungsbeispiel wird ferner in Netzübergang 10 eine spezielle Verarbeitung (Umsetzung in Daten mit einem anderen Rahmenaufbau) durchgeführt, wobei diese Verarbeitung jedoch alternativ auch zum Beispiel ebenso in der Vermittlung 8 durchgeführt werden kann.
  • Des Weiteren führen DCE 4 und Netzübergang 10 ebenfalls bei dem vorliegenden Ausführungsbeispiel die gemäß 16 gezeigte Verarbeitung durch.
  • [Weiteres]
  • Das erste und das zweite Ausführungsbeispiel verwenden Zusatzinformationen, wobei jedoch solche Zusatzinformationen nicht erforderlich sind, wenn ein Aufbau verfügbar ist, der zum Identifizieren eines PPP in einer niedrigeren Schicht als PPP fähig ist. In einem solchen Fall sind das Zusatzinformation-Hinzufügungsbauteil 26 und das Zusatzinformation-Löschungsbauteil 32 nicht erforderlich.
  • Bei dem ersten und dem zweiten Ausführungsbeispiel ist die Erfindung in Verbindung mit Oktett-Einfügung und -Löschung beschrieben, wobei die Erfindung jedoch auch auf den Fall von Bit-Einfügung und -Löschung angewandt werden kann.
  • 15 ist eine Darstellung zur Erläuterung einer Bit-Einfügung. Ein Beispiel zur Durchführung einer Oktett- Einfügung in DTE 2 ist gemäß 9 beschrieben, wobei ein Betrieb, wenn in DTE 2 eine Bit-Einfügung durchgeführt wird, zum Beispiel wie gemäß 15 gezeigt ist. Bei dem Beispiel von 15 wird eine Bit-Einfügung durchgeführt, wenn fünf "1"s auf andere Daten als ein Flag folgen, indem danach eine "0" eingefügt wird. Da eine Bit-Löschung die umgekehrte Verarbeitung einer Bit-Einfügung ist, wird bei einer Bit-Löschung, wenn fünf "1"s auf andere Daten als ein Flag folgen, eine "0" danach gelöscht.
  • Wie vorstehend beschrieben wird die Oktett-/Bit-Einfügung bei der Erfindung während einer Kommunikation gemäß PPP in einem Abschnitt verhindert, der keine Oktett-/Bit-Einfügung erfordert, so dass die Datenübertragungsmenge reduziert werden kann und der Durchsatz verbessert werden kann. Kann die Datenübertragungsmenge reduziert werden, können die Nutzer mit verschiedenen Diensten zu niedrigen Kosten ausgestattet werden.
  • [Drittes Ausführungsbeispiel]
  • 23 zeigt ein Ablaufdiagramm, wenn die Erfindung auf ein Beispiel einer LCP- oder NCP-Verbindungsaufbauabfolge gemäß 20 angewandt wird. Eine (Kommunikations-)Vorrichtung 71 und eine (Kommunikations-)Vorrichtung 72 gehören zu Knoten A, und eine (Kommunikations-)Vorrichtung 73 und eine (Kommunikations-)Vorrichtung 74 zu Knoten B, die physikalisch unterschiedliche Vorrichtungen oder die gleiche Vorrichtung sein können. Zwischen der Vorrichtung und der Vorrichtung 73 ist eine Kommunikationsleitung verbunden. Zum Beispiel kann DTE 2 gemäß 17 der Vorrichtung 71 entsprechen, DCE 4 der Vorrichtung 72, DCE 8 der Vorrichtung 73, und DTE 10 der Vorrichtung 74, wobei ein redundantes Paket zwischen DCE 4 und DCE 8 gelöscht werden kann.
  • Die Vorgänge werden nachstehend beschrieben.
    • (a) Ein Einstellanforderungspaket wurde von der Vorrichtung 71 übertragen, hat die Vorrichtung 72 passiert, und ist vor Ankunft an Knoten B verloren gegangen.
    • (b) Die Vorrichtung 71 hat, da eine bestimmte Zeitdauer lang kein Antwortpaket auf das Einstellanforderungspaket von (a) empfangen wird, das Einstellanforderungspaket erneut übertragen. In diesem Fall wurde nur der ID-Wert auf einen Wert gesetzt, der sich von dem Einstellanforderungspaket von (a) unterscheidet.
    • (c) Ein Einstellanforderungspaket wurde von der Vorrichtung 74 übertragen, hat die Vorrichtung 73 passiert, und ist vor Ankunft an Knoten A verloren gegangen.
    • (d) Die Vorrichtung 74 hat, da Opt_C, Opt_D und Opt_E nicht erkannt werden können, auf das Einstellanforderungspaket von (b) das über die Vorrichtung 73 empfangen wurde, in einem Einstellzurückweisungspaket eine Antwort ausgeübt, die diese Optionen enthält.
    • (e) Die Vorrichtung 73 hat das Einstellzurückweisungspaket von (d) nicht an die Vorrichtung 72 übermittelt, hat Opt_C, Opt_D and Opt_E entfernt, um ein Einstellanforderungspaket mit geändertem ID-Wert zu erstellen, und dieses an die Vorrichtung 74 übertragen.
    • (f) Die Vorrichtung 74 hat, weil alle Optionen in dem empfangenden Einstellanforderungspaket von (e) und diese Werte tolerierbar sind, eine Antwort in einem Einstellidentifikationspaket ausgeübt. Die Vorrichtung 73 überträgt, wenn sie das Einstellidentifikationspaket von der Vorrichtung 74 empfängt, nur Informationen, die in dem Paket von (d) enthalten sind, an die Vorrichtung 72. Wie bei dem vorliegenden Beispiel wird, wenn das Einstellidentifikationspaket nach Empfang des Einstellzurückweisungspakets oder des Einstellverneinungspakets von der Vorrichtung 74 empfangen wird, dieses Einstellidentifikationspaket zum Abschluss gebracht. Wurde das Einstellidentifikationspaket jedoch empfangen, während das Einstellzurückweisungspaket oder das Einstellverneinungspaket von der Vorrichtung 74 nicht empfangen werden, wird dieses Einstellidentifikationspaket nicht zum Abschluss gebracht. In diesem Fall wird der Vorrichtung 72 (zum Beispiel durch Übertragung des Einstellidentifikationspakets) gemeldet, dass das Einstellidentifikationspaket einfach empfangen wurde.
    • (g) Die Vorrichtung 72 überträgt das Einstellzurückweisungspaket, das aus in dem Paket von (d) enthaltenen Informationen erstellt wird, an die Vorrichtung 71. Die Vorrichtung 71 entfernt bei Empfang des Einstellzurückweisungspakets von der Vorrichtung 72 Opt_C, Opt_D und Opt_E, und überträgt das Einstellanforderungspaket mit einem geänderten ID-Wert. Die Pakete von (e) und (g) sind, auch wenn sie sich im ID-Wert unterscheiden, Einstellanforderungspakete mit den gleichen Optionen.
    • (h) Die Vorrichtung 72 überträgt das Einstellanforderungspaket von (g) nicht an die Vorrichtung 73, sondern übt eine Antwort in einem Einstellidentifikationspaket aus. Die Pakete von (f) und (h) sind, selbst wenn sie sich im ID-Wert unterscheiden, Einstellidentifikationspakete mit den gleichen Optionen.
    • (i) Die Vorrichtung 74 überträgt, da ein Antwortpaket auf das Einstellanforderungspaket von (c) eine bestimmte Zeitdauer lang nicht empfangen wird, wiederum eine Einstellanforderungspaket mit dem gleichen Format wie das Einstellanforderungspaket von (c).
    • (j) Die Vorrichtung 71 übt, da Option Opt_G des empfangenden Einstellanforderungspakets von (i) nicht erkannt werden kann, in dem Einstellzurückweisungspaket eine Antwort einschließlich der Option aus.
    • (k) Die Vorrichtung 72 überträgt das Einstellzurückweisungspaket von (j) nicht an die Vorrichtung 73, überträgt das Einstellanforderungspaket mit der entfernten Option Opt_G und dem geänderten ID-Wert an die Vorrichtung 71.
    • (l) Die Vorrichtung 71 hat, da der Wert w2 der Option Opt_A in dem empfangenden Einstellanforderungspaket von (k) tolerierbar ist, es jedoch tolerierbar ist, wenn der Wert von der Option Opt_F nicht z1, sondern z2 ist, in dem Einstellverneinungspaket den Wert der Option Opt_F in z2 geändert und dieses übertragen.
    • (m) Die Vorrichtung 72 überträgt das Einstellverneinungspaket von (1) nicht an die Vorrichtung 71, sondern ändert den Wert der Option Opt_F in z2 und überträgt das Einstellanforderungspaket an die Vorrichtung 71.
    • (n) Die Vorrichtung 71 übt, da alle Optionen in dem empfangenen Einstellanforderungspaket von (m) erkannt werden können und diese Werte alle tolerierbar sind, in dem Einstellidentifikationspaket eine Antwort aus. Die Vorrichtung 72 überträgt bei Empfang des Einstellidentifikationspakets nur Informationen, die in den Paketen von (j) und (1) enthalten sind, an die Vorrichtung 73.
    • (o) Die Vorrichtung 73 überträgt zunächst bei Empfang von Informationen, die in den Paketen von (j) und (1) enthalten sind, von der Vorrichtung 72, ein Einstellzurückweisungspaket, das aus Informationen von (j) erstellt ist, an die Vorrichtung 74. Die Pakete von (j) und (o) sind Einstellzurückweisungspakete mit den gleichen Optionen.
    • (p) Die Vorrichtung 74 entfernt die Option Opt_G in dem empfangenden Einstellzurückweisungspaket von (o) und überträgt ein Einstellanforderungspaket mit einem geänderten ID-Wert. Die Pakete von (k) und (p) sind, auch wenn sie sich im ID-Wert unterscheiden, Einstellanforderungspakete mit den gleichen Optionen.
    • (q) Die Vorrichtung 73 überträgt das Einstellanforderungspaket von (p) nicht an die Vorrichtung 72, sondern, da es aus in dem Paket von (1) enthaltenen Informationen bekannt ist, dass der Wert w2 der Option Opt_A tolerierbar ist, es jedoch tolerierbar ist, wenn der Wert der Option Opt_F nicht z1, sondern z2 ist, ändert sie in dem Einstellverneinungspaket den Wert der Option Opt_F in z2 und überträgt dieses an die Vorrichtung 74. Die Pakete von (l) und (q) sind, selbst wenn sie sich im ID-Wert unterscheiden, Einstellverreinungspakete mit den gleichen Optionen.
    • (r) Die Vorrichtung 74 ändert den Wert der Option Opt_F in dem empfangenden Einstellverneinungspaket von (q) in z2 und überträgt ein Einstellanforderungspaket. Die Pakete von (m) und (r) sind, selbst wenn sie sich im ID-Wert unterscheiden, Einstellanforderungspakete mit den gleichen Optionen.
    • (s) Die Vorrichtung 73 überträgt das Einstellanforderungspaket von (r) nicht an die Vorrichtung 72, sondern, da alle Optionen in dem Einstellanforderungspaket erkannt werden können und diese Werte alle tolerierbar sind, übt sie in dem Einstellidentifikationspaket eine Antwort an die Vorrichtung 74 aus. Die Pakete von (n) und (s) sind, selbst wenn sie sich im ID-Wert unterscheiden, Einstellidentifikationspakete mit den gleichen Optionen.
  • 24 zeigt ein Ablaufdiagramm, wenn die Erfindung auf das LCP-Verbindungstrennungsabfolgebeispiel gemäß 21 angewandt wird. Die Vorgänge werden nachstehend beschrieben.
    • (a) Die Vorrichtung 71 überträgt ein Endanforderungspaket, um eine Verbindungsfreigabe anzufordern. Die Vorrichtung 72 überträgt auf Empfang des Endanforderungspakets ein Kommunikationsendanforderungssignal an die Vorrichtung 73. Die Vorrichtung 73 erzeugt auf Empfang des Kommunikationsendanforderungssignals ein Endanforderungspaket und überträgt dieses an die Vorrichtung 74.
    • (b) Die Vorrichtung 72 überträgt auf Empfang des Endeanforderungspakets von der Vorrichtung 71 ein Endeidentifikationspaket an die Vorrichtung 71. Die Vorrichtung 71, die das Endidentifikationspaket empfängt, geht in einen Verbindungsschlusszustand über. Andererseits überträgt die Vorrichtung 74, die das Endeanforderungspaket von der Vorrichtung 73 empfängt, ein Endeidentifikationspaket. Die Vorrichtung 73 überträgt das Endeidentifikationspaket nicht an die Vorrichtung 72.
    • (c) Die Vorrichtung 74 überträgt nach dem Ablauf einer Zeit seit der Endeidentifikationspaketübertragung ein Endeanforderungspaket. Die Vorrichtung 73 überträgt auf Empfang des Endeanforderungspakets ein Kommunikationsendeidentifikationssignal an die Vorrichtung 72. Die Vorrichtung 72, die das Kommunikationsendeidentifikationssignal empfängt, erzeugt ein Endeanforderungspaket und überträgt dieses an die Vorrichtung 71.
    • (d) Die Vorrichtung 73, die das Endeanforderungspaket empfängt, überträgt ein Endeidentifikationspaket an die Vorrichtung 74. Die Vorrichtung 74, die das Endeidentifikationspaket empfängt, geht in den Verbindungsschlusszustand über und, nach Trennung der physikalischen Verbindung, geht sie in einen Verbindungsunterbrechungsphasenzustand über. Die Vorrichtung 71, die das Endeanforderungspaket von der Vorrichtung 72 empfängt, überträgt andererseits ein Endeidentifikationspaket und, nach Trennung der physikalischen Verbindung, geht sie in einen Verbindungsunterbrechungsphasenzustand über. Die Vorrichtung 72 übermittelt das Endeidentifikationspaket nicht an die Vorrichtung 73.
  • 25 zeigt ein Ablaufdiagramm, wenn die Erfindung auf das LCP-Aufrechterhaltungabfolgebeispiel gemäß 22 angewandt wird. Die Vorgänge werden nachstehend beschrieben.
    • (a) Die Vorrichtung 71 überträgt, um zu bestätigen, ob die LCP-Verbindung aufrechterhalten wird oder nicht, ein LCP-Echoanforderungspaket.
    • (b) Die Vorrichtung 72 überträgt das empfangene LCP-Echoanforderungspaket von (a) nicht an die Vorrichtung 73, sondern überträgt ein LCP-Echoantwortpaket an die Vorrichtung 71.
    • (c) Die Vorrichtung 74 überträgt, um zu bestätigen, ob die LCP-Verbindung aufrechterhalten wird oder nicht, ein LCP-Echoanforderungspaket.
    • (d) Die Vorrichtung 73 überträgt das empfangene LCP-Echoanforderungspaket von (c) nicht an die Vorrichtung 72, sondern überträgt ein LCP-Echoantwortpaket an die Vorrichtung 74.
  • Wie vorstehend beschrieben wird zwischen der Vorrichtung 72 und der Vorrichtung 73 kein Signal übermittelt.
  • Bei dem vorliegenden Ausführungsbeispiel liegt ein Beispiel vor, bei dem die Erfindung auf eine Kommunikation gemäß PPP-Protokoll angewandt wird, wobei die Erfindung jedoch auch auf eine Kommunikation basierend auf einem ähnlichen Protokoll angewandt werden kann.
  • Wie vorstehend beschrieben kann ein Steuerpaket auf der Kommunikationsleitung mit der Erfindung reduziert werden.
  • Mit dieser Konfiguration werden redundante Pakete, zum Beispiel bei einem Ende-zu-Ende-PPP-Verbindungsaufbauvorgang, -trennungsvorgang und PPP-Verbindungsfortbestandsidentifikationsvorgang in dem gleichen Knoten zum Abschluss gebracht, wodurch eine auf der Kommunikationsleitung übermittelte Steuerpaketmenge reduziert werden kann, Kommunikationsgebühren und Kommunikationskosten reduziert werden können, und in Zusammenhang mit einer Reduktion einer Kommunikationsverkehrsmenge eine Teilnehmerkapazität erhöht werden kann.
  • Die Erfindung wurde mit Bezug auf bevorzugte Ausführungsbeispiele ausführlich beschrieben, und es wird für einen Fachmann aus dem Vorstehenden nun offenkundig sein, dass Änderungen und Modifikationen vorgenommen werden können, ohne von der Erfindung in ihren breitesten Aspekten abzuweichen, und es daher in den zugehörigen Patentansprüchen die Intention bzw. Absicht ist, alle solchen Änderungen und Modifikationen abzudecken, die in den Umfang der Erfindung fallen.

Claims (3)

  1. Datenumsetzungsverfahren in einer dritten Kommunikationsvorrichtung (4; 10), die sich zwischen einer ersten Kommunikationsvorrichtung (2; 14) und einer zweiten Kommunikationsvorrichtung (14; 2) befindet, die eine Datenkommunikation mit der ersten Kommunikationsvorrichtung basierend auf PPP durchführt, wobei das Datenumsetzungsverfahren aufweist: einen Empfangsschritt zum Empfangen von ersten Daten von der ersten Kommunikationsvorrichtung (2; 14); einen Datenumsetzungsschritt zum Umsetzen der ersten Daten in zweite Daten; und einen Übertragungsschritt zum Übertragen der zweiten Daten in Richtung der zweiten Kommunikationsvorrichtung (14; 2), wobei die ersten Daten Daten mit Oktett-Einfügung oder Bit-Einfügung sind und die zweiten Daten Daten ohne Oktett-Einfügung und ohne Bit-Einfügung sind, und die Daten ohne Oktett-Einfügung und ohne Bit-Einfügung eine Rahmenkonfiguration aufweisen, bei der zusätzliche Informationen einschließlich Informationen zum Identifizieren einer Rahmenaufteilung zu einer PPP-Rahmenkonfiguration hinzugefügt sind, oder eine Rahmenkonfiguration aufweisen, bei der zusätzliche Informationen einschließlich Informationen zum Identifizieren einer Rahmenaufteilung zu einer Rahmenkonfiguration mit Flag-Löschung gegenüber einer PPP-Rahmenkonfiguration hinzugefügt sind, und die Informationen zum Identifizieren eine Rahmenlänge darstellen.
  2. Datenumsetzungsverfahren gemäß Anspruch 1, wobei die Daten ohne Oktett-Einfügung und ohne Bit-Einfügung eine Rahmenkonfiguration aufweisen, bei der zusätzliche Informationen einschließlich Informationen zum Identifizieren einer Rahmenaufteilung zu einer PPP-Rahmenkonfiguration hinzugefügt sind.
  3. Datenumsetzungsverfahren gemäß Anspruch 1, wobei die Daten ohne Oktett-Einfügung und ohne Bit-Einfügung eine Rahmenkonfiguration aufweisen, bei der zusätzliche Informationen einschließlich Informationen zum Identifizieren einer Rahmenaufteilung zu einer Rahmenkonfiguration mit Flag-Löschung gegenüber einer PPP-Rahmenkonfiguration hinzugefügt sind.
DE60034193T 1999-09-21 2000-09-21 Datenumsetzungsgeräte und -verfahren Expired - Lifetime DE60034193T2 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP26686299 1999-09-21
JP26686299A JP3689279B2 (ja) 1999-09-21 1999-09-21 データ変換装置、信号、データ変換方法、dceおよびゲートウェイ
JP2000118620 2000-04-19
JP2000118620A JP3793393B2 (ja) 2000-04-19 2000-04-19 通信装置

Publications (2)

Publication Number Publication Date
DE60034193D1 DE60034193D1 (de) 2007-05-16
DE60034193T2 true DE60034193T2 (de) 2007-12-20

Family

ID=26547621

Family Applications (2)

Application Number Title Priority Date Filing Date
DE60037210T Expired - Lifetime DE60037210T2 (de) 1999-09-21 2000-09-21 Datenumwandlungs- und Kommunikationsverfahren
DE60034193T Expired - Lifetime DE60034193T2 (de) 1999-09-21 2000-09-21 Datenumsetzungsgeräte und -verfahren

Family Applications Before (1)

Application Number Title Priority Date Filing Date
DE60037210T Expired - Lifetime DE60037210T2 (de) 1999-09-21 2000-09-21 Datenumwandlungs- und Kommunikationsverfahren

Country Status (6)

Country Link
US (2) US7260107B1 (de)
EP (2) EP1087591B1 (de)
KR (1) KR100367657B1 (de)
CN (2) CN1164059C (de)
DE (2) DE60037210T2 (de)
SG (3) SG119207A1 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3959402B2 (ja) * 2004-03-19 2007-08-15 株式会社日立コミュニケーションテクノロジー 通信接続装置及び通信端末ならびにこれを用いた通信方法
KR100575989B1 (ko) * 2004-04-08 2006-05-02 삼성전자주식회사 동기화 이더넷에서의 비동기 데이터의 분할 전송 방법 및그 방법에 사용되는 데이터 구조
US7657744B2 (en) * 2004-08-10 2010-02-02 Cisco Technology, Inc. System and method for dynamically determining the role of a network device in a link authentication protocol exchange
CN101729391B (zh) * 2008-10-23 2012-09-19 华为技术有限公司 获取链路汇聚组信息的方法、节点和系统
US9692784B1 (en) * 2016-10-25 2017-06-27 Fortress Cyber Security, LLC Security appliance
CN115118497B (zh) * 2022-06-28 2024-01-30 中国南方电网有限责任公司 边缘网关的对点方法、装置、计算机设备、存储介质

Family Cites Families (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS58199238A (ja) 1982-05-17 1983-11-19 Nissan Motor Co Ltd 車両用グロ−ブボツクスのヒンジピン
US4607364A (en) * 1983-11-08 1986-08-19 Jeffrey Neumann Multimode data communication system
JPH0773240B2 (ja) 1985-12-13 1995-08-02 日本電気株式会社 自動再トレ−ニング方式
US5054019A (en) 1989-01-13 1991-10-01 International Business Machines Corporation Transfer direction turnaround in network data communications
US5416772A (en) * 1993-08-20 1995-05-16 At&T Corp. Apparatus for insertion of overhead protocol data into a switched data stream
US5446736A (en) * 1993-10-07 1995-08-29 Ast Research, Inc. Method and apparatus for connecting a node to a wireless network using a standard protocol
US6181703B1 (en) * 1995-09-08 2001-01-30 Sprint Communications Company L. P. System for managing telecommunications
AU706160B2 (en) 1994-06-08 1999-06-10 Hughes Electronics Corporation Apparatus and method for hybrid network access
JPH08102761A (ja) 1994-09-30 1996-04-16 Toshiba Corp プロトコル変換装置およびプロトコル変換方法
FI98027C (fi) 1995-01-10 1997-03-25 Nokia Telecommunications Oy Pakettiradiojärjestelmä ja päätelaitteisto pakettiradiojärjestelmää varten
EP0805621B1 (de) 1995-01-11 2002-04-03 WCI OUTDOOR PRODUCTS, Inc. Schneidkopf für trimmer mit flexiblem schneidfaden
JP2687919B2 (ja) 1995-03-29 1997-12-08 日本電気株式会社 キープアライブ代理応答およびキープアライブ代理送達を行うルータ
US6304574B1 (en) * 1995-06-07 2001-10-16 3Com Corporation Distributed processing of high level protocols, in a network access server
US5666362A (en) * 1995-07-25 1997-09-09 3Com Corporation Method and apparatus for asynchronous PPP and synchronous PPP conversion
US5657452A (en) * 1995-09-08 1997-08-12 U.S. Robotics Corp. Transparent support of protocol and data compression features for data communication
US5870540A (en) 1995-11-20 1999-02-09 Ncr Corporation Low overhead method for detecting communication failures on a network
US5781726A (en) * 1996-01-31 1998-07-14 3Com Corporation Management of polling traffic in connection oriented protocol sessions
JPH09307580A (ja) 1996-05-10 1997-11-28 Nippon Telegr & Teleph Corp <Ntt> 不正パケット防止方法およびブリッジ装置
JPH09326819A (ja) * 1996-06-03 1997-12-16 Nec Corp ゲートウェイ装置
JPH1023003A (ja) 1996-06-27 1998-01-23 Matsushita Electric Ind Co Ltd ターミナルアダプタ
US6754181B1 (en) * 1996-11-18 2004-06-22 Mci Communications Corporation System and method for a directory service supporting a hybrid communication system architecture
CA2245808C (en) * 1996-12-10 2003-01-28 Ntt Mobile Communications Network Inc. Mobile communication device, method for mobile data communication, and program storage medium
JP3735168B2 (ja) 1996-12-11 2006-01-18 富士通株式会社 簡易ルーチング方式
US6144671A (en) 1997-03-04 2000-11-07 Nortel Networks Corporation Call redirection methods in a packet based communications network
JPH10322361A (ja) 1997-03-14 1998-12-04 Fujitsu Ltd シグナリング方法、スイッチング装置、記憶媒体及びネットワーク
JP2970579B2 (ja) 1997-03-19 1999-11-02 日本電気株式会社 Atm通信システム
JP3156760B2 (ja) 1997-05-19 2001-04-16 日本電気株式会社 パケット通信方式
JPH1174992A (ja) 1997-06-23 1999-03-16 Canon Inc 無線通信装置
DE69827759T2 (de) 1997-06-24 2005-11-03 Ntt Mobile Communications Network Inc. Kommunikationssystem, kommunikationssteuerverfahren und kommunikationssteuerung
JPH1127740A (ja) 1997-06-30 1999-01-29 Matsushita Electric Ind Co Ltd データ通信端末装置
GB9715966D0 (en) 1997-07-30 1997-10-01 Ibm Data communications management for use with networking applications and for mobile communications environments
GB2329550A (en) * 1997-09-22 1999-03-24 Northern Telecom Ltd Transporting multi-protocol datagrams over an asynchronous virtual channel
JP3922482B2 (ja) * 1997-10-14 2007-05-30 ソニー株式会社 情報処理装置および方法
US6577643B1 (en) * 1997-10-14 2003-06-10 Lucent Technologies Inc. Message and communication system in a network
US6233248B1 (en) * 1997-10-14 2001-05-15 Itt Manufacturing Enterprises, Inc. User data protocol for internet data communications
US6856618B2 (en) * 1997-10-21 2005-02-15 Intel Corporation Apparatus and method for computer telephone integration in packet switched telephone networks
JPH11136240A (ja) * 1997-10-27 1999-05-21 Oki Electric Ind Co Ltd ノード
US6438137B1 (en) * 1997-12-22 2002-08-20 Nms Communications Corporation Packet-based trunking
DE19800772C2 (de) * 1998-01-12 2000-04-06 Ericsson Telefon Ab L M Verfahren und Vorrichtung zur Verbindung mit einem Paketaustauschnetz
CA2262774A1 (en) 1998-03-06 1999-09-06 Lucent Technologies Inc. Simple data link (sdl) protocol
US6118785A (en) * 1998-04-07 2000-09-12 3Com Corporation Point-to-point protocol with a signaling channel
US6847614B2 (en) * 1998-04-20 2005-01-25 Broadcom Corporation Apparatus and method for unilateral topology discovery in network management
US6496491B2 (en) * 1998-05-08 2002-12-17 Lucent Technologies Inc. Mobile point-to-point protocol
US6449272B1 (en) * 1998-05-08 2002-09-10 Lucent Technologies Inc. Multi-hop point-to-point protocol
US6320874B1 (en) * 1998-10-07 2001-11-20 Nortel Networks Limited Establishing and terminating connections in a mixed protocol network
JP2000209920A (ja) 1999-01-19 2000-08-02 Iseki & Co Ltd 根菜類収穫機の掘起し深さ制御装置
US6370118B1 (en) * 1999-02-24 2002-04-09 Qualcomm Incorporated Simultaneous set up of PPP on AUM and a RM interface
US6721333B1 (en) * 1999-03-25 2004-04-13 Motorola, Inc. Point to point protocol multiplexing/demultiplexing method and apparatus
US6636505B1 (en) * 1999-05-28 2003-10-21 3Com Corporation Method for service provisioning a broadband modem
US6483822B1 (en) * 1999-06-07 2002-11-19 Marcello Lioy Establishing a packet network call between a mobile terminal device and an interworking function

Also Published As

Publication number Publication date
KR20010050542A (ko) 2001-06-15
EP1087591B1 (de) 2007-04-04
CN1529483A (zh) 2004-09-15
CN1164059C (zh) 2004-08-25
EP1087591A3 (de) 2004-04-07
US7260107B1 (en) 2007-08-21
DE60034193D1 (de) 2007-05-16
SG119207A1 (en) 2006-02-28
SG114472A1 (en) 2005-09-28
SG119208A1 (en) 2006-02-28
CN1296351A (zh) 2001-05-23
EP1549023B1 (de) 2007-11-21
EP1549023A1 (de) 2005-06-29
KR100367657B1 (ko) 2003-01-10
DE60037210T2 (de) 2008-09-25
DE60037210D1 (de) 2008-01-03
CN1287574C (zh) 2006-11-29
US20060193341A1 (en) 2006-08-31
US7680122B2 (en) 2010-03-16
EP1087591A2 (de) 2001-03-28

Similar Documents

Publication Publication Date Title
DE60110974T2 (de) Abfangverfahren und -vorrichtung zur Kompensation nachteiliger Eigenschaften eines Kommunikationsprotokolls
DE60105127T2 (de) Sitzungseintichtungsprotokoll basierend auf fortschrittlichen intelligenten netz/intelligenten netznachrichtenübertragung
DE60031673T2 (de) Aufbau eines paketnetzrufes zwischen einem mobilen endgerät und einer anpassungsfunktion
DE19933751B4 (de) Verfahren und Umsetzfunktionsvorrichtung zum drahtlosen Datentransport
DE10361704B4 (de) Vorrichtung und Verfahren zum Aufbauen einer Verbindung in einem aus mobilen Knoten gebildeten Funknetzwerk
DE60031817T2 (de) Verfahren zum Kommunikationssitzungsaufbau zwischen einem Endgerät eines paketbasierten Netzwerks und einem Endgerät verbunden mit einem Fernzugriffsserver
DE60034193T2 (de) Datenumsetzungsgeräte und -verfahren
DE10027456A1 (de) Vorrichtung und Verfahren zum Verbessern der Leistung in Master- und Slave-Kommunikationssystemen
EP1482701B1 (de) Verfahren zum paketorientierten Übertragen von Daten in Telekommunikationsnetzen mittels Umsetzung in einem Zwischenknoten von einem verbindungslosen zu einem verbindungsorientierten Übertragungsprotokoll und umgekehrt
EP0998078A1 (de) Konfigurationsverfahren einer Nachrichtenverbindung für eine Datenübertragung
EP1512311B1 (de) Verfahren und zugangsmultiplexer für den schnellen zugang zu datennetzen
EP0957613A1 (de) Verfahren und Vorrichtung zur Erhöhung eines Datendurchsatzes
DE60032096T2 (de) Mehrkanal- Kommunikationssteuerungssystem und -verfahren
DE60023393T2 (de) Verfahren und Vorrichtung zur Paketkommunikation
DE69935584T2 (de) Aktivierung von mehreren xdsl-modems durch sowohl halb- als auch vollduplexverfahren
DE10007012B4 (de) Verfahren zur bidirektionalen Datenübertragung über eine paketorientierte Netzwerkeinrichtung
DE10056087B4 (de) Funkkommunikationssystem
DE10344764B4 (de) Verfahren zum Übermitteln von Informationen
DE102005003016A1 (de) Verfahren und Vorrichtungen zur Datenübertragung
DE102005046780A1 (de) Vorrichtung und Verfahren zum Weiterleiten von Telefondaten
DE10035368C2 (de) Vorrichtung, Verfahren und Computerprogrammprodukt zum Verwalten einer Datenübertragung
EP1257145B1 (de) Verfahren und Vorrichtungen zur Datenübertragung mit zeitlich veränderlicher Datenrate
EP1099326A2 (de) Verfahren zur verbindung von endgeräten mit externen modems
DE19833969A1 (de) Verfahren zum Aufbau einer Kommunikationsverbindung
EP0554525B1 (de) Verfahren zum übersichtlichen Betrieb einer Übertragungs-Einrichtung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8328 Change in the person/name/address of the agent

Representative=s name: HOFFMANN & EITLE, 81925 MUENCHEN