博主未授权任何人或组织机构转载博主任何原创文章,感谢各位对原创的支持!
博主链接
本人就职于国际知名终端厂商,负责modem芯片研发。
在5G早期负责终端数据业务层、核心网相关的开发工作,目前牵头6G算力网络技术标准研究。
博客内容主要围绕:
5G/6G协议讲解
算力网络讲解(云计算,边缘计算,端计算)
高级C语言讲解
Rust语言讲解
文章目录
- 一、CU与DU之间的F1协议介绍
- 二、F1接口的功能
- 2.1 控制面功能
- 2.1.1 `F1 Setup`
- 2.1.2 `Reset`
- 2.1.3 `Error Indication`
- 2.1.4 `gNB-DU Configuration Update`
- 2.1.5 `gNB-CU Configuration Update`
- 2.1.6 `gNB-DU Resource Coordination`
- 2.1.7 `gNB-DU Status Indication`
- 2.1.8 `Initial UL RRC Message Transfer`
- 2.1.9 `DL RRC Message Transfer`
- 2.1.10 `UL RRC Message Transfer`
- 2.1.11 `UE Context Setup`
- 2.1.12 `UE Context Modification`
- 2.1.13 `UE Context Release`
- 2.1.14 `UE Inactivity Notification`
- 2.1.15 `Notify`
- 2.1.16 `System Information Delivery`
- 2.1.17 `Write-Replace Warning`
- 2.1.18 `Paging`
- 2.2 用户面功能
- 2.2.1 `PDU Type 0`
- 2.2.2 `PDU Type 1`
- 三、总结
- 参考
一、CU与DU之间的F1协议介绍
gNB CU与gNB DU通过F1接口连接,F1又分为控制面(F1-C)和用户面(F1-U),其中F1-C用于传输信令,而F1-U用于数据传输。下图说明了属于F1接口的CP和UP协议栈。控制面使用SCTP协议,而用户面使用GTP-U协议。
二、F1接口的功能
F1接口执行下面的管理操作:
2.1 控制面功能
2.1.1 F1 Setup
F1 Setup流程用于在CU-CP和DU之间创建一条逻辑F1连接。在启动F1 Setup之前,必须在CU-CP和DU之间建立一个SCTP连接。DU通过发送一个F1 Setup Request消息来启动这个过程,而CU-CP通过返回一个F1 Setup Response来完成这个过程。F1 Setup Request用于告知CU-CP DU的身份和DU支持的小区集合。F1 Setup Response用于指示哪些DU小区应该被激活。
2.1.2 Reset
Reset过程可以由CU-CP发起,也可以由DU发起。它用于重置所有F1AP UE上下文,或F1AP UE上下文的一个特定子集。当CU-CP发起Reset流程时,DU释放F1接口的所有相关资源和所有相关无线资源。当DU发起复位时,CU-CP释放F1接口的所有相关资源。该过程使用Reset/Reset确认握手。它不会导致F1接口本身重置。
2.1.3 Error Indication
该过程可以由CU-CP或DU发起。它用于报告在传入的F1 AP消息中检测到错误。当相关信令流程中的错误消息无法上报时可以使用Error Indication。
2.1.4 gNB-DU Configuration Update
DU使用此消息向CU-CP更新关于其支持的小区集信息。gNB-DU配置更新消息允许添加新小区、修改或删除现有的小区。CU-CP使用GNB-DU Configuration Update Acknowledge消息确认更新。
2.1.5 gNB-CU Configuration Update
CU使用此消息向DU更新关于激活或去激活的小区集信息。当激活一个小区时,CU能够指定激活小区的PCI。CU通过GNB-CU Configuration Update消息启动该过程,而DU通过GNB-CU Configuration Update Acknowledge消息确认更新。
2.1.6 gNB-DU Resource Coordination
适用于gNB和NG-eNB共享重叠覆盖区域的频谱。F1AP过程用作对应的XnAP过程的一部分,即F1AP过程用于在CU和DU之间转发XnAP消息。F1AP: GNB-DU Resource Coordination Request消息用于封装XnAP: E-UTRA – NR Cell Resource Coordination Request消息。类似地,F1AP响应封装了XnAP响应。DU是这个过程的目标,而不是CU,因为它会影响位于DU内部的分组调度器。
2.1.7 gNB-DU Status Indication
DU可以通过gNB-DU Status Indication消息上报CU是否过载。gNB-DU Status Indication消息只包含一个标志,表示DU是否过载。
2.1.8 Initial UL RRC Message Transfer
用于将初始的上行RRC消息从DU转发到CU-CP。此初始上行消息属于CCCH,例如RRC Setup Request消息。该过程还用于向CU-CP通知由DU分配的C-RNTI,并向CU-CP提供CellGroupConfig参数结构,其中包括有关新连接的RLC、MAC和物理层配置的信息。此外,该过程用于发起建立跨F1接口的UE相关连接。这是通过向CU-CP提供gNB-DU UE F1AP Identity来实现的,该标识可用于在任何后续消息传输期间寻址与UE相关的连接。CU-CP在第一个DL RRC消息传输中提供相应的gNB-CU UE F1AP Identity。
2.1.9 DL RRC Message Transfer
用于从CU-CP向DU传输下行RRC消息。CU-CP生成RRC消息,并在PDCP层中处理。然后它们作为PDCP PDU被传输到DU。DL RRC Message Transfer消息可以包含一个标志,指示DU应用SRB重复功能。重复传输通过使用多个载波传输相同的RRC消息来提高可靠性。此外,DL RRC Message Transfer消息可以包括RAT频率优先信息,当传输RRC消息时用于DU内的优先级决策。
2.1.10 UL RRC Message Transfer
用于从DU向CU-CP传输上行RRC消息。DU接收来自UE的RRC消息,并在物理层、MAC层和RLC层进行处理,然后传输到CU-CP。
2.1.11 UE Context Setup
F1AP UE Context Setup流程包括UE Context Setup Request和UE Context Setup Response。该过程总是由CU-CP发起。在初始连接建立的情况下,在AMF的NG-C:Initial UE Context Setup Request之后,F1AP:UE Context Setup Request消息。通过F1AP的UE Context Setup Request消息可以配置一组SRB和一组DRB。DU为每个DRB提供上行GTP-U TEID,允许上行用户平面数据向CU传输。F1AP的UE Context Setup Response消息详细说明了对应的下行GTP-U TEID。UE上下文设置过程也可以在进入切换过程中使用,即在目标DU创建一个新的UE上下文。在决定切换后,即从UE收到RRC Measurement Report后,CU立即向目标DU请求新的UE上下文。
2.1.12 UE Context Modification
CU-CP通过修改终端上下文流程更新初始化终端上下文设置时提供的配置。它也可以用来指示DU停止或重新开始向UE传输。UE Context Modification Request消息可用于封装RRC消息,DU随后将该消息发送给UE。当DU从CU发送的UE Context Modification Request消息中收到RRC重配置信息,其会向终端转发这条RRC重配置信息。DU使用UE Context Modification Required流程更新下行GTP-U TEID集合。它还可以指定释放特定SRB和DRB的要求。此外,当gNB和NG-eNB共享重叠覆盖的频谱时,它可以提供关于其小区的更新信息,并指定更新资源协调信息的需求。
2.1.13 UE Context Release
CU-CP可以通过UE Context Release流程释放已存在的UE上下文。DU可以向CU发送UE Context Release Request消息来请求CU发起该过程,并且发送该消息对应于该UE上下文释放请求过程。
2.1.14 UE Inactivity Notification
通过此操作,DU可以上报终端的非活动状态。DU会指示每个DRB的“活跃”或“不活跃”。
2.1.15 Notify
当特定的DRB不再满足GFBR时,Notify过程允许DU通知CU-CP。这适用于启用Notification Control的GBR QoS流。如果随后又满足GFBR要求,DU也能够去通知CU。
2.1.16 System Information Delivery
这个过程允许CU-CP向DU提供Other System Information(OSI)类型的列表,以便在特定的小区上广播。OSI包括SIB2到SIB9。系统信息传递过程可以通过终端请求广播其他系统信息来触发。
2.1.17 Write-Replace Warning
这个过程允许CU发起或覆盖警告消息广播。这些信息适用于公共警报系统(PWS)。该过程使用CU-CP和DU之间的Write-Replace Warning Request和Write-Replace Warning Response。Write-Replace Warning Request消息包含了需要广播的PWS系统信息。CU-CP可以使用PWS取消流程指示DU停止广播PWS系统信息。DU使用PWS重启指示程序向CU提供一个有可用PWS信息的小区列表。DU使用PWS故障指示流程向CU提供PWS传输失败的小区列表。
2.1.18 Paging
CU-CP在请求DU寻呼特定终端时使用paging流程。paging消息包含UE标识索引,可用于计算目标UE的寻呼帧。寻呼消息可以包括RAN UE Paging Identity (I-RNTI)或Core Network UE Paging Identity (S-TMSI)。当使用RRC Inactive状态时,I-RNTI被分配给UE。DU还提供了寻呼DRX周期长度、寻呼优先级和传输寻呼消息的小区列表。
2.2 用户面功能
F1-U的用户平面用于在CU-UP和DU之间传输应用层数据。每个DRB建立一个隧道,并使用TEID来识别每个隧道。运行在GTP-U层之上的用户面协议提供了与下行数据传输相关的各种控制机制,这些控制机制包括流量控制、丢包检测和成功递交报告。用户面协议使用的帧格式称为PDU Type 0,由CU发送,PDU Type 1由DU发送。
2.2.1 PDU Type 0
CU-UP使用PDU Type 0为每个下行数据包添加一个序列号。DU使用这个序列号来检测丢失的数据包。CU-CP也可以使用POU类型来提供各种丢弃指令。如果DU报告无线链路中断,那么CU-UP可能尝试使用第二个DU从PDCP层重新传输。如果第二个DU上报PDCP PDU递交成功,则CU-UP通知原DU丢弃已成功递交的报文,以避免不必要的传输。
2.2.2 PDU Type 1
DU使用PDU Type 1来报告任何丢失的数据包,并控制CU发送下行数据的速率,即它提供了一种流量控制机制,以避免DU内部的缓冲区变得太满。DU会指示成功递交的最高PDCP PDU序列号、期望的缓冲区级别和期望的数据速率。期望的数据速率指定为DU希望在1秒的时间间隔内接收的字节数。CU使用这些信息元素来确定发送给DU的数据量。DU也可以使用PDU Type 1来表示无线电链路中断或无线电链路恢复。
三、总结
- F1接口是一个开放接口,F1两端的接口可以是不同的设备商;
- 3GPP TS 38.470介绍了F1、3GPP TS 38.473介绍了F1AP、3GPP TS 38.425介绍了F1- U;
- F1接口支持节点之间的信令和数据交换;
- 从逻辑角度来看,F1是端点之间的点对点接口,这意味着即使端点之间没有物理直接连接,点对点逻辑接口也应该是可行的;
- F1接口支持控制平面和用户平面分离;
- F1接口分离了无线网络层和传输网络层;
- F1接口可以交换终端相关的信息和非终端相关的信息;
参考
- 3GPP TS 38.470 5G NG-RAN F1 general aspects and principles
- 3GPP TS 38.473 5G NG-RAN; F1 Application Protocol (F1AP)
- 3GPP TS 38.425 5G NG-RAN; NR user plane protocol