一份交给 RLC 的数据被分成 A1、A2、A3 三段，接收端只收到 A1 和 A3。缺失的 A2 要不要补传，由谁决定，接收端又该等多久？这组问题，可以帮助我们理解 UM 和 AM，也能看清 6G 为什么还要研究 UM-like 与 AM-like 操作。
现有 UM 不执行 RLC 层的确认重传，AM 则通过接收状态反馈和重传恢复缺失数据。6G 讨论中的“-like”借用了这两类操作特征，具体实现仍在研究。理解它们，先要掌握已有机制，再看哪些处理正在发生变化。
3GPP TS 38.300 V18.8.0，第 4.4.1 节，图 4.4.1-1：User Plane Protocol Stack（用户面协议栈）
在普通 NR 用户面协议栈中，RLC 位于 PDCP 与 MAC 之间。PDCP 交下来的协议数据单元（PDU），对 RLC 而言就是服务数据单元（SDU）。RLC 根据需要分段、添加报头，形成交给下层的 PDU；接收端则把分段重组成 SDU，交还上层。下面以 SDU A 缺失一个分段为例，对照两种处理过程。
图 1同一个 SDU 缺段时的两种处理路径
UM 非确认模式 |
AM 确认模式 |
接收端收到 A1、A3 A2 始终未到达 ↓ |
接收端收到 A1、A3 检测到 A2 缺失 ↓ |
按重组窗口和定时器规则 处理不完整的 SDU A ↓ |
满足触发条件后 通过 STATUS 报告缺失 ↓ |
不请求 RLC ARQ 补传 满足条件后丢弃相关分段 ↓ |
发送端安排缺失数据重传 必要时再次分段 ↓ |
A 无法完成重组 不能作为完整 SDU 交付 |
若补齐 A2，重组 A 并交付 通过确认更新发送状态 |
注：A1、A2、A3 为分段示意标签；两列分别表示各自流程，不表示时刻同步。UM 的丢弃、AM 的反馈和重传均须满足相应条件。
UM 的简单性，来自不执行 RLC 确认重传这一功能取舍。
UM 是 Unacknowledged Mode，即非确认模式。发送端形成 UMD PDU 并提交下层；接收端完成必要的重组，完整 SDU 一旦可用，就向上层交付。
如果 A2 始终没有到达，UM 接收端不会通过 RLC ARQ 要求对端补传，而是依据重组窗口和定时器规则处理 A1、A3，在满足条件后丢弃无法完成重组的相关分段。它有接收缓存、状态变量和 t-Reassembly 定时器，只是没有 AM 那套确认、轮询与重传管理过程。
UM 不执行 RLC 重传，并不等于空口没有重传。
NR 的 MAC 层提供混合自动重传请求（HARQ）功能；AM 另外提供 RLC 层的自动重传请求（ARQ）功能。两者处理的数据对象和反馈过程不同。因此，即使采用 UM，适用的下层 HARQ 过程仍可以参与错误恢复；若数据最终仍未交到 RLC，UM 自身不会再通过 RLC ARQ 补回。
AM 增加的是一套发送与接收协同的丢失恢复机制。
AM 是 Acknowledged Mode，即确认模式。数据提交下层后，发送端仍保留可靠传输所需的数据和状态，等待对端的接收反馈。对端通过 STATUS PDU 报告接收情况，发送端据此更新状态并处理重传。
仍以 A2 缺失为例，接收端在满足触发条件后，可以用 NACK_SN 指示缺失数据所属的 RLC 序列号（SN），用分段偏移信息描述缺失的字节范围。发送端据此安排符合条件的数据重传，必要时再次分段，以适应新的传输机会。A2 补齐后，接收端完成 A 的重组并交付上层；相应确认信息使发送端更新状态、释放已确认的数据。
这套过程不是“一包对应一条立即回复的确认”。STATUS 可以综合报告接收情况，发送端也可以通过轮询请求反馈。t-StatusProhibit 控制状态报告的发送，t-PollRetransmit 配合轮询过程处理等待反馈的情况。AM 还维护重传计数，达到最大重传阈值时向上层报告；这一步不能直接解释成自动丢弃，也不能把 AM 描述为无限重传直到成功。
这些机制带来了恢复能力，也需要缓存、状态维护、控制报文和重传资源。前部数据长期未确认，还可能影响发送窗口推进。工程上要判断的是：丢失数据是否值得继续恢复，恢复所需时间和资源是否符合业务需要。
另一个容易混淆的地方是“等待”。NR 的 UM、AM 都要求完整 SDU 可用时尽快向上层交付。因此，A 尚未补齐，并不意味着后续已经完整的 B 必须滞留在 RLC 接收端。RLC 的分段重组、AM 的发送窗口推进和 PDCP 的重排序，属于不同的处理过程。
UM 与 AM 的分工，可以追溯到早期 UMTS 规范。
2000 年 12 月的 TS 25.322 V3.5.0 属于 Release 1999，其中已经分别定义了 UM 实体与 AM 实体，并描述了 AM 的重传缓存、反馈和重传处理。两类操作并非到了 6G 才出现。
LTE 延续了这种分工。其 RLC 支持 SDU 的串接、分段和重组，也定义了 RLC 数据 PDU 的重排序过程。NR 保留 UM、AM 名称，但调整了数据组织和接收处理：一个 UMD 或 AMD 数据 PDU 承载一个完整 SDU，或者该 SDU 的一个分段；完整 SDU 可用后尽快交付上层。理解 NR 时，不能把 LTE 的具体流程直接套过来。
报头能直观体现 NR 两种模式的差别。UM 在传送未分段的完整 SDU 时，不在 UMD 报头中携带 RLC SN；只有 SDU 分段时才携带 SN。AM 的 AMD 报头则包含 SN，用于配合相应的协议处理。可见，保留 UM 的低开销，还涉及报头、编号和接收状态管理，不能只看重传功能是否关闭。
NR Release 19 已在 AM 框架内增强对数据时效性的处理。TS 38.322 V19.3.0 中已经定义了与上层丢弃指示、剩余时间有关的处理。它们体现出两个方向：不再为已经失去用途的数据继续消耗资源；在需要时，更及时地推动尚未确认数据的恢复。具体行为仍受配置和触发条件约束。
表 1NR Release 19 中与数据时效性有关的 AM 处理
要解决的问题 |
规范中的相关处理 |
已交下层的数据被上层指示丢弃 |
配置 stopReTxDiscardedSDU 后，按上层丢弃指示及规范条件，停止相应 SDU 的重传，或其分段的后续传输与重传。 |
尚未确认的数据需要更及时地恢复 |
上层指示满足基于剩余时间的条件时，将已提交下层且尚未肯定确认的数据考虑用于重传；相应的上层指示也可触发轮询。 |
接收端需要处理不再等待的缺口 |
配置 t-RxDiscard 后，接收端按到期规则丢弃相关缓存数据、更新接收状态并触发状态报告。 |
依据 TS 38.322 V19.3.0 第 5.2.3.1.1、5.2.3.2.5、5.3.2、5.3.3.2 和 5.3.4 节。
接收端的配套处理尤其重要。如果发送端不再重传某些数据，接收端还需要处理留下的缺口，使缓存和接收状态能够继续推进。停止重传因而会影响两端的处理，不能仅实现为发送端删除一份数据。
6G 继续研究的，是这些能力可以怎样组织得更灵活、更高效。
现有 NR 的 RLC 实体按配置运行一种数据传输模式，Release 19 又在 AM 中增加了有条件的区别处理。部分 6G 提案进一步探索：能否用一个机制，更普遍地承接不同数据包的可靠性要求？这里既有对已有能力的继承，也有对决策粒度和两端职责的重新设计。
Nokia 在 RAN2#135 提交的 R2-2605135《Unified RLC Mode》，提出由发送端决定每个 PDU 如何处理，包括是否重传、重传次数、放弃条件和发送优先级。需要可靠传输的数据保留并等待确认；允许尽力传输的数据可以不重传。提案用这两类行为解释 AM-like 和 UM-like 操作。
这会带来一个具体问题：接收序号出现缺口，是否一定意味着有数据需要补传？在该候选设计中，缺口也可能来自延迟到达、灵活发送顺序或主动放弃。接收端仅凭缺口难以判断发送意图，因此提案把更多重传决策交给发送端，接收端主要负责重组、交付和报告已经收到的数据。
接收端的记录也不能无限增长。为此，提案让发送端通告一个下边界 L，表示仍可能发送或重传的数据范围从哪里开始；低于该边界的数据不再要求确认，接收端据此清理相应状态。它解决的是哪些记录还需要保留的问题。这是 Nokia 提案中的机制，尚不能作为 6G 已确定的协议过程。
会上也有沿用现有模式继续增强的思路。vivo 的 R2-2604726 主张，以现有 AM、UM 为基线分别研究改进。围绕统一方案的讨论则涉及报头是否增大、UM 类业务是否承担额外反馈、状态记录是否过多等问题。这些问题直接关系到轻量操作能否继续保持简单。
RAN2#135 最终版 Chair Notes 要求 RLC 支持 UM-like 和 AM-like 两类操作，继续研究效率改进，同时保留 UM 的简单性。对技术人员而言，这意味着评估方案时需要同时看两件事：需要恢复的数据能否得到合适的确认重传处理；不需要这类处理的数据是否仍能维持较低的报头、反馈和状态维护开销。该段意见约定的是操作能力，尚未确定最终模式数量，也不能据此认定统一 RLC 方案已被否决。
截至 2026 年 9 月 7 日，3GPP Portal 将 TR 38.760-2《Study on 6G Radio RAN2 aspects》列为 Release 20 的 Draft。当前可以把 UM-like 与 AM-like 理解为 6G RLC 需要覆盖的两类操作特征；独立模式、统一机制和逐包控制如何落实，还需要继续跟踪后续研究文本和规范定义。
