東莞割接MME后無線掉話率惡化問題V2.0

文檔名稱文檔密級(jí)TIME\@"yyyy-M-d"2015-6-17華為保密信息,未經(jīng)授權(quán)禁止擴(kuò)散第頁(yè)東莞TAC割接后掉話惡化分析問題描述5.15日凌晨將TAC10250和TAC9822割接到新建的MMEPool后，無線掉話率惡化，不能恢復(fù)；5月26日對(duì)TAC9982和TAC9243進(jìn)行割接，無線掉話率也惡化，不能恢復(fù)，MME為華為設(shè)備。前期初步分析第一批割接的10250和9822前期分析，TOP小區(qū)均是在POOL邊界；掉話主因是UELOST。深入詳細(xì)分析由于第一批割接伴核心網(wǎng)DNS數(shù)據(jù)映射錯(cuò)誤的切換問題，本報(bào)告重點(diǎn)以第二批割接TAC9982/9243掉話抬升為例進(jìn)行分析。掉話原因第二批于5月26日凌晨割接，即5月29日核心網(wǎng)整改DNS（解決MME間TAU更新成功率問題）后進(jìn)一步惡化。主因是UELOST增加。掉話TOP站分布經(jīng)過分析，掉話增多并非整個(gè)TAC所有站均有所增多，掉話TOP站分布有一定關(guān)系，目前來看屬于POOL邊界：挑選新增掉話TOP站挑選條件：割接前每天掉話次數(shù)少于100次；割接后新增掉話次數(shù)排序，挑選TOP，確保目前跟到的掉話信令基本都是屬于新增的掉話。掉話信令經(jīng)過跟蹤典型TOP站分析發(fā)現(xiàn)，新增的掉話信令具有明顯的共性特征：均是S1切換到目標(biāo)側(cè)后在幾百毫秒內(nèi)掉話。典型信令如下：統(tǒng)計(jì)切換入的eNodeBID發(fā)現(xiàn)均是其他POOL的TAC切換入本TAC。信令深入分析：用戶首先從東莞大新圍站點(diǎn)Attach接入。通過wireshark解析分析發(fā)現(xiàn)給該用戶分配的M-TMSI為:D71A1421切換到目標(biāo)側(cè)手機(jī)立馬掉話，eNodeB10秒不活動(dòng)定時(shí)器超時(shí)釋放UELOST。其實(shí)該UE切換到國(guó)龍工業(yè)區(qū)后立馬掉話后，又立馬重新在大新圍站點(diǎn)Attach接入。從其攜帶的M-TMSI信息可以確認(rèn)是同一個(gè)用戶。但是UE切換到目標(biāo)側(cè)國(guó)龍工業(yè)區(qū)后，又立馬掉話，原因?yàn)閁ELOST。POOL邊界：整個(gè)流程如下：該問題與已知問題相同掉話率惡化點(diǎn)出現(xiàn)TAC邊界區(qū)，目前懷疑掉話是因?yàn)閭€(gè)別終端被核心網(wǎng)用#15"nosuitablecellsintrackingarea"拒絕，終端將該TAC記錄在forbiddentrackingareasforroaming列表中，導(dǎo)致終端后續(xù)連接態(tài)切換到forbiddenTAC區(qū)域內(nèi)的小區(qū)后UE自動(dòng)掉話。針對(duì)該懷疑點(diǎn)的理論分析及協(xié)議原理摘錄如下：（1）終端在發(fā)起InitialNAS流程（TAU/Attach/Servicerequest）時(shí)，MME可能因?yàn)榫W(wǎng)絡(luò)側(cè)異常（如：宜昌出現(xiàn)的DRA改造異常，導(dǎo)致MME與HSS間diameter消息交互異常；或者核心網(wǎng)改造恢復(fù)過程中時(shí)序配合問題等）這里就不要了吧，而發(fā)送攜帶#15原因值的TAUreject/Attachreject/Servicereject，此時(shí)UE會(huì)將當(dāng)前TAI記入forbiddenTA列表:這里就不要了吧24.301：（2）TAforbidden列表會(huì)在UE關(guān)機(jī)/USIM卡移除/UE內(nèi)部維護(hù)的周期定時(shí)器（12~24小時(shí)間）超時(shí)后，才會(huì)清除掉24.301：（3）而后處于該forbiddenTA邊界區(qū)的UE可能接入到相鄰的TAC小區(qū)中進(jìn)行業(yè)務(wù)，但forbiddenTAC的鄰區(qū)信號(hào)在滿足條件后，UE會(huì)在連接態(tài)切換到forbiddenTAC的鄰區(qū)，切換到目標(biāo)鄰區(qū)（UE在目標(biāo)小區(qū)發(fā)送切換完成消息RRCConnectionReconfigurationComplete）后，搜索目標(biāo)小區(qū)的SIB（含TAI信息）后，才發(fā)現(xiàn)該小區(qū)屬于forbiddenTA小區(qū)，所以，UE自行掉網(wǎng)離開了目標(biāo)小區(qū)，導(dǎo)致目標(biāo)小區(qū)掉話。協(xié)議規(guī)定UE是在切換完成后，才發(fā)起SIB消息捕獲：36.331：5.3.5.4

ReceptionofanRRCConnectionReconfigurationincludingthemobilityControlInfobytheUE(handover)TAI信息是在SIB1消息中發(fā)送的：實(shí)驗(yàn)室驗(yàn)證被#15號(hào)原因值拒絕終端表現(xiàn)實(shí)驗(yàn)室構(gòu)造模擬復(fù)現(xiàn)場(chǎng)景：源站：PCI=159，TAC=1目標(biāo)站：PCI=158，TAC=5（TAC=5被構(gòu)造成TAU失敗以15號(hào)原因拒絕）成功復(fù)現(xiàn)出，終端被拒絕后的表現(xiàn)：只有158的信號(hào)時(shí)，被拒絕后終端被釋放RRC連接后，無法入網(wǎng)，終端側(cè)顯示不停地在搜信號(hào)，最后顯示無服務(wù)。從159切換入158時(shí)，網(wǎng)側(cè)必現(xiàn)掉話，概率100%。禁止TAI列表終端被網(wǎng)絡(luò)以15號(hào)原因拒絕后將TAI加入FTAI。并啟動(dòng)類似定時(shí)器，ds1=MM=Start87,timeout43200:0（43200s?/3600=12h?）。終端芯片公司對(duì)此的答復(fù)CreatedBy:OnkarUpadhyay(2/11/20154:52AM)DearCustomer,IwillanswerabouttheNASrelatedprints.Youunderstandingiscorrect.Thisistimer:EMM_FORBIDDEN_TAI_CLEAR_TIMERThisissetfor12hrinanditisinaccordancewithNAS3GPPspecification24.301==============================================5.3.2ListsofforbiddentrackingareasTheUEshallstorealistof"forbiddentrackingareasforroaming",aswellasalistof"forbiddentrackingareasforregionalprovisionofservice".TheselistsshallbeerasedwhentheUEisswitchedofforwhentheUICCcontainingtheUSIMisremoved,andperiodically(withaperiodintherange12to24hours).=================================Regards,Onkarnath被拒絕后空閑態(tài)重新搜網(wǎng)的表現(xiàn)終端被網(wǎng)側(cè)以15號(hào)原因拒絕，并釋放RRC連接進(jìn)入空閑態(tài)。終端將被拒絕的TAC加入到FTAI“禁止TAI列表”。終端重新搜網(wǎng)，PSS/SSS同步發(fā)現(xiàn)，又搜到該小區(qū)，還是這個(gè)TAC的PCI。讀取SIB1后發(fā)現(xiàn)該P(yáng)CI的TAC在FTAI“禁止TAI列表”里面，于是將該P(yáng)CI加入黑名單。隨后再次同步時(shí)，就不再主動(dòng)搜索該P(yáng)CI小區(qū)信息。被拒絕后從其他TAC切換入的表現(xiàn)終端正常切換，切換的非競(jìng)爭(zhēng)的隨機(jī)接入過程正常，MSG1/2/3正常。隨后開始讀取系統(tǒng)消息，MSG3過了20ms后就讀取到SIB1。讀取SIB1后發(fā)現(xiàn)該小區(qū)的TAC在FTAI“禁止的TAI列表”里面，于是終端釋放RRC連接。釋放RRC連接后終端重新進(jìn)入搜網(wǎng)ACQ流程，隨后的流程同空閑態(tài)重新搜網(wǎng)過程一樣。FTAI“禁止TAI列表“的影響總結(jié)實(shí)驗(yàn)室驗(yàn)證，終端只要被核心網(wǎng)以12\13\15號(hào)原因拒絕過一次，終端就將該TAC加入FTAI，時(shí)長(zhǎng)為43200s即12個(gè)小時(shí)（其他的終端可能時(shí)長(zhǎng)不一樣，協(xié)議規(guī)定12小時(shí)~24小時(shí)）。此時(shí)終端12個(gè)小時(shí)內(nèi)一直處于該TAC內(nèi)，未做移動(dòng)，那么終端將不再搜索4G網(wǎng)絡(luò)，無法在4G網(wǎng)絡(luò)空閑態(tài)駐留、以及建立連接，除非插拔USIM卡、或者重啟手機(jī)才能恢復(fù)。此時(shí)終端從其他TAC正常接入，切換到被拒絕過的TAC小區(qū)時(shí)，能夠正常完成切換流程，但隨后幾十或幾百毫秒（取決于搜索SIB1的快慢）內(nèi)，UE自行釋放RRC連接，重新搜網(wǎng)，此時(shí)必然造成無線網(wǎng)側(cè)鏈路異常；造成無線側(cè)掉話，掉話原因?yàn)閁ELOST。東莞核心網(wǎng)#15號(hào)原因值拒絕在割接后突增核對(duì)核心網(wǎng)的TAU拒絕指標(biāo)，在割接后出現(xiàn)#15號(hào)原因值突增。區(qū)分MME來看104/304/305/306在26日（割接）TAU#15有突增，101/102/201/202在5月28日（DNS調(diào)整），6月5日有突增。整體來看，東莞所有MME#15號(hào)原因值在在割接后呈增加趨勢(shì)，特別是在28日后突增近2w次。按時(shí)間點(diǎn)統(tǒng)計(jì)，104/304/305/306在5月26日凌晨突增，跟MME跟割接強(qiáng)相關(guān)。按時(shí)間點(diǎn)統(tǒng)計(jì)，101/102/201/202在5月28日凌晨之后變多，跟MME的DNS調(diào)整強(qiáng)相關(guān)。找異常TOP終端POOL邊界只要存在這種被#15拒絕過的用戶，就無法避免這個(gè)問題。一定會(huì)造成無線側(cè)掉話。要把終端找出來，把拒絕的找出來，看是否正常，以及怎么規(guī)避。無線核心網(wǎng)聯(lián)合抓取信令CHR6月11日聯(lián)合核心網(wǎng)一起抓取異常終端信息：核心網(wǎng)側(cè)：開啟時(shí)間：14:30-16:00核心網(wǎng)側(cè)打開POO3，MMEGID：0369的MME的正常呼叫的CHR開關(guān)。無線側(cè)跟蹤：跟蹤時(shí)間：14:40-15:40目標(biāo)站：東莞國(guó)龍工業(yè)區(qū)F-HLH-2只跟蹤S1，勾選去掉PAGE消息。源站：只跟蹤S1和UU信令，勾選去掉PAGE消息POOL3反復(fù)attach，反復(fù)切換入POOL5掉話昨天無線側(cè)拼接了不到一分鐘的信令，一個(gè)用戶反復(fù)切換到國(guó)龍工業(yè)區(qū)POO5

不到一分鐘的時(shí)間里掉話6次，又反復(fù)重新attach到源站東莞李屋POOL3。已從核心網(wǎng)CHR找到該用戶信息：核心網(wǎng)側(cè)對(duì)應(yīng)CHR：POOL5歷史CHR顯示的確被TAC9243以#15拒絕該終端的確被POOL5的國(guó)龍工業(yè)區(qū)所在TAC：9243被#15TAU拒絕過：6月11日凌晨2:47被MME304以#15拒絕TAC9243的TAU：6月11日中午15:15被MME306以#15拒絕TAC9243的TAU：核心網(wǎng)TAU#15拒絕分析根據(jù)CHR打點(diǎn)信息分析，這個(gè)場(chǎng)景是由于TAU新側(cè)在做安全流程時(shí)，收到HSS發(fā)來的CancelLocation。正常信令消息如下圖：沖突場(chǎng)景，在第6步收到第14步的消息。也就是說，該MME作為前一次TAU的老側(cè)，收到HSS的CancelLocation，但實(shí)際上，用戶此時(shí)已經(jīng)TAU切換回來，正在作為新側(cè)進(jìn)行安全流程。問題根因無線側(cè)掉話根因POOL邊界存在TAU被#15小區(qū)不可用拒絕一次的用戶，該用戶會(huì)將該TAC記錄在自身的FTAI（禁止接入TAC列表）中，在不插拔卡/不重啟的之后12-24小時(shí)，該用戶無法接入該TAC，且從可接入的TAC連接態(tài)切換至被拒絕的該TAC，切換流程走完后，搜索SIB1，發(fā)現(xiàn)當(dāng)前所處TAC屬于FTAI列表中，自行釋放空口RRC鏈路重新搜網(wǎng)，不通知網(wǎng)絡(luò)側(cè)，必然造成無線側(cè)UElost掉話。核心網(wǎng)POOL邊界#15根因由于POOL邊界頻繁切換，TAU流程和CancelLocation沖突，導(dǎo)致MME下發(fā)#15。問題根因POOL邊界，無線側(cè)的連續(xù)乒乓跨POOL切換，引起MME的TAU鑒權(quán)流程與HSS的CancelLocation流程沖突，MME下發(fā)#15號(hào)原因值拒絕新的TAU流程，導(dǎo)致：用戶12-24個(gè)小時(shí)內(nèi)無法在該TAC接入，影響用戶正常進(jìn)行4G業(yè)務(wù)。從其他TAC連接態(tài)切換入該TAC會(huì)立即掉話，影響無線側(cè)掉話率。規(guī)避措施臨時(shí)規(guī)避措施優(yōu)化POOL邊界的跨POOL切換的小區(qū)無線參數(shù)，避免乒乓切換，減少?zèng)_突的概率，但無法保證完全規(guī)避。根本解決措施核心網(wǎng)對(duì)這種流程沖突的錯(cuò)誤改寫原因值，不能以12/13/15號(hào)原因值拒絕，以普通原因值拒絕。相關(guān)FAQMMEPOOL間/內(nèi)切換差異POOL內(nèi)切換，eNB走X2，切換前后MME不會(huì)改變。POOL間切換，eNB走S1，切換前后MME改變。eNB如何判斷是否跨POOL切換eNB會(huì)通過X2口識(shí)別周邊的eNB所連接的MMEGID信息。如果切換源站與目標(biāo)站X2鏈路正常，MMEGID相同判定走X2。MMEPOOL改造期間MMEGID相同，但是MME并未組POOL怎么切換？eNB只根據(jù)MMEGID來識(shí)別是否組POOL，處于工程態(tài)的MME組POOL期間，eNB無法識(shí)別是否“真正”的組POOL；依然會(huì)走X2切換。此時(shí)X2切換會(huì)切換準(zhǔn)備失敗，只有當(dāng)目標(biāo)側(cè)返回準(zhǔn)備失敗原因值為UnknownMMECODE或UnknowMMEGID時(shí)，源站eNB會(huì)再次發(fā)起補(bǔ)救流程，嘗試再走一次S1切換。當(dāng)然eNB不會(huì)記錄這種狀態(tài)，例如，UE1先走X2失敗后走S1切換，UE2依然會(huì)優(yōu)先走X2，繼續(xù)失敗，再走S1.現(xiàn)網(wǎng)中本身就存在大量的#15，UE被#15后處在POOL內(nèi)TAL邊界切換，會(huì)掉話嗎？對(duì)用戶來說，肯定會(huì)掉話。對(duì)eNB來說，此時(shí)UE切換到目標(biāo)側(cè)掉話后，立馬重新Attach到源側(cè)，因?yàn)槟繕?biāo)側(cè)與源側(cè)的MME相同，同一個(gè)MME對(duì)一個(gè)用戶只會(huì)保存一個(gè)上下文，MME會(huì)給目標(biāo)側(cè)eNB下發(fā)Normalrel釋放掉老的上下文。此過程只要不超過無線側(cè)的10秒不活動(dòng)定時(shí)器，無線側(cè)就不會(huì)記錄為掉話，如果這個(gè)時(shí)間超過10秒，無線側(cè)依然會(huì)