C.8 Configuration Parameter Exchange on Abis/Ater and A Interfaces for AMR and AMR-WB

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

The TFO Speech Service Configuration parameters for TFO may be sent from the BSC via the BTS to the TRAU;

The following block diagram is intended for guidance only. If no TFO is ongoing, then the Config_Prot ends always in the (local) TRAU. If TFO is ongoing, then a mirrored (distant) BSS´ exists. Between the local TRAU and the distant TRAU´ an unknown transit network exists, which is transparent for the TFO Messages and the TFO Frames, but may contain devices involved in the TFO connection (e.g. TFO specific Circuit Multiplication Equipments, TCMEs, for cost efficient transmission).

Figure C.8-1: Block diagram of the transmission paths for the exchange of Configuration Parameter

The Configuration parameters received from the BSC (1) shall be sent uplink to the TRAU by inband signalling on the Abis/Ater interface (6). In most Codec_Modes the TRAU speech frames have sufficiently spare capacity to transmit these configuration parameters. Otherwise a No_Speech frame (mainly a No_Data Frame) shall be used, i.e. a speech frame shall be stolen. No_Data Frames are naturally used at call setup or after handover. From REL-5 onwards generic configuration frames are used, when both sides support this (see clause 4.3).

C.8.1 Protocol for the Exchange of Configuration Parameters

A simple protocol is defined to ensure correct receipt. It uses the Config_Prot field to code a Request or Acknowledge message and the Message_No field to bind Request and Acknowledgement together. Both are defined in clauses C.6.1.2 and C.6.1.3.

The Par_Type field defines whether a Request or Acknowledgement has defined configuration parameters or not, and which type of parameters are included: None, Local, Distant or Optimal. If a Con_Req has no configuration parameters, then the corresponding Con_Ack shall include the local ones. If Con_Req contains new or modified distant Configuration parameters, then the corresponding Con_Ack shall contain the local configuration parameters. If no configuration is to be exchanged, then the Config_Prot field shall be set to "No_Con". In this case the configuration parameter field is undefined. The receiver shall not acknowledge a No_Con message.

The configuration exchange shall start always with a Request from one side and shall end with an Acknowledgement from the other side. If the Acknowledgement is not received before N_Out_3 frames are elapsed, then the Request shall be repeated without modifying the Message_No. N_Out_3 is at resource allocation initialised (e.g. N_Out_3:= 4), but shall be adapted to the round trip delay during the connection (see clause C.4.5).

If more than three consecutive repetitions are without success, then TFO shall be terminated and the TFO Protocol shall enter State FAILURE.

The sender of the Request shall always use a new Message_No, e.g. by incrementing a counter, for a new Request. The receiver shall acknowledge by sending the appropriate Acknowledge_Code and the received Message_No back, if the Request was received without detectable errors. Otherwise, in case of detected errors, it shall not acknowledge, but wait for a repetition.

Typically no new request shall be sent before the previous configuration exchange is terminated. Exceptions exist at Resource Allocation, because it is not clear if and when the path between BTS and TRAU is connected through.

C.8.2 Initial Configuration at Resource Allocation

The BTS shall send "Con_Req" Messages. Typically at resource allocation no speech is received from the air interface or at least some FACCH arrive. Therefore "No_Data" frames may be used. Generic configuration frames are used from REL-5 onwards. The local TRAU shall acknowledge with "DL_Ack".

As long as No_Speech frames are sent in uplink direction the BTS shall increment the Message_No and send the configuration in every new frame, until a DL_Ack is received, i.e. the TRAU is synchronized. The exchange is considered as terminated, when the last sent Message_No is received back.

If, however, already speech frames are received in uplink direction from the air interface before the TRAU is synchronized, then appropriate speech frames shall be sent. If the configuration parameters can be included in these speech frames (e.g. as for all Codec_Modes below 10,2 kbit/s in 16 kbit/s sub-multiplexing), then the procedure is exactly as described for No_Speech frames. If, however, the configuration parameters cannot be included, then every 4^th speech frame shall be stolen on the Abis/Ater interface and be replaced by a No_Speech (No_Data) frame (generic configuration frame) to transmit the configuration.

C.8.3 Distant Configuration before TFO is established

After call set-up the TRAU may try to establish a TFO connection by using the TFO Protocol. During that time and before TFO is established the TRAU may get already knowledge about the distant configuration, either by TFO_REQ or TFO_Ack.

If distant and local configurations allow TFO (see Clauses 11 and 12 for the TFO Decision algorithm) then the TRAU shall immediately send TFO_Soon with the appropriate Rate Control to its local BTS. It may also include the partially known distant configuration parameters by using Dis_Req together with TFO_Soon.

Otherwise the distant configuration parameters shall be sent by using Dis_Req together with TFO_Off, when the information required for Codec Type and/or Configuration mismatch resolutions are available, either after TFO_REQ_L or TFO_ACK_L.

Dis_Req shall be used by the TRAUin downlink to transmit the distant or the optimal configuration parameters, when these have not been received by Con_Req or Con_Ack from the distant side.

C.8.4 Optimal TFO configuration

In TFO mode versions 5 and 6 (see C.2.4), the TFO Decision algorithm is only run by the TRAU. In this case the TRAU does not send the distant configuration to the BTS or the BSC, but the result of the TFO Decision algorithm, i.e. the optimal Codec Type and the optimal configuration parameters.

As soon as the optimal TFO configuration is known (result of the TFO Decision algorithm), the TRAU shall send it to the BTS by using Dis_Req.

C.8.5 Configuration Exchange in TFO

If TFO is ongoing (state OPERATION: the BTS is informed about that by TFO_On, see clause C.6.2) then the configuration sent by the BTS with Con_Req shall be relayed through by the local TRAU and the distant TRAU´ down to the distant BTS´. All devices in the path (TRAUs, but maybe also others, e.g. TCMEs) are updated to the new configuration. The distant BTS´ shall acknowledge this by Con_Ack. This message takes the same way back. The exchange shall be considered terminated when the originating BTS received the Con_Ack.

NOTE: The round trip delay in TFO connections shall be considered.

In case of TFO with a non_AMR Codec Type of a release lower than REL-5 only TFO_REQ_L and TFO_ACK_L messages can be used for exchange of TFO Configuration data (mainly the Codec_List).

In case of TFO with an AMR or AMR-WB Codec Type the Config_Frames may be used instead, because they are substantially faster in transmission and are exactly traffic frame synchronised and they may come anyhow from the BTS within the traffic flow. TFO_REQ_L messages with the same piece of information may be transmitted as for non AMR Codec Types, but only one of these methods shall be used, either Con_Req or TFO_REQ_L, not both in parallel. In case of discrepancy between the Config_Frames and the TFO messages, the receiving side decides which shall have precedence.
In any case TFO_REQ_L must be acknowledged by a TFO_ACK_L and a Con_Req by a Con_Ack. . In the (rare) case that a TFO_ACK_L contains an embedded Con_Req frame, the parameters of the TFO_ACK_L shall be ignored, because the Con_Req travels faster and contains more recent configuration parameters.

C.8.6 Handover_Complete Notification in TFO

A new BTS shall reset an internal "Handover_Flag", when it is activated for a new call setup.
A new BTS shall set this internal Handover_Flag, when it is activated for a handover.

The new BTS shall send the "Handover_Complete Notification" within each Con_Req in the uplink direction as long as the Handover_Flag is set. The Handover_Flag shall be reset when receiving a Con_Ack from the distant side. A DL_Ack from the local TRAU shall not reset the Handover_Flag.

After a local handover, there are two events that trigger the new BTS to enter the TFO_YES State:

– a TFO_On Message (Inter-BSC handover and call setup);

– a Con_Ack Frame (Intra-BSC handover).

In the case of a local Inter-BSC handover a new TRAU is initialized. This new TRAU starts the TFO protocol with Not_Active. The Con_Req(loc) (with the Handover_Complete Notification) of the new BTS is acknowledged directly with a DL_Ack(empty) by the local TRAU. This shall not reset the Handover_Flag within the new BTS, but shall terminate the sending of the Con_Req(loc) in uplink. Later, a TFO_On message from the new local TRAU will trigger the new BTS to enter TFO_YES. In this case a Con_Req(loc) shall be sent to the distant side, because the time delay is not measured yet. Since the Handover_Flag is still set, the "Handover_Complete Notification" shall be included and the distant side is informed that a handover has taken place and the time delay has to be measured again. The distant BTS therefore shall send a Con_Ack(dis) to acknowledge the Con_Req(loc) and then a Con_Req(dis) and wait for the Con_Ack(loc) for delay determination.

In the case of a local Intra-BSC handover the TRAU typically doesn’t change and therefore doesn´t interrupt the ongoing TFO connection. It remains in State Operation. Therefore no TFO_On message will be sent to the new local BTS. In this case, the Con_Req(loc) (with the Handover_Complete Notification) of the local BTS will not be acknowledged by the local TRAU, but directly with a Con_Ack(dis) by the distant BTS. This Con_Ack(dis) allows to determine the round trip delay on the local side, resets the Handover_Flag and triggers the local BTS to enter TFO_YES. No further Con_Req(loc) has to be sent to the distant side because the time delay was already measured. Since the distant side has received the Handover_Complete Notification, it knows that the time delay has to be measured again on its side. The distant BTS therefore shall send a Con_Req(dis) and wait for the Con_Ack(loc) for delay determination.