MS188-110: probe designation symbols D1-D2 and 200ms ACF

in a previous post I already talked about the way MS188-110 scrambler length affects the value of the ACF at certain data rates. Now I want verify the typical 200ms ACF  of a 2400 bps data rate (short interleaver): as seen in the above post, this ACF value is also met at other data rates along with the 66ms value.  Summarizing:

• In case of low data rates (from 150 up to 1200 bps) four groups of the pairs data + probe (Unknown + Known) count 160 symbols (4 x 40) and they are just in sync with the scrambler length (160 symbols) causing the strong 66.67mS ACF.
• In case of the lowest speed (75bps data rate) the channel probes are not sent so the 66.67mS ACF is just due to the scrambler length (160 symbols).
• In case of 2400 bps the pair probe+data counts 48 symbols (32+16 UK) and this value is not correlated to the the scrambler length, so the "visible" ACF in this wavfeorm, and in 4800 uncoded, is the 200 mS or 480 symbols.

pic. 1

So, why the 480 symbols ACF rather than the expected 48?

pic. 2 - strong 200ms ACF spikes in a MS188-110 signal

The short interleaver matrix dimension for 2400 bps speed consists of 40 rows and 72 columns i.e. 2880 bits and is loaded in 600 ms. This means that from the short interleaver matrix we get 960 symbols that in turn will be transmitted into 30 data blocks (Unknown data) each consisting of 32 symbols and followed by a known 16 symbols sequence (probe or Known data). That said, the lenght of one transmitted interlever block is 1440 symbols or 30 UK frames (32+16).

The period of the demodulated stream (pic.3) is 1440 bit lenght (not symbols!), just 10 UK frames, which are well visible in pic. 3. It's worth noticing that the patterns of the last two probes (yellow circled) exhibits a certain discontinuity that is not present in the patterns of the middle probes. Also notice that 3 rows identify 1 interleaver block!

pic. 3 - 1440-bit period

The reason is in the way the last two probe are formed (pic. 4). Quoting MIL-STD 188-110 - 5.3.2.3.7.1.2 Known data: "During the periods where known (channel probe) symbols are to be transmitted, the channel symbol formation output shall be set to 0 (000) except for the two known symbol patterns preceding the transmission of each new interleaved block. When the two known symbol patterns preceding the transmission of each new interleaver block are transmitted, the 16 tribit symbols of these two known symbol patterns shall be set to D1 and D2, respectively, as defined in table XV of 5.3.2.3.7.2.1 and table XVII of 5.3.2.3.7.2.2. The two known symbol patterns are repeated twice rather than four times as they are in table XVII to produce a pattern of 16 tribit numbers."

(The three bit values of D1 and D2 also designate the bit rate and interleave setting of the transmitting modem during the Sync preamble sequence)

 

pic. 4

In my opinion the patterns of the last two probes of each interleaver block - or better the Designation Symbols D1, D2 - cause the 1400-bit/200ms ACF since they act as a kind of autocorrelation sequence (pic. 5)

 

pic.5 - the 10 interleaver blocks

Its worth noting that the 66.67ms ACF visible at lower data rates (due to the scrambler length) corresponds to 480 bits and this value is a submultiple, exactly 1/3, of the 1440 bit period that is due to the Designation Symbols D1,D2. These two matters concurr to the two ACF spikes which are visible, for example, in the 150bps data rate waveform (pics. 6,7).

pic.6

pic.7

playing with MARS-ALE v3.00 and FS-1052 DLP messaging

MARS-ALE is a Personal Computer based 2G-ALE Modem and Controller that in conjunction with a supported computer controllable HF SSB transceiver allows for HF ALE communications. MARS-ALE also provides an implementation of FED-STD 1052 (FS-1052) Appendix B, DLP Data Link Protocol, running over the integral software defined MS188-110A modem on the PC Sound Device. The latest MARS-ALE v3.00 and MS-DMT (MIL-STD Data Modem Terminal) versions can be downloaded from here: 

www.n2ckh.com/MARS_ALE_FORUM/MA300B1000_TB5_1_7_4FI.zip

www.n2ckh.com/MARS_ALE_FORUM/MSDMT32v101B1011_FI.ZIP 

When used in conjunction with other programs such as Audacity, Signals Analyzer, MS-DMT and BEE (a bitstream editor), MARS-ALE is a great tool for practicing with MS188-110 ST and FS-1052 DLP waveforms: digital signal enthusiasts can prepare clear and clean waveforms for study, analysis and comparisons with real-world signals. Below is a  short FS-1052 DLP messaging example just to show and understand the educational possibilities offered by MARS-ALE.

Modem Type and Data Mode settings are configured as follows (pic. 1,2)

Pic. 1 - MS188-110 messaging settings

Pic. 2 -FS-1052 DLP messaging settings

As expected, since the overhead added by FS-1052 DLP the lasting of this transmission is longer than MS-188-110 SYNC sending the same message and at the same data rate (pic. 3)

 

Pic. 3 - lasting of the two transmissions

 

In pictures 4,5 I run two MARS-ALE sessions, acting as the transmitting an receiving modems,  linked by a virtual cable: since FS-1052 DLP is a Data Terminal protocol, no portions of the message are printed until the entire message is received error free.

Pic. 4 - entering the message to be sent via MS188-110 + FS-1052 DLP

Pic. 5 - transmitting and receiving modems

For the same reason, it's very interesting to note that a plain MS188-110 receiving modem, as for example MS-DMT modem, does not print any message in its output screen unless the HEX string "5C 5C 5C D3 00 00 00 00 00 00 00 00" (pic. 6) and that is just the frame sync pattern used to mark DLP processed traffic.

Pic. 6 - MS-DMT modem facing a FS-1052 DLP transmission

From FED-STD 1052 App.B "50.1.1.1 Frame sync pattern":  Each new transmission over the physical channel shall begin with a three byte (24-bit) frame synchronization pattern to identify the following traffic as DLP processed traffic. The frame synchronization sequence in hexadecimal format, shall be "5C5C5C". The sync pattern shall be transmitted such that the first eight bits in order of transmission are "00111010". Note: As shown here in transmission sequence, the left-most bits are the LSBs.

The FS-1052 DLP frame sync pattern can be easily seen by processing the ASCII-bits file obtained from the output of a common MS188-110 decoder as Sorcerer used in this example (pics 7,8): this way we get the bistream after removed the MS188-110 stuff

Pic. 7 - bistream after MS188-110 removal

Pic. 8 - FS-1052 DLP frame sync pattern

If a transmission contains more than one frame, a two-byte sync sequence shall be inserted between each pair of adjacent frames: this pattern (hexadecimal) is "5C5C" (pic. 9)

Pic. 9 - two-byte sync sequence between frames

The sync sequences, along with other control bits and CRC, are also visible looking at the output of the ASCII parser of the bitstream editor: note the lack of such bits in a plain MS188-110 transmission (pic. 10)

Pic. 10

From FED-STD 1052 App.B "50.1.1.5 CRC error control checksum": a 32-bit CRC following the Frame Headers and Data field shall conclude each protocol frame. After initially setting all 32 bits to one, the CRC shall be calculated using all bits of the frame starting with the Sync Mismatch bit and ending with the last bit of the Frame Headers and Data field. The generator polynomial for the CRC calculation shall be:

 x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1

After removed the sync patterns out from the bitstream, I tried to find all the possible 32-bit polynomial which match with the data length and CRC bits.. but it's a long time consuming procedure and I stopped it just after the first results (pic. 11)

Pic. 11 - find the CRC polynomial

Another interesting MARS-ALE tool is the TRACING dialogue (pic. 12). This feature provides seven check boxes to enable/disable the display of data related to Received (RX) Words, Transmitted (TX) Words, program States, program Events, program Commands, program Timers and FS-1052 parameters as shown in pic. 13.

Pic. 12 - the "tracing" dialogue

Pic. 13 - tracing FS-1052 DLP at work

FS-1052 DLP is typically implemented in computer software applications and not in the hardware modem, however some tactical radios do implement an embedded 1052 ARQ and Broadcast capability. 

Historically, in MIL-STD-187-721C, “Interface and Performance Standard for Automated Control Applique for HF Radio,” Appendix A (USAISEC TECHNICAL REPORT “ HFDLP HF DATA LINK PROTOCOL”) is provided which specifies HFDLP for use with MS188-110A.

logs

05320.0 ---: Unid 0621 USB STANAG-4197 (08Apr16) (AAI)
07102.0 9A0MIL: Global ALE HF Network Zagreb, HRV 0613 USB MIL 188-141 2G-ALE sounding (15Apr16) (AAI)
08010.0 ---: Ukraine Mil, UKR 0620 (cf) MFSK-4 (double FSK) 100Bd 500Hz, (tones at -750, -250, +250, +750 Hz) (19Apr16) (AAI)
08132.0 BP21: German Police vessel Bredstedt, D 0632 USB MIL 188-141 2G-ALE calling BPLEZS (19Apr16) (AAI)
08132.0 BP25: German Police vessel Bayreuth, D 0634 USB MIL 188-141 2G-ALE calling BPLEZS (19Apr16) (AAI)
09239.8 ---: Unid 0815 (cf) FSK 100Bd/1000 not sending data (08Apr16) (AAI)
10170.0 OCI: Slovakian Mil, SVK 0643 USB MIL 188-141 2G-ALE calling SIP (13Apr16) (AAI)
10226.8 ---: Unid (prob Finnish Intel) 0814 (cf) Nokia MSG-Terminal FSK 301Bd/780 (13Apr16) (AAI)
10246.0 F11: Polish intel, POL 0700 USB  POL-FSK 100Bd/740 (22Apr16) (AAI)
10275.0 4236: Sonatrach, ALG 0730 LSB MIL 188-141 2G-ALE sounding (13Apr16) (AAI)
10315.0 ---: MAECT Bucuresti, ROM 0756 USB MIL 188-110 serial carrying zipped test email via STANAG-5066 HBFTP client (18Apr16) (AAI)
10315.0 ---: Unid (prob. NATO station) 0650 USB MIL 188-110 Serial carrying KG-84 encrypted data (13Apr16) (AAI)
10333.0 RCI: Saudi Air Force, ARS 1622 ISB MIL 188-141 2G-ALE calling NAI (13Apr16) (AAI)
10417.5 B10: Ukrainian x10 net, UKR 1353 USB MIL 188-141 2G-ALE sounding (13Apr16) (AAI)
10417.5 C10: Ukrainian x10 net, UKR 1601 USB MIL 188-141 2G-ALE sounding (13Apr16) (AAI)
10417.5 J10: Ukrainian x10 net, UKR 1623 USB MIL 188-141 2G-ALE sounding (13Apr16) (AAI)
10569.7 RFAL4: Unid net 1611 USB MIL 188-141 2G-ALE calling RFAL2 (13Apr16) (AAI)
10658.0 4017: Turkish red crescent TUR 0701  USB MIL 188-141 2G-ALE calling 3010 (22Apr16) (AAI)
10668.0 ---: Unid 0702 USB Arcotel MAHRS-2400 ALE burst (22Apr16) (AAI)
10677.0 RHI: Saudi Air Force, ARS 1628 ISB MIL 188-141 2G-ALE calling AAI (13Apr16) (AAI)
10724.0 ---: Iranian net, IRN 1557 (cf) Iranian-QPSK 468.75Bd (13Apr16) (AAI)
10729.0 ---: Unid (prob. V22) 1230 (cf) PSK-2 62.5Bd, 3 mins lasting (20Apr16) (AAI)
10750.0 GANOB1: GMRA net, LYB 1614 USB MIL 188-141 2G-ALE calling HQ1 (13Apr16) (AAI)
10750.0 GANOB10: GMRA net, LYB 1614 USB MIL 188-141 2G-ALE calling HQ1 (13Apr16) (AAI)
10786.0 ---: Unid 1545 USB STANAG-4197 modem (13Apr16) (AAI)
10790.0 152: Unid net 1615 USB MIL 188-141 2G-ALE sounding (13Apr16) (AAI)
10888.0 ---: Russian Navy, RUS 0705 (cf) CIS-Akula FSK 500Bd/1000 bursts (22Apr16) (AAI)
10980.0 ---: Chinese Mil, CHN 1617 LSB Chinese OFDM 30-tone bursts (13Apr16) (AAI)
11010.0 ---: Unid 0810 USB Arcotel MAHRS-2400 ALE burst (22Apr16) (AAI)
12394.0 ---: Unid 0746 USB Arcotel MAHRS-2400 ALE burst (22Apr16) (AAI)
12736.0 ---: Unid (prob Russian AF) 0620 (cf) FSK 100Bd/800 not sending data (13Apr16) (AAI)
12935.0 HLG: Seoul Radio, KOR 1455 CW "CQ de HLG QSX 12 MHz K" (09Apr16) (AAI)
13499.0 1114: Unid (prob. Moroccan Civil Protection, MRC) 1433 USB MIL 188-141 2G-ALE sounding (09Apr16) (AAI)
13514.0 ---: Israeli Navy, ISR 1440 USB hybrid HF modem (09Apr16) (AAI)
13538.0 ---: Russian Mil, RUS 0640 USB CIS-45 OFDM HDR modem_v2 40Bd BPSK (19Apr16) (AAI)
14421.0 BAL: Algerian AF, ALG 0823 USB MIL 188-141 2G-ALE calling CM3 (21Apr16) (AAI)
14489.5 ---: Unid (prob Russian Gov.) 0615 (cf) FSK 100Bd/2000 (13Apr16) (AAI)
14590.0 ---: Unid 0915 USB Arcotel MAHRS-2400 ALE burst (09Apr16) (AAI)
14672.0 ---: Russian Navy, RUS 0803 USB AT-3004D modem + CW opchat on 2^ channel "QRJ ? K" "QJB3 K" (09Apr16) (AAI)
14925.0 ANK: Finland MFA (prob. Embassy Ankara, TUR) 1147 USB MIL 188-141 2G-ALE calling HKI2 Helsinki (14Apr16) (AAI)
14925.0 HKI2: Finland MFA Helsinki, FNL 1143 USB MIL 188-141 2G-ALE calling ANK (prob. Embassy Ankara) (14Apr16) (AAI)
14925.0 HKI3: Finland MFA Helsinki, FNL 1209 USB MIL 188-141 2G-ALE calling ANK (prob. Embassy Ankara) flwd by SKY-OFDM 22-tone data (14Apr16) (AAI)
16161.0 5601:  Iranian AF, IRN 0936 USB MIL 188-141 2G-ALE calling 20001 (15Apr16) (AAI)
16175.0 ---: Russian AF, RUS 0700 USB VFT 3 x 100Bd/1450 + extra tone at ~3440Hz (pilot?) (19Apr16) (AAI)
16230.0 ---: Russian Intel, RUS 0830 (cf) CIS FTM-4, MFSK-4 150Bd (effective 37.5Bd) 4000Hz (tones at: -6, -2, +2, +6 KHz) 8 minutes lasting (22Apr16) (AAI)
16240.0 1326: Unid (prob.  Moroccan Civil Protection, MRC) 0811 USB MIL 188-141 2G-ALE sounding (21Apr16) (AAI)
16283.6 KVX53: US Dept of State station 0802 USB MIL 188-141 2G-ALE calling KVX51 (21Apr16) (AAI)
16283.6 KVX53: US Dept of State station 0818 USB MIL 188-141 2G-ALE calling KVX99 (21Apr16) (AAI)
16468.1 PHR: Unid network 0717 USB MIL 188-141 2G-ALE calling SHL (21Apr16) (AAI)
16468.1 PHR: Unid network 0725 USB MIL 188-141 2G-ALE calling GUN (21Apr16) (AAI)
16468.2 GUC: Unid network 1559 USB MIL 188-141 2G-ALE calling SHL (15Apr16) (AAI)
16468.2 GUN: Unid network 1304 USB MIL 188-141 2G-ALE calling SHL (15Apr16) (AAI)
16468.2 GUN: Unid network 1310 USB MIL 188-141 2G-ALE calling PHR (15Apr16) (AAI)
16468.2 PHR: Unid network 1313 USB MIL 188-141 2G-ALE calling GUN (15Apr16) (AAI)
16766.5 ---: Unid 1340 (cf +1500Hz USB) SiTOR-A 100Bd/170 "538678 STRN XTEST+ TST+TEST" (17Apr16) (AAI)
17415.0 ---: MFA Cairo, EGY 1325 USB (cf +1700 USB) SiTOR-A 100Bd/170 calling IPTX Havana (08Apr16) (AAI)
17912.0 014: ARINC Krasnoyarsk, RUS 1209 USB HFDL, working flight UP0003 (10Apr16) (AAI)
18350.0 LEB: Unid network 0702 USB MIL 188-141 2G-ALE calling KUL (15Apr16) (AAI)

email over HF using STANAG-5066 DTS: a more interesting example

This recording is another example of sending compressed e-mail file using STANAG-5066 DTS and the MS188-110A serial waveform as "carrier" at physical layer: while the previous recording was relative to Polish Military, the present one concerns a BFTP transfer over HF link between two peers of Romanian MAECT - Minister of Foreign Affairs (...which surely use Harris hardware/software equipments). The transfer was heard on 10315.0 KHz/USB on 18 Apr, starting from 0756 UTC.

STANAG 5066 (Profile for HF Radio Data Communication) is a NATO protocol stack definition operated over HF modem/radio equipment. S5066 provides standard clients over SIS (Subnetwork Interface Sublayer) and an IP mapping/adaptation in order to make use of conventional IP applications over HF radio band in a transparent way. There exist three editions of S5066 specification. Edition 1, and Edition 2 radios do not attempt to transmit when it is known that another radio is transmitting. It means that the data exchange is node to node and no more than two peers may communicate at the same time. With the release of S5066 Edition 3, this problem was resolved by using CSMA and HFTRP methods. The DTS (Data Transfer Sublayer) are same for Edition 1 and 2, the  CSMA and HFTRP new features was added to DTS layer of Edition 3 maintaing backward compatibility with the 1,2 editions. 

I used k500 decoder to demodulate the heard transmissions and then passed to the analysis of the obtained bitstream, once removed the 188-110 overhead.

188-110 over-the-air symbols

 Since S5066 is a "protocol stack", it has up to eight different Packet Data Units (PDUs) available and then analyzing a S-5066 transfer we could face different packet lenghts as in a wireshark capture example in pic. 1
 

Pic. 1 - some S5066_DTS PDU types

Although the DATA_ONLY PDU (222 byte, or 1776 bit period) is the more often met, this sample is interesting since exhibits pronounced 29 byte (or 232 bit) period mostly due to the EXP_NON_ARQ_DATA PDUs in the last two 2400bps/L 188-110 messages (pic. 2).  The DATA_ONLY (1776 bit) is clearly visible analyzing the PDU in the first 1200bps/short 188-110 message (pic. 3).
 

Pic. 2 - 29 byte = 232 bit period mostly due to  PDU type 8: EXP_NON_ARQ_DATA

Pic. 3 - 222 byte = DTS PDU type 0: DATA_ONLY

 It's interesting to note in pic. 4 that all the four S5066 PDUs have the same pattern:

Pic. 4

I just focused on the first 1200bps/S 188-110 message since it's the one that just contains a valid DATA_ONLY PDU.
The presence of the file HBFTP--1.gz  into the bitstream after S5066 PDU-0 removal (pic. 5), reveals that the data transfer is performed using a compressed file and Basic File Transfer Protocol (BFTP): in this case the used protocol is HBFTP that stands for Harris BFTP.

Pic. 5 - the compressed file HBFTP--1

The Basic File Transfer Protocol (BFTP) is a very simple protocol (based on the ZMODEM protocol) and is not designed to be especially robust. It's used in conjunction with CFTP (and obviously S5066) to forward e-mails over HF links. Messages produced by an e-mail application are  compressed in CFTP, segmented in the S5066 Basic File Transfer Protocol (BFTP), and passed to the S5066 DTS. At the receiving node, this process is reversed, and the uncompressed e-mail message is delivered to the receiving e-mail application for delivery or forwarding (pic. 6)

Pic. 6 - S5066 as a "connecting link" between wired and HF networks

It's worth noting that S5066 may use two top protocols named RCOP (Reliable Connection Oriented Protocol) and UDOP (Unreliable Datagram-Oriented Protocol) which are the HF equivalents of the well-known TCP and UDP protocols used in wired (inter)networks. In a few words, S5066 is a sort of "Middle-Earth" between wired and HF network... but that's another story.

Back to the received BFTP file, once decompressed we get the original e-mail message (pic 7,8): it's a simple and nice test message that in my opinion can be safely shown because it's a not a "suepr secret" message  but just a simple e-mail "chat" between operators (I only obscured part of the involved addresses): they know what are doing when send clear text.

Pic. 7

 

For nosey people, it's also possible to understand that "HARRIS2" uses HP computer (look at "...Received: from hp3254104...").

MIL 188-110C App.D: BW3 KHz, SR2400 Bd, WALSH and PSK-8

Both the two signals A and B have the same duration and both have a long preamble-segment followed by the data-segment. The signals spread ~3KHz bandwidth and consist of a 1800Hz carrier with PSK-8 modulation at 2400 symbols/sec.

synchronization preamble segment

From MS188-110C App.D "The synchronization preamble is used for rapid initial synchronization and provides time and frequency alignment. The synchronization preamble shall consist of two main sections, a transmitter level control (TLC) settling time section, and a synchronization section containing a repeated preamble super-frame. The preamble super-frame consists of three distinct subsections, one with a fixed (known) modulation, one to convey a downcount, and one to convey waveform identification." The superframe shall be repeated M times. The Synchronization section shall be immediately followed by the modulated data (pic 1).

Pic. 1

Both the two sync preamble segments have the same lenght (~ 5 seconds) and the same ACF structure: 239.98 ms frame that makes 576 symbols or 1728 bits. 

From the 188-110C App.D documentation, the orthogonal Walsh modulation is used in the synchronization section of the preamble and the length of the super-frame is 18 channel-symbols, ie: 

9 (fixed) + 4 (downcount) + 5 (waveform identification)  

Since in 3KHz bandwidth waveforms the preamble channel-symbol is 32 symbol length (pic. 2), the length of each repeated superframe is: 18 (channel-symbols) x 32 (length of one channel-symbol) that makes the measured 576 symbols or 1728 bits (pic. 3). 

Pic. 2

Pic. 3

That's ok in pic.4, where the synchronization section of the two preambles exhibits a clear 1728 bit period length.

Pic. 4

data segment
The data segments have the same lenghts but different frame structures (pic. 5).
 

Pic. 5 - over-the-air bitstreams after removed the sync preamble

The frame structure for the signal-A waveform is the one shown in figure D-7 of Appendix D: the initial synchronization preamble is followed by frames of alternating data (unknown-data) and probe symbols (known-data):
 

After demodulating the signal the bistream analysis reveals a 288 symbols (or 864 bits) length frame, consisting of 256 unknown-data + 32 known-data (96 bits probe). This signal  meet the waveform ID-7 of the 3KHz bandwidth set (pic. 6)

Pic. 6a - WID-7 frame structure

Pic. 6b - WID-7 32 known-data (96 bits probe)

The signal-B waveform does not exhibit a data+probe structure but rather strong 853.4ms ACF spikes (pic. 7) that makes 2048 symbols/sec at 2400Bd speed or 6144 bits.  This signal meet the waveform ID-0, which uses a different structure after the synchronization preamble. Data “frames” are 32-symbol Walsh sequences (channel symbols), each corresponding to a single unknown (data) bit.

Pic. 7 - 2048 symbols ACF (~853.4ms) for the signal B

As shown in pic. 8 (after demodulating the signal-B) mini-probes are not sent in waveform 0, Walsh-coded data symbols are sent continuously after the initial synchronization preamble and the 2048 symbols (6144 bit) period is due to the scrambler lenght. For this waveform the data scrambling implementation just generates 256 x 8 or 2048 values and the scrambling sequences are continuously wrapped around the 2048 symbol boundary. Athough data are modulated using Walsh ortogonal modulation, they are scrambled to appear, on-air, as an 8PSK constellation.

Pic. 8 - WID-0 6144 bit period caused by the scrambler lenght

CIS-112 modem 22.22 Bd BPSK stream

other than the π/4 DQPSK burst mode, CIS OFDM 122-tone can be met also as a stream-waveform where all channels use BPSK modulation as part of the basic QPSK in the absolute constellation. The 22.22Bd manipulation speed and 25.6Hz channels separation are the same in both the two waveforms as well as the typical CIS pilot-tone transmitted at 3300 Hz from the suppressed carrier. This sample was recordered at 0940 UTC on 10980.0 KHz/USB (April, 3).

pic. 1 - CIS-112 BPSK stream-waveform

This CIS-112 waveform  has two functionally distinct transmission phases: synchronization preamble phase and data phase. The sync preamble phase is discussed in another post.

During the data phase, the transmit waveform contains both message information and special symbols, say "probes", most likely reserved for equalization and sync by the receive modem. These probes are:

- a single special/service character consisting of the 56 odd tones, transmitted each 72 symbols 

pic. 4 - a special/service character is sent each 72 symbols

pic. 5 - the special/service symbol in the spectrogram

 - a four symbol periods (181ms length) pattern transmitted each 144 symbols that causes strong 6500ms ACF spikes. It's worth noting that 144 is just the double of 72.

In my opinion this sequence consists of known-data and should work like the mini-probes of the MS188-110 serial waveforms. Looking at the spectrogram, it seems that only the 3rd symbol is transmitted at higher level.

pic. 6 - fours symbol periods pattern transmitted each 144 symbols

pic. 7 - 6500 ACF spikes

Is quite easy isolate a single channel and measure the manipulation speed but it's very difficult to get the sub-carrier and consequently a clear phase constellation, despite the good quality of this sample (pic. 8). 

It's worth noting that some experts suggest that CIS-112 may use IOTA-OQAM technology and it causes intersymbolic-interference effects when analyzed with classical tools.

pic. 8

IOTA-OQAM technolgy  
http://signals.radioscanner.ru/base/signal229/