聯(lián)通lte問題案例庫(kù)nokia廠家

1、湖南LTE 問題案例庫(kù)目錄湖南LTE 問題案例庫(kù)11網(wǎng)絡(luò)相關(guān)原因21.11.21.31.41.54G 用戶被叫時(shí)被提示用戶忙或者轉(zhuǎn)至 1161142GGSN6 雙承載無(wú)法上網(wǎng)問題3SGW restartcounter 變化導(dǎo)致用戶無(wú)法被叫問題4SGSN 修改 4G PDP context CC 字段導(dǎo)致第一次 TAU 失敗問題5SGW PDEL TIME 超時(shí)導(dǎo)致用戶無(wú)法被叫，需升級(jí) MME解決72終端原因82.12.2CSFB 后無(wú)法FR，參數(shù)調(diào)整解決8登陸 4G 網(wǎng)絡(luò)，頻繁出現(xiàn)無(wú)法做被叫的情況，終端側(cè)設(shè)置 3GNET長(zhǎng)沙酷派雙承載為 WONET 解決。132.3蘋果設(shè)置“勿擾模式”導(dǎo)致做被

2、叫無(wú)法接通153優(yōu)化原因183.13.23.33.4CSFB 無(wú)法正?；芈?8不同運(yùn)營(yíng)商相同頻段致使網(wǎng)未做 TAC 和 LAC導(dǎo)致無(wú)法駐留問題22長(zhǎng)沙4G 無(wú)法做被叫，無(wú)線參數(shù)調(diào)整解決23LAC 邊界用戶語(yǔ)音回落被叫無(wú)應(yīng)答問題，開啟 MTRF 解決271 網(wǎng)絡(luò)相關(guān)原因1.1 4G 用戶被叫時(shí)被提示用戶忙或者轉(zhuǎn)至 116114問題現(xiàn)象:通過用戶，發(fā)現(xiàn)某些用戶在 4G 網(wǎng)絡(luò)做被叫的時(shí)候會(huì)提示用戶忙或者被轉(zhuǎn)至116114 的提示。具體分析：為了確認(rèn)是用戶無(wú)法被叫的具體原因，進(jìn)行 IPDU 抓包測(cè)試分析。通過 IPDU 抓包 log 分析，發(fā)現(xiàn)兩種現(xiàn)象1）主叫提示被叫忙：MSC 發(fā)送 paging 消

3、息給 MME，MME 立即回復(fù) reject cause=imsi detach for eps servi，并未向 eNB 發(fā)送任何消息with2）轉(zhuǎn)接至 116114：MSC 發(fā)送 paging 消息給 MME，MME 立即回復(fù) rejectwithcause=moobile termination cs fallback call rejected by the user，并未向 eNB 發(fā)送任何消息查看被叫在 MME 的狀態(tài)，并無(wú)異常，設(shè)備無(wú)異常告警查看整個(gè)呼叫流程，并未發(fā)現(xiàn)信令的異常收集 MME 相關(guān)log 及配置信息提交研發(fā)根本原因:當(dāng)前系統(tǒng)對(duì)于 UE 在 idle 和 conne

4、ct 狀態(tài)轉(zhuǎn)換時(shí)錯(cuò)誤，造成 CSFB 失敗解決措施：升級(jí)問題與結(jié)論：通過對(duì)于系統(tǒng)轉(zhuǎn)換時(shí)會(huì)發(fā)生log 分析發(fā)現(xiàn)，當(dāng)前系統(tǒng)對(duì)于 UE 在 IDLE 和 Connect 狀態(tài)錯(cuò)誤，對(duì)于 UE 的當(dāng)前狀態(tài)判斷有誤，從而對(duì)于 MSC 發(fā)起的 CSFB被叫的 Paging 消息響應(yīng)錯(cuò)誤，導(dǎo)致 CSFB 被叫失敗。該問題屬于當(dāng)前版本(NS30)bug，需要升級(jí)解決。1.2 GGSN6 雙承載無(wú)法上網(wǎng)問題問題現(xiàn)象：通過用戶，發(fā)現(xiàn)當(dāng) UE 在 4G 網(wǎng)絡(luò)進(jìn)行發(fā)送彩信時(shí)，當(dāng) WAP 的 APN 是在 GGSN6 建立時(shí)，承載無(wú)法建立，最終彩信發(fā)送失敗。具體分析：1，為確認(rèn) WAP 的APN 無(wú)法建立，在GGSN6

5、 上進(jìn)行抓包測(cè)試2，在 SAEGW 上進(jìn)行信令測(cè)試，并進(jìn)行大量彩信發(fā)送測(cè)試3，當(dāng)直接用 3gwap 附著網(wǎng)絡(luò)建立承載時(shí)，彩信測(cè)試無(wú)失敗4，當(dāng)用非 wap 的apn 附著網(wǎng)絡(luò)建立承載，彩信發(fā)送可能出現(xiàn)失敗5，繼續(xù)測(cè)試發(fā)現(xiàn)，非 wap apn 附著網(wǎng)絡(luò)建立承載，并且發(fā)送彩信時(shí)建立的第二條承載都落在 NG6 上時(shí)，發(fā)送失敗6，查看 NG6 的信令結(jié)果，發(fā)現(xiàn)彩信發(fā)送失敗是的 3gwap 承載建立過程信令異常，正常情況下 S-GW 和 P-GW 選在同臺(tái)設(shè)備時(shí) S5 口信令不應(yīng)該能看到才對(duì)，并且在 S11 口的信令交換也是異常的7，因NG6 剛完成 NG3.1 的升級(jí)，并且使用了新功能 single a

6、ddres，懷疑 NG31 的問題根本原因：經(jīng)研發(fā)對(duì)日志及消息 log 分析，確認(rèn)該問題屬于 single address 功能與 service group 功能產(chǎn)生，導(dǎo)致承載建立失敗解決措施：當(dāng)前版本(NG3.1)下取消 single address 功能的使用問題與結(jié)論原因是 Single address mode 的負(fù)載均衡需要在 node 之間轉(zhuǎn)發(fā)信令和業(yè)務(wù)數(shù)據(jù)，node 之間相互轉(zhuǎn)發(fā)消息是基于 TEID。在同一個(gè) service group 中的node 對(duì)于同一個(gè)用戶無(wú)法通過原因是Single address mode 的負(fù)載均衡需要在 node 之間轉(zhuǎn)發(fā)信令和業(yè)務(wù)數(shù)據(jù)，node

7、 之間相互轉(zhuǎn)發(fā)消息是基于TEID。在同一個(gè) service group 中的 node 對(duì)于同一個(gè)用戶無(wú)法通過。1.3SGW restartcounter 變化導(dǎo)致用戶無(wú)法被叫問題問題現(xiàn)象：通過用戶具體分析：，發(fā)現(xiàn)部分用戶在 4G 網(wǎng)絡(luò)下被叫失敗1）在進(jìn)行 CSFB MT 多次測(cè)試進(jìn)行問題復(fù)現(xiàn)發(fā)現(xiàn)：發(fā)現(xiàn) MME 會(huì)主MSC 發(fā)送EPS Detach 消息，將該 UE 進(jìn)行 Detach 操作2）當(dāng)發(fā)生 detach 后，若 UE 主動(dòng)發(fā)起業(yè)務(wù)請(qǐng)求，會(huì)發(fā)生第一次 ServiceRequest 失敗，重新進(jìn)行attach 到網(wǎng)絡(luò)，進(jìn)而進(jìn)行業(yè)務(wù)操作，此時(shí) CSFB MT 正常。3）當(dāng)發(fā)生 detac

8、h 后，若 UE 不主動(dòng)進(jìn)行業(yè)務(wù)請(qǐng)求，此時(shí) UE 一直處于 detached 狀態(tài)，若有其它 UE 呼叫時(shí)，MME 會(huì)直接MSC 發(fā)送的Paging 消息，導(dǎo)致 CSFB MT失敗。4）查看系統(tǒng)告警日志，發(fā)現(xiàn)在發(fā)生 MME 主動(dòng)發(fā)起EPS detach 的動(dòng)作時(shí)，系統(tǒng)有 221的告警，并且此時(shí) S1 接口伴有大量的 MME 發(fā)起的 detach 消息。根本原因：SGW 發(fā)往 MME 的GTP 消息中帶有RestartCounter 字段發(fā)生變化導(dǎo)致 MME 認(rèn)為SGW發(fā)生重啟（AHP 會(huì)看到大量 Notice=221），進(jìn)而進(jìn)行刪除與該 SGW 相關(guān)的用戶信息，處于連接態(tài)的會(huì)要求重新 Atta

9、ch，對(duì)于 Idle 態(tài)的，按照隱式去附著處理，所以當(dāng)作為被叫時(shí)，MME 直接原因是隱式去附著，只有 UE 主動(dòng)發(fā)起業(yè)務(wù)才能重新 attach 到網(wǎng)絡(luò)，業(yè)務(wù)恢復(fù)解決措施：臨時(shí)解決：諾基亞 MME 通過修改，對(duì)于SGW 導(dǎo)致的 Restart 不對(duì)用戶進(jìn)行detach 處理最終解決：SGW 進(jìn)行升級(jí)問題與結(jié)論：SGW 發(fā)往 MME 的GTP 消息中帶有RestartCounter 字段發(fā)生變化導(dǎo)致 MME 認(rèn)為SGW發(fā)生重啟（AHP 會(huì)看到大量 Notice=221），因諾基亞 MME 對(duì)于收到 SGW 重啟的消息后，默認(rèn)進(jìn)行刪除與該SGW 相關(guān)的用戶信息，處于連接態(tài)的會(huì)要求重新 Attach，

10、對(duì)于 Idle 態(tài)的，按照隱式去附著處理，所以當(dāng)作為被叫時(shí)，MME 直接原因是隱式去附著，只有 UE 主動(dòng)發(fā)起業(yè)務(wù)才能重新attache 到網(wǎng)絡(luò)，業(yè)務(wù)恢復(fù)1.4 SGSN 修改 4G PDP context CC 字段導(dǎo)致第一次 TAU失敗問題問題現(xiàn)象：網(wǎng)優(yōu)同事在進(jìn)行日常測(cè)試時(shí)發(fā)現(xiàn)，經(jīng)常出現(xiàn) TAU 失敗的現(xiàn)象。具體分析：1）針對(duì)網(wǎng)優(yōu)同事發(fā)現(xiàn)的 UE TAU 到 4G 時(shí)會(huì)出現(xiàn) TAU Reject，并且失敗率很高，隨之進(jìn)行問題2）做多次 TAU 測(cè)試后，對(duì)信令消息解讀發(fā)現(xiàn)，當(dāng) SGW 選在的 SAEGW 時(shí)，一定會(huì)失敗，UE 必須重新attach，當(dāng)Nokia 的 SAEGW 時(shí)，則成功3）

11、測(cè)試發(fā)現(xiàn)SGW 響應(yīng) MME 的 CreateSesResponse 消息中沒有承載信息4）查看整個(gè)信令過程，發(fā)現(xiàn) UE TAU 時(shí)消息中的 cc 字異常，值為 0，并不是 HSS 所簽約的數(shù)據(jù)，根據(jù)整個(gè) 3/4G 切換流程懷疑諾基亞 SGSN 對(duì) cc 字段處理有問題，發(fā)現(xiàn)該字段在從 3G 回到 4G 時(shí)被 SGSN 變?yōu)?0，5）隨后與SAEGW 對(duì)于 CC 字段要求嚴(yán)格，0Request 進(jìn)行工程師進(jìn)行該問題確認(rèn)，得到結(jié)論為字段，所以SAEGW 會(huì)對(duì) CreateSes根本原因：當(dāng)前 MME版本(NS30)在 UE 進(jìn)行erSystem 切換后，對(duì)于 CC 字段的處理有誤。解決措施：進(jìn)行

12、系統(tǒng)升級(jí)問題與結(jié)論：當(dāng)前 MME版本(NS30)在 UE 進(jìn)行erSystem 切換后，對(duì)于 CC 字段的處理有誤，導(dǎo)致無(wú)法正確將 UE 的簽約數(shù)據(jù)中的 CC 值進(jìn)行轉(zhuǎn)發(fā)，因SGW 對(duì)于 CC 字段的處理機(jī)制有諾基亞 SGW 的處理機(jī)制（對(duì)于 cc=0 時(shí)會(huì)用系統(tǒng)配置的默認(rèn) cc 值進(jìn)行覆蓋），對(duì)于 cc=0直接進(jìn)行處理，導(dǎo)致 TAU 失敗。1.5 SGW PDMMEEL TIME 超時(shí)導(dǎo)致用戶無(wú)法被叫，需升級(jí)解決問題現(xiàn)象:發(fā)現(xiàn) 4G 被叫問題，通過查詢用戶經(jīng)常自動(dòng)掉至 3G 網(wǎng)絡(luò)，再回落最近有用戶至 4G 網(wǎng)絡(luò)。 最后就不能做 4G 被叫了具體分析：1、通過用戶信令，發(fā)現(xiàn)當(dāng)用戶激活后，長(zhǎng)時(shí)間

13、無(wú)上下行流量時(shí)超過 30 分鐘后，到達(dá)諾基亞 SGW PDP IDEL TIME 時(shí)， SGW 踢掉該用戶。 此時(shí) MME 會(huì)向用戶發(fā)起DetachRequest(type=2,cause=re-attach not required。此時(shí)用戶會(huì)短暫的回落至 3G，大約 1-2分鐘后，會(huì)回落至 4G。查看此時(shí)用戶在 MME 中的狀態(tài)發(fā)現(xiàn) TAI 信息異常,為 4 個(gè)F。2、通過 MME信令分析：被 MME 踢掉后，短暫回落至 3G 后，重新 attach 到 4G MME 時(shí)，會(huì)從老的 sgsn取 context 信息。在此過程中，MME 的 MMDU 單元錯(cuò)誤的用取到的數(shù)據(jù)覆蓋attach

14、時(shí)帶上來(lái)的 tai 數(shù)據(jù)(把它置為F)，然后 CPPU 處理 SGS-PAGING 時(shí)，從 MMDU 里取出錯(cuò)誤的 TAI(F)，再轉(zhuǎn)發(fā)給 IPDU，IPDU 向外轉(zhuǎn)發(fā) paging 消息時(shí)，會(huì)檢查 paging 消息里的TAI 字段，以決定向那些 ENB 發(fā)送，當(dāng) IPDU 發(fā)現(xiàn) TAI 字段為F 時(shí)，就會(huì)丟棄 paging消息，導(dǎo)致4G 被叫失敗。根本原因:研發(fā)分析確認(rèn)在 SGW PDP 老化時(shí)間到了后向 MME 發(fā)起用戶去附著操作，如果用戶回落到 3G，再次向 4G 發(fā)起 TAU 時(shí)，由于會(huì)更換 MME,新的 MME 在數(shù)據(jù)庫(kù)內(nèi)沒能正確填寫TAC 信息，導(dǎo)致 MSC 發(fā)向 MME 的尋呼

15、無(wú)法下發(fā)到用戶所在的 TAC,因而導(dǎo)致無(wú)法被叫。解決措施：新版補(bǔ)丁 NS3.0 CD4001CM 內(nèi)含有該問題的補(bǔ)丁。1 月 23 日凌晨已經(jīng)完成 2 臺(tái)MME 升級(jí)，2 月 5 日將完成所有湖南8 臺(tái) MME 升級(jí)，屆時(shí)將徹底解決本問題。2 終端原因CSFB 后無(wú)法 FR，參數(shù)調(diào)整解決2.1 長(zhǎng)沙問題現(xiàn)象:近日接到長(zhǎng)沙運(yùn)維反饋部分三星 S3、5 等出現(xiàn)在 CSFB 到 3G 進(jìn)行語(yǔ)音后不回 4G 的現(xiàn)象。使用三星 9305也出現(xiàn)了相同情況：在通過PSHO 的CSFB 從 4G 回落 3G 后后出現(xiàn)了沒能觸發(fā)Fast Return 的情況，致使不返回 4G 網(wǎng)絡(luò)。具體分析：針對(duì)以上情況，應(yīng)客戶

16、要求將 CSFB 的方式由 PSHO 改為 R8 重定向:重定向的 CSFB，后可以觸發(fā) FR 回 4G，初步解決了問題。根本原因:從LOG 分析中看到主要問題來(lái)自UE。在 PSHO 的 CSFB 過程中，在Relocation Request 里面，包含了 UE 所支持的 LTE band 信息。v860NonCriticalExtens erRAndoverInfoWith erRATCapabilities-v860ext ue-RATSpecificCapability eutra-RadioAcsCapability ue-EUTRA-Capability 81 20 00 00 0

17、8 04 08 7E BE 1F B9 01 10 00 04 74 A8H但是當(dāng) RNC 查詢 UE 能力信息時(shí)，UE 沒有上報(bào)它所支持的LTE band 信息。244RRC:UeCapabilityEnquiry 249-14:37:51.65RRC:UeCapabilityInformation14:37:51.81這樣會(huì)讓 RNC 認(rèn)為 UE 是不支持 LTE 的，從而沒有觸發(fā) fast return 的流程。而在 R8 的過程中，由于需要重新建立 RRC 連接，UE 總是能夠正確的上報(bào) LTE 能力信息的。解決措施：諾基亞 RNC 有針對(duì) Smart Layer (FAST RETU

18、RN) 的 PRFILE parameter 002:1916PARAMETER CLASS: 2SYSTEM_FUNCT_CONFIGURIDENTIFIERNAME OF PARAMETERVALUEYESCHANGESIBILITY01916RN60_MA_410第二位字節(jié)，定義了是否檢查重定向回 LTE 網(wǎng)絡(luò)的UE 能力這個(gè)參數(shù)的修正，可以從根本上解決部分終端在 PSHO 的 CSFB 后不能 FR 回 4GValueoftheparameter002:1916RN60_MA_41 1)Descriptionx0 x (default)Redirection can be done o

19、nly to LTE frequency t belongs to LTE band t is indicated to be supported by the UE.x1xLTE frequency is not checked against LTE bands supported by the UE.在參數(shù)開啟后，通過 PSHO 的 CSFB 回落 3G 的 S34G，沒有上報(bào) 4G 能力，也能重定向回使用多款測(cè)試了許多次，沒有出現(xiàn)無(wú)法 FR 的現(xiàn)象。問題與結(jié)論：目前使用重定向的 CSFB ，可以初步解決CSFB后不能觸發(fā) Fast Return 的情況最終，還是建議使用 PSHO 的

20、CSFB，因?yàn)樗梢员ＷC在 3G 網(wǎng)絡(luò)的通話質(zhì)量。同時(shí)需要開啟 3G RNC 的 PRFILE parameter 002:1916 ： 0110這樣可以忽略能力，保證這些終端能夠觸發(fā) FR 回 4G 。2.2 酷派雙承載登陸 4G 網(wǎng)絡(luò)，頻繁出現(xiàn)無(wú)法做被叫的情況，終端側(cè)設(shè)置 3GNET 為 WONET 解決。問題現(xiàn)象:岳陽(yáng)發(fā)現(xiàn)酷派登陸 4G 網(wǎng)絡(luò)，頻繁出現(xiàn)不能被叫的情況。而在相同的環(huán)境下測(cè)試，其他終端未出現(xiàn)類似情況。具體分析：為了查明酷派在 4G 網(wǎng)絡(luò)中頻繁出現(xiàn)不能被叫，在諾基亞的 MME 中了酷派的完整信令發(fā)現(xiàn)如下問題：1、端。登陸 4G 網(wǎng)絡(luò)時(shí)上網(wǎng)時(shí)，存在兩個(gè)APN，WONET 和 3G

21、NET?？崤墒请p承載終2、當(dāng)因?yàn)樽霰唤?，CSFB 至 3G 網(wǎng)絡(luò)后，重新回落至 4G 時(shí)，酷派發(fā)起的 TAU 請(qǐng)求消息中缺失了 3GENT 這個(gè) APN，只有WONET 一個(gè) APN。發(fā)起的 Tracking area update request 消息中 EBI=6（3GNET）是 inactive 的。發(fā)起的 Tracking area update request 消息中 EBI=5（WONET）是 active 的。3、而后續(xù) 3G SGSN 向 4G MME SGSN CONTEXT RESPONSE 消息中可以看到是有兩個(gè)APN，即WONET 和 3GNET。4、因 TAU 消息中

22、 EBI=6 是 INACTIVE，MME 后續(xù)發(fā)起對(duì) EBI=6 的 delete消息，即刪除 3GNET 這個(gè) PDP CONTEXT。sesrequest5、但是最還是以 3GNET APN 來(lái)建立PDN 連接，因 MME 中已經(jīng)沒有 3GNET 這個(gè)APN了，所以承載建立就失敗了。最終終端不能正常的回落到 4G。根本原因:終端從 3G 回落 4G 過程中，發(fā)起的 TAU 請(qǐng)求信令中異常的丟失了 3GENT 這個(gè)APN，而后在建立 PDN 連接中，卻又使用 3GNET APN 建立默認(rèn)承載，導(dǎo)致默認(rèn)承載建立失敗。最終不能正常的回落到 4G，導(dǎo)致 4G 被叫失敗。解決措施：因酷派是雙承載終

23、端，在終端設(shè)置APN 處,把 3GNET 設(shè)置為WONET。上網(wǎng)時(shí)就只激活WONET 一個(gè) APN，避免在 TAU 過程中丟失 APN，最終避免 4G 被叫問題。2.3 蘋果設(shè)置“勿擾模式”導(dǎo)致做被叫無(wú)法接通問題現(xiàn)象:1 月初省公司某位話。反饋，在開會(huì)期間有幾個(gè)人打他，均沒有接到電具體分析：通過調(diào)取當(dāng)時(shí)的博瑞德的分析發(fā)現(xiàn)，主叫呼叫了早釋。全部正常，在被叫階段用戶進(jìn)行核查被叫階段的博瑞德呼叫，從上可以看到，被叫呼叫信令正常，但在Alerting 后1 秒鐘收到對(duì)端發(fā)來(lái)的 Disconnect 消息，消息的原因?yàn)椤癠ser busy”。用戶忙測(cè)試現(xiàn)象通過模擬設(shè)置并測(cè)試分析發(fā)現(xiàn)，蘋果有“勿擾模式”設(shè)

24、置。當(dāng)設(shè)置成：手動(dòng)啟用該模式；同時(shí)選定好靜音模式開的設(shè)定時(shí)間（如從 XX 點(diǎn)到 XX 點(diǎn)之間開啟靜音模式）；設(shè)置是否啟動(dòng)重復(fù)來(lái)電則不設(shè)置為靜音的選擇（啟用后，相同來(lái)電者在三分鐘內(nèi)的第二個(gè)來(lái)電不會(huì)被設(shè)為靜音）；靜音模式選擇是總是還是僅當(dāng)啟用。已鎖定時(shí)當(dāng)你有撥”，而你在你設(shè)置的設(shè)定時(shí)間內(nèi)打進(jìn)來(lái)時(shí)，對(duì)方會(huì)聽到“對(duì)不起用戶正忙，請(qǐng)稍后再機(jī)不會(huì)直接在上顯示有未接來(lái)電；如果在三分鐘內(nèi)第二次撥打你的，則能正常接通。如果三分鐘后第二次撥打你的，則與第一次撥打的提示一樣。由于不響鈴，只是在上顯示未接來(lái)電的提示，導(dǎo)致用戶感覺沒有接打成功。問題與結(jié)論：根本原因?yàn)橹悄芸贫巳缣O果有“勿擾模式”設(shè)置，只要用戶開啟該模式后

25、，有主叫用戶撥打該后，被叫系統(tǒng)會(huì)在主叫接通后會(huì)自動(dòng)進(jìn)行，所以主叫提示為“對(duì)不起用戶正忙，請(qǐng)稍后再撥”，但實(shí)際上整個(gè)呼叫已正常建立。如果在設(shè)定的時(shí)間內(nèi)撥打二個(gè)，則系統(tǒng)不會(huì)主動(dòng)。3 優(yōu)化原因3.1 不同運(yùn)營(yíng)商相同頻段致使CSFB 無(wú)法正?；芈鋯栴}現(xiàn)象:1 月 6 日湘潭韶山永義、區(qū)域陸續(xù)有個(gè)別用戶反映在鎮(zhèn)上偶爾能占用上 4G，但上網(wǎng)速率很慢，在 4G 拔打后無(wú)法占用 4G 的情況，過很長(zhǎng)時(shí)間才能回落至4G，而在韶山縣城區(qū)域無(wú)此問題。反映的區(qū)域如下：具體分析：為了確認(rèn)是用戶回落 4G 問題，核查如下：永義、為湘潭鄉(xiāng)鎮(zhèn)站點(diǎn)，入網(wǎng)較早，在 11 月就已入網(wǎng)，對(duì)兩站的單站驗(yàn)證過程中，上網(wǎng)速率與 CSFB

26、回落都正常，由于近期 LTE 未進(jìn)行割接及其它操作，因此 LTE 側(cè)的參數(shù)可以確保正常；查看 LTE 的運(yùn)行狀態(tài)及告警情況，未發(fā)現(xiàn)異常情況。由于兩站為覆蓋鄉(xiāng)鎮(zhèn)站點(diǎn)，日常用戶較少，檢查兩站的運(yùn)行指標(biāo)也未發(fā)現(xiàn)異常；區(qū)域近期新開了 W 站點(diǎn)，通知 W 優(yōu)化，對(duì) 3G 關(guān)于 LTE 的參數(shù)及開關(guān)核查，反饋W 方面無(wú)問題；通過以上核查，未找出具體原因，需現(xiàn)象測(cè)試，以確定的真實(shí)性及問題產(chǎn)生的原因。網(wǎng)優(yōu)組于 8 日對(duì)韶山測(cè)試現(xiàn)象現(xiàn)場(chǎng)測(cè)試，發(fā)現(xiàn)如下現(xiàn)象：永義區(qū)域進(jìn)行了測(cè)試。發(fā)現(xiàn)占用韶山市工行小區(qū)后，信號(hào)SINR 明顯偏低，發(fā)起業(yè)務(wù)速率偏低；CSFB 存在無(wú)法回落的情況，能正?；芈涞母怕试?20%左右，不能回落

27、概率達(dá) 80%。不能回落時(shí)需重起，才能正常占用 4G。能正?；芈鋾r(shí)延較長(zhǎng)，回落時(shí)延達(dá)到 10S 以上。測(cè)試問題排查1、測(cè)試中鄰小區(qū)內(nèi)新增加了 PCI 為 57、58、59 站點(diǎn)，且信號(hào)好于主服務(wù)小區(qū)，下行頻點(diǎn)都為 1650，在信令中發(fā)現(xiàn)系統(tǒng)中發(fā)生測(cè)量成不了切換。對(duì)周邊和工參信息無(wú)此站點(diǎn)信息。，A3 事件不停上報(bào)且完2、為了排除是否新建站點(diǎn)沒有更新數(shù)據(jù)，進(jìn)行了以下操作，閉鎖主服務(wù)小區(qū)LHF-工行站點(diǎn)，檢查是否會(huì)占用 PCI 為 57、58、59 的站點(diǎn)。經(jīng)測(cè)試占用了PCI 為 57 小區(qū)后，無(wú)法發(fā)起業(yè)務(wù)，情況如下：3、從信令中發(fā)現(xiàn)占用PCI 為 57 的站點(diǎn)后，UE 向ENODEB 發(fā)起 RRC

28、CONNECTIONRE 消息，UE 又重新發(fā)起隨機(jī)接入。隨后接入失敗，啟動(dòng)了異頻測(cè)量，重選至 1825 電信頻點(diǎn)上，然后建立連接失敗。4、從信令中分析，NOBLE NETWORK CODE 為 00，為中國(guó)移動(dòng)的網(wǎng)絡(luò)識(shí)別號(hào)，懷疑移動(dòng)使用的頻點(diǎn)。通過測(cè)試定位出，在、永義周邊移動(dòng)使用的 LTE 頻點(diǎn)，LTE 受到干擾，造成 4G 回落與上網(wǎng)速率慢。解決措施問題定位后，湘潭運(yùn)維部門與移動(dòng)公司協(xié)商，確認(rèn)移動(dòng)在永義與設(shè)了兩個(gè)試驗(yàn)站點(diǎn)，使用的頻率為 1840-1860，經(jīng)要求移動(dòng)對(duì)頻點(diǎn)進(jìn)行更改后，對(duì)現(xiàn)場(chǎng)測(cè)試，速回落正常：?jiǎn)栴}與結(jié)論重定項(xiàng)回落時(shí)終端在 LTE 側(cè)發(fā)起呼叫或者接收到尋呼，LTE 網(wǎng)絡(luò)通過 R

29、8 重定向命令（RRC Connection Release）下發(fā) 3G 頻點(diǎn)，指引終端回落到 3G 網(wǎng)絡(luò)。當(dāng)接入相同頻點(diǎn)且非所在運(yùn)營(yíng)商時(shí)，無(wú)法從而導(dǎo)致接入失敗，無(wú)法正常回落。3.2網(wǎng)未做 TAC 和 LAC導(dǎo)致無(wú)法駐留問題問題現(xiàn)象:2014-05-16 日測(cè)試在 517 前在“海底世界”保障時(shí)發(fā)現(xiàn)，和 D2 等終端無(wú)法占用 LTE 網(wǎng)絡(luò)，經(jīng)過網(wǎng)和無(wú)線側(cè)共同抓取信令 log 分析得出，由于此區(qū)域新開的站點(diǎn)使用了一個(gè)新入網(wǎng) TAC 號(hào)，沒有及時(shí)通知網(wǎng)在 MME、DNS 上做TAC 和 LAC關(guān)系，導(dǎo)致和 D2 等終端在 MME 上失敗。具體分析：測(cè)試測(cè)試分析：網(wǎng)優(yōu)工程師到現(xiàn)場(chǎng)用和 D2 終端測(cè)試

30、顯示無(wú)信號(hào)，連接 CDS 后顯示，不停的上報(bào)隨機(jī)接入失敗。從KPI 分析：KPI 上查看 PRACH 指標(biāo)發(fā)現(xiàn)，成功率為 0。網(wǎng)側(cè)分析：網(wǎng)在抓 log 時(shí)發(fā)現(xiàn)，每次做附著時(shí)，網(wǎng)馬上被拒，提示網(wǎng)絡(luò)不可用，網(wǎng)經(jīng)過分析得出，配置的 TAC 號(hào)不在 MME 配置的 TAC 列表內(nèi)，所以導(dǎo)致用戶無(wú)法接入。根本原因:配置的 TAC 號(hào)不在 MME 配置的 TAC 列表內(nèi)，所以導(dǎo)致用戶無(wú)法接入。解決措施：網(wǎng)將新入網(wǎng)的TAC 加入到MME 列表內(nèi)，并根據(jù)TAC 和LAC 物理覆蓋范圍，在 MME、DNS 上配置 TAC 和 LAC 的關(guān)系。問題與結(jié)論：網(wǎng)配置完成后，通知前臺(tái)再次測(cè)試驗(yàn)證，測(cè)試在現(xiàn)場(chǎng)測(cè)試反饋，手

31、機(jī)可以正常駐留網(wǎng)絡(luò)，并且可以正常做數(shù)據(jù)業(yè)務(wù)和 CSFB 語(yǔ)音撥打測(cè)試LNBTSIDLRIDDATETIMEBTSNAMEPRACH_SUC_RATOPRACH_SUCPRACH_ATT72216612014/5/15LFH-長(zhǎng)沙縣世界之窗新天鵝城堡006872216622014/5/15LFH-長(zhǎng)沙縣世界之窗新天鵝城堡005272216632014/5/15LFH-長(zhǎng)沙縣世界之窗新天鵝城堡004772216712014/5/15LFH-長(zhǎng)沙縣世界之窗辦公樓004272216722014/5/15LFH-長(zhǎng)沙縣世界之窗辦公樓003472216732014/5/15LFH-長(zhǎng)沙縣世界之窗辦公樓00

32、3472216412014/5/15LFH-長(zhǎng)沙縣 YD 世界之窗海底世界路燈003072216422014/5/15LFH-長(zhǎng)沙縣 YD 世界之窗海底世界路燈002972216432014/5/15LFH-長(zhǎng)沙縣 YD 世界之窗海底世界路燈00264G 無(wú)法做被叫，無(wú)線參數(shù)調(diào)整解決3.3 長(zhǎng)沙問題現(xiàn)象:長(zhǎng)沙運(yùn)維反饋 4G 網(wǎng)絡(luò)下漏接的，智能出現(xiàn) 4G 脫網(wǎng)和語(yǔ)音被叫提示正忙現(xiàn)象。在 CSFB 從 4G 回落 3G 后，F(xiàn)R 回 4G 時(shí)，出現(xiàn)了后再次上發(fā) TAU 才成功上發(fā) TAU 沒反應(yīng)情況，相隔 10S 之在這 10S 時(shí)間內(nèi)，顯示的是 4G 脫網(wǎng)和語(yǔ)音被叫提示正忙這兩次 TAU_req

33、 網(wǎng)側(cè)在十幾秒后才回 TAU_accept 消息，這會(huì)導(dǎo)致這段時(shí)間內(nèi)不能處理尋呼，從而接不到來(lái)電。具體分析：從 UE 測(cè)試 LOG 分析中看到出線問題bar 概率 5%，應(yīng)該是網(wǎng)絡(luò)設(shè)置問題。被 Bar，SIB2 中配置了 ac-barringinfo，被根本原因:ac-BarringFactor 參數(shù)是為了避免95%這會(huì)隨機(jī)5%的正常業(yè)務(wù)接入超負(fù)荷工作而設(shè)置的，規(guī)范中是可選參數(shù)，最大取值在現(xiàn)階段 4G 網(wǎng)絡(luò)并不繁忙的情況下，為了避免不必要的 4G 用戶準(zhǔn)入限制，建議取消 4G 網(wǎng)絡(luò)中 ac-barring 的參數(shù)設(shè)置，保證 100% 接入不被BAR ??；解決措施：針對(duì)UE 測(cè)試中的 SIB2

34、中配置問題，檢查參數(shù)如下:1 ac-BarringFactor Nokia 參數(shù)對(duì)應(yīng)是 probFac 現(xiàn)網(wǎng)為 95%Defines the probability for a UE to establish an RRC connection.The acsprobability factor defines the probability for a UE to establish an RRCconnection.The UE draws a random number (0 = rand 1). If rand is higher n the value indi-cated by t

35、he acs probability factor, the UE considers theacs barring check to be unsucsful.2 規(guī)范說(shuō)明如果 UE 建立 RRC 連接的目的是移動(dòng)始發(fā)呼叫（mobile originating call）：如果定時(shí)器 T302 或T303 正在運(yùn)行：認(rèn)為接入該小區(qū)受限。否則如果SystemInformationBlockType2 包含 ac-BarringInfo，且 ac-BarringForMo-Data 存在：如果 UE 有一個(gè)或個(gè)范圍為 1115 的接入級(jí)別（在 USIM 中），按照3GPP TS 22.011v9

36、30-2009 和 3GPP TS 23.122 v930-2010 的要求，該范圍對(duì) UE是有效的；其中至少一種接入級(jí)別，ac-BarringForMo-Data 中 ac-BarringForSpelAC 的相應(yīng)比特位值為 0，則認(rèn)為可以接入該小區(qū)。否則：在 0 rand 1 范圍內(nèi)均勻隨機(jī)抽取 rand 值；如果rand 低于ac-BarringForMo-Data 中ac-BarringFactor 所指示的值，則認(rèn)為可以接入該小區(qū)；否則認(rèn)為接入該小區(qū)受限。否則：認(rèn)為可以接入該小區(qū)。因?yàn)?ac-BarringFactor 參數(shù)，95%是這個(gè)參數(shù)的最大值了，如要以保證 100% 不被 B

37、AR住，建議將這組參數(shù)刪除。選定一個(gè)小區(qū)，將 ac-BarringFactor 參數(shù)刪除，解除 4G5%的 BAR 設(shè)置。參數(shù)修正后，測(cè)試了幾百次呼叫，沒有出現(xiàn)被叫無(wú)法接通現(xiàn)象。問題與結(jié)論：長(zhǎng)沙 4G 全網(wǎng)進(jìn)行了 ac-barring 的參數(shù)修正，避免 4G 用戶的準(zhǔn)入限制到目前為止，經(jīng)過現(xiàn)象。半個(gè)月的，沒有再出現(xiàn)由于準(zhǔn)入限制造成的 4G 用戶無(wú)法做被叫3.4 LAC 邊界用戶語(yǔ)音回落被叫無(wú)應(yīng)答問題，開啟 MTRF 解決問題現(xiàn)象用戶在衡陽(yáng)御景新城 4G終端經(jīng)常出現(xiàn)被叫無(wú)法接通，而做主叫正常，能正常重定向至 UMTS 并在呼叫結(jié)束快速返回 LTE，但在做被叫時(shí)經(jīng)常出現(xiàn)提示用戶暫時(shí)無(wú)法接通的情況。

38、處理過程現(xiàn)場(chǎng)測(cè)試發(fā)現(xiàn)用戶所處位置 3G 信號(hào)比較雜亂，駐留小區(qū)有歸屬 LAC58204 的WD-蒸湘區(qū)蒸水花苑-3，WD-八角亭-2，歸屬 LAC58205 的 WD-蒸湘區(qū)雨母校區(qū)美化樹-1,LAC58204 屬于 HYMSS1，LAC58205 屬于HYMSS3。4G 信號(hào)駐留小區(qū)為 LFH-蒸湘區(qū)客運(yùn)站-3，當(dāng)用戶做被叫回落到 WD-蒸湘區(qū)雨母校區(qū)美化樹-1 時(shí)就出現(xiàn)無(wú)法接通現(xiàn)象。置LAC，TAC及MSC用戶所處位分布情況：被叫漫游前轉(zhuǎn)特性，簡(jiǎn)稱 MTRF（Mobile Terminating Roaming Forwarding），用于解決 MSC 邊界（非 POOL 組網(wǎng)）或 MSC

39、 POOL 邊界 CSFB 被叫跨 MSC 或跨 POOL 呼叫失敗的問題，使呼叫能夠繼續(xù)接續(xù)，從而提高呼叫成功率。MSC 邊界（非 POOL 組網(wǎng)）或 MSC POOL 邊界 CSFB 被叫跨 MSC 或跨 POOL 呼叫失敗的觸發(fā)場(chǎng)景：TAI-LAI 規(guī)劃錯(cuò)誤，存在 TAI 跨LAI 情況，且兩個(gè) LAI 分屬不同 MSC（非 POOL 組網(wǎng)）或不同 MSC POOL，此種場(chǎng)景建議優(yōu)先通過優(yōu)化 TAI-LAI 對(duì)應(yīng)關(guān)系來(lái)解決；TAI-LAI 規(guī)劃正確，MSC1 的位置區(qū) LAI1 和 MSC2 的位置區(qū) LAI2（非 POOL 組網(wǎng)）存在交疊區(qū)域，或 POOL1 內(nèi) MSC1 的位置區(qū) L

40、AI1 和 POOL2 內(nèi) MSC2 的位置區(qū)LAI2 存在交疊區(qū)域， CSFB 被叫回落時(shí)：當(dāng) LAI2 與 LAI1 為同頻覆蓋，LAI2 信號(hào)好于LAI1；當(dāng) LAI2 與 LAI1 為非同頻覆蓋，但 UE 測(cè)量發(fā)現(xiàn)LAI1 的信號(hào)強(qiáng)度低于門限值，而 LAI2的信號(hào)較好高于門限值；在這兩種情況下，UE 都會(huì)在 LAI2 接入 MSC2 導(dǎo)致被叫失敗。MTRF 原理：MTRF 的實(shí)現(xiàn)有兩種方式：MSC 方式（當(dāng)前階段）、MSC+HLR 方式。2.1 MSC 方式 MTRF 流程圖：場(chǎng)景 1：普通非 POOL 組網(wǎng)，oldMSC 與 newMSC 為兩個(gè)獨(dú)立的物理 MSC。流程簡(jiǎn)明：1、 流程 11：UE 在位置更新消息中，攜帶 CSMT 標(biāo)識(shí)為 CSFB 被叫，攜帶 TMSI 與 PLAI用于流程 12 new MSC 發(fā)起取局間識(shí)別流程；2、 流程 12：New MSC 發(fā)送Send Identification 消息到Old MSC，并在 SI 消息中攜帶MTRF Support（表示本局支持 MTRF 功能）、New msc Number、New vlr Number信元（用于 old MSC 發(fā)起