I-RNTI是Inactive RNTI的缩写，它是per RNA配置的一个参数, 主要作用就是UE在RRCResume的时候, 方便new gNB去获取UE之前的锚点gNB(从而获取UE上下文)。

在R2-1812504中有关I-RNTI的agreement如上图：

1 gNB 在suspend消息中为 UE 配置full I-RNTI 和short I-RNTI。UE 将根据 SI 中的恢复消息大小指示在RRCResumeRequest 中使用full或short I-RNTI。

2 支持一个备用位，包括 Msg3 中最右边的 39 位 5G-S-TMSI，并相应地从 msg3 位中的随机值中减少一位。

3 支持 4 位原因值

UE会从RRCRelease->suspend消息中收到两个 I-RNTI。gNB 将从full I-RNTI 中派生出short I-RNTI，并将它们都发送给 UE。full I-RNTI 能够定位一个特定的source gNB 来检索 UE context。当 UE需要传输受限大小的 Msg3 时，尤其需要short I-RNTI。由于short I-RNTI 没有足够的比特，short I-RNTI 可能对应多个full I-RNTI。从 UE 的角度来看，当网络要求 UE 适应上行消息的有限大小时，就需要short I-RNTI。从 gNB 的角度来看，当target gNB 收到short I-RNTI 时，target gNB 可能无法确定特定的source gNB，而是确定多个潜在的 gNB，这是不可避免的。因此，short I-RNTI 有利于上行传输，但可能会导致target gNB 的额外工作。

正常的UL-CCCH总共也就是48bit, 但是这样就意味着只能使用short-I-RNTI了, 24bit的这种短I-RNTI, 可能会让new gNB在查找时候出现识别锚点gNB的分歧, 所以如果一个小区覆盖比较小的时候, 小站覆盖一般比较好, 可以可靠接收, 所以这个小区可以通过SIB1告诉所有UE可以使用40bit的I-RNTI, 避免查找锚点gNB的分歧。

那 shortI-RNTI如何实现full I-RNTI的功能 主要看gNB实现了。