对S11 KPI降级进行故障排除
简介
本文档介绍如何对S11关键性能指标(KPI)降级问题进行故障排除。
概述
S11是连接长期演进(LTE)网络中的移动管理实体(MME)和服务网关(SGW)的接口。该接口使用Gn或GPRS隧道协议控制(GTP-C)。
S11接口中的消息
- 创建会话请求/响应
- 修改会话请求/响应
- 删除会话请求/响应
EPS会话建立：
- 与其CSR尝试相比，当您看到更多创建会话请求(CSR)拒绝（必须是根本原因）时，会发现S11 KPI下降。
您可以了解用于度量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分钟的时间间隔从节点捕获两个显示支持详细信息(SSD)实例。
- 系统日志的范围从降级发生之前的两小时到当前时间。
mon sub/pro traces和logging monitor msid <imsi>。
故障排除顺序
故障排除顺序-
通过分析批量统计数据，评估S11 KPI公式中涉及的每个计数器的KPI趋势。
-
比较有问题的时间表期间的KPI趋势与无问题的时间表。
-
检查如何根据流量定义确定的问题批量统计数据计数器，并建立任何模式。
-
通过3至5分钟的多次迭代从节点收集断开原因。
您可以分析在不同的时间戳上收集的两个SSD之间的断开原因差异。显示增量值显著增加的断开原因可以视为KPI降级的原因。有关所有断开原因的详细说明，请参阅此处的《思科统计数据和计数器参考》：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 verbose5. 根据节点类型检查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 logs7. 在分析调试日志后，如果您确定问题的原因，您可以继续捕获观察错误日志的特定事件的核心文件。
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: 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 <Host:x.x.x.x, Port:31456, seq_num:82011>
So in this error event
facility :: sessmgr
event ID = 141027
line number = 10068
警告：每当请求收集日志（如调试日志、日志记录监控器、mon-sub或mon-pro）时，请确保在维护时段内收集这些日志，这一点非常重要。此外，监控这段时间的CPU负载也至关重要。
症状的分析和鉴定
症状的分析和鉴定- 首先，检查SSD在系统中是否检测到任何频繁崩溃。
show crash list
- 请验证是否遇到了任何许可证问题。在某些情况下，当服务数据包数据网关(SPGW)的许可证过期时，它将无法再接受新呼叫，从而导致呼叫失败并导致S11降级或下降。
show resource info
- 请验证是否由于内存或CPU使用率高而处于警告/超时状态的多个sessmgr实例。如果发现此类实例，请检查是否由于这些条件而拒绝新呼叫。
- 从调试日志中，您可以检查哪个接口上的呼叫被拒绝错误。
如果特定用户在“sgw-egress”上下文中发生大量呼叫拒绝错误，随后同一用户在“sgw-ingress”上下文中被拒绝，则可以推断数据包数据网关(PGW)的拒绝被发送到S11上下文中的SGW-> MME。要从PGW端进行进一步确认和故障排除，现在您可以为此IMSI执行监控子操作。
2022-Nov-26+00:20:51.763 [egtpc 141018 unusual] [7/0/16871 <sessmgr:579> _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 <sessmgr:579> _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 dip可能有多个拒绝原因，因此您需要分别检查每个原因并相应地继续。
no_resource_available/user_auth_failure
例如，对于漫游用户，某些International Mobile Subscriber Identity (IMSI)系列可能会出现错误增加，因此需要从PGW检查这些错误。可能由于remote peer not responding等原因导致创建会话请求在SGW超时，从而导致S11 KPI性能下降。此创建会话可能会被从SGW到MME以No_resource_available形式拒绝。可以从监控协议日志中观察到这些拒绝原因代码，您可以检查Create Session Request和Create Session Responses，以确定从中发送这些拒绝原因代码的特定IP地址。
修订历史记录
| 版本 | 发布日期 | 备注 |
|---|---|---|
1.0 |
18-Jun-2023 |
初始版本 |
反馈