R-PHY MAP advance time selection

Abstract

A system and method for dynamically adjusting a MAP advance time of a MAP message sent from a CCAP core to an RPD based on a comparison of at least one latency measurement to at least one threshold.

Description

[Technical field]

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

[0002] The subject matter of this application relates generally to distributed access architectures for hybrid CATV networks, and more particularly to an R-PHY (Remote Physical) architecture that distributes cable modem termination system functionality across a network.

[0003] Although cable television (CATV) networks originally used dedicated RF transmission systems to deliver content to subscribers over long distances, 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, converting them back to RF signals so that they can be received by viewers. Within the headend, the system that provides the video channels to the subscribers typically includes multiple EdgeQAM units operating in different frequency bands that are combined and multiplexed before being output onto the HFC network.

[0004] Historically, the headend also included a separate cable modem termination system (CMTS) used to provide high-speed data services such as video, cable Internet, and voice over Internet Protocol 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 connected to the cable company's Hybrid Fiber Coax (HFC) system. Downstream traffic is delivered from the CMTS to the customer's cable modem, while upstream traffic is delivered from the customer's cable modem back to the CMTS. Many current HFC CATV systems have combined the functionality of the CMTS with a video distribution system (EdgeQAM) in a single platform called a Converged Cable Access Platform (CCAP).

[0005] As networks have expanded and headends have correspondingly become more crowded with equipment, many content providers have in recent years spread the CMTS / CCAP functions across the network by using a distributed architecture. This distributed access architecture (DAA) keeps the 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 distributed architecture works by replacing the analog links between the headend and the access network with digital fiber (Ethernet / PON) connections.

[0006] One such distributed architecture is the Remote PHY (R-PHY) distributed access architecture, which relocates the traditional CCAP's physical layer (PHY) by pushing it to the fiber nodes of the network. Thus, while the core in the CCAP performs the upper layer MAC layer processing, the R-PHY device in the node converts downstream data sent by the core from digital to analog for transmission over radio frequencies, and converts upstream RF data sent by cable modems from analog to digital format for optical transmission to the core.

[0007] However, when the CMTS / CCAP functions are split between, for example, the Mac layer in the CCAP core and various PHY devices throughout the network, it becomes much more difficult to synchronously coordinate transmissions between downstream cable modems and the CCAP core. Specifically, to reduce interference between upstream transmissions, the CCAP transmits downstream scheduling messages that inform each cable modem of its assigned upcoming transmission window, and these scheduling messages must be received well in advance of such transmission window. Typically, the CCAP can reliably calculate the transmission delay between sending such a message and the cable modem receiving it, since conditions between the CCAP and the modem do not typically change rapidly. However, such rapid changes exist in an R-PHY system. Thus, an improved system and method for determining the delay between sending and receiving a MAP message in an R-PHY architecture is desired.

[0008] 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]

[0009] [Figure 1A]FIG. 1A illustrates an exemplary R-PHY architecture that uses a CCAP core to synchronously schedule transmissions among multiple cable modems. [Figure 1B] FIG. 1B illustrates an exemplary R-PHY architecture that uses a CCAP core to synchronously schedule transmissions among multiple cable modems. [Diagram 2] FIG. 2 illustrates an example timing system for determining the MAP advance time delay. [Diagram 3] FIG. 3 shows an alternative timing system for determining the MAP advance time delay. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] For purposes of this disclosure and claims, the following terms are defined to more readily understand the subject matter described and claimed. Master Clock: A clock that sends timing information to slave clocks on its behalf and synchronizes its own time with that of the master clock. Slave Clock: A clock that receives timing information from a master clock and synchronizes its time with that of the master clock. Grandmaster Clock: A clock that acts only as a master clock and is the source of time for a packet network. Boundary Clock: A clock that acts as both a slave and a master by having one port in slave state that receives time from a master clock and one or more ports in master state that distribute timing information to the slaves. MAP Message: A message sent by CCAP that contains a Bandwidth Allocation Map (MAP). The MAP contains information about when and for how long a cable modem can transmit. CCAP must proactively send MAP messages to ensure that cable modems do not miss transmission opportunities. MAP Advance Time: The amount of time that the CCAP sends a MAP message ahead of the cable modem's transmission opportunity. DOCSIS Tick: A unit of time expressed in minislots since CMTS initialization time, where a minislot is 6.25 μs.

[0011] As already mentioned, in an R-PHY system, the clocks of the remote PHY device (RPD) and the CCAP core must be synchronized in both phase and frequency for time scheduling of data transfers to function properly. Figure 1A shows an exemplary topology 10 used to synchronize devices in an R-PHY architecture. The topology 10 may include a CCAP core 12 synchronized with an RPD 13 connected together via multiple network switches 14. The RPD 13 is in turn connected to one or more cable modems 15. Synchronization is achieved by a clock 16 in the core 12 acting as a grandmaster clock that transmits timing information to a slave clock 17 in the RPD 13. Although Figure 1 shows only one RPD 13 connected to the core 12, one skilled in the art will understand that multiple such RPDs can be connected to the core 12 simultaneously, with each RPD having a slave clock 17 that receives timing information from the grandmaster clock 16 in the core. One skilled in the art will also understand that alternative timing architectures can include separate grandmaster clocks.

[0012] 1B shows an alternative topology 18 that differs from topology 10 in that a separate grandmaster clock 19 is used to synchronize both the clock 16 of the core 12 and the clock 17 of the RPD 13. In this architecture, clock 16 operates as a boundary clock that is a slave to the grandmaster clock 19 but acts as a master clock to the slave clock 17 in the RPD 13.

[0013] Also, as already mentioned, the CCAP core 12 operates as a MAC layer in the R-PHY system and is responsible for creating and sending periodic downstream MAP packets, i.e., scheduling messages to the cable modems 15, to coordinate their upstream transmissions between the network. The cable modems 15 then use the received MAP messages to determine when they can each gain access to the upstream channel and transmit packets in the upstream direction. These MAP messages must be received in sufficient time before the transmission window contained in the MAP message is scheduled to begin. Typically, the CMTS is configured with the maximum time required for a MAP message to propagate through the HFC network to the cable modem, so that the CMTS can send the MAPS early enough that it is available when it reaches the cable modem. In legacy systems that are not based on the R-PHY architecture, the conditions between the CCAP and the cable modem are known in advance, so that the CCAP can reliably calculate the maximum transmission delay between when the MAP message is sent and when it is received by the cable modem.

[0014] However, in an R-PHY system, a variable delay is added to the transmission of the MAP message because the MAC and PHY layers of the CMTS are geographically separated by a packet-switched network, and this delay is often unpredictable by the operator. Thus, when the MAC layer prepares the bandwidth MAP and sends it to the PHY layer, it must determine the extra delay traversing the packet-switched network between the MAC and PHY layers when determining when to send the bandwidth MAP packet. Knowledge of the MAC to PHY layer delay is critical to the operation and performance of the system.

[0015] 2 illustrates a method for determining an appropriate MAP advance time in an R-PHY system. In this method, the CCAP core 20 has a master clock 21 that is used to synchronize its time with that of a slave clock 23 in the RPD 22, ensuring that the core 20 and the RPD 22 are each synchronized to the same DOCIS tick since CMTS initialization. Those skilled in the art will appreciate that the master clock 21 may be a grandmaster clock, or similarly, a boundary clock that is a slave to a separate grandmaster clock.

[0016] The CCAP core 28 may utilize a DEPI Delay Measurement (DLM) message exchange protocol that uses Downstream External PHY Interface (DEPI) messages that serve to measure the delay between the CCAP core 20 and the RPD 22. Specifically, the CCAP core 20 sends a DLM request message 24 to the RPD 22. Before sending the DLM request message 24 over the packet-switched network, the CCAP core 20 writes a timestamp in the packet to record the CCAP core transmission time of the packet. The units of this timestamp are preferably DOCSIS ticks. When the DLM request 24 arrives at the RPD 22, the RPD 22 records the packet arrival time. The RPD 22 then forms a DLM response message 26 that includes a timestamp from the CCAP core 22 and a timestamp representing the packet arrival time at the RPD 22, both in units of DOCSIS ticks. The RPD 22 then sends this DLM response to the CCAP core, which then subtracts the CCAP core timestamp from the RPD timestamp, thereby obtaining a resulting value that is the one-way delay 28 from the CCAP core 20 to the RPD 22 in DOCSIS ticks. This time can be converted to seconds. Once the CCAP core 20 has the latency measurement, it can make other delay estimates in the time it takes for a BWMAP packet to get from the CCAP core 20 to the cable modem, and use these estimates together with a measure of the delay from the CCAP core 20 to the RPD 22 to determine the ideal time to send the BWMAP to have it reach the cable modem within an acceptable range.

[0017] The method shown in Figure 2 may have several drawbacks. First, DLM requires additional data plane messages to achieve its goal. Second, DLM requires extensive modifications of the CCAP core and RPDs to be able to format and process DLM messages and handle message error scenarios. Additionally, the CCAP core needs to keep track of periodically sent messages and outstanding messages. Third, the CCAP core may be connected to hundreds of RPDs. Periodically sending DLM requests and processing DLM responses from potentially hundreds of RPDs could overwhelm the processing power of the CCAP core.

[0018] FIG. 3 illustrates an alternative system and method for determining an appropriate MAP front-loading time in an R-PHY system that, instead of exchanging a separate message dedicated to measuring packet delay from the CCAP core 30 to the RPD 32, uses data from the MAP message itself to estimate the delay and adjusts the MAP front-loading time accordingly. The MAP message includes a MAP allocation start time, which is the start of the time window in which the MAP allocates bandwidth. By examining the MAP allocation start time in the received MAP and comparing it to the time the RPD receives the MAP message, the RPD can determine an actual measured "HFC MAP lead time," which is the time of reception relative to the MAP allocation start time. The RPD 32 may record, store, and report this data to the CCAP core 30 as needed. When determining its MAP front-loading time, i.e., the time before the window in which the MAP applies the CCAP core calculates that the MAP message should be sent, the CCAP core makes certain assumptions about the delay between the MAC layer and the PHY layer, and from those assumptions determines an expected HFC MAP lead time at which the RPD is expected to receive the MAP. A MAC layer device can compare the measured HFC map lead time reported by the PHY layer device with its own expected HFC map lead time. From this comparison, the MAC layer can determine whether its expected latency is correct and can adjust the expected latency until the expected HFC map lead time matches the measured HFC map lead time.

[0019] Specifically, the system may include a CCAP core 30 having a master clock 31 connected via a packet-switched network to an RPD 32 having a slave clock 33. The master clock 31 and slave clock 33 ensure that each of the core 30 and the RPD 32 are synchronized to the same DOCIS tick since CMTS initialization. The CCAP core 30 may construct a MAP message 34 that includes the start time of the window for which the MAP will allocate bandwidth, recorded as start_alloc_time_mini_slots. The MAP message is sent to the RPD 32, which normally passes the MAP message downstream to its RF ports. However, before doing so, the RPD 23 parses the MAP message to obtain start_alloc_time_mini_slots and records that value along with the timestamp for receiving the MAP message, pkt_arrival_time_docsis_tick.

[0020] The start_alloc_time_mini_slots value in the Bandwidth MAP packet is expressed in units of minislots since CMTS initialization time. The RPD 32 preferably converts this timestamp to units of DOCSIS ticks since CMTS initialization. This can be done by looking at the "minislot size" associated with the MAP, which is configured on the RPD 32 by the CCAP core 30 at RPD initialization time. The configured minislot size parameter is the size of a single minislot in DOCSIS ticks. Thus, the start_alloc_time_mini_slots in the Bandwidth MAP packet is multiplied by the minislot size to arrive at the resulting allocation start time, expressed in DOCSIS ticks, and stored as map_alloc_start_time_docsis_tick. The RPD may also estimate from its record of pkt_arrival_time_docsis_tick how long it will take for the Bandwidth MAP packet to actually be transmitted downstream on its RF port. This estimate is fairly constant for the RPD 32, since the processing time for the Bandwidth MAP packet does not change significantly over time. This constant is also preferably expressed in units of DOCSIS ticks and may be denoted as est_processing_time_docsis_ticks.

[0021] A time expressed in units of DOCSIS ticks may be converted to seconds by multiplying by a constant, seconds_per_docsis_tick, which is equal to 1 / 10240000. Thus, the RPD may create a message 36 containing the time in seconds that the RPD 32 actually received the MAP message 34 before the MAP start allocation time via the following formula: hfc_map_lead_time_secs = (map_alloc_start_time_docsis_tick - (pkt_arrival_time_docsis_tick + est_processing_time_docs_tick)) * seconds_per_docsis_tick. A message 36 may then be sent to the CCAP core 30, which may use the measured MAP lead time to dynamically adjust its MAP advance time. In some embodiments, the CCAP core 30 may look at the recorded samples and determine if the measured HFC map lead time is within an acceptable threshold for the portion of the RF plant attached to the reporting RPD 32. If the HFC map lead time is outside of acceptable limits, the CCAP core 30 may take a number of actions, including, but not limited to: (i) alerting an operator via a log or other user interface, (ii) adjusting its internal algorithms for how early it sends the bandwidth MAP to the RPD in an effort to bring the HFC map lead time back within acceptable limits, and (iii) collecting and storing data for later analysis to identify and debug network issues.

[0022] In some embodiments, the RPD 32 may periodically inspect MAP packets and record the HFC map lead times for these packets. Each HFC map lead time is sampled and stored in the database in the RPD 32. The RPD 32 may store the most recent X samples in some embodiments for retrieval by the CCAP core 30 or the cable operator. The RPD 32 may provide storage for several samples because the delay of the network between the CCAP core 30 and the RPD 32 may change over time based on routing, congestion, and other factors.

[0023] In many cases, it may not be desirable to change the MAP advance time frequently, especially based on only small changes in delay, as this requires processing resources. However, in particular, some operators use networks that provide normal and redundant paths from the core to the RPD, and the redundant paths are usually longer, so they require a longer MAP advance time because a too short MAP advance time can result in data loss and modem deregistration. However, when using shorter normal paths, a shorter MAP advance time helps improve performance, since a shorter MAP advance time leads to better user throughput and reduced delay.

[0024] Novel systems and methods are disclosed that avoid excessive MAP front-loading time adjustments and maintain user throughput while avoiding data loss. Specifically, this specification discloses systems and methods that utilize a small number of discrete MAP front-loading time values ​​and switch between these values ​​based on a comparison of a measured latency metric to a threshold latency metric. In an exemplary embodiment, there may be only two layers of MAP front-loading time values ​​and a single threshold latency metric. Other embodiments may employ more tiers of MAP front-loading time values ​​and more associated threshold latency metric.

[0025] 4 illustrates an exemplary method according to one embodiment of the present disclosure. At step 110, a latency metric is selected, and at step 112, a counter is set. At step 114, a short MAP advance time is adopted by a CCAP core, such as core 30, and transmitted in a downstream MAP message. At step 116, one or more latency metrics L mThe latency metrics may be obtained in any suitable manner. In one embodiment, for example, the latency from the CCAP core to the remote device may be measured by the CCAP core using Downstream External PHY Interface (DEPI) delay measurements. In other embodiments, the latency measurements may be calculated based on Precision Timing Protocol (PTP) message exchanges between the CCAP core and the remote device. These latency measurements may be calculated by the CCAP core or, alternatively, may be calculated by the remote device and transmitted to the CCAP core.

[0026] In step 118, the calculated latency metric is compared to one or more thresholds L s If the latency metric is greater than the applicable threshold, a higher MAP time is selected in step 120. In a preferred embodiment, in optional step 122, a counter is set from an initial value of zero to a value of "N". As explained below, this counter is used to ensure that the higher MAP value is reduced only after a threshold number of measurements indicate a decrease in latency. Thus, in this particular preferred embodiment, a single instance of a latency measurement exceeding the threshold may cause the method to use a higher MAP advance time, but that higher MAP time is not reduced until a number of successive measurements have been made that indicate doing so is justified. This precaution adds robustness to the method and minimizes the number of instances in which a MAP message is not received on time.

[0027] After the counter is set in step 122, a new latency measurement is obtained in step 116 and then compared to the threshold again in step 118. If the comparison indicates that the latency measurement is still higher than the threshold, a higher MAP time is again selected and the counter remains at the value "N". (Those skilled in the art will recognize that if more than two MAP times are used, then the MAP time may be further increased in step 120 if a comparison to more than one threshold is required.)

[0028] Returning to step 118, if the latency measurement is less than the applicable threshold, then in step 124 it is determined whether the counter is zero. If not, the counter is decremented by one and the method returns to step 116 for a new latency measurement, and so on. The above procedure occurs until the counter is decremented to zero, at which point the procedure returns to step 114 where the MAP time is reduced to a lower value.

[0029] 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 principle that expands the scope of enforceable claims beyond their 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, structure, or method having more instances of that element than are recited. As used in the claims, the term "comprise" or any derivative thereof 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. 1. A method comprising: setting a plurality of predetermined MAP advance time values; Measuring an amount of latency between a CCAP core transmitting upstream and a remote device; selecting one of the plurality of predefined MAP advance time values ​​based on the amount of latency measured; and and transmitting a reservation MAP to the remote device having the identified MAP advance time.

2. The method of claim 1 , further comprising comparing the measured amount of latency to at least one threshold.

3. The method of claim 2 , wherein the number of thresholds is one less than the number of the plurality of predetermined MAP advance time values.

4. The method of claim 1 , further comprising altering a value of a counter based on a comparison of the latency measurement to the threshold.

5. The method of claim 4 , wherein the counter is incremented or decremented based on whether the latency measurement exceeds or does not exceed the threshold.

6. The method of claim 4 , wherein the counter is decremented if the counter is greater than one and the latency measurement is not greater than the threshold.

7. The method of claim 1 , wherein the number of the plurality of predetermined MAP advance times is two.

8. The method of claim 1 , wherein the number of the plurality of predetermined MAP advance times is greater than two.

9. The method of claim 1 , wherein a higher value of the predetermined MAP time is selected when a signal instance of a latency measurement exceeds the threshold.

10. The method of claim 9 , wherein a lower value of the predetermined MAP time is selected after determining that the continuously measured pre-latency values ​​do not exceed the threshold.

11. 1. A CCAP core for communicating with a remote device in a communications network, the CCAP core being configured to determine a latency associated with sending a MAP message to the remote device and to use the determined latency to select from among a plurality of predefined MAP advance time values ​​for communicating in the MAP message.

12. The CCAP core of claim 1 , configured to compare the latency measurement to at least one threshold.

13. The CCAP core of claim 12 , wherein the number of thresholds is one less than a number of the plurality of predetermined MAP advance time values.

14. The CCAP core of claim 12 configured to modify a value of a counter based on the comparison.

15. The CCAP core of claim 14 , wherein the counter is incremented or decremented based on whether the latency measurement exceeds or does not exceed the threshold.

16. 15. The CCAP core of claim 14, configured to decrement the counter when the counter is greater than one and the latency measurement is not greater than the threshold.

17. The CCAP core of claim 11 , wherein the number of the plurality of predetermined MAP advance times is two.

18. The CCAP core of claim 11 , wherein the number of the plurality of predetermined MAP advance times is greater than two.

19. The CCAP core of claim 11 , configured to select a higher value of the predetermined MAP time when a signal instance of the latency measurement exceeds the threshold.

20. 20. The CCAP core of claim 19, configured to select a lower value of the predetermined MAP time after a determination that a number of successively measured latency measurements do not exceed the threshold.

Images