6G通算融合网络架构

彭程晖，邓 娟，吴建军，刘 哲，李芳芳，刘光毅，孙韶辉，杨 旸，张宏纲，李荣鹏

(1.华为技术有限公司 无线技术实验室，上海 201206；2.中国移动通信有限公司研究院 未来研究院，北京 100053；3.中信科移动通信技术股份有限公司，北京 100083；4.上海科技大学 信息科学与技术学院，上海201210；5.浙江大学 电子与信息工程学院，浙江 杭州310027)

0 引言

近年来，互联网、大数据、云计算、人工智能、区块链等技术创新，新业态、新场景和新模式的不断涌现，加速了数字经济的发展，推动了海量数据产生，使各行各业对通信和计算提出了更为迫切的需求。通信和计算已成为全社会数智化转型的基石，直接决定社会智能的发展高度。而通信网络作为连接用户和传输数据的管道，可感知计算，用于支撑多样性的分布式计算资源的高效使用，例如部署于通信网络内的边缘计算来降低端到端时延和提升业务体验等，已成为业界关注热点[1-3]。多样性计算资源、通算融合等成为业界重要技术趋势。

当前，业界已经发表了近百篇的6G白皮书，对6G时代的愿景、新兴业务场景、技术需求等进行了广泛、深入的分析。其中，通过设计6G网络架构原生地支持通信与计算的深度融合，以更好地实现各项6G网络新能力(如内生智能、泛在感知)和新业务(如沉浸式XR、数字孪生、云宇宙等)，从而进一步实现6G智能普惠愿景已成为业界共识[4-7]。

通信与计算的深度融合是6G网络内生AI的重要技术特征。通过传统Cloud AI提供的AI服务，其数据安全隐私需要更为有效的基础保障手段，分布式计算资源、AI模型等也需要更高效的共享手段，从而支撑以相对较低的成本为用户提供所需的AI服务并保障服务质量。通过6G网络内生的AI能力，即通过网络AI[4]提供AI服务(Artificial-Intelligence-as-a-Service，AIaaS)，有望解决上述挑战，并在极致性能、高安全隐私等业务场景下，成为Cloud AI的有益补充。在网络AI场景中，如何基于通信和分布式计算资源的高效协同，为用户提供更低时延抖动、更高综合效率的计算服务和保障AI QoS(Quality of Service)服务是一个待解问题；而其中一个重要的技术挑战是通算融合问题，即通信与计算实现更深入、实时的协同，以在动态复杂无线网络环境下，保障未来新业务端到端的超低时延、高数据安全隐私和可持续性节能等要求。

1 背景介绍

无线网络通算融合的目标是在动态复杂无线环境下满足AI QoS的同时，实现网络资源、计算资源的最佳效率。当前，业界谈到通算融合，一般存在外挂计算资源、内生计算资源两种形式。其中，外挂计算资源，如边缘计算，网络节点的通信资源与计算节点的计算资源通过管理面功能实现联合优化。内生计算资源，是利用网络的内生计算资源，网络节点不仅具备控制与转发能力，还能兼顾计算能力。这两种方式存在本质区别，下面进行具体分析。

1.1 边缘计算

传统云计算中心集中存储、计算的模式正向边缘下沉，这已经成为云计算的重要发展趋势[8]。分布式的边缘计算(Edge Computing，EC)或多边缘计算(Multi-access Edge Computing，MEC)作为云计算的演进，将计算从集中式数据中心下沉到通信网络接入网边缘，更接近终端用户[9]。EC/MEC以分布式的方式在更靠近用户的网络边缘提供计算服务，便于在提供更低时延的同时，减少对网络资源的消耗，以更好地服务一些行业应用，比如视频加速、网络自动驾驶、增强现实/虚拟现实(Augmented Reality/Virtual Reality，AR/VR)等低延时高带宽的场景,以及包括非实时的无线协议处理及网络优化等在内的网络应用。然而，EC/MEC只是在物理位置上部署在通信网络内，但是在逻辑上计算与通信拥有彼此独立的管控体系；基于EC/MEC的应用部署是通过管理面实现通信资源与计算资源的联合优化，动态性存在一定的缺陷，难以实现网络和计算在控制面的统一，从而及时响应用户的移动以及网络的变化。

1.2 承载网络通算协同

面向通算融合的演进需求，在承载网络层面也开展了许多研究工作。中国信息通信研究院联合三大运营商等，就目前通算融合趋势下的不同技术路线展开探索，关于通算融合的必要性做了很多分析[10-12]。其中，路由层引入了通算融合机制，通过边界网关协议(Border Gateway Protocol，BGP)[10-12]、内部网关协议(Interior Gateway Protocol，IGP)[10-11]或基于IPv6的分段路由(Segment Routing IPv6，SRv6)[12]等IP层协议的随路控制信令实现计算与网络性能信息扩散与同步，因此路由层可以结合当前的计算能力状况、应用效能等信息和网络状况，将计算任务报文路由到相应的计算节点，从而实现连接与计算资源在网络的全局优化。

整体无线通信系统可以进一步分为承载网络和业务网络，如图1所示。承载网络是为无线接入网(Radio Access Network，RAN)和核心网(Core Network，CN)提供连接的基础网络；业务网络包括无线接入网和核心网两个部分，为移动用户提供无线数据服务，连接移动用户(User Equipment，UE)与数据网络(Data Network，DN)[13-14]。

图1 承载网络与业务网络

对于通算融合来说，对于通算融合来说，既可以在承载网络进行通信与计算的协同，也可以在业务网络进行通信与计算的协同。业务网络和承载网络分别工作在不同的协议层面，其中承载网络的核心协议是由IETF(Internet Engineering Task Force)来定义，而业务网络的核心协议是由3GPP(The 3rd Generation Partnership Project )定义。它们的核心场景存在区别，如业务网络可以直接感知用户、会话，提供用户的接入控制、适配无线动态信道环境、用户移动管理等，因此，业务网络和承载网络相对是解耦的，例如，无线网络的空口协议不感知IP层协议。因而，承载网络提供的通算协同机制难以直接被业务网络使用，业务网络需要基于自身的特性，来设计对应的通算协同机制。

2 独立计算面

由于EC/MEC或承载网络的通算协同还难以直接被6G网络使用，特别是在无线接入层面，因此，移动无线网络的通算协同机制需要进一步设计。为在6G网络架构层面原生支持通算协同，本文提出了一种计算面设计方案，包括计算与连接的融合控制、计算数据的传输和计算执行，并进一步设计了统一的通算融合框架，基于该框架设计了无线网络内通信与计算实时协同的计算面方案。通算融合框架需要支持如下关键能力：

① 在控制面实现实时通算协同，管控计算会话和计算执行，应对无线的快速变化环境、用户移动性等带来的问题；

② 管控网络内的分布式计算资源，支持通信和计算相互感知，提升综合资源能效。

2.1 移动无线网络通算协同

6G网络中，计算资源将遍布于包括中心云、边缘云、网络设备甚至终端设备在内的各种基础设施。计算资源以及附着之上的人工智能算法或功能应用，不仅能服务于网络或者设备本身用以改善性能，优化网络运维，还能通过统一的接口向外开放、服务于上层应用。计算和通信需要相互感知，实现用尽量少的通信资源和计算资源满足用户所需的QoS。为了实现上述目的，本文设计了在控制面支持通信与计算实时协同的计算面方案。

2.2 计算面定义

图2所示的计算面包括计算控制部分、计算执行部分和计算数据的传输部分(计算传输部分)。其中，计算控制部分包括计算执行控制和计算连接控制—计算执行部分是指节点的计算执行功能利用计算控制分配的计算资源去执行计算任务的过程；计算传输部分是指不同节点的计算执行功能之间利用计算连接交互计算数据，从而实现不同节点协作完成计算任务。

图2 计算面-控制、执行、传输

2.2.1 计算控制部分

计算连接控制实时感知计算连接的状态，对计算连接进行连接资源控制、质量控制,并支持终端状态感知和移动性下的业务连续性保证；对传输计算数据所需的计算连接进行控制，如支持计算连接的建立、更改、迁移、重建、删除等过程，并支持连接资源的调配。

计算执行控制对节点计算执行功能使用的计算资源进行分配、控制执行的计算操作量、控制计算质量，并支持终端移动性。计算资源的控制实时感知计算资源的状态，控制计算资源的调配，如计算资源的添加、修改、删除、释放等；计算质量的控制根据资源量、精度和时延需求，编排计算操作，配置计算过程相关参数(如计算精度、量化精度、稀疏化等)；计算执行控制还支持终端移动性、计算资源地址管理功能、计算服务的接入控制、终端计算资源的控制，以及多计算资源聚合时的计算资源管理控制。

在多节点协作完成计算任务的场景中，计算连接的质量和计算执行的质量将共同决定整个计算任务的完成质量，因此存在联合优化的可能；计算连接与通信连接共享连接资源，将加剧连接资源状态的动态性，处于动态变化中的资源状态，会对计算质量产生实时的影响，需要联合考虑；对于执行计算任务且处于移动状态的终端，其计算连接和计算执行的控制将同步执行，计算连接与计算资源的状态和质量目标均将影响其切换决策。由此可见，计算面的计算执行控制和计算连接控制存在融合的需求和可能，即 “通算融合控制”。

通算融合支持通算相互感知、相互协同，实现计算资源和计算连接资源的合理分配。例如，通算融合控制可以通过计算资源的控制部分，实时感知用户移动性、用户动态环境变化导致的无线承载所需计算资源变化，从而实时调整计算资源；或通过计算连接的控制部分，实时感知计算资源状态，动态调整用户的连接带宽，从而持续地保证计算服务的QoS。例如，xNB上的通算融合控制功能可以完成终端与基站之间的计算连接管理，以及小区切换或添加辅小区时的计算接入控制。

2.2.2 计算执行部分

计算执行部分是指节点的计算执行功能在计算控制分配的计算资源上执行计算的过程。计算执行功能包括对底层异构计算资源的统一建模度量，对各类计算任务所需计算能力的统一换算，按照对计算操作的编排进行串行/并行计算，按照配置的精度进行计算、存储和量化处理等过程。

2.2.3 计算传输部分

在6G网络中，计算业务和通信业务将分属不同的服务类型，计算数据的传输承载与通信数据的传输承载(连接终端与DN的PDU会话包括终端与基站之间的数据无线承载，以及基站与UPF之间的GTP-U隧道)需要有所区分。同时，由于业务模型的不同，即计算数据在参与计算的网络节点间可能存在特别的交互模式(如终端与网络协作的模型分割推理或训练)，以及对连接质量可能存在特殊需求，当前5G网络面向eMBB、URLLC和mMTC场景设计的空口协议栈是否能够提供较好的支持需要研究。基于以上两点原因，因此存在面向计算数据的传输设计新型承载协议的可能性。

不同节点上的计算执行功能可以通过计算会话交互来计算数据。计算会话可以建立在计算无线承载、计算承载之上，其中：计算无线承载是指终端与基站的计算执行功能之间的数据传输通道；计算承载是指不同基站计算执行功能之间、一个基站不同部分的计算执行功能之间，或者基站与核心网的计算执行功能之间的数据传输通道。

2.3 关键技术问题

通信和分布式计算资源的高效协同，为用户提供更低时延抖动、更高综合效率的计算服务需要解决如下关键技术问题：

面向计算任务质量保障的高效协同如何通过通信和计算间高效协同的资源分配和质量控制机制，保障计算任务QoS的达成？

面向移动性支持的高效协同当计算任务涉及到终端的计算执行功能时，通算融合控制功能如何高效地控制计算执行功能、计算会话，从而降低终端移动性对计算任务QoS的影响？

3 关键技术设计

3.1 计算控制

6G网络架构原生支持通算的融合至少包括在控制面支持计算执行与计算连接的相互感知、相互协同，实现实时准确的计算资源发现、灵活动态计算资源以及计算质量的调度，提供无处不在的计算服务和连接服务，实现计算资源、连接资源的合理分配。融合控制功能对架构存在如下影响：① RAN(Radio Access Network)侧的计算执行、计算连接融合控制机制；② 核心网(Core Network)侧的计算执行、计算连接融合控制机制；③ 跨技术域(如RAN域、CN域、管理域等)的计算执行、计算连接的协同机制。

通算融合控制存在如图3所示的3种方式：

图3 通算融合控制选项

选项1计算连接控制与计算执行控制通过上层融合控制功能进行协调。例如，逻辑计算基站xNC(xNode-Compute)与连接基站xNB(xNode-Base- station)对等，xNB的RRC(Radio Resource Control)和xNC的CRC(Computing Resource Control)通过上层融合控制功能进行协调控制。其中，CRC用于控制xNC的计算执行功能占用的计算资源、计算操作量、计算质量等。这种方案的好处是允许上层通算融合控制功能覆盖范围内的大规模的xNB设备和xNC设备之间进行协调，部署方式更灵活，运营商可选择范围更大；缺点是上层外部接口时延较长，较难满足通算融合控制的实时性要求。

选项2计算连接控制与计算执行控制通过标准接口或内部接口进行交互。例如，xNB的RRC和xNC的CRC通过标准接口进行控制面交互[7,15]。这种方案的好处是允许xNB设备和xNC设备间异厂商连接，部署方式更灵活，运营商可选择范围更大；缺点是外部接口时延较长，较难满足通算融合控制的实时性要求。或者，基站xNB还包括计算执行功能，此时RRC和CRC通过内部接口进行控制面交互[7,15]。这种方案的好处是基站内部接口实现性能较好，且无线通信资源和计算资源的独立控制、按需调用，便于依据资源特性设计专用控制流程，也便于统计资源状态。此外，相比于选项1，选项2的设计更加扁平化，降低逻辑功能设计的复杂度。

选项3计算连接控制与计算执行控制也可以融合成一个控制功能，即融合控制功能。例如，基站xNB同时包括计算执行功能，RRC和CRC融合成统一的资源控制实体(xRC)，同时对计算连接和计算执行进行控制[7,15]。这种方案的好处是同时决定连接(包括通信和计算连接)和计算执行的控制决策，资源控制的协同和实时性最佳，但联合控制机制的设计较复杂。

3.2 计算传输协议

以RAN架构为例，如果将计算面引入RAN架构，如图4所示，计算面的控制包括计算执行控制与计算连接控制。

图4 计算面协议栈

一种可能的空口计算连接控制可以基于RRC现有协议机制来实现，即通过修改RRC协议或通过调用RRC协议的基本功能以支持计算连接的控制；计算执行控制由CRC实现，CRC可以与RRC独立(即融合控制的选项2)，也可以与RRC融合成xRC(即融合控制的选项3)。CRC用于控制计算执行功能占用的计算资源、计算操作量、计算质量等。一种可能的基站间(Xn口)的计算连接控制、计算执行控制可以基于现有Xn-AP机制来实现(调用或修改)。

传统通信的用户面连接用户与DN，计算面的传输部分用于无线网络系统内不同节点的计算执行功能之间传输计算数据，即计算面的数据不传输到DN，因此，计算面传输机制的设计需要与传统通信用户面有所区分。一种可能的计算面传输方式是承载层面引入新的承载方式，如空口部分的计算无线承载(Computing Radio Bearer，CRB)、Xn口部分的计算承载(Computing Bearer，CB)，并在会话层面引入新的无线计算会话协议(Radio Computing Session Protocol，RCSP)，此时计算会话又可以称为RCSP会话。

RCSP是一种无线网络内计算资源的高效数据通信协议，支持终端、基站或核心网功能的计算执行功能之间交互计算数据，从而支持不同节点间的计算协作，共同完成一个计算任务。计算任务的QoS由计算会话的QoS与计算执行的QoS共同确定。其中，计算执行的QoS受分配的计算资源、计算量和计算流程影响，基本的指标包括计算耗时和计算精度。计算会话的端点位置由计算执行功能所在的节点位置确定。例如，图5(a)所示的RCSP会话包括CRB，即终端与基站之间交互计算数据；图5(b)所示的RCSP会话包括计算承载，即不同基站之间、基站与核心网之间或DU(Distributed Unit)与CU(Central Unit)之间交互计算数据；图5(c)所示的RCSP会话包括CRB与计算承载，即终端与核心网之间交互计算数据。

(a) RCSP与CRB

如图5(a)所示，基站将为该终端创建一个或多个计算无线承载(Computing Radio Bearer，CRB)。一个RCSP会话可以映射到N个不同的CRB，不同的CRB提供不同的连接QoS能力，RCSP会话中不同要求的数据包需要根据自身的情况，选择不同特性的CRB。此外，考虑到不同RCSP可能有相同的QoS需求，因此N个不同RCSP会话中具有相同QoS需求的计算数据可以映射到一个CRB中；即当N个RCSP会话有N种不同的QoS的配置时，N个RCSP会话中不同QoS要求的数据包需要根据自身的情况，选择映射到N个不同特性CRB中的一个CRB。此外，如图5(b)、图5(c)所示，RCSP会话与计算承载之间是1对1映射。

xNB负责维护CRB与RCSP会话的对应关系，其作用是使得终端在发送上行计算数据到无线网络内部计算资源的节点时，可以通过选择对应的CRB，来实现最终的数据传送；而无线网络内部计算资源的节点在传送下行计算数据到终端时，也可以通过选择RCSP会话对应的CRB，来实现最终的数据传送。xNB在中间通过CRB和RCSP会话的映射，实现了数据在终端和部署在基站中的计算执行功能之间、基于RCSP协议的数据交互。

3.3 移动性支持

移动性管理是无线网络的一项基本功能，用于保证用户在移动的情况下享受无中断的服务。连接态移动性管理通常简称为切换，它是指为了保障连接态的用户在移动过程中能够持续接受网络的连接服务。切换过程包括切换准备阶段、切换执行阶段、切换完成阶段。

传统的切换准备阶段中，源基站发送切换请求时仅考虑用户的信号质量，目标站点根据自身的负载信息确定是否接收源站关于该用户的切换请求；通算融合的源基站(Source-xNB，S-xNB)下切换请求的触发原因除了用户的信号质量，还包括源基站计算资源的状态(如计算资源是否足够继续支持用户当前计算任务)，通算融合的目标基站(Target-xNB，T-xNB)在确定是否需要接受用户的切换请求时除了需要考虑目标站点通信资源情况，还需要考虑计算资源情况以及源站上的计算执行情况、计算迁移开销(包括通信开销、通信时延、QoS保障等)，通过通信资源、计算资源的统筹考虑来保证计算服务质量不受移动性影响。此外，传统的切换执行阶段中，源基站与目标基站之间只需要考虑连接的切换；通算融合的S-xNB与T-xNB之间除了需要考虑连接的切换，还需要考虑计算的迁移情况。

例如，图6所示的切换准备过程中，T-xNB在确定是否接受S-xNB的连接切换请求时，除了需要考虑自身的通信资源，还需要考虑计算资源、计算迁移的开销(包括通信开销、通信时延、QoS保障等)、S-xNB上计算任务的执行状态等信息。若T-xNB的计算资源足够，或计算资源资源与计算迁移开销两个条件同时得到满足时，则接受S-xNB的切换请求，切换执行过程涉及到计算迁移，如步骤3a所示，RCSP会话1更新为RCSP会话2(由CRB组成)；反之，切换执行过程不涉及计算迁移，如步骤3b所示，对应的RCSP会话1更新为RCSP会话3(由CRB 与CB组成)。

图6 计算迁移与连接切换解耦

4 实时协同验证

假设AI模型为VGG-13，用户的CPU是1核，基站计算资源的CPU是10核，数据集为Mnist，拆分推理的数据到达率为每秒30个样本，用户与基站之间的带宽从20 MByte/s变化到2 MByte/s。

用户与基站计算之间的拆分推理有两种模式：

模式1用户上传原始样本，由基站计算完成整个样本推理，用户与基站计算执行功能之间每次推理需要交互的样本大小为3.2 MByte；

模式2用户计算4个卷积层，基站计算完成VGG-13的剩余部分，用户与基站计算执行功能之间每次推理需要交互的特征向量大小为0.26 MByte。

以用户与基站的联合拆分推理应用举例，中心用户的信道容量大，用户可以计算神经网络的更少层，将输出结果及剩下层的计算交给基站计算，即用户与基站使用模式1完成推理服务；边缘用户的信道容量小，用户可以执行更多的计算层数，将输出结果及剩下层的计算交给基站计算，即用户与基站使用模式2完成推理服务。当用户信道条件发生变化时，或用户从小区中心移动到小区边缘时，如用户与基站计算资源的计算连接带宽从20 MByte/s变化到2 MByte/s时，用户与基站的计算连接与计算执行应该如何协同调整，以保证用户的推理服务时延比较小。

基于以上仿真假设，对比3种不同的协同调整方案。方案1是计算连接状态或带宽发生变化后，基站计算资源与用户计算资源的工作模式不做任何调整；方案2是通过能力开放的方式，计算资源的管理能力在感知到计算连接状态或带宽发生变化之后再调整基站计算资源、用户计算资源的工作模式，这种能力开放的方式，从计算连接状态变化到调整计算执行功能的计算模式，其调整时延比较长，通常为秒级；方案3是控制面融合的方式，例如在xRC(融合RRC与CRC功能)层，计算连接或计算执行在控制面相互感知，因此基站计算资源与用户计算资源的工作模式的调整时延可以降低到10 ms级别甚至是1 ms级别。上述3种不同协同调整的方案，其联合推理时延的仿真结果如图7所示。图7中，前33个推理样本的时延在170 ms左右，当用户带宽从20 MByte/s变化到2 MByte/s后，通过控制面协同调整仍然能保证推理时延在170 ms左右，时延抖动为8 ms；通过管理面协同调，能保证调整完成之后(即66个推理样本之后)的推理时延仍然在170 ms左右，但是存在一个管理面调整时延，在该调整时延内(即从33个推理样本到66个推理样本之间)，推理时延恶化到1 600 ms左右，时延抖动为1 442 ms；不做任何调整策略之后，推理时延恶化到1 600 ms左右。因此，图7所示的联合推理时延结果表明，相比于不调整或管理面的协同调整方案来说，控制面的实时协同调整方案能保障推理时延受带宽变化的影响抖动更小，可以更好地持续保证终端&基站拆分推理服务的QoS。

图7 实时协同

5 结束语

6G移动基础设施将从单纯的提供连接服务发展为同时能提供连接服务+计算服务的基础设施，可以满足AI所需的连接和分布式计算服务；并可能进一步基于AI的连接和计算融合控制需求，支持通算深度融合。

通算融合是指在控制面拉通计算资源与通信资源，支持分布式计算资源与连接的相互感知、相互协同，实现实时准确的计算资源发现、灵活动态的计算资源调度，提供无处不在、满足服务质量需求的计算服务和连接服务，实现计算资源、连接资源的合理分配，从而支撑AIaaS。通算融合在实现相应功能时能够综合考虑空口状态信息、网络状态、计算资源分布等信息以达到性能的最优化或者资源最小消耗。在终端&基站联合拆分推理的场景下，实验结果表明控制面的通算协同调整方案能大幅降低业务的时延抖动。

致谢:特别感谢6GANA提供通算融合研讨的平台，在研讨过程中不断拓展思路，从而支撑计算面关键技术设计的丰富与完善。