WRNC系統(tǒng)中單用戶(hù)跟蹤的設(shè)計(jì)
本文引入一定的機(jī)制，使無(wú)線(xiàn)網(wǎng)絡(luò)控制器RNC（Radio Network Control）內(nèi)部能夠方便、準(zhǔn)確地收集到單用戶(hù)數(shù)據(jù)處理中各個(gè)環(huán)節(jié)的統(tǒng)計(jì)信息，便于快速地對(duì)單用戶(hù)信息進(jìn)行統(tǒng)計(jì)與核對(duì)，提高問(wèn)題分析的效率。
1 速率問(wèn)題的產(chǎn)生及現(xiàn)象
RNC內(nèi)部速率問(wèn)題的產(chǎn)生主要有3個(gè)原因：(1)用戶(hù)面處理數(shù)據(jù)包不當(dāng)，異常丟包；(2)控制面?zhèn)鬟f給用戶(hù)面的接續(xù)參數(shù)有誤，用戶(hù)面與承載無(wú)法銜接；(3)用戶(hù)面自身在處理各種接續(xù)關(guān)系時(shí)處理不當(dāng)。
在實(shí)際應(yīng)用中幾種不同情況的速率現(xiàn)象分別為：(1)HSDPA/HSUPA業(yè)務(wù)進(jìn)行時(shí)上下行速率不穩(wěn)定；(2)HSDPA/HSUPA業(yè)務(wù)進(jìn)行過(guò)程中出現(xiàn)速率掉鉤；(3)HSDPA/HSUPA PS業(yè)務(wù)無(wú)法達(dá)到簽約的預(yù)期速率；（4） 速 率正常。
2 傳統(tǒng)的定位方法及缺陷
目前，傳統(tǒng)的速率定位方法分為3種：SHELL命令定位、DSP打印定位和信令跟蹤定位。
但是對(duì)于外場(chǎng)定位來(lái)說(shuō)，這些傳統(tǒng)的定位手段卻很難實(shí)現(xiàn)。首先，SHELL命令定位，外場(chǎng)接口板數(shù)量多，承載著不同的業(yè)務(wù)，需要在接口板之間輪流輸入SHELL命令，顯得極其麻煩，同時(shí)SHELL命令只能跟蹤所有的業(yè)務(wù)流量信息，無(wú)法針對(duì)特定用戶(hù)，缺少針對(duì)性。其次，外場(chǎng)對(duì)于打印有嚴(yán)格的要求，一般不允許開(kāi)啟內(nèi)部打印，正式的商用局資源本來(lái)就比較少，開(kāi)啟內(nèi)部繁多的打印，會(huì)影響整個(gè)系統(tǒng)的運(yùn)行。最后，信令跟蹤只是記錄控制面的基本信息，對(duì)于用戶(hù)面的檢查無(wú)法起到真正的幫助作用。
因此對(duì)于此類(lèi)問(wèn)題，需要有一個(gè)良好的定位方法將問(wèn)題鎖定在具體的接口或者FP層面上。單用戶(hù)跟蹤正是針對(duì)這個(gè)缺陷設(shè)計(jì)的，其優(yōu)點(diǎn)是：(1)數(shù)據(jù)的上報(bào)通過(guò)后臺(tái)信令跟蹤來(lái)記載，利于觀(guān)測(cè)；(2)數(shù)據(jù)跟蹤以FP為單位，直接定位到業(yè)務(wù)通道，定位準(zhǔn)確；(3)對(duì)正常的設(shè)備運(yùn)行不會(huì)增加額外的開(kāi)銷(xiāo)，且不需要進(jìn)行多余的手工操作，使用方便。
3 單用戶(hù)跟蹤的設(shè)計(jì)及實(shí)現(xiàn)
3.1 WCDMA系統(tǒng)的整體概述
WCDMA系統(tǒng)主要由三大核心部分組成，分為核心網(wǎng)(CN)、無(wú)線(xiàn)網(wǎng)絡(luò)控制器(RNC)和基站(NodeB)。RNC連接著CN和NodeB，在整個(gè)WCDMA中起著舉足輕重的作用。RNC和RNC之間用IUR口連接。RNC分為CRNC(控制RNC)、SRNC(服務(wù)RNC)和DRNC(漂移RNC)三部分[5]。
3.2 單用戶(hù)跟蹤的數(shù)據(jù)流
RNC內(nèi)數(shù)據(jù)流的路徑分為兩條，一條是通過(guò)IUB口直接進(jìn)入SRNC，途經(jīng)IU口到達(dá)CN；另一條是通過(guò)IUB口先到達(dá)DRNC，再由DRNC經(jīng)IUR口到SRNC，最后到達(dá)CN[6]。如果能在每個(gè)結(jié)點(diǎn)處對(duì)各個(gè)FP的數(shù)據(jù)包進(jìn)行統(tǒng)計(jì)，對(duì)比各個(gè)結(jié)點(diǎn)數(shù)據(jù)的流量，就能迅速定位出數(shù)據(jù)丟失的接口和FP。
3.3 單用戶(hù)跟蹤的整體設(shè)計(jì)
UTRAN各個(gè)接口的協(xié)議架構(gòu)是按照一個(gè)通用的協(xié)議模型設(shè)計(jì)的，如圖1所示。設(shè)計(jì)的原則是層間和平面間在邏輯上相互獨(dú)立。從水平層面來(lái)看，協(xié)議結(jié)構(gòu)主要包括兩層：無(wú)線(xiàn)網(wǎng)絡(luò)層和傳輸網(wǎng)絡(luò)層。所有UTRAN相關(guān)問(wèn)題只與無(wú)線(xiàn)網(wǎng)絡(luò)層有關(guān)，傳輸網(wǎng)絡(luò)層只是UTRAN采用的標(biāo)準(zhǔn)化的傳輸技術(shù)，與UTRAN的特定功能無(wú)關(guān)。從垂直平面來(lái)看，協(xié)議結(jié)構(gòu)包括控制平面、用戶(hù)平面、傳輸網(wǎng)絡(luò)控制平面和傳輸網(wǎng)絡(luò)用戶(hù)平面[1]。
本設(shè)計(jì)根據(jù)UTRAN的協(xié)議架構(gòu)，分為以下幾個(gè)模塊：消息處理模塊、控制面、用戶(hù)面、承載管理模塊和信令跟蹤模塊。
整個(gè)單用戶(hù)跟蹤設(shè)計(jì)思路如圖2所示，其中實(shí)線(xiàn)代表控制流，虛線(xiàn)代表數(shù)據(jù)流。
對(duì)于控制信息來(lái)說(shuō)，后臺(tái)將媒體面跟蹤的任務(wù)分配到消息處理模塊（Daemon），Daemon通知控制面CP(Control Plane)和用戶(hù)面UP（User Plane）?？刂泼嬖诔休d鏈路建立和刪除時(shí)通知承載管理模塊BM（Bear Management,BM）建立和刪除相關(guān)的承載跟蹤。從消息中提取相關(guān)信息，并發(fā)送消息通知接口板，接口板收到消息后，設(shè)置好過(guò)濾條件，對(duì)處理的報(bào)文進(jìn)行過(guò)濾統(tǒng)計(jì)。
對(duì)于數(shù)據(jù)業(yè)務(wù)流來(lái)說(shuō)，收集跟蹤信息后，接口板和用戶(hù)面直接將跟蹤信息上報(bào)到Daemon。Daemon將消息的內(nèi)容進(jìn)行核對(duì)后上報(bào)給后臺(tái)。
3.4 單用戶(hù)跟蹤的實(shí)現(xiàn)流程
為了在現(xiàn)有體系的框架下順利實(shí)現(xiàn)各個(gè)接口FP的流量上報(bào)，設(shè)計(jì)如下2個(gè)流程：任務(wù)的啟動(dòng)和數(shù)據(jù)的上報(bào)及核對(duì)。[!--empirenews.page--]
3.4.1 媒體面單用戶(hù)跟蹤的啟動(dòng)
單用戶(hù)跟蹤的啟動(dòng)過(guò)程為：
(1)后臺(tái)向信令跟蹤模塊(ToolKit)發(fā)送EV_UE_MEDIA_START_REQ的請(qǐng)求消息。消息中攜帶需要跟蹤的IMSI號(hào)和跟蹤標(biāo)志位給ToolKit。
(2)ToolKit采取應(yīng)答處理機(jī)制，收到消息后立馬向后臺(tái)回響應(yīng)，告知消息已收到。ToolKit內(nèi)部維護(hù)了一張關(guān)于UE各種跟蹤任務(wù)的狀態(tài)表（TraceUE）。根據(jù)消息中的IMSI號(hào)來(lái)判斷，如果ToolKit模塊中未能查詢(xún)到保存的IMSI號(hào)，說(shuō)明該流程錯(cuò)誤，直接結(jié)束。若IMSI號(hào)存在，并且已處于跟蹤狀態(tài)，說(shuō)明跟蹤重復(fù)，直接結(jié)束。若IMSI號(hào)處于未跟蹤狀態(tài)，ToolKit將創(chuàng)建關(guān)于該UE的一個(gè)上下文，同時(shí)保存到TraceUE的信息中，以便將來(lái)查詢(xún)使用。
(3)ToolKit需要給消息處理模塊（Daemon）發(fā)送消息EV_START_MEDIA_TRACE。由Daemon根據(jù)不同的消息來(lái)決定需要給哪些模塊發(fā)送跟蹤消息。
(4)Daemon向用戶(hù)面發(fā)送媒體面啟動(dòng)的消息EV_START_MEDIA_TRACE。用戶(hù)面收到該跟蹤指示消息后將跟蹤信息記錄下來(lái)，使得在調(diào)用承載接口建立連接表時(shí)，指示此承載鏈路上的數(shù)據(jù)需要跟蹤，便于之后從用戶(hù)面直接上報(bào)數(shù)據(jù)量信息。
(5)Daemon向各個(gè)地面接口(IUB/IUR/IU)發(fā)送EV_START_MEDIA_TRACE消息，觸發(fā)各個(gè)地面接口向各自的底層鏈路發(fā)送跟蹤指示。
(6)各個(gè)地面標(biāo)準(zhǔn)模塊收到媒體面單用戶(hù)跟蹤消息后，根據(jù)IMSI號(hào)搜索各自保存的關(guān)于這個(gè)UE相關(guān)的傳輸層信息，啟動(dòng)消息發(fā)送機(jī)制，對(duì)和這個(gè)UE相關(guān)的承載，依次給承載管理模塊發(fā)送EV_START_LINK_TRACE消息，觸發(fā)關(guān)于這個(gè)UE的底層承載被標(biāo)記成跟蹤態(tài)。這條消息不僅需要攜帶該條承載鏈路建立時(shí)的所有信息(BearId、bindingID、TransportAddress等)，還要加上被媒體面跟蹤的標(biāo)志位。底層承載管理模塊BM收到該消息后，需要對(duì)承載信息進(jìn)行遍歷和核對(duì)，對(duì)確實(shí)需要跟蹤的承載鏈路進(jìn)行相關(guān)字段的標(biāo)記，便于以后統(tǒng)計(jì)時(shí)使用。
3.4.2 媒體面單用戶(hù)跟蹤的上報(bào)時(shí)間及核對(duì)
(1)上報(bào)時(shí)間對(duì)齊
數(shù)據(jù)的上報(bào)都是在一定時(shí)間內(nèi)累積的結(jié)果。為了保證業(yè)務(wù)數(shù)據(jù)統(tǒng)計(jì)的準(zhǔn)確性，必須確保各個(gè)單板上系統(tǒng)時(shí)間的一致性。為了保證這一點(diǎn)，采取統(tǒng)計(jì)初始清零時(shí)間和統(tǒng)計(jì)上報(bào)時(shí)間對(duì)齊的策略。
統(tǒng)計(jì)初始清零時(shí)間對(duì)齊：在承載鏈路建立的時(shí)候，接口板上對(duì)此鏈路對(duì)應(yīng)的統(tǒng)計(jì)信息清零。在用戶(hù)面處理板上也采用類(lèi)似的方式對(duì)相關(guān)承載上的統(tǒng)計(jì)清零。
統(tǒng)計(jì)上報(bào)的時(shí)間對(duì)齊通過(guò)兩種方式實(shí)現(xiàn)：(1)約定好上報(bào)的粒度，例如15 s、30 s、60 s等。(2)通過(guò)單板上絕對(duì)時(shí)間來(lái)對(duì)齊。例如在時(shí)間對(duì)齊的前提下，在每分鐘的15 s、30 s、45 s、60 s的時(shí)刻進(jìn)行上報(bào)。為了將上報(bào)時(shí)間對(duì)齊，在DSP上新維護(hù)一個(gè)記錄絕對(duì)時(shí)間的軟時(shí)鐘，軟時(shí)鐘的基準(zhǔn)通過(guò)HOST同步，HOST可以定期對(duì)DSP上的時(shí)鐘進(jìn)行校正。
(2)上報(bào)途徑
為使信息核對(duì)，設(shè)計(jì)了兩條上報(bào)途徑：(1)CP各個(gè)接口模塊與UP之間都有?；钕?，保活消息將觸發(fā)UP上報(bào)用戶(hù)在不同接口(IUB、IUR、IU)上的所有承載鏈路的統(tǒng)計(jì)。UP收到?；钕⒑螅l(fā)現(xiàn)該用戶(hù)被媒體面跟蹤，則調(diào)用數(shù)據(jù)上報(bào)接口上報(bào)統(tǒng)計(jì)，這時(shí)用戶(hù)面就會(huì)查詢(xún)啟動(dòng)時(shí)被跟蹤的承載信息。通過(guò)內(nèi)部機(jī)制，將跟蹤信息轉(zhuǎn)發(fā)到Daemon，直至送給后臺(tái)。(2)CP各個(gè)接口模塊在給UP發(fā)送?；钕r(shí)，發(fā)現(xiàn)該用戶(hù)被媒體面跟蹤，則給BM模塊發(fā)送數(shù)據(jù)上報(bào)請(qǐng)求消息EV_START_LINKTRACERPT_REQ，BM收到消息后，根據(jù)本地保存的跟蹤用戶(hù)信息，通知接口板。接口板將跟蹤信息上報(bào)到Daemon，直至后臺(tái)。
(3)統(tǒng)計(jì)信息的核對(duì)
用戶(hù)面在調(diào)用承載接口發(fā)送報(bào)文時(shí)，會(huì)根據(jù)接口中承載被跟蹤的信息進(jìn)行過(guò)濾。在接收?qǐng)?bào)文時(shí)，會(huì)根據(jù)承載連接表中的信息，對(duì)此報(bào)文進(jìn)行過(guò)濾。
對(duì)于接口板來(lái)說(shuō)，承載管理模塊需要對(duì)統(tǒng)計(jì)的信息設(shè)置過(guò)濾條件。對(duì)于不同的承載類(lèi)型，過(guò)濾條件是不一致的。在A(yíng)TM方式下，IUB、IUCS、IUR需要根據(jù)VPI、VCI、CID的信息來(lái)完成對(duì)出入網(wǎng)元信息的過(guò)濾，IUPS需要根據(jù)對(duì)端和本端的TEID來(lái)完成出入局的過(guò)濾。在IP方式下，IUB、IUCS、IUR根據(jù)本端IP地址和UDP端口號(hào)來(lái)完成出入網(wǎng)元的過(guò)濾，IUPS則需要本端和對(duì)端的TEID來(lái)判斷。
為了和用戶(hù)面核對(duì)統(tǒng)計(jì)信息，對(duì)于每一條的承載鏈路，控制面還需告知承載管理模塊過(guò)濾方向、接口類(lèi)型、鏈路屬性和用戶(hù)的全局標(biāo)識(shí)信息。
Daemon通過(guò)對(duì)兩種途徑上報(bào)的數(shù)據(jù)進(jìn)行匯總和核對(duì)，防止了統(tǒng)計(jì)信息的不一致，提高了信息上報(bào)的準(zhǔn)確性。
4 單用戶(hù)跟蹤的測(cè)試效果
本設(shè)計(jì)在WRNC系統(tǒng)中進(jìn)行了測(cè)試和驗(yàn)證。圖3是業(yè)務(wù)上報(bào)消息中的Iu口的信令解析。
其中包括單用戶(hù)跟蹤的一些統(tǒng)計(jì)信元。如：IuupUlPsRecvNum、IuupUlPsSendNum、IuupDlPsRecvNum和Iuup DlPsSendNum等，分別記錄上下行PS域的收發(fā)數(shù)據(jù)量。從該圖中可以看到IuUp的上行收發(fā)數(shù)據(jù)量都為21，代表此FP的數(shù)據(jù)收發(fā)正常，未出現(xiàn)異常情況。
從圖3中可以看到該方案成功地實(shí)現(xiàn)了業(yè)務(wù)數(shù)據(jù)的收集和上報(bào)。后臺(tái)的信令跟蹤清楚地記錄了各個(gè)標(biāo)準(zhǔn)接口中各個(gè)FP的類(lèi)型和數(shù)據(jù)的收發(fā)信息。
該方案實(shí)現(xiàn)了在RNC內(nèi)部各個(gè)接口用戶(hù)數(shù)據(jù)的上報(bào)和統(tǒng)計(jì)，徹底解決了傳統(tǒng)速率問(wèn)題定位的復(fù)雜性和不準(zhǔn)確性。定位準(zhǔn)確、利于觀(guān)測(cè)和便于操作使得該定位方法大大優(yōu)于傳統(tǒng)的定位方法。
在商用局的應(yīng)用中，單用戶(hù)跟蹤能大大縮短速率問(wèn)題的定位時(shí)間，極大地降低了外場(chǎng)其他用戶(hù)的干擾。這項(xiàng)設(shè)計(jì)為提高運(yùn)營(yíng)商的滿(mǎn)意度和快速推進(jìn)中國(guó)3G的部署起了重要的作用。
下載文檔
