Fig. 1 shows the required procedure for a failed Link Set Up. All 2-way FLSU calls require only a Request and Confirm PDU transmission. The third handshake is issued only if the caller PU does not correctly receive a Confirm PDU as expected. There can be many reasons for such a case. Some examples include: CRC failure, propagation failure, an unexpected result in any field of the FLSU_Confirm PDU, or reception of an unexpected PDU of a different type. In these cases the caller PU is required to transmit a FLSU_Terminate PDU. However, the caller must honour the requirement that a receiving PU need not execute more than dual demodulation.
 |
| Fig. 1 |
The scenario in fig. 2 depicts the case in which the HDL ARQ protocol is invoked via the original FLSU call.
Since the calling PU did not receive the FLSU_Confirm response, it must assume that the response did not propagate properly and that the called PU is prepared for the HDL packet transfer protocol. As such, the called PU is set up to receive either the first HDL forward packet PDU (BW2), or an HDL_Terminate PDU (BW1) . Sending a FLSU_Terminate (ie a BW5 burst) would impose a triple demodulation requirement on the receiving PU!
Thus, the calling PU must send up to N BW1 bursts carrying the HDL_Terminate PDU’s to abort the ARQ protocol (under the xDL protocol specification, “N” is defined by the number of xDL_Terminate PDUs that would fit within the time slot of a forward packet PDU). In this sample, the caller sends 3 BW1 bursts for a total duration of (3 x 1306.66) = 3919.98 msec.
If this were a Circuit Traffic example, as seen, the “xDL_Terminate” PDU’s would not be necessary, and the calling PU could send the FLSU_Terminate PDU (BW5) immediately after the failed call response.
If this were a Circuit Traffic example, as seen, the “xDL_Terminate” PDU’s would not be necessary, and the calling PU could send the FLSU_Terminate PDU (BW5) immediately after the failed call response.
 |
| Fig. 2 |
 |
| Fig. 3 |
No comments:
Post a Comment