Baudot FSK 50Bd/500 (unid Rus Gov/Mil)

Some day ago, me and my friend KarapuZ were talking about some asynchronous 500 Hz shift FSK-2 signals and the way to get a meaningful decoding from the demodulator of SA. The first step is the removal of the START/STOP bits according to the size of the data field  (ie 5, 6, 7 or 8 bits) and then try different alphabet codes in turn, until you find one that produces an output that makes a sense. 

The analyzed signals have a shift of 500 Hz, a manipulation speed of 50 Baud and a 5-bit size data field. 

Once removed the START/STOP bits, we tried the 5-38 code (1 start bit, 1.5 stop bits, the good old Baudot), as KarapuZ advised, and we got groups of 5 LTs (or 5 FGs ?). The used procedure, and the results, are shown below.

Fig.1

Fig.2

Groups of 5 LTs is a "format" that is frequently used by several Military and Governative Agencies so in the absence of other evidence it's a bit difficult to identify the source, although there are good chances in favour of  CIS/Russian users.

https://yadi.sk/d/fcGKlSq_3GV8HT

STANAG-4538, HDL+ and LDL protocols swapping in a bidirectional link

This is a very interesting 3G-HF on-air scenario where as many as 5 burst waveforms and 2 datalink protocols are used, moreover, thanks to the different strength of the signals, it's also possible to notice the swap of the data-flow directions.
In the first part, after the 2-way Fast link setup PDUs exchange, data flows from PU1 to PU2 using HDL+ protocol. Immediately after the HDL+ transfer is complete, ie after the three HDL+ ACK PDUs (BW6) sent by PU1, both stations remain linked and initiate the Fast Traffic Management (FTM) protocol to negotiate further traffic. This gives PU2, which was the called station, the opportunity to send reverse traffic to PU1 (which was the caller) so data now flow from PU2 to Pu1.

After the LDL transfer is complete, ie after the ACK PDU (BW4) sent by PU2, stations wait for possible FTM PDUs and after the link timeout has occurred, the last station to receive an xDL transfer (PU1 in this case) terminates the link with an FLSU_Term PDU request.

Fig. 2

It's important to notice the use of the BW6 waveform for FLSU and FTM protocols PDUs (marked with an "*" in Figure 2) which are usually conveyed using the BW5 waveform. Indeed, as stated in STANAG 4538 Annex-C Edition1 Amendment2, if a link has been established for delivery of packet traffic using the HDL+ data link protocol, all FTM and FLSU PDUs transmitted for the remaining duration of the packet link shall be transmitted using the BW6 burst waveform, up to and including the FLSU_TERM PDU transmitted to terminate the link, and any optional response to the FLSU_TERM.
This means that BW6, other than BW7 header, ACK, and EOT (EOM) PDUs of the HDL+ protocol, is also used to convey PDUs of the fast link setup (FLSU) and fast traffic management (FTM) protocols in HDL+ links. It's worth noting that altough the link is subsequently used for LDL, it was initialized for HDL+ protocol.

Transmission was copied on 9175.0 KHz/USB at 1454 UTC (March, 22): MIL 188-110B traffic from Algerian Army was logged on this QRG, are we facing the same user? 
For what concerns the nature of the exchanged data, we can only state that LDL is used by PU2 to send an HARRIS Citadel encryped message to PU1 (Fig.3): probably the end-to-end acknowledgment mechanism which is part of P-MUL protocol; this is and end-to-end ACK at application layer and it's related to the delivery of the message (not the ACKs issued in xDL link protocols). The use of Citadel encryption is a clue in favor of HARRIS sw/hw equipments, e.g. Falcon II RF-5800H radios.

Difficult to say what sits on top of S-4538: it could be an email messaging system (eg HARRIS WMT RF-6710) as well as a  STANAG-4406 application (Thales XOmail): the presence of the reverse message from PU2 to PU1 leads to think to the latter, since WMT does not provide delivery confirmations. I will discuss this topic in further posts.

Fig. 3

https://yadi.sk/d/0ju0lxSE3GFc37

a STANAG-5066 HF MailServer at work

this is a good example of a STANAG-5066 based HF Mail Server (an MTA, Mail Tranfer Agent) at work: the HF Mail Server receives one email transmitted by a wireless client (over-the-air path) which is addressed to multiple non-HF recipients, and then it takes care of each single delivery by forwarding each message through an infrastructured TCP/IP path and returns back the email transmitted notifications to the sender (Fig. 1). Just the copy of the over-the-air "notifications" allowed to retrace the scenario.

The transmission concerns HF mail tests from a Turkish HF newtork, most likely belonging to the Coast Guard, and was (accidentally!) copied by KarapuZ. The HF Mail Server sits in the middle and acts as default MTA for the turkhfmail.com domain, so it's  "transparent" to the users. Both the sender and the Mail Server are in the same STANAG-5066 HF network: respectively, 1.0.0.3 and 1.0.0.1 (S-5066 Addresses).

Fig. 1

The used HF waveform is STANAG-4285 with ARQ extension provided by upper STANAG-5066 data link protocol (Fig. 2), the channel is used in half-duplex mode.

Fig. 2

The transmission, as said, convey test emails in clear-text, so these are not critical/secure messages, however only the domain names are visible while the account names are obscured. As I mentioned several times, I'm only interested on the way the "boxes" travel on-the air and not in their contents.

Figure 3 shows the transmission of the email from a certain <user>@turkhfmail.com (the sender at gw-HF-mail) to some recipients belonging to different not-HF email domains. Notice that the Adobe license is the content used as test message (so nothing important, just a text).

Fig. 3

the HF mail server reports the emails status to the original sender by transmitting a single notification for each addressed recipient: in this case the sender is the HF mail server.

I wanted to illustrate more clearly two of those test notifications in order to understand the involved users and their role. Figure 4 shows the status notification of the email which is addressed to Directorate General of Coastal Safety, Figure 5 show the status of an email addressed to Selex ES headquarter in Turkey

Fig. 4

Fig. 5

The Turkish Directorate General of Coastal Safety is the client and the Italian Selex-ES is the solution vendor: it's quite obvious that these are the recipients since they are the most interested on the results of the tests. 

Some other informations can be acquired from the headers. 
1) The used protocol is CFTP (Compressed File Transport Protocol). CFTP is used to reliably send compressed SMTP e-mail over a STANAG-5066 HF subnetwork from one SMTP mail server to another. In operation, when an email message is received at a 5066 node, it is placed in an incoming mail folder (mail spool directory). The CFTP client, also called the Delivery Agent (DA), removes mail from this incoming folder and processes the mail for delivery over HF via 5066. The CFTP DA compresses the message and information about the message, e.g. size, id, recipients, etc. into a file. This compressed file is then transferred to the destination HF 5066 node(s).
2) User-Agent at the sender node is Mozilla/5.0 rv:12.0 Thunderbird/12.0.1 on Windows NT 6.1
3) The email domain name is turkhfmail.com, usually mail servers use mail.<domain name> as their hostname so I tried to nslookup mail.turkhfmail.com and got 212.156.62.66 (relay7.selex-comms.com.tr); the mail server is owned by Turk telekom and hosted directly by Selex-ES (Fig. 6)

Fig. 6

The HF mail server, as an MTA, also delivers messages from senders outside the HF network to STANAG-5066 HF recipients as shown in Figure 7

Fig. 7

It's worth noting the match of the mail server public IP address.

Nokia M/90 (Panasonic CF-U1): FSK 301-401Bd 780Hz shift

This is an interesting copy of FSK-2 transmissions in dual 401 (401.5) and 301 Baud mode, both running with constant 780 Hz shift and heard on 10225.0 KHz/USB (offset = 1700 Hz) at 0605 UTC.  This waveform was originally used in Nokia Adaptive MSG-Terminal "Sanomalaite M/90" [1] used by all branches of Finnish Defence Forces but from 2013 onward,  these devices are being replaced with Panasonic CF-U1 Toughbook tablet computers [2].

Fig. 1

The three transmissions resemble a PtP ARQ system where the caller station use the 401Bd mode to send data and the called station use the 301 Bd mode for ACKs, also note that in the second transmission the 401Bd frame is sent without the preamble: maybe it is a segment which belongs to the first transmission. However, during that same recording the 401Bd mode has been used also as stand-alone (Fig. 2).

Fig. 2

Just the preamble is probably the "business card" of this waveform: talking with my friend KarapuZ about this device, he pointed the fact that the preamble it's always modulated at a speed of 301 Baud.  Indeed, at a first glance the speed seem to be constant in the two modes: 401 and 301 Baud (Fig. 3)

Fig. 3

but trying to demodulate the 401Bd signal it's possible notice some distorsions in the preamble which are not present when the stream is forced to 301 Baud (Fig. 4)

Fig. 4

These distorsions are not present in the case of the 301Bd signal (Fig. 5)

Fig. 5

In order to prove this characteristic, KarapuZ sent me a recording of the Nokia M/90 running at 151 (150.5) Bd and also in this case it's possibile notice that same behavior in the preamble (Figs. 6,7)

Fig. 6

Fig. 7

KarapuZ also suggested to demodulate the 151Bd signal using the differential decoding: after the removal of the synchronization bits (vertical solid columns in the 4-bit period stream) and inverting the polarity, a period of 8 bits with 1 stop bit is obtained.  (Fig. 8). Next, it's difficult to state how to process the information, as a rule, such terminals use off-line encryption. Since the removal of 2 bits of four, the data signaling rate is 150/2 = 75 bps.

Fig. 8

https://yadi.sk/d/htVJdKCj3G5aHc
https://yadi.sk/d/QP1c4nli3G5afh

---

[1] http://www.radioscanner.ru/forum/topic39959-51.html
[2] https://en.wikipedia.org/wiki/Sanomalaite_M/90

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

3G-ALE, Synchronous 2-way FLSU failure – packet traffic example

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.

Fig. 2

Fig. 3

https://yadi.sk/d/2uhRkPWn3FLp9V 

3G-ALE, 2-Way Link Quality Analysis (“LQA Exchange”) example

this is surely a post of few or zero significance, just to add another over-the-air scenario of those depicted in the NATO STANAG-4538 document.

The diagram in Fig. 1 shows the procedure by which a PU can exchange SNR information for all scanned channels in both directions with a second specified PU. This is accomplished by means of a 3-way FLSU PDU exchange on each of the scan channels. The LQA Exchange, as well as other 3G-HF activity, has been copied on 10132.0 KHz/USB (sunday morning, 1019 UTC) in the reserved WARC band of 30mt.  

Fig. 1

When a PU is given a request for an LQA Exchange with another PU, it sends a FLSU_Req PDU on the next scan channel on which it is able to. The FLSU_Req PDU includes the caller PU address and called PU address, and is of type REQUEST_2Way.

The called PU estimates the SNR of the received FLSU_Req PDU and reports the channel quality back to the caller PU by responding with an FLSU_Conf PDU on the same channel. The caller PU, on its turn, estimates the SNR of the FLSU_Conf PDU and reports it back to the called PDU through an FLSU_Term PDU that terminates the 3-way exchange.

  https://yadi.sk/d/3PSAdsPi3FEkYE

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