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

はじめに

このドキュメントでは、4G Attach Success Rate(ASR)Key Performance Indicator(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

トラブルシューティングシーケンス

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の計算に使用されるカウンタが複数あるため、bulkstatsから、各カウンタのKPIの傾向を確認する必要があります。

3.問題のないタイムラインおよび問題のあるタイムラインと比較されるKPIトレンド。

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

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 
    
    
        ---------- 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 
    
    
      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 
     
       _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 
       
       
 
       
So in this error event 
       
 
       
facility :: sessmgr 
       
event ID = 141027 
       
line number = 10068 
       
      
    

この問題をトラブルシューティングするには、次に示すさまざまな手順を実行します。