unid datalink protocol(s) over a PSK8 ST and STANAG-4539 (2)

I had the opportunity to record other transmissions on 3712.70 KHz/USB and - also following the comment of my friend KarapuZ - I can state with reasonable certainty that the waveforms analyzed in the previous post [1] come from Thales equipment. 
As mentioned, both Thales and L3Harris use the GMSK-MFSK8 waveform to handle HF links but the L3Harris bitmap/bitstream have a very recognizable pattern that is not present in the bursts recorded today (Figs 1,2): therefore, the GMSK-MFSK-8 signal is the Thales Systeme-3000 "Skymaster ALE", used in TRC-3500 and TRC-3600/TRC-3700 series radios (HF 3000 family).

Fig. 1 - Thales Systeme-3000 GMFKS+MFSK8

Fig. 2 - Thales Systeme-3000 GMFKS: bitstream after differential decoding and 50ms bitmap

As you see in Figure 2, I used the OQPSK "view" to demodulate the preamble of the Skyaster ALE signal: however, the differential decoding clearly show a 2-state keying (precisely GMFSK) that can be demodulated also using the "classic" FSK approach (Figure 3).

Fig. 3 - use of the SA MFSK dem

For what concerns the two PSK8 Serial Tone waveforms A & B [1], they also could be proprietary ones (Thales); indeed, quoting TRC-3600 datasheet: "Thanks to its digital advanced technology, the TRC 3600 offers new embedded services: secure high data rate and digital voice transmissions. It integrates a high data rate, multiwaveform, single tone modem (from 75 to 5400 bps) and a vocoder (800 - 2400 bps) associated to a high security digital COMSEC chip". 

The data link protocol could be the digital voice vocoder (new MELP/LPC10), given the similarity of the bitstream with its L3Harris analogue, but that is just an unconfirmed hypothesis of mine.

Fig. 4 - bitmaps of the two PSK8 ST waveforms

 

 https://disk.yandex.com/d/6NK6xYRAWzjzEw

 [1] http://i56578-swl.blogspot.com/2024/04/unid-datalink-protocols-over-psk8-st.html

unid datalink protocol(s) over a PSK8 ST and STANAG-4539 (Thales? L3Harris?)

A few days ago I came across some transmissions that caught my attention for at least three good reasons:
1. the frequency used, i.e. 7312.7 KHz/USB, within the 42 meter broadcast band;
2. the use of different traffic waveforms, ie PSK8 serial Tone and STANAG-4539, in ARQ and non-ARQ modes. The ARQ mode is easily recognizable by the difference between the frequencies of the subcarriers (around 50Hz) of data and ACK segments (1);  

Fig. 1 - different traffic waveforms

3. the use of a waveform composed of GMFSK-2000Bd + MFSK8 for the link setup procedure (Figure 2): as far as I know, this particular waveform is used by both Thales and Harris. Notice that the MFSK8 part is 188-141A compatible (125Bd & 250Hz separation between the 8 tones) but use a diferrent tone library.

Fig. 2 - GMFSK + MSK8 link setup waveform

I had already met such transmissions, noting how the system was able to simultaneously demodulate 2/3 waveforms (or more if we consider the ALE exchanges) even during the same logical link. In these recordings a single waveform (PSK8 ST or S-4539) is mostly used and I took advantage of this to study the characteristics of the used datalink protocol; a protocol which - in my opinion and according to my analysis - turns out to be proprietary and quite complex.

PSK8 Serial Tone
Figure 3 shows the 8-ary constellation (states and transitions) as well as the rasters of the two PSK8 modulated waveforms A and B. In the phase states, and especially looking at the transitions, one can easily notice the presence of a PSK2 modulation which is certainly used for the synchronization sequences visible in the bitmaps below. As usual, the resulting PSK2 symbols are then mapped and scrambled to appear, on-air, as a PSK8 costellation. Bot the the waveforms have an ACF of 106.6 ms that makes a 256 PSK8 symbols frame at the modulation rate of 2400Bd. However, although of the same length, two different framings are adopted, in particular the Type B waveform uses a framing similar in composition to that of STANAG-4285. 

 

Fig. 3 - constellation and bitmaps of the PSK8 Serial Tone waveform

It is important to note both in the bitmaps of Figure 3 and in the demodulated bistream of Figure 4 (related to the Type A waveform) the presence of "regular" and similar patterns, as well as the "invariance" of the symbols of the synchronization sequences. In my opinion such patterns and sequences could indicate the use of a uncoded mode and even no interleaving (or 1 frame length interleaver), furthermore the length of the scrambler should coincide with that of the frame (256 symbols) or at least it should be initialized at the beginning of each frame (2).

Fig. 4 - PSK8 ST type "A" waveform: demodulated bitstream

Examining the symbols of the synchronization sequences offers further food for thought. In Type A waveform, the use of PSK2 modulation is confirmed by the 2-state transitions in the sync sequence, the latter consisting of a pseudorandom sequence of 31 symbols that is repeated twice for a total of 62 symbols (Figure 5).

 

Fig. 5 - sync sequence symbols, PSK8 type "A" waveform

Two state-transitions are also visible in the sync sequence of Type B waveform (Figure 6). Given its similarity to the S-4285 framing, the synchronization sequence consists of 80 symbols and it too is a pseudorandom sequence of length 31, which is repeated periodically within the 80-symbol window (2 periods of length 31 plus the first 18 symbols of another period).

Fig. 6 - sync sequence symbols, PSK8 type "B" waveform

The most interesting thing, apart from the state values which may be due to both the scrambler and the the possible phase-offset errors of the SA PSK demodulator (3), is that both the two Types of waveforms use the same 31-symbol sync sequence: indeed, as can be seen in Figure 7, the 2-state transitions are the same. Perhaps the length of the sync sequence is used by the receiving modem to figure out which of the two waveforms is incoming, but it's just a my guess.

Fig. 7 - sync sequence symbols, PSK8 type "B" and "A" waveforms

Since the Type B waveform has the same framing as S-4285, an S-4285 decoder recognizes the Type B waveform samples (100% confidence) but since the synchronization sequences are different (see the 2-state transitions in Figure 8) it does not successfully engage any sub-modes.

 

Fig. 8 - comparison between sync sequences of PSK8 Type "B"  and STANAG-4285

STANAG-4539
As per STANAG-4539, both the QAM16 and PSK8 waveforms have the same 287-symbol framing (119.6ms ACF, 2400Bd) although the user data rate is different: 6400bps and 3200bps respectively for QAM16 and PSK8.

Fig. 9 - constellations and bitmaps of STANAG-4539 QAM16 and PSK8 waveforms

If in the case of PSK8 ST it was only possible to analyze the symbols after demodulation, in the case of STANAG-4539 it is possible to decode the signals and then analyze the composition of the upper layer datalink protocol(s).
Figure 10 shows a detail of a bitstream obtained after removing the S-4539 QAM16 overhead and consists of 96-byte (768 bits) Protocol Data Units (PDUs), each PDU consisting of 3 bytes header followed by 93 bytes of data:
1st byte: a ID/value field, in this sample: 0x09 (LSB first)
2nd byte: down-counter field (LSB first)
3rd byte: up-counter field (LSB first)
As one can see looking at the values of the two counters in Figure 10, the sample consists of 55 PDUs, numbered from 0 (00000000) to 54 (00110110).

Fig. 10 - headers and part fo bitstream after S-4539 QAM16 decoding

 

The same fields' structure can be found in the PDUs extracted from a sample of STANAG-4539 PSK8 (Figure 11). Since the half of the user data rate (3200bps Vs 6400bps), each PDU consists of 48 bytes: 3 bytes for the header fields followed by 45 bytes of data. It's interesting to see that a change in the first field (from 01001000 (36) to 00001000 (8)) occurs when the down-counter field restarts its value after reaching the 0: curiously, the up-counter does not "reset" but continues its counting.
It's worth noting that that patterns highlighted in the bitstream of Figure 4 (and the bitmaps of Figure 3) are most likely the two counter fields of Figure 11: if so, both tPSK8 ST and S-4539 traffic waveform transport the same datalink PDUs.

 

Fig. 11 - headers and part fo bitstream after S-4539 PSK8 decoding

 

Even more interesting. After removing the 3 bytes of the headers, I reshaped the stream into a 128 bit scheme (16 bytes), i.e. to the most probable value of its period, and I noticed the repetition of the string 0x3CF04F; so I synced the stream on this value (Figure 12), fixing a minimum length of 128 bits. The result highlights the presence of 45 PDUs of a "secondary" datalink protocol where each PDU has an header consisting of 4 bytes and a minimum length of 16 bytes (128 bits), the maximum is over 600 bytes (I was not able to establish it accurately):
bytes 1-3: a ID/value field, [001111001111000001001111] 0x3CF04 (LSB first)
4th byte: up-counter field (LSB first)

 

Fig. 12 - the emerging "secondary" datalink protocol PDUs

This may be a hasty statement, but it seems that the "secondary" datalink protocol PDUs > 16 bytes length are fragmented into small segments and then incapsulated into the 45/95 bytes payload of the "primary" datalink protocol PDUs. By the way, at least in these samples, the "secondary" PDUs have been found only in the primary PDUs which have the first byte of the hedaer equal to 0x48, maybe just a mere coincidence (Figure 13,14).

Fig. 13

Fig. 14

comments
Since the lack of clear-text callsigns it's impossible to id the user, we may speculate just some guess about the manufacturer of the used devices:

 

- as far as I know both Thales and L3Harris make use of the GMSK-MFSK8 waveform to manage HF links: unfortunately the GMFSK signals portions are too short to allow the analysis of the bitmaps (L3Harris GMFSK has a well recognizable pattern [1]);

L3Harris typical pattern in GMFSK-MFSK8 signals

- the patterns highlighted in Figures 3,4 are very similar to the ones visible in the demodulated bitmaps of PSK8 Voice Digital waveform (L3Harris VD mode) [2];

L3Harris VD mode bitstream

- from Harris RF-5800 datasheet "L3Harris VD mode also allows data to be sent...both data and voice are secured with Citadel encryption" [2]: well, I did not find the Citadel characteristic pattern within the decoded bitstream, even if they could be plain-text transmissions.

 

So: Thales? L3Harris? either of them? ...hints and comments are welcome.

(to be continued)

 

https://disk.yandex.com/d/tMk8PwVw1gu8dg 

 

(1)50Hz difference between 1800Hz sub-carriers

 

(2) FEC encoding and interleaving should provide time separation between contiguous values.

(3) SA is a signal analyzer and not a decoder, therefore its phase-plane demodulator does not sync  any particular protocol, as it happens for example in STANAG-4285 "suited" decoders. Working with phase keyed signals, the SA phane-plane demodulator produces right interpretations and views (number of phases, angles, modulation speed, carrier frequency,...) but it may return wrong demodulated streams due to the possible phase-offset errors.

 

[1] http://i56578-swl.blogspot.com/2015/06/harris-selective-call-msk-2000bd1000.html
[2] http://i56578-swl.blogspot.com/2021/11/harris-rf-5800-digital-voice-psk8.html

CIS MFSK-33 (here:15+∅+17), likely a "Serdolik" multimode waveform

Fig. 1 - "Serdolik" multimode waveform

The MFSK segments have the usual 40Bd and 40Hz (channels separation) values which are typical of the Serdolik waveforms family: a long-range radio system used by the Russian and CIS countries Diplomatic Service, possibly Serdolik V2. It's worth noting in Figure 2 - at least in this sample - that although the system provides a 33 channels grid, only 32 are the effective (used) ones: specifically, the first 15 lower channels plus the 17 higher ones (the 16th channel is not used).

Fig. 2 - MFSK segments

The FSK inserts too have usual Serdolik values, ie 40Bd/680Hz in this sample, and consist of short "01"s sequences (Figure 3).

Fig. 3 - FSK segments

This sample has been recorded on 20.8155 MHz/USB using a remote AirSpy server located in UK.

CIS MFSK-33 waveform is not the only one that does not always use all the available channels of the frequency grid: CIS MFSK-34 (aka Crowd-36) is another example in this regard (Figure 4).

Fig. 4 - frequency grid of some CIS MFSK-34 samples

https://disk.yandex.com/d/wgskeCZfRcz6Ow

3G-HF Fast Traffic Manager (FTM) at work

This sample provides an example of the use of 3G-HF (STANAG-4538) Fast Traffic Manager (FTM) protocol, which is sometimes referred to as simply FLSU (Fast Link SetUp). More precisely, FLSU is used to set up links, and it includes the traffic type that will be used immediately after the link set up is complete; FTM is used after the FLSU for cases in which the traffic type needs to be changed, or to negotiate channel access among linked stations.
As stated in S-4538 Annex-C Edition1 Amendment2, if a link has been established for delivery of packet traffic using the HDL+ data link protocol (BW7), all FTM and FLSU Protocol Data Units (PDUs) transmitted for the remaining duration of the packet link shall be transmitted using the BW6 burst waveform: thus, since the use of BW6, the link was initialized for HDL+ protocol. But, as you can see in Figure 1, at some point an FTM negotiation causes the change of the traffic type: from HDL+  (BW7 waveform) to LDL (BW3 waveform).

Fig. 1 - traffic type change

It's worth noting the use of BW4 waveform bursts after LDL data delivery, it's requested by the #4.6.5 Dual Demodulation condition: "Under no circumstances shall stations be required to simultaneously demodulate more than two waveforms. Any scenario requiring more than dual-demodulation is either an error in the specification or an error in interpretation" (1).

 
By the way, the BW3 burst transports a L3Harris "Citadel" encrypted message (Figure 2).

Fig. 3

https://disk.yandex.com/d/YCupV-cFBXOmqQ

(1) HDL+ states is missing in the Table 4.6.5-1: however, since BW6 burst waveform is used for Ack/EOM/Term messages, Master and Slave stations expect to receive a BW6 or a BW7 waveform.

(unid) synchronous transfer protocol over MS-110A & FED-1052 DLP

Durings the last few days I have monitored the frequency 7762.0 KHz/U and collected very interesting recordings of transmissions regarding a (possible) synchronous transfer protocol which sits at a higher layer than the datalink one. All transmissions use MS-110A as the HF waveform and most of them use FED-1052 App.B as Data Link Protocol (DLP)(1): Figure 1 is an example in this regard. Since the use of FED-1052 DLP, the HF waveform could likewise be FED-1052 serial (single-tone) given that the two waveforms are interoperable. Links are performed using 2G-ALE handshakes (MS-141A), logged callsigns are K01, k02, K03, K08, K13, and K14. 

Fig. 1

1. The demodulated bitstreams of the first four Tx segments ("A" in Figure 1) have a common 26-byte (10+16) length initial sequence which may be seen as consisting of the two Hex strings/sequences shown in Figure 2:

[16 16 16 16 16 16 16 16 16 16] [8E 5C 0B AA 97 30 56 E6 93 A2 B3 FB 6D 1A E2 01] 

Fig. 2 - initial Hex sequences

The two initial strings are followed by an apparently random 224-bit/28-byte sequence which is 3 times repeated: that sequence is unique for each Tx segment so that it could be an Initialization Vector (IV): the repetitions are indeed a good clue (Figure 3):

[54 6A 59 86 D8 0D 5E EE 94 AF B7 25 C1 DB 44 A8 BF 4B F9 DF AF F4 BF 1D 94 F9 6D 3F]

[FA D6 B4 C8 3D 50 BA 06 F1 E7 4C 22 02 A5 86 48 F9 6D AA 76 29 3C 0A E0 51 E8 61 FF] 

[58 FC 4A D4 09 C2 82 9B 75 93 16 2D 8A 11 B1 D3 8A DE F1 55 79 2E 52 E1 53 02 E2 B5]
[A7 55 A7 B1 8E E9 68 96 84 DF 57 FA AF A2 09 E9 EA DB D5 53 16 9F 20 E7 93 75 24 86]

Fig. 3 - 28 bytes sequences

The bitstreams end with a 20-byte string of 0x16, just the double of the length of the initial 0x16 sequence:

[16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16]

Fig. 3 - ending Hex sequences

Since these Tx segments are sent using the 2400bps/voice mode, the data blocks between the (presumed) IVs and and the ending sequences could consist of secure digital voice. The Shannon entropy value computed on data blocks (7.792888420337759) could suggest encrypted or compressed files. Just to be thorough, I thought about checking whether the repeated 28-bytes sequences were SHA-224 digests (64 rounds, by default) of the following data blocks, but the results did not confirm this hypothesis.

2. The bitstreams resulting after demodulating the other 12 Tx segments ("B" in Figure 1) are recognized as FED-1052 App. B "DLP Data Link Protocol" frames (also known as HF Data Link Protocol, HFDLP). Quoting FED-1052 standard #50.1.1.1 Frame sync pattern:  Each new transmission over the physical channel shall begin with a three byte (24-bit) frame synchronization pattern to identify the following traffic as DLP processed traffic. The frame synchronization sequence in hexadecimal format, shall be "5C5C5C". The sync pattern shall be transmitted such that the first eight bits in order of transmission are "00111010" (see Figure 4).

Fig. 4 - FED-1052 DLP sync patterns

Looking at the Source and Destination Address fields (2) in the hexdumps of Figure 5, it's possible to see the exchanges of DLP frames between the addresses 03 (0x3330, ASCII 30) and 01 (0x3130, ASCII 10): forward and reverse directions are due to the ARQ feature of DLP protocol. Notice that the DLP addresses 01 and 03 match the ALE callsigns K01 and K03 used during the link setup process (Figure 5).

Fig. 5 - DEF-1052 DLP frames exchanges

More precisely, each DLP transfer consists of 3 frames (Figure 6):  the first is a data frame (bytes block delimited by 0x16) while the 2nd and 3th are control frames.

Fig. 6

DLP data frames consist of 56-bytes "packages", thus the re-assembly process produces files that have lengths in multiples of 56 (112, 168, 224, ...). By the way, packages are the result of a "fragmentation" of messages received from the user (or from a higher-layer protocol).

The small files resulting after the re-assembly process (and the removal of FED-1052 DLP overhead) are not in clear-text... and here things get interesting. 

The files start with a common 18-byte (10+8) sequence which may be seen as consisting of two Hex strings:

[16 16 16 16 16 16 16 16 16 16] [DF 73 0D 1D 5B 22 53 81]

and term with the 20 bytes Hex sequence:

[16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16] 

Also in this case, the ending 0x16 sequence is the double of the length of the initial 0x16 sequence (Figure 7):

Fig. 7

The 0 value bytes are padding bytes added to the last package to obtain the 56-byte size: it can easily be verified for each packet by subtracting the "data" bytes from the "received" ones. Quoting FED-1052 standard #50.4.3.1.2: All data frames shall be of the same size [...] this implies that the last data frame of a message may need to be padded with fill bits. The receive terminal will use the transmit message size information to determine where the message is to be truncated in order to remove the fill bits from its output data stream. The 16-bit graphic rapresentations are shown in Figure 8.

Fig. 8

 

Data consist of a few bytes, I do not think they are compatible with digital voice or "informal messages", maybe they are numerical data even if some format does not emerge.

3. I know that 0x16 is the <SYN> "Synchronous Idle" (TC9) ASCII control character. It is used in synchronous transmission systems to provide a signal from which synchronous correction may be achieved between data terminal equipments, particularly when no other character is being transmitted. The SYNC char was also used in syncrhonous modems at start and end of info blocks. So, the initial sequences of SYNC make me think of a kind of "synchronous transfer protocol" sitting at higher-layer.
Moreover, from the bitstreams analysis, it seems to me that the protocol is used to send different type of data and in different modalities: some types of data (Tx segments "A" in Figure 1) are forwarded directly to the MS-110A/FS-1052 modem, other types of data (Tx segments "B" in Figure 1) are first managed by FED-1052 DLP and then forwarded to the MS-110A/FS-1052 modem. Maybe the two initial strings announce the type of the following data blocks, but it's only a my guess.

By the way, the long durations of the 2G-ALE scanning call provide some indications about the number of the available channels: assuming full compatibility(!) with MS-141, the collected scan lists should be >= 20 channels (3). User should be Dutch MIL... but it's not confirmed.

Fig. 9 - 2G-ALE MS-141 scan call

 

https://disk.yandex.com/d/CrXu2QY4-AP9vQ 

(1) The HFDLP is a selective repeat ARQ protocol with the ability to adaptively vary several parameters in response to changing channel conditions. A transmission usually consists of a data series, containing several data frames, or a single control frame. Every frame contains a CRC. Before data transfer commences, HFDLP terminals exchange control frames to negotiate the number of data bytes per data frame (56 to 1023), the number of data frames per data series (1 to 255), and a few other characteristics of the data transfer procedure.

(2) As per FED-1052 standard, Source Address and Destination Address fields are restricted to two bytes each, LSB first. 

(3) 188-141 A.5.5.3.1 "If the called station (JOE) is known to be listening on the chosen channel (not scanning), the calling station (SAM) shall transmit a single-channel call that contains only a leading call and a conclusion (see upper frame in figure A-29). Otherwise, it (SAM) shall send a longer calling cycle that precedes the leading call with a scanning call of sufficient length to capture the called station’s receiver as it scans (lower frame in figure A-29). The duration of this scanning call shall be 784ms for each channel that the called station is scanning.

KW-46 secured fleet broadcast over S-4285 in ISB mode (Humpty Doo, MHFCS)

Interesting fleet broadcast from the MHFCS (Modernised High Frequency Communications System) site in Humpty Doo, Northern Territory - Australia. The transmissions use STANAG-4285 600bps/L in ISB mode and are audible on 11145.0 KHz (Figure 1).

Fig. 1

Bitstream of the LSB channel (Figure 2) is a "classic" broadcast which is encrypted using KW-46 (or compatible) cipher device given the presence of the m-sequence generated by the polinomyal x^31 + x^3 +1 (KW-46T uses that M-sequences to synch the KW-46R receive devices).

Fig. 2 - bitstream of the LSB channel

The bitstream of the USB channel is more interesting since it consists of 12-bit strings where all the bits have the same logical value, likely originated by the GA-205 12-channel time division multiplexer: I already met such signal some years ago [1] but that time from the "Naval Communication Station Harold E. Holt" (NCS HEH) 6 km north of Exmouth. USB channel too transports a KW-46 secured traffic: as shown in Figure 3, I filtered out 11 channels and reshaped a single "column" into a 7-bit pattern then I successfully checked the presence of the x^31 + x^3 +1 m-sequence.

Fig. 3 - bitstream of the USB channel

As said, in this case the transmission is source by a Tx located in Humpty Doo, Northern Territory Australia.

Fig. 4 - DirectionFinding results (TDoA algorithm)

 

https://disk.yandex.com/d/cd6YKgpc18NPrw

[1] http://i56578-swl.blogspot.com/2019/05/kw-46kiv-7m-secured-fleet-broadcast.html

MIL 188-220 App.D (Combat Net Radio) compliant transmissions in HF band

MIL-STD 188-220 suite (here indicated as MS-220D) was developed to meet the requirements for mobile Combat Net Radios (CNR) such as SINCGARS (Single Ground and Airborne Radio System) or more recent JTRS (Joint Tactical Radio System). The radios can handle voice and data communication, both secure and non-secure. SINCGARS radios work in the lower VHF band (30 to 88 MHz), with 25 kHz channel spacing and can operate on a single channel as well as in Frequency Hopping mode (FH). It's therefore rather rare to find transmissions in HF that use this protocol suite, especially in the low HF band (7 MHz)... but it may happen. Indeed, I was lucky enough to catch such transmissions on the same day (1030Z and 1058Z) on 7510 KHz/U (and it's not the first time it occurs).
The transmissions under consideration (Figure 1) are in STANAG-4538 "circuit service" mode, where link setup is performed by FLSU request/confirm exchanges (BW5 bursts) and MIL-STD 188-110A is the used traffic waveform.

Fig. 1 - STANAG-4538 Circuit Service mode

Appendix D of of MIL-STD-188-220 regards Communications Security Standards (COMSEC) and describes the requirements of the transmission frame structure when link encryption is provided by "external COMSEC" (traditional COMSEC) or by "embedded COMSEC" devices. The demodulated bitstreams perfectly fit the COMSEC preamble for external COMSEC (Figs. 2,3), ie when link encryption is provided by external devices.

Fig. 2 - Traditional COMSEC transmission frame structure (FIGURE D-1, MS-220D)

Fig. 3 - The COMSEC preambles of the demodulated bitstreams

Bit Synchronization subfield is used to provide a signal for achieving bit synchronization and for indicating activity on a data link to the receiver.  The  subfield consists of the data-rate clock signal, a string of alternating ones and zeros.

Frame Synchronization subfield is used to provide a framing signal indicating the start of the encoded MI (Message Indicator) to the receiving station. As for MS-220D "this subfield shall be 465 bits long, consisting of 31 Phi-encoded bits (1 encoded bit = 15 bits). The Phi patterns are a method of redundantly encoding data bits, a logical 1 data bit shall be encoded as Phi(l)=111101011001000, and logical 0 data bit shall be encoded as Phi(0)=000010100110111. A simple majority voting process may be performed at the receiver to decode the Phi-encoded frame pattern to its original format". Figure 4 shows the Frame Sync subfield of the demodulated bitstreams: as one can easily verify, the Phi-decoded content matches perfectly the sync pattern indicated in Figure D.2 of MS-220D (#D.5.1.1.2). 

Fig. 4 - Phi-encoded frame sync

Message Indicator subfield contais the COMSEC-provided MI (or Initialization Vector), a stream of 87 random bits that are redundantly encoded using the Phi patterns seen above. Cryptographic synchronization is achieved when the receiver acquires the correct MI. Decoding can be easily achieved (Figure 5).

Fig. 5 - Message Indicator subfield

Since the COMSEC preambles of the analyzed bitstreams match the "external COMSEC" frame structure, likely the encrypted parts (voice/data) are secured by an external crypto unit such as the KY-57 (Vinson) or the more advanced KY-99.
Such uncommon (in HF band) transmissions are maybe a forward from a VHF link, who knows.

https://disk.yandex.com/d/-_3GnxUV_XKN9Q

QPSK (Link-22) & PSK8 (unid) bursts

Since some days on 7907.0 KHz/USB, starting in the morning, it's possible to hear long sessions of 2400Bd burst signals which use different modulations and ways. Signal "A" in Figure 1 consists of 4-segment bursts, each segment lasting about 420 ms.

Fig. 1

Modulation used is PSK8 at the rate of 2400Bd. The demodulated bitstream has a period length of 18 bits (6 PSK8 symbols, Figure 2) that can be reduced to 3 bits or even 2 bits if the "1s" column is removed.

Fig. 2 - demodulated bitstream of a PSK8 burst

Signal "B" in Figure 3 is the same as the above but in this case two station are involved, as it's easy to figure out looking at the different strengths of the bursts and their fading patterns. The "2-stations" mode starts randomly after a while but w/out a sort of schedule: in my opinion the time-slot paradigma (or Time Division Multiple Access mode, TDMA) is used (1).

Fig. 3

Signal "C" (Figure 4) use QPSK modulation instead (again 2400Bd) and 550 ms bursts with a "duty cycle" of 50%. 

Fig. 4

The demodulated bitstreams have a period length of 540 bits (270 PSK4 symbols, Figure 5) with a clearly visible framing consisting of 8 sections "Data-MiniProbe" of different durations. The 270-symbol frames and the durations of the eight "Data-MP" sections are the same of the STANAG-4539 TDMA waveform WF2 (see Table I), thus the recording "C" is definitely a Link-22 transmission (2).

Table I

Fig. 5

All my direction finding tries (TDoA algorithm with 5 receivers!) point to an area near Nuremberg (Nürnberg), Germany. Probably it's the USAG (U.S. Army Garrison) Ansbach base which is located in northern Bavaria, approximately 40 kilometers southwest of Nuremberg [1].

Fig. 6 - Direction Finding tries

For what concerns the PSK8 bursts, bitstreams and TDMA mode make me think about a Tactical Data Link (TDL), even if the analyzed waveforms do not match the standards Link-11 or Link-22 (atleast the ones I know). Anyway, given the lack of other information, it cannot be ruled out that it could be telemetry signals.

Monitoring has been made thanks to KiwiSDRs of OE3AKB (Landersdorf, AUSTRIA) e OZ1BFM (Vejby, Denmark) [2][3].

https://disk.yandex.com/d/b04EpZUQIO5GIw

(1) In TDMA mode each user is allowed to transmit only within specified time intervals named as "Time Slots" so that different users transmit in differents time slots.

(2) #2.3.2 Media Code Frame structure, Annex D to STANAG-4539 

[1] https://installations.militaryonesource.mil/.../ansbach-united-states-army-garrison
[2] http://oe3akb.ddns.net:8073/
[3] http://oz1bfm.proxy.kiwisdr.com:8073/