TD-LTE網(wǎng)絡(luò)優(yōu)化案例匯總

.32/33TD-LTE網(wǎng)絡(luò)優(yōu)化案例匯總項(xiàng)目名稱文檔編號(hào)版本號(hào)部門專業(yè)服務(wù)業(yè)務(wù)部作者版權(quán)所有大唐移動(dòng)通信設(shè)備本資料及其包含的所有內(nèi)容為大唐移動(dòng)通信設(shè)備<大唐移動(dòng)>所有,受中國法律及適用之國際公約中有關(guān)著作權(quán)法律的保護(hù)。未經(jīng)大唐移動(dòng)書面授權(quán),任何人不得以任何形式復(fù)制、傳播、散布、改動(dòng)或以其它方式使用本資料的部分或全部內(nèi)容,違者將被依法追究責(zé)任。目錄1.切換類問題21.1鄰基站信息未配置成功21.2X2口不通導(dǎo)致的切換失敗41.3硬件和傳輸故障61.4隨機(jī)接入?yún)?shù)配置不當(dāng)引起切換失敗71.5重選優(yōu)先級(jí)設(shè)置不一致導(dǎo)致異頻無法切換111.6MME問題導(dǎo)致入POOL基站大量切換失敗121.7開站數(shù)據(jù)模板不對(duì)引起切換失敗171.8傳輸端口環(huán)回問題導(dǎo)致S1切換成功率低211.9府東街-3小區(qū)異常切換<A1/A2異頻切換>242.接入類問題302.1MCC設(shè)置錯(cuò)誤導(dǎo)致E-RAB建立成功率為0302.2核心網(wǎng)問題導(dǎo)致REAB建立失敗312.3LTE多模終端自由選擇網(wǎng)絡(luò)不能接入LTE網(wǎng)絡(luò)問題分析342.4默認(rèn)網(wǎng)關(guān)配置錯(cuò)誤372.5核心網(wǎng)算法問題392.6信令面流程正常業(yè)務(wù)面無法上網(wǎng)案例422.7三星NOTE23信號(hào)標(biāo)識(shí)不顯示問題分析案例433.速率類問題483.1下行子幀調(diào)度不滿導(dǎo)致平均下載速率低問題分析483.2傳輸受限引起的速率問題513.3CFI相關(guān)設(shè)置影響LTE拉網(wǎng)速率分析524.CSFB類問題594.1UE未收到Release消息重選到TDS594.2網(wǎng)絡(luò)側(cè)不下發(fā)Release消息614.3MME配置TA與LA映射錯(cuò)誤導(dǎo)致開機(jī)聯(lián)合注冊(cè)失敗634.4并發(fā)業(yè)務(wù)導(dǎo)致CSFB失敗64切換類問題1.1鄰基站信息未配置成功問題描述：測(cè)試發(fā)現(xiàn)NBHS維科上院FHTL-1PCI=487與NBHS青林灣西FHTL-0PCI=438之間切換失敗。從前臺(tái)測(cè)試LOG可以看出,18:10:8.533占用NBHS維科上院FHTL-1PCI=487上報(bào)MR,目標(biāo)小區(qū)NBHS青林灣西FHTL-0PCI=438,沒有響應(yīng),18:10:50.42秒后上報(bào)第2個(gè)MR。兩個(gè)小區(qū)的位置圖層：問題分析：ATP抓包反饋情況：第一個(gè)MR沒有反饋：第二個(gè)MR,啟動(dòng)切換,但是切換準(zhǔn)備失敗,反饋傳輸資源不足造成,最后還是完成切換,前臺(tái)測(cè)試切換至NBHS錦江年華FHTL-2PCI=320非NBHS青林灣西FHTL-0PCI=438。查看導(dǎo)出的鄰區(qū)關(guān)系列表,NBHS維科上院FHTL-1PCI=487與NBHS青林灣西FHTL-0PCI=438兩個(gè)小區(qū)之間存在鄰區(qū)關(guān)系,但是查看配置文件,發(fā)現(xiàn)青林灣西鄰基站中未配置維科上院的鄰基站信息〔200914與200894。解決措施：添加青林灣西鄰基站中未配置維科上院的鄰基站信息。處理效果添加兩個(gè)基站之間的鄰基站信息后,小區(qū)間切換支持。附件或日志：1.2X2口不通導(dǎo)致的切換失敗問題描述：測(cè)試車輛由南向北行駛至前XX路路段,UE占用NBYZ四季瑞麗1小區(qū)PCI483的信號(hào),在該路段接收到主服小區(qū)的RSRP-106dBm,無線信號(hào)在該路段覆蓋較差。通過UE上報(bào)的測(cè)量報(bào)告發(fā)現(xiàn),UE有上報(bào)切換目標(biāo)為NBYZ現(xiàn)代轎車城3小區(qū)PCI473,該小區(qū)的RSRP-88dBm,信號(hào)良好；但未發(fā)生切換。無線覆蓋示意圖測(cè)量報(bào)告示意圖鄰區(qū)關(guān)系示意圖問題分析：測(cè)試車輛由南向北行駛至前XX路路段,UE占用NBYZ四季瑞麗1小區(qū)PCI483的信號(hào),在該路段接收到主服小區(qū)的RSRP-106dBm,無線信號(hào)在該路段覆蓋較差。通過UE上報(bào)的測(cè)量報(bào)告發(fā)現(xiàn),UE有上報(bào)切換目標(biāo)為NBYZ現(xiàn)代轎車城3小區(qū)PCI473,該小區(qū)的RSRP-88dBm,信號(hào)良好；但未發(fā)生切換,經(jīng)核查鄰區(qū)發(fā)現(xiàn)NBYZ四季瑞麗1小區(qū)與NBYZ現(xiàn)代轎車城3小區(qū)之間未添加鄰區(qū)關(guān)系。解決措施：添加這兩個(gè)小區(qū)鄰區(qū)關(guān)系之后仍不切換,檢查小區(qū)狀態(tài),狀態(tài)運(yùn)行正常,無故障。隨后檢查這兩個(gè)小區(qū)的X2接口連接指示發(fā)現(xiàn),配置狀態(tài)為"不存在",修改為"存在"后,切換正常。處理效果把X2接口連接指示配置狀態(tài)修改為"存在后"切換正常。1.3硬件和傳輸故障問題描述:5月27日,蔣王廟試擴(kuò)L329138,00蔣王廟試擴(kuò)L-2_2站內(nèi)切換指標(biāo)如下：服務(wù)小區(qū)名稱服務(wù)小區(qū)IDeNodeB內(nèi)切換出成功次數(shù)eNodeB內(nèi)切換出嘗試次數(shù)eNodeB內(nèi)切換出失敗次數(shù)ENODE內(nèi)切換成功率蔣王廟試擴(kuò)L329138,00蔣王廟試擴(kuò)L-2_2329138911281.82%32913856183.33%32913856183.33%32913846266.67%從KPI的統(tǒng)計(jì)表中可以看出,基站內(nèi)切換成功率在一段集中的時(shí)間內(nèi)較差,而之前的時(shí)間段ENB內(nèi)切換成功率均為100%。問題分析：根據(jù)下圖上午MR計(jì)算出目標(biāo)小區(qū)的RSRP為-90dBm,覆蓋良好。1.4隨機(jī)接入?yún)?shù)配置不當(dāng)引起切換失敗問題描述：使用L1*Outum8.0進(jìn)行測(cè)試時(shí)候發(fā)現(xiàn)XXXXLTE網(wǎng)絡(luò)新入網(wǎng)很多基站在無線環(huán)境很好〔RSRP-80dbm左右&SINR20左右的情況下基站內(nèi)小區(qū)間切換均失敗,在測(cè)試中時(shí)出現(xiàn)以下情況,UE在正常接入小區(qū)后,UE上發(fā)測(cè)量報(bào)告,然后基站下發(fā)重配置消息,UE上傳重配置完成消息,從無線口信令消息看切換已經(jīng)完成。但是從測(cè)試過程中發(fā)現(xiàn)并沒有切換成功,而是經(jīng)過2秒后基站下發(fā)MIB消息、系統(tǒng)消息,然后UE上傳連接重建消息,接著基站下發(fā)連接重建命令,UE上傳連接重建完成,到此UE應(yīng)該是重新接入小區(qū),并不是切換。具體個(gè)例如下：同時(shí)在基站側(cè)用ATP進(jìn)行跟蹤時(shí),出現(xiàn)如下圖情況：UE上傳測(cè)量報(bào)告,基站下發(fā)連接重配置消息,但UE在2秒內(nèi)無回應(yīng)或者基站在這2秒內(nèi)沒收到重配置完成消息,于是2秒之后UE上傳系統(tǒng)消息1,而基站則下發(fā)系統(tǒng)消息2,然后就是上傳連接重建請(qǐng)求消息,基站下發(fā)連接重建命令,接著UE上傳連接重建完成,到此UE重新接入小區(qū)問題處理流程：1、首先針對(duì)小區(qū)內(nèi)鄰區(qū)進(jìn)行檢查,鄰區(qū)配置正確；2、由于是雙模站點(diǎn),所以提取同樣為雙模站點(diǎn)的XX參數(shù)進(jìn)行對(duì)比,發(fā)現(xiàn)關(guān)于切換的參數(shù)均配置正確；3、通過以上分析發(fā)現(xiàn)發(fā)生切換時(shí)候手機(jī)能上報(bào)重配置完成消息,但是基站側(cè)沒有收到這條消息,說明有可能是接入?yún)?shù)有異常。4、研發(fā)支持：通過收取CDL/ATP/基站公共日志進(jìn)行分析以后研發(fā)懷疑是隨機(jī)參數(shù)設(shè)置不當(dāng)造成的,隨機(jī)接入?yún)?shù)零相關(guān)配置參數(shù)現(xiàn)場(chǎng)設(shè)置為11比較大,建議調(diào)整為默認(rèn)的設(shè)置3以后進(jìn)行試驗(yàn)。問題解決效果：將零相關(guān)配置從11調(diào)整為3以后從下圖可以看出調(diào)整前測(cè)試還是出現(xiàn)切換失敗,但是調(diào)整以后基站內(nèi)小區(qū)間切換成功,對(duì)基站間相鄰小區(qū)的切換也成功,說明該問題已經(jīng)解決?？偨Y(jié)：根序列索引規(guī)劃建議現(xiàn)網(wǎng)中宏站Preamble格式通常選擇格式0,室分為格式4；宏站PRACH配置索引設(shè)置為3,室分為51；室外推薦的零相關(guān)配置為3,對(duì)應(yīng)低速非受限取值為18；室內(nèi)站點(diǎn)零相關(guān)配置為3；對(duì)應(yīng)的Ncs值為8；根序列索引的配置和PCI相關(guān)：若室外宏站的零相關(guān)配置采用3,對(duì)應(yīng)的Ncs值為18,這樣每個(gè)根序列能產(chǎn)生838/18=46個(gè)preamble碼,每個(gè)小區(qū)需要產(chǎn)生64個(gè)preamble碼,故需要64/46=2個(gè)根序列產(chǎn)生一個(gè)小區(qū)所需的premble碼,故838個(gè)索引能產(chǎn)生838/2=419個(gè)小區(qū)所需的preamble碼,所有小區(qū)重復(fù)利用這419個(gè),為了避免相鄰小區(qū)的根序列索引沖突,故根序列索引值和PCI關(guān)聯(lián),即根序列索引=〔PCImod419*2；室分站點(diǎn)零相關(guān)配置采用3,對(duì)應(yīng)的Ncs值等于8,這樣每個(gè)根序列能產(chǎn)生138/8=17個(gè)preamble碼,每個(gè)小區(qū)需要產(chǎn)生64個(gè)preamble碼,故需要64/17=4個(gè)根序列產(chǎn)生一個(gè)區(qū)所需的premble碼,故138個(gè)索引能產(chǎn)生138/4=34個(gè)小區(qū)所需的preamble碼,所有小區(qū)重復(fù)利用這34個(gè),為了避免相鄰小區(qū)的根序列索引沖突,故根序列索引值和PCI關(guān)聯(lián),故根序列索引=〔PCImod34*4。排查基站告警,在查詢基站告警日志發(fā)現(xiàn)在該時(shí)間段存在小區(qū)退服,傳輸故障,X2鏈路故障的告警。如果由于小區(qū)重復(fù)退服,可能導(dǎo)致站內(nèi)切換成功率下降。告警名稱告警級(jí)別告警源網(wǎng)元類型產(chǎn)生時(shí)間小區(qū)退服,傳輸故障主要蔣王廟試擴(kuò)L329138,小區(qū)2ENB2013-05-2720:38:16X2鏈路故障次要蔣王廟試擴(kuò)L329138,SCTP鏈路2ENB2013-05-2720:02:05小區(qū)退服,傳輸故障主要蔣王廟試擴(kuò)L329138,小區(qū)2ENB2013-05-2719:28:36問題解決：安排基站人員上站排查,重現(xiàn)建立X2鏈路后告警消除。解決效果：28日現(xiàn)場(chǎng)排除告警后提取當(dāng)日指標(biāo)進(jìn)行驗(yàn)證。下表為蔣王廟28日全天級(jí)指標(biāo),已有明顯提升。服務(wù)小區(qū)名稱服務(wù)小區(qū)IDeNodeB內(nèi)切換出成功次數(shù)eNodeB內(nèi)切換出嘗試次數(shù)eNodeB內(nèi)切換出失敗次數(shù)ENODE內(nèi)切換成功率蔣王廟試擴(kuò)L329138329138261264398.86%1.5重選優(yōu)先級(jí)設(shè)置不一致導(dǎo)致異頻無法切換問題描述：XXXXLTE實(shí)驗(yàn)網(wǎng)新開局對(duì)室內(nèi)和宏站之間異頻切換進(jìn)行驗(yàn)證。使用L1*Outum8.0/華為MIFI*Outum8.0進(jìn)行異頻切換驗(yàn)證；驗(yàn)證參數(shù)配置：1、X2鏈路、鄰區(qū)關(guān)系與小區(qū)異載波信息配置完成；2、A1A2算法均開啟測(cè)量；3、GAP測(cè)量打開；從驗(yàn)證結(jié)果發(fā)現(xiàn)室分可以切換到宏站,而從宏站無法切換到室分；問題分析：在進(jìn)行切換驗(yàn)證測(cè)試時(shí)發(fā)現(xiàn)當(dāng)師大商學(xué)院〔宏站的RSRP值達(dá)到-112dbm且嵩明XX師范大學(xué)商學(xué)院動(dòng)感廳〔室分的RSRP達(dá)到-69dbm時(shí),已經(jīng)達(dá)到切換門限,但是UE仍駐留在師大商學(xué)院2小區(qū)中不發(fā)生切換,最終由于信號(hào)過低終端進(jìn)行重建而駐留到室分基站,切換失敗,查看信令消息時(shí),此時(shí)UE已經(jīng)上傳測(cè)量報(bào)告,而且也有重配置消息下發(fā)但是終端并沒有發(fā)生切換,對(duì)重配置消息進(jìn)行解析發(fā)現(xiàn)該重配置消息并不是用于切換的重配置消息。如下圖所示問題處理流程：1、對(duì)兩個(gè)基站的X2鏈路及鄰區(qū)關(guān)系進(jìn)行刪除再重新創(chuàng)建,并且重新配置異頻載波信息,切換問題未解決；2、由于室外宏基站是雙模站而室分是單模站,因此對(duì)單模站點(diǎn)的"單模RRU幀頭偏移置"進(jìn)行設(shè)置,由無偏移設(shè)置為700us,參數(shù)修改以后進(jìn)行驗(yàn)證,切換問題未解決；3、經(jīng)研發(fā)老師指導(dǎo)發(fā)現(xiàn)師大商學(xué)院基站的小區(qū)重選公共參數(shù)中的"小區(qū)重選優(yōu)先級(jí)"設(shè)置為3,而EUTRAN異頻載波信息中的"小區(qū)重選頻點(diǎn)優(yōu)先級(jí)"設(shè)置為1。將小區(qū)重選公共參數(shù)中的"小區(qū)重選優(yōu)先級(jí)"設(shè)置為1,與EUTRAN異頻載波信息中的"小區(qū)重選頻點(diǎn)優(yōu)先級(jí)"設(shè)置保持一致,切換問題解決；問題解決效果將師大商學(xué)院基站的小區(qū)重選公共參數(shù)中的"小區(qū)重選優(yōu)先級(jí)"設(shè)置為1,與EUTRAN異頻載波信息中的"小區(qū)重選頻點(diǎn)優(yōu)先級(jí)"設(shè)置為1保持一致,通過驗(yàn)證發(fā)現(xiàn)問題已經(jīng)徹底解決?？偨Y(jié)：目前我司設(shè)備的異頻切換算法,采用A1/A2/A3/A4/A5算法,A1用于異頻關(guān)閉,其中A2用于開啟異頻測(cè)量,A3用于啟動(dòng)切換請(qǐng)求〔當(dāng)A3用于異頻時(shí)必需保證源小區(qū)和目標(biāo)小區(qū)的小區(qū)重選優(yōu)先級(jí)一致,A4用于異頻高優(yōu)先級(jí)切換,A5用于異頻低優(yōu)先級(jí)切換；在異頻切換時(shí),若僅開啟A2、A3測(cè)量開關(guān),小區(qū)重選公共參數(shù)中的"小區(qū)重選優(yōu)先級(jí)"與EUTRAN異頻載波信息中的"小區(qū)重選頻點(diǎn)優(yōu)先級(jí)"設(shè)置必須一致。出于某種目的,"小區(qū)重選優(yōu)先級(jí)"必須設(shè)置成不一致時(shí),需要開啟A4或者A5測(cè)量開關(guān)用于異頻測(cè)量。1.6MME問題導(dǎo)致入POOL基站大量切換失敗問題描述：XXKPI組發(fā)現(xiàn)3月8日后全網(wǎng)的切換成功率一直在惡化,提取切換失敗TOP小區(qū)分析CDL發(fā)現(xiàn),切換失敗大部分為目標(biāo)小區(qū)回復(fù)切換準(zhǔn)備失敗攜帶原因?yàn)閠ransport-resource-unavailable。問題分析：在基站版本45.16版本升級(jí)后,XX全網(wǎng)也出現(xiàn)了大量的切換失敗,失敗原因?yàn)閠ransport-resource-unavailable,排查定位過程發(fā)現(xiàn)是基站的鄰基站中SCTP鏈路索引對(duì)應(yīng)錯(cuò)誤導(dǎo)致,基站升級(jí)后解決。而近期又出現(xiàn)了相同原因的切換失敗,所以第一時(shí)間核查了全網(wǎng)的X2鏈路、鄰基站,但是發(fā)現(xiàn)并沒有異常,于是基本排除是X2鏈路、鄰基站的原因?qū)е履繕?biāo)小區(qū)切換準(zhǔn)備失敗。于是,分析TOP小區(qū),以上渡派出所-DLH〔ENBID:418705為例,提取該站CDL日志分析。切換統(tǒng)計(jì)顯示站內(nèi)切換和S1切換都正常,X2切換成功率只有10.79%,而且切換出失敗中99.91%是"切換目標(biāo)側(cè)準(zhǔn)備失敗",通過切換分析可以看出,1082次切換失敗,全部是往ENBID:418644切換,而且釋放原因全部為transport-resource-unavailable?，F(xiàn)場(chǎng)已知該原因釋放的問題主要是X2資源導(dǎo)致的,而已經(jīng)核查過全網(wǎng)X2配置,且確認(rèn)418705和418644之間完全正常。 在X2切換成功的詳表中發(fā)現(xiàn)目標(biāo)基站ID為418644的切換有成功的,于是對(duì)比時(shí)間相近的切換失敗和切換成功。通過對(duì)比x2HandoverRequest的IE值,發(fā)現(xiàn)切換成功時(shí)該消息拾的GUMMEI中MME-CODE為'D0H〔208對(duì)應(yīng)XXMME,而切換失敗時(shí)的MME-CODE都為'10H<16>對(duì)應(yīng)XXMME。在OMC上查看418705的S1鏈路狀態(tài),發(fā)現(xiàn)到XXMME的S1鏈路狀態(tài)為"與對(duì)端連接成功"〔正常,而與XXMME的S1鏈路狀態(tài)為"驅(qū)動(dòng)建立成功"〔故障。 再分析目標(biāo)基站418644的CDL日志,發(fā)現(xiàn)該站有大量的S1建立失敗信令,檢查S1SetupRequest的各IE值都正常,S1SetupFailure攜帶原因?yàn)閙essage-not-compatible-with-receiver-state。為區(qū)分是基站問題還是MME問題,分別刪除再添加該站到XX和XX的MME,到XXMME的S1鏈路馬上建立成功,到XXMME的S1鏈路仍然故障。對(duì)比基站給兩個(gè)MME發(fā)送的S1SetupRequest的IE值完全一致,說明基站的S1SetupRequest消息并沒有問題,問題出在XXMME上。 分析剩余的TOP小區(qū),發(fā)現(xiàn)都存在與418705一致的現(xiàn)象,即目標(biāo)小區(qū)到XXMME的S1鏈路故障。 目前XX全網(wǎng)基站已開啟S1-FLEX算法,全部入MMEPOOL<XX、XX兩臺(tái)MME>,且兩臺(tái)MME的能力都配置為50,為負(fù)荷分擔(dān)方式組網(wǎng),所以正常入POOL的基站下接入,UE有50%的概率接入到兩臺(tái)MME上。 通過信令和TS36.413我們可以知道,ENB發(fā)起S1SetupRequest,MME回復(fù)S1SetupResponse會(huì)攜帶MME的相關(guān)信息〔PLMN,MME組號(hào),MME編號(hào),MME能力等。,而S1鏈路建立失敗時(shí)ENB獲取不到相應(yīng)的MME的信息的。 假設(shè)ENB1正常入POOL〔兩條S1〔S1a,S1b正常,ENB2〔其中1條S1故障〔S1a正常,S1b故障,當(dāng)UE在ENB1下從S1a接入,往ENB2切換,由于ENB2的S1a是正常的,ENB2上有S1a對(duì)應(yīng)MME的信息,切換可以正常進(jìn)行。而當(dāng)UE在ENB1下從S1b接入,往ENB2切換,由于ENB2的S1b故障,ENB2上并沒有S1b對(duì)應(yīng)的MME信息,所以切換需要的S1資源無法成功準(zhǔn)備,所以會(huì)給ENB1回復(fù)HandoverPreparationFailure,導(dǎo)致切換失敗。解決措施： 在分析出是XXMME問題導(dǎo)致全網(wǎng)切換失敗后,聯(lián)系XXMME人員,提供S1建立失敗的基站信息,MME側(cè)抓包、提取MME日志確認(rèn)是MME的問題。只要MME處理完后基站S1正常建立,切換成功率即可恢復(fù)。 雖然切換成功率惡化的原因已查明為MME故障,但是在定位過程中基站給出的切換準(zhǔn)備失敗的Cause值誤導(dǎo)了現(xiàn)場(chǎng)的問題定位。 對(duì)于目標(biāo)S1鏈路故障導(dǎo)致切換準(zhǔn)備失敗的現(xiàn)象,在和NSN,ZTE跨廠家切換的時(shí)候已經(jīng)分析過,但是對(duì)于這類問題,其他廠家一般在HandoverPreparationfailure中攜帶的原因?yàn)?UnknownMMECode",而我們基站是回復(fù)"transport-resource-unavailable",影響了問題的定位效率,而TS36.423中對(duì)這類原因有注釋,其他廠家此類問題的原因歸類為"UnknownMMECode"更能有效指導(dǎo)問題定位。 與研發(fā)確認(rèn),目前基站版本eNB只是發(fā)現(xiàn)用戶所在的Gummei與自己連接的MME不一致,直接判斷失敗。并沒有進(jìn)一步判斷是GroudID不正確,Plmn不正確,還是MmeCode不正確。為便于容易指導(dǎo)現(xiàn)場(chǎng)定位,后續(xù)基站版本會(huì)加入相應(yīng)判斷,優(yōu)化Cause值。處理效果： 3月15日凌晨,XXMME人員針對(duì)S1無法建立的問題現(xiàn)場(chǎng)處理后,原因到XXMME的S1鏈路故障的全部恢復(fù)正常,當(dāng)天全網(wǎng)的切換成功率就回升到95%。1.7開站數(shù)據(jù)模板不對(duì)引起切換失敗問題描述：近日新開LTE室VIP站點(diǎn)泗陽移動(dòng)公司新大樓,添加完鄰區(qū)后狀態(tài)正常,現(xiàn)場(chǎng)發(fā)現(xiàn)無法切換到室外宏站,但是室外宏站可以切換到室內(nèi),隨后對(duì)該問題進(jìn)行分析定位。問題分析：無線環(huán)境分析CellNameECITACBandWidthFrequency_DLPCI宿遷泗陽移動(dòng)新大樓LEW-1020559202360500宿遷泗陽新世界LF-102055920189084根據(jù)現(xiàn)場(chǎng)測(cè)試,宿遷泗陽移動(dòng)新大樓室外最強(qiáng)宏站為泗陽新世界LF-1,RSRP電平在-90~-100之間,相對(duì)較弱,但根據(jù)小區(qū)算法-切換算法-鄰小區(qū)RSRP門限為20〔-120dbm,室外電平滿足切換入的要求。信令分析1、通過前臺(tái)新令分析,在由室內(nèi)到室外過程中,UE發(fā)送MR后收到RRC釋放請(qǐng)求,并沒有進(jìn)入RRC重配過程,如下圖：從后臺(tái)上看為收到測(cè)量報(bào)告后,eNB向EPC側(cè)發(fā)送UEContextReleaseRequest釋放上下文,同時(shí)向UE發(fā)送RRC釋放,最終無法完成切換。分析eNB釋放上下文攜帶的原因?yàn)閡e-not-aivilble-for-ps-service,該原因與CSFB重定向到2G的原因一致,對(duì)RRCConnectionRelease進(jìn)行分析,發(fā)現(xiàn)攜帶GERAN頻點(diǎn)信息,初步判斷為進(jìn)入了盲重向過程,而沒有進(jìn)行異頻信息測(cè)量。2、現(xiàn)場(chǎng)隨后進(jìn)行參修改,關(guān)閉小區(qū)-小區(qū)測(cè)量-A3事件配置1.1-測(cè)量相關(guān)算法中的小區(qū)間干擾協(xié)調(diào)算法,同時(shí)將A1和A2RSRQ門限值都修改為-50,現(xiàn)場(chǎng)測(cè)試發(fā)現(xiàn)UE一直上發(fā)測(cè)量報(bào)告,但無法收到攜帶異頻〔38350的RRC重配置消息,導(dǎo)致終端一直無法進(jìn)行異頻測(cè)量,該問題為現(xiàn)場(chǎng)將A1/A2設(shè)置一致導(dǎo)致異頻測(cè)量無法啟動(dòng)。3、現(xiàn)場(chǎng)將GERAN異載波信息、GERAN鄰小區(qū)關(guān)系刪除,同時(shí)將A2RSRP門限值修改為-90,同時(shí)關(guān)閉A1事件配置〔關(guān)閉A1事件配置為更換定位問題,終端始終開啟異頻測(cè)量,測(cè)試發(fā)現(xiàn)能夠正常進(jìn)行切換。4、后臺(tái)重新將GERAN異載波信息、GERAN鄰小區(qū)關(guān)系添加后測(cè)試,又再現(xiàn)RRC釋放,現(xiàn)象和之前一樣,判斷為添加GERAN異載波信息后上報(bào)本小區(qū)電平測(cè)量達(dá)到一定的門限,觸發(fā)了盲重定向過程,而該過程門限高于異頻切換門限,導(dǎo)致在室內(nèi)到室外移動(dòng)過程中,室內(nèi)信號(hào)漸弱,在室外電平未滿足切換之前發(fā)生了盲重定向,釋放RRC,其中A2RSRP門限、系統(tǒng)間測(cè)量門限、和盲重定向門限設(shè)置如下當(dāng)時(shí)無線環(huán)境RSRP電平在-90~-100之間,有可能啟動(dòng)系統(tǒng)間測(cè)量,但是若盲重定向門限為-118dbm,則不滿足盲重定向門限。5、重新核查盲重定向門限,發(fā)現(xiàn)該站點(diǎn)小區(qū)-小區(qū)算法-異系統(tǒng)互操作中無重定向門限,如下：而正常的站點(diǎn)含有盲重定向門限,如下：問題定位：經(jīng)過上述分析,將問題定位為RRC釋放的原因?yàn)榘l(fā)送了盲重定向,而該站點(diǎn)模板或版本存在問題,無盲重定向門限設(shè)置導(dǎo)致。盲重定向門限為TD-LTE_V3.20.03版本后添加的,該站點(diǎn)開通時(shí)項(xiàng)目已統(tǒng)一使用45.17.03的開站模板,進(jìn)一步核查,發(fā)現(xiàn)該站點(diǎn)運(yùn)行基站軟件包版本為TD-LTE_V3.20.00.45.17而使用45.17.03模板進(jìn)行開通導(dǎo)致,隨后對(duì)該站點(diǎn)軟件版本升級(jí)到TD-LTE_V3.20.03后測(cè)試正常。未出現(xiàn)盲重定向問題。后續(xù)建議：該問題最終定位為站點(diǎn)開通模板和站點(diǎn)運(yùn)行的軟件包版本不一致導(dǎo)致,由于版本升級(jí)前后的變更可能導(dǎo)致個(gè)別新增的參數(shù)和功能在老版本的站點(diǎn)中出現(xiàn)問題,最終導(dǎo)致異常事件發(fā)生,建議在后續(xù)站點(diǎn)開通過程規(guī)范版本和模板,開站數(shù)據(jù)模板注明對(duì)應(yīng)的版本信息,保證督導(dǎo)使用現(xiàn)網(wǎng)最新統(tǒng)一的版本和基站數(shù)據(jù)進(jìn)行站點(diǎn)開通。1.8傳輸端口環(huán)回問題導(dǎo)致S1切換成功率低問題描述：XX兩站之間S1切換失敗次數(shù)較多,影響全網(wǎng)KPI指標(biāo)。查看SCTP鏈路故障,顯示驅(qū)動(dòng)配置成功。問題分析：查看CDL：UE上發(fā)MR之后,由于X2鏈路故障基站判決走S1切換。在經(jīng)過200個(gè)半幀后遲遲未收到核心網(wǎng)的回應(yīng),導(dǎo)致S1切換定時(shí)器超時(shí)后向EPC發(fā)起切換取消的命令。這里有兩種可能,一種是基站側(cè)消息發(fā)出去了核心網(wǎng)沒有收到。一種是核心網(wǎng)下發(fā)了回應(yīng)消息而基站側(cè)沒有收到。定位過程：出現(xiàn)這種情況受限切換走S1就不正常,需要先排查X2鏈路故障的原因。通過查看核查鄰區(qū)關(guān)系,路由配置以及傳輸參數(shù)沒有發(fā)現(xiàn)問題。用LMT登錄基站在診斷測(cè)試?yán)锘ハ鄍ing對(duì)端基站的業(yè)務(wù)IP都不通,在A站Ping自己的網(wǎng)關(guān)發(fā)現(xiàn)存在丟包現(xiàn)象。查看SCTP鏈路顯示驅(qū)動(dòng)配置成功,A站為服務(wù)器,B站為客戶端。刪除A站的服務(wù)器后A站又自動(dòng)建立。然后同時(shí)刪除兩端的SCTP鏈路,在A站建立客戶端,然而B站卻無法自動(dòng)建立服務(wù)器。說明B站收不到A站的發(fā)包,而A站卻可以收到B站的發(fā)包。因此懷疑傳輸側(cè)存在問題,導(dǎo)致X2鏈路不通?；镜木W(wǎng)關(guān)跟基站間就相當(dāng)于區(qū)域網(wǎng)內(nèi)直連,如果這樣ping通的情況都會(huì)有丟包,說明基站跟網(wǎng)關(guān)的物理鏈路很不好,即基站消息發(fā)送的第一結(jié)點(diǎn)都不能保證傳輸質(zhì)量。而傳輸質(zhì)量不好必然會(huì)影響切換的成功率。為進(jìn)一步定位是否是傳輸問題影響的切換,進(jìn)行以下操作：打開電腦的cmd命令窗口,telnet登陸基站,使用OM管理IP,例如：telnet,用戶名和密碼都是root然后直接敲命令ping對(duì)端基站,ping時(shí)候使用X2對(duì)端業(yè)務(wù)IP,例如ping9-s200-c10[-s<SIZE>表示ping包大小,-c<CNT>表示ping次數(shù)]之后會(huì)在cmd命令窗口,看到如下示例,如果PTN端口有問題,會(huì)看到好多回復(fù)報(bào)文,TTL從64減到1才會(huì)停止。如果兩個(gè)站ping不通,可以選另外一個(gè)可以ping通的X2對(duì)端基站,以便發(fā)現(xiàn)PTN內(nèi)部環(huán)回問題。傳輸端口環(huán)回：傳輸正常：定位結(jié)果：現(xiàn)場(chǎng)將此問題現(xiàn)場(chǎng)呈現(xiàn)給傳輸側(cè),傳輸重新把該站的傳輸數(shù)據(jù)做了一下之后SCTP鏈路全部恢復(fù)正常,提取KPI指標(biāo),沒有再出現(xiàn)S1切換,且X2切換成功率明顯上升。1.9府東街-3小區(qū)異常切換<A1/A2異頻切換>問題描述：府東街基站天線可視20米距離不能切換到該基戰(zhàn),始終占用臨近鄉(xiāng)政府基站信號(hào)問題分析：8月8日路測(cè)人員反映在府東街基站附近面對(duì)天線可是條件20米距離只能接收到鄉(xiāng)政府基站兩個(gè)扇區(qū)的信號(hào),收不到府東街的信號(hào)。測(cè)試工程師打至后臺(tái),確認(rèn)基站狀態(tài)正常,功率參數(shù)正常。使用CDS設(shè)備到現(xiàn)場(chǎng)測(cè)試發(fā)現(xiàn)：圖中紅色圓圈位置距離鄉(xiāng)政府基站560m,距離府東街距離280米,在已經(jīng)越過府東街280的情況下,而且鄉(xiāng)政府1小區(qū)RSRP已經(jīng)達(dá)到-99dBm的情況下沒有切換到府東街基站。核查基站狀態(tài)、功率參數(shù),都在正常范圍內(nèi)。為了確認(rèn)是否為基站問題,做了反向測(cè)試,發(fā)現(xiàn)從府東街到鄉(xiāng)政府方向能正常占用府東街信號(hào)。下圖是反向測(cè)試截圖,表明終端可正常占用府東街信號(hào)：反向測(cè)試結(jié)果表明,問題不在基站側(cè)。反復(fù)測(cè)試時(shí)發(fā)現(xiàn),從鄉(xiāng)鎮(zhèn)局到府東街方向,終端在占用鄉(xiāng)鎮(zhèn)局信號(hào)時(shí)不上報(bào)A2消息,而且鄉(xiāng)鎮(zhèn)局的信號(hào)已經(jīng)到了-99dBm時(shí)都沒有下發(fā)鄰區(qū)列表,初步分析問題出在鄉(xiāng)鎮(zhèn)局,不是鄉(xiāng)鎮(zhèn)局到府東街不能切換,應(yīng)該是鄉(xiāng)鎮(zhèn)局參數(shù)配置有誤。核查后臺(tái)參數(shù)后發(fā)現(xiàn)鄉(xiāng)鎮(zhèn)局為F頻段基站〔38350,府東街為D頻段基站〔37900,鄉(xiāng)鎮(zhèn)局基站A1配置為-98dBm,A2配置為-100dBm,府東街基站A1配置為-88dBm,A2配置為-90dBm,兩個(gè)基站的事件遲滯參數(shù)配置都為2。在LTE系統(tǒng)切換分為三個(gè)步驟：在切換過程中的異頻異系統(tǒng)測(cè)量主要由A1、A2事件控制,A1事件表示服務(wù)小區(qū)質(zhì)量高于一定門限,當(dāng)滿足事件觸發(fā)條件時(shí),UE便上報(bào)測(cè)量報(bào)告,eNode停止異頻異系統(tǒng)測(cè)量；A2事件表示服務(wù)小區(qū)質(zhì)量低于一定門限,當(dāng)滿足事件觸發(fā)條件時(shí),UE便上報(bào)測(cè)量報(bào)告,eNode啟動(dòng)異頻異系統(tǒng)測(cè)量。A1事件的觸發(fā)條件：Ms–Hys>ThreshA2事件的觸發(fā)條件：Ms+Hys<Thresh按照A1、A2的觸發(fā)條件,我們可以計(jì)算出從鄉(xiāng)政府到府東街方向測(cè)量控制行為的伐值A(chǔ)1:MS-2>-98MS>-96dBm時(shí)停止異頻異系統(tǒng)測(cè)量A2:MS+2<-100MS<-102dBm時(shí)啟動(dòng)異頻異系統(tǒng)測(cè)量這就解釋了為什么從鄉(xiāng)政府到府東街方向異常切換的原因是A1、A2參數(shù)設(shè)置不合理導(dǎo)致。網(wǎng)絡(luò)優(yōu)化本身就是個(gè)性化和精細(xì)化的工作,A1、A2參數(shù)的設(shè)置并沒有死板的規(guī)定,在很多特殊或者精細(xì)化場(chǎng)景A1=--98,A2=-100并沒有什么錯(cuò)誤,但對(duì)于鄉(xiāng)政府--府東街這個(gè)方向這樣的參數(shù)設(shè)置顯然是不合理的,顯然當(dāng)時(shí)配置參數(shù)的工程師僅僅從一個(gè)方面考慮問題,沒有全面考慮參數(shù)配置對(duì)網(wǎng)絡(luò)的影響。對(duì)該問題的分析討論不僅僅是為了解決一個(gè)簡單的異常切換問題,重點(diǎn)是討論分析不同場(chǎng)景的切換策略。我們可以通過分析鄉(xiāng)政府周邊站點(diǎn)的情況來看當(dāng)時(shí)配置A1、A2參數(shù)的原因：專題地圖中基站中心不同顏色的圓點(diǎn)代表的頻率信息,扇區(qū)顏色代表模三信息。紅色為D頻段37900,綠色代表F頻段38350,從專題地圖中可以明顯看出F頻段的鄉(xiāng)鎮(zhèn)局周邊被D頻段的站點(diǎn)所包夾。如果按照正常場(chǎng)景或者正常優(yōu)化思路,這種場(chǎng)景為了規(guī)避數(shù)量較多的D頻段基站的模三干擾A1=-98dBm,A2=-100dBm的參數(shù)配置可以使終端在業(yè)務(wù)態(tài)時(shí)盡量占用無線環(huán)境較為純凈的F頻段的信號(hào)。但是這樣的參數(shù)設(shè)置沒有考慮到鄉(xiāng)政府-府東街一線由于特殊的無線環(huán)境,這兩個(gè)基站1扇區(qū)的信號(hào)都被限制在基站所在的道路上,那同時(shí)外邊的信號(hào)也基本不能覆蓋到該區(qū)域,我們可以通過這條道路的SINR值來印證。參數(shù)修改前鄉(xiāng)鎮(zhèn)局1小區(qū)與府東街1小區(qū)的切換點(diǎn)參數(shù)修改前鄉(xiāng)鎮(zhèn)局1小區(qū)與府東街1小區(qū)的切換點(diǎn)從SINR圖示我們可以看到在這條無線環(huán)境相對(duì)比較封閉的道路上無論占用F頻段的鄉(xiāng)政府-1小區(qū)還是D頻段的府東街-1小區(qū),SINR都非常好,絕大多數(shù)采樣點(diǎn)SINR值都在15-40范圍內(nèi),即便是少數(shù)幾個(gè)不好的采樣點(diǎn)SINR值也在9-15之間,這已經(jīng)是很好的無線環(huán)境,在這種無線環(huán)境中讓終端占用F頻段的基站并沒有明顯的益處,反而會(huì)拉低這個(gè)小范圍的下載速率,導(dǎo)致基站利用率降低。由于TD-LTE和TD-SCDMA都是時(shí)分雙工系統(tǒng),為了最大限度的降低兩個(gè)系統(tǒng)的上行干擾必須拉起這兩個(gè)系統(tǒng)的特殊時(shí)隙,也就是要保證TD-SCDMA和TD-LTE在特殊時(shí)隙上同發(fā)同收,否則會(huì)因雜散或者互調(diào)問題導(dǎo)致下行強(qiáng)干擾信號(hào)影響上行。基于以上原因F頻段基站的特殊子幀的配比必須是3：9：2,按照LTE協(xié)議規(guī)定,當(dāng)DwPTS符號(hào)配比>=9時(shí),才允許傳送業(yè)務(wù)數(shù)據(jù),F頻段的基站DwPTS配比為3的時(shí)候不符合可以傳送業(yè)務(wù)數(shù)據(jù)的條件,因此在F頻段的基站特殊子幀不能傳送業(yè)務(wù)數(shù)據(jù)。D頻段站點(diǎn)因?yàn)椴簧婕芭c其他網(wǎng)絡(luò)的雜散或者互調(diào)干擾問題,特殊子幀的符號(hào)配比可以在協(xié)議規(guī)定范圍靈活選擇,當(dāng)前網(wǎng)絡(luò)D頻段的特殊子幀的符號(hào)配比為10：2：2,按照這種符號(hào)配比,D頻段基站的特殊子幀的下行導(dǎo)頻時(shí)隙可以傳送業(yè)務(wù)數(shù)據(jù)。根據(jù)以上分析我們可以得出結(jié)論,在SINR值相當(dāng)?shù)那闆r下D頻段基站的下載速率大于F頻段的基站。我們可以通過A1、A2參數(shù)修改前后的路測(cè)結(jié)果驗(yàn)證以上結(jié)論。參數(shù)修改前的下載速率渲染圖參數(shù)修改后的下載速率渲染圖從下載速率我們可以看到,修改參數(shù)后在鄉(xiāng)政府到府東街路段下載速率得到明顯改善。解決措施： 修改鄉(xiāng)政府1小區(qū)A1事件參數(shù),原參數(shù)設(shè)置A1=-98的Bm,修改為-86dBm修改鄉(xiāng)政府1小區(qū)A2事件參數(shù),原參數(shù)設(shè)置A2=-100的Bm,修改為-88dBm修改鄉(xiāng)政府1小區(qū)A3事件參數(shù),對(duì)于鄉(xiāng)政府-1的鄰區(qū)府東街-1,小區(qū)個(gè)性偏移原值為0,修改后的值為5。修改的目的：讓終端更快的切到下載速率更好的D頻段。接入類問題2.1MCC設(shè)置錯(cuò)誤導(dǎo)致E-RAB建立成功率為0問題描述：在分析TOP小區(qū)時(shí),發(fā)現(xiàn)HD堤村1小區(qū)無線接通率為0,其中RRC連接成功率為100%,E-RAB建立次數(shù)及成功率均為0,與前面RRC連接次數(shù)極不對(duì)稱,統(tǒng)計(jì)指標(biāo)如下圖所示：問題分析：首先通過CDL對(duì)本基站1小區(qū)的E-RAB建立進(jìn)行分析,從信令流程上具體定位問題發(fā)現(xiàn)在哪個(gè)環(huán)節(jié)；根據(jù)CDL信令流程或提示再核查基站的告警狀態(tài)、是否故障或者開站數(shù)據(jù)是否有誤〔如SCTP鏈路、VLAN、路由、基站ID、MCC、MNC、TAC等；問題排查：分析基站CDL日志方法步驟：通過分析本基站1小區(qū)的CDL日志,發(fā)現(xiàn)在本小區(qū)下,有終端一直進(jìn)行RRC連接,但連接完成后直接釋放,即不進(jìn)行E-RAB建立,信令流程圖如下：核查基站的開站基礎(chǔ)數(shù)據(jù)方法步驟：通過信令得知UE不進(jìn)行E-RAB建立,首先需要核查本小區(qū)是否存在故障或者告警,通過核查后無這方面的因素；同時(shí)分析所得因?yàn)閁E不進(jìn)行E-RAB建立,應(yīng)該把參數(shù)核查重點(diǎn)放在跟核心網(wǎng)有關(guān)的參數(shù)上面,因此通過檢查基站的參數(shù)發(fā)現(xiàn)本基站1小區(qū)的MCC設(shè)置為640,如下圖所示：正確設(shè)置應(yīng)該為MCC為460。處理過程：將本基站1小區(qū)的MCC由640更改為460。處理效果將MCC更改正確后的本小區(qū)指標(biāo)正常,如下圖：延伸1、當(dāng)一個(gè)小區(qū)RRC連接成功率很高,但E-RAB建立成功比較低,一般可確認(rèn)空口不存在問題,此時(shí)一般可以從開站數(shù)據(jù)核查開始,即主要涉及UE接入核心的參數(shù)進(jìn)行核查,諸如MCC、MNC、TAC等；2、在督導(dǎo)開站過程中一定要注意基站基礎(chǔ)數(shù)據(jù)的配置是否正確,否則一個(gè)小小的失誤將會(huì)造成基本的指標(biāo)直線下降。2.2核心網(wǎng)問題導(dǎo)致REAB建立失敗問題描述：XX在海峽會(huì)展保障期間出現(xiàn)大量ERAB建立失敗,18:00~19:00,E-RAB失敗2100次,嚴(yán)重影響全網(wǎng)指標(biāo),造成用戶感知較差。問題分析：查看CDL：核心網(wǎng)在發(fā)起S1InitialContextSetupRequest,之后AP側(cè)上報(bào)兩次AP_PER_ERROR,基站直接回復(fù)S1InitialContextSetupFailure,失敗原因?yàn)閟emantic-error定位過程：經(jīng)過查看核心網(wǎng)發(fā)出的上下文建立請(qǐng)求消息中,發(fā)現(xiàn)AMBR攜帶的值為0,根據(jù)協(xié)議,eNB判斷此消息非法,會(huì)導(dǎo)致上下文建立失敗,影響上下文建立和承載建立的KPI。現(xiàn)場(chǎng)和諾西的核心網(wǎng)廠家確認(rèn),此問題為諾西EPC的已知BUG。具體協(xié)議如下：0UEAggregateMaximumBitRateTheUEAggregateMaximumBitrateisapplicableforallNon-GBRbearersperUEwhichisdefinedfortheDownlinkandtheUplinkdirectionandprovidedbytheMMEtotheeNB.IE/GroupNamePresenceRangeIEtypeandreferenceSemanticsdescriptionUEAggregateMaximumBitRateApplicablefornon-GBRE-RABs.>UEAggregateMaximumBitRateDownlinkMThisIEindicatestheUEAggregateMaximumBitRateasspecifiedinTS23.401[11]inthedownlinkdirection.>UEAggregateMaximumBitRateUplinkMThisIEindicatestheUEAggregateMaximumBitRateasspecifiedinTS23.401[11]intheuplinkdirection.ReceivingboththeUEAggregateMaximumBitRateDownlinkIEandtheUEAggregateMaximumBitRateUplinkIEequaltovaluezeroshallbeconsideredasalogicalerrorbytheeNB.定位結(jié)果：現(xiàn)場(chǎng)將此問題呈現(xiàn)給諾西廠家,希望能盡早解決此BUG。KPI指標(biāo)目標(biāo)目前已恢復(fù)正常。2.3LTE多模終端自由選擇網(wǎng)絡(luò)不能接入LTE網(wǎng)絡(luò)問題分析問題描述：IPHONE5S和L1終端在自由選擇網(wǎng)絡(luò)模式下,無法駐留在任何網(wǎng)絡(luò)。在手機(jī)上看,是手機(jī)顯示LTE網(wǎng)絡(luò),或者2G/3G網(wǎng)絡(luò),但是不能進(jìn)行任何業(yè)務(wù),打和上網(wǎng)。而且信號(hào)格顯示是空的,即沒有信號(hào)。而IPHONE5S和L1終端終端在華為的站點(diǎn)下,是可以正常駐留并進(jìn)行CSFB業(yè)務(wù)的。L1終端選擇僅LTE模式下,可以正常接入LTE網(wǎng)絡(luò),并且進(jìn)行數(shù)據(jù)業(yè)務(wù)。使用HISIE5776測(cè)試此站點(diǎn),無任何功能性問題,可以接入,業(yè)務(wù)正常。將IPHONE5S在問題站點(diǎn)下重新開關(guān)機(jī),提取基站CDL日志,從CDL日志的信令流程來看,信令走到了SecurityModeCommand就釋放了,見下圖：圖1-1IPHONE5S開機(jī)CDL信令流程點(diǎn)開SecurityModeCommand,里面的詳細(xì)內(nèi)容見下圖：圖1-2SecurityModeCommand消息內(nèi)容問題分析：1、一般接入問題需要檢查站點(diǎn)配置文件中的接入?yún)?shù)、TAC、IP地址和路由關(guān)系等參數(shù)設(shè)置。本案例中,使用L1和E5776可以正常接入網(wǎng)絡(luò)并且進(jìn)行數(shù)據(jù)業(yè)務(wù),說明基站側(cè)接入?yún)?shù)、TAC、IP地址和路由關(guān)系都沒有問題。2、商用終端的完整性保護(hù)算法不能為空算法,這在早期的網(wǎng)絡(luò)優(yōu)化過程中也遇到一些商用終端不能接入LTE網(wǎng)絡(luò)的問題,后來都是通過修改完整性保護(hù)算法優(yōu)先級(jí)來解決。3、對(duì)于有CSFB功能的LTE終端來說,聯(lián)合附著不成功,會(huì)導(dǎo)致終端不能駐留在LTE網(wǎng)絡(luò)。典型的CSFB業(yè)務(wù)流程主要包括聯(lián)合附著、位置更新、主叫<MO>CSFB流程、被叫<MT>CSFB流程以及去附著等。啟用CSFB功能的用戶的附著流程是基于聯(lián)合GPRS/IMSI附著流程來實(shí)現(xiàn)的。問題處理流程：由于CDL日志里面,完整性保護(hù)算法為eia0,即為空算法,導(dǎo)致終端不能接入。因此需要檢查基站側(cè)的完整性保護(hù)算法參數(shù)。檢查基站的完整性保護(hù)算法參數(shù),空算法的優(yōu)先級(jí)為0,高優(yōu)先級(jí)的完整性保護(hù)算法都不是空算法,參數(shù)配置沒有任何問題,見下圖：圖1-3配置文件完整性保護(hù)算法參數(shù)由于基站側(cè)完整性保護(hù)算法參數(shù)沒有任何問題,而CDL日志里面,完整性保護(hù)算法為空算法,因此懷疑是核心網(wǎng)側(cè)問題,聯(lián)系核心網(wǎng)側(cè)人員,核心網(wǎng)側(cè)人員答復(fù)TAC與LAC對(duì)應(yīng)關(guān)系出現(xiàn)問題,導(dǎo)致聯(lián)合附著失敗。處理過程：華為核心網(wǎng)側(cè)人員將TAC與LAC對(duì)應(yīng)關(guān)系做了之后,IPHONE5S、5C以及L1在自由選擇網(wǎng)絡(luò)模式下,都可以駐留在LTE網(wǎng)絡(luò)上。聯(lián)合附著流程：TD-LTE/TD-SCDMA/GSM<GPRS>多模單待手持終端在給MME發(fā)送的附著請(qǐng)求消息中攜帶支持CSFB能力的指示。MME在收到用戶的聯(lián)合附著請(qǐng)求后,在進(jìn)行EPS附著的同時(shí),會(huì)推導(dǎo)出其相關(guān)CS域的VLR信息,并向這個(gè)VLR發(fā)起位置更新請(qǐng)求,VLR收到位置更新請(qǐng)求以后,會(huì)將該用戶標(biāo)記為已經(jīng)進(jìn)行EPS附著了,并保存用戶的MME的IP地址,這樣,VLR中就創(chuàng)建了用戶的VLR與MME間的SGs關(guān)聯(lián)。隨后,MSCServer/VLR會(huì)進(jìn)行CS域位置更新并把用戶的TMSI和LAI<位置區(qū)標(biāo)識(shí)>傳給MME,從而在MME中建立SGs關(guān)聯(lián)。最后,MME把VLR給用戶分配的TMSI以及LAI等信息包含在附著請(qǐng)求接受消息中發(fā)送給UE,此時(shí)就表明用戶的聯(lián)合附著已經(jīng)成功了。因此,具有CSFB功能的LTE終端自由模式開機(jī)正常流程：優(yōu)先駐留在LTE,即終端開機(jī)—>LTE及2G/3G電路域聯(lián)合注冊(cè)〔確保用戶同時(shí)注冊(cè)在EPS和GSM電路域網(wǎng)絡(luò)—>駐留LTE,見圖1-4：圖1-4聯(lián)合附著示意圖2.4默認(rèn)網(wǎng)關(guān)配置錯(cuò)誤問題描述：20XX4月23日車輛在江北環(huán)城北路行駛至NB清純服飾FHTL附近時(shí),發(fā)現(xiàn)UE無論是S1、X2均無法從其他站切換至本站進(jìn)行業(yè)務(wù)測(cè)試,UE顯示"無服務(wù)"現(xiàn)象,處于脫網(wǎng)狀態(tài)。待車輛行駛至附近其他基站覆蓋區(qū)域時(shí),UE重新建立鏈接,業(yè)務(wù)測(cè)試正常。如下圖：問題分析：如上圖可見,在NB清純服飾FHTL-0、-1主覆蓋區(qū)域RSRP、SINR指標(biāo)良好〔RSRP-75,SINR7,排除無線環(huán)境惡劣導(dǎo)致。查看基站側(cè)發(fā)射功率、鄰區(qū)關(guān)系、接入?yún)?shù)、切換參數(shù)等均無異常,基站運(yùn)行狀態(tài)良好,無告警。查看CDL日志發(fā)現(xiàn),UE也無法從此站接入,UE接入時(shí)提示lintialContextsetupFailure〔CAUSETYPEtransport_chosen,如下：查看路由表發(fā)現(xiàn)路由表中默認(rèn)網(wǎng)關(guān)配置錯(cuò)誤,實(shí)際網(wǎng)關(guān)應(yīng)為29,誤配置為92。解決措施：修改路由表中默認(rèn)網(wǎng)關(guān)為29。處理效果修改后復(fù)測(cè),發(fā)現(xiàn)站點(diǎn)NB清純服飾FHTL接入正常,切換正常,數(shù)據(jù)下載業(yè)務(wù)良好。如下:附件或日志：2.5核心網(wǎng)算法問題問題描述：海思E5776終端ATTACH不成功。無法做業(yè)務(wù)。問題分析：1、原因?yàn)榫W(wǎng)絡(luò)側(cè)下發(fā)NAS層消息指示終端使用EIA0算法,而海思E5776終端拒絕。無線側(cè)信令如下圖所示。S1接口抓包信令如下：經(jīng)核查發(fā)現(xiàn)MME在SACKid-downlinkNASTransport,Securitymodecommand中下發(fā)的integrityprotectionalgorithm為EIA0<nullintegrityprotectionalgorithm><0>。海思終端回復(fù)了SACKid-uplinkNASTransport,Securitymodereject。Securitymodereject消息的詳細(xì)信息中含有PlainNASmessage,notsecurityprotected<0>,表明未啟用安全保護(hù)。SACKid-downlinkNASTransport,Attachreject。2、經(jīng)由排查發(fā)現(xiàn)協(xié)議規(guī)定,空算法一般用于緊急呼叫,普通的業(yè)務(wù)應(yīng)該使用snow3g和aes算法,當(dāng)前諾西核心網(wǎng)的設(shè)置為空完整性算法,所以了海思E5776終端拒絕。具體協(xié)議規(guī)定如下圖所示：解決措施：將諾西MME修改IntegrityAlgorithm為AES,修改后參數(shù)后的信令如下：在Securitymodecommand消息中,integrityprotectionalgorithm已經(jīng)改為EPSintegrityalgorithm128-EIA2<2>：在Securitymodecomplete消息中,integrity方式已變?yōu)閜rotected。在后續(xù)的流程中,完成附著。經(jīng)驗(yàn)總結(jié)：正常的附著流程如下圖所示：MME會(huì)通過NASSecurityModeCommand消息將完整性算法傳送給UE。UE根據(jù)NASSecurityModeCommand中選中的算法計(jì)算相應(yīng)的密鑰,用于對(duì)空口上傳輸?shù)男帕钌w一個(gè)完整性保護(hù)戳,幫助接收端確認(rèn)收到信令消息的合法性。完整性保護(hù)算法是必選的。因協(xié)議規(guī)定,空算法只能用于緊急呼叫,故MME要下發(fā)的完整性算法應(yīng)該是AES或SNOW3G,而不要下發(fā)空完整性算法。2.6信令面流程正常業(yè)務(wù)面無法上網(wǎng)案例問題描述：2月3日與聯(lián)誼賓館進(jìn)行測(cè)試,信令面走到RRC重配置、RRC重配置完成、AttachComplete流程。但是業(yè)務(wù)面無速率。問題分析：在聯(lián)誼賓館站下進(jìn)行附著接入過程,信令面走到RRCConnectionReconfiguration、RRCConnectionReconfigurationComplete、Attach附著完成流程。但是業(yè)務(wù)面存在問題,無法上網(wǎng)。檢查基站配置文件,發(fā)現(xiàn)路由關(guān)系中網(wǎng)關(guān)IP地址配置錯(cuò)誤,應(yīng)該配置為100：67：0：193。實(shí)際配置為100：67：0：27。解決措施：將聯(lián)誼賓館路由關(guān)系修改成100：67：0：193處理效果修改后,業(yè)務(wù)面正常,上網(wǎng)正常,FTP下載速率穩(wěn)定在41M〔單通道。2.7三星NOTE23信號(hào)標(biāo)識(shí)不顯示問題分析案例問題描述：用戶反饋三星NOTE2/3一定概率出現(xiàn)不顯示數(shù)據(jù)業(yè)務(wù)信號(hào)格的情況。此時(shí)語音業(yè)務(wù)正常,數(shù)據(jù)業(yè)務(wù)中斷。問題分析：1問題現(xiàn)象：對(duì)比NOTE2和NOTE3出現(xiàn)該問題時(shí)的現(xiàn)象和信令圖,發(fā)現(xiàn)終端從23G模式切換到234G模式后,大約有12S左右無法使用數(shù)據(jù)業(yè)務(wù),終端上的4G信號(hào)格不顯示4G標(biāo)識(shí)。見圖1：NOTE2異常的事件見圖2：NOTE2異常的異常信令2協(xié)議過程分析：從終端側(cè)看信令：終端在LTE側(cè)進(jìn)行了RRC請(qǐng)求、建立、完成后,未收到下行傳送消息。此時(shí)終端上信號(hào)格顯示的形狀也略有不同,NOTE2顯示為一個(gè)信號(hào)格,NOTE3顯示為兩個(gè)信號(hào)格,左邊為34G模塊,只有信號(hào)格無信號(hào)標(biāo)識(shí),右邊為GSM模塊,可正常顯示信號(hào)標(biāo)識(shí)。由于核心網(wǎng)有時(shí)會(huì)在15s左右響應(yīng)NAS層SecurityCommandrequest消息,大唐的RRC連接釋放定時(shí)器設(shè)置為10s,所以這時(shí)候終端被異常釋放,在4G上未注冊(cè)成功,從終端表現(xiàn)來看4G信號(hào)格不顯示4G。圖1：NOTE2出現(xiàn)該事件時(shí)的表現(xiàn)：圖2：NOTE2出現(xiàn)該事件時(shí)的表現(xiàn)〔圖中出現(xiàn)了一次TAU拒絕,該問題為已知問題承載未建立：對(duì)比正常時(shí)與出現(xiàn)該異常事件時(shí)的信令表現(xiàn),出現(xiàn)異常事件時(shí),終端發(fā)送的ATTACHREQUEST長時(shí)間未得到網(wǎng)絡(luò)側(cè)的相應(yīng)。從基站側(cè)看：基站向核心網(wǎng)發(fā)送了S1直傳消息,正常EPC應(yīng)該下發(fā)S1上下文建立請(qǐng)求給基站,但基站在長時(shí)間未收到該消息,釋放了空口RRC。異常：正常：聯(lián)系核心網(wǎng)人員,確認(rèn)該問題由于有鏈路走的CMNET而不是走IP承載,導(dǎo)致出現(xiàn)幾率性丟包情況。核心網(wǎng)提供的信令截圖,可以看到從收到終端附著請(qǐng)求到MME去HSS取鑒權(quán)集就用了15S,正常只要不到1S。解決措施：針對(duì)此問題,核心網(wǎng)已經(jīng)將出現(xiàn)該事件時(shí)的定時(shí)器由15S改為6S〔見附圖6,由于小于大唐的RRC連接釋放定時(shí)器,這時(shí)用戶不會(huì)被釋放,可縮短用戶終端上顯示只有信號(hào)格的時(shí)間。MME取鑒權(quán)超時(shí)計(jì)數(shù)器修改后驗(yàn)證,7秒終端可收到下行消息。速率類問題3.1下行子幀調(diào)度不滿導(dǎo)致平均下載速率低問題分析問題描述：在對(duì)晉寧移動(dòng)LTE網(wǎng)絡(luò)示范區(qū)使用鼎力ATU設(shè)備進(jìn)行拉網(wǎng)時(shí),發(fā)現(xiàn)平均速率比較低,拉網(wǎng)結(jié)果與華為區(qū)域?qū)Ρ热缦卤恚河杀碇袛?shù)據(jù)可知,我司設(shè)備在無線條件均比華為區(qū)域好的情況下,FTP下載速率與華為區(qū)域相差較大,另外一項(xiàng)比較差的指標(biāo)為DL平均每秒調(diào)度PRB個(gè)數(shù),與華為相差13000多個(gè)PRB,懷疑此為導(dǎo)致速率低的主要原因。問題分析：FTP下載速率問題分析方法：首先進(jìn)行無線環(huán)境、小區(qū)無線參數(shù)、基站告警和傳輸限制等常規(guī)檢查,在排除這些原因之后,根據(jù)速率優(yōu)化的特點(diǎn),從以下三方面入手排查速率問題：1CQI與MCS：MCS等級(jí)決定了下載速率大小,遇到速率不高的問題,可先檢查統(tǒng)計(jì)結(jié)果中平均MCS等級(jí),若發(fā)現(xiàn)MCS等級(jí)不高需檢查上報(bào)的CQI的信道值。CQI主要通過SINR映射,UE上報(bào)CQI,基站通過一定策略計(jì)算后決定了下行調(diào)度的MCS。2MIMO模式：目前外場(chǎng)一般使用TM3和TM7兩種模式切換,而我司設(shè)備參數(shù)值設(shè)置是保證雙流在TM3上,單流在TM7上。通過統(tǒng)計(jì)結(jié)果查看雙流占比是否合適,如果雙流占比不高,則需對(duì)轉(zhuǎn)換參數(shù)進(jìn)行優(yōu)化。3PRB調(diào)度是否飽滿：PRB調(diào)度是否飽滿直接影響速率,通過測(cè)試數(shù)據(jù)統(tǒng)計(jì)的結(jié)果可以看到PRB調(diào)度相關(guān)的統(tǒng)計(jì)值。PRB調(diào)度不滿可能的原因?yàn)榫W(wǎng)絡(luò)資源或傳輸不夠?qū)е?、系統(tǒng)不用使用那么多PRB就可以傳輸數(shù)據(jù)現(xiàn)有的數(shù)據(jù)。DL平均每秒調(diào)度PRB個(gè)數(shù)如果不滿,可能的原因有PRB調(diào)度個(gè)數(shù)/slot不滿,測(cè)量GAP開啟,切換過多導(dǎo)致。問題處理流程：查看無線環(huán)境是否良好,從測(cè)試指標(biāo)上看,我們的平均和邊緣RSRP和SINR均優(yōu)于華為區(qū)域,因此排除無線環(huán)境方面的問題。核查示范區(qū)內(nèi)所有小區(qū)無線參數(shù)是否正確；方法步驟：查看示范區(qū)基站小區(qū)是否設(shè)置不當(dāng),通過查看確定上下行HARQ開關(guān)為開、上下行CQI修正開關(guān)為開、下行傳輸模樣固定開關(guān)為模式間自適應(yīng)、分配PRB限制開關(guān)為不限制、MCS等級(jí)限制開關(guān)為不限制、下行流控開關(guān)為關(guān)、下行ICIC開關(guān)為關(guān)、DRX配置有效指示為關(guān)閉,如下圖所示：通過核查鄰區(qū)關(guān)系,觀察到受限小區(qū)都配有D頻段異頻鄰區(qū),于是檢查A1、A2、GAP開關(guān)狀態(tài)是否開啟,檢查結(jié)果為A1、A2、GAP均為關(guān)閉狀態(tài),如下圖所示,另外檢查信道質(zhì)量指示參數(shù),如下圖所示：檢查參數(shù)發(fā)現(xiàn)參數(shù)都是正常的。核查基站設(shè)備是否存在告警或基站是否存在故障；通過檢查示范區(qū)域基站的告警信息,發(fā)現(xiàn)測(cè)試區(qū)域基站無重要告警信息。檢查基站傳輸是否受到限制；通過與局方傳輸人員溝通確認(rèn),晉寧示范區(qū)基站傳輸沒有限制,使用的都是千M網(wǎng)口。從示范區(qū)單站驗(yàn)證報(bào)告來看,各個(gè)小區(qū)在好點(diǎn)處CAT3終端FTP下載速率都能夠達(dá)到60M以上?，F(xiàn)場(chǎng)也抽驗(yàn)了幾個(gè)站點(diǎn),也未發(fā)現(xiàn)傳輸有問題,因此排除傳輸受限的問題。通過測(cè)試統(tǒng)計(jì)結(jié)果,檢查MCS等級(jí),平均MCS等級(jí)為19,為比較高的水平。天線模式,雙流時(shí)長占比為84.29%,所以傳輸模式也不存在問題。檢查PRB調(diào)度統(tǒng)計(jì),發(fā)現(xiàn)每時(shí)隙調(diào)度數(shù)為97.22,而每秒鐘調(diào)度PRB個(gè)數(shù)為95039個(gè),根據(jù)計(jì)算,每時(shí)隙調(diào)度97.22個(gè),那么每秒鐘應(yīng)該是：97.22*2*6*100=116664個(gè)〔*2：為每子幀；*6：為每幀下行子幀數(shù)；*100：每秒調(diào)度PRB數(shù),而實(shí)際值為95039個(gè),這種情況,只有測(cè)量GAP打開,終端進(jìn)行了異頻測(cè)量或者是切換過多導(dǎo)致。但是切換的次數(shù)總共只有38次,測(cè)試的時(shí)間有30分鐘,所以切換的影響非常小。在上下行子幀配置為1：3,特殊子幀配置為3:9:3的配置下,DL子幀滿調(diào)度數(shù)應(yīng)該為600,而我們的測(cè)試結(jié)果為469.3,比滿調(diào)度少了131次,比華為少了88次。所以推測(cè),是由于測(cè)量GAP打開導(dǎo)致子幀調(diào)度不滿。經(jīng)過和研發(fā)討論定位如下：每時(shí)隙調(diào)度滿,而每秒鐘調(diào)度不滿,即子幀調(diào)度不滿,很有可能是測(cè)量GAP打開的原因。目前產(chǎn)品實(shí)現(xiàn)上,在進(jìn)行小區(qū)切換時(shí),如果目標(biāo)小區(qū)存在異頻配置,就會(huì)默認(rèn)配置Gap；如果此時(shí)不配置A1,則GaP就一直無法關(guān)閉。如存在異頻配置,且在拉網(wǎng)測(cè)試時(shí)不想使用Gap,要么一：將各基站的異頻頻點(diǎn)和異頻鄰區(qū)都刪除〔但會(huì)影響異頻切換,與室分的切換；要么二：開啟A1/A2,按照建議值設(shè)置A1/A2,建議A1門限調(diào)整到-86dbm,A2門限調(diào)整到-90dbm,Gap索引配置為68。問題解決效果：晉寧示范區(qū)內(nèi)D頻段站點(diǎn)覆蓋過弱,無法覆蓋主干道,因此刪除異頻鄰區(qū),刪除后復(fù)測(cè),發(fā)現(xiàn)每時(shí)隙PRB調(diào)度和每秒鐘PRB調(diào)度滿?？偨Y(jié)：根據(jù)公司設(shè)備的目前版本情況下,GAP開關(guān)是無效的,不需要異頻切換的小區(qū),建議不添加異頻鄰區(qū)有配置異頻鄰區(qū)的小區(qū),建議按照研發(fā)給出的A1/A2和GAP值進(jìn)行配置。具體如下：測(cè)量GAP偏移A1門限A2門限68-86-90附：在測(cè)試軟件中如何觀察調(diào)度是否滿圖中,DCIFormat1aCount或者DCIFormat2aCount值表示5ms調(diào)度次數(shù),以上下行子幀配比為2:2,特殊子幀配比為10:2:2為例,其5ms調(diào)度PRB應(yīng)為：3*100=300,因?yàn)橛?個(gè)下行子幀,頻域上100個(gè)PRB,但調(diào)度時(shí),是以PRB對(duì)為單位的,因?yàn)門TI為1ms。所以300為PRB滿調(diào)度數(shù)目。圖中PDCCHDLGrantCount為每秒鐘子幀調(diào)度次數(shù),每10ms有6個(gè)下行子幀,所以1s鐘就有6*100次子幀調(diào)度,因此,這個(gè)計(jì)數(shù)器的滿調(diào)度在配置為2:2,10:2:2下,應(yīng)該為600。3.2傳輸受限引起的速率問題問題描述：日常單站業(yè)務(wù)驗(yàn)證期間,發(fā)現(xiàn)化工一廠南,下載速率達(dá)不到優(yōu)化標(biāo)準(zhǔn),環(huán)境在SINR=28RSRP=-85COI=14的情況下,下載速率在40M左右,基本沒有什么變,圖如下：問題分析：分析思路：a>參數(shù)配置異常。b>基站是否存在異常告警。b>光模塊的大小。d>是否是傳輸?shù)膯栴}。分析：a>請(qǐng)機(jī)房核查,確認(rèn)一下基本的優(yōu)化參數(shù),參數(shù)正常。b>詳細(xì)查看基站告警,未發(fā)現(xiàn)異常。c>上站查詢傳輸光模塊是6G,正常。d>請(qǐng)機(jī)房幫忙灌包,開始是先灌60M的包,我在這端通過DUMeter查看和原來下載的速率一樣,穩(wěn)定在40M左右,然后有開始灌30M的包,我在這端通過DUMeter查看和原來下載的速率一樣,穩(wěn)定在30M左右,接著灌40M的包,我在這端通過DUMeter查看和原來下載的速率一樣,穩(wěn)定在40M左右,最后灌45M的包,我在這端通過DUMeter查看和原來下載的速率一樣,仍然穩(wěn)定在40M左右。解決措施：通過和傳輸人員溝通,修改傳輸帶寬,業(yè)務(wù)正常。3.3CFI相關(guān)設(shè)置影響LTE拉網(wǎng)速率分析問題描述：在祿勸縣城網(wǎng)格拉網(wǎng)中,ATU測(cè)試速率太低。經(jīng)過分析發(fā)現(xiàn),很多路段,下載速率僅為10M左右。導(dǎo)致此次拉網(wǎng)平均速率不高,平均速率僅為20M。更換華為5776MIFI拉網(wǎng),速率僅為22M,此次拉網(wǎng)測(cè)試存在多處如下問題路段。路測(cè)數(shù)據(jù)分析,該區(qū)域?qū)儆诟采w良好區(qū)域,運(yùn)政大樓3小區(qū)RSRP在-75dBm以上,SINR在17以上,但下載速率僅為6M左右。問題分析：1,查詢低速率路段覆蓋站點(diǎn)是否存在故障,低速率路段處誤碼率高不高。經(jīng)查詢站點(diǎn)無故障,低速率路段誤碼率不高。2,由于ATU拉網(wǎng)測(cè)試無法看到實(shí)時(shí)調(diào)度情況,統(tǒng)計(jì)此次拉網(wǎng)本次測(cè)試本次測(cè)試每秒調(diào)度PRB個(gè)數(shù)87616.5703,下行子幀調(diào)度率392。懷疑當(dāng)時(shí)服務(wù)器出問題,或是測(cè)試設(shè)備異常。通過復(fù)測(cè)定位問題。更換測(cè)試設(shè)備拉網(wǎng)測(cè)試,分析是否為設(shè)備問題,此次定位更換為華為5776MIFI；使用30線程拉網(wǎng),分析是否為服務(wù)器問題。3,使用華為5776拉網(wǎng),拉網(wǎng)過程中查看實(shí)時(shí)調(diào)度情況,發(fā)現(xiàn)ATU測(cè)試低速率路段,使用MIFI測(cè)試速率仍然在10M以下,排除設(shè)備問題。而拉網(wǎng)過程中仍然有高速率路段,調(diào)度600,說明服務(wù)器沒有問題。本次測(cè)試中仍然存在如下低速率路段,測(cè)試發(fā)現(xiàn)在這些路段主服務(wù)小區(qū)下,調(diào)度太少均在100多。如下運(yùn)政大樓3小區(qū)覆蓋路段和錦繡家園1小區(qū)覆蓋路段：4,小區(qū)下定點(diǎn)測(cè)試,復(fù)位站點(diǎn),發(fā)現(xiàn)復(fù)位起來后一段時(shí)間內(nèi)下載正常,但是1小時(shí)以后再查看,發(fā)現(xiàn)問題復(fù)現(xiàn)。5,查看這些小區(qū)下用戶數(shù),發(fā)現(xiàn)均存在較多用戶,選取一個(gè)用戶數(shù)較少的小區(qū)進(jìn)行定點(diǎn)測(cè)試,選擇彝城新都燈桿1小區(qū),該小區(qū)下存在1-2個(gè)用戶。測(cè)試速率仍然不理想。懷疑此時(shí)為多用戶同時(shí)下載導(dǎo)致調(diào)度低,速率低。選擇凌晨1點(diǎn)對(duì)該小區(qū)進(jìn)行測(cè)試發(fā)現(xiàn)調(diào)度問題仍無改善,調(diào)度僅為100多,速率仍然在10M左右。6,懷疑多用戶引起調(diào)度不足問題,查看調(diào)度相關(guān)參數(shù)。此時(shí)的設(shè)置時(shí)：專用搜索空間聚合等級(jí)為8CCE,上下行都發(fā)PDSCH控制符號(hào)數(shù)為2,下行發(fā)PDCCH時(shí)域控制符號(hào)數(shù)為1。嘗試修改上下行都發(fā)PDSCH控制符號(hào)數(shù)配置為3,下行發(fā)PDCCH時(shí)域控制符號(hào)數(shù)為2時(shí),調(diào)度和速率正常。解決措施：從上述分析,得知本次低速率問題是由于：專用搜索空間聚合等級(jí)為8CCE,上下行都發(fā)PDSCH控制符號(hào)數(shù)為2,下行發(fā)PDCCH時(shí)域控制符號(hào)數(shù)為1。按照目前cce為8的設(shè)置,單個(gè)子幀上下行同時(shí)調(diào)度,只能調(diào)度1個(gè)用戶。除非能夠保證小區(qū)內(nèi)就一個(gè)用戶在做業(yè)務(wù)。否則速度很低。從上述驗(yàn)證情況看：專用搜索空間聚合等級(jí)配置為8CCE,上下行都發(fā)PDSCH控制符號(hào)數(shù)配置為3,下行發(fā)PDCCH時(shí)域控制符號(hào)數(shù)為2時(shí),調(diào)度能接近600滿調(diào)度,下載速率正常;將全網(wǎng)改為：專用搜索空間聚合等級(jí)配置為8CCE,上下行都發(fā)PDSCH控制符號(hào)數(shù)配置為3,下行發(fā)PDCCH時(shí)域控制符號(hào)數(shù)為2。處理效果測(cè)試中低速率路段,調(diào)度低問題解決,下載速率提升明顯。5線程MIFI拉網(wǎng)速率為32M。運(yùn)政大樓3小區(qū)拉網(wǎng)測(cè)試速率改善：錦繡家園1小區(qū)拉網(wǎng)測(cè)試速率改善：CSFB類問題4.1UE未收到Release消息重選到TDS問題描述：XX市蓮都區(qū)移動(dòng)公司,通過兩部iPhone5s互撥發(fā)現(xiàn)主,被叫均出現(xiàn)概率性回落到3G的情況。通過鼎力軟件分析發(fā)現(xiàn)終端在發(fā)起Extendedservicerequest后沒有收到rrcconnectionrelease消息,之后重選到3G。下圖所示為主叫收到rrcconnectionrelease消息重選到3G。問題分析：提取該時(shí)段CDL日志發(fā)現(xiàn)基站側(cè)向UE發(fā)起rrcconnectionrelease消息〔攜帶了G網(wǎng)頻點(diǎn)信息。如下圖所示：查看小區(qū)狀態(tài)均正常,無上行干擾,通過去激活激活小區(qū)操作無效；通過與正常站點(diǎn)的參數(shù)核查對(duì)比,最后發(fā)現(xiàn)LTE服務(wù)小區(qū)D780401蓮都移動(dòng)大樓分布E-2〔PCI：1的DRX功能開啟指示為"打開",而DRX配置信息中DRX配置有效指示為"關(guān)閉"。對(duì)比D780401蓮都移動(dòng)大樓分布E-1小區(qū),DRX功能開啟指示為"打開",DRX配置信息中DRX配置有效指示為"打開"；將D780401蓮都移動(dòng)大樓分布E-2小區(qū)修改DRX參數(shù)配置信息與D780401蓮都移動(dòng)大樓分布E-1小區(qū)相同,主要修改DRX配置有效指示為：開啟、激活定時(shí)器時(shí)長：6調(diào)整為8、非激活定時(shí)器時(shí)長10調(diào)整為60、重傳定時(shí)器時(shí)長：8調(diào)整為4、長DRX周期調(diào)整為160,CSFB就不再回落到3G。服務(wù)小區(qū)修改DRX參數(shù)基站配置信息前,如下圖