Latency Paths in xDSL Standards

Unlike the EFM Copper PHYs, previous standard xDSL flavors provide two different latency paths at the ?-interface. The need for different paths comes from the different transmission requirements for certain applications or services.

An application transporting a real-time voice conversation over Ethernet (e.g., voice-over-IP) requires a very low latency in order for the subjective quality of the transmission to be acceptable for the human user. When the round-trip time exceeds about 400 ms, any amount of residual echo causes a doubletalk effect that makes it impossible for most people to carry on a conversation. Encoding and decoding of the speech signal will typically use up a significant part of that delay budget, so it s essential to keep the delay due to the transmission down to a minimum.

Prerecorded video content, on the other hand, does not require the same low latency (as long as it is one-way streaming). Even so-called live video content (e.g., televised news shows, sports events, concerts) does not lose its appeal under a transmission delay of up to several seconds (again, encoding and decoding of the video stream will take a significant amount of time). Loss of packets impacts the appreciation of the video quality much more; effects such as blocking artefacts and image freezes can be caused in theory by individual bit errors, leading to entire packets being discarded. Hence the need to keep the BER to a minimum, even at the expense of higher...