无线通算融合思考1——从需求出发

0、前言

技术由浅入深是具有发展路线的，无线通算融合则可以看作现在研究比较火热的算力网络的更为深入的技术。

算力网络从承载网的角度实现各地区分布的节点算力路由和共享，算力的提供者或执行计算的节点更偏向于服务器、计算机等，如集中式云和分布式云。
在这个过程中，承载网充当搬运工的身份，要做的即是感知各个云的计算能力，通过对计算任务的执行节点、传输策略和资源配置进行管理，来实现对多用户多计算任务的统筹规划，从而实现东数西算这样灵活按需的计算资源分配的效果。
因此，算力网络中研究要点其一为算网协同网关的设计和部署，以解决各个云的算力注册和感知、网络资源的注册和感知、用户需求感知；其二为算网协同调度机制，以解决用户需求到网络资源和计算资源的映射和配置。

也就是说，算力网络中，组成承载网的通信节点设备只是参与数据的转发，这些数据或是计算任务、或是计算任务的结果，并不参与计算任务的计算执行，真正的计算过程仍然在各个云当中完成。
由此，为了进一步加深通信和计算融合，无线通算融合应运而生。

1、概念解析

物理融合：无线通算融合，顾名思义，即无线侧通信和计算融合。不同于算力网络中提供算力的服务器、计算机等，组成无线网络设备节点成为可提供算力的基础服务设施，为用户提供就近、实时且泛在的计算能力。这是最为直观的理解，也是物理意义上的融合。

功能融合：若是从功能层面上来理解，无线通算融合应该是要达到两者功能相互促进的作用。一方面，无线网络为用户提供就近、实时且泛在的算力，为用户终端扩展算力，提升计算任务KPI，如降低计算时延；另一方面，从无线网络侧抽象出来的灵活可调配的计算资源（算力、算法等），可通过资源的有效配置，支撑不同通信条件下性能较优的物理层、高层的无线通信算法，从而提升无线网络性能。

当然，需求引领技术发展，上述无线通算融合的观点若是没有需求作为导向，也只能是空中楼阁。

2、需求分析

目前业界对于无线通算融合的需求分析主要分为两个方面：

a）计算需求——通信for计算

该方面主要从计算需求来分析为什么无线网络要提供计算能力服务（通信for计算）。

用户角度

算力需求逐年增加，且对计算任务的需求以低时延+中/低CPU核数的需求为主——阿里云数据

用户的计算需求增加，其典型用例就是沉浸式XR、车联网，此时：
1、用户终端自身算力不足；
2、各种云计算传输时延高；
以上两点触发了用户对就近、实时的算力需求。

场景角度

随着芯片算力和算法增强，未来的车辆可能无需基站侧或云侧提供计算服务，但仍需要基站侧的就近算力来支撑车路协同中感知信息和高精地图的低时延处理。

基站侧需要可支配的算力支撑车路协同、物联网等场景下，多个终端的数据在基站侧所进行的低时延计算处理任务，此时：
1、基站侧算力资源架构固定，仅服务于通信算法过程，算力资源通常“尽力而为”；
2、各种云计算传输压力大，时延高；
以上两点触发了基站侧对实时可支配的算力需求。

运营商角度
目前已经部署的基站通常服从“28定律”，即20%的基站解决了80%的用户需求，突出资源不均衡，大部分基站处于空闲状态。因此，通过已部署在中华各地的基站实现泛在计算，也能使运营商进入互联网企业的云服务的赛道，甚至由于运营商本身基站大范围部署的优势，可以在传统云服务的赛道中走出一片新天地，用户得到了就近实时且泛在的计算能力服务，而运营商则获得了利润。

b）通信需求——计算for通信

该方面主要从通信需求来分析为什么无线网络需要计算支撑（通信for计算）。

现阶段影响网络性能的因素有很多，排除人们难以掌控的外界因素如信道条件，直接影响通信吞吐量的就是通信算法。

比如物理层的编解码，高层的资源调配算法，这些算法都需要算力支撑，而目前基站侧算力不足，难以支撑复杂的资源调度算法，从而导致目前应用的5G基站仍然采用的传统的资源调度算法，因此若当基站侧算力能够抽象出来可供调度，基站侧就能根据现有信道等通信条件和算力条件，选择合适的物理层或高层的算法，从而使得算力用在刀刃上，提高整体网络性能。

目前学术界各个大学又开始讲目光放到6G与AI融合上，产生出了物理层AI编解码、基于AI的资源分配算法，而支撑一个自适应的AI模型，就需要基站侧拥有足够的算力来支持模型训练，且也只有贴近用户侧，才能将AI模型训练得贴近需求。

因此，无线网络需要计算支撑，且足够的算力能提高无线网络性能。

3、问题思考

无线通算融合的一个主要目的是为用户提供就近、实时且泛在的计算能力。然而目前基站侧算力仅仅支撑现有的低复杂度的通信算法，就这样算力还仍缺少。我连自己的算力需求都难以满足，为什么还要满足你用户的算力需求？

亚信科技实现了BBU的虚拟化，通过时分复用和核分复用来共享计算资源，从实验结果上虽然证明了资源利用率很高，可以提高能效。但是并未说明对通信性能的影响，难道本来仅用于通信的情况下基站侧BBU的计算资源利用率就不高？这若是如此，必然与计算过程或架构有关了

若是要同时满足用户和基站通信的两者需求，基站侧算力扩展必不可少，架构也应当重新考虑设计，这也大概是大家都在研究的问题吧！

以上为我在近期对无线通算融合调研过程的思考，大家有什么问题和想法，欢迎讨论！