Rohde & Schwarz ALIS (RS-ARQ): pool size and frame length

Like in other ALE systems, during an ALIS call [1] the caller station transmits a defined number of "calling" frames so that the called station could have enough time to scan the frequencies of the current pool and, in case of late entry, could ever receive at least three frames for synchronization and data acquisition (Fig. 1).

Fig. 1 - ALIS late entry support to facilitate data acquisition

Thus, the number of the transmitted frames during an ALIS call is not fixed but depends on the size of the current pool of frequencies: roughly it is = (3 x number of pool frequencies) + 1. Don't know what is the maximum of frequencies for each pool and the maximum of different pools which are allowed by the ALIS processor.
I had a look at some ALIS calls and surprisingly found different ACF results, eg (Fig. 2): 

~358.6 ms for a pool size = 6
~376.1 ms for a pool size = 8
~402.2 ms for a pool size = 9
~402.8 ms for a pool size = 10
~415.5 ms for a pool size = 11

(although there are some decoder indecisions about pool sizes 9 and 10).

Fig. 2 - pool sizes and ACFs

Since the system operates at constant speed (228.6 symbols/sec) the higher is ACF and the greater the number of symbols per frame, thus the length of the frames is not fixed  and it can be presumed(!) that it depends on the the pool size.

This dependence is even more neat looking at the demodulated streams shown in Figure 3: you can notice a constant 61-bit pattern which follows a variable length field termed as "FC".

Fig. 3 - pool sizes and frame lengths

82-bit period for a pool size = 6
86-bit period for a pool size = 8
95-bit period for a pool size = 11

It's easy to note that computing  period length - 61, the result matches the number of the frames to be transmitted for each pool size according the relation:

number of frames ~ (3 x pool size) + 1

Figure 4 shows the "vertical" comparison of the 61-bit block for three different pool sizes (6,8,11) and a my rough reading of the bitfields structure; the decoder outputs in the right boxes help to identify values and differences:

• the first 15-bit field (0-14) is the address of the called station;
• the 23-bit last field (38-60) is probably transmitted for sync/correlation since this field exhibits the same pattern in all the 3 frames; if so, the rightmost bit should be the first to be transmitted;
• the 23-bit middle field (15-38) is the "status" of the caller station (FSK, voice, data, ARQ, adaptive reaction, fixed operation on a single frequency, frequency hopping mode, message key for frequency hopping mode, ...).

It's worth noting that, despite other ALE waveforms, the caller address is never transmitted.

Fig. 4 - 61-bit block structure
(Note that the format "15 + 23 + 23" is only a my guess)

As you see, no field contains informations for the pool size (the middle field can't store the pool size because the first two frames have diffrent pool sizes and same value for this field!).  

Given the above, the fact that the decoder prints out the size of the selected pool of frequencies (Fig. 1), means that this information is obtained from the "parsing" of the variable lenght field of the frame. I just wrote "parsing" because in this block, rather than a numeric value, they adopted a "positional" rapresentation by using the lenght of the block and the position of the 1-value bit, which is right-shifted in each received frame (Fig. 5).

Fig. 5 - FC blocks

One could say that the FC block looks like a function table of a n-bit shift register, in which each received frame acts as a transition of the clock input. 
Besides enumerate and identifiy the received frames, and consequently the pool size, the implementation of the FC block could also be used as a timing logic for re-sync the receive modem. But that's just a my opinion.

Please note that I do not own professional analysis tool so the numbers could be a bit inaccurate or different, anyway I think the underlaying reasoning remains valid. Who knows? maybe someone from R&S will read and comment... 

---

[1] quoting Hoka Electronic: "Some people call RS-ARQ (Rohde & Schwarz simplex ARQ) as ALIS but strictly speaking, ALIS is only the automatic link processor and frequency management system. It is not responsible for generating the traffic. ALIS is therefore somewhat of a misnomer. The modems generating the traffic are the GM857 and GM2000. Our suggestion is to stick with RS-ARQ as the system name."