9 TFO State Machine

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

A State Machine, consisting of 17 States can describe the TFO_Protocol Process, see the following figure.

Figure 9-1: TFO_Protocol State Machine with most important transitions

There are five main States:

– Initialisation ( Not_Active,  Wakeup)

– Establishment ( First_Try,  Continuous_Retry,  Periodic_Retry,  Monitor,  Mismatch)

– Contact ( Contact)

– Preparation ( Wait_RC,  Konnect)

– Operation ( Operation)

Exception handling needs further States (see figure 9-1):

– Local Handover ( Fast_Try,  Fast_Contact).

– Distant Handover ( Sync_Lost,  Re_Konnect).

– Misbehaviour ( Failure).

– Termination ( TFO_Term).

It is assumed that Events (Conditions checking), Actions and Transitions to another State are handled almost instantaneous and in any case significantly faster than the time required to complete the transmission of any TFO Message or TFO Frame.

9.1 Initialisation

9.1.1 Not_Active State

The Not_Active state shall be the initial state of the TFO_Protocol. In this state the TFO_Protocol is not active and the TRAU/TC works in a conventional way. The state Not_Active is left and a transition to the Wakeup state is performed when a new speech call is set up or/and when TFO gets enabled.

9.1.2 Wakeup State

In the Wakeup state the TFO_Protocol waits until PCM speech samples are received that are different from PCM_Idle. Then a transition to the First_Try state is performed and three TFO_FILL messages and some TFO_REQ messages are initiated.

Option: The number of TFO_REQ messages may be adapted to achieve a longer time before the Runout occurs in First_Try. The default value is 35 TFO_REQ Messages (about 5 seconds). This may be extended to 7*35 TFO_REQ Messages (about 35 seconds), or any other value resulting in a timeout longer than the usual "not reachable" timer.

9.2 Establishment

9.2.1 First_Try State

The TC enters the First_Try state from the Wakeup state if TFO was enabled and PCM_Non_Idle speech samples are received. Regular TFO_REQ Messages are sent continuously for a certain maximum time. After that, if no TFO Partner answers before a Runout of TFO Messages, TFO_Protocol enters automatically into the Monitor State.

If TFO_REQ Messages are received with the same, own Signature, then a circuit loop back is assumed, i.e. the call is still not through connected. The TC selects a new Signature and continues sending TFO_REQ Messages, until a different Signature is received or a TFO_ACK is received. Since loop back delays may be substantial in some cases, the TC has to remember and compare also the previously selected own Signature. Care must be taken that the Signature selection contains a true random element to avoid that two different TCs select by coincidence identical signatures again and again.

When the TC receives a TFO_REQ with an appropriate signature and TFO is possible, it enters the Contact State.

If the TC receives a TFO_ACK to a previously sent TFO_REQ, TFO_Protocol enters the Mismatch State, if immediate TFO establishment is not possible.

If immediate TFO establishment is possible, TFO_Protocol enters directly the Konnect State in the case of Non_AMR Codec Types. If immediate TFO establishment is possible in case of an AMR or AMR-WB Codec Type, the TFO_Protocol enters the Wait_RC State, before it goes on to the Konnect State.

If the TC receives TFO Frames in the First_Try State, it should assume that a TFO might have been established previously and was recently broken because of a local handover. The TC should then enter the Fast_Try State.

9.2.2 Continuous_Retry State

In this state, TFO Contact has existed either by TFO Messages or by TFO Frames, but was interrupted and sync was lost. The TC sends a maximum number of regular TFO_REQ Messages continuously in order to test, if TFO could be re-established. In case of Runout of TFO messages, the TFO_Protocol enters the Periodic_Retry State.

9.2.3 Periodic_Retry State

The Periodic_Retry state is typically entered from Continuous_Retry in the case of Runout of TFO messages. The TFO_Protocol tests from time to time by sending a single TFO_REQ_L message, if TFO could be re-established. As soon as a TFO Message is received, TFO_Protocol leaves this State.

NOTE: Since no contiguous transmission of TFO Messages is ongoing, possible IPEs may be unsynchronised.

9.2.4 Monitor State

In this state the TC monitors the PCM samples for TFO messages or TFO Frames, but it does not send any TFO messages or TFO frames. As soon as a TFO message has been received from a distant partner, the TC knows that a TFO Partner exists. Moreover, it knows that the transmission path from the distant partner is digitally transparent. The TC may already now see, whether TFO is possible, but it must ensure that all IPEs are synchronised. It therefore transits into the Continuous_Retry state. If no TFO is possible, the TFO_Protocol informs its local BSS/RAN and transits into the Mismatch state by sending back TFO_REQ_L messages.

Option: The incoming PCM stream may be searched in the Monitor state for the occurrence of any PCM pattern that is constant for at least 500ms. If such a long constant pattern is detected, then a transition back into Wakeup may be performed to re-trigger the TFO Negotiation. This search need not be performed longer than 30 seconds after entering the Monitor state.

NOTE: Since no contiguous transmission of TFO Messages is ongoing, possible IPEs may be unsynchronised.

9.2.5 Mismatch State

In this state it is obvious from a previous contact that a distant TFO Partner exists, but TFO establishment was not possible because of incompatible codec types or codec configurations. The TC waits without sending TFO messages or TFO frames until the mismatch situation is resolved.

NOTE: Since no contiguous transmission of TFO Messages is ongoing, possible IPEs may be unsynchronised.

9.3 Contact State

In this state the TFO_Protocol knows that there is a distant TFO Partner, which has sent TFO_REQ. The Codecs do match and the ACSs are compatible, or Immediate Codec Type Optimisation is possible (see below). The link from the distant partner is transparent. Now TFO_ACK need to be sent to check the transparency of the link to the distant partner.

After the exchange of TFO_REQ and/or TFO_ACK messages, it may become obvious that a preferred TFO configuration is possible when changing the codec type at the local and/or the distant side. For example, this is the case when both sides support AMR-WB but one side is currently using AMR-NB (in this case, Immediate Codec Type Optimisation is an alternative to Codec Mismatch Resolution). In this case, the TFO protocol stays in the Contact state and performs an Immediate Codec Type Optimization (see 11.7). After the codecs have been changed, the normal protocol flow continues.

As soon as a TFO_ACK or TFO_TRANS from a distant partner has been received, the TC knows that the links in both directions are digitally transparent. In the case of a Non_AMR Codec Type the TC sends TFO_TRANS to bypass the IPEs and starts sending TFO Frames, and the TFO_Protocol transits into Konnect State. In the case of an AMR or AMR-WB Codec Type the TC sends a Rate Control Command downlink to its BTS/RNC in order to steer the uplink Codec Mode down to the TFO_Setup_Mode for a safe TFO Setup. Additionally, TFO_ACK is sent to the distant TFO Partner and the TFO_Protocol transits into the Wait_RC State.

9.4 Preparation

9.4.1 Wait_RC State

This State exists only when the local used Codec Type is an AMR or AMR-WB Codec. For all other Codec Types this State is not entered and all transitions go instead directly into Konnect State.

The state WAIT_RC is typically entered when a TFO_ACK message is received in Contact State. Rate control is done. In GSM, a TFO_Soon message is sent to the BTS. In 3G a Rate Control command is sent to the RNC.

In this Wait_RC State the TFO_Protocol waits for the acknowledgement from the BTS / RNC that the Rate Control Command has been received and executed. Then the TC sends TFO_TRANS to bypass the IPEs, starts sending TFO Frames and TFO_Protocol transits into the Konnect State.

9.4.2 Konnect State

In the Konnect state the TC sends TFO Frames and possibly embedded TFO Messages as long as it receives correct TFO Messages.

The first received TFO Frame causes the transition into the Operation State.

If no TFO Frames are received within a certain period, the TC transits to the Failure State.

9.5 Operation State

In this State – the Main State of TFO_Protocol – the TC sends and receives TFO Frames, thus the TFO Connection is fully operating. TFO Messages may occur embedded into TFO Frames.

9.6 Local Handover

9.6.1 Fast_Try State

When the TC is in First_Try and suddenly receives TFO Frames and the Codecs do match, then there is a high probability that a local handover has initialised the TC into an existing TFO connection and a fast TFO establishment is likely. The TFO_Protocol has still to check, whether the link to the distant TFO Partner is (already) transparent. This is done by the specific TFO_DUP Message.

Since the handover must have been a local handover, i.e. close to the (new) TC, it can be assumed that the possibly existing IPEs are still in transparent mode and TFO Messages therefore pass through directly.

9.6.2 Fast_Contact State

This State is entered from First_Try via Fast_Try, if TFO Frames and then TFO_SYL Messages are received. The TC continues to send TFO_DUP Messages, until TFO Frames are received again. Then it immediately starts to send TFO Frames, with a TFO_TRANS embedded into the first TFO Frames. The TC transits directly to Operation State.

9.7 Distant Handover, TFO Interruption

9.7.1 Sync_Lost State

If the TC was in Operation State and suddenly the TFO Frame synchronisation is lost, then the TC enters the Sync_Lost State for a short while, before it transits to Continuous_Retry.

If synchronisation was lost due to a distant handover, then a fast TFO establishment might be possible and the TC enters Operation State soon again. In Sync_Lost it expects TFO_DUP Message as confirmation of the distant handover. Then it transits to Re_Konnect.

9.7.2 Re_Konnect State

This State is entered from Operation via Sync_Lost, if TFO_DUP Messages are received. The TC starts immediately to send TFO Frames again, with a TFO_TRANS embedded into the first TFO Frames. The TC transits back to Operation State, as soon as TFO Frames are received, again.

9.7.3 TFO_Term

This State is entered when TFO is disabled by either the local or distant TRAU/TC. The TRAU/TC stops then sending TFO frames but still accepts receiving TFO frames and messages sent by the distant TRAU/TC.

When the TFO termination has been initiated locally the TRAU/TC transits through this state before entering to Not_Active state after the TFO termination has been acknowledged by the distant side.

When the TFO termination has been initiated by the distant TRAU/TC, the TRAU/TC enters in MONITOR state when TFO frames are no more received.

9.8 Failure State

This State is entered when the distant partner shows an incorrect behaviour. The TC then sends pure PCM samples and waits for the failure to disappear. It does not send TFO Frames or TFO Messages.