4、在USN9810的LMT客户端的USN网元下 ， 输入LST DNSN ， 查看相关配置如下 ， 主要查看FQDN构造：操作结果如下:-FQDN Host Name索引 网元类型 接口类型 S5接口协议类型TAC-LB01.TAC-HB00.TAC.EPC.MNC003.MCC460.3GPPNETWORK.ORG 1 SGW S11 GTPCTNET.APN.EPC.MNC003.MCC460.3GPPN 。

9、ETWORK.ORG 2 PGW S5 GTP(结果个数 = 2)从查询结果中看出 ， TAC的配置跟消息带上来的不一致 ， 消息中TAC为2541 ， 配置中为0001 ， 由该原因导致DNS解析失败 。
处理过程：1、添加TAC对应的TALST(ADD TALST)：ADD TALST: TALISTID=1, TAI=460032541, DESC=to-S1;
2、添加DNS的A解析记录（ADD IPV4DNSH ， 如果之前配置 ， 则无需再加）：ADD IPV4DNSH: HSINDEX=1, HOSTNAME=topon.s11.gw0101-b-hw.xtx, ADDRSECTION=SECTION1, I 。

10、PV4ADDR1=115.169.148.178, PRIORITY1=127, WEIGHT1=127;
3、添加DNS的NAPTR解析记录（ADD DNSN) ， 保证TAC配置正确 ， 并且跟A记录的主机名索引保持一致:ADD DNSN: FQDN=TAC-LB41.TAC-HB25.TAC.epc.mnc011.mcc460.3gppnetwork.org, HSINDEX=1, ENTITY=SGW, INTYPE=S11, S5PROTOCOL=GTP, S8PROTOCOL=GTP, PRIORITY=0, WEIGHT=100;
执行完以上三步后 ， 用户可以正常上网 。
建议与总结：配置置USN 。

【特选材料|华为核心侧案例集[特选材料]】11、9810的数据时 ， 要严格按照数据规划完整的添加需要配置的TALST ， 并正确添加相应的DNS数据配置 。
A解析记录中 ， 主要注意正确配置主机名与相应网元（SGW、PGW等）的IP地址对应关系 ， NAPTR解析记录中 ， 主要注意正确配置TAC ， 正确引用A解析记录 。
案例3：PCC配置错误导致UGW基于三四层专有承载无法建立问题现象描述：按照UGW9811 V900R010C01SPC520T的设备验收测试手册 ， 有一项基于三四层专有承载的建立 ， 配置三四层规则 ， 并将相应的user-profile-group绑定到apn下 ， 测试时 ， 需要由UGW触发专有承载建立 ， 但专有承载未建立 。
以上配置数据配置完毕后 ， 数据卡连接 。

12、网络 ， 在电脑上ping公网地址 ， 专有承载没有建立 。
告警信息：无原因分析：1、网络侧触发专有承载的建立有三种方式： （1)PCC动态用户由PCRF下发动态规则触发专有承载建立； （2)PCC静态用户由PCRF下发预定义规则触发专有承载建立； （3)PCC静态用户由UGW触发专有承载建立； 该项测试中使用第三种方式触发专有承载 。
2、跟踪消息中发现用户再激活时向PCRF发送了CCR消息 ， 并且PCRF回了CCA消息（CCR/CCA通过DRA转接） ， 如图1所示 ， 并且CCA消息显示该用户未在PCRF中签约； 图1 3、对于PCC静态用户由PGW发起专有承载建立的原则为 ， 用户上线后 ， 不应该向PCRF发起 。

13、CCR ， 而是根据APN下绑定的user-profile-group匹配相应规则进行专有承载的建立 ， 但APN下的PCC开关必须打开 ， 因为在V900R010C01SPC520T 版本中 ， 非PCC用户无法建立专有承载； 4、如果UGW向PCRF发起CCR ， 那么UGW就会以第二种方式建立专有承载（PCC静态用户由PCRF下发预定义规则触发专有承载建立 ） ， 而不会匹配APN下的user-profile-group ， CCA中没有下发预定义规则名 ， 规则匹配失败 ， 专有承载未建立； 5、UGW为什么会向PCRF发起CCR ， 通过检查APN下的配置发现 ， APN下绑定了如下两条命令： realm-binding ap 。

14、plication gx realm epc.mnc011.mcc460.3gppnetwork.org pcc-template-binding pcc_template_1 第一条为APN下绑定的到PCRF的域路由 ， 第二条为APN下绑定的PCC模板 ， 如此一来 ， 当用户在该APN下激活时 ， UGW都要到PCRF申请用户策略 ， 所以向PCRF发起CCR ， 并期望CCA中回复策略 ， CCA中没有策略 ， 专有承载无法建立；处理过程：将APN下的PCRF域路由和PCC模板删掉 ， 然后用户下线重新上线 ， 在电脑上ping公网地址 ， 专有承载建立成功 ， 如下图所示： UGW向MME发起create bear request 。

15、 ， MME向UGW回复create bear response ， 并且UGW没有向PCRF发起消息； 案例点评：对于基于三四层和七层的专有建立 ， 首先必须要在APN下打开PCC开关 ， 非PCC用户无法建立专有承载；其次要删掉PCRF相关的PCC模板和域路由 ， 否则UGW会向PCRF请求策略 ， 如果PCRF没有给该用户签约或未配置相应的预定义规则 ， 专有承载不会建立；最后UGW上的相应DPI规则要配置正确 。
案例4：X国TAU被拒绝 ， 原因为UE identity cannot be derived by the network现象描述：X国反馈从在TAU流程中被MME拒绝 ， 原因值为UE identity can 。

16、not be derived by the network 。
告警信息：无 原因分析：1) UE驻留在LTE ， 发起CSFB流程2) UE回落后 ， 在2/3G SGSN发起了RAU ， 到本端查询上下文信息 ， 可以看到对端SGSN的地址为C9 17 AF C1 ， 也就是201.23.175.1933) UE完成CS业务后 ， TAU回4G ， 为了获取上下文信息 ， 需要通过DNS查询2/3G SGSN的地址4) 使用DNS查询结果中的地址C9.17.BF.0C(201.23.191.12)发起SGSN Context Request,但是对端返回失败 ， 原因为cause-ie:imsi-not-known (194)5 。

来源：(未知)

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

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