學習完此課程，您將會：的內容、分析與定掌握網優工作日常性能位思路掌握一般性能指標優化的思想與工具字段理解并掌握TD-SCDMA話統接通率問題的原理、分析思路與優化方法理解并掌握TD-SCDMA話統掉話率問題的原理、分析思路與優化方法理解并掌握TD-SCDMA話統互操作成功率問題的原理、分析思路與優化方法目標Page

21.

《TD-SCDMA無線網絡無線接通率優化指導書》2.

《TD-SCDMA無線網絡CS接通率專題分析指導及報告模版v1.2》3.

《TD接通率提升參數優化經驗（V2.0）》4.

《TD-SCDMA無線網絡CS掉話率優化指導書》5.

《TD-SCDMA無線網絡PS掉話率優化指導書》6.

《TD

SCDMA性能CS掉話率專題分析指導及報告模版V1.0》7.

《TD-SCDMA

2G3G互操作性能優化指導書》8.

《TD-SCDMA無線網絡2G3G互操作性能優化指導》9.

《RNPS

GSM與TD-SCDMA互操作研究v1.2》參考資料Page

3Page4第1章

性能

與問題處理第2章CS/PS接通率第3章CS/PS掉話率第4章CS/PS互操作成功率全面網絡性能

：主動發現問題話統PCHR1.業務量指標：CS話務量、PS業務量，零話務小區2.可接入性指標：RRC建立成功率、RAB建立成功率、CS/PS接入成功率3.可保持性指標：CS掉話率、PS掉線率4.可移動性指標：RNC內切換成功率、RNC間切換成功率、系統間切換成功率5.信道擁塞：RRC擁塞特性、RAB擁塞特性、PCH擁塞特性、傳輸信道擁塞6.信道特性：上行TS1/TS2時隙ISCP、UpPCH信道ISCP、上行業務信道BLER1.

VIP/VAP用戶分析與

：接入、掉話、超短呼叫、VQI、PS速率、HTTP業務斷鏈次數、重點小區分布2.覆蓋分析：接入電平分布、MR報告電平3.鄰區漏配分析：基于RNC漏配鄰區檢測算法4.終端性能統計：了解現網終端特性對整碗指標的影響5.特殊業務分析：并發業務特性、短消息特性、登記特性指標名稱CS域無線接通率CS域無線掉話率PS域無線接通率PS域無線掉線率RNC內同頻切換成功率RNC內異頻切換成功率CS域3Gto2G切換成功率PS域3Gto2G切換成功率RNC間切換入成功率RNC間切換出成功率平均99.23%0.17%99.08%1.17%97.39%98.50%98.32%94.98%95.86%94.41%區域關鍵指標情況PCHR原型工具功能Page

5持續拉網性能測試：體驗用戶感受DT測試CQT測試1.空口覆蓋狀況，網絡干擾狀況：弱覆蓋點與

擾區域優化2.網絡配置狀況：鄰區、擾碼、頻點的優化配置3.4.基礎感知評估：接通、掉話、語音質量評估、切換時延評估、PS速率評估、空閑態用戶感知（ 、重選……）關鍵指標評估：系統內切換成功率、系統間切換成功率1.CS用戶感知：AMR語音質量、VP質量、接入時延2.PS用戶感知：PS速率、HTTP業務斷鏈次數3.問題復現：終端側log抓取將鼎力側log與RNC側log對照，是分段排查問題的有效

！鼎力側信令RNC側信令Page

6Page

7“TOP”與“分段”：問題分析的主要思想“TOP”思想是話統問題分析的基礎：1TOP原因：影響指標的各原因值各占多少比例？主要原因是什么？各原因值數量分布比例是否正常？各RNC是否現象一致？3TOP

IMEI/IMSI狀況：通過PCHR＋Excel篩選是否存在TOPIMEI/IMSI？TOP

IMEI/IMSI問題規律性如何？可否協調相應終端測試？能否

臺 IMSI信息？TOP

IMSI/IMEI2TOP

Cell狀況：是否存在TOP

Cell？TOPCell的業務量是否足夠多？TOPCell有無設備類告警？TOP

Cell話統指標間關聯關系如何？TOPCell實地測試結果如何？TOP

CellTOP原因“分段”思想是測試問題分析的基礎：UE

NodeB①H速率低 ②空口良好

③來水量不足RNC④傳輸未擁塞CN④更換FTP服務器，搞定！性能工具與打點：問題分析與網絡優化的利器工具/打點主要功能話統網絡指標

與初步分析PCHRRNC呼叫日志，記錄呼叫過程的NodeB

CHR以RL建立為起點記錄的日志，結合PCHR，為性能問題定位提供NodeB

的相關信息MR根據終端、NODEB上報的

、公共測量報告，包括P

CHRSCP、上下行BLER、TA等數據，進行覆蓋、鄰區等信息分析尋呼日志嵌入

網CHR

記錄5個模塊156個字段，為定位尋呼相關問題提供信息CDT抓取通話過程中，RNC側詳細信息；可同時抓取業務面信息TPCwin除定位NodeB設備問題外，TPCwin還提供豐富的Tools以分析上下行空口相關信息頻譜分析工具通過

log，可離線分析上行干擾問題MML核查工具CME集成工具，可自定義模版核查全網參數配置鼎力log終端側空口、時間、信令等信息，可與系統側信息對照，進行問題分析與定位在問題定位與分析的不同階段，使用不同工具與打點信息RNC：話統PCHRMRCDTMML核查NodeB：NodeB

CHRTPCwin頻譜分析CN：尋呼日志UE：鼎力logPage

8良好覆蓋＋合理配置＋精細優化：構建精品網絡市區主要道路覆蓋99.32％部分區域存在大片待補站區域3.市區深度覆蓋需要進一步補充覆蓋提升參數基線是在

“安全”前提下的最優配置對于與參數基線配置有出入的配置，要求視情況盡量規范化配置優化通過右圖兩條折線對比，可以看到經過優化后，同一路段上切換次數顯著減少，測試MOS分也相應提升：頻繁切換會顯著影響

DT測試MOS分，一次切換平均會降低

MOS分1分左右；因此，減少不必要的頻繁切換，是提升MOS的重要

。RF調整前RF調整后MOS均值3.383.52①覆蓋優化過程②配置優化過程③精細優化過程Page

9Page10第1章

性能

與問題處理第2章CS/PS接通率第3章CS/PS掉話率第4章CS/PS互操作成功率Page11第2章CS/PS接通率第1節接通率基礎第2節接通率問題分析方法第3節接通率優化提升方法第4節接通率典型案例呼叫建立信令流程與話統規范中國移動規范：TD語音無線接通率=會話類業務

RRC建立成功率×語音業務RAB建立成功率無線接通率=

會話類業務RRC建立成功率×

業務RAB建立成功率PS域無線接通率=所有業務RRC建立成功率×PS域RAB建立成功率以上定義，PS無線接通率定義不合理，應該使用PS業務相關RRC建立成功率。UENodeB10

RAB建立(CS)RNC建立RRC連接建立CM連接CN1

RRC建立3

鑒權和加密（CS域）建立MM連接UENodeBRNCCN2

初始直傳4

DCCH:Uplink

Direct

Transfer(SETUP)5

DCH:DCH

DATA

FRAME

(Uplink

Direct

Transfer)6

Direct

Transfer

(SETUP)7

Direct

Transfer

(CALL

PROCEEDING)8

DCH:DCH

DATA

FRAME(Downlink

Direct

Transfer)9

DCCH:Downlink

Direct

Transfer

(CALL

PROCEEDING)11

Direct

Transfer(ALERTING)12

DCH:DCH

DATA

FRAME(Downlink

Direct

Transfer)13

DCCH:

DownlinkDirect

Transfer

(ALERTING)14

Direct

Transfer

(CONNECT)15

DCH:DCH

DATA

FRAME(Downlink

Direct

Transfer)16

DCCH:

DownlinkDirect

Transfer19

Direct

Transfer

(CONNECT

ACK)18

DCH:DCH

DATA

FRAME(Uplink

Direct

Transfer)(CONNECT)17

DCCH:

Uplink

Direct

Transfer(CONNECT

ACK)CS主叫信令流程Page12RRC建立流程話統定義：RRC請求次數=RNC收到RRCConnection

Request次數RRC成功次數=RNC收到RRCConnectionSetupComplete次數空口一共三條消息，若第一條消息失敗，不會有RRC請求；若第二、三條消息失敗，在話統的表現均為

“NoReply”。因此，設備正常運轉情況下“NoReply”應該是RRC建立失敗的絕對主體UENodeBRNC3.

CCCH:RRC

Connection

Request4.

RACH：RACH

DATA

FRAME(RRC

Connection

Request)1.

SYNC_UL2.

FPACH

Burst5.

Radio

Link

Setup

Requeststart

RX6.

Radio

Link

Setup

Response9.

Downlink

Synchronisation10.

Uplink

Synchronisationstart

TX12.

CCCH:RRC

Connection

Setup11

FACH：FACH

DATA

FRAME(RRC

Connection

Setup)14.

Radio

Link

Restore

Indication15.

DCCH:RRC

Connection

Setup

Complete16.

DCH：DCH

DATA

FRAME(RRC

Connection

Setup

Complete)Allocate

RNTI

and

Select

L1

and

L2parameters7.

ALCAP

Iub

Establish

Request8.

ALCAP

Iub

Establish

Confirm13.

special

burstUEPage13NodeBRNC話統RRC指標細分1.

RRC共定義19種業務2.

業務

“5”在協議中是有的：“Originating4.Subscribed

traffic

Call”3.

部分業務有定義，但實際是沒有業務發生的、系統間重選兩類業務占RRC請求約50％5.

PS業務相關RRC請求約占25％6.

CS業務相關RRC約占15％7.

各業務的RRC建立成功率，可通過話統或PCHR進行評估業務業務類型請求次數成功次數請求次數占比1主叫類會話業務950594145.65%2主叫類流業務000.00%3主叫類交互業務172121716610.22%4主叫類背景業務282812822016.80%6被叫類會話業務805380314.78%7被叫類流業務180451799510.72%8被叫類交互式業務000.00%9被叫類背景業務000.00%10緊急呼叫770.00%11系統間小區重選321373198119.09%12系統間小區改變命令000.00%13416064131424.71%14IMSI分離136513190.81%主叫發起高優先級信令連接.77%主叫發起低優先級信令連接.47%17呼叫重建59560.04%18被叫發起高優先級信令連接000.00%19被叫發起低優先級信令連接20未知原因Page14RAB建立流程LCR4.1話統定義：RAB請求次數=RNC收到RABAssignment

Request次數RAB成功次數=RNC發出RABAssignment

Response，并顯示為為成功的次數在無線資源充足的情況下，RNC收到RAB

Assignment

Request后不發RBSetup的可能性很低；當空口發生故障時，不論是RBSetup發下UE未收到，還是UE發回的RB

Setup

Complete消息RNC未收到，在話統體現的都是

“Failure

in

the

Radio

InterfaceProcedure”UENodeBRNCCN1

RANAP:

RAB

Assignment

Request

(Establishment)Select

L1,

L2

and

Iu

Data

Transport

Bearer

parameters2

ALCAP:

Iu

Establish

Request3

ALCAP

:

Iu

EstablishConfirm4

NBAP:

RadioLink

Reconfiguration

Prepare

5

NBAP

Radio

LinkReconfiguration

Ready6

ALCAp:

Iub

Establish

Request7

ALCAP

:Iub

Establish

Confirm8

Downlink

Synchronisation9

UplinkSynchronisation10

NBAP:

Radio

LinkReconfiguration

Commit11

DCH:

DCH

DATA

FRAME

(Radio

Bearer

Setup)12

DCCH:

Radio

Bearer

Setup13

Apply

new

transport

format

set14

DCCH:

Radio

Bearer

SetupComplete

15

DCH:

DCH

DATA

FRAME(Radio

Bearer

Setup

Complete)16

INITIALISATION17

INITIALISATION

ACK18

RANAP:RAB

Assignment

ResponsePage15UENodeBRNCCN話統RAB指標細分1.

上表為4.1C01版本中CS/PS域RAB建立失敗的細分原因值2.

RAB失敗的打點為“收到RAB

Assignment

Response”后，記錄對應

原因3.

4.1C02版本新增加一項“.14”失敗（Failurein

the

Radio

Interface

Procedure），對應場景為：RB

Setup下發后，直至定時器超時，未收到RB

Setup

Complete4.

與RRC建立失敗的情況一樣，在無線網絡中，“.14”失敗應該是主流的RAB失敗原因RAB.FailEstabCsNoQueuing.19電路域無排隊的RAB指配建立失敗的RAB數目<無效的RAB參數>RAB.FailEstabCsNoQueuing.20電路域無排隊的RAB指配建立失敗的RAB數目<最大速率不支持>RAB.FailEstabCsNoQueuing.66電路域無排隊的RAB指配建立失敗的RAB數目<IU口傳輸連接建立失敗>RAB.FailEstabCsNoQueuing.114電路域無排隊的RAB指配建立失敗的RAB數目<無可用資源>RAB.FailEstabCsNoQueuing.115電路域無排隊的RAB指配建立失敗的RAB數目<未知原因>RAB.FailEstabPsNoQueuing.19分組域無排隊的RAB指配建立失敗的RAB數目<無效RAB參數>RAB.FailEstabPsNoQueuing.20分組域無排隊的RAB指配建立失敗的RAB數目<最大速率不支持>RAB.FailEstabPsNoQueuing.66分組域無排隊的RAB指配建立失敗的RAB數目<IU口傳輸連接建立失敗>RAB.FailEstabPsNoQueuing.114分組域無排隊的RAB指配建立失敗的RAB數目<無可用資源>RAB.FailEstabPsNoQueuing.115分組域無排隊的RAB指配建立失敗的RAB數目<未知錯誤>CS域RAB失敗原因值：PS域RAB失敗原因值：Page16接通率網上表現區域接通率周平均指標：CS域RRC連接建立成功率CS域RAB建立成功率CS域無線接通率PS域RRC連接建立成功率PS域RAB建立成功率PS域無線接通率五月99.50%

↑99.73%

↑99.23%

↑99.57%

↑99.51%

↑99.08%

↑三月99.48%99.65%99.13%99.56%99.44%98.97%PCHR異常原因值解析（以某局點數據為例）：接入流程分類信令失敗錯誤編碼次數原因解釋信令失敗錯誤編碼RR_ERR_RNCAP_ALCFG_IU_AAL2_LOCAL_FAIL(184945361)1Iub口AAL2建立失敗RR_ERR_RNCAP_RELOC_ABNORMAL_FAIL(184748169)1待考證RR_ERR_RNCAP_RELOC_SEC_RELOC_REQ_TIMEOUT(185272276)1待考證RR_ERR_RNCAP_RRC_UE_RSP_TIMEOUT(185468882)1427RRC建立等待UE響應超時RAB異常錯誤編碼NULL730C02SPC600解決RAB異常信息塊輸出NULL問題RR_ERR_RNCAP_RB_CU_OVERLAP_BACK(185468906)25RAB建立過程與CellUpdate流程嵌套RR_ERR_RNCAP_RB_WAIT_UE_RB_CFG_TIMEOUT(185468904)127RAB建立過程等待UE響應超時RR_ERR_RNCAP_RRC_MAIN_ABNORMAL_ERR(184944605)3待考證RR_ERR_UU_INTERFACE_INVALID_CFG_ERR_NULL_TYPE(185468937)47呼叫早 、UE異常近兩月接通率各項指標均有提升！接入失敗主要發生在空口！Page17Page18第1章CS/PS接通率第1節接通率基礎第2節接通率問題分析方法第3節接通率優化提升方法第4節接通率典型案例“TOP”思想在接通率問題中的運用TOP分析各過程，可進行交叉分析；如針對某TOP原因篩選所在的TOP小區、TOP終端接通率低！怎么辦？TOP原因：根據話統、PCHR判斷，影響接通率的主要因素是RRC階段還是RAB階段RRC階段和RAB階段的未接通，理清各失敗原因值分布情況針對各階段和失敗原因值采取對應解決措施，優先處理非空口原因的接入失敗TOP小區：根據話統、PCHR對發生未接通的TOP小區進行排序，查找TOP小區針對TOP小區的TOP原因，采取對應解決措施TOP小區的相關告警信息需要關注；根據PCHR過濾的框、槽、端口異常信息需要關注必要時可對TOP小區進行實地測試以發現、分析問題TOP

IMSI/IMEI：PCHR分析前先做“

UE標識”的操作根據PCHR篩選出RRC、RAB接入失敗，自定義輸出IMSI/IMEI等信息后，使用Excel數據

判斷TOPIMSI/IMEI信息對RAB建立失敗，可以通過“PCHR工具＋Excel”來找到TOP

IMSI和TOP

IMEI對RRC建立失敗，若

UE標識后，仍然只能看到TMSI或P-TMSI，則需要手工找出與其對應的IMSI、IMEIPage19利用PCHR深入分析接通率問題RRC過程信息1.

接入小區2.

接入信道所在載頻3.

接入信道所在時隙4.

接入時RRC狀態5.

接入原因6.

信令失敗錯誤編碼RAB過程信息1.

RAB請求建立類型2.

RAB請求業務類型3.

RAB請求域業務指示4.

RAB掉話業務指示5.

RAB異常錯誤編碼PCHR工具＋Excel＋UltraEdit1.

實現對TOP小區，TOP用戶、TOP原因的匯總2.

結合“信令流程信息”和“前直傳信令信息”可進一步定位呼叫失敗的具體原因根據PCHR，可分析：1.

接入特性與接入電平分布的關系2.

接入特性與頻繁登記的關系3.

接入特性與覆蓋空洞的關系4.

……Page20Page21第1章CS/PS接通率第1節接通率基礎第2節接通率問題分析方法第3節接通率優化提升方法第4節接通率典型案例接通率優化提升措施：場景優化主叫會話類RRC成功率低而被叫會話類RRC成功率高1.這是一個正常現象，但兩者差異不能過大2.被叫時的“Paging

Tpye

1”消息為下行鏈路質量提供了保障3.對于兩者差異過大的場景，可通過提升FACH功率進行優化類RRC建立成功率低系統間重選類RRC建立成功率差1.系統間重選的RRC有兩種情況：PS域2G到3G切換、空閑態2G到3G后進行登記2.可見，系統間重選都發生在3G的覆蓋邊界3.

除通用的常規優化 外，該場景下可在2G側提高重選3G側電平門限1.

對于集中在LAC邊界的 類RRC指標差，需通過實地測試找到弱覆蓋邊界，進行覆蓋優化；或進行站點割接2.

對于短時集中于某個TMSI的 類RRC建立失敗，可通過提高小區駐留電平、延長周期性位置更新時間進行優化并發業務RAB建立成功率低1.在幀分打開情況下，RB

Setup消息空口下發需要的時間比非幀分情況下長；因此，幀分打開時，可通過提高ACTTIMEDEFOFFVALFORSAMECELL來保證RB

Setup消息被UE順利接收區分不同場景進行優化，是網絡精細優化的必要動作Page22接通率優化提升措施：算法參數優化算法/參數作用建議措施時隙均分均衡時隙間業務量，減少由于業務過度集中在某時隙導致的干擾抬升打開載波均分均衡載波間業務量，減少由于業務過度集中在某載波導致的干擾抬升打開UpPTS

Shifting將Uppts時隙遷移到其后的上行時隙中，并將Uppts時隙遷移的信息通過系統消息5傳遞給UE，以規避上行UpPTS干擾打開DCCC開關打開時，則PS業務進行過程中可根據實際需求進行碼資源分配，既保證用戶需求，又節省碼道資源RAB降速接入開關打開時，則PS業務以初始速率接入，占用較少碼道資源；結合DCCC算法，可減少“最大速率不支持”的RAB建立失敗打開RRCUERSPTMRRNC發出RRC

Connection

Setup后，等待UE返回RRC

ConnectionSetup

Complete消息的時間10000RBSETUPRSPTMRRNC發出RBSetup后，等待UE返回RBSetup

Complete消息的時間10000N300UE未收到RRCConnection

Setup，則重發RRC

ConnectionRequest；最多可發送N300＋1次7ULINTERFERERSV用于計算RRC、RAB建立過程中UE進行上行同步時的初始增大DLINTERFERERSV用于計算RRC、RAB建立過程中NodeB進行下行同步時的初始增大金銀銅牌用戶上行最大可調速率DCCC策略調整的給用戶的最大上行可用速率；對于出現“最大速率不支持”的PS

RAB失敗，可限制用戶上行最大可調速率減小Page23LCR

4.1C02

&

5.0在接通率方面新特性新增話統打點：RAB.FailEstabCsPerCell.14對應協議原因為：Failurein

the

Radio

InterfaceProcedure常見場景為：RNC下發RBSetup后，沒有收到UE返回的RBSetup

Complete消息價值信息：“UE收到Special

Burst的數量”，“UE收到block

data的數量”使用方法：NodeB收到上行SpecialBurst或者 block

data進行累加，鏈路刪除時上報；最大254，超過254取最大值。如果出現組合業務，取所有業務的累加值。對呼叫早

的處理：RAB建立請求統計點后移干擾余量分場景設置：精細調整RRC、RAB階段的初始“產品改進”與“網絡優化”共同保證成功交付NodeBCHR共同構筑版本提升RAB新增話統打點參數設置話統打點改進Page24Page25第1章CS/PS接通率第1節接通率基礎第2節接通率問題分析方法第3節接通率優化提升方法第4節接通率典型案例接通率提升案例-1現象A局點CS/PS接通率一直維持99.1～99.2左右，相對省內友商局點競爭壓力較大，需要優化提升主要是因為RRC建立成功率較低，為99.2左右；，為99.85左右。因此，針對該局點，需要重點eply問題，當前版本暫時無法判斷故障在上行取全面優化的策略，需要提升RRC建立過程的初立的同步流程和層三消息順利進行。R配置一致，應該不是主要問題4.

下行干擾余量按照基線配置180，經過計算應該足夠措施5.

上行干擾余量按照基線1.

提升上行干擾余量為192.

其它參數輔助：N300=效果以上措施，PS/CS接通配7率A局點全網無線接通率指標趨勢99.10%99.20%99.30%99.40%99.50%99.60%99.00%98.90%98.80%2-

2-

2-

2-

2-

2-

2-

2-

2-

3-1

3-2

3-3

3-4

3-5

3-6

3-7

3-8

3-9

3-20

21

22

23

24

25

26

27

28

10CS無線接通率PS無線接通率A局點全網RRC指標趨勢99.60%99.55%99.50%99.45%99.40%99.35%99.30%99.25%99.20%99.15%99.10%99.65%2-

2-

2-

2-

2-

2-

2-

2-

2-

3-1

3-2

3-3

3-4

3-5

3-6

3-7

3-8

3-9

3-20

21

22

23

24

25

26

27

28

10會話類RRC建立成功率總體RRC建立成功率Page26接通率提升案例-2現象B局點的CS接通率較低，主要因為RAB接通率較差。2月4日CS

RRC成功率99.12%，CS

RAB成功率99.13%，CS接通率98.26。分析1.PCHR分析，RAB建立失敗80％的原因為“RB建立等待UE響應超時”2.話統中發現CS

RAB的嘗試次數比CS

RRC的嘗試次數多5％左右，懷疑該局點并發業務量比較大3.PCHR進一步發現并發業務中CS

RAB的建立成功率為76.87％，現然非常低4.該局點打開了下行伴隨信道二倍幀分，在先建立PS，再建立CS的并發業務中，下行伴隨信道下發的信令會比不幀分情況下需要的時間更長；因此，需要增大ACTTIMEDEFOFFVALFORSAMECELL措施將ACTTIMEDEFOFFVALFORSAMECELL由原配置80修改為160效果修改該參說后，CS域RAB建立成功率由99.2％左右提升到99.7％左右Page27Page28第1章

性能

與問題處理第2章CS/PS接通率第3章CS/PS掉話率第4章CS/PS互操作成功率Page29第1章CS/PS掉話率第1節掉話率基礎第2節掉話率問題分析方法第3節掉話率優化提升方法第4節掉話率典型案例掉話信令流程與話統規范1.

在業務進行過程中，RNC主動發出IuRelease

Request或RAB

ReleaseRequest 鏈路，則發生掉話2.

Iu 完成后，需要依次

RRC、RL3.

右圖是一個典型的PS掉線中國移動指標規范：TD語音業務無線掉話率=（語音業務RABRAB次數）÷語音業務RAB建立成功次數業務無線掉話率=（

RA次數＋語音業務Iu

對應的次數＋

Iu

對應的RAB次數）÷

RAB建立成功次數PS域無線掉線率=（PS域RA

次數＋PS域I

對應的RAB次數）÷PS域RAB建立成功次數以上定義存在不足之處：分母應該添加“硬切換成功切入次數”Page30Page31話統中掉話原因細分CSRAB.RelReqCsPerCause.113RNC請求 的按原因分類的電路域RAB數目<OM干預>RAB.RelReqCsPerCause.40RNC請求 的按原因分類的電路域RAB數目<一定時間后，數據量很小>RAB.RelReqCsPerCause.16RNC請求 的按原因分類的電路域RAB數目<用戶無響應>RAB.RelReqCsPerCause.1RNC請求 的按原因分類的電路域RAB數目<RAB搶占>RAB.RelReqCsPerCause.65RNC請求 的按原因分類的電路域RAB數目<AAL2失步>PSRAB.RelReqPsPerCause.113RNC請求 的按原因分類的分組域RAB數目<OM干預>RAB.RelReqPsPerCause.40RNC請求 的按原因分類的分組域RAB數目<一定時間后，數據量很小>RAB.RelReqPsPerCause.16RNC請求 的按原因分類的分組域RAB數目<用戶無響應>RAB.RelReqPsPerCause.1RNC請求 的按原因分類的分組域RAB數目<RAB搶占>RAB.RelReqPsPerCause.RbResetRNC請求 的按原因分類的分組域RAB數目<RB復位>RAB.RelReqPsPerCause.GtpuLossRNC請求 的按原因分類的分組域RAB數目<GTPU失步>RAB

：CSIU.AttConnRelReqUtranCs.113RNC請求 電路域Iu連接次數<OM干預>IU.AttConnRelReqUtranCs.16RNC請求 電路域Iu連接次數<UE無響應>IU.AttConnRelReqUtranCs.RlFailRNC請求 電路域Iu連接次數<RL

失步>IU.AttConnRelReqUtranPs.113RNC請求 分組域Iu連接次數<OM干預>PSIU.AttConnRelReqUtranPs.16RNC請求 分組域Iu連接次數<UE無響應>IU.AttConnRelReqUtranPs.RlFailRNC請求 分組域Iu連接次數<RL失步>IU.NbrRabPsRelIuConnPerCause.113RNC請求 分組域Iu連接對應的RAB數目<OM干預>IU.NbrRabPsRelIuConnPerCause.40RNC請求 分組域Iu連接對應的RAB數目<一定時間后，數據量很小>IU.NbrRabPsRelIuConnPerCause.16RNC請求 分組域Iu連接對應的RAB數目<UE無響應>IU.NbrRabPsRelIuConnPerCause.RlFailRNC請求 分組域Iu連接對應的RAB數目<RL失步>IuPage32話統常見掉話原因解釋CallDropRL

FailureSRBResetUserInactiveTRB

ResetRL

Failure：NodeB持續檢測上行空口鏈路，當檢測到NOUTSYNCIND個連續失步幀，啟動TRLFAILURE，若該定時器超時仍未收到NINSYNCIND個同步幀，則判斷上行失步，向RNC發出Radio

Link

Failure

Indication消息；RNC判斷若經過了RLRSTRTMR

＋

N302×T302時間未收到NodeB發出的Radio

Link

Restore，則向

網發出Iu

ReleaseRequest

鏈路SRBReset：在RLC

AM模式下，某個PDU經過了Max_DAT-1次重傳后，都沒有成功發送，發送端因此發起一次RLC重置過程。若在TIMERRST時間內接收了到對端響應，則停止TIMERRST定時器。如果TIMERRST定時器超時，重新發起RLC重置過程，直至經過MAXRST后嘗試后，發生掉話，RNC發出IuRelease

Request消息，攜帶原因值Connection

with

UElost；CDT顯示的RLC層原因為SRB

Reset。User

Inactive：正常 ，不計如掉話TRB

Reset：針對AM模式的TRB，原理同SRB

Reset除UserInactive外，其余主要掉話問題，都與空口質量有關掉話率網上表現RAB異常原因次數原因解釋RR_ERR_RNCAP_RLC_FAILURE_SRB_RST651信令RB復位，CS、PS業務均會出現RR_ERR_RNCAP_RLC_FAILURE_TRB_RST405業務RB復位，PS業務會出現RR_ERR_RNCAP_RB_WAIT_UE_RB_CFG_TIMEOUT97DCCC過程，發出RB

RECFG后，等待UE返回RB

RECFG消息超時；PS業務專有RR_ERR_RNCAP_CU_WAIT_UE_RSP_TIMEOUT34收到UE的CellUpdate請求并響應，但是沒有收到PHY

ChannelComplete消息RR_ERR_IUB_INTERFACE_PERMANENT_RL_FAILURE27NodeB檢測到上行失步，在定時器超時后

IuRR_ERR_RNCAP_RB_CU_OVERLAP_BACK19RB重配置過程，未收到RBRECFG

Complete，收到CellUpdateRR_ERR_RNCAP_RELOC_PSOUT_IU_REL_CMD_TIMEOUT6PS從3G到2G切換，等待Iu

Release

Command超時RR_ERR_RNCAP_DEL_OLD_CCB4兩種場景：（1）是UE掉話RNC側沒有

（原有CCB表沒有刪除），但UE同時又發起了接入流程，導致第一次接入被強制

；（2）當前子系統用戶數滿，此時新接入用戶會剔除之前重連次數最多的用戶RR_ERR_UU_INTERFACEPATIBLE_SIM_RECFG_ERR_NULL_TYPE1從PCHR中信令看，發生RB

RECFG

FAIL；判斷應該與終端突發異常有關掉話問題主要發生在空口！PS域無線掉線率CS域無線掉話率五月1.17%

↑0.17%

↑三月1.48%0.22%近兩月接通率各項指標均有提升！PCHR異常原因值解析（以某局點數據為例）：Page33Page34第1章CS/PS掉話率第1節掉話率基礎第2節掉話率問題分析方法第3節掉話率優化提升方法第4節掉話率典型案例“TOP”思想在掉話率問題中的運用TOP分析各過程，可進行交叉分析；如針對某TOP原因篩選所在的TOP小區、TOP終端掉話率低！怎么辦？TOP原因：根據話統判斷，影響掉話率的主要原因有哪些？各占比例多少？根據PCHR分析，造成掉話的原因有哪些？各占比例多少？結合前面解釋的話統掉話原因與PCHR掉話原因，優先處理非空口原因的接入失敗TOP小區：根據話統、PCHR對發生掉話的TOP小區進行排序，查找TOP小區針對TOP小區的TOP原因，采取對應解決措施TOP小區的相關告警信息需要關注；根據PCHR過濾的框、槽、端口異常信息需要關注必要時可對TOP小區進行實地測試以發現、分析問題關注漏配鄰區對掉話率的影響，必要時可使用RNC的漏配鄰區檢測功能TOP

IMSI/IMEI：PCHR分析前先做“

UE標識”的操作根據PCHR篩選出掉話呼叫，自定義輸出IMSI/IMEI等信息后，使用Excel數據

判斷TOP

IMSI/IMEI信息對于TOPIMSI/IMEI，可分析其業務特征：是否出現周期性掉話，是否出現超短呼叫，整個呼叫過程的上行鏈路質量等對于查找出的TOP

IMSI/IMEI，可采用該終端進行復測，或者直接IMSI的CDT和載頻TPCwinPage35利用PCHR深入分析掉話率問題公共信息塊1.

IMSI，IMEI2.

UE功率能力信令接入塊1.

接入小區、載頻、時隙2.

接入小區P CH

RSCPRAB信息塊1.

RAB請求業務類型2.

RAB請求完成時間3.

RAB掉話域業務指示4.

鏈路質量信息（上行BLER等信息）5.

RAB異常錯誤編碼DCCC信息塊1.

DCCC是否成功統計塊1.

同頻硬切換發起、成功次數2.

異頻硬切換發起、成功次數3.

CellUpdate發起、成功次數4.

RNC間切換發起、成功次數RRC

塊1.時所在小區、載頻、時隙2.

IU

具體原因3.

RRC

RF信息4.

信令流程根據PCHR，可分析：1.

掉話特性與接入電平的關系2.

掉話特性與超短呼叫的關系3.

掉話特性與鏈路質量信息的關系4.

掉話特性與DCCC的關系5.

掉話特性與頻繁切換關系6.

……Page36Page37第1章CS/PS掉話率第1節掉話率基礎第2節掉話率問題分析方法第3節掉話率優化提升方法第4節掉話率典型案例掉話率優化提升措施：場景優化系統內、系統間切換成功率1.

切換不成功或不及時，對掉話的影響很大2.

對于掉話率集中的小區，需要分析其對應的系統內、系統間切換成功率3.

通過PCHR可以分析呼叫

前發出的測量報告，以及發生切換的結果；據此可以將切換性能與掉話性能緊密聯系起來幀分打開場景下PS掉線率的優化DCCC頻繁導致的掉話1.

對于PS業務，頻繁的DCCC會增大掉線風險，表現為RB重配置時等待UE響應超時2.

通過PCHR可以分析PS掉線與DCCC次數之間的關系，以此作為優化調整DCCC參數的依據3.

DCCC場景的優化，通常以降低DCCC次數為標桿；但合理的優化需要同時考慮用戶體驗1.

已知部分終端對幀分特新支持較差，打開網絡側幀分，會導致PS掉線抬升；根據PCHR可判斷TOP

IMEI的影響2.

幀分打開場景下，需要關閉DOFFC功能3.

在5.0版本之前，可適當增大ACTTIMEDEFOFFVALFORUNCELLH以減少PHY

Channel

RECFG未被UE收到的情況頻繁切換與若覆蓋掉話1.

除了通過路測發現頻繁切換以外，還可以通過PCHR來查找貧乏切換呼叫2.

PCHR中的HHO統計塊包含豐富的信息（同頻切換、異頻切換、CellUpdate、RNC間切換的請求、成功次數）3.

根據這些信息，結合呼叫時常，可判斷掉話與切換、CellUpdate的關系Page38Page39第1章CS/PS掉話率第1節掉話率基礎第2節掉話率問題分析方法第3節掉話率優化提升方法第4節掉話率典型案例話統掉話率提升案例現象、、、3等PS掉話率比較高，通過話統幾天的話統看小區掉話次數也多分析1.

通過分析小區40644的PCHRLog，發現很多呼叫在短時間內發生了很多次切換，如下圖，不到5分鐘的呼叫切換了22次2.

查看PCHR最后15條信令也是由于切換物理信道重配過程中的掉話3.

通過PCHR提取出該小區的Top掉話IMSI， 標口消息，證實用戶不斷在做乒乓切換，兩次切換只間隔9s4.

用同樣方法也找到4667也是由于乒乓切換而導致的掉話高措施為了防止小區4667和48053，58053和40644乒乓切換，將CELLINDIVIDALOFFSET從0改為-10效果修改參數后，掉話率得到明顯好轉N454CellNamePS業務掉話率PS業務掉話次數PS業務RAB建立成功次數406440.1033324580530.061017446670.14322Page40Page41第1章

性能

與問題處理第2章CS/PS接通率第3章CS/PS掉話率第4章CS/PS互操作成功率Page42第1章CS/PS互操作成功率第1節互操作基礎第2節互操作問題分析方法第3節互操作優化提升方法第4節互操作典型案例CS互操作信令流程與話統規范中國移動指標規范：系統間CS域切換成功率（TD-SCDMA->GSM）=(電路域系統間切換出請求次數（3G->GSM）-電路域系統間切換出失敗次數（3G->GSM）)/電路域系統間切換出請求次數（3G->GSM）*100%MAP/EMAP/E2.

PREPARE

HANDOVERBSSMAPBSSMAP4.

HANDOVER

REQUESTACKRANAPRANAP13.

IU

RELEASE

COMPLETEBSSMAPBSSMAP3.

HANDOVER

REQUESTMAP/EMAP/E5.

PREPARE

HANDOVERRESPONSERANAPRANAP6.

RELOCATION

COMMANDBSSMAPBSSMAP8.

HANDOVER

DETECTBSSMAPBSSMAP10.

HANDOVER

COMPLETEMAP/EMAP/E11.

SEND

END

SIGNALREQUESTMAP/EMAP/E14.

SEND

END

SIGNALRANAPRANAP1.

RELOCATION

REQUIREDUENodeBSRNCCNGSM/MSCGSM/BSCRRC7.DCCH

:

HANDOVER

FROM

UTRAN

COMMANDRRC[Hard

Handover]RR9.

HANDOVER

COMPLETERRRANAPPage43RANAP12.

IU

RELEASE

COMMANDRESPONSEPS互操作信令流程與話統規范中國移動指標規范：系統間PS域切換成功率（TD-SCDMA->GPRS，UTRAN發起）=(網絡側發起分組域系統間切換出請求次數（TD-SCDMA->GPRS）-分組域系統間切換出失敗次數（TD-SCDMA->GPRS）)/網絡側發起分組域系統間切換出請求次數（TD-SCDMA->GPRS）*100%Page44Page45指標含義IRATHO.FailOutCs.1原因為<配置不支持>的電路域系統間小區間切換出失敗次數(TD-SCDMA->GSM)IRATHO.FailOutCs.2原因為<物理信道失敗>的電路域系統間小區間切換出失敗次數(TD-SCDMA->GSM)IRATHO.FailOutCs.3原因為<協議錯誤>的電路域系統間小區間切換出失敗次數(TD-SCDMA->GSM)IRATHO.FailOutCs.4原因為<系統間協議錯誤>的電路域系統間小區間切換出失敗次數(TD-SCDMA->GSM)IRATHO.FailOutCs.5原因為<不可知錯誤>的電路域系統間小區間切換出失敗次數(TD-SCDMA->GSM)IRATHO.FailOutCs.NoRsp原因為<無響應>的電路域系統間小區間切換出失敗次數(TD-SCDMA->GSM)IRATHO.FailOutCs.RelocAbort原因為<遷移流程中止>的電路域系統間小區間切換出失敗次數(TD-SCDMA->GSM)指標含義IRATHO.FailOutPsUtran.1原因為<配置不支持>的分組域系統間小區間切換出失敗次數(TD-SCDMA->GPRS)IRATHO.FailOutPsUtran.2原因為<物理信道失敗>的分組域系統間小區間切換出失敗次數(TD-SCDMA->GPRS)IRATHO.FailOutPsUtran.3原因為<協議錯誤>的分組域系統間小區間切換出失敗次數(TD-SCDMA->GPRS)IRATHO.FailOutPsUtran.4原因為<不可知錯誤>的分組域系統間小區間切換出失敗次數(TD-SCDMA->GPRS)IRATHO.FailOutPsUtran.NoRsp原因為<無響應>的分組域系統間小區間切換出失敗次數(TD-SCDMA->GPRS)CS域互操作失敗原因：PS域互操作失敗原因：互操作話統指標細分Page46CS互操作常見失敗原因之“物理信道失敗”現象：TD網絡側在下發HANDOVER

FROM

UTRAN之后，終端回復了HANDOVER

FROMUTRANFAILURE，其中攜帶的原因值是物理信道失敗，在互操作失敗原因統計中，該原因是當前CS互操作失敗的top1原因，占70％以上。原因：目標GSM小區原因：干擾較大或者存在快衰，終端與GSM小區同步和接入過程失敗終端測量原因：(1)GSM鄰小區存在同頻鄰小區，導致終端測量的GSM目標小區RSSI值虛高；(2)在配置GSM同頻鄰小區的情況下，部分終端不能正確解析BISC碼，導致上報的鄰區和實際切換不是同一個小區，展訊和聯芯都存在此問題配置錯誤：GSM鄰小區信息未正確配置導致終端在上報測量報告后，網絡側資源準備完成，但是在同步時不能成功；終端本身bug：展訊2G網絡“偽頻點”配置導致終端死機現象；終端上報RSSI值很小的GSM鄰區，導致切換失敗；終端不支持A5-2加密算法，導致切換流程失敗；終端能力上報不支持1800M的GSM，導致切換失??；CS互操作常見失敗原因之“遷移流程終止”現象：TD網絡側在下發HANDOVERFROMUTRAN之后，并未收到終端回復的任何信息，隨后

發起由于

lpete定時器超時導致的IUReleaseCommand，從用戶感受角度，直接掉話；從話統角度，由于是

網主動發起

，只是一次切換失敗，不會記為掉話。該原因是當前CS互操作失敗的top2原因，占20％左右。原因：終端本身bug，例如酷派6168，無線固話等等；終端bug導致切換時遷移流程終止；終端沒有收到切換命令切換失敗回到TD，TD沒有收到Page47PS常見失敗原因之“物理信道失敗”現象:RNC向UE發送CELLCHANGEORDER消息后，UE由于無法重選入GSM小區，回退到TD網絡時向網絡回CELLCHANGEORDERFAILURE消息，攜帶原因為物理信道失敗，該原因是當前CS互操作失敗的top1原因，占90％以上。原因：由于PS切換沒有資源預留過程，如果目標小區負載較高，PS業務切換到目標小區時可能被準入

，導致切換失敗；其他原因同CS切換失敗Page48互操作成功率網上表現區域接通率周平均指標：CS域3Gto2G切換成功率PS3Gto2G切換成功率五月98.32%

↑94.98%

↑三月98.00%94.11%PCHR異常原因值解析（以某局點數據為例）：近兩月互操作成功率逐步提升！切換域互操作切換結果次數原因解釋CSRR_ERR_UU_IRHFC_IRHFC_PHY_CHANEL_FAIL(185468956)1883物理信道失敗RR_ERR_IU_INTERFACE_TIMER_RELOC_CMP_EXPIRY(185272289)763遷移流程終止，聯芯已定位終端存在bugRR_ERR_RNCAP_RELOC_SYS_HO_UU_HO_FAIL(185468901)1833A測量報告后伴隨CELL

UPDATE流程,與空口環境相關。RR_ERR_IU_INTERFACE_REQUESTED_INFO_NOT_AVAIL(185272327)1242準備失敗，不計入切換統計，5.0版本解決該問題PSRR_ERR_UU_IRCFC_PHY_CHANEL_FAIL(185468992)3111物理信道失敗RR_ERR_RNCAP_RELOC_SYS_HO_UU_HO_FAIL(185468901)8313A測量報告后伴隨CELL

UPDATE流程,與空口環境相關。RR_ERR_RNCAP_RELOC_PSOUT_IU_REL_CMD_TIMEOUT(185272280)231無響應RR_ERR_UU_IRCFC_CONF_UNACCEPT(185468991)93終端問題：大唐DT800H數據卡、

貝爾

ASB

T920Page49Page50第1章CS/PS互操作成功率第1節互操作基礎第2節互操作問題分析方法第3節互操作優化提升方法第4節互操作典型案例CS互操作分析流程根據checklist檢查基本參數配置是否正確根據話統cell-gcell表，分析切換失敗的top小區（取一周的話統cell-gcell數據，根據top小區分析原則選取top小區）結合話統cell-gcell表和PCHR數據，分析切換失敗的top原因物理信道失敗遷移流程終止終端原因或者用戶行為原因判斷方法：1、根據PCHR分析，找出top終端類型，和互操作問題終端比較；2、同一IMSI在不同小區經常切換失敗，而其他IMSI在這些小區切換正常，；解決方法：1、展訊終端問題，參照展訊終端問題解決方法；2、中興U110終端問題，參照U110解決方法;3、針對top

IMSI，

用戶，判斷是否由于用戶行為導致切換失敗，必要時可以進行回訪等終端原因判斷方法：RNC下發切換指令后，終端嘗試切換到2G失敗，但返回TD也失?。]有回復“Handover

From

UTRAN

Failure”消息），最終

網IU接口保護定時器超時，下發IU

Release

Command消息，原因值為“Trelocco

mplete－expire”。解決方法：通過降低本系統門限規避CS互操作成功率<98%?是分析整網CS互操作次數是否突變，若有突變，分析各RNC

CS互操作次數是否突變，判斷是否由于參數調整、移動業務推廣等因素導致切換次數增加或減少，成功率下降開始CS互操作成功率〉98%，每天跟蹤指標變化趨勢，若發生突變否鄰區配置不合理或者鄰區干擾大判斷方法：1、同一IMSI切換到某一個鄰區失敗，而切換到其他小區成功；2、所有切入該2G鄰區的成功率偏低解決方法：1、調低該鄰區的CIO2、提高3A異系統門限；3、結合2G話統分析，如果900M鄰區干擾較大，直接刪除該2G鄰區或者用1800M小區替換；CS互操作指標分析流程Page51結合話統cell-gcell表和PCHR數據，分析切換失敗的top原因無響應不可知錯誤物理信道失敗解決方法：檢查

RELOCIURELCMDTMR定時器設置是否為60000，若不是，則進行修改解決方法：分析DCCC參數設置，若設置策略為快升快降，調整為慢升慢降策略解決方法：1、同CS處理方法2、系統間切換失敗懲罰門限/AMNTOFINTERRATCELLPELS設置為1根據checklist檢查基本參數配置是否正確分析整網PS互操作次數是否突變，若有突變，分析各RNCPS互操作次數是否突變，判斷是否由于參數調整、移動業務推廣等因素導致切換次數增加或減少，成功率下降開始PS互操作成功率〉93%，每天跟蹤指標變化趨勢，若發生突變PS互操作成功率<93%?否是PS互操作指標分析流程Page52PS互操作分析流程“TOP”思想在互操