User Manual

SGD-SB2025NT-TUM, Part 2
Jan 12 Page 81 TROUBLESHOOTING & MAINT
11 ET TROUBLESHOOTING AND MAINTENANCE
11.1 N ETWORK L ATENCY AND F AULTS
The crucial parameters in the successful operation of Solar are the buffer times, which are set in
the ‘Sync Timing’ page of the TM ET (see Section 7 – Solar (Sync) Timing for details). Making
the buffers unnecessarily large will undoubtedly mean the Solar network will function but will
introduce noticeable end-to-end audio delay especially for T/T operation. It is far better to optimise
the settings to match the characteristics of the network. In order to do that requires an
understanding of the effects that can result from network issues; these are examined in the
following sub-sections.
11.1.1 Packets Arriving Late
Data packets that arrive outside of the allocated time window will be discarded. If this situation
occurs infrequently, the effect is highly unlikely to be noticed. However, if the packet loss rate
increases to a significant number, the glitches in recovered audio signal will become apparent,
necessitating an increase in the overall time allocation or a examination of the network quality or
both. If a problem occurs that causes every packet to arrive outside of the time window, the NI will
not function, i.e. neither the audio nor the signalling will be output. The NI reports lost packets on
the Setup Info page (see Section 2.4.1.4 – Pkt Errors ).
11.1.2 Network Re-routing
One of the biggest advantages of using IP networks is the possibility to quickly re-route ‘traffic’
around a fault condition. Traditionally, this is not something that a conventional simulcast system
could easily manage, due to the change in audio characteristics that inevitably results from
changing a bearer circuit. As Solar is transported entirely at IP level, then, subject to its operating
limits, Solar is able to make good use of the network re-route feature and provide a level of
resilience not available to conventional simulcast systems.
It is quite reasonable to assume that, when a network route change occurs, the network latency or
packet delivery times to one or more NI will also change. If this results in an increase in time, the
buffer time(s) allocated could prove to be insufficient. This could easily be manifest as
performance degradation on a Solar network that has been operating perfectly up until the point
when a network re-route occurs.
Consequently, it is most important that all potential re-route conditions are carefully examined at
the commissioning stage and the effect on packet delivery times are noted, which will probably
require manually forcing a re-route to occur and analysing the effect. Once the “worst case”
situation has been identified, i.e. the one that reports the longest network delivery times, these
figures should be used to set the ‘Sync Timing’ parameters on the TM.
11.1.3 TM Duplication
If a duplicated TM configuration is to be used, then, as discussed briefly in Section 8.1.1 , there is a
clear benefit in not locating both Primary and Secondary units together. If this approach is
adopted, there are two situations that must be considered:
(a). The network latency time between any given NI and each TM could be quite different.
(b). A network fault could result in loss of communications between the TM even though each TM
is operating normally.