26.09.2012 Views

Triple-Play Service Deployment

Triple-Play Service Deployment

Triple-Play Service Deployment

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

190<br />

Chapter 7: Troubleshooting Video <strong>Service</strong> in the Field<br />

Problem resolution<br />

Packet loss (continuity error) problems typically are seen on all<br />

channels/programs coming to the customer premises because<br />

they are not source- or content-related. If packet loss is present,<br />

analysis of the physical layer at the xDSL interface or Ethernet<br />

interface will aid in sectionalization. If no physical layer errors are<br />

present, then packet loss is most likely being caused by the<br />

distribution network, not by the access network. More than likely,<br />

congestion is the issue.<br />

Looking further into the temporal component is important. Are<br />

packets being lost during known peak traffic times during the<br />

day? Are the packet loses coming in bursts with intervals with no<br />

loss? Or, are they random, single, or small packet loss events? Bursts<br />

of loss are symptomatic of buffer overflows related to heavy traffic.<br />

Random single or small events are more likely to be caused by noise<br />

hits on the access network that are impacting packet flows.<br />

PCR jitter problems may be caused by content quality problems as<br />

outlined previously or overall network packet jitter. This can be<br />

determined by evaluating more than one channel/program at a<br />

time. If excessive PCR jitter is present on more than one channel,<br />

network jitter is most likely at fault. If excessive PCR jitter is present<br />

on only one channel, then a source problem, as described above, is<br />

typically the cause.<br />

Error indicator analysis will help diagnose content problems. Since<br />

the error indicator can be set only by the encoder, it specifically<br />

indicates content-only problems. Usually this affects only one<br />

program or channel. However, if a multiple program feed in the<br />

headend is experiencing problems, multiple programs or channels<br />

can be affected. In this case, analyzing a channel from another<br />

source, or different feed, is useful.<br />

IGMP latency measures the network’s performance. Typically, IGMP<br />

latency is similar for multiple channels. However, if network topology<br />

and network management place access to certain program material<br />

deeper in the network, then differences may be seen.Testing multiple<br />

channels/programs to exercise this network design is useful.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!