LTE 光连接模式下的UE状态和流程

光连接最关键是需要减少信令，旨在减轻UE在CONNECTED和IDLE状态之间转换所造成的信令负担。协议在最初的讨论中已经提出的开放问题之一是如何建模和指定LTE光连接模式。最初考虑了三种主要方法——一种单独的状态，IDLE和CONNECTED——RAN WG2从中选择了一种主要方法，即尝试在不引入新状态的情况下重用现有状态。然而，对于IDLE或CONNECTED哪个选项更好，尚无定论。

Light connection模式下的UE状态建模

在深入研究每个建模选项的优点和缺点的更具体细节之前，值得注意的是协议RAN已经达成的一些相关协议：

1.当UE被配置为具有光连接模式时，从MME的角度来看，UE状态是EMM_CONNECTED，并且保持S1接口。

2.当UE被配置为具有光连接模式时，从eNB的角度来看，UE状态是RRC_CONNECTED。

因此，关于NAS/AS状态，RAN 已经从网络侧的角度假设UE状态是CONNECTED（更准确地说，EMM_CONNECTED/RRC_CONNECTED）。然而，如引言中所述，未决定应为UE侧选择哪个选项。然而，RAN 一直隐含地假设NAS/AS处于相同状态。换言之，EMM_CONNECTED/RRC_COCONNECTED和EMM_IDLE/RRC_IDLE是两个主要选项。

一般来说，“状态”的整个概念假设，通信双方应该对当前状态有相同的理解，以采取相应的行动和对外部触发做出反应。如果一个人建立了一个无论另一个实体的“状态”如何都能正常运行的系统，那么它实际上意味着它没有任何功能含义，因此是多余的。

EMM_IDLE/RRC_IDLE建模选项

关于该建模选项（为清楚起见，因此称为“IDLE”），CT 初步确定了以下问题：

1.处于空闲模式的UE启动周期性跟踪区域更新过程。然而，从MME的角度来看，UE处于EMM_CONNECTED模式，因此后者既不运行其移动可达定时器，也不期望从UE接收这样的指示（这实际上可能触发某些特定于实现的恢复过程，因为MME可能认为存在状态失配）。当然，克服此问题的潜在解决方案是强制UE不向MME发送这些指示当ue发现需要发起切换时，就像UE处于EMM_CONNECTED中一样。

2.对于移动发起的数据和信令消息，处于IDLE状态的UE需要发送相应的服务请求，从MME的角度来看，其接收将是模糊的。如在上面的情况中，为了绕过这个问题，需要防止UE发送这个指示，再次偏离IDLE状态的当前功能。

3.存在假定两个通信端处于相同状态的某些特征。其中之一是PSM，它仅适用于处于IDLE模式的UE，其激活在NAS层协商。如果从MME的角度来看，UE仍处于连接模式，则一旦下行数据到达MME，MME将立即将其转发给eNB，eNB将尝试到达UE。然而，被配置为具有空闲状态的PSM模式的UE可能简单地无法接收eNB指示，因为它不会监听寻呼信道。

EMM_CONNECTED/RRC_CONNECTED

关于此建模选项（因此称为“仅连接”），协议和其他公司初步确定了以下关键问题：

1.该选项的主要关注点之一是如何确保对移动源数据的访问控制。假设RAN WG2将启用一些现有的接入控制机制，将对NAS/AS交互产生一些影响，以确保NAS向AS层提供相应的信息。

2.在讨论期间提出的另一个问题是，由于处于光连接模式的UE将执行自主小区重选当ue发现需要发起切换时，而从MME的角度来看，它处于EMM_CONNECTED模式，因此移动性应由MME控制，因此是否会对当前的过程和要求产生任何影响。

光连接的信号流程

在将UE重新配置为光连接模式时，UE和“锚”eNB都保持UE上下文。然而，当在寻呼区域周围移动时，UE可以最终到达另一eNB，该eNB可以属于相同或不同的寻呼区域。为了进一步简化，我们将分别考虑当UE停留在同一区域中和当UE跨越寻呼区域边界时的情况。

同一寻呼区域

如果UE停留在同一寻呼区域内而不需要与网络交换数据，即不存在移动触发或移动终止呼叫，那么我们不期望UE向网络发送任何消息，这旨在消除不必要的信令负载。相反，由于UE可以开始在不同的eNB中交换数据，因此应该有一种方法来确保对应的eNB具有UE上下文信息。原则上，我们可以重用UE上下文检索过程，以便一旦UE获得对新eNB的访问，就将相应的信息传送给它。图1示出了在网络元件之间交换的用于移动发起和移动终止呼叫的信令消息的示例集合。可以看出，共同点是UE通过新的eNB发送消息，之后获取UE上下文并将其移动到新位置。这两种情况之间的唯一区别是UE作为UL数据的存在的结果或者作为通过整个寻呼区域发送的接收寻呼消息的结果发送RRC消息。

图1:MO和MT呼叫的一组示例性信令消息

从图1中可以看出，原则上，我们可以重用CIoT框架引入的RRC消息，以向网络指示UE具有UL数据（或已经从网络接收到寻呼指示），之后，根据现有过程，网络将为CONNECTED模式提供配置。必须注意，RRC ConnectionResumeRequest消息必须具有相应的指示符（隐式或显式），以便网络知道UE必须保持在CONNECTED模式，这不是RAN区域更新过程。

不同的寻呼区域（存在X2）

也可能存在这样的情况，即UE刚刚越过寻呼区域边界，而没有被寻呼或其UL缓冲器中没有数据。如果X2接口可用，那么我们可以遵循与移动发起呼叫相同的原则，因此UE上下文将移动到新寻呼区域中的新eNB，如图2a所示。参考该图，与移动发起的呼叫相比，唯一的本质区别在于，一旦eNB从UE接收到RRC ConnectionResumeRequest消息，前者将要求UE移回到光连接模式。

图2：寻呼区域更改的一组示例性信令消息

不同的寻呼区域（X2不存在）

回到图2（a，b）中描述的信令过程，假设源和目标eNB之间存在X2接口，即使它们属于不同的RAN寻呼区域。然而，存在eNB不具有X2建立的接口的情况，这对于属于不同RAN寻呼区域的两个eNB来说是很容易的情况（事实上，构建RAN寻呼区的一种方法是将在它们之间建立X2接口的eNB分组在一起）。

为了克服这个问题，应该还建议依赖允许通过MME在目标eNB处建立UE上下文的现有信令。如下图3所示，如果目标eNB不具有UE上下文并且也不能联系源eNB，则它不能“接受”恢复过程，而是将触发RRC连接的建立。如果UE向MME（例如TAU）发送NAS消息，则在接收到该消息后，MME可以在旧eNB处释放UE上下文，并向新eNB提供相应的信息。新eNB将负责决定下一步采取哪些行动，包括将UE移动到光连接模式的决定。

图3：寻呼区域更改的一组示例性信令消息（无X2接口）