專利名稱：一種尋呼消息發(fā)送裝置及方法
技術(shù)領(lǐng)域：
本發(fā)明涉及移動(dòng)通訊系統(tǒng)領(lǐng)域，尤其涉及一種降低主控板CPU消耗的尋呼消息發(fā)送裝置及方法。
背景技術(shù)：
隨著移動(dòng)通訊的發(fā)展和普及，3G以后的移動(dòng)通訊用戶越來越多，各種智能終端的出現(xiàn)以及智能終端上的應(yīng)用的發(fā)展(如手機(jī)QQ等應(yīng)用)，使得系統(tǒng)的尋呼消息發(fā)送量越來越大。大量的尋呼消息對(duì)主控板，尤其是BTS側(cè)(Base Transceiver Station,基站收發(fā)臺(tái))的主控板的CPU處理能力提出了挑戰(zhàn)。同時(shí)，由于尋呼還具有突發(fā)性，很容易造成主控板CPU瞬時(shí)沖高，而導(dǎo)致此時(shí)用戶接入困難，影響了用戶的感受以及呼叫連接建立成功率等 KPI (Key Performance Indicator,關(guān)鍵性能指標(biāo))指標(biāo)。目前，現(xiàn)有專利對(duì)CPU有的優(yōu)化主要是針對(duì)BSC側(cè)(Base Station Controller，基站控制單元)主控板，如專利CN200610011162提出了一種通過接口板對(duì)尋呼消息地址進(jìn)行復(fù)制后發(fā)往IP傳輸網(wǎng)的方法，減少BSC側(cè)主控板發(fā)送尋呼消息的量以達(dá)到降低主控板CPU 利用率的目的。但現(xiàn)在網(wǎng)絡(luò)的情況一般LAC(Location Area Code,位置區(qū)碼)和子網(wǎng)劃分比較大，這樣造成的結(jié)果是一個(gè)BTS需要承受的尋呼量近乎于一個(gè)BSC的總尋呼量，因此， 尋呼對(duì)于BTS的主控板影響更大。CN200610011162提出的方法無(wú)法解決尋呼對(duì)BTS側(cè)主控板CPU的沖擊。

發(fā)明內(nèi)容
為了減少尋呼對(duì)BTS主控板CPU的沖擊，避免主控板CPU利用率過高而導(dǎo)致用戶接入困難等問題，本發(fā)明提出了一種尋呼消息發(fā)送裝置及方法，以解決尋呼對(duì)BTS主控板 CPU的沖擊問題。為達(dá)到上述目的，本發(fā)明的技術(shù)方案是這樣實(shí)現(xiàn)的一種尋呼消息發(fā)送裝置，包括尋呼消息識(shí)別單元，用于識(shí)別尋呼消息并根據(jù)不同的尋呼消息類型確定尋呼消息的廣播范圍；微碼廣播單元，用于根據(jù)尋呼消息識(shí)別單元確定的廣播范圍把尋呼消息廣播給尋呼消息處理單元；尋呼消息處理單元，用于判斷當(dāng)所述尋呼消息的目的載扇是當(dāng)前配置的載扇信息時(shí)，發(fā)送所述尋呼消息。具體地，尋呼消息識(shí)別單元根據(jù)尋呼消息的UDP端口號(hào)和消息標(biāo)識(shí)進(jìn)行識(shí)別。優(yōu)選地，所述微碼廣播單元設(shè)置在主控板的微碼中。優(yōu)選地，所述尋呼消息處理單元設(shè)置在信道板上。所述尋呼消息處理單元還用于判斷當(dāng)所述尋呼消息的目的載扇不是當(dāng)前配置的載扇信息時(shí)，丟棄所述尋呼消息。一種尋呼消息發(fā)送方法，該方法包括尋呼消息識(shí)別單元識(shí)別尋呼消息并根據(jù)不同的尋呼消息類型確定尋呼消息的廣播范圍；微碼廣播單元根據(jù)尋呼消息識(shí)別單元確定的廣播范圍把尋呼消息廣播給相應(yīng)的信道板；尋呼消息處理單元判斷當(dāng)所述尋呼消息的目的載扇是當(dāng)前配置的載扇信息時(shí)，發(fā)送所述尋呼消息。與現(xiàn)有技術(shù)相比，本發(fā)明避免了 BTS主控板CPU參與尋呼消息的發(fā)送，解決了尋呼導(dǎo)致主控板CPU利用率過高的問題，同時(shí)解決了由于尋呼大導(dǎo)致CPU利用率過高進(jìn)而導(dǎo)致用戶接入困難的問題。此外，由于每個(gè)信道板只處理需要自己處理的尋呼，實(shí)際形成了一個(gè)分布式系統(tǒng)，這樣對(duì)于信道板而言，這種尋呼消息發(fā)送方法與原來的尋呼消息發(fā)送方法對(duì)信道板CPU的沖擊基本相同。達(dá)到了改善主控板CPU利用率的同時(shí)，沒有使的信道板CPU 利用率有較大升高的效果。


圖I是本發(fā)明實(shí)現(xiàn)尋呼消息發(fā)送裝置的結(jié)構(gòu)示意圖；圖2是本發(fā)明實(shí)現(xiàn)尋呼消息發(fā)送方法的流程圖。
具體實(shí)施例方式下面結(jié)合附圖對(duì)本發(fā)明實(shí)現(xiàn)尋呼消息發(fā)送裝置和方法進(jìn)行說明。請(qǐng)參閱圖I所示，其是本發(fā)明實(shí)現(xiàn)尋呼消息發(fā)送裝置的結(jié)構(gòu)示意圖。實(shí)現(xiàn)尋呼消息發(fā)送的裝置包括尋呼消息識(shí)別單元10，微碼廣播單元20，尋呼消息處理單元30，其中，尋呼消息識(shí)別單元10用于識(shí)別出BSC發(fā)給BTS的消息中屬于尋呼的消息，并根據(jù)不同的尋呼消息類型決定尋呼消息的廣播范圍，輸出給微碼廣播單元。微碼廣播單元20用于接收尋呼消息識(shí)別單元輸出的廣播范圍，把尋呼消息廣播給相應(yīng)的信道板。該裝置駐留在主控板的微碼中，其運(yùn)行不耗費(fèi)單板CPU資源。尋呼消息處理單元30駐留在信道板上，接收微碼廣播單元廣播出的尋呼消息，用于判斷當(dāng)所述尋呼消息的目的載扇是當(dāng)前配置的載扇信息時(shí)，發(fā)送所述尋呼消息；否則，丟棄該尋呼消息。 具體地，所述尋呼消息識(shí)別單元10根據(jù)該消息發(fā)送的UDP (User Datagram Protocol，用戶數(shù)據(jù)包協(xié)議)端口號(hào)以及消息標(biāo)識(shí)等信息識(shí)別出該消息是否為尋呼消息以及尋呼消息的類型優(yōu)選地，該裝置還包括輸入接口和輸出接口，其中，輸出接口用于接收BSC側(cè)發(fā)給 BTS的消息，輸出接口用于發(fā)送該尋呼消息給終端。該尋呼消息處理單元30發(fā)送尋呼消息具體為該尋呼消息處理單元30通過把尋呼消息打包成空口的控制信道包，再通過空口發(fā)送給終端。請(qǐng)參閱圖2所示，描述了本發(fā)明實(shí)現(xiàn)降低主控板CPU消耗的尋呼消息發(fā)送的處理流程，該處理步驟如下下面給出本發(fā)明的具體運(yùn)用實(shí)例。S20UBSC 發(fā)送消息給 BTS ；S202、當(dāng)一條消息從BSC發(fā)給BTS后，尋呼消息識(shí)別單元根據(jù)該消息發(fā)送的UDP端口號(hào)以及消息標(biāo)識(shí)等信息識(shí)別出該消息是否為尋呼消息以及尋呼消息的類型，若該消息不是尋呼消息，則執(zhí)行正常處理流程，本流程結(jié)束；若該消息是尋呼消息則轉(zhuǎn)入S203。S203、尋呼消息識(shí)別單元根據(jù)尋呼消息的類型，匹配相應(yīng)的尋呼范圍，輸出給微碼廣播單元。S204、微碼廣播單元根據(jù)尋呼消息識(shí)別單元輸出的廣播范圍，把該尋呼廣播給相應(yīng)的信道板。S205、尋呼消息處理單元收到微碼廣播單元發(fā)來的尋呼消息，判斷是否需要本板進(jìn)行處理。若是則轉(zhuǎn)入步驟S206 ;若否，則丟棄該尋呼消息并結(jié)束本流程。具體地，尋呼消息處理單元接收來自微碼廣播單元的廣播出來的尋呼消息，對(duì)比該尋呼消息中的目的載扇信息與當(dāng)前本信道板配置的載扇信息，若目的載扇為本信道板配置的載扇，則處理；否則丟棄。S206、尋呼消息處理單元在空口控制信道發(fā)送尋呼消息。具體地，尋呼消息處理單元把尋呼消息打包成空口的控制信道包，然后通過空口發(fā)送給終端。與現(xiàn)有技術(shù)相比，本發(fā)明實(shí)現(xiàn)尋呼發(fā)送裝置和方法由尋呼消息識(shí)別單元，微碼廣播單元和尋呼消息處理單元構(gòu)成。由于微碼廣播單元的引入，完全避免了 BTS主控板CPU參與尋呼消息的發(fā)送，完全解決了尋呼導(dǎo)致主控板CPU利用率過高的問題，同時(shí)解決了由于尋呼大導(dǎo)致CPU利用率過高進(jìn)而導(dǎo)致用戶接入困難的問題。此外，由于每個(gè)信道板只處理需要自己處理的尋呼，實(shí)際形成了一個(gè)分布式系統(tǒng)，這樣對(duì)于信道板而言，這種尋呼消息發(fā)送方法與原來的尋呼消息發(fā)送方法對(duì)信道板CPU的沖擊基本相同。達(dá)到了改善主控板CPU 利用率的同時(shí)，沒有使信道板CPU利用率有較大升高的效果。以上僅為本發(fā)明的優(yōu)選實(shí)施案例而已，并不用于限制本發(fā)明，對(duì)于本領(lǐng)域的技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種尋呼消息發(fā)送裝置，其特征在于，包括尋呼消息識(shí)別單元，用于識(shí)別尋呼消息并根據(jù)不同的尋呼消息類型確定尋呼消息的廣播范圍；微碼廣播單元，用于根據(jù)尋呼消息識(shí)別單元確定的廣播范圍把尋呼消息廣播給尋呼消息處理單元；尋呼消息處理單元，用于判斷當(dāng)所述尋呼消息的目的載扇是當(dāng)前配置的載扇信息時(shí)， 發(fā)送所述尋呼消息。
2.根據(jù)權(quán)利要求I所述裝置，其特征在于，所述用于識(shí)別尋呼消息并根據(jù)不同的尋呼消息類型確定尋呼消息的廣播范圍具體為尋呼消息識(shí)別單元根據(jù)尋呼消息的UDP端口號(hào)和消息標(biāo)識(shí)進(jìn)行識(shí)別。
3.根據(jù)權(quán)利要求I所述裝置，其特征在于，所述微碼廣播單元設(shè)置在主控板的微碼中。
4.根據(jù)權(quán)利要求I所述裝置，其特征在于，所述尋呼消息處理單元設(shè)置在信道板上。
5.根據(jù)權(quán)利要求I所述裝置，其特征在于，所述尋呼消息處理單元還用于判斷當(dāng)所述尋呼消息的目的載扇不是當(dāng)前配置的載扇信息時(shí)，丟棄所述尋呼消息。
6.一種尋呼消息發(fā)送方法，該方法包括尋呼消息識(shí)別單元識(shí)別尋呼消息并根據(jù)不同的尋呼消息類型確定尋呼消息的廣播范圍；微碼廣播單元根據(jù)尋呼消息識(shí)別單元確定的廣播范圍把尋呼消息廣播給相應(yīng)的信道板；尋呼消息處理單元判斷當(dāng)所述尋呼消息的目的載扇是當(dāng)前配置的載扇信息時(shí)，發(fā)送所述尋呼消息。
7.根據(jù)權(quán)利要求6所述方法，其特征在于，所述尋呼消息識(shí)別單元識(shí)別尋呼消息并根據(jù)不同的尋呼消息類型確定尋呼消息的廣播范圍具體為尋呼消息識(shí)別單元根據(jù)尋呼消息的UDP端口號(hào)和消息標(biāo)識(shí)進(jìn)行識(shí)別。
8.根據(jù)權(quán)利要求6所述方法，其特征在于，所述尋呼消息處理單元還用于判斷當(dāng)所述尋呼消息的目的載扇不是當(dāng)前配置的載扇信息時(shí)，丟棄所述尋呼消息。
全文摘要
本發(fā)明公開了一種尋呼消息發(fā)送裝置及方法，該裝置包括尋呼消息識(shí)別單元，用于識(shí)別尋呼消息并根據(jù)不同的尋呼消息類型確定尋呼消息的廣播范圍；微碼廣播單元，用于根據(jù)尋呼消息識(shí)別單元確定的廣播范圍把尋呼消息廣播給尋呼消息處理單元；尋呼消息處理單元，用于判斷當(dāng)所述尋呼消息的目的載扇是當(dāng)前配置的載扇信息時(shí)，發(fā)送所述尋呼消息。與現(xiàn)有技術(shù)相比，本發(fā)明避免了BTS主控板CPU參與尋呼消息的發(fā)送，解決了尋呼導(dǎo)致主控板CPU利用率過高的問題，同時(shí)解決了由于尋呼大導(dǎo)致CPU利用率過高進(jìn)而導(dǎo)致用戶接入困難的問題。
文檔編號(hào)H04W4/06GK102595332SQ20121002538
公開日2012年7月18日 申請(qǐng)日期2012年2月6日 優(yōu)先權(quán)日2012年2月6日
發(fā)明者關(guān)勛 申請(qǐng)人:中興通訊股份有限公司