interesting paper about IP Multicasting in HF Radio Networks

I recently found in the web the interesting paper titled IP Multicasting in HF Radio Networks (2008) that proposes a multicast data link protocol for third generation (3G) high frequency (HF) radio networks:

http://mac-ee211.nmsu.edu/hf/papers/3g_mdl.pdf
I have a doubt about the "MDL Operation" paragraph and the related Figure 3 of the paper:

According to §4.6.5 "Dual Demodulation" of Annex-C to STANAG-4538 Ed.1: under no circumstances shall PUs be required to simultaneously demodulate more than two waveforms.
Well, at time "tn" in Figure 3 the receiving PUs expect an LDL_DATA PDU (BW3) or an LDL_EOM/TERM PDU (BW4): sending a FLSU PDU (BW5) would impose a triple demodulation requirement. 

Thus, the calling PU shall send an LDL_EOM PDU (BW4) to indicate that the entire datagram has been transferred and the FEC Phase 0 session is terminated; then the following FSL PDU (BW5) will be sent to announce the repetition of the datagram in the alternate FEC code:

Anyway, since the multicast scenarios proposed in the paper have been evaluated using the DoD-validated HF Network Simulator (NetSim-SC), and then not implemented in real radios, the procedure depicted in Figure 3, although wrong, could be a simplification.

a possible EMCON retransmission mode for Multicast Data Link protocol ?

This is an MDL-N (Multicast Data Link with NACKs) transfer received on 10958.0 KHz/USB. The transfer begins with an FLSU Point-to-MultiPoint call (BW5) followed by four forward transmissions consisting of LDL288 DATA PDUs (BW3); the ending BW4 burst is the LDL EOM PDU informing the receiving stations that the entire datagram has been transmitted. In MDL-N each forward transmission is followed by a pause, during which receivers that were not able to decode that transmission emit a very robust pseudonoise PSK symbol sequence to request retransmission: in this sample there is no NACK PDUs issued by the receiver stations.

At a first glance, one could say that the incoming datagram at the sender has been splitted in four LDL 288-byte data packets (unless the padding bytes in the last packet) which are then forwarded using four BW3 bursts ...but things are not properly in this way.
Indeed, looking at Figures 1-2,  it's easy to notice that packets #1 and #2 are exactly the same, as well as the packets #3 and #4 (275 bytes length). 

Fig. 1 - packets #1, #2

Fig. 2 - packets #3, #4

This means that each packet is sent twice before to clear the TxFrame buffer, so that the receiver stations have two copy of the same message, each obtained by adding the packets #1, #3 and the packets #2, #4 (Fig. 4)

Fig. 4 - the received entire datagram

(note that the encryption is applied before the datagram is segmented).

According to these observations, I try to give an explanation that makes sense to that scenario.
For a reliable transmission of the message, each packet is always sent twice (at leats in this sample): a station that decodes the entire error-free message can deliver the message and discard the copy. Otherwise it must process the copies and attempt to correctly decode the message. Summarizing: each packet is transmitted n-times instead of n-retransmissions of the complete message.  This mechanism could contrast with the chance of use ACK/NACK PDUs, but - other than adds redundancy - it could be also a good solution in case of receiver stations which must remain in EMCON mode (radio silence) for extended periods and consequently can't send NACKs neither delayed acknowledgements.  
The same behavior has been observed also in some LDLn transfers, but here the retransmissions could be requested by the receiver station.
Most likely, to increase the reliability a sort of 'retransmission counter', or a 'configurable setting', indicates the number of times each packet shall be retransmitted (repeated) or not during a particular link , according to the established xDL PDU for that transmission and the conditions of the channel, no matter if the packets have been ACKed or not, to increase the probability that user data will be received correctly.

As pointed out, this is a my thought, a supposition based on what I see: I do not know if it's  just a coincidence or a sort of implementation of STANAG-4538 since I have not found confirmations in the documentation that is publicy available in the web. Further recordings are needed in order to better understand this kind of scenario. By the way, your comments are welcome.

 https://yadi.sk/d/J8mreWoP3Go2ip

3G MDL with BW3-32 (LDL) burst waveform

Yet another over-the-air example of 3G Multicast Data Link (MDL) protocol copied on 7700.0 KHz/USB at 2206 UTC, 14 Mar: this time the BW3 waveform from the LDL protocol, the one with a 32-byte payload (most robust), has been used.

The One-way Point-To-Multipoint (PTM) FLSU_Request PDU specifies the group address as its destination and the originating station address as its source. The Channel field is normally set to ‘111111’ to indicate that the channel carrying this PDU will also be used for the traffic. The Traffic Type field indicates which of the MDL modes will be used to carry the traffic.

The carried message has been secured using Harris "Citadel" encryption, as well as the FLSU_Request (sent in Linking Protection mode).

https://yadi.sk/d/hZI6WjHL3FsjGs

a 3G Multicast Data Link w/ NAKs?

few days ago, 16 Feb, I copied a 3G-HF transmission on 10958.0 KHz/USB consisting of an initial FLSU PDU (BW5 burst) followed by 13 not-ACKed LDL PDUs (BW3 bursts) and ending with a single BW4 burst: since LDL is a stop-and-wait ARQ protocol, ACK burst were expected. This scenario recalls the 3G Multicast Data Link with NAKs (MDLN) protocol previously copied and reported here (Fig. 1).

Fig. 1

I could not find official NATO/Stanag documentations about the 3G Multicast but only some "proposed" papers; Multicast MDL Protocol is still cited as "still in development" in STANG-4538 Amendment 2 Draft 0.3, the one at my disposal, thus the following are my suppositions based on the clues which I can see, so, comments are welcome (after all, this blog is just a collection of notes and experiences of a digital signals enthusiast and amateur analyst and does not claim to be a scientific blog).

Multicast Data Link protocol (MDL/MDLN) shares many of the characteristics of the other 3G data link protocols but unlike the 3G ARQ protocols, MDL links employ the one-way link setup: each transmission begins with an TM,  FTM or FLSU PDU that indicates the MDL mode that will be used in the remainder of the transmission.

The MDL_Data PDUs use the BW2 and BW3 burst waveforms used in HDL and LDL: in this case the MDL-288, a stream of 288-byte bursts, is used (as known the BW3 data section can be any multiple of 32 bytes, from 32 up to 512 bytes).

Fig. 2 - BW3 frame

The transfer ends with a BW4 burst, Fig. 3, most likely acting as MDL_EOM PDU (any PDU sent using BW4 in the forward direction is an EOM PDU).

Fig. 3

Sending an FLSU_Terminate would impose a triple demodulation requirement [1] on the receiving stations (they do not expect BW5 bursts) thus, as it happens in LDL transfers, the calling station sends an MDL_EOM PDU (BW4 burst) to signal the receiving stations that the datagram has been transferred, and hence will send no more MDL_Data PDUs for the current datagram.  MDL_EOM PDU would use BW1 burst in case of MDL-5k (HDL BW2 used for MDL_Data)?

Once demodulated, the received datagram transports Harris Citadel off-line encrypted messages (Fig. 4) 

Fig. 4

[1] Dual Demodulation clarifying example:

PU1 issues a FLSU_Request to PU2, requesting LDL ARQ traffic. PU2 issues a FLSU_Confirm that is not received by PU1 due to poor propagation. Since PU2 must only look for at most two waveforms, it looks for the LDL Forward Packet waveform (BW3) and the LDL_EOM PDU (BW4). Thus, in order to terminate the link due to missing the FLSU_Confirm, PU1 must send a LDL_EOM followed by a FLSU_Terminate.

https://yadi.sk/d/koXEHpgJ3EFozb 

a (possible) 3G-HF multicast transfer with MDLN protocol

This burst-trasmision has been heard on 13505.0 KHz/USB at 1120 UTC (27 Oct). All of the burst waveforms use an 8-ary PSK serial tone modulation of an 1800 Hz carrier at 2400 symbols per second (fig. 1)

fig. 1

The analysis of the bursts say that they belong to the HF burst waveforms described in STANAG-4538 3G-HF, specifically: after the initial BW5 FLSU burst, there are four BW3 tansmissions which transport 4 x 512 bytes of data and two zero-filled BW3 transmissions which transpot 2 x 51 bytes of data. The transfer ends with a single BW4 burst. BW3 and BW4 waveforms are used by LDL protocol, as defined in STANAG-4538.

fig. 2 - BW3 burst

fig. 3 - BW4 burst

In a normal  LDL data transfer, the sending station and the receiving station alternate transmissions in the manner of figure 4: the sending station transmits LDL_DATA PDUs containing payload data  packets,  and  the  receiving  station  transmits  LDL_ACK  PDUs  each  containing  an acknowledgement  of  whether  or  not  the  data  packet  in  the  preceding  LDL_DATA  PDU  was received without error. The LDL_EOM PDU is transmitted using  the  BW4  waveform indicating that the entire user  datagram  has  been  delivered  to  the  receiving  station  without  errors ( LDL_EOM  PDUs  are  distinguished  from  LDL_ACK PDUs by context: any PDU sent using BW4 in the forward direction is an LDL_EOM PDU, while any PDU sent using BW4 in the reverse direction is an LDL_ACK PDU).

fig. 4 - 3G-HF LDL protocol transfer session

Conversely, in this recording there are no BW4 ACK bursts returned by the receiver station but only a final BW4 burst... unless the BW4 ACKs were transmitted and I did not receive them (Fig. 5):

fig. 5 - the heard 3G-HF session

The supposed lack of ACKs in figure 5 leads to think to a non-ARQ multicast transmission or a trasmission for recipients which are in EMCON (Emission Control): anyway STANAG-4538 does not provide the non-ARQ modality and the HDL/LDL protocols are for point-to-point applications only.

A possible scenario could be the use of the MDL-NACK protocol, Multicast Data Link with NAKs or MDLN. MDLN is a 3G multicast protocol with embedded retransmissions, it's added alongside the point-to-point 3G data link protocols HDL, HDL+ and LDL and shares many of the characteristics of the other 3G data link protocols (fig. 6).

fig. 6 - extended 3G-HF

In MDLN each forward transmission is followed by a pause during which receivers that were not able to decode that transmission emit a very robust pseudonoise (PN) PSK symbol sequence to request retransmission (fig. 7). All receivers share the NAK slot. (Detection of the PN NAK sequence is sufficiently robust to allow any number of NAKs to overlap during the slot.) When the sender detects a NAK, it sends additional redundancy bits. Thus MDLN, like the point-to-point ARQ protocols, sends only enough redundancy to convey the message error-free. 

In our case, the data transfer is performed using MDL-512, a robust mode that uses a stream of 512-byte BW3 bursts. All recipients have decoded the entire transmission so we do not see NACKs.

fig. 7 - MDL-NACK opeation

MDL-MDLN protocol has been introduced in "Third Generation and Wideband HF Radio Communications" and in "Military Communications Conference, 2005" by E. Koski - Harris Corporation. The presence of the Citadel pattern (fig. 8) in the decoded bistream is a strong clue and would just confirm the use of Harris equipment. The transfer contains only one encrypted datagram. Obviously, the encryption is off-line.

fig. 8 - Citadel encryption

https://yadi.sk/d/7sMqo4-OxnJEm