Dynamic update system for remote physical devices

The dynamic update system for remote PHY devices in cable television systems addresses service interruptions by applying selective resets based on image analysis, ensuring rapid service recovery.

JP7874114B2Active Publication Date: 2026-06-15ARRIS ENTERPRISES LLC

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
ARRIS ENTERPRISES LLC
Filing Date
2022-06-01
Publication Date
2026-06-15

Smart Images

  • Figure 0007874114000001
    Figure 0007874114000001
  • Figure 0007874114000002
    Figure 0007874114000002
  • Figure 0007874114000003
    Figure 0007874114000003
Patent Text Reader

Abstract

A method for updating an embedded device including a processor that receives an image file including at least one of kernel software, hardware configuration data, and application software, the embedded device analyzes the image file to determine a portion of the image file indicated by at least one flag as having been modified from that currently contained on the embedded device, the embedded device installs at least a portion of the image file on the embedded device, and resets the portion of the embedded device based on the at least one flag.
Need to check novelty before this filing date? Find Prior Art

Description

【Technical Field】 【0001】 Cross - reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 195,529, filed on Jun. 1, 2021. 【0002】 The subject matter of this application relates to efficient remote PHY data plane management for cable systems. 【Background Art】 【0003】 Cable television (CATV) services generally provide content from a central distribution unit, generally referred to as a "headend", to a large number of customers (e.g., subscribers). The headend includes associated components (nodes, amplifiers, and taps) and distributes content channels to its customers from this central distribution unit through an access network that includes a hybrid fiber - coaxial (HFC) cable plant. However, modern cable television (CATV) service networks not only provide media content such as television channels and music channels to customers, but also host Internet services, video - on - demand, telephone services such as VoIP, and digital communication services such as home automation / security. These digital communication services sequentially require communication to customers in the downstream direction from the headend through the HFC, typically forming a branch network, and also require communication from customers to the headend in the upstream direction, typically through the HFC network. 【0004】 For this purpose, a CATV headend traditionally included a separate Cable Modem Termination System (CMTS) used to provide cable customers with high-speed data services such as cable internet and voice over internet protocol, as well as a video headend system used to provide video services such as broadcast video and video on demand (VOD). Typically, the CMTS would include both an Ethernet interface (or other more traditional high-speed data interface) and a radio frequency (RF) interface so that incoming traffic from the internet can be routed (or bridged) through the CMTS and then onto an RF interface connected to the cable company's hybrid fiber coaxial (HFC) system. Downstream traffic is delivered from the CMTS to the customer's home cable modem and / or set-top box, while upstream traffic is delivered from the customer's home cable modem and / or set-top box to the CMTS. The video headend system similarly delivers video to either a set-top, a TV with a video decoding card, or another device capable of demodulating and decrypting incoming encrypted video services. Many modern CATV systems combine the functions of a CMTS with a video distribution system (e.g., EdgeQAM - quadrature amplitude modulation) within a single platform generally referred to as an integrated CMTS (e.g., an integrated centralized cable access platform (CCAP)), where video services are created and provided to an I-CCAP, which then QAM modulates the video on the appropriate frequency. Yet another modern CATV system, generally referred to as a distributed CMTS (e.g., a distributed centralized cable access platform), may include a remote PHY (or R-PHY) that relocates the physical layer (PHY) of a conventional integrated CCAP by pushing it to the fiber nodes of the network (an R-MAC PHY relocates both the MAC and PHY to the network nodes).Therefore, while the core within the CCAP platform performs higher-layer processing, the R-PHY device in the remote node converts the downstream data transmitted from the core from digital to analog so that it can be transmitted over radio frequencies to the cable modem and / or set-top box, and converts the upstream radio frequency data transmitted from the cable modem and / or set-top box from analog to digital so that it can be optically transmitted to the core. [Brief explanation of the drawing] 【0005】 To better understand the present invention and to show how it can be carried out, the following accompanying drawings are referenced here as an example. [Figure 1] Figure 1 shows an integrated cable modem termination system. [Figure 2] Figure 2 shows a distributed cable modem termination system. [Figure 3] Figure 3 shows a layered network processing stack. [Figure 4] Figure 4 shows the types of resets supported by the remote physical device. [Figure 5] Figure 5 shows the hard reset process for a remote physical device. [Figure 6] Figure 6 shows the soft reset process for a remote physical device. [Figure 7] Figure 7 shows a software image and its components. [Figure 8] Figure 8 shows the comparison process for identifying the modified components of an image file, and the type of reset process to be performed. [Modes for carrying out the invention] 【0006】 Referring to Figure 1, the integrated CMTS system (e.g., an integrated centralized cable access platform (CCAP)) 100 may include data 110 that is typically transmitted and received over the internet (or other network) in the form of packetized data. The integrated CMTS 100 may also receive downstream video 120, typically in the form of packetized data, from an operator video aggregation system. For example, broadcast video is typically acquired from a satellite distribution system and pre-processed for distribution to subscribers through a CCAP or video headend system. The integrated CMTS 100 receives and processes the received data 110 and downstream video 120. The CMTS 130 may transmit the downstream data 140 and downstream video 150 to the customer's cable modem and / or set-top box 160 through an RF distribution network that may include other devices such as amplifiers and splitters. The CMTS 130 may receive upstream data 170 from the customer's cable modem and / or set-top box 160 through a network that may include other devices such as amplifiers and splitters. The CMTS130 may include multiple devices to achieve its desired capabilities. 【0007】 Referring to Figure 2, as a result of increasing bandwidth demands, limited installation space for integrated CMTS, and power consumption considerations, it is desirable to include a distributed cable modem termination system (D-CMTS) 200 (e.g., a distributed centralized cable access platform (CCAP)). Generally, while CMTS focus on data services, CCAP further includes broadcast video services. The D-CMTS 200 distributes a portion of the functionality of the I-CMTS 100 to downstream locations such as fiber nodes using network packetized data. An exemplary D-CMTS 200 may include a remote PHY architecture, where the remote PHY (R-PHY) is preferably an optical node device located at the fiber and coaxial junction. Generally, the R-PHY often includes the MAC and PHY layers of a portion of the system. The D-CMTS 200 may include a D-CMTS 230 (e.g., a core) which contains data 210 that is transmitted and received over the internet (or other network), typically in the form of packetized data. The D-CMTS230 may also receive downstream video 220, typically in the form of packetized data from an operator video aggregation system. The D-CMTS230 receives and processes the received data 210 and downstream video 220. The remote fiber node 280 preferably includes a remote PHY device 290. The remote PHY device 290 may transmit downstream data 240 and downstream video 250 to the customer's cable modem and / or set-top box 260 through a network which may include other devices such as amplifiers and splitters. The remote PHY device 290 may receive upstream data 270 from the customer's cable modem and / or set-top box 260 through a network which may include other devices such as amplifiers and splitters. The remote PHY device 290 may include multiple devices to achieve its desired capabilities.The remote PHY device 290 primarily includes PHY-related circuitry such as a downstream QAM modulator and an upstream QAM demodulator, along with pseudowire logic connecting to the D-CMTS 230 using network packetized data. The remote PHY device 290 and the D-CMTS 230 may include data and / or video interconnects such as downstream data, downstream video, and upstream data 295. It should be noted that in some embodiments, video traffic may proceed directly to the remote physical device, thereby bypassing the D-CMTS 230. 【0008】 As an example, the remote PHY device 290 may convert downstream DOCSIS (i.e., Data Over Cable Service Interface Specification) data (e.g., DOCSIS 1.0, 1.1, 2.0, 3.0, 3.1, and 4.0, each incorporated herein by reference in its entirety), video data, and out-of-band signals received from the D-CMTS 230 into analog for transmission over RF or analog optics. As an example, the remote PHY device 290 may convert upstream DOCSIS and out-of-band signals received from analog media such as RF or analog optics into digital for transmission to the D-CMTS 230. As can be observed, depending on the particular configuration, the R-PHY may move all or part of the DOCSIS MAC and / or PHY layer to the fiber node. 【0009】 Referring to Figure 3, for data processing and data transfer over a network, the hardware and / or software architecture may consist of multiple different planes, each performing a different set of functions. In the relevant parts, the layered architecture may include different planes such as the management plane 300, the control plane 310, and the data plane 320. The switch fabric 330 may be included as part of the layered architecture. 【0010】 For example, the management plane 300 can generally be considered as customer interaction or a general software application that would otherwise be executed. The management plane typically configures, monitors, and provides management, monitoring, and configuration to all layers of the network stack and other parts of the system. 【0011】 For example, the control plane 310 is often a component of the switching functionality, including system configuration, management, and the exchange of routing table information and forwarding information. Typically, the exchange of routing table information is performed relatively infrequently. The route controller of the control plane 310 exchanges topology information with other switches and builds routing tables based on routing protocols. The control plane may also create forwarding tables for the forwarding engine. Generally, the control plane can be thought of as the layer that determines where traffic is sent. Because control functions are not performed for each individual packet arriving, they tend not to have strict speed constraints. 【0012】 For example, the data plane 320 parses packet headers for switching and manages quality of service, filtering, media access control, encapsulation, and / or queuing. Generally speaking, the data plane carries data traffic, which might be equivalent in a cable distribution network. Generally, the data plane can be thought of as the layer that primarily forwards traffic to the next hop along a chosen path to a destination, through the switch fabric, according to control plane logic. Because the data plane performs functions for each individual packet arriving, it tends to be highly speed-constrained. 【0013】 The remote physical device 290 needs to support software updates for the remote physical device. For example, D-CMTS230 may instruct the remote physical device 290 to reset via ResetCtrl GCP TLV, for example, by using a command-line interface. For example, the remote physical device 290 may initiate a reset on its own in response to some internal or external event. 【0014】 Referring to Figure 4, the remote physical device 290 may include a hard reset 400, which is the most comprehensive form of reset. A hard reset 400 can be considered a "reboot" of the device. When the remote physical device 290 performs a hard reset 400, it performs a power cycle or equivalent, and then returns to a state similar to the state achieved at initial power-up. The remote physical device 290 maintains a non-volatile configuration throughout the hard reset. After the hard reset 400, the remote physical device 290 returns to the beginning of the machine's initialization state and performs initialization. 【0015】 The remote physical device 290 may include a soft reset 410 that provides a partial reset of the remote physical device 290. Following the soft reset 410, the remote physical device 290 takes steps to expedite its initialization process and minimize service interruption. The soft reset 410 resets the volatile configuration and operating state of the remote physical device 290, including terminating all connections to all D-CMTS, releasing IP addresses obtained via DHCP, and clearing network authentication information. The remote physical device 290 may reset all software state except that required to maintain the IEEE 1588 clock frequency. 【0016】 The soft reset 410 achieves faster initialization of the remote physical device 290 by maintaining the current IEEE 1588 clock frequency without adjustment throughout the soft reset 410 process until the synchronization process with the Grand Master Clock (GMC) is resumed. This allows the remote physical device 290 to provide synchronized operation without having to participate in the time consumed by the full PTP synchronization process with the GMC. 【0017】 Referring to Figure 5, a hard reset 400 undergoes a process that typically takes 4-5 minutes, during which service for the customer is not provided by the remote physical device 290. While the hard reset 400 process tends to vary from remote physical device to remote physical device, generally, the D-CMTS230 downloads an image file (.ITB) containing the FPGA image, Uboot (Boot.bin), the Linux® kernel, and all application and software data planes. Next, the remote physical device 290 executes a primary boot loader 530 containing instructions to start the operating system kernel of the remote physical device 290. The operating system kernel 540 is started, and then the software stack 550 is initiated. The software stack 550 includes a software data plane 552 and multiple software applications 554. After the software stack 550 is started, the remote physical device 290 initializes the hardware 560 (e.g., the hardware / programmable logic or FPGA circuitry of the RPD). After the hardware has been initialized (560), the remote physical device 290 is connected to the configured D-CMTS230 (570), and a precision timing protocol is established (580). FPGAs and other electronic circuits are generally referred to as processors in this specification. 【0018】 Referring to Figure 6, the soft reset 410 omits downloading the image file (.ITB), omits resetting the remote physical device, omits reading the entire image file (.ITB), omits executing the primary boot loader, and omits booting the operating system kernel. The soft reset 410 undergoes a somewhat time-consuming process, generally requiring 60 seconds, if service for the customer is not provided by the remote physical device 290. The soft reset 410 may include starting a software stack 650, which includes a software data plane 652 and multiple software applications 654. After starting the software stack 650, the remote physical device 290 initializes the hardware 660 (e.g., initializing the hardware / programmable logic or FPGA circuitry of the RPD). After the hardware is initialized (660), the remote physical device 290 connects to the configured D-CMTS 230 (670), and the precision timing protocol 680 remains established. 【0019】 In either a hard or soft reset, video services, data services, out-of-band data services, etc., are affected because the reset process erases all applications, including the software data plane. During the reset process, the remote physical device 290 re-establishes its connection with GCP ("General-Purpose Control Plane," the protocol used to configure the remote physical device) and L2TP (Layer 2 Tunneling Protocol) from scratch. Also, during the reset process of the remote physical device 290, the software data plane is restarted and reprogrammed. Furthermore, the FPGA data plane modulator is reprogrammed. 【0020】 When the remote physical device 290 is restarted as a result of either a hard or soft reset, processing of video content, data services, and out-of-band data will not resume until the configuration has been processed and the precision timing protocol has been established or maintained. Unfortunately, in the case of a hard reset, this process typically takes 4-5 minutes to complete. In most cases, the reset of the remote physical device, execution of the primary boot loader, download of image files (.ITB) files, and startup of the operating system kernel are unnecessary as those parts of the remote physical device 290 remain operational. In most cases, if an update is needed, only the software stack 650, which includes the software data plane 652 and multiple software applications 654, is modified. After the modification of the software stack 650, the remote physical device 290 initializes the hardware 660, connects to and configures the D-CMTS 230 (670), and establishes the precision timing protocol 680. 【0021】 Unfortunately, the hard reset process typically requires over 4 - 5 minutes to complete, and the soft reset process typically requires over 1 minute to complete, during which time the service for the customer is unavailable. The modified process is desirable to reduce the impact on currently active services from both the perspective of the remote physical device and the D-CMTS. To achieve a reduction in the unavailability of active services during the reset process, it is desirable to modify an image file downloaded to the remote physical device 290 and containing a plurality of different parts therein. Referring to FIG. 7, the software image may be in the form of an image tree blob (.ITB) file format. The software image 700 may include an FPGA image 710 (e.g., bitstream, configuration data), a primary bootloader 720 (e.g., Uboot), a kernel 730 (e.g., Linux (registered trademark)), a software data plane 740, and / or a software application 750. In this way, the software image may include selected parts of the entire system to update the remote physical device 290. While it is beneficial to provide selected parts of the entire system for the remote physical device 290, also, the software image 700 includes those parts of the image files such as the FPGA image 710, the primary bootloader 720, the kernel 730, the software data plane 740, and / or the software application 750, including a part modified from a previous over software image provided to the remote physical device 290 (in the case of the overall configuration, multiple software images are included in the multiple software images). 【0022】 Referring to Figure 8, when packaging a software image 700 for a remote physical device 290, a comparison 800 is performed to identify parts that differ from one or more previous image files installed on the remote physical device 290. For example, the comparison 800 may identify whether the kernel 810 has been modified, whether the FPGA has been modified (812), whether any of the software applications have been modified (814), whether any particular software application has been modified (816), and any modified portion 818 of any particular software application. Furthermore, the comparison 800 may further identify the type of reset that would be appropriate based on the modification, such as a hard reset 830, a soft reset 832, a software data plane reset 834, a software data plane and software application reset 836, a specific software application 838 for the software data plane reset, and a specific software application 840 for the software data plane and software application reset. The image packaging may include one or more flags 850 to be included in the package to indicate how the image should be installed. In the case of a Linux® distribution, the image file is all or part of the root file system. Note that image files may include sub-image files contained within them. A reset may be, for example, a reset of the entire device. A reset may be, for example, a reset of all software applications running on the FPGA. A reset may be, for example, a reset of a selected set of one or more software applications running on the FPGA. A reset may be, for example, a reset of one of the software applications running on the FPGA, which does not affect the services provided to the user. In this way, only selected parts of the system may be dynamically updated based on flags. Furthermore, the type of reset process that occurs may be based on properties that are changed or otherwise indicated based on flags.It should be understood that the flag may be a single bit, string, set of bits, or any other type of indicator. During the comparison of ITB files, the system may use the MD5 hash value to determine which sub-images have changed, and it is further noted that the MD5 hash value can be calculated during the build time. 【0023】 As described above, to reduce the impact on the service, if there is an error in the data plane, it is determined that the software data plane needs to be updated (if necessary) and restarted in an effective way. If there is an error in the software application, one or more of the software applications need to be updated (if necessary) and restarted in an effective way. 【0024】 The soft reset process, hard reset process, and / or any modified reset process may be started in any suitable way. For example, the start may be via a remote physical device in case of failures such as a command line interface, commands from a D-CMTS and / or software crash, watchdog timeout, software upgrade, etc. 【0025】 As described above, the process by which the image file is built can include the ability to perform comparisons and can be modified to include a flag therein. The remote physical device analyzes the image file, determines an appropriate way to load a portion of the image file based on the flag, and install them on the remote physical device. 【0026】 Note that the process by which the image file is flagged or otherwise a change is identified within the image file can be used by other applications, excluding the remote physical device and excluding the cable networking environment. 【0027】 Furthermore, each functional block or various feature in each of the embodiments described above may be implemented or executed by a circuit, typically an integrated circuit or a combination of integrated circuits. Circuits designed to perform the functions described herein may include general-purpose processors, digital signal processors (DSPs), application-specific or general-purpose integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gates or transistor logic, or discrete hardware components, or combinations thereof. A general-purpose processor may be a microprocessor, or alternatively, a processor may be a conventional processor, controller, microcontroller, or state machine. The general-purpose processors or circuits described above may be composed of digital circuits or analog circuits. Furthermore, as advances in semiconductor technology lead to the emergence of technologies that replace multiple integrated circuits currently in use, integrated circuits using these technologies may also be used. 【0028】 The present invention is not limited to the specific embodiments described, and it will be understood that modifications may be made therein so as to be interpreted in accordance with the principle of superiority law, including equivalent doctrines or any other principle that expands the enforceable scope of 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 claim reference to the number of instances of an element, whether it is a reference to one instance or multiple instances, requires at least the number of instances of that element described, but is not intended to exclude the scope, structure or method of a claim having more instances of that element than described. The term “comprise” or its derivatives used in the claims is used in a non-exclusive sense and is not intended to exclude the presence of other elements or steps in the claimed structure or method.

Claims

[Claim 1] A cable distribution system including a headend connected to a plurality of customer devices via a transmission network including a remote fiber node including a processor that converts digital data into analog data suitable for a plurality of customer devices, (a) The remote fiber node receives an image file which includes at least one of kernel software, hardware configuration data, and application software. (b) The remote fiber node analyzes the image file and determines a portion of the image file that has been modified from what is currently contained on the remote fiber node, as indicated by at least one flag; (c) A cable distribution system comprising the steps of: installing at least a portion of the image file on the remote fiber node; and resetting the portion of the remote fiber node based on at least one flag. [Claim 2] The cable distribution system according to claim 1, further comprising the remote fiber node for resetting a software application within the control plane. [Claim 3] The cable distribution system according to claim 2, further comprising modifying at least one of the software applications as a result of resetting the remote fiber node. [Claim 4] The cable distribution system according to claim 1, further comprising correcting the software data plane as a result of resetting the remote fiber node. [Claim 5] The cable distribution system according to claim 1, further comprising the remote fiber node for resetting software applications in the software plane. [Claim 6] The cable distribution system according to claim 1, further comprising a hard reset of the remote fiber node. [Claim 7] The cable distribution system according to claim 1, further comprising a soft reset of the remote fiber node. [Claim 8] The cable distribution system according to claim 1, wherein the image file includes kernel software. [Claim 9] The cable distribution system according to claim 1, wherein the image file includes hardware configuration data. [Claim 10] The cable distribution system according to claim 1, wherein the image file includes application software. [Claim 11] A method for updating a remote fiber node in a cable distribution system, which includes a headend connected to a plurality of customer devices via a transmission network including a remote fiber node that converts digital data into analog data suitable for a plurality of customer devices, the headend being connected to the plurality of customer devices via a transmission network including a remote fiber node that includes a processor for converting digital data into analog data suitable for a plurality of customer devices, (a) The remote fiber node receives an image file which includes at least one of kernel software, hardware configuration data, and application software. (b) The remote fiber node analyzes the image file and determines a portion of the image file that has been modified from what is currently contained on the remote fiber node, as indicated by at least one flag; (c) A method comprising the steps of installing at least a portion of the image file on the remote fiber node and resetting a portion of the remote fiber node based on at least one flag. [Claim 12] The remote fiber node resets the software application within the control plane. The method according to claim 11, further comprising: [Claim 13] The method according to claim 12, further comprising modifying at least one of the software applications as a result of resetting the remote fiber node. [Claim 14] The method according to claim 11, further comprising correcting the software data plane as a result of resetting the remote fiber node. [Claim 15] The method according to claim 11, further comprising the remote fiber node for resetting a software application in the software plane. [Claim 16] The method according to claim 11, further comprising a hard reset of the remote fiber node. [Claim 17] The method according to claim 11, further comprising a soft reset of the remote fiber node. [Claim 18] The method according to claim 11, wherein the image file includes kernel software. [Claim 19] The method according to claim 11, wherein the image file includes hardware configuration data. [Claim 20] The method according to claim 11, wherein the image file includes application software.