WO2001010075A1

WO2001010075A1 - Method for retransmitting data packets

Info

Publication number: WO2001010075A1
Application number: PCT/DE2000/002358
Authority: WO
Inventors: Klaus David Gradischnig
Original assignee: Siemens Aktiengesellschaft
Priority date: 1999-07-30
Filing date: 2000-07-19
Publication date: 2001-02-08
Also published as: DE19935911A1

Abstract

The invention relates to an alternative retransmission method (RV (2)) that can be used selectively or in replacement of a retransmission method (RV (1)) according to a protocol (P), for instance international ITU standard Q.2110, if data packets have been unsuccessful transmitted. According to said method, only the data packets that were unsuccessfully transmitted are retransmitted. Disclosed is an alternative retransmission method (RV (2)) according to which all data packets from an unsuccessfully transmitted data packet onward are retransmitted. Economic advantages are obtained due to the little complexity of the alternative retransmission method (RV (2)).

Description

description

RETRYING PROCESSES OF DATA PACKAGES

Proven protocols for the transmission of data packets, e.g. those recommended in the international ITU standards X.25, Q.921 or Q.703 seem to be only conditional for the transmission of large amounts of data on connections that have a large product of capacity times transmission time and a not negligible probability of transmission errors suitable. First, a significantly larger sequence number space is required. On the other hand, a retransmission method is used in the signaling methods mentioned, in which, in the event of unsuccessful information transmissions, for example using sequence-numbered data packets, all data packets sent from an unsuccessfully transmitted data packet are retransmitted, even those that are already transmitted correctly - this process is also known as the 'go-back-N process'. This means that even with a single unsuccessful transmission, a period of about twice the simple transmission time remains unused, which is the case with large capacities and long transmission distances, e.g. in broadband satellite connections, can lead to a considerable reduction in the capacity available for successful transmission of data packets.

In the international ITU standard Q.2110 - also called SSCOP or 'Service Specific Connection Oriented Protocol' - 24 bits are therefore used to represent the sequence numbers. In addition, a new type of retransmission procedure is proposed, according to which only data packets transmitted unsuccessfully are retransmitted. However, implementation of the Q.2110 standard requires additional effort in terms of implementation and application due to the higher complexity of the protocol, e.g. due to the recommended retransmission Method in the receiver of the data packets requires considerable additional memory.

The invention has for its object to improve the secure transmission of data packets. The object is achieved by the features of patent claim 1.

The essential aspect of the invention is that when data packets are transmitted, in which at least one version of a protocol, e.g. the international ITU standard Q.2110 in its version from July 1994, alternatively to or instead of the retransmission procedure at least recommended in the version of the protocol in the event of unsuccessful transmission, according to which only unsuccessfully transmitted data packets are retransmitted, at least one alternative than Retransmission method designed as a go-back-N method is provided, according to which all data packets are retransmitted from the first unsuccessfully transmitted data packet. Some essential advantages of the invention are mentioned below. These may be on

An example of a protocol designed according to the international ITU standard Q.2110 is explained, but is not restricted to this standard:

Protocol instances that already support both retransmission procedures are fully compatible with protocol instances, of which only one of the two procedures is supported

This compatibility is achieved with little effort, provided the retransmission procedure provided in the protocol has already been implemented, since the go-back-N procedure is very similar to the retransmission procedure provided in the protocol, but is less complex. If the advantages of the retransmission procedure recommended in the protocol are not sufficient to compensate for the additional effort for implementation and execution, the protocol will be considerably simplified Protocol instances that only support the go-back-N process can therefore be produced more economically without at the same time significantly increasing the costs for protocol instances, which both retransmission processes must support

This enables an economically optimal gradual introduction of the retransmission procedure provided in the standard Q.2110 by initially introducing inexpensive protocol instances that only support the go-back-N procedure, which are later used when converting central protocol instances to that in the standard The retransmission procedures envisaged in Q.2110 will remain fully compatible, provided the converted protocol instances support both retransmission procedures, which - as already explained - can be largely cost-neutral

The go-back-N method is particularly suitable for the connection of simple B-ISDN end devices, since there are no such high demands on the retransmission method used in the signaling as for the connection of a signaling speed and data volume B-ISDN ("Broadband Integrated Services Digital Network") private branch exchange or a LAN ("Local Area Network"), ie End devices can thus be manufactured particularly economically

Even with short transmission paths with mostly low error rates, the go-back-N method is often sufficient and usually economically optimal. The reduced costs are of particular economic interest, especially for smaller network nodes and pilot projects

In addition, interconnection with communication networks in which the go-back-N method or a method related to this is preferably used is simplified. This is, for example, when interconnecting with modern HDLC ("High level Data Link Communication") communication networks, e.g. networks with frame relay according to ITU standard Q.922

According to a further development of the method according to the invention, when a communication relationship is established between two adjacent, protocol-compliant protocol levels of a communication network, the retransmission method is used to retransmit unsuccessfully transmitted data packets at least for the duration of the existence of the communication relationship - claim 2 According to one embodiment of the method according to the invention, the retransmission method is set before the communication relationship is established by administrative configuration in the neighboring protocol instances, according to which the re-transmission of unsuccessfully transmitted data packets will take place at least for the duration of the existence of the communication relationship after the communication relationship has been established - 3. The communication relationship is thus set without changing the PDUs provided in the standard Q.2110 (“Protocol Data -Unit "), i.e. Existing protocols that only implement the retransmission procedure recommended by the standard Q.2110 may be automatic, i.e. without change, compatible with a protocol instance according to the invention.

According to a variant of the method according to the invention, it is provided that when the communication relationship is established, each of the two protocol entities communicates to the other protocol entity which retransmission procedures are supported and as the retransmission procedure, according to which, after the communication relationship has been established, the retransmission of unsuccessfully transmitted data packets will take place at least for the duration of the existence of the communication relationship, a retransmission method is selected that is supported by both protocol authorities - claim 4. This will gradually change the protocol authorities from the go-back. N method enables the retransmission procedure according to the standard Q.2110 without administrative configuration of the protocol instances.

Further advantageous refinements of the method according to the invention result from the subclaims.

The method according to the invention is explained in more detail below with reference to several figures. It shows

1 shows in a flow chart the establishment of a communication relationship between two protocol instances according to the invention, and

FIG. 2 shows in a flow chart the establishment of a communication relationship between a protocol-compliant and a protocol instance according to the invention.

In both figures, communication sequences relevant to the invention are shown in extracts between two - in the sense of a protocol P - neighboring protocol instances PIi and PI ₂ . A communication relationship KB is provided at least temporarily between these two protocol instances PI, for this purpose at least the retransmission methods RV - for example designed as protocol-compliant

Retransmission procedure RV (1) and as alternative retransmission procedure RV (2) - relevant regulations and / or recommendations of Protocol P are used. The temporary nature of the communication relationship KB is indicated by a broken line. Protocol P could essentially correspond to the international ITU standard Q.2110, for example its version from July 1994. According to this standard, signaling information is essentially transported by the data packets.

Status variables RVM and KBZ are optionally provided in the protocol instances PI, the status variables RVM the retransmission method RV used and the status variables KBZ indicate the state of the communication relationship KB. At least the retransmission methods RV (1) and RV (2) are provided for the status variables RVM, the values UP and DOWN for the status variables KBZ, the value UP meaning that the communication relationship KB exists and through the value DOWN the opposite is displayed. If only one retransmission method RV is supported by a protocol instance PI, the status variable RVM can be omitted. This is indicated in the figures by the fact that in these cases the status variables RVM are shown in square brackets.

The communication between the protocol instances is effected in each case by the exchange of protocol data units PDU. These are designed, for example, to set up the communication relationship KB either as a set-up request BGN, as a set-up request confirmation BGAK and as a set-up request rejection BGREJ. The M and N information may be contained in the BGN setup request and BGAK setup request feedback. Information M indicates whether the sending protocol entity PI conforms to the protocol. If the protocol instance PI does not conform to the protocol, the information N indicates which non-protocol-compatible retransmission methods RV are supported. The information M is advantageously represented by a single bit, the value 0 indicating that the protocol instance PI conforms to the protocol, while the value 1 indicates that the protocol instance PI has been modified compared to the protocol P. In the case of a single protocol-compliant retransmission method RV (1) and a single alternative retransmission method RV (2), the information N can also be represented by a single bit, the value 0 indicating that both retransmission methods RV (1) and RV (2) are supported, and the value 1 that only the retransmission procedure RV (2) is supported. In general, bits that have not yet been used according to the P protocol are used for this for use. Since the value 0 is normally transmitted for such bits as standard, the information M = 0 and N = 0 is automatically transmitted by only protocol instances PI which implement the protocol P. These values are interpreted by a receiving protocol entity PI according to the invention in such a way that the protocol-compliant retransmission method RV (1) is implemented in the sending protocol instance PI. and the alternative retransmission procedure RV (2) is not supported. The method according to the invention can thus be implemented without changing existing protocol instances PI.

In Figure 1, the PI protocol entity _X as a protocol instance PIi (RV (1), RV (2)) is formed and the protocol entity PI ₂ as a protocol entity PI ₂ (RV (2)). This indicates that the protocol instance PIi optionally at least the protocol-compliant retransmission method RV (1) and at least the alternative retransmission method RV (2) and the protocol entity PI ₂ at least the alternative retransmission method RV (2) instead of the protocol-compliant Retransmission procedure RV (1) are supported. The status variables RVMi and KBZi are thus provided in the protocol instance PIi and the status variables RVM ₂ and KBZ _{2 are} provided in the protocol instance PI _2, the status variable RVM _{2 being} optional.

In FIG. 2, the protocol instance PI _{X is designed} as a protocol instance PIi (RV (1)) and the protocol instance PI ₂ as a protocol instance PI ₂ (RV (2)). This indicates that of the protocol instance PIi at least the protocol-compliant retransmission method RV (1), but not the alternative retransmission method RV (2), and of the protocol instance PI ₂ at least the alternative retransmission method RV (2), but not the protocol-compliant retransmission procedure RV (1) is supported. The status variables RVMi and KBZi are thus in the protocol instance PIi and the status variables RVM- and KBZ- in the protocol instance PI ₂ . provided, with the status variables RVMi and RVM _{2 being} optional.

For the exemplary embodiment, it is assumed that the establishment of the communication relationship KB in the two cases according to the figures is initiated by the protocol authority PIχ by sending the establishment request BGN.

In the scenario according to FIG. 1, the protocol entity PIi sends a setup request BGN, the information M = 1 and the information N = 0 st. This indicates that the retransmission methods RV (1) or RV (2) can be used in the protocol instance PIi modified compared to the existing protocol P. After receiving this message, the protocol authority PI _2, after evaluating the values M and N, specifies that the retransmission method RV (2) should be used, since only this is supported by it. This determination is shared with the protocol authority PIi by means of the BGAK it- setup request feedback, with which information M = 1 and N = 1 are transmitted. In addition, the status variable KBZ can assume the value UP in this protocol entity PI ₂ , ie from the point of view of the protocol entity PI ₂ , the communication relationship KB is established. After receiving the BGAK setup request feedback and checking the information M and N, the protocol retransmission PIi is set the alternative retransmission method RV (2) and the status variable RVMi = RV (2) is set. In addition, the status variable KBZ can now assume the value UP in this protocol entity PI _X , ie the communication relationship KB is also established from the perspective of the protocol entity PI _± . The retransmission method RV (2) is therefore used for this communication relationship KB.

In the case of the scenario according to FIG. 2, the protocol entity PIi sends a setup request BGN, the information being M = 0 and N = 0. According to the protocol P, no information should originally be displayed with this - this is indicated in the figures by the fact that, in contrast to FIG. 1, FIG. 2 does not contain any meaning of the values 0 or 1 in parentheses. From the PI protocol instance? However, this is interpreted to mean that the retransmission method RV (2) cannot be used in the PIi protocol instance. After receiving this message, the protocol instance PI _2, after evaluating the values M and N, determines that the two protocol instances PIi and PI _{2 are} not compatible with one another, since only the retransmission method is used by the protocol instance PIi

RV (1) and only the retransmission procedure RV (2) is supported by the protocol instance PI ₂ . This is communicated to the PIi protocol entity by means of the rejection request BGREJ. In addition, the status variable KBZ ₂ may retain the value DOWN in the protocol instance PI, ie the communication relationship KB is not established from the perspective of the protocol instance PI ₂ . After receipt of the rejection request BGREJ, the status variable KBZi is also retained in the PIi protocol instance, possibly the value DOWN, ie the communication relationship KB is not established from the point of view of the PIi protocol instance. Since the communication relationship KB was not established, no retransmission procedure RV is used. In this case, the RVM status variables have no significant meaning.

In the following it should be exemplified how the ITU standard Q.2110 from July 1994 as well as a protocol instance PI developed according to this standard and thus only supporting the retransmission method RV (1) can be expanded in such a way that either the

Retransmission procedure RV (1) as well as the retransmission procedure RV (2) is supported. The terms and abbreviations used in the ITU standard Q.2110 are assumed to be known, ie reference should be made to the corresponding standards for their definition. The choice of which of the two methods is used is made either administratively, for example by defining the method for a specific ATM service access point, or dynamically, for example by the user of the protocol or by exchanging protocol data units PDU with the neighboring protocol instance PI.

No further definitions are necessary for the administrative procedure, however, corresponding agreements must be kept by both protocol instances PI. For the dynamic process, at least one method of communication between the two sides is necessary in order to determine the retransmission procedure used. This method can of course also be combined with the administrative one.

A method for this definition is described below as an example. Other methods, such as A corresponding interface extension to the user of the standard Q.2110 and provision of the necessary control information by the users of the standard Q.2110 are in principle also possible, easy to define and are not excluded here.

Two previously reserved bits are used for the dynamic determination of the retransmission method RV in the credits of the setup request BGN ("committing") and the setup request feedback BGAK ("begin acknowledge"). In the version of the standard Q.2110 from July 1994 there are 26 of these or 34 reserved bits are available In principle, more than two bits, for example one or two bytes, could also be used. The bits M are used to transmit the information M and N, the bit used to transmit the information M. , hereinafter also 'C-Bit-M' and the bit, with the help of which the information N is transmitted, hereinafter also referred to as 'C-Bit-N'.

These bits are used as follows: If a protocol entity PI, which is expanded according to the invention and which masters the retransmission methods RV (1) and RV (2), tries to establish a communication relationship KB with the neighboring protocol entity PI, the C bit M of the set-up request BGN set to the value 1 to indicate that this is a protocol instance PI according to the standard Q.2110 from July 1994, which was modified in accordance with the teaching of this invention. The C bit N is set to 0 to indicate that both the RV (1) conforming to the July 1994 standard Q.2110 and the retransmission method RV (2) can be used. Since on the one hand reserved fields are set to the value 0 and not evaluated and on the other hand the value 0 of the C-bits identifies the previously defined correction mechanism of the SSCOP, this method is fully compatible with previous versions of the Q.2110 standard and the versions newly defined here.

Upon receipt of the BGAK setup request response, or upon receipt of a BGN setup request, provided the connection establishment is initiated by the neighboring protocol entity, the C bits are evaluated by the protocol entity PI expanded according to the invention. The decision is made according to the following table:

Table 1

Decision table for determining the retransmission procedure RV

The retransmission method RV defined for this communication relationship KB is recorded in the status variable RVM, designed as a local parameter C-meth of the protocol instance PI. Based on this, Chapter §8 of the specification of the standard Q.2110 in its version from July 1994 is modified by introducing two new parameters or variables:

C-meth the parameter which indicates which retransmission method RV is used for the existing communication relationship KB:

C-Meth = old the retransmission method RV (i; is used

C-Meth = new the retransmission method RV (i; is used The parameter is set in accordance with Table 1 above after receipt of the BGN setup request or BGAK setup request feedback.

VR (Err) a status variable of the receiver, which indicates whether there is a transmission error to be corrected

VR (Err) = yes there is a transmission error to be corrected that has already been reported via a USTAT or STAT message; further data packets received out of sequence do not result in a USTAT message being sent.

VR (Err) = no there is no transmission error yet to be corrected; a data packet received out of sequence e leads to the transmission of a

USTAT message; VR (Err) is set to yes.

After initialization of the receiver status variable and after receiving a message in the correct order, the variable contains the value no.

Control over the transmission of USTAT messages can also be controlled via other mechanisms, such as via the sequence number of the SD message triggering the USTAT message, but this is not explained in more detail here.

In addition to the correct setting or correct evaluation of the C bits and the correct initialization of the new variables the affected procedures of the Q.2110 standard are changed so that the go-back-N method is used for C-Meth = new:

1. In the standard Q.2110 from July 1994 on page 66 the figure 20 (sheet 40 of 51) is changed in such a way that SD messages arriving in the wrong order are discarded and a USTAT message is sent if necessary. Please note that due to the go-back-N method VR (H) = VR (R) must be, VR (H) may only be increased if this also happens for VR (R). Thus, when an SD message with N (S)> VR (R) VR (H) is received, the go-back-N method cannot be changed

2. Only the value of a received USTAT message

N (R) were evaluated and all data packets enqueued a Retransmissionbuffer from the packet with the sequence number N (R) ^'. Any data packets that are still in the retransmission buffer are discarded beforehand, since these would be ignored by the neighboring protocol instance PI anyway. However, the update of the value of VT (PS) stored with the data packets associated with the retransmission buffer is carried out normally

3. Only the values of a received STAT message

N (R) and N (PS) evaluated and all data packets from the packet with sequence number N (R) placed in the retransmission buffer, provided that the value of SD.NP (PS) stored with the data packet with sequence number N (R) is less than N (PS) of the STAT message received. If it is not, the STAT message is ignored. Any data packets already in the retransmission buffer are discarded beforehand or, according to their sequence number, placed in the retransmitter to be transmitted, if data packets are actually in the retransmission buffer be classified. The update of the value of VT (PS) stored with the data packets associated with the retransmission buffer m is carried out normally

4. The change of VR (H) upon receipt of a POLL message will not be made

With these changes described, the standard Q.2110 from July 1994 has the ability to also use the go-back-N method. Compared to the complexity of the entire Q.2110 standard, these changes are negligible. The procedure described for negotiating the retransmission procedure RV is fully backwards compatible with existing implementations of the standard Q.2110.

In particular, the method resulting from the use of the method described in the standard Q.2110 is also very efficient for go-back-N methods, since requests for retransmission of data packets do not have to be controlled by excessively long timers.

In addition, it should be mentioned as an example how the ITU standard Q.2110 from July 1994 and a protocol body PI designed according to this standard and thus only supporting the retransmission procedure RV (1) could be changed so that this instead of the retransmission procedure RV (1) the retransmission procedure RV (2) is supported. This version of the ITU standard Q.2110 is therefore generally not compatible with the version of the ITU standard Q.2110 defined in July 1994, for example, but only with an equally reduced version or the extended version just described. However, the reduced version is characterized by a significantly lower complexity of the protocol. When using this reduced version, it must be ensured that the neighboring protocol entity PI provides a compatible protocol version. This can be done either statically or dynamically. Static definition can be designed, for example, as an administrative configuration of the protocol instances PI. Before establishing communication relationships KB, the retransmission method RV is used. During the establishment of a communication relationship KB between two protocol punch PIs configured in this way, no further measures are taken to determine the retransmission method RV to be used.

A dynamic definition takes place, for example, with the aid of PDU protocol data units. When the information M = 1 and N = 0 or M = 1 and N = 1 is received in a setup request BGN, the setup request feedback BGAK replies with the information M = 1 and N = 1. The same information is used in the setup request BGN when the connection setup is initialized by the protocol entity PI modified in this way. However, if this protocol entity PI receives the information M = N = 0 in a setup request BGN or setup request response BGAK, the connection is rejected according to Table 1, since this value indicates that the adjacent protocol entity PI is not compatible. However, a communication relationship KB could also be established in the event of an incompatibility if the transmission error rate can be ignored. This may have been announced to the PI protocol authorities, for example on the basis of prior administrative work. In this case, the retransmission method RV used is not relevant since there are no or only negligible retransmission requirements. 17

Furthermore, the procedures for handling received SD, STAT and USTAT messages are changed in such a way that the corresponding procedures are reduced by those parts which are only required for carrying out the retransmission procedure previously defined in the July 1994 standard Q.2110 , The generation of STAT messages is also simplified since a list no longer has to be created. The simplifications that can be further achieved are not carried out in detail, but are obvious to any expert familiar with the prior art using the information given here.

In conclusion, it should be emphasized that the invention is not limited to extensions of the ITU standard Q.2110, but can be applied to any protocol P which is designed in accordance with the features of the main claim relevant to the protocol P. In particular, the invention is applicable to further developments of the ITU standard Q.2110, such as the ITU standard Q.2111.

Claims

claims

1. Method for transmitting data packets, in which at least one version of a protocol (P) in the

In the event of unsuccessful transmission, at least one retransmission procedure (RV (1)) is provided, according to which only unsuccessfully transmitted data packets are retransmitted, characterized in that either for this retransmission procedure (RV (1)) or instead of this retransmission procedure ( RV (1)) at least one alternative retransmission method (RV (2)) is provided, according to which all data packets are retransmitted from a data packet transmitted unsuccessfully.

2nd Method according to Claim 1, characterized in that when a communication relationship (KB) is established between two neighboring, protocol-compliant protocol instances (PI) of a communication network, the retransmission method (RV) is used to retransmit unsuccessfully transmitted data packets at least for the duration of the existence the communication relationship (KB) will take place.

3. The method according to claim 2, characterized in that before establishing the communication relationship (KB) by administrative configuration in the neighboring protocol instances (PI), the retransmission method (RV) is set, after which after the communication relationship (KB) the retransmission of unsuccessfully transmitted data packets will take place at least for the duration of the existence of the communication relationship (KB).

4th Method according to Claim 2, characterized in that when the communication relationship (KB) is established, each of the two protocol entities (PI) communicates to the other protocol entity (PI) which retransmission methods (RV) are supported and which are used as the retransmission Method (RV), according to which after the establishment of the communication relationship (KB) the retransmission of unsuccessfully transmitted data packets will take place at least for the duration of the existence of the communication relationship (KB)

Retransmission procedure (RV) is selected, which is supported by both protocol instances (PI).

5. The method according to any one of the preceding claims, characterized in that essentially signaling information is transported from the data packets.

6. The method according to any one of the preceding claims, characterized in that the protocol (P) is essentially in accordance with an international ITU standard (Q.2110).

7. The method according to any one of the preceding claims, characterized in that the version of the protocol (P) corresponds essentially to the version of the international ITU standard Q.2110 from July 1994.