> 5.5.2 | Usage of Frames in Siemens Multiplexer Protocol Version 4

> With the Siemens multiplexer protocol version 4, basic mode with UIH frames is still used on the control channel, but is no longer supported on the data channels.
> After activation of multiplexer protocol version 4, UIH frames are not parsed anymore on the data channels because now a proprietary Siemens frame type, referred to as UIH_E frame, applies. The MS does NOT check the PN frame type parameter of a channel to perform DCLI parameter negotiation as defined in the GSM 07.10 specificaton. Instead, it will always code/decode the new Siemens frame type UIH_E on the data channels.
> On the control channel, the MS uses the UIH frames for management and control information as MSC or for parameter negotiation like in all earlier multiplexer protocol versions.
> Frame types used for error recovery mode as of multiplexer protocol version 4:

> • | UIH_E UIH with N(S) and N(R). New Siemens frame type implemented on all data channels to provide better performance.

> • | RR Receive ready

> • | RNR Receive not ready

> • | REJ Reject

> Frames and procedures not supported in multiplexer protocol version 4:

> • | I frames (performance reasons)

> • | P/F bit checkpoint handling (GSM 07.10, chapter 6.2.2.5.3), use REJ instead

> New frame behavior in multiplexer protocol version 4:

> • | The MSC frame will still transmit V.24 status lines, but the flow control FC bit (Bit 2) is always ignored.

> • | SABM/DISC frames will reset all internal HDLC states and counters.

> • | PN frame: Separate parameter negotiation on each channel allows using different configurations on either channel (see below).

> Changed behavior of the PN frame:
> In multiplexer protocol version 4, the following system parameters can be adjusted on each channel. To configure those parameters, send a proposal, read the response and use the values returned by the module in the host application:

> • | Windows size: Any value from 2 (default) to 7.

> • | Frame size: minimum value 98 maximum value = (internal Rx buffer of MS) / (WindowsSize+1)

> The following values are read only in all multiplexer protocol versions (the module does not change them anyway):

> • | T1: Acknowledgement timer given in 1/100 seconds from 10 to 255. The module always returns, within the PN frame, the value 200. So the result of the negotiation is always 200.

> • | Frame type: = 0x00 (UIH) if multiplexer protocol version <3 = 0x95 (UIH_E) if multiplexer protocol version <4

> Changed behavior of UIH frames in multiplexer protocol version 4:
> IMPORTANT: Since the module has not enough CPU power to perform I frame handling (ISO HDLC transparency mechanism with complete checksum), it is designed to use UIH_E frames instead. Payload data are always transported with length byte and header checksum. Nevertheless, send sequence number N(S) and receive sequence number N(R) are supported and must be used. The control type is coded as I frame.
> The following table shows an example frame with 6 Bytes payload, N(R) is 2, N(S) is 2.

> Table 9: | Frame example for multiplexer protocol version 4

> Startflag | Address Field | Control Field, includes N(R) and N(S) | Length Field | Payload | Header Checksum | Endflag
> F9 | 07 | 22 | 0D | 0D 0A 4F 4B 0D 0A | 30 | F9

> Coding of the control field:
> In multiplexer protocol version 4, the module uses the following control field coding. Please notice that the UIH_E frame type has the same control field coding as the standard I frame in GSM 07.10. N(R) and N(S) are receive and sequence number, the P/F bit (Bit 5) is always set to 0 from the module, and not read on any received frame.

> Table 10: | Control field coding in multiplexer protocol version 4

> Frame Type | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
> UIH_E payload | 0 | N(S) | 0 | N(R)
> RR Receive Ready | 1 | 0 | 0 | 0 | 0 | N(R)
> RNR Receive Not Ready | 1 | 0 | 1 | 0 | 0 | N(R)
> REJ Reject | 1 | 0 | 0 | 1 | 0 | N(R)