CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to India patent application serial number 202031028744 filed July 6, 2020.

BACKGROUND

[0002] The subject matter of this application generally relates to timing mechanisms for clocks in an R-PHY transmission network.

[0003] Although Cable Television (CATV) networks originally delivered television content to subscribers over large distances using an exclusively RF transmission system, modem CATV transmission systems have replaced much of the RF transmission path from a provider’s head end to a subscriber’s premises with a more effective optical network, creating a hybrid transmission system where cable content is transmitted over the bulk of the distance between the head and the subscriber using optical signals, but terminates as RF signals over coaxial cables.

[0004] Historically, the head end also included a Cable Modem Termination System (CMTS), used to provide high speed data services such as video, cable Internet, Voice over Internet Protocol, etc. Typically, a CMTS will include both Ethernet interfaces (or other more traditional high-speed data interfaces) as well as RF interfaces so that traffic that is coming from the Internet can be routed (or bridged) through the Ethernet interface, through the CMTS, and then onto the optical RF interfaces that are connected to the cable company's hybrid fiber coax (HFC) system. Dow nstream traffic is delivered from the CMTS to a cable modem in a subscriber's home, while upstream traffic is delivered from a cable modem in a subscriber’s home back to the CMTS. Many modem HFC CATV systems have combined the functionality of the CMTS with the television delivery system (EdgeQAM) in a single platform called the Converged Cable Access Platform (CCAP).

[0005] As networks have expanded and head ends have accordingly become increasingly congested with equipment, many content providers have recently used distributed architectures to spread the functionality of the CMTS/CCAP throughout the network. This distributed architecture keeps the data and video signals in digital format as long as possible, extending the digital signals beyond the CMTS/CCAP deep into the network before converting them to RF. It does so by replacing the analog links between the head end and the access network with a digital fiber (Ethemet/PON) connection.

[0006] 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 by pushing it to the network’s fiber nodes. Thus, while the core in the CMTS/CCAP performs the higher layer processing, the R-PHY device in the node converts the downstream data sent by the core from digital to analog to be transmitted on radio frequency, and converts the upstream RF data sent by cable modems from analog to digital format to be transmitted optically to the core.

[0007] Once the functionality of the CMTS/CCAP is divided between a core in the head end and various PHY devices throughout the network, however, protocols must be established to properly synchronize the clocks in the core with those in the PHY devices, and this is typically accomplished using sync messages under the Precision Timing Protocol (PTP). Moreover, an R-PHY network transmits information according to the Data over Cable Service Interface Specification (DOCSIS), where behavior of various components must be scheduled and/or coordinated, such as when various cable modems are each assigned their own respective time slots to send upstream transmissions. to a CCAP. However, the PTP protocol synchronizes hardware to a 204.8MHz clock, which the DOCSIS standard communicates in software using a 10.24 MHz clock. This timing discrepancy is often problematical since the higher-frequency hardware clock must be converted to a lower frequency to conform to DOCSIS protocols.

[0008] What is therefore desired are improved systems and methods for deriving DOCSIS timing information in an R-PHY network.

BRIEF DESCRIPTION OF THE DRAWINGS [0009] For a better understanding of the invention, and to show how the same may be carried into effect, reference will now be made, by way of example, to the accompanying drawings, in which:

[0010] FIG. 1 shows an exemplary timing arrangement for an R-PHY system where a CCAP core is used as timing grandmaster and Remote PHY Devices (RPDs) are the timing slaves.

[0011] FIG. 2 shows an exemplary timing arrangement for an R-PHY system where both a CCAP core and its RPDs are timing slaves to an external grandmaster clock (GM).

[0012] FIG. 3 shows an exemplary RPD that operates one or more emulated DOCSIS clocks.

[0013] FIG. 4 shows an exemplary method used to calibrate the DOCSIS clock of FIG. 3.

DETAILED DESCRIPTION

[0014] For purposes of the disclosure and the claims, the following terms are defined to as to more easily understand the subject matter described and claimed:

Master Clock: a clock that sends timing information to a slave clock for that clock to synchronize its time to that of the master clock.

Slave Clock: a clock that receives timing information from a master clock to synchronize its time to that of the master clock.

Grandmaster Clock: a clock that only operates as a master clock and is the source of time to the packet network:

Ordinary clock: a slave clock that has a single port receiving timing information from a master clock. Boundary Clock: a clock that operates as both a slave and a master by having one port in a slave state receiving time from a master clock, and one or more ports in a master state which disseminate timing information to downstream slaves.

As already noted, in R-PHY systems the clocks of the Remote PHY Devices (RPDs) and the CCAP core must be sy nchronized for time scheduling of data transfers to work properly, and this synchronization must not only be of frequency, but also of phase. Referring to FIG. 1, for example, a first topology 1 may include a CCAP core 2 synchronized with an RPD 3 connected together via a plurality of network switches 4. The RPD 3 is in turn connected to one or more cable modems 5. Synchronization is attained by a grandmaster clock 6 in the core 2 which sends timing information to a slave clock 7 in the RPD 3. Those of ordinary skill in the art will appreciate that, although FIG. 1 shows only one RPD 3 connected to the core 2, many such RPDs may be simultaneously connected to the core 2, with each RPD having a slave clock 7 receiving timing information from the grandmaster clock 6 in the core.

[0015] FIG. 2 shows a second topology 10 to provide synchronization between a CCAP core 14 and an RPD 16, which again is connected to one or more cable modems 18. Unlike the system of FIG. 1, however, a separate timing grandmaster device 12 provides timing information to both the CCAP core 14 and the RPD 16. Specifically, the timing grandmaster 12 has a first master port 20a connected to a boundary clock 22 in the CCAP core 14 and a second master port 20b connected to a slave clock 24 in the RPD 16. The boundary clock 24 may therefore be a slave to the grandmaster 12 but a master to the slave clock 24 in the RPD. Those of ordinary skill in the art will recognize that the respective clocks of the CCAP core 14 and the RPD 16 may both be connected to a single master port in the timing grandmaster device 12, and the use of separate timing ports 20a and 20b in FIG. 2 is used merely to more easily describe the separate timing processes. The CCAP core 14 may be connected to the timing grandmaster 12 through one or more switches 26 while the RPD 16 may be connected to the timing grandmaster 12 through one or more switches 26. Again, those of ordinary skill in the art will appreciate that, although FIG. 2 shows only one RPD 16 connected to the timing grandmaster 12, many such RPDs may be simultaneously connected to the grandmaster 12, with each RPD having a slave clock 24 receiving timing information from a port 20b in the grandmaster clock 12. Due to common performance issues in the CCAP core, the topology 10 shown in FIG. 2 is usually more reliable than that shown in FIG. 1.

[0016] The CCAP core 14 operates as a Medium Access Control (MAC) layer in an R-PHY system while the RPD 16 is the physical (PHY) device that performs the physical layer processing, such as QAM-modulating a variety of different content received over an IP packet-based network so that a downstream set top box (STB) may receive respectively desired content by tuning to a particular channel. In a CATV system, the user equipment such an STB or a cable modem should be unaware of whether the system it is connected to is an integrated or a distributed architecture, meaning that the R-PHY system must operate as if it were an integrated architecture where both the MAC and PHY layers were collocated in a single head end. For this to occur, the operation of the MAC layer in the CCAP core 12 and the PHY layer in the RPD 16 must be precisely synchronized. To this end, the Precision Timing Protocol (PTP), and other such timing protocols, have been promulgated to provide for such synchronization. PTP specifically is providing timing synchronization using a 204.8 MHz clock. PTP utilizes hardware time stamps to ensure devices are synchronized, where the hardware that performs the time stamps is dedicated to synchronization. Therefore, PTP networks have much sharper time resolutions than software-based timing protocols and furthermore will timestamp the amount of time that synchronization messages spend in each device, which accounts for device latency.

[0017] The software data plane (or packet forwarding module) of an R-PHY system, however, uses a 10.24 MHz DOCSIS clock to implement DOCSIS timing- related activities, such as downstream channel scheduling for transmitting packets, time-stamping SYNC and PLC packets, and PCR re-stamping for video. Because, however, the hardware Field-Programmable Gate Array (FPGA) clock is locked to PTP time stamps that implement a 204.8 MHz clock, the software data plane must convert that 204.8 MHz clock to a 10.24 MHz DOCSIS clock. [0018] Sampling the FPGA clock is often costly and may introduce latency, which adversely impacts clock accuracy. For example, the necessity to access the hardware introduces latency given the time needed to access the memory registers containing the timing information. Also, if the R-PHY system uses multiple CPU cores in bare metal mode for the software data plane, and each core operates on a 10.24 MHz clock, each core will attempt to access the same registers/shared memory, which results in contention to access the FPGA among the cores to read the FPGA clock, introducing random delays as FPGA reads must be queued during periods of contention. Such contention occurs frequently because each core must access the hardware clock at a high rate. These issues together reduce the packet forwarding rate of the CPU in the RPD 16 because the CPU must take time reading the hardware clock and/or waiting in a queue.

[0019] FIG. 3 shows an exemplary RPD 50 that implements a novel emulated DOCSIS clock. Though FIG. 3 shows an exemplary RPD, those of ordinary skill in the art will appreciate that other devices in a distributed access architecture (DAA) may also utilize the disclosed emulated DOCSIS clock, such as a Remote ONU, a Remote OLT, an amplifier, or any other DAA device that uses PTP timing information to determine DOCSIS timing information.

[0020] The RPD 50 may include an FPGA 52 or other such hardware device that includes a clock 54 that receives PTP sync messages from a master or grandmaster clock in a communications network. The clock 54 may operate on a relatively high frequency, such as 204.8 MHz as specified in the PTP protocol. The RPD 50 may also include one or more processing cores, such as cores 56, 58, and 60 which perform data plane software processing for the communications network using timing information of a relatively low frequency, such as a 10.24 MHz frequency specified by the DOCSIS standard. Each of the one or more cores 56, 58, and 60 also preferably implement a respective emulated DOCSIS clock 62, 64, 66 at the relatively low frequency, e.g. 10.24 MHz based on timing information from the CPU clocks of the respective cores and timing information from the clock 54 as further specified. Those of ordinary skill in the art will appreciate that, although FIG. 3 shows each core running a separate emulated clock, some architectures may operate a single emulated clock used by each core.

[0021] FIG. 4 shows an exemplary method 100 that initializes and runs the emulated clocks 62, 64, and 66 of FIG. 3. At step 110 the system is initialized and at step 120 the system reads both a current CPU time and a relatively low-frequency current emulation time, such as a DOCSIS time, based on the hardware clock 54 that operates on a relatively high frequency, e.g. 204.8 MHz. Assuming, for example, that the hardware clock 54 operates at a 204.8 MHz PTP frequency, and the low- frequency emulation time is a 10.24 MHz frequency specified under the DOCSIS protocol, a current DOCSIS time can be computed from a sample of the clock 54 using the formula current DOCSIS time = current PTP time / 20. The sampled CPU time is proportional to the speed of the CPU, which will of course vary based on the internal components of the core(s) 56, 58. 60. For purposes of the remainder of this disclosure, it will be assumed that the relatively low-frequency emulation time is a 10.24 MHz DOCSIS time and that the relatively high-frequency time is a 204.8 MHz PTP time, but those of ordinary skill in the art will understand that the systems and methods disclosed in this specification may be generalized to other frequencies as is appropriate for particular applications.

[0022] At step 122, the sampled current CPU time and current DOCSIS time are stored, and in step 124 the initial samples are also stored as a reference CPU time and a reference DOCSIS time, respectively. At step 128, the method waits for a first threshold amount of time to pass before taking another sample. In one disclosed embodiment, the threshold amount of time may be 10 seconds. After this time has elapsed, the method proceeds to step 130 to determine whether a second threshold amount of time has been exceeded, which as disclosed later, represents the amount of time before a sufficient number of samples has been collected to begin running the emulated DOCSIS clock. If the second threshold amount of time has not been reached, the method returns to step 120 and another sample of a current CPU and current DOCSIS time are again stored at step 122. At step 124, where previous reference samples exist, difference values are calculated between the reference values and the current values as follows:

CPUTimeDiff = CurrentCPUTime - RefCPUTime

DOCSISTimeDiff = Current DOCSISTime - RefDOCSIS Time

After these difference values are stored, the current CPU time and the Current DOCSIS time replace the previously stored reference values, respectively for the next iteration.

[0023] Then at step 126 an adjustment factor is calculated as the ratio of the DOCSIS time difference over the CPU time difference, and the adjustment value is stored, i.e. the ratio CPUTimeDiff/ DOCSISTimeDiff is stored in an array, such that each successive measurement of this ratio over the interval between the first threshold time and the second threshold time reflects a sample of a scaling factor that converts the CPU time to a 10.24 MHz DOCSIS time. As noted earlier, this sample will be affected by a bottleneck delay to access the hardware clock of the FPGA as well as randomly encountered queue delays.

[0024] As noted, the disclosed method continues to take such samples until the second threshold time is reached. In one disclosed embodiment, the second threshold time may be one minute, i.e. where the first threshold time is 10 seconds, seven samples of a current CPU and current DOCSIS time are collected, and six difference value pairs are collected as well as six adjustment factors. Then at step 132 an average adjustment factor is calculated. As noted earlier, each sample of the adjustment factor will be affected by a bottleneck delay to access the hardware clock of the FPGA as well as randomly encountered queue delays, but by taking a number of samples and averaging them, a true scaling factor between the CPU time and the desired 10.24 MHz DOCSIS time may be approached with a desired degree of accuracy simply by adjusting the first and second thresholds to acquire more samples. This reflects a trade-off between performance (small number of samples) and accuracy (large number of samples). [0025] Once the desired number of samples have been collected over the desired interval, at step 134 the emulated DOCSIS clock may be used by the RPD or other device 50. The emulation clock may be implemented by reading a current CPU time and inputting it into the formula

Current DOCSISTime = RefDOCSIS time + ((CurTime - RefCPUTime)* AvAdj) where CurTime is the current CPU time and AvAdj is the average adjustment factor calculated in step 132.

[0026] In some preferred embodiments, the systems and methods shown in FIGS 3 and 4 may adjust for changes in the CPU clock over time due to temperature changes or other variables that affect the CPU clock. In such systems, after the emulation clock is in use via the formula recited in the preceding paragraph, the reference DOCSIS time and reference CPU time may be periodically resampled, e.g. every minute or other desired interval.

[0027] In some preferred embodiments, the systems and methods shown in FIGS 3 and 4 may implements configurable parameters for either or both of the first threshold and the second threshold, as well as optionally for the resampling interval used to correct the CPU clock for temperature or other variations.

[0028] It will be appreciated that the invention is not restricted to the particular embodiment that has been described, and that variations may be made therein without departing from the scope of the invention as defined in the appended claims, as interpreted in accordance with principles of prevailing law, including the doctrine of equivalents or any other principle that enlarges the enforceable scope of a claim beyond its literal scope. Unless the context indicates otherwise, a reference in a claim to the number of instances of an element, be it a reference to one instance or more than one instance, requires at least the stated 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 stated. The word "comprise" or a derivative thereof, when used in a claim, is used in a nonexclusive sense that is not intended to exclude the presence of other elements or steps in a claimed structure or method.