29 October 2017

Maritime Interdiction Operations (MIOs) in Med'sea, a joint exercise?


The heard communications concern a Maritime Interdiction Operation (MIO) in Mediterranean sea and involve 2 vessels and one ashore station which acts as the net-control station by coordinating all the activities. It is not clear if  the heard activity is part of a routine patrol or rather a naval joint exercise. The ALE IDs used in communications (ie "CMOC", that could stands for Combined Maritime Operation Center), some terms in the messages (such as PUBEX, EVOLEX) and the "special" email domain name (here not reported for confidentiality) make me think to a MIO joint exercise. By the way, I did not find any related news in some specialized websites neither in press-agency sites.
The activity was heard on 7 and 8 MHz bands, expecially on 27 October. Communications  make use of 188-141 2G ALE for link setup while the messages are sent using a battle force email system based on STANAG-5066 HBFTP protocol. STANAG-4539/MS-110A are used as bearer HF waveforms, mostly QAM-64 9600bps and PSK-8 1200bps modulations (Figs 1,2). The STANAG-5066 addresses of the network nodes belong to the dummy block 10.000.000.zzz  which is not assigned to a country.
The language used for working out operational documents and for communications is English and French, this could be another hint in favour of a joint exercise.

Fig. 1 - STANAG-4539 transfer using QAM-64
Fig. 2 - STANAG-5066 stream
In addition to text or routine messages such as request to compress photos ("compresser la photo svp"), link informations ("liaison XXX to YYY par HF est nulle") or some ehortations ("veilles respecter le battle rythme et nous transmettre la situation RMP TN/DZ et vos position 12h00"), I saw some operational messages that are worth seeing. Although it could be a joint exercise, I avoid to go into details and some parts of these messages, as well as callsigns, are obscured or omitted for reasons of confidentiality of sensitive information. 

The firts two messages are related to the operation (tactical instructions?) and to the use of the MIO Board.

Fig. 3
Fig. 4
In Fig.5,  looks like they send informal ACP-like messages using email: note the from CMOC (Combined Maritime Operations Center?) to OTC (Operational Training Center?) header

Fig. 5
The operation was successull since the report on the interception of a boat of narcotrafficants (Fig. 6). Drug smugglers have thrown the material off at sea but it has been recovered by the navy sailors. Note how such reports are rigidly formatted in sections (termed "alfa", "bravo", "charlie") and sub-sections.

Fig. 6
Note also that in some messages, likely the more important ones, they make use of return receipts, as indicated by the MDN (Message Disposition Notification) tags in the email shown in Fig. 7 (turnaround time of 31 secs.). I saw MDNs in both English and French language.

Fig. 7
Many joint exercises (Phoenix Express, Morjane, Osis, MEDEX,...) take place every year in Souther Med'sea, so what I heard could be an ad-hoc scenario just established for this exercise.

update: 31 October 2017

...as expected:
http://en.aps.dz/algeria/20899-naval-force... 


21 October 2017

strong 4+4 π/4 DQPSK 75Bd Chinese modem


Strong copy of the 4+4 DQPSK 75Bd Chinese modem on 17149.7 KHz/USB at 0915, 1128 and 1129 UTC.

Fig. 1
Fig. 2
Fig. 3
Note the different periods in preamble, 36-bit length, and data segments, 12-bit length: most likely a 6-bit structure signal with 1 stop bit (Fig. 6)

Fig. 4 - 36-bit period in the preamble segments
Fig. 5 - 12-bit period in the data segments
Fig. 6 - 6-bit signal

The same signal was also heard few hours later (around 1130z) at -91dB and no QSB: too good conditions for a signal coming from China:


By the way, the Algerian Navy recently acquired three C28A Corvettes built in China [1] by Hudong-Zhonghua Shipbuilding Group, a subsidiary of China State Shipbuilding Corporation, this could explain the strength of the signal.

[1]http://www.defenceweb.co.za/...Sea&Itemid=106 

20 October 2017

BPSK 4800,9600,19200Bd 6,12,24 KHz (Marine Band)

Other WideBand burst waveforms spotted in HF Marine band: speed 4800, 9600 and 19200 Baud, bandwidth  6, 12 and 24 KHz.

Fig. 1 - 16625.0 KHz/USB
Fig. 2 - 16657.0 KHz/USB
Still uncertain whether these transmissions concern the over-the-air tests of KNL Networks CNHF (Cognitive Networked HF) system, as they illustrated in their presentation slide of this system (Fig. 3), or perhaps a real-world testbed/implementation.

https://yadi.sk/i/7bcD0sWZHqF6sw
 Some info about CNHF system can be read in their website.



19 October 2017

Radio Teleswitch, an example of AM Signalling System (AMSS)
(by ANgazu)

BBC Radio-4 (LF 198 Khz) is a radio station that broadcasts a great variety of programs. At first glance, it looks like any other AM commercial emitter, but there is a feature that makes it different: its carrier is PSK modulated, transmiting  data to switch electric meters and consumer appliances to take advantage of best electric tariffs [1].
This sample was recorded using TWENTE sdr in USB mode so to preserve the carrier, its spectrogram is as any standard AM broadcast (Fig. 1) and it's occupation is about 12 Khz as most AM comercial stations.

Fig. 1
When zooming on carrier (Fig. 2), there is a  signal using about 50 Hz BW on each side of the carrier and once filtered, the modulation speed is 50 symbols/sec (Fig.3).

Fig. 2
Fig. 3
In this case, carrier is the AM carrier so we  can go to  the signal constelation that shows that the carrier phase is shifted  ±  22.5º (Fig. 4). This small shift is suitable  for retrieving data and is small enough to avoid interferences with the intended AM signal.

Fig. 4
To  demodulate this signal, you have to filter out the carrier and proceed as in any BPSK signal. ACF is about 2 seconds, this means that there are 30 frames within each second and everyone carries 100 bits. Signal is "manchester" coded so we will have 50 bits of information per frame (Fig. 5). The signal is idling most of the time (01010101…) 

Fig. 5

[1]

14 October 2017

BPSK & QPSK 2400Bd, QPSK 1500Bd, ARQ system (Maritime Band)


Robust ISB SDR ARQ system heard on 6231.5 KHz/USB (Maritime Mobile band) 2800Hz offset from carrier, around 0630z on 12 October and in which the two channels are used as follows:

- on USB upper channel: user data transfer using adaptive 2400 Baud PSK-2 and QPSK burst waveform, according to the channel conditions and the feasible data-rate. Initial bursts use PSK-2 modulation at 2400 Baud;  
- on LSB lower channel: link and traffic management (ACKs and mode used for data transfer) using 1500 Baud PSK-2/QPSK waveform; 

is not clear if the change of the mode used for data transfer is signaled in the management channel by the caller or it is requested by the called station.

Fig. 1 - user data transfer waveform (upper channel)
Fig. 2 - link and traffic management waveform (lower channel)

At least in this sample, data bursts last 2088 msec for PSK-2 and 3144 msec for QPSK, the initial bursts have a duration of 520msec; link and traffic management bursts last 310 msec. PSK-2 and QPSK data bursts exhibit strong ACF spikes every 523 msec which suggest a 1256 symbols frame structure (Fig. 3); initial data bursts have ACF = 0, probably Walsh modulation is used (Fig. 4).

Fig. 3
Fig. 4
Together with IK1YDE we studied the bitstreams after PSK-2 and QPSK demodulations and found a frame structure similar to those provided by the recent MS-110 Appendix C for the waveforms ID 5 and 6 (Fig.5). Indeed both PSK-2 and QPsK frames consist of 288 symbols (Fig. 6): 32 knwon symbols (mini probes) followed by 256 unknown (data user) symbols. It must be noted anyway that the data rate of the analyzed waveform (in its USB channel) is 2400 Baud and doesn't match the one provided by the waveforms 5 and 6 of MS-110 App.C.
Most likely the 1256-bit ACF is due to the length of the interleaver or the scrambler sequences.

Fig. 5
Fig. 6 - data bits and symbol numbers

A similar system was heard on 5 November 2016: in that case ACK burst were sent after each BPSK data burst (Figs. 7,8)
.
fig.7
fig.8

Talking with KarapuZ about this system, he suggested a SDR equipment rather than a ISB mode (I edited the text of the post accordingly) and proposed to have a look at the KNL Networks website since they are testing a proprietary 3G HF hybrid system (termed CNHF) to support the ship traffic in Artic regions [1]. In that high latitudes satcomm links can't be easily used since geostationary satellites do not cover these areas, moreover due to the long dark periods the low portion of HF shall be used (lack of F layers). Perhaps may catches are related to their tests... but it's only my guess (I emailed them to ask a confirm and maybe shed some ligth on this system).





TADIRAN HF modem running in scrambler mode

Tadiran/ElbitHF modem, probably the HF-6000 model, running in COMSEC mode using FSK 125Bd/300Hz Digital Coded Squelch (DCS) and scrambled voice-comms. Transmission heard on 5885.0 KHz/USB at 0755z with a very poor SNR. The sample marked as "A" is the "autocall" waveform: it precedes the MFSK/scrambler sessions, marked as "B", and terminates the link (Figure 1).
Fig. 1
The FSK segmentes (the DCS part) sent during the scrambled voice-comms have a speed of 125Bd and 300Hz shift, ie same parameters of the F7B (apparently MFSK-4) waveform, and cosists of 84 bit repeated strings:

Fig. 2

Fig. 3

12 October 2017

OFDM modem 12+12 tones 48Bd (Marconi 25-tones)


Probably a simplex transmission heard on 6246.5 KHz/USB. Although the SNR is poor, it's possible to see a central un-modulated tone a + 1500Hz  that splits the signal in two identical parts which I analyzed separately. The results show an OFDM modulation of 12 + 12 tones at a rate of 48 symbols/sec; the on-air constellation seems to be QPSK on each channel.

Fig. 1
Fig. 2
Fig. 3
 The initial part exhibits an upper un-modulated tone and a short FSK

Fig. 4

 Modem name and users are unknown to me.

Update:
thanks to hf_linkz who pointed me to the correct identification of this modem: it's the "Marconi 25-tones" as depicted here:
http://signals.radioscanner.ru/base/signal125/ 
https://www.sigidwiki.com/wiki/Marconi_Selenia_25-Tone_Modem  





THALES mention

happy to be mentioned by THALES in their HFXL modem "Sea Trials" presentation during the last HFIA meeting in Kjeller Norway on 8 September 2017. Thanks to Catherine LAMY-BERGOT, from THALES, who kindly asked the permission to use the material from my blog.
The whole presentation HFXL Sea Trials on French BPC, as well as other works, can be downloaded from here:
http://www.hfindustry.com/meetings_presentations/2017_sep_hfia.htm


 




11 October 2017

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): 
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