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.
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.
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.
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.
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.
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.
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:
This example is a simpler implementation with the frame aggregation removed.
State transitions:
Below are listed the possible state transitions and signalling that is involved.
This example is an implementation with the redundant states removed.
State transitions:
Below are listed the possible state transitions and signalling that is involved.