从LTE开始，无线网络的目标是允许UE保持在“始终连接”模式，这有效地涵盖了许多场景，例如初始建立连接或过渡到UE可以开始与网络交换数据的状态。在RAN2#98会议期间，NR引入了INACTIVE状态，该状态被建模为独立的RRC状态。其实在层2还考虑了许多状态转换案例，并就如何实现这些案例做出了决定。如何准确地引用INACTIVE状态以及CONNECTED是否引用特定RRC状态或是否应该有一种方法来指示UE具有AS上下文，而不管其处于何种RRC状态。
在3G时代，也就是UMTS系统中引入了不同的RRC状态。参考TS 25.331，从NAS层的角度来看，UE可以处于空闲模式或连接模式，因此连接模式包括另外四种不同的RRC状态：URA_PCH、CELL_PCH、CellL_FACH和CELL_DCH。当准确的RRC状态不重要时，这种方法允许区分IDLE和CONNECTED模式，但更重要的是强调UE具有AS上下文。同时，可以参考特定RRC状态，例如CELL_DCH。
对于NR系统，可能会出现与UMTS中完全相同的术语问题：有时需要指示UE处于CONNECTED模式，这意味着它具有as上下文，而有时需要参考特定的RRC状态（例如，INACTIVE或ACTIVE/CONNECTED）。考虑到NR第2阶段和第3阶段规范已经将RRC状态称为RRC_IDLE、RRC_INACTIVE和RRC_CONNECTED，可以通过如下图2所示区分特定的RRC状态和“模式”。该方法的另一个优点是它与LTE技术（只有IDLE和CONNECTED）在逻辑上一致，并且当连接到5G CN时也可能具有INACTIVE状态。
避免术语歧义的一种更激进的方法是将RRC_CONNECTED状态重命名为RRC_ACTIVE，如图3所示。换句话说，CONNECTED模式将包含两种RRC状态：RRC_INACTIVE和RRC_ACTIVE。优点是CONNECTED模式将明确地指代AS模式，并且不会与图2所示的相应RRC状态混淆。这种方法的缺点是，即使NR RRC_ACTIVE将直接对应于LTE CONNECTED，名称也会不同。
图4提供了NR RRC状态机的高级概述，以及RRC状态之间的可能转换。INACTIVE被建模为独立的RRC状态，因此可以设想以下状态转换情况：
从IDLE到CONNECTED以及从CONNECTED到IDLE；
从已连接到未激活，以及从未激活到已连接；
从停用到空闲。
关于从INACTIVE状态到IDLE状态的状态转换，可能存在各种错误情况，因此UE丢失其上下文或重新排序以重新建立其RRC连接和AS上下文。除此之外，还有由网络内部RRM机制触发的正常RRC连接释放过程。即使可以假设没有用户面活动的UE将长时间保持在INACTIVE状态，但不能假设网络将无限地保持UE处于该状态；也不能强制执行这种网络行为。此外，即使网络原则上可以在不通知UE的情况下删除UE上下文，并在下一次连接尝试时要求其建立新连接，但这不是运行整个系统的最有效方式，因为UE将需要更多时间来恢复其连接。除此之外，某些潜在特征的功能，例如INACTIVE中的数据传输，将要求网络保持UE上下文，结果，网络仍将寻求发送明确指示以释放UE RRC连接。
用于将UE从INACTIVE重新配置为IDLE的基线过程是使得网络首先将UE带到CONNECTED模式，从该模式可以将其连接释放到IDLE。然而，如图5所示，它将涉及在gNB和UE之间交换的大量RRC消息，因为前者必须寻呼UE（1条消息），确保其已进入CONNECTED模式（3条消息用于基线恢复过程），并最终释放连接（1条信息）。当网络确实有理由将UE移动到CONNECTED状态之后，可以将其释放到IDLE时，该动作序列更适用于这种情况。
减少RRC消息数量的最简单方法之一是允许网络响应请求消息发送消息（例如RRCConnectionRelease）。相应的一组消息如下图5所示，涉及UE和网络之间交换的3个RRC消息。响应消息是否应该始终加密并通过SRB1发送，以便UE可以信任它，或者是否也允许通过SRB0发送响应消息。
从图5中可以看出，仍需要3个RRC消息将UE从INACTIVE移动到IDLE，可以认为，将UE从一个功率有效状态移动到另一个功率高效状态是一个简单操作的巨大信令开销。进一步最小化RRC消息数量的解决方案之一是对RRC寻呼消息采用新的原因值，这将指示UE释放其连接。如图6所示，一旦UE从网络接收到寻呼+释放指示，它将向网络发送“完成”消息，确认接收到该寻呼指示符。如果网络从UE接收到响应，则它将知道UE已经接收到寻呼并且将释放其连接；否则网络可以考虑重新发送寻呼消息。
作为图6所示解决方案的进一步优化，可以考虑从UE中删除“完整”消息。此解决方案已经存在于UMTS规范中，但由于没有来自UE的“响应”，因此有些不可靠。换言之，当网络发出带有“释放”命令的寻呼消息时，后者不知道UE是否接收到该寻呼消息，因此不知道如何到达该寻呼消息。另一方面，处于INACTIVE状态的UE也可以接收CN寻呼消息，这意味着即使UE错过了RAN级寻呼，它仍将对网络稍后可能发送的CN寻呼采取行动。
