EP1188288A2 - Protokolleinrichtung eines protokoll-systems zur übertragung von nachrichten - Google Patents

Protokolleinrichtung eines protokoll-systems zur übertragung von nachrichten

Info

Publication number
EP1188288A2
EP1188288A2 EP00931216A EP00931216A EP1188288A2 EP 1188288 A2 EP1188288 A2 EP 1188288A2 EP 00931216 A EP00931216 A EP 00931216A EP 00931216 A EP00931216 A EP 00931216A EP 1188288 A2 EP1188288 A2 EP 1188288A2
Authority
EP
European Patent Office
Prior art keywords
protocol
information
stat
messages
pdu
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.)
Withdrawn
Application number
EP00931216A
Other languages
English (en)
French (fr)
Inventor
Michael TÜXEN
Klaus David Gradischnig
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.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Siemens AG
Nokia Siemens Networks GmbH and Co KG
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 Siemens AG, Nokia Siemens Networks GmbH and Co KG filed Critical Siemens AG
Publication of EP1188288A2 publication Critical patent/EP1188288A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • 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
    • 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

Definitions

  • the sequence number (in Q.2110 in the parameter N (MR) of a control message for example one.) Is given here under a loan that the recipient of user data messages (in Q.2110 referred to as SD-PDUs) grants to the sender via a control message STAT-PDU or USTAT-PDU, included) understood that user data message that is first no longer accepted by the recipient.
  • the window size is understood to be a number of user data that the recipient is ready to accept.
  • the sequence number (in Q.2110 contained in the parameter N (R) of a STAT-PDU or USTAT-PDU) is used to count up to which the recipient has already received and acknowledged all messages with a smaller sequence number.
  • the invention now describes how to avoid discarding current control information. In particular, it describes how to extend existing protocols that do not solve the problem to solve this problem.
  • Another simple way to solve the problem is to number all the control information and then treat the control information analogously to the user data. It is difficult to introduce this retrospectively for protocols, since one would normally have to change the message format for numbering. However, this is usually not acceptable for reasons of compatibility when extending existing protocols.
  • the recipient of the control message can always decide whether this control message received by him contains information that is newer than his current information status. As a result, older information cannot overwrite more current information due to message overhaul.
  • Protocol information is used to decide whether information received by a received control message is newer than the information already available (Control information which serves to control user data messages, for example confirm receipt of user data messages or display non-received user data messages or which contain the sequence number of the message up to which all messages were received without gaps), if possible , If the transmission sequence cannot be reconstructed on the basis of the protocol information contained in the control messages, only those control information for which this is absolutely necessary and which permit such an introduction are additionally numbered.
  • a special feature of the invention lies in the skillful combination of a message format change that is compatible with the existing protocol and an analysis of the protocol in order to reconstruct the chronological order in which the control information was sent to the recipient of the control information. You can then discard old information.
  • SSCOP defined in Q.2110
  • the lower layer transmits the data with sequence security.
  • MSSCOP Dynamic Synchronization Protocol
  • the simplest method is that the credit can no longer be reduced in the MSSCOP. However, this represents a significant restriction of the protocol. When a STAT PDU is received, the credit information would be discarded if the received credit was smaller than the current one.
  • the sender uses protocol information contained in the list elements and the parameter N (R) of the received STAT and USTAT PDUs as follows:
  • the variable VT (A) of the transmitter is changed in such a way that it in turn changes the value of the contains the next ("oldest") message to be confirmed.
  • the information in the list elements is used to decide whether certain messages in the send buffer have to be sent again or have been confirmed by the recipient.
  • the parameter N (R) is also used for the latter. If messages have been confirmed, they can be removed from the send buffer, unless the user of the SSCOP does not allow this. (In this case the SSCOP parameter Clear-buffers has the value FALSE.)
  • an additional SSCOP status variable VT (H) of the transmitter (transmitter) is now being introduced.
  • the new variable VT (H) stores the largest last list element of all received STAT-PDUs and USTAT-PDUs (the last list element specifies the highest SD-PDU expected by the receiver in a STAT-PDU, provided the STAT-PDU has list elements at all contains and in a USTAT-PDU, the last list element reports the first SD-PDU received after the reception error reported by the USTAT-PDU).
  • the parameter N (R) contained in the STAT-PDU is used to adapt the variable VT (H) if it is greater than the current value of the variable VT (H) (Note: USTATs always contain exactly 2 list elements that signal the gap to be reported. N (R) m of a USTAT is therefore always "smaller" than the list elements contained).
  • N (SS) is set with the value VR (SS).
  • VR (SS) is the next STAT sequence number that numbers the STAT PDUs within a poll cycle (a poll cycle is the time between the receipt of two POLL PDUs).
  • the modified STAT-PDU format is shown in Figure 1. Because N (SS) in a field is written, which is currently marked as Reserved, an unmodified SSCOP protocol machine can also process such a message because it does not process N (SS).
  • VR (SS) 0 is only set before a STAT PDU is generated. If a further STAT PDU is now to be generated within a poll cycle in order to modify the credit, this will only be done if VR (SS) ⁇ 255 applies. Otherwise no such STAT PDU is generated. (However, this is an acceptable limitation and in any case better than not allowing any spontaneous modification of the loan at all.) In the case of VR (SS) ⁇ 255, VR (SS) is increased by 1 and then a STAT-PDU is generated.
  • VT (SS) 0 if VT (PA) ⁇ N (PS) applies.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)

Abstract

Bei Kommunikationsprotokollen werden sowohl Nutzerdaten als auch Kontrollinformationen übertragen. Während bei vielen Protokollen (Nachrichten-)Pakete mit Nutzerdaten durchnumeriert werden und dadurch sichergestellt wird, daß die Nutzerdaten vollständig und sequenzgesichert an den Empfänger übergeben werden, werden Nachrichten, die nur Kontrollinformationen enthalten, üblicherweise nicht durchnumeriert. Dieser Umstand kann zu Überholungen von Kontrollnachrichten und dadurch zum Verwerfen von aktueller Kontrollinformation führen. Die Erfindung beschreibt nun, wie man das Verwerfen aktueller Kontrollinformation vermeidet.

Description

Beschreibung
Protokolleinrichtung eines Protokoll-Systems zur Übertragung von Nachrichten
1. Welches technische Problem soll durch Ihre Erfindung gelöst werden?
2. Wie wurde dieses Problem bisher gelöst?
3. In welcher Weise löst Ihre Erfindung das angegebene technische Problem (geben Sie Vorteile an) ?
4. Worin liegt eine Besonderheit der Erfindung ?
5. Ausführungsbeispiel [e] der Erfindung.
Zu 1. :
Bei Kommunikationsprotokollen werden sowohl Nutzerdaten als auch Kontrollinformationen übertragen. Dabei wird bei vielen Protokollen sichergestellt, daß die Nutzerdaten vollständig (d. h. alle gesendeten Daten werden auch empfangen) und sequenzgesichert (d. h. in der richtigen vom Sender bestimmten Reihenfolge) an den Empfänger übergeben werden. Für die Nutzerdaten wird dies oft dadurch erreicht, daß die Sendereinrichtung des Protokollsystems alle Nutzerdaten mit einer Sequenznummer durchnumeriert. (Nachrichten-) Pakete, die nur Kontrollinformationen enthalten, werden üblicherweise nicht durchnumeriert, allenfalls Pakete mit bestimmten Klassen von Kontrollinformationen. Werden die Kontrollnachrichten aber nun nicht sequenzgesichert von der unteren Schicht übertragen, so kann es zu Überholungen der Kontrollnachrichten führen. Falls die Überholung nicht erkannt wird, bedeutet dies für den Empfänger von Kontrollinformation, daß er statt mit aktueller Kontrollinformation, die ihm ebenfalls vorliegt, mit veralteter Kontrollinformation arbeitet, da er sie für aktueller hält. In der Regel ist dieses Verhalten für diejenige Kontrollinformation, die Nachrichtenempfang bestätigt, nicht kritisch, da diese Information nicht veraltet. Kritisch ist jedoch das Verwerfen aktueller Kontrollinformation, die die Flußkontrolle betrifft (z.B. Kreditinformation) , durch das Verwenden veralteter Information, da diese Information sehr schnell veraltet. Insbesondere sind davon dynamische Fenstergrößen, die vom Empfänger bestimmt werden, betroffen.
Einschub :
Im Zusammenhang mit der Flußkontrolle seien zwei Bezeichnungen fixiert. Unter einem Kredit, den der Empfänger von Nutzerdaten-Nachrichten (in Q.2110 als SD-PDUs bezeichnet) dem Sender über eine Kontrollnachricht gewährt, wird hier die Sequenznummer (in Q.2110 in dem Parameter N(MR) einer Kontrollnachricht, z.B. einer STAT-PDU oder USTAT-PDU, enthalten) derjenigen Nutzerdaten-Nachricht verstanden, die als erste nicht mehr vom Empfänger akzeptiert wird. Unter der Fenstergröße wird eine Anzahl von Nutzdaten verstanden, die der Empfänger bereit ist zu akzeptieren. Dabei wird von der Sequenznummer (in Q.2110 in dem Parameter N(R) einer STAT-PDU bzw. USTAT-PDU enthalten) aus gezählt, bis zu der der Empfänger alle Nachrichten mit kleinerer Sequenznummer bereits erhalten und quittiert hat.
Die Erfindung beschreibt nun, wie man das Verwerfen aktueller Kontrollinformation vermeidet. Insbesondere wird beschrieben, wie man bestehende Protokolle, die das Problem nicht lösen, dahingehend erweitern kann, daß sie dieses Problem lösen.
Man könnte meinen, daß man dieses Problem nicht behandeln muß, falls die untere Protokollschicht eine sequenzgesicherte Übertragung garantiert. Will man aber mit Hilfe einer solchen Schicht eine Multilink-Verbindung realisieren, so hat man auch bei einer solchen Schicht mit Nachrichtenüberholungen zu rechnen. Zu 2 .
Wenn man sich darauf beschränkt, daß der Empfänger einen einmal gegebenen Kredit nicht wieder zurücknehmen darf, so kann man leicht das oben genannte Problem lösen, indem man Kontrollinformation, die diese Regel verletzt, einfach nicht bearbeitet. Dies entspricht der Lösung im TCP/IP Protokoll. Dies beinhaltet auch den Fall konstanter Fenstergröße.
Eine weitere einfache Möglichkeit zur Lösung des Problems besteht darin, alle Kontrollinformationen durchzunumerieren und dann die Kontrollinformationen analog zu den Nutzdaten zu behandeln. Dies nachträglich bei Protokollen einzuführen, ist aber schwierig, da man zur Nummerierung in der Regel das Nachrichtenformat ändern müßte. Dies ist aber bei der Erweiterung bestehender Protokolle aus Kompatibilitätsgründen meist nicht akzeptabel.
Die Möglichkeit der Rücknahme des Kredits ist bei einigen Protokollen, wie zum Beispiel SSCOP, eine wichtige Eigenschaft. Bei solchen Protokollen scheint das Problem zur Zeit ungelöst zu sein.
Zu 3
Bei der hier angegeben Lösung kann der Empfänger der Kontrollnachricht stets entscheiden, ob diese von ihm empfangene Kontrollnachricht eine Information beinhaltet, die neuer ist, als sein aktueller Informationsstand. Dadurch kann durch Nachrichtenüberholung keine ältere Information eine aktuellere Information überschreiben.
Um zu entscheiden, ob eine durch eine empfangene Kontrollnachricht erhaltene Information neuer ist als die schon vorhandene Information, werden Protokollinformationen (Kontrollinformationen, die der Kontrolle von Nutzerdaten- Nachrichten dienen, z.B. Empfang von Nutzerdaten-Nachrichten bestätigen bzw. nicht empfangene Nutzerdaten-Nachrichten anzeigen oder die die Sequenznummer der Nachricht enthalten, bis zu der all Nachrichten lückenlos empfangen wurden) benutzt, sofern dies möglich ist. Kann man aufgrund der in den Kontrollnachrichten enthaltenen Protokollinformationen die Sendereihenfolge nicht rekonstruieren, so werden nur diejenigen Kontrollinformationen zusätzlich durchnumeriert, für die dies unbedingt nötig ist und die eine solche Einführung zulassen.
Zu 4
Eine Besonderheit der Erfindung liegt in der geschickten Kombination aus einer Nachrichtenformatänderung, die kompatibel mit dem bestehenden Protokoll ist, und einer Analyse des Protokolls, um beim Empfänger der Kontrollinformation die zeitliche Reihenfolge des Sendens der Kontrollinformation zu rekonstruieren. Damit kann man dann alte Information verwerfen.
Zu 5. :
Im folgenden werden drei Ausführungsbeispiele gegeben, die alle auf dem Protokoll SSCOP basieren. SSCOP, definiert in der Q.2110, setzt voraus, daß die untere Schicht die Daten sequenzgesichert überträgt. Wie in 1. ausgeführt, stellt sich hier das diskutierte Problem also nicht. Gegenwärtig wird aber SSCOP erweitert, um Multilink-fähig zu werden und über einer unteren Schicht zu funktionieren, die keine sequenzgesicherte Übertragung sicherstellt. Dies entspricht dem MSSCOP (Draft Q.2111 mit dem Stand vor Beginn des Treffens der ITU-T Working Party 5/11 und der Rapporteure für Studienfrage 15/11, Washington, 28. Juni bis 1. Juli 1999), wie er aktuell bei der ITU diskutiert wird. Das hier diskutierte Problem wird dort jedoch nicht gelöst.
Ausführungsbeispiel 1:
Die einfachste Methode besteht darin, daß im MSSCOP der Kredit nicht mehr verringert werden darf. Dies stellt aber eine wesentliche Einschränkung des Protokolls dar. Beim Empfang einer STAT-PDU würde man die Kreditinformation verwerfen, wenn der empfangene Kredit kleiner als der aktuelle wäre.
Ausführungsbeispiel 2
Beim dem Protokoll MSSCOP (Draft Q.2111, mit dem Stand vor Beginn des Treffens der ITU-T Working Party 5/11 und der Rapporteure für Studienfrage 15/11, Washington, 28. Juni bis 1. Juli 1999), wie es aktuell diskutiert wird, kann man allein aus der Protokollinformation der STAT-PDUs bzw. USTAT- PDUs die Sendereihenfolge rekonstruieren. In diesem Ausführungsbeispiel braucht man keine Nachrichtenformate zu ändern.
In SSCOP werden vom Sender (der Nutzdaten) Protokollinformationen, die in den Listelementen und dem Parameter N(R) der empfangenen STAT- und USTAT-PDUs enthalten sind, wie folgt verwendet:
Wenn bereits gesendete Nutzerdaten-Nachrichten durch Listelemente oder den Paremeter N(R) der empfangenen STAT- und USTAT-PDUs bis zu einer bestimmten Sequenznummer lückenlos bestätigt werden, wird die Variable VT (A) des Senders dahingehend geändert, daß sie wiederum den Wert der nächsten ("ältesten") zu bestätigenden Nachricht enthält. Außerdem werden die Informationen der Listelemente verwendet, um zu entscheiden ob gewisse Nachrichten im Sendebuffer neu gesendet werden müssen oder durch den Empfanger bestätigt wurden. Für letzteres wird auch der Paremeter N(R) eingesetzt. Falls Nachrichten bestätigt wurden, können sie aus dem Sendebuffer entfernt werden, außer dies wird vom Anwender des SSCOP nicht erlaubt. (In diesem Fall hat der SSCOP Parameter Clear-buffers den Wert FALSE . )
Erfmdungsgemaß wird nun eine zusätzliche SSCOP Status Variable VT (H) des Senders (Transmitters) eingeführt. Die neue Variable VT (H) speichert jeweils das größte letzte Listenelement aller empfangenen STAT-PDUs und USTAT-PDUs ( durch das letzte Listenelement wird m einer STAT-PDU die höchste vom Empfanger erwartete SD-PDU angegeben, sofern die STAT-PDU überhaupt Listenelemente enthalt und m einer USTAT- PDU wird durch das letzte Listenelement die erste, nach der durch die USTAT-PDU gemeldeten Empfangfslucke empfangene SD- PDU gemeldet) .
Ist m einer empfangenen STAT-PDU kein Listenelement enthalten, so wird der m der STAT-PDU enthaltene Parameter N(R), sofern er großer als der momentane Wert der Variable VT (H) ist, zum Anpassen der Variable VT (H) verwendet (Bemerkung: USTATs enthalten immer genau 2 Listenelemente, die die zu meldende Lücke signalisieren. N(R) m einer USTAT ist damit immer "kleiner" als die enthaltenen Listenelemente) .
Die Bearbeitung von empfangenen POLL-PDUs und STAT-PDUs sowie d e Verwaltung der neuen Statusvariablen VT (H) ergibt sich aus den folgenden Regeln:
Wenn man eine USTAT-PDU empfangt, so verwirft man die Kreditinformation, falls das letzte Listenelement dieser
Nachricht, nämlich List Element 2 <= VT (H) ist. Andernfalls bearbeitet man die Kreditinformation und setzt VT (H) = List Element 2.
Wenn man eine STAT-PDU empfängt, verwirft die Kreditinformation, falls das letzte Listenelement List Element L < VT (H) . Andernfalls nutzt man die Kreditinformation und setzt VT (H) = List Element L. Ist aber kein Listelement entahlten, wird die Kreditinformation verworfen, falls N(R) < VT (H) ist; andernfalls nutzt man die Kreditinformation und setzt VT (H) = N(R).
Ausführungsbeispiel 3:
Es wird gegenwärtig eine Erweiterung des SSCOP und damit auch des MSSCOP diskutiert, die es dem Empfänger ermöglicht, eine STAT-PDU zu senden ohne das diese eine direkte Antwort auf eine POLL-PDU ist. (Im MSSCOP würden diese STAT-PDUs die z.Zt. definierten/diskutierten CREDIT-PDUs ersetzen.) Damit soll dem Empfänger ermöglicht werden, Kreditinformation zu übertragen, wannimmer es für den Empfänger sinnvoll erscheint. Dazu generiert der Empfänger eine STAT-PDU mit der neuen Kreditinformation. Da sich zwischen dem Aussenden mehrerer STAT-PDU in einem Pollzyklus der Status des Empfängers nicht verändern muß und damit das letzte List Element bzw. der Paremeter N(R) gleich bleiben kann, muß man die STAT-PDUs im selben Pollzyklus durchnumerieren. Dazu verwendet man eine STAT-Sequenznummer . Ansonsten ist dies Ausführungsbeispiel eine Erweiterung des Ausführungsbeispiels 2.
Man führt den SSCOP-PDU Parameter N(SS) und die SSCOP Status Variable VR(SS) ein. Beim Generieren einer STAT-PDU wird N(SS) mit dem Wert VR(SS) gesetzt. VR(SS) ist die nächste STAT Sequenznummer, die die STAT-PDUs innerhalb eines Pollzyklus (ein Pollzyklus ist die Zeit zwischen dem Empfang zweier POLL-PDUs) durchnumeriert. Das modifizierte STAT-PDU Format ist in Abbildung 1 dargestellt. Da N(SS) in ein Feld geschrieben wird, das momentan als Reserved gekennzeichnet ist, kann auch eine nicht modifizierte SSCOP Protokoll Maschine solch eine Nachricht verarbeiten, da sie N(SS) nicht bearbeitet.
Wird eine POLL-PDU mit neuer Pollsequenznummer empfangen, so wird diese wie üblich behandelt. Nur bevor eine STAT-PDU generiert wird, wird noch VR(SS)=0 gesetzt. Soll nun innerhalb eines Pollzyklus eine weitere STAT-PDU generiert werden, um den Kredit zu modifizieren, so wird dies nur noch dann getan, falls VR(SS)<255 gilt. Andernfalls wird keine solche STAT-PDU generiert. (Dies ist jedoch eine akzeptable Einschränkung und in jedem Fall besser als überhaupt keine spontane Modifikation des Kredits zuzulassen.) Im Fall VR(SS) < 255 wird VR(SS) um 1 erhöht und dann eine STAT-PDU generiert .
Man braucht ferner noch zwei weitere SSCOP Status Variablen:
• VT (SS), dies ist die STAT-Sequenznummer der zuletzt im aktuellen Pollzyklus empfangenen STAT-PDU beziehungsweise
0, falls noch keine empfangen wurde.
• VT (H) , dies ist das größte letzte Listenelement aller empfangenen STAT-PDUs und USTAT-PDUs.
Die Bearbeitung von empfangenen POLL-PDUs und STAT-PDUs sowie die Verwaltung dieser neuen Statusvariablen ergibt sich aus den folgenden Regeln:
Wenn man eine USTAT-PDU empfängt, so verwirft man die Kreditinformation, falls List Element 2 <= VT (H) ist. Andernfalls bearbeitet man die Kreditinformation und setzt VT(H) = List Element 2.
Wenn man eine STAT-PDU empfängt, so setzt man VT (SS) = 0, falls VT (PA) < N(PS) gilt.
Gilt nun N(SS) < VT (SS), so verwirft man die Kreditinformation. Gilt N(SS) >= VT (SS), so setzt man VT (SS) = N(SS) und verwirft die Kreditinformation, falls das letzte Listenelement List element L < V (H) . Andernfalls nutzt man die Kreditinformation und setzt VT (H) = List Element L.

Claims

Patentansprüche
1. Protokolleinrichtung eines Protokoll-Systems zur Übertragung von Nachrichten, dadurch gekennzeichnet, daß die Protokolleinrichtung anhand der Protokollinformation, die in einer von ihr empfangenen Kontrollnachricht enthalten ist, feststellt, ob diese Kontrollnachricht eine Information beinhaltet, die neuer ist, als der aktuelle Informationsstand der Protokolleinrichtung und sie ihren Informationsstand aufgrund dieser Feststellung aktualisiert oder nicht.
2. Protokolleinrichtung nach Anspruch 1, dadurch gekennzeichnet, daß sie diejenigen Kontrollnachrichten zusätzlich durchnumeriert, für die sie die Reihenfolge der empfangenen Kontrollnachrichten aufgrund der genannten Protokollinformationen nicht rekonstruieren kann.
3. Protokolleinrichtung nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß es sich bei den Kontrollnachrichten um Nachrichten zur Flußkontrolle handelt.
EP00931216A 1999-06-24 2000-05-15 Protokolleinrichtung eines protokoll-systems zur übertragung von nachrichten Withdrawn EP1188288A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE19929002 1999-06-24
DE19929002 1999-06-24
PCT/EP2000/004355 WO2001001652A2 (de) 1999-06-24 2000-05-15 Protokolleinrichtung eines protokoll-systems zur übertragung von nachrichten

Publications (1)

Publication Number Publication Date
EP1188288A2 true EP1188288A2 (de) 2002-03-20

Family

ID=7912412

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00931216A Withdrawn EP1188288A2 (de) 1999-06-24 2000-05-15 Protokolleinrichtung eines protokoll-systems zur übertragung von nachrichten

Country Status (4)

Country Link
US (1) US20020138639A1 (de)
EP (1) EP1188288A2 (de)
CN (1) CN1363170A (de)
WO (1) WO2001001652A2 (de)

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5007051A (en) * 1987-09-30 1991-04-09 Hewlett-Packard Company Link layer protocol and apparatus for data communication
JPH06508008A (ja) * 1991-06-12 1994-09-08 ヒューレット・パッカード・カンパニー パケットベースネットワークをテストするための方法および装置
US5440545A (en) * 1993-08-02 1995-08-08 Motorola, Inc. Packet delivery system
US5793976A (en) * 1996-04-01 1998-08-11 Gte Laboratories Incorporated Method and apparatus for performance monitoring in electronic communications networks
US6134237A (en) * 1997-09-30 2000-10-17 Motorola, Inc. Method and apparatus for tracking data packets in a packet data communication system
US6356629B1 (en) * 1999-02-02 2002-03-12 Cisco Technology, Inc. Switched virtual circuit controller setup congestion management strategy
US6714516B1 (en) * 1999-04-30 2004-03-30 Alcatel Congestion control mechanism for SSCOP protocol

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
COHEN R.: "An improved SSCOP-like scheme for avoiding unnecessary retransmissions and achieving ideal throughput", PROCEEDINGS OF IEEE INFOCOM 1996, vol. 2 CONF. 15, 24 March 1996 (1996-03-24), LOS ALAMITOS, IEEE COMP. SOC. PRESS, US, pages 855 - 862, XP010158150 *
HEBUTERNE G.; WEI MONIN: "Service specific connection oriented protocol (SSCOP) with no credit limitation", BROADBAND COMMUNICATIONS. GLOBAL INFRASTRUCTURE FOR THE INFORMATION AGE, 23 April 1996 (1996-04-23), LONDON, CHAPMAN AND HALL, GB, pages 283 - 293, XP010525729 *

Also Published As

Publication number Publication date
CN1363170A (zh) 2002-08-07
WO2001001652A3 (de) 2001-05-25
US20020138639A1 (en) 2002-09-26
WO2001001652A2 (de) 2001-01-04

Similar Documents

Publication Publication Date Title
DE2148906C2 (de) Schaltungsanordnung zur Übertragung von Daten zwischen einem Rechner und einer Vielzahl von Endgeräten
DE3018945C2 (de) Verfahren und Einrichtung zur Überprüfung der Zulässigkeit einer Verbindung zwischen Datenübertragungsnetz-Teilnehmern
EP0009627B1 (de) Übertragungssystem zum Fernkopieren und zur elektronischen Übermittlung von Hauspost
EP0788283B1 (de) Verfahren zum Konvertieren von unterschiedliche Formate aufweisenden Nachrichten in Kommunikationssystemen
EP0382680A1 (de) Verfahren zum kryptographischen Behandeln von Daten und kryptographisches System
EP3949309B1 (de) Digitales zertifikat und verfahren zum sicheren bereitstellen eines öffentlichen schlüssels
DE69828544T2 (de) Verfahren und Vorrichtung zum Nachrichtenaustausch zwischen mehreren Nachrichtenaustauschdiensten
DE3139960A1 (de) Datengeraet-diagnosesystem
EP0618703A2 (de) Verfahren für Punkt-zu-Mehrpunkt-Verbindungen in selbstroutenden ATM-Koppelfeldern
DE19843810A1 (de) Datenbus
DE4037723A1 (de) Verfahren zum uebermitteln von an mehreren datenschnittstellen einer prozessorgesteuerten einrichtung vorliegenden informationen an deren prozessoreinrichtung
WO2001099440A2 (de) Verfahren zur übertragung von kurznachrichten
DE1437643B2 (de) Informationsaustausch-Pufferverfahren und Einrichtung zur Durchführung dieses Verfahrens
DE2423195A1 (de) Wartungsvorrichtung
DE60016430T2 (de) Verfahren und system zur übertragung einer meldungskette für datenbanken
EP1188288A2 (de) Protokolleinrichtung eines protokoll-systems zur übertragung von nachrichten
DE10084674B4 (de) Verfahren und Anordnung zum Verhindern von Metastabilität
DE2131063C3 (de) Gerät zum Ver- und Entschlüsseln von empfangenen, mehrstellig codierten Signalen
WO1998002991A1 (de) Verfahren zur schlüsselverteilung zwischen zwei einheiten in einer isdn/internet verbindung
DE19906134B4 (de) Anbindung eines ressourcenbeschränkten, prozessorbasierten Systems an einen Mechanismus zur Signalisierung von Nachrichten
DE10340865B3 (de) Verfahren und System zur Handhabung von Daten sowie Automatisierungssystem mit mehreren Automatisierungseinrichtungen
DE1111239B (de) Selbstaendiges Mischgeraet mit einem Entzerrer zum zeichenelementweisen Ver- bzw. Entschluesseln
EP1668850A1 (de) Verfahren zur nachrichten bertragung in einem netzwerk
DE10220489A1 (de) Adressierverfahren
WO2001024069A2 (de) Verfahren zum austausch von daten in einem computernetzwerk

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20011205

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

17Q First examination report despatched

Effective date: 20021029

RBV Designated contracting states (corrected)

Designated state(s): DE ES GB IT

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS S.P.A.

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20071218