Method and system for implementing autonomous and rapid upgrade of HGU in passive optical network

Abstract

The application relates to the technical field of passive optical network terminal upgrading, and discloses an implementation method and system for autonomous and rapid upgrading of an HGU in a passive optical network. The method comprises the following steps: after the HGU completes OLT registration, the HGU builds an independent upgrading channel and obtains an IP based on IPHOST configuration, initiatively connects a version management server to complete version comparison, and starts an image downloading process when it is determined that there is a higher version; the HGU joins a multicast to receive pre-split upgrading image data, checks the data integrity after the transmission is completed, and selects full multicast retransmission or unicast directional block supplementing according to the proportion of missing data to complete image acquisition; and the HGU writes the image into a local storage medium after checking that the image is complete and correct, restarts the equipment, loads a new version, and completes terminal upgrading. The application can improve the execution efficiency of HGU batch upgrading without additionally deploying a special management platform.

Description

Technical Field

[0001] This application relates to the technical field of passive optical network terminal upgrades, and in particular to a method and system for implementing autonomous and rapid upgrades of HGUs in passive optical networks. Background Technology

[0002] In passive optical network (PON) systems, HGU (Hyper-Gate Unit) optical network units serve as gateway access devices for home users, and remote software upgrades are a core aspect of optical network operation and maintenance management. Currently, HGU upgrades in the industry primarily rely on two technical approaches: one is through the TR69 network management platform for device management and version push, and the other is through the Optical Line Terminal (OLT) directly sending upgrade data to the registered HGU. These two methods correspond to different network deployment scales and operation and maintenance architectures.

[0003] Upgrade solutions using the TR69 network management platform require the independent deployment of a dedicated management system, resulting in high construction and maintenance costs and making them unsuitable for the lightweight maintenance needs of small and medium-sized passive optical networks. On the other hand, upgrade solutions using direct OLT control are limited by the transmission performance of the device management interface, resulting in limited data concurrency during batch upgrades and a long overall upgrade time. Therefore, improving the efficiency of HGU batch upgrades without deploying an additional dedicated management platform is a pressing technical problem that needs to be solved in this field. Summary of the Invention

[0004] To improve the efficiency of HGU batch upgrades without the need for additional dedicated management platforms, this application provides a method for autonomous and rapid HGU upgrades in passive optical networks.

[0005] Firstly, this application provides a method for achieving autonomous and rapid upgrades of HGUs in a passive optical network, employing the following technical solution: A method for implementing autonomous and rapid HGU upgrades in a passive optical network includes: After completing registration on the OLT, the HGU establishes an upgrade channel according to the IPHOST service configuration issued by the OLT and obtains an IP address through the upgrade channel. The HGU actively connects to the preset version control server, reads the target software version number and compares it with the version number of its own currently running software. When the target software version number is higher than the currently running software version number, the upgrade process is started. The HGU accesses the upgrade multicast data stream and receives upgrade image block data sent by the version control server in multicast mode. After the multicast data transmission is completed, the HGU verifies the integrity of the local upgrade image. When the amount of missing data exceeds a preset ratio, it sends a full transmission request to the version control server and re-receives the complete upgrade image data in multicast mode. When the amount of missing data does not exceed the preset ratio, it reports the missing data block information to the version control server and receives the corresponding data block sent by the version control server in unicast mode. After the upgrade image data is complete, HGU writes the complete upgrade image to the local storage medium to complete the version upgrade.

[0006] Optionally, the steps of establishing an upgrade channel and connecting to the version control server in HGU include: The OLT configures a dedicated VLAN for the HGU as an upgrade channel through the IPHOST function. DHCP service is deployed within the upgrade channel, and the HGU obtains a dynamic IP address for the upgrade network segment through the DHCP service. The version control server is addressed by a reserved fixed IP address within the upgrade network segment or by a public domain name. HGU actively initiates a connection to the version control server based on the pre-configured addressing information.

[0007] Optionally, the step of reading the target software version number and performing version comparison in HGU includes: The version control server stores independent upgrade image files and version number files in a designated storage directory. HGU first downloads the version number file and reads the target software version number. After completing the version comparison, it determines whether to start the download process of the upgrade image. When the target software version number is not higher than the currently running software version number, the current version check ends and waits for the next check cycle.

[0008] Optionally, the step of the HGU receiving upgrade mirror chunk data in multicast format includes: The version control server pre-splits the complete upgrade image into several data blocks of equal length and sends them sequentially in the order of the data blocks via multicast. The version control server continuously monitors for new upgrade requests during each round of multicast transmission. After all data blocks in the current round have been sent, if a new upgrade request is detected, a new round of full multicast transmission is initiated. If no new upgrade request is detected, the current multicast transmission is stopped.

[0009] Optionally, the steps of HGU reporting missing data block information and receiving unicast data include: HGU counts all missing data block numbers locally and reports the data block number information to the version control server; After receiving the reported information, the version control server extracts the corresponding data block from the pre-split upgrade image according to the data block number and sends it to the HGU that initiated the request via unicast. All resent data blocks are the same length as the data blocks sent via multicast, and the resentment process does not require secondary splitting of the upgrade image.

[0010] Optionally, the step of transmitting upgrade data through the upgrade channel includes: All upgrade data within the upgrade channel is transmitted using IP data packets and does not rely on the OMCI management protocol channel; OLT only performs pass-through processing of IP data within the upgrade channel, does not parse the upgrade data content, and does not participate in the control and scheduling of the upgrade process; Multiple HGUs can receive upgrade data in parallel through the upgrade channel, and the upgrade concurrency is not limited by the upgrade management capabilities of the OLT device.

[0011] Optionally, the step of the HGU receiving the corresponding data block sent in unicast mode includes: After receiving all the resent data blocks, HGU verifies the integrity of the local upgrade image again; If there are still missing data blocks and the amount of missing data does not exceed the preset ratio, the HGU will report the number of the currently missing data block again and continue to receive the retransmitted data via unicast. If the amount of missing data exceeds a preset proportion after multiple unicast retransmissions, HGU will stop unicast retransmission requests and instead send a full transmission request to the version control server to re-receive the complete upgrade image data via multicast.

[0012] Optionally, the step of initiating multicast transmission by the version control server includes: After receiving a multicast retransmission request from HGU, the version control server does not trigger a multicast transmission for a single request, but instead aggregates all multicast retransmission requests within the current time period. Once all current multicast rounds have been completed, the version control server will initiate a new round of full multicast transmission based on the aggregated requests, thus completing data coverage for all requesting devices.

[0013] Optionally, the steps of initiating a new round of full multicast transmission on the version control server include: After each round of full multicast transmission is completed, the version control server counts the total number of upgrade requests and retransmission requests received in the current round period. If no new requests are received in multiple rounds of multicast transmission, the version control server stops sending multicast data, only retains a listening state for upgrade requests and retransmission requests, and restarts multicast transmission when a new request is received.

[0014] Secondly, this application provides a system for realizing autonomous and rapid upgrades of HGUs in a passive optical network, which adopts the following technical solution: A system for enabling autonomous and rapid upgrades of HGUs in a passive optical network includes: The pre-configured version detection module allows the HGU to establish an upgrade channel based on the IPHOST service configuration issued by the OLT after completing registration on the OLT. The HGU obtains an IP address through the upgrade channel. The HGU actively connects to the preset version control server, reads the target software version number and compares it with the version number of its own currently running software. When the target software version number is higher than the currently running software version number, the upgrade process is started. The block-based hierarchical data acquisition module allows the HGU to access the upgrade multicast data stream and receive upgrade image block data sent by the version control server in multicast mode. After the multicast data transmission is completed, the HGU verifies the integrity of the local upgrade image. When the amount of missing data exceeds a preset ratio, it sends a full transmission request to the version control server and re-receives the complete upgrade image data in multicast mode. When the amount of missing data does not exceed the preset ratio, it reports the missing data block information to the version control server and receives the corresponding data block sent by the version control server in unicast mode. The image solidification upgrade module allows HGU to write the complete upgrade image to local storage media after the upgrade image data is complete, thus completing the version upgrade.

[0015] In summary, this application includes at least one of the following beneficial technical effects: By building an independent upgrade transmission channel using the OLT's built-in IPHOST capability, there is no need to deploy a dedicated TR69 management platform throughout the process, saving the costs associated with building and maintaining such a platform. At the same time, upgrade images are transmitted without the OMCI narrowband management channel, and upgrade data is carried by IP data packets. This frees the OLT from the constraints of its control capabilities on the number of concurrent upgrades, allowing multiple HGUs to simultaneously access the upgrade link to perform version detection and image downloads, significantly increasing the concurrency limit for batch upgrades at the transmission link level.

[0016] Furthermore, by adopting a transmission mode that combines multicast image distribution with precise unicast patching, the version control server can cover all HGUs to be upgraded within the network in one round of multicast. Only devices with a small number of packet losses are targeted to resend missing data segments, without the need to retransmit the complete image. At the same time, the server centrally aggregates upgrade requests from multiple devices and then initiates multicast in a unified manner. When there are no new requests, multicast output is paused, reducing invalid bandwidth usage. These dual transmission optimization methods further shorten the overall batch upgrade time, enabling rapid upgrades under a lightweight architecture. Attached Figure Description

[0017] Figure 1This is a network structure for dynamic HGU service adaptation in an implementation method for autonomous and rapid HGU upgrade in a passive optical network, as illustrated in an exemplary embodiment.

[0018] Figure 2 This is a flowchart illustrating an implementation method for autonomous and rapid HGU upgrades in a passive optical network according to an exemplary embodiment.

[0019] Figure 3 This is a flowchart of steps S101 to S104 of an implementation method for autonomous and rapid HGU upgrade in a passive optical network according to an exemplary embodiment.

[0020] Figure 4 This is a flowchart of steps S201 to S205 of an implementation method for autonomous and rapid HGU upgrade in a passive optical network according to an exemplary embodiment.

[0021] Figure 5 This is a flowchart of steps S301 to S303 of an implementation method for autonomous and rapid HGU upgrade in a passive optical network according to an exemplary embodiment.

[0022] Figure 6 This is a structural block diagram illustrating an implementation system for autonomous and rapid HGU upgrades in a passive optical network, according to an exemplary embodiment. Detailed Implementation

[0023] The embodiments of this application are described in detail below, and examples of the embodiments are shown in the accompanying drawings.

[0024] In the description of this specification, the references to "certain embodiments," "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples" refer to specific features, structures, materials, or characteristics described in connection with the described embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0025] This application discloses a method for autonomous and rapid HGU upgrades in passive optical networks (PONs), primarily applicable to scenarios such as terminal version maintenance of small and medium-sized PONs, batch upgrades of campus optical networks, and lightweight network version management. In these scenarios, the deployment scale of PONs is limited, and the maintenance budget and personnel configuration are relatively streamlined. If the traditional TR69 management platform is used to upgrade HGUs, a dedicated platform system needs to be purchased and dedicated personnel need to maintain it, resulting in high deployment and usage costs. If the upgrade is directly managed by the OLT, the transmission performance and concurrent processing capabilities of the OMCI management channel are limited, resulting in a limited number of upgrade devices that a single OLT can support simultaneously during batch upgrades, leading to a long overall upgrade cycle and low execution efficiency.

[0026] Reference Figure 1 The HGU service dynamic adaptation network structure shown in this embodiment, the passive optical network system used in this example, mainly consists of an OLT, a 1:N optical splitter, multiple HGU-type optical network units, and a version control server. The OLT is deployed on the core network side, undertaking the aggregation and distribution functions of Layer 2 services, and is connected to the primary optical splitter via fiber optic links. The optical splitter adopts a passive splitting architecture, dividing one optical signal into multiple paths, each connected to HGUs in different locations, forming a point-to-multipoint optical access network. The HGU, as a home gateway unit facing the user side, is responsible for user-side service access and data forwarding, and carries the software version and configuration data required for operation. The version control server is deployed on the WAN side network and is connected to the OLT via an IP network. In the entire upgrade system, the OLT does not need to undertake upgrade control or data scheduling functions; it only needs to configure an independent upgrade transmission channel for the connected HGUs through its general IPHOST function to support HGUs in autonomously accessing the version control server and completing the entire process from version detection to upgrade execution, without the need for additional dedicated terminal management platforms.

[0027] This application discloses a method for implementing autonomous and rapid HGU upgrades in a passive optical network, referring to... Figure 2 The following section details this solution with specific implementation steps: After completing registration on the OLT, the S100 HGU establishes an upgrade channel according to the IPHOST service configuration issued by the OLT and obtains an IP address through the upgrade channel. The HGU actively connects to the preset version control server, reads the target software version number and compares it with the version number of its own currently running software. When the target software version number is higher than the currently running software version number, the upgrade process is started.

[0028] In this embodiment of the invention, reference is made to Figure 3 The specific execution process of S100 is as follows: After the S101 HGU is powered on, it executes the optical network registration process, receives the IPHOST service configuration issued by the OLT, and establishes a dedicated upgrade channel.

[0029] After the HGU powers on and completes system initialization, it sends a registration request to the OLT. The OLT then completes device authentication and resource allocation, and sends pre-configured IPHOST service parameters to the HGU. Based on the received service parameters, the HGU configures the corresponding VLAN interface locally, building a dedicated upgrade channel isolated from the service channel. Data forwarding within this upgrade channel is independent of regular user service channels such as internet access and voice calls, ensuring that upgrade data transmission does not interfere with normal user services. This upgrade channel relies on the OLT's natively supported IPHOST function, requiring no hardware modifications or functional upgrades to the OLT. General-purpose OLTs can support this configuration, making it compatible with most deployed passive optical network scenarios at extremely low cost.

[0030] S102, the address allocation service is deployed within the upgrade channel. After the HGU obtains the network segment IP address, it connects to the version control server based on the preset addressing information.

[0031] The upgrade VLAN channel deploys a DHCP service and pre-plans a dedicated upgrade address pool. This pool reserves fixed IP addresses as dedicated access addresses for the version control server, while the remaining addresses are dynamically assigned to connected HGU devices. After configuring the upgrade channel's interfaces, the HGU sends an address request to the DHCP server within the channel to obtain a dynamic IP address within the upgrade network segment, thus establishing the network foundation for IP communication with the version control server. In scenarios with a small network size and fixed server nodes, the HGU can directly address and connect to the version control server based on the pre-written fixed IP address in its firmware, making configuration simple and straightforward. In scenarios with many network nodes and where servers require flexible expansion and migration, a public domain name can be used for server addressing. The HGU obtains the actual access address of the version control server through domain name resolution, eliminating the need to permanently store server address information on the terminal side, thus adapting to a more flexible network deployment architecture.

[0032] S103, HGU downloads a separate version number file from the version control server, reads the target software version number and compares it with the locally running version.

[0033] In the designated storage directory of the version control server, there are two independent files: an upgrade image file and a version number file. The upgrade image file contains the complete software firmware required for HGU operation and has a large data volume. The version number file is a lightweight text file that only records the version number of the target software to be released. Its data volume is extremely small, and the download time is negligible. The two files correspond one-to-one. When maintenance personnel need to release a new version, they only need to replace both files in the directory to complete the version update configuration. The operation process is simple and convenient. After HGU establishes a connection with the version control server, it first downloads the smaller version number file, parses and reads the target software version number from the file, and then compares the target version number with the version number of its own currently running software to determine whether an upgrade operation is needed. Using an independent version number file for pre-comparison avoids downloading the complete large-capacity upgrade image when the device does not need to be upgraded, significantly reducing unnecessary bandwidth consumption. It also shortens the time of a single version check and supports performing periodic checks at a higher frequency, ensuring that the new version can be quickly recognized and deployed by the terminal.

[0034] S104 determines whether to initiate the upgrade process based on the version comparison results. If no upgrade is needed, it enters a periodic detection waiting state.

[0035] When the comparison determines that the target software version number is higher than the currently running software version number of the HGU, it is determined that the current device needs to perform a version iteration, and the subsequent upgrade image download and upgrade execution process is initiated. When the comparison determines that the target software version number is less than or equal to the currently running software version number, it means that the current device is already running the latest version and no upgrade operation is required. The HGU ends the version detection process and enters a waiting state. After the preset detection cycle is reached, the version detection operation is repeated. Through an automated periodic detection mechanism, there is no need for maintenance personnel to trigger upgrades on a machine-by-machine basis. All online HGUs can autonomously identify version updates and execute upgrades, achieving silent rollover of batch versions and significantly reducing the manpower required for upgrade maintenance.

[0036] S200, HGU accesses the upgrade multicast data stream and receives upgrade image block data sent by the version control server in multicast mode. After the multicast data transmission is completed, HGU verifies the integrity of the local upgrade image. When the amount of missing data exceeds a preset ratio, it sends a full transmission request to the version control server and re-receives the complete upgrade image data in multicast mode. When the amount of missing data does not exceed the preset ratio, it reports the missing data block information to the version control server and receives the corresponding data block sent by the version control server in unicast mode.

[0037] In this embodiment of the invention, reference is made to Figure 4 The specific execution process of S200 is as follows: S201, the HGU joins the upgrade multicast group and transmits upgrade data through the IP-based upgrade channel, while the OLT only performs data pass-through.

[0038] After the upgrade process is initiated, the HGU sends an upgrade request to the version control server and joins the corresponding upgrade multicast group, preparing to receive upgrade data in multicast format. The entire upgrade data transmission process uses IP data packets, independent of the OMCI management protocol channel. The OLT only performs Layer 2 pass-through processing on the IP data within the upgrade channel, without parsing the specific content of the upgrade data or participating in the management and scheduling of the upgrade process. Compared to the OMCI-encapsulated messages used in traditional OLT-controlled upgrades, IP data packets offer higher transmission efficiency and eliminate the overhead of additional management protocol encapsulation. Furthermore, upgrade concurrency is no longer limited by the OLT's management and processing power; multiple HGUs can receive upgrade data in parallel through the upgrade channel, and a single OLT can simultaneously support a large number of HGUs performing upgrade operations, completely breaking through the concurrency bottleneck of traditional OMCI upgrades and making it more suitable for batch upgrade application scenarios.

[0039] S202, the version control server pre-splits the upgrade image into equal-length data blocks, distributes them sequentially in a multicast manner, and schedules the transmission rounds.

[0040] Before initiating multicast distribution, the version control server pre-divides the complete upgrade image into several data blocks of equal length, assigning each data block a unique sequential number. The receiving end can reconstruct the complete image sequentially using these numbers, or quickly locate missing data segments. After splitting, the version control server sends all data blocks sequentially via multicast according to their numbers. All HGUs joined in the multicast group can receive data simultaneously, and a single round of multicast transmission can cover all online devices awaiting upgrade. Compared to unicast transmission per device, multicast distribution only requires sending one data stream to cover multiple receiving devices, significantly reducing server outbound bandwidth usage and shortening the overall transmission time for batch upgrades.

[0041] During each round of multicast transmission, the version control server continuously monitors for new HGU upgrade requests in the network. If a new HGU upgrade request is detected during the current round of transmission, the server will not immediately interrupt the current transmission and restart it. Instead, it will wait until all data blocks in the current round have been sent before initiating a new round of full multicast transmission to ensure that newly joined devices can receive complete upgrade image data. If no new upgrade request is detected during the entire current round of transmission, the multicast transmission will be stopped after the current round of data transmission is completed to avoid meaningless repeated transmissions that continuously consume bandwidth resources.

[0042] S203 After the multicast transmission ends, the HGU verifies the data integrity and determines the corresponding retransmission method based on the proportion of missing data.

[0043] After the multicast transmission ends, the HGU counts the number of missing data blocks based on the locally received data block numbers, calculates the proportion of missing data to the total data volume of the upgrade image, and compares it with a preset proportion threshold. When the missing data exceeds the preset proportion, it indicates that the integrity of the locally received data is low, usually caused by device restarts or prolonged network fluctuations. In this case, if unicast block-by-block retransmission is used, the amount of data to be retransmitted is large, and the retransmission process is time-consuming. The HGU sends a full transmission request to the version control server, waiting for the server to initiate a new round of multicast transmission to re-receive the complete upgrade image data. When the missing data does not exceed the preset proportion, it indicates that only a small number of data blocks are lost, usually caused by network jitter or occasional packet loss. In this case, unicast retransmission is more efficient in supplementing the missing data, without waiting for a new round of multicast transmission. Through the hierarchical retransmission strategy, the optimal retransmission method can be flexibly selected according to the actual packet loss level, balancing transmission efficiency and bandwidth resource utilization, and adapting to optical network environments of different qualities.

[0044] S204, HGU reports the missing data block number, receives the targeted retransmission data via unicast and performs secondary verification.

[0045] After determining that unicast packet replacement is the preferred method, the HGU (Upgrade Image Unit) counts all missing data block numbers locally, packages all missing number information, and reports it to the version control server. Upon receiving the reported missing number information, the version control server directly extracts the corresponding numbered data block from the pre-splitting image data blocks and sends it via unicast to the requesting HGU. Since the upgrade image has already been pre-splitting into unified blocks, there is no need for secondary splitting during the replacement process; the server only needs to extract the corresponding data block based on the number, resulting in extremely low processing overhead. Furthermore, all replacement data blocks are of the same length as the multicast data blocks, allowing the HGU to directly fill in the corresponding positions according to the number without additional format conversion or splicing, thus improving packet replacement efficiency.

[0046] After receiving all the retransmitted data blocks, the HGU re-verifies the completeness of the local upgrade image to confirm whether any missing data blocks still exist. If missing data blocks still exist, and the amount of missing data does not exceed a preset proportion, the HGU reports the number of the currently missing data block again and continues to receive retransmitted data via unicast. This process of retransmitting packets gradually completes the image data until it is complete. If, after multiple unicast retransmissions, the amount of missing data still exceeds the preset proportion, it indicates that packet loss in the current network environment is severe, and continuous unicast retransmission is inefficient, potentially leading to a loop of repeated retransmissions. In this case, the HGU proactively stops unicast retransmission requests and instead sends a full transmission request to the version control server, re-receiving the complete upgrade image data via multicast. This retransmission mechanism, with its dual verification and dynamic switching, saves bandwidth and time in scenarios with minimal packet loss through precise unicast retransmission, while automatically switching to full multicast retransmission in scenarios with severe packet loss to ensure upgrade success rates. It is adaptable to network environments with varying stability levels.

[0047] S205, the version control server aggregates multicast retransmission requests and schedules the start and stop status of multicast rounds as needed.

[0048] For multicast retransmission requests sent by HGUs, the version control server employs a consolidated scheduling logic. Upon receiving a multicast retransmission request from a single HGU, the server does not immediately trigger a round of multicast transmission for that individual request. Instead, it consolidates and statistically analyzes all multicast retransmission requests received within the current time period, recording the device information for each request. Once all currently ongoing multicast rounds have been completed, the server initiates a new round of full multicast transmission based on the consolidated retransmission requests, covering all devices requesting retransmission in a single round. This consolidated scheduling approach avoids transmission fragmentation caused by frequent multicast rounds triggered by scattered requests, reduces the scheduling overhead of multicast startup and termination, improves the effective utilization of multicast bandwidth, and reduces the server's scheduling processing pressure.

[0049] After each round of full multicast transmission, the version control server counts the total number of upgrade and retransmission requests received within the current cycle to determine if any devices in the network still require upgrades. If no new upgrade or retransmission requests are received for several consecutive rounds of multicast transmission, it indicates that all devices in the network awaiting upgrade have received mirrored data and no longer require multicast data streams. At this point, the version control server stops sending multicast data, only maintaining a listening state for upgrade and retransmission requests. When a new HGU comes online and sends an upgrade request, the server restarts the multicast transmission process. This on-demand multicast scheduling mechanism automatically releases multicast bandwidth resources when there is no upgrade requirement, reducing the server's operating load. It is particularly suitable for the operation and maintenance scenarios of non-continuous, batch upgrades in small and medium-sized networks, avoiding long-term bandwidth waste caused by fixed-cycle cyclic multicast.

[0050] After the S300 and HGU confirm that the upgrade image data is complete, they will write the complete upgrade image to the local storage medium to complete the version upgrade.

[0051] In this embodiment of the invention, reference is made to Figure 5 The specific execution process of S300 is as follows: S301, HGU performs a validity and integrity check on the complete upgrade image to confirm that the image is usable.

[0052] After confirming that all local data blocks have been received, the HGU first performs a validity check on the assembled complete upgrade image. This check includes verifying the image file's checksum, device model compatibility identifier, and version identifier to ensure the image data has not been tampered with and is compatible with the current HGU's hardware model and version, preventing erroneous image writing that could cause device boot failure. After the validity check passes, the HGU then performs an integrity check on the complete image to confirm that all data blocks are correctly assembled without data loss or misalignment, ensuring the accuracy of the image data before writing. This dual-check mechanism mitigates the risk of device failure due to erroneous upgrades at the source, improving the reliability of the upgrade operation.

[0053] S302, HGU writes the verified upgrade image into blocks to the local storage medium, verifying the accuracy of the write block by block.

[0054] After successful verification, HGU writes the complete upgrade image to local non-volatile storage media. The writing process employs a block-by-block verification method. After each data block is written, the written data is immediately read and verified to ensure consistency with the source data before continuing to write the next data block, thus preventing data errors during the writing process. This block-by-block verification method allows for timely detection of anomalies during the writing process, avoiding rework caused by discovering errors only after the entire package has been written, and improving the fault tolerance of the writing process and the accuracy of the final data.

[0055] S303, HGU performs device reboot, loads the new software version and completes the version upgrade to take effect.

[0056] After the image is written and verified to be correct, the HGU executes the system restart process. During the restart, the new version of the software image is loaded, completing the version switch and update. After the device restarts, the HGU re-executes the optical network registration process, connects to the passive optical network, and starts operating services normally. After the upgrade, the HGU will compare the new version number as the current running version during subsequent periodic version checks. If the server-side version number has not been updated, the upgrade process will not be triggered again. The entire upgrade process requires no manual intervention; the HGU autonomously completes the entire process from detection to upgrade, achieving unattended automated version iteration.

[0057] Based on the embodiments of this application, the following scenario illustrates the solution: In the operation and maintenance scenario of a small-to-medium-sized passive optical network in a county, the local operator is responsible for the operation and maintenance of the optical network in the townships under its jurisdiction. Hundreds of HGU-type optical network units are deployed within the network. Due to limitations in operation and maintenance costs and personnel configuration, a dedicated TR69 management platform has not been purchased and deployed in this area. Previously, HGU version updates relied on maintenance personnel going to each township to perform on-site operations, which not only involved significant manpower and high travel costs, but also took several days to complete a version update across the entire area, resulting in extremely low version iteration efficiency and difficulty in quickly responding to security vulnerability fixes and feature updates. With this solution, only the existing IPHOST function of the existing OLT equipment is utilized, a dedicated upgrade VLAN channel is configured, and a general-purpose server is deployed in the central computer room as a version control server. There is no need to purchase an additional dedicated management system or upgrade the OLT equipment. The upgrade system can be built simply through basic network configuration. The overall deployment cost is far lower than that of a dedicated management platform solution, significantly reducing the barrier to version control for small-to-medium-sized networks.

[0058] During batch version upgrades, maintenance personnel only need to upload the new version's image file and the corresponding version number file to the designated directory on the version control server. All online HGUs will automatically identify the new version during periodic checks and autonomously initiate the upgrade process. The version control server distributes the upgrade image via multicast, allowing all online HGUs to receive upgrade data simultaneously. No unicast transmission is required for each device; a single multicast round can cover all devices in the area to be upgraded. For devices experiencing minor packet loss due to fluctuations in rural line quality, the system automatically resends missing data blocks via unicast, eliminating the need for a full retransmission and completing the data replacement in a very short time. Throughout the upgrade process, the OLT only handles IP data transmission; the upgrade concurrency is not limited by the performance of the OLT management channel. Hundreds of HGUs in the area can simultaneously complete version updates, resulting in a significant reduction in overall upgrade time compared to traditional on-site upgrade methods.

[0059] After the solution was implemented, HGU version updates in the region became automated and unattended, requiring no on-site operation by maintenance personnel or dedicated maintenance of a management platform. Only server-side files needed to be updated when a new version was released. Without incurring additional costs for a dedicated management platform, this solution reduced manpower and time costs associated with upgrade maintenance, significantly improved the efficiency and speed of batch upgrades, and enabled rapid response to version iteration and vulnerability patching needs. It is fully compatible with the lightweight maintenance requirements of small and medium-sized passive optical networks, providing a low-cost, high-efficiency solution for terminal version management in such networks.

[0060] This application discloses a system for implementing autonomous and rapid HGU upgrades in a passive optical network, referring to... Figure 6 ,include: The pre-configured version detection module allows the HGU to establish an upgrade channel based on the IPHOST service configuration issued by the OLT after completing registration on the OLT. The HGU obtains an IP address through the upgrade channel. The HGU actively connects to the preset version control server, reads the target software version number and compares it with the version number of its own currently running software. When the target software version number is higher than the currently running software version number, the upgrade process is started. The block-based hierarchical data acquisition module allows the HGU to access the upgrade multicast data stream and receive upgrade image block data sent by the version control server in multicast mode. After the multicast data transmission is completed, the HGU verifies the integrity of the local upgrade image. When the amount of missing data exceeds a preset ratio, it sends a full transmission request to the version control server and re-receives the complete upgrade image data in multicast mode. When the amount of missing data does not exceed the preset ratio, it reports the missing data block information to the version control server and receives the corresponding data block sent by the version control server in unicast mode. The image solidification upgrade module allows HGU to write the complete upgrade image to local storage media after the upgrade image data is complete, thus completing the version upgrade.

[0061] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for implementing autonomous and rapid upgrades of HGUs in a passive optical network, characterized in that, include: After HGU completes registration on OLT, it establishes an upgrade channel according to the IPHOST service configuration issued by OLT and obtains an IP address through the upgrade channel; HGU actively connects to the preset version control server, reads the target software version number and compares it with the version number of its own currently running software. When the target software version number is higher than the currently running software version number, the upgrade process is started. The HGU accesses the upgrade multicast data stream and receives upgrade image block data sent by the version control server in multicast mode. After the multicast data transmission is completed, the HGU verifies the integrity of the local upgrade image. When the amount of missing data exceeds a preset ratio, it sends a full transmission request to the version control server and re-receives the complete upgrade image data in multicast mode. When the amount of missing data does not exceed the preset ratio, it reports the missing data block information to the version control server and receives the corresponding data block sent by the version control server in unicast mode. After the upgrade image data is complete, HGU writes the complete upgrade image to the local storage medium to complete the version upgrade.

2. The method for implementing autonomous and rapid HGU upgrade in a passive optical network according to claim 1, characterized in that, The steps involved in establishing an upgrade channel and connecting to the version control server in HGU include: The OLT configures a dedicated VLAN for the HGU as an upgrade channel through the IPHOST function. DHCP service is deployed within the upgrade channel, and the HGU obtains a dynamic IP address for the upgrade network segment through the DHCP service. The version control server is addressed by a reserved fixed IP address within the upgrade network segment or by a public domain name. HGU actively initiates a connection to the version control server based on the pre-configured addressing information.

3. The method for implementing autonomous and rapid HGU upgrades in a passive optical network according to claim 1, characterized in that, The steps of HGU reading the target software version number and performing version comparison include: The version control server stores independent upgrade image files and version number files in a designated storage directory. HGU first downloads the version number file and reads the target software version number. After completing the version comparison, it determines whether to start the download process of the upgrade image. When the target software version number is not higher than the currently running software version number, the current version check ends and waits for the next check cycle.

4. The method for implementing autonomous and rapid HGU upgrades in a passive optical network according to claim 1, characterized in that, The steps for HGU to receive upgrade image chunk data in multicast format include: The version control server pre-splits the complete upgrade image into several data blocks of equal length and sends them sequentially in the order of the data blocks via multicast. The version control server continuously monitors for new upgrade requests during each round of multicast transmission. After all data blocks in the current round have been sent, if a new upgrade request is detected, a new round of full multicast transmission is initiated. If no new upgrade request is detected, the current multicast transmission is stopped.

5. The method for implementing autonomous and rapid HGU upgrades in a passive optical network according to claim 1, characterized in that, The steps of HGU reporting missing data block information and receiving unicast data include: HGU counts all missing data block numbers locally and reports the data block number information to the version control server; After receiving the reported information, the version control server extracts the corresponding data block from the pre-split upgrade image according to the data block number and sends it to the HGU that initiated the request via unicast. All resent data blocks are the same length as the data blocks sent via multicast, and the resentment process does not require secondary splitting of the upgrade image.

6. The method for implementing autonomous and rapid HGU upgrades in a passive optical network according to claim 2, characterized in that, The steps of transmitting upgrade data through the upgrade channel include: All upgrade data within the upgrade channel is transmitted using IP data packets and does not rely on the OMCI management protocol channel; OLT only performs pass-through processing of IP data within the upgrade channel, does not parse the upgrade data content, and does not participate in the control and scheduling of the upgrade process; Multiple HGUs can receive upgrade data in parallel through the upgrade channel, and the upgrade concurrency is not limited by the upgrade management capabilities of the OLT device.

7. The method for implementing autonomous and rapid HGU upgrades in a passive optical network according to claim 5, characterized in that, The steps for HGU to receive the corresponding data block sent via unicast include: After receiving all the resent data blocks, HGU verifies the integrity of the local upgrade image again; If there are still missing data blocks and the amount of missing data does not exceed the preset ratio, the HGU will report the number of the currently missing data block again and continue to receive the retransmitted data via unicast. If the amount of missing data exceeds a preset proportion after multiple unicast retransmissions, HGU will stop unicast retransmission requests and instead send a full transmission request to the version control server to re-receive the complete upgrade image data via multicast.

8. The method for implementing autonomous and rapid HGU upgrade in a passive optical network according to claim 4, characterized in that, The steps involved in initiating a multicast transmission from the version control server include: After receiving a multicast retransmission request from HGU, the version control server does not trigger a multicast transmission for a single request, but instead aggregates all multicast retransmission requests within the current time period. Once all current multicast rounds have been completed, the version control server will initiate a new round of full multicast transmission based on the aggregated requests, thus completing data coverage for all requesting devices.

9. The method for implementing autonomous and rapid HGU upgrades in a passive optical network according to claim 8, characterized in that, The steps involved in initiating a new round of full multicast transmission on the version control server include: After each round of full multicast transmission is completed, the version control server counts the total number of upgrade requests and retransmission requests received in the current round period. If no new requests are received in multiple rounds of multicast transmission, the version control server stops sending multicast data, only retains a listening state for upgrade requests and retransmission requests, and restarts multicast transmission when a new request is received.

10. A system for implementing autonomous and rapid upgrades of HGUs in a passive optical network, characterized in that, include: The pre-configured version detection module allows the HGU to establish an upgrade channel based on the IPHOST service configuration issued by the OLT after completing registration on the OLT, and obtain the IP address through the upgrade channel. HGU actively connects to the preset version control server, reads the target software version number and compares it with the version number of its own currently running software. When the target software version number is higher than the currently running software version number, the upgrade process is started. The block-based hierarchical data acquisition module allows the HGU to access the upgrade multicast data stream and receive upgrade image block data sent by the version control server in multicast mode. After the multicast data transmission is completed, the HGU verifies the integrity of the local upgrade image. When the amount of missing data exceeds a preset ratio, it sends a full transmission request to the version control server and re-receives the complete upgrade image data in multicast mode. When the amount of missing data does not exceed the preset ratio, it reports the missing data block information to the version control server and receives the corresponding data block sent by the version control server in unicast mode. The image solidification upgrade module allows HGU to write the complete upgrade image to local storage media after the upgrade image data is complete, thus completing the version upgrade.

Images