从边缘智能迈向泛在智能

1、为什么我们需要泛在智能：万物互联的必然趋势

 

泛在智能概念的提出是建立在边缘智能技术和应用蓬勃发展的基础之上。基于万物互联的快速发展态势，今年8月末，中国物联网的终端用户数量已经超过移动电话用户数量，使得我国成为全球主要经济体中率先实现“物超人”国家。随着新基建和智慧城市建设的不断深化，物联网的器件数量将会大幅度地超越当前情况。

在IMT2030推进组的报告里也提到[1]，未来6G移动通信系统会有八大不同的应用场景，如图1所示，其中的普惠智能和数字孪生场景是我们今天讨论的重点。

图1 6G移动通信系统的八大应用场景[1]

为了实现这样的应用愿景，6G系统需要部署大量的、泛在的计算资源来承载普惠智能。所以，我们必须要思考在边缘计算之后，普惠智能的需求会遇到什么样的挑战和困难？由于人类社会是大自然创造的最优秀最聪明的智能网络，所以我认为未来的普惠智能服务将会构建在一种分层次、分布式的算力网络之上。

这样，大量高冗余度、低质量、低价值的本地物联网数据就可以利用边缘和网络中的分布式计算资源来及时处理，从而显著提升用户服务质量、数据安全性和响应时效性，降低了必须要传输到云端的数据量，同事减少了能量消耗。目前，在网络里有很多计算资源还没有被完全地利用起来，通过GECC社区所有人的共同努力，我们可以逐步实现云网边端所有计算资源的协作与管理，支撑无处不在的普惠智能应用愿景。

在21年10月的开发者创新大会上，英特尔公司在边缘计算和算网架构方面提出了四大战略方向[2]，

图2 英特尔公司提出的四大战略方向[2]

分别是Ubiquitous Compute（泛在的计算）、Pervasive Connectivity（遍布的链接）、Cloud-to-Edge Infrastructure（云到边的算力架构）、以及Artificial Intelligence （人工智能）。它们合在一起，就构成了泛在、普惠的智能服务架构，能够把边缘、网络、以及云端的海量计算资源都有效管理和调度服务，实现为用户、为需求所用。这与我们做泛在智能的想法不谋而合。

 

2、怎样支持泛在智能：Network AI Architecture

 

当前的云管边端架构将算力资源和智能算法主要集中在云端，不太适合及时处理海量的物联网数据。为了支持泛在智能服务，我们需要创建一个新型网络架构，能够灵活利用云、网、边、端等多层次、分布式的泛在计算资源。我们在2018年的论文[3,4]中提出了这个类似八爪鱼的网络架构，其中白色的圆圈表示网络中的空闲计算资源，它们是与应用软件解耦合的。八爪鱼的触角越往下颜色越深，这意味着这些共享的泛在计算资源已按需被软件定义成不同的功能和作用，从而更有效地去服务千差万别的应用场景，比如：智能机场、智能制造、车联网、智能交通等等。

当某个应用场景的特定服务结束后，相应的计算硬件和智能软件的耦合与协作状态解除，就可以释放这部分被占用的计算资源，让它们重新恢复白色空闲状态。这样就能够充分发挥本地和区域内多层次、分布式计算资源的共享优势和协作能力，更加灵活、弹性、智能地服务未来不确定的应用场景和用户需求，服务未知的环境状态和变化的用户需求体现了网络架构智能化的水平。

图3 多层次泛在计算的智能网络架构[3]

在2019年9月，芬兰科学家提出了6G移动通讯网络的泛在无线智能架构[5]，将边缘计算节点、雾计算节点和移动通信网络结合在一起，目标是把物理世界和数字世界完全融合，能够用无处不在的计算资源来满足用户千差万别的个性化服务需求。

图4 联通CUBE-Net 3.0架构[6]

在去年3月，中国联通发布了CUBE-Net3.0网络架构[6]，包含了边缘DC，区域DC和基地DC，这些计算资源是分层级、分布式部署的，要根据数据量、服务覆盖范围和任务复杂性等做出合理分配和调度管理。这样做的本质上是将计算资源下沉，实现智能服务的本地化和低时延，提升用户满意度。

中国移动在去年11月发布了算力网络白皮书[7]，提出了算力网络架构发展的三个阶段，即泛在协同阶段、融合统一阶段、以及一体内生阶段。最终，通信和计算在未来的智能网络架构中是不可分割的，这是我们努力的方向和目标。

在学术界和工业界许多资深专家的指导下，我们在今年7月份提出了一个网络智能架构（Network AI Architecture）[8]。图5展示了云智能、边缘智能和网络智能服务的差别。红色虚线标出的云智能服务高高在上，要等所有的用户数据和任务通过移动通信网络传送到云端进行分析和处理。绿色虚线标出的边缘智能服务利用了外挂式的本地计算资源，通常与通信网络是割裂的，用户数据和任务要经过移动通信网络的传输才能到达边缘计算节点。就算这个边缘计算节点就在你身边，对不起，数据还是要通过移动通信网络兜一圈才能为你提供边缘智能服务。

图5 以每个用户为中心的网络智能架构[8]

在蓝色虚线标出的网络智能架构中，为了实现真正的AI内生，需要将泛在计算资源与移动通信网络深度融合在一起。我们提出的方案是采用多功能节点（mNode: multi-function Node）来替代所有网元，每一个mNode都集成了感知、存储、通信、计算、控制和AI算法等多种能力（如图3中的白色圆圈），通过软硬件解耦合和网络功能虚拟化技术来实现传统基站、路由器、交换机和服务器的不同功能，真正达到了感存通算控智等综合能力的深度融合和灵活运用。就好像社会中的每个人，既要能够干活（计算能力），也要善于沟通（通信能力），又要了解工作环境（感知能力），还要始终不忘初心（存储能力）。

为了更好地管理和利用多层分布的mNode，我们设计了两个控制单元。其中，NALC（Network AI Logic and Control）单元负责本地和区域资源的调度和管理，保障用户的实时和准实时服务需求；NAMO（Network AI management and Orchestration）单元负责跨领域和外挂式资源的调度和协作，保障用户的高强度算力资源需求。这种基于多层次计算资源的网络架构可以有效支持泛在智能的服务需求，能够突破当前的烟囱式、碎片化物联网服务模式，充分复用网络中的软硬件资源和系统功能，只需要针对不同行业嵌入特别的领域知识，就可以开发出物联网的新应用和新服务，从而大大缩短了研发周期，并降低了系统复杂性和研发成本。

 

3、如何评估网络智能架构的性能：服务用户业务定制的能力

 

通信工程师传统上非常注重系统侧的性能指标，比如：频谱效率、能耗效率、服务覆盖率、系统吞吐量、以及用户容量等。在物理世界里，我们习惯于先将用户或场景进行分类（比如：移动用户或静止用户，语音用户或数据用户，eMBB/uRLLC/mMTC应用场景），然后为不同类型的用户提供不同的标准化服务，这样做的服务效率和性价比最高。这就像一款夹克会分为XL/L/M/S等号码来适应不同体型的用户需求。相反，定制化服务在物理世界中会耗费更多人力、物力和时间，往往非常昂贵。

而未来的数字世界里[9]，每个用户都有自己的数字孪生和数据仓库，定制化服务将成为新常态和新标准，现在的许多移动互联网应用已经可以根据每个用户的浏览和购买记录来推送类似的新闻或者商品。在充分保护用户数据安全和个人隐私的前提下，每个用户在数字世界中都会积累越来越多的行为数据和模型，从而将智能服务的颗粒度从一组同类型用户缩小为每个用户，这将是源自用户侧需求的根本性变化。

定制化服务是为了充分满足每个用户的个性化需求，具有多样性和复杂性，往往包含了多个用户侧性能指标的组合。比如打互动性很强的网络游戏时，用户会同时要求低时延（响应快捷）、高速率（图像清晰）、高可靠（体验稳定）、低功耗（服务时间长）、以及少收费（性价比高）等等，她/他不会因为是坐在高铁里打游戏，就降低对服务质量和用户体验的要求。所以，用户侧（需求侧）关心的性能指标与系统侧（供给侧）的性能指标是很不一样的。

每个用户的个性化服务需求是由一系列用户侧性能指标的上限和下限来描述的，比如，数据速率和可靠性指标肯定是下限，越高越好；服务时延、能耗和费用肯定是上限，越低越好。每个用户的不同业务都会有一个专属的服务需求区间（Service Requirement Zone, SRZ），可以用雷达图来清晰展示这个个性化、多维度的新概念。如图6所示，除了打游戏的SRZ，每个月初我都会第一时间把工资转给我太太，在移动银行转账业务的SRZ中，我对安全性要求特别高，对服务时延要求没那么高。转账时间稍微长一点没关系，能看见这个数字在我的账号里多停留一秒钟，也是让我多开心一会儿。

 

图6 互动网络游戏与移动银行转账的服务需求区间[8]

我们认为要客观公正地评估云智能、边缘智能、或网络智能架构到底好不好，最简单、最根本的方法就是测试和验证它是不是能同时满足大量用户的个性化、定制化、多维度的服务需求区间 SRZ要求，也就是能同时支持多个用户不同的业务性能指标组合，如图7所示。虽然这些性能指标单独看起来没有那么高，但是要做到让每个用户都满意的定制化服务，就必须要同时满足为各个用户量身订制的多个性能指标，这实际上是一个很高的要求。

因此，我们把用户满意率（User Satisfaction Ratio, USR）作为评估网络智能架构能力的最简单、最公平的系统侧核心性能指标，即在所有已服务过的用户中，完全满意用户的比例。USR客观反映了用户的整体服务体验，既可以用于分析多个用户的不同任务满意率，也可以分析同一个用户的多个任务的满意率。

图7 智能系统的用户满意率[8]

为了公平比较，在图8中，我们对云智能、边缘智能和网络智能架构进行了统一建模，同时考虑了多层次的计算资源（C1、C2、C3和CC）和通信速率（R1、R2、R3和RC），所以每个用户不同业务的执行要同时低于端到端的时延（通信时延+计算时延）和能耗（通信能耗+计算能耗）的上限要求。换言之，只有同时满足了这两个性能指标，用户才是满意的，USR才能得到提升。

图8 通信计算一体化的网络智能架构模型[8]

图9和图10分别展示了用户业务密度、计算需求、业务大小和网络通信速率对于用户满意率的影响。

图9 业务密度和计算需求对USR的影响[8]

图10 业务大小和网络通信速率对USR的影响[8]

在两种不同的业务调度算法下（TCTB和FES），与集中式的云智能架构相比，边缘智能和网络智能架构分别建立在两层次和多层次的分布式计算资源之上，可以有效支持每个用户各种类型的业务达到更高的服务满意率。

作为总结，今天我们在用户侧和系统侧分别提出了“服务需求区间SRZ”和“用户满意率”的概念和指标，用于评估支持泛在智能的网络架构的定制化服务能力。如同GECC这个温暖的大家庭，我们不会把所有事情都交给会议主席一个人去处理（无法确保响应时间），也不会把所有事情都交给会务公司去处理（无法确保技术报告质量），而是要利用GECC核心骨干成员每个人的能力和资源，通过协作互助模式更好地为所有与会者服务，在效果、质量、效率和费用之间取得最好的平衡。