WO2025171833A1 - Method and system for bidirectional communication in a network - Google Patents

Abstract

The present disclosure relates to a method (200) for bidirectional communication in a network, comprising: transmitting (210), by means of a transmission module (HO), data to a receiver module (120) according to the Transmission Control Protocol, TCP; determining (220), by means of the transmission module (110), whether the receiver module (120) is configured for out-of-order queuing, OoO queuing; and selecting (230) a first operating mode (BM1) of the transmission module (110) if the receiver module (120) is configured for OoO queuing, or a second operating mode (BM2) if the receiver module (120) is not configured for OoO queuing, the first operating mode (BM1) and the second operating mode (BM2) having different retransmission characteristics for unconfirmed TCP segments (SEG-C).

Description

Method and system for bidirectional communication in a

Network

The present disclosure relates to a method for bidirectional communication in a network, a storage medium for implementing the method, and a system for bidirectional communication in a network. In particular, the present disclosure relates to improved TCP congestion control in resource-constrained systems.

State of the art

In resource-constrained systems, conventional Transmission Control Protocol (TCP) congestion control approaches such as Tahoe, (New) Reno, etc., reach their limits. The associated low transmission rates and flash aborts due to inappropriate timeouts from higher protocol layers currently require complex traffic shaping measures. While these attempt to reduce the load on the TCP stacks and prevent packet loss, they do not optimize the fundamental weaknesses of TCP implementations. Therefore, despite traffic shaping, undesirable problems can still occur.

Previous TCP congestion control algorithms are primarily designed for consumer/enterprise systems and only superficially consider the different traffic patterns in the network. However, standards-based approaches neglect implementation weaknesses of embedded systems, which can lead to undesirable interactions. In particular, under certain conditions, which may be present in vehicle networks, so-called "retransmission chains" can occur in which two participating TCPs remain in an inefficient "ping-pong" pattern, which can lead to significant

can lead to data rate reductions. Disclosure of the invention

It is an object of the present disclosure to provide a method for bidirectional communication in a network, a storage medium for implementing the method, and a system for bidirectional communication in a network that enable improved data transmission between communication partners. In particular, it is an object of the present disclosure to enable improved TCP congestion control in resource-limited systems and to compensate for any deficiencies of a resource-limited remote TCP (receiver module).

This object is achieved by the subject matter of the independent claims. Advantageous embodiments are specified in the subclaims.

According to an independent aspect of the present disclosure, a method for bidirectional communication in a network is provided. The method comprises sending, by a transmitting module, data to a receiving module according to the Transmission Control Protocol (TCP); determining, by the transmitting module, whether the receiving module is configured for out-of-order queuing (OoO queuing); and selecting a first operating mode of the transmitting module if the receiving module is configured for OoO queuing, or a second operating mode if the receiving module is not configured for OoO queuing, wherein the first operating mode and the second operating mode have different retransmission characteristics for unacknowledged TCP segments.

According to the invention, the transmitting module detects certain capabilities of the receiving module and automatically switches to an appropriate mode. In particular, different retransmission characteristics are used depending on whether the receiving module is configured for OoO queuing or not. For example, only the last unconfirmed data segment can be transmitted if the receiving module supports OoO queuing. If the receiving module supports OoO queuing, If, however, there is no OoO queuing, the portion of the send window for which the receive acknowledgments are still pending can be transmitted in its entirety. This allows the sending module to react independently and flexibly to the capabilities of the receiving module and select a suitable operating mode, enabling improved data transmission between communication partners. In particular, improved TCP congestion control can be enabled in resource-limited systems.

The communication according to the invention is based on the Transmission Control Protocol (TCP). The Transmission Control Protocol is a central protocol in the Internet protocol stack (TCP/IP) and is responsible for the reliable transmission of data over networks. TCP provides a number of mechanisms to ensure that data is transmitted correctly and in the correct order between a transmitting module and a receiving module.

TCP is a connection-oriented protocol, meaning it establishes a connection between the sending and receiving modules before data transmission. This connection remains active throughout the entire communication and is closed after the data transfer is complete. Each connection has interdependent states that are continuously synchronized and managed by state machines. One of the most important properties of TCP, realized with state machines, is the reliable transmission of data. It uses mechanisms such as acknowledgments (ACKs), sequence numbers, and retry requests to ensure that data arrives correctly, in the correct order, and without duplication or loss.

In TCP, the transmission of data is organized into segments. A TCP segment is a data structure that contains information about the data to be sent and is sent over the network. Each TCP segment contains data and is identified by a sequence number. For example, each TCP segment can a header containing the data (payload), and a checksum for verifying the integrity of the transmitted data. The header can include, for example, the sequence number, an acknowledgment number, a sliding window size, flags, etc.

The ACK (acknowledgment) is a mechanism by which the receiver of a TCP segment notifies the sender that the received data has arrived successfully. If the sent data has not reached the receiver module, has not arrived correctly, and/or is not acknowledged or acknowledged in a specific way, the transmitting module can resend the data. This is referred to as "retransmission" in the context of this disclosure. Retransmission is adapted depending on whether the receiver module is configured for out-of-order queuing or not.

The term "out-of-order queuing" refers to a situation in network communications where received data packets or segments arrive out of order. This can occur in TCP/IP networks, particularly when data packets or segments experience different delays due to different paths through the network, when they arrive at different speeds due to network congestion, or when individual packets are lost, resulting in a gap in the data stream (or sequence numbers), the compensation for which requires an out-of-order segment (retransmission).

If the receiver module can handle such a situation and put the data packets in the correct order, even if the reception order is different, the receiver module is “configured for out-of-order queuing” within the meaning of the present disclosure. If the receiver module cannot handle such a situation and put the data packets in the correct order or does not correct the incorrect order, recognize, the receiver module is “not configured for out-of-order queuing” within the meaning of the present disclosure.

Preferably, the method further comprises receiving, by the transmitting module, a duplicate acknowledgment (DUP-ACK) from the receiving module; and determining, upon receipt of the DUP-ACK, that the receiving module is not configured for out-of-order queuing. Thus, for example, if a DUP-ACK or a certain number of DUP-ACKs is received in the first operating mode, a switch can be made from the first operating mode to the second operating mode, in which it is assumed that the receiving module is not configured for out-of-order queuing.

Duplicate Acknowledgment (DUP-ACK) is a form of acknowledgment in TCP. A DUP-ACK occurs when the receiving module retransmits or needs to retransmit an acknowledgment for a segment it has already received. Typically, a DUP-ACK occurs in situations where the receiving module detects that a particular TCP segment is missing or lost. If the receiving module determines that a particular segment did not arrive in time, it sends a DUP-ACK to (implicitly) alert the sending module that the missing segment should be retransmitted. DUP-ACKs can also occur in other situations, such as when processing TCP segments that arrive out of order. In such cases, the receiving module sends a DUP-ACK to inform the sending module that segments were received out of order (and therefore cannot be accepted). If DUP-ACKs are received for a complete transmission window, the transmitting module can safely say that the receiving module does not support out-of-order queuing, especially since at least one segment that fills a gap, which must exist if out-of-order queuing is supported, should have triggered a regular ACK. Thus, the receipt of a DUP-ACK, for example, under the previously described circumstances is a sure indication that the receiver module is not configured for out-of-order queuing.

Preferably, the method further comprises receiving, by the transmitting module and in the second operating mode, a cumulative acknowledgment (CUM-ACK) from the receiving module; and switching from the second operating mode to the first operating mode upon receipt of the CUM-ACK. Thus, if a CUM-ACK is received in the second operating mode, in which it is assumed that the receiving module is not configured for out-of-order queuing, this assumption is revised, and the first operating mode is selected, in which it is assumed that the receiving module is configured for out-of-order queuing.

Whether this mode change should be performed or not can be activated or deactivated according to an independent aspect. Which mode changes are advantageous depends, for example, on the initial operating mode. For example, it could be assumed that out-of-order queuing is not supported until the opposite is proven by the receipt of a CUM-ACK following a preceding DUP-ACK, and the operating mode could only be changed afterward. Conversely, one could also start from the other operating mode and assume that out-of-order queuing is supported, only changing the operating mode when this assumption can no longer be maintained. In one design, only a single mode change may be necessary, so that any transitional conditions would not further disrupt operation.

Cumulative Acknowledgment (CUM-ACK) is a form of acknowledgement in TCP. When the receiving module successfully receives data, it sends an ACK back to the sending module to confirm this. With a CUM-ACK, the receiving module acknowledges not only the last seamless segment received, but also all previously seamless segments up to a specific sequence number. The CUM-ACK thus indicates that all data up to a specific sequence number has been successfully received. This simplifies the implementation and operation of TCP because the sending module does not need to receive a separate acknowledgment for each received segment and relieves the interrupt load from the sending module. Thus, under certain circumstances, the receipt of a CUM-ACK provides a reliable indication that the receiving module is configured for out-of-order queuing. In particular, a CUM-ACK in the same send window in which a DUP-ACK previously occurred provides this indication.

Preferably, the TCP includes a sliding window. The sliding window is generally used to control the transmission of data between the sending module and the receiving module and allows multiple data packets to be transmitted simultaneously without having to wait for acknowledgment of each individual packet. The sliding window represents the range of unacknowledged data packets or TCP segments that the sending module can send simultaneously before waiting for acknowledgments from the receiving module. In simple terms, the sliding window can also be viewed as the memory situation at the receiving module, or the sending module's view of the memory situation at the receiving module. When acknowledgments for sent data packets are received, the sliding window is moved. The size of the sliding window is referred to as the "window size."

Preferably, according to some embodiments of the present disclosure, a repeat window is defined within the sliding window. In the first operating mode and the second operating mode of the transmit module, TCP segments are retransmitted from the repeat window, in particular exclusively from the repeat window.

Preferably, the sliding window and the retry window have the same starting point, such as a base TCP segment of the sliding window. Preferably, the retry window is defined from the base TCP segment (including the base TCP segment) to a next unsent TCP segment of the sliding window (excluding the unsent TCP segment).

Preferably, the sliding window and the repeat window have different endpoints.

Preferably, the sliding window and the repeat window have different window sizes.

Preferably, the retry window includes only sent TCP segments.

Preferably, the retransmission characteristic in the first operating mode is such that only the oldest unacknowledged TCP segment is transmitted, such as the oldest unacknowledged TCP segment of the retransmission window. The oldest unacknowledged TCP segment is the TCP segment with the lowest sequence number that has not yet been acknowledged by the receiver module. This allows for the most efficient retransmission of unacknowledged data, assuming the receiver module has OoO queuing capability.

Preferably, the retransmission characteristic in the second operating mode is such that multiple unacknowledged TCP segments are transmitted. For example, all TCP segments of the retransmission window, or at least all (still) unacknowledged TCP segments of the retransmission window, can be transmitted. This allows for maximum efficiency in the retransmission of unacknowledged data, assuming the receiver module lacks OoO queuing capability.

Preferably, the method is intended for vehicle programming and/or is used in vehicle programming. Vehicle programming can, for example, include the programming of control units (e.g., ECUs) for various functions such as engine control, transmission control, braking, chassis control, infotainment, etc. In another example, vehicle programming can relate to driver assistance systems for automated driving. This includes, for example, the programming of algorithms for sensor data processing, decision-making, and real-time vehicle control.

The term "vehicle" includes cars, trucks, vans, buses, mobile homes, motorcycles, etc., used to transport people, goods, etc. In particular, the term includes motor vehicles used for passenger transport.

The method is preferably used in or with embedded systems. Embedded systems are specialized computer systems that are embedded in other devices or systems to perform specific functions or control tasks. Unlike conventional computers, which are used for general purposes, embedded systems are designed to perform specific functions in a dedicated environment.

According to a further independent aspect of the present disclosure, a software (SW) program is provided. The SW program can be configured to run on one or more processors and thereby implement the method described in this document for bidirectional communication in a network.

According to a further independent aspect of the present disclosure, a storage medium is provided. The storage medium can comprise a software program configured to be executed on one or more processors and thereby to carry out the method described in this document for bidirectional communication in a network. According to a further independent aspect of the present disclosure, software with program code is provided. The software is configured to implement the method for bidirectional communication in a network when the software runs on one or more software-controlled devices.

According to a further independent aspect of the present disclosure, a system for bidirectional communication in a network is provided. The system comprises one or more processors; and at least one memory connected to the one or more processors and containing instructions executable by the one or more processors to perform the method for bidirectional communication in a network described in this document.

Preferably, the system comprises, or is, the transmitter module.

Preferably, the system comprises the transmitter module and the receiver module, or consists of the transmitter module and the receiver module.

A processor or processor module is a programmable computing unit, i.e. a machine or an electronic circuit that controls other elements according to given instructions and thereby drives an algorithm (process).

Short description of the drawings

Embodiments of the disclosure are illustrated in the figures and are described in more detail below. They show:

Figure 1 schematically shows a system for bidirectional communication in a network according to embodiments of the present disclosure, Figure 2 is a flowchart of a method for bidirectional communication in a network according to embodiments of the present disclosure,

Figure 3 shows a plurality of TCP segments of the TCP according to embodiments of the present disclosure, and

Figure 4 shows a state machine for adaptive flow control according to embodiments of the present disclosure.

Embodiments of the disclosure

In the following, unless otherwise stated, the same reference symbols are used for identical and equivalent elements.

Figure 1 schematically shows a system for bidirectional communication in a network according to embodiments of the present disclosure.

The system comprises a transmitter module 110 (Tx) and a receiver module 120 (Rx), which communicate with each other via a network. The term "network" refers to a communications infrastructure over which data is exchanged between the transmitter module 110 and the receiver module 120. This network can include the Internet, a local area network (LAN), a wide area network (WAN), or other types of networks. Generally, data exchange is bidirectional, meaning that a transmitter module is always also a receiver module. The choice of representation serves to understand the essential aspects and is not intended to limit this.

The communication between the transmitting module 110 and the receiving module 120 is based on the Transmission Control Protocol (TCP). In TCP, the transmission of data is organized into segments. A TCP segment (SEG) is a data structure that contains information about the data to be sent and about the network. Each TCP segment (SEG) contains data and is identified by a sequence number. For example, each TCP segment (SEG) can include a header, the data (payload), and a checksum for verifying the integrity of the transmitted data. The header can include, for example, the sequence number, an acknowledgment number, a sliding window size, flags, etc.

The acknowledgment ACK is a message with which the receiver module 120 notifies the transmitter module 110 that the TCP segments SEG have arrived successfully. If the transmitted TCP segments SEG have not arrived at the receiver module 120, the transmitter module 110 can resend the data. This is referred to as "retransmission" in the context of the present disclosure.

Generally, TCP congestion control is used to manage network traffic and prevent network congestion. However, in resource-constrained systems, conventional TCP congestion control approaches such as Tahoe, (New) Reno, etc., reach their limits. In particular, conventional TCP congestion control algorithms are primarily designed for consumer/enterprise systems and neglect implementation weaknesses of embedded systems, which can lead to undesirable interactions. For example, so-called "retransmission chains" can occur in which two participating TCPs remain in an inefficient "ping-pong" state, which can lead to significant data rate reductions.

The embodiments of the present disclosure solve such problems of conventional TCP congestion control algorithms by providing different transmit module operating modes depending on the receiver's ability to perform out-of-order queuing, as described below. The term "out-of-order queuing" refers to a situation in network communication in which the received data packets or segments arrive out of order. Figure 2 shows a flowchart of a method 200 for bidirectional communication in a network according to embodiments of the present disclosure. The method 200 can be implemented by appropriate software executable by one or more processors (e.g., a CPU).

The method 200 comprises, in block 210, sending, by a transmitting module, data to a receiving module according to the Transmission Control Protocol (TCP); in block 220, determining, by the transmitting module, whether the receiving module is configured for out-of-order queuing (OoO queuing); and, in block 230, selecting a first operating mode of the transmitting module if the receiving module is configured for OoO queuing, or a second operating mode if the receiving module is not configured for OoO queuing, wherein the first operating mode and the second operating mode have different retransmission characteristics for unacknowledged TCP segments.

This allows the transmitting module to recognize certain capabilities of the receiving module and independently switch to an appropriate mode. In particular, different retransmission characteristics are used depending on whether the receiving module is configured for OoO queuing or not. For example, only the last unacknowledged data segment can be transmitted if the receiving module supports OoO queuing. However, if the receiving module does not support OoO queuing, the entire retransmission window can be transmitted. This allows the transmitting module to respond independently and flexibly to the capabilities of the receiving module and select a suitable operating mode, enabling improved data transmission between communication partners. In particular, improved TCP congestion control can be enabled in resource-limited systems. In some embodiments, method 200 is provided for vehicle programming and/or is used in vehicle programming. Vehicle programming may include, for example, the programming of control units (e.g., ECUs) for various functions such as engine control, transmission control, braking, chassis control, infotainment, etc. In another example, vehicle programming may relate to driver assistance systems for automated driving. This includes, for example, the programming of algorithms for sensor data processing, decision-making, and real-time vehicle control. Additionally or alternatively, method 200 is used in or with embedded systems.

Figure 3 shows a plurality of TCP segments of the TCP according to embodiments of the present disclosure.

In the example shown, the TCP segments include confirmed TCP segments SEG-A, TCP segments usable for transmission but not yet sent SEG-B, TCP segments sent but not yet confirmed SEG-C, and unusable TCP segments SEG-D.

TCP may include a sliding window (SLW). The sliding window (SLW) is generally used to control the transmission of data between the transmitting module and the receiving module and allows multiple data packets to be transmitted simultaneously without having to wait for each individual packet to be acknowledged (pipelining). When acknowledgements for sent data packets are received, the sliding window (SLW) is shifted. The size of the sliding window (SLW) is called the "window size" and is specified, for example, by the receiving module as part of flow control.

Within the Sliding Window SLW, a Repeat Window REW can be defined, which only contains sent TCP segments SEG-A and SEG-C. In the first operating mode and the second operating mode of the transmit module, TCP segments are retransmitted from the retransmission window REW, in particular exclusively from the retransmission window REW.

The sliding window SLW and the retry window REW may have the same starting point, such as a base TCP segment (base) of the sliding window SLW, and may have different endpoints. Thus, the sliding window SLW and the retry window REW may have different window sizes. In some embodiments, the retry window REW extends from the base TCP segment (base) to a next unsent TCP segment of the sliding window SLW (nextseq).

In some embodiments, the retransmission characteristic in the first operating mode is such that only the oldest unacknowledged TCP segment of the retransmission window REW is transmitted. The oldest unacknowledged TCP segment is the TCP segment with the lowest sequence number that has not yet been acknowledged by the receiver module. This allows for the most efficient retransmission of unacknowledged data, assuming the receiver module has OoO queuing capability.

In addition, the retransmission characteristics in the second operating mode can be such that multiple unacknowledged TCP segments are transmitted. For example, all TCP segments of the retransmission window REW, or at least all unacknowledged TCP segments of the retransmission window REW, can be transmitted. This allows for the most efficient retransmission of unacknowledged data, assuming the receiver module lacks OoO queuing capability, by breaking all retransmission chains. Figure 4 shows a state machine for adaptive flow control according to embodiments of the present disclosure.

In some embodiments, the transmitting module can determine that the receiving module is not configured for out-of-order queuing when a duplicate acknowledgment (DUP-ACK) is received from the receiving module. For example, if a DUP-ACK or a certain number of DUP-ACKs dependent on the transmit window is received in the first operating mode (BMI), the first operating mode (BMI) can be switched to the second operating mode (BM2), in which it is assumed that the receiving module is not configured for out-of-order queuing.

Duplicate Acknowledgment (DUP-ACK) is a form of acknowledgment in the TCP protocol. Typically, a DUP-ACK occurs in situations where the receiving module detects that a particular TCP segment is missing or lost. If the receiving module determines that a particular segment did not arrive in time, it sends a DUP-ACK to inform the sending module (e.g., implicitly) that the missing segment should be retransmitted. DUP-ACKs can also occur in other situations, such as when processing TCP segments that arrive out of the expected order. In such cases, the receiving module sends a DUP-ACK to inform the sending module that segments have been received out of order. Thus, the receipt of a DUP-ACK provides, for example, under the conditions described in more detail in this document, a reliable indication that the receiving module is not configured for out-of-order queuing.

In some embodiments, the transmitting module can switch from the second operating mode BM2 (back) to the first operating mode BMI when a cumulative acknowledgment, CUM-ACK, is received from the receiving module. Thus, in the second operating mode BM2, in which it is assumed that the If a CUM-ACK is received when the receiver module is not configured for out-of-order queuing, this assumption is revised and the first operating mode BMI is selected, in which it is assumed that the receiver module is configured for out-of-order queuing.

Cumulative Acknowledgment (CUM-ACK) is a form of acknowledgment in TCP. When the receiving module successfully receives data, it sends an ACK back to the sending module to confirm this. With a CUM-ACK, the receiving module acknowledges not only the most recently received segment, but also all previously received segments up to a certain sequence number. The CUM-ACK thus indicates that all data up to a certain sequence number has been successfully received. This simplifies the implementation and operation of TCP, as the sending module does not need to receive a separate acknowledgment for each individual received segment. Receiving a CUM-ACK in the same send window in which a DUP-ACK previously occurred thus provides a reliable indication that the receiving module is configured for out-of-order queuing.

The embodiments of the present disclosure enable sustainable improvements in TCP implementations without circumventing existing features. One focus is on the targeted optimization of TCP stacks for resource-constrained systems, particularly those implemented in embedded systems that deliberately do not implement all aspects of the relevant standards. This creates an efficient and optimized TCP congestion control algorithm that specifically addresses the implementation weaknesses of embedded systems.

Although the invention has been illustrated and explained in detail by means of preferred embodiments, the invention is not limited by the disclosed examples and other variations can be derived therefrom by a person skilled in the art without departing from the scope of the invention. It is therefore clear that a multitude of possible variations exist. It is also clear that embodiments mentioned by way of example really only represent examples that are not to be understood in any way as limiting the scope of protection, the possible applications or the configuration of the invention. Rather, the foregoing description and the description of the figures enable the person skilled in the art to specifically implement the exemplary embodiments. The person skilled in the art, with knowledge of the disclosed inventive concept, can make various changes, for example with regard to the function or the arrangement of individual elements mentioned in an exemplary embodiment, without departing from the scope of protection defined by the claims and their legal equivalents, such as further explanations in the description.

Claims

Patent claims 1. A method (200) for bidirectional communication in a network, comprising: Sending (210), by a transmitting module (HO), data to a receiving module (120) according to the Transmission Control Protocol, TCP; Determining (220), by the transmitting module (110), whether the receiving module (120) is configured for out-of-order queuing, OoO queuing; and Selecting (230) a first operating mode (BMI) of the transmitting module (110) if the receiving module (120) is configured for OoO queuing, or a second operating mode (BM2) if the receiving module (120) is not configured for OoO queuing, wherein the first operating mode (BMI) and the second operating mode (BM2) have different retransmission characteristics for unacknowledged TCP segments (SEG-C). 2. The method (200) of claim 1, further comprising: Receiving, by the transmitting module (110), a duplicate acknowledgment, DUP-ACK, from the receiving module (120); and Determining, upon receipt of the DUP-ACK, that the receiver module (120) is not configured for OoO queuing. 3. The method (200) according to claim 1 or 2, further comprising: Receiving, by the transmitting module (110) and in the second operating mode (BM2), a Cumulative Acknowledgment, CUM-ACK, from the receiving module (120); and Switching from the second operating mode (BM2) to the first operating mode (BMI) upon receipt of the CUM-ACK. 4. Method (200) according to one of claims 1 to 3, wherein within a sliding window (SLW) of the TCP a repetition window (REW) is defined, which comprises exclusively sent TCP segments (SEG-A, SEG-C), wherein a base TCP segment represents the beginning of the sliding window (SLW) and the retry window (REW), and in the first operating mode (BMI) and in the second operating mode (BM2) a retransmission of TCP segments from the retry window (REW) takes place. 5. The method (200) of claim 4, wherein: the sliding window (SLW) and the retry window (REW) have different endpoints; and/or the sliding window (SLW) and the retry window (REW) have different window sizes; and/or the retry window (REW) is defined from the base TCP segment to a next unsent TCP segment of the sliding window (SLW). 6. The method (200) according to any one of claims 1 to 5, wherein the re-transmission characteristic in the first operating mode (BMI) is such that only an oldest unconfirmed TCP segment is transmitted, in particular an oldest unconfirmed TCP segment of the retransmission window (REW). 7. The method (200) according to any one of claims 1 to 6, wherein the re-transmission characteristic in the second operating mode (BM2) is such that a plurality of unconfirmed TCP segments are transmitted, in particular all unconfirmed TCP segments of the repetition window (REW). 8. A storage medium comprising a software program configured to be executed on one or more processors and thereby to carry out the method (200) according to any one of claims 1 to 7. 9. A system for bidirectional communication in a network, comprising: one or more processors; and at least one memory connected to the one or more processors and containing instructions executed by the one or more Processors can be executed to carry out the method for bidirectional communication in a network according to one of claims 1 to 7. 10. The system according to claim 9, wherein the system comprises the transmitter module (110), in particular the transmitter module (110) and the receiver module (120).