C.3.3 Tx_TFO Process

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

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 or directly (Max_Rate parameter).

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

Toggling between these two States is commanded by TFO_Protocol with Begin_TFO (BT) and Discontinue_TFO (DT).

Figure C3.3-1: States of the Tx_TFO Process

During TFOtx == 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 TFOtx == 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 Appendix A). 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 has proceeded and shall "Modify on the Fly" this last TFO_Message before Tc into the first one after Tc, see Figure C3.3-2.

Figure C.3.3-2: Examples of Modification on the Fly within the Header Transmission

C.3.3.1 Maximum Rate Control

In case of the non_AMR Codec Types (GSM_FR, GSM_HR, GSM_EFR) no rate control is applied.

Maximum Rate Control for the downlink direction in TFO: Tx_TFO shall take the minimum of the local "Max_Rate" parameter and the received Rate Control parameter (CMR) from the BTS via Rx_TRAU and sends this minimum uplink to the distant TFO partner as CMR. This Rate Control is independent of the TFO State, but has only effect if TFO Frames are sent. In case the TFO_Protocol alters the Max_Rate parameter this shall be taken into account to the earliest possible point in time for all following frames.

C.3.3.2 Codec Modes outside the allowed Range

In case of AMR and AMR-WB TFO calls it may happen due to various error reasons that the TRAU Frames in uplink (or Iu Frames or Nb Frames) contain speech parameters coded with a Codec Mode higher than allowed by Rate Control, or a Codec Mode, which is outside the common ACS (CACS). This subclause describes how to handle these error cases.

Case 1: If the Codec Mode of the received TRAU Frame (or Iu Frame or Nb Frame) is within the common ACS, but higher than allowed by Rate Control, then the frame shall be send forward as TFO Frame.
Note: in many cases the frame can well be transported to the final destination, although the risk or frame errors is higher than wanted. In other cases the frame may have to be replaced by No_Data at a later point in the path.

Case 2: If the Codec Mode of the received TRAU Frame (or Iu Frame or Nb Frame) is not within the common ACS, then it shall not be send forward, but the frame shall be replaced by a "No_Data" frame.
Note: in this case there is no chance to deliver the frame.

Case 3: SID-Frames shall be send forward in any case, regardless which Codec Mode Indication (CMI) they contain.
Note: SID_Frames contain first of all the information that Comfort Noise has to be generated or continued. This is very important and therefore shall not be lost by a replacement with No_Data. Second, SID_Frames contain new Comfort Noise parameters, which are to a very large extend independent of the CMI and are useful.