51学通信

深度解析 3GPP TS 38.523-3：7.1 Common Aspects (通用测试方法：构建自动化测试的基石)

21分钟阅读

深度解析 3GPP TS 38.523-3：7.1 Common Aspects (通用测试方法：构建自动化测试的基石)

本文技术原理深度参考了3GPP TS 38.523-3 V18.2.0 (2025-03) Release 18规范中，关于“7.1 Common aspects”的核心章节，旨在为读者详细拆解5G UE协议一致性测试中通用的方法论与设计原则，揭示自动化测试脚本背后的“标准作业程序”（SOP）。

前言：“Explorer-Sat”的“导演手册”

在之前的篇章中，我们跟随测试工程师李工，已经熟悉了5G终端测试的“场地”（第5章 测试模型）和“沟通语言”（第6章 系统接口）。他现在拥有了为“Explorer-Sat”勘探终端搭建各种虚拟网络环境的能力，并且掌握了通过ASP（抽象系统原语）向这些虚拟环境发送精确指令的方法。

然而，仅仅拥有场地和语言是远远不够的。要导演出一出精彩的、符合规范的“通信大戏”，李工还需要一本详尽的“导演手册”。这本手册需要告诉他：

  • 灯光（物理层资源）应该如何布置和调度？
  • 演员（UE和SS）在舞台上应该如何走位（信令交互）？
  • 整场演出的时间节奏应该如何精确控制？

3GPP TS 38.523-3的第七章“Test methods and design considerations”正是这样一本权威的“导演手册”。它不再仅仅是描述静态的环境，而是深入到动态的交互流程和设计细节中，为TTCN-3测试脚本的编写提供了最具体、最直接的指导。

由于第七章内容极其庞大，涵盖了从通用原则到特定技术（EN-DC, SA, Sidelink等）的方方面面。根据我们的拆解计划，本篇文章将聚焦于其第一节——7.1 Common Aspects（通用方面）。这一节是整本“导演手册”的总纲，它所定义的物理层调度、系统信息处理、时序管理等原则，是所有后续测试场景（无论是SA还是NSA）都必须共同遵守的基石。

现在，让我们跟随李工，翻开这本手册的第一页，学习如何成为一名合格的5G自动化测试“导演”。

1. 舞台的灯光艺术：7.1.2 Physical layer aspects (物理层方面)

物理层是所有通信的基础，如同舞台上的灯光系统。如何精确地控制每一束“光”（无线资源），照亮正确的“演员”（UE），是所有测试的起点。7.1.2节详细规定了测试系统（SS）在物理层调度方面的行为准则。

1.1 对白的时间与地点：7.1.2.1 Search spaces and DCI (搜索空间与下行控制信息)

DCI（Downlink Control Information）是基站用来指挥UE的“指令条”，它告诉UE应该去哪里接收下行数据（PDSCH），或者在哪里发送上行数据（PUSCH）。而UE并不是时刻都在盲目地监听整个频段来寻找DCI，它只会在预先约定好的、特定的时间和频率区域进行监听，这些区域就叫做“搜索空间”（Search Space）。

  • 配置搜索空间：为“指令”划定舞台 李工的第一个导演任务，就是为“Explorer-Sat”划定接收指令的“舞台”。TTCN-3脚本通过ASP，可以配置一个或多个搜索空间。对于每一个搜索空间，都需要定义一系列关键参数。规范在PDCCH monitoring periodicity, PDCCH monitoring offset, PDCCH monitoring pattern等表格中对此进行了详细定义。

    Table: PDCCH monitoring periodicity

    Comment/descriptionslot periodicity in time domain
    ASN.1 parameterSearchSpace.monitoringSlotPeriodicityAndOffset
    Core spec referenceTS 38.213 clause 10.1

    Table: PDCCH monitoring offset

    Comment/descriptionslot offset
    ASN.1 parameterSearchSpace.monitoringSlotPeriodicityAndOffset
    Core spec referenceTS 38.213 clause 10.1

    Table: PDCCH monitoring pattern

    Comment/descriptionfirst symbol(s) of the control resource set within a slot for PDCCH monitoring…
    ASN.1 parameterSearchSpace.monitoringSymbolsWithinSlot
    Core spec referenceTS 38.213 clause 10.1
    • 场景故事：约定接头暗号 李工需要配置一个UE专用的搜索空间。他通过ASP设置了monitoringSlotPeriodicityAndOffset：周期为sl10（每10个slot），偏移为2。这意味着，“Explorer-Sat”只需要在SFN x的第2, 12, 22, 32…个slot醒来检查指令，其他时间则可以“打盹”省电（DRX）。他还设置了monitoringSymbolsWithinSlot，告诉UE只需要在这些slot的前两个OFDM符号进行监听。这个精确的约定，就是UE与网络之间的“接头暗号”。

  • PDCCH候选与优先级：当“导演们”发生冲突 在一个复杂的场景中，可能会有多个“导演”（调度逻辑）想在同一个时刻给UE下发指令。例如，系统信息广播的调度和用户数据传输的调度可能发生在同一个slot。如果它们不幸选中了相同的物理资源（CCE，控制信道单元），就会发生冲突。

    The SS shall consider search space priorities as configured by TTCN to find appropriate PDCCH candidates for scheduling of DCI formats in case of: a) Overlapping search spaces: … b) Within a search space if different search space types are mapped to the same search space configuration.

    为此，规范引入了搜索空间优先级的概念。TTCN脚本在配置每个搜索空间时，可以为其赋予一个优先级（P）。当SS的调度器发现冲突时，它会遵循以下规则：

    1. 保留高优先级搜索空间的PDCCH候选。
    2. 为低优先级搜索空间在本轮调度中选择下一个可用的候选位置。

    这确保了关键的信令（如寻呼、系统信息）总能优先于普通数据被调度出去。

当UE成功解码DCI后，它就知道了下行数据PDSCH的位置。这一节详细定义了SS如何描述这个“位置”。

  • 时域资源分配：数据传输的时间窗口

    For time domain resource allocation, either a default PDSCH time domain allocation … is applied or a table (pdsch-AllocationList) is configured via RRC signalling… This table corresponds to L1 parameter “pdsch-AllocationList” and the entries are referred to by DCI.

    DCI中并不包含PDSCH时域位置的所有细节，而是包含一个索引，指向一个预先通过RRC信令配置给UE的“时域资源分配表”（TDRA-Table）。这个表中的每一行都定义了一个具体的时域组合，包括：

    Table: PDSCH slot offset (K0)

    Comment/descriptionSlot offset of PDSCH transmission based on the corresponding PDCCH transmission (DCI)…
    ASN.1 parameterPDSCH-TimeDomainResourceAllocation.k0

    Table: PDSCH mapping type

    Comment/descriptionPDSCH mapping type A or B
    ASN.1 parameterPDSCH-TimeDomainResourceAllocation.mappingType

    Table: Start and length indicator (SLIV)

    Comment/descriptionThe SLIV specifies the starting symbol (S) and the number of symbols (L) of the PDSCH resource assignment…
    ASN.1 parameterPDSCH-TimeDomainResourceAllocation.startSymbolAndLength
    • K0: PDSCH相对于其调度DCI所在slot的偏移量。
    • Mapping Type: PDSCH的映射类型（Type A或Type B），影响起始符号的定义。
    • SLIV: 一个紧凑的14位字段，同时编码了PDSCH在一个slot内的起始符号（S）和符号长度（L）。

    规范中的“Figure 7.1.2.2.2-1: Example for time domain resource allocation for K0 = 0”和“Figure 7.1.2.2.2-2: Example for time domain resource allocation for K0 > 0”生动地展示了K0的作用。当K0=0时，DCI和它所调度的PDSCH在同一个slot内；当K0>0时，PDSCH则位于DCI之后的第K0个slot。

上行授权与下行调度类似，也是通过DCI（通常是DCI format 0_X）来下发。但其触发机制更为多样，规范将其归纳为四种主要的授权分配类型。

7.1.2.3.1.2 Grant allocation types

  • 场景故事：“Explorer-Sat”的四种“发言”方式 李工需要测试“Explorer-Sat”在不同场景下的上行传输能力，他依次配置了四种授权模式：

    1. 类型1：举手发言 (Uplink grant triggered by SR) “Explorer-Sat”有新的勘探数据要上报，它首先在一个配置好的PUCCH资源上发送一个SR（Scheduling Request），就像学生在课堂上“举手”。SS的MAC层检测到SR后，在10ms内通过PDCCH下发一个一次性的UL Grant，给予其“发言”机会。

    2. 类型2：定时发言 (Periodic uplink grant) “Explorer-Sat”需要周期性地上报心跳和位置信息。李工为其配置了一个周期性的授权，例如，每100个slot，SS都会自动下发一个UL Grant，无论UE是否请求。这保证了关键信息的规律性上报，类似于VoIP业务。

    3. 类型3：点名发言 (Single uplink grant) 这是一种特殊的周期授权，周期次数为1。SS只下发一次UL Grant，用于一次性的数据传输任务。

    4. 类型4：举手后获得定时发言权 (Periodic uplink grant triggered by SR) 这是类型1和类型2的结合。初始状态下没有周期授权。当“Explorer-Sat”第一次“举手”（发送SR）后，SS不仅会给它一个立即的授权，还会激活一个后续的周期性授权。这适用于突发性但又可能持续一段时间的业务。

2. 演出的剧本与时间线：系统信息与时序管理

2.1 系统信息广播：7.1.3 System information

系统信息（MIB和SIB）是UE了解一个小区特性的“说明书”。TTCN-3测试脚本负责提供这份“说明书”的内容，而SS则负责像一个广播电台一样，在正确的时间、以正确的格式将其播出。

TTCN provides the MIB message to the SS as a structured ASN.1 type using a control ASP (NR_SYSTEM_CTRL_REQ). The SS shall:

  • set the systemFrameNumber in the MIB to the 6 MSBs of the current SFN…
  • transmit the encoded MIB message periodically as specified in TS 38.331.

这段描述指出了一个关键的实现细节：TTCN提供的MIB内容中，SFN（系统帧号）字段只是一个“占位符”。SS在实际发送MIB时，必须用当前真实的SFN来替换这个占位符。这保证了UE接收到的系统信息中的时间戳是与网络实时同步的。

2.2 全局时钟：7.1.5 Timing aspects

在多小区测试场景（如切换）中，所有模拟的小区必须有一个统一的时间基准，以保证测试的可重复性。

The SS shall provide one system time common across all RATs and cells being configured in a test case. The timing of each configured cell is specified as an offset to this common system time.

  • SS Master Clock: 测试系统（SS）内部维护一个主时钟。
  • Cell Offsets: 每个模拟的小区（Cell 1, Cell 2…）的定时，都以相对于这个主时钟的一个特定偏移量来定义。这些偏移量在Table 7.1.5.2-1: DL timing parameters of simulated NR cells中被标准化。

Table 7.1.5.2-1: DL timing parameters of simulated NR cells

NR cell IdH-SFN-offset (note 1)SFN-offset for FDD (note 2)SFN-offset for TDD (note 2)Tcell (note 3)Tc-offset (note 4)
NR Cell 100000
NR Cell 20124000
NR Cell 3025725700
………………
  • 场景故事：一次精准的切换测试 李工要测试“Explorer-Sat”从Cell 1切换到Cell 3。通过这张表，他知道Cell 3的帧定时相对于Cell 1有257个SFN的偏移。他可以在TTCN脚本中精确地计算出UE应该在哪个时刻收到来自Cell 3的信号，从而对切换过程中的各种定时器行为进行精确的判决。

3. 其他通用规则的简述

7.1节还包含了一些其他的通用规则，根据我们的解读策略，这里进行简要说明：

  • 7.1.4 Cell(s) handling：多小区环境的管理（如功率变化）原则，遵循LTE规范（TS 36.523-3）的定义。
  • 7.1.6 Test modes：定义了RLC层的测试模式，同样遵循LTE规范的定义，我们将在后续RLC章节的实战中具体应用。
  • 7.1.7 Random Access procedure：明确了默认使用4步随机接入，除非测试用例特别指定2步RACH。
  • 7.1.8 Race conditions：竞争条件的处理，同样遵循LTE规范，确保测试在遇到信令交叉等情况时有确定的行为。

总结：掌握自动化测试的“标准作业程序”

通过对7.1 Common Aspects的深度解读，我们掌握了5G自动化测试的“导演手册”的总纲。它为看似杂乱无章的物理层调度和高层信令交互，建立了一套严谨、可预测的“标准作业程序”（SOP）。

李工现在已经不仅仅是一个测试执行者，他更像是一个“导演”：

  • 他知道如何通过配置搜索空间来为UE搭建接收指令的“舞台”。
  • 他精通DCI这门“导演语言”，知道如何通过TDRA和UL Grant来精确调度UE的下行接收和上行发送。
  • 他掌握了整个“片场”的时间线，能够通过统一的SS时钟和标准化的小区偏移，来编排复杂的多小区协同“演出”。

掌握了这些通用方法论，就如同掌握了拍摄任何类型“电影”（无论是SA、NSA还是Sidelink）的基础技法。在下一篇文章中，我们将把这些通用技法应用到第一个具体的“剧本”中——7.2 EN-DC，看看在NSA双连接的特定场景下，“导演手册”又有哪些特殊的补充说明。

FAQ

Q1：DCI（下行控制信息）和PDSCH（物理下行共享信道）是什么关系？

A1：它们是“指令”和“内容”的关系。DCI是一小段在PDCCH上传输的控制信息，它告诉UE“有一份给你的数据”。而这份数据本身，即PDSCH，则承载在另一个物理信道上。DCI会详细说明这份PDSCH数据在哪里（时频域位置）、有多大（TBS）、应该如何解调（MCS）等。UE必须先成功解码PDCCH上的DCI，才能知道如何去接收对应的PDSCH。

Q2：UL Grant的四种类型在使用场景上有什么典型区别？

A2：

  • Type 1 (SR触发)：适用于突发、非周期性的上行数据，如用户点击发送一条即时消息。
  • Type 2 (周期性)：适用于规律、周期性的上行数据，如VoIP语音包、周期性的心跳上报等。
  • Type 3 (单次)：适用于一次性的、由网络侧触发的上行传输任务。
  • Type 4 (SR触发的周期性)：适用于突发且可能持续一段时间的业务，如开始一次文件上传。先通过SR获取第一次传输机会，后续则自动获得周期资源，无需每次都请求。

Q3：什么是搜索空间（Search Space）？为什么要设置优先级？

A3：搜索空间是UE在时间和频率上监听PDCCH（即DCI指令）的预定义区域。UE无需盲目搜索整个带宽，只需在这些指定的“窗口”进行监听，可以大大节省功耗。设置优先级是为了解决资源冲突。当不同类型、不同重要性的DCI（如寻呼DCI、系统信息DCI、用户数据DCI）需要在同一时间调度时，可能会竞争同一个物理资源。通过为承载它们的搜索空间设置不同优先级，可以确保高优先级的DCI（如寻呼）总能被成功调度，从而保证系统的基本功能不受影响。

Q4：为什么测试系统（SS）在发送MIB时，需要用实时的SFN替换掉TTCN脚本里提供的SFN？

A4：这是为了保证测试环境的时间同步性和真实性。SFN（系统帧号）是网络的时间基准。UE在接入网络时，必须与网络的SFN同步。TTCN-3脚本运行在逻辑时间上，它无法实时获知SS物理硬件的精确SFN。因此，脚本只提供MIB的“内容模板”，而SS在物理层发送的最后一刻，负责将实时的SFN“盖印”到MIB上。这确保了UE接收到的MIB中的时间戳是准确的，其后续的所有定时行为（如寻呼监听、测量报告等）才能与SS的调度节奏保持一致。

Q5：Table 7.1.5.2-1中定义的小区定时偏移在什么测试场景下至关重要？

A5：在所有多小区（multi-cell）场景下都至关重要，最典型的就是切换（Handover）测试。在切换测试中，SS需要同时模拟源小区和目标小区。为了使测试过程可预测、可重复，这两个小区之间的时间关系必须是固定的、标准化的。这张表就提供了标准化的偏移值。测试脚本可以根据这个表格，精确计算出当UE从源小区切换到目标小区时，它应该在哪个具体的时刻（SFN、slot）开始接收目标小区的同步信号和系统信息，从而能够对UE的切换速度和定时行为进行精确的判决。

关系图谱