EP1440543A1 - Procede, dispositif recepteur et dispositif emetteur permettant de determiner le chemin de messages le plus rapide sans synchronisation des horloges - Google Patents

Procede, dispositif recepteur et dispositif emetteur permettant de determiner le chemin de messages le plus rapide sans synchronisation des horloges

Info

Publication number
EP1440543A1
EP1440543A1 EP02785146A EP02785146A EP1440543A1 EP 1440543 A1 EP1440543 A1 EP 1440543A1 EP 02785146 A EP02785146 A EP 02785146A EP 02785146 A EP02785146 A EP 02785146A EP 1440543 A1 EP1440543 A1 EP 1440543A1
Authority
EP
European Patent Office
Prior art keywords
message
receiving device
messages
transmitting device
path
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
EP02785146A
Other languages
German (de)
English (en)
Inventor
Hanns Jürgen SCHWARZBAUER
Michael TÜXEN
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
Priority to EP02785146A priority Critical patent/EP1440543A1/fr
Publication of EP1440543A1 publication Critical patent/EP1440543A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/12Shortest path evaluation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/50Testing arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/12Shortest path evaluation
    • H04L45/121Shortest path evaluation by minimising delays

Definitions

  • Secured transport protocols usually measure the round trip delay, i.e. the total delay that occurs in the transmission of a message from a sender to a receiver and the transmission of another message, e.g. a confirmation message that occurs from the receiver to the sender in order to derive therefrom when messages have to be repeated.
  • Typical examples of such secure transport protocols are Transmission Control Protocol TCP according to IETF RFC 793 and Stream Control Transmission Protocol SCTP according to IETF RFC 2960.
  • the sending time of a message is noted in the transmitter and the receiving time of a confirmation message arriving from the recipient of the sent message is determined.
  • the round trip delay is determined from the difference between these times. Clock synchronization is not required for this procedure.
  • the value of the round trip delay determined does not allow any conclusions to be drawn about the one-way delays from the transmitter to the receiver and vice versa. Even if the transmission of the messages from the sender to the recipient takes place on the same message path as the transmission of the confirmation messages from the recipient to the sender, the determined value of the round trip delay does not allow conclusions to be drawn about the one-way delays from the sender to the recipient and vice versa, since the Message path can be highly unbalanced.
  • the sender may be expedient to send the messages on the message path on which they are transmitted the fastest to the recipient. To do this, the sender must have information as to which message path is the fastest. The fastest message path can be determined based on the one-way delays of all message paths from the sender to the receiver.
  • clock synchronism means that the clocks or clock generators run at the same speed, but do not necessarily have the same absolute times. If the clock is synchronized, any message or a message provided by the transmitter with a time stamp, which is provided for measuring purposes, is sent from the transmitter to the receiver.
  • the one-way delay for the relevant message path can be determined by the receiver from the difference between the time of reception and the time stamp. In order to determine the fastest from a number of existing message paths, the method must be repeated in a suitable manner for all message paths. By comparing the one-way delays determined by the receiver for all message paths, it is easily possible in the receiver to identify the fastest message path and to signal this to the sender.
  • the object on which the present invention is based is to improve the known methods, receiving devices and transmitting devices for determining the fastest message path. This object is achieved by the features of patent claims 1, 9 and 15.
  • An important advantage of the method according to the invention is that clock synchronization of the transmitter and receiver is not necessary in order to determine the fastest message path between the transmitter and receiver. This is based on the idea that to determine the fastest message path it is not necessary to know the absolute delay times on the different message paths, but rather that it is sufficient to send one message each on several message paths to be examined and using the
  • Message runtimes are determined, i.e. the delays caused by each individual message path compared to the fastest message path - claim 2. This can be used, for example, for load sharing between two or more message paths if the transit times of the message paths differ only slightly, i.e. the determined relative runtimes of these message paths in relation to the fastest message path are sufficiently short.
  • the messages that are sent by the transmitter to determine the fastest message path or to measure the relative transit times are advantageously sent at the same time or with a short time interval - claim 4. If the communication protocol used and / or the sending device, the simultaneous sending of messages to more - If the message paths are not provided, a short time interval between these messages can be provided.
  • FIG. 1 shows a receiving device E and a transmitting device S as well as three messages sent via three different message paths P1, P2, P3 between receiving device E and transmitting device S from transmitting device S to receiving device E at time TO, which are sent at different times T1, T2 , T3 can be received by the receiving device E.
  • the relative message transit times .DELTA.T2, .DELTA.T3 of the message paths P2, P3 are shown in relation to the fastest message path P1.
  • FIG. 2 shows the receiving device E and the transmitting device S as well as a request message DelayReq sent from the receiving device E to the transmitting device S and three identical messages sent at the time T0 by the transmitting device S to the receiving device E on the three different message threads P1, P2, P3 Confirmation messages DelayRes that are received by the receiving device E at different times T1, T2, T3.
  • the transmitting device S sends a message to the receiving device E on a plurality of message paths P1, P2, P3.
  • the fastest message path P1 can be determined by the receiving device E on the basis of the reception sequence.
  • the absolute reception time T1 and the absolute delay time between the transmitting device S and the receiving device E expressed by the formula T1-T0, are irrelevant. It is only important that the first of the identical messages that were sent at the same time or with negligible time intervals were received via the first message path P1.
  • the first message path P1 is thus determined as the fastest message path.
  • the time differences between the receipt of the identical messages via the various message paths P1, P2, P3 can also be used to determine the relative running time differences ⁇ T2, ⁇ T3, i.e. the delay times that occur on all message paths P2, P3 compared to the fastest message path P1.
  • the relative transit time ⁇ T1 of the fastest message path Pl represents a special case.
  • ⁇ T1 0 - not shown. If the relative message transit times .DELTA.T1, .DELTA.T2, .DELTA.T3 are transmitted to the transmitting device S, this ensures that the transmitting device S recognizes the fastest message path P1 without this having to be signaled separately.
  • the receiving device E To determine the fastest message path P1 or the relative message transit times, the receiving device E only has to be able to recognize that the messages were sent at the same time. This can e.g. by a time stamp in the messages, a specific message type with sequence numbers or simply derived from the protocol itself.
  • the described method is used independently in both directions - not shown.
  • message elements, notifications or parameters embedded in ordinary messages can also be used to carry out the method according to the invention.
  • a request message element DelayReq is then used.
  • either the already mentioned confirmation messages DelayRes can be sent, or another message type is used, in which a corresponding confirmation message element DelayRes is embedded.
  • SCTP Stream Control Transmission Protocol
  • IP address Internet Protocol address
  • an SCTP endpoint E can set the primary path or primary message path of a communication partner S, that is, E can determine the path on which the communication partner S sends messages to the endpoint E. This extension is used to signal which message path is the fastest.
  • An SCTP message consists of a common header and a number of chunks. This number of chunks can vary with which SCTP messages are different, it is also permissible to use messages without chunks. Each chunk is classified by a chunk type - a number between 0 and 255.
  • the method described here uses special new chunk types (DelayReq (SN), DelayRes (SN)) with a sequence number SN. SCTP allows such extensions. It is possible to maintain interoperability with SCTP endpoints for which these new chunks are not implemented.
  • the receiving device E sends a request message DelayReq (SN) in order to initiate a measurement. In the next measurement, the sequence number used is SN + 1, ie an additional counter is passed through the receiving device E.
  • a request message DelayReq (SN) is received by the transmitting device S, then a confirmation message DelayRes (SN) is sent on some or all of the available message paths P1, P2, P3.
  • the receiving device E can then determine which message path P1, P2, P3 is the fastest.
  • the fastest message path P1 is given by the destination IP address or destination IP address of the confirmation message, which contains the DelayRes (SN) chunk and is received first.
  • This IP address is now reproduced with the message "Set Primary IP Address" (setting of the primary IP address, described in 3.2.5 and 4.4 of the IETF Internet Drafts draft-ietf-tsvwg-addip-sctp-02, below) ) signals to the transmitting device S, which will then always use this message path P1 as the first one for data transmission.
  • the frequency of these measurements depends on the stability of the network. However, it makes sense, for example, to carry out such measurements periodically.
  • the heartbeat and heartbeat-ack chunks can also be used to determine the fastest message path P1, P2, P3.
  • heartbeat-ack chunks are then sent on some or all message paths, instead of the DelayRes chunks in the above embodiment. This procedure also ensures interoperability with other implementations.
  • the introduction of new chunk types can also be dispensed with, but the behavior of the protocol must be adapted accordingly.
  • This field contains an IPv4 or IPv6 address parameter as described in 3.3.2.1 of [RFC2960].
  • the complete TLV is wrapped within this parameter. It requests the receiver to mark the specified address as the primary address to send data to (see section 5.1.2 of [RFC2960]). The receiver MAY mark this as its primary upon receiving this request.
  • TLV requesting that the IPv4 address 10.1.1.1 be made the primary destination address would look as follows:
  • the Set Primary IP Address parameter may appear in the ASCONF Chunk, the INIT, or the INIT-ACK chunk type.
  • the inclusion of this parameter in the INIT or INIT-ACK can be used to indicate an initial preference of primary address.
  • a sender of this option may elect to send this combined with a deletion or addition of an address.
  • a request to set primary MAY also appear in a INIT or INIT-ACK chunk. This can give advice to the peer endpoint as to which of its addresses the sender of the INIT or INIT-ACK would like to be used as the primary address.
  • the request to set an address as the primary path is an option the receiver SHOULD perform. It is considered advice to the receiver of the best destination address to use in sending SCTP packets (in the requester's view). If a request arrives that asks the receiver to set an address as primary that does not exist, the receiver should NOT honor the request, leaving its existing primary address unchanged.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne des protocoles de transport sécurisés qui normalement mesurent le temps de transmission aller-retour pour déduire quand il faut répéter les messages. Des exemples typiques de tels protocoles de transport sécurisés sont le protocole de contrôle de transmission TCP conformément à IETF RFC 793 et le protocole de transmission de contrôle de flux SCTP conformément à IETF RFC 2960. Il est généralement impossible de déduire le temps de transmission à l'aller à partir du temps de transmission aller-retour. Si un émetteur (S) dispose de plusieurs chemins de messages (P1, P2, P3) pour envoyer les messages à un récepteur (E), il peut s'avérer favorable d'envoyer les messages au chemin de messages (P1) qui permet la retransmission la plus rapide au récepteur. A cet effet, l'émetteur (S) doit contenir des informations précisant le chemin de messages (P1, P2, P3) le plus rapide. Selon l'invention, cela ne nécessite pas de synchronisation des horloges de l'émetteur (S) et du récepteur (E). L'invention est fondée sur l'idée que pour déterminer le chemin de messages (P1) le plus rapide, on n'a pas besoin de connaître les temps de transmission absolus des différents chemins de messages (P1, P2, P3) mais il suffit d'envoyer respectivement un message (DelayRes) par chaque chemin de messages (P1, P2, P3) à examiner et de reconnaître, à l'appui de la séquence de réception, le chemin de messages (P1) le plus rapide.
EP02785146A 2001-10-31 2002-10-01 Procede, dispositif recepteur et dispositif emetteur permettant de determiner le chemin de messages le plus rapide sans synchronisation des horloges Withdrawn EP1440543A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP02785146A EP1440543A1 (fr) 2001-10-31 2002-10-01 Procede, dispositif recepteur et dispositif emetteur permettant de determiner le chemin de messages le plus rapide sans synchronisation des horloges

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP01126009 2001-10-31
EP01126009A EP1309133A1 (fr) 2001-10-31 2001-10-31 Méthode et dispositifs d'émission et de réception pour la détermination de la voie de donnée la plus rapide sans synchronisation des horloges
PCT/EP2002/011013 WO2003039081A1 (fr) 2001-10-31 2002-10-01 Procede, dispositif recepteur et dispositif emetteur permettant de determiner le chemin de messages le plus rapide sans synchronisation des horloges
EP02785146A EP1440543A1 (fr) 2001-10-31 2002-10-01 Procede, dispositif recepteur et dispositif emetteur permettant de determiner le chemin de messages le plus rapide sans synchronisation des horloges

Publications (1)

Publication Number Publication Date
EP1440543A1 true EP1440543A1 (fr) 2004-07-28

Family

ID=8179137

Family Applications (2)

Application Number Title Priority Date Filing Date
EP01126009A Withdrawn EP1309133A1 (fr) 2001-10-31 2001-10-31 Méthode et dispositifs d'émission et de réception pour la détermination de la voie de donnée la plus rapide sans synchronisation des horloges
EP02785146A Withdrawn EP1440543A1 (fr) 2001-10-31 2002-10-01 Procede, dispositif recepteur et dispositif emetteur permettant de determiner le chemin de messages le plus rapide sans synchronisation des horloges

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP01126009A Withdrawn EP1309133A1 (fr) 2001-10-31 2001-10-31 Méthode et dispositifs d'émission et de réception pour la détermination de la voie de donnée la plus rapide sans synchronisation des horloges

Country Status (6)

Country Link
US (1) US20050030900A1 (fr)
EP (2) EP1309133A1 (fr)
JP (1) JP2005507610A (fr)
KR (1) KR20040053226A (fr)
CN (1) CN100342699C (fr)
WO (1) WO2003039081A1 (fr)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8812706B1 (en) 2001-09-06 2014-08-19 Qualcomm Incorporated Method and apparatus for compensating for mismatched delays in signals of a mobile display interface (MDDI) system
TWI374635B (en) 2003-06-02 2012-10-11 Qualcomm Inc Generating and implementing a signal protocol and interface for higher data rates
US8705571B2 (en) 2003-08-13 2014-04-22 Qualcomm Incorporated Signal interface for higher data rates
RU2369033C2 (ru) 2003-09-10 2009-09-27 Квэлкомм Инкорпорейтед Интерфейс высокоскоростной передачи данных
CN102801595A (zh) 2003-10-15 2012-11-28 高通股份有限公司 高数据速率接口
BRPI0508582A (pt) 2004-03-10 2007-08-14 Qualcomm Inc equipamento e método de interface de alta taxa de dados
US8650304B2 (en) 2004-06-04 2014-02-11 Qualcomm Incorporated Determining a pre skew and post skew calibration data rate in a mobile display digital interface (MDDI) communication system
KR100882166B1 (ko) 2004-06-04 2009-02-06 퀄컴 인코포레이티드 고 데이터 레이트 인터페이스 장치 및 방법
EP1978694B1 (fr) 2004-06-04 2011-05-25 QUALCOMM Incorporated Appareil d'interface à débit de données élevé et procédé correspondant
US7443801B2 (en) * 2004-10-28 2008-10-28 Telcordia Technologies, Inc. Remote estimation of round-trip delays in a data network
US8667363B2 (en) 2004-11-24 2014-03-04 Qualcomm Incorporated Systems and methods for implementing cyclic redundancy checks
US8873584B2 (en) 2004-11-24 2014-10-28 Qualcomm Incorporated Digital data interface device
US8539119B2 (en) 2004-11-24 2013-09-17 Qualcomm Incorporated Methods and apparatus for exchanging messages having a digital data interface device message format
US8692838B2 (en) 2004-11-24 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
US8699330B2 (en) 2004-11-24 2014-04-15 Qualcomm Incorporated Systems and methods for digital data transmission rate control
US8692839B2 (en) 2005-11-23 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
EP2738995A1 (fr) 2012-11-30 2014-06-04 Thomson Licensing Procédé et équipement multi-connexions pour établir une connexion par trajets multiples
CN105009557B (zh) * 2013-01-22 2018-10-26 统一有限责任两合公司 在被呼叫终端中的无答复定时器上显示和操纵呼叫转接
US10939400B2 (en) * 2017-12-19 2021-03-02 Qualcomm Incorporated Time synchronization techniques for wireless communications
CN111556559B (zh) * 2020-05-09 2021-11-26 重庆邮电大学 基于免时间戳交互与单向消息传播的混合时钟同步方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4974224A (en) * 1989-11-07 1990-11-27 Harris Corporation Distributed split flow routing mechanism for multi-node packet switching communication network
US5150360A (en) * 1990-03-07 1992-09-22 Digital Equipment Corporation Utilization of redundant links in bridged networks
SE515148C2 (sv) * 1993-06-23 2001-06-18 Ericsson Telefon Ab L M Styrning av cellväljare
DE4416720C1 (de) * 1994-05-11 1995-03-23 Siemens Ag Verfahren und Schaltungsanordnung zum Synchronisieren von redundant übertragenen Nachrichtenzellenströmen
US6016307A (en) * 1996-10-31 2000-01-18 Connect One, Inc. Multi-protocol telecommunications routing optimization
DE19713049C2 (de) * 1997-03-27 1999-07-15 Siemens Ag Verfahren zur Ermittlung der Differenz der Übertragungsdauer zwischen redundanten Übertragungswegen
US6487172B1 (en) * 1998-08-21 2002-11-26 Nortel Networks Limited Packet network route selection method and apparatus using a bidding algorithm
JP2002176441A (ja) * 2000-12-08 2002-06-21 Fujitsu Ltd 通信装置
US7012893B2 (en) * 2001-06-12 2006-03-14 Smartpackets, Inc. Adaptive control of data packet size in networks

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO03039081A1 *

Also Published As

Publication number Publication date
US20050030900A1 (en) 2005-02-10
JP2005507610A (ja) 2005-03-17
KR20040053226A (ko) 2004-06-23
EP1309133A1 (fr) 2003-05-07
CN1579074A (zh) 2005-02-09
WO2003039081A1 (fr) 2003-05-08
CN100342699C (zh) 2007-10-10

Similar Documents

Publication Publication Date Title
EP1440543A1 (fr) Procede, dispositif recepteur et dispositif emetteur permettant de determiner le chemin de messages le plus rapide sans synchronisation des horloges
DE60220592T2 (de) Taktsynchronisation durch Teilnetzwerke
DE69533579T2 (de) Synchronisierung in einem Datenkommunikationsnetzwerk
DE10113261C2 (de) Synchrones, getaktetes Kommunikationssystem mit dezentralen Ein-/Ausgabe-Baugruppen und Verfahren zur Einbindung dezentraler Ein-/Ausgabe-Baugruppen in ein solches System
DE60037660T2 (de) Auf-anfrage überlagerungsrouting für rechnerbasierte communicationsnetzwerke
DE60310749T2 (de) Verfahren zur bestimmung eines timing-offset zwischen einem ersten takt und einem zweiten takt in einem kommunikationsnetz
DE19983761B3 (de) Vorrichtung und Verfahren zum Sammeln und Analysieren von Kommunikationsdaten
EP2523397B1 (fr) Method and device for operating wind park grids with improved data transfer protocol
EP2258082B1 (fr) Procédé d'attribution dynamique de bande passante sécurisée sur tt-ethernet
WO2002049274A2 (fr) Procede pour faire fonctionner un reseau ad-hoc pour la transmission de donnees sans fil de messages synchrone et asynchrone
DE102006024965A1 (de) Verfahren zum Messen einer Zeitverzögerungsmetrik und Messsystem
DE102005029438A1 (de) System und Verfahren zur stabilen Kommunikation über ein unzuverlässiges Protokoll
DE10361178B4 (de) Datenalterungsüberwachungsvorrichtung für Sicherheitsnetzwerke
DE602004011484T2 (de) Verfahren und Vorrichtung zum Synchronisieren von Uhren von Netzknoten
DE60131765T2 (de) Verfahren zur verbindung mehrerer kommunikationsbusse mit drahtlosen verbindungen
DE69833206T2 (de) Netzwerkkontrolle zum verarbeiten von statusproblemen
WO2018162071A1 (fr) Procédé et dispositif permettant l'orientation modulaire d'un flux avb
DE60123935T2 (de) Synchronisierte datenübermittlung
EP1413114A1 (fr) Procede de support de plusieurs algorithmes de checksum (somme de controle) dans un noeud de reseau
EP3910886B1 (fr) Dispositif et procédé de transmission de données sur une pluralité de canaux de transmission de données
DE602004001196T2 (de) Verfahren und Vorrichtung zur Datenübertragung für hybride isochrone/asynchrone Netzwerke
EP2263399B1 (fr) Procédé et système de communication pour la détermination de la qualité d'au moins une liaison ip entre un dispositif mobile et un serveur lié avec un réseau de communication public à base ip
EP2822224B1 (fr) Détermination de paramètres de performance unidirectionnelle dans un sous-réseau de communication par paquet
EP4040736B1 (fr) Système, dispositif et procédé de transfert de données entre deux réseaux
EP3513500B1 (fr) Synchronisation de noeuds de transmission

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: 20040408

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

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 IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20090430