Partial video asynchronous support using R-MACPHY devices

Abstract

A system and method for providing timing information from an R-MACPHY device to a video core when the R-MACPHY device receives video data from the video core while operating in an asynchronous mode, in some embodiments, the R-MACPHY device may be selectively configured to switch between synchronous and asynchronous modes of operation, and may provide timing information to the video core when switching to the asynchronous mode.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims priority to U.S. Provisional Patent Application No. 63 / 168,032, filed Mar. 30, 2021, and U.S. Provisional Patent Application No. 63 / 119,954, filed Dec. 1, 2020, the entire disclosures of both of which are incorporated herein by reference.

Background Art

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

Summary of the Invention

[0003] While cable television (CATV) networks originally used dedicated RF transmission systems to deliver content to subscribers over long distances, current CATV transmission systems have replaced much of the RF transmission path with more efficient optical networks, creating a hybrid transmission system where cable content terminates as RF signals on coaxial cables, but is transmitted using optical signals over the majority of the distance between the content provider and the subscriber. Specifically, a CATV network includes a headend at the content provider's location to receive signals representing many channels of content, to multiplex those signals, and to distribute those signals along the optical fiber network to one or more nodes adjacent to each subscriber group. The nodes then demultiplex the received optical signals, converting them back into RF signals that viewers can receive. Within the headend, the system providing video channels to subscribers typically includes multiple EdgeQAM units operating in different frequency bands that are coupled and multiplexed before being output over the HFC network.

[0004] Historically, the headend also included a separate Cable Modem Termination System (CMTS) used to provide cable subscribers with high-speed data services such as video, cable internet, and voice over internet protocol. Typically, the CMTS included both an Ethernet® interface (or other more conventional high-speed data interface) and an RF interface, allowing traffic coming from the internet to 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 coaxial (HFC) system. Downstream traffic was delivered from the CMTS to the subscriber's cable modem, while upstream traffic was delivered from the subscriber'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 expand and headends become increasingly congested with equipment, many content providers have in recent years been extending CMTS / CCAP capabilities across the entire network by using distributed architectures. This distributed architecture preserves cable data and video signals in digital format as much as possible, extends the digital signals beyond the CMTS / CCAP into the deeper parts of 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.

[0006] One such distributed architecture is the Remote PHY (R-PHY) distributed access architecture, which relocates the physical layer (PHY) of a conventional CMTS or CCAP by pushing it into the network's fiber nodes. Thus, while the core within the CMTS / CCAP performs processing at the higher layer, the R-PHY devices within the nodes convert the downstream data transmitted by the core from digital to analog for transmission at radio frequencies, and convert the upstream RF data transmitted by the cable modem from analog to digital for optical transmission to the core. Another distributed access architecture is the Remote MAC PHY (R-MACPHY), which not only pushes the physical layer of a conventional CMTS into the network but also assigns the functionality of the Media Access Control (MAC) layer, one of the two layers that make up the data link layer of the transport stream, to one or more nodes in the network called Remote MACPHY devices (RMDs).

[0007] However, when the CMTS / CCAP functionality is divided between the headend core and various PHY or MACPHY devices throughout the network, a protocol must be established to accurately preserve the timing of the reconstructed video data communicated across the network. One typical configuration for accurately preserving the timing of the communicated video data is to ensure that the clocks of various devices in the network are synchronized. Figure 1 shows an exemplary topology 10 that provides synchronization between, for example, a CCAP core 14 and an RPD 16 connected to one or more "customer premises equipment (CPE)" devices 18, but it should be noted that a similar topology can be used, for example, between the core and the RMD. A 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 slave clock 22 in the CCAP core 14 and a second master port 20b connected to a slave clock 24 in the RPD 16. Alternatively, the respective slave 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. The CCAP core 14 may be connected to the timing grandmaster 12 via one or more switches 26, while the RPD 16 may be connected to the timing grandmaster 12 via one or more switches 28. Although Figure 1 shows only one RPD 16 connected to the timing grandmaster 12, multiple such RPDs may be connected to the grandmaster 12 simultaneously, in which case each RPD has a slave clock 24 that receives timing information from port 20b in the grandmaster clock 12.

[0008] While both the core 14 and the RPD 16 are locked to the timing groundmaster 12, no major problems occur. However, problems arise when either the RPD 16 or the core 14 loses its connection to the timing groundmaster 12. During such a holdover period, when one or both devices are not connected to the timing clock of the groundmaster 12, the unconnected devices will drift in terms of frequency and phase from the timing groundmaster 12 and from the other device. The magnitude of this drift will depend on many factors, including the length of the holdover period, temperature fluctuations, and the performance of the internal oscillator. For example, in an RPD with a typical TCXO oscillator, the phase may drift by 1 ms even within an hour. Typically, the drift of the RPD is worse than that of the core, as the core usually has a better oscillator and is in a temperature-controlled environment. If the holdover period during which the drift occurs is long enough, the video quality will degrade to an unacceptable level.

[0009] While alternative asynchronous architectures do not rely on synchronization between the core and downstream devices such as RPDs and RMDs, these architectures involve more complex processing and often result in data packet degradation.

[0010] Therefore, there is a need for improved architectures and methods to accurately store timing information associated with video data transmitted in a distributed access architecture. [Brief explanation of the drawing]

[0011] To better understand the present invention and to illustrate how it can be implemented, the accompanying drawings will be referenced below as examples.

[0012] [Figure 1]Figure 1 shows an exemplary R-PHY system in which both the CCAP core and its RPD are timing slaves to an external ground master clock (GM).

[0013] [Figure 2] Figure 2 shows an architecture in which the video core transmits video data to the RPD in synchronous mode.

[0014] [Figure 3] Figure 3 shows an architecture in which the video core in Figure 2 transmits video data to the RPD in Figure 2 in asynchronous mode.

[0015] [Figure 4] Figure 4 illustrates an exemplary method for the architectures in Figures 2 and 3 to dynamically transition between synchronous and asynchronous modes.

[0016] [Figure 5] Figure 5 shows an exemplary RMACPHY architecture operating in partially asynchronous mode. [Modes for carrying out the invention]

[0017] As mentioned above, in distributed access architectures for delivering video content, two modes of video processing can be used: synchronous mode and asynchronous mode. Typically, network devices have hardware capable of operating in either mode, and in that case, software is provided that allows the video core itself, and connected downstream devices, to be configured to switch to one of those modes when setting up a video channel. In synchronous mode, the RPD (or RMD) and its video core are temporally synchronized with the same reference clock. In this synchronous mode, the RPD only needs to detect lost video packets using Layer 2 Tunneling Protocol v.3 (L2TPv3) sequence number monitoring and insert an MPEG null packet for each missing packet. This is a relatively simple implementation that does not require any additional modifications to the video stream.

[0018] Figure 2 shows a system in a first configuration 100, for example, in which the video core 102 communicates with 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 forwards video data packets to the RPD 104 via a downstream external PHY interface (DEPI) using L2TPv3. The video packets sent from the video core 102 to the RPD 104 will 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.

[0019] The RPD110 then receives video packets transmitted from the video core 108 into the processing device 114's digitter buffer 116. The digitter buffer 116 receives and outputs packet data at a rate that eliminates network jitter caused by different paths of the received packet data or by other sources that cause variations in network delay between the video core and the RPD. Because some packets transmitted by the video streamer 112 may be lost or misplaced during transport to the RPD104, the packets output from the digitter buffer 116 may preferably be forwarded to a module 118 that inserts null packets into the data stream to account for those lost packets in order to maintain the proper timing rate of the transmitted video in synchronous mode. The transport stream, with null packets appropriately inserted, is then forwarded to the PHY device 120, which may decode the packetized elementary stream into a sequence of decoded video frames for downstream distribution to end users by outputting QAM-modulated data in a format expected by 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, or mobile phone.

[0020] Alternatively, the system described here may be configured to operate in asynchronous mode. In asynchronous mode, the RPD104 and its video core 102 are not time-synchronized with respect to the same reference clock. Instead, the RPD104 needs to detect the difference between its own clock 110 and the clock 108 of the video core 102, and also need to be able to insert or remove MPEG packets as needed to maintain the expected MPEG bitrate, and further adjust the MPEG PCR value based on the removal / insertion of MPEG packets.

[0021] Figure 3 shows, for example, the hardware of Figure 2 configured to operate in 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 therefore may 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 in this case also receives the data into the digitter buffer 116 and removes network jitter as described above. However, unlike the configuration of Figure 2, packets output from the digitter buffer 116 are forwarded to a module 118 that both adds null packets as needed and drops packets as needed to maintain an appropriate and constant bitrate for the data received from the digitter buffer 116. Furthermore, after packets are added / dropped as needed, the PCR module 119 re-stamps the data packets with updated PCRs based on the removal / insertion of MPEG packets, and then forwards the re-stamped packets to the PHY device 120.

[0022] Although systems 100 and 101 shown in Figures 2 and 32 are shown using an RPD 104 connected to a video core 102 for illustrative purposes, those skilled in the art will understand that RMDs can also be connected to the video core 102, and that the same components shown with respect to the RPD 104 can be operated in the same manner as the RPD 104.

[0023] Both the synchronous and asynchronous operating modes have advantages and disadvantages. Regarding the asynchronous mode, the main advantage is that it does not depend on clock synchronization between the video core 112 and the RPD 114. Therefore, the RPD 114 will detect those clock differences and accordingly "correct" the MPEG output. The main disadvantage of the asynchronous mode is that this mode is more complex with respect to the video processing that occurs within the RPD 114 during the synchronous mode, and also that, for the purpose of correcting timing mismatches, the RPD 114 needs to sometimes drop MPEG packets from the input stream. This adverse effect can be mitigated if the video core adds null packets to the stream so that the RPD can hold the null packets when it needs to drop packets, but this option adds unnecessary bandwidth to the data stream and / or has an adverse effect on video quality. In many cases, the video core does not add enough null packets to completely eliminate the need to drop data-carrying packets.

[0024] In the synchronous mode, the main advantage is that the RPD does not need to track changes between the input video stream and the internal clock, and no MPEG modifications need to be applied other than adding MPEG null packets in case of detected input packet loss to maintain a constant bit rate at the output, so the video processing of the RPD is simple. The main disadvantage of the synchronous mode is that it depends on clock synchronization between the RPD and the video core. This assumption is usually valid because it is not common for the video core and / or the RPD to lose their connection to the grand master clock, but there are cases where such a connection is lost, and even if not, the clocks of the core and the RPD may not be fully synchronized based on differences in network delays in the timing messages to the grand master clock, or based on internal problems related to either the core or the RPD. In any of these examples, since the synchronous-mode RPD does not adjust the MPEG PCRs at all, the clock difference can cause an improper MPEG stream out of the RPD, which may result in an observable degradation in video quality.

[0025] In some preferred embodiments, the system illustrated in FIGS. 2 and 3 may dynamically shift the RPD104 from the synchronous mode to the asynchronous mode based on information obtained from the digital buffer 116. In such embodiments, the RPD may be configured to operate in the synchronous mode as shown in FIG. 2 in its initial setting until a conditional event is triggered, after which the RPD104 switches to the asynchronous mode as shown in FIG. 3. The RPD104 will then remain in the asynchronous mode until a second conditional event is detected, after which the RPD104 will change to resume synchronous operation as shown in FIG. 2.

[0026] In some embodiments, one or more conditional events may be based on measurements of the state of the dijitter buffer 116. For example, the RPD 104 may preferably implement a first threshold based on measurements, above which the video stream is considered out of sync. The threshold can be defined in many different ways. For example, a suitable first threshold could be the maximum average change (plus or minus) in the buffer's full state from a predefined standard operating level. Thus, the RPD 104 may measure the buffer's full state, optionally average it in some embodiments, or apply filters to remove transient spikes in network jitter, and if the measurement exceeds a predefined first threshold of change, the stream is considered out of sync. An exemplary first threshold in a preferred embodiment may be ±25%. In some preferred embodiments, this first threshold may be configurable.

[0027] An alternative threshold may be a value that measures the rate at which the buffer fills up / empties. The RPD104 may also measure such a metric by selectively filtering, in this case as well, to remove transient changes based on network jitter. If the rate of change exceeds a predefined threshold, the video stream is considered out of sync.

[0028] The RPD104 may also preferably implement a second threshold for dynamically transitioning back from asynchronous mode to synchronous mode. In some embodiments, the second threshold may be the same as the first threshold for transitioning to asynchronous mode, but in other embodiments, the first and second thresholds are different. When different thresholds are used, the second threshold is preferably stricter than the first threshold. For example, using the above example where a first threshold of ±25% is set as the limit for the RPD to dynamically transition from synchronous mode to asynchronous mode, a second threshold of ±15% may be used to dynamically transition back to synchronous mode. In this case as well, in some preferred embodiments, the second threshold may be configurable.

[0029] In some embodiments, when RPD104 is operating in asynchronous mode, RPD104 may implement a priority list of packets to be dropped (in this case, null packets are the first to be dropped, followed by a set of PID values ​​(e.g., SI PIDs, CAT PIDs, etc.)) to reduce the probability of dropping "critical" MPEG packets when null packets are unavailable. Other methods may be applied to reduce the probability of dropping essential MPEG packets, such as prioritizing I-frames over P-frames and B-frames, and prioritizing P-frames over B-frames. Alternative implementations may use a priority-based approach to dynamically reduce the packet rate in a bitstream consisting of program-specific information (PSI), such as program-related table (PAT) data or program-mapping table (PMT) data, to the minimum rate permitted by the MPEG standard.

[0030] Since the switch to asynchronous mode occurs after the buffer state deviates from the nominal or optimal value by a threshold, in some embodiments, the RPD104 may decide to "pull back" the queue to its nominal or optimal depth before switching back to synchronous mode, in order to maintain jitter headroom. This may be appropriate, for example, when the first threshold is set to a small value for low latency.

[0031] Figure 4 illustrates an exemplary method by which the RPD104 can dynamically switch between synchronous and asynchronous modes. In step 132, the RPD is configured to operate in synchronous mode. In step 134, the processing mode of the RPD104 is set to "synchronous". In determination step 136, it is determined whether the buffer state exceeds the first threshold, as described above. If the answer is "no", the method proceeds to step 138, where the RPD104 processes the video stream in "synchronous" mode, then proceeds to step 140, where it is determined whether the data exits buffer 116 at a fixed rate, and proceeds to step 142, where null packets are added as needed to maintain a fixed bitrate entering PHY120. The procedure then returns to step 136, where it is again determined whether the buffer state exceeds the first threshold.

[0032] If it is determined in step 136 that the buffer state exceeds the first threshold, the method then proceeds to step 144, where the RPD processing mode is set to "asynchronous". Next, in step 146, null packets are added or packets are deleted, and further, in step 148, PCR stamps on the packets are adjusted based on the added and deleted packets. In step 148, the packets enter the PHY at a fixed bitrate.

[0033] In decision step 152, it is determined whether the state of buffer 116 exceeds the second threshold. If it does not, the procedure returns to step 144. If it does, the procedure may proceed to optional steps 154 and 156. In decision step 154, it is determined whether it is necessary to return the buffer to the optimal or nominal depth. If the answer is no, the system returns to step 134 and the processing mode of RPD 104 is set to "synchronous". If the answer is yes, in step 156, the asynchronous mode is continued until the buffer is returned to its nominal or optimal depth, and then the procedure returns to step 134 as described above.

[0034] Those skilled in the art will understand that although the systems and methods described with respect to Figures 2 to 4 are illustrated using a video core connected to an RPD, the above disclosure also applies to communication between the video core and the RMD. However, while an RPD typically has to rely on an external source to provide its timing information, an RMD typically includes hardware components having its own oscillator for operating an independent clock within the RMD. Thus, if a network such as those described above includes one or more MACPHY devices, this application discloses additional and partial asynchronous modes that, in some embodiments, can be used in combination with the above systems and methods, or, in alternative embodiments, can be used in systems or methods in which remote devices such as RMDs and RPDs cannot dynamically switch between synchronous and asynchronous modes.

[0035] Specifically, downstream network devices such as RPDs or RMDs operating in asynchronous mode can theoretically detect the clock difference between themselves and the core and "correct" the MPEG output accordingly. However, for this to work, both the video core and the RMD must have oscillators of sufficient quality to maintain an MPEG-compliant clock (approximately 30 PPM accuracy and approximately 10 PPM / hour drift). Since RMDs are hardware-built platforms, they typically have oscillators that meet these requirements for Data Over Cable Service Interface Specification (DOCSIS) operation, which has stricter clock requirements than MPEG video distribution. However, video cores are often simply implemented in software using oscillators built into off-the-shelf (OTS) servers and may not be able to support the required accuracy. In such cases, the video core requires an external GM on which it depends for its clock, thus negating the advantages of operating in asynchronous mode.

[0036] Therefore, referring to Figure 5, the system 200 may include a video core 202 connected to one or more RMDs 204a, 204b, 204c, etc., and each of the RMDs may preferably be configured to have the components shown in Figure 3 with respect to the RPD 104, namely, each of the one or more RMDs may be provided with a digitter buffer 216, modules 118 and 119 for providing null packet insertion / packet removal and PCR adjustment, respectively, a downstream PHY 220, and a clock 210. Although only RMDs are shown in Figure 5, it will be understood by those skilled in the art that the system 200 may also include one or more RPDs.

[0037] As described above, in some embodiments, when the video core 202 loses its connection to the timing grandmaster, the RMDs 204a, 204b, and 204c (and any RPDs 104 in the network) may be configured to operate in asynchronous mode, as described above, preferably to continue processing video packets received from the video core 202. However, to operate reliably in asynchronous mode, the core 202 requires a suitable internal clock, which may not be provided. In such examples, the core 202 may provide more reliable timing information than what its own clock could generate by using one of the RMDs 204a, 204b, or 204c as a designated grandmaster, because the RMDs typically have oscillators that meet the requirements for MPEG video encoding and transmission. In Figure 5, for example, the clock 210 of RMD 204a acts as a designated grandmaster and sends a clock synchronization message 222 to the core 202. In a preferred embodiment, the synchronization message is transmitted from the clock 210 of the RMD204a to the clock 208 of the video core. Preferably, each RMD204a, 204b, 204c, etc., can act as a designated grandmaster, for example, if the connection between the video core 202 and any RMD that previously acted as a designated grandmaster is lost.

[0038] In this "partially asynchronous" mode, the video core 202 preferably locks the designated RMD 204a to its own clock, as it would to any "normal" grandmaster timer, and bases its MPEG clock and PCR on the designated RMD 204a. The designated RMD 204a may preferably only synchronize the video core's clock 208 to its own clock 210, but otherwise, like all other RMDs 204b, 204c, etc., and like any RPDs 104 in the network, it will operate in asynchronous mode. The sole purpose of clock synchronization between the designated RMD 204a and the video core 202 is to provide the video core 202 with a reliable MPEG-compliant clock, and it is not necessary to lock the other RMDs 204b, 204c, etc. to their own clock in order for them to preferably operate in asynchronous mode. Furthermore, since the specified RMD204a can rely on its own oscillator, there is no need to provide it with any other external clock reference in order to lock its own clock.

[0039] Any suitable method may be used to select an RMD that serves as the designated source of timing information for the video core 202 in asynchronous mode. For example, a dedicated provisioning server may be configured to connect the video core 202 to the RMD it designates. Alternatively, each RMD 204a, 204b, 204c, etc., may be configured in asynchronous mode to send its timing information to the video core 202, which then designates a stream to use as the designated grandmaster, for example, using the Best Master Clock Algorithm (BMCA).

[0040] Regardless of the method used to designate an RMD to act as a designated grandmaster, the RMD designated as the timing source for the video core 202 is not locked to an external clock. Therefore, if, for example, the designated RMD is reset or goes offline and triggers another RMD to act as the designated grandmaster, the timing base of the information sent to the video core 202 may change abruptly. This can cause the PCRs it inserts into the MPEG stream to "jump," which in turn can cause problems for the decoder receiving the MPEG stream. Thus, in some preferred embodiments, the video 202 core may set an appropriate "discontinuity indicator" flag on the adaptive field of the first PCR packet when it detects that the time base has changed. The RMDs (or RPDs) may then adjust the PCRs that re-stamp the video stream to eliminate the discontinuity.

[0041] The above disclosure relating to an R-MACPHY device that transmits timing information to a video core while operating in asynchronous mode has been described in the context of a system in which the R-MACPHY device can dynamically configure itself to operate in either synchronous or asynchronous mode. However, those skilled in the art will understand that the embodiment shown in Figure 5 can be similarly used in other situations. For example, as noted above, RPDs and RMDs can often be configured in either asynchronous or synchronous mode, and a video core or other network device can simply be configured to always operate connected RPDs and RMDs in asynchronous mode. Even in such situations, the system shown in Figure 5 can be beneficial. For example, while a remotely connected device is configured to operate in asynchronous mode, if the video core is not receiving timing information from an external grandmaster, the advantage of receiving more reliable timing information from the RMD compared to what its own internal clock provides is obvious, due to the temporary loss of connection, or simply because it is not configured to receive such information from an external grandmaster.

[0042] It will be understood that the present invention is not limited to the specific embodiments described, and that modifications thereof may be made without departing from the scope of the invention as defined in the appended claims, so as to be interpreted in accordance with the principles of current law, including the doctrine of equivalents or any other principle that extends the scope of the claims beyond their literal meaning. Unless the context indicates otherwise, a reference in the claims to the number of component examples, whether it is a reference to one example or to two or more examples, requires at least the number of component examples described, but is not intended to exclude from the claims any structure or method having more component examples than described. When used in the claims, the term “including,” or its derivatives, is used in a non-exclusive sense and is not intended to exclude the existence of other components or steps in the claimed structure or method. The inventions disclosed herein include the following: [Aspect 1] A remote MACPHY (R-MACPHY) device, A clock, and a digitizer buffer that receives video packets from the video core, The system includes at least one module capable of adjusting video packets received from the digitter buffer, wherein the adjustment is modified based on whether the R-MACPHY device is configured to operate in synchronous or asynchronous mode, The aforementioned clock can be configured to selectively output timing information to other devices, and the remote MACPHY (R-MACPHY) device is configured to selectively choose to output timing information to other devices when the R-MACPHY device is operating in asynchronous mode. [Aspect 2] The device according to embodiment 1, wherein at least one module selectively drops packets received from the digitter buffer in asynchronous mode. [Aspect 3] The device according to embodiment 1, wherein at least one module selectively re-stamps the packet with a program clock reference (PCR) value in asynchronous mode. [Aspect 4] The device according to embodiment 3, configured to selectively use an offset value to re-stamp the PCR value. [Aspect 5] The device according to embodiment 1, wherein the other device is the video core. [Aspect 6] The other device is a provisioning server, as described in Embodiment 1. [Aspect 7] It is a video core, A video streamer configured to send video packets to at least one remote device, including a first device, A clock having a first input configured to receive synchronization information from the first device and to use the synchronization information to control the rate at which the video streamer transmits the plurality of packets to the at least one remote device, A video core, wherein the core does not transmit the synchronization information to the at least one remote device, the video packets include PCRs, and the video streamer is configured to transmit offset values ​​associated with the PCRs. [Aspect 8] The video core according to embodiment 7, configured to select synchronization information from the first device from among synchronization information received from multiple unsynchronized remote devices. [Aspect 9] The video core according to embodiment 7, configured to receive information from one of the multiple unsynchronized remote devices selected by the provisioning server. [Aspect 10] A device within a communication network, which is a device that receives and selectively modifies an MPEG-compliant transport stream received from a video core, and further transmits the transport stream downstream to customer premises equipment (CPE), wherein the device is configured to determine the amount of synchronization between the device and the video core, and is configured to switch itself to either a synchronous mode or an asynchronous mode selectively based on the determined amount of synchronization. [Aspect 11] The device according to embodiment 10, including a remote physical device (RPD). [Aspect 12] The device according to embodiment 10, including a remote MACPHY device (RMD). [Aspect 13] The device according to embodiment 10, which is configured to receive timing information from a common timing source and also provides the timing information to the video core, and switches from synchronous mode to asynchronous mode when at least one of the device and the video core loses a lock on the common timing source. [Aspect 14] The device according to embodiment 13, wherein the device switches from asynchronous mode to synchronous mode when at least one of the device and the video core, which has lost a lock on the common timing source, regains the lock on the common timing source. [Aspect 15] The device according to embodiment 10, which can be configured to receive timing information from a common timing source and also to provide the timing information to the video core, and which can switch from synchronous mode to asynchronous mode at once when both the device and the video core maintain a lock on the common timing source. [Aspect 16] The device according to embodiment 10, wherein the device has a digitter buffer, and the device modifies the MPEG-compliant transport stream based on the output of the digitter buffer. [Aspect 17] The device according to embodiment 16, wherein the device determines the synchronization amount using the output of the digitizer buffer. [Aspect 18] The device according to embodiment 10, wherein the device is configured to change from a synchronous mode to an asynchronous mode based on a determined amount of synchronization, and is also configured to change from an asynchronous mode to a synchronous mode based on a determined amount of synchronization. [Aspect 19] The device according to embodiment 18, which can change from asynchronous mode to synchronous mode using the determined synchronization amount and the determined offset of the jitter buffer in the device with respect to the degree of fullness from a predetermined amount of fullness. [Aspect 20] It is a system, A video core having a core clock and a video streamer, A remote MACPHY (R-MACPHY) device includes: a clock communicating with the video core clock; a digitter buffer that receives video packets from the video streamer; and at least one module capable of adjusting the video packets received from the digitter buffer, the adjustment being modified based on whether the R-MACPHY device is configured to operate in synchronous or asynchronous mode; The remote clock is a system that selectively provides timing information to the core clock when the R-MACPHY device is operating in asynchronous mode. [Aspect 21] The system according to embodiment 20, wherein at least one module selectively drops packets received from the digitter buffer in asynchronous mode. [Aspect 22] The system according to embodiment 20, wherein at least one module selectively re-stamps the packet with a program clock reference (PCR) value in asynchronous mode. [Aspect 23] The system according to embodiment 20, wherein the core clock is configured to selectively transmit an offset value to the R-MACPHY device. [Aspect 24] It is a method, The R-MACPHY device transmits synchronization information from a remote clock to the core clock in the video core. The video streamer within the video core transmits video data to at least one physical (PHY) device downstream from the video core, which includes the R-MACPHY device. A method comprising operating the at least one PHY device, including the R-MACPHY device, in asynchronous mode. [Aspect 25] The method according to embodiment 24, wherein the core clock is configured to selectively transmit an offset value to the R-MACPHY device. [Aspect 26] The method according to embodiment 24, wherein the video core controls the rate at which packets are transmitted from the video streamer by providing the synchronization information from the R-MACPHY device to the video streamer. [Aspect 27] The method according to embodiment 26, wherein the at least one other device includes another R-MACPHY device. [Aspect 28] The method according to embodiment 27, wherein timing information from the R-MACPHY device is selected preferentially over timing information from another R-MACPHY device for the video core to transmit to the video streamer. [Aspect 29] The method according to embodiment 27, wherein the selection of timing information from the R-MACPHY device is performed by the video core. [Aspect 30] The method according to embodiment 27, wherein the selection of timing information from the R-MACPHY device is performed by the provisioning server. [Aspect 31] A method for dynamically switching between synchronous and asynchronous operating modes for a device that is in a communication network and receives video data from a video core, Initializing the device to operate in synchronous mode, Determining the synchronization strength between the device and the video core, A method comprising selectively switching to asynchronous mode based on a determined amount of synchronization. [Aspect 32] The method according to embodiment 31, performed by a remote physical device (RPD). [Aspect 33] The method according to embodiment 31, performed by a remote MACPHY device (RMD). [Aspect 34] The method according to embodiment 31, further comprising the step of selectively changing from asynchronous mode back to synchronous mode based on a determined second synchronization intensity. [Aspect 35] The method according to embodiment 34, comprising the steps of determining the synchronization strength by measuring the state of the digitter buffer in the device, and restoring the degree of fullness of the digitter buffer to a predetermined level before changing the device back to asynchronous mode. [Aspect 36] The method according to embodiment 34, wherein the second synchronous strength to be determined is different from the first synchronous strength to be determined. [Aspect 37] The method according to embodiment 36, wherein the determined second synchronous intensity is smaller than the determined first synchronous intensity. [Aspect 38] The method according to embodiment 31, wherein the synchronization strength is determined by measuring the state of the digitator buffer in the device. [Aspect 39] The method according to embodiment 38, wherein the state of the digitizer buffer to be measured is the full state of the digitizer buffer and the rate of change of the full state of the digitizer buffer. [Aspect 40] The method according to embodiment 38, wherein the state of the digitizer buffer to be measured is defined as the rate of change of the full state of the digitizer buffer.

Claims

1. A remote MACPHY (R-MACPHY) device, A clock, and a digitizer buffer that receives video packets from the video core, The system includes at least one module capable of adjusting video packets received from the digitter buffer, wherein the adjustment is modified based on whether the R-MACPHY device is configured to operate in synchronous or asynchronous mode, The aforementioned clock can be configured to selectively output timing information to other devices, and the remote MACPHY (R-MACPHY) device is configured to selectively choose to output timing information to other devices when the R-MACPHY device is operating in asynchronous mode.

2. The device according to claim 1, wherein at least one module selectively drops packets received from the digitter buffer in asynchronous mode.

3. The device according to claim 1, wherein at least one module selectively re-stamps the packet with a program clock reference (PCR) value in asynchronous mode.

4. The device according to claim 3, configured to selectively use an offset value to re-stamp the PCR value.

5. The device according to claim 1, wherein the other device is the video core.

6. The device according to claim 1, wherein the other device is a provisioning server.

7. It is a video core, A video streamer configured to send video packets to at least one remote device, including a first device, A clock having a first input configured to receive synchronization information from the first device and to use the synchronization information to control the rate at which the video streamer transmits a plurality of packets to at least one remote device, A video core, wherein the core does not transmit the synchronization information to the at least one remote device, the video packet includes a PCR, and the video streamer is configured to transmit an offset value associated with the PCR.

8. The video core according to claim 7, configured to select synchronization information from the first device from among synchronization information received from multiple unsynchronized remote devices.

9. The video core according to claim 7, configured to receive information from one of the multiple unsynchronized remote devices selected by the provisioning server.

10. A device within a communication network, which is a device that receives and selectively modifies an MPEG-compliant transport stream received from a video core, and further transmits the transport stream downstream to customer premises equipment (CPE), wherein the device is configured to determine the amount of synchronization between the device and the video core, and is configured to switch itself to either a synchronous mode or an asynchronous mode selectively based on the determined amount of synchronization.

11. The device according to claim 10, comprising a remote physical device (RPD).

12. The device according to claim 10, comprising a remote MACPHY device (RMD).

13. The device according to claim 10, which is configured to receive timing information from a common timing source and also provides the timing information to the video core, and switches from synchronous mode to asynchronous mode when at least one of the device and the video core loses a lock to the common timing source.

14. The device according to claim 13, wherein the device switches from asynchronous mode to synchronous mode when at least one of the device and the video core, which has lost a lock on the common timing source, regains the lock on the common timing source.

15. The device according to claim 10, which is configured to receive timing information from a common timing source and also provides the timing information to the video core, and switches from synchronous mode to asynchronous mode when both the device and the video core maintain a lock to the common timing source.

16. The device according to claim 10, further comprising a digitter buffer, wherein the device modifies the MPEG-compliant transport stream based on the output of the digitter buffer.

17. The device according to claim 16, wherein the device determines the synchronization amount using the output of the digitizer buffer.

18. The device according to claim 10, wherein the device is configured to change from a synchronous mode to an asynchronous mode based on a determined synchronization amount, and is configured to change from an asynchronous mode to a synchronous mode based on a determined synchronization amount.

19. The device according to claim 18, which can change from asynchronous mode to synchronous mode using the determined synchronization amount and the determined offset of the jitter buffer in the device with respect to the degree of fullness from a predetermined amount of fullness.

20. It is a system, A video core having a core clock and a video streamer, An R-MACPHY device includes: a clock communicating with a video core clock; a digitter buffer that receives video packets from the video streamer; and at least one module capable of adjusting the video packets received from the digitter buffer, wherein the adjustment is modified based on whether the remote MACPHY (R-MACPHY) device is configured to operate in synchronous or asynchronous mode. The aforementioned clock is a system that selectively provides timing information to the core clock when the R-MACPHY device is operating in asynchronous mode.

21. The system according to claim 20, wherein at least one module selectively drops packets received from the digitter buffer in asynchronous mode.

22. The system according to claim 20, wherein at least one module selectively re-stamps the packet with a program clock reference (PCR) value in asynchronous mode.

23. The system according to claim 20, wherein the core clock is configured to selectively transmit an offset value to the R-MACPHY device.

24. It is a method, The R-MACPHY device transmits synchronization information from a remote clock to the core clock in the video core, The video streamer within the video core transmits video data to at least one physical (PHY) device downstream from the video core, which includes the R-MACPHY device. This includes operating the at least one PHY device, including the R-MACPHY device, in asynchronous mode. A method wherein the core clock is configured to selectively transmit an offset value to the R-MACPHY device.

25. The method according to claim 24, wherein the video core controls the rate at which packets are transmitted from the video streamer by providing the synchronization information from the R-MACPHY device to the video streamer.

26. The method according to claim 25, wherein the at least one PHY device includes another R-MACPHY device.

27. The method according to claim 26, wherein timing information from the R-MACPHY device is selected preferentially over timing information from another R-MACPHY device for the video core to transmit to the video streamer.

28. The method according to claim 26, wherein the selection of timing information from the R-MACPHY device is performed by the video core.

29. The method according to claim 26, wherein the selection of timing information from the R-MACPHY device is performed by a provisioning server.

30. A method for dynamically switching between synchronous and asynchronous operating modes for a device that is in a communication network and receives video data from a video core, Initializing the device to operate in synchronous mode, Determining the first synchronization amount between the device and the video core, A method comprising selectively switching to an asynchronous mode based on a determined first synchronization amount.

31. The method according to claim 30, performed by a remote physical device (RPD).

32. The method according to claim 30, performed by a remote MACPHY device (RMD).

33. The method according to claim 30, further comprising the step of selectively changing from asynchronous mode back to synchronous mode based on a determined second synchronization amount.

34. The method according to claim 33, comprising the steps of determining the first synchronization amount by measuring the state of the digitter buffer in the device, and restoring the degree of fullness of the digitter buffer to a predetermined level before changing the device back to synchronization mode.

35. The method according to claim 33, wherein the second synchronization amount to be determined is different from the first synchronization amount to be determined.

36. The method according to claim 35, wherein the second synchronization amount to be determined is smaller than the first synchronization amount to be determined.

37. The method according to claim 30, wherein the first synchronization amount is determined by measuring the state of the digitter buffer in the device.

38. The method according to claim 37, wherein the state of the digitator buffer to be measured is the state of the digitator buffer being full and the rate of change of the state of the digitator buffer being full.

39. The method according to claim 37, wherein the state of the digitizer buffer to be measured is defined as the rate of change of the full state of the digitizer buffer.

Images