1、TD-LTE 網絡優(yōu)化經驗總結網絡優(yōu)化經驗總結 優(yōu)化案例集優(yōu)化案例集案例一：長河水產市場下載速度低案例一：長河水產市場下載速度低案例九：修正案例九：修正測試規(guī)測試規(guī)范范BF Gain計計算公式算公式案例二：案例二：濱濱江江電電力公司上力公司上傳傳速率低速率低案例三：海斯案例三：海斯終終端無法搜網端無法搜網案例五：案例五：遠見遠見智能第智能第1小區(qū)下小區(qū)下載載速率偏低速率偏低問題問題案例六：室分小區(qū)隨機接入失案例六：室分小區(qū)隨機接入失敗敗案例七：基站有信號，案例七：基站有信號，Attach不成功不成功案例四：海斯案例四：海斯終終端端ATTCH 失失敗敗案例八：參數配置案例八：參數配置導導致切致切

2、換換失失敗敗案例一：長河水產市場下載速度低案例一：長河水產市場下載速度低u案例描述：在對長河水產市場進行單站驗證的過程中，對該站進行定點的上傳和下載業(yè)務，發(fā)現即使在覆蓋“極好點”，該站的下載速度依舊只有810Mbps，達不到測試用例的要求；u案例分析：1.根據在該站采用不同的電腦分別在不同的極好點進行測試下載速度均只能達到810Mbps，排除無線環(huán)境的因素；2.檢查電腦網卡設置，修改TCP相關參數，排除電腦本身的網卡設置導致無法達到要求的上傳速度； 3.使用jperf，對傳輸進行推送測試，發(fā)現主要問題應該在傳輸上，由于傳輸的限制導致下載速度最大只能達到10Mbps；u問題解決：1.根據傳輸的拓

3、撲結構，測試路徑一共分為三段：1、長河水產基站到PTN側CE，如果下載速率有問題，證明 PTN傳輸有問題，如果沒有問題，排除PTN傳輸2、PTN側CE到EPC機房FTP server，如果PTN側CE到EPC FTP SERVER速率有問題3、EPC機房交換機上內網FTP SERVER測試2.測試結果顯示為長河水產基站到PTN側CE存在問題，下載速度約為10Mbps，上傳速度約為90Mbps；3.在測試完畢后，經過和華為確認，華為在PTN上做了些QOS的配置，根據不同業(yè)務限制了最高帶寬，對下載業(yè)務帶寬為10M，這樣導致了下載的限制。u優(yōu)化結果：在改變了PTN上的QOS配置的限制之后，再進行下載

4、驗證，結果顯示恢復正常，達到30Mbps以上，符合用例需求；案例一：長河水產市場下載速度低案例一：長河水產市場下載速度低案例九：修正案例九：修正測試規(guī)測試規(guī)范范BF Gain計計算公式算公式案例二：案例二：濱濱江江電電力公司上力公司上傳傳速率低速率低案例三：海斯案例三：海斯終終端無法搜網端無法搜網案例五：案例五：遠見遠見智能第智能第1小區(qū)下小區(qū)下載載速率偏低速率偏低問題問題案例六：室分小區(qū)隨機接入失案例六：室分小區(qū)隨機接入失敗敗案例七：基站有信號，案例七：基站有信號，Attach不成功不成功案例四：海斯案例四：海斯終終端端ATTCH 失失敗敗案例八：參數配置案例八：參數配置導導致切致切換換失失

5、敗敗案例二：濱江電力公司上傳速率低案例二：濱江電力公司上傳速率低u案例描述：在對濱江電力公司進行單站驗證的過程中，在進行上傳業(yè)務時發(fā)現該站點的3個扇區(qū)的速度均比較低，只能達到約25Mbps，而在前期的測試中，該站的上傳速度表現一直很好達到了15Mbps以上；u案例分析：1.在濱江電力1扇區(qū)測試中顯示BLER較高，MCS較低；2.在濱江電力3扇區(qū)測試中顯示時隙配比為3：1；u問題解決：1.在濱江電力1小區(qū)進行參數核查，確定無線參數均正常，嘗試修改相關上行參數進行調整，但上傳速度依舊沒有改善；2.恢復修改的參數，核查干擾源，檢查周邊鄰區(qū)的無線參數配置，經過核查發(fā)現濱江電力3小區(qū)的TDDframec

6、onf=2，即時隙配比為3：1，而周邊基站均為2：2；3.將時隙配比改為2：2后，三個扇區(qū)上傳速度均達到了15Mbps以上，確認為3扇區(qū)的3：1配置對該站有強干擾導致上行底噪上升，上傳速度低；u優(yōu)化結果：在將濱江電力3小區(qū)的時隙配比TDDframeconf改為1后，分別驗證3個小區(qū)的上傳速率，均達到了15Mbps以上；案例一：長河水產市場下載速度低案例一：長河水產市場下載速度低案例九：修正案例九：修正測試規(guī)測試規(guī)范范BF Gain計計算公式算公式案例二：案例二：濱濱江江電電力公司上力公司上傳傳速率低速率低案例三：海斯案例三：海斯終終端無法搜網端無法搜網案例五：案例五：遠見遠見智能第智能第1小區(qū)

7、下小區(qū)下載載速率偏低速率偏低問題問題案例六：室分小區(qū)隨機接入失案例六：室分小區(qū)隨機接入失敗敗案例七：基站有信號，案例七：基站有信號，Attach不成功不成功案例四：海斯案例四：海斯終終端端ATTCH 失失敗敗案例八：參數配置案例八：參數配置導導致切致切換換失失敗敗案例三：海斯終端無法搜網案例三：海斯終端無法搜網u【現象描述】在優(yōu)化中突然發(fā)現海思終端無法進行小區(qū)搜索。u【問題分析】 懷疑CDS軟件設置問題，重啟CDS程序，問題依舊；懷疑Windows問題，重啟系統(tǒng)，問題依舊；懷疑電腦硬件問題，更換電腦，問題依舊；懷疑海思終端問題，更換海思終端，問題不出現。初步定位海思終端故障。u【解決方案】把現

8、象報給海思技術支持，回復可能是鎖小區(qū)的原因造成的，CDS上查看，并沒有鎖小區(qū)，仍然執(zhí)行行鎖小區(qū)解鎖，問題依舊；繼續(xù)重啟電腦，拔插海思終端，問題解決。注意：海思終端，在進行鎖小區(qū)操作后，會在硬件中記錄，即使斷電重啟也不會復位。需要在CDS軟件上進行解鎖操作后，并且重啟海思終端，重啟電腦，才能復位。 案例一：長河水產市場下載速度低案例一：長河水產市場下載速度低案例九：修正案例九：修正測試規(guī)測試規(guī)范范BF Gain計計算公式算公式案例二：案例二：濱濱江江電電力公司上力公司上傳傳速率低速率低案例三：海斯案例三：海斯終終端無法搜網端無法搜網案例五：案例五：遠見遠見智能第智能第1小區(qū)下小區(qū)下載載速率偏低速

9、率偏低問題問題案例六：室分小區(qū)隨機接入失案例六：室分小區(qū)隨機接入失敗敗案例七：基站有信號，案例七：基站有信號，Attach不成功不成功案例四：海斯案例四：海斯終終端端ATTCH 失失敗敗案例八：參數配置案例八：參數配置導導致切致切換換失失敗敗案例四：海斯終端案例四：海斯終端ATTCH 失敗，出現失敗，出現EPS attach failedu【現象描述】最近在測試過程中，經常出現hisi終端無法進行attach業(yè)務和ping 服務器無法到達的情況，具體表現為發(fā)起attach業(yè)務時在信令中出現EPS Attach failedu【問題分析】海斯終端鑒權與網絡不同步u【解決方案】通過sscom32在

10、hisi終端的bluetooth口發(fā)送命令，將hisi終端的鑒權與基站側的鑒權進行同步。設備連接后，通過sscom32打開終端的bluetooth端口，發(fā)送命令：g_ulSmcControl=1，點擊發(fā)送后，鼠標移至運行窗口按enter，返回值value = 1即表示操作成功，然后關閉bluetooth端口，如下圖所示。案例一：長河水產市場下載速度低案例一：長河水產市場下載速度低案例九：修正案例九：修正測試規(guī)測試規(guī)范范BF Gain計計算公式算公式案例二：案例二：濱濱江江電電力公司上力公司上傳傳速率低速率低案例三：海斯案例三：海斯終終端無法搜網端無法搜網案例五：案例五：遠見遠見智能第智能第1小

11、區(qū)下小區(qū)下載載速率偏低速率偏低問題問題案例六：室分小區(qū)隨機接入失案例六：室分小區(qū)隨機接入失敗敗案例七：基站有信號，案例七：基站有信號，Attach不成功不成功案例四：海斯案例四：海斯終終端端ATTCH 失失敗敗案例八：參數配置案例八：參數配置導導致切致切換換失失敗敗案例五：遠見智能第案例五：遠見智能第1小區(qū)下載速率偏低問題小區(qū)下載速率偏低問題u【現象描述】在遠見智能基站1小區(qū)下載速率偏低（20Mbps), RSRP很高，下行SINR很好，MCS偏低，16QAM比例很高、BLER很低?！締栴}分析】 關閉ATB/UL PC等問題依然存在。關閉遠見智能第2、3小區(qū)問題依然存在；初步分析問題不是由于干

12、擾問題，檢查SCF文件發(fā)現DLTARGETBLER設置為1%，可能與此有關，由于BLER要求太高，OLLA會調低MCS以保證BLER目標，而對于FTP等業(yè)務不需要如此高的BLER要求，并且會導致不能夠使用高階MCS及64QAM，從而導致下載速率偏低。u【解決方案】將第1小區(qū)恢復成DLTARGETBLER=10%。案例一：長河水產市場下載速度低案例一：長河水產市場下載速度低案例九：修正案例九：修正測試規(guī)測試規(guī)范范BF Gain計計算公式算公式案例二：案例二：濱濱江江電電力公司上力公司上傳傳速率低速率低案例三：海斯案例三：海斯終終端無法搜網端無法搜網案例五：案例五：遠見遠見智能第智能第1小區(qū)下小區(qū)

13、下載載速率偏低速率偏低問題問題案例六：室分小區(qū)隨機接入失案例六：室分小區(qū)隨機接入失敗敗案例七：基站有信號，案例七：基站有信號，Attach不成功不成功案例四：海斯案例四：海斯終終端端ATTCH 失失敗敗案例八：參數配置案例八：參數配置導導致切致切換換失失敗敗案例六：室分小區(qū)隨機接入失敗u【現象描述】室分小區(qū)隨機接入失敗。1.在室分主測小區(qū)切換或者初始接入時，經常會有切換失敗或者attch失敗，現象為PRACH上行同步次數較多，且PRACH的功率會逐漸攀升到滿功率23dbm。CDS軟件會提示定時器T304或T300超時。如圖2.反切失敗。室分主測小區(qū)PCI：336向同層同頻的PCI:337切換正

14、常，但是經過海量測試發(fā)現PCI:337向PCI:336失敗率高?，F象和上圖中PRACH接入問題相同。室分小區(qū)隨機接入失敗u【問題分析】懷疑定時器設置或者切換參數問題，但是核查參數發(fā)現336和337的定時器設置相同，切換參數也相同，故排除定時器設置和切換參數問題； 懷疑無線環(huán)境問題，336小區(qū)和337小區(qū)做的是同層的2個小區(qū)，在同層測試RSRP/RSRQ/SINR都比較好，排除無線環(huán)境問題； 懷疑隨機接入參數設置有問題，由于336向337切換都正常而反向切換337向336會出現失敗，因此對比這兩個小區(qū)的PRACH參數，發(fā)現prachConfigIndex參數不同。將336小區(qū)的prachConf

15、igIndex從51修改到3，多次測試切換成功率和接入成功率明顯提高。進一步定位發(fā)現海思終端在prachConfigIndex=51(preamble format 4)時隨機接入的成功率較低。室分小區(qū)隨機接入失敗u【解決方案】 prachConfigIndex與preamble format對應表如下：prachConfigIndex=51時，對應的preamble format為4，prachConfigIndex=3時，對應的preamble format為0。室分小區(qū)隨機接入失敗u【解決方案】preamble format 4時PRACH在UPPTS發(fā)送，這種格式的CP時域長度和Seq

16、uence的時域長度都比preamble format 0小很多，被基站成功解調的幾率也小很多，所以選擇format 0會比選擇format 4切換成功率高。因此修改參數prachConfigIndex從51修改到3。問題解決。preamble format 規(guī)范定義的格式如下：案例一：長河水產市場下載速度低案例一：長河水產市場下載速度低案例九：修正案例九：修正測試規(guī)測試規(guī)范范BF Gain計計算公式算公式案例二：案例二：濱濱江江電電力公司上力公司上傳傳速率低速率低案例三：海斯案例三：海斯終終端無法搜網端無法搜網案例五：案例五：遠見遠見智能第智能第1小區(qū)下小區(qū)下載載速率偏低速率偏低問題問題案例

17、六：室分小區(qū)隨機接入失案例六：室分小區(qū)隨機接入失敗敗案例七：基站有信號，案例七：基站有信號，Attach不成功不成功案例四：海斯案例四：海斯終終端端ATTCH 失失敗敗案例八：參數配置案例八：參數配置導導致切致切換換失失敗敗27 Nokia Siemens Networks案例七：基站有信號，案例七：基站有信號，Attach不成功不成功u【問題描述】在下沙頂新1小區(qū)下做業(yè)務，從CDS軟件中觀察主服務小區(qū)有信號，但是無論做Attach，ping，upload，download業(yè)務，均不成功u【問題分析】懷疑測試終端問題，重啟海思終端，拔插SIM卡，問題依然存在；懷疑為Windows系統(tǒng)問題，重啟

18、電腦，重新接入，仍未解決；懷疑基站問題，更換至其他小區(qū)測試測試，業(yè)務正常，定位為小區(qū)問題。28 Nokia Siemens Networksu【解決方案】聯(lián)系排障組上站排查，發(fā)現該小區(qū)主BBU上的第二個FSP下的3個CPU全部DOWN掉，導致無法做業(yè)務，但是小區(qū)有信號； 排障組對該小區(qū)的主BBU進行斷電重啟，5分鐘后基站側觀察該小區(qū)BBU狀態(tài)，模塊均恢復正常，使用海思終端在該小區(qū)下做業(yè)務，業(yè)務可以做且均成功基站有信號，基站有信號，Attach不成功不成功案例一：長河水產市場下載速度低案例一：長河水產市場下載速度低案例九：修正案例九：修正測試規(guī)測試規(guī)范范BF Gain計計算公式算公式案例二：案例

19、二：濱濱江江電電力公司上力公司上傳傳速率低速率低案例三：海斯案例三：海斯終終端無法搜網端無法搜網案例五：案例五：遠見遠見智能第智能第1小區(qū)下小區(qū)下載載速率偏低速率偏低問題問題案例六：室分小區(qū)隨機接入失案例六：室分小區(qū)隨機接入失敗敗案例七：基站有信號，案例七：基站有信號，Attach不成功不成功案例四：海斯案例四：海斯終終端端ATTCH 失失敗敗案例八：參數配置案例八：參數配置導導致切致切換換失失敗敗案例八：參數配置導致切換失敗案例八：參數配置導致切換失敗u【現象描述】測試中UE由LTE_下沙聯(lián)華1小區(qū)（PCI:49)向LTE_下沙聯(lián)華3小區(qū)(PCI:50)切換失敗，如下圖所示：LOG分析，UE

20、在四號大街由東向西行駛，占用LTE_下沙聯(lián)華1（PCI:49）UE上發(fā)測量報告，目標小區(qū)為LTE_下沙聯(lián)華3（PCI:50），當RSRP相差10db仍未發(fā)生切換，1秒后出現“HandOver Failed” 。u【問題分析】 核查切換參數：配置正確無問題；核查鄰區(qū)配置：均已配置；懷疑設備問題，重啟設備，復測問題依舊；嘗試重新配置鄰區(qū)：刪除原鄰區(qū)配置，重新添加雙向鄰區(qū)，進行復測，切換關系正常，如下圖所示：u【解決方案】重新核查參數，發(fā)現鄰區(qū)配置參數存在問題。正常鄰區(qū)配置參數如下：eNodeB IP，eNB id，MCC，MNC，MNC length in PLMN，如21 7

21、19204 460 8 2 存在問題的鄰區(qū)配置參數如下：9 0 0 0 2 9 05 2 06 21 719204 460 8 2 23 739204 460 8 2 39由于前期工程部門配置鄰區(qū)參數存在問題，需要重新正確配置。參數配置導致切換失敗創(chuàng)毅視訊終端切換失敗創(chuàng)毅視訊終端切換失敗u【現象描述】 采用創(chuàng)毅視訊終端，在下沙聯(lián)華_1與文苑風情_2小區(qū)之間，進行FTP下載測試時，創(chuàng)毅視訊終端無法成功切換至文苑風情_2。而導致FTP掉線。u【問題分析】 切換

22、失敗，可能由以下幾方面產生：軟件、終端、測試電腦等。網絡問題（包括覆蓋、干擾、鄰區(qū)、基站狀態(tài)等）問題發(fā)生時，小區(qū)覆蓋、干擾均正常，主要考慮軟件、終端及鄰區(qū)等方面。檢查小區(qū)狀態(tài)和配置：向后臺查詢這兩個小區(qū)狀態(tài)，鄰區(qū)情況，發(fā)現均正常。懷疑PDCCH DCI格式問題：已知創(chuàng)毅視訊終端的一個bug，創(chuàng)毅視訊終端只支持PDCCH DCI格式為1A ，懷疑小區(qū)PDCCH DCI格式未配置為1A導致切換失敗。向后臺查詢這兩個小區(qū)PDCCH DCI格式，反饋這兩個小區(qū)均配置為1A。懷疑終端和電腦問題：更換另一個創(chuàng)毅視訊終端、更換SIM卡、重啟電腦重新測試，發(fā)現問題依舊。懷疑基站問題：重新啟動基站，并再次修改文

23、苑風情_2 PDCCH DCI格式為1A后，重新測試，切換正常。創(chuàng)毅視訊終端切換失敗u【解決方案】 DCI: Downlink Control Information ，承載在PDCCH上。Format 1C:緊湊型單碼字PDSCH調度。Format 1A: 用于下行傳輸，單碼字PDSCH調度，下行數據觸發(fā)隨機接入過程。目前，海思終端對于上述兩種格式均支持，而創(chuàng)毅視訊終端只支持1A格式，由于此格式問題，會導致UE無法接入網絡，導致重選失敗、切換失敗等問題?；颈恢貑⒑螅揇CI格式將恢復到1C的默認值，需要重新修改為1A，特殊情況，小區(qū)顯示DCI格式為1A，但是并沒有生效，需要重啟小區(qū)，重新修

24、改PDCCH DCI格式才生效。創(chuàng)毅視訊終端切換失敗案例一：長河水產市場下載速度低案例一：長河水產市場下載速度低案例九：修正案例九：修正測試規(guī)測試規(guī)范范BF Gain計計算公式算公式案例二：案例二：濱濱江江電電力公司上力公司上傳傳速率低速率低案例三：海斯案例三：海斯終終端無法搜網端無法搜網案例五：案例五：遠見遠見智能第智能第1小區(qū)下小區(qū)下載載速率偏低速率偏低問題問題案例六：室分小區(qū)隨機接入失案例六：室分小區(qū)隨機接入失敗敗案例七：基站有信號，案例七：基站有信號，Attach不成功不成功案例四：海斯案例四：海斯終終端端ATTCH 失失敗敗案例八：參數配置案例八：參數配置導導致切致切換換失失敗敗36

25、 Nokia Siemens Networksu【問題描述】按照中國移動測試規(guī)范STT-3-2-1 TD-LTE規(guī)模技術試驗-六城市測試-多天線測試規(guī)范 v1.7.2，BF Gain是采用的DRS_RSRP CRS_RSRP，沒有指明CRS-RSRP是在哪種傳輸模式下。 使用BF Gain=DRS_RSRP_TM7 CRS_RSRP_TM2計算，增益為10 dB左右，而正常值=6dB 使用BF Gain=DRS_RSRP_TM7 CRS_RSRP_TM7計算， 增益為5dB左右，正常u【問題分析】 DRS_RSRP：專門用于BF的，也就是在TM7的時候，當用戶打上業(yè)務后，才有DRS。存在于用戶分配到的PDSCH的RB上。 CRS-RSRP：是指Cell-specific reference signal。在系統(tǒng)頻帶內的任一個RB上都有CRS，用于測量。無論系統(tǒng)是TM2還是TM7，是否有業(yè)務都有CRS。 查看TM500數據統(tǒng)計：DRS_RSRP_TM7統(tǒng)計的是100個RB上的平均值CRS_RSRP_TM2統(tǒng)計的是中心6個RB上的平均值CRS_RSRP_TM7統(tǒng)