案例点评：此类问题一般情况下是信 。

25、元带的不正确导致的 ， 可先参考协议进行排查 。
案例7：DNS server和DNSN中主机名命名不同 ， 导致EnodeB间切换失败现象描述：T国B局点phase 0 新建两个PS站点 ， 配置分别为1*USN+1*UGW+2DNS ， 在PAT测试阶段 ， 发现EnodeB之间切换失败 ， UGW上打印出来的消息为SP Change to SP fail ， USN上流程失败在HO preparation failure 。
告警信息：无原因分析：1、从USN和UGW trace上发现 ， UGW 在create session response消息中拒绝了建立会话请求 。
UGW上面打印出来的免维护消息是“SP change。

26、to SP failure” 。
2、对比HO流程中建立会话请求消息和附着流程中建立会话请求消息发现 ， SGW地址相同（0A 50 82 3E） 。
根据Enodeb切换流程 ， 如果服务的SGW不变 ， 不应该发起create session request消息 。
总结：MME 在此发起了错误的create session request流程 ， 该用户已经在此SGW中建立了一个默认会话 ， 所以SGW返回reject ， 从而HO失败 。
处理过程： 1、为什么服务的SGW地址一样 ， MME依然发起create session request流程？查看DNS请求消息发现HO流程中DNS请求消息携带的是改变了的TAC和att 。

27、ach流程中DNS查询结果 。
2、DNS查询结果如下所示 ， DNS返回的是通过TAC查询出的SGW的hostname ， 并且和上次的hostname不一样 。
3、查看USN和DNS配置发现“TAC-LB2A.TAC- HB23.TAC.EPC.MNC004.MCC520.3GPPNETWORK.ORG”FQDN是在USN DNSN中配置的 ， 而TAC-LB2C.TAC-HB23.TAC.EPC.MNC004.MCC520.3GPPNETWORK.ORG是在 server中配置了 ， 而两边配置的hostname名字不一样 。
4、删除USN 中DNSN配置 ， 将TAC-LB2A.TAC-HB23.TAC.EPC 。

28、.MNC004.MCC520.3GPPNETWORK.ORG配置加入至DNS server中 ， 再次测试切换 ， 问题得到解决 。
建议与总结：MME不是根据SGW IP地址决定是否SGW是否改变 ， 而是根据解析的hostname 。
理解流程细节 ， 能够有效的解决问题 。
案例8：友商SGW Delete Session Request报文中bearer-id错误导致会话去活失败 现象描述：我司UGW9811 V900R001C05作为PGW ， 与N公司SGW做对接测试 。
信令交互过程如图1：图中最后PGW发给SGW的Delete Session Response消息中回复失败 ， 原因值为context-not-fou 。

29、nd ， 如图2：告警信息：无原因分析：1） PGW回复失败消息 ， 从PGW入手 ， 查看失败原因值 ， 为context-not-found 。
2） 在PGW上access-view下执行display pdpcontext命令 ， 发现存在缺省承载 ， 没有专有承载 。
3） 查看对应的请求消息 ， 即SGW发给PGW的Delete Session Request消息 ， 发现eps-bearer-id值为0x6 ， 为专有承载 ， 如图3 。
前面通过display pdpcontext命令查询已经知道只有缺省承载 ， 因此必然找不到上下文而失败 。
4） 分析此时PGW上只有缺省承载是否正确：从图1中的信令交互过程 ， SGW已经通过Delet 。

30、e Bearer Command消息出发PGW删除之前建立的专有承载 ， 因此此时已经没有专有承载 ， SGW的eps-bearer-id值是错误的 。
5） 按协议描述 ， SGW不会发送Delete Bearer Request消息 ， 只有Delete Session Request消息的场景 ， 而Delete Session Request消息请求删除会话 ， 携带的eps-bearer-id只能为0x5 。
6） 进一步测试 ， 发现如果没有建立过专有承载 ， 则SGW在Delete Bearer Request消息中携带的eps-bearer-id值为0x5 ， 可见SGW的实现上对该信元的值只增不减 ， 导致问题出现 。
处理过 。

31、程： SGW侧通过补丁修改Delete Session Request消息中eps-bearer-id信元值为0x5 ， 问题解决 。
案例点评：对于信令交互失败类问题 ， 先从回复失败消息的信元入手 ， 通过分析失败原因值、内部调试信息计数器 ， 找到失败原因 ， 从信令交互消息中确认交互失败的根因在哪个信元 ， 对症下药 ， 最终解决问题 。
案例9：UGW配置专有承载规则后附着失败现象描述：某实验局中 ， 配置完USN、UGW后 ， 用户附着正常 。
增加专有承载配置完成后 ， 初始的时候 ， 专有承载能正常建立 ， 但第二天继续测试的时候 ， MME拒掉UE附着 ， 默认承载建立失败 ， 提示错误为network failure 。
告警信息：无原因分析：第一 。

32、天测试完后 ， 到第二天重新测试期间 ， 设备没有做任何改动 ， 也看不到任何新增告警 。
分析认为没有加识别库 ， 因此无法建立专有承载；但是加载协议识别库后 ， 依旧不能成功附着 。
处理过程： 后发现未添加兜底过滤器 ， 添加filter filter-any l34-protocol any后 ， 设备附着成功 ， 专有承载激活成功 。
案例点评：兜底规则 ， 没有增加兜底规则 ， 设备无法附着 ， 导致没法激活 。

来源：(未知)

【学习资料】网址：/a/2021/0321/0021743012.html

标题：特选材料|华为核心侧案例集[特选材料]( 四 )