当前位置: 首页 > article >正文

【5G】5G 无线协议 Radio Protocols(一)

长期演进(LTE)无线电协议主要设计用于通过扁平架构提供PS服务,相比之前的代际,这代表了一个重大改进,它消除了支持电路交换(CS)服务和复杂架构中固有的复杂性。许多原始的LTE原则自第8版以来一直未被改动,已经证明是十多年来的稳固基线。因此,在5G标准化的早期,大家一致同意使用LTE无线电协议作为5G的基线,并对其进行增强,以支持极高的数据速率、低延迟、动态频谱使用和灵活的服务质量(QoS)。

1. 5G无线电协议层

5G无线电协议包括用户面 user plane(UP)和控制面 control plane(CP)。用户面位于IP层和物理层之间:在计算机网络的OSI模型中,用户面对应于数据链路层,因此通常被称为第2层。新无线电(NR)的第2层由四个不同的子层组成:

  • 服务数据适配协议 Service Data Adaption Protocol(SDAP):负责向5GC中的UPF提供QoS流。
  • 数据包数据收敛协议 Packet Data Convergence Protocol(PDCP):向SDAP提供无线电承载。
  • 无线链路控制 Radio Link Control(RLC):向PDCP提供RLC信道。
  • 媒体访问控制 Medium Access Control(MAC):向RLC提供逻辑信道。

SDAP 层仅在与 5GC 接口时需要,也就是说对于与 LTE 双连接的非独立 5G(非 SA 5G),不需要 SDAP,但对于独立 5G(SA 5G)与 5GC 连接时,SDAP 是必须的。控制平面(CP)包括如上图所示的无线资源控制(RRC)协议,在 RRC 之上是 5GC 中 AMF 的非接入层(NAS)协议。除了处理 5G 物理层的新方面所需的机制外, radio 协议在 LTE 基线上的主要变化驱动因素包括:(1)需要支持比早期代更大的数据速率和更低的延迟;(2)提供动态频谱使用;(3)支持来自 5GC 的新 QoS 框架。以下是根据这些关键驱动因素所做的主要变更摘要。

首先,为了支持大数据速率和低延迟的组合,5G 无线协议已针对 UE 处理进行优化。处理要求受实时操作的约束。在上行链路中,这意味着 UE 在收到网络授予后需要执行的操作,以构建上行传输块。为了放宽处理要求,实时操作被推到无线协议的较低层,尽可能接近物理层,以便在不知道授予大小的情况下进行尽可能多的处理,即允许尽可能多的非实时操作和预处理。最大化非实时操作的数量也使并行处理变得更容易,这是减少电池消耗的关键。为了简化 UE 处理,5G 无线协议与 LTE 相比引入的主要变化如下:

  • RLC 拼接移动到 MAC(构建 RLC PDU 变成非实时操作)。
  • 上行链路和下行链路中 MAC CE 的不对称放置(使 UE 处理 MAC CE 更容易)。
  • MAC 中子头的交织(使 MAC PDU 的流水线处理成为可能)。

此外,重新排序操作在无线协议中得到了简化,现在只有 PDCP 执行包的重新排序(在 LTE 中,RLC 和 PDCP 都有重新排序窗口)。无需在 RLC 中重新排序包,PDCP 可以在包到达 UE 时解密(参见第 7.4 节)。RLC 中确认包的序列缺口不再阻碍 PDCP 中的解密操作。

其次,NR 中频谱使用的粒度低于传统系统的载波频率:随着带宽部分(BWP)的加入,UE 可以被约束在一个有限的频段(即“带宽部分”)内进行操作,因此得名“带宽部分”。此外,UE 使用的 BWP 可以在同一小区内命令变更,并且所有 BWP 不必使用相同的数字特性。

第三,在连接到 5GC 时,QoS 不再与传统系统的无线接入承载模型相关联。在 5GC 中,每个数据包都会由核心网络标记一个质量服务流标识符(QFI),gNB 可以使用该信息选择适当的无线承载。核心网络的无线接入承载与无线接入网络(RAN)中的无线承载之间的“一对一”映射关系消失,gNB 被赋予配置和选择适当无线承载的任务,以满足 QoS 要求。

2. SDAP

SDAP 层处理将 PDU 会话中的 QoS 流映射到数据无线承载(DRB)上。与之前的网络代际不同,核心网中的无线接入承载(RAB)与 RAN 中的无线承载之间不存在一一对应关系。在 5G 中,QoS 模型不是基于 RAB,而是基于 QoS 流;它支持需要保证流量比特率的 QoS 流(GBR QoS 流)和不需要保证流量比特率的 QoS 流(非 GBR QoS 流)。该模型为 RAN 提供了更大的自由度:5GC 仅通过 QFI 标记数据包,RAN 被委托使用该信息配置并选择适当的 DRB 来匹配相应的 QoS 流。并非所有的 QoS 流都需要独立的 DRB,多个 QoS 流可以由 gNB 在同一 DRB 上进行复用。QFI 在 NG-U 上的封装头中携带,作为指向 QoS 配置文件的指针,描述多个用于表征流的 QoS 参数,例如保证流量比特率(GFBR)、最大流量比特率(MFBR)和最大丢包率(见 3GPP TS 23.501)。QoS 配置文件还包含一个 5G QoS 标识符(5QI),该标识符指向 QoS 特性,例如优先级级别、包延迟预算(PDB)、包错误率(PER)和最大数据突发量(MDBV)。这一点在下图中做了总结。5QI 与 QoS 特性之间的对应关系要么在规范中固定,要么由 5GC 在 PDU 会话建立时或稍后通过 PDU 会话修改程序通知 gNB。


gNB 将 QoS 流映射到 DRB 的方式基于 QFI 和相关的 QoS 配置文件(即从核心网信令的 QoS 参数和 QoS 特性),如下图 所示。服务数据流(SDF)到 QoS 流的映射由核心网管理。


在上行链路中,UE 将 QoS 流映射到 RB 的规则由 gNB 向 UE 信令,如下图所示。SDF 到 QoS 流的映射由核心网管理,并在 NAS 层通过信令传递给 UE。


映射规则可以通过 RRC 信令显式配置,或通过反射 QoS(RQoS)隐式配置。使用 RQoS 时,UE 从下行链路可用的信息中推导出上行链路的映射规则。例如,一个 QoS 流 x 在下行链路的 DRB y 上接收时,隐式告诉 UE 使用相同的 DRB y 来发送来自该 QoS 流的上行数据;也就是说,QoS 流 x 到 DRB y 的映射规则是隐式配置的。此外,所有未配置映射规则的 QoS 流会默认映射到默认 DRB 上。
因此,5G 的 QoS 框架允许一种操作模式,其中(1)使用配置了默认 QoS 的默认 DRB 来承载大部分流量;(2)只有具有特定要求的 QoS 流在出现时才会动态地(重新)映射到专用 DRB,而无需涉及 5GC。结合 RQoS,这极大地减少了信令的数量并降低了控制面延迟:并非所有 DRB 在从 IDLE 转移到 CONNECTED 时都需要配置,而且 QoS 流的重新映射不总是需要控制面信令。事实上,在典型的使用场景中,处理的流量数量非常大,并且频繁地来去。例如,在浏览互联网时,一个点击可能会启动十多个 TCP/IP 流。使用 RQoS 时,虽然无线承载的分配仍由网络控制,但控制面信令仅限于承载的建立:无需显式地对大量流量进行映射规则的信令。
配置 SDAP 子层以处理一个 PDU 会话的 QoS 流的过程被称为 SDAP 实体。在单连接的情况下(仅使用一个 gNB),每个由 5GC 建立的 PDU 会话对应一个 SDAP 实体。

2.1. QoS 流重新映射

当 QoS 流的映射规则发生变化时,需要进行 QoS 流重新映射,例如在切换时,当目标 gNB 的映射策略与源 gNB 不同,或当 gNB 将新的 QoS 流从默认承载中移开时。
在将 QoS 流从旧承载映射到新承载时,可能有一些来自该 QoS 流的包仍在等待在旧承载上传输——由于 5G 允许大量预处理,因此这种情况是非常常见的。更新映射规则后,来自 QoS 流的包将同时从旧承载和新承载并行到达接收方,直到旧承载中的包被传送完毕(请注意,要求 UE 拉取所有预处理数据并将其从旧承载中移除以进行重新映射的方案被认为不可行)。有序交付因此需要在新 DRB 上缓冲新数据,直到旧 DRB 中的数据完全传输完毕。此缓冲可以在接收方或发送方进行。
在发送方缓冲的情况下,只有在传输完从旧承载迁移过来的 QoS 流的所有数据包后,才会开始通过新承载传输新数据。这对于接收方是透明的,但要求发送方在迁移的 QoS 流上缓冲新数据。在接收方缓冲的情况下,只有在所有来自旧承载的 QoS 流的数据包都已收到并按顺序交付给上层后,才会将新承载中的新数据交付给上层。这对于发送方是透明的,但要求接收方缓冲来自 QoS 流的新数据。
为了最小化 UE 的缓冲要求,在下行链路中使用发送方缓冲,而在上行链路中则使用接收方缓冲。然而,为了帮助 gNB 确认所有来自重新映射的 QoS 流的数据已经通过旧承载发送完毕,引入了结束标记。结束标记始终由 UE 在更新映射规则后通过旧承载传输。
下行链路中 QoS 流迁移的示例如图所示,其中 QoS 流 A 最初与 QoS 流 B 一起映射到 RB1,然后被重新映射到 RB2(图中的步骤 1)。更新映射规则后,来自 QoS 流 A 的新数据在 RB2 的传输队列中被缓冲,直到 RB1 中不再有来自 QoS 流 A 的数据(图中的步骤 2)。一旦 RB1 中不再有来自 QoS 流 A 的数据,就可以开始在 RB2 上传输来自 QoS 流 A 的数据(图中的步骤 3)。
上行链路中 QoS 流迁移的示例如图 7.6 所示,其中 QoS 流 A 最初与 QoS 流 B 一起映射到RB1,然后被重新映射到 RB2(图中的步骤 1)。更新映射规则后,来自 QoS 流 A 的新数据在 DRB2 中被接收方缓冲,直到接收到结束标记(图中的 M)为止(图中的步骤 2)。一旦收到结束标记,来自 QoS 流 A 的缓冲数据将交付给上层,缓冲过程结束(图中的步骤 3)。

2.2. 最大数据突发量(MDBV)

在 5G 中引入的一个新的 QoS 特性是 MDBV。MDBV 表示在给定延迟内需要服务的最大数据量,是 5G QoS 配置文件的一个特性。
MDBV 被用于无线接入控制,以评估在一个小区中可以并行支持多少个延迟关键型 GBR 承载。如果延迟关键型 GBR 承载发送的数据量超过了 MDBV 中最初指示的数据量,gNB 必须在执行接入控制时考虑统计变化,从而减少它允许的延迟关键型 GBR 承载的数量,并减少需要保证资源的任何类型的承载。例如,考虑一个延迟关键型 GBR 服务,要求每秒在 5 毫秒内发送 160 字节数据,配置 PDB 为 5 毫秒,MDBV 为 160 字节,GBR 为 1280 bit/s(160 字节/s)。如果没有 MDBV,gNB 必须处理最高 256,000 bit/s(160 字节的 1/2 倍),这是为了满足延迟关键型 GBR 服务。引入 MDBV 后,gNB 可以限制延迟关键型 GBR 服务的最大服务容量,以确保服务在指定的突发量内。

2.3. DRB 和 SDAP 关联

SDAP 子层与 DRB 层的关联至关重要。DRB(数据无线承载)负责为 PDU 会话提供数据承载服务,而 SDAP 子层则负责在数据承载上映射和管理 QoS 流。每个 PDU 会话的传输都通过一个或多个 DRB 进行,而 SDAP 的作用是确保每个 DRB 上的数据流按照其 QoS 特性进行处理。

3. PDCP

PDCP层处理DRB(数据承载)并保证无重复地按顺序传递给上层,必要时进行头部压缩,并负责在RAN中通过加密和完整性保护实现安全性。在5G中,PDCP层还负责重复处理,以提高可靠性并减少延迟。每个PDCP实体用于处理一个无线承载的配置。每个无线承载都有一个PDCP实体。
在LTE和5G双连接的情况下,总是使用基于5G的PDCP层。这使得实际的数据路由(是否通过eNB或gNB)对UE实现保持透明,因为用户面操作在两种路由选项下保持一致。

3.1. 重排序

LTE中PDCP重排序窗口的设计过程是很有趣的。首先,在切换过程中同意了重排序窗口的使用,以确保在切换期间按顺序传递。然后,为了应对切换期间可能发生的转发丢失,重排序窗口改为重复丢弃窗口。最终,为了简化行为,决定始终应用该窗口(即不仅仅在切换时应用),并移除清空定时器。因此,当UE在LTE中接收到PDCP SDU时,它会将该SDU以及所有具有较低序列号(SN)的PDCP SDU按升序一起传递给上层,无论是否有间隙。考虑到进一步的简化,尽管在Release 8结束时没有进一步的修改,但LTE的PDCP重排序窗口原则未作更改。
5G开启了进一步简化的大门:决定只在PDCP中执行重排序,而不在RLC中执行重排序。无需在RLC中重排序数据包,PDCP现在可以即时解密数据包:在RLC中已确认数据包的SN序列发生间隙时,数据传递不会因此停滞,解密操作也不再处理大量的数据包。此外,与LTE不同,在5G中还可以配置PDCP不进行数据包重排序。这是针对那些能够容忍乱序传递的应用。
另一个在5G中达成的简化是,依赖COUNT变量来指定UE的行为(而不是像LTE中那样依赖SN),并假定它永远不会环绕。COUNT仍然是基于接收到的SN和状态变量来确定的,但这种简化使得描述更加简洁,易于理解。COUNT使用32位,可以交换约43亿个数据包,才会发生环绕。这相当于6442 Gb的数据,或者是连续994天的电话通话(假设每个数据包1500字节,间隔20毫秒)。因此,假设COUNT不会环绕没有实际限制。如果环绕发生,gNB可以将QoS流移动到新的无线承载。

3.2. 安全性

RAN中的安全性通过加密和完整性保护得到保证。与LTE相同,完整性保护的配置对于信令无线承载(SRB)和处于有限服务状态的UE的紧急呼叫是强制的,NULL算法被配置。然而与LTE不同的是,完整性保护不仅限于SRB;它也可以配置用于DRB,但其比特率有UE能力的限制。
PDCP的完整性保护功能包括发射端的完整性保护和接收端的完整性验证。完整性保护会生成一个32位的MAC-I,附加在PDCP PDU的末尾。完整性保护的算法及其输入在3GPP TS 33.501中定义。
PDCP的加密功能包括发射端的加密和接收端的解密。只有SDAP PDU的数据部分会被加密,同时当有时,MAC-I也会一起加密。由于SDAP头部不加密,允许在接收端进行数据路由,从而在解密之前进行处理。如果SDAP头部也被加密,会导致UE和网络的硬件架构限制,无法进行这种路由。加密算法及其输入在3GPP TS 33.501中定义。
下图总结了PDCP中的安全性,并说明了完整性保护和加密适用的PDCP PDU部分。在解密后,如果接收端对无线承载的完整性验证失败,则只丢弃相应的PDU,并通知RRC。如果这是SRB的完整性验证失败,则RRC会触发重建。在DRB上发生完整性验证失败时不触发重建,限制了数据包注入的影响,并减少了拒绝服务(DoS)的可能性。

3.4. 头部压缩

PDCP中的头部压缩基于RFC 5795定义的稳健头部压缩(RoHC)框架,该框架定义了多个头部压缩算法(也称为配置文件),特定于RAN中的第二层之上的层,如TCP/IP或RTP/UDP/IP。头部压缩的动机来源于语音服务,旨在为这些服务提供与传统CS服务相当的覆盖范围,而这些传统服务没有RTP/UDP/IP头部。
一旦为DRB配置了RoHC,RoHC会生成两种类型的数据包:一种是具有压缩头部的PDCP PDU,另一种是RoHC反馈数据包。前者总是与PDCP SN关联,并且可以加密,而后者则归类为PDCP控制PDU,不具备SN关联,且既不加密也不进行完整性保护。

3.5. 重复和状态报告

重复可能由PDCP下层的协议层生成,当确认应答失效,导致重传失败时。这通常发生在切换期间,由于没有足够的时间同步RLC的传输和接收窗口(在确认模式下),且RLC实体被重置时,接收方正确接收的最新PDU并不为发送方所知。为了确保无损移动性,这些PDU在切换后会被重新传输,从而生成重复。
为了避免将这些重复传递给上层,PDCP根据接收到的SN丢弃重复的PDU:如果已经接收到具有相同SN的PDU,则丢弃该PDU。然后,为了减少切换后重复的数量,PDCP可以在切换后与目标小区交换状态报告。重要的是要理解,PDCP状态报告并不是为了保证无损移动性而必须的;它们只是帮助减少重复所带来的空中接口开销。此外,由于在接收到和处理PDCP状态报告之前,目标小区的重传可以在一个方向(例如下行链路)开始,因此并非所有的重复都能被消除。然而,几次重复的开销在空中接口上是可以接受的,以确保低延迟的无损移动性(等待状态报告的接收和处理可能会不必要地延迟传输)。图7.8展示了状态报告如何工作。


如图所示,在下行链路上,切换前源gNB发送了PDU {a, b, c, d, e, f, g, h},但只有{a, d}被UE确认。UE的接收窗口知道PDU {b, c}丢失,这阻止了PDU {d, e, f, g}向上交付,而PDU {a}已交付给上层。在上行链路上,切换前UE发送了PDU {1, 2, 3, 4, 5, 6, 7, 8},但只有{1, 2, 4, 6}被gNB确认,因此第一个丢失的PDU是{3}。在gNB的接收窗口中,PDU {3}已知丢失,这阻止了PDU {4, 5, 6}向上交付,而PDU {1, 2}已交付给上层。在切换时,源gNB将其接收和发送窗口的内容转发给目标gNB,即下行链路中的PDU {b, c, e, f, g, h}以及上行链路中的PDU {4, 5, 6},同时UE准备重传所有从第一个已知丢失的PDU开始的PDU,即PDU {3, 4, 5, 6, 7, 8}。切换后,gNB生成的上行链路状态报告通知UE,PDU {1, 2}和PDU {4, 5, 6}已正确接收,UE可以从其传输缓冲区清除这些PDU,仅重传PDU {3, 7, 8}而不是{3, 4, 5, 6, 7, 8}。UE生成的下行链路状态报告通知gNB,PDU {a}和PDU {d, e, f, g}已正确接收,gNB可以从其传输缓冲区清除这些PDU,仅重传PDU {b, c, h}而不是{b, c, e, f, g, h}。

3.6. 重复

为了支持超可靠低延迟通信(URLLC)服务,5G在PDCP中引入了重复传输。通过重复,除了在“主路径”上发送原始PDU外,还使用“副路径”传输原始PDU的重复副本,如图所示。


只要两个路径彼此独立,重复传输就可以增加以尽可能短的时间将PDU传送到接收端的机会:在任何时刻,最快的路径都会推动传输的进程。为了保证两个路径彼此独立并且不通过相同的无线电路径传输,采用不同的小区或不同的小区组进行多样性传输。前者称为载波聚合(CA)重复,后者称为双连接(DC)重复。在这两种情况下,都保证原始PDU和其重复副本不会被传输到相同的传输块中。注意,CA重复依赖于LCP限制,以确保使用不同的传输块。
一旦已知PDU到达接收端,如果对应的PDU仍在等待传输,则会丢弃该PDU(如果重复副本通过副路径接收到,则丢弃主路径上的原始PDU,或者如果原始PDU通过主路径接收到,则丢弃副路径上的重复副本)。在接收端,当第二次收到相同的PDU时,使用相同机制丢弃该PDU。


http://www.kler.cn/a/447575.html

相关文章:

  • Linux应用开发————mysql数据库表
  • 任务三数据库加固
  • 【计算机网络2】计算机网络的性能能指标
  • HUAWEI-eNSP交换机链路聚合(手动负载分担模式)
  • DB-GPT V0.6.3 版本更新:支持 SiliconCloud 模型、新增知识处理工作流等
  • 【Linux系统编程】:信号(2)——信号的产生
  • 【大语言模型】ACL2024论文-30 探索语言模型在文本分类中的伪相关性:概念层面的分析
  • clickhouse-题库
  • VSCode中的Black Formatter没有生效的解决办法
  • 云计算赋能:TSP 问题求解与创新定价机制的全景剖析
  • MFC/C++学习系列之简单记录10——定时器
  • 基于SpringBoot+Vue的音乐网站-无偿分享 (附源码+LW+调试)
  • LSTM实现天气模型训练与预测
  • 编译原理复习---运行存储分配
  • 化工行业SAP管理系统:构建未来可持续生产模式的基石
  • 【新立电子】FPC的未来展望:柔性电子技术的无限可能
  • Python数学运算
  • jquery弹性动画特效插件DomLastic.js
  • 基于cobra开发的k8s命令行管理工具k8s-manager
  • Redis篇--常见问题篇9--其他一些问题
  • Coding Caprice - Linked-List 1
  • 【第八节】git与github
  • 【Leecode】Leecode刷题之路第88天之合并两个有序数组
  • Linux下基于最新稳定版ESP-IDF5.3.2开发esp32s3入门任务间的通讯-信号量【入门三】
  • 前端项目打包部署后,如何避免让用户强制去清除浏览器缓存
  • STM32低功耗模式结合看门狗