51学通信

深度解析 3GPP TS 38.523-3：7.3 NR5GC (Part 1 - SA独立组网：开机、驻留与寻呼的测试方法)

22分钟阅读

深度解析 3GPP TS 38.523-3：7.3 NR/5GC (Part 1 - SA独立组网：开机、驻留与寻呼的测试方法)

本文技术原理深度参考了3GPP TS 38.523-3 V18.2.0 (2025-03) Release 18规范中，关于“7.3 NR/5GC”的核心章节，旨在为读者详细拆解在5G SA（独立组网）模式下，UE从开机、获取系统信息到进入空闲态并响应寻呼这一系列 foundational procedures（基础流程）的标准化测试方法。

前言：进入纯粹5G世界，“Explorer-Sat”的生存第一课

在之前，测试工程师李工已经带领他的“Explorer-Sat”勘探终端，成功地在EN-DC（NSA）这个“4G+5G混合动力”的复杂环境中证明了其协议栈的成熟与稳定。现在，测试进入了更激动人心的阶段——NR/5GC，即SA（独立组网）模式。这是5G的“完全体”形态，也是“Explorer-Sat”能否发挥其全部潜能（如支持URLLC、网络切片等）的终极试炼场。

李工将测试场景切换到了一个纯粹的5G世界。在这里，没有了LTE的辅助，“Explorer-Sat”必须像一个初生的婴儿，独立完成认识世界（读取系统信息）、融入集体（网络注册）、保持静默（空闲态）并随时响应召唤（寻呼）的全过程。这个过程中的每一步，都必须精确地遵循3GPP制定的“社会规则”。

第七章的7.3节，正是这本“导演手册”中为SA模式编写的宏大剧本。其内容之丰富、细节之详尽，远超EN-DC章节，因为它从零开始定义了UE在一个独立5G网络中的所有行为准则。由于其篇幅巨大，我们将分多篇文章进行解读。

本篇作为“Part 1”，将聚焦于UE的“生存第一课”：从开机到能够被网络联系到。我们将跟随李工，深入探索7.3节的前半部分，重点关注：

  • 新形态终端的特殊法则：针对RedCap（轻量化5G）和SDT（小数据传输）等新特性，测试方法有何不同？
  • 网络的“欢迎手册”：如何验证UE能正确、高效地读取并理解系统信息？
  • “你找我”的约定：如何测试UE在DRX/eDRX等复杂省电模式下，依然能可靠地响应网络寻呼？

让我们正式开启这场SA世界的生存挑战之旅。

1. 新物种的生存法则：7.3.2 物理层特殊方面

在SA的世界里，并非所有设备都是像“Explorer-Sat”这样的“全能型选手”。为了适应物联网等多样化场景，5G家族引入了新成员——RedCap（Reduced Capability）。同时，为了提升效率，也引入了新的通信范式——SDT（Small Data Transmission）。7.3.2节首先为这些“新物种”和“新行为”定义了测试规则。

1.1 RedCap的“节俭之道” (7.3.2.2)

李工拿到了一款“Explorer-Sat”的衍生型号——一个用于环境监测的低功耗、低成本传感器。它正是典型的RedCap设备。为了省电和降低成本，它的能力被“裁剪”了，例如更窄的带宽、更少的天线，以及一种特殊的FDD工作模式。

  • 更窄的视野：BWP Operation

    When RedCap-specific initial downlink BWP is configured, TTCN configures both the default initial DL BWP and the RedCap-specific initial DL BWP in SS. Each DCI is assigned to either the initial DL BWP or the RedCap-specific initial DL BWP depending on the test case configuration.

    导演的解读：为了让RedCap设备快速接入，网络可以为其配置一个专属的、更窄的初始BWP。测试系统（SS）必须同时模拟出“标准”初始BWP和“RedCap”初始BWP。TTCN脚本在调度时，会明确指定DCI应该发在哪一个BWP上，以验证RedCap设备能否在正确的“小窗”里接收到自己的控制信令。

  • “对讲机”模式：Half-Duplex FDD operation 为了节省成本，RedCap设备可以不支持FDD全双工（同时收发），而是采用HD-FDD（半双工）模式，即“收的时候不能发，发的时候不能收”。

    A RedCap UE in Half-Duplex FDD mode (HD-FDD) has limitations in receiving an UL symbol following a DL symbol, hence a blank slot is needed in between, defined as gap T_Proc,2. … When TimingInfo is “Now”, the SS shall restrict UL/DL operations as per Table 7.3.2.2.2-1 below:

    导演的解读：这是HD-FDD测试的核心。当SS要调度一次下行传输，并紧接着期望UE进行一次上行传输时，它不能像全双工那样无缝衔接。SS的调度器必须遵循Table 7.3.2.2.2-1的规定，在下行传输和上行授权之间留出足够的处理“间隙”（Gap）。

    Table 7.3.2.2.2-1: Data scheduling for FR1: HD-FDD, SCS=15kHz (non-explicitly scheduled)

    Subframe0123456789
    DLDCI P-RNTI / PDCCH UL grant#1 / SSBsDCI P-RNTI / SIB1DCI P-RNTI / SIB1 / PDSCH#1PDCCH UL grant#2 / SISIPDSCH#2
    ULGap T_Proc,2RA occasion / PUSCH#1 / HARQ of PDSCH#2Gap T_Proc,2PUSCH#2 / HARQ of PDSCH#1
    • 场景故事：李工的脚本控制SS在subframe 2下发了一个PDSCH给RedCap传感器。根据此表，对应的上行HARQ-ACK反馈应该在subframe 5的PUSCH上传输。在全双工模式下，SS可以在subframe 2或3就下发这个PUSCH的UL Grant。但在HD-FDD模式下，为了留出T_Proc,2的“思考时间”，SS必须遵循表中subframe 3的“Gap”，将UL Grant的调度推迟到更晚的时间点。TTCN脚本会精确控制SS的这一调度行为，并验证RedCap设备是否在subframe 5正确地发送了ACK。

1.2 轻量级通信：小数据传输 (SDT - 7.3.2.3)

常规的数据传输需要先建立RRC连接，过程繁琐，对于只需发送几百字节数据的物联网传感器来说是一种巨大的浪费。SDT允许UE在RRC_INACTIVE或IDLE状态下，“捎带”着用户数据完成接入过程，实现“轻量级”的通信。

  • RA-SDT：在“敲门”时递上“名片” (7.3.2.3.1)

    For SDT procedure over RACH, SDT DTCH data is expected together with CCCH/RRCResumeRequest:

    • in Msg3 when 4-step RA type is configured,
    • or in MSGA when 2-step RA type is configured.

    导演的解读：RA-SDT（基于随机接入的SDT）的测试方法是：TTCN先将UE配置到RRC_INACTIVE状态。然后，当UE发起恢复流程时，SS需要验证UE发送的Msg3（或2步RACH的MSGA）中，是否不仅包含了RRCResumeRequest信令，还同时复用了来自DTCH（数据信道）的用户数据。

  • CG-SDT：使用“VIP专属通道” (7.3.2.3.2)

    For SDT procedure over CG resources, TTCN configures the initial UL and DL BWP and DCI in the SS according to parameters provided to UE in SDT-MAC-PHY-CG-Config-r17.

    导演的解读：CG-SDT（基于预配置授权的SDT）则更为高效。网络可以提前为UE配置好一组专用的上行资源。当有小数据要发送时，UE可以直接使用这些资源，无需进行随机接入的竞争。测试时，TTCN脚本会模拟这一配置过程，然后验证UE是否在指定的CG资源上，正确地发送了其小数据包。

2. 阅读“城市公告”：7.3.3 系统信息 (System Information)

“Explorer-Sat”开机后，第一件事就是寻找并读取当前小区的“公告栏”——系统信息，以了解网络的基本配置。

2.1 确定性的广播时间表 (7.3.3.2 Scheduling information)

为了让测试过程完全可预测，规范为系统信息的广播制定了一套精确到slot的时间表。

SIB1 is broadcasted in slot#1 in frames with even SFN in cells configured with SSB#0 and in slot#2 in frames with even SFN in cells configured with SSB#1.

Table 7.3.3.2-2: MIB, SIB1 and SI scheduling for FR1: FDD and TDD, SCS=15kHz

SFNSubframe 0Subframe 1Subframe 2…Subframe 6…
0MIBSIB1 SSB#0SIB1 SSB#1…SI1 SSB#0…
2MIBSIB1 SSB#0SIB1 SSB#1…SI1 SSB#0…
…………………

导演的解读：这张表就是SS广播SI的“节目单”。它明确规定了在哪个系统帧（SFN）的哪个子帧（subframe），应该广播哪条系统消息（MIB, SIB1, 或其他SI）。例如，对于一个使用SSB#0的小区，SIB1总是在偶数SFN的subframe 1中广播。这种确定性使得李工可以编写出非常精准的测试脚本：在启动测试后，脚本可以精确地等待到SFN=2, subframe=1这个时刻，然后去验证“Explorer-Sat”是否已经成功解码SIB1并存储了相关信息。

2.2 按需索取信息：On-demand SI (7.3.3.4)

有些特殊的系统信息（如GNSS辅助数据）不常变化，网络不会周期性广播以节省空口资源。当UE需要时，它必须主动“举手”索取。

In case PRACH preamble (RA Msg1) is used for indication of requested other SI:

  • TTCN configures SS with the SI-RequestConfig as provided to UE in SIB1 and SS shall monitor these PRACH resources.
  • TTCN reconfigures SS to stop broadcasting a specific SI … and reconfigures SS to restart broadcasting the SI with activation time ‘Now’ (after the reception of PRACH preamble in TTCN).

导演的解读：这个测试流程非常巧妙：

  1. 准备：TTCN首先配置SS，让它停止广播某个特定的SI（例如SIB8）。
  2. 触发：UE发现自己需要SIB8，于是它会在一个预先由SIB1告知的、专门用于SI请求的PRACH资源上，发送一个特定的前导码。
  3. 响应与验证：SS的物理层检测到这个前导码后，立刻上报_IND给TTCN。TTCN收到指示，明白UE正在请求SIB8。于是，它立即通过_REQ命令，让SS重新开始广播SIB8。
  4. 最终确认：TTCN在稍后的时间点，通过其他方式（如下发一个需要SIB8信息才能完成的指令），验证UE是否已经成功获取了这份按需广播的系统信息。

3. 在沉睡中保持警惕：7.3.4 寻呼与短消息

当“Explorer-Sat”完成网络注册后，为了省电，它会进入DRX（非连续接收）的“浅睡眠”状态。网络需要通过“寻呼”（Paging）来将它唤醒。

3.1 DRX、eDRX与PEI：省电的三重境界

  • DRX (7.3.4.2)：常规的“睡眠-唤醒”周期。UE只在被称为“寻呼时机”（PO, Paging Occasion）的特定时刻醒来监听寻呼。PO的计算是确定的，依赖于UE的ID。

  • eDRX (extended DRX, 7.3.4.3)：超长“冬眠”周期。适用于数小时甚至数天才需要通信一次的物联网设备。UE只在一个被称为“寻呼时间窗口”（PTW, Paging Time Window）的较短时间内，按照常规DRX周期监听寻呼，而在PTW之外的漫长时间里则可以深度睡眠。

    The Paging Hyperframe (PH) refers to the hyper SFN (H-SFN) in which the UE starts monitoring POs during a Paging Time Window (PTW).

  • PEI (Paging Early Indication, 7.3.4.4)：寻呼的“预告片”。在正式的PO之前，网络可以先发送一个更短、更易检测的PEI信号。UE如果检测到PEI，就知道“可能有我的寻呼”，于是才会在接下来的PO保持唤醒；如果没检测到PEI，则可以立即回去继续“睡觉”，连PO都无需监听，进一步节省了电量。

3.2 寻呼测试的通用方法

SS is triggered by TTCN to send the Paging message or a Short Message indication at a calculated Paging Occasion (PO) provided in the activation time…

导演的解读：所有寻呼测试都遵循一个核心逻辑：

  1. 计算PO：TTCN脚本根据UE的ID和RRC配置的DRX/eDRX/PEI参数，精确地计算出下一个PO（或PEI-O）应该出现在哪个SFN、哪个slot。
  2. 定时触发：TTCN使用这个计算出的精确时间作为TimingInfo，通过ASP请求，命令SS在且仅在那个时刻发送Paging DCI和PDSCH。
  3. 验证响应：脚本随后开始监听来自SS的_IND指示。如果UE被成功唤醒，它会发起随机接入来响应寻呼。TTCN只要在预期的时间窗口内收到了SS上报的PRACH _IND，就证明寻呼测试成功。

总结：打牢SA生存之基

通过对7.3章节前半部分的深度剖析，我们系统地学习了UE在SA独立组网模式下，从开机到能够稳定驻留并响应网络召唤所需遵循的一系列标准测试方法。这本“导演手册”的总纲部分，为我们展示了3GPP规范的严谨与精妙：

  • 它为RedCap、SDT等新技术新范式，定义了清晰、可执行的验证路径。
  • 它通过确定性的广播时间表和请求-响应机制，将系统信息获取这一基础行为，转化为了可精确度量的测试流程。
  • 它通过对DRX/eDRX/PEI背后复杂算法的精确实现，确保了对UE省电能力和网络可达性的双重考验。

李工通过这些测试，确保了“Explorer-Sat”即使在最基础的生存环节，其一举一动都如同教科书般标准。现在，“Explorer-Sat”已经是一个合格的、能在SA世界中“安营扎寨”的成员了。接下来的挑战，将是它在“联网”状态下的各种复杂交互。在下一篇文章中，我们将进入7.3.5 RRC Connection Control，探索SA模式下连接控制、切换、重建立等核心“动作大戏”的拍摄手法。

FAQ

Q1：RedCap UE的半双工FDD（HD-FDD）模式，对测试方法提出了什么特殊要求？

A1：特殊要求在于测试系统（SS）的调度行为必须受限。由于HD-FDD设备无法同时收发，SS在调度一次下行传输后，不能立即期望UE进行上行传输（如HARQ-ACK反馈）。SS的调度器必须在下行传输的结束和对应的上行传输的开始之间，留出一个被称为T_proc,2的保护间隔（Gap）。在自动化测试中，TTCN脚本必须精确计算和控制SS的调度时序，确保这个Gap被严格遵守，以正确验证UE在HD-FDD模式下的行为。

Q2：什么是小数据传输（SDT）？测试RA-SDT和CG-SDT的关注点有何不同？

A2：SDT是一种允许UE在RRC_INACTIVE或IDLE状态下，无需建立完整RRC连接即可发送少量用户数据的技术。

  • RA-SDT（基于随机接入）的测试关注点是信令与数据的复用。测试需要验证UE是否能将用户数据（DTCH）与RRC恢复/建立请求（CCCH）正确地复用在同一个上行消息（Msg3或MSGA）中发送。
  • CG-SDT（基于预配置授权）的测试关注点是资源的正确使用。测试需要验证UE是否能在网络预先为其分配的、专用的上行资源（Configured Grant）上，正确地发送其用户数据。

Q3：为什么3GPP要在测试规范中定义一个如此精确的系统信息（SI）广播时间表？

A3：为了保证测试的可重复性和确定性。如果SI的广播是随机或由SS实现决定的，那么TTCN脚本就无法预测UE在何时能获取到SI。这会导致测试的时序变得不确定，难以编写稳定的、有精确时序要求的测试用例（例如，测试UE从开机到完成SIB1解码的总时长）。一个固定的、标准化的广播时间表，为所有测试提供了一个统一的时间基准，使得测试流程和判决都变得精确可控。

Q4：eDRX和常规DRX在寻呼测试方法上的主要区别是什么？

A4：主要区别在于寻呼时机（PO）的计算和监听窗口。

  • DRX：UE在每一个DRX周期都会醒来监听一个或多个PO。测试时，TTCN只需计算下一个DRX周期内的PO即可。
  • eDRX：UE只在一个被称为“寻呼时间窗口”（PTW）的较短时间内，像常规DRX一样监听PO。在PTW之外的超长eDRX周期中，UE处于深度睡眠，不监听任何寻呼。因此，eDRX的测试方法更复杂，TTCN不仅要计算出PO在slot内的位置，还必须首先计算出正确的PTW在哪一个“超系统帧”（H-SFN）内开始，然后才能在该窗口内触发寻呼。

Q5：什么是寻呼提前指示（PEI）？如何测试它？

A5：PEI是在正式的寻呼时机（PO）之前发送的一个简短的物理层信号，用于“预告”即将到来的寻呼。UE可以只监听PEI，如果没检测到，就可以立即返回睡眠，无需再等待和监听完整的PO，从而进一步省电。测试PEI的方法是：

  1. TTCN计算出PEI的时机（PEI-O）和PO。
  2. TTCN触发SS在PEI-O发送PEI信号，并在PO发送正式的Paging信号。
  3. 验证UE的行为。例如，如果PEI指示该寻呼不属于此UE，测试需要验证UE在PO时刻没有发起任何响应。如果PEI指示有寻呼，则验证UE在PO后会正确响应。

关系图谱