Proposed APU algorithm

We propose our APU algorithm based on the APU state diagram derived from Figure 7-27. The state diagram shows the desirable transitions from the current state according to our subjective testing. The APU state diagram is shown in Figure 7-27. Our objective cases to enhance is that with poor or unacceptable MOS score. Thus no transitions or enhancements for <P, A> or <A, A> or <U, A> states because they already have acceptable MOS based on the network losses indicating acceptable call quality.

Figure 7-27 APU state diagram

The simplest way to build a control algorithm is to have a target residual loss rate at the receiver after applying FEC, but our algorithm is based on choosing the optimum FEC coding scheme from three different RS codes that are commonly used in the VoIP applications [66, 68] according to the current network conditions. In our algorithm, the network conditions are measured based on the RTCP receiver reports (RRs) from generated packets. Iperf [75] can be used also for the same purpose by generating the codec‘s traffic using UDP and measuring the current network conditions. The RTCP feedback is sent back by the receiver every 5 seconds [3] but unfortunately, RTCP report does not include information about random packet lost (p) and burst ratio (q) separately. Thus, two solutions are provided around this issue [76]. The first solution is to use other unused fields (e.g.: jitter) in RTCP RRs to include p and q separately. The second solution is to assume that the loss process is Bernoulli, and not Gilbert [76]. We applied the first solution as it is more preferable especially that FEC depends on the burst ratio as well as the random packet loss rate. In our algorithm, we wait for every 5 consecutive RRs (25 seconds) to take our decision. Then the rating factor R and the overall one way delay is measured so that the current state (i.e.: <P, P>) can be deduced. Our algorithm focuses on enhancing only the MOS score (packet loss level indication) with poor or unacceptable level as these states are considered our target to enhance. The transit state is deduced by calculating the R and delay values after reconstruction using three main commonly used RS

codes in VoIP applications. It is now direct to determine whether the next state is a valid state or not by the usage of the state diagram that shows the desirable transitions deduced from Figure 7-27. We will choose the RS code to be used with the corresponding state having minimum APU score. It is possible to have 2 same states which means the same APU score, if this is the case then we will choose the smaller RS code as it will result in less delay.

A summary of the APU algorithm proposed in this chapter and applied at the sender side is shown in Figure 7-28.

if (! 5 RTCP RRs are received) Wait until all the 5RRs received; else

Calculate avgPacketLoss, avgBurstRatio, and avgDelay; // calculate current state without using any RS codes: Calculate rating MOS score using E-model (_MOSnetwork); Calculate overall Delay (d_network);

if (MOS != P||U) Nothing to be done; else

Deduce current state <d_network, _MOSnetwork>; Deduce equivalent APU score for the current state; Add ―NO RS‖ and its APU score in list (validStates); Loop for i=0....2

Calculate MOS after reconstruction for RS(2+i,1+i); Calculate overall delay after reconstruction

Deduce next_state <d_network, _MOSnetwork>;

if (next_state [i] is valid transition state) // from state diagram Deduce APU_score for next_state[i];

Add RS(2+i,1+i) and its APU score in list (validStates); else

Exclude next_state; end if

end Loop

Sort the validStates list by APU score in descending order; if (2 states or more has same APU score)

Sort them with minimum delay mode // RS(2,1)<RS(3,2)<RS(4,3) end if

Use the top RS mode in the validStates list; end if

7.7

Results and Discussion

In this section, we present the simulation results for the APU algorithm, we show the response and the results of our APU algorithm under different network conditions and how it affects the overall conversational call quality perceived by the end user. Moreover, we show the APU adaptive algorithm results and compare then with the different pure Reed Solomon FEC codes.

Our results and test cases are based on varying the network conditions six times with different levels of delay and packet loss. We have measured our results within the boundaries of the APU model of the packet loss and delay so that we can move from one state to another after adding the overhead in the one-way delay and the percentage of packet loss recovered as a result of using certain RS code. This demonstrates the effect of the APU algorithm on the final perceived VoIP call quality.

We have tested the APU algorithm under two commonly used codecs: G.711 and G.723.1 6.4k. In our simulation setup, we vary the network conditions after 20, 45, 70, 95, 120 and 145 seconds (i.e.: before five seconds from taking the decision in the APU algorithm based on the next received RTP report). We give two more seconds which are needed to switch between different states having different APU scores. In our results, the time is represented on the x axis in seconds, while the APU score is represented on the y axis. The APU score gives an indication of the final quality perceived by the end user as it is directly proportional with the quality of experience (QoE). A sample of our results are described in four different test cases. The first two test cases are tested using G.711 codec while the last two test cases are tested using G.723 6.4k codec. In each test case, we compare the adaptive APU algorithm with the fixed RS(2,1), RS(3,2) and RS(4,3). In each test case, we have demonstrated our results in a table to show the different states indicating different RS codec used in our proposed adaptive redundancy control algorithm.