3GPP MTSIMA MO contains a set of parameters which can be used in the construction of adaptation state machines. If available, information on the expected behavior of the network, such as the scheduling strategy applied to eNodeB, can assist the design and calibration process. Basically the receiver estimates the encoding and payload packetization status of the sender, and transmits appropriate RTCP-APP messages when the state of adaptation state machine needs to be switched. Each PLR in Table 17.1 is used to specify the conditions, usually as a threshold, to enter or exit a state. MAX, LOW, STATE_REVERSION, and RED_INEFFECTIVE correspond to PLR_1, PLR_2, PLR_3, and PLR_4 in Annex C respectively. Once the measured PLR exceeds or falls below the thresholds, while meeting certain conditions, adaptation state machine triggers the programmed transitions. A subset of PLRs can be used to construct adaptation state machines with fewer states. For example, the two-state adaptation state machine in Annex C can be built with MAX and LOW. DURATION_MAX, DURATION_LOW, DURATION_STATE_REVERSION, and DURATION_RED_INEFFECTIVE can be used to specify the duration of sliding window over which MAX, LOW, STATE_REVERSION, and RED_INEFFECTIVE PLR are observed and computed. DURATION is reserved for the case when it is not necessary to separately specify the durations. N_HOLD allows setting of the duration as an integer multiple of DURATION. With each pair of a PLR and a DURATION, the observation period of each PLR can be controlled and the sensitivity of each transition path can be tailored to meet the requirements. For example, larger DURATION values are likely to smooth out the impact of bursty loss of packets and reduce the likelihood of frequent transitions between states, i.e., the ping-pong effects, but can delay the reaction to events that require immediate repairing actions. In general, transitions to states designed for better transmission conditions need to be taken more conservately than transitions to states for worse transmission conditions. Other requirements can be combined with PLR to refine the conditions for transitions. Packet loss burst (PLB) refers to a davastating event in which a large number of packets are lost during a limited period. Immediate measures, such as changing the bit rate or payload packetization are required to reduce the impact on the perceived speech quality. As PLR and PLR/DURATION enable detailed specification of PLR, PLB can be described efficiently with PLB/LOST_PACKET and PLB/DURATION. The parameters ICM/INITIAL_CODEC_RATE, ICM/INIT_WAIT and ICM/INIT_UPSWITCH_WAIT can be used to control the rate adaptation during the beginning of the session. ICM/INITIAL_CODEC_RATE is used to define what codec mode should be used when starting the encoding for the RTP stream. In EVS Primary mode, ICM/INITIAL_CODEC_BANDWIDTH is used to define which audio bandwidth should be used when starting the encoding for the RTP stream. ICM/INIT_WAIT defines the period over which the sending MTSI client in terminal should use the Initial Codec Mode when ECN is not used. If no codec mode request or other feedback information is received within this period then the sender is allowed to adapt to a higher rate. Since it is unknown in the beginning of the RTP stream whether the transmission path can support higher rates, the adaptation to higher bit rates needs to be conservative. It is therefore recommended that when adapting to a higher rate the sender increases the rate only to the next higher rate in the list of codec modes allowed in the session. It is also recommended that the sender waits for a while in-between consecutive up-switches, to give the receiver a chance to evaluate whether the new rate can be sustained. This waiting period in-between consecutive up-switches can be controlled with the ICM/INIT_UPSWITCH_WAIT parameter when ECN is not used. For the channel aware mode of EVS Primary, ICM/INIT_PARTIAL_REDUNDANCY_OFFSET_SEND and INIT_PARTIAL_REDUNDANCY_OFFSET_RECV can be used to configure the initial redundancy offset for the send and the receive directions respectively. When ECN is used in the session, the ECN/INIT_WAIT and ECN/INIT_UPSWITCH_WAIT parameters are used instead of the ICM/INIT_WAIT and ICM/INIT_UPSWITCH_WAIT parameters, respectively. N_INHIBIT can be used to limit the earliest time for the next transition, after transition is temporarily disabled due to frequent transitions among a limited number of states. Use of N_INHIBIT is suggested as a measure to avoid unnecessary transtions during rapid fluctuations of transmission conditions. It is left as the discretion of the implementation to handle RTCP-APP messages received before the sender is allowed to transition again. T_RESPONSE refers to the maximum period the receiver can tolerate, before declaring that either the transmitted RTCP-APP message was lost or its execution was denied by the sender. After the timer expires, the receiver may retransmit the request or transmit a new request, or choose to be satisfied with current status. Adaptation state machines using above parameters collect the information on transmission path by analysing the packet reception process. Another, more direct source of information can be provided by network nodes, such as eNodeB, in the form of Explicit Congestion Notification (ECN) to IP. A key benefit of ECN is more refined initiation of adaptation in which the receiver can be aware of incoming deterioration of transmission conditions even before any packets are dropped by network node, i.e., as an early-warning scheme for congestion. STEPWISE_DOWNSWITCH can be used to control the path of bit-rate reduction, i.e., whether to directly down-switch to ECN/MIN_RATE or to gradually down-switch via several intermediate bit-rates specified in ECN/RATE_LIST. The former path may be preferred when rapid reduction of the bit-rate is required while the latter path may be employed for more graceful degradation of speech quality. To avoid premature up-switch before the congestion has been cleared, waiting periods during which the sender is not allowed to increase the bit-rate can be defined with ECN/CONGESTION_WAIT parameter. The ECN/CONGESTION_UPSWITCH_WAIT parameter is used to prevent congestion from re-occurring during the upswitch after the ECN/CONGESTION_WAIT period. To align speech adaptation of the MTSI client in terminal with the purpose of quality control or network management, not only the terminals, which might be managed by different service providers, but also the behaviour, such as scheduling strategy or ECN-marking policy, of network nodes should be considered in the construction of adaptation state machines. It is also possible to program the terminals to adapt differently, as a means of differentiating the quality of service. With 3GPP MTSIMA MO, it is possible to shape a rough trajectory of the bit rate over time-varying transmission conditions but the maximum and minimum bit rates of speech codec are determined during session setup with mode-set, which can be managed with RateSet leaf of 3GPP MTSINP MO (see clause 15). Adaptation state machines designed to recover the once reduced bit or packet rate at an earliest opportunity might be considered as an adaptation policy oriented to service quality. However, such an aggressive up-switch before the transmission conditions fully recover takes the risk of degrading the quality or even backward transitions, i.e., the ping-pong effects. Such an optimistic adaptation strategy might not necessarily result in higher quality but can influence the service quality of other terminals sharing the same link. On the other hand, adaptation state machines that increase the once reduced bit or packet rate more conservatively are likely to avoid such situations but might be late in the recovery of speech quality after the transmission conditions are restored. Even at similar total bit rates, bit stream consisting of a smaller number of larger packets can be at a disadvantage during transmission over packet networks or shared links, when the link quality deteriorates or the link becomes congested, than bit stream consisting of a larger number of smaller packets, since many types of schedulers installed in the network nodes base their decisions on the size of packets such that lower priorities are assigned to larger packets. RTCP_APP_REQ_RED, RTCP_APP_REQ_AGG, and RTCP_APP_CMR specify detailed request for the bit rate and packetization. Bit-fields of RTCP_APP_REQ_RED and RTCP_APP_REQ_AGG are restricted by parameters, such as max-red and maxptime, which are negotiated during session setup.

Compared with speech adaptation where the number of allowed bit rates from speech encoder is limited and each encoded speech frame covers the same short period, e.g., 20 ms, or contains the same number of bits when voice activity is present, video adaptation should tolerate a higher level of uncertainty in the control of the bit rate. Moreover, due to the structural dependence between encoded video frames, from motion estimation and compensation, packetization is not likely to be used as an opportunity for adaptation. This dependence necessitates not only controling the bit rate but also putting an end to error propagation with AVPF NACK or PLI. Output bit rate from video encoder depends also on the scene being encoded and even if maintaining a constant bit rate is intended, actual output bit rate is likely to fluctuate around a target value. In the design of adaptation state machines for video, this uncertainty needs to be compensated for, for example, with additional implementation margin. Encoded speech frames have a clear boundary in the bit stream and multiple speech frames can be transported over an RTP packet. In contrast, an encoded video frame, whose size depends on the bit rate, frame rate, and image size, is typically far larger than an encoded speech frame. Multiple packets are usually necessary to transport even a predicted frame, which is usually smaller than an intra frame. As in speech adaptation, basic information on transmission path can be obtained from analyzing received packet stream. However, perceived video quality can be more sensitive to PLR since the compression ratio of video is typically higher than that of speech and even a minor level of packet loss can initiate error propagation to the following predicted frames, rendering them unrecognizable. For example, at comparable PLR values, speech quality can be acceptable but video quality can be significantly damaged such that dropping the media might be considered. Two parameters for PLR, MAX and LOW, and two additional parameters for their durations, DURATION_MAX and DURATION_LOW, are available for video adaptation. PLB/LOST_PACKET and PLB/DURATION are also available for video but the fundamental differences in the frame structure need to be taken into account when the event of packet loss burst is defined for video. INC_FBACK_MIN_INTERVAL and DEC_FBACK_MIN_INTERVAL can be used to control the rate of adaptation and also the amount of signalling overhead. These two minimum intervals are provided separately since the minimum interval between the feedback messages to decrease the bit rate typically needs to be shorter than the one to increase the bit rate. The urgency of rate-decreasing conditions generally requires shorter minimum feedback intervals. Target bit rate for video is determined during session setup and can be considered as the maximum bit rate to be used during session, which can be configured with the Bandwidth leaf of 3GPP MTSINP MO. On the other hand, BIT_RATE can be used to set a lower threshold for the bit rate. Whether MIN_QUALITY/BIT_RATE/ABSOLUTE or MIN_QUALITY/BIT_RATE/RELATIVE is to be used is left as the discretion of the implementation or service provider. For example, capability of setting a fixed minimum bit rate can be necessary when the lowest quality of MTSI is required to be comparable to the quality of 3G-324M, whose bit rate for video is in general set to 47 ~ 49 kbps. If both MIN_QUALITY/BIT_RATE/ABSOLUTE and MIN_QUALITY/BIT_RATE/RELATIVE are set, the larger of these two shall be used as the minimum bit rate. In the case of speech adaptation, the MTSI client in terminal limits the initial codec mode (ICM) to a lower mode than the maximum mode negotiated, until at least one frame block or an RTCP message is received with rate control information (see clause 7.5). This policy is recommended to avoid congestion during initial phase of session when the information on transmission path is known to neither the sender nor the receiver. INITIAL_CODEC_RATE can be used for video with similar objectives as that of ICM, i.e., a warming-up process in the beginning of session. Once the session starts and few packets are lost during delivery, the receiver will attempt to increase the bit rate by transmitting TMMBR messages requesting higher bit rates until the negotiated value is reached. However, low INITIAL_CODEC_RATE can reduce the video quality at session setup when the transmission path is free of congestion. The maximum bit rate allowed for video communication in a session depends on the outcome of the SDP offer-answer negotiation. For inter-working with 3G-324M it is likely that the bit rate is limited to 47 ~ 49 kbps while for high-quality video communication it is foreseen that bit rates in the order of several hundred kbps might be used. This can be challenging when setting the ECN/MIN_RATE parameter since the configuration of the MTSI client in terminal parameters occurs rarely while the maximum allowed bit rate used for video may vary from session to session. Two parameters, ECN/MIN_RATE/ABSOLUTE and ECN/MIN_RATE/RELATIVE, are therefore provided to enable better control of the video rate adaptation algorithm. The ECN/MIN_RATE/RELATIVE parameter is provided to limit the bit range variations during a session to avoid large quality variations. The ECN/MIN_RATE/ABSOLUTE parameter is provided to avoid reducing the bit rate to an unacceptably low quality level. FRAME_RATE can be used to set a lower threshold for the frame rate. As the bit rate is controlled during adaptation between two limits, the frame rate also needs to be controlled between the limits while maintaining a balance between spatial quality and temporal resolution (see clause 10.3). As the increase in codec profile/level can result in an abrupt increase of the maximum image size, e.g., from QCIF to CIF, so can quadruple the maximum frame rate, with a fixed image size. With "imageattr" attribute, it is possible that image sizes whose maximum frame rates are unspecified by codec profile/level, such as 272x224, can be negotiated (see clause A.4). In this case, the maximum frame rate is determined as the maximum value at the maximum image size supported by the profile/level negotiated. Whether MIN_QUALITY/FRAME_RATE/ABSOLUTE or MIN_QUALITY/FRAME_RATE/RELATIVE is used to specify the lower threshold of the frame rate is left as the discretion of the implementation or service provider. If both are set, the larger of these two shall be used as the minimum frame rate. RTP_GAP can be used to set the maximum interval between received packets before the receiver considers repairing actions. During periods of severe congestion or packet loss, the receiver may not receive packets for an unexpectedly long period. Observing such gaps in the reception of packets can be used by the receiver to request the sender to decrease the bit or packet rate. In the case of severe packet loss, this gap can be detected before any other observations are made and thus allows for faster reaction, while detection of packet loss requires reception of at least one packet after the loss. However, estimating such gaps in the arrival of packets can be challenging because video encoder may not always output packets at regular intervals and typical scheduling strategy of network node, especially in the downlink, can cause jitter in the delivery of video packets. Therefore, it is recommended that RTP_GAP is set conservatively and the measured gap is based on a moving average estimate of the frame period observed by the receiver. The timestamps of the received packets allow the receiver to estimate the frame period based on the past a few received video frames. Since typical video encoders are not likely to abruptly change their encoding frame rates, this estimate can serve as a fairly reliable basis for detecting the gaps in the transport of video packets. Leaf nodes for luminance quantization parameter, H263, MPEG4, and H264, can be used to set a lower threshold for the image clarity to be maintained. Target range of the quantization parameters depends on the video codec negotiated. If the MTSI client in terminal cannot maintain the bit rate or the frame rate higher than the lower thresholds, or cannot maintain the quantization parameter lower than the higher threshold, the video stream might be put on hold, dropped, or the session might be ended, depending on the criteria for service quality or policy for network management, with HOLD_DROP_END. RAMP_UP_RATE and RAMP_DOWN_RATE can be used to control how fast the sender changes its target bit rate from its current target value to the value indicated in the most recently received TMMBR message, when the bit rate is being increased and decreased respectively. As with INC_FBACK_MIN_INTERVAL and DEC_FBACK_MIN_INTERVAL, rates for ramping up and down need to be different, as rapid ramping down is usually necessary whereas rapid ramping up is undesirable as it can cause sudden congestion in the transmission path. DECONGEST_TIME can be used to control the time spent in resolving the congestion of transmission path. Smaller values of this parameter can result in faster reduction of the bit rate while larger values can be used for slower decongestion. If the situation at the receiver does not improve at the end of initial decongesting, another round of decongestion can be attempted, or the video stream can be dropped or put on hold. From received packets, video frames are typically reconstructed to YUV format, converted to formats such as RGB, and stored in the frame buffer, before being fed to the display for visual presentation. TARGET_PLAYOUT_MARGIN_HI and TARGET_PLAYOUT_MARGIN_MIN can be used to maintain appropriate playout margin, defined as the interval between packet arrival and its properly scheduled playout. Duration of sliding window over which the interval is observed and computed can be controlled with TP_DURATION_HI and TP_DURATION_MIN. In general, video should be encoded, packetized, transmitted, de-packetized, decoded, and, played out within a total delay target. In addition, processing of video should be appropriately synchronized to that of speech. If the estimated playout margin exceeds TARGET_PLAYOUT_MARGIN_HI, it is considered that video packets are arriving too early and there remains room for higher bit rate in the transmission path. Therefore the receiver may signal the sender to increase the bit rate with TMMBR messages. If the estimated playout margin falls below TARGET_PLAYOUT_MARGIN_MIN, it is considered that video packets are arriving too late and current transmission path cannot sustain the bit rate. Therefore the receiver should signal the sender to reduce the bit rate to enable earlier arrival of video packets. X_PERCENTILE can be used to control the target playout margin but the packet arrival distribution is left to the discretion of the implementation, which might be implemented as statistical models or empirical data.

The MEDIA_ROBUSTNESS node defined under the 3GPP MTSIMA MO may be used to manage media robustness adaptation across different vendor terminals in a network. For each codec type, the MO node provides a list of codec configurations arranged from least robust to most robust. For each of these configurations, with the exception the first and last, the MO node also provides two sets of PLR threshold levels (see Figure 17.2):

• A set of high PLR thresholds that trigger the media receiver to request a more robust configuration from the media sender when the PLR is increasing in order to reduce the effects of the higher PLR on QoE, and
• A set of low PLR thresholds that trigger the media receiver to request a less robust configuration from the media sender when the PLR is decreasing in order to take advantage of the improved media quality supported at the lower PLR.

The high PLR and low PLR thresholds between two codec configurations can be set independently to avoid ping-pong switching by introducing hysteresis. The least robust configuration does not have a low PLR threshold and the most robust configuration does not have a high PLR threshold. The MO node does not describe the type of request message that shall be used for adapting the codec configuration as this is determined by the codec configuration being requested, i.e., in-band RTP CMR if requesting a speech codec mode change, RTCP-APP if it requesting speech application layer redundancy change, TMMBR for video.

The MO node also provides a flag to indicate whether PLR measurements are to be made before or after the de-jitter buffer in the receiver. Measuring before provides an estimate of the PLR over the transport link to the media receiver while measuring after provides a PLR estimate that is closer to the QoE after the media decoder. The MO node also specifies the sliding averaging window over which PLR estimates are to be calculated. The parameters are specified independent of the media codec or radio access bearer technology. In addition, vendor specific parameters of the implementation can be placed under Ext nodes. Detailed descriptions of the speech robustness adaptation parameters can be found in Table 17.1.