6G服务化RAN白皮书2.0.pdf

中国移动通信集团有限公司中国移动通信集团有限公司编制单位编制单位：中移智库中移智库、中国移动通信研究院中国移动通信研究院、中国电信股份有限公司中国电信股份有限公司研究院研究院、中国联合网络通信有限公司研究院中国联合网络通信有限公司研究院、中信科移动通信技术股中信科移动通信技术股份有限公司份有限公司、亚信科技亚信科技（中国中国）有限公司有限公司、联想研究院联想研究院、中国科学院中国科学院计算技术研究所计算技术研究所、北京邮电大学北京邮电大学、中关村泛联移动通信技术创新应用中关村泛联移动通信技术创新应用研究院研究院6G6G 服务化服务化 RANRAN 白皮书白皮书（2022023 3 年年）中国移动6G 服务化 RAN 白皮书（2023）前前言言5G 核心网革命性地将服务化架构作为网络基础架构，实现了网络功能的可独立扩容、独立演进、按需部署，并在持续推动服务化功能与框架的增强与优化。6G 将在 5G 的基础上，围绕“领域拓展、机制深化、要素扩展”三个维度，开展全服务化设计。领域拓展方面，服务化机制将向无线接入网扩展，从接口服务化向功能服务化分阶段展开；机制深化方面，将在现有 5G 服务化基础上，进一步探索服务解耦和服务调用效率提升；要素扩展方面，进一步引入 AI、计算、数据等要素，推动 DOICT 的深度融合。服务化 RAN 是实现全服务化设计的关键。中国移动、中国电信、中国联通、中信科移动、亚信科技、联想、中科院计算所、北京邮电大学、中关村创新院一直在积极推动业界对服务化 RAN 的研究与思考，6G 服务化 RAN 白皮书 2.0（2023）作为6G 服务化 RAN 白皮书（2022）1的继承与延续，旨在分享服务化 RAN 最新的研究思路，包括服务化 RAN 的定义、架构模式、设计思路、端到端流程等，供业界同仁参考。中国移动6G 服务化 RAN 白皮书（2023）目录目录一、一、服务化服务化 RAN 是实现云原生是实现云原生 RAN 的关键的关键.1二、二、服务化服务化 RANRAN 应用场景应用场景.3三、三、服务化服务化 RAN 相关概念相关概念及定义及定义.33.1 云化 RAN 与云原生 RAN.33.2 微服务架构与基于服务的架构.43.2.1 常见架构模式对比.43.2.2 服务化 RAN 的架构模式.63.3 服务化 RAN 的定义.7四、四、服务化服务化 RAN 体系化设计体系化设计.84.1 服务化 RAN 演进路线.84.2 RAN 控制面服务化.94.2.1 NF 及 NF service 定义.94.2.2 RAN 基本方案.104.2.3 RAN 与 CN 联合设计.114.2.4 RAN 与 UE 之间的交互.134.3 RAN 用户面服务化.144.3.1 NF 及 NF service 定义.144.3.2 基本问题与方案.154.4 服务化演进.184.4.1 多维能力服务化.184.4.2 架构模式灵活化.194.4.3 软硬件联合优化.204.4.4 运维管理智能化.20五、五、关键挑战关键挑战.21六、六、总结总结.21缩略语列表.22参考文献.23中国移动6G 服务化 RAN 白皮书（2023）1一、一、服务化服务化 RAN 是实现云原生是实现云原生 RAN 的关键的关键为了满足多样化业务对网络的敏捷性、灵活性和可扩展性的要求，网络向虚拟化、云原生化转型已是必然趋势，云原生 RAN 也得到了全球运营商的广泛青睐。云原生 RAN 有助于运营商构建高成本效益、高运营效率、绿色、全自动化无线网络，并为客户提供创新服务。与其他云原生架构相似，容器化、微服务架构和 Kubernetes 编排是云原生RAN 的核心特征。容器化与 Kubernetes 编排更多地是实现方式，微服务架构则体现为功能的重构。基于微服务架构，RAN 被构建为松散耦合服务的集合。每个服务都执行特定的功能，可以独立开发、部署和扩展，也可以在任何基础设施和容器平台上开发、部署、扩展2。但微服务架构并不是 RAN 改造过程中可以采用的唯一架构模式，因此先将面向云原生设计原则进行功能改造的 RAN 称为服务化 RAN，在第三章中将给出服务化 RAN 的定义以及采用架构模式的建议。具体地，服务化 RAN/云原生 RAN 的驱动力大致可以包括使能 6G 网络与赋能行业应用两个方面：1、在在赋能赋能业务应用方面：业务应用方面：能力开放共享能力开放共享：RAN 能力需要开放给更多网络功能或第三方应用，以更好赋能行业应用。通过 SBI 直接开放可以避免过多的 P2P 接口定义及不必要的AMF 透明转发、提升通信效率，因此被看作是服务化 RAN 的核心价值之一。具体包括，RAN 与 UCMF/LMF/NWDAF 之间的通信，RAN 节点之间的信息传输（如 RIM/SON 配置）。虽然通过定义 P2P 接口也可以实现 RAN 与这些功能之间的直接交互，但 SBI 可实现接口的快速建立、调整与故障恢复，避免新增功能和服务时定义过多的 P2P 接口以及 P2P 接口建链复杂等问题。此外，基于 SBI的通信可以使 RAN 服务开放给更多的节点，如在未来通信、计算、感知、数据、AI 深度融合的网络中，通信、计算、感知、数据、AI 等网络功能可能都需要类似的 RAN 信息服务，以便于提升各维度的 QoS 性能。用户体验提升：用户体验提升：邬贺铨院士曾指出，行业应用是 6G 研究的重点，6G 网络需要具备灵活适配 2B 场景定制化需求的能力。5G 面向 eMBB、uRLLC、mMTC三大场景提出了相应解决方案，但在实际落地时依然困难重重，主要挑战在于不同行业客户需要不同维度的极致性能和定制化能力，同时要求成本可控、敏捷部中国移动6G 服务化 RAN 白皮书（2023）2署、使用简便、算力按需扩展、二次开发定制。5G 单体基站架构面向 2C 进行设计，不可能同时满足这些需求，如果依然沿用 5G 的研发思路，行业应用的痛点问题必然得不到解决。服务化 RAN 因其具备弹性扩缩、按需组合、敏捷开发等能力，是解决行业痛点问题的主要解决方案。激发新业态激发新业态：服务化将使能第三方功能的灵活嵌入到 RAN 的处理过程中，实现跨层优化，进而可能引入新的商业模式。随着通信与计算的深度融合，RAN将为第三方提供定制化的计算服务，允许第三方在处理链路上嵌入必要的计算功能而非 MEC 的外挂实现方式，从而优化用户体验。例如，对于云游戏、云 XR、全息通信等 6G 典型业务，可以在 RAN 处理过程中引入第三方视频帧帧调速服务，使业务特征可以更快速地适配无线链路状态。2、在使能、在使能 6G 网络方面：网络方面：一体化管理一体化管理：服务化 RAN 将实现与服务化 CN、IT 支撑系统等的一体融合管理，降低网络运维管理复杂度。在电信行业，云原生理念及其技术以灵活性、敏捷性和便捷性已获得电信行业的广泛关注，已初步引入到 5G 核心网、并在逐步向其他子域扩展。除业务系统之外，电信运营商的运营和运维管理等 IT 支撑系统也正在逐步引入云原生的设计理念（如微服务、容器、DevOps 等），以适配电信业务的快速发展需求、高效可靠的平台需求、敏捷快速的运营运维需求。基于云原生的电信系统一体化管理将大大降低管理复杂度。极简网络设计极简网络设计：服务化 RAN“高内聚”“松耦合”“无状态设计”等基本设计原则，将助力实现网络协议的轻量化设计。例如，面向大量低成本和低复杂度终端（例如零功耗终端），基于无状态管理模式或者弱状态管理将更有助于高效的小数据传输。高内聚的功能服务设计，可降低标准化开销，避免在不同协议层引入类似功能导致的协议栈功能堆叠和低效。创新速度加快：创新速度加快：服务化 RAN 将助力实现 RAN 新功能的快速引入，旧功能的快速迭代演进，满足市场需求。从功能角度，目前 BBU 开发的最小粒度为CU 或 DU，颗粒度较大，如果需要对 CU 或 DU 进行更新，则需要以 Release 为单位开展标准化工作，软件更新时间最短需要 2 年。但软件功能上线速度将直接影响市场占有情况，这将使网络不能及时满足行业应用需求，降低基础设施的价值。虽然可以通过缩短 Release 周期缩短标准化和产业化时间，但这会降低网络中国移动6G 服务化 RAN 白皮书（2023）3的稳定性。而通过服务化设计，新功能将以高内聚与松耦合的服务形式出现，避免了对已有功能服务的影响，保证了网络稳定性。由此可以实现功能服务稳定地敏捷开发、快速引入、按需迭代演进。网络成本优化网络成本优化：在网络建设成本和功耗方面，RAN 服务化基于云原生基础设施平台，将实现硬件资源池化共享，并在传统云化的基础上，通过“功能服务级别”的弹性扩缩容进一步实现网络资源利用率的最优化，由此大幅降低网络建设成本和以能耗为主的网络维护成本。二、二、服务化服务化 RANRAN 应用场景应用场景服务化 RAN 最重要的特征是敏捷部署与按需服务，其价值在于提升网络的包容性与经济性，这是与始终关注高性能的传统 RAN 最大的不同。因此，需要敏捷开发/迭代演进/按需部署的场景、以及需要差异化定制网络能力的场景是服务化 RAN 的主要应用场景。例如：行业行业应用应用场景，提供按需定制服务场景，提供按需定制服务：服务化 RAN 可面向场景需求进行极简网络的定制，对网络服务能力与资源进行动态编排与调度，包括与智能、计算等多样化增强服务的组合，支持智慧城市、工业自动化、全息通信、物联网、车联网等应用，将场景适配网络转变成场景定义网络。应急通信和受灾场景应急通信和受灾场景，实现快速部署实现快速部署：服务化 RAN 可通过软件定义和虚拟化的方式快速部署，带来网络弹性和自适应性优势，可以用于灾难恢复和临时通信网络场景，迅速适应网络需求的变化，同时服务化 RAN 可以智能地管理和优化资源，满足紧急通信需求，确保关键通信的优先级。三、三、服务化服务化 RAN 相关概念相关概念及定义及定义3.1 云化云化 RAN 与云原生与云原生 RAN核心观点：云原生（计算）是云计算的再升级。微服务架构核心观点：云原生（计算）是云计算的再升级。微服务架构 MSA 重构是云重构是云原生原生（计算计算）相比云计算的核心区别之一相比云计算的核心区别之一，也是未来云原生也是未来云原生 RAN 相比于现阶段相比于现阶段云化云化 RAN 的核心区别，将有助于的核心区别，将有助于 RAN 软件更好使用云原生平台的优势。软件更好使用云原生平台的优势。云化 RAN 是未来的必然发展趋势。RAN 是电信运营商最大的资本支出和运营支出项，在总拥有成本（TCO）中的份额正在从 45%-50%上升到 65%；同时也是利用率最低的资源，大多数基站的使用率通常低于 50%3。将 RAN 的计算中国移动6G 服务化 RAN 白皮书（2023）4迁移到云中能够享受云计算带来的众多好处，例如，通过云基础设施共享可以提高利用率，从而帮助运营商最大程度地减少 CAPEX 和 OPEX，此外，将 RAN软件从硬件中分离出来并部署在云中能够加速新技术的创新和增值服务的推出。现阶段的云化 RAN 更多的是基于云原生技术的实现，通过容器编排等技术简化网络管理流程，提高运维效率，降低站点功耗。这种简单的云端迁移方案（即Re-platform 模式）并没有重构 RAN 软件架构，只是对集中式单元 CU、分布式单元 DU 进行了模块化设计和容器化打包与部署，即只改变了软件运行的平台和运维的技术体系，因此软件在分布式场景下需要解决的问题，如组件或服务之间的数据同步、稳定性、资源利用率不高等问题都需要自行解决4。只有将 RAN软件进行重构（即 Re-build 模式）并充分考虑云原生设计原则（如微服务设计模式、存储状态分离等），即实现云原生 RAN 设计，才能充分利用云原生基础设施所带来的独立部署、按需扩缩、可观测性、高可用等技术优势，从而实现网络资源利用率、成本效率、稳定性的最优化。3.2 微服务架构与基于服务的架构微服务架构与基于服务的架构3.2.1 常见架构模式对比常见架构模式对比核心观点核心观点：基于服务的架构基于服务的架构（Service-based architecture，SBA）是一种融合是一种融合了单体架构和了单体架构和 MSA 的混合架构风格，相比的混合架构风格，相比 MSA 可以专注领域和功能的拆分，可以专注领域和功能的拆分，暂时不对数据库进行分解。暂时不对数据库进行分解。SOA、MSA、SBA 是三种常见的分布式架构模式，其目的均是构建松耦合的服务，以提升架构的灵活性、可扩展性以及对业务的敏捷适应性5。因此，其基本设计原则是一致的，具体包括：-服务具备明确定义的标准化接口，实现服务消费者和服务提供者之间的解耦；-服务是松耦合的，服务之间不应存在时间、技术、团队上的依赖；-服务是无状态的，实现服务调用与会话上下文状态的解耦；-服务是自治和自包含的，由此可以实现服务的独立部署与升级；-服务是可发现、可组合的。如表 1 所示，从 IT 领域发展路径来看，面向服务的架构设计经历了从 SOA中国移动6G 服务化 RAN 白皮书（2023）5到第一代 MSA、第二代 MSA、再到现阶段的第三代 MSA 的演变，正在朝着基于 Serverless 的第四代 MSA 演进6。5GC 标准化采用的 SBA 架构模式，可以看作是单体架构和 MSA 的折中，是一种混合架构风格7，服务划分的粒度相比微服务更粗。服务在 SBA 中与在 MSA 中遵循相同的设计原则（基于领域驱动的限界上下文），区别是 SBA 中的服务依赖同一个关系型数据库。因此，SBA 通常可以看作是 MSA 改造的第一步，当然也可以看作是系统架构改造的最终目标。SBA 相比 MSA 有两个核心区别特征：一是 SBA 允许多个服务间共享同一个单体数据库，降低了 MSA 中的一个复杂度数据库级别的隔离，使得 SBA 在架构上既有单体架构的特点，也有分布式架构的特点；二是 SBA 不允许服务间通信，这与 MSA 有本质的区别8。5GC Rel-15 SBA 主要参考第二代 MSA 进行设计，引入 NRF 实现服务的注册与发现；Rel-16 SBA 参考第三代 MSA 引入服务通信代理 SCP，并设计了间接通信机制。整体来讲，SBA 是随着 MSA 的演进而迭代发展的。随着第四代 MSA的出现，SBA 也可能需要做适应性改造，以更好利用云原生平台优势。表 1：几种常见架构模式比较SOA第一代 MSA第二代 MSA第三代 MSA/云原生架构云原生时代微服务架构架构示意目的解决大量竖桶型存量系统复用问题，提升架构灵活性、扩展性，提升业务敏捷性应对互联网规模的快速增长问题，并且能够快速迭代，低成本试错解决第一代 MSA 寻址等问题解决第二代架构中多语言支持问题特点引入集中式企业服务总线(Enterprise Service Bus，ESB)提供服务之间的连接，转换,以及中介处理能力核心思想是应用功能的解耦，每个服务遵守单一责任原则（Single Responsibility Principle）；使用去中心化分布式架构风格来替代 ESB引入服务注册中心实现服务注册与发现；服务之间的通讯以及容错机制开始模块化，形成独立服务框架Service Mesh（服务网格）出现，原来被模块化到服务框架里的微服务基础能力被进一步从一个 SDK 演进成为一个独立进程-Sidecar，微服务基础能力演进和业务逻辑迭代彻底解耦中国移动6G 服务化 RAN 白皮书（2023）6优势实现了业务逻辑与服务集成的解耦每个服务可独立部署和交付，大大提升业务敏捷性；每个服务可独立扩缩，应对互联网规模的挑战问题IT 系统架构未改变，导致大量服务集成的实现逻辑被下沉到 ESB 内部，这些逻辑非常难以维护，无法保证业务敏捷、架构可扩展的需求服务除了要实现业务逻辑，还要解决寻址等问题随着服务框架内功能日益增多，用不同语言的基础功能复用显得十分困难，这也就意味着微服务的开发者被迫被绑定在某种特定语言上，从而违背了微服务的敏捷迭代原则增加部署复杂性（sidecar）和损失性能（增加两跳）业务逻辑与服务治理逻辑又耦合在一起在5G网络中的应用Rel-15 SBARel-16 eSBA3.2.2 服务化服务化 RAN 的架构模式的架构模式核心观点：服务化核心观点：服务化 RAN（至少）初期（至少）初期将将采用采用 SBA 架构模式，功能上采架构模式，功能上采用用NF+NF service 两级划分两级划分，NF service 提供对外可调用的服务提供对外可调用的服务，NF 层面实现内部层面实现内部多个多个 NF service 之间的上下文共享。之间的上下文共享。微服务架构改造涉及功能拆分和数据库拆分两部分内容。在功能拆分方面，IT 领域通常使用绞杀者模式将一个一个单体架构功能重构为微服务，并优先考虑将新增网络能力设计为微服务9。但这种逐一功能拆分方式可能并不适用于RAN，因为现阶段大部分基站采用专用硬件实现，每个标准版本只定义几个服务会增加由于前向兼容性带来的系统复杂度，因此 RAN 软件架构改造初期最好采用粗粒度的拆分方式，后续迭代优化。在数据库拆分方面，理想的数据库模式是每个服务有自己的数据库，只读写与访问自己的数据库。但从单体到理想模式改造力度较大、存在风险较大，既涉及海量历史数据的迁移问题，也涉及跨库的事务处理、跨库的关联查询等技术难题，因此通常初期会采用数据共享模式10。考虑到 RAN 内部上下文之间的耦合关系，服务化 RAN 改造初期也可以先采用数据共享模式，类似 5GC SBA 的“NF+NF service”两级设计，同一个 NF 内部的多个 NF service 之间数据共享，仅中国移动6G 服务化 RAN 白皮书（2023）7需要考虑 NF 之间的上下文拆分即可。图 1：数据库模式对比5GC SBA 改造通过两步实现：第一步是功能重构、软件化，将 4G 的“网元”重构为 5G 的“网络功能”，实现软件定义的网络功能和连接。第二步是服务的设计，借鉴 SOA、微服务等理念，面向云原生定义基于 API 接口调用的网络功能服务 NF service11。CN 网元是面向特定功能的，因此第一步对网络功能进行“高内聚”重构是合理且较易实现的。但 RAN 节点（如 CU、DU）囊括了多个无线功能且功能之间紧耦合，先拆分 NF 并不一定适用于 RAN。因此在做 RAN 服务化时，可以考虑先定义服务，再基于服务之间的紧密程度、上下文耦合性等，将服务聚合为 NF，而无需一定要像 5GC 一样采用相同的改造步骤。3.3 服务化服务化 RAN 的定义的定义核心观点核心观点：6G 服务化服务化 RAN，旨在基于云原生思想旨在基于云原生思想，将传统集成单体基站功将传统集成单体基站功能解耦为网络功能与服务，通过服务化接口实现功能服务之间的交互与能力开能解耦为网络功能与服务，通过服务化接口实现功能服务之间的交互与能力开放，以按需组合的方式提供更灵活、更精简的网络服务能力，助力提升网络对放，以按需组合的方式提供更灵活、更精简的网络服务能力，助力提升网络对全行业的适应能力。全行业的适应能力。服务化 RAN 的研究一定是顺应技术发展趋势，并随着云原生技术生态的演进而迭代优化。但服务化 RAN 不仅仅是技术驱动，其价值更在于提升网络对全行业全应用的适应能力，尤其是满足行业应用功能定制、成本可控、敏捷部署、按需扩展、快速迭代等需求。整体上，服务化 RAN 主要包括如下四个技术特征：特征 1：功能解耦。只有构建高内聚松耦合的服务，才能最大限度实现功能复用、并发挥云原生平台优势，所以功能解耦是实现服务化 RAN 的必要步骤；特征 2：按需组合，是服务化 RAN 的核心价值所在。通过按需组合必要的功能服务，满足运营商及客户定制化、成本可控、灵活适配、敏捷响应的需求；中国移动6G 服务化 RAN 白皮书（2023）8特征 3：能力开放，是服务化 RAN 提供的基本能力。特征 4：服务化接口，通过 API 访问特定网络功能提供的服务。四、四、服务化服务化 RAN 体系化设计体系化设计4.1 服务化服务化 RAN 演进路线演进路线整体上，服务化 RAN 的演进可能分为两个阶段：接口服务化和功能服务化。在接口服务化阶段，又可以分为 N2 接口部分服务化（选项 1）和 N2 接口全服务化（选项 2）两个选项。两个选项可能是分阶段演进关系，例如从选项 1 演进到选项 2，也可能是并列选择关系。选项 1 主要面向 RAN 能力开放场景，因此至少需要定义一个 RAN 能力开放服务，由此 CN NF（如 NWDAF）可以直接调用该服务获取 RAN 的信息。如果想实现 RAN NF 与 CN NF 之间的直接服务调用，选项 2 的设计必不可少，但这也将意味着传统 NAS 模型需要改变，突破 NAS协议之间的嵌套关系。第一阶段接口服务化可以实现部分场景赋能，但第二阶段 RAN 功能的服务化及按需组合才能真正发挥服务化的价值。这一阶段又可以分为针对传统 RAN功能的服务化（选项 3）和针对新增 DOICT 能力的服务化（选项 4）。两个选项可以独立设计、融合发展。在选项 3 的设计过程中，不仅需要考虑 RAN 能力如何拆分为服务，还需要进一步考虑 RAN 与 CN 相关功能服务与流程的融合设计，以更好满足高内聚、松耦合的设计原则，精简网络设计。图 2：服务化 RAN 演进路线中国移动6G 服务化 RAN 白皮书（2023）94.2 RAN 控制面服务化控制面服务化4.2.1 NF 及及 NF service 定义定义核心观点：核心观点：RRC 是是 RAN 内部逻辑功能，而服务化内部逻辑功能，而服务化 RAN 关注的是关注的是 RAN 对对外可以提供的业务能力外可以提供的业务能力，因此服务定义的重点不是对因此服务定义的重点不是对 RRC 等内部逻辑功能进行等内部逻辑功能进行拆分，而是对拆分，而是对 RAN 接口接口服务服务能力的改造。当然，能力的改造。当然，RAN 接口接口服务服务能力改造必然能力改造必然会带来内部逻辑的改变。会带来内部逻辑的改变。IT 领域常用的两种服务分解主要模式是按领域驱动设计 DDD（DomainDriven Design）的子域分解和按业务能力分解912。整体思路都是，分析应用是做什么的，其每个业务能力都可以被认为是一个服务。RAN 控制面的业务能力主要体现在接口交互上。以 CU-CP 为例，其对外交互接口包括 NG-C、XN-C、E1、F1-C，相应的服务对象为 AMF、对等 CU-CP、关联的 CU-UP、DU。当考虑 RAN 控制面是否需要服务化时，应先重点关注与NG-C 及 XN-C 接口能力相关的服务定义，因为 E1/F1-C 接口能力的改造不仅仅是控制面的问题、还涉及到 RAN 用户面是否要服务化。图 3：RAN 控制面服务化设计思路参考 NGAP/XnAP 支持的主要功能与流程，CU-CP 大致可以拆分为如下 6 个服务（即 NF service）：会话管理服务、连接与移动性管理服务、消息传输服务、多播广播服务、数据采集服务、开放服务。由于消息传输服务、多播广播服务、数据采集服务、部分开放服务与连接与移动性密不可分，因此这些服务可以关联到一个 NF，如 RCMF（radio connection and mobility function，无线连接与移动性管理功能）；会话管理服务及会话相关的开放服务关联到另一个 NF，如 RSMF（radio session management function，无线会话管理功能）。中国移动6G 服务化 RAN 白皮书（2023）10图 4：RAN 控制面服务定义4.2.2 RAN 基本方案基本方案无状态是服务化设计的一项基本原则。在 RAN 层面，最直接的影响是需要引入一个类似 UDM 的状态数据存储服务，由此相同服务的实例通过状态数据存储服务可实现状态同步，即所谓的业务逻辑与状态上下文之间的分离。该状态数据存储服务的引入，将对 RAN 基本流程带来一些影响，包括切换、状态转换等。图 5：基于状态服务的切换流程示意例如，切换是一个缓慢发生的过程，而不是从一个接入点直接将状态和路径切换到另外一个接入点。通过在多个服务路径间实现数据分流，网络与用户的状态信息通过无状态服务实现同步，由此可实现终端无感切换。中国移动6G 服务化 RAN 白皮书（2023）114.2.3 RAN 与与 CN 联合设计联合设计6G 服务化架构将贯通 RAN 与 CN，实现全服务化。RAN 与 CN 的联合设计由浅入深可以包括协同优化（阶段一）与融合贯通（阶段二）两个阶段。阶段一：端到端协同设计阶段一：端到端协同设计该阶段可以实现 RAN 与所有 CN NFs 的直接交互，而无需 AMF 转发，由此可以降低端到端时延、提升处理效率。具体地，交互场景包括两类：一类是与NAS 消息无关的信令交互，如 RAN/UE 将数据上报 NWDAF；另一类是与 NAS消息直接相关的信令交互，如 RAN/UE 与 LMF 之间的定位消息传输。1.无线无线事件开放事件开放针对第一类场景。相比 5G，服务化 RAN 与 CN 的主要变化是 RAN 需要定义一个能力开放服务，并通过 SBI 直接将 UE 无关的信息开放给 CN NF。2.NAS 模型模型优化优化针对第二类场景，虽然服务化架构允许 RAN 与 CN NF 直接交互，但受限于NAS 模型，UE 与 LMF 之间的 LPP 等消息仍然需要先转发到 AMF，因为 LPP等消息通过 NAS-MM 承载、NAS-MM 的锚点在 AMF。为了避免 LPP、NAS-SM等消息的不必要 AMF 转发，需要对 NAS 模型进行适应性修改。新协议模型将突破 NAS 消息间的依赖关系，使能 NAS 消息直接转发到对应的 CN NF。图 6：5G NAS 模型与新 NAS 模型对比中国移动6G 服务化 RAN 白皮书（2023）12阶段二：端到端融合设计阶段二：端到端融合设计RAN 与 CN 在控制面的融合设计至少包括流程与功能服务两个层面。1.流程并行流程并行优化优化除了减少不必要的 AMF 转发，流程融合设计还可以考虑并行化。RAN 服务化之后，端到端流程可以被进一步拆解、并支持多个子流程的并行执行，一方面可以缩短信令流程、避免响应等待导致的端到端时延长问题，另一方面可以缓解服务调用栈太深导致的新功能引入门槛高、调用失败回退流程长等问题。图 7：端到端流程并行化2.功能功能融合设计融合设计从端到端整网来看，RAN 控制面与 CN 控制面有很多类似的功能服务，包括连接与移动性管理服务、承载及会话管理服务等。考虑到 6G 核心网下沉趋势，以及服务化架构高内聚松耦合的设计原则，RAN 与 CN 相似的功能可以融合设计，以提升 NF 部署灵活性、降低信令开销。例如，可以将 RAN 与 CN 连接与移动性管理功能融合为 uAMF（unifiedAMF），RAN 与 CN 会话与承载管理功能融合为 uSMF（unified SMF），由此可以实现更为精简的业务建立、切换、QoS管理等流程。中国移动6G 服务化 RAN 白皮书（2023）134.2.4 RAN 与与 UE 之间的交互之间的交互核心观点：核心观点：HTTP 并非替代并非替代 RRC，RRC 功能依然存在。功能依然存在。HTTP 与与 RRC 的的关系可以包括两种：关系可以包括两种：RRC 透传透传 HTTP 消息，消息，RRC 转译转译 HTTP 内容。内容。除了 CN NF，UE 也可以是 RAN 服务的消费者。传统的 RAN 能力是通过RRC/MAC 提供给 UE 的，例如，RRC 连接管理、移动性管理、资源分配等，在设计新的 RAN 能力时就需要考虑对现有 RRC/MAC 功能的影响，因此新技术开发周期长、部署周期同样较长，设计复杂度的增加也增加了运维管理复杂度。随着未来 RAN 能力的增强以及未来差异化应用需求的不断增加，RAN 需要具备更多的能力（如 AI、计算、感知等）。如果依然采用传统 RAN 能力提供方式，即通过 RRC/MAC 提供给 UE，将不能满足业务快速上线的需求。为了避免对 RRC协议的影响、加速 RAN 新功能上线，可以通过 HTTP 消息将 RAN 能力提供给UE，由此，RAN 能力可不与 RRC 协议集成，而是可以作为“服务”集成到 RAN应用层，从而避免对 RRC 协议的标准影响。图 8：5G NR-Uu 协议栈与新 Uu 协议栈对比在新 Uu 协议栈架构下，RRC 消息与 HTTP 消息可能存在两种关系：一是RRC 消息透明转发 HTTP 消息，二是 RAN 需要具备将 HTTP 消息转译为 RRC消息的能力，类似5G定位中gNB需要将部分 NRPPa消息转译为RRC广播消息。中国移动6G 服务化 RAN 白皮书（2023）144.3 RAN 用户面服务化用户面服务化4.3.1 NF 及及 NF service 定义定义关于用户面服务定义，可以从现有 3GPP 标准得到一些启示。以 PDCP 为例，TS38.323 除了明确 PDCP 具备的功能，还给出了其向上层提供的“服务”（即传输控制面数据服务、传输用户面数据服务、头压缩服务、上行数据压缩服务、加密服务、完整性保护）、以及希望下层提供的“服务”（即 RLC 层确认的数据传输服务、非确认的数据传输服务）。图 9：现有 3GPP 协议对“服务”的定义整体来看，RAN 用户面“服务”包括两类：一类是数据传输服务，与特定功能无关；另一类是功能相关，如头压缩服务。在 RAN 用户面服务化设计过程中，也可以参考类似的服务定义方式：选项选项 1：仅定义数据传输服务：仅定义数据传输服务具体数据传输服务如何实现取决于 NF 内部实现。为了满足差异化场景需求，数据传输服务可以进一步被细化为面向不同场景的服务，例如面向 eMBB 的数据传输服务 1、面向 uRLLC 的数据传输服务 2 等。或者，针对不同场景需求分别定义服务操作（Service Operations）。中国移动6G 服务化 RAN 白皮书（2023）15图 10：用户面服务定义选项 1选项选项 2：将不同数据处理功能定义为不同的：将不同数据处理功能定义为不同的网络网络功能功能服务服务每个 NF 仅包含一个或一类数据传输服务。例如用户面 NF1 仅提供加/解密服务；当然也允许一个 NF 包含多个同一类别的 NF service，例如在用户面 NF2 中可以包括基于 ROHC 的头压缩服务以及基于 EHC 的头压缩服务。图 11：用户面服务定义选项 24.3.2 基本问题与基本问题与方案方案RAN 用户面服务突破了传统分层协议栈的限制，使功能不再受限于上下层，可以灵活调用、按需组合，但这种灵活性带来的问题是数据处理顺序、包头格式需要重新设计。中国移动6G 服务化 RAN 白皮书（2023）16表 2：栈式协议模型与服务调用模型对比1.功能功能服务服务链链用户面服务编排需要基于系统任务统一编排结果、业务的 QoS 策略、定制化需求确定。整体上，服务编排可以通过集中编排和分散协作两种方式实现。集中编排由一个主要职责是编排工作流的服务完成；分散协作方式中没有编排者服务，工作流中的服务共同分担协调职责。编排方式编排方式 1：集中编排：集中编排对于选项 1（面向不同应用场景定义不同的数据传输服务），集中编排可以由数据传输服务来实现，其基于编排策略逐一选择 NF 内部处理功能实现定制化的数据处理。对于选项 2（将不同数据处理功能定义为不同的数据传输服务），需要借助具有编排服务的 NF 来完成服务功能链的串联。图 12：选项 1 集中编排图 13：选项 2 集中编排中国移动6G 服务化 RAN 白皮书（2023）17编排方式编排方式 2：分散协作：分散协作对于选项 1，需要提前将服务选择策略/编排策略下发给每个相关的处理功能（非标准定义的服务），这样处理功能可以基于特定标识直接完成下一功能的选择。类似地，对于选项 2，策略需要提前告知每个相关的 NF，以便于 NF 选择下一个服务。图 14：选项 1 处理功能之间的分散协作图 15：选项 2 不同 NF/NF service 之间的分散协作除灵活编排处理功能外，服务化 RAN 还可能具备如下两个新特征：新特征新特征 1：使能多服务并行处理：使能多服务并行处理处理顺序不仅包括链式串联，还包括并行处理。例如，现有 PDCP 层会先执行完整性保护、再执行加密、添加 PDCP 头的操作，考虑到加密对象主要是 IP及 IP 以上的包头、数据域、MAC-I，但 MAC-I 加密的必要性并不大，可以将加密、完整性保护等服务并行执行，由此可以大大提升数据处理的效率。图 16：多服务并行处理中国移动6G 服务化 RAN 白皮书（2023）18新特征新特征 2：允许：允许服务服务级动态级动态扩缩扩缩潮汐现象是网络中的常见的动态变化，在不同的空间中，网络中接入的用户数以及传输的数据量均会随着时间而变化。服务化 RAN 可监测网络中的潮汐变化情况，动态的部署或删除服务实例，实现服务级别的动态扩缩。如接入用户数增多，仅扩展控制面中用户管理相关的服务。下行数据量增大时仅需增加下行服务实例等。而非像现有 5G DRB 一样，只能实现承载级别的扩缩容。图 17：服务级扩缩容2.灵活包格式灵活包格式不同于传统固定格式的包头，服务化 RAN 架构下的包头格式与处理链路上的服务相关，因此包头可能会包括两部分：公共部分与服务特定部分。在服务特定部分，只有该服务可以对该部分包数据进行修改。图 18：服务特定包头4.4 服务化演进服务化演进服务化 RAN 设计既要确保 5G 网络在未来可以平滑升级，也要满足 6G 业务新应用场景和挑战，提供整网的按需服务能力。一些关键问题需要拉通前后端提前进行分析。4.4.1 多维能力服务化多维能力服务化未来 6G 网络赋能各行各业的愿景，要求 6G 网络的设计满足能力开放、灵中国移动6G 服务化 RAN 白皮书（2023）19活、按需的需求。未来 6G 网络的设计需要对网络构成元素进行抽象，通过网络编排和 AI 智能的引入，满足各行业对网络通信服务、算力服务、数据服务、AI服务、安全服务的能力需求，达到业务通信能力按需组合，算力能力的按需分配，数据需求的按需存取，促进服务使能层的更加“开放”和“繁荣”。服务化 RAN作为全域服务化的重要组成，同样需要在传统通信能力的基础上进一步扩展多维能力，面向低时延等特殊场景需求，将 RAN 的计算、数据、AI 等能力打造成可对外提供的服务。此外，多维能力的引入也将赋能未来网络全服务化设计。例如，AI 将降低网络功能原子化、微服务化带来的编排设计复杂性，实现在时变环境下网络服务与业务最优匹配，提升网络运行效率和用户体验。4.4.2 架构模式灵活化架构模式灵活化RAN 服务化在初期阶段为了简化分析，可参考核心网现有 SBA 模式拆分为多个 NF service，NF service 归属于特定的 NF，通过 NRF 进行服务注册/发现。但是该模式下 NF 需要实现较多的通用事务处理，如配置管理、备份容灾、负载调度等。虽然 Rel-16 定义的 NF set、SCP 等特性在一定程度上缓解了 NF 的实现复杂度，但没有彻底解决问题，需要考虑继续演进，图 19 为可能的一种演进思路，最终在 Option B 中弱化 NF 概念，NFs 以 Serverless 方式提供能力，可以按需把多个 NFs 自由组合为 NF，多个 NF 形成自治域，多个自治域分级组合形成完整通信网络。图 19：架构模式演进中国移动6G 服务化 RAN 白皮书（2023）204.4.3 软硬件联合优化软硬件联合优化服务化 RAN 可以满足不同应用部署场景对网络的敏捷性、灵活性和可扩展性等诉求，但现阶段在通用服务器上运行的纯虚拟化软件可能无法满足特定场景下的极致性能和超低时延需求，需要专用硬件进行关键模块加速，