TD-LTE網絡優(yōu)化案例匯總

《TD-LTE網絡優(yōu)化案例匯總》由會員分享，可在線閱讀，更多相關《TD-LTE網絡優(yōu)化案例匯總（68頁珍藏版）》請在裝配圖網上搜索。

1、 TD-LTE網絡優(yōu)化案例匯總 項目名稱 文檔編號 版 本 號 部 門 專業(yè)服務業(yè)務部 作 者 版權所有 大唐移動通信設備有限公司 本資料及其包含的所有內容為大唐移動通信設備有限公司(大唐移動)所有,受中國法律及適用之國際公約中有關著作權法律的保護。未經大唐移動書面授權，任何人不得以任何形式復制、傳播、散布、改動或以其它方式使用本資料的部分或全部內容，違者將被依法追究責任。 目 錄 1. 切換類問題 2 1.1鄰基站信息未

2、配置成功 2 1.2 X2口不通導致的切換失敗 4 1.3硬件和傳輸故障 6 1.4隨機接入參數(shù)配置不當引起切換失敗 7 1.5重選優(yōu)先級設置不一致導致異頻無法切換 11 1.6 MME問題導致入POOL基站大量切換失敗 12 1.7開站數(shù)據(jù)模板不對引起切換失敗 17 1.8傳輸端口環(huán)回問題導致S1切換成功率低 21 1.9府東街-3小區(qū)異常切換(A1/A2異頻切換) 24 2. 接入類問題 30 2.1MCC設置錯誤導致E-RAB建立成功率為0 30 2.2核心網問題導致REAB建立失敗 31 2.3LTE多模終端自由選擇網絡不能接入LTE網絡問題分析 34 2.4

3、默認網關配置錯誤 37 2.5核心網算法問題 39 2.6信令面流程正常業(yè)務面無法上網案例 42 2.7三星NOTE23信號標識不顯示問題分析案例 43 3. 速率類問題 48 3.1下行子幀調度不滿導致平均下載速率低問題分析 48 3.2傳輸受限引起的速率問題 51 3.3CFI相關設置影響LTE拉網速率分析 52 4. CSFB類問題 59 4.1UE未收到Release消息重選到TDS 59 4.2網絡側不下發(fā)Release消息 61 4.3MME配置TA與LA映射錯誤導致開機聯(lián)合注冊失敗 63 4.4并發(fā)業(yè)務導致CSFB失敗 64 1. 切換類問題 1.

4、1鄰基站信息未配置成功 問題描述： 測試發(fā)現(xiàn)NBHS維科上院FHTL-1 PCI=487與NBHS青林灣西FHTL-0 PCI=438之間切換失敗。 從前臺測試LOG可以看出，18:10:8.533占用NBHS維科上院FHTL-1 PCI=487上報MR，目標小區(qū)NBHS青林灣西FHTL-0 PCI=438，沒有響應，18:10:50. 42秒后上報第2個MR。 兩個小區(qū)的位置圖層： 問題分析： ATP抓包反饋情況： 第一個MR沒有反饋： 第二個MR，啟動切換，但是切換準備失敗，反饋傳輸資源不足造成，最后還是完成切換，前臺測試切換至NBHS錦江年華FHTL-2 PCI

5、=320非NBHS青林灣西FHTL-0 PCI=438。 查看導出的鄰區(qū)關系列表，NBHS維科上院FHTL-1 PCI=487與NBHS青林灣西FHTL-0 PCI=438兩個小區(qū)之間存在鄰區(qū)關系，但是查看配置文件，發(fā)現(xiàn)青林灣西鄰基站中未配置維科上院的鄰基站信息（200914與200894）。 解決措施： 添加青林灣西鄰基站中未配置維科上院的鄰基站信息。 處理效果 添加兩個基站之間的鄰基站信息后，小區(qū)間切換支持。 附件或日志： 1.2 X2口不通導致的切換失敗 問題描述： 測試車輛由南向北行駛至前湖北路路段，UE占用NBYZ四季瑞麗1小區(qū)PCI483的信號，在該路段接

6、收到主服小區(qū)的RSRP-106dBm，無線信號在該路段覆蓋較差。通過UE上報的測量報告發(fā)現(xiàn)，UE有上報切換目標為NBYZ現(xiàn)代轎車城3小區(qū)PCI473，該小區(qū)的RSRP-88dBm，信號良好；但未發(fā)生切換。 無線覆蓋示意圖 測量報告示意圖 鄰區(qū)關系示意圖 問題分析： 測試車輛由南向北行駛至前湖北路路段，UE占用NBYZ四季瑞麗1小區(qū)PCI483的信號，在該路段接收到主服小區(qū)的RSRP-106dBm，無線信號在該路段覆蓋較差。通過UE上報的測量報告發(fā)現(xiàn)，UE有上報切換目標為NBYZ現(xiàn)代轎車城3小區(qū)PCI473，該小區(qū)的RSRP-88dBm，信號良好；但未發(fā)生切換，經核查鄰區(qū)發(fā)

7、現(xiàn)NBYZ四季瑞麗1小區(qū)與NBYZ現(xiàn)代轎車城3小區(qū)之間未添加鄰區(qū)關系。 解決措施： 添加這兩個小區(qū)鄰區(qū)關系之后仍不切換，檢查小區(qū)狀態(tài)，狀態(tài)運行正常，無故障。隨后檢查這兩個小區(qū)的X2接口連接指示發(fā)現(xiàn)，配置狀態(tài)為“不存在”，修改為“存在”后，切換正常。 處理效果 把X2接口連接指示配置狀態(tài)修改為”存在后“切換正常。 1.3硬件和傳輸故障 問題描述:5月27日，蔣王廟試擴L 329138,00蔣王廟試擴L-2_2站內切換指標如下： 服務小區(qū)名稱 服務小區(qū)ID eNodeB內切換出成功次數(shù) eNodeB內切換出嘗試次數(shù) eNodeB內切換出失敗次數(shù) ENODE內切換成功率 蔣

8、王廟試擴L 329138,00蔣王廟試擴L-2_2 329138 9 11 2 81.82% 329138 5 6 1 83.33% 329138 5 6 1 83.33% 329138 4 6 2 66.67% 從KPI的統(tǒng)計表中可以看出，基站內切換成功率在一段集中的時間內較差，而之前的時間段ENB內切換成功率均為100%。 問題分析：根據(jù)下圖上午MR計算出目標小區(qū)的RSRP為-90dBm，覆蓋良好。 1.4隨機接入參數(shù)配置不當引起切換失敗 問題描述： 使用L1*Outum8.0進行測試時候發(fā)現(xiàn)云南昆明LTE網絡新入網很多基站在無線環(huán)境很好（

9、RSRP-80dbm左右&SINR20左右）的情況下基站內小區(qū)間切換均失敗，在測試中時出現(xiàn)以下情況，UE在正常接入小區(qū)后，UE上發(fā)測量報告，然后基站下發(fā)重配置消息，UE上傳重配置完成消息，從無線口信令消息看切換已經完成。但是從測試過程中發(fā)現(xiàn)并沒有切換成功，而是經過2秒后基站下發(fā)MIB消息、系統(tǒng)消息，然后 UE上傳連接重建消息，接著基站下發(fā)連接重建命令，UE上傳連接重建完成，到此UE應該是重新接入小區(qū)，并不是切換。具體個例如下： 同時在基站側用ATP進行跟蹤時，出現(xiàn)如下圖情況：UE上傳測量報告，基站下發(fā)連接重配置消息，但UE在2秒內無回應或者基站在這2秒內沒收到重配置完成消息，于是2秒之后

10、UE上傳系統(tǒng)消息1，而基站則下發(fā)系統(tǒng)消息2，然后就是上傳連接重建請求消息，基站下發(fā)連接重建命令，接著 UE上傳連接重建完成，到此UE重新接入小區(qū) 問題處理流程： 1、首先針對小區(qū)內鄰區(qū)進行檢查，鄰區(qū)配置正確； 2、由于是雙模站點，所以提取同樣為雙模站點的寧波參數(shù)進行對比，發(fā)現(xiàn)關于切換的參數(shù)均配置正確； 3、通過以上分析發(fā)現(xiàn)發(fā)生切換時候手機能上報重配置完成消息，但是基站側沒有收到這條消息，說明有可能是接入參數(shù)有異常。 4、研發(fā)支持：通過收取CDL/ATP/基站公共日志進行分析以后研發(fā)懷疑是隨機參數(shù)設置不當造成的，隨機接入參數(shù)零相關配置參數(shù)現(xiàn)場設置為11比較大，建議調整為默認的設置3

11、以后進行試驗。 問題解決效果： 將零相關配置從11調整為3以后從下圖可以看出調整前測試還是出現(xiàn)切換失敗，但是調整以后基站內小區(qū)間切換成功，對基站間相鄰小區(qū)的切換也成功，說明該問題已經解決。 總結： 根序列索引規(guī)劃建議 現(xiàn)網中宏站Preamble格式通常選擇格式0，室分為格式4；宏站PRACH配置索引設置為3，室分為51；室外推薦的零相關配置為3，對應低速非受限取值為18；室內站點零相關配置為3；對應的Ncs值為8；根序列索引的配置和PCI相關： 若室外宏站的零相關配置采用3，對應的Ncs值為18，這樣每個根序列能產生838/18=46個preamble碼，每個小區(qū)需要產生64個

12、preamble碼，故需要64/46=2個根序列產生一個小區(qū)所需的premble碼，故838個索引能產生838/2=419個小區(qū)所需的preamble碼，所有小區(qū)重復利用這419個，為了避免相鄰小區(qū)的根序列索引沖突，故根序列索引值和PCI關聯(lián)，即根序列索引=（PCImod419）*2； 室分站點零相關配置采用3，對應的Ncs值等于8，這樣每個根序列能產生138/8=17個preamble碼，每個小區(qū)需要產生64個preamble碼，故需要64/17=4個根序列產生一個區(qū)所需的premble碼，故138個索引能產生138/4=34個小區(qū)所需的preamble碼，所有小區(qū)重復利用這34個，為了避

13、免相鄰小區(qū)的根序列索引沖突，故根序列索引值和PCI關聯(lián)，故根序列索引=（PCImod34）*4。 排查基站告警，在查詢基站告警日志發(fā)現(xiàn)在該時間段存在小區(qū)退服,傳輸故障，X2鏈路故障的告警。如果由于小區(qū)重復退服，可能導致站內切換成功率下降。 告警名稱 告警級別 告警源 網元類型 產生時間 小區(qū)退服,傳輸故障 主要 蔣王廟試擴L 329138,小區(qū) 2 ENB 2013-05-27 20:38:16 X2鏈路故障 次要 蔣王廟試擴L 329138,SCTP鏈路 2 ENB 2013-05-27 20:02:05 小區(qū)退服,傳輸故障 主要 蔣王廟試擴L

14、329138,小區(qū) 2 ENB 2013-05-27 19:28:36 問題解決：安排基站人員上站排查，重現(xiàn)建立X2鏈路后告警消除。 解決效果：28日現(xiàn)場排除告警后提取當日指標進行驗證。下表為蔣王廟28日全天級指標，已有明顯提升。 服務小區(qū)名稱 服務小區(qū)ID eNodeB內切換出成功次數(shù) eNodeB內切換出嘗試次數(shù) eNodeB內切換出失敗次數(shù) ENODE內切換成功率 蔣王廟試擴L 329138 329138 261 264 3 98.86% 1.5重選優(yōu)先級設置不一致導致異頻無法切換 問題描述：云南昆明LTE實驗網新開局對室內和宏站之間異頻切換進行驗

15、證。使用L1*Outum8.0/華為MIFI*Outum8.0進行異頻切換驗證；驗證參數(shù)配置： 1、X2鏈路、鄰區(qū)關系與小區(qū)異載波信息配置完成；2、A1 A2算法均開啟測量；3、GAP測量打開；從驗證結果發(fā)現(xiàn)室分可以切換到宏站，而從宏站無法切換到室分； 問題分析：在進行切換驗證測試時發(fā)現(xiàn)當師大商學院（宏站）的RSRP值達到-112dbm且嵩明云南師范大學商學院動感廳（室分）的RSRP達到-69dbm時，已經達到切換門限，但是UE仍駐留在師大商學院2小區(qū)中不發(fā)生切換，最終由于信號過低終端進行重建而駐留到室分基站，切換失敗，查看信令消息時，此時UE已經上傳測量報告，而且也有重配置消息下發(fā)但是終端

16、并沒有發(fā)生切換，對重配置消息進行解析發(fā)現(xiàn)該重配置消息并不是用于切換的重配置消息。如下圖所示 問題處理流程： 1、對兩個基站的X2鏈路及鄰區(qū)關系進行刪除再重新創(chuàng)建，并且重新配置異頻載波信息，切換問題未解決； 2、由于室外宏基站是雙模站而室分是單模站，因此對單模站點的“單模RRU幀頭偏移置”進行設置，由無偏移設置為700us，參數(shù)修改以后進行驗證，切換問題未解決； 3、經研發(fā)老師指導發(fā)現(xiàn)師大商學院基站的小區(qū)重選公共參數(shù)中的“小區(qū)重選優(yōu)先級”設置為3，而EUTRAN異頻載波信息中的“小區(qū)重選頻點優(yōu)先級”設置為1。將小區(qū)重選公共參數(shù)中的“小區(qū)重選優(yōu)先級”設置為1，與EUTRAN異頻載波

17、信息中的“小區(qū)重選頻點優(yōu)先級”設置保持一致，切換問題解決； 問題解決效果 將師大商學院基站的小區(qū)重選公共參數(shù)中的“小區(qū)重選優(yōu)先級”設置為1，與EUTRAN異頻載波信息中的“小區(qū)重選頻點優(yōu)先級”設置為1保持一致，通過驗證發(fā)現(xiàn)問題已經徹底解決。 總結： 目前我司設備的異頻切換算法，采用A1/A2/A3/A4/A5算法， A1用于異頻關閉，其中A2用于開啟異頻測量，A3用于啟動切換請求（當A3用于異頻時必需保證源小區(qū)和目標小區(qū)的小區(qū)重選優(yōu)先級一致），A4用于異頻高優(yōu)先級切換，A5用于異頻低優(yōu)先級切換； 在異頻切換時，若僅開啟A2、A3測量開關，小區(qū)重選公共參數(shù)中的“小區(qū)重選優(yōu)先級”與EUT

18、RAN異頻載波信息中的“小區(qū)重選頻點優(yōu)先級”設置必須一致。 出于某種目的，“小區(qū)重選優(yōu)先級”必須設置成不一致時，需要開啟A4或者A5測量開關用于異頻測量。 1.6 MME問題導致入POOL基站大量切換失敗 問題描述：福州KPI組發(fā)現(xiàn)3月8日后全網的切換成功率一直在惡化，提取切換失敗TOP小區(qū)分析CDL發(fā)現(xiàn)，切換失敗大部分為目標小區(qū)回復切換準備失敗攜帶原因為transport-resource-unavailable。 問題分析：在基站版本45.16版本升級后，福州全網也出現(xiàn)了大量的切換失敗，失敗原因為transport-resource-unavailable，排查定位過程發(fā)現(xiàn)是基

19、站的鄰基站中SCTP鏈路索引對應錯誤導致，基站升級后解決。而近期又出現(xiàn)了相同原因的切換失敗，所以第一時間核查了全網的X2鏈路、鄰基站，但是發(fā)現(xiàn)并沒有異常，于是基本排除是X2鏈路、鄰基站的原因導致目標小區(qū)切換準備失敗。于是，分析TOP小區(qū)，以上渡派出所-DLH（ENBID:418705）為例，提取該站CDL日志分析。 切換統(tǒng)計顯示站內切換和S1切換都正常，X2切換成功率只有10.79%，而且切換出失敗中99.91%是“切換目標側準備失敗”，通過切換分析可以看出，1082次切換失敗，全部是往ENBID:418644切換，而且釋放原因全部為transport-resource-unavaila

20、ble?，F(xiàn)場已知該原因釋放的問題主要是X2資源導致的，而已經核查過全網X2配置，且確認418705和418644之間完全正常。 在X2切換成功的詳表中發(fā)現(xiàn)目標基站ID為418644的切換有成功的，于是對比時間相近的切換失敗和切換成功。通過對比x2 Handover Request的IE值，發(fā)現(xiàn)切換成功時該消息拾的GUMMEI中MME-CODE為D0H（208）對應福州MME，而切換失敗時的MME-CODE都為10H(16)對應廈門MME。在OMC上查看418705的S1鏈路狀態(tài)，發(fā)現(xiàn)到福州MME的S1鏈路狀態(tài)為“與對端連接成功”（正常），而與廈門MME的S1鏈路狀態(tài)為“驅動建立

21、成功”（故障）。 再分析目標基站418644的CDL日志，發(fā)現(xiàn)該站有大量的S1建立失敗信令，檢查S1 Setup Request的各IE值都正常，S1 Setup Failure攜帶原因為message-not-compatible-with-receiver-state。為區(qū)分是基站問題還是MME問題，分別刪除再添加該站到廈門和福州的MME，到福州MME的S1鏈路馬上建立成功，到廈門MME的S1鏈路仍然故障。對比基站給兩個MME發(fā)送的S1 Setup Request的IE值完全一致，說明基站的S1 Setup Request消息并沒有問題，問題出在廈門MME上。

22、分析剩余的TOP小區(qū)，發(fā)現(xiàn)都存在與418705一致的現(xiàn)象，即目標小區(qū)到廈門MME的S1鏈路故障。 目前福州全網基站已開啟S1-FLEX算法，全部入MME POOL(福州、廈門兩臺MME)，且兩臺MME的能力都配置為50，為負荷分擔方式組網，所以正常入POOL的基站下接入，UE有50%的概率接入到兩臺MME上。 通過信令和TS36.413我們可以知道，ENB發(fā)起S1 Setup Request，MME回復S1 Setup Response會攜帶MME的相關信息（PLMN，MME組號，MME編號， MME能力等。），而S1鏈路建立失敗時ENB獲取不到相應的MME的信息的。 假設ENB1

23、正常入POOL（兩條S1（S1a，S1b）正常），ENB2（其中1條S1故障（S1a正常，S1b故障），當UE在ENB1下從S1a接入，往ENB2切換，由于ENB2的S1a是正常的，ENB2上有S1a對應MME的信息，切換可以正常進行。而當UE在ENB1下從S1b接入，往ENB2切換，由于ENB2的S1b故障，ENB2上并沒有S1b對應的MME信息，所以切換需要的S1資源無法成功準備，所以會給ENB1回復Handover Preparation Failure，導致切換失敗。 解決措施： 在分析出是廈門MME問題導致全網切換失敗后，聯(lián)系廈門MME人員，提供S1建立失敗的基站信息，MM

24、E側抓包、提取MME日志確認是MME的問題。只要MME處理完后基站S1正常建立，切換成功率即可恢復。 雖然切換成功率惡化的原因已查明為MME故障，但是在定位過程中基站給出的切換準備失敗的Cause值誤導了現(xiàn)場的問題定位。 對于目標S1鏈路故障導致切換準備失敗的現(xiàn)象，在和NSN,ZTE跨廠家切換的時候已經分析過，但是對于這類問題，其他廠家一般在Handover Preparation failure中攜帶的原因為“Unknown MME Code”，而我們基站是回復“transport-resource-unavailable”，影響了問題的定位效率，而TS36.423中對這類原因有注釋

25、，其他廠家此類問題的原因歸類為“Unknown MME Code”更能有效指導問題定位。 與研發(fā)確認，目前基站版本eNB只是發(fā)現(xiàn)用戶所在的Gummei與自己連接的MME不一致，直接判斷失敗。并沒有進一步判斷是GroudID不正確，Plmn不正確，還是Mme Code不正確。為便于容易指導現(xiàn)場定位，后續(xù)基站版本會加入相應判斷，優(yōu)化Cause值。 處理效果： 3月15日凌晨，廈門MME人員針對S1無法建立的問題現(xiàn)場處理后，原因到廈門MME的S1鏈路故障的全部恢復正常，當天全網的切換成功率就回升到95%。 1.7開站數(shù)據(jù)模板不對引起切換失敗 問題描述：近日新開LTE室VIP站點

26、泗陽移動公司新大樓，添加完鄰區(qū)后狀態(tài)正常，現(xiàn)場發(fā)現(xiàn)無法切換到室外宏站，但是室外宏站可以切換到室內，隨后對該問題進行分析定位。 問題分析： 1、 無線環(huán)境分析 CellName ECI TAC BandWidth Frequency_DL PCI 宿遷泗陽移動新大樓LEW-1 0 20559 20 2360 500 宿遷泗陽新世界LF-1 0 20559 20 1890 84 根據(jù)現(xiàn)場測試，宿遷泗陽移動新大樓室外最強宏站為泗陽新世界LF-1，RSRP電平在-90~-100之間，相對較弱，但根據(jù)小區(qū)算法-切換算法-鄰小區(qū)RSRP門限為20（-120dbm）

27、，室外電平滿足切換入的要求。 2、 信令分析 1）、通過前臺新令分析，在由室內到室外過程中，UE發(fā)送MR后收到RRC釋放請求，并沒有進入RRC 重配過程，如下圖： 從后臺上看為收到測量報告后，eNB向EPC側發(fā)送 UE Context Release Request 釋放上下文，同時向UE發(fā)送RRC釋放，最終無法完成切換。 分析eNB釋放上下文攜帶的原因為ue-not-aivilble-for-ps-service,該原因與CSFB重定向到2G的原因一致，對RRC Connection Release進行分析，發(fā)現(xiàn)攜帶GERAN頻點信息，初步判斷為進入了盲重向過程，

28、而沒有進行異頻信息測量。 2）、現(xiàn)場隨后進行參修改，關閉小區(qū)-小區(qū)測量-A3事件配置1.1-測量相關算法中的小區(qū)間干擾協(xié)調算法，同時將A1和A2 RSRQ門限值都修改為-50，現(xiàn)場測試發(fā)現(xiàn)UE一直上發(fā)測量報告，但無法收到攜帶異頻（38350）的RRC重配置消息，導致終端一直無法進行異頻測量，該問題為現(xiàn)場將A1/A2設置一致導致異頻測量無法啟動。 3）、現(xiàn)場將GERAN異載波信息、GERAN鄰小區(qū)關系刪除，同時將A2 RSRP門限值修改為-90，同時關閉A1事件配置（關閉A1事件配置為更換定位問題，終端始終開啟異頻測量），測試發(fā)現(xiàn)能夠正常進行切換。 4）、后臺重新將GER

29、AN異載波信息、GERAN鄰小區(qū)關系添加后測試，又再現(xiàn)RRC釋放，現(xiàn)象和之前一樣，判斷為添加GERAN異載波信息后上報本小區(qū)電平測量達到一定的門限，觸發(fā)了盲重定向過程，而該過程門限高于異頻切換門限，導致在室內到室外移動過程中，室內信號漸弱，在室外電平未滿足切換之前發(fā)生了盲重定向，釋放RRC，其中A2 RSRP門限、系統(tǒng)間測量門限、和盲重定向門限設置如下 當時無線環(huán)境RSRP電平在-90~-100之間，有可能啟動系統(tǒng)間測量，但是若盲重定向門限為-118dbm，則不滿足盲重定向門限。 5）、重新核查盲重定向門限，發(fā)現(xiàn)該站點小區(qū)-小區(qū)算法-異系統(tǒng)互操作中無重定向門限，如下：

30、 而正常的站點含有盲重定向門限，如下： 問題定位： 經過上述分析，將問題定位為RRC釋放的原因為發(fā)送了盲重定向，而該站點模板或版本存在問題，無盲重定向門限設置導致。 盲重定向門限為TD-LTE_V3.20.00.45.17.03版本后添加的，該站點開通時項目已統(tǒng)一使用45.17.03的開站模板，進一步核查，發(fā)現(xiàn)該站點運行基站軟件包版本為TD-LTE_V3.20.00.45.17而使用45.17.03模板進行開通導致，隨后對該站點軟件版本升級到TD-LTE_V3.20.00.45.17.03后測試正常。未出現(xiàn)盲重定向問題。 后續(xù)建議： 該問題最終定位為站點開通模板和站點運行的軟

31、件包版本不一致導致，由于版本升級前后的變更可能導致個別新增的參數(shù)和功能在老版本的站點中出現(xiàn)問題，最終導致異常事件發(fā)生，建議在后續(xù)站點開通過程規(guī)范版本和模板，開站數(shù)據(jù)模板注明對應的版本信息，保證督導使用現(xiàn)網最新統(tǒng)一的版本和基站數(shù)據(jù)進行站點開通。 1.8傳輸端口環(huán)回問題導致S1切換成功率低 問題描述： 臨汾兩站之間S1切換失敗次數(shù)較多，影響全網KPI指標。查看SCTP鏈路故障，顯示驅動配置成功。 問題分析： 查看CDL：UE上發(fā)MR之后， 由于X2鏈路故障基站判決走S1切換。在經過200個半幀后遲遲未收到核心網的回應，導致S1切換定時器超時后向EPC發(fā)起切換取消的命令。這里有兩種可

32、能，一種是基站側消息發(fā)出去了核心網沒有收到。一種是核心網下發(fā)了回應消息而基站側沒有收到。 定位過程： 出現(xiàn)這種情況受限切換走S1就不正常，需要先排查X2鏈路故障的原因。通過查看核查鄰區(qū)關系，路由配置以及傳輸參數(shù)沒有發(fā)現(xiàn)問題。用LMT登錄基站在診斷測試里互相ping對端基站的業(yè)務IP都不通，在A站Ping自己的網關發(fā)現(xiàn)存在丟包現(xiàn)象。查看SCTP鏈路顯示驅動配置成功，A站為服務器，B站為客戶端。刪除A站的服務器后A站又自動建立。然后同時刪除兩端的SCTP鏈路，在A站建立客戶端，然而B站卻無法自動建立服務器。說明B站收不到A站的發(fā)包，而A站卻可以收到B站的發(fā)包。因此懷疑傳輸側存在問題，導致X

33、2鏈路不通。 基站的網關跟基站間就相當于區(qū)域網內直連，如果這樣ping通的情況都會有丟包，說明基站跟網關的物理鏈路很不好，即基站消息發(fā)送的第一結點都不能保證傳輸質量。而傳輸質量不好必然會影響切換的成功率。 為進一步定位是否是傳輸問題影響的切換，進行以下操作： 打開電腦的cmd命令窗口，telnet登陸基站，使用OM管理IP，例如： telnet 100.92.194.9，用戶名和密碼都是 root 然后直接敲命令ping對端基站，ping時候使用X2對端業(yè)務IP，例如 ping 100.84.194.19 -s 200 -c 10 【-s (SIZE) 表示ping包大小， -

34、c (CNT)表示ping次數(shù)】 之后會在cmd命令窗口，看到如下示例，如果PTN端口有問題，會看到好多回復報文，TTL從64減到1才會停止。如果兩個站ping不通，可以選另外一個可以ping通的X2對端基站，以便發(fā)現(xiàn)PTN內部環(huán)回問題。 傳輸端口環(huán)回： 傳輸正常： 定位結果： 現(xiàn)場將此問題現(xiàn)場呈現(xiàn)給傳輸側，傳輸重新把該站的傳輸數(shù)據(jù)做了一下之后SCTP鏈路全部恢復正常，提取KPI指標，沒有再出現(xiàn)S1切換，且X2切換成功率明顯上升。 1.9府東街-3小區(qū)異常切換(A1/A2異頻切換) 問題描述： 府東街基站天線可視20米距離不能切換到該基戰(zhàn)，始終占用臨近鄉(xiāng)政府基站信號

35、 問題分析： 8月8日路測人員反映在府東街基站附近面對天線可是條件20米距離只能接收到鄉(xiāng)政府基站兩個扇區(qū)的信號，收不到府東街的信號。測試工程師打電話至后臺，確認基站狀態(tài)正常，功率參數(shù)正常。使用CDS設備到現(xiàn)場測試發(fā)現(xiàn)： 圖中紅色圓圈位置距離鄉(xiāng)政府基站560m，距離府東街距離280米，在已經越過府東街280的情況下，而且鄉(xiāng)政府1小區(qū)RSRP已經達到-99dBm的情況下沒有切換到府東街基站。核查基站狀態(tài)、功率參數(shù)，都在正常范圍內。為了確認是否為基站問題，做了反向測試，發(fā)現(xiàn)從府東街到鄉(xiāng)政府方向能正常占用府東街信號。 下圖是反向測試截圖，表明終端可正常占用府東街信號： 反向測試結果表明

36、，問題不在基站側。 反復測試時發(fā)現(xiàn)，從鄉(xiāng)鎮(zhèn)局到府東街方向，終端在占用鄉(xiāng)鎮(zhèn)局信號時不上報A2消息，而且鄉(xiāng)鎮(zhèn)局的信號已經到了-99dBm時都沒有下發(fā)鄰區(qū)列表，初步分析問題出在鄉(xiāng)鎮(zhèn)局，不是鄉(xiāng)鎮(zhèn)局到府東街不能切換，應該是鄉(xiāng)鎮(zhèn)局參數(shù)配置有誤。核查后臺參數(shù)后發(fā)現(xiàn)鄉(xiāng)鎮(zhèn)局為F頻段基站（38350），府東街為D頻段基站（37900），鄉(xiāng)鎮(zhèn)局基站A1配置為-98dBm，A2配置為-100dBm，府東街基站A1配置為-88dBm，A2配置為-90dBm，兩個基站的事件遲滯參數(shù)配置都為2。 在LTE系統(tǒng)切換分為三個步驟： 在切換過程中的異頻異系統(tǒng)測量主要由A1、A2 事件控制，A1事件表示服務小區(qū)質量高于一

37、定門限，當滿足事件觸發(fā)條件時，UE便上報測量報告，eNode停止異頻異系統(tǒng)測量；A2事件表示服務小區(qū)質量低于一定門限，當滿足事件觸發(fā)條件時，UE便上報測量報告，eNode啟動異頻異系統(tǒng)測量。 A1事件的觸發(fā)條件：Ms – Hys > Thresh A2事件的觸發(fā)條件：Ms + Hys < Thresh 按照A1、A2的觸發(fā)條件，我們可以計算出從鄉(xiāng)政府到府東街方向測量控制行為的伐值 A1: MS-2>-98 MS>-96 dBm 時停止異頻異系統(tǒng)測量 A2:MS+2<-100 MS<-102dBm時啟動異頻異系統(tǒng)測量 這就解釋了為什么從鄉(xiāng)政府到府

38、東街方向異常切換的原因是A1、A2參數(shù)設置不合理導致。 網絡優(yōu)化本身就是個性化和精細化的工作，A1、A2參數(shù)的設置并沒有死板的規(guī)定，在很多特殊或者精細化場景A1=--98，A2=-100并沒有什么錯誤，但對于鄉(xiāng)政府--府東街這個方向這樣的參數(shù)設置顯然是不合理的，顯然當時配置參數(shù)的工程師僅僅從一個方面考慮問題，沒有全面考慮參數(shù)配置對網絡的影響。 對該問題的分析討論不僅僅是為了解決一個簡單的異常切換問題，重點是討論分析不同場景的切換策略。 我們可以通過分析鄉(xiāng)政府周邊站點的情況來看當時配置A1、A2參數(shù)的原因： 專題地圖中基站中心不同顏色的圓點代表的頻率信息，扇區(qū)顏色代表模三信息。紅色為

39、D頻段37900，綠色代表F頻段38350，從專題地圖中可以明顯看出F頻段的鄉(xiāng)鎮(zhèn)局周邊被D頻段的站點所包夾。如果按照正常場景或者正常優(yōu)化思路，這種場景為了規(guī)避數(shù)量較多的D頻段基站的模三干擾A1=-98dBm，A2=-100dBm的參數(shù)配置可以使終端在業(yè)務態(tài)時盡量占用無線環(huán)境較為純凈的F頻段的信號。但是這樣的參數(shù)設置沒有考慮到鄉(xiāng)政府-府東街一線由于特殊的無線環(huán)境，這兩個基站1扇區(qū)的信號都被限制在基站所在的道路上，那同時外邊的信號也基本不能覆蓋到該區(qū)域，我們可以通過這條道路的SINR值來印證。 參數(shù)修改前鄉(xiāng)鎮(zhèn)局1小區(qū)與府東街1小區(qū)的切換點 從SINR圖示我們可以看到在這條無線環(huán)境相對比較封

40、閉的道路上無論占用F頻段的鄉(xiāng)政府-1小區(qū)還是D頻段的府東街-1小區(qū)，SINR都非常好，絕大多數(shù)采樣點SINR值都在15-40范圍內，即便是少數(shù)幾個不好的采樣點SINR值也在9-15之間，這已經是很好的無線環(huán)境，在這種無線環(huán)境中讓終端占用F頻段的基站并沒有明顯的益處，反而會拉低這個小范圍的下載速率，導致基站利用率降低。 由于TD-LTE和TD-SCDMA都是時分雙工系統(tǒng)，為了最大限度的降低兩個系統(tǒng)的上行干擾必須拉起這兩個系統(tǒng)的特殊時隙，也就是要保證TD-SCDMA和TD-LTE在特殊時隙上同發(fā)同收，否則會因雜散或者互調問題導致下行強干擾信號影響上行。 基于以上原因F頻段基站的特殊子幀的配比必

41、須是3：9：2，按照LTE協(xié)議規(guī)定，當DwPTS符號配比>=9時，才允許傳送業(yè)務數(shù)據(jù)，F(xiàn)頻段的基站DwPTS配比為3的時候不符合可以傳送業(yè)務數(shù)據(jù)的條件，因此在F頻段的基站特殊子幀不能傳送業(yè)務數(shù)據(jù)。 D 頻段站點因為不涉及與其他網絡的雜散或者互調干擾問題，特殊子幀的符號配比可以在協(xié)議規(guī)定范圍靈活選擇，當前網絡D頻段的特殊子幀的符號配比為10：2：2，按照這種符號配比，D頻段基站的特殊子幀的下行導頻時隙可以傳送業(yè)務數(shù)據(jù)。 根據(jù)以上分析我們可以得出結論，在SINR值相當?shù)那闆r下D頻段基站的下載速率大于F頻段的基站。 我們可以通過A1、A2參數(shù)修改前后的路測結果驗證以上結論。 參數(shù)修改前的下載

42、速率渲染圖 參數(shù)修改后的下載速率渲染圖 從下載速率我們可以看到，修改參數(shù)后在鄉(xiāng)政府到府東街路段下載速率得到明顯改善。 解決措施： 修改鄉(xiāng)政府1小區(qū)A1 事件參數(shù)，原參數(shù)設置 A1= -98 的Bm，修改為 -86dBm 修改鄉(xiāng)政府1小區(qū)A2事件參數(shù)，原參數(shù)設置 A2= -100 的Bm，修改為 -88dBm 修改鄉(xiāng)政府1小區(qū)A3事件參數(shù)，對于鄉(xiāng)政府-1的鄰區(qū)府東街-1，小區(qū)個性偏移原值為0，修改后的值為5。 修改的目的：讓終端更快的切到下載速率更好的D頻段。 2. 接入類問題 2.1MCC設置錯誤導致E-RAB建立成功率為0 問題描述： 在分析TOP小區(qū)

43、時，發(fā)現(xiàn)HD堤村1小區(qū)無線接通率為0，其中RRC連接成功率為100%，E-RAB建立次數(shù)及成功率均為0，與前面RRC連接次數(shù)極不對稱，統(tǒng)計指標如下圖所示： 問題分析： 首先通過CDL對本基站1小區(qū)的E-RAB建立進行分析，從信令流程上具體定位問題發(fā)現(xiàn)在哪個環(huán)節(jié)；根據(jù)CDL信令流程或提示再核查基站的告警狀態(tài)、是否故障或者開站數(shù)據(jù)是否有誤（如SCTP鏈路、VLAN、路由、基站ID、MCC、MNC、TAC等）； 問題排查： 分析基站CDL日志 方法步驟：通過分析本基站1小區(qū)的CDL日志，發(fā)現(xiàn)在本小區(qū)下，有終端一直進行RRC連接，但連接完成后直接釋放，即不進行E-RAB建立，信令流程圖

44、如下： 核查基站的開站基礎數(shù)據(jù) 方法步驟：通過信令得知UE不進行E-RAB建立，首先需要核查本小區(qū)是否存在故障或者告警，通過核查后無這方面的因素；同時分析所得因為UE不進行E-RAB建立，應該把參數(shù)核查重點放在跟核心網有關的參數(shù)上面，因此通過檢查基站的參數(shù)發(fā)現(xiàn)本基站1小區(qū)的MCC設置為640，如下圖所示： 正確設置應該為MCC為460。 處理過程： 將本基站1小區(qū)的MCC由640更改為460。 處理效果 將MCC更改正確后的本小區(qū)指標正常，如下圖： 延伸 1、當一個小區(qū)RRC連接成功率很高，但E-RAB建立成功比較低，一般可確認空口不存在問題，此時一般可以從開站數(shù)

45、據(jù)核查開始，即主要涉及UE接入核心的參數(shù)進行核查，諸如MCC、MNC、TAC等； 2、在督導開站過程中一定要注意基站基礎數(shù)據(jù)的配置是否正確，否則一個小小的失誤將會造成基本的指標直線下降。 2.2核心網問題導致REAB建立失敗 問題描述： 福州在海峽會展保障期間出現(xiàn)大量ERAB建立失敗，18:00~19:00，E-RAB失敗2100次，嚴重影響全網指標，造成用戶感知較差。 問題分析： 查看CDL：核心網在發(fā)起S1 Initial Context Setup Request，之后AP側上報兩次AP_PER_ERROR，基站直接回復S1 Initial Context Setup

46、Failure,失敗原因為semantic-error 定位過程： 經過查看核心網發(fā)出的上下文建立請求消息中，發(fā)現(xiàn)AMBR攜帶的值為0，根據(jù)協(xié)議，eNB判斷此消息非法，會導致上下文建立失敗，影響上下文建立和承載建立的KPI?，F(xiàn)場和諾西的核心網廠家確認，此問題為諾西EPC的已知BUG。 具體協(xié)議如下： 9.2.1.20 UE Aggregate Maximum Bit Rate The UE Aggregate Maximum Bitrate is applicable for all Non-GBR bearers per UE which is defined for th

47、e Downlink and the Uplink direction and provided by the MME to the eNB. IE/Group Name Presence Range IE type and reference Semantics description UE Aggregate Maximum Bit Rate Applicable for non-GBR E-RABs. >UE Aggregate Maximum Bit Rate Downlink M Bit Rate 9.2.1.19 This IE indicat

48、es the UE Aggregate Maximum Bit Rate as specified in TS 23.401 [11] in the downlink direction. >UE Aggregate Maximum Bit Rate Uplink M Bit Rate 9.2.1.19 This IE indicates the UE Aggregate Maximum Bit Rate as specified in TS 23.401 [11] in the uplink direction. Receiving both the UE Aggregate M

49、aximum Bit Rate Downlink IE and the UE Aggregate Maximum Bit Rate Uplink IE equal to value zero shall be considered as a logical error by the eNB. 定位結果： 現(xiàn)場將此問題呈現(xiàn)給諾西廠家，希望能盡早解決此BUG。KPI指標目標目前已恢復正常。 2.3LTE多模終端自由選擇網絡不能接入LTE網絡問題分析 問題描述：IPHONE 5S和L1終端在自由選擇網絡模式下，無法駐留在任何網絡。在手機上看，是手機顯示LTE網絡，或者2G/3G網絡，但是不能

50、進行任何業(yè)務，打電話和上網。而且信號格顯示是空的，即沒有信號。而IPHONE 5S和L1終端終端在華為的站點下，是可以正常駐留并進行CSFB業(yè)務的。L1終端選擇僅LTE模式下，可以正常接入LTE網絡，并且進行數(shù)據(jù)業(yè)務。使用HISI E5776測試此站點，無任何功能性問題，可以接入，業(yè)務正常。 將IPHONE 5S在問題站點下重新開關機，提取基站CDL日志，從CDL日志的信令流程來看，信令走到了SecurityModeCommand就釋放了，見下圖： 圖1-1 IPHONE 5S開機CDL信令流程 點開SecurityModeCommand，里面的詳細內容見下圖： 圖1-2 Se

51、curityModeCommand消息內容 問題分析： 1、一般接入問題需要檢查站點配置文件中的接入參數(shù)、TAC、IP地址和路由關系等參數(shù)設置。本案例中，使用L1和E5776可以正常接入網絡并且進行數(shù)據(jù)業(yè)務，說明基站側接入參數(shù)、TAC、IP地址和路由關系都沒有問題。 2、商用終端的完整性保護算法不能為空算法，這在早期的網絡優(yōu)化過程中也遇到一些商用終端不能接入LTE網絡的問題，后來都是通過修改完整性保護算法優(yōu)先級來解決。 3、對于有CSFB功能的LTE終端來說，聯(lián)合附著不成功，會導致終端不能駐留在LTE網絡。典型的CSFB業(yè)務流程主要包括聯(lián)合附著、位置更新、主叫(MO)CSFB流程、被叫

52、(MT)CSFB流程以及去附著等。 啟用CSFB功能的用戶的附著流程是基于聯(lián)合GPRS/IMSI附著流程來實現(xiàn)的。 問題處理流程： 1、 由于CDL日志里面，完整性保護算法為eia0，即為空算法，導致終端不能接入。因此需要檢查基站側的完整性保護算法參數(shù)。 檢查基站的完整性保護算法參數(shù)，空算法的優(yōu)先級為0，高優(yōu)先級的完整性保護算法都不是空算法，參數(shù)配置沒有任何問題，見下圖： 圖1-3 配置文件完整性保護算法參數(shù) 2、 由于基站側完整性保護算法參數(shù)沒有任何問題，而CDL日志里面，完整性保護算法為空算法，因此懷疑是核心網側問題，聯(lián)系核心網側人員，核心網側人員答復TAC與LAC對應關系出

53、現(xiàn)問題，導致聯(lián)合附著失敗。 處理過程： 華為核心網側人員將TAC與LAC對應關系做了之后，IPHONE 5S、5C以及L1在自由選擇網絡模式下，都可以駐留在LTE網絡上。 聯(lián)合附著流程： TD-LTE/TD-SCDMA/GSM(GPRS)多模單待手持終端在給MME發(fā)送的附著請求消息中攜帶支持CSFB能力的指示。MME在收到用戶的聯(lián)合附著請求后，在進行EPS附著的同時，會推導出其相關CS域的VLR信息，并向這個VLR發(fā)起位置更新請求，VLR收到位置更新請求以后，會將該用戶標記為已經進行EPS附著了，并保存用戶的MME的IP地址，這樣，VLR中就創(chuàng)建了用戶的VLR與MME間的 SGs關聯(lián)。

54、隨后，MSC Server/VLR會進行CS域位置更新并把用戶的TMSI和LAI(位置區(qū)標識)傳給MME，從而在MME中建立SGs關聯(lián)。最后，MME把VLR給用戶分配的TMSI以及LAI等信息包含在附著請求接受消息中發(fā)送給UE，此時就表明用戶的聯(lián)合附著已經成功了。 因此，具有CSFB功能的LTE終端自由模式開機正常流程：優(yōu)先駐留在LTE，即終端開機—>LTE及2G/3G電路域聯(lián)合注冊（確保用戶同時注冊在EPS和GSM電路域網絡）—>駐留LTE，見圖1-4： 圖1-4 聯(lián)合附著示意圖 2.4默認網關配置錯誤 問題描述： 2013年4月23日車輛在江北環(huán)城北路行駛至NBJB清純服飾F

55、HTL附近時,發(fā)現(xiàn)UE無論是S1、X2均無法從其他站切換至本站進行業(yè)務測試，UE顯示“無服務”現(xiàn)象，處于脫網狀態(tài)。待車輛行駛至附近其他基站覆蓋區(qū)域時，UE重新建立鏈接，業(yè)務測試正常。如下圖： 問題分析： 如上圖可見，在NBJB清純服飾FHTL-0、-1主覆蓋區(qū)域RSRP、SINR指標良好（RSRP-75，SINR7），排除無線環(huán)境惡劣導致。查看基站側發(fā)射功率、鄰區(qū)關系、接入參數(shù)、切換參數(shù)等均無異常，基站運行狀態(tài)良好，無告警。查看CDL日志發(fā)現(xiàn)，UE也無法從此站接入，UE接入時提示lintial Context setup Failure（CAUSE TYPE transport_cho

56、sen），如下： 查看路由表發(fā)現(xiàn)路由表中默認網關配置錯誤，實際網關應為100.67.4.129，誤配置為100.67.6.192。 解決措施： 修改路由表中默認網關為100.67.4.129。 處理效果 修改后復測，發(fā)現(xiàn)站點NBJB清純服飾FHTL接入正常，切換正常，數(shù)據(jù)下載業(yè)務良好。如下: 附件或日志： 2.5核心網算法問題 問題描述： 海思E5776終端ATTACH不成功。無法做業(yè)務。 問題分析： 1、原因為網絡側下發(fā)NAS層消息指示終端使用EIA0算法，而海思E5776終端拒絕。無線側信令如下圖所示。 S1接口抓包信令如下： 經核查發(fā)現(xiàn)MM

57、E在SACK id-downlinkNASTransport, Security mode command中下發(fā)的integrity protection algorithm為EIA0 (null integrity protection algorithm) (0)。 海思終端回復了SACK id-uplinkNASTransport, Security mode reject。 Security mode reject消息的詳細信息中含有Plain NAS message, not security protected (0)，表明未啟用安全保護。 SACK id-d

58、ownlinkNASTransport, Attach reject。 2、經由排查發(fā)現(xiàn)協(xié)議規(guī)定，空算法一般用于緊急呼叫，普通的業(yè)務應該使用snow3g和aes算法， 當前諾西核心網的設置為空完整性算法，所以了海思E5776終端拒絕。具體協(xié)議規(guī)定如下圖所示： 解決措施： 將諾西MME修改IntegrityAlgorithm為AES，修改后參數(shù)后的信令如下： 在Security mode command消息中，integrity protection algorithm已經改為 EPS integrity algorithm 128-EIA2 (2)： 在Secur

59、ity mode complete 消息中，integrity方式已變?yōu)閜rotected。在后續(xù)的流程中，完成附著。 經驗總結： 正常的附著流程如下圖所示：MME會通過NAS Security Mode Command 消息將完整性算法傳送給UE。UE根據(jù)NAS Security ModeCommand中選中的算法計算相應的密鑰，用于對空口上傳輸?shù)男帕钌w一個完整性保護戳，幫助接收端確認收到信令消息的合法性。 完整性保護算法是必選的。因協(xié)議規(guī)定，空算法只能用于緊急呼叫，故MME要下發(fā)的完整性算法應該是AES或SNOW3G，而不要下發(fā)空完整性算法。 2.6信令面流程正常業(yè)務面無法

60、上網案例 問題描述： 2月3日與聯(lián)誼賓館進行測試，信令面走到RRC重配置、RRC重配置完成、Attach Complete流程。但是業(yè)務面無速率。 問題分析： 在聯(lián)誼賓館站下進行附著接入過程，信令面走到RRCConnectionReconfiguration、RRCConnectionReconfigurationComplete、Attach附著完成流程。但是業(yè)務面存在問題，無法上網。 檢查基站配置文件，發(fā)現(xiàn)路由關系中網關IP地址配置錯誤，應該配置為100：67：0：193。實際配置為100：67：0：27。 解決措施： 將聯(lián)誼賓館路由關系修改成100：67：0：193

61、 處理效果 修改后，業(yè)務面正常，上網正常，F(xiàn)TP下載速率穩(wěn)定在41M（單通道）。 2.7三星NOTE23信號標識不顯示問題分析案例 問題描述： 用戶反饋三星NOTE2/3一定概率出現(xiàn)不顯示數(shù)據(jù)業(yè)務信號格的情況。此時語音業(yè)務正常，數(shù)據(jù)業(yè)務中斷。 問題分析： 1）問題現(xiàn)象： 對比NOTE2和NOTE3出現(xiàn)該問題時的現(xiàn)象和信令圖，發(fā)現(xiàn)終端從23G模式切換到234G模式后，大約有12S左右無法使用數(shù)據(jù)業(yè)務，終端上的4G信號格不顯示4G標識。 見圖1 ：NOTE2異常的事件 見圖2： NOTE2異常的異常信令 2）協(xié)議過程分析： 從終端側看信令：終端在LTE側進行了RRC

62、請求、建立、完成后，未收到下行傳送消息。此時終端上信號格顯示的形狀也略有不同，NOTE2顯示為一個信號格，NOTE3顯示為兩個信號格，左邊為34G模塊，只有信號格無信號標識，右邊為GSM模塊，可正常顯示信號標識。 由于核心網有時會在15s左右響應NAS層Security Command request消息，大唐的RRC連接釋放定時器設置為10s，所以這時候終端被異常釋放，在4G上未注冊成功，從終端表現(xiàn)來看4G信號格不顯示4G。 圖1：NOTE2出現(xiàn)該事件時的表現(xiàn)： 圖2：NOTE2出現(xiàn)該事件時的表現(xiàn)（圖中出現(xiàn)了一次TAU拒絕，該問題為已知問題承載未建立）： 對比正常時與出現(xiàn)

63、該異常事件時的信令表現(xiàn)，出現(xiàn)異常事件時，終端發(fā)送的ATTACH REQUEST長時間未得到網絡側的相應。 從基站側看：基站向核心網發(fā)送了S1 直傳消息，正常EPC應該下發(fā)S1上下文建立請求給基站，但基站在長時間未收到該消息，釋放了空口RRC。 異常： 正常： 聯(lián)系核心網人員，確認該問題由于有鏈路走的CMNET而不是走IP承載，導致出現(xiàn)幾率性丟包情況。核心網提供的信令截圖，可以看到從收到終端附著請求到MME去HSS取鑒權集就用了15S，正常只要不到1S。 解決措施： 針對此問題，核心網已經將出現(xiàn)該事件時的定時器由15S改為6S（見附圖6），由于小于大唐的RRC連接釋放

64、定時器，這時用戶不會被釋放，可縮短用戶終端上顯示只有信號格的時間。 MME取鑒權超時計數(shù)器修改后驗證，7秒終端可收到下行消息。 3. 速率類問題 3.1下行子幀調度不滿導致平均下載速率低問題分析 問題描述： 在對晉寧移動LTE網絡示范區(qū)使用鼎力ATU設備進行拉網時，發(fā)現(xiàn)平均速率比較低，拉網結果與華為區(qū)域對比如下表： 由表中數(shù)據(jù)可知，我司設備在無線條件均比華為區(qū)域好的情況下，F(xiàn)TP下載速率與華為區(qū)域相差較大，另外一項比較差的指標為DL平均每秒調度PRB個數(shù)，與華為相差13000多個PRB，懷疑此為導致速率低的主要原因。 問題分析： FTP下載速率問題分析方法：

65、首先進行無線環(huán)境、小區(qū)無線參數(shù)、基站告警和傳輸限制等常規(guī)檢查，在排除這些原因之后，根據(jù)速率優(yōu)化的特點，從以下三方面入手排查速率問題： 1 CQI與MCS：MCS等級決定了下載速率大小，遇到速率不高的問題，可先檢查統(tǒng)計結果中平均MCS等級，若發(fā)現(xiàn)MCS等級不高需檢查上報的CQI的信道值。CQI主要通過SINR映射，UE上報CQI，基站通過一定策略計算后決定了下行調度的MCS。 2 MIMO模式：目前外場一般使用TM3和TM7兩種模式切換，而我司設備參數(shù)值設置是保證雙流在TM3上，單流在TM7上。通過統(tǒng)計結果查看雙流占比是否合適，如果雙流占比不高，則需對轉換參數(shù)進行優(yōu)化。 3 PRB調度是否

66、飽滿：PRB調度是否飽滿直接影響速率，通過測試數(shù)據(jù)統(tǒng)計的結果可以看到PRB調度相關的統(tǒng)計值。PRB調度不滿可能的原因為網絡資源或傳輸不夠導致、系統(tǒng)不用使用那么多PRB就可以傳輸數(shù)據(jù)現(xiàn)有的數(shù)據(jù)。DL平均每秒調度PRB個數(shù)如果不滿，可能的原因有PRB調度個數(shù)/slot不滿，測量GAP開啟，切換過多導致。 問題處理流程： 3、 查看無線環(huán)境是否良好，從測試指標上看，我們的平均和邊緣RSRP和SINR均優(yōu)于華為區(qū)域，因此排除無線環(huán)境方面的問題。 4、 核查示范區(qū)內所有小區(qū)無線參數(shù)是否正確； 方法步驟：查看示范區(qū)基站小區(qū)是否設置不當，通過查看確定上下行HARQ開關為開、上下行CQI修正開關為開、下行傳輸模樣固定開關為模式間自適應、分配PRB限制開關為不限制、MCS等級限制開關為不限制、下行流控開關為關、下行ICIC開關為關、DRX配置有效指示為關閉，如下圖所示： 通過核查鄰區(qū)關系，觀察到受限小區(qū)都配有D頻段異頻鄰區(qū)，于是檢查A1、A2、GAP開關狀態(tài)是否開啟，檢查結果為A1、A2、GAP均為關閉狀態(tài)，如下圖所示， 另外檢