專利名稱：一種對版本上報消息處理流程的性能優(yōu)化方法及裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，尤其涉及一種通信系統(tǒng)中對版本上報消息處理流程的 性能優(yōu)化方法及裝置，尤其適用于處理大量同時上報的版本消息。
背景技術(shù)：
在移動通信系統(tǒng)無線接入網(wǎng)絡(luò)中，小型基站具有很多優(yōu)勢，適合于熱點地區(qū)的信 號覆蓋，但這種小型基站覆蓋區(qū)域較小，所以一般情況下都會有部署大量基站。基站啟動后會向統(tǒng)一網(wǎng)管平臺中的版本管理模塊發(fā)送當(dāng)前的運行版本信息。統(tǒng)一 網(wǎng)管平臺的版本管理模塊負(fù)責(zé)全網(wǎng)所轄基站的版本比較及更新，是保證基站穩(wěn)定運行的關(guān) 鍵手段。版本管理模塊收到版本信息后向基站返回一個阻止繼續(xù)上報消息。網(wǎng)管平臺方面應(yīng)該盡早向基站發(fā)送反饋消息，這樣一方面可以及時阻止基站繼續(xù) 上報版本信息，另一方面基站可以盡早結(jié)束上報線程，達(dá)到節(jié)省網(wǎng)管平臺以及基站寶貴系 統(tǒng)資源的目的。在舊有處理流程中，參照圖1所示，為現(xiàn)有的無線接入網(wǎng)絡(luò)系統(tǒng)框圖。如圖中所 示，版本管理模塊的版本上報消息處理流程是通信層接到基站的上報消息將其轉(zhuǎn)發(fā)給邏輯 處理層，然后邏輯處理層通過查詢數(shù)據(jù)庫得到基站的基本信息再生成反饋消息通過通信層 發(fā)送到基站。網(wǎng)管平臺從接收到基站的版本上報消息到將反饋消息發(fā)向網(wǎng)元，需要通過6個類 的處理。處理版本上報消息和生成反饋消息所需時間較長，并且處理過程也需要創(chuàng)建多條 線程導(dǎo)致資源占用也較大。反饋消息的構(gòu)成需要基站的基本信息。為了獲得基站的基本信 息，需要在邏輯處理層從數(shù)據(jù)庫讀取該信息，導(dǎo)致版本上報信息需要在通信層和邏輯處理 層轉(zhuǎn)發(fā)多次，并且在轉(zhuǎn)發(fā)中大多數(shù)類沒做復(fù)雜的加工處理，大量的時間和資源浪費在了轉(zhuǎn) 發(fā)過程中。轉(zhuǎn)發(fā)的過程中還創(chuàng)建了大量的對象實例和多條線程并且采用了 Java的反射機 制，導(dǎo)致網(wǎng)管平臺寶貴資源的浪費，更使得反饋消息生成時間延長。而且，基站側(cè)在收到網(wǎng)管平臺反饋消息之前都會維護一個發(fā)送線程，所以收到反 饋消息的時間越長基站側(cè)浪費的資源也就越多。在極端情況下，大量基站同時啟動并上報版本信息，此時網(wǎng)管平臺服務(wù)器在短短 幾分鐘內(nèi)需要處理數(shù)千甚至數(shù)萬條版本上報信息，對于優(yōu)化前的處理流程來說，每條上報 信息需要數(shù)秒的處理時間和多條處理線程，將會使服務(wù)器資源非常緊張甚至拖垮服務(wù)器。

發(fā)明內(nèi)容
本發(fā)明所要解決的技術(shù)問題是提供一種對版本上報消息處理流程的性能優(yōu)化方 法及裝置，有效提高版本上報消息處理效率并同時減少資源消耗。為了解決上述技術(shù)問題，本發(fā)明提供了一種對版本上報消息處理流程的性能優(yōu)化 方法，包括當(dāng)網(wǎng)管平臺運行時，在內(nèi)存中維護基站的基本信息；
網(wǎng)管平臺在通信層收到基站的版本上報消息后，提取其中的標(biāo)識信息，并根據(jù)所 述標(biāo)識信息在內(nèi)存中查詢該基站的基本信息；若成功查詢到該基站的基本信息，則采用此基本信息構(gòu)造一個阻止版本繼續(xù)上報 消息發(fā)向基站。進一步來說，所述標(biāo)識信息為地址信息。進一步來說，所述方法還包括將版本上報消息轉(zhuǎn)發(fā)到邏輯處理層進行后續(xù)操作。進一步來說，所述后續(xù)操作，包括版本入庫和版本下載。進一步來說，所述方法還包括若在內(nèi)存中無法查詢到該基站的基本信息，則結(jié)束流程，放棄處理所述基站的版 本上報消息。為了解決上述技術(shù)問題，本發(fā)明還提供了一種對版本上報消息處理流程的性能優(yōu) 化裝置，設(shè)置于網(wǎng)管平臺，包括維護模塊，用于當(dāng)網(wǎng)管平臺運行時，在內(nèi)存中維護基站的基本信息；查詢模塊，用于在網(wǎng)管平臺通信層收到基站的版本上報消息后，提取其中的標(biāo)識 信息，并根據(jù)所述標(biāo)識信息在內(nèi)存中查詢該基站的基本信息；發(fā)送模塊，用于在成功查詢到該基站的基本信息，則采用此基本信息構(gòu)造一個阻 止版本繼續(xù)上報消息發(fā)向基站。進一步來說，所述查詢模塊提取的標(biāo)識信息為地址信息。進一步來說，所述裝置還包括轉(zhuǎn)發(fā)模塊，用于將版本上報消息轉(zhuǎn)發(fā)到邏輯處理層進行后續(xù)操作。進一步來說，所述后續(xù)操作，包括版本入庫和版本下載。進一步來說，所述查詢模塊，還用于當(dāng)在內(nèi)存中無法查詢到該基站的基本信息，則 結(jié)束流程，放棄處理所述基站的版本上報消息。本發(fā)明通過將基站的基本信息存在統(tǒng)一網(wǎng)管平臺的內(nèi)存中，查詢基站的基本信息 只需在內(nèi)存中進行，并且生成版本阻止上報消息只需在通信層中構(gòu)造就可發(fā)向基站，從而 優(yōu)化了統(tǒng)一網(wǎng)管平臺版本上報消息處理流程，有效提高版本上報消息處理效率并同時減少 資源消耗。


圖1是現(xiàn)有的無線接入網(wǎng)絡(luò)系統(tǒng)框圖。圖2是本發(fā)明的對版本上報消息處理流程的性能優(yōu)化方法流程圖。圖3A-圖3B是版本上報消息處理時序圖及優(yōu)化方案。圖4是原有流程與優(yōu)化后返回阻止上報消息所用時間比較。圖5是原有流程與優(yōu)化后在不同時刻JVM中的線程數(shù)量比較。圖6是本發(fā)明的對版本上報消息處理流程的性能優(yōu)化裝置結(jié)構(gòu)示意圖。
具體實施例方式本發(fā)明的主要思想是當(dāng)網(wǎng)管平臺運行時，在內(nèi)存中維護基站的基本信息，當(dāng)需要基站的基本信息時無需讀取數(shù)據(jù)庫，而是直接從內(nèi)存中取出相應(yīng)信息。在構(gòu)成反饋消息時 利用內(nèi)存中的基本信息直接構(gòu)造反饋消息，從而不用經(jīng)過邏輯處理層即可成功構(gòu)造反饋消 息。通過這種改進減少了讀取數(shù)據(jù)庫和網(wǎng)管平臺內(nèi)消息轉(zhuǎn)發(fā)的時間消耗和資源消耗。為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，以下結(jié)合附圖及具體實施例，對本 發(fā)明作進一步地詳細(xì)說明。參照圖2所示，為本發(fā)明的對版本上報消息處理流程的性能優(yōu)化方法流程圖，所 述方法包括以下步驟步驟201 當(dāng)網(wǎng)管平臺運行時，在內(nèi)存中維護基站的基本信息；步驟202 網(wǎng)管平臺在通信層收到基站的版本上報消息后就立即提取其中的標(biāo)識 信息，根據(jù)所述標(biāo)識信息在內(nèi)存中查詢該基站的基本信息；需要指出的是，所述標(biāo)識信息是對基站進行唯一識別的信息，具體可以為地址信 息，當(dāng)然也可以是其他的可以對基站進行唯一識別的信息，比如還可以是網(wǎng)元的MAC(Mdium Access Control，媒體接入控制)地址或EID(電子序列號/Electronical ID)，本發(fā)明對此 不加以限定。步驟203 若成功查詢到該基站的基本信息，則利用此基本信息構(gòu)造一個阻止版 本繼續(xù)上報消息發(fā)向基站；若無法查詢到該基站的基本信息，則證明此基站沒有在此網(wǎng)管平臺注冊，則無需 處理此消息。步驟204 阻止版本繼續(xù)上報消息發(fā)送成功，將版本上報消息轉(zhuǎn)發(fā)到邏輯處理層 進行后續(xù)操作，如版本入庫和版本下載。需要說明的是，“組織版本繼續(xù)上報消息發(fā)送成功”與“版本上報消息轉(zhuǎn)發(fā)到邏輯 處理層進行后續(xù)操作”是并行執(zhí)行的，也就是說先啟動“組織版本繼續(xù)上報消息發(fā)送成功” 動作，然后立即啟動“版本上報消息轉(zhuǎn)發(fā)到邏輯處理層進行后續(xù)操作”動作。在技術(shù)上實現(xiàn) 是采用的多線程技術(shù)?？梢?，通過上述的步驟，本發(fā)明生成版本阻止上報消息只需在通信層中構(gòu)造就可 發(fā)向基站，查詢基本信息也只需在內(nèi)存中進行。具體來說，在具體實現(xiàn)中需要修改兩個類通信層的消息監(jiān)聽類和邏輯處理層的 版本上報消息處理類。首先在邏輯處理層的版本上報消息處理類中將發(fā)送阻止上報消息的 代碼去掉。然后在通信層的消息監(jiān)聽類中添加發(fā)送阻止上報消息相關(guān)代碼，這些代碼可以 從邏輯處理層的版本上報消息處理類中的相關(guān)代碼進行修改得來。在全部實現(xiàn)中，生成阻止上報消息有關(guān)代碼與原有代碼有較大區(qū)別。其原因是原 有流程的上報消息從通信層到邏輯處理層又返回到通信層，在流轉(zhuǎn)期間進行多次封裝。而 優(yōu)化后流程只需從基站的上報的SNMP (Simple Network Management Protocol，簡單網(wǎng)絡(luò) 管理協(xié)議)消息中直接提取基本信息，即可生成阻止上報消息。如圖3A所示，圖中的線為原處理流程中消息轉(zhuǎn)發(fā)的路徑，可以看到在原流程中消 息需要轉(zhuǎn)發(fā)到邏輯處理層的版本上報消息處理類，在此類中查詢數(shù)據(jù)庫獲得基站基本信息 后再構(gòu)造阻止上報消息。如圖3B所示，優(yōu)化后的流程為在通信層的消息監(jiān)聽類中直接讀取內(nèi)存提取出基 站的基本信息，并構(gòu)造出阻止上報消息通過通信層SNMP消息處理類將阻止上報消息發(fā)回給基站。通過對比圖3A與圖3B所示，可以清晰的看出優(yōu)化后的流程減少了大量的消息轉(zhuǎn) 發(fā)，以達(dá)到節(jié)省資源和縮短消息生成的時間。另外，讀取內(nèi)存相對讀取數(shù)據(jù)庫所需的時間也 減少了很多。下面通過應(yīng)用中的實例對優(yōu)化前后所需的系統(tǒng)資源和時間進行測試統(tǒng)計。對優(yōu)化前后的消息反饋時間和系統(tǒng)資源兩方面進行數(shù)據(jù)統(tǒng)計，實驗使用的環(huán)境如下硬件環(huán)境AMD雙核2. 5G主頻；2G內(nèi)存軟件環(huán)境Windows XP SP3 ；網(wǎng)管平臺版本V3. 02. 01. 00B3 ；基站使用仿真基站 (也在服務(wù)器本地運行)。在本次測試中只模擬一個基站上電后上報版本數(shù)據(jù)的情況。網(wǎng)管平臺服務(wù)器沒有 任何其他負(fù)載?；臼褂玫氖欠抡娉绦?只是用程序模擬基站進行一些必要消息的返回)， 所以網(wǎng)絡(luò)通信延遲和基站內(nèi)部處理時間的長度都將比真實環(huán)境大大減少。下面是優(yōu)化前后在時間上的比較。因為優(yōu)化后反饋消息機制的性能基本不受上述因素的影響，而原有流程反饋消息 機制的性能受上述因素影響較大，所以上面提供的理想環(huán)境將會使原有流程反饋消息機制 的性能達(dá)到最好效果。圖4中的數(shù)據(jù)就是在這種對原有流程十分有利的環(huán)境下兩種性能參 數(shù)對比。圖4是從統(tǒng)一網(wǎng)管平臺的通信層監(jiān)聽器收到基站上報消息到反饋消息發(fā)送完為 止的時間(縱軸)，共進行了 4次試驗(橫軸)。從圖表可以看到第一線條401所示的原有 流程反饋消息所需時間至少都在3秒以上，而第二線條402所示的優(yōu)化后反饋消息所需時 間最多也只需半秒。所述數(shù)據(jù)是在比較理想的測試環(huán)境下得到的，可以推斷的是當(dāng)服務(wù)器的負(fù)載壓力 上來后，原有流程的反饋時間將會更長。這是因為Java虛擬機可以調(diào)用的資源將會大大減 少，而JVM(JAVA虛擬機)在運行時調(diào)用反射機制需要的資源將不能得到滿足導(dǎo)致利用反射 機制創(chuàng)建實例變得更慢。而在優(yōu)化后的方案中由于不需要使用反射機制創(chuàng)建實例所以反饋 消息的時間受服務(wù)器壓力影響很少。另外，時間的縮短也幫助基站節(jié)省下系統(tǒng)資源，如果網(wǎng)管平臺能夠早一刻將反饋 消息發(fā)向基站不僅能減少基站重復(fù)發(fā)送版本上報消息的概率，而且還能使基站更早的結(jié)束 發(fā)送線程，釋放占用的資源，這些資源對于基站有限的系統(tǒng)資源來說是非常重要的。下面對系統(tǒng)資源占用做比較。下面通過Java虛擬機JVM中線程數(shù)量的多少來分析一下網(wǎng)管平臺服務(wù)器端系統(tǒng) 資源優(yōu)化前后的情況，圖5是在不同時刻統(tǒng)計的JVM中的線程數(shù)量。圖5中的第一線段數(shù)據(jù)501是通信層收到基站的版本上報信息時刻JVM中的線程 數(shù)。第二線段數(shù)據(jù)502和第三線段數(shù)據(jù)503分別是原有流程和優(yōu)化后反饋消息發(fā)向基站時 刻JVM中的線程數(shù)。從第二線段數(shù)據(jù)502與第一線段數(shù)據(jù)501的比較可以看出，為生成并發(fā)送反饋消 息原有流程需要使用6條以上的線程，從第三線段數(shù)據(jù)503與第一線段數(shù)據(jù)501的比較可 以看出，在優(yōu)化后只需要1條線程。優(yōu)化后的線程數(shù)量比原有流程平均減少了 5條，可以推斷當(dāng)有大量基站同時上報時，節(jié)省的線程數(shù)量是很可觀的。由于系統(tǒng)中的每條線程都會 占用計算資源甚至是內(nèi)存資源，所以線程數(shù)量的減少可以推斷出系統(tǒng)計算和內(nèi)存資源的節(jié)省。設(shè)想如果有1000個基站同時上報版本那么優(yōu)化后的系統(tǒng)就會比原有流程的系統(tǒng) 中少開5000條左右的線程，節(jié)省的系統(tǒng)資源還是非?？捎^的。參照圖6所示，為本發(fā)明的對版本上報消息處理流程的性能優(yōu)化裝置，設(shè)置于網(wǎng) 管平臺，包括維護模塊601，用于當(dāng)網(wǎng)管平臺運行時，在內(nèi)存中維護基站的基本信息；查詢模塊602，用于在網(wǎng)管平臺通信層收到基站的版本上報消息后，提取其中的標(biāo) 識信息，并根據(jù)所述標(biāo)識信息在內(nèi)存中查詢該基站的基本信息；發(fā)送模塊603，用于在成功查詢到該基站的基本信息，則采用此基本信息構(gòu)造一個 阻止版本繼續(xù)上報消息發(fā)向基站。在本發(fā)明的一個優(yōu)選實施例中，所述查詢模塊602提取的標(biāo)識信息為地址信息。在本發(fā)明的一個優(yōu)選實施例中，所述裝置還包括轉(zhuǎn)發(fā)模塊604，用于在阻止版本 繼續(xù)上報消息發(fā)送成功后，再將版本上報消息轉(zhuǎn)發(fā)到邏輯處理層進行后續(xù)操作。其中，所述后續(xù)操作，包括版本入庫和版本下載。在本發(fā)明的又一個優(yōu)選實施例中，所述查詢模塊602，還用于當(dāng)在內(nèi)存中無法查詢 到該基站的基本信息，則結(jié)束流程，放棄處理所述基站的版本上報消息。綜上所述，優(yōu)化后網(wǎng)管平臺發(fā)送反饋消息的機制更加節(jié)省時間和系統(tǒng)資源，也更 加適合在大規(guī)?；镜沫h(huán)境中運行。需要指出的是，以上所述僅為本發(fā)明的優(yōu)選實施例，并不用于限制本發(fā)明，對于本 領(lǐng)域的技術(shù)人員來說，在不脫離本發(fā)明技術(shù)原理的前提下，本發(fā)明可以有各種更改和變化。 凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換等，均應(yīng)包含在本發(fā)明的權(quán)利要 求范圍之內(nèi)。
權(quán)利要求
一種對版本上報消息處理流程的性能優(yōu)化方法，其特征在于，包括當(dāng)網(wǎng)管平臺運行時，在內(nèi)存中維護基站的基本信息；網(wǎng)管平臺在通信層收到基站的版本上報消息后，提取其中的標(biāo)識信息，并根據(jù)所述標(biāo)識信息在內(nèi)存中查詢該基站的基本信息；若成功查詢到該基站的基本信息，則采用此基本信息構(gòu)造一個阻止版本繼續(xù)上報消息發(fā)向基站。
2.如權(quán)利要求1所述的方法，其特征在于，所述標(biāo)識信息為地址信息。
3.如權(quán)利要求1所述的方法，其特征在于，所述方法還包括 將版本上報消息轉(zhuǎn)發(fā)到邏輯處理層進行后續(xù)操作。
4.如權(quán)利要求3所述的方法，其特征在于， 所述后續(xù)操作，包括版本入庫和版本下載。
5.如權(quán)利要求1所述的方法，其特征在于，所述方法還包括若在內(nèi)存中無法查詢到該基站的基本信息，則結(jié)束流程，放棄處理所述基站的版本上 報消息。
6.一種對版本上報消息處理流程的性能優(yōu)化裝置，設(shè)置于網(wǎng)管平臺，其特征在于，包括維護模塊，用于當(dāng)網(wǎng)管平臺運行時，在內(nèi)存中維護基站的基本信息； 查詢模塊，用于在網(wǎng)管平臺通信層收到基站的版本上報消息后，提取其中的標(biāo)識信息， 并根據(jù)所述標(biāo)識信息在內(nèi)存中查詢該基站的基本信息；發(fā)送模塊，用于在成功查詢到該基站的基本信息，則采用此基本信息構(gòu)造一個阻止版 本繼續(xù)上報消息發(fā)向基站。
7.如權(quán)利要求6所述的裝置，其特征在于，所述查詢模塊提取的標(biāo)識信息為地址信息。
8.如權(quán)利要求6所述的裝置，其特征在于，所述裝置還包括 轉(zhuǎn)發(fā)模塊，用于將版本上報消息轉(zhuǎn)發(fā)到邏輯處理層進行后續(xù)操作。
9.如權(quán)利要求8所述的裝置，其特征在于， 所述后續(xù)操作，包括版本入庫和版本下載。
10.如權(quán)利要求6所述的裝置，其特征在于，所述查詢模塊，還用于當(dāng)在內(nèi)存中無法查詢到該基站的基本信息，則結(jié)束流程，放棄處 理所述基站的版本上報消息。
全文摘要
本發(fā)明公開了一種對版本上報消息處理流程的性能優(yōu)化方法及裝置，所述方法包括當(dāng)網(wǎng)管平臺運行時，在內(nèi)存中維護基站的基本信息；網(wǎng)管平臺在通信層收到基站的版本上報消息后，提取其中的標(biāo)識信息，并根據(jù)所述標(biāo)識信息在內(nèi)存中查詢該基站的基本信息；若成功查詢到該基站的基本信息，則采用此基本信息構(gòu)造一個阻止版本繼續(xù)上報消息發(fā)向基站。本發(fā)明通過將基站的基本信息存在統(tǒng)一網(wǎng)管平臺的內(nèi)存中，查詢基站的基本信息只需在內(nèi)存中進行，并且生成版本阻止上報消息只需在通信層中構(gòu)造就可發(fā)向基站，從而優(yōu)化了統(tǒng)一網(wǎng)管平臺版本上報消息處理流程，有效提高版本上報消息處理效率并同時減少資源消耗。
文檔編號H04W88/18GK101990225SQ20101054733
公開日2011年3月23日 申請日期2010年11月16日 優(yōu)先權(quán)日2010年11月16日
發(fā)明者周庶愷 申請人:中興通訊股份有限公司