Simulation Results

Simulations considered scenarios where DSQ is available, in addition to scenarios where only BE queuing is possible. Fur-thermore, the delay variation of timing packets was also inves-tigated.

For further details on the simulation settings, readers are re-ferred to PublicationI.

3.6.1 Voice Call Quality if DSQ is Available

The simulations revealed that if DSQ is available, then the qual-ity of voice calls is unaffected by all other traffic types. As long as the maximum number of voice calls that the DSL line can support is not exceeded, the call quality depends only on the proportion of dropped packets. This sensitivity to packet loss was quantified with the help of Conversational Mean Opinion Score (MOSc) [18], which is a quality of experience metric for phone calls. It is a subjective rating from 1 to 5, where 5 is the

best score. In the simulation, however, it is calculated with the PESQ algorithm [19][20], considering packet delays and losses, to attain an objective value equal to the expected average sub-jective value. The MOSc values for voice call quality, according to the ratio of dropped ATM cells on the DSL link, is shown in Figure 4. As previously mentioned, one small voice packet can-not fit into less than four ATM cells on the DSL link due to the extreme overhead, the voice call is four times as sensitive to cell losses due to the overhead. This is visible in Figure 4, which also displays a purely hypothetical simulation case where the packet overheads are omitted. In addition to the simulated values, a theoretical maximum calculation is also presented which takes into account only the limitations of the speech compression and the packet drops.

Figure 4.Average MOSc according to cell loss probability on the DSL link, in the case of DSQ

3.6.2 Voice Call Quality if only BE Queuing is Available If DSQ is not available and BE queuing is used, then the quality of voice calls also depends on the volume of competing data traffic. The simulations described in I provided evidence that all voice calls will be dissatisfactory if there is just a single TCP based connection also transferred over the DSL line. For exam-ple, in the traffic mix with four mobile voice calls and no other connections, the MOSc of the voice calls is 4.06 and 4.08 for

1 1.5 2 2.5 3 3.5 4 4.5 5

0.00001 0.0001 0.001 0.01 0.1 1

AverageMOSc

Cell loss probability on the DSL link theoretical maximum

simulated result without overhead

Excellent Good Medium Poor Bad Very bad

Downlink (DL) and Uplink (UL) directions, respectively, re-gardless of the available bandwidth. This represents clearly au-dible voice quality. In contrast, if there is just a single mobile TCP data connection both in the uplink and downlink direction, then voice quality is unacceptable. If the UL data rate of the DSL line is 512 kb/s, then the MOSc in the UL direction will be 1.95-2.01, which indicates that the call is barely audible. If the UL data rate is 1 Mb/s, then the voice call quality scores 2.77 on the MOSc scale, which means the conversation is difficult to understand. In the DL direction the situation is only better for higher DL data rates. These values clearly indicate that satis-factory QoS cannot be provided with BE queuing when the DSL link also serves TCP traffic. This is due to the inherent nature of TCP, as TCP increases its data rate until packets are dropped from a buffer.

3.6.3 Jitter of Timing Packets

The investigation of the delay and jitter of timing synchroniza-tion packets also considered both DSQ and BE scheduling. In the case where DSQ is available, the timing packets that arrive at the DSL link are always the first to be scheduled, as they have the highest priority. Despite this, other traffic types do have an effect on the end to end latency of the timing packets. If there is a packet transmission already in progress when the timing packet arrives, then the high priority timing packet cannot ac-cess the DSL link immediately, and is buffered. The ongoing packet transmission has to be completed, and only then will the high priority packet be sent through the DSL link. While this causes only a minor extra delay, it is completely random, there-fore causing some jitter, and network synchronization is very sensitive to this jitter.

Simulation results revealed that if there are no parallel TCP or streaming connections active, then the end to end delay of the timing packets will be very steady. If there are other active high data rate applications, then the maximum delay can in-crease by maximum 2.5 ms, and at least 95% of timing packets will have less than 1 ms added delay in all investigated scenar-ios. This is within the tolerance limit, according to Metsälä and

Salmelin [2], who state that the packet jitter should be less than 5 ms. This assures us that clock synchronization over the net-work is possible if DSQ is available, and timing packets are pri-oritized.

On the other hand, if DSQ is not available, only BE queuing, then timing packets may be excessively delayed, depending on the length of the packet queue. When any data connection fully loads the DSL link, then the delay of timing packets can in-crease by several seconds. This clearly is several orders of mag-nitude more than that which is tolerable for precise synchroni-zation. Therefore, in the case of BE queuing, synchronization over the backhaul network is only possible when the DSL link is uncongested.