Drop Sessions(Part 1 of 2)

有多种原因可以使LTE drop。然而，会话是否被丢弃依赖于特定的供应商的实现。也就是说，下降可能会由UE消息或由eNodeB进行的测量所引起的。

两个UE和eNodeB可检查无线电链路是否in-syn。在该博客，我们将描述该UE执行，以确定是否所述无线电链路是in-syn及其后果的活动。这个博客的第2部分，将展示该eNodeB可进行以确定无线电链路是，同步或不活动。

什么时候无线链路in-syn？

UE监控下行链路中的RS。基于所述参考信号（即RSRP）的信号强度，则UE确定它是否能够基于在规范中提供的一组特定的参数来解码PDCCH。每个UE都会有不同的RSRP阈值，低于阈值它会认为它无法读取PDCCH。如果参考信号具有足够的强度，使得该UE能够始终如一解码PDCCH，则链路的in-syn。

我们如何确定无线链路不同步？

确定是否由于不同步而链路失败的全部程序示于下图。在画面中，有示出三个参数：

N310：该参数表示当UE由于检测到低的RSRP而无法成功解码PDCCH的200毫秒间隔。即该参数表示的时间内UE无法成功解码连续20帧在下行链路的数目。

T310：它是一个定时器，在几秒钟内，用于允许UE取回与所述eNodeB的同步。

N311：该参数表示的100毫秒的间隔，该UE必须成功解码所述PDCCH的数量，从而重新和eNodeB in-syn。即该参数表示的时间内在下行链路中UE必须成功解码连续10帧，为了使UE认为无线电链路是in-syn的数目。

如果UE检测N310连续失同步指示，它会启动T310定时器。如果计时器超时，链接失败。如果UE检测N311连续在同步之前的T310定时器没有超时，则定时器停止，链路没有失败。



UE检测到链路故障后，会发生什么？

如果UE确定无线电链路失败，则UE将尝试重新连接的RRC连接重建请求消息。有一些情况下，可能发生基于供应商实现。

如果eNodeB不支持RRC连接重建呢？

在下面的图中所示的情况是在eNB不支持RRC连接重建时最简单的情况。在这种情况下，eNB响应RRC连接重建拒绝消息。同时，则eNB将认识到，无线链路已失败，并请求连接释放到MME。它首先请求删除UE上下文或到UE的连接。原因值被设置为“与UE丢失无线连接。”该MME将UE Context Release Command作出响应。此时，所述eNodeB将响应UE Context Release Complete消息发送到MME，并通过发送RRC Connection Release消息到UE释放与UE的RRC连接。根据不同的射频情况下，则UE可以接收或不接收该消息。



如果eNodeB确实支持RRC连接重建？

如果所述eNodeB支持RRC连接重建，并假设eNodeB发现两个UL和DL同步（当它接收到RRC连接重建请求消息时），可能会出现两种情况：RRC连接重建的成功和失败。

在一个RRC连接重建成功的情况下，下面的信令进行交换。



如果RRC连接被成功地重建，则会话不会被删除。

如果RRC连接重建过程失败的其步骤之一，则eNodeB将发送UE context release request消息发送到MME。需要注意的是在RRC连接重建过程可以在几个步骤失败。下面，在图中，仅示出一个案件。



如果RRC连接重建失败，则会话被丢弃。

如果增加了RS的功率，如果增加N310，如果增加T310，或者如果你减少N311为最小值，drop数量将减少。