single couples of Fast LSU PDUs: what is the scenario?

Often, and on several frequencies, I noted isolated couples of Fast LSU PDUs (BW5 waveform) which exhibit the following characteristics:

1) since the strength of the signals, the bursts seem to be issued by the same station;
2) they are not immediately followed by traffic (circuit or packet);
3) in all the observed cases the time distance bewteen the two bursts is always the same, ie ~2212 msec (Fig. 1) as if there was a missing LFSU PDU in the middle (Fig. 2). It's worth noting that the time between a Request and a Confirm PDU is ~580 msec;

Fig. 1

Fig. 2

4) PDUs have inconsistent protocol field values, thus, unless decode errors, these are issued in Linking Protection mode.

That said, what scenario these couples of FLSU PDUs depict? 

I searched an answer in STANAG-4538 #5.1, which describes, by means of specific example scenarios, a subset(!) of the over-the-air capabilities provided by the FLSU protocol. According to these examples, the copied FLSU PDUs can be attributed to failed 2-way link setups (circuit mode) and to failed LQA exchanges. Other scenarios as the Broadcast TOD (Time Of Day) distribution are less probable since their specific format.  

a) failed 2-way link setup (circuit mode) 

Fig. 3a - failed 2-way link setup (circuit mode)

All two-way FLSU calls require only a request and confirm PDU transmission. A third transmission is issued only if the caller station does not correctly receive, or does not receive, a confirm PDU as expected (the empty place in Fig.1): in these cases, the caller station is required to transmit an FLSU_Terminate PDU.

If this were a packet traffic example, sending an FLSU_Terminate would impose a triple demodulation requirement on the receiving station. Thus, the calling station must send up to N “xDL_Terminate” (EOM)  PDUs to abort the ARQ protocol, ie a BW1 ACK for HDL and a BW4 ACK for LDL as in Fig. 3b (ACKs sent in the data forward direction are intended as EOM).  
Since this is a circuit traffic example, the “xDL_Terminate” PDUs is not necessary, and the calling station sends the FLSU_Terminate PDU immediately after the failed call response (as in Fig. 3a).

Fig. 3b - failed 2-way link setup (packet mode)

b) failed LQA exchange

Fig. 4

Many times I copied 2G LQA exchange requests w/ no reply sent by the called station e.g.:

11130.0: X2: 1012 USB MIL 188-141 2G-ALE calling S41, requesting LQA exchange, no reply 

and this could be a possible 3G scenario of such cases.

As said above, the basic exchange in FLSU is a two-way handshake: the caller sends a request PDU and the called station responds with a confirm PDU; if the caller station does not correctly receive, or does not receive, a confirm PDU as expected, the caller is required to transmit an FLSU_Terminate PDU.

c) Broadcast TOD distribution

In a TOD Distribution scenario, the unsynchronized station transmits 1.35N Asynchronous FLSU_Req PDUs using the asynchronous calling technique described in this post. The FLSU_ Request PDU (with traffic type set to TOD) is transmitted once, at the end of the asynchronous calling period . 

The Broadcast TOD distribution can be achieved by the net control station issuing both the TOD_Request and TOD_Response PDUs. All stations that monitor the broadcast TOD can then receive the TOD sync passively. The TOD_Response PDU is sent after the monitoring timeout period which is defined as two scanning dwell periods.
But, if this were the scenario, the TOD_Request is sent alone and not as the last in the Async request! so this case appears improbable (Fig. 5).

Fig.5

d)
Lastly, one could say that I did not copy the missing FLSU Confirm PDUs: yes, it could be real, but the fact that in all these copies I never heard them would be singular as much as  improbable.

Above I have exposed my (maybe wrong?) suppositions, but vendors implementations and the common practice, which may diverge from the standard specifications, must also be considered as well as other capabilities that are not specified in the STANAG-4538 profile. 
That's why I expect your comments (after all, that's the beauty of the web).
  

https://yadi.sk/d/cAJShDFl3EzkYc 
https://yadi.sk/d/ltCmE4Go3EzksW