Diskless starting method and system in FTTR virtual domain

Abstract

The invention provides a diskless starting method and system in an FTTR virtual domain, and belongs to the technical field of network communication, and the method comprises the steps: receiving at least one software firmware version loading request, and enabling each software firmware version loading request to be transmitted by a home gateway unit; determining the number of home gateway units sending the software firmware version loading requests; and based on the number, determining a sending mode of the software firmware version, and sending the software firmware version to the home gateway unit based on the sending mode, so that the home gateway unit completes starting according to the software firmware version. According to the invention, the number of the loading requests of the home gateway unit is received and counted through the virtual home gateway unit, a multicast or unicast mode is flexibly selected to distribute software firmware versions, and efficient diskless startup is realized, so that the number and the capacity of a nonvolatile memory are reduced.

Description

Technical Field

[0001] The present invention relates to the field of network communication technology, and in particular to a diskless boot method and system in a FTTR virtual domain. Background Art

[0002] With the growing demand for high-speed Internet access in modern households, fiber-to-the-room (FTTR) technology has emerged as an ideal solution for providing high-bandwidth, low-latency network services. In an FTTR network, an optical link terminal (OLT) connects multiple home gateway units (HGUs) via optical fiber to achieve high-speed network coverage throughout the house.

[0003] In the traditional FTTR network architecture, each HGU needs to be equipped with non-volatile memory (such as flash memory) to store the device's bootloader, configuration data, and complete software and firmware versions. With the development of technology, the functions of HGU have become increasingly rich, and the size of its software and firmware versions has also continued to expand, from the initial 4MB to 8MB, 16MB, and even larger. This trend has led to the need for more and larger non-volatile memories to store the increasingly large software and firmware versions as the number of HGUs increases, resulting in more complex hardware design and increased hardware costs.

[0004] Therefore, as the number of home gateway units increases, how to reduce the number and capacity of non-volatile memories becomes a technical problem that needs to be solved urgently. Summary of the invention

[0005] The present invention provides a diskless boot method, system, electronic device and storage medium in a FTTR virtual domain, which are used to solve the defects in the prior art and reduce the number and capacity of non-volatile memories as the number of home gateway units increases.

[0006] The present invention provides a diskless boot method in a FTTR virtual domain, which is applied to a virtual home gateway unit. The virtual home gateway unit is used to maintain the MAC address information of all home gateway units in the virtual domain and save the software firmware versions of all home gateway units. The method comprises the following steps: Receiving at least one software firmware version loading request, each of the software firmware version loading request is sent by a home gateway unit; Determining the number of home gateway units that sent the software firmware version loading request; Based on the quantity, a sending method of the software firmware version is determined, and based on the sending method, the software firmware version is sent to the home gateway unit, so that the home gateway unit completes startup according to the software firmware version.

[0007] According to a diskless boot method in a FTTR virtual domain provided by the present invention, the method of sending the software firmware version is determined based on the quantity, and the software firmware version is sent to the home gateway unit based on the sending method, specifically comprising: When the number is greater than 1, create a multicast software firmware version task and obtain the task creation status; When the task is created successfully, the software firmware version is sent to the home gateway unit via multicast; When the task creation fails, or the number is less than 1, the software firmware version is sent to the home gateway unit via unicast.

[0008] According to a diskless boot method in a FTTR virtual domain provided by the present invention, sending the software firmware version to the home gateway unit by multicast specifically includes: Allocating a unique transaction identifier to the multicast software firmware version task; Sending a multicast response message to the virtual domain, the multicast response message including the transaction identifier and the MAC address information of each home gateway unit requested to be loaded, so that each home gateway unit requested to be loaded matches the transaction identifier corresponding to its own MAC address information from the virtual domain; The segmented software firmware version data containing the transaction identifier is sent to the virtual domain in sequence, so that each home gateway unit requesting to load matches the segmented software firmware version data corresponding to its own transaction identifier from the virtual domain; the segmented software firmware version data is to divide the complete software firmware version into multiple data segments according to a predetermined size or logic.

[0009] According to a diskless boot method in a FTTR virtual domain provided by the present invention, sending the software firmware version to the home gateway unit in a unicast manner specifically includes: Establishing a unicast communication connection with the home gateway unit; The software firmware version is sent to the home gateway unit via the unicast communication connection.

[0010] According to a diskless boot method in a FTTR virtual domain provided by the present invention, after sending the software firmware version to the home gateway unit in a multicast manner, the method further includes: Receiving loading completion confirmation information sent by the home gateway unit; The software loading status of the home gateway unit is updated based on the loading completion confirmation information.

[0011] According to a diskless boot method in a FTTR virtual domain provided by the present invention, the method further comprises: When creating a virtual domain, a unique domain identifier is assigned to the virtual domain; The domain identifier is added in the communication message with the home gateway unit.

[0012] The present invention also provides a diskless boot system in a FTTR virtual domain, comprising the following modules: A receiving module, configured to receive at least one software firmware version loading request, each of which is sent by a home gateway unit; A first processing module, used to determine the number of home gateway units that send the software firmware version loading request; The second processing module is used to determine the sending method of the software firmware version based on the quantity, and send the software firmware version to the home gateway unit based on the sending method, so that the home gateway unit completes startup according to the software firmware version.

[0013] The present invention also provides an electronic device, comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the diskless boot method within the FTTR virtual domain as described above is implemented.

[0014] The present invention also provides a non-transitory computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the diskless boot method in the FTTR virtual domain as described above is implemented.

[0015] The present invention also provides a computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the computer program implements any of the above-mentioned diskless boot methods within the FTTR virtual domain.

[0016] In summary, one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: By receiving at least one software firmware version loading request, the virtual home gateway unit can obtain the information of the home gateway unit that issues the startup demand in the current virtual domain, so as to perceive in real time which home gateway units need to load the software firmware version for startup. This solution ensures that the virtual home gateway unit can obtain the startup demand of the home gateway unit in time and prepare the subsequent loading process, avoiding the storage cost and management complexity caused by the home gateway units storing firmware separately. After receiving the loading request of the home gateway unit, the virtual home gateway unit can accurately count the total number of home gateway units with loading demand in the current virtual domain by determining the number of home gateway units that send the loading request, thereby laying the foundation for the subsequent selection of the appropriate loading method. This statistical method allows the virtual home gateway unit to flexibly respond to different loading scenarios, especially when multiple home gateway units request loading at the same time. By counting the number, the virtual home gateway unit can determine whether it is suitable to use multicast for firmware distribution, thereby improving transmission efficiency and effectively saving network bandwidth. Based on the number of home gateway units counted, the virtual home gateway unit can select the best sending method. When the number of requests is 1, the virtual home gateway unit uses unicast for loading, thereby ensuring that the needs of a single home gateway unit can be responded to in a timely manner without waiting for the creation or transmission conditions of multicast. When the number is greater than 1, the virtual home gateway unit will give priority to multicast mode to meet the loading needs of multiple home gateway units at one time, thereby avoiding repeated transmission of the same data stream, reducing network resource usage, and optimizing transmission efficiency, thereby reducing the number and capacity of non-volatile memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0018] Figure 1 This is one of the flow diagrams of the diskless boot method in the FTTR virtual domain provided by the present invention.

[0019] Figure 2 This is the second flow chart of the diskless boot method in the FTTR virtual domain provided by the present invention.

[0020] Figure 3 This is the third flow chart of the diskless boot method in the FTTR virtual domain provided by the present invention.

[0021] Figure 4 It is a structural schematic diagram of the diskless boot system in the FTTR virtual domain provided by the present invention.

[0022] Figure 5 It is a structural schematic diagram of the electronic device provided by the present invention. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the drawings of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0024] It should be noted that, in the description of the present invention, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "include one..." do not exclude the existence of other identical elements in the process, method, article or device including the elements. The orientation or positional relationship indicated by the terms "upper", "lower", etc. is based on the orientation or positional relationship shown in the accompanying drawings, and is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the system or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to the specific circumstances.

[0025] The terms "first", "second", etc. in the present invention are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present invention can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first", "second", etc. are generally of the same type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" means at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0026] Combine the following Figure 1-Figure 5 The present invention describes the diskless boot method, system, electronic device and storage medium in the FTTR virtual domain.

[0027] Figure 1 It is one of the flow charts of the diskless boot method in the FTTR virtual domain provided by the present invention, such as Figure 1As shown, it is applied to a virtual home gateway unit, and the virtual home gateway unit is used to maintain the MAC address information of all home gateway units in the virtual domain and save the software firmware versions of all home gateway units, including but not limited to the following steps: Step 1: Receive at least one software firmware version loading request, each software firmware version loading request is sent by a home gateway unit.

[0028] In the diskless boot method within the FTTR virtual domain of the present invention, the embodiment of step 1 specifically embodies how the virtual home gateway unit (VHGU) receives a software firmware version loading request from the home gateway unit (HGU).

[0029] When a HGU needs to reload the software firmware version due to power failure, restart or soft reset, it will first initialize its local bootloader. After completing the initial initialization, the HGU will immediately send a software firmware version loading request to the VHGU to obtain the complete firmware version to complete the startup. Each loading request contains the MAC address information of the HGU. By receiving these requests, the VHGU can identify the HGU that issued the request in the current virtual domain in real time.

[0030] Specifically, after completing the bootloader initialization, the HGU will send a loading request through a multicast virtual domain multicast loading (VDML) request message, and start a local timer (timer1), marking its own loading status as "Wait". At this time, the information in the VDML request message includes identification information such as the MAC address of the HGU, and other HGUs in the domain will automatically ignore this request message to avoid unnecessary interference. When the VHGU receives the request, it will confirm the source of the loading request based on the HGU's MAC address, and start a local statistical timer (Vtimer_s) to record the number of HGUs that request to load the software firmware version within the set timeout period.

[0031] The purpose of this design is to grasp the total number of HGUs that issue loading requests in the virtual domain in real time through regular statistics, providing a basis for selecting the sending method in the subsequent steps. In addition, by receiving loading requests and recording the MAC address information of HGU, VHGU can accurately track the startup status and request requirements of each HGU, which provides an efficient distribution basis for subsequent multicast or unicast loading solutions.

[0032] Step 2: Determine the number of home gateway units that send software firmware version load requests.

[0033] Specifically, in step 1, the VHGU has received load requests from multiple HGUs. Next, in step 2, the VHGU will perform regular statistics based on the local statistical timer (Vtimer_s) to determine the total number of HGUs that have sent software firmware version load requests to it within the timeout period. Specifically, after receiving the load request from each HGU, the VHGU will record the MAC address of the HGU from which the request originated into the local list, and start the Vtimer_s timer at the same time to count the total number of requests within the set time window. After the Vtimer_s statistical process is completed, the VHGU will summarize the number of HGUs in the MAC address list and finally confirm the total number of requested HGUs.

[0034] Furthermore, the purpose of counting the number of requests is to enable the VHGU to flexibly select the appropriate sending mode according to the current HGU loading requirements. When there are more than one HGU, it means that multiple HGUs need to load the software firmware version at the same time. At this time, the VHGU can give priority to sending the software firmware version through multicast, so as to meet the needs of multiple HGUs at one time, reduce repeated transmission, and optimize network resource utilization. When there is only one HGU, multicast is not required. The VHGU can directly use unicast to transmit the software firmware version, so as to provide stable and reliable data loading for the needs of a single HGU.

[0035] Step 3: Based on the quantity, determine the sending method of the software firmware version, and send the software firmware version to the home gateway unit based on the sending method, so that the home gateway unit completes the startup according to the software firmware version.

[0036] In the diskless boot method within the FTTR virtual domain of the present invention, step 3 is used to determine the sending method of the software firmware version based on the number of home gateway unit (HGU) requests counted in step 2, and send the software firmware version to the HGU so that the HGU can complete the startup. The design purpose of step 3 is to reasonably utilize network resources under the premise of ensuring data transmission efficiency, and to ensure that a stable and efficient firmware distribution method is provided in different HGU request scenarios.

[0037] In one possible implementation, refer to Figure 2 , Figure 2 This is the second flow chart of the diskless boot method in the FTTR virtual domain provided by the present invention, and step 3 specifically includes steps 31-33: Step 31: When the quantity is greater than 1, create a multicast software firmware version task and obtain the task creation status.

[0038] Specifically, when the VHGU counts in step 2 that the number of HGUs that have issued loading requests is greater than 1, it enters the multicast loading process. At this time, the VHGU first creates a multicast software firmware version task and assigns a unique transaction ID to the task. The role of the transaction ID is to ensure the uniqueness of the current task, so that each HGU can accurately identify the task when receiving the multicast message to avoid confusion with other tasks. At the same time, the VHGU stores the MAC address information of all HGUs requesting loading in the task-associated list to facilitate subsequent distribution operations.

[0039] During the task creation process, VHGU will obtain the task creation status in real time to ensure the reliability of task creation. If the task is created successfully, VHGU will further execute the multicast loading process and send multicast response messages and segmented software firmware version data to HGU in turn. If the task creation fails, VHGU will switch to unicast mode based on the feedback information of the creation failure to ensure that HGU can successfully complete the startup in another way.

[0040] Through this design, VHGU can effectively manage the synchronous loading requirements of multiple HGUs. When the multicast task is successfully created, VHGU can satisfy all HGUs requesting loading through only one multicast transmission, thereby reducing the amount of data transmitted repeatedly, saving network bandwidth, and improving loading efficiency. In the case of task creation failure, switching to unicast mode can ensure that the startup of HGU is not delayed. Therefore, the implementation method of step 31 not only ensures efficient loading in the scenario of multiple HGU requests, but also provides a reliable alternative solution when multicast task creation exceptions occur. This not only optimizes the resource utilization of the FTTR virtual domain, but also greatly improves the startup response speed of the device and the flexibility of the system.

[0041] Step 32: When the task is created successfully, the software firmware version is sent to the home gateway unit via multicast.

[0042] Specifically, in the diskless boot method in the FTTR virtual domain of the present invention, step 32 is used for the virtual home gateway unit (VHGU) to send the software firmware version to the home gateway unit (HGU) requesting loading by multicasting when the multicast software firmware version task is successfully created. The purpose of designing step 32 is to realize synchronous firmware loading of multiple HGUs by multicasting, reduce repeated data transmission, save network resources, and improve loading efficiency.

[0043] In one possible implementation, refer to Figure 3 , Figure 3 This is the third flow chart of the diskless boot method in the FTTR virtual domain provided by the present invention. Step 32 specifically includes the following steps: Step 321: Allocate a unique transaction identifier for the multicast software firmware version task.

[0044] Specifically, when the VHGU successfully creates the multicast software firmware version task in step 31, it immediately generates a unique transaction ID for the task. This Transaction ID is used to identify the current multicast task and will be used as a unique task identifier in subsequent multicast data messages, so that each HGU can identify and verify the legitimacy of the data source when receiving data. The process of generating the Transaction ID can be based on the current timestamp, task sequence number or other random generation mechanism to ensure that the identifier of each task is unique, thereby avoiding task conflicts.

[0045] The allocation of Transaction ID is crucial for multicast tasks. In a multicast environment, multiple HGUs may receive the same multicast data stream, but different tasks may involve different firmware versions, or there may be other tasks executing in parallel. Therefore, VHGU adds a Transaction ID to each multicast data fragment message, so that each HGU can confirm the correctness and uniqueness of the data by comparing the Transaction ID when receiving data. Only the HGU whose TransactionID matches its own task will continue to receive and process the data, otherwise it will directly discard the unmatched message to avoid unnecessary data processing and potential waste of resources.

[0046] By assigning Transaction IDs to multicast tasks, VHGU achieves efficient management of multicast data transmission. This approach ensures that when multiple HGUs request to load, each HGU only receives the firmware version data it needs, improving the accuracy of transmission and the control effect of data flow.

[0047] Step 322: Send a multicast response message to the virtual domain, the multicast response message including the transaction identifier and the MAC address information of each home gateway unit requested to be loaded, so that each home gateway unit requested to be loaded matches the transaction identifier corresponding to its own MAC address information from the virtual domain.

[0048] In the diskless boot method within the FTTR virtual domain of the present invention, step 322 is used for sending a multicast response message from the virtual home gateway unit (VHGU) to the virtual domain after the multicast task is successfully created and a unique transaction identifier (Transaction ID) is assigned. The message contains the Transaction ID and a list of MAC addresses of the home gateway unit (HGU) requested to be loaded. The design purpose of step 322 is to ensure that only the HGU requested to be loaded can receive and process the corresponding multicast data, thereby avoiding cross-domain interference or erroneous reception of irrelevant HGUs, and ensuring the accuracy and security of multicast transmission.

[0049] In the specific implementation process, after successfully creating a multicast task and generating a Transaction ID, the VHGU first encapsulates the ID and the MAC address information of all HGUs requesting to be loaded into a multicast response message. The message is broadcast to all HGUs in the virtual domain via multicast. After receiving the multicast response message, each HGU will parse the message content and check whether the message contains its own MAC address information. If it finds that its own MAC address is in the MAC address list of the message, the HGU confirms that it is part of the multicast task, records the Transaction ID, marks its own multicast loading status as "Ready", turns off the request timer, and enters the state of waiting to receive data; for HGUs that do not contain their own information in the MAC address list, the message is directly discarded to ensure that only relevant HGUs participate in the task, avoiding unnecessary bandwidth occupation and data processing.

[0050] The reason for this design is that within the FTTR virtual domain, there may be data streams from other multicast tasks, or non-task-related HGUs may receive multicast data. By including the Transaction ID and MAC address list in the multicast response message, the VHGU can accurately control each HGU participating in the task to ensure that the HGU only receives data streams that meet the conditions. The MAC address list is part of the verification conditions, allowing each HGU to quickly determine the relevance of the task to itself, avoiding the mistaken reception of data from other HGUs, and ensuring the accuracy of data reception.

[0051] Step 323: The segmented software firmware version data containing the transaction identifier is sent to the virtual domain in sequence, so that each home gateway unit that requests to be loaded matches the segmented software firmware version data corresponding to its own transaction identifier from the virtual domain; the segmented software firmware version data is to divide the complete software firmware version into multiple data segments according to a predetermined size or logic.

[0052] In the diskless boot method in the FTTR virtual domain of the present invention, step 323 is used for sending the segmented software firmware version data including the transaction ID to the home gateway units (HGU) in the virtual domain in sequence by the virtual home gateway unit (VHGU) through multicast after the multicast response message is sent. The design purpose of step 323 is to ensure data integrity and reduce the risk of packet loss through segmented transmission, so that multiple HGUs can complete firmware loading efficiently and orderly.

[0053] Specifically, when the VHGU sends a multicast response message containing a Transaction ID and a MAC address list to the HGU in the virtual domain in step 322, all HGUs participating in the task enter the "ready" state and wait to receive the segmented software firmware version data. In step 323, the VHGU divides the complete software firmware version data into several data segments according to a predetermined size or logic, and each segment is accompanied by a Transaction ID to ensure the uniqueness of the transmission and the correctness of the data. The VHGU then sends these segmented data one by one to the virtual domain via multicast, and broadcasts each segment data in sequence to all HGUs that request to load.

[0054] During the data reception process, when each HGU receives a multicast data segment, it first verifies the Transaction ID in the data packet to confirm the task ownership of the data. Only the HGU with a matching Transaction ID will store the segmented data in the specified memory address and begin receiving and assembling it segment by segment. If the Transaction ID of the received data segment does not match, the HGU will immediately discard the data segment to ensure that only the data of the relevant task is processed to avoid interference from other tasks. As all the segmented data are received and stored in sequence, the HGU will assemble the data segments according to the sequence number and perform data verification after the assembly is completed to ensure the integrity and correctness of the segmented data. After the data verification passes, the HGU loads the software firmware version from the specified memory address, starts to initialize the kernel and rootfs, and completes the startup.

[0055] Step 33: When the task creation fails, or the number is less than 1, the software firmware version is sent to the home gateway unit via unicast.

[0056] In the diskless boot method in the FTTR virtual domain of the present invention, step 33 is used to send the software firmware version to the home gateway unit (HGU) by the virtual home gateway unit (VHGU) by unicast when the multicast task creation fails or the number of the home gateway unit (HGU) for the loading request is 1. The design purpose of step 33 is to ensure that each HGU can still obtain the necessary software firmware version by unicast to complete the boot process when the multicast task cannot be realized or is not suitable.

[0057] In a possible implementation, step 33 specifically includes the following steps: Establishing a unicast communication connection with a home gateway unit; The software firmware version is sent to the home gateway unit via a unicast communication connection.

[0058] Specifically, when the VHGU fails to create a multicast task in step 31, or determines in step 2 that the number of HGUs requested to be loaded is only 1, the VHGU initiates the unicast transmission process. At this time, the VHGU first establishes a unicast communication connection with the target HGU. To this end, the HGU sends a Dynamic Host Configuration Protocol (DHCP) request to the VHGU to apply for an IP address so that the VHGU can assign it a unique network address to establish a dedicated unicast channel. After the unicast communication connection is successfully established, the HGU immediately initiates a download request based on TFTP (Trivial File Transfer Protocol) to the VHGU in order to receive the complete software firmware version through the dedicated channel.

[0059] Next, VHGU starts to transmit the complete software firmware version data to HGU via unicast. Unlike multicast, unicast transmission has a clear target, and the data transmission is directly to the requesting HGU without segmentation. This process ensures that the HGU can stably receive the required complete firmware version without interference from other devices. HGU stores the received software firmware version to the specified memory address and verifies it after the data transmission is completed to ensure the integrity and accuracy of the data. After the verification passes, HGU loads the software firmware version from the memory address and enters the initialization process of kernel and rootfs, successfully completing the startup.

[0060] The reason why this design chooses unicast transmission is that when the number of requested HGUs is small or the multicast task cannot be successfully created, multicast transmission will not be able to fully utilize network resources and may increase the complexity of task management. In this case, directly establishing a unicast connection to provide an independent transmission channel for the HGU can better meet the startup requirements of individual HGUs and ensure data reliability. Through unicast, VHGU can flexibly respond to various loading scenarios, so that each HGU can normally obtain the software and firmware version and complete diskless boot regardless of multicast failure or unicast requirements.

[0061] In a possible implementation, after step 32, the method further includes the following steps: Receiving loading completion confirmation information sent by the home gateway unit; The software loading status of the home gateway unit is updated based on the loading completion confirmation information.

[0062] Specifically, when the HGU completes the reception and verification of the software firmware version through multicast or unicast, it sets the loading status to Done and sends a loading completion confirmation message to the VHGU through the VDML (Virtual Domain Multicast Load) protocol. The confirmation message contains the MAC address of the HGU and the transaction identifier (Transaction ID) of the loading task to ensure that the VHGU can accurately identify the source of the confirmation information and the associated loading task. After receiving the confirmation message, the VHGU will parse the MAC address and Transaction ID in the message to confirm that the loading status of the HGU has been successfully completed, and further ensure that the HGU has correctly obtained and loaded the firmware version. The design of this confirmation step ensures that the VHGU can obtain the loading completion status of the HGU in real time, avoiding repeated tasks or accumulation of errors during the loading process.

[0063] Next, based on the loading completion confirmation information, VHGU immediately updates the locally recorded HGU loading status. Specifically, VHGU will update the status of the HGU from "loading" to "completed" and record the relevant Transaction ID as the completed status for subsequent management and maintenance. By updating the loading status, VHGU achieves unified management of the HGU startup process within the domain, making the loading status of each HGU clear at a glance, facilitating future firmware version management and troubleshooting. In addition, this loading status update helps VHGU identify completed HGUs when performing the next round of firmware version updates, thereby avoiding repeated loading or waste of resources.

[0064] The key to this design is to achieve accurate management and efficient monitoring of the startup status of devices in the domain through the confirmation of loading completion of HGU and the update of loading status of VHGU. First, it ensures that VHGU can receive feedback information of loading completion in a timely manner and effectively control the startup process of HGU; secondly, the status update further strengthens the system's ability to record and manage the device startup process. This dual confirmation and update mechanism not only improves the reliability of the system, but also ensures the orderly execution of the diskless startup process in the FTTR virtual domain, laying a solid foundation for the subsequent firmware updates and device management of the system. Finally, the implementation of the above steps ensures the closed-loop control and data consistency of the entire startup process, significantly improving the management efficiency and response speed of the FTTR virtual domain diskless startup solution.

[0065] In a possible implementation, the method further includes the following steps: When creating a virtual domain, a unique domain identifier is assigned to the virtual domain; In the communication message with the home gateway unit, a domain identifier is added.

[0066] Specifically, when the optical link terminal (OLT) creates a VHGU for an FTTR virtual domain, it assigns a unique domain identifier (domain ID) and stores the domain ID in association with the VHGU in the virtual domain. The domain ID is designed to distinguish the communication ranges of different virtual domains. Because in a multi-virtual domain environment, multiple virtual domains may share the same network resources and physical environment, it is necessary to assign a unique identifier to each virtual domain to ensure the independence and data isolation of each virtual domain. By assigning a unique domain ID to each virtual domain, the VHGU can accurately identify the HGU device belonging to the domain according to the domain ID during management and transmission, avoiding cross-domain data conflicts. At the same time, domain ID allocation provides a key basis for subsequent communication management and security control.

[0067] After the domain ID is assigned, the VHGU will add the domain ID of the virtual domain to each communication message during the communication with the HGU. Specifically, whenever the VHGU and the HGU communicate with each other such as software firmware version loading request, response or data transmission, the VHGU will embed the domain ID of the current virtual domain in the header or specified field of the communication message. When the HGU receives the message, it will first check whether the domain ID is consistent with the identifier of the domain to which it belongs, so as to confirm whether the message comes from the VHGU of this domain. If the domain ID matches, the HGU will continue to process the message content; if the domain ID does not match, the message will be directly discarded to avoid unnecessary data processing and ensure cross-domain data isolation. This verification step ensures that only the VHGU and HGU of this domain can communicate normally, effectively preventing cross-domain interference.

[0068] Reference Figure 4 , Figure 4 It is a structural schematic diagram of the diskless boot system in the FTTR virtual domain provided by the present invention, and the system includes: A receiving module, used to receive at least one software firmware version loading request, each software firmware version loading request is sent by a home gateway unit; A first processing module, used to determine the number of home gateway units that send software firmware version loading requests; The second processing module is used to determine the sending method of the software firmware version based on the quantity, and send the software firmware version to the home gateway unit based on the sending method, so that the home gateway unit completes the startup according to the software firmware version.

[0069] In a possible implementation manner, the second processing module is further configured to: When the number is greater than 1, create a multicast software firmware version task and obtain the task creation status; When the task is created successfully, the software firmware version is sent to the home gateway unit via multicast; When the task creation fails, or the number is less than 1, the software firmware version is sent to the home gateway unit via unicast.

[0070] In a possible implementation manner, the second processing module is further configured to: Assign a unique transaction identifier to the multicast software firmware version task; Sending a multicast response message to the virtual domain, the multicast response message including the transaction identifier and the MAC address information of each home gateway unit requested to be loaded, so that each home gateway unit requested to be loaded matches the transaction identifier corresponding to its own MAC address information from the virtual domain; The segmented software firmware version data containing the transaction identifier is sent to the virtual domain in sequence, so that each home gateway unit requesting to be loaded matches the segmented software firmware version data corresponding to its own transaction identifier from the virtual domain; the segmented software firmware version data is to divide the complete software firmware version into multiple data segments according to a predetermined size or logic.

[0071] In a possible implementation manner, the second processing module is further configured to: Establishing a unicast communication connection with a home gateway unit; The software firmware version is sent to the home gateway unit via a unicast communication connection.

[0072] In a possible implementation manner, the receiving module is further configured to receive loading completion confirmation information sent by the home gateway unit; The second processing module is also used to update the software loading status of the home gateway unit based on the loading completion confirmation information.

[0073] In a possible implementation manner, the first processing module is further configured to: When creating a virtual domain, a unique domain identifier is assigned to the virtual domain; In the communication message with the home gateway unit, a domain identifier is added.

[0074] It should be noted that the diskless boot system in the FTTR virtual domain provided by the present invention can execute the diskless boot method in the FTTR virtual domain of any of the above embodiments during specific operation, which will not be described in detail in this embodiment.

[0075] Figure 5 is a schematic diagram of the structure of the electronic device provided by the present invention, such as Figure 5 As shown, the electronic device may include: a processor 510 (processor), a communication interface 520 (CommunicationsInterface), a memory 530 (memory) and a communication bus 540, wherein the processor 510, the communication interface 520, and the memory 530 communicate with each other through the communication bus 540. The processor 510 may call the logic instructions in the memory 530 to execute the diskless boot method in the FTTR virtual domain, the method comprising: receiving at least one software firmware version loading request, each software firmware version loading request is sent by a home gateway unit; determining the number of home gateway units that send the software firmware version loading request; based on the number, determining the sending method of the software firmware version, and sending the software firmware version to the home gateway unit based on the sending method, so that the home gateway unit completes the startup according to the software firmware version.

[0076] In addition, the logic instructions in the above-mentioned memory 530 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on such an understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods of various embodiments of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory 530 (ROM, Read-Only Memory), random access memory 530 (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0077] On the other hand, the present invention also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer, the computer can execute the diskless startup method within the FTTR virtual domain provided by the above-mentioned embodiments, and the method includes: receiving at least one software firmware version loading request, each software firmware version loading request is sent by a home gateway unit; determining the number of home gateway units that send software firmware version loading requests; based on the number, determining a sending method for the software firmware version, and sending the software firmware version to the home gateway unit based on the sending method, so that the home gateway unit completes the startup according to the software firmware version.

[0078] On the other hand, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon. When the computer program is executed by the processor 510, it is implemented to execute the diskless boot method within the FTTR virtual domain provided by the above-mentioned embodiments, the method comprising: receiving at least one software firmware version loading request, each software firmware version loading request is sent by a home gateway unit; determining the number of home gateway units that send the software firmware version loading request; based on the number, determining a sending method of the software firmware version, and sending the software firmware version to the home gateway unit based on the sending method, so that the home gateway unit completes the startup according to the software firmware version.

[0079] The system embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, i.e., they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Those of ordinary skill in the art may understand and implement it without creative effort.

[0080] Through the description of the above implementation modes, those skilled in the art can clearly understand that each implementation mode can be implemented by means of software plus a necessary general hardware platform, or of course by hardware. Based on such an understanding, the above technical solution can essentially or in other words be embodied in the form of a software product that contributes to the prior art. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of each embodiment or some parts of the embodiment.

[0081] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A diskless boot method in a FTTR virtual domain, characterized in that: Applied to a virtual home gateway unit, the virtual home gateway unit is used to maintain the MAC address information of all home gateway units in the virtual domain and save the software firmware versions of all home gateway units, including: Receiving at least one software firmware version loading request, each of the software firmware version loading request is sent by a home gateway unit; Determining the number of home gateway units that sent the software firmware version loading request; Based on the quantity, a sending method of the software firmware version is determined, and based on the sending method, the software firmware version is sent to the home gateway unit, so that the home gateway unit completes startup according to the software firmware version.

2. The diskless boot method in the FTTR virtual domain according to claim 1, characterized in that: The determining, based on the quantity, a sending method of the software firmware version, and sending the software firmware version to the home gateway unit based on the sending method specifically includes: When the number is greater than 1, create a multicast software firmware version task and obtain the task creation status; When the task is created successfully, the software firmware version is sent to the home gateway unit via multicast; When the task creation fails, or the number is less than 1, the software firmware version is sent to the home gateway unit via unicast.

3. The diskless boot method in the FTTR virtual domain according to claim 2, characterized in that: The sending of the software firmware version to the home gateway unit by multicasting specifically includes: Allocating a unique transaction identifier to the multicast software firmware version task; Sending a multicast response message to the virtual domain, the multicast response message including the transaction identifier and the MAC address information of each home gateway unit requested to be loaded, so that each home gateway unit requested to be loaded matches the transaction identifier corresponding to its own MAC address information from the virtual domain; The segmented software firmware version data containing the transaction identifier is sent to the virtual domain in sequence, so that each home gateway unit requesting to load matches the segmented software firmware version data corresponding to its own transaction identifier from the virtual domain; the segmented software firmware version data is to divide the complete software firmware version into multiple data segments according to a predetermined size or logic.

4. The diskless boot method in the FTTR virtual domain according to claim 2, characterized in that: The sending of the software firmware version to the home gateway unit by unicast specifically includes: Establishing a unicast communication connection with the home gateway unit; The software firmware version is sent to the home gateway unit via the unicast communication connection.

5. The diskless boot method in the FTTR virtual domain according to claim 2, characterized in that: After sending the software firmware version to the home gateway unit by multicasting, the method further includes: Receiving loading completion confirmation information sent by the home gateway unit; The software loading status of the home gateway unit is updated based on the loading completion confirmation information.

6. The diskless boot method in the FTTR virtual domain according to claim 1, characterized in that: The method further comprises: When creating a virtual domain, a unique domain identifier is assigned to the virtual domain; The domain identifier is added in the communication message with the home gateway unit.

7. A diskless boot system in a FTTR virtual domain, characterized in that: include: A receiving module, configured to receive at least one software firmware version loading request, each of which is sent by a home gateway unit; A first processing module, used to determine the number of home gateway units that send the software firmware version loading request; The second processing module is used to determine the sending method of the software firmware version based on the quantity, and send the software firmware version to the home gateway unit based on the sending method, so that the home gateway unit completes startup according to the software firmware version.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the diskless boot method within the FTTR virtual domain is implemented as described in any one of claims 1-6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the diskless boot method in the FTTR virtual domain is implemented as claimed in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the diskless boot method in the FTTR virtual domain is implemented as claimed in any one of claims 1 to 6.

Images