3GPP RAN TSG#102会议R19项目-32 Discussion on Rel19 duplex

New WID: Discussion on Rel19 duplex 主体提案编号：RP-232901

一、文档摘要-3GPP TSG RAN 会议 #102: Rel-19 双工增强功能范围（AI生成）

讨论了 3GPP TSG RAN 第 102 次会议中关于 Rel-19 (第 19 版本) 双工增强功能的范围。主要观点和论据如下：

动态 SBFD:

• 本文档重点介绍了 TR38.858 技术规范对动态 SBFD 的结论。它讨论了动态 SBFD 的优缺点，包括其对基站实现复杂性、资源损耗、基站间 CLI、调度复杂性以及用户设备实现复杂性的影响。文档还提供了针对不同场景的评估结果，并表明动态 SBFD 的性能提升仅限于特定流量模式和 TDD 符号类型。

• 提案 1：文档提出将动态 SBFD 排除在 Rel-19 双工增强功能的范围之外，理由是缺乏充分的理由且实际部署场景有限。

RRC_Connected vs. RRC_Idle/Inactive:

• 文档讨论了 SBFD 是否仅应支持处于 RRC_Connected 状态的 UE，还是应该与 UE 的 RRC 状态无关。它对支持 RRC_Idle/Inactive 状态下 SBFD 符号中的随机访问的益处提出了质疑，并建议仅为处于 RRC_Connected 状态的 UE 实现半静态 SBFD。

• 提案 2：文档建议 Rel-19 双工操作不适用于 RRC_Idle/Inactive 状态的 UE，RAN1 会议将决定是否支持处于 RRC_Connected 状态的 UE 在 SBFD 符号中进行 PRACH 以及配置方法。

CLI 处理:

• 文档讨论了“SBFD 操作驱动 CLI 增强”这句话的解释，并建议 Rel-19 双工的 WID 应反映支持基站到基站共信道 CLI 处理方案和用户到用户共信道 CLI 处理方案的目标。

• 提案 3：文档提出了 Rel-19 双工 WID 的具体目标，包括向用户设备指示 SBFD 子频带、SBFD 符号中的传输和接收行为，以及支持 CLI 处理。

总结

该文档强调了关于 Rel-19 双工增强功能范围的观察和建议，包括排除动态 SBFD、将 SBFD 操作限制为 RRC_Connected 状态以及 Rel-19 双工 WID 的目标。

二、讨论内容学习

2.1 Dynamic SBFD

Rel-18 双工 SI 的 TR38.858 为动态 SBFD 得出以下结论：

（1）与半静态SBFD相比，动态SBFD可以更好地根据上下行流量负载适应上下行资源需求。

（2）动态SBFD可能会增加gNB实现的复杂性，因为涉及到动态天线/面板切换以及滤波器/射频调谐，可能会因过渡时间而导致资源损失，可能会增加gNB之间的CLI，可能会增加调度复杂性，并且可能会在半静态SBFD的基础上对规范产生额外的影响。

（3）如果UE支持动态SBFD，则可能会增加UE的实现复杂性，并且动态SBFD可能会导致增加的UE对UE的CLI。

在上述结论中，RAN1没有就动态SBFD的性能优势达成共识。实际上，在RAN1的研究中观察到以下评估结果：

• 对于室内场景（FR1）时隙配置{XXXXU}，在大数据包情况下，基于2个来源的结果显示，动态SBFD选项3在低负载水平下优于半静态SBFD。

• 对于室内场景（FR1）时隙配置{XXXXX}，在大数据包情况下，基于2个来源的结果显示，动态SBFD选项3优于半静态SBFD。

• 对于其他评估情况，来自多个来源的结果存在冲突。

  其中，动态SBFD选项3指的是由TDD-UL-DL-ConfigCommon配置的柔性符号上的SBFD符号，可以在三种符号状态之间动态切换：{带有UL子频段的SBFD符号，传统DL符号，传统UL符号}。

基于上述观察，我们可以得出以下关于动态 SBFD 的几点提示：

• 性能提升有限： 动态 SBFD 的性能提升仅限于特定流量模式 (例如大数据包) 和特定 TDD 符号类型 (例如可动态地在 DL 和 UL 之间切换的 TDD 灵活符号) 的组合。这种限制制约了动态 TDD 收益的实现可行性。例如，众所周知，TDD 灵活符号迄今为止并不是一个流行的部署选择，这意味着市场上大多数部署场景都无法观察到动态 TDD 的收益。

• 收益来源不明确： 评估动态 SBFD 收益时，假设符号可以在三种状态之间切换：{SBFD 符号、全 DL 符号、全 UL 符号}。然而，自 Rel-15 以来，动态 TDD 已经支持全 DL 符号和全 UL 符号之间的切换。因此，不清楚报告的优于半静态 SBFD 的性能提升有多少来自纯动态 SBFD，又有多少来自动态 TDD 本身。此外，由于 RAN1 尚未决定是否允许用户设备在配置的灵活符号上超出配置的上行链路子频带进行传输，因此动态 SBFD 可能仅通过仅在两种符号状态之间动态切换来构建：{SBFD 符号、全 DL 符号}。

意见-1：TR38.858 没有充分说明在 WI 中支持动态 SBFD 的理由。

 动态 SBFD 相对于半静态 SBFD 的评估增益取决于实际部署中可能无法满足的条件（如配置的灵活符号）。

 在 SI 阶段显示的动态 SBFD 相对于半静态 SBFD 的评估增益可能是由于动态 SBFD 以外的某些技术。

与动态 SBFD 有关的另一个重要说明是："支持动态 SBFD "和 "支持动态 SBFD 指示 "是两个不同的概念。前者是后者的必要条件，但不是充分条件。TR38.858 记录了以下 RAN1 协议：

如果支持动态 SBFD，可以考虑以下选项：

注意 1： 动态 SBFD 在性能和复杂性方面是否有益处是一个单独的讨论话题。

注意 2： 对于选项 1，引入灵活子频带类型以实现超出半静态配置的 SBFD 下行链路子频带的接收以及/或者超出半静态配置的 SBFD 上行链路子频带的传输的可能性仍然存在。

注意 3： 上述选项均不意味着上下行链路子频带大小会动态变化。

实现动态 SBFD 的选项：

• 选项 1：调度 DCI 消息

• 通过调度 DCI 消息来实现动态 SBFD，该消息用于调度超出半静态配置的 SBFD 下行链路子频带的接收和/或超出半静态配置的 SBFD 上行链路子频带的传输。

• 例如，基站可以发送特定的 DCI 消息告诉用户设备在即将到来的符号中接收来自超出 SBFD 配置的下行链路信号，或者发送 DCI 消息指示用户设备在下个符号中使用超出 SBFD 配置的上行链路子频带进行传输。

• 选项 2：非调度 DCI 消息

• 通过非调度的 DCI 消息来实现动态 SBFD，该消息指示符号是 SBFD 符号还是非 SBFD 符号。

• 这个选项与选项 1 的区别在于，DCI 消息本身不携带具体的调度指令，而是仅告诉用户设备该符号的类型。用户设备需要根据其他信令或者更高层的协议来决定如何处理该符号。

• 选项 3：MAC 控制元素 (MAC-CE)

• 通过 MAC 控制元素 (MAC-CE) 来实现动态 SBFD，该控制元素指示符号是 SBFD 符号还是非 SBFD 符号。

• MAC-CE 承载着控制信令，可以用于指示即将到来的符号类型。

在上述协议中，方案 2 中使用的非调度 DCI 和方案 3 中使用的 MAC-CE 可归类为动态 SBFD 的指示；但是，方案 1 中使用的调度 DCI 按规范只指示 DL/UL 调度。

意见-2：根据 TR38.858，支持动态 SBFD 不一定意味着支持专门用于动态 SBFD 的动态指示。

建议 1：Rel-19 双工范围不包括动态 SBFD。

2.2 RRC_Connected 与 RRC_Idle/非活动状态

半静态SBFD显然是Rel-19双工WI的一部分。其中一个关键问题是是否从UE的角度支持RRC_Connected状态下的SBFD，还是无论RRC状态如何都支持。在整个Rel-18 SI过程中，UE在RRC_Connected状态下的SBFD操作是关注的重点，但对于RRC_IDLE/Inactive状态几乎没有进行过多的处理。对于后一种情况，TR38.858规定了如下内容：

• 如果允许SBFD-aware UE在SBFD符号上进行随机接入，有可能减少随机接入延迟，降低PRACH碰撞概率和/或改善PRACH和Msg3的覆盖范围。这些方面在RAN1中尚未进行充分评估。

• 在SBFD符号中UL子频段中的PRACH和Msg3传输可能导致UE之间的CLI。系统性能影响在RAN1中未进行评估。

• 预计规范的影响是允许在TDD-UL-DL-ConfigCommon中将符号配置为DL的情况下，至少允许在SBFD符号上进行PRACH和Msg3的随机接入。

根据技术规范 (TR) 中措辞温和的“可能潜在”的说法，我们认为支持在 SBFD 符号中进行随机访问的益处尚不清楚或缺乏足够的理由。

潜在的负面影响：

• 减少随机访问延迟和 PRACH 碰撞概率取决于分配给 SBFD 符号的 PRACH 资源量，以及 PRACH 尝试能否分别来自 SBFD 符号和非 SBFD 符号（即传统 PRACH 尝试）。

• 为了避免对下行链路性能产生重大负面影响，DL 符号中的上行链路子频带不应该过大。这会导致上行链路子频带中 PRACH 与其他上行链路信道/信号之间存在资源竞争。评估 PRACH 性能（即延迟和碰撞概率）时，不应独立于其他上行链路信道/信号进行评估。

• 分配 PRACH 到 SBFD 符号可能会限制覆盖范围的改善，因为由此产生的用户间同信道干扰 (UE-to-UE CLI) 可能反过来限制 PRACH 尝试的功率提升。目前为止，RAN1 没有研究和结论表明用户设备可以在 SBFD 符号中将 PRACH 功率提高到与非 SBFD 符号中一样高，以实现与非 SBFD 符号相同的覆盖范围。

基於以上分析，我们提出以下建议：

• 提议 2：仅在 RRC_Connected 状态下为用户设备实施 Rel-19 半静态 SBFD。换句话说，Rel-19 双工工作指示 (WI) 中的 SBFD 操作不适用于处于 RRC_Idle/非活动状态的用户设备。

RAN1 接下来需决定的问题：

• RAN1 需要决定是否支持处于 RRC_Connected 状态的用户设备在 SBFD 符号中进行 PRACH。

• RAN1 需要决定是使用用户设备专用 RRC 信令还是 SIB 信令来配置 SBFD。

2.3 CLI handling

技术规范草案 [3] 中提到“SBFD 操作驱动了 CLI 增强”，这句话可以用多种方式解释，例如：

• 解释 1：根据规范设计，CLI 增强方案针对 SBFD 操作进行。换句话说，SBFD 操作本身并不包含额外的 CLI 增强功能，而是规范要求基站具备处理 SBFD 场景下同信道干扰的能力。

• 解释 2：CLI 增强是 SBFD 操作的内置部分，或者 SBFD 操作直接支持 CLI 增强操作。这是基于运行时程序的理解。换句话说，SBFD 操作的引入可能会使得现有的 CLI 处理机制需要增强才能满足需求。

我们认为，解释 1 从工作指示 (WID) 的角度来看就足够了。WID 不需要描述具体的运行时程序细节，而只需要强调需要支持哪些功能。

基于以上讨论以及技术规范草案 [1] 中的论述，我们建议在 WID 中反映以下内容，并突出显示与草案 [3] 中潜在目标的区别：

提案 3：Rel-19 双工工作指示 (WID) 反映以下目标：

• (保持原有目标) 指示用户设备 SBFD 子频带的时域和频域位置

• (保持原有目标) 用户设备在 SBFD 符号和/或与 SBFD 操作相关的非 SBFD 符号中的传输和接收行为和流程

• (新增目标) 支持基站到基站 (gNB-to-gNB) 共信道 CLI 处理方案

• (新增目标) 支持用户到用户 (UE-to-UE) 共信道 CLI 处理方案

三、Rel-19 双工增强功能工作指示 (WID) 总结

观察 1：关于动态 SBFD

• TR38.858 技术规范中没有足够理由支持动态 SBFD 纳入工作指示 (WI)。

• 评估表明动态 SBFD 相比于半静态 SBFD 的性能提升取决于一些实际部署中可能无法满足的条件 (例如配置的灵活符号)。

• 技术规范侧的评估结果显示动态 SBFD 相比于半静态 SBFD 的性能提升可能还归功于除动态 SBFD 以外的其他技术。

• TR38.858 指出，支持动态 SBFD 并不一定意味着支持专门用于动态 SBFD 的动态指示。

建议 1：排除动态 SBFD

• 将动态 SBFD 排除在 Rel-19 双工功能的范围之外。

观察 2：关于 RRC_Idle/非活动状态下的 SBFD 操作

• 根据 TR38.858，Rel-19 双工操作不适用于处于 RRC_Idle/非活动状态的用户设备。

建议 2：RRC_Idle/非活动状态下的 SBFD 操作

• 由 RAN1 决定是否支持处于 RRC_Connected 状态的用户设备在 SBFD 符号中进行 PRACH。

• 由 RAN1 决定是使用用户设备专用 RRC 信令还是 SIB 信令来配置 SBFD。

建议 3：Rel-19 双工 WID 的内容

基站侧子带非重叠全双工 (SBFD) 操作

• 向处于 RRC_CONNECTED 模式 的用户设备指示 SBFD 子频带的 时域 位置 (半静态/动态 指示)。

• 向处于 RRC_CONNECTED 模式 的用户设备指示 SBFD 子频带的 频域 位置 (半静态 指示)。

• 用户设备在 RRC_CONNECTED 模式 下的 SBFD 符号和/或非 SBFD 符号中的传输和接收行为和程序。

• 注意：以下内容基于 TR 38.858 作出假设

SBFD 选项 4

• 支持蜂窝内同时存在传统用户设备和支持 SBFD 的用户设备 (即基站侧启用 SBFD)。

• 单个配置的下行链路和上行链路带宽对 (BWP) 内的 SBFD 方案，具有对齐的中心频率。

• TDD 载波内单个 SBFD 符号中用于 SBFD 操作的上行链路子频带 (不包括传统上行链路符号/时隙)。

• 至少应考虑两个运营商之间至少相邻信道共存。

CLI 处理增强

• 支持基站到基站 (gNB-to-gNB) 共信道 CLI 处理方案和用户到用户 (UE-to-UE) 共信道 CLI 处理方案 (具体方案将从 TR38.858 中的方案进行选择)。

• 针对 SBFD 操作的 CLI 增强应主要用于支持 SBFD 操作，但也应适用于动态/灵活 TDD 操作，但不会进行专门优化。