WRNC系統中單用戶跟蹤的設計

本文引入一定的機制，使無線網絡控制器RNC（Radio Network Control）內部能夠方便、準確地收集到單用戶數據處理中各個環節的統計信息，便于快速地對單用戶信息進行統計與核對，提高問題分析的效率。

隨著3G網絡的迅猛發展，WCDMA系統正在大規模地商用。以前常用的一些定位手段，如斷點調試、LogView等已經越來越難以符合外場的需求。與簡單的實驗室環境相比，外場定位問題會更加困難，目前針對HSDPA/HSUPA 業務速率不穩和PS業務（Packet Stream數據業務）不通等問題，普通的排查手段顯得十分有限，定位難度很大。加上外場用戶多、干擾數據大等特殊情況，傳統的定位方法根本無法獲取單一用戶的相關統計信息及流量的跟蹤信息，給問題的定位和解決帶來了諸多難點。

1 速率問題的產生及現象

RNC內部速率問題的產生主要有3個原因：(1)用戶面處理數據包不當，異常丟包；(2)控制面傳遞給用戶面的接續參數有誤，用戶面與承載無法銜接；(3)用戶面自身在處理各種接續關系時處理不當。

在實際應用中幾種不同情況的速率現象分別為：(1)HSDPA/HSUPA業務進行時上下行速率不穩定；(2)HSDPA/HSUPA業務進行過程中出現速率掉鉤；(3)HSDPA/HSUPA PS業務無法達到簽約的預期速率；（4） 速率正常。

2 傳統的定位方法及缺陷

目前，傳統的速率定位方法分為3種：SHELL命令定位、DSP打印定位和信令跟蹤定位。

但是對于外場定位來說，這些傳統的定位手段卻很難實現。首先，SHELL命令定位，外場接口板數量多，承載著不同的業務，需要在接口板之間輪流輸入SHELL命令，顯得極其麻煩，同時SHELL命令只能跟蹤所有的業務流量信息，無法針對特定用戶，缺少針對性。其次，外場對于打印有嚴格的要求，一般不允許開啟內部打印，正式的商用局資源本來就比較少，開啟內部繁多的打印，會影響整個系統的運行。最后，信令跟蹤只是記錄控制面的基本信息，對于用戶面的檢查無法起到真正的幫助作用。

因此對于此類問題，需要有一個良好的定位方法將問題鎖定在具體的接口或者FP層面上。單用戶跟蹤正是針對這個缺陷設計的，其優點是：(1)數據的上報通過后臺信令跟蹤來記載，利于觀測；(2)數據跟蹤以FP為單位，直接定位到業務通道，定位準確；(3)對正常的設備運行不會增加額外的開銷，且不需要進行多余的手工操作，使用方便。

3 單用戶跟蹤的設計及實現

3.1 WCDMA系統的整體概述

WCDMA系統主要由三大核心部分組成，分為核心網(CN)、無線網絡控制器(RNC)和基站(NodeB)。RNC連接著CN和NodeB，在整個WCDMA中起著舉足輕重的作用。RNC和RNC之間用IUR口連接。RNC分為CRNC(控制RNC)、SRNC(服務RNC)和DRNC(漂移RNC)三部分[5]。

3.2 單用戶跟蹤的數據流

RNC內數據流的路徑分為兩條，一條是通過IUB口直接進入SRNC，途經IU口到達CN；另一條是通過IUB口先到達DRNC，再由DRNC經IUR口到SRNC，最后到達CN[6]。如果能在每個結點處對各個FP的數據包進行統計，對比各個結點數據的流量，就能迅速定位出數據丟失的接口和FP。

3.3 單用戶跟蹤的整體設計

UTRAN各個接口的協議架構是按照一個通用的協議模型設計的，如圖1所示。設計的原則是層間和平面間在邏輯上相互獨立。從水平層面來看，協議結構主要包括兩層：無線網絡層和傳輸網絡層。所有UTRAN相關問題只與無線網絡層有關，傳輸網絡層只是UTRAN采用的標準化的傳輸技術，與UTRAN的特定功能無關。從垂直平面來看，協議結構包括控制平面、用戶平面、傳輸網絡控制平面和傳輸網絡用戶平面[1]。



本設計根據UTRAN的協議架構，分為以下幾個模塊：消息處理模塊、控制面、用戶面、承載管理模塊和信令跟蹤模塊。

整個單用戶跟蹤設計思路如圖2所示，其中實線代表控制流，虛線代表數據流。



對于控制信息來說，后臺將媒體面跟蹤的任務分配到消息處理模塊（Daemon），Daemon通知控制面CP(Control Plane)和用戶面UP（User Plane）。控制面在承載鏈路建立和刪除時通知承載管理模塊BM（Bear Management,BM）建立和刪除相關的承載跟蹤。從消息中提取相關信息，并發送消息通知接口板，接口板收到消息后，設置好過濾條件，對處理的報文進行過濾統計。

對于數據業務流來說，收集跟蹤信息后，接口板和用戶面直接將跟蹤信息上報到Daemon。Daemon將消息的內容進行核對后上報給后臺。

3.4 單用戶跟蹤的實現流程

為了在現有體系的框架下順利實現各個接口FP的流量上報，設計如下2個流程：任務的啟動和數據的上報及核對。

3.4.1 媒體面單用戶跟蹤的啟動

單用戶跟蹤的啟動過程為：

(1)后臺向信令跟蹤模塊(ToolKit)發送EV_UE_MEDIA_START_REQ的請求消息。消息中攜帶需要跟蹤的IMSI號和跟蹤標志位給ToolKit。

(2)ToolKit采取應答處理機制，收到消息后立馬向后臺回響應，告知消息已收到。ToolKit內部維護了一張關于UE各種跟蹤任務的狀態表（TraceUE）。根據消息中的IMSI號來判斷，如果ToolKit模塊中未能查詢到保存的IMSI號，說明該流程錯誤，直接結束。若IMSI號存在，并且已處于跟蹤狀態，說明跟蹤重復，直接結束。若IMSI號處于未跟蹤狀態，ToolKit將創建關于該UE的一個上下文，同時保存到TraceUE的信息中，以便將來查詢使用。

(3)ToolKit需要給消息處理模塊（Daemon）發送消息EV_START_MEDIA_TRACE。由Daemon根據不同的消息來決定需要給哪些模塊發送跟蹤消息。

(4)Daemon向用戶面發送媒體面啟動的消息EV_START_MEDIA_TRACE。用戶面收到該跟蹤指示消息后將跟蹤信息記錄下來，使得在調用承載接口建立連接表時，指示此承載鏈路上的數據需要跟蹤，便于之后從用戶面直接上報數據量信息。

(5)Daemon向各個地面接口(IUB/IUR/IU)發送EV_START_MEDIA_TRACE消息，觸發各個地面接口向各自的底層鏈路發送跟蹤指示。

(6)各個地面標準模塊收到媒體面單用戶跟蹤消息后，根據IMSI號搜索各自保存的關于這個UE相關的傳輸層信息，啟動消息發送機制，對和這個UE相關的承載，依次給承載管理模塊發送EV_START_LINK_TRACE消息，觸發關于這個UE的底層承載被標記成跟蹤態。這條消息不僅需要攜帶該條承載鏈路建立時的所有信息(BearId、bindingID、TransportAddress等)，還要加上被媒體面跟蹤的標志位。底層承載管理模塊BM收到該消息后，需要對承載信息進行遍歷和核對，對確實需要跟蹤的承載鏈路進行相關字段的標記，便于以后統計時使用。

3.4.2 媒體面單用戶跟蹤的上報時間及核對

(1)上報時間對齊

數據的上報都是在一定時間內累積的結果。為了保證業務數據統計的準確性，必須確保各個單板上系統時間的一致性。為了保證這一點，采取統計初始清零時間和統計上報時間對齊的策略。

統計初始清零時間對齊：在承載鏈路建立的時候，接口板上對此鏈路對應的統計信息清零。在用戶面處理板上也采用類似的方式對相關承載上的統計清零。

統計上報的時間對齊通過兩種方式實現：(1)約定好上報的粒度，例如15 s、30 s、60 s等。(2)通過單板上絕對時間來對齊。例如在時間對齊的前提下，在每分鐘的15 s、30 s、45 s、60 s的時刻進行上報。為了將上報時間對齊，在DSP上新維護一個記錄絕對時間的軟時鐘，軟時鐘的基準通過HOST同步，HOST可以定期對DSP上的時鐘進行校正。

(2)上報途徑

為使信息核對，設計了兩條上報途徑：(1)CP各個接口模塊與UP之間都有保活消息，保活消息將觸發UP上報用戶在不同接口(IUB、IUR、IU)上的所有承載鏈路的統計。UP收到保活消息后，發現該用戶被媒體面跟蹤，則調用數據上報接口上報統計，這時用戶面就會查詢啟動時被跟蹤的承載信息。通過內部機制，將跟蹤信息轉發到Daemon，直至送給后臺。(2)CP各個接口模塊在給UP發送保活消息時，發現該用戶被媒體面跟蹤，則給BM模塊發送數據上報請求消息EV_START_LINKTRACERPT_REQ，BM收到消息后，根據本地保存的跟蹤用戶信息，通知接口板。接口板將跟蹤信息上報到Daemon，直至后臺。

(3)統計信息的核對

用戶面在調用承載接口發送報文時，會根據接口中承載被跟蹤的信息進行過濾。在接收報文時，會根據承載連接表中的信息，對此報文進行過濾。

對于接口板來說，承載管理模塊需要對統計的信息設置過濾條件。對于不同的承載類型，過濾條件是不一致的。在ATM方式下，IUB、IUCS、IUR需要根據VPI、VCI、CID的信息來完成對出入網元信息的過濾，IUPS需要根據對端和本端的TEID來完成出入局的過濾。在IP方式下，IUB、IUCS、IUR根據本端IP地址和UDP端口號來完成出入網元的過濾，IUPS則需要本端和對端的TEID來判斷。

為了和用戶面核對統計信息，對于每一條的承載鏈路，控制面還需告知承載管理模塊過濾方向、接口類型、鏈路屬性和用戶的全局標識信息。

Daemon通過對兩種途徑上報的數據進行匯總和核對，防止了統計信息的不一致，提高了信息上報的準確性。

4 單用戶跟蹤的測試效果

本設計在WRNC系統中進行了測試和驗證。圖3是業務上報消息中的Iu口的信令解析。



其中包括單用戶跟蹤的一些統計信元。如：IuupUlPsRecvNum、IuupUlPsSendNum、IuupDlPsRecvNum和Iuup DlPsSendNum等，分別記錄上下行PS域的收發數據量。從該圖中可以看到IuUp的上行收發數據量都為21，代表此FP的數據收發正常，未出現異常情況。

從圖3中可以看到該方案成功地實現了業務數據的收集和上報。后臺的信令跟蹤清楚地記錄了各個標準接口中各個FP的類型和數據的收發信息。

該方案實現了在RNC內部各個接口用戶數據的上報和統計，徹底解決了傳統速率問題定位的復雜性和不準確性。定位準確、利于觀測和便于操作使得該定位方法大大優于傳統的定位方法。

在商用局的應用中，單用戶跟蹤能大大縮短速率問題的定位時間，極大地降低了外場其他用戶的干擾。這項設計為提高運營商的滿意度和快速推進中國3G的部署起了重要的作用。