諾西GPRS典型案例

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

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

3、 “ZHTKJ.HZ.SD.MNC*.MCC*.GPRS”進行PDPcontext激活。 進一步分析該用戶的行為， 發(fā)現(xiàn)該用戶每分鐘做一次PDPcontext激活，而且信令流程不同于一般的手機用戶，應該是使用功能不完善的通訊軟件在進行數(shù)據(jù)業(yè)務。并且由于未能成功建立通信連接而不斷重撥， 導致以上業(yè)務失敗次數(shù)的增加。 進一步對上午忙時的數(shù)據(jù)進行分析， 同樣發(fā)現(xiàn)該類用戶在不斷重復此項活動。這個APN的失敗次數(shù)占到所有APN失敗次數(shù)的52%。因此可以確定是該類用戶使用某種不規(guī)范的終端工具，未能激活數(shù)據(jù)業(yè)務，自動重試，從而導致KPI的降低。案例一：案例一：PDP激活成功率降低激活成功率降低三.分析 進一

4、步在Gp口檢查該APN的激活情況，該請求正確的發(fā)送到了目的GGSN， 使用的是GTPv1。而從所有發(fā)到該目的GGSN的消息看該GGSN不能識別GTPv1的消息， 只能處理GTPv0的消息， 因此在激活過程中時間較長。SGSN的處理方式為先用GTPv1發(fā)3次請求， 每次間隔3秒，若無回應則用GTPv0再發(fā)。因此第一次GTPv0的消息是在12秒以后才能發(fā)出，而該用戶未能配合這類情況，在到達12秒之前就已經(jīng)中斷了該次激活，從而導致激活不成功 案例一：案例一：PDP激活成功率降低激活成功率降低四.結(jié)論從數(shù)據(jù)分析的情況看此次故障和核心網(wǎng)無關(guān)。建議查找該類用戶，了解情況，并協(xié)商解決。建議聯(lián)系目的GGSN所

5、在的省分公司， 解決GTP版本的問題。從GGSN側(cè)解決此問題。案例二：案例二：SGSN的的Gr Link負載不均衡負載不均衡一.描述 多條Gr Link中只有一部分的信令負荷為0，即該Gr Link的單向信令傳輸不生效。案例二：案例二：SGSN的的Gr Link負載不均衡負載不均衡二.處理過程 通過OLT命令查詢相應的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

6、00-timeUsage(7) value: 0-serviceChangeCondition(8) value: 0-sgsnAddress(10)-SEQUENCE(16)-iPTextV4Address(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)時間為案例三：話單中上網(wǎng)時間為0的問題

7、的問題三.分析SGSN產(chǎn)生的S-CDR話單c g 1 _ 2 0 0 9 0 2 0 1 0 5 0 0 0 7 . c d r. b o s s : 1 8 7 8 3 7 3 5 6 6 1 46001415203590620090131202240 0 8613022175033 220.206.129.48 220.206.129.2541535848641CMWAP.MNC001.MCC460.GPRS m n c 0 0 . m c c 4 6 0 . g p rs 10.100.152.3060F5 5184 70360821 80 00 83678 29686501FF0000

8、0000040000000102739673737482FFFF2009020104224020090201044007 1047 案例三：話單中上網(wǎng)時間為案例三：話單中上網(wǎng)時間為0的問題的問題三.分析 一般來說：用戶使用的時長在話單中取Duration字段，而不是timeUsage。只有在內(nèi)容計費的同時又需要對子業(yè)務進行時長計費的時候在將該參數(shù)改為Enabled，如下面話單所示：listOfTrafficVolumes(12) ：-changeTime(6) value: 09 02 01 04 39 45 +08 00-recordOpeningTime(13) value: 09 02

9、01 04 22 18 +08 00-duration(14) value: 1047 而不是而不是 -timeUsage(7) value: 0案例三：話單中上網(wǎng)時間為案例三：話單中上網(wǎng)時間為0的問題的問題三.分析檢查FlexiISN3.0上Charging Class的設(shè)置： 默認情況下，ChargingClass 里面的 Time項設(shè)置是 Disabled，在Disabled狀態(tài)下，Timeusage的數(shù)值為0。打開Time值設(shè)置后，話單中 timeUsage 字段為實際流量。 案例三：話單中上網(wǎng)時間為案例三：話單中上網(wǎng)時間為0的問題的問題四.結(jié)論 在不需要對子業(yè)務記錄時長時關(guān)閉Time

10、選項，在需要對子業(yè)務記錄時長時再打開該選項。案例四：案例四：SGSN重啟后部分重啟后部分BVC狀態(tài)不一致狀態(tài)不一致 一.描述 SGSN重啟動完成后檢查BVC狀態(tài)均正常。但測試發(fā)現(xiàn)有部分基站下面GPRS業(yè)務不可用。在BSC上檢查基站的GPRS為blocked狀態(tài)。在SGSN重啟后出現(xiàn)的這種現(xiàn)象，與核心網(wǎng)版本無關(guān)。案例四：案例四：SGSN重啟后部分重啟后部分BVC狀態(tài)不一致狀態(tài)不一致 二.處理過程 通過BSS側(cè)的開關(guān)GPRS功能或者SGSN側(cè)的NSVC閉解鎖操作能夠清除不正常的BSS狀態(tài)。案例四：案例四：SGSN重啟后部分重啟后部分BVC狀態(tài)不一致狀態(tài)不一致 三.分析重置過程如下圖所示：BSS S

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

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

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

14、RESET-ACK消息，BSC會重發(fā)BVC-RESET消息，直到嘗試次數(shù)達到計數(shù)器BVCResetRetries。如果仍然沒有響應，BSC停止BVC-RESET程序，BVC狀態(tài)保持為blocked。案例四：案例四：SGSN重啟后部分重啟后部分BVC狀態(tài)不一致狀態(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沒有應答B(yǎng)VC-RESET-ACK消息，比如處理器

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

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

17、et procedureBVCResetRetries 1 - 100/3案例五：案例五：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

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

19、激活無法激活PDP 三.分析通過抓包分析可以看到：案例五：案例五：SGSN上安裝上安裝Feature378的的License后后無法激活無法激活PDP 三.分析在同一Flexi-ISN上激活的用戶2G是無效的，但是3G是有效的。進一步檢查Flexi-ISN 中 Service access control: GERAN Allowed 被設(shè)置成 False。如果該值設(shè)置成 False，而且SGSN發(fā)送的消息中RAT字段在無線接入類型是 GERAN 的時候，PDP激活會被拒絕。如果該值設(shè)置成 False，而且SGSN發(fā)送的消息不包含RAT字段的時候，PDP激活仍然會被允許。而參數(shù)UTRAN Al

20、lowed 被設(shè)置成 True，所以3G用戶并不受影響。把該值設(shè)置成 True 后，問題解決。案例五：案例五：SGSN上安裝上安裝Feature378的的License后后無法激活無法激活PDP 三.分析案例五：案例五：SGSN上安裝上安裝Feature378的的License后后無法激活無法激活PDP 四.結(jié)論將UTRAN Allowed 和GERAN Allowed被設(shè)置成 True才能保證業(yè)務的正常使用。案例六：案例六：Inter-SGSN路由區(qū)更新后路由區(qū)更新后APN GOI丟失丟失 一.描述 用戶在激活PDP context狀態(tài)下切換到相鄰SGSN然后繼續(xù)GPRS會話，后續(xù)SGSN下

21、生成的計費話單中沒有填寫APN_OI。計費中心在分揀話單時認為是錯單。案例六：案例六：Inter-SGSN路由區(qū)更新后路由區(qū)更新后APN GOI丟失丟失 二.處理過程 按照3GPP相關(guān)規(guī)范，SGSN之間通過GTP程序SGSN_Context_Request傳遞用戶的MM Context和PDP context。在Release 99中，PDP context中的APN字段只包含APN_NI并不包含APN_OI。(APN_OI:MNC002.MCC460.GPRSAPN_NI:UNIWAP）3GPP TS 29.060 V3.12.0 (2002-03) Release 997.7.29PDP

22、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 Access Point Name contains a logical name that is the APN Network Identifier (see 3GPP TS 23.060).案例六：案例六：Inter-SGSN路由區(qū)更新后路由區(qū)更新后APN GOI丟失丟失 二.處理過程

23、而在Release 4之后，規(guī)范對相關(guān)字段進行了修改，PDP context中的APN將同時包含APN_NI和APN_OI。3GPP TS 29.060 V4.4.0 (2002-03) Release 47.7.29PDP ContextThe APN is the Access Point Name in use in the old SGSN. This APN field shall be composed of the APN NetworkIdentifier part and the APN Operator Identifier part.案例六：案例六：Inter-SGSN路

24、由區(qū)更新后路由區(qū)更新后APN GOI丟失丟失 三.分析 用戶是在Release 99的SGSN下發(fā)起激活PDP context的。在路由區(qū)更新到相鄰SGSN的時候，APN_OI不會被傳遞過去。在這之后如果有繼續(xù)的SGSN改變，APN_OI也不會再被填充。案例六：案例六：Inter-SGSN路由區(qū)更新后路由區(qū)更新后APN GOI丟失丟失 四.結(jié)論 差異是由于規(guī)范的變化引起的，按照向下兼容的規(guī)則SGSN都能夠接受Release 99的消息。計費中心應當調(diào)整其后處理軟件以兼容和支持更多的網(wǎng)元版本。案例七：單向案例七：單向RAU更新失敗更新失敗 一.描述 從LAC9525至LAC9753單向RAU失敗

25、。案例七：單向案例七：單向RAU更新失敗更新失敗 二.處理過程 路由區(qū)更新失敗，從PAPU上解析相應LAC地址， DNS解析正常。 在GN口抓包：沒有發(fā)現(xiàn)從LAC9753所在PAPU發(fā)至LAC9525所在PAPU的SGSN context request 消息，即新的SGSN沒有向舊的SGSN發(fā)送SGSN context request 消息 案例七：單向案例七：單向RAU更新失敗更新失敗 三.分析 新的 SGSN不向舊的SGSN發(fā)送SGSN context request消息的可能原因是：1） 新的SGSN沒有解析到新的SGSN的PAPU ip地址；2）新的SGSN認為手機的RAI (MCC

26、+MNC+LAC+RAC)應該是自己處理的。案例七：單向案例七：單向RAU更新失敗更新失敗 三.分析 檢查SGSN10發(fā)現(xiàn)LAC9525下的小區(qū)曾經(jīng)加載成功的日志。MAIN LEVEL COMMAND EJL:PAPU=4;LOADING PROGRAM VERSION 7.5-6SGSN SZHSG10BNK 2007-06-16 03:35:05NETWORK CONFIGURATION DATA OUTPUTNSEI-00351PAPU-04MCC-460 MNC-00 LAC-09525 RAC-001 CI-03901 BVCI-00386 STATE-WO案例七：單向案例七：單向R

27、AU更新失敗更新失敗 三.分析 手機從LAC9525 到 LAC9753，將向SGSN10發(fā)起RAU request。SGSN10檢查RAI (MCC+MNC+LAC+RAC), 發(fā)現(xiàn)這個路由區(qū)應該是自己處理的。然而SGSN10檢查SMMU（GSBASE)）并不能找到該用戶的信息，導致LAC9525到LAC9753的RAU失敗。所以，BSC側(cè)對LAC數(shù)據(jù)的錯誤配置，是導致本次RAU失敗的原因。 案例七：單向案例七：單向RAU更新失敗更新失敗 四.結(jié)論 1 .在SGSN的LAC 關(guān)聯(lián)里只保留與其實際相關(guān)聯(lián)的LAC信息，刪除不必要的LAC。2. 在BSC側(cè)檢查，保證沒有同一個LAC的小區(qū)分別掛在不

28、同的SGSN上的情況。案例八：案例八：GSBASE程序模塊告警程序模塊告警一.描述 某省分由于業(yè)務推廣， 用戶量增加比較多，SGSN擴容無法跟上， 容量已經(jīng)接近飽和。最近不斷出現(xiàn)告警。檢查發(fā)現(xiàn)SGSN容量應該在64萬， 用MMN查看的用戶數(shù)已經(jīng)達到62萬， 而用GHP察看M-CDR有15萬， S-CDR有2萬。從S-CDR的情況看業(yè)務量并沒有很大的增長， 不理解為什么SGSN會有GSBASE程序模塊告警。 案例八：案例八：GSBASE程序模塊告警程序模塊告警二.處理過程 MCDR（15萬）代表著實際的附著用戶數(shù)，SCDR（2萬）代表著實際的PDP激活數(shù)量，MMN（62萬）代表著GSBASE 的

29、用戶數(shù)，即從HLR得到的尚未purge的用戶數(shù)，其中包含著當前附著的，以及已經(jīng)去附著但沒有被purge掉的。 案例八：案例八：GSBASE程序模塊告警程序模塊告警三.分析 MCDR（15萬）代表著實際的附著用戶數(shù)，SCDR（2萬）代表著實際的PDP激活數(shù)量，MMN（62萬）代表著GSBASE 的用戶數(shù)，即從HLR得到的尚未purge的用戶數(shù)，其中包含著當前附著的，以及已經(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后（可以是手機側(cè)發(fā)起，也可以是網(wǎng)絡(luò)側(cè)發(fā)起）STT參數(shù)開始計時，如果在STT時間內(nèi)沒有再發(fā)起ATTACH請求，那么將被打上標簽，在特定的時間進行Purge。案例八：案例八：GSBASE程序模塊告警