8 Processes for Tandem Free Operation

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

The following chapters describe the actions within the TRAU to establish and maintain Tandem Free Operation in terms of a State Machine, respectively TFO Processes, handling synchronisation and protocol. The description of the TFO Protocol does not reflect implementation details for the I/O Processes, but they may need to be considered for the exact understanding of the behaviour. Only the TFO_Protocol Process is detailed, which is responsible for the handling of the TFO Protocol.

The SDL-Simulation, as described in Annex C, however, takes the necessary details into account and can serve as example implementation for all processes, as far as the TFO Protocol is concerned.

The TFO_TRAU can be regarded as consisting of five processes, which are strongly coupled to each other, which run in parallel, but phase shifted. The TFO_Protocol Process communicates with the TFO I/O processes and, optionally, with its corresponding process within the BSS (BSC) to resolve Codec Mismatch, see figure 7.

Under normal circumstances (exceptions occur during time alignments or octet slips) all TFO I/O Processes are triggered every 160 samples or every speech frame of 20 ms. All events and actions are quantized in time into these smallest intervals.

It can be assumed that the processing times for the TFO Processes are very short and negligible.

However, it must be ensured that no timing ambiguity occurs between the Processes.

This means the processing and exchange of information between them do not overlap in time. Care must be taken especially when time alignment occurs, which may be completely independent in uplink and downlink.

During these time alignments the TFO Frames or TFO Messages may shift in time and consequently the triggering point for the related TFO Processes changes, too.

Figure 7: The TFO_TRAU consists of five Processes

8.1 Rx_TRAU Process

The Rx_TRAU Process receives Uplink TRAU Frames from the Abis/Ater Interface and synchronises to them, i.e. checks correct synchronisation and contents. It performs all actions of a conventional Uplink TRAU (see GSM 08.60 respectively GSM 08.61): It extracts the data bits and calls, if appropriate, the Bad Frame Handler, the Uplink DTX functions and Comfort Noise Generator and finally the Speech Decoder.

The resulting speech samples are handled to the Tx_TFO Process for output to the A interface. In addition Rx_TRAU passes the Uplink TRAU Frames directly and unaltered to Tx_TFO.

It further extracts the control bits, respectively commands, from the Uplink TRAU Frames and sends corresponding Rx_TRAU Messages to the Tx_TRAU Process (see GSM 08.60 respectively GSM 08.61) and the TFO_Protocol Process (see subclause 8.5).

8.2 Tx_TRAU Process

The Tx_TRAU Process builds autonomously the relevant Downlink TRAU Frames and sends them in the correct phase relation onto the Abis/Ater-Interface as commanded by the time alignment from the BTS.

Tx_TRAU has two major States: TFO == OFF (default at beginning) and TFO == ON, see Figure 8.

Toggling between these two States is commanded by TFO_Protocol with Accept_TFO, respectively Ignore_TFO.

Figure 8: States of the Tx_TRAU Process

During TFO == OFF, Tx_TRAU performs all actions of a conventional downlink TRAU (see GSM 08.60 respectively GSM 08.61): On command from Rx_TRAU it performs necessary downlink time alignments and starts or stops sending of TRAU Frames. It samples one frame of speech samples in the correct phase position and calls the Speech Encoder. The resulting speech parameters are then transmitted downlink on the Abis/Ater interface.

During TFO == ON, Tx_TRAU performs Bad Frame Handling and Comfort Noise Parameter Handling on parameter level on the received TFO Frames, if necessary. The resulting speech parameters and control bits are buffered until they are passed as Downlink TRAU Frames in correct phase position to the BTS (see also subclause 7.3).

There are four possible cases regarding DTX in a Mobile-to-Mobile communication, as reflected in Table 7.

Table 7: DTX configurations in Mobile-To-Mobile communications

Case

Local TRAU: Downlink

Distant TRAU: Uplink

0

No-DTX

No-DTX

1

No-DTX

DTX

2

DTX

DTX

3

DTX

No-DTX

8.2.1 Downlink Speech Transmission if TFO is ON

During TFO == ON and if neither Uplink nor Downlink DTX is active (case 0 in Table 7), the Tx_TFO Process receives TFO Frames from the A Interface with SID == "0". It synchronises to them, i.e. checks correct synchronisation and contents. It extracts the data bits and calls, if appropriate (e.g. if BFI == "1" or if the TFO Frame is not-valid, see subclause 8.4.2), a Bad Frame Handler to derive suitable parameters for Downlink TRAU Frames. This Bad Frame Handler on parameter level is subject to manufacturer dependent future improvements and is not part of this recommendation.

During TFO == ON and if distant Uplink DTX is active, but not local Downlink DTX (case 1 in Table 7), then the Tx_TFO Process receives TFO Frames containing speech parameters (SID == "0": handling as in case 0, see above), but also TFO Frames containing SID parameters (SID == "1" or "2") and TFO Frames marked with BFI == "1" during speech inactivity. Tx_TFO then calls a Comfort Noise Generator to derive suitable "speech" parameters for Downlink TRAU Frames. The SP flag shall always be set to SP = "1". The Downlink TRAU Frames shall not contain the SID codeword, but parameters that allow a direct decoding. Also this Comfort Noise Generator on parameter level is subject to manufacturer dependent future improvements and is not part of this recommendation.

8.2.2 DTX Procedures in Downlink Direction if TFO is ON

During TFO == ON and if distant Uplink DTX and local downlink DTX are active (case 2 in Table 7), then the Tx_TFO Process receives TFO Frames containing either Speech parameters (SID == "0, handling see subclause 8.2.1) or SID parameters (SID == "1" or "2") or TFO Frames marked with BFI == "1" during speech inactivity due to transmission errors.

If a TFO Frame marked as a valid SID frame (SID == "2", BFI == "0") is received, it shall be stored in Tx_TRAU and its parameters shall be sent directly as Downlink TRAU SID Frame with correct timing. The DL_TRAU SID Frames produced from the valid stored frame are output repeatedly to the Abis/Ater interface whilst invalid SID frames (SID == "1") or frames marked as bad (BFI == "1") are received. These Downlink TRAU SID Frames shall be marked with the SP flag = "0" and shall all contain the SID codeword.

The stored SID Frame shall be considered as being valid for SID frame generation purposes until the receipt of the second instance of TAF == "1" (in a TFO Frame) following its initial storage. On expiry of the stored SID frame a suitable Bad Frame Handler for SID Frames shall be invoked to mute the Comfort Noise. Also this Bad Frame Handler for SID Frames on parameter level is subject to manufacturer dependent future improvements and is not part of this recommendation.

During TFO == ON and if distant Uplink DTX is not active, but local downlink DTX is on (case 3 in Table 7), i.e. only TFO Frames containing speech parameters are received , then one of the following alternative methods shall be used:

Downlink DTX need not to be used.
The speech parameters are extracted from the TFO Frames and are passed to the BTS. This is virtually identical to case 0 in Table 7, with no speech pauses detected, and handled like described above.

Alternatively, a voice activity detector makes the decision as to whether the frame contains speech or not based on the PCM samples received from the A interface. During periods decided as "Active Speech" the TFO Frame parameters are used as described above. During periods of "Speech Pause" Comfort Noise Parameters are calculated.

These operations are manufacturer dependent and not detailed here.

Alternatively, decoding of the speech parameters received in TFO Frames may be undertaken and these PCM samples may be used for normal downlink VAD and DTX functions.

8.2.3 Synchronisation and Bit Errors in Received TFO Frames

If Rx_TFO detects an error in the received TFO Frame synchronization or control bits or if a CRC error is detected, and the error is detected prior to beginning the output of the same frame (as a Downlink TRAU Frame), then Tx_TRAU shall either substitute parameters from the last good TFO Frame, or shall encode the received PCM samples for the duration of this frame.

If Rx_TFO detects an error in the received TFO Frame synchronization or control bits or if a CRC error is detected, and the error is detected after beginning of the output of the same frame (as a Downlink TRAU Frame), then Tx_TRAU shall deliberately corrupt the remaining, still unsent synchronization bits by setting them all to "0" and deliberately shall corrupt the remaining CRC bits. This will result in the BTS discarding this TRAU Frame, and transmitting a Fill frame to the Mobile station (see GSM 08.60 and GSM 08.61). The effect of the frame error will subsequently be masked by the Mobile station’s handling of bad frames.

8.3 Tx_TFO Process

The Tx_TFO Process gets directly the unaltered Uplink TRAU Frames (containing the speech parameters and the control bits) and the decoded speech PCM samples from Rx_TRAU. It further gets internal messages (commands) from TFO_Protocol via the Tx_Queue.

Tx_TFO has two major States: TFO == OFF (default at beginning) and TFO == ON, see Figure 9.

Toggling between these two States is commanded by TFO_Protocol with Begin_TFO respectively Discontinue_TFO.

Figure 9: States of the Tx_TFO Process

During TFO == OFF, decoded speech PCM samples and regular TFO Messages (if any) are sent onto the A interface. Time Alignment takes place only once, just before the beginning of the first regular TFO Message.

During TFO == ON, TFO Frames and embedded TFO Messages (if any) are sent. Time Alignment takes place just before the first TFO Frame and then whenever required in between two TFO Frames.

The Tx_TFO Process builds the relevant TFO Frames and sends them in the correct phase relation onto the A-Interface. Time alignment of TFO Messages and TFO Frames are handled autonomously and independent of the TFO_Protocol Process. Rx_TRAU informs Tx_TFO about any changes in the phase position of the Uplink TRAU Frame and Tx_TFO inserts automatically the correct number of T_Bits before the next TFO Frame, and embeds autonomously the next TFO_Message or a TFO_FILL Message, if necessary.

The TFO_Protocol Process can send internal messages into the Tx_Queue (First In, First Out). Tx_TFO shall take the message from the Tx_Queue one by one, shall process them autonomously and shall send the resulting TFO Messages in correct order and phase position, as regular or as embedded TFO Messages.Tx_TFO shall generate a Runout Message to TFO_Protocol, if the last TFO Message is sent without guarantee of a direct continuation by another TFO Message, i.e. if the (possible) IPEs may have run out of synchronisation (see chapter 10). TFO_Protocol may delete messages from Tx_Queue, as long as they are in there:
Command "Clear Tx_Queue", at time Tc.

Basically, messages or commands that are already in processing by Tx_TFO at Tc can not be stopped, deleted or interrupted. The TFO Protocol is designed to work properly with that default handling, although not with fastest processing.

But: Tx_TFO shall investigate at Tc, how far the transmission of the current TFO Message is proceeded and shall "Modify on the Fly" this last TFO_Message before Tc into the first one after Tc, see Figure 10.

Figure 10: Modification on the Fly within the Header Transmission, examples

8.4 Rx_TFO Process

The Rx_TFO Process receives TFO Messages and TFO Frames from the A-Interface and synchronises to them, i.e. checks correct sync and contents. It bypasses all PCM samples and TFO Frames directly to Tx_TRAU for further processing. The Rx_TFO Process further extracts all the control bits and TFO Messages and sends corresponding Rx_TFO Messages to the TFO_Protocol Process.

8.4.1 Search for and Monitoring of TFO Synchronization

The monitoring of TFO Frame or TFO Message synchronisation shall be a continuous process. Typically, TFO Messages and TFO Frames follow each other with a well defined phase relation. Insertion of T_Bits or octet slips may, however, disturb that regular phase relation every now and then and shall be taken into account. In all error cases, the receiver shall investigate, if sync has been lost due to octet slip, phase adjustment or other events and shall try to resynchronize as fast as possible.

Typically, TFO Frame synchronisation is similar or identical to TRAU Frame synchronisation, see GSM 08.60 and 08.61.

During Tandem Free Operation, however, it is sometimes necessary, to exchange TFO Messages by embedding them into the TFO Frame flow. This is indicated by a control bit (C5). Some of the TFO Frame synchronization bits are then replaced by bits of the TFO Message. TFO Messages follow specific design rules, which can be used to check if synchronisation is still valid.

The first TFO Message or the first TFO Frame (whatever comes first) shall be completely error free to be acceptable by Rx_TFO. After that all "valid" (see subclause 8.4.2) TFO Messages shall be reported to TFO_Protocol with a respective message. If a TFO Message has been received before and synchronisation is not found again for more than 60 ms, i.e. no "present" or "valid" TFO Message can be found during that time, then Rx_TFO shall generate a MSL (Message_Sync_Lost) Message to TFO_Protocol. A "not-valid", but "present" TFO Message shall not be reported, but also no MSL shall be reported, i.e. synchronisation is regarded as not lost, but the TFO Message is ignored.

Similar, the first five "valid" TFO Frames shall be reported to TFO_Protocol with frame number n (n == 1,2,..5). Further valid TFO Frames do not need to be reported.

Similar, if for the first time after the PCM_Idle period, PCM_Non_Idle samples are received, then a PCM_Non_Idle Message shall be sent to TFO_Protocol. Further PCM_Non_Idle samples need not be reported.

If TFO Frame Synchronization is lost, or if too many errors are detected in TFO Frames (no present TFO Frames), then the Rx_TFO shall generate a FSL (Frame_Sync_Lost) Message to TFO_Protocol with frame number n (n == 1,2,3), the number of lost TFO Frames since the last valid TFO Frame. No more than three FSL Messages need to be reported in a series.

NOTE: The MSL and FSL Messages shall not be mixed up with the TFO_SYL Message, by which the distant TFO Partner reports lost synchronisation.

TFO Messages with Extension_Blocks that can not be understood by the receiving TRAU, but which follow the design rules for IS_Extension_Blocks, shall be ignored. This guarantees future expandability.

8.4.2 Errors in TFO Messages and TFO Frames

Some Definitions, which may serve as a guideline:

A TFO Message is called "error-free", if no error can be detected within the whole message.

A TFO Message is called "single-error", if no more than one bit position differs either in the IS_Header or the IS_Command_Block or the GSM_Ident_Block or the IPE_Mode_Block or the Sync bits and no errors are detectable within the CRC fields or the EX-fields.

A TFO Message may be regarded as "correctable", if the phase position is as in preceeding TFO Messages and

– no more than 2 bit positions differ in the IS_Header; and

– no more than 1 error is detected within the IS_Command_Block; and

– no more than 3 errors are detected within the IPE_Mode_Block; and

– no more than 3 errors are detected within the GSM_Ident_Block; and

– no more than 1 error is detected within the Sync-Bit(s); and

– no more than 0 error is detected within the EX-field(s); and

– no more than 0 error is detected within the CRC-fields; and

– the total number of detected errors is not higher than 3.

TFO Message, which are error-free, single-error or correctable are also called "valid" TFO Messages. All other TFO Messages are called "not-valid".

A TFO Message may be regarded as "present", if the phase position is as in preceeding TFO Messages and

– no more than 4 bit positions differ in the IS_Header; and

– no more than 2 errors are detected within the IS_Command_Block; and

– no more than 3 errors are detected within the IPE_Mode_Block; and

– no more than 3 errors are detected within the GSM_Ident_Block; and

– no more than 2 errors are detected within the Sync-Bit(s); and

– no more than 1 error is detected within the EX-field(s); and

– no more than 1 error is detected within the CRC-fields; and

– the total number of detected errors is not higher than 5.

Sequences, which differ in more than "present" may not be recognized as TFO Messages at all ("not-present").

Note that the insertion of T_Bits may change the phase position of the TFO Frames and of bits of an embedded TFO Message. The TFO Message shall in that case be classified after the removal of the T_Bits.

An octet slip may also change the phase position of bits within a regular or embedded TFO Message.

If an error-free or a single-error TFO Message can be found after considering a hypothetical octet slip (1 sample), then it may be regarded as error-free or single-error and the new phase position shall be regarded as valid, if no valid or present TFO Message can be found at the old phase position.

A TFO Frame is called "error-free", if no error can be detected within the whole frame.

A TFO Frame is called "single-error", if no more than one bit position differs either in the synchronisation bits or the T_Bits and if no other errors can be detected. TFO Frames, which are error-free, or single-error are also called "valid" TFO Frames. All other TFO Frames are called "not-valid".

A TFO Frame may be regarded as "present", if

– no more than 4 bit positions differ in the synchronisation bits

– no more than 2 errors are detected within the T_Bits;

– no more than 1 error is detected within the control bits;

– no more than 1 error is detected within the CRC block; and

– the total number of detected errors is not higher than 5.

Sequences, which differ in more than "present" may not be recognized as TFO Frames at all ("not-present" ).

Note that the insertion or deletion of T_Bits may change the phase position of the TFO Frames .The TFO Frame shall in that case be classified after considering the T_Bits.

An octet slip may also change the phase position of bits within a TFO Frame. Typically a TFO Frame can not be corrected after an octet slip, but the next TFO Frame shall be found again.

The parameters of a valid TFO Frame shall be regarded as "bad", if the BFI flag is set to BFI == "1". Similar definitions hold for other valid TFO Frames, equivalent to Uplink TRAU Frames (see 08.60 and 08.61).

8.5 TFO_Protocol Process

The TFO_Protocol Process is typically invoked whenever a message is received, either from Rx_TRAU, Rx_TFO, Tx_TFO or the local BSS (i.e. the BSC).

Two events are due to modifications of the local MS-BSS configuration,

– a modification of the used speech Codec (New_Local_Codec); and

– a modification of the list of the alternative speech Codecs (New_Local_Codec_List).

The New_Local_Codec is extracted from the uplink TRAU Frames and reported by Rx_TRAU.

The New_Local_Codec_List is reported by the BSS in a manufacturer dependent way.

It may happen during an established TFO connection that the used Codec is identified as not optimal. Then the distant partner (e.g. a GCME) may inform the TRAU by a TFO_REQ_P Message that another Codec would be preferred.

The TRAU has to inform the local BSS about the preferred Codec, but continues with TFO until an optional In_Call_Modification is performed by the local BSS.

8.5.1 Messages from Rx_TRAU or local BSS

Rx == New_Speech_Call (Local_Used_Codec); Rx_TRAU is activated by BTS.

Rx == New_Local_Codec (New_Local_Used_Codec); In Call Modification to other Codec Type.

Rx == Data_Call; In Call Modification to Data_Call.

Rx == Local_Codec_List; Manufacturer dependent, optional, from BSS.

Rx == TRAU_Idle; Manufacturer dependent, either from BTS or BSS.

8.5.2 Messages to Tx_TRAU

Tx_TRAU := Accept_TFO; if TFO Frames are correctly received, they shall be used.

Tx_TRAU := Ignore_TFO; TFO Frames, even if received correctly, shall be ignored.

8.5.3 Optional Messages to the local BSS

BSS := TFO (Distant_Used_Codec, Distant_Codec_List, Distant_Preferred_Codec, …).

8.5.4 Messages to and from Tx_TFO

The symbol () indicates that these Messages contain parameters, see clause 6.

Tx := TFO_REQ (); main TFO_REQ Message.

Tx := TFO_ACK (); main TFO_ACK Message, response only to TFO_REQ.

Tx := TFO_REQ_L (); used in Mismatch, Operation and Periodic_Retry to inform about alternative Codecs.

Tx := TFO_ACK_L (); response only to TFO_REQ_L.

(Tx := TFO_REQ_P ()); undefined for TRAU, defined only for GCME.

Tx := TFO_TRANS (); command IPEs to go transparent.

Tx := TFO_NORMAL; reset IPEs into their normal operation.

Tx := TFO_FILL; mainly to pre-synchronise IPEs.

Tx := TFO_DUP; "I receive TFO Frames in Establishment".

Tx := TFO_SYL; "I lost TFO Frame synchronisation".

Tx := Begin_TFO; Insert TFO Frames from now on.

Tx := Discontinue_TFO; Discontinue inserting TFO Frames.

Clear Tx_Queue; Clears all remaining commands from Tx_Queue.

Rx == Runout; Reports that the continuous stream of outgoing TFO Messages may be interrupted.

8.5.5 Messages from Rx_TFO

The symbol () indicates that these Messages contain parameters, see clause 6.

Rx == TFO_REQ ().

Rx == TFO_ACK ().

Rx == TFO_REQ_L ().

Rx == TFO_ACK_L ().

Rx == TFO_REQ_P () ;requests an other, preferred Codec, plus Codec_List.

Rx == TFO_TRANS () ;may serve as alternative TFO_ACK in some cases!.

Rx == TFO_NORMAL.

Rx == TFO_FILL.

Rx == TFO_DUP.

Rx == TFO_SYL.

Rx == TFO_Frame () ;TFO_Frame (Distant_Used_Codec; Number_of_Received_Frames).

Rx == Frame_Sync_Lost () ;Frame_Sync_Lost (Number_of_Lost_Frames).

Rx == Mess_Sync_Lost ;Message_Sync_Lost.

Rx == PCM_Non_Idle ;at the beginning of a period with several samples/frame different from PCM_Idle.

The message "TFO_Frame ()" needs to be sent only at the first five occurrences, either after a not valid TFO Frame, or if the Distant_Used_Codec changed.

The message "Frame_Sync_Lost ()" needs to be sent only at the first five occurrences of errors in TFO Frames or loss of synchronisation, after a correctly received TFO Frame.

The message "Mess_Sync_Lost" is sent, when after a valid TFO Message no following TFO Message is found.