Patent Description:
D1 (<CIT>) discloses an example method for managing time offset and frequency drift in asynchronous data over cable service interface specification (DOCSIS) remote physical layer (R-PHY) network environments. D2 (<CIT>) discloses an M-CMTS compatible UEQAM device that implements circuitry to identify and analyze a MAP message in the data stream sent from a M-CMTS core with respect to timing information embedded in those messages.

Although Cable Television (CATV) networks originally delivered content to subscribers over large distances using an exclusively RF transmission system, modern CATV transmission systems have replaced much of the RF transmission path with a more effective optical network, creating a hybrid transmission system where cable content terminates as RF signals over coaxial cables, but is transmitted over the bulk of the distance between the content provider and the subscriber using optical signals. Specifically, CATV networks include a head end at the content provider for receiving signals representing many channels of content, multiplexing them, and distributing them along a fiber-optic network to one or more nodes, each proximate a group of subscribers. The node then de-multiplexes the received optical signal and converts it to an RF signal so that it can be received by viewers. The system in a head end that provides the video channels to a subscriber typically comprises a plurality of EdgeQAM units operating on different frequency bands that are combined and multiplexed before being output onto the HFC network.

Historically, the head end also included a separate Cable Modem Termination System (CMTS), used to provide high speed data services, such as video, cable Internet, Voice over Internet Protocol, etc. to cable subscribers. Typically, a CMTS will include both Ethernet interfaces (or other more traditional high-speed data interfaces) as well as RF interfaces so that traffic 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. Downstream 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 modern HFC CATV systems have combined the functionality of the CMTS with the video delivery system (EdgeQAM) in a single platform called the Converged Cable Access Platform (CCAP).

As networks have expanded and head ends have therefore 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 access architecture (DAA) keeps the cable 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 (Ethernet/PON) connection.

One such distributed architecture is Remote PHY (R-PHY) distributed access architecture that relocates the physical layer (PHY) of a traditional CCAP by pushing it to the network's fiber nodes. Thus, while the core in the CCAP performs the higher layer MAC 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.

Once the functionality of the CMTS/CCAP is divided between a MAC layer in, e.g. a CCAP core and various PHY devices throughout the network, however, synchronously coordinating the transmissions between the downstream cable modems and the CCAP core becomes much more difficult. Specifically, to reduce interference among upstream transmissions, the CCAP sends downstream scheduling messages informing each cable modem of upcoming transmission windows assigned to it, and these scheduling messages must be received a sufficient amount of time before such transmission windows, and close enough to the transmission window so as not to interfere with cable modem performance. Ordinarily, a CCAP would be able to reliably calculate the transmission delay between when it sends such messages and the time a cable modem receives the messages because the conditions between the CCAP and modem typically do not change rapidly. Such rapid changes do exist in an R-PHY system, however. What is therefore desired are improved systems and methods in an R-PHY architecture for determining the delay between the time a MAP message is sent and the time it is received.

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:.

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:.

MAP messages: messages sent by the CCAP containing bandwidth allocation maps (MAP). The MAP contains information that indicates when a cable modem can transmit and for how long. The CCAP needs to send MAP messages ahead of time, so the cable modem will not miss the transmit opportunity.

MAP advance time: The amount of time that the CCAP sends the MAP messages ahead of the transmit opportunity of a cable modem.

DOCSIS tics: a unit of time expressed in units of mini-slots since CMTS initialization time, where a mini-slot is <NUM>µsec.

As already noted, in R-PHY systems, the clocks of the Remote PHY Devices (RPDs) and the CCAP core must be synchronized in both phase and frequency to properly schedule data transfers between network components. <FIG> shows an exemplary topology <NUM> used to synchronize the devices in an R-PHY architecture. Topology <NUM> may include a CCAP core <NUM> synchronized with an RPD <NUM> connected together via a plurality of network switches <NUM>. The RPD <NUM> is in turn connected to one or more cable modems <NUM>. Synchronization is attained by a clock <NUM> in the core <NUM>, acting as a grandmaster clock, which sends timing information to a slave clock <NUM> in the RPD <NUM>. Those of ordinary skill in the art will appreciate that, although <FIG> shows only one RPD <NUM> connected to the core <NUM>, many such RPDs may be simultaneously connected to the core <NUM>, with each RPD having a slave clock <NUM> receiving timing information from the grandmaster clock <NUM> in the core. Those of ordinary skill in the art will also appreciate that an alternative timing architecture could include a separate grandmaster clock.

<FIG> shows an alternate topology <NUM>, which differs from the topology <NUM> in that a separate grandmaster clock <NUM> is used to synchronize both the clock <NUM> in the core <NUM> and the clock <NUM> in the RPD <NUM>. In this architecture, the clock <NUM> and the clock <NUM> operates as a slave to the grandmaster clock <NUM>.

Also as already noted, the CCAP core <NUM> operates as a MAC layer in an R-PHY system and is responsible for creating and sending periodic downstream MAP packets i.e., scheduling messages to the cable modems <NUM> so as to coordinate upstream transmissions among the network of cable modems <NUM>. In turn, the cable modems <NUM> use the received MAP messages to determine when they may each gain access to the upstream channel and transmit packets in the upstream direction. These MAP messages must be received a sufficient amount of time before the transmission windows included in the MAP messages are scheduled to begin. Typically, the CMTS is configured with the maximum time needed for a MAP message to propagate through the HFC network to a cable modem, so that the CMTS can make sure it transmits MAPs early enough to be usable when it arrives at the cable modem. In legacy systems not based on an R-PHY architecture, a CCAP could reliably calculate the maximum transmission delay between when a MAP message is sent and when it will be received by a cable modem because the conditions between the CCAP and a cable modem are mostly known in advance, and because the transmission path between the CCAP and the cable modem is not subject to significant jitter.

In an R-PHY system, however, a variable latency is added in the transmission of a MAP message because the MAC layer and PHY layer of the CMTS are geographically separated by a packet switched network, and this latency often cannot be predicted by an operator. Thus, when the MAC layer prepares a bandwidth MAP and sends it to the PHY layer, it must determine the extra delay of traversing the packet switched network between the MAC and PHY layers when determining how early to send a Bandwidth MAP packet. Knowledge of the delay from the MAC layer to the PHY layer is crucial to the operation and performance of the system.

<FIG> shows a method for determining an appropriate MAP advance time in an R-PHY system. In this method, a CCAP core <NUM> has a master clock <NUM> used to synchronize its time to that of a slave clock <NUM> in an RPD <NUM>, ensuring that each of the core <NUM> and the RPD <NUM> are synchronized to the same DOCIS tics since CMTS initialization. Those of ordinary skill in the art will appreciate that the master clock <NUM> may be a grandmaster clock or may in turn be a boundary clock that is a slave to a separate grandmaster clock.

The CCAP core <NUM> may utilize a DEPI Latency Measurement (DLM) message exchange protocol, which uses Downstream External PHY Interface (DEPI) messages that serve to measure the latency between the CCAP Core <NUM> and RPD <NUM>. Specifically, The CCAP Core <NUM> sends a DLM request message <NUM> to the RPD <NUM>. Before transmitting the DLM request message <NUM> on the packet switched network, the CCAP Core <NUM> writes a timestamp in the packet, recording the CCAP Core transmit time of the packet. The units for this timestamp are preferably DOCSIS ticks. When the DLM request <NUM> arrives at the RPD <NUM>, the RPD <NUM> records the time of packet arrival. The RPD <NUM> then forms a DLM response message <NUM>, which contains the timestamp from the CCAP Core <NUM> and a timestamp representing the time of packet arrival at the RPD <NUM> - both in units of DOCSIS ticks. The RPD <NUM> then transmits this DLM response to the CCAP Core, which then subtracts the CCAP Core timestamp from the RPD timestamp, and thereby get a resultant value which is the one-way latency <NUM> from the CCAP Core <NUM> to the RPD <NUM> in DOCSIS ticks. This time can be converted to units of seconds. Once the CCAP Core <NUM> has the latency measurement, it can make estimates of the other delays in the time it takes for the Bandwidth MAP packet to make it from the CCAP Core <NUM> to the cable modem, and use these estimates along with the measure of the latency from the CCAP Core <NUM> to the RPD <NUM> to determine the ideal time to transmit a Bandwidth MAP to have it arrive at a cable modem within tolerance.

The method shown in <FIG> may have several disadvantages. First, DLM requires extra dataplane messages to achieve its goal. Second, DLM requires extensive changes on the CCAP Core and RPD to be able to format and process DLM messages and handle message error scenarios. In addition, the CCAP Core needs to track periodically sent messages and outstanding messages. Third, a CCAP Core may be connected to hundreds of RPDs. Periodically sending a DLM request and processing a DLM response from potentially hundreds of RPDs may overwhelm the processing capability of the CCAP Core.

<FIG> shows an alternate system and method, according to the claimed invention, for determining an appropriate MAP advance time in an R-PHY system, which instead of exchanging separate messages devoted to measuring the packet delay from a CCAP core <NUM> to an RPD <NUM>, uses data from the MAP messages themselves to estimate delay and adjust a MAP advance time accordingly. MAP messages include a MAP allocation start time, which is the start time of the temporal window for which the MAP allocates bandwidth. By examining the map allocation start time in a received MAP and comparing it to the time the RPD transmits the received MAP message to downstream cable modems, an RPD can determine the actual measured "HFC map lead time," which is the receipt time relative to the MAP allocation start time. The RPD <NUM> can record, store, and report this data as needed back to the CCAP core <NUM>. When determining its MAP advance time, i.e. the time that the CCAP core calculates that it should send a MAP message in advance of the window for which the MAP is applicable, the CCAP core will have made certain assumptions about the latency between the MAC layer and PHY layer, and from those assumptions determine an expected HFC map lead time by which the RPD will have been expected to have received the MAP and relayed it downstream to a cable modem. The MAC layer device can compare the measured HFC map lead time that is reported by the PHY layer device, to its own expected HFC map lead time. From this comparison the MAC layer can determine if its assumed latency is correct or not, and can adjust the assumed latency until the expected HFC map lead time matches the measured HFC map lead time.

Specifically, a system may include a CCAP core <NUM> with a master clock <NUM> connected via a packet switched network to an RPD <NUM> having a slave clock <NUM>. The master clock <NUM> and the slave clock <NUM> ensure that each of the core <NUM> and the RPD <NUM> are synchronized to the same DOCIS tics since CMTS initialization. The CCAP core <NUM> may construct a MAP message <NUM> which includes a start time for the window that the MAP allocates bandwidth, recorded as a start_alloc_time_mini_slots. The MAP message is transmitted to the RPD <NUM>, which would ordinarily pass the MAP message downstream onto its RF port. Prior to doing so, however, the RPD <NUM> parses the MAP message to retrieve the start_alloc_time_mini_slots, and records that value along with a time stamp for receipt of the MAP message, pkt_arrival_time_docsis_tick.

The start_alloc_time_mini_slots value in the Bandwidth MAP packet is expressed in units of mini-slots since CMTS initialization time. The RPD <NUM> preferably converts this time stamp into units of DOCSIS ticks since CMTS initialization. This can be done by looking at the "mini-slot size" associated with the MAP, which is configured on the RPD <NUM> by the CCAP Core <NUM> at RPD initialization. The configured mini-slot size parameter is the size of a single mini-slot in DOCSIS ticks. Thus, the start_alloc_time_mini_slots in the Bandwidth MAP packet is multiplied by the mini-slot size to give the resultant alloc start time expressed in DOCSIS ticks which is stored as map_alloc_start_time_docsis_tick. The RPD may also estimate the time it takes from recordation of the pkt_arrival_time_docsis_tick to the time that the Bandwidth MAP packet is actually transmitted downstream on its RF port. This estimate is fairly constant for the RPD <NUM>, as the processing time for Bandwidth MAP packets does not vary much over time. This constant is also preferably expressed in units of DOCSIS ticks and may be denoted as est_processing_time_docsis_ticks.

A time expressed in units of DOCSIS ticks can be converted to seconds via multiplying by the constant seconds_per_docsis_tick, which is equal to <NUM>/<NUM>. Thus, The RPD can create a message <NUM> comprising the time in seconds that the RPD <NUM> actually received the MAP message <NUM> in advance of the MAP start allocation time via the following formula: <MAT>.

The message <NUM> may then be sent to the CCAP core <NUM> which may use the measured MAP lead time to dynamically adjust its MAP advance time. In some embodiments, the CCAP core <NUM> may examine the recorded samples and determine if the measured HFC map lead time is within a tolerance threshold for a portion of the RF plant attached to the reporting RPD <NUM>. If the HFC map lead time is out of tolerance, the CCAP Core <NUM> can take a number of actions, including but not limited to (i) alerting the operator via logging or other user interface; (ii) adjusting its internal algorithms for how early to transmit Bandwidth MAPs to the RPD for the purpose of bringing the HFC map lead time back into tolerance; and (iii) collecting and storing data for later analysis to allow for identifying network issues and debugging.

In some embodiments, the RPD <NUM> may examine a MAP packet periodically and record the HFC map lead time for these packets. Each HFC map lead time is recorded a sample in a database and stored on the RPD <NUM>. The RPD <NUM> may in some embodiments store the most recent X samples for retrieval by the CCAP Core <NUM> or a cable operator. The RPD <NUM> may provide storage for a number of samples, because the latency of the network between the CCAP Core <NUM> and the RPD <NUM> can vary over time based on routing, congestion, and other factors.

Claim 1:
A Converged Cable Access Platform 'CCAP' core (<NUM>) in a Remote Physical 'R-PHY' architecture that sequentially sends a plurality of bandwidth MAP messages to a Remote Physical Device 'RPD'(<NUM>), each MAP message sent at a time based on a calculated MAP advance time and each MAP message allocating bandwidth for the RPD (<NUM>) during an interval beginning at a start time (<NUM>) specified in the MAP message, characterised in that the CCAP core (<NUM>) is capable of dynamically adjusting the MAP advance time using a measured parameter received within a message from the RPD (<NUM>), where the measured parameter is based on difference between the start time (<NUM>) in the MAP message and a measurement of the time (<NUM>) that the RPD (<NUM>) received the MAP message from the CCAP core (<NUM>).