WO2011160385A1 - 一种基站自配置过程获取基本配置参数的自愈方法及基站 - Google Patents

一种基站自配置过程获取基本配置参数的自愈方法及基站 Download PDF

Info

Publication number
WO2011160385A1
WO2011160385A1 PCT/CN2010/078775 CN2010078775W WO2011160385A1 WO 2011160385 A1 WO2011160385 A1 WO 2011160385A1 CN 2010078775 W CN2010078775 W CN 2010078775W WO 2011160385 A1 WO2011160385 A1 WO 2011160385A1
Authority
WO
WIPO (PCT)
Prior art keywords
base station
rescue
help
message
request
Prior art date
Application number
PCT/CN2010/078775
Other languages
English (en)
French (fr)
Inventor
郑纪伟
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2011160385A1 publication Critical patent/WO2011160385A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/30—Network data restoration; Network data reliability; Network data fault tolerance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition

Definitions

  • the present invention relates to the field of wireless communications, and in particular, to a self-healing method and a base station for obtaining basic configuration parameters in a self-configuration process of a base station in a Long Term Evolution (LTE) system self-organizing network.
  • LTE Long Term Evolution
  • SON in LTE system has four functions: self-configuration, self-optimization, self-healing and self-planning.
  • the main functions of the process and implementation of the self-configuration and self-optimization process are shown in Figure 1.
  • the Evolved Node B eNB
  • the 110 basic startup phase of the self-configuration process, at least: 111: IP address configuration and operation and maintenance center (OMC) server detection, 112: node authentication, 113: establishment and evolution grouping
  • EPC Evolved Packet Core Network
  • 114 eNB software and download of operating parameters, etc.
  • initial wireless parameter configuration phase includes at least: 121: neighbor cell list Establish and 122: Coverage/capacity related parameter configuration and other parts
  • the optimization and adjustment phase includes at least: 131: optimization of neighbor cell list and 132: coverage/capacity control and other parts.
  • the node When a node is added to the network, the node first establishes an initial logical connection with the OMC server to complete the authentication and obtain the information needed to properly connect to the network. In order to establish an initial connection with the OMC server, the node first needs to know some basic parameter information, such as the node's own IP address, gateway address, Domain Name System (DNS) server address, and so on. In order to support self-configuration and self-optimization, these basic parameter information should be dynamically obtained.
  • the method for obtaining basic parameter information is basically implemented by Dynamic Host Control Protocol (DHCP).
  • DHCP Dynamic Host Control Protocol
  • the technical problem to be solved by the present invention is to provide a self-healing method and a base station for acquiring basic configuration parameters in a self-configuration process of a base station, so as to solve the defect that the base station cannot automatically recover after acquiring the basic configuration parameter information of the prior art.
  • the present invention provides a self-healing method for obtaining basic configuration parameters in a self-configuration process of a base station, including:
  • the base station If the base station fails to request its own basic configuration parameter information during the self-configuration process, the base station sends a help-seeking broadcast message to the neighboring base station;
  • the neighboring base station After receiving the call for help broadcast message, the neighboring base station broadcasts a rescue response message to the base station and other neighboring base stations if it has successfully obtained basic configuration parameters;
  • the rescue base station sends the requested basic configuration parameter information of the base station to the base station.
  • the method further includes:
  • the neighboring base station determines that it has not obtained the basic configuration parameters, it discards the help probe broadcast message.
  • the step of the base station transmitting the help probe broadcast message further includes:
  • the help probe broadcast message is resent.
  • the step of the base station selecting one of the neighboring base stations that broadcast the rescue response message as the rescue base station includes:
  • the base station selects, from among all the neighboring base stations that broadcast the rescue response message, the base station that first receives the adjacent base station corresponding to the rescue response message as the rescue base station; or
  • the base station selects, as a rescue base station, a neighboring base station corresponding to a message with a source IP address of a maximum or a minimum of all the rescue response messages received by the base station from all neighboring base stations that broadcast the rescue response message; or
  • the base station randomly selects one of all neighboring base stations broadcasting the rescue response message as a rescue base station.
  • the step of the base station requesting the rescue base station to request basic configuration parameter information of the base station from the DHCP server includes:
  • the base station sends a rescue request message, which carries the unique identifier information of the base station; after receiving the rescue request message, the rescue base station initiates a DHCP request to the DHCP server, where the unique identifier information of the base station is carried;
  • the DHCP server After receiving the DHCP request, the DHCP server allocates basic configuration parameter information to the base station according to the unique identification information of the base station, and sends the allocated basic configuration parameter information to the rescue base station.
  • the step of the neighboring base station transmitting the rescue response message to the base station and the other neighboring base stations further includes: adding the identifier label information of the neighboring base station itself to the rescue response message, And the identifier label information is recorded locally; wherein the identifier label information is used to uniquely identify the neighboring base station;
  • the rescue request message sent by the base station further carries the identifier label information of the rescue base station;
  • the rescue base station After the rescue base station receives the rescue request message, initiate the message to the DHCP server.
  • the steps of the DHCP request include:
  • the step of the base station transmitting the salvage detection broadcast message further includes: the base station setting the running state value of the base station to indicate that it is in a waiting for rescue state;
  • the other neighboring base station After receiving the rescue response message broadcast by the neighboring base station, the other neighboring base station determines whether the running state value of the neighboring base station indicates that it is in a waiting state; if the running state value of the neighboring station indicates that it is in a waiting state, it indicates that it In order to save the base station, the step of selecting the rescue base station is performed; if the running status value of the base station is not indicating that it is in the waiting for rescue state, the rescue response message is discarded.
  • the above method further includes:
  • the base station presets a threshold for the number of calls for help
  • the rescue base station If the rescue base station fails to replace the base station to request the basic configuration parameter, the rescue base station sends a notification message carrying the indication of the request failure identifier to the base station;
  • the base station After receiving the notification message, the base station determines whether the number of times of the rescue has reached the threshold of the number of times of the help; if the number of times of the rescue has reached the threshold of the number of calls, the base station restarts, and after the restart, the station is restarted.
  • the self-configuration process is performed; if the number of times of the help does not reach the threshold value of the number of calls for help, the step of transmitting the call for help broadcast message is re-executed.
  • the invention also provides a base station, comprising: a dynamic host configuration protocol DHCP request module, a help probe sending processing module, a help message receiving processing module, a rescue response sending processing module, a rescue response receiving processing module, a rescue request sending processing module, and a rescue a request receiving processing module, a basic parameter information sending module, and a basic parameter information acquiring module; wherein
  • the base station acts as a rescue base station
  • the DHCP requesting module is configured to: if the basic configuration parameter information of the base station itself is failed to be requested by the DHCP server, send a help-seeking command to the help-being detection sending processing module;
  • the help probe sending processing module is configured to: after receiving the help request, send a help probe broadcast message to the neighboring base station;
  • the rescue response receiving processing module is configured to: receive a rescue response message broadcasted after the neighboring base station receives the help probe broadcast message, and select one of all neighboring base stations that broadcast the rescue response message as a rescue base station, and Notifying the rescue request sending processing module; the rescue request sending processing module is configured to: after receiving the notification of the rescue response receiving processing module, send a rescue request message to the rescue base station;
  • the basic parameter information obtaining module is configured to: receive the basic configuration parameter information of the rescue base station requested by the rescue base station according to the received rescue request message to the DHCP server;
  • the base station acts as a rescue base station
  • the help message receiving processing module is configured to: after receiving the help probe broadcast message, if the basic configuration parameter is successfully obtained, the rescue response sending module sends a rescue response command;
  • the rescue response sending processing module is configured to: after receiving the rescue response command, broadcast a rescue response message to the rescue base station and other neighboring base stations;
  • the rescue request receiving processing module is configured to: after receiving the rescue request message sent by the help requesting base station according to the rescue response message received by the help requesting base station, send a DHCP request to the DHCP requesting module;
  • the DHCP requesting module is further configured to: after receiving the DHCP request, request the basic configuration parameter information of the help requesting base station to the DHCP server instead of the help requesting base station;
  • the basic parameter information sending module is configured to: send basic configuration parameter information of the help requesting base station requested by the DHCP requesting module to the help-seeking base station.
  • the help probe sending processing module is further configured to start a wait response timer; and if it is detected that the wait response timer expires, the rescue response receiving processing module still does not receive the rescue response message, Resending the distress probe broadcast message.
  • the rescue request message sent by the rescue request sending processing module carries the unique identification information of the base station
  • the rescue request receiving processing module is further configured to: after receiving the rescue request message, carry the unique identifier information of the help requesting base station to the DHCP request initiated by the DHCP server.
  • the rescue response transmission processing module is further configured to: add the identification label information of the base station itself to the rescue response message broadcasted to the help base station and other neighboring base stations, and record the identification label information locally;
  • the identifier label information is used to uniquely identify the base station;
  • the rescue request message sent by the rescue request sending processing module further carries the identifier label information of the rescue base station;
  • the rescue request receiving processing module is configured to: after receiving the rescue request message, determine whether the locality has recorded the identification label information of the base station; if the identification label information of the base station is not recorded, discard the rescue request If the identifier information of the local base station is recorded, it is determined whether the identification label information of the local record is consistent with the identification label information carried in the rescue request message; if the locally recorded identification label information is carried in the rescue request message If the identification label information is consistent, it is learned that it is the rescue base station, and the DHCP request is initiated to the DHCP server; if the locally recorded identification label information is inconsistent with the identification label information carried in the rescue request message, the discard is discarded.
  • the rescue request message is configured to: after receiving the rescue request message, determine whether the locality has recorded the identification label information of the base station; if the identification label information of the base station is not recorded, discard the rescue request If the identifier information of the local base station is recorded, it is determined whether the identification label information of the local record is consistent with the identification label information carried in
  • the help probe sending processing module is further configured to set an operating state value of the base station to indicate that it is in a waiting state;
  • the rescue response receiving processing module is further configured to: after receiving the rescue response message broadcast by the neighboring base station, determine whether the running status value of the base station indicates that it is in a waiting for rescue state; The self-operating state value indicates that it is in the waiting for rescue state, and indicates that it is the help-seeking base station, and performs the selection of the rescue base station; if the operating state value of the self does not indicate that it is in the waiting for rescue state, the rescue response message is discarded.
  • FIG. 1 is a schematic diagram of a self-configuration and self-optimization process of a base station SON in the prior art
  • FIG. 2 is a flow chart of a self-healing method for obtaining basic configuration parameters in a self-configuration process of a base station according to an embodiment of the present invention
  • FIG. 3 is a flowchart of processing of a neighboring base station in an embodiment of the present invention.
  • FIG. 4 is a structural diagram of a base station capable of realizing a self-healing function according to an embodiment of the present invention
  • FIG. 5 is another structural diagram of a base station capable of realizing a self-healing function according to an embodiment of the present invention
  • FIG. 6 is a schematic flow chart of an application example 1 of the present invention.
  • Fig. 7 is a flow chart showing the application example 2 of the present invention. Preferred embodiment of the invention
  • a description of a specific embodiment of the present invention relates to an LTE ad hoc network system, including at least
  • DHCP server (DHCP Server), OMC server, and multiple base stations. It involves the interaction process between the base station and the DHCP server and the OMC server, but it is not the focus of the present invention, so only a very brief description or only a reference is made; the invention is further illustrated by the interaction process between multiple base stations.
  • the basic idea of the method of the present invention is: if the base station fails to request its own basic parameter information through DHCP during the self-configuration process, it sends a SOS probe broadcast message; after receiving the neighboring base station, it has successfully obtained the basic configuration parameters. Responding to the above base station with a rescue response message; After receiving the base station, the base station selects one of the neighboring base stations that respond to the rescue source response message as the rescue base station, and requests the rescue base station to perform the DHCP request on behalf of the base station; the rescue base station sends the requested basic configuration parameters to the base station.
  • the self-healing method provided by the present invention includes the following steps:
  • Steps 201 to 202 The base station is powered on, and sends a DHCP request to the DHCP server, where the DHCP request carries the unique identification information of the base station.
  • the unique identifier information of the base station is an identifier that can represent the entire device asset information of the base station, and the base station carries the unique identifier information in the DHCP option 61, that is, the client-identifier that carries the unique identifier of the DHCP client. Perform a DHCP request and interact with the DHCP server to obtain basic configuration parameter information.
  • Step 203 Is the DHCP request successful? If the DHCP request fails, go to step 204, otherwise, go to step 215;
  • Step 204 The base station sends a SOS detection broadcast message to perform a salvage detection, and starts a wait response timer, and sets an operation state value of the base station to indicate that the waiting for rescue state is entered; as shown in FIG. 3:
  • Step 301 The neighboring base station receives the help probe broadcast message sent by the helper base station.
  • Step 302 the neighboring base station determines whether it satisfies the condition of the rescue base station, that is, whether it has obtained the basic configuration parameters, if the condition as the rescue base station is satisfied, step 303 is performed, otherwise step 305 is performed;
  • Step 303 The neighboring base station records its own identification label.
  • Step 304 The neighboring base station sends a rescue response broadcast message carrying its own identification tag information to the base station to perform a rescue response, and the partial operation of the adjacent base station ends;
  • Step 305 Discard the help probe broadcast message, and the part of the operation is terminated by the neighboring base station.
  • the identifier label information of the neighboring base station is used to uniquely identify the neighboring base station, and the identifier label information may be an IP address or a hardware MAC address of the neighboring base station itself, or may be utilized.
  • a tag generated by a random number generation algorithm may also be a unique identifier of the neighboring base station itself, etc., wherein the unique identification information of the neighboring base station is basically pre-cured, such as an electronic serial number of the adjacent base station;
  • the neighboring base station in step 302 determines whether the condition of the base station as the rescue base station is: the neighboring base station determines whether it has successfully obtained basic parameter information including its own IP address, etc. from the DHCP server; if not, it considers It does not meet the conditions of the rescue base station itself; if it has succeeded, it considers itself to be a condition for the rescue base station.
  • Step 205 Determine whether the rescue base station receives the rescue response message sent by the neighboring base station before the waiting response timer expires. If the rescue response message is received, step 206 is performed, otherwise, step 204 is returned;
  • Step 206 Select a rescue base station according to the established policy, that is, select one of the neighboring base stations that send the rescue response message as the rescue base station;
  • Step 207 Send a broadcast message carrying the identifier label information of the selected rescue base station and the unique identifier information of the selected base station to the neighboring base station (ie, the rescue base station);
  • Step 208 Enter a state of waiting for basic configuration parameters.
  • Step 304 if the neighboring base station itself satisfies the condition as the rescue base station, it is a broadcast rescue response message, and other neighboring base stations in the non-waiting rescue state directly discard the processing after receiving the rescue response message, such as Steps 306 to 307 in FIG.
  • the method for the rescue base station to select the rescue base station may have multiple methods: for example, the neighboring base station corresponding to the first received rescue response message may be selected as the rescue base station; or all the rescue response messages received are received.
  • the neighboring base station with the largest or smallest source IP address of the selected packet is used as the rescue base station; and a neighboring base station may be randomly selected as the rescue base station in the received rescue response.
  • Step 308 The neighboring base station receives the identifier label information of the selected rescue base station and the unique identifier information of the rescue base station, which is sent by the requesting base station. Broadcast message, that is, the request for help message; Step 309, the neighboring base station determines whether it has recorded its own identification label, if it has not recorded the identification label, step 316 is performed, otherwise, step 310 is performed; Step 310: Obtain an identifier label of the rescue base station carried in the request message.
  • Step 311 The neighboring base station compares the acquired identification label of the rescue base station with its own identification label; if the identification label does not match, step 316 is performed; otherwise, if it is known that it is the rescue base station, step 312 is further performed;
  • Step 312 Acquire the unique identification information of the help-seeking base station in the received request message.
  • Step 313 The rescue base station carries the unique identification information of the help-seeking base station in the DHCP message option 61, and requests the rescue base station to perform a DHCP request.
  • Step 314 Perform message interaction with the DHCP server to complete the DHCP process.
  • Step 315 The selected rescue base station sends a broadcast message carrying the unique identification information of the help-seeking base station and the DHCP request result information of the help-seeking base station, and the neighboring base station ends the operation of the part. ;
  • the result of the request in the step 315 carries the identification information indicating that the DHCP request succeeds or fails.
  • the DHCP request result information also carries the basic configuration parameter information of the requested rescue base station.
  • Step 316 Discard the broadcast message directly, and the part of the operation is terminated by the neighboring base station.
  • Step 209 The helper base station receives a broadcast message that carries the help station base station unique identifier information and the help base station DHCP request result information sent by the rescue base station, and processes the result information.
  • Step 210 After receiving the foregoing message sent by the rescue base station, the help-seeking base station that is in the state of waiting for the basic configuration parameter extracts the unique identifier information of the base station carried in the message;
  • Step 211 The help base station compares the extracted base station unique identifier information with its unique identifier information to determine whether it matches. If the two do not match, the broadcast message is discarded; otherwise, step 212 is performed;
  • Step 212 Extract the DHCP result identification information.
  • Step 213 Determine whether the identifier indicates success. If the identifier indicates success, step 214 is performed, if the identifier indicates failure, step 217 is performed;
  • Step 214 Extract basic parameter configuration information including the IP address of the help base station itself; Step 215 216, perform configuration, perform a subsequent SON process, and end.
  • Step 217 The rescue base station determines whether the number of requests for help has reached a predetermined threshold, if not, Then, step 204 is performed again to start a new round of help-seeking action; otherwise, step 218 is performed; step 218, the rescue base station itself restarts, and after the startup, the basic configuration parameter request is performed, that is, step 202 is performed.
  • the selected rescue base station transmits a broadcast message carrying the unique identification information of the help base station and the DHCP request result information of the help base station, and if other neighboring base stations are in a non-waiting rescue state. Then, after receiving the configuration parameter information sent by the rescue base station, the discarding process is directly performed, as shown in step 317 to step 318 in FIG.
  • the device involved in the self-healing method provided by the present invention is implemented on a base station, and the base station can be either a help-seeking base station or a rescue base station, but the functional modules in the base station used in the base station are different, in this embodiment.
  • the base station is an overall device including the functions of the rescue base station and the rescue base station, as shown in the figure.
  • the base station includes the following components: a dynamic host configuration protocol (DHCP) request module 401, a help probe transmission processing module 402, a help message receiving processing module 403, a rescue response sending processing module 404, a rescue response receiving processing module 405, The rescue request sending processing module 406, the rescue request receiving processing module 407, the basic parameter information transmitting module 408, and the basic parameter information acquiring module 409.
  • DHCP dynamic host configuration protocol
  • the DHCP requesting module 401 is configured to request the DHCP server to acquire the basic parameter information of the base station itself, and is further configured to send, as a module in the help requesting base station, the help probe sending processing module 402, when the basic parameter information fails to be acquired.
  • Sending a help-seeking command ; further configured to: when the base station serves as a rescue base station, request the basic parameter information of the help-seeking base station to the DHCP server instead of the help-seeking base station.
  • the help probe transmission processing module 402 is configured to send a rescue probe broadcast message after receiving the help command.
  • the help message receiving processing module 403 is configured to, after receiving the help probe broadcast message, determine that the basic configuration parameter has been successfully obtained,
  • the rescue response transmission processing module 404 initiates a rescue response command.
  • the rescue response sending processing module 404 is configured to send a rescue response message after receiving the rescue response command.
  • the rescue response receiving processing module 405 is configured to receive the rescue response message, select one of all neighboring base stations that reply to the rescue response message as a rescue base station, and notify the The rescue request is sent to the processing module 406.
  • the rescue request transmission processing module 406 is arranged to send a rescue request message to the rescue base station after receiving the above notification.
  • the rescue request receiving processing module 407 is configured to, after receiving the rescue request message, replace the basic data of the help request base station with the DHCP server instead of the help request base station. .
  • the basic parameter information sending module 408 is configured to send the requested basic configuration parameter information of the base station to the help substation base station.
  • the basic parameter information obtaining module 409 is configured to receive basic configuration parameter information sent by the basic parameter information sending module 408, when the base station is used as the calling base station.
  • the base station may further include a basic parameter information configuration module 410 configured to perform configuration of basic parameter information including the base station's own IP address.
  • the base station is divided into a helper base station and a neighboring base station to describe the functional modules therein, as shown in FIG. 5.
  • the method includes: a DHCP request module 510, a help probe transmission processing module 512, a rescue response receiving processing module 515, a rescue request transmission processing module 516, a basic parameter information obtaining module 519, and a basic parameter information configuration module 520.
  • the DHCP requesting module 510 is configured to: if the basic configuration parameter information of the base station itself is failed to be sent to the DHCP server, send a help command to the help probe sending processing module 512; the help probe sending processing module 512 is configured to: After receiving the help-seeking command, sending a help-seeking broadcast message to the neighboring base station; the rescue response receiving processing module 515 is configured to: receive a rescue response message broadcasted by the neighboring base station after receiving the help-seeking broadcast message, and One of the neighboring base stations broadcasting the rescue response message is selected as the rescue base station, and the rescue request transmission processing module 516 is notified; the rescue request transmission processing module 516 is configured to: receive the rescue response receiving processing module 515 After the notification, sending a rescue request message to the rescue base station; and the basic parameter information obtaining module 519 is configured to: receive the rescue base station according to The received rescue request message is the basic configuration parameter information of the help-seeking base station requested by the DHCP server.
  • the method includes: a DHCP request module 530, a help message receiving processing module 513, a rescue response sending processing module 514, a rescue request receiving processing module 517, a basic parameter information sending module 518, and a basic parameter information configuring module 540.
  • the DHCP requesting module 530 is configured to: request the DHCP server to obtain the basic parameter information of the base station itself; the help message receiving processing module 513 is configured to: after receiving the help probe broadcast message, if the user has successfully obtained the basic information
  • the configuration parameter sends a rescue response command to the rescue response sending processing module 514.
  • the rescue response sending processing module 514 is configured to: after receiving the rescue response command, broadcast a rescue response message to the rescue base station and other neighboring base stations.
  • the rescue request receiving processing module 517 is configured to: after receiving the rescue request message sent by the help requesting base station according to the rescue response message received by the help requesting base station, send a DHCP request to the DHCP requesting module 530; the DHCP request
  • the module 530 is further configured to: after receiving the DHCP request, request the basic configuration parameter information of the help-seeking base station to the DHCP server instead of the help-seeking base station; and the basic parameter information sending module 518 is configured to: The base of the help base station requested by the DHCP request module 530 Configuration parameter information transmitted to the base station for help.
  • the help probe transmission processing module is further configured to start a wait response timer when transmitting the help probe broadcast message.
  • the rescue response receiving processing module sends a heavy weight to the help probe sending processing module if the rescue response message is not received when the waiting response timer expires. Send a command.
  • the help probe sending processing module is configured to resend the help probe broadcast message after receiving the resend command.
  • the help probe sending processing module may be further configured to start a wait response timer; and if the wait response timer expires, the rescue response receiving processing module still does not receive the rescue response message. And resending the help probe broadcast message.
  • the rescue request message may carry unique identification information of the help base station.
  • the rescue request receiving processing module may be further configured to: after receiving the rescue request message, initiate a DHCP request to the DHCP server, where the unique identification information of the help requesting base station is carried.
  • the rescue response sending processing module may further be configured to add the identification label information of the base station itself to the rescue response message that is replied, and record the identification label information locally; wherein the identifier label information is used by Uniquely identifies the base station.
  • the rescue request message further carries identification tag information of the rescue base station.
  • the rescue request receiving processing module is configured to: after receiving the rescue request message, first determine whether the identification label information of the local base station has been recorded locally; if not, discard the rescue request message; otherwise, Whether the identification label information used to determine the local record is consistent with the identification label information carried in the rescue request message; if they are consistent, it is learned that it is the rescue base station, initiates the DHCP request to the DHCP server, and performs subsequent If the process is inconsistent, the rescue request message is discarded.
  • the help probe sending processing module may be further configured to set the running state value of the base station to indicate that it is in a waiting for rescue state when transmitting the help probe broadcast message.
  • the rescue response receiving processing module may be further configured to: after receiving the rescue response message, determine whether the running status value of the base station indicates that it is in a waiting state; if yes, perform a selection and subsequent process of the rescue base station; otherwise, Discard the rescue response message.
  • the first embodiment includes three base stations: base station A (newly powered base station), base station B (powered before base station A, has been operating normally), and base station C (powered after base station A).
  • base station A newly powered base station
  • base station B powered before base station A, has been operating normally
  • base station C powered after base station A.
  • the base station A is newly powered on, and performs initial startup; at this time, the base station B has successfully obtained the basic configuration parameter information, and obtains contact with the OMC, and operates normally; the base station C has not been powered on;
  • the base station A enters a self-healing process, starts a waiting rescue response timer, and enters a waiting for rescue state.
  • S604 The base station A sends a help probe broadcast message to the base station B and the base station C, and performs a help probe detection.
  • S605 Both the base station B and the base station C receive the help probe message sent by the base station A.
  • the base station B determines its own state and finds that it has successfully interacted with the DHCP server, that is, it can consider itself as a rescue base station, and the base station B uses its own MAC address as its own. Identification label (Note: In this example, the method of using its own MAC address as its own identification label) and recording and saving locally;
  • the base station C determines its own state, and finds that it has not successfully obtained the basic configuration parameter information from the DHCP server, and discards the help probe broadcast message;
  • the base station B sends a rescue response message including the identifier information of the own identity, and responds to the base station A.
  • the DHCP request process of the base station C ends, the DHCP request succeeds, the basic parameter information is configured, and the OMC is contacted, and the SON is followed.
  • the base station A receives the rescue response message sent by the base station B in the waiting time, extracts the identifier label of the base station B, and saves it, and selects the base station B as the rescue base station;
  • the base station C receives the rescue response message in a non-waiting rescue state and directly discards it.
  • the base station A sends a rescue request broadcast message carrying its own unique identification information and the identification information of the rescue base station B, and enters a waiting basic parameter configuration state;
  • the base station B receives the broadcast message sent by the base station A, and finds that the locality has the identification label information, so as to further extract the identification information of the rescue base station in the message, and compares it with its own identification label; the base station B finds that the identifier label matches. , confirming that it is the rescue base station, thereby further extracting the unique identification information of the rescue base station A and saving it locally;
  • the base station C receives the broadcast message that is sent by the base station A and contains the unique identifier information, and displays that the local device does not have the identifier information and discards the broadcast message.
  • the rescue base station B carries the unique identification information of the rescue base station A, interacts with the DHCP server, performs a DHCP request for the base station A, and the DHCP request succeeds;
  • the base station B sends a broadcast message carrying the unique identification information of the rescue base station A, the result information indicating that the DHCP request is successful, and the basic configuration parameter information of the requested base station A;
  • the rescue base station A receives the basic configuration parameter broadcast message sent by the rescue base station B while waiting for the basic configuration parameter state, first extracts the unique identification information of the base station, compares with the unique identification information of the base station, and the result matches; further extracts the DHCP request result information, Found that the request was successful, and then extracted Basic configuration parameter information;
  • the base station C receives the basic configuration parameter broadcast message in a non-waiting rescue state, and directly discards it;
  • the base station A completes the configuration according to the obtained basic configuration parameter information, and performs a SON subsequent process.
  • the present embodiment 2 includes four base stations: a base station A1 (new power-on base station), a base station A2 (new power-on base station), a base station D (new power-on base station, and power-on after base stations A1 and A2), and a base station E (new Power up the base station, and power up after base stations A1 and A2).
  • a base station A1 new power-on base station
  • a base station A2 new power-on base station
  • D new power-on base station, and power-on after base stations A1 and A2
  • a base station E new Power up the base station, and power up after base stations A1 and A2
  • S701 The base stations A1 and A2 are newly powered on, and the initial startup is performed; at this time, both the base station D and the base station E are not powered on;
  • the base stations A1 and A2 enter the self-healing process respectively, start the waiting response timer, and enter the waiting for rescue state.
  • the base stations A1 and A2 both send a help-seeking broadcast message to perform a salvage detection; at this time, the base station D and the base station E start to be powered on;
  • the base station D and the base station E receive the help probe messages sent by the base stations A1 and A2, determine their respective states, and find that they have not successfully obtained the basic configuration parameter information from the DHCP server, and discard the help probe broadcast message.
  • the base station A1 receives the help probe message sent by the base station A2, determines its own state, finds that it has not successfully obtained the basic configuration parameter information from the DHCP server, and discards the call for help broadcast message. Similarly, the base station A2 receives the call for help from the base station A1. Detecting a broadcast message and discarding the broadcast message;
  • S705 The base stations A1 and A2 both wait for timeout, do not receive any response message, are still waiting for the rescue state, restart the timer, and send the help probe broadcast message again;
  • the base station D and the base station E receive the help probe broadcast message sent by the base stations A1 and A2, determine their respective states, and find that they have successfully interacted with the DHCP server, and the judgment result considers itself It can be used as a rescue base station; base station D and base station E use their unique identification information as their own identification label (Note: in this example, the base station unique identifier is used as its own identification label) and record and save locally;
  • Each of the base stations A1 and A2 receives the call for help broadcast message of the other party, and discards the broadcast message directly because it has not succeeded in the DHCP request.
  • the base station A1 first receives the rescue response message sent by the base station D, extracts the identifier label information of the base station D, and saves it, and selects the base station D as the rescue base station. (Note: the base station corresponding to the rescue response that is the first to arrive is used as the rescue base station. Selecting a policy); the base station A1 receives the rescue response message sent by the base station E, and discards it;
  • the base station A2 first receives the rescue response message sent by the base station E, extracts the identification label information of the base station E and saves it, and selects the base station E as the rescue base station; the base station A2 receives the rescue response message sent by the base station D, and discards it;
  • the base station D receives the rescue response message sent by the base station E in the non-waiting rescue state, and directly discards it; likewise, the base station E receives the rescue response message sent by the base station D in the non-waiting rescue state, and directly discards it.
  • the base station A1 sends a broadcast message carrying its own unique identification information and the identifier information of the rescue base station D, and enters a waiting basic parameter configuration state;
  • the base station A2 sends a broadcast message carrying its own unique identification information and the identification information of the rescue base station E, and enters the waiting basic parameter configuration state.
  • the base station D receives the broadcast message sent by the base station A1, and finds that the locality has the identification label information, so as to further extract the rescue base station identification label information in the message, and compares it with its own identification label; the base station D finds that the identification label matches. Confirming that it is the rescue base station, thereby further extracting the unique identification information of the rescue base station A1 and storing it locally; the base station D receives the broadcast message sent by the base station A2, and checks that the local identification label information is found, thereby further extracting the information in the message. Rescuing the base station identification label information, compared with its own identification label; the base station D finds that the identification label does not match, discarding the broadcast message;
  • the base station E receives the broadcast message sent by the base station A2, and finds that it has local identification label information, so as to further extract the identification information of the rescue base station in the message, and compares it with its own identification label; the base station E finds that the identification label matches, confirms I am the rescue base station, which further Obtaining the unique identification information of the rescue base station A2 and storing it locally; the base station E receives the broadcast message sent by the base station A1, and finds that it has local identification label information, thereby further extracting the identification information of the rescue base station in the message, and its own The identification label is compared; the base station E finds that the identification label does not match, and discards the broadcast message;
  • the base stations A1 and A2 receive each other's broadcast messages carrying their own unique identification information and the identification information of the rescue base station identification labels, and view the discovery that they have no identification label information, and discard the broadcast message.
  • the base station D carries the unique identification information of the rescue base station A1, and interacts with the DHCP server to complete the DHCP interaction process, and the DHCP result fails.
  • the base station E carries the unique identification information of the rescue base station A2, and interacts with the DHCP server to complete the DHCP interaction process, and the DHCP result is successful.
  • the base station D sends a broadcast message carrying the unique identifier information of the help base station A1 and the failure information of the DHCP request result;
  • the base station E transmits a broadcast message carrying the unique identification information of the rescue base station A2, the success of the DHCP request result, and the basic configuration parameter information of the base station A2.
  • the rescue base station A1 receives the broadcast message containing the failure of the DHCP request result sent by the rescue base station D while waiting for the basic configuration parameter state, first extracts the unique identifier information of the base station, compares with the unique identification information of the base station, and the result matches; further extracts the DHCP request.
  • the result information the request is found to be unsuccessful; further determining whether the number of salvage times is reached (for example, the preset is 5 times), and the comparison finds that the value is less than the threshold value, and a new round of the rescue operation is performed;
  • the helper base station A1 receives the broadcast message containing the result of the DHCP request sent by the rescue base station E while waiting for the basic configuration parameter state, and first extracts the unique identifier information of the base station, and compares with the unique identifier information of the base station, the result does not match, and the broadcast message is directly discarded. ;
  • the helper base station A2 receives the broadcast message containing the result of the DHCP request successfully sent by the rescue base station E while waiting for the basic configuration parameter state, first extracts the unique identifier information of the base station, and compares with the unique identification information of the base station, and the result matches; further extracts the DHCP request result information. , the request is found to be successful, and then the basic configuration parameter information is extracted;
  • the helper base station A2 receives the broadcast message containing the result of the DHCP request sent by the rescue base station D while waiting for the basic configuration parameter state, and first extracts the unique identifier information of the base station, and the unique identifier of the base station. If the information is compared, the result does not match, and the broadcast message is directly discarded;
  • the rescue base station D and the rescue base station E respectively receive the broadcast message of the basic configuration parameter sent by the other party in the non-waiting rescue state, and directly discard it.
  • the base station A2 completes the configuration according to the obtained basic configuration parameter information, and performs a SON subsequent process.
  • the self-healing method of the DHCP request by the neighboring base station is provided as a basic premise of the base station SON self-configuration process, that is, the basic configuration parameter information including the base station's own IP address is provided.
  • the guarantee makes the subsequent SON process go smoothly, which greatly enhances the robustness of the base station itself and the self-organizing network.
  • the self-healing method for obtaining the basic configuration parameters and the base station by the base station self-configuration process of the present invention, the self-healing method for the DHCP request by the neighboring base station, the basic premise of the self-configuration process of the base station SON is the basic configuration parameter including the IP address of the base station itself.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

一种基站自配置过程获取基本配置参数的自愈方法及基站，所述方法包括：基站在自配置过程中若请求自身基本配置参数信息失败，则发送求救探测广播消息至邻接基站；邻接基站收到求救探测广播消息后，若自身已成功获得基本配置参数，则向所述基站及其他邻接基站广播救援响应消息；基站从广播所述救援响应消息的所有邻接基站中选择一个作为救援基站，并请求该救援基站代为向DHCP服务器请求所述基站的基本配置参数信息；救援基站将请求到的基站的基本配置参数信息发送给基站。采用本发明后，有利于减少人工干预，降低运营成本，可有效保证自配置过程以及后续SON过程的顺利进行，可极大地增强基站自身以及SON过程的鲁棒性。

Description

一种基站自配置过程获取基本配置参数的自愈方法及基站
技术领域
本发明涉及无线通信领域， 特别涉及长期演进（Long Term Evolution, 简 称 LTE ) 系统自组织网络中一种基站自配置过程获取基本配置参数的自愈方 法及基站。
背景技术
未来网络中， 不同网络共存将会使网络变得更加复杂。 大量无线参数和 数据的配置以及优化将会使网络规划和网络优化人员的工作变得更加繁杂， 而运营商则希望降低运营成本和人工干预。于是，在 LTE网络的标准化阶段， 由移动运营商主导提出了自组织网络（Self-organized Network, 简称 SON ) 的概念， 其主要思想是实现网络的一些自主功能以减少人工干预。 在这一背 景下,演进型通用移动通信系统( Universal Mobile Telecommunications System, 简称 UMTS ) 陆地无线接入网 （Evolved UMTS Terrestrial Radio Access Network, 简称 E-UTRAN )系统的 SON特性被作为第三代合作伙伴计划（ 3M Generation Partnership Proj ect , 简称 3 GPP ) 的重要研究方向之一。
LTE系统中的 SON具有自配置、 自优化、 自治愈和自规划四大功能。 自 配置和自优化过程的流程和实现的主要功能如图 1所示。 基站， 演进型节点 B ( Evolved Node B, 简称 eNB )上电后， 进入自配置即预运营状态， 顺序执 行 110:基本启动和 120:初始无线参数配置这 2个步骤，然后进入运营状态， 执行步骤 130: 优化与调整。 其中， 在自配置过程的 110: 基本启动阶段至少 包括： 111 : IP地址配置与操作维护中心 （Operation and Maintenance Center, 简称 OMC )服务器检测、 112: 节点的鉴权、 113: 建立与演进型分组核心网 ( Evolved Packet Core Network, 简称 EPC ) 的连接、 114: eNB软件以及运 行参数的下载等几个部分； 在自配置过程的 120: 初始无线参数配置阶段至 少包括： 121 : 相邻小区列表的建立及 122: 覆盖 /容量相关的参数配置等几个 部分； 在自优化过程的 130: 优化与调整阶段至少包括： 131 : 相邻小区列表 的优化及 132: 覆盖 /容量控制等几个部分。 当网络中新增一个节点时， 该节点首先要与 OMC服务器之间建立一个 初始的逻辑连接， 用于完成鉴权并获得正确连接到网络所需要的信息。 为了 与 OMC服务器之间建立初始连接， 该节点首先需要知道一些必要的基本参 数信息 , 如节点自身的 IP地址、 网关地址、域名系统（ Domain Name System, 简称 DNS )服务器地址等。 为了支持自配置和自优化功能， 这些基本参数信 息应该是动态获取的。 关于基本参数信息的获取方法， 目前基本上都是釆用 动态主机配置协议（ Dynamic Host Control Protocol, 简称 DHCP )来实现的。
包括节点， 如基站（ eNB ) , 自身 IP地址在内的基本参数信息的获取和 配置是基站自配置过程以及整个 SON过程最基本的前提。如果基本参数信息 获取失败， 后续 SON过程将无法进行， 且目前只能通过专业人员上站去排查 来解决问题， 耗时耗力。 因此， 自配置阶段的基本参数信息获取的鲁棒性就 成为基站 SON过程一个非常重要的方面。 发明内容
本发明要解决的技术问题是提供一种基站自配置过程获取基本配置参数 的自愈方法及基站， 以解决现有技术中基站在获取自身基本配置参数信息失 败后无法自动恢复的缺陷。
为解决上述问题， 本发明提供了一种基站自配置过程中获取基本配置参 数的自愈方法， 包括：
基站在自配置过程中若请求自身基本配置参数信息失败， 则发送求救探 测广播消息至邻接基站；
所述邻接基站接收到所述求救探测广播消息后， 若自身已成功获得基本 配置参数， 则向所述基站及其他邻接基站广播救援响应消息；
所述基站接收所有邻接基站的所述救援响应消息， 从广播所述救援响应 消息的所有邻接基站中选择一个作为救援基站， 并请求所述救援基站代为向 动态主机配置协议 DHCP服务器请求所述基站的基本配置参数信息；
所述救援基站将请求到的所述基站的基本配置参数信息发送给所述基 站。 优选地， 在所述邻接基站接收到所述求救探测广播消息的步骤之后， 还 可包括：
若所述邻接基站判断出自身还没有获得基本配置参数， 则丟弃所述求救 探测广播消息。
优选地， 所述基站发送求救探测广播消息的步骤还包括：
启动等待响应定时器；
若所述等待响应定时器超时仍未收到所述救援响应消息， 则重新发送所 述求救探测广播消息。
优选地， 所述基站从广播所述救援响应消息的所有邻接基站中选择一个 作为救援基站的步骤包括：
所述基站从广播所述救援响应消息的所有邻接基站中选择该基站最先接 收到所述救援响应消息对应的邻接基站作为救援基站； 或者，
所述基站从广播所述救援响应消息的所有邻接基站中选择该基站接收到 的所有救援响应消息的源 IP地址最大或最小的消息所对应的邻接基站作为救 援基站； 或者，
所述基站从广播所述救援响应消息的所有邻接基站中随机选择一个作为 救援基站。
优选地， 所述基站请求所述救援基站代为向 DHCP服务器请求所述基站 的基本配置参数信息的步骤包括：
所述基站发送救援请求消息， 其中携带所述基站的唯一标识信息； 所述救援基站收到所述救援请求消息后，向所述 DHCP服务器发起 DHCP 请求， 其中携带所述基站的唯一标识信息；
所述 DHCP服务器收到所述 DHCP请求后， 根据所述基站的唯一标识信 息为所述基站分配基本配置参数信息， 并将分配好的所述基本配置参数信息 发送给所述救援基站。
优选地， 所述邻接基站向所述基站及其他邻接基站广播救援响应消息的 步骤中还包括：在所述救援响应消息中添加该邻接基站自身的标识标签信息， 并在本地记录所述标识标签信息； 其中， 所述标识标签信息用于唯一标识所 述邻接基站； 则，
所述基站发送的所述救援请求消息中还携带所述救援基站的标识标签信 息；
在所述救援基站收到所述救援请求消息后， 向所述 DHCP服务器发起
DHCP请求的步骤包括：
判断本地是否已记录本基站的标识标签信息； 若未记录本基站的标识标 签信息， 则丟弃所述救援请求消息； 若记录有本基站的标识标签信息， 则判 断本地记录的标识标签信息与所述救援请求消息中携带的标识标签信息是否 一致； 若本地记录的标识标签信息与所述救援请求消息中携带的标识标签信 息一致， 则获知自身是所述救援基站， 向所述 DHCP服务器发起所述 DHCP 请求； 若本地记录的标识标签信息与所述救援请求消息中携带的标识标签信 息不一致， 则丟弃所述救援请求消息。
优选地， 所述基站发送求救探测广播消息的步骤还包括： 所述基站将自 身的运行状态值置为表示处于等待救援状态； 则， 还包括：
所述其他邻接基站在收到所述邻接基站广播的所述救援响应消息后， 判 断自身的运行状态值是否表示处于等待救援状态； 若自身的运行状态值是表 示处于等待救援状态， 则表示自身为求救基站， 进行救援基站的选择的步骤； 若自身的运行状态值不是表示处于等待救援状态，则丟弃所述救援响应消息。
优选地， 上述方法还包括：
所述基站预设求救次数阔值；
若所述救援基站代替所述基站请求基本配置参数失败， 则所述救援基站 向所述基站发送携带表示请求失败标识的通知消息；
所述基站收到所述通知消息后， 判断求救次数是否已达到所述求救次数 阔值； 若求救次数已达到所述求救次数阔值， 则所述基站重新启动， 并在重 新启动后进行所述自配置过程； 若求救次数未达到所述求救次数阔值， 则重 新执行发送所述求救探测广播消息的步骤。 本发明还提供了一种基站， 包括： 动态主机配置协议 DHCP请求模块、 求救探测发送处理模块、 求救消息接收处理模块、 救援响应发送处理模块、 救援响应接收处理模块、 救援请求发送处理模块、 救援请求接收处理模块、 基本参数信息发送模块及基本参数信息获取模块； 其中，
若所述基站作为求救基站， 则
所述 DHCP请求模块设置为： 若向 DHCP服务器请求本基站自身的基本 配置参数信息失败， 则向所述求救探测发送处理模块发送求救命令；
所述求救探测发送处理模块设置为： 在收到所述求救命令后， 发送求救 探测广播消息至邻接基站；
所述救援响应接收处理模块设置为： 接收所述邻接基站接收到所述求救 探测广播消息后广播的救援响应消息， 以及从广播所述救援响应消息的所有 邻接基站中选择一个作为救援基站， 并通知所述救援请求发送处理模块； 所述救援请求发送处理模块设置为： 在收到所述救援响应接收处理模块 的通知后， 向所述救援基站发送救援请求消息； 以及
所述基本参数信息获取模块设置为： 接收所述救援基站根据接收到的所 述救援请求消息代为向所述 DHCP服务器请求的所述求救基站的基本配置参 数信息；
若所述基站作为救援基站， 则
所述求救消息接收处理模块设置为： 在收到所述求救探测广播消息后， 若自身已成功获得基本配置参数， 则向所述救援响应发送处理模块发起救援 响应命令；
所述救援响应发送处理模块设置为： 在收到所述救援响应命令后， 向求 救基站及其他邻接基站广播救援响应消息；
所述救援请求接收处理模块设置为： 在收到所述求救基站根据其接收的 所述救援响应消息发送的救援请求消息后，向所述 DHCP请求模块发送 DHCP 请求；
所述 DHCP请求模块还设置为： 在收到所述 DHCP请求后， 代替所述求 救基站向所述 DHCP服务器请求所述求救基站的基本配置参数信息； 以及 所述基本参数信息发送模块设置为： 将所述 DHCP请求模块请求到的所 述求救基站的基本配置参数信息发送给所述求救基站。
优选地， 所述求救探测发送处理模块还设置为启动一等待响应定时器； 并且若检测到所述等待响应定时器超时， 所述救援响应接收处理模块仍 未收到所述救援响应消息， 则重新发送所述求救探测广播消息。
优选地 , 所述救援请求发送处理模块发送的所述救援请求消息中携带有 所述求 ：基站的唯一标识信息；
则， 所述救援请求接收处理模块还设置为在收到所述救援请求消息后， 向所述 DHCP服务器发起的所述 DHCP请求中携带所述求救基站的唯一标识 信息。
优选地， 所述救援响应发送处理模块还设置为： 在向求救基站及其他邻 接基站广播的所述救援响应消息中添加本基站自身的标识标签信息， 并在本 地记录所述标识标签信息； 其中， 所述标识标签信息用于唯一标识本基站； 则，
所述救援请求发送处理模块发送的所述救援请求消息中还携带所述救援 基站的标识标签信息；
所述救援请求接收处理模块是设置为： 在收到所述救援请求消息后， 判 断本地是否已记录本基站的标识标签信息；若未记录本基站的标识标签信息， 则丟弃所述救援请求消息； 若记录有本基站的标识标签信息， 则判断本地记 录的标识标签信息与所述救援请求消息中携带的标识标签信息是否一致； 若 本地记录的标识标签信息与所述救援请求消息中携带的标识标签信息一致， 则获知自身是所述救援基站， 向所述 DHCP服务器发起所述 DHCP请求； 若 本地记录的标识标签信息与所述救援请求消息中携带的标识标签信息不一 致， 则丟弃所述救援请求消息。
优选地， 所述求救探测发送处理模块还设置为将本基站的运行状态值置 为表示处于等待救援状态；
所述救援响应接收处理模块还设置为： 在收到所述邻接基站广播的所述 救援响应消息后， 判断本基站的运行状态值是否表示处于等待救援状态； 若 自身的运行状态值是表示处于等待救援状态， 则表示自身为求救基站， 进行 救援基站的选择的步骤； 若自身的运行状态值不是表示处于等待救援状态， 则丟弃所述救援响应消息。
釆用本发明后， 有利于减少人工干预， 降低运营成本， 可有效保证自配 置过程以及后续 SON过程的顺利进行， 可极大地增强基站自身以及 SON过 程的鲁棒性。 附图概述
图 1为现有技术中基站 SON自配置和自优化过程示意图；
图 2本发明实施例中基站自配置过程获取基本配置参数的自愈方法流程 图；
图 3为本发明实施例中邻接基站的处理流程图；
图 4为本发明实施例中能实现自愈功能的基站结构图；
图 5为本发明实施例中能实现自愈功能的基站的另一结构图；
图 6为本发明应用实例 1的流程示意图；
图 7为本发明应用实例 2的流程示意图。 本发明的较佳实施方式
本发明具体实施方式的描述， 涉及一个 LTE自组织网络系统， 至少包括
DHCP服务器（DHCP Server ) 、 OMC服务器以及多个基站。 其中涉及到基 站和 DHCP服务器以及 OMC服务器之间的交互过程， 但是并非本发明的重 点， 因此只进行非常简要的描述或者只是提及； 主要通过多个基站之间的交 互过程进一步说明本发明中的自配置过程自愈方法。
本发明所述方法的基本构思是： 基站在自配置过程中若通过 DHCP请求 自身基本参数信息失败， 则发送求救探测广播消息； 邻接基站收到后， 在自 身已成功获得基本配置参数的前提下， 向上述基站回复救援响应消息； 上述 基站收到后， 从上述回复救源响应消息的所有邻接基站中选择一个作为救援 基站， 并请求该救援基站代为进行 DHCP请求； 该救援基站将代为请求到的 基本配置参数发送给上述基站。
优选地， 如图 2所示， 结合如图 3所示的各邻接基站的处理流程， 本发 明提供的自愈方法包括如下步骤：
步骤 201~202、基站上电启动， 向 DHCP服务器发送 DHCP请求， DHCP 请求中携带该基站的唯一标识信息；
其中， 基站的唯一标识信息是指可以代表基站整个设备资产信息的一个 标识，基站在 DHCP选项 61 , 即用于携带 DHCP客户端唯一标识的客户端标 识（ Client-identifier )中携带该唯一标识信息进行 DHCP请求， 与 DHCP服务 器进行交互， 以获取基本配置参数信息。
步骤 203、 DHCP请求是否成功？ 如果 DHCP请求失败，则执行步骤 204 , 否则， 执行步骤 215;
步骤 204、 上述基站发送求救探测广播消息， 以进行求救探测， 并启动 等待响应定时器， 且将本基站的运行状态值设置为表示进入等待救援状态； 如图 3所示：
步骤 301、 邻接基站收到求救基站发送的求救探测广播消息；
步骤 302、 邻接基站判断自身是否满足作为救援基站的条件， 即其自身 是否已获得基本配置参数， 如果满足作为救援基站的条件， 则执行步骤 303 , 否则执行步骤 305;
步骤 303、 邻接基站记录自身标识标签；
步骤 304、 邻接基站发送携带自身标识标签信息的救援响应广播消息至 上述基站进行救援响应， 邻接基站该部分操作结束；
步骤 305、 丟弃该求救探测广播消息， 邻接基站该部分操作结束。
其中， 邻接基站的标识标签信息用于唯一的标识出该邻接基站， 该标识 标签信息可以是该邻接基站自身的 IP地址或硬件 MAC地址， 也可以是利用 某种随机数生成算法生成的一个标签， 也可以是该邻接基站自身唯一标识等 等； 其中， 邻接基站的唯一标识信息基本上是预先固化好的， 比如邻接基站 的电子序列号等；
优选地， 步骤 302中的邻接基站判断自身是否满足作为救援基站的条件 是指： 邻接基站判断自身是否已经从 DHCP服务器成功获取到包括自身的 IP 地址等的基本参数信息； 如果未成功， 则认为自身不满足作为救援基站的条 件； 如果已经成功， 则认为自身满足作为救援基站的条件。
步骤 205、 判断在等待响应定时器超时前， 求救基站是否收到邻接基站 发送的救援响应消息？ 如果收到救援响应消息， 则执行步骤 206, 否则， 返 回步骤 204;
步骤 206、 按照既定策略选择救援基站， 即从发送救援响应消息的邻接 基站中选出一个作为救援基站；
步骤 207、 发送携带所选择的救援基站的标识标签信息和自身唯一标识 信息的广播消息给邻接基站（即救援基站） ；
步骤 208、 进入等待基本配置参数状态；
由上述步骤 304可知， 邻接基站自身如果满足作为救援基站的条件， 其 是广播救援响应消息， 此时其他处于非等待救援状态的邻接基站， 在收到救 援响应消息后直接进行丟弃处理， 如图 3中的步骤 306至步骤 307。
在上述步骤 206中， 求救基站选择救援基站的策略可以有多种方法： 例 如可以选择最先接收到的救援响应报文对应的邻接基站作为救援基站； 或者 是在接收到的所有救援响应报文中选择发送的报文源 IP地址最大或者最小的 邻接基站作为救援基站； 也可以在接收到的救援响应中随机选择一个邻接基 站作为救援基站。
由于在上述步骤 207中求救基站发送的是广播消息， 因此如图 3所示： 步骤 308、 邻接基站收到求救基站发送的携带所选择的救援基站的标识 标签信息以及求救基站自身唯一标识信息的广播消息， 即求救请求消息； 步骤 309、 邻接基站判断自身是否记录有其自身的标识标签， 如果自身 没有记录过标识标签， 则执行步骤 316, 否则， 执行步骤 310; 步骤 310、 获取上述请求消息中携带的救援基站的标识标签；
步骤 311、 邻接基站将获取的救援基站的标识标签与自身的标识标签相 比较； 如果标识标签不匹配， 则执行步骤 316; 否则， 得知自己就是救援基 站， 则进一步执行步骤 312;
步骤 312、 获取接收到的请求消息中的求救基站的唯一标识信息； 步骤 313、救援基站在 DHCP报文选项 61中携带求救基站的唯一标识信 息， 代求救基站进行 DHCP请求；
步骤 314、 和 DHCP服务器之间进行消息交互， 完成 DHCP过程； 步骤 315、 被选定的该救援基站发送携带求救基站唯一标识信息和求救 基站 DHCP请求结果信息的广播消息， 邻接基站该部分操作结束；
该步骤 315中的该请求结果中携带表示 DHCP请求成功或失败的标识信 息， 此外， 如请求成功， 该 DHCP请求结果信息中还携带请求到的求救基站 的基本配置参数信息。
步骤 316、 直接丟弃该广播消息， 邻接基站该部分操作结束。
步骤 209、 求救基站接收救援基站发送的携带求救基站唯一标识信息和 求救基站 DHCP请求结果信息的广播消息， 对结果信息进行处理；
步骤 210、 处于等待基本配置参数状态的求救基站在收到救援基站发送 的上述消息后， 提取该消息中携带的基站唯一标识信息；
步骤 211、 该求救基站将提取的基站唯一标识信息和自身的唯一标识信 息相比较， 判断是否匹配？ 如果二者不匹配， 则丟弃该广播消息； 否则， 执 行步骤 212;
步骤 212、 提取出 DHCP结果标识信息；
步骤 213、 判断该标识是否表示成功？ 如果该标识表示成功， 则执行步 骤 214, 如果标识表示失败， 则执行步骤 217;
步骤 214、 提取出包括求救基站自身 IP地址在内的基本参数配置信息； 步骤 215 216、 进行配置， 进行后续 SON过程， 结束。
步骤 217、 求救基站判断其求救次数是否已到达预定阔值， 如果没有， 则重新执行步骤 204, 以开始进行新一轮的求救动作； 否则， 执行步骤 218; 步骤 218、 求救基站自身进行重启， 并在启动后自行进行基本配置参数 的请求， 即执行步骤 202。
如图 3所示， 由上述步骤 315可知， 被选定的该救援基站发送的是携带 求救基站唯一标识信息和求救基站 DHCP请求结果信息的广播消息， 此时如 果其他邻接基站在非等待救援状态， 则收到救援基站发送的该配置参数信息 后， 直接进行丟弃处理， 如图 3中的步骤 317至步骤 318。
此外， 本发明提供的自愈方法涉及的装置是在一个基站上实现的， 该基 站既可以是求救基站又可以是救援基站， 只是其所用到的基站中的功能模块 不同， 本实施例中的基站是包括求救基站和救援基站功能的整体装置， 如图
4所示，该基站包含如下组成部分：动态主机配置协议（DHCP )请求模块 401、 求救探测发送处理模块 402、 求救消息接收处理模块 403、救援响应发送处理 模块 404、 救援响应接收处理模块 405、 救援请求发送处理模块 406、 救援请 求接收处理模块 407、 基本参数信息发送模块 408及基本参数信息获取模块 409。
所述 DHCP请求模块 401设置为向 DHCP服务器请求获取所述基站自身 的基本参数信息； 还设置为在获取所述基本参数信息失败时， 作为求救基站 中的模块向所述求救探测发送处理模块 402发送求救命令； 还设置为在所述 基站作为救援基站时， 代替求救基站向所述 DHCP服务器请求所述求救基站 的基本参数信息。
所述求救探测发送处理模块 402设置为在收到所述求救命令后， 发送求 救探测广播消息。
当所述基站作为所述求救基站的邻接基站时， 所述求救消息接收处理模 块 403设置为在收到所述求救探测广播消息后， 在判断出自身已成功获得基 本配置参数的前提下，向所述救援响应发送处理模块 404发起救援响应命令。
所述救援响应发送处理模块 404设置为在收到所述救援响应命令后， 对 外发送救援响应消息。 当所述基站作为所述求救基站时， 所述救援响应接收处理模块 405设置 为接收所述救援响应消息， 从回复所述救援响应消息的所有邻接基站中选择 一个作为救援基站， 且通知所述救援请求发送处理模块 406。
救援请求发送处理模块 406设置为在收到上述通知后， 向所述救援基站 发送救援请求消息。
当所述基站作为所述救援基站时， 所述救援请求接收处理模块 407设置 为在收到所述救援请求消息后， 代替所述求救基站向所述 DHCP服务器请求 所述求救基站的基本参数信息。
当所述基站作为所述救援基站时， 所述基本参数信息发送模块 408设置 为将请求到的所述基站的基本配置参数信息发送给所述求救基站。
当所述基站作为所述求救基站时， 所述基本参数信息获取模块 409设置 为接收所述基本参数信息发送模块 408发来的基本配置参数信息。
在该基站中还可以包括基本参数信息配置模块 410, 其设置为负责完成 包括基站自身 IP地址在内的基本参数信息的配置。
具体地， 为了更加清楚地说明该基站的组成， 将基站分为求救基站和邻 接基站对其中的功能模块进行描述， 如图 5所示。
若上述基站作为求救基站， 则包括： DHCP请求模块 510、 求救探测发送 处理模块 512、 救援响应接收处理模块 515、 救援请求发送处理模块 516、 基 本参数信息获取模块 519及基本参数信息配置模块 520。
所述 DHCP请求模块 510设置为： 若向 DHCP服务器请求本基站自身的 基本配置参数信息失败，则向所述求救探测发送处理模块 512发送求救命令； 所述求救探测发送处理模块 512设置为： 在收到所述求救命令后， 发送求救 探测广播消息至邻接基站； 所述救援响应接收处理模块 515设置为： 接收所 述邻接基站接收到所述求救探测广播消息后广播的救援响应消息， 以及从广 播所述救援响应消息的所有邻接基站中选择一个作为救援基站， 并通知所述 救援请求发送处理模块 516; 所述救援请求发送处理模块 516设置为： 在收 到所述救援响应接收处理模块 515的通知后， 向所述救援基站发送救援请求 消息； 以及所述基本参数信息获取模块 519设置为： 接收所述救援基站根据 接收到的所述救援请求消息代为向所述 DHCP服务器请求的所述求救基站的 基本配置参数信息。
若上述基站作为救援基站， 则包括： DHCP请求模块 530、 求救消息接收 处理模块 513、 救援响应发送处理模块 514、 救援请求接收处理模块 517、 基 本参数信息发送模块 518及基本参数信息配置模块 540。
所述 DHCP请求模块 530设置为： 向 DHCP服务器请求获取本基站自身 的基本参数信息； 所述求救消息接收处理模块 513设置为： 在收到所述求救 探测广播消息后， 若自身已成功获得基本配置参数， 则向所述救援响应发送 处理模块 514发起救援响应命令； 所述救援响应发送处理模块 514设置为： 在收到所述救援响应命令后，向求救基站及其他邻接基站广播救援响应消息； 所述救援请求接收处理模块 517设置为： 在收到所述求救基站根据其接收的 所述救援响应消息发送的救援请求消息后， 向所述 DHCP请求模块 530发送 DHCP请求； 所述 DHCP请求模块 530还设置为： 在收到所述 DHCP请求后， 代替所述求救基站向所述 DHCP服务器请求所述求救基站的基本配置参数信 息；以及所述基本参数信息发送模块 518设置为：将所述 DHCP请求模块 530 请求到的所述求救基站的基本配置参数信息发送给所述求救基站。 结合上述图 4与图 5所示的基站， 还包括如下优选的功能设置。
优选地， 所述求救探测发送处理模块还设置为在发送所述求救探测广播 消息时， 启动一等待响应定时器。 当所述基站作为所述求救基站时， 所述救 援响应接收处理模块若在所述等待响应定时器超时时， 仍未收到所述救援响 应消息， 则向所述求救探测发送处理模块发送重发命令。 所述求救探测发送 处理模块用于在收到重发命令后， 重新发送所述求救探测广播消息。
更优选地， 所述求救探测发送处理模块还可以设置为启动一等待响应定 时器； 并且若检测到所述等待响应定时器超时， 所述救援响应接收处理模块 仍未收到所述救援响应消息， 则重新发送所述求救探测广播消息。
此外， 所述救援请求消息中可携带有所述求救基站的唯一标识信息。 救 援请求接收处理模块还可以设置为在收到所述救援请求消息后， 向所述 DHCP服务器发起 DHCP请求， 其中携带所述求救基站的唯一标识信息。 优选地， 所述救援响应发送处理模块还可以设置为在回复的所述救援响 应消息中添加本基站自身的标识标签信息，并在本地记录所述标识标签信息； 其中， 所述标识标签信息用于唯一的标识本基站。 所述救援请求消息中还携 带有所述救援基站的标识标签信息。
那么， 所述救援请求接收处理模块用于在收到所述救援请求消息后， 首 先判断本地是否已记录本基站的标识标签信息； 如未记录， 则丟弃所述救援 请求消息； 否则， 还用于判断本地记录的标识标签信息与所述救援请求消息 中携带的标识标签信息是否一致； 若一致， 则获知自身是所述救援基站， 向 所述 DHCP服务器发起所述 DHCP请求， 并执行后续流程； 若不一致， 则丟 弃所述救援请求消息。
所述求救探测发送处理模块还可设置为在发送所述求救探测广播消息 时， 将本基站的运行状态值置为表示处于等待救援状态。
所述救援响应接收处理模块还可设置为在收到所述救援响应消息后， 判 断本基站的运行状态值是否表示处于等待救援状态； 若是， 则进行救援基站 的选择及后续流程； 否则， 丟弃所述救援响应消息。
下面， 用本发明的两个应用实例进行进一步说明。
应用实例 1 :
本实施 1中包括 3个基站： 基站 A (新上电的基站 ) , 基站 B (在基站 A 之前上电， 已经正常运行） ， 基站 C (在基站 A之后上电） 。 下面通过本发 明的应用实例 1 , 并结合图 6对本发明的技术方案进行进一步说明。
S601 : 基站 A新上电， 进行初始启动； 此时基站 B已经成功获取基本配 置参数信息， 并和 OMC取得联系， 正常运行； 基站 C尚未上电；
S602: 基站 A与 DHCP服务器之间进行消息交互， DHCP结果失败； 此 时基站 C开始上电启动；
S603: 基站 A进入自愈流程， 启动等待救援响应定时器， 进入等待救援 状态。
S604:基站 A向基站 B和基站 C发送求救探测广播消息，进行求救探测； S605: 基站 B和基站 C均收到基站 A发送的求救探测消息； 基站 B判断自身状态， 发现自己已经和 DHCP服务器成功交互， 即认为 自己可以作为救援基站，则基站 B利用自身 MAC地址作为自身标识标签（注： 此例中釆用自身 MAC地址作为自身标识标签的方法）并在本地进行记录保 存；
基站 C判断自身状态， 发现自己尚未从 DHCP服务器成功获取基本配置 参数信息， 则丟弃该求救探测广播消息；
S606: 基站 B发送包含自身标识标签信息的救援响应消息， 对基站 A进 行响应； 并且此时基站 C 的 DHCP请求过程结束， DHCP请求成功， 配置基 本参数信息， 并和 OMC取得联系， 进行 SON后续过程；
S607: 基站 A在等待时间内收到基站 B发送的救援响应消息， 从中提取 基站 B的标识标签并进行保存， 选定基站 B作为救援基站；
基站 C在非等待救援状态收到该救援响应消息， 直接丟弃。
S608:基站 A发送携带自身唯一标识信息和救援基站 B标识标签信息的 救援请求广播消息， 进入等待基本参数配置状态；
S609: 基站 B收到基站 A发送的广播消息， 查看发现自己本地有标识标 签信息， 从而进一步提取该消息中的救援基站标识标签信息， 和自己的标识 标签相比对； 基站 B发现标识标签匹配， 确认自己就是救援基站， 从而进一 步提取求救基站 A的唯一标识信息并在本地进行保存；
基站 C收到基站 A发送的包含其唯一标识信息的广播消息， 查看发现自 己本地没有标识标签信息， 直接丟弃该广播消息。
S610: 救援基站 B携带求救基站 A的唯一标识信息， 与 DHCP服务器之 间进行交互， 为基站 A进行 DHCP请求， 且 DHCP请求成功；
S611 : 基站 B发送携带有求救基站 A唯一标识信息、表示 DHCP请求成 功的结果信息以及请求到的基站 A基本配置参数信息的广播消息；
S612: 求救基站 A在等待基本配置参数状态收到救援基站 B发送的基本 配置参数广播消息， 先提取基站唯一标识信息， 与自己的唯一标识信息相比 较， 结果匹配； 进一步提取 DHCP请求结果信息， 发现请求成功， 进而提取 基本配置参数信息；
基站 C在非等待救援状态收到该基本配置参数广播消息， 直接丟弃；
S613: 基站 A根据获取到的基本配置参数信息完成配置， 进行 SON后 续过程。
应用实例 2:
本实施 2中包括 4个基站： 基站 A1 (新上电基站） ， 基站 A2 (新上电 基站 ) ,基站 D (新上电基站， 而且在基站 A1和 A2之后上电 ) , 基站 E (新 上电基站， 而且在基站 A1和 A2之后上电）。 下面通过本发明的应用实例 2, 并结合图 7对本发明的内容进行进一步说明。
S701 : 基站 A1和 A2新上电， 进行初始启动； 此时基站 D和基站 E均 未上电；
S702: 基站 A1和 A2与 DHCP服务器之间进行消息交互， DHCP结果 均失败；
S703: 基站 A1和 A2分别进入自愈流程， 启动等待响应定时器， 进入等 待救援状态。 基站 A1和 A2均发送求救探测广播消息， 进行求救探测； 此时 基站 D和基站 E开始上电启动；
S704: 基站 D和基站 E收到基站 A1和 A2发送的求救探测消息， 判断 各自的状态， 发现自己尚未从 DHCP服务器成功获取基本配置参数信息， 均 丟弃该求救探测广播消息；
基站 A1收到基站 A2发送的求救探测消息， 判断自身的状态， 发现自己 尚未从 DHCP服务器成功获取基本配置参数信息，丟弃该求救探测广播消息； 同理， 基站 A2收到基站 A1发送的求救探测广播消息， 亦丟弃该广播消息；
S705: 基站 A1和 A2均等待超时， 未收到任何响应消息， 仍处于等待救 援状态， 重新启动定时器， 再次发送求救探测广播消息；
S706: 此时， 基站 D和基站 E均完成与 DHCP服务器的交互， 成功获取 各自的基本配置参数信息， 并已进行配置， 正常运行；
S707: 基站 D和基站 E收到基站 A1和 A2发送的求救探测广播消息， 判断各自状态， 发现自己已经和 DHCP服务器成功交互， 判断结果认为自己 可以作为救援基站； 基站 D和基站 E利用自身唯一标识信息作为自身标识标 签（注： 此例中釆用基站唯一标识作为自身标识标签）并在本地进行记录保 存；
基站 A1和 A2各自收到对方的求救探测广播消息， 因为自身尚未 DHCP 请求成功， 均直接丟弃该广播消息。
S708: 基站 D和基站 E均发送携带自身标识标签信息的救援响应消息；
S709: 基站 A1先收到基站 D发送的救援响应消息， 提取基站 D的标识 标签信息并保存， 选择基站 D作为救援基站（注： 釆用选取最先到达的救援 响应对应的基站作为救援基站的选择策略） ； 基站 A1收到基站 E发送的救 援响应消息， 进行丟弃；
基站 A2先收到基站 E发送的救援响应消息， 提取基站 E的标识标签信 息并保存， 选择基站 E作为救援基站； 基站 A2收到基站 D发送的救援响应 消息， 进行丟弃；
基站 D在非等待救援状态收到基站 E发送的救援响应消息， 直接丟弃； 同样，基站 E在非等待救援状态收到基站 D发送的救援响应消息，直接丟弃。
S710: 基站 A1发送携带自身唯一标识信息和救援基站 D标识标签信息 的广播消息， 进入等待基本参数配置状态；
基站 A2发送携带自身唯一标识信息和救援基站 E标识标签信息的广播 消息， 进入等待基本参数配置状态。
S711 : 基站 D收到基站 A1发送的广播消息， 查看发现自己本地有标识 标签信息， 从而进一步提取该消息中的救援基站标识标签信息， 和自己的标 识标签相比对； 基站 D发现标识标签匹配， 确认自己就是救援基站， 从而进 一步提取求救基站 A1的唯一标识信息并在本地进行保存； 基站 D收到基站 A2发送的广播消息， 查看发现自己本地有标识标签信息， 从而进一步提取该 消息中的救援基站标识标签信息， 和自己的标识标签相比对； 基站 D发现标 识标签不匹配， 丟弃该广播消息；
基站 E收到基站 A2发送的广播消息， 查看发现自己本地有标识标签信 息， 从而进一步提取该消息中的救援基站标识标签信息， 和自己的标识标签 相比对； 基站 E发现标识标签匹配， 确认自己就是救援基站， 从而进一步提 取求救基站 A2的唯一标识信息并在本地进行保存；基站 E收到基站 A1发送 的广播消息， 查看发现自己本地有标识标签信息， 从而进一步提取该消息中 的救援基站标识标签信息， 和自己的标识标签相比对； 基站 E发现标识标签 不匹配， 丟弃该广播消息；
基站 A1和 A2互相收到对方发送的携带有自身唯一标识信息和救援基站 标识标签信息的广播消息， 查看发现自身无标识标签信息， 均丟弃该广播消 息。
S712: 基站 D携带求救基站 A1的唯一标识信息， 与 DHCP服务器之间 进行交互， 完成 DHCP交互过程， DHCP结果失败；
基站 E携带求救基站 A2的唯一标识信息， 与 DHCP服务器之间进行交 互， 完成 DHCP交互过程， DHCP结果成功。
S713: 基站 D发送携带有求救基站 A1唯一标识信息以及 DHCP请求结 果失败信息的广播消息；
基站 E发送携带有求救基站 A2唯一标识信息、 DHCP请求结果成功以及 基站 A2基本配置参数信息的广播消息。
S714: 求救基站 A1在等待基本配置参数状态收到救援基站 D发送的包 含 DHCP请求结果失败的广播消息， 先提取基站唯一标识信息， 与自己的唯 一标识信息相比较， 结果匹配； 进一步提取 DHCP请求结果信息， 发现请求 失败； 进一步判断是否达到求救次数阔值（例如， 预置为 5次） ， 比较发现 小于阔值， 进行新一轮的求救动作；
求救基站 A1在等待基本配置参数状态收到救援基站 E发送的包含 DHCP 请求结果的广播消息， 先提取基站唯一标识信息， 与自己的唯一标识信息相 比较， 结果不匹配， 直接丟弃该广播消息；
求救基站 A2在等待基本配置参数状态收到救援基站 E发送的包含 DHCP 请求结果成功的广播消息， 先提取基站唯一标识信息， 与自己的唯一标识信 息相比较， 结果匹配； 进一步提取 DHCP请求结果信息， 发现请求成功， 进 而提取基本配置参数信息；
求救基站 A2 在等待基本配置参数状态收到救援基站 D发送的包含 DHCP请求结果的广播消息， 先提取基站唯一标识信息， 与自己的唯一标识 信息相比较， 结果不匹配， 直接丟弃该广播消息；
救援基站 D和救援基站 E在非等待救援状态各自收到对方发送的该基本 配置参数广播消息， 直接丟弃。
S715: 基站 A2根据获取到的基本配置参数信息完成配置， 进行 SON后 续过程。
综上所述，本发明内容所述的通过邻接基站代为 DHCP请求的自愈方法， 为基站 SON 自配置过程的基本前提即包括基站自身 IP地址在内的基本配置 参数信息的获取提供了有力的保障， 使得后续 SON过程能够顺利进行， 极大 增强了基站自身以及自组织网络的鲁棒性。
本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序 来指令相关硬件完成， 所述程序可以存储于计算机可读存储介质中， 如只读 存储器、 磁盘或光盘等。 可选地， 上述实施例的全部或部分步骤也可以使用 一个或多个集成电路来实现。 相应地， 上述实施例中的各模块 /单元可以釆用 硬件的形式实现， 也可以釆用软件功能模块的形式实现。 本发明不限制于任 何特定形式的硬件和软件的结合。
工业实用性
本发明的基站自配置过程获取基本配置参数的自愈方法及基站， 通过邻 接基站代为 DHCP请求的自愈方法，为基站 SON自配置过程的基本前提即包 括基站自身 IP地址在内的基本配置参数信息的获取提供了有力的保障，使得 后续 SON过程能够顺利进行， 极大增强了基站自身以及自组织网络的鲁棒 性。

Claims

权 利 要 求 书
1、 一种基站自配置过程中获取基本配置参数的自愈方法， 包括： 基站在自配置过程中若请求自身基本配置参数信息失败， 则发送求救探 测广播消息至邻接基站；
所述邻接基站接收到所述求救探测广播消息后， 若自身已成功获得基本 配置参数， 则向所述基站及其他邻接基站广播救援响应消息；
所述基站接收所有邻接基站的所述救援响应消息， 从广播所述救援响应 消息的所有邻接基站中选择一个作为救援基站， 并请求所述救援基站代为向 动态主机配置协议 DHCP服务器请求所述基站的基本配置参数信息；
所述救援基站将请求到的所述基站的基本配置参数信息发送给所述基 站。
2、 如权利要求 1所述的方法， 其中， 在所述邻接基站接收到所述求救探 测广播消息的步骤之后， 还包括：
若所述邻接基站判断出自身还没有获得基本配置参数， 则丟弃所述求救 探测广播消息。
3、 如权利要求 1所述的方法， 其中， 所述基站发送求救探测广播消息的 步骤还包括：
启动等待响应定时器；
若所述等待响应定时器超时仍未收到所述救援响应消息， 则重新发送所 述求救探测广播消息。
4、 如权利要求 1所述的方法， 其中， 所述基站从广播所述救援响应消息 的所有邻接基站中选择一个作为救援基站的步骤包括：
所述基站从广播所述救援响应消息的所有邻接基站中选择该基站最先接 收到所述救援响应消息对应的邻接基站作为救援基站； 或者，
所述基站从广播所述救援响应消息的所有邻接基站中选择该基站接收到 的所有救援响应消息的源 IP地址最大或最小的消息所对应的邻接基站作为救 援基站； 或者， 所述基站从广播所述救援响应消息的所有邻接基站中随机选择一个作为 救援基站。
5、 如权利要求 1至 4任一项所述的方法， 其中， 所述基站请求所述救援 基站代为向 DHCP服务器请求所述基站的基本配置参数信息的步骤包括： 所述基站发送救援请求消息， 其中携带所述基站的唯一标识信息； 所述救援基站收到所述救援请求消息后，向所述 DHCP服务器发起 DHCP 请求， 其中携带所述基站的唯一标识信息；
所述 DHCP服务器收到所述 DHCP请求后， 根据所述基站的唯一标识信 息为所述基站分配基本配置参数信息， 并将分配好的所述基本配置参数信息 发送给所述救援基站。
6、 如权利要求 5所述的方法， 其中，
所述邻接基站向所述基站及其他邻接基站广播救援响应消息的步骤中还 包括： 在所述救援响应消息中添加该邻接基站自身的标识标签信息， 并在本 地记录所述标识标签信息； 其中， 所述标识标签信息用于唯一标识所述邻接 基站； 则，
所述基站发送的所述救援请求消息中还携带所述救援基站的标识标签信 息；
在所述救援基站收到所述救援请求消息后， 向所述 DHCP服务器发起 DHCP请求的步骤包括：
判断本地是否已记录本基站的标识标签信息； 若未记录本基站的标识标 签信息， 则丟弃所述救援请求消息； 若记录有本基站的标识标签信息， 则判 断本地记录的标识标签信息与所述救援请求消息中携带的标识标签信息是否 一致； 若本地记录的标识标签信息与所述救援请求消息中携带的标识标签信 息一致， 则获知自身是所述救援基站， 向所述 DHCP服务器发起所述 DHCP 请求； 若本地记录的标识标签信息与所述救援请求消息中携带的标识标签信 息不一致， 则丟弃所述救援请求消息。
7、 如权利要求 1至 4任一项所述的方法， 其中， 所述基站发送求救探测 广播消息的步骤还包括： 所述基站将自身的运行状态值置为表示处于等待救 援状态； 则， 还包括：
所述其他邻接基站在收到所述邻接基站广播的所述救援响应消息后， 判 断自身的运行状态值是否表示处于等待救援状态； 若自身的运行状态值是表 示处于等待救援状态， 则表示自身为求救基站， 进行救援基站的选择的步骤； 若自身的运行状态值不是表示处于等待救援状态，则丟弃所述救援响应消息。
8、 如权利要求 1所述的方法， 还包括：
所述基站预设求救次数阔值；
若所述救援基站代替所述基站请求基本配置参数失败， 则所述救援基站 向所述基站发送携带表示请求失败标识的通知消息；
所述基站收到所述通知消息后， 判断求救次数是否已达到所述求救次数 阔值； 若求救次数已达到所述求救次数阔值， 则所述基站重新启动， 并在重 新启动后进行所述自配置过程； 若求救次数未达到所述求救次数阔值， 则重 新执行发送所述求救探测广播消息的步骤。
9、 一种基站， 包括： 动态主机配置协议 DHCP请求模块、 求救探测发送 处理模块、 求救消息接收处理模块、 救援响应发送处理模块、 救援响应接收 处理模块、 救援请求发送处理模块、 救援请求接收处理模块、 基本参数信息 发送模块及基本参数信息获取模块； 其中，
若所述基站作为求救基站， 则
所述 DHCP请求模块设置为： 若向 DHCP服务器请求本基站自身的基本 配置参数信息失败， 则向所述求救探测发送处理模块发送求救命令；
所述求救探测发送处理模块设置为： 在收到所述求救命令后， 发送求救 探测广播消息至邻接基站；
所述救援响应接收处理模块设置为： 接收所述邻接基站接收到所述求救 探测广播消息后广播的救援响应消息， 以及从广播所述救援响应消息的所有 邻接基站中选择一个作为救援基站， 并通知所述救援请求发送处理模块； 所述救援请求发送处理模块设置为： 在收到所述救援响应接收处理模块 的通知后， 向所述救援基站发送救援请求消息； 以及
所述基本参数信息获取模块设置为： 接收所述救援基站根据接收到的所 述救援请求消息代为向所述 DHCP服务器请求的所述求救基站的基本配置参 数信息；
若所述基站作为救援基站， 则
所述求救消息接收处理模块设置为： 在收到所述求救探测广播消息后， 若自身已成功获得基本配置参数， 则向所述救援响应发送处理模块发起救援 响应命令；
所述救援响应发送处理模块设置为： 在收到所述救援响应命令后， 向求 救基站及其他邻接基站广播救援响应消息；
所述救援请求接收处理模块设置为： 在收到所述求救基站根据其接收的 所述救援响应消息发送的救援请求消息后，向所述 DHCP请求模块发送 DHCP 请求；
所述 DHCP请求模块还设置为： 在收到所述 DHCP请求后， 代替所述求 救基站向所述 DHCP服务器请求所述求救基站的基本配置参数信息； 以及 所述基本参数信息发送模块设置为： 将所述 DHCP请求模块请求到的所 述求救基站的基本配置参数信息发送给所述求救基站。
10、 如权利要求 9所述的基站， 其中，
所述求救探测发送处理模块还设置为启动一等待响应定时器； 并且若检 测到所述等待响应定时器超时， 所述救援响应接收处理模块仍未收到所述救 援响应消息， 则重新发送所述求救探测广播消息。
11、 如权利要求 9所述的基站， 其中， 所述救援请求发送处理模块发送 的所述救援请求消息中携带有所述求救基站的唯一标识信息；
则， 所述救援请求接收处理模块还设置为在收到所述救援请求消息后， 向所述 DHCP服务器发起的所述 DHCP请求中携带所述求救基站的唯一标识 信息。
12、 如权利要求 11所述的基站， 其中，
所述救援响应发送处理模块还设置为： 在向求救基站及其他邻接基站广 播的所述救援响应消息中添加本基站自身的标识标签信息， 并在本地记录所 述标识标签信息； 其中， 所述标识标签信息用于唯一标识本基站； 则， 所述救援请求发送处理模块发送的所述救援请求消息中还携带所述救援 基站的标识标签信息；
所述救援请求接收处理模块是设置为： 在收到所述救援请求消息后， 判 断本地是否已记录本基站的标识标签信息；若未记录本基站的标识标签信息， 则丟弃所述救援请求消息； 若记录有本基站的标识标签信息， 则判断本地记 录的标识标签信息与所述救援请求消息中携带的标识标签信息是否一致； 若 本地记录的标识标签信息与所述救援请求消息中携带的标识标签信息一致， 则获知自身是所述救援基站， 向所述 DHCP服务器发起所述 DHCP请求； 若 本地记录的标识标签信息与所述救援请求消息中携带的标识标签信息不一 致， 则丟弃所述救援请求消息。
13、 如权利要求 9所述的基站， 其中，
所述求救探测发送处理模块还设置为将本基站的运行状态值置为表示处 于等待救援状态；
所述救援响应接收处理模块还设置为： 在收到所述邻接基站广播的所述 救援响应消息后， 判断本基站的运行状态值是否表示处于等待救援状态； 若 自身的运行状态值是表示处于等待救援状态， 则表示自身为求救基站， 进行 救援基站的选择的步骤； 若自身的运行状态值不是表示处于等待救援状态， 则丟弃所述救援响应消息。
PCT/CN2010/078775 2010-06-24 2010-11-16 一种基站自配置过程获取基本配置参数的自愈方法及基站 WO2011160385A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2010102130995A CN102300207A (zh) 2010-06-24 2010-06-24 一种基站自配置过程获取基本配置参数的自愈方法及基站
CN201010213099.5 2010-06-24

Publications (1)

Publication Number Publication Date
WO2011160385A1 true WO2011160385A1 (zh) 2011-12-29

Family

ID=45360305

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/078775 WO2011160385A1 (zh) 2010-06-24 2010-11-16 一种基站自配置过程获取基本配置参数的自愈方法及基站

Country Status (2)

Country Link
CN (1) CN102300207A (zh)
WO (1) WO2011160385A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104754629B (zh) * 2013-12-31 2020-01-07 中兴通讯股份有限公司 一种基站设备自愈的实现方法及装置
CN104185199B (zh) * 2014-08-25 2017-12-05 大唐移动通信设备有限公司 一种基站自启动及其控制方法及装置
CN112770360A (zh) * 2020-12-28 2021-05-07 浪潮软件科技有限公司 无线参数优化方法、装置和系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1983868A (zh) * 2005-12-14 2007-06-20 明基电通股份有限公司 用以传递救援讯息的无线通讯系统及其管理方法
CN101466105A (zh) * 2008-12-30 2009-06-24 上海无线通信研究中心 蜂窝系统中基站的自动配置方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE523051T1 (de) * 2007-02-06 2011-09-15 Ericsson Telefon Ab L M Verfahren und system für intra-e-utran-handover

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1983868A (zh) * 2005-12-14 2007-06-20 明基电通股份有限公司 用以传递救援讯息的无线通讯系统及其管理方法
CN101466105A (zh) * 2008-12-30 2009-06-24 上海无线通信研究中心 蜂窝系统中基站的自动配置方法

Also Published As

Publication number Publication date
CN102300207A (zh) 2011-12-28

Similar Documents

Publication Publication Date Title
CN112042259B (zh) 用于在无线通信系统中执行通信的方法和装置
JP6631818B2 (ja) Ｘ２−ゲートウェイを用いたトランスポートネットワーク層アドレス発見
JP5816696B2 (ja) ピアトゥピア通信を確立するための方法および装置
CN103428783B (zh) 支持检测rlf或者切换失败原因的方法
US9001716B2 (en) Apparatus and method for detecting cause of radio link failure or handover failure in mobile communication system
TWI450545B (zh) 通過相關資訊報告並處理失敗事件的方法和用戶設備
EP3994953B1 (en) Nas recovery in a wireless communication network
WO2018019001A1 (zh) 一种终端状态转换方法及装置
WO2014019131A1 (zh) 链路失败的恢复方法及装置
WO2016155261A1 (zh) 终端节电方法及装置
EP1832049A1 (en) Method and system for recovery from access point infrastructure link failures
JP2009253561A (ja) 移動局、移動交換局及び移動通信方法
JP2021522698A (ja) セルのグローバル識別情報の報告
JP2021505053A (ja) 隣接基地局関係を更新するための方法及び装置
CN114173431B (zh) 一种rrc连接释放的方法及装置
WO2012130133A1 (zh) 一种接入点及终端接入方法
WO2013113159A1 (zh) 无线连接恢复方法、移动通信系统、用户设备和基站
EP3804385A1 (en) Technique for updating cellular neighbor relations
WO2011160385A1 (zh) 一种基站自配置过程获取基本配置参数的自愈方法及基站
CN102256287B (zh) 确定家庭基站在线状态的方法及系统
JP2003318943A (ja) Ｉｐアドレス生成方法及び無線基地局装置
US20230042022A1 (en) Method for channel switching in wireless mesh network, and wireless device
WO2015043289A1 (zh) 一种基站与x2网关交互的方法、基站及x2网关
CN112839392B (zh) 无线接入点的控制和配置协议会话重建方法、装置及系统
WO2022257974A1 (zh) 切换信息报告方法、用户设备以及通信系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10853524

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10853524

Country of ref document: EP

Kind code of ref document: A1