一種基于IuPS接口分析數(shù)據(jù)業(yè)務(wù)占用3G無(wú)線信道的方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及無(wú)線通信領(lǐng)域，特別涉及一種基于IuPS接口分析數(shù)據(jù)業(yè)務(wù)占用3G無(wú)線信道的方法。
【背景技術(shù)】
[0002]無(wú)線信道資源為移動(dòng)通信網(wǎng)絡(luò)最重要且有限的資源，隨著移動(dòng)數(shù)據(jù)業(yè)務(wù)迅猛發(fā)展，3G(TD-SCDMA、WCDMA)網(wǎng)絡(luò)無(wú)線資源優(yōu)化成為運(yùn)營(yíng)商網(wǎng)絡(luò)管理的重中之重。
[0003]在3GPP規(guī)范中定義了三種無(wú)線信道，分別是邏輯信道、傳輸信道、物理信道，信道間有約定的映射關(guān)系。邏輯信道通?？梢苑譃?控制信道和業(yè)務(wù)信道；傳輸信道通過(guò)可分為:專用信道和公共信道；物理信道分為:上行物理信道、下行物理信道和同步信道。
[0004]一次數(shù)據(jù)業(yè)務(wù)的發(fā)起，首先要通過(guò)控制信道建立信令連接，并分配業(yè)務(wù)信道供數(shù)據(jù)傳輸使用，業(yè)務(wù)過(guò)程中RNC要實(shí)時(shí)監(jiān)控MS狀態(tài)，根據(jù)具體需求釋放及分配無(wú)線信道資源。由于3G網(wǎng)絡(luò)具有對(duì)無(wú)線資源靈活管理的特點(diǎn)，某些與服務(wù)端具有心跳檢測(cè)模式的IM業(yè)務(wù)、M2M業(yè)務(wù)，以及具備節(jié)電模式的終端會(huì)頻繁請(qǐng)求和釋放無(wú)線信道資源，這將導(dǎo)致信道資源頻繁占用，在上述業(yè)務(wù)及終端過(guò)多的情況下，極易引起RNC、SGSN設(shè)備過(guò)載，嚴(yán)重情況下將導(dǎo)致網(wǎng)絡(luò)癱瘓。因此針對(duì)數(shù)據(jù)業(yè)務(wù)引發(fā)的無(wú)線資源占用，為現(xiàn)階段運(yùn)營(yíng)商無(wú)線網(wǎng)絡(luò)優(yōu)化的重點(diǎn)之一。
[0005]現(xiàn)階段運(yùn)營(yíng)商針對(duì)無(wú)線資源管理與優(yōu)化分析主要基于NodeB-RNC間的Iub接口，或RNC-SGSN間的IuPS接口實(shí)現(xiàn)，相關(guān)接口示意圖如圖1所示。
[0006]Iub接口最靠近空口，基于Iub接口可準(zhǔn)確的分析無(wú)線資源的占用情況，RNC-SGSN間的IuPS接口雖無(wú)法直接分析無(wú)線資源占用情況，但通過(guò)對(duì)MS PMM狀態(tài)迀移的跟蹤，可推測(cè)得出無(wú)線資源占用情況。
[0007]Iub接口多由ATM承載，采集成本高，協(xié)議棧復(fù)雜?；贗ub接口解析信道映射關(guān)系要通過(guò)跟蹤動(dòng)態(tài)信令來(lái)識(shí)別，實(shí)現(xiàn)極為復(fù)雜，且針對(duì)加密協(xié)議解析需要關(guān)聯(lián)IuPS、IuCS接口消息，若鏈路采集范圍不全，會(huì)導(dǎo)致信令無(wú)法解析，影響數(shù)據(jù)準(zhǔn)確性。
[0008]現(xiàn)階段基于IuPS接口實(shí)現(xiàn)3G(TD-SCDMA、WCDMA)無(wú)線資源占用分析方案主要通過(guò)跟蹤MS PMM狀態(tài)迀移的方式來(lái)實(shí)現(xiàn)，這種方案可分析無(wú)線資源占用情況，但需跟蹤MS PMM狀態(tài)迀移過(guò)程，解析開銷較大。
[0009]此外，上述兩種方案都是基于控制面信令進(jìn)行數(shù)據(jù)分析，均未結(jié)合用戶面數(shù)據(jù)關(guān)聯(lián)分析，無(wú)法定位引起無(wú)線資源占用的具體原因。

【發(fā)明內(nèi)容】

[0010]鑒于現(xiàn)有技術(shù)中存在的問(wèn)題，本發(fā)明目的在于提供一種基于IuPS接口分析數(shù)據(jù)業(yè)務(wù)占用3G無(wú)線信道的方法，從而針對(duì)現(xiàn)有分析方案存在的局限性，通過(guò)IuPS接口控制面信令，結(jié)合IuPS接口用戶面數(shù)據(jù)，對(duì)3G(TD-SCDMA、WCDMA)無(wú)線資源占用情況及成因進(jìn)行深入分析。
[0011]根據(jù)本發(fā)明的一個(gè)方面，提供了一種基于IuPS接口分析數(shù)據(jù)業(yè)務(wù)占用3G無(wú)線信道的方法，包括步驟:
[0012]在IuPS接口捕獲MS發(fā)出的Service Request消息及后續(xù)信令，根據(jù)ServiceRequest消息特征，結(jié)合后續(xù)信令消息來(lái)判斷MS的PMM狀態(tài)從IDEL向CONNECTED迀移，以判別MS是否產(chǎn)生無(wú)線控制信道占用；同時(shí)對(duì)捕獲到的Service Request消息及其后續(xù)信令消息進(jìn)行關(guān)聯(lián)分析，通過(guò)關(guān)聯(lián)用戶面數(shù)據(jù)，獲得應(yīng)用IP地址；通過(guò)DNS信令獲知域名與應(yīng)用IP地址的對(duì)應(yīng)關(guān)系，根據(jù)域名獲知具體的應(yīng)用類型，以確定是何種業(yè)務(wù)引起無(wú)線控制信道占用。優(yōu)選的，在Service Request消息中的Service Type為I的情況下，ServiceRequest消息后如果有安全模式控制流程，則認(rèn)為是在PMM-1DLE狀態(tài)發(fā)起的業(yè)務(wù)請(qǐng)求，即可確認(rèn)為產(chǎn)生了一次RRC連接建立并分配了業(yè)務(wù)信道。
[0013]優(yōu)選的，在Service Request消息中的Service Type為2的情況下，貝Ij認(rèn)為產(chǎn)生了一次PCH信道占用，同時(shí)產(chǎn)生了一次RRC連接建立并分配了業(yè)務(wù)信道。
[0014]優(yōu)選的，在捕獲到的Service Request消息及其后續(xù)信令消息后，根據(jù)SCCP本地參考號(hào)關(guān)聯(lián)一個(gè)會(huì)話內(nèi)的控制面信令，并基于控制面信令完成PMM狀態(tài)迀移判斷，以及用戶身份、位置信息識(shí)別，并通過(guò)RAB指配消息攜帶信息關(guān)聯(lián)用戶面數(shù)據(jù)。
[0015]優(yōu)選的，判斷是在PMM-1DLE狀態(tài)發(fā)起的業(yè)務(wù)請(qǐng)求后，記錄以下內(nèi)容:
[0016](I)信道占用時(shí)間-Service Request消息的發(fā)起時(shí)間；
[0017](2)觸發(fā)原因:上行消息觸發(fā)；
[0018](3)用戶身份信息:基于C0MM0NID消息RNAP層提??；
[0019](4)用戶位置信息:基于Service Request消息RNAP層提取的LAC/SAC ；
[0020](5)觸發(fā)信令信道占用的業(yè)務(wù)信息:關(guān)聯(lián)后的第一個(gè)用戶面消息的應(yīng)用層目的IPo
[0021]優(yōu)選的，判斷產(chǎn)生了一次PCH信道占用后，記錄以下內(nèi)容:
[0022](I)信道占用時(shí)間:Service Request消息發(fā)起時(shí)間；
[0023](2)觸發(fā)原因:下行消息觸發(fā)；
[0024](3)用戶身份信息:基于C0MM0NID消息RNAP層提??；
[0025](4)用戶位置信息:基于Service Request消息RNAP層提取的LAC/SAC ；
[0026](5)觸發(fā)信令信道占用的業(yè)務(wù)信息:關(guān)聯(lián)后的第一個(gè)用戶面消息的應(yīng)用層源IP。
[0027]優(yōu)選的，通過(guò)DNS信令建立一張動(dòng)態(tài)維護(hù)的應(yīng)用IP、域名、業(yè)務(wù)類型對(duì)應(yīng)關(guān)系表，上、下行業(yè)務(wù)觸發(fā)的信令信道占用分析過(guò)程記錄中的應(yīng)用層IP可通過(guò)這張表關(guān)聯(lián)到具體業(yè)務(wù)類型，以便確認(rèn)是哪種業(yè)務(wù)導(dǎo)致信令信道占用
【附圖說(shuō)明】
[0028]圖1例示了現(xiàn)有技術(shù)中3G無(wú)線網(wǎng)絡(luò)設(shè)備間的接口類型；
[0029]圖2例示了 3G PS域MS發(fā)起數(shù)據(jù)業(yè)務(wù)的流程圖；
[0030]圖3例示了 3G PS域網(wǎng)絡(luò)發(fā)起業(yè)務(wù)的流程圖；
[0031]圖4例示了本發(fā)明實(shí)施例數(shù)據(jù)業(yè)務(wù)上行消息觸發(fā)的無(wú)線信道占用識(shí)別CDR記錄信息的提取不意圖；
[0032]圖5例示了本發(fā)明實(shí)施例數(shù)據(jù)業(yè)務(wù)下行消息觸發(fā)的無(wú)線信道占用識(shí)別CDR記錄信息的提取不意圖；
[0033]圖6例示了本發(fā)明實(shí)施例獲知應(yīng)用類型的示意圖。
【具體實(shí)施方式】
[0034]為使本發(fā)明的上述目的、特征和優(yōu)點(diǎn)更加明顯易懂，下面結(jié)合附圖和【具體實(shí)施方式】對(duì)本發(fā)明作進(jìn)一步詳細(xì)的說(shuō)明。
[0035]為了說(shuō)明本發(fā)明的實(shí)現(xiàn)方式，需要首先從本發(fā)明的技術(shù)背景進(jìn)行介紹。
[0036]在3G(TD-SCDMA、WCDMA) PS 域，MS 附著網(wǎng)絡(luò)后，有兩種狀態(tài):PMM_IDLE、PMM-CONNECTEDo MS無(wú)數(shù)據(jù)傳輸時(shí)，工作在PMM-1DLE狀態(tài)，這時(shí)的MS不占用無(wú)線信道資源，MS如要發(fā)起業(yè)務(wù)，需先通過(guò)控制信道建立RRC連接，然后按要求分配業(yè)務(wù)信道資源。RRC連接及相應(yīng)傳輸承載建立完成后，MS可正常與服務(wù)端通信，此時(shí)MS工作在PMM-CONNECTED狀態(tài)，在后續(xù)MS無(wú)數(shù)據(jù)業(yè)務(wù)流量傳輸情況下，如RRC-Connect1n-Release timer超時(shí)或MS端發(fā)起釋放連接請(qǐng)求，RNC將向SGSN發(fā)起Iu釋放請(qǐng)求，SGSN收到該消息后，發(fā)起Iu釋放流程，RNC釋放傳輸承載及RRC連接后，回Iu釋放完成消息，MS回到PMM-1DLE狀態(tài)。
[0037]圖2例示了 3G PS域MS發(fā)起數(shù)據(jù)業(yè)務(wù)的流程圖，如圖2所示，所述流程包括:
[0038](I)如果不存在CS通信，則MS建立RRC連接。連接建立過(guò)程消息通過(guò)控制信道傳輸，并分配專用業(yè)務(wù)信道。
[0039](2)MS 向 SGSN 發(fā)送 Service Request 消息。Service Type 指示所請(qǐng)求的業(yè)務(wù)。Service Type會(huì)指示出:數(shù)據(jù)或信令。
[0040]如果Service Type指示為數(shù)據(jù)，則會(huì)在MS和SGSN間建立信令連接，分配激活I(lǐng)3DP上下文的資源，比如為激活PDP上下文的RAB建立。
[0041]如果Service Type指示為信令，則會(huì)在MS和SGSN間建立信令連接從而發(fā)生上層信令消息，比如Activate PDP Context Request。不為激活PDP上下文分配資源。
[0042](3)如果MS是在PMM-1DLE狀態(tài)發(fā)起的業(yè)務(wù)請(qǐng)求，則SGSN會(huì)進(jìn)行安全模式控制流程。
[0043](4)網(wǎng)絡(luò)處于PMM-CONNECTED狀態(tài)且Service Type指示為數(shù)據(jù)時(shí)，若業(yè)務(wù)請(qǐng)求被SGSN接受，則SGSN會(huì)向MS發(fā)送Service Accept消息。若Service Type指示為數(shù)據(jù)，SGSN會(huì)發(fā)送Rad1 Access Bearer Assignment Request消息，除了擁有最大上行比特率、下行比特率為O的PDP上下文之外，為每個(gè)激活的PDP上下文重建RAB。
[0044](5) RNC指示MS已經(jīng)建立新的無(wú)線接入承載標(biāo)識(shí)和相應(yīng)的RAB ID。
[0045](6) SRNC 回復(fù) Rad1 Access Bearer Assignment Response 消息，并在 Iu 接口上建立GTP隧道做為用戶面數(shù)據(jù)傳輸通道。
[0046](7) SGSN發(fā)起PDP上下文修改。
[0047](8) MS發(fā)送上行包。
[0048]圖3例示了 3G PS域網(wǎng)絡(luò)發(fā)起業(yè)務(wù)的流程圖，如圖3所示，所述流程包括:
[0049](I) SGSN 收到處在 PMM-1DLE 的 MS 的下行 PDP PDU。
[0050](2) SGSN發(fā)送尋呼消息給RNC，RNC尋呼通過(guò)發(fā)送尋呼消息尋呼MS。
[0051](3)如果沒(méi)有CS通路，MS建立RRC連接。
[0052](4)MS發(fā)送Service Request消息給SGSN，服務(wù)類型為尋呼響應(yīng)。此時(shí)，SGSN可能發(fā)起一個(gè)鑒權(quán)。SGSN知道下行包是否需要RAB重建。
[0053](5) SGSN指定加密模式。
[0054](6)如果F1DP上下文的資源重建，SGSN發(fā)送Rad1 Access BearerAssignmentRequest0 RNC 發(fā)送 Rad1 Access BearerAssignment Response 消息給 SGSN，指明GTP隧道已經(jīng)建立在Iu接口，并且無(wú)線接入承載已經(jīng)在RNC和MS之間建立。
[0055](7) SGSN發(fā)起PDP上下文修改。
[0056](8) SGSN發(fā)送下行包。
[0057]通過(guò)以上分析可知:RRC連接建立與釋放流程涉及控制信道占用及業(yè)務(wù)信道分配與釋放，基于Iub接口可實(shí)現(xiàn)RRC連接分析，IuPS接口無(wú)法直接實(shí)現(xiàn)RRC連接分析，但可通過(guò)核心網(wǎng)信令對(duì)RRC連接做推測(cè)性分析，由于RRC連接建立與釋放流程成對(duì)出現(xiàn)，因此，基于核心網(wǎng)信令對(duì)RRC連接只做建立流程的推測(cè)分析即可。
[0058]結(jié)合3G數(shù)據(jù)業(yè)務(wù)流程分析，無(wú)論是MS發(fā)起，還是網(wǎng)絡(luò)發(fā)起的數(shù)據(jù)業(yè)務(wù)流程，且無(wú)論 MS 的 PMM 狀態(tài)是 PMM-1DLE 還是 PMM-CONNECTED，MS 都會(huì)發(fā)起 Service Request 消息，這個(gè)消息在Iub、IuPS接口都能捕獲。
[0059]因此，我們可以基于捕獲到的Service Request消息分析到很多內(nèi)容。
[0060]Service Request 流程用途說(shuō)明:
[0061]DPMM-1DLE狀態(tài)的MS利用業(yè)務(wù)請(qǐng)求程序向SGSN請(qǐng)求建立一條安全的連接，用于發(fā)送上行鏈路信令消息或用戶數(shù)據(jù)；
[0062]2) MS在PMM-CONNECTED狀態(tài)時(shí)，也可為已激活的PDP上下文請(qǐng)求資源預(yù)留
[0063]Se