移动用户无法正常返回4G网络的案例分析
2017年第2期 信息通信
2017
(总第 170 期）
INFORMATION & COMMUNICATIONS
(Sum. No 170)
移动用户无法正常返回4G 网络的案例分析
肖辉
(中国联合网络通信有限公司武汉市分公司，湖北武汉430000)
摘要：随着4G 网络的发展，文章针对测试中发现的用户长时间不能返回4G 网络的案例，分场景进行了详细的原因分析， 通过底层抓包操作，最终提出了有效解决方案。关键词:SGSN-MME ; ISU  TAU ; PGW ；参数调整中图分类号:TN929.5
文献标识码:A
文章编号:1673-1131(2017)02-0192-02
1背景描述
随着通信网络的发展，用户对移动网络的感知越来越敏
感。为了让用户有着完美的4G 网络体验，我们的测试也越来
越精细化。
SGSN-MME 覆盖业务区测试中，以下两种场景，发现部 分用户出现长时间不能返回4G 的情况，ISCTAU 失败原因值 为 17 (Network Failure)：第一种场景：测试中，在三环上遇到手机长时间不能返回 4G 网络，但经多款手机模拟测试仅三星Note2手机存在一直 回不了 4G 网的情况，其他iPhone6、华为P1、中兴Z 9均可在 12分钟后自动返回4G 。
第二种场景：部分用户从在武汉火车站出现用户长时间 驻留在3G 网络上，不能返回4G 的情况。2原因分析
经查用户手机发送TAU 给MME 之后，MME 返回TAU 失败，原因值为 17 (Network Failure )。
在分析ISC TAU 失败原因前，可以先了解SGSN-MME
ISC TAU 流程。
The Gn/Gp-SGSN to MME TAU procedure is shown in Figure 28 and described below
图 1
SGSN-MME ISC TAU 流程图
从流程图可以看到ISC TAU 步骤：(1) MME 收到TAUrequest 之后，查SGSN 的IP 地址。 此步骤里MME 需通过RAC FQDN 的解析，通过DNS 查询到 SGSN 的IP 地址。(2) 到 SGSN 发 SGSN context request 到 SGSN, SGSN 返回 SGSN context response 。在SGSN context response 这条消息里的SGSN 会在Pri-vate Extension IE 中携带 Initial GGSN IP address ，同时消息里
也会有 PDP 使用的 APN。MME 通过 SGSN context response 的APN 查询PGW ，查到的PGW 要支持x-gn 接口，否则TAU 会被 reject。MME 对比 PGW 的 IP address 和 Private Extension IE 中携带InitialGGSNIPaddress ，如果不匹配，TAU 会被reject.(3)到PGW 后会通过DNS 查询SGW 的IP address ，然 后发消息给SGW 。
从流程图里可以看到，有两个原因会导致TAU 被拒绝，原 因值为CC17。
(1 )MME 通过APN 查询PGW，不到PGW 。(现网DNS 已添加配置，不存在不到PGW 的情况)。
(2)MME 通过对比 PGW 的 IP address 和 Private Extension IE 中携带Initial GGSN IP address，如果不匹配，TAU 失败，原 因值为CC17。
2.1第一种场景原因分析
通过在现网中模拟第一种场景，在维护窗口期间对测试 用户进行底层抓包分析。详细的测试结果分析如下：
(1) UE 在 3G 的时候选用的 A PNSgnet^PGWIP 为 220206.173.7。
(2) TAU 到 4G 后，MME 用 3gnet.460. 去查PGW 的地址。最后匹配到广州、北京 的国漫PGW 地址列表。
(3) 通过比对PGW IP 地址，发现广州和北京的PGW 地 址和用户在3G 上PGW 地址不一致（用户在3G 上用的是湖 北的PGW 地址)，所以导致了 TAU 失败，没有到PGW 。所 以ISCTAU 失败。
00:50:59,952: (l_21,Cid 120092662) call gw_selection_Min:iaap_gwjelection_error_to_scc (pgw not found) Erom gw selection main:niap ggsn to pgw/3
匕」^
ISlilUPGW  ""
00:50:59,952: (l_21,Cid 120092662) return gwjelection_main:niap_gw_selection_error-to_scc/l ->
797
00:50:59,952: (l_21fCid 120092662) return gw_selection_main:niap_ggsn_to_pgw/3 ->{fault,pgw not found,797}
00:50:59,952: (l_21fCid 120092662) return gw_3election_protected:iQap_gg3n_to_pgw/3 ->{fault f  pgw_not_found,797}
00:50:59,952: (l_21,Cid 120092662) return esm_lib:select_pgw_for_pdn/2 ->
{fault,pgw not found,797}
图2 ISC TAU 失败原因分析(4) 但是用户为什么没有本地的PGW ，而是选择了广州 和北京的PGW 呢？抓包发现是由于终端上报不支持4G ，从 而导致选择不是FQDN 方式的PGW.。由于不带FQDN ，用户
从2/3G SGSN TAU 到4G MME 后，MME 从SGSN 拿取用户 的上下文信息也就没有带FQ D N ，进而导致MME 无法通过
PGW FQDN 的方式到本地的PGW，而是通过DNS 解析去
192
信息通信肖辉：移动用户无法正常返回4G网络的案例分析
PGW。但T A U过程中的D N S解析方式无法通过号段扩展 进行解析，所以默认解析到广州和北京的PGW。进而导致ISC T A U失败。
上报不支持4G的终端，选择不带FQ D N的PGW；上报支 持4G的用户，则会选择FQ D N方式PGW:
(5)对于上报支持终端支持4G的用户，用户从2/3G SGSN T A U到4G M M E后，M M E从SGSN拿取用户的上下文信息 也就带PGW FQDN。M M E可以通过P G W的FQDN，可以直 接到本地的PGW，从而ISC T A U成功。
从流程看到M M E到PGW，并向PG W发消息之前是 在第7步。而M M E知道用户的M S IS D N是在第14步，HSS 返回给M M E的update location answ er消息里，在此之前，M M E是不知道用户的M S IS D N号码的。所以T A U的过程 中，M M E查PGW是无法通过号段M SISDN扩展来完成的。
从第一种场景和第二种场景分析来看，都是由于终端在 3G网络上没有上报支持4G的消息字段，从而导致ISC TAU 失败，原因值为CC17。对于这种终端在3G网络发起不支 持4G，从而导致ISC T A U失败，原因值为CC17的问题。相
对于一个上报终端支持4G的用户M M E会从SGSN取 到当前的PGW FQ D N信息；对于一个上报终端不
支持4G的用户M M E会从SGSN取不到当前的PGW FQ D N信息。2.2第二种场景原因分析
由于SGSN-M M E底层抓包建议在维护窗口期间进行操 作，而第二种场景只能在白天进行测试。所以不能通过抓包 确定其原因，但是在测试过程中查看测试用户的信息，发现 T A U失败的用户在3G网络上查看信息不带FQDN，T A U成 功的用户在3G网络上带FQDN。
带不带P G W的F Q D N是由终端上报4G支持能力决定 的。可以通过终端在3G网络中的attach request和RAU request 消息 MS network capability里包含的 EPC capablity字段查看。如果上报EPC supported表示支持4G，如果不上报此字段或 者上报EPC not supported表示不支持4G。
测试时，SGSN-M M E软件版本还不能实现对3G用户信 令单用户的跟踪，要抓3G信令，需要抓和某个RNC连接的所 有信令。而第二种场景测试过程中跨了 4个RNC，所以没有 办法抓到在用户T A U失败前那一刻的RAU request消息，从 而确定终端是否上报支持4G的消息字段。但是从SGSN-M M E查看用户的信息带不带FQDN，也是可以确定终端是否 上报支持4G的消息字段。
3解决办法
在场景测试中发现T A U到4G后，M M E用3gnet.apn.epc. ，去查 PGW的地址。这里为 什么不是通过号段扩展解析3gnet.<msisdn>.001. 去 PGW。
如果没有通过号段扩展解析，那么解析到的PGW地址肯 定不是本省用户的PG W地址。
还是查看I SC T A U流程：
图3 SGSN-MME ISC T A U流程图解析关设备厂家研发核查SGSN-M M E当前的处理机制是符合
规范的。
但是由于CC17会导致终端长期驻留在3G，而无法通过
再次附着连接到4G，从而影响用户的业务感知，我们可以通过
修改 SGSN-MME参数 “private_ie_ggsn_in it_sig_add_enable”
解决。可以通过参数设置 “private_ie_ggsn_in it_sig_add_en-able”为false，让M M E不比较GGSN和P G W的地址，直接实
现#10(10代表隐含去附着)的TA U拒绝，U E收到之后会重新
附着LTE，不影响使用L T E网络。
*月*日凌晨对厂家SGSN-M M E进行此参数调整，参数调
整完成后，ISC T A U指标明显上升，业务测试正常。
*月*日凌晨对厂家其他的SGSN-M M E进行此参数调整，
参数调整完成后，SGSN-M M E上ISC T A U指标都明显上升，
业务测试正常。
同时在*月*日白天，对两种种场景进行测试验证，没有发
现CC=17的情况，但是有CC=10的情况，参数修改符合预期。CC=10信令如下：
：23.501000
：23.502000
：2B.904000
：24,058000
124.058000
：
24.059000
；24.278000
：24.282000
:24.315000
：24.323000
：24.325000
124.366000
124.367000
：24.430000
:24.436000
：28.437000
：
28.448000
：28.449000
：28.560000
：28.561000
3.0. 0.3
3.0. 0.B
3.0. 0.3
4.0. 0.4
3.0. 0.B
3.0. 0.3
2.0. 0.2
3.0. 0.3
4.0. 0.4
2.0. 0.2
3.0. 0.3
2.0. 0.2
3.0. 0.3
4.0. 0.4
220.206.139.130
220.206.139.130
220.206.139.140
3.0. 0.B
7.0. 0.7
3.0. 0.3
2.0.0.；
武汉移动营业厅
2.0.0.J
3.0.0.：
51AP/NAS-EP5
2.0. 0.2 S1AP
4.0. 0.4 DIAMETER
3.0. 0.3 DIAMETER
DIAMETER
S1AP/NAS-EP5
S1AP/NAS-EPS
S1AP/NAS-EPS
DIAMETER
SlAP/NAS-EPS
SlAP/NAS-EPS
S1AP/NAS-EPS
DIAMETER
DIAMETER
220.206.1GTPV2
220.206,1GTPV2
220.206,1G
7.0. 0.7
3.0. 0.3 S6SAP
2.0. 0.2 SlAP/NAS-EPS
16TPV2
S6SAP
^04 Id-downlinkNASTransport, Tracking area update reject (imp Udt lv detached)]
92 id-UEContextRelease, UEContextReleasecomnand [NAS-cause=normal-release]
464 cid=36PP-Authentication-lnfonation Request(318) S6a/S6d(1677/
492 cnd«3GPP-Authentication-lnfonation Answer(318) f l ag s-P- appl»3GPP S6a/S6d(16777；
512 ciid-3GPP-Authentication-lnforiation Request(318) flags*RP- appl*3GPP S6a/S6d(1677/
132 id-downlinlcNASTransport, Authentication request
132 id-uplinkNASTransport, Authentication response
112 id-downlinkNASTransport, Security lode command
656 cnd«3GPP-Authentkation-lnforiation Answer(318) f1ags*-P- appl»3GPP S6a/56d(167772
136 1d-upl1nkNASTransport, security mode complete
104 id-downlinkNASTransport, es m information request
132 Id-uplInkNASTransport, esm Infornatlon response
660 cmd.3GPP-update-L〇cation Request(316) flags.RP- appl.BGPP S6a/S6d(16777251) h2h»7!
908 cid-36PP-update-L〇cat1on Answr(316) f l a g s-P- appl«3GPP S6a/S6d(16777251) h2h-751
308 Create Session Request
308 Create Session Request
186 create session Response
156 S6SAF-LOCAn〇N-UPDATE-REQUEST f f l bfIfAHarhlflii
92SGSAP-L0CAT10N-_TE-ACCEPT__________用尸
|368 1d-in1t1a1c〇fitextsetup, inltlalcontextsetupRiquest , Attach accept, jctlvate defaul
0010 » security header type: integrity protected and ciphered ⑵
.... 0111 ■ Protocol discriminator: EPS wbility management messages (0x07)
Message authentication code: 0x0d71471d
sequence number
0000.,..= security header type: Plain na s Message, not security protected (0)
.... 0111 = protocol discriminator: ep s lobility «
acking <
i圯細加n
n a s EPS Mobi Iity Managefflent Message TVpe: Trai
_____________P^c a u s e[T A_
sage, not security protected ((
y management messages (0x07)
:ing area update reject (0x4b)
图4两种场景验证测试
通过参数调整，不管换何种类型的手机终端，测试两种场
景中的移动用户无法正常返回4G网络的情况不再出现，问题
得到彻底解决。
参考文献:
[1]陈宇恒，肖竹，王洪.LT E协议栈与信令分析[M].北京：人民
邮电出版社，2013.
[2]曾召华.LTE基础原理与关键技术[M].西安电子科技大学
出版社,2010.
作者简介：肖辉(1982-)，女，湖北省武汉市人，毕业于华中科
技大学移动与通信系统专业，现从事移动核心网维护工作。
193

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。