How to measure timing holdover performance in R-PHY systems

Abstract

A system and method for measuring the amount of drift of a clock in a remote device relative to a clock in a core in both distributed access architectures by measuring changes in the fullness of a de-jitter buffer in the remote device that holds data provided from the core.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 63 / 314,904, filed February 28, 2022, the contents of which are incorporated by reference in their entirety herein. [Background technology]

[0002] The subject matter of this application relates generally to the delivery of video content using a distributed access architecture (DAA) in a hybrid CATV network, and more particularly to an architecture that distributes cable modem termination system functions between a core and remote devices, such as remote PHY devices or remote MACPHY devices, that are synchronized with respect to the core.

[0003] Cable television (CATV) networks originally used dedicated RF transmission systems to distribute content to subscribers over long distances, but modern CATV transmission systems have replaced many of the RF transmission paths with more efficient optical networks, creating a hybrid transmission system in which cable content terminates as RF signals on coaxial cable but is transmitted using optical signals over most of the distance between content providers and subscribers. Specifically, CATV networks include a headend for receiving signals representing many channels of content at a content provider, multiplexing the signals, and distributing the signals along an optical fiber network to one or more nodes each in close proximity to a group of subscribers. The nodes then demultiplex the received optical signals and convert them to RF signals so that they can be received by viewers. Within the headend, the system that provides the video channels to subscribers typically includes multiple edge QAM units operating at different frequency bands that are combined and multiplexed before being output onto the HFC network.

[0004] A traditional HFC architecture includes a headend with a cable modem termination system (CMTS) that is used to provide high-speed data services, such as video, cable Internet, voice over Internet Protocol, etc., to cable subscribers. Typically, the CMTS will include both an Ethernet interface (or other more traditional high-speed data interface) and an RF interface, so that traffic coming from the Internet can be routed (or bridged) through the Ethernet interface, through the CMTS, and then onto an optical RF interface that is connected to the cable company's Hybrid Fiber Coax (HFC) system. Downstream traffic is delivered from the CMTS to the subscriber's cable modem, while upstream traffic is delivered from the subscriber's cable modem back to the CMTS. Many current HFC CATV systems have combined the functionality of the CMTS with the video distribution system in a single platform called a Converged Cable Access Platform (CCAP).

[0005] In these conventional HFC architectures, video is modulated onto the RF network by a Video Edge QAM (VEQ). The VEQ receives Internet Protocol (IP) encapsulated single and multi-program transport streams (SPTS and MPTS) from various sources (unicast / multicast), removes any jitter from the network ingress streams, and then statically or dynamically maps these streams to QAM channels, remaps program identifiers (PIDs), and multiplexes the required individual SPTSs into a single MPTS through one or more ports of the VEQ. The VEQ may also perform local encryption of the video elementary streams (ES).

[0006] As networks have expanded and headends have correspondingly become more crowded with equipment, many content providers have in recent years spread the CMTS / CCAP functionality across the network by using a distributed architecture that keeps cable data and video signals in digital form as much as possible, extends the digital signals beyond the CMTS / CCAP deep into the network, and then converts the digital signals to RF. This is done by replacing analog links between the headend and the access network with digital fiber (Ethernet / PON) connections.

[0007] One such distributed architecture is the Remote PHY (R-PHY) distributed access architecture, which relocates the physical layer (PHY) of a traditional CMTS or CCAP, including the VEQ, by pushing the PHY to the fiber node of the network. Thus, while the core in the CMTS / CCAP performs the higher layer processing, the R-PHY device in the node converts downstream video data packets sent by the core from digital to analog for transmission over wireless radio frequencies, and converts upstream RF data sent by cable modems from analog to digital format for optical transmission to the core. Another distributed access architecture is the Remote MAC PHY (R-MACPHY), which not only pushes the PHY layer of a traditional CMTS into the network, but also allocates the media access control (MAC) layer functions, one of the two layers that make up the data link layer of the transmission stream, to one or more nodes in the network, referred to as Remote MACPHY Devices (RMDs).

[0008] Thus, in the DAA architecture, the RF network includes remote video-enabled devices such as RMDs and RPDs, VEQs that modulate the fully formed MPTS streams transmitted by the core. One advantage of this arrangement is that the RMD / RPD devices are generally lower power and require lower computational and memory resources than traditional video edge QAMs located at the headend. Similar to the VEQ located at the headend, the VEQ located at the RPD / RMD must map and modulate the IP-encapsulated fully formed MPTS video streams it receives from the headend into one or more QAM channels (one stream per channel), eliminating network jitter in the process. However, the difference with respect to the VEQ at the headend is that the VEQ at the remote devices only receives fully encapsulated MPTS streams, and thus does not need to multiplex various SPTS content together.

[0009] On the other hand, in a DAA architecture, since the CMTS / CCAP functions are split between the headend core and various PHY or MACPHY devices throughout the network, protocols must be established to accurately preserve the timing of the reconstructed video data communicated throughout the network. Thus, even though the remote devices only receive MPTS video data that is already synchronized together, they still must account for any differences between the clock rate at which they receive the data and the clock rate at which they output the data. For example, the DAA remote devices may not be synchronized to the same time base as the CCAP core (asynchronous operation), or even if the CCAP core and remote devices are synchronized to a common clock (synchronous operation), the CCAP core and remote devices may lose timing lock.

[0010] In synchronous mode, no significant issues arise as long as the clocks of the remote device and the core(s) are locked together. However, problems arise during holdover if the remote device or the core loses connection to the timing source. During holdover, the remote device drifts in frequency and phase relative to the core. The Remote DOCSIS Timing Interface (R-DTI) requires that the remote device provide notification when it exceeds a specified amount of drift, but the remote device is often unable to accurately measure the amount of drift.

[0011] Therefore, an improved system and method for accurately determining the amount of drift of a remote device relative to a core of a distributed access architecture is desired. Summary of the Invention

[0012] For a better understanding of the present invention and to show how it may be carried into effect, reference will now be made, by way of example, to the accompanying drawings in which: [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 shows an exemplary conventional HFC architecture having a video EQAM unit that packages and transmits an MPTS transport stream to downstream nodes. [Diagram 2] FIG. 2 illustrates an example architecture including multiple cores, each transmitting data and / or video to a remote physical device (RPD). [Figure 3A] FIG. 3A illustrates an example system in which the video / CCAP core of FIG. 2 transmits video data to an RPD in a synchronous mode. [Figure 3B] FIG. 3B illustrates an exemplary system in which the video / CCAP core of FIG. 2 transmits video data to the RPD in an asynchronous mode. [Figure 4] FIG. 4 illustrates an exemplary method according to some embodiments of the present disclosure. [Diagram 5] FIG. 5 illustrates an exemplary apparatus for providing input data for the method of FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Although the disclosed systems and methods are described using a distributed access architecture providing video and data, those skilled in the art will understand that the disclosed embodiments may be used with other synchronized architectures that provide data to remote devices that are subject to holdover and stored in a de-jitter buffer.

[0015] As previously mentioned, a Video EQAM (VEQ) device is used to receive multiple channels of video and output an RF modulated (i.e., QAM or Quadrature Amplitude Modulated) signal that combines the different channels that the VEQ receives. Figure 1 shows a conventional architecture 10 with an HFC network 12 including a headend 14 that distributes content to subscriber equipment 24, such as subscriber premises shown in the figure as cable modems, although those skilled in the art will appreciate that the subscriber equipment can include set-top boxes, gateways, wireless telephones, computers, etc.

[0016] HFC network 12 includes a headend 14, a number of hubs 20, with each hub associated with a number of nodes 22, and a number of subscriber equipment 24, such as cable modems. Headend 14 typically includes a cable modem termination system (CMTS) 13 and a number of video EQAM units 16. Each of the nodes 22 has one or more corresponding access points, and each subscriber may have one or more corresponding network elements 24, shown in FIG. 1 as a cable modem.

[0017] As also mentioned above, in these conventional HFC architectures 10, video is modulated onto the RF network by the VEQ 16, which receives Internet Protocol (IP) encapsulated single and multi-program transport streams (SPTS and MPTS) from various sources (e.g., content providers) via the content distribution network 26. The content distribution network is typically a switching network where packetized IP data is routed from one address to another and may exhibit unpredictable and variable delays in the received packets. Therefore, the VEQ 16 preferably removes this jitter from the network ingress streams before mapping and modulating the video data onto multiple QAM channels. Also, as mentioned above, delivery of MPTS streams onto QAM channels in accordance with ISO 13818-1 requires the VEQ to recover the ingress program clock reference (PCR) values ​​encoded within each transport stream and re-stamp them with the VEQ's internal 27 MHz clock so that all streams are delivered on the same time base.

[0018] FIG. 2 illustrates an alternative distributed access architecture (DAA) in which some of the VEQ functionality is moved to the nodes. Specifically, FIG. 2 illustrates what is known as a n-remote physical architecture (R-PHY) 50 in which one or more cores, such as a CCAP core 54a, a video core 54b, and an OOB core 54c, transmit data to a remote physical device (RPD) 56, which in turn is connected to one or more customer premises equipment (CPE) devices 18, such as set-top boxes, cable modems, etc. Although an R-PHY architecture is illustrated in FIG. 2, it should be understood that the description herein is equally applicable to other DAA architectures, such as, for example, an R-MACPHY architecture. In some embodiments, a timing grandmaster device 52 may be available to provide timing information to both the video / CCAP / OOB cores 54a-54c and the RPD 56. Specifically, the timing grandmaster 52 has a first master port 60a connected to a slave clock 62 in the CCAP core 54 and a second master port 60b connected to a slave clock 64 in the RPD 56, although alternatively the slave clocks 64 of each of the cores 54a-54c and the RPD 56 may both be connected to a single master port in the timing grandmaster device 52. The cores 54a-54c may be connected to the timing grandmaster 52 through one or more switches 66, while the RPD 56 may be connected to the timing grandmaster 52 through one or more switches 68. Although FIG. 2 shows only one RPD 56 connected to the timing grandmaster 52, multiple such RPDs may be connected to the grandmaster 52 simultaneously, with each RPD having a slave clock 64 that receives timing information from port 60b in the grandmaster clock 52.

[0019] Although the architecture of FIG. 2 shows a common grandmaster device 52 that can synchronize the video / CCAP / OOB cores 54a-54c to the RPD 56, the architecture of FIG. 2 may also be configured to operate asynchronously with respect to the video data, where the grandmaster device 52 does not send common timing information for the video core 54b to the RPD 56. For example, the RPD 56 may be configured to operate asynchronously if the video core 54b does not support the IEEE 1588 timing protocol, or if the RPD 56 is desired to be more robust to holdover periods when the RPD and / or cores lose connection to the timing grandmaster and drift exceeds a certain threshold amount. Furthermore, in an R-MACPHY system, the RMD may be switched to synchronous mode if other services, such as wireless backhaul, require IEEE 1588 services, or if the oscillator of the video core 54b is of poor quality and requires an external timing source, but since DOCSIS services do not require it, the RMD may typically be set to asynchronous mode by default to eliminate the need for 1588 timing. Thus, the system shown in FIG. 2 may be configured to operate in either synchronous or asynchronous modes to process video content, and thus in some embodiments, video core 54b and RPD (RMD) 55 may each include hardware capable of operating in either mode and may include software to enable configuration by the video core itself and to alternatively connect downstream devices to either of these modes when setting up a video channel.

[0020] In synchronous (sync) mode, the RPD (or RMD) and its video core 102 are synchronized in time with respect to the same reference clock. In this synchronous mode, the RPD is required to detect lost video packets using Layer 2 Tunneling Protocol v.3 (L2TPv3) sequence number monitoring and insert MPEG null packets for each missing packet. FIG. 3, for example, shows a system in a configuration 100 in which the video core 102 communicates to the RPD 104 in synchronous mode using a common grandmaster timing server 106. The timing server 106 maintains the same timing lock (i.e., frequency and phase) for both the clock 108 in the video core 102 and the clock 110 in the RPD 104. The video core 102 has a video streamer 112 that transfers video data packets to the RPD 104 over a downstream external PHY interface (DEPI) using L2TPv3. The video packets sent from the video core 102 to the RPD 104 typically contain all the information necessary to decode the packetized elementary video transport stream, such as program identifiers (PIDs), program clock reference (PCR) data, etc.

[0021] The RPD 110 then receives the video packets transmitted from the video core 108 in a de-jitter buffer 116 of the processing device 114. The de-jitter buffer 116 receives and outputs the packet data at a rate that removes network jitter due to different paths of the received packet data or due to other sources that vary the network delay between the video core and the RPD. Because some packets transmitted by the video streamer 112 may be lost or misplaced in transit to the RPD 104, the packets output from the de-jitter buffer 116 may be forwarded to a module 118 that, in the case of a synchronous mode, preferably inserts null packets into the data stream to account for those lost packets so as to maintain the proper timing rate of the transmitted video. The transport stream, with null packets appropriately inserted, may then be forwarded to PHY device 120, which may decode the packetized elementary stream into a sequence of decoded video frames for downstream delivery to an end user by outputting the QAM modulated data in a format expected by a customer premises equipment such as a set-top box. Alternatively, the PHY device may simply forward the packetized data to, for example, a cable modem, without decoding the packetized data, for decoding by user equipment such as a computer, tablet, cell phone, etc.

[0022] In synchronous mode, the RPD 104 and its video core 102 must be synchronized to the same reference clock, so the frequency of the PCR clock contained within the ingress MPTS matches the frequency of the local clock on the remote device. Thus, there is no frequency offset on the RPD between the ingress and egress streams, and as mentioned above, the RPD 104 simply needs to remove network jitter, detect lost video packets using L2TPv3 sequence number monitoring, and insert MPEG NULL packets for each missing packet to maintain proper timing information for the transmitted video data.

[0023] However, alternatively, the RPD and video core may be configured to operate in an asynchronous mode, in which the RPD 104 and its video core 102 are not time-synchronized with respect to the same reference clock. Instead, the RPD 104 needs to detect the difference between its own clock 110 and the clock 108 of the video core 102, and needs to be able to insert or remove MPEG packets as necessary to maintain the expected MPEG bit rate, and further needs to adjust the MPEG PCR values ​​based on the removal / insertion of MPEG packets.

[0024] 3B illustrates the hardware of FIG. 2, for example, configured to operate in an asynchronous mode instead. In this configuration 101, the clock 108 of the video core 102 and the clock 110 of the RPD 104 are not synchronized and may therefore drift relative to each other. The video streamer 112 of the video core 102 forwards packets of the packetized video data elementary stream to the RPD 104, which again receives the data in a de-jitter buffer 116 to remove network jitter as described above. However, unlike the configuration of FIG. 2, the packets output from the de-jitter buffer 116 are forwarded to a module 118 that both adds null packets as necessary and drops packets as necessary to keep the bit rate of the data received from the de-jitter buffer 116 fair and constant.

[0025] Furthermore, because the RPD and its video core are not time-synchronized with respect to the same reference clock, the PCR in the ingress MPTS is offset in frequency from the local RPD clock frequency. Thus, in addition to performing the above-mentioned functions common to those performed in synchronous mode, the RPD must also detect the magnitude of the frequency offset from the video core and correct it. Thus, after packets are added / dropped as necessary, the PCR module 119 restamps the video packets with updated PCRs based on the removal / insertion of MPEG packets, and then forwards the restamped packets to the PHY device 120.

[0026] As previously mentioned, in a distributed access architecture, a remote device such as an RPD is typically configured to operate in a synchronous mode with respect to a video core, where the RPD and video core maintain timing lock, and synchronization must be maintained by both frequency and phase for DOCSIS time scheduling to function properly. A remote device such as an RPD is also configured to maintain timing lock with a data core, such as the CCAP core 54a and OOB core 54c of FIG. 2. For example, the Remote DTI (R-DTI) specification requires that the RPD and CCAP cores be phase aligned with less than 1 ms difference, and the R-PHY specification specifies IEEE-1588 as a method for performing this frequency and phase synchronization in an R-PHY system.

[0027] While the remote device and core(s) maintain timing lock, no significant difficulties arise. However, problems arise whenever the remote device or core loses connection to a common timing source, such as a grandmaster timer, or otherwise loses synchronization with each other. In this case, the RPD enters a state called "holdover" in which the remote device drifts in frequency and phase with respect to the core(s). The magnitude of this drift depends on many factors, such as temperature variations, the performance of the internal oscillator, etc. For example, an RPD with a typical TCXO oscillator may drift in phase by as much as 1 ms within a few hours, or even within a few minutes in a worst case scenario. For video distribution, an RPD in holdover may simply switch operation to an asynchronous mode. However, if the phase difference between the remote device's clock and its core's clock becomes too large during holdover, the cable modem may go offline, and therefore the R-DTI specification provides for a notification from a remote device, such as an RPD, during holdover if its drift exceeds a specified threshold.

[0028] Typically, the holdover problem is addressed by attempting to improve holdover performance, either through the use of better oscillators or frequency assistance from the network (SyncE) to avoid frequency drift. However, both of these solutions are expensive in both power and price. Furthermore, SyncE requires the network to support it, which is often not present.

[0029] As mentioned above, the R-DTI specification provides for notification from a remote device, such as an RPD, when its drift during holdover exceeds a specified threshold, but the specification does not provide a mechanism for how the RPD detects the magnitude of that drift. Typically, a device in holdover cannot measure the magnitude of its own drift because it has lost its time reference, and therefore a typical method for determining the amount of drift is simply to estimate that the remote device has exceeded a threshold after a predetermined amount of time has elapsed during holdover, the amount of time being based on the hardware characteristics of a clock or oscillator in the remote device.

[0030] The present disclosure provides a novel mechanism by which a remote device may measure in real time the amount of drift that has occurred during holdover. Specifically, the embodiments disclosed herein take advantage of the fact that while data services cannot operate indefinitely without synchronizing with the core's date, video services can. Thus, the present disclosure describes an embodiment that allows a remote device, such as an RPD, to detect a fractional frequency offset relative to the core by detecting and analyzing the variation in the bit rate of a video or other data stream coming from the video core during holdover. The video stream from the video core in the distributed architecture is preferably configured to transmit video data at a constant bit rate (CBR) based on a video core clock, e.g., a 27 MHz MPEG clock (locked to a reference clock in synchronous mode).

[0031] Assuming that a data core such as core 54a or 54c in FIG. 2 is still locked to the reference clock while the RPD is in holdover and while the RPD operates in asynchronous mode during holdover (because the RPD id is configured to operate in asynchronous mode, or because the RPD switches to asynchronous mode when it enters holdover from synchronous mode), any frequency drift between the MPEG clock and its assumed frequency of the remote device will be reflected by bitrate variations in the video stream detected by the remote device, which for purposes of this specification is presumed to be the RPD, although one skilled in the art will recognize that it could be another remote device, such as an RMD.

[0032] The RPD preferably includes a video de-jitter buffer, such as buffer 116 of FIG. 3, capable of holding at least 10 ms of video packets. When the RPD and video core clocks are synchronized, some variation in buffer depth is caused by network jitter. If the RPD and video core are not synchronized because the RPD goes into holdover, clock drift in the RPD will result in further variation in buffer depth. However, the network variations caused by network jitter are much higher in frequency than the variations caused by frequency drift. Therefore, the RPD can implement low pass filtering (LPF) techniques to filter the variations caused by network jitter. What remains are the variations that represent drift.

[0033] Thus, in a preferred embodiment, the disclosed system and method may include a remote device that measures buffer depth variations, applies a low-pass filter to those variations, and uses the filtered result to calculate the bitrate difference between the nominal configured bitrate and the actual bitrate of the video stream, and derives a fractional frequency offset between its own clock and the PCR clock of the incoming MPEG stream.

[0034] As already mentioned, network jitter is removed by using a "de-jitter" buffer 116 shown in Figure 3B. This de-jitter buffer 116 is preferably initially filled to its midpoint when MPTS stream delivery begins. Since de-jitter is typically accomplished using a low-pass filter that averages delay over a sufficiently long interval, the de-jitter buffer 116 is preferably large enough to absorb buffer depth fluctuations caused by jitter on the ingress stream without underflowing or overflowing.

[0035] The frequency difference between the ingress PCR and the local RPD clock (i.e., the egress rate) appears as a drift in the de-jitter buffer depth after low-pass filtering. This produces a frequency offset-induced queue depth drift rate. This drift rate is directly proportional to the offset between the frequency of the ingress PCR and the frequency of the remote device's local clock. Specifically, the ingress frequency Fi is directly proportional to the ingress bit rate Bi,

number

number

number

[0036] The rate of change of the buffer depth is also proportional to the bitrate derivative dB / dt. Thus,

number

[0037] Knowing the fractional frequency offset is not sufficient due to the cumulative effect of frequency drift on phase drift. Therefore, in a preferred embodiment, the RPD measures the fractional frequency offset (FFO) rapidly (e.g., every few seconds) and performs an integral function on all FFO measurements to estimate the total phase drift. It should be noted that the FFO value can be positive or negative.

number

[0038] FIG 4 illustrates an exemplary method 150 for carrying out the above-described procedures. Method 150 is preferably implemented on a remote device in a distributed access architecture or on data recovered from a remote device in a distributed access architecture. For example, in one embodiment, method 150 may be implemented on a processing device housed within RPD 104, as shown in FIG 3. In an alternative embodiment, some or all of the steps illustrated in FIG 4 may be implemented on a server based on data collected from a remote device, such as RPD 104 of FIG 3.

[0039] At step 152, a fractional frequency offset (FFO) value is determined. At step 154, the determined value is added to an accumulator, i.e., a function that accumulates previous FFO values. At step 156, it is determined whether the accumulated value exceeds a threshold. Those skilled in the art will appreciate that appropriate values ​​for the threshold will vary depending on the accuracy of the hardware, e.g., an oscillator in a remote device such as the RPD 104. If the threshold is exceeded, a notification is sent at step 158. If the accumulated value determined at step 156 does not exceed the appropriate threshold, the method returns to step 152, where another FFO value is determined and added to the accumulator at step 154, and so on.

[0040] FIG. 5 illustrates one preferred system for outputting FFO values. FIG. 5 illustrates an embodiment having the processing device 114 of FIG. 3 together with its de-jitter buffer 116. A buffer depth measurement unit 132 receives data from the de-jitter buffer 116, including a time series of values ​​of the depth of the de-jitter buffer 116, i.e., a series of measurements representative of how full the de-jitter buffer 116 is. The output of the buffer depth measurement unit 132 is then provided to a low pass filter 134, preferably configured to filter out high frequency variations in the buffer depth due to network jitter. The output of the low pass filter 134 is then provided to a unit 136, which calculates a sequence of FFO values ​​to be used in the method of FIG. 4. The sequence of FFO values ​​is calculated as the rate of change (positive or negative) of the filtered output of the low pass filter 134, as previously described.

[0041] It will be understood that the present invention is not limited to the particular embodiments described, and that modifications may be made therein, as interpreted in accordance with the principles of prevailing law, including the doctrine of equivalents, or any other doctrine that expands the scope of an enforceable claim beyond its literal scope, without departing from the scope of the invention as defined in the appended claims. Unless the context indicates otherwise, a reference in a claim to the number of instances of an element, whether it is a reference to one instance or to multiple instances, requires at least the recited number of instances of the element, but is not intended to exclude from the scope of the claim a structure or method having more instances of that element than are recited. As used in the claims, the term "comprise" or its derivatives is used in a non-exclusive sense that is not intended to exclude the presence of other elements or steps in the claimed structure or method.

Claims

1. A remote device in a distributed access architecture of a communications network, the remote device being operably connected to a core that provides data to the remote device, the remote device including a de-jitter buffer and a processor configured to measure sequential values, each value representing an instantaneous fullness state of the de-jitter buffer, and using the values ​​to determine a magnitude of drift of a first clock of the remote device relative to a second clock of the core.

2. The remote device of claim 1 comprising an RPD.

3. The remote device of claim 1 , further comprising a low pass filter for filtering the sequential values.

4. The remote device of claim 3 , wherein the low pass filter blocks variations in the sequential values ​​due to network jitter.

5. The remote device of claim 3 , wherein an output of the low pass filter is used to determine a sequence of fractional frequency offset values.

6. The remote device of claim 5 , wherein the processor accumulates the sequence of fractional frequency offset values ​​to provide an accumulated value and compares the accumulated value to a threshold value.

7. The remote device of claim 6 , wherein the remote device provides an alert based on the comparison.

8. 1. A method comprising: measuring sequential values ​​representative of a fullness state of a de-jitter buffer of a first network device having a first clock; and using the sequential value to determine a magnitude of drift of the first clock relative to a second clock associated with a second device that provides data to the de-jitter buffer.

9. The method of claim 8 , wherein the first network device is at least one of a remote physical device (RPD) and a remote MACPHY device (RMD).

10. The method of claim 8 comprising applying a low pass filter to the sequential values.

11. The method of claim 10 , wherein the low pass filter blocks variations in the sequential values ​​due to network jitter.

12. The method of claim 10 , wherein an output of the low pass filter is used to determine a sequence of fractional frequency offset values.

13. The method of claim 12 , comprising accumulating a sequence of the fractional frequency offset values ​​to provide an accumulated value.

14. The method of claim 13, comprising comparing the accumulated value to a threshold value.

15. The method of claim 14 , comprising providing an alert based on the comparison.

16. 1. A method comprising: repeatedly measuring a fullness state of the buffer to provide a first sequence of values; low pass filtering the first sequence of values ​​to provide a second sequence of values; accumulating a rate of change of said second sequence of values ​​to provide an output signal; providing an alarm when the output signal exceeds a threshold.

17. 20. The method of claim 16, implemented in a remote device within a distributed access architecture of a communications network.

18. The method of claim 17 , wherein the buffer is a de-jitter buffer.

19. The method of claim 18 , wherein the de-jitter buffer receives data from a video core.

20. 20. The method of claim 19, wherein the alarm signals that the drift of the remote device's clock has drifted relative to the core's clock by an amount that exceeds a threshold.

Images