永不掉线的LTE终端？

燚先生

是的，你没有看错，正如标题所说LTE终端的掉线不会由于终端发起，如果出现掉线，只有通过网络发起，到底是什么情况呢，今天我们来探探究竟。

一般无线通信设备在统计掉线/掉话时候，都是通过基站侧的包含cause value的信令交互进行统计，然后通过计数器（counter）进行数值统计。那么在LTE的掉线统计中的信令是什么呢？

就是上图中的UE上下文释放信令，该信令属于S1接口中的应用协议（S1 AP），触发该信令的原因值有很多，36.413中进行了举例，例如 “UserInactivity”, “Radio Connection With UE Lost”, “CSG Subscription Expiry”,“CS Fallback triggered”, “Redirection towards 1xRTT”, “Inter-RAT Redirection”, “UE Not Available for PS
Service”，“TX2RELOCOverall Expiry”

有些原因值属于正常释放，例如,“CS Fallback triggered”, “Redirection towards 1xRTT”, “Inter-RAT Redirection”等，意味网络侧将UE通过RRC Connection Release的方式CSFB或者重定向到其他的2，3G网络。因此这些原因值带来的UE上下网释放会在掉线统计时被剔除，这是各大运营商本身在制定规范标准需要进行明确的，3GPP规范并不做任何约束。对于给现网“诊病治疗”的通信工程师来讲，一般不需要太关心这些正常的原因值，而且恰恰将研究重心转向那些异常的情况，例如“Radio Connection With UE Lost”,Radio resources notavailable,Failure in the RadioInterface Procedure,Cell not available，TS1RELOCoverall Expiry,TS1RELOCprep Expiry,等等。

我们先看看TS1RELOCoverall Expiry,TS1RELOCprep Expiry这组定时器超时的原因分析，一个正常的切换流程在S1接口部分涵盖两个流程，切换准备阶段（含切换资源分配流程）以及用户上下文的迁移阶段



下图是LTE UE网内通过S1切换的一个端到端流程，

这里在基站侧涉及到两个定时器，TS1RELOCprep 控制了基站之间资源准备的流程，TS1RELOCoverall控制了用户上下文转移释放流程，TS1RELOCprep基本都是基站之间内部流程资源协调之间出现的问题，不太可能是漏配邻区导致，如果没有配置目标基站作为邻区，那么也不会发送切换请求指令，同时TS1RELOCprep定时器都不会启动。超时有可能是这么几种原因，定时设置较小，切换资源准备流程交互时间较长，导致该定时超时前仍没有收到切换指令；目标基站故障或者资源超负荷，已经无法容纳新建至少一条non-GBR E-RAB资源；或者切换准备中出现了错误，错误原因值返回时该定时已超时。一旦该定时器超时，源目标基站会触发切换取消流程，而不管是否收到切换取消响应，源基站都认为对该UE的切换准备取消了，此时虽然不计作掉线，但是会切实影响用户感知，可能造成UE侧下行失步继而引发后续的RRC重建流程，或者UE侧上行失步引发的随机接入流程。如果我们是设备厂家人员，将该定时器设置朝向另一个极端，例如无穷大，那么可能引发什么现象么，我们一起再分析下。这时会造成定时器永远在线，不会出现定时超时造成的切换取消，那么后续很可能会出现UE侧上下行失步导致的RRC重建或者随机接入。那么通过S1接口提取信令不会看到太多的异常，而且对于eNodeB负荷也不会有太多的影响（除非大量的切换需求没有响应，这么做在高铁的时候是比较危险的，目标基站出现故障的情况下，源基站也可能被大量永久在线的切换准备定时器撑爆），这样做从目前的S1信令提取手段来看感觉能够“瞒天过海”，因此运营商进行网络管理时需要对该定时器进行关注。

下面我们来看看TS1RELOCoverall定时器，该定时器控制了UE上下文的转换，如果该定时器启动，那么意味着源基站已经收到了切换指令（HANDOVER COMMAND），TS1RELOCprep定时终止，同时源基站已经向UE下发了含切换指令IE的RRC重配信令，如果该定时设置过小，在超时前没有收到MME发出的UE上下文释放指令，那么源基站会向MME发送UE上下文释放，这会被统计成掉线的，这是谁也不想看到的。那么这个定时器至少应该设置足够大，至少大到MME收到HANDOVER NOTIFY（说明UE已经和目标基站同步完成，上下文已经迁移），大体上可认为该定时至少大于现网T304的设置范围。如果按照上面切换准备定时器的分析逻辑，将TS1RELOCoverall该定时器设置为无穷大，这时该定时器永远在线，S1接口不会出现由于该定时器超时导致的用户上下文释放，也不会出现由此产生的掉线统计。对于这种定时器设置，往往问题会出现在T304超时导致的切换失败而触发后续的重建，当然T304超时的触发原因有多种，我们假设可能是由于切换参数设置不当导致的切换过早或者目标小区弱覆盖/高干扰，那么往往后续的RRC重建可能会选择驻留一个较强小区进行，我们假设该小区是源基站小区，那么此时重建往往会成功，因为此时源基站UE上下文仍然予以保留。对于其他类假设分析情况留给读者自行脑补了。

该定时器如果设置较为合理，例如设置略大于现网T304+T301+T311，那么由于该定时超时导致的源基站UE上下文释放可以一定程度上评估切换失败导致的掉线问题。如果该定时设置足够大，例如远远大于现网T304+T301+T311，而在此期间源基站由于其他的原因（例如Radio Connection With UE Lost等）发起了UE上下文释放请求，这一般意味UE由于T304超时或者RLF原因触发了在目标小区或者第三方小区的重建流程，此时在此时间戳回溯T301+T311时间滑窗，观察目标基站小区或者周边第三方小区是否收到最近的RRC重建请求中附带源基站小区PCI，如果收到了，那么可以认为该定时器的设置和网络侧的优化问题（覆盖，干扰）需要被关联起来进行检视。

下面我们再分析一个原因值Radio Connection With UE Lost导致的eNodeB触发UE上下文释放，对该原因值协议并没有给出过多的描述，只说明了网络侧丢失了对于UE的无线连接，因此可认为网络侧长期没有收到对于UE侧的下行数据传输响应，这样一种可能是UE检测到无线链路的下行失步，或者由于无线链路上行阻断没有成功收到ACK，如果上下行失步导致的RRC重建或者随机接入在检测到Radio Connection With UE Lost之前在源基站收到，那么就不会触发后续的UE上下文释放流程了，对于上行空口阻断，很难单纯通过S1信令来进行分析，需要结合UE侧的信令。对于后续RRC重建在源基站小区，需要通过回溯检视RRC重建请求之前的MR测量判断源小区的绝对弱覆盖问题，而对于RRC重建的其他基站小区，则首先需要检视该小区与源小区的邻区关系以及相应的切换参数设置。

LTE网络技术相比2，3G网络增加了RRC重建机制（可重建在其他小区），这可能由于LTE主要是数据业务网络，通过该机制能够一定程度挽救掉线，保护用户感知，因此只有在eNodeB触发的UE上下文释放才被统计为掉线，所以，从终端的角度来看，LTE可以认为是“永不掉线”的，其实从234G延续下来对于整个电信网的设计思想都是一致的，就是网络侧控制指标统计，那么掉话/掉线都只能由于网络侧来触发统计了。