C.1 Example of feedback and adaptation for speech and video
26.1143GPPIP Multimedia Subsystem (IMS)Media handling and interactionMultimedia telephonyRelease 18TS
C.1.1 Introduction
This annex gives the outline of possible example adaptation implementations that make use of adaptation signalling for speech as described in section 10.2. Several different adaptation implementations are possible and the examples shown in this section are not to be seen as a set of different adaptive schemes excluding other designs. Implementers are free to use these examples or to use any other adaptation algorithms. The examples are based on measuring the packet loss rate (PLR) but Annex C.1.3.1 describes how the measured frame loss rate (FLR) can be used instead of the PLR. A real implementation is free to use other adaptation triggers. The purpose of the section is to show a few different examples of how receiver state machines can be used both to control the signalling but also to control the signalling requests. Notice that the MTSI clients can have different implementations of the adaptation state machines.
The annex is divided into three sections:
– Signalling considerations – Implementation considerations on the signalling mechanism; the signalling state machine.
– Adaptation state machines – Three different examples of adaptation state machines either using the full set of adaptation dimensions or a subset thereof.
– Other issues and solutions – Default actions and lower layer triggers.
In this annex, a media receiver is the receiving end of the media flow, hence the request sender of any adaptation request. A media sender is the sending entity of the media, hence the request receiver of the adaptation request. The three different adaptation mechanisms available; bit-rate, packet-rate and error resilience, represents different ways to adapt to current transport characteristics:
– Bit-rate adaptation. Reducing the bit-rate is in all examples shown in this section the first action done whenever a measurement indicating that action is needed to further optimize the session quality. A bit-rate reduction will reduce the utilization of the network resources to transmit the data. In the radio case, this would reduce the required transmission power and free resources either for more data or added channel coding. It is reasonable to assume, also consistent with a proper behaviour on IP networks, that a reduction of bit-rate is a valid first measure to take whenever the transport characteristics indicate that the current settings of the session do not provide an optimized session quality.
– Packet-rate adaptation. In some of the examples, packet-rate adaptation is a second measure available to further adapt to the transport characteristics. A reduction of packet rate will in some cases improve the session quality, e.g. in transmission channels including WLAN. Further, a reduction of packet rate will also reduce the protocol overhead since more data is encapsulated into each RTP packet. Although robust header compression (RoHC) can reduce the protocol overhead over the wireless link, the core network will still see the full header and for speech data, it consists of a considerable part of the data transmitted. Hence, packet-rate adaptation serves as a second step in reducing the total bit-rate needed for the session.
– Error resilience. The last adaptive measure in these examples is the use of error resilience measures, or explicitly, application level redundancy. Application level redundancy does not reduce the amount of bits needed to be transmitted but instead transmit the data in a more robust way. Application level redundancy should only be seen as a last measure when no other adaptation action has succeeded in optimizing the session quality sufficiently well. For most normal use cases, application level redundancy is not foreseen to be used, rather it serves as the last resort when the session quality is severely jeopardized.
C.1.2 Signalling state considerations
The control of the adaptation signalling can by itself be characterized as a state machine. The implementation of the state machine is in the decoder and each MTSI client has its own implementation. The decoder sends requests as described in clause 10.2 to the encoder in the other end.
The requests that are transmitted can be queued up in a send buffer to be transmitted the next time an RTCP-APP packet is to be sent. Hence, a sender might receive one, two or all three receiver requests at the same time. It should not expect any specific order of the requests. A receiver shall not send multiple requests of the same type in the same RTCP-APP packet. Transmission of the requests should preferably be done immediately using the AVPF early mode but in some cases it may be justified to delay the transmission a limited time or until the next DTX period in order to minimize disturbance on the RTP stream, in the latter case monitoring of the RTP stream described below must take the additional delay into account.
To summarize:
– A request can be sent immediately (alone in one RTCP-APP packet) but the subsequent RTCP-APP packet must follow the transmission rules for RTCP.
– RTCP-APP packets may be delayed until the next DTX period.
Reception of the transmitted RTCP-APP packets is not guaranteed. Similar to the RTP packets, the RTCP packets might be lost due to link losses. Monitoring that the adaptation requests are followed can to be done by means of inspection of the received RTP stream.
For various reasons the requests might not be followed even though they received successfully by the other end. This behaviour can be seen in the following ways:
– Request completely ignored: An example is a request for 1 frame/packet which might be rejected as the MTSI client decides that the default mode of operation 2 frames/packet or more and a frame aggregation reduction compared to the default state is not allowed.
– Request partially followed: An example here is when no redundancy is received and a request for 100 % redundancy with 1 extra frame offset is made which may be realized by the media sender as 100 % redundancy with no extra offset. Another example is when a request for 5.9 kbps codec rate is sent and it is realized as e.g. 6.7 kbps codec rate. Table C.1 displays how the requests and realizations are grouped. E.g. it can be seen (if Ninit =1) that a request for 3 frames per packets realized as 2 frames per packet is considered to be fulfilled.
Table C.1: Distinction of different settings for frame aggregation,
redundancy and codec mode settings
|
Codec rate |
Frame aggregation |
Redundancy |
|
Highest rate in mode set |
Ninit frame per packet |
No redundancy |
|
All other codec rates |
≥ Ninit+1 frames per packet |
≥ 100 % redundancy , arbitrary offset |
In table C.1 above Ninit is 1 in most cases which corresponds to 1 frame per packet. In certain cases Ninit might have another value, one such example is E-GPRS access where Ninit may be 2. Ninit is given by the ptime SDP attribute.
NOTE: Special care in the monitoring should be taken when DTX is used as DTX SID update packets are normally not aggregated or transmitted redundant. Important is also that it takes at least one roundtrip before the effect of a request is seen in the RTP flow, if transmission of RTCP is delayed due to e.g. bandwidth requirements this extra delay must also be taken into account in the monitoring.
If the requests are not followed as requested, the request should not be repeated infinitely as it will increase the total bit-rate without clear benefit. In order to avoid such behaviour the following recommendations apply:
– Partially fulfilled requests should be considered as obeyed.
– If a new request is not fulfilled within T_RESPONSE ms, the request is repeated again with a delay between trials of 2*T_RESPONSE ms. If the three attempts have been made without sender action, it should be assumed that the request cannot be fulfilled. In this case, the adaptation state machine will stay in the previous state or in a state that matches the current properties (codec mode, redundancy, frame aggregation). Any potential mismatch between define states in the adaptation state machine and the current properties of the media stream should resolved by the request sender.
– The default mode of operation for a MTSI client if the RTCP bandwidth for the session is greater than zero is that the requests received should be followed. Ignoring requests should be avoided as much as possible. However, it is required that any signalling requests are aligned with the agreed session parameters in the SDP.
In some cases the adaptation state machine may go out-of-synch with the received RTP stream. Such cases may occur if e.g. the other MTSI client makes a reset. These special cases can be sensed, e.g. through a detection of a large gap in timestamp and/or sequence number. The state machine should then reset to the default state and start over again.
The signalling state machine has three states according to table C.2.
Table C.2: Signalling state machine states
|
State |
Description |
|
T1 |
Idle state: This is the default state of the signalling state machine. The signalling state should always return here after a state transition and when it has been detected that the media sender has followed the request, either completely or partially. The signalling state machine remains in this state as long as the selected adaptation is "stable", i.e. as long as the adaptation measures are appropriate for the current operating conditions. When it has been detected that the operating conditions has changed so much that the current adaptation measures are no longer appropriate then the adaptation function triggers a request signalling and the signalling state machine goes to state T2. |
|
T2 |
In this state, the received RTP stream is monitored to verify that the properties of a given adaptation state (redundancy, frame aggregation and codec mode) are detected in the received RTP stream. If necessary, some of the requests are repeated maximum 3 times. If any of the properties is considered to be not fulfilled, the signalling state machine enters state T3. |
|
T3 |
In this state, the properties of the RTP stream (redundancy, frame aggregation and codec rate) is reverted back to the properties of the last successful state and a new state transition is tested in T2, or alternatively the adaptation state is set to the state that matches the current properties (codec mode, redundancy, frame aggregation). |
Figure C.1: Signalling state machine, implemented in order
to ensure safe adaptation state transitions
C.1.3 Adaptation state machine implementations
C.1.3.1 General
The example adaptation state machines shown in this section are different realizations of the control algorithm for the adaptation requests. Note that this does not include how the actual signalling should be done but how various triggers will result in the transmission of different requests.
The example adaptation state machines make use of the signalling state machine outlined in clause B.2. Common to all adaptation state machines is that it is possible to implement all versions in the same code and just exclude appropriate states depending on desired mode of operation. All examples can transit between a number of states (denoted S1…S4). In these examples, it is assumed that the codec is AMR-NB and that it uses two coding rates (AMR 12.2 and AMR 5.9). However, this is not a limitation of the adaptation mechanism by itself. It is only the scenario used in these examples.
Since the purpose of the adaptation mechanism is to improve the quality of the session, any adaptation signalling is based upon some trigger; either a received indication or a measurement. In the case of a measurement trigger, it is important to gather reliable statistics. This requires a measurement period which is sufficiently long to give a reliable estimation of the channel quality but also sufficiently short to enable fast adaptation. For typical MTSI scenarios on 3GPP accesses, a measurement period in the order of 100 packets is recommended. Further, in order to have an adaptation control which is reliable and stable, a hangover period is needed after a new state has been entered (typically 100 to 200 packets). An even longer hangover period is suitable when transiting from an error resilient state or a reduced rate into the default, normal state. In the below examples, it is assumed that the metric used in the adaptation is the packet loss rate measured on the application layer. It is possible to use other metrics such as lower layer channel quality metrics.
NOTE: Mode change requests must follow the rules outlined in clause 5.2.1.
The example solution is designed based on the following assumptions:
– When the packet loss rate increases, the adaptation should:
– First try with a lower codec mode rate, i.e. bit-rate back off.
– If this does not improve the situation, then one should try with packet rate back-off by increasing the frame aggregation.
– If none of these methods help, then application layer redundancy should be added to save the session.
– When the packet loss rate increases, one should try to increase the bit rate in a "safe" manner. This is done by probing for higher bit rates by adding redundancy.
– The downwards adaptation, towards lower rates and redundancy, should be fast while the upwards adaptation should be slow.
– Hysteresis should be used to avoid oscillating behaviour between two states.
A description of the different states and what trigger the transition into the respective state is given in table C.3.
Table C.3: Adaptation state machine states and their meaning
|
State |
Description |
|
S1 |
Default/normal state: Good channel conditions. This state has the properties: – Codec rate: Highest mode in mode set. – Frame aggregation: Equal to the ptime value in the agreed session parameters. – Redundancy: 0%. |
|
S2 |
In this state the encoding bit-rate and the packet rate is reduced. The state is divided into 2 sub states (S2a and S2b). In state S2a the codec rate is reduced and in state S2b the packet rate is also reduced (the frame aggregation is increased). State S2a may also involve a gradual decrease of the codec-rate in order to be in agreement with the session parameters. If no restrictions are in place regarding mode changes (i.e. such as only allowing changing to a neighbouring mode), it changes bit-rate to the target reduced bit-rate directly. If restrictions are in place, several mode changes might be needed. This state has the properties: – Codec rate: Any codec rate except the highest rate in mode set, preferably a codec rate that is roughly half the highest rate. – Frame aggregation: – S2a: Equal to the ptime value in the agreed session parameters. – S2b: ptime+N*20ms where N > 1, limited by max-ptime. – Redundancy: 0%. |
|
S3 |
This is an interim state where the total bit-rate and packet rate is roughly equal to state S1. 100% redundancy is used with a lower codec mode than S1. This is done to probe the channel band-width with a higher tolerance to packet loss to determine if it is possible to revert back to S1 without significantly increase the packet loss rate. This state has the properties: – Codec rate: Any codec rate except the highest rate in mode set, preferably a codec rate that is roughly half the highest rate, target total rate (with redundancy) should be roughly the same as in S1. – Frame aggregation: Equal to the ptime value in the agreed session parameters. – Redundancy: 100%. |
|
S4 |
In this state the encoding bit-rate is reduced (the same bit-rate as in S2) and redundancy is turned on. Optionally also the packet rate is kept the same as in state S2. This state has the properties: – Codec rate: Any codec rate except the highest rate in mode set, preferably a codec rate that is roughly half the highest rate. – Frame aggregation: Equal to the ptime value in the agreed session parameters. – Redundancy: 100%, possibly with offset. |
The parameters and other definitions controlling the behaviour of the adaptation state machine are described in table C.4. Example values are also shown, values which give good performance on a wide range of different channel conditions.
Table C.4: State transition definitions, thresholds and temporal adaptation control parameters
|
Parameter |
Value/meaning |
Comment |
|
PLR_1 |
3 % |
|
|
PLR_2 |
1 % |
|
|
PLR_3 |
2 % |
|
|
PLR_4 |
10 % |
|
|
N_INHIBIT |
1 000 frames |
A random value may be used to avoid large scale oscillation problems. |
|
N_HOLD |
5 measurement periods |
|
|
T_RESPONSE |
500 ms |
Estimated response time for a request to be fulfilled. |
|
Packet loss burst |
2 or more packet losses in the last 20 packets. |
As described in Annex C.1.1, the frame loss rate (FLR) can be used instead of the packet loss rate to trigger the adaptation. The benefit with using FLR is that this metric can (and should) include the late losses that occur if frames are received too late to be useful for decoding. Table C.4a shows thresholds that can be used for FLR if the FLR-triggered adaptation is used instead of the PLR-triggered adaptation.
Table C.4a: FLR thresholds when using the frame loss rate to control the adaptation
|
Parameter |
Value/meaning |
Comment |
|
FLR_1 |
3 % |
Used instead of PLR_1 |
|
FLR_2 |
1 % |
Used instead of PLR_2 |
|
FLR_3 |
2 % |
Used instead of PLR_3 |
|
FLR_4 |
3 % |
Used instead of PLR_4 |
|
Frame loss burst |
2 or more frame losses in the last 20 frames. |
Replaces packet loss burst |
The adaptation state machines shown in Annex C.1.3.2, C.1.3.3 and C.1.3.4 can be used also for FLR-triggered adaptation by applying the following modifications:
– The media receiver needs to measure the frame loss rate instead of the packet loss rate. The frame loss rate includes late losses.
– The PLR thresholds need to be replaced with the corresponding FLR thresholds, as shown in Table C.4a.
The state machines are otherwise the same.
C.1.3.2 Adaptation state machine with four states
The first example utilizes all adaptation possibilities, both in terms of possible states and transitions between the states. Figure C.2 shows the layout of the adaptation state machine and the signalling used in the transitions between the states.
Figure C.2: State diagram for four-state adaptation state machine
State transitions:
Below are listed the possible state transitions and signalling that is involved. Note that the state can go from S1 to either S2 or state S4, this is explained below:
Table C.5: State transitions for four-state adaptation state machine
|
State transition |
Conditions and actions |
|
S1 🡪 S2a |
Condition: Packet loss ≥ PLR_1 or packet loss burst detected. |
|
S2a 🡪 S2b |
Condition: Packet loss ≥ PLR_1. This state transition occurs if the packet loss is still high despite the reduction in codec rate. A request is sent to reduce the packet rate is reduced by means of an RTCP_APP_REQ_AGG message. |
|
S2b 🡪 S2a |
Condition: Packet loss ≤ PLR_ 2 for N_HOLD consecutive measurement periods. This state transition involves an increase of the packet rate restoring it to the same value as in S1. The request transmitted is RTCP_APP_REQ_AGG. If the state transition S2b🡪S2a🡪S2b occurs in sequence, the state will be locked to S2b for N_INHIBIT frames to avoid state oscillation. |
|
S2a 🡪 S3 |
Condition: Packet loss ≤ PLR_2 for N_HOLD consecutive measurement periods. A request to turn on 100% redundancy is transmitted by means of request RTCP_APP_REQ_RED. |
|
S3 🡪 S2a |
Condition: Packet loss ≥ PLR_3. Same actions as in transition from, S1🡪S2a. If the transition S2a🡪S3🡪S2a🡪S3🡪S2a occurs, the S3 is disabled for N_INHIBIT frames. |
|
S3 🡪 S1 |
Condition: Packet loss ≤ PLR_2 for N_HOLD consecutive measurement periods. A request to turn off redundancy is transmitted as RTCP_APP _REQ_RED. Encoding bit-rate is increased by means of RTCP_APP_CMR. |
|
S2b 🡪 S4 |
Condition: Packet loss ≥ PLR_3. A request to turn on 100% redundancy is transmitted by means of request RTCP_APP_REQ_RED. The packet rate is restored to same value as in S1 using RTCP_APP _REQ_AGG. |
|
S4 🡪 S2b |
Condition: 1. If the previous transition was S2b🡪S4 and packet loss ≥ to 4*PLR@ S2b🡪S4 (packet loss considerably increased since transition to state S4). 2. If previous transition was S1🡪S4 and packet loss >= PLR_4. |
|
S4 🡪 S1 |
Condition: Packet loss < PLR_3 for N_HOLD consecutive measurement periods. A request to turn off redundancy is transmitted using RTCP_APP _REQ_RED. Encoding bit-rate is requested to increase using RTCP_APP_CMR. |
|
S1 🡪 S4 |
Condition: Packet loss ≥ PLR_1 or packet loss burst detected AND the previous transition was S4🡪S1, otherwise the transition S1🡪S2a will occur. A request to turn on 100% redundancy is transmitted using RTCP_APP_REQ_RED. The encoding bit-rate is requested to be reduced (in the example from AMR 12.2 to AMR 5.9) using RTCP_APP_CMR. |
C.1.3.3 Adaptation state machine with four states (simplified version without frame aggregation)
This example is a simpler implementation with the frame aggregation removed.
Figure C.3: State diagram for simplified four-state adaptation state machine
State transitions:
Below are listed the possible state transitions and signalling that is involved.
Table C.6: State transitions for simplified four-state adaptation state machine
|
State transition |
Conditions and actions |
|
S1 🡪 S2a |
Condition: Packet loss ≥ PLR_1 or packet loss burst detected. |
|
S2a 🡪 S3 |
Condition: Packet loss ≤ PLR_2 for N_HOLD consecutive measurement periods. A request to turn on 100% redundancy is transmitted by means of request RTCP_APP_REQ_RED. |
|
S3 🡪 S2a |
Condition: Packet loss ≥ PLR_3. Same actions as in transition from, S1🡪S2a. If the transition S2a🡪S3🡪S2a🡪S3🡪S2a happens in sequence state S3 is disabled for N_INHIBIT frames. |
|
S3 🡪 S1 |
Condition: Packet loss ≤ PLR_2 for N_HOLD consecutive measurement periods. A request to turn off redundancy is transmitted as RTCP_APP _REQ_RED. Encoding bit-rate is increased by means of RTCP_APP_CMR. |
|
S2a 🡪 S4 |
Condition: Packet loss ≥ PLR_3. A request to turn on 100% redundancy is transmitted by means of request RTCP_APP_REQ_RED. |
|
S4 🡪 S2a |
Condition: Packet loss ≥ to 4*PLR@ S2b🡪S4 (packet loss considerably increased since transition to state S4). This is indicative of that the total bit-rate is too high and that it is probably better to transmit with a lower packet rate/bit-rate instead. This case might occur if the packet loss is high in S2a due to a congested link, a switch to redundant mode S4 will then increase the packet loss even more. |
|
S4 🡪 S1 |
Condition: Packet loss < PLR_3 for N_HOLD consecutive measurement periods. A request to turn off redundancy is transmitted using RTCP_APP _REQ_RED. Encoding bit-rate is requested to increase using RTCP_APP_CMR. |
C.1.3.4 Adaptation state machine with two states
This example is an implementation with the redundant states removed.
Figure C.4: State diagram for two-state adaptation state machine
State transitions:
Below are listed the possible state transitions and signalling that is involved.
Table C.7: State transitions for two-state adaptation state machine
|
State transition |
Conditions and actions |
|
S1 🡪 S2a |
Condition: Packet loss ≥ PLR_1 or packet loss burst detected. A failed transition counter counts the number of consecutive switching attempts S2a🡪S1 that fails. In the number of failed attempts is two or more state S1 is inhibited for N_INHIBIT frames. A failed transition attempt occurs if the previous transition was S2a🡪S1 and the state transition immediately occurs back to S2a. |
|
S2a 🡪 S2b |
Condition: Packet loss ≥ PLR_1. This state transition occurs if the packet loss is still high despite the reduction in codec rate. A request is sent to reduce the packet rate is reduced by means of an RTCP_APP_REQ_AGG message. |
|
S2b 🡪 S2a |
Condition: Packet loss ≤ PLR_2 for N_HOLD consecutive measurement periods. This state transition involves an increase of the packet rate. Also packet rate is restored to same value as in State (1) RTCP_APP_REQ_AGG. If the state transition S2b🡪S2a🡪S2b occurs in sequence, the state will be locked to S2b for N_INHIBIT frames. |
|
S2a 🡪 S1 |
Condition: Packet loss ≤ PLR_2 for N_HOLD consecutive measurement periods. Redundancy is turned on (100 %) by means of request RTCP_APP_REQ_RED. |
C.1.3.5 Adaptation when using ECN
This example shows how ECN may be used to trigger media bit-rate adaptation. ECN can be used in combination with other adaptation triggers, for example packet loss triggered adaptation schemes or frame loss rate triggered adaptation schemes, although this is not included in this example.
In this example, the ECN-triggered adaptation is configured using the set of parameters as described in Table C.8.
Table C.8: Configuration parameters used for the ECN triggered adaptation in this example
|
Parameter |
Description |
|
ECN_min_rate |
Used in accordance with Table 10.1 |
|
ECN_congestion_wait |
Used in accordance with Table 10.1 |
Figure C.5 shows how the codec rate changes over the session if there is no congestion and therefore no ECN-CE marking (and no packet losses). The codec modes that can be used during the session are negotiated at session setup. In this case it is assumed that the recommended four AMR {4.75, 5.9, 7.4 and 12.2 kbps} codec modes can be used in the session. It is further assumed that the highest codec mode allowed in the session is AMR 12.2 kbps and the ECN_min_rate corresponds to AMR 5.9 kbps, see Clause 10.2.0.
NOTE: ECN can also be used for AMR-WB in a corresponding way, with the difference that the highest codec mode and ECN_min_rate would be selected based on the AMR-WB codec mode rates.
Figure C.5: Example of codec mode usage in a session
The session starts with the Initial Codec Mode (ICM), i.e. the AMR 5.9 kbps codec mode, see Clause 7.5.2.1.6. The receiving MTSI client evaluates the performance, for example by measuring the packet loss rate and detecting ECN-CE marked packets, and adapts the codec mode upwards (by sending adaptation requests backwards to the sender) in steps as long as no ECN-CE marked packets and no (or only marginal) performance problems are detected. In this case, this means that the MTSI client starts using the AMR 5.9 kbps mode, then switches to the AMR 7.4 kbps mode and then to the AMR 12.2 kbps mode.
The step-wise upswitching is used because the receiving MTSI client does not know whether the new and higher rate is sustainable or not. The transmission performance for each new rate needs to be verified over a time period before further upswitching can be attempted. If the new bit rate would prove to be not sustainable then the receiving MTSI client would switch back to the previously used rate or even a lower rate (not shown in these figures).
Figure C.6 shows how ECN-CE marked packets may trigger codec adaptation.
Figure C.6: Example of how ECN may trigger codec adaptation
Again, the session starts with ICM, i.e. the AMR 5.9 kbps codec mode. The MTSI client evaluates the performance, for example the packet loss rate and/or ECN-CE marked packets, and adapts the codec mode upwards if it is deemed possible to do so. During the upwards adaptation, the receiver detects in this example a congestion event since ECN-CE is set for at least one of the received IP packets. In this case a fast back-off strategy is used and the receiver therefore sends an adaptation request back to the sender using RTCP APP with a request to switch to a low codec mode, in this case to adapt to the AMR 5.9 kbps mode. The AVPF profile allows for sending an (one) RTCP packet without waiting for the normal RTCP transmission interval, even if a regular compound RTCP was recently transmitted. This gives a faster reaction to ECN-CE.
After the down-switch, a waiting time is used to prevent upswitch too soon after the congestion event since too early upswitch is likely to trigger further congestion. The receiver uses RTCP APP also for the adaptation requests for upswitch. It is beneficial to use the normal RTCP transmission rules, defined for the AVP profile, for the upswitch adaptation signalling because this enables using the AVPF transmission rules in case congestion would occur immediately after the upswitch.
The response to the ECN-CE marking, the waiting time and the upswitching after a congestion event is the same regardless of when the congestion occurs, which is shown in Figure C.7. This is because the MTSI client is evaluating if the bit rate is sustainable also after switching up to the high bit rate.
Figure C.7: Example of codec mode usage in a session
Figure C.7 also shows how the fast down-switch gives a rapid codec mode switch from the AMR 12.2 kbps to the AMR 5.9 kbps mode. The codec mode request (CMR) sent from the receiver may suggest a direct switch from the AMR 12.2 kbps mode to the AMR 5.9 kbps mode. However, if the MTSI client is inter-working with a CS GERAN then mode changes will be limited in the session setup to every other frame border and also to neighboring modes. The MTSI client obviously has to follow such rules for mode changes, if they are defined in the session setup. The sender may therefore be prevented from following the CMR directly and it may take a few frames until the target codec mode is reached.