华为核心侧案例集.docx

华为核心侧案例集.docx

《华为核心侧案例集.docx》由会员分享，可在线阅读，更多相关《华为核心侧案例集.docx（24页珍藏版）》请在冰点文库上搜索。

华为核心侧案例集

案例１:

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

现象描述:

U国某局点反映用运营商４G旧终端能够上网,而用新终端（如华为AscendP１LTE、Ｅ392及其他终端）不能附着到网络,因此需要分析是什么原因导致新终端附着不到网络。

USＮ　版本:

V９00Ｒ０11C01ＳPC3０0

告警信息:

原因分析:

USN上的告警时GＴPC隧道路径断,查看USN配置,发现37、11０、20９、209的地址描述是ＤＥＳC="Ｇｎ/Ｓ10/S１１coｎtroｌｐlaｎe",基本能够排除问题是由此告警导致的。

从问题现象来看,估计的原因有:

1）终端的问题。

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

3）HSＳ签约数据问题,估计限制了终端的类型,导致某类终端不能接入4Ｇ网络、

处理过程:

１）查看新终端附着不成功的跟踪文件,发现失败原因都是eMＭ—ｃaｕse:

uＥ—ｓecuｒity－capabｉｌｉtiｅs-ｍｉｓmａtｃh,UE的安全能力不匹配,特别有估计是加密没有开启导致的。

２）查看配置ADＤS１USRSEＣPARA:

IＭSIＰRE="ＤEFAULＴ”,　SＥCPＬC=NＥVEＲ;设置了所有的用户都不鉴权加密,依照协议规定,所有的４G用户都是应该开启鉴权加密的,产品文档也写了的。

因此开启鉴权加密进行测试。

３）开启鉴权加密后,测试仍然失败,失败原因值是ｅMM-causｅ:

meｓｓａge－not—ｐatiblｅ—ｗｉtｈ-thｅ—protocol—ｓtaｔe,当前协议状态下消息不可得。

从后面的消息中又发现了tｉmeｏｕｔ的现象,超时原因是等待aｔtａcｈ　plete消息超时

4）查看协议2３４01,第23步,协议规定MME在收到 InitｉalContｅxt　Respoｎse消息和Atｔａcｈｐｌｅtｅ后才会给ＳＧW发送MｏdiｆyBeaｒerReqｕｅsｔ　消息,特别显然,问题出现在ＵＥ没有及时的给ＭME发送ａttａchplete消息。

２3。

　Upoｎrｅcｅptｉon　oｆｂoｔh,thｅＩnｉtiａlConｔext　Ｒeｓｐonsｅmessageinstep２１ａnｄthｅ　Attachpｌｅtemｅｓsａgeinｓｔep 2２,tｈｅ　ｎewMＭEsenｄｓa　MoｄifyBeａrｅrＲeｑuest（EPSＢeａｒeｒIdentitｙ,　eＮoｄeBaddress,　ｅＮodeB　TＥＩD,　ＨaｎdoveｒIndiｃatｉｏn）mｅｓsａｇetotheSerｖinｇGW。

５）旧终端是上的了网的,因此问题肯定在新终端上,那是不是因为新终端有问题呢,不支持协议?

问题陷入了僵局。

这个时候用旧的终端连4Ｇ网络,发现也上不了网了、问题一下子陷入了两难。

观察跟踪文件。

HSＳ回复鉴权拒绝的消息给MME、

６）询问一线测试工程师,发现他是RMVＵＳＲ之后出现旧终端测试失败的,那么用新终端测试会是如何样呢？

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

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

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

权拒绝,那么问题应该是出现在HSS上了,和HSS工程师做过沟通之后,发现他选的卡的类型是ＳＩM,而不是UＳIM,依照之前２／3G的概念,SIＭ卡鉴权是取３元组的,而４GＥＰＣ网络鉴权是4元组,而USＮ现在还不支持３元组向4元组进行转换,因此鉴权肯定是失败的。

因此3ＧＰＰ协议推荐4G里面选USＩM卡,如此3Ｇ用户就能够顺利过渡到4G这是因为３G里面的鉴权５元组能够转为4元组、

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

案例点评:

从整个问题的处理看,纠结于终端的原因花了特别长的时间,然而后面终于依然发现了鉴权拒绝的原因,从而根因于ＨＳS签约数据的问题,4G网络中使用的卡的类型不再是ＳIＭ卡、EPＣ网络现在要求都是鉴权加密,因此现在的时候也都支持加密、此案例中新终端是强制了加密的,旧终端没有强制,因此用SIＭ卡附着新终端是上不了网,而不强制加密的旧终端则能上网。

案例2:

USN9８１0未配置相应ＴAC导致用户附着失败问题

现象描述:

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

告警信息:

无

原因分析:

登陆USＮ９810,打开用户跟踪对话框,输入用户ＩMSI号码跟踪消息:

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

                           ＵE发起Aｔtａch　Requset消息,同时MME向HSS发起鉴权请求（ＡｕthｅntｉcａtｉonInｆｏrmatiｏnＲequesｔ）得到响应（AuｔhｅｎｔicaｔｉonInforｍaｔｉｏｎ　Anｓwｅr）,由MＭE向HSS发起的跟踪区更新请求消息看出,UE鉴权通过HSＳ的签约数据没有问题。

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

ﻫ

UＥ附着被拒绝（Atｔａch　Reｊｅcｔ）,双击该条消息,从具体信息中得到下图信息,ﻫ

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

3、依照2步骤定位的原因,直截了当找到ＳM—DNS的解析消息:

ﻫ

 双击ＳＭ—DNS的消息,从具体信息中得到如下图的信息,

ﻫ        从图中看到要解析的两个FQＤN（由ＡPN和TAC构造所得）,具体配置在ＡDＤDNSN命令下。

4、在USN９810的LＭT客户端的ＵSＮ网元下,输入LSTDNＳＮ,查看相关配置如下,主要查看FＱDN构造:

ﻫ操作结果如下:

－—－—--—-—－－－—－—－—--－-—---ﻫFQDＮ                           　　　　　ＨoｓｔNａme索引  网元类型 　接口类型 S5接口协议类型 ﻫTAC－LＢ01、ＴAC—HB00。

TＡＣ、ＥＰC、ＭNＣ00３、ＭＣC４６0。

3ＧPPNETWORK、ORG １             ＳGW    Ｓ1１            GＴP            ＣＴNET、APN、EＰＣ、MＮＣ0０３、MCC46０。

3GPPNＥTWORK。

ＯＲG                   2             　PＧW    S５              GTＰ         ﻫ（结果个数=2）ﻫ从查询结果中看出,TAＣ的配置跟消息带上来的不一致,消息中TＡＣ为２５41,配置中为00０1,由该原因导致DNS解析失败。

ﻫ处理过程:

1、添加TAＣ对应的TALST（ＡDDTＡＬST）:

ﻫAＤＤTＡＬST:

TＡLＩＳＴIＤ=1,　TＡI=＂4６0032541＂,　DＥSＣ="ｔｏ－S1＂;

2、添加DＮＳ的A解析记录（ADDＩＰV4DＮSH,假如之前配置,则无需再加）:

ﻫADＤ　IＰV4DNＳH:

HSINDEX＝1,　HＯSTNAＭE="topon、ｓ1１。

gw0101-b—hｗ、ｘｔx＂,AＤDRSＥCTIＯN=SECTION１,IPＶ4ＡＤDR1=＂１15、169。

１48。

1７8”,　PRIＯRIＴY1=1２7,　WEIＧHT1=127;ﻫ３、添加DNS的NAPTＲ解析记录（ＡＤD　ＤNSN）,保证TAC配置正确,同时跟A记录的主机名索引保持一致:

ﻫAＤＤ　ＤNSN:

FQDＮ＝＂TＡＣ-ＬB４1。

ＴAC－ＨＢ25、TAC、epc、mnc0１1。

mcc4６0、３ｇppｎeｔｗｏrｋ。

orｇ＂,HSINDEX=1,ENTＩTY＝SGW,INTYPＥ＝S11,　Ｓ5PROＴOCOL=GTP,S8PROTOCOL＝GTP,PRIＯRITY=0,　WEIGＨＴ=1０0; 

 执行完以上三步后,用户能够正常上网。

建议与总结:

ﻫ配置置USN９8１０的数据时,要严格依照数据规划完整的添加需要配置的TALSＴ,并正确添加相应的ＤNＳ数据配置。

A解析记录中,主要注意正确配置主机名与相应网元（SGW、PGW等）的ＩP地址对应关系,NＡPTR解析记录中,主要注意正确配置ＴAC,正确引用A解析记录、

案例３:

PCＣ配置错误导致ＵGW基于三四层专有承载无法建立问题

现象描述:

依照UGW9811V900Ｒ０10C01SPC５２0T的设备验收测试手册,有一项基于三四层专有承载的建立,配置三四层规则,并将相应的ｕser-pｒo绑定到apn下,测试时,需要由UGW触发专有承载建立,但专有承载未建立、

以上配置数据配置完毕后,数据卡连接网络,在电脑上ping公网地址,专有承载没有建立。

告警信息:

无

原因分析:

１、网络侧触发专有承载的建立有三种方式:

ﻫ

（1）PCＣ动态用户由ＰＣＲF下发动态规则触发专有承载建立;　ﻫ（２）PCC静态用户由PＣRF下发预定义规则触发专有承载建立;ﻫ（3）PＣC静态用户由ＵGW触发专有承载建立;ﻫ该项测试中使用第三种方式触发专有承载。

　ﻫ2、跟踪消息中发现用户再激活时向PＣＲF发送了CＣR消息,同时PCＲF回了CCA消息（CＣR/CCA通过ＤRA转接）,如图１所示,同时CＣＡ消息显示该用户未在PCＲF中签约;ﻫ

图1ﻫ3、关于ＰCＣ静态用户由PGＷ发起专有承载建立的原则为,用户上线后,不应该向PＣＲF发起CCR,而是依照ＡPＮ下绑定的user-pro匹配相应规则进行专有承载的建立,但ＡＰN下的ＰCC开关必须打开,因为在Ｖ900R01０C0１ＳPＣ５2０T版本中,非PCC用户无法建立专有承载;ﻫ４、假如ＵGW向ＰCＲＦ发起CCR,那么UGＷ就会以第二种方式建立专有承载（PCC静态用户由ＰCRF下发预定义规则触发专有承载建立）,而可不能匹配ＡＰＮ下的useｒ-pro,CCA中没有下发预定义规则名,规则匹配失败,专有承载未建立;ﻫ５、UGW为什么会向PCRF发起ＣCR,通过检查ＡPＮ下的配置发现,ＡPＮ下绑定了如下两条命令:

ﻫｒealm—ｂｉnｄingapｐliｃａｔｉoｎgxrealmepc、mｎc0１１、mｃｃ４6０、3gｐｐneｔwｏｒk。

oｒgﻫpcｃ—teｍｐlate－biｎｄingｐcc_template_１ﻫ第一条为ＡPN下绑定的到PCＲF的域路由,第二条为ＡPＮ下绑定的ＰCC模板,如此一来,当用户在该AＰN下激活时,UGW都要到ＰＣRF申请用户策略,因此向ＰCRF发起CCR,并期望ＣCＡ中回复策略,ＣCA中没有策略,专有承载无法建立;

处理过程:

将APN下的PCRＦ域路由和PＣC模板删掉,然后用户下线重新上线,在电脑上ｐiｎｇ公网地址,专有承载建立成功,如下图所示:

ﻫUGW向ＭＭE发起createbeaｒｒeｑueｓt,ＭＭE向ＵＧW回复ｃreate　beａｒ　rｅsponse,同时UGＷ没有向PＣＲF发起消息;ﻫ

案例点评:

关于基于三四层和七层的专有建立,首先必须要在ＡPＮ下打开ＰCC开关,非PCＣ用户无法建立专有承载;其次要删掉PＣRF相关的ＰＣC模板和域路由,否则UGＷ会向ＰCRF请求策略,假如ＰCRF没有给该用户签约或未配置相应的预定义规则,专有承载可不能建立;最后UＧＷ上

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

案例４:

X国TAＵ被拒绝,原因为UＥｉdeｎｔityｃannｏt　be　ｄeｒｉvｅｄｂｙ　ｔhenｅtwork

现象描述:

X国反馈从在TAＵ流程中被MME拒绝,原因值为ＵEiｄentitｙcａnnotbederived　ｂｙthe　netwoｒｋ、

告警信息:

无

原因分析:

ﻫ１）ＵE驻留在LTE,发起CSFB流程

2）　　UE回落后,在2/3Ｇ　ＳGSN发起了RAU,到本端查询上下文信息,能够看到对端ＳGＳＮ的地址为Ｃ9１7　AFC1,也就是20１。

2３、１７5。

193

3）UＥ完成CS业务后,TAU回4G,为了获取上下文信息,需要通过DＮS查询2／3Ｇ　ＳGSＮ的地址

4）使用DＮS查询结果中的地址C9、1７、BF、０C（２0１。

２3、１91、１２）发起SＧSNＣｏntextRｅqｕeｓt,然而对端返回失败,原因为cauｓe—ie:

iｍｓi-ｎoｔ—knｏwn（1９4）

5）ＭＭE下发位置更新拒绝,原因为eＭＭ—caｕｓe:

uE－identｉty－caｎｎot-be-derｉved-by-the—ｎｅｔworｋ（9）

3GPPＴS　24。

３０1　有相关描述如下:

5。

5、３、３、5binｅdtrackinｇａrea　updating　ｐroｃｅdｕｒenotａｃceptｅd　bｙ　tｈe　netwｏrk

＃９　（UEｉdｅntitycannotbe　dｅｒivｅdbｙ　theｎｅtwoｒｋ）;

Tｈe　UＥ　ｓhallsetｔhe　EPSｕpdaｔｅｓtatｕｓtｏEＵ2　NＯTUＰDATED（aｎdｓhall　stoｒｅ　ｉｔ　ａｃcｏrdiｎgto　sｕbｃlausｅ5。

1、3、３）　andｓｈａlldeｌｅｔe　anｙ　ＧUTI,lasｔ　visiｔｅdrｅgistereｄ　TAＩ,TAIＬisｔ　ａndｅKＳI、Ｔhe　UEshalldeletｅ　tｈｅ　ｌiｓｔ　ｏｆ　eqｕivalｅnｔPLMNsanｄｅntｅrtheｓtaｔe　EMＭ－DEREGISTERED、

以上就是说ＭＭE获取不了UE的身份,拒绝ＴＡＵ请求,TAＵ失败后,UE会自动发起ａttacｈ流程　

处理过程:

１）随机取了１2次ＣＳFＢ后的ＴＡＵ过程进行分析,发现其中有4次成功,8次失败,所有失败和上面描述失败流程是一样的,都是由于进行ＳGSN　ＣｏntｅxｔＲeqｕest时对端返回失败（原因为imsi-not－kｎoｗn）

2）进一步分析发现,失败的8次ＤＮS解析后使用的对端SＧＳＮ地址都是１91网段,也就是2０１、2３、１91、＊,而成功的4次使用的都是1７5网段,也就是地址２０１、2３。

１７5、＊

因此能够确认１91网段的SGＳＮ有问题,需要一线排查SＧSN的ＤＮS配置是否正确,近期是否做过相关配置操作

３）排查发现1０月4日当天,SＧSN上有操作,添加了1９１网段的ＳGSN,然而在对应的ＤNS没有添加相应的配置信息,导致TAＵ时MＭE无法获取到UＥ的信息,进而导致ＴAU失败

４）　在１91网段的ＳＧSＮ的DＮS添加相应的配置信息,CＳFB过程中的TAU成功,问题解决。

案例５:

由于hｏstfｉle文件配置不规范导致的TＡU失败

现象描述:

某局点两个TＡ之间存在ＴAU失败的情况,同一时间发现,在另外两个ＴA之间却能够正常的进行ＴAU。

现网PS10、0版本EＰＣ组网,两台MME,一台融合UGW。

现网差不多开启终端能力识别功能,４G终端统一激活在融合UGＷ上。

告警信息:

无

原因分析:

推断问题估计的原因如下:

ﻫＴA数据在ＤＮS上没有配置完全,有漏配的情况;尽管ＴA配置完整,然而解析的结果存在问题,没有依照预期选择正确的SＧW;ﻫ1）首先排查了DNS的配置,确认现场反馈的两个ＴＡ（9３Ｄ0和93１C）都是在DNＳ上配置了的,同时配置完全符合要求。

进行单用户跟踪测试,跟踪信令发现TAＵ　Ｒeject的消息,错误原因值为:

no－EPＳ－beaｒｅｒ-ｃonｔｅｘt-aｃｔivatｅd,如下图:

附着的时候,PGW返回:

ﻫ

ＴAU的时候,

从上面能够看出,PGW确实作为锚点,一直没有改变过,DNＳ解析的目的地址为同一个、2）同步在UＧW上做了跟踪,如下:

ﻫ

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

ﻫ由于重复的激活,同一个用户同一个承载ID,SGＷ拒绝。

但在同一个SＧW的情况下,MME发起第二次重复异常行为。

3）排查本地ｈoｓｔｆilｅ配置、由于开局的时候未使用DNS服务器解析,统一使用的ｈoｓtｆｉlｅ,后来在ＤNS增加4G解析数据后,又没有及时删除本地hostｆilｅ,导致目前事实上部分DNＳ解析依然通过本地ｈostfile进行的。

4）　依照优先级,MME优选hoｓtfｉｌe的配置来解析93D0,问题的关键在于,ｈostfilｅ中的SGW主机名与ＤNＳ服务器中的标准配置是不一致的。

首先看附着的时候,在931C跟踪区下的DNＳ返回,这个时候使用的是ＤNS服务器查询:

ＴＡU的时候,也就是在跟踪区９3D０下,ＤNＳ查询的结果,这个时候使用的是ｈoｓｔfile中的配置:

ﻫ

从这两个解析结果可看出,同一个SGW在不同的ＴA下却对应了不同的主机名,如此MMＥ就认为是不同的SＧW,出现了重复激活的现象,进而ＴAU失败。

处理过程:

这个问题的根本原因是hoｓtｆile的配置未依照规范进行,TA下解析出的ＳGW主机名与规范不一致。

而出现问题的两个TA一个采纳ＤNＳ服务器解析,一个采纳本地hｏｓｔfilｅ解析,如此必定导致解析出的ＳGW主机名结果不一致,MME误认为是SGＷ变更,触发重复激活。

依照问题分析,在两台MMＥ上删除了所有的ＴA相关的hostｆilｅ配置,清除MME上的DNS缓存后,现场测试正常,TＡＵ成功、

案例6:

由于PCＲF在CＣA消息中下发信元错误导致UGW动态规则加载失败

现象描述:

PCRＦ下发动态规则,ＵGＷ加载失败,导致激活失败

告警信息:

无

原因分析:

1、估计导致UGW动态规则加载失败的原因:

A、对端链路异常无响应,没有回复ＣＣA

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

C、GX接口配置错误

2、通过跟踪消息能够看到CCA消息,排除PCRＦ无响应的原因:

3、排查ＧＸ接口配置,配置正确

4、分析ＣCA消息,发现Chａｒging—rulｅ－inｓｔａlｌ里面缺少必要的信元:

ＲG／SID,reportｉng—leｖｅl,ｂearer－iｄ

5、同时Floｗ—info不符合协议要求:

ＦloｗIｎｆoｒｍａtｉｏn中携带了两个Floｗｄescｒiption

处理过程:

ＰCＲＦ下发正确的信元后问题解决。

案例点评:

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

案例7:

DＮSsｅrver和DNＳN中主机名命名不同,导致EnodeB间切换失败

现象描述:

T国B局点phａｓｅ　0新建两个PＳ站点,配置分别为1＊UＳＮ+1*UGＷ+２DNS,在PAT测试时期,发现ＥnｏdeB之间切换失败,UGW上打印出来的消息为＂SP　ＣhanｇeｔoSＰfaｉl＂,ＵSN上流程失败在ＨO　ｐrepaｒaｔion　faiｌurｅ。

ﻫ

告警信息:

无

原因分析:

ﻫ1、从USＮ和UGWtrace上发现,UGW　在createseｓsionrｅspoｎse消息中拒绝了建立会话请求。

ﻫ

UＧＷ上面打印出来的免维护消息是“ＳＰcｈａnge　toSPfaiｌｕrｅ”。

ﻫ２、对比HO流程中建立会话请求消息和附着流程中建立会话请求消息发现,SGW地址相同（0A　５0　823Ｅ）、依照Ｅnｏdeｂ切换流程,假如服务的SＧW不变,不应该发起cｒeａｔｅ　ｓessｉoｎrequeｓｔ消息、ﻫ总结:

ＭMＥ在此发起了错误的ｃｒｅateｓｅｓsｉｏｎ　reｑuesｔ流程,该用户差不多在此SGW中建立了一个默认会话,因此SＧW返回rｅjeｃt,从而HＯ失败。

处理过程:

1、为什么服务的SGW地址一样,ＭME依然发起ｃreatesessｉｏn　ｒequeｓt流程？

查看ＤNS请求消息发现HＯ流程中DNＳ请求消息携带的是改变了的ＴＡC和atｔａｃh流程中DＮS查询结果。

2、ＤNＳ查询结果如下所示,ＤNS返回的是通过TＡC查询出的ＳGW的ｈｏsｔnａme,同时和上次的hｏｓtnａmｅ不一样、

3、查看UＳN和ＤNS配置发现“ＴAC－LB2A。

ＴＡC-　ＨB２３、TAＣ。

EPC。

MＮＣ００4、MＣＣ520。

3ＧPＰNEＴWＯRK。

ORG”FQDN是在USＮDNＳN中配置的,而ＴAＣ-ＬB２C、ＴAＣ－ＨB２３。

TＡＣ、EPＣ。

MNC0０４、MCC５２0。

3ＧＰPＮＥTWORＫ。

ORG是在serｖｅr中配置了,而两边配置的hostnａme名字不一样。

　ﻫ４、删除ＵＳN中DNSＮ配置,将TＡC—LＢ2A、ＴAC-HB23、TＡC、EPC。

ＭNC０0４、MCC５2０。

3ＧPPNＥＴWOＲＫ、OＲＧ配置加入至DＮＳsｅrveｒ中,再次测试切换,问题得到解决。

建议与总结:

MME不是依照ＳGW　IＰ地址决定是否SGW是否改变,而是依照解析的ｈｏｓtnamｅ。

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

。

、

案例8:

友商ＳGWＤｅｌetｅＳessiｏnRｅqｕest报文中beaｒｅr－ｉd错误导致会话去活失败

现象描述:

我司ＵGＷ9８１１Ｖ9０0R001C０5作为PＧW,与Ｎ公司ＳGＷ做对接测试、信令交互过程如图１:

图中最后ＰGＷ发给SGW的Deｌetｅ　ＳｅsｓionReｓponse消息中回复失败,原因值为ｃontext—nｏt－ｆound,如图2:

告警信息:

无

原因分析:

1）PGＷ回复失败消息,从PGＷ入手,查看失败原因值,为contｅxｔ-not－foｕnd。

2）在PGW上access-view下执行dispｌaypｄｐｃｏnｔext命令,发现存在缺省承载,没有专有承载、

3）查看对应的请求消息,即SGＷ发给PGW的Deｌeｔe　Session　Reｑueｓt消息,发现

eｐs－bｅaｒeｒ－iｄ值为０x6,为专有承载,如图3。

前面通过disｐｌaｙpｄpcｏｎｔexｔ命令查询差不多明白只有缺省承载,因此必定找不到上下文而失败。

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

从图1中的信令交互过程,SGＷ差不多通过Ｄeleｔｅ　Ｂeaｒermaｎd消息出发PGW删除之前建立的专有承载,因此此时差不多没有专有承载,ＳGＷ的eｐｓ—beａreｒ-id值是错误的。

5）按协议描述,SGW可不能发送Delｅtｅ　BｅaｒerReqｕｅｓt消息,只有ＤｅlｅtｅＳeｓｓｉoｎ　Rｅquｅst消息的场景,而DｅleteSesｓionRｅqueｓt消息请求删除会话,携带的eps-ｂeａrer-id只能为０ｘ５、

6）进一步测试,发现假如没有建立过专有承载,则ＳGW在DeｌｅtｅＢeａｒerＲequeｓｔ消息中携带的eps—ｂｅarer-ｉd值为0ｘ5,可见SGW的实现上对该信元的值只增不减,导致问题出现、

处理过程:

SGW侧通过补丁修改DeｌetｅＳｅｓｓionRｅqｕｅsｔ消息中eps-beareｒ—id信元值为０x5,问题解决。

案例点评:

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



案例9:

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

现象描述:

某实验局中,配置完ＵＳＮ、UGＷ后,用户附着正常。

增加专有承载配置完成后,初始的时候,专有承载能正常建立,但第二天接着测试的时候,MＭＥ拒掉UＥ附着,默认承载建立失败,提示错误为networkfailurｅ。

告警信息:

无

原因分析:

第一天测试完后,到第二天重新测试期间,设备没有做任何改动,也看不到任何新增告警、分析认为没有加识别库,因此无法建立专有承载;然而加载协议识