WRNC系統中單用戶(hù)跟蹤的設計
加入技術(shù)交流群
3.4.1 媒體面單用戶(hù)跟蹤的啟動(dòng)
單用戶(hù)跟蹤的啟動(dòng)過(guò)程為：
(1)后臺向信令跟蹤模塊(ToolKit)發(fā)送EV_UE_MEDIA_START_REQ的請求消息。消息中攜帶需要跟蹤的IMSI號和跟蹤標志位給ToolKit。
(2)ToolKit采取應答處理機制，收到消息后立馬向后臺回響應，告知消息已收到。ToolKit內部維護了一張關(guān)于UE各種跟蹤任務(wù)的狀態(tài)表（TraceUE）。根據消息中的IMSI號來(lái)判斷，如果ToolKit模塊中未能查詢(xún)到保存的IMSI號，說(shuō)明該流程錯誤，直接結束。若IMSI號存在，并且已處于跟蹤狀態(tài)，說(shuō)明跟蹤重復，直接結束。若IMSI號處于未跟蹤狀態(tài)，ToolKit將創(chuàng )建關(guān)于該UE的一個(gè)上下文，同時(shí)保存到TraceUE的信息中，以便將來(lái)查詢(xún)使用。
(3)ToolKit需要給消息處理模塊（Daemon）發(fā)送消息EV_START_MEDIA_TRACE。由Daemon根據不同的消息來(lái)決定需要給哪些模塊發(fā)送跟蹤消息。
(4)Daemon向用戶(hù)面發(fā)送媒體面啟動(dòng)的消息EV_START_MEDIA_TRACE。用戶(hù)面收到該跟蹤指示消息后將跟蹤信息記錄下來(lái)，使得在調用承載接口建立連接表時(shí)，指示此承載鏈路上的數據需要跟蹤，便于之后從用戶(hù)面直接上報數據量信息。
(5)Daemon向各個(gè)地面接口(IUB/IUR/IU)發(fā)送EV_START_MEDIA_TRACE消息，觸發(fā)各個(gè)地面接口向各自的底層鏈路發(fā)送跟蹤指示。
(6)各個(gè)地面標準模塊收到媒體面單用戶(hù)跟蹤消息后，根據IMSI號搜索各自保存的關(guān)于這個(gè)UE相關(guān)的傳輸層信息，啟動(dòng)消息發(fā)送機制，對和這個(gè)UE相關(guān)的承載，依次給承載管理模塊發(fā)送EV_START_LINK_TRACE消息，觸發(fā)關(guān)于這個(gè)UE的底層承載被標記成跟蹤態(tài)。這條消息不僅需要攜帶該條承載鏈路建立時(shí)的所有信息(BearId、bindingID、TransportAddress等)，還要加上被媒體面跟蹤的標志位。底層承載管理模塊BM收到該消息后，需要對承載信息進(jìn)行遍歷和核對，對確實(shí)需要跟蹤的承載鏈路進(jìn)行相關(guān)字段的標記，便于以后統計時(shí)使用。
3.4.2 媒體面單用戶(hù)跟蹤的上報時(shí)間及核對
(1)上報時(shí)間對齊
數據的上報都是在一定時(shí)間內累積的結果。為了保證業(yè)務(wù)數據統計的準確性，必須確保各個(gè)單板上系統時(shí)間的一致性。為了保證這一點(diǎn)，采取統計初始清零時(shí)間和統計上報時(shí)間對齊的策略。
統計初始清零時(shí)間對齊：在承載鏈路建立的時(shí)候，接口板上對此鏈路對應的統計信息清零。在用戶(hù)面處理板上也采用類(lèi)似的方式對相關(guān)承載上的統計清零。
統計上報的時(shí)間對齊通過(guò)兩種方式實(shí)現：(1)約定好上報的粒度，例如15 s、30 s、60 s等。(2)通過(guò)單板上絕對時(shí)間來(lái)對齊。例如在時(shí)間對齊的前提下，在每分鐘的15 s、30 s、45 s、60 s的時(shí)刻進(jìn)行上報。為了將上報時(shí)間對齊，在DSP上新維護一個(gè)記錄絕對時(shí)間的軟時(shí)鐘，軟時(shí)鐘的基準通過(guò)HOST同步，HOST可以定期對DSP上的時(shí)鐘進(jìn)行校正。
(2)上報途徑
為使信息核對，設計了兩條上報途徑：(1)CP各個(gè)接口模塊與UP之間都有?；钕?，?；钕⒂|發(fā)UP上報用戶(hù)在不同接口(IUB、IUR、IU)上的所有承載鏈路的統計。UP收到?；钕⒑?，發(fā)現該用戶(hù)被媒體面跟蹤，則調用數據上報接口上報統計，這時(shí)用戶(hù)面就會(huì )查詢(xún)啟動(dòng)時(shí)被跟蹤的承載信息。通過(guò)內部機制，將跟蹤信息轉發(fā)到Daemon，直至送給后臺。(2)CP各個(gè)接口模塊在給UP發(fā)送?；钕r(shí)，發(fā)現該用戶(hù)被媒體面跟蹤，則給BM模塊發(fā)送數據上報請求消息EV_START_LINKTRACERPT_REQ，BM收到消息后，根據本地保存的跟蹤用戶(hù)信息，通知接口板。接口板將跟蹤信息上報到Daemon，直至后臺。
(3)統計信息的核對
用戶(hù)面在調用承載接口發(fā)送報文時(shí)，會(huì )根據接口中承載被跟蹤的信息進(jìn)行過(guò)濾。在接收報文時(shí)，會(huì )根據承載連接表中的信息，對此報文進(jìn)行過(guò)濾。
對于接口板來(lái)說(shuō)，承載管理模塊需要對統計的信息設置過(guò)濾條件。對于不同的承載類(lèi)型，過(guò)濾條件是不一致的。在A(yíng)TM方式下，IUB、IUCS、IUR需要根據VPI、VCI、CID的信息來(lái)完成對出入網(wǎng)元信息的過(guò)濾，IUPS需要根據對端和本端的TEID來(lái)完成出入局的過(guò)濾。在IP方式下，IUB、IUCS、IUR根據本端IP地址和UDP端口號來(lái)完成出入網(wǎng)元的過(guò)濾，IUPS則需要本端和對端的TEID來(lái)判斷。
為了和用戶(hù)面核對統計信息，對于每一條的承載鏈路，控制面還需告知承載管理模塊過(guò)濾方向、接口類(lèi)型、鏈路屬性和用戶(hù)的全局標識信息。
Daemon通過(guò)對兩種途徑上報的數據進(jìn)行匯總和核對，防止了統計信息的不一致，提高了信息上報的準確性。
4 單用戶(hù)跟蹤的測試效果
本設計在WRNC系統中進(jìn)行了測試和驗證。圖3是業(yè)務(wù)上報消息中的Iu口的信令解析。本文引用地址：http://dyxdggzs.com/article/157505.htm
其中包括單用戶(hù)跟蹤的一些統計信元。如：IuupUlPsRecvNum、IuupUlPsSendNum、IuupDlPsRecvNum和Iuup DlPsSendNum等，分別記錄上下行PS域的收發(fā)數據量。從該圖中可以看到IuUp的上行收發(fā)數據量都為21，代表此FP的數據收發(fā)正常，未出現異常情況。
從圖3中可以看到該方案成功地實(shí)現了業(yè)務(wù)數據的收集和上報。后臺的信令跟蹤清楚地記錄了各個(gè)標準接口中各個(gè)FP的類(lèi)型和數據的收發(fā)信息。
該方案實(shí)現了在RNC內部各個(gè)接口用戶(hù)數據的上報和統計，徹底解決了傳統速率問(wèn)題定位的復雜性和不準確性。定位準確、利于觀(guān)測和便于操作使得該定位方法大大優(yōu)于傳統的定位方法。
在商用局的應用中，單用戶(hù)跟蹤能大大縮短速率問(wèn)題的定位時(shí)間，極大地降低了外場(chǎng)其他用戶(hù)的干擾。這項設計為提高運營(yíng)商的滿(mǎn)意度和快速推進(jìn)中國3G的部署起了重要的作用。
評論