51学通信

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 6 - 寻呼、异系统切换与连接释放)

19分钟阅读

好的，我们继续3GPP TS 38.331规范的第六章。在Part 5中，我们跟随主角“小明”的高铁之旅，深入探讨了UE如何上报测量结果和各种链路失败信息。现在，小明的旅途告一段落，手机进入了相对“平静”的状态。本章，我们将聚焦于UE生命周期中几个关键的转折点：从静默中被唤醒、跨系统网络的无缝漫游、以及会话结束后的优雅退场。

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 6 - 寻呼、异系统切换与连接释放)

本文技术原理深度参考了3GPP TS 38.331 V18.5.0 (2025-03) Release 18规范中，关于“6.2.2 Message definitions”章节中涉及Paging、MobilityFromNRCommand和RRCRelease这三个核心消息的内容。本文旨在为读者清晰地描绘UE如何从空闲/非激活状态被网络唤醒，如何从5G网络平滑切换到4G网络，以及RRC连接如何被网络挂起或彻底释放的完整信令图景。

新的场景：从城市到郊野的旅程

我们的主角“小明”结束了高铁旅行，回到了市区。他的手机在不使用数据业务时，为了省电，被网络置于RRC_INACTIVE状态。

  1. 场景一：朋友来电。小明正在咖啡馆休息，手机静静地躺在桌上。突然，朋友打来电话。核心网如何通知到他的手机？Paging消息将在此刻登场。

  2. 场景二：驶入4G覆盖区。接完电话，小明驾车前往郊野公园。途中，汽车驶入一片只有4G覆盖的区域。为了保证通话和导航不中断，5G网络必须将他的手机无缝切换到4G网络。MobilityFromNRCommand将是这次跨系统“接力”的关键指令。

  3. 场景三：会话结束。到达目的地后，小明的通话结束，数据业务也暂停了。为了最大化节省手机电量，网络决定将他的RRC连接释放，并转换到RRC_IDLE状态。RRCRelease消息将执行这次“会话终结”操作。

1. Paging (寻呼)

The Paging message is used for the notification of one or more UEs.

解读与场景：

寻呼是移动通信中最基本的功能之一。当UE处于RRC_IDLE或RRC_INACTIVE状态（即与网络没有建立专用的RRC连接）时，如果核心网有下行数据或信令要发给这个UE（最典型的就是电话呼入），它就会在UE最后所在的一片区域（Tracking Area或RAN Notification Area）内的所有基站上发起“广播喊话”。Paging消息就是这个“喊话”的内容。

  • 信令承载: N/A

  • RLC-SAP: TM (透明模式)

  • 逻辑信道: PCCH (Paging Control Channel)

  • 方向: Network to UE

1.1 消息结构 (ASN.1)

 
Paging ::= SEQUENCE {
 
    pagingRecordList                PagingRecordList OPTIONAL, -- Need N
 
    lateNonCriticalExtension        OCTET STRING OPTIONAL,
 
    nonCriticalExtension            Paging-v1700-IEs OPTIONAL
 
}
 
PagingRecordList ::= SEQUENCE (SIZE(1..maxNrofPageRec)) OF PagingRecord
 
PagingRecord ::= SEQUENCE {
 
    ue-Identity                     PagingUE-Identity,
 
    accessType                      ENUMERATED {non3GPP} OPTIONAL, -- Need N
 
    ...
 
}
 
PagingRecord-v1800 ::= SEQUENCE {
 
    mt-SDT                          ENUMERATED {true} OPTIONAL -- Need N
 
}
 
PagingUE-Identity ::= CHOICE {
 
    ng-5G-S-TMSI                    NG-5G-S-TMSI,
 
    fullI-RNTI                      I-RNTI-Value,
 
    ...
 
}

1.2 关键参数与表格解读

| 字段名 (PagingRecord) | 描述 |

|:---|:---|

| accessType | 指示寻呼消息是否源于非3GPP接入的PDU会话。 |

| inactiveReceptionAllowed | 指示具有有效PTM配置的UE是否在PAGINGGROUPList中的TMGI下停留在RRC_INACTIVE状态以接收相应的MBS多播会话。 |

| mt-SDT | 移动终端小数据传输（SDT）指示。网络仅当UE的I-RNTI包含在寻呼消息中时，才在寻呼消息中包含mt-SDT指示。 |

| pagingRecordList | 寻呼记录列表。网络可以一次寻呼多个UE。 |

| pagingCause | 指示寻呼消息是否源于IMS语音。 |

| pagingGroupList | 寻呼组列表。 |

  • pagingRecordList: 一条Paging消息可以同时“喊”多个UE。这个列表中的每一条PagingRecord都针对一个特定的UE。

  • ue-Identity: 这是寻呼的核心，用于标识被寻呼的UE。它是一个CHOICE类型：

    • ng-5G-S-TMSI: 当UE处于RRC_IDLE状态时，网络使用由核心网分配的5G-S-TMSI作为其主要标识。

    • fullI-RNTI: 当UE处于RRC_INACTIVE状态时，网络使用由gNB分配的I-RNTI作为其标识。I-RNTI比5G-S-TMSI更“本地化”，仅在RAN范围内有效。

  • pagingCause-r17: 指示寻呼的原因。例如，voice表示这次寻呼是由IMS语音电话触发的。这可以帮助UE在后续接入时设置正确的建立原因（establishment cause）。

  • mt-SDT-r18: 这是一个Rel-18引入的重要新特性，用于被叫小数据传输（Mobile Terminated - Small Data Transmission）。如果小明手机处于RRC_INACTIVE态，此时来了一条微信短消息。网络可以在寻呼时设置mt-SDT为true，指示UE可以使用SDT流程来接收这条消息，而无需恢复到完整的RRC_CONNECTED态，从而大大降低信令开销和功耗。

在小明朋友来电的场景中，gNB会广播一条Paging消息，其中ue-Identity将是小明手机的I-RNTI（因为他处于INACTIVE态）。手机的RRC层在自己的寻呼时机（Paging Occasion）监听到这条消息并匹配到自己的ID后，会立即“醒来”，并发起RRCResumeRequest流程，恢复到连接态，准备接听电话。

2. MobilityFromNRCommand (从NR切换指令)

The MobilityFromNRCommand message is used to command handover from NR to E-UTRA/EPC, E-UTRA/5GC or UTRA-FDD.

解读与场景：

这是5G NR网络指挥UE**切换到其他无线接入技术（RAT）**的指令，主要是切换到4G LTE（E-UTRA），也可以是3G（UTRA）。这条消息本身是一个“容器”或“信封”，它里面封装了目标RAT的RRC消息。

  • 信令承载: SRB1

  • RLC-SAP: AM

  • 逻辑信道: DCCH

  • 方向: Network to UE

2.1 消息结构 (ASN.1)

 
MobilityFromNRCommand ::= SEQUENCE {
 
    rrc-TransactionIdentifier       RRC-TransactionIdentifier,
 
    criticalExtensions              CHOICE {
 
        mobilityFromNRCommand       MobilityFromNRCommand-IEs,
 
        criticalExtensionsFuture    SEQUENCE {}
 
    }
 
}
 
MobilityFromNRCommand-IEs ::= SEQUENCE {
 
    targetRAT-Type                  ENUMERATED { eutra, utra-fdd-v1610, spare2, spare1, ...},
 
    targetRAT-MessageContainer      OCTET STRING,
 
    nas-SecurityParamFromNR         OCTET STRING OPTIONAL, -- Cond HO-ToEPCUTRAN
 
    ...
 
}

2.2 关键参数与表格解读

MobilityFromNRCommand-IEs 字段描述

| 字段名 | 描述 |

|:---|:---|

| nas-SecurityParamFromNR | 用于NR到LTE/EPC切换的密钥同步和密钥新鲜度传递，以及部分下行NAS COUNT值。 |

| targetRAT-MessageContainer| 包含由targetRAT-Type指示的、在另一个标准中指定的消息。 |

| targetRAT-Type | 指示目标RAT类型。 |

| voiceFallbackIndication| 指示切换是由IMS语音的EPS回退触发的。 |

目标RAT类型与消息容器的对应关系

| targetRAT-Type | 应用的标准 | targetRAT-MessageContainer |

|:---|:---|:---|

| eutra | TS 36.331 (clause 5.4.2) | DL-DCCH-Message including the RRCConnectionReconfiguration |

| utra-fdd | TS 25.331 (clause 10.2.16a) | Handover TO UTRAN command |

  • targetRAT-Type: 明确告诉UE要切换到哪个系统，例如eutra（即4G LTE）。

  • targetRAT-MessageContainer: 这是异RAT切换的精髓。它不是由NR gNB生成的，而是NR gNB通过核心网从目标系统的基站（如4G eNB）获取的。这个字段里包含了一条完整的目标RAT RRC消息。在切换到4G的场景中，它里面就是一条4G的RRCConnectionReconfiguration消息！

  • nas-SecurityParamFromNR: 用于安全上下文的平滑过渡。当小明从5G NSA或5GC网络切换到4G EPC网络时，这个字段携带了必要的安全参数，使得UE无需在切换后重新进行NAS安全模式协商，保证了业务的连续性。

在小明驾车进入4G区的场景中，5G gNB在收到UE关于4G邻区信号强的MeasurementReport后，决定发起异RAT切换。它通过核心网联系目标4G eNB，eNB为小明准备好资源并生成一条RRCConnectionReconfiguration消息。gNB将这条4G消息封装进MobilityFromNRCommand的targetRAT-MessageContainer字段，然后发给小明的手机。手机收到后，会解析出这个“信封”里的4G指令，并据此与目标4G小区进行同步和接入，完成切换。

3. RRCRelease (RRC释放)

The RRCRelease message is used to command the release of an RRC connection or the suspension of the RRC connection.

解读与场景：

这是网络用来结束当前RRC连接的指令。它有两种主要模式：

  1. 彻底释放: 将UE转换到RRC_IDLE状态。UE的上下文会从gNB中删除，下次接入需要走完整的RRC连接建立流程。

  2. 挂起连接: 将UE转换到RRC_INACTIVE状态。gNB会保存UE的上下文（AS Context），UE下次接入时可以走快速的RRCResume流程。

  • 信令承载: SRB1

  • RLC-SAP: AM

  • 逻辑信道: DCCH

  • 方向: Network to UE

3.1 消息结构 (ASN.1)

 
RRCRelease-IEs ::= SEQUENCE {
 
    redirectedCarrierInfo           RedirectedCarrierInfo OPTIONAL, -- Need N
 
    cellReselectionPriorities       CellReselectionPriorities OPTIONAL, -- Need R
 
    suspendConfig                   SuspendConfig OPTIONAL, -- Need R
 
    deprioritisationReq             SEQUENCE {
 
        deprioritisationType            ENUMERATED {frequency, nr},
 
        deprioritisationTimer           ENUMERATED {min5, min10, min15, min30}
 
    } OPTIONAL, -- Need N
 
    ...
 
}

3.2 关键参数解读

| 字段名 (RRCRelease-IEs) | 描述 |

|:---|:---|

| cellReselectionPriorities | 用于小区重选的专用优先级。 |

| cnType | 指示UE被重定向到EPC或5GC。 |

| deprioritisationReq | 指示当前频率或RAT是否需要被降级。 |

| redirectedCarrierInfo | 指示一个载波频率（下行，FDD），用于将UE重定向到NR或inter-RAT载波频率。 |

| suspendConfig | RRC_INACTIVE状态的配置。 |

| voiceFallbackIndication | 指示RRC释放是由IMS语音的EPS回退触发的。 |

  • suspendConfig: 这是决定UE进入RRC_INACTIVE态的关键。如果这条消息中包含suspendConfig，UE就会进入INACTIVE态；如果没有，则进入IDLE态。

    • fullI-RNTI, shortI-RNTI: gNB为UE分配的非激活状态下的身份标识。

    • ran-PagingCycle: INACTIVE态下的寻呼周期。

    • ran-NotificationAreaInfo: 定义了UE在INACTIVE态下可以自由移动的区域（RAN Notification Area, RNA）。只要UE在这个区域内移动，就无需通知网络；一旦移出，则需要发起RNA Update（一种特殊的RRCResume流程）来更新位置。

    • t380: RNAU（RAN-based Notification Area Update）周期性更新定时器。

  • redirectedCarrierInfo: 在释放UE的同时，指示它去另一个频率或RAT。常用于负载均衡，例如，网络可以将小明从一个拥挤的5G频段释放，并指示他去驻留到一个较为空闲的4G频段。

  • deprioritisationReq: 比重定向更“强硬”的负载均衡手段。它指示UE在deprioritisationTimer指定的时间内（如15分钟），降低当前频率或整个NR RAT的重选优先级。这意味着，除非别无选择，否则UE在这段时间内会尽量避免返回当前频率/RAT。

在小明通话结束的场景中，gNB为了让他手机省电，发送了RRCRelease消息，其中包含了suspendConfig。小明的手机收到后，保存了其中的I-RNTI、RNA等信息，然后关闭了大部分收发信机电路，进入了低功耗的RRC_INACTIVE状态，等待下一次被寻呼或主动发起业务。

FAQ环节

Q1：UE在RRC_IDLE和RRC_INACTIVE状态下都会被寻呼，那么网络在发送Paging消息时，如何区分UE处于哪种状态？

A1：关键在于Paging消息中使用的UE身份标识（ue-Identity）。

  • 如果UE处于**RRC_IDLE态，其位置由核心网（AMF）以跟踪区（Tracking Area）的粒度管理。寻呼由AMF发起，使用的UE标识是核心网分配的ng-5G-S-TMSI**。

  • 如果UE处于**RRC_INACTIVE态，其上下文保留在gNB，位置由gNB以RAN通知区（RNA）的粒度管理。寻呼由gNB发起，使用的UE标识是gNB在RRCRelease时分配的fullI-RNTI**。

通过检查PagingRecord中的UE ID类型，就可以明确寻呼的是IDLE态UE还是INACTIVE态UE。

Q2：MobilityFromNRCommand中的targetRAT-MessageContainer既然是目标RAT的消息，NR gNB是否需要理解其内容？

A2：不需要。NR gNB在这里扮演的是一个“邮差”的角色。它从核心网获取这个OCTET STRING（字节串），然后原封不动地放进MobilityFromNRCommand消息中发给UE。gNB完全不关心也不解析这个容器里的具体内容。消息的解析工作完全由UE的RRC协议栈来完成，UE的RRC层会识别出这是一个异RAT切换指令，然后调用其对应RAT（如LTE）的协议栈模块来解析targetRAT-MessageContainer中的RRCConnectionReconfiguration消息。

Q3：RRCRelease消息中的“重定向”（redirectedCarrierInfo）和“去优先级”（deprioritisationReq）有什么应用上的区别？

A3：两者都是网络控制UE驻留行为的工具，但控制的“强度”和“目的”不同：

  • 重定向 (Redirection): 是一种引导性的、一次性的行为。网络在释放UE时，“建议”它去某个特定的频率。UE会立即尝试在该频率上进行小区选择。如果成功，任务就完成了；如果失败，UE还是会按照常规的小区重选规则去寻找其他小区。常用于即时的负载均衡。

  • 去优先级 (Deprioritisation): 是一种限制性的、持续一段时间的行为。网络给UE施加一个“惩罚”，在指定的时间内（如15分钟），让UE“不爱”待在当前频率或RAT。这是一种更强力的、中长期的负载控制或网络策略执行手段，可以有效地将用户“驱离”某个拥塞的频段。

Q4：进入RRC_INACTIVE状态相比进入RRC_IDLE状态，对UE和网络各有什么好处？

A4：RRC_INACTIVE是5G引入的重要特性，旨在平衡信令开销、功耗和接入时延，相比RRC_IDLE有显著优势：

  • 对UE的好处: 接入时延极低。由于AS上下文（如安全密钥、承载配置）被保留，UE可以快速恢复到连接态（RRCResume），时延远小于从IDLE态发起的完整RRC连接建立。这对于需要频繁发送小包数据的物联网业务尤其有利。

  • 对网络的好处: 减少了核心网的信令负荷。在INACTIVE态，UE的移动性（RNA内的移动）由RAN（gNB）自己管理，无需频繁地向核心网（AMF）上报位置更新。只有当UE移出RNA或需要恢复连接时，才与核心网交互。

  • 代价: gNB需要消耗一定的内存资源来存储INACTIVE态UE的上下文。因此，网络需要根据UE的数量、业务模型和硬件能力来决定是否以及为多少UE启用RRC_INACTIVE态。

Q5：如果UE处于RRC_INACTIVE状态，并且移动到了一个新的gNB覆盖下（但仍在上一个gNB定义的RNA内），此时有电话呼入，寻呼流程是怎样的？

A5：这是一个典型的RRC_INACTIVE移动性场景。流程如下：

  1. 核心网（AMF）将寻呼请求发给上次为UE提供服务的gNB（我们称之为gNB-A），因为UE的上下文仍然保存在gNB-A。

  2. gNB-A知道该UE的RNA范围，它会在该RNA内的所有小区（包括由其他gNB，如gNB-B，管理的小区）上广播这条寻呼消息。gNB之间通过Xn接口协调这个跨基站的寻呼。

  3. UE在新gNB（gNB-B）的覆盖下，监听并收到了这条包含其I-RNTI的寻呼消息。

  4. UE会在gNB-B的小区上发起RRCResumeRequest。

  5. gNB-B发现自己没有该UE的上下文，于是通过Xn接口向gNB-A请求UE上下文。

  6. gNB-A将UE上下文传输给gNB-B，并释放自己保存的上下文。

  7. gNB-B使用获取到的上下文，向UE回应RRCResume消息，完成连接恢复。UE现在与gNB-B建立了连接。这个过程对核心网是透明的。

关系图谱