27 April 2017

STANAG-5066 CFTP messaging over MIL 188-110A

The transmission has been copied on 7788.0KHz/USB and consists of an emails exchange between an Algerian Navy ship (Rais Hamidou) and the Headquarter of French Navy in Toulon (COMTOULON).  Messaging is performed by Stanag-5066 CFTP protocol (Internet Messaging over ARQ) in half-duplex mode, carried by MIL 188-110A serial waveform (Fig. 1). Link is not negotiated/established using ALE but by means of voice-comms between the operators.

Fig. 1
Basically, CFTP (Compressed File Transfer Protocol), sometimes referred to as BFEM (Battle Force Email), is a file transfer mechanism and STANAG 5066 Annex F defines its use for message transfer. CFTP is specified to work over a point to point network - that is, to communicate between a pair of nodes, with both nodes able to send data.

Fig. 2 - S5066 bitstream synched on D_PDU SYNC
The CFTP protocol shall not be used for Formal or High Grade Military Messaging (military orders) and may be used for informal interpersonal e-mail only; anyway, I'm interested in the way the "boxes" travel and not in their contents.
In operation, when an email message is received at a S-5066 node (port 5066 on localhost), it is placed in an incoming mail folder (mail spool directory). The CFTP client, also called the Delivery Agent, removes the mail from this incoming folder and compresses the message and information about the message, e.g. size, id, recipients, etc. into a file which is then transferred to the destination node using the Edition-1 Basic File Transfer Protocol (BFTPv1)  PDUs which are then incapsulated into Data PDUs (Fig. 2) before to be sent to the HF modem. The structure of BFTPv1  PDU is shown in Fig. 3, along with the g-zipped file from the copied transmission.

Fig. 3 - BFTPv1 Protocol Data Unit Structure
Client Delivery confirmation is provided by the receiving node using the Message Acknowledgement, sent as the body-part (!) of a CFTP/RCOPv1 PDU:

Fig. 4 - BFTPv1 Message Acknowledgement Structure
The CFTP mail-file is built as specified in paragraph "F.14.6 Detailed Description of CFTP, ANNEX F to STANAG 5066 Edition 3":

Fig. 5 - CFTP email-file
Below, some details about the two STANAG-5066 nodes in the play:

node: EMMA046
tactical callsign: PI (papa india)
S-5066 address: 006.014.100.001 (official  NATO S-5066 address)
email domain: toulon.frenchnavy.fr
host: EMMA046 (Rockliffe SMTPRA 4.2.4)
site: COMTOULON Toulon, French Navy

node: BDSL472
tactical callsign: BD (bravo delta)
S-5066 address: 010.000.000.001 

(near-official NATO S-5066 address since the 010.001 block is assigned to Algeria)
email domain: rh.raishamidou.dz
host: BDSL472 (Windows NT 6.1; WOW64; rv:24.0)
site: corvette "Rais Hamidou", Algerian Navy

Rais Hamidou corvette, photo from wikipedia https://fr.wikipedia.org/wiki/Rais_Hamidou_(corvette)
The other labels in the emails headers offer some other informations:  

1) PC at COMTOULON run an SMTP daemon hosted on a Rockliffe MailSite based server (Rockliffe SMTPRA 4.2.4):
https://www.rockliffe.com/index.html

2) the "WOW64" in user-agent string means a 32-bit version of Internet Explorer is running on a 64-bit processor: so the ship is equipped with a 64-bit PC running Windows7 or Windows Server 7 (Windows NT 6.1)

By the way, it's interesting to note in the curious behavior of one of the two 188-110A modems and  precisely the one at the ship side of the link: the initial 2600Hz tone-beep is maintained for the duration of each single transmission time and does not affect the correct demodulation of the signal (Fig. 3)

Fig. 3
Although 188-110A is an auto-baud waveform, operators negotiate the speed and interleaver which will be used during the initial phase of the data transmission: this leads to think to inter-operability or deployment tests.

(due to confidentiality, wav file and bitstream are not avalilable. Sorry.)

25 April 2017

Logs


05717.0: MER39ALEX: Unid 0536 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to ALEX (20Apr17) (AAI)
06258.0: ---: Unid 1753 USB R&S GM-2100 serial modem 2400Bd bursts (22Apr17) (AAI)
06303.0: ---: Unid 1954 USB 2-way FLSU handshake followed by LDL32 sending 139 bytes 'Citadel' encrypted datagram (20Apr17) (AAI)
06303.0: ---: Unid 1958 USB 2-way FLSU handshake followed by LDL512 sending 2379 bytes 'Citadel' encrypted datagram (20Apr17) (AAI)
06745.0: COLMALEX: Unid 1722 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to MER22ALEX (19Apr17) (AAI)
06745.0: MER22ALEX: Unid 1724 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to COLMALEX (19Apr17) (AAI)
06745.0: MER39ALEX: Unid 1723 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to MER22ALEX (19Apr17) (AAI)
06745.0: MER39ALEX: Unid 1729 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to MER28ALEX (19Apr17) (AAI)
06933.0: M72: Israeli Air Force Boeing KC707, ISR 0707 USB MIL 188-141 2G-ALE calling itself ??? (06Apr17) (AAI)
07401.0: ZBOR: German customs Patrol vessel Borkum, D 0755 USB MIL 188-141 2G-ALE calling ZLST (11Apr17) (AAI)
07480.0: DO7: Polish Military, POL 0621 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to OS6 (12Apr17) (AAI)
07527.0: TYMT2: Spanish Police Toledo, E 0619 USB MIL 188-141 2G-ALE sounding (14Apr17) (AAI)
07692.0: Q7E: Moroccan Gendarmerie, MRC 1901 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to 0VM (09Apr17) (AAI)
07692.0: W4V: Moroccan Gendarmerie, MRC 1637 USB MIL 188-141 2G-ALE handshake Q7E followed by MIL 188-110A serial (07Apr17) (AAI)
07715.0: ---: Unid 1906 USB 3G-HF 2-way FLSU handshake followed by LDL128 transfer (11Apr17) (AAI)
07803.0: RFFXCC: French Forces CENTCORADIO FAVIERES, F 0710 (cf) ARQ-E 184.6Bd/400 test msg to REGLEGETPARA CALVI (10Apr17) (AAI)
07813.0: S31: Moroccan Military, MRC 1856 USB MIL 188-141 2G-ALE sounding (09Apr17) (AAI)
07885.0: PIZ: Unid 0818 USB MIL 188-141 2G-ALE any station call followed by MIL 188-110A serial (24Apr17) (AAI)
07903.0: ---: Unid 1819 USB 3G-HF 2-way FLSU handshake followed by circuit mode (MIL 188-110A serial) (14Apr17) (AAI)
07917.0: BS110A: Unid (prob. Algerian net, ALG) 0857 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to BS108B (17Apr17) (AAI)
07940.0: 400001: Mauretanian Law-Enforcement, MTN 1846 USB MIL 188-141 2G-ALE sounding (09Apr17) (AAI)
08021.0: ---: Unid 1200 USB STANAG-4285 600bps/L modem, KG-84 encrypted messages (11Apr17) (AAI)
08061.0: ---: Unid 2140 USB 3G-HF 2-way FLSU handshake followed by LDL232 transfer (10Apr17) (AAI)
08070.0: 123: Algerian Military, ALG 0906 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to AT5 (08Apr17) (AAI)
08086.5: ICI11: Italian Coast Guard Catania, I 1149 J3E/USB calling ship IGSV for a radio-check, no reply heard (11Apr17) (AAI)
08125.0: DU6: Polish Military, POL 0638 USB MIL 188-141 2G-ALE handshake HA9 followed by MIL 188-110A serial (12Apr17) (AAI)
08165.0: ---: Russian Mil, RUS 1700 USB CIS-45 HDR modem v2, OFDM 45-tone 40Bd DQPSK (20Apr17) (AAI)
08218.0: ---: Unid 1738 USB 2-way FLSU handshake followed by HDL+ (21Apr17) (AAI)
08327.0: ---: Unid 1416 USB 3G-HF 2-way FLSU handshake followed by 10 x LDL160 transfer (9 retransmissions of the same Citadel encrypted data packet) (14Apr17) (AAI)
08327.0: ---: Unid 1445 USB 3G-HF 2-way FLSU handshake followed by HDL+ transfer (14Apr17) (AAI)
08330.6: ---: Unid 0750 USB STANAG-4285 600bps/L modem, KG-84 encrypted messages (11Apr17) (AAI)
09182.0: N61: Chinese Military, CHN 1735 USB MIL 188-141 2G-ALE calling A99 (20Apr17) (AAI)
09328.0: ---: Russian MFA, RUS 0825 (cf) FSK 200Bd/1000 (08Apr17) (AAI)
10600.0: 641814: Unid USB MIL 188-141 2G-ALE sounding (13Apr17) (AAI)
10958.0: ---: Unid 1356 USB 3G-HF MDL transfer using LDL288 (08Apr17) (AAI)
11010.0: ---: Unid 0858 USB ARCOTEL-MAHRS 2400 Serial ARQ system (13Apr17) (AAI)
11130.0: GR2: Moroccan Military, MRC 1908 USB MIL 188-141 2G-ALE sounding (07Apr17) (AAI)
11165.0: BASOR1: Algerian Air Force, ALG 0811 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to CM1OR1 (09Apr17) (AAI)
11165.0: CM1: Algerian Air Force, ALG 0815 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to 761 (09Apr17) (AAI)
11165.0: CM1: Algerian Air Force, ALG 0818 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to 745 (09Apr17) (AAI)
11169.6: ---: Unid 0822 (cf) Siemens CHX-200 modem selcall (09Apr17) (AAI)
11226.0: AKR: USAF Akrotiri, CYP 1122 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to 201085 (24Apr17) (AAI)
11430.0: 410BBLU410CAVB: US Army 1248 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to 410BCDR410CAVB
11430.0: 64BSBT: US Army 1328 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to BDETOC3ABCT
11454.0: ---: Russian Mil/Gov, RUS 0928 USB CIS-3000 PSK-8 3000Bd followed by MFSK-64 (32+32) 45Bd (10Apr17) (AAI)
13449.5: ---: UK Mil/Gov St. Eval 1340 USB WinDRM-based OFDM 51-tone modem (14Apr17) (AAI)
16083.0: ---: Russian Intel, RUS 0900 USB CIS FTM-4, MFSK-4 150Bd (effective 37.5:Bd) 4000Hz modem (tones at: -6, -2, +2, +6 KHz) 8 mins lasting (10Apr17) (AAI)
16332.3: A: MX Beacon "A" Astrakhan 1238 CW id "._" (20Apr17) (AAI)


23 April 2017

CIS Navy FSK 50Bd/250 136 bit


Interesting signal from my friend KarapuZ: it's the quite uncommon 50Bd/250 136 Bit by some Cis networks, most likely CIS Navy. The waveform is similar to the well known T600 (50Bd 200/250Hz) but in this case the full period is 544 bits lenght, ie 4 x 136 bit frames.

Fig. 1
Fig. 2

20 April 2017

splitting datagrams into LDLn Tx Frames

This post is added  to complete the previous one, so to study and verify the way a datagram is splitted to fit the length of the chosen LDLn Tx frame (n =32,64,96,…,512 bytes) and the mechanism used to fill the remaining room. This recording concerns a 139-byte lenght 'Citadel' encrypted datagram which is sent within five LDL32 PDUs, ie using 5 x 32 = 160 bytes: the protocol shall fill the extra 21 bytes of the last PDU with 0-value bytes (Fig. 1). 

Fig. 1
After the data link connection has been configured (FLSU/BW5), the sending station and the receiving station alternate transmissions in the usual STANAG-4538 manner: the sending station transmitting LDL PDUs containing payload data packets (BW3), and the receiving station transmitting ACK PDUs (BW4) each containing an acknowledgment of whether or not the data packet in the preceding LDL PDU was received without error. The sending station sends an EOM PDU (BW4) repeated as many times as possible to indicate to the receiving station that the the datagram have been delivered successfully and the link will be terminated (Fig. 2)

Fig. 2
For a better understanding of the way LDL protocol works the incoming datagram, let's see how the LDL PDU and BW3 are formed (quoting Annex C to NATO STANAG-4538).
If the Tx Frame buffer is clear, construct a new outgoing data packet in the following manner (Fig. 3):
1. Get the next data segment (the next PacketLength consecutive data bytes to be transmitted) from Tx Datagram buffer; place these in the Payload field of the data packet. If fewer than PacketLength data bytes remain to be transmitted, place these bytes at the
beginning of the Payload field; fill the remainder of the field with zero-valued bytes so that the Payload field contains a filled segment.
2. Construct a sequence number and write this value into the packet’s Sequence Number field.
3. Construct a control field with all 8 bits set to zero.
4. Place the data packet generated in steps 1-3 into the Tx Frame buffer.
5. Send an LD PDU containing the tx frame in Tx Frame buffer, using BW3 waveform.

Fig. 3
It's worth noting that:
- one LDLn Tx Frame, same as an LDLn PDU, consists of a single data packet of n-bytes (n=32,64,96,…,512); then LDLn delivers chunks of n-bytes at time (n=32,64,96,…,512);


- one HDLn Tx Frame, same as an HDLn PDU, consists of n-data packets each of 233 bytes (n=3,6,12,24); then HDLn delivers n-packets at time, each of 233 bytes (n=3,6,12,24).

 
The number of bits in a BW3 data packet is of the form 8n+25, where n = 32, 64, 96, 128, 160, 192, 224, 256, 288, 320, 352, 384, 416, 448, 480, or 512 (number of payload data bytes carried by each LDL protocol forward transmission);  the additional 25 bits of payload in each BW3 transmission are LDL overhead (17 bits Sequence number + 8 bits for reserved use). A 32-bit Cyclic Redundancy Check (CRC) value is computed across the payload data bits in the data packet, and is then appended to the data packet, then 7 flush bits having the value 0 are appended to the (8n+57) bits of the data packet with CRC to ensure that the encoder is in the all-zero state upon encoding the last flush bit.
So each BW3 data packet has a length of 8n+64 bits (8n+17+8+32+7): just the latest eigth bytes will be used for the analysis.

From theory to practice, the way the 139 byte datagram is splitted in five LDL32 Tx Frames can be verified by inspecting the  Sequence Number fields in the last 64 bits of the five BW2 data packets of the copied transmission (Fig. 4).

Fig. 4
Some aspects must be first considered:

a) the 8-bit reserved field is added after the CRC field and not after the Sequence Number, as specified in Annex C to STANAG-4538; I don't know if it's the modus operandi of the decoder;

b)  following the last bit of the Payload field-value, the bits of the Sequence Number field are transmitted starting with the least significant bit (bit 0) rather than the most significant bit (bit 16). Most likely it's the modus operandi of the decoder, as above;

c) as in the Sequence Number of HDL Tx frames (see the previous post), the bits 14-6 of the first packet in datagram contain the number of user bytes in packet -1 and this contrasts what specified in Table 7.1.4.1-2; it depends on the particular STANAG-4538 implementation?

c) the 'Packet Number', bits 5-0 in the Sequence Number field, indicates the position occupied by a data segment within a datagram. Since the datagram passed to LDL for delivery is an ordered sequence of up to 16,384,000 bytes (7,634,944 bytes for LDL), limiting the packets addressing to 6 bits could be fastidious in ARQ.

As expected, EOM and SOM fields (bits 16,15) show that the BW2 packet 0 contains the first packet of the datagram, while BW2 packet 4 contains the last packet of the datagram. Consequently, the Packet Number (bits 5-0) starts from 0 to 4: ie, the useful payload consists of five BW2 packets. Consider now the Packet Byte Count (bits 14-6): as already specified, this field show the number of user bytes in packet –1. Each of the first four packets contains 32 bytes (00001111 = 31) and the last packet contains 11 bytes (00001010 = 10). The outgoing datagram was then (4 x 32) + 11 = 139 bytes length.
During the traffic setup phase, the user process determines the number of data bytes per LDL PDU so as to deliver the user data efficiently. Once it is determined, every transmitted LDL PDU shall contain the same number of data bytes until the entire datagram has been delivered.



https://yadi.sk/d/PvOS5FbM3H96Wz
https://yadi.sk/i/UgFjnPTv3H97zz

 
 

18 April 2017

housing of data packets in a HDLn Tx Frame

This recording is nothing special but rather a good example in order to study and verify the way the data packets are housed in an HDLn Tx frame and the mechanisms used to fill the unused room when the length of the outgoing datagram is less than the length of the Tx frame of the used HDLn version (n = 3,6,12,24 packets each of 233 bytes). Particularly, the recording concerns a 1889-byte lenght 'Citadel' encrypted datagram which is sent in one HDL12 PDU, ie using 233 x 12 = 2796 bytes: the protocol shall use the extra space of 907 bytes adding 0-value bytes and reinserting one or more data packets (Fig. 1).

Fig. 1
For what concerns the on-air signal (Fig. 2), the HDL12 PDU is trasmitted within a BW2 waveform across an already-established HF link (FLSU/BW5) and is folowed by three EOM PDUs (BW1) sent by the transmitter station meaning that entire datagram has been successfully delivered. The HDL12 PDU is acknownledged by an ACK PDU (BW1) transmitted by the receiver station. The logical link will be terminated by a couple of FLSU exchanged  between the two stations. The transmission was copied on 8327.0 KHz/USB.

Fig. 2
For a better understanding of the way HDL protocol arranges the extra 917 bytes, let's see how the HDL PDU and BW2 are formed (quoting Annex C to NATO STANAG-4538).
For each of the first data packet positions in HDL TxFrame buffer (12 positions in this case), if the data packet position is empty, construct a new outgoing data packet in this position:
1. Get the next data segment (the next 233 consecutive data bytes to be transmitted) from
TxDatagram buffer; place these in the payload field of the data packet. If fewer than 233 data bytes remain to be transmitted, place these bytes at the beginning of the payload field; fill the remainder of the field with zero bytes.
2. Construct a sequence number value and write this value into the packet’s Sequence Number field.
 3. If TxDatagram buffer is completely emptied of payload data before all packet positions in TxFrame buffer have been filled with new packets, fill the remaining packet positions with repetitions of packets already residing in other positions of TxFrame buffer. The HDL transmitter is at liberty to select packets from the current datagram to repeat as it pleases; the HDL receiver must inspect the sequence number of each packet received without errors, and use this information to discard duplicate packets
4. Send an HDL PDU containing the tx frame in TxFrame buffer, using BW2 waveform.

Fig. 3 - formation of the HDL12 Tx fame for this example
The 0-value bytes and the packet repetions are well visible in Fig. 1.

During the construction of BW2 waveform structure, a 32-bit Cyclic Redundancy Check (CRC) value is computed across the 1881 payload data bits in each data packet (1864 bits of user data, plus a 17-bit Sequence Number added by the protocol), and is then appended to the data packet. The seven encoder flush bits with values of zero (Flush) are then appended to produce an Extended Data packet of 1920 bit length that will be used for FEC, frame formation, symbol formation, and so on. 

From theory to practice, the way the data packets are housed in TxFrame buffer can be verified by inspecting the  Sequence Number fields in the last 56 bits of the first nine BW2 extended data packets of the copied transmission (Fig. 4).

Fig. 4 - the last 56 bits (Sequence Number + CRC + Flush) of the copied BW2 Extended Packets
As expected, EOM and SOM fields (bits 16,15) show that the positions 0 and 9 of the TxFrame buffer are both filled with the first packet of the datagram, while position 8 of the TxFrame buffer is filled with the last packet of the datagram. Consequently, the Packet Number (bits 5-0) starts from 0 to 8: ie, the useful payload consists of 9 packets (note also that positions 0 and 9 have the same Packet Number).
Consider now the Packet Byte Count (bits 14-6):
this field show the number of user bytes in packet –1. The first eight packets, positions 0-7, contain 233 bytes (011101000 = 232) and the last packet, in position 8, contains 35 bytes (000100010 = 34). The outgoing datagram was then (8 x 233) + 35 = 1899 bytes length.

One could say "since the datagram length is 1899 bytes and fills 9 data packets, why don't use 1 HDL6 PDU + 1 HDL3 PDU?". It would be impossible.
During the link setup phase, the session manager process determines the number of data packets per HDL PDU (3, 6, 12, or 24) shortening the HDL PDU whenever the entire datagram is short enough to fit within the shortened PDU. Once it is determined, the number of data packets per HDL PDU for the current datagram delivery remains unchanged, ie every HDL PDU contains the same number of data packets until the entire datagram has been delivered (so: 3 x HDL3 PDUs, or 2 x HDL6 PDUs, or just 1 HDL12 PDU... btw more PDUs means the more turnaround time).



https://yadi.sk/d/wcvQBJfr3H75uc
https://yadi.sk/i/j0nqeWiC3H75x9 

15 April 2017

an LDL160 transfer with nine retransmissions


this is a copy of an 10 x LDL160 transfer, heard on 8327.0KHz/USB, with up to nine retransmissions of the same 'Citadel' encrypted  data packet (Fig. 1). Since the LDL forwards are followed by ACKs from the receiver station, although they are faintly visible, the nine retransmissions could be due to repeat requests.

Fig. 1
The analysis of the last 64 bits of each BW3 bursts shows a fixed structure in the Sequence Number field: if the reps had been in the datagram passed to the LDL protocol then the sequence number would have been incremented, moreover the EOM and SOM fileds (bits 16,15) are both to 1 in all the packets meaning that this is the only packet in the sent datagram  (Fig. 2)
Fig. 2
As said, since the ARQ ACK mechanism of xDL protocols, it could be that the nine retransmissions are requested by the receiver (bad channel conditions at receiver side?) but it could also be a technique to improve the reliability of the transmission: transmitting the same information more than once (each time encoded using alternate FEC codes) during a particular link increase the probability that user data will be received correctly.






10 April 2017

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



8 April 2017

recent Logs


05838.0: ABC7: Croatian Military, HRV 0734 USB USB MIL 188-141 2G-ALE followed by voice radio-check w/ ABF2 ABS5 ABH3 ABK4 (28Mar17) (AAI)
06250.0: ---: Unid (prob. Turkish Mil, TUR) 0713 (cf) FSK 600Bd/840, KG-84C vectors w/out sync (28Mar17) (AAI)
06758.7: ---: Unid (cf) NATO 75Bd/850 RATT, KG-84 encrypted messages (07Apr17) (AAI)
06831.0: D20: HPRD-net Dubrovnik, HRV 0729 USB MIL 188-141 2G-ALE sounding (07Apr17) (AAI)
07401.0: ZRUE: Zollboot Ruegen, D 0739 USB MIL 188-141 2G-ALE calling ZLST (05Apr17) (AAI)
07467.0: SL2: Slovakian Mil, SVK 0639 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to MC1 (07Apr17) (AAI)
07468.0: 01: Unid 1343 USB/J3E Thales skymaster ALE followed by voice call to 085, no reply (03Apr17) (AAI)
07527.0: OWK: OWK: USCGC Dependable (WMEC 626) US 0553 USB MIL 188-141 2G-ALE sounding (07Apr17) (AAI)
07560.0: Z19: Unid 0628 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to Z21 (07Apr17) (AAI)
07630.0: ESH: Algerian Air Force (Ecole de Specialisation sur Helicopters), ALG 0802 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to CM5 (04Apr17) (AAI)
07649.0: ---: Unid 1913 USB 3G-HF 2-way FLSU handshake followed by LDL32 transfer, Harris Citadel encryption (04Apr17) (AAI)
07660.0: ---: Unid 0858 USB 3G-HF 1-way FLSU followed by MDL protocol using LDL128 (BW3 waveform) (20Mar17)(AAI)
07692.0: 6DP: Moroccan Gendarmerie, MRC 1936 USB MIL 188-141 2G-ALE handshake 5YZ followed by MIL 188-110A serial (04Apr17) (AAI)
07692.0: 6DP: Moroccan Gendarmerie, MRC 1939 USB MIL 188-141 2G-ALE handshake Q7E followed by MIL 188-110A serial (04Apr17) (AAI)
07699.0: ---: Unid 1957 USB 3G-HF 2-way FLSU handshake followed by LDL32 transfer, Harris Citadel encryption (04Apr17) (AAI)
07700.0: ---: Unid 0557 USB 3G-HF 2-way FLSU handshake followed by HDL+ transfer (07Apr17) (AAI)
07762.5: 6007: Unid 1929 USB MIL 188-141 2G-ALE sounding (04Apr17) (AAI)
07762.5: 6010: Unid 1949 USB MIL 188-141 2G-ALE sounding (04Apr17) (AAI)
07770.0: D15: Ukrainian Net, UKR 1859 USB MIL 188-141 2G-ALE 2-way LQA exchange w/ D17 (30Mar17) (AAI)
07803.0: ---: Unid (prob. French Forces Calvi, F) (cf) 0750 ARQ-E, FSK-2 184.6Bd/400, no traffic (27Mar17) (AAI)
07840.0: SWT: Unid 0716 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to SDL (04Apr17) (AAI)
07870.0: 21202: Unid (Turkish Civil Defense?) 1856 USB MIL 188-141 2G-ALE sounding (04Apr17) (AAI)
07892.0: 8411: Turkish Civil Defense Kocaeli, TUR 2110 USB MIL 188-141 2G-ALE sounding (28Mar17) (AAI)
07930.0: ---: Unid 0729 USB 3G-HF 2-way FLSU handshake followed by HDL6 transfer (04Apr17) (AAI)
07935.6: ---: Unid 0749 (cf) (04Apr17) Siemens CHX-200 modem selcall(04Apr17) (AAI)
07944.0: ---: Unid 1859 USB 3G-HF 2-way FLSU handshake followed by LDL32 transfer, Harris Citadel encryption (04Apr17) (AAI)
07945.0: ANOUAL2: Moroccan Military, MRC 0721 USB MIL 188-141 2G-ALE sounding (04Apr17) (AAI)
07956.0: ABC7: Croatian Military, HRV 0938 USB MIL 188-141 2G-ALE calling ABF2 (23Mar17) (AAI)
07961.0: AAA: Israeli Air Force, ISR 0612 MIL 188-141 2G-ALE handshake B28 followed by voice comms (07Apr17) (AAI)
07970.0: 820699: presumed Kyrgyz net, KGZ 1945 MIL 188-141 2G-ALE calling 820xxx (incomplete call) (04Apr17) (AAI)
08005.0: 920001: Unid 2103 USB MIL 188-141 2G-ALE handshake 920004 followed by series of 500Hz beeps (28Mar17) (AAI)
08005.0: 920007: Unid 1933 USB MIL 188-141 2G-ALE sounding (04Apr17) (AAI)
08005.0: 920007: Unid 2103 USB MIL 188-141 2G-ALE calling 920001 (28Mar17) (AAI)
08055.0: 1001: Unid 2031 USB MIL 188-141 2G-ALE calling 1004, followed by Codan ChirpCall 1047571 to 1047574 (28Mar17) (AAI)
08056.5: 106001: Turkish Civil Defense, TUR 2044 USB MIL 188-141 2G-ALE sounding (28Mar17) (AAI)
08090.0: 2159: Unid 1628 USB MIL 188-141 2G-ALE handshake 2167 followed by voice comms in French (31Mar17) (AAI)
08138.0: YDM: Unid 1028 USB MIL 188-141 2G-ALE LQA Report to UDR (24Mar17) (AAI)
08151.0: TYMT2: Spanish Police Toledo, E 0948 USB MIL 188-141 2G-ALE sounding (26Mar17) (AAI)
08162.0: BX01: Algerian Military, ALG 0922 USB MIL 188-141 2G-ALE handshake 123 (07Apr17) (AAI)
08162.0: JP02: Algerian Military, ALG 1017 USB MIL 188-141 2G-ALE LQA Report to PY01 (23Mar17) (AAI)
08178.5: KA2: Polish Military 1138 USB MIL 188-141 2G-ALE handshake MI2 followed by vy weak voice comms (06Apr17) (AAI)
08182.0: XDH: UK-DHFCS station, G 1021 USB MIL 188-141 2G-ALE LQA Report to XSS (23Mar17) (AAI)
08194.0: 280: Chinese Military, CHN 1843 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to 284 (04Apr17) (AAI)
08218.0: ---: Unid 0837 USB 3G-HF 2-way FSLU handshake followed by HDL traffic (23Mar17) (AAI)
08308.7: ---: Unid 0855 USB STANAG-4285 600bps/L KG-84 encrypted messages (25Mar17) (AAI)
08327.0: ---: Unid 2024 USB 3G-HF 2-way FLSU handshake followed by LDL480 transfer, Harris Citadel encryption (04Apr17) (AAI)
08488.0: ---: Unid 0810 USB 3G-HF 2-way FLSU handshake followed by LDL traffic (25Mar17) (AAI)
08850.0: R26577: US Army Helo 94-26577 1013 USB MIL 188-141 2G-ALE sounding (25Mar17) (AAI)
08992.0: ---: Andrews AFB, US 1002 J3E/USB test count (24Mar17) (AAI)
09175.0: ---: Unid 1354 USB 3G-HF 2-way FSLU handshake followed by bidirectional HDL+/LDL traffic (22Mar17) (AAI)
09220.0: GZS: Polish Military, POL 1254 USB MIL 188-141 2G-ALE LQA Report to 12B (25Mar17) (AAI)
09476.0: ---: Unid 1241 (cf) FSK-2 50Bd/500 ACF: 15-bit preamble and 45-bit data, groups of 5 figs (22Mar17) (AAI)
10132.0: ---: Unid 0919 USB 3G-HF 2-way FLSU handshake followed by HDL+ transfer (05Apr17) (AAI)
10150.0: 1RS: Polish Military, POL 1154 USB MIL 188-141 2G-ALE LQA Report to PWB (25Mar17) (AAI)
10150.0: PWB: Polish Military, POL 1155 USB MIL 188-141 2G-ALE LQA Report to GRP (25Mar17) (AAI)
10222.0: ---: Unid 1022 USB Hagelin HC-256 voice scrambler (05Apr17) (AAI)
10225.8: ---: Unid (prob. Finnish Military) 1145 USB Nokia Adaptive MSG-Terminal, FSK 401Bd/301Bd 780Hz shift (28Mar17) (AAI)
10280.0: 1536: Unid 0659 USB MIL 188-141 2G-ALE LQA Report to 8536 (31Mar17) (AAI)
10345.0: JCU: Saudi Air Force, ARS 1423 USB MIL 188-141 2G-ALE calling RFU (25Mar17) (AAI)
10425.0: JAI: Saudi Air Force, ARS 0842 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to BPR (07Apr17) (AAI)
10425.0: JAI: Saudi Air Force, ARS 0846 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to BPN (07Apr17) (AAI)
10539.6: ---: Unid 0826 (cf) (04Apr17) Siemens CHX-200 modem selcall (04Apr17) (AAI)
10627.0: ---: Unid 0931 3G-HF 2-way FLSU handshake followed by HDL6 transfer (04Apr17) (AAI)
10627.0: ---: Unid 1011 USB 3G-HF 2-way FLSU handshake followed by HDL6 transfer (05Apr17) (AAI)
10627.0: ---: Unid 1122 USB 3G-HF 2-way FSLU handshake followed by HDL traffic (28Mar17) (AAI)
11010.0: ---: Unid 0746 USB Arcotel MAHRS-2400 serial modem (05Apr17) (AAI)
11050.0: ST3: presumed Egyptian net, EGY 1331 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to SHARK3 (05Apr17) (AAI)
11168.6: KWT94: Unid US DoS station 1322 USB MIL 188-141 2G-ALE sounding (05Apr17) (AAI)
11186.0: ---: Unid 1307 USB 3G-HF 2-way FSLU handshake followed by HDL traffic (28Mar17) (AAI)
11347.0: 9GQK: Ghana Navy, GHA 0904 USB MIL 188-141 2G-ALE sounding (24Mar17) (AAI)
11820.0: AAC: Unid (Israeli Air Force ?) 0746 USB MIL 188-141 2G-ALE calling AAA (05Apr17) (AAI)
14426.8: ---: Russian Diplo/Intel 1235 (cf) mixed mode 5 x MFSK-16 10Bd/20Hz, BPSK 250Bd insertions each 10 secs (04Apr17) (AAI)
16350.6: ---: Russian Diplo/Intel 1215 (cf) mixed mode 5 x MFSK-16 10Bd/20Hz, BPSK 250Bd insertions each 10 secs (06Apr17) (AAI)
18292.8: ---: Russian Diplo/Intel 1140 (cf) mixed mode 5 x MFSK-16 10Bd/20Hz, BPSK 250Bd insertions each 10 secs (04Apr17) (AAI)
18475.0: 1BGQY: Unid US net 1603 SB MIL 188-141 2G-ALE calling 57YMD (30Mar17) (AAI)
18475.0: 5M81G: Unid US net 1624 SB MIL 188-141 2G-ALE calling 5GZ7D (30Mar17) (AAI)
18475.0: 5QMG8: Unid US net 1402 SB MIL 188-141 2G-ALE calling BM57G (30Mar17) (AAI)
18475.0: 5QMG8: Unid US net 1520 SB MIL 188-141 2G-ALE calling 5GZ7D (30Mar17) (AAI)


2 April 2017

xDL PDUs, BW2 & BW3 waveforms, and Harris 'Citadel' encryption

I spent some time to understand where and when the 'Citadel' encryption is applied to a message in the STANAG-4538 xDL implementation by Harris, eg in the RF-5800H transceiver, regardless of whether the message came from STANAG-4406 P-MUL or HMTP/CFTP and at least (!) in my copies.
HDL and LDL protocols exist in different variants, and a number n (eg xDLn) specifies the size of one forward transmission. For HDL the number n (24, 12, 6, or 3) should be multiplied by 233 bytes plus a 17-bit sequence number added by the protocol to give the total number of bytes in one forward Tx frame.  If the data segment is of length less than 233 bytes,  a sequence of null data bytes (of value zero) is appended to the data segment so as to extend it to length 233 in constructing the data packet.
In case the datagram is emptied and not all data packet positions have been filled with new packets, the remaining data packet positions are filled with repetitions of packets already residing in other positions. The HDL transmitter is at liberty to select packets from the current datagram to repeat as it pleases; the HDL receiver must inspect the sequence number of each packet received without errors, and use this information to discard duplicate packets.  Note: Whenever a packet is retransmitted, it is always placed in the same packet position within the Tx frame that it occupied in the previous transmission.
Fig. 1 shows the formation of two HDL3 forward transmissions.

Fig. 1 (not in scale)
For LDL, the number n (32, 64, 96,…,512) gives the number of bytes explicitly in a tx frame plus 25 bits due to LDL overhead, ie 17-bit sequence number plus 8-bit data reserved for future use. As for HDL, the tx frame length of the LDL protocol has discrete values, so that a data segment will be padded with 0 value bits if ist length is less than the packet length established for the current LDL transfer (32, 64, 96,…,512). Fig. 2 shows the formation of two LDL512 forward transmissions.

Fig. 2 (not in scale)

Now assume that a STANAG-4406 message shall be encrypted and transferred. P-MUL protocol segments a message into UDP/IP packets with a maximum length of the IP packet of 1500 bytes. If the length of the message to be transferred is 15 kbytes, a total of 11 IP consecutive packets are required for the message transfer. Consider now how the STANAG-4538 protocols operate when transferring one IP packet. At the arrival of the first IP packet at the sender station, a link to the destination node is set up by FLSU PDUs. Then, a 1500 byte datagram containing the first IP packet is transferred for example by using two HDL6 Data PDUs or three LDL512 Data PDUs, each related to one segment of the datagram and followed by an ACK in the reverse direction. 

The Citadel engine works on each datagram before to construct the xDL PDU, in case of the incoming datagram matches the length established for the current xDL transfer then the encryption could be seen as directly applied to the xDL PDU. Since the encryption adds overhead bits, the length of the datagram segments is chosen accordingly.

encryption in a HDL formation

The insertion of the encryption is more clear looking at xDL bitstreams from the real world. An HDL12 transfer is shown in Fig. 3: the presence of the Citadel "business card" is well visible just at the beginning of the PDU (Fig. 5).

Fig.3 - Citadel encrypted 1 x HDL12 transfer
Fig.4 - Citadel encrypted 1 x HDL12 transfer
An LDL32 transfer is shown in Figs. 5,6 : the presence of the Citadel pattern is well visible just in the first packet of the datagram.
 
Fig. 5 - Citadel encrypted 2 x LDL32 transfer

Fig. 6 - Citadel encrypted 2 x LDL32 transfer
Looking at Fig.2, the correspondence 1 LDL PDU = 1 data packet could wrongly lead to think to an encryption applied on data packet basis: the encryption insertion is more clear looking at HDLn, where 1 HDLn PDU = n data packets (Figs. 3,4).

Now look carefully at Fig. 5: each packet is indicated with its index followed by the dimension of the data segment, 32 bytes in this case (LDL32). That said, why five 8-byte rows, ie 40 bytes, are printed ? The same incongruity is verifiable in HDL packets: 240 bytes printed instead of the expected 233 (fig. 7)
 
Fig.7
LDL use burst waveform BW3 to transmit its PDUs. The number of payload bits is of the form 8n+25, where n = 32, 64, 96,..., 512 and the additional 25 bits are the overhead consisting of 17 bits of the sequence number + 8 bits for future use. A 32-bit Cyclic Redundancy Check (CRC) value is computed across the payload data bits in the data packet, and is then appended to the data packet. Then, 7 flush bits having the value 0 are appended to the (8n+57) bits of the data packet with CRC. In the example of Fig. 7 (LDL32) we obtain (8 x 32) + 57 + 7 = 320 bits that make the 40 bytes.

For what concerns HDL PDUs, these are transmitted by BW2 burst waveform. Each data packet is composed of a 1864 bits data-segment (233 bytes) + 17 bits of the sequence number. A 32-bit CRC value is computed across the 1881 payload data bits in each data packet, and is appended to the data packet. Then, seven encoder flush bits with values of zero are appended to the 1913 payload and CRC bits of each data packet to produce an Extended Data Packet (EDataPkt) of 1920 bits or just 240 bytes.

Juts another way to say that HDL is not BW2, and LDL is not BW3: xDL are protocols while BWn are waveforms.

For what concerns MDL protocol, it seems that the Citadel encryption is applied on the incoming datagram before its segmentation (Fig. 8).


Fig.8 -  MDL transfer using 3 x LDL32
Behavior of STANAG-4538 depends on vendor implementation as well as on its configurable parameters, so this post does not aim to show a sort of  fixed rule but just some cases of  transmissions that happened to hear.