华为核心侧标准规定样式分析集.docx

华为核心侧标准规定样式分析集.docx

《华为核心侧标准规定样式分析集.docx》由会员分享，可在线阅读，更多相关《华为核心侧标准规定样式分析集.docx（25页珍藏版）》请在冰豆网上搜索。

华为核心侧标准规定样式分析集

案例1：

鉴权配置错误导致4G用户附着失败

现象描述：

U国某局点反映用运营商4G旧终端能够上网，而用新终端（如华为AscendP1LTE、E392及其他终端）不能附着到网络，所以需要分析是什么原因导致新终端附着不到网络。

USN版本：

V900R011C01SPC300

告警信息：

原因分析：

USN上的告警时GTPC隧道路径断，查看USN配置，发现37.110.209.209的地址描述是DESC="Gn/S10/S11controlplane"，基本可以排除问题是由此告警导致的。

从问题现象来看，可能的原因有：

1）终端的问题。

2）USN少配置数据，导致新终端不能接入网络。

3）HSS签约数据问题，可能限制了终端的类型，导致某类终端不能接入4G网络。

处理过程：

1）查看新终端附着不成功的跟踪文件，发现失败原因都是eMM-cause:

uE-security-capabilities-mismatch，UE的安全能力不匹配，很有可能是加密没有开启导致的。

2）查看配置ADDS1USRSECPARA:

IMSIPRE="DEFAULT",SECPLC=NEVER;设置了所有的用户都不鉴权加密，按照协议规定，所有的4G用户都是应该开启鉴权加密的，产品文档也写了的。

所以开启鉴权加密进行测试。

3）开启鉴权加密后，测试仍然失败，失败原因值是eMM-cause:

message-not-compatible-with-the-protocol-state，当前协议状态下消息不可得。

从后面的消息中又发现了timeout的现象，超时原因是等待attachcomplete消息超时

4）查看协议23401，第23步，协议规定MME在收到 InitialContextResponse消息和AttachComplete后才会给SGW发送ModifyBearerRequest消息，很显然，问题出现在UE没有及时的给MME发送attachcomplete消息。

23.Uponreceptionofboth,theInitialContextResponsemessageinstep21andtheAttachCompletemessageinstep 22,thenewMMEsendsaModifyBearerRequest（EPSBearerIdentity,eNodeBaddress,eNodeBTEID,HandoverIndication）messagetotheServingGW.

5）旧终端是上的了网的，所以问题肯定在新终端上，那是不是因为新终端有问题呢，不支持协议？

问题陷入了僵局。

这个时候用旧的终端连4G网络，发现也上不了网了。

问题一下子陷入了两难。

观察跟踪文件。

HSS回复鉴权拒绝的消息给MME。

6）询问一线测试工程师，发现他是RMVUSR之后出现旧终端测试失败的，那么用新终端测试会是怎么样呢？

新终端测试仍然拒绝，而且原因值和旧终端一致，鉴权拒绝。

看来问题终于有了一致性了。

7）用旧终端不开启鉴权保护能上网，开启了鉴权保护就不能上网，而且原因值是鉴

权拒绝，那么问题应该是出现在HSS上了，和HSS工程师做过沟通之后，发现他选的卡的类型是SIM，而不是USIM，按照之前2/3G的概念，SIM卡鉴权是取3元组的，而4GEPC网络鉴权是4元组，而USN现在还不支持3元组向4元组进行转换，所以鉴权肯定是失败的。

所以3GPP协议推荐4G里面选USIM卡，这样3G用户就能够顺利过渡到4G这是因为3G里面的鉴权5元组能够转为4元组。

8）将卡的类型变更为USIM后，新旧终端都能够接入网络了。

案例点评：

从整个问题的处理看，纠结于终端的原因花了很长的时间，但是后面终于还是发现了鉴权拒绝的原因，从而根因于HSS签约数据的问题，4G网络中使用的卡的类型不再是SIM卡。

EPC网络现在要求都是鉴权加密，所以现在的时候也都支持加密。

此案例中新终端是强制了加密的，旧终端没有强制，所以用SIM卡附着新终端是上不了网，而不强制加密的旧终端则能上网。

案例2：

USN9810未配置相应TAC导致用户附着失败问题

现象描述：

新建局LTE网络，无线侧安装完站点后，用户测试上网失败，无线侧跟踪消息显示，用户附着被拒绝，无法上网。

告警信息：

无

原因分析：

登陆USN9810，打开用户跟踪对话框，输入用户IMSI号码跟踪消息：

1、从跟踪到的消息看到下图信息；                 

                           UE发起AttachRequset消息，并且MME向HSS发起鉴权请求（AuthenticationInformationRequest）得到响应（AuthenticationInformationAnswer），由MME向HSS发起的跟踪区更新请求消息看出，UE鉴权通过HSS的签约数据没有问题。

2、从跟踪消息中看到如下图信息：

UE附着被拒绝（AttachReject），双击该条消息，从具体信息中得到下图信息，

用户被拒绝是由于APN未知或错误。

3、根据2步骤定位的原因，直接找到SM-DNS的解析消息：

 双击SM-DNS的消息，从具体信息中得到如下图的信息，

        从图中看到要解析的两个FQDN（由APN和TAC构造所得），具体配置在ADDDNSN命令下。

4、在USN9810的LMT客户端的USN网元下，输入LSTDNSN，查看相关配置如下，主要查看FQDN构造：

操作结果如下:

-------------------------

FQDN                           HostName索引  网元类型 接口类型 S5接口协议类型 

TAC-LB01.TAC-HB00.TAC.EPC.MNC003.MCC460.3GPPNETWORK.ORG 1             SGW    S11            GTP            CTNET.APN.EPC.MNC003.MCC460.3GPPNETWORK.ORG                   2             PGW    S5              GTP         

（结果个数=2）

从查询结果中看出，TAC的配置跟消息带上来的不一致，消息中TAC为2541，配置中为0001，由该原因导致DNS解析失败。

处理过程：

1、添加TAC对应的TALST（ADDTALST）：

ADDTALST:

TALISTID=1,TAI="460032541",DESC="to-S1";

2、添加DNS的A解析记录（ADDIPV4DNSH，如果之前配置，则无需再加）：

ADDIPV4DNSH:

HSINDEX=1,HOSTNAME="topon.s11.gw0101-b-hw.xtx",ADDRSECTION=SECTION1,IPV4ADDR1="115.169.148.178",PRIORITY1=127,WEIGHT1=127;

3、添加DNS的NAPTR解析记录（ADDDNSN），保证TAC配置正确，并且跟A记录的主机名索引保持一致:

ADDDNSN:

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; 

 执行完以上三步后，用户可以正常上网。

建议与总结：

配置置USN9810的数据时，要严格按照数据规划完整的添加需要配置的TALST，并正确添加相应的DNS数据配置。

A解析记录中，主要注意正确配置主机名与相应网元（SGW、PGW等）的IP地址对应关系，NAPTR解析记录中，主要注意正确配置TAC，正确引用A解析记录。

案例3：

PCC配置错误导致UGW基于三四层专有承载无法建立问题

现象描述：

按照UGW9811V900R010C01SPC520T的设备验收测试手册，有一项基于三四层专有承载的建立，配置三四层规则，并将相应的user-profile-group绑定到apn下，测试时，需要由UGW触发专有承载建立，但专有承载未建立。

以上配置数据配置完毕后，数据卡连接网络，在电脑上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发起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-bindingapplicationgxrealmepc.mnc011.mcc460.3gppnetwork.org

pcc-template-bindingpcc_template_1

第一条为APN下绑定的到PCRF的域路由，第二条为APN下绑定的PCC模板，如此一来，当用户在该APN下激活时，UGW都要到PCRF申请用户策略，所以向PCRF发起CCR，并期望CCA中回复策略，CCA中没有策略，专有承载无法建立；

处理过程：

将APN下的PCRF域路由和PCC模板删掉，然后用户下线重新上线，在电脑上ping公网地址，专有承载建立成功，如下图所示：

UGW向MME发起createbearrequest，MME向UGW回复createbearresponse，并且UGW没有向PCRF发起消息；

案例点评：

对于基于三四层和七层的专有建立，首先必须要在APN下打开PCC开关，非PCC用户无法建立专有承载；其次要删掉PCRF相关的PCC模板和域路由，否则UGW会向PCRF请求策略，如果PCRF没有给该用户签约或未配置相应的预定义规则，专有承载不会建立；最后UGW上

的相应DPI规则要配置正确。

案例4：

X国TAU被拒绝，原因为UEidentitycannotbederivedbythenetwork

现象描述：

X国反馈从在TAU流程中被MME拒绝，原因值为UEidentitycannotbederivedbythenetwork。

告警信息：

无

原因分析：

1）UE驻留在LTE，发起CSFB流程

2）UE回落后，在2/3GSGSN发起了RAU，到本端查询上下文信息，可以看到对端SGSN的地址为C917AFC1，也就是201.23.175.193

3）UE完成CS业务后，TAU回4G，为了获取上下文信息，需要通过DNS查询2/3GSGSN的地址

4）使用DNS查询结果中的地址C9.17.BF.0C（201.23.191.12）发起SGSNContextRequest,但是对端返回失败，原因为cause-ie:

imsi-not-known（194）

5）MME下发位置更新拒绝，原因为eMM-cause:

uE-identity-cannot-be-derived-by-the-network（9）

3GPPTS24.301有相关描述如下：

5.5.3.3.5Combinedtrackingareaupdatingprocedurenotacceptedbythenetwork

#9（UEidentitycannotbederivedbythenetwork）;

TheUEshallsettheEPSupdatestatustoEU2NOTUPDATED（andshallstoreitaccordingtosubclause5.1.3.3）andshalldeleteanyGUTI,lastvisitedregisteredTAI,TAIListandeKSI.TheUEshalldeletethelistofequivalentPLMNsandenterthestateEMM-DEREGISTERED.

以上就是说MME获取不了UE的身份，拒绝TAU请求，TAU失败后，UE会自动发起attach流程

处理过程：

1）随机取了12次CSFB后的TAU过程进行分析，发现其中有4次成功，8次失败，所有失败和上面描述失败流程是一样的，都是由于进行SGSNContextRequest时对端返回失败（原因为imsi-not-known）

2）进一步分析发现，失败的8次DNS解析后使用的对端SGSN地址都是191网段，也就是201.23.191.*,而成功的4次使用的都是175网段，也就是地址201.23.175.*

因此可以确认191网段的SGSN有问题，需要一线排查SGSN的DNS配置是否正确，近期是否做过相关配置操作

3）排查发现10月4日当天，SGSN上有操作，添加了191网段的SGSN，但是在对应的DNS没有添加相应的配置信息，导致TAU时MME无法获取到UE的信息，进而导致TAU失败

4）在191网段的SGSN的DNS添加相应的配置信息，CSFB过程中的TAU成功，问题解决。

案例5：

由于hostfile文件配置不规范导致的TAU失败

现象描述：

某局点两个TA之间存在TAU失败的情况，同一时间发现，在另外两个TA之间却可以正常的进行TAU。

现网PS10.0版本EPC组网，两台MME，一台融合UGW。

现网已经开启终端能力识别功能，4G终端统一激活在融合UGW上。

告警信息：

无

原因分析：

推断问题可能的原因如下：

TA数据在DNS上没有配置完全，有漏配的情况；虽然TA配置完整，但是解析的结果存在问题，没有按照预期选择正确的SGW；

1）首先排查了DNS的配置，确认现场反馈的两个TA（93D0和931C）都是在DNS上配置了的，并且配置完全符合要求。

进行单用户跟踪测试，跟踪信令发现TAUReject的消息，错误原因值为：

no-EPS-bearer-context-activated，如下图：

附着的时候，PGW返回：

TAU的时候，

从上面可以看出，PGW确实作为锚点，一直没有改变过，DNS解析的目的地址为同一个。

2）同步在UGW上做了跟踪，如下：

在出错的时间区间，发现有两次激活请求，但是没有去激活的消息，导致重复激活。

由于重复的激活，同一个用户同一个承载ID，SGW拒绝。

但在同一个SGW的情况下，MME发起第二次重复异常行为。

3）排查本地hostfile配置。

由于开局的时候未使用DNS服务器解析，统一使用的hostfile，后来在DNS增加4G解析数据后，又没有及时删除本地hostfile，导致目前其实部分DNS解析还是通过本地hostfile进行的。

4）根据优先级，MME优选hostfile的配置来解析93D0，问题的关键在于，hostfile中的SGW主机名与DNS服务器中的标准配置是不一致的。

首先看附着的时候，在931C跟踪区下的DNS返回，这个时候使用的是DNS服务器查询：

TAU的时候，也就是在跟踪区93D0下，DNS查询的结果，这个时候使用的是hostfile中的配置：

从这两个解析结果可看出，同一个SGW在不同的TA下却对应了不同的主机名，这样MME就认为是不同的SGW，出现了重复激活的现象，进而TAU失败。

处理过程：

这个问题的根本原因是hostfile的配置未按照规范进行，TA下解析出的SGW主机名与规范不一致。

而出现问题的两个TA一个采用DNS服务器解析，一个采用本地hostfile解析，这样必然导致解析出的SGW主机名结果不一致，MME误认为是SGW变更，触发重复激活。

根据问题分析，在两台MME上删除了所有的TA相关的hostfile配置，清除MME上的DNS缓存后，现场测试正常，TAU成功。

案例6：

由于PCRF在CCA消息中下发信元错误导致UGW动态规则加载失败

现象描述：

PCRF下发动态规则，UGW加载失败，导致激活失败

告警信息：

无

原因分析：

1、可能导致UGW动态规则加载失败的原因：

A、对端链路异常无响应，没有回复CCA

B、CCA消息异常导致rule安装失败

C、GX接口配置错误

2、通过跟踪消息可以看到CCA消息，排除PCRF无响应的原因：

3、排查GX接口配置，配置正确

4、分析CCA消息，发现Charging-rule-install里面缺少必要的信元：

RG/SID，reporting-level，bearer-id

5、同时Flow-info不符合协议要求：

FlowInformation中携带了两个Flowdescription

处理过程：

PCRF下发正确的信元后问题解决。

案例点评：

此类问题一般情况下是信元带的不正确导致的，可先参考协议进行排查。

案例7：

DNSserver和DNSN中主机名命名不同，导致EnodeB间切换失败

现象描述：

T国B局点phase0新建两个PS站点，配置分别为1*USN+1*UGW+2DNS，在PAT测试阶段，发现EnodeB之间切换失败，UGW上打印出来的消息为"SPChangetoSPfail"，USN上流程失败在HOpreparationfailure。

告警信息：

无

原因分析：

1、从USN和UGWtrace上发现，UGW在createsessionresponse消息中拒绝了建立会话请求。

UGW上面打印出来的免维护消息是“SPchangetoSPfailure”。

2、对比HO流程中建立会话请求消息和附着流程中建立会话请求消息发现，SGW地址相同（0A50823E）。

根据Enodeb切换流程，如果服务的SGW不变，不应该发起createsessionrequest消息。

总结：

MME在此发起了错误的createsessionrequest流程，该用户已经在此SGW中建立了一个默认会话，所以SGW返回reject，从而HO失败。

处理过程：

1、为什么服务的SGW地址一样，MME依然发起createsessionrequest流程？

查看DNS请求消息发现HO流程中DNS请求消息携带的是改变了的TAC和attach流程中DNS查询结果。

2、DNS查询结果如下所示，DNS返回的是通过TAC查询出的SGW的hostname，并且和上次的hostname不一样。

3、查看USN和DNS配置发现“TAC-LB2A.TAC-HB23.TAC.EPC.MNC004.MCC520.3GPPNETWORK.ORG”FQDN是在USNDNSN中配置的，而TAC-LB2C.TAC-HB23.TAC.EPC.MNC004.MCC520.3GPPNETWORK.ORG是在server中配置了，而两边配置的hostname名字不一样。

4、删除USN中DNSN配置，将TAC-LB2A.TAC-HB23.TAC.EPC.MNC004.MCC520.3GPPNETWORK.ORG配置加入至DNSserver中，再次测试切换，问题得到解决。

建议与总结：

MME不是根据SGWIP地址决定是否SGW是否改变，而是根据解析的hostname。

理解流程细节，能够有效的解决问题。

案例8：

友商SGWDeleteSessionRequest报文中bearer-id错误导致会话去活失败

现象描述：

我司UGW9811V900R001C05作为PGW，与N公司SGW做对接测试。

信令交互过程如图1：

图中最后PGW发给SGW的DeleteSessionResponse消息中回复失败，原因值为context-not-found，如图2：

告警信息：

无

原因分析：

1）PGW回复失败消息，从PGW入手，查看失败原因值，为context-not-found。

2）在PGW上access-view下执行displaypdpcontext命令，发现存在缺省承载，没有专有承载。

3）查看对应的请求消息，即SGW发给PGW的DeleteSessionRequest消息，发现

eps-bearer-id值为0x6，为专有承载，如图3。

前面通过displaypdpcontext命令查询已经知道只有缺省承载，因此必然找不到上下文而失败。

4）分析此时PGW上只有缺省承载是否正确：

从图1中的信令交互过程，SGW已经通过DeleteBearerCommand消息出发PGW删除之前建立的专有承载，因此此时已经没有专有承载，SGW的eps-bearer-id值是错误的。

5）按协议描述，SGW不会发送DeleteBearerRequest消息，只有DeleteSessionRequest消息的场景，而DeleteSessionRequest消息请求删除会话，携带的eps-bearer-id只能为0x5。

6）进一步测试，发现如果没有建立过专有承载，则SGW在DeleteBearerRequest消息中携带的eps-bearer-id值为0x5，可见SGW的实现上对该信元的值只增不减，导致问题出现。

处理过程：

SGW侧通过补丁修改DeleteSessionRequest消息中eps-bearer-id信元值为0x5，问题解决。

案例点评：

对于信令交互失败类问题，先从回复失败消息的信元入手，通过分析失败原因值、内部调试信息计数器，找到失败原因，从信令交互消息中确认交互失败的根因在哪个信元，对症下药，最终解决问题。

案例9：

UGW配置专有承载规则后附着失败

现象描述：

某实验局中，配置完USN、UGW后，用户附着正常。

增加专有承载配置完成后，初始的时候，专有承载能正常建立，但第二天继续测试的时候，MME拒掉UE附着，默认承载建立失败，提示错误为networkfail