23 June 2017

the beauty of grayline

188-141A calls copied this morning around 0455 UTC on 11111.0 KHz/USB (Fig. 1). The ALE addresses  belongs to the French Navy naval bases at overseas departments and territories Papeete and Noumea:
1OMFUM French Navy OMAR Net, Papeete OCE
1OMFUJ French Navy OMAR Net, Noumea NC
more than 16000 Km far from my antenna: reception has been possible thanks to a grayline-path (Fig. 2).

Fig. 1 - decoding
Fig. 2 - the grayline at the reception time

It's interesting to note that, at that same time, exploiting the same grayline path I also had a good copy of CHU Ottawa Canada (Fig. 3).

Fig. 3

Grayline observations and predictions can be read at the VOACAP (Voice of America Coverage Analysis Program) site:
http://www.voacap.com/p2p/index.html
as well as a lot of interesting and accurate services about about HF propagation:
http://www.voacap.com/ 

French Navy OMAR (Organisation MARitime des transmissions haute fréquence) HF New-Generation program have the task to modernize all the High-Frequency transmissions media of about 80 assets of the Ocean forces of the French Navy, maintaining interoperability with other NATO Navy. The project was committed to Thomson-CSF (now THALES):

21 June 2017

THALES HFXL modem, "SALAMANDRE" tests go on

Likely another "SALAMANDRE" test session for the new Thales HFXL modem spotted this morning on the 7MHz band. This time the modem uses 12 non-contiguous 3 kHz channels from 7505.8 KHz up to 7656.1 KHz (~150 KHz bandwidth). The HF waveform is a modified STANAG-4539 with the extended preamble of 124 symbols added by Thales developers; further info about the modified waveform and the modem, as well as useful links, can be read in this post.

Fig. 1
It's interesting to note in Figure 2 the use of a double 188-141A 2G link setup exchange before the beginning of the HFXL session: the ALE exchanges happen just on the first and last channel of the next HFXL transmission as to negotiate/announce the used band; anyway, the HFXL session starts after the usual 2G 3-way handshake (as in Fig. 1). This initial link setup part is termed by Thales as the "3KHz phase" and it is illustrated in one of their presentations
By the way, the used ALE calls are XLA and XLB and almost surely they stand for (HF)XL modem-A and modem-B and belongs to French Forces network.

Fig. 2
The HFXL modem 12 channels have been tracked using SDR-Console v3 software configured for twelve simultaneous receivers, in this sample all the channels exhibit a PSK-8 modulation at 2400 symbols/sec (Figs. 3,4): the channel #4 is damaged by an adiacente FSK-2 transmission.

Fig. 3
Fig. 4

19 June 2017

unid STANAG-5066 RCOP/UDOP client, Swedish Army "C2" integrator? (tentative)

[updated, 19 June]

As said in the previous post, in all the monitored transmissions the chosen 3G-HF service is the Circuit Mode, and 1200 bps MIL 188-110A is the used 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, but so far the client protocol which run over S-5066 has not been yet identified. Me and S4538 (the nickname of a friend of mine) started to analyze these transmissions since several days and below are exposed the tentative results in order to get comments from out there, further posts will follow.

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
It's interesting to note in Fig. 2 the initial same structures which are present in all the recordered copies, in both RCOP and UDOP cases, after the removal of the DTS overhead (D_PDU encapsulations):
 
Fig. 2
 Let's have a look at ASCII rapresentations of a series of decoded transmissions (Fig. 3):

Fig. 3
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 (see later)

{3,001}
total number of data-blocks (see later)

{10,1570853327}
most likely a timestamp (see later)

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

{143,data-block}
number of bytes followed by 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 that acts as a "bridge" to passing data between T-MMH systems (eg X.400 and ACP127 networks, although STANAG-4006 performs that task) or between C2 systems.

By the way, "The Sweidish Army uses C2 systems that are not interoperable and data must be manually transferred between them. Sweden began to integrate all the service's C2 systems, at all levels, in 2005 under the name SWECCIS. [...] Swedish Armed Forces HQ tasked FOA, FMV and FHS to propose a vision for a mobile military joint C2 system for 2010, this project has been expanded to include civilian C2 elements [...] the goal is a single C2 environment..." [1].
But these are only suppositions(!), although some clues come also from this picture [2]



For what concerns the timestamp header, it seems related to the "wrapped" data file. By examining consecutive transmissions, the granularity is in milliseconds and the Epoch Time started on Sat May 13 2017 00:00 CEST (GMT +2): possibly the date on which this "service" came into production?

***  structure of the protocol ***
In the cases depicted in Figure 4a, if the data-block length is greather than 1977 bytes then it is segmented into smaller blocks, each block consisting of the same {<length>,<content>} headers. The timestamp header remains unchanged while the current data-block header is updated.

Fig. 4a
Anyway, the max length of the data-block is not constant but depends on the length of the IDs, or better, on the length of the headers (Fig. 4b):

Fig. 4b
The max length of the data-block varies to match the max length of the transmission-block which appears to be  2051 bytes for both RCOP and UDOP protocols. The data-blocks are not filled if their length is smaller than the one allowed by the transmission block max length.

Why 2051 bytes? The maximum transmission unit (MTU) for S-5066 Subnetwork Interface is 2048 bytes when using point-to-point transmitting mode (ARQ or NON-ARQ), so the clients are responsible for segmenting larger messages into User Protocol Data Units (U_PDUs). The Subnetwork Interface Service will discard any U_PDU submitted by a client where the U_PDU is greater in size than the MTU size, but clients shall accept larger U_PDUs when receiving data. 
Note that we see the U_PDUs plus the 12-byte overhead due to C_PCI, S_PCI, and RCOP/UDOP headers added by S-5066 (Fig. 4c), so - unless null bytes - likely the MTU used by this protocol is 2035-2039 bytes. It's worth noting that the U_PDUs are sent un-segmented and that the Apllication Identifier is 0x8008, that just belongs to the values which are available for user-defined applications (S-5066 Annex F, table F5).
 
Fig. 4c


The transmsission blocks at the sending S-5066 node are then splitted in un-filled "chunks" of 200 bytes length and sent to S-5066 port (Fig. 5).

Fig. 5

Indeed, looking at the hex rapresentation of an UDOP transmission block (Fig. 6) we see that the 200-byte chunks are sent twice, unless the last chunk and the first chunk of the successives data-blocks. This makes sense to improve the reliability, since the nature of UDOP protocol itself (it's a basic connection-less protocol) and the use of S-5066 non-ARQ service. 

Fig.6

*** nature of the data ***
For what concerns the nature of the data, since the {<length>,<content>} headers  are in plain-text, the encryption if any is performed upstream before this protocol.
A termed here "magic string", in the form  ZLLLL (ie "Z" followed by 4 uppercase letters), appears in the first 40 bytes of the data-block and it is always preceeded by the 34-byte sequence 0x7E0862...61D5EE20 (Fig. 7). In case of a multi-blocks transfer the magic string is present only in the first block ( Fig. 4a). So far, the seen values are: empty, ZXPBC, ZXPBD, ZRTBC, and ZRTBD. This is another unclear point and needs further observations.

Fig.7
The data obtained after the removal of the headers do not exhibit particular structures or recognizable patterns, unless the firts 40 bytes followed by the magic string. 


*** S-5066 HF network ***
For what concerns the HF network, they have tens(!) of channels. Anyway, at least from a monitoring by S4538, each channel is always used with the same RCOP/UDOP protocol.
So far, matching S-5066 addresses and src/dest headers we got:

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

[006.046.001.zzz] block
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,HEH002  006.046.001.34
CAU   006.046.001.046

In the vast majority of the cases (almost 99%) traffic is originated from 006.046.000.zzz block nodes (HWK01,ZMK002) to 006.046.001.zzz block nodes. Very few traffic in the reverse direction. Maybe 006.046.000.zzz block is assigned to the main (strategic?) nodes of the net?
Anyway, it's interesting to note that in some transmissions the same ID "HWK01" appear in both the src and dest blocks, although with different S-5066 addresses (anyway belonging to the same block 006.046.000.zzz):

Fig.8
where:
{5,HWK01}{5,HWK01} have the S-5066 addresses 006.046.000.102 and 006.046.000.028

Perhaps two possible reasons:
a) the ID HWK01 acts like a sort of ZIP-code or global-ID with different users/services, each with a distinct S-5066 Address 
b) these are two physical instances. 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.

Helps, comments and recordings are welcome!
(to be continued) 

Links:

13 June 2017

(not such) logs

06303.0: ---: Unid 1959 USB 3G-HF 2-way FLSU handshake followed by LDL32 transfer(09Jun17) (AAI)
06363.2: ---: Unid prob French Navy 0550 USB THALES HF XL modem, likely "SALAMANDRE" tests (09Jun17) (AAI)
06909.0: ABC7: Croatian Military, HRV 0737  USB MIL 188-141A call ABG6 (06Jun17) (AAI)
07401.0: ZBOR: German customs Patrol vessel Borkum, D 0732 USB MIL 188-141A call BMEK (29May17) (AAI)
07498.5: ---: Unid 0600 USB STANAG-4197 modem (31May17) (AAI)
07500.0: AI1: Polish Military, POL 1030 USB MIL 188-141A call SZ1 (28May17) (AAI)
07559.0: ---: Unid 0731 USB 3G-HF Circuit Mode in MIL 188-110A Serial (29May17) (AAI)
07559.0: ---: Unid 0800 USB 3G-HF 2-way FLSU handshake followed by HDL+ transfer (29May17) (AAI)
07628.0: A98: Unid Chinese net, C 2108 USB MIL 188-141A handshake D78 (07Jun17) (AAI)
07630.0: ---: Unid 0618 3G-HF 2-way FLSU handshake followed by LDL352 transfer, sending 675-byte Citadel encrypted data (07Jun17) (AAI)
07651.0: ---: Unid 0403 USB 3G-HF FLSU failure (02Jun17) (AAI)
07712.0: ---: Unid 0407 USB 3G-HF 2-way FLSU handshake followed by HDL12 transfer (02Jun17) (AAI)
07745.0: TBB: Turkish Navy, TUR 0617 STANAG-4285 600bps/L CARBs "//TBB040I(0)/TBB041I(0)/TBB044I(0)/TBB042I(0)/TBB043I(0)/TBB047I(0)/TBB045I(0)/TBB046I(0)/TBB048I(0)/TBB049I(0)/TBB050I(0)//" (31May17) (AAI)
07756.0: ---: Unid NATO stn 0707 ISB LINK-11 SLEW modem (29May17) (AAI)
07761.0: 6007: Unid 2024 USB MIL 188-141A sounding (09Jun17) (AAI)
07788.0: ---: Unid 0823 USB R&S GM2100 modem (06Jun17) (AAI)
07793.0: ---: Unid 0615 USB 3G-HF Circuit Mode in MIL 188-110A Serial (31May17) (AAI)
07803.0: ---: Unid French Forces stn, F 0653 (cf) ARQ-E 184.6Bd/388 modem (29May17) (AAI)
07813.0: J62 Moroccan Military, MRC 0600 USB USB MIL 188-141A sounding (06Jun17) (AAI)
07814.0: ---: Unid 0609 USB 3G-HF Circuit Mode in MIL 188-110A Serial (31May17) (AAI)
07860.0: PC21: Unid (Algerian Military?) 0612 USB MIL 188-141A call NX20 (31May17) (AAI)
07898.0: 049112: German Red Cross, D 2113 USB MIL 188-141A sounding (07Jun17) (AAI)
07899.0: XS72: Unid 0627 USB MIL 188-141A handshake NX40 followed by unid vocoder (06Jun17) (AAI)
07930.0: ---: Unid 0413 USB 3G-HF 2-way FLSU handshake followed by HDL12 transfer (02Jun17) (AAI)
08000.0: ---: Russian Military, RUS 0747 USB CIS-Makhovik BPSK 1200Bd before CIS-12 (31May17) (AAI)
08005.0: 920: Unid 2103 USB MIL 188-141A sounding (07Jun17) (AAI)
08023.0: BX80: Unid 0713 USB MIL 188-141A call NX80 (03Jun17) (AAI)
08072.0: PEM01D: French Navy, F 0645 USB MIL 188-141A call PEM05D (07Jun17) (AAI)
08151.0: TYMT2: Spanish Police Toledo, E 0628 USB USB MIL 188-141A sounding (07Jun17) (AAI)
08162.0: 035: Hungarian Army, HNG 0712 USB MIL 188-141A handshake 082, female voice comms followed by unid vocoder (10Jun17) (AAI)
08163.0: ---: Unid 0339 USB 3G-HF FLSU failure (02Jun17) (AAI)
08182.0: XGL: Unid UK-DHFCS node 0811 USB MIL 188-141A call XSS (29May17) (AAI)
08218.0: ---: Unid 0614 USB 3G-HF 2-way FLSU handshake followed by HDL12 transfer (06Jun17) (AAI)
08297.0: ---: Portuguese Air Force, POR 0742 USB STANAG-4197 (03Jun17) (AAI)
08297.0: ---: Portuguese Air Force, POR 1205 USB STANAG-4197 16-tone library only (02Jun17) (AAI)
08327.0: ---: Unid 2016 USB 3G-HF 2-way FLSU handshake followed by HDL24 transfer (09Jun17) (AAI)
08906.0: ---: Santa Maria, AZR 1953 J3E/USB wkg 9364ER (09Jun17) (AAI)
09018.3: NAVY1: Iraqi Navy HQ, IRQ 1754 USB MIL 188-141A call P103 (10Jun17) (AAI)
09018.3: P102: Iraqi Navy Patrol Boat P103, IRQ 1741 USB MIL 188-141A call NAVY2 Iraqi Navy HQ (10Jun17) (AAI)
09019.0: 220208: GBR-RAF A/c C17A 1730 USB MIL 188-141A call [?] CMD AMD [TAZ RRR6395 REQ TAF EGVN]
"to XSS (TAZ) de RAF flight 6395, request weather for Brize Norton, UK (EGVN)" (10Jun17) (AAI)
09025.0: 220208: GBR-RAF A/c C17A 1727 USB MIL 188-141A call XSS (10Jun17) (AAI)
09272.5: ---: Unid French Forces stn, F 1155 (cf) ARQ-E 184.6Bd/388 modem (29May17) (AAI)
10035.0: K36: Israeli Air Force, ISR 1356 USB MIL 188-141A call AA2 (28May17) (AAI)
10211.6: ---: Polish Intel, POL 0700 FSK 100Bd/620, 96-bit ACF (26May17) (AAI)
10590.5: ---: Swedish Armed Forces, S 0831 3G-HF Circuit Mode in MIL 188-110A Serial carrying STANAG-5066 data (31May17) (AAI)
10627.0: ---: Unid 0740 3G-HF 2-way FLSU handshake followed by HDL3 transfer (30May17) (AAI)
10638.0: EK9: Greek Military, GRC 0848 USB MIL 188-141A call GEF (29May17) (AAI)
10642.0: AC4: Unid 1730 USB MIL 188-141A call DD3 (29May17) (AAI)
10750.0: HQ4: Unid (presumed Egyptian net)1534 USB MIL 188-141A handshake GANOB5 followed by CLOVER-2000 modem and voice comms in Arabic (29May17) (AAI)
10820.0: ---: Unid 1744 USB 3G-HF Asynchronous FLSU call (29May17) (AAI)
10947.0: CAIRADIO: Unid 1504 USB MIL 188-141A sounding, also on 11300.0 KHz/USB (29May17) (AAI)
10960.0: HWK01: Swedish Armed Forces, S 1124 3G-HF Circuit Mode, MIL 188-110A carrying STANAG-5066 as bearer for unid MMHS (06Jun17) (AAI)
10975.0: 1SR: NATO BALTOPS-2017 Exercise 0650 USB MIL 188-141A call BRO (06Jun17) (AAI)
10994.2: HWK01: Swedish Armed Forces, S 1036 3G-HF Circuit Mode, MIL 188-110A carrying STANAG-5066 as bearer for unid MMHS (06Jun17) (AAI)
11022.0: ---: Israeli Navy 0710 ISRNy-HYBRID Parallel/Serial modem (06Jun17) (AAI)
11050.0: SK1: Unid (Egyptian net ?) 1343 USB MIL 188-141A call SZ1 (30May17) (AAI)
11050.0: SK1: Unid (Egyptian net ?) 1348 USB MIL 188-141A handshake SV1 followed by MIL 188-110A Serial (30May17) (AAI)
11050.0: SK1: Unid (Egyptian net ?) 1354 USB MIL 188-141A handshake XV1 followed by MIL 188-110A Serial (30May17) (AAI)
11112.0: CLC: Unid 1020 USB MIL 188-141A call CLB (11Jun17) (AAI)09018.3: BOT: Iraqi Navy HQ, IRQ 1844 USB MIL 188-141A call P104 (10Jun17) (AAI)
11112.0: CLC: Unid 1045 USB MIL 188-141A call HIC (11Jun17) (AAI)
11112.0: CLC: Unid 1232 USB MIL 188-141A call VIK (11Jun17) (AAI)
11114.5: ---: Unid 0647 USB ARCOTEL MAHRS 2400Bd serial modem (06Jun17) (AAI)
11215.0: 400001: Unid Mauretanian net, MRT 1944 USB MIL 188-141A sounding (09Jun17) (AAI)
11215.0: 400013: Unid Mauretanian Net, MTN 1750 USB MIL 188-141A call 400001 (29May17) (AAI)
11217.0: UKE303: RAF E-3 Awacs 1504 USB MIL 188-141A sounding (30May17) (AAI)
11430.0: ---: Unid 1743 USB 3G-HF 2-way FLSU handshake followed by HDL+ transfer (29May17) (AAI)
12386.0: ---: Unid 1416 Unid BPSK 62.5Bd (BPSK63 HAM) modem, encrypted msg (28May17) (AAI)
13077.1: ---: Unid USB STANAG-4285 600bps/L modem, KG-84 encrypted messages (02Jun17) (AAI)

10 June 2017

STANAG-4539 in multichannel mode: Thales HF XL modem (likely "SALAMANDRE" tests)


This system has been copied on 9 different simultaneous channels from ~6200 to ~6400 KHz on USB during 9 June morning. The analysis reveals it's a STANAG-4539 modem (frame length is 287 PSK-8 symbols) running at different data signaling rates at constant 2400Bd data rate. The system uses bursts and (possibly) ARQ mode. My friend KarapuZ too copied this system but on a different HF segment.

Fig. 1
Fig. 2

The decisive contribution for the identification of the signal came from my friend ANgazu: he suggested that these transmissions could be the Thales HFXL modem, since they use up to 16 narrowband channels in 200 Khz bw just using 4539 waveforms. Most likely, the heard transmissions are tests related to the Thales /French MOD contract: PEA "SALAMANDRE".

Indeed, as depicted in Thales presentation of the HFXL modem:
they uses an evolution from the SANAG-4539 frame structure, mainly differing in the preamble parts as shown in Figure 3 

Fig. 3
Other than the long miniproble (32 symbols length rather than 31), they added a third 124 PSK-8 symbols part (termed "Extended") to the S-4539 initial synchronization preamble. The data block length (256 symbols) and the mini probe length (31 symbols) remain unchanged so that the period counts 287 symbols as in S-4539 (Figure 2).
The extended synchronization preamble is specific to  HF XL.  This part, not included when operating according to S-4539 or MS 188-110C ISB modes, is combined with the main preamble to carry all  information  necessary  to  the  HF XL  waveform, in particular information on modulation choice for each channel. Furthermore, a specific redundancy capability is introduced, that ensures resilience to the loss of a channel as long as the number of channels is greater or equal to 3.

A deeper look at the preamble of one heard transmission confirms the Thales HF XL modem, as depicted in Figures 4,5

Fig. 4 - the whole preamble
Fig. 5 - the 124 symbols (51.6 msec) added by Thales
As further confirm, ANgazu measured the parts of the preamble (Fig. 6) and time durations fit perfectly:

Fig. 6 - parts durations in HF XL preamble
A: syncronization preamble (76 ms)
B: initial sync 287 symbols (b1 of 184 and b2 of 103 symbols)
C: extended Thales preamble (124 symbols)


The adaptive wideband HF waveform termed “HF XL” relies on the usage of several non-contiguous 3 kHz channels spread over a 200 kHz wide sub-band.


Fig. 7
Expanding on the high performance of the serial tone modem technology standardized in STANAG 4539 for 3 kHz sideband to conjugate a plurality of channels in a multi narrow band (MNB) waveform, this approach can be seen as an extension of the US MIL-STD-188-110C appendix F “ISB”, with the addition of specific redundancy capabilities to provide resistance to the highly variable HF channel conditions.  As illustrated in Figure 7, these channels do not need to be contiguous, which allows to select only good quality and authorized channels.
A 4G ALE alternate proposte ?
(see also this post)

Thanks to ANgazu for the identification and collaboration.

Links:
https://events.thalesgroup.com/euronaval/en/article/778731/SALAMANDRE-HF-with-wideband-capability 
http://www.hfindustry.com/meetings_presentations/presentation_materials/2014_feb_hfia/presentations/8-HFIAfeb2014ThalesXLALEfinal.pdf 
http://www.hfindustry.com/meetings_presentations/presentation_materials/2013_jan_hfia/presentations/8-HFIA_HF_modemXL.pdf 
http://lamyc.free.fr/publications/NORDICHF2013_1.pdf 


https://yadi.sk/d/iS9KPa-h3Jybxq

9 June 2017

5 June 2017

CIS Makhovik ("The flywheel") before CIS-12


CIS Makhovik ("The flywheel") is classified as "vocoder" but can be used also for sending encrypted data. It was originally designed to operate in the UHF but very often is found on the HF as a waveform of the AT-3004D/AT-3104D modem. In this ample (Figure 1) is possible to see the switch from the flywheel to CIS-12 waveform. The flywheel modulation can be QPSK, MSK, and PSK-2 as in this sample (speed is 1200 Baud).

Fig. 1
Fig. 1 - 425.8 msec period



31 May 2017

3G link + S5066: example of Circuit Mode (HF2000, Swedish Army)

Nice example of how to send STANAG-5066 data on a 3G link, using the Circuit Mode service provided by the 3G-HF STANAG-4538 profile.
The link is established with the 2-way FLSU procedure: the FLSU_Request PDU (BW5) sent by the caller station specifies the traffic waveforms that will be used during circuit mode, in this case MIL 188-110 (also termed MS110), and it is followed by an FLSU_Confirm PDU by the called station (not heard at my side). Once circuit mode begins, any station can initiate transmissions using the specified traffic waveform. A CSMA/CA process is used to avoid collisions. After the transfer is completed, an FLSU_Term PDU is sent by the caller and the link is terminated (Fig. 1).

Fig. 1
The most interesting aspect is the use of STANAG-5066, which has been detected thanks to the lack of the encryption before the MS110 modem: indeed, STANAG-5066 allows to indentify the Authority/Country by the addresses coded into the Data PDU (D_PDU), unless dummy addresses are used:

Once removed the overhead bits added by MS110, the D_PDUs can be isolated by syncing the resulting bitstream with the sequence 0xEB90 (regardless of type, all the D_PDUs begin with the same sync sequence): the result is displayed in Figure 2.

Fig. 2
The Size-of-Address Field specifies the number of bytes in which the source and destination address are encoded, the address field may be from 1 to 7 bytes in length (as in this case), with the source and destination address of equal length.The first half is the destination address and the second half is the source address:

In this case:
source address: 006.046.000.028
destination address: 006.046.001.010
both belonging to the block 6.46.x.y allocated to Sweden (Table N-6 European National Addressing Schema):

Fig. 3
Almost surely it is the HF2000 System developed by the Italian "Marconi Selex" company:

The user data carried by D_PDUs are structured in a 8-bit code (Fig. 4):

Fig. 4
By the way, the transmission has been copied on 10590.5 KHz/USB and thanks to S5066 Addresses this is the firts time I identify a 3G-HF transmission.
(to be continued here)



28 May 2017

short log


 
05825.0: ---: Ukraine Militay, UKR 0618 USB MFSK-4 (double FSK) 100Bd 500Hz,(tones at -750, -250, +250, +750) (18May17) (AAI)
06547.0: SHANWICK: Shanwick MWARA IRL 2023 USB/J3E ATC in comms w/004 (17May17) (AAI)
06873.5: XEN: Unid UK-DHFCS node, UK 2054 USB MIL 188-141A handshake w/XSS followed by MIL 188-110A Serial (17May17) (AAI)
07505.9: XLA: Unid 0808  USB MIL 188-141A call to XLB (19May17) (AAI)
07510.0: HI9: Polish Military, POL 0751 USB MIL 188-141A call to HE5 (19May17) (AAI)
07510.0: HI9: Polish Military, POL 0908 USB MIL 188-141A call TU9 (22May17) (AAI)
07559.0: ---: Unid 0741 3G-HF 2-way FLSU handshake followed by LDL320 sending 591 bytes Citadel encrypted datagram (20May17) (AAI)
07594.5: OEY: Austrian Army, AUT 0848 USB MIL 188-141A call OEY61 (22May17) (AAI)
07605.0: LEONE1: Italian Air Force airborne, I 0754 J3E/USB in comms with ground "take off at 52" (22May17) (AAI)
07628.0: PI: French Navy ODPI Toulon, F 1141 J3E/USB in comms w/FLA, QSLing RATT 75Bd/850 KG-84 encrypted message sent from FLA (QSL de votre message) (20May17) (AAI)
07655.0: RAM: Roumenian Police Ramnicu Valcea, ROU 0831 USB MIL 188-141A call to 1PY (18May17) (AAI)
07655.0: VAS: Roumenian Police Vaslui, ROU 0837 USB MIL 188-141A call to 1PY (18May17) (AAI)
07669.0: ZM55: Unid (presumed Algerian Mil.) 1603 USB MIL 188-141A LQA Request Response to NX50 (20May17) (AAI)
07669.0: ZM66: Unid (presumed Algerian Mil.) 1600 USB MIL 188-141A LQA Request Response to NX50 (20May17) (AAI)
07669.0: ZM68: Unid (presumed Algerian Mil.) 1608 USB MIL 188-141A  2-way LQA exchange w/NX50 (20May17) (AAI)
07711.6: ---: Unid 0730 (cf) continuous RATT 75Bd/850 (20May17) (AAI)
07754.0: Z01: Unid, prob. Polish Military 0845 USB MIL 188-141A call KA1 (22May17) (AAI)
07765.0: BX80: Unid 0736 USB MIL 188-141A LQA Request Response to NX80 (20May17) (AAI)
07766.5: B10: Unid, prob. Ukrainian net 2012 USB MIL 188-141A sounding (17May17) (AAI)
07830.0: WG01: Algerian Military, ALG 0912 USB MIL 188-141A call NX01 (22May17) (AAI)
07890.0: KB15: Unid (presumed Algerian Mil.) 1546 USB MIL 188-141A 2-way LQA exchange w/NX10 (20May17) (AAI)
07890.0: KB17: Unid (presumed Algerian Mil.) 1545 USB MIL 188-141A 2-way LQA exchange w/NX10 (20May17) (AAI)
07890.0: KB20: Unid (presumed Algerian Mil.) 1543 USB MIL 188-141A 2-way LQA exchange w/NX10 (20May17) (AAI)
07899.0: NX40: Unid (presumed Algerian Mil.) 1247 USB MIL 188-141A LQA Request Response to XS62 (21May17) (AAI)
07899.0: XS54: Algerian Military, ALG 1556 USB MIL 188-141A LQA Request Response to NX40 (20May17) (AAI)
07937.0: EVW: Unid 1508 USB MIL 188-141A handshake w/TJ4 (20May17) (AAI)
07945.5: ANOUAL2: Moroccan Military, MRC 2018 USB MIL 188-141A sounding (17May17) (AAI)
07964.0: ZM60: Unid (presumed Algerian Mil.) 1519 USB MIL 188-141A LQA Request Response to NX50 (20May17) (AAI)
07964.0: ZM60: Unid (presumed Algerian Mil.) 1519 USB MIL 188-141A LQA Request Response to ZM40 (20May17) (AAI)
07964.0: ZM64: Unid (presumed Algerian Mil.) 1530 USB MIL 188-141A LQA Request Response to NX50 (20May17) (AAI)
08020.0: 88: Italian Air Force C-27J Spartan "MM62214 46-88", I  0914 USB MIL 188-141A call CHARLY46 (22May17) (AAI)
08023.0: BX80: Unid 0739 USB MIL 188-141A LQA Request Response to NX80 (20May17) (AAI)
08023.0: FQ71: Unid 0813 USB MIL 188-141A LQA Request Response to NX80 (20May17) (AAI)
08034.0: ---: Unid 0808 3G-HF 2-way FLSU handshake followed by Circuit Mode service using MIL 188-110A Serial (20May17) (AAI)
08061.0: RK37: Unid (presumed Algerian Mil.) 1551 USB MIL 188-141A LQA Request Response to NX30 (20May17) (AAI)
08162.0: 035: Ungarian Military, HNG 1514 USB MIL 188-141A LQA Request Response to 093 (20May17) (AAI)
08190.0: CAVATORTO: Italian GdF patrol boat, I 0723 USB MIL 188-141A call to BARBARISI (17May17) (AAI)
08195.0: 1PY: Roumenian Police, ROU 0729 USB MIL 188-141A 2-way LQA exchange with SIB Sibiu (22May17) (AAI)
08582.0: P52: Moroccan Military, MRC 2048 USB MIL 188-141A sounding (17May17) (AAI)
08582.0: X42: Moroccan Military, MRC 2048 USB MIL 188-141A sounding (17May17) (AAI)
09044.0: ---: Unid, prob. Russian Mil/Diplo 1257 (cf) FSK 300Bd/500 360-bit ACF (18May17) (AAI)
09274.0: ---: Unid 1155 (cf) RACAL MA4248 "MEROD" FSK 266.7Bd/800 bursts, call to @VW96G61B (15May17) (AAI)
10225.5: ---: Unid 0929 USB Unid QPSK 2400Bd burst system, 180-bit ACF (modified Stanag-4539 TDMA?) (23May17) (AAI)
10425.0: ---: (no call) Unid 0714 USB MIL 188-141A LQA Request Response to 1VR (20May17) (AAI)
10853.5: XCF: Unid UK-DHFCS node, UK 1318 USB MIL 188-141A call to XSS (18May17) (AAI)
10935.5: ---: Unid 0921 USB MIL 188-141A Linking Protection mode handshake followed by MIL 188-110A Serial modem (23May17) (AAI)
11032.0: ---: Unid (presumed Bulgarian Diplo) 0830 USB RFSM-8000 with data-masking (22May17) (AAI)
11050.0: ND1: Unid 1457 USB MIL 188-141A handshake w/SK1 followed by MIL 188-110A Serial (19May17) (AAI)
11165.0: AOS: Algerian Air Force Ain Oussera, ALG 0802 USB MIL 188-141A call CM1 (22May17) (AAI)
11430.0: ZRO: NATO NCS 0809 USB MIL 188-141A call STM (23May17) (AAI)
11430.0: ZRO: NATO NCS 0828 USB MIL 188-141A call ACR (23May17) (AAI)
11543.0: ---: Unid 0751 USB 3G-HF 2-way FLSU handshake followed by HDL+ (22May17) (AAI)
13110.0: ---: Unid, prob. Russian Mil/Diplo 1330 (cf) FSK 300Bd/500 360-bit ACF (18May17) (AAI)
13560.0: ---: Russian Navy, RUS 0739 (cf) CIS Navy "Akula", FSK 500Bd/1000 (23May17) (AAI)
15040.0: 240: Unid 1342 USB MIL 188-141A sounding (18May17) (AAI)
15858.0: MHFCS network, AUS 1350 ISB, GFSK 600Bd/340 on LSB & FSK 50Bd/340 on USB (17May17) (AAI)
17409.5: ---: Uk Mil/Gov, UK 0728 USB WINDRM modified waveform OFDM 51-tone (23May17) (AAI)


26 May 2017

FSK 100Bd/620, Polish Intel

update (26May17)

This morning I copied a transmission on 10211.6 KHz/USB with same ACF (96 bit) but with different frame structure that exhibits a sort of 24-bit length "preamble" followed  by 16-bit length data blocks (8+8 UK) and resembling, in some way, the Stanag/MIL-STD framing.



https://yadi.sk/d/jJ_1leZR3JYWKW

  

FSK 100Bd/620, Polish Intel (10Feb16)


FSK-2 modulation with 620 Hz shift and 100 Baud speed, in use by Polish Intel service.

pic. 1 - baudrate and shift
The signal exhibits clean ACF spikes at 96 bits (~960ms lenght). Looking more closely one can distinguish six periods of 16 bits, most likely they represent a five digits code and a separator between the groups as also shown in the bitstream (pic. 3).

pic. 2 - 96 bits ACF (6 x 16 bits digits)
.
pic. 3
Looking at the whole demodulated bitstream (pic. 4), although inclusive of the overhead bits, we can get an idea of the signal structure. First of all, note that the ACF is due to the final part "D" and then does not characterize the entire signal but only a part. While the parts A and E can be assumed as the 'start' and 'end' of transmission, it's difficult to fix the roles of the other groups: message, destination address, coded-instructions and so on. Talking with my friend KarapuZ, he says we need much more recordings for statistic comparisons since a previous recording of 2014 just exhibits that same characteristics. And if he says so...

pic. 4