目錄

簡介

可能的案例

初始分析所需的日誌

疑難排解順序

簡介

本文檔介紹如何排除4G配售成功率(ASR)關鍵效能指標(KPI)下降故障。

可能的案例

4G ASR效能下降可能由多種因素引起：

1. 網路問題

2. 呼叫流特定問題

3. 特定於節點的問題

4. 配置問題

5. RAN結束問題

初始分析所需的日誌

1. 突出顯示降級的KPI趨勢圖。

2. 用於測量的KPI公式。

3. 自問題開始以來，原始批次統計資料計數器和原因代碼趨勢。

4. 在問題時段內，以30分鐘間隔捕獲兩個顯示支援詳細資訊(SSD)例項。

5. 從降級前兩小時到當前時間收集的Syslog。

6. 捕獲以下日誌：

- Mon-sub/pro traces

- Logging monitor msid <imsi>

疑難排解順序

1. 確定ASR公式：

1-((emm-msgtx-decode-failure+emm-msgtx-attach-rej-gw-reject+emm-msgtx-attach-rej-activation-reject+emm-msgtx-attach-rej-svc-temp-out-of-order+emm-msgtx-attach-rej-protocol-error+emm-msgtx-attach-auth-failed+attach-proc-fail-max-retx-auth-req+attach-proc-fail-max-retx-sec-mode-cmd+attach-proc-fail-max-retx-attach-accept+attach-proc-fail-setup-timeout-exp+attach-proc-fail-sctp-fail+attach-proc-fail-guard-timeout-exp+attach-proc-fail-max-retx-esm-info-req+emm-msgtx-attach-rej-gw-auth-failed+emm-msgtx-attach-rej-insuff-resources+emm-msgtx-attach-reject-congestion+emm-msgtx-attach-reject-severe-network-failure+emm-msgtx-network-failure ) / (epsattach-imsi-attempted+epsattach-guti-local-attempted+epsattach-guti-foreign-attempted+epsattach-ptmsi-attempted+combinedattach-imsi-attempted+combinedattach-guti-local-attached+combinedattach-guti-foreign-attempted+combinedattach-ptmsi-attempted))

注意：公式會根據「客戶」測量KPI的方式而有所不同。

2. 根據公式，有多個計數器可用於計算ASR，因此從批次統計資料中，您需要檢查每個計數器的KPI趨勢。

3. 要與沒有問題的時間表和有問題的時間表進行比較的重要績效指標趨勢。

4. 從KPI公式辨識出有問題的批次統計資料計數器後，您需要檢查此計數器如何根據流程進行定義並嘗試建立模式。

5. 此外，請收集來自具有多重反覆專案（時間間隔為3至5分鐘）的節點的中斷連線原因。

您可以透過兩個不同時間戳記收集的SSD找到中斷連線原因的差異。與Delta斷開連線的斷開原因迅速增加可以歸因於KPI降級的原因。此外，有關所有斷開連線的說明，請參閱Cisco統計資訊和計數器參考；https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/21-23/Stat-Count-Reference/21-23-show-command-output/m_showsession.html。

show session disconnect-reasons verbose

以下是解決因斷開連線原因「MME-HSS-User-Unknown」增加而導致效能下降的問題的故障排除步驟示例。請參閱https://www.cisco.com/c/en/us/support/docs/wireless/mme-mobility-management-entity/214633-troubleshoot-4g-asr-kpi-degradation-due.html。

6. 根據節點型別檢查egtp統計資料。

--- SGW end -----

show egtpc statistics interface sgw-ingress path-failure-reasons

show egtpc statistics interface sgw-ingress summary

show egtpc statistics interface sgw-ingress verbose

show egtpc statistics interface sgw-ingress sessmgr-only

show egtpc statistics interface sgw-egress path-failure-reasons

show egtpc statistics interface sgw-egress summary

show egtpc statistics interface sgw-egress verbose

show egtpc statistics interface sgw-egress sessmgr-only

---- PGW end -----

show egtpc statistics interface pgw-ingress path-failure-reasons

show egtpc statistics interface sgw-ingress summary

show egtpc statistics interface sgw-ingress verbose

show egtpc statistics interface sgw-ingress sessmgr-only

--- MME end -----

show egtpc statistics interface mme path-failure-reasons

show egtpc statistics interface mme summary

show egtpc statistics interface mme verbose

show egtpc statistics interface mme sessmgr-only

7. 要進一步分析和排除KPI降級故障，請捕獲mon-sub/mon pro呼叫跟蹤，並考慮使用外部工具獲取Wireshark跟蹤。這些跟蹤有助於確定導致問題的特定呼叫流。

用於捕獲Mon子蹤跡的命令如下：

monitor subscriber imsi <IMSI number>  ---------- verosity level +++++,A, S, X, Y, 19. 26, 33, 34, 35

More options can be enabled depending on the protocol or call flow we need to capture specifically

8. 如果由於KPI降級百分比很小而無法捕獲mon-sub之類的跟蹤，則捕獲系統級別的調試日誌。此外，捕獲sessmgr和egptc的調試日誌，如果可疑問題涉及HSS/RAN等實體，則根據特定問題捕獲s1-ap/diameter的調試日誌。

logging filter active facility sessmgr level debug

logging filter active facility egtpc level debug

logging filter active facility diameter level debug ----- depending on scenario

logging filter active facility s1-ap evel debug ----- depending on scenario

logging active ----------------- to enable

no logging active ------------- to disable

Note :: Debugging logs can increase CPU utilization so need to keep a watch while executing debugging logs

9. 一旦您從debuglogs中取得任何線索，您就可以針對您看到錯誤日誌的特定事件擷取核心檔案：

logging enable-debug facility sessmgr instance <instance-ID> eventid 11176 line-number 3219 collect-cores 1

For example :: consider we are getting below error log in debug logs which we suspect can be a cause of issue

and we don;t have any call trace

[egtpc 141027 info] [15/0/6045 <sessmgr:93> _handler_func.c:10068] [context: MME01, contextID: 6] [software internal user syslog] [mme-egress] Sending reject response for the message EGTP_MSG_UPDATE_BEARER_REQUEST with cause EGTP_CAUSE_NO_RESOURCES_AVAILABLE to <Host:x.x.x.x, Port:31456, seq_num:82011>

So in this error event

facility :: sessmgr

event ID = 141027

line number = 10068

以下是排除此問題的各個步驟。