Haykey哥最近处理了两个Bug，相同点都是由于网络异常导致手机呈现出通信问题。为什么可以这么肯定地说是网络异常呢？因为翻看协议后发现网络的行为严重违反协议规定，特拿出分享给大家品鉴。
在步入正题之前，先扯点有意思的：）。在Haykey哥服务过的诸多公司里，对于这种由于网络问题引起的手机行为异常，按照处理方式会分为两类。
第一类是国际大厂们，一般会提供技术分析文档（tech memo)，然后联系运营商接口人，尝试让其involve网络设备相关人等修改网络配置以及行为；
第二类是国内移动互联网厂商们，永远是网络问题手机端解决的思路，一是没有渠道或者能力去联系运营商，设备商，二也是出于提高改善用户体验的角度；
其实这两种处理方式各有利弊，从终端用户的角度来看更倾向于后者，排除价格因素，所以也好理解目前国际大厂在中国节节败退，一个接一个品牌退出中国市场也都是早晚的事情。从通信行业从业者角度，其实我更倾向于前者，你网络有问题，你就应该修整啊！
好了，现在让我们看看这两个现实案例吧。
问题一： 在爱沙尼亚，开机或开关飞行模式后，手机都无法注网PLMN号248-03的Tele2 EE的网络
过滤完OTA日志后，很明显可以看出是UE回复了NAS SMC reject后导致Attach失败，NAS SMC Reject还携带了原因值UE security capability mismatch。通过这条线索，我们继续看看网络发给UE的NAS SMC都带了那些UE安全相关的能力，如下包含了EEA/EIA/UIA/UEA各算法的支持情况
那实际上UE支持的安全相关的能力又有哪些呢？在UE发给网络的Attach Request中，我们可以找到以下答案。
在表示3G/4G相关能力的UE_Network_Cap IE里，包含支持不支持的EEA/EIA/UEA/UIA算法
在表示2G相关能力的MS_Network_Cap IE里包含了支持和不支持的GEA算法，但这些GPRS相关的加密算法在网络发给UE的NAS SMC中是不包含的，UE security capabililty mismatch是不是跟这个相关呢？
查阅了EMM的代码后发现就是简单的一句内存比较函数memcmp，比较手机本地缓存的安全能力和网络SMC过程带的replayed_ue_sec_capabilities IE。
看了眼对应的结构体lte_nas_emm_ue_security_type后，果不其然导致UE security capabililty mismatch就是因为网络在SMC过程没有包含GEA算法相关IE，memcmp不为0。
那么网路究竟应该包含GEA相关安全参数么？参考下面协议章节
摘自3GPP TS24.301 Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3
5.4.3.2 NAS security mode control initiation by the network
根据标黄的陈述，很显然我们的UE在发送给网络的Attach Request里已经表明UE支持GEA算法，但是MME竟然忽视GEA，在NAS SMC里没有在replayed security capabilities of UE IE中包含GEA相关安全能力是违反协议规定的。 此问题归结于MME在发送NAS SMC异常。
最后，再多说一句这些EEA/EIA/UEA/UIA/GEA算法的支持还是不支持，需要看平台的能力，然后再根据各运营商的需求进行正确的配置。需要配置NV和EF文件如下
（LTE）
/nv/item_files/modem/nas/lte_nas_ue_sec_
（WCDMA）
NV#880 NV_RRC_INTEGRITY_ENABLED_I
NV#881 NV_RRC_CIPHERING_ENABLED_I
NV#882 NV_RRC_FAKE_SECURITY_ENABLED_I
（TDSCDMA）
NV#66011 /nv/item_files/modem/tdscdma/rrc/integrity_enabled
NV#66012 /nv/item_files/modem/tdscdma/rrc/ciphering_enabled
NV#66013 /nv/item_files/modem/tdscdma/rrc/fake_sec_enabled
当然过GCF/PTCRB认证时，对应的PICS/PIXS也要设置正确，如px_UTRAN_CipheringAlgorithm = UEA0 or UEA1 or UEA2
问题二： 在德国Telekom网下，用户关闭IMS开关后，手机不响应Deactivate EPS bearer context request
看看当时欧洲测试人员的问题描述，如下
再聊些题外话，Haykey哥接触过的大多数欧美测试人员，除了不会读代码，那真是又会翻看协议规范，又会查看空口日志的通信专业人才。相比较国内的终端侧黑盒测试人员，更像是个手机玩家角色。一是由于项目压力大没有时间去学习相关领域的专业知识，只能重复机械性地跑测试用例，二是很多都是刚毕业的新人，但凡业务熟练成为老司机了，必然会往QA，Test Lead， PM角色转型（间接也解释了为啥很多R&D会认为大部分PM技术方面啥也不懂，更像是个协调为主的秘书，干些Call会，发总结性mail，Push人事宜为主）。这样陷入了恶性的死循环，永远都是新手在做实际的测试工作。扯远了，回正题啊：）
查看OTA日志，确实如测试人员所说，当UE收到了Deactivate EPS bearer context request MSG后未发送后续的DEACTIVATE EPS BEARER CONTEXT Accept。
Haykey哥比起欧美测试人员多的一项技能就是可以查看协议栈软件的工作日志和会看code，这不能浪费了，以第一次UE收到Deactivate EPS bearer context req为例，先去看看ESM层都干了些啥？
关键就是标识为Error类型的MSG 13:21:38.374 NAS SM/Error [ esm_bpm.c 839] DS: SUB 1 ESM: Unknown or unassigned PTI 58 received by ESM
提示收到的procedure transaction identity (PTI) = 58不正确，导致UE忽略Deactivate EPS bearer context request信令
那么协议是怎么规定Deactivate EPS bearer context request Msg所带的PTI呢？
摘自3GPP TS24.301 Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3
6.4.4.2 EPS bearer context deactivation initiated by the network
读者朋友们可以连读我标黄的句子，大体意思就是如果deactivation是由于UE要求PDN连接释放过程引起，MME应该在Deactivate EPS bearer context request 里设置PTI为其在UE发给它的PDN Disconnect request里收到的一致。
调查方向一转，查看了UE发给MME的PDN disconnect request里PTI就是等于58。MME行为正确！
继续在UE日志上挖掘，发现了PTI = 58被释放的原因，是因为UE在收到MME的Deactivate EPS bearer context request之前先收到了eNB的RRC重配来释放EPS bearer ID = 6对应的DRB5，如下：
//查看L-RRC -> EMM -> ESM的层间处理
MSG 13:21:38.372 LTE RRC/Low [ lte_rrc_config.c 4409] Reconfiguration Message validated
MSG 13:21:38.372 LTE RRC/Low [ lte_rrc_meas.c 28491] ObtainLocCfg absent in RRCConnectionReconfig
MSG 13:21:38.372 LTE RRC/Low [ lte_rrc_config.c 4213] Sending Config Request to LLC
MSG 13:21:38.372 LTE RRC/High [ lte_rrc_llcdb.c 5220] PDCP DL: rb_cfg_idx 5 being released
MSG 13:21:38.372 LTE RRC/High [ lte_rrc_llcdb.c 5670] MAC: Logical channel 4 being released
MSG 13:21:38.373 LTE RRC/High [ lte_rrc_llcdb.c 5265] PDCP UL: rb_cfg_idx 5 being released
MSG 13:21:38.374 LTE RRC/High [ lte_rrc_llcdb.c 4102] Active EPS id 5, RB id 4
//UE本地释放EPS ID=6, RB ID=5
MSG 13:21:38.374 LTE RRC/High [ lte_rrc_llcdb.c 4122] Removed EPS id 6, RB id 5
MSG 13:21:38.374 LTE RRC/High [ lte_rrc_llcdb.c 4128] Num active bearers 1, Num added bearers 0,Num removed bearers 1
MSG 13:21:38.374 LTE RRC/High [ lte_rrc_config.c 6152] Active EPS bearers list sent to NAS
//L-RRC发送LTE_RRC_ACTIVE_EPS_BEARER_UPDATE_IND原语到EMM
MSG 13:21:38.374 NAS MM/High [ emm_rrc_handler.c 6089] DS: SUB 1 =EMM=LTE_RRC_ACTIVE_EPS_BEARER_UPDATE_IND, set nas_secure_exchange to TRUE
MSG 13:21:38.374 NAS MM/High [ emm_esm_handler.c 2057] DS: SUB 1 =EMM= Active EPS bearer update ind - Added 0, rmved 1, active 1
MSG 13:21:38.374 NAS MM/High [ emm_esm_handler.c 2125] DS: SUB 1 =EMM= Active EPS bearer ID 5, RB_ID 4
MSG 13:21:38.374 NAS MM/High [ emm_esm_handler.c 2147] DS: SUB 1 =EMM= Removed EPS bearer ID 6, RB_ID 5
MSG 13:21:38.374 NAS MM/High [ emm_esm_handler.c 2161] DS: SUB 1 =EMM= SentNAS_ESM_ACTIVE_EPS_IND
//EMM发送NAS_ESM_ACTIVE_EPS_IND原语到ESM
MSG 13:21:38.374 NAS SM/Low [ esm_bcm.c 1196] DS: SUB 1 ESM: Enter BCM: handle_emm_message\n
MSG 13:21:38.374 NAS SM/High [ esm_bcm.c 1251] DS: SUB 1 ESM: Active EPS IND - Added 0,rmved 1, active 1
MSG 13:21:38.374 NAS SM/High [ esm_bcm.c 1300] DS: SUB 1 ESM: Romved EPS bearer ID 6, RB_ID 5
MSG 13:21:38.374 NAS SM/High [ esm_utils.c 914] DS: SUB 1 ESM: Sending DEACT BC REQ - BID 6,Default 1, LBI 0
// PTI=58被释放！
MSG 13:21:38.374 NAS SM/High [ esm_bpm.c 220] DS: SUB 1 ESM: PTI 58 is released
那UE的这种本地释放EPS bearer的行为是否正确呢？
摘自3GPP TS24.301 Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3
参照以上协议的第4种情况，当eNB释放了DRB后，手机应该本地释放DRB对应的EPS bearer而无需通过ESM信令再通知对端MME，手机行为完全满足协议要求。
问题就出在无线侧eNB处异常，发送了异常RRC重配，正常情况下的eNB会下发不仅包含DRB释放还会包含NAS信令（即Deactivate EPS bearer context request）的RRC重配消息，如下：
问题三：在国内，遇到联通网络下发异常 DETACH, 导致手机从LTE长时间回落到2/3G
如果说以上两个网络问题引起的手机异常，还有依可循的话，这个问题就是无厘头了。当时SPM直接拿着插有联通4G卡的手机找到我工位，说手机有问题上不了4G，开关飞行模式，重启手机都无改善，让我现场抓日志分析。
一旦手机attach成功后，联通LTE网络就会下发DETACH 原因值为 cause#40 "No EPS bearer context activated", 同时 detach_type值为2 "re-attach not required"时，根据 3GPP TS24.301 5.5.2.3.4, 需要忽略当前LTE 网络，并尝试其他2G/3G网络。
LTE NAS EMM Plain OTA Incoming Message -- Detach request Msg
prot_disc = 7 (0x7) (EPS mobility management messages)
msg_type = 69 (0x45) (Detach request)
lte_emm_msg
emm_detach_request
switch_off = 0 (0x0) (normal detach)
detach_type = 2 (0x2) (re-attach not required)
emm_cause_incl = 1 (0x1)
emm_cause
cause_value = 40 (0x28) (No EPS bearer context activated)
摘自3GPP TS24.301 Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3
本情况满足协议的第b种情况，所以UE的处理又是完全遵守协议规定的。但是SPM可不管UE是遵守还是违反协议规定，为了用户体验，让手机端寻找解决方案来规避此诡异网络问题。要说Q公司也开始走M公司亲民路线了，毕竟全球5大里中国公司占据三席，竟然也专为这种国内网络问题做了个workaround，通过EFs文件
/nv/item_files/modem/nas/mt_detach_abnormal_handling开关控制。
如果开关打开，即mt_detach_abnormal_handling值=1时，会强制映射成DETACH 原因值为17 NW failure，并且detach_type值为re-attach required来防止UE disable LTE
好了，今天就到这里。（本文完）
来源：CSDN
作者：知不足而奋进
链接：https://blog.csdn.net/ZhongGuoRenMei/article/details/103679404