D.3 TFO_TC

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

The following clauses describe the actions within the TC to establish and maintain Tandem Free Operation in terms of a State Machine, respectively TFO Processes, handling synchronization and protocol. The description of the TFO Protocol does not reflect implementation details for the I/O Processes (Rx_IU, Tx_IU, Tx_TFO, and Rx_TFO), but they may need to be considered for the exact understanding of the behavior. Only the TFO_Protocol Process is detailed, which is responsible for the handling of the TFO Protocol.

The TFO_TC 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 MSC Server (TFO_MSC) to resolve Codec Mismatch, see Figure D.3.1-1.

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 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 D.3-1: The five TFO_TC Processes and the TFO_MSC Process

D.3.1 Rx_IU Process

The Rx_IU Process receives Uplink IU Frames from the IU Interface and checks correct synchronisation and contents. It performs all actions of a conventional Uplink TC. 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. In case of AMR-WB a successive downsampling is performed before G.711 encoding.

The resulting speech samples are handled to the Tx_TFO Process for output to the Nb interface. In addition Rx_IU passes the Uplink IU Speech Parameters directly and unaltered to Tx_TFO.

It further extracts the Rate Control information (if any) from the Uplink IU Frames and sends corresponding Rx_IU Messages to the Tx_IU Process, the Tx_TFO Process and the TFO_Protocol Process.

D.3.2 Tx_IU Process

The Tx_IU Process builds autonomously the relevant downlink IU Frames and sends them in the correct phase relation onto the IU-Interface as commanded by the (optional) time alignment from the RNC.

Tx_IU has two major States: TFOdl == OFF (start-up default state) and TFOdl == ON (see Figure D.3.2-1).

TFO_Protocol controls the transitions between these states using the Accept_TFO (AT) and Ignore_TFO (IT) commands.

Figure D.3.2-1: States of the Tx_IU Process

During TFOdl == OFF Tx_IU performs all actions of a conventional downlink TC: On command from Rx_IU it performs necessary downlink time alignments (optional). It samples one frame of speech samples in the correct phase position and calls the Speech Encoder. In case of AMR-WB the received PCM samples are decoded and upsampled before the WB Speech Encoder is called. The resulting speech parameters are then transmitted downlink on the IU interface. In case of AMR, Tx_IU furthermore steers the AMR Codec Mode according to the UL Rate Control Command received from the Rx_IU.

During TFOdl == ON no Bad Frame Handling or Comfort Noise Parameter Handling are performed. The speech parameters extracted from the TFO Frames are passed as Downlink IU Frames with least possible delay down to the RNC. The Tx_IU shall not perform any Error Correction, but rather relay the received parameters unaltered through. If a synchronisation error or a CRC error is detected in the TFO Frame, the payload CRC of the IU frame shall be inverted bit by bit.

Tx_IU performs Maximum Rate Control for the uplink direction by taking the minimum of the local "Max_Rate" parameter and the received Rate Control parameter from Rx_TFO and sends this downlink to the RNC, whenever a change in this result occurs. This Rate Control is independent of the TFO state. The exact handling of the Rate Control Commands on the IU interface is described in 3GPP TS 25.415. In case the TFO_Protocol alters the Max_Rate parameter a Rate Control Command has to be sent.

D.3.3 Tx_TFO Process

The Tx_TFO Process gets directly and with minimal delay the unaltered Uplink speech parameters and control bits and with some delay the decoded speech PCM samples from Rx_IU. It further gets internal messages (commands) from TFO_Protocol via the Tx_Queue, or directly without delay.

Tx_TFO has two major States: TFOul == OFF (default at beginning) and TFOul == ON, see Figure D3.3-1. Toggling between these two States is commanded by TFO_Protocol with Begin_TFO (BT) and Discontinue_TFO (DT).

Figure D.3.3-1: States of the Tx_TFO Process

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

During TFOul == 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 Nb-Interface. Time alignment of TFO Messages and TFO Frames are handled autonomously and independent of the TFO_Protocol Process. Rx_IU informs Tx_TFO about any changes in the phase position of the Uplink IU Frames 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 D.3.3-2.

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

Tx_TFO performs Maximum Rate Control for the downlink direction by taking the minimum of the local "Max_Rate" parameter and the received Rate Control parameter from Rx_IU and sends this minimum uplink to the distant TFO partner.

D.3.4 Rx_TFO Process

The Rx_TFO Process receives TFO Messages and TFO Frames from the Nb-Interface and synchronises to them, i.e. checks correct synchronisation and contents. It bypasses all PCM samples and Speech parameters directly to Tx_IU 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.

When the Rx_TFO received distant TFO parameters, either by TFO Messages or TFO Frames (Config_Prot Frames), it relays them to the TFO_Protocol Process.

D.3.4.1 Search for and Monitoring of TFO Synchronization

See Annex C, clause C.3.4.1 for the detailed description.

D.3.5 TFO_Protocol Process

The TFO_Protocol Process consists of a set of different states. The initial state shall be Not_Active. The TFO_Protocol Process is typically invoked whenever a message is received, either from Rx_IU, Rx_TFO, Tx_TFO or the MSC Server.

Some key events are due to modifications of the local configuration:

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

– its Configuration Parameters (e.g. the ACS in case of AMR) (New_Local_Configuration); and

– a modification of the list of the alternative speech Codec Types (New_Local_Codec_List);

– TFO Enable or TFO Disable.

These parameters are received from the MSC Server, e.g. via the vertical interface using H.248.

D.3.5.1 Messages from the MSC Server to TFO_Protocol

Rx == New_Speech_Call (Local_Used_Codec); Initialises the TC.

Rx == New_Local_Codec (New_Local_Used_Codec); In Call Modification to another Codec Type or Configuration.

Rx == Data_Call; In Call Modification to Data_Call (not relevant)

Rx == New_Local_Codec_List (Codec_List); Information on available resources

Rx == TC_Idle; The TC is set into Idle mode (equivalent to TRAU_Idle see clauses 10.4 and C.3.5.1)

Rx == TFO_Enable; Enable the TFO_Protocol process

Rx == TFO_Disable; Disable the TFO_Protocol process

D.3.5.2 Messages from TFO_Protocol to Tx_IU

Tx_IU:= Accept_TFO; If TFO Frames are correctly received, they shall be used.

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

Tx_IU:= Set_Max_Rate (Max_Rate); The Rate Control is limited to an upper bound.
This command is executed immediately.
It triggers a Rate_Control_Req to be sent to the RNC.
The RNC has to acknowledge this by Rate_Control_Ack.

D.3.5.3 Messages from TFO_Protocol to the MSC Server

Tx_MSC:= Optimal_Codec_Type (); Triggers a Codec Modification by OobTC

Tx_MSC:= TFO_Status (); Inform about TFO status and configuration

D.3.5.4 Messages between TFO_Protocol and Tx_TFO

The symbol () indicates that these Messages contain parameters, see Clause 8.

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 Codec Types and Configurations

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

Tx:= Con_Req (); used in TFO to inform the distant TFO Partner about the local Configuration;
second method to TFO_REQ_L with same parameters, but 10 times faster;

Tx:= Con_Ack (); used in TFO to respond to Con_Req;

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.
This command is executed immediately and
does not go via the Tx_Queue (of course not).

Tx:= Set_Max_Rate (Max_Rate); The Rate Control is limited to an upper bound..
This command is executed immediately and
does not go via the Tx_Queue!

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

D.3.5.5 Messages from Rx_TFO to TFO_Protocol

The symbol () indicates that these Messages contain parameters, see Clause 8.

Rx == TFO_REQ ();

Rx == TFO_ACK ();

Rx == TFO_REQ_L ();

Rx == TFO_ACK_L ();

Rx:= Con_Req ();

Rx:= Con_Ack ();

Rx == TFO_TRANS (); serves as alternative, faster 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
that are different from the PCM_Idle sample.

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.

D.3.5.6 Messages from Rx_IU to TFO_Protocol

Rx_IU := Rate_Control_Ack (Max_Rate); The Rate_Control_Req is acknowledged.
This is important for the TFO Protocol
In addition the downlink rate may be limited to an upper bound.
This is reported to Tx_TFO and to Tx_IU.