KPI低下のトラブルシューティング：4G ASR

はじめに

このドキュメントでは、4Gの接続成功率(ASR)の主要業績評価指標(KPI)の低下をトラブルシューティングする方法について説明します。

考えられるシナリオ

4G ASRの劣化は、次の複数の要因によって発生する可能性があります。 

1. ネットワークの問題
2. コールフロー固有の問題
3. ノード固有の問題
4. 設定の問題
5. RAN終了の問題

初期分析に必要なログ

1. 品質低下を強調表示するKPIトレンドグラフ。
2. 測定に使用されるKPIフォーミュラ。
3. 未処理のバルクスタットカウンタと、この問題が始まってから発生したコードの傾向。
4. 問題が発生している間に30分間隔でキャプチャされたShow Support Details(SSD)の2つのインスタンス。
5. 品質低下の2時間前から現在までの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. 問題のないタイムラインや問題のあるタイムラインと比較されるKPIトレンド

4. KPI式から問題のあるバルクスタットカウンタが特定されたら、このカウンタがフローに基づいてどのように定義されているかを確認し、パターンを確立する必要があります。 

5. また、3分から5分の間隔で複数回の反復を行って、ノードから切断理由を収集します。

異なるタイムスタンプで収集された2つのSSDからの切断理由の差分を確認できます。デルタ接続解除によって急速に増加する接続解除理由は、KPIの低下の原因である可能性があります。また、すべての接続解除については、シスコの『Statistics and Counters Reference』(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. デバッグログから何らかの手がかりが得られたら、エラーログが記録されている特定のイベントのコアファイルをキャプチャすることもできます。

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

この問題をトラブルシューティングするには、さまざまな手順があります。