Swedish Defence, unid datalink protocol over MS-110A

The analysis concerns short transmissions monitored on 3824.0 KHz/USB within the 80mt Ham Band (1) thanks to SM1OTX Airspy HF+ in Sweden and OZ1AEF KiwiSDR in Denmark. According to my observations, at least on this channel (3824 KHz/USB), daytime transmissions occur at intervals of 15 minutes but not with a fixed schedule (for sample: hh05, hh20, hh35, hh50; hh10, hh25, hh40, hh55; hh08, hh23, hh38, hh53) and if there are messages to be sent. The transmissions seem less frequent at night, but I don't have enough IQ monitoring to say for sure; however I have noticed that - at night - the same frequency is sometimes occupied by CIS-12 transmissions.

I ran several Direction Finding tests using the TdoA algorithm and all the results point to an area south from Stockholm, probably the NAVCOMMCEN of the Sweden Defence (Figure 1).

Fig. 1 - Direction Finding results

In this regard, it's worth noting the use of the 3824 KHz frequency. Indeed , at that high latitudes, due to the long dark periods and the sun low on the horizon during winter, the low portion of HF must be used (lack of F layers).  The 80 meter band is certainly the best choice for medium distance contacts (eg  ships in Baltic Sea or Gulf of Bothnia) as it guarantees 100% reliability over 24 hours (Figure 2) and is suitable for NVIS (Near Vertical Incidence Skywave) mode propagation for local contacts.

Fig. 2 - Circuit Reliability for 80 mt comms between medium distances

Below the results of my analysis, aimed to understand and write down the Protocol Data Units (PDUs) of the datalink protocol and the way their fields are encoded. Please notice that the "designations" used are only mine and are introduced just for convenient reference.

The MIL-STD 110A (MS-110A) 1200bps Short Interleaver is the used HF waveform (Figure 3).

Fig. 3 - MS-110A waveform and ACF (66.6 ms)

Sometimes it may happens to see fast exchanges (bursts 1-4) before a "usual" data transfer: judging by the fading patterns in Figure 4, two nodes are involved.

Fig. 4 - fast exchanges before a data transfer

Discarding the MS-110A waveform overhead, the bitstreams exhibit a 104-bit period: data blocks, well-defined structures and repeated patterns are clearly visible in Figure 5.

Fig. 5 - a bitstream after the removal of MS-110A waveform

Blocks are delimited by long series of logical "1s" and are composed of up to 17 datagrams. Each datagram starts with a synchronization-type PDU (S_PDU) followed by data-type PDUs (D_PDU):

Fig. 6 - general structure of a MS-110A transmission

synchronization-type PDU (S_PDU)
The S_PDU consists of a common 40-bit/5-byte sync sequence (2)

[0111111001111110100010111001100010111001] 0x7E7E8B98B9

followed by a 104-bit/13-byte chunk of data which is  repeated three times. After synchronizing the bitstreams on the sync sequence and a length of 144 bits (ie: sync + ACF), the 13-byte chunk is formed of (Figures 7,8):

- a specific 8-bit field h (designated a header)
- a 40-bit/5-byte field m
- a common (!) 32-bit/4-byte sequence s

[11101010011010100010001001100010] 0xEA6A2262

- a 3 bits ("000") string
- a 21 bits field n

Fig. 7 - a synched bitstream (first 144 bits)

 

Fig. 8 - bit-field map of the synchronization-type PDU (S_PDU)

 

data-type PDU (D_PDU)

The D_PDU consists of 80-bit/10-byte field p (designated a payload) followed by a 3 bits "000" string and a final 21 bits field q (Figures 9,10): notice that the final part is the same as the one of the S_PDU.

 

Fig. 9 - datagrams consisting of a S_PDU followed by D_PDUs

 

Fig. 10 - bit-field map of the data-type PDU (D_PDU)

 The general structure of a datagram is shown in Figure 11:

Fig. 11

I spent some days studying the bitstreams and trying to understand the meaning of the fields of  both  S_PDU and D_PDU, and I came to the following conclusions.  

Header field
The argument of the 8-bit header field of the S_PDU is coded as described in CCITT V.42 paragraph 8.1.2.2, which specifies that the least significant bit of a 1-byte argument shall be transmitted first. Therefore, after its conversion into a decimal number xyz, I found that the field it indicates the number of the useful bytes of the datagram and the eventual presence of a filler in the last D_PDU of the datagram.
Given that:
- each D_PDU has a payload of 10 bytes (40 bits)
- the header field of the S_PDU is a 8-bit field
the system is designed so that each datagram may contain up to 255 bytes of data (11111111). For example (see Figure 12):

xyz = 130: 130 useful bytes, 13 complete D_PDUs, no padding
xyz = 126: 126 useful bytes, 12 complete D_PDUs + 6 useful bytes in the 13th D_PDU (the remaining space is filled with four 0 value bytes)
xyz = 118: 118 useful bytes, 11 complete D_PDUs + 8 useful bytes in the 12th D_PDU (the remaining space is filled with two 0 value bytes)

So, the max value of the header field (255) stands for: 255 useful bytes, 25 complete D_PDUs + 5 useful bytes in the 26th D_PDU (the remaining space is filled with five 0 value bytes).

Fig. 12 - meaning of the header field of S_PDU

That meaning of the header field is also confirmed by analyzing the bistreams of the bursts in Figure 4 

- burst 1 (header: 01101110) carries 110 bytes of data within a single datagram of 11 D_PDUs
- bursts 2,3,4 (header: 00001110) carry short 14-byte "messages" in 2 D_PDUs and six padding bytes

Fig. 13

(It is practically impossible to define the nature of these short 14-byte messages, one can only assume that it involves some form of negotiation between the two nodes. Likewise, it cannot be said whether these messages are due to the operator intervention or whether they are automatically generated by the protocol, as is the case with STANAG-5066) 

FEC
The argument of field q of the D_PDU  consists of the 21-bit Cyclic Redundancy Check (CRC) applied and computed on the first 83 bits (ie payload p + "000"). The same consideration can be made up regarding the S_PDU, where the argument of field n is the 21-bit CRC field and fields h+m+s + "000" form the 83 bits which shall be coded.
Indeed, thanks to the help of my friend cryptomaster, we found a (104,21) matrix generated by the polynomial: 

x^21+x^18+x^17+x^15+x^14+x^12+x^11+x^8+x^7+x^6+x^5+x+1

which is well suited to the specific case.

Fig. 14 - (104,21) matrix used for CRC

I coded a short Octave script and tested the check sub-matrix on the first 83 bits of both the types of  PDUs, results are shown in Figures 15,16: the check-matrix works like a charm! So, if we consider that fields are structured in bytes, the 000 bits act as kind of padding added to the word being coded and a (104,83) FEC coding is used (BCH? LDPC?).

Fig. 15 - check matrix applied to the S_PDUs

Fig. 16- check matrix applied to the D_PDUs

Encryption
In this regard  I extracted and merge together more than 500 D_PDU payloads into a single stream then I performed some tests on it.  The quality of the cryptography can be evaluated with a statistical method or by calculating the Shannon Entropy (3) and the Index of Coincidence (IC) (4) of the stream.
The statistical test (Figure 17) determines the randomness, the number of single bits in the stream is counted, then the double bits, then the triple bits and so on to the end. The result is a graph: if the information is not systematic, the adjacent columns should be half the size of the previous ones. The test shows good encryption quality. 

Fig. 17

The measure of the Shannon Entropy can be used, in a broad sense, to detect whether data is likely to be structured or unstructured. 8 is the maximum, representing highly unstructured, 'random' data. Properly encrypted or compressed data should have an entropy of over 7.5 while a low IC generally means that the text is random, compressed or encrypted (Figure 18):

Shannon entropy: 7.948409571238646
Index of Coincidence: 0.039349499261437125

Fig. 18 - Shannon Entropy and Index of Coincidence

If my guess is correct, the string m of the S_PDU is an Initialization Vector (repeated 3 times) of a stream cipher and thus the preamble is actually a COMSEC preamble consisting of bit sync, header, Initialization Vector, frame sync and a final CRC field.

A Secure Text system?
According my analysis, the PDUs of the used datalink protocol consists of the following formats (please notice that the 3-bit field encoded with the value "0" could be specified as NOT USED):

Fig. 19

But what kind of comms we are speaking about?
 

- although a datagram may contain up to 255 bytes of data, according my recordings each datagram is composed of no more than 130 bytes of data: such brevity could mean that the datagrams are made up of short text messages;
- transmissions occur almost regularly every 15 minutes, as if the sender station collects  messages coming from one link and then group and forward them into another link;
- transmissions are in a "blind" way, i.e. they are not preceded by 2G/3G ALE neither by voice calls and are not followed by ACKs: this could mean transmissions addressed to "stared" receiver(s);

 

the above issues make me think of a Secure Text system, ie a system that allows text and data exchange up to and including the level of secret and protected by cryptographic devices (5).
A good point in favor of my guess is that Swedish Armed Forces currently use a variety of national secure text messages that are not interoperable with international systems and are distributed just through the MaRA Naval Communications Centre (NAVCOMMCEN) for maritime platforms and operations [1].

...some speculations
Since Sweden Defence use  national crypto for domestic comms (6), what about the MGZI "Kryptomodem 1401" (Kryapp 1401, Crypto Modem for serial communication) commissioned by FMV (Swedish Defense) to Sectra [2]?

Fig. 20

The Swedish Defence Materiel Administration (Swedish: Försvarets materielverk, FMV)[3] is a Swedish government agency that reports to the Ministry of Defence. The agency is responsible for the supply of materiel to the Swedish defence organisation. In this case they also provide Kryptomodem 1401 to the Swedish Navy. Notice in Figure 21 that maybe the "Stri 8000" could be identified with the HF-8000 SDR Radio System prioduced by ELBIT (ELBIT Sweden is one of the supplier of Swedish Defence).

Fig. 21

 

 https://disk.yandex.com/d/3qW7_b3IbdkEGw 

(1) The 80-meter or 3.5 MHz band is a band of radio frequencies allocated for amateur radio use, from 3.5 to 4.0 MHz in IARU Region 2, and generally 3.5 to 3.8 or 3.9 MHz in Regions 1 and 3 respectively. European common allocation is AERONAUTICAL MOBILE (OR) FIXED LAND MOBILE 

(2) It must be said that in many messages the sync sequence seems to be 48 bits starting with [00000000] 0x00

(3) In the context of information theory, Shannon's entropy is a measure of the rate at which information is produced by a source of data. It can be used, in a broad sense, to detect whether data is likely to be structured or unstructured. 8 is the maximum, representing highly unstructured, 'random' data. English language text usually falls somewhere between 3.5 and 5. Properly encrypted or compressed data should have an entropy of over 7.5

(4) 0 represents complete randomness (all characters are unique), whereas 1 represents no randomness (all characters are identical). English text generally has an IC of between 0.67 to 0.78 whereas 'Random' text is determined by the probability that each letter occurs the same number of times as another. A low IC generally means that the text is random, compressed or encrypted. 

(5) Secure text systems enable the armed forces to transmission and receipt military request, reports, orders, plans and policies and can be achieved in different ways, both regarding the format of the message and its method of transmission.

(6) A few words on Swedish cryptology
For two centuries Sweden has upheld neutrality in the sense that the country has not been member of any military alliance. Only recently did the country apply for NATO membership although it has been a public secret that Sweden since the end of WWII has had an informal, but quite strong collaboration with NATO countries, especially the Scandinavian countries including Finland with which strong historical, cultural and linguistic bonds exist. The cooperation has manifested itself in the area of signals intelligence, exchange of intercepted information and interoperability of communications equipment including crypto equipment, and more recently in a close collaboration with NSA.
The credibility of neutrality has been supported by strong defense forces, including cryptologic efforts. A few cases serves to lustrate this: In spite of its neutrality, Sweden was able to just a short time after Germany attacked Denmark and Norway in April 1940 by systematic interception to reading German military telegraph traffic, which transited Sweden, by cracking the so called Geheimschreiber (a kind of substitution cipher where the key was changing with each character and the initialization vector was altered with a few days’ interval) primarily based on the attack by a mathematical genius, Arne Beurling. 
Another feat was the successful evacuation – operation Stella Polaris - of the entire (nearly) Finnish SIGINT staff, their families and crypto analytic material and equipment after the Russo-Finnish war in 1944 ended in Finnish defeat.
Already in 1942, all cryptological and cryptanalytic effort were concentrated in FRA, Försvarets Radioanstalt (Defense Radio Establishment).
Thus, for many years the crypto efforts of Sweden's defence forces and government communications have had a high priority as a national endeavour, mainly due to the centuries long Swedish neutrality, as described above. Today, as Swedish membership of NATO is imminent pending ratification by the Turkish parlament, this collaboration of long duree ensures that the transition from neutrality to NATO mebership will be smooth. There is no doubt that the navy of Sweden in the actual geopolitical situation will play an important regional role in the Baltic Sea and the approaches to this ocean area.
The designations of Swedish crypto equipment is quite straightforward: 

MXY[Z] - Maskinkrypto; Machinegenerated crypto
X - G = Gemensamt (common for all service branches), M - Marinen (navy), L - Flygvapnet (air force)
Y - Typ Y; Type Y
[Z] - Optional designator; Z =  I, for international use, Z = U, for use abroad
The equipment is graded according to its degree of signal protection (Sw., SG, signalskyddsgrad), i.e. SG R(estricted), C(onfidential), S(secret) and T(op) S(ecret).

[1] https://docplayer.net/45022367...internet.html
[2] https://communications.sectra.com/case/encryption-solutions-for-the-swedish-defence/
[3] https://www.fmv.se/english/

Swedish STANAG-5066 client-application, a look at the DTS sublayer

(Just an update about the "Swedish Defence client-application for STANAG-5066" topic)
As said in the previous posts, the users employ the 3G-HF "Circuit Mode" service (STANAG-4538), data are transferred in non-ARQ mode using the STANAG-5066 stack and basic end-to-end transport protocols (UDOP/RCOP). Since the use of 3G-HF, the stations partecipating the netwok synchronously scan the assigned pool of frequencies and transmissions just happen when in need. 
I came across on a transmission, on 4742.0 KHz/USB, that exhibits two features never seen before in the previous transmissions (at least in my case):
● the used HF waveform is STANAG-4539 3200bps (usually they employ 188-110 1200bps along with S-5066 or alone in 8-bit text mode);
● the multiple occurrences of the ASCII string "WVKA" inside a message, which implies a look at the role of the Data Transfer Sublayer (DTS) of STANAG-5066.

Fig. 1 - Multiple occurrences of the string "WVKA", here in block 2 out-of 20

It's noteworthy that, actually, the occurrences are about the half since data are repeated!

Just a reminder for background: in case of a source message that is larger than the MTU (Maximum Transmission Unit) of the S-5066 subnetwork interface (usually <=2048 bytes), the client-application segments the message into n-blocks (A_PDUs) before its submission. The blocks are then encapsulated into the final C_PDUs, which in turn are segmented by the Data Transfer Sublayer (DTS) into smaller 200-byte D_PDUs (PDU stands for Protocol Data Unit).

Fig. 2 - progressive encapsulations and segmentation in S-5066 stack

It's possible to verify that in some circumstances - probably when UDOP protocol is used - segmenting a C_PDU results in duplicate D_PDUs (!), except the first and the last D_PDUs (read below). As clearly shown in Figure 3, the analyzed transmission just matches that case.

Fig. 3 - The duplicated D_PDUs in the block 2 out-of 20 (the same block of Figure 2)

This behavior is easily seen in many transmissions, whether they use S-4539 or 188-110A waveforms: note in Figure 4 that the first D_PDU is repeated only in the first C_PDU, while the last D_PDU is never repeated.

Fig. 4

Where do the duplicate D_PDUs come from? Inspecting the headers in Figure 5, it's possible to note that the "C_PDU Segment Offset" field contains the same value in the pairs of the duplicate D_PDUs. Given that the Segment Offset indicates the location of the first byte of the segment with respect to the start of the C_PDU, it means that the C_PDU (and thus the upper sublayers) does not contain duplicate data, otherwise the Segment Offset fields in the pairs of the duplicate D_PDUs would have contained different values! Thus, in my opinion, the duplicate D_PDUs are originated by the DTS sublayer. Notice that what we see in Figure 5 are the on-air bytes, thus after they have leaved the DTS (see the S-5066 stack in Figure 2).

Fig. 5 - headers of the D_PDUs (each row is a D_PDU, see Figure 2)

Segment Offset fields contains a 200 bytes step values, as expected:
0x0000 =    0
0x00C8 =  200
0x0190 =  400
0x0258 =  600
0x0320 =  800
0x03E8 = 1000
...

The receive node will re-assembly a C_PDU from its segments (the D_PDUs) after they have passed the CRC error-check and have no detectable errors: probably the redundancy is used in this regard. I did not find any reference in the S-5066 standard, at least the one at my disposal, and I tend to exclude possible errors of the S-4539 (or 188-110A) decoder since the same results were obtained using different decoders and different HF waveforms: so, at least in my opinion, the repetition of the D_PDUs could be a custom modification of the code of DTS  (switchable to maintain NATO compatibility) or a new feature added to a recent edition of S-5066. Definitely, even if the latency increases (such transmission mode takes about twice as much time, although they have moved on the 3200 bps of S-4539) the add of redundancy improves the general reliability of the system since S-5066 is used in non-ARQ mode.

As for the string "WVKA", only guesswork can be made: further recordings are in need. For now, I'm going to code a S-5066 dissector to facilitate the reading of the headers...

https://yadi.sk/d/9vqs2DfTOKN1sg
https://yadi.sk/d/s7oyiYaTt406vw 

Swedish Navy submarine MSK multi-channel broadcast

(For background it might be helpful to read the relevant entries here)

Swedish Royal Navy (Swedish: Svenska marinen [1]) uses a broadcast function of STANAG-5030 (1) for communication with its subs in the Baltic Sea, the return channel is believed to be low-end HF. These LF broadcasts use the 200Bd/100 MSK waveform and can be heard on 40.4, 42.5, and 44.2 KHz (CF) by using  KiwiSDR receivers located in the island of Gotland which have a good SNR. [2].

All the three signals have the classic set of parameters for (G)MSK: a spectrum equal to 1.5*Br (300Hz), shift equal to Br/2 (100Hz), a characteristic bell-shaped appearance (Figure 1), and others such as 4-point constellation, transitions and real trajectories (Figure 2). Please note that the carrier in the fourth degree is very weakly expressed, sometimes it is practically invisible at all.

Fig. 1

Fig. 2

Using 200Bd MSK (a form of QPSK) it is possible to transmit two 100 Baud channels X and Y, each on a pair of phase, and each channel can consists of 2x50 Baud multiplexed channels. Thus, MSK can provide a TDM multi-channel broadcast of  up to 4x50 Baud X1 X2 Y1 Y2 channels within the 200Hz assigned band (MSK4).  Some aspects about the similarities bewteen QPSK and MSK are covered in radioscanner forum [3].

In conditions where no messages are available for transmission, the four channels are arranegd with two "empty channel filler" (ECF) patterns, probably generated automatically at the transmitter equipment:

- two channels share the same 15-bit pattern;
- a third channel uses a different 5-bit pattern;
- the fourth channel uses the same 5-bit pattern where one column is repalced by the bits of the pseuso-random sequence generated by the polynomial x^31+x^3+1.
An example of this "idle" mode is shown in Figure 4: here the m-sequence is sent in the Y2 channel (notice the same pattern sent in X1 X2 channels ).

Fig. 3

A more generalized scheme highlighting the position of the m-sequence channel in four different recordings is shown in Figure 4.

Fig. 4

 In case of messages, the four channels use a 5-bit format with different framings:  

- two channels share the same 5-bit framing, i.e 1-bit marker (pos/neg according the polarity) + 4-bit data:

- a third channel uses an unid (to me) framing;

- the fourth channel uses the same 5-bit framing of the first two channels but the marker column is replaced by the bits of the pseuso-random sequence generated by the polynomial x^31+x^3+1.
Figures 5a,5b show such arrangement.

Fig. 5a

Fig. 5b

Due to their strategic and tactical importance, subcomms require secure cryptographic protocols and this could explain the presence of the x^31+x^3+1 pseudo-ramdom sequence which is used to sync the receive KW-46/KIV-7 ciphers (other than to permit channel identification), although an encrypted 4-bit stream is rather unusual as well as the use of the 1+4 bits frames. 

In this regard, one might even think that the actual secured messages channel is Y before the TDM split (Figure 6), while the other channels X1 X2 transport not critical 4-bit coded data (WX forecast, sea conditions, ...). This way, messages could use 10-bit START-STOP code which is then encrypted using the KW-46/KIV-7 equipment. Encryption results in bits 2 to 10 being encrypted and bit 1 (START) being replaced with unencrypted bit defined by the polynomial x^31+x^3+1, or in reverse order - bits 1 to 9 encrypted and bit 10 (STOP) replaced (2). A second hypothesis - perhaps the most likely - is that each channel is encrypted with a specific cipher ...but these are just my speculations.

Fig. 6 (m-sequence columns are highlighted)

The results of TD0A geolocation indicate three probable transmitter sites that match fairly exactly with those indicated in a map presented by FMV (the Swedish Defence Materiel Administration) [4] at the March 2020 HFIA HF Industry Association [5] Meeting in San Diego, CA (Figure 7):

- 40.4 KHz: SAS/SRC Varberg
- 42.5 KHz: SAS2 Gudinge
- 44.2 KHz: SHR Ruda

Fig. 7

It must be taken into account that I can't record the (KiwiSDR) LF spectrum 24/7 so the results indicated above may be incomplete: further recordings are needed and possibly an update post will be published later. Hints and comments are welcome.

https://yadi.sk/d/RlVneazxS8HT4w idle

https://yadi.sk/d/hDRK-867rvKaqg traffic

(1) STANAG-5030 is a restricted document so no information is publicy available. Moreover, the new STANAG-4724 "VLF/LF MSK Multi Channel Broadcast" is currently being ratified by NATO member states as next evolution:

https://nso.nato.int/nso/nsdd/ListPromulg.html 

(2) max success for x^31+x^3+1 in Y stream was found for a length frame of 10 bit; that same frame does not have parity bits (x^31+x^3+1 column excluded from the checksum)

[1] https://www.forsvarsmakten.se/../marinen/

[2] http://kiwisdr.thulesius.se:8073/ ,  http://158.174.17.55:8073/

[3] http://signals.radioscanner.ru/info/item281/

[4] https://www.fmv.se/english/

[5] https://www.hfindustry.com/

Swedish Defence 8-bit text ACP-127

Thanks to the help of some friends of mine - Guido, J.S4538 and Karapuz -  I've been studying these transmissions for several months and some of their characteristics (mainly their occurences and format) lead to think that this traffic is most likely the encrypted "8-bit text ACP-127 (SV-7)" from the Swedish Armed Forces, as indicated in one slide of their presentation of the HF2000 system at HFIA Metting 2010 [1] and reported below in Fig. 1 (at present I don't know what the term "SV-7" stands for).

Fig. 1

All the transmissions use the MIL 188-110A Serial waveform with a data-rate of 1200bps and modem running in ASYNC 8N1 mode, they are not preceded by 2G/3G ALE neither by voice calls and happen many times per day w/out an apparent sked.  The transmitted 8-bit (encrypted) text can be obtained using a 188-110A decoder that shall be configured to work in ASYNC mode and  8N1 framing, or you may get the source bitstream by configuring the output of the decoder as ASCII Bits: in the latter way you have to manually remove the start/stop bits in order to obtain the 8-bit text (I mostly used this method to study the "format" of the bitstreams).

𝑭𝒓𝒆𝒒𝒖𝒆𝒏𝒄𝒊𝒆𝒔
As well as with our receivers, monitoring is performed thaks to the use of four remote KiwiSDRs located in Sweden and Finland (Fig. 2)

Fig. 2 - the used KiwiSDRs and map of main RT/x stations

So far these are the spotted frequencies thanks to Guido, J-4538 and Karapuz (all freq. are USB): 

3034, 4228, 4321, 4373, 4396, 4408, 4513, 4522, 5242 

Although in a small percentage, synchronous 188-110A transmissions (still 1200bps/Long) can be received in these channels.
A parallel monitoring of 4396 KHz (using KP20 in Finland) and 4513 KHz (using SM0KOT in the northern part of Sweden) was performed during the morning-time on 20 December 2017 and got some interesting points about these two channels. Looking at the waterfall in Fig. 3, the strengths of the received signals point out different transmitters sites; since the waterfall is related to KP20 SDR, frequency 4396 KHz - on the left in the waterfall - perhaps could be operated by the close Karlskrona Naval Base. Moreover, transmissions on 4396 and 4513 KHz occurred almost simultaneously during all the monitored time (Dec 20th, 2017) but actually it's impossible to say if they carried the same messages.
 

Fig. 3- KiwiSDR KP20 in Finland

However, such behavior was not observed during the first seven days of January 2017: indeed, those two frequencies seem not to be used, as well as 4321, and the trasmissions happen on 4373 KHz (Fig. 4) which was spotted by Karapuz on 2 January.

Fig. 4 -
KiwiSDR KP20 in Finland

➤ 𝑢𝑝𝑑𝑎𝑡𝑒 On Jan 8th, 4.3 MHz transmissions take place only on the new 4372 KHz. I do not know the reasons for these changes.

𝟴𝐍𝟏 𝐟𝐨𝐫𝐦𝐚𝐭𝐬 
Looking at the bitstreams, it's esay to see that headers and data are arranged in different formats, although the same "8N1" framing is used (Fig. 5).

Fig. 5

"A" format (headers and data are shifted and separated) is used in 4373, 4396, 4408, and 4522;
"B" format (headers and data are contiguous) is used in 4228, 4321, 4513, and 5242;
"C" format (as in "A" but data appears as "fragmented" in separated blocks) is used in 3034.

(for what concerns the 3034 KHz I could record only very few 8N1 transmissions during long-time periods, perhaps it is related to a less used service)

Probably the different formats (and the one used in STANAG-5066 [2]) and the different Tx sites are due to the different recipients, ie: Army, Navy, Air Force and Civil Defence ...but it's only my guess.

𝐭𝐡𝐞 𝐙-𝐬𝐭𝐫𝐢𝐧𝐠𝐬 𝐢𝐧 𝟴𝐍𝟏 𝐚𝐧𝐝 𝐒-𝟓𝟎𝟔𝟔 𝐭𝐫𝐚𝐧𝐬𝐦𝐢𝐬𝐬𝐢𝐨𝐧𝐬
The most important aspect is the presence of the Z-strings in the messages' headers: these are the same as the strings already seen in the data-blocks of the  S-5066 transmissions from the Swedish Armed Forces [2]. Note also that in both the transmissions the Z-strings are contained within the same sequences  (I catched tens of transmissions, for simplicity I show in Fig. 7 only two of these but the matches are in all the recordings).

Fig. 6 (HEX view)

The 8-bit transmissions use only the Z-strings ZAPD<L> and ZXPD<L> and both are used every day with a prominence of the latter. So far, these are the heard strings:

ZAPD flwd by B,C,D,E,F (ie: ZAPDB, ZAPDC,...)
ZXPD flwd by B,C,D,E,F (ie: ZXPDB, ZXPDC,...)

I saw that the fifth letter of the Z-string does not change during the week, then in the following week it takes the next value in the alphabetical order: for example ZAPDD is used from Mon to Sun then in the following monday it changes into ZAPDE; the same happens for ZXPDD which changes into ZXPDE.
This alphabetical progression  is verified by a long-time monitoring and it's not a simple  "rotation" but rather a way to indicate the week of the year using the last two letters and the convention A=1, B=2, C=3,... so that for example DC = 43, DD = 44 and so on (Fig. 7).

Fig. 7

It is very important to note that the same mechanism has been observed in the variations of the Z-strings in S-5066 transmissions (sporadic catches, not from a monitoring):

ZRTBC and ZXPBC on 6,7 June (BC = 23th week)
ZRTBD and ZXPBD on 15,16,17 June (BD = 24th week)
ZXPBE on 23 June (BE = 25th week)
ZAPCA on 1,2 August (CA = 31th week)

as you see, the dates belong to the number of the week indicated by the last two letters of the Z-strings. Nothing (unless the timestamp header in S-5066 transmissions) seems indicate the time & date of the message, maybe it is contained within the encrypted text.

The Z-strings suffix "DI" was expected during the week 4-10 December to indicate the week #49 but curiously they skipped the letter "I" and adopted "J" to code the number 9 (Fig. 8), maybe to avoid confusion between "I" and "1" ?

Fig. 8 - "DJ" suffix to code week #49 (8x19 view)

It's interesting to note the choice of the letter "K" to code the "0" during the fiftieth week (11-17 December): indeed the suffix "EK" (more precisely the string "ZXPEK") has been found in all the messages of the monitored frequencies (3034, 4396 and 4513) during the week #50. 

As expected, the suffix "KA" (= 01) is used to code the first week of the year: the presence of the ZXPKA string has been confirmed also by the catches of my friends Guido and Karapuz (see the comments to this post). Figure 9 below shows the string ZXPKA in a message received in the firts week of 2018 (Jan 4th): note the use of MS-DMT software configured in Async 8N1 mode. 

Fig. 9 - "ZXPKA" string during the week #01(transmission decoded using MS-DMT)

That said, the Z-strings shall be considered as 3-letters:
ZAP
ZNT (so fare seen only in S-5066 transmissions)
ZRT (so far seen only in S-5066 transmissions)
ZXP

followed by 2-letters (encoded) week of the year, according to:
A = 1, B = 2, C = 3, ..., H = 8, J = 9, K = 0 

It's difficult to say what the initial 3-letters  stand for, maybe they could indicate the precedence of the messages: ie, ZAP for higher priority (flash) and ZXP for routine, or maybe a kind of classification. 
I tried the NATO military Z-signals defined in ACP 131 [3] but their meanings make poor sense in our context.

---

[1] http://www.hfindustry.com/meetings_presentations/...HF2000_HFIA_2010.pdf 
[2] https://i56578-swl.blogspot.it/2017/06/unid-stanag-5066...client.html
[3] http://www.angelfire.com/va3/navy_mars/ACP131.pdf

 

https://youtu.be/lWNljuCQw_0

Swedish Defence, unid STANAG-5066 RCOP/UDOP client

As said in the previous post, in all the monitored transmissions the chosen 3G-HF service is the Circuit Mode, and 1200bps 188-110A Serial is the used HF traffic waveform. Data are transferred by STANAG-5066 D_PDUs and both the RCOP (Reliable Connection Oriented Protocol) and UDOP (Unreliable Datagram Oriented Protocol) are used as basic end-to-end transport protocols. 
The use of 3G-HF means that the stations partecipating the netwok synchronously scan the assigned pool of frequencies; moreover, transmissions are not scheduled and looks like they happen just when in need.

The analysis of the S-5066 PDUs help to identify the user of the system: indeed, all the S-5066 Addresses belong to the 006.046.yyy.zzz block which is allocate to Sweden, most likely the user is the Swedish Armed Forces (Swedish: Försvarsmakten). So far the client protocol has not been identified.
Me and S4538 (the nickname of a friend of mine) analyze these transmissions since several moths and this post show the results of the investigations: some aspects are confirmed while some other are tentatives.

1. Protocol Units, a "wrapper" protocol

Figure 1 shows two bitstreams after MS-110A removal and after synced on 0xEB90 (S-5066 D_PDU synchronisation sequence): in this cases all the D_PDUs are of type 7 (non-ARQ delivery) and 0 (Simplex data transfer) and carry UDOP and RCOP protocol.

Fig. 1

 

 Let's have a look at ASCII rapresentations of a series of decoded transmissions (Fig. 2):

Fig.2

 

 

Data are structured as a series of headers having the format {<length>,<content>}:

{5,HWK01}{3,PFY}{3,001}{3,001}{10,1570853327}{0}{143,...}{0}
{5,HWK01}{3,ZHO}{3,001}{3,001}{10,2096500086}{0}{625,...}{0}
{5,HWK01}{3,ZHO}{3,001}{3,001}{10,2097463403}{0}{937,...}{0}
...
...

A possible explanation could be:

{5,HWK01}{3,PFY}
source and destination IDs

{3,001}
number of the current data-block 

{3,001}
total number of data-blocks

{10,1570853327}
most likely a timestamp

{0}
unknown. So far, never seen something different at this position, probably marks the start of a data block (SOF).

{143,data-block}
size length in bytes of the block, data.

{0}
unknown. So far, never seen something different at this position, probably marks the end of a data block (EOF).

The particular format of the headers {<length>,<content>}, the iteration of the transmissions and their duration, lead to think to a wrapper protocol: it simply catches the requested values from a  original/received file, computes their lengths and arrange them in the form {<length>,<content>} for its subsequent forward.

1.1 Source/Destination IDs

The attribute "length" is not fixed but depends on the length of ID. In the large majority of the cases traffic is originated from 006.046.000.zzz nodes (IDs: HWK01,ZMK002) and directed to 006.046.001.zzz nodes. Very few traffic in the reverse direction. Maybe the 006.046.000.zzz block is assigned to a command/regional subnet. So far, only one transmission between 006.046.001.zzz block nodes has been copyied, namely from BYN21 (006.046.001.006) to NZH21 (006.046.001.052).
It's interesting to note that in some transmissions the same ID "HWK01" appear in both the src and dest blocks (Fig. 3) but with different S-5066 addresses (anyway belonging to the same block 006.046.000.zzz): 006.046.000.102 and 006.046.000.028. Perhaps there are two possible reasons:
a) the ID HWK01 acts like a sort of global-ID with different users/services, each with a distinct S-5066 Address;
b) these physical instances. Indeed, as shown in [2], they have separated Rx and Tx stations. Maybe this is a information transfer from one Tx to its corresponding Rx station which logically share the same ID.

Fig.3

 

For what concerns the identifications, I could find a possible clue about "HWK01". Sweden Air Defense Regiment has two air defence battalions equipped with Robotsystem 70 (RBS 70) and Robotsystem 97 (RBS 97): 

http://www.wikiwand.com/en/Air_Defence_Regiment_(Sweden)

Recently, defence and security company SAAB has signed a contract with the Swedish Defence Materiel Administration (FMV) for a service life extension of the RBS 97 air defence missile system, this order ensures the continuing effectiveness of a missile system that is the backbone of Sweden's two air defence battalions:
http://saabgroup.com/Media/news-press/news/2015-11/saab-provides-service-life-extension-for-rbs-97-air-defence-system/

The RBS 97 is a surface-to-air missile system that is better known as "HAWK", then  it could be that HWK01 = HAWK 01 = Air Defence Battalion 1.

1.2 Timestamp

For what concerns the timestamp header, it seems related to the timestamp of the "wrapped" file, perhaps when it has been received: I think it's a unmanned system working in a FIFO logic, ie the messages are wrapped and forwarded in the same order they arrive (first came first served). 
As well as for the IDs, the wrapper does not use a fixed length for the timestamp and its length  varies from a 7 to 10 bytes. By examining consecutive transmissions, the granularity of the clock is 1 msec, a new Epoch Time starts when the timestamp reaches its maximun value (9999999999).
I copied some transmissions probably just few minutes after the start of a new epoch time and thus a timestamp with increasing length of 7, 8 and 9 bytes (Fig. 4).

Fig.4

1.3 Data Block, the "Z-strings"

As shown in Figure 5, if the length of the data-block is longer than the max allowed value (1977 bytes in this case) it is segmented into smaller blocks. The timestamp header in the segmented block remains unchanged while the current data-block number and the data-block length are updated. The data-blocks are not filled if their length is smaller then the maximum allowed value.

Fig.5

 

It must be noted that the maximum lenght of the data-block changes according to the length of the Source/Destinations IDs and the length of the timestamp, as shown in Fig. 6

Fig.6

 

Each data block exhibits a fixed 33-byte sequence that precedes a particular string that consists of the letter "Z" followed by four letters, all in uppercase format: we term these strings as  "Z-strings". Adding the received UDOP/RDOP data blocks to form a single file, it's possible to point out the 33-byte sequences and the Z-strings: most likely they form the preamble of the data-blocks (Fig. 7).

Fig. 7

 

A complete discussion about the "Z-strings" can be read in the post related to the "8-bit text transmissions" from Swedish Army:
https://i56578-swl.blogspot.it/2017/11/swedish-army-8-bit-text-acp-127.html

2. Application Identifier "0x8008"

In order to identify the application that is responsible for the wrapper protocol we have to look at a generic D_PDU which transports the protocol data (the S-5066 D_PDUs are visible once removed the 188-110A overhead and synched the bitstream on the sequence 0xEB90).
As shown in Figure 8 the Application Identifier related to the wrapper protocol is "0x8008", that just belongs to the values which are available for user-defined applications (S-5066 Annex F, table F5).

Fig.8

As shown in Fig. 9, the Application Data, ie the data coming from the S-5066 client application,  begin just after the Application Identifier field of the UDOP/RCOP U_PDU. So far I found the same 4-byte sequence "00 00 00 01" for both RCOP and UDOP protocols and, in my opinion, it is a sort of "identifier" for the wrapper protocol PDU.

Fig.9

  3. Protocol MTU

Given the initial 4-byte sequence "00 00 00 01" and the lengths of all the headers, the Maximun Transmission Unit (MTU) of the wrapper protocol is equal to 2039 bytes for both RCOP and UDOP protocols, eg:

ID{5,HWK01}{5,HWK01}{3,001}{3,002}{10,2367731361}{0}{1975,......}{0}
4 + 56 + 1975 + 4 = 2039 bytes

ID{5,HWK01}{3,VJL}{3,001}{3,002}{10,2223461543}{0}{1977,......}{0}
4 + 54 + 1977 + 4 = 2039 bytes

As for above, the maximum lenght of the data-block must vary according to the lenghta of the Source/Destination IDs and the timestamp current format (from 7 to 10 bytes):

*10-byte timestamp {10,nnnnnnnnnn} (15-byte length)
1975 bytes (Dest ID = 5 bytes)
1977 bytes (Dest ID = 3 bytes)

*9-byte timestamp {9,nnnnnnnnn} (13-byte length)
1977 bytes (Dest ID = 5 bytes)
1979 bytes (Dest ID = 3 bytes)

and so on for 8 and 9 bytes timestamp formats.

It's interesting to note in Fig. 10 that in case of use of UDOP protocol each D_PDU is transmitted twice unless the last. This makes sense to improve the reliability, since the nature of UDOP protocol itself (a basic connection-less protocol) and the use of S-5066 non-ARQ service. Also note that the C_PDU is segmented into 200-byte segments (each segment will be encapsulated in one D_PDU): as you see, the overhead bytes added by C, S and U sublayers are present only in the first segment.

Fig.10

 

The used C_PDU-Segment size (200 bytes) is the one indicated in the segmentation examples depicted in STANAG-5066 C.4.2 Edition 3, in our case the max size of C_PDU is 2051 bytes (Fig. 11).

Fig.11

4. Networks, IDs

For what concerns the HF network, they have tens(!) of available frequencies, each may be used with RCOP or UDOP protocol.
STANAG-5066 Addresses heard so far:

[006.046.000.zzz] block
HWK01   006.046.000.028, 006.046.000.102
ZMK002  006.046.000.037
OYO01   006.046.000.101

[006.046.001.zzz] block
FRJ    006.046.001.001
BYN21  006.046.001.006 (prob. the complete call for BYN)
DWY    006.046.001.009
PFY    006.046.001.010
ZHO    006.046.001.028
RJY    006.046.001.029
GZL    006.046.001.030
HEH    006.046.001.034
HEH002     --"--
CAU    006.046.001.046
NZH21  006.046.001.052 (probably the complete call for NZH)
VJL    006.046.001.054

5. Retransmissions?

I had the chance to copy a transmission on 5206.3 KHz followed by an identical one on 5059.4 KHz after few seconds (Fig. 12). This is quite easy to accomplish since they use S-4538 FLSU for link setup thus the stations of the network are synched and scan the same pool of frequencies at same times. Repetitions increase the reliability of the system but do not know if it was just a planned episode or a routine scenario (more powerful monitoring tools would help in such cases).

Fig. 12

 

[1] https://books.google.it/books?id=ylh8AgAAQBAJ&lpg=PA78&ots=0H2YO-Mnvk&dq=KV90%20Sweden%20Army&hl=it&pg=PA78#v=onepage&q&f=true

[2] http://www.hfindustry.com/meetings_presentations/presentation_materials/2010_feb_hfia/presentations/HF2000_HFIA_2010.pdf