B.6 Compliance to IS Messages

08.623GPPInband Tandem Free Operation (TFO) of speech codecsService descriptionStage 3TS

An IS_Compliant IPE shall be capable of interpreting and obeying the IS_IPE Messages.

It depends on the intelligence and task of an IPE, how many and which of the other IS Messages it needs to understand.

The IPEs shall synchronise to all IS Messages, especially to find or refind the Keep_Open_Indication. All IPEs shall resynchronize, if they see an IS Message in a new phase position, and if the synchronization can not be found in the old phase position anymore.

B.6.1 Compliance to IS_REQ and IS_ACK Messages

Most IPEs need not and do not understand these messages. They just synchronise to them and let them pass unaltered.

Only IS_Responsive IPEs may take advantage. This is system specific and IPE specific.

B.6.2 Compliance to IS_NORMAL Message

The IPE shall act in response to the receipt of an IS_NORMAL Message such that:

The IPE shall synchronise to it. The message shall appear unchanged at the output of the IPE.

The IPE shall resume its Normal_Mode of operation for all data received subsequent to the IS_NORMAL Message,
until a different command is received.

It depends on the type and operation of the specific IPE, whether the Normal_Mode is resumed in both directions, or only in the direction in which the IS_NORMAL Message flows. It must be assumed that in general only this one direction is affected.

B.6.3 Compliance to IS_TRANS_x Messages

The IPE shall act in response to the receipt of an IS_TRANS_x Message (x in the range 1 to 8) such that:

The IPE shall synchronise to it. The IS_TRANS_x Message shall appear unchanged at the output of the IPE.

The IPE shall be transparent in all x LSBs of all PCM samples received subsequent to the IS_TRANS Message.

The transparency shall persist as long as the Keep_Open_Indication persists, or until a different command is received.

The (8-x) upper bits of the PCM samples are not of interest and may be modified arbitrarily by the IPE.

It depends on the type and operation of the specific IPE, whether the Transparent_Mode is resumed in both directions, or only in the direction in which the IS_TRANS Message flows. It must be assumed that in general only this one direction is affected.

B.6.4 Compliance to IS_TRANS_x_u Messages

The IPE shall act in response to the receipt of an IS_TRANS_x_u Message (x in the range 1 to 7) such that:

The IPE shall synchronise to it. The messages shall appear unchanged at the output of the IPE.

The IPE shall be transparent in all x LSBs of all PCM samples received subsequent to the IS_TRANS Message.

The transparency shall persist as long as the Keep_Open_Indication persists, or until a different command is received.

The (8-x) upper bits of the PCM samples are important and in general shall not be modified by the IPE, but shall be bypassed transparently in exactly the same manner and delay as the x LSBs. It is important that this transparency for the upper bits is provided by IPEs that do not understand the specific IS Protocol (e.g. do not understand the IS_System_Identification or the protocol of the transmitted parameters).

Only IPEs which do exactly understand the specific IS Protocol shall take advantage of the opportunities given with the IS_TRANS_x_u Messages. An example is the GCME, which transmits internally only the coded speech parameters and re-generates the upper x bits at its output (termed here as "first solution"). The resulting delay in the upper 8-x bits shall be identical to the delay in the x LSBs.

If this transparency of the upper (8-x) bits or their re-generation can not be established, then the upper bits shall contain a constant pattern, giving the least output energy (PCM_Silence). This "second solution" may cause temporary interruptions of the speech signal in some transition cases (e.g. hand over in some tandem free GSM mobile-to-mobile calls). Therefore the first solution is the preferred one.

IPEs, which implements the second solution shall switch to the full transparent 64 kBit/s channel as soon as they loose synchronisation with the protocol of the transmitted parameters (e.g. the "TFO Frames" in GSM Systems). The full transparency shall be executed for both directions. The near side shall be fully transparent in less than 60 ms and the other side the one way delay of that IPE later.

It depends on the type and operation of the specific IPE, whether the Transparent_Mode is resumed in both directions, or only in the direction in which the IS_TRANS Message flows. It must be assumed that in general only this one direction is affected.

B.6.5 Compliance to IS_FILL Message

The IS_FILL Message has no specific meaning, but may serve for two purposes.

First of all, it can be used to close the gap in an IS Protocol to keep all IPEs synchronized. Otherwise – in case of an interruption – the n IPEs in the path would swallow the next n IS Messages again.

Second, an IS_FILL Message can be used to resynchronize all IPEs to a new grid position, if necessary.

B.6.6 Compliance to IS_DUP Messages

The IS_DUP Message is sent by an IS Partner to the distant IS Partner to inform about a specific Half_Duplex reception.

Most IPEs need not and do not understand this message. They just synchronize to it and let it pass unaltered.

Only IS_Responsive IPEs may take advantage. This is system specific and IPE specific.

B.6.7 Compliance to IS_SYL Messages

The IS_SYL Message is sent by an IS Partner to the distant IS Partner to inform about a specific Sync_Lost Situation.

Most IPEs need not and do not understand this message. They just synchronize to it and let it pass unaltered.

Only IS_Responsive IPEs may take advantage. This is system specific and IPE specific.

Annex C (Informative):
The SDL model of the TFO protocol

This annex contains a few selected pages from the formal SDL model of the protocol for Tandem Free Operation described in the main body of this standard. The complete SDL specification, which is fully simulateable, is available in various electronic formats as described below.

The SDL model gives a precise description of the logical behaviour of the TFO protocol. It is not intended to imply a particular way of implementing the protocol nor does it intend to restrict an implementation only to what is specified in the SDL.

This is not a real-time model and critical timing requirements have not been included. These are fully described in the main text of this standard, for example clause 7. The purpose of this SDL specification is to give a clear and unambiguous understanding of the TFO protocol with respect to the temporal ordering and interchange of TFO messages over the A-interface.

The SDL specification models the TFO messages as described in clause 6, the TFO processes as described in clause 8 and the TFO protocol as described in clauses 9 and 10. Additionally, it illustrates the use of Table 19 (clause 11) for resolving codec mismatch. In the case of a conflict between the SDL model and clauses 9 and 10, clause 9 and 10 shall have precedence.

The SDL model is available in electronic format in the zip archive TFO_SDL.zip. This archive can be found on the ETSI CD-ROM together with the TFO standard.

TFO_SDL.zip contains the following files:

  • README.txt

how to install and use the simulateable model

  • TFO_PDF.pdf

the complete SDL specification in graphical format as a .pdf file

  • TFO_CIF.pr

the complete SDL specification in machine processable format as a .pr file

  • TFO_SDT

a directory containing all the SDT (version 3.2) source files

If you have any questions related to the SDL model please contact: pex@etsi.fr

Figure C.1: Overall SDL model structure

Figure C.2: TFO/TRAU SDL process diagrams

Figure C.3: Partial TFO protocol transition (taken from the First_Try state)

The complete SDL for the TFO messages, TFO process and the TFO protocol transitions corresponding to the protocol matrix given in clause 10 can be found in the electronic SDL files.

Annex D (informative):
Change history

Change history

Date

TSG #

TSG Doc.

CR

Rev

Subject/Comment

Old

New

March 00

SA#7

SP-000026

A002

1

TFO Message Extendibility

7.0.0

7.1.0