專利名稱：一種基站自配置過程獲取基本配置參數(shù)的自愈方法及基站的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及無線通信領(lǐng)域，特別涉及LTE (Long Term Evolution，長期演進)系統(tǒng)自組織網(wǎng)絡(luò)中一種基站自配置過程獲取基本配置參數(shù)的自愈方法及基站。
背景技術(shù)：
未來網(wǎng)絡(luò)中，不同網(wǎng)絡(luò)共存將會使網(wǎng)絡(luò)變得更加復(fù)雜。大量無線參數(shù)和數(shù)據(jù)的配置以及優(yōu)化將會使網(wǎng)絡(luò)規(guī)劃和網(wǎng)絡(luò)優(yōu)化人員的工作變得更加繁雜，而運營商則希望降低運營成本和人工干預(yù)。于是，在LTE網(wǎng)絡(luò)的標準化階段，由移動運營商主導(dǎo)提出了 SON (Self-organized Network,自組織網(wǎng)絡(luò))的概念，其主要思想是實現(xiàn)網(wǎng)絡(luò)的一些自主功能以減少人工干預(yù)。在這一背景下，E-UTRAN(Evolved UMTS Terrestrial Radio Access Network，演進型 UMTS (Universal Mobile Telecommunications System，通用移動通信系統(tǒng))陸地?zé)o線接入網(wǎng))系統(tǒng)的SON特性被作為3GPP (3rd Generation Partnership Project, 第三代合作伙伴計劃)的重要研究方向之一。LTE系統(tǒng)中的SON具有自配置、自優(yōu)化、自治愈和自規(guī)劃四大功能。自配置和自優(yōu)化過程的流程和實現(xiàn)的主要功能如圖1所示?；緀NB(Evolved Node B，演進型節(jié)點B)上電后，進入自配置即預(yù)運營狀態(tài)，順序執(zhí)行(A)基本啟動；(B)初始無線參數(shù)配置2個步驟， 然后進入運營狀態(tài)，執(zhí)行步驟(C)優(yōu)化與調(diào)整。其中，在自配置過程的基本啟動階段至少包括了 IP地址配置與OMC(Operation and Maintenance Center，操作維護中心)服務(wù)器檢測、節(jié)點的鑒權(quán)、建立與EPC(EV0lVed Packet Core Network，演進型分組核心網(wǎng))的連接、 eNB軟件以及運行參數(shù)下載等幾個部分；在自配置過程的初始無線參數(shù)配置階段至少包括了相鄰小區(qū)列表的建立及覆蓋/容量相關(guān)的參數(shù)配置等幾個部分；在自優(yōu)化過程的優(yōu)化與調(diào)整階段至少包括了相鄰小區(qū)列表的優(yōu)化及覆蓋/容量控制等幾個部分。當網(wǎng)絡(luò)中新增一個節(jié)點時，該節(jié)點首先要與OMC服務(wù)器之間建立一個初始的邏輯連接，用于完成鑒權(quán)并獲得正確連接到網(wǎng)絡(luò)所需要的信息。為了與OMC服務(wù)器之間建立初始連接，該節(jié)點首先需要知道一些必要的基本參數(shù)信息，如節(jié)點自身的IP地址、網(wǎng)關(guān)地址、 DNS (Domain Name System，域名系統(tǒng))服務(wù)器地址等。為了支持自配置和自優(yōu)化功能，這些基本參數(shù)信息應(yīng)該是動態(tài)獲取的。關(guān)于基本參數(shù)信息的獲取方法，目前基本上都是采用 DHCP (Dynamic Host Control Protocol，動態(tài)主機配置協(xié)議)來實現(xiàn)的。包括基站自身IP地址在內(nèi)的基本參數(shù)信息的獲取和配置是基站自配置過程以及整個SON過程最基本的前提。如果基本參數(shù)信息獲取失敗，后續(xù)SON過程將無法進行，且目前只能通過專業(yè)人員上站去排查來解決問題，耗時耗力。因此，自配置階段的基本參數(shù)信息獲取的魯棒性就成為基站SON過程一個非常重要的方面。

發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問題是提供一種基站自配置過程獲取基本配置參數(shù)的自愈方法及基站，以解決現(xiàn)有技術(shù)中基站在獲取自身基本配置參數(shù)信息失敗后無法自動恢復(fù)的缺陷。為解決上述問題，本發(fā)明提供了一種基站自配置過程中獲取基本配置參數(shù)的自愈方法，包括基站在自配置過程中若請求自身基本參數(shù)信息失敗，則發(fā)送求救探測廣播消息； 鄰接基站收到后，在自身已成功獲得基本配置參數(shù)的前提下，向所述基站回復(fù)救援響應(yīng)消息；所述基站從回復(fù)所述救援響應(yīng)消息的所有鄰接基站中選擇一個作為救援基站，并請求該救援基站代為向動態(tài)主機配置協(xié)議(DHCP)服務(wù)器請求所述基站的基本參數(shù)信息；所述救援基站將請求到的所述基站的基本配置參數(shù)信息發(fā)送給所述基站。進一步地，上述方法還可包括鄰接基站在收到所述求救探測廣播消息后，若判斷出自身還沒有獲得基本配置參數(shù)，則丟棄所述求救探測廣播消息。進一步地，上述方法還可具有以下特征所述基站在發(fā)送所述求救探測廣播消息時，啟動等待響應(yīng)定時器；若在所述等待響應(yīng)定時器超時時，仍未收到所述救援響應(yīng)消息，則重新發(fā)送所述求救探測廣播消息，并執(zhí)行后續(xù)流程。進一步地，上述方法還可具有以下特征所述基站從回復(fù)所述救援響應(yīng)消息的所有鄰接基站中選擇一個作為救援基站是指所述基站選擇最先接收到的所述救援響應(yīng)消息對應(yīng)的鄰接基站作為救援基站；或者，所述基站選擇所接收到的所有救援響應(yīng)響應(yīng)消息的源IP地址最大或最小的消息所對應(yīng)的鄰接基站作為救援基站；或者，所述基站從所有回復(fù)所述救援響應(yīng)消息的鄰接基站中隨機選擇一個作為救援基站。進一步地，上述方法還可具有以下特征所述基站請求該救援基站代為向所述DHCP服務(wù)器請求所述基站的基本參數(shù)信息具體包括所述基站發(fā)送救援請求消息，其中攜帶所述基站的唯一標識信息； 所述救援基站收到后，向所述DHCP服務(wù)器發(fā)起DHCP請求，其中攜帶所述基站的唯一標識信息；所述DHCP服務(wù)器收到后，按照所述基站的唯一標識信息為所述基站分配基本參數(shù)信息，并將分配好的所述基本參數(shù)信息發(fā)送給所述救援基站。進一步地，上述方法還可包括所述鄰接基站在回復(fù)的所述救援響應(yīng)消息中添加該鄰接基站自身的標識標簽信息，并在本地記錄所述標識標簽信息；其中，所述標識標簽信息用于唯一的標識所述鄰接基站；所述基站發(fā)送的所述救援請求消息中還攜帶有所述救援基站的標識標簽信息；鄰接基站在收到所述救援請求消息后，首先判斷本地是否已記錄本基站的標識標簽信息；如未記錄，則丟棄所述救援請求消息；否則，判斷本地記錄的標識標簽信息與所述救援請求消息中攜帶的標識標簽信息是否一致；若一致，則獲知自身是所述救援基站，向所述DHCP服務(wù)器發(fā)起所述DHCP請求，并執(zhí)行后續(xù)流程；若不一致，則丟棄所述救援請求消息。進一步地，上述方法還可包括所述基站在發(fā)送所述求救探測廣播消息時，將自身的運行狀態(tài)值置為表示處于等待救援狀態(tài)；鄰接基站在收到其他鄰接基站回復(fù)的救援響應(yīng)消息后，判斷自身的運行狀態(tài)值是否表示處于等待救援狀態(tài)；若是，則進行救援基站的選擇及后續(xù)流程；否則，丟棄所述救援響應(yīng)消息。進一步地，上述方法還可具有以下特征所述基站內(nèi)預(yù)設(shè)有求救次數(shù)閾值；如所述救援基站代替所述基站請求基本配置參數(shù)失敗，則所述救援基站向所述基站發(fā)送攜帶表示請求失敗標識的通知消息；所述基站收到后，判斷求救次數(shù)是否已達到所述求救次數(shù)閾值；若是，則重新啟動，并在啟動后自行進行基本配置參數(shù)的請求；否則，重新發(fā)送所述求救探測廣播消息，并執(zhí)行后續(xù)流程。本發(fā)明還提供了一種基站，包括動態(tài)主機配置協(xié)議(DHCP)請求模塊、求救探測發(fā)送處理模塊、求救消息接收處理模塊、救援響應(yīng)發(fā)送處理模塊、救援響應(yīng)接收處理模塊、救援請求發(fā)送處理模塊、救援請求接收處理模塊、基本參數(shù)信息發(fā)送模塊及基本參數(shù)信息發(fā)送模塊；所述DHCP請求模塊用于向DHCP服務(wù)器請求獲取所述基站自身的基本參數(shù)信息； 還用于在獲取所述基本參數(shù)信息失敗時，作為求救基站中的模塊向所述求救探測發(fā)送處理模塊發(fā)送求救命令；還用于在所述基站作為救援基站時，代替求救基站向所述DHCP服務(wù)器請求所述求救基站的基本參數(shù)信息；所述求救探測發(fā)送處理模塊用于在收到所述求救命令后，發(fā)送求救探測廣播消息；當所述基站作為所述求救基站的鄰接基站時，所述求救消息接收處理模塊用于在收到所述求救探測廣播消息后，在判斷出自身已成功獲得基本配置參數(shù)的前提下，向所述救援響應(yīng)發(fā)送處理模塊發(fā)起救援響應(yīng)命令；所述救援響應(yīng)發(fā)送處理模塊用于在收到所述救援響應(yīng)命令后，對外發(fā)送救援響應(yīng)消息；當所述基站作為所述求救基站時，所述救援響應(yīng)接收處理模塊用于接收所述救援響應(yīng)消息，從回復(fù)所述救援響應(yīng)消息的所有鄰接基站中選擇一個作為救援基站，且通知所述救援請求發(fā)送處理模塊；救援請求發(fā)送處理模塊用于在收到上述通知后，向所述救援基站發(fā)送救援請求消息；當所述基站作為所述救援基站時，所述救援請求接收處理模塊用于在收到所述救援請求消息后，代替所述求救基站向所述DHCP服務(wù)器請求所述求救基站的基本參數(shù)信息；當所述基站作為所述救援基站時，所述基本參數(shù)信息發(fā)送模塊用于將請求到的所述基站的基本配置參數(shù)信息發(fā)送給所述求救基站；
當所述基站作為所述求救基站時，所述基本參數(shù)信息獲取模塊用于接收所述基本參數(shù)信息發(fā)送模塊發(fā)來的基本配置參數(shù)信息。進一步地，上述基站還可具有以下特征所述求救探測發(fā)送處理模塊還用于在發(fā)送所述求救探測廣播消息時，啟動一等待響應(yīng)定時器；當所述基站作為所述求救基站時，所述救援響應(yīng)接收處理模塊若在所述等待響應(yīng)定時器超時時，仍未收到所述救援響應(yīng)消息，則向所述求救探測發(fā)送處理模塊發(fā)送重發(fā)命令；所述求救探測發(fā)送處理模塊用于在收到重發(fā)命令后，重新發(fā)送所述求救探測廣播消息。進一步地，上述基站還可具有以下特征所述救援請求消息中攜帶有所述求救基站的唯一標識信息；救援請求接收處理模塊用于在收到所述救援請求消息后，向所述DHCP服務(wù)器發(fā)起DHCP請求，其中攜帶所述求救基站的唯一標識信息。進一步地，上述基站還可具有以下特征所述救援響應(yīng)發(fā)送處理模塊用于在回復(fù)的所述救援響應(yīng)消息中添加本基站自身的標識標簽信息，并在本地記錄所述標識標簽信息；其中，所述標識標簽信息用于唯一的標識本基站；所述救援請求消息中還攜帶有所述救援基站的標識標簽信息；所述救援請求接收處理模塊用于在收到所述救援請求消息后，首先判斷本地是否已記錄本基站的標識標簽信息；如未記錄，則丟棄所述救援請求消息；否則，還用于判斷本地記錄的標識標簽信息與所述救援請求消息中攜帶的標識標簽信息是否一致；若一致，則獲知自身是所述救援基站，向所述DHCP服務(wù)器發(fā)起所述DHCP請求，并執(zhí)行后續(xù)流程；若不一致，則丟棄所述救援請求消息。進一步地，上述基站還可具有以下特征所述求救探測發(fā)送處理模塊用于還用于在發(fā)送所述求救探測廣播消息時，將本基站的運行狀態(tài)值置為表示處于等待救援狀態(tài)；所述救援響應(yīng)接收處理模塊用于還用于在收到所述救援響應(yīng)消息后，判斷本基站的運行狀態(tài)值是否表示處于等待救援狀態(tài)；若是，則進行救援基站的選擇及后續(xù)流程；否則，丟棄所述救援響應(yīng)消息。采用本發(fā)明后，有利于減少人工干預(yù)，降低運營成本，可有效保證自配置過程以及后續(xù)SON過程的順利進行，可極大地增強基站自身以及SON過程的魯棒性。


圖1為現(xiàn)有技術(shù)中基站SON自配置和自優(yōu)化過程示意圖；圖2本發(fā)明實施例中基站自配置過程獲取基本配置參數(shù)的自愈方法流程圖；圖3為本發(fā)明實施例中鄰接基站的處理流程圖；圖4為本發(fā)明實施例中能實現(xiàn)自愈功能的基站結(jié)構(gòu)圖；圖5為本發(fā)明應(yīng)用實例1的關(guān)鍵流程示意圖6為本發(fā)明應(yīng)用實例2的關(guān)鍵流程示意圖。
具體實施例方式本發(fā)明具體實施方式
的描述，涉及一個LTE自組織網(wǎng)絡(luò)系統(tǒng)，至少包括DHCP服務(wù)器(DHCP Server)、OMC服務(wù)器以及多個基站。其中涉及到基站和DHCP服務(wù)器以及OMC服務(wù)器之間的交互過程，但是并非本發(fā)明的重點，因此只進行非常簡要的描述或者只是提及； 主要通過多個基站之間的交互過程進一步說明本發(fā)明中的自配置過程自愈方法。本發(fā)明所述方法的基本構(gòu)思是基站在自配置過程中若通過DHCP請求自身基本參數(shù)信息失敗，則發(fā)送求救探測廣播消息；鄰接基站收到后，在自身已成功獲得基本配置參數(shù)的前提下，向上述基站回復(fù)救援響應(yīng)消息；上述基站收到后，從上述回復(fù)救源響應(yīng)消息的所有鄰接基站中選擇一個作為救援基站，并請求該救援基站代為進行DHCP請求；該救援基站將代為請求到的基本配置參數(shù)發(fā)送給上述基站。進一步地，如圖2所示，本發(fā)明提供的自愈方法包括如下步驟(其中，各鄰接基站的處理流程如圖3所示。)(1)基站上電啟動，向DHCP服務(wù)器發(fā)送DHCP請求，其中攜帶該基站的唯一標識信息；如果DHCP請求失敗，則執(zhí)行下一步驟；其中，基站的唯一標識信息是指可以代表基站整個設(shè)備資產(chǎn)信息的一個標識，基站在DHCP選項61 (即客戶端標識(Client-identifier)，用于攜帶DHCP客戶端唯一標識) 中攜帶該唯一標識信息進行DHCP請求，與DHCP服務(wù)器進行交互，以獲取基本配置參數(shù)信肩、ο(2)上述基站發(fā)送求救探測廣播消息，以進行求救探測，并啟動等待響應(yīng)定時器， 且將本基站的運行狀態(tài)值設(shè)置為表示進入等待救援狀態(tài)；(3)鄰接基站收到求救基站發(fā)送的求救探測廣播消息，如果滿足作為救援基站的條件，發(fā)送攜帶自身標識標簽信息的救援響應(yīng)廣播消息進行救援響應(yīng)；否則，丟棄該求救探測廣播消息；其中，上述鄰接基站的標識標簽信息用于唯一的標識出該鄰接基站，該標識標簽信息可以是該鄰接基站自身的IP地址或硬件MAC地址，也可以是利用某種隨機數(shù)生成算法生成的一個標簽，也可以是該鄰接基站自身唯一標識等等；其中，鄰接基站的唯一標識信息基本上是預(yù)先固化好的，比如鄰接基站的電子序列號等；優(yōu)選地，鄰接基站判斷自身是否滿足作為救援基站的條件是指鄰接基站判斷自身是否已經(jīng)從DHCP服務(wù)器成功獲取到包括自身的IP地址等的基本參數(shù)信息；如果未成功， 則認為自身不滿足作為救援基站的條件；如果已經(jīng)成功，則認為自身滿足作為救援基站的條件。(4)如在等待響應(yīng)定時器超時前，求救基站收到鄰接基站發(fā)送的救援響應(yīng)消息，則按照既定策略選擇從發(fā)送救援響應(yīng)消息的鄰接基站中選出一個作為救援基站，并發(fā)送攜帶所選擇救援基站的標識標簽信息和自身唯一標識信息的廣播消息給鄰接基站，進入等待基本配置參數(shù)狀態(tài)；否則，重新執(zhí)行步驟O)；而其他處于非等待救援狀態(tài)的鄰接基站，在收到救援響應(yīng)消息后直接進行丟棄處理；在本步驟中，求救基站選擇救援基站的策略可以有多種方法例如可以選擇最先接收到的救援響應(yīng)報文對應(yīng)的鄰接基站作為救援基站；或者是在接收到的所有救援響應(yīng)報文中選擇發(fā)送的報文源IP地址最大或者最小的鄰接基站作為救援基站；也可以在接收到的救援響應(yīng)中隨機選擇一個鄰接基站作為救援基站；(5)鄰接基站中被選定的救援基站獲取求救基站的唯一標識信息，代替求救基站向DHCP服務(wù)器進行DHCP請求；由于求救基站發(fā)送的是廣播消息，因此鄰接基站收到求救基站發(fā)送的攜帶了所選擇的救援基站自身標識標簽信息以及求救基站自身唯一標識信息的廣播消息后，先判斷自身是否記錄有標識標簽，如果自身沒有記錄過標識標簽，則直接丟棄該廣播消息；否則，獲取上述消息中攜帶的救援基站的標識標簽，并與自身的標識標簽相比較；如果標簽不匹配， 則丟棄該廣播消息；否則，得知自己就是救援基站，則進一步獲取接收消息中的求救基站的唯一標識信息；救援基站在DHCP報文選項61中攜帶求救基站的唯一標識信息，代求救基站進行DHCP請求，和DHCP服務(wù)器之間進行消息交互，完成DHCP過程。(6)被選定的救援基站發(fā)送攜帶求救基站唯一標識信息和求救基站DHCP請求結(jié)果信息的廣播消息；該請求結(jié)果中攜帶表示DHCP請求成功或失敗的標識信息，此外，如請求成功，該請求結(jié)果信息中還攜帶請求道的求救基站的基本配置參數(shù)信息。(7)求救基站接收救援結(jié)果信息并進行處理。處于等待基本配置參數(shù)狀態(tài)的求救基站在收到救援基站發(fā)送的上述消息后，先提取該消息中攜帶的基站唯一標識信息，和自身的唯一標識信息相比較，如果二者不匹配，則丟棄該消息；否則，進一步提取出DHCP結(jié)果標識，如果表示成功，則進一步提取出包括自身 IP地址在內(nèi)的基本參數(shù)配置信息進行配置，進行后續(xù)SON過程；如果標識表示失敗，則判斷求救次數(shù)是否已到達預(yù)定閾值，如果沒有，則重新執(zhí)行步驟0)，以開始進行新一輪的求救動作；否則，基站自身進行重啟，并在啟動后自行進行基本配置參數(shù)的請求；而其他鄰接基站在非等待救援狀態(tài)，收到救援基站發(fā)送的該配置參數(shù)消息，直接進行丟棄處理。此外，本發(fā)明提供的自愈方法涉及的裝置是在一個基站上實現(xiàn)了包括求救基站和救援基站功能的整體裝置，如圖4所示，包含如下組成部分動態(tài)主機配置協(xié)議(DHCP)請求模塊、求救探測發(fā)送處理模塊、求救消息接收處理模塊、救援響應(yīng)發(fā)送處理模塊、救援響應(yīng)接收處理模塊、救援請求發(fā)送處理模塊、救援請求接收處理模塊、基本參數(shù)信息發(fā)送模塊及基本參數(shù)信息發(fā)送模塊；所述DHCP請求模塊用于向DHCP服務(wù)器請求獲取所述基站自身的基本參數(shù)信息； 還用于在獲取所述基本參數(shù)信息失敗時，作為求救基站中的模塊向所述求救探測發(fā)送處理模塊發(fā)送求救命令；還用于在所述基站作為救援基站時，代替求救基站向所述DHCP服務(wù)器請求所述求救基站的基本參數(shù)信息；所述求救探測發(fā)送處理模塊用于在收到所述求救命令后，發(fā)送求救探測廣播消息；當所述基站作為所述求救基站的鄰接基站時，所述求救消息接收處理模塊用于在收到所述求救探測廣播消息后，在判斷出自身已成功獲得基本配置參數(shù)的前提下，向所述救援響應(yīng)發(fā)送處理模塊發(fā)起救援響應(yīng)命令；所述救援響應(yīng)發(fā)送處理模塊用于在收到所述救援響應(yīng)命令后，對外發(fā)送救援響應(yīng)消息；當所述基站作為所述求救基站時，所述救援響應(yīng)接收處理模塊用于接收所述救援響應(yīng)消息，從回復(fù)所述救援響應(yīng)消息的所有鄰接基站中選擇一個作為救援基站，且通知所述救援請求發(fā)送處理模塊；救援請求發(fā)送處理模塊用于在收到上述通知后，向所述救援基站發(fā)送救援請求消息；當所述基站作為所述救援基站時，所述救援請求接收處理模塊用于在收到所述救援請求消息后，代替所述求救基站向所述DHCP服務(wù)器請求所述求救基站的基本參數(shù)信息；當所述基站作為所述救援基站時，所述基本參數(shù)信息發(fā)送模塊用于將請求到的所述基站的基本配置參數(shù)信息發(fā)送給所述求救基站；當所述基站作為所述求救基站時，所述基本參數(shù)信息獲取模塊用于接收所述基本參數(shù)信息發(fā)送模塊發(fā)來的基本配置參數(shù)信息；基本參數(shù)信息配置模塊負責(zé)完成包括基站自身IP地址在內(nèi)的基本參數(shù)信息的配置。優(yōu)選地，所述求救探測發(fā)送處理模塊還用于在發(fā)送所述求救探測廣播消息時，啟動一等待響應(yīng)定時器；當所述基站作為所述求救基站時，所述救援響應(yīng)接收處理模塊若在所述等待響應(yīng)定時器超時時，仍未收到所述救援響應(yīng)消息，則向所述求救探測發(fā)送處理模塊發(fā)送重發(fā)命令；所述求救探測發(fā)送處理模塊用于在收到重發(fā)命令后，重新發(fā)送所述求救探測廣播消息。此外，所述救援請求消息中可攜帶有所述求救基站的唯一標識信息；救援請求接收處理模塊用于在收到所述救援請求消息后，向所述DHCP服務(wù)器發(fā)起DHCP請求，其中攜帶所述求救基站的唯一標識信息。所述救援響應(yīng)發(fā)送處理模塊用于在回復(fù)的所述救援響應(yīng)消息中添加本基站自身的標識標簽信息，并在本地記錄所述標識標簽信息；其中，所述標識標簽信息用于唯一的標識本基站；所述救援請求消息中還攜帶有所述救援基站的標識標簽信息；所述救援請求接收處理模塊用于在收到所述救援請求消息后，首先判斷本地是否已記錄本基站的標識標簽信息；如未記錄，則丟棄所述救援請求消息；否則，還用于判斷本地記錄的標識標簽信息與所述救援請求消息中攜帶的標識標簽信息是否一致；若一致，則獲知自身是所述救援基站，向所述DHCP服務(wù)器發(fā)起所述DHCP請求，并執(zhí)行后續(xù)流程；若不一致，則丟棄所述救援請求消息。所述求救探測發(fā)送處理模塊用于還可用于在發(fā)送所述求救探測廣播消息時，將本基站的運行狀態(tài)值置為表示處于等待救援狀態(tài)；所述救援響應(yīng)接收處理模塊用于還用于在收到所述救援響應(yīng)消息后，判斷本基站的運行狀態(tài)值是否表示處于等待救援狀態(tài)；若是，則進行救援基站的選擇及后續(xù)流程；否則，丟棄所述救援響應(yīng)消息。下面，用本發(fā)明的兩個應(yīng)用實例進行進一步說明。
應(yīng)用實例1 本實施1中包括3個基站基站A (新上電的基站)，基站B(在基站A之前上電， 已經(jīng)正常運行)，基站C (在基站A之后上電)。下面通過本發(fā)明的應(yīng)用實例1，并結(jié)合圖5 對本發(fā)明的內(nèi)容進行進一步說明。SlOl 基站A新上電，進行初始啟動；此時基站B已經(jīng)成功獲取基本配置參數(shù)信息，并和OMC取得聯(lián)系，正常運行；基站C尚未上電；S102 基站A與DHCP服務(wù)器之間進行消息交互，DHCP結(jié)果失敗；此時基站C開始上電啟動；S103 基站A進入自愈流程，啟動等待救援響應(yīng)定時器，進入等待救援狀態(tài)?；?A發(fā)送求救探測廣播消息，進行求救探測；S104 基站B和基站C均收到基站A發(fā)送的求救探測消息；基站B判斷自身狀態(tài)， 發(fā)現(xiàn)自己已經(jīng)和DHCP服務(wù)器成功交互，即認為自己可以作為救援基站，則基站B利用自身 MAC地址作為自身標識標簽(注此例中采用自身MAC地址作為自身標識標簽的方法)并在本地進行記錄保存；基站C判斷自身狀態(tài)，發(fā)現(xiàn)自己尚未從DHCP服務(wù)器成功獲取基本配置參數(shù)信息， 則丟棄該求救探測廣播消息；S105 基站B發(fā)送包含自身標識標簽信息的救援響應(yīng)消息，對基站A進行響應(yīng)；基站C的DHCP請求過程結(jié)束，DHCP請求成功，配置基本參數(shù)信息，并和OMC取得聯(lián)系，進行SON 后續(xù)過程；S106 基站A在等待時間內(nèi)收到基站B發(fā)送的救援響應(yīng)消息，從中提取基站B的標識標簽并進行保存，選定基站B作為救援基站；基站C在非等待救援狀態(tài)收到該救援響應(yīng)消息，直接丟棄。S107 基站A發(fā)送攜帶自身唯一標識信息和救援基站B標識標簽信息的救援請求廣播消息，進入等待基本參數(shù)配置狀態(tài)；S108 基站B收到基站A發(fā)送的廣播消息，查看發(fā)現(xiàn)自己本地有標識標簽信息，從而進一步提取該消息中的救援基站標識標簽信息，和自己的標識標簽相比對；基站B發(fā)現(xiàn)標識標簽匹配，確認自己就是救援基站，從而進一步提取求救基站A的唯一標識信息并在本地進行保存；基站C收到基站A發(fā)送的包含其唯一標識信息的廣播消息，查看發(fā)現(xiàn)自己本地沒有標識標簽信息，直接丟棄該廣播消息。S109 救援基站B攜帶求救基站A的唯一標識信息，與DHCP服務(wù)器之間進行交互， 為基站A進行DHCP請求，且DHCP請求成功；SllO 基站B發(fā)送攜帶有求救基站A唯一標識信息、表示DHCP請求成功的結(jié)果信息以及請求到的基站A基本配置參數(shù)信息的廣播消息；Slll 求救基站A在等待基本配置參數(shù)狀態(tài)收到救援基站B發(fā)送的基本配置參數(shù)廣播消息，先提取基站唯一標識信息，與自己的唯一標識信息相比較，結(jié)果匹配；進一步提取DHCP請求結(jié)果信息，發(fā)現(xiàn)請求成功，進而提取基本配置參數(shù)信息；基站C在非等待救援狀態(tài)收到該基本配置參數(shù)廣播消息，直接丟棄；S112 基站A根據(jù)獲取到的基本配置參數(shù)信息完成配置，進行SON后續(xù)過程。
應(yīng)用實例2:本實施2中包括4個基站基站Al (新上電基站)，基站A2 (新上電基站)，基站 D (新上電基站，而且在基站Al和A2之后上電)，基站E (新上電基站，而且在基站Al和A2 之后上電)。下面通過本發(fā)明的應(yīng)用實例2，并結(jié)合圖6對本發(fā)明的內(nèi)容進行進一步說明。S201 基站Al和A2新上電，進行初始啟動；此時基站D和基站E均未上電；S202 基站Al和A2與DHCP服務(wù)器之間進行消息交互，DHCP結(jié)果均失??；S203:基站Al和A2分別進入自愈流程，啟動等待響應(yīng)定時器，進入等待救援狀態(tài)。 基站Al和A2均發(fā)送求救探測廣播消息，進行求救探測；此時基站D和基站E開始上電啟動；S204 基站D和基站E收到基站Al和A2發(fā)送的求救探測消息，判斷各自的狀態(tài)， 發(fā)現(xiàn)自己尚未從DHCP服務(wù)器成功獲取基本配置參數(shù)信息，均丟棄該求救探測廣播消息；基站Al收到基站A2發(fā)送的求救探測消息，判斷自身的狀態(tài)，發(fā)現(xiàn)自己尚未從DHCP 服務(wù)器成功獲取基本配置參數(shù)信息，丟棄該求救探測廣播消息；同理，基站A2收到基站Al 發(fā)送的求救探測廣播消息，亦丟棄該廣播消息；S205 基站Al和A2均等待超時，未收到任何響應(yīng)消息，仍處于等待救援狀態(tài)，重新啟動定時器，再次發(fā)送求救探測廣播消息； S206 此時，基站D和基站E均完成與DHCP服務(wù)器的交互，成功獲取各自的基本配置參數(shù)信息，并已進行配置，正常運行；S207 基站D和基站E收到基站Al和A2發(fā)送的求救探測廣播消息，判斷各自狀態(tài)，發(fā)現(xiàn)自己已經(jīng)和DHCP服務(wù)器成功交互，判斷結(jié)果認為自己可以作為救援基站；基站D和基站E利用自身唯一標識信息作為自身標識標簽(注此例中采用基站唯一標識作為自身標識標簽)并在本地進行記錄保存；基站Al和A2各自收到對方的求救探測廣播消息，因為自身尚未DHCP請求成功， 均直接丟棄該廣播消息。S208 基站D和基站E均發(fā)送攜帶自身標識標簽信息的救援響應(yīng)消息；S209 基站Al先收到基站D發(fā)送的救援響應(yīng)消息，提取基站D的標識標簽信息并保存，選擇基站D作為救援基站(注采用選取最先到達的救援響應(yīng)對應(yīng)的基站作為救援基站的選擇策略)；基站Al收到基站E發(fā)送的救援響應(yīng)消息，進行丟棄；基站A2先收到基站E發(fā)送的救援響應(yīng)消息，提取基站E的標識標簽信息并保存， 選擇基站E作為救援基站；基站A2收到基站D發(fā)送的救援響應(yīng)消息，進行丟棄；基站D在非等待救援狀態(tài)收到基站E發(fā)送的救援響應(yīng)消息，直接丟棄；同樣，基站 E在非等待救援狀態(tài)收到基站D發(fā)送的救援響應(yīng)消息，直接丟棄。S210 基站Al發(fā)送攜帶自身唯一標識信息和救援基站D標識標簽信息的廣播消息，進入等待基本參數(shù)配置狀態(tài)；基站A2發(fā)送攜帶自身唯一標識信息和救援基站E標識標簽信息的廣播消息，進入等待基本參數(shù)配置狀態(tài)。S211 基站D收到基站Al發(fā)送的廣播消息，查看發(fā)現(xiàn)自己本地有標識標簽信息，從而進一步提取該消息中的救援基站標識標簽信息，和自己的標識標簽相比對；基站D發(fā)現(xiàn)標識標簽匹配，確認自己就是救援基站，從而進一步提取求救基站Al的唯一標識信息并在本地進行保存；基站D收到基站A2發(fā)送的廣播消息，查看發(fā)現(xiàn)自己本地有標識標簽信息，從而進一步提取該消息中的救援基站標識標簽信息，和自己的標識標簽相比對；基站D發(fā)現(xiàn)標識標簽不匹配，丟棄該廣播消息；基站E收到基站A2發(fā)送的廣播消息，查看發(fā)現(xiàn)自己本地有標識標簽信息，從而進一步提取該消息中的救援基站標識標簽信息，和自己的標識標簽相比對；基站E發(fā)現(xiàn)標識標簽匹配，確認自己就是救援基站，從而進一步提取求救基站A2的唯一標識信息并在本地進行保存；基站E收到基站Al發(fā)送的廣播消息，查看發(fā)現(xiàn)自己本地有標識標簽信息，從而進一步提取該消息中的救援基站標識標簽信息，和自己的標識標簽相比對；基站E發(fā)現(xiàn)標識標簽不匹配，丟棄該廣播消息；基站Al和A2互相收到對方發(fā)送的攜帶有自身唯一標識信息和救援基站標識標簽信息的廣播消息，查看發(fā)現(xiàn)自身無標識標簽信息，均丟棄該廣播消息。S212 基站D攜帶求救基站Al的唯一標識信息，與DHCP服務(wù)器之間進行交互，完成DHCP交互過程，DHCP結(jié)果失??；基站E攜帶求救基站A2的唯一標識信息，與DHCP服務(wù)器之間進行交互，完成DHCP 交互過程，DHCP結(jié)果成功。S213 基站D發(fā)送攜帶有求救基站Al唯一標識信息以及DHCP請求結(jié)果失敗信息的廣播消息；基站E發(fā)送攜帶有求救基站A2唯一標識信息、DHCP請求結(jié)果成功以及基站A2基本配置參數(shù)信息的廣播消息。S214 求救基站Al在等待基本配置參數(shù)狀態(tài)收到救援基站D發(fā)送的包含DHCP請求結(jié)果失敗的廣播消息，先提取基站唯一標識信息，與自己的唯一標識信息相比較，結(jié)果匹配；進一步提取DHCP請求結(jié)果信息，發(fā)現(xiàn)請求失?。贿M一步判斷是否達到求救次數(shù)閾值 (例如，預(yù)置為5次)，比較發(fā)現(xiàn)小于閾值，進行新一輪的求救動作；求救基站Al在等待基本配置參數(shù)狀態(tài)收到救援基站E發(fā)送的包含DHCP請求結(jié)果的廣播消息，先提取基站唯一標識信息，與自己的唯一標識信息相比較，結(jié)果不匹配，直接丟棄該廣播消息；求救基站A2在等待基本配置參數(shù)狀態(tài)收到救援基站E發(fā)送的包含DHCP請求結(jié)果成功的廣播消息，先提取基站唯一標識信息，與自己的唯一標識信息相比較，結(jié)果匹配；進一步提取DHCP請求結(jié)果信息，發(fā)現(xiàn)請求成功，進而提取基本配置參數(shù)信息；求救基站A2在等待基本配置參數(shù)狀態(tài)收到救援基站D發(fā)送的包含DHCP請求結(jié)果的廣播消息，先提取基站唯一標識信息，與自己的唯一標識信息相比較，結(jié)果不匹配，直接丟棄該廣播消息； 救援基站D和救援基站E在非等待救援狀態(tài)各自收到對方發(fā)送的該基本配置參數(shù)廣播消息，直接丟棄。S215:基站A2根據(jù)獲取到的基本配置參數(shù)信息完成配置，進行SON后續(xù)過程。綜上所述，本發(fā)明內(nèi)容所述的通過鄰接基站代為DHCP請求的自愈方法，為基站 SON自配置過程的基本前提即包括基站自身IP地址在內(nèi)的基本配置參數(shù)信息的獲取提供了有力的保障，使得后續(xù)SON過程能夠順利進行，極大增強了基站自身以及自組織網(wǎng)絡(luò)的
魯棒性。
本領(lǐng)域普通技術(shù)人員可以理解上述方法中的全部或部分步驟可通過程序來指令相關(guān)硬件完成，所述程序可以存儲于計算機可讀存儲介質(zhì)中，如只讀存儲器、磁盤或光盤等。可選地，上述實施例的全部或部分步驟也可以使用一個或多個集成電路來實現(xiàn)。相應(yīng)地，上述實施例中的各模塊/單元可以采用硬件的形式實現(xiàn)，也可以采用軟件功能模塊的形式實現(xiàn)。本發(fā)明不限制于任何特定形式的硬件和軟件的結(jié)合。
權(quán)利要求
1.一種基站自配置過程中獲取基本配置參數(shù)的自愈方法，包括基站在自配置過程中若請求自身基本參數(shù)信息失敗，則發(fā)送求救探測廣播消息；鄰接基站收到后，在自身已成功獲得基本配置參數(shù)的前提下，向所述基站回復(fù)救援響應(yīng)消息；所述基站從回復(fù)所述救援響應(yīng)消息的所有鄰接基站中選擇一個作為救援基站，并請求該救援基站代為向動態(tài)主機配置協(xié)議(DHCP)服務(wù)器請求所述基站的基本參數(shù)信息；所述救援基站將請求到的所述基站的基本配置參數(shù)信息發(fā)送給所述基站。
2.如權(quán)利要求1所述的方法，其特征在于，還包括鄰接基站在收到所述求救探測廣播消息后，若判斷出自身還沒有獲得基本配置參數(shù)， 則丟棄所述求救探測廣播消息。
3.如權(quán)利要求1或2所述的方法，其特征在于所述基站在發(fā)送所述求救探測廣播消息時，啟動等待響應(yīng)定時器；若在所述等待響應(yīng)定時器超時時，仍未收到所述救援響應(yīng)消息，則重新發(fā)送所述求救探測廣播消息，并執(zhí)行后續(xù)流程。
4.如權(quán)利要求1所述的方法，其特征在于所述基站從回復(fù)所述救援響應(yīng)消息的所有鄰接基站中選擇一個作為救援基站是指所述基站選擇最先接收到的所述救援響應(yīng)消息對應(yīng)的鄰接基站作為救援基站；或者，所述基站選擇所接收到的所有救援響應(yīng)響應(yīng)消息的源IP地址最大或最小的消息所對應(yīng)的鄰接基站作為救援基站；或者，所述基站從所有回復(fù)所述救援響應(yīng)消息的鄰接基站中隨機選擇一個作為救援基站。
5.如權(quán)利要求1或4所述的方法，其特征在于所述基站請求該救援基站代為向所述DHCP服務(wù)器請求所述基站的基本參數(shù)信息具體包括所述基站發(fā)送救援請求消息，其中攜帶所述基站的唯一標識信息；所述救援基站收到后，向所述DHCP服務(wù)器發(fā)起DHCP請求，其中攜帶所述基站的唯一標識信息；所述DHCP服務(wù)器收到后，按照所述基站的唯一標識信息為所述基站分配基本參數(shù)信息，并將分配好的所述基本參數(shù)信息發(fā)送給所述救援基站。
6.如權(quán)利要求5所述的方法，其特征在于，還包括所述鄰接基站在回復(fù)的所述救援響應(yīng)消息中添加該鄰接基站自身的標識標簽信息，并在本地記錄所述標識標簽信息；其中，所述標識標簽信息用于唯一的標識所述鄰接基站；所述基站發(fā)送的所述救援請求消息中還攜帶有所述救援基站的標識標簽信息；鄰接基站在收到所述救援請求消息后，首先判斷本地是否已記錄本基站的標識標簽信息；如未記錄，則丟棄所述救援請求消息；否則，判斷本地記錄的標識標簽信息與所述救援請求消息中攜帶的標識標簽信息是否一致；若一致，則獲知自身是所述救援基站，向所述 DHCP服務(wù)器發(fā)起所述DHCP請求，并執(zhí)行后續(xù)流程；若不一致，則丟棄所述救援請求消息。
7.如權(quán)利要求1或4所述的方法，其特征在于，還包括所述基站在發(fā)送所述求救探測廣播消息時，將自身的運行狀態(tài)值置為表示處于等待救援狀態(tài)；鄰接基站在收到其他鄰接基站回復(fù)的救援響應(yīng)消息后，判斷自身的運行狀態(tài)值是否表示處于等待救援狀態(tài)；若是，則進行救援基站的選擇及后續(xù)流程；否則，丟棄所述救援響應(yīng)消息。
8.如權(quán)利要求1所述的方法，其特征在于 所述基站內(nèi)預(yù)設(shè)有求救次數(shù)閾值；如所述救援基站代替所述基站請求基本配置參數(shù)失敗，則所述救援基站向所述基站發(fā)送攜帶表示請求失敗標識的通知消息；所述基站收到后，判斷求救次數(shù)是否已達到所述求救次數(shù)閾值；若是，則重新啟動，并在啟動后自行進行基本配置參數(shù)的請求；否則，重新發(fā)送所述求救探測廣播消息，并執(zhí)行后續(xù)流程。
9.一種基站，包括動態(tài)主機配置協(xié)議(DHCP)請求模塊、求救探測發(fā)送處理模塊、求救消息接收處理模塊、救援響應(yīng)發(fā)送處理模塊、救援響應(yīng)接收處理模塊、救援請求發(fā)送處理模塊、救援請求接收處理模塊、基本參數(shù)信息發(fā)送模塊及基本參數(shù)信息發(fā)送模塊；所述DHCP請求模塊用于向DHCP服務(wù)器請求獲取所述基站自身的基本參數(shù)信息；還用于在獲取所述基本參數(shù)信息失敗時，作為求救基站中的模塊向所述求救探測發(fā)送處理模塊發(fā)送求救命令；還用于在所述基站作為救援基站時，代替求救基站向所述DHCP服務(wù)器請求所述求救基站的基本參數(shù)信息；所述求救探測發(fā)送處理模塊用于在收到所述求救命令后，發(fā)送求救探測廣播消息； 當所述基站作為所述求救基站的鄰接基站時，所述求救消息接收處理模塊用于在收到所述求救探測廣播消息后，在判斷出自身已成功獲得基本配置參數(shù)的前提下，向所述救援響應(yīng)發(fā)送處理模塊發(fā)起救援響應(yīng)命令；所述救援響應(yīng)發(fā)送處理模塊用于在收到所述救援響應(yīng)命令后，對外發(fā)送救援響應(yīng)消息；當所述基站作為所述求救基站時，所述救援響應(yīng)接收處理模塊用于接收所述救援響應(yīng)消息，從回復(fù)所述救援響應(yīng)消息的所有鄰接基站中選擇一個作為救援基站，且通知所述救援請求發(fā)送處理模塊；救援請求發(fā)送處理模塊用于在收到上述通知后，向所述救援基站發(fā)送救援請求消息； 當所述基站作為所述救援基站時，所述救援請求接收處理模塊用于在收到所述救援請求消息后，代替所述求救基站向所述DHCP服務(wù)器請求所述求救基站的基本參數(shù)信息；當所述基站作為所述救援基站時，所述基本參數(shù)信息發(fā)送模塊用于將請求到的所述基站的基本配置參數(shù)信息發(fā)送給所述求救基站；當所述基站作為所述求救基站時，所述基本參數(shù)信息獲取模塊用于接收所述基本參數(shù)信息發(fā)送模塊發(fā)來的基本配置參數(shù)信息。
10.如權(quán)利要求9所述的基站，其特征在于，所述求救探測發(fā)送處理模塊還用于在發(fā)送所述求救探測廣播消息時，啟動一等待響應(yīng)定時器；當所述基站作為所述求救基站時，所述救援響應(yīng)接收處理模塊若在所述等待響應(yīng)定時器超時時，仍未收到所述救援響應(yīng)消息，則向所述求救探測發(fā)送處理模塊發(fā)送重發(fā)命令； 所述求救探測發(fā)送處理模塊用于在收到重發(fā)命令后，重新發(fā)送所述求救探測廣播消息。
11.如權(quán)利要求9所述的基站，其特征在于，所述救援請求消息中攜帶有所述求救基站的唯一標識信息；救援請求接收處理模塊用于在收到所述救援請求消息后，向所述DHCP服務(wù)器發(fā)起 DHCP請求，其中攜帶所述求救基站的唯一標識信息。
12.如權(quán)利要求11所述的基站，其特征在于，所述救援響應(yīng)發(fā)送處理模塊用于在回復(fù)的所述救援響應(yīng)消息中添加本基站自身的標識標簽信息，并在本地記錄所述標識標簽信息；其中，所述標識標簽信息用于唯一的標識本基站；所述救援請求消息中還攜帶有所述救援基站的標識標簽信息； 所述救援請求接收處理模塊用于在收到所述救援請求消息后，首先判斷本地是否已記錄本基站的標識標簽信息；如未記錄，則丟棄所述救援請求消息；否則，還用于判斷本地記錄的標識標簽信息與所述救援請求消息中攜帶的標識標簽信息是否一致；若一致，則獲知自身是所述救援基站，向所述DHCP服務(wù)器發(fā)起所述DHCP請求，并執(zhí)行后續(xù)流程；若不一致， 則丟棄所述救援請求消息。
13.如權(quán)利要求9所述的基站，其特征在于，所述求救探測發(fā)送處理模塊用于還用于在發(fā)送所述求救探測廣播消息時，將本基站的運行狀態(tài)值置為表示處于等待救援狀態(tài)；所述救援響應(yīng)接收處理模塊用于還用于在收到所述救援響應(yīng)消息后，判斷本基站的運行狀態(tài)值是否表示處于等待救援狀態(tài)；若是，則進行救援基站的選擇及后續(xù)流程；否則，丟棄所述救援響應(yīng)消息。
全文摘要
一種基站自配置過程獲取基本配置參數(shù)的自愈方法及基站，所述方法包括基站在自配置過程中若請求自身基本參數(shù)信息失敗，則發(fā)送求救探測廣播消息；鄰接基站收到后，在自身已成功獲得基本配置參數(shù)的前提下，向所述基站回復(fù)救援響應(yīng)消息；所述基站從回復(fù)所述救援響應(yīng)消息的所有鄰接基站中選擇一個作為救援基站，并請求該救援基站代為向動態(tài)主機配置協(xié)議(DHCP)服務(wù)器請求所述基站的基本參數(shù)信息；所述救援基站將請求到的所述基站的基本配置參數(shù)信息發(fā)送給所述基站。采用本發(fā)明后，有利于減少人工干預(yù)，降低運營成本，可有效保證自配置過程以及后續(xù)SON過程的順利進行，可極大地增強基站自身以及SON過程的魯棒性。
文檔編號H04W8/30GK102300207SQ201010213099
公開日2011年12月28日 申請日期2010年6月24日 優(yōu)先權(quán)日2010年6月24日
發(fā)明者鄭紀偉 申請人:中興通訊股份有限公司