目錄

1 概述
2 掉話分類定義
2.1. 路測數(shù)據(jù)
2.1.1. 掉話定義
2.1.2. 表現(xiàn)形式
2.1.3. 獲取方式
2.2. 標(biāo)口信令
2.2.1. 掉話表現(xiàn)形式
2.2.2. 獲取方式
2.3. 話統(tǒng)數(shù)據(jù)
2.3.1. 掉話率指標(biāo)話統(tǒng)公式
2.3.2. 掉話Counter介紹
2.3.3. 獲取方式
2.4. CHR數(shù)據(jù)
2.4.1. 獲取方式

2.4.2. 呈現(xiàn)方式



1 概述

本《LTE掉話優(yōu)化指導(dǎo)書》重點介紹了LTE系統(tǒng)內(nèi)掉話率指標(biāo)的優(yōu)化思路、分析方法、定位手段及典型案例；

本《指導(dǎo)書》結(jié)構(gòu)如下：

第一部分 主要從路測、標(biāo)準(zhǔn)接口、話統(tǒng)、CHR多角度出發(fā)給出了掉話的定義；

第二部分 給出了常見的掉話原因，掉話機制的介紹；

第三部分 介紹了掉話問題的隔離定位分析方法；

第四部分 分享了掉話優(yōu)化的典型案例；

第五部分 介紹了CHR數(shù)據(jù)的分析方法，影響掉話的定時器介紹及重建的機制介紹。


2 掉話分類定義

掉話是指在UE在與eNB間成功建立eRAB之后，由于異常原因?qū)е碌膃RAB釋放，本章將分別從路測數(shù)據(jù)、標(biāo)準(zhǔn)接口信令、話統(tǒng)數(shù)據(jù)及CHR數(shù)據(jù)4個方面介紹一下掉話的表現(xiàn)。


2.1. 路測數(shù)據(jù)


2.1.1. 掉話定義

在華為Probe&Assistant側(cè)對于掉話（eRab Abnormal Release）的定義如下：

一、沒有收到“DEACTIVATE EPS BEARER CONTEXT REQUEST”的NAS消息，也沒有收到MME的“DETACH REQUEST”的NAS消息，也沒有向網(wǎng)絡(luò)側(cè)主動發(fā)出“DETACH REQUEST”的NAS消息，收到了RRCConnectionReconfiguration消息，且其中有信元“drb-ToReleaseList”，則生成一次ERABAbnormalRel，在Info中顯示所有“drb-ToReleaseList”下對應(yīng)的eps-BearerIdentity，并記錄ReleaseList下的eps-BearerIdentity個數(shù)。ERAB num –釋放個數(shù), 如果ERAB減完以后是0了，則狀態(tài)遷移到RRC_Idle，否則狀態(tài)不遷移。

二、或者在沒有收到“DEACTIVATE EPS BEARER CONTEXT REQUEST”的NAS消息，也沒有收到MME的“DETACH REQUEST”的NAS消息，也沒有向網(wǎng)絡(luò)側(cè)主動發(fā)出“DETACH REQUEST”的NAS消息，收到了RRCConnection release消息并且前4s如果有RLC層速率傳輸(上下行都需要考慮進來的，任何一個方向只要有數(shù)傳即滿足條件)，生成一次ERABAbnormalRel，狀態(tài)遷移到RRC_idle。

三、或者收到RRC Connection Reconfiguration消息中包含了信元“drb-ToAddModList”后，收到RRC釋放信令之前，手機的RRCState=Idle，生成一次ERABAbnormalRel，釋放次數(shù)增加所有“drb-ToAddModListt”下對應(yīng)的eps-BearerIdentity個數(shù)，狀態(tài)遷移到RRC_idle。

四、在沒有收到RRC Connection Reconfiguration，DEACTIVATE EPS BEARER CONTEXT REQUEST，DETACH REQUEST，RRC State, RRCConnection release消息時，收到RRC請求時將判斷一個ERAB異常釋放事件。

五、遇到RRCReestablishFail事件時同時輸出ERAB異常釋放事件，打點時間與RRCReestablishFail相同。


2.1.2. 表現(xiàn)形式

通常路測時，使用PROBE軟件+華為測試UE/華為數(shù)據(jù)卡觀察（其它商用終端加相應(yīng)的終端信令跟蹤軟件），以及路測計算機安裝的流量監(jiān)控軟件，能看到如下信息：

1）流量突然掉底或為0

在Ftp下載或上傳（或者灌包）沒有進行手動干預(yù)的情況下，此時吞吐率應(yīng)該保持持續(xù)，若出現(xiàn)突然掉底，則有可能出現(xiàn)掉話。


圖1 路測吞吐率掉底

2） UE開始接收系統(tǒng)消息

通常，UE在Detach/不活動定時器釋放/切換至新小區(qū)/發(fā)生重建這些場景時會讀取系統(tǒng)消息，但如果在業(yè)務(wù)正常進行過程中，在未涉及這些場景時突然接收系統(tǒng)消息時，則可以判定為掉話。


圖2 開始接收系統(tǒng)消息


2.1.3. 獲取方式

通過華為Genex Probe可獲取華為測試UE及高通芯片數(shù)據(jù)卡log；

華為測試UE也可以通過OMT獲��；

三星UE通過三星數(shù)據(jù)卡及XCal/Tems軟件獲�。�

高通芯片TTI及跟蹤可通過QXDM軟件獲取。


2.2. 標(biāo)口信令

在eNodeB跟蹤到的標(biāo)準(zhǔn)接口信令中，如果存在eNodeB發(fā)起的釋放，既在S1接口上發(fā)往CN的S1AP_UE_CONTEXT_REL_REQ消息內(nèi)攜帶的原因值不為“User-inactivity”、“cs fallback triggered”、“UE Not Available For PS Service”、“Inter-RAT redirection”時，則判斷為掉話。
2.2.1. 掉話表現(xiàn)形式

異常掉話通常都是由ENB發(fā)起的釋放，通知MME釋放上下文，因此只要查看S1口發(fā)送的S1AP_UE_CONTEXT_REL_REQ消息即可，如下圖所示為正常釋放。


圖3 S1AP_UE_CONTEXT_REL_REQ

點擊“標(biāo)準(zhǔn)接口消息類型”按消息類型進行排序，這樣所有的S1AP_UE_CONTEXT_REL_REQ都會排列在一起，如下圖所示。


圖4 按消息類型排序

依次點擊下一條，查看中的原因值，找出信令內(nèi)攜帶的原因值為異常釋放原因值的進行分析。如下圖所示為一異常釋放的話單記錄。


圖5 找到異常掉話消息

根據(jù)對應(yīng)的時間點，打開標(biāo)準(zhǔn)UU口的跟蹤，找到對應(yīng)時間點的RRC_CONN_REL消息，如下圖所示。


圖6 找到對應(yīng)的UU口消息

再查找對應(yīng)時間點的IFTS跟蹤，看是否跟蹤到此次異常釋放對應(yīng)的IFTS跟蹤。


圖7 找到對應(yīng)的IFTS消息

打開IFTS跟蹤，查找對應(yīng)的時間點的跟蹤是否可以和UU口、SI口對應(yīng)上，如果無法對應(yīng)，說明該IFTS跟蹤的UE和當(dāng)前掉話的UE不是同一個UE，則該IFTS跟蹤就沒有分析的必要。如果可以找到IFTS跟蹤的UE和當(dāng)前掉話的UE是同一個UE，則把該S1/UU/IFTS跟蹤發(fā)回來分析。


2.2.2. 獲取方式

在eRAN2.1版本之后，可以通過M2000采集Ifts數(shù)據(jù)，獲取步驟簡介如下：

Step1：登錄M2000服務(wù)器，選擇 監(jiān)控->信令跟蹤->信令跟蹤管理


圖8 M2000信令跟蹤管理

Step2：在左側(cè)菜單欄中雙擊“IFTS跟蹤”


圖9 M2000IFTS跟蹤

Step3：點擊“創(chuàng)建”，出現(xiàn)如下對話框，填寫跟蹤名稱，并選定跟蹤網(wǎng)元，點擊下一步


圖10 M2000 IFTS跟蹤網(wǎng)元與時間設(shè)置

Step4：


圖11 M2000 IFTS跟蹤信息選擇設(shè)置

1）小區(qū)ID：按實際填寫；

2）跟蹤層：L1需要勾選“L1上行鏈路特征信息”、“L1下行鏈路”；L2 TTI需要勾選“L2性能算法特征信息”；

3）勾選”trace type”中的“內(nèi)部消息”(inner)和“文本消息”(text)；

4）MAC內(nèi)部數(shù)據(jù)跟蹤字段：需要跟蹤不同的模塊時填寫不同的數(shù)字，比如要跟蹤“L2下行調(diào)度”

模塊，在上面的空格中輸入33，如果要跟蹤多個模塊，中間用“/”隔開。

目前支持的數(shù)據(jù)源和LAE解析類型參考發(fā)布的LAE配置文件對應(yīng)的sheet：“TLV類型”

常用IFTS L2 MAC跟蹤布控類型如下表所示：


Step5：點擊“完成”，任務(wù)創(chuàng)建成功


圖12 IFTS跟蹤運行中

Step6：用戶接入，可以跟蹤到相關(guān)日志

Step7：單擊右鍵，選擇“停止”可以停止跟蹤


圖13 停止IFTS跟蹤

Step8：導(dǎo)出數(shù)據(jù)，點擊“Export”，選擇本地存放路徑


圖14 IFTS跟蹤數(shù)據(jù)導(dǎo)出

注意事項：IFTS跟蹤是跟蹤第一個接入的用戶，具體哪個用戶是由IFTS跟蹤界面打開后L3根據(jù)實際接入用戶情況跟蹤的。

需要先打開IFTS跟蹤，再接入用戶，才能跟蹤到內(nèi)容。

2.3. 話統(tǒng)數(shù)據(jù)
2.3.1. 掉話率指標(biāo)話統(tǒng)公式

在話統(tǒng)側(cè)異常掉話指標(biāo)的公式定義如下：

Call Drop Rate = L.E-RAB.AbnormRel / （L.E-RAB.AbnormRel + L.E-RAB.NormRel）

其中：

L.E-RAB.AbnormRel：小區(qū)異常釋放用戶E-RAB的總次數(shù)

L.E-RAB.NormRel：小區(qū)正常釋放用戶E-RAB的總次數(shù)

而E-RAB是LTE網(wǎng)絡(luò)中承載用戶業(yè)務(wù)數(shù)據(jù)的接入層承載，E-RAB釋放過程是用戶接入層業(yè)務(wù)承載資源的釋放過程，反映了小區(qū)為用戶釋放接入層業(yè)務(wù)數(shù)據(jù)承載資源的能力。此類Counter在統(tǒng)計時以E-RAB的個數(shù)為單位，一個E-RAB的釋放統(tǒng)計為一次。

故從該指標(biāo)中可以知道，掉話率的指標(biāo)統(tǒng)計是針對業(yè)務(wù)而非用戶的，如果一個用戶建立了多個DRB業(yè)務(wù)，則在分別掉話時，有可能會統(tǒng)計多次異常掉話值。


2.3.2. 掉話Counter介紹

掉話相關(guān)Counter主要有45個，按釋放類型可分為正常釋放、異常釋放、切換出正常釋放、切換出異常釋放；按照標(biāo)準(zhǔn)QCI等級，又進行從QCI1~QCI9的分類；按照異常釋放原因，又可以分為：無線、傳輸、擁塞、切換失敗、MME共5類。


2.3.2.1. 正常釋放Counter

下表內(nèi)所含為正常釋放次數(shù)對應(yīng)的Counter。其中，由于存在擴展QCI，故L.E-RAB.NormRel（1526727547）的統(tǒng)計次數(shù)會大于等與QCI1~QCI9的總和。


如下圖中A點所示，當(dāng)eNodeB收到來自MME的E-RAB RELEASE COMMAND消息時統(tǒng)計該指標(biāo)，如果是MME主動發(fā)起的釋放，根據(jù)不同QCI統(tǒng)計對應(yīng)指標(biāo)；如果是eNodeB主動發(fā)起的釋放，當(dāng)釋放原因為“Normal Release”，“Detach”，“User Inactivity”，“cs fallback triggered”，“Inter-RAT redirection”，“UE Not Available For PS Service”時，根據(jù)不同QCI統(tǒng)計對應(yīng)指標(biāo)。如果E-RAB RELEASE COMMAND消息中要求同時釋放多個E-RAB，則相應(yīng)指標(biāo)按各個業(yè)務(wù)的QCI分別進行累加。


圖15 小區(qū)E-RAB正常釋放打點_1

如下圖中A點所示，當(dāng)eNodeB收到來自MME的UE CONTEXT RELEASE COMMAND消息，會釋放UE的所有E-RAB。如果是MME主動發(fā)起的釋放，根據(jù)不同QCI統(tǒng)計對應(yīng)指標(biāo)；如果是eNodeB主動發(fā)起的釋放，當(dāng)釋放原因為“Normal Release”，“Detach”，“User Inactivity”，“cs fallback triggered”，“Inter-RAT redirection” ，“UE Not Available For PS Service”時，相應(yīng)指標(biāo)按各個業(yè)務(wù)的QCI分別進行累加。


圖16 小區(qū)E-RAB正常釋放打點_2


2.3.2.2. 異常釋放Counter

下表內(nèi)所含為異常釋放次數(shù)對應(yīng)的Counter。其中，由于存在擴展QCI，故L.E-RAB.AbnormRel（1526727546）的統(tǒng)計次數(shù)會大于等與QCI1~QCI9的總和。


如下圖中A點所示，當(dāng)eNodeB向MME發(fā)送E-RAB RELEASE INDICATION消息，且釋放原因不為“Normal Release”，“User Inactivity”，“cs fallback triggered”，“Inter-RAT redirection” ，“UE Not Available For PS Service”時統(tǒng)計該指標(biāo)，并且在MME回復(fù)E-RAB RELEASE COMMAND消息時，該指標(biāo)不會被重復(fù)記錄，如果E-RAB RELEASE INDICATION消息中要求同時釋放多個E-RAB，則相應(yīng)指標(biāo)按各個業(yè)務(wù)的QCI分別進行累加；


圖17 小區(qū)E-RAB異常釋放打點_1

如下圖中A點所示，當(dāng)eNodeB向MME發(fā)送UE CONTEXT RELEASE REQUEST消息，會釋放UE的所有E-RAB。當(dāng)釋放原因不為“Normal Release”，“User Inactivity”，“cs fallback triggered”，“Inter-RAT redirection” ，“UE Not Available For PS Service”時統(tǒng)計該指標(biāo)，相應(yīng)指標(biāo)按各個業(yè)務(wù)的QCI分別進行累加。并且在MME回復(fù)UE CONTEXT RELEASE COMMAND消息時，該指標(biāo)不會被重復(fù)記錄。


圖18 小區(qū)E-RAB異常釋放打點_2


2.3.2.3. 切換出正常釋放Counter

下表內(nèi)所含為切換出正常釋放次數(shù)對應(yīng)的Counter。其中，由于存在擴展QCI，故L.E-RAB.NormRel.HOOut（1526728246）的統(tǒng)計次數(shù)會大于等與QCI1~QCI9的總和。


如下圖所示，從左到右依次為eNodeB內(nèi)切換、X2接口切換及S1接口切換。而圖中C點所示為切換執(zhí)行成功，對于目標(biāo)小區(qū)已經(jīng)成功建立的E-RAB，源小區(qū)正常釋放對應(yīng)的E-RAB，此時的釋放原因可能為：“successful handover”，則在源小區(qū)按各個業(yè)務(wù)的QCI分別統(tǒng)計該指標(biāo)。

圖19 小區(qū)切換出E-RAB正常釋放打點


2.3.2.4. 切換出異常釋放Counter

下表內(nèi)所含為切換出異常釋放次數(shù)對應(yīng)的Counter。其中，由于存在擴展QCI，故L.E-RAB.AbnormRel.HOOut（1526728247）的統(tǒng)計次數(shù)會大于等與QCI1~QCI9的總和。


如下圖所示，從左到右依次為eNodeB內(nèi)切換、X2接口切換及S1接口切換。圖中C點所示為切換執(zhí)行成功，但目標(biāo)小區(qū)有建立失敗的E-RAB，源小區(qū)異常釋放對應(yīng)的E-RAB，此時的釋放原因可能為：“Partial Handover”等，則在源小區(qū)按各個業(yè)務(wù)的QCI分別統(tǒng)計該指標(biāo)。
圖20 小區(qū)切換出E-RAB異常釋放打點


2.3.2.5. 異常釋放原因Counter

下表內(nèi)所含為異常釋放原因分類對應(yīng)的Counter。

如下圖中A點所示，MME主動發(fā)起E-RAB釋放流程，當(dāng)eNodeB收到來自MME的E-RAB RELEASE COMMAND消息時，且釋放原因不為“Normal Release”，“Detach”，“User Inactivity”，“cs fallback triggered”，“Inter-RAT redirection” ，“UE Not Available For PS Service”則統(tǒng)計L.E-RAB.AbnormRel.MME指標(biāo)。如果E-RAB RELEASE COMMAND消息中要求同時釋放多個E-RAB，則指標(biāo)L.E-RAB.AbnormRel.MME按具體業(yè)務(wù)數(shù)目進行累加；


圖21 小區(qū)E-RAB異常釋放原因打點_1

如下圖中A點所示，MME主動發(fā)起UE CONTEXT釋放流程，當(dāng)eNodeB收到來自MME的UE CONTEXT RELEASE COMMAND消息時，會釋放UE的所有E-RAB。當(dāng)釋放原因不為“Normal Release”，“Detach”，“User Inactivity”，“cs fallback triggered”，“Inter-RAT redirection” ，“UE Not Available For PS Service”時，統(tǒng)計L.E-RAB.AbnormRel.MME指標(biāo)，指標(biāo)L.E-RAB.AbnormRel.MME按具體業(yè)務(wù)數(shù)目進行累加；


圖22 小區(qū)E-RAB異常釋放原因打點_2

如下圖中A點所示，當(dāng)eNodeB向MME發(fā)送E-RAB RELEASE INDICATION消息，當(dāng)釋放原因為無線層錯誤時，統(tǒng)計L.E-RAB.AbnormRel.Radio指標(biāo)，無線層錯誤描述請參考3GPP TS36.413協(xié)議定義；當(dāng)釋放原因為傳輸層錯誤時，統(tǒng)計L.E-RAB.AbnormRel.TNL指標(biāo)，傳輸層錯誤描述請參考3GPP TS36.413協(xié)議定義；當(dāng)釋放原因為網(wǎng)絡(luò)擁塞時，統(tǒng)計L.E-RAB.AbnormRel.Cong指標(biāo)。如果E-RAB RELEASE INDICATION消息中要求同時釋放多個E-RAB，則相應(yīng)指標(biāo)根據(jù)具體業(yè)務(wù)數(shù)目按上述原因分別進行累加；


圖23 小區(qū)E-RAB異常釋放原因打點_3

如下圖中A點所示，當(dāng)eNodeB向MME發(fā)送UE CONTEXT RELEASE REQUEST消息，會釋放UE的所有E-RAB。當(dāng)釋放原因為無線層錯誤時，統(tǒng)計L.E-RAB.AbnormRel.Radio指標(biāo)，無線層錯誤描述請參考3GPP TS36.413協(xié)議定義；當(dāng)釋放原因為傳輸層錯誤時，統(tǒng)計L.E-RAB.AbnormRel.TNL指標(biāo)，傳輸層錯誤描述請參考3GPP TS36.413協(xié)議定義；當(dāng)釋放原因為網(wǎng)絡(luò)擁塞時，統(tǒng)計L.E-RAB.AbnormRel.Cong指標(biāo)，本指標(biāo)統(tǒng)計包括因搶占和資源擁塞導(dǎo)致的異常釋放；當(dāng)釋放原因為切換失敗時，統(tǒng)計L.E-RAB.AbnormRel.HOFailure指標(biāo)。相應(yīng)指標(biāo)根據(jù)具體業(yè)務(wù)數(shù)目按上述原因分別進行累加。并且在MME回復(fù)UE CONTEXT RELEASE COMMAND消息時，該指標(biāo)不會被重復(fù)記錄。


圖24 小區(qū)E-RAB異常釋放原因打點_4
2.3.3. 獲取方式

通常為方便數(shù)據(jù)發(fā)送及后處理，話統(tǒng)數(shù)據(jù)可通過M2000進行獲取導(dǎo)出，格式一般為Excel，相關(guān)格式如下圖所示


圖25 話統(tǒng)文件格式

也可以通過PRS/OMStar軟件直接處理M2000服務(wù)器上的原始話統(tǒng)數(shù)據(jù)。


2.4. CHR數(shù)據(jù)

CHR側(cè)掉話定義與話統(tǒng)側(cè)相一致，只是CHR側(cè)會依據(jù)相對應(yīng)異常釋放話單內(nèi)部流程的錯誤原因?qū)⒌粼捲�因進行細分，并依據(jù)L3內(nèi)部的實現(xiàn)輸出內(nèi)部失敗原因值，便于工程師將掉話原因進行分類。
2.4.1. 獲取方式
2.4.1.1. 直接獲取CHR日志

通過web LMT或M2000直接獲取

Step1：在web LMT或M2000上輸入LST LOGFILE: LT=CHRLOG; 查詢當(dāng)前CHR日志文件列表；


圖 LST LOGFILE執(zhí)行結(jié)果

Step2：在web LMT或M2000上輸入ULD NEFILE（V100R003C00及以后版本），然后選擇日志類型為CHR，輸入需要保存的目標(biāo)文件的名稱（通常命名規(guī)則為NE Name+獲取日期），并輸入FTP服務(wù)器IP、用戶名、密碼 FTP服務(wù)器信息請向機房管理人員或者維護工程師索取），可以上傳對應(yīng)的CHR日志至FTP服務(wù)器。


圖 Log 上傳到服務(wù)器

這種采集日志的方法只能挨個導(dǎo)出單個站點的日志。
2.4.1.2. 通過一鍵式日志獲取

從主控板所在槽位上導(dǎo)出的一鍵式日志，其中既包含了Debug日志、Sig日志及CHR日志等。導(dǎo)出一鍵式日志可通過在WebLMT或者M2000上執(zhí)行MML命令“ULD NEFILE”完成，其中單板所在的框號、槽號需要與主控板所在位置對應(yīng)。


圖26 一鍵式日志獲取


2.4.1.3. 使用LogUnpack.exe解包日志

將上傳后的CHR數(shù)據(jù)（2.1版本）或一鍵式日志使用Log Unpack工具解壓，就能提取出CHR日志可供分析。如下圖所示：


圖27 日志解包


2.4.2. 呈現(xiàn)方式

CHR數(shù)據(jù)可通過華為開發(fā)的InsightSharp軟件進行解析，相關(guān)操作界面如下圖所示


圖28 InsightSharp界面