CN117950474A - Centralized RRU reset control method - Google Patents

Abstract

The invention provides a centralized RRU reset control method, which comprises the following steps: establishing a device reset process; establishing a communication bridge between a device reset process and other processes; and when the device reset process controls the reset, sending a notification to other processes, and resetting after receiving the confirmation. The invention establishes an independent device reset process and limits control command, avoids a plurality of reset inlets in one system, and uniformly manages reset reasons. The waiting control of the reset is realized through the inquiry mechanism of the equipment reset process, and the abnormal occurrence of the process of the service communication due to the reset can be effectively avoided.

Description

Centralized RRU reset control method

Technical Field

The invention relates to the field of wireless access networks, in particular to a centralized RRU reset control method.

Background

For devices with operating systems, multiple processes run independently of each other to reduce coupling, and each process may have a request to reset the device. For the embedded operating system equipment, because related work needs to be completed independently and automatically, a man-machine interface and man-machine interaction rarely exist, and a user cannot be reset manually or confirmed in a trigger event mode. Meanwhile, for a device that needs to interact with other devices, if service communication is in progress, device reset cannot be performed at this time. Based on this, there is a need for a reset method for embedded systems that require interconnection.

Disclosure of Invention

Aiming at the problems existing in the prior art, a centralized RRU reset control method is provided, and reset control of equipment is realized by establishing an independent equipment reset process and establishing a judging mechanism.

The technical scheme adopted by the invention is as follows: a centralized RRU reset control method comprises the following steps:

Establishing a device reset process;

establishing a communication bridge between a device reset process and other processes;

And when the device reset process controls the reset, sending a notification to other processes, and resetting after receiving the confirmation.

Furthermore, the device reset process is an independent process, is started before other processes related to the service in the RRU, and is controlled to be reset through a bottom command line.

Further, the command to control reset is saved to a PATH that will not be added to the PATH environment variable by default.

Further, the command controlling the reset is renamed.

Further, the establishing a communication bridge between the device reset process and other processes specifically includes:

All processes needing to be reset establish communication with the device reset process in the initialization process, and define a message format of the communication, including a reset reason and a priority, wherein the priority is used for indicating whether other processes need to wait for confirmation, and the reset reason is used for acquiring after the reset.

Further, when all the processes needing to be reset need to reset the equipment, a reset request and a reset reason are sent to a reset management process; and the reset management process collects corresponding log files and performs backup according to the reset request type, and records the reset reason.

Further, the specific process of resetting after receiving the acknowledgement includes:

All processes concerned about resetting the equipment register with the equipment resetting process during initialization;

When the device reset process controls the reset, a notification is sent to all registered processes, and the device is inquired whether the important transaction is required to be completed or not when the device is about to be reset;

And the other processes reply whether to reset according to the self conditions, if all processes agree to reset, the reset is executed, otherwise, whether to reset or wait is judged according to the priority of the process requesting to reset.

Further, the specific process of judging whether to reset or wait according to the priority of the reset request process includes:

if the priority of the process requesting reset is higher than that of the process which does not agree with reset, the device resets the process period and inquires for three times, if the reply is not received after three times, the device directly resets after recording information, and if the process requesting reset is lower than that of the process which does not agree with reset, the device always waits and inquires.

Further, for the devices connected with the upper and lower stages, the upper and lower stages are informed to make backup and protection measures before reset or the upper stage device is enabled to perform reset control on the local device during reset.

Further, the protection strategy of the device reset process is also included:

① Disabling all semaphores;

② Oom score of setting a device reset process;

③ And monitoring the reset process of the equipment, and if abnormality is found, exiting and automatically starting the equipment to ensure that the equipment survives all the time.

Compared with the prior art, the beneficial effects of adopting the technical scheme are as follows: the invention establishes an independent device reset process and limits control command, avoids a plurality of reset inlets in one system, and uniformly manages reset reasons. The waiting control of the reset is realized through the inquiry mechanism of the equipment reset process, and the abnormal occurrence of the process of the service communication is avoided.

Drawings

Fig. 1 is a flowchart of a centralized RRU reset control method according to the present invention.

Fig. 2 is a schematic diagram of centralized RRU reset control interaction in an embodiment of the present invention.

Detailed Description

Embodiments of the present application are described in detail below, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to like or similar modules or modules having like or similar functions throughout. The embodiments described below by referring to the drawings are illustrative only and are not to be construed as limiting the application. On the contrary, the embodiments of the application include all alternatives, modifications and equivalents as may be included within the spirit and scope of the appended claims.

In order to propose a device reset management mechanism for an embedded system, please refer to fig. 1 and fig. 2, an embodiment of the present invention proposes a centralized RRU reset control method. The specific scheme is as follows:

and step 1, establishing a device reset process.

In this embodiment, the established device reset process is an independent process, and the process is started before other processes related to the service in the RRU, and may adopt a Socket communication mode, where the process controls the reset through the bottom command line.

In order to prevent abuse of the command for controlling reset elsewhere, in this embodiment, the command for resetting the device (e.g. re_boot in Linux) is moved to a PATH that will be added to the PATH environment variable by default, and/or the command is renamed, so that it can be effectively avoided that the command is found by searching for the command, and at this time, the system will only reset through the device resetting process.

And 2, establishing a communication bridge between the equipment resetting process and other processes.

Referring to fig. 2, all processes requiring reset establish communication with the device reset process during the initialization process, such as other process 1 and other process 2 in fig. 2 each subscribe to the device reset process. Meanwhile, the message format of the communication between the two parties needs to be defined, and the message format mainly comprises priority and reset reasons. Wherein,

The priority is mainly used for indicating whether other processes need to wait for confirmation, such as a manual reset command, and the priority of a bit command issued by a previous device (such as a DU) is the highest priority, and the process is directly reset without waiting for the completion of processing of other processes.

The reset reason is mainly used for acquiring reset information after reset. When the equipment needs to be reset, all the processes needing to be reset send a reset request and a reset reason to a reset management process; and the reset management process collects corresponding log files and performs backup according to the reset request type, and records the reset reason. In this embodiment, the corresponding log file mainly includes: operating system logs (e.g., dmesg or/var/log, message files), on-RU exception logs (e.g., alarms, read-write failures, etc.), and logs of RU interactions with the previous layer DUs.

In one embodiment, the log files may be collected by an associated log module, or by the reset management process itself. If the log module is adopted, the reset information is recorded to the related log module, and at the moment, the reset management process is also connected with the log module.

Note that, the recording of the reset reason is automatically completed by the reset management process. In practical application, the data can be recorded in a database or a file which is not lost when power is lost, so that a viewable reset reason can be provided after reset. After reset, the reset management process runs, sorts the reset reason, and prints the reset reason into the serial port or sets a variable, and provides the variable when needed. In addition, in addition to acquiring information recorded by the process prior to reset, other reasons need to be acquired from the operating system, such as power-down reboot, watchdog timeout, etc.

And step 3, when the device reset process controls the reset, sending a notification to other processes, and resetting after receiving the confirmation.

With continued reference to fig. 2, since, during reset, the device to be reset may be currently interacting with other processes, a reset secondary acknowledgement mechanism of other processes is proposed in this embodiment.

Specifically, all processes concerned about resetting the device register with the device reset process at the time of initialization. When the device reset process controls the reset, a notification is sent to all registered processes, and the device is inquired whether the important transaction is required to be completed or not when the device is about to be reset; and the other processes reply whether to reset according to the self conditions, if all processes agree to reset, the reset is executed, otherwise, whether to reset or wait is judged according to the priority of the process requesting to reset.

In this embodiment, a corresponding priority judging method is provided, which specifically includes:

If the priority of the process requesting reset is higher than that of the process which does not agree with reset, the device resets the process period (for example, interval 10 s) to inquire for three times, if the reply is not received after three times, the device directly resets after recording the information, and if the process requesting reset is lower than that of the process which does not agree with reset, the device always waits and inquires.

In addition, in practical application, the RRU is an upper and lower device, and for a device with priority to the upper and lower devices, in order to avoid data loss, the upper and lower devices need to be notified of backup and protection measures before reset, or the upper/lower devices directly perform reset control on the present device, that is, send a message requesting reset by the upper and lower devices. If the upper device resets the RU, the reset reason is passive reset, and the event information requesting the reset needs to be recorded in the log, that is, even if the reset reason is passive reset, the upper device (for example, the DU) is requested to be reset by the RU after the RU has the own reason from the log information.

In one embodiment, the centralized RRU reset control method needs to ensure that the device reset process is always in an active state in order to provide a stable device reset function. In this embodiment, the following strategies are employed:

① Disabling all semaphores can preferentially avoid turning them off by kill commands.

② Oom score (Oom: out of memory) of the device reset procedure is set to avoid being turned off preferentially when memory is not sufficient. The operating system scores the memory usage of each process, and if the memory is insufficient, the operating system preferentially kills the highest occupied memory (oom score the highest score). In this embodiment, oom score of the device reset process is manually set to a smaller value, so that the problem that RU cannot be reset due to shutdown of the process caused by insufficient memory is avoided.

③ And monitoring the reset process of the equipment, and if abnormality is found, exiting and automatically starting the equipment to ensure that the equipment survives all the time. In particular, according to embodiments of the present application, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts.

It should be noted that, the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-Only Memory (ROM), an erasable programmable read-Only Memory (Erasable Programmable Read Only Memory, EPROM), a flash Memory, an optical fiber, a portable compact disc read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Where each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units involved in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be provided in a processor. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.

As another aspect, the present application also provides a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the centralized RRU reset control method described in the above embodiment.

As another aspect, the present application also provides a computer-readable medium that may be contained in the electronic device described in the above embodiment; or may exist alone without being incorporated into the electronic device. The computer-readable medium carries one or more programs that, when executed by one of the electronic devices, cause the electronic device to implement the centralized RRU reset control method described in the above embodiments.

It should be noted that although in the above detailed description several modules or units of a device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functions of two or more modules or units described above may be embodied in one module or unit in accordance with embodiments of the application. Conversely, the features and functions of one module or unit described above may be further divided into a plurality of modules or units to be embodied.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, the technical solution according to the embodiments of the present application may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-RAM, a usb disk, a mobile hard disk, etc.) or on a network, and includes several instructions to cause a computing device (may be a personal computer, a server, a touch terminal, or a network device, etc.) to perform the method according to the embodiments of the present application.

The specific meaning of the above terms in the present invention will be understood in detail by those skilled in the art; the accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the principles of the invention. The components of the embodiments of the present invention generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations.

While embodiments of the present application have been shown and described above, it will be understood that the above embodiments are illustrative and not to be construed as limiting the application, and that variations, modifications, alternatives and variations may be made to the above embodiments by one of ordinary skill in the art within the scope of the application.

Claims (10)

1. The centralized RRU reset control method is characterized by comprising the following steps:

Establishing a device reset process;

establishing a communication bridge between a device reset process and other processes;

And when the device reset process controls the reset, sending a notification to other processes, and resetting after receiving the confirmation.

2. The method of claim 1, wherein the device reset process is an independent process that is started prior to other service related processes in the RRU and is controlled to be reset by an underlying command line.

3. The method of claim 2, wherein the command to control the reset is saved to a PATH that does not default to the PATH environment variable.

4. A centralized RRU reset control method as claimed in claim 2 or 3, wherein the command to control the reset is renamed.

5. The method for controlling centralized RRU reset according to claim 1, wherein said establishing a communication bridge between the device reset process and the other processes specifically comprises:

All processes needing to be reset establish communication with the device reset process in the initialization process, and define a message format of the communication, including a reset reason and a priority, wherein the priority is used for indicating whether other processes need to wait for confirmation, and the reset reason is used for acquiring after the reset.

6. The method for controlling the reset of the centralized RRU of claim 5, wherein when all processes needing to be reset need to reset the device, a reset request and a reset reason are sent to a reset management process; and the reset management process collects corresponding log files and performs backup according to the reset request type, and records the reset reason.

7. The method for controlling centralized RRU reset according to claim 1, wherein the specific process of resetting after receiving the acknowledgement comprises:

All processes concerned about resetting the equipment register with the equipment resetting process during initialization;

When the device reset process controls the reset, a notification is sent to all registered processes, and the device is inquired whether the important transaction is required to be completed or not when the device is about to be reset;

And the other processes reply whether to reset according to the self conditions, if all processes agree to reset, the reset is executed, otherwise, whether to reset or wait is judged according to the priority of the process requesting to reset.

8. The method for controlling the centralized RRU reset according to claim 7, wherein said specific procedure for determining whether to reset or wait according to the priority of the request for reset procedure comprises:

if the priority of the process requesting reset is higher than that of the process which does not agree with reset, the device resets the process period and inquires for three times, if the reply is not received after three times, the device directly resets after recording information, and if the process requesting reset is lower than that of the process which does not agree with reset, the device always waits and inquires.

9. The method for controlling the reset of the centralized RRU according to claim 1, wherein for the devices associated with the upper and lower stages, the upper and lower stages are informed of performing backup and protection measures before the reset or the upper stage device performs the reset control on the local device during the reset.

10. The method for centralized RRU reset control of claim 1, further comprising a protection policy for the device reset procedure:

① Disabling all semaphores;

② Oom score of setting a device reset process;

③ And monitoring the reset process of the equipment, and if abnormality is found, exiting and automatically starting the equipment to ensure that the equipment survives all the time.