WO2009138365A1 - Procédé de communication entre une unité source et une unité destination et nœud de communication - Google Patents

Procédé de communication entre une unité source et une unité destination et nœud de communication Download PDF

Info

Publication number
WO2009138365A1
WO2009138365A1 PCT/EP2009/055603 EP2009055603W WO2009138365A1 WO 2009138365 A1 WO2009138365 A1 WO 2009138365A1 EP 2009055603 W EP2009055603 W EP 2009055603W WO 2009138365 A1 WO2009138365 A1 WO 2009138365A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
unit
source
destination
acknowledgement
Prior art date
Application number
PCT/EP2009/055603
Other languages
English (en)
Inventor
Andrei Radulescu
Peter Van Den Hamer
Original Assignee
Nxp B. V.
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 Nxp B. V. filed Critical Nxp B. V.
Publication of WO2009138365A1 publication Critical patent/WO2009138365A1/fr

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/30Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes

Definitions

  • the present invention relates to a method of communication between a source unit and a destination unit and communication node.
  • the Mobile Industry Processor Interface alliance MIPl has defined a standard for chip-to-chip networks based on high-speed serial links, i.e. the UNIfied PROtoeo! or UniPro (www.mipi.org), UniPro relates to a general purpose protocol addressing high-speed interconnect issues, e.g. like error handling, flow control, routing and arbitration.
  • UniPro may be used as a communication protocol for a digital link e. g. between the radio frequency RF chip and baseband BB chip in electronic devices with a two- chip modem solution. Such a two-chip solution is preferably used in mobile devices,
  • the modem solution may include 802.11 modems WiFi, video on mobile TVoM or WiMAX protocols, UniPro includes two communication services, namely a connection orientated
  • connection-oriented communication For a connection orientated communication, a connection needs to be set up allocating states as well as resources (like buffers).
  • the connection orientated communication can implement an end-to-end flow control based on credits. This may be performed for example to prevent a buffer overflow. Due to the fact that the UniPro links are reliable (no data loss or data corruption) and that the end-to-end flow control prevents buffer overflow at the edges of the network the data communication using a connection is reliable.
  • connection- less communication is intended for a simple and quick communication without the need to set up connections, although the communication may be performed over a reliable network, it may occur at the interfaces or edges of the network that data is lost. This can for example occur if the receiver of the data is not able to receive the data due to a buffer overflow at its input.
  • Fig. 1 shows a schematic representation of a frame structure in UniPro for a connection orientated communication.
  • a connection between a transmitting/source and receiving/destination device must be present before any data can be transmitted.
  • the communication requires a device access point CPort, wherein the state thereof may contain a device ID and the device access point CPort of a peer device, the traffic class of the connection and the end-to-end flow control state.
  • Fig. 1 the data frame format of a connection orientated communication is depicted.
  • Each frame comprises a header and a trailer.
  • the header comprises an escape byte ESCJDL, a symbol control ID field CTRLJD, a field for the traffic class TCx and three reserved bits R.
  • the escape byte ESC JDL can be converted to an escape symbol of the physical layer and can denote a control symbol.
  • the symbol control ID CTRLJD may constitute a start of frame SOF.
  • the traffic class TCx can have a value of O or 1. Other values of TCx may be allowed in future versions of UniPro.
  • the trailer of the frame comprises an end of frame control symbol EOF and a CRC symbol for error detection.
  • the end of frame symbol EOF may comprise an escape byte ESCJDL, a symbol control ID field CTRLJD which may correspond to an end of frame EOF and a frame sequence number SN,
  • the packet (in L3 the protocol data unit PDU) comprises the L3s bit and a destination device ID DDID.
  • the L3s bit is set to 1 in order to indicate a short L3 header.
  • the segment (L4 PDU) comprises a header with a L4s bit, a destination CPort
  • the bit of the L4s bit is set to 1 in order to indicate a short L4 header,
  • the flow control bit FCT is used to transmit end-to-end flow control credits to a destination device.
  • the applica ⁇ tio ⁇ merely needs to deliver data and to indicate the boundaries of the message,
  • the rest of the information required for a transfer is provided by UniPro based on the device access point CPort state.
  • Fig. 2 shows a schematic representation of a further potential frame structure in UniPro based on a connection-orientated communication.
  • the schematic representation of the frame structure according to Fig. 2 substantially corresponds to the frame structure according to Fig, 1.
  • a frame length FL is used in order to indicate the boundaries of a frame. Therefore, a data symbol related to the frame length I L is inserted after the start of frame control symbol SOF.
  • the frame length FL data symbol comprises the frame length FL and the frame sequence number FSN. As the boundaries of the frame are defined by the frame length, an end of file control symbol is not required any more.
  • Fig. 3 shows a schematic representation of a frame structure in a Unified Protocol based on a connection-less communication.
  • the data to be sent can be packetized and sent via the network.
  • the overhead of the communication will increase as for example a source port, a source device ID, a protocol ID, etc. must be included in the packet header.
  • the connection- less communication does not implement an end-to-end flow control.
  • a destination device may discard data if the destination device cannot accept the data, for example due to a buffer overflow.
  • a data access point RPort is required for the connection-less communication.
  • the header of a frame structure of a connection- less communication corresponds to the header of a frame structure of a connection orientated communication as shown in Fig, 1.
  • the trailer of the connection-less data structure corresponds to the trailer of the connection orientated frame structure.
  • the L3 header includes a destination device ID DDID, a source device f ⁇ SDlD and a bit Ext for each L3 symbol.
  • the source device ID SDlD can be used for information relating to the source of the packets.
  • the L4 header comprises a destination port DP, a bit Ver, a source port SP, a
  • the bit Ver is set to 0 to indicate a first generation PDU version.
  • the bit may also be set to 1 to indicate a new layer for PDU.
  • the bit Ext is set to 1 to indicate a further extensions follow in the L4 header, otherwise it indicates the end of the L4 header.
  • One such extension may carry the protocol ID field PID relates to the communication protocol which is used by the application.
  • the boundaries of a message in a connection- less communication is set by the application.
  • the destination device ID DID, the RPort and optionally the protocol ID PlD can be specified by the application.
  • messages can be packetized without being segmented.
  • the frame structure according to Fig, 4 corresponds to the frame structure according to Fig. 3.
  • a frame length field can be used instead of an end of file control symbol to define the boundaries of a frame.
  • the frame length field can be inserted after the start of file control symbol and may comprise information with respect to the frame length and the frame sequence number.
  • a method of communicating between at least one source unit and at least one a destination unit over a reliable network having boundaries at which data can be dropped is provided.
  • At least one message is transmitted from one of the at least one source units to a destination unit.
  • the at least one message contains information on the sending source unit and a payload.
  • At least one acknowledgement is transmitted from the receiving destination unit to the transmitting source unit after receiving the at least one message.
  • a message is transmitted from the transmitting source unit to the destination unit indicating that the end of transmission of the at least one messages after receiving the at least one acknowledgement from the destination unit.
  • a timer unit is started by the transmitting source unit when at least one message is transmitted.
  • the at least one transmitted message is re-transmitted if the timer unit has reached a specific value and no acknowledgement has been received by the transmitting source unit.
  • the message received by the destination unit is rejected if it has already received a message from the transmitting source unit and has transmitted an acknowledgement.
  • space is allocated in a buffer of the at least one source unit in order to guarantee the ability to receive at least one message
  • the invention also relates to a communication node which can be coupled to a reliable network having boundaries at which data can be dropped.
  • the communication node comprises a source device having a source buffer, a timer unit for initiating a timer when at least one message has been sent, an acknowledgement receiving unit for receiving acknowledgment signals and a done message sending unit for sending a done message if acknowledgement messages from all transmitted messages have been received.
  • the timer unit is furthermore adapted to stop the timer if an acknowledgement message is received.
  • the source buffer is adapted for buffering messages which have been transmitted from the source until an acknowledgement message has been received by the acknowledgement receiving unit.
  • the tinier unit can be restarted for each message which is transmitted.
  • the invention also relates to a communication node coupled to a reliable network having boundaries at which data can be dropped.
  • the communication node comprises a destination device having a source identification unit for identifying a source unit of a received message, a destination buffer for buffering received messages, an acknowledgement sending unit for sending at least one acknowledgement message for at least one received message and a done message receiving unit for receiving a done message and for releasing reserved space in the destination buffer.
  • a communication node may comprises a source device as well as a destination device as described above. Further aspects of the invention are defined in the dependent claims.
  • Fig. 1 shows a schematic representation of a frame structure in UniPro based on a connection orientated communication
  • Fig. 2 shows a schematic representation of a further frame structure in UniPro based on a connection orientated communication
  • Fig. 3 shows a schematic representation of a frame structure in UniPro based on a connection-less communication
  • Fig. 4 shows a schematic representation of a further frame structure in UniPro based on a connection-less communication
  • Fsg. 5 shows a basic representation of a system according to a first embodiment
  • Fig. 6 shows a basic representation of a system according to a second embodiment
  • Fig. 7 shows a basic representation of a system according to a third embodiment
  • Figs. 8A and 8B show a basic representation of a frame structure according to the invention
  • Fig. 9 shows a basic representation of a frame structure according to the invention
  • Fig. 10 shows a flow chart of an operation of a source in a system according to a fourth embodiment
  • Fig, 1 1 shows a flow chart of an operation of a destination device in a system according to a fifth embodiment
  • Fig. 12 shows a basic representation of a system according to a sixth embodiment
  • Fig. 13 shows a basic representation of a system according to a seventh embodiment
  • Fig. 14 shows a basic representation of a system according to an eighth embodiment
  • Fig. 15 shows a flow chart of an operation of a transmitter of a source in a system according to a ninth embodiment
  • Fig. 16 shows a flow chart of an operation of a source according to a tenth embodiment
  • Fig. 37 shows a flow chart of an operation of a source in a system according to an eleventh embodiment
  • Fig. 18 shows a flow chart of an operation of a receiver of a source in a system according to a twelfth embodiment
  • Fig. 19 shows a flow chart of an operation of a destination device in a system according to a thirteenth embodiment
  • Fig. 20 shows a flow chart of an operation of a destination device in a system according to a fourteenth embodiment.
  • the communication according to the invention can be based on the UniPro protocol as designed by the Mobile Industry Processor Interface Alliance MIPf, i.e. the communication may be performed over an UniPro network.
  • the Communication according to the present invention is based on a three message exchange which can enable a reliable message communication.
  • the protocol data unit PDU encoding can be a) that a device access port CPort bit is set to 1, indicating that the used port has state (as opposed to an RPort).
  • the reliable messaging scheme described in this invention would then be identified by the L4 header extensions which differentiate the reliable messaging from the pure connection oriented communication) or that b) the CPort bit is set to O, indicating the port is not CPort but RPort or TCOPort.
  • the fact that the PDU is TCO is encoded by the L4 header extensions added to the PDU).
  • the embodiments of the invention are related to a communication based on UniPro. Accordingly, a communication may be performed from a source device via a network to a destination device.
  • the network is preferably a reliable and an ordered network. This means that the network does not allow a data corruption, a data loss or a data duplication. Furthermore, the network allows that all data is delivered at the destination in the same order as it has been sent from the source device. However, if a connection-less communication is performed based on the Unified Protocol, L4 data units (messages or datagrams) inay be lost due to a buffer overflow.
  • the communication scheme according to the invention does not require that a connection is present before starting to communicate.
  • connection-less communication may be faster as it is not necessary to wait for the establishment of a connection.
  • the communication scheme according to the invention will be less efficient in terms of the overhead compared to the connection orientated communication.
  • the advantages of the (connection-less) communication according to the invention will become evident if short and urgent messages need to be exchanged.
  • the communication according to the invention can be performed by a three- way handshake per message or by pipelined messages using sequence numbers (e.g. one acknowledgment for N messages).
  • sequence numbers e.g. one acknowledgment for N messages.
  • the pipeline connectionless message will be acknowledged and resources are freed by means of an explicit message. Although this will improve the message to message delay and reduce the number of internal messages, it will also require a higher buffering for the message retransmission in case of errors,
  • Fig. 5 shows a basic representation of a system according to a first embodiment.
  • a source device S, a network N and a destination device D are depicted.
  • the first embodiment according to Fig. 5 is related to a reliable message communication scheme using a three-way handshake.
  • This type of reliable messaging communication is also called transactiona] connection-oriented (TCO) communication.
  • the three-way handshake will comprise a data packet TCOPckt transmitted from a source device S via the reliable network N to a destination device D.
  • the destination device D will acknowledge Ack the TCO packet TCOPckt.
  • a done message DO sent from the source S to the destination device D will complete the three-way handshake, and will indicate that no further TCO messages are transmitted.
  • the source device S comprises a source buffer BS, a timer unit TU, an acknowledgment receiving unit AR and a done message sending unit DS.
  • a copy of the TCO message which is being sent is stored in the source buffer BS. This is advantageous if the message must be retransmitted.
  • the timer unit TU is started when the data message TCO is sent. By means of the timer unit TU, it can be detected whether the "connection-less" message is lost on the destination side.
  • the source device S needs to reserve some space in the source buffer BS and needs to be ready to receive an acknowledgment Ack from a destination device D by the acknowledgement receiving unit AR. As soon as the acknowledgement Ack by the destination device D is received by the acknowledgement receiving unit AR, the saved copy of the sent message can be discarded from the buffer BS.
  • the time unit TU can be stopped and the done message DO can be forwarded to the destination device.
  • the destination device comprises a destination buffer BD, a source identification unit SI, a done message receiving unit DR and an acknowledgment sending unit AS and receives the TCO message and identifies in the source identification unit SI the source S by means of its device ID DID and its port which form part of the received message.
  • This information about the source device is stored until the done message DO is received from the source device S, This is performed by the done message receiving unit DR.
  • the destination device D can determine based on the information about the source whether any duplicated messages (re-transmitted) are received.
  • the destination device D receives a (connection-less) message, it must be able to receive a done message DO, for example sufficient buffer space must be provided in the buffer BD.
  • the destination device D comprises an acknowledgement sending unit AS for sending an acknowledgement when it has received a message from the source unit S.
  • the source device S can only send further TCO messages to the same destination device D after ⁇ t has received the acknowledgement Ack from the destination device D and after it has sent the done message DO.
  • a destination port TCOPort may be able to send and receive several TCO messages from different ports TCOPort from the sources concurrently if sufficient buffer space for each source device S is reserved. For example, due to hardware implementations, only a limited number of states can be reserved such that the number of concurrent TCO messages can be limited to the number of the states. If the destination device D has not sufficient states available, any further TCO messages cannot be accepted. On the other hand, a source device S may send multiple TCO messages to different destination devices if it has a timer unit TU and a retransmission buffer BS associated to each of the TCO messages.
  • Fig. 6 shows a basic representation of a system according to a second embodiment.
  • the source device S and the destination device D according to the second embodiment correspond to the source device S and the destination device D according to the first embodiment.
  • the second embodiment relates to the situation that the TCO message TCOpckt is not accepted by the destination device D (packet rejected PJ). Accordingrv. the timer unit TU of the source device S will expire, i.e, a time-out condition will be detected.
  • the source will retransmit the message TCOpckt (buffered in the buffer BS) to the destination device D.
  • This is preferably performed by extracting the copies of the message stored in the buffer BS of the source device S and transmit (retransmit the message) it.
  • the retransmitted message TCOpckt is received by the destination device (package accepted PA) and space is reserved in the buffer BD in the destination device.
  • the acknowledgement sending unit AS in the destination device will then send an acknowledge message to the source unit.
  • the done message sending unit DS will send a done message to the destination device.
  • the done message receiving unit DR in the destination device D receives the done signal, the reserved state or buffer space in the buffer BD is released,
  • Fig. 7 shows a basic representation of a system according to a third embodiment.
  • the source device S and the destination device D according to the third embodiment correspond to the source device S and the destination device D according to the first or second embodiment.
  • the third embodiment relates to the situation that the message TCOPckt sent by the source device S is received by the destination device but the acknow ledgment Ack of the destination device arrives at the source device after a timeout condition of the timer.
  • the delay of the acknowledgment Ack may be due to delays in the network N. Accordingly, as described in the second embodiment, the source device S will 5 retransmit the TCO message TCOPckt.
  • the acknowledgement Ack will be received by the source device S which will then send a done message DO to the destination device D.
  • the destination device D will identify the retransmission of the message by the source identification unit as this message originates from the same source device as the previous message. Therefore, the packet will rejected PJ as the done signal DOl
  • Fig. 8 A shows a basic representation of the structure of a TCO data message according to a third embodiment.
  • the acknowledged message ACK is encoded as an L4
  • Fig. 8B shows a basic representation of the structure of an acknowledged message according to a third embodiment.
  • the acknowledged message ACK is encoded as an L4 extension.
  • Fig. 9 shows a basic representation of the structure of a done message 0 according to the third embodiment.
  • the done message DO is encoded as a L4 extension.
  • the acknowledgment Ack and the done message DO can be encoded as two UniPro L4 extensions for the Ext Tag, namely RELIABLE JvlSG_ACK for the acknowledgement according to Fig. 8B and RELIABLE_MSG_DOKE according to Fig, 9.
  • the drop bit is set to ! indicating that the (connection-less) messages will 5 not be dropped if the destination D does not recognize these extensions.
  • the Ext Len will be set to 0 due lo the fact that they do not contain extension values.
  • the acknowledgment ACK and done messages DO can be piggybacked to other (connection-less) messages sent between the source device S and the destination device D. For example, this can be performed by piggybacking a done message DO on the L4 extension of a FCO data0 message.
  • an acknowledgement Ack can be piggybacked on a TCO data message sent in the direction opposite to the acknowledged TCO data message as a L4 extension,
  • Fig. 10 shows a basic representation of a flow chart of an operation of a source according to a fourth embodiment.
  • the source according to the fourth embodiment may be I l based on the source according to the first, second or third embodiment, i.e. the fourth embodiment may be based on any one of the first to third embodiments.
  • step SlO the process is initiated and in step Sl 1, the process is in an idle condition.
  • step Si 2 a message including the destination device ID and the destination TCO Port is received by the source device S.
  • step S13 a copy of the message is saved in the buffer BS.
  • step S 14 the message is send based on the UmPro protocol to the destination device D,
  • step S 15 a timer unit TU is started for the particular destination device ID DID and for a particular destination port.
  • step S 16 an acknowledgment Ack is awaited by the acknowledge receiving unit AR. If an acknowledgement Ack is received, the flow will continue to step S20.
  • the acknowledgement Ack may also comprise the destination device ID DDID and the destination port of the destination.
  • step S21 a done message DO including the destination device ID DDlD and the destination device port is transmitted, m step S22, the timer for the destination device ID DDID and the destination port is stopped and a release message is sent.
  • step S 16 if in step S 16 no acknowledgement has been received, the flow will continue to step S17 where the timer TU will detect a time-out for the destination device ID DDID and the destination port.
  • step Sl 8 the original message (buffered in the buffer BS of the source) is retransmitted according to the UniPro protocol.
  • step S 19 a timer is restarted for the destination device ID DDID and for the destination port.
  • a source sends a message and saves a copy thereof. Furthermore, it starts a timer and awaits the acknowledgments. If the acknowledgement is received, the source devices sends a done message and released the message from the retransmission buffer. If, however, the timer expires the message will be retransmitted and the timer is restarted.
  • Fig. 1 1 shows a basic representation of a flow diagram of an operation of a destination device according to a fifth embodiment.
  • the destination device according to the fifth embodiment can be based on the destination device according to the first, second or third embodiment.
  • the fifth embodiment relates to the situation in the destination device when receiving the signals from the source device according to the fourth embodiment.
  • step S30 the process is initiated and it remains idle in step S31.
  • a message is received including a source device ID SDID and a source port in step S32.
  • step S33 it is determined whether the device can accept the message. If the device cannot accept the message (e.g. as it does not have sufficient space in its buffer), the flow will continue to step S3 1.
  • step S34 the message including the source device ID and the source port is supplied to the application.
  • step S35 an acknowledgement is initiated by the acknowledgement sending unit AS to the source device S.
  • step S36 the destination device D will await the done signal. If the destination device receives a done signal In step S38 by the done message receiving unit, the flow will continue to step S3 1 , Otherwise, if a message is received from the source in step S37, the flow will continue to step S36.
  • Fig. 12 shows a basic representation of a system according to a sixth embodiment.
  • the sixth embodiment is related to a pipelined TCO (PTCO) message communication.
  • the source unit S and the destination unit D according to the sixth embodiment can be based on the source unit or the destination unit according to the first, second, third or fifth embodiment.
  • PTCO messages can for example be performed by means of sequence numbers, acknowledgements and done messages.
  • the done messages DO can be used to end a message sequence.
  • Each PTCO message will comprise a sequence number PTCOPckt # O - PTCOPckt M 2.
  • acknowledgements may aho indicate a sequence number to acknowledge that and which message has been accepted at the destination device.
  • the sequence number can be added as> a dedicated field in the L4 header or as an L4 extension,
  • the sequence numbers in the acknowledgement signals can be encoded or provided as a value field in the L4 extension of the acknowledgement.
  • a copy of the message when a PTCO message is sent by a source device S, a copy of the message will be saved in the buffer BS such that this copy may be retransmitted if required. Furthermore, a timer TU is set and started (also as described according to the first to third embodiment). The source S will also guarantee the receipt of acknowledgement messages Ack, e.g., by reserving some buffer space in the buffer BS for the receipt of acknowledgement messages. If an acknowledgment message is received from a destination device D by means of the acknowledge receiving unit, the associated sequence number is checked and the saved copies of the transmitted messages can be discarded from the buffer BS.
  • the destination device D will monitor the incoming messages PTCOckt * O - PTCOPckt # 2 and identify the source of the messages in the source identification unit by means of the device ID and the ports present in the messages. Thereafter, the destination device D could reserve some space in its ⁇ input buffer) until BD it has received a done message DO from a source S with the same ID and port. However, it should be noted that this reservation of resources based on the source device ID is optional. The destination device D should guarantee the receipt of the done message DO, e.g., by allocating buffer space for DO.
  • Fig. 13 shows a basic representation of a system according to a seventh embodiment.
  • the seventh embodiment is based on the sixth embodiment and relates to a situation where at least one of the (connection-less) messages is not accepted at the destination device D.
  • a time-out at the timer TU of the source device S will occur and the source will retransmit those unacknowledged messages, i.e. a copy stored in the (retransmission) buffer BS will be retransmitted.
  • a situation may occur for example due to delays in the network that the respective acknowledgement from the destination device D wil! be recehed at the source device S when a time-out of the timer unit TU has occurred. Therefore, the source S will retransmit those PTCO messages for which no acknowledgement Ack has been received.
  • the destination device D will identify the message based on the information contained therein and will therefore discard the message as it does not comprise a sequence number which is in the required order.
  • Fig. 14 shows a basic representation of a system according to an eighth embodiment.
  • the system according to the eighth embodiment is based on the system according to the seventh embodiment of Fig. 13.
  • the situation is shown that several packets are send from the source device S to the destination device D.
  • the destination device D receives a first package PTCOpckt#0, the packet is accepted and a state is reserved. Thereafter, the second and third packet PTCOpckt# I and PTC0pckt#2 are received by the destination device D and are accepted PA. Thereafter, the destination device D sends an acknowledgement message Ack#2 by the acknowledgement sending unit AS indicating that the first, second and third packet or message have been received.
  • the timer unit TU in the source device S will be started when the first package or message has been sent to the destination unit D.
  • the timer unit TU will be restarted.
  • the second message Pl COpckt#l is retransmitted from the source to the destination device D.
  • the destination device receives the second retransmitted message PTCOpckt#l, the package will be rejected PJ as it comprises a wrong sequence number WSN.
  • the timer is restarted and the fourth and fifth message PTC0 ⁇ ckt#3 and PTC0pckt#4 are sent from the source device S to the destination device D, These two packages are accepted PA and a second acknowledgment message Ack#4 is sent from the acknowledgement sending unit AS in the destination device D to the acknowledgment receiving unit AR in the source device S.
  • the timer TU is stopped and a done message DO is sent from the done message sending unit DS.
  • the destination device D receives the done message DO, the reserved states are released.
  • Fig, 15 shows a flow diagram of an operation of a transmitter in a source device in a system according to the ninth embodiment.
  • the source device according to the ninth embodiment may be based on a source device according to one of the first to eighth embodiment.
  • the transmitter part of a source device will be initiated in step S50.
  • step S51 the sequence numbers of the following frame are set to 0 and the last acknowledged frame sequence number is set to -1 . If the source device will transmit a message, the flow will continue to step S54, which is described in more detail in Fig, 16. Therefore, in step S8 1 , a copy of the message is saved, in step S82, the message is sent via the network N in step $83, the timer is started and the next frame sequence number is incremented.
  • step S55 the source device is in a connected state. In such a state, several events may occur.
  • step S56 a message may be received which is to be forwarded to the destination device by means of the step S59, PMsgJSre.
  • the port of the source may continue to step S62 to apply "back pressure" to the retransmission buffer,
  • the connected back pressure state corresponds to the connected state with the exception that no new user messages are accepted.
  • step S55 the flow can continue to step S57 if a time-out of the timer has occurred. Accordingly, those frames which have not been acknowledged will be retransmitted in step S60.
  • step S60 the procedure according to Fig. 17 is implemented. Therefore, in step S9G. the replay is initiated and in step S92, a message is sent to the destination device, in step S93, the timer is restarted and the sequence number counter RplySeq is incremented. In step S94, it is determined whether this counter corresponds to the next sequence. If this is the case, the replay will be stopped, othenvise the flow will continue to step S92.
  • Fig. 18 shows a basic representation of a flow chart of an operation of a receiver of the source device according to a twelfth embodiment. The receiver part of the source device is used to handle the incoming acknowledgements from the destination devices D.
  • step SlOO the operation is initiated.
  • step S lOl a counter of the next sequence NextSeq is set to zero and the acknowledged sequence counter AckedSeq is set to the maximum sequence number -I,
  • step S 102 the operation is in an idle state.
  • step S 103 an acknowledgement message Ack with a destination device ID, a destination Rport and a sequence is received based on a UniPro protocol. Then the flow continues to step S 104 where it is determined whether the received acknowledgement is an acknowledgement for an outstanding message. If this is not the case, the flow will continue to step S 102, Otherwise in step S 105, ⁇ hose messages which are stored in the retransmission buffer BS and which correspond up to the acknowledgement message can be discarded. In step S 106 it is determined whether the acknowledgement corresponds to a currently replayed message. If this is not the case, the flow will continue to step S 102.
  • step S102 the reply sequence is set to the sequence and the flow will continue to step S 108.
  • step S 108 it is determined whether all messages have been acknowledged, If this is not the case, the flow will continue to step S1Q9 where the timer is reset and started again for the destination device D ID and destination Rport of the outstanding acknowledgement. Otherwise, if all messages have been acknowledged, the flow will continue to step SI lO where the timer is stopped for the particular destination device ID and the destination Rport.
  • Fig. 19 shows a basic representation of a flow chart of an operation of a destination device according to a thirteenth embodiment.
  • step S 120 the flow chart is started.
  • step Sl 21 the expected and sent sequence numbers are set to 0.
  • step S 122 the flow is in an idle condition. If the destination device D receives a message a process described in Fig. 20 in more detail is activated. Here, in step S 130 this process is initiated.
  • step S131 it is determined whether the application can accept a message. If no, the flow ⁇ $ stopped. Otherwise the received message is supplied to the user.
  • step S 134 the sequence number is checked. If the sequence number is not correct the message will be discarded. If the sequence number is correct, the flow will continue to step S 135. Here, an acknowledge is forwarded to the source.
  • step S 124 If in step S 124 a message is accepted, the destination device D is connected in step S 125. Then the flow continues to step S 127 if no further messages are present and thereafter the flow continues to step S 121. Otherwise the flow will continue to step S 126 where a message is received based on the UniPro protocol.
  • the message can comprise a source device ID, a source Rport and a sequence number. Thereafter, the flow will continue to step S 128.
  • the operation according to step S128 is depicted in Fig. 20. The above described principles of the invention can be applied for example in

Landscapes

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

Abstract

Cette invention se rapporte à un procédé de communication entre au moins une unité source (S) et au moins une unité destination (D) sur un réseau fiable (N) qui présente des frontières où des données peuvent être déposées. Au moins un message (TCOPckt) est transmis à partir de la ou des unités sources (S) vers une unité destination (D). Le ou les messages contiennent des informations qui concernent l'unité source expéditrice (S) et une charge utile. Au moins un accusé de réception (ACK) est transmis à partir de l'unité destination réceptrice (D) vers l'unité source expéditrice (S) après avoir reçu le ou les messages (TCOPckt). Un message (DO) est transmis à partir de l'unité source expéditrice (S) vers l'unité destinataire (D) qui indique la fin de la transmission du ou des messages (TCOPckt) après avoir reçu le ou les accusés de réception (ACK) en provenance de l'unité destination (D).
PCT/EP2009/055603 2008-05-13 2009-05-08 Procédé de communication entre une unité source et une unité destination et nœud de communication WO2009138365A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP08290449 2008-05-13
EP08290449.1 2008-05-13

Publications (1)

Publication Number Publication Date
WO2009138365A1 true WO2009138365A1 (fr) 2009-11-19

Family

ID=40935568

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/055603 WO2009138365A1 (fr) 2008-05-13 2009-05-08 Procédé de communication entre une unité source et une unité destination et nœud de communication

Country Status (1)

Country Link
WO (1) WO2009138365A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014166525A1 (fr) 2013-04-09 2014-10-16 Phonak Ag Procédé et système pour fournir une aide auditive à un utilisateur

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070237076A1 (en) * 2006-03-30 2007-10-11 Nokia Corporation Node
EP1950932A1 (fr) * 2007-01-29 2008-07-30 Stmicroelectronics Sa Système de transmission de données au sein d'un réseau entre les noeuds du réseau et le processus de contrôle de flux pour transmettre les données citées

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070237076A1 (en) * 2006-03-30 2007-10-11 Nokia Corporation Node
EP1950932A1 (fr) * 2007-01-29 2008-07-30 Stmicroelectronics Sa Système de transmission de données au sein d'un réseau entre les noeuds du réseau et le processus de contrôle de flux pour transmettre les données citées

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DEFENSE ADVANCED RESEARCH PROJECTS AGENCY INFORMATION SCIENCES INSTITUTE UNIVERSITY OF SOUTHERN CALIFORNIA 4676 ADMIRALTY WAY MARI: "TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION prepared for Information Processing Techniques Office 1400 Wilson Boulevard 22209 by ; rfc793.txt", IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1 September 1981 (1981-09-01), XP015006775, ISSN: 0000-0003 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014166525A1 (fr) 2013-04-09 2014-10-16 Phonak Ag Procédé et système pour fournir une aide auditive à un utilisateur

Similar Documents

Publication Publication Date Title
US9674832B2 (en) Method and apparatus for layer 2 ARQ for packets
US6519223B1 (en) System and method for implementing a semi reliable retransmission protocol
JP5523350B2 (ja) Tcpフロー制御のための方法及び装置
JP5544430B2 (ja) 通信装置および通信システム
US6335933B1 (en) Limited automatic repeat request protocol for frame-based communication channels
US6694471B1 (en) System and method for periodic retransmission of messages
US6987981B2 (en) Robust RLC reset procedure in a wireless communication system
US6590905B1 (en) Changing XID/PDCP parameters during connection
JP5081900B2 (ja) 再送要求送信方法及び受信側装置
JP4929349B2 (ja) 再送要求送信方法及び受信側装置
JP2011135601A (ja) パケット通信方法及び受信側装置
US20170006496A1 (en) Method and apparatus for packet communication using header compression
CN116074401B (zh) 一种在可编程交换机上的传输层协议实现方法
WO2009138365A1 (fr) Procédé de communication entre une unité source et une unité destination et nœud de communication
US20120072520A1 (en) System and Method for Establishing Reliable Communication in a Connection-Less Environment
JP4759218B2 (ja) データ伝送方法
KR102184144B1 (ko) Mptcp를 이용한 통신에서의 응답 메시지 처리 방법 및 시스템
KR100812822B1 (ko) 무선 네트워크 시스템에서 목적지 상태에 기초한 무선데이터 통신 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09745697

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09745697

Country of ref document: EP

Kind code of ref document: A1