目錄

1 概述
2 掉話分類定義
2.1. 路測(cè)數(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)書》重點(diǎn)介紹了LTE系統(tǒng)內(nèi)掉話率指標(biāo)的優(yōu)化思路、分析方法、定位手段及典型案例；

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

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

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

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

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

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


2 掉話分類定義

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


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


2.1.1. 掉話定義

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

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

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

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

四、在沒(méi)有收到RRC Connection Reconfiguration，DEACTIVATE EPS BEARER CONTEXT REQUEST，DETACH REQUEST，RRC State, RRCConnection release消息時(shí)，收到RRC請(qǐng)求時(shí)將判斷一個(gè)ERAB異常釋放事件。

五、遇到RRCReestablishFail事件時(shí)同時(shí)輸出ERAB異常釋放事件，打點(diǎn)時(shí)間與RRCReestablishFail相同。


2.1.2. 表現(xiàn)形式

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

1）流量突然掉底或?yàn)?

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


圖1 路測(cè)吞吐率掉底

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

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


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


2.1.3. 獲取方式

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

華為測(cè)試UE也可以通過(guò)OMT獲��；

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

高通芯片TTI及跟蹤可通過(guò)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”時(shí)，則判斷為掉話。
2.2.1. 掉話表現(xiàn)形式

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


圖3 S1AP_UE_CONTEXT_REL_REQ

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


圖4 按消息類型排序

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


圖5 找到異常掉話消息

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


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

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


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

打開IFTS跟蹤，查找對(duì)應(yīng)的時(shí)間點(diǎn)的跟蹤是否可以和UU口、SI口對(duì)應(yīng)上，如果無(wú)法對(duì)應(yīng)，說(shuō)明該IFTS跟蹤的UE和當(dāng)前掉話的UE不是同一個(gè)UE，則該IFTS跟蹤就沒(méi)有分析的必要。如果可以找到IFTS跟蹤的UE和當(dāng)前掉話的UE是同一個(gè)UE，則把該S1/UU/IFTS跟蹤發(fā)回來(lái)分析。


2.2.2. 獲取方式

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

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


圖8 M2000信令跟蹤管理

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


圖9 M2000IFTS跟蹤

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


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

Step4：


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

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

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

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

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

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

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

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


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


圖12 IFTS跟蹤運(yùn)行中

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

Step7：?jiǎn)螕粲益I，選擇“停止”可以停止跟蹤


圖13 停止IFTS跟蹤

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


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

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

需要先打開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釋放過(guò)程是用戶接入層業(yè)務(wù)承載資源的釋放過(guò)程，反映了小區(qū)為用戶釋放接入層業(yè)務(wù)數(shù)據(jù)承載資源的能力。此類Counter在統(tǒng)計(jì)時(shí)以E-RAB的個(gè)數(shù)為單位，一個(gè)E-RAB的釋放統(tǒng)計(jì)為一次。

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


2.3.2. 掉話Counter介紹

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


2.3.2.1. 正常釋放Counter

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


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


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

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


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


2.3.2.2. 異常釋放Counter

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


如下圖中A點(diǎn)所示，當(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”時(shí)統(tǒng)計(jì)該指標(biāo)，并且在MME回復(fù)E-RAB RELEASE COMMAND消息時(shí)，該指標(biāo)不會(huì)被重復(fù)記錄，如果E-RAB RELEASE INDICATION消息中要求同時(shí)釋放多個(gè)E-RAB，則相應(yīng)指標(biāo)按各個(gè)業(yè)務(wù)的QCI分別進(jìn)行累加；


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

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


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


2.3.2.3. 切換出正常釋放Counter

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


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

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


2.3.2.4. 切換出異常釋放Counter

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


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


2.3.2.5. 異常釋放原因Counter

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

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


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

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


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

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


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

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


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

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


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

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


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

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

通過(guò)web LMT或M2000直接獲取

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


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

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


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

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

從主控板所在槽位上導(dǎo)出的一鍵式日志，其中既包含了Debug日志、Sig日志及CHR日志等。導(dǎo)出一鍵式日志可通過(guò)在WebLMT或者M(jìn)2000上執(zhí)行MML命令“ULD NEFILE”完成，其中單板所在的框號(hào)、槽號(hào)需要與主控板所在位置對(duì)應(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ù)可通過(guò)華為開發(fā)的InsightSharp軟件進(jìn)行解析，相關(guān)操作界面如下圖所示


圖28 InsightSharp界面