【正文】 016/5/21宿遷_宿城_耿車丁莊LF_163358712920929_1257219192016/5/21宿遷_宿城_耿車丁莊LF_163358712920929_12573772016/5/22宿遷_宿城_耿車丁莊LF_163358712920929_1257233332016/5/22宿遷_宿城_耿車丁莊LF_163358712920929_12573662016/5/23宿遷_宿城_耿車丁莊LF_163358712920929_1257212122016/5/23宿遷_宿城_耿車丁莊LF_163358712920929_12573552）跟蹤信令分析： 4G小區(qū)633587向GSM小區(qū)LAC：51C1(HEX),CI:311c(HEX)對應(yīng)20929_12572發(fā)起eSRVCC切換請求；S1口返回切換準(zhǔn)備失敗HandoverPreparation failure，失敗原因為：ho_failure_in_target_EPC_eNB_or_target_system；S1口返回切換準(zhǔn)備失敗HandoverPreparation failure，失敗原因為：ho_failure_in_target_EPC_eNB_or_target_system；3）4G側(cè)數(shù)據(jù)核查正常；2G側(cè)核查情況216。 2G無告警； 2G小區(qū)無告警，無干擾，接入，切換正常，無擁塞；216。 核查卡特GSM側(cè)三樹楊樓3及三樹楊樓4的切換設(shè)置，發(fā)現(xiàn)切入允許參數(shù)“EN_INCOMING_HO”被設(shè)置為”DISABLED”，正常應(yīng)該設(shè)置為“ENABLED”,配置參數(shù)如下：將EN_INCOMING_HO的”DISABLED”修改“ENABLED”后，eSRVCC切換恢復(fù)正常。 MSC定義BSC不一致導(dǎo)致eSRVCC切換失敗問題近期，通過SEQ平臺，以目標(biāo)小區(qū)為中心查詢eSRVCC切換成功率指標(biāo)時，發(fā)現(xiàn)泰州華為2G站點楊莊二，連續(xù)一周eSRVCC切換成功率成功率均為0。且失敗原因值均為：Relocation Failure withTarget system。，反復(fù)修改RAC無改善，判斷eSRVCC失敗與RAC的設(shè)置、無線側(cè)參數(shù)設(shè)置無關(guān) Lisence及eSRVCC準(zhǔn)入開關(guān)核查經(jīng)網(wǎng)管核查，楊莊二站點3個小區(qū)均已有Lisence，且eSRVCC準(zhǔn)入開關(guān)均已打開。 參數(shù)核查楊莊二3基站3個小區(qū)，原為卡特站點RAC=16。后替換為華為站點后，RAC更改為1，但在4G的鄰區(qū)關(guān)系中，RAC未改，仍為16，因此懷疑可能是RAC在2/4G側(cè)設(shè)置不一致導(dǎo)致eSRVCC失敗。5月24日，在4G的鄰區(qū)關(guān)系中，將RAC改為255兜底默認(rèn)配置，eSRVCC切換仍全部失敗。5月25日再在4G的鄰區(qū)關(guān)系中，將RAC改為1。但根據(jù)26號數(shù)據(jù)來看， eSRVCC切換仍全部失敗，原因值仍為Relocation Failure withTarget system。 現(xiàn)場測試確認(rèn)測試小區(qū)對：4G側(cè)源小區(qū)、2G側(cè)目標(biāo)小區(qū)分別為：廠家區(qū)域地段CellNameTACPCI頻段eNodeBIDCellIDECGIEARFCN華為高港城區(qū)泰州高港野徐二LF121034372F34599718857523338400華為高港城區(qū)泰州高港野徐二LF221034373F34599728857523438400華為高港城區(qū)泰州高港野徐二LF321034374F34599738857523538400CellNameCNSiteNo地市區(qū)縣CellNameLACCIBSICBCCH楊莊二3YangZhuangEr泰州高港YangZhuangEr_32103433663463從4G小區(qū)泰州高港野徐二LF1向弱場移動，希望其通過eSRVCC切換至楊莊二3小區(qū)。根據(jù)空口信令，從15:18:，UE連續(xù)上報B2事件。15:18:,eNODEB向MME發(fā)起切換請求HANDOVER REQUIRED。在此消息中，eNODEB并沒有將RAC值帶給MME。15:18:，MME向DNS發(fā)起請求，由于eNode B 沒有上報RAC，MME用兜底的RAC（255）拼裝FQDN解析 eMSC。在DNS返回解析出來的eMSC ip地址之后，MME向MSC發(fā)起eSRVCC切換請求SRVCC PS to CS Request，也未攜帶RAC信息。15:18:，eMSC向MME回復(fù)SRVCC PS to CS Response，該條消息中攜帶拒絕切換的原因：handover relocation failure withtarget system。15:18:，MME向eNODEB回復(fù)Handover preparation failure。至此，本次eSRVCC失敗。 在此過程中，eNodeb并未上報RAC信息，且MME都采用的兜底的RAC（255），因此判斷eSRVCC失敗與RAC的設(shè)置沒有關(guān)系。，發(fā)現(xiàn)跟蹤A口無消息，eMSC收到MSC發(fā)送切換響應(yīng)消息，攜帶失敗的原因值:invalidcell216。 在eSRVCC發(fā)起的過程中，UEeNodebMMEeMSC階段的信令流程均正常。但最終，eMSC拒絕了切換請求。因此懷疑問題出現(xiàn)在eMSCBSCBts段。再次安排復(fù)測，并跟蹤eMSC側(cè)的消息。15:35:，eMSC向端局發(fā)出了切換請求，且目標(biāo)小區(qū)為46000522A837F（楊莊二3小區(qū)）。216。 15:35:，eMSC從端局收到切換響應(yīng)消息，攜帶失敗的原因值:invalidcell。提示目標(biāo)小區(qū)為無效小區(qū)。216。 再去BSC查看對應(yīng)的A口消息，結(jié)果發(fā)現(xiàn)A口未收到任何信令消息。由此，確認(rèn)問題出現(xiàn)在MSCBSC段。eMSC發(fā)出了切換請求，并且收到了響應(yīng)消息，而目標(biāo)小區(qū)對應(yīng)的BSC卻沒收到任何信息，因此，懷疑與eMSC發(fā)生交互的BSC并非目標(biāo)小區(qū)所在的BSC。216。 數(shù)據(jù)核查結(jié)果：MSC中定義小區(qū)BSC與實際不一致導(dǎo)致經(jīng)查詢,楊莊二基站BSCMSC信令點對應(yīng)如下：CellNameCNSiteNoLACCIBSCMSC號對應(yīng)信令點楊莊二搬遷DBS1楊莊二搬遷DBS12103433661TAZHWBSC186134403280011C9楊莊二搬遷DBS2楊莊二搬遷DBS22103433662TAZHWBSC186134403280011C9楊莊二搬遷DBS3楊莊二搬遷DBS32103433663TAZHWBSC186134403280011C9再在MSC中查詢配置的信令點:發(fā)現(xiàn)楊莊二基站還是對應(yīng)的搬遷前卡特的BSC：TAZABSCG367，對應(yīng)信令點為：0011D8。MSC號LACCIBSC對應(yīng)信令點86134403282103433661TAZABSCG3670011D886134403282103433662TAZABSCG3670011D886134403282103433663TAZABSCG3670011D8216。 在MSC中修改楊莊二基站及其對應(yīng)的信令點。MSC號LACCIBSC對應(yīng)信令點86134403282103433661TAZHWBSC10011C986134403282103433662TAZHWBSC10011C986134403282103433663TAZHWBSC10011C9216。 效果驗證再次進(jìn)行復(fù)測，UE上報B2事件后，MME向MSC發(fā)起eSRVCC切換請求，MSC回復(fù)的響應(yīng)中攜帶接受請求的字段，本次eSRVCC切換成功。經(jīng)多次測試，eSRVCC切換均正常，問題得以解決。 目標(biāo)側(cè)2G存在冗余數(shù)據(jù)或垃圾數(shù)據(jù)導(dǎo)致eSRVCC失敗對5月23日出現(xiàn)切換失敗原因為Handover /Relocation Failure with Target system的2G小區(qū)，分公司核查后發(fā)現(xiàn)部分存在垃圾數(shù)據(jù)，刪除后正常。地市2GCGI5月23日失敗次數(shù)失敗原因南京460005001EB1962G數(shù)據(jù)庫無對應(yīng)小區(qū)南京460005001EB4B12G數(shù)據(jù)庫無對應(yīng)小區(qū)南京460005001EB8712G數(shù)據(jù)庫無對應(yīng)小區(qū)南京4600050066E2D52G數(shù)據(jù)庫無對應(yīng)小區(qū)鎮(zhèn)江4600050ED63BB2鎮(zhèn)江小區(qū)現(xiàn)網(wǎng)找不到鎮(zhèn)江4600050ED63BC2鎮(zhèn)江小區(qū)現(xiàn)網(wǎng)找不到鎮(zhèn)江4600050ED63BD29鎮(zhèn)江小區(qū)現(xiàn)網(wǎng)找不到鎮(zhèn)江4600052C550904鎮(zhèn)江小區(qū)現(xiàn)網(wǎng)找不到無錫46000502C61BD4目標(biāo)2G小區(qū)（尚未開通）為華為設(shè)備計劃開通替換現(xiàn)有的愛立信小區(qū)，工程在定義LTE鄰區(qū)定義中直接使用了原有小區(qū)的BCCH和BSIC，導(dǎo)致存在4G小區(qū)的2G鄰區(qū)里有2個同BCCH和BSIC的小區(qū)。鹽城4600050D3F8E212G數(shù)據(jù)庫無對應(yīng)小區(qū)鹽城460005252719842G數(shù)據(jù)庫無對應(yīng)小區(qū)常州4600052F216C9312G數(shù)據(jù)庫無對應(yīng)小區(qū)常州4600052F216CA62G數(shù)據(jù)庫無對應(yīng)小區(qū)1000timeoutSEQ平臺采集問題 timeout次數(shù)與網(wǎng)管統(tǒng)計進(jìn)行比對，確認(rèn)與網(wǎng)管統(tǒng)計不符對eSRVCC失敗原因值：1000 timeout，選取常州部分小區(qū)指標(biāo)如下：（對應(yīng)時段并沒有SRVCC失?。〥ateIdHourIdCityEutranCellTddeSRVCC嘗試次數(shù)eSRVCC切換成功率eSRVCC成功次數(shù)eSRVCC失敗次數(shù)201652321ERICSSONCMJSCZLD31G79C110010201652321ERICSSONCMJSCZLD33G83A110010201652321ERICSSONCMJSCZLE3EF04A110010201652321ERICSSONCMJSCZLE3EH49A110010201652321ERICSSONCMJSCZLE3LB75B110010201652321ERICSSONCMJSCZLF31B69A310030201652321ERICSSONCMJSCZLF31M85B110010201652321ERICSSONCMJSCZLF32B38E110010201652321ERICSSONCMJSCZLF32B49A0　00201652321ERICSSONCMJSCZLF32B76A110010選取LF21B69A查看CTR如下共上報3次B2與指標(biāo)統(tǒng)計相符，3次切換請求均為不同UE發(fā)起，全部切換成功： 均存在切換請求重發(fā)的問題，重發(fā)間隔1s,非MME重發(fā)。挑選了前5個小區(qū)信令，現(xiàn)象都是MME多發(fā)了1次切換請求，能否找MME核實下有沒重發(fā)DateIdHourIdCityEutranCellTddeSRVCC嘗試次數(shù)eSRVCC切換成功率eSRVCC成功次數(shù)eSRVCC失敗次數(shù)201652321ERICSSONCMJSCZLD31G79C110010201652321ERICSSONCMJSCZLD33G83A110010201652321ERICSSONCMJSCZLE3EF04A110010201652321ERICSSONCMJSCZLE3EH49A110010201652321ERICSSONCMJSCZLE3LB75B110010MME核查發(fā)現(xiàn)確認(rèn)：從具體切換請求的時間戳來看，MME重發(fā)的可能性很小，時間間隔不到1秒。MME有個機制，比如說向eMSC發(fā)送SRVCC PS to CS request請求，其在7S內(nèi)未收到回復(fù)的話，那么會再次發(fā)送一次SRVCC PS to CS request請求給EMSC，所以時間上是不吻合的，屬于信令重復(fù)采集，因為最初只有IMS探針，Sv口是在eMSC側(cè)采集的，現(xiàn)在PS探針剛部署，Sv口在MME側(cè)也采集了，所以存在重復(fù)。等全部驗證OK后，會把eMSC側(cè)的Sv口采集給斷開的。成功Sv口流程如下，如果缺少Response或者Ack ,或者沒有Complete消息均認(rèn)為超時的。PS to CS RequestPS to CS ResponsePS to Complete NotifyPS to Complete Ack失敗原因值為 Handover/Relocation cancelled by source system切換失敗問題分析—4G側(cè)發(fā)起切換取消全省每個地市、每個設(shè)備廠家都有這個問題，占比較高；