【文章內容簡介】 根據(jù)觀察 No resource available 主要出現(xiàn)在用戶激活以下兩個企業(yè) APN 的情況下，并且這兩個 APN 的 No resource available 均為單獨的一個用戶的 PDP 激活請求造成： Gn Create_PDP_GTP_Cause Analysis IMSI APN GTP_Cause GTP_Cause_Count 460007290118119 . No resource available 244 460006184836372 . No resource available 11 建議局方檢查這兩個 APN 的地址池分配情況，并對這兩個行業(yè) APN 做合理的 IP地址規(guī)劃。 Radius 性能分析 Times Accounting_Num Accounting_Response_Num Radius_Visit_Succ(%) Radius_Response_Time(Avg) 2020522 15:00 69291 64132 % 2020522 16:00 278121 257136 % 2020522 17:00 6712 6173 % 上表是對 5/22 15:00~17:00 時間區(qū)間里面 Radius 訪問的時延統(tǒng)計， Radius Server 的計費請求成功率平均為 %。 下面是對 Radius Server 時延情況的分布圖： 可以看出，大部分 Radius 訪問時延集中到 50~100ms, 平均值為 比較理想。 在失敗的 Radius 失敗訪問中，主要存在兩種情況： ? Accounting Stop Request 無應答 ? Accounting Start Request 無應答 前一種情況占多數(shù)，這將會引起用戶端 IP 不能釋放，占用系統(tǒng)資源，如果策略不當還會引起串號、計費錯誤等問題。 優(yōu)化建議：建議 Radius 服務器采用相應的 Timeout 策略，對 Accounting Stop Request 請求采用較短的 Timeout 進行 計時。 DNS 性能分析 下 圖 是 5/22 14:00~17:00 區(qū)間里面排名前五位的 DNS 訪問 成功率和時延統(tǒng)計： 可以看 出 作為 現(xiàn)網 主要的 DNS 服務器，占了所有訪問量的％ ，并且 平均查詢 時延 為 ， 時延 性能及指標較好 ，其查詢成功率為％ ， 在所有的訪問失敗中 ‘請求無響應 ’占據(jù)了 ％ 。 作為次要的 DNS 服務器，承擔了 ％ 的 查詢 訪問量，平均訪問時延 劣于主用 DNS 服務器 為 。 TOP5 各 DNS 的訪問 查詢 量分布如下 圖 所示 ： 由上圖可以看到，現(xiàn)網排名前 5 的 DNS 占據(jù)了所有 DNS 訪問量的 91%。 在 DNS 的失敗訪問中 的 DNS 服務器比例相對較高，達到%。 下表是對現(xiàn)網 DNS Server 訪問失敗的原因及對查詢時延貢獻的分類： DNS R_Code Response_Code_Num DNS R_Code Rate(%) Response_Time(Avg) no error condition 172461 % name error 9194 % server failure 2755 % refused 401 % format error 153 % not implemented 85 % ? name error 這種 DNS Query 過程中的錯誤主要 是由于用戶輸入的Domain Name 有誤， DNS 無法查詢出對應的 IP 地址。 ? 用戶請求錯誤的 URI 異致的 錯誤舉例如下： URI DNS Status Query Failure Query Failure w Query Failure w Query Failure w Query Failure w Query Failure Query Failure ? server failure 錯誤主要是由于訪問量 過高 或 DNS Server 性能 存在 問題造成 用戶 查詢無回應，占到失敗整體的 %。 4 連接性能分析 ConnectReply 分析 Connect 時延分析 在 WAP 業(yè)務中， ConnectReply 過程在核心網上的信令流程如下圖： WAP Connect 時延是在 Gn 或 Gi 接口從手機上發(fā) Connect Request 開始，到在 Gn 或 Gi 接口收到 WAP 網關下發(fā) Connect Reply 信令之間的時間差。下面是對 Connect 過程時延 情況的分布圖： 如上圖所示在 Conenct 過程時延分布圖中， 82%請求時延小于 10ms，大于500ms 的請求也達到了 4%。這些大的時延很有可能導致終端用戶由于長時間等待而放棄業(yè)務，從而造成 WAP 業(yè)務成功率的下降，進而影響用戶業(yè)務體驗。 Connect 成功率分析 下表是 5 月 22 日 15:0017:00 的 Connect KPI 結果： Times Connect_Total Reply Total Ack Total Abort_Total Connect Reply Succ(%) Relpy_Delay_Time(Avg) 2020522 15:00 22072 21811 21435 273 % 2020522 16:00 101266 100175 98114 1494 % 2020522 17:00 2573 2527 2480 30 % 根據(jù)我們的統(tǒng)計，移動現(xiàn)網 Connect 成功率在 98%以上，從數(shù)據(jù)結果來看成功率較高。但仍然有一些異常的 Abort 影響了 Connect 的連接成功率，我們對在 Connect 過程中出現(xiàn)的 Abort 進行了 歸類。如下表所示： Connect Abort_Reason Abort_Reason_Count Abort_Peretage(%) Abort_Time(Avg) Abort_Type Session has been disconnected 1146 % User User request 542 % User Unknow n 50 % Provider Netw ork error 50 % User Invalid TID 7 % Provider No Response 2 % Provider 從以上可看出本次采集過程當中，在 Connect 請求至網關下發(fā) Connect Reply 間，上行方向的 User 原因產生的 Abort 取消占到 95％ 以上，其中又以 User Request 和 Session has been disconnected 兩種原因居多；下行方向的 Network原因產生的 Abort 消息主要以 Unknown 及 Invalid TID 消息為主。 CASE Analysis： User Request (%) — 用戶主動發(fā)起 在 Connect 過程中 User request 原因的 Abort 消息主要源于終端行為或用戶主動釋放，兩者可以通過該種原因 Abort 的時間分布來區(qū)分。 我們認為用戶的習慣性行為從發(fā)起連接請求到立即釋放的反應時間通常大于 1秒，小于 1 秒的大致可以推算為某些品牌手機終端的異常行為 造成 。 Connect 和 Abort消息間隔 4秒，影響用戶感知，用戶主動要求終止 從上圖的信令流程 中 可看出終端用戶在 16:59:20’627 向 WAP 網關發(fā)送Connect 請求消息，在 16:59:24’990 戶向網絡發(fā)出 Abort 消息，其中 Abort 原因為User Request。用戶發(fā)起的 Connect 請求與用戶發(fā)起的 Abort 間隔為 4363ms，應該是該用戶在短時間內未獲取到業(yè)務而主動放棄造成， User request 是典型的用戶行為， 在大多數(shù)情況下 與網絡傳輸及網絡質量沒有關系。 CASE Analysis: User Request (%) — 終端原因引發(fā) 以上信令流程可看出使用 MOTL7/ MIB/ Profile/品牌的終端用戶在 16:54:27’481 向 WAP 網關發(fā)送 Connect 請求消息，在間隔 36 毫秒又向網絡主動發(fā)起了 Abort 消息，其中的 Abort reason 為 User Request。在之后用戶又重新發(fā)起一次正常的 Connect 流程。出現(xiàn)這種情況我們大致可以推斷出可能是由于某些品牌手機軟件存在不穩(wěn)定因素而導致。 Connect 和Abort 消息 間隔僅 36毫秒 我們通過對 Connect 信令中的 UserAgent 字段進行了統(tǒng)計發(fā)現(xiàn)用戶在發(fā)起Connect 后在 1 秒內又發(fā)起 Abort 的手機終端多為摩托羅拉及索尼愛立信的幾種 品牌的手機： Mobile_Type_Main Abort_ReasonOfCount Abort_Rate(%) Abort_Time(Avg) MAUI MMS User Agent 266 % UNTRUSTED 108 % MOTL7 101 % MOTV3i 96 % MOTV3 72 % MAUI WAP Brow ser 56 % SonyEricssonW700c 35 % XJXNF420 34 % MOTL6 32 % SonyEricssonK750c 29 % 如果排除 User Request 對現(xiàn)網 Connect 成功率的影響，成功率將在原有基礎上提升 %左右。 CASE Analysis: Session has been disconnected(%)終端原 因引起 Session has been disconnected 該種 Abort 消息主要是由于用戶行為、終端性能以及無線網丟包造成的，終端往往在發(fā)了 Connect 后的極短時間里又發(fā)了Abort 消息，原因值為 Session has been disconnected，上圖為出現(xiàn)這種情況下的Session has been disconnected Abort 的詳細流程。 從以上流程可看出終端用戶使用終端 UA 為 MAUI MMS User Agent 在16:57:22’274 時向網關發(fā)起 Connect 請求消息 。在 WAP 網關還未來及發(fā)送Connect reply 消息前，幾科同時被終端取消，在這么短的時延理論上來說并不影響用戶的感知，而且用戶也很難在這么短的時延內主動取消業(yè)務。 CASE Analysis 續(xù) 1: Session has been disconnected(%)終端無響應 下圖為此次掛表數(shù)據(jù)中發(fā)現(xiàn)的由于終端無響應原因造成用戶端超時發(fā)起Session has been disconnected 的典型案例： 從以上可以流程可以看出終端 UA 為 MAUI MMS User Agent，連續(xù)發(fā) 送了 3次 Connect，并且收到網關回復的 Connect Reply。但是一直未得到終端的確認消息，計數(shù)器超時發(fā)送 Session has been disconnected 的 Abort 用于終止這個Session。 Connect 過程一直未收到終端發(fā)送的 Ack 歷時長達 30 秒 從中可以看出由于網絡原因未響應終端側請求也會導致終端重發(fā)超時后發(fā)起Session has been disconnected 的 Abort。 發(fā)起 Session has been disconnected 的終端排名： Mobile_Type_Main Abort_Reason Abort Rate(%) Abort_ReasonOfCount Reply_time MAUI MMS User Agent Session has been disconnected % 265 MAUI WAP Brow ser Session has been disconnected % 56 MOTL7 Session has been disconnected % 48 MOTV3i Session has been disconnected % 35 SonyEricssonW700c Session has been disconnected % 35 XJXNF420 Session has been disconnected % 34 SonyEricssonK750c Session has been disconnected % 29 MOTV3 Session has been disconnected % 27 SonyEricssonK700c Session has been disconnected % 21 CASE Analysis : Invalid TID (%)無效的 TID Invalid TID 這種 Abort 主要在終端與 WAP 的一個 Session 未