S11 KPI低下のトラブルシューティング

はじめに

このドキュメントでは、S11主要業績評価指標(KPI)の品質低下の問題をトラブルシューティングする方法について説明します。

概要

S11は、Long Term Evolution(LTE)ネットワークでモビリティマネージメントエンティティ(MME)とサービングゲートウェイ(SGW)を接続するインターフェイスです。このインターフェイスは、GnまたはGPRS Tunneling Protocol-Control(GTP-C)を使用します。

S11インターフェイスのメッセージ 

• セッション要求/応答の作成
• セッション要求/応答の変更
• セッション要求/応答の削除

EPSセッションの確立

• S11 KPIの低下は、根本原因となる必要があるCSRの試行よりも多くのCreate Session Requests(CSR)の拒否が確認された場合に観察されます。

KPIの測定に使用される式を把握し、式に含まれるすべてのカウンタをメモし、劣化の原因となる正確なカウンタを特定できます。

S11 ASR (SPGW)  = ((tun-sent-cresessrespaccept+ggsn_tun-sent-cresessrespdeniedUserAuthFailed+tun-sent-cresessrespdeniedPrefPdnTypeUnsupported+tun-sent-cresessrespdeniedCtxtNotFound)/EGTPC-ggsn_tun-recv-cresess)*100

PDN Connectivity Success Rate (MME) : ((%esmevent-pdncon-success%) + (%esm-msgtx-pdncon-rej%))*) / (%esmevent-pdncon-attempt%) *100)

注：計算式は、測定方法によって異なります。

初期レベルで必要なログ：

• 品質低下を示すKPIトレンド。
• 使用されているKPIフォーミュラ。

• 未処理のバルクスタットカウンタと問題の開始時からのコードの傾向。
• 問題が発生する期間に30分間隔でノードからShow Support Details(SSD)の2つのインスタンスをキャプチャします。
• Syslogの時間は、品質低下が発生する2時間前から現在の時刻までの範囲でした。 mon sub/pro traces  と  logging monitor msid  を参照。

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

1. S11 KPI式に含まれる各カウンタのKPIトレンドをバルクスタットを分析して評価します。

2. 問題のあるタイムラインと問題のないタイムラインの間のKPIトレンドを比較します。

3. 特定された問題のあるbulkstatカウンタがフローに基づいてどのように定義されているかを調べ、パターンを確立します。

4. 3 ～ 5分の間隔で複数回の反復を通じてノードから切断理由を収集します。

異なるタイムスタンプで収集された2つのSSD間の切断理由のデルタを分析できます。デルタ値の大幅な増加を示す切断理由は、KPIの低下の原因と考えられます。すべての切断理由の詳細については、次のCisco Statistics and Counters Referenceを参照してください。 https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/21-23/Stat-Count-Reference/21-23-show-comman..

show session disconnect-reasons verbose

5.対象のノードのタイプに基づいて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

 6. 問題を引き起こしている特定のカウンタを特定したら、mon-sub/mon-proコールトレースをキャプチャして、KPIの低下を引き起こしている特定のコールフローをさらに分析し、特定する必要があります。さらに、外部ツールを使用してWiresharkトレースを取得し、より詳細な分析を行うこともできます。

Monサブトレースをキャプチャするコマンドは次のとおりです。 

monitor subscriber with options 19, 26,33, 34, 35, 49,A,S, X, Y, verbosity +5 during the issue.

mon-pro with options 19, 26,33, 34, 35, 49,A,S, X, Y, verbosity +5 during the issue if no mon-sub is present.

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

KPIの低下の割合が最小限であるためにmon-subのようなトレースのキャプチャが実行できない場合は、代わりにシステムレベルのデバッグログをキャプチャする必要があります。これには、sessmgrとegptcのデバッグログのキャプチャ、および必要に応じたゲートウェイ固有のフローのキャプチャが含まれます。

logging filter active facility sessmgr level debug 
logging filter active facility egtpc level debug
logging filter active facility sgw level debug
logging filter active facility pgw level debug

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

7.デバッグログを分析した後、問題の原因を特定した場合は、エラーログを確認する特定のイベントのコアファイルのキャプチャに進むことができます。

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: INLAND_PTL_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 
       
      
    

警告:デバッグログ、logging monitor、mon-sub、mon-proなどのログの収集を要求する場合は常に、これらのログがメンテナンスウィンドウ中に収集されるようにすることが重要です。また、この間にCPU負荷を監視することも重要です。

症状の分析と特定

• 最初に、SSDからシステムに頻繁なクラッシュが見られるかどうかを確認します。

show crash list

• ライセンスの問題が発生したかどうかを確認してください。場合によっては、Serving Packet Data Gateway(SPGW)のライセンスが期限切れになると、新しいコールを受け入れることができなくなり、その結果、コールが失敗し、S11の劣化またはディップが発生します。

show resource info

• メモリまたはCPUの使用率が高いために、警告/超過状態のsessmgrインスタンスが複数あるかどうかを確認してください。このようなインスタンスが見つかった場合は、次の条件が原因で新しいコールが拒否されているかどうかを確認します。
• デバッグログから、どのインターフェイスでコール拒否エラーが発生したかを確認できます。

「sgw-egress」コンテキストで特定のサブスクライバに対して大量のコール拒否エラーが発生し、続いて「sgw-ingress」コンテキストで同じサブスクライバが拒否された場合は、Packet Data Gateway(PGW)からの拒否がS11コンテキストでSGW-> MMEに送信されると推測できます。PGW側からさらに確認してトラブルシューティングを行うために、このIMSIのmon-subを取得できるようになりました。

2022-Nov-26+00:20:51.763 [egtpc 141018 unusual] [7/0/16871 
    
    
      _handler_func.c:3227] [context: gwctx, contextID: 2] [software internal user syslog] [sgw-egress] For IMSI: 427021600263284, create session request is rejected by the peer with cause EGTP_CAUSE_NO_RESOURCES_AVAILABLE 2022-Nov-26+00:20:51.763 [egtpc 141018 unusual] [7/0/16871 
     
       _handler_func.c:2505] [context: gwctx, contextID: 2] [software internal user syslog] [sgw-ingress] For IMSI: 427021600263284, create session request is rejected by the SAP user with cause EGTPC_REASON_UNKNOWN 
      
    

• KPIディップに対して複数の拒否理由が存在する場合があるため、各理由を個別に確認し、それに従って処理を進める必要があります。

たとえば、  no_resource_available/user_auth_failure  特定のInternational Mobile Subscriber Identity(IMSI)シリーズ（インローマー加入者向け）のエラーが増加するため、PGWから確認する必要があります。次のような理由が考えられます remote peer not responding SGWでタイムアウトするセッション要求を作成すると、S11 KPIが低下する可能性があります。この作成セッションは、次の名前で拒否される可能性があります： No_resource_available SGWからMMEに向かいますこれらの拒否原因コードは、モニタプロトコルログから確認できます。また、Create Session RequestおよびCreate Session Responsesをチェックして、これらの拒否原因コードの送信元である特定のIPアドレスを特定できます。