-諾西GPRS典型案例分析-PPT課件

1、GPRS典型案例分析案例一：PDP激活成功率降低描述： 某省公司GPRS業(yè)務(wù)的PDP context成功率最近不穩(wěn)定， 有一定程度的降低。從網(wǎng)元告警情況分析未發(fā)現(xiàn)明顯異常， 需要工程師到現(xiàn)場處理 。案例一：PDP激活成功率降低二.處理過程 通過Traffica對現(xiàn)網(wǎng)的歷史數(shù)據(jù)進(jìn)行分析 ，PDPcontext激活失敗的原因按類型分布如下： 案例一：PDP激活成功率降低三.分析在所有的失敗原因里，主要是如下幾個原因：0 x1E: 占 95.34% ，原因為用戶APN錯誤0 x5C: 占 0.52%，原因為用戶未填寫APN0 x67: 占 2.04%，原因為用戶請求的服務(wù)未登記0 x90: 占 0.

2、08%，原因為用戶激活過程未完成即被中斷0XB2: 占 2.02%，原因為用戶激活過程未完成即被中斷 其中0 x1E，0 x5C，0 x67均為用戶原因， 在KPI里不必考慮， 而B2和90是對KPI有影響的。這兩個錯誤的原因基本都是由于激活請求沒有得到響應(yīng)而產(chǎn)生。其中以B2數(shù)量較大，須重點分析。 案例一：PDP激活成功率降低三.分析 30日下午對現(xiàn)網(wǎng)數(shù)據(jù)進(jìn)行實時分析，從15：20到15點35分采集了15分鐘的數(shù)據(jù)， 采集到29次B2事件。其中13次均為同一用戶所為。該用戶使用APN “ZHTKJ.HZ.SD.MNC*.MCC*.GPRS”進(jìn)行PDPcontext激活。 進(jìn)一步分析該用戶的行為

3、， 發(fā)現(xiàn)該用戶每分鐘做一次PDPcontext激活，而且信令流程不同于一般的手機(jī)用戶，應(yīng)該是使用功能不完善的通訊軟件在進(jìn)行數(shù)據(jù)業(yè)務(wù)。并且由于未能成功建立通信連接而不斷重?fù)埽?導(dǎo)致以上業(yè)務(wù)失敗次數(shù)的增加。 進(jìn)一步對上午忙時的數(shù)據(jù)進(jìn)行分析， 同樣發(fā)現(xiàn)該類用戶在不斷重復(fù)此項活動。這個APN的失敗次數(shù)占到所有APN失敗次數(shù)的52%。因此可以確定是該類用戶使用某種不規(guī)范的終端工具，未能激活數(shù)據(jù)業(yè)務(wù)，自動重試，從而導(dǎo)致KPI的降低。案例一：PDP激活成功率降低三.分析 進(jìn)一步在Gp口檢查該APN的激活情況，該請求正確的發(fā)送到了目的GGSN， 使用的是GTPv1。而從所有發(fā)到該目的GGSN的消息看該GGSN

4、不能識別GTPv1的消息， 只能處理GTPv0的消息， 因此在激活過程中時間較長。SGSN的處理方式為先用GTPv1發(fā)3次請求， 每次間隔3秒，若無回應(yīng)則用GTPv0再發(fā)。因此第一次GTPv0的消息是在12秒以后才能發(fā)出，而該用戶未能配合這類情況，在到達(dá)12秒之前就已經(jīng)中斷了該次激活，從而導(dǎo)致激活不成功 案例一：PDP激活成功率降低四.結(jié)論從數(shù)據(jù)分析的情況看此次故障和核心網(wǎng)無關(guān)。建議查找該類用戶，了解情況，并協(xié)商解決。建議聯(lián)系目的GGSN所在的省分公司， 解決GTP版本的問題。從GGSN側(cè)解決此問題。案例二：SGSN的Gr Link負(fù)載不均衡一.描述 多條Gr Link中只有一部分的信令負(fù)荷為

5、0，即該Gr Link的單向信令傳輸不生效。案例二：SGSN的Gr Link負(fù)載不均衡二.處理過程 通過OLT命令查詢相應(yīng)的Gr LinklocalSequenceNumber(4) value: 20-timeOfFirstUsage(5) value: 09 02 01 04 22 18 +08 00-timeOfLastUsage(6) value: 09 02 01 04 39 45 +08 00-timeUsage(7) value: 0-serviceChangeCondition(8) value: 0-sgsnAddress(10)-SEQUENCE(16)-iPTextV4A

6、ddress(2) value: 220.206.129.48-volumeUplink(12) value: 83678-volumeDownlink(13) value: 296865-serviceIdentifier(17) value: 33554433-consolidationResult(35) value: normal(0) 案例三：話單中上網(wǎng)時間為0的問題三.分析SGSN產(chǎn)生的S-CDR話單cg1_20090201950007.cdr.boss: 18 783735661 46001415203590620090131202240 0 8613022175033 220.

7、206.129.48 220.206.129.2541535848641CMWAP.MNC001.MCC460.GPRS mnc00.mcc460.gprs 10.100.152.3060F5 5184 70360821 80 00 83678 29686501FF00000000040000000102739673737482FFFF2009020194224020090201944007 1047案例三：話單中上網(wǎng)時間為0的問題三.分析 一般來說：用戶使用的時長在話單中取Duration字段，而不是timeUsage。只有在內(nèi)容計費的同時又需要對子業(yè)務(wù)進(jìn)行時長計費的時候在將該參數(shù)改為Ena

8、bled，如下面話單所示：listOfTrafficVolumes(12) ：-changeTime(6) value: 09 02 01 04 39 45 +08 00-recordOpeningTime(13) value: 09 02 01 04 22 18 +08 00-duration(14) value: 1047而不是 -timeUsage(7) value: 0案例三：話單中上網(wǎng)時間為0的問題三.分析檢查FlexiISN3.0上Charging Class的設(shè)置： 默認(rèn)情況下，ChargingClass 里面的 Time項設(shè)置是 Disabled，在Disabled狀態(tài)下，Ti

9、meusage的數(shù)值為0。打開Time值設(shè)置后，話單中 timeUsage 字段為實際流量。 案例三：話單中上網(wǎng)時間為0的問題四.結(jié)論 在不需要對子業(yè)務(wù)記錄時長時關(guān)閉Time選項，在需要對子業(yè)務(wù)記錄時長時再打開該選項。案例四：SGSN重啟后部分BVC狀態(tài)不一致 一.描述 SGSN重啟動完成后檢查BVC狀態(tài)均正常。但測試發(fā)現(xiàn)有部分基站下面GPRS業(yè)務(wù)不可用。在BSC上檢查基站的GPRS為blocked狀態(tài)。在SGSN重啟后出現(xiàn)的這種現(xiàn)象，與核心網(wǎng)版本無關(guān)。案例四：SGSN重啟后部分BVC狀態(tài)不一致 二.處理過程 通過BSS側(cè)的開關(guān)GPRS功能或者SGSN側(cè)的NSVC閉解鎖操作能夠清除不正常的BS

10、S狀態(tài)。案例四：SGSN重啟后部分BVC狀態(tài)不一致 三.分析重置過程如下圖所示：BSS SGSN BVC-RESET(BVCI=0) BVC-RESET(BVCI0,CELLid) - BVC-RESET-ACK(BVCI) FLOW-CONTROL-BVC-ACK - . . 案例四：SGSN重啟后部分BVC狀態(tài)不一致 三.分析1.在SGSN開始重啟動之后，所有Gb的物理連接被中斷。 在BSC側(cè)，當(dāng)一個NSE(PCU)連接的所有NS-VC都為不可用的狀態(tài)時，相關(guān)的BVC會被隱性地設(shè)置為BVC-BLOCK狀態(tài)，也不會有消息通知BSSGP對端。2. 當(dāng)SGSN重啟動完成后，Gb接口的物理連接被恢

11、復(fù)。SGSN將發(fā)起B(yǎng)VC-RESET(signalling)程序。 我們知道，SGSN側(cè)只配置NSE(PCU)的的信息，關(guān)于每個BTS的BVC信息是動態(tài)的，沒有手工配置數(shù)據(jù)。這里的BVC復(fù)位不是對于某一個BSS(CELL)發(fā)起的，而是BVCI=0，標(biāo)示這是復(fù)位信令BVC，只是通知到PCU。案例四：SGSN重啟后部分BVC狀態(tài)不一致 三.分析3. 在收到BVC-RESET-ACK后，SGSN將NSE的狀態(tài)置為可用狀態(tài)。SGSN發(fā)起的復(fù)位程序即告完成。4. 接下來，PCU側(cè)根據(jù)控制的BTS狀態(tài)，發(fā)起對于每一個BTS的BVC-RESET程序，通過該程序?qū)VC轉(zhuǎn)換到可用狀態(tài)。 這時的復(fù)位程序是對于P

12、TP(點到點) BVC，是對于單個BTS的，其中攜帶有BVCI和小區(qū)標(biāo)示。 同時，BSC會啟動定時器TgbReset(T1)。 5. 在收到BVC-RESET PDU后，SGSN將BVCI和CELLid存儲在動態(tài)數(shù)據(jù)庫中，標(biāo)示BVCI為unblocked狀態(tài)。并通過BVC-RESET-ACK消息向BSC確認(rèn)該BVCI信息。案例四：SGSN重啟后部分BVC狀態(tài)不一致 三.分析6. 在收到BVC-RESET-ACK消息后，BSC設(shè)置BVC狀態(tài)為unblocked，并停止定時器TgbReset(T1)。然后發(fā)起Flow-Control-BVC程序。7. 如果在定時器TgbReset超時后仍沒有收到B

13、VC-RESET-ACK消息，BSC會重發(fā)BVC-RESET消息，直到嘗試次數(shù)達(dá)到計數(shù)器BVCResetRetries。如果仍然沒有響應(yīng)，BSC停止BVC-RESET程序，BVC狀態(tài)保持為blocked。案例四：SGSN重啟后部分BVC狀態(tài)不一致 三.分析根據(jù)現(xiàn)場觀察到的情況，SGSN側(cè)已經(jīng)存儲了相關(guān)的BVCI和Cellid信息，這說明SGSN已經(jīng)收到了BSC發(fā)送過來的BVC-RESET消息。但是BSC側(cè)并沒有將相關(guān)BVC的狀態(tài)置為unblock狀態(tài)。因此問題發(fā)生在上述第5步和第六步之間。其中，可能的原因有：1. SGSN沒有應(yīng)答B(yǎng)VC-RESET-ACK消息，比如處理器忙的原因；2. SGS

14、N應(yīng)答的BVC-RESET-ACK消息沒有成功發(fā)送給BSC，比如鏈路層上的過載而被丟棄；3. BSC收到了BVC-RESET-ACK消息，但無法處理，比如處理器忙的原因。案例四：SGSN重啟后部分BVC狀態(tài)不一致 三.分析根據(jù)我們的經(jīng)驗，在SGSN重啟后的短時間內(nèi)Gb接口出現(xiàn)擁塞的可能性還是比較大的。一個BSC下的BVC復(fù)位完成是有先后順序的，在完成復(fù)位后，BTS就立即投入工作狀態(tài)。這時來自終端的重新附著請求量是很大的，在短時間內(nèi)可能造成接口的過載。這時過載控制機(jī)制會被啟動以逐步消除過載，其中可能會造成部分PDU被丟棄。那么對于后續(xù)的BVC復(fù)位程序是會造成影響的。根據(jù)當(dāng)前網(wǎng)絡(luò)參數(shù)配置，定時器T

15、gbReset缺省設(shè)置為3秒，計數(shù)器BVCResetRetries也為3次。理論上說，如果Gb下行鏈路如果出現(xiàn)超過9秒的擁塞，而這期間有BSC發(fā)起的BVC-RESET程序在執(zhí)行，就可能出現(xiàn)我們看到的這種情況。案例四：SGSN重啟后部分BVC狀態(tài)不一致 四.結(jié)論作為改進(jìn)的建議，可以適當(dāng)加大BVC-RESET的定時器，以及增加BVC-RESET的重復(fù)嘗試次數(shù)。比如TgbReset=12秒，BVCResetRetries=10次BSS參數(shù)取值范圍及缺省值TgbReset 1 - 120s/3s Guards the reset procedureBVCResetRetries 1 - 100/3案例

16、五：SGSN上安裝Feature378的License后無法激活PDP 一.描述 Flexi-ISN添加新的License后存在一定概率無法正常激活PDP。案例五：SGSN上安裝Feature378的License后無法激活PDP 二.處理過程 SGSN Feature 378的解釋為 SGSN GTP Information sending，激活該Feature后，SGSN向GGSN額外發(fā)送以下消息 . Cell Global Identity (CGI). MS time zone. International Mobile Equipment Identity and Software

17、Version Number (IMEISV) of the MS. Radio Access Type (RAT)案例五：SGSN上安裝Feature378的License后無法激活PDP 二.處理過程 根據(jù)現(xiàn)象分析，并非同一手機(jī)的每一次PDP激活都是失敗的，在檢查完SGSN的配置后以及與Flexi-ISN的連通性后，將目光轉(zhuǎn)移到Flexi-ISN的配置上來案例五：SGSN上安裝Feature378的License后無法激活PDP 三.分析通過抓包分析可以看到：案例五：SGSN上安裝Feature378的License后無法激活PDP 三.分析在同一Flexi-ISN上激活的用戶2G是無效的

18、，但是3G是有效的。進(jìn)一步檢查Flexi-ISN 中 Service access control: GERAN Allowed 被設(shè)置成 False。如果該值設(shè)置成 False，而且SGSN發(fā)送的消息中RAT字段在無線接入類型是 GERAN 的時候，PDP激活會被拒絕。如果該值設(shè)置成 False，而且SGSN發(fā)送的消息不包含RAT字段的時候，PDP激活仍然會被允許。而參數(shù)UTRAN Allowed 被設(shè)置成 True，所以3G用戶并不受影響。把該值設(shè)置成 True 后，問題解決。案例五：SGSN上安裝Feature378的License后無法激活PDP 三.分析案例五：SGSN上安裝Feat

19、ure378的License后無法激活PDP 四.結(jié)論將UTRAN Allowed 和GERAN Allowed被設(shè)置成 True才能保證業(yè)務(wù)的正常使用。案例六：Inter-SGSN路由區(qū)更新后APN GOI丟失 一.描述 用戶在激活PDP context狀態(tài)下切換到相鄰SGSN然后繼續(xù)GPRS會話，后續(xù)SGSN下生成的計費話單中沒有填寫APN_OI。計費中心在分揀話單時認(rèn)為是錯單。案例六：Inter-SGSN路由區(qū)更新后APN GOI丟失 二.處理過程 按照3GPP相關(guān)規(guī)范，SGSN之間通過GTP程序SGSN_Context_Request傳遞用戶的MM Context和PDP contex

20、t。在Release 99中，PDP context中的APN字段只包含APN_NI并不包含APN_OI。(APN_OI:MNC002.MCC460.GPRSAPN_NI:UNIWAP）3GPP TS 29.060 V3.12.0 (2019-03) Release 997.7.29PDP Context The APN is the Access Point Name in use in the old SGSN. I.e. the APN sent in the Create PDP Context request message.7.7.30Access Point Name The A

21、ccess Point Name contains a logical name that is the APN Network Identifier (see 3GPP TS 23.060).案例六：Inter-SGSN路由區(qū)更新后APN GOI丟失 二.處理過程 而在Release 4之后，規(guī)范對相關(guān)字段進(jìn)行了修改，PDP context中的APN將同時包含APN_NI和APN_OI。3GPP TS 29.060 V4.4.0 (2019-03) Release 47.7.29PDP ContextThe APN is the Access Point Name in use in the

22、 old SGSN. This APN field shall be composed of the APN NetworkIdentifier part and the APN Operator Identifier part.案例六：Inter-SGSN路由區(qū)更新后APN GOI丟失 三.分析 用戶是在Release 99的SGSN下發(fā)起激活PDP context的。在路由區(qū)更新到相鄰SGSN的時候，APN_OI不會被傳遞過去。在這之后如果有繼續(xù)的SGSN改變，APN_OI也不會再被填充。案例六：Inter-SGSN路由區(qū)更新后APN GOI丟失 四.結(jié)論 差異是由于規(guī)范的變化引起的，按照

23、向下兼容的規(guī)則SGSN都能夠接受Release 99的消息。計費中心應(yīng)當(dāng)調(diào)整其后處理軟件以兼容和支持更多的網(wǎng)元版本。案例七：單向RAU更新失敗 一.描述 從LAC9525至LAC9753單向RAU失敗。案例七：單向RAU更新失敗 二.處理過程 路由區(qū)更新失敗，從PAPU上解析相應(yīng)LAC地址， DNS解析正常。 在GN口抓包：沒有發(fā)現(xiàn)從LAC9753所在PAPU發(fā)至LAC9525所在PAPU的SGSN context request 消息，即新的SGSN沒有向舊的SGSN發(fā)送SGSN context request 消息 案例七：單向RAU更新失敗 三.分析 新的 SGSN不向舊的SGSN發(fā)送S

24、GSN context request消息的可能原因是：1） 新的SGSN沒有解析到新的SGSN的PAPU ip地址；2）新的SGSN認(rèn)為手機(jī)的RAI (MCC+MNC+LAC+RAC)應(yīng)該是自己處理的。案例七：單向RAU更新失敗 三.分析 檢查SGSN10發(fā)現(xiàn)LAC9525下的小區(qū)曾經(jīng)加載成功的日志。MAIN LEVEL COMMAND EJL:PAPU=4;LOADING PROGRAM VERSION 7.5-6SGSN SZHSG10BNK 2019-06-16 03:35:05NETWORK CONFIGURATION DATA OUTPUTNSEI-00351PAPU-04MCC-

25、460 MNC-00 LAC-09525 RAC-001 CI-03901 BVCI-00386 STATE-WO案例七：單向RAU更新失敗 三.分析 手機(jī)從LAC9525 到 LAC9753，將向SGSN10發(fā)起RAU request。SGSN10檢查RAI (MCC+MNC+LAC+RAC), 發(fā)現(xiàn)這個路由區(qū)應(yīng)該是自己處理的。然而SGSN10檢查SMMU（GSBASE)）并不能找到該用戶的信息，導(dǎo)致LAC9525到LAC9753的RAU失敗。所以，BSC側(cè)對LAC數(shù)據(jù)的錯誤配置，是導(dǎo)致本次RAU失敗的原因。 案例七：單向RAU更新失敗 四.結(jié)論 1 .在SGSN的LAC 關(guān)聯(lián)里只保留與其實

26、際相關(guān)聯(lián)的LAC信息，刪除不必要的LAC。2. 在BSC側(cè)檢查，保證沒有同一個LAC的小區(qū)分別掛在不同的SGSN上的情況。案例八：GSBASE程序模塊告警一.描述 某省分由于業(yè)務(wù)推廣， 用戶量增加比較多，SGSN擴(kuò)容無法跟上， 容量已經(jīng)接近飽和。最近不斷出現(xiàn)告警。檢查發(fā)現(xiàn)SGSN容量應(yīng)該在64萬， 用MMN查看的用戶數(shù)已經(jīng)達(dá)到62萬， 而用GHP察看M-CDR有15萬， S-CDR有2萬。從S-CDR的情況看業(yè)務(wù)量并沒有很大的增長， 不理解為什么SGSN會有GSBASE程序模塊告警。 案例八：GSBASE程序模塊告警二.處理過程 MCDR（15萬）代表著實際的附著用戶數(shù)，SCDR（2萬）代表著

27、實際的PDP激活數(shù)量，MMN（62萬）代表著GSBASE 的用戶數(shù)，即從HLR得到的尚未purge的用戶數(shù)，其中包含著當(dāng)前附著的，以及已經(jīng)去附著但沒有被purge掉的。 案例八：GSBASE程序模塊告警三.分析 MCDR（15萬）代表著實際的附著用戶數(shù)，SCDR（2萬）代表著實際的PDP激活數(shù)量，MMN（62萬）代表著GSBASE 的用戶數(shù)，即從HLR得到的尚未purge的用戶數(shù)，其中包含著當(dāng)前附著的，以及已經(jīng)去附著但沒有被purge掉的。 案例八：GSBASE程序模塊告警三.分析 MM里面的DET,STT，UDC和UDL來減少detach用戶存在于GSBASE 里的數(shù)量。DET: DETACH TIMER 附著用戶從上一次去激活算起，如果在DET時間內(nèi)均未發(fā)起PDP激活請求，則由網(wǎng)絡(luò)側(cè)對用戶發(fā)起DETACH。 STT: DETACHED SUBSCRIBER STORAGE TIME 用戶完成DETACH后（可以是手機(jī)側(cè)發(fā)起，也可以是網(wǎng)絡(luò)側(cè)發(fā)起）STT參數(shù)開始計時，如果在STT時間內(nèi)沒有再發(fā)起ATTACH請求，那么將被打上標(biāo)簽，在特定的時間進(jìn)行Purge。案例八：GSBASE程序模塊告警三.分析 UDC: UTILISAT