点击查看更多紫金山实验室：2023从设计安全到内生安全技术白皮书（81页）.pdf精彩内容。

0人已浏览 2023-12-18 81页 5星级

点击查看更多湖南省量子科技学会：2023量子测量技术发展蓝皮书（90页）.pdf精彩内容。

0人已浏览 2023-12-18 90页 5星级

射频识别（RFID）技术与标准化蓝皮书（2023）中国电子技术标准化研究院2023 年 11 月版权声明：如需转载或引用，请注明出处。顾问：王立建王桂华王东李继春任晓涛杨伟奇许汝峰编制单位（排名不分先.

0人已浏览 2023-12-18 134页 5星级

 15A景区旅游活跃度盘点月报2023年7月-艾瞰系列-2023 iResearch Inc.第三方支付行业平台活跃研究2023年12月22023.12 iResearch I第三方支付市场发展概述经济.

0人已浏览 2023-12-17 13页 5星级

点击查看更多负荷柔性控制技术研究与创新（2023）（18页）.pdf精彩内容。

0人已浏览 2023-12-16 18页 5星级

北京稻壳科技有限公司Beijing Rice Hull Technology Co.,Ltd.地址：北京市朝阳区九住路 188 号IMT-2030(6G)推进组IMT-2030(6G)Promotion Group2023 年年 12 月月版权声明版权声明 Copyright Notification未经书面许可未经书面许可 禁止打印、复制及通过任何媒体传播禁止打印、复制及通过任何媒体传播2023 IMT-2030（6G）推进组版权所有3IMT-2030(6G)推进组IMT-2030(6G)Promotion Group目录目录.3图目录.5表目录.7第一章背景.8第二章挑战.92.1太赫兹信道方面的挑战.92.2太赫兹收发机方面的挑战.9第三章技术进展.113.1非理想特性补偿技术.113.1.1 太赫兹基带器件非理想失真挑战.113.1.2 数字预失真算法.123.1.3 峰值因子消减算法.133.1.4 通道一致性校准算法.143.1.5 基于 AI 的波束成形技术.153.2超大规模天线基带信号处理.163.2.1 分布式基带信号处理技术.163.2.2 基于期望传播算法的分布式接收机.173.2.3 基于用户分组的接收机设计.193.3智能接入技术.203.3.1 大规模 MIMO 接入挑战.203.3.2 基于延迟相位预编码架构的太赫兹主动协调式接入机制.203.3.3 面向超密集组网的太赫兹系统可重构接入方法.213.4超大规模天线阵列：MIMO 与智能反射面技术结合.223.4.1 宽带太赫兹智能超表面通信波束色散管理.223.4.2 超大规模 RIS 辅助的信道估计和定位.244IMT-2030(6G)推进组IMT-2030(6G)Promotion Group3.5波束管理.253.5.1 RIS 辅助的宽带太赫兹高精度波束训练方法.253.5.2 低时延的太赫兹波束管理方法.25第四章系统原型验证.274.1宽带太赫兹高速通信链路和 MIMO 系统.274.2MIMO 高阶调制系统.294.2.1 高阶调制系统架构.294.2.2 高谱效系统原型验证.30第五章未来发展.315.1太赫兹远近混合场信号处理技术.315.1.1 太赫兹远近场效应.315.1.2 混合球面和平面波信道模型.325.1.3 基于深度学习的信道估计.335.1.4 基于压缩感知的信道估计.345.2感知协同太赫兹 MIMO 通信.355.2.1 感知协同的 MIMO 通信性能界.355.2.2 感知协同波束赋形技术.375.2.3 感知协同的波束追踪技术.385.3数据驱动太赫兹高速传输技术.395.3.1 数据驱动的物理层技术.395.3.2 数据驱动的传输和高速业务一体化技术.40第六章参考文献.42第七章主要贡献单位.435IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图目录图 3-1数字预失真原理示意图.12图 3-2数字预失真实现原理框图.12图 3-3功放输入输出特性示意图.13图 3-4消峰基本原理示意图.14图 3-5多通道一致性校准流程图.15图 3-6DeepRx 处理流程图.16图 3-7DeepRx 系统与传统 LMMSE 性能对比.16图 3-8分布式 M-MIMO.17图 3-9基于 EP 的分布式接收机方案.18图 3-10基于稀疏化 EP 的分布式架构.19图 3-11DBP 星状架构（左）和 DBP 菊花链架构（右）.20图 3-12延迟相位混合波束赋形架构.21图 3-13波束训练示意图.21图 3-14太赫兹系统可重构接入方法.22图 3-15(a)传统移相器结构，(b)单层时延器结构，(c)双层时延器结构。.23图 3-16(a)分布式 STAR-RIS 辅助通信;(b)STAR-RIS 子连接结构.23图 3-17(a)联合信道和用户位置感知;(b)不依赖于信道估计的位置感知.24图 3-18基于能量分布的太赫兹宽带 RIS 波束训练性能.25图 3-19PWS 感知帧结构.26图 4-1(a)实验系统设置(b)系统实物图.27图 4-2室内长距离的太赫兹通信测试.28图 4-3一种高谱效的太赫兹通信系统架构.29图 4-4太赫兹基带预均衡方案.29图 4-5分布式的相位噪声抑制方案.30图 4-6THz 室外远距离通信样机（上），THz 室外 MIMO 通信样机（下）30图 5-1(a)PWM 和 SWM 需要估计的参数数目对比;(b)PWM 模型误差。31图 5-2HSPM 示意图.32图 5-3HSPM 的误差性能。.33图 5-4所提信道估计 DCNN 网络架构。.336IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图 5-5基于 DCNN 的信道估计方案的误差性能.34图 5-6不同感知协同部署追踪.35图 5-7通信感知一体化研究中的性能指标.36图 5-8感知协同太赫兹通信闭式表达式与理论真值对比.37图 5-9感知协同太赫兹宽带波束赋形方案示意图.37图 5-10全连接的混合预编码系统结构.38图 5-11MIMO-OTFS 太赫兹信道追踪架构图.38图 5-12视觉辅助的太赫兹超大规模 MIMO 波束追踪方案流程图.39图 5-13传输模型的神经网络结构.40图 5-14面向高速业务的数据驱动太赫兹传输系统结构.417IMT-2030(6G)推进组IMT-2030(6G)Promotion Group表目录表 4-1有 MIMO 串扰的四通道 D 波段太赫兹通信测试结果.28表 4-2有 MIMO 串扰的四通道 G 波段太赫兹通信测试结果.28表 7-1主要贡献单位.438IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第一章 背景太赫兹（0.1-10 THz）频段具备超大带宽的天然优势，有望实现超高数据速率以及毫米级精度感知。基于太赫兹频段的通信感知技术将颠覆第六代及未来的无线通信系统，真正实现“万物智联”。为了充分发挥太赫兹频段的潜能，研究太赫兹空时频高速信号处理技术显得尤为重要，包括空域的波束管理、时频域的信号处理设计。相比于微波及毫米波频段，太赫兹频段存在更为严重的路径损耗，包括自由空间传播损耗、反射散射损耗、分子吸收损耗。如果不进行处理，这些损耗会极大限制通信和感知的最大距离，降低了频谱效率和感知精度。因此，当发射功率固定时，一般需要利用超大规模天线阵列（Ultra-Massive MIMO,UM-MIMO）产生定向波束来克服这些损耗。当天线数目较多时，需要研究高能效、低复杂度的波束赋形架构以及空域预编码算法。此外，定向波束的使用会限制感知的角域覆盖范围。在太赫兹频段，为了同时实现高速率的数据传输与全方位的高精度感知，需要设计高速有效的波束管理方案与空域信号处理技术。为了实现上述太赫兹通信和感知的宏伟愿景，时频域的通感双功能波形设计以及相应的基带信号处理也是太赫兹 UM-MIMO 系统中极为重要的一环。不同的时频域调制和波形方案具有不同的优劣势，包括峰均功率比、对多普勒效应的鲁棒性、信号处理复杂度、时频资源分配的灵活性、与 UM-MIMO 的兼容性等。同时，需要针对太赫兹接收机的信道估计、数据检测、感知定位等功能研究相应的高速信号处理算法，以解决太赫兹频段的挑战，充分利用太赫兹频谱资源的优势。9IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第二章 挑战2.1 太赫兹信道方面的挑战1.信道时延特性：信道时延特性：太赫兹频段较高的反射和散射损耗，可能导致非视距路径的功率损耗和数量衰减，此时太赫兹通信信道的时延扩展会有所减小，相关带宽有所增大。因此，在考虑太赫兹通信时，可以减少太赫兹信号的循环前缀长度以提高频谱效率。然而，与通信的时延扩展不同，在考虑太赫兹感知时，已有的信号处理方法要求最大感知距离的往返延迟小于循环前缀长度。此时，如果不研究新型信号处理方案，减小循环前缀的长度，会限制了太赫兹感知的最大距离。2.多普勒效应：多普勒效应：由于多普勒扩展效应与载波频率成正比，所以在太赫兹频段，特别是在高迁移率情况下，多普勒扩展效应更加严重。高多普勒频移的时频双选信道会破坏子载波的正交性，引起载波间干扰。一方面，通过增大子载波间隔可以抑制多普勒效应的影响。另一方面，也可以通过研究新型时频域信号处理技术提高系统对于多普勒效应的鲁棒性。阻挡效应阻挡效应：由于穿透损耗，在太赫兹通信网络中需要考虑阻挡效应。太赫兹波很难通过许多常见阻挡物体，如墙壁和人体。在遇到各种阻挡的环境中，接入点与用户设备之间的视距路径可能被阻塞，从而降低了接入点的覆盖距离。因此，需要研究空时频高速信号处理技术，解决随时出现的阻挡问题，保证数据传输不中断，实现高质量的太赫兹通信服务。3.远近场信号处理：远近场信号处理：在太赫兹频段，当传输距离小于天线阵的瑞利距离时，需要考虑近场传播。在这种情况下，作为球面波传播近似模型的平面波传播模型就会失效，给波束赋形以及空域的信号处理带来了困难。2.2 太赫兹收发机方面的挑战1.功率放大器：功率放大器：由于功率放大器的饱和输出功率随着载波频率的增加而迅速减小，太赫兹频段的功率放大效率和平均输出功率对太赫兹波段的峰均功率比更为敏感。为了优化发射机的发射功率和功率效率，通过有效的时频域基带信号处理，降低太赫兹发射信号的峰均功率比是实现高能效太赫兹通信的关键技术。2.波束分裂效应波束分裂效应：在太赫兹波段，一般利用超大规模天线阵列来提供高的波束增益。然而，在宽带 UM-MIMO 模拟或混合波束赋形系统中，可能会出现了波束分裂效应。在波束赋形预编码设计无法实现完全自由度的情况下，混合波束赋形结构利用10IMT-2030(6G)推进组IMT-2030(6G)Promotion Group移相器对所有频率进行相同的加权调整，因此非中心频率的波束方向可能会偏离中心方向并偏离目标或用户。此时，阵列增益大大降低，从而影响感知和通信的性能。3.时间复杂度：时间复杂度：为了支持具有超高速数据速率的无线链路，需要对太赫兹收发机的信号处理复杂度进行合理优化。由于实现 Tbps 级别的基带数字信号处理硬件仍然具有挑战性，低复杂度的高速信号处理方法尤为重要，特别是在接收机的信号处理模块，包括信道参数估计和数据检测技术。相应算法的时间复杂度应当尽可能随着空时频资源的数目呈线性增长或线性对数增长。11IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第三章技术进展3.1 非理想特性补偿技术3.1.1太赫兹基带器件非理想失真挑战根据 ITU 提出的 6G 愿景，6G 系统支持高达 100GHz 甚至 1THz 的大带宽，6G 高频系统的下行峰值速率可以高达 100Gbps，上行峰值速率高达 1Tbps，预计将大幅提升系统的传输能力。太赫兹频段超大带宽方面的资源优势，可以支持系统具备超高速率的通信能力，但是太赫兹通信高频率和大带宽将引入复杂动态信道、混合失真、复合噪声、方向性强易被遮挡等不利影响。为支持超宽带超高速通信应用，太赫兹通信系统对数模转化芯片采样率需求提升。而高精度的模数转换器（Analog-to-Digital Converter，ADC）和数模转换器（Digital-to-Analog Converter，DAC）具有较高的功耗和硬件成本。除此之外，高频功率放大器的工作效率对整机功耗的影响接近 40%，其性能对太赫兹基带处理能力和功耗能效控制至关重要1。ADC/DAC 的量化误差、相移器的非理想性、功率放大器的非线性失真、低噪声放大器的非理想性均对太赫兹基带信号处理带来挑战。因此，在发射机侧，需要满足高增益、高功率、高效率、高线性度、低误差矢量幅度（EVM），在接收机侧，需要在宽带接收范围内表现低接收器灵敏度、低噪声和高增益/线性度。太赫兹通信系统对消峰处理和数字预失真等射频算法提出了更高的能力要求，亟需非线性补偿校正提升工作效率，需要从不同层面研究适应于太赫兹硬件设备实现的低复杂度、高效信号处理方法。针对太赫兹频段器件非理想特性和工程实现的约束，尝试根据现有的理论基础，设计适应大带宽高数据速率的太赫兹通信波形和低复杂度的并行化基带信号处理架构，解决太赫兹超高传输速率的物理层设计和工程实现问题，让太赫兹通信在当前器件约束下走向实际应用。由于太赫兹的超大信号带宽和超大阵列，全数字信号处理架构需要依赖高精度和高采样率的数模和模数转换器，以及复杂信号处理算法，这对器件的成本和设计难度，高速接口，系统功耗带来了极大挑战。模拟以及数模混合的信号处理体制，可以使用低精度 AD/DA 的收发体制及简化算法基带，在太赫兹通信中是一个有潜在的研究方向。一方面，需要研究如何降低对 AD/DA 的采样率需求，常规系统通常需要以多倍符号速率进行采样，对太赫兹超高速率信号将会带来极高的基带处理资源开销；另一方面需要研究低量化精度信号处理技术，具体包括比特量化与信号算法的联合优化设计、自适应量化门限、单比特解调的联合优化设计以及基于概率计算的低复杂度的硬件集成电路设计等。12IMT-2030(6G)推进组IMT-2030(6G)Promotion Group3.1.2数字预失真算法功放的输入输出特性只有在较低功率部分具有线性响应特性，随着输入功率的提升，功放输出功率开始产生非线性压缩，平均发射功率处于较强非线性区域，如图 3-1 所示。非线性响应特性会导致信号能量的泄露，引起带外非线性失真，影响信号发射质量，降低功放工作效率。图3-1数字预失真原理示意图数字预失真（Digital Pre-Distortion，DPD）是针对功放非线性进行预失真校正的技术，其主要原理是通过训练数据和反馈数据来计算和逼近功放的非线性数学模型，通过模型的计算结果在数字中频对发射数据进行功放行为逆模型的预失真补偿，保证功放输出的线性，优化和改善非线性导致的相邻频道泄漏比（ACLR）和误差矢量幅度（EVM）指标恶化。如图 3-2 所示为在基站产品中实现 DPD 算法的原理框图。图3-2数字预失真实现原理框图数字预失真算法对功放线性校准和效率提升的改善能力主要取决于以下几方面因素：1）是功放行为模型建模。行为模型建模越逼近功放的实际响应特性，建模精度越高，预失真补偿的效果越好。2）是反馈数据采样带宽。反馈链路一般需要满足载波带宽 35 倍的采样带宽，才能通过计算得到较为精确的预失真模型参数，达到较好的线性校正效果。3）是反馈数据的误差。反馈数据中非功放响应特性导致的数据误差越大，预失真模型参数误差也就越大，进而影响到数字预失真性能。13IMT-2030(6G)推进组IMT-2030(6G)Promotion Group在系统设备实际研发过程中，会综合考虑功耗、性能和成本等因素，通过功放行为模型和反馈数据采样带宽的折中选择，确定数字预失真算法的最终实现方案。数字预失真方案的实现面临众多难题：首先是大带宽的影响。数字预失真实现往往需要反馈通道提供载波带宽 3 倍以上的采样带宽，采样带宽不足会导致链路的非线性改善能力受限。但是现有成果多以算法复杂度和运算资源增加为代价来提升欠采样条件下的数字预失真性能，对相关算法处理芯片形成功耗压力，且算法实时性较差。其次是混合波束赋形架构的引入。混合赋形架构下，多个高频模拟通道功放合路造成的非线性特性做统一的预失真补偿校正，校正能力受限。并且其非线性状态又会随模拟波束的切换而发生改变，数字预失真校正与模拟波束切换之间的实现流程需要交互设计，影响系统波束切换的实时性。目前在 6G 高频系统中的数字预失真方案开发过程中，业界多是对系统设备的功能和性能进行折中考虑，通过降低数字预失真模型复杂度和实现难度，提高其可行性。或是不做数字预失真处理，通过高频功放发射功率回退使其工作在线性区，保证整机的线性指标。3.1.3峰值因子消减算法针对太赫兹功率放大器功耗大，输出功率有限问题，提出为峰值因子消减算法（CFR）。功率放大器的输入输出特性如图 3-3 所示，功放输出功率无法超过饱和功率，功放的平均发射功率为饱和功率与峰均比 PAPR 之差。而由于太赫兹信号传输带宽大，基于 OFDM 的波形将导致更高的峰均比，影响系统整机功耗和工作效率。图3-3功放输入输出特性示意图CFR 消峰算法是通过在数字中频对信号的峰值采用适当处理，降低信号峰均比，提升功放平均输出功率，从而提高功放工作效率，其原理如图 3-4 所示。消峰算法主要分14IMT-2030(6G)推进组IMT-2030(6G)Promotion Group为脉冲抵消和硬切等方法，目前，基于脉冲抵消的消峰算法是实现消峰功能的主流 CFR算法，既能较好的降低信号峰均比，又能防止关键射频性能 EVM 指标恶化。基于硬切的消峰算法一般用于通道关断保护。消峰算法在 4G 设备和 5G 低频段设备中已有成熟开发和应用，可以在保证发射信号质量的前提下，将原始基带信号的峰均比削减 3dB 左右。图3-4消峰基本原理示意图适用于大带宽新空口基带信号的消峰算法优化和性能提升方案是太赫兹系统研发需要面临和解决的技术问题，影响消峰算法性能的主要因素有以下两方面。一是消峰门限的确定。消峰门限越低，信号峰值压缩程度越高，信号峰均比降低，信号带内失真程度加深。虽然系统的关键射频性能邻道功率泄露比（ACLR）指标会改善，但是信号发射质量变差，EVM 指标恶化。因此消峰门限的设定需要结合功放的输出特性和整机需求综合考量。二是基带信号的有效带宽。脉冲抵消消峰算法在峰值脉冲抵消后需要加成型滤波来证系统发射信号带外性能不受影响，有效带宽过高会导致滤波器过渡带过窄，需要占用更多数字中频算法资源用以实现有效成型滤波。如算法资源不足导致，则易造成滤波器带外抑制能力不足，影响系统的 ACLR 指标。3.1.4通道一致性校准算法通道一致性校准算法用于保证所有系统所有收发通道的幅相响应在设备的整个工作带宽内具有一致性。太赫兹前端系统各通道间的幅相一致性是空间复用、波束赋形功能等超大规模天线技术优势被有效应用的前提和保障。通道一致性校准的原理通过具有特殊性质的原始校准序列和校准序列之间的差异计算出不同通道在整个工作带宽内的校准补偿因子，再将校准因子补偿至各个发射/接收通道，保证所有发射/接收通道在整个工作带宽内幅相响应的一致性。发射/接收通道校准流程如图 3-5 所示。15IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图3-5多通道一致性校准流程图大规模天线阵列的多通道幅相一致性对于整个系统设备波束赋形功能的有效实现至关重要，通道一致性校准方案的设计也是太赫兹前端关键技术之一。但是在整个工作频段内以符号为单位对各个通道信号做校准因子补偿，会占用较多运算资源，因此算法设计面临如下难题。首先，高频段、大工作带宽导致硬件校准链路缺少可靠的硬件耦合回路用于校准信号的接收和处理，采用开关电路又容易导致校准实现流程复杂度增加，影响校准效果。其次，混合赋形架构的引入使得无法再直接对发射/接收通道信号进行信道参数估计和校准补偿，而是需要更加复杂的分组校准才能实现对每个高频通道在单一频点处的幅相校准，实现流程和方案较复杂，系统校准实时性较差。另外无法对单个模拟赋形模块内的多个高频通道在整个工作带宽内的幅相一致性进行差异化校正。3.1.5基于 AI 的波束成形技术为了更好应对太赫兹器件复杂的非线性问题，可以考虑在波束成形系统中引入深度学习网络，获得全局优化补偿方案。为此，提出一种深度全卷积神经网络 DeepRx，用于解决这些非理性特性的影响。DeepRx 是一种基于机器学习的新型接收器系统，在接收机处插入深度学习网络，可以实现联合信道估计、均衡和信号解映射。在传统的接收机架构中，信道估计等算法以线性假设为前提，并且解映射器在 I-Q 两个维度上去做最后的软比特判决，因此接收机性能受到太赫兹系统芯片、器件非线性特性的影响。而基于 AI 的 DeepRx 方案利用深度学习算法，可以模拟硬件系统中的非线性关系，可对失真做更精准的补偿。DeepRx16IMT-2030(6G)推进组IMT-2030(6G)Promotion Group的解映射器可在更高维度上判决，新的自由度带来了额外的增益。并且，利用 AI 的灵活性，DeepRx 可自适应不同的传输环境，在当前条件下去学习获得最优补偿算法。由于太赫兹信号传输受大气环境变化明显，使用 DeepRx 在太赫兹接收机系统中可以降低硬件失真、传输环境动态导致的性能损失。引用 DeepRx 可以 1）减少信道估计所需的导频数；2）经过神经网络训练的精确参数可以用于 MIMO 波束成形与追踪中；3）延展的神经网络分支可以支持非正交的更高维度解映射算法。进一步的，考虑到传统 OFDM 波形的高 PAPR 影响，未来太赫兹系统可能采用OFDM 改进波形。目前，单载波 DFT-s-OFDM 是太赫兹极具潜力的候选波形。新型的基于 DFT-s-OFDM 的 DeepRx 采用三层处理架构，将难以处理的 IDFT 解调信号放在两层神经网络中间，如图 3-6 所示。第一层神经网络执行信道估计与信号均衡，后面的神经网络用作解映射器，进一步提升系统性能。图3-6DeepRx处理流程图目前，该 DeepRx 方案以开发测试平台，在首届 6G 候选技术测试中完成了性能测试。在双数据流传输场景中，峰值速率达到 200GHz，相较于传统的 LMMSE 接收机有超过 30%的性能提升，如图 3-7 所示。图3-7DeepRx系统与传统LMMSE性能对比3.2 超大规模天线基带信号处理3.2.1分布式基带信号处理技术与传统的小规模 MIMO 系统相比，大规模多用户多输入多输出（M-MIMO）系统在频谱效率、容量和可靠性方面都有很大提升。然而，低复杂度高性能接收机设计是17IMT-2030(6G)推进组IMT-2030(6G)Promotion GroupM-MIMO 技术实施的前提。为支持 M-MIMO，需要基带处理单元之间传输大量的原始基带数据，超高的数据传输速率超过了现有高速互联的带宽（如通用公共无线电接口（CPRI）带宽标准，24.3Gbps）。接近现有芯片输入/输出接口的极限的数据传输需求给硬件实现带来了巨大负担。传统的 M-MIMO 采用集中式架构，这种集中式框架需要完整的信道状态信息（CSI）和完整的接收信号，这给大规模 MU-MIMO 系统带来了过高的计算复杂度和功耗。因此，提出 M-MIMO 系统的分布式基带处理架构（DBP）。分布式架构的单个基站上的大规模天线被划分为多个独立的天线簇。每个天线簇与一个分布式处理单元相关联，该单元包括本地信道估计（CHEST）模块和本地检测器。然后，通过一个集中式处理单元将每个天线群产生的信息进行融合，并将融合后的信息传送给解码器进行解码。当总天线数量增加时，这种灵活、可扩展的分布式天线架构可实现灵活分配每个集群的天线，而不需要对传统的集中式大规模 MIMO 架构的整个系统进行重新设计。图3-8分布式M-MIMO如图 3-8 所示，天线簇独立并行进行信道估计与检测，并在中心处理单元（CPU）处消息合并、译码，这种架构可以降低海量基带数据和 CPU 计算复杂度。但是，由于天线簇相互独立，信息共享受限，相较集中式检测存在性能损失。分布式架构的性能损耗随着天线簇数量的增多而上升，这限制了其在超大规模阵列下的应用性能，需要为共享受限基带信号处理的设计低复杂度的分布式检测算法，逼近集中式架构的性能界。3.2.2基于期望传播算法的分布式接收机期望传播算法（EPA）是一种确定性近似算法，它将符号近似为高斯概率密度函数（PDF），通过均值和方差传播来简化复杂的消息传递规则。EPA 通过一组局部近似来逼近后验分布，通过局部近似对每个数据点进行迭代精炼。期望传播算法可以提供分析和计算上的优势。18IMT-2030(6G)推进组IMT-2030(6G)Promotion Group在分布式接收机方案中，基站的天线被划分为多个独立的单元簇。在每个簇中，分布式处理单元根据从本地 CHEST 模块接收得到的 CSI 信息和接收信号进行本地检测。中心式处理单元（CPU）接收每个来自每个单元簇传递的均值和方差，并通过单变量高斯 PDF 的乘积原理计算融合均值和方差。对数似然比（LLR）根据融合的均值和方差迭代更新，实现解码。基于 EP 的分布式架构如图 3-9 所示，分布式处理单元负责本地CHEST 和本地 EPA 信号检测，中心处理单元负责信息融合和 LLR 精炼解码2。图3-9基于EP的分布式接收机方案基于该架构，提出在单元簇中使用非线性 EP 分布式检测方案，并且提出在中心处理单元处使用基于高斯乘积原理的非线性消息合并规则，有效增强天线簇之间的信息共享，提升接收机性能2。仿真结果表明，建议的分散式 EPA 信号检测性能接近集中式EPA，而计算复杂度开销很小，特别是在天线簇的数量较多的情况下，其性能优于最先进的分散式 EPA。进一步地，由于随着接收天线数量的增加，基于 EP 架构计算复杂度也会快速增加。当系统高负荷运行时，其性能也会下降。因此，提出一种基于信道稀疏化的改进 EP 分布式接收机设计，简称 S-EP，架构如图 3-10 所示3。其主要思想是先对信道进行稀疏化处理，降低相关因子图（FG）中的变量节点（VN）和函数节点（FN）平均度显著降低，从而减少有效干扰。因此，可以提高解调的准确性。同时，还可以降低互信息计算复杂性。19IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图3-10 基于稀疏化EP 的分布式架构分析和仿真结果表明，与传统的基于 EP 的检测方案相比，所提出的基于 S-EP 的检测方案实现了明显的性能提升，而所需的计算复杂度却更低。尤其是在高过载率和/或高阶调制的系统中，并取得了与 VAMP 检测器相似的性能。对于有大量接收天线的系统，计算量的节省更为明显。3.2.3基于用户分组的接收机设计为实现上行大规模 MU-MIMO 系统，基于 DBP 架构提出了一种用户分组的接收机设计。传统的基于 DBP 的方法是在每个群组中逐个用户进行干扰消除，由于天线簇之间不能完全共享信息（如接收信号、噪声样本和信道状态信息（CSI），因此传统的基于 DBP 的检测器会有相当大的性能损失。对于具有大量簇的 DBP 架构，提出基于分组的接收机方案，以提高 DBP 架构系统的性能4。分组方案的核心思想是充分利用分组信息，共同抑制每个用户组中用户信号的残余干扰。在所提出的方案中，首先将用户分成多个组，并在每个天线群的分散处理器上进行分组 EP（GW-EP）检测，每个组向 CPU 传递均值向量和协方差矩阵。然后，根据基于多元复高斯乘积消息合并规则，在 CPU 上对输出的本地信息进行融合。GW-EP 可以应用于星状架构和菊花链架构，如图 3-11 所示。星状结构中所有簇都直接单向连接到中央处理器。每个集群独立并行执行本地基带处理任务。菊花链架构GW-EP 每个簇在本地计算部分信息，与前一个簇接收到的传递过来的多元高斯 PDF 的均值向量和协方差矩阵，然后将合并后的信息转发给下一个簇。20IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图3-11 DBP星状架构（左）和DBP菊花链架构（右）数值结果表明在有大量集群和空间相关信道的情况下，GW-EP 检测器优于传统检测器。星状架构下，随天线簇数量增多，检测器性能恶化，而 GW-EP 在菊花链架构中，获得近似集中式性能；当总天线数相同时，菊花链架构性能与天线簇数无关，交互数据恒定。DBP 相对于集中式所节省的互连带宽随天线数增加而增大，在菊花链架构下交互数据保持恒定，显著低于集中式处理。3.3 智能接入技术3.3.1大规模 MIMO 接入挑战大规模 MIMO 技术可以产生具有高阵列增益的定向波束，有效弥补信号传输损耗带来的阵列增益损失。但是在太赫兹超宽带通信应用中，大规模 MIMO 将引发空间宽带效应，进而导致波束分裂现象。同时，6G 网络超密集的组网环境导致信道空间干扰加剧，进一步增大太赫兹节点接入难度。在太赫兹频段，更大的天线规模导致的窄波束和更大带宽导致的宽间距，从而波束分裂效应，发射机将生成分散波束，使得不同频率的信号指向不同的物理方向。对于全数字收发器，可以通过单独调节每个阵元的矢量来解决波束分裂问题。然而，在大规模MIMO 下，全数字架构开销巨大，通常使用混合相控阵，由于移相器的硬件限制，波束斜视/分裂效应难以消除。太赫兹预计应用场景需要支持超密集组网，如热点区域、工业物联网等。其用户通常具有过载、分布密度高等特点。在热点区域，由于用户分布密度高，因此不同用户的空间信道具有强相关性，用户的数据空间流将产生严重干扰，造成用户接入困难。因此，太赫兹通信通信系统亟需进一步探索更先进的干扰协调技术和更高的用户接入能力。3.3.2基于延迟相位预编码架构的太赫兹主动协调式接入机制为缓解大规模天线和宽带传输下的波束分裂效应，研究提出在混合预编码架构中添21IMT-2030(6G)推进组IMT-2030(6G)Promotion Group加真时延器（True-Time Delayer，TTD），在时域上补偿孔径时延，在频率上引起相位变化，有效缓解波束分裂现象，如图 3-12 所示。通过设计频率相关的波束赋形器，可以控制波束在不同子载波频率上的分裂方向，在整个带宽内生成朝向目标物理方向的频率相关波束。图3-12 延迟相位混合波束赋形架构基于 TTD 混合波束赋形架构开发的波束训练过程如图 3-13 所示。上行波束训练过程是基于导频的波束对齐过程。预先定义一个关于用户到达角的分层后验概率模型，在导频发送过程中，基于可控的分裂波束感知空间信息并逐次更新后验概率模型，最终获得用户的精确到达角信息。对应的下行波束训练基于用户的到达角信息，调节 TTD 架构聚焦分裂波束，实现高效的数据传输。图3-13 波束训练示意图3.3.3面向超密集组网的太赫兹系统可重构接入方法针对太赫兹超密集组网下接入难题，提出一种太赫兹系统动态可重构接入方法。该方案利用可重构智能超表面（Reconfigurable Intelligent Surface，RIS）和非正交多址接入（Non-Orthogonal MultipleAccess,NOMA）技术，实现更高效的多域复用无线接入。可重构智能超表面是一种新型无源器件，通过大量低成本电磁单元智能控制无线信号的反射特征，从而实现无线传播环境的重构，使得无线电环境可控。通过对控制 RIS的单个反射单元的相移，来创造可控的传播环境，能够进一步探索空间域资源，有效缓解超密集组网中的用户干扰。非正交多址接入（NOMA）技术作为下一代移动通信系统的候选技术之一，在时频域外引入功率域以提升频谱效率与提高移动设备接入数量，与传统的正交多址接入不同，22IMT-2030(6G)推进组IMT-2030(6G)Promotion GroupNOMA 允许多个用户共享相同的时频资源,使用不同功率等级来区分不同用户信号,在接收端应用串行干扰消除技术进行多用户检测和解码。功率域复用使 NOMA 可以显著提升用户接入数量和频谱效率。为应对密集组网下的大规模接入场景，提出通过需进一步融合 NOMA 技术及 RIS，探索更先进的多域复用方法，如图 3-14 所示。通过在超密集组网场景中部署多基站和RIS，通过 RIS 设计，覆盖所有用户并降低波束之间的干扰。在每个波束应用 NOMA 技术，提升单波束用户接入能力。进一步地，为提高 RIS 调控精确度，提出基于机器学习辅助的动态 RIS 控制策略。AI 辅助方案可实现在不完全环境信息下对动态反射元件选择、协调离散相移和功率分配系数进行在线优化，以最大化系统能效，同时保障不同用户对数据传输速率、通信可靠性和用户连接的差异化 QoS 需求。图3-14 太赫兹系统可重构接入方法3.4 超大规模天线阵列：MIMO 与智能反射面技术结合3.4.1宽带太赫兹智能超表面通信波束色散管理为解决太赫兹混合波束成形架构中的波束色散问题，已有相关研究考虑联合数字/模拟波束形成和时延线时延来对波束进行扩展和聚拢解决波束色散问题。RIS 预计将引入太赫兹通信系统用于改善信道状态，减少太赫兹直射径阻挡的影响，提高太赫兹信号覆盖。RIS 由于只能调整反射信号相位，也将面临波束色散问题。需要设计基站或 RIS天线结构及其波束资源优化来实现宽带太赫兹 RIS 辅助通信。可采用一种双层时延线(TD)结构用于降低基站波束色散效应，同时有效降低硬件复杂度，双层 TD 与传统单层 TD 架构对比如图 3-15 所示5。23IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图3-15(a)传统移相器结构，(b)单层时延器结构，(c)双层时延器结构。双层 TD 结构可以有效减少 TD 所需的最大延时量。时延范围越大的 TD，涉及额外的插入损耗和放大电路，导致电路硬件复杂度越高。在此基础上，设计了一种基于 RIS位置优化相移和时延的模拟波束形成方案5。通过联合优化模拟/数字混合波束形成、双层 TD 网络时延和 RIS 反射系数，建立 RIS 辅助太赫兹通信的可达速率最大化问题，基于最小均方误差和坐标更新算法交替优化数字波束形成和 RIS 反射系数。由于不同 RIS 大小、形状和部署将引起不同程度的波束分裂效应。RIS 单元数越多，波束色散越严重，相同单元数的条件下，集中式 RIS 比分布式 RIS 波束色散严重；且特定角度的前提下，正方形 RIS 相比矩形 RIS 可以缓解波束色散。因此，提出分布式太赫兹智能超表面部署。在基站应用单层并行 TD 结构，RIS 端部署分布式结构，协同缓解波束色散效应。改变 RIS 部署方式可以缓解 RIS 端波束色散问题，但不能从根本消除波束色散。为了消除波束色散同时扩大覆盖范围，提出一种低硬件复杂度、低功耗的子连接结构的STAR-RIS 架构，即多个 STAR-RIS 单元共用一个 TD，如图 3-16 所示6。通过联合优化模拟/数字混合波束形成、基站时延以及 STAR-RIS 的双层相移系数、时延和幅度系数。方案首先为每个 STAR-RIS 分配用户，得到模拟波束形成、基站时延以及每个 STAR-RIS 处的双层相移系数和时延。再利用交替迭代优化算法获得基站的数字波束形成和STAR-RIS 的幅度系数。仿真分析表明上述设计的基站和 RIS 天线结构可以有效消除波束色散问题，提高系统性能。图3-16(a)分布式STAR-RIS辅助通信;(b)STAR-RIS子连接结构24IMT-2030(6G)推进组IMT-2030(6G)Promotion Group3.4.2超大规模 RIS 辅助的信道估计和定位由于宽带波束分裂效应，波束方向偏移将明显影响太赫兹混合场中的信道估计和定位精度。提出两种定位算法用于缓解远近场混合效应和波束斜视效应对定位与信道估计的影响7。图3-17(a)联合信道和用户位置感知;(b)不依赖于信道估计的位置感知联合信道和位置感知策略包含用于信道估计的定位辅助的广义多测量矢量正交匹配搜索算法（LA-GMMV-OMP）和基于完整词典的定位（CDL）模块，如图 3-17（a）所示。信道估计模块输基于 BS 和 RIS 采集的信息，向定位模块输出一个粗角度估计值。定位模块反馈一个离线的高精度角度估计值用于改进信道估计。联合信道和位置感知策略通过 LA-GMMV-OMP 算法将粗略的角度估计值输出给 CDL 模块用于定位。在CDL 模块中，通过极域梯度下降（PGD）算法来获得从角度的精细离网估计值，并利用极域分层字典（PHD）来获得从 RIS 观测到角度的精细估计值。由此，可以获得精确定位。进一步地，提出一种不依赖信道测量的纯位置感知方案，如图 3-17（b）所示。若只需要用户位置，使用该方案可以进一步减少传感信号开销。为了直接感知用户位置，可使用基于部分字典的定位（PDL）方案。PDL 利用 到达时间差（TDoA）将用户锁定在双曲线上，并将 BS 和 RIS 作为锚点。在双曲线上生成部分频率选择行极坐标冗余词典（FSPRD）获得粗精度角度，然后利用 PGD 算法角度估计的精度。由于用户已被锚点被锁定在双曲线上，所需 FSPRD 的大小和整体算法计算复杂度大幅降低。25IMT-2030(6G)推进组IMT-2030(6G)Promotion Group3.5 波束管理3.5.1RIS 辅助的宽带太赫兹高精度波束训练方法在太赫兹系统中部署智能超表面（RIS）可以形成高增益波束从而增强信号覆盖。在 RIS 辅助的太赫兹宽带系统中，获取信道状态信息是有效利用 RIS 带来的自由度和阵列增益的前提。波束训练是一种常用的信道信息获取方法，通过发射指向不同方向的波束，可以高效地确定用户的方位进行信号传输。然而，在太赫兹宽带波束分裂将导致不同子载波对应的波束指向空间中的不同方向。这导致波束训练精度大幅降低。为提升太赫兹宽带系统中的波束训练精度，提出基于能量分布模式的太赫兹宽带RIS 波束训练方法。分析存在波束分裂的情况下，空间中不同方位的能量分布模式直接解算用户方位，从而提升太赫兹宽带系统下的波束训练精度。在太赫兹宽带 RIS 系统下，波束分裂会导致波束能量在空间的不同角度具有特定的分布模式。这带来了在频率维度可利用信息，可用于提升波束训练的精确度。方案首先设计一对相邻的宽波束用于分析，这对宽波束彼此相邻且具有相同的宽度。在一定的角度范围内，其能量与用户位置成单调关系。利用其接收功率计算，可反推出用户角度，基于此原理设计的码本可实现相比传统方法更高精度的波束训练8。仿真结果如图 3-18所示，所提方法相比传统方法，可以实现更高的可达速率性能。图3-18基于能量分布的太赫兹宽带RIS波束训练性能3.5.2低时延的太赫兹波束管理方法由于太赫兹采用更窄的波束，存在窄波束管理难题。在太赫兹网络中，数据传输分为两个阶段，链路建立和数据传输。在链路建立阶段，太赫兹波束更窄，需要更多的扫描波束个数，扫描时间增长。在数据传输阶段，由于波束极窄，波束更易失准，需要更低时延的波束对建立方案。随着通信感知一体化技术（ISAC）的发展，可考虑开发感知辅助的太赫兹低时延波束管理用于实现 URLLC 通信。目前，多种感知技术都具有应用潜力。能量检测（ED）26IMT-2030(6G)推进组IMT-2030(6G)Promotion Group技术因其简单有效而成为应用最广泛的标准化方法，该方案在采样后进行权重分配，之后计算能量，自适应阈值对比，最后得到判决结果。基于半双工（HD）的 ED 能够在存在干扰的情况下检测用户，基于全双工（FD）的 ED 技术可利用同步通信与感知传输进行碰撞检测。但是，在实际波束扫描过程中，各样本的能量分布并不均匀，需要为不通的样本分配不同的权重。提出首个为 6G 毫米波和太赫兹波束系统设计的 ED 技术，可进一步适应太赫兹窄波束系统，将各样本的概率度量作为实际样本的权重9。采用基于概率的自适应加权传感方法高清和远距离同步感知技术，即 PWS 技术。PWS 根据波束对准和未对准的时间中样本的累积分布函数，自适应设计权重分配，从而补偿能量分布不均造成的影响。PWS 包含两个阶段，如图 3-19 所示。首先是链路建立阶段，采用半双工感知，搜索最佳波束对；2)在数据传输阶段，采用全双工感知，用于随机接入和波束维持等各种功能。在链路建立阶段，选择高精度感知，而远距离感知在随机接入和数据传输阶段执行，同时分别在随机接入信道（RACH）场合或数据帧中发送前置信号。图3-19 PWS感知帧结构为进一步缩短感知检测时间，未来可通过如下方面提升 1）改变 ISAC 帧结构，如引入极短微时隙；2）可修改同步及接入资源配置，如快速波束扫描算法；3）设计适应ISAC 等高层通信算法和协议，如快速的波束调度协议 快速链路中断判别及重建。27IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第四章 系统原型验证4.1 宽带太赫兹高速通信链路和 MIMO 系统在太赫兹通信系统中，随着载波信号频率的增加，带宽资源迅速增大。然而，高速的太赫兹电子集成器件器的带宽、线性度等关键性能均因物理特性而受到一定限制。如电子固态混频器的基带带宽可能仅有数 GHz，相比于太赫兹频带内的带宽资源，该类器件远远无法完整地利用新频谱所带来的优势，且电子固态混频器的较低线性度也对信号有所损伤，难以利用高阶调制提升频谱效率。为实现满足宽带太赫兹高速通信需求，搭建宽带太赫兹高速通信链路和 MIMO 系统，分别测试验证并分析了 D 波段（110-170GHz）和 G 波段（140-220 GHz）的太赫兹宽带高速通信链路和 MIMO 系统的通信性能。图4-1(a)实验系统设置(b)系统实物图系统设置如图 4-1（a）所示，实物如图 4-1（b）所示。发射端和接收端使用的本振频率均为 16.25GHz，通过 8 倍频器得到 D 波段的 130GHz 中心载波，通过 12 倍频器得到 G 波段的 195GHz 中心载波。宽带基带信号由任意波形发生器（AWG）产生，经由可选的预均衡器，送入电子混频器。由电子混频器完成信号的上变频和下变频过程，下变频后的基带信号由数字存储示波器（OSC）采集并送至数字端进行处理。MIMO 系统由四发射四接收组成，通信距离为 0.5 米。我们所使用的调制格式为比特加载的离散多音（DMT）调制，子载波数量为 256 个，有效子载波 248 个。分别对 D 波段和 G 波段系统中的一路信号进行了测试。D 波段单通道的最高传输速率为 135.5Gbit/s，G 波段单通道的最高传输速率为 116.8Gbit/s。进一步对四通道 D 波段和 G 波段太赫兹通信进行测试，测试结果如表 4-1、表 4-2。结果表明，D 波段四通道MIMO 总传输速率可达 475Gbit/s，G 波段四通道 MIMO 总传输速率可达 399Gbit/s。28IMT-2030(6G)推进组IMT-2030(6G)Promotion Group表 4-1有 MIMO 串扰的四通道 D 波段太赫兹通信测试结果CH1CH2CH3CH4总计总速率（Gbit/s）119.3438125.8125117.375112.4063474.9376误码率0.0409740.042690.0385780.03794/净速率（Gbit/s）96.245101.461794.6572690.65024383.0142表 4-2有 MIMO 串扰的四通道 G 波段太赫兹通信测试结果CH1CH2CH3CH4总计总速率（Gbit/s）96.8438114.843886.5313100.875399.0939误码率0.0433790.0449630.0414080.036849/净速率（Gbit/s）78.0998492.6159769.7833181.35081321.8499对 G 波段通信系统进行了室内长距离的太赫兹通信测试。使用了卡塞格伦天线，天线增益为 54.8dBi，测试场景如图 4-2 所示。在 30 米通信距离下，实现 22.21Gbit/s 的通信速率，40 米时为 29.20Gbit/s，在 50 米处可达 32.36Gbit/s 的通信速率。距离越远速率越高，这是由于测试环境没有达到天线的远场工作条件，实际天线增益没有完整地发挥出来。图4-2 室内长距离的太赫兹通信测试我们对 D 波段和 G 波段的宽带太赫兹高速通信链路和 MIMO 系统进行了测试验证与性能分析。在近距离下，D 波段太赫兹通信中心载波 130GHz，单通道速率可达135.5Gbit/s，四通道 MIMO 总速率可达 475Gbit/s。G 波段太赫兹通信中心载波 195Ghz，单通道速率可达 116.8Gbit/s，四通道 MIMO 总速率可达 399Gbit/s。29IMT-2030(6G)推进组IMT-2030(6G)Promotion Group4.2 MIMO 高阶调制系统4.2.1高阶调制系统架构太赫兹系统容量可以通过高阶调制实现成倍的增加，有效提升太赫兹通信系统的综合能效。相比低频和毫米波，受限于太赫兹空间传播特性和太赫兹宽带器件的非理想性，太赫兹高阶调制面临巨大挑战，包括本振的相位噪声，射频器件的带内平坦度和群延迟波动，高功率功放的非线性特性，正交调制器的 IQ 不平衡，以及超高速 ADC/DAC 的交织损伤等，补偿太赫兹频段器件非理想性的如果在模拟域进行，通常会受到稳定性和精度的限制，且设备成本、尺寸、功耗等往往会增加。因此，需要研究低复杂度和低功耗的高性能中射频算法，补偿中射频器件的损伤，使得太赫兹系统在大带宽下也能采用高阶调制。提出一种高谱效太赫兹通信系统架构，支持同时高阶调制和多通道，最大化的提高频谱效率，如图 4-3 所示。采用 2*2 MIMO XPIC 架构，同时采用极化复用和空间复用技术。图4-3 一种高谱效的太赫兹通信系统架构进一步地，针对太赫兹大带宽下的带内不平坦问题，提出太赫兹基带预均衡方案；针对多通道下的分布式的独立相位噪声问题，分布式的相位噪声抑制方案。太赫兹基带预均衡方案如图 4-4 所示。方案通过在发射侧通过预均衡器来补偿 Tx模拟频率响应的高频衰减和信号带内的深衰落凹陷，减轻带宽限制，如所示。因 THz器件的非理想性，在整个信号带宽内，模拟通道带内平坦度呈现不规则波动，因此本提案提出采用预均衡的方法，来改善信道平坦度和对应的 MSE 性能。图4-4 太赫兹基带预均衡方案30IMT-2030(6G)推进组IMT-2030(6G)Promotion Group分布式的相位噪声抑制方案解决在多通道系统中，独立相位噪声产生和接收侧耦合的分布式本振，方案如图 4-5 所示。采用特殊构造的导频码字将混合相位噪声投影到空时正交码空间上。两级主从锁相环（MS-PLL）和准线性插值相位噪声抑制（PNS）算法，在多通道信号空间维度上跟踪和补偿相位噪声，这种低开销（5%导频比例）解决方案，能够有效抑制典型的分布式独立相位噪声。图4-5 分布式的相位噪声抑制方案4.2.2高谱效系统原型验证2022 年，华为公司完成了业界首个室外远距离太赫兹 MIMO 和多用户通信原型系统的研制和验证工作，该原型系统采用固态电子学架构，关键电路基于 III-V 族化合物半导体器件实现，在混频器，倍频器，低噪放等太赫兹关键器件上取得了技术突破,样机工作在 220GHz 中心频点，带宽 13.5GHz，系统采用同时利用极化和空间复用的 4*4MIMO 架构，以及超宽带和低比特量化数字基带处理技术，对基带信号进行信道估计及均衡、非线性补偿、解调和解码。室外实测验证选取城市场景，发射机模拟典型基站架设在楼宇顶层，接收机设置在城市街道地面处，如图 4-6 所示。对于中远距离场景，链路距离约 500 米，实现 240Gbps 高速视距空口传输；对于远距离多用户场景，实现了两用户总吞吐 80Gbps 传输，论证了室外超高速率太赫兹通信技术可行性。图4-6 THz室外远距离通信样机（上），THz室外MIMO通信样机（下）31IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第五章 未来发展5.1 太赫兹远近混合场信号处理技术5.1.1太赫兹远近场效应传统通信信道通常考虑远场通信，采用经典的平面波信道模型（PWM），PWM 把电磁波传播视为为一个平面。一个天线的信道响应可以从它与参考天线之间的相位差中推导出来。而随着太赫兹超大规模 MIMO（UM-MIMO）阵列的应用，阵列尺寸的快速增加以及太赫兹极短波长，太赫兹应用场景的传输距离逼近远场和近场之间的经典界限。在近场下，传统的平面波模型不再适用，需要采用球面波模型（SWM）。例如，在 0.3 THz下、包含 1024 个元素的半波长天线间距的均匀平面阵列（UPA）远近场边界，即瑞利距离，约为 1 米。这个距离在 THz 宽间距多子阵列系统中可能进一步增加到数十甚至数百米。因此，太赫兹通信范围从纯远场渗透到近场，系统需解决远近混合场通信对传统模型的改变。远近混合长通信场景的出现对信道建模和信道估计带来的挑战。在近场下，传统PWM 模型具有不可忽视的建模误差。虽然 SWM 更接近真实信道模型，但是在UM-MIMO 系统中，SWM 的计算复杂度大幅上升。SWM 的信道响应的幅度和相位针对单个天线阵元分别进行计算，所需的参数数量与天线数量和传播路径数量的乘积成正比。例如，考虑在 Tx 和 Rx 处有 1024 个天线，对于稀疏的 THz 信道（少于 10 的信道数），需分析的参数数量将达到107。SWM 和 PWM 所需的参数数目对比如图 5-1（a）所示。然而，由于平面波传播假设造成的相位近似误差，PWM 在近场区域变得不准确，PWM 的模型误差随频率增高而增加，如图 5-1（b）所示。图5-1(a)PWM和SWM需要估计的参数数目对比;(b)PWM模型误差。现有传输技术多数是基于 PWM 或 SWM 设计的，然而，瑞利距离是远场和近场之间的一个近似边界，仅指示近似范围，真实的远近场变化是渐变而非跳跃。因此，为远场或近场的单独设计的建模方案都不能作为太赫兹混合场通信的统一解决方案，适用于太赫兹混合远近场的信道建模和估计方案仍待研究。32IMT-2030(6G)推进组IMT-2030(6G)Promotion Group5.1.2混合球面和平面波信道模型无论是基于 SWM 还是 PWM 的技术，都不适合用于远近混合场信道估计。基于近场 SWM，信道估计必须考虑大量的角度和传播距离信息以确定 SWM 元素的相位，从而导致高度的复杂性。相比之下，在基于 PWM 的设计中，只考虑了角度信息，在近场区域遭受显著的估计和训练精度损失10。为了支持 THz 远近混合场通信，权衡高准确性和低复杂性，提出混合球面和平面波信道模型（HSPM），如图 5-2 所示10。HSPM 结合 PWM 和 SWM 各自的优势，将大规模天线分为多个子阵。在子阵中使用 PWM，由于小阵列的口径小，可以认为传输始终是在子阵列的远场中进行的。因此，采用子阵式的 PWM 建模可减小建模误差。子阵列之间，为了提高建模准确性，采用 SWM 建模。整体上实现太赫兹远近混合场信道建模。兼顾精度与计算复杂度开销，HSPM 可实现在远场和近场区域更优的综合性能。图5-2HSPM示意图就建模复杂性而言，相同路径数下，确定 HSPM 所需的参数数量与子阵列数量成正比。相较于 SWM 所需的与天线数量成正比的参数个数，HSPW 复杂度远小于 SWM。尽管 HSPM 的建模复杂性略高于 PWM，但通过进一步将物理子阵列划分为多个虚拟子阵列，在虚拟子阵列内部部署 PWM，并在建模过程中在虚拟子阵列之间部署 SWM，HSPM 在实现准确性和复杂性的有效的平衡。如图 5-3 所示，HSPM 的精度比 PWM 高约 175 倍，同时它所需的参数量为 SWM 参数数量的 0.01%，是 PWM 和 33 倍。33IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图5-3 HSPM的误差性能。5.1.3基于深度学习的信道估计考虑 HSPM 信道模型特点，提出基于深度卷积神经网络（DCNN）的两阶段的信道估计机制。在第一阶段，估计信道中多径的数目，包括出发和到达的方位角和俯仰角、路径增益的幅度，以及参考子阵列间的通信距离。在第二阶段，通过几何关系分析了参考子阵列与其余子阵列之间参数的关系。结合两阶段信息，重构信道矩阵。具体来说，我们设计了如图 5-4 所示的 DCNN 网络用于阶段 1 的参考子阵列参数估计。网络输入为经过训练后接收到的信号的实数、虚数和绝对值，输出为估计参数，包括角度、距离和路径增益的幅度。在阶段 2，我们通过考虑子阵列间的球面传播特性，推导其余子阵列的参数，基于参考子阵列与其他子阵列之间的几何关系进行角度和距离估计，其中考虑路径增益的幅度在各个子阵列之间是相同的。该方案利用 DCNN 完成参数估计实现了低复杂度，用阵列间的几何关系刻画信道的近场效应，实现了高效信道估计。图5-4 所提信道估计DCNN网络架构。对比传统 OMP、AMP、和基于 CNN、RNN 的方案，DCNN 的实现了最低的信道估计归一化均方误差（NMSE）。在 SNR（信噪比）=0 dB 时，其 NMSE 比 RNN 低 6 dB。34IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图5-5 基于DCNN的信道估计方案的误差性能5.1.4基于压缩感知的信道估计在混合天线架构下，射频链路（RF）数量受限。为用少量的 RF 获得高维信道估计，通常需要多次的导频传输，增大了导频开销。为了解决这个问题，在远场和近场通信中可采用基于压缩感知（CS）的信道估计方法。CS 利用 THz 无线信道的稀疏性，从压缩观测中恢复高维信道矩阵，降低导频开销。基于 CS 的信道估计需要设计码本对信道进行稀疏表示。每个采样点对应一个码字。通过收集这些点的阵列指向矢量来构造稀疏码本。由于网格的数量通常远大于传播路径数，因此信道可以被稀疏表示。基于 SWM 的近场传输中，角度和距离维度都会被采样，然而二维采样导致过多的码本维度，从而带来巨大的复杂度。对于 PWM 模型，由于其对角度的近似，在角度域进行一维采样就足够组成码本，但是会导致明显的误差。为结合 SWM 模型和 PWM 模型各自优势，基于 CS 的信道估计可以利用子阵架构特性11。考虑 PWM 特性，在每个子阵列内，一条路径的入射角被认为对所有子阵列元素是相同的。因此，对子阵列信道的角度域进行采样以组成一个子阵列码本。考虑 SWM特性，在不同的子阵列之间，考虑一条路径的入射角对不同的子阵列是不同的。因此，不同子阵列的角度采样是独立的。基于子阵列的 CS 信道估计算法可以稀疏表示太赫兹远近场混合信道。与基于 PWM 的传统解决方案相比，所提出的稀疏表示方法具有相同的复杂性，但在近场具有更高的准确性。与基于 SWM 的联合角度和距离域稀疏表示相比，所提出的码本的计算复杂性显著降低。为进一步降低复杂度，利用子阵列间的空间相关性，提出字典缩减估计（DSE）算法。该算法借助不同子阵列的入射角在空间域内相近的特性降低搜索范围，以进一步降低复杂性。35IMT-2030(6G)推进组IMT-2030(6G)Promotion Group5.2 感知协同太赫兹 MIMO 通信5.2.1感知协同的 MIMO 通信性能界太赫兹极窄波束对波束对准精度和对准时延提出了更高的要求。在移动通信场景中，太赫兹超大规模 MIMO 通信中波束方向需要依据用户运动进行实时调整，即波束追踪。传统波束训练方案在进行波束追踪前预先设置所有可能的波束方向，在追踪中需要根据码本逐一匹配，并选取当前的最优波束。但为支撑太赫兹极窄波束，波束训练的码本开销巨大，并且在窄波束通信下，信道呈现非平稳高时变特性，传统信道预测方案也不再适用于太赫兹 MIMO 通信。为降低导频开销和码本复杂度，提出使用感知协同技术波束追踪12。感知协同方案以感知信息作为通信的先验信息，一方面减少通信系统上行反馈的开销，简化通信协议流程，另一方面可利用感知信息构造与信道环境强相关的码本空间，极大降低复杂度。当前感知协同通信技术主要可以分为如图 5-6 所示的基于信道感知的波束追踪、基于回波感知的波束追踪与基于带外感知的波束追踪三大类。图5-6 不同感知协同部署追踪基于信道感知的波束追踪通过利用通信系统内生感知能力直接在信道中提取感知参数。由于太赫兹信道具有一定的确定性特征，可以反映通信中收发双方的实际物理特征，因此可以通过信道获得用户运动信息。基于回波感知的太赫兹波束追踪不依赖于上行信号反馈，可以直接通过对发射信号回波的处理实现对用户位置、速度的估计。由于不需要额外的导频开销，此类追踪方案能够降低通信系统，高层通信协议的复杂度，实现高效的通信。基于带外感知协同的太赫兹通信需要结合不同的系统，如 sub-6G、雷达、可见光等36IMT-2030(6G)推进组IMT-2030(6G)Promotion Group其他频段与太赫兹频段结合进行用户的追踪。当前基于视觉精度高、技术成熟、应用范围广等优势，使用视觉辅助的太赫兹通信依然是带外感知的研究热点。但是由于基于深度学习等启发式算法的加入，需要采集不同场景下的大量数据，具有较高挑战性。为优化感知协同部署方案，需要探索感知协同太赫兹超大规模 MIMO 通信的性能界限。传统的感知和通信指标通常在物理意义和量纲上是分离的。为了联合表征和优化通信与感知性能，需要采用太赫兹通感联合指标。候选指标可分为以下几类，总结如图5-7。1)面向感知的指标：基于统计理论的克拉美罗界（CRB）用于感知领域限定参数估计方差下界。可以对应定义通信 CRB 作为接收信息比特方差的下界。另一方面，自由度（DoF）用于体现感知分辨率，而通信中的自由度则用于指示移动通信可用资源。2)面向通信的指标：香农容量是最为典型的通信速率的上界指标。互信息可与香农容量作联合优化。衡量在一段时间间隔内感知从信道中提取的条件互信息可作为感知的有效性指标；基于率失真理论，可采用估计速率来表征参数估计的精度；此外，面向目标探测的测距、测角与测速，也出现了雷达容量的新定义指标。3)面向信号的指标：对于受杂波影响的雷达系统，可以用杂波噪声比（CNR）来表征其性能。例如利用状态噪声比（StNR）来表征从信号中提取的目标参数，从而用于优化太赫兹感知协同通信的性能。考虑空域或频域的特征，可以利用峰旁瓣比（PSLR）或峰均功率比（PAPR）来描述波束的功率分布特性。4)通感联合指标：为了实现通信与感知性能之间的最佳折中，计算估计速率和香农容量的加权和是一种常见的方法。对应的，联合 CRB 也可用于体现联合通感性能上界。图5-7 通信感知一体化研究中的性能指标37IMT-2030(6G)推进组IMT-2030(6G)Promotion Group现有联合指标大多面向通信与感知间的性能制约，但在感知协同 MIMO 通信中，需提出衡量感知信息对通信性能的增益性能的新指标。在感知协同太赫兹通信中，通信与感知的性能关系由增强因素与制约因素两方面组成。其中，增强因素随着雷达速率增加而减弱，而制约因素随着雷达速率增加而增强。可根据感知的辅助增益以及感知的开销在网络中的主导趋势变化，将通信速率表示为估计速率的闭式分段函数作为联合性能表征函数13。所得分段函数如图 5-8 所示，其拟合结果在通信速率和通信最优点均约等于理论真值，具有实用性。图5-8 感知协同太赫兹通信闭式表达式与理论真值对比5.2.2感知协同波束赋形技术虽然已有提出基于真时延器的混合波束赋形架构来补偿太赫兹波束分裂效应的影响，但是在大规模 MIMO 引入真时延器会导致较大的硬件功耗。因此，提出一种感知协同的太赫兹宽带混合预编码方案。通过感知波束色散程度，建立完备信道字典对非完备信道状态信息进行补偿，最后实现模拟预编码和数字预编码的联合优化，如图 5-9 所示。图5-9 感知协同太赫兹宽带波束赋形方案示意图为解决多用户场景中有限RF链条件下的波束色散问题，提出动态分配RF链的方案提高系统的谱效和能效，降低系统总功耗，结构如图 5-10 所示。利用信道稀疏性，可38IMT-2030(6G)推进组IMT-2030(6G)Promotion Group以在全连接结构的超大规模MIMO阵列天线结构中引入开关网络。由于射频链的数目远小于天线数目，因此开关网络规模很小，有效减少系统功耗。提出针对该架构的RF链路优化算法，算法提出动态射频链和动态功率分配方案，在满足通信速率需求下减少所需接入射频链路数量。相比于基于TTD的混合预编码方案和基于部分CSI的混合预编码方案，性能增益提升 50%，略差于基于完备CSI的混合预编码方案。图5-10全连接的混合预编码系统结构5.2.3感知协同的波束追踪技术波束追踪对维护用户链路稳定、提升通信服务质量至关重要。太赫兹极窄定向波束覆盖距离变短，需要精准波束追踪与高速切换，对于波束追踪算法性能提出了更高的要求。传统波束追踪上行链路反馈时延大，导致 CSI 获取不及时，波束方向严重滞后。为解决该挑战，提出基于基带波形设计的感知协同波束追踪技术。方案通过挖掘信号波形设计特性，在不对系统进行硬件层面的调整下，实现感知参数的获取。正交时频空调制（Orthogonal Time Frequency Space，OTFS）调制技术在时延-多普勒域传输信息。相较于传统 OFDM 调制技术，OTFS 调制技术不但能够在高速运动场景下获得更好的抗多普勒频偏性能，也能够获得当前用户运动的距离与速度，进一步增强通信系统感知能力。基于 MIMO-OTFS 的信道追踪方案架构如图 5-11 所示。图5-11MIMO-OTFS太赫兹信道追踪架构图感知协同方案步骤如下。第一步进行信道估计与初始化波束对准。为保证感知数据的可靠，要求精确的 CSI 以实现准确的波束赋型。利用太赫兹时延-多普勒-角域信道呈现块状稀疏性的特性，采用压缩感知算法进行信道恢复。第二步提取用户的感知信息，39IMT-2030(6G)推进组IMT-2030(6G)Promotion Group并对用户运动状态进行预测。MIMO-OTFS 中信道包含时延-多普勒-角度三维信息。时延、多普勒与虚拟角度可以通过线性变换得到用户实际距离、速度与物理角度，基于感知参数分析和利用卡尔曼滤波技术实现对用户未来运动状态的可靠追踪。第三步预测用户运动，将用户运动状态转化为太赫兹信道状态信息。基于太赫兹信道的强确定性特征，可以通过反演实现推断当前太赫兹信道状态信息，并基于此信道状态信息进行波束赋型。考虑到感知资源与通信功能形成资源竞争，利用 RGB/深度相机进行辅助通信开始受到广泛关注，即视觉辅助的太赫兹超大规模 MIMO 波束追踪。考虑多接入和用户不确定性问题，提出视觉辅助的多用户波束跟踪算法。基于机器学习框架，方案利用历史视觉信息以及波束信息，对场景中所有用户未来时刻的波束生成矢量进行预测，以降低太赫兹通信系统在波束赋形过程中的开销。图5-12视觉辅助的太赫兹超大规模MIMO波束追踪方案流程图如图 5-12 所示，视觉辅助的波束追踪方案包括以下步骤。首先，进行数据预处理，将信道状态信息转化为波束码本索引和将历史信息组合成序列。第二步，利用通过视觉特征提取获得视觉感知特征。采用 CSPDarknet53 网络作为视觉特征提取模块，在目标检测任务中特征提取能力显著，且存在预训练模型，可以避免完全重新训练。第三步，通过时序特征信息提取模块获得连续时隙内波束的变化信息，将图像特征与波束特征分别提取，再将两者输出特征进行拼接。第四步，输出的是图像与波束的拼接特征，使用构建多层感知器解决从图像波束序列特征到多用户波束分类的映射问题。5.3 数据驱动太赫兹高速传输技术5.3.1 数据驱动的物理层技术太赫兹器件非理想特性十分显著且复杂,不同的模拟电路元器件在通信性能上的差异也愈发明显。即使同一个器件，受不同的温度和湿度等工作环境的影响，非理想特性也有偏差。因此，很难建立基于统计的离线模型对太赫兹传输系统中存在的非理想特性40IMT-2030(6G)推进组IMT-2030(6G)Promotion Group进行有效建模；而不准确的非理想特性模型必将大大降低太赫兹传输系统的性能。提出基于数据驱动的太赫兹通信物理层技术，根据实际传输数据对通信信道和器件非理想特性进行学习和实时拟合，来优化收发端的物理层，进而实现比特的有效传输。这使得无需进行统计建模，规避了太赫兹信道和非理想特性难以准确建模的难题。特别地，基于数据驱动的太赫兹传输系统通过端到端（End to End）的方式学习得到，不需要严格的模块化划分，系统结构简单而且在时变信道下泛化性能更好，更适合移动接入等时变性强的太赫兹通信场景。具体的，提出了基于二值神经网络（BNN）模型和生成对抗网络（GAN）训练方法的传输系统，结构如图 5-13 所示。具体包括数据驱动的调制解调、信道估计和信道编解码等物理层模块的神经网络模型构建、训练方法、轻量化设计等内容。在未知太赫兹信道模型的情况下，可以有效训练发送端和接收端，取得优于现有 QAM 调制解调的性能。运算和存储复杂度均降为现有的卷积神经网络系统的 20%。对比传统方法，数据驱动方案最高性能优势可达 10 倍以上。随相位噪声强度增大，BNN GAN 性能越发接近复杂度高的 CNN 方法。在性能相当的情况下，网络参数量和计算复杂度只有原数据驱动方法的 20%。图5-13传输模型的神经网络结构5.3.2 数据驱动的传输和高速业务一体化技术图像视频是太赫兹传输承载的重要内容。现有的图像传输方案是将此任务分为图像压缩和比特传输。前者的目标是高压缩率和良好的重建质量，后者的目标是高效无差错传输。传统任务采用分离的信源编码和信道编码。然而，太赫兹信道具有时变性。在通信资源有限的情况下，物理层很难及时适应变化的信道，接收到的数据会发生位翻转。位传输错误可能导致接收图像损坏且难以恢复甚至触发重传请求。通过在图像压缩和重建期间考虑当前传输条件，可以实现更鲁棒的图像传输。41IMT-2030(6G)推进组IMT-2030(6G)Promotion Group针对高清图像视频等高速业务信息实时传输场景，研究基于数据驱动的太赫兹传输和高速业务一体化技术，来实现更加鲁棒和自适应的传输效果。具体地，该一体化技术根据当前数据传输状况，动态调整高清图像、视频和语音等多媒体信息编解码过程，并重点保护高速业务中的高价值多媒体信息，其架构如图 5-14 所示图5-14面向高速业务的数据驱动太赫兹传输系统结构为实现高清图像的高速传输，提出一种基于生成对抗网络（GAN）训练的基于神经网络的图像传输系统，以实现对信道条件变化的鲁棒性，可应对太赫兹信道变化快特性。基于 GAN 的训练方法有望使接收器适应当前传输条件并恢复原始图像。面对不同传输条件下时变的太赫兹信道，该技术具备更优良的抗突发错误的能力，进而有望实现更加鲁棒和自适应的高清业务传输效果。在移动接入等时变性强的太赫兹传输场景下，基于数据驱动的传输和高速业务一体化技术有望实现更加高效、鲁棒和自适应的高速业务传输效果。42IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第六章 参考文献1黄宇红,刘盛纲,杨光,等.5G 高频系统关键技术及设计M.人民邮电出版社,20182Z.Zhang,H.Li,Y.Dong,X.Wang and X.Dai,Decentralized Signal Detection via ExpectationPropagation Algorithm for Uplink Massive MIMO Systems,in IEEE Transactions on VehicularTechnology,vol.69,no.10,pp.11233-11240,Oct.2020.3Y.Dong,H.Li,Z.Zhang,X.Wang and X.Dai,Efficient EP Detectors Based on Channel Sparsificationfor Massive MIMO Systems,in IEEE Communications Letters,vol.24,no.3,pp.539-542,March 2020.4H.Li,Y.Dong,C.Gong,X.Wang and X.Dai,Decentralized group wise expectation propagation detectorfor uplink massive MU MIMO systems,IEEE Internet Things J,vol.10,no.6,pp.5393-5405,Mar.2023.5G.Sun,W.Yan,W.Hao,C.Huang,C.Yuen,Beamforming Design for the Distributed RISs-aidedTHz Communications with Double-Layer True Time Delays,IEEE TVT.(Major Revision)6W.Yan,W.Hao,C.Huang,et al.Wideband Beamforming for STAR-RIS-assisted THz Communicationswith Three-Side Beam Split.7Z.Li,Z.Gao and T.Li,Sensing Users Channel and Location with Terahertz Extra-Large ReconfigurableIntelligent Surface under Hybrid-Field Beam Squint Effect,in IEEE Journal of Selected Topics in SignalProcessing.doi:10.1109/JSTSP.2023.3278942.8Y.Chen,J.Tan,M.Hao,R.MacKenzie,and L.Dai,Accurate beam training for RIS-assisted widebandterahertz communication,IEEE Trans.Commun.,2023.9J.Zang,Q.Liu,J.He and G.Wang,On Spectrum Sensing for mmWave and THz Beam basedCommunications,2023 IEEE 97th Vehicular Technology Conference(VTC2023 Spring)Spring),Florence,Italy,2023,pp.1 6,doi:10.1109/VTC2023 Spring57618.2023.10199957.10 Y.Chen,L.Yan,and C.Han,Hybrid Spherical-and Planar-Wave Modeling and DCNN-poweredEstimation of Terahertz Ultra-massive MIMO Channels,IEEE Trans.Commun.,vol.69,no.10,pp.70637076,Oct.2021.11 Y.Chen,R.Li,C.Han,S.Sun,and M.Tao,Hybrid Spherical-and Planar-Wave Channel Modeling andEstimation for Terahertz Integrated UM-MIMO and IRS Systems,IEEE Trans.Wireless Commun.,toappear 2023.12 K.Meng,Q.Wu,W.Chen and D.Li,Sensing-Assisted Communication in Vehicular Networks WithIntelligent Surface,IEEE Trans.Veh.Technol.,early access,2023.13 Z.Liu,C.Yang,Y.Sun,and M.Peng,Closed-Form Model for Performance Analysis of THz JointRadar-Communication Systems,IEEE Trans.Wireless Commun.,early access,2023.43IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第七章 主要贡献单位表7-1主要贡献单位序号序号主主要要贡献单位贡献单位1电子科技大学2上海交通大学3中国联通4诺基亚贝尔实验室5北京科技大学6武汉大学7北京理工大学8郑州大学9华为技术有限公司10清华大学11复旦大学12北京邮电大学

0人已浏览 2023-12-15 43页 5星级

北京稻壳科技有限公司Beijing Rice Hull Technology Co.,Ltd.地址：北京市朝阳区九住路 188 号IMT-2030(6G)推进组IMT-2030(6G)Promotion Group2023 年年 12 月月版权声明版权声明 Copyright Notification未经书面许可未经书面许可 禁止打印、复制及通过任何媒体传播禁止打印、复制及通过任何媒体传播2023 IMT-2030（6G）推进组版权所有2IMT-2030(6G)推进组IMT-2030(6G)Promotion Group目录图目录.5表目录.7第一章 引言.8第二章 语义通信适用场景与技术需求.102.1 场景一：全息视频通话.102.2 场景二：自动驾驶.112.3 场景三：智能医疗.122.4 场景四：卫星通信.122.5 场景五：工业互联网.13第三章 语义通信网络架构.153.1 语义通信的系统框架与性能极限.153.1.1 引言.153.1.2 研究进展.163.1.3 结论.203.2 基于语义转换的通信系统.203.2.1 引言.203.2.2 研究进展.213.2.3 结论.22第四章 语义通信理论.244.1 语义感知的联合信源信道编码及其性能分析.244.1.1 引言.244.1.2 研究进展.244.1.3 结论.264.2 面向任务的信号量化理论.264.2.1 引言.264.2.2 研究进展.274.2.3 结论.284.3 基于图结构的语义表征模型与压缩理论研究.294.3.1 引言.294.3.2 研究进展.294.3.3 结论.30第五章 联合信源信道编码技术.315.1 弱耦合下的信源信道联合编码技术.315.1.1 引言.315.1.2 研究进展.325.1.3 结论.345.2 面向深度联合信源信道编码的信道自适应设计.345.2.1 引言.345.2.2 研究进展.353IMT-2030(6G)推进组IMT-2030(6G)Promotion Group5.2.3 结论.375.3 面向 CSI反馈的深度联合信源信道编码设计.375.3.1 引言.375.3.2 研究进展.375.3.3 结论.395.4 面向多模态数据传输的目标语义通信技术.395.4.1 引言.395.4.2 研究进展.405.4.3 结论.415.5 多级语义信息辅助下的图像无线传输系统.425.5.1 引言.425.5.2 研究进展.425.5.3 结论.445.6 用于多任务图像传输的语义通信系统.445.6.1 引言.445.6.2 研究进展.445.6.3 结论.455.7 面向语音的高效语义通信系统.465.7.1 引言.465.7.2 研究进展.465.7.3 结论.485.8 基于 GAN 逆方法的高效图像隐私传输语义通信.485.8.1 引言.485.8.2 研究进展.485.8.3 结论.505.9 面向点云分类任务的预训练鲁棒语义通信系统.505.9.1 引言.505.9.2 研究进展.515.9.3 结论.525.10 非线性变换信源信道联合编码.535.10.1 引言.535.10.2 研究进展.545.10.3 结论.605.11 生成式的联合信源信道编码模型.605.12 波束质量上报.61第六章 语义通信的物理层技术.636.1 面向语义通信的信道表征学习与自适应调制.636.1.1 引言.636.1.2 研究进展.636.1.3 结论.656.2 联合语义编码与数字调制.656.2.1 引言.654IMT-2030(6G)推进组IMT-2030(6G)Promotion Group6.2.2 研究进展.666.2.3 结论.686.3 基于卡尔曼滤波的端到端空口设计.686.3.1 引言.686.3.2 研究进展.706.3.3 结论.73第七章 语义通信的链路层技术.747.1 面向语义通信的混合自动重传请求和语义相似度检测.747.1.1 引言.747.1.2 研究进展.747.1.3 结论.767.2 动态数据环境下的语义通信系统.777.2.1 引言.777.2.2 研究进展.777.2.3 结论.797.3 针对联合信源信道编码系统容量优化的资源分配算法.797.3.1 引言.797.3.2 研究进展.807.3.3 结论.827.4 深度图像语义传输系统的自适应速率控制.827.4.1 引言.827.4.2 研究进展.837.4.3 结论.84第八章 语义通信的安全机制.858.1 具备隐私保护功能的加密语义通信系统.858.1.1 引言.858.1.2 研究进展.858.1.3 结论.878.2 基于数据混淆的语义信息安全传输机制.878.2.1 引言.878.2.2 研究进展.888.2.3 结论.89第九章 总结.90参考文献.93致谢.98附录：缩略词表.995IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图目录图 3-1 语义通信的通用系统模型.16图 3-2 柯尔莫哥洛夫复杂度示意图.18图 3-3 不同英文语料库的语义压缩率的编码结果.19图 3-4 经典编码传输和语义编码传输的典型序列对比.19图 3-5 基于联合训练的语义通信系统.21图 3-6 基于语义转换的语义通信系统.22图 4-1 语义感知的联合信源信道编码模型22.25图 4-2 语义感知的联合信源信道编码错误概率的上下界刻画.26图 4-3 面向任务的量化系统设计框架.28图 4-4(a)原始图像；(b)基于图结构的语义统一表征.30图 5-1 经典通信系统架构。.33图 5-2ADJSCC 网络结构.35图 5-3AF 模块结构.36图 5-4 带宽利用率为 1/12 时 ADJSCC与 BDJSCC性能.36图 5-5ADJSCC-CSI 框架.38图 5-6=32 时 ADJSCC-CSINet 与基于 SSCC 的 CSINet 性能对比.39图 5-7 面向物联网边缘端的多模态目标语义通信框架.40图 5-8 面向人体动作识别的视频联合信源信道编码.40图 5-9 面向加速度数据和视频的多模态传输控制机制.41图 5-10 图像语义通信系统的整体架构.43图 5-11（a）编码器模块、解码器模块（b）图像重建模块.43图 5-12 通道注意力机制.43图 5-13 系统的总体架构.44图 5-14 注意力模块的架构.45图 5-15 fine 模块和 dual features 模块.45图 5-16 基于深度学习的语音语义通信结构.46图 5-17 错误率和句子相似度对比图.47图 5-18 额外语音信息重建结果.48图 5-19 基于 GAN逆方法的高效图像隐私传输语义通信结构.49图 5-20 客观评价指标对比图.50图 5-21 主管评价指标对比图.50图 5-22 隐私保护效果图.50图 5-24 不同信道条件下的点云分类准确率图.52图 5-25 不同压缩效率下的点云分类准确率图.52图 5-27 非线性变换联合信源信道编码流程及对应的概率建模.55图 5-28 传输图像带宽分配结果.57图 5-29 PSNR 与 AWGN信道不同 SNR 的关系.58图 5-30 MS-SSIM 与 CBR 和 SNR 的关系.596IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图 5-31 SNR=10dB 的 AWGN信道上 LPIPS 与 CBR 的关系.59图 5-32 Generative JSCC模型.60图 5-33 图像语义通信的实际部署.61图 6-1 自适应调制与信道信息指导的语义图像传输系统结构.64图 6-2 基于语义分割的图片传输系统性能比较.64图 6-3 学习到的星座点与相似度性能比较.65图 6-4 联合编码调制系统框图.66图 6-5 不同 SNR和调制方式下的系统性能.67图 6-6 端到端智能通信系统66.69图 6-7 卡尔曼滤波端到端智能空口.70图 6-8 RBF 下 10000迭代的误码率.73图 7-1 SCHARQ结构和单次传输的编解码和校验过程.75图 7-2 编码器和解码器的具体结构.75图 7-3 SCHARQ与其他方案的性能对比.76图 7-4 基于数据自适应网络的语义通信系统.78图 7-5 数据自适应网络架构.78图 7-6 数据自适应性能展示.79图 7-7 数据自适应转化的可视化效果.79图 7-8 语义通信网络示意图.80图 7-9 系统支持用户数随功率变化图.82图 7-10 深度图像语义传输系统自适应速率控制方案框图.83图 8-1 加密语义通信系统的结构.85图 8-2 加密器和解密器的结构.86图 8-3 对抗训练方式下的损失函数，和.87图 8-4 非对抗训练方式下的损失函数，和.87图 8-5 语义信息随机混淆方案.89图 8-6 基于数据混淆的语义信息安全传输性能验证.897IMT-2030(6G)推进组IMT-2030(6G)Promotion Group表目录表 3-2 语义信息的度量指标体系.17表 9-1 主要贡献单位.988IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第一章 引言自从 1948 年香农奠基信息论以来，现代通信技术，特别是移动通信技术的发展已经逐步逼近理论极限，例如信源编码技术已经逼近信源熵率失真函数，而信道编码技如 LDPC 码、极化码等也已逼近信道容量。近来，各种新的互联网应用不断出现，例如虚拟现实、自动运输、消费机器人、环境监测和远程健康。这些应用程序的互连将产生惊人的字节数量的数据。此外，这些应用程序需要在有限的频谱资源上支持大规模连接，但需要较低的延迟，这对传统的信源信道编码提出了严峻挑战。建立在概率信息基础上的通信系统，迫切需要技术突破与变革，才能应对未来 6G 移动通信的发展需求。通信真正的目的是通过通信双方交互使接收方理解发送方的信息内容，即“达意”通信。香农早已定义信息所表示的内容为“语义”。Weaver 进一步研究通信的深层含义,并提出了三个层次的通信:第一层次为技术问题,它主要解决“通信符号如何准确传输”的问题;第二层次为语义问题,它主要解决“传输的符号如何精准传达含义”的问题;第三层次为效用问题,它主要解决“收到的含义如何以期望的方式有效影响行为”的问题.自香农建立信息论以来的七十多年,学者们就如何逼近香农限做出了大量卓越贡献,这些工作主要集中在第一个层次.近几年,随着人工智能、自然语言处理等相关支撑技术的快速发展,通信设备的智能化水平和对外界的认知能力不断增强,为深入开展第二层次的语义通信问题研究提供了可能，语义通信也逐渐成为通信领域的一大研究趋势1。与传统通信相比，语义通信可以通过提取数据的含义，过滤掉无用、无关和非本质的信息，从而在保留数据语义的同时进一步压缩数据，进而减少传输的信息量，降低了对信道带宽的要求2。此外，语义通信还有希望对恶劣的信道环境，即低信噪比区域具有鲁棒性，这非常适合要求高可靠性的应用。面向语义的通信系统已被公认为下一代无线通信的一个有前景的方向3。语义通信与传统通信的最大区别在于语义通信有存在于发送端和接收端的共享知识，发送端基于共享知识从信源信息中提取语义信息，接收端基于共享知识根据语义信息进行信息重建，从而减少需要传输的信息量4。在实际的通信系统设计中，编码器和译码器的模型参数就相当于共享知识5。概括而言，语义通信是指通信双方具有“语义共识”前提条件下基于“语义先验”的“语义可达”意义上的通信。这些语义共识通过所谓语义字典、语义知识库等表征刻画，可在通信之前事先建立或者随通信过程逐步动态构建，并不断更新；而语义先验则提供了关于9IMT-2030(6G)推进组IMT-2030(6G)Promotion Group语义信息内涵和通信场景的层次化结构特征和相应的统计关联描述，这也是语义信息得以压缩的根源。语义可达性即语义层面的可靠性和一致性，是语义通信最基本的目标，同时也正因为语义一致性、关联性的约束而为其它底层的通信方式带来特殊的校验和纠错方式，从而降低了对底层通信能力的需求。正因为如此，语义通信具有其适用的场景。语义通信当前面临的基础问题主要包括：如何利用语义知识实现数据压缩和可靠通信?语义编译码如何与现有经典编译码问题构建联系?语义编码是否存在与第一层次通信系统中与香农限相类似的上限值?应该考虑采用什么指标表征语义通信系统的有效性和可靠性?目前一部分工作从语义信息论角度探讨了语义通信压缩编码问题。Carnap6等首先提出了基于逻辑概率的语义信息理论。Bao7等定义了语义通信无损压缩编码过程中诸多概念(例如语义噪声、语义冗余等)和通用语义通信模型，并设计了度量语义信息的方法。Juba8等基于收发两方字符出现先验概率分布可能不一致的前提条件下设计了有损压缩编码方案，并通过信息论证明了模糊性对于压缩的必要性。Guler9等引入第三方，利用博弈论方法从语义相似度角度设计有损压缩编码方案，其目标为最小化端对端平均语义错误。另一些工作从具体语义编译码模型设计出发，主要采用深度学习方法、自动编译码结构实现文本、图片等语义通信系统。Xie 等人10提出基于深度学习的文本传输语义通信系统DeepSC 和适用于物联网的 Lite 分布式语义通信系统 L-DeepSC 提高系统容量和减少语义错误。Bourtsoulatze 等人11提出基于深度学习的图片传输语义信源信道联合编译码设计。Weng 等人12在 DeepSC 的基础上提出语音传输语义通信系统并证明其在低信噪比下具有良好的传输性能。Shi 等人13提出一个面向语义保真度的通信框架并设计了一个面向语义保真度的音频传输实例。在 IMT-2030（6G）推进组的统一安排下，无线技术工作组无线 AI 任务组就语义信息理论和语义通信具体实现及其应用开展了深入调研分析，以为下一步开展相关研究提供指导和思路。本报告在对当前国内外的主要研究状况进行调研分析的基础上，结合部分成员单位在语义通信上的一些研究工作，对语义通信的一些应用场景、若干研究方向及其关键技术进行了较为全面地分析和讨论，同时探讨了语义通信的难点、挑战和产业化前景。10IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第二章 语义通信适用场景与技术需求作为未来通信技术的潜在发展方向，语义通信的主要技术特征包括：信息传递与信息理解一体化、实时语义保真的通信质量、支撑强智能体协同通信等。语义通信以节点智能为基础，赋予节点类人感知能力，实现达意传输，满足人-机-物之间的敏捷交互。6G和人工智能(AI)时代的许多应用，如智能终端、机器人、智能监控，能够理解场景并自动执行指令。因此，面向任务的语义通信的核心是深层次发语义层面的保真度，而不是浅层的比特传输的精度。语义通信框架有可能适用于工业互联网、智能交通、视频会议、在线教育、增强现实(AR)、虚拟现实(VR)等领域的一些特殊应用场景。2.1 场景一：全息视频通话全息通信传输的流媒体对网络带宽的需求将达 Mbit/s 级。摄像头传感器（如微软KinectforWindowsv2）输出的 1080P 图像，每个像素有 4byte 的彩色数据，深度图像的分辨率为 512dpi424dpi，每个像素有 2byte 的深度数据，相当于每帧 70.4MB 的原始数据。并且，随着传感器和视点数量的增加，在更高的分辨率和帧速率下，需要的网络带宽会更高。对于 70 英寸显示屏，全息通信需要约 1Tbit/s 的网络带宽。与 AR/VR 等强交互沉浸式应用的要求相同，为了让用户获得身临其境的感觉，全息通信要求网络必须提供小于 1ms 的端到端时延。语义通信在发送端可以剔除与任务相关性较低的数据，从而在保证服务质量（QoS）的基础上，显著降低所需的通信资源。在全息视频通话的应用场景中，信道必须传输大量的全息视频流数据，同时要确保清晰的画面和极低的延迟以保证用户的体验质量（QoE）。实际上，当网络环境不理想时，视频通话的画面通常会出现模糊，有时甚至卡顿，这极大地影响了用户的使用体验。语义通信可以通过在发送端使用预训练模型对视频数据进行特殊压缩，保留对 QoE 至关重要的特征信息，从而最大限度地减少冗余信息在整体数据中所占比例。由于全息视频通话主要传输的是人脸信息，而人脸特征在计算机视觉领域已经被广泛研究，因此，语义通信在视频通话场景的应用具有坚实的研究基础。通过进一步压缩与 QoE 关联度较低的数据，可以有效提高视频通话的 QoS，从而极大地提升用户的视频通话体验。在全息视频通话场景中应用语义通信，最主要的关键技术为自适应的人脸特征提取模型。11IMT-2030(6G)推进组IMT-2030(6G)Promotion Group所谓人脸特征提取，即该模型需要精准保留对 QoE 影响较大的人脸关键数据，同时压缩冗余的部分。所谓自适应，是指该模型需要根据双方用户的网络环境实时调整语义压缩率，以在网络条件允许的范围内，最大程度地提升 QoE。语义通信在全息视频通话场景的应用具有巨大的产业化应用前景。当前主流的即时通讯软件，例如微信、钉钉等，都配备了视频通话功能，而像腾讯会议、钉钉会议这样的在线会议平台也能从这项技术中获益。目前，人们对视频通话的需求普遍增加，语义通信在视频通话中的产业化应用将极大地提升大众用户的 QoE。但是该技术也存在着一些局限性。首先，该技术仅在网络环境不佳时对 QoS 有显著提升，适用场景包括山区、水域、人流密集场所等。其次，当视频通话内容为人脸以外的画面时，其增益较小。2.2 场景二：自动驾驶基于车联网通信技术（V2X，Vehicle to Everything）的车联网（IoV，Internet of Vehicle）是自动驾驶领域的关键基础。但是在实际应用中，这种传统技术需要用户和设施之间进行频繁的数据交换，使计算资源紧缺，此外在自动驾驶的决策过程中要求极高的感知准确性和极低的延迟。为了实现高智能的完全自动驾驶，边缘智能技术被应用在车联网中，边缘智能将AI，通信网络和移动的边缘计算无缝集成在一起15，通过均衡的资源支持和更复杂的模型，可以显著增强整个系统的计算能力和存储容量，促进基于 AI 的处理和决策，在该架构下产生了大规模数据传输的挑战，包括多模态数据传输和融合，多用户协作和连接，以及多任务训练和执行。语义通信由于其在传输效率方面的显著优势，可以解决上述问题。将用户的需求和数据的语义信息集成到数据处理和传输的过程中，只传输面向接收端任务的必要信息，可以提高传输效率和可靠性。同时，通过构建一个通用的、可理解的语义知识库，增强了系统对噪声和干扰的鲁棒性，使其能够连接各种类型的设备，提高了传输的可靠性有望解决由于信息形式不一致而导致的不兼容问题，方便不同类型设备之间的连接。此外，由于其面向任务的性质，自动驾驶的效率也可以提高。语义通信在自动驾驶领域已有很多相关研究，16中提出了支持车辆自组织网络(VANET)动态更新的语义感知空间关键字搜索方案。该方案提取对象的潜在语义特征，并通过使用 LDA（Latent Dirichlet Allocation，潜在狄利克雷分配）主题模型找到关键词。建立了加密的 R 树结构来动态更新数据，并设计了一个积极的安全方案来防止隐私泄露。该方法不仅具有较高的搜索准确率和效率，而且保证了隐私性和安全性。准确定位对于自动驾驶来说12IMT-2030(6G)推进组IMT-2030(6G)Promotion Group非常重要，文献17提出了一种基于语义映射的视觉定位方法，建立多传感器定位系统，获取定位信息。通过构建语义局部映射并对其进行编码来推断特征相似性来评估相机位置，然后将视觉定位结果与其他机载传感器集成，实现高精度定位功能。2.3 场景三：智能医疗传统医疗系统效率低下，面临许多挑战。集成了人工智能和物联网技术的智能医疗的出现，通过提高医疗服务的智能化和数字化，给医疗服务带来了革命性的变化。然而，海量异构数据给物联网带来了大量的资源开销和计算负担。因此，智能医疗的迅速发展需要一个更加多功能和强大的智能网络。随着 6G 时代的到来，智能设备的需求、性能的提升、医疗成本的降低都应被考虑在内，语义通信在医疗领域的应用备受关注，语义通信不仅可以改善医疗信息传递的效率，还可以促进医疗决策的准确性和患者护理的个性化。Dridi 等人提出了一种语义医疗物联网平台，为医疗设备互操作、整合海量异构数据、实现数据可视化提供了解决方案18。该平台是一个基于物联网的远程医疗监控平台。作者建立了一个语义互操作框架来标记数据并形成个性化的数据可视化，从而实现智能交互。语义医疗物联网平台平台还定义了新的基于合同的安全策略，以确保患者健康信息的保密性。此外，平台可以提供的服务包括：多类型的功能沟通服务、为患者简化医疗术语表达以及社交媒体技术的有效整合。语义通信技术在医学成像应用中也发挥着重要作用。Huang 等人提出了一种基于深度语义分割特征的辐射组学框架，可准确捕捉病变区域的特征，有效支持医疗诊断19。该框架由深度语义特征提取模块和特征选择模块组成。前者用于提取病变层次的语义特征，后者采用特征相似性自适应算法选择具有代表性的特征。具体而言，从患者图像中选取病变聚集点，重建有效特征来判断病变类别，从而实现准确诊断。Deep-SC 框架是一种结合深度学习和语义通信的方法，该框架利用深度学习驱动的语义通信的力量来进一步提高医疗系统的性能。值得注意的是，语义通信在促进跨不同医疗系统的快速和安全信息共享、无缝数据集成和智能医疗保健方面发挥着关键作用，有效地解决了与安全和隐私相关的问题。2.4 场景四：卫星通信全球通信网络技术的关键研究方向之一是空天地一体化信息网络，旨在通过整合天基卫星通信网络、空基通信网络和地基陆地通信网络，实现全球通信网络的普遍连接。天基卫星13IMT-2030(6G)推进组IMT-2030(6G)Promotion Group通信网络由于其广覆盖、远距离通信等优势，已经成为现代通信方式的重要组成部分。然而，随着移动通信特别是 6G 技术对通信速率和数据量的不断增长，天基卫星通信网络面临通信资源受限、频谱资源利用率低、用户请求时延大以及星际管理复杂等问题。这导致了天基卫星通信网络难以满足不断增长的移动通信需求。解决这些问题的关键在于构建高效的天基通信网络架构，提高资源利用率，实现高效且高质量的通信。这包括实现天基卫星通信网络的资源合理分配与充分利用，减少用户请求时延，降低星际多跳传输，实现按需缓存和分发服务内容，以及协同管理和调配天基中继节点。应用语义通信技术可以辅助解决以上问题，提取卫星通信数据的语义信息和语义标签，将选择使用的每颗卫星用于获取语义内容数据包，并基于语义内容数据包协议通信。谢卓宸等研究者提供了一种感知计算存储一体化的空间智能网络架构20，兼容 IP(Internet Protocol)网络，实现数据传输与内容感知融合、应用与网络跨层协同服务。通过提供具有内容感知能力的空间路由器，在内容存储中检测内容，可以实现网内存储传输，降低传输时延，资源与能源消耗。在语义通信赋能的背景下，卫星通信可达到的关键指标如下：地面用户速率为10100Gbps，卫星用户峰值速率可达 1Gbps，同时地面空口时延为 0.1ms，卫星空口时延大小在 10ms。除了上述所描述的场景，语义通信在数字孪生、物联网、分布式学习等场景均有广阔的应用前景。当前，语义通信的研究仍处于初级阶段，面临着许多挑战，我们提出以下几方面的技术需求。一是语义通信理论的问题，包括基于概率图的语义信息统一表征模型，语义压缩编码极限以及率失真理论。二是联合信源信道编码技术，包括语义驱动的图片，音频，视频等多模态信息的高效语义编码传输机制、信源信道联合编码机制等。三是语义通信的物理层技术的问题，包括面向语义通信的信道表征学习、自适应调制与波形技术，预编码技术，多用户接入技术等。四是语义通信的链路层技术，这部分内容包括面向语义通信的自适应链路控制、资源管理与分配、自适应重传机制设计、语义容错机制等。最后是语义通信的安全机制，包括语义通信的数据安全机制、隐私保护传输机制、语义知识库安全构建与共享机制等。2.5 场景五：工业互联网工业互联网自被提出以来一直备受工业部门的关注。在工业互联网的帮助下，企业可以建立更智慧高效的生产管理模式，降低生产成本，提高资源利用率与生产效率。工业互联网诸多优势的根源是人、机、物的互联互通，主要任务就是传输传感器产生的各种数据，为各14IMT-2030(6G)推进组IMT-2030(6G)Promotion Group机器、算法完成其下游任务提供数据支持。然而，传感器产生的数据量庞大，机器执行下游任务又对数据的可靠性与实时性有着较高的要求，现今的通信技术已经难以支持工业网络完成其任务，需要引进新的通信技术提升性能。语义通信由于其在传输效率和精简网络数据，减轻系统压力方面的显著优势，可以解决上述问题，是改善工业网络性能的理想技术。在工业场景中，下游任务处理的数据类型主要可以分为两类:时间序列数据与图像数据。时间序列数据指的是生产端的各种传感器按时间顺序记录下的数据序列，如温度传感器记录的机器温度变化日志文件。在生产过程中，时间序列数据是持续不断产生的，数据的总量十分庞大，且语义信息密度极低，直接传输和存储这些数据会造成很大的资源浪费。语义通信技术可以帮助我们对这些时间序列数据进行精炼简化，将其转化为语义信息密变较高的表示方式，大幅减少需要传输和存储的数据总量，减轻系统负担，同时提高云端各模型的分析效率。图像类型的数据主要指的是生产线上各种产品的图像，在生产端的高清摄像头拍摄生产线上的产品，并将产品图像传送到云端完成各种下游任务，如产品缺陷检测、智能分拣等。然而，在通信资源有限的工业场景中，传输图像时往往造成云端重建出的图像出现失真。图像的失真会造成下游任务的完成质量变差。语义方法可以帮助避免这种情况。机器完成各种下游任务是基于数据的各种语义特征的，且完成一个下游任务往往只需要获得数据的部分语义特征。通过语义方法，可以在压缩图像时根据下游任务的需求有选择地保留信息。这样即使在云端重建出地图像存在较大失真，将其用于完成下游任务也不会带来过大的性能损失。未来语义通信在工业互联网场景会释放更大潜力。机器对于数据的感知与理解是基于特征的，机器完成下游任务的过程本质上也是对特征的分析处理过程。因此，相比于无损的传输原数据，向机器直接发送数据相关特征是一种更高效的方式，既不会影响下游任务的完成，又方便了机器对信息的利用。而提取和传输特征恰也是语义通信的工作方式。典型业务场景包括远程监测，在火灾等检测场景中，在相应的传感器仅把业务所需求的语义信息上传并忽视无关的信息和数据；故障检测，通过语义感知采样控制数据量，使用语义信源信道联合编码，可传输压缩后的语义信息并优先保障重要语义对象的质量，达到降低网络带宽需求，有效提升能量利用效率的目的。15IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第三章 语义通信网络架构传统的通信系统主要关注基本的信息传递，而语义通信要求系统能够理解更复杂的用户意图、情感和上下文。同时语义通信系统需要能够处理如文本、语音、图像等多模态数据，并从中提取跨模态的语义信息，以实现更全面的交流。这需要新型的架构能够进行更深入的语义理解和推理，以满足用户更高级的交互需求。本章节将介绍工作组在语义通信网络架构方面的研究进展。3.1 语义通信的系统框架与性能极限3.1.1引言1948 年美国科学家香农(C.E.Shannon)发表了经典文献通信的数学理论21，为信息与通信奠定了理论基础。过去 70 年，经典信息论指导下的通信技术已经日臻完善，以哈夫曼编码、算术编码、矢量量化、变换编码为代表信源编码技术已经逼近了信源熵/率失真函数，以低密度奇偶校验码(LDPC Code)、极化码(Polar Code)为代表的先进信道编码技术已经逼近信道容量。但是，经典信息论在研究范畴、研究层次与研究维度方面仍然存在局限。从认识论观点看，信息分为三个层次：语法、语义和语用，语法信息是最简单、最基本的层次。长期以来，经典信息论局限在语法信息传输层次。实际上，在经典信息论21奠基的次年，Shannon 和 Weaver32已经意识到了语义的重要性，指出通信的语义问题以及有效性问题。现有通信系统的工程需求，只考虑了语法层次信息的传输，但这并不意味着人们要永远忽视语义信息。70 多年来，人们一直在推进语义信息论的研究，如用逻辑概率而非经典信息论中的统计概率度量语义信息量，用 Rnyi 熵对语义信息进行度量，等等。但这些工作仍然停留在语义信息的初步探讨，语义信息的定义与度量尚未形成统一观点，语义通信的理论框架与实现方法还有待深入。近些年人工智能的兴起为通信系统处理语义信息提供了技术底座，对语义通信的理论研究又注入了新的活力。北京邮电大学张平院士深入分析语义信息特征，提出语义基(Seb：Semantic Base)模型33，指出语义信息可以用高维空间的特征参量 Seb 进行表征。张平院士提出“智简(Intellicise)”理念34，进一步提出模型驱动的语义通信框架，实现通信系统由传统传输比特演进为传输“模型”，该模型即为信源信道联合语义处理得到的新特征，例如语义基等。秦志金等探讨了深度学习赋能的语义通信理论、框架和系统模型35。16IMT-2030(6G)推进组IMT-2030(6G)Promotion Group3.1.2研究进展本节在现有工作基础上，提出语义通信的通用系统模型、基本概念与术语，建立语义信息的度量指标体系，最后对于语义通信的性能极限进行探讨分析。3.1.2.1 语义通信系统模型本节提出的语义通信系统模型结构如图 3-1 所示，参照 Shannon 与 Weaver 的思想32，分为 Level A 技术级通信与 Level B 语义级通信两个层级，由信源、语义知识库、语义编码器、语法编码器、信道、语法译码器、语义译码器、信宿等八个部分组成。其中，技术级通信包括了信源、语法编码器、信道、语法译码器、信宿等五个模块，这是香农在经典文献21中提出的点到点通信系统模型。语义通信是叠加在经典通信模型上的系统，构成了语义级通信，引入了语义编码器、语义译码器以及语义知识库，并扩展了信道与信宿。图图3-13-1 语义通信的通用系统模型语义通信的通用系统模型主要模块的定义及功能如下：1)语义知识库。语义知识库是语义通信区别于经典通信而引入的重要模块。它从信源或信宿中提取语义背景知识，从信道传播环境中提取语义特征知识，作为先验信息，为语义编译码提供辅助指导。这种背景/特征知识具有多种表示形式，例如知识图谱、语义标签、下游任务相关知识、经过训练/优化的参数模型或非参数模型、信道模型及传播环境特征等。2)语义编码器。语义编码器在语义知识库的辅助下，提取信源消息的语义相关特征以及与传输任务有关的特征，而非概率信息。此外，语义编码器根据信源语义特性和信道特性，指导语法编码器对语义特征进行适当的编码来对抗传输中的干扰和噪声。因此，语义编码器既关注信源的语义特征，也关注信道的语义特征。3)语义译码器。根据信宿的传输需求，语义译码器选择重建信源消息，即面向人类感知，或者执行下游智能任务，即面向机器或其他意识体。17IMT-2030(6G)推进组IMT-2030(6G)Promotion Group与经典通信系统相比，语义通信系统含有语义知识库、语义编码器以及语义译码器等 3个重要模块，这是两者的关键性区别。语义通信可以理解为附着在经典通信之上的高层系统，既依赖但又高于经典通信系统。语义知识库为收发两端提供语义信息处理的指导，发射机和接收机共享知识库使语义通信成为可能。语义知识库不仅“感知”到信源的语义特征，还与具体的传输任务和传输条件有关，这使在“感知”信道状态信息的情况下能够实现非平衡传输，将更多资源分配到更重要的语义特征上。3.1.2.2 语义信息理论多年来，语义信息度量与语义通信极限的研究一直持续进行。学者从多个角度多个层次探讨了语义信息的内涵，富有启发意义，但现有语义通信的理论框架还不够完善与统一。参考图 3-1 的语义通信系统模型，信源集合为U，语义信息集合为S，定义知识库为KTWU，其中，T是信源语义集合，W是信道语义集合。语法信息集合为X，经过物理信道接收到的语法信息序列集合为Y，等价的接收端语义信息集合为S，最终重建的信宿消息集合为V。本节总结了语义信息的度量指标体系，如表 3-1 所示，包括语义熵、语义互信息、语义失真、语义信道容量、语义率失真函数。名称含义表达式语义熵平均语义信息量H S T语义互信息一个对象包含关于另一对象的语义信息量;,I S Y T W语义失真语义通信导致的语义信息损失,sds sE语义信道容量特定语义失真下的最大传输速率ssC语义率失真函数特定语义失真下的最小编码速率函数()ssR D表 3-2 语义信息的度量指标体系3.1.2.3 语义压缩极限分析基于概率模型的香农信息熵并不适合用于量化语义信息量，香农信息熵 衡量消息概率集合中的不确定性，但语义信息不能仅仅用概率行为来刻画，它还存在其他不确定度，如模糊性。复杂的结构性数据（如音频、图像、视频）不能假设为伯努利信源或者稳态遍历信源。语义传输的极限应定义在某个特殊的信源消息集合，而不是反映总体消息集合的平均性能指标。信息计算、操作和传输的范式越来越多地从面向随机变量转变为面向个体对象。信源消息的语义信息量，即语义编码传输需要的最少资源，可以由该消息个体的语义信息量来度量。一般意义上，语义信息可以用通用图灵机建模，而最简表述可以衡量该字符串的语义信息量18IMT-2030(6G)推进组IMT-2030(6G)Promotion Group下限。柯尔莫哥洛夫复杂度36是算法信息论中的一个关键指标，它建立在通用图灵机的理念上，用于描述计算机程序或算法序列的最短长度，可以刻画单个有限长序列的描述复杂度。图灵证明了一切消息或算法程序都可以在通用图灵机上进行合理计算。一个字符串的柯氏复杂度定义为这个字符串的最短描述长度。图图3-23-2 柯尔莫哥洛夫复杂度示意柯尔莫哥洛夫复杂度示意图图本节提出语义通信是以特定语义知识库为条件的通信，在有限知识库条件下的语义压缩极限，可以用归一化条件复杂度（NCC,normalized conditional complexity）作为柯氏复杂度的近似，用于对语义编码压缩极限的估计 NCC 定义为在有/无知识库的情况下特定数据集各个消息编码的额外所需的复杂度，由联合复杂度和知识库本身的复杂度给出，并用信源消息序列长度归一化，其表示形式为,()NCC|()s SC s TCTl sTSE8.1.1其中，为知识库即信源语义集合，为语义信息集合，为柯尔莫哥洛夫复杂度，为信源消息序列的长度。如需计算单个数据集的归一化复杂度（即知识库由自身建立），则需对不同的数据集划分方式进行枚举并求期望。由此，NCC 可以衡量在特定先验语义知识的情况下对某个信源消息集合进行语义编码/压缩的极限，是语义压缩编码下界的估计。不同文本信源上语义压缩率的评估结果如图 3-3 所示，数据集分别取自小说集合、法律文档等英文文本数据集，结果均折合为平均每单词编码比特数。由图 3-3 可见，语义编码方案的压缩性能介于香农信源熵与 NCC 界之间。NCC 界显示了文本信息有进一步压缩的潜力，但它只是对语义压缩极限的初步探索，未来还需要从多个角度继续深入研究语义编码极限。19IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图3-33-3 不同英文语料库的语义压缩率的编码结果不同英文语料库的语义压缩率的编码结果3.1.2.4 典型序列渐近分析类比经典信息论的典型序列分析方法21，语义信息论也可以采用类似方法进行渐近分析。依据渐近等分割（AEP）特性，当序列长度n足够大时，一个独立同分布观察序列的概率近似等于2nH，H为单符号熵。由此将所有编码序列构成的集合划分成 2 个子集，其中，一个子集是典型集合，其样本为典型序列，样本熵接近于香农熵；另一个子集为非典型集，包含几乎不可能出现的序列。对于任意0，只要序列长度n足够大，典型序列出现的概率满足1log()()nXpH Xn8.1.2图图3-43-4 经典编码传输和语义编码传输的典型序列对比经典编码传输和语义编码传输的典型序列对比经典编码传输和语义编码传输的典型序列对比如图 3-4 所示。对于经典通信系统，每个20IMT-2030(6G)推进组IMT-2030(6G)Promotion Group编码长度为n的码字nX都对应于在信源信号空间长度为m的典型序列mU。经过信道传输后，总的接收序列nY包含约()2nH Y个序列。每个典型序列nX对应接收序列nY构成的一个子集，这个子集中的序列和nX构成了联合典型序列。子集中包含约(|)2nH Y X个等概序列，其中|H Y X为条件熵。为了区分不同的典型序列nX，需要将它们映射到互不相交子集中，因此子集数量不多于()(|)(;)22n H YH Y XnI X Y，这意味着最多能发送(;)2nI X Y个长度为n的序列。对于语义编码系统，每个压缩后的语义编码序列nS和信源序列mU的子集对应，它们构成了联合典型序列。这个子集中的信源序列具有相同的语义含义，经过压缩编码的码字是相同的。从经典信源编码的角度出发，这种合并的过程显然会导致有损的数据压缩。然而，因为语义通信系统中背景知识的存在，这个合并过程在语义层次上是“无损”的，语义信息能够无差错传输，或者完美执行下游任务。基于语义合并操作，语义空间中的典型序列数量将显著少于信号空间中的序列数量，另外，语义编码序列对应的接收序列子集大小也是不等的。3.1.3结论本文对语义通信的理论提出了初步的研究结论，包括语义通信概念及术语，提出了一个通用的语义通信系统模型，基于算法信息论探讨了语义压缩极限，提出了归一化条件复杂度的概念，还从典型序列分析的角度理论分析了语义编码的潜在优势。但在语义通信理论方先仍有较多的研究难点与问题，包括但不限于：语义信息具有复杂的层次关系，无法用简单的统计模型表征，需要引入全新的分析方法。在多种模态信息同时存在的情况下，是否有统一的定量分析语义信息的方法。在语义压缩与传输极限方面，虽然有初步的探索，但还没有形成业界公认的理论成果。类比经典信息论，语义信息论也应当在语义无失真压缩、语义信道容量、语义限失真编码、多用户语义通信等方面建立牢固的理论基础，从而指导通信系统的优化设计。3.2 基于语义转换的通信系统3.2.1引言语义通信是这样一种通信模式，目标是接收者对发送消息语义的正确解释，而不是精准重建发送的数据，这通常要求收发端具有公共的语义知识库。通过在发送端对原始数据进行语义提取，传输提取的语义信息，而不是原始的数据，可以显著降低带宽需求。本文将讨论21IMT-2030(6G)推进组IMT-2030(6G)Promotion Group语义通信问题，提出一种基于语义转换的通信系统架构。3.2.2研究进展3.2.2.1 语义信息的表达数据的语义信息可以通过事物及其关系表示，如三元组c11?1?1?c2，表示事物 c1、c2，以及他们之间具有关系 r1。复杂的语义信息可以通过多个三元组表示。语义信息的处理通常借助以深度神经网络（deep neural networks,DNN）为代表的深度学习技术。如图片中的物体分类、检测、描述，自然语言的理解、翻译等。数据的分布式特性和设备的能力差异，导致大量模型的产生，而基于海量数据训练可以得到性能更好、应对多样任务的大模型。基于 DNN 的语义信息处理可以将语义关系嵌入到 DNN 的输入输出向量中，例如，先将单词等嵌入到向量中，处理得到的输出也是向量，单词嵌入的向量之间的距离可以反映单词的语义距离。3.2.2.2 基于联合训练的语义通信系统图图3-53-5 基于联合训练的语义通信系统基于联合训练的语义通信系统基于联合训练的语义通信系统59如图 3-5 所示。发送端通过神经网络从数据中提取语义信息，然后进行信道编码后发送；接收端对信道译码后的信息通过神经网络进行语义处理。收发端的语义提取和语义处理神经网络需要联合训练，联合训练的语义处理模块可以认为具有相同的语义知识库。语义表示即语义提取模块的输出由联合训练得到，不同模式的信源，如图像、文本、语音等，需要分别训练，语义表示可能不同；不同节点训练的神经网络，语义表示也不同，限制了语义通信的实现。22IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图3-63-6 基于语义转换的语义通信系统基于语义转换的语义通信系统如图 3-6 所示，为了更高效地实现语义通信，我们提出在系统中增加语义转换模块。在发送端侧，不同种类的数据经过语义提取后，可能被映射到不同的空间中。通过语义转换模块，将它们统一到公共的语义空间中，再进行下一步的编码（语义编码、信道编码）和传输。接收端经过语义解码得到的信息，再经过语义转换后，进行后续的语义处理，完成语义通信。3.2.3结论基于语义转换的语义通信系统运行过程包括两个阶段：1.语义校验与同步，对发送端的语义提取模型与接收端的语义处理模型进行同步，保证收发端对语义理解的一致性；2.基于语义转换的通信过程，包括语义提取、语义转换、语义编码、信道编码以及它们的逆过程。其中关键的处理语义转换，可以通过公共模型实现。大模型通过超大规模的参数和海量数据训练，可以用于构造全局语义知识，从而构造公共语义空间。将大模型作为公共模型，由通信系统提供给各个节点。各节点根据本地模型和公共模型构造语义转换函数。各节点根据相同的输入，分别送入本地模型和公共模型，得到本地语义向量和公共语义向量，作为语义转换函数的输入和输出，对语义转换函数进行训练。训练完成后，传输时，各节点将提取的语义信息通过语义转换到由公共模型定义的语义空间，然后进行编码后传输。接收时，各节点将接收到的语义向量通过反向语义转换到自己的语义空间，以利用本地模型进行后续的语义处理。24IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第四章 语义通信理论相比于传统传输的语法通信，语义通信通过提取数据的含义，过滤掉无用、无关和非本质的信息，从而在保留数据语义的同时进一步压缩数据，进而减少传输的信息量。在目前的研究中，基于逻辑概率模型的语义信息理论存在着信息表征不完整的问题。其他语义表征方式如自然语言模型存在着表征复杂等问题。基于深度学习的语义通信系统将神经网络的嵌入特征视作语义信息，无法进行显式的理论研究。研究语义信息的定义与度量，建立完善的语义通信的理论框架是技术实现的基石，因而本节将介绍语义信息理论方面的一些研究进展。4.1 语义感知的联合信源信道编码及其性能分析4.1.1引言语义通信首次被提出，可以追溯到 Shannon 与 Weaver 的开创性工作The Mathematicaltheory of communication21。随后语义熵、语义信道容量、语义反馈以及背景知识等概念相继引入，极大推动了语义层传输的理论研究。然而信息论先贤们对语义信息以及语义度量的理解，大多基于逻辑概率测度对语义的刻画，使得这些 20 世纪前沿性的工作难以拓展到文本以外的应用场景中，并导致语义通信经典信息论视角的解读仍是一个开放性问题。随着时间推移，深度学习及其应用（如自然语言处理、语音识别和计算机视觉）的最新进展为多模态语义通信的实现提供了可能，为语音、图片、视频传输开发的一系列语义通信框架在最近引起广泛的关注。然而即使上述的语义通信方案在特定场景中已经取得较好的表现，在6G 网络中的性能迭代与实际部署仍然囿于现有物理层的制约，很难由前述基于逻辑概率的语义理论模型来指导，仍然需要基于统计概率的框架来设计。因此，本小节旨在提出一个基于香农信息论的通用数学模型22，将语义信息建模为与观测信息相关的信源，并基于该模型引入语义感知的联合信源信道编码（JSCC），及其超失真概率的性能分析。4.1.2研究进展如 3-1，信源的语义特征被刻画为不可见的信源服从分布，至信源可观测外部特征的图转移概率为|。从分组编码视角出发，针对长可观测信源序列进行 JSCC编码得到码字，经过信道后得到码字并将其译码为语义恢复?与观测恢复?，与传统编码方案不同之处在于，要求整体框架可以使得语义恢复与观测恢复的失真程度同时在给定阈值与范围内23。这是由于系统多样化下游任务的本征特性决定的。25IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图4-14-1 语义感知的联合信源信道编码模型语义感知的联合信源信道编码模型2222基于图 4-1 的模型，超失真事件与超失真概率分别定义为：,=:,#3.1.1 =|?,|?#3.1.2通过对超失真概率 的上下界研究，能够反映语义感知的编码方案中，编码速率，失真约束大小以及失真概率之间的权衡。下面是本工作呈现的第一个定理：定理 3.1c.f.3：假定一个可观测的无记忆信源服从分布，条件概率|以及一个转移概率为|的无记忆信道，并且两个失真约束与满足,|,|的情形下，对于最优的,的语义 JSCC 编码，其超失真概率 可表述为：liminf?1log min?,| ,|#3.1.3liminf?1log min?,| ,|#3.1.4参数如下：:,|,|#3.1.5?,|minmin|:,|,(| (|)#3.1.6,|maxmin|:;|()#3.1.7,|maxmin?:=?|,? ,? #3.1.8 其中(|)定义为条件 K-L 散度，|是信道|同分布的输出,?之间的 Bhattacharya 距离，并且|代表信道容量且,|,为刻画语义信息的率失真函数：,|,=min?,?|;?,?,s.t.?(,?)and(,?)，并且?,?,?=。超失真概率随失真约束的具体刻画如图 4-2 所示。26IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图4-24-2 语义感知的联合信源信道编码错误概率的上下界刻画语义感知的联合信源信道编码错误概率的上下界刻画在探讨 JSCC 的超失真概率的同时，本小节同样分析了相同设定下的分离信源信道（SSCC）方案性能：假定=1 2,=1 2，其中下标 1,2 分别对应独立的信源与信道编码器24，则存在一组这样的编码器使得其超失真概率表述为：liminf?1log =max min?,|,|3.1.9分析式 3.1.4 与 3.1.9，可知 JSCC 的超失真概率可达界总是好于 SSCC，换言之，对于任意语义感知的 SSCC 方案，总存在 JSCC 方案以期获得更低的超失真概率以及更快的收敛速率。4.1.3结论本小节基于经典信息论的视角，针对语义感知的联合信源信道编码性能提出了通用的数学模型，并推导出相应超失真概率与编码速率关系的上下界。同时，本小节分析了同等设定下分离信源信道编码的性能。由结论可知，语义感知的 JSCC 相比于 SSCC 方案拥有更快的超失真概率下降速度与更短的编码块长，从理论上论证了语义通信框架中设计信源信道联合编码的必要性。4.2 面向任务的信号量化理论4.2.1引言随着 5G 网络的广泛部署与人工智能技术的大力发展，配备自主学习、感知、推断、决策等功能的先进设备的植入正在推动通信系统的智能化发展。然而，高度智能化的系统也同时带来了成倍增加的数据与信息，其对于数据传输以及数据处理能力的需求也更加严苛。在有限通信资源下，如何有效地传输关键语义信息以辅助接收端的推断、决策等过程，保证系27IMT-2030(6G)推进组IMT-2030(6G)Promotion Group统性能指标的完成，是目前超 5G 时代面临的一大公开难题25。为了进一步提升通信的效率，近年来兴起的语义通信和面向任务通信通过强调信号中语义特征的传输以及探索传输过程与系统任务之间的关联性，来降低信号失真对于系统性能的干扰。由于信号本身与系统任务的关联从数学上难以被轻易地刻画，有损压缩带来的信号失真对于系统性能的负面影响从数学上也难以被显性地表示，当前面向任务的信号压缩方法以及传输设计主要是通过深度学习方法来实现，但是对于面向任务压缩方法的可解释性及其背后的理论研究仍处于起步阶段。基于与有损压缩相关的理论展开研究，不仅从理论层面可以探明面向任务压缩方法的内在机理，还能从应用层面完善相应神经网络的设计。率失真理论和高分辨率量化理论是研究有损压缩问题中最常用的两种理论工具，分别对应了编码长度无限长和传输速率无限大的两种理想场景。率失真理论描述了理论上压缩方案可以达到的极限性能，然而对于如何设计对应的压缩方案以达到极限性能是一直困扰此类方法的难题。当压缩的目标从还原信号变为优化系统任务对应的性能指标之后，寻求最小化系统性能损失的压缩方案就变得更加棘手。因此，本小节拟利用高分辨率量化理论作为突破口，聚焦于有损压缩中最常用的量化过程，全面开展面向任务量化理论的研究262728。4.2.2研究进展要探索语义通信中面向任务压缩问题背后的理论支撑，关键问题是要探明信号失真对于系统任务的影响。然而，信号压缩误差与系统性能损失之间的映射关系难以通过一个普适的数学公式来显性表达。针对这个难题，本小节从微分学的数学思想中得到启发，利用函数微分表征自变量的细微变化对于函数值的变化程度，将级数展开、渐进分析等数学方法与传统的量化理论相结合，推导出理想情况下信号压缩与系统任务之间的映射关系26。我们假设系统的任务可以被目标函数(;)来准确描述，其中 为参数变量（不可控），为决策变量（可控）。发送端将随机变量量化成(),然后被接收端获取。与传统通信系统不同的是，信息的交互并不是通信的终点，如何利用接收到的信号来提高后续环节的完成度才是真正需要被关注的核心问题。在此框架中，此问题可以转换为如何设计量化过程使得接收端能够基于接收到的压缩信号()做出最准确的决策，从而可以最小化量化噪声给系统任务带来的负面影响（见图 4-3）。28IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图4-34-3 面向任务的量化系统设计框架面向任务的量化系统设计框架在高分辨率情况下,信号所对应的空间被分为很多个极小的胞腔/子空间，因此属于同一个胞腔中的信号可以被近似地认为具有相同的概率密度。在高分辨率情况下，量化设计可以被近似地简化为寻找量化胞腔密度29。把微分学中的数学思想与高分辨率量化理论相结合，理想状况下面向任务的标量量化的最优量化胞腔密度可以表示为：=d d =;1 1d d =;1 1?#3.2.1其中，代表目标函数对于决策变量的非零偏导数的最小阶数，代表接受端基于信号的最优决策，代表信号的概率密度函数。通过此表达式可以发现，当量化的目的不再是还原信号本身而是为了提高系统最终的性能之后，量化胞腔的密度不仅与信号本身的概率分布相关，还与接收端决策对信号偏差的抗干扰程度，以及系统任务对于决策偏差的敏感度也有着密切的联系。对于矢量量化，最优的量化胞腔密度也可以被证明与目标函数对应的 Jacobian 矩阵以及 Hessian 矩阵有紧密联系，基于这两个矩阵也可以推导出给定量化资源下系统性能损失的上界与下界26。4.2.3结论与传统的高分辨率量化理论相对比，当通信的最终目的不局限于信号重构时，最优的量化胞腔密度不再与信号概率密度函数的 1/3 次方成正比，而是与任务相关的加权概率密度函数的 1/3 次方成正比关系。此加权概率密度函数由三部分组成，分别为信号本身的概率密度函数、接收端的最优决策关于信号的一阶导数和目标函数关于最优决策的二次偏导数，从实际意义上来说分别体现了信号分布、信号失真对于系统决策的偏差以及信号失真引起的决策偏差对于系统性能的干扰这三类因素对于压缩问题的影响。该成果对于刻画任务与信号压缩29IMT-2030(6G)推进组IMT-2030(6G)Promotion Group的映射关系起到了重要作用，此证明思想以及加权概率分布的得到也可以为构造任务相关的信息熵以及互信息提供了新思路，为面向任务的率失真理论以及语义信息论的发展做出了铺垫。4.3 基于图结构的语义表征模型与压缩理论研究4.3.1引言经典信息论专注于研究位级别信息的可靠通信问题，以熵的概念量化信息的不确定性21，取得了众多极具启发性与指导性的成果，在 5G 时代成熟商用的通讯手段已经可以逼近经典信息论指出的信道容量上限30。为了进一步提高信道容量限制下的通信能力，在经典信息论中被有意忽略的语义内容激发了人们浓厚的研究兴趣，如何将信息的意义融入传输过程，建立起一套全新的语义通信框架是当前的研究热点。然而，将抽象的语义概念用数学语言表示并给语义信息建立合适的度量是十分困难的。现有的语义表征方式如自然语言模型存在着表征复杂等问题，逻辑概率模型存在着信息表征不完整的问题，同时现有的基于深度学习的语义通信系统将神经网络的嵌入特征视作语义信息，无法进行显式的理论研究。针对上述问题，本节对基于图结构的语义统一标准模型展开研究，利用简明统一且具有数学结构的图语言来描述信号中的语义信息，在语义统一表征模型的基础上，利用概率图模型等数学理论，构建语义概率模型，推导语义熵和语义互信息的一般数学表达式，以度量语义信息量。同时结合面向任务，得到语义失真度量，推导语义编码速率-语义失真关系，得到语义编码理论极限。4.3.2研究进展基于图的语言比逻辑具有显著的优势，因为图结构是一个更通用的数学模型，图语言模型已被广泛用于场景图描述和知识图。图模型是通过多变量间的条件概率来表示语义成分的联合分布的一种方式，其中信号中隐含的对象和状态可以用节点来表示，对象之间的依赖关系可以用有向边表达，以传达对底层语义信息的完整描述。30IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图4-44-4(a)(a)原始图像；原始图像；(b)(b)基于图结构的语义统一表征基于图结构的语义统一表征我们考虑一个有向图，其中隐含的对象、属性以及对应的关系被认为是由不同的图节点表示的随机变量，同时具有因果关系的节点通过边E连接。贝叶斯网络结构可以由专家知识构造，每个节点的条件概率矩阵（CPM）可以通过基于图像数据集的频率计数方法获得。在本文中，我们假设语义源由一组相关的语义元素组成，其联合概率分布由贝叶斯网络建模，基于图结构的语义统一表征实例如图 4-4 所示。由此我们可以利用图结构的统计信息得 到 语 义 的 熵 1,2,以 及 语 义 互 信 息 1,2,，?1,?2,.,?=1,2,1,2,|?1,?2,.,?。接着，我们可以得到语义无损压缩的速率极限 1,2,。与此同时，我们可以利用网络的条件独立性对多变量语义信源进行分离编码，降低编码开销31。1,2,=1?1,1=1?#3.3.1同理，在得到基于图的语义互信息表示后，我们可以进一步研究失真约束下的语义有损压缩问题，定义一个合适的率失真函序列1,2,用以度量近似的图节点1,2,与图节点?1,?2,.,?之间的失真，限失真的语义压缩极限可以被表示为1,2,1,2,=min?1,?2,?1,2,?1,11?2,22?,?1,2,;?1,?2,.,?#3.3.24.3.3结论本节提出将多模态信号（包括文本、语音、图像和视频等模态）中隐含的语义信息通过图结构进行统一表征，语义信息中的对象、属性以及对应的关系被认为是由不同的图节点表示的随机变量，同时具有因果关系的节点通过边连接，完成语义信息的完整描述。基于统一语义描述模型，利用图结构表征的联合概率信息对语义不确定性即语义信息量进行度量，并发展语义熵和语义互信息概念，推导语义编码速率-语义失真关系，给出语义源的有损压缩的极限。为下一步研究物理信道噪声对语义信道的干扰机制，推导语义传输极限奠定基础。31IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第五章 联合信源信道编码技术传统编码方案使用信源编码器对信源信息编码去除冗余得到比特流，再对比特流进行信道编码，增加相应的校验位来抵抗信道噪声，再经过调制后传入信道，经过解调后，由信道译码器，信源译码器进行信息的恢复重建。与信源信道分离编码的方案相比，深度联合信源信道编码（DJSCC）不依赖明确的编码压缩或纠错，只有一个编码器，不将像素值转换为比特流，而是直接将图像的像素值映射到噪声信道中进行传输，很大程度上避免了“悬崖效应”，同时提高了图像传输的准确性。本章节将介绍工作组在信源信道联合编码方面的一些研究进展。5.1 弱耦合下的信源信道联合编码技术5.1.1引言除了按照传输数据的模态对语义通信系统进行分类外，还可以根据语义通信系统具体的人工神经网络（Artificial Neural Network,ANN）实现划分为两类：一类为采用一个统一的ANN 模块将信源编码与信道编码一起实现，另一类为采用两个分离的 ANN 模块，分别实现信源编码与信道编码。但是无论采用哪种实现方式，其训练总需要采用端到端联合训练。这样的训练方式本质上将网络中的参数进行了统一调整，即便是分离的 ANN 模块，在联合训练过程中，负责信源编码的 ANN 模块会与负责信道编码的 ANN 模块相互影响，因此本质上也属于联合编码。对于传统的端到端联合训练方式，可以认为是强耦合的信源信道联合编码技术，它将信源编码、信道编码、信道、信道译码、信源译码视为一体，进行训练与测试。但是，为了更好地与现有的通信框架相融合，在同一协议层或者不同协议层中融入语义通信技术，需要研究针对分离模块的分开训练方式。相对于必须采用端到端联合训练的强耦合信源信道联合编码技术，弱耦合可以实现分离训练，从而不需要跨协议的梯度传播，因此更容易嵌入当前的通信系统网络框架，实现产品的落地和应用。但是，为了达到与端到端联合训练相同的通信效果，弱耦合下不同语义通信模块之间需要根据较少交互信息，对各模块相关参数进行微调（Fine-Tuning）。32IMT-2030(6G)推进组IMT-2030(6G)Promotion Group5.1.2研究进展经过研究，语义通信本质上是一种允许数据失真，但是却可以通过建立先验信息（知识库）使得语义保真的通信方式37，语义通信更关注人，或者具有“智能”的机器对信息的理解与感受，而并不聚焦在数据是否无失真传输。因此，语义通信有其特定的应用场景，对于一些必须确保数据毫无差错的传输场景，需要将语义通信切换回经典通信模块，以确保达到通信目的。为此，或许可以开发保真度预测机制，专门针对语义通信模块与经典通信模块进行选择。在实际通信实现过程中，采用的往往是失真信源，而在语义通信中，由于更加关注通信的目的或信宿的感受，因此信源也一般需要经历率失真过程。在失真情况下，联合信源信道编码技术能够利用信源与信道之间的相关性，获得进一步增益，此时分离可能不再是最优传输方案。特别的，针对基于 ANN 的语义通信系统，训练与测试过程可以看作是经过一个编码器函数、一个通信通道、一个译码器函数，最后产生一个输出。因此弱耦合下的信源信道联合编码技术包括两个方面，一方面为针对信源端编码器训练与针对信宿端译码器训练的弱耦合，另一方面为针对实现信源编码 ANN 模块与实现信道编码 ANN 模块训练的弱耦合。为方便描述，我们将弱耦合情况下的编码器描述为信源语义编码器与信道语义编码器，将译码器描述为信道语义译码器与信宿语义译码器。在语义通信系统编译码器参数训练过程中，有两个关键特征：首先，梯度通过信道反向流动，这意味着语义编码模块同时完成了信源编码与信道编码，并且考虑了信道状态。在迭代训练优化过程中，使得编码过程可以利用信源与信道的相关性获得增益；其次，语义编码模块与语义译码模块也进行了联合训练，这说明语义编码模块参数与语义译码模块参数之间也是相关的，它们依靠相同的知识库进行编译码，而知识库则是同时考虑了信源和信道的联合语义表示。但是，如图 5-1 所示，经典通信系统架构为分离形式，在信源编码、信道编码、信道之间存在着各种协议层，如果采用强耦合方式，需要新的设计以确保梯度能够从信宿端译码器回传到信源端编码器，一方面，面对各种复杂协议，这种设计势必会增加不必要的复杂度，另一方面，添加了这样设计的系统其增益很有可能会大打折扣。因此，为了能够在经典通信框架中融入语义通信模块，需要研究分离训练的方式。更进一步的，由于语义通信考虑的是信源与信道的联合语义表示，如果各模块之间没有信息交互，那么语义通信的应用潜力可能无法达到。因此，需要采用弱耦合形式下的信源信道联合编码技术。33IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图5-15-1 经典通信系统架构。经典通信系统架构。这里，我们将弱耦合下的信源信道联合编码技术分为三个方向进行研究，主要为：信道端添加信道语义编码器与信道语义译码器。信道语义编码器弱耦合体现为能够接收上层协议编码作为输入，功能为根据信道语义进行进一步压缩，此外可以对信源编码进行反馈，使其能够按照信道语义调整压缩策略。信道语义译码器弱耦合体现为可以独立训练，但是同样需要来自信道语义编码器输出的弱耦合信息进行微调，以便于实现不同信道参数情况下的语义级别解码。该研究目的在于利用语义通信模块增强经典通信模块的性能。信源端添加信源语义编码器，信宿端添加信宿语义译码器。信源语义编码器弱耦合体现为能够接收经典信源编码作为输入，将其再次进行语义级别压缩。此外，能够输出一部分弱耦合信息给经典信道编译码，作为信道编译码根据语义调整的依据。信宿语义译码器弱耦合体现为可以独立训练，但是同样需要来自信源语义编码器输出的弱耦合信息进行微调，以便于实现语义级别解码37。该研究目的在于利用语义通信模块增强经典通信模块的性能。信源端添加信源语义编码器，信宿端添加信宿语义译码器，同时，信道端也添加信道语义编码器与信道语义译码器。四者均可以单独训练，但是在通信过程中可以通过弱耦合方式，传递少量信息进行参数微调，从而最终实现信源与信道语义的联合与适配。该研究目的在于充分发掘语义通信潜力，完成语义通信与经典通信的完全融合。为了完成上述工作，未来还有诸多理论问题与技术问题需要进一步讨论与研究，主要包括如下三个方面问题：语义保真与数据保真之间的融合：该方向包含了衡量语义通信的性能指标定义，语义保真指标和数据保真指标之间的转换和过度以及不同的应用场景下保真度指标的选取等；语义通信模块与经典通信模块融合问题：该方向上需要研究经典通信模块的输出是否还具有一定的语义能够被进一步处理，加密交织等协议处理方式对语义的影响以及不同模34IMT-2030(6G)推进组IMT-2030(6G)Promotion Group态的数据处理方式能否统一。语义通信模块的弱耦合优化：在当前研究的基础上，我们后续需要进一步研究弱耦合方式下不同模块之间信息交互内容，频次等对于性能的影响，以及与强耦合性能的差异（包括理论差异和不同场景下的实际差异）。此外，就弱耦合方式下不同语义通信模块添加所引入的实现复杂度进行系统分析。5.1.3结论为了将语义通信系统嵌入经典通信架构中，需要考虑将语义通信系统中的编码器与译码器分开训练，将信源语义编码器与信道语义编码器分开训练。但是为了获得语义通信的增益，这些模块之间很可能需要传递一些弱耦合信息，其数据量要远小于传输的数据，但是这些信息可以在测试阶段起到辅助不同模块参数微调的作用，最终实现语义通信与经典通信框架的融合，推动语义通信在实际通信系统部署中的应用和落地。5.2 面向深度联合信源信道编码的信道自适应设计5.2.1引言目前，基于深度学习的联合信源信道编码(Deep Joint Source-Channel Coding)已获得广泛的研究。得益于神经网络强大的非线性表达能力以及端到端的训练方法，DJSCC 能够克服在分离信源信道编码中广泛存在的“悬崖效应”，在信道条件恶化的情况下实现通信系统性能的缓慢下降。尽管 DJSCC 在一定程度上能够实现通信系统性能的平缓变化，为了保证最优的系统性能，大多数现有 DJSCC 方法都设定在特定的信噪比(SNR)下运行(测试信噪比与训练信噪比完全一致)。考虑到实际中多变的信道条件，通常需要训练一系列针对特定 SNR 的模型并在实际使用时选择与当前 SNR 匹配的模型执行相应的无线传输任务。这会导致如下缺陷：（1）在训练阶段，增加了成倍的计算资源以训练多个模型；（2）增加了实际部署时设备侧的存储负载，并产生模型加载时通信延迟及内存占用过大等问题。因此，本小节38提出一种基于注意力机制的 DJSCC 方法(Attention Based Deep JointSource-Channel Coding,ADJSCC)，以自适应多变的信道条件，旨在降低训练资源以及设备存储消耗。35IMT-2030(6G)推进组IMT-2030(6G)Promotion Group5.2.2研究进展所提出的 ADJSCC 网络为自编码器结构，如图 5-2 所示。ADJSCC 包含编码器()以及解码器()，信源信号 将被编码器()映射为信道输入符号 ，接收端在收到噪声信道的输出符号?后，使用解码器()恢复重构信源信号?。其中编码器 和解码器()均由交替连接的特征学习(Feature Learning,FL)模块以及轻量的注意力特征(Attention Feature,AF)模块堆叠而成。AF 模块为不同 SNR 下的特征组=1,2,生成缩放序列=1,2,以对特征实现通道级重校准，从而帮助网络根据信道状态动态地缩放不同的特征。图图5-25-2 ADJSCCADJSCC网络结构网络结构AF 模块的结构如图 5-3所示。具体来说，AF 模块包含以下三部分：（1）上下文提取：平均的所有元素以获得全局特征信息并与 SNR 合并为上下文信息:=1=1?#4.2.1=,1,2, 1#4.2.2（2）因子预测：将1,2,级联构成因子预测网络()以利用上下文信息为特征组生成通道级注意力:36IMT-2030(6G)推进组IMT-2030(6G)Promotion Group=2 1#4.2.3（3）特征重校准：利用通道级注意力，将特征组的每个通道重校准为:=#4.2.4图图5-35-3 AFAF模块结构模块结构我们基于 CIFAR-10 数据集，使用不含 AF 模块的 BDJSCC 与包含 AF 模块的 ADJSCC分别在不同 SNR 的 AWGN 信道中传输图像，通过 PSNR 衡量图像重构质量以体现 DJSCC通信系统性能，如图 5-4 所示。随着的下降，远离的 BDJSCC 与 ADJSCC 的差距越来越大，至多 6dB。即使在=，即训练与测试的信道条件完全匹配时，ADJSCC 的性能也优于 BDJSCC，这充分表明了所提出 AF 模块能够帮助网络自适用于不同的信道条件，从而更好地对抗时变的噪声信道。图图5-45-4 带宽利用率为带宽利用率为1 1/12/12时时ADJSCCADJSCC与与BDJSCCBDJSCC性能性能37IMT-2030(6G)推进组IMT-2030(6G)Promotion Group5.2.3结论本小节提出了一种轻量的基于注意力的 AF 模块，其可以灵活地插入不同的 DJSCC网络以帮助网络自适应于不同的信道条件，在提升系统性能的同时避免了额外的训练及存储开销。实验表明，在图像重构任务上，所提出的 ADJSCC 表现出了更强的鲁棒性与有效性。5.3 面向 CSI反馈的深度联合信源信道编码设计5.3.1引言在大规模 MIMO 技术下，基站侧通常需要获知瞬时下行 CSI 以充分利用大量的天线。随着 5G 到 6G 天线数量的增加，现有基于码本的反馈方法的码本空间急剧增大，进而增大了反馈开销。现有 CSI 反馈的基于分离信源信道编码方法(Separate Source-Channel Coding,SSCC)，使用基于深度学习的信源编码方法将 CSI 反馈看成图像压缩任务以降低 CSI 反馈开销，同时使用适当的信道编码提供可靠的传输。然而，相比于联合信源信道编码方法(JointSource-Channel Coding,JSCC)，基于深度学习 SSCC 的 CSI 压缩反馈面临因信道状态不匹配导致的“悬崖效应”以及时延问题，并需训练多个针对特定信噪比(SNR)的模型以对抗时变信道，增加了设备侧的存储开销。以上缺陷导致基于深度学习的 SSCC 的实际使用受阻。本小节提出了一个通用的基于深度学习的联合信源信道编码框架(ADJSCC-CSI)39用于实现 CSI 的压缩反馈。通过将所有模块结构设计为神经网络并实现端到端的优化，所提出的框架能够自适应于时变信道，且性能显著优于 SSCC 下的 CSI压缩反馈框架。5.3.2研究进展所提出的 ADJSCC-CSI框架如图 5-5所示，主要包含了非线性变换模块(ATN&STN)，深度联合信源信道编码模块(SC-CSI-E&D)以及信噪比自适应模块(AF)构成。假定用户侧(UE)天线数=1，基站侧(BS)天线数=32，上下行链路子载波数=256。38IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图5-55-5 ADJSCCADJSCC-CS-CSI I框架框架CSI的压缩反馈流程如下：发射模块发射模块（1）结合 SNR 信息，UE 侧通过 ATN 模块及 AF 模块将 CSI 信息 进行特征提取与压缩：=(),)#4.3.1（2）结合 SNR 信息，UE侧使用 SC-CSI-E 模块进一步将特征映射为符号:=(,)2#4.3.2（3）UE 侧将符号两两组合构造为复数符号 并实现功率归一化。随后复数符号通过OFDM 映射到子载波上由发射机发送。接收模块接收模块（4）BS 侧在实现最大比合并及 OFDM 去映射后，将接收到的复数符号?的实部虚部拆分，还原为实数符号?2。（5）结合 SNR 信息，BS 侧使用 SC-CSI-D模块将重构的实数符号?映射为特征?:?=(?),)#4.3.3（6）结合 SNR 信息，BS 侧使用 STN模块从特征中重构 CSI信息?：?=(?),)#4.3.4其中，AF模块被频繁用于各个主要模块之中以强化网络对不同信道条件的自适应能力，传输过程的带宽限制为。实验中使用的上行链路 CSI 和下行链路 CSI 是由 QuaDRiGa 根据第三代合作伙伴项目(3GPP)TR 38.901生成。我们创建一个开放的室内场景，其中下行链路的中心频率为 5.2GHz，上行链路的中心频率为 5.4GHz。BS 位于一个长宽分别为 20m 的矩形区域的中心。在 BS 上部署了具有半波长天线空间的均匀线性阵列（ULA）。实验设置=32。本小节的通用框架能够兼容不同的 SC-CSI 编解码器，我们以一个经典 SC-CSI40编解码器 CSINet 为例进行了实验，结果如图 5-6 所示。其中，CSINet _Q_QAM 代表CSINet 输出维度为，符号量化位数为，信道编码的码率为，调制阶数为的 QAM 调制方案。CSINet _32 与 CSINet _64 使用了比特级 CSINet 方案与自适应调制编码策略的最优组合。可以发现，ADJSCC-CSINet 明显优于各种 SSCC 下的 CSINet 且能够克服 SSCC 中39IMT-2030(6G)推进组IMT-2030(6G)Promotion Group的“悬崖效应”，同时略优于 CSI 压缩反馈网络 AAnalogDeepCMC41，验证了所提出框架的有效性。图图5-65-6=3232时时ADJSCCADJSCC-CSINet -CSINet 与基于与基于SSCCSSCC的的CSICSINet Net 性能对比性能对比5.3.3结论本小节为 CSI反馈任务提出了一个通用的 ADJSCC-CSI 方法，其中所有模块均通过参数化的神经网络实现并实现端到端的训练。实验结果表明，在广泛的 SNR 条件下，在克服“悬崖效应”的同时均优于基于 SSCC 的 CSI 反馈方法。本小节的框架能够兼容多样的 SC-CSI编解码器，证明了所提出框架的通用性。5.4 面向多模态数据传输的目标语义通信技术5.4.1引言为了实现高效的智能物联网服务，既需要利用有限的通信资源下解决海量设备的联网和多模态数据传输问题，也要利用有限的计算和存储解决人工智能算法的部署和运行问题。近年来，面向图像、文本、视频和音频等单模态数据的目标语义通信系统得到了充分研究，其利用联合信源信道编码技术，在实现高效的数据传输的同时，保证了下游目标应用的性能。本技术在目标语义通信框架的基础上，引入基于多模态语义分析的传输控制机制，提出面向物联网便云端的多模态目标语义通信框架。40IMT-2030(6G)推进组IMT-2030(6G)Promotion Group5.4.2研究进展图图5-75-7 面向物联网边缘端的多模态目标语义通信框架面向物联网边缘端的多模态目标语义通信框架本技术45提出的面向物联网边缘端的多模态目标语义通信框架如图 5-7 所示。发送端包含多个边缘设备，每个设备部署了数据感知模块（Data Sensing）、语义提取器（SemanticExtractor）和联合信源信道编码器（Jiont Semantic and Channel Encoder）等模块，面向具体目标任务采集、处理和上传不同模态语义信息。边缘服务器作为接收端，包含联合信道和语义解码器（Jiont Semantic and Channel Decoder）和传输控制器（Transmission Controller）等模块，利用收到的语义信息执行相应的目标任务，并在联合分析多模态语义信息的基础上控制边缘设备的数据上传。考虑到物联网场景下小型传感器的硬件资源限制，规定设备仅上传原始数据，语义信息提取在边缘服务器上实现。将该框架运用在智慧家庭场景下，以人体动作识别为目标任务，利用人体加速度传感数据控制监控视频的上传。边缘设备包含安装在卧室、厨房、客厅的 3 台监控摄像头以及佩戴在用户左上臂的 1个加速度传感器，边缘服务器为 1 台边缘网关。图图5-85-8 面向人体动作识别的视频联合信源信道编码面向人体动作识别的视频联合信源信道编码面向人体识别任务的视频联合信源信道编码如图 5-8 所示。当各房间内的监控摄像头收到边缘网关发送的传输请求信号（ACK）时，滑动窗口对原始视频流连续采样得到图像帧样本 161121123。在语义和信道联合编码器中，由三维卷积层和三维池化层构成的神经网络从图像帧样本提取得到人体动作语义特征 452222；整形层将高维语义特征转换41IMT-2030(6G)推进组IMT-2030(6G)Promotion Group为低维语义特征编码 48402，以适应物理信道传输。边缘网关接收到带有信道噪声干扰的语义特征编码?48402。在语义和信道联合解码器中，整形层还原得到高维人体动作语义特征?452222；由三维卷积层和三维池化层构成的神经网络进一步提取得到人体行为语义特征 8155。最终由整形层和全连接层（FC）构成的分类器输出人体行为分类结果，包括在沙发上休息、在床上睡觉、在书桌前学习、在厨房就餐等 4类行为。图图5-95-9 面向加速度数据和视频的多模态传输控制机制面向加速度数据和视频的多模态传输控制机制面向加速度数据和视频的多模态传输控制机制如图 5-9 所示。边缘网关在收到来自传感器的原始加速度数据后，先利用 1 个低通滤波器和 1个滑动窗口提取包含人体动作方向信息的低频信号；再使用滑动窗口进行采样得到加速度矩阵 350。在语义和信道联合编码器中，特征提取器得到表征人体动作转向的余弦特征值，再由随机森林分类器得到姿态分类结果，包括站、坐、躺和走等 3 类姿态。传输控制器通过比较连续两个姿态分类结果来判断用户的姿态是否变化。基于人体行为和人体姿态之间的语义关系，即：人体行为变化一定包含姿态转变。因此，只需要在传输控制器检测到有效的姿态变化时，生成一个传输请求信号，要求监控摄像头上传此时从原始视频流中提取的人体动作语义特征进行人体动作识别。5.4.3结论本框架以单模态联合信源与信道编码为基础，从原始冗余数据中提取与目标任务相关的语义特征信息进行传输；并引入基于多模态数据语义关系的传输控制机制，利用传输量更低的数据模态控制传输需求更大的数据数据的传输，从而进一步降低系统的通信量。该框架被具体应用在智慧家庭场景下面向人体动作识别任务的视频和传感器数据的传输上。仿真实验结果表明：在 AWGN 信道中，采用通信框架达到的视频压缩量相较于传统 MPEG-4 编码提升了 90%以上；系统经过适当训练后，在保证高效数据传输的同时，人体动作识别的准确率达到了 97%以上。这表明利用基于多模态语义分析的传输控制机制，实现物联网边缘场景下多模态数据传输的合理性，以及利用目标语义通信系统开发物联网智能服务与应用的潜力。42IMT-2030(6G)推进组IMT-2030(6G)Promotion Group5.5 多级语义信息辅助下的图像无线传输系统5.5.1引言基于深度学习的语义通信系统显示出巨大的潜力46，能够有效传输不同类型的信息。随着物联网设备的大量部署而衍生出的以目标为导向的通信方式，给边缘设备带来巨大的通信压力。语义通信只传输目标需要的信息，大大的减少数据的通信量，提高通信效率，语义通信将成为下一代物联网无线通信技术的重要组成部分。信道噪声干扰是影响无线通信系统性能的主要因素之一，提高通信系统应对噪声环境的鲁棒性是传统通信和语义通信的共同目标。数字通信方案通过增加信道编码量提高系统的抗噪能力，同时带来通信量的剧增。当前，基于深度学习的通信系统通过 DNN 缓解噪声对系统的干扰，同时平衡系统的通信量。其中信源编码、信道编码、调制解调等传统模块由 DNN 所取代47，端到端系统可以以数据驱动的方式成功地利用各种相关性，并获得优异的结果5.5.2研究进展为提高图像无线通信的高效性和准确性，我们提出一种多级别语义通信系统48，该通信系统由两部分组成：(i)编码器，从输入图像中提取语义特征并将其编码为符号信号以实现无线信道传输；(ii)解码器，从接收到的信号中解码语义特征，以重构源图像。编码器由两部分组成：多级语义特征提取器和联合语义信道编码器。首先编码器的输入图像 I 由标准化层预处理，使得图像中的每个元素都在0,1范围内。然后通过多级语义特征提取器提取输入图像不同层级的语义特征。联合语义信道编码器将这些语义特征编码为符号，并通过无线信道发送给接收器。本文提出一种基于深度学习的无线图像传输语义通信系统，如图 5-10 所示。其中，多级语义特征提取器用于提取不同级别的语义特征。其中，高级语义信息包含图像的抽象性和通用性指标，低级语义信息包含图像的局部细节语义信息。通过基于深度学习的特征提取器提取信源特征，并通过与语义信道的联合训练给不同的信息赋予不同的权重。语义信道编码器和解码器联合在接收器处成功恢复这些语义特征，并通过图像重建模块对多级语义信息进行融合并重构目标图像。43IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图5-105-10 图像语义通信系统的整体架构图像语义通信系统的整体架构(a)(b)图图5-115-11（a a）编码器模块、解码器模块（）编码器模块、解码器模块（b b）图像重建模块）图像重建模块图像重建模块需要融合不同形式和内容的语义特征，完成不同语义内容之间的相互补充，通过注意力机制深度挖掘融合信息，进而将融合特征重建为目标图像。首先通过双特征融合模块对两种形式的高级语义特征进行融合，该模块通过交叉结构和通道注意力机制（CA,channel attention）学习输入特征；然后通过像素上采样模块对特征信息升维，其由卷积层和像素重组层构成；最后将相同维度的高级语义信息和低级细节补充信息进行级联操作，通过残差网络对融合后的信息进行提取并重建目标图像，该模块由反卷积层和 PReLU 激活函数构成（最后一层为 sigmoid 激活函数），其网络结构如图 5-11（b）所示。在图像重建模块中，不同形式特征生成的粗糙图像含有不同的成分。其中包含比较平滑的低频信息和充满边缘、纹理的高频信息。同时，卷积层的每个过滤器都包含一个局部感受野，其输出无法利用局部信息之外的上下文信息。因此，通过通道注意力机制改变特征权重，提高重要信息的权重占比，其网络结构如图 5-12 所示。图图5-125-12 通道注意力机制通道注意力机制44IMT-2030(6G)推进组IMT-2030(6G)Promotion Group5.5.3结论示例中提出了一种基于深度学习的无线图像传输语义通信系统，与其他基于深度学习和基于分离的数字传输方案相比，所提出的语义通信系统的有效性和鲁棒性均优于其他方案。同时，验证了不同形式语义特征的对系统性能的提升。5.6 用于多任务图像传输的语义通信系统5.6.1引言语义通信系统提取重要的语义信息并将其传输到目的地，在目的地，系统可分为数据重建和智能任务执行49。对于数据重建，语义通信系统将全局语义特征传输到接收器。然而，智能任务通信系统只提取与任务相关的特征。受使用高级语义信息改进图像字幕的启发50，本示例使用多级语义特征提取器来提取关于文本和分割语义特征的高级语义信息，以及关于图像细节的低级语义信息，从而提高了系统的性能51。5.6.2研究进展图像源信息包含面向任务的通信系统中使用的各种语义特征，如图 5-13 所示，语义编码器由三个重要网络组成，以提取不同形式的语义特征：核心网络、中间网络和补充网络。核心网络以文本形式提取高级图像特征，中间网络以图像形式提取高级语义相关特征，补充网络获得低级细节像素特征。图图5-135-13 系统的总体架构系统的总体架构我们使用两种注意机制来提取具有不同注意方法的语义特征,注意力模块的输入特征具有相同的大小和不同的内容。注意模块 1 是 ResNet 网络，随后插入卷积块注意模块（CBAM-ResNet）。信道细化特征被输入到空间注意力模块，以通过平均池化和最大池化操45IMT-2030(6G)推进组IMT-2030(6G)Promotion Group作来提取组件的空间间关系，空间注意力部分也通过元素乘法运算。我们通过 CNN 层将输入特征分割成块，并通过挤压和激励 ResNet（SE-ResNet）提取输入源的语义。挤压操作通过聚集 2D 空间维度获得信道方向特征的全局分布，激励操作通过选择机制调整通道权重。图图5-145-14 注意力模块的架构注意力模块的架构解码器使用从 coarse-to-fine 的结构融合不同的图像特征，以提高图像相关任务的性能。coarse 模块通过来自信道解码器的单个源信息恢复粗略图像特征，fine 模块融合各种粗略图像特征以重建目标图像。如图 5-15 所示，fine 模块接受三种类型的输入：文本嵌入到图像生成、语义分割到图像生成和低级图像特征。我们使用双重特征块来合并和提取图像语义特征的生成，其中 CA 是通道注意（channel attention）机制。Dual features module 和 attentionmodule 的输出特征通过 sub-pixel block 放大输入信息。通过 fine 模块后，我们使用 ResNet模块学习的联合语义特征。图图5-155-15 finefine模块和模块和dualdual featuresfeatures模块模块5.6.3结论示例提出了一种新的面向任务的语义通信系统，用于实现单模态数据的多任务。该系统46IMT-2030(6G)推进组IMT-2030(6G)Promotion Group旨在传输与任务相关的语义信息，以实现不同的图像相关任务：图像到文本、图像生成、显著性检测和图像重建。实例中提出了两个注意力模块来提取跨维度和模式的语义信息。此外，该示例使用不同的语义解码器基于从信道解码器接收的不同信息实现各种任务。同时，提出一种从粗到细的结构，以集成不同的图像特征，提高了系统的图像相关任务性能。5.7 面向语音的高效语义通信系统5.7.1引言语义通信已经在多种信息传输领域取得了显著的成效，特别是在图像和文本传输方面。相比于传统的无线通信方法，语义通信方法通过只发送源数据的语义相关信息来实现更高的传输效率和更好的性能。在本节中我们将介绍一种面向语音的语义传输系统，其核心思想是仅传输与语音语义相关的信息，并设计了一个额外的语音信息提取机制，以实现语音重构任务。我们将深入研究如何从原始语音信号中提取语义信息，以及如何在接收端恢复这些信息以获得准确的语音识别结果，并抵抗语音传输过程中的信道干扰，以提高系统的整体性能。5.7.2研究进展我们设计并实现了一种端到端的基于深度学习的高效语音语义通信传输系统52。如图5-16 所示，该系统由多个模块组成，包括软对齐模块、冗余移除模块、语义纠正器模块以及额外语音信息模块。图图5-165-16 基于深度学习的语音语义通信结构基于深度学习的语音语义通信结构首先，软对齐模块利用注意力机制从输入的语音频谱中提取和编码语义信息。这个模块用于提取与文本相关的语义特征，使用 1000 个子词的词汇表，并使用标记来表示词的结束（EOS）和开始（BOS）。通过这样的对齐机制，可以使输入序列的长度被有效地压缩到原始长度的 10%。其次，冗余剔除模块使用全连接层移除语义无关的特征，即 EOS 标记后的所有信息。这一步骤成功地将传输长度平均减少了 63.9%。之后，语义纠正器模块在大规模文本数据集 Librispeech 上进行预训练，该数据集包含了 14500本公有领域的书籍。该模块能够根据上下文进一步纠正输出的文字，从而极大提高47IMT-2030(6G)推进组IMT-2030(6G)Promotion Group了文字的准确性。在这个过程中，我们采用了束搜索（Beam Search）策略，通过选取最可能的 K 个文字序列，以提高恢复文字的准确性，同时利用了语义长时依赖性。额外的语音信息提取模块采用 Viterbi 算法基于 CTC 进行帧级对齐，从而获取每个音素的持续时间、音调和功率信息。尽管这些信息量非常小，几乎可以忽略不计，但它们在生成更自然的语音时至关重要。最后，我们采用非自回归模型 FastSpeech2 和预训练的 GAN 模型 HiFi GAN 进行语音重构。FastSpeech2 用于获取语音谱，而 HiFi GAN 用于生成相应的语音。这两个模块共同实现了高质量的语音生成。我们的系统采用了一个两阶段的训练方案53。在第一阶段，我们忽略了噪声信道，只训练了语义编码器、CTC 对齐和语义解码器，采用的损失函数为 CTC 损失和交叉熵损失。在第二阶段，我们包括了噪声信道，并增加了信道编码器、信道解码器、语义解码器和语音重建器的训练，此时的损失函数为交叉熵损失和均方误差损失。我们的实验结果表明，与现有的工作相比，我们的方法在错误率（WER）方面减少了10%，并且在信噪比为 0dB 时，依然能够保持良好的性能。对于语音到文本的传输，我们的系统将传输的信息量减少了 50%，同时实现了 10%的 WER 降低。对于语音到语音的传输，我们的系统只需要传输现有方法 0.2%的信息量，同时实现了与现有方法相似的语音重建质量。这些结果充分证明，我们提出的方法在多个方面都优于其他方法。图图5-175-17错误率和句子相似度对比图错误率和句子相似度对比图48IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图5-185-18额外语音信息重建结果额外语音信息重建结果5.7.3结论本节的主要贡献在于设计并实现了一种全新的语音语义通信系统，该系统在语音识别和恢复任务中实现了高效的语音传输。我们的系统从输入的语音频谱中仅提取与语义相关的信息并发送。为了增强接收器预测文字信息的正确性，我们使用束搜索解码器来查找最可能的子词序列，并使用语义纠正器通过利用预训练的语言模型来避免语义错误。模拟结果表明，我们的方法大大提高了传输效率，同时改善了预测转录的准确性，并保持了高质量的语音信号重建。5.8 基于 GAN 逆方法的高效图像隐私传输语义通信5.8.1引言随着信息产业的迅猛发展，图像传输和处理的重要性日益凸显。传统的图像传输需求大量带宽，导致传输数据量巨大。为提高通信效率，利用语义通信的手段来传输图像成为了研究的新趋势。现有的语义通信研究结合了深度学习技术，实现了高效的图像语义传输，推动了语义通信方法的发展。不过现有的图像语义传输系统的传输目标主要是图像的像素级别还原，我们提出的方法是在保证主观视觉质量前提下，提高通信效率和保护传输图片的隐私信息。5.8.2研究进展我们提出了一种基于 GAN 逆方法的语义通信方法。现有工作中利用 GAN 的判别器模49IMT-2030(6G)推进组IMT-2030(6G)Promotion Group型提取图像的无监督潜在表示以实现图像的编码和解码，可以达到优良的压缩和重构效果。然而，这种方法存在安全性问题，提取出的潜在表示可能泄露原图像的个人信息。图图5-195-19 基于基于GANGAN逆方法的高效图像隐私传输语义通信结构逆方法的高效图像隐私传输语义通信结构为解决上述问题，我们采用了基于 GAN 的生成模型进行语义通信53。提取出潜在表示后，我们引入了隐私过滤器和知识库，从潜在表示中抹去敏感个人信息，并用来自知识库的自然特征替代，以确保个人信息的安全。这种基于生成模型的语义通信方法能高效地传输图像，同时保持质量和隐私保护。利用 GAN 的逆方法，我们实现了高压缩比例，并对潜在编码的隐私部分进行特定的修改，符合人主管感知地改变图像，而不需要像传统方法那样大量使用遮罩或添加噪声以修改受保护的图像特征。GAN 能从低维向量生成高维图像，而GAN 的逆方法则可为给定的图像获取潜在向量，这样可以生成接近原始图像的图像。通过GAN 逆方法，我们进一步提高了传输效率。我们用 SemanticStyleGAN 的反转方法提取输入图像的解耦潜在代码，这些代码可被修改以实现语义通信和隐私保护。在不同的通道噪声下，我们的方法表现良好，显示出其鲁棒性。与现有方法相比，即使在更高的压缩比例下，我们的方法也可以保持对人类感知的高质量图像。我们的方法通过使用标准化流来改变复杂的数据分布，通过标准化流可逆转换来简化和优化数据分布，从而简化了传输和存储。如下图所示，我们的方法提供了优于传统方法的隐私保护，通过解耦的语义隐空间实现了对受保护图像特征的无缝和真实的修改，而不是通过大量的遮罩或噪声添加。我们的隐私过滤器成功地从输入图像中移除了隐私信息，同时保持了图像的整体完整性。50IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图5-205-20 客观评价指标对比图客观评价指标对比图图图5-215-21 主管评价指标对比图主管评价指标对比图图图5-225-22 隐私保护效果图隐私保护效果图5.8.3结论我们提出的基于生成模型的语义通信框架能有效应对物联网、自动驾驶和元宇宙等新兴应用场景的数据流量暴增。这一框架采用 SemanticStyleGAN 的反转方法，专注于传输与任务相关的信息，过滤无关信息，减少传输量，并提高人类的感知性。我们同时引入了隐私过滤器和知识库，以在保护隐私的同时自然地重建图像。尽管像素级还原的表现不如现有方法，但在如 LPIPS 这样的主管评价分数上取得了显著的提高。在隐私保护示例中，我们发现，通过分割不同的语义部分并通过隐私过滤器和语义知识库的处理，我们的方法能有效地保护隐私信息。5.9 面向点云分类任务的预训练鲁棒语义通信系统5.9.1引言本文将介绍一种基于预训练的 Point-BERT 模型的语义通信系统，该系统主要用于点云分类的鲁棒处理。随着三维数据采集设备的广泛应用，传输三维点云的需求日益增长。点云数据的传输面临许多挑战，如数据量巨大及对噪声的高敏感性。为解决这些问题，我们提出一种全新的语义通信系统，其包含语义编码器、信道编码器、信道解码器以及语义解码器四51IMT-2030(6G)推进组IMT-2030(6G)Promotion Group个主要组成部分。此系统采用了两阶段训练策略，以便适应特定的分类任务。实验证明，该系统在各种信噪比条件下均显示出优良的分类能力和对信道噪声的鲁棒性。5.9.2研究进展图图5-235-23 面向点云分类任务的的点云语义通信结构面向点云分类任务的的点云语义通信结构在处理输入的密集点云时，我们首先采用下采样模块，来减少点云中的点数，同时保留原始数据的基本结构和特性，从而降低计算复杂性和通信开销54。具体而言，我们运用最远点采样(FPS)算法对输入点云进行处理，选取 64 个关键点，然后利用 k 最近邻(kNN)算法为每个关键点找到 32 个最近的点，生成 64 个子云，每个子云包含一个关键点及其 32 个最近的邻点。这个策略有助于点云数据的高效处理和表示。接下来的我们采用可学习的位置 embedding 模块对这些关键点的相对位置进行编码，以捕获点云中点之间的空间关系，也即位置 embedding。在对点云进行语义编码的过程中，我们运用了一种预训练的 Transformer 模型Point-BERT，其能有效地从点云数据中提取出高级语义信息。具体来说，首先使用一个轻量级的 PointNet 对每个子云进行特征提取，然后将生成的点嵌入作为 Point-BERT 模型的输入。通过自注意力机制及大规模点云数据集上的预训练，Point-BERT模型能够捕获数据的潜在语义，从而实现更精确的分类和理解。在对语义信息编码并传输后，我们使用信道解码器对接收到的信号进行解码，随后利用语义解码器对解码后的向量进行进一步解码，以获得相应的分类结果。在训练阶段，我们实施了两阶段训练策略，包括预训练的 Point-BERT 模型和在不同信道条件下的训练。这样，我们的系统不仅能有效处理点云数据，而且在使用同等通信资源的前提下，提供了更佳的稳定性和可靠性，尤其是在极端的信道条件下。在实验部分，我们选用 ModelNet40 数据集来验证我们的方法，并与最新的基准方法进行了对比。实验结果显示，在所有信噪比条件下，我们的方法均优于基准方法。当信噪比大于 10 dB 时，我们的方法实现了超过 89的分类准确率，并始终比基准方法高出至少 0.8。尤其令人鼓舞的是，即使在最恶劣的条件下，也就是信噪比只有 6 dB 时，我们的方法实现52IMT-2030(6G)推进组IMT-2030(6G)Promotion Group了 78以上的准确率，这比现有方法高出了 50%。这充分证明了我们的方法在各种信噪比条件下的优秀性能。图图5-245-24 不同信道条件下的点云分类准确率图不同信道条件下的点云分类准确率图图图5-255-25不同压缩效率下的点云分类准确率图不同压缩效率下的点云分类准确率图5.9.3结论此方法实现了计算复杂性、速度和分类准确性之间的良好平衡，使其成为面向 3D 点云分类任务语义通信的可靠且高效的解决方案。在保持计算效率和速度的平衡的同时，基于预训练语义通信模型展现出了强大的鲁棒性。特别是在低信噪比范围内，我们的方法能显著提高分类准确率53IMT-2030(6G)推进组IMT-2030(6G)Promotion Group5.10 非线性变换信源信道联合编码5.10.1 引言香农信息论指导下的经典通信系统设计具有以下局限性。1)模块设计分离。依据香农信源信道分离定理21，在编码码长、时延、复杂度均不受限的条件下，信源压缩与信道传输模块可以进行分离设计，两者独立的优化等价于端到端系统全局优化。过去几十年，该原理被应用于通信系统的各个模块（如信道编码、信号调制等），简化了系统设计。但实际系统的编码码长、时延、复杂度均受到限制，尤其是对于实时性要求较高的新业务通信系统，由于编码码长和编解码复杂度等限制更严格，模块化分离优化设计相比于系统联合优化设计有明显性能损失。2)处理范式受限。现有通信系统的编解码、调制解调等模块大多采用线性处理，虽然该范式简化了系统设计，且一定条件下可以推导得到模块最优处理的解析表达式，但线性处理范式限制了模块处理能力的提升，无法进一步满足系统性能提升需求。以深度学习为代表的人工智能技术正是利用了多层神经网络的非线性处理机制，显著提升了信息处理能力，为通信系统各模块处理机制的创新提供了思路。3)优化准则单一。经典通信系统以香农信息论为理论基础，以准确传输数据或精确传送信号波形为目标，而其中承载的内容信息是什么以及信息被如何使用并未受到特别关注。在此背景下，通信系统大多数模块的数学推导都基于高斯噪声假设，因此模块优化设计的优化准则大多为最小均方误差（MSE），如信道估计、信号检测、信道编解码均是如此。然而，当考虑范畴更广的端到端通信系统时，简单的 MSE 准则无法准确匹配信源侧人类主观感知体验或智能机器任务表现，导致全系统优化效率降低。4)先验知识不足。经典信源压缩与信道传输模块均基于统计概率特征进行构建，没有考虑具体通信场景中的先验知识来辅助提升端到端传输性能，尤其没有涉及更高层的语义先验信息，也没有考虑信息传输过程推进中先验知识的更新。以上先验知识形态、使用、更新几方面的不足在一定程度上制约了系统性能的进一步提升。语义通信试图实现从技术层到语义层的跨层升级，更注重收发端到端的传输性能，而非比特级别的传输准确率。因此，利用信源信道的联合设计，使得编解码模型能将信源特征与信道特性匹配，能有效突破现有系统模块设计分离的局限，赋能端到端通信系统的整体性能跃升。现有信源信道联合编码方法通过级联信道环境样本一同训练，将语义特征提取、信源信道编码封装为一个编码器模块，该方法称为深度联合信源信道编码（DeepJSCC）55-56。54IMT-2030(6G)推进组IMT-2030(6G)Promotion Group本质上，该结构源于深度自编码器（auto-encoder）结构，采用了“定长编码”的方法，对任意符号，其编码后用于在信道中传输符号数量都是定值，且没有考虑信源数据内部在语义内容复杂性上的差异，系统编码效率还有待进一步提升。本节引入变换编码，联合信源信道的非线性处理范式和多元目标引导的端到端优化这三个新机制来提升端到端传输性能，克服传统通信系统的技术瓶颈。通过对非线性变换编码传输系统的深入研究，具体回答语义特征如何提取、如何传输、如何使用三大核心问题。5.10.2 研究进展5.10.2.1 非线性变换联合信源信道编码方法本节提出非线性变换联合信源信道编码方法（NTSCC,nonlinear transform source-channelcoding）。如图 5-26 所示，在发送端，非线性解析变换ag(;)g 用于提取信源样本x的深层语义特征，构成隐空间语义特征图y。y将会继续被送入变速率联合信源信道编码e(;)ff 得到信道输入矢量s。给定信道传输函数(;)W ，则接收符号序列为(;)Wss。接收端先将 s送入变速率联合信源信道译码d(;)ff 恢复得到关于隐空间语义特征图的估计 y，再送入非线性合成变换sg(;)g 进行语义特征融合重构信源数据 x。整个 NTSCC 系统的流程为aeds()()()()()gffgW xyssyx图图5-265-26两类非线性信源信道联合编码传输方案对比两类非线性信源信道联合编码传输方案对比语义隐空间表征矢量y会被送入先验熵模型py，计算得到语义表征y每个维度上取值对应的概率，从而获得原始数据x在语义隐空间y上的信息量分布。py实际是由 DNN 所定义的一个参数化分布，参数集合记为。先验熵模型(;)pyy 的计算式为55IMT-2030(6G)推进组IMT-2030(6G)Promotion Group4.11.1其中，()(;)iip y 表示由参数()i确定的关于iy的熵模型，表示卷积操作，1 1,2 2U表示1 1,2 2范围内的均匀分布，最后卷积形成的概率分布()(;)iipy表示关于iy的代理熵模型。卷积均匀分布操作目的是使()(;)iipy在任何iy取值点上的概率都落在(0,1)范围内，保证后续信息量计算的数值稳定。以图像信源为例，Deep JSCC 的操作逻辑为将一张图像表示为像素点组成的一个m维矢量mxR R，通过一个基于 DNN 的编码函数映射e(;)ffsx 到一个k维的信道输入矢量ksR R，其中f 表示构成编码器的 DNN 参数集合。通常有km，km为信道带宽比（CBR,channelbandwidth ratio），表示信道输入维度与信源维度的比值。而在 NTSCC 系统中，在先验熵模型的引导下，每个信源样本x所对应的信道输入矢量s的总维度是动态变化的，并且可以实现每个语义隐空间的表征矢量iy对应不同的编码码率，即iy编码得到的传输矢量is的维度不一样，可以依据iy所对应的熵大小来确定。语义隐空间的先验熵模型结合联合信源信道编码的码率分配策略，使 NTSCC 实现变换编码传输，这是其相对于 Deep JSCC 直接编码传输方案获得大幅性能提升的本质原因。图图5-275-27 非线性变换联合信源信道编码流程及对应的概率建模非线性变换联合信源信道编码流程及对应的概率建模5.10.2.2 非线性变换联合信源信道编码变分建模从端到端系统角度来看，面向数据传输任务的语义通信目标是使接收端恢复的数据分布与发送端的真实数据分布尽可能一致，从而不仅实现数据元素级别的恢复，而且追求全局视野的感知体验优化，这符合深度学习“生成模型”的思想。因此，可以从变分建模的角度，推导出语义通信编码传输的率失真优化准则。从变分自编码器（VAE,variational auto-encoder）角度来看，图 5-27 所示的 NTSCC 系统对以下几个概率分布进行了建模。1)|()|qs xs x表示给定信源样本x时，关于接收符号序列 s的条件概率分布。|()|qs xs x由非线56IMT-2030(6G)推进组IMT-2030(6G)Promotion Group性解析变换a(;)gg 、非线性联合信源信道编码e(;)ff 、通信信道(;)W 共同决定，因此|qs x是关于参数,gf 的概率模型。2)()pss表示关于接收符号序列 s的可学习的先验概率分布。在给定非线性解析变换(;)agg 、非线性联合信源信道编码e(;)ff 、通信信道(;)W 后，()pss是由语义隐空间熵模型(;)pyy 及信道转移概率|(|)ps ss s共同确定的，其计算式为4.11.23)|(|)px sx s表示接收端得到接收符号序列 s时，关于恢复数据x的条件概率分布。该概率分布由非线性联合信源信道译码d(;)ff 、非线性合成变换s(;)gg 及失真度量d共同确定。例如，当使用均方误差（MSE）作为失真度量d时，|(|)px sx s为4.11.3其中，sd(;();)fggfss 表示高斯分布的均值，即模型推理过程中的信源的估计值)(xs，2为常数，是端到端传输的能量约束。结合变分建模理论，NTSCC 系统端到端优化目标为最小化两组联合概率分布之间的 KL（Kullback-Leibler）散度，表示为4.11.4经 过 推 导 发 现，NTSCC 系 统 优 化 目 标 本 质 上 是 寻 求 平 均 传 输 速 率与平均端到端失真之间的折中。注意到速率项中的()pss是由语义空间y的熵模型(;)pyy 确定的，据此可以推导得到语义通信编码传输系统的一般化设计准则，即最小化信道传输速率失真（RD）损失函数表示为4.11.5其中，ik表示语义特征矢量iy经过信源信道编码后对应的符号矢量is的维度，可视为is通过信道传输所占用的带宽，i表示从iy的熵到信道传输符号数量ik的比例放缩系数。当无特殊兴趣区域时，全局范围i设置为相同值,ii。(),d x x表示信源样本x与重构样本 x之间的误差度量，超参数控制总传输速率iikk与失真d之间的折中。越大，优化得到的57IMT-2030(6G)推进组IMT-2030(6G)Promotion GroupNTSCC 模型信道带宽开销k越大，对应的端到端传输失真d越小；反之亦然。(),d x x一般表示客观误差度量，如图 5-28 给了不同取值下传输图像带宽分配结果，从图 3-3 可以看出，带宽分配与图像内容复杂度有显著关系。图图5-285-28 传输图像带宽分配结果传输图像带宽分配结果5.10.2.3 实验及仿真结果为了验证所提语义非线性变换编码传输系统的端到端传输性能，本节将比较 NTSCC 系统与前文提到的直接编码传输 Deep JSCC系统和经典信源信道编码传输系统的性能。实验的具体配置如下。1)数据集。为了量化端到端图像传输能力，实验使用不同分辨率、内容各异的图像数据集进行测试，图像尺寸从小到大的测试集依次为：CIFAR10（50 000 张训练图像和 10 000张测试图像，32*32像素）、Kodak（24张图像，768*512像素）、CLIC2021（60张图像，2048*1890像素）。2)对比方案。端到端的图像传输包括信源信道编码和无线信道传输 2 个主要模块。因此，对比方案包括所提的 Deep JSCC 方案和经典分离式信源信道编码方案。分离式信源信道编码方案采用了压缩能力依次增强的图像信源编码方案 JPEG、JPEG2000、BPG（H.265 视频编码标准的帧内图像编码方案），并结合实际应用的 5G 标准 LDPC 信道编码（分别记为 JPEG LDPC，JPEG2000 LDPC 和 BPG LDPC）。本文考虑 AWGN 信道和衰落信道下测试性能，在实际部署中，为了与先前工作一致，将信道输入序列中的2 个连续实符号转换为一个复信道输入符号，并添加复高斯噪声。3)度量指标和损失函数。实验使用广泛应用的像素级度量指标（如 PSNR和 MS-SSIM57）和最近兴起的基于深度学习的感知度量指标（如 LPIPS58）对所提出的 NTSCC模型和其他端到端传输模型进行性能评估。PSNR 对应于像素级的欧式距离，因此在评估模型在 PSNR 上的表现时，将失真函数d设置为信源图像x和重构图像 x间的均方误差MSE。当评估 MS-SSIM 指标时，失真函数 被设置为 1MS-SSIM 以最小化。更高的58IMT-2030(6G)推进组IMT-2030(6G)Promotion GroupPSNR/MS-SSIM 指数意味着更好的传输表现。然而，即便 PSNR 和 MS-SSIM 被广泛用作经典图像质量评价指标，它们仍旧是简单且固定的函数，难以反映人类感知的诸多细微差别。本节进一步采用了基于深度学习的 LPIPS 指标作为量化图像传输效果的语义感知损失。LPIPS 取值范围为 01，LPIPS 值越小表示损失越少。以下分不同指标给出非线性变换联合信源信道编码的图像编码传输性能及对比。1)PSNR 性能。图 5-29(a)和图 5-29(b)展示了 PSNR 与 AWGN 信道不同 SNR 的关系，CRB 设置为116km。对于分离式方案，通过评估 LDPC 码率和调制的不同组合的性能，得到了在每个 SNR 下最佳性能配置的性能曲线的包络。由于 NTSCC 方法学习到了一种速率匹配机制，因而可以通过微调模型训练超参数，确保其最大信道带宽比低于116，以达到公平的比较。结果表明，NTSCC 系统表现出显著性能提升，相较于 Deep JSCC、JPEG LDPC 和 JPEG2000 LDPC 至少提升 1 dB。此外，如图 5-29(c)所示，当 SNR 逐渐降低时，NTSCC 表现出和 Deep JSCC 同样平滑的性能下降，然而基于分离式的“BPG LDPC”传输方案的性能出现陡降（被称为“悬崖效应”），这是由于信道译码出现差错导致信源译码出现明显差错传播效应。图图5-295-29 PSNRPSNR与与AWGNAWGN信道信道不同不同SNRSNR的关系的关系2)MS-SSIM 性能。图 5-30(a)和图 5-30(b)展示了 SNR=10 dB 的 AWGN信道上 MS-SSIM与 CBR 的关系；图 5-30(c)和图 5-30(d)展示了 MS-SSIM 与 AWGN 信道不同 SNR 的关系，CBR 设置为116km。由于 MS-SSIM 的值介于 0（最差）和 1（最好）之间，并且绝大多数值高于 0.9，本文将 MS-SSIM 值转换为 dB 以提高易读性。结果表明，NTSCC很大程度上优于其他方案，并且在高 CBR 区域具有更高的性能增益。与 PSNR 指标下的结果相比，易发现 BPG LDPC 的结果普遍差于深度学习驱动的语义通信方案。59IMT-2030(6G)推进组IMT-2030(6G)Promotion Group3)LPIPS性能。除了上述 PSNR和 MS-SSIM 失真度量外，面向语义通信目标，本节进一步使用以人类视觉感知为导向的 LPIPIS 损失函数训练 NTSCC 模型，LPIPS 度量能对齐人的感知体验。图 5-31展示了 SNR=10 dB的 AWGN 信道上 LPIPS与 CBR的关系，LPIPS值越小表示失真越小。对于端到端语义通信传输方案（Deep JSCC和 NTSCC），图 5-31 在括号中标记了 PSNR 和 MS-SSIM 以指示模型的训练目标。NTSCC（Perceptual）曲线表示以式的 RDP感知损失函数来优化模型。显然，感知优化的 NTSCC在性能上远优于其他方案。图图5-305-30 MS-SSIMMS-SSIM与与C CBRBR和和S SNRNR的关系的关系图图5-315-31 SNR=10dBSNR=10dB的的AWGNAWGN信道上信道上LPIPSLPIPS与与CBRCBR的关系的关系60IMT-2030(6G)推进组IMT-2030(6G)Promotion Group5.10.3 结论本节提出了面向语义通信的端到端非线性变换编码传输新框架。首先，基于变分理论推导出了语义通信端到端率失真优化准则。据此，设计了非线性变换来提取信源数据在语义隐空间的紧致表征，并通过语义变分熵建模引导实现了可变速率的联合信源信道编码。结果表明，语义非线性变换编码能显著提升端到端数据传输性能及鲁棒性，是实现语义通信的关键技术之一。本节提出的编码技术面向高保真/优人类感知体验的端到端数据传输设计，未来可进一步扩展到机器类智能任务主导的端到端语义通信场景，具有广阔的研究前景。5.11 生成式的联合信源信道编码模型现代通信中，图像和视频数据的通信数据量呈指数性增长，越来越多的人喜欢通过图像和视频进行分享和交流。随着图像和视频通信数据的增长，现有的通信资源逐渐不足以支撑如此庞大的流量。而语义通信作为一种提高通信效率的有效手段，并且语义通信能够更好的抵抗噪声，非常适用于高吞吐的图像/视频通信场景11。现有很多关于图像语义通信的研究，其中有代表性的是 Generative Joint Source ChannelCoding（Generative JSCC）模型14。Generative JSCC 具体结构如图 5-32 所示，利用神经网络提取图像特征向量进行传输，能够有效降低通信开销。实验证明，Generative JSCC的图像重建能力显著强于普通的 JSCC，更加适用于现代图像/视频的应用场景。图图5-325-32 GenerativeGenerative JSCCJSCC模型模型一个典型的应用是在偏远山区等信号覆盖较小、传输带宽分配较少的场景进行图像/视频通信。由于 Generative JSCC能够显著的节省带宽，并且在 SNR较低的场景下，GenerativeJSCC 也能够保持较好的图像重建性能，这类图像语义通信能够很好地支撑偏远山区的图像/视频通话业务。由于 Generative JSCC 使用了神经网络代替了传统通信中的信源编码、信道编码和调制解调模块，因此需要使用大量的数据进行训练之后才能保证神经网络具备较好的泛化性。另外 Generative JSCC 只适用于图像/视频传输的场景，因为 generator 是一种图像生成模型。这61IMT-2030(6G)推进组IMT-2030(6G)Promotion Group就导致了对于其他的业务，例如文本和语音传输需要使用其他模型，增大了语义通信落地的成本。在图像语义通信实现产业化和实际部署过程中需要考虑设备计算资源的具体情况。以无线下行图像通信为例，如图 5-33 所示，基站侧需要将图像提取出特征向量进行传输，基站作为计算资源比较丰富的设备，进行图像语义抽取较轻松。而对于移动终端或者是 IoT 设备，由于计算资源有限，往往只能支持轻量级的模型。因此，在产业化过程中，需要对模型进行压缩之后才能部署在移动终端和 IoT 设备。图图5-335-33 图像语义通信的实际部署图像语义通信的实际部署5.12 波束质量上报在 AI 波束管理用例中，当基站进行训练数据收集或模型监视时，需要 UE 将所有收发波束对的波束质量上报给基站。在现有的 5G 通信协议中，UE支持最大 4个质量最强波束的上报。具体方案为最强 L1-RSRP测量值采用 7bit 量化，用于表示-140,-44 dBm 范围，步长为 1dB。剩余 3 个次强波束采用差分 L1-RSRP 上报，即与最强 L1-RSRP 测量值的差值量化为 4bit，步长为 2dB，即可以表示的波束质量范围是 30dB，无法满足波束质量标签数据变化的表征需求。并且，如果将可上报的波束个数从 4个改为所有波束对个数（例如 256，512，1024），又进一步增加上报开销。为此，可以考虑面向波束质量上报的语义通信方法。图 5-34 表示了收发波束对 L1-RSRP 的热力图。横坐标标识发送波束标识 132，纵坐标是接收波束标识 18。为了降低波束质量上报开销，UE 先根据共享知识库提取波束质量热力图的语义特征，再通过 Encoder。在 Encoder 时，可以根据不同 patch 的重要性，分配不同的量化步长。在基站侧将接收信号通过 Decoder，再根据共享的知识库恢复出波束质量热力图。62IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图5-345-34 收发波束对收发波束对L L1-RSRP1-RSRP的热力图的热力图在 AI 波束管理用例中，当基站进行训练数据收据或模型监视时，可以利用收发端共享的知识库提取波束质量热力图的语义信息，进而降低波束管理标签数据上报时的通信开销。63IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第六章 语义通信的物理层技术语义通信通过存在于发送端和接收端的共享知识进行语义信息的提取和重建，目前的语义通信研究多基于深度学习来提取语义特征，这也使得变化的无线传输环境影响了通信质量。传统的物理层模块为了最小化比特错误，将调制、信号检测和信道估计等模块分开进行优化，使得传输难以达到最优的语义指标。因此，需要对传统物理模块进行调整，以适应语义通信的需求。本章节将介绍工作组在面向语义通信的物理层技术设计的一些工作。6.1 面向语义通信的信道表征学习与自适应调制6.1.1引言语义通信通过构建传输背景知识库、感知传输内容，大大节省传输带宽，提升传输质量，在文本、图像和语音传输领域得到广泛应用。用于文本、图像传输的语义通信系统，可以有效地从文本、图像中提取语义信息，同时最大化系统容量。此外，一些用于语音传输的语义通信系统，采用注意力机制来捕捉语音信号的关键特征，提升语音中的语义的传输准确性。然而，上述研究使用深度学习来提取语义特征，导致端到端语义通信系统难以适应变化的无线环境。为了构建完整的语义传输系统60，语义通信正逐步与无线通信物理层融合61-64。传统的物理层模块，如调制、信号检测和信道估计，通常是独立优化的，以最小化比特错误，难以达到语义指标的最优化。因此，需要对传统物理模块进行调整，以适应语义通信的需求。基于此，本节从修改物理层模块出发，提出两种优化方法：一是基于语义分割的图像传输系统，利用信道信息对传输内容进行保护，以适应变化的无线信道；二是考虑句子的语义相似度的自适应调制方案，以适应语义系统的需要。6.1.2研究进展基于语义分割的图像传输系统在文献61中提出，结构如图 6-1 所示。对于图像分类任务，图像中的物体部分具有更重要的作用，而背景部分对分类准确性影响较小。因此该系统在图像传输的过程中，首先通过语义分割技术将图像分割为物体和背景部分，并对分割后的图像进行编码；接着考虑无线信道和信道状态信息（CSI）对网络设计的影响，根据传输系统不同子载波上的信噪比（SNR），对语义分割后的特征保护，即在低信噪比下优先传输保护影响分类准确性的物体部分，在高信噪比下进一步保护背景信息。64IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图6-16-1 自适应调制与信道信息指导的语义图像传输系统结构自适应调制与信道信息指导的语义图像传输系统结构图 6-2 展示了图片传输分类准确性和 MSE 性能，结果显示提出的基于 CSI 的图像语义分割编码（SS-CSI）在不同的信噪比上都能取得较好的分类准确率和均方误差性能。（a）不同信噪比下均方误差性能比较（b）不同信噪比下物种识别准确率性能比较图图6-26-2 基于语义分割的图片传输系统性能比较基于语义分割的图片传输系统性能比较在传统调制技术中，如 QAM 和 PSK等，假设所有比特重要性相同，因此星座点均匀分布。然而，在实际传输中，不同语义特征的重要程度并不相同。因此文献60中提出了一种自适应调制技术，类似于图 6-1 描述的自适应调制技术，考虑端到端语义联合信源信道编码（JSCC）方法，将每个符号编码成 4 比特，并通过神经网络将每个比特映射为代表二维坐标的两个实数，从而形成一个具有 16 个位置的星座点集合。然后，以最大化句子相似度为目标，通过端到端训练将句子调制为 80 个星座点，使相似的句子可以被映射到相近的星座点。65IMT-2030(6G)推进组IMT-2030(6G)Promotion Group（a）学习到的自适应调制星座点（b）不同信噪比下句子相似度性能比较图图6-36-3 学习到的星座点与相似度性能比较学习到的星座点与相似度性能比较图 6-3（a）展示了训练得到的星座点，点之间的距离基于句子相似度而变化。从图 6-3（b）可以观察到相比于 16-QAM，训练的调制方式在感知相似度方面具有更好的性能。而在高信噪比下，一些点由于距离太近无法正确检测，从而导致训练的调制方式性能略差于16-QAM。6.1.3结论本小节介绍了语义通信物理层的研究背景与现状，分析了相关研究的局限性，然后阐述了两种物理模块语义化设计方法。其中，基于语义分割的图像传输系统，利用 CSI 信息实现了在不同的信噪比上的性能增益；自适应调制方案则根据句子相似度将相似句子映射到相邻的星座点，提升感知句子相似性的能力。因此，通过对物理层模块进行专门的语义化设计可以更好地适应相应的语义任务，有望提升语义通信在网络层、应用层等更上层结构中不同语义任务的性能。同时，目前的设计仍然存在一些问题，如网络经端到端训练后参数固定，难以适应所有的语义任务场景，且 CSI信息的准确性也会对其指导的语义传输系统造成影响，故后续研究需要聚焦于提升语义通信物理层系统的鲁棒性和泛化性，以适应实际的通信场景与语义任务需求。6.2 联合语义编码与数字调制6.2.1引言语义通信系统普遍使用的模拟调制技术，将神经网络编码的实数输出直接送入信道。然而，这种方式无法与现有数字通信系统所兼容。语义通信系统之所以较少使用数字调制，是因为数字调制的内在机制使其等效为一不可导函数，无法用基于随机梯度下降的神经网络进行优化。为实现数字调制，现有的数字语义通信系统对实数输出进行量化，包括均匀量化和66IMT-2030(6G)推进组IMT-2030(6G)Promotion Group基于神经网络的量化。然而，量化过程并未考虑信道噪声，因此会造成性能损失。本节介绍一种面向数字语义通信的联合语义编码与调制技术65，可有效解决数字调制不可导问题以及调制与信道不匹配问题。6.2.2研究进展图图6-46-4 联合编码调制系统框图联合编码调制系统框图本方案65用神经网络学习发送星座点的概率，而非学习一映射函数，以此来解决数字调制不可导的问题。为解决调制与信道不匹配问题，本方案使用一个神经网络联合设计编码与调制，并与接收端在信道噪声下共同训练，以此得到可以匹配信道噪声的调制策略。联合编码调制系统框图如图 6-4 所示。联合编码调制系统基于 VAE概率编解码器架构，包括一个发送端处的联合编码-调制模块与一个接收端处的解码模块。在发送端，有一个信源，此信源由语义信息通过一个未知转移概率生成，在接收端处分别恢复为?和?。联合编码-调制模块由概率编码调制器和星座符号生成器组成。概率编码-调制器学习从信源到信道输入的转移概率(|,)，其中，表示神经网络参数。根据该转移概率，星座符号生成器使用可导的采样方法生成一个 M 阶调制的数字序列，即信道输入。信道被建模为加性白高斯噪声（AWGN）信道，因此，接收序列可以表示为?= ，为独立同分布的高斯噪声，每一个分量的均值为 0，方差为2。在接收端，解码模块使用两个概率解码器分别解码信源信息与语义信息。给定接收序列?，两个解码器分别估计出信源信息与语义信息的后验概率，,(|?,)与,(|?,)，其中，和分别为神经网络参数。信源信息与语义信息通过最大似然解码进行恢复。本方案以最大化互信息为原则对联合编码调制系统进行优化，将目标函数确立为;? ;?#5.2.1其中，为平衡两项互信息重要性的超参数。由于基于互信息的目标函数难以估计，且并未考虑解码端的神经网络的优化，本方案利用变分学习的方法推导出这一目标函数的变分67IMT-2030(6G)推进组IMT-2030(6G)Promotion Group下界，并以此变分下界为损失函数对编码调制器概率(|,)以及解码器概率,(|?,)与,(|?,)进行端到端的联合优化。变分下界由下式给出：;? ;?,?,?, ?,?, (5.2.2)其中，=() ()为一个常数。通过最大化此变分下界，解码器概率,(|?,)与,(|?,)可以不断逼近真实后验概率 p(|?)与 p(|?)，从而提高解码性能，编码-调制器也可以更好地最大化互信息。(a)分类准确率性能(b)PSNR性能图图6-56-5 不同不同SNRSNR和调制方式下的系统性能和调制方式下的系统性能图 6-5 展示了不同 SNR 与不同调制方式下的系统性能 channel use 为 1024，数据集为CIFAR10。其中，图 6-2(a)展示了不同信噪比下的分类准确率。可以看出，联合编码调制系统有明显的性能优势，尤其在低信噪比区域。例如，SNR=-12dB 时，联合编码调制系统在BPSK 下取得了 54.9%的正确率，比其他方案至少高 20%。图 6-2(b)展示了不同信噪比下的图像恢复 PSNR 性能。在低信噪比区域，本方案的图像恢复 PSNR 远超其他方案。在高信噪比区域，虽然模拟调制方案有更高的 PSNR，但是本方案可以仍好于其他数字调制方案，并68IMT-2030(6G)推进组IMT-2030(6G)Promotion Group随着调制阶数的不断增高，逐渐接近模拟调制方案性能。6.2.3结论本节提出了一个联合编码调制数字语义通信方案。通过使用一个神经网络联合学习编码和调制，本方案可以学习到与信道状态匹配的调制策略。实验结果证明了本方案的优越性。在低信噪比区域，联合编码调制方案有优于现存的数字语义通信方案以及模拟调制方案；在高信噪比区域，联合编码调制方案优于现存的数字语义通信方案，且性能接近模拟调制方案。6.3 基于卡尔曼滤波的端到端空口设计6.3.1引言70 年前，在信息论创立之初，Dr.Weaver 将通信问题分为三个层次21：通信符号能以怎样的准确程度进行传输？（技术问题）被传输的符号能以怎样的精确程度表达其中的语义？（语义问题）符号中的语义能以怎样的有效程度影响后续的操作？（效用问题）对于技术问题（第一层次），虽然随着无线通信系统的发展，无线资源使用的频谱效率逐步提高，但传统的模块化设计使通信链路难以进行全局优化。同时，面对持续增长的传输数据量，我们还需要考虑更高层次的通信（第二和第三层次），即实现收发端的有效交流，而不是数据的精准复制。面对上述问题，本文提出了一种智能无线空口设计方案，结合卡尔曼滤波和自编码器，实现灵活、鲁棒的端到端空口。基于神经网络的智能无线空口技术是面向 6G 的原生智能通信系统的重要研究方向之一。如文献66中所论述，其链路模型下图 6-6 所示，发送端和接收端都基于神经网络处理收发信号并适应传输环境变化，发射机则可通过接收相应的反馈信息完成相关的优化。区别于传统模块化通信系统的设计，智能无线空口技术有希望能最大限度的挖掘收发机性能空间以及灵活适配无线空口传输环境的性能潜力。69IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图6-6 端到端智能通信系统端到端智能通信系统66当前有许多关于使用深度神经网络（DNN），特别是使用自编码器（Auto Encoder）来训练无线收发器的研究工作。在理想假设的情况下，收发端的神经网络可以通过随机梯度下降算法直接训练并优化神经网络参数。但是在无线传输过程中，由于信道响应未知，梯度无法准确反向传播到发送端，这是直接将 Auto Encoder 简单套用于无线通信链路中所存在的最大问题。随后在如文献67利用已知的统计信道模型，离线端到端训练神经网络，然后在实际部署后，在线调整接收端的译码神经网络。文献68利用扰动统计优化，计算模型在发送端的近似梯度，用于神经网络的训练。文献69利用强化学习，交替训练收发机，其中接收机利用真实梯度训练，发送机利用近似梯度训练。文献70利用条件生成对抗网络代替信道，利用导频并进行编译码神经网络的端到端训练，等等都提出了一些尝试解决该问题的方法。现有通信系统中，由于真实信道和估计信道之间存在误差，因此尽管基于 DNN 的自编码器可以训练收发器以适应特定类型的已知和静态多维信道来传输相关的信息，然而，时变的、受噪声干扰的多天线无线信道会导致预先训练的收发机出现性能次优的情况。此外，当不可预测的信道条件出现（等同于训练数据集出现异常值的情况），预训练的收发机的性能将急剧下降。产生此种情况的主要原因是因为组成收发机的神经网络单元在推理阶段都被冻结，且不具有适应环境变化可调整性。本小结在介绍一种新型的智能空口设计方法。在 AE 结构中的编码器之后通过级联基于卡尔曼滤波算法的控制层，提出了一种 KF-AE 级联结构。区别于现有 AE 方法对信道模型已知的依赖，该方案是一种高鲁棒性、快速收敛的端到端智能空口结构与训练方法71。70IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图6-76-7 卡尔曼滤波卡尔曼滤波端到端端到端智能空口智能空口如图 6-7 所示，将卡尔曼滤波和 AutoEncoder 结合的智能空口设计可视为更为合理的解决方案。其主要思想是在 AutoEncoder 编码器的最后一层后添加相应的线性控制层。将该控制层的每个参数建模为随机游走的变量，并将其视为控制量，通过卡尔曼滤波的方法跟踪其参数变化并进行参数估计和训练。具体的训练步骤如下：（1）预设编码器控制层的参数与初始协方差，采样得到多组控制层先验参数。（2）输入一批训练数据，通过前馈计算出自编码器的损失函数值。（3）将损失函数值作为观测值反馈给编码器，通过卡尔曼滤波方法更新编码器的控制层参数和误差协方差，并更新解码器的网络参数。（4）可利用卡尔曼增益更新编码器的其他参数。上述步骤将卡尔曼滤波和编码器、解码器的训练联系在一起，且控制层的参数通过预测和观测迭代更新，因此无需获取信道模型。此外，该方法还可以保留编码器网络所提取的传输信息的特征，并通过最大后验估计来更新控制层中的参数。针对信道是否可以建模为可微函数，我们提供了两种控制层设计方法：对于线性或弱非线性信道等可建模为可微函数的信道场景，可以使用扩展卡尔曼滤波方法；对于强非线性信道，可使用容积卡尔曼滤波方法。6.3.2研究进展考虑线性或弱非线性信道，如 AWGN 信道或非线性模拟信道，其信道模型可以建模为可微分函数。此时，可以利用监督学习的方法完成收发机网络的训练。在此基础上，为了应对扰动的信道环境，我们使用扩展卡尔曼滤波方法对编码器的最后一层进行优化，从而提升模型的鲁棒性。n是维度为 n的第 k步控制层网络参数，它是卡尔曼滤波的状态向量，为维度为 M 的自编码器理想输出，即卡尔曼滤波的测量向量。此时，卡尔曼滤波的71IMT-2030(6G)推进组IMT-2030(6G)Promotion Group“运动方程”和“测量方程”可以写为=1 1#5.3.1=; #5.3.2其中，1为预测噪声，为测量噪声，;为观测函数，为输入的数据样本。预测过程可以表示为?|1=11:1=?1|1|1=1|1 1其中，表示条件期望，设预测噪声协方差1=11|1随迭代逐渐减少，0,1 为遗忘系数72。同时，通过扩展卡尔曼滤波对校验过程中的观测函数;一阶泰勒展开，可以表示为;=;?|1 ;?|1?|1#5.3.3其中，那么预测观测函数可以表示为?|1=;?|1#5.3.4为了减少反馈的通信开销，可以通过将原来向量表示的测量方程改写为计算得到的交叉熵损失函数k=|1;?|1，将其作为反馈的标量观测量。定义=;?，则卡尔曼增益和网络参数可以分别表示为=|1|1 1#5.3.5|=|1 #5.3.6由于信道是可微分的，因此其余层的参数可以使用随机梯度下降法进行更新。考虑强非线性信道，我们采用容积卡尔曼滤波方法进行训练。此时卡尔曼滤波的预测过程和校验过程中的高斯加权积分可以近似为?,?12=12 ?#5.3.7其中令协方差=，为正交点，表示为=1;1 1; 1 2#5.3.8其中 R表示第个基本列向量。那么，利用容积卡尔曼滤波法更新编码器控制层的参数方法如下72IMT-2030(6G)推进组IMT-2030(6G)Promotion Group=?1|1 1,=1,2,2#5.3.9此时，估计预测值=(,;)。进而可以得到=12=12? #5.3.10=12=12?#5.3.11其中?和?分别为和的均值。卡尔曼增益=1。除控制层外，编码器的其余层参数的梯度可以通过卡尔曼增益来进行估计。控制层的参数更新过程可以表示为 1=1#5.3.12其中为控制层的输出值，1为编码器第 1 层的输出值。用卡尔曼增益更新方式近似神经网络参数更新方式，有?|1=1#5.3.13那么，第 1 层的参数更新过程可以表示为1 1=1 1=1 111=1 ?|11 2#5.3.14其余层的训练过程类似1 表示层的伪逆。该方法可以保留容积卡尔曼滤波的稳定性和高效性，且可以保留 DNN 提取的特征信息。仿真测试考虑如下的编解码器设置：编码器网络拥有 2 层隐藏层，每个隐藏层包含 32个单元和 Tanh 激活函数，控制层的参数为 32 2 2=66 个；解码器网络拥有 1层隐藏层，包含 32 个单元和 Tanh 激活函数。在每个迭代过程中，batch 值=256，且 AWGN 信道的信噪比服从均匀分布0 10,25 dB，调制阶数为 4 阶。73IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图6-86-8 RBFRBF下下1000010000迭代的迭代的误码率误码率图 6-8 刻画了在 Rayleigh block fading（RBF）信道下经过 10000 迭代训练后基于容积卡尔曼滤波和基于强化学习策略梯度的误码率变化。从图中可以看到，相比于基于强化学习策略梯度(PG)的训练方法，基于容积卡尔曼滤波(CKF)的训练方法拥有更快的收敛速度。6.3.3结论本部分讨论了无线智能空口技术及其面临的技术挑战，讨论了现有研究工作直接将自编码器套用在无线通信链路中的局限性，介绍了将卡尔曼滤波和自编码器相结合的智能空口解决方案。74IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第七章 语义通信的链路层技术语义通信中不同节点的能力存在不均衡性，实际应用场景存在动态变化。如何依据应用场景的实际情况以及不同节点的需求和能力灵活地部署相应的模型，设计传输机制，并进行合理的资源分配，以提升语义恢复准确度和降低服务响应时延，是语义通信的一个关键挑战。本章节将介绍工作组在面向语义通信的链路层技术上的一些工作。7.1 面向语义通信的混合自动重传请求和语义相似度检测7.1.1引言深度学习的巨大成功使许多语义任务成为可能，因此语义通信正在成为热点研究方向之一。传统的通信系统专注于比特或符号级性能，而语义通信则以传递语义信息为目的。现阶段关于语义通信的研究在语义提取方法、语义度量方法和语义通信架构等方向有了一系列进展，如利用长短时记忆(LSTM)结构实现擦除信道下的句子传输，基于 Transformer 的语义收发器 DeepSC 等，但现有研究存在无法根据信道动态改变编码长度，灵活性有限，且无法确保语义信息的可靠传输等问题。在传统通信中，混合自动重传请求(HARQ)可以保证传输的数据包根据确认反馈被正确接收，是实现可靠传输的重要组成部分，被广泛应用于现代移动通信系统中。因此考虑将语义通信和 HARQ 结合，从解决语义通信的可靠传输和灵活性入手，提出一种基于语义通信的增量混合重传请求 SCHARQ73。7.1.2研究进展SCHARQ结构如图 7-1 所示，其中红色虚线左侧是省略 CRC 校验和 Sim32 相似度检测的 SCHARQ整体结构，右侧是单次传输的编解码和校验过程。75IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图7-17-1 SCHARQSCHARQ结构和单次传输的编解码和校验过程结构和单次传输的编解码和校验过程有对编码器和解码器用于次传输。句子在第次传输时经过编码器编码得到第次传输的增量位，经过信道被接收端接收得到?，?经过解码器解码得到?。接收端用 CRC 校验?，如果通过 CRC 错误检测，则获得最终结果，不需要后续传输。如果无法通过 CRC 错误检测，表示本次传输不能获得正确的句子。接收端将错误信息反馈至发送端，发送端再次传输增量位 1，直至通过 CRC错误检测。接收端联合接收到的全部?，解码得到最终结果?。的长度作为超参数决定了每个编码器的输出维数，这些超参数根据 HARQ 的传输目标设置。在第一次传输中，传输位长用于良好的信道环境，需使得多数信源内容可以被编码而没有任何信息损失。然后设置接下来的传输位长，以恢复较差信道下的长句子。编解码器分别由语义编码器、量化器和语义解码器、解量化器组成，具体结构如图 7-2所示。其中，语义编解码器和主要由 Transformer、全连接网络等组成，实现对信源的语义编解码、语义信息压缩和解压。量化器和解量化器1主要由全连接网络组成，将高维向量量化为待传比特并根据句子长度和信道信息控制量化后的比特数。图图7-27-2 编码器和解码器的具体结构编码器和解码器的具体结构两个句子的语义相似度可以用预训练模型 BERT 编码这两个句子，并使用编码后高维向量间的余弦距离衡量它们的语义相似度。为了在面向语义通信的 HARQ 系统中进行重传判断，需要接收端获取原始句子和重建句子的语义相似度。但原始句子的语义信息在接收端不可获得，因此提出 Sim32 相似度检测网络替代 CRC 校验，如图 7-1 绿色虚线框中的内容。76IMT-2030(6G)推进组IMT-2030(6G)Promotion Group其中 Sim32 Encoder,Decoder 结构与 SCHARQ 的编码器、编码器类似，Sim32 Encoder 输出32 位比特替代用于 CRC 校验的 32 位比特。当 Sim32 Decoder 的输出结果大于设定阈值时，表示接收句子的语义信息损失在可接受范围内，认为传输成功，否则传输失败。为了提高检测结果的可靠性，进一步结合 CRC 和 Sim32 提出 CRC-Sim32 校验方案，即在接收端先进行CRC校验，在不满足 CRC校验前提下再进行 Sim32 相似度检测。SCHARQ 对比不同方案的性能结果如图 7-3 所示。在低 BER 情况下 SCHARQ 性能略低于 SC-RS-HARQ 和传统 Huffman-RS-HARQ，在高 BER 情况下相反，但 SCHARQ 整体待传比特数远小于其他方案。CRC-Sim32 错误检测方案整体性能优于 CRC和 Sim32。图图7-37-3 SCHARQSCHARQ与其他方案的性能对比与其他方案的性能对比7.1.3结论本方案将 HARQ 技术引入语义通信提出端到端的 SCHARQ，该架构具有较高的灵活性和效率，可以通过传输增量比特来解决不同句子长度和不同信道条件的问题，同时提高语义信息传输的可靠性。为了充分发挥语义编码器的潜力，本方案介绍了一种名为 Sim32的相似度检测方法来检测估计句子中的语义错误，并将其与 CRC 相结合，得到的方案称为 CRC-Sim32。所提出的错误检测方法允许接收相似的句子，从而可以传输更多句子，特别是在误77IMT-2030(6G)推进组IMT-2030(6G)Promotion Group码率较高的情况下。上述面向语义通信的混合自动重传请求和语义相似度检测在一定程度上解决了语义通信中语义信源编码灵活性差、传输可靠性低等问题，使语义通信系统能够利用无线信道环境并具备新的语义错误检测机制，从而进一步提升通信可靠性。但是语义通信与物理层融合仍然处于探索初期，还面临着比如多模态信源、不同的语义指标和高效语义编码等问题和挑战，亟待未来展开进一步讨论与研究74-75。7.2 动态数据环境下的语义通信系统7.2.1引言现有研究多集中于理想环境下的语义通信研究，即经验数据的分布与实际应用时观测到的数据分布一致。而在现实场景中，因采集数据的环境可能发生变化，故经验数据和实际数据的分布也往往并不一致，仅依靠神经网络泛化性不足以保证通信的质量。以无人机采集图像数据并回传为例，随着无人机地理位置的变化，如在公路、草地、雪地等不同环境中，图像数据的分布会有巨大的差别。本节介绍一种由上海交通大学团队提出的基于数据适应网络的语义通信系统框架，能有效应对动态数据环境，提高语义编译码在不同数据环境下的泛化性76。7.2.2研究进展所考虑的语义通信系统框架如图 7-4 所示，它包含数字适应网络和语义编码网络两个主要部分，其中数据适应网络采用了迁移学习中的域适应（Domain Adaptation,DA）技术，可以解决动态数据环境的问题并且不会产生额外通信开销。系统先使用经验数据集对语义编码网络进行训练。语义通信与传统编码相比的本质区别在于语义通信不仅需要保证数据恢复的性能，还需要保证语用性能。因此损失函数由语义信息失真和可观测信息失真组成，定义如下1,2,?,?=ob,? 1 pr,?#6.2.1其中ob和pr分别为可观测信息和语用输出的失真度量函数，超参数随着语义编码码率变化，被用来平衡可观测信息和语用输出的失真度量函数；当两种失真函数的定义不同时，超参数用于缩放失真ob的值，以便与失真pr的动态范围对齐。78IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图7-47-4 基于数据自适应网络的语义通信系统基于数据自适应网络的语义通信系统在系统工作阶段，当实际观测数据集与经验数据集的分布不同时，数据适应网络对实际数据进行处理，尽可能将可观测数据转换为与经验数据分布类似的数据，同时保证转化前后的语义信息不变。具体来说，本节使用 Cycle-GAN 实现了数据自适应功能。如图 7-5 所示，该网络包括两对生成器和判别器，并且包含一对对称的循环生成组，其中一个循环(红色线)是将观测到的数据转化到经验数据再转化到观测到的数据，再将其转化回与实际观测数据分布相同的数据。判别器用以对观测到的实际数据和最终生成的数据进行判别，当无法区分两者时代表生成器可以成功转化。另一个循环(黑色线)则将经验数据转化到观测到的数据，再将其转化回与经验数据分布相同的数据。判别器同样用以对观测到的实际数据和最终生成的数据进行判别，当无法区分两者时代表生成器可以成功转化。该数据自适应网络具有以下优点:1)不需要太多被标记的训练样本；2)可以继续使用原始的语义编码器而不需要重新训练；3)使语义通信系统更具可扩展性。图图7-57-5 数据自适应网络架构数据自适应网络架构在该语义通信系统的仿真中，使用经验数据集为 MNIST 数据集进行语义编码器的训练，而实际观测到的数据集是 SVHN 数据集，考虑的语用任务是数字识别。本文采用重新训练编译码器的方案作为性能理论上界，与依靠神经网络泛化性直接传输的方案作对比。如图 7-6 所示，团队提出的采用 DA 的方案能基本达到性能上界，并且相对于原始系统能带来大量的语义信息准确度增益。图 7-7 展示了 DA对图片的转化效果，针对的语用任务是数字识别。可以看出 DA 转化后，图片的风格发生了很大的改变，但是语义信息（数字）保持不变。79IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图7-67-6 数据自适应性能展示数据自适应性能展示(a)原始 SVHN(b)DA转化 SVHN图图7-77-7 数据自适应转化的可视化效果数据自适应转化的可视化效果7.2.3结论本节介绍了一种应对动态数据环境的语义通信系统，该系统引入了一种基于域自适应的方法，以节省再训练语义编码网络的通信成本。结果表明，数据适应网络的性能接近重新训练的上界。相关研究可以加速语义通信在实际场景中的部署，比如语义通信在物联网设备或无人机上的实际应用。7.3 针对联合信源信道编码系统容量优化的资源分配算法7.3.1引言语义通信是一种新型通信范式，不同于现有通信系统中不考虑任务语义的信源信道编解码，语义通信系统提取任务相关的语义信息进行编码传输，可以有效降低通信量，并且可以在窄带宽、高噪声的情况下进行通信。目前大部分与语义通信相关的工作都集中在语义信息的提取，对其在资源分配相关的研究比较少。而有效的资源分配对通信系统性能的提升有着重要的影响，因此，关于语义通信系统的资源分配的研究很有必要。本文提出了一种语义通信场景下的下行资源分配算法。在该场景中，每个用户都有一个时延的约束和一个通信性能的约束。我们提出一种联合语义压缩和资源分配算法，在满足用户时延和性能需求的情况下，最大化系统所能服务的用户数。80IMT-2030(6G)推进组IMT-2030(6G)Promotion Group7.3.2研究进展如图 7-8 所示，我们考虑一个语义传输的网络，一共有 K 个用户，基站会向每个用户传递语义信息，以支撑用户完成某种任务，在这里，我们以图像传输任务为例，需要说明的是，这并非针对于图像传输任务，对于其他语义传输任务也是一样的。由于每个用户对时延和性能的要求不同，用户会向基站端传递其时延和性能的要求，并且同时反馈其与基站之间的信道状态信息（CSI）。基站在接收到每个用户的传递信息之后，会根据接收到的信息进行一个资源分配。对于基站来说，不同的性能需求意味着不同的传输数据量，如果用户对任务的需求比较高，那么我们需要传递更多的数据量，反之，如果用户对任务的需求比较低，那么所需的数据量比较少。因此，我们可以根据用户的性能要求和时延要求，自适应地决定语义压缩的比例，根据不同的压缩比例，选取对应的语义压缩的网络，以 JSCC 为例，不同的压缩比对应着不同的网络。在选取对应的压缩网络将数据编码之后，基站将压缩得到的数据进行发送，并且将对应的网络编号发送给接收端，接收端用户根据对应的编号，选取对应的解码网络77。图图7-87-8 语义通信网络示意图语义通信网络示意图我们先定义一个效用函数。对于用户 k 来说，假设其时延要求为，其性能要求为，在这里，由于是考虑图像传输任务，因此我们把图像传输任务中常用的性能指标 PSNR 作为性能指标，这个性能指标是关于压缩比和信噪比的函数，并且其函数表达式由语义通信的网络模型所决定。在这里，我们假设一个用户如果它的时延要求和性能要求都得到了满足，那么这个网络的效用函数则为 1，否则为 0。=1,if ,0,otherwise.#6.3.1我们的目标是联合语义压缩，功率分配，用户资源块配对，最大化系统的支持的用户数，即81IMT-2030(6G)推进组IMT-2030(6G)Promotion Group1:max,=1?,s.t.,0,1,?,1,?,1,=1?=1?,1,2,.其中，,表示用户-资源块配对情况，即,=1 表示第 m 个资源块分配给了第 k个用户，否则,=0，是关于第 k 个用户传输图片的压缩比，,是基站在第 m 个资源块上分配给用户 k的功率。前三个约束保证了一个资源块最多分配个一个用户，一个用户最多占用一个资源块；第四个约束是关于功率的约束，第五个约束保证了压缩比是在给定的范围内选取。这是一个混合整数非线性优化问题，比较难以解决，为了求解，我们将其分解为两个子问题，分别对子问题进行解决，并且，我们证明了两个子问题的最优解就是原问题的最优解。首先，我们先求解在每种可能的用户-资源块配对情况下，满足用户时延和性能所需要的最小的功率。其次，我们在得到各种用户-资源块配对所需的最小功率的情况下，进行最优用户-资源块配对。两个子问题分别对应于2 和3。2:min,s.t.,1,2,.3:max,=1,s.t.,0,1,1,1,=1=1,其中，,表示在将资源块 m 分配给用户 k 之后，满足用户时延和性能所需的最小功率。之后，我们又通过一系列转换的方法求出了问题3 的解。仿真结果如下所示，从图 7-9 中可以看出，所提出的算法在相同功率的情况下，能够支82IMT-2030(6G)推进组IMT-2030(6G)Promotion Group持更多的用户数，其中，Hungarian 代表将问题 3 用匈牙利算法求解，得到每个用户所需的功率，然后根据贪婪算法选择用户的结果；Random 表示由2 求得不同用户-资源块配对情况下所需的最小功率，资源块随机配对；Uniform 表示功率平均分配，资源块随机配对。图图7-97-9 系统支持用户数随功率变化图系统支持用户数随功率变化图7.3.3结论由于语义通信与传统的通信系统有所区别，针对这个通信系统，我们需要设计新的资源分配的方案。本文所提出的语义通信场景下的资源分配方案，考虑了语义通信系统的特点，可以有效地利用有限的资源。7.4 深度图像语义传输系统的自适应速率控制7.4.1引言在深度图像语义传输系统中，通常使用基于深度学习的联合信源信道编码技术（DeepJSCC）来提取输入图像的语义信息。传统的 Deep JSCC 方案仍存在一些问题。一方面，Deep JSCC 将输入图像的像素值映射到复值信道输入符号，用相同的信道资源平等地对待每个符号。但对于不同的传输目的，传输的信道符号可能具有不同的重要性。另一方面，DeepJSCC 的传输速率是固定的，在通信资源有限的场景下，限制了图像内容的传输。为了解决这样的限制，可以通过速率自适应控制，只对部分重要的语义信息进行传输。已经对自适应速率控制的语义通信进行了一些研究。Kurka 等人78使用多个模型支持多个通信速率，但无法适应不同的信道条件，模型在部署时可能遭受性能损失。Yang等人79使用单个模型支持多个速率，并且可以根据信道信噪比（SNR）和源图像的特征图调整通信速率。他们只考虑了传输部分重要的特征图，然而这些特征图的像素在空间上可能具有不同的重要性，因此可以只传输一部分像素。我们希望研究出一种深度图像语义传输系统的自适应速率控制方案，以解决现存的问题。83IMT-2030(6G)推进组IMT-2030(6G)Promotion Group7.4.2研究进展我们针对深度图像语义传输系统，提出了一种自适应速率控制方案80，使用单个深度神经网络适应不同信道条件，根据源图像的特征图及其熵、信道信噪比自动调整通信速率，实现更好的图像重构性能。首先，经典的Deep JSCC用相同的信道资源平等地对待每个复值信道输入符号。在我们提出的方案中，认为具有更高的熵的语义信息（特征图）中的符号对于图像重构任务更重要，因为它们平均携带了更多的信息。其次，我们的方案可以选择性地传输每个语义信息中的一部分像素，剪枝掉那些重要性低的像素。由于这些语义信息的空间结构也是重要的信息，我们保留每个语义信息中被剪枝像素的位置，并对其进行调制，与复值信道输入符号一同输入到无线信道中。在接收端可以恢复它们的空间结构。这样的设计进一步提高了提出的方案的灵活性，因为我们在传输重要的语义信息时对它们进行了稀疏化。我们提出的深度图像语义传输系统自适应速率控制方案的框图如图 7-10 所示。图图7-107-10 深度图像语义传输系统自适应速率控制方案框图深度图像语义传输系统自适应速率控制方案框图为传输源图像，将其输入到语义编码器中，提取其语义信息。随后，我们将提取的语义信息输入到语义信息选择模块中。该模块主要由一个策略网络构成，可以生成掩码，选择重要的语义信息进行传输。接着，通过语义信息剪枝模块，剪枝每个语义信息中不重要的像素，记录它们的位置信息。该模块由另一个策略网络构成，实现了语义信息的稀疏化。在信道编码器中，对这些语义信息进行功率归一化，然后送入无线信道。在接收端，信道解码器对语义信息进行零填充。接着，语义解码器对这些语义信息进行恢复，输出重构图像。信道的信噪比被送入语义编码器、语义信息选择模块、语义信息剪枝模块和语义解码器，使得整个系统能够适应不同的信道条件。模型被端到端训练，损失函数由MSE失真、信道利用率和语义84IMT-2030(6G)推进组IMT-2030(6G)Promotion Group信息的熵构成。在训练过程中，我们最小化MSE失真和信道利用率，最大化语义信息的熵，实现了自适应速率控制。相较于现有方案，我们的方法的重构图像的PSNR提升了 0.11-0.57dB。7.4.3结论实验结果表明，在提取语义信息时最大化其熵，并根据语义信息及其熵、信道条件选择重要的语义信息，可以提升深度图像语义传输系统的性能。同时，语义信息可以被稀疏化，以进一步减少信道资源的消耗。我们使用深度神经网络对语义信息编解码、语义信息选择与剪枝、信道编解码等模块进行联合设计，并端到端优化整个系统。我们在语义信息提取、选择、剪枝、解码时考虑信道信噪比，实现了在不同信道条件下优秀的自适应速率控制。这样的速率控制方案可以在各种通信资源有限的场景中很好地应用。85IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第八章 语义通信的安全机制在本报告中，我们在结合现有的一些研究工作的基础上，对语义通信这个研究领域上涉及到的研究内容进行了讨论。主要讨论总结了现有的基于 AI/ML 的物理层技术，链路层技术以及网络上层技术，并探讨了无线 AI 的一个关键性问题，即研究数据集的获取和共享问题。本章将总结全文内容，概述语义通信的潜能和优势，分析其产业化前景、现有的技术成熟度及其对标准化和产业化应用的影响。8.1 具备隐私保护功能的加密语义通信系统8.1.1引言本章介绍了一种加密语义通信系统来保护用户隐私81，该系统兼顾了语义系统的通用性和隐私保护性。通用性体现在所有网络模块结构是公有的，且都基于共享背景数据库进行训练，适合在实际场景中大规模部署。同时，通过对称加密机制实现了隐私保护性。实验结果表明，所提出的加密语义通信系统，无论传输的语义信息在发送端是否加密，接收端都能很好的解码出准确的语义消息，而攻击者很难从窃听到的消息中重建原始语义信息。8.1.2研究进展图图8-18-1 加密语义通信系统的结构加密语义通信系统的结构考虑安全通信经典场景，涉及三个用户(Alice，Bob 和 Eve)。Alice 和 Bob 需要实现安全语义通信，而 Eve 试图窃听他们的通信信息。Alice 希望向 Bob 发送一条私密的语义消息，并通过语义和信道编码器处理输入,Alice 不仅对消息进行语义编码，而且还对消息进行加密。86IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图8-28-2 加密器和解密器加密器和解密器的结构的结构发送端输入句子记作为 S，将 S 分解为多个令牌（token）的顺序组合，令牌指背景知识库中的储存单位，每个令牌都是一个 One-hot 向量。输入的句子通过词嵌入层，可以将每个令牌映射到固定维的浮点数向量，输出记为?。然后，如果需要加密，则将语义消息 S 与密钥一起输入到加密器 Ke()中进行加密，然后将加密的消息输入到语义编码器 E()进行语义编码，反之则不加密，分别输出语义向量 Xk和 X。最后，进行信道编码，得到输出 Yk或 Y。语义编解码器用 Transformer 进行设计，信道编解码器使用自动编解码器。编码信息通过AWGN 信道传输后，Eve 试图通过一个语义攻击器 A()重建原始语义消息。同时，Bob 直接通过语义解码器 D()解码未加密的消息，而加密的消息需要首先使用解密器 Kd()解密，然后通过语义解码器 D()解码。无需加密的语义通信链路的损失函数由下式给出,=,#7.1.1其中 E(E,)和 D(D,)分别表示语义编码器和语义解码器的输出，通过最小化这种损失来获得最佳的语义编码器和解码器。加密的语义通信链路的损失函数的定义为：,=,#7.1.2其中 Ke(Ke,)和 Kd(Kd,)分别是加密器和解密器的输出。通过最小化该损失来获得接收机的最佳解密器。窃听者将使用语义攻击者直接重建语义信息，其损失函数为：,=,#7.1.3其中 A(A,)是窃听者接收机的输出。通过最小化损失可以获得最强的语义攻击器。组合和来给出加密器和解密器的损失函数可以由下式给出,通过最小化这种损失来获得最佳加密器：=,#7.1.4超参数 调整效用性和隐私保护性对加密方法的影响程度。87IMT-2030(6G)推进组IMT-2030(6G)Promotion Group加密语义通信网络的训练分为两个步骤。第一步是训练具有对称结构的信道编码器和信道解码器。我们使用随机生成的向量对该网络模块进行训练，类似于编码的语义向量。训练过程中将信道 SNR 的参数设置为在一定范围内动态变化，这样可以增强网络的鲁棒性。并利用 MSE 作为损失函数来降低向量的失真度。第二步是利用发射机与接收机和窃听者的语义攻击器之间的重构误差交替更新各网络模块的参数。8.1.3结论图图8-38-3 对抗训练方式下的损失函数对抗训练方式下的损失函数，和和图图8-48-4 非对抗训练方式下的损失函数非对抗训练方式下的损失函数，和和在对抗训练时，通过使用提出的加密语义通信系统方案，两个损失函数可以收敛到 0。但是，不能收敛到 0,代表窃听者解码器将无法正确重建原始消息，验证了系统的隐私保护性。另一方面，使用非对抗训练方案时，即当 不参与训 练更新时，和 三个损失函数的值都可以收敛到 0。这意味着尽管该语义通信系统具有很高的效用性，但隐私保护性较差。总而言之，本章提出了一种对抗性加密训练方案，该方案可以有效保证加密和未加密模式下语义通信的准确性，并抵御攻击者窃听语义信息，解决了语义通信系统中窃听的安全问题，显著提高了通用结构的语义通信系统的隐私保护能力。8.2 基于数据混淆的语义信息安全传输机制8.2.1引言相比于传统通信，语义通信中所传输的语义信息更容易泄漏隐私。在传统通信系统中，所传输的比特序列包含冗余比特位，能够提供一定程度的隐私保护。然而，语义通信中所传88IMT-2030(6G)推进组IMT-2030(6G)Promotion Group输的语义信息包含更加紧凑和语义相关的符号，更容易泄漏隐私。另外，基于深度学习的语义通信也容易受到面向深度学习模型的攻击。假如在传输的语义信息被恶意攻击者所窃取，攻击者可以使用模型反演攻击，从语义信息中重构原数据。攻击者也可以向语义信息添加扰动，使语义通信系统在下游任务中做出错误的决策。因此，语义信息的安全传输是语义通信至关重要的一环。目前，国内外有许多学者提出了抵御模型反演攻击的方法，如加密82、差分隐私83和攻击者感知的训练84等。然而，加密算法会带来较大的计算开销。尽管差分隐私和攻击者感知的训练能够一定程度防御攻击，但是在语义通信的场景中，攻击者和接收者的目标都是从语义信息中重构原信息，如果在这些防御方法下接收者能够重构原信息，那么攻击者在理论上也能够重构原信息。因此，这些防御方法在语义通信的场景下并不合适。为了实现语义信息的安全传输，本小节提出一种基于数据混淆的语义信息安全传输机制。在通信开始之前，通信双方通过密钥交换机制确认数据混淆方案。在发送方传输语义信息之前，根据所确认的数据混淆方案对语义信息进行随机置换和替换。接收方接收到语义信息后先根据数据混淆方案对语义信息进行还原，再从语义信息中重构出原信息。8.2.2研究进展本小节所提出的基于数据混淆的语义信息安全传输机制包含两步，分别是混淆方案选择与语义信息混淆。在混淆方案选择中，通信双方需要确认本次通信所使用的数据混淆方案。假设通信双方共享一个数据置换方案集合和一个数据替换方案集合。在每次通信开始前，发送方随机生成一个数据对=,，该数据对能够从和中选出相应的置换方案和替换方案。接着，发送方通过密钥交换算法，将该数据对共享给接收方。在接收到混淆后的语义信息后，接收方可以基于对语义信息进行还原。在每次发送方传输语义信息前，发送方利用,从和中获取相应的置换方案和替换方案。假设语义信息是一个高维张量，在进行信道编码前，沿着其第一维度对张量进行行置换，接着与下一个要传输的语义信息的部分行进行交换，实现随机替换。如果只有一个语义信息要进行传输，则发送方多传输一个由随机噪声组成的张量。经过随机置换和替换后的语义信息通过信道编码后传输到接收方。接收方对语义信息进行信道解码后，利用,从和中获取相应的置换方案和替换方案，对进行数据混淆后的语义信息进行还原。由于每次通信所使用的数据混淆方案都不同，即使攻击者多次截取到语义信息，也无法从其中确认所使用的和，从而也无法还原出原始数据。另外，由于数据混淆由替换和置换构成，因此具有较低的计算开销。图 8-5 给出了所提出的语义信息安全传输的数据混淆示意图。89IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图图8-58-5 语义信息随机混淆方案语义信息随机混淆方案8.2.3结论我们对所提出的基于数据混淆的语义信息安全传输机制进行仿真验证，探究不同信噪比条件下攻击者从语义信息中重构原数据的效果。从仿真结果中可以看出，在不同信噪比条件下，攻击者都无法重构出质量较好的图像，具有较低的 PSNR 和 SSIM 指标，从而验证了所提出的机制的有效性。13.61dB/0.1315.00dB/0.2210.61dB/-0.0612.72dB/0.0713.38dB/0.1811.22dB/-0.0111.83dB/-0.08Eavesdropper Channel SNR10.99dB/0.0111.20dB/0.0211.31dB/0.0411.24dB/0.0212.05dB/0.2010.62dB/0.029.95dB/-0.0114.68dB/0.078.99dB/-0.0111.27dB/0.0511.01dB/0.010dB10dB20dB0dB10dB20dBMain Channel SNR图图8-68-6 基于数据混淆的语义信息安全传输性能验证基于数据混淆的语义信息安全传输性能验证90IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第九章 总结在本报告中，我们在结合现有的一些研究工作的基础上，对语义通信这个研究领域上涉及到的研究内容进行了讨论。主要讨论总结了现有的语义通信理论，联合信源信道编码技术，面向语义通信的物理层技术、链路层技术以及安全机制，同时展望了语义通信的网络架构。本章将总结全文内容，概述语义通信的潜能和优势以及未来的发展方向。在语义信息理论方面，本报告的第三章节首先基于经典信息论视角，通过通用数学模型和上下界推导，论证了语义感知的联合信源信道编码相对于分离方案的性能优势，强调了在语义通信中设计信源信道联合编码的重要性。此外探索了面向任务的信号量化理论，推导了当通信目标不仅是信号重构时，最优的量化胞腔密度与任务相关的加权概率密度函数的1/3 次方成正比，这加权概率密度函数由信号分布、失真对决策影响以及决策偏差对系统性能影响三部分组成，为压缩问题中任务与信号压缩的映射关系提供了新思路，为任务相关信息熵和互信息的构造提供了潜在方法，为面向任务的率失真理论和语义信息论的发展奠定基础。最后提出通过图结构统一表征多模态信号中的隐含语义信息，将对象、属性和关系表示为图节点，建立因果关系的边连接，实现完整的语义信息描述。基于这一统一语义描述模型，利用图结构联合概率信息度量语义不确定性，引入语义熵和语义互信息概念，推导语义编码速率与失真关系，探索语义源的有损压缩极限，为进一步研究物理信道对语义信道的影响提供了基础。在联合信源信道编码技术方面，本报告的第四章节首先提出基于弱耦合的信源语义编码器与信道语义编码器分离训练技术，在模块之间传递少量弱耦合信息以获得增益，在测试阶段可用于微调不同模块参数。此外讨论了面向 CSI 反馈、文本、语音、图像、点云、多模态数据的联合信源信道编码方案，相较于传统方案，在传输效率和任务完成质量上都有了质的提升。针对变化的信道，此章节也提出了一种注意力模块，其可以灵活地插入不同的DJSCC 网络以帮助网络自适应于不同的信道条件，在提升系统性能的同时避免了额外的训练及存储开销。这些成果显示基于深度学习的联合信源信道编码技术由于端到端优化的能力，高效提取任务相关语义信息的能力，相较于传统方案可带来显著的性能提升，同时对变化的环境具有较强的适应性和鲁棒性。在面向语义通信的物理层技术方面，本报告的第五章节介绍了面向语义通信的信道表征学习与自适应调制技术，通过对调制等物理层模块进行专门的语义化设计以更好地适应相应的语义任务；联合编码调制数字语义通信方案，通过使用一个神经网络联合学习编码和调制，91IMT-2030(6G)推进组IMT-2030(6G)Promotion Group可以学习到与信道状态匹配的调制策略；基于卡尔曼滤波的端到端空口设计，实现高鲁棒性、快速收敛的端到端智能空口结构与训练方法。这些成果显示，通过对物理层模块进行专门的语义化设计，有望提升语义通信在网络层、应用层等更上层结构中不同语义任务的性能。在面向语义通信的链路层技术方面，本报告的第六章节介绍了面向语义通信的混合自动重传请求和语义相似度检测，使语义通信系统能够利用无线信道环境并具备新的语义错误检测机制，从而进一步提升通信可靠性；应对动态数据环境的域自适应方案，使得数据适应网络的性能接近重新训练的上界；语义通信场景下的资源分配方案，考虑了语义通信系统的特点，可以有效地利用有限的资源；深度图像语义传输系统的自适应速率控制方案，根据语义信息、信道信噪比，实现了在不同信道条件下优秀的自适应速率控制。这些方案在一定程度上解决了语义通信中语义信源编码灵活性差、传输可靠性低等问题，可以优化网络中的资源分配，使其更好地适应动态环境以及目标任务。在语义通信的安全机制方面，本报告的第七章节介绍了一种对抗性加密训练方案，该方案可以有效保证加密和未加密模式下语义通信的准确性，并抵御攻击者窃听语义信息；一种基于数据混淆的语义信息安全传输机制，使得攻击者在各种信噪比的条件下都无法重构出质量较好的图像。这些方案一定程度上解决了语义通信系统中窃听的安全问题，显著提高了通用结构的语义通信系统的隐私保护能力。本报告的第八章节还介绍了语义通信的网络架构，介绍了语义通信概念及术语，提出了一个通用的语义通信系统模型，基于算法信息论探讨了语义压缩极限，提出了归一化条件复杂度的概念，还从典型序列分析的角度理论分析了语义编码的潜在优势。此外，第八章节还介绍了基于语义转换的语义通信系统，提出可利用大模型得到语义公共模型，在结合本地模型构造语义转换函数，将各节点的语义信息转换到公共语义空间，实现语义传输。综上所述，语义通信相较于传统通信在多个方面具有显著的优势。随着物联网、智能家居、无人驾驶等新技术的兴起，未来通信不再仅仅是数据的传输，更多的是设备、人和系统之间的语义理解与交互。语义通信具有更强的信息表达力，相较于传统通信更加注重传输的信息的含义，以确保双方能够正确理解信息的真实意图，实现任务目标。同时，结合深度学习技术，语义通信能够自动适应各种通信环境，并优化编码与传输策略，采用自适应调制、自动重传请求等技术，从而提高通信的鲁棒性和适应性。通过知识库安全共享并结合对抗性加密等技术，语义通信能够提高对数据的隐私性保护，防止潜在的攻击者窃取信息。尽管语义通信在许多方面都显示出了巨大的潜力，但仍存在许多未解决的问题，需要学界和工业界的持续投入和合作来推动解决。比如语义通信涉及到深度学习、图结构、编码等92IMT-2030(6G)推进组IMT-2030(6G)Promotion Group复杂的技术，这些技术的计算开销较大。未来需要寻找更加高效的算法和硬件实现，以降低计算复杂性，提高实时性。随着通信中涉及的数据类型越来越多样，如何在多种数据模态之间实现一致的语义解释和传输也是一个挑战。需要深入研究如何将不同模态的信息融合，并确保在传输过程中保持一致性。虽然此报告已经介绍了一些对抗性加密和数据混淆的方法来保护语义信息的安全性，但随着攻击技术的不断进步，仍需要更加健壮和创新的安全机制来应对各种潜在的威胁。语义通信涉及多种技术和应用场景，需要建立通用的标准和协议，以确保不同系统之间的互操作性，从而实现更加开放和普适的语义通信生态。同时需要针对不同应用场景，如医疗、智能交通等，深入研究并开发适用的语义通信技术。随着语义通信的发展，还需要关注与之相关的社会和伦理问题，如隐私权、数据使用等，以确保技术的合理和负责的应用。综上所述，语义通信的发展还需学界和工业界在技术创新、标准制定和应用推广等方面共同合作，推动语义通信走向更加成熟和广泛应用的阶段。93IMT-2030(6G)推进组IMT-2030(6G)Promotion Group参考文献1 张亦驰，张平，熊急波.面向智能体的语义通信：架构与范例.J 中国科学:信息科学,2022，52(5):9079212 涂勇峰,陈文.基于联邦学习的多用户语义通信系统部署方法J.信号处理,2022,38(12):10-143 Strinati E C,S.Barbarossa.6G networks:Beyond Shannon towards semantic and goalorientedcommunicationsJ.Computer Networks,2021,190:107930.4 涂勇峰,陈文.基于深度学习的语义通信系统J.移动通信,2021,45(4):91-94.5 石光明,李莹玉,谢雪梅.语义通讯:智能时代的产物J.模式识别与人工智能,2018,31(1):91-99.6 Carnap R,Bar-Hillel Y,et al.An Outline of A Theory of Semantic Information.RLE TechnicalReports 247,19527 Bao J,Basu P,Dean M,et al.Towards a theory of semantic communication.In:Proceedings ofthe 1st International Workshop on Network Science,West Point,2011.1101178 Juba B,Sudan M.Universal semantic communication I.In:Proceedings of ACM InternationalSymposium on Theory of Computing,Victoria,2008.1231329 Guler B,Yener A,Swami A.The semantic communication game.IEEE Trans Cogn CommunNetw,2018,4:78780210Xie H Q,Qin Z J.A lite distributed semantic communication system for Internet of Things.IEEE J SelAreas Commun,2021,39:14215311Bourtsoulatze E,Burth Kurka D,Gunduz D.Deep joint source-channel coding for wirelessimage transmission.IEEE Trans Cogn Commun Netw,2019,5:56757912Weng Z Z,Qin Z J.Semantic communication systems for speech transmission.2021.ArXiv:2102.1260513Shi G M,Gao D H,Song X D,et al.A new communication paradigm:from bit accuracy tosemantic fidelity.2021.ArXiv:2101.1264914J.Wang,S.Wang,J.Dai,Z.Si,D.Zhou,and K.Niu,Perceptual learned source-channelcoding for high-fidelity image semantic transmission,in GLOBECOM 2022-2022 IEEEGlobal Communications Conference.IEEE,2022,pp.39593964.15Y.Xiao,G.Shi,Y.Li,W.Saad,and H.V.Poor,“Towards Self-learning Edge Intelligence in6G,”IEEE Communications Magazine,vol.58,no.12,pp.3440,Dec.2020.16J.Li,J.Ma,Y.Miao,F.Yang,X.Liu,K.-K.R.Choo,Secure semantic-aware search overdynamic spatial data in VANETs,IEEE Transactions on Vehicular Technology 70(9)(2021)89128925.17Z.Zhang,J.Zhao,C.Huang,L.Li,Learning visual semantic map-matching for loosely multi-sensor fusion localization of autonomous vehicles,IEEE Transactions on Intelligent Vehicles 8(1)(2023)358367.18A.Dridi,S.Sassi,S.Faiz,Towards a semantic medical Internet of things,in:2017 IEEE/ACS14th International Conference on Computer Systems and Applications(AICCSA),2017,pp.14211428.19B.Huang,J.Tian,H.Zhang,Z.Luo,J.Qin,C.Huang,X.He,Y.Luo,Y.Zhou,G.Dan,H.Chen,S.-T.Feng,C.Yuan,Deep semantic segmentation feature-based radiomics for theclassification tasks in medical image analysis,IEEE Journal of Biomedical and Health94IMT-2030(6G)推进组IMT-2030(6G)Promotion GroupInformatics 25(7)(2021)26552664.20谢卓辰,周豪,吴妍君等.一种基于语义内容的卫星通信网络架构P.上海市：CN116073889B,2023-09-01.21C.E.Shannon,W.Weaver,“The mathematical theory of communication“.Urbana:Universityof Illinois Press,194922Y.Shi,S.Shao,Y.Wu,W.Zhang,X-G.Xia,C.Xiao,Excess distortion exponent analysis forsemantic-aware MIMO communication system,IEEE Transactions on WirelessCommunications,2023(early excess).23J.Liu,S.Shao,W.Zhang,and H.V.Poor,An indirect rate-distortion characterization forsemantic sources:General model and the case of Gaussian observation,IEEE Transactions onCommunications,vol.70,no.9,pp.59465959,Jun.2022.24I.Csiszar,“On the error exponent of source-channel transmission with a distortion threshold,”IEEE Transactions on Information Theory,vol.28,no.6,pp.823828,Nov.1982.25 C.Zhang,H.Zou,S.Lasaulce,W.Saad,and M.Kountouris,Goal-oriented communicationsfor the IoT and application to data compression,vol.5,no.4,pp.58-63,IEEE Internet ofThings Magazine,2022.26H.Zou,C.Zhang,S.Lasaulce,L.Saludjian and H.V.Poor,Goal-Oriented Quantization:Analysis,Design,and Application to Resource Allocation,in IEEE Journal on Selected Areasin Communications,vol.41,no.1,pp.42-54,2023.27C.Zhang,S.Lasaulce,M.Hennebel,L.Saludjian,P.Panciatici,and H.V.Poor,Decision-making oriented clustering:Application to pricing and power consumption scheduling,Applied Energy,297:117106,2021.28C.Zhang,N.Khalfet,S.Lasaulce,V.Varma,and S.Tarbouriech,Payoff-oriented quantizationand application to power control,15th IEEE International Symposium on Modeling andOptimization in Mobile,Ad Hoc,and Wireless Networks(WiOpt),Paris,France,2017.29R.M.Gray and D.L.Neuhoff,“Quantization,”IEEE Trans.Inf.Theory,vol.44,no.6,pp.23252383,Oct.1998.30F.Rusek et al.,Scaling Up MIMO:Opportunities and Challenges with Very Large Arrays,IEEE Signal Processing Magazine,vol.30,no.1,pp.40-60,Jan.2013.31J.Tang,Q.Yang,et al.,Information-Theoretic Limits on Compression of SemanticInformation,arXiv preprint arXiv:2306.02305,2023.32Shannon C E,Weaver W.The Mathematical Theory of CommunicationM.The University ofIllinois Press,1971.33Zhang P,Xu W,Gao H,et al.Toward Wisdom-Evolutionary and Primitive-Concise 6G:A NewParadigm of Semantic Communication NetworksJ.Engineering,2022,8(1):60-73.34Zhang P,Xu X,Dong C,et al.Intellicise communication system:model-driven semanticcommunicationsJ.The Journal of China Universities of Posts and Telecommunications,2022,29(1):2-12.35Qin Z,Tao X,Lu J,et al.Semantic communications:Principles and challengesJ.arXivpreprint arXiv:2201.01389,2021.36Li M,VITNYI P.An introduction to Kolmogorov complexity and its applicationsM.NewYork:Springer,2008.37Y.Feng,J.Xu,C.Liang,G Yu,L Hu,T Yuan.Decoupling Source and Semantic Encoding:AnImplementation Study,Electronics,vol.13,no,13,pp.2755,Jun.202395IMT-2030(6G)推进组IMT-2030(6G)Promotion Group38Jialong Xu,Bo Ai,Wei Chen,Ang Yang,Peng Sun,Miguel Rodrigues,“Wireless ImageTransmissionUsingDeepSourceChannelCodingWithAttentionModules,”IEEETransactions on Circuits and Systems for Video Technology(TCSVT),32(4):2315-2328,2022.39Jialong Xu,Bo Ai,Ning Wang,Wei Chen,“Deep Joint Source-Channel Coding for CSIFeedback:An End-to-End Approach,”IEEE Journal on Selected Areas in Communications(JSAC),41(1):260-273,2023.40Jiajia Guo,Chao-Kai Wen,Shi Jin,Geoffrey Ye Li,“Convolutional neural network-basedmultiple-rate compressive sensing for massive MIMO CSI feedback:Design,simulation,andanalysis,”IEEE Transactions on Wireless Communications,19(4):28272840,2020.41Mahdi Boloursaz Mashhadi,Qianqian Yang,Gunduz Deniz,“CNN-based analog CSI feedbackin FDD MIMOOFDM systems”,IEEE International Conference on Acoustics,Speech andSignal Processing(ICASSP),85798583,2020.42Z.Yang,M.Chen,Z.Zhang and C.Huang,Energy Efficient Semantic Communication OverWireless Networks With Rate Splitting,in IEEE Journal on Selected Areas in Communications,vol.41,no.5,pp.1484-1495,May 2023.43Devlin,Jacob,et al.Bert:Pre-training of deep bidirectional transformers for languageunderstanding.arXiv preprint arXiv:1810.04805(2018).44OpenAI.GPT-4 Technical Report,arXiv preprint arXiv:2303.08774,2023.45Wang,Shiqi et al.“Cooperative Task-Oriented Communication for Multi-Modal Data withTransmission Control.”ArXiv abs/2302.02608(2023):n.pag.46 Ye H,Li G Y,Juang B H.Deep learning based end-to-end wireless communication systemswithout pilotsJ.IEEE Transactions on Cognitive Communications and Networking,2021,7(3):702-714.47 Bourtsoulatze E,Kurka D B,Gunduz D.Deep joint source-channel coding for wireless imagetransmissionJ.IEEE Transactions on Cognitive Communications and Networking,2019,5(3):567-579.48 Zhang Z,Yang Q,He S,et al.Wireless transmission of images with the assistance of multi-level semantic informationC/2022 International Symposium on Wireless CommunicationSystems(ISWCS).IEEE,2022:1-6.49 Xie H,Qin Z,Tao X,et al.Task-oriented multi-user semantic communicationsJ.IEEEJournal on Selected Areas in Communications,2022,40(9):2584-2597.50 Liu X,Xu Q.Adaptive attention-based high-level semantic introduction for image captionJ.ACM Transactions on Multimedia Computing,Communications,and Applications(TOMM),2020,16(4):1-22.51 Zhang Z,Yang Q,He S,et al.Semantic communication approach for multi-task imagetransmissionC/2022 IEEE 96th Vehicular Technology Conference(VTC2022-Fall).IEEE,2022:1-2.52T.Han,Q.Yang,Z.Shi,S.He and Z.Zhang,Semantic-Preserved Communication System forHighly Efficient Speech Transmission,IEEE Journal on Selected Areas in Communications,vol.41,no.1,pp.245-259,Jan.2023.53T.Han,J.Tang,Q.Yang,Y.Duan,Z.Zhang and Z.Shi,Semantic-aware Speech to TextTransmission with Redundancy Removal,IEEE International Conference on Acoustics,Speechand Signal Processing(ICASSP),2023.96IMT-2030(6G)推进组IMT-2030(6G)Promotion Group54T.Han,K.Chi,Q.Yang,Y.Duan,Z.Shi and Z.Zhang,Semantic-aware Transmission forRobust Point Cloud Classification,IEEE Global Communications Conference(Globecom),2023.55Farsad N,Rao M,Goldsmith A.Deep learning for joint source-channel coding oftextC/Proceedings of 2018 IEEE International Conference on Acoustics,Speech and SignalProcessing(ICASSP).Piscataway:IEEEPress,2018:2326-2330.http:/dx.doi.org/10.1109/ICASSP.2018.846198356Choi K,Tatwawadi K,Grover A,et al.Neural joint source-channel codingC/InternationalConference on Machine Learning.New York:PMLR,2019:1182-1192.57Wang Z,Simoncelli E P,Bovik A C.Multiscale structural similarity for image qualityassessmentC/Proceedings of Thrity-Seventh Asilomar Conference on Signals,Systems&Computers.Piscataway:IEEE Press,2004:1398-1402.58Zhang R,Isola P,Efros A A,et al.The unreasonable effec-tiveness of deep features as aperceptual metricC/Proceedings of 2018 IEEE/CVF Conference on Computer Vision andPattern Recognition.Piscataway:IEEE Press,2018:586-595.59Xie H,Qin Z,Li G Y,et al.Deep learning enabled semantic communication systemsJ.IEEETransactions on Signal Processing,2021,69:2663-2675.60P.Jiang,C.-K.Wen,S.Jin,and G.Y.Li,Wireless semantic transmission via revising modulesin conventional communications.,to appear in IEEE Wireless Communications,June 2023.61姜培文,韩瑜,金石,李潇.基于 CSI反馈的语义图像传输J.中兴通讯技术,2023,29(02):24-28.62S.Guo and Y.Wang,“Signal Shaping for Semantic Communications,”arXiv preprintarXiv:2202.02072,2022.63Q.Zhou,R.Li,Z.Zhao,Y.Xiao,and H.Zhang,“Adaptive Bit Rate Control in SemanticCommunication With Incremental Knowledge-Based HARQ,”arXiv preprint arXiv:2203.06634,2022.64Y.Shao and D.Gunduz,“Semantic Communications With Discrete-TimeAnalog Transmission:APAPR Perspective,”arXiv preprint arXiv:2208.08342,2022.65Y.Bo,Y.Duan,S.Shao and M.Tao,Learning Based Joint Coding-Modulation for DigitalSemanticCommunicationSystems,202214thInternationalConferenceonWirelessCommunications and Signal Processing(WCSP),Nanjing,China,2022,pp.1-6.66W.Tong,P.Zhu,et al,6G:The Next Horizon:From Connected People and Things toConnected Intelligence.Cambridge:Cambridge University Press,2021.67Sebastian Dorner,et al,“Deep learning based communications over the air,”IEEE Journal ofSelected Topics in Signal Processing,vol.12,no.1,pp.132-143,Feb.2018.68Vishnu Raj and Sheetal Kalyani,“Backpropagation through the air:Deep learning at physicallayer without channel models,”IEEE Communications Letters,vol.22,no.11,pp.2278-2281,Nov.2018.69Faycal Ait Aoudia and Jakob Hoydis,“Model-free training of end-to-end communicationsystems,”IEEE Journal of Selected Areas in Communications,vol.37,no.11,pp.2503-2516,Nov.2019.70H.Ye,L.Liang,G.Y.Li,and B.-H.Juang,“Deep learning-based end-to-end wirelesscommunication systems with conditional GANs as unknown channels,”IEEE Transactions on97IMT-2030(6G)推进组IMT-2030(6G)Promotion GroupWireless Communications,vol.19,no.5,pp.31333143,May 2020.71B.Hu,J.Wang,C.Xu,G.Zhang and R.Li,“A Kalman-Based Autoencoder Framework forEnd-To-End Communication Systems,”PIMRC wks.2021.72Geist M,Pietquin O.Kalman temporal differencesJ.Journal of artificial intelligence research,2010,39:483-532.73P.Jiang,C.K.Wen,S.Jin,and G.Y.Li.Deep source-channel coding for sentence semantictransmission with HARQ.IEEE Transactions on Communications,2022,70(8):5225-5240.74Tong W,Li G Y.Nine challenges in artificial intelligence and wireless communications for 6G.IEEE Wireless Communications,2022,29(4):140-145.75Zhou Q,Li R,Zhao Z,et al.Adaptive bit rate control in semantic communication withincremental knowledge-based HARQ.IEEE Open Journal of the Communications Society,2022,3:1076-1089.76Zhang H,Shao S,Tao M,et al.Deep learning-enabled semantic communication systems withtask-unawaretransmitteranddynamicdataJ.IEEEJournalonSelectedAreasinCommunications,2022,41(1):170-185.77K.Chi,Q.Yang,Z.Yang,Y,Duan and Z.Zhang Resource Allocation for CapacityOptimization in Joint Source-Channel Coding Systems,IEEE International Conference onCommunications,Rome,Italy,May 2023.78Kurka,David Burth,and Deniz Gunduz.Bandwidth-agile image transmission with deep jointsource-channel coding.IEEE Transactions on Wireless Communications 20,no.12(2021):8081-8095.79Yang,Mingyu,and Hun-Seok Kim.Deep joint source-channel coding for wireless imagetransmission with adaptive rate control.In ICASSP 2022-2022 IEEE International Conferenceon Acoustics,Speech and Signal Processing(ICASSP),pp.5193-5197.IEEE,2022.80Chen,Weixuan,Yuhao Chen,Qianqian Yang,Chongwen Huang,Qian Wang,and ZhaoyangZhang.Deep Joint Source-Channel Coding for Wireless Image Transmission with Entropy-AwareAdaptive Rate Control.arXiv preprint arXiv:2306.02825(2023).81X.Luo,Z.Chen,M.Tao,F.Yang,“Encrypted semantic communication using adversarialtraining for privacy preserving.”IEEE Communications Letters,vol.27,no.6,June 2023.82T.-Y.Tung and D.Gunduz,“Deep joint source-channel and en-cryption coding:Securesemantic communications,”arXiv preprint arXiv:2208.09245,2022.83Z.He,T.Zhang,and R.B.Lee,“Attacking and protecting data privacy in edgecloudcollaborative inference systems,”IEEE Internet of Things Journal,vol.8,no.12,pp.97069716,2020.84J.Li,A.S.Rakin,X.Chen,Z.He,D.Fan,and C.Chakrabarti,“Ressfl:A resistance transferframework for defending model inversion attack in split federated learning,”in Proceedings ofthe IEEE/CVF Conference on Computer Vision and Pattern Recognition,2022,pp.10 19410202.98IMT-2030(6G)推进组IMT-2030(6G)Promotion Group致谢本报告得到 IMT-2030（6G）推进组各位领导、专家的大力支持和指导、IMT-2030（6G）无线 AI 任务组各成员单位的大力支持以及多位学术界、产业界同仁的关心和支持，在此深表感谢！表9-1 主要贡献单位序号序号主要贡献单位主要贡献单位贡献内容贡献内容1浙江大学1.2浙江大学2.13浙江大学2.2、2.3、2.44中国电信研究院2.55北京邮电大学3.16上海交通大学4.17中南大学4.28浙江大学4.39ZTE5.110北京交通大学5.2、5.311浙江大学5.412浙江大学5.5、5.613浙江大学5.7、5.8、5.914北京邮电大学5.1015东南大学6.1、7.116上海交通大学6.2、7.217上海交通大学8.118浙江大学7.319浙江大学7.420浙江大学8.221华为6.3、3.222vivo5.1223中山大学5.1124浙江大学报告总体规划构思、全文架构和内容梳理、编排校对99IMT-2030(6G)推进组IMT-2030(6G)Promotion Group附录：缩略词表缩略词缩略词英文全称英文全称中文全称中文全称AIartificial intelligence人工智能MLmachine learning机器学习DNNdeep neural network深度神经网络LDPClow-density parity-check低密度奇偶校验SCsemantic communication语义通信ARaugmented reality增强现实VRvirtual reality虚拟现实XRextended reality拓展现实IoTInternet of things物联网QoSquality of service服务质量QoEquality of experience体验质量V2Xvehicle to everything车联网通信技术IoVInternet of vehicle车联网LDAlatent dirichlet allocation潜在狄利克雷分配VANETvehicular ad-hoc network车辆自组织网络JSCCjoint source-channel coding联合信源信道编码DJSCCdeep joint source-channel coding深度联合信源信道编码ADJSCCattention based deep joint source-channel coding基于注意力机制的深度联合信源信道编码SSCCseparate source-channel coding分离信源信道编码ANNartificial neural network人工神经网络CNNconvolutional neural networks卷积神经网络SNRsignal to noise ratio信噪比FLfeature learning特征学习AFattention feature注意力特征AWGNadditive white Gaussian noise加性高斯白噪声MIMOmultiple-input multiple-output多进多出技术CSIchannel state information信道状态信息OFDMorthogonal frequency-division正交频分复用100IMT-2030(6G)推进组IMT-2030(6G)Promotion GroupmultiplexingACKacknowledge character传输请求信号FCfully connected layer全连接层MPEGmoving picture experts group运动图像专家组DNNdeep neural networks深度神经网络ResNetdeep residual network深度残差网络CAchannel attention通道注意GANgenerative adversarial network生成对抗网络CTCconnectionist temporal classification连接主义时间分类WERword error rate词错率LPIPSlearned perceptual image patchsimilarity学习感知图像块相似度KNNK-nearest neighborK最近邻算法FPSfarthest point sampling最远采样点算法NTSCCnonlinear transform source-channelcoding非线性变换联合信源信道编码CBRchannel bandwidth ratio信道带宽比VAEvariational auto-encoder变分自编码器KLkullback-leibler散度JPEGjoint photographic experts group图像信源编码方案BPGbetter portable graphicsH.265 视频编码标准的帧内图像编码PSNRpeak signal-to-noise ratio峰值信噪比MSEmean square error均方差SSIMstructural similarity index measure结构相似性MS-SSIMmulti-scale structural similarity indexmeasure多尺度结构相似性DeCNNde-convolutional neural network反卷积神经网络SS-CSIsemantic segmentation coding basedon CSI基于 CSI 的图像语义分割编码QAMquadrature amplitude modulation正交幅度调制PSKphase shift keying相移键控BPSKbinary phase shift keying二相相移键控PSNRpeak signal-to-noise ratio峰值信噪比101IMT-2030(6G)推进组IMT-2030(6G)Promotion GroupAEauto encoder自编码器KFKalman filtering卡尔曼滤波LSTMlong short-term memory长短时记忆HARQhybrid automatic repeat request混合自动重传请求CRCcyclic redundancy check循环冗余校验BERTbidirectional encoder representationfrom transformer基于变换器的双向编码器表示技术DAdomain adaptation域适应Cycle-GANcycle-consistent generativeadversarial networks循环一致性生成对抗网络Sebsemantic base语义基NCCnormalized conditional complexity归一化条件复杂度AEPasymptotic equipartition property渐近等分割联系方式邮箱：COPYRIGHT2023 IMT-2030(6G)PROMOTION GROUP.ALL RIGHTS RESERVED.

0人已浏览 2023-12-14 102页 5星级

2023 iResearch Inc.2023年中国基础软件开源产业研究白皮书2目 录CONTENTS010203开源基础软件界定及中外发展对比中国开源基础软件产业链及参与者洞察中国开源基础软件产业细分领域洞察3开源基础软件界定及中外发展对比0142023.11 iResearch I基础软件开源界限划分操作系统、数据库、中间件、AI框架底层代码按规范进行共享与协作本篇报告研究的基础软件开源范围，是指研究“开源”中“基础软件”板块的情况。开源过程中，参与者可以共享、协作完成开发，正好与基础软件庞大的开发量需求相契合。这种契合性促进了基础软件良性、可持续性发展，并因为基础软件对上层软件生态有支撑作用，基础软件的开源价值远超过单一产品的范畴，其意义惠及软件产业全领域。注释：由于暂无国内厂商主导的开源编程语言，因而不列入本报告研究范围。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。对于这四类基础软件（操作系统、数据库、AI框架、中间件），其编写者将实现功能的代码按照一定的开源规范开放，任何人可以查看、使用、贡献，同时，使用者也要遵循一定的开源规范。基础软件开源范畴界定国内基础软件开源界定基础软件具备能衍生出并支撑多个技术簇的一类根技术软件，拥有技术门槛高、衍生场景复杂等特点中间件：不同系统和应用程序之间交互与协作的桥梁AI框架：具备构建和部署人工智能模型的基础的全套开发工具操作系统：是软硬件资源的资源管理者，为用户与应用程序提供交互接口数据库：通过对数据的访问与管理，支持各种应用程序和业务的需求编程语言：人与计算机交互的“语言”，含编译器、基础编程语言、IED等社区协作：鼓励各方在开放平台上协作贡献，推动开源内容的发展创新改进：通过资源共享与协作共生，提升开源内容质量，并产生新的内容自由共享：开源内容可以免费被任何人查看、学习、使用透明与可审查：开源的源代码可以被任何人审查验证、保持质量开源精神通过传递一种对于知识分享、知识透明和平等合作的价值观，凝聚群众力量，促进开源内容传播应用与迭代升级，达到社会集体效应最大化52023.11 iResearch I软件开源规范不同许可证对软件再发行是否需要开源有不同要求，企业需根据自身商业需求谨慎选择开源代码使用来源：参考可信开源合规计划，根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。使用开源许可证需注意的风险点审判机关开发者开源许可证“两者的契约”开源者将许可证视为“合同”，基于著作权法、专利法等法律法规对相关纠纷进行判决围绕许可证可能出现的其他风险专利风险数据风险出口风险其他风险开发者商用开源代码时容易出现的违规风险：不同开源许可证对于二次发行有不同程度的开源要求，要求越严格，开发者越难保护商业版本发行的机密性，不知情企业闭源发行时越容易有侵权风险类别一允许二次闭源发行，需要保留原始版权和许可声明常见许可证：MITApache2.0BDS2.0-clause木兰宽松许可证类别二一定条件下允许二次闭源发行常见许可证：LGLP2.1，商业软件通过代码类库引用（软件代码与引用的源代码 呈“松 耦 合性”）的方式下可以闭源发行类别三不允许二次闭源发行常见许可证：GPL（其 2.0 版本不允许闭源发行，3.0版本在此之上设置了更严格的开源要求）AGPL（由GPLv3修改而来，开源要求进一步涉及到了前端、后端等衍生作品生态）木兰公共许可证开源许可证类别62023.11 iResearch I中外软件开源对比（1）开发者开源规范意识较弱、企业开源战略参与度较低，是当前国内出现的主要现象1#BD%其他木兰宽松许可证都了解且自觉遵守木兰公共许可证Mozilla许可证全部不了解直接使用LGPL许可证BSD许可证GPL许可证MIT许可证Apache许可证百分比（%）来源：Gitee2022中国开源开发者报告，结合专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。开发者对常见开源许可证了解情况开源开发者对于许可证种类与应用的了解不全17%的开源开发者对于所有开源许可证不了解但直接使用开发者对于许可证的种类认知并不全面，了解程度最高的Apache许可证占比仅有60%，对于常见开源许可证都了解且自觉遵守的开发者占比只有11%。18.6).4R.0%不了解是否开发者所在企业是否将开源列为企业战略之一中国企业对开源战略的参与度有待提高仍有一半以上企业没有将开源视为一种战略，Github2022年公布的按贡献者数量计算的顶级开源项目中，多半是国外商业公司支持的项目，很难看到中国公司的影子。国内开源认知分析72023.11 iResearch I2023.11 iResearch I来源：Github、Gitee、CSDN，根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。来源：Github、Gitee、CSDN，根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。中外软件开源对比（2）国内九成以上开发者使用开源软件，其中近半数人员参与开源，新增贡献者占比世界靠前中国开源产业起步晚，发展尚不成熟的现象可以从信息技术发展环境、权威性组织的建立这两个角度看出。权威性组织的建立方面，全球开源软件标准的权威发布机构OSI于1998年成立，但国内第一个权威性开源软件推进联盟成立于2004年；再如阿帕奇软件基金会于1999年成立，而中国开放原子开源基金会成立于2020年。起步晚也是上文中提到的开源意识欠缺等现象的主要原因。然而，不管是从世界的角度，还是国内的角度，中国开源产业仍处在“积极的上升期”。从世界角度看中国开源产业增长32%7%7&%印度中国巴西俄罗斯印度尼西亚其他国家 GitHub2022年各国新增贡献者占比（不包含美国）Github认为，到2025年，美国开源贡献者的比例会由2015年30.4%下降并稳定在16.4%，而中国开源贡献者的比例预计将达到13.3%，同时期预估其他贡献率强劲的国家数据分别是印度（7.9%）、巴西（3%）、尼日利亚（1.5%）。Github2025年开源贡献者比例预估（按国别分）从国内角度看中国开源现状 Gitee2022年平台上开源指标的变化平台仓库2500万新增用户200万新仓库480万总用户1000万 CSDN2023年调研：使用开源软件的开发者比例642%2%2%经常使用偶尔使用不清楚从未使用42I 222023开发者参与开源项目的比例8中国开源基础软件产业链及参与者洞察0292023.11 iResearch I开源产业链关系以开源社区及代码托管平台为中心，各方合力促进产业源与端共生共长发起者可以将源代码放在代码托管平台上，结合开发者的代码贡献进一步提升源代码质量。在这个代码优化的过程中，也有其他力量辅助：1）开源基金会可选择性接受项目的捐赠并运营项目；2）开源技术论坛通常会提供更广阔的开发者交流平台，提升开发者能力水平；3）开源社区评估机构可对开源社区进行评分，辅助开发者选择要参与的开源项目；4）开源产业联盟往往会对行业贡献技术指标、开源规范等，引导行业专业化发展。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。开源产业链运营：发起者为运营者开源技术论坛开源社区评估机构开源产业联盟提供参与者交流的平台，推动开源技术发展、打造最佳实践赋能开源全产业生态的循环流转与运行规范发起者代码/文档贡献参与社区互动开发者运营：开源基金会为运营者使用者开源代码托管平台代码维护：对代码进行日常维护，如审核开发者贡献的代码质量开源社区治理与运营者建立开源社区，提供开发者交流平台，包括建立sig中心、设立公开课等开源项目运营开源基金会提供基础软件发起者选择性捐赠项目102023.11 iResearch I中国基础软件开源产业主要参与者图谱来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。中间件操作系统AI框架数据库开源技术论坛开源产业联盟开源组织基础软件开源项目开源基金会开源社区评估机构X-Deep Learning开源代码托管平台112023.11 iResearch I开源企业洞察（1/2）避免聚焦ROI的短视思维，树立长期战略意识，持续加码开源项目运营基础软件的开源发起者一般为企业级开发者，对于他们来讲，开源项目从设立、运营到最终成熟是一个长期的过程。不同于传统项目具有明确、可量化的ROI，开源项目为企业带来的多为无法直接变现的间接性收益，但这类收益却是支撑企业长期走稳走强的底层动力。我们看到，市场中一些开源项目因一段时间后仍无法看到明确的项目回报而以失败告终，逐渐被开源发起者抛弃。正因如此，企业应转变短视思路，认识到开源是一种长期行为，对应制定长期战略。仅以投入产出比衡量开源项目收益将忽视开源对于企业在提升技术领导力、增进创新力、构建活力生态、树立行业标准方面的贡献，短视的战略部署无法支撑企业持续投入，等到开源项目的最终开花结果。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。开源项目长期投入要素及长期收益开源长期战略（顶层设计）运营人员投入开源技术投入开源资金投入企业组织重组开源板块规划合作伙伴联结开源长期投入要素开源项目长期收益构建活力生态提升技术领导力增进企业创新力树立行业标准降低开发费用间接收益企业长远发展持续动力收益直接企业倾向在自身技术实力较强、产品能力较扎实的领域选择开源社区运营是开源人力投入的焦点，头部企业社区人员投入量超过千名为方便各职能开源人员交流和开源业务整合，企业针对性调整组织架构基础软件是底层技术投入较多的领域之一，需要企业持续供给技术资源开源项目的研发、运营、激励都需要“真金白银”的投入企业作为开源发起者，应主导开源生态的建设，努力引入战略合作伙伴122023.11 iResearch I开源企业洞察（2/2）开源部门引领下，企业内多组织人员协作配合，推进开源项目正常运营开源项目需要企业内多组织的共同投入，开源项目的良好运营也需要不同组织间的通力协作。我国较大规模的开源企业发起者，每年投入开源项目的资金量达到10亿元级别，同时企业从包含技术、产品、运营、战略、职能各部门组织超过千人的团队，投入到开源项目的治理。近年来，越来越多的企业选择在内部设立开源部门/开源办公室（OSPO）/开源委员会，统筹沟通企业开源人员，协调开源资源分配，体现了企业对于开源战略及运营重视高度的提升。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。法务服务社区治理社区运营代码审核开源开发生态合作法务合规开源企业发起者内的多组织协作开源开发战略合作社区运营代码审核软件优化选择适合开源项目的开源协议，依据企业对项目的开源方案审定协议中个别条款向上对接高校及研究机构，加紧基础技术共建；向下对应发行版ISV厂商，将软件向更多行业及场景渗透规划开源软件迭代方向，包括但不限于软件特性增加、现有功能增强、Bug修补，并提出相应的合格指标一方面积极对社区开发者的回复给予反馈，另一方面发掘优秀的灵感，增强创新能力对开发者提交的代码进行评审，确保代码的可读性和可维护性，及时做出缺陷反馈提出企业开源项目，确定是否开源、开源时间、企业内是否具有开源应用场景以及可预期开源收益开源办公室132023.11 iResearch I2023.11 iResearch I来源：OSCHINA 2022中国开源开发者报告，艾瑞咨询研究院自主研究及绘制。来源：开源社 2022年中国开源年度报告，艾瑞咨询研究院自主研究及绘制。开源开发者洞察（1/2）开源使用者多于开源贡献者，寻求知识增长、自我认同与职业发展是开发者参与开源社区的三大主要原因开源社区中，使用开源项目的开发者占比最高，达到27.8%，仍将社区视为获取资源的重要渠道。同时我们看到，也有18.2%的开发者对社区做出了代码贡献，比例排名第二。在开发者参与开源贡献的原因中，提升自身知识技术水平、提高自我认同、获得职业发展机会排名前三，这也与开发者参与开源的方式相互印证。7.7.3.21.53.6G.6%挑战技术难题维护程序问题/可拓展性获得经济收益了解前沿技术实现互惠互利、共建共享获得职业发展机会提高自我认同提升自身知识技术水平占比（%）56.6S.9%参与开源贡献的原因开源代码仓、开源社区公开课程、讲座、技术指南已成为开发者在工作学习外的重要行业知识来源知识技术水平提升实现自我价值认同开发者多以兴趣为导向选择开源项目，在帮助项目逐渐完善的过程中，完成自身的价值认同获得职业发展机会对开源社区的贡献能够很好的反应开发者的技术素养，企业下探至社区发掘人才成为当下趋势开发者参加开源方式使用开源项目27.8%参与代码贡献18.2%参与传播开源项目13.8%参与文档相关贡献10.9%参加开源兴趣小组8.9%协助社区活动举办5.5%维护基于开源商业化项目5.2%开源布道者4.5%参与开源社区运营工作4.4%其他0.9%开源社区中，使用者比例最高，使用开源软件、发掘开源代码是大多数开发者加入开源项目的起点，随着与社区的绑定不断加深，使用者逐渐向贡献者转化，围绕项目提出自身的建议或优化方向。142023.11 iResearch I开源开发者洞察（2/2）个人开发者以爱好为导向，企业开发者重视商业化价值以开发者属性分类，开源开发者可分为个人开发者、企业开发者。这两种类型群体在参与开源项目的过程中，行为上有明显差异。个人开发者多数同时也是企业中的程序开发人员，在业余时间选择开源社区丰富自身知识储备，以兴趣为导向提供代码改进建议。企业开发者旨在实现商业收益，选取优秀开源代码，并根据自身的行业Knowhow，在其上二次开发产出定制化的行业发行版本。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。两类开源开发者行为差异参与开源目的代码贡献特征付费意愿平台权益个人开发者企业开发者出于兴趣或求知欲进入开源社区，希望学习社区内优秀代码，并与“大神”交流以商业视角出发，希望通过对开源项目的二次开发形成开源软件的行业发行版，实现商业收益代码贡献多针对于某一单一模块的能力优化或Bug修补，商业化潜力小基于企业的行业侧经验积淀，贡献根据特定场景、行业深度订制的代码或功能优化，有较强的商业化潜力通常使用免费版本，仅在公共代码仓中分享代码，并查看其他开源发起者的公共代码愿意为基于开源项目的服务或商业版付费，期望查看更完整、硬核的代码。同样地，将自身代码设置为收费，获得收益仅使用代码托管平台中的基本权益，如代码审查、测试、版本管理、关联仓库等享受平台增值服务，包括关键指标统计、操作日志管理、关键行为监控，方便社区内开发者的协同开发152023.11 iResearch I开放原子开源基金会以培育开源生态、孵化开源项目、构筑技术优势为目标的中国本土基金会秉持科技、公益、慈善的属性，华为、阿里巴巴、百度等多家行业龙头于2020年发起设立开放原子开源基金会，是目前为止中国境内最重要的开源产业非盈利机构，为行业中各参与者提供战略咨询、法律赋能、项目运营、品牌推广四大能力加持。3年内，开放原子基金会在包括操作系统、中间件、数据库的基础软件及其他共12个重点领域已通过32个开源项目的技术准入，汇聚产业领袖、行业专家与“技术大神”，履行了“提升我国对全球开源贡献”这一重要使命。来源：开放原子开源基金会官网，2023年11月；公开资料，由艾瑞咨询研究院自主研究及绘制。开放原子开源基金会技术指导营销指导项目指导用户指导项目工作委员会开源战略咨询：帮助企业制定开源战略布局，规划开源成功路径，提出开源实施方案开源法律赋能：提供开源许可证翻译，完成评审并发布。组织开源法律书籍翻译，公益课程及合规论坛开源项目运营：支持开发者社区运营，促进项目生态建设。拓展开源生态链，汇聚企业、个人、组织参与开源项目。开源品牌推广：打造年度重大品牌活动，完善传播矩阵，培养开源人才，链接各方资源促进开源繁荣理事会安全委员会技术监督委员会依据项目属性，选取若干家行业优秀企业共同组成，对项目未来发展献计献策白金捐赠人黄金捐赠人白银捐赠人开源贡献人17家13家20家6家截至2023年8月，开放原子开源基金会共有资金捐赠人58家，围绕开源项目发展的共建者超过35家，累计获得捐赠收入1.83亿元，通过TOC技术准入项目33个，处于捐赠期的开源项目18个。32个开源项目通过技术准入15个孵化期开源项目17个捐赠期开源项目40 个储备开源项目工业开源体系区块链云原生与超算RISC-V芯片终端操作系统设计自动化人工智能开发环境及语言中间件、数据库工具软件服务器操作系统安全体系16中国开源基础软件产业细分领域洞察03172023.11 iResearch I开源操作系统图谱头部操作系统开源衍生链路较长，长链路呈纺锤形分布，L2环节的商用企业角色较活跃，版本多定位于服务器与桌面操作系统场景注释：产业链展示了部分企业LOGO，并且在L1-L3中仅展示了中国参与者，但实际上也不乏国外项目参与其中。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。L0级：基础开源OSL1级：基于上游的开源OSL2级：基于L1的商业版OSL3级：L1/L2二开原创自研的操作系统，通常将底层技术进行开源基于L0级开源OS深度优化和定制，补充自主开发的先进技术、企业级功能服务，实行再开源商业公司针对L1级别的操作系统进行商业版优化发行，可选择性的开源，也可额外发行L3的开源版本在L1基础上做场景化发行；或经过L2企业版大规模验证后发行开源版L4级：其他衍生版本OS182023.11 iResearch I操作系统开源价值开源的人才吸引力契合操作系统本身性能提升与生态适配的需求操作系统的性能提升需要大量人力：从操作系统本身而言，其作为大型软件，庞杂的代码量需要相应规模的人分工合作才能共同完成设计。加之国内的操作系统起步较晚，需要更多的人才不断迭代整体性能水平。操作系统生态适配需要大量人力：操作系统需要对软硬件生态适配、兼容，才能更好的发挥其资源管理者的作用。这种适配是双向的，不同应用场景操作系统适配的生态也有所差异，随着场景的不断创新增加，生态适配性问题日渐复杂，仅靠单个操作系统发行商进行生态匹配难以解决问题，需要开源集合更多的开发者力量进行帮助。开源帮助操作系统优化性能、提升使用体验：在常见的操作系统开源sig分布中，大量的开发者有序的渗入到不同功能板块的代码仓中，帮助客户端进一步用好更好的操作系统，同时，sig常见的社区治理类板块，更好的发挥了社区的“网络效应”，实现人才生态的“源远流长”。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。操作系统开源社区常见小组分布操作系统适配生态概览技术类语言基础功能中间件图形/桌面架构/内核云原生基础设施安全测试行业解决方案治理类职能组织社区基础设施版本发行社区生态管理服务器云计算边缘计算智能终端桌面操作系统应用场景处理器服务器端设备内存系统软件数据库管理软件应用软件编译软件开源促进“更好的”操作系统被“更好地”使用硬件适配软件适配192023.11 iResearch IopenEuler数字基础设施操作系统，原子化解耦灵活构建，三向连接实现“一至无限”openEuler通过全栈原子化解耦和榫卯架构，可以做到版本灵活构建和服务自由组合，从而实现一套操作系统架构对全场景应用、主流设备的全覆盖。除南向支持多样设备，北向覆盖应用场景外，openEuler还通过分布式套件与OpenHarmony系统互通，从而提供更全面、更丰富的解决方案。这种融合不仅有助于促进用户之间的无缝交互，也为开发者提供了更多的创新空间和灵活性。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。openEuler连接全景图主流场景100%支持|含3.5W 主流应用 工业控制云原生大数据CDNMEC覆盖全场景应用支持多样性设备服务器边缘计算嵌入式云计算主流计算架构100%覆盖|220 整机，1000 板卡LoongArchARMX86RISC-VSW-64PoweropenEuler：面向数字基础设施的开源操作系统，通过一套操作系统架构 南向支持多样性设备 北向覆盖全场景应用 横向对接OpenHarmony等其他操作系统通过能力共享实现生态互通生态互通能力更享OpenHarmonyITCTOT202023.11 iResearch IopenEuler充分发挥社区“网络效应”推动生态良性循环，逐步扩展国际影响回顾openEuler的发展历程，自开源以后，社区不断完善自身的治理架构。这一举措渐渐吸引了众多厂商加入社区和发布商业发行版。随后，反哺行为开始出现，捐赠项目的数量也在不断上涨。社区已经成功建立了一个从源到端、从端扩源的良性闭环循环路径。至今，从相关指标数据来看，社区的活力在中国开源基础软件领域中屈指可数。为了进一步提升社区的活力，社区正在加强产学研联动措施，以扩大参与人才的广度和深度，以期产生更好的马太效应。社区的发展不仅局限于国内生态，还积极吸引海外参与者，致力于深化操作系统的渗透率和覆盖率，充分发挥操作系统作为“资源管理者”的角色。注释：指标数据时间截止2023年11月。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。2019.09华为宣布openEuler开源2020.12社区理事会正式成立，3万套商业装机2021.11openEuler捐赠至开放原子基金会300 企业加入社区2022.12成立openEuler项目群2023.06管理、孵化创新项目达400个openEuler社区发展概览开放透明的数据指标社区数据动态实时看板多元活跃的商用角色商用OSV：22庞大成熟的社区规模 代码仓：11K 社区用户：2087K 特别兴趣小组：103 贡献者：16.7K 是目前操作系统商用发行版最多的社区2019.12openEuler正式开源212023.11 iResearch IOpenHarmony统一框架积木化灵活应用，构建面向全场景、全连接、全智能时代的智能终端设备操作系统OpenHarmony是一个主要定位于智能终端设备操作系统的开源项目。其核心技术在于通过一套框架，实现了不同设备间的便利互通。这一套框架的积木化拼装能够覆盖多种形态的设备，包括轻量、小型和标准化设备。同时，鸿蒙的硬件生态适配非常丰富。借助这些技术架构特性，用户可以在各类设备中应用鸿蒙操作系统，实现统一便捷的设备管理。无论是智能手机、智能家居、智能穿戴还是其他智能终端设备，OpenHarmony都能提供高效、稳定的操作系统支持，为用户带来优质的智能体验。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。OpenHarmony架构与应用全景图一套开发框架支持应用运行于不同的设备形态一套架构积木化拼装，对轻量、小型、标准场景设备提供系统支持硬件生态丰富，通用处理器与各类加速器全覆盖将单用户的多种终端整合为单一虚拟终端OpenHarmony技术架构应用层发行版内核层LiteOS-MLiteOS-ALinux kernel Uniproton驱动HDF统一驱动框架开发框架与系统服务分布式基座图形部件媒体部件Ability部件ArkUI部件网络部件安全部件通信部件传感器部件政务金融制造交通教育桌面电话设备栏设置222023.11 iResearch I码云数据社区生态OpenHarmony技术架构与社区运营良性契合，打造智能终端OS根社区并向上扩展升级OpenHarmony社区是技术发展逐步演变的典范。自开源以来，OpenHarmony操作系统逐渐由仅支持小型带屏设备逐步演进为可支持复杂标准带屏设备。这意味着开源促进了OpenHarmony操作系统的技术升级，增强了对复杂、多样场景的支持。OpenHarmony的演变成果得益于其良好的技术架构，良好的系统原生特性加之后期持续的社区运营努力，便有了今天的成果。从码云数据、社区活跃度、生态等指标来看，OpenHarmony都展现出其在智能终端设备操作系统领域的卓越地位。注释：指标数据时间截止2023年11月。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。OpenHarmony社区发展概览自由流转智慧协同扎实技术功底架构解耦弹性部署极简开发一致体验2020.09OpenHarmony 1.0支持无屏设备2021.05OpenHarmony 2.0支持小型带屏设备2021.09OpenHarmony 3.0支持简单标准带屏设备2022.03OpenHarmony 3.1支持复杂标准带屏设备2023.03OpenHarmony 3.2支持复杂带屏设备Gitee指数：第一名后期社区持续运营代码行数：1亿 Star数：2.3万 fork数：6.4万 社区活跃度SIG数：59日均PR合入数：190 下载次数：1.97亿 社区贡献者：6289 芯片支持：47商用设备：130 生态伙伴：150 共建企业：51成员单位：31覆盖行业：10 开发版：120 软件发行版：30 PR数：24.4万 232023.11 iResearch I中国开源数据库图谱来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。关系型数据库时序数据库图数据库键值数据库向量及空间数据库数据库内核中国开源数据库多数基于国外成熟的数据库内核，仅少部分厂商自研242023.11 iResearch I开源数据库的行业分布传统行业与互联网行业在系统架构、运营方式及数据库通用性上具有明显差异，互联网行业更容易吸引开源开发者，因此在传统行业中闭源数据库占据主流，而互联网行业中开源数据库得到普遍应用。在这种分类方式下，数据库功能也存在明显差异，传统行业数据库更注重安全与稳定，而互联网数据库更注重灵活与扩展。虽然以云原生数据库为代表的互联网行业数据库经过商业定制后有逐步向传统行业渗透的趋势，但由于两类行业差异明显，云原生数据库在传统行业中的占比仍然较小。互联网行业及传统行业数据库开源情况及影响因素来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。互联网行业传统行业数据库通用性系统架构运营方式封闭性强：与某一适配的数据库无法适配其他行业政府（工业交通金融）通用性强：同一数据库可以轻松扩展至其他互联网平台架构复杂：多为单体应用，架构上耦合度较高，代码难度高架构轻：前端展示、中层业务处理逻辑、后端数据库“求稳定”：更注重系统对业务的安全性和稳定性的支持，因而采用自建服务器或私有云的运营方式“求灵活”：更注重系统对业务快速扩张和灵活变动的支持，因而更多采取订阅云服务的轻资产模式开源闭源：更轻、更通用、更求灵活的系统及运营思路下，开发者贡献代码意愿更强对开源的影响互联网巨头：将数据库在PaaS层封装，连带底层IaaS一起对外提供能力，帮助客户对数据库作定制化的性能调优其他厂商：具备一定技术能力，在开源社区中自行下载开源版本，在云厂商IaaS层上部署自研数据库互联网厂商开源数据库绝大部分基于云构建，可在分为两类：数据库门类较多，配套开发工具较齐全TiDBOceanBasePolarDBGDB代表开源厂商及产品阿里PingCAP兼具开源与商业发行版数据库openGauss华为传统行业中最重要的开源数据库厂商，数据库为集中式，注重安全稳定互联网行业开源已成主流；国产化替代趋势下，传统行业市场空间巨大互联网开源数据库对传统行业的渗透：传统行业逐步互联网化，一些C端业务可以适用开源数据库 鼓励国产化替代，降低传统行业对海外数据库（Oracle、DB2等）的依赖 受限于行业差异，渗透势头不大蚂蚁252023.11 iResearch I中国开源数据库开发者特征开发者对数据库内核贡献较少，主要围绕提升应用层适配进行二次开发中国开源数据库开发者主要有两类特征。第一，对数据库的核心优化贡献较弱，更多基于国内开源版数据库，在应用场景适配、二次定制开发的圈层进行开发活动。第二，国内开源数据库大多基于海外数据库内核研发，相较而言数据库内核才是网罗开发者的最大公约数，而国内开发者社区比较分散。因此，自研内核数据库社区更容易吸引硬核开发者的加入，长期来看将在社区能力值、成长性及活跃度方面得到体现。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。数据库开发者开源贡献特征数据库指标提升响应时间并发能力吞吐量性能数据备份数据恢复故障切换可靠性编程语言系统接口兼容性存储引擎数据库内核 修改计算引擎支持语法扩充 修改存储协议支持更多数据库格式 底层IO调优支持高并发能力 围绕内核层级的开发贡献围绕数据库内核开发在国外开发者中较为常见，国内开发者对此贡献较少。此种生态下，有实力的国内硬核开发者倾向于转至国外开源社区进行开发围绕数据库外层的开发贡献应用场景适配二次定制开发接口开发生态环境适配国内数据库开发者比较集中对数据库外层能力的优化给予贡献。同时，由于国内数据库大多基于国外数据库内核，开发者生态随开源项目分布较为分散开发者生态分散项目1生态1项目2生态2SQL引擎内存引擎262023.11 iResearch IopenGauss自主化根技术，夯实四高能力，内核与架构双引擎创新驱动来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。openGauss自主架构与版本发展路径基础版本2020.03Release 1.0单机极致性能2020.12Preview 1.0企业级特性2021.03Release 2.0高性能/高可靠/高安全/高智能2021.09Preview 2.1多场景支持2022.03Release 3.0分布式解决方案2022.09Preview 3.1资源池化数据安全生命周期自动化管理2023.09Release 5.1可插拔数据库引擎PDE多样性算力内存池化服务DMS内存互联储存池化服务DSS多样性存储智能运维资源管理安装部署数据迁移数据建模数据开发openGaussDataPod资源池化架构全站可观测、可追踪、全加密SQL引擎插件化开箱性能即最佳openGaussDataKit插件化架构标准化插件接口数据全生命周期管理覆盖部署开发运维等阶段社区发行版打造根技术、提供企业级内核能力商业发行版集中式数据库、多模数据库企业自用版金融、运营商、能源交通等行业openGauss基于自主化根技术，聚焦数据库内核与架构，通过技术创新解决行业需求。内核方面，不断夯实高性能、高可靠、高安全、高智能的“四高”能力，同时注重智能化建设；架构方面，围绕多样性算力融合，提升资源利用率，使能多模多态，打造资源池化插件化的架构，满足千行百业场景的诉求。通过内核与架构的双引擎创新，实现技术突破，为中国乃至全球的数据库的优质发展贡献力量。多模态HATP智能运维机密计算数据智能272023.11 iResearch IopenGauss注释：指标数据时间截止2023年11月。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。openGauss社区及行业应用评审：239K需求&问题：14.7K特别兴趣小组：24社区用户：230万 内核代码行数：240万 单位会员：457总代码行数：1500万 合并请求：14.4K高校合作：170 社区贡献者：5900 规模商用行业：10 openGauss社区看板openGauss服务千行百业能源中国海洋石油国家电网江苏电力长江电力教育北京大学公安大学北京农业大学电子科技大学制造比亚迪集团中国中车创维集团京东方科技集团政府山西财政政务云四川气象大企业央广网人福医药中储粮悦海集团交通中国民航交通运输部北京首都机场陕西西安地铁医疗三甲医院南京/上海/湖南卫健委运营商中国移动中国联通中国电信银行邮储银行兴业银行民商银行桂林银行证券保险上交所联合人寿中国人民保险中信建投证券活力创新的开发者社区汇聚实力伙伴，多样态数据库辐射千行百业开源3年来，openGauss开发者数量增长接近30倍，代码总数量增长逾4倍，社区丰富度及创新活力均有显著提升。社区用户覆盖包括金融、运营商、交通、能源等十大重点行业，并向外辐射千行百业，主要用户包括上海证券交易所、比亚迪集团、国家电网、中国联通等行业领军企业，同时云和恩墨、南大通用等国内多家主流数据库厂商成为openGauss合作伙伴。openGauss系产品覆盖关系型集中式数据库、键值数据库、地理空间数据库、时序数据库等多样形态。未来，openGauss仍将不断汇聚开发者力量，持续攻坚数据库领域，共创数智产业未来。282023.11 iResearch I中间件开源图谱开源使能范围覆盖企业底层分布式架构搭建和服务治理，生态较分散、薄弱中间件的产生与分布式架构的发展息息相关。分布式架构，尤其是其中的微服务架构，通常把系统按照业务维度切分，再通过网络将不同业务板块协作运行，以缓解我国用网人数众多、业务复杂等问题为应用程序带来的网络高并发等痛点。各业务板块运行独立性较强，协作时不仅需要各个节点之间通信、连接，还需要维持节点同步。中间件能很好的缓解此问题，因中间件本身是一种独立的系统软件或服务程序，主要解决异构网络下分布式应用软件的互联与互操作问题。中间件市场基本由商业闭源中间件厂商占据，提供应用服务器中间件、负载均衡、消息中间件等基础中间件和服务总线等数据类中间件，帮助企业在自有架构上提供更稳定的应用程序运行环境。而中间件开源主要由科技巨头领导，结合了企业内部应用实践，开源范围覆盖底层通信框架与相关服务治理，与云环境的关联更多，并在一些功能性较强的板块衍生出开源小领域，但是从中间件功能板块、开源项目数量角度、商用活跃状态等角度看，整体开源生态仍较为薄弱。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。RPC框架类作为基础设置提供远程过程调用的功能，用于不同服务之间的通信和数据传输PhxRPCMotan消息队列类异步通信功能，实现服务之间消息传送PhxQueue容器编排管理类容器编排类管理和编排容器化应用程序TKE服务治理类提供了服务注册与发现、负载均衡、熔断降级等功能，用于构建和管理微服务架构Pebble其他类分布式事务类解决分布式系统中事务一致性问题中间件开源图谱应用测试类主要负责测试应用性能、发现问题或提前演练以预防故障、优化程序：如QTFA、Arthas、ChaosBlade；安全类涵盖防恶意请求、加密、认证授权、审计等功能：如Tongsuo、Kona；292023.11 iResearch I中间件开源展望：云原生中间件云原生中间件开源能降低企业构建更敏捷云原生应用的门槛，但目前开源项目较分散，需要进一步集中开源力量来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。云原生应用编排及管理编排与调度远程调用服务代理API网关服务网格分布式架构消息处理Serverless自动化配置数据库镜像制作边缘计算人工智能大数据区块链云原生底层技术容器技术存储技术网络技术云原生顶层应用云原生应用安全云原生应用监测分析灰色填充内容表示非中间件范围，其余均为含本篇报告的中间件研究范围的部分云原生生态概览云原生的意义：通过底层云原生技术与相关应用编排管理组件的使用，在云原生生态之上运行的应用，能在构建时更快速、运行时更稳定、修改时更简便，提升企业应对快速业务变化的敏捷调整能力。云原生生态与云原生中间件云原生中间件特色：底层资源容器化，同时通过组件化、事件驱动等设计原则让中间件更具备低耦合、标准化等特性，拥有屏蔽底层技术细节、减免架构复杂度带来的管理难度，对底层流量等资源配置更加灵活等优势，让开发者集中注意力至业务逻辑，花费更少时间在非业务核心功能管理上，构建出更敏捷稳定的应用程序。云原生中间件开源现状：企业对于云原生整体生态开源贡献较为活跃，但是在云原生中间件板块，国内并未形成体系化的发展，开源社区较为分散，尚不能形成统一的标准、规范。302023.11 iResearch I中间件开源展望：安全中间件目前完全自研并开源的项目匮乏，政策与自主权需求将持续推进开源发展随着网络环境的发展，国家逐渐形成体系化的相关安全管控方式，覆盖个人信息、网络环境、相关数据传输、电子签名等领域。这些领域的安全防护都离不开密码的使用，国家对此也推出了一系列密码相关的法律法规，并在今年推出了修订版的商业密码管理条例，对于商用密码应用管理做出的规范更加细致。从最新修订版的商用密码政策来看，商用密码发展尚未成熟，仍处于国家鼓励并积极引导合规使用的阶段。政府的激励将成为安全中间件开源的发展驱动力，而开源能帮助更多人规范使用商用密码，提升身份隐私防护、数据保护等安全等级，反向促进了政策激励目标的实现。注释：政策发布时间为最新版的颁布时间；来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。安全政策与安全中间件开源可作用互补主要目的规范商用密码应用和管理，鼓励和促进商用密码产业发展认证进出口应用监督管理提出加强保护支持产权，鼓励产学研结合等鼓励措施推进商用密码检测认证体系建设，明确商用密码检测机构的资质科研检测规范对采用商用密码技术提供电子认证服务的行为和资质认定定义需要实时进口许可、出口管制的商用密码鼓励公民、法人和其他组织使用规范商用密码保护网络信息安全督促商用密码建成协作监督机制，推进信用体系建立条例重点规范活动与相关监督管理强调商用密码人才培养，鼓励行业协会等相关角色发挥作用，进行商用密码规范的宣传教育详细规定了相关法律责任，对违法行为分类，制定违法行为相对应的具体罚款金额其他强调点商业密码管理条例解读（2023.05.24）中华人民共和国个人信息保护法（2021.08.20）中华人民共和国网络安全法（2016.11.07）中华人民共和国密码法（2019.10.26）中华人民共和国数据安全法（2021.06.10）中华人民共和国电子签名法（2019.04.23）这里的安全中间件是指支持国家标准密码算法及其他国际算法，通过参数转换、对象管理、接口调度等模块，完成身份认证、安全邮件、安全传输等安全业务场景的中间件安全中间件开源厂商较少，主要使用国外OpenSSL，或 基 于OpenSSL的二次开源中间件，完全自主开源的安全中间件较为匮乏。开源安全中间件发展鼓励促进312023.11 iResearch I典型案例：华为中间件不局限于“分布式”“云原生”“基础软件”关键词，能力进一步扩展到边缘云，赋能开发者高效开发与企业敏捷创新华为中间件的开源范围涵盖底层资源弹性调用、中层服务管理编排、顶层开发协助工具等多个方面，结合华为内部丰富的磨合经验，充分发挥中间件“承上启下”的作用，屏蔽相关资源管理、服务调用等细节，以“统一化”、“标准化”为目标，持续对开发者高效开发赋能，加快企业数字化转型。不同于为常见“微服务式架构”服务的中间件，华为中间件扩大了赋能范围，中间件能力进一步扩展到边缘，简化开发者在边缘计算设备上应用的开发、部署、管理。这种能力的开源不仅仅是“云原生”意义层上的应用生态建立，更是将云的生态扩展到了距离企业更近的范围内，满足对计算实时性要求较高的企业需求，并将5G更好的引入到企业应用中，支撑企业更多业务创新模式。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。华为部分开源中间件展示KubeEdge包含云上部分的控制功能与边缘部分的控制功能，可将本机容器化应用编排和管理扩展到边缘端设备，实现云边协同KubeEdge让开发人员可以编写常规的基于http或mqtt的应用程序在Edge或Cloud的任何地方运行。更轻松的将复杂的机器学习、图像识别、事件处理等高级应用程序部署到边缘Volcano是一个建立在Kubernetes上的批处理系统，可对承接应用程序通常运行多种通用领域框架，如TensorFlow、Spark、Ray等进行集成。OpenTiny是企业级组件库解决方案，拥有主题配置系统/中后台模板/CLI 命令行等效率提升工具，一套API接口即可跨端、技术栈、版本、设计规范使用EdgeGallery包含应用编排和管理器、应用开发集成平台、应用仓库、MEP四部分，提升开发者开发、部署、管理边缘计算应用效率EdgeGallery通过开源打造一个统一开放的5G MEC产业平台，解决开发者在部署边缘应用时遇到的5G环境下，MEC网络部署差异大、应用集成难，语法语言和平台不统一问题，构筑边缘计算应用生态，以加速5G业务商用，拉升整体企业数字化水平322023.11 iResearch I2023.11 iResearch I来源：CSDN 2023中国开发者调查报告，艾瑞咨询研究院自主研究及绘制。来源：OMDIA 中国人工智能框架市场调研报告，艾瑞咨询研究院自主研究及绘制。AI框架的开源趋势AI现已经成为最受关注的开源领域，部分得益于海外厂商对AI框架开源的促进。2015年是AI开源的重要一年，TensorFlow、MXNet、Keras于该年先后开源，PyTorch紧随其后，在2016年也宣布开放。这一系列动作使得国内AI开发者可无障碍获取成熟的海外框架，海外框架由此获得先发优势。目前来看，海外框架在国内的使用率仍然领先。2016年底，以飞桨为代表的国产AI框架陆续进入市场，为AI企业提供技术自主、性能高效的开发工具，成为海外框架的有力挑战者。开发者关注的开源技术领域中AI处于领先位置18)34E%其他元宇宙操作系统数据库大前端云原生大数据编程语言AI2015PyTorch34%TensorFlow30%MindSpore11%PaddlePaddle11%OneFlow3%MXNet2%MegEngine2%Jittor1%其他6 162020AI产业发展释放底层开发需求，国产开源框架不惧挑战奋起直追中国开发者主流人工智能框架使用率排名海外AI框架开源时间2016年底，飞桨宣布开源AI产业的迅速成长，将顶层（应用层）需求向底层（开发层）传导，开发侧需求既包括本报告讨论的开源AI框架，也包括开源AI大模型以及其他开源工具。332023.11 iResearch I中国开源AI框架行业分层国内市场中，AI框架可分为通用型与垂直型两类。互联网及技术巨头基于自身基础设施布局以及资源投入优势成为通用型AI框架的主要厂商，其中飞桨与MindSpore具有较为领先的位置，提供覆盖全场景的AI开发要素。AI企业基于自身业务将底层框架开放，以及科研机构自主研发是垂直类AI框架的主要渠道，针对某一具体场景提供高效灵活的开发支持。来源：开源版本数据来自Gitee、Github，根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。中国主要开源AI框架分类2016.9通用型AI框架开源发起者多为互联网或ICT巨头（BATH），一方面AI框架的能力提供需要基于底层的基础算力、通信及云技术，科技巨头在此有较深厚的积累，另一方面AI的接口提供、算法优化以及工具套件均需要较强的技术实力，这也是科技巨头的优势所在基础设施层AI工具层模型服务层2020.32018.122017.6开源后共迭代18次，最新版3.2.0更新于2021年8月仅于开源时发行1.2版，后续无迭代记录开源后共迭代33次，最新版2.0.0更新于2023年6月开源后共迭代60次，最新版2.5.0更新于2023年7月在企业层面实行AI开源战略，将AI框架与自身业务场景深度融合。其中飞桨是国内最早开源的AI框架，MindSpore2020年开源后追赶势头迅猛与飞桨并列AI框架分层成为中国前两位的AI框架提供者。通用型AI框架垂直型AI框架领先梯队追赶梯队X-deep learning与Angel曾经作出开源框架的尝试，但或因放弃了版本维护，或因为未能持续推广框架在集团业务中的多元应用，框架均没有得到持续演进，目前处于追赶态势。提供适用于视觉、语言、知识图谱、机器学习等某一AI领域的开发框架。（X-Deep Learning）由清华大学计算机系图形学实验室开发，实现图像识别、检测、分割、生成、渲染等AI能力的开源开发框架。开源时间国内首个以AI为主营业务的企业，对外开放的围绕机器视觉打造的开发框架，主要应用于视频分析、影像处理、金融预测等领域。技术巨头推出AI通用型框架，AI厂商及研究机构聚焦垂直型框架342023.11 iResearch IAI框架能力指标可达智能水平、资源投入、开发者友好度、人时成本是框架四大能力指标去除如代码贡献者数量、版本下载量等AI社区指标，仅从框架自身角度，开发者主要通过可达智能水平、开发资源投入量、开发者友好度、开发人时成本四方面衡量AI框架的能力水平，他们分别影响着AI模型的最终性能、配合框架需投入的资源水平、开发者上手框架实现开发的门槛以及开发过程中对人员的实际消耗。从AI框架厂商角度，指标越强代表AI框架对开发者具有更强的聚拢能力，更容易形成多元、丰富的开发者生态。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。开发者视角下的AI框架能力指标可达智能水平基于此AI框架，训练模型达到相同可达水平时，所需花费的时间及所需要训练的数据集体量，这决定了采用该种AI框架开发后，所需投入的资源要素。这一般与AI框架体系中搭配的组件有关。不同框架在处理源码和编译命令时的方式有所不同，对数据的运算能力也不相同，是基于此AI框架开发的神经网络通达性的主要影响因素，即在相应领域完成某种任务的准确率、处理速度或学习能力。资源投入度开发者友好度AI框架的使用过程中，从部署、开发到落地的完整流程中，所需投入的人时成本。部分AI无法做到并行开发，以扩大开发人数的方式缩短开发周期不再可行，因此AI框架开发效率是开发时长的重要因子。AI框架编译难度是在此框架下做应用、训练开发设计的难易程度。以开发者的角度，这对应了AI框架的不同范式，不同的AI框架都有一定的学习成本，会影响开发者使用AI框架的便捷程度。开发人时成本API接口编程语言内存优化分布式运行主要能力提供模块总开发人数单人平均开发时长模型库扩展库套件库科学计算主要能力提供模块文档可视化训练调试器课程教程主要能力提供模块非并行的开发模式中无法通过“堆人”方式缩短开发时长选择最具效率 的 AI 框架是降低人时成本的重要方式352023.11 iResearch IMindSpore具有多种类模型库、数据集以及内置开发套件，可一站式满足AI开发需求。框架向下支持包括CPU、GPU、昇腾的多类型算力，向上支持国内包括紫东太初2、秦岭翔语、CodeGeeX、鹏程神农、空天灵眸等50 大模型。MindSpore深耕学术应用，在加速科学实验、启迪算法发现及促进计算优化方面支撑我国科学计算深化发展，在电子制造、生物医药、流体领域做出“AI 科学计算”的创新成果。MindSpore提供AI开发全种类套件，原生高效支持大模型开发及科学计算来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。MindSpore架构及能力特点原生支持AI大模型完备的AI开发工具，高效支持大模型开发及训练AI 科学计算手机电磁仿真、化合物预训练模型、飞机气动仿真MindSpore Lite简化部署AI实验室一站式开发Build-in套件BERTLSTMVitResNet模型库图像分类目标检测文本分类数据集在线加载快速上手官方样例仓库完备使用教程代码管理在线训练界面启动JupyterNotebook在线推理支持多种算力CPUGPUAscendMindPet简化微调MindFormers简化AI开发流程362023.11 iResearch IMindSpore注释：指标数据时间截止2023年11月。来源：根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。MindSpore丰富的社区生态论文开源仓：370 社区SIG：30 社区运营组织：30 高校及科研院所伙伴：325 社区PR总数：8.3万 社区全球下载量：650万 MindSpore社区看板社区活跃度处于国内第一梯队，联合企业及学术机构推动大模型应用MindSpores在生态活跃度及场景应用方面已处于国内第一梯队。截至目前，社区总下载量超过551万，核心贡献者超过2万4千名，服务5500 企业，与325家高校及科研院所展开合作，于其中270余家开展教学活动。持续赋能千行百业，随着MindSpore进入行业应用端，在“AI 金融”、“AI 制造”、“AI 电力”、“AI 医疗”领域逐渐树立标杆案例。同时，MindSpore进入科研院所，基于鹏程云脑II AI集群，共同打造2000亿参数的鹏程盘古中文模型，与武汉大学、中科院自动化所分别展开遥感领域人工智能研究并开发多模态（图文音）大模型，引领AI技术发展并释放产业机遇。社区企业成员：100 认证开发者：370 服务企业数量：5500 社区生态案例：100 核心贡献者：2.4万 社区开源模型：50 高校覆盖200 活动参与1万 课程数量150 学习参与20万社区比赛2万 开源贡献550 校企合作成果悟空画画紫东太初武大Luojia大模型支持【以文生图】【以文生图/以图生文】【目标检测】372023.11 iResearch I开源基础软件社区评估指数（1/4）来源：细分指标具体含义参见开源指南针官网，根据专家访谈、公开资料，由艾瑞咨询研究院自主研究及绘制。基于开源指南针社区生态体系评估系统，提出开源社区可信评估指数开源指南针（OSS COMPASS）基于海量数据以及专业的建模方法，为开源社区管理者、OSPO、学术研究人员、投资机构提供围绕开源项目的数据分析类服务。Board成员包括开源领域的专家学者、社区创始人以及企业侧开源实践人员。开源指南针是本次中国开源基础软件社区评估指数的源数据供给方，并提供了有价值的数据分析意见。开源的基础是“公开透明”，但其内核是“协作”。可以说开源为人类的协作提供了一种经典范式，各方只有通过在社区中的彼此协作，开源项目的价值才能得到提升。因此，对开源社区的评估模型紧紧围绕“协作”这一主题搭建，向下拆分为协作开发、社区服务与支撑、组织活跃度以及活跃度四维指数，且各指数间有机联结，为行业提供可信的社区健康度评估参考。活跃度体现社区持续维护和改进的综合性指标贡献者数量最近版本发布次数维护者数量更新于/创建于开源基础软件社区评估模型及指数代码是开源社区的核心，本指数围绕代码级别的开发协作建立相关指标进行评估代码参与者数量代码提交频率代码提交关联 PR 的比率是体现社区为开发者提供服务与支撑的衡量指数。与开发者通过代码在前端协同开发相对，此指标可看做是对开源后勤保障系统的整体性评估更新 Issue 数量关闭 PR 数量Issue 首次响应时间Bug类Issue处理时间Issue 评论频率组织活跃度用于评估社区中组织（商业公司、高校等）的活跃程度，体现开源社区与外界的连接与互动。指标越高，社区围绕自身构建南北向生态越丰富，商业价值与学术价值的体现越明显组织数量组织贡献者数量组织代码提交频率组织持续贡献协作开发社区服务与支撑指数算法指标权重（AHP）模型搭建382023.11 iResearch I开源基础软件社区评估指数（2/4）来源：数据及算法来自开源指南针（OSS COMPASS），统计时间为2023年1-8月。作为示意，仅展示主要基础软件开源社区活跃度指数，由艾瑞咨询研究院自主研究及绘制。中国主要操作系统开源社区指数展示OpenHarmonyopenEulerOpenAnolisOpenCloudOSopenKylin协作开发指数社区服务与支撑组织活跃度社区活跃度OpenHarmonyopenEulerOpenAnolisOpenCloudOSopenKylinOpenHarmonyopenEulerOpenAnolisOpenCloudOSopenKylinOpenHarmonyopenEulerOpenAnolisOpenCloudOSopenKylinopenEuler与OpenHarmony继承了华为软件代码开发协作的优良传统，开发者参与度、贡献度较高；社区服务与支撑指数方面，OpenHarmony较为领先，openEuler与OpenAnolis、OpenCloudOS、openKylin较为接近；组织活跃度方面，openEuler与其余4个社区指数基本相同，处于稍微领先的位置；总体来看，openEuler与OpenHarmony的社区活跃度较高，但其余社区内的开发者活动也比较丰富，基础软件开源社区总体呈现共生共荣的图景。392023.11 iResearch I开源基础软件社区评估指数（3/4）来源：数据及算法来自开源指南针（OSS COMPASS），统计时间为2023年1-8月。作为示意，仅展示主要基础软件开源社区活跃度指数，由艾瑞咨询研究院自主研究及绘制。中国主要数据库开源社区指数展示openGauss协作开发指数社区服务与支撑组织活跃度社区活跃度开源数据库社区中，在四个指标维度上各有发挥突出的社区。openGauss社区在协作开发方面有一定优势；TiDB的社区服务与支撑相对完善；同时，openGauss和TiDB都具有较高的组织活跃度；Doris在以上三项指标中的表现虽不突出，然后也均不逊色，因而在总体社区活跃度的表现上时长处于领先位置。另外，OceanBase的各项指标成绩也比较优秀，同样具备一定的竞争力。DorisTiDBStoneDBOceanBaseopenGaussDorisTiDBStoneDBOceanBaseopenGaussDorisTiDBStoneDBOceanBaseopenGaussDorisTiDBStoneDBOceanBase402023.11 iResearch I开源基础软件社区评估指数（4/4）来源：数据及算法来自开源指南针（OSS COMPASS），统计时间为2023年1-8月。作为示意，仅展示主要基础软件开源社区活跃度指数，由艾瑞咨询研究院自主研究及绘制。中国主要AI框架开源社区指数展示AI框架的开发社区中，飞桨和昇思在四项指标上都是领先意义的存在。其中，协作开发方面，昇思领先优势明显，这应与华为在代码开发方面深厚积淀与活跃氛围有关；社区服务与支撑方面，飞桨的最终指标更好，同时OneFlow与MegEngine紧随其后；组织活跃度和社区活跃度方面飞桨与昇思非常接近。总体来说，科技巨头依靠自身的人员实力和资源构建能力，更容易搭建一个生态丰富的开源社区，垂直类企业还需要持续深耕、加强投入，以缩小与前段领先者的差距。MindSpore协作开发指数社区服务与支撑组织活跃度社区活跃度OneFlowMegEngineJittorPaddlePaddleMindSporeOneFlowMegEngineJittorPaddlePaddleMindSporeOneFlowMegEngineJittorPaddlePaddleMindSporeOneFlowMegEngineJittorPaddlePaddle42LEGAL STATEMENT版权声明本报告为艾瑞数智旗下品牌艾瑞咨询制作，其版权归属艾瑞咨询，没有经过艾瑞咨询的书面许可，任何组织和个人不得以任何形式复制、传播或输出中华人民共和国境外。任何未经授权使用本报告的相关商业行为都将违反中华人民共和国著作权法和其他法律法规以及有关国际公约的规定。免责条款本报告中行业数据及相关市场预测主要为公司研究员采用桌面研究、行业访谈、市场调查及其他研究方法，部分文字和数据采集于公开信息，并且结合艾瑞监测产品数据，通过艾瑞统计预测模型估算获得；企业数据主要为访谈获得，艾瑞咨询对该等信息的准确性、完整性或可靠性作尽最大努力的追求，但不作任何保证。在任何情况下，本报告中的信息或所表述的观点均不构成任何建议。本报告中发布的调研数据采用样本调研方法，其数据结果受到样本的影响。由于调研方法及样本的限制，调查资料收集范围的限制，该数据仅代表调研时间和人群的基本状况，仅服务于当前的调研目的，为市场和客户提供基本参考。受研究方法和数据获取资源的限制，本报告只提供给用户作为市场参考资料，本公司对该报告的数据和观点不承担法律责任。法律声明

0人已浏览 2023-12-14 41页 5星级

（20232023 年年）中国信息通信研究院泰尔终端实验室 电信终端产业协会云协同创新工作委员会 2023年12月 实时云渲染技术与产业发展实时云渲染技术与产业发展研究报告研究报告 版权声明版权声明 本报告版权属于中国信息通信研究院、电信终端产业协会，并受法律保护。转载、摘编或利用其它方式使用本报告文字或者观点的，应注明“来源：中国信息通信研究院、电信终端产业协会”。违反上述声明者，编者将追究其相关法律责任。本报告版权属于中国信息通信研究院、电信终端产业协会，并受法律保护。转载、摘编或利用其它方式使用本报告文字或者观点的，应注明“来源：中国信息通信研究院、电信终端产业协会”。违反上述声明者，编者将追究其相关法律责任。前前 言言 当前，国际形势错综复杂，百年变局加速演进，全球主要经济体争先抢占新一轮科技发展增长制高点。在信息技术快速迭代及新兴应用市场需求演变升级的双轮驱动下，全球数字化建设加速推进，虚拟化、沉浸感、强交互等新方向成为行业发展焦点，实时云渲染作为以云计算为基础的新型渲染方式应运而生、蓬勃发展。实时云渲染能够提高数字内容创作效率，提升数字内容呈现质量，推动数字产业完善升级，促进数实融合深度发展，全面赋能数字产业转型，将持续为数字中国建设和数字经济发展提供多方面助力。本报告从数字化建设、顶层战略规划、新兴信息技术变革、应用场景融合拓展等四个层面分析了实时云渲染产业发展的背景，提出实时云渲染的概念及定义。首次明确了实时云渲染“四纵一体”的技术体系结构，并对低时延高带宽网络、高性能存储、分布式渲染等多项关键技术进行了重点剖析。通过行业头部企业调研、数据分析和案例梳理，并结合相关领域专家学者建议，对实时云渲染产业发展现状和未来发展趋势进行了深入研究和分析预测，希望通过本报告可以帮助实时云渲染行业相关参与者深度了解和认识整个行业的发展脉络，共同推进行业的长足发展。目目 录录 一、发展背景.1（一）数字化建设驱动实时云渲染产业应运而生.1（二）顶层战略规划为实时云渲染发展提供政策引领.2（三）新兴信息技术变革升级为实时云渲染发展夯实产业根基.3（四）应用场景融合拓展助推实时云渲染产业规模化升级.6 二、概念及内涵.7（一）需求牵引和技术演进双轮驱动，计算机渲染跨入实时云渲染时代.7（二）实时云渲染：以云计算为基础的新型渲染方式.11 三、关键技术剖析.17（一）技术体系：呈现“四纵一体”结构特征.18（二）低时延高带宽网络：构筑网络基础设施底座.19（三）云存储：满足海量多类型数据存储和管理需求.20（四）边缘计算：丰富实时性、强交互性应用场景.22（五）虚拟化：提高资源利用率和系统灵活性.23（六）异构算力池化：实现计算资源按需分配和灵活扩展.26（七）实时数据传输：全方位提升用户使用体验.27（八）音视频编解码：保障高质量音视频网络传输.29（九）分布式渲染：助力渲染效果量质齐升.34 四、产业生态及市场前景.37（一）产业形态逐步明晰，链条合作协同升级.37（二）产业市场初见规模，应用领域多向开拓.39（三）综合能力象限评估，多家主体崭露头角.41 五、发展趋势.45（一）云渲染服务从谋求单点技术的“极致”，向多元化、专业化、场景化综合生态发展.45（二）元宇宙、数字孪生、AIGC 等前沿应用为实时云渲染产业发展提供强大驱动力.48（三）人工智能技术推动实时云渲染更加智能化、自动化、高效化.50 六、行业应用与典型案例.53（一）教育行业.53（二）工业行业.54（三）医疗行业.56（四）文旅行业.59（五）金融行业.63（六）游戏行业.65（七）影视行业.75 图图 目目 录录 图 1 计算机渲染发展历程.7 图 2 实时云渲染运行过程.12 图 3 实时云渲染技术体系（2023）.18 图 4 边缘计算结构图.22 图 5 边缘计算应用场景对网络延迟要求.23 图 6 实时云渲染产业全景架构图（2023）.37 图 7 全球实时云渲染产业规模及增长预测.39 图 8 实时云渲染领导力象限图（IaaS层）.43 图 9 实时云渲染领导力象限图（PaaS层）.44 图 10 实时云渲染领导力象限图（应用层）.45 图 11 国开在线官方网站展示庭宇木鹰云教育.54 图 12 火山引擎 VR 医疗教育培训技术方案框架图.57 图 13 数字人工具平台架构图.60 图 14 元境解决方案.63 图 15 蔚领云游戏服务平台.67 图 16 元境解决方案.69 图 17 分布式实时云渲染流程.71 图 18 车载云游戏方案.72 图 19 达龙云解决方案.74 图 20 星际广场画面.76 表表 目目 录录 表 1 不同分布式渲染对比表.35 表 2 实时云渲染领导力象限评估指标体系.42 实时云渲染技术与产业发展研究报告（2023年）1 一、发展背景（一）数字化建设驱动实时云渲染产业应运而生（一）数字化建设驱动实时云渲染产业应运而生 当前，国际形势错综复杂，百年变局加速演进，全球主要经济体争先抢占新一轮科技发展增长制高点。数字经济作为继农业经济、工业经济之后的主要经济形态，以数据资源为关键要素，以现代信息网络为主要载体，以信息通信技术融合应用、全要素数字化转型为主要推动力，在加快经济社会转型的变革中发挥了关键作用，并逐步上升为各国重要战略指引。党和国家高度重视数字经济发展，党的十八大以来，以习近平同志为核心的党中央高度重视发展数字经济，不断加强顶层战略布局规划，持续完善数字化建设协调机制，在习近平新时代中国特色社会主义思想特别是习近平总书记关于网络强国的重要思想的指导下，我国数字经济顶层战略规划体系渐趋完备。2023 年 2 月，中共中央、国务院印发数字中国建设整体布局规划，规划明确，全面提升数字中国建设的整体性、系统性、协同性，促进数字经济和实体经济深度融合，以数字化驱动生产生活和治理方式变革，为以中国式现代化全面推进中华民族伟大复兴注入强大动力。数字经济已经成为推动中国经济增长、加快数字化建设的主引擎，引领传统产业转型升级，助力消费需求加速释放，促进经济形态重构变革。在数字化转型的驱动下，数实融合深入推进，人类消费需求不断升级加深，实时云渲染产业应运而生。当前，虚拟化、沉浸感、强交互等新方向成为行业发展焦点，元宇宙、数字娱乐、数字文旅、实时云渲染技术与产业发展研究报告（2023年）2 数字孪生等实时性交互应用进入发展窗口期，数字化建设驱动实时云渲染产业蓬勃向上，催化实时云渲染技术快速发展。实时云渲染能够充分发挥云端海量计算资源及高速网络传输的优势，提高数字内容创作效率，降低数字内容创作成本，提升数字内容呈现质量，升级用户使用体验，推动数字产业完善升级，已经成为数字化时代推进中国式现代化的重要引擎，并持续为数字中国建设和数字经济发展提供多方面助力。（二）顶层战略规划为实时云渲染发展提供政策引领（二）顶层战略规划为实时云渲染发展提供政策引领 国家和各地区相继出台系列政策推动数字化建设，为实时云渲染产业提供了强有力的政策支撑及广阔的发展环境。2022 年 4 月，国务院发布关于进一步释放消费潜力促进消费持续恢复的意见，提出推进“第五代移动通信（5G）、物联网、云计算、人工智能、区块链、大数据等领域标准研制，加快超高清视频、互动视频、沉浸式视频、云游戏、虚拟现实、增强现实、可穿戴等技术标准预研，加强与相关应用标准的衔接配套”。2022 年 10 月，工业和信息化部、教育部、文旅部、国家广播电视总局、国家体育总局联合发布虚拟现实与行业应用融合发展行动计划（2022-2026 年），明确将“渲染处理”作为关键技术融合创新工程重点推进，提出“重点推进渲染优化技术，研发混合云渲染、基于眼球追踪的注视点渲染、人工智能渲染等新兴技术，推动虚拟现实渲染处理向软硬耦合、质量效率兼顾的精细化方向发展”以及“开发三维场景编辑器、高性能拼接缝合、高精度云端实时渲染处理、虚拟现实视频融合制播、沉浸实时云渲染技术与产业发展研究报告（2023年）3 式音频编辑制作等关键内容生产软件”。2023 年 9 月，工业和信息化部办公厅、教育部办公厅、文化和旅游部办公厅、国务院国资委办公厅、广电总局办公厅联合印发元宇宙产业创新发展三年行动计划（20232025 年），行动计划提出，“强化人工智能、区块链、云计算、虚拟现实等新一代信息技术在元宇宙中的集成突破”、“打造适用元宇宙的智能内容生产工具，实现多人实时协同、端边云一体渲染的内容生产”。在元宇宙中，用户将实时访问大量的虚拟数据、场景和模型等，并进行实时的交互和操作，海量的图形渲染将会带来超大量数据的吞吐和计算，需要以强大的算力和实时云渲染技术为能力支撑。数字中国、虚拟现实、元宇宙等相关产业政策的发布进一步提升了新一代信息技术发展的高度，促进实时云渲染技术的创新与升级，为实时云渲染产业的生态发展、试点应用、标准构建等提供要素保障及政策引导。（三）新兴信息技术变革升级为实时云渲染发展夯实产业根基（三）新兴信息技术变革升级为实时云渲染发展夯实产业根基 云计算、人工智能、新型通信网络等为代表的新一代信息技术蓬勃发展，不断催生新行业、新应用、新模式、新生态。新兴技术已全面融入人类政治文化、社会生活、生态文明建设的各领域及全过程，成为促进消费、拉动投资、扩大市场、提升国家综合实力的重要抓手。新兴技术在人类需求以及科技创新的驱动下不断变革升级，进一步夯实以数字化技术为核心的产业发展根基。云计算技术加速演进，算力服务构建全新算力范式，为实时云实时云渲染技术与产业发展研究报告（2023年）4 渲染产业发展提供算力保障。在算力服务方面，云计算突破了单台计算机算力的瓶颈，带动算力由量变产生质变，以 GPU 为代表的新一代计算芯片正按照摩尔定律的发展规律周期性地提升着单点计算能力，推动算力服务模式创新升级，算力的发展逐渐呈现出多技术融合、多架构共存、多领域协同、多行业渗透、多元化发展的生态特征。算力服务在赋能传统行业的同时加速新兴产业算力化的进程，云网边端融合协同，形成全新算力经济范式。在云计算规模方面，Gartner 数据显示，2022 年，全球云计算市场规模为 4,910 亿美元，增速 19%，预计到 2026 年将突破万亿美元。在大模型、新场景算力需求的刺激下，云计算市场仍将保持快速的增长。实时云渲染是以云计算为基础的新型渲染方式，云计算市场的稳定发展能够为实时云渲染产业的发展提供关键的技术支撑及良好的市场环境。同时，随着市场业务发展及网络性能的不断提升，全球云计算中心算力逐渐向边缘下沉，将密集型和实时性任务迁移至附近的网络边缘，能够快速响应用户请求并提升服务质量，提高了万物互联时代大规模数据的处理效率，进一步保障了实时云渲染对实时性的高性能要求。5G F5G 双千兆网络协同发展，万兆网络融合创新，构筑实时云渲染基础设施网络支撑。以 5G 和 F5G 为代表的“双千兆”网络，能够实现超大带宽、超低时延、超高速率的网络传输，是新型基础设施的重要组成和承载底座。实时云渲染过程需要进行大量的数据传输和处理计算，低时延、高带宽网络是保障云端渲染服务器到本地用户终端设备间实时数据传输的基本条件。工业和信息化部已印实时云渲染技术与产业发展研究报告（2023年）5 发的“双千兆”网络协同发展行动计划（2021-2023 年）提出，用三年时间，基本建成全面覆盖城市地区和有条件乡镇的“双千兆”网络基础设施，实现固定和移动网络普遍具备“千兆到户”能力。截至 2023 年 6 月底，我国 5G 基站累计已达到 293.7 万个，覆盖所有地级市城区、县城城区，覆盖广度深度持续拓展。此外，我国千兆光网城市建设深度推进，万兆光网开启深入研究，通信网络全面提速扩容，全光联接已成为未来数字时代的基础。云边一体、算网一体、多元化、高质量的新型算力全面支撑数字化建设，为实时云渲染超高内容拟真度、实时交互自由度提供算力保障，构筑实时云渲染基础设施网络支撑。人工智能发展迈入全新阶段，拓宽实时云渲染上层应用生态边界。人工智能技术快速发展，机器学习算法取得重大突破，生成式人工智能技术大幅提升模型制作效率，人工智能生成内容（AIGC）重塑数字内容生产方式和消费模式。内容生产方式的变革颠覆了创作信息处理、加工、结构化的全过程，在办公、影视、娱乐、电商等数字化程度高、内容需求丰富的行业取得重大进展。人工智能算法与渲染技术的深度融合改变了应用内容的渲染效能及渲染质量，进一步拓宽实时云渲染上层应用生态边界。在渲染画面质量方面，英伟达发布的新一代系列显卡中，推出了包含深度学习超采样（DLSS）功能的驱动程序，通过降低渲染图像分辨率然后采用人工智能算法填充像素的方式，大幅提升渲染画面精细度，随着 DLSS技术的演进，画面的分辨率和帧率性能不断提升。在图像预处理方实时云渲染技术与产业发展研究报告（2023年）6 面，采用深度学习降噪处理方式预先对图像进行降噪处理，能够获得更优的峰值信噪比与结构相似性，减少高保真图像的渲染时间，提升图像最终的渲染质量。（四）应用场景融合拓展助推实时云渲染产业规模化升级（四）应用场景融合拓展助推实时云渲染产业规模化升级 实时云渲染能够为用户带来全新的交互体验和视觉体验。云购物、云会展、云论坛等新的商业场景持续壮大，云演艺、云旅游等新的文旅场景不断演进，云游戏、云社交等新的娱乐场景快速发展，数字孪生、医疗影像等工业场景不断开发。智慧可视化层面，数字孪生在智慧交通、智慧城市、智慧园区、建筑信息化领域的应用逐渐加深，随着数字经济和云端治理的发展，对场景加载、渲染、交互体验的需求不断提升，实时云渲染技术助力数字模型和真实实体的逐一映射、连接、交互，满足场景对“实时、移动、交互”的用户需求。互动娱乐层面，以云游戏为代表的数字娱乐产业在 5G 技术的催化下快速发展并呈稳定增长的趋势，已经步入“商业可行走向商业腾飞”的发展进程，在产业快速发展过程中，加快了高性能渲染算力及网络基础设施的不断建设，推动了虚拟化、流媒体传输等核心技术的研发升级，促进了网络基础设施的建设和优化，推动了实时云渲染技术的成熟与应用。根据信通院全球云游戏产业深度观察及趋势研判研究报告（2023 年）数据，2022 年中国云游戏市场收入已达 63.5 亿元人民币，同比增长 56.4%，云游戏的规模化应用成为实时云渲染产业蓬勃发展的重要助推剂。市场营销层面，在实时云渲染技术与产业发展研究报告（2023年）7 产业数字化及数字产业化的驱动下，数字技术持续赋能零售、文旅、博览、汽车、地产等行业，助力营销模式推陈出新，线上定制、线上浏览、虚拟演唱会等方式得到快速推广。实时云渲染以优质的建模效果和渲染质量，为用户呈现更真实、更逼真、更生动的写实产品或人物形象，有效提升了用户的获客率及留存率。二、概念及内涵（一）需求牵引和技术演进双轮驱动，计算机渲染跨入实时云渲染时代（一）需求牵引和技术演进双轮驱动，计算机渲染跨入实时云渲染时代 计算机渲染技术的发展过程大致可分为五个阶段，分别是早期探索阶段（20 世纪 50 年代至 70 年代）、产业化初期阶段（20 世纪80 年代）、快速成长阶段（20 世纪 90 年代）、技术加速变革阶段（21 世纪初）、行业创新与爆发阶段（21 世纪 10 年代至今）。来源：中国信息通信研究院 图 1 计算机渲染发展历程 实时云渲染技术与产业发展研究报告（2023年）8 早期探索阶段（20 世纪 50 年代至 70 年代）。1950 年，美国麻省理工学院旋风一号计算机配备了世界上第一台图形显示器，该显示器通过使用阴极射线管实现了图像显示功能，但是不能对图形进行交互操作，此时的计算机图形学处于准备和酝酿时期，称之为“被动式”图形学。1959 年，林肯实验室第一次使用了具有指挥和控制功能的阴极射线管显示器，“被动式”图形学开始迈向交互式计算机图形学。1970 年代，随着光栅显示器的诞生与应用，光栅图形学算法迅速发展，区域填充、消隐、裁剪等概念相继出现，很多国家开启以计算机图形学为基础的 CAD 系统的研究，图形学进入第一个兴盛时期，计算机图形学与渲染计算技术取得关键性突破。产业化初期阶段（20 世纪 80 年代）。20 世纪 80 年代，带有光栅扫描显示器的微型计算机和图形工作站相继诞生，极大的推动了计算机图形技术的演进。80 年代时期，图形加速硬件公司相继成立。1981 年 SGI 成立，1985 年 VideoLogic（后来改名为 Imagination Technologies）以及 ATI Technologies Inc（后来被 AMD 收购）成立，1989 年 S3 Graphics 成立。产业链的不断完善推动了图形硬件的创新和竞争，图形渲染的速度和质量不断提高，成本和功耗不断降低。随着奔腾系列 CPU 产品更迭升级，计算机图形的部分软件功能开始由硬件去实现，并且随着高性能显卡、液晶显示屏、高传输率大容量硬盘的推广使用，计算机整体性能不断提升。80 年代中期以后，超大规模集成电路技术快速发展，计算机运算能力显著增强，图形处理速度明显提升，全面促进了图形学相关研究方向的进展。但该实时云渲染技术与产业发展研究报告（2023年）9 时期的计算机渲染技术应用仍处于传统阶段，采用的是基于线框模型的平面着色技术，只能呈现简单的几何形状和颜色，无法呈现真实感和光影效果。快速成长阶段（20 世纪 90 年代）。20 世纪 90 年代，N64、PlayStation、Sega Saturn 等游戏主机发售，电子游戏进入 3D 游戏时代。伴随着 3D 游戏的推广，SGI 公司推出 3D 图形接口 OpenGL，微软推出用于 Windows 操作系统的 3D 图形接口 Direct3D。OpenGL和 Direct3D 为计算机图形学提供了底层支持，使得开发人员能够更好地实现复杂的 3D 图形渲染效果。1993 年 NVIDIA 成立，1994 年3dfx 成立，NVIDIA 以及 3dfx 的出现对整个计算机行业产生了极其深远的影响。1999 年，英伟达首次提出了 GPU 的概念，并推出能够提供完整渲染能力以及进行硬件加速的 GeForce 256 显卡。GPU的发明和应用，使图形渲染的功能和效率得到了极大的提升，并为图形编程和图形算法的研究和创新提供了更强大的平台和工具。芯片硬件以及软件系统的演进升级，加速了 3D 渲染技术的成熟，计算机图形学不断朝着更标准化、更集成化和更智能化的方向发展，离线渲染技术日趋成熟。技术加速变革阶段（21 世纪初）。2000 年代，采用更加复杂光照模型和算法、呈现更加真实光照效果的全局光照渲染技术开始发展。2001 年，微软推出 Direct3D 8.0，Direct3D 8.0 支持处理顶点的Vertex Shader 以及处理像素的 Pixel Shader，标志着可编程渲染管线的出现。实时云渲染技术与产业发展研究报告（2023年）10 2006 年，“云计算”概念正式被提出，云计算改变了用户获取ICT 资源的方式，引发 ICT 产业的深刻变革，云计算服务厂商相继构建多元化的云服务能力。亚马逊推出 Amazon Elastic Compute Cloud（Amazon EC2）服务，微软推出 Azure 云计算平台和 Azure Batch 服务，Google 推出 Google Cloud Platform 和 Zync Render 渲染服务。云计算具有高性能的计算资源及海量的存储资源，并能以动态按需和可度量的方式向用户提供服务，为云渲染的规模化应用奠定基础。行业创新与爆发阶段（21 世纪 10 年代至今）。随着全球云计算基础设施建设的加速推进，计算机渲染技术进入新的探索时代实时云渲染时代。2010 年 Onlive 正式推出实时云渲染服务云游戏，但受限于当时的网络条件等因素，整体处于技术探索期。2019 年随着 5G 的正式商用以及云端基础设施的日益完善，云游戏正式进入发展的窗口期，谷歌、微软、索尼、英伟达在云游戏领域投入继续扩大，国内中国移动咪咕、电信新国脉、联通小沃、腾讯、网易等都相继推出了云游戏平台。2021 年，元宇宙概念火热并相继成为各国科技竞争的战略制高点，进一步促进实时云渲染服务体系的完善与技术创新的加速。2022 年，虚拟现实（VR）软、硬件供应商密集迎来融资，海内外巨头持续加码元宇宙，基于云渲染的 Cloud XR 大幅降低头显算力门槛。2023 年，AIGC 全球高度普及，为三维内容制作和数字人赋能，实时云渲染是超写实虚拟数字人低门槛走进消费者的重要一环，其关键技术再次被行业关注。随着元宇宙、云应实时云渲染技术与产业发展研究报告（2023年）11 用等虚拟场景的不断推广及数字内容创作领域的不断升级，渲染任务对硬件计算性能和存储空间提出了新的挑战，对渲染质量和渲染时效提出了更高的要求。依托高速率、大带宽、低延时网络技术和更强大云端计算资源的实时云渲染成为行业发展的必然趋势，计算机渲染正式跨入实时云渲染时代。（二）实时云渲染：以云计算为基础的新型渲染方式（二）实时云渲染：以云计算为基础的新型渲染方式 1、实时云渲染的定义 实时云渲染是以云计算为基础的新型渲染方式，所有渲染工作都在服务器端运行，并将渲染完毕的画面及声音编码后以音视频流的方式通过网络实时传输给用户。实时云渲染是在云计算、虚拟化、渲染引擎等技术迅猛发展的基础上新兴的渲染方式，其利用云计算资源和分布式计算技术，将复杂的二维或三维图形场景实时渲染成高质量的视频流。在这种渲染方式下，客户端发起渲染交互指令，将所有的渲染工作都交由云端服务器实时进行，最后将渲染后的声音及画面编码生成音视频流形式，通过网络实时传回客户端，实现云端渲染效果的实时展现，进而保证用户获得即时的反馈和体验。2、实时云渲染运行过程 实时云渲染的原理是将所有的渲染程序部署至云端处理，渲染完成后，将编码后的视频流实时传送至客户端。运行过程如下：第一，用户根据使用需求发起创建渲染任务的请求。第二，用户在客户端向调度服务器发起渲染请求指令，调度服务器将任务相关的 3D实时云渲染技术与产业发展研究报告（2023年）12 场景数据、纹理、光照和其他参数分发至云端渲染服务器。第三，渲染服务器根据指令请求对渲染任务进行计算处理，并将渲染结果进行编码，形成视频流回传至客户端。第四，客户端对收到的视频流进行解码，并呈现最终的渲染结果。客户端将解码后的图像渲染在屏幕上，用户通过鼠标、键盘等输入设备进行操作交互时，渲染服务器响应用户操作指令，更新渲染内容。数据来源：中国信息通信研究院 图 2 实时云渲染运行过程 在整个渲染流程中，渲染服务器发挥着桥头堡的作用，服务器的架构设计及算力性能直接影响渲染的最终结果。在实时云渲染技术中，渲染服务器通常使用分布式渲染系统来进行任务的分发和并实时云渲染技术与产业发展研究报告（2023年）13 行计算，同时能按照不同的业务需求进行弹性扩展，依据渲染任务的数量和复杂度自动调整渲染节点的数量，确保在高负载或者复杂场景下仍能提供高效高质的渲染服务。渲染服务器集群会设置一个（或几个）调度节点和多个渲染节点。调度节点负责任务调度和控制整个渲染流程：在渲染计算量较高的情况下，通常会根据渲染节点的负载情况及网络延迟等因素，使用分布式任务调度算法将渲染任务动态分发给渲染节点进行并行计算，然后将渲染结果进行合并和编码，最后传输给客户端，以便实现更佳的负载均衡和最优的资源利用。渲染节点是独立的计算单元，每个渲染节点负责渲染部分场景或多个场景中的一部分，并将渲染结果返回给调度节点。不同渲染节点之间通常使用高速网络进行数据传输，并基于高速传输协议和通过优化算法来减少数据传输的延迟和带宽消耗。并行计算的渲染方式不仅能加速整体的渲染过程，还能保证渲染的画面质量和用户体验效果，进而提高整体的渲染效率。3、实时云渲染主要特征 相比于其他计算机渲染方式，实时云渲染体现了以下显著特征：一是终端设备轻量化。实时云渲染将资源消耗占比最大的图形计算需求迁移至云端后，能够大幅降低对本地终端的硬件配置需求，使终端设备的主要功能聚焦于显示和交互上，从而实现终端的无绳化、移动化、轻量化，充分释放用户的使用限制，进一步加速元宇宙等前沿应用的规模化落地。实时云渲染技术与产业发展研究报告（2023年）14 二是应用跨平台支持。实时云渲染基于云计算理念，利用云流送技术实现三维应用的交互及实时访问，通过将本地任务部署到远程服务器，通过远程高阶的计算机集群进行运算和操作，把运行结果用“流”的方式推送至各类终端。用户可通过不同的终端设备接入云端渲染服务，无需受限于特定的操作系统或终端平台，从而打破设备和地域的限制，实现资源共享和互动。三是即时便捷性。实时云渲染能够实现即时的渲染和交互体验。用户可以即时加载应用程序或场景，并立即开始进行渲染和交互操作，无需等待漫长的下载或安装过程。这种快速的部署和即时体验提供了良好的便利性和使用效率，用户可以立即享受到云端渲染的优势，无需额外的等待时间。四是渲染质量提档升级。云渲染的原理是利用高速互联网的传输能力，将渲染过程从个人终端迁移至云渲染服务器集群。海量的云端计算资源对数据的处理能力远超过单台终端设备的计算能力，因此实时云渲染的服务方式促使渲染质量进一步提档升级。五是用户体验持续进阶。实时云渲染的推广应用解除了渲染任务对终端硬件性能的依赖，打破了因设备存储、性能、算力等方面的不足对高精度、高沉浸感使用场景的桎梏。利用超强的云端计算资源，能够实现更高的画面分辨率和更流畅的交互体验，为用户带来超高清、全实时、沉浸式、强交互的全新使用感受。实时云渲染在串流和编码压缩技术的支持下，能够提供高品质的细节呈现，通过使用云端高性能渲染服务器，可以支持高分辨率、高帧率的渲染，实时云渲染技术与产业发展研究报告（2023年）15 呈现逼真的光影效果和细节，基于物理拟真渲染的技术，可以提供与本地渲染相媲美的视觉品质。此外，云端渲染具备强大的计算和处理能力，能够支持大规模并发用户和复杂的渲染场景，通过云端的资源调度和管理，能够保证用户在高负载情况下仍能获得稳定和流畅的渲染效果，尤其对于需要处理大规模渲染任务或需要同时满足多个用户需求的应用程序和场景，实时云渲染在保障良好用户体验层面发挥了关键作用。六是降本增效成果显著。当前云游戏、元宇宙、影视、文旅、教育等众多需要强渲染计算资源的新业务领域中的应用正加速推广，但因用户群体、使用场景的多元化，不同应用对算力的消耗有明显的峰谷时间差异。实时云渲染能够通过云端资源的精准化、结构化部署，充分整合和发挥云端算力资源优势，实现资源根据渲染场景的需求按需取用、灵活调度、弹性伸缩、动态扩展及高密度部署。在分时复用、全局协同调度等技术的加持下，能够大幅降低单位成本，最大限度提升全域资源利用率。七是数据安全多重保障。实时云渲染将计算模型和数据部署在云端，用户端仅处理流化数据，无需下载或保存渲染相关内容，减少了数据被盗用的风险，进一步提高了数据的安全性。同时，云平台通常具备多重安全保障机制，统一能力纳管及统一攻击防护能够应对多种突发事件和安全威胁，保护用户和应用数据的安全。4、实时云渲染与其他渲染方式的差异 实时云渲染作为计算机渲染发展的创新阶段，与离线渲染、实实时云渲染技术与产业发展研究报告（2023年）16 时渲染、混合渲染等渲染方式在实时性、交互性、应用场景、终端要求、渲染图像质量等核心维度层面既有交叉重叠，又有技术区别。离线渲染，首先进行物体建模，规划好场景和点、线、面、材质、光照等渲染参数，再根据事先定义好的场景设置，将模型在视点、光线、运动轨迹等不同因素下的视觉画面计算出来。离线渲染可以利用更高级的光线追踪、全局光照以及复杂的几何建模和纹理，生成逼真度更高的图像，因此广泛应用于需要极高图像渲染质量的场景，如电影和电视动画制作。离线渲染通常需要大量的计算资源，但因对实时性没有特殊的要求，因此离线渲染的制作周期相对较长，难以在实时场景中应用。实时渲染，要求在用户操作时，系统能够在短时间内生成并呈现高质量的图像或视频，对实时性有严苛的条件要求，以保证用户的操作交互能够得到即时的视觉反馈。实时渲染一般是在本地终端上完成，主要强调实时性和交互性，通常采用图形加速卡来实现高效的图形计算和渲染，一般用于电子游戏、3D 应用等实时的交互性应用场景中。相较于离线渲染，实时渲染的渲染时间更短，可以实时响应用户操作，但会牺牲图像质量来确保足够的帧率和响应速度，因此图像质量相对较低，无法达到真实光影的效果。混合渲染，将实时渲染和离线渲染关键技术相融合，在满足实时交互要求的同时，输出更高质量的图像或视频，需要高性能的图形硬件和与云端的稳定连接。在混合渲染中，渲染任务被拆分为在云端和本地并行处理。云端利用其强大的计算和存储能力来处理高实时云渲染技术与产业发展研究报告（2023年）17 复杂度的渲染任务，比如全局光照和复杂的阴影效果。而本地则处理一些与用户交互密切相关的渲染任务，如直接光照和视图相关的效果，来保证低延迟的要求。三、关键技术剖析 实时云渲染利用云端的强大计算能力实现高质量的图形渲染，再将渲染结果数据压缩后传输到终端，从用户的操作响应到最终的画面呈现，需要渲染引擎、服务器、通信网络、数据传输等多领域、多种类技术手段的相互配合，协同合作。实时云渲染技术并非仰仗某单一技术实现，而是一个完整的技术体系。实时云渲染技术体系涉及多项关键技术，本章选取实时云渲染技术体系中最为核心、最具代表性的关键技术进行剖析，包括降低云与端通信时延的低时延高带宽网络技术、满足海量多类型数据存储和管理需求的云存储技术、缓解云数据中心高峰期运算和带宽压力的边缘计算技术、提高资源利用率的虚拟化和异构算力池化技术、保障和提升用户体验的实时数据传输技术与音视频编解码技术、提高渲染计算速度和效率的分布式渲染技术，以期能够尽量详细和全面地帮助从业者了解实时云渲染技术体系构成及相关技术原理。实时云渲染技术与产业发展研究报告（2023年）18（一）技术体系：呈现“四纵一体”结构特征（一）技术体系：呈现“四纵一体”结构特征 来源：中国信息通信研究院 图 3 实时云渲染技术体系（2023）实时云渲染技术体系是新一代信息技术的集合体，呈现出“四纵一体”的结构特征。四纵代表支撑实时云渲染运行的四大技术领域，包括基础硬件、网络通信、基础平台服务和工具引擎，一体代表实时云渲染所依赖的核心技术是一个技术集合整体，相互融合、交叉赋能。基础硬件：实时云渲染的实现是建立在 CPU、GPU、高性能存实时云渲染技术与产业发展研究报告（2023年）19 储设备及云端服务器设备的支持之上，基础硬件的不断更新和升级是实时云渲染产业不断发展的基础和保障。同种硬件的多种类区分为不同云渲染业务需求提供了多样性的选择，增加了云渲染应用部署方式与业务需求之间的契合度，提升效能的同时减少了计算资源的浪费，全面助力产业降本增效的落实。网络通信：渲染结果的实时传输和用户操作的及时响应高度依赖于高速、稳定、低延迟的网络通信。网络通信技术搭建了机器与感官的桥梁纽带，包含 5G、边缘计算等技术在内的新一代网络通信技术将助力数据走好云端与终端的“最后一公里”，极大增强用户使用体验。基础平台服务：基础平台服务主要通过虚拟化技术和弹性资源调度技术，实现计算、存储、网络等资源的弹性调配、智能分配和自动化管理，使复杂的云渲染任务可以高效稳定运行；并利用流化技术，实现高质量的云端渲染结果实时传输。基础平台服务大幅简化了应用开发和平台运维，提升了整体资源利用率和系统扩展能力。工具引擎：工具引擎是实时云渲染技术体系的核心。精确、逼真的渲染画面是用户选择实时云渲染技术的重要驱动力。实时渲染引擎叠加 AIGC 能力形成的 AIGC 类工具，可以提供更高质量的渲染结果、更好的实时交互性、自动化的渲染流程和智能化的资源管理。（二）低时延高带宽网络：构筑网络基础设施底座（二）低时延高带宽网络：构筑网络基础设施底座 实时云渲染技术栈中的低时延高带宽网络技术是指利用高速网实时云渲染技术与产业发展研究报告（2023年）20 络传输技术，将云端计算资源和用户设备之间的通信时延降到最低，保证用户可以及时、顺畅地获取云渲染结果，并提高云渲染的效率和用户满意度。在云渲染过程中，需要进行大量的数据传输，如果网络不稳定或传输速度慢，将会导致用户体验下降和渲染时间延长，因此，低时延高带宽网络技术是保障实时云渲染运行的基础。具体可从网络架构、传输协议、缓存技术三方面进行阐述：网络架构：低时延高带宽网络技术通常采用分布式架构，将云端计算资源分散部署在多个地理位置，通过高速互联网骨干网络进行连接。例如，云渲染服务提供商可以在全球各地的数据中心部署大量计算节点，通过高速互联网骨干网络将数据传输到用户设备上。传输协议：低时延高带宽网络技术通常采用 UDP 传输层协议进行数据传输。UDP 协议相比 TCP 协议具有更低的传输时延和更高的传输速率，同时，该技术还可以利用多路复用技术来提高数据传输效率，将多个数据流合并传输，从而降低传输时延。缓存技术：低时延高带宽网络技术可以利用缓存技术来减少数据传输量和传输时延，该技术将云渲染结果缓存到用户设备本地，当用户需要重新渲染同样的场景时，可以直接使用本地缓存数据，避免重新从云端下载数据，从而提高渲染效率和用户体验。（三）云存储：满足海量多类型数据存储和管理需求（三）云存储：满足海量多类型数据存储和管理需求 云存储技术是一种基于云计算的存储服务，它将数据存储在云端服务器上，通过互联网实现数据的远程访问和共享。云存储技术是实时云渲染的核心技术之一，它可以提供高可靠性、高可扩展性、实时云渲染技术与产业发展研究报告（2023年）21 高安全性的存储服务，满足实时云渲染中海量数据的存储和管理需求，是实时云渲染实现实时、便捷、高效的重要保障。在实时云渲染中，应用数据和用户数据需要进行存储和管理，以便在不同的终端设备上进行访问和共享。渲染过程中需要处理大规模的数据，包括场景模型、纹理、光照信息等，这些数据需要快速加载、读取和写入，以支持渲染引擎的实时计算和图像生成。传统存储解决方案在面对高负载和高吞吐量的工作负载时可能无法满足要求，因此需要借助高性能存储来提供高效的数据存储和访问能力。高性能存储通常采用诸如固态硬盘（SSD）、NVMe 和高速网络存储等相关技术来实现较高的 I/O 性能和低延迟。此外，高性能存储还通过并行数据访问、数据压缩和预取等优化策略，进一步提升存储系统的性能和效率。相比传统的本地存储方式，云存储技术具有以下优势：高可靠性：云存储技术可以提供高可靠性的存储服务，通过数据备份、数据冗余等技术可以保证数据的安全性和可靠性。高可扩展性：云存储技术可以根据用户需求提供不同规模的存储容量，可以实现快速扩展和缩减存储容量。高安全性：云存储技术可以提供高安全性的存储服务，通过数据加密、访问控制等技术可以保证数据的安全性和隐私性。便捷性：云存储技术可以实现数据的远程访问和共享，用户可以在不同的终端设备上访问和管理数据，具有很高的便捷性和灵活性。实时云渲染技术与产业发展研究报告（2023年）22（四）边缘计算：丰富实时性、强交互性应用场景（四）边缘计算：丰富实时性、强交互性应用场景 边缘计算是随市场业务发展和网络性能提升而产生的一种新型的计算技术和服务形态。边缘计算作为一种新的计算范式，在更靠近终端数据的网络边缘上提供与云计算类似的算力服务，大大减少上传至云数据中心的数据量，从而缓解中心核心部分的运算压力及网络带宽压力，降低网络传输时延，提升计算效率，节约计算成本，可以更好地解决数据安全和隐私问题。边缘算力形态呈现多样化、分散化的特征，算力规模依据需要处理的数据量进行精准化的部署，规模可以接近中心云规模大小进而建设成区域性边缘，也可以在现场进行微云的部署。来源：公开资料整理 图 4 边缘计算结构图 边缘计算广泛应用在物联网、音视频、实时云渲染、智慧工厂、安防监控、新零售等领域。但对于不同细分场景，对网络延迟要求有所差别，实时云渲染对延迟要求最高的是双眼不同画面的云 XR实时云渲染技术与产业发展研究报告（2023年）23 推流服务，其次是对交互有要求的电竞娱乐、数字孪生、元宇宙场景的云游戏、云应用，要求最低的是用于普通基础办公或远程运维的 VDI 云桌面。放眼整个边缘计算应用，实时云渲染要求高于传统视频监控与智慧工程，但低于自动驾驶和远程手术。来源：公开资料整理 图 5 边缘计算应用场景对网络延迟要求 边缘数据中心规模化、规范化建设为 GPU 算力硬件设备提供了稳定的物理运行环境，云算力助推实时云渲染与边缘计算结合，给予了媲美本地运行的画质效果，考验了服务商对算力编排，资源调度，边缘异构设备混部的能力，充分利用边缘计算的特点，能对产品服务质量正向加持。（五）虚拟化：提高资源利用率和系统灵活性（五）虚拟化：提高资源利用率和系统灵活性 虚拟化技术是一种抽象计算资源的技术，它通过软件模拟和硬件资源的抽象与隔离，为上层应用程序构建出一套拥有独立资源的虚拟运行环境。虚拟化技术可以实现资源的隔离、共享、动态分配实时云渲染技术与产业发展研究报告（2023年）24 等功能，提高资源利用率和灵活性。实时云渲染行业采用的虚拟化技术主要有：GPU 虚拟化：GPU 虚拟化在云渲染技术中起着重要的角色，主流 GPU 虚拟化主要有以下几种：一是直通模式：直通模式是将物理GPU 直接透传给虚拟机使用，对比物理机性能损耗最小，硬件驱动无需修改，被各大公有云厂商广泛采用。对于支持直通的 GPU 而言，直通模式没有对可支持的 GPU 数量做限制，也没有对 GPU 功能性做阉割。GPU 厂家的绝大多数新功能可以在直通模式下无修改地支持。所以直通模式性能损耗最小，基本可达和物理 GPU 一样的性能，功能兼容性好，技术简单，运维成本低，但是不支持热迁移，不支持对 GPU 资源的分割。二是 GPU 分片虚拟化：此处的分片从两个维度上来定义：其一，是对 GPU 在时间片段上的划分，与 CPU 的进程调度类似，一个物理 GPU 的计算引擎在几个 vGPU 之间共享，而调度时间片一般都在 1-10ms 左右；其二，是对 GPU 资源的划分，主要是指对 GPU 显存的划分。以 16GB 显存的 GPU 为例：一个物理 GPU 带有 16GB 的显存，那么按照 16 个 vGPU 来划分，每个vGPU 得到 1GB 的显存。由于安全隔离的要求，每个 vGPU 独享分配给它的显存，不会与其它 vGPU 共享。分片虚拟化有一部分性能损失，但是更为灵活，可以将一块物理 GPU 卡灵活的切分成多个vGPU，并且对热迁移的支持比较友好。三是 GPU SRIOV 虚拟化：SRIOV 的本质是把一个 PCI 卡资源（PF）拆分成多个小份（VF），这些 VF 依然是符合 PCI 规范的 endpoint 设备。但是 SRIOV 虚拟化实时云渲染技术与产业发展研究报告（2023年）25 没有分片 vGPU 灵活，一般硬件决定了一块物理 GPU 可以切成几个vGPU，而且一般不能再增加。实时云渲染场景需要根据场景选择合适的 GPU 虚拟化方案，主要从安全性，性能，vGPU 数量上进行综合选择。图形 API 虚拟化：如 OpenGL 和 DirectX 虚拟化，在图形 API 层进行虚拟化。操 作 系 统 虚 拟 化：KVM、VMware、vSphere、VMware Workstation 等。多进程虚拟化：多进程虚拟化是在单个操作系统内部，通过进程级的隔离来实现虚拟化。它可以在一台服务器上同时运行多个渲染进程，在消费级显卡上实现虚拟化的资源共享，提高 CPU 和 GPU的资源利用率。相比传统的物理资源分配方式，虚拟化技术具有以下优势：高资源利用率：虚拟化技术可以将物理资源虚拟化为多个逻辑资源，提高资源利用率和灵活性。高灵活性：虚拟化技术可以实现资源的隔离、共享、动态分配等功能，提高系统的灵活性和可扩展性。高安全性：虚拟化技术可以实现资源的隔离和安全性控制，防止不同用户之间的资源冲突和安全漏洞。高可靠性：虚拟化技术可以实现资源的冗余和备份，提高系统的可靠性和容错性。实时云渲染技术与产业发展研究报告（2023年）26（六）异构算力池化：实现计算资源按需分配和灵活扩展（六）异构算力池化：实现计算资源按需分配和灵活扩展 随着计算机技术的不断发展，计算任务越来越复杂，对计算资源的需求也越来越高。实时云渲染作为一项复杂的计算任务，需要各种异构的算力资源来满足不同的需求。为了更好地利用这些资源，提高渲染效率，降低资源浪费，异构算力池化技术应运而生。异构算力池化技术是指将不同架构、不同型号的算力资源（如 CPU、GPU、NPU、DPU、FPGA 等）整合到一个统一的资源池中，根据任务需求进行动态分配和调度。这种技术可以充分利用不同算力资源的优势，实现算力资源的按需分配和灵活扩展，提高资源利用率和整体性能。异构算力池化将充分发挥各资源的优势，实现资源的最优分配与灵活扩展。不同的渲染任务对算力资源的需求差异较大，异构算力池化技术可以根据任务需求选择最适合的算力资源进行计算，从而提高渲染效率。例如，有些任务更适合使用 CPU 进行通用计算，有些任务更适合使用 GPU 进行大规模并行计算，或使用 FPGA 进行高度定制的计算。通过将这些异构资源汇集到一个资源池中，可以实现资源的最优分配与协同，充分发挥各资源的优势。异构算力池化将全面推动实时云渲染应用降本增效。传统的渲染方式会导致某些算力资源闲置，而异构算力池化技术通过统一的调度方案可以将资源充分利用，实现资源的灵活调度使用，从而提高资源利用率与整体性能，降低单一渲染场景的资源成本。实时云渲染技术与产业发展研究报告（2023年）27 随着新技术的不断涌现，异构算力池化技术将会不断创新和优化，为实时云渲染带来更加高效、灵活和便捷的服务。一是 AI 算法与异构算力池化技术的结合，实现智能化、自适应的渲染任务调度和资源管理，进一步提高渲染效率和资源利用率。二是分布式计算技术与异构算力池化技术的结合，实现大规模、分布式的云渲染场景服务，满足实时交互的需求。三是移动终端、物联网设备和异构算力池化技术的结合，实现随时随地、无处不在的渲染服务，满足业务人员、管理人员以及终端用户的使用需求。随着可穿戴设备和物联网技术的不断发展以及元宇宙产业的快速发展，云渲染服务将会更加注重移动性和便携性。（七）实时数据传输：全方位提升用户使用体验（七）实时数据传输：全方位提升用户使用体验 实时云渲染技术中的实时数据传输技术，是指将云端渲染服务产生的渲染数据实时传输到用户的设备上，以便用户可以实时查看渲染结果的技术。主要包括数据压缩、传输协议、网络架构、数据缓存和预加载、带宽控制技术、安全技术等。数据压缩：实时数据传输需要将大量的数据快速传输到用户端，因此需要采取数据压缩技术来减少数据传输量。通常采用的压缩算法包括基于视频编码标准的压缩算法（如 H.264、H.265）和基于图像压缩的算法（如 JPEG、PNG）等，这些算法具有高效的压缩性能和良好的图像质量，可以在保证传输速度的同时提供高质量的渲染结果。传输协议：实时数据传输需要采用高效的传输协议，在保证数实时云渲染技术与产业发展研究报告（2023年）28 据传输实时性的同时，提供高速的传输速度。通常采用的传输协议包括 RTC、QUIC、SRT 等，这些协议具有低延迟、高速率和可靠性强等特点，可以满足实时数据传输的需求。网络架构：实时数据传输需要采用高速、低延迟的网络架构，将云端计算资源和用户设备之间的通信时延降到最低。通常采用的网络架构有分布式架构、CDN 加速等，这些架构可以提高数据传输速度和稳定性，减少数据传输时延。数据缓存和预加载：实时数据传输需要采用缓存技术来提高数据传输效率和用户体验。当用户需要重新查看渲染结果时，通过在用户设备上缓存部分渲染数据或提前加载下一帧的数据，可以减少等待时间，实现更快速的渲染和显示，提高查看效率和用户体验。带宽控制技术：实时数据传输需要控制数据传输速度，避免实时音视频流的传输占用过多网络带宽，造成带宽抢占。根据当前的网络带宽情况，动态调整数据传输的速率和质量，以确保渲染结果能够在不同网络条件下快速和稳定地传输。通常采用的带宽控制技术有流量控制、速率限制等，通过控制数据传输速度，可以保证数据传输的稳定性和可靠性。安全技术：实时数据传输需要采用安全技术来保护数据传输的安全性。通常采用的安全技术有 SSL 加密、数字签名等，可以保护数据传输过程中的数据不被篡改或窃取。实时数据传输是实现云渲染的关键技术之一。它通过快速、稳定地传递用户指令和云端渲染结果，保障反馈的及时准确性，为用实时云渲染技术与产业发展研究报告（2023年）29 户降低了设备要求、提供多设备兼容性，实现了高效的云渲染体验。同时，它还为远程渲染和灵活扩展等方面提供了支持，推动了云渲染在各个领域的广泛应用。（八）音视频编解码：保障高质量音视频网络传输（八）音视频编解码：保障高质量音视频网络传输 音视频编解码技术是一种将音频和视频数据进行压缩和解压缩的技术，旨在减小数据量以便在有限的带宽和存储容量条件下传输和存储音视频内容，在多媒体通信、流媒体传输、视频会议等领域起到了关键作用。音视频编解码技术在云渲染场景中扮演着重要角色，它能高效地压缩渲染图像和音频信号，并通过网路传输至客户端，进行数据的解码与展示。同时，还可利用 GPU 进行编解码实现高性能、高效率的数据处理，提供顺畅的音视频渲染体验。主要包括视频编解码技术、音频编解码技术。1、视频编解码技术 编码算法：视频编码技术利用压缩算法对渲染图像进行压缩，以减小数据量并提高传输效率。常见的视频编码算法包括 H.264、H.265（HEVC）、VP8、VP9、AV1 等，这些算法通过去除冗余信息、空间和时间相关性等方法来实现高效压缩。VVC（Versatile Video Coding）作为一种新的视频编码标准，目前正在探索阶段。VVC 标准的目标是在保持高质量视频编码的情况下，能够降低码率和延迟。与 HEVC 相比，VVC 编码预计将码率降低 50%以上，同时还能提高视频质量和编码效率。GPU 加速编解码：使用 GPU 进行编解码可以利用其并行计算能实时云渲染技术与产业发展研究报告（2023年）30 力，加速编码和解码过程。通过 GPU 的硬件加速和并行计算能力，可以实现更高的编解码性能和效率，减轻 CPU 负担，提升整体系统性能。码率控制：在云渲染场景中，通过控制编码器输出的比特率来平衡视频质量和传输带宽。常见的码率控制方法包括恒定比特率（CBR）、可变比特率（VBR）、恒定质量（CQP）等。分辨率和帧率动态调整：需要支持 1080P8K、60140FPS 等分辨率和帧率的编码。并能根据网络带宽和设备性能动态调整视频的分辨率和帧率以适应不同的播放环境，动态调整可以通过分辨率缩放、自适应码率等技术实现。编码输入格式：云渲染需要支持多种编码输入格式，以满足不同客户和应用的需求。常见的编码输入格式包括 YUV 格式和 RGB 格式。YUV 格式是视频编码中常见的原始像素格式之一，它将每个像素分为亮度（Y）和色度（U、V）分量。常见的 YUV 格式包括 YUV420、YUV422、YUV444 等。其中，YUV420 是最常用的格式，它使用更低的带宽来传输色度信息，适用于大多数视频应用。RGB 格式是另一种常见的原始像素格式，它直接表示每个像素的红、绿、蓝三个颜色分量。常见的 RGB 格式包括 RGB888、RGBA8888、ARGB8888 等。RGB 格式在一些特定的应用场景中更为常用，例如GPU 渲染输出的图像格式。图像组大小控制：图像组（Group of Pictures，简称 GOP）大小可以影响视频编码的压缩效率、传输延迟和解码质量。较小的 GOP实时云渲染技术与产业发展研究报告（2023年）31 可以提高视频编码的压缩效率，减小每个 GOP 的数据量，但也会增加传输延迟，因为解码器需要等待关键帧来恢复视频序列。较大的GOP 可以减小传输延迟，但可能会降低压缩效率和解码质量，因为非关键帧的压缩依赖于之前的关键帧。编码器模式：快速模式、标准模式和高质量模式在云渲染中用于平衡编码速度和视频质量。选择适当的编码器模式取决于应用或服务的具体需求，需要权衡实时性、高效编码和高视觉保真度之间的需求。快速模式旨在追求较快的编码速度，适用于对实时性要求较高的场景。在快速模式下，编码器会采用一些快速算法和设置，以减少编码时间，但可能会牺牲一定的视频质量。标准模式是编码器的默认设置，提供了平衡编码速度和视频质量的选择。在标准模式下，编码器会根据一般需求采用合理的算法和参数配置，以在编码速度和视频质量之间取得平衡。高质量模式注重优化视频质量，愿意牺牲编码速度和效率来获得更好的视觉效果。在高质量模式下，编码器会采用更复杂的算法和更精细的参数配置，以提高视频的视觉质量，但可能会增加编码时间。随着人工智能的快速发展以及与各产业的深度融合，在传统的混合编码框架下，AI 深度学习技术被逐渐应用于编解码中，能够更好地提升编码效率和质量。主要包括以下几个方向：基于机器学习的预测编码：预测编码是一种常用的视频编码技术，它通过利用视频帧间的相关性来进行压缩。基于机器学习的预实时云渲染技术与产业发展研究报告（2023年）32 测编码可以利用神经网络等机器学习模型来预测视频帧间的相关性，从而提高编码效率和质量。基于深度学习的视频超分辨率：视频超分辨率是一种通过增加视频的空间分辨率来提高视频质量的技术。基于深度学习的视频超分辨率可以通过训练神经网络来实现高质量的视频超分辨率，从而提高视频编码的质量和效率。基于深度学习的视频降噪：视频降噪是一种通过去除视频中的噪声来提高视频质量的技术。基于深度学习的视频降噪可以通过训练神经网络来实现高质量的视频降噪，从而提高视频编码的质量和效率。基于深度学习的视频修复：视频修复是一种通过修复视频中的损坏和缺失来提高视频质量的技术。基于深度学习的视频修复可以通过训练神经网络来实现高质量的视频修复，从而提高视频编码的质量和效率。2、音频编解码技术 编码算法：音频编码技术使用压缩算法将音频信号转换为数字数据，并减小数据量以提高传输效率。常见的音频编码算法包括PCM（脉 冲 编 码 调 制）、MP3（MPEG-1 Audio Layer 3）、AAC（Advanced Audio Coding）等。采样率和量化位数：在云渲染场景中，音频编码需要根据网络条件和带宽限制，动态调整采样率和量化位数，以平衡音频质量和传输效率。常见的音频采样率包括 44.1 kHz、48 kHz 等。常见的量实时云渲染技术与产业发展研究报告（2023年）33 化位数有 8 位、16 位、24 位等。声道数：在云渲染中，根据场景的需求和音频效果的要求，需要选择合适的声道数。对于需要呈现逼真环境的场景，使用多声道可以提供更具沉浸感的音频效果。对于一些简单的场景或低延迟的应用，可能只需要使用单声道或立体声即可满足要求。常见的声道数包括单声道（Mono）、立体声（Stereo）等。熵编码：音频编码技术使用熵编码算法（如霍夫曼编码、算术编码）对量化后的音频数据进行进一步压缩，以减少冗余信息。音频预处理：在编码前对音频信号进行预处理，如降噪、混响抑制、均衡器调节等，以提高编码后音频的质量和环境适应性。动态质量调整：音频编码技术可以根据网络状况和设备性能实时调整编码参数，以平衡音频质量和传输效率，提供最佳的音频体验。音频混音：将多个音频源混合成单个音频流的技术，常用于多音轨或多人协同场景。音频混音可以实现不同音频源之间的平衡、混合和定位，以创建更丰富的音频体验。音视频编解码是保证实时云渲染正常运行的关键，由于实时云渲染场景的特殊性，因此对音视频编解码技术在实时性、传输效率、跨平台兼容性、多媒体格式支持、多路流处理等方面提出了更高的要求。实时性要求：实时云渲染要求渲染结果能够在用户终端设备上实时显示，以达到交互性和即时性的要求，部分云渲染任务规模较实时云渲染技术与产业发展研究报告（2023年）34 大，但仍需要稳定地、实时地进行音视频数据的处理，因此对编码器性能提出了更高的要求。传输效率：云渲染需要对音视频数据进行高效的压缩和传输，以减小数据量并降低网络传输的带宽要求。同时，还需要保证在压缩过程中尽量减少对音视频质量的影响，以提供高质量的音视频渲染。跨平台兼容性：云渲染应用场景可能会面向不同的终端设备，因此音视频编解码需要具备跨平台兼容性，能够在不同设备上进行编解码操作，并确保兼容性和可靠性。多媒体格式支持：云渲染中涉及到多种多媒体格式，包括不同的视频编码标准、音频编码格式等。编解码器需要支持广泛的多媒体格式，以满足不同场景和客户需求。多路流处理：在云渲染中，可能需要同时处理多个音视频流，如多个渲染任务的音视频数据。编解码器需要具备多路流处理的能力，能够同时解码和编码多个音视频流，并保持良好的性能和质量。（九）分布式渲染：助力渲染效果量质齐升（九）分布式渲染：助力渲染效果量质齐升 分布式渲染技术是一种利用多台计算机（或多个计算节点）分布式协同渲染单帧图像的网络渲染技术，可提供影视级的真实感效果、更逼真的光照及粒子特效。通过将任务分配给不同的节点，分布式渲染可以提高渲染速度和效率，同时还可以减轻单个节点的压力。分布式渲染服务通常提供管理工具和 API，以便用户可以轻松地管理和监控他们的工作负载。在部分渲染场景中，需要同时联合实时云渲染技术与产业发展研究报告（2023年）35 声音技术更准确地还原空间声场，以与场景深度融合，因此需要更强的计算资源支持，传统单节点机器难以在效果与性能上取得平衡，此时需引入分布式实时渲染协同解决。分布式渲染主要采用并行图形架构，主要渲染方式如下，详见表 1。表 1 不同分布式渲染对比表 渲染类型 渲染方式 优点 缺点 Sort-first 对 屏 幕 进 行 网 格 式 划分，使其对应区域的待渲染物体由该区域的渲染 节 点 进 行 完 整 渲 染（包括几何处理和光栅化等），渲染节点完成子图像渲染结果后发送到Merge 节点进行图像拼接，形成最终图像。可水平扩展渲染节点，实现更大场景与更高清的图像渲染需求。区块划分较为单一，容易导致 负 载 不 均衡，实现较复杂，同时可能出现时延不一致导致的等待现象。Sort-middle 几何元素重新分配发生在几何变换与光栅化间进行。每个几何处理单元会被分配接近相同数量的几何数据处理，处理完后的几何则是被几何坐标变换后的几何数据。这些几何数据会被排序进 Tiles，Tiles 是一个个组成整个屏幕且互不重叠的方块。Tile 内的数据会被传递给光栅单元和像素处理单元的共用，在其缓冲中，光栅单元和像素处理单元可以对这些数据进行极快的读写从而提升了效率。几何数据在网络间传输开销较大，不太适合分布式集群架 构 共 享 处理。同时对于图形分布在多个 Tile 情况，需 要 多 次 绘制，增加了总渲染时间。Sort-last 将场景中的不同对象发可对图像进行负网络通信较为实时云渲染技术与产业发展研究报告（2023年）36 送到不同的渲染节点，每个节点渲染一个或多个具备深度的图像，最后将所有渲染结果汇总到中心节点，根据 z-buffer 进行合并。载均衡分配，避免单个节点渲染任务过重。复杂，需要传输大量图像与深度数据做后续处理；透明度难以处理。来源：公开资料整理实时分布式云渲染相对于普通实时云渲染，具有以下优势：一是分布式云渲染可以使 3D 渲染脱离算力的限制，可以满足超大规模场景、超拟真模拟、超逼真实时渲染效果的算力要求。二是能针对超大场景实现实时细分算法，无需提前处理，可将网格细节最高提升上千倍，实时呈现影视级的视觉表达。三是能实现实时物理解算与流体仿真，基于物理碰撞实现刚体与流体的实时交互，仿真与渲染可以在不同 GPU 上执行，最高实现百万级粒子实时解算。分布式渲染将呈现云原生部署、渲算分离、端云协同的发展趋势。一是弹性伸缩，将传统单体渲染架构升级为基于微服务的云原生渲染架构，充分考虑网络延时、故障容错，资源冗余等特点，实现可快速伸缩、快速部署、水平分解的面向不同场景的方案。二是渲染计算分离，将场景渲染中的图形渲染部分和引擎计算部分工作负荷分离，发挥算网异构资源充足的特点，将不同类型任务交由不同节点分别完成，最终汇总统一合并处理。三是端云协同，对渲染任务进行解耦设计，使渲染任务可以在云边端实现灵活切换和调度，有效利用终端闲置的硬件资源，复用运算结果降低重复计算，突破实时云渲染技术与产业发展研究报告（2023年）37 传统云渲染终端只做视频播放与交互的限制。四、产业生态及市场前景（一）产业形态逐步明晰，链条合作协同升级 （一）产业形态逐步明晰，链条合作协同升级 来源：中国信息通信研究院 图 6 实时云渲染产业全景架构图（2023）实时云渲染产业链条较长，主要分为底层能力、基础设施、平台服务、技术工具、行业应用及生态服务。底层能力方面，主要包括以 ARM 服务器、X86 服务器、SoC 阵列服务器等为主的基础硬件以及数据存储、通信网络服务。多元化硬件架构间的性能指标差异决定着其不同的优势和适用场景。例如，ARM 服务器具有低功耗、高集成、高性价比等特点，适于移动端的云渲染；X86 服务器具有高性能、高兼容性等特点，适于 PC 端和 VR/AR 等高画质需求云渲染；SoC 阵列服务器的高并行、低延迟、算力异构等特点，使其能够满足多样化计算场景需求。而高速、高可靠、高容量的数据存储实时云渲染技术与产业发展研究报告（2023年）38 空间，高带宽、低延迟、低抖动的通信网络连接则决定了实时云渲染的数据安全、传输速度和用户体验。基础设施服务方面，指云渲染 IaaS 算力设施服务，为用户提供计算、存储、网络等基础设施资源，并能根据用户需求实现弹性部署。当前 IaaS 算力设施服务提供商主要包括亚马逊、阿里云、腾讯云、海马云、火山引擎、启朔科技、云天畅想、瑞云科技等。随着云计算的加速演进以及应用场景的多变，算力服务的发展也逐渐呈现出多技术融合、多架构共存、多领域协同、多元化发展的生态特征，算力服务商相继推出全新的算力范式。平台服务方面，指云渲染 PaaS 平台服务，建立在云计算基础设施之上，为用户提供高效、安全、可靠、低成本的云渲染服务解决方案，助力客户快速搭建符合需求的应用及服务。主要包括提供渲染资源的分配、调度、监控、优化等功能的云渲染管理平台，提供云渲染的开发环境、开发工具、开发框架等功能，实现需求快速开发的云渲染开发平台等。当前 PaaS 平台服务商主要包括阿里元境、蔚领时代、海马云、火山引擎、移动云、达龙云、云天畅想等。技术工具方面，主要包括渲染引擎、3D 建模平台、数字人系统、AI工具及内容创作平台。内容生产方式的变革重塑了创作信息处理、加工、结构化的全过程，改变了云渲染应用内容的品质及表现形式。同时，人工智能算法与渲染技术的深度融合提升了不同场景任务的渲染效率和渲染质量。多样化技术工具的应用将突破传统建模技术的单一性桎梏，在虚拟世界建构中碰撞出令人叹为观止的化学反应，真正使想象力如臂使指。行业应用方面，实时云渲染作为以云计算实时云渲染技术与产业发展研究报告（2023年）39 为基础的新型渲染方式，依托“终端设备轻量化”、“跨平台支持”、“即时便捷性”等方面的优势，全面赋能于文旅、办公、娱乐、影响等生活消费领域，教育、医疗、交通、政务等公共服务领域，汽车、物流等生产制造领域以及元宇宙、数字孪生、AIGC 等前沿应用领域。实时云渲染较长的产业链条与交织融合的创新体系驱动厂商由供需合作向生态协同升级，主要表现为发展战略、资源整合及能力实现的协同。（二）产业市场初见规模，应用领域多向开拓（二）产业市场初见规模，应用领域多向开拓 来源：公开资料整理 图 7 全球实时云渲染产业规模及增长预测 产业市场初见规模，呈现蓬勃发展态势。根据统计及分析，2023 年，全球实时云渲染产业规模预计达到 106 亿美元，市场规模达行业预期。随着元宇宙、AIGC 等前沿应用的牵引推动以及用户消实时云渲染技术与产业发展研究报告（2023年）40 费需求的进一步升级，2025 年全球实时云渲染规模有望突破 200 亿美元，实现 41.1%的快速增长。从总体发展阶段判断，当前实时云渲染产业处于重要战略机遇期。赋能作用深入发挥，应用领域多向开拓。实时云渲染作为以云计算为基础的新型渲染方式，能够为用户带来全新的交互体验、视觉体验、沉浸体验，广泛赋能于娱乐、影视、文旅、建筑、社交、办公等日常领域及元宇宙、数字孪生、AIGC 等前沿领域。实时云渲染技术在娱乐领域主要应用于云游戏、VR/AR、动漫等行业，为用户提供高品质、高交互性、高沉浸感的娱乐体验，其中云游戏是目前实时云渲染技术在数字娱乐领域应用中市场份额占比最大的场景。随着分布式渲染、多视角协同渲染、容器化技术等能力的提升，将催生更多云原生游戏的出现，优质的云原生内容将助力云游戏实现爆发性增长，进而推动实时云渲染产业规模的不断扩大。实时云渲染技术在文旅领域主要应用于博物馆、景区、会展、虚拟活动等行业，通过数实深度融合，对文旅行业的用户体验、产业关系、文化价值、消费形式等进行多维度升级创新，为用户提供能在线上体验的高清还原的文化和旅游资源。随着文化产业数字化战略的实施落地及地方文旅资源与现代科技的紧密、快速、持续融合，实时云渲染技术将会更广泛的赋能文旅产业，数字文旅的快速发展将对实时云渲染核心技术提出更高的要求，进而推动整个产业规模的提升。前沿应用相继落地，推动全球实时云渲染朝着泛在化、智能化、多元化的方向发展。随着云计算、人工智能等技术的不断创新，实实时云渲染技术与产业发展研究报告（2023年）41 时云渲染市场正逐步成为新兴产业的新热点。元宇宙、数字孪生、AIGC 等前沿应用受到全球政府及产业的高度关注，前沿应用作为新技术落地的典型模式，将为实时云渲染市场发展提供强大的驱动力，推动实时云渲染技术的创新升级及产业的高质量发展。（三）综合能力象限评估，多家主体崭露头角（三）综合能力象限评估，多家主体崭露头角 为全面梳理我国实时云渲染产业发展现状及市场发展潜力，编制组充分结合产业发展特点和关键影响因素，依据象限评估指标体系，从技术影响力、市场影响力两大维度对实时云渲染相关企业进行了客观公正的研判评估，形成实时云渲染领导力象限图。1、象限构建原则 实时云渲染领导力象限旨在对实时云渲染领域的企业进行研究评估，为保证研究内容独立、客观，依据技术测试、问卷调研、企业调研、专家评审等方式，融合多维视角，输出分析成果。象限基于横坐标轴的市场维度和纵坐标轴的技术维度来分别选取指标构建，指标选择时遵循科学性、代表性、独立性的原则，结合行业发展特点和重点影响因素，并综合考虑到相关数据的可获取性和可比较性。象限图反映了企业的技术影响力和市场影响力，并划分为：卓越引领者、领域开拓者、创新潜力者。卓越引领者代表引领实时云渲染技术的发展，对市场发展有着积极的推动作用。领域开拓者代表面对市场挑战灵活应对，通过不断拓展业务范围争当行业先驱者，正在逐步积累技术实力。创新潜力者代表积极寻求技术的突破，持续提升产品和服务的竞争力，谨慎应对市场挑战，正积极寻求市场突实时云渲染技术与产业发展研究报告（2023年）42 破。2、象限评估范围 入选实时云渲染领导力象限的企业更专注于实时云渲染垂直细分市场，在此领域均表现优异，并通过为行业持续输出价值而占据了一席之地。象限的评估范围主要围绕实时云渲染基础设施服务提供商（IaaS）、平台服务提供商（PaaS）、行业应用提供商展开。企业根据自身业务定位实际情况选择一个或多个层级进行评选，为保证评估的公平、公正，同类型企业在同一层进行评估。3、象限评估指标体系 在建立评估指标体系前，编制组对我国实时云渲染行业发展现状进行了全面梳理，广泛征求了专家意见，结合行业发展特点和重点因素，从市场能力和技术能力两大维度搭建出评估指标体系。技术影响力主要包括创新水平、研发能力、综合性能等三项二级指标，市场影响力主要包括市场综合能力、行业覆盖能力、行业荣誉等三项二级指标，按照科学的研究与分析方法，对各项指标进行权重确定、赋值和计算打分阶段，最终根据得分表现将其划分到象限中。评估指标体系维度均为实时云渲染领域。表 2 实时云渲染领导力象限评估指标体系 一级指标 二级指标 三级指标 技术影响力 创新水平 知识产权、技术专利数量 研发能力 研发投入 综合性能 产品性能、兼容性、易用性 市场影响力 市场综合能力 用户规模、市场营收 行业覆盖能力 各行业覆盖情况、典型案例 行业荣誉 行业荣誉、奖项 来源：中国信息通信研究院 实时云渲染技术与产业发展研究报告（2023年）43 4、象限评估结果及分析 入选实时云渲染领导力象限（IaaS 层）的共有 7 家企业，处于领导力象限的企业在实时云渲染赛道发展强劲，云渲染领域的技术迭代速度很快，这些企业持续重视前沿技术的创新，在行业中有很明确的定位，占据了实时云渲染细分市场的主导地位，除传统云游戏之外，他们通过部署大量的计算节点服务众多不同行业，积累了大量的客户资源。在激烈的市场环境中，他们也具备灵活的策略，建立与其他技术提供商、行业领导者和研究机构的合作伙伴关系，共同推动技术和市场的发展。来源：中国信息通信研究院 图 8 实时云渲染领导力象限图（IaaS层）入选实时云渲染领导力象限（PaaS 层）的共有 9 家企业，随着实时云渲染行业技术、体验效果、网络建设等方面也越来越成熟，处于领导力象限的企业都开始探索新的交互模式和应用场景。从技实时云渲染技术与产业发展研究报告（2023年）44 术角度看，他们在技术研发层面投入大量精力，组建了庞大的研发团队，并积极参与相关行业标准的制定，积累了丰富的专利成果，面向不同客户提供针对性解决方案。在 PaaS 平台这个赛道上虽然竞争激烈，但也代表实时云渲染行业的繁荣发展。这些企业的不断耕耘，给行业提供丰富的经验参考，为行业进步夯实了基础。来源：中国信息通信研究院 图 9 实时云渲染领导力象限图（PaaS层）实时云渲染领导力象限（应用层）的共有 9 家企业，处于领导力象限的各家企业凭借先进的技术实力和对市场需求的敏锐洞察，成功打造了一系列在实时云渲染应用领域值得借鉴的产品和服务，展现出了很好地前瞻性和创新力。在教育、工业、医疗、文旅、金融、游戏、影视等行业的深耕为产业发展带来了正向的效果。现阶段，实时云渲染的应用产品不断向着元宇宙形态靠拢，象限中的企业倾向于转向云原生的内容开发平台及工具的打造，另外 AIGC 技术的发展将进一步推动实时云渲染技术在不同行业领域的普及。因实时云渲染技术与产业发展研究报告（2023年）45 此，未来将有更多的企业进入到这个赛道中，为实时云渲染行业注入活力。来源：中国信息通信研究院 图 10 实时云渲染领导力象限图（应用层）五、发展趋势（一）云渲染服务从谋求单点技术的“极致”，向多元化、专业化、场景化综合生态发展（一）云渲染服务从谋求单点技术的“极致”，向多元化、专业化、场景化综合生态发展 XR 应用的崛起与应用需要实时渲染大量复杂场景和物体的能力，数字人、元宇宙等前沿应用的推广，需要渲染程序提供更高质量的交互体验，AIGC 逐渐从技术探索到工程化应用落地，科学技术的发展进一步推动实时云渲染快速适应市场和复杂的产业生态。随着科技的快速进步以及应用场景的不断拓展，实时云渲染服务逐渐呈现多元化、专业化的发展趋势。云渲染服务将根据不同用户的应用场景、显示设备和互动方式等提供高度定制化的解决方案，渲染算法实时云渲染技术与产业发展研究报告（2023年）46 和云资源将动态调配，以满足个性化定制需求。从传统的 CPU 渲染到如今的 GPU 云渲染、边缘计算渲染、自适应渲染、多 GPU 协同渲染等，渲染服务已经具备了更高的效率和更广泛的应用场景。同时，自适应渲染服务的出现也为用户提供了更加智能化和个性化的解决方案。多样化的渲染服务不仅提高了工作效率和质量，还为不同领域的用户提供了更多的选择和灵活性。GPU 云渲染：GPU 云渲染是一种在云端使用高性能图形处理器GPU 进行渲染的服务。这种服务通常用于大规模的视觉效果、动画和虚拟现实项目，因为它可以显著提高渲染速度和效率。GPU 云渲染服务提供商通常提供各种配置的计算资源，用户可以根据自己的需求选择合适的实例。此外，许多服务还提供了 API 和 SDK，以便开发人员可以在自己的应用程序中集成 GPU 加速渲染功能。边缘计算渲染：边缘计算渲染是一种将渲染任务分配给靠近数据源的边缘设备进行处理的服务。这种方法旨在减少网络延迟和带宽需求，从而提高实时渲染的性能。例如，在虚拟现实或增强现实应用中，边缘计算可以将渲染任务分配给附近的移动设备或传感器，以实现更低的延迟和更高的响应速度。自适应渲染：自适应渲染服务通常使用机器学习和人工智能技术来实现自动化决策。这些技术可以分析大量的数据和图像样本，学习如何识别和优化不同的渲染参数和设置。通过这种方式，自适应渲染服务可以为客户提供更高效、更准确的渲染解决方案。多 GPU 协同渲染：多 GPU 协同渲染是指通过调度多 GPU 资源实时云渲染技术与产业发展研究报告（2023年）47 来协同进行渲染的渲染技术，多个图形处理器（GPU）共同参与一个或多个渲染任务，其中多个 GPU 之间使用高带宽的有线/无线局域网连接，主控程序在向子 GPU 下发和收集子绘制任务时能满足低延时的特性，能够降低渲染应用的总网络延时。多 GPU 协同渲染能够将多个 GPU 的算力进行叠加，从而提高渲染效率，提升渲染质量，可面向游戏、VR、AR 等行业，数字孪生、智慧城市等场景提供渲染服务，并使元宇宙下的虚拟世界在商业化上成为可能。多 GPU 协同渲染通常分为硬件实现和软件实现。硬件实现方案使用特定的硬件，如 AMD 公司推出的 CrossFire 以及 NVIDIA 公司推出的 NVLink，将多块 GPU 连接在一起并通过特定配置和优化，来作为一个共同的计算单元处理渲染任务。这种情况下常用的渲染方式有（1）交替帧渲染：划分帧序列，第 i 1 帧分发给 GPU1 渲染，第 i 2 帧交给 GPU2 渲染，以此类推；（2）分帧渲染：将单一帧的不同区域分发给对应的 GPU 来渲染。基于软件的实现需要实现额外的线程管理和任务调度机制，显式地拆解渲染任务为多个子任务线程，每个子线程分别绑定到不同的 GPU 上，独立地进行渲染，并由主线程进行渲染结果的合并。一些渲染应用程序接口（如DirectX 12 和 Vulkan）提供了显式多 GPU 渲染的支持，可以在更底层的层面直接管理多个 GPU，并分配对应的渲染任务。蔚领时代积极探索 XR 内容生产方式，以云游戏行业以及云渲染行业的深度积累作为基础，攻关“多 GPU 协同渲染”核心技术，融合影视与游戏的工业化生产管线，打造适合未来的实时互动作品，实时云渲染技术与产业发展研究报告（2023年）48 春草传由此诞生。春草传通过蔚领时代数据中心的多 GPU协同计算能力进行渲染，可以从头到尾呈现 8K 画面、120Hz 刷新率、杜比环绕音的视听效果。在故事情节展现上无论是最后的“灯塔号”游船，还是整个“蚁城”，这些上亿级别面数的模型都能流畅运行，并通过推流将画面实时传送到用户的任何显示设备上，将春草传最高品质的一面展现出来。（二）元宇宙、数字孪生、AIGC 等前沿应用为实时云渲染产业发展提供强大驱动力（二）元宇宙、数字孪生、AIGC 等前沿应用为实时云渲染产业发展提供强大驱动力 元宇宙作为实时云渲染的典型应用场景，以新一代信息技术集合为基础，以构建虚拟世界为核心，以“共创、共享、共治”为主要特征，是数字经济与实体经济融合的高级形态，有望通过虚实互促引领下一代互联网发展，加速制造业高端化、智能化、绿色化升级，支撑建设现代化产业体系。当前元宇宙的发展热点主要聚焦于数字生活及工业场景。在数字生活领域，多家公司推出消费级 VR 头显设备、AR 头显设备、AR 眼镜等，将市场下沉至大众用户，进一步满足数智文旅沉浸式体验空间、元宇宙游戏、文旅元宇宙等强沉浸场景中用户对交互体验的需求。元宇宙在工业场景中的应用主要以解决问题、实现资源的更高效配置为目标导向，是新型工业化建设的重要发力点之一。当前多地推出工业元宇宙发展规划，加快打造工业数字孪生生态，培育“工业元宇宙 产线”、“工业元宇宙 工厂”、“工业元宇宙 园区”等多场景应用，不断探索工业元宇宙创新应用的新模式。发展虚实实时云渲染技术与产业发展研究报告（2023年）49 融合互促的工业元宇宙，将进一步加速三维交互的工业元宇宙体系的构建，加速制造业的智能化、数字化升级转型。元宇宙在沉浸交互的生活消费场景、虚实融合的公共服务场景、支撑智慧安全的应急保障场景及三维交互的工业场景等多种领域的应用推广，将进一步推动实时云渲染产业规模的增长扩大，实时云渲染相关技术的突破也将进一步加速元宇宙在不同领域的应用推广。数字孪生作为一种将现实世界与虚拟世界连接的技术，通过创建物理实体的虚拟副本，为实时云渲染市场的发展提供了新的机遇和动力。数字孪生技术在各行各业（如制造业、建筑业）的广泛应用将为实时云渲染市场带来更多跨行业合作的机会。随着 ChatGPT 的爆火，AI 再次受到全球的重点关注。从底层的大模型到上层的各种“AI ”应用，AIGC 已成为行业升级的新风口，越来越多的科技公司开始深入研究 AIGC，探索将 AI 和大模型技术与自身应用场景相结合，利用 AIGC 打造新的增长曲线。如将虚拟数字人与 AI 相结合，通过融合新一代 AI 强大的逻辑和生成能力，提升虚拟数字人的理解能力和响应准确度，满足用户多方面的需求。在 AI 的赋能加持下，虚拟数字人将逐渐“智能进化”，并能根据教育、金融、电商、物流、社交等不同场景的需求，化身成虚拟教师、虚拟客服、虚拟主播、虚拟好友等多种身份角色，为用户提供更加个性化的沟通服务。例如在各种虚拟活动场景中，新一代的虚拟数字人能够自然应对用户咨询，随时随地为用户提供指引；在社交娱乐场景中，新一代的虚拟数字人可以为用户提供 24 小时的陪伴，用实时云渲染技术与产业发展研究报告（2023年）50 户还能够定制自己专属的个性化数字人，创造一个时刻在线的贴心好友；在虚拟直播场景，新一代的虚拟数字人不仅能够全天候直播卖货，还能智能生成话术、回复问题、弹幕互动，帮助企业实现服务与营销的数智化转型。高精度的虚拟数字人画面渲染需要大量的算力支持，数字人与AI 结合后，自生成内容对算力的依赖进一步提高。实时云渲染通过海量的云端计算资源，能够解决 AI 数字人对终端的性能束缚，满足AI 数字人多场景的实时应用，AIGC 的快速发展将为实时云渲染提供新的发展机遇。应用场景的拓展为实时云渲染市场的发展提供了新的机遇和挑战。实时云渲染平台需要不断提升自身的技术和服务水平，为用户提供更加优质的体验。同时，开发者需要不断创新，为用户带来更加丰富、多样化的内容。只有在多方的共同努力下，实时云渲染市场才能更加和谐、健康、绿色的发展。（三）人工智能技术推动实时云渲染更加智能化、自动化、高效化（三）人工智能技术推动实时云渲染更加智能化、自动化、高效化 人工智能已成为全球最活跃的科技创新领域，并以空前的广度和深度推动着社会发展，加速着产业转型优化。以深度学习为主导路线的人工智能技术不断升级优化，逐步向更多的行业领域渗透。人工智能在云渲染领域的应用可以使渲染过程更加高效，并能提供更好的视觉质量和用户体验。主要包括以下方面：基于深度学习的图像超分辨率技术：通过训练深度神经网络模实时云渲染技术与产业发展研究报告（2023年）51 型来将低分辨率图像转换成高分辨率图像，从而提高图像的质量。这种技术可以应用于游戏渲染中，使得低分辨率的纹理或者模型在渲染过程中被动态地提升为高分辨率，从而提供更加细腻的视觉效果。基于机器学习的渲染自动优化技术：利用机器学习算法对渲染器进行训练和优化，从而在渲染过程中减少冗余计算，提高渲染速度和效率。这种技术可以通过学习过往渲染任务的数据和结果，自动寻找合适的渲染参数和优化策略，从而达到更高的渲染性能。利用强化学习进行渲染策略的动态调整和优化：通过强化学习算法，在渲染过程中智能地调整渲染策略，优化渲染结果。例如，可以通过模拟渲染器的行为并根据预设的奖励函数进行训练，使其能够根据当前的渲染情况和任务需求，动态地选择合适的渲染参数和策略，从而达到更好的渲染效果和性能。利用生成对抗网络进行内容生成和编辑：生成对抗网络（GAN）可以用于生成逼真的图像和内容，并且可以用于对已有图像进行编辑和增强。在渲染中，可以利用 GAN 生成新的纹理、模型或者场景元素，从而丰富渲染结果。此外，GAN 也可以用于对渲染结果进行编辑，例如改变光照、材质等属性，从而快速得到满足需求的渲染效果。结合 NeRF、DIBR 和 DLSS 等技术，实现更高质量、更真实、更高效的图像渲染。NeRF（Neural Radiance Fields）利用神经网络模型建模场景中实时云渲染技术与产业发展研究报告（2023年）52 的辐射场，以实现高度逼真的三维重建和渲染。通过深度学习，NeRF 可以从大量的图像和相机视角生成场景的立体形状和纹理。这种技术可以提供更具细节和真实感的渲染效果。人工智能在 NeRF中的应用在于通过训练神经网络模型来捕捉场景的辐射属性，使得渲染能够以更高质量和更快的速度进行。DIBR（Depth Image-Based Rendering）是一种基于深度图像的渲染技术，它通过将深度信息与纹理信息相结合，实现对虚拟场景的渲染。传统的 DIBR 方法通常使用手动定义的规则来合成深度图像，而人工智能可以通过机器学习方法来从现有的图像数据中自动学习深度图像合成策略。利用深度学习技术，可以使得 DIBR 技术更加精确和高效，并在渲染中产生更真实的景深效果。DLSS（Deep Learning Super Sampling）是一种基于深度学习的超采样技术，在渲染中可以提供较高质量的图像放大和反锯齿效果。通过训练神经网络模型，DLSS 可以从低分辨率图像中恢复出高分辨率图像的细节，从而提供更清晰和逼真的图像。此技术可以大幅优化渲染性能，减少计算资源的消耗，并在保持画质的同时提高渲染速度。通过深度学习和机器学习的方法，可以自动学习场景的属性、合成深度图像，并通过超采样实现更高分辨率的渲染结果。人工智能技术的应用将推动渲染技术的进一步发展，为用户提供更优质的视觉体验。实时云渲染技术与产业发展研究报告（2023年）53 六、行业应用与典型案例（一）教育行业（一）教育行业 实时云渲染与教育行业结合逐渐紧密，中国教育科学研究院印发的中国智慧教育蓝皮书（2022）提到：“创新教育教学场景，促进人技融合，培育跨年级、跨班级、跨学科、跨时空的学习共同体，实现规模化教育与个性化培养的有机结合”。实时云渲染在教育行业中的应用主要体现在虚拟实验、智慧课堂、在线教育等方面，为学生和教师提供更加沉浸式、互动性强的学习体验。实时云渲染技术可以将数字孪生实训平台中的教学内容实时渲染到虚拟空间中，此外，实时渲染云平台整合第三方丰富成熟的课程内容以及各种VR/AR 终端，打造面向 5G XR 的智慧教育整体解决方案，为教育行业提供更加优质的教育内容，有力推动教育变革和创新。1、应用案例：国开在线教育元宇宙平台 案例介绍：国家开放大学前身是中央广播电视大学，是面向全国开展开放教育的新型高等学校。在推广相关设计类课程时遇到很多学生终端性能不满足，搭建相关环境流程繁琐等问题。北京庭宇科技有限公司与客户通过多轮产品沟通和技术测试，通过将课程学习统一上云，为学员统一提供云渲染桌面的形式解决了终端环境和终端算力不足的问题，大大降低了课程学生学习相关课程的启动门槛。资源统一上云管理，也提高了整体的维护管理效率。解决方案：庭宇科技 2023 年与国开在线（国家开放大学全资校办平台）共建元宇宙云教育平台，以科技赋能、算力驱动，全方位实时云渲染技术与产业发展研究报告（2023年）54 推动教育变革，通过 VDI 云桌面为云渲染底座，放置国开在线丰富的课程资源，两大服务商联合打造立体云教育基地，实现云与端双边融合，远程接入仿真实训，培养专业技能人才。平台服务于 45 个省级分部，可统一连接使用，共享多维课程资源。此外，云教育架构充分利用云计算服务的资源复用、灵活拓展、海量并发优势，任意地域学生只需统一完成认证。来源：北京庭宇科技有限公司 图 11 国开在线官方网站展示庭宇木鹰云教育 应用成效：平台允许学生利用课余、碎片时间随时随地接入学习；打破课程资源区域不平衡，实现全国漫游共享；立足于教育变革，课程资源服务化；不受运行环境限制，兼容老旧课程。（二）工业行业（二）工业行业 工业虚拟现实将通过在虚拟与现实空间的联动协作，来赋能工业各个环节与场景，其运行离不开实时渲染。单一的、本地的渲染计算资源与渲染方案难以满足大型 3D 软件的实时交互与应用，而通过将软件放在云端，利用云端强大渲染算力，则能保障用户即使实时云渲染技术与产业发展研究报告（2023年）55 只在轻量化设备的支撑下，也能获得超大规模，超高复杂度，高度逼真的实时交互体验，助力经济社会深度数字化转型。1、应用案例：工业虚拟现实软件实时云渲染项目 案例介绍：该案例客户是一家从事虚拟现实功能化开发，为设计师提供专业的虚拟现实解决方案的企业。企业核心产品是一款构建虚拟场景的软件，软件对于用户的显卡、存储空间等均有较高要求，因此在产品推广/试用阶段，用户终端性能极大程度的影响了市场推广效果。在此次合作中，海马云基于自身成熟实时云渲染平台，向客户提供实时云渲染服务，用户无需高昂硬件配置，也无需下载安装，点击就可以通过 H5/微端的方式迅速体验到该企业产品，大幅降低用户终端门槛，提高获客效率。解决方案：海马云为该企业提供全栈实时云渲染服务。在基础设施层，在全国超 30 个省份和地区，以及美国、日本、欧洲、东南亚等地区和国家自主建设 100G 全光节点，云端拥有超大规模 GPU 集群，支持分布式渲染集群，形成全球实时云渲染基础设施覆盖。在平台层，以自研的面向超高带宽和超低延迟的实时传输系统、基于容器的异构图形虚拟化技术、自研百万级容器实时调度管理系统、大容量分布式存储系统等多项前沿技术，实现超高画质超低延迟的实时云渲染体验。企业用户无需高昂硬件配置，也不用下载近10G 的安装包，就能以最低 60ms 的端到端传输延迟，最高4k/8k/144FPS 超高分辨率，体验软件全部功能。实时云渲染技术与产业发展研究报告（2023年）56 应用成效：海马云帮助该企业有效解决了大型软件终端存储和配置上的压力，同时降低了市场推广的成本，提高推广获客效率。通过此次合作，企业工具使用率提升约 20%，在促进用户体验/试用环节发挥显著效能。（三）医疗行业（三）医疗行业 近些年来实时云渲染技术正在加速渗透医疗行业，凭借其高拟真和沉浸感、可重复利用、0 风险操作等特性，拓展了医学教育和培训手段并降低人力物力资源消耗。借助全景直播能力实现远程会诊，打破时间地域、感染风险、医疗条件等各方面限制，极大缓解了我国医疗资源分配不均问题，并以其丰富的可视化效果，在医疗图像处理和模型设计仿真领域中占据一席之地。这些创新应用正逐步显现出云渲染技术不可替代的优势和价值：降低医疗硬件要求和成本，提高医疗服务质量和效率，促进医疗数据共享和分析，为医疗行业带来新的创新和机遇，有助于提升我国医疗水平和人民健康水平。1、应用案例：火山引擎&英特尔 VR医疗教育培训项目 案例介绍：火山引擎携手英特尔，助力北京某三甲医院打造高效能 VR 医疗培训系统，拓展云渲染应用场景与 5G 行业解决方案。公众急救培训：传统方式是由医疗机构定期组织公众、企业培训，受到场地、人员、设备数量等限制。而通过云渲染技术、AI 和云计算可提高培训场景真实性，实现近 8K 电影级的画面效果显示；实时云渲染技术与产业发展研究报告（2023年）57 通过 VR 的交互互动提高受训者的参与度，提高公众对急救知识和流程的认知度，避免如对 AED 使用不熟悉导致的人员死亡。医疗现场培训：急诊科室培训例如留观病人的查房问诊等，目前主要方式是学生跟随专家进行现场观摩学习，这种方式受限于时间、感染风险等条件，无法有效且持续进行。并且对于突发状况或特殊病例，专家及学生很难及时到场指导或学习。借助实时云渲染技术，让实景培训或指导打破时空限制，实现录制视频无法达到的身临其境和自由视角效果。解决方案：来源：北京火山引擎科技有限公司 图 12 火山引擎 VR 医疗教育培训技术方案框架图 公众急救培训：引入火山引擎边缘计算节点，构建基于边缘云的边缘渲染平台，利用高性能 GPU、虚拟化技术、硬件加速技术实时管理和渲染 VR教学场景；采用 BVC 编解码器融合英特尔高级矢量扩展 AVX-512指令集，实现超清高质视频的实时快速编解码；利用实时音视频veRTC 实现高品质低延时的传输。实时云渲染技术与产业发展研究报告（2023年）58 客户端基于 PICO 头显完成解码与渲染，呈现双目高清画面；采集头显位姿和手柄数据并实时上传，保证用户头动与操作及时响应，给予用户身临其境的感受。整体实现双目 2K、72FPS 的高清画面显示，能清晰显示急救场景细节，操作手感流畅无卡顿，头动延时小于 20 毫秒，端到端延时小于 100 毫秒。本套方案也适用于云VR 游戏串流。医疗现场培训：采集端使用 360 度全景相机，将生成的 8K 全景视频流通过 5G专线上传至火山引擎边缘云计算渲染平台后，完成全景视频转码和分发，实现高画质低延时的 8K 全景直播体验。使用了基于变换视角的自研 VR 推流方案，能在满足用户观看 8K 全景视频的画质要求下，控制下行视频流在 10Mbps 以内，满足头动延时小于 20 毫秒，使用户能在普通家庭 Wi-Fi 下畅享 VR 视频，极大降低 VR 设备使用门槛，也极大节省服务侧流量成本。客户端基于 PICO 头显完成交付，也提供 SDK 满足多端介入需求。整体效果实现院方设想场景，画面流畅无卡顿，显示效果清晰，满足院方看清 2 米外生命体征仪器显示数字的需求。本套方案也支持点播、虚拟场景实时云渲染等多种场景，满足不同需求。应用成效：VR 医疗急救培训应用已在该北京三甲医院医学应急教育培训中心部署，开展了大量医疗培训实践，大幅提升培训效能，且每次使用的边际成本几乎仅为 5G 流量费，有效帮助压降培训成本，提升经济效益。而实时查房系统可以让专家对一线医生进行远实时云渲染技术与产业发展研究报告（2023年）59 程指导，和病人实时交流，为远程智慧医疗带来更多可能。对国家一直倡导的区域医联体建设、强化基层诊疗能力，将产生深远影响。（四）文旅行业（四）文旅行业 文旅行业与实时云渲染技术相结合，其中一个典型场景就是文旅元宇宙。近年来，文旅景区数字化转型升级是已成为文旅行业的潮流趋势，各文旅景区结合自身资源特色和属性，打破传统旅游“时”与“空”的局限，构建与其文化特色相匹配的沉浸式场景空间和体验业态，通过线上线下融合，让用户获得更有沉浸感、科技感、补偿感的体验。在文旅内容创作阶段，通过云上高性能的渲染算力、海量存储能力和领先的空间搭建云渲染引擎，开发者可以专注于业务需求的满足，避免本地渲染算力约束带来的内容品质下降。此外，在一些文旅细分场景中，依托云上渲染能力可以打造不一样的创新业务，例如数字藏品的跨链分享，做到和真实世界一样，让用户的数字收藏可以在不同的元宇宙空间和场景中流动。一次制作可以在不同的元宇宙空间中被欣赏和体验，大幅减少了投入成本，扩大了用户群。1、应用案例：东方明珠云美术馆项目 案例介绍：东方明珠云美术馆项目，是围绕东方明珠云美术馆研发的高画质、支持“数字人”百人同屏互动的应用项目，是上海市十大元宇宙应用场景标杆项目、揭榜挂帅项目之一。蔚领时代利用自身的实时云渲染技术，为“云美术馆”的海量艺术展品进行赋能。用户只需要通过手机，快速访问小程序登录，实时云渲染技术与产业发展研究报告（2023年）60 创建自己的数字人“虚拟化身”，便可进入元宇宙空间沉浸式观展。解决方案：通过本解决方案，实现用户无需下载庞大的客户端，用低端手机也能跑 3A 游戏级的线上元宇宙场景。用户创建一次高品质数字人“虚拟化身”，可在多个活动多次重复使用，应用中随时进行个性化装扮，装扮数据存储在云端，随时随地可调用。并且依据项目的目标流量人数，支持至少上百人同屏，实时聊天、发布表情、动作驱动时，也能拥有高画质、高品质、流畅的交互体验。此外，灵活契合营销需求，用户可通过手机、VR/AR 眼镜、PC、平板等设备，在低成本本地算力的情况下进入宏大的元宇宙世界。项目采用以下技术方案：数字人工具平台：基于实时云渲染能力构建数字人工具平台，提供多种核心服务，以支持数字人各种商业应用和终端实现。来源：北京蔚领时代科技有限公司 图 13 数字人工具平台架构图 实时云渲染技术与产业发展研究报告（2023年）61 数字人生产管线：通过蔚领自研的掌握核心知识产权的数字人生成管线，提供数字人服务。包括：WAvatar 虚拟化身云服务、WDNA 微表情编辑系统、MTP 模型自动化拓扑系统、WFace 面捕驱动系统、WLive Link 动捕标准化数据接入结构。支持多种照片 AI 生成、光场扫描、DNA 混合、人工雕刻等技术手段进行模型制作，拥有自动化模型拓扑管线，从立项到上线投入的成本不到传统管线的一半。自研发尖端建模组件、结合光场扫描技术、表情身体智能绑定技术，以及表情迁移技术，捕捉真人日常表情、口型面部肌肉动作等细微变化，使其更生动、个性化且更具可互动性。同时支持布料实时模拟与离线模拟，兼顾仿真与效率。云端实时渲染：自研的“方舟”架构，利用多 GPU 协同渲染，可支持通过云端实现实时渲染，为高品质数字人在沉浸式地元宇宙场景中，满足用户消费的个性化需求提供了技术支撑。元宇宙空间搭建技术：自研的 DataAsset 数据结构，实现虚拟空间对象关系的标准化管理，提供快速搭建虚拟空间的整套管线系统。应用成效：本项目满足了用户低门槛、差异化的参观需求，助力科技赋能推动文化发展，传承历史，增强文化自信的目标。通过实时云渲染技术在数字人及应用场景的支持，应用能够以小程序为载体扩大项目影响力。利用公域流量，将有效激发用户兴趣，强化沉浸体验的元宇宙参观之旅。项目与线下展览协同，每半年更换一次主题，包括用户数字人实时云渲染技术与产业发展研究报告（2023年）62 的装扮和场景等，让用户可以定期获得不同的体验。通过促进科技与艺术融合，为文化消费构筑新入口与新场景。2、应用案例：嵩山主题文旅元宇宙 案例介绍：河南登封文旅集团联合阿里元境发布首个嵩山主题文旅元宇宙产品，围绕嵩山打造游戏化互动空间和数字藏品，结合线下景点虚实联动，构建嵩山文化新场景和数字新品牌。这也是河南省登封市首次将当地文化旅游资源与元宇宙相结合，利用新科技打造文旅消费新场景，拉动当地旅游消费增长。解决方案：移动互联网发展了十多年后，流量逐渐枯竭的问题开始显现，整个数字营销领域都在寻求突破。而元宇宙在经过前期的“轰轰烈烈”后，已经沉淀出了真正符合实体经济需求的形态与解决方案。阿里元境与河南登封文旅集团、河南广电大象元的合作，将现实中的“人”用户、“货”线下权益、“场”景点资源映射到元宇宙中的“数字人”、“数字权益”、“数字 3D 空间”。通过对数字权益的运营，关联到线下真实的“货”来提升真实用户的忠诚度，将传统的一次性数字营销，通过元宇宙变成了可持续的营销活动。实时云渲染技术与产业发展研究报告（2023年）63 来源：元境生生（北京）科技有限公司 图 14 元境解决方案 元宇宙本身是具备生命力的，其中的各项元素，游戏化内容会随着市场、业务的发展持续更新与变化。此次活动中，用户既可以通过线下数字藏品直接扫码游览线下景点，用户线下打卡的景点，也会同步在线上数字藏品中点亮，真正做到虚实结合。应用成效：升级后的“人货场”关系，主打的是一种“win-win”双赢模式。用户在线上元宇宙的活动，即是一种线上娱乐、教育形式，也能带来线下的权益。而作为此次合作中的 IP 授权方登封文旅，可以通过与元宇宙虚实结合的方式更好的做用户运营，相比较传统社群模式，元宇宙带来更多的用户粘性与更大的想象空间。同时，元宇宙也将成为当地文旅资源的数字化品牌，将登封的文旅资源展示在全世界面前，带来巨大的社会公益与文化传播价值。（五）金融行业（五）金融行业 近年来，数字技术所蕴藏的技术创新活力和应用革新潜力，正实时云渲染技术与产业发展研究报告（2023年）64 深度影响着金融行业的发展趋势，以实时云渲染为代表的数字技术不但对金融行业进行着业务流程的重塑，也为用户带来了全新的业务体验，数字空间与物理空间的深度融合，正在为金融行业带来新的发展机遇。从应用情况来看，国内金融机构主要围绕提升用户服务体验、强化服务环境建设、创新金融营销等方面开展数字化升级。1、应用案例：银行低延迟云渲染智能数字营销项目 案例介绍：在竞争日益激烈、新客拓展趋势放缓的市场环境下，银行业针对企业客户的金融服务手段、产品同质性日趋明显，银行要在竞争中站稳脚跟、赢得市场，需要跟上数字化变革发展的主旋律，依托数字力量不断拓展用户服务的深度和广度，增强客户服务的精度和准度。为达成低成本高效率触达客户、精细化深度化服务客户的目标，某银行个人金融业务与海马云云手机达成合作，以云手机提升业务营销效率，提高用户服务体验，构筑数字营销竞争力。解决方案：海马云将自身云手机能力与该银行智能营销系统进行深入集成整合，形成统一的协同平台。方案基于海马云实时云渲染能力，将该银行金融营销系统 AI 智能客服持续稳定运行在云端手机中，利用海马云云手机端云协同能力，通过低延时渲染方案，支持多用户实时操作云端营销系统，让多角色、多终端实现实时协作工作。同时利用海马云云手机实时音视频上下行功能，将云端应用的实时云渲染技术与产业发展研究报告（2023年）65 音视频画面高清低时延的实时渲染同步给本地客户端，实现集约运营人员和客户之间实时视频通话，帮助该银行提高信息处理能力，大幅提升客户服务和营销效率。面对金融类业务数据安全问题，海马云云手机采用云端独立部署，同时采用包括身份认证、数据加密、访问控制等多层次的安全策略，保护客户云端数据不落地、不外泄、不丢失。海马云云手机依托于海马云多年积累的底层基础设施与平台能力构建，拥有全国覆盖率最高的云化虚拟桌面服务节点，全栈式打通服务器、存储、网络、操作系统、云平台和应用组件，在海量云端分布式容器资源池及音视频编解码、网络传输等技术的加持下实现以云助端，即使身处复杂的网络环境下，也能以超越旗舰机的性能，助力该银行个人金融业务实现高清、低时延、稳定流畅的云手机使用体验。应用成效：通过此次合作，海马云云手机帮助某银行个人金融业务在有效降低运营成本的同时，增强客户服务的速度和精准度，用户触达成功率提升 200% ，用户月度有效沟通占比增加 100% ，以数字化力量助力该银行在激烈的竞争中加速市场占领的脚步。（六）游戏行业（六）游戏行业 云游戏是实时云渲染技术在游戏行业中最典型的应用形式。在云游戏中，游戏运算与渲染都在云服务器完成，将实时游戏画面编码并传输到玩家的客户端设备进行解码和显示。实时云渲染为云游戏行业提供高品质的游戏渲染画面，提高渲染效率、降低终端设备实时云渲染技术与产业发展研究报告（2023年）66 性能要求，实现跨终端的游戏体验，助力云游戏沉浸式体验新玩法。云计算、5G 网络与 AR/VR 技术的不断发展与普及，将会进一步推动云游戏的发展与广泛运用，实时云渲染技术也必将发挥更加重要的作用。实时云渲染使得云游戏成为现实，它将继续改变与影响整个游戏产业的未来。1、应用案例：云原神 案例介绍：云原神是开启云游戏商业模式新时代的一款现象级的游戏，是由蔚领时代和米哈游共同打磨的游戏产品。原神游戏发布之初，由于游戏的高清画质和庞大的包体，众多玩家无法在自己的个人设备上流畅地体验最高清画质的游戏。通过蔚领提供的实时音视频渲染和低延迟串流技术，即使中低端的手机也可以体验到高端 PC 机的精品游戏画质，极大地满足了玩家对游戏的体验诉求。解决方案：作为国内领先且同时支持 X86 架构及 ARM 架构的云游戏服务平台，蔚领云游戏服务平台在两个架构中同时支持多种方案。在 X86 架构中不仅支持容器化多开方案，也支持桌面模式的一对一方案，帮助客户实现成本降低及体验升级；在 ARM 架构中，平台同样兼顾 Android 板卡方案和 ARM Server 方案，为客户提供最适合的技术方案模式。实时云渲染技术与产业发展研究报告（2023年）67 来源：北京蔚领时代科技有限公司 图 15 蔚领云游戏服务平台 蔚领的解决方案共分为四个部分：基础层服务：蔚领云游戏服务平台采用定制的高性能 X86 服务器集群以及高性能 ARM 服务器集群，结合云厂商优质的云服务资源，为用户提供最底层的服务保障。平台层服务：蔚领自研的云游戏容器技术，配合 PaaS 平台的全链路功能覆盖，为用户提供计费统计、数据统计、分布式调度等一站式的标准化平台服务。业务层接入：蔚领云游戏服务平台为用户提供全终端 SDK 接入，包括但不限于 Android SDK、IOS SDK、JS SDK 等终端形态，降低用户本身研发投入的同时，实现平台功能的快速对接。业务场景层：平台可帮助用户实现云游戏场景之外，也可支持用户实现云 VR/AR、云应用、云渲染等多重场景，全面赋能数字化行业发展。实时云渲染技术与产业发展研究报告（2023年）68 应用成效：云原神上线后所达成的成果以及表现已经成为云游戏行业里程碑产品，树立了云游戏产业的标杆。2022 年 1 月 10 日云原神IOS 平台公测正式开启，成为全球首款在 App Store 上架的云游戏，上线第二日即冲上免费榜第 3 名。2、应用案例：战舰世界云游戏版 案例介绍：战舰世界（World of Warships）是由战争游戏研发公司 Wargaming 出品、360 在中国大陆运营的海战题材网游巨制，超清 3D 建模高度还原战舰细节，为玩家带来超强的真实感沉浸感。战舰世界原本专注于运行在 Windows 平台，依托于阿里元境的实时云渲染技术能力，战舰世界云游戏打破了固有的运行方式，不再依赖于本地设备的性能条件和平台能力，而是将运行计算和渲染全部置于云端，让云端的海量算力充分发挥出价值，本地设备将仅作为接收音视频和操控的设备。解决方案：高品质游戏内容的呈现往往离不开设备强大的渲染能力做支撑，而部分玩家受制于电脑的性能，流畅地运行与画面效果全开不能兼得，对体验的提升带来了很大的挑战。战舰世界云游戏通过云端算力保障高品质的渲染效果，通过高效的数据传输保障流畅的体验。元境凭借扎实的实时云渲染基础设施，为海量云端算力提供保障，在算力保障之外，依托于全国可覆盖的 2800 多个边缘节点、31个省运营商全覆盖，实现玩家终端最后 10 公里的触达。元境也充分考虑到当下的市场需求和网络现状，对 4G 网络、5G 网络和 Wi-Fi实时云渲染技术与产业发展研究报告（2023年）69 网络进行了带宽侦测、卡顿识别、码率自适应、帧率自适应等优化，通过分区部署、多运营商网关接入以及端边云一体化等手段实现全网、全域的覆盖，使云游戏的体验始终处于特定网络条件下的较高水位。让玩家可以在更多不同的网络环境下，随时随地享受畅爽的云游戏体验。来源：元境生生（北京）科技有限公司 图 16 元境解决方案 应用成效：通过对云上图形算力的充分运用，大幅降低了内容运行对硬件配置的要求。并以浏览器的形式提供服务给最终用户，最大程度的做到了跨端分发。借助流服务自身的特性，用户运行应用省去了大量的下载与安装时间，并可以通过各种 APP 进行分发与传播，为内容的运营方拓展用户群体提供了极大的便利。3、应用案例：咪咕快游电信级云游戏商用平台 案例介绍：中国移动咪咕公司充分发挥 5G 算力网络的技术优实时云渲染技术与产业发展研究报告（2023年）70 势，利用实时云渲染技术将游戏的渲染计算任务迁移到云端，打造了全国首个电信级云游戏商用平台咪咕快游。在行业内构建起跨“移动端、TV 端、PC 端”全产品矩阵，实现用户云游戏体验全场景覆盖。满足“超高清画质、低时延、跨终端即点畅玩”等技术特性。同时平台结合“游戏 直播”场景创新需求，支持玩家与好友实时语音互动，更有游戏直播、攻略视频、云对战、云助战、云观战等云交互服务，为玩家带来一体化的线上游戏娱乐新体验。解决方案：实时云渲染在云游戏行业中主要用于云端服务器游戏画面渲染。它将游戏场景渲染成视频流，在视频流编码阶段，将渲染的视频流进行编码压缩，以便更高效地传输给终端用户。根据游戏画面的复杂度可采用不同的渲染架构，即点对点实时云渲染和分布式实时云渲染。针对画面精度要求不太高、低复杂度的云游戏可以采用点对点实时云渲染，单个任务在云端服务器和终端侧点对点结合智能编解码、串流技术实现渲染实时输出。针对高精度高算力低时延的大场景云游戏，通过对分布式计算框架、渲染引擎和引擎配套的物理引擎、动画引擎、布料仿真引擎进行分布式改造，结合协同渲染技术和智能算力调度技术，实现单帧画面的块级拆分，把原本一台机器渲染的画面任务分摊到多台，从而实现大场景的分布式实时渲染。实时云渲染技术与产业发展研究报告（2023年）71 来源：中国移动咪咕公司 图 17 分布式实时云渲染流程 云游戏的实时渲染需要强大的算力支持，咪咕快游通过构建ARM、X86、GPU 异构算力，并采用算力性能升级、算力下沉和边缘节点扩容等技术手段，有效地优化了算力分布和扩展了算力节点覆盖，以确保算力节点与业务发展规模相匹配。应用成效：凭借中国移动大网优势，咪咕建成了覆盖全国范围、技术领先且品质优良的云游戏算力网络，能够支持手游和主机游戏的实时云渲染能力。咪咕快游云游戏平台可为用户提供 4K 超高清画质内容传输，保证 5G 网络下的最低时延为 20 毫秒，以及移动端60 帧高帧率画面，确保用户享受高质量的游戏体验。截至 2023 年 6月，全场景有效月活用户数达到 1.2 亿，并拥有 2200 款在线畅玩精品正版云游戏内容，可满足用户全品类全方位内容需求。实时云渲染技术与产业发展研究报告（2023年）72 4、应用案例：广汽埃安云游戏定制合作项目 案例介绍：“移动云”是中国移动基于自研的先进技术打造的安全智慧云品牌，充分发挥“央企保障、安全智慧、算网一体、属地服务”优势，为客户提供行业领先的云计算、大数据、人工智能产品。项目整体交付端到端的 5G 云游戏车载能力，包括云游戏算力、云游戏 PaaS 平台、5G 物联网卡、为广汽埃安定制的客户端、云游戏游戏手柄。车主接入云游戏时，云游戏平台根据车主的实时位置，向车主分配距离最近的边缘云游戏算力，端到端网络延迟最低达到20ms。云游戏内容具有较强的操作性，可满足车主在等人、驻车休息、长途行车时后座乘客娱乐等多场景需求。来源：中移（苏州）软件技术有限公司 图 18 车载云游戏方案 解决方案：安全性高、占用率低：云游戏包体全部运行在云端，产品本身有安全检测，车企只需要内置一次，即可达到接入海量游戏的效果，不占用存储、运行资源。实时云渲染技术与产业发展研究报告（2023年）73 千车千面精细化定制：可根据不同车企用户画像及品牌定位，定制 UI 界面风格及游戏内容，满足不同车企个性化定制需求。应用成效：助力智能电竞仓打造：车企客户无需花费巨额游戏版权费即可为用户提供 3A 大作云游戏服务，打造跨次元梦想电竞仓。增值收入提升：丰富的内容及良好的操控体验吸引用户通过车企购买会员权益、游戏手柄、流量包等，助力车企增值收入提升。5、应用案例：达龙云 VR 案例介绍：达龙云 VR 为了解决用户 VR 一体设备算力不够无法流畅运行大型 VR 优质内容的问题，借助云端算力让用户体验更流畅高画质的内容，减少卡顿掉帧带来的眩晕感，提升 VR 体验。随着元宇宙的兴起，元宇宙是未来虚拟世界和现实社会交互的重要平台，是数字经济新的表现形态，潜力巨大。为了呈现更加真实的元宇宙，各种元应用必然在云端运行，而 VR 作为进入元宇宙的硬件之一，达龙云 VR 可以为元宇宙的发展提供基础设施。通过将内容、用户和服务整合到云端，可以更好地实现跨平台、跨设备的元宇宙体验，使用户可以在不同的虚拟现实环境中自由流动。解决方案：实时云渲染技术与产业发展研究报告（2023年）74 来源：上海达珑信息科技有限公司 图 19 达龙云解决方案 达龙云 VR 将虚拟现实技术与自研 DLXR Streaming RTC 技术、算力切分、云渲染、空间计算以及终端交互等关键技术相结合，旨在为用户提供高质量、更流畅以及更具交互性的 VR 服务。对于性能有限的 VR 一体机来说，渲染任务交由云端 GPU 集群处理。这意味着终端设备无需承担复杂的渲染计算任务，减轻终端设备负担的同时让终端专注于更有效的交互功能，例如实时运动捕捉、手势识别和空间定位等。画质表现上通过将渲染任务从终端设备转移到云端，不仅能够提供更高质量的图像和高帧率的画面效果，还能减少丢帧卡顿带来的眩晕不适感，从而让更多的用户感受到虚拟现实技术的所带来的魅力。应用成效：达龙云 VR 目前已在 SideQuest、87VR、Pico 应用商店上线，硬件适配方面涵盖了当前主流的 Quest2、Pico neo3/4、实时云渲染技术与产业发展研究报告（2023年）75 HTC VIVE FOCUS3 在内的多款 VR 硬件。引入了中文梗博物馆、SpaceDraw等多款优质内容。随着云 VR 应用的推出，开拓了VR 应用场景的同时，提升了用户使用 VR 设备时的体验。（七）影视行业（七）影视行业 影视行业是实时云渲染的一个重要应用场景。传统的影视及动画制作使用的大量渲染资源给制片公司带来成本压力，并且渲染过程需要耗费大量时间，延长了制作周期。在新兴的互动影视及云演艺直播场景，传统的单机渲染或离线渲染无法满足根据用户的交互实时处理和呈现高品质影音效果的需求。实时云渲染在动画制作领域中的应用可以大大提高生产效率和降低成本，实现快速迭代设计、大场景分布式渲染、降本增效轻资产，对传统影视动画行业的发展有着非常积极的影响。在云演艺和直播场景中，实时云渲染技术可以针对舞台背景、特效、直播节目中的数字场景进行实时渲染，提升演出和直播效果，提高渲染速度和质量，减轻设备负担，未来应用前景广阔。1、应用案例：基于 5G 算力网络的分布式实时渲染元宇宙比特空间星际广场 案例介绍：星际广场是中国移动咪咕在 2022 卡塔尔世界杯足球赛期间推出的首款以世界杯为主题的云原生社交互动观赛平台，是基于 5G 算力网络的分布式实时渲染元宇宙比特空间。星际广场提供 24 小时高清世界杯赛事节目直播、世界杯周边节目等元宇宙沉浸观赛体验，具备虚拟形象定制生成、万人同屏观赛、游戏化互动等实时云渲染技术与产业发展研究报告（2023年）76 元宇宙数实互动功能，实现小屏、大屏（咪视界）、智能硬件（移动云 VR 等）等多端交互链接。解决方案：在这个项目中采用了创新分布式实时渲染技术，实现了云原生实时互动体验的最小业务模型，采用多（N）台电脑（运算设备）的集群，服务更多（M）个用户的一个非对称的多对多业务模式，达成一定程度的算力设备共享的体验。这也是率先实现实时渲染交互中的计算和渲染任务多用户共享的具有突破性创新的系统的首次产品化体验。这样根据更多的体验需要更大的算力为代价的假设，更多的算力可共享的系统，才可以在实时渲染领域体现设备集群相较于每个人拥有高性能算力设备的优势。来源：中国移动咪咕公司 图 20 星际广场画面 应用成效：星际广场同时采用了高清数字人、实时状态同步、自定义大场景渲染管线、基于空间声场的范围语音和支持动态扩展的服务器框架等技术，为用户打造了一个高沉浸、低延时的互动空间，借助本地渲染引擎预测和数据传输算法优化，实时状态同步方案支持万人同时参与。产品在完成超大尺寸场景渲染的同时，引入动静光照系统、场景光照探针和动态阴影，模拟真实且梦幻的展厅效果，打造更为真实的场景沉浸感。用以上的技术突破与实现，为用户营造出独一无二的元宇宙赛事观看体验。编制说明编制说明 实时云渲染作为新一代信息技术的融合产业，全面赋能各个行业。在此阶段，中国信息通信研究院联合行业代表企业，共同编制发布实时云渲染技术与产业发展研究报告（2023 年），希望为业界厂商、政府机构等相关方提供有益参考，共同推进实时云渲染产业创新发展。特别感谢安徽海马云科技股份有限公司、阿里云计算有限公司、北京蔚领时代科技有限公司、北京庭宇科技有限公司、北京火山引擎科技有限公司、北京凌宇智控科技有限公司、北京英博数科科技有限公司、北京松应科技有限公司、硅基大陆（成都）科技有限公司、光线云（杭州）科技有限公司、咪咕文化科技有限公司、启朔（深圳）科技有限公司、上海达龙信息科技有限公司、深圳云天畅想信息科技有限公司、腾讯云计算（北京）有限责任公司、武汉芯动控股集团有限公司、新国脉数字文化股份有限公司、元境生生（北京）科技有限公司、中移（苏州）软件技术有限公司等单位的支持（以上排名不分先后）。限于编写时间、项目组知识积累与产业尚未完全成熟等方面的因素，内容恐有疏漏，烦请不吝指正。中国信息通信研究院 泰尔终端实验室中国信息通信研究院 泰尔终端实验室 地址：北京市海淀区花园北路地址：北京市海淀区花园北路52号号 邮编：邮编：100191 电话：电话：-2923 传真：传真： 网址：网址：

0人已浏览 2023-12-13 84页 5星级

R17 RedCap技术，助力5G终端更轻、更简、更优化国际电信联盟（ITU）定义了5G的三大需求，分别是eMBB（增强型移动宽带）、uRLLC（低时延高可靠通信）和mMTC（海量物联网机器类通信）三大应用场景弥补中高速空白n 2018年，R15提供了大幅超越4G体验的5G eMBB能力。n 2020年，R16提供了完整的URLLC能力，使能低时延、高可靠、TSN时间同步网络，为智能制造工厂类业务提供了基于蜂窝技术前所未有的体验。n 2022年，R17完成，为业界带来了基于NR新空口的5G物联网技术RedCap，定义了面向物联网的第一款5G NR终端类型。RedCap定位：相比eMBB、URLLC更轻量级、更低复杂度、更低成本 RedCap意义：大幅降低5G终端模组成本，扩展5G生态系统，推动5G在更多行业的落地和增长。2020.62020.122022.33GPP RAN#90R17 RedCap WI立项3GPP RAN#88R17 RedCap SI立项3GPP RAN#95R17核心标准冻结3GPP RAN#94R18 RedCap演进立项成功2021.63GPP RAN#92R18启动2021.122022 6R17 RedCap冻结（含ASN.1等）R18 RedCap演进WI计划开展时间2022 Q32024 Q2R18 RedCap演进计划冻结时间（含ASN.1等）3GPPCCSA2021.3TC5WG9#113次会议 RedCap关键技术研究报告立项2022.4TC5WG9#118次会议 RedCap关键技术研究报告征求意见稿RedCap标准化，指导5G行业发展2022.12TC5WG9#120次会议 5G轻量化通用模组技术要求立项3GPP即将完成R18功能冻结，CCSA同步进行行标制定2022.6TC5WG9#120次会议 RedCap终端设备技术要求和测试方法立项R17 RedCap典型应用场景RedCap是3GPP R17面向低复杂度5G终端类型的标准，旨在打造轻量级终端，满足中速物联网需求。针对无线传感器、视频监控、可穿戴等业务应用，利用RedCap，可同时满足业务性能和低成本需求参考比特速率2Mbps，可靠性为99.99%，端到端时延100ms。对于安全类型的传感器，时延需求更低，为5-10ms，电源可持续数年经济型视频，参考比特速率为2-4Mbps,可靠性为99%-99.9%，时延500ms。高端视频，例如用于农业，需要7.5-25Mbps。视频监控的业务模型主要为上行传输 例如：智能手表、可穿戴医疗设备、AR/VR护目镜等。参考比特速率为下行5-50Mbps和上行2-5Mbps，峰值速率下行达到150Mbps，上行达到50Mbp。电源应能持续1-2周工业无线传感器视频监控可穿戴设备R17 RedCap研究内容（1/2）Specify support for the following UE complexity reduction features RAN1,RAN2,RAN4:oReduced maximum UE bandwidth:Maximum bandwidth of an FR1 RedCap UE during and after initial access is 20 MHz.Maximum bandwidth of an FR2 RedCap UE during and after initial access is 100 MHz.oReduced minimum number of Rx branches:For frequency bands where a legacy NR UE is required to be equipped with a minimum of 2 Rx antenna ports,the minimum number of Rx branches supported by specification for a RedCap UE is 1.The specification also supports 2 Rx branches for a RedCap UE in these bands.For frequency bands where a legacy NR UE(other than 2-Rx vehicular UE)is required to be equipped with a minimum of 4 Rx antenna ports,the minimum number of Rx branches supported by specification for a RedCap UE is 1.The specification also supports 2 Rx branches for a RedCap UE in these bands.The gNB can know the number of Rx branches of the UE by MIMO layer reporting.oMaximum number of DL MIMO layers:For a RedCap UE with 1 Rx branch,1 DL MIMO layer is supported.For a RedCap UE with 2 Rx branches,2 DL MIMO layers are supported.oRelaxed maximum modulation order:Support of 256QAM in DL is optional(instead of mandatory)for an FR1 RedCap UE.No other relaxations of maximum modulation order are specified for a RedCap UE.oDuplex operation:HD-FDD type A with the minimum specification impact(Note that FD-FDD and TDD are also supported.)R17 RedCap研究内容（2/2）终端类型定义：区分RedCap和非RedCap终端，对RedCap接入控制Specify definition of one RedCap UE type including capabilities for RedCap UE identification and for constraining the use of those RedCap capabilities only for RedCap UEs,and preventing RedCap UEs from using capabilities not intended for RedCap UEs including at least carrier aggregation,dual connectivity and wider bandwidths.RAN2,RAN1早期识别：匹配的调度，接入控制Specify functionality that will enable RedCap UEs to be explicitly identifiable to networks through an early indication in Msg1 and/or Msg3,and Msg A if supported,including the ability for the early indication to be configurable by the network.RAN2,RAN1接入控制：降低对传统终端影响Specify a system information indication to indicate whether a RedCap UE can camp on the cell/frequency or not;The indication is specific to the number of Rx branches of the UE.RAN2,RAN1 Specify support for the Extended DRX enhancements for RedCap UEs RAN2,RAN3,RAN4:Specify support for the RRM measurement relaxations for neighbouring cells for RedCap devices:for RRC_Idle/Inactive/Connected RAN2,RAN4RedCap技术，促进5G行业应用落地RedCap通过最大带宽缩减（20MHz）、减少收发天线数目（最低1T1R）、降低调制阶数（上下行64QAM）等规格裁减，有效降低复杂度和终端（模组）成本，预期复杂度相比eMBB终端降低约37%，芯片设计开发难度大幅下降，在一定程度上降低芯片研发/制造成本RedCap速率方面略优于LTE Cat 4终端，结合5G网络覆盖度以及RedCap终端初始价格的影响，建议产业优先切入RedCap具备明显优势的领域技术指标NR eMBBNR RedCapLTE Cat 4（标准）LTE Cat 1/1bis带宽(MHz)n28：30 n41：1002020收发天线n28：1T2R n41：2T4R1T2R1T1R1T2R1T1R调制方式256QAM64QAM（256QAM可选）64QAMDL：64QAMUL：16QAM速率(Mbps)FDDDL：350UL：175DLULDLULDL：150UL：75DL：10UL：5TDD注DL：1700UL：250DLULDLULDL：100UL：15DL：7.4UL：1注：NR TDD：7D1S2U，特殊时隙6:4:4；LTE TDD：3D1U，特殊时隙10:2:2数据来源：参见3GPP TR 38.875R18 RedCap研究背景及研究内容背景与需求 场景：FR1 FDD R18 RedCap定位：比R17 RedCap低端，比LPWA高端的物联网终端，例如工业传感器，峰值速率10Mbps研究内容Further reduced UE complexity in FR1 RAN1,RAN2,RAN4UE BB bandwidth reduction5 MHz BB bandwidth only for PDSCH(for both unicast and broadcast)and PUSCH,with 20 MHz RF bandwidth for UL and DLThe other physical channels and signals are still allowed to use a BWP up to the 20 MHz maximum UE RF BB bandwidthSupport additional separate early indication(s)RAN1,RAN2UE peak data rate reductionRelaxation of the constraint(vLayersQmf 4)for peak data rate reductionThe relaxed constraint is,e.g.,1(instead of 4)The parameters(vLayers,Qm,f)can be as in Rel-17 RedCapBoth 15 kHz SCS and 30 kHz SCS are supported.Define at most one Rel-18 RedCap UE type for further UE complexity reduction.RedCap引入5G通用模组，加速5G行业发展2022.6R17 RedCap标准冻结2023Q3-2024H1首批R17 RedCap芯片/模组商用2024H2-2025R17 RedCap终端/模组规模应用2022.Q4R17 RedCap端到端技术试验2025-2026首批R18 RedCap芯片/模组商用2027R18 RedCap终端/模组规模应用应用进程RedCap的产业发展必然经历标准制定、技术验证、芯片产品化、终端/模组商用初期、规模化应用阶段的历程，随着商用进程，功能逐步叠加，性能日趋稳定。预计RedCap引入5G通用模组后，年出货量达千万量级、累计出货量上亿级时，5G通用模组价格有望达到100元级（4G模组出货量达亿级以上，加上对4G芯片的持续优化，Cat4模组已降至70元左右）RedCap NR其他技术，赋能千行百业叠加NR各类优秀特性（URLLC、节能、覆盖增强、切片、CAG、边缘计算、SUL、5G LAN等），在带宽、时延、可靠性、安全隔离等具备优势，实现对垂直行业的强大赋能RedCap终端能够更好地满足垂直行业需求，在性价比上将比4G终端更具优势，且RedCap终端预期将比4G终端具备更长久的生命周期、更广阔的应用领域降时延降时延lRedCap URLLC等等l场景：工业传感器等低时延场景降功耗降功耗lRedCap WUS等等l场景：低功耗场景，如可穿戴强覆盖强覆盖lRedCap R17覆盖增强覆盖增强/SUL等等l场景：深度覆盖场景差异化管理差异化管理lRedCap 切片、切片、CAG、边缘计算、边缘计算l场景：不同业务需求场景开展技术试验，加速RedCap商用成熟北京实验室覆盖5家网络厂商和4家芯片厂商涵盖基本功能、终端识别、驻留与接入控制、BWP配置、功耗优化等关键技术网络初步具备RedCap能力外场覆盖5家网络厂商和3家芯片厂商涵盖业务性能、移动性、边缘覆盖等方面关键技术网络具备商用条件山东江苏上海浙江湖北2023年是发展初期，预计2024年起逐步起量规模发展面向RedCap商用，构建端网协同测试体系，联合产业在实验室和外场开展全面测试，加速端网互通，提升产业成熟度，助力RedCap商用.RedCap发展与应用建议，多维度推动技术落地发展与应用建议继续完善RedCap国内相关标准的制定，明确具体能力要求，指导产业，加快产业节奏；产业链各环节积极合作，加速产业发展，积极参与技术试验和试点应用，尽快开展RedCap终端与网络的端到端功能/性能验证，结合技术验证，对RedCap引入后网络和用户体验的性能影响加以研究，加快产业成熟；在保障性能的基础上，加快开展进一步降低终端/模组成本的方案研究，助力5G行业化应用落地

0人已浏览 2023-12-13 12页 5星级

北京稻壳科技有限公司Beijing Rice Hull Technology Co.,Ltd.地址：北京市朝阳区九住路 188 号IMT-2030(6G)推进组IMT-2030(6G)Promotion Group2023 年年 12 月月版权声明版权声明 Copyright Notification未经书面许可未经书面许可 禁止打印、复制及通过任何媒体传播禁止打印、复制及通过任何媒体传播2023 IMT-2030（6G）推进组版权所有2IMT-2030(6G)推进组IMT-2030(6G)Promotion Group目录第一章第一章新型多址接入概述新型多址接入概述.51.1基本概念和原理.51.2技术研究的国内外现状.61.3产业发展现状.71.4与 5G 非正交多址研究的区别.8第二章第二章应用场景和性能指标需求应用场景和性能指标需求.92.16G 系统的典型场景和空口关键性能指标.92.2海量连接场景.92.3密集紧要连接场景.102.4空天地一体化场景.102.5大容量场景.112.6需求小结.12第三章第三章多址接入的理论研究多址接入的理论研究.133.1无标识多址接入的信息论容量界.133.1.1系统模型.133.1.2CSIR 理论界.143.1.3No-CSI 理论界.153.1.4数值计算结果.153.2基于随机几何分析免调度叠加传输理论性能界.16第四章第四章海量多址接入关键技术海量多址接入关键技术.184.1稀疏 IDMA 压缩感知.184.1.1系统架构.184.1.2接收机算法.204.1.3初步仿真结果.214.2线性扩展类的传输.254.2.1基于码域空域联合扩展的无连接传输.254.2.2基于立方分割码本.284.2.3级联式线性扩展码本.294.2.4基于模式分割的随机接入方案.304.3多段编译码.304.3.1压缩感知.304.3.2资源跳跃.324.4混合类或其它方案.344.4.1基于 Reed-Muller 码.344.4.2稀疏 IDMA 有限域扩展.354.4.3可扩展同步前导序列.37参考文献参考文献.38具体贡献说明具体贡献说明.413IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图目录图 1-1下行两用户系统非正交多址（NOMA）与正交多址（OMA）的容量比较.5图 1-2上行两用户系统非正交多址（NOMA）与正交多址（OMA）的容量比较.6图 2-1新型多址接入的四大应用场景.9图 2-2紧要连接场景：智能工厂（左图）、V2X（右图）.10图 2-3空天地一体化场景31.11图 2-4大容量场景.11图 3-1多址接入研究现状与本节研究内容.13图 3-2活跃用户数随每比特能量的变化.16图 3-3频谱利用效率随天线数的变化.16图 3-4CS-GF-NOMA 系统的检测成功率。(a)与 P 的关系；(b)与 N 的关系.17图 4-1稀疏 IDMA 的系统架构.18图 4-2基于 LDPC 码的稀疏 IDMA 的编译码原理.19图 4-3基于极化调整卷积编码的稀疏 IDMA 编译码框架.20图 4-4稀疏 IDMA 的和EXIT 分析.20图 4-5基于压缩感知的迭代检测.21图 4-6MAMP 接收机.21图 4-7错误检测概率与 FFT 大小关系，激活用户数是 300.22图 4-8卷积码和 LDPC 性能比较.23图 4-9真实信道估计及其性能.23图 4-10SNR 门限随活跃用户数的变化关系.24图 4-11基于极化调整卷积码的稀疏 IDMA 仿真性能.24图 4-12用户激活检测仿真性能对比.25图 4-13线性扩展随机接入多址发射机.25图 4-14分区匹配法（Partition Matching Method）.27图 4-15超低碰撞率导频.27图 4-16发射机系统框图.28图 4-17传输包大小为 10 字节时系统误比特率性能仿真.29图 4-18两个扩展码本级联举例.29图 4-19不相关瑞利衰落信道下 PMF曲线.30图 4-20压缩感知编码的系统架构.31图 4-21基于硬判决的波束空间树译码器的剪枝过程.31图 4-22基于软判决的波束空间树译码器的剪枝过程.31图 4-23资源跳跃多址发射机设计.32图 4-24资源跳跃多址接收机设计.32图 4-25结合 SIC 的资源跳跃多址发射机设计.33图 4-26ALOHA 与资源跳跃多址（RHMA）的碰撞解决概率对比.33图 4-27Reed-Muller 码无源多址方案.34图 4-28Reed-Muller 无源多址方案仿真性能.35图 4-29有限域在 GF(4)上扩展的一个例子.36图 4-30级联因子图编解码举例（用户 1 和 2 分别通过重复 2 次和 1 次来扩展编码符号）.36图 4-31所需信噪比随活跃用户数变化的性能曲线.374IMT-2030(6G)推进组IMT-2030(6G)Promotion Group表目录表 2-1新型多址接入技术需求指标.12表 4-1单时隙仿真参数配置.21表 4-2Case I，II 和 III 参数配置.22表 4-3多时隙仿真基本参数配置.23表 4-4碰撞容限和重复度分布的参数设置.23表 4-5多用户单天线系统传输性能仿真参数.28表 4-6基于 Reed-Muller 码的无源多址仿真参数.345IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第一章第一章新型多址接入概述新型多址接入概述1.1 基本概念和原理多址接入是指通信资源的多用户复用。移动通信从第一代（1thgeneration，1G）到第五代（5thgeneration，5G）基本上都是正交多址（Orthogonal multiple access，OMA），即不同用户的频域、时域或者码域资源彼此正交。第一代蜂窝通信的多址技术是频分复用（FDMA，Frequency division multipleaccess），仅支持语音服务。每个用户的无线资源按固定的频率划分。第二代蜂窝通信的多址技术以时分复用（Time division multiple access，TDMA）为主，基本业务是语音通话。第三代蜂窝通信广泛采用扩展码分复用（Code division multiple access，CDMA），使得信道的抗干扰能力大大增强。相邻小区可以完全复用频率。第四代和第五代蜂窝通信主要采用正交频分接入（Orthogonal frequency multiple access，OFDMA），子载波间的正交性通过集中式的多载波处理和添加循环前缀（Cyclic Prefix，CP）来保证，具有较高的频谱效率，能够有效支持大带宽和多天线（Multiple-input multiple-output，MIMO）技术。由于用户之间的干扰较低，正交多址实现起来比较简单，接收侧的信号处理复杂度较低。但在多用户系统，正交多址的性能潜力与系统的容量界有很大差距。非正交多址（Non-orthogonal multiple access，NOMA），能够有效地支持多个用户同时同频同空域的传输，以提高系统吞吐和终端连接数。理论上可以证明，非正交多址多用户系统容量界明显高于正交多址。图 1-1 是一个单发单收天线的两用户下行传输系统1，这里的 UE1 和 UE2 分别代表远离基站和靠近基站的用户，下行发射功率分别为 P1和 P2，总的发射功率（P1 P2）保持恒定，但可以调整 P1和 P2之间的比例。信道增益分别是21h和22h。图1-1下行两用户系统非正交多址（NOMA）与正交多址（OMA）的容量比较从图 1-1 发现，无论发射功率的配比如何，下行非正交多址的“和容量”总是大于正交多址的“和容量”。具体的看，非正交容量界的 A 点所对应的 UE1 的频谱效率是 0.9 bps/Hz（bit per second per Hertz）,此时 UE2 的频谱效率是 3 bps/Hz。正交容量界的 B 点所对应的 UE1 的频谱效率是 0.64 bps/Hz,明显低于非正交的。再看正交容量界的 C 点，所对应的 UE1 的频谱效率是 0.9 bps/Hz，与容量界的 A 点相当，但此时 UE2 的频谱效率只有 1 bps/Hz，大大低于非正交时 UE2 的水平（即 3 bps/Hz）。同理，上行两用户系统容量也可以采用类似的分析，图 1-2 是当 UE1 和 UE2 的上行信噪比为 0 dB和 20 dB 时的上行正交多址和非正交多址的“和容量”，可以看出在多数情况下，非正交多址系统的上行容量高于正交多址。6IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图1-2上行两用户系统非正交多址（NOMA）与正交多址（OMA）的容量比较在以上的多址系统分析中，假设每个用户处于连接态（Connected），有大数据包连续发送，系统能够根据用户的信道状态信息（Channel state information，CSI）来进行用户配对、资源调度和链路自适应等，比较适合增强移动宽带（Enhanced mobile broadband，eMBB）业务。除此之外，多址还应支持处于非激活态（Inactive）或者是空闲态（Idle）用户的数据传输，即免调度（Grant-free）传输或完全自主（Autonomous）传输，且以上行为主。免调度是指系统无需为用户分配正交的时频域资源，也不需要根据 CSI 反馈和重传来对衰落信道进行动态的链路自适应。免调度可以是非竞争式的，此时用户处于连接态的或非激活态，一些重要参数系统事先已为每个用户配好，例如参考信号（导频）序列、扩展码、交织图样、扰码等，以保证不同用户彼此之间不发生碰撞。因此，免调度也被称为预先配置的调度（Configured Grant）。免调度还可以是完全自主的传输，也被称为无物理标识（Unsourced）传输。此时用户处于空闲态，通过竞争的方式接入，有可能出现导频、扩展码等的碰撞问题。无物理标识传输比较类似随机接入的场景，传统方法是 ALOHA 方式的竞争接入。但是随着海量巨址接入的引入，ALOHA 方式不再有效，最近几年在信息论上的相关突破，使得非正交多址接入的理论有了长足发展。1.2 技术研究的国内外现状新型多址接入近几年在信息论方面的研究有不少突破，尤其在无物理标识上行传输，即基站接收端只恢复所传输的消息，而不做用户检测。十分适合完全自主传输的场景，对于海量叠加传输具有重要的指导意义。这些理论分析的价值还体现在对有限码长的性能分析上。海量叠加传输的数据类型一般是短包，此时信道容量与假设无限码长的香农容量界相差很大，考虑有限码长有利于得到更紧的容量界，提供更加精准的设计目标。海量用户系统容量分析的早期代表如文献2，开启了信息论的另一套分析方法，得到了当用户数和信息码块长度都趋向无穷（但保持有限比率）时的系统容量，文献3在此基础上，结合有限码长的条件，对多用户 Unsourced 传输进行分析，得出高斯多用户接入信道（Gaussian MultipleAccess Channel，GMAC）的容量。进一步地，文献4推导出有限码长瑞利衰落信道（Rayleigh Fading）下的无物理标识传输的系统容量。这些信息论方面的分析结果明确指出：正交传输或者 ALOHA 方式传输的系统性能远远低于 Unsourced 传输的容量界，并且性能差距随着用户数的增多而增加。从衰落信道多用户系统平均中断概率的角度，可以分析非正交传输相对于正交传输的性能潜力5。通过蒙特卡洛数值方法，计算在总频谱效率一定的情况下，随着用户增多，要满足相同的中断概率，非正交传输所需的信噪比要更低，这从某种意义上体现了用户分集（User Diversity）的增益。虽然文献5假设码长无限，所用的分析方法与文献4也不相同，但结果所呈现的趋势是一致的：用户数愈多，非正交多址的潜力愈大。基于调度的非正交多址理论性能的研究近几年也有一些进展，例如文献6提出基于信号和干扰对齐的速率分拆（Signal InterferenceAlignment based Rate Splitting,SIA-RS），一方面利用了速率分拆对 CSI的鲁棒性，另一方面得益于对齐带来的可靠性。公共信号和私有的目标信号可以对齐以提高串行干扰消除（Successive Interference Cancellation,SIC）接收的性能，而私有的干扰信号可以通过干扰对齐得到减7IMT-2030(6G)推进组IMT-2030(6G)Promotion Group弱。上述方案能够降低公共信号对 CSI 准确度的要求，增加叠加复用的增益。在传输技术方面，主要有如下几大方向：基于符号级或者比特级的扩展，可以是线性扩展，采用非正交的扩展序列，而不改变信号的调制方式，例如文献7中的复数序列，或者是严格满足 Welch-Bound 的序列8。还可以是扩展与调制联合设计，以最大化不同用户符号间的欧式距离，并引入稀疏特性，降低接收机复杂度910。这一类方法比较适用于非竞争式免调度场景，对于线性扩展类的，如11可以用于无物理标识上行传输。基于比特级的交织、加扰、重复等，降低码率，形成资源上的稀疏分布，依靠接收侧的迭代检测和译码来区分不同数据。这类方法的性能很大程度上取决于信道编码，而与传统针对单用户的信道编码设计不同，这里的信道编码需要有较强的对抗多用户干扰的能力，并且能够在迭代检测和译码过程中迅速收敛。这类方法既可以用于免调度场景，例如实现高过载率的叠加传输12，也可以用于无物理标识上行传输131415。级联编码，采用内码和外码级联的方式，有若干细分种类，例如内码用于对抗高斯信道的加性白噪声，而外码用于解决多个用户碰撞问题16。或者是内码采用压缩感知编码，将每个子块的消息恢复抽象为压缩感知问题，而外码采用树型编码，通过校验冗余，完成数据的拆分和拼接17。级联编码类的方法主要用于无物理标识上行传输。与传输方案相配合，有几个方面的研究对系统性能、复杂度等会产生重要影响：用户激活检测和信道估计的压缩感知类算法。对于无物理标识传输，海量用户接入的潜在数量巨大，但同时激活的用户数比例较低，呈现稀疏性。可以借助压缩感知算法1819，检测到激活用户和所用的交织、扰码、扩展序列，以便进行下一步的数据检测和译码20。联合接收机算法，包括集用户激活检测、信道估计和信号检测于一体的近似消息传递和贝叶斯算法21，不需要参考信号、直接基于数据进行信道盲估计和解调译码11等。与多天线技术的结合。多天线已在 4G 和 5G 系统中广泛应用，即使是中低频段，许多 5G 基站支持 48 根天线。实际系统中的多天线空间信道可能具有一定的相关度，此时经典压缩感知算法不再适用，文献22提出的算法可以在天线之间有相关性的条件下有效工作。利用机器学习/深度学习来改进算法，尤其是在压缩感知的接收算法方面23。例如对经典AMP(Approximate message passing)算法的增强24，降低估计误差，提高迭代收敛速度。1.3 产业发展现状基于调度的下行非正交多址在 3GPP 称为 Multiple User Superposition Transmission（MUST）25，于2016 年完成标准化，属于 4G LTE-Advanced 比较后期的版本，邻近 5G 标准化的开启时间。MUST 支持下行两用户叠加传输，两用户可以采用相同的空间预编码（即处于相同的波束），或者采用不同的空间预编码（类似多用户 MIMO）。对于相同预编码的情形，限定配对的远端用户的调制阶数不能超过Quadrature phase shift keying（QPSK），可以是传统终端，无需进行串行干扰消除。近端用户的最高调制阶数为 64-Quadrature amplitude modulation(QAM)。相应的标准化集中在发射侧的星座图叠加，一处是通过特别的映射处理，保证合成星座图符合格雷映射，从而降低近端用户接收机的复杂度，只需符号级 SIC，而不用进行码字级 SIC；另一处是通过合理分配远端和近端用户的发射功率比，使得合成星座点保持等间距。经过这两处优化，两用户合成星座图始终是标准 256-QAM 或者是 256-QAM 的等间距采样星座点，这样可以显著降低终端硬件射频模块的复杂度。日本 NTT DOCOMO 公司对 MUST 技术在密集城区场景进行了测试。上行非正交传输，尤其是非竞争式的免调度，在 3GPP 5G 中开展过大量的链路级/系统级的性能仿真26，分两个时间段，2016 年 4 月到 2016 年 10 月，以及 2018 年 2 月持续至 2018 年 12 月。积极参与的公司超过 20 家，提出的各类方案有十几种，大体上分为三类，第一类是基于线性符号级扩展，扩展序列具有比较低的互相关；第二类是基于比特交织/扰码的，需要迭代检测；第三类是符号扩展与星座调制联合设计，码字具有一定的稀疏性，需要简化的消息传递迭代接收算法。因为种种原因，5G 最后没有达成方案的融合收敛，但部分设计思想在之后的两步随机接入（2-step RACH）中标准化27。8IMT-2030(6G)推进组IMT-2030(6G)Promotion Group20172018 年期间，华为、中兴和中信科移动对各自的 5G NOMA 方案进行了样机系统研制开发，并完成基于实际环境的外场测试，测试结果表明，相比传统正交多址，非正交传输能够支持更多的并发用户。1.4 与 5G 非正交多址研究的区别与 5G 时代非正交研究相比，6G(6thgeneration)新型多址与其区别如下：研究内容更多5G 主要是多址传输方案，6G 可以认为是随机接入和非正交多址的接合。除了多址传输方案，还包括导频设计，用户激活检测，多用户信道估计和多用户迭代检测。接入用户数更多5G 多址研究是十几个用户接入（一般不大于 15），6G 由于连接密度更大，接入用户数巨大，例如300 用户的同时接入。用户标识，激活用户数是否已知5G 时一般假设用户标识如扩频序列，星座图映射，资源映射，交织器，扰码已知，激活用户数已知（只有少数方案假设用户标识未知，激活用户数未知）。在用户标识已知和激活用户数已知条件下研究多用户传输方案及检测方法。6G 新型多址用户标识未知，需要利用导频进行估计。激活用户也未知，需要通过对导频进行检测得到。导频是否碰撞5G 多址很多情况下假设导频不碰撞，但用户标识可能存在碰撞。由于导频也是叠加在一起的，它也是非正交复用。当导频碰撞时多用户信道估计也是一个难题。如何在导频碰撞条件下进行多用户信道估计和多用户信号检测非常具有挑战。6G 新型多址考虑了导频碰撞和利用导频进行信道估计。导频设计及对导频的信号处理5G 非正交多址导频沿用 5G NR(New radio)设计，对导频的处理一般是干扰消除。由于 5G NR 导频数目有限，同时干扰消除接收机性能有限，整体性能受限，如支持用户数不多。6G 使用压缩感知进行信号处理，导频使用缩短的 FFT(Fast Fourier transform)矩阵或其它正交变换的矩阵，码本数量巨大，可达215，以此确保用户碰撞概率很低。使用 AMP 或 OAMP(Orthogonal approximate message passing)，MAMP(Memory approximate message passing)进行迭代检测，以低复杂度可达最大似然接收机性能。信道编码不同5G 非正交多址的信道编码沿用 5G NR 的设计，即 LDPC(Low density parity check)编码。由于 LDPC在短码长下性能存在较大损失，因此使用 LDPC 性能受限。6G 新型多址信道编码也是其重要研究内容，大约束长度的咬尾卷积码，不规则重复累积码(Irregular repeat-accumulate)，多元 LDPC 以及 Polar 码都值得做进一步研究。9IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第二章第二章 应用应用场景和性能指标需求场景和性能指标需求2.1 6G系统的典型场景和空口关键性能指标随着移动通信系统的持续发展，6G 将会考虑对新场景的支持，并提出新需求，这也需要多址技术继续演进以满足 6G 新场景的需求，进一步提升系统容量，提高连接密度，降低系统的功耗和成本，降低接入时延等。本节将从如图 2-1 所示的 4 个场景进行初步分析，考虑对新型多址接入技术的指标需求。图2-1新型多址接入的四大应用场景2.2 海量连接场景海量机器类通信（massive Machine Type Communication,mMTC）是 5G 三大典型应用场景之一，面向 2030 年及未来的 6G 将在 5G 典型应用场景的基础上进行深化，进一步构建超大规模连接，扩展全新的应用领域和能力边界。从终端数量来看，传统智能手机业务将保持稳定增长态势，同时随着物联网设备在个人消费、人工智能、智慧交通、智慧城市、智慧医疗、数字孪生等领域的应用，面向智能生活和面向工业生产的物联网终端设备有望呈现爆发式增长。根据 IMT（International Mobile Telecommunications）-2030（6G）推进组预测，面向 2030 年商用的 6G 网络中将涌现出智能体交互、通信感知、普惠智能等新业务、新服务，预计连接密度将达到每平方公里一千万个连接或者更大的连接数28。海量连接场景有着众多领域的应用，在不同的应用场景下，根据业务特征不同，终端设备进行数据发送的频率也会有所差异。这里以数据发送频率为 1 message/30 seconds/device 为例进行分析，结合每平方公里 1 千万的连接数，假设一个宏站可覆盖 1 平方公里的面积，那么可以估算出每个宏站需要在 1 毫秒的时间内完成大约 300 个小数据包的接收。如果采用 5G NR 中现有的 4-step 或 2-step 接入方式，等完成接入之后才进行数据传输，为每个突发、短暂的消息上报过程建立并维护通信链路，容易造成系统的过载以及信令拥塞，导致终端接入时延增大，甚至服务中断；另一方面，拥塞环境下终端可能需要尝试多次才能接入网络，也会显著增加消息上报的功耗，不利于低成本低功耗的物联网终端。因此，在设计 6G 中的接入技术时，为能够支持海量连接场景，需引入新型多址接入技术，简化接入过程，降低信令开销和功耗。10IMT-2030(6G)推进组IMT-2030(6G)Promotion Group2.3 密集紧要连接场景密集紧要连接场景将在超高可靠低时延通信（Ultra Reliable Low Latency Communication,URLLC）的基础上进一步进行增强，实现更低时延、更高可靠性、更大连接数的目标。典型应用包括垂直行业的数字化（例如“智能工厂”应用场景）和自动驾驶的深度智能化（例如“V2X（Vehicle-to-everything）”应用场景），能够极大提高生产效率，如图 2-2 所示。图2-2紧要连接场景：智能工厂（左图）、V2X（右图）在面向工业 4.0 的智能工厂应用场景中29，10000m2厂房范围内的终端数量一般大于 2000 个，要求通信速率大于 100kbps（视频监控除外），通信时延小于 10ms，通信可靠性须满足工业报警信息的可靠传输，5G NR 系统可以满足工业 4.0 的需求指标。不断发展的工业 5.030对无线通信提出了更高的要求，相比工业 4.0 预计有高达百倍的性能提升，需要系统能够提供安全可靠的通信服务，以满足超低时延、超高可靠的控制需求。工业 5.0 的性能要求初步按照如下假定进行估算，在 10000 m2的厂房范围内，部署 10 个以上的基站，总的终端数量大于 20000 个，通信速率大于 10Mbps（Million bits per second），通信时延小于 0.1ms（millisecond），通信可靠性为丢包率小于 10-5。V2X 场景中，需要实时进行信息交互。例如，部署在车辆上的数据采集设备需要对车辆的实时位置、速度、目的地等信息进行上报，同时部署在道路上的数据采集设备需要实时上传道路的车量总数、路况、红绿灯等信息，用于控制中心对实时交通进行建模，预测未来的道路交通情况，给出最优的交通调度和指引信息。数据传输指标可以按照以下进行估算，进行数据上传的频率可能为毫秒级，需要上传的数据量预计在数十到数百字节，完成数据传输的时延可能在毫秒级。另一方面，基于车辆间直连通信的 V2V（Vehicle-to-vehicle）由于传输距离更短，可以让车辆之间实现更低时延（例如亚毫秒级）的高可靠信息交互。紧要连接场景中，需要考虑极低的时延。例如，一种可能的处理是要求每个终端都处于激活态，这样可以减少由于建立连接导致的时延。在这种假设下，每个基站预计需要同时维持 2000 个终端的 RRC（Radio resource control）连接，这已经超出目前商用 5G 最大可支持 400 个 RRC 连接的能力。在平均数据流量上，紧要连接场景预计每个基站为 20 Gbps（Giga bits per second）以上，目前的 5G 技术能够满足这一指标要求；通信时延方面，紧要连接场景预计比 5G 低一个数量级，例如小于 0.1ms；紧要连接场景中的可靠性与 5G 的可靠性最高要求相同，例如丢包率小于 10-5。实际上，紧要连接场景真正给 5G 带来挑战的，是上述通信指标需要同时被满足。特别地，对于 V2X 这种紧要连接场景，由于车辆节点的快速移动,导致车联网网络拓扑迅速变化，使得海量、突发、低时延、高可靠这些通信需求同时满足更为困难。因此需要引入一个具有极高传输效率的新型多址接入技术，以支持紧要连接场景。2.4 空天地一体化场景以 5G 为代表的地面移动通信能够提供丰富的业务支撑能力和良好的用户体验，但地面移动通信整体上存在覆盖范围受限的问题。空天地一体化具有扩展覆盖、节省成本等多种优势，被业界视为 6G的重要关键技术。空天地一体化场景如图 2-3 所示。11IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图2-3空天地一体化场景31低轨卫星通信32是实现空天地一体化的一个典型考虑。地面无线网络仅覆盖了地球表面积的 6%，作为地面无线网络的补充，低轨卫星通信具有较低的成本、较低的时延、较低的路损等优势，将成为 6G的重要组成部分，实现全球立体覆盖。以低轨卫星为例进行分析，例如假设低轨卫星的高度 h0为 600 km33，低轨卫星有效覆盖的最小俯仰角为 10。根据地球半径 6378 km，可以计算出假设的低轨卫星到地面终端设备的最远距离 d 为 1932km，如图 2-3（右）所示。对于 transparent 类型的低轨卫星，根据上述假设进行计算，仅由距离引起的RTT（round trip time）时延将会达到 25.77 ms。对于 5G 地面无线网络中的控制面时延，从发出注册请求消息开始到发出注册完成消息为止，大约为 70100ms。假设低轨卫星，如果按 10 次信令交互计算，地面无线网络的传播时延在 10 微秒级，相对卫星网络的传播时延可以忽略，低轨卫星的控制面时延大约为330360 ms。同时，由于低轨卫星移动速度快，典型的卫星波束服务时间为秒级，被波束边缘服务的终端设备，卫星波束服务时间更短。假设卫星波束 1 秒切换一次，控制面时延将占到卫星波束总时域资源的 336%。可见，控制面时延开销对低轨卫星来说占的比重较大，导致系统效率降低。因此，如果采用 5G 技术支持 6G 全球立体覆盖场景，会在时延、效率等方面存在缺陷。6G 需要引入极简的新型多址接入技术，减少信令交互次数（例如把控制面和数据面的空口交互次数降到最低 24 次，把信令交互的资源开销降低 60%），以支持空天地一体化场景。2.5 大容量场景大容量是 6G 的一个重要应用场景，无论是以人为中心的通信还是以机器为中心的通信，随着社会智能化的发展，对峰值速率、用户体验速率、系统容量等提出了更高的要求。根据 ITU-R（Radiocommunication division of the international telecommunication union）的预测34，在 2030 年之前，移动数据流量将会随时间呈现指数级的增长，达到现在的 25 倍左右，移动数据流量以 XR（extended reality）、全息通信等新业务所产生的流量为主，如图 2-4 所示。图2-4 大容量场景理想的 XR、全息通信等新业务所产生的流量是非常大的3534。XR 业务的用户体验要想达到完全沉浸的水平，例如进行如下估算，角分辨率需达 60 ppd（pixels per dot），帧率不能低于 120 Hz，视场角不能低于 130，每个像素按照 12 比特，且能够在一定程度上消解调焦冲突引发的眩晕感，如果压缩比为 100，那么单个终端的吞吐量需求约为 3.8 Gbps。全息通信如果想达到足够快的全息图像传输能力和12IMT-2030(6G)推进组IMT-2030(6G)Promotion Group强大的空间三维显示能力，以传送原始像素尺寸为 1920108050 的 3D 目标数据为例，RGB（Red greenblue）数据为 24 比特，刷新频率 60 fps(frame per second)，需要峰值吞吐量约为 149.3 Gbps，按照压缩比 100 计算，平均吞吐量需求约为 1.5 Gbps，由于用户在全方位、多角度的全息交互需要上千个并发数据流，由此推断用户吞吐量可以达到 Tbps(Tera bits per second)量级。目前，各方纷纷提出 6G 的关键技术指标和若干关键使能技术。针对大容量的场景，6G 的谱效提升可能是非常有挑战性的目标，可引入新型多址接入技术，在传统的谱效提升技术出现边际效应后，还能够获得 1.52 倍以上的谱效增益。2.6 需求小结本节分析了 6G 的四个主要应用场景，6G 对新型多址接入技术的需求指标总结在表 2-1 中，随着 6G的发展，可能会出现更多的场景，对新型多址接入技术也会提出更多的新需求。表2-1新型多址接入技术需求指标应用场景5G 的能力设计目标示例海量连接一个宏基站支持每十毫秒内完成 1.39个终端的多址接入和小数据包传输。一个宏基站支持每十毫秒内完成 3000 个终端的多址接入和小数据包传输。密集紧要连接目前商用 5G 最大可支持 400 个左右的RRC 连接；5G 的通信时延能力是 1ms；5G 中三大场景仅能够分别满足，不能同时满足。在单个基站覆盖范围内，同时满足下述所有指标：同时服务 2000 个以上的设备、平均数据流量达到 20Gbps 以上、通信时延小于 0.1ms、丢包率小于 10-5等。空天地一体化单载扇可以支持 400 个左右的 RRC 连接；控制面时延可能将占到总时域资源的 20%以上，明显降低了系统的效率。每波束需要同时服务5万个窄带IoT设备，明显降低控制面的总时延，把控制面和数据面的空口交互次数降到最低 24 次，把信令交互的资源开销降低 60%。大容量达到 1Tbps 的峰值数据速率、5Gbps 的用户体验数据速率是非常困难的。达到 1Tbps 的峰值数据速率、5Gbps 的用户体验数据速率。13IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第三章第三章多址接入的理论研究多址接入的理论研究3.1 无标识多址接入的信息论容量界经典的信息论针对单用户且码长 n 趋于无穷的场景给出了信道容量的表达式，当码长 n 有限时，文献36推导了速率的高阶近似表达式。在传统的多用户接入模型中，一般假设码长较长，但系统中的用户数保持不变，基于联合误差概率准则，文献37和文献38分别建立了传统多用户接入的容量域以及速率高阶近似表达式。多址接入基础理论分析的研究现状如图 3-1 所总结。与传统多用户接入场景相比，超大规模连接场景中的通信方案设计主要受四个因素的影响39：1)海量用户通常以随机活跃的方式接入系统；2)每个用户传输的信息比特数量较少；3)每个用户的通信能效有严格要求；4)每个用户要尽量实现低时延传输。为应对这些挑战，需要采用大规模随机接入技术，因此需要建立与传统多用户信息理论不同的研究体系。针对超大规模连接场景，文献2提出了海量用户接入信道模型，并基于联合误差概率准则分析当用户数随码长变化并趋于无穷时的对称信道容量。然而，该信道容量的分析依赖于每比特能量趋于无穷的假设，不满足实际通信系统的低功耗需求。针对这个问题，文献4使用平均每个用户误差概率准则，并基于码长和用户数趋于无穷但每比特能量保持有限的假设，分析单天线瑞利衰落信道中多用户接入的理论界，发现当用户密度较小时，存在编码方案能够消除多用户干扰。然而，码长和用户数趋于无穷的假设与超大规模连接场景的特点不一致，无法刻画实际系统的性能极限。因此，针对超大规模连接的非渐近理论界仍然未知。此外，基于多天线的多路数据传输技术可以充分利用信道的空间资源达到复用时域资源、增强信号、抑制干扰的目的，从而有效提高系统频谱利用率和功率效率，在超大规模连接场景中具有重要价值。因此，本节旨在围绕超大规模连接的场景，如图 3-1 所示，分别针对信道状态信息已知(Channel stateinformation at the receiver，CSIR)和信道状态信息未知(No-channel state information，no-CSI)两种情况介绍非渐近域下的空时频三维大规模用户接入系统时传输性能紧致的理论极限40，系统性地分析天线数、每个用户传输信息比特数、用户随机接入概率、发送功率、错误概率门限等因素和用户容量界之间的关系，从而揭示出超大规模连接系统中的性能极限并指导实际多址接入方案的设计。图3-1多址接入研究现状与本节研究内容3.1.1系统模型考虑一般性的超大规模连接信道，其中基站配置的天线数为 L，总用户数为 K，用户均配置单天线。假设活跃用户数 Ka已知，活跃用户集合记为aK，每个活跃用户传输的信息比特数为 J。假设每个用户有独立的码本，包含 M 个长度为 n 的码字。14IMT-2030(6G)推进组IMT-2030(6G)Promotion Group考虑瑞利块衰落信道，即假设信道衰落系数在一个长度为 n 的资源块上保持不变。基站第 l 个天线的接收信号可表示为：,(),anlk lklkhyxzK(3-1)其中，,(0,1)k lh CN表示第 k 个用户和第 l 个接收天线之间的信道衰落系数；lz表示加性高斯白噪声；()kx表示第 k 个用户传输的码字，当第 k 个用户活跃时，该用户发送的信息服从均匀分布。当信道衰落系数为 1 时，该信道模型退化为高斯多址信道。假设接收端分别在 CSIR 和 no-CSI 两种情况下进行译码，将为第 k 个用户检测到的码字记为kW。随机接入码的定义如下：定义定义 1.令CSIR,no-CSIi，随机接入码(,)in MP包括：1)编码函数将用户k的信息映射成码字，且码字功率不超过 nP。2)在 CSIR 情况下，接收机利用接收信号和信道衰落系数进行译码；在 no-CSI 情况下，接收机利用接收信号进行译码。译码函数满足平均每用户误差概率约束：1.PaekkkaPWWKK(3-2)令bEnP J表示每比特能量。为保证存在随机接入码(,)in MP，将系统所需最小的每比特能量记为*,b iE。3.1.2CSIR 理论界定理 1 给出了 CSIR 情况下的可达性能界：定理定理 1:在多天线准静态瑞利衰落信道中，当用户的信道状态信息已知时，为满足大维随机接入的平均每用户误差概率准则和最大功率约束所需要的最小的每比特能量满足：*,CSIR(,)inf,ubnPEn MJ(3-3)其中，inf 针对满足01,2,01minmin 1,auKttPPtatpppK的uP取极小值。该定理通过发送端采用随机编码方案以及接收端采用最大似然译码方案得到。上述条件中包含两部分：第一部分 p0表示不满足功率约束的概率的上界，利用联合界和卡方分布的性质求得；第二部分表示没有功率约束的情况下平均每用户误差概率的上界，其中 p1t和 p2t表示共有 t 个用户传输的码字译码错误的概率，分别采用 Gallager-指数的方法以及费诺界41求得。定理 2 给出了 CSIR 情况下支持用户随机所需每比特能量的逆定理。定理定理 2:在多天线准静态瑞利衰落信道中，当用户的信道状态信息已知时，为满足大维随机接入的平均每用户误差概率准则和最大功率约束所需要的最小的每比特能量满足：*,CSIR(,)inf,lbnPEn MJ(3-4)22log,EtHLttaaatnJhPtKKKHIH H(3-5)其中t LtH中的元素服从 i.i.d.(0,1)CN分布。此外，单用户情况下的逆定理也可作为多用户情况下的逆定理理论界。15IMT-2030(6G)推进组IMT-2030(6G)Promotion Group该逆定理主要包含两部分。多用户情况下，公式(6)主要采用费诺不等式和互信息链式法则等求得。单用户情况下的逆定理主要基于文献36中的 meta-converse 定理得到。此外，假设有 Ka个活跃用户，当Ka-1 个活跃用户的信道衰落系数和发送的信息已知时，检测 Ka个发送信息的问题可以退化到单用户的问题。因此，多用户情况下所需要的每比特能量会多于单用户情况下所需要的每比特能量，即单用户情况下的逆定理也可作为多用户情况下的逆定理理论界。3.1.3No-CSI 理论界本节针对接收端已知信道分布但不知道信道衰落系数的场景，分别分析了支持用户随机接入所需每比特能量的可达界和逆定理。定理 3 给出了 no-CSI 情况下的可达性能界：定理定理 3:在 no-CSI 多天线准静态瑞利衰落信道中，为满足大维随机接入的平均每用户误差概率准则和最大功率约束所需要的最小的每比特能量满足：*,no-CSI(,)inf,ubnPEn MJ(3-6)其中，inf 针对满足001minmin 1,auKPPttatppK的uP取极小值。与 CSIR 的情况类似，no-CSI 情况下仍采用随机编码和最大似然译码。二者的区别主要在于似然函数不同，因此在利用费诺界求共有 t 个用户的码字译码错误的概率时，选取的接收信号以较大概率分布的区域也有所不同。但求可达界时采用的基本工具仍然相似，均为费诺界、Chernoff 不等式以及二次型矩生成函数等。定理 4 给出了 no-CSI 情况下支持用户随机所需每比特能量的逆定理。定理定理 4:在 no-CSI 多天线准静态瑞利衰落信道中，为满足大维随机接入的平均每用户误差概率准则和最大功率约束所需要的最小的每比特能量满足：*,no-CSI(,)inf,lbnPEn MJ(3-7)其中，inf 针对满足以下两个条件的功率0lP求极小值：（1）当码本矩阵aan KKX中的元素服从 i.i.d.均值为 0 方差为 Pl的分布时，应满足：222log11log,EKaaaaalHKKKaanLK PLJhKKXIXX(3-8)（2）单用户有限长逆定理表明：21,(2)(1(1)PlMLnP r(3-9)其中，r 表示2(2)PLr的解。该逆定理包含两部分。第一部分基于高斯码本的假设利用多用户费诺不等式求得。不同于 CSIR 的情况，由于 no-CSI 假设下存在信道的未知性，发送码字集合和检测码字集合之间的互信息较难求解，因此条件一加入了高斯码本的假设降低计算难度。第二部分利用单用户情况下的逆定理得到，适用于所有类型的码本3.1.4数值计算结果对定理 1 到定理 4 的结果进行数值计算。在图 3-2 中，假设码长 n=1000，天线数 L=32，数据量 J=100 bits，活跃用户数 Ka=400，以及误差要求0.001，仿真了 CSIR 和 no-CSI 情况下可支持的活跃用户数随每比特能量的变化情况，以及文献36和42给出的 TDMA 方案的理论性能和文献43提出的实际方案的性能。从结果可知，在 CSIR 情况下，可达界和逆定理之间的差距小于 2.5 dB；当活跃用户数小于 500 时，可达界和逆定理之间的差距小于 4 dB。因此，该理论界能够比较准确地衡量实际系统的性能极限。此外，在多天线衰落信道中，当活跃用户较少时，存在多用户干扰消除现象，即当用户数小于某个门限时，不16IMT-2030(6G)推进组IMT-2030(6G)Promotion Group需要额外增加每比特能量即可满足误差要求。但是，传统的 TDMA 方案没有多用户干扰消除的效果，且在用户较多的情况下性能较差。文献43中提出的基于协方差的实际方案在用户较多的场景中优于 TDMA方案，但仍与理论界有较大差距。因此，现有大维随机接入方案的性能仍有较大的提升空间。图3-2活跃用户数随每比特能量的变化在图 3-3 中，假设码长 n=1 000，数据量 J=100 bits，每比特能量 Eb=10,20dB，活跃用户数 Ka=400 以及误差要求0.001，分别仿真了 CSIR 和 no-CSI 情况下总频谱利用效率和天线数的关系。从结果可知，在 CSIR 的情况下，总频谱利用效率随天线数近似线性增长；在 no-CSI 的情况下，由于信道的不确定性，总频谱利用效率随天线数的增长速度由快变慢，即平均每天线的频谱利用效率随天线数的增加逐渐减小。(a)CSIR(b)No-CSI图3-3频谱利用效率随天线数的变化3.2 基于随机几何分析免调度叠加传输理论性能界针对 NOMA 的系统设计与网络部署问题，可以利用随机几何(Stochastic Geometry)理论建模并分析免调度（Grant Free NOMA,GF-NOMA）系统，从而推导出 GF-NOMA 系统在随机几何模型中的用户检测成功率和信道估计误差的解析表达式4444。因为 NOMA 的理论性能界依赖于的激活用户的检测成功率与输入相干解调的信道估计值，因此，文献44给出的性能分析结果可以用于判定 NOMA 多用户检测算法的可行性，对 NOMA 设计与具体网络部署有指导意义。考虑如下的网络几何分布模型：基站位于一个内径为0D、外径1D为的圆环的中心，J个用户均匀随机散布于圆环内。每个用户与基站距离r的 CDF 为 2222(),01001rDDDFrDrDr。因此，r的概率密度函数（PDF）为17IMT-2030(6G)推进组IMT-2030(6G)Promotion Group012210d2()(),.drrrfrF rDrDrDD(3-10)令ACTP表示每个用户在每个时隙内活跃的概率。由于用户数1N 很大并且ACTP通常很低，因而可以将用户的分布看成是密度为ACTNP的二维齐次泊松点过程（Homogeneous Poisson Point Process，HPPP）。信道模型采用幂律路径损耗模型。第j个用户的信道增益为2jj jhr。其中，exp(1)j表征瑞利衰落，是路径损耗常数，jr是用户到基站的距离。为分析 GF-NOMA 中的用户检测成功率，可将基于非正交导频的多用户检测问题构造成一个压缩感知稀疏信号重构问题，令 SuppK q表示活跃用户数，Suppminminnnqqq表示所有的活跃用户中到基站的信道响应的幅度的最小值，推导出用户检测成功率succP的公式（定理 5）。选取系统仿真参数为：小区内径 r0=10 米，外径 r1=150 米，前导码长度 L=120，每个子信道上的噪声功率2110dBm，用户总数 J=240，用户活跃率ACT0.1P，用户发送功率 P=20 dBm。图 3-4验证了定理 5 给出的 GF-NOMA 系统检测成功率，分别展示PERP随用户发送功率P和用户总数 N 的变化趋势。为更清晰展示在 0.9 1 的趋势，以对数坐标呈现。作为对比，图 3-4 分别给出的门限辅助子空间匹配（Threshold-Assisted Subspace Pursuit，TA-SP）算法和稀疏贝叶斯学习（Sparse BayesianLearning，SBL）算法45 46的性能，以及 DGOMP 算法44性能。图3-4CS-GF-NOMA系统的检测成功率。(a)与P的关系；(b)与N的关系18IMT-2030(6G)推进组IMT-2030(6G)Promotion Group第四章第四章海量多址接入关键技术海量多址接入关键技术目前，支持海量连接的多址接入技术主要有如下几大技术路线，包括：稀疏 IDMA（Interleaver divisionmultiple access）和压缩感知的结合、级联码方案、编码压缩感知以及基于线性扩展和盲均衡的方案。4.1 稀疏IDMA 压缩感知4.1.1系统架构稀疏 IDMA 压缩感知是无源随机接入的重要技术方案。其核心设计思想结合两项技术，第一项技术是基于压缩感知的导频编码，为了支持无物理层标识传输，需要指示用户独特信息，组成一个很大的码本，码本序号经过压缩感知映射成为较短的导频，附加在数据部分之前。第二项技术是稀疏 IDMA 叠加编码，通过比特重复和填零来提高抗多用户干扰的能力，通过使用不同交织器来区分用户并随机化多用户干扰。图4-1稀疏IDMA的系统架构图 4-1 是稀疏 IDMA 的系统架构，第一部分进行导频编码。导频编码的一种方式是采用 FFT 矩阵，将正交矩阵（Fourier transform 或 Hadamard 矩阵）的行随机交织后打孔，得到一个长度较小的序列作为导频编码。第二部分进行稀疏 IDMA 编码。在接收端，导频与 IDMA 码字分开译码，先通过导频恢复交织图样、比特重复次数、填零数目，再做数据部分多用户检测，最终将两部分信息译码结果拼合得到用户的完整发送信息。19IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图4-2基于LDPC码的稀疏IDMA的编译码原理以两个用户 MAC 系统为例，稀疏 IDMA 的编译码原理如图 4-2 所示。用户 1 和用户 2 都是采用同样的 LDPC（Low density parity check code，低密度校验码）码进行编码，它们各自的校验节点到变量节点的因子图是相同的。用户 1 经过 LDPC 编码之后没有重复，只是补 0，所以因子图中相应部分的边数没有增加。用户 2 经过 LDPC 编码之后重复 2 次，因子图相应部分的边数加倍。比特交织之后，因子图的边的分布进一步随机化。两个用户分别的因子图通过 MAC 叠加节点联系起来，构成一个三层的整体因子图。整个因子图的配置信息，包括重复次数和交织图样都是通过导频的压缩感知恢复算法解出。稀疏 IDMA 信道编码也可以采用其它编码，如卷积码、不规则重复累积码、NBLDPC（Non-binary lowdensity parity check、多元低密度校验码，详见 4.4.2 节）编码。由于这里使用迭代检测，需要信道编码的译码器能提供软入软出的译码信息。5G 所采用的极化码在短码长约束下存在信道极化不完全的问题，导致传输性能受限，因而需要级联CRC（Cyclic redundancy check）码弥补性能上的局限。然而，CRC 校验的极化码与无源多址结合时，需抵消额外的串行干扰，增加处理时延开销及复杂度。为解决上述问题，极化调整卷积编码（polarization-adjusted convolutional codes，PAC）53通过引入级联编码，可以在短码长约束下获得更好的传输性能。因而可以将 PAC 码与无源多址技术相结合54，在有效提高纠错性能的同时，降低实现复杂度，其编码以及译码过程如图 4-3 所示。(a)编码框架20IMT-2030(6G)推进组IMT-2030(6G)Promotion Group(b)译码框架图4-3基于极化调整卷积编码的稀疏IDMA编译码框架4.1.2接收机算法多用户检测稀疏 IDMA 的多用户检测通常包括检测器和信道译码两部分，彼此之间进行信息传递，形成迭代检测。其中的检测器可以采用 Elementary Signal Estimation（ESE）算法或者置信度传播（Belief Propagation，BP）。ESE 或 BP 检测器的转移函数可以写成，其输入是译码器的软信息输出，输出为对数似然比（Log-Likelihood Ratio，LLR）。信道译码器的转移函数可以表示成，其输入是对数似然比，输出为信息比特的软信息。可以通过和之间的 EXIT（Extrinsic InformationTransfer，外信息传递图）图来分析稀疏 IDMA 的收敛性。图 4-4 左边的曲线位于左边，两条曲线不交叉，可以形成演进通道，成功完成迭代检测；而图 4-4 右边的曲线与有交叉，演进通道被堵死，不能成功完成迭代检测。从图 4-4 的分析可以看出，稀疏 IDMA 的译码器特性需要与检测器的特性相匹配，才能迭代收敛。传统的信道编码通常是针对单用户信道进行优化的，虽然在单用户（正交多址）下性能优异，但其迭代译码特性不一定能与多用户检测器匹配，需要采用新的方法进行设计。图4-4稀疏IDMA的和EXIT分析激活用户检测与信道估计压缩感知（Compressed sensing，CS）可有效检测稀疏信号的数值，用于多用户激活检测及信道估计。压缩感知的核心是信号在某个变换域是稀疏的，可以用一个与变换基不相关的观测矩阵将变换所得信号投影到另外一个信号空间上，通过不断的迭代检测来完成对原始信号的精确估计。为简化计算复杂度，可以采用近似消息传递 AMP 算法，该算法需两个假设，一是消息从因子节点到变量节点是近似高斯，二是消息从变量节点到因子节点可以用 Taylor 展开来近似。对压缩感知系统而言，发射信号是感知矩阵和稀疏矢量的乘积。AMP 算法收敛需要假设感知矩阵足够的随机化。感知矩阵除了Gaussian 独立同分布（Independent identical distribution,i.i.d）的矩阵，其它很多正交矩阵，例如部分随机离散傅立叶变换（partial random Discrete Fourier transform），离散余弦变换(Discrete cosine transform)矩阵，都可以用作压缩感知矩阵。21IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图4-5基于压缩感知的迭代检测图 4-5 是一个用 Turbo 压缩感知检测的例子48。Turbo 压缩感知包含两部分。模块 A 是一个线性最小均方误差（minimum mean square error，MMSE）估计器，输入是接收信号 y 和模块 B 的输入。模块 B 通过合并 x 的先验信息和模块 A 的输入进行 MMSE 去噪。信息在两个模块间不断迭代以得到更精确的 x 值。迭代次数与用户数，导频长度和感知矩阵维度的大小有关。通过控制迭代次数，可以控制计算的复杂度。降低感知矩阵的维度也可以有效降低计算复杂度。AMP 算法存在某些条件下不收敛的缺点，基于此，正交近似消息传递（OAMP）被提出4950。通过正交化输入估计误差和输出估计误差，OAMP 在奇异信道(如相关信道，低秩信道)取得比 AMP 更优的性能。但 OAMP 里有 MMSE 矩阵求逆操作，复杂度较大。为能够实现低复杂度且高可靠地恢复信号，采用记忆近似消息传递（MAMP）接收机5152，如图 4-6所示，MU-MAMP 接收机由记忆线性检测器（memory linear detector,MLD）和非线性检测器（Nonlineardetector,NLD）组成，其中 MLD 采用长记忆匹配滤波器（LM-MF）来代替 OAMP/VAMP 接收机中最小均方误差（LMMSE），并在 NLD 采用阻尼来保证和加速收敛。111MLD:()()NLD(),()tttttttttttttttp线性检测非线性检测rXXXxrXr:其中1,.,ttXxx，11()()()HHtttttttyXAXAAx，HIAA，minmax()/2。min和max分别是矩HAA的最小和最大特征值。此外，松弛参数t和权重参数t可用来提高MU-MAMP 接收机的收敛速度。图4-6MAMP接收机在 MAMP 中当前输出估计错误与所有输入估计错误正交。MAMP 不需要矩阵求逆也可以取得和OAMP 一样的性能，因此，具有较好的应用前景。其缺陷是要求感知矩阵维度较大(压缩感知矩阵列数大于 500)，对于维度较小的 MIMO 系统(列是 16 到 128)使用这种方法有一定的困难。另外，在用户采用非正交方式免授权/免调度接入时，尤其是小数据包场景下，导频长度较短将使得用户激活检测与信道估计性能受限。此时，可以利用用户传输的数据信号与导频信号结合，在两者打包共同传输的模型下，构建深度神经网络以实现对数据信号与导频信号进行联合信息提取，增强用户激活检测与信道估计性能。在神经网络的结构设计中，设计了两个模块 PDNN（Privacy-aware distributed neuralnetworks）和 DDNN（Distributed deep neural networks）分别对导频信号及数据信号进行信息挖掘，更借鉴了传统压缩感知技术中的迭代检测思想，通过引入多个相似结构信号处理单元，以迭代形式依次增强上一单元输出结果，最终提升估计结果的准确性。4.1.3初步仿真结果基于 LDPC 和卷积码的单时隙稀疏 IDMA 方案仿真结果表4-1单时隙仿真参数配置参数配置信道AWGN（Additive white Gaussian noise）调制BPSK（Binary phase shift keying）信道编码LDPC 5G NR,convolutional code（CC）133,22IMT-2030(6G)推进组IMT-2030(6G)Promotion Group171OCT重复次数2码率0.5压缩感知数据长度2000多用户数据传输长度28000信息比特长度（压缩感知 数据）13 87激活用户数50300表4-2Case I，II 和 III参数配置Case ICase IICase IIISNR1=-12.8 dB,SNR2=-2.3 dB,真实用户激活检测和信道估计SNR1=-10.8 dB,SNR2=-3.3dB，真实用户激活检测和信道估计SNR2=-3.5dB，理想用户激活检测和理想信道估计图 4-7 给出了用户激活检测错误概率和 FFT 点数的关系。FFT 点数越大，用户激活检测性能越差。此处仿真没有考虑用户导频碰撞，仅考虑压缩感知进行信号检测的性能。图 4-8 左图给出了单用户使用 LDPC 码和卷积码的性能，可以发现卷积码有明显的性能增益。卷积码的误码率（BER）更小意味着用于多址时多用户干扰更小，因此可以取得更好的性能。图 4-8 右图给出反映软入软出译码器特性的 f()函数和反映检测器特性的 g()函数。稀疏 IDMA 由于在每个用户传输的信号里填入大量的零使得用户间干扰大大降低。当激活用户数是 250，每个资源上叠加的平均用户数大概为K=6；当激活用户数是 200，K=4。当 K=6 时卷积码的 f()函数不与 g()函数相交，表明此时使用卷积码可以迭代收敛。而 K=6 时 LDPC 码的 f()函数与 g()函数在 v 接近 1 的时候相交，表明此时使用 LDPC不能迭代收敛。当 K=4 时 LDPC 码的 f()函数与 g()函数在 v 接近 0.05 的时候相交，表明此时使用 LDPC可以迭代收敛。图 4-9 左图给出了真实用户激活检测和信道估计的性能。对 Case I，SNR1 是-12.8 dB，即压缩感知信号的信噪比是-12.8 dB，此时 250 个用户发现了 249 个。Case II 中 SNR1 增大到-10.8 dB，可以发现所有 250 个用户。为使多用户检测能迭代收敛，Case I 时数据信号的信噪比 SNR2 是-2.3 dB，case II 时 SNR2是-3.3 dB。Case II 需要的信噪比更低。图 4-9 右图给出了 Case I，Case II 和 Case III 迭代收敛的性能。其中 Case III 是理想用户激活检测和信道估计。真实信道估计时由于每个用户信道增益不一样，使得迭代检测时收敛速比理想信道估计时更快。图4-7错误检测概率与FFT大小关系，激活用户数是30023IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图4-8卷积码和LDPC性能比较图4-9真实信道估计及其性能基于 LDPC 的多时隙稀疏 IDMA 方案仿真结果表4-3多时隙仿真基本参数配置参数配置总帧长45000单时隙长度1500用户载荷长度100LDPC 编码配置5G NR BG2IDMA 调制阶数BPSK用户平均错误概率（PUPE）要求0.05超容限概率 p0.05表4-4碰撞容限和重复度分布的参数设置活跃用户数aK500300时隙数V30碰撞容限T469111315重复度分布321/43/4xx2x27/92/9xx 22/119/11xx 211133/12/xx 24/51/5xx 仿真结果图 4-10 所示。选取的对比方案均为单时隙编码方案，例如在整个帧上稀疏扩展的稀疏 IDMA方案13，而 BCH（BoseChaudhuriHocquenghem）为级联 BCH 码方案55，并根据3给出巨址接入可达的最佳性能界。纵向观察，多时隙方案对于对比 BCH 方案能够提升 6 dB 以上的系统能效；相对于 Sparse24IMT-2030(6G)推进组IMT-2030(6G)Promotion GroupIDMA 方案，多时隙方案在每个时隙的译码复杂度较低。表 4-4 中的用户重复度分布暂未进行优化，其性能仍有进一步提升空间。BCH 方案由于编码效率低而且依赖于信道等效，在用户数很大、密集碰撞的场景下性能迅速恶化。图4-10SNR门限随活跃用户数的变化关系基于极化调整卷积码的单时隙稀疏 IDMA 方案仿真结果仿真性能如图 4-11 所示。其中，信息比特总长度为|w|=|ws| |wc|=7 64=71，信道编码后的长度为 128。译码器为串行抵消列表译码（Successive Cancellation List，SCL），其搜索宽度为 L=256。作为对比，还进行了极化码为信道编码的仿真性能，极化码在编码时添加 8 位 CRC，序列长度为 128。可以看出，基于 PAC 码的稀疏 IDMA 性能明显优于基于 Polar 的。而且避免 CRC 校验的同时，在译码阶段也避免串行干扰消除过程，从而减少了额外的时间开销，同时降低实现复杂度。图4-11基于极化调整卷积码的稀疏IDMA仿真性能基于 AI 的接收机仿真性能在图 4-12 仿真中，分别在天线数为 4 和 1 的场景展示 PDNN 和 DDNN 相比传统压缩感知方案 AMP、OMP、全连接神经网络 FCNN 方案的用户激活检测性能的优越性。25IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图4-12用户激活检测仿真性能对比4.2 线性扩展类的传输基于符号级线性扩展的方案是发射端通过对调制后的数据符号进行扩展，如图 4-13 所示，不同用户选用非正交的扩展码本，将扩展后的数据叠加在同一份时频资源上进行传输的，而在接收端，通常采用干扰消除算法进行串行或者并行译码，其主要原理是利用各用户对应的扩展序列进行相关解扩，达到抑制用户间干扰的效果，从而使得强用户（接收信干噪比较高）的信号能够优先译码，接着将译码正确的用户数据进行重构并从叠加的接收信号中消去，进而可以提升剩余弱用户数据的信干噪比，然后对弱用户进行译码尝试。图4-13线性扩展随机接入多址发射机4.2.1基于码域空域联合扩展的无连接传输非正交技术通过允许不同用户信号不完全正交，增加信号的多样性，使得用户间干扰更平均，尽可能减少严重到不可分离的用户间干扰的出现，从而让多用户性能更鲁棒。进一步，先进的非正交多用户检测技术，通过一定的复杂度代价，可以在严重的多用户互扰下依然能确保检测的性能。因此无连接传输需要先进的非正交发射和接收技术。但是，传统的非正交收发技术都需要依赖导频去获取不同用户数据信号的差异性，然后才能利用这些差异性去分离用户的数据；然而在无连接传输场景，导频严重碰撞下，基站难以利用碰撞严重的导频去估计数据信号的差异性，实现多用户检测。因此，高效无连接传输需要进一步考虑可以少依赖导频甚至不依赖导频的先进非正交技术。非正交技术的多用户复用能力可以来自功率域、码域和空域。功率域26IMT-2030(6G)推进组IMT-2030(6G)Promotion Group无连接传输由于没有基站等中心的控制，因此无法实现精确的功率控制，导致远近效应，这也自然提供了一个在功率域上分离多用信息的能力。例如，如果两个用户的信号到达基站处一强一弱，基站就可以先解调译码功率较强的用户的信息，然后将信息重构回传输信号，进而可以从接收的合信号中消除强用户的信号；这样解调弱用户信号时，就没有强用户的干扰了。码域利用码域扩展的无连接传输中，发射端随机挑选扩展码字，接收端利用扩展码来降低用户间干扰，提升符号信噪比。扩展序列的属性会直接影响无连接传输的性能和接收机复杂度，是码域扩展方案的关键。如果像传统 DS-CDMA（Direct sequence code division multiple access)那样使用很长的伪随机序列（PN,pseudo noise），序列之间的低相关性是比较容易保证的，而且可以为系统提供一个软容量，即允许同时接入的用户数量大于序列长度，这时系统相当于工作在过载的状态。长 PN 序列虽然可以提供一定的软容量，即一定的过载率，但是在巨连接系统需求下，系统过载率往往是比较大的，而在大过载率的情况下，采用长 PN 序列所导致的 SIC 过程是非常复杂和冗长的。进一步，发射侧符号的时频展开太多，也增加终端发射的复杂度。相反，如果较短的序列，通过优化设计，也能达到长序列的高过载率的话，那从发射接收复杂度和处理时延考量，使用这样的短序列更合适。然而，传统 PN 序列是二元实序列，随机产生的序列集合的低互相关性难以保证，缩短后所能支持的用户过载率迅速降低。相对的，好的码域扩展方案都是通过优化符号扩展序列来提升码域方案在竞争式非正交下的性能。其中 eMUSA（Enhanced multi-user shared access）技术方案使用复数域多元码序列作为符号扩展的序列757，使得扩展序列的组合变得更加丰富，例如，典型的 eMUSA 序列中每一个元素的实部/虚部取值于一个简单的二元集合-1,1或三元集合-1,0,1。此类序列即使很短时，如长度为 8 或 4 时，也能获得大量低相关的序列。例如长度为 4 的序列，PN 序列最多只能找到 8 条不同的序列；而 eMUSA 序列，互相关能量（即互相干扰的能量）小于 0.63 的序列多达 156条，能很大程度上避免碰撞，从而实现很好的用户间干扰随机化的效果。再结合高效的串行干扰消除（SIC）接收机，eMUSA 可以支持数倍于扩展码长度的节点通过自主选取扩展序列在相同的时频资源传输。空域基站部署 M 根接收天线时，不同用户的 M 维空域信道矢量通常不是完全相同的，这点提供了多用户复用能力。形象地看，多天线基站可以形成不同的接收波束去接收不同用户的信号。这样就算不同用户的达功率相同，扩展码也相同，只要这些用户的空域信道有一定的差异，基站还是有可能通过空域分离他们的。巨连接场景出现导频碰撞的概率非常高。为尽可能减少导频碰撞，通常做法是数倍地增加导频的数量。但是传统检测技术要依赖导频去估计信道、时偏和频偏，这要求每个导频在整个时频资源上分布足够多的参考符号，最终导致导频开销显著增加，甚至出现导频占用时频资源超过数据包的情况。进一步，基站进行多用户检测时，需要对大量长导频进行检测，复杂度也会显著增加。为减少导频开销和复杂度，需要考虑少依赖甚至不依赖导频的先进检测技术，确保无连接传输下依然可以充分利用空域，码域，功率域多用户复用能力来支持巨量连接。eMUSA Data-only 技术5657以及超低碰撞导频技术5859反转了传统检测顺序：先利用空域码域功率域进行干扰抑制，再利用干扰抑制后的数据符号来估计信道，进而均衡、解调译码。如图 4-14 所示。即使大连接高负载场景，通过空域码域功率域干扰抑制后的数据符号的信干噪比仍然较高，可确保信道估计性能。其中Data-only技术通过挖掘各个用户接收数据符号的统计特性和几何特性来实现高效的盲检测。其中最主要的部分是分区匹配法,如图 4-14 所示,即基于调制符号星座图的几何特点，来估计整个传输资源上的信道以及时频偏。低阶调制符号，例如 BPSKQPSK,对应的星座图都具备简单的几何形状，即使接收到的调制符号经过了信道的畸变，所对应的星座图也只是经历了旋转缩放，几何形状依然比较简单。27IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图4-14分区匹配法（Partition Matching Method）eMUSA 超低碰撞导频技术的主要思想是应用 Data-only 技术，利用数据调制符号去完成大部分信道估计任务，这样可以让导频的估计任务最小化，数量最大化，碰撞最少化。具体而言，超低碰撞导频技术中，导频只需负责空域合并权值的估计，而不用估计多径选择性衰落，也不用估计时频偏。eMUSA 超低碰撞率导频技术具体如图 4-15 所示。作为对比，传统的导频需要估计整个时频资源的信道，因此导频符号需要铺满整个时频资源，开销很大，可以说是稠密分布的。而应用 Data-only 技术后，每个导频可以只需估计一个时频位置上的信道，这个估值量通常用于多天线空域合并权值的计算，而剩下的信道估计任务通过数据调制符号来完成，因此，每个导频可以只占用一个时频位置，这样的开销是最小化的，也可以说是最稀疏的。相同的导频开销下，极稀疏导频方案可以让导频数量最大化，导频碰撞最小化。进一步，传统数据传输帧中，通常只有一个导频，这个导频碰撞了就没办法准确检测了。eMUSA超低碰撞导频技术另一个主要部分是独立多导频技术：一次传输中包含多个导频，并且导频之间独立无关的。不同用户的独立多个导频同时碰撞的概率会比传统单导频小很多，如下图所示。基站通过迭代的多用户接收机，每轮都可以通过那些没有碰撞的导频解出对应的用户数据，然后将其数据和导频都重构出来并从接收信号中消除掉，如此迭代直到解出所有可解的用户。图4-15超低碰撞率导频eMUSA 无连接传输不仅仅可以应用于基于蜂窝的物联网场景，还可以应用到更广泛的场景中，例如V2V 通信场景中。高密度车联网的信息传输，具有海量和突发两个特点，而车联网信息传输又有低时延高可靠的需求。在海量、突发的信息传输场景要满足低时延高可靠的需求是非常大的挑战。进一步，由于车辆节点的快速移动,导致车联网网络拓扑迅速变化，使得海量、突发、低时延、高可靠这些通信需求同时满足更为困难。eMUSA 无连接传输方案充分利用 V2V 传输的特点，实现一种非常高效的 V2V 传输方案，充分利用下面两个特点：1）车辆体积比一般通信终端大得多；2）越近车辆的信息越重要。将收发天线尽量分离放置，以使得即使完全不进行自干扰消除，全双工的自干扰也不会比目标信号大很多。进一步，eMUSA 无连接传输可以无连接下充分利用空域/码域/功率域的多用户复用能力，并将全双工的自干扰当成是目标信号来处理，实现了全双工下的无连接传输的高可靠性。而且这样可以不用额外增加自干扰消除模块，进一步简化全双工 V2V 通信。通过结合 eMUSA 无连接传输技术和高效全双工技术，可以允许大量车辆终端无需先听后发，直接交换信息；并且避免传统技术的漏收和隐藏节点问题；最终28IMT-2030(6G)推进组IMT-2030(6G)Promotion Group实现超低时延和超高可靠性的 V2V 直接通信。仿真结果显示，对于高密度车辆网场景，eMUSA 的传输时延仅是传统方法的 1/51/10，而可靠性提高 13 个量级60。4.2.2基于立方分割码本考虑一个具有 K 个独立用户的 mMTC 场景，每个用户的信道编码方案为 LDPC 编码。系统的发射机如图 4-16 所示。用户将初始数据比特添加 CRC 后进行码块分割，随后进行 LDPC 信道编码和码率匹配。将码率匹配后的比特流通过单用户立方分割码本进行码字映射，并将得到的码字进行线性扩展。扩展后的码字在选择扩频图案后进行扩频，这些符号形成用户发送的数据包。图4-16发射机系统框图根据线性扩展矩阵和扩频图案表的设计，接收方先对接收到的数据进行解扩从而进行用户扩频图案重建，恢复出每个符号单元所使用的扩频图案。随后，再根据线性扩展矩阵的设计，反解出每个用户的数据符号。在得到用户的数据符号后，通过计算对数似然比进行 LDPC 软解码，并进行 CRC 校验。将通过 CRC 校验的用户，利用基于最小二乘的信道估计，对解码信号进行重构，消除已解码符号对未通过CRC 校验的用户影响。对多用户传输时使用立方分割码本的性能进行仿真，仿真参数如表 4-5 所列。表4-5多用户单天线系统传输性能仿真参数参数参数设置设置载波频率700MHz信道编码LDPC 编码（16bit CRC，译码迭代次数 25）参数集子载波间隔 15 kHz，14 个 OFDM 符号系统带宽1.08 MHz用户数4用户传输包大小10 字节/20 字节/40 字节/60 字节/75 字节码本参数D=4,B=1公共扩频池/导频复正交序列扩频序列/导频长度4扩频图案表行数20信道类型瑞利信道图 4-17 所示为传输包大小为 10 字节时的系统的误比特率曲线仿真结果61。可以看出，基于线性扩展的传输方案在信噪比较高时对比基于导频估计的传输方案存在约 46 dB 的性能增益，在理想扩频图案估计的情况下能获得约 26 dB 的性能增益。总体上基于线性扩展的传输方案性能不如基于理想信道估计的正交导频传输方案，这说明基于线性扩展的传输方案主要性能增益来源于较小的信道估计误差。29IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图4-17传输包大小为10字节时系统误比特率性能仿真4.2.3级联式线性扩展码本两个扩展码本级联的构造原理如图 4-18 所示。可以看到，级联备选组中码本序列个数W越大，新生成的码本S码池将越大。对于新构造的扩频序列S，前L位是原扩频序列，后L位是级联备选组序列。图4-18两个扩展码本级联举例结合该码本构造方法的设计准则，考虑一种“串行”分阶段级联检测的方法，即通过两轮检测 将 SINR较大的扩频序列挑出。具体地，对于利用扩频序列长度为 L 码池大小为 N 的码本生成新的构造码本，其中扩频序列长度变为原先的 2 倍，即 2L，码池大小变为 NW。第一阶段，利用自相关矩阵的逆矩阵的左上角 LL 矩阵对 L 长 N 大小的原扩频码本序列进行遍历，从 N 条原始序列中挑选出 SINR 最大的 M1条，即确定了用户前 L 位的扩展序列；第二阶段，在第一轮挑出 M1条扩频序列的基础上，利用自相关矩阵的逆矩阵对 2L 长 M1W 大小的构造码本池中的序列遍历，进而挑选出译码成功可能性最大的 M2条。最终利用这 M2条激活的扩展序列进行后续的解扩、均衡、译码等。相比于传统方法使用自相关矩阵对 2L 长 NW 大小的构造序列中遍历进行盲激活序列检测，此方法可以使计算复杂度大大降低。30IMT-2030(6G)推进组IMT-2030(6G)Promotion Group4.2.4基于模式分割的随机接入方案针对 mMTC 场景下的导频碰撞问题，考虑模式分割随机接入(pattern division random access，PDRA)设计原则47，即基于“图样叠加”的模式域导频，将导频竞争空间扩展到模式域，在不增加物理资源的前提下扩大导频竞争空间，并且接收端可以低复杂度实现“部分碰撞”判决，降低导频碰撞概率，提高接入成功率，3GPP 4G/5G 系统中每个导频序列由具有不同循环移位和根索引的 ZC（Zadoff-Chu）序列生成，用户在公用导频池中随机选择一个导频序列发送至基站进而发起 RA 请求。以 ZC 序列为例，将模式域导频构造为同一 ZC 根序列的循环移位序列中任意 L 个不同序列的叠加，假设单一 ZC 根序列构造的导频集合大小为 NSS，对于根序列号为 u 的 ZC 序列 au，其构造的第 j 个模式域导频表达式为：,11,0,1,01lLu ju vlSSPSlvNjNLsa(1)其中，SSLPSNNC为一个根序列构造出的模式域导频大小，,lu va为根序列号为u的ZC序列循环移位后生成的序列，表示为：,mod,01 allu vu vulCSZCZCaiaiv NNiN(2)其中，CSN表示循环移位间隔，(01)lCSlSSv NvN表示循环位移值，ZCN为序列长度。假设 ZC 根序列总数为 R，则模式域导频集合的大小表示为PPSNRN。与传统 ZC 序列导频集合大小SSN相比，模式域导频集合大小扩大了SSSSLLNNSSSSRCCRNN倍。对于接收端，基于模式域导频的设计使基站可以在用户间只有部分碰撞时仍可以判决出用户的信道，从而实现接入请求。以 19 个正六边形蜂窝小区组成的通信场景进行仿真，图 4-19 给出不相关瑞利衰落信道下，激活概率为 PA=0.15%时，RA 成功概率 PMF随 ZC 根序列数 R 的变化曲线。从图中可以看出，随着 NSS的增大，传统 RA 方案和 PDRA 方案的 RA 成功概率均有所提高，但 PDRA 方案性能更好。另外图 4-19 中 R3 时 PDRA 方案在 NSS=32 时的性能甚至优于传统 RA 方案 NSS=64 时性能，这是因为模式域导频通过扩大导频竞争空间有效缓解导频碰撞。图4-19不相关瑞利衰落信道下PMF曲线4.3 多段编译码4.3.1压缩感知采用切块树编码与压缩感知编码的级联结构，如图 4-20 所示，用户的子块编码结果分别映射到多个31IMT-2030(6G)推进组IMT-2030(6G)Promotion Group时隙上，在每一子块后缀上增加树编码校验比特，组成等长的复合信息，将复合信息映射为 1 个稀疏向量，经过压缩感知映射后发送到时隙上。接收端可进行逐 CS 时隙的译码，解出其上叠加的复合信息（包含数据部分与树编码校验比特），从根节点（无校验）开始，扩展树结构并且根据校验关系找到正确路径，串联起属于同一用户的信息，拼合出各个用户的信息。此外，压缩感知编码可以与波束空间结合。具体地，基于编码压缩感知方案，设计基于硬判决和软判决的波束空间树译码器。通过利用波束区分特性辅助区分不同用户传输的信息子块，两个译码器可以使得系统可以容纳更多活跃用户。图4-20压缩感知编码的系统架构基于硬判决的波束空间树形译码器使用波束图样匹配的方式提升校验能力，降低在译码过程中搜索的解空间，具有较低的计算复杂度。如图 4-21 所示，波束图样失配的候选路径会被提前剪枝。图4-21基于硬判决的波束空间树译码器的剪枝过程注意到 CS 译码器丢失的任意信息子块都会导致活跃用户的消息序列漏检，使得性能下降。为解决这一问题，如图 4-22 所示，基于软判决的波束空间译码器在译码过程的每个阶段构建因子图并执行消息传递算法，赋予根据校验关系得到的候选信息子块置信值。接着使用列表译码的方式，根据一种路径度量计算每个候选路径的可靠度，并在每个阶段保留一些可靠的路径，最终在最后一个阶段输出幸存的路径作为正确结果。图4-22基于软判决的波束空间树译码器的剪枝过程32IMT-2030(6G)推进组IMT-2030(6G)Promotion Group4.3.2资源跳跃资源跳跃多址（Resource Hopping Multiple Access，RHMA）是一种基于多段编码的适用于大规模免授权随机接入的多址方案。，终端在激活传输时会随机从签名池中选择一个签名来表征自己的信号。然而在信道资源有限的情况下，容易发生用户签名的碰撞。资源跳跃多址针对该问题进行相应设计，其基本思想为：首先与 4.3.1 中的方案类似，将单个时隙内的用户数据包进行分段，但是 RHMA 并非对每个数据段添加冗余比特，而是以数据段为基本单位进行段编码以生成冗余的数据段。之后，包含冗余数据段在内的所有编码数据段将映射至不同的信道资源（扩频序列、子载波等）上，从而以有限信道资源生成大量跳跃图案来表征海量用户身份，并利用冗余段解决用户间的碰撞。方案发射机如图 4-23 所示，该方案与传统发射机不同之处在于其在信道编码之后利用分流器将用户数据比特分成多个数据段，而后利用段编码生成冗余数据段。之后用户根据自己所特定的资源映射图案将每一个编码数据段上的数据符号映射至不同的信道资源上，而后再利用合流器将多个编码数据段合并进行传输。图4-23资源跳跃多址发射机设计方案接收机如图 4-24 所示，当基站接收到数据之后，首先利用分流器将接收数据分成多段，并针对每段检测其在每个信道资源上是否映射有数据，而后根据在所有段上所检测到的信道资源的映射情况，基于资源映射图案码本对接入的激活用户进行识别。用户识别之后，接收机针对每一个识别用户基于其资源映射图案将其所有段上的数据进行解映射，而后进行信道估计、均衡以及解调，并将该识别用户所有段上的数据比特输入到段解码器中解码及合并，输入到信道解码器中。图4-24资源跳跃多址接收机设计另外，接收端可以结合码片级串行干扰消除，以复杂度为代价来提升碰撞解决能力。如图 4-25 所示，当一个用户可以被成功解码时，接收机可以将其数据进行恢复，并从接收数据中减去，如此原先无法被解码的用户中被碰撞的段在下一次就有可能变为无碰撞的段，从而可以让该用户被成功解码。33IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图4-25结合SIC的资源跳跃多址发射机设计若正交信道资源的数量为 q，传统 ALOHA 的签名池规模为 q，但资源跳跃多址可生成的签名池规模为 q2，图 4-26 展示了 ALOHA 在 q=8,64 时以及资源跳跃多址在 q=8 时具有 SIC 和不具有 SIC 时的碰撞解决概率。可以看到，由于资源跳跃多址基于 q=8 可得到规模为 64 的签名池，因而在激活用户数量Ka 小于 8 时，资源跳跃多址的碰撞解决概率与 ALOHA 在 q=64 时的碰撞解决概率一致。此时，资源跳跃多址中用户间数据段的碰撞可以被段编码生成的冗余数据段所恢复。但当激活用户数量 Ka 进一步增大时，段编码产生的冗余数据段不足以恢复用户间所碰撞的数据段，因而资源跳跃多址的碰撞解决能力会出现下降。同时可以看到，资源跳跃多址碰撞解决概率的下降可以利用结合 SIC 的方案进行延缓，当利用 SIC 时，激活用户数量 Ka 在达到 14 时才会出现碰撞概率的下降。因此，资源跳跃多址是通过牺牲用户速率来提升用户在免授权随机接入中的接入可靠性。图4-26ALOHA与资源跳跃多址（RHMA）的碰撞解决概率对比34IMT-2030(6G)推进组IMT-2030(6G)Promotion Group4.4 混合类或其它方案4.4.1基于 Reed-Muller 码Reed-Muller 码可以生成高维度的正交矩阵，如同高维度的 FFT 矩阵，Reed-Muller 码生成的正交矩阵也可以用于压缩感知62。此正交矩阵在无源多址中可以用于用户激活检测和信道估计。利用Reed-Muller码的无源多址方案见图 4-27。用户信息比特是 K，将其中的 K-2p 个比特用于 Reed-Muller 码的编码。图4-27Reed-Muller码无源多址方案该方案使用 2p时隙传输多用户数据。用户 p 个信息比特可用于确定传输时隙的序号（总的时隙数是2p）。为提高用户检测成功概率，每个用户在两个时隙上传输。两个时隙同时检测失败的概率较低，因此，这种策略可以提高用户检测成功的概率。当一个用户信息在时隙 A 被成功检测，其在时隙 B 的信号将被干扰消除，以增加其它用户在时隙 B 的检测成功概率。可以使用用户信息比特的最后 2p 个比特确定用户在两个时隙传输的序号，于是，用户用于 Reed-Muller 码编码的比特数是 K-2p。Reed-Muller 码的用户激活检测和数据检测的算法描述如下63。其中 y 是接收信号，m 是 Reed-Muller 码的阶数，编码后的数据长度是 2m。findPb(y)是 Reed-Muller 码根据接收信号 y 的 Reed-Muller 码译码。译码后得到矩阵 Ps和矢量 bs.。P,b是根据 Ps和 bs进行 Reed-Muller编码后的结果。是长度为 2m的 Reed-Muller 码组成的矩阵，Cs是信道增益，-1是对矩阵求伪逆。仿真参数如下。表4-6基于Reed-Muller码的无源多址仿真参数信道AWGN调制BPSK时隙数128激活用户数(Ka)50300信息比特数42编码后比特数25635IMT-2030(6G)推进组IMT-2030(6G)Promotion Group编码方法Reed-Muller仿真结果如图 4-28 所示。可以发现，当时隙数是 128 时，Reed-Muller 码可支持 300 个用户。用户数大于200 后，由于用户间干扰加剧，5%用户接入失败率所需比特信噪比增加较快，但在用户数小于 200 时性能较好。Reed-Muller 码的检测仅仅涉及相关运算，其计算复杂度较低。适合作为信息比特数较小（42 比特左右）的低复杂度无源多址方案。图4-28Reed-Muller无源多址方案仿真性能4.4.2稀疏 IDMA 有限域扩展在大多数现有的编码方案中，信道编码和/或扩展仅限于二元域；另外，随着接入用户数增加，系统性能下降较快。有限域（finite filed,FF）中具有良好性质的代数结构尚未被利用。研究表明，与二元方案相比，非二元方案：（1）增加了多用户叠加的多样性，即更少混叠；（2）在相同系统负载下，连边更加稀疏，从而减少了多用户干扰；（3）在高用户区域、高负载下性能增益更加明显；（4）随着多元域域参数的增加，系统容量越高，更贴近容量限。文献64将有限域扩展应用到无源多址接入（unsourcedmultiple access,UMA）场景，提出面向无源多址接入的一种新型的有限域扩展（finite field spreading,FFS）方法。与图 4-1 中的稀疏 IDMA 的基本架构类似，发射侧由两个并行分支组成：一个分支进行 CS 导频映射，承载包头部分的信息，并用于指示扩展图样。第二部分 Bd比特的数据首先被转换为长度为 Sd=Bd/log2(q)的 GF(q)上的信息符号，并由码率为 Rc非二元 LDPC 编码器编码成长度为 S=Sd/Rc的符号序列 ui。用户 i的有限域扩展图样由用户 i 的包头信息 di确定，从有限域扩展码本中选择，记作(di)。有限域扩展可以拆分为一系列步骤来实现，包括重复、有限域乘法、填零和交织。用户 i 的重复次数 l 和有限域乘法的系数向量 g 可以直接从扩展图样(di)中获得，分别记作 l(di)和 g(di)。在图 4-29 中，由一个框中的一组蓝色圆圈表示的长度为 S 的编码符号序列 ui被重复 l(di)次，生成长度为 S/Ri的较低速率码字()times(,.,)iiiiil dru uu ，其中所有用户的重复率 Ri=1/l(di)可以不同，以引入不相等的分集。为了获得有限域中的编码分集增益，将码字 ri与在有限域 GF(q)上定义的相同长度的系数向量 g(di)按元素相乘，产生新的向量()iiidrrg,如图 4-29 中的一组绿色圆圈表示。i r被填零到长度sF，即(,0,0,.,0)iirr。然后，通过由id确定的置换操作idP，获得交织的 GF(q)码字ic。有限域编码背后的核心思想是：（1）不一致的重复设置给活跃用户带来了不等的可靠度；（2）按元素乘法和交织不仅提高了编码增益，而且减少每个 MAC 节点上的叠加数；（3）填零使传输稀疏化，并降低每个信道被使用的干扰水平，尤其是当sdSF时。有限域在 GF(4)上扩展的一个简单例子也如图3 所示。GF(4)LDPC 码字 ui=(2103)被重复 l(di)=2 次，以产生 ri=(21032103)，随后该码字逐元素地与36IMT-2030(6G)推进组IMT-2030(6G)Promotion Groupg(di)=(32212313)相乘。根据 GF(4)上的乘法规则，得到(12033302)ir。在填零和交织操作之后，获得FFS 码字为(10323320)ic。注ic中的每个“”表示填零的位置，并且与 GF(4)上的“0”元素（0）具有不同的含义。图4-29有限域在GF(4)上扩展的一个例子根据 GF(q)到星座字母表 A 的一一映射函数(.)，ci被调制为复数域中的码字 mi。图 4-29 中，GF(4)域扩展后采用 QPSK 调制来产生码字 mi。注意只有ic中的有限域元素被调制，而填充的零（即“”）不发送任何内容。有限域扩展可以由非二元因子图表示，与信道编码进行联合迭代译码。图 4-30 给出了 Kv=2 个用户提供了一个简单示例。相同颜色的圆圈和正方形分别表示 LDPC 码的变量节点（variable nodes,VN）和校验节点（check nodes,CN）。由标记的正方形表示 MAC 节点（MAC nodes,MN）。非二元因子图的连边上有从 1 到 q-1 的整数系数表示有限域乘法。接收端通过压缩感知译码器恢复导频信息，从而恢复所有活跃用户的扩展图样后，即可获得 VN 与 MN 节点之间的因子图结构。上层因子图表示的(S,Sd)=(4,2)非二元 LDPC 码对 Kv=2 个用户的数据部分进行编码。然后，来自变量节点的编码符号12,uu u稀疏地分布到由下层因子图表示的 Fs=10 个 MAC 节点上。给定 MAC 节点上的接收信号dvy，联合 BP 译码器沿着非二元因子图的边迭代地交换软信息，包括（1）用户检测器 MN 和 VN 节点之间的迭代译码，（2）单用非二元 LDPC 译码器 VN 与 CN 节点之间的迭代译码。检测器和译码器内部节点的消息传递和更新为内迭代。多用户检测器和单用户信道译码器通过共有的 VN 节点传递软信息。每通过 VN 节点完成一次双向消息传递即完成一次外迭代。软信息具体为 q 维对数似然比向量或对数概率向量L。图4-30级联因子图编解码举例（用户1和2分别通过重复2次和1次来扩展编码符号）考虑用户平均错误概率 Pe 150 时性能更好。当 Ka=150 时，有限域方案（8q）与基于二元 LDPC 编码的稀疏 IDMA 方案相比有明显性能优势，当 Ka 175 时，其性能优于直接扩频方案（包括 Polar 码 稀疏扩频、稀疏 IDMA 方案）。在较高用户数区域 Ka 200，与所有现有方案相比，所提方案实现了明显的性能增益。此外，所提出的方案的复杂性低于 Polar 码 IRSA、Polar 码 稀疏扩频和稀疏 IDMA 方案。图4-31所需信噪比随活跃用户数变化的性能曲线4.4.3可扩展同步前导序列针对大规模接入条件下用户连接态维护困难，以及物理随机接入信道的前导序列不足的问题，可以考虑可扩展同步用户激活检测体制。该体制充分利用终端业务零星性自然造成的信号稀疏性特征，设计具有海量连接且满足恒模要求的非正交前导序列集合及其发送接收方法。每一用户关联一个数字频率不同的复指数序列，实现海量终端用户标识的唯一化，由此避免在有限时频资源条件下的前导序列碰撞问题。用户侧充分利用信道先验知识，可采用预均衡或相位预补偿的方法发送关联序列，由此简化基站侧检测处理并提高检测效率。所采用的序列发送方法实现了用户活动信息的非负性表示，将自然诱导检测结果的稀疏性。因此，在稀疏性检测算法设计中可以避免使用基于范数的正则化项，从而实现在有限步数内收敛的快速检测算法，彻底解决检测算法的收敛问题。所提出的可扩展同步用户活动性检测体制实现了最小化完美检测所需的序列长度，使其仅取决于实际活动终端的数量，适应终端总量的任意扩展，避免现有基于压缩感知方法所固有的搜索损失，便于网络扩展。38IMT-2030(6G)推进组IMT-2030(6G)Promotion Group参考文献1 袁弋非，袁志锋，5G 非正交多址技术（NOMA），人民邮电出版社，2019.2 X.Chen,T-Y Chen,D.Guo,“Capacity of Gaussian many-access channels”,IEEE Trans.on Info.Theory,vol.63,no.6,June 2017,pp.3516-39.3 I.Zadik,Y.Polyanskiy,and C.Thrampoulidis,“Improved bounds on Gaussian MAC and sparseregression via Gaussian inequalities,”in 2019 IEEE International Symposium on Information Theory(ISIT).IEEE,2019.4 S.S.Kowshik,and Y.Polyanskiy,“Quasi-static fading MAC with many users and finite payload,”Proc.IEEE Intl.Symp.Info.Theory,2019.5 Y.Zhang et al.,“Asymptotic analysis for NOMA over fading channel without CSIT,”Proc.14th Intl.Wireless Commun.&Mobile Computing Conf.,2018,pp.111620.6 X.Su,Y.Yuan,and Q.Wang,“Performance analysis of rate splitting in K-user interference channelunder imperfect CSIT:average sum rate,outage probability and SER,”IEEE Access,August 2020.7 Z.Yuan,et.al,“Multi-user shared access for Internet-of-Things,”IEEE 83rd VTC Spring,2016.8 J.A.Tropp,Complex equiangular tight frames,Proc.SPIE Wavelets XI,San Diego,August 2005,pp.590412.01-11.9 H.Nikopour,H.Baligh,“Sparse code multiple access,”IEEE 24th Int.Symp.on Personal,Indoor andMobile Radio Commun,2013.10Y.Chen et al.,Toward the standardization of non-orthogonal multiple access for next generationwireless networks,IEEE Commun.Mag.,vol.56,no.3,Mar.2018,pp.19-27.11Z.Yuan,C.Yan,Y.Yuan and W.Li,Blind Multiple User Detection for Grant-Free MUSA withoutReference Signal,IEEE 86th Vehicular Technology Conference(VTC-Fall),Toronto,ON,2017.12Y.Hu,et.al,“Interleave division multiple access in high rate applications”,IEEE Wireless Comm.Letters,vol.8,no.2,April,2019,pp.476-9.13A.K.Pradhan,V.K.Amalladinne,A.Vem,K.R.Narayanan and J.-F.Chamberland,Sparse IDMA:AJoint Graph-Based Coding Scheme for Unsourced Random Access,in IEEE Transactions onCommunications,vol.70,no.11,pp.7124-7133,Nov.2022.14K.Andreev,et.al,“A Polar code based TIN-SIC scheme for the unsourced random access in thequasi-static fading MAC,”IEEE Intl.Symp.on Info.Theory(ISIT)2020.15Z.Han,X.Yuan,C.Xu,S.Jiang,and X.Wang,“Sparse Kronecker-product coding for unsourcedmultiple access,”IEEE Wireless Comm.Letters,vol.10,no.10,Oct.2021,pp.2274-8.16Ordentlich and Y.Polyanskiy,“Low complexity schemes for the random access gaussian channel,”IEEE Intl Symp.on Info.Theory(ISIT),2017.17V.Amalladinne,J-F Chamberland,K.R.Narayanan,“A coded compressed sensing scheme forunsourced multiple access,”IEEE Trans.on Info.Theory,vol.66,no.10,Oct.2020,pp.6509-6533.18D.Donoho,A.Maleki,and A.Montanari,“Message-passing algorithms for compressed sensing,”Proc.National Academy of Science,USA,vol.106,no.45,Nov.2009,pp.18914-19.19J.Ma,X.Yuan,and Li Ping,“Turbo compressed sensing with partial DFT sensing matrix,”IEEE SignalProcessing Letters,vol.22,no.2,Feb.2015,pp.158-161.20Z.Chen,F.Sobrabi,and W.Yu,“Sparse activity detection for massive connectivity,”IEEE Trans.onSignal Processing,vo.66,no.7,April,2018,pp.1890-1904.21S.Jiang,X.Yuan,X.Wang,C.Xu,and W.Yu,“Joint user identification,channel estimation,and signaldetection for grant-free NOMA,”IEEE Trans.Wireless Comm.,vol.19,no.10,Oct.2020,pp.6960-6976.22Y.Cheng,L.Liu,and L.Ping,“Orthogonal AMP for massive access in channels with spatial andtemporal correlations,”IEEE J.Sel.Areas Commun,vol.39,no.3,March 2021,pp.726-740.23Y.Bai,W.Chen,F.Sun,B.Ai,“Data-Driven Compressed Sensing for Massive Wireless Access,”accepted for IEEE Communications Magazine.24M.Borgerding,P.Schniter and S.Rangan,AMP-Inspired Deep Networks for Sparse Linear InverseProblems,IEEE Trans.on Signal Processing,vol.65,no.16,Aug,2017,pp.4293-4308.253GPP TR 36.859,“Study on Downlink Multiuser Superposition Transmission(MUST)for LTE”(Release 13).263GPPTR 38.812,“Study on non-orthogonal multiple access(NOMA)for 5G”(Release 16).27田力，袁弋非，张峻峰、邱徵虹，5G 随机接入增强技术，人民邮电出版社，2021.28IMT-2030（6G）推进组，6G 典型场景和关键能力白皮书，2022 年 7 月。29工业互联网产业联盟，无线应用场景白皮书-汽车制造领域（2018 年），2018 年 10 月39IMT-2030(6G)推进组IMT-2030(6G)Promotion Group30EUROPEAN COMMISSION.Industry 5.0：towards a sustainable，human-centric and resilientEuropean industryR.Luxembourg：Publications Office of the European Union，2021：14-1531https:/ TS 22.261 v18.6.1,“Service requirements for the 5G system”,June 2022.333GPP TR 36.763“Study on narrow-band internet of things(NB-IoT)/enhanced machine typecommunication(eMTC)support for non-terrestrial networks(NTN).34ITU FG NET-2030,“Network 2030-a blueprint of technology,applications and market driverstowards the year 2030 and beyond”,Whitepaper,May 2019.35IMT-2030（6G）推进组，6G 总体愿景与潜在关键技术白皮书，2021 年 6 月。36Y.Polyanskiy,H.V.Poor,and S.Verd,“Channel coding rate in the finite blocklength regime,”IEEETrans.Inf.Theory,vol.56,no.5,pp.2307-2359,May 2010.37T.M.Cover and J.A.Thomas,Elements of Information Theory,John Wiley&Sons,2012.38E.MolavianJazi and J.N.Laneman,“A second-order achievable rate region for Gaussian multi-accesschannels via a central limit theorem for functions,”IEEE Trans.Inf.Theory,vol.61,no.12,pp.6719-6733,Dec.2015.39Y.Wu,X.Gao,S.Zhou,W.Yang,Y.Polyanskiy,and G.Caire,“Massive access for future wirelesscommunication systems,”IEEE Wireless Commun.,vol.27,no.4,pp.148-156,Aug.2020.40J.Gao,Y.Wu,S.Shao,W.Yang,and H.V.Poor,“Energy efficiency of massive random access inMIMO quasi-static Rayleigh fading channels with finite blocklength,”to appear in IEEE Trans.Inf.Theory,Nov.2022.Online.Available:https:/arxiv.org/abs/2210.1197041R.M.Fano,Transmission of Information.Jointly published by the MIT Press and John Wiley&Sons,1961.42W.Yang,G.Durisi,T.Koch,and Y.Polyanskiy,“Quasi-static multiple-antenna fading channels at finiteblocklength,”IEEE Trans.Inf.Theory,vol.60,no.7,pp.4232-4265,2014.43A.Fengler,S.Haghighatshoar,P.Jung,and G.Caire,“Non-bayesian activity detection,large-scalefading coefficient estimation,and unsourced random access with a massive MIMO receiver,”IEEETrans.Inf.Theory,vol.67,no.5,pp.2925-2951,May 2021.44J.Liu,G.Wu,X.Zhang,S.Fang,S.Li,“Modeling,analysis,and optimization of grant-free NOMA inmassive MTC via stochastic geometry,”IEEE Internet of Things Journal,vol.8,no.6,pp.4389-4402,March 2021.45Y.Du,C.Cheng,B.Dong,et al.Block-Sparsity-Based Multiuser Detection for Uplink Grant-FreeNOMAJ.IEEE Transactions on Wireless Communications,2018,17(12):7894-790.46Y.Zhang,Q.Guo,Z.Wang,et al.Block Sparse Bayesian Learning Based Joint User Activity Detectionand Channel Estimation for Grant-Free NOMA SystemsJ.IEEE Transactions on Vehicular Technology,2018,67(10):X.Dai,T.Yan,Q.Li,H.Li and X.Wang.Pattern Division Random Access(PDRA)for M2MCommunications With Massive MIMO SystemsJ.IEEE Transactions on Vehicular Technology,2021,70(12):J.Ma,X.Yuan and L.Ping,Turbo Compressed Sensing with Partial DFT Sensing Matrix,in IEEESignal Processing Letters,vol.22,no.2,pp.158-161,Feb.2015,doi:10.1109/LSP.2014.2351822.49Y.Chi,L.Liu,et al.,Constrained Capacity Optimal Generalized Multi-User MIMO:ATheoretical andPractical Framework,IEEE TCOM,2022.50J.Ma and L.Ping,“OrthogonalAMP,”IEEE Access,vol.5,pp.20202033,2017,arXiv:1602.06509,2016.51L.Liu,S.Huang,and B.M.Kurkoski,“Memory AMP,”IEEE Trans.Inf.Theory,vol.68,no.12,pp.80158039,2022.52Y.Chen,L.Liu,Y.Chi,Y.Li,Z.Zhang,“Low-complexity and information-theoretic optimal memoryAMP for coded generalized MIMO”,IEEE Global Commun.Conf.(GLOBECOM),pp.1-6,202353ErdalArkan,“From sequential decoding to channel polarization and back again,”ArXiv,vol.abs/1908.09594,2019.54Z.Sun,Y.Xiao,D.Lin and X.Xu,Performance Evaluation of Unsourced Multiple Access withPolarization-Adjusted Convolutional Coding,2022 IEEE 95th Vehicular Technology Conference,Helsinki,Finland,2022,pp.1-5.55O.Ordentlich and Y.Polyanskiy,“Low complexity schemes for the random access Gaussian channel,”IEEE International Symposium on Information Theory-Proceedings,2017,pp.25282532.56Z.Yuan,Y.Hu,W.Li,and J.Dai,“Blind multi-user detection for autonomous grant-freehigh-overloading multiple-access without reference signal,”in Proc.87th Vehicular TechnologyConference(VTC-Spring),Porto,Portugal,2018.40IMT-2030(6G)推进组IMT-2030(6G)Promotion Group57Y.Ma,Z.Yuan,Y.Hu,W.Li and Z.Li,A Data-assisted Algorithm for Truly Grant-free Transmissionsof Future mMTC,GLOBECOM 2020-2020 IEEE Global Communications Conference,2020,pp.1-6,doi:10.1109/GLOBECOM42002.2020.9348198.58Z.Yuan,W.Li,Z.Li,Y.Ma and Y.Hu,Contention-based Grant-free Transmission with IndependentMulti-pilot Scheme,2020 IEEE 92nd Vehicular Technology Conference(VTC2020-Fall),Victoria,BC,Canada,2020.59Z.Yuan,Z.Li,W.Li,Y.Ma and C.Liang,Contention-based Grant-free Transmission with ExtremelySparse Orthogonal Pilot Scheme,2021 IEEE 94th Vehicular Technology Conference(VTC2021-Fall),2021,pp.1-6,doi:10.1109/VTC2021-Fall52928.2021.9625265.60Z.Yuan,Y.Ma,Y.Hu,and W.Li,“High-efficiency full-duplex V2V communication,”in Proc.2nd 6GWireless Summit,Levi,Finland,Mar.2020.61Li Y,Li C,He X,et al.The Grassmannian-Codebook Based Non-Coherent Multiple Access for MassiveConnectionsC/2021 IEEE/CIC International Conference on Communications in China(ICCC).IEEE,2021:189-194.62S.D.Howard,A.R.Calderbank and S.J.Searle,“A fast reconstruction algorithm for deterministiccompressive sensing using second order reed-muller codes,”2008 42nd Annual Conference onInformationSciencesandSystems,Princeton,NJ,USA,2008,pp.11-15,doi:10.1109/CISS.2008.4558486.63R.Calderbank,A.Thompson,“CHIRRUP:a practical algorithm for unsourced multiple access”,Information and Inference:A Journal of the IMA,Volume 9,Issue 4,December 2020,Pages 875897,https:/doi.org/10.1093/imaiai/iaz029.64X.Sui,Z.Si,J.Dai,S.Wang,and Y.Yuan,“Non-Orthogonal Multiple Access via Non-binary FactorGraphs”,in IEEE Wireless Communications and Networking Conference(WCNC),Glasgow,UnitedKingdom,2023,pp.1-641IMT-2030(6G)推进组IMT-2030(6G)Promotion Group具体贡献说明序号序号主主要要贡献单位贡献单位贡献章节贡献章节1中国移动总体、第1章、第2章、第4章1节2中信科移动第2章3华为第2章4中兴通讯第4章第2节5诺基亚上海贝尔第4章第4节6中关村泛联院第4章1节、第4章4节7上海交通大学第3章第1节8电子科技大学第3章第1节，第4章1节9北京邮电大学第4章1节、第4章第2节、第4章4节10浙江大学第4章第1节、第4章第3节11北京理工大学第4章1节12北京交通大学第4章第3节联系方式邮箱：COPYRIGHT2023 IMT-2030(6G)PROMOTION GROUP.ALL RIGHTS RESERVED.

0人已浏览 2023-12-13 43页 5星级

北京稻壳科技有限公司Beijing Rice Hull Technology Co.,Ltd.地址：北京市朝阳区九住路 188 号IMT-2030(6G)推进组IMT-2030(6G)Promotion Group2023 年年 12 月月版权声明版权声明 Copyright Notification未经书面许可未经书面许可 禁止打印、复制及通过任何媒体传播禁止打印、复制及通过任何媒体传播2023 IMT-2030（6G）推进组版权所有3IMT-2030(6G)推进组IMT-2030(6G)Promotion Group1第一章第一章概述概述.52第二章第二章 超大规模天线信道建模超大规模天线信道建模.52.1近场信道建模.52.2远场信道建模.92.3混合近场/远场信道建模.103第三章第三章 新型天线架构新型天线架构.113.1稀布阵.113.2基于 RIS 的新型天线架构.143.3RIS 辅助 MEGAMIMO.164第四章第四章 信道状态信息反馈信道状态信息反馈.184.1近场球面波信道的 CSI 反馈码本设计.184.2近场非平稳信道的 CSI 反馈设计.204.3面向模块化天线的 CSI 反馈优化设计.214.4面向 RIS 的 CSI 反馈增强.235第五章第五章 预处理算法预处理算法.255.1面向广义极化 MIMO 的预处理算法.255.2对抗波束分裂的预编码码本设计.286第六章第六章 非平稳信道下接收机算法设计非平稳信道下接收机算法设计.296.1算法描述.306.2性能评估.317第七章第七章 波束管理波束管理.337.1基于 RIS 的波束管理.337.2分层 RIS 波束训练技术.358第八章第八章 总结及发展建议总结及发展建议.378.1总结.378.2研究方向发展建议.379参考文献参考文献.3710主要贡献单位主要贡献单位.4011缩略语缩略语.414IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图目录图 2.1-1电磁波波前示意图.6图 2.1-2基于几何的随机统计的近场信道建模流程.8图 2.2-1远场平面波传播示意图.9图 2.2-2超大规模天线远场传播场景几何建模示意图.10图 2.2-3超大规模天线远场信道建模流程图.10图 3.1-1稀布阵示例.11图 3.1-2Type A 用户分布下的系统吞吐性能 CDF 曲线.12图 3.1-3Type B 用户分布下的系统吞吐性能 CDF 曲线.13图 3.2-1RIS 用作收发机的设备实物.15图 3.3-1RIS 辅助 Mega MIMO 示意图.16图 3.3-2可达吞吐性能随相控阵天线总发射功率的变化.18图 4.1-1不同方案量化性能比较.20图 4.2-1空间非平稳 LoS 径信道示意图.20图 4.2-2空间非平稳多径信道示意图.21图 4.3-1模块化天线阵列示意图.22图 4.3-2两级码本示意图.23图 4.3-3不规则天线模块码本构造示意图.23图 4.4-1基于 RIS 的无线通信系统.23图 4.4-2RIS 示意图.24图 5.1-1极化编码-调制-预编码的联合设计.25图 5.1-2基于广义极化的 MIMO 预处理框图.26图 5.1-3基于广义极化的 MIMIO 预处理框图.26图 5.1-4GP-RP、PC-MIMO-QR 和 DFT-QR 方案容量对比.27图 5.1-5不同调制阶数下 GP-RP、PC-MIMO-QR 和 DFT-QR 方案的 BLER.28图 6.2-1因子图模型.30图 6.2-2PE-EP 因子图模型.31图 6.3-1算法性能分析.33图 6.3-2不同检测器性能对比.34图 7.1-1RIS 接收波束扫描示意图.34图 7.1-2RIS 发送波束扫描示意图.35图 7.2-1分层训练的设计逻辑训练决策示意图.36图 7.2-2两种分层码本的波束训练成功率.36表格目录表 3.3-1两种 RIS 辅助 Mega MIMO 传输方案.17表 5.1-1仿真参数.27表 6.3-1 计算复杂度对比.325IMT-2030(6G)推进组IMT-2030(6G)Promotion Group1第一章第一章概述概述在 4G、5G 中 MIMO 技术与大规模 MIMO 技术一直承担着提高数据传输速率、频谱利用效率和覆盖能力的重任，在 6G 中超大规模 MIMO 技术将继续支撑系统性能指标的进一步提升。然而，随着天线规模的持续增加，超大规模 MIMO 系统在众多方面展现出了新的特性并遇到了新的技术挑战：超大规模 MIMO 信道表现出了近场特性、空间非平稳特性；超大规模天线阵列所形成的波束具有更高的空间分辨率，给波束管理带来新的挑战；天线数的大幅增加所带来的功耗和数据处理复杂度的大幅提升、CSI 反馈开销的大幅增加等问题。本报告针对集中式超大规模 MIMO 所面临的挑战与问题开展研究，提供有效的解决方案，指出当前研究中尚存在的不足，探讨超大规模 MIMO 未来的发展方向，以使得超大规模 MIMO 能为 6G 提供更有力的技术支撑与性能提升。关于分布式超大规模 MIMO技术、低功耗以及智能化超大规模 MIMO 技术的研究进展和成果将在分布式超大规模MIMO 研究报告和绿色智能化超大规模 MIMO 研究报告中呈现。本报告主要包含以下研究内容：在信道建模方面，需要新的信道建模方法去刻划超大规模 MIMO 随天线数增加所表现出的近场特性与空间非平稳特性；在天线形态方面，随着天线规模的扩大，天线的功耗也将变得不可忽视，需要研究具有低功耗、高能效的新型天线架构；在 CSI 反馈方面，特别是在基于码本的 CSI 反馈方案设计中，需要充分考虑超大规模信道的近场特性、空间非平稳特性、以及新型天线架构的影响；在预处理算法方面，特别是预编码的设计方面，需要充分考虑超大规模 MIMO的信道特点、高频段下的大带宽特性、以及新型天线架构的影响；在接收机算法方面，随着天线数的增加，接收机算法的复杂度变得很高，需要设计考虑超大规模信道特点的低复杂度的接收机算法；在波束管理方面，需要考虑超大规模 MIMO 的高空间分辨率特性，并考虑新型天线架构的引入对波束管理的影响。2第二章第二章 超大规模天线信道建模超大规模天线信道建模2.1 近场信道建模近场信道建模2.1.1近场信道建模的背景与挑战近场信道建模的背景与挑战根据电磁理论和天线理论，发射机周围的场可分为近场和远场，近场区可进一步分为反应近场区域和辐射近场区域1。其中，反应近场区域仅限于靠近天线的空间，在这6IMT-2030(6G)推进组IMT-2030(6G)Promotion Group一区域内倏逝波占主导地位，电磁场并不以辐射波的形式从天线传播出去。辐射近场区域位于距离天线几个波长以上的区域，在此区域内，辐射的电磁波还没有完全发展成具有远场特征的平面波，而主要以球形波前的形式进行传播。远场区域包围着辐射近场区域，在远场中电磁波可以近似视为平面波前。由于反应近场区域通常较小，且倏逝波随距离呈指数级衰减，因此在实际的近场通信系统中，通常主要关注辐射近场区域内的无线通信，即“近场”一般表示辐射近场区域。近场与远场区域并没有严格统一的界限，因此，也有着多种边界划分的指标来表征近场与远场区域的边界。从相位误差角度看，出现了几种常用的经验法则，包括瑞利距离、夫琅禾费距离1、基于 MIMO 收发器和 RIS 场景的扩展瑞利距离2，这些距离主要适用于靠近天线孔径主轴的场边界。从信道增益误差的角度来看，可以对离轴区域给出更准确的场边界描述。近场与远场的边界不仅取决于天线孔径大小和波长，还取决于出发角、到达角和发射天线形状3。从波束聚焦能力角度，可以基于近场增益和最大波束聚焦距离划分近场与远场区域4。从信道容量表征角度，可以结合信道的秩来评估远场平面波与近场球面波的适用区域，通过等秩面给出近场与远场边界，可以证明近场范围会随着视距和非视距环境中散射体数量的增加而增加，且在非视距环境中增加更为显著5。在诸多近远场边界划分方法中，夫琅禾费距离(22/，其中，L 表示天线孔径，表示波长)是最为广泛使用的划分指标，其主要与表征发射信号的相位行为有关。传统 MIMO 天线系统中，由于天线数量较少，天线孔径较小，天线阵列的近场区域范围很小。例如，考虑 64 端口的 2.4GHz MIMO 面天线阵列，以每端口对应 4 个天线单元为例，天线孔径不足 1 米，夫琅禾费距离约为 14 米。用户到基站发射端的距离往往大于夫琅禾费距离，使用户处于天线阵列的远场区域。此时可认为所有收发天线对间的信道经历相同的散射体，同一个散射路径信号到达天线阵列的各天线阵元近似平行，可近似为平面波前。图 2.1-1(a)给出了平面波示意图。相对于传统的 MIMO 天线系统，超大规模 MIMO 系统的天线阵列规模更大。随着天线阵列尺寸的增加，天线阵列的夫琅禾费距离也会增大，用户与基站之间的距离可能不再满足远场条件。以 1600 单元、半波长单元间距、2.4GHz 的超大规模正方形天线阵列为例，夫琅禾费距离达到约 100 米。此时，到达天线阵列不同阵元的电磁波会呈现出球面波特性。图 2.1-1(b)所示给出了一个位于近场的终端球面波示意图。（a）平面波前示意图（b）球面波前示意图图 2.1-1电磁波波前示意图对于超大规模天线阵列来说，信道不能被看作是平稳的。阵列天线的不同部分可能会经历不同的传播环境，即阵列天线的每一部分能够观察到的反射体（或散射体）可能是不一样的。因此，从超大规模天线阵不同空间位置的阵元上发射的信号在传播过程中7IMT-2030(6G)推进组IMT-2030(6G)Promotion Group可能由不同的反射体（或散射体）反射（或散射），导致信号在不同的收发天线阵元对之间经历的信道不同，呈现出空间非平稳特性。以上近场球面波效应和空间非平稳特性是超大规模 MIMO 信道建模的重要特征，对系统设计带来相应的挑战。当采用球面波假设和随机几何特性对超大规模 MIMO 的近场效应进行信道建模时，通过对不同的天线收发对分别建模路损、角度参数、多普勒频移等可以更精确地进行信道建模。但天线规模巨大，意味着子信道增多，信道的建模也将变得非常复杂。找到一种兼顾复杂度和精确度的球面波（近似）建模方法是亟需解决的问题。针对近场信道的空间非平稳特性，空间非平稳信道的建模方法、非平稳信道的关键参数设计、信道测量方案设计等问题同样需要解决，不同典型场景下的非平稳信道特征也需要进一步探明。2.1.2近场信道建模方法近场信道建模方法如上文所述，近场超大规模 MIMO 信道具备两个显著特征：球面波传播以及空间非平稳67。实际上，这两种信道特征在以往室内场景的大规模 MIMO 信道测量中已被广泛观测到。例如，在文献9的测量结果显示，多径的离开方位角和离开俯仰角的测量值会随着检测区域在整个阵列的位置变化而变化，这反映了近场超大规模 MIMO 信道的球面波传播特征。此外，大规模阵列上不同检测区域位置提取得到的多径数量也不尽相同，且不同的簇（Cluster）具有不同的可视区域，这反映了近场超大规模 MIMO 信道的空间非平稳特征。几何的随机统计信道建模方法(Geometry-Based Stochastic Channel Model,GBSM)在各大标准模型中广泛使用。近场信道建模可以使用基于位置的确定性信道建模或者半统计的确定性建模方法。文献6中提出了一种面向多径信道的半统计的确定性信道建模方法。文献6假设终端和多径散射体都可能处于近场范围内，分别对端到端的近场直射路径、近场散射体提供的非直射路径进行了建模。在收发两端是位于同一平面的均匀线阵天线的情况下，直射路径建模为2,1=12,122,1（公式 2.1-1）2,1=cos 2sin 2 sin 2cos 12（公式 2.1-2）其中，2,1表示发射端天线2与接收端天线1之间的距离；表示发射端天线 1 与接收端天线 1 之间的距离，1和2分别表示接收天线阵列和发送天线阵列的天线间隔，和分别表示接收天线阵列和发送天线阵列之间的夹角和发送天线阵列的离开角（Angle ofDeparture,AOD）。在非直射路径建模中，假设近场散射体与发送天线阵列/接收天线阵列的距离和角度分别为,/,，按照直射路径建模发射端与散射体之间的导向矢量,和散射体与接收端之间的导向矢量,。基于近场散射体的非直射路径建模为8IMT-2030(6G)推进组IMT-2030(6G)Promotion Group=,（公式 2.1-3）其中为散射体 l 的路径增益。近场区域内 LOS 和 NLOS 多径路径最终建模为= =1?（公式 2.1-4）在近场超大规模 MIMO 信道统计模型中，由于簇内子径的相位与簇到阵列的距离直接相关，超大规模天线的近场信道建模需要考虑近场簇（Near-Field Cluster）的空间位置7。5G NR 所采用的 3GPP TR 38.901 信道模型尚未对近场簇的空间位置进行确定性建模。文献8给出了一种在 3GPP TR 38.901 信道模型的基础上改进的近场信道建模。该方法基于 3GPP TR 38.901 信道模型的多径时延、角度参数，通过几何关系确定了首跳散射体（First-Bounce Scatterer，FBS）簇或末跳散射体（Last-Bounce Scatterer，LBS）簇在信道坐标系中的确切位置，且簇中的多径成份（Multi-Path Component，MPC）到阵列每个阵元的相位都是根据 FBS 或 LBS 与阵元之间的距离独立计算，这个过程实现了近场信道的球面波建模。对于空间非平稳特征建模，关键是需要对信道中簇的可视区域的大小和位置进行刻画，可以采用基于概率模型的建模方式，也可以采用基于信道测量的统计性建模方式9，或者采用结合上述两种方法的混合建模方式。图 2.1-2 基于几何的随机统计的近场信道建模流程基于 GBSM 建模超大规模天线近场信道的流程如图 2.1-2 所示。该流程以 3GPP TR38.901 信道建模流程为基础，考虑了公式(2.1-1)-公式(2.1-3)中近场球面波对信道衰落建模的影响，生成并采用球面波信道矩阵系数。超大规模 MIMO 近场信道 MIMO 系统设计主要有以下影响：1)波束赋形时，仅用基站与用户之间角度信息无法准确对准用户，需要利用基站和用户之间的距离信息。2)近场超大规模 MIMO 的 LoS 信道具有丰富的空间自由度能够提高空间复用增益，从而支持多流传输，但需要合理设计预编码矩阵充分利用空间自由度。9IMT-2030(6G)推进组IMT-2030(6G)Promotion Group2.2 远场信道建模远场信道建模相对于近场通信，超大规模天线远场通信信道中特定多径分量角度参数对于不同天线阵元被认为是一致的。对于超大规模天线信道，电磁波到达不同阵元的相位差只与特定角度和阵元间隔有关。图 2.2-1 远场平面波传播示意图图 2.2-1 为发射天线远场传播平面波示意图。相对于近场球面波前多径分量与收发机之间角度不同，远场信道中平面波前与收发机之间的角度是相同的。考虑收发端均为超大规模天线，分别具有 个面阵天线和 个面阵天线。为第 p 行第 q列发射天线位置矢量，为第w行第n列接收天线位置矢量。发射端导向矢量,和接收端导向矢量,分别表示为：,=1,21 1 ,.,21 1 (公式 2.2-1),=1,21 1 ,.,21 1 (公式2.2-2)其中，/和/分别表示不同子径与发射天线/接收天线之间的水平出发/到达角度和垂直出发/到达角度，与分别表示发射端与接收端天线的阵元间距。目前，主流的信道建模包括统计性建模、确定性建模以及基于几何的随机性建模方法。基于实测的统计性建模通过采集实际通信数据进行统计分析，提供真实场景下信道特性，但受限于实测数据的数量和覆盖范围10。确定性建模根据几何光学和一致性绕射理论进行建模，可以提供高精度的信道信息，但计算复杂度相对较高11。基于几何的随机性建模将实际通信场景抽象为几何模型，通过定义随机变量和概率分布描述信道特性，具有较低的计算复杂度，广泛应用于标准化研究中1213。本节考虑基于几何原理以及导向矢量建立随机性信道模型。图 2.2-2 为超大规模天线传播远场场景几何建模示意图。10IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图 2.2-2 超大规模天线远场传播场景几何建模示意图信道矩阵,是维度大小为 的复矩阵，具体表示为：,= 1LoS, 1 1LoS,(公式 2.2-3)其中，K 为莱斯 K 因子，为收发端之间的路径损耗。LoS 信道矩阵LoS,和 NLoS信道矩阵NLoS,分别表示为：LoS,=,2 ,(公式 2.2-4)NLoS,=1=1=1,2?,(公式 2.2-5)其中，M 和 N 分别表示多径簇和簇内子径的数目，/和/分别表示 LoS 径的水平出发/到达角度和垂直出发/到达角度，/和/分别表示第 m 个簇中 n 条子径的水平出发/到达角度和垂直出发/到达角度。和 分别表示时变的 LoS 径和 NLoS 径时延。,，,，,和,分别表示 LoS 和 NLoS 分量的波导矢量。基于上述描述，超大规模天线远场信道建模的流程如图 2.2-3 所示，涵盖了大尺度信道参数、小尺度信道参数和时变信道参数的更新过程。与 3GPP 标准化信道模型不同的是，基于几何原理进行远场信道建模时多径分量的角度、时延等信道参数的生成更加注重几何关系的描述，对实测统计参数的依赖较低，该建模方式较为准确且复杂度适中。标准化模型中以上参数的生成通常是基于概率分布和统计参数等方式生成。图 2.2-3 超大规模天线远场信道建模流程图2.3 混合近场混合近场/远场信道建模远场信道建模在现有的远场或近场信道模型中，假设所有散射体都在远场或近场区域。实际上，在超大规模 MIMO 系统中更容易出现混合场通信环境，即其中一些散射体位于远场区域，而另一些位于近场区域。换句话说，超大规模 MIMO 信道通常由远场和近场路径分量共同组成。然而，现有的远场或近场信道模型与混合场信道特征并不能完全匹配，这使得现有的远场或近场信道模型无法直接用于精确描述混合近场/远场信道。为了应对这一挑战，一种可行的方案是通过对近场和远场散射体分别建模，将混合场的信道表示成一定比例的近场径分量和远场径分量的加和，其中近场径经由近场散射体反射（或散射），采用 2.1 节中的近场信道模型，远场径经由远场散射体反射（或散射），11IMT-2030(6G)推进组IMT-2030(6G)Promotion Group采用 2.2 节中的远场信道模型，从而得到混合近场/远场场景下的多径信道模型14。3第三章第三章 新型天线架构新型天线架构3.1 稀布阵稀布阵3.1.1基本原理基本原理稀布阵技术实现的基本原理是，利用子空间的采样定理，通过优化阵元位置、幅度激励等方法，减少阵元数/通道数，且保证天线增益、旁瓣抑制等与半波长间距的均匀阵保持相同。如图 3.1-1 所示，稀布阵按照是否网格抽取阵元样点，可分为稀疏阵列、稀布阵列，前者按格点抽取，后者不限阵元位置，更具灵活性；按照阵列形态，稀布阵又可分为直线阵、平面阵、圆环阵。图 3.1-1 稀布阵示例3.1.2技术优势技术优势由图 3.1-1 可以看出，此时相邻天线阵元的阵间距不再相同，且不再受半波长的约束，部分阵间距甚至可达到若干个半波长，因此稀布阵具有节省天线数、简化阵列结构、减轻阵列重量、抑制天线间互耦效应等优势。除此之外，相比于基于均匀阵增加天线阵列间距的方式，稀布阵可以通过优化位置、激励振幅等设计达到比相同阵子数的均匀阵更好的通信效果，实现更高的空间自由度，并有助于达到更好的小区边缘性能。3.1.3设计算法设计算法天线方向图综合是稀布阵设计的核心关键。为了获得与原均匀阵相当的性能，稀布阵天线综合需要在给定阵列尺寸、最小阵元间距等诸多约束条件下，对天线阵元的位置、激励幅度等目标参数进行优化设计。由此可见，稀布阵天线综合是一个多变量的非线性优化问题。业界针对稀布阵天线综合算法的有效性开展了广泛的研究，目前应用于稀布阵天线综合的算法主要有：12IMT-2030(6G)推进组IMT-2030(6G)Promotion Group智能化优化算法，包括遗传算法(genetic algorithm，GA)15、粒子群算法(particleswarm optimization,PSO)16、差分算法(differential evolution，DE)17等，该类算法可在较小天线规模阵列中应用，而对于大规模天线阵列，其算法的复杂度显著增加。快速傅里叶变换(fast Fourier Transform,FFT)18、矩阵束(matrix pencil method,MPM)19、前后向矩阵束(forward-backward MPM,FBMPM)20等算法有效提升了计算效率，使得大规模天线阵列的稀布综合成为可能，但这类算法大多需要目标优化天线数作为先验信息，无法获取最优天线数。压缩感知类算法，例如基于凸优化(convex optimization,CO)2122的算法等，可同时优化阵元分布和阵元激励幅度，同时灵活处理最小阵间距等约束条件，具有较高的自由度。考虑移动通信环境下用户分布不确定性和移动特性，文献23提出了一种联合凸优化（joint convex optimization,JCO）的稀布综合理论模型，有效抑制天线阵列扫描产生的旁瓣/栅瓣引入的干扰。3.1.4系统级性能评估系统级性能评估系统级性能评估基于时分双工（time division duplexing,TDD）移动通信系统以及宏蜂窝（Urban Macro cell,UMa）应用场景展开，并根据 3GPP TR 38.90126构建 5G 信道模型。仿真中，基站将分别配置 64-UPA、32-UPA、CO-based 32-SPA、JCO-based 32-SPA天线阵列对不同的用户分布模型进行性能对比分析。系统带宽为 100 MHz，载频为 2.4GHz，用户分布模型分为 TypeA、TypeB。TypeA：用户随机分布在阵列法线方向，波束的辐射方向固定为。用于直观地比较基于 CO 和基于 JCO 的合成方法在无波束扫描的情况下的性能差异。TypeB：用户随机分布在以面板为中心，半径为为 R 的圆上，波束的辐射方向沿位置变化。用于验证基于 JCO 的合成方法在抑制导致相邻干涉的光栅波瓣方面的有效性。图 3.1-2 给出在 TypeA 用户分布模型下，64-UPA、32-UPA、CO-based 32-SPA、JCO-based 32-SPA 四种阵列应用系统的 CDF 曲线图。图 3.1-2 Type A用户分布下的系统吞吐性能CDF曲线在 TypeA 模型下，对于相同 32 阵子的面板，JCO-based 32-SPA 系统的小区边缘用户吞吐量比 32-UPA 系统高 13.36%，并且比 CO-based 32-SPA 系统高 9.36%。这是因为SPA 的主瓣辐射能力取决于方向上的扫描能力，而方向与天线元件在垂直方向上的位置有关。每列中的 SPAs 上的天线元件的位置不平行于 z 轴，使 SPA 拥有比 32-UPA 更13IMT-2030(6G)推进组IMT-2030(6G)Promotion Group高的空间自由度，并有助于达到更好的小区边缘性能。此外，在阵子数减少一半的情况下，JCO-based 32-SPA 系统的小区边缘用户吞吐量与 64-UPA 系统接近。图 3.1-3 给出 TypeB 用户分布模型下，64-UPA、32-UPA、CO-based 32-SPA、JCO-based 32-SPA 四种阵列应用系统的 CDF 曲线图。其中(a)表示半径 R=ISD/6，(b)表示 R=ISD/2。(a)半径 R=ISD/6(b)半径 R=ISD/2图 3.1-3 Type B用户分布下的系统吞吐性能CDF曲线在 TypeB 模型下，对于 32 阵子的面板，随着半径 R 增大，JCO-based 32-SPA 系统、CO-based 32-SPA 系统、32-UPA 系统之间的性能差距进一步扩大。这是因为较小的 R 表示 UE 位于基站附近，因此系统可以提供更好的服务。但对于较大的 R，其他扇区的潜在干扰的可能性增加。当 R 达到 ISD/2 时，JCO-based 的 32-SPA 系统的小区边缘用户吞吐量比 32-UPA 系统高 28.17%，并且比 CO-based 的 32-SPA 体系高 17.86%。与预期相同，JCO-based 的 32-SPA 系统得益于波束成形和联合方向图，受到的干扰比 CO-based32-SPA 更小，尤其是当 UE 位于小区边缘时。此外，在阵子数减少一半的情况下，JCO-based 32-SPA 系统的每个用户的净吞吐量接近 64-UPA 系统。结合上述分析，可获得以下结论：阵子数相同时，JCO-based 32-SPA 系统优于 32-UPA系统和 CO-based 32-SPA 系统。特别在面对邻区干扰时，JCO-based 32-SPA 系统鲁棒性更强。此外，当天线单元的数量减少近 50%时，基于 JCO 的 32-SPA 系统的性能接近64-UPA 系统，这对于未来 B5G 和 6G 移动通信的实际部署具有吸引力。3.1.5预编码方案设计预编码方案设计当稀布阵技术应用考虑基于码本的预编码方案时，由于现有标准仅支持特定天线数（2 的幂次方）的均匀阵预编码码本，并不支持稀布阵对应的预编码码本，因此系统采用稀布阵进行数据传输时，UE 无法向基站反馈基于稀布阵天线数规格的预编码矩阵指示（Precoding Matrix Indicator,PMI）信息。此外，由于稀布阵的天线数量、天线间距与应用场景、稀布综合算法有关，因此未来稀布阵的阵列形式一定是多样化的，对稀布阵预编码码本进行标准化难度较大。针对这个技术难题，需要对 PMI 信息反馈方面进行优化设计，设计思路可以从基站侧或终端侧两个方面开展：对于基站侧，可以考虑通过某14IMT-2030(6G)推进组IMT-2030(6G)Promotion Group种技术手段将天线激活信息和码本信息进行显示或隐示的指示，同时考虑复用现有的均匀阵码本，并在其基础上通过预处理的方式得到适配的稀布阵码本；对于终端侧，可以考虑设计基于测量信息主动上报的方式，协助基站侧进行预编码矩阵的选择。3.1.6小结小结总的来说，在实际移动通信环境中，稀布阵可在小幅性能损失的情况下，大幅降低天线数/射频通道数（可高达 50%），进而大幅降低整机成本和系统复杂度，因此实际部署可综合权衡性能下降和天线数降低两者之间的关系。面向未来 B5G 和 6G 移动通信网络，稀布阵技术未来有望在以下方向得到广泛研究与应用：高频段（例如毫米波）应用高频段（例如毫米波）应用：高频段波长小，天线尺寸可进一步压缩，因此面板空间相对于天线阵子更大，这也意味着每个天线单元有更大的排布空间，有利于相同规模阵元数在更大的阵面空间进行自由排布，进而降低阵元间耦合效应。因此该技术有可能成为未来全数字毫米波提升系统性能的可行解决方案。用户特定分布下的应用用户特定分布下的应用：面向未来高容量场景，大量用户有可能集中分布在某个方向（例如写字楼等），因此，未来移动通信系统可根据这些特定方向进行阵列优化，降低整机成本的同时满足上述方向用户获得较好的服务体验的需求，从而提升系统整体性能。3.2 基于基于 RIS 的的新型天线架构新型天线架构3.2.1基本原理基本原理RIS(Reconfigurable Intelligent Surfaces)技术是一种基于可调控超材料的新型天线架构。通过简单的改变有源器件两端的电压，即可改变 RIS 超单元的反射系数，进而影响反射电磁波的幅度和相位。对于无源 RIS 来说，为尽可能减小损耗，在设计上一般不做幅值调控，因此无源 RIS 主要通过调相来对电磁波进行调控。3.2.2技术优势技术优势从结构上来说，基于 RIS 的新天线架构基于超材料原理，可以实现远小于半波长的单元间距，因此在调控电磁波的精细程度上相对传统相控阵具有明显优势。接近于连续表面的 RIS 类器件能够实现更好的空间分辨率和更细的调控颗粒度。从成本上来说，基于 RIS 的新天线架构大部分采用成熟的 PCB 工艺，且无需采用能耗高的 RFchain 和相移器，因此在功耗上具有明显优势。同时 RIS 单个单元的工业化制造成本也相对较低，能够轻易地在低成本的情况下实现超大规模 MIMO。从部署上来说，基于 RIS 的新天线架构能够低成本地任意部署在靠近基站侧、靠近终端侧作为中继，部署在建筑物、装饰物、玻璃等的表面，具有改变电磁环境的能力。15IMT-2030(6G)推进组IMT-2030(6G)Promotion Group3.2.3传输方案传输方案对于无源 RIS 和大部分有源 RIS 天线架构来说，其至少存在基站馈源到 RIS，RIS到用户的两段级联信道。此时，传输方案可以总结为在发端的数字波束赋形（或混合波束赋形）与在 RIS 侧的模拟波束赋形的综合系统。当 RIS 用作发射机的模拟天线阵列时，基站使用纯数字天线阵列将发射信号发射到一个 RIS 阵面上，信号经由 RIS 阵面反射后达到 UE。此时 RIS 相当于基站的模拟天线阵列。与传统的天线阵列的区别在于 RIS 阵面天线无法直接通过电路与基站的射频电路相连。RIS 用作发射机的模拟天线阵列时，基站发射天线与 RIS 距离较近，可以考虑不定义新的接口。图 3.2-1 RIS用作收发机的设备实物将 RIS 面板用作发射机模拟天线阵列的一种实现结构如图 3.2-1 所示。图 3.2-1 所示收发机支持的数据流数为=2。将发送信号表示为=1,2,，数据流经过维度为 的数字预编码矩阵，输出路数据=1,2,=。路数据通过射频链连接的个馈源天线发出，传播到包含个单元的 RIS(相移矩阵为）面板，经由 RIS 进行模拟波束赋形以后发射出去。理想情况下 RIS 的调控矩阵为，从馈源到 RIS 的信道为；RIS 到 UE 的信道矩阵为。馈源信号不经过 RIS 直接到 UE 的信道表示为，噪声为0。则在完全已知信道信息的情况下 UE 侧的接收信号为=( ) 0（公式 3.3-2）在实际场景下，由于工艺的误差和信道测量反馈的损失，不可避免地会引入一些非理想因素。这些非理想因素可以建模为相位误差和信道估计误差。相位误差模型可以建模为= （公式 3.3-3）其中作为相位误差。对于 RIS 的两段信道来说，由于 RIS 无源的特性，其信道估计存在的误差以及发端和收端的噪声和导致的综合影响可以体现在最终估计的信道，即（公式 3.3-3）中的理想信道估计和和需要被替换为以下的实际模型?= （公式 3.3-4）?= （公式 3.3-5）16IMT-2030(6G)推进组IMT-2030(6G)Promotion Group此时的传输方案转化为，在考虑误差情况下，保证系统的指标（如接收信噪比）能够最大概率地满足要求。通过考虑误差的问题转化及其鲁棒波束赋形方法，可以使得系统的稳定性大大提升，系统的和速率在高信噪比情况下提升 50%，在优化目标为中断概率的问题中，系统的中断概率显著降低（在一些场景下可从 80%降低到 20%）25。3.3 RIS 辅助辅助 Mega MIMO100GHz 以上的 sub-THz 频段可以提供足够的带宽，用于满足 6G 系统 100Gbps 以上的极致吞吐需求。为弥补 sub-THz 信道的高路损，可以在基站（BS）应用基于可重构智能表面（RIS）的大尺寸阵列天线，降低成本和功耗。此外，Sub-THz 无线信道具有以视线（LoS）传播为主的“准光”特性，进而影响传统 MIMO 系统的空间复用能力和频谱效率。一种解决方式是利用大孔径阵列的近场效应。近场中 LoS 信道具有较高的自由度，因此可以利用近场 MIMO 技术提升 LoS 场景中的空间复用增益。例如，LoS-MIMO 技术已经应用于微波回传链路26。但传统 LoS-MIMO 技术中天线阵列固定不变，导致用于接入链路时，天线排布非理想，性能下降。本文介绍一种基于 RIS 辅助的新型 MIMO 架构，可以针对用户位置和姿态进行自适应孔径调节，以保障 LoS-MIMO 用于接入链路时的传输性能27。3.3.1基本原理基本原理图 3.3-1 所示为 RIS 辅助 Mega MIMO 示意图。基站（BS）天线采用相控阵-RIS 两重波束赋形天线架构。其中相控阵作为 RIS 的馈源，用于对 RIS 馈电；透射式 RIS 用于将入射波向用户设备（UE）传输。具体来说，各相控阵子阵将已预编码的数据流经过波束赋形向 RIS 传输。当 RIS 尺寸足够大时，可以通过控制相控阵波束调整 RIS 上入射波功率分布，从而选择性激活特定位置的 RIS 阵元。本方案中，为了降低馈电损耗并在传输方案设计中提高信道正交性，相控阵波束设计考虑聚焦波束。下一步，通过调控被激活的 RIS 阵元的相位使 RIS 波束指向 UE 方向，达到相干的波束赋形传输。而 UE 侧使用传统相控阵天线接收。图 3.3-1 RIS辅助Mega MIMO示意图上述相控阵-RIS 两重波束赋形天线架构可以在 BS 天线物理位置不变的条件下，等效的实现自适应孔径调节。从 UE 侧看，被激活的部分 RIS 阵元替代了相控阵天线，成为 BS 的等效发射天线。由于被激活的 RIS 阵元的的位置可以通过控制相控阵波束方向进行调整，因此等效的实现了自适应孔径调节。这是本方案与传统空馈相控阵的区别。17IMT-2030(6G)推进组IMT-2030(6G)Promotion Group3.3.2技术优势技术优势首先，RIS 辅助 Mega MIMO 在 LoS 传播为主的高频信道中可以获得较高的空间复用增益和传输性能。自适应孔径调节能针对用户位置和姿态将 BS 等效发射天线调整到最优位置27。此时，等效 MIMO 信道近似满足规范正交性（orthonormality），即等效MIMO 信道不仅正交，而且各特征值也相等，从而可以提高传输性能。相比基于传统相控阵的混合波束赋形（HBF），可以获得 1.5 倍2 倍的增益。其次，RIS 辅助 Mega MIMO可以降低 BS 天线的成本和功耗，提高能量效率。BS 可以利用较小尺寸的相控阵对 RIS馈电，降低成本和功耗。通过相控阵波束的合理设计，还可以达到较低的馈电损耗。尽管需要使用较大尺寸的 RIS，但仅有少数 RIS 阵元被激活用于传输，其它 RIS 阵元可以配置为功耗较低的关闭或随机散射模式，同时降低计算和控制复杂度。此外，RIS 辅助Mega MIMO 可以极大简化收发方案设计，实现不依赖发端信道状态信息（CSIT）的传输。具体传输方案将在下一小结中介绍。3.3.3传输方案传输方案由于 RIS 辅助 Mega MIMO 可以借助自适应孔径调节实现规范正交的等效 MIMO 信道，收发方案可以称为基于自适应孔径的规范正交空间复用（Orthonormal SpatialMultiplexing with Adaptive Aperture,OSMA2）。理想情况下，当 BS 已知用户的精确位置和姿态时，可以据此进行孔径调节和波束赋形，并且可以使用 DFT 矩阵对数据流进行数字预编码。由于等效 MIMO 信道各特征值相等，等功率分配即为最优功率分配。此时各接收天线可以接收到无流间串扰的数据流并直接解调，不再需要空域合并。当存在定位误差时，BS 可以根据有误差的用户位置和姿态进行孔径调节和波束赋形。各数据流可以不经数字预编码直接传输。此时只需要接收机基于收端 CSI 估计进行复杂度较低的匹配滤波（matched filter，MF）即可获得接近最优的性能。两种收发方案对比见表 3.3-1。表 3.3-1 两种RIS辅助Mega MIMO传输方案方案 1方案 2BS 侧（发端）信息精确用户位置和姿态有误差的用户位置和姿态数字预编码DFT 矩阵无（各子阵发射独立数据流）空域接收机无（各接收天线信号独立解调）基于 CSIRS 估计的 MF图 3.3-2 展示了本方案（OSMA2）在 100GHz 载频和 6.4GHz 带宽下的可达吞吐性能。可 以 看 到 在 较 实 际 的 中 等 发 射 功 率 区 间 内（1530dBm），本 方 案 可 以 达 到200800Gbps 的吞吐，是传统 HBF 的 1.5 倍2 倍。而且即使存在 50cm 的定位误差，方案性能下降仍小于 10%。18IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图 3.3-2 可达吞吐性能随相控阵天线总发射功率的变化4第四章第四章 信道状态信息反馈信道状态信息反馈4.1 近场球面波信道的近场球面波信道的 CSI 反馈码本设计反馈码本设计随着天线阵列向更大规模演进，如超大孔径天线阵列(Extremely Large Aperture Array,ELAA)、可重构智能超表面(RIS)技术等，用户会以更大概率出现在近场。以工作在100GHz、单元数 256*256、半波长间距的阵列为例，根据经典理论，其近场范围为 200m以内。已有 CSI 反馈方案基于用户位于远场假设，将电磁波视为平面波，基于此设计的CSI 反馈码本具有 1D/2D-DFT 向量形式。然而，近场信道体现出球面波特性，将已有CSI 反馈方案直接应用在近场会导致系统性能下降，例如波束赋形增益损失。因此，需要设计适配近场球面波信道的 CSI 反馈方案。4.1.1码本设计码本设计从宏观角度分析，平面波导向矢量仅包含俯仰角和水平角两个维度的信息，现有码本反馈方案即对两个维度的信息进行量化，通过克罗内克积得到码字构造的基本单元。值得注意的是，反馈变量并非分别对应俯仰角和水平角维度信息，而是经由两个维度进行组合变换。近场的 CSI 反馈码本设计仍然可以沿用远场研究的思路。根据近场球面波模型特性，假设用户球坐标为(,)，均匀线性阵（Uniform Linear Antenna,ULA）以及均匀平面阵（Uniform Planar Antenna,UPA）的导向矢量可以分别表示为：,=1,2,T（公式 4.1-1）sin cos222（公式 4.1-2）,=1,1,1,2,1,T（公式4.1-3）19IMT-2030(6G)推进组IMT-2030(6G)Promotion Group,sincos sinsin 1 sin2cos222 1 sin2sin222sin2（公式4.1-4）其中和,分别表示 ULA、UPA 各单元与用户 LoS 径的距离，决定了信号的相位关系，是设计反馈码本的重要依据。不难发现，当r取值较大时，分别可以得到 sin以及,sincos sinsin，相位随电磁单元坐标线性变化，等相位面是平面。因此，平面波模型可以视作球面波模型的特例，可以推断出依据球面波导向矢量,以及(,)设计的反馈码本能够兼容已有远场方案。另一点需要注意的是，在远场平面波近似中，,可以解耦合为关于以及的两项，因此已有远场 UPA 码本可以表示为 ULA 码本克罗内克积的形式。然而，对于近场球面波信道，,中存在关于的交叉项，因此 UPA 码本无法简单设计为 ULA 码本的克罗内克积。基于上述分析，ULA 和 UPA 的近场 CSI 反馈码本的基本码字构造单元设计如下：()=exp 2（公式 4.1-5）()=exp ? 0.5 1 22 0.5 1?22?（公式 4.1-6）其中，?以及均是根据 PMI 确定的码字生成参数，其余变量均为配置好的已知变量。对于 ULA，和可以理解为对 sin以及cos2/2的均匀量化；而对于 UPA，?和可以理解为对 sincos，sinsin以及 1/的均匀量化。当=0 时，上述码字构造单元退化为 DFT 向量形式，保持了对已有远场方案的兼容性。4.1.2性能评估性能评估为了评估所述近场反馈码本性能，仿真考虑 16*16 大小的 UPA，工作频率为 3GHz，重点关注基本码字构造单元的量化性能，即码字与 LoS 信道向量相关性maxH （公式 4.1-7）为了说明近场 CSI 需要设计与之匹配的码本，假设用户分布在 1,5的区域。在保持反馈总比特相同的情况下，对比方案包括：方案 1：传统 2D-DFT 码本，不考虑距离维度信息；方案 2：对,分别进行均匀量化；方案 3：对,分别进行均匀量化，对 1/进行均匀量化；方案 4：和所述方案区别仅在于对进行均匀量化。图 4.1-1 展示了基本码字单元对近场信道的量化性能，图例中的数字分别表示,三个维度的反馈开销。可以看到，所提方案实现了几乎最好的量化性能。此外，在有限的反馈开销限制下，应平衡角度维度以及距离维度的反馈开销。20IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图 4.1-1 不同方案量化性能比较4.2 近场非平稳信道的近场非平稳信道的 CSI 反馈设计反馈设计随着通信频率的提高和越来越大的天线阵列，近场区域的范围也逐渐变得不可忽视，由于阵列尺寸的增大和用户的近场分布，阵列不同区域的天线单元经历不同的传播环境，信道更容易呈现空域非平稳特性28。在信道非平稳的近场通信场景中，由于球面波传输距离和角度的影响，LoS 和多径信号的能量主要由基站天线阵列的一部分提供或接收29，即对于一个大规模天线阵列，环境中某些散射体的反射（或散射）信号可能只能被阵列某个局部区域内的天线接收到；反之亦然，只有阵列某个局部区域内的天线发送信号才能被环境中某些散射体反射（或散射）。这会导致不同用户可能会映射到天线阵列的不同区域，对信道测量和波束赋形都提出了更多的挑战。对于一个大规模天线阵列，LoS 径上的用户和反射径上的每个散射体都对应着一个天线阵列上一个能接收到信号的局部区域，该局部区域称为（多径在阵列上的）可视区域（Visibility Region，VR）29。基于基站天线阵列的子阵列分组情况，可视区域也可以用子阵列集合的形式表示。例如，图 4.2-1 所示为 LoS 径上终端用户对应的可视区域；图 4.2-2 所示为空间非平稳的多径信道，其中“远场 cluster 1”的可视区域为“可视区域 1”，“近场 cluster 1”的可视区域为“可视区域 2”。图 4.2-1 空间非平稳LoS径信道示意图21IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图 4.2-2 空间非平稳多径信道示意图考虑最简单的多用户 LOS 场景下的上行信道测量过程29，终端发送上行参考信号=1,，其中表示终端 k 发送的上行参考信号，网络侧接收到的信号 y 可以表示为 y=Hx n，其中表示信道矩阵，n 表示噪声。基站的大规模天线阵列沿着水平和垂直方向分割成=个子阵列，其中水平方向分成了份、垂直方向分成了份。针对每个终端 1,，基站根据每个子阵列(,)的位置和范围信息，利用最大比合并等方法分别检测来自终端的接收功率,并排序，从高到低依次将接收功率最高的子阵列加入终端的可视区域，直到满足总接收功率门限。考虑终端的可视区域为，表示基站天线阵列上满足总接收功率门限的子阵列集合，那么终端 k 只需要由可视区域中的子阵列服务，那么只需要考虑终端用户与其基站侧可视区域之间的信道,。基于近场信道非平稳特性的可视区域反馈，可以在网络性能损失很小的情况下，将信号处理复杂度大幅度降低（例如，在网络和速率损失低于 5%的情况下，可以将信号处理复杂度降低 90%以上29）。另外，上述过程也可以扩展到下行信道测量，或者进一步扩展到多径场景下的信道测量中。根据不同的近场信道状态测量方案，近场信道状态信息反馈需要考虑增加相应的测量结果，例如多径散射体的距离/角度信息、天线子阵列的分组选择信息等。基于近场信道的非平稳特性，可以考虑将天线选择的思想应用于近场多用户信道测量中，基于基站天线各个子阵的信道测量信息来确定近场多用户或者各个散射体的信号能量集中的子阵列分组，并基于子阵列分组结果进行波束赋形和组内干扰协调，有助于降低终端的信号处理复杂度，并降低网络信号传输的资源开销。4.3 面向模块化天线的面向模块化天线的 CSI 反馈优化设计反馈优化设计在超大规模天线技术研究中，通常将天线阵列形态划分为集中式和分布式两大类。在集中式天线阵列方面，全部天线位于同一个一维或二维面板中。集中式天线阵列的问题是信号源位置单一，导致覆盖范围容易受障碍物遮挡而出现空洞。此外，由于天线元件之间需要半波长距离，因此在实际可行的天线尺寸上能够集成的天线元件数量在低频段受到很大限制。在分布式天线阵列方面，要求环境中部署大量分布式接入点，每个接入点具有各自的天线阵列。分布式天线阵列的一项重要技术为联合传输，即利用多个接22IMT-2030(6G)推进组IMT-2030(6G)Promotion Group入点进行数据传输。本节主要研究一种介于集中式与分布式之间的模块化天线形态。该阵列形态需要首先预定义基本的天线模块，再根据部署场景将多个天线模块灵活地连接在一起形成完整的多天线系统，从而能够灵活设计阵列形态，并且可以降低安装维护难度。其中，每个天线模块由多个天线构成，且不同模块的天线形态可以不同。每个模块可以独立进行波束赋形，也可以实现多个天线模块之间的联合传输。模块化天线示意图如图 4.3-1 所示。为了更好的匹配建筑物的角落或弯曲的建筑表面，天线模块可以为不规则形状。图 4.3-1 模块化天线阵列示意图模块化天线的概念在学术界已经有了一定的研究，例如在文献30中提出了模块化天线的概念，其重点是研究分布式计算复杂度的问题。在预编码方面，该文献仅仅采用简单的 ZF 预编码，并未针对 CSI 反馈进行特殊设计。在文献31中提出了大规模 MIMO系统的模块化概念，并作为一种构建具有较小天线模块的单个大型 FD-MIMO 天线面板的方法。本章节重点关注分布式模块化天线的 CSI 反馈方案，通过对分布式模块化天线的反馈码本设计，辅助基站利用多个天线模块进行用户调度。在信道测量方面，基站向终端配置并发送用于信道状态信息测量的参考信号。终端接收参考信号并进行信道估计，获得每个天线模块的信道状态信息。在反馈方面，终端基于每个天线模块的信道状态信息，计算每个天线模块的子码本并进行联合上报，码本结构如图 4.3-2 所示。其中，W 为多个天线模块的预编码矩阵，W1和W2分别为每个天线模块的预编码子矩阵。对于每个预编码子矩阵，可以通过引入空域基矢量来实现两级码本结构。例如W1可以细分为矩阵W1,1和W1,2的乘积。其中W1,1为空域基矢量构成的矩阵，W1,2为空域基矢量之间的线性加权系数构成的矩阵。终端将空域基向量索引及其线性加权系数向基站进行反馈，用于基站恢复多个天线模块的预编码矩阵。23IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图 4.3-2 两级码本示意图当天线模块为不规则形态时，一种可行的方式是在不规则天线模块中选择一个一维或二维规则天线子阵列用于码本构造，如图 4.3-3（a）所示。此外，为了充分利用不规则天线模块中的全部天线，也可以将不规则天线模块进一步细分为多个一维或二维规则天线子阵列用于码本构造，如图 4.3-3（b）所示。其中，选择天线子阵列的方式有多种，例如优先选择天线数量最多的天线子阵列、垂直方向天线数量最多的天线子阵列或水平方向天线数量最多的天线子阵列等。（a）（b）（a）选择一个子阵列（b）选择多个子阵列图 4.3-3 不规则天线模块码本构造示意图4.4 面向面向 RIS 的的 CSI 反馈增强反馈增强在基于 RIS 构建的无线通信系统中，信道估计和 CSI 反馈不仅用于确定调度信息、波束赋形与预编码矩阵等，还要用于对 RIS 进行状态调控。随着阵列规模的增大，信道估计与 CSI 反馈的复杂度与开销也愈发增大，而 RIS 的无源特性也进一步增加了信道信息获取的复杂度。本节考虑对基于 RIS 构建的无线通信系统的信道状态信息获取方法进行增强。在如图 4.4-1 所示基于 RIS 构建的无线通信系统，基站到 UE 之间的信道包括基站-RIS、RIS-UE 这两段信道。为了调整 RIS 的状态，最理想的方式是可以获取 RIS-UE 这段信道的信道状态，并基于该段信道的信道状态确定 RIS 的状态。为了获得基站侧发射机的波束赋形和预编码矩阵，则需要获取基站-RIS 或基站到 UE 的信道信息。假设基站到 RIS段的信道为1，RIS 到 UE 段的信道为2。图 4.4-1 基于RIS 的无线通信系统现有的数模混合波束赋形架构下的波束赋形方案，是先确定模拟赋形，在固定的模拟赋形基础下，进行信道估计获得数字赋形。在加入 RIS 的通信系统中，也可以使用类似的方案，通过波束扫描确定 RIS 的相移矩阵，然后在确定的 RIS 相移矩阵下，进行信道测量，获得信道估计，用于基站侧的波束赋形。该方案包括两个过程：波束扫描过程和信道信息获取过程。24IMT-2030(6G)推进组IMT-2030(6G)Promotion Group波束扫描过程中，基站需要向 UE 发送导频信号，进行波束测量。测量过程包含基站波束和 RIS 波束。假设基站有 N 个波束，RIS 有 L 个波束，则需要进行 N*L 个导频信号测量。其中，基站波束指基站发射波束，RIS 波束指 RIS 相移矩阵，一个 RIS 相移矩阵对应一对 RIS 接收波束与 RIS 发送波束对。UE 在接收到导频信号后，会将测量结果上报基站。基站根据 UE 上报的测量结果确定基站发送波束和 RIS 相移矩阵。信道信息获取过程中，基站根据波束扫描过程中确定的发送波束和 RIS 相移矩阵，在对应的基站波束和 RIS 波束上发送导频信号，进行信道测量。UE 接收导频信号获得信道估计信息并上报给基站。基站利用 UE 上报的信道信息进行调度。在信道信息获取过程过程中，RIS 的相移矩阵保持不变，直至基站基于 UE 反馈的信道信息发送数据。该方案导频开销较大。随着频段增高，RIS 的规模增大，RIS 波束变窄，覆盖服务区域所需的波束数量增多，信道信息获取的难度会大增，对于测量开销与时间也会增加。为了降低复杂度和开销，考虑将 RIS 阵列划分为多个子阵，仅对部分 RIS 子阵进行信道测量，然后通过空域插值获得完整 RIS 阵列的信道。该方法假设在 RIS 子阵单独控制，可独立开关。以图 4.4-2 所示的 RIS 阵列为例，将 RIS 阵列分为 59 个 RIS 子阵，其中蓝色高亮的 6 个子阵具备简单信号发射功能，发送用于 RIS-UE 段信道测量的测量信号。通过对图中蓝色高亮的 6 个子阵的进行独立测量，获得 6 个子阵对应的信道信息。然后通过对 6 个子阵进行空域插值获得完整 RIS 阵列对应的信道信息。图 4.4-2 RIS示意图根据图 4.4-1 所示链路，经过 UE 接收到 RIS 反射的信号为：=21 （公式 4.4-1）其中，x 为基站发出的信号，1为 BS-RIS 段信道，2为 RIS-UE 段信道，为 RIS的调控矩阵。而当 UE 接收的是 RIS 发出的信号时，该信号可以表示为=2 （公式 4.4-2）整个测量过程分为两部分：RIS-UE 测量过程：逐一打开高亮 RIS 子阵的发射模块，发射测量信号，UE 接收测量信号获取每个高亮子阵的 RIS-UE 段的信道信息，根据所获得的 6 组信道信息的空域插值结果获得 RIS-UE 的完整信道信息2。BS-RIS-UE 测量过程，关闭 RIS 子阵的发射模块，基站发射导频信号，经过 RIS转发给 UE，UE 测量获得 BS-RIS-UE 的等效信道=21的信道信息。最后，利用测量得到的2和，以及已知的，获得 BS-RIS 段的信道1的信息，进而确定基站的波束赋形。这一过程，相较传统的波束扫描方案，大大降低了波束扫描过程波束扫描过程中的波束测量开销与波束扫描时间。无需多次扫描与测量即可确定基站25IMT-2030(6G)推进组IMT-2030(6G)Promotion Group和 RIS 处的波束。但是，根据对空域插值的精度要求，在计算1的信息时，可能存在一定的计算复杂度。在基于 RIS-UE 的信道信息确定 RIS 调控矩阵时，也可以选择多个可能的 RIS 调控矩阵，在第二阶段测量过程中进行选择或校正，降低 RIS-UE 的信道信息精度损失可能带来的影响。5第五章第五章 预处理算法预处理算法5.1 面向广义极化面向广义极化 MIMO 的预处理算法的预处理算法在信道衰落独立同分布和码长无限（100bit）假设下，基于经典香农信息论的 MIMO信道容量限为log2(1 SNR)，与空间信道的自由度 m 成正比。然而，经典的容量限没有考虑到信道编码在有限码长条件下的影响。尤其当码长降低到一定程度（例如低于 100比特），MIMO 系统的可达速率会发生严重恶化32。因此，亟需开展有限码长条件下的MIMO 传输方案设计，提升 MIMO 系统的可达传输速率。当前 MIMO 系统预处理方案设计主要是在无限码长条件下以系统容量、最大似然和用户信干噪比等为准则，旨在实现系统容量、用户公平性等指标的最优。在有限码长条件下，信道编码方案也将对 MIMO系统的传输速率产生重要影响，开展信道编码与 MIMO 传输方案的联合设计对于提升MIMO 系统在未来低时延、高可靠场景下的传输性能显得尤为重要。图 5.1-1 极化编码-调制-预编码的联合设计Polar 码是基于信道极化理论提出的一种线性分组码，相比于 4G 的 Turbo 码和 5G数据信道的 LDPC 编码，Polar 码在短码条件下具有明显的性能优势，是目前唯一数学证明可以达到香容量农限的编码方案，被确定为 5G 控制信道编码方案。信道极化现象已经被发现广泛地存在于很多其他信号处理的过程中。如图 5.1-1 所示，通过将比特域的极化编码扩展到调制和预编码，可以实现比特、符号和数据流的联合设计，使极化效果可以逐级累加，从而增大极化深度、提升 MIMO 预处理方案的传输性能。5.1.1算法描述算法描述如图 5.1-2 所示为基于广义极化的 MIMO 预处理框图。发送端的原始比特经过极化编码与调制后生成符号流。经过层映射和预编码，最终通过 MIMO 信道传输到接收端。系统的第一级进行层信道极化分解，第二级和第三级分别完成调制和比特极化分解最终得到比特极化信道，实现数据流、调制符号、比特的广义极化编码。26IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图 5.1-2 基于广义极化的MIMO预处理框图图 5.1-3 基于广义极化的MIMIO预处理框图针对第一级，需要通过极化编码与多天线预处理的联合设计，增强数据流间的极化效果进而提升系统整体的极化增益。如图 5.1-3 所示，预编码矩阵 F 需要在系统容量最大的前提下，增大数据流间的极化效果（可靠度差异）。因此，将预编码矩阵 F 定义为两个子矩阵的乘积：F=WQ（公式 5.1-1）其中，子矩阵 W 可以由二维 DFT 向量采用两级码本 W1和 W2的乘积构造：W=12；子矩阵 Q 为极化增强矩阵，可以增大数据流之间容量差异33，维度为 LL，L 表示数据流（Layer）数。相应地，子矩阵 Q 需要满足：=arg Qmax1Li=1LIi I?2?（公式 5.1-2）利用酉矩阵 W 具有H=的特性，不失一般性地，利用酉矩阵的排序和旋转可以构造极化增强矩阵 Q，数学公示表式为：=DFT（公式 5.1-3）其中，l=0,N-1 为旋转角度参数，PL为 LL 的排序矩阵，由单位阵 IL按照数据流的一定排序 r=r1,r2,.,rL经过初等变换得到，即=()。r=r1,r2,.,rL可以通过量化排序索引的方式，利用 log2(L!)比特进行反馈。QDFT为旋转基矩阵，数学公式表示为：=12/2(1)/（公式 5.1-4）其中，N 为固定常数，用于定义旋转角的量化精度。为了确定最优的排序和旋转角度，27IMT-2030(6G)推进组IMT-2030(6G)Promotion Group可以建立容量约束下的极化效果最大化问题并进行求解，确定最优的极化增强预编码矩阵33：,1=1?2?S.t.QR=H(,)，(,)=P()()，l=1,.,L，i=1,.,N!（公式 5.1-5）5.1.2性能评估性能评估表 5.1-1 仿真参数参数数值信道时隙（N）256码率（R）0.25,0.5调制阶数（m）2,4,6流数（L）4,6参照表 5.1-1 中的参数设置，对基于排序和旋转的极化增强 MIMO 方案（GP-RP）的误块率（BLER）进行仿真。在仿真中主要考虑两种对比方案：一是 QR 分解的极化MIMO 方案（PC-MIMO-QR），二是将 H 特征分解矩阵和 DFT 矩阵旋转结合的预编码方案（DFT-QR）。图 5.1-4 GP-RP、PC-MIMO-QR和DFT-QR方案容量对比图 5.1-4 首先比较了 GP-RP、PC-MIMO-QR 和 DFT-QR 方案中不同数据流的信道容量方差。仿真中将码率设置为 0.5，数据流数目为 4，分别采用 16-QAM 和 64QAM 调制，随机对信道矩阵 H 进行 100 次实现并取平均。从图中可以发现，GP-RP 方案数据流间的信道容量方差均高于 PC-MIMO-QR 和 DFT-QR 方案。从而说明采用矩阵的排序和旋转后，GP-RP 方案能够实现更大的极化效果。图 5.1-5 在数据流数为 4 的情况下，比较了 GP-RP、PC-MIMO-QR 和 DFT-QR 方案采用不同调制阶数的 BLER 性能。由图 5.1-5 可以发现，在 QPSK、16-QAM 和 64-QAM配置下，GP-RP 的 BLER 性能均能够优于 PC-MIMO-QR 和 DFT-QR 方案，这是由于 GP-RP方案能够实现更大的极化深度，从而提升了传输性能。例如对于 QPSK，当 BLER 达到10-2时，GP-RP 所需的信噪比相比于 PC-MIMO-QR 和 DFT-QR 方案分别获得了 1.2dB 和0.6dB 增益。并且当采用更高阶的调制方式时，GP-RP 的信噪比增益可以进一步增大。例如，采用 16-QAM 调制后 PC-MIMO-QR 与 GP-RP 方案的差距缩小到约 1dB。这是由28IMT-2030(6G)推进组IMT-2030(6G)Promotion Group于在相同信道数 N 的条件下，采用高阶调制能够增大码长，从而也说明了 Polar 更适用于短码场景下的传输要求。图 5.1-5 不同调制阶数下GP-RP、PC-MIMO-QR和DFT-QR方案的BLER广义极化 MIMO 预处理方案改变了传统通信系统各个模块“分离设计”的范式，实现Polar 码与 MIMO 预编码的联合设计，有利于满足未来 6G 场景中高可靠、低时延条件下的大容量通信需求。在超大规模 MIMO 系统中，可以利用天线规模的增大进一步获取更多极化编码增益，提升传输性能，最终实现时延、可靠性、系统谱效的优化折衷。5.2 对抗波束分裂的预编码码本设计对抗波束分裂的预编码码本设计在毫米波频段和太赫兹频段，系统带宽可能达到几个 GHz 或几百 GHz，此时使用传统的混合模拟数字波束赋形，将会导致严重的波束分裂（beam squint）现象，即波束像光的色散一样偏离瞄准线而扩散到其他方向，而且波束偏离瞄准线的角度随着信号频率的变化而变化。波束分裂会降低终端接收信号的功率，降低通信系统的传输速率。因此，有必要设计一种能够解决超大规模天线在超大带宽下波束分裂的有效方案。本节通过将大带宽的信号分解成多个子带，分别针对每个子带单独设计数字波束赋形码本，将模拟波束赋形所导致的波束分裂，按照子带补偿回来，以降低降低波束分裂带来的性能损失。本节基于的信号模型为：假设宽带信号的中心频率为，带宽为 B，带宽范围为（-B/2, B/2），基站有根发送天线，有个射频链，流数为，终端有根接收天线，设为模拟波束赋形矩阵，维度为，设为数字预编码矩阵，维度为，待发送的符号向量为，其维度为 1，则基站发送的信号的表达式为=（公式 5.2-1）模拟波束赋形矩阵的设计过程包括：基站将系统带宽 B 均匀划分为 M 个子带，其中每个子带的带宽为 W=B/M，设子带 m 的中心频率为，其中 m 的取值为 m=1,M。每个子带的带宽 W 的设置规则是：使得频率 W/2 或频率 W/2 取得最大天线增益时的方向角与预设的中心方向角0之间的角度差=0小于预设的门限值。基站针对每个子带 m 的中心频率，设计等效的模拟波束赋形矩阵，使得频率在预设角度方向0处的天线阵列的增益最大。29IMT-2030(6G)推进组IMT-2030(6G)Promotion Group数字波束赋形矩阵的设计过程包括：假设移相器不变，其所生成的模拟波束赋形矩阵为是针对全带宽的，为实现分子带的等效模拟波束赋形矩阵，需要在的后面乘以一个补偿的矩阵。的设计原则是使得尽量接近，且为了保证发送功率不变，应该是一个酉矩阵，即应满足以下条件：min，s.t.=（公式 5.2-2）其中 表示矩阵的 F 范数，上述最优化问题为典型的 Procrustes 正交问题，其最优解为以下闭式解：=（公式 5.2-3）其中和是矩阵进行奇异值分解得到的酉矩阵，即=。虽然是为了逼近分子带的模拟波束赋形矩阵而设计的，但是在数字域实现的，即相当于在数字预编码矩阵的前面乘以了。数字预编码矩阵的设计仍可以按照之前的设计规则进行。即等效的数字预编码矩阵为=（公式 5.2-4）即此时子带 m 上的发送信号的表达式为=（公式 5.2-5）基站针对常用的预设角度0、常用的子带数目 M、以及子带的带宽 W，设计与预设角度0对应的等效模拟波束赋形矩阵wm，并基于wm进一步获得等效数字预编码矩阵=，其中 m=1,M，所有0、M 和 W 的取值，以及不同0、M 和 W 取值下与等效数字预编码矩阵对应的等效数字预编码矩阵=构成基站的发送码本。鉴于上述所设计的对抗波束分裂的码本是通过将大带宽的信号划分为多个子带，并针对每个子带对由于模拟波束赋形所导致的波束分裂在数字域进行预补偿，即相当于对每个子带都加了一个数字滤波器，整个带宽上的波束分裂被按照子带控制在一个合理的范围内，可以预期其能够减小大带宽下波束分裂所导致的性能下降，提高通信性能。6第六章第六章 非平稳信道下接收机算法设计非平稳信道下接收机算法设计在超大规模 MIMO 系统中，由于大量的天线和用户，使用线性检测器和最优非线性检测器进行信号检测，将导致极大的计算复杂度。这是因为线性检测器的复杂度主要源于对高维矩阵进行的复杂矩阵运算。近年来，基于消息传递(MP)算法的 MIMO 检测器得到了广泛的研究。基于 MP 算法的期望传播(EP)34算法不需要传递整个分布的样本值，只关注矩信息等充分的统计量。因此，EP 具有更低的复杂度和更好的性能。文献35基于期望传播算法原理提出了集中式 MIMO 检测器，性能优于多种经典 MIMO 检测器方案。在该场景下，集中式 EP 算法中存在的矩阵求逆过程所带来的复杂度是无法承受的。本章提出了一种采用分布式结构的新型低复杂度 EP(PE-EP)检测器。采用类似于36、37的子阵 EP 结构来适应大规模天线阵中出现的空间非平稳现象，并将泰勒级数的多项式展开式用于降低 EP 的复杂度。30IMT-2030(6G)推进组IMT-2030(6G)Promotion Group6.1 算法描述算法描述考虑一个超大规模 MIMO 场景，其中基站端配有 N 个接收天线，为 K 个单天线用户提供服务。用户符号向量为=1,2,其中表示星座集。基站端 N 根天线被分成 C 个不相交的子阵列处理单元，每个子阵列中的天线数为，因此存在=1=?。并考虑空间非平稳性的影响，第 c 个子阵列的等效基带接收信号模型为=? (公式 6.2-1)其中，表示第 c 个天线子阵接收到的信号矢量；?表示独立同分布的瑞利衰落信道矩阵且存在列非稀疏列；(0,2)是第 c 个天线子阵列中的 AWGN。将因子图与 EP 算法相结合，所传输的符号矢量的后验概率可被转换为因子图中的数学模型，具有以下表达形式()0()()?(公式 6.2-2)其中，0()表示先验分布；()?表示似然函数；()可等效为一个边缘似然，该概率模型所对应的因子图模型如图 6.2-1 所示。其中，方形代表因子节点(FN)，圆形代表变量节点(VN)，消息传递则表示 FN 和 VN 之间的信息迭代过程。设符号代表由 VN 到 FN 传递的信息；符号则代表由 FN 到 VN 传递的信息。图 6.2-1 因子图模型结合和积算法，第 c 个子阵列中第 j 个用户符号的实际后验概率表示为=()()(公式 6.2-3)定义矢量置信度()并服从指数族分布，用于表示第 c 个子阵列中检测符号的近似后验分布。使用 KL 散度运算来刻画(|)和()之间的偏差程度，并找到使得 KL散度最小的()，且两个概率分布的 KL 散度最小化等价于矩匹配。()的均值和方差由 MMSE 估计生成，定义其协方差矩阵为且后验均值为?，即=(12 )1(公式 6.2-4)?=(12 )(公式 6.2-5)其中，=和=1,2,分别表示 x 的先验方差和先验均值，表示为 K 维的单位矩阵。并使用平均方差=(1()1作为第 c 个子阵列的方差，即有()=(;?,1)。迭代更新实现矩匹配后，根据(公式 6.2-3)有31IMT-2030(6G)推进组IMT-2030(6G)Promotion Group()()()(公式 6.2-6)其中，()和()都近似为高斯分布，在第 l 次迭代过程中它们的分布分别被定义为;(),()1和;(),()1。其中，和分别等价代表先验均值向量和先验方差。虽然 EP 算法能够达到良好的检测性能，但每一次迭代过程中，由于(公式 6.2-4)涉及到的矩阵求逆运算使得每一次迭代计算复杂度量级为(3)，在该场景下的计算复杂度增加。因此，提出一种基于多项式展开（Polynomial Expansion，PE）的 EP 算法，简称为 PE-EP。对任何正定 Hermitian 矩阵 X 有1=()1=0()? (公式 6.2-7)其中，是对应维度的单位阵；是保证近似精度的收敛因子；是仅截断到第 J 项所导致的误差。将其应用至(公式 6.2-4)，对于任意子阵可表示为=0 2 ?(公式 6.2-8)PE 的收敛速度由控制，因此使用文献38中的最优收敛因子opt的获取方式和文献39中的近似特征值求法，在降低复杂度的同时能够保持良好的性能。图 6.2-2 PE-EP因子图模型子阵列处理单元完成前端多项式展开的 MMSE 信号检测，在每个子阵处理本地信息之后，消息被并行地通过最大比合并方式合并到中央处理单元中。如果迭代没有停止，合并后的统计信息将被中央处理单元作为先验数据并行反馈给子阵列处理单元。在进行L 次算法迭代后最终输出用户符号估计值。基于以上流程的检测器因子结构如图 6.2-2所示。6.2 性能评估性能评估对所提算法的计算复杂度进行分析。由于空间非平稳特性的影响，每个子阵内只有部分强功率用户被接收进行处理，即每个子阵内实际处理用户数为。为更加清晰的对32IMT-2030(6G)推进组IMT-2030(6G)Promotion Group比各种算法复杂度，给出表 6.3-1 计算复杂度对比，其中 J 为最大截断项满足 1，L为 EP 的迭代次数，LADMM为 ADMM 的迭代次数。通过分析知，基于空间非平稳特性所构建的子阵化架构，每个子阵内的用户数和接收天线数都远低于集中式处理架构，即，。这大大降低了基站的数据处理开销。且 PE-EP 检测器在最大截断项取=1 时，复杂度可降低至(2)量级，这降低了基站信号处理的计算复杂度。当然，有限的截断项会导致信号检测器性能下降。表 6.3-1计算复杂度对比算法计算复杂度集中式 MMSE3 32 2 1集中式 ZF3 2 集中式 EP35(3 52 2 4 2)ADMM40(1033 2 2 82 5) ADMM(2 2 2)子阵化 EP37(3 52 2 4 2)子阵化 PE-EP(1)(3 2) 52 2 6 1)对本文所提出的低复杂度信号检测器进行性能仿真分析。以误码率作为信号检测性能指标，采用 16QAM 调制方式，EP 算法迭代次数均为 L=5，整个阵列被分为 4 个子阵，每个子阵内天线数平均分配，即=(=4)，基站端总天线数 N=1152，总单天线用户数为 K=128，且每个子阵中的强功率用户数在仿真时设置为=/4。在图 6.3-1 中，对所提子阵化低复杂度信号检测器进行了不同信噪比下的性能测试。可以发现集中式 EP 算法性能显著优于传统检测算法 MMSE，且所提子阵化 EP 检测器性能接近集中式 EP 检测器。对所提的 PE-EP 检测器进行性能分析，分别测试其在最大截断项 J=1 和 J=2 时的检测性能。当最大截断项取 J=1 时，所提 PE-EP 检测器接近原始子阵化 EP 检测器的性能，当 J=2 时检测器性能近一步提升，但计算复杂度已不具优势。在图 6.3-2 中将所提算法与传统线性检测器和子阵化架构 ADMM 检测器进行性能的比较。对 ZF 检测器、MMSE 检测器、EP 检测器、迭代次数为 5 次时 ADMM 检测器与所提子阵化 EP 和基于 1 阶展开的 PE-EP子阵化检测器进行性能对比。可以发现 ADMM检测器性能明显弱于所提检测器。并且，EP 算法性能显著优于传统检测算法 MMSE 和ZF，且所提子阵化 EP 检测器性能接近集中式 EP 检测器。33IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图 6.3-1算法性能分析图 6.3-2不同检测器性能对比7第七章第七章 波束管理波束管理7.1基于基于 RIS 的波束管理的波束管理在 5G NR 中，支持网络控制的转发器（Network Controlled Repeater,NCR）技术，NCR 可以对网络侧发送的信号放大转发，提升信号传输质量。由于 NCR 用于特定位置的信号补盲，且具有较低成本和放大功能，因此天线规模通常不会很大。NCR 对 UE 是透明的，UE 仅能检测网络侧-NCR-UE 之间的等效信道。在基于 RIS 的超大规模天线系统中，RIS 同样可以对网络侧发送的信号进行转发，通常考虑无源 RIS，即无信号放大功能，通过使用数量巨大的 RIS 单元进行波束赋形以提升赋形增益。相比 NCR 系统，RIS 单元的数量更多，波束数量也更多，网络侧-RIS-UE之间的等效信道的波束组合数量会更多。因此，在进行波束扫描时，RIS 系统需要扫描的波束组合数相比 5G 系统会显著增多。例如，网络侧的发送波束数量为1个，UE 的接收波束数量为2个，RIS 的接收波束和发送波束数量分别为R和T个，则波束组合数量高达1RT2组。在 5G NR 中，UE 在一次波束测量上报中至多对 64 个波束进行测量，即使 UE 处理能力在 6G 系统中成倍提高（如一次测量 128 个波束），仍然会显著增加波束测量上报时间，降低数据传输效率。因此，在基于 RIS 的超大规模 MIMO 系统中，需对 UE 的测量上报方法进行增强，寻求次优的波束扫描方法，降低 UE 波束扫描的时间。本节提出一种分级的波束扫描方案，将 2 跳等效链路分解为多个子链路，分别对子链路的波束组合进行扫描，例如，首先基于网络侧-RIS 之间链路进行网络侧发送波束扫描，然后分别对 RIS 接收波束进行扫描，对 RIS 发送波束进行扫描，最后对 UE 接收波束进行扫描。在对网络侧的发送波束进行扫描时，可以将 RIS 处的控制节点（用于接收网络侧的控制信息并对 RIS 进行调控，相当于 NCR 系统中的 NCR-MT），上报最优波束。本方案要求控制节点和 RIS 在地理位置上较接近，即二者对应的网络侧的最优发送波束是相同的。在对 UE 侧的接收波束进行扫描时，可以令网络侧的发送波束、RIS 的接收波束、RIS 的发送波束固定，而后 UE 确定与当前网络侧和/或 RIS 波束对应的接收波束。在介绍 RIS 接收波束扫描或 RIS 发送扫描前，首先介绍一下 RIS 的调控矩阵。假设 RIS 阵列有行列，即共有个 RIS 单元，RIS 阵列的调控矩阵可以表示为行列的对角矩阵。可以将对角矩阵拆成如下形式：=（公式 7.1-1）其中，和均为对角阵，用于对网络侧发送的信号进行接收调控，用于对RIS 转发的信号进行发送调控，为补偿路损等影响（如果需要的话）的相位调控矩阵。可以对 RIS 各调控子矩阵进行设置，使得 UE 的接收功率最大化。当 RIS 仅用于接收信号赋形时，可以控制 RIS 的调控矩阵为=，即=,=，其中为单位矩阵；当 RIS 仅用于发送信号赋形时，可以控制 RIS 的调控矩阵为=，34IMT-2030(6G)推进组IMT-2030(6G)Promotion Group即=,=；当 RIS 仅用于相位调控时，可以控制 RIS 的调控矩阵为=，即=,=；类似地，当 RIS 既用于接收信号赋形，又用于相位调控时=，=；当 RIS 既用于发送信号赋形，又用于相位调控时=，=。图 7.1-1 给出了一种 RIS 接收波束扫描的示意图，其中，基站的发送波束是固定的。由于 RIS 不具备数字信号处理功能，可以使用控制节点辅助 RIS 进行接收波束扫描（即确定）。图 7.1-1 RIS接收波束扫描示意图在进行 RIS 接收波束扫描时，RIS 的接收波束可变，为简化设计，假设=，控制节点接收到网络侧发送的信号，以及 RIS 为其转发的信号，接收信号表示为= ，其中，和分别为网络侧-控制节点间信道、RIS-控制节点间信道、网络侧-RIS 间信道，和分别为网络侧的发送波束矩阵和控制节点处的接收波束矩阵，和分别是网络侧发送的参考信号和控制节点处的接收噪声。通常假设控制节点具有较少的天线，因此可以对应一个固定的接收宽波束。通过对进行扫描，控制节点接收的参考信号的测量值是在发生变化的，最优取值可以是令控制节点接收参考信号测量值最大的接收波束。本方案中将控制节点作为观测点，而不使用 UE 作为观测点，去测量最优 RIS 接收波束的原因是：RIS 调控矩阵中的参数和均未确定，会加重 UE 的测量上报负担，并且 RIS 接收波束的确定过程仅和网络侧到 RIS 间信道有关，和 UE 相关的链路无关，因此，由控制节点辅助 RIS 进行接收波束更加合适。另一方面，在训练 RIS 接收波束时，网络侧可能还未掌握网络侧到 RIS 间的信道信息，更无 RIS 到 UE 之间信道的信息，此时的调控矩阵设置未针对 RIS 到 UE 信道进行优化，在此情况下，UE 可能无法收到 RIS转发的信号，或者在较低的信号质量下测量并不可靠。此方案可以工作的前提是，控制节点需要部署在 RIS 的反射或透射范围内，例如，控制节点可以部署在 RIS 阵面前面，即只要不部署在 RIS 背板后面即可。控制节点可以仅配置单根天线，无需复杂度波束赋形操作，测量过程也相对简单。图 7.1-2 给出了一种 RIS 发送波束扫描的示意图，其中，基站的发送波束和 RIS 的接收波束是固定的，此时=或=，由 UE 作为观测点，UE 可以将接收参考信号最大测量值对应的波束作为 RIS 最优发送波束并上报给网络侧。注意，RIS接收波束固定指的是固定子矩阵不变，通过改变进行发送波束扫描。在实际调控过程中，可以将调控矩阵整体量化为一个码书，通过选取不同码字实现不变，变化的效果。35IMT-2030(6G)推进组IMT-2030(6G)Promotion Group图 7.1-2 RIS发送波束扫描示意图在本方案中，首先对两跳链路涉及到的波束逐一进行波束扫描，可以使得每个的波束选取是局部最优。并最终对两跳等效链路进行扫描（如基站发送波束固定、RIS 波束固定、RIS 发送波束固定，对 UE 接收波束进行扫描），即令等效链路接收信号功率最强。局部最优虽然不能保证确定的波束对全局最优，但是却是一种平衡复杂度和性能的折中方案。相比两跳链路所有波束联合进行扫描的方案，本方案的扫描次数可以显著降低。例如，对网络侧的发送波束进行扫描（共1个波束，进行1次扫描），对 RIS 接收波束进行扫描（对应R次扫描），对 RIS 发送波束进行扫描（对应T次扫描），以及对 UE 接收波束扫描（对应2次扫描），每次仅对一个波束进行扫描，需要测量的波束总数或扫描总次数为1 R T 2，相比1RT2，波束测量次数显著降低。此外，还可以与5G NR 类似，在扫描的初始阶段，对多个波束进行联合粗扫描，例如对网络侧和 RIS 之间链路进行收发波束联合粗扫描，或对网络侧-RIS-UE 链路进行 4 波束联合粗扫描，而后再进行单个波束扫描，本方案中的 RIS 接收波束或 RIS 发送波束扫描方法仍然适用。7.2 分层分层 RIS 波束训练技术波束训练技术由于 RIS 具有大规模的特点，其在空域上的角度分辨率很高，波束窄且增益高，指向精确，但是这也带来了导频开销大，通信效率下降的问题。因此，为了降低开销，利用分层的思想进行 RIS 波束训练的方案设计十分有必要。分层训练需要在空间上实现宽波束的覆盖，这对于传统天线阵列比较容易实现，对于 RIS 来说，分层码本的设计由于级联信道的存在较难实现。7.2.1算法描述算法描述以 RIS 初始搜索空间规模为 M=16 的情况举例，分层训练的设计逻辑采用二叉树的架构。这 16 个单波束方向将所服务的区域分为 16 个子空间，与基础的 16 个单波束方向一一对应。波束训练的目标即是找到这 16 个中能够最优的码字。对于传统线性训练来说，需要 O(M)时间复杂度的训练过程才能确保找到最优的码字。而分层训练通过每一层不同精度的宽波束扫描，从宽波束到窄波束，逐渐搜索到可能的最优的单波束方向。如图 7.2-1 所示，水平方向代表波束能够覆盖的空域，从上到下代表沿时间轴的码本搜索过程。第一层（代表第一个搜索时隙）的两个宽波束方向分别覆盖了1,2,3,4,5,6,7,8号单波束方向对应的空域和9,10,11,12,13,14,15,16号单波束方向对应的空域范围；通过收端反馈，选择第一层第一个宽波束方向 C（1，1）的子分支 C（2，1）和 C(2,2)进行36IMT-2030(6G)推进组IMT-2030(6G)Promotion Group波束扫描，最终通过如下图绿线所示的波束训练反馈和决策过程，得到单波束方向的第6 号码字即为最优的波束指向。对于 RIS 来说，更多的波束也可以继续分层迭代，进行更深层的训练和扫描。（，）（，）（，）C(4,6)图 7.2-1 分层训练的设计逻辑训练决策示意图分层训练的生成方法一般基于经典的 PA（Pattern Analysis）算法图样叠加来实现宽波束。对于图 7.2-1 来说，其横向代表了波束方向的覆盖范围，纵向代表每一层波束方向按时间顺序从上层到下层进行波束训练和决策。对于每层分支数为 U 的分层训练过程来说，其在第 L 层的第 K 个波束方向，其下一层的子空间波束方向与其的对应关系为，=1 1( 1,)?（公式 7.2-1）其中累加运算符表示其在空域覆盖上的叠加关系。7.2.2性能评估性能评估分层训练常用于通信环境较好的情况下，此时可建模信道为莱斯信道，在莱斯因子足够大（LOS 主径足够强）的情况下，对于规模为 M 的基础码本来说，其导频开销为（M）；而对于分层训练来说，若每层的分支为 K，其导频开销为（( 1)）。根据如图 7.2-2 所示的仿真结果，尽管分层训练可以实现时间复杂度的高效降低，但是，由于多波束形成时产生的波束畸变，分层训练的性能相较于传统码本仍有所下降（平均成功率 85%左右，且与信道本身特征强相关），仍然需要进一步进行波束整形来实现更好的性能效果。图7.2-2 两种分层码本的波束训练成功率37IMT-2030(6G)推进组IMT-2030(6G)Promotion Group8第八章第八章 总结及发展建议总结及发展建议8.1 总结总结本研究报告汇集了 IMT-2030 超大规模天线技术组近一年来在超大规模 MIMO 关键技术研究领域中所取得的进展和阶段性成果，主要包括：超大规模天线的近场及远场信道建模方法；包括稀布阵、RIS 辅助 Mega MIMO、RIS 等新型天线架构方面的研究进展；面向近场信道及新型天线阵列的 CSI 反馈码本设计；面向新型天线阵列、大带宽的预编码设计；面向近场非平稳信道的接收机算法设计；以及面向新型天线架构的波束管理研究进展等。8.2 研究方向发展建议研究方向发展建议超大规模 MIMO 技术是 6G 的关键技术之一，将在提高平均谱效、区域流量密度等方面起到重要作用，为使得未来 6G 技术具有更优越的性能，未来超大规模 MIMO 的关键技术需要在以下方向取得关键性突破：即能够准确刻画超大规模 MIMO 信道近场特性又能兼容远场信道特性的近场远场混合信道建模方法；具备低功耗、低成本、支持更大规模天线的新型天线架构；具有趋近于连续孔径的全息 MIMO 天线阵列；低反馈开销的适用于超大规模天线的 CSI 反馈方案；低计算复杂度的超大规模 MIMO 预编码算法和接收机算法；降低具备超高空间分辨率的超大规模 MIMO 波束失败的波束管理方案等；能够降低计算复杂度、降低信令开销、降低波束扫描时间的智能化 MIMO 技术；以及能够提升边缘频谱效率、提高用户体验速率、可以实现以用户为中心的分布式 MIMO 技术等。9参考文献参考文献1A.Yaghjian,“An overview of near-field antenna measurements,”IEEE Trans.AntennasPropag.,vol.34,no.1,pp.3045,Jan.1986.2F.H.Danufane,M.D.Renzo,J.de Rosny,and S.Tretyakov,“On the path-loss ofreconfigurable intelligent surfaces:An approach based on Greens theorem applied to vectorfields,”IEEE Trans.Commun.,vol.69,no.8,pp.55735592,Aug.2021.3Y.Liu,Z.Wang,J.Xu,C.Ouyang,X.Mu and R.Schober,Near-Field Communications:ATutorial Review,in IEEE Open Journal of the Communications Society,vol.4,pp.1999-2049,2023.4P.Mei et al.,On the Study of Reconfigurable Intelligent Surfaces in the Near-Field Region,in IEEE Transactions on Antennas and Propagation,vol.70,no.10,pp.8718-8728,Oct.2022.5R.Li,S.Sun,and M.Tao,“Applicable regions of spherical and plane wave models forextremely large-scale array communications,”accepted by China Communications,2023.Online.Available:https:/arxiv.org/pdf/2301.06036.pdf.6Y.Lu and L.Dai,“Near-Field Channel Estimation in Mixed LoS/NLoS Environments forExtremely Large-Scale MIMO Systems,”IEEE Transactions on Communications,vol.71,issue.6,Jun.2023,pp.3694-3707.7Z.Yuan,J.Zhang,Y.Ji,G.F.Pedersen and W.Fan,Spatial Non-Stationary Near-FieldChannel Modeling and Validation for Massive MIMO Systems,in IEEE Transactions on38IMT-2030(6G)推进组IMT-2030(6G)Promotion GroupAntennas and Propagation,vol.71,no.1,pp.921-933,Jan.2023.8Fraunhofer Heinrich Hertz Institute,“Quasi Deterministic Radio Channel Generator UserManual and Documentation”.Document Revision v2.6.1.July 12.2021.9J.Li,B.Ai,R.He,M.Yang,Z.Zhong,Y.Hao,and G.Shi,On 3D cluster-based channelmodelingforlarge-scalearraycommunications.IEEETransactionsonWirelessCommunications,vol.18,issue.Oct.2019,pp.4902-4914.10 Y.Zheng,C.-X.Wang,R.Yang,L.Yu,F.Lai,J.Huang,R.Feng,C.Wang,C.Li and Z.Zhong,Ultra-Massive MIMO Channel Measurements at 5.3 GHz and a General 6G ChannelModel,IEEE Transactions on Vehicular Technology,vol.72,no.1,pp.20-34,Jan.2023.11 C.Han,J.M.Jornet,et.al.,Ultra-Massive MIMO Channel Modeling for Graphene-EnabledTerahertz-Band Communications,in Proc.IEEE VTC Spring,2018,pp.1-5.12 Y.Yuan,R.He,B.Ai,Z.Ma,Y.Miao,Y.Niu,J.Zhang,R.Chen,Z.Zhong,A 3DGeometry-Based THz Channel Model for 6G Ultra Massive MIMO Systems,IEEETransactions on Vehicular Technology,vol.71,no.3,pp.2251-2266,March 2022.13 J.Wang,C.-X.Wang,et.al.,A General 3D Space-Time-Frequency Non-Stationary THzChannel Model for 6G Ultra-Massive MIMO Wireless Communication Systems,IEEEJournal on Selected Areas in Communications,vol.39,no.6,pp.1576-1589,June 2021.14 X.Wei and L.Dai,Channel Estimation for Extremely Large-Scale Massive MIMO:Far-Field,Near-Field,or Hybrid-Field?,IEEE Communications Letters,vol.26,no.1,pp.177-181,Jan.2022.15 F.J.Ares-Pena,J.A.Rodriguez-Gonzalez,E.Villanueva-Lopez and S.R.Rengarajan,Genetic algorithms in the design and optimization of antenna array patterns,in IEEETransactions on Antennas and Propagation,vol.47,no.3,pp.506-510,March 1999.16 N.N.Pathak,G.Mahanti,S.K.Singh,J.K.Mishra,and A.Chakraborty,Synthesis ofThinned Planar Circular Array Antennas Using Modified Particle Swarm Optimization,Progress In Electromagnetics Research Letters,Vol.12,87-97,2009.17 S.Caorsi,A.Massa,M.Pastorino and A.Randazzo,Optimization of the difference patternsfor monopulse antennas by a hybrid real/integer-coded differential evolution method,inIEEE Transactions on Antennas and Propagation,vol.53,no.1,pp.372-376,Jan.2005.18 W.P.M.N.Keizer,Large Planar Array Thinning Using Iterative FFT Techniques,in IEEETransactions on Antennas and Propagation,vol.57,no.10,pp.3359-3362,Oct.2009.19 Y.Liu,Z.Nie and Q.H.Liu,Reducing the Number of Elements in a Linear Antenna Arrayby the Matrix Pencil Method,in IEEE Transactions on Antennas and Propagation,vol.56,no.9,pp.2955-2962,Sept.2008.20 Y.Liu,Q.H.Liu and Z.Nie,Reducing the Number of Elements in the Synthesis ofShaped-BeamPatternsbytheForward-BackwardMatrixPencilMethod,inIEEETransactions on Antennas and Propagation,vol.58,no.2,pp.604-608,Feb.2010.21 X.Zhao,Q.Yang,“Compressed sensing approach for pattern synthesis of maximally sparsenon-uniform linear array”.IET Microwaves,Antennas&Propagation,8(5):301-307,2014.22 M.Lou,J.Jin,H.Wang,et al.“Applying Sparse Array in Massive MIMO via Convexoptimization”.2020 IEEE Asia-Pacific Microwave Conference,Hong Kong,Hong Kong,2020:721-723.23 M.Lou et al.,Performance analysis of sparse array based massive MIMO via joint convexoptimization,in China Communications,vol.19,no.3,pp.88-100,March 2022.24 W.Xu,Y.Cui,H.Zhang,G.Y.Li,and X.You,“Robust beamforming with partial channelstate information for energy efficient networks,”IEEE J.Sel.Areas Commun.,vol.33,no.12,pp.29202935,Dec.2015.25 L.You,A.Liu,W.Wang and X.Gao,Outage Constrained Robust Multigroup MulticastBeamformingforMulti-BeamSatelliteCommunicationSystems,inIEEEWirelessCommunications Letters,vol.8,no.2,pp.352-355,April 2019.26 Ericsson,Breaking the 100Gbps barrier,”in Ericsson Microwave Outlook 2019,Tech.Report,pp.13-16,2019.Online.Available:https:/27 X.Li,X.Wang,X.Hou,L.Chen,S.Suyama and T.Asai,RIS-Aided Mega MIMO:Achieving Orthonormal Spatial Multiplexing with Adaptive Aperture,in Proc.2022 IEEEGlobecom Workshops(GC Wkshps),Rio de Janeiro,Brazil,2022,pp.692-698.28 M.Cui,Z.Wu,Y.Lu,X.Wei and L.Dai,Near-Field MIMO Communications for 6G:Fundamentals,Challenges,Potentials,and Future Directions,in IEEE CommunicationsMagazine,vol.61,no.1,pp.40-46,January 2023.29 K.Zhi,C.Pan,H.Ren,K.K.Chai,C.-X.Wang,R.Schober,and X.You,“PerformanceAnalysisandLow-ComplexityDesignforXL-MIMOwithNear-FieldSpatial39IMT-2030(6G)推进组IMT-2030(6G)Promotion GroupNon-Stationarities,”arXiv:2304.00172,Mar.2023.30 E.Bertilsson et.al.,“A Modular Base Station Architecture for Massive MIMO with Antennaand User Scalability per Processing Node,”52nd Asilomar Conf.,Oct.2018.31 T.Wirth et al.,“Modular Concepts for Practical Massive MIMO Implementations,”IEEERadio and Wireless Symp.,Jan.2020.32 X.You,et.al.,“6G extreme connectivity via exploring spatiotemporal exchangeability,”中国科学:信息科学(英文版),66(3):3,2023.33 Z.Feng et al.,A Precoding Scheme for Polar Coded Uplink MU-MIMO Systems,ICC 2022-IEEE International Conference on Communications,Seoul,Korea,Republic of,2022,pp.2489-2494.34 T.P.Minka,“Expectation propagation for approximate Bayesian inference,”arXiv preprintarXiv:1301.2294,2013.35 J.Cspedes,P.M.Olmos,M.Snchez-FernndezandF.Perez-Cruz,ExpectationPropagationDetectionforHigh-OrderHigh-DimensionalMIMOSystems,inIEEETransactions on Communications,vol.62,no.8,pp.2840-2849,Aug.2014.36 H.Wang,A.Kosasih,C.-K.Wen,S.Jin and W.Hardjawana,Expectation PropagationDetector for Extra-Large Scale Massive MIMO,in IEEE Transactions on WirelessCommunications,vol.19,no.3,pp.2036-2051,March 2020.37 Z.Zhang,H.Li,Y.Dong,X.Wang and X.Dai,Decentralized Signal Detection viaExpectationPropagationAlgorithmforUplinkMassiveMIMOSystems,inIEEETransactions on Vehicular Technology,vol.69,no.10,pp.11233-11240,Oct.2020.38 N.Shariati,E.Bjrnson,M.Bengtsson and M.Debbah,Low-Complexity PolynomialChannel Estimation in Large-Scale MIMO With Arbitrary Statistics,in IEEE Journal ofSelected Topics in Signal Processing,vol.8,no.5,pp.815-830,Oct.2014.39 M.Wu,B.Yin,G.Wang,C.Dick,J.R.Cavallaro and C.Studer,Large-Scale MIMODetection for 3GPP LTE:Algorithms and FPGA Implementations,in IEEE Journal ofSelected Topics in Signal Processing,vol.8,no.5,pp.916-929,Oct.2014.40 K.Li,R.R.Sharan,Y.Chen,T.Goldstein,J.R.Cavallaro and C.Studer,DecentralizedBaseband Processing for Massive MU-MIMO Systems,in IEEE Journal on Emerging andSelected Topics in Circuits and Systems,vol.7,no.4,pp.491-507,Dec.2017.40IMT-2030(6G)推进组IMT-2030(6G)Promotion Group10 主要贡献单位主要贡献单位主要贡献单位（排名不分先后）序号序号主要贡献单位主要贡献单位贡献内容贡献内容1中信科移动通信技术股份有限公司第1章、第2.1.2节、第3.2节、第4.4节、第5.2节、第7.1节、第7.2节、第8章2维沃移动通信有限公司第2.1.1节、第2.3节、第4.2节3北京交通大学第2.2节4中国移动第3.1节、第5.1节5都科摩（北京）通信技术研究中心有限公司第3.3节6中兴通讯股份有限公司第4.1节7紫光展锐第4.3节8重庆邮电大学第6章41IMT-2030(6G)推进组IMT-2030(6G)Promotion Group11缩略语缩略语英文缩写英文全称中文全称4G4thGeneration第四代移动通信系统5G5thGeneration第五代移动通信系统6G6thGeneration第六代移动通信系统AODAngle of Departure离开角BSBase Station基站COconvex optimization凸优化CSIChannel State Information信道状态信息CSITChannel State Information at Transmitter发端信道状态信息DEDifferential Evolution差分算法DFTDiscrete Fourier Transform离散傅里叶变换ELAAExtremely Large Aperture Array超大孔径天线阵列FBMPMForward-Backward Matrix Pencil Method前后向矩阵束FBSFirst-Bounce Scatterer首跳散射体FFTFast Fourier Transform快速傅里叶变换GAGenetic Algorithm遗传算法GBSMGeometry-Based Stochastic Channel Model基于几何的随机统计信道建模方法HBFHybrid BeamForming混合波束赋形IOSIntelligent Omni-Surfaces智能全向超表面JCOJoint Convex Optimization联合凸优化LBSLast-Bounce Scatterer末跳散射体LOSLine-Of-Sight直射径MFMatched Filter匹配滤波MIMOMultiple Input Multiple Output多输入多输出MPCMulti-Path Component多径成份MPMMatrix Pencil Method矩阵束42IMT-2030(6G)推进组IMT-2030(6G)Promotion GroupNCRNetwork Controlled Repeater网络控制的转发器NLOSNon Line Of Sight非直射径OSMA2OrthogonomalSpatialMultiplexingwithAdaptive Aperture基于自适应孔径的规范正交空间复用PEPolynomial Expansion多项式展开PMIPrecoding Matrix Indicator预编码矩阵指示PSOParticle Swarm Optimization粒子群算法RHSReconfigurable Holographic Surfaces可重构全息超表面RISReconfigurable Intelligent Surface可重构智能超表面STAR-RISSimultaneously-Transmitting-and-ReflectingRIS同时反射和透射的 RISTDDTime Division Duplexing时分双工ULAUniform Linear Antenna均匀线性阵UMaUrban Macro cell宏蜂窝UPAUniform Planar Antenna均匀平面阵VRVisibility Region可视区域联系方式邮箱：COPYRIGHT2023 IMT-2030(6G)PROMOTION GROUP.ALL RIGHTS RESERVED.

0人已浏览 2023-12-13 43页 5星级

目录 1.万物互联带来新机遇，边缘 Serverless 开辟新增长空间.1 1.1.产业数字化持续演进，催生众多边缘应用需求.1 1.2.边缘计算增长态势良好，发展进入高景气周期.2 1.3.契合边缘侧发展诉求，边缘 Serverless 大有可为.7 2.技术和市场相互促进，边缘 Serverless 生态日趋完善.8 2.1.阐明本质内涵，边缘 Serverless 概念清晰定义.8 2.2.用户需求旺盛，边缘 Serverless 产品日渐丰富.10 2.3.应用前景广阔，边缘 Serverless 生态持续繁荣.11 3.通用函数融合专用组件，边缘 Serverless 技术走向成熟.12 3.1.边缘函数提供轻量化解决方案.13 3.1.1.边缘函数研发.16 3.1.2.边缘函数发布.18 3.1.3.边缘函数接入.20 3.1.4.边缘函数执行.27 3.2.边缘组件满足个性化业务需求.29 3.2.1.边缘存储.30 3.2.2.边缘 AI 推理.31 3.2.3.边缘图片处理.31 3.2.4.边缘中间件.32 4.边缘 Serverless 典型应用场景.32 4.1.边缘渲染.32 4.2.灰度发布.34 4.3.APK 动态签名.34 4.4.M3U8 改写.36 5.总结与展望.37 前言 数字经济蓬勃发展，重点行业积极创新，数字技术已成为各行业企业提升竞争力的新战场。其中边缘 Serverless 充分融合边缘计算与服务器无感知的技术优势，缩短数据传输链路，简化运维复杂程度，盘活边缘算力资源，为万物互联互通背景下全行业的数字化转型开辟了新的道路。本白皮书梳理了边缘 Serverless 的发展背景，给出了边缘 Serverless 的清晰定义，分析了边缘 Serverless 的市场趋势，深度剖析了边缘 Serverless 的战略价值，详细解析了边缘Serverless 的技术要点。本白皮书从技术实践出发，对比了边缘 Serverless 解决方案较传统模式带来的显著变化与优势。充分展现了边缘 Serverless 的实际效用与现实价值。最后，本白皮书对边缘 Serverless 的未来发展进行了展望。期望通过本白皮书能够加深业界对边缘 Serverless 的认知，为边缘 Serverless 建设提供参考思路，加速边缘 Serverless 技术的持续演进，推动边缘 Serverless 理念的广泛落地。1 1.万物互联带来新机遇，边缘 Serverless 开辟新增长空间 1.1.产业数字化持续演进，催生众多边缘应用需求 数字经济蓬勃发展，产业数字化进程持续加深。2022 年，我国数字经济规模达 50.2 万亿元，同比名义增长 10.3%，占 GDP 比重达 41.5%，连续 11 年显著高于同期 GDP 名义增速。其中产业数字化规模占数字经济总规模的 81.7%，发展处于快车道1。2023 年中共中央、国务院印发的 数字中国建设整体布局规划 明确指出，要促进数字经济和实体经济深度融合，以数字化驱动生产生活和治理方式变革。当前，各重点行业正积极响应时代号召，拥抱数字化浪潮，深刻践行数字化转型方针，充分发挥数字技术效用，提升自身数字化能力，促进数字中国建设水平的跃升与中国式现代化伟大目标的达成。重点行业积极创新，全新数字模式构筑新常态。数字化已成为各行业企业提升竞争力的新战场，未来的生产生活都将与数字技术息息相关。一方面，传统行业正积极采纳数字技术为旧场景注入新活力。自动驾驶场景下，基于对周围环境及变化的感知与决策可实现辅助驾驶甚至无人驾驶；智慧工厂场景下，通过对工业设备运行状况的实时采集、监测与统一控制，大幅提升执行效率、降低运维成本；智慧农业场景下，通过对土壤水分数据的采集与分析实时调整灌溉系统的出水量。另一方面，新兴的数字需求也演生出诸多新业态。以元宇宙为例，通过对虚拟现实、增强现实、边缘计算、区块链等先进数字技术的综合运用，以游戏、社交等场景为切入点，逐步实现物理世界与虚拟世界的深层次连接。算力需求爆发式增长，边缘侧计算能力成为刚需。截至 2022 年底，我国移动物联网 1 数据来源：中国数字经济发展报告（2023 年），中国信息通信研究院 2 连接数已达 18.45 亿户，较上一年度净增 4.47 亿户，占全球总数的 70%2，万物互联基础不断夯实。随着终端侧处理需求的激增及数据量的暴涨，单纯采用中心云计算的建设方案暴露出网络带宽受限、决策实时性不足、隐私保护风险等问题，无法满足庞大的算力需求与流畅的交互体验，需要靠近端侧的边缘设备承担部分负载。边缘计算是一种将服务托管在靠近用户接入点的边缘设备上，通过减少端到端延迟和传输网络负载以实现高效服务交付的模式。边缘计算被视作实现 5G 通信与计算融合的一项关键使能技术，是中心云计算的有效补充，能够有效应对万物互联互通大背景下指数级增长的算力需求。图 1 中国移动物联网连接数量 1.2.边缘计算增长态势良好，发展进入高景气周期 国内外政策积极引导，边缘计算被视作价值高地。从国际形势来看，各国充分重视边缘计算的发展。2019 年韩国科学技术信息通信部发布的5G ICT 研发技术路线图（20192026）强调边缘计算是十大核心产业，并计划于 2026 年开发出融合公共、民间等不同领域使用的边缘计算技术。2020年欧盟发布的欧洲数据战略强调要抓住边缘计算、5G和 2 数据来源：中国互联网络发展状况统计报告,中国互联网络信息中心，2023 年 3 月 3 物联网带来的新机遇。同年美国白宫发布的引领未来先进计算生态系统：战略计划强调要从集中式先进计算资源向分布式边缘到云的联合计算和数据资源转变。2021 年澳大利亚航天局发布的空间对地观测路线图 20212030强调要探索边缘计算在内的跨越式概念。从国内环境来看，政策红利驱使边缘计算与产业的融合。2020 年 4 月，工信部在关于工业大数据发展的指导意见中提出要推动人工智能、区块链和边缘计算等前沿技术的部署和融合。2020 年 12 月工业互联网专项工作组发布的 工业互联网创新发展行动计划（2021-2023年）指出要结合边缘计算等新技术应用和产业发展趋势，完善工业互联网标准体系。2022年 1 月国务院发布的“十四五”数字经济发展计划指出要加快实施“东数西算”工程，加强面向特定场景的边缘计算能力。2023 年中共中央、国务院发布的数字中国建设整体布局规划 指出要促进东西部算力高效互补和协同联动，引导边缘数据中心的合理梯次布局。表 1 国外边缘计算的相关政策 发布时间 发布单位 政策名称 重点内容 2019.7 韩国科学技术信息通信部 5G ICT 研发技术路线图（20192026）2023 年开发出制造、医疗、交通等产业现场使用的边缘计算技术；2026 年开发出融合公共、民间等不同领域使用的边缘计算技术。2019.11 美国白宫 国家战略性计算计划（更新版）有效利用包括边缘计算在内的国家计算生态系统。4 2020.2 欧盟 欧洲数据战略 抓住边缘计算、5G 和物联网带来的新机遇。2020.11 美国白宫 引领未来先进计算生态系统：战略计划 从集中式先进计算资源（即“超级计算机”）向分布式边缘到云的联合计算和数据资源转变 2021.5 美国战略部 云战略 公布战术边缘云战略，推进边缘计算的军事化应用。2021.11 法国 国家云工业计划 支持法国创新产品开发，扩大法国企业在大数据或协作工作等关键技术方面的规模，加强边缘计算等颠覆性技术发展。2021.11 澳大利亚航天局 空间对地观测路线图20212030 探索边缘计算在内的跨越式概念 2022.3 日本总务省、学术机构 超越 5G 白皮书 重点关注边缘计算技术，通过非地面网络扩大网络覆盖范围。表 2 我国边缘计算相关政策 发布时间 发布单位 政策名称 重点内容 5 2020.4 工信部 关于工业大数据发展的指导意见 加快数据汇聚、建模分析、应用开发、资源调度和监测管理等共性技术的研发和应用，推动人工智能、区块链和边缘计算等前沿技术的部署和融合。2020.9 工信部 关于深入推进移动物联网全面发展的通知 面向不同垂直行业应用环境和业务需求，重点加强包括边缘计算在内的多项新兴关键技术研究 2020.12 工业互联网专项工作组 工业互联网创新发展行动计划（2021-2023年）结合 5G、边缘计算、人工智能等新技术应用和产业发展趋势，完善工业互联网标准体系，明确标准化重点领域和方向，指导标准化工作分领域推进实施。2021.7 工信部 新型数据中心发展三年行动计划（2021-2023年）加速改造升级“老旧小散”数据中心，提高“老旧小散”数据中心能源利用效率和算力供给能力，更好满足当地边缘计算应用需求。6 边缘计算优势显著，算力沉降突破触达边界。边缘计算与中心云计算相辅相成，深度贯通“云-边-端”，真正实现算力的全领域触达。边缘计算的主要优势如下：一是低延迟性能助力万物互联，在接近数据源的节点即可执行部分或全部的计算要求，缩短数据传输链路有效降低延时，满足高实时性场景要求。二是复杂网络环境下保障服务高可靠，边缘节点在网络正常时可不断从云端拉取最新元数据，在断网或弱网状态下能够从本地缓存获取元数据2021.11 工信部、国家标准化管理委员会 工业互联网综合标准化体系建设指南（2021版）边缘计算能够有效推动工业数据纵向集成及实时处理，已成为工业互联网云边网端协同的关键枢纽环节。围绕边缘计算的需求、总体架构、关键节点模型及要求等方面形成一系列标准。2022.1 国务院“十四五”数字经济发展计划 加快实施“东数西算”工程，推进云网协同发展，提升数据中心跨网络、跨地域数据交互能力，加强面向特定场景的边缘计算能力，强化算力统筹和智能调度。2023.2 中共中央、国务院 数字中国建设整体布局规划 要促进东西部算力高效互补和协同联动，引导边缘数据中心的合理梯次布局。7 实现一定程度的自治，保障业务稳定运行。三是数据隔离特性为安全保驾护航，可通过就近边缘节点对用户源数据进行预处理，实现敏感数据的隔离保护，同时支持数据在特定的安全边界内保持私有化，有效降低安全风险。边缘计算市场前景广阔，产业规模稳步攀升。随着边缘侧需求的增长，计算往边缘下沉的速度正在加快。边缘计算在 2020 年被 Gartner 评为十大战略技术趋势之一，根据MarketsandMarkets 统计数据，2022 年全球边缘计算市场规模超 447 亿美元，预计到 2027年底将达到 1013 亿美元以上。在人工智能浪潮的驱动下，2023 年全球边缘 AI 市场将从 2018年的 3.56 亿美元增长至 11.52 亿美元。国内市场来看，信通院调研数据显示 2021 年我国边缘计算市场规模已达到 436.4 亿元，预计 2024 年将达 1803.7 亿元，增长空间广阔。从落地角度看，IDC 预测，到 2023 年末将有 50%的企业 IT 基础架构软件选择在边缘部署，到 2024年末边缘应用将有 8 倍的增长。1.3.契合边缘侧发展诉求，边缘 Serverless 大有可为 落地面临挑战，边缘侧计算模式仍有待优化。区别于具备大规模海量数据处理能力的中心云计算，在边缘场景下，关注点更多聚焦于靠近用户侧的实时数据处理与分析。5G 技术的演进与落地进一步满足了严苛的实时性要求，然而边缘侧应用场景仍面临诸多挑战。一是边缘设备计算能力不足，为缓解中心云的负载压力，部分逻辑下沉到边缘侧执行，需要边缘节点提供灵活简单的计算模式。二是边缘节点资源大小受限，单个边缘节点的计算、存储、网络等资源固定，需要更轻量化更低开销的方案，充分利用有限资源。三是边缘资源协同调度难度大，边缘节点数量众多且分散在全球各地，需要将分布式的边缘节点协调联动，面向用户提供统一的计算、分析、处理等服务。聚焦上层应用，Serverless（服务器无感知）是高频竞争时代的破局利器。Serverless 8 是一种将基础设施资源抽象成按需使用的服务，用户只需关注应用逻辑，而无需管理复杂的基础设施运维工作的设计模式。Serverless 定义了一种全新的开发范式，聚焦业务价值，屏蔽底层基础设施复杂性，具备按需伸缩、免运维、快速交付、按量付费等特性，充分体现了以应用为中心的理念。FaaS（Function as a Service，函数即服务）作为 Serverless 最典型的计算形态，当有请求到来时，触发函数执行相关代码逻辑，当请求结束后，即可释放资源，突破了传统应用自行规划容量、提前申请并占用常驻资源的构建模式，在轻量、敏捷、弹性、成本等方面具有无可比拟的优势。切中边缘侧痛点，FaaS 与边缘融合释放倍乘效用。在边缘侧运用 Serverless 技术能够发挥两点典型优势：一方面体现为轻量化的代码托管能力。边缘计算的核心目的是把原先必须在云端执行的逻辑下沉到边缘设备，从而能够在更靠近用户的地方更快响应用户请求，因此边缘设备需要具备灵活执行用户代码的能力。FaaS模式能够降低业务逻辑构建的复杂性，支持以更轻量化的方式编写、更新与托管代码逻辑。另一方面体现为算力资源的统筹利用。由于受到边缘物理基础设施的限制，边缘计算的资源扩展难度大。FaaS 模式下无需提前规划，能够充分调度边缘节点的资源实现按需弹性，同时运行完成后即可释放资源，充分提高资源利用率，盘活算力资源。2.技术和市场相互促进，边缘 Serverless 生态日趋完善 2.1.阐明本质内涵，边缘 Serverless 概念清晰定义 根据部署位置差异，函数即服务的形态可划分为两类：一是中心云函数即服务，二是边缘函数即服务。边缘函数是指运行在边缘节点上的代码逻辑。边缘函数即服务是指基于事件驱动的边缘函数托管服务，可将不同地域的请求调度至就近边缘节点执行计算任务，且能 9 够根据请求量按需获取和释放计算资源，是服务器无感知架构的一种实现方式。边缘函数即服务与中心云函数即服务都是基于 Serverless 理念构建的，均具备Serverless 的敏捷、免运维、即需即用等特性，由于适用场景及其对应使用诉求不同，两类函数即服务在诸多特性上存在较大差异。表 3 函数即服务差异对比 边缘函数即服务 中心云函数即服务 部署位置 边缘节点，全球分布 中心集群，集中在主要大城市 冷启动延时 短 长 运行时 Chromium V8、WebAssembly 容器 最大运行时长 秒级 分钟级 最大占用内存 MB 级 GB 级 代码包大小 KB 级 MB 级 支持语言 以 JavaScript 为主 多语言，如 Node.js、Python、PHP 等 可承受 QPS 高 低 适用场景 轻计算，延迟敏感 重计算，延迟不敏感 10 边缘组件是边缘 Serverless 生态的重要组成部分，边缘组件可以有效组织硬件资源，为边缘函数提供了丰富的功能补充。边缘组件也像边缘函数一样，具备低延迟、弹性、隔离、安全等特性，同时边缘组件 API 和边缘函数 Runtime 可以完美结合，开箱即用，使得非专业人员也可以使用专业度较高的组件能力。边缘函数和边缘组件共同组成了边缘 Serverless，提供了强大的功能开发和运行能力。2.2.用户需求旺盛，边缘 Serverless 产品日渐丰富 图 2 边缘函数即服务发展历程 从国外情况来看，各厂商对边缘函数即服务的探索开始较早，并积极开展落地。亚马逊作为全球云计算领域的先行者，继 2014 年发布全球首款中心云函数即服务 Lambda 后，于 2017 年 7 月发布了以容器化形式将函数部署到边缘的解决方案 LambdaEdge，在 2021年又基于新的虚拟及隔离技术发布 Cloudfront Functions，进一步优化了冷启动时延与成本。2017 年 9 月 Cloudflare 发布基于 Chromium V8 引擎的边缘函数即服务解决方案 Workers，冷启动时延可达到毫秒级别，并于 2019 年推出全球分布式键值数据库 KV store，能够与Workers配合使用。同年，Akamai 推出 Edge Worker，功能及性能与 Cloudflare Workers 类似。不同于Cloudflare 的技术路线，Fastly 全心投入 WebAssembly 的研究并自研 Lucet 编译器和运行时，2021 年正式发布 ComputeEdge，将冷启动时延缩小到微秒级别。11 从国内情况来看，各厂商的中心云函数产品已趋于完善，但边缘函数即服务仍处于建设阶段。2017 年，腾讯云、阿里云、华为云、百度智能云先后发布中心云函数即服务产品。随着 Serverless 理念的发展以及边缘侧需求的增长，国内厂商逐步开展边缘函数即服务的实践。2021 年 7 月阿里云推出边缘应用 EdgeRoutine，同年 12 月白山云推出 FunctionEdge，2022 年 9 月腾讯云正式发布边缘函数 Edge Functions。同时，华为云、火山引擎、天翼云等厂商也正在持续打磨与孵化边缘函数即服务产品，国内边缘函数即服务的产业生态将持续繁荣。2.3.应用前景广阔，边缘 Serverless 生态持续繁荣 从入局企业来看，边缘 Serverless 服务提供商主要分为两大阵营。一类是云厂商，云厂商通常配套丰富的云产品能力，且具备深厚的技术积累，能够将先进的云原生技术赋能到边缘侧，同时与中心云的相关产品结合，满足各类处理诉求。另一类是 CDN（Content Distribution Network，内容分发网络）厂商，传统 CDN 市场日渐式微，CDN 厂商正积极转型探索边缘场景，CDN 厂商通常具有数量众多的可覆盖全球的边缘节点，从而能够更靠近终端用户，一定程度上可减少触达时延。从市场规模来看，边缘 Serverless 实力强劲，增长潜力大。根据中国信通院测算，2021 年我国边缘计算市场规模为 436.4 亿元，其中边缘软件与服务市场规模为 146.2 亿元，预计 2024 年边缘计算市场整体规模将达 1803.7 亿元。KBV 研究公司发布的 全球 Serverless架构市场报告显示，全球 Serverless 架构市场的规模预计到 2024 年将达 140 亿美元，且预测期内将以 23.4%的年复合增长率增长。Gartner 在 2022 云平台服务成熟度曲线中预测边缘函数即服务将在 2-5 年内进入稳定期。Akamai 的边缘应用业务（包括边缘函数即服务形态）在 2020 年收入为 1.51 亿美元，预计到 2025 年将增长至 90 亿美元，达到与传统 CDN 市 12 场相当的市值。Cloudflare 预测基于其 Serverless 架构之上（包括 Workers、Workers KV 等产品）所提供服务的目标市场总值将在 2024 达到 7000 亿人民币。在边缘服务需求与 Serverless架构演进的双重驱动下，可以预见，边缘 Serverless 服务将进入高景气周期。图 3 Gartner 2022 云平台服务成熟度曲线 从应用情况来看，边缘函数即服务价值逐步被认可，采纳率可观。Datadog 于 2021 年发布的数据显示，四分之一的 Amazon CloudFront 企业客户已经在使用 LambdaEdge，如根据用户特征实现图像的动态转换，或者在 A/B 测试中提供 Web 应用程序的不同版本等，67%的 LambdaEdge 函数运行时长在 20 毫秒以内。根据中国信息通信研究院2022 中国Serverless 用户调查数据，近四成受访用户已将 FaaS 投入生产，其中用于核心业务生产环境的比例高达 17.83%，已采纳 FaaS 的用户中有 31.13%已将 FaaS 应用于边缘场景。3.通用函数融合专用组件，边缘 Serverless 技术走向成熟 边缘 Serverless 其实是将边缘 Serverless 节点当作一台超级计算机，边缘函数可以看作 13 这台设备的“计算模块”。单一的边缘函数计算服务能够满足大部分无状态的执行逻辑，但是对于有状态的逻辑开发，还需要为这台计算机添加边缘组件这样的“存储模块”用于临时或者永久存储一些状态。因此，边缘组件同样是边缘 Serverless 生态中的重要一环，它和边缘函数一起构成了完整的边缘 Serverless 生态。随着技术发展逐步深入，在不同行业领域诞生了大量的专用硬件和软件，这些专用硬件和软件在对应领域的性能等方面往往大幅度领先通用组件，为满足在某些细分领域上有更高要求的开发人员，需要为边缘 Serverless 这台超级计算机添加对应的专有能力，例如“AI模块”、“图片处理模块”等。最后还需要类似“定时任务”、“消息队列”等辅助组件共同协作以完成复杂系统的开发。在实践过程中，边缘函数层负责将业务逻辑进行函数化包装，并在全球边缘 Serverless 节点进行发布，根据用户请求执行对应的函数逻辑，最终返回结果；边缘组件层负责在函数从执行到返回的全生命周期中，依据不同的业务类型，提供各种能力支撑。图 4 边缘 Serverless 生态 3.1.边缘函数提供轻量化解决方案 尽管边缘函数具有诸多优势和价值，例如较低的延迟，更好的数据安全和隐私保护能 14 力，更高的灵活性和可扩展性等。但由于边缘计算与中心计算在部署架构和分布上存在明显区别，因此在边缘函数的研发、部署接入、全球数据状态一致性及完整性、以及边缘运行时的性能保障等方面存在诸多挑战。图 5 边缘函数架构 研发：由于函数执行本身对隔离性有一定的要求，因此函数往往被部署在某个沙箱环境中，对外部组件、磁盘、网络等访问的过程由特殊的运行时 API 提供。因此用户无法完全在本地环境运行、调试函数，对研发过程造成了极大的不变，需要提供配套的工具链以改善研发体验。部署和接入：由于边缘网络具有全球分布性，经常跨越各个国家的一级运营商，同时不同地区的边缘设备可能位于不同的网络环境中，其网络状况和访问速度也会存在差异，导致函数的就近接入和全球部署变得困难重重。因此，要确保边缘函数在全球范围内的稳定性和性能，需要采取更加复杂和灵活的技术和策略。全球数据状态一致性及完整性：中心计算场景下，数据状态的强一致性通常比较容易保 15 证，因为中心计算通常运行在一个集中式的环境中，且中心节点对于整个系统具有完全的控制权。因此，中心计算可以采用更为简单和直接的方法，例如在所有节点之间进行数据同步和复制，以保证数据状态的一致性。与此相反，在分布式环境中，数据同步的延迟和一致性非常难以保证。边缘设备的异构性和全球分布性，使得数据在不同的节点之间传输和同步存在各种不可预知的延迟和错误，例如网络延迟、节点故障、数据冲突等，这些问题都可能导致数据同步出现错误和不一致性。同时，边缘设备的异构性和全球各地机房管控标准的差异性也会导致全球数据状态的不完整。在全球同步数据的过程中，由于网络问题、劫持问题以及设备故障等原因，数据的状态很容易被篡改，进一步影响数据的完整性。因此，需要采取更加灵活和可扩展的技术和策略，来解决边缘函数中全球同步数据的挑战，并保护数据的完整性。边缘运行时的性能保障：相比中心云，边缘设备异构且通常具有资源受限的特点，例如内存、存储和处理能力等方面的限制；同时，边缘函数所处理的任务并发量高（每秒千万量级次请求），负载相对较小（处理时长一般在 5 毫秒量级），用完即走，这对边缘函数来说是一个全新的挑战。从边缘函数本身的使用周期来讲，可以将这些技术挑战划分到四个阶段：研发阶段：由函数开发方完成函数的编写、调试和测试。发布阶段：函数研发完成后，由边缘 Serverless 平台部署到全球边缘 Serverless 节点中，等待请求接入。接入阶段：由边缘 Serverless 平台提供域名等调度手段，将调用请求根据边缘 Serverless节点的负载、访问延迟等特征，调度至最优节点。运行阶段：请求被调度至当前边缘 Serverless 节点后，执行对应函数，计算产生结果。16 下面将围绕这四个阶段，从边缘函数的研发、发布、接入、及运行展开阐述具体的挑战和解决方案。3.1.1.边缘函数研发 问题和挑战：边缘函数一般运行在边缘计算节点特定的沙箱环境中，用户无法像在中心算力一样访问设备的任意资源，这导致边缘函数往往只能用于逻辑简单的无状态纯计算服务，应用场景明显受限。并且用户只能使用沙箱环境支持的语言和特定环境进行开发，无法本地测试，进一步增大了用户的研发难度。因此边缘函数在研发阶段最大的挑战就是如何向用户提供一套和本地开发能力接近的研发平台，使得用户只需要像开发本地单机服务一样进行研发，就可以在全球部署。解决方案：边缘函数研发平台的目标是打造功能完备且易用的一站式解决方案。在开发阶段，希望为开发者屏蔽所有不相关的底层逻辑，例如申请对象存储、接入加速 CDN、部署队列服务等，他们只需要关注业务逻辑，基于熟悉的开发语言进行开发，实现各种业务应用。并且提供远程调试脚手架、实时流式日志等能力，提升调试体验。研发平台的基本思想就是把全球机房节点当作一个超级计算机，在之上去抽象网络、计算、存储接口。正如前面所提及，在边缘函数中，网络与计算类接口与中心函数计算差别不大，而存储（计算状态）接口是边缘与中心的核心区别所在。因此，研发平台可按照边缘函数计算的无状态、弱状态、强状态去划分存储接口及演进体系。无状态：指的是在边缘提供一些常用的，与跨地域状态无关的计算能力，例如网络处理、17 流式计算等接口。这类接口可支持实现图片处理、页面渲染等无状态应用。弱状态：指的是在全球边缘提供最终一致性的状态同步能力，例如边缘缓存及 KV。有了这类接口就可以开发实现边缘 WAF、Public DNS 等需要弱状态同步的应用。强状态：指的是在边缘上实现全球强一致的同步，包括了支持事务性的数据库及强一致的对象存储能力等接口。这类接口将支持有强一致要求的应用，例如文档协同，多人游戏等应用。模块扩展：同时，边缘函数研发平台还应支持更加通用的扩展性，包括了通过 WASM 通用字节码对多语言的支持，以及支持核心组件的服务化，包括视频编码、人工智能等能力的服务化。这样，不同专业领域的开发者都可以加入到同一个平台上，一起构建边缘函数研发生态。图 6 Serverless 接口分类及演进 同时提供脚手架命令行工具支持上述组件的绑定、发布、代码检查、实时调试、实时流式日志订阅等能力，使得用户可以像本地研发一样可以实时部署调试，所见既所得，全面提升边缘函数的开发体验。18 3.1.2.边缘函数发布 问题和挑战：服务在中心算力部署时一般部署在特定的某几个机房的某些设备上，而边缘函数出于在全球各地提供低延迟服务的目的，需要在全球分布的大量边缘 Serverless 机房部署；并且由于边缘设备单机算力有限，又进一步导致了需要部署的边缘 Serverless 节点数量增多。由于部署的设备数量大幅度上升，以传统的推送部署模式在超大规模集群上发布边缘函数可能会遇到如下问题：因为无法知晓用户的请求会发送到哪些设备，因此新增函数在所有节点部署完成前无法提供给用户使用，函数必须再所有节点都完成发布后才能对外使用，整体发布耗时大幅度增长。部署消耗的带宽极大。假设需要在全球一万个边缘 Serverless 节点上部署 5MB 的函数，会产生 50GB 的流量。如果需要在 10 秒内部署完成，单个函数部署的峰值带宽就会达到 40Gbps。即使使用压缩传输，带来的带宽开销也是难以承受的。部署产生的流量绝大多数都是无效流量，一是由于开发者可能仅出于体验测试的目的尝试部署，仅有个别节点会产生实际的访问。二是由于大部分的产品用户分布也较为集中，一般会集中访问某个地域的节点而不是全球所有的节点。因此如何在全球部署的场景下仍然保持极低的部署延迟和部署开销是边缘函数发布的主要挑战。解决方案：边缘函数的载体是代码文件，边缘函数的全球发布本质上是一次文件分发，而如何将 19 文件快速、低成本的分发至全球边缘节点恰好是 内容分发网络（CDN）本身需要解决的问题。CDN 从一开始就面临着如何将海量的用户文件低成本快速分发至边缘节点以加速用户访问的问题。并且客户甚至不会通知 CDN 供应商哪些文件需要被分发。为了解决这一问题，CDN 厂商往往使用“回源”模式处理文件内容而非分发模式，即 CDN 厂商并不是主动将所有文件分发至边缘节点，而是当用户实际访问这些文件时再根据用户的访问路径和客户配置好的“源站”按需获取文件内容并流式传输给客户端同时缓存下来。如果当前节点某些文件并没有被访问过，那么 CDN 厂商并不会产生无效的文件拉取流量。虽然这会导致当前文件在节点上首次被访问的延迟上涨，但是这使得 CDN 厂商可以在不知晓源站文件列表也不需要主动分发文件的前提下，立刻为全球的用户提供边缘文件分发服务。并且文件被访问过后会在边缘节点上生成缓存，后续的访问并不会有额外的延迟，同时源站也不需要提供额外的分发带宽。由于边缘函数发布本质上也是文件的全球分发过程，因此可以借鉴 CDN 的处理逻辑，采用类似“回源”的惰性拉取模式进行函数的分发：开发者提交函数后，不主动推送到所有边缘 Serverless 节点上，仅存储在中心管控。当客户端请求节点时，检查本地是否存在对应的边缘函数。如不存在，则实时向Serverless 中心管控系统拉取并缓存。当开发者重新发布边缘函数后，向节点下发清理旧函数缓存的信令，允许重新回源拉取。20 图 7 函数分发过程 使用惰性拉取方案具有如下优点：新接入的边缘 Serverless 节点在全球范围实时生效，用户无需等待即可访问。只有真正需要使用该边缘函数的节点会产生拉取动作，避免产生无意义的分发流量。信令大小远小于边缘函数本身的大小，可以在极短的时间内完成分发，无需担心分发带宽。同时，P2P 也是文件分发中经常被采用的一种技术，P2P 分发可以将分发从“中心到边缘”优化为“边缘到边缘”，降低中心服务的压力。边缘函数的分发也可以采用类似的思路，即当本地缓存没有对应函数时，可以尝试访问机房内或者临近机房的其他边缘 Serverless节点获取函数，可以进一步降低函数发布所需的成本。3.1.3.边缘函数接入 边缘函数部署在全球的边缘节点，边缘机房往往跨越各个国家一级运营商，同时不同地区的边缘设备可能位于不同的网络环境中，其网络状况和访问速度也会存在差异，难以确 21 认当前用户的最优边缘函数接入点。因此，要确保边缘函数在全球范围内用户请求接入的稳定性和性能，需要采取更加复杂和灵活的调度技术和策略。网络质量实时探测 问题和挑战：对边缘网络来说，网络的复杂性要远高于中心网络。不同的地区、运营商甚至每个边缘 Serverless 节点的链路情况都不同。单纯基于运营商网络的特点和 IP 地址库等方式对网络质量进行评估是不够准确的，但是准确的网络质量评估是高质量调度策略中的关键信息之一。因此保证高质量接入的一大困难就是如何获取到用户具体的网络情况，比如：丢包率、带宽、延迟等信息，从而综合评估出用户侧网络质量。由于用户设备本身存在频繁的上下线和 IP 切换等行为，直接探测用户设备会影响数据的稳定性，因此首先需要解决的就是如何选取到稳定可靠并且可以代表用户网络质量的探测点，并且得出综合的网络质量数据。解决方案：22 图 8 端到端网络访问 如图 8 所示，回归到网络本身，使用网络拓扑，寻找代表用户网络质量的汇聚点point。这类汇聚点一般是用户的网络出口，比较稳定且离用户较近，可以用来代表用户的网络质量。23 图 9 用户拓扑的聚集性 选取到可信的探测点后，就可以开始对这些探测点进行综合质量评估：端到端质量：如下图所示，通过机房对汇聚点发送 echo 请求报文，得到延时、丢包、抖动数据，从而进行用户和机房端到端的网络质量评估。图 10 机房质量 质量函数：基于获取到的延时、丢包、抖动数据，通过质量函数计算，获得综合的质量 24 数据。质量地图：如下图所示，根据质量函数生成质量地图。根据质量地图调整机房排序，生成边缘网络的调度结果，并且可以实时调整用户访问调度。图 11 质量地图 DNS 就近接入 问题和挑战：在获取到准确的质量信息后，就可以综合容量等信息计算调度结果，尽可能使用 DNS将用户调度到就近的接入点，优化用户的访问延时。常用的方案为地理位置就近调度，即 DNS使用分地域解析机制，对不同区域的 LDNS 请求返回地理位置就近的服务节点 IP。但是，基于地理位置的就近调度方案存在一些问题：无法取得质量最优化：地理位置就近并非代表底层的网络距离也是就近的，就近的机房可能会出现质量不如距离用户更远的机房的情况。无法处理质量变化：机房的质量是动态变化的，基于地理位置的静态调度无法总是取得质量最优化的机房位置。调度粒度相对较粗：同地域可能存在多服务节点部署，对本地域不同的用户群体具有不同的服务质量。在这种情况下，按地域进行调度无法精细化优化质量。LDNS 牵引不符合预期：在海外很多国家的运营商，并非各个地域都有 LDNS 部署，无法 25 实现单独调度对应地域的流量。图 12 DNS 就近接入 解决方案：根据静态数据计算往往无法得到最优调度策略，必须结合实时数据才能计算出对真实用户更加友好的调度结果，因此需要基于 LDNS 实时质量地图进行精细化调度：分析出全网的 LDNS IP，并根据 LDNS IP 所处的网络不同划分到不同分组 从各个服务节点实时探测各个 LDNS IP 分组，获得 LDNS 分组到各个服务节点的质量排序 每当收到 LDNS 的查询请求时，根据第 2 步的质量排序返回质量最优的边缘 Serverless节点 相比于基于地理位置就近调度方案，基于实时质量地图调度，全球平均可取得 10%以上的延时收益。HTTPDNS：权威 DNS 根据 LDNS IP 来判断请求来源。某些情况下，用户和所使用的 LDNS出口距离较远（例如用户使用不支持 ECS 的 Public DNS），会导致用户访问到非最优的服务节点。对于有条件的情况，建议在客户端上使用 HTTPDNS，或者完整支持 ECS 的Public DNS 来解析服务域名。26 Anycast 就近接入 问题和挑战：Anycast 也是常用的将用户请求调度到就近节点的方案，和 Unicast 不同的是，Anycast 方案需要将路由前缀在多个服务机房进行发布。发布后，运营商路由器会获取到对应前缀的多条路径。一般情况下，路由器会根据最短路径的原则进行选路，进而将用户的请求路由到就近的服务节点。相比于 DNS 就近调度方案，使用 Anycast 方案的优势是，不需要额外系统就能实现就近接入，而且服务节点对外中断后路由会自动撤销，实现自动化容灾。但是，在每个服务节点的各个出口直接发布 Anycast 路由，存在如下问题：负载风险：路由系统的复杂性造成路由发布的结果难以提前预测，在网络出口发布路由，可能会出现引流超过预期，出现服务节点过载。质量风险：新增发布并不一定会使质量优化，在路由系统出现多条可选路径的情况下，反而可能选择质量更差的路径。解决方案：为了解决上述问题，可以使用基于 Anycast 流域测量的 Anycast 路由发布方案：使用一个测试网段，尝试各种可能的发布组合 评估不同发布组合的质量和负载，根据业务需求选择质量和负载综合最优的方案 将最终选择的发布组合，应用于实际服务网段 周期性执行上述过程，以针对流域的变化，不断调整发布组合 在一个全球 10 个服务节点的部署案例中，相比于全出口发布，基于流域测量的方案可 27 取得 30%以上的延时收益。3.1.4.边缘函数执行 性能优化 问题和挑战：边缘函数的执行性能和隔离性对于整个边缘函数系统的稳定性和可靠性至关重要。边缘函数的性能直接影响着边缘计算的延迟和响应速度，是保证边缘计算能够快速、准确地处理海量数据的关键。因此，边缘函数需要具有高效、可靠、低延迟的性能特点，同时具备强大的处理能力和数据处理能力，以满足不断变化的业务需求和应用场景。解决方案：对于性能优化，需要对边缘函数开发的全流程逐一进行优化。边缘函数的执行流程一般包括启动隔离环境、预处理、编译和执行等几个步骤：首先，在执行边缘函数前，需要在边缘 Serverless 节点上启动隔离环境，隔离环境是为了避免边缘函数与其他程序之间的干扰，保证边缘函数的执行环境安全可靠。其次，在预处理阶段，边缘函数会加载函数代码，进行词法分析、语法分析等操作，生成抽象语法树。这一步是边缘函数执行的前置步骤，为接下来的编译打下基础。接下来，在编译阶段，边缘函数会将抽象语法树转化为字节码或直接进行 JIT（即时编译），最终生成机器码。最后，在执行阶段，边缘函数会根据业务需求执行相应的业务逻辑。在这个阶段，边缘函数可能需要依赖一些网络框架或者其他系统资源，以实现具体的功能。同时，边缘函数在执行过程中也需要实时收集和处理数据，以保证计算结果的准确性和及时性。边缘函数的执行流程包含了启动隔离、预处理、编译和执行等多个步骤，每个步骤都影响着边缘函数的执行性能：28 隔离环境：在隔离环境上，可以根据实际的使用场景对隔离程度以及冷启动速度做权衡，实现不同级别的隔离方式，例如同一用户之间的边缘函数可以选择更轻量的隔离级别，以降低不必要的性能开销。同时，隔离环境和其他函数执行的资源分配本身是一个比较耗时的过程，如果在请求到来时再临时分配，对边缘函数的启动延迟会有明显的影响。因此推荐在服务启动时，Serverless 节点根据自身的硬件资源和请求的大致分布预先初始化若干隔离环境。当请求到来可以从隔离环境池中直接获取一个已分配的空闲隔离环境，而不是临时分配资源，避免分配隔离环境对启动时间造成的影响。编译优化：对于单一边缘函数来讲，变更一般不会特别频繁，可以对函数编译后的字节码和其他产出物进行缓存，减少重复编译的次数，可以加快程序的编译和加载速度，提升整体性能。自动代码检查：边缘函数研发平台可以通过代码检查功能，优化冗余代码逻辑，移除未使用的变量、函数和无效代码，减少整体代码量，提升性能。多租户隔离 问题与挑战：在边缘计算中，多租户环境是相当常见的，即多个用户和应用共享同一个边缘计算资源池。因此边缘函数需要尽可能地保证多租户间的隔离性，避免不同用户和应用之间的数据被非法获取或篡改。解决方案：为了避免多个用户间函数执行互相影响，边缘函数需要在应用程序内实现和操作系统类似的多任务调度能力。否则如果有用户的函数需要持续使用 CPU，会导致其他用户的函数无法执行。29 边缘函数在实际执行时可以切分为更小粒度的时间片分配 CPU 时间。当前边缘函数执行超过时间片限制后，可以挂起当前函数让出 CPU。根据某种任务调度策略挑选出一个等待的函数继续执行，尽量让所有函数都得到公平的 CPU 使用机会，避免单一用户的函数消耗过高影响其他租户。同时也可以根据边缘函数的类型（实时请求还是定时任务等特征），实现更加丰富的时间片调度策略。，同时，隔离性还可以保证不同用户和应用之间的计算资源、存储资源等之间相互隔离，避免因为资源争用而造成系统的不稳定性和性能下降。数据完整性 问题与挑战：由于资源隔离的特性边缘函数往往允许直接访问本机的存储资源，对存储的访问通常会涉及到跨设备传输，如何保证跨设备传输数据的一致性也是必须要解决的问题。解决方案：边缘函数往往需要利用边缘存储（缓存、KV、文件存储）等服务完成更复杂的功能，对于此类存储服务，需要在网络传输和数据读写上保证数据完整性，避免数据错乱对逻辑造成未知的影响。可以根据自身的功能设计和可以接受的性能损耗定制传输和存储协议或者选择成熟的开源协议（如 TLS），利用额外的校验值验证数据是否完整 3.2.边缘组件满足个性化业务需求 出于安全、隔离、弹性等考虑，边缘函数平台一般不会允许函数直接操作硬件资源，同时有部分硬件（例如 GPU）的直接使用难度较高，对开发人员有明显的专业性要求。对于这些资源的使用，边缘组件可以将硬件资源有效的组织起来，提供安全、隔离、弹性、开箱即用的抽象资源接口。30 边缘组件主要解决边缘 Serverless 开发中的三个问题：资源隔离，通过租户配额、屏蔽底层接口等方式，避免不同函数之间对硬件的使用互相影响。提升资源访问性能，通过同机房部署、就近部署、缓存、主动推送等方式，降低边缘节点对硬件资源访问的延迟。提供风格统一、简单易用的边缘函数 Runtime API，降低开发者的使用难度。降低开发者重复开发的工作量，尤其是在 AI 等专业难度较高的领域，可以由专业的研发人员负责开发边缘组件，普通开发者直接使用即可。3.2.1.边缘存储 边缘缓存 缓存是系统开发中常用的一种思想，通过将资源缓存在本地的内存、磁盘等方式，可以极大的提升系统的吞吐能力，降低对外部依赖的压力。在边缘 Serverless 节点中，可以将设备的内存、固态硬盘、机械硬盘等资源组织起来，形成访问速率、性能、成本各有优劣的缓存集群，通过边缘函数 Runtime API 对开发者暴露。开发者无需关心资源存储的形式，只需根据业务对延迟、缓存量级、成本等维度的要求，绑定合适的缓存介质到 Runtime 中即可使用。边缘 KV 存储 KV 存储也是系统开发中常用的一种持久化的存储组件，用于存储类似于用户信息、任务状态等“键-值”形式的数据。由于边缘 Serverless 节点本身可能出现频繁的上下线等情况，因此并不适合在单一边 31 缘机房中存储有持久化需求的数据。对于边缘 KV 存储，可以采用在多地存储，全球同步的机制。即由多个机房的多台设备构成一个存储集群，以最终一致的形式存储持久化的 KV 数据，同时，当写入事件发生时，利用消息队列订阅等方式，自动推送至全球边缘 Serverless节点的 KV 缓存，使得用户可以在全球各地都以较低的访问延迟读取 KV 数据。边缘文件存储 相似的，系统也可以用类似 KV 存储的形式提供边缘文件存储能力，使得用户可以方便的存储或者读取文件内容。3.2.2.边缘 AI 推理 近些年 AI 快速发展，在翻译、物体检测、内容生成等领域都诞生了非常成熟的应用模型，AI 开始逐渐与每一个应用相关。在边缘 Serverless 节点中，可以放置 GPU 等特殊计算硬件的设备组成 AI 专用的推理计算集群，通过边缘函数 Runtime API 暴露 AI 推理能力。在系统建设初期，通常可以将常用的经典模型内置在推理集群上，封装为开箱即用的工具化 Runtime API，满足绝大多数普通开发者对 AI 能力的使用。随着系统建设的愈加完善，用户可以上传自己的自定义模型，在 Runtime API 中丰富 AI 预处理和后处理的能力，以便专业的 AI 开发者在函数内根据自己的需求将素材处理成自定义模型的原始入参，在边缘Serverless 节点内完成通用推理。3.2.3.边缘图片处理 图片是目前边缘流量中非常常见的一种资源类型，同时很多用户都有根据终端的类型、分辨率、网络质量等因素返回压缩格式或者大小不同的图片。32 在传统的中心计算模型下，一般都是由图片存储的中心组件完成对图片的二次加工，同时在边缘根据请求信息缓存多份内容，这一过程通常会产生不必要的中心算力和流量浪费。而在边缘 Serverless 节点内处理上述过程，可以天然规避这些的问题。通过内置图片处理服务，支持开发者在边缘节点内完成对图片的二次加工。同时边缘节点距离用户更近，可以更加明确的感知到用户的网络质量等信息，做出更加丰富准确的图片处理决策。3.2.4.边缘中间件 定时任务 在一些应用场景中，边缘函数的执行并不是由实际的请求触发，而是自身周期性的执行，例如网络质量探测、信息收集、数据清洗等。对于这一类应用场景，边缘 Serverless 节点能够提供定时任务能力，可以按照用户需求，在全球定时驱动若干个节点执行。消息队列 消息队列是一种常见的组件，往往用于任务分派、结果通知、组件解耦等场景。通过在边缘 Serverless 节点内提供消息队列和边缘函数的订阅者模式，可以帮助开发者构建更加复杂的多模块应用。比如，利用定时任务驱动作为任务中控的边缘函数发布网络探测任务，再由全球的消息队列消费者边缘函数消费这些任务，完成探测请求并通过日志推送能力收集数据，最后再通过定时任务驱动数据清洗边缘函数汇总数据。4.边缘 Serverless 典型应用场景 4.1.边缘渲染 场景需求：33 某业务需要在海外多个国家提供网页服务，而海外由于网络链路的原因导致用户访问性能较差。业务分别尝试了客户端渲染（CSR）和服务端渲染（SSR）。但是在实际操作中，由于客户端渲染依赖用户设备的性能且需要多次访问服务端获取动态内容导致效果不佳。而服务端渲染因中心服务距离客户端较远，客户端访问服务端路径长会导致时延高。并且服务端需要处理众多客户端请求，处理压力也会变大。因此期望有一种新的解决方案，在距离客户端较近的边缘执行渲染操作。接入效果：边缘函数可以帮助用户实现边缘渲染（ESR），用户可以将 HTML 模板内置在边缘函数中，使用边缘存储组件放置其他静态资源，使用边缘函数在边缘 Serverless 节点上渲染支出页面，兼顾客户端渲染和服务端渲染的优势。图 13 边缘渲染 上线后其首屏渲染速度时延降低 42%，显著提升了用户体验；另外，客户端请求不再需要频繁回服务端，有效降低了回源成本。34 4.2.灰度发布 场景需求：某业务为了避免新功能发布到生产环境影响全网用户，在 Web 前端希望采用灰度发布的方式让一部分用户试用新功能，根据观察用户使用情况再考虑全量放开或回退到上一个版本，这种方式可有效减少新版本发布时的风险和影响。如无灰度发布，新功能一旦发布有异常则会影响现网所有用户；如灰度发布在云中心实现，则控制链路长，时延高，会影响网站的访问速度和用户体验。接入效果：图 14 灰度发布 通过边缘函数可以在边缘侧根据用户特征实现某种灰度策略，对命中灰度策略的用户返回灰度内容或者重定向到灰度地址。相比云中心灰度发布，边缘节点更靠近用户处理灰度逻辑，可以尽可能降低灰度对网站的访问速度的影响。4.3.APK 动态签名 场景需求：35 安卓 APP 出于业务推广的目的往往会向应用市场、搜索引擎、其他 APP 等投放渠道包，渠道包内通过 APK 签名的机制打入对应的渠道信息用于应用方区分不同的渠道。但是维护成千上百的渠道包引入了额外的运营复杂度，并且目前的安卓 APP 尤其是游戏 APP 往往非常大（几百 MB 到几十 GB），大量的渠道包又额外引入了不必要的源站存储和流量成本。某游戏业务遇到该问题后，希望可以将写入渠道签名信息的逻辑转移到边缘执行，不再依赖源站分渠道包准备不同的安装包。接入效果：图 15 APK 动态签名 接入边缘函数后，业务只需要打包一份原始 APK 放在源站，用户通过不同的渠道链接访问边缘 Serverless 节点时，由边缘函数根据访问信息将签名数据打入 APK 内发送给用户。方案全量上线后业务源站回源流量下降接近九成，并且发布流程也明显简化。36 4.4.M3U8 改写 场景需求：HTTP Live Streaming（HLS）是一种基于 HTTP 的流媒体传输协议，广泛应用于直播和点播视频内容的传输。M3U8 文件是 HLS 技术中的一部分，包含对多个媒体文件的引用（通常是 TS 文件）。在实际使用中，视频的内容可能是付费内容/会员内容。出于对视频内容保护的目的，需要对 TS 文件的访问进行鉴权，避免未授权用户可以直接访问这些视频。由于鉴权串的计算一般都和 URL、时间戳等因素相关，导致每次用户访问 M3U8 文件时，需要根据当前用户的访问信息，实时计算出 M3U8 中包含的 TS 列表的鉴权串，并将 M3U8 中的 TS 列表对应的 URL 修改为携带鉴权信息的 URL 后，再返回给用户。如果 M3U8 的修改由传统的中心计算负责，会增加用户的首屏延迟，同时增加额外的计算和运营成本，因此业务希望在距离用户更近的边缘 Serverless 节点完成 M3U8 改写。接入效果：37 图 16 M3U8 改写 在边缘 Serverless 节点直接进行 M3U8 改写，既可以满足业务希望对视频内容做鉴权保护的需求，又不会引入额外的访问延迟和计算成本。架构上边缘函数的改写逻辑和边缘缓存逻辑部署在一起，不引入额外的外部依赖，也不会导致额外的稳定性问题。并且基于该架构还可以进一步扩展广告插入、自定义播放列表等个性化功能，具有充分的可扩展性。5.总结与展望 边缘 Serverless 是一种全新的算力模式，相对于传统的中心算力，天然具有低延迟、低成本的优势。然而边缘函数本身面临着网络条件复杂、硬件不稳定、节点分布零散等问题，针对这些问题，目前业界提出了如下解决方案：使用轻量级隔离环境和惰性加载等方案，降低部署和启动代价，使得边缘函数可以在全球任意节点随时执行，避免单机故障对用户造成影响。配合时间片调度等能力，提供和虚拟机、容器等环境类似的多租户隔离能力。提供边缘存储服务，避免单节点磁盘故障导致数据丢失，通过校验和等方式保障数据完整性，使得用户可以在边缘使用存储能力构建有状态服务。通过精细化自动调度能力，保障用户始终被调度在距离调用方延迟和负载最佳的节点。近 20 年，得益于内容分发网络（CDN）的蓬勃发展，互联网完成了流量从中心到边缘的迁移。而当前人工智能算法和基础研究快速发展，生成式 AI（文生图、大语言）逐步开始大规模应用。OpenAI 推出 ChatGPT 将大语言模型带入了用户的日常生活，目前已经拥有超过 1.8 亿用户。国内互联网厂商腾讯、百度等也分别推出了“通义千问”、“混元”、“文心一言”等大语言模型，以文心一言为例，对外发布后，目前已经收获了超过 4500 万用户。大模型的大规模应用导致厂商对计算尤其是GPU计算的需求量大幅度增长，根据媒体报道，38 早在 2023 年 4 月，OpenAI 每天就需要为 ChatGPT 支付超过 70 万美元的成本。当行业出现一款真正的国民级 AI 应用后，计算的成本开销将成为该行业的主要成本之一。鉴于边缘函数天然的低成本优势，相信在可以预见的未来，算力也会像流量一样完成从中心到边缘的迁移。

0人已浏览 2023-12-12 42页 5星级

出品机构：甲子光年智库研究指导：宋涛研究团队：刘瑶发布时间：2023.12目 录Part 01审视：简单概念之下的深刻内涵Part 02突围：时代飞速发展下的惊涛骇浪Part 04实践：智能时代下围绕业务的探索Part 05展望：低/无代码时代的人才需求Part 03价值：来源于技术，忠于业务实现追本溯源，低代码/无代码概念的关注来自于开发效率的极致追求对低代码/无代码概念的观察，不仅仅要看近10年的变化，市场需要将时间线拉长，理解这一概念提出背后的本质追求降低编码语言的晦涩难懂，从根本上提高开发的效率。第一阶段 初有萌芽，探索尝试1980年代，4GL“第四代编程语言”的出现(后衍生为VPL)；1987 年，Apple 发布的 HyperCard；2001年，SaaS的兴起，各类软件厂商尝试减轻开发难度；2001年，模型驱动架构(MDA)的出现；2007年，Salesforce面向开发者推出F应用开发平台；第二阶段 概念初成，头部尝鲜2007年，苹果发布iPhone iOS进入移动设备市场，随后一年谷歌的Android问世，Android Studio和Xcode等可视化编辑器提升开发效率；同时期，基于可视化编程语言的Web应用程序开发平台逐步得到认可，越来越多可视化手段帮助灵活地创建相应的web网站，带来更好的用户体验。2014年，Forrester提出“低代码平台”的概念；并且Gartner 将这一概念更广泛地推向大众，低代码/无代码从技术探索逐步走向形成市场共识。第三阶段 高速发展，群雄争霸移动互联网和云计算的发展，为低代码提供了技术支持，低代码/无代码实现飞速的增长；2018年，西门子收购低代码企业Mendix、美国低代码独角兽企业Outsystems获得1.5亿美元的融资。海内外市场均进入了高速发展的阶段。2015-2022年，国内低代码/无代码企业得到资本关注，截至2022年年末，融资事件高达80笔以上，其中亿元以上融资有18笔以上，并且软件开发厂商、云服务厂商等软件开发相关企业纷纷进入。2007年之前2007年-2014年2015年-2022年2023年开始，企业要面对机会与挑战的考验第四阶段 竞争加剧，AI登场生成式人工智能（AIGC）的价值与影响力在2023年得到诸多关注。2023年3月22日，微软旗下代码托管平台GitHub发布了编程辅助工具Copilot的全新版本Copilot X，新版本接入GPT-4，并新增了聊天和语音功能，允许开发人员用自然语言询问如何完成特定的编码功能。代码的开发方式，断崖式地提高了开发效率。同时，经过近十年的快速发展，低代码/无代码的厂商大量进入市场，同质化竞争愈演愈烈，部分脱离业务的低代码/无代码产品在使用过程中也备受争议，褒贬不一。低代码/无代码市场未来将面对技术及需求的双重洗礼，在探索中寻找出正确答案。ChatGPT带领全球跑步进入AGI时代，低代码/无代码对于开发效率的实践落地能力值得重新思考广义的低代码、无代码的理解：完成业务数字化项目开发的多重手段Forrester对于低代码的定义：能够以“最少的手写代码”和设置快速开发应用、配置和部署业务应用程序。也是目前市场对于低代码开发平台产品及服务的核心需求。无论是低代码、无代码还是纯代码，这些概念并不完全互斥，而是所表达的是工具对于项目开发环境、时间、人员要求不同程度的助力，解决企业数字化转型的业务需求和开发成本之间的矛盾，更高效地利用企业的数字化资产。广义的低代码无代码纯代码X%（1-X%）“无”“低”X（0X100）代表了多层次、细粒度、可复用的企业“数字化资产”满足应用开发需求的程度X值越大，数字化资产满足业务需求的程度越高降低代码的撰写门槛难度：往往在可视化界面中，通过拖拉拽执行代码模块。市场往往希望强调不需要任何编程语言基础，目的是消除使用者的语言学习成本。提升开发工作的效率：减少可重复代码的繁琐工作，通过搭建工具提升软件开发速度，加快项目的上线及迭代效率，市场的关注点是提升开发项目的经济性，加速企业数字化的进程。纯代码往往指全部或者绝大部分的编码工作均由开发者编写完成，不依靠任何模块自动化生成通过降低项目开发成本的资金及时间双重成本，提升业务数字化效率数据来源：低代码、纯代码和无代码的区别与联系，公开资料，专家访谈，甲子光年整理比较指标纯代码无代码低代码技术特征的区别开发方法模型驱动表单驱动*模型驱动&表单驱动*代码生成方式全程手写代码100%平台自动生成80%以上平台自动生成*平台可复用“数字化资产”不依赖依赖度高依赖度较高编码灵活性高偏低较高可编程能力高偏低较高客户化定制能力高偏低较高可移植性强极大地依赖于 APaaS 平台的部署功能对开发者的要求很高门槛较低仍有门槛（仍需要编码逻辑及开发基础）编码标准化程度低高较高编码的错误率高低较低用户操作的一致体验不一致一致BizDevOps 一体化过程自己建设APaaS平台负责管理从技术特征剖析无代码及低代码：不单单是代码工作量的极简*部分无代码平台/低代码平台是围绕表格完成业务的流转，一般被称为表格驱动；*模型驱动、表单驱动及表格驱动往往是从开发的角度出发进行区分，其他如“数据驱动”等，则是从业务需求和数据治理的角度去进行产品的描述。数据来源：低代码、纯代码和无代码的区别与联系，公开资料，专家访谈，甲子光年整理从业务需求剖析无代码及低代码：应用场景互补，目标人群具备差异性比较指标纯代码无代码低代码经济性的区别工作量较大较小较纯代码大幅减少交付较慢较快较快开发周期较长较短较纯代码明显缩短总开发成本较高较低较纯代码明显降低应用适应性预算充裕的应用开发预算较小的轻量化应用预算有限的普通应用开发应用场景的区别普适性强弱较强应用场景限制没有特别的限制专注于特定的细分领域适用于管理应用的开发行业领域通用性高不高较高适合的应用类型业务决策层应用业务执行层业务管理层应用目标开发者的区别对开发者的要求很高不高较高目标开发者专业开发者公民开发者专业和公民开发者融合团队业务复杂度负责人专业开发者公民开发者公民开发者客户化代码复杂度负责人无专业开发者样板代码复杂度负责人低代码平台低代码平台全体开发者构成专业开发者公民开发者，低代码平台公民开发者，专业开发者，低代码平台数据来源：低代码、纯代码和无代码的区别与联系，公开资料，专家访谈，甲子光年整理低代码/无代码均提供了数字化转型新的生产作业模式工具企业在构建数字化作业系统的过程中需要同时解决柔性作业、敏捷作业、快速研发、降本转型的基本问题企业的数字化转型低代码无代码通用化开发可视化、无需编码；主要交付企业生产作业过程中常用的系统和服务；不同产品发展基因和思路的低代码产品，直接影响交付的常用系统和服务能力范畴。扩展化开发少量编码；主要交付企业生产作业过程中个性化的系统和服务。无代码应用搭建平台基于规范的流程结合可视化的“拖拉拽”搭建相对较为简单的应用和服务；例如各种在线表单、问卷、审批等；大部分情况下，产品本身无法完成业务逻辑的编写。面向T端用户在线集成开发环境，支持应用程序开发、部署和运行，提供软件开发中的基础工具给用户，包括数据对象、权限管理、用户界面等。直面B端用户直面B端用户数据来源：公开资料，甲子光年整理目 录Part 01审视：简单概念之下的深刻内涵1Part 02突围：时代飞速发展下的惊涛骇浪Part 04实践：智能时代下围绕业务的探索Part 05展望：低/无代码时代的人才需求Part 03价值：来源于技术，忠于业务实现“数字化”依然是全球及中国企业发展的重要关注点，将持续驱动相关市场27.231.335.839.245.550.20.010.020.030.040.050.060.0200202021202210.6.9.6.0.2%-3.3%5.7%2.9%3.0%3.0%-5.0%5.0.0%.0 20202120222023E2024E数字化转型支出增幅GDP增幅全球数字化转型支出及GDP增长趋势预测，2020-2024中国数字经济规模（万亿元）及数字经济占GDP比重，.9A.5%数字经济占GDP比重数字经济占GDP比重数字化转型依然是全球企业的优先关注事项，是企业及组织寻求成为数字化企业的必经之路，在数字化企业中，对流程、产品、服务和体验的技术使用依然是关键性支出。产业数字化推动中国数字经济发展取得新突破，2022年，中国数字经济规模达到50.2万亿元，同比名义增长10.3%，已连续11年显著高于同期GDP名义增速，数字经济占GDP比重达到41.5%，这一比重相当于第二产业占国民经济的比重。子话题举例流程自动化、数字营销人工智能、云计算、5G气候变化、碳排放15914651数字化转型单点应用前沿技术探索可持续发展资源行业文章数量（篇）中国企业在数字化转型在深度和广度上有了新要求2018年5月至2019年4月2022年5月至2023年4月图 媒体报道中“数字化转型”的细分主题分类变化数字化作为企业整体转型战略来讨论，而非停留在技术革新的层面。企业逐渐认识到，数字化已不再是简单的技术概念或技术选择，而是进化成为关乎企业生死存亡的整体战略。企业对于人工智能、云技术、大数据等技术的讨论逐渐转向实际应用和效果，更关注技术投资是否能实现业务目标。企业对数字化转型的探索由局部的单点应用转向了系统化的构建和升级。技术作为企业转型的关键，展现出巨大的影响力，所覆盖的话题不断延展和深化。子话题举例业务增长、商业智能、投资决策、创新突破通信网络、人工智能、虚拟现实、大语言模型数字方案、应用开发、数字安全、数据合规数据分析、数据联通、智能运营、架构开发碳减排、自然资源管理、绿色行动、可再生能源上海品茶、岗位创造、技能匹配、远程办公278422568236861334721企业整体战略数字基建和前沿应用数字化转型系统工具数据智能可持续发展新增长来源文化和人才文章数量（篇）数据说明:以752家主流商业媒体发布的关于中国“数字化转型(Digitalization)”的中英文文章为分析样本，利用生成式人工智能提取出所有文章的主题，通过聚类算法对主题分簇，并根据所含主题内容对各簇进行命名。企业数字化业务将带来大量的企业级软件应用/服务的创新机会数量的增加：企业级应用/服务可以完成企业的数字化业务的载体，可提供新产品、新服务、新体验及新流程，数字经济的发展带来大量的新应用。创新的需求：企业软件创新能力与企业数字化成熟度息息相关，成熟度越高（如处于管理运营、优化创新阶段）的企业往往具备较强的软件创新能力（如主动创新、引领趋势）。IDCIDC预测：20242024年，数字经济的发展将孕育出超过5 5亿个新应用/服务，相当于过去4040年间出现的应用数量的总和。4.2%7.4%&%$.1 5D7.516.90%3.37.9.7%5%单点实验局部推广复制整合管理运营优化创新被追赶发展趋势孤岛化、碎片化主动创新引领趋势图 企业数字化转型成熟度与软件创新能力相关性分析企业数字化转型成熟度软件创新能力软件业务收入连续9年增加，数字化业务开发需求持续上升37026 42848 48232 55103 61909 72072 81506 95502 106126 15.7.6.2.4.4.2.1.2 002020212022软件业务收入（亿元）增速（%）图 中国20142014年-20222022年软件业务收入增长情况软件开发行业的快速发展让低代码/无代码平台迎来发展契机：2022年，中国软件业务收入跃上十万亿元台阶，全国软件和信息技术服务业规模以上企业超3.5万家，累计完成软件业务收入106126亿元，同比增长11.2%。2022年全国软件和信息技术服务业规模以上企业超3.5万家数据来源：公开资料，甲子光年整理数据来源：精益产品开发：原则、方法与实施，甲子光年整理中国低代码/无代码市场发展来自于对定制化开发的质量及效率的双重追求质量效率质量效率质量效率(个性化的)体验前工业时代工业时代规模化加标准化，让质量和效率得到统一数字化时代从规模化标准制造到规模化定制2843669200222023E2024E2025E2026E图 中国20202121年-20202626年低代码/无代码市场规模（亿元）中国低代码/无代码产品市场已经度过早期的技术与商业化模式的探索期，其产品能力的逐步提升，已经开始逐步实现企业核心业务系统的开发，市场逐步进入行业上升期。数字化时代，企业数字化转型的开发需要定制化的开发，同时兼顾质量及效率，低代码/无代码市场则高度匹配这一趋势，具备爆发式增长机会。在市场高速发展时期，开发相关的企业均借助自身优势赢取早期红利“下周”期望6 6-9 9个月现实新业务上线效率总是慢于预期大量临时定制化需求业务快速创新，需求定制常态化，且要求快速交付，企业缺少灵活支持应用创新的定制能力。专业技能短缺专业技能提升开发门槛，例如云、大数据移动化、视频、物联网、AI、安全。开发资源少，关注的事情多专业开发人员不足，需要负责机房搭建硬件，网络，软件部署，运维、安全等。经验无沉淀，能力无复用能力重复投资，重复建设，无法沉淀通用力，业务应用快速构建和创新。VSVS通过低/无代码解决开发的效率及成本问题云服务商（B B端云生态）原生型低代码/无代码厂商企服软件开发厂商RPARPA厂商传统定制开发项目厂商数字化转型咨询厂商衍生型服务厂商企业数字化的新业务不断提出，对项目开发提出了更高的时间需求，而资源难以匹配；低代码/无代码平台提供方则抓住机会，得以快速抢占市场。数据来源：公开资料，甲子光年整理抛开“低”“无”之争，产品需要扎实解决数字化建设的细节按技术路径及厂商背景的市场分类原生型服务厂商衍生型服务厂商提供无代码应用搭建平台提供低代码开发平台原生型服务厂商提供无代码应用搭建平台提供低代码开发平台衍生型服务厂商产品逐步凸显自身特色，解决企业数字化转型的“难啃的骨头”无代码搭建平台：基于规范的流程结合可视化的“拖拉拽”搭建相对较为简单的应用和服务。低代码开发平台：在线集成开发环境，支持应用程序开发、部署和运行，提供软件开发中的基础工具给用户。垂直场景的低代码/无代码解决方案AIGC 代码的开发范式探索企业级开发全栈的代码生成全链条的流程管理及企业协同数据治理能力无代码搭建方式/低代码开发平台的确为数字化建设提供了较纯代码更为方便的技术/工具，但在经过市场快速发展后，企业更关注如何利用工具可以解决自身的业务问题，选择更符合自身要求的工具。从通用性的工具转向更贴近企业自身的领域，关注产品的行业经验AIGC对于代码撰写颠覆式的创新引发更多技术改造低/无代码产品开发方式的稳定性、功能丰富性及可复制性，尤其是解决大型企业的复杂需求关注开发项目的“长治久安”，项目的安全及迭代仍然无法抛弃“源代码”业务的数字化转型需要以企业数据治理为基础，低代码/无代码也无法避免开发为业务服务，不仅仅要解决业务的单点问题，还要为整个组织的数字化建设服务数据来源：公开资料，甲子光年整理低代码/无代码推动“技术全民化”的同时也在重塑技术和业务的关系图 技术成为数字业务创新和发展的核心动力，技术与业务之间的关系发生重塑业务技术业务技术业务技术瀑布开发模式Biz与Dev分离，Dev和Ops分离敏捷、精益、DevOpsBiz与Dev更紧密的协作，Dev与Ops融合BizDevOpsDev和Ops融合基础上，Biz与技术融合通过信息系统支持商业的需求，改进运营效率早期信息化互联网技术与业务开始融合，激发商业模式创新互联网经济数字化技术成为业务创新和发展的核心动力数字经济基于低代码产品的应用与服务开发模式：打破了职能竖井，还能通过统一的可视化语言和单一的应用表示（页面/数据/逻辑），轻松对齐项目各方对应用形态和项目进度的理解，实现更终极的敏捷开发模式，以及在传统 DevOps 基础之上更进一步的 BizDevOps，打造数字化业务背后的作业体系持续赋能数字化业务的创新和发展。数据来源：公开资料，甲子光年整理目 录Part 01审视：简单概念之下的深刻内涵Part 02突围：时代飞速发展下的惊涛骇浪Part 04实践：智能时代下围绕业务的探索Part 05展望：低/无代码时代的人才需求Part 03价值：来源于技术，忠于业务实现业务实现的困境：技术交付面对的复杂度在不断提升图 数字化时代产品技术交付的三大核心挑战高效交付成为数字化时代产品技术的挑战，核心问题是背后IT复杂度的不断增加。数字化时代，技术交付的复杂度持续提升：协作需求：需要跨业务和产品的协同才能交付完整价值，协作的复杂度变大；工程复杂：系统复杂度的提升，以及全面的数字化带来的包括云、IOT、边缘设备和各类终端的联动，让工程复杂度极大提升；业务融合：随着技术和业务的融合，业务本身的不确定性和复杂度也在提升。局部效率高效交付持续高效业务成功 数字化进程期望现实ITIT成为业务创新和发展核心，对ITIT交付效能的期望越来越高ITIT交付效能复杂度增加，ITIT交付效能有下降趋势IT IT 交付的复杂度关键因素：协作、工程、业务图 数字化时代的ITIT交付效能急需提升数据来源：公开资料，甲子光年整理时间复杂化业务功能增加用户量增长团队规模增长时间复杂化控制复杂度技术复杂度（偶然复杂度）业务复杂度（本质复杂度）关注点分离开发者职责低代码模式基础设施下沉技术复杂度业务复杂度技术复杂度传统开发模式低代码产品职责开发者职责传统企业数字化步伐的加快与需求激增，传统开发模式下的开发者（团队）需要同时解决“业务复杂度”与“技术复杂度”，而同时具备业务经验与开发技术的IT人才供给不足，导致企业数字化建设受阻；常见的基于低代码平台的开发者（团队），由项目负责人、业务专家、架构师、高级程序员为基本组成，其中：项目负责人与业务团队深度沟通需求，理解并梳理清楚业务逻辑 架构师根据业务专家导入清晰的业务逻辑，输出系统搭建思路（含技术路线、开发步骤等）高级程序员根据业务专家需求，会同架构师进行数据模型、应用服务的设计，并形成完整的文档（含技术选型、架构设计、功能设计、数据库设计、服务设计、UI原型设计等）初级程序员以及受过一定低代码技术培训的业务人员，根据相关文档，进行具体系统功能的开发这种开发模式下，开发者（团队）的职责聚焦于解决“业务复杂度”，而“技术复杂度”由低代码平台的提供者解决，甚至借助平台的开发者社区来解决高频、共性的开发问题对抗软件复杂度的“战争”低代码/无代码对于业务实现的核心价值之一：对抗不断增加的复杂度商业上获得成功的软件必然伴随着业务的增加、用户量的增长、研发团队的增长，这三个因素会不断推动软件复杂度的增长直至爆炸。软件工程要解决的一个核心命题，就是如何控制复杂度。图 软件开发过程中的复杂度示意图数据来源：公开资料，甲子光年整理时间整体进度“战术编程”“战略编程”“成为一名优秀的软件设计师的第一步是认识到仅仅为了完成工作编写代码是不够的。为了更快地完成当前的任务而引入不必要的复杂性是不可接受的。最重要的是这个系统的长期结构。”-John Ousterhout（约翰欧斯特霍特），A Philosophy of Software Design低代码/无代码为开发人员提供了项目质量管理的战略思考角度图“战略编程”与“战术编程”的进度比较低代码开发平台可以提供在线集成开发环境，支持应用程序开发、部署和运行，提供软件开发中的基础工具给用户，包括数据对象、权限管理、用户界面等。无代码搭建平台通过快速建立多种表单、基于规范的流程进行链接，并定义输出的方式，迅速搭建一个轻量级的应用或服务，从而实现在多个参与者之间按某种预定规则自动传递文档、信息或者任务。从“战术角度”提供了绝好的代码撰写工具从“战略角度”提供了与业务建立链接的机会低代码/无代码平台可让业务人员及开发人员实现更快地原型沟通，可在日常需求开发工作中，推动需求所涉及到的设计能够面向未来扩展，而非仅仅着眼于完成当前的需求。低代码/无代码平台通过不断弥补业务与开发之间的沟壑来提高“战略编程”的时效性。数据来源：公开资料，甲子光年整理企业的数字化转型需要低代码/无代码平台实现数据与业务的链接（1/2)各个环节的数字化应用用户价值驱动的全链路款字化各独立环节的信息化信息层面的系统集成数据共享价值链路业务环节信息传递2.数字能力：全微路放字化运行1.业务能力：连接价值交付链路数据应用和数据智能3.数据能力:沉淀并释放数据资产价值1.业务能力：连接价值交付链路站在客户的视角，打通客户（业务）价值交付链路，精准地获取、响应和满足客户的（个性化）需求。2.数字能力：全链路数字化运行基于对业务的本质理解，建立底层数字化模型，并有效连接数字世票和物理世界。以此为基础，在全链路上共享数据，重构价值交付链路，确保价值交付的全链路效率和质量。3.数据能力：沉淀并释放数据资产价值基于全量、全要素和实时的数据，保障和持续提升业务运营的效率。并以此为基础，沉淀和应用数据资产，激发业务创新，创造全新的商业模式和用户体验。图 数字化转型的三个核心能力数据来源：公开资料，甲子光年整理企业的数字化转型需要低代码/无代码平台实现数据与业务的链接（2/2)数据标准模型数据标准配置元数据管理数据标准执行数据标准数据集成ETL任务算子调度执行引擎流程控制引擎数据集成数据质量稽核数据质量稽核数据质量报告问题数据预警数据质量数据雾化安全算法安全密钥数据加解密数据质量统一资产操作接口（SDK/物理建模/数据权限）数据资产管理资产数据资产配置数据结构关联关系血缘关系分析图表质量检测数据权限生命周期模型采集/模型设计/关系定义物理资产逻辑资产多媒体时空资产关系型/非关系型教据库低代码/无代码应用数据接口配置接口配置接口配置接口配置低代码/无代码平台接口loT设备数据在线公共数据国产数据库数据接入图 低代码/无代码平台可接入企业数据资产并基于此进行项目开发及数据管理数据来源：公开资料，数睿数据，甲子光年整理不断快速搭建数字化业务流程，实现企业的数字化能力迭代行政人力组织文化行政管理绩效管理法律顾问公司培训招聘管理财务资金财务管理税务管理资金统筹预算分析成本控制内部审计生产制造技术开发生产计划采购供应仓储物流设备维护质量检测市场营销市场运营商务销售渠道管理客户服务广告投放品牌公关IT信息IT规划信息安全功能开发项目管理系统运维企业部门与部门之间、部门内部之间的协作与融合表单类应用与服务信息汇总与展示类应用与服务办公类应用与服务客户管理/经营类应用与服务供应商/经销商管理类企业资源管理与计划类应用与服务链接、连接、联通存量系统商机与营销类应用与服务场景化解决方案细分场景解决方案一体化数字化解决方案传统产业数字化作业体系设计、开发、运维一体化Infrastructure程序化自动执行类应用与服务低代码/无代码产品从单点工作业务开发到整体的企业级建设数据来源：公开资料，甲子光年整理从单点轻量应用到构建完整的数字化作业体系企业互联网平台（企业数字化平台系统）产业互联网平台（全产业链数字化生态系统）供应端（交易）品牌端（交易 运营）平台端（后台管理）渠道端/终端（交易）用户端（交互）数字化采购数字化组织数字化系统数字化分销数字化终端数字化营销应用管理数据管理业务管理PC运营管理App管理/商城小程序商城商品中心渠道中心会员中心结算中心分账中心业务数据存储数据集成数据分销分销分销分销门店客户分销一级分销电商渠道传统渠道大客户线上电商直营/加盟/KA线上社会化营销线下社会化营销线上用户线下用户三方平台下单自有平台下单交易订单门店下单门店订单线上营销推广线上用户活动线下营销推广线下用户活动商品管理销售订单销售结算售后服务物流发货仓库接单物流接单第三方物流送货上门订单中心库存中心商品中心渠道中心会员中心结算中心品牌中心物流中心客服中心仓库接单总仓 电商仓物流接单第三方物流送货上门线上电商产品营销自动补货销售信息产品组合仓储管理加工订单生产工艺供应采购业务不仅仅需要解决单点问题，更需要向作业的前后链路、企业的内外链路扩展，实现一套企业自身流畅的数字化打法数据来源：甲子光年智库尊重不同规模企业的数字化需求与规划，在短期内保持战略与战术目标同在小型企业（稳定生存）中型企业（发展壮大）大型企业（引领发展）数字化作业体系需要快速响应能力，对不同人员作业响应能力的要求的挑战数字化作业体系强化了整个组织在作业规则和流程方面的持续建设，使得整个组织的创新力不足难以兼顾各个部门差异化、个性化的业务需求组织现有的业务最佳实践与积累，在转型的过程中缺乏有效的“容器”，可复用性降低面临着流失的风险数字化作业体系提供的实时信息深度洞察所形成的业务角色精准支撑，打破了现有的作业习惯和整个组织的运作惯性原有的IT系统和设施给数字化转型带来的负担IoT与低/无代码产品的融合实践，同样是企业的高价值应用场景数据用户流程基于低代码构建AIoT化作业平台连接可视化在云上构建端到端的生产制造管理：产品构思、设计、测试、仿真、排产，到质量控制、产线设计、生产执行低代码产品物联网平台构建产品智能化改造应用场景化方案基于设备的售后体系生产端智能化改造产品、备件的全生命周期追踪Now利用低代码的平台能力：企业可以对已有产品、生产端进行智能化改造，为实现整个生产制造的闭环打下技术基础；企业可以把研发设计、运营管理、生产制造的全业务系统打通，形成高价值应用场景化方案；构建产品、设备的全生命周期追踪能力，把产品状态和生产过程信息采集和汇总，打通研发和生产制造的最后一公里，实现整个生产制造的闭环，从而将产品研发创新提升到新的高度。Before传统企业信息化系统可以管理从产品设计到仿真、试验，再到排产、质量控制和生产制造等过程，但产品出厂之后的状态是无法获取的，这导致企业与消费者之间出现信息断层，不利于产品进一步优化创新。数据来源：公开资料，甲子光年整理AIGC的价值不仅在于一步生成代码，也带来了更智能的交互方式革命式的代码生成方式带来了期待交互体验的提升正在实现AIGC自然语言文本代码代码生成任务数据生成代码预处理大模型预训练微调后处理大量样本生成文本/代码大数据现阶段的代码大模型：采用自然语言的需求描述或其他提示，通过预训练代码大模型直接生成满足需求的程序代码。AIGC对于低代码/无代码平台的最大冲击来自于市场对于AIGC的极高期待，尤其是代码与自然语言在模型训练上的类似性让市场寄予厚望。但大模型本身所具有的不确定性等问题，短时间内难以快速形成商业化产品的封装，在短期内的功能更多体现在交互体验的提升上。需求初始方案迭代修订终版沟通交付需求1需求n一轮n轮Part 1Part nPart 2需求2迭代二轮未来的代码大模型：学习代码中蕴含的编程逻辑，实现AI生成相应业务的逻辑模型，实现一步完成业务需求的理解与代码生成。AIGCAIGC可直接根据需求生成初版的样例，减轻文档背后的沟通压力。AIGCAIGC可帮助实现需求的理解，从“拖拉拽”改为更为简单的语言或语音交互模式，进一步降低非开发人员的应用难度。AIGCAIGC作为辅助学习助手，可以降低低代码/无代码平台的学习门槛，加快“全民开发者”的学习速度。数据来源：公开资料，甲子光年整理多数开发者会选择尝试AI编码提升自身的效率及技能水平开发者使用AI编程工具的比例70%的开发者认为AI可提高开发水平的比例92p%的开发者开始使用AI编程工具开发者认可AI的比例57SQA%提高编程技能变得更有效率创造性工作防止倦怠开发者使用AI代码生成可提升工作效果数据备注：GitHub AI对开发者体验影响调研，调研对象：员工规模超过1000人的美国企业的研发人员，N=500，时间：2023年6月数据来源：公开资料，致远互联，甲子光年整理大模型爆发元年，国内低代码/无代码企业紧跟趋势，探索AIGC在低代码方向的应用致远互联于今年9月正式发布AI-COP大模型框架，推出一站式AI协同管理与运营服务平台，并发布国内首个公文领域大模型。数睿数据在AI层面的规划为“智能体验”，将AIGC融入数据、分析、应用三个核心能力体系，致力于打造适配smardaten的AIGC能力框架，来提高用户体验。炎黄盈动率先发布国内AI低代码平台，8月22日，推出Al Copilot for Builder，采用自然语言交互生成更贴合用户需求的数字化应用，在持续引领AI低代码领域创新发展的同时，效率与安全透明并重。蓝凌全面开启智能化战略，用AI增强低代码、BPM流程管理、知识管理等平台，为组织数字化转型按下“AI加速键”。奥哲对低代码 AIGC融合演进早已做了长期明确的规划，深度关注AI发展。目前旗下AI相关产品正处于客户共创阶段，并已开通申请使用资格，计划在不久之后推出市场。AIGC可贯穿数据资产管理与软件开发全周期，赋能低/无代码产品迭代升级贯穿软件开发全流程AIGC在企业信息化数据治理方面的赋能环节示例AIGC在软件开发方面的赋能环节示例数据标准管理数据模型管理贯穿数据生命管理周期数据资产管理主数据管理数据质量管理元数据管理数据共享管理数据安全治理数据治理环节核心价值围绕数据源的管理，解决数据存储及数据计算的问题基于AI对图片、视频及自然语言的理解能力，对非结构化数据进行更高价值的管理，满足数据处理的高并发及实时性要求赋能环节示例构建基础数据标准、指标数据标和数据模型标准，在数据共享流通基础上为开发及应用提供“一致语言”针对元数据的采集、分类、识别及质量分析进行优化管理，借助生成式AI的分析能力实现对于视频、语言等类型的数据质量评估、跟进、监控及自动化处理及报告，便于业务人员参与数据治理软件开发环节核心价值赋能环节示例需求调研分析概要设计详细设计软件编码软件测试交付准备软件验收运维服务通过生成式AI，可以减少代码编写过程中的大量重复性工作，规避大量在代码生成过程中的语法问题，并且实现需求文档的快速生成降低多部门、多组织的交互难度，通过自然语言跨越业务人员与代码人员之间的沟通壁垒，实现局部需求的快速实现及迭代完成功能需求分析、性能需求分析等快速生成代码草稿，自动生成代码注释及文档，加快代码生成效率通过交互式语言快速生成代码片段及需求模块，便于原型阶段的设计及需求同步自动生成测试、验收报告，实现部分文件交付环节的自动化数据来源：公开资料，甲子光年整理目 录Part 01审视：简单概念之下的深刻内涵Part 02突围：时代飞速发展下的惊涛骇浪Part 04实践：智能时代下围绕业务的探索Part 05展望：低/无代码时代的人才需求Part 03价值：来源于技术，忠于业务实现产业图谱：涌现了一批优秀的低代码/无代码厂商参与者的多元性逐步增加，在打造产品独特性的同时也在不断借鉴融合低代码/无代码供应商始终在探索适合中国本土企业应用之道重视本土企业的切实需求：基于中国本土软件开发或数字化发展的具体特点进行产品迭代；关注以AIGC为代表的先进技术：始终关注技术发展与应用，甚至进行提前布局，可第一时间将生成式AI等前进技术与产品进行融合；普惠大众，对象广泛：无论是“公民开发者”还是“专业开发者”，都是中国低代码/无代码厂商的关注对象；切实提升开发能力：无论是针对个人级开发还是企业级开发，中国厂商都在寻找一条切实可行的低代码/无代码落地之路，最大程度提升个人/企业的开发能力。低代码/无代码厂商*企业应用及软件开发商云服务RPA厂商低代码/无代码供应商图谱（海外）*部分情况下，战略上高度关注低代码/无代码产品的厂商也在此列重点厂商产品及服务能力分析数睿数据低/无代码开发平台通用或行业应用软件BI/大数据平台三方能力融合量变到质变成长型软件企业产品设计、开发、测试、实施人员，大型企业信息中心开发、实施人员无代码开发 全域数据资产管理 可视化分析与BI产品能力应用场景用户画像软件产品研发底座、企业数字化基座运行中心运营中心测试集成应用/模块开发组件库安装部署升级维护巡检监测日志分析异常告警应用数据分析组件使用分析 资产盘点用户反馈用户分析项目管理生产中心需求设计产品优势“数用一体”能力需求的全覆盖能力面向不同客户的差异化服务统一无代码开发统一应用集成全域数据资产管理贯穿软件工程的一体化开发平台，提升研发交付能力面向软件企业面向甲方客户打造覆盖数字化建设、运维、运营管理的一体化能力政务|智慧城市|工业制造|能源电力|教育|环保|应急管理|企业数字化 服务能力面对甲方客户：完成高质量、高效率的多场景业务需求落地，打造一体化数字化能力。应用场景面对ISV：提供高效能的无代码开发能力，授之以渔，实现交付效能提升、标准化产品沉淀和业务拓展。数睿数据（南京数睿数据科技有限公司）是数据驱动的企业级无代码开发平台领导者，smardaten核心能力在于数用一体的数字化应用构建，包含数字底座、无代码应用构建能力、物联网中间件以及智能化技术在数据智能分析、应用自动化构建中的应用。聚焦服务行业软件企业、中大型终端企业客户，面向软件开发团队提供贯穿软件工程（需求-设计-开发-测试）全流程工具能力，也面向企业信息中心打造一体化的软件生产-运维-运营能力。目前已成功服务10多个行业领域的400 行业头部企业，目前在智慧政务、智慧城市、工业制造、能源电力、数字乡村、企业数字化等多个行业场景均已得到验证。数据驱动的企业级无代码软件平台，专注赋能行业软件企业与中大型终端企业需求分析-原型设计-功能配置开发-集成测试-一体化交付运维重点厂商产品及服务能力分析数睿数据某传统工业领域国企研究院，是服务于国家“两弹一星”战略工程而成立的国家级科研院所，是玻璃纤维工业技术的策源地，是行业和区域性的中心基地，主要从事玻璃纤维及制品的研发、设计、制造和测试评价，为国防军工配套、行业技术进步和新材料产业升级做出了重要贡献。项目效果业务需求项目亮点客户背景介绍 数字化能力上相对来说较为薄弱，研发能力跟不上业务快速发展需求，需要高效快速地建设自身的数字化能力。在多个场景业务中需要加速数字化建设、实现转型发展。但不希望采用传统项目形式（往往使用多家厂商来完成数字化系统建设）避免出现效率低、多厂商难以形成融合的情况出现。不同业务系统都能在统一的平台上进行数据沉淀和业务沉淀，为未来的能力建设提供基础通过预防性诊断平台，加速生产管理能力、降低设备故障率。数字实验室管理实现全过程的实验智能管控和实验室管理，系统迭代数次后，已推广至全国4家实验室。工业算法模型已沉淀和优化数十种模型，提高产品检验监测能力。将基于行业数据中心之上，打造面向行业的数据资源开放共享平台，充分发挥现有数据资源价值。基于企业级无代码开发平台的一体化数字化建设方案，形成可持续的企业数字化能力，实现已有业务的沉淀、未来业务可不断迭代和生成。smardaten作为通用开发底座，可面向全场景进行开发交付，满足客户广泛的业务领域需求，并且选择在当前几个典型业务场景和数字化建设需求更加强烈的领域进行开发，再根据业务需求持续迭代和优化，并能对标准化系统进行复制和推广。某工业领域的国家级科研院所基于smardaten企业级无代码开发平台，形成一体化的数字化应用开发模式，采用无代码智能软件工厂高效的实施交付模式，实现多个业务场景的数字化应用构建在将近2年的时间，数睿数据为客户提供生产管理、行业数据管理、项目管理、实验管理、产业数字化服务等多场景数字化建设服务。主要场景涉及到复合材料生产监控、数字实验室管理、项目管理、工业算法模型以及行业数据中心建设等。工序计划进度跟踪计划能力评估高级排程作业调度作业指令进度进度汇报作业监控品质数采品质追溯测质量监控质量SPC物料标识物流计划料拉式配送智能物流设备管理工艺装备机运行监控动态OEE工艺设定作业指导法异常管理防错纠错人员档案上岗记录人能力资质绩效评估安环巡查能耗采集环环境监测安环预警数据沉淀数据接入数据集成数据质量数据安全数据标准数据管理数据服务数据资产/行业知识库重点厂商产品及服务能力分析致远互联发布AI-COP大模型框架，打造新型to B数字化基座和智慧型运营服务商致远互联成立于2002年，是一家集产品的设计、研发、销售及服务为一体高新技术企业，为客户提供专业的协同管理产品、解决方案、平台及云服务。致远互联坚持平台化经营、生态化发展，打造数智化协同运营平台AI-COP，以“平台 低代码”模式，提供一体化数智底座和一站式数字生长能力，一站使能政企数智升级，实现高质量发展。基于一体化平台底座能力，以及可规模化、可定制化、可深度集成的应用搭建能力，为客户及生态伙伴提供高定制化与高性价比的支撑方案，助力客户及伙伴搭建出更符合个性化需求的行业应用。产品优势技术亮点标杆客户致远互联AI-COP大模型框架COP核心能力大模型管理能力数据及知识管理能力公文大模型内控合规模型行为绩效模型华为盘古通义千问智源基座大模型Open AI文心一言协同领域大模型协同应用模型AI-COP能力平台低代码能力 AI编程能力场景智能应用领域智能应用行业智能应用AI工具箱数字员工数智化应用面向复杂可规模化交付的产品构建的企业级低代码平台，提供企业级复杂应用的底层支撑：包括流程、门户、BI、AI、连接等可复用的业务能力单元，适配不同领域、行业、规模客户的深度需求。丰富稳定的功能：领域模型驱动、代码生成、编译执行、高性能高安全、云原生微服务架构可保证应用实现脱离低代码平台独立运行。灵活的部署方式：云端设计，线下运行，支持私有化部署和SaaS运维，支持标准微服务方式部署，也支持轻量的单体模式部署，支持多端、多云、国产化适配。多层级定制能力：分层研发，立体化多层次的规模化定制体系，为原厂设计师、组件开发人员、实施顾问、客户IT和业务人员提供不同层次的定制能力，支持平滑升级。助力全国50000 50000 家政府及企业组织实现数字化转型升级，基于aPaaS服务打造的组装式应用业务定制平台，以“平台 资源 服务”的方式，满足客户增量、长尾需求，让企业全链路数字化系统变得更加连续。至今，致远互联低代码客户使用率已达到85%以上，已实现多行业、多领域覆盖。重点厂商产品及服务能力分析致远互联郎酒股份是以生产经营中国名酒“郎”牌系列酒为主营业务的大型现代化企业，更以自开一脉的“赤水河左岸庄园酱酒”的青花郎酒成为业内瞩目的名酒品牌。全资及控股了17家子公司，员工总数20000余人，已步入百亿白酒集团行列。业务需求项目亮点客户背景介绍数据量大难支撑2010年，随着业务的快速扩张，每天需要审批签字的文件不计其数。与此同时，承载郎酒股份生产经营的ERP系统沉淀的信息和数据越来越多，业务系统也亟需更新改造。传统 OA 无法满足企业需求郎酒股份的信息化建设一直由总部来做总体规划，在生产、销售、人力、财务等不同领域各自上线应用系统，最后造成各业务系统独立运行，形成信息孤岛。致远互联助力郎酒股份集团化协同运营管控的探索项目效果郎酒股份以致远互联协同运营平台为信息化骨干系统，并基于对业务系统的内核需求分析，搭建相应的专业子模块，满足部门和集团总部的管理需求，实现业务运作和协同运营的完美融合。全生命周期人事管理实现在统一规范下个性化的人事管理，高效统计全集团员工日常考勤等情况，让优秀人才可储备、可推荐。建立合理费控管理体系严格控制从预算到核报的整个业务线，保障信息完整性和数据有效性，通过多维度综合分析，建立合理的费用管理体系，降低市场成本、提高经营效益。实现全面预算自动化实时掌握集团各分子公司、部门预算的编制和执行情况，从线下管控模式转变为线上自动化管控，极大提升办公效率。从2012年，上线协同管理平台和市场费用管理平台，并在随后的两年，自主完成协同平台的功能拓展，自建应用流程上千项；2016年-2017年，完成人力资源管理系统建设，实现企业员工全职业生命周期管理、统一规范下的个性化管理；2018年，完成全面预算管理建设，完成郎酒14类预算主体的费用管理；2021年，完成生产管理系统；2022年，完成大资产管理系统，实现生产管理业务执行数据前后有效衔接；同年，启动大资产管理建设，通过各类资产的全生命周期管理。目前，实现整个股份公司内多组织、20000余员工，从办公、业务、财务、管理与运营的一体化运作，全面提效郎酒数智化转型。2012年2016年2017年2018年2021年2022年重点厂商产品及服务能力分析奥哲稳居低代码市场领先地位，提供全面的低代码产品矩阵奥哲成立于2010年，是一家拥有完整零代码和低代码产品矩阵的数字化服务厂商，支持私有云、混合云和公有云等多种部署模式，致力于通过提供低代码产品和相应解决方案，帮助不同类型企业快速实现数字化转型。奥哲累计服务超过20万家企业组织，包括60%的中国500强及众多行业标杆企业。全行业覆盖，特别在金融、建筑、制造、能源、政府等行业，斩获多家行业标杆型企业客户，包含华泰证券、国信证券、中国石化、中建集团、中国铁建、西子联合、建发地产、汇川联合动力等。产品优势技术优势最早一批布局低代码的企业，连续十年将30%收入投入研发，在业务模型、流程引擎、逻辑引擎、页面引擎、数据处理引擎五大低代码技术核心领域深度积累。拥有自研编译器能力的企业，该项技术能力全球领先；拥有自研页面引擎技术能力，依托该引擎突破了2B2C设计场景化的交互方式难点，为客户提供最佳体验。自研的流程引擎贴合中国企业管理流程管理要求，可实现大型企业流程100%配置。将领域模型设计落地到产品，将低代码从传统的表单型业务应用、进化到可支撑企业核心业务系统的构建。在开发效率和使用门槛上，奥哲低代码平台可面向不同层次的用户进行分层设计，让技术和业务深度融合，为企业数字化创新提供能力支撑。汇集国内第一批低代码行业开创者，拥有行业经验丰富、专业的研发团队：技术核心成员来自于微软、华为、腾讯、阿里等知名企业，具有AI研究、TO B创业经历和10余年技术研发经验。应用开发平台大中型企业数字化核心引擎业务类SaaS应用核心业务系统中小组织业务数字化一站式平台大型企业部门数字化统一工作平台采用最新的云原生、微服务架构理念，以元数据和模型驱动的应用开发模式，支持前后端快速扩展、在线开发、应用全生命周期闭环管理与无缝平滑升级。云枢主要应用于企业统一流程中台构建、各类业务应用的敏捷开发，也适用于大型企业统一开发平台，帮助企业构建统一开发标准，提升业务构建效率，助力企业实现业务敏捷、业务在线。截至目前，中国500强企业中超六成企业使用奥哲云枢构建企业核心应用系统。通过氚云，用户不需要代码即可在线搭建应用并快速完成上线。目前，已有20多万家企业通过氚云搭建个性化系统，应用覆盖制造、建筑、贸易、零售、教育等多个行业，满足业务、IT、企业管理者等各种角色的数字化需求。氚云现已拥有530万终端用户，累计创造业务应用达到150万个，为近30个细分行业提供了300 行业解决方案。面向企业级部门和团队数字化统一工作平台，是以数据为核心的零代码产品。用户体感流畅平滑，并且拥有后台数据、流程和计算引擎等自研技术，可构建前台低代码内核（代号LCOS），致力于让普通业务人员轻松创建各类业务应用及场景化应用。业务管理类应用数据协同类应用场景广度简单易用场景深度自主可控国产化全民开发平台流程管理平台统一开发平台个性定制：敏捷支持汇川个性化联动排产等数字化应用；敏捷高效：联动排产应用原计划4个月完成，采用低代码2个月构建上线；赋能共创：赋能 共创，为汇川提供一个系统外，也提供一个平台、一支队伍、一个体系；自主可控：构建汇川联合动力自主可控敏捷开发平台，支持LTC、供应链、生产制造等更多业务数字化。重点厂商产品及服务能力分析奥哲苏州汇川联合动力系统有限公司是汇川集团旗下子公司，专业从事新能源汽车动力总成系统、电机控制器、电机、电源总成等产品的研发、制造。作为业内优秀的新能源企业，在LTC、供应链、生产制造、研发等持续创新，亟需一个面向未来、敏捷可扩展的低代码开发平台，为企业未来持续数字化及创新提供有力支撑。项目效果业务需求项目亮点客户背景介绍以联动排产为例，项目需求痛点：1.按客户订单生成总成工单、电控工单、电机工单及减速器工单，总成工单和电控工单、电机工单减速器工单相互联动，手工排产繁琐易出错；2.不同总成工单有相同半成品工单，排产需要进行合单、拆单、拼板；3.联动排产需要进行复杂的逻辑计算，没有标准产品可以实现；4.需要和ERP、MES、WMS、HR等系统集成；同时，在LTC、供应链、生产管理等其他环节也存在大量个性化创新场景，缺乏数字化系统支持。全面数字化：构建标准ERP 低代码敏捷应用的数字化新生态，实现全面数字化。TCO（总体成本）最低：基于奥哲云枢低代码平台，满足持续涌现的数字化需求并迭代，TCO最低。持续成功：提升汇川联合动力企业数字化综合能力，实现数字化项目持续成功。面向未来：低代码具备未来支持IT扩展性，柔性支撑的特性，为汇川联合动力未来持续数字化及创新提供有力支撑。业务应用技术中台后台系统容器中间件服务治理DevOps镜像仓库云枢低代码规则设计器表单设计器流程设计器报表设计器视图设计器门户员工供应商 经销商 合作伙伴客户飞书、小程序、WebWeb浏览器、Open APIOpen APIAIPRAAR/VR新技术集成设计器门户设计器ERPADWMSHRMES基础数据工厂车间线体外协供应商应用服务库位日历班次日历明细日历列表生产班次排班信息物料类别排产规则工单规则合单规则工单管理工单新增工单导入工单合并工单发放工单取消工单变更工单上报ERP异常ERP物料变更记录ERP工单中间表工单排产工单排产工单排序看板管理计划看板排产看板生产看板联动排产管理系统示意图重点厂商产品及服务能力分析蓝凌软件提供零代码、低代码、高代码一体化的平台，数智化办公专家蓝凌（深圳市蓝凌软件股份有限公司）成立于2001年，是深圳500强企业。为各类组织提供工作门户、BPM流程、低代码、信创办公、协同办公、知识管理、合同管理、费控等数字化解决方案；公司现有员工及伙伴3000 ，技术研发人员占70%。蓝凌低代码开发平台可大幅降低企业应用开发门槛，简单拖拽即可快速实现应用模块设计，随需而建，随需而变；支持AI搭建应用、AI优化场景、AI代码助手、AI业务场景，支持实时预览、快速部署，让业务实现更简单，较传统开发方式效率提升10倍。产品优势标杆客户技术优势零代码低代码高代码面向业务创新者，提供零代码配置的能力，可拖拉拽简单配置完成业务构建。面对柔性变化的业务，提供Lcode低代码平台，可以在线编码，进行前端和后端的代码扩展，并且提供了丰富的扩展点和样例代码库，在线编码，完成业务的定制。面对复杂的业务以及长流程的场景，通过低代码搭建的成果生成源代码，结合蓝凌的专业开发能力完成企业需求。蓝凌低代码是零代码、低代码、高代码一体化的平台，满足企业各类角色使用，同时满足长期技术发展。先后助力中信、万科、小米、紫金矿业等数万家知名企业实现了智慧管理与高效办公的工作变革；截至2022年底，公司与华为云、阿里云、金山云等100 家厂商达成战略合作，累计服务4000 万员工。研发部：研发专利管理高效率生产/制造部：轻量化生产制造更便利厂务部：固资管理更简单销售部：高效经营新老客户采购部：采购与供应商管理更透明市场及运营部：营销费用管理降成本财务部：经济类合同管理在线搭建专利管理，形成统一知识产权库，文件统一线上管理，提高查找效率，降低管理成本，降低资产损失；各部门之间可实时了解公司专利情况，打破部门之间的信息孤岛，避免重复建设。围绕业务主线系统建立销售单、财务收款、生产单、质检单、发货单等功能，构建生产制造全生命周期管理，加快企业产业结构升级。打造固资管理，对固资从申购、入库、领用到报废进行全生命周期管理，加强管理规范性；每个固定资产都有唯一责任人，实现固资管理流程化。涵盖客户信息管理、跟进、拜访记录、商机管理、报价管理、合同管理等全生命周期的功能，支撑客户经营人员的日常需要，高效经营新老客户，实现完整业绩闭环。将采购需求统一线上管理，支持采购人员线上询价、供应商线上报价，缩短沟通链条的同时降低沟通成本，提高采购效率；建立供应商准入、认证、考核机制，规范供应商管理保证产品质量，降低企业成本，反哺企业的发展与盈利。制造业企业财务部，通过蓝凌低代码搭建经济类合同管理，支持合同在线起草、移动审批、归档，并集成第三方在线签署服务，让合同全程高效，支撑业务赢单，企业收入不断增长。搭建营销费用全生命周期管理：基础信息管理、经销商管理、合同管理、政策管理、订单管理、核销管理，可大幅降低企业应用开发门槛规范管理营销费用，助力企业业绩增长。可用于生产制造的多个重要部门进行业务管理：重点厂商产品及服务能力分析蓝凌软件湖南省第五工程有限公司是老牌建筑施工企业，始建于1953年，隶属湖南建设投资集团有限责任公司，是以建筑施工为主业，集设计、科研、建筑工业化、投融资一体的省属国有企业。近年来多次入选“全国优秀施工企业”“中国建筑业竞争力200强企业”“全国施工总承包200强”、湖南“建筑强企”，获评株洲市“市长质量奖”等荣誉，保持行业高信用评级，市场竞争力稳居行业领先。项目效果业务痛点项目亮点客户背景介绍1.多业务系统难以融合：组织亟需建立信息化顶层设计，打破“集息孤岛”和“数据烟囱”进行端对端业务闭环；2.环境多端适配难度大：多端对客服务（包括大屏端、各类IOS、安卓端），需要保证工作稳定高效；3.各模块场景割裂：需要人力、成控、市场营销、工程管理等模块数据支撑管理层统一管理；4.生态覆盖能力弱：上下游供应链需要高效协同。搭建办公管理中心通过搭建了办公管理中心，蓝凌协助客户实现集团本部、分公司、项目部三级管理联动，高效协同、政令畅通。平台提供表单自定义、流程自定义、业务办理通知、前置预警和监控预警等功能；形成工程项目运营中心公司各管理层级能实时了解项目各项经济指标数据，同时也提供过程追溯。通过平台，实时统计、动态跟踪项目成本费用，并依据市场行情动态预测得出当前利润和预估项目结项后收益，项目管理工作由结果分析向过程管控转变。公司管理也与平台建设同步改革，建立了诸多会管又会算的优秀项目团队，确保项目顺利交付并获得预期盈利；建立项目及时结算机制并日趋完善平台实现业财互通，项目自动核算和资金集中管理等功能，项目资金流水往来清晰，有效避免各方事后分歧甚至法律纠纷，项目合同、发票、资金流水均有据可查。有效降低以往统筹安排资金、税务，项目资金等工作成本。以数据流程为纽带，对各种管理要素和管理体系进行全方面的梳理及整合，让管理者理清楚完整的管理思路，让员工明确地知道“什么是正确的做事方式”实现流程的有效落地，使得管理体系有效地运行起来。同时，通过流程治理体系的建立，建立长效管理机制，确保企业的员工“按正确的方式做事”。“理清楚”“管起来”蓝凌低代码，搭建全生命周期流程管理&整合平台，复杂业务，跨系统流转，拖拉拽完成业务搭建，一键发布到PC和手机端。支撑所有管理业务及活动“理清楚、管起来”，全面提升了项目精细化管理水平。重点厂商产品及服务能力分析炎黄盈动专业、自主、安全的AI低代码PaaS和智能BPM PaaS平台提供者炎黄盈动（北京炎黄盈动科技发展有限责任公司）2003年成立，长期专注于AI低代码PaaS和智能BPM PaaS平台的研发与服务。以BPM业务流程切入PaaS服务领域，目前已具备包括AI低/无代码、智能流程、集成、移动、业务规则在内的多项PaaS能力。全栈信创适配，可为用户提供安全自主可控的国产一体化平台，支撑和探索数字化转型不同发展级别的能力要求，加速数字化转型和运营创新。标杆用户覆盖军工、金融、政府、教育、制造、能源、汽车、工程建筑、零售、医疗等16个主要行业，服务过中国航天，国家能源集团，江苏银行，大众汽车，国药器械，京东方集团，古井贡酒等知名国内企业。产品优势AI低/无代码能力赋能应用构建：可快速构建场景化应用，不断降低构建成本，不断提高构建效率和灵活度，从而能够持续、深度扩展数字化应用边界。降低应用构建门槛，开发快、上线快、调整快，门槛低、成本低、风险低，让组织掌握数字化转型更多主动权；智能BPM能力赋能流程驱动：数字化转型的流程大脑，BPMN2.0国际标准的建模和引擎技术，100%覆盖WCP 43种控制模式。自主研发的十种BPM技术打通流程挖掘、梳理、执行、分析、监控全过程，自动化应用和数据串联，加速推进业务集成融合；iPaaS集成能力赋能数据驱动：汇聚内外部数据和服务，不断降低数据集成门槛，可视化服务编排，让组织参与和探索数据驱动的业务创新方式。技术优势模式创新快速为生态伙伴赋能：微服务架构结合自主研发的微应用技术，提供开放云原生多租户PaaS服务，将低代码快速构建、流程驱动业务、数据驱动创新等核心能力开放给组织内外和上下游生态伙伴；全场景的数字化BPM能力：涵盖AWS PMI（流程挖掘洞察）与AWS PAL（流程资产库）、AWS BPA（业务流程分析）、AWS BAM（业务活动监控）全家桶方案，实现了以数据驱动的业务流程全链路闭环，是首个通过中国信通院数字化业务流程管理能力要求的企业；国内首批落地AI低代码的厂商：通过AI Copilot提供自然语言的对话交互方式，生成更贴合用户需求的数字化应用；核心技术自主研发，安全可控：元数据应用容器获得国家发明专利，产品已全栈适配国产 CPU、操作系统、数据库、中间件、云服务等近百家主流软硬件生态环境。aPaaSBpmPaaSiPaaSPaaS 打造数字化转型的技术底座，通过“平台 应用 解决方案”的方式，全方位满足不同用户的数字化转型需求满足企业5-10年的数字化转型需求的数字化PaaS底座-炎黄盈动提供开放共享的商业模式：通过共享一个PaaS平台能力，整合伙伴各自专业分工特长，迅速推出有竞争力的产品和服务，共创客户价值，共享商业成功。重点厂商产品及服务能力分析炎黄盈动江苏银行是全国19家系统重要性银行之一、江苏省内最大法人银行，总部位于江苏南京。截至2022年末，营业网点520余家，员工1.5万余人，资产总额达2.98万亿元。服务网络辐射长三角、珠三角、环渤海三大经济圈，实现了江苏省内县域全覆盖。项目效果业务需求项目亮点客户背景介绍1.根据整体规划，为及时响应业务快速发展需求，需筹建敏态统一开发平台；2.低代码和流程均为统一开发平台的建设重点，同时需要满足国产化适配需求；3.需要实现江苏银行本部及下属534家分支机构原有流程的打通和集中管理；4.借助信创统一开发平台构建公共组件，打造统一交互风格，提升全行应用的使用体验。共享一个PaaS平台能力微服务架构结合自主研发的微应用技术，通过开放云原生多租户PaaS服务，将低代码快速构建、流程驱动业务、数据驱动创新等核心能力开放给江苏银行本部及下属分支机构，提升江苏银行IT架构敏捷性，树立城商行科技领先地位。低/无代码赋能应用构建于AWS PaaS强大的扩展能力，封装多种公共业务组件，完全融合行内开发框架，包括表单统一风格、角色组件、影像平台组件、推送待办中心组件、预览组件、组织同步组件、职务同步组件、日志监控组件等。智能BPM赋能流程驱动四周完成行内包括AMIS系统、采购系统、托管系统、投资管理平台、信用卡审批、定价系统、信管系统、comstart系统、事务审批、结存系统等40支核心流程的打通，实现业务流程的闭环管理。全栈国产化信创适配AWS PaaS平台具备信创适配基础，快速完成了从服务器、中间件、数据库到上层应用的全面替代和构建。打造了未来5-10年开发底座，构建安全、可靠、稳定、开放的信创开发平台。奠定江苏银行敏态IT架构在城商行中的领先地位，满足江苏银行行内架构标准，有效提高统一技术支持力度。敏捷创新能力大幅提升，投产周期缩至以周为单位，赋能业务系统，避免反复造轮子。替换了行内现有流程平台和陈旧技术架构的业务系统，借助低代码快速构建应用，业务随需而变。统一构建行内移动端UI，统一标准，交互体验明显提高，提高用户满意度。目 录Part 01审视：简单概念之下的深刻内涵Part 02突围：时代飞速发展下的惊涛骇浪Part 04实践：智能时代下围绕业务的探索Part 05展望：低/无代码时代的人才需求Part 03价值：来源于技术，忠于业务实现随着低代码/无代码市场的成熟，技术与业务的复合型创新人才将更为需要复合型创新人才的发展是市场关注的焦点，以博世的全球人才标准为例，员工的数字化能力可分为技术胜任力和跨职能胜任力，复合型人才需要能力交叉。低代码/无代码产品将进一步降低技术学习的门槛，也将进一步提供技术与业务融合的手段、工具及机会，企业的数字化转型也更需要复合型的人才。数据技术人工智能系统工程云计算技术胜任力软件工程信息技术安全敏捷用户体验创新/设计思维变革管理与理念变革领导力建立关系及合作商业模式数字化媒体跨职能胜任力图 人才的数字化能力模型复合型人才的能力交叉数据来源：博世，公开资料，甲子光年整理职位、行业及业务全链路的跨领域人才也将成为市场的关注点知识宽度专业能力专业能力通用能力专业能力专业能力专业能力专业能力专业能力专业能力知识深度知识深度通用能力通用能力“I型”人才“T型”人才“型”人才“梳型”人才随着市场创新性需求的增加，人才的能力结构需要更加丰富，单方向的人才在知识宽度及深度方向略显不足。尽管企业对复合型人才的紧缺有着普遍的不安，但是不同企业之间、不同背景的人才之间的交流，轮岗以及跨领域的行动学习，加上智能技术的支持，都会有助于复合性人才的快速培养。图 复合型人才的结构示意图数据来源：公开资料，甲子光年整理低代码/无代码可帮助组织逐步实现“共享模式”的管理模式CEO其他职能负责人IT规划仅由IT部门主导其他部门之间相互独立运营用户体验人力运营安全运维IT部门财务关注实现技术现代化，减少技术债务CEO其他职能负责人各部门领导驱动和引领数字化目标的推进和达成运营用户体验人力运营安全运维IT部门财务相关领导参与企业决策制定，在董事会获得席位孤岛模式集中模式财务运营IT部门安全运维人力用户体验业务部门智库信息安全管理小组创新部门ESG小组数字化办公供应链产品部门数字化体验CEO共享模式完成可持续发展和目标驱动的增长CEO积极倡导数字化优先战略的制定，长期推进企业创新，IT部门共同参与提升企业敏捷性，思考企业的发展方向和增长目标，链接企业部门图 企业数字化管理的最终目标，打造数字化管理的梦之队，实现业务及人才的融合数据来源：公开资料，甲子光年整理20232023甲子光年低代码/无代码推荐厂商用友网络科技股份有限公司金蝶软件（中国）有限公司北京致远互联软件股份有限公司蓝凌软件股份有限公司杭州网易数帆科技有限公司北京百特云享科技有限公司浪潮通用软件有限公司南京数睿数据科技有限公司深圳奥哲网络科技有限公司北京炎黄盈动科技发展有限责任公司上海易校信息科技有限公司广州市云动力科技有限公司*以上排名不分先后智库院长宋涛微信stgg_6406分析师刘瑶微信北京甲子光年科技服务有限公司是一家科技智库，包含智库、媒体、社群、企业服务版块，立足于中国科技创新前沿阵地，动态跟踪头部科技企业发展和传统产业技术升级案例，致力于推动人工智能、大数据、物联网、云计算、AR/VR交互技术、信息安全、金融科技、大健康等科技创新在产业之中的应用与落地扫码联系商务合作关注甲子光年公众号商业合作负责人李胜驰（手机&微信）

0人已浏览 2023-12-11 47页 5星级

技术白皮书 V1.02023 年对于小米而言，是开启全新发展周期的一年，也是一系列的深刻变革进入深水区之时。集团正处于一个全新殿堂的门槛上，全新阶段的起跑线上。这一年我们的关键词是“稳健推进，蓄势待发”，这一年里，我们要不断夯实基础、构建强化体系能力，为未来5-10 年的长期发展打下坚实基础，并为未来 2-3 年的新一轮爆发做好充分的准备。（雷军 2023/01/30）从小米创办之初，我们就开始研发 MIUI。可能不少朋友并不了解，MIUI 不只是基于安卓原生系统交互层改进，而是早已深入系统底层的 Linux 内核，在系统框架、性能调度、内核能力做了大量的底层“魔改”。比如在2013 年，我们推出了进程对齐唤醒机制，领先安卓半年，为保护用户隐私推出的运行时权限管理，更是领先了安卓近三年。随着 IoT 业务率先启动，小米对嵌入式系统的研发也越发深入。为了解决 IoT 网络中设备系统的碎片化和连接隔阂，2014 年，小米就发布了 IoT 设备的连接协议。2017 年，小米自研的 Vela OS 正式发布。为了弹性适应各类智能硬件产品，Vela OS 做到了可伸缩、可裁切，支持从简单到复杂的各类设备，开始逐步统一 IoT 设备生态，目前已经装机量已达 2000 万台以上。2016 年，小米就开始研发跨端应用框架。2019 年，我们开始并行研发纯自研通用系统Mina OS，并在部分产品上小规模量产验证，同时在实验室中也成功在手机上跑通，其中部分技术成果也已融入小米澎湃 OS。2021 年，小米开启了车机 OS 的研发。2022 年初，我们决定统一 MIUI、Vela、Mina、车机 OS 四个系统的软件架构。自此，小米的操作系统底层合并完成。超过 5000 人研发团队，又经过两年打磨，小米澎湃 OS 应运而生，人车家全生态由此开启。（雷军 2023/10/23）序言小米操作系统大事记2010 年 MIUI 诞生2014 年 统一的 IoT 设备连接协议、通用 IoT 模组发布2016 年 跨端快应用框架启用2017 年 自研 Vela OS，逐步统一 IoT 设备系统2019 年 预研 Mina OS；自研微内核安全系统启动2020 年 跨端互联互通协议融合2021 年 统一技术架构设计；小米汽车 OS 启动2022 年 统一软件架构，系统研发并线完成序言在全球技术进步与数字化转型的驱动下，我们正在见证一个技术领域内的巨大变革。随着互联网技术的普及，物联网设备的广泛应用以及大数据与 AI 的结合，人类的生活和工作方式正发生着翻天覆地的变化。这不仅仅是一场关于技术的革命，它还在社会、经济和文化等多个领域带来了深刻的影响。在这样的背景下，传统的、基于单一设备的计算模式显得过于陈旧，难以适应日益复杂的技术需求。现代社会的技术环境已经超越了单一设备，形成了一个由人、机器和各种物体组成的互动网络。在这种环境中，我们需要一个全新的、更为先进和全面的操作系统来进行管理。于是，小米澎湃 OS 应运而生。它不仅要满足不同设备间的连接与管理需求，还要保证系统交互的流畅性、易用性和安全性。小米澎湃 OS 可以搭载在手机、汽车、智能家居等200 多个品类上，最终构建人车家一体的全生态平台。同时，随着 AI 技术的逐步成熟，它正在改变软件的传统角色。软件不再只是一套指令，而是成为了支持和驱动各种创新应用的基础。因此，软件开发和管理的方法也需要随之变革，以适应这个新的技术环境。面对这一系列的挑战，小米集团站在了最前端，决心为社会提供最前沿的技术解决方案。小米软件团队在技术研究上投入了大量的资源，他们的研究范围涵盖了从系统内核、系统服务、跨端互融、开发生态的各个方面。在这个既充满机遇又充满挑战的技术趋势下，我们需要不断地创新和进步。而小米澎湃OS 无疑是小米在这个万物互联的时代，为用户和开发者提供的一份最优质的答案。序言背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem5我们正式公布了小米澎湃 OS 完整系统架构。这个架构图背后，凝聚着小米创业 13 年来，数千名工程师研发探索的心血。从 2010 年MIUI 诞生起，小米在 OS 方面的研发探索，覆盖了手机操作系统、嵌入式操作系统、纯自研通用操作系统、车机系统等全部领域，最终在小米澎湃 OS 上并线合流，如今拥有一支 5000 多名工程师的操作系统研发团队。可以说，小米的创业史，就是一段操作系统研发的探索史。小米澎湃 OS 是一个超级庞大的工程体系。从架构设计之初，我们就明确了四个目标：第一，实现单端性能表现最强；第二，AI 赋能，成为整个生态的“智能大脑”，能够为用户提供主动服务；第三，更加便捷高效的连接；第四，实现全端隐私安全坚固防护。在最底层的系统内核层，我们将自研的 Vela 系统内核与深度修改的 Linux 系统内核进行融合，重构了性能调度、任务管理、内存管理、文件管理等各个基础模块，实现了性能、效率的大幅提升。这一全新的融合内核，支持 200 多个处理器平台、20 多种文件系统，还能根据硬件能力差异灵活配置，具有很好的兼容性，使得每个独立设备的性能都能得到彻底解放。在系统内核层之上的服务与框架层，我们将安卓的服务框架和自研 Vela 系统的服务框架，都作为“中间件”纳入其中；同时，全新打造了 8 大子系统，其中全新的 AI 子系统融合大模型能力，成为整个系统的“智能大脑”，不仅可以让单设备实现极强的端侧 AI 能力，同时赋予整个生态智能能力。最上层 HyperConnect 跨端层，则是彻底打破了硬件设备的隔阂，让所有设备可以统一连接协议，并且实时通信。让整个小米澎湃 OS 生态打通“任督二脉”，每个设备如同感知世界的触角，像一张巨大的网一样连接一起，最终构建人车家全生态的智能世界。特别值得一提的是，这次我们打造了贯穿内核层、服务框架层、跨端层的全端安全系统，尤其是内核层，我们启用了完全独立的自研微内核安全系统，保障了安全从最底层实现。（雷军 2023/10/23）2 技术架构2.1技术架构简介背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem6小米澎湃 OS 是一个为下一代的计算与多种设备生态设计的系统。主要针对以下关键挑战提供了解决方案：设备多样性 在当前的数字世界中，各种操作系统和技术标准使设备高度分散。小米澎湃 OS旨在提供一个一致性的平台，使从手机到 IoT 设备的所有设备能更好地统一与集成。设备间的交互 大多数传统操作系统并未为多设备互动进行设计。而小米澎湃 OS 注重设备间的流畅交互，以确保高效的跨设备合作。开发流程的简化 通过小米澎湃 OS，开发者能为不同设备编写统一的代码，消除了开发跨设备应用的复杂性。增强安全保障 小米澎湃 OS 打造高安全的 TEE OS（EAL 5 ）和其他安全特性，以减少潜在风险并提高系统整体的安全水平。高效的性能调配 小米澎湃 OS 在设计时就已考虑到各类设备的性能和资源需求，尤其是在资源有限的场景中。鼓励生态发展 为了吸引更多的开发者参与并促进生态的建设，小米澎湃 OS 的核心组件选择了开源的道路。小米澎湃 OS 针对设备的多样性、设备间的交互、开发流程、系统安全、性能调配和生态发展等挑战提供了综合的解决方案。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem72.2技术架构图2.3核心组件内核层 Linux 内核：融合内核的标准化组件集，适用重载硬件资源的抽象与管理。Vela 内核：融合内核的轻量化组件集，适用轻量硬件资源的抽象与管理。系统服务层：资源调度子系统：负责合理、高效地分配和管理系统资源，以确保应用和任务能够流畅运行。网络子系统：旨在支持多设备、分布式、安全和高性能的网络通信，以满足不同设备和应用场景的通信需求。图 2.2-1 小米澎湃 OS 技术架构背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem8 多媒体子系统：提供了处理多媒体内容（如音频、视频和图像）以及与多媒体硬件交互的功能和服务。图形子系统：负责管理和控制图形显示以及用户界面（UI）渲染，高性能和响应性的用户界面。硬件服务子系统：负责管理和控制硬件资源以及提供硬件访问和互动的功能和服务，提供一致的硬件访问接口。AI 子系统：集成人工智能（AI）和机器学习（ML）技术，以提供更丰富、更智能、更个性化的体验。安全子系统：满足不同设备和应用场景的安全需求而设计，提供全面的安全性和隐私保护，确保用户设备和数据的安全。编译器与运行时：提供跨设备统一的编译器与运行时，确保应用的运行性能，同时保障跨端运行的安全性。跨端层：分布式子系统：支持多设备之间的协同工作和数据共享，以提供无缝的分布式计算和体验，从而提高用户体验和便利性。跨端服务框架子系统：为应用程序提供一套丰富的服务和工具，以增强应用程序的功能和性能，提供了一个多元化的应用程序服务平台。跨端公共能力子系统：提供了标准化的开发工具和库，以支持开发者构建各种应用程序和服务，有助于提高应用程序的可移植性和一致性，使开发者能够更轻松地开发和维护跨平台的应用程序。跨端应用框架子系统：提供一种轻量级的应用程序模型，旨在提供更快、更流畅的应用体验，并减少了应用程序的安装和占用存储空间的需求。跨端安全子系统：专注于提供安全性和隐私保护，以确保跨不同端设备之间的通信和数据共享的安全性。开发者服务：开发平台：开发平台是一套工具和资源，旨在帮助开发者创建应用程序和服务，以运行在小米澎湃 OS 操作系统上。分发体系：小米澎湃 OS 的分发体系是一个多层次的策略，旨在将该操作系统部署到各种不同类型的设备上，提供多样性的应用程序和服务，以满足不同市场和用户需求。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem9分布式子系统是通过近场通信的跨设备互联协议，在跨平台基础互联的基础上构建跨端分布式服务框架。通过核心服务的分布式能力实现应用生态融合，影音互联，文件系统，硬件协同，硬件控制等领域的纵向和横向扩展，并且为上层应用提供基础的安全通信和同账号系统服务，助力跨设备功能的持续演进。3 跨端层(HyperConnect)3.1 分布式子系统3.1.1子系统简介3.1.2子系统架构互联开放框架跨设备应用接力跨设备桌面跨设备通知生态融合视频流转音频流传耳机跨设备体验影音互联文件互传跨设备文件跨设备剪贴板文件系统摄像头协同电话协同网络协同硬件协同设备控制设备信息同步设备中心设备控制分布式任务调度分布式服务分布式核心服务分布式硬件分布式数据分布式安全分布式文件跨设备互联总线统一设备管理框架传输管理广播发现融合连接协议自组网基础连接一对多消息IoT-LinkMiWear 安全连接手机硬件设备设备层平板手表手环电脑图 3.1-1 分布式子系统架构音箱IoT 设备车机电视背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem10技术介绍跨设备总线提供面向多设备互联、跨平台、面向异构网络的广播、发现、连接、传输能力。广播：提供统一的广播发送功能，支持自定义广播，协议兼容。发现：提供统一的、可复用的发现功能。连接：提供统一的基于服务驱动的经典蓝牙，低功耗蓝牙，局域网，点对点等连接通信能力，支持多端连接、通道复用。传输：提供面向服务的信息交换传输通道。技术架构3.1.3重点特性3.1.3.1跨设备总线 图 3.1-2 跨设备软总线 SDK跨设备软总线 SDK发现连接传输组网一对多设备管理自组网广播与发现数据分发流媒体传输决策中心数据传输链路链接与认证安全管理畅快连OTU/蓝牙MeshMiWear多平台通信协议抽象层背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem111.广播基本信息2.交换设备和服务信息1.广播基本信息2.交换设备和服务信息关键技术1.智能自组网 自组网可实现周边设备和服务的自动感知、同步，实现安全认证和加密传输，简化业务开发难度，提高接入效率。提供多端统一开发模式,极大的简化接入业务的复杂度，并降低了系统的开销。优势：低功耗、动态的发现策略；服务发现到设备发现；虚实连接结合的组网管理。快速发现，稳定连接，跨设备可信互联图 3.1-3 智能自组网图 3.1-4 异构组网无感连接自动感知同账号设备预知灭屏设备感知智能自调节发现自适应算法多路径融合算法组网拓扑自维护组网信息自维护算法无连接组网应用按需拉起智能最佳通道选择按需拉起应用，去常驻异构组网无感连接设备 A设备 B设备 C服务信息服务信息服务信息背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem12 设备靠近自感知 采用多种融合技术，包括 BLE、局域网广播、局域网组网等机制，快速发现周边可信设备。组网策略自调节 感觉环境事件、用户事件动态调节自感知技术的参数，使得功耗、性能均衡，无需业务感知就能实现快速的组网。拓扑与信息自维护自适应 自动维护设备的拓扑关系、设备的能力信息、以及设备的环境信息，并以极低的开销实现资源的快速同步。运行时机自调度 基于自组网的业务，可定义业务激活条件，条件满足后，才拉起激活业务，避免业务必须常驻才能实现业务。多链路动态复用 结合多种通信技术，决策最优媒介类型，快速建立链接，提升互联体验。2.一对多消息分发协议 一对多消息分发机制支持应用自定义的 Topic 主题进行消息订阅和发布，根据应用发布的数据大小自动选择链路并自动完成连接和传输的过程，为应用提供安全、快速、稳定的传输通道。关键功能点：图 3.1-5 多设备分发架构业务 1业务 2业务 3业务 1业务 2业务 3数据聚合数据分发.WiFi-P2P智能选择WLANBLE多设备分发发送端接收端背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem13 智能决策 根据设备间组网的状态、设备数量、设备状态、网络状态、消息的大小自选择合适的链路送达对端设备。稳定可靠 消息支持按需获取全量数据，消息送达时，可保障消息的事件能快速达到，并按需获取全量消息。通道复用 多个消息，可合并为单一消息，提高复用度。安全加密 通过广播、连接等方式的数据，均通过加密方式送达，确保信息的安全。灵活便捷 可支持所有同账号设备、指定设备、指定组网类型等多种方式送达消息。技术介绍在跨端安全隐私的基础上，实现数据、文件、流媒体跨设备迁移，同时支持硬件的跨设备组合使用。技术架构3.1.3.2服务框架图 3.1-6 分布式服务框架设备 A互联互通API分布式硬件分布式安全分布式调度分布式文件跨设备互联总线设备 B设备 N分布式数据应用互联互通API应用互联互通API应用分布式核心服务背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem14关键技术1.分布式硬件 分布式硬件实现跨设备的资源融合和访问。针对不同应用场景，为用户匹配并选择能力合适的执行硬件，使应用无感在不同设备间流转，充分发挥不同设备的能力优势。分布式硬件是多端协同交互体验的关键技术。图 3.1-7 分布式硬件分布式硬件典型场景：跨设备相机笔记本上的软件使用手机相机，操作简单且无需适配笔记本手机跨设备互联总线视频通话类软件相机硬件硬件管理硬件管理跨端硬件管理服务本地硬件管理服务跨端硬件管理服务本地硬件管理服务背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem152.分布式数据 分布式数据基于跨设备互联软总线，实现系统和应用程序数据以及用户数据的分布式管理。支持跨设备相互同步用户数据，使多种终端设备上数据访问体验保持一致。通过调用分布式数据接口，应用可以将数据保存到分布式数据库中。图 3.1-8 分布式数据分布式数据典型场景：跨设备剪切板三方软件无需适配，实现跨设备、跨系统、跨应用复制粘贴手机笔记本跨设备互联总线手机相册文本编辑类软件分布式数据管理分布式数据管理跨端数据管理服务本地数据管理服务跨端数据管理服务本地数据管理服务背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem163.分布式安全 分布式安全确保跨端可信服务，保证设备本身是合法的设备，防止被劫持，被root和破解，通过跨端权限子系统保证用户设备的安全和隐私安全，给用户进行敏感权限提醒，以及跨端行为记录追溯历史。图 3.1-9 分布式安全分布式安全基于多维度安全机制，构建互联互通安全底座手机笔记本跨设备互联总线跨端电话接听录音权限分布式安全管理分布式安全管理本地安全管理服务跨端安全管理服务本地安全管理服务通话权限联网权限申请权限获得权限跨端安全管理服务服务权限验证设备可信验证服务权限验证设备可信验证背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem17图 3.1-10 分布式文件4.分布式文件 分布式文件为用户设备中的应用程序提供多设备之间的文件共享能力，支持相同帐号下同一应用文件的跨设备访问，应用程序可以不感知文件所在的存储设备，在多个设备间获取文件。分布式文件典型场景：跨设备文件互传三方软件无需适配，实现跨设备、跨系统、跨应用的文件传输手机笔记本跨设备互联总线手机文件笔记本文件分布式文件管理分布式文件管理跨端文件管理服务本地文件管理服务跨端文件管理服务本地文件管理服务背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem18技术介绍提供能力完备、高效低门槛的互联接入方案。面向互联服务开发、应用接力开发、硬件协同开发等不同层次开发者开放。技术架构3.1.3.3跨设备应用开发框架图 3.1-11 跨设备应用开发框架基础连接框架 API应用接力框架 API影音互联框架 API硬件协同框架 API互联开放框架BT/BLEWiFiNFCUWB多设备异构系统应用背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem19关键技术1.基础连接框架 基础连接框架 API 包括组网发现、数据传输、消息分发。图 3.1-12 基础链接框架 API图 3.1-13 消息分发 组网发现 可提供设备发现、设备变更、服务上线、服务下线，组网类型变更等多种发现功能。发布者发布服务，自组网完成服务同步，观察者即可收到服务通知。支持静态注册方式，当满足条件时，自动拉起服务。数据传输 归一化蓝牙、WLAN、WiFi-P2P 等不同通道创建的差异，提供一致性、极简接入。接收端指定服务名称，发送指定设备 ID 和服务名称，即可创建多种类型的通道，实现发送消息、文件等多种传输能力。数据传输支持静态注册方式，可在触发接收时，自动拉起服务。消息分发 接收者指定 Topic 订阅内容，发布者指定 Topic 发布内容，自组网内所有订阅该Topic 的接收者均能收到消息。消息分发支持静态订阅方式，可在收到消息时，自动拉起服务。基础连接框架 API完成跨设备间快速通信，提供组网发现、数据传输、消息分发等系统能力发布者Topic订阅者订阅者订阅者背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem202.应用接力框架 向系统注册接力服务后，在用户触发应用接力后，自动迁移。将在迁移发起端存储数据，接收端恢复数据，类似本地应用前后台切换一样便利。图 3.1-14 应用接力框架 API3.影音互联框架 基于小米跨设备影音互联框架打造，拥有极致互联性能。支持全系小米核心设备，包括手机、平板、笔记本、电视、音箱。支持全系主流音视频协议，包括 MiPlay、Miracast、DLNA。支持控制中心操控体验，同时支持应用内集成系统播控交互。在视频场景调用影音互联 API 弹出设备列表，即可完成互联迁移。应用接力框架 API提供跨设备的应用接力能力，可提供跨设备间快速、稳定的应用接力体验图 3.1-15 影音互联框架 API影音互联框架 API提供跨设备的影音流转和控制能力，使用附近的大屏幕或扬声器，获得更好的影音体验背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem213.2跨端服务框架子系统3.2.1子系统简介跨端服务框架子系统定位于 OS 以上，基于系统基础能力与接口，以 SDK 或者接口的方式为上层应用提供统一的服务能力。这些服务具有专业的领域知识，如应用服务提供OCR/天气等能力，媒体服务提供抽帧/编辑能力等。从行业整体技术发展来看：服务组件是每个 OS 体系中必不可少的一个层级。行业参与者均在服务组件层面不断升级更新，旨在助力 OS 生态大力发展。4.硬件协同硬件协同框架 API提供跨设备的硬件虚拟化能力，用用使用附近设备的硬件能力，就像本地调用一样简单图 3.1-16 硬件协同框架 API 远端硬件资源本地化，像访问本地硬件一样访问附近设备的硬件能力。获取服务时，指定设备 ID，即可获取远端指定设备的本地化服务代理。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem223.2.2子系统架构系统应用应用层三方应用桌面相册主题壁纸系统工具社交游戏视频.KITS服务框架层应用服务框架多媒体服务框架UI服务框架互联服务框架AI服务框架安全服务框架图形计算框架系统服务框架Core 框架系统层OS图 3.2-1 跨端服务框架子系统架构3.2.3重点特性3.2.3.1应用服务框架技术介绍应用服务组件目标是为开发者的应用提供天气、OCR 及交互、高质录屏等一致的系统服务。应用服务组件位于开发者应用与操作系统之间，为应用开发提供基础服务能力。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem23关键技术 应用服务组件平台采用动态加载方案，支持组件管理器下载安装、组件版本管理和组件服务管理等功能。天气服务组件提供城市天气和城市信息查询能力。录屏服务组件提供高质量系统内声音和屏幕录制能力。OCR 服务组件提供便捷的图片文字识别和交互能力。图片搜索组件提供图片名称、类型、文字识别等图片关键信息搜索能力。技术架构系统应用应用层三方应用桌面相册主题壁纸系统工具社交游戏视频.KITS应用服务 KIT高质录屏OCR及交互天气服务语音控制图片搜索.Platform系统层OS图 3.2-2 应用服务框架技术架构管理平台更新平台鉴权平台.背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem243.2.3.2高性能视频播放服务技术介绍高性能视频播放服务提供能力丰富、性能强悍的音视频播放服务，助力业务快速集成并定制自己的播放器，为用户提供优秀的视频媒体体验。技术架构关键技术1.快慢速播放：支持小米相机拍摄的慢动作视频的播放、编辑和配乐。2.逐帧播放：支持对视频进行逐帧播放，满足快速浏览视频内容的需求。3.短视频点播：性能强劲的短视频播放能力，可快速响应视频切换。4.全景视频：功能完备的全景视频播放能力，可通过传感器和屏幕触摸控制播放视角。技术架构应用层相册小米视频电视 OTT文件管理器主题壁纸Audio多媒体 KIT语音转文字多路录音MediaResourceManager系统层OS图 3.2-3 高性能视频播放服务技术架构SDK/API音频播放控制/倍速HDR滤镜视频点播快慢速播放短视频播放逐帧播放数字授权图像处理全景视频VideoOther背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem253.2.3.3响应式 UI 组件技术介绍为上层系统应用提供自适应的容器、布局、控件，支持一套代码自动适配不同各种不同小米设备（手机，平板，折叠屏）。技术架构关键技术1.屏幕密度参数优化：自动调整应用屏幕密度参数，适配不同分辨率。2.自适应规则优化：根据不同设备/窗口类型，自动调整页面容器排版，控件形态变化。3.控件内容规则优化：根据不同的文本内容，自动调整控件形态。应用层桌面相册主题壁纸系统工具短信UI组件层Core 框架系统层OS图 3.2-4 响应式 UI 组件技术架构系统应用联系人其他普通控件普通布局普通容器自适应控件自适应布局自适应容器动态 DPI 框架响应式规则框架背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem263.2.3.4互联服务框架技术介绍通过近场通信的跨设备互联私有协议，实现跨平台的基础互联，进而支撑跨端分布式架构系统。在跨设备互联总线的基础上，传输实现快速互联、安全统一的架构体系，并为上层应用提供基础的安全通信和同账号系统服务，实现更全面的分级覆盖策略和协同升级能力、跨端无缝连接体验，以及持续连续演进的跨设备功能。使应用生态融合，影音互联，文件系统，硬件协同，硬件控制方向继续大力扩展。技术架构关键技术1.高性能基础连接：为跨端业务提供高性能的设备发现、连接、传输、组网和消息分发机制，构建便捷高效的跨端通信底座。2.硬件虚拟化服务：实现资源全面虚拟化，达到跨端资源共享与融合，极简接入，丰富跨端业务场景。应用层跨设备应用接力互联服务 KIT互联服务框架图 3.2-5 互联服务框架技术架构生态融合基础链接 KIT影音互联 KIT跨设备桌面跨设备通知视频流转影音互联音频流转耳机跨设备体验文件互传文件系统跨设备文件跨设备剪贴板摄像头协同硬件协同电话协同网络协同应用接力 KIT硬件接力 KIT流转服务时间通知服务多媒体服务硬件虚拟化服务背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem273.2.3.5AI 服务框架技术介绍AI 服务框架是包含大模型能力在内的系统 AI 能力集中管理框架，并且提供智慧能力服务。框架内部采用模块化设计，使得 AI 能力提供方能够灵活地接入，同时为 AI 能力需求方提供统一、可靠、高效、丰富的 API 接口，同时也提供了智慧能力的系统服务，助力应用程序实现 AI 相关的复杂功能。技术架构关键技术1.XiaomiHyperMind：全设备思考中枢，通过原子感知能力，学习人的习惯，让周边设备基于习惯来运作和协同。2.大模型：整合了视觉大模型和语言大模型，能够将用户输入的图片、视频、文字等信息进行精细化理解和整合。3.运行框架：提供了模型加载、推理、优化、并行处理等关键功能。保障模型运行的高性能和效率，同时支持模型的灵活更新，使得 AI 服务框架能够不断适应新的 AI 技术。应用层小爱同学相册图库米家融合设备中心MIAI 引擎AISDK/API系统层OS图 3.2-6 AI 服务框架技术架构其他系统应用其他三方应用图像处理语音处理人脸人体自然语言处理能力中心语言大模型视觉大模型大模型HyperMind小爱建议智慧切卡应用推荐智慧中心背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem283.2.3.6安全服务框架技术介绍安全服务框架的目的是为应用提供系统级安全开放能力。为开发者提供了设备可信服务、恶意应用检测和虚假点击检测三方面的功能。技术架构关键技术1.设备可信服务：在 TEE 中动态获取系统完整性数据，加密后的数据通过安全服务框架提供给应用。2.恶意应用检测：系统侧动态检测系统中是否存在恶意应用。3.虚假点击检测：系统侧根据点击事件输入结合当前系统状态检测是否发生虚假点击。应用层应用商店小米金融小米商城小米视频安全服务框架SDK/API系统层OS图 3.2-7 安全服务框架技术架构系统应用普通控件普通布局普通容器自适应控件鉴权三方应用金融电商安全.背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem293.2.3.7图形计算框架技术介绍图像计算框架基于 GPU/CPU 提供能力丰富、性能强悍的图形图像处理能力，帮助应用低成本集成相关技术，提升产品业务体验。关键技术1.超分技术：基于不同硬件平台，通过使用各种算法和深度学习模型，提高图像的质量，使其更清晰、更详细。2.图形引擎：面向应用提供的一款高性能、低功耗、轻量级渲染引擎服务。3.2.3.8系统服务框架技术介绍系统服务框架为应用提供高阶系统能力，比如马达振动、网络增强、信号增强等能力。关键技术1.马达振动：支持应用自定义振动类型和频率，打造体验更好的振动用户体验。3.3跨端公共能力子系统3.3.1子系统简介跨端公共能力子系统定义跨端兼容接口层，并提供跨端公共组件开发套件，让系统开发者可以使用 C/C /Rust 等语言开发高性能的系统原生程序或库，可在标准系统与轻量系统共用，以实现标准系统和轻量系统一致的公共能力。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem303.3.2子系统架构3.3.3重点特性3.3.3.1跨端兼容接口层技术介绍跨端兼容接口层致力于在高度约束的环境中维护一组标准内核与轻量内核的兼容性接口层，这一兼容性接口层是指内核空间到用户空间的接口层，其目的是让用户空间的程序或库可以在限定的条件下，无需关心底层的标准内核或轻量内核差异，使用统一的系统调用，无需针对特定的内核进行修改或重新编写。技术架构图 3.3-1 跨端公共能力子系统技术架构服务与框架层小米云服务小米账号语音唤醒日志与事件跨端标准系统调用标准内核轻量内核跨端层.跨端原生开发套（NDK）公共能力跨端兼容接口C/C 源码跨端公共能力组件工具链Rust 源码工具链跨端原生开发套件（NDK）标准接口arch-armarch-arm64工具链公共基础库标准接口公共基础库图 3.3-2 跨端兼容接口层背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem31关键技术1.标准接口:标准接口是指一组头文件（header files），用于定义和声明在 C/C 代码中使用的函数、结构体、宏和常量等，不仅规范了标准系统调用（POSIX APIs），还包含了处理网络、图形、线程、内存管理、标准加解密等。2.公共基础库:公共基础库是指一组动态链接库、静态链接库，包含公共功能和算法标准实现，例如加解密、跨进程通信、序列化与反序列化等。开发人员可以在不同的程序中重复使用这些代码，不仅可以提高代码的复用性与一致性，还能够有效降低资源占用。支持多种 ABI（Application Binary Interface），每个 ABI 都有其特定的库文件。3.3.3.2账号技术介绍小米账号是用户用于访问所有小米服务和设备的统一身份标识，为用户提供账号身份验证服务。目前小米账号在中国大陆和海外多个地区本地部署，为全球小米用户提供符合当地隐私法规的服务，小米账号在手机、平板、笔记本、电视、有屏音箱等各种设备端提供身份能力与服务。技术架构云服务小米商城米家有品多看阅读应用层SDKSDKSDKSDKSDK.SDK页面交互扫码登录近场登录授权登录WebView自动登录.SSO服务Oauth服务Token 管理账号管理身份识别配置云控Cookie管理安全认证SIM 取号SNSJSB 框架FIDO/Webautn存储加密网络事件通知消息处理设备信息任务管理Keystore跨设备服务FIDO（TEE/TA）接口层子系统功能层系统层图 3.3-3 账号子系统背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem32关键技术1.用户身份和数据全面安全:以跨端兼容接口层为基础，保障用户在手机、平板、笔记本、电视、有屏音箱等各种设备端的帐号拥有一致的安全性，安全的使用账号认证信息注册和登录，登录过程中和存储到本地的账号数据也是安全的。使用跨端原生开发套件开发，深度使用底层能力，基于 TEE 环境中的私钥提供真实设备数据签名。实现了跨端统一的安全秘钥、安全存储、加密网络传输，网络模块加固，Token 生命周期管理等。2.灵活方便快捷的集成:基于不同业务场景提供多种 SDK 或 JSBridge 模块，并实现页面交互和多种登录方式，包括传统密码登录、取号短信登录、OAuth 授权登录、扫码登录、Webview 自动登录等。3.3.3.3云服务技术介绍云服务是多设备的个人数据中枢，主要功能围绕个人数据在多设备场景下的同步、备份、管理和分享等能力。云服务存储的是个人私有数据，安全的数据存储是基础能力，智能数据整理可以帮助用户更好的使用数据，共享协同能力方便用户更方便的分享数据。技术架构云同步有屏音箱电视桌面布局SettingsDeskLockWi-FiBrowserAPPDATA云备份云盘电纸书手表APPThemeSecurityCenterWeather.GalleryContactSMSNoteRecorderCallLogCalendar.HyperOS同步框架Push同步框架备份框架DocMoviePictureMusic.文件同步框架OpenSDKCloud Server数据传输安全端到端加密数据合并策略同步任务调度备份削峰应用兼容性适配应用数据备份流量管控错误透传文件传输优化SDK 分层隐私合规同步速度优化自研同步框架备份速度优化预装应用适配分块并发系统同步场景原生系统备份场景设置项备份场景应用数据云文件场景同步场景桌面备份场景图 3.3-4 云服务子系统背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem33关键技术1.端到端加密：E2EE（End-to-end encryption）是只有参与通讯的用户可以读取明文信息的通信系统，可防止窃听者(潜在窃听者包括电信供应商、互联网服务供应商以及该通讯系统的提供者)获取双方通信的明文，能为用户提供更高的数据安全性保护能力。2.全平台统一接入：以跨端兼容接口层为基础，实现跨端公共的 MiCloudKit 系统组件，集成云同步、云盘、云备份跨端统一，提供权限和访问控制、传输数据加密、数据同步、日历同步、便签同步、联系人同步等公共能力。3.3.3.4日志与系统事件技术介绍通过统一收集和记录系统组件在不同设备上的日志信息，开发者可以全面、有效的分析日志数据，识别潜在的问题，并进行故障排查。统一日志与系统事件系统可以提供运行时信息、错误日志、异常堆栈跟踪等，有助于快速定位和修复问题。并且可以根据预制的策略进行有效的自检、故障恢复、服务降级等。技术架构稳定性MiSightServer业务领域插件性能功耗通信.事件接收DFT 领域插件隐私管控流控&存储私有日志抓取压缩打包插件化管理平台流水日志抓取DFT消息通道事件订阅事件分发流水线管理插件管理加/卸载、调度配置管理公共能力（db/xml操作）图 3.3-5 日志与系统事件背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem343.4跨端应用框架子系统3.4.1子系统简介跨端应用框架子系统提供了面向具备跨端运行能力的轻量化应用的完整能力集合，开发者可以高效开发出运行在所有类型的澎湃 OS 终端设备上的工具应用、小部件、游戏等多种类型的应用程序。跨端应用是一种新型的应用形态，它结合了原生应用和 Web 应用二者的优点，能够让用户无需下载安装，还能流畅的体验应用内容，实现了“即点即用”的用户体验；同时跨端应用尺寸小巧，可以灵活地分发到各种终端设备上，并可在多个终端设备之间进行快速流转，让用户可以随时随地使用跨端应用。同时此子系统还提供了 IoT 框架，使采用米家 IoT 协议的设备能够轻松连接米家平台，实现与其他设备和云的互动。这包括多种基础通信协议和用于业务开发的功能模块。3.4.2子系统架构3.4.2.1整体架构跨端应用框架子系统整体框架如下图所示：关键技术跨端系统统一检测：以跨端兼容接口层为基础，实现跨端公共的日志与事件系统组件，统一标准系统与轻量系统的事件编码，支持各设备系统各层模块使用统一接口上报事件，实现了可跨端联合检测、观察、测试的事件设计。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem35图 3.4-1 跨端应用框架子系统架构应用层APPWidgetGame平台层ManagerSystemAdaptorPlatformServices内核层Linux/Velacore服务与框架层RouterPageFeatureComponent通用服务OTS/OTUAppRuntimeWidgetRuntimeGameRuntimeUIComponentJSEngineServiceHybridBridgeGameBridgeBaseAPIExtensionAPIOTPub/SubMIoTSpec协议适配层米家蓝牙协议栈消息总线快应用IoT跨端应用框架子系统的设计以“一次开发、多端运行”为目标，通过对底层设备能力的抽象和封装，尽可能屏蔽各类设备的能力差异，并构建出满足不同应用类型的跨设备运行时环境；并在上层将这些运行时环境集成起来，为开发者提供一个规范统一、能力丰富的开发框架，降低跨端应用的开发难度；此外，跨设备运行时环境会根据各类终端设备能力差异性进行针对性的优化，保证应用在多种终端设备上均能提供流畅的用户体验。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem363.4.2.2技术特点采用前端技术栈 原生渲染混合模式 前端技术栈-对前端开发者友好，充分发挥前端高效易学的优势，降低学习成本。原生渲染-克服浏览器的渲染性能劣势，提供流畅的应用体验。即点即用-继承网页应用的优势，避免过长的下载安装等待，快速触达用户。提供能力完整的跨设备、跨系统应用框架 丰富的基础框架能力-丰富的 UI 控件、系统能力及三方服务、可满足诸如购物、阅读、影音娱乐等应用开发诉求。高性能，优质体验-原生渲染技术，用户使用体验流畅。自适应不同设备屏幕-通过界面逻辑分离设计、弹性布局、媒体查询等技术手段，实现组件位置尺寸灵活自适应能力。提供高效动画渲染能力 高性能的物理动画引擎-采用逐帧实时计算的物理计算模型，可以更好地模拟真实世界中的物理效果。创新的动画状态管理-提供多属性动画、属性监测功能、基于物理特性的运动计算等多种管理机制。完善的动画编辑工具-专门为设计师或者运营人员打造，无需编程即能设计出美轮美奂的动画效果。支持多端分发部署 统一工程开发-一个工程即可支持多类型设备的应用开发，提升代码复用率，避免冗繁的工程项目维护工作。可组合的应用打包-将一个应用打成多个小文件包，按设备类型进行组合，支持按需下载。灵活的分发策略-一个应用对应一组应用包，按设备类型/型号进行匹配管理，为设备分发合适的应用包。支持多种应用形态 应用-即点即用，接近原生体验，提供丰富的 UI 组件和能力 API。小部件-轻量化桌面卡片，可与应用联动，提供强大、流畅的动画渲染能力。游戏-即点即玩，深度优化的游戏性能，支持国内主流游戏引擎，提供丰富的 Game API 和安全机制。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem373.4.3重点特性3.4.3.1跨端应用框架技术介绍应用模型应用模型是跨端应用的抽象表示，一个跨端应用由一个 App 和多个 Page 组成，Page 之间可以通过路由进行任意切换，页面栈负责维护 Page 之间的切换关系，遵循先进后出的原则；任何时刻只能显示一个 Page，即位于页面栈顶部的 Page。与应用模型相对应，一个跨端应用程序由一个配置文件和多个 ux 文件组成。配置文件用于定义应用基础信息、功能权限声明、系统配置和页面路由等数据；ux 文件则记录页面或组件的具体实现代码，包括 UI 模板、样式单、数据定义和回调事件处理等。MVVM 模式跨端应用框架采用主流的 MVVM 模式设计，MVVM 是 Model-View-ViewModel 的简写，本质上就是 MVC 模式的改进版本。MVVM 模式有助于将应用程序的业务逻辑与 UI 清晰分离，使应用程序更易于开发、测试和维护。在 MVVM 模式下，一个应用可以分为Model、View 和 ViewModel 三个部分，其中 Model 表示业务数据模型、View 表示用户图形界面，ViewModel 则是将二者的关联起来的桥梁，通过数据绑定机制将 Model 的数据转化成 View 所呈现的用户图形界面，通过事件监听回调将 View 上产生的交互事件传递给 Model 来更新数据。ViewModelViewModel虚拟 dom数据绑定事件回调图 3.4-2 MVVM 模式背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem38生命周期模型跨端应用的生命周期由 App 生命周期和 Page 生命周期组合而成，Page 只能运行在 App生命周期之内，而不能脱离 App 独立运行。App 生命周期主要包含 onCreate、onShow、onHide、onDestroy 等主要状态，Page 生命周期较为复杂些，主要包含 onInit、onReady、onShow、onHide、onRefresh、onDestroy 等主要状态。当跨端应用运行时，会在应用的不同的生命状态下，触发对应的回调函数，开发者可以精确掌控应用的运行状态并做出正确的响应操作。生命周期状态的具体作用说明见下表。生命周期状态说明onCreate监听应用创建,当 App 创建时调用onInit表示页面的 ViewModel 的数据已经准备好onReady表示页面的 ViewModel 模板已经编译完成，此时可以获取 DOM 节点onShow表示 App/Page 的已经显示onHide表示 App/Page 的已经隐藏onMenuPress当点击顶部系统菜单时调用onBackPress当用户点击返回实体按键、返回菜单等操作时调用onRefresh当页面重新打开时调用onDestroy当 App/Page 被销毁时调用，此时可以做应用退出前的资源释放操作，比如：取消事件订阅监听等背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem39开发范式语法规范跨端应用框架是一套以前端开发技术栈为主的应用开发框架，语法规范的设计上，采用流行的前端开发模式，尽可能贴合主流前端开发者的思维习惯。每个跨端应用的页面由三个部分组成：、和，其中 Template 负责描述页面组成结构，Style 负责页面元素的样式描述，Script 负责逻辑处理。Template-采用类似 HTML 的标签语言，利用基础组件、自定义组件、block/slot等元素构建出复杂的页面结构，还支持列表渲染、条件渲染、数据/事件绑定等高级功能。Style-遵循 CSS 语言规范，描述页面中组件的显示样式。Script-遵循 JavaScript ES6 语法标准，编写代码实现具体的业务逻辑和数据处理。路由管理跨端应用框架负责管理整个应用的页面路由，实现页面间的无缝切换，并管理每个页面的完整生命周期。开发者需要将页面在应用配置文件中进行注册，也可以在 Script 中通过路由 API 来控制页面切换。路由管理除了支持应用内页面跳转之外，还支持应用间的跳转，即从一个应用中打开并跳转到另一个应用的某个页面，比如打开系统设置的 WIFI 管理界面。数据绑定数据绑定是 MVVM 模式的重要功能，开发者通过数据绑定，只需少量的代码就可以实现数据与视图的同步。在 Script 中对已经绑定的数据进行修改时，视图就会自动完成相应的更新。对于数组类型的数据，可以通过循环渲染指令简化绑定过程，能够根据数组元素的数目，自动生成相同数量的 Dom 节点完成一一对应的绑定。布尔类型的数据，可以配合条件渲染指令，动态控制页面中组件的可见状态。系统组件跨端应用框架提供了一组基础的原生实现的系统组件，系统组件除了支持常用的 HTML5 标签（比如、等）外，还提供了更多复杂的 UI 组件（比如、等）。由于不同的设备对系统组件的支持能力存在差异，因此可将系统组件分为通用组件和非通用组件：通用组件：可以运行在所有类型的设备上，比如 非通用组件：只能运行在特定的一种或几种设备上，比如 在开发跨端运行的跨端应用时，尽可能使用通用组件；如果必须使用设备相关组件时，可以通过条件渲染、动态组件等手段来减少适配工作量。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem40组件自定义为了更好的组织逻辑与代码，可以把一个页面按照功能拆成多个模块，每个模块负责其中的一个功能部分，最后页面将这些模块引入管理起来，传递业务与配置数据完成代码分离，这些模块这就是自定义组件。自定义组件不同于框架所提供的原生实现的系统组件，它是由开发者采用跨端应用语法来实现的，使用方式与和系统组件是完全一样的；自定义组件拥有与 Page 相同的生命周期模型，也具备对数据、事件和方法的管理功能；另外也为组件提供了父子组件通信、兄弟/跨级组件通信机制，高效实现组件之间数据传递和协同工作。原生系统能力跨端应用框架提供了丰富的原生能力 API，既有通用的系统功能，比如设备信息、屏幕亮度、文件访问等，也有硬件模组相关能力，比如传感器、地理位置、蓝牙、NFC 等，还有第三方服务的对接，比如推送，支付、账号、广告等。这些原生能力 API 可以大大节省开发者工作量，快速开发出跨端应用。与系统组件类似，原生系统能力也分为通用能力和非通用能力：通用能力：在所有类型的设备上均可用的能力，比如应用上下文、日志打印、页面路由等。非通用能力：只能在特定的一种或几种设备上可用的能力，通常与设备的硬件模组相关，比如地理位置、震动、传感器等。为了方便跨端开发，跨端应用框架采用能力可用性查询 API 和能力调用降级处理等手段，确保当使用无效的设备相关能力时不会导致应用运行异常。多语言覆盖跨端应用框架也提供了多语言支持能力，可以做到让一个跨端应用同时支持多个语言版本的切换，开发者无需开发多个不同语言的源码项目，避免给项目维护带来困难。开发者配置多语言的方式非常简单，只需要定义资源、引用资源两个步骤即可完成；另外也提供标准 API 允许跨端应用在运行过程中修改地区语言。关键技术UI 自适应智能终端设备种类繁多，在屏幕大小、屏幕分辨率、页面结构、交互方式等方面都有差异，因此页面的自适应能力就非常重要，否则会给开发者带来大量的适配工作。UI 自适应能力通过多种技术手段和途径组合实现，最终保证页面能够在各种设备上呈现出满意的 UI 表现：背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem41 弹性布局-弹性布局的独特之处在于能够扩展和收缩组件元素，以最大限度地填充可用空间，因此弹性布局可以让页面在面对不同的屏幕尺寸时，具备更好的适应能力 等比缩放-每个 App 定义了设计宽度属性 designWidth，当实际运行的设备屏幕宽度与 designWidth 不同时，采用等比例放大缩小来实现自动适应。非等比例屏幕适配-非等比例的适配也是开发中经常遇到的一种需求，比如：同一个页面在大屏和小屏上显示的内容不同。针对这种需求，采用设备独立像素、媒体查询等手段来控制页面上组件的显示状态（比如大小、显示/隐藏等）来解决内容适应问题。可见即可说可见即可说能力为应用提供了 2 种开发接入方式，一是语音技能绑定方式，该方式利用强大的后端 AI 服务提供复杂的 NLP 模型和意图识别能力，而且也可以为应用关联更复杂的在线服务和业务逻辑；二是本地意图识别方式，采用框架预置的意图识别引擎，只需简单的配置就可实现本地化的基础语义理解能力，能够大大降低使用门槛。页面自适应组件隐藏/替换拆分不同页面组件自适应布局自适应媒体查询界面逻辑分离组件自定义MVVM图 3.4-3 UI 自适应技术解决方案图 3.4-4 可见即可说接入方式 模块粒度组织模板/样式/逻辑语音开发者绑定语音技能框架预置模糊匹配语义事件界面响应语音事件派发流程CSS:JS 静态/动态导入独立 JS 文件 不同设备页面重新组合背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem423.4.3.2小部件技术介绍小部件是一种轻量的卡片应用，可以驻留运行在终端设备的桌面应用上。由于小部件采用各种规范尺寸的卡片来呈现，所以界面内容相对简单，通常借助设计工具来辅助开发，其典型开发流程如下所示。小部件采用自己独有的运行时，其技术特点如下：统一跨端体验-面向跨端的运行时设计，采用统一的动画计算模型，为各类终端设备提供一致的交互体验。高效的动画渲染 -小部件注重动画效果，因此采用高性能的物理动画引擎，帮助开发者实现酷炫的动画表现。技术架构小部件运行时主要包含 Amaml 渲染器、动画引擎和卡片容器等核心模块，其整体框架结构如下图所示。动画引擎提供了丰富的动画接口，支持 Folme 物理动画引擎、关键帧动画、Lottie 等等，Amaml 渲染器底层采用 Canvas 图形渲染，实现了图像、文字、矢量图形等元素的高性能绘制和场景管理；卡片容器集成二者，实现卡片应用的生命周期、VDom 以及交互事件等基础管理功能。图 3.4-5 小部件典型开发流程主题小部件表盘设计工具Renderer渲染层ASTXMLMTZ/BIN转义层通用性背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem43关键技术1.Folme 动画引擎：Folme，取名于 Follow Me，是一套设计端与开发端统一思路与接口的跨平台递进式动画 SDK，其保证了设计端和开发端一致的语言、一致的参数得到一致的效果，并大幅提高设计效率与研发效率。在以往的动画设计与研发流程中，动画对接都是一个耗时耗精力的过程。原因大致有：图 3.4-6 小部件架构桥接层HybirdBridge运行时层FolmeLottieKeyFrameMamlAnimationAmamlRender框架层BaseAPIExtensionAPIRouterPageComponentFeatureAnimationGraphicsControlsVectorGraphicsImageTextAmamlContainerServiceFeatureJSEngineUIComponent背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem44 设计与研发工具不统一，导致动画参数与形态不一致。Android 动画框架过于老旧，不支持交互、打断、可变速度等操作。传统的插值器不能支撑现代动画设计。针对这些问题，我们以“提升动画对接效率，支撑现代化的动画效果”为设计目标研发了Folme 引擎，其主要特点在于：高性能：Folme 非常注重动画的性能，尤其是在多元素同时运行的场景下，Folme 做了大量的性能优化，保证动画的流畅顺滑。模块化：Folme 层级之间相互解耦并且可以单独调用。开发者可以基于 Folme 提供的基础模块开发可适配不同运行环境的动画引擎。使用简单：Folme 在操作层做了大量的工作，优化了接口调用方式，添加了多元素编排，支持智能单位转换等等。此外，我们也为开发者提供了 Folme 组件库，将项目中常用的动画效果抽象封装成为开箱即用的组件，这有利于提高小部件的开发效率，也方便技术沉淀和积累。Folme 组件的优势在于：开箱即用：只要在页面中简单引入一个 js 文件即可使用组件，非常方便。图 3.4-7 Folme 动画引擎架构操作层Set/To/CancelStagger多元素编排插值队列计算层回调层回调队列测量队列复原队列TimerTracker计算引擎WebWorker插值器缓动目标元素格式化配置格式化单位转换渲染层Timer渲染队列TargetValue物理缓动TargetValue背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem45 跨框架：组件库基于 WebComponent，可以在任何框架下像使用原生组件一样使用 Folme 组件。可扩展：组件库是按需加载的，即便添加再多组件也不会影响到每个组件的加载性能。安全：组件库使用 Shadow DOM，开发者不需要担心引入组件造成样式污染。2.动画编辑器：动画编辑器是一款专门为设计师或者运营人员提供的简易动画编辑应用，旨在解决设计师在设计动画时需要进行大量简单而重复的工作痛点，利用补间动画原理，只需要设计师设计几个关键的动画帧，然后设置好帧与帧之间过渡的缓动曲线函数就可以实现很好的动画效果。动画编辑器支持的素材类型有：圆角矩形、椭圆、文字、图片、序列帧、编组，支持的属性有：大小、位置、缩放、旋转、颜色、边框颜色、字体、字体颜色、字体大小、不透明度、蒙版等，同时，还支持所有的缓动曲线函数。在设计阶段，动画编辑器采用可视化编辑方案，属性设置立即生效，同时支持高频操作的快捷键及拖拽操作，操作习惯与其他常用的设计软件保持一致，尽可能降低设计师的使用学习成本。此外，该编辑器对动画曲线的支持粒度非常地细，对每个关键帧、每个素材及每个属性都可以分别设置缓动曲线函数及 delay，让动画设计更加自由和灵活，动画效果更加酷炫。在预览和产出阶段，动画编辑器提供了两种方案：Web版-提供实时预览、生成 h5 动画并下载、协同与共享等功能。桌面版-提供实时预览、工程文件保存、代码辅助（支持手势、陀螺仪）、ADB 连接手机调试、生成代码文件等功能。3.4.3.3开发工具套件技术介绍开发工具套件为开发者提供了一个完整的、跨平台的开发环境，包含命令行工具(AIOT-Toolkit)和 IDE(AIOT-IDE)两部分。开发者可以根据需要使用命令行工具或者 IDE 来进行开发，给开发者开发带来更便捷的可视化操作体验。技术架构开发工具套件组成结构如下图所示：背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem46开发工具套件技术特点包含：功能强大的命令行工具命令行工具基本覆盖了跨端应用开发的全部流程，包括项目创建、项目打包编译、项目运行。它基于 Nodejs 来开发，是一个跨平台、跨 IDE 的系统级命令行工具，开发者完全可以在喜欢的 IDE 中结合 AIOT-Toolkit 来开发跨端应用。高度可扩展的插件机制AIOT-IDE 针对跨端应用开发场景对 VSCode 进行了二次开发，完整继承了 VSCode 的插件能力，同时也对插件接口的能力进行了扩展，使得 IDE 即可以直接使用 VSCode 现有丰富插件，也可以定制开发出针对跨端应用的各种工具插件。实时快速的语言服务器插件语言服务器是跨端应用开发必备的代码理解帮助工具，它通过对跨端应用代码上下文进行实时分析，快速准确地完成代码提示、补全、代码诊断等工作，有助于减小代码中的人为错误，提高跨端应用代码开发效率。工程管理AIOT-IDE代码编辑代码检查编译构建流程管控真机模拟通信代码运行AIOT-IDE 基础能力、插件系统基础功能集成功能命令行工具AIOT-Toolkit模拟器图 3.4-8 开发工具套件背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem47关键技术1.工程管理：提供项目管理的能力，包含创建项目，删除项目，以及项目文件创建、删除、项目资源管理等等。开发者可以方便地管理多个项目的文件和资源，提高开发效率。2.代码编辑：代码编辑包含代码编辑器和语言服务器两部分：代码编辑器-主要用于编辑代码。代码编辑器可以用于任何一种编码语言或框架。它具有代码词法高亮、自动缩进、自动补全、代码折叠等功能，以帮助程序员编写更高效、更易于阅读和维护的代码。语言服务器-能够在开发者在进行跨端应用代码编辑的时候，对代码进行理解，对输入的代码进行实时语法高亮；根据代码的上下文进行代码提示和补全；对于输入完的代码，进行代码校验、诊断，对于存在错误或不合理的地方，给与标记并给出错误提示。3.流程管控：在使用 IDE 进行三方应用开发过程中，流程管控能力提供了一个标准化的跨端应用开发流程管理功能，使得开发者可以清晰得知道自己在项目开发的什么阶段，当下需要处理什么问题；另外，流程管控还以可视化的方式，将整个开发流程串联，让开发者快速上手。4.代码调试：在开发跨端应用时，代码调试是使用频率非常高的功能。开发者可以使用代码的断点来跟踪代码中的问题；通过分析代码执行时产生的日志来定位代码中的问题。AIOT-IDE 中提供以下主要调试能力：断点功能 在代码的编辑过程中，你可以对代码进行断点操作，这样，在代码运行的时候，运行到断点处时，代码会暂停在断点处。此时，你可以查看代码运行到此处的状态，如变量查看，逻辑分析等等，方便排查问题。日志查看 并不是所有的调试都方便用断点的方式查看，比如程序运行过程中一个多次变化的变量，这时，你可以通过日志的方式，输出该变量，可以方便的查看这个变量的变化过程。创建项目流程管控开发运行调试编译图 3.4-9 开发工具流程管控背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem48 DOM 树查看 跨端应用在显示布局上与 HTML 非常类似，调试工具提供了 DOM 树查看的能力，该能力方便开发者可以准确快速的查看代码布局的情况，选中调试工具中的 DOM 树，该 DOM 树在渲染窗口中的实际渲染产物会被高亮，可以方便开发者定位布局样式等问题。5.命令行工具：命令行工具是基于 Nodejs 的开发工具，它对用户开发的代码进行编译，并将源码打包成三方应用的格式(RPK)，在打包的过程中，它对应用进行签名。在应用上架和安装过程中，都会进行签名验证，防止应用被恶意篡改。命令行工具提供了丰富的命令，可以支持所有类型跨端应用的打包编译。在打包编译的过程中，它还可以对源码进行校验，当源码出现一些错误时，会给出提示并指出打包错误的地方。除此之外，命令行工具还可以调用 Emulator 模拟器，可以让程序在模拟器 Emulator 中运行并查看运行效果。6.模拟器：AIOT-IDE 集成了多种设备模拟器 Emulator，能完整支持跨端应用开发、调试和测试等工作，而且部分性能评估工作也可以在模拟器上完成。另外，模拟器也支持跨平台，可以在 Linux/Windows/MAC 等平台上运行。7.插件扩展能力：AIOT-IDE 针对跨端应用开发场景对 VSCode 进行了二次开发，增加了插件接口的能力方便完成业务需求。基于 AIOT-IDE-SDK，可以开发出功能更强大的各类插件工具。此外，AIOT-IDE 也完整兼容 VSCode 的插件生态，让海量插件在AIOT-IDE 上随搜随用。3.4.3.4IoT 框架技术介绍IoT 框架提供了通用的功能模块，使得采用米家 IoT 协议簇的设备可以接入米家平台，并和其他设备以及云服务进行交互。其中基础连接协议层提供多种不同的通信协议与跨端设备进行通信，而通用服务层提供不同的功能模块进行业务开发。技术架构背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem49小米澎湃 OS 操作系统 IoT 子系统包含协议连接层、中间件、通用服务三层协议框架。连接协议层 连接协议层包含 Wi-Fi 和米家 Mesh 协议，以及 PLC 有线协议。中间件 中间件包含基于 TLS 的米家云端连接协议 OTS，以及米家局域网控制协议 OTU。同时实现了基于订阅发布的应用间消息总线和局域网端到端的分布式通信总线。MIoT Spec 是对于 IoT 设备规范化的功能性描述语言。米家自研的 Host 和 Mesh 蓝牙协议栈，扩展了低功耗和 Mesh 组网的 IoT 设备应用。通用服务层 通用服务层为米家应用、云端、小爱语音提供应用服务能力。其包含畅快连配网服务，以提供设备的极致配网体验。以及固件 OTA 服务，用以设备固件下载和升级。与此同时，通用服务层还提供了米家本地化服务集，包括中枢服务、本地控制服务和自动化服务，用以实现设备本地协同、离线控制和设备联动。通用服务网关服务中枢服务本地控制服务自动化服务图 3.4-10 IoT 框架畅快连OTA大数据.中间层OTSOTUOTPub/SubMIoTSpec协议适配层米家蓝牙议栈消息总线.连接协议层Wi-Fi米家MeshPLC.背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem50关键技术1.畅快连：小米畅快连是一种自动发现设备并配网、离线自动回连的能力，它在小米智能设备生态之上，基于米家 Wi-Fi 和 BLE 连接协议，提供了以下四大功能体验：靠近配网：靠近即发现，点击即配网。手机靠近设备，系统/米家 APP 主动发现新设备，并引导用户快速绑定。一键配网：插电即发现，点击即配网。搭配小米畅快连路由器使用，新 IoT 设备接通电源后，米家 APP 会主动弹窗提示发现新设备，一键点击即可快速进行配网操作，且不需要手动输入 Wi-Fi 账号密码。无感配网：下单预绑定，插电即配网。用户在小米商城下单时选择了“无感添加”服务，新 IoT 设备接通电源后，与小米手机或小米畅快连路由器自动联动，用户全程零操作，是设备配网的最优体验。改密同步：Wi-Fi 改密，设备自动回连。搭配小米畅快连路由器使用，当路由器修改 Wi-Fi 账号密码后，IoT 设备可自动连接新的 Wi-Fi 账号，避免需要重置设备重新配网。2.OTA：固件升级是智能设备的关键能力，它可以为用户提供不断进化的产品体验。对于亿级设备的小米 IoT 平台而言，固件 OTA 能力至关重要。小米 IoT 平台具备行业领先的固件升级能力：设备固件静默升级：取得用户的授权后，设备可按需启动智能升级，且升级过程对用户无打扰。可大幅提升设备升级率，便于产品新体验的推广普及。基于容器化的独立升级方案：设备中的米家连接模块和产品功能模块实现解耦，可独立升级，降低开发者的开发维护成本。实时监控与熔断机制：设备端支持分钟级的实时监控，在监控到升级关键指标异常时自动采取熔断操作，降低可能的用户和平台损失。3.网关服务：网关服务作为一种通用能力，可以将其他协议的设备接入到米家平台，如蓝牙设备、PLC 设备等。通过统一的适配层，网关服务屏蔽了芯片、操作系统、协议带来的不同，为用户带来一致的体验。网关服务包括多项具体功能：设备管理：网关统一管理设备的信息和状态，包括设备标识、网络拓扑、在线/离线状态等。协议转化：不同协议接入的设备及其行为都会被转化为统一的 MIoT Spec 描述，为设备互通提供基础能力。分组/批量/场景控制：根据使用场景的需求，提供分组/批量/场景等多种控制方式。流量管理：屏蔽无效上下行流量、减轻服务器压力。设备漫游：网关自动捕获附近设备，设备可在不同网关间无感漫游。4.本地化服务：本地化服务是若干服务的能力集，包括中枢服务、本地控制服务和自动化服务等，可以在外网离线的情况下对设备进行控制和设备联动。各主要服务的功能如下：中枢服务 中枢服务提供了网关设备之间协同能力，包括：背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem51 协同组网能力：集成不同中枢能力的设备，在局域网内可以组成主、备、从三种角色的中枢拓扑架构。数据同步能力：主备之间可以进行文件同步和设备属性状态的同步，保证设备之间数据的一致性。设备发现能力：通过设备发现协议探测 IoT 设备，并根据设备能力进行消息订阅和总线连接。本地控制服务 本地控制服务结合中枢服务，对外提供 IoT 设备的本地控制能力。具备控制能力的应用和终端设备，通过连接主中枢控制其他设备。自动化服务 自动化服务提供设备联动的能力，基于有向图规则引擎，可以创建不局限于 When-If-Then 的复杂场景。跨端身份认证通用密钥管理设备可信跨端身份认证通用密钥管理设备可信可信连接可信传输可信对端状态MiTEE图 3.5-1 跨端安全子系统整体框架3.5.2子系统架构3.5跨端安全子系统3.5.1子系统简介小米澎湃 OS 基于不同的硬件环境使用不同的 TEE 方案构建可信的安全底座，进一步依赖安全底座构建了框架层的设备可信、通用密钥管理和跨端身份认证的能力，对跨端场景提供了可信连接、可信传输和可信对端状态。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem52关键技术1.证书私钥：设备在登录小米账号后，将由小米账号云为该设备签发证书，确保该设备登录了该账号。证书将用于同账号设备之间的相互认证。2.私钥保护：证书的私钥由安全 OS 全生命周期保护，在认证过程中，将校验对端设备证书的合法性、有效性，确保证书是签发给该设备的。即使将认证在另一台小米设备上使用，也将无法通过身份认证。3.5.3重点特性3.5.3.1可信连接技术介绍为保证小米澎湃 OS 的连接安全，实现用户数据在多设备场景下各个设备之间的安全流转，需要保证设备之间相互正安全可信，系统提供了安全可信的身份认证和可信连接。技术架构小米账号云证书服务器安全 OS设备 1安全 OS设备 2证书私钥证书私钥小米账号在该设备的证书小米账号在该设备的证书正式签发正式签发图 3.5-2 跨端可信连接背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem533.5.3.2可信传输技术介绍提供有身份验证，加密保护的可信通信，确保数据的机密性和完整性。技术架构关键技术1.应用身份校验：在设备级安全连接的基础上，对应用之间的通信连接也会进行应用身份校验，确保跨端应用身份的合法性，避免应用伪装等场景。HyperConnect 服务将校验应用的签名信息，包名等关键信息，确保两端应用的通信的身份安全。2.加密通信：应用间任一连接、任一会话将使用独立通信秘钥，通信的数据将自动加密，确保数据的机密性和完整性。应用身份认证图 3.5-3 跨端可信传输 设备 A应用进程应用身份认证设备 B应用进程HyperConnect 服务HyperConnect 服务1.应用身份校验2.加密通信背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem543.5.3.3可信对端状态技术介绍小米澎湃 OS 借鉴了可信计算和零信任安全模型等前沿的安全理念和架构，在深度融合了小米 IoT 万物互联的实践经验上，通过动态验证对端的可信状态，来应对万物互联时代带来的新挑战。关键技术1.统一的安全建模：小米澎湃 OS 基于分布在不同设备上硬件隔离环境，对系统运行状态提取运行特征，并根据统一的安全模型叠加不同设备类别的维度，对设备进行动态度量，用于识别设备是否处于安全状态。2.可信的对端度量：小米澎湃 OS 基于出厂时在不同互联设备上基于硬件执行环境预置的信任根，来达到可信确认对端安全状态的目的。处于互联状态中的小米设备，在本端完成动态度量后，度量结果加上互联对端传入的挑战值，组合后由硬件执行环境中的信任根进行加密及签名保护，得以可信任的被对端确认。3.持续的动态验证：在互联状态下，基于可信的互联对端度量，小米澎湃 OS 在系统底层维护了互联对端的可信状态，并开放的提供给互联应用作为参考。在互联应用需要时，可以实时对对端可信状态进行刷新，达到动态验证的目的。图 3.5-4 跨端持续动态验证持续动态验证4.永不信任的主动免疫：互联状态下的不同小米澎湃 OS 设备实体，秉承永不信任的零信任思想，在确认对端可信的情况下进行互联融合，也会在动态验证对方发现问题时进行主动免疫，避免互联场景引入的单点设备风险。MiTEE设备 AHyperConnect基于 MiTEE 的设备可信状态MiTEE设备 BHyperConnect基于 MiTEE 的设备可信状态背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem554系统服务与框架4.1资源调度子系统资源调度子系统主要围绕系统资源来进行工作，聚焦任务如何在硬件上进行管理和调度，主要提供三个关键能力，即：抽象协同芯片硬件，释放硬件能力；统筹管理资源供需，提升全局能效；使能应用高效运行，提供生态入口。资源调度子系统重点组成部分为 CPU 资源子系统（存储、GPU 会在其他章节介绍），CPU 是对手机的所有硬件资源进行控制、运算和管理的核心硬件单元。随着 CPU 制作工艺的提升，手机所能提供的算力也越来越强，游戏和相机等高负载应用，在高算力的支持下，运行的也越来越流畅。但算力增长的同时，续航却变的越来越差，发烫也日益严重。因此 CPU 的自身性能和调度方式，是用户体验是否满意的一个主导因素。传统的 CFS 调度，主要是面向桌面系统/服务器的调度策略，可以更好的兼顾交互应用与系统吞吐量之间的平衡。属于性能优先的调度策略，通过把任务近乎平均的分配到系统所有可用的 CPU 上，最大限度地提高系统的吞吐量，不会过多的考虑到系统的耗电问题，设计时主要针对的是 SMP 系统。CFS 并没有充分利用各个核的能效比、频率差来平衡性能和功耗，自然也不适用于有交互界面、场景复杂的手机操作系统。2012 年前后，ARM 推出了 big.little 处理器架构，来优化手机日常使用中的 CPU 能效。随后，Linaro与 ARM 联合提出了 EAS(Engry Aware Schedule)调度算法，通过对原有的调度策略（选核，负载追踪，均衡等）做重新设计，打通了 CPU idle 管理子系统，CPU freq 子系统与调度之间的关联，以调度为核心，让 CPU 状态管理相关的几个模块紧密协作在一起，目标是在保证系统性能的前提下尽可能地降低功耗。因此，CPU 调度子系统做为操作系统中的核心子系统，对任务资源调度平衡起着关键作用，需要通过一系列先进的技术来管理、调度和优化 CPU 资源，以提供高效的计算和响应能力。小米澎湃 OS 资源调度子系统目前主要包括关键任务的识别染色、焦点计算和 SOC一体化调频等技术，从而实现了对 CPU 资源的能效管理和优化，有助于确保系统的稳定性和性能，满足各种算力需求。4.1.1子系统简介(Service&Framework)背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem564.1.2子系统架构图 4.1-1 调度子系统整体架构 基于用户场景的优化智能调度赋能平台基于系统资源的智能调度策略CPU 资源管理机制CPU 资源计算三方流畅加速引擎游戏加速 SDK应用加速器MiSpeedSDK前后台信息渲染状态场景特征提取平台信息窗口类型软硬资源状态场景信息分类应用内转场进程活跃度Miaware核心场景Speedinput场景信息分类关键任务识别染色丢帧预测Cache智能分配任务聚类IPA 热感知算力分配后台进程梯度冻结/查杀/宽带控制功耗自反馈计算大小核智能调度关键任务优先调度Teas 热感知系统帧负载称重PMU 事件监控CPU 资源调度CPU 资源统一管理和鉴权平台任务亲和性管控次级任务错峰调度负载分层和均衡系统CFS 双周期调度基于调度轨迹追踪的算力自动调节身份识别需求拦截CPU 状态管理帧负载称重PMU 事件监控SOC 频率一体化调节周期同步子系统快速提频子系统频率调节子系统硬件驱动层硬件平台层应用框架层用户空间系统框架层内核层 内核空间技术栈背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem57任务 D4.1.3重点特性4.1.3.1关键任务识别染色技术介绍手机在使用过程中，会有成千上万个任务处于活跃状态，这些任务当中，有些是前台任务，有些是后台任务，将前台任务中会影响到渲染绘制时长的任务识别成关键任务，通过对关键任务标记，根据任务的阻塞状态和阻塞原因，对关键任务依赖的普通任务进行追踪染色处理，从而实现链式优先调度，带宽控制，错峰对齐等操作。就绪任务任务 A任务 B任务 C任务 D场景关键任务自动识别智能任务聚类任务 E任务 F任务 G任务 H任务 I.任务 X任务 A任务 B任务 C任务 D任务 E任务 F任务 J任务 I任务 H.任务 G任务 X关键任务普通任务次级任务任务 A任务 B任务 C任务 D任务 E主动加速任务 F任务 G任务 H.任务 X任务分类场景识别图 4.1-2 关键任务识别染色机制示意图任务 C任务 A任务 B任务 G任务 X任务 F锁/信号量任务 E任务 J任务 H任务 I.链式着色背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem58技术架构关键技术1.关键任务的链式识别：资源调度子系统能够通过任务的阻塞状、阻塞原因识别出渲染过程中的焦点任务转移路径，动态标记当前影响渲染的任务为关键任务，并优先供给系统资源，达到渲染全链路加速的效果。资源调度子系统针对不同的依赖类型进行不同的标记传递。不局限于静态的管控单一任务，而是通过追踪任务依赖，动态的管控整个渲染链路。2.次级任务识别和管控：资源调度子系统针对剩余的普通任务进行进一步的精细化识别，识别出其中对用户感知以及对于系统体验影响较小的次级任务。并针对次级任务进行带宽控制，错峰调度。3.不可感知任务识别：通过对用户场景的识别和对系统资源使用状态的探测，评估每个任务的用户感知程度。通过组件交互信息的拦截和梳理，确定活跃应用的关联任务范围，从而识别出系统中的用户不可感知任务，进行资源使用管控。图 4.1-3 关键任务识别染色技术架构应用分类感知识别框架任务聚类和管理导航使用感知下载感知蓝牙使用感知音频使用感知沉浸式体验感知.三方应用系统应用后台应用前台应用当前应用小窗应用用户使用感知前台应用渲染任务标记依赖关系自动追踪组件交互感知关键任务普通任务次级任务不可感知任务背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem594.1.3.2丢帧预测模型技术介绍丢帧预测模型主要是基于渲染链路各关键节点的负载变化差异以及核心应用丢帧特征进行丢帧预测，为了适用更多应用，需要对更多常见的丢帧特征进行学习和训练，以此提高丢帧预测的准确性。技术架构关键技术1.渲染耗时感知模块：资源调度子系统收集画面渲染过程中的事件、场景、帧率和画面信息。通过采集到的信息能够勾勒出渲染的整体情况，并且统计出渲染各个过程的耗时情况以及资源消耗情况，从而能够识别出渲染过程中的资源瓶颈。2.丢帧预测模块：通过采集到的渲染信息、耗时以及资源消耗情况，预测出下一帧发生丢帧的概率，针对高概率场景，提前做系统的资源的预先供给或算力补偿。基于经验学习的应用丢帧特征识别，通过对高丢帧特征的实时监控以尽可能早的预测出任务的负载变化，进而提高预测精度。图 4.1-4 丢帧预测模型技术架构应用层淘宝微信抖音快手框架层场景识别模块核心应用渲染流关键节点耗时监控关键任务 block 状态溯源和异常探测系统资源状态诊断滑动场景微博头条.丢帧检测通用场景（全链路丢帧预测）启动场景其他核心场景渲染链路耗时监控基于 AI 的丢帧特征识别和启发式预测算法背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem604.1.3.3帧负载称重技术介绍传统的 CPU 负载计算方式，无法准确评估每一帧之内关键任务的真实负载，因此可能会导致负载评估不准而引起的 CPU 频率调节不精确的问题，进而导致性能不足或者功耗的浪费。通过研究发现，即使限制 CPU 频率，仍可以保证游戏帧率满帧，说明当前系统平台上直接计算得到的频率并不准确，存在算力供给过剩的情况。进一步分析发现，当前系统采用的负载统计方法中，某些计算进入负载的任务对用户感知影响并不明显，但会极大的拉高 CPU 的频率。例如对于游戏来说，只要保证游戏的渲染相关线程在当前帧结束前运行完成即可，这样就可以保证游戏流畅度。为了能够解决这些问题，资源调度子系统自研了帧负载称重方案，在精细化管控和识别精度上更近一步，以降低系统不必要的功耗为基础，提高 CPU 日常使用过程中的能效。技术架构图 4.1-5 帧负载称重技术架构非核心场景场景智能识别关键任务核心场景游戏场景任务聚类STOPDLIDLE帧周期同步普通任务负载追踪VIP 任务负载追踪负载拟合算法智能选核帧负载称重Frameutil调频算法EASWALTSchedutil非关键任务VIPRTVIPCFS背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem61关键技术1.渲染链路上的负载追踪技术：一帧的绘制过程，是由多个任务协同完成的。而任务在协同过程中，会产生前后依赖关系。因此，渲染链路上的负载追踪技术，主要是识别任一时刻从事绘制事件的焦点任务程序片段，并计算该段时间的负载。从而根据依赖关系，精确的跟踪渲染链路中的实际负载。2.普通任务负载：与帧绘制流程无关的任务或程序执行片段，所产生的负载将单独计算。3.负载拟合算法：对不同种类的负载进行拟合，确定 CPU 的算力需求，从而发起按需调度请求。4.1.3.4焦点计算技术介绍随着安卓应用的发展种类呈现出多样化的趋势，现在越来越多的应用为了提高自己的响应速度或者达成自己的商业目的，会在后台进行未经授权的运行，并且存在滥用系统资源的风险。图 4.1-6 应用的特立独行行为前台 service 保活在不播放音频时，仍保持高优先级频繁进行网络交互应用的特立独行应用主动加强自身保活，防止被系统管控，如挂载非必要的前合服务应用后合绘帧背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem62技术架构Linux 原生的进程冻结机制，可以将活跃状态的任务进行冷冻处理，暂停并保留其执行上下文，以便后期解冻时快速恢复。该方式可以增强系统对后台应用的行为约束和管控，是一种强有力的系统管控策略。但由于系统中，任务间的依赖关系非常复杂，进程一旦被冻结后无法接收或处理外部消息（比如，手机实时通讯 apk 在后台运行中被冻结，会导致无法接收网络信息包，最终令客户无法收到通讯消息），会给用户体验带来非常多的负面影响。为了限制后台应用对系统资源的占用，减少其运行过程中对前台应用分配资源的争抢和干扰，同时不影响用户对后台应用的功能使用，设计了一套全新的冻结解决方案。该方案以后台三方应用资源管控为中心，对后台任务进行冻结，降低其活跃度，同时针对各路试图唤醒被冻任务的子系统进行拦截和管控，是一个典型的围点打援类的系统级大型优化方案。同时，抑制活跃度，降低其对 CPU 带宽的占用，也会使前台应用收益，从而增加其流畅度。新一代冻结技术在更多的细分场景中进行策略差异化定制来提升优化效果和减少冻结异常概率，同时要将冻结方案的范围从 CPU 端扩展到传感器，音频等子系统，通过各子系统资源的后台联合管控和优化，提升和改善用户体验。应用类型重点场景系统应用三方应用游戏相机启动灭屏滑动充电丢帧观影后台管控 policy省电冻结深度冻结模式强力提速智能感知全维阻断动态限制MilletAlarm唤醒网络GPUsensorCPUFrameworksKernelhardwareCPU 宽带限制图 4.1-7 焦点计算技术架构背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem63关键技术1.极限续航模式：极限续航模式下的深度冻结方案是独立的后台管控方案，且只在极限续航模式下才会生效，非极限续航模式下使用默认冻结方案管控后台应用。极限续航模式深度冻结：首先通过极限模式上层监听到的设置变化来通知冻结控制中心，系统已进入极限续航模式，需切换管控方案以进行深度冻结模式，执行更严格的管控。其次，针对极少数必要场景条件进行解冻放行，而对于频繁解冻的应用采取查杀策略，其余绝大多数非必要条件下的解冻需求，则推迟至极限续航模式退出后再解冻。2.前台服务的可感知性探测和管控：对影响用户使用的可感知的前台服务，比如音乐、导航、下载等，不进行限制；而用户不可感知的前台服务，统一进行后台管控限制。比如用户在全屏观影或者上网课的情况下，属于前台高度关注场景，此时对后台的app 的行为进行深度冻结限制，只保留必要的解冻唤醒，降低后台功耗的同时减少后台应用对前台应用的运行干扰。3.性能强力提速：一些高负载的手机使用场景，CPU 负载大，如果此刻后台应用频繁的唤醒和执行，会抢占前台应用的 CPU 带宽，加重前台运行时的丢帧。通过对后台应用进行短时间的严格冻结，来保证前台应用对 CPU 的占用不受后台应用的争抢，提高前台流畅度。4.1.3.5SOC 一体化调频技术介绍一帧的绘制完成，是需要多个硬件部件相互配合完成的。其中，CPU 是主控中心，GPU和 DDR,Cache 等属于配套资源。当 CPU 绘制完成，将顶点/纹理等数据提交到 GPU进行渲染或合成时，焦点将转换到 GPU 上。当 CPU 发起文件读写请求时，I/O 就会成为影响流畅度的主角。因此，多部件之间如何高效一体配合来减少掉帧，是该方案的优化主题。现有的 DCVS(Dynamic Clock and Voltage Scaling)和 DVFS(Dynamic voltage Frequency Scaling),都是采用基于周期采样的负载预测调频算法。试图用前一周期的负载，去预测下一周期内的负载变化，从而导致频率变更需求通常要有一个采样周期的滞后性。而通过大量的帧绘制流程分析，我们观测到 CPU 作为帧绘制流程的主控方，往往能提前预判该帧绘制过程对其它从设备的资源使用需求，从而指导相应设备做出快速的频率变更响应，减少丢帧。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem64RunningTaskSocTurboSocControllerSocMonltorGPUMPAMDividerBandwidthMonitorDDRSystemCacheBus 总线图 4.1-8 SOC 一体化调频技术架构VIPTask1NormalTaskFrequencyControllerNPUCPU7CPU6CPU5CPU4CPU1CPU3CPU0CPU2VIPPartNormalPartL3cahceCPUSoc一体化调频关键技术1.帧负载同步技术：协调 CPU/GPU/L3 cache/DDR 等子系统的调频周期，使其与帧绘制周期同步。2.算力补偿和快速提频：当丢帧等行为发生时，联合诊断丢帧原因，对产生资源需求瓶颈的子系统做快速的算力拉升和调配。3.SOC 一体化频率调节：通过精准追踪 CPU 的流水线指标动态变化趋势，及时预估负载变化对 CPU/GPU/L3 cache/DDR 等子系统的算力新需求，并做出统一部署。通过精密计算不同策略的能效，选择最优算力调配方案，提升系统能效。技术架构背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem65应用场景滑动前后台切换图 4.1-9 智能调度技术架构系统场景场景识别接口层定制化接口赋能平台帧率信息统计策略配置中心接口层内核子系统标准公开接口焦点变化关键技术1.关键任务优先调度：传统的调度策略，对外主要提供了 CFS 和 RT 两种调度策略，实时线程用于处理一些实时性要求高的系统级短时任务，普通任务用于承载应用的绝大多数业务逻辑。但普通任务数量庞大，其中部分任务用于渲染绘制，其执行时间的快慢会影响一帧的绘制时长，从而影响到用户感知。与此同时，其它的任务运行时间的快慢用户感知并不明显。所以，为了对普通任务中的关键任务执行调度加速，故提供了关键任务优先调度功能。资源调度子系统打破了原有的 Linux 内核公平调度机制，针对标记的关键任务进行优先排队，使关键任务能够在系统极度拥塞的场景下也能及时获取 CPU 资源，从而让系统保持流畅运行。负载监控中心智能调度内核接口SoC 算力统一分配次级任务惰性调度关键任务优先调度频率自适应调节资源异常检测和自恢复启动退出系统引导跨进程模糊技术架构4.1.3.6智能调度赋能平台技术介绍为了将目前小米在 SoC 调度领域的能力拓展到更多场景，并且帮助应用开发者根据实际需求来提升其在小米澎湃 OS 上的性能体验，基于目前资源调度子系统的能力，开发了智能调度赋能平台。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem662.次级任务低功耗调度：应用开发者，可以根据业务自身的特点和开发过程中任务角色的划分，将一些用户感知不明显的任务主动接入次级任务低功耗调度接口，从而减少其对 CPU 资源的过多占用。3.更加安全的调度加速解决方案：关键任务优先调度，相比于原有 RT 调度，更具有普适性。关键任务优先调度功能既不会影响系统中低优先级实时任务的运行，也可以在关键任务发生异常时及时中断其优先调度功能，实现异常探测和调度异常自恢复。同时，资源调度子系统还集成了频率异常监控机制等，防止系统出现过热或 CPU 资源异常无法释放的情况。4.基于任务调度轨迹追踪的精准提频方案：智能调度避开了原生的系统提频机制，独立实现了一套精准提频机制，能够快速响应提频和取消提频的指令。避免了原有提频机制可能会被阻塞而推迟提频的问题，并且追随关键任务的调度轨迹，只对其所在的CPU 做算力提升和动态迁移，从而做到精准提频。图 4.1-10 关键任务优先调度机制示意调度类实时任务调度非实时任务调度.任务分区调度（上半区）关键任务优先调度（中区）普通任务调度（下半区）次级任务错峰调度背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem67AI 子系统承接小米澎湃 OS 中包含大模型能力在内的各类 AI 能力、以及感知/理解/推荐（即智慧能力）的提供，为整个系统的“智能大脑”，是小米澎湃 OS 的最重要组成部分之一。AI 子系统不仅可以让单设备实现极强的端侧 AI 能力，同时赋予整个生态智能能力。4.2AI 子系统4.2.1子系统简介AI 子系统分为:AI SDK，AI 能力中心、AI 智慧中心、AI 融合部署框架四个部分，如下图所示：4.2.2子系统架构其中，AI SDK 是系统 AI 能力集中管理框架，并提供智慧能力服务，为应用程序提供统一的调用接口。AI 能力中心将包含大模型能力在内的各类 AI 相关能力集中至系统侧，完成对 AI 能力的统一管理与发布。AI 智慧中心主要围绕用户的高频刚需场景构建建议能力，通过学习用户在小米澎湃OS 各端的使用习惯，识别用户当前所处场景及需求，从而进行信息或服务的推荐。AI 融合部署框架用来支持能力中心和智慧中心中的各类 AI 算法在多端设备上的运行。小爱同学相机图库米家融合设备中心其他应用图 4.2-1 AI 子系统技术架构AISDK图形图像语音处理自然语言处理语言大模型视觉大模型AI 融合部署框架智慧理解多模态融合感知原子感知应用层SDKAI 能力中心大模型部署框架AI 智慧中心背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem68技术介绍AI SDK 是 AI 子系统的重要组成部分，是包含大模型能力在内的系统 AI 能力集中管理框架，并且提供智慧能力服务。框架内部采用模块化设计，使得 AI 能力提供方能够灵活地接入，同时为 AI 能力需求方提供统一、可靠、高效、丰富的 API 接口，同时也提供了智慧能力的系统服务，助力应用程序实现 AI 相关的复杂功能。本框架可分为 API 层、引擎层、管理中心、能力中心和智慧中心等核心组件，后续章节会有更详细的阐述。技术架构4.2.3重点特性4.2.3.1AISDK图 4.2-2 AI SDK业务层AIEngineAIAPIVisionAPINLPAPICloudAPISpeechAPI相册小爱视觉小爱建议相机系统其他 APP三方 APP权限校验CoreServiceAIEngineServiceNLPServiceVisionServiceSpeechServiceCognitionService能力中心管理中心智慧中心模型升级模型加载背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem69AI SDK 的主要组成部分如下：业务层 API 包括用于与 AI Engine 进行通信的一组 API。这些 API 提供了开发者与 AI Engine交互的接口，使他们能够请求不同的 AI 功能和服务。AIEngine AI Engine 是一个独立的系统服务，负责实现 AI 功能的处理和计算。AI Engine 包含以下关键功能：功能处理：接收来自业务层 API 的请求，执行相应的 AI 任务，如图像分析、语音合成等。结果返回：生成处理结果，并将结果返回给业务层 API，以便应用程序使用。AIEngine 中包含以下部分：NLP Service：自然语言处理服务，负责加载 AI 能力中心里自然语言处理模块中的能力。Vision Service：图像处理服务，负责加载 AI 能力中心里视觉图像模块中的能力。Speech Service：语音处理服务，负责加载 AI 能力中心里语音处理模块中的能力。Cognition Service：认知模块，负责加载智慧中心的智慧能力。管理中心 模型加载：负责加载所需的 AI 模型，这些模型用于不同的 AI 任务。模型升级：具有升级模型的功能，以确保应用程序使用最新的 AI 模型，从而提高性能和精度。AI API 承接应用请求与 AI Engine 进行交互，在 AI Engine 中找到对应的 Service 并加载 AI 能力中心及 AI 智慧中心对应能力实现进一步的处理和计算。关键技术1.实时性 低延迟：快速响应用户请求，如实时翻译、虚拟现实交互等。2.安全性 数据隐私：保护用户的个人数据，确保其不被滥用。模型保护：防止模型被恶意修改或盗用。3.可扩展性 多平台支持：跨 Android 和 Vela 等多个平台使用统一的 AI 能力。模块化设计：允许应用程序选择性地集成和使用 AI 功能。4.自适应性 学习能力：支持模型更新，以适应不断变化的用户需求和环境。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem70技术介绍AI 能力中心是一个集成在智能设备上提供多种 AI 能力的服务中台。它将系统中散布各类 AI 相关能力集中至系统侧，完成对 AI 能力的统一管理与发布，这些能力包括：大模型、视觉图像、自然语言处理等多个领域的能力。AI 能力中心能够优化用户与设备的互动，增加设备的自动化能力，并提供更丰富的功能。技术架构4.2.3.2AI能力中心AI 能力中心包含大模型、视觉图像、语音处理、自然语言处理等模块：大模型 整合了视觉大模型和语言大模型能力，能够将用户输入的图片、视频、文字等信息进行精细化理解和整合。视觉图像处理模块 提供超分辨率、图像分割、人脸检测等基础能力，可实现图像质量改善、增强特定功能、识别人脸或场景等一系列视觉识别、增强功能。语音处理模块 处理和分析用户的语音输入，以识别语音指令、转录文本、实现语音识别、合成语音和同声传译等功能。自然语言处理模块 提供各种处理和分析文本和语言数据的基础能力，以使智能设备能够理解和生成自然语言文本。视觉图像文字识别表格检测智能分类图像分割超分辨率人脸检测人脸属性人脸对比朝向识别手势识别.语音处理语音识别语音合成口语评测同声传译.文本翻译关键词提取情感识别人设对话.自然语言处理图 4.2-3 AI 能力中心架构大模型视觉大模型语言大模型背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem71关键技术AI 子系统封装并提供大模型能力，包括：1.视觉大模型：AI 写真：根据用户提供的个人图片生成各种不同场景的用户个性化图片，创造出各种有趣和独特的效果，满足用户的多样化需求。AI 妙画：根据用户的涂鸦和输入的文字描述作为创作材料，生成各种风格和主题的精美图像，让用户能够将自己的创意转化为图画作品，无需专业绘画技能。AI 搜索：帮助用户通过文本描述来查找其手机中相关内容的图片，用户能够使用文字输入来快速找到智能设备中的图像资源，提高图像管理和检索的效率。AI 编辑：实现帮助用户扩展图像内容、替换图片中的特定物体等功能，改进图像质量或满足用户特定需求。2.语言大模型：意图理解：根据用户交互的上下文，包括对话历史和语境，更好地理解用户意图和情感倾向。这使它们能够提供更具连贯性和准确性的回应。知识问答：基于广泛的知识库进行了训练，涵盖了多个领域的信息。它们可以回答各种主题和领域的问题，从历史事实到科学知识。并实时从互联网获取信息，以回答当前事件和趋势相关的问题。工具调用：它们可以用于自动执行各种任务，如发送电子邮件、创建日程事件、提供天气信息、翻译文本等。用户可以通过自然语言自动化地调用工具，以完成日常任务。技术介绍AI 智慧中心是一个多层次、多模态的智能系统。基于终端设备丰富的传感器和强大的计算能力，AI 智慧中心可以感知用户身边发生的事件，以及设备操作记录。旨在为用户提供更加智能化、个性化的服务。它包含四个关键模块：原子化感知、多模态融合感知、智慧理解以及应用服务。每个模块都扮演着不可或缺的角色，共同构建了终端设备的 AI智慧生态系统。4.2.3.3AI 智慧中心背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem72技术架构应用服务应用推荐小爱建议危险通知XiaomiHyperMind危险监听行为检测意图理解用户画像出行检测智能推荐时间线学习空间定位用户行为学习环境感知NLP地理围栏运动感知音频感知声音事件/场景/场所识别运动状态感知驾车识别，步行识别.IOT 操作感知设备开启，设备调控空间感知车内车外感知/室内定位用户状态感知睡眠感知，呼吸/心率感知.用户操作感知应用开启，媒体播放.手势感知传感器/超声/相机手势场所识别常住地识别，室内外识别.设备状态感知屏幕状态，应用状态，环境光感知，信标感知.图 4.2-4 AI 智慧中心技术架构智能理解多模态融合感知原子化感知背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem73AI 智慧中心分为原子化感知，多模态融合感知，智慧理解，应用服务四个模块：1.原子化感知 原子化感知是整个系统的基础，它涵盖了一系列手机传感器和数据源的感知能力。这包括用户状态感知，空间感知，操作感知，音频感知和设备状态感知等。这些感知数据为系统提供了关键的环境信息，以便更好地理解用户与其周围世界的互动。2.多模态融合感知 多模态融合是基于原子化感知的能力，将不同感知源的数据整合在一起，创造了更全面、丰富的感知能力。这包括地理围栏，环境感知以及用户行为学习。多模态融合允许系统更全面地理解用户的上下文和行为，为更高级的智能服务提供了关键信息。3.智慧理解 智慧理解模块通过学习和分析多模态融合感知数据，构建了用户画像，实现出行检测，提供智能推荐，以及实现对用户意图的理解。这个阶段的技术使系统能够更好地理解用户需求和喜好，从而为用户提供更个性化的服务。4.应用服务 最终，AI智慧中心的目标是为用户提供有价值的应用服务。这包括小爱建议、习惯推荐、以及行为习惯学习与自动执行（Xiaomi HyperMind）。这些服务是系统的最终输出，旨在提高用户的生活质量和满足其需求。通过这个技术架构，AI智慧中心能够实现更智能、更个性化的用户体验，提供广泛的应用服务，从而满足用户的不断变化的需求和期望。这个架构为智能终端的 AI 生态系统的未来发展奠定了坚实的基础。关键技术AI 智慧中心的技术架构具有以下重要特性，这些特性为其提供卓越的智能能力和用户体验：1.多模态感知和融合：该架构强调了多模态感知的能力，通过整合各种传感器和数据源，使系统能够理解用户的多重上下文，包括位置、环境、行为和声音等。这为更深入的智能服务提供了丰富的数据基础。2.个性化智慧理解：通过学习用户的行为习惯、喜好和意图，智慧理解模块构建了个性化的用户画像，从而为用户提供智能推荐和个性化建议。这个特性提高了用户的满意度和服务质量。3.XiaomiHyperMind 行为学习和执行：Xiaomi HyperMind 是这个架构的关键特性之一，它使系统能够学习用户的行为习惯并在用户授权的情况下自动执行任务。这为自动化生活和用户便捷性提供了新的可能性。以下是一些示例说明 Xiaomi HyperMind如何在各种情境下提供便捷的自动化：a）音乐播放场景：当用户打开音乐应用时，Xiaomi HyperMind 可以识别用户的位置和已连接的音响设备，然后自动将音频流切换到附近的音箱，以提供更好的音乐体验。b）电话通话场景：当用户接听电话时，Xiaomi HyperMind 可以感知到用户的通话状态，并可以自动调低周围媒体设备的音量，确保用户可以清晰地进行通话，而不会被嘈杂的声音打扰。c）回家的情境：当用户回到家时，Xiaomi HyperMind 可以根据用户的位置数据和时间，自动触发一系背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem74列操作。它可以打开家里的智能灯光系统，并将灯光调整到用户喜好的亮度。这不仅提供了方便，还创造了一个愉悦的家居环境。4.用户授权和隐私保护：AI 智慧中心强调用户授权。用户可以明确授权系统执行任务，并保护他们的隐私。这为用户提供了对他们个人数据的控制，在提供智慧服务能力的同时确保其数据的安全性和隐私。综合来看，AI 智慧中心的技术架构具有多模态感知、个性化智慧理解、自动学习和执行等关键特性，这些特性使其能够提供高度智能化和个性化的服务，同时保护用户隐私和授权权利。这为用户提供了更便捷、智能和个性化的手机体验，将来将继续发展以满足不断变化的用户需求。技术介绍AI 融合部署框架提供了一个可以应用于各种终端设备场景的统一 AI 部署框架，旨在解决业务中碎片化的框架部署、优化无法通用以及资源浪费等问题，通过软硬件深度融合、实现统一、高效的 AI 模型部署，赋能手机、平板、汽车、家电、IoT 设备、可穿戴设备等各类终端设备。技术架构4.2.3.4AI 融合部署框架模型转换模型压缩前处理图 4.2-5 AI 部署框架技术架构计算图优化Runtime 推理异构技术IoT 设备可穿戴设备手机/平板底层子系统计算图优化Runtime 推理异构计算MNNQMNNeuroPilotCPUDSPGPUCPUGPUNPU手机平板汽车异构硬件终端设备AI 融合部署框架MiTinyAIPlantformMiAIDeployPlantform三方部署框架.背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem75AI 融合部署框架包括通用工具和 AI 推理框架两部分：通用工具 模型转换：支持 pb、ONNX、TFLite 等模型转换。模型压缩：支持量化、知识蒸馏、剪枝等功能。前处理：支持常用的音频、图像、视频信号处理。AI 推理框架 面向小米澎湃 OS 标准设备的 Mi AI Deploy Platform，支持 CPU、GPU、NPU 异构计算，可部署在手机、平板、汽车等终端设备。面向小米澎湃 OS 轻量设备的 Mi TinyAI Platform，支持 CPU、DSP、GPU 异构计算，可部署在手机底层子系统及 IoT 设备、可穿戴设备等终端设备。三方部署框架，包括高通 QNN、MTK NeuroPilot、开源推理框架 MNN 等。关键技术AI 融合部署框架可以更灵活地选择适用于其硬件设备的最佳 AI 部署框架，提高通用性和性能。1.通用部分的提取和共享：为了实现通用性，AI 融合部署框架可以提取和共享通用部分，包括模型转换工具、模型压缩算法、前处理功能等。这些通用部分可以跨不同的 AI部署框架共享，从而减少了冗余开发和维护工作，同时确保了一致性。2.多硬件支持：AI 融合部署框架具有广泛的硬件支持，包括但不限于：面向小米澎湃 OS 标准设备，可部署在手机、平板、汽车等高性能设备平台，支持CPU、GPU 和 NPU 等，以便在高算力平台实现高性能的模型推理。面向小米澎湃 OS 轻量设备，可部署在资源受限的嵌入式系统和物联网设备，包括嵌入式 CPU、DSP、GPU，甚至边缘 AI 处理器。针对小米澎湃 OS 轻量设备，AI 融合部署框架在保留核心框架和算子的基础上最大化优化了框架的空间占用，并对每一种异构硬件架构进行指令级算子优化，确保 AI 能力在这些平台上高效运行。3.动态硬件检测和智能选择：AI 融合部署框架的核心功能是在部署时动态检测当前硬件设备的状态。这包括 CPU、GPU、NPU、DSP 等硬件资源的可用性和性能。根据这些信息，框架可以智能地选择最适合的系统调度策略，以确保在特定硬件设备上获得最佳性能。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem76图形图像子系统是澎湃 OS 重要组成部分，作为系统与用户间最重要的交互界面。多年来小米持续在该领域进行重点投入，从底层根技术到用户体验进行深层拆解，在多个核心方向进行自研攻关，成功打造自研视效引擎、游戏图像渲染引擎等领先技术，整体体验处于行业领先水平。4.3图形子系统4.3.1子系统简介4.3.2子系统架构AnimationManagementAdaptiveUIFramworkMAMLDSLRTPhysicsCalculationAdaptiveWidgetIllustrationEngineCoreUIFramework图 4.3-1 图形子系统架构AnimationLoadBalanceAdaptiveDensitySystemVirtualRuntimeHyperUITurboAndroidUIPlatformMiGraphicMiRenderThreadMiPielineMiRenderEngineMiCompositionEngineDisplayHardwarePhysicsEngineMiFilamentMiMediaEngineMiVFXEngineConcurrentCompositionOpsManagerGraphicsManagerMiDisplayHALHWCSkiaMilinkOpenGL/VulkanEffectsEngineUnionRenderingHWUISurfaceFlingerMI-UIMIUIXFolmeMAML背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem774.3.3重点特性4.3.3.1视效引擎技术介绍视效技术是关乎系统体验最重要的因素之一，小米澎湃 OS 基于用户体验需求，结合多年技术沉淀打造视效引擎，在“系统 GUI 高效绘制”和“2D 和 3D 相融合的 GUI 特效绘制”两个方向取得长足的进展和较大的突破。关键技术1.系统级统一 UI 和动画框架：实现一次开发，多端适配的核心能力，随着应用窗口的变化，UI（布局与控件）不断的响应变化，动态适配不同类型的终端设备。通过响应式规范 定义不同终端设备的 UI 展现形态 通过响应式支撑框架，通知 MIUIX 控件/布局/业务做形态调整 通过响应式 控件/布局库，减少业务适配代码2.系统动效引擎：全局系统动效体系，动效稳定性和连续性全面领先，实现 2D 元素的3D 空间层级渲染，多种滤镜透视效果，还原真实空间玻璃质感。OpenGLES 后处理（充分利用 GPU 和 VPU 计算能力）基于已解码数据，通过 OpenGLES 进行特效处理，从而减少动画所需的运算量 倒播、无级变速、逐帧播放等等能力 定制化场景3.天气特效引擎：在体积云实时渲染领域，效果最好的是 Ray Marching 方法，它利用3D 噪声纹理（堆叠起来的 2D 纹理），搭配使用逐像素光线步进的方法进行实时立体云形状、亮度计算。澎湃 OS 利用体积云和光照特效，还原真实天气视觉渲染，2D文字和 3D 气象空间融合渲染。4.系统联合渲染：突破应用层级限制，实现真实空间光影渲染效果。设计 HWUI 新的渲染流程 联合渲染架构 离屏渲染并行加速，多层级 Layer 合并计算，高效完成空间计算绘制。渲染管线全链条优化 CPU/GPU 动态调度策略，针对模糊混色场景合理的分配硬件资源，保证模糊混色的实时渲染。设计新的合成策略 SurfaceFlinger 合成时，根据需要对指定的窗口做相应的渲染效果，针对不同的场景满足效果的同时不影响合成效率。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem785.自研图形绘制算法库 MiInk：全局平滑圆角算法，深度模糊算法，弥散投影算法。图 4.3-2 联合渲染技术架构RenderNode统一渲染控件背景模糊MIHWUI控件阴影渲染通道控件跨窗口模糊控件圆角MIGUIGUIHWUI原生窗口背景模糊原生窗口阴影原生窗口圆角窗口背景模糊HDR局部高亮窗口阴影窗口自身模糊窗口混色窗口隐私防护窗口渐变模糊跨窗口模糊窗口平滑圆角多屏并发合成UnionRendering原生控件阴影原生控件圆角原生渲染通道SurfaceflingerMISurfaceflinger4.3.3.2游戏图像渲染引擎技术介绍基于 Android 原生渲染架构，在 OpenGL 驱动层增加 wrapper，实现渲染指令的拦截和替换，通过对原有渲染逻辑的修改，达到优化游戏渲染负载，支持多种分辨率切换，提升画质等功能。技术架构背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem79图 4.3-3 游戏图像渲染引擎技术架构GTSDKRayTracingVulkanMAGTTGPA64 位生态推广软件插帧算法软件超分算法游戏 AIHDR硬件插帧（PW）硬件超分（PW）VRS自研或开源算法动态分辨率Shader 优化分辨率增强资源联合调度GLES 场景识别稳帧算法系统优化多线程渲染智能补帧纹理压缩GPU外置显示芯片智能推荐HW关键技术1.GPU 增效算法方案 自研超分/插帧算法 动态渲染分辨率。同性能的场景下，功耗优化 10%游戏渲染负载优化。通过对游戏原生 shader 进行优化，同性能场景下，功耗优化 5%游戏画质增强。大型游戏支持更高分辨率，画质体验更好2.自适应调度方案 创新自研动态稳帧技术，实现 CPU/GPU/DDR 联动降载 与第三方合作游戏厂商合作，推出自适应调度框架，满足实时降载需求，与游戏厂商实现联合调优3.平台调度优化方案 AI 负载预测，通过 GLES 实现游戏内主动场景识别（加载，团战，传送等），实现自动加速 联合硬件平台厂商实现芯片能效的整体调优4.生态推进与合作 支持 Vulkan 标准及推动提升 Vulkan 覆盖率，优化内容，实现降低游戏负载 与联盟推动 64 位游戏生态普及 自研 Kite Profiler Tool，支持多维度游戏性能数据实时抓取和分析背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem804.4网络子系统4.4.1子系统简介网络子系统是通信网络中的核心部分，在小米澎湃 OS 操作系统中，网络子系统由短距子系统和蜂窝子系统组成。它们在操作系统中扮演着至关重要的角色，负责数据的传输、接收和通信。短距子系统主要负责设备之间近距离的通信，例如 WiFi、蓝牙、UWB、NFC 等。这些技术通过空气以电波或光波的形式传递信息，覆盖范围相对较小，但可以非常高效地传输大量数据。它们常被用于无线耳机、个人电脑、智能手机和打印机等设备的连接，以及在智能家居和工业自动化等环境中的设备间通信。蜂窝子系统则负责远距离的通信，通过无线电信号在蜂窝网络中传输信息。常见的蜂窝网络包括 5G、4G、3G 和 2G 等。这类网络覆盖范围广，可容纳更多的设备同时通信，但数据传输速度相对较慢。它广泛应用于手机、平板电脑和移动设备等，为人们提供了无处不在的通信连接。在网络子系统中，短距和蜂窝子系统各自发挥优势，互相补充。短距子系统负责设备间高速、高效的通信，而蜂窝子系统则提供了更大范围的覆盖和稳定的连接。这样的组合使得网络子系统能够满足各种通信需求，从短距离的高清视频流到远距离的语音通话和数据传输，都能得到良好的支持。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem814.4.2子系统架构图 4.4-1 网络子系统整体架构信号网络服务协议能力服务平台能力服务无线硬件服务特色业务框架全球网络框架模块客制框架近距离通信框架通信共享框架蓝牙唤醒应用框架设备热更新框架设备管理插件框架低功耗设备感知框架NFC分享框架快连开放框架近距离自组网服务车机协同框架DK框架安全认证框架远程车控框架安全测距框架语音通信框架多媒体框架导航框架智能助理无线音频框架无线音额分享框架无线低延迟框架无线高清语音服务可穿戴一配件配置无线高湾音频服务5G 增强业务平台防伪基站服务通话安全服务虚拟卡eSIM服务应急通信服务5G切片服务5G新通话服务5G高精定位服务网络加速平台多网协同框架网络框架加速资源协同调度引挛网络加速K1T智能选网域名加速引擎通信传输引擎超级近场通信内核协议栈增强蜂寞低时延传输无线链路加速引擎蜂窝高可靠传输蜂窝网络智能调度蜂窝低功耗通信卫星定位通信框架高精度定位服务室内定位框架多维通信服务低功耗地理围栏专家诊断框架蜂窝端专家诊断蜂窝云策略推送无线自恢复系统蜂窝能力组件运营商定制组件蜂窝网络管理引擘信号预测服务手势识别服务业务场景感知服务信号线路识别服务随选覆盖识别服务运营专网识别服务边缘网络识别服务算法支撑链路评估算法弱网预测算法PPP算法RTK算法智能选网算法行为识别算法SMG算法实时防抖算法协议支撑快速发现协议配件配置协议账号同步协议身份认证协议极简快传安全测距协议安全解锁协议米家配置协议NativeApps蜂窝子系统无线子系统蓝牙子系统网络子系统定位导航子系统短距子系统UWB 子系统.小爱米家SIM 卡应用商店网络数据短彩妙享中心系统应用.客制业务游戏视频即时通信工具 SDK三方应用.国际虚商国内卫通运营商多通信技术融合应用应用层系统能力终端设备手机平板电视音响电脑手表路由器汽车广告牌、智能水表.IoT 外围Native Apps蜂窝基础通讯框架背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem82 全场景信号协同加速 四网协同、弱网优化、域名加速、资源协同调度、游戏加速、微信通话加速 超级近场、数据包聚合加速、文件互传、加速引擎、极简协议 蜂窝全覆盖通信：边缘网络优化、运营专网加速、随选覆盖感知 全景协作通信：通信共享、多网融合、全域通信 智慧蜂窝专家：弱信号预测、端云网络专家 增强泛 5G 通信：5G 高精定位、5G 切片、5G-XR、5G 新通话 极速客制 KIT 蜂窝能力组件、特色安全通信、全球运营商客制 无线数字音频 高音质：192KHZ(LHDC)，900Kbps 低延迟：55ms(LEA)，aptX(85ms)高清语音：32KHZ，16bit 音频分享：2 套 高清 TWS 播放 近距离通信 快连弹窗、米家配置、耳机自动切换、耳机流转、小米秒享、靠近发现、小米钱包 插件 OTA、配件固件 OTA、低功耗设备感知、近场(NFC)分享、近距离自组网 车机协同 数字车钥匙：无感开锁，无钥匙启动，钥匙分享，远程车控 CarWith：导航，多媒体，语音通信，智能助理认证 定位导航 地理围栏、高精度定位 卫星通信 短消息、通话、应急通信4.4.3重点特性4.4.3.1NetworkX技术介绍Network X 为短距通信领域网络加速的统称，主要包括协同加速引擎、智能选网、域名加速引擎等功能，为用户提供快速便捷的网络体验。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem83技术架构图 4.4-2 Network X 技术架构弱网预测算法实时防抖算法CAA 评估算法主/被动链路评估算法智能选网算法APFConnectivityServiceSocket 优先级多网协同（并发/辅助/冗余）双 WLANQEEQoENetworkKit游戏模式NetworkPolicyGROTSOGSOUDPTCPBIG 协议TCP/IP 协议栈eBPFNetFilterIP/ARP资源协同调度决策中心游戏加速网速测试优先级管理后台网络策略NetdeBPFiPtablestrafficipruleSmartDNSLibc/netlink/syscall/.SlaD零拷贝技术冗余加速极简快传协议QUIC加速引擎OSTRTPPHCKernelNetworkStatsService背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem84关键技术1.协同加速引擎(MatrixEngine)基于多网协同并发技术，高延迟降低 62%，最大并发带宽可达 7Gbps 实时链路质量评估引擎 网络实时防抖算法 链路并发/冗余加速引擎 传感器数据运动状态进行辅助识别2.智能选网(SmartLinkHandover)采用主动和被动网络探测方案，实时进行链路质量评估，进入离开范围进行精准识别 CCA 物理信道质量评估算法，精准环境拥堵和干扰信息评估，为决策中心提供依据 低延迟漫游，不同 SSID/不同密码 AP，芯片级低延迟无感漫游 跨子网 AP 间地址分配协议优化，加快网络配置速度 传感器数据运动状态等场景进行辅助识别3.网络资源协同调度(NetworkSynergyEngine)手机和路由间标准协议，路由可以依据手机发送给路由的数据优先级，设定路由发送给手机的数据优先级，保证延迟敏感数据包优先传输。在游戏、VOIP 场景可以提供更好的信道和网络竞争能力。根据应用服务进行分类，提高游戏/语音等关键业务优先级，并与路由器实时同步优先级协同工作。根据手机应用前后台进行分类，提高前台应用优先级，并限制后台带宽，并与路由器实时同步优先级协同工作。4.域名加速引擎(SmartDNS)多线程并发查询：加快查询速度 基于网络 ID 的 DNS 缓存，充分利用历史查询结果 连通性检测，剔除无法连接的 IP 地址，选择最快的结果 提升应用程序网络连接速度 20%避免双栈网络（IPv4 和 IPv6）返回的解析结果无法连接的问题5.内核协议栈增强(Data-PathPassthrough)内核 TCP 零拷贝技术，UDP 零拷贝技术 重点应用场景优化，下载管理、应用商店、小米互传、一键换机、SpeedTest、iPerf4.4.3.2NetworkKit技术介绍Network X 为短距通信领域网络加速的统称，主要包括协同加速引擎、智能选网、域名加速引擎等功能，为用户提供快速便捷的网络体验。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem85关键技术1.标准的框架 API Socket 级别的网络控制（网络优先级、网速、延迟等）更精准的业务场景检测 多网协同（并发、辅助、切换）能力2.提供标准网络协议框架加速 QEE:QUIC 系统级加速框架 OKHTTP/Netty 加速框架3.提供更准确的网络质量监控数据，比如：链路的质量参数（占空比、SNR、AMPDU 聚合程度，CCA 等）网络上下行统计数据（某个时间窗口内的上下行网络数据）图 4.4-3 Network Kit 技术架构BrowserVideo.AppbuildBydeveloperTrafficControlQoEGameModeQuicEnhanceLinkXHTTPEnhanceCellularSIM1Wi-Fi2.4GCellularSIM2AppStoreGame技术架构MSCSQoS.3PFrameworkAPIbyXiaomiFrameworkDevicelayerimplementedandexposedbyXiaomiDeviceWi-Fi5GSwitchConcurrencyDuplicateMultiLinkXAPPS背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem864.4.3.3无线网络自恢复系统技术介绍提供一套集网络质量监测、网络诊断、网络恢复、云修复、大数据于一体的无线网络自恢复系统，实现在用户端自动分析故障并自愈的功能，提升用户体验。并根据大数据监测，全周期监控产品质量。技术架构图 4.4-4 无线网络自恢复技术架构监测模块业务层NetworkStack帮助系统网络监测系统网络诊断系统网络恢复系统大数据及控制平台从服务器获取帮助文档TCP质量监测DNS质量监测链路状态诊断链路质量检测游戏延时监测邻居系统监测协议栈自动恢复手动恢复网络协议诊断链路质量诊断网络设定诊断信号质量诊断路由组网诊断DNS配置诊断网络连接诊断网络延迟诊断质量指标质量预警云修复云控制监测模块诊断模块恢复模块控制模块SocketWi-Fi 状态机Kernel 网络协议栈KernelConnsysHWWifiDriverWifiFirmwareSDK背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem87关键技术1.网络监测：监测网络质量指标，分析网络异常类型和原因；2.网络诊断：实现私有的网络诊断模块，精细化诊断故障；3.自恢复：根据异常类型，自动/手动执行定制的恢复策略；4.大数据：统计终端设备组网类型，故障类型，恢复成功率，游戏延时等；5.云修复：线上实时修复故障，无需升级 OTA。4.4.3.4超级近场通信技术介绍针对 Wi-Fi Direct 通信的业务场景和信道特征，优化协议参数，精简传输协议，自研网络旁路方案，自研极简协议 PHC 和 OSRTP。技术架构图 4.4-5 极简快传协议（PHC）技术架构场景管理TCPIP协议精简压缩TSO/LROA-MSDU帧聚合优化A-MPDUTCP/IP 协议栈网络接口驱动应用程序终端设备 A场景管理TCPIP协议精简压缩TSO/LROA-MSDU帧聚合优化A-MPDUTCP/IP 协议栈网络接口驱动应用程序终端设备 B背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem88图 4.4-6 极简快传协议（OSRTP）技术架构关键技术1.极简快传协议-PHC：PHC 协议(IP/TCP/UDP 精简），帧聚合优化，可以使功耗降低 5%2.极简快传协议-OSRTP：自研极简快传协议，吞吐提升 5%-15%，功耗降低 5%3.多连接高频宽(HBW)：160M 能力，MLO 能力，互传速率提升 50%4.CastBoost(MTK)：MCC 时隙动态优化，P2P 吞吐提升 8.91%，投屏场景 P2P时延降低 2%，双向时延降低 22y.6%5.直连连接速度优化(HDL)：W-HDL、B-HDL，直连速度提升 30%6.蓝牙加速引擎：互联互通蓝牙连接速度提升 50%以上，快连弹窗速度提升 20%以上PASSApplicationApplication直连简单快速可靠传输协议网络旁路用户态 SDKAF XDP socketAF XDP socketUserspacesocketstcegresstcingressNetworkStackKernelRedirectUMEM(内存共享)RUNBPFPROCBPFMAP网络旁路内核态实现TXNICRXTX网络旁路网卡实现Driver近场通信链路PASSApplicationApplication直连简单快速可靠传输协议网络旁路用户态 SDKAF XDP socketAF XDP socketUserspacesocketstcegresstcingressNetworkStackKernelRedirectUMEM(内存共享)RUNBPFPROCBPFMAP网络旁路内核态实现TXNICRXTX网络旁路网卡实现Driver背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem894.4.3.5数字车钥匙技术介绍小米数字钥匙基于 PKI 体系的非对称密钥架构，具有高安全、高隐私的特点。支持在线开通、离线开通两种方式，具有高度的灵活性。支持灵活的跨平台钥匙分享方案。支持蓝牙无感解闭锁，UWB 无感解闭锁，为用户带来丰富多样的选择。技术架构关键技术无钥匙进入，无钥匙启动，RKE，跨品牌钥匙分享，分享至穿戴。图 4.4-7 数字车钥匙技术架构设备管理密钥管理证书管理分层管理ICCOA钥匙管理CCC钥匙管理汽车厂商管理推送服务邮箱服务手机钱包车企APP1车企APP2车企APP3运动检测发现服务分享服务穿戴服务蓝牙测距服务UWB测距服务车控服务多车管理服务协议抽象层设备服务器应用服务设备服务器ICCOA数字钥匙协议CCC数字钥匙协议安全硬件TEEDigitalkeyTASecureElementDigitalkeyapplet背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem904.4.3.6高精定位技术介绍高精定位服务包含 RTK、PPP、基于机器学习的高精度定位算法，可用于高精度导航、运动健康以及各种位置服务的应用。技术架构关键技术1.PPP 技术基于高精度的卫星轨道和钟差数据，采用载波相位观测值，综合考量并采用误差模型对误差项进行精确的改正，进行精密定位解算。支持卫星播发和网络获取SSR 数据。2.基于深度机器学习的信号筛选算法，显著提高弱场环境下的定位精度。4.4.3.7无线音频服务技术介绍无线音频服务主要包含蓝牙无线高清音频、音频低延迟、高清语音通话、音频分享、助听器等行业最全面与领先的蓝牙编解码技术和协议支持，搭配无线音频接收终端和小米无线音频配件配置框架，全方位覆盖用户无线音频体验场景，从基础的蓝牙媒体音频和通话场景，进阶到高清无损音频、音频分享和助听无障碍领域。LocationFrameworkLocationAPPsLocationBasedServicesOSRSeverLocationEngineGNSSChipRTKAlgorithmMLAlgorithmPPPAlgorithmSSRSever图 4.4-8 高精定位技术架构背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem91技术架构图 4.4-9 无线音频服务整体技术架构LE AudioLE Audio HiresLADC HiresLosslessAptx Hires三方高清音频全链路高清音频音频传输增强引擎游戏低延迟自适应框架影院低延迟共存模式低延迟测试系统无线高清音频无线低延迟系统系统与三方应用Local SharingPublic SharingDual A2DPVolume Sync无线音频分享全链路高清语音SWB立体声录音三方高清语音无线高清语音MMA协议框架耳机/音箱设置小米生态配件配置三方配件配置音频流转可穿戴/配件配置ASHA助听HAP助听助听器配置架构APC蓝牙助听器硬件平合能力无线音频编解码框架蓝牙设置蓝牙插件系统 UI三方 APP小米云大数据服务无线音频可扩展框架超级蓝牙HighBandEnhancedPowerControlMultiAntenna数据并发接收增强常规编解码MiHires1HDCSeriesAotxSeries三方编解码语咅编解码应用层核心服务层底层硬件子系统背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem924.4.3.8蜂窝信号地图技术介绍利用海量的通讯大数据，基于小区维度，聚合终端现网的电话、数据、网络、短彩信异常事件的权重、频次、时间段，在云端通过 AI 决策树算法，实时生成全国各个基站小区质量评分。当前手机匹配异常基站小区，快速切换并驻留最优小区。技术架构整体技术方案：关键技术1.无线高清音频：小米领先支持 LHDC 高清音频 96K/192K 采样高清音频；领先支持新一代 LE AUDIO 蓝牙音频；并在积极布局三方无损和自研无损编解码方案。2.无线音频分享框架：支持传统蓝牙耳机 SBC 的音频分享方案；支持新一代 LE AUDIO Auracast 音频分享方案。3.蓝牙低延迟：蓝牙低延迟持续追求极致领先行业，已发布的几代 K76/L76/M75A 持续保持领先。4.蓝牙高清语音：率先支持 aptx-tws 32K 高清蓝牙语音方案；率先支持 LE Audio 32K高清语音方案。5.蓝牙助听器：率先发布支持 Google ASHA 助听器方案；支持 LE AUDIO HAP 助听器方案，关注听力障碍群体。6.可穿戴配件/配置框架：支持小米自研 MMA 协议，配件配置、音频自动流转算法，打造极致无线音频互联互通体验。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem93CLOUD图 4.4-10 蜂窝信号地图技术架构数据网络通话GPSWi-Fi基站Wi-Fi基站Wi-Fi基站Wi-Fi基站APPLICATION云控版本识别城市定位云控小区更新线路小区收集线路匹配线路重匹配地铁场景高铁场景数据策略信号地图预制库信号地图云控库FRAMEWORK栅格化小区线路拓扑信号围栏MODEMdubiouscelllistdatastallcelllistMQs质量定位导航智能网络调度坏小区规避触发卡顿监测小区切换亮屏检测信号强弱执行智能双卡智慧5G网络调度预加载恢复小区切换周期轮询关键技术1.基站定位技术：通过 GPS 与 Wi-Fi 定位技术采集用户的地理位置信息与扫描到的基站信息，对单个基站的多个 GPS 位置信息采用 DBSCAN 中心聚类方法提取到基站的定位信息，供上层使用。2.基站评分体系：对于 UE 侧发生的通话、数据、网络的异常行为进行采集、加工、清洗、过滤，提取部分区域的最大值，采用自有评分体系对单个基站的网络性能进行评估。3.栅格化小区：融合基站定位与基站评分多维数据源，采用二维空间索引技术将单个GPS 点位信息转换为二维空间中的栅格小区，对栅格小区进行评分，形成栅格化网络基础能力。4.线路小区采集：使用地图开放平台轨迹提取服务提取线路起终点信息，通过【位置与时间】标签，筛选出在特定时间内（如一个月之内）在特定高铁线路起始站坐标出现背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem944.4.3.9弱信号预测技术介绍基于实时小区参数和用户场景，通过小区学习实现对常用线路的蜂窝信号质量/数据质量的学习，并生成线路小区数据集；通过小区预测实现对未来小区的信号质量/数据质量的综合预测。在弱信号预测中，通过打通 AP 和 Modem 之间的链路，实现了更加多元更加精细的关键参数搜集。同时，将 Modem 底层参数与 AP 场景结合，实现基于用户场景的小区质量评判标准；预测过程将结合用户实时场景和学习结果，实现对下一小区的信号预测。技术架构过的用户的轨迹信息，并从该部分用户（量级为一万/日）的轨迹信息中提取设备当时连接的基站信息，最终仅将特定高铁线路沿线的基站信息传输到端侧。5.线路匹配算法：端侧将每个线路的所有小区信息提取到 bitmap 中，进入高铁模式后，顺序采集用户驻留小区，匹配 bitmap，匹配到具体线路后进行线路小区加载。APPLICATIONFRAMEWORK弱信号预测服务引擎场景识别算法参数搜集参数标准自适应MODEM底层参数监听异常参数识别周期性数据传输线路学习算法线路小区数据集起点终点识别小区智能更新小区质量评估算法智能启停算法线路预测算法场景识别算法数据搜集线路构建小区模型小区学习小区预测弱信号预测 L5 架构小区信息用户场景NAS信令RRC信令L2/L1参数图 4.4-11 弱信号预测技术架构背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem95关键技术1.预测下一小区的信号质量/数据质量。基于当前服务小区的信息，实时匹配线路，并对线路下一个小区的预测。支持应用注册相关服务。FRAMEWORK4.4.3.10智能网络调度技术介绍智能网络调度是指智能调度双卡上网能力（双卡并发/切换），解决主卡无服务/无法上网/上网过程中卡顿/下载慢/延时高等问题，通过动态建立双数据/动态选择双卡里面通讯质量最好的网络，来减少无网或网络环境差导致的数据卡顿，缩短下载时间，降低时延。通过监控网络能力/信号质量/设备状态/链路状态/业务场景/双卡资费套餐/开关状态/底层 Modem 推荐算法，智能切换双卡并发和切换的状态。技术架构APPLICATION网络能力信号质量动态更新MODEM双卡双通智能默认数据卡推荐坏小区规避设备状态链路状态大数据打点业务场景双卡资费套餐设备状态图 4.4-12 智能网络调度技术架构UI 控制智能切换状态发射资源共享优选数据卡评估策略双数据主卡副卡背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem96关键技术1.双卡无缝切换 正常情况：当一张卡信号不好，自动切换到另一张卡(中间过程:Telephony 断开一张卡的数据链路，然后发请求给 Modem 建立另一张卡的网络连接，Modem RRC 建立/PDP 激活，返回给 Telephony，Telephony 根据 Modem 携带参数重新建立路由）然后通知三方应用链路切换。优化情况：游戏时同时建立双链路，即形成 SIM1/SIM2 双链路共存，一路信号质量不好时自动切换到另一路（无中间过程），然后通知三方应用链路切换。2.智能调整并发和切换 监控双卡信号质量，智能决策并发/切换。动态场景推荐使用 SIM1 SIM2 的数据并发，双链路备份，提供可靠上网服务。静态场景推荐使用 SIM1/SIM2 智能协同，优选最优链路，提供最佳上网服务。4.4.3.11蜂窝通信共享技术介绍利用互联互通技术，将有通讯能力设备上的电话、短信、蜂窝数据能力无缝接力到无通讯能力的设备上。技术架构 通讯互联子系统 优点：代码精简、跨层传输少、高扩展、低耦合、无平台限制。效果：支持多设备多平台共享，可以实现信令消息同步几乎 零时延。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem97关键技术1.语音通话低延时接力 精简封装语音电话实时消息，并发传输 建立电话自组网传输通道 建立音频虚拟设备控制通道 实现 InCallUI 页面切换显示2.短信零延时接力 精简封装短信实时消息，并发传输 建立短信自组网传输通道 实现通知栏 Notification 消息显示3.蜂窝数据低功耗流转 精简封装蜂窝数据实时消息，并发传输 建立蜂窝数据自组网传输通道 重构蜂窝数据自组网传输通道 P2P 实现底层链路图 4.4-13 蜂窝通信共享技术架构系统库 HAL媒体库RIL二维图形引擎.系统库 HAL媒体库RIL二维图形引擎.手机应用层短信电话通知状态栏.应用层短信电话通知状态栏.PAD用户操作系统Audio 驱动Camera 驱动Display 驱动.Modem 调制解调器内核层Audio 驱动Camera 驱动Display 驱动.通讯互联子系统TelephonyRelay服务框架CallRadioSMS.自组网通道创建虚拟设备控制服务AudioCameraMedia.应用程序框架层通知管理器虚拟设备管理器虚拟设备管理器通讯互联子系统TelephonyRelay服务框架CallRadioSMS.自组网通道创建虚拟设备控制服务AudioCameraMedia.分布式软总线用户操作系统通知管理器虚拟设备管理器虚拟设备管理器分布式软总线背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem984.4.3.12智慧出行技术介绍智慧出行（蜂窝场景化定向提优）依托用户出行的特定场景（e.g 高铁、地铁等），通过快速感知用户痛点信号网络问题，结合用户设备状态，使用决策树算法在方案矩阵里寻找最优解，静默解决用户信号网络问题，持续改善用户出行的通讯体验。技术架构 5G 智能出行：地铁/高铁/郊野/机场/高速公路 高频弱场场景优化：电梯/地库/居民楼关键技术1.场景感知：结合网络转弯特征和 sensor 来动态识别不同场景（高铁、地铁、电梯、地库、机场等）2.小区优化：针对频繁乒乓的小区进行小区评估和打分，对驻留时间短信号质量差的坏小区进行规避优化；同时针对 datastall 引起的坏小区可实现快速惩罚和切换3.快速漫游/快速回网：针对海外场景可实现频点预置，可实现快速驻网；针对 2/3G/脱网场景可实现快速回网4.弱信号预测预加载：固定通勤线路上，可提前感知弱信号即将到来，提前做三方预加载或者降分辨率等相关优化措施，来提升用户体验图 4.4-14 智慧出行技术架构APPLICATIONFRAMEWORK应用类型场景感知网络特征设备状态用户习惯TCP 指标DNS 指标链路有效性误码率上行资源信号强度数据SIM 卡网络短信通话安全分层诊断业务建模决策树算法大数据统计决策弱信号预测MODEM多链路协同小区惩罚强制搜网SA 降级 LTELTE 重注册.背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem994.4.3.13信号智选引擎关键技术1.软硬融合算法 多天线软件方案，软硬融合，不同场景进行动态天线切换，提升上行和下行性能 射频增强软件方案，软硬融合，不同场景进行动态天线调谐，提升上行和下行性能2.手势识别辅助增强 基于 AI 模型，识别用户各种握姿 通过白名单机制，控制核心场景图 4.4-15 信号智选引擎技术架构技术介绍通过核心场景识别，核心参数输入，核心算法决策当前底层射频天线行为策略，提升基础信号能力。技术架构应用层VolteVONR游戏视频直播微信视频框架层RSRPSNRSensorWiFiCamera.驱动层天线切換夭线调谐射频通路切换发射功率控制名天线软件方案射频增强软件方案软硬融合算法MODEM层AI手势识别自名单机制手势识别算法弱网发射增强多模共存动态接收增强抗干扰方案基础信号增强.核心参数接口场景识别引擎优化策略背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem100 天线切换和调谐，优化核心场景信号3.基础信号增强 弱网发射增强，识别弱网，动态调整发射功率 动态接收增强，智能判别接收通路质量，动态切换接收通路 多模共存，识别多模共存场景，动态进行天线调谐 抗干扰方案，识别多种干扰场景，动态进行天线切换和天线调谐4.4.3.14双卡双通双数据技术介绍 随着移动通信技术的不断发展以及 5G 技术的普及，越来越多的用户选择 5G 的上网套餐。由于 5G 套餐资费贵、流量耗费快的特点，很多用户会选择大王卡，物联网卡这类流量卡，但是由于这类套餐往往都限制应用，用户在使用起来需要频繁切卡，为使用带来了很多的不便。双卡双通双数据模式依赖于底层 DSDA 能力，建立两条数据链路，对 tcp 连接建立两条 socket 通路，通过 iptables 技术将两条链路的数据包聚合；通过两张网卡发送相同的数据包，两个数据包竞速，先到达的数据包先被接收。最终达到应对复杂网络场景挑战，双管齐下，无惧断流。技术架构对于双卡用户，基于手机的 DSDA 能力，使用负载均衡相关技术对双卡的数据流量进行平衡。用户在复杂网络环境下，手机可根据当前的网络环境，自动调整两张 SIM 卡上的流量；针对流量卡这种特殊卡，手机也可以通过识别对应的 APP 选择合适流量卡进行上网。项目整体架构设计如下图所示。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem101关键技术1.副卡数据连接托管，增加 Android 双网卡的 bringup 以及对副卡的数据管理 nDDS 基本的 BringUp/TearDown 功能 nDDS 数据图标指示 nDDS 和双卡切换容错，按需快速重建 并发模式和主从模式的优先级设定2.双数据网络数据包融合，完成两张网卡的数据聚合，从而实现增大带宽的效果 双数据网络路由管理：通过 ip rule 对两张网卡上的数据流进行策略路由，将打 Mark的数据包路由到对应的网卡 双数据网络负载均衡：通过 iptables 技术，将服务端传到手机上的数据包按照一定的算法动态分配到两张网卡上，从而达到两个数据链路的负载均衡，增大带宽图 4.4-16 双卡双通双数据技术架构Framework层应用白名单通讯参数管理云控系统链路质量感知特殊网络评估智能网络选择流量统计ConnectivityService双卡网络托管副卡图标知识决策树中心优先级管理TelephonyMultiLinkProxyModem 层DSDAIMSSMSVOICEMMSApplication层直播场景短视频场景影音视频网页场景下载场景视频场景大流量游戏场景游戏Kernel层TCP/IP协议栈DataPath防火墙管理路由管理Netd流量统计SDK管理守护进程网卡驱动低时延通道网卡管理RILIPruleeBPFLTE/NRProtocol背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1024.5多媒体子系统4.5.1子系统简介多媒体子系统是澎湃 OS 的一个重要组成部分，是处理音频、视频、影像等多媒体数据的功能/服务集合，对外提供丰富的 API，使应用程序能够高效地处理音频、视频以及执行多媒体相关的任务。本子系统包括音频系统、视频系统、影像系统等诸多组件。音频系统是澎湃 OS 中负责音频流管理、音频设备管理、音频数据处理等功能的软件系统。视频系统是澎湃 OS 中负责视频播放、视频录制、硬件编解码、缩略图、媒体库、视频文件封装解析、视频后处理、视频转码等功能的模块。影像系统也是澎湃 OS 多媒体系统的重要组成部分，为用户提供诸如美颜、夜景、防抖等诸多影像功能。4.5.2子系统架构图 4.5-1 多媒体子系统架构音频策略服务音频渲染服视频录制与播放服务视频编解码服务相机拍照预览服务影音互联互通服务视频图像编辑服务系统能力层应用层多媒体播放器相机K 歌应用智能语音助理短视频应用录音机.设备层手机平板电视笔记本手表音箱耳机全链路高清音频实时耳返电影音效沉浸声个性化音频变声游戏声音增强.夜景拍照HDR拍照人像拍照美颜拍照视频防抖拍照双风格焦段控制.米音AI 智能音效视频超分算法3A 算法虚化算法AI 识别感知算法语音唤醒算法空间音频算法视频插帧算法HDR 算法夜景算法音箱视频HDR视频转码多屏统一色域视频插帧视频超分基础服务音频增强视频增强影像增强算法支撑背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1034.5.3重点特性技术介绍音频子系统是澎湃 OS 中负责音频流管理、音频设备管理、音频数据处理等功能的软件组合，可分为音频 API 层、服务层和硬件抽象层等核心部分。以下是音频子系统中主要组件，例如音频管理器、音频录制/音频播放，音频策略服务、音质音效等组件。澎湃 OS 音频在高品质音频、沉浸感、互通互联能力等方面进行了专项优化，为用户呈现极致音频体验。技术架构4.5.3.1音频系统图 4.5-2 音频系统架构框架层音频基础服务播放、录制、策略等基础服务音效增强引擎变声、电影音效、游戏声音增强后台音频监控引擎实施播放监控，优化系统功耗音频流转框架本地音频重定向、远程音频流转等增强组件基础组件抽象层及内核层ALSA 框架内核原生音频管理组件音频探测框架通过音频事件增强环境探测能力语音唤醒框架支持低功耗、多唤醒词唤醒DSP 音频接入框架实时耳返、超声等接入及运行澎湃 OS 音频框架背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem104关键技术1.高清音频播放：在澎湃 OS 中，对于扬声器/有线耳机场景，实现了全链路位深 32比特通路播放，使音频数据动态范围更大，精度更高，量化误差更小,噪声降低近30db，有效地还原了声音细节。图 4.5-3 高清音频播放框架播放类应用音频框架层框架层 32 比特适配音频硬件抽象层抽象层 32 比特适配DSP 处理器DSP 处理器 32 比特适配SMART PACODECCODEC32 比特优化多层级优化高清音频播放通过对音频系统各个层级进行优化实现了有线耳机/扬声器场景的全链路位深 32 比特播放通路背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1052.实时耳返：在开启 K 歌应用，开启 K 歌耳返，能让您实时听到自己的声音。相比于 K歌类应用自带耳返，澎湃 OS 实时耳返通路直接从 ADSP 环回，这样的设计有效地减少了音频延迟，给您极佳的返听体验。不仅如此，澎湃 OS 实时耳返还提供如下功能：实时调整声音大小。选择不同的混响效果，让您获得 KTV、剧场、音乐厅等不同的场景音效体验。图 4.5-4 实时耳返框架耳返类应用音频框架层音频硬件抽象层ADSPADSP耳机麦克风耳机听筒实时耳返通路音量实时调节多种混响效果应用自带耳返通路背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem106技术介绍视频系统是澎湃 OS 中负责视频播放、视频录制等功能的模块，具体功能如下：视频播放，视频录制，硬件编解码，媒体库，缩略图等通用视频场景和功能实现。视频文件封装，视频文件解析，视频转码等通用能力及定制。视频后处理，视频画质增强，杜比视界录制，杜比视界播放等定制服务和能力。HDR10，HEIF，P3 等特定功能的通用实现和定制。技术架构4.5.3.2视频系统图 4.5-5 视频系统架构接口层视频播放视频录制编解码器编解码能力视频能力杜比视界文件封装文件解析视频 DRM媒体库ROI转码应用层相机相册视频社交视频编辑视频工具箱.硬件支撑VPUCDSPEVACameraMDPGPU系统实现MediaPlayerMediaRecoderHEIF视频超分杜比视界转SDRP3MPEG4WriterMPEG4ExtractorCodec2.0视频插帧HLG 转杜比视界HDR10 MediaStoreMediaTranscoding缩略图轮廓增强HDR 转SDRROIEncode杜比视界录像杜比视界播放杜比视界编辑原生能力背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1072.全链路杜比视界 杜比视界录像，杜比视界播放，杜比视界编辑。杜比视界 metadata 生成、保存和解析。杜比视界编码、解码和显示画质。关键技术1.多屏统一色域-P3 编解码 提供全链路 P3 色域支持和 P3 编解码能力。相对于 bt 709，P3 录像视频支持的色域范围更广，色彩更丰富。投屏/短视频录制/社交分享场景/拍摄动态照片/相机录制等场景。解决手机画面流转至电视、pad 场景下色彩失真问题，最终实现任意屏幕（电视、车机、平板、电脑）投屏，色域一致。屏幕流转电视车机平板电脑视频录制手机CameraVideoRecoder/sdcard/dolby.mp4VideoEdit/sdcard/dolby.mp4VideoPlaybackDisplay全链路杜比视界相机输出HLGYUV杜比视界录制编码metadata生成杜比视界格式 mp4文件保存杜比视界metadata解析生成和编解码杜比视界格式 mp4 文件保存杜比视界播放解码metadata合成杜比视界画质显示相机录像动态照片短视频录制社交分享图 4.5-6 多屏同色和 P3 编解码场景示意图 4.5-7 全链路杜比视界架构背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1083.视频后处理 视频超分 视频分辨率长和宽分别放大两倍或三倍后再输出显示 更好适配屏幕分辨率，视频播放更清晰 视频插帧 基于硬件电路实现视频帧率提升两倍 更好地匹配屏幕刷新率，视频播放更流畅 轮廓增强 基于硬件电路提升视频对比度、亮度和色度 视频播放画质更鲜艳明亮 图 4.5-8 视频后处理流程视频后处理视频超分视频插帧视频源轮廓增强视频解码视频解码屏幕显示技术介绍影像大脑是小米在软件方面的一大突破功能，通过重写相机架构，将软硬件能力整合重建，可以为小米手机相机带来全方面的快。目前影像大脑升级到 2.0 阶段，包括：生态引擎、融合光学、仿生感知、色彩引擎、加速引擎以及 ISP 等。4.5.3.3影像大脑背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem109关键技术打造三大核心特性：1.快拍相机：自研加速引擎，启动、对焦、抓拍全流程提速，定格能力比肩专业相机。多项核心指标得到显著提升：启动速度： 16%对焦速度： 26%抓拍速度： 14%2.万物追焦2.0：惊鸟鸣虫，这次也能锁定；新增猫狗眼、昆虫、鸟类等智能追焦对象，出镜自动找回目标，真正万物可追。3.超色彩影像：让色彩，获得真实表达。通过 AI 学习照片色彩与光影关系，搭配全链路 P3 广色域，高保真记录颜色层次与画面细节，还原你眼中的真实质感。小米影像大脑 2.0色彩引擎拟合人类感知以人脑仿生的方式呈现真实色彩技术架构融合光学综合光学信息空间融合，时间融合、光影融合仿生感知AI 意图识别 针对场景优化图像加速引擎并行协同 提升拍照流程流畅度跨应用支持三方 APP 可调用更多能力图 4.5-9 影像大脑架构画质增强感知色彩瞬间抓拍智能场景优化生态引擎背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1104.6硬件服务子系统4.6.1子系统简介硬件服务子系统是操作系统重要组成部分，作为硬件的抽象，为操作系统提供底层硬件服务支撑。多年来小米持续在该领域进行重点投入，从底层根技术到用户体验进行深层拆解，在多个核心方向进行自研攻关，成功打造视觉服务引擎、输入外设系统服务、智能感知服务、智慧充电引擎及振感框架等领先技术，整体体验处于行业领先水平。4.6.2子系统架构图 4.6-1 硬件服务子系统架构应用层相册视频阅读护眼.硬件服务子系统框架层视觉服务引擎输入外设系统服务亮度控制服务生物特征识别服务智能感知服务智慧充电服务振感服务健康服务.基础框架图像数据处理框架调光框架触控框架传感器基础框架充电框架GPU.背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1114.6.3重点特性技术介绍显示模块，是手机系统中非常重要的部分，它决定了手机与用户交互的效率与质感。应用于显示部分的视觉服务引擎，是基于图形渲染技术，通过对亮度，色彩、帧率等方面的精细控制，融合了机器学习技术和硬件定制，致力于打造出流畅、专业的视觉体验的解决方案。小米的视觉服务引擎，得益于在显示架构中，从上到下的自研算法的使用，以及横向软硬件数据的拉通，具备了高度定制，灵活应用的能力。它采用了机器学习技术，深度融合各类软硬件数据，结合专业定制与校准的显示模组，能够智能的地适应各种复杂的环境和需求，自动优化图像处理过程，实现更为出色的画面效果。形成了以采用高效算法的图形渲染引擎为基础，以专业增强游戏视频场景体验为特长，能搭配专业定制显示硬件，兼顾多种视觉保护方案为特点的整体系统显示解决方案。小米视觉服务引擎的应用，可以为用户带来更为安全，优质、高效、个性化的视觉享受和操作体验，满足人们对美的追求，为手机与用户的交互带来新的无限可能。技术架构小米显示总体框架中，自研的算法和驱动融合在了从 APP 端到硬件驱动的整个过程中。自研算的融入，一方面专门针对手机硬件的特点进行优化，实现了更精确的色彩还原、更流畅的动画效果和更快的响应速度。同时，配合上层设计，提高了系统的稳定性和兼容性，形成特有的视觉服务引擎体系，还能提供更好的安全性和隐私保护。让用户在观看视频、玩游戏或浏览网页时享受到更清晰、更细腻的图像，更流畅的操作手感，更小的能量消耗，以及更安全的使用体验。4.6.3.1视觉服务引擎背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem112关键技术1.图形渲染引擎：手机图形渲染功能作为手机系统的重要组成部分，通过 GPU、图形API 和驱动程序的协同工作，为手机系统的渲染场景加速提供了底层加速支撑。它不仅能够实现高质量的图像渲染和动画效果，呈现逼真的光影效果和细腻的纹理细节，还能提升用户界面的交互体验、多媒体内容的展示以及虚拟现实等领域的表现，为用户带来更加流畅、生动和真实的手机使用体验。应用层设置系统 UI视频工具箱游戏工貝箱框架层小米显示功能管理服务基础框架层小米渲染引擎3D 引擎小米图层管理服务显示功能框架服务硬件抽象架层小米硬件叠图框架小米显示硬件抽象服务内核层小米显示硬件驱动框架小米显示硬件驱动硬件层DPUGPU屏幕图 4.6-2 视觉服务引擎架构背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1132.游戏视频增强：游戏和视频是手机重要的应用场景，在游戏视频引擎中，融合了超动态显示，memc 功能，超帧，画质增强，环境适应等技术，让用户在不同的环境下，不同的内容中，都能有更真实更丰富更流畅的视觉体验。除了上述技术的融合外，游戏视频引擎还加强了整合各组件的资源调度，避免卡顿和掉帧现象的发生，实现全局的性能加速，带来更流畅的操作体验。3.专业显示：在系统的默认显示模式中，开启色彩管理功能，在桌面，相册等原生应用app 端全面支持广色域显示，系统级实现色彩的准确还原。硬件端采用自研颜色校准算法，参考基于人眼仿生标准观测者模型 CIE2015 标准调校屏幕，不但让每个手机屏幕都获得了极致精确的色准，更实现了让不同设备，不同光谱的屏幕，显示出相同颜色，成功解决了色彩准确性和跨屏色彩一致性难题。游戏视频引擎画质增强不同滤镜可选暗态增强分辨率可调动态显示支持 MEMC刷新率根据内容动态调节环境感知获取环境信息动态调整性能策略全局加速资源调度优化全响应加速防卡顿防掉帧图 4.6-3 游戏视频引擎图 4.6-4 专业显示专业显示色彩管理默认开启原生 app 适配多屏同色CIE2015 曲线校准基于人眼仿生模型，跨设备跨材质多屏同色显示极致色准自研校准算法屏幕单片校准背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1144.视觉保护：视觉保护也是视觉服务引擎的一个重要方向。目前已经包含有经典护眼、节律护眼、纸质护眼、防闪烁调光、真彩显示和深色模式等多种功能的应用，可以为不同使用习惯的用户提供多种选择，在不同方面降低可能的物理损害，缓解用眼疲劳，提供更加舒适的视觉享受。视觉保护经典护眼节律护眼纸质护眼护眼模式防闪烁（DC）调光真彩显示深色模式图 4.6-5 视觉保护背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem115技术介绍输入外设系统服务基于 输入外设设备（触控，压感，手写键盘等），融合机器学习技术，打造准确流畅的输入操控体验。技术架构4.6.3.2输入外设系统服务应用层触控工貝边缘抑制游戏引擎输入法框架层触控功能服务触控监控服务Android输入框架基础框架层手写笔算法触控报点算法触控感知交互触控 AI内核层小米触控驱动框架Linux 输入驱动小米触控驱动硬件层触控 ICSensorHub高速总线图 4.6-6 输入外设系统架构背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1162.手写笔引擎（PencilEngine）：手写笔相关应用算法技术，包括手写笔笔迹预测算法、文字识别算法和一笔成型算法等，并负责 Pen Engine 开发，将算法提供接口给三方应用，来提高三方应用性能。3.算法融合：触控模块充分利用其他器件提升触控体验，算法融合触控，显示，指纹，传感器数据，实现握姿检测、姿态检测、口袋模式等，实现触控防误触，灵敏度增强，进一步提升指纹解锁体验和触控跟手性能。关键技术1.自研触控框架（TouchHostProcess）：自研触控框架将底层硬件和算法实现分层，将触控原始信号的处理上移至平台端，实现更强大的报点速率，更平滑的轨迹预测，功耗与性能也获得更加优异的平衡点。同时在框架端实现各种触控算法的接入和扩展，其中触控算法包含对 Touch IC 电容信号滤波处理算法，Peak 合并算法，多点追踪匹配算法，平滑滤波算法以及坐标计算等，同时也专注于用户体验功能开发，如超高灵敏度触摸，智能防误触，湿手触控等。自研触控框架高阶降噪超高分辨率动态报点率跟手预测高灵敏度湿手触控图 4.6-7 自研触控框架手写笔引擎预测算法文字识别一笔成型绘制引擎图 4.6-8 手写笔引擎背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem117 图 4.6-9 边缘防误触功能技术介绍智能感知服务基于传感器外设设备（环境光传感器，加速度计传感器，陀螺仪，地磁传感器，距离传感器，TOF，电容传感器，气压计，温湿度传感器、低功耗相机等），在传感器融合算法中引入机器学习技术，为 OS 使用者提供丰富的定制化功能以及原始传感器数据做三方客制化的开发。同时，为 OS 提供了多个相对独立的功能模块，服务于操作系统的基础体验。技术架构4.6.3.3智能感知服务背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem118应用层自动亮度调节系统特色接入功能三方应用的支持图 4.6-10 智能感知服务架构传感器服务层AOSP 原生传感器服务接口低功耗相机服务接口运动类数据服务接口传感器框架层AOSP 原生传感器接入框架小米自研传感器服务框架屏下光感服务框架硬件层传感器协处理器子系统框架层传感器硬件计步器算法手势类算法运动状态检测算法防误触算法低功耗相机检测算法关键技术1.自动亮度相关的特有技术：360 光感/色温检测技术 基于环境光传感器和运动类传感器的光源无损还原技术 基于运动状态检测和 AON 场景识别的智能调光技术 自动亮度调光策略及自动亮度客制化聚类曲线技术2.基于传感器运动和环境检测的防误触技术：基于使用者特定动作检测的防误触算法技术 基于多传感器数据融合加机器学习模型的防误触算法技术3.基于硬件传感器衍生的算法技术：计步器服务 运动状态检测（步行、骑行、乘车、地铁、高铁、乘机等）服务 手持、左右手手持姿态检测 快捷手势类算法（背部敲击、空中签名等）技术 常驻地磁校准算法技术背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem119技术介绍通过一系列智慧算法策略以及和上层用户交互、用户习惯学习，优化用户低电、导航、户外、重载等场景下的充电速度温升平衡或电池循环次数，提高充电体验和延长电池寿命，以提升小米产品的竞争力。技术架构4.6.3.4智慧充电引擎4.基于低功耗相机的特有场景检测技术：人脸识别技术 基于人脸方向的智能旋屏技术 基于低功耗相机的眩光场景检测技术 可支持功能扩展和定制的低功耗相机软件架构5.基于互联互通的传感器数据共享技术:支持小米澎湃 OS 设备的传感器数据互传技术6.屏下环境光传感器的特有技术：不同芯片平台共用的屏下光感算法接口及软件架构 基于机器学习方式实现的显示内容实施转化为环境光亮度影响技术应用层充电加速电池保护重载智充接口层特征反馈服务目标解析服务逻辑层充电调节算法电池健康算法协议控制策略硬件层澎湃充电芯片澎湃电池管理芯片小米充电套装充电卫士智慧充电引擎架构图图 4.6-11 智慧充电引擎架构背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem120关键技术1.导航断充算法：打开“智能断充保护”功能后，可学习常用的地图软件使用导航功能习惯，静默通知用户断充保护生效，解决长时间导航和充电并发场景下电池过饱和时衰减加快的痛点问题。（注：不同产品、软件版本，在功能、界面上可能存在差异，请以产品实际情况为准）2.低电疾充策略：打开“低电疾充”功能后，手机在较低电量状态下连接原装充电器进行息屏充电时，会启动加速充电，满足用户低电量快速补电的较强需求，降低低电焦虑。此功能生效时，手机温度可能略有升高。（注：不同产品、软件版本，在功能、界面上可能存在差异，请以产品实际情况为准）图 4.6-12 电池保护功能背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem121图 4.6-13 更多电池功能3.户外充电模式：当充电场景智能侦测技术识别到用户在陌生环境或户外进行充电时，会针对专用充电端口类型进行定向电流提升，解决户外用户使用共享充电宝充电缓慢并且收费较贵的痛点问题。4.重载智充：凭靠小米澎湃快充芯片的高效率优势，在用户边充电边重载使用手机场景下，通过小米自研多模提效算法进行快充芯片工作模式的自适应动态切换，实现同等充电电流下的手机温升降低约 1或者同等温升下充电速度的小幅提升。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem122技术介绍振感框架是一套振动波形的生成框架，可以通过参数或者 HE 格式为你的线性马达机器定制出丰富的振动效果。技术架构4.6.3.5振感框架应用层基础振动能力扩展振动能力声音振动耦合自定义振动HAL 层振动特性.服务层基础振动支持自定义振动支持亮度控制服务.调试指令支持声音振动耦合支持无级振动服务.图 4.6-14 振感框架架构关键技术1.波形采样率提升：波形算法优化，提升波形采样点，增加到 16 个甚至更多。可以提升波形的材质感和纹理感。2.混播算法：振动事件时间可以重合，重合的两个振动事件以混播的方式振动。在同一时间点同时发生两个振动事件，混播可以同时实现这两个层次的感受。3.频率与强度范围：强度与频率范围为-50100。4.更多 Pattern 支持：HE 文件支持不限数量的 Pattern，一个 HE 文件可以配合一个完整长视频振动。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem123技术介绍指纹服务基于多种类型的指纹传感器（电容指纹、屏下光学指纹、屏下超声波指纹等），在保证用户设备安全的基础上为用户提供更便捷、快速的解锁服务。技术架构4.6.3.6指纹服务核心框架层应用层关键技术1.安全：基于生物认证技术，在 TEE 安全环境中进行指纹信息的采集、加密存储和匹配处理，具备支付级安全等级。2.快速：融合机器学习技术，快速进行指纹识别匹配，并与小米澎湃 OS 输入外设系统服务、视觉服务引擎紧密协作，为用户提供快速便捷的指纹解锁体验。MiTEE指纹特征提取模板加密存储AI 防伪算法快速匹配算法系统与三方应用系统锁屏系统设置应用锁三方应用图 4.6-15 指纹架构硬件指纹传感器小米指纹引擎Kernel指纹电源管理生物识别框架人脸服务框架指纹服务框架.底层服务硬件小米指纹框架背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1244.7编译器与运行时子系统4.7.1子系统简介编译器与运行时子系统的职责是可依据目标产品的不同，实现可大可小的小米澎湃 OS，不仅支持子系统裁剪、模块裁剪，还实现了模块可按需选择不同类型的编译器与运行时，将不同模块的源代码（如 C、C 、Java、TS 等）转换成机器代码，并针对不同编程语言提供特定的、可靠的、高效的运行时环境。手机平板电视座舱音箱HyperOS源码仓库A 子系统编译A 子系统稳定接口层A 子系统模块 跨端应用模块编译 安卓应用模块编译 轻量应用模块编译 4.7.2子系统架构编译系统是基于 Ninja 和 Bazel 的现代化编译系统，设计了统一的产品配置模版，支持各种不同品类的产品配置其子系统及模块，编译时按配置文件自动选择正确的代码并编译目标系统，编译过程中采用了小米自研的并行编译技术、远程缓存算法，比传统的安卓构建编译快 5 倍。B 子系统编译C 子系统编译图 4.7-1 编译器与运行时子系统技术架构远程编译服务集群兼容性校验编译加速兼容性校验编译加速兼容性校验编译加谏背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem125流程主要包括以下步骤：1.配置解析：解析待编译的配置文件，加载相关配置，计算依赖关系。2.子系统动态规划：根据解析的配置（如子系统、编译类型），动态选择目标编译工具链和编译选项，裁剪不必要的子系统。3.子系统兼容性检查：启动预编译检查工具，对依赖的子系统及其稳定接口层的兼容性信息进行检查，包括接口名称、参数、版本等。4.模块动态规划：解析模块配置，裁剪不必要的模块，从远程服务器下载预编译缓存、编译优化配置。5.子系统模块编译：根据目标模块调用对应工具链进行源码编译，在所有模块完成编后进行子系统构建。6.系统构建：并行完成各子系统编译构建任务，合并目标文件，构建系统。4.7.3重点特性技术介绍采用 AOT 编译策略进行安卓应用模块编译，对其部分或全部代码从字节码形式编译成本机机器码，以便在 ART 运行时获得更好的执行性能和更快的启动时间。使用预热技术优化 AOT 编译过程，对超大内存设备进行了指令集优化、指令调度、寄存器分配和内存回收策略优化，对 ART 运行时电源消耗进行优化。技术架构4.7.3.1安卓应用编译与运行时常量折叠內联优化资源裁切无效代码消除布局展开应用编译预编译热点并发编译资源预处理元信息预处理内存布局索引应用安装大内存 GC 优化标准 GC 优化并发垃圾回收高频代码预热高频资源预读应用运行闲时预编译增量资源合并增量信息合并插件预编译应用更新图 4.7-2 安卓应用编译与运行时架构背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem126关键技术1.预编译云端热点：分析安卓应用执行数据，如热点代码，预先在云平台为每一款应用生成一个高效、稳定的代码编译配置文件，在应用安装期间，会对配置文件中的方法执行预先编译(AOT)，应用更新后，结合应用新版本与热点代码在云端持续分析并更新编译配置文件，设备闲时进行持续优化。2.分层分级垃圾回收器：针对不同硬件资源的设备优化了最合适的垃圾回收器，优化并发标记和并发清理的策略，在标记阶段，使用并发线程来标记存活对象，而应用程序可以继续执行，减少了垃圾回收对应用程序的停顿时间。在清理阶段，同样使用并发线程来清理未被标记的对象，并回收内存空间。使用读屏障（Read Barrier）技术在并发执行时确保引用的一致性。技术介绍跨端应用采用 UX 编程语言，拥有现代化编程语言特性，特点是更好的代码结构化与绑定式语法，不仅对开发者友好，也易于进行运行时优化，获得更好的运行性能。技术架构4.7.3.2跨端应用编译与运行时图 4.7-3 跨端应用编译与运行时架构TemplateStyleScriptPageRenderViewModleStylesWidgetWidgetWidgetStyleStyleStyleStylesManagerFSMComponentfComponentfComponentfStylesViewModleData.EventListenerCompileRuntimeUXNative背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem127 配置解析：解析项目中的配置文件，解析程序名称、版本、包名、页面配置、服务配置等信息。依赖分析：根据代码中引用关系，进行各个代码模块的依赖关系分析。语法转换：对 UX 进行语法转换，生成中间代码。代码编译：对中间代码进行转换，生成二进制文件。应用打包：获取应用的资源及二进制文件等产物，根据应用配置，使用用户签名进行应用打包。关键技术1.预编译机器码：跨端编译工具链支持在编译时对目标设备进行代码优化，将代码提前转换为机器码，消除了运行时的解析和编译过程，从而提高了执行速度和性能。图 4.7-4 编译过程图 4.7-5 编译工具链UX解析ast 树错误检查应用生成优化生成视频播放转换源码编译可选：编译二进制生成应用手机端IoT 设备端安装执行编译运行时背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem128关键技术1.运行高效率：编译器在编译 TS 源码时，会保留语言的类型信息，在编译期间尽量确定对象内存布局，进行静态化编译，以提高运行效率。另外，支持 AOT 技术，可以利用字节码中的类型信息，将 wasm 文件编译为机器码，使 TS 程序有着接近 Native程序的运行性能。2.开发高效性：保留了 TS 语言的动态特性，极大提升了前端开发人员的开发效率。对编译期无法确定的动态性，在运行时动态构建对象内存布局，并采用指令 cache 技术提高运行效率。技术介绍跨端应用采用 UX 编程语言，拥有现代化编程语言特性，特点是更好的代码结构化与绑定式语法，不仅对开发者友好，也易于进行运行时优化，获得更好的运行性能。技术架构4.7.3.3轻量应用编译与运行时图 4.7-6 轻量应用编译与运行时架构tsfiletscapiAstprocesSemanitcBinaryenapiwasm背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1294.8安全子系统4.8.1子系统简介小米澎湃 OS 安全子系统结合软硬件安全技术，在硬件层、内核层、框架层和应用层使用不同的安全技术，对设备提供端到端的完整链路保护，在底层保障用户的数据安全和隐私，并在应用层为用户提供许多隐私安全特性。硬件安全和可信执行环境：小米澎湃 OS 的安全是基于一体化软硬件的平台，使用隔离的硬件资源结合可信执行环境构建整个系统的安全基石。系统安全：基于信任根建立完整的安全启动链，确保系统可信，保护内核及网络通信，对设备进行管理控制，安全高效地更新系统软件。身份认证与数据安全：确保正确的用户才可以访问设备。基于 小米澎湃 OS 设计的数据保护架构，在保障用户数据安全的同时，也提升了 小米澎湃 OS 的易用性和便捷性。应用安全：小米澎湃 OS 确保应用的安全运行及用户数据的安全性，同时也对各种恶意软件进行治理，保证用户的良好体验。安全开放框架：小米澎湃 OS 开放各种隐私安全能力，与和各方共建良好的生态，共同保护用户的隐私安全。安全认证与隐私政策：小米在信息安全与隐私保护方面的总体原则、组织架构、安全与隐私认证、隐私政策以及持续改进机制。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1304.8.2子系统架构4.8.3重点特性4.8.3.1.1硬件唯一密钥（HUK）HUK（Hardware Unique Key，设备唯一密钥）出厂前被固化在设备芯片上，每台设备的 HUK 都唯一且不可篡改，仅可以通过硬件加密引擎访问 HUK。HUK 为系统的锁屏密码、文件系统加密等功能所使用的密钥提供了唯一性保障。4.8.3.1硬件安全和可信执行环境设备可信服务安全开放框架系统安全检测服务硬件级安全保护照明弹拦截网防追踪应用锁手机分身病毒扫描.锁屏密码生物识别密钥管理文件级加密安全存储安全擦除安全启动安全网络协议伪基站短信识别Wi-Fi 探头保护网络安全内核安全系统软件更新查找设备手机锁定/解锁策略第二空间设备控制移动设备管理应用安全身份认证和数据安全系统安全安全芯片(eSE)硬件唯一密钥(HUK)硬件加解密引擎TrustZone硬件安全可信执行环境MiTEE图 4.8-1 安全子系统整体框架4.8.3.1.2硬件加解密引擎加密和解密通常需要极大的计算能力。对于移动设备来说，计算速度、节能和安全性至关重要。通过高性能硬件加解密引擎，小米澎湃 OS 确保设备在保证安全强度的同时不对性能、续航等造成影响。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1314.8.3.1.3安全芯片（eSE）eSE(Embedded Secure Element)是一颗具备安全计算和安全存储能力的独立安全芯片，安全等级高，即使设备系统被 ROOT、硬件被飞线，eSE 的存储数据依然可信。eSE 的安全特性不依赖网络，可实现脱机认证和交易，被广泛运用于金融、支付和身份认证等行业。基于 eSE 安全芯片，可以在很多生活场景中使用小米澎湃 OS 的设备：OMAPIFrameworkDigitalKeyFrameworkSecureElementServiceNFCServiceBluetoothServiceNFCFrameworkBluetoothFrameworkHyperosFrameworkTrusted Service Management ClientService Provider ApplicationTEETAISDGlobalPlatform2.2SSD公交卡SSD银行卡CASD公交卡SSD门卡SSD车钥匙ARA-MeSENFCBluetoothSPII2C图 4.8-2 eSE 整体架构业务名称使用场景数字车钥匙使用 NFC、蓝牙、UWB 等技术连接手机和车，实现车辆的开门、启动等功能交通卡公交上下车、地铁出入站刷卡、线上充值、换机移卡Mi Pay商户 NFC 刷卡交易、线下商户主被扫二维码交易、线上 app 应用内交易门卡小区门禁 NFC 刷卡、办公楼宇 NFC 刷卡、智能门锁卡、换机移卡校园卡校园食堂、门禁、图书借阅等 NFC 刷卡eID深圳部分酒店、机场身份识别数字人民币商户 NFC 刷卡交易背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1324.8.3.1.5TEE（TrustedExecutionEnvironment）TEE 访问的软硬件资源是与用户操作系统隔离的。TEE 提供了可信应用的安全执行环境，同时也保护可信应用的资源和数据的保密性、完整性及访问权限。TEE 内部包含了密钥管理、密码算法、安全存储、安全时钟、可信 UI 等安全服务。在 TEE 中，每个可信应用是相互隔离的，在未授权的情况下也不能相互访问。小米澎湃 OS 基于不同的硬件环境使用不同的 TEE 方案，自研了 MiTEE 系统，同时兼容了标准高性能设备和轻量设备，保证了安全性和灵活性。ClientApplicationTEEFunctionalAPITEEClientAPILinux/VelakernelTrustedApplicationTEEOSFrameworkMiTEEkernelTrustedApplicationRuntime用户操作系统TEE 安全系统SecureCPUSecureDisplaySecureMemoryCryptoEngineSecureStorage.Hardware Platform4.8.3.1.4设备证明为了确保设备的可信度，小米给设备预装了证书，可以唯一识别每台设备。证书的公钥集中存储在小米的服务器中。在需要更高安全级别的场景中，应用程序可以向小米服务器发送认证请求，以验证设备的真实性。图 4.8-3 TEE 整体框架背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1334.8.3.2系统安全4.8.3.2.1安全启动安全启动是在系统启动过程中，通过公钥验证程序或数据的签名，确保启动文件或程序的完整和可信，以防止在启动过程中加载并运行了未经授权的程序。在安全启动机制下，所有启动文件（如：启动引导程序、内核镜像、基带固件）均需先通过签名校验才被允许加载运行，在启动过程的任何阶段，如果签名验证失败，则启动过程会被终止。片内引导程序（ROM SoC Bootloader）是在芯片制造时被写入芯片内部只读 ROM 中的一段引导程序，出厂后无法修改，设备上电后最先执行此代码。设备上电后，片内引导程序执行基本的系统初始化，从存储芯片中加载一级引导程序，并利用保存在主芯片内部Fuse只读空间的公钥对一级引导程序镜像的数字签名进行校验，验证成功后运行一级引导程序。随后，一级引导程序加载、校验和执行安全 OS 镜像，安全 OS 运行起来后，由安全 OS 和一级引导程序共同校验、加载和执行二级引导程序。以此类推，直到整个系统启动完成，从而保证启动过程的信任链传递，防止未授权程序被恶意加载运行。小米澎湃 OS 系统的启动过程支持 VB(Verified Boot)功能。在设备启动过程中，从受硬件保护的信任根到引导加载程序，再到启动分区和其他已验证分区（包括 system、vendor 和可选的 OEM 分区），无论是在哪个阶段，都会在进入下一个阶段之前验证代码可靠且没有任何已知的安全缺陷之后才会执行。VB 有助于防止永久驻留的 Rootkit 恶意软件持有 ROOT 权限危害设备，可确保设备在启动过程中的安全性。小米澎湃 OS 用户系统verification and loadingKernelVerifiedBootLevelIIBootloaderBootROMverification and loadingloadingLevelIBootloaderloading安全 OSverificationloadingSecureBoot图 4.8-4 HyperOS 安全引导过程1.当设备通电时，PC 指针指向片内引导程序的地址，开始执行片内引导程序。2.片内引导程序从外部存储设备加载并验证一级 bootloader，然后跳转执行。3.一级bootloader加载安全OS映像文件。4.一级bootloader加载二级bootloader，由安全 os 验证其完整性。5.二级 bootloader 验证并加载内核。6.内核进一步验证并加载 HyperOS 主用户系统。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1344.8.3.2.2内核安全小米澎湃 OS 支持原生的 SELinux 特性，对系统中的进程、文件、目录等所有资源的操作均实施强制访问控制，任何进程在 SELinux 系统中执行操作之前都必须先在安全策略配置文件中赋予权限，而控制访问权限的策略配置文件在设备启动过程中会被保护起来，无法被第三方更改。通过 SELinux，小米澎湃 OS 可以阻止系统进程读写受保护的数据，还可以阻止系统进程绕过内核的安全机制或攻击其他进程。小米澎湃 OS 支持 KASLR（Kernel Address Space Layout Randomization，内核地址空间布局随机化），在每次系统启动时，小米澎湃 OS 都对内核的地址空间进行随机布局，避免使用固定的内核的地址空间布局，提升代码重用攻击的难度，降低被许多复杂攻击的可能性。小米澎湃 OS 还支持内核运行时保护机制，可以对内核及驱动模块的代码段、数据段以及关键动态数据进行保护，进一步提升了系统内核的安全性。4.8.3.2.3系统软件更新小米澎湃 OS 支持通过 OTA(Over The Air)方式更新系统软件，实现了安全、高效的系统升级管理。系统软件更新前，系统更新程序验证 OTA 下载到设备或离线复制到设备的 ROM 镜像的完整性。在完成如文件大小、哈希值等校验后，根据设备选择不同的升级模式:1.非 VirtualA/B 机型：设备重启进入 Recovery 模式，再次验证签名密钥的正确性。校验通过后，Recovery 模式才会将更新的 ROM 包写入系统存储区域。2.VAB 机型：双分区升级模式下，有系统升级时用户正常使用当前系统，升级模块会验证ROM的完整性，验证通过后将ROM镜像写入另一个分区中。更新完毕后设备重启，会自动同步更新内容并完成升级。4.8.3.2.4网络安全 安全网络协议 使用安全网络协议可以降低用户设备连接网络时遭遇数据泄露和篡改的风险。小米澎湃 OS 用户可以通过公共网络链路建立自己的虚拟专用网络（VPN）。小米澎湃OS 支持多种 VPN 模式，包括：PPTP、L2TP/IPSecPSK、L2TP/IPSec RSK、IPSec Xauth PSK、IPSec XauthRSA 和 IPSec 混合 RSA。用户可以根据需要选择 VPN 模式来访问和传输敏感数据。小米澎湃 OS 的无线局域网连接支持 WEP、WPA/WPA2PSK、802.1EAP、WAPI 等多种身份验证方法，满足用户不同级别的安全需求。小米澎湃 OS 的 WLAN 热点功能默认禁用，当用户启用该功能时，默认使用WPA2PSK 认证方式保证连接的安全性，同时 WLAN 热点功能还支持配置终端 MAC地址黑名单。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem135 伪基站短信识别 伪基站是一种利用了通信系统缺陷的非法无线电通信设备，常被犯罪分子用于冒用他人手机号码向伪基站周边的设备发送诈骗短信或垃圾短信。当伪基站运行时，会干扰和屏蔽一定范围内的运营商信号，用户手机信号被强制连接到该设备，影响用户正常使用。即使用户尚未启用防伪基站功能，小米澎湃 OS 仍可向用户提供识别伪基站短信的功能，此功能不依赖芯片。使用人工智能机器学习，通过对伪基站接入电话的特征和伪基站发送的短信的文本特征进行分析，可以判定是否为伪基站消息。小米澎湃 OS 对伪基站消息的识别是在用户移动终端离线执行的。每当识别出伪基站短信，小米澎湃 OS 都会提示用户。Wi-Fi 探头保护 通过监测其他电子设备发送的 Wi-Fi 信号携带的 MAC 地址，Wi-Fi 探头盒可以识别每个用户。小米澎湃 OS 能够发送带有随机 MAC 地址的数据包，以防止 Wi-Fi 探头获取设备的真实 MAC 地址。4.8.3.2.5设备控制 查找设备 小米澎湃 OS 为用户提供了查找设备功能，为用户找回丢失设备提供帮助，同时保护设备的数据安全。此功能需用户手动开启后才能使用。启用后，在设备丢失的情况下，用户可登录小米云服务网页（https:/）远程对丢失的设备进行以下操作：查找定位、设备发声、丢失锁定和清除数据。设备锁定/解锁策略 启用查找设备功能后，设备将关联到当前登录的小米账号。在用户丢失设备或忘记小米帐号密码的情况下，设备均有可能被锁定，针对设备被锁定的情况，小米澎湃 OS设计了多种安全策略来保障用户权利。查找定位允许用户通过网络或短信命令获取设备的当前位置并通过地图直观显示。设备发声通过网络或短信指令使设备响铃，用于查找可能就在附近的设备。丢失锁定通过网络或短信指令锁定设备，锁定后周期性自动上报定位位置，同时自动解绑 Mi Pay 绑定的银行卡。清除数据通过网络或短信指令重置设备，关闭数据同步并解绑 Mi Pay 银行卡。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem136 此外，如果设备丢失，锁屏密码的存在使得设备极有可能被强制刷机。小米澎湃 OS将账号与设备之间的关联存储到其云服务器（一些设备将关联状态写入不被刷机覆盖的特殊分区），保证关联关系不可篡改。启动时，要求设备连接到网络并从服务器获取真实关联。如果当前登录账号与服务器上的关联账号不同，小米澎湃 OS 将要求用户切换回关联账号后才能继续使用。被解锁的设备可以通过强制刷机非小米澎湃 OS 系统或篡改过的小米澎湃 OS 系统来绕过设备锁定。然而，这种 ROM 不能执行 OTA 升级，也不能正常登录小米账号。当设备刷回官方小米澎湃 OS 包时，它将再次受到查找设备功能的保护。手机分身 小米澎湃 OS 用户可通过手机分身创建一个完全独立于原系统的独立空间，用户的帐户、应用和数据等与主空间隔离，并分别加密保护。用户可以通过设置不同的解锁密码进入主空间和分身空间，达到如同拥有第二部手机一般的虚拟手机体验。用户可以通过对这个分身空间设置访问密码，保存各类私密文件、图片等信息，安装私密应用等。这个分身空间又类似于一个“沙箱”，在这个“沙箱”内进行任何的操作，都不会对主空间造成影响。移动设备管理（MDM）MDM（Mobile Device Management，移动设备管理）是小米澎湃 OS 提供给设备管理类应用的设备保护功能，是对设备进行管理和操作的接口。通过 MDM 应用和小米澎湃 OS 提供的 API 接口，企业 IT 系统可以轻松实现对小米澎湃 OS 设备的控制和管理。API 接口调用需要授权，保证接口调用的权限管控和安全性。对于引导或提供非正常使用设备管理器权限的应用，按标准执行系统管控策略，包括但不限于：在系统内强提醒用户进行关闭处理、禁止应用获取服务或权限接口。对于引导或提供通过设备管理器权限，对用户的数据、设备使用安全可能产生危害的应用，将严格执行如下操作：将该应用在小米应用商店进行下架处理、禁止应用获取相关服务接口、禁止相关应用在设备管理器应用列表中显示。激活锁定如果启用查找设备功能后，当小米设备恢复到出厂默认设置并对小米设备重新刷机时，设备将被锁定。设备只能使用关联到设备的小米账号密码进行解锁。密码重置保护为避免用户设备丢失后，帐号密码被使用设备验证进行重置，小米帐号重置密码后 3 天内无法关闭“查找设备”功能，为丢失设备的用户提供时间补办 SIM 卡，重新夺取帐号和设备的控制权。客服解锁如果用户忘记了自己的小米账号密码，无法找回密码，用户可以通过客服解锁设备。做出解锁决定所需的信息包括锁定界面或 IMEI 上的解锁代码、订单号或发票等购买证明以及小米账号的电话号码。如果购买证明被确认为无效或不完整，解锁申请将被拒绝。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1374.8.3.3身份认证和数据安全4.8.3.3.1锁屏密码小米澎湃 OS 锁屏密码支持绘制模式、数字密码和混合密码，每种密码都有最小密码长度要求，以确保更安全的密码。绘制图案密码：至少需要连接 4 个点。数字密码：这些密码支持 4-16 位之间的长度。混合密码：这些密码支持大小写字母、数字和长度在 4-16 个字符之间的符号的任何组合。小米澎湃 OS 锁屏密码受硬件唯一密钥（HUK）保护，并在 TEE 中加密。当用户创建或修改锁屏密码，或使用锁屏密码解锁屏幕以进行验证时，锁屏密码将在 TEE 中处理。小米澎湃 OS 限制输入错误密码的次数。连续多次尝试使用错误密码后，手机将被锁定，以防止锁屏密码被暴力破解。在部分产品上，小米澎湃 OS 基于安全芯片，支持基于安全芯片的锁屏密码增强。对于锁屏密码的校验的错误计数等逻辑均运行在安全芯片中，提供抗硬件物理攻击的安全强度。4.8.3.3.2生物识别小米澎湃 OS 提供指纹和人脸两种生物识别方式。指纹识别指纹识别功能是小米手机优化用户体验的特色功能设计之一。指纹识别基于生物认证技术兼具强密码安全性的特点，只需用户将手指放到设备的指纹传感器位置，根据用户提前录入的一个或多个指纹特征信息，就能快速解锁访问自己的设备。考虑到密码是用户通过加密方式保护其个人数据的根基，指纹识别的目标是在保证用户设备安全的基础上为用户提供更便捷、快速的解锁服务，因此指纹识别功能不会取代设备的密码解锁模式。用户在每一次开启/关闭指纹识别功能前都需要输入密码，并在以下场景中，只能通过输入密码才能继续操作设备，以保障用户设备及器个人数据的安全：当用户的设备刚刚打开或重新启动时；当设备超过 72 小时未使用密码解锁时；当用户的设备连续指纹解锁失败达到 5 次以上，20 次之内时，每次指纹解锁失败会临时锁定指纹功能 30 秒；当用户的设备连续指纹解锁失败达到 20 次时。人脸识别人脸识别功能是小米手机优化用户体验的特色功能设计之一。人脸识别基于生物认证技术兼具强密码安全性的特点，通过人脸识别 AI 算法智能检测人脸面部特征并进行高精度匹配，让用户只需注视设备屏幕，就能快速解锁访问自己的设备。考虑到密码是用户通过加密方式保护其个人数据的根基，人脸识别的目标是在保证用户背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem138设备安全的基础上为用户提供更便捷、快速的解锁服务，因此人脸识别功能不会取代设备的密码解锁模式。用户在每一次开启/关闭人脸识别功能前都需要输入密码，并在以下场景中，只能通过输入密码才能继续操作设备，以保障用户设备及个人数据的安全：当用户的设备刚刚打开或重新启动时；当设备超过 72 小时未使用密码解锁时；当用户的设备连续人脸识别失败达到 5 次时。充分考虑安全与用户隐私的生物识别机制。小米澎湃 OS 一直以来都将用户的隐私保护置于各项产品和服务的重要地位，对于 AI 技术及产品而言也没有例外。我们将隐私设计的理念贯穿于生物识别产品生命周期的各个阶段，不仅符合法律的要求，更在于追求实现最佳实践。我们深知用户生物特征信息对于用户的重要性，在生物识别功能设计初期，考虑到对数据采集、传输、存储、销毁等各个处理环节可能存在的风险，通过识别风险、制定策略和技术措施防护，监督落实等方法，在为用户提供更优使用体验的同时，力求将安全与隐私风险降到最低。我们承诺只有在用户授权和明确同意的情况下，才会保存和调用生物特征值信息。仅采集用户不可逆的生物特征值信息。生物识别功能需要用户提前录入生物特征模板，在录入的过程中，AI 算法提取人脸或指纹的特征值信息后，仅保存提取后不可逆的生物特征值信息，不会保留用户原始的生物信息。生物特征值信息的不可逆性也降低了通过人脸特征值信息还原原始人脸生物信息的可能，进一步保障了用户原始人脸生物信息的隐私性。生物特征信息仅在用户设备本地存储和使用。生物识别 AI 算法集成在设备端本地运行，人脸特征信息的录入、存储、验证过程都在用户的设备本地完成。我们不会将用户的人脸特征数据备份或上传到任何包括小米服务器在内的其他平台，从根本上避免了由于数据传输过程中可能存在的安全与隐私风险。构建算法安全架构，提供安全的运行和存储环境。小米澎湃 OS 通过构建基于硬件隔离技术的生物识别安全架构，在 TEE 环境中进行完成对生物特征信息的采集、存储和验证，保障生物特征信息数据不被任何第三方应用获取。在采集的过程中。设备基于硬件安全机制（比如2D RGB镜头方案的安全摄像头），使小米澎湃 OS 的用户侧只能控制生物信息采集设备的打开/关闭等操作，不能直接读取生物信息采集设备采集到的原始信息。在存储的过程中。用户的生物特征信息存储在 TEE 提供的安全文件存储系统中，安全文件存储系统的加密密钥存储在芯片内部，只有 TEE 可以访问，即使是生物识别 TA也不能直接访问密钥，保证攻击者在入侵内核和平台后也无法读取和篡改生物特征值信息。在验证的过程中。TEE 环境外的小米澎湃 OS 只能发起生物特征认证的请求和接收认证结果，生物特征识别算法的生物特征信息比对过程在 TEE 环境下进行，任何 TEE环境外的应用都无法访问生物特征数据本身。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem139用户可在本地对生物特征数据进行管理。生物特征信息仅保留在设备本地，不会上传或备份到任何包括小米服务器在内的其他平台。用户可以通过设备的“设置-指纹、面部与密码”页面下对已录入的生物数据进行管理如添加、命名、删除。为保证用户信息的隐私与安全，用户在进入生物数据管理界面前，每一次都需要用户输入设定的密码进行身份验证。用户可随时选择关闭/开启生物识别功能。用户可以通过设备的“设置-指纹、面部与密码”页面随时选择开启或关闭人脸解锁功能。在每一次开启或关闭生物识别功能时，都需要用户输入密码进行身份验证。停用生物识别功能后，生物识别服务将不会被调起和使用，启用时已保存在生物特征数据不会自动删除，需要用户在相应的生物信息管理页面人工进行删除操作。4.8.3.3.3通用密钥库小米澎湃 OS 的通用密钥库主要用于管理应用程序开发人员使用的密钥和证书的生命周期，同时还为硬件隔离环境中（部分设备为 TEE，部分设备为 TEE 和安全芯片双环境）的设备证书提供远程认证。通用密钥库具有以下功能：生成和存储小米澎湃 OS 的通用密钥库提供了硬件保护的密钥存储机制，应用程序中生成的密钥是加密的，只能由相应的设备使用。加密和解密当应用程序需要使用该密钥时，将先前生成的加密密钥和待加密数据发回相应设备的硬件隔离环境中，该密钥只能用于在相应设备的硬件隔离环境中执行加密和解密操作。密钥认证每一部小米手机在制造时，都在硬件隔离环境内部安全生成一对公私钥，其中公钥证书被导出，存储在云服务器中，用于安全认证每一台小米手机的合法性。基于该公私钥对，进一步支持了远程密钥认证功能，提供三方网络服务在无法窥探用户隐私的前提下，对小米澎湃 OS 设备进行合法性认证。小米澎湃 OS 通用密钥库的技术基础是硬件隔离环境，通过防止密钥提取和密钥使用授权等措施，防止在设备外部和设备上未经授权使用密钥材料。预防提取为避免在小米澎湃 OS 设备之外以未经授权的方式使用密钥材料，通过 Keystore 密钥执行加密操作时，应用会将待签署或验证的明文、密文和消息发送到执行加密操作的系统进程，而不是应用进程。因此，即使应用进程遭受攻击，攻击者也无法提取密钥材料。同时，小米澎湃 OS 还将密钥材料绑定到小米设备可信执行环境的安全硬件，使其不会暴背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem140露于安全硬件之外。即使 小米澎湃 OS 操作系统遭受攻击或者攻击者读取到设备的存储空间，也无法从设备上提取这些绑定安全硬件的密钥材料。密钥使用授权为了减少小米澎湃 OS 设备上密钥的未经授权使用，在生成或导入密钥时，Keystore 会让应用指定密钥的授权使用方式。一旦生成或导入密钥，其授权就不能更改。以后每次使用密钥时，都会由 Keystore 强制执行授权。小米澎湃 OS 中支持的密钥使用授权分为以下类别：加密：授权的密钥算法、操作或目的（加密、解密、签名、验证）、填充方案、块模式和可以使用密钥的摘要。时间有效性间隔：密钥被授权使用的时间间隔。用户身份验证：只有当用户最近进行了身份验证时，才可以使用密钥。4.8.3.3.4用户数据加密基于锁屏密码和通用密钥库机制，小米澎湃 OS 实现了一套完整的用户数据加密方案。小米澎湃 OS 文件系统分为系统分区和用户分区。系统分区是只读的，与用户分区隔离。常见的应用程序只能访问系统分区的部分目录。在用户分区的情况下，系统提供了基于文件的数据加密和目录权限管理机制，以限制不同应用程序之间的数据访问。此外，小米澎湃 OS 提供了更多基于硬件隔离加密技术的安全功能和应用程序，提高了小米澎湃OS 的便利性和可用性，同时也保护了用户数据安全。文件级加密小米澎湃 OS 基于 TEE 的安全能力，结合芯片提供的硬件加解密引擎及内核加密文件系统模块，基于对称密码算法提供了文件级的用户数据加密保护。基于小米澎湃 OS 的小米设备都为每个用户提供了两个应用程序存储位置：凭据加密（CE）存储区域：CE 区域是默认存储区域，只有设备重启后，用户首次使用锁屏密码解锁设备才能访问。设备加密（DE）存储区域：无论是否解锁，设备通电后都可以访问 DE 区域。CE 存储区域是小米澎湃 OS 中应用程序存储数据的默认存储区域，以确保应用程序和应用程序数据的安全性。只有无线身份验证、闹钟、铃声、蓝牙等应用程序才会在 DE 存储区域中存储某些数据。这确保了某些基本服务将在用户提供凭据之前运行，同时系统继续保护用户隐私信息。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem141安全存储小米澎湃OS的安全存储功能由基于TEE的安全文件系统（SFS）实现，用于安全存储密钥、证书、指纹模板等敏感信息。运行在 TEE 中的可信应用程序（TA）使用安全存储应用编程接口加密和存储数据。加密数据只有 TA 才能访问，因此外部应用程序无法访问。小米澎湃 OS 中的安全存储采用高强度对称密码进行加密、解密和真实性完整性封装。安全存储密钥来自硬件唯一密钥（HUK），并始终存储在设备的 TEE 中。通过密钥加密的数据不能在 TEE 之外解密。小米澎湃 OS 进一步提供 RPMB（重放保护内存块）分区功能，以保护某些系统数据免受未经授权的删除和访问。RPMB 分区由 TEE 直接控制，用于安全，并绑定到硬件唯一密钥（HUK）派生的密钥。只有 TEE 可以访问 RPMB 保护的数据，外部用户环境不提供访问 RPMB 的接口。RPMB 通过内置计数器、密钥和 HMAC 验证机制防止重放攻击，以确保数据不能被恶意覆盖或篡改。安全擦除一般的“出厂重置”并不保证存储在物理存储中的数据会被彻底擦除。为了提高效率，这通常是通过删除逻辑地址来实现的。然而，物理地址空间实际上并没有被擦除，数据可以被恢复。小米澎湃OS为用户提供了当他们希望恢复出厂设置时“格式化模拟SD卡”的选项。一旦选择了这个选项，系统将格式化存储空间并完全擦除数据，以保护设备出售或报废后的用户数据安全。图 4.8-5 基于文件的数据加密过程文件保护文件密钥保护封装后的类密钥保护类密钥保护通用密钥库密钥派生硬件根密钥MiTEE用户设置的身份凭证1.用硬件根密钥派生通用密钥库密钥。2.使用通用密钥库密钥和用户身份凭证加密类密钥。3.在启动系统时，为每个类密钥进行密码学封装，用于防止类密钥的明文在用户环境中暴露。4.使用封装后的类密钥加密和保护文件密钥。5.使用文件密钥加密文件。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1424.8.3.4.1照明弹又称为应用行为记录。在应用发生特定敏感行为时，小米澎湃 OS 会进行记录并展示给用户，主要包含了自启动与关联启动记录、敏感权限使用记录、跨端行为记录。同时敏感权限中的相机、麦克风和位置在使用中会在状态栏有明显的状态提醒，用户可以实时查看哪些应用正在使用这三个权限，并支持用户对应用进行关闭。实时保护用户个人隐私知情权。4.8.3.4应用安全4.8.3.4.2拦截网小米澎湃 OS 支持多个权限的多种授权状态，除了允许与拒绝外，还有仅在使用中允许与本次使用中允许。仅在使用中允许：仅允许进程状态处于前台的应用使用该权限，后台应用访问会被拒绝。本次使用中允许：用户在一次连续使用过程中允许使用该权限，一旦进程被杀或者用户停止使用一段时间后，权限将被自动收回。图 4.8-6 应用行为记录整体框架Icon/WidgetRecentTaskNotificationNativeAppsBroadCastSourceActionAimedActionUIActionbyUserOperationAutoStartChainStartCoreservicesActivityManagerServerCrossAndroidPlatformAppOpsServiceWakePathCheckerRecordandPersistencePermissionControlApplicationUlandControlSystemControlUISecurityApplication背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1434.8.3.4.3防追踪小米澎湃 OS 禁止三方应用获取不可重置标识符，如 IMEI、MEID、IMSI、Mac 地址、Serial 号等。同时对外开放了一套用户可重置可关闭的虚拟身份 ID，同时智能识别并禁用应用内嵌入的各类型追踪器，例如通过手机存储共享个人标识，共用 SDK 追踪等。4.8.3.4.4权限管理小米澎湃 OS 将权限分为不同的类型，包括安装时权限、运行时权限和特殊权限。每种权限类型都指明了当系统授予应用该权限后，应用可以访问的受限数据范围以及应用可以执行的受限操作范围。安装时权限安装时权限授予应用对受限数据的受限访问权限，或允许应用执行对系统或其他应用只有最低影响的受限操作。如果在应用中声明了安装时权限，应用商店会在用户查看应用详情页面时向其显示安装时权限通知。系统会在用户安装您的应用时自动向应用授予权限。小米澎湃 OS 提供多个安装时权限子类型，包括一般权限和签名权限。运行时权限运行时权限也称为危险权限，此类权限授予应用对受限数据的额外访问权限，或允许应用执行对系统和其他应用具有更严重影响的受限操作。因此，需要先在应用中请求运行时权限，然后才能访问受限数据或执行受限操作。当应用请求运行时权限时，系统会显示运行时权限提示，用户可以选择允许、拒绝以及仅在使用中允许等选项。许多运行时权限会访问用户私人数据，这是一种特殊的受限数据，其中包括可能比较敏感的信息。例如，位置信息和联系信息就属于用户私人数据。特殊权限声明特殊权限的应用会显示在系统设置中的特殊权限设置页面内。如需向应用授予特殊权限，用户必须转到此页面：设置隐私与安全其他权限特殊权限设置。如显示在其他应用上层权限，不会弹出授权弹窗，需要跳转单独的管理界面。4.8.3.4.5安全扫描病毒扫描集成了多个知名安全厂商（腾讯，安天）的病毒查杀引擎及小米自研病毒引擎。提供本地及云端查杀能力，确保设备在有无联网的情况下都能发现应用的安全风险。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1444.8.3.4.6运行时保护应用沙箱小米澎湃 OS 使用应用沙箱机制，确保每个应用运行在沙箱中且相互隔离，保证应用运行时安全。运行时内存保护小米澎湃 OS 支持地址空间布局随机化（Address Space Layout Randomization，ASLR）及数据执行保护技术（Data Execution Prevention，DEP）。ASLR 提供对缓冲区溢出的安全保护技术，通过对堆、栈、共享库映射等线性区布局的随机化，增加攻击者预测目的地址的难度，防止攻击者定位攻击代码位置，达到阻止溢出攻击的目的。ASLR 技术提高了攻击者在利用内存漏洞 上的难度。DEP 机制会把内存中的特定区域标注为不可执行区，以防止内存漏洞攻击。安全输入用户在输入密码时，小米澎湃 OS 自动启用安全键盘。安全键盘不具备联想和记忆功能，没有联网权限，禁止后台录屏或第三方应用截屏，禁止第三方应用悬浮窗覆盖在安全键盘之上，确保用户的密码输入安全。应用锁应用锁既可保护应用数据安全，同时又防止应用中的隐私信息被他人窥见。小米澎湃 OS 用户可通过“应用管理”进入“应用锁”模块，为应用设置多种样式的解锁密码（图案、数字、混合），用户可设置在退出应用后或是退出应用 1 分钟后锁定，以及在锁屏后再次打开应用时验证应用锁。为了增加解锁的便捷性和安全性，小米澎湃 OS 增加了指纹和人脸的生物识别解锁机制。病毒查杀引擎支持应用安装时检测，用户也可以在手机管家中手动触发设备病毒扫描功能，对恶意应用和恶意文件进行扫描。异常检测此外，“手机管家”-“异常检测”功能还提供了 ROOT 安全检测以及手机性能、操作、耗电等异常检测，主要包括以下功能：手机性能异常检测检测APP是否开启了辅助功能、设备管理器，手机剩余内存是否不足等操作异常检测检测是否开启了飞行模式、拦截联系人来电、拦截陌生人来电、勿扰模式、护眼模式等耗电异常检测检测自启动应用是否过多，是否开启了热点等其他异常检测检测系统是否被ROOT，存储空间不足时提示用户无法安装应用等背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1454.8.3.5安全开放框架4.8.3.5.1设备可信服务HyperOS 基于可信执行环境 TEE 提供系统安全检测结果，在 TEE 中动态获取系统完整性数据，可信度高，并通过设备可信服务将设备状态数据提供给应用，为应用进行业务风控提供高可信的系统环境检测数据。应用开发者存在被恶意应用攻击的风险。同时，部分三方应用的人脸识别、指纹识别等功能并未采用硬件级方案，存在安全隐患。为了帮助开发者抵御恶意应用威胁，提高安全保护级别，HyperOS 通过安全开放框架为应用提供系统级安全开放能力。安全开放框架以 SDK 的方式为开发者提供了设备可信服务、系统安全检测、硬件级安全保护三方面的功能。4.8.3.5.2系统安全检测服务恶意应用检测服务HyperOS 基于端侧扫描为应用提供了获取当前系统是否安装了恶意应用的能力，应用可以通过恶意应用检测服务获取到的恶意应用类型，来确定需要采取的风控策略。虚假点击检测服务HyperOS 为应用提供了系统级的虚假点击检测服务，基于当前系统的运行时状态以及点击事件触发方式和特征动态判断当前设备是否存在虚假点击的行为，提升应用的风控能力。4.8.3.4.7安全支付使用支付类应用时，将会自动检测系统环境是否处于安全状态。如若发现风险项，将会通过弹框等形式进行提醒，帮助用户判断是否继续完成交易，以降低可能的风险带给您的不必要损失。检测的因素主要包括：当前交易环境中连接的 WIFI 是否安全 使用的输入法是否安全（检测用户的输入法是否为白名单中的正版安全输入法）系统中是否存在病毒应用（检测后台进程是否有木马、病毒运行）屏幕共享防护用户在使用共享屏幕等功能时，小米澎湃 OS 会在状态栏进行明显的状态提醒，防止用户忘记处于共享状态。同时，通过虚拟屏幕技术，将短信、金融软件类等敏感数据、悬浮通知隐藏或模糊起来，保护用户不会泄露验证码等个人隐私数据，导致财产损失等。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1464.8.3.6安全认证与隐私政策小米公司以尊重和保护用户隐私与安全，致力于打造让用户信任的产品，享受科技的乐趣为目标。为确保信息安全与隐私保护策略的贯彻执行，小米在 2014 年就正式成立信息安全与隐私委员会，通过技术防护、流程制度、评估和审查机制等建立了完善的安全管理体系。同时，小米聘请了欧盟当地的资深律师作为欧盟业务的数据保护官，以确保小米符合各国法律法规的要求。为向用户提供符合法律法规及业界标准要求的业务运行环境及服务，小米已开展全球化合规治理工作，并接受外部监管机构的定期审查。小米已经通过多种隐私安全的认证，更多具体认证信息请访问：https:/ HyperOS 可信执行环境中，通过高安全能力支撑应用安全业务场景。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1475系统内核（Kernel）5.1Linux 内核子系统结合用户体验和性能需求，针对传统 linux 内核的内存管理、虚拟文件系统进行重点重构和优化（进程调度、网络接口、进程间通信等部分分别在其余对应子系统中做重点优化和展示。5.1.1子系统简介5.1.2子系统架构图 5.1-1 Linux 内核子系统架构Device物理碎片整理物理垃圾回收CLS内存扩展文件系统Native Apps内存交换内存分配系统进程 vip通道前台优先分配内存碎片整理内存回收前台感知回收内存压力监控冷热数据分类弹性缓存内存扩展内存冻结IO快速路径虚拟内存预加载自适应内存交换调度系统VIP调度热感知调度进程冻结帧负载追踪丢顿预测SoC 一体化调频网络极简协议报头精简OSRTP 极简快传协议QUIC 加速引擎TCP/IP 协议栈全链路Big协议零拷贝技术TCP/UDPOffload冷热数据压缩Cow 文件系统快照智能缓存加速碎片整理引擎BlockCPQIO调度算法弹性分区Syscall API设备驱动硬件平台背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1485.1.3重点特性5.1.3.1Hyper 内存分配管理引擎技术介绍Hyper 内存分配管理引擎主要负责为上层业务分配所需要的物理内存资源，以此满足业务需求。内存分配速度的快慢直接关系到上层业务的软件服务质量。小米内存分配管理引擎打破了传统的Linux内核无法感知上层业务的限制，能够感知上层业务整个生命周期，即使在极端场景下，也能够及时满足前台业务的内存分配请求，保证前台业务的软件服务质量。同时，针对大内存设备，Hyper 内存分配管理引擎通过大页管理技术降低系统内存管理开销，提升系统整体性能和流畅度。技术架构关键技术1.核心场景内存预留：通过识别核心场景内存需求，提前为核心场景预留一定的内存，确保核心场景内存分配请求能够得到及时满足，提升核心场景系统流畅度和稳定性。2.内存加速：针对资讯类与短视频类应用，将临时文件目录通过内存文件系统挂载，减少 UFS 写入，提升 Flash 寿命。3.内存分片：改变过去单区域内存管理模式，将内存进行多区域管理，内存可以并行分配，减少内存分配延迟，降低内存碎片化概率。4.大页管理：针对大内存手机，改变过去 4k 页面管理方式，降低大内存手机系统内存管理开销，提升系统流畅度。5.预分配：基于用户日常使用习惯预测应用启动时机，通过预加载机制加速应用启动速度。图 5.1-2 Hyper 内存分配管理引擎技术架构上层业务感知场景识别应用场景信息/前后台信息/应用生命周期核心场景内存预留systemui/Home/动画预分配应用行为预测，应用预加载Hyper 内存分配管理引擎前台优先分配系统进程 vip 通道前台感知分配内存加速短时应用内存文件系统高效内存管理内存分片多区域管理，并行分配大页管理背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1495.1.3.2Hyper 内存回收交换引擎技术介绍随着系统长时间使用，系统可用内存不断降低。为了保证上层业务内存分配请求得到及时满足，系统需要从当前已分配内存中选择一部分内存数据进行回收，以此释放出空闲内存。Hyper 内存回收交换引擎通过冷热内存分离技术以及前台感知技术，能够有效识别出对用户体验影响较小的内存数据，通过优先回收这部分内存数据来降低系统回收对用户体验的影响。对于系统中那些长期不活跃的匿名页，Hyper 内存回收交换引擎通过内存扩展技术，将这些数据交换到 Flash，进一步提升系统可用内存大小。技术架构关键技术1.前台感知回收：感知上层应用整个生命周期，优先回收用户感知不明显应用内存数据。2.内存冷热数据分离：通过对应用前台使用过程中的内存数据访问进行采样，识别应用冷热内存数据，优先对冷数据进行回收。3.内存扩展：通过多次标记技术，将内存中不活跃内存数据并将其交换到 Flash 来提升系统可用内存，改善用户体验。4.内存冻结：在内存、ZRAM、Flash 之间建立三级缓存，根据 TOP 应用物理内存占用，在三级缓存之间交换内存数据，提升系统后台驻留能力。图 5.1-3 Hyper 内存回收交换引擎技术架构应用管理模块应用内存回收模块采样结果管理应用内存回收应用内存访问采样前台应用后台应用后台应用应用信息内存访问采样模块sysfs 接口层策略层采样层内存管理模块内存交换内存分配内存回收PSI 内存压力监控应用内存回收应用内存访问监控内核层框架层应用进程虚拟地址空间VMA1VMA2VMA3内存访问采样PC 侧Converter二级缓存ZRAM一级缓存专属内存DDR压缩内存交换三级缓存NANDFlashFlash内存回读背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1505.1.3.3存储引擎技术介绍存储引擎包含 3 个存储方面的专项内容：1.智慧 IO 引擎 2.0，负责提高存储的性能。2.焕新存储，负责预防存储的老化。3.系统精简，负责精简系统资源对存储大小的占用。技术架构图 5.1-4 存储引擎技术架构系统精简用户分区压缩策略文件去重策略A/B分区复用分区动态扩展焕新存储文件碎片整理策略垃圾回收策略智慧 IO 引擎用户感知模型智能冷起加速IO 感知加速应用层空间缩减F2FS文件级去重F2FS压缩文件归并压缩算法EROFS压缩EROFS去重NativeApps焦点IO介质调度器智能优先级BLOCK智能预读NativeAppsF2FS文件碎片整理GC垃圾回收算法智能文件预留l0 加速文件大页数据Cache优化FsSync优化内核层防止老化UDE 扩容CLD 硬件垃圾清理SmartGCFBO 硬件碎片整理空间HPBSwapBoost智能文件存储L2P 命中SMCQIO 融合SDQDWBIO 引擎Other自研 FW冷热数据自封装设备层背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem151关键技术1.智慧 IO 引擎 2.0：包含焦点 IO、智慧 IO 预加载、数据 Cache 优化三项核心能力。焦点 IO IO 性能是保证系统流畅的一个基础必要因素，受益于行业上游硬件的发展，硬件 IO带宽在过去 10 年提升了 10 倍，但是我们仍然有可能会出现前台 app 操作不够流畅，或是在一些大文件加载或拷贝的场景加载过慢。这些场景的卡顿有很大概率是后台应用的 io 请求抢占了前台应用的 io 请求造成的。焦点 IO 技术将前台/后台的 io 带宽分配一个合理的比例，前台 io 优先下发，避免后台 io 对前台 io 的抢占，进而优化 app 冷启和使用过程中的流畅度。智慧 IO 预加载：通过机器学习预测需要哪些 I/O 并提前执行来减少应用程序启动时间，预取数据操作完成后，应用程序几乎可以立即从 pagecache 访问这些数据，从而显着减少应用程序启动延迟。工作流程：在学习阶段，即应用程序的第一次启动期间，用户模型感知模型通过监视磁盘读取或页面错误收集与启动相关的块以及它们的访问序列。后续应用程序启动期间，智能冷启加速模块使用收集的启动序列进行磁盘预取以加速加载。数据 Cache 优化 在 f2fs 基础上加入 AI 算法的智能文件系统，通过 AI 算法，识别文件的生命周期，对使用过程中产生的应用缓存文件进行智能分类，识别出那些生命周期很短的文件，提前将其删除，避免 data 分区不必要的回写量，减少存储碎片化，延缓存储老化进程，延长 UFS 寿命（UFS 写次数是有限的）。2.焕新存储：存储老化及性能改善方案，底层硬件的 FBO 换新存储整合了四个象限，成为目前世界上第一个完整的整理功能。其中，文件碎片整理提高文件读取性能，降低 APP 在手机老化情况下的启动时间；Smart GC 智能碎片整理，大负载后保证 IO性能；GC垃圾回收算法降低功耗，增加UFS寿命；智能文件预留控制运用的文件范围，降低碎片程度，提升性能；CacheSifter降低Flash写操作，减缓存储碎片化，提升性能。3.系统精简：系统精简主要集中在系统固件的精简以及用户可用空间的增大上，系统固件精简在新机上已做到智能手机业界（包括 Android 阵营和苹果手机）行业第一。背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1525.2Vela 内核子系统5.2.1子系统简介5.2.1.1物联网操作系统技术演进史目前，物联网操作系统没有严格的定义，按发展路径和阶段可以分为四大类：一是由传统的嵌入式 RTOS 发展而来；二是基于传统操作系统进行的“剪裁”和定制；三是专门面向物联网研发的操作系统；四是新一代统一型操作系统，通常称为跨设备分布式操作系统。这些操作系统，虽然出现的时间点各有先后，但并非代际替换的关系。一些物联网操作系统，比如 QNX，虽然出现很早，但现在还是在工业界，特别是车机领域得到大量的应用。图 5.2-1 物联网技术演进史ONX(1982)VxWorks(1987)ucOS(1991)NativeAppsNucleus(1993)FreeRTOS(2003)PikeOS(2005)NativeAppsNuttx(2007)第一类:传统的嵌入式 RTOSARMMbedOS(2009)OpenWRT(LinuxBased)(2010)YoctoLinux(2010)WearOS(2014)第二类:基于成熟操作系统剪裁和定制AndroidThings(2015)HuaweiLiteOS(2012)NativeAppsTizenRT(NuttXbased)(2015)Zephyr(2016)AliosThings(2017)RT-Thread(2017)第三类 面向物联网的轻量级操作系统NativeAppsVela(2019)HarmonyOS(2019)OniroOS(2021)第四类 新一代统一型操作系统XiaomiHyperOS(2023)背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1535.2.1.2物联网操作系统技术发展趋势 端云一体：随着云计算技术的不断发展，越来越多的物联网设备开始与云端进行交互。因此，物联网操作系统需要具备更好的端云一体支持，如云端管理、云端数据存储、云端分析等，而云端的数据可以结合目前的多模态大模型 AI 能力，建设 IoT 的智能化能力。跨端互调用：未来的物联网操作系统面临的是多端的环境，可能运行在不同的端侧，但具备相同的跨端能力和跨端互联框架，这样的趋势也是泛在操作系统演化的基本形态。统一多 OS 内核架构：未来的物联网 OS，会是多内核共存的形式，每种内核负责解决不同场景下的问题；典型的如 Open Harmony/Oniro，会整合 Linux，LiteOS，Zephyr 这几种不同的内核以及和内核密切相关的框架和运行时，内核组件化的趋势逐渐开始形成。内核组件化的本质还是为了解决物联网应用场景的扩展和不断增加的设备种类所带来的碎片化问题。统一安全框架：随着物联网设备的数量不断增加，设备的安全性问题也越来越受到关注，由于其联网的属性，所以未来安全性也是 IoT 设备的重大挑战之一。物联网操作系统作为技术基础底座，需要具备更加完善的安全机制，所以未来的主要挑战之一也就是物联网操作系统的安全性。AI 能力：下一代的 AI 能力体现在多模态大模型，这是指同时处理多种数据类型（如文本、图像、语音等）的大型深度学习模型。多模态大模型可以为操作系统的“智能化”赋能，从云侧和端侧两边同时发力，推动物联网技术的发展和应用。图 5.2-2 物联网技术发展趋势端云一体云端管理平台NativeApps跨端互联应用框架统一跨端能力端侧 AI 能力多模态大模型AI 能力跨端互调用能力OSComponentRichosFrameworks&RuntimeRichOSKernel(LinuxBased)OSComponentRTOSFrameworks&RuntimeRTOSKernel(NuttX/Zephyr/LiteOSBased)AI 能力可信加载和 TEE 环境统一多 0S内核架构统一安全框架背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1545.2.1.3Vela的目标和定位 Vela 的目标 IoT 技术领域的核心痛点就是碎片化，其本质是市场和需求的碎片化所带来的技术组件碎片化。碎片化带来软件的低复用、低效率、和低质量。Vela 的目标是提供标准化的软件平台，高效、高质量支撑小米 AIoT 亿级设备的开发和接入，降本增效，解决IoT 设备的碎片化问题 Vela的定位 在 Xiaomi HyperOS 的技术体系下，Vela 定位为轻载硬件资源下，使用的轻量操作系统。所以 Vela 所覆盖的设备是所有 L0 L2 类设备，同时覆盖 L3 L5 设备的小核/小系统。图 5.2-3 IoT 领域核心痛点NativeAppsRTOS 内核网络协议栈互联互通方式GUI 框架硬件的碎片化处理器架构SoC硬件外设开发方式的碎片化编译工具链编程框架和语言IDE 或原生环境技术组件的碎片化市场和需求的碎片化图 5.2-4 Vela 的定位IoT 领域的核心痛点是碎片化32K1ML0loT设备1M64ML1运动手表智能音箱64M512ML2摄像头512M2GL3智能手表2G4GL4电视4GL5手机、平板、车机Vela可以覆盖此类设备Vela可以覆盖此类设备的小核/小系统背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1555.2.2子系统架构 VelaKernel：提供最基本的任务调度、跨进程间通信、文件系统等基础 OS 功能，同时也提供简洁高效的设备驱动、轻量级的 TCP/IP 协议栈和电源管理等组件，也包括同构多核和异构多核的支持。VelaFramwork:分为上下两层，下层是为扩展系统服务而提供的通用应用框架，上层是针对不同的物联网应用而开发的定制应用框架，例如多媒体应用框架和传感应用框架，提供 Cloud SDK 可以方便开发者更快速的接入小米云服务。VelaTools：除了常见的 Logger 和 Debugger 工具，Xiaomi Vela 还提供 Emulator工具来帮助开发者提升调试效率，使用 Emulator，开发者可以利用 PC 端丰富的调试工具和调试信息，降低嵌入式系统开发和调试的难度。图 5.2-4 Vela 的定位ApplicationFramework(C /JS)VelaFrameworkMishareSDKSensorFrameworkMultiMediaFramework容器运行时JS/WASMruntimeAlSDKCloudSDK关键数据保护 KVDB升级框架OTA蓝牙BluetoothConnectivityNativeAppsCPC图形框架 GUI融合IPC&CPCXPC标准 POSIXAPI 接口 POSIXAPI&C/C APIVelaKernel(NuttXBased)设备驱动DeviceDriver连接系统ConnectivityTCP/IP&Wiff文件系统 FileSystem异构多核 AMP电源管理 PowerMananger调度系统 NuttXScheduler&IPC同构多核 SMP平台支持(ARM&Risc-V&X86)ToolsIDEUIDesignerEmulatorLogger&debuggerAutoTestFramework背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1565.2.3重点特性技术介绍异构多核设计是低功耗融合计算平台的发展趋势，Vela 提供了标准化、高可靠、低延时、轻量级的跨核通讯机制。Vela 核间通信能力有如下一些优势：对用户无感，基于标准系统调用，跨核服务均在系统底层实现。对开发者友好，配置简单清晰，接口明确。Vela IPC 框架为分布式架构提供整体解决方案，多媒体、网络、传感器等系统核心服务可以基于该框架实现异构多核能力的融合。技术架构5.2.3.1异构多核框架 轻量级，高可靠，低延迟。功能全，覆盖 15 跨核服务框架（文件系统，套接字，诊断系统，虚拟串口、终端，分布式时钟树等）。灵活度高，多媒体、网络、传感器等系统核心服务可以基于该框架实现异构多核能力的融合。成熟性好，支持业内常见架构及 10 头部 SoC 平台差异化多核架构设计。图 5.2-6 多核异构架构APCoreCortex-MTEEREEAudioCoreDSPXtensaHIFIBT/WifiCoreCortex-MSensorCoreCortex-M背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem157关键技术1.异构多核文件系统服务 文件系统分布式多核共享。对上层无感，开发者无需关心文件系统处于哪个核心，从虚拟文件系统层支持异构核文件系统访问。文件、目录相关系统调用完全支持，支持动态挂载/卸载。2.异构多核虚拟串口、终端服务 支持异构核虚拟终端，提供多核终端动态切换功能。节约前期硬件资源和布线成本，支持物理串口多路复用或单串口多路软件复用。降低开发难度和诊断成本，支持传统协议工具(adb/telnet/ssh)对于多核的调试。3.异构多核网络套接字服务 异构多核协议族基于标准网络套接字(socket)，完全兼容所有套接字系统调用。降低开发难度和学习成本，套接字完全兼容主流多路复用和异步 IO 模型。多协议族可无缝切换，一次开发即可支持本地/跨核/IP 网络三种通信模型。4.其它异构多核服务 异构多核日志诊断服务：将日志和系统诊断信息输出到其他核心。异构多核硬件 IO 访问服务：支持跨核访问硬件 IO 资源(GPIO/I2C)。异构多核网络服务：支持跨核 IP 网络访问。异构多核时钟服务：支持多核共享 RTC 时钟源，支持订阅、发布原语。异构多核电源管理服务：多核动态电源管理框架。异构多核微对象发布订阅服务：高度融合的混杂数据订阅发布框架，特别适用于多传感器需要数据仲裁的场景（低延时、高性能、动态采样、数据融合）。图 5.2-7 多核异构模块异构多核服务MasterCore.AppsServices异构多核服务 文件系统日志系统虚拟终端.套接字rptunOpenAMPVelaKernelPC 侧ConverterAppsAppsServices.套接字rptunFlashUART虚拟终端.文件系统日志系统OpenAMPVelaKernel共享内存/SPI/UART背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem158 异构多核时钟树服务：分布式多核时钟树可以在异构核间实现动态调节硬件时钟。异构多核保活服务：异构多核保活服务用于监听和诊断远端核心（上下电，异常诊断），同时也可以评估跨核通讯时延。异构多核远程应用调用服务：基于多核网络套接字的跨核远程应用调用服务。异构多核数据库：分布式多核数据库实现，可在异构核间共享数据库资源。技术介绍Xiaomi HyperOS 在 IoT 设备上使用 MiTEE，结合软硬件安全技术，在硬件层、内核层、框架层和应用层使用不同的安全技术，结合 Web Assembly 技术开发的 MCU 安全三重隔离技术，为应用提供安全保障。主要有如下的一些关键技术:硬件安全和可信执行环境：基于一体化软硬件平台，使用隔离的硬件资源结合可信执行环境构建整个系统的安全基石。系统安全：基于信任根建立的可信密钥链，提供安全启动、安全升级等功能，确保设备系统安全。安全框架：确保应用安全和应用敏感数据的安全，提供密钥库系统、加解密引擎、安全存储等服务，简化应用开发的难度。应用沙箱安全隔离：通过 Web Assembley 容器技术结合可信安全执行环境，进一步为应用提供了 MCU 安全三重隔离技术，保证 IoT 设备的安全性。技术架构5.2.3.2安全技术框架安全启动其他应用权限控制加解密引擎密钥库系统安全存储可信计算安全升级账号应用支付应用沙箱应用系统安全可信执行环境MiTEETrustZone硬件加解密引擎硬件唯一密钥(HUK)硬件安全安全框架图 5.2-8 Vela 安全技术架构背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem159MiTEE 可信执行环境关键技术1.安全启动：安全启动是在系统启动过程中，通过公钥验证程序或数据的签名，确保启动文件或程序的完整和可信，以防止在启动过程中加载并运行了未经授权的程序或镜像。Vela 安全启动，各镜像都需要一级级校验，保证启动过程中的信任链传递，签名验签通过后才允许加载和运行。在启动过程的任何阶段，如果签名验证失败，则启动过程会被终止。2.安全升级：Vela 支持通过 OTA(Over The Air)方式更新系统软件，实现了安全、高效的系统升级管理。系统软件更新前，系统更新程序验证 OTA 下载到设备 ROM 镜像的完整性和合法性。在完成如文件大小、哈希值、签名等校验后，开始更新分区。此外，常规启动（包括升级后的首次启动）也会在 bootloader 对下一阶段要启动的分区进行验证，以杜绝启动篡改过的非法系统。3.密钥库系统：Vela 轻量级密钥库系统，用于向应用程序提供密钥和证书的生命周期管理，同时为应用屏蔽不同的硬件安全环境（如 TEE 安全环境）的差异，简化应用开发的难度。包括密钥生成、安全加解密、安全存储、密钥认证等，确保整个存储和计算在安全硬件的隔离环境中。4.加解密引擎：Vela 加解密引擎支持主流的加解密算法，如 AES,RSA,MD5/SHA1/SHA,X.509 证书管理和 TLS/DTLS 等协议支持，并利用硬件的能力，通过 Vela 内核的 Crypto 框架对接硬件加速，进一步提高安全性和性能。Vela 用户系统ClientApplicationSecureFrameworkTEEClientAPI(GPCompatible)VelaGenericKernelMiTEE 系统TrustedApplicationTEEOSFrameworkVelaSecureKernelTrusted Application RuntimeWasmRuntimePC 侧ConverterSecureCPUSecureMemorySecureStorageHUKCryptoEngine.HardwarePlatform图 5.2-9 MiTEE 可信执行环境背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录HyperConnectService&FrameworkKernelEcosystem1605.权限控制：Vela 轻量级的权限控制，用于控制三方应用的权限，权限分为不同的类型，包括安装时权限、运行时权限。6.应用沙箱安全隔离：IoT MCU 设备通常没有硬件内存管理单元，无虚拟内存，应用使用的内存无隔离环境，导致应用间很难做到内存隔离。基于 Web Assembley 容器技术，保证应用和应用间的私有内存是相互隔离的，并且接口必须要导入才能被使用来保证安全性，因此恶意应用无法冒充合法应用的身份去获取敏感数据。因此，Vela 基于 Web Assembley 容器技术结合 TEE 可信执行环境，提供了 MCU 设备三重安全隔离技术来保障安全。TEE 和 REE 之间隔离：提供安全隔离的环境。TEE 内核和用户空间的 TA 隔离：保证用户开发的 TA 不会影响 TEE 安全系统。应用 TA 间，TA 和 Runtime 之间隔离：保证可信应用之间也无法相互获取对方的敏感信息。技术介绍Vela 低功耗图形渲染子系统主要包括 Widgets、动画、布局、输入事件、矢量绘制、字体和并行渲染等模块，满足硬件资源受限的 IoT 设备应用的开发。各模块介绍如下：UI组件（Widgets）:包括 Div,Image,Video,Chart,Swiper,RichText,List,Input,BarCode,Progress,TextArea 等。动效引擎模块（AnimEngine）：支持自定义属性插值动画和物理动画。布局模块（Layout）：Flex,Grid 等。输入事件模块（InputEvent）：支持多种输入设备，如 Mouse,Touch,Keyboard 等。2D图形模块（2Dgraphics）：包括点、线、圆、图片和文字等绘制。同时支持软件渲染和硬件加速渲染。矢量绘制（Vector-Drawing）：支持矢量图形渲染。并行渲染模块（Parellelrendering）：支持渲染任务并行处理，提高渲染效率。技术架构5.2.3.3轻量级图形渲染框架背景简介技术架构跨端层系统服务与框架系统内核 系统生态 开源开放附录Hype

0人已浏览 2023-12-08 181页 5星级

前 言 云网络（也称作 SDN）是实现公有云环境下多租户隔离的关键技术手段，而云网络网关（也称作 SDN 网关）作为云网络系统的关键转发网元，在云网络系统中扮演着至关重要的角色（注：在本技术白皮书中，“SDN”和“云网络”是可以相互替换的术语）。本技术白皮书对当前业界主流的云网络网关技术路线进行了较为全面、客观的优劣势分析，并结合对云网络网关相关技术的现状和趋势的研判，提出了将有状态网关和无状态网关解藕并分别采取不同技术路线实现高性能网关的技术思路。该技术思路不仅符合开放网络的理念，同时也顺应极简网络的潮流。目前移动云正携手合作伙伴推动上述技术路线的落地部署。通过该技术白皮书的技术分享，希望在业界形成更广泛的共识，共同推动云网络朝着更加开放的极简网络的方向演进。编写单位和人员 中国移动:姚军,王燕,徐小虎,徐硕，俞文俊，谭跃辉，李维亮，徐璐，金鹏程，主要负责技术白皮书整体章节的构思以及第一章、第二章以及 4.1 章节的编写以及所有章节的修订。北京邮电大学：潘恬，主要负责第二章的编写 英特尔:陈志华，主要负责 3.1 和 4.2 章节的编写 博通:张玺，何宗应，王娜，曲延光，主要负责 3.2 章节的编写 锐捷:吴航，邹赛虎，章建钦，主要负责 4.3 章节的编写 新华三：王雪，主要负责 4.3 章节的编写 目录 第 1 章 云网络网关功能定位及分类.1 1.1 无状态网关.1 1.2 有状态网关.2 第 2 章 当前云网络网关主要技术路线.3 2.1 NFV 形态网关技术路线.3 2.2 超融合硬件形态云网络网关技术路线.7 第 3 章 云网络网关相关技术现状和趋势.11 3.1 DPU/IPU.11 3.2 新一代可编程网络芯片.14 3.2.1 基于流水线逻辑的可编程.15 3.2.2 基于表项资源的可编程.18 3.2.3 基于队列调度的可编程.20 3.2.4 基于加速引擎的模块化设计.21 3.2.5 更加友好的可编程软件.22 第 4 章 开放云网络高性能网关技术路线.26 4.1 有状态网关和无状态网关解藕.26 4.2 有状态网关的技术路线.27 4.3 无状态网关的技术路线.30 缩略语列表.36 开放云网络之高性能网关技术白皮书 1 第 1 章 云网络网关功能定位及分类 云网络（也称作 SDN）是实现公有云环境下多租户隔离的关键技术手段，而云网络网关（也称作 SDN 网关）作为云网络系统的关键网元，在云网络系统中扮演着至关重要的角色，如实现租户流量集中转发控制（比如跨 VPC 的互访）和复杂业务处理逻辑（比如网络地址翻译即 NAT 和服务器负载均衡即 SLB）。按照是否需要维护租户流量的会话状态（比如 TCP/UDP 会话），可以将云网络网关分为无状态网关和有状态网关两类。顾名思义，无状态网关无需维护会话状态，而有状态网关则需维护会话状态。1.11.1 无状态网关 无状态网关通常只需要维护路由转发表和静态的地址映射表。VPC 网关（以下简称 VGW）和互联网网关（以下简称 IGW）是典型的无状态网关。VGW 主要维护 VPC 路由信息，IGW 除了维护 VPC 路由之外，通常还需要维护 VPC 私网地址和公网地址的 1:1 NAT 映射表和功能用于 1:1 NAT 功能。IGW 的 1:1 NAT 功能有别于下文中提到的 NAT 网关的功能，1:1 NAT 主要完成 VPC 地址到公网地址的 1:1 翻译，1:1 NAT 映射条目在租户购买公网 IP 地址之后就通过 2 SDN 集中控制器配置生成并下发到 IGW，而不是由途径 IGW 的 TCP/UDP 等流量触发创建，因此，IGW 的 1:1 NAT 条目数量取决于 IGW 所在的云数据中心对外已售卖的 EIP 地址数量，而与会话数量无关。1.21.2 有状态网关 有状态网关除了需要维护少量条目的路由转发表之外，需要动态创建并维护由途径的 TCP/UDP 等流量触发的会话连接表条目。NAT 网关和 SLB 网关是典型的有状态网关。NAT 网关主要完成 VPC 内主机主动访问互联网所需要的n:1 SNAT 功能，即源地址翻译功能，由于某个 VPC 内的多个 VPC 私有地址会复用一个关联到 NAT 网关的公网地址或 NAT 网关的私网地址（注：该私网地址将在 IGW 上完成 1:1 NAT，将该私网地址转化为公网地址）对外通信，NAT网关需要维护 TCP/UDP 会话连接状态来实现多种用途，比如保证一个内部主机主动发起的任意一个 TCP/UDP 会话的所有数据包在经过 NAT 网关时，源地址和源端口翻译之后的源地址和源端口始终保持不变。SLB 网关主要完成四层负载均衡能力，不论是采用 Full NAT 模式，DR 模式还是 DSR 模式，SLB 网关都需要跟踪维护会话连接状态信息，以保证同一 TCP/UDP 会话的流量始终被负载分担到服务器集群中某个固定的真实服务器 Real Server 或 L7 负载均衡服务器（比如 Ngnix 服务器）。此外，VPN 网关也属于有状态网关，因为其需要与对端 VPN 设备（如 VPN客户端）建立和维护 IPsec 或 SSL 会话连接。开放云网络之高性能网关技术白皮书 3 第 2 章 当前云网络网关主要技术路线 针对上述提到的云网络网关（包括有状态网关和无状态网关）的技术实现路线，不同云厂商采用的技术路线往往不尽相同，比如，有的完全采用 NFV 方式实现有状态网关和无状态网关，有的则采用超融合硬件设备来实现有状态网关和无状态网关，有的则采用 NFV 方式实现有状态网关而采用可编程硬件设备实现无状态网关。2.12.1 NFV 形态网关技术路线 云网络发展早期主要使用厂商硬件设备方案支撑相关网关业务发展，但随着云网络业务的快速发展，上述方案暴露出的问题越来越明显，比如设备的采购成本和维护成本高昂，设备的规格和特性无法快速升级迭代，已经严重制约了云网络的快速和可持续发展。由此，云网络网关开始往 NFV 网关技术方向演进，相关技术经过多年的发展，目前已经经过了三轮迭代演进，分别是 NFV 1.0、NFV2.0 和 NFV3.0。4 图 2-1 NFV 1.0 方案 基于 Linux 内核的 NFV1.0 方案，如图 2-1 所示。在 Linux 内核中，基于网络子系统的 Netfilter 模块，开源组织开发出了用于负载均衡的 LVS 和用于防火墙、NAT 的 Iptables。云厂商将这部分功能进行整理和自定义，完成了 NFV 1.0 的方案。该方案基于开源系统，可以在有新需求的时候进行快速开发迭代，并且该方案运行在 x86 服务器上，当设备性能和容量不够时可以方便快速地扩容 x86 服务器集群。NFV1.0 方案很好地满足了云网络业务快速开发迭代、快速扩容的需求，但是受限于 Linux 内核相对复杂冗长的报文处理逻辑，单个 NFV网元设备的性能始终无法达到较高水平。开放云网络之高性能网关技术白皮书 5 图 2-2 NFV 2.0 方案 随着 DPDK（Data Plane Development Kit，数据平面开发套件）技术的出现和不断成熟，业界开始使用 DPDK 技术开发用户态的网关系统，由此从 NFV 1.0 进入到 NFV 2.0 阶段。在如图 2-2 所示的 NFV 2.0 方案下，通过内核旁路、核隔离、独占网卡、内存巨页、网卡多队列和 DPDK 用户态协议栈等一系列优化技术的使用，单个 NFV 网元的性能得到了大幅提升，已经可以达到 10/25G网卡线速转发能力,相比内核态网关，大约有 10 倍以上的提升。6 图 2-3 NFV 3.0 方案 虽然在 NFV 2.0 阶段解决了性能问题，但随着云网络的进一步发展，弹性能力不足、开放性不够等新的问题又开始凸显出来。为进一步解决弹性扩容、支撑第三方网元等问题，业界开始了 NFV 3.0 的演进。NFV 3.0 方案如图 2-3 所示。在 NFV 3.0 方案中 NFV 网元不再部署在物理服务器上，而是使用通用云主机（即虚拟机），这样网元便拥有了普通云主机的极致灵活性，具有极强的弹性伸缩能力，也不再需要适配新的网卡硬件。网元开始被统一的 NFV 平台纳管调度，这就使得其开放性大幅提高，云上用户自己的第三方网元也可以运行到 NFV平台上，被 NFV 平台调度，提供服务给云上其他租户使用。基于 NFV 形态的 SDN 网元拥有了极致的弹性和开放性，这极大促进了云网络网关的快速发展。然而随着云网络的持续快速发展，在一些场景下开始出现一些 NFV 方案无法解决的问题，主要体现在以下两方面：1、无法处理超大单流 开放云网络之高性能网关技术白皮书 7 NFV 通过进行横向弹性扩容来支持大流量的处理，但这种大流量有个前提，即整体流量中流比较均匀且每条流都不能太大。如果流量中出现了一些超大的单流或者 HASH 分发不均匀，则 NFV 方案将遇到性能瓶颈，因为 NFV 方案中网络流量转发依赖于 CPU 核的软件转发，而单个 CPU 核的转发能力是存在一个上限的。当单个 CPU 核上承载的流量超过其上限时将会出现过载丢包，影响大单流的租户和该 CPU 核上的其他租户。2、超大规模部署下的高昂成本 NFV 的横向弹性扩容将会使得在处理超大带宽时引入超大规模的网元集群。假设某个集群达到了 1Tbps 的带宽，以单个虚拟网元 8Gbps 处理能力计算，则需要至少 125 台虚拟网元，如果考虑冗余容错等其他因素，则需要更多的虚拟网元。这将导致 NFV 集群的整体拥有成本即 TCO 变得十分高昂。2.22.2 超融合硬件形态云网络网关技术路线 近年来，一些云厂商采用了超融合硬件网关来实现高性能 SDN 网关功能。超融合硬件网关也称作 Server Switch，其包含了 Tofino、x86 CPU 甚至 FPGA等硬件资源，将所有网元包括有状态网关和无状态网关统一在超融合硬件网关内实现。8 图 2-4 融合 Tofino、x86、FPGA 的硬件设备 当前 Tofino 芯片的片上内存容量（SRAM、TCAM）相对较小，无法大规模云网络对数以百万计的 VPC 路由容量需求。为此，需要从多个维度对表项资源的分配使用进行优化：第一个维度是使用多级存储转发架构，用 FPGA 甚至CPU 作为可编程交换机中可编程交换芯片有限片上内存资源的补充，可编程芯片没有流表命中的流量将转到 FPGA 甚至 CPU 处理；第二个维度是使用多台可编程交换机实现表项的水平分割；第三个维度是在单台可编程交换机上，使用流水线折叠等技巧压缩表项的存储空间占用（如图 2-5 所示）；第四个维度是基于可编程交换机集群和 x86 服务器集群的两级转发处理架构，其中流量经过负载均衡器之后首先进入可编程交换机集群进行快速处理，因为可编程交换机交换芯片的片上内存容量有限，没有流表命中的流量将转到 x86 服务器集群处理。开放云网络之高性能网关技术白皮书 9 图 2-5 基于流水线折叠优化 Tofino 芯片的存储占用 超融合硬件形态网关的流量转发模型参考如下图 2-6 所示：图 2-6 超融合硬件网关的流量转发模型参考 首先，报文在 Tofino 查表命中会进行快速转发；然后，若报文未命中 Tofino表，会上送到 FPGA查表命中后转发；最后，如果报文均未命中 Tofino和 FPGA，会上送 CPU 后进行转发。超融合硬件网关优势主要体现在超强的包转发处理性能，例如单个 Tofino芯片就可以提供 12.8Tbps 的转发性能，相当于几十台的 x86 服务器的性能，且由于单个流水线转发吞吐极大，流量突发或汇聚产生的网关打爆导致丢包现 10 象将很少出现。超融合硬件网关同样存在以下两方面的不足：首先，超融合硬件网关将 CPU、DPU、FPGA 和可编程芯片（如 Tofino）集成在一个硬件设备上，且需要上述转发单元之间的转发逻辑协同，系统架构相对复杂，开发和维护技术门槛较高；其次，超融合硬件网关通常基于领域特定芯片提供极致的性能，这类芯片产量较少，盈利模式不稳定，因此其技术路线的发展也同样容易出现变数，例如 Intel突然宣布不再支持下一代 Tofino 芯片的研发，这给云厂商技术路线的选择带来挑战。开放云网络之高性能网关技术白皮书 11 第 3 章 云网络网关相关技术现状和趋势 3.13.1 DPU/IPU 根据统计，数据中心的网络带宽复合增长率从 10 年前的 30%，已经增加到近年的 45%。这些网络任务对计算能力的需求在不断增长，采用传统的主机CPU 处理的方式已经不堪重负。一方面为了减轻主机 CPU 的负载，另一方面提高网络吞吐的性能，数据中心的网络接口在不断的升级换代。从普通的传统网卡，到带硬件卸载的智能网卡，今天已经来到了 DPU（数据处理器）/IPU（基础设施处理器）的时代。DPU/IPU 作为一种新型的数据处理器，可以满足网络、存储和安全的硬件卸载和加速。针对 DPU/IPU 的设计，其实国内外有很多不同的架构，比如ASIC CPU、FPGA CPU、NP CPU 等等。由于 ASIC CPU 在大规模部署上有成本优势，且它通过 ASIC 可以提供强大的硬件卸载功能、通过 CPU 提供灵活的计算功能，ASIC CPU 架构将可能成为市场的主流方向。DPU/IPU 作为网络处理的接口，它首要解决的问题是带宽的吞吐。因此，25G、100G 接口是基本的要求，而 200G、400G 的更高速率接口也已经开始 12 商用。但是，仅仅具备网络接口还只能充当普通的网卡，还远远不能满足数据中心网络的要求。因此，DPU/IPU 还需要提供硬件卸载、加速的功能，才能释放其高达 400G 的网络吞吐性能：-支持主机或虚拟机使用高性能 SR-IOV 和传统虚拟化 VirtIO-OVS/OVS-DPDK 将数据平面和控制平面都能够卸载到 DPU 上，主机上无须运行这些软件，整个系统成为一个安全隔离和精简的平台-支持 RDMA/RoCE（远程内存直接访问），大幅度降低内存读写时延-专用芯片针对 IPsec、TLS、MACsec 等进行硬件卸载来提升性能。图 3-1 Intel IPU ES2000 系统结构示意图 ES2000 是 Intel 最新一代 IPU 产品。如上图所示，ES2000 具有 800M PPS处理能力的硬件 pipeline，支持多次 recirculation。另外，ES2000 包含 3 个开放云网络之高性能网关技术白皮书 13 LPDDR4 控制器，最大可支持 48GB DDR，报文处理所需的所有表项，包括 ACL表，路由表，各种查找表，连接跟踪表等，都可以直接存储在该 DDR 中，无需借助 Host Memory。正是如此，ES2000 可在支持千万级别的并发连接情况下，仍然能够支持 200Gbps 线速的双向处理。此外，ES2000 包含一个 200Gbps双向线速处理能力的 Inline IPSec 引擎。由此可见，ES2000 可以满足高性能有状态 SDN 网关的相关指标要求。图 3-2 英伟达 DPU BF3 系统结构示意图 如上图的英伟达 BlueField-3 产品（采用了 CX7 AISC 和 ARM A78 Hercules CPU core）是 CPU ASIC 架构的 DPU 的典型代表。这个架构采用了内置的 PCIe Switch，方便与主机、其它模块、甚至与多 DPU 的灵活互连，而 14 且互连带宽能够得到保障，也是 DPU 业界的发展趋势之一。图 3-3 BF2 与 BF3 关键性能指标对比 从上图中 BlueField-3 与其前一代产品即 BlueField-2 的硬件卸载性能对比数据可以看出，不管是接口带宽、加密性能、有状态的并发会话数量，BlueField-3 相比前一代产品都有了大幅提升，BlueField-3 完全可以满足高性能有状态 SDN 网关的相关指标要求。3.23.2 新一代可编程网络芯片 为了满足网络未来可见的发展，同时准备适应潜在的变化，网络数据面不仅在容量和性能上要保持超过摩尔定律的发展速度，在灵活性上也需要进一步提高。网络数据面的灵活性的一个重要体现就是网络数据面的可编程能力。上一代的高速大容量网络芯片的灵活性体现在如下层面：开放云网络之高性能网关技术白皮书 15 1）芯片转发层面 芯片厂商通常实现并提供标准的数据面转发功能。对于网关等特定应用场景的个性化转发需求，用户可以使用特定的芯片转发层面可编程语言，自行开发可编程应用程序，定制化报文处理以及转发的流水线。可编程应用程序通过芯片厂商提供的工具链生成二进制镜像文件并由 SDK 加载到芯片以实现定制化转发。2）SDK 层面 运行在主机 CPU 上的控制面通过 SDK API 调用传递信息到“片上资源管理逻辑”，进而通过内部通道来配置不同的片上逻辑，到达相应的目的。在此之上，为了能够适配更多的应用场景，并提升编程效率，新一代的可编程芯片通常如下特性：-基于流水线逻辑的可编程-基于表项资源的可编程-基于队列调度的可编程-基于加速引擎的模块化设计-更加友好的可编程软件 3.2.1 基于流水线逻辑的可编程 作为可编程芯片的核心功能，基于流水线逻辑的可编程已经广泛被上一代 16 可编程芯片所支持。一个数据包的处理，至少要涉及端口，入方向处理，查找表资源，数据包缓存和出方向处理。数据面在这几个环节的灵活性（可编程）至关重要。“入方向处理”部分，数据包包头的解析为后继动作提供重要输入，逻辑上可以表达为一个有向图，解析步骤的可定义，合理的解析深度是数据面可编程的重点之一。在“入方向处理”部分，数据包头解析之后，要根据层次化的结果，通过查找表，确定后继处理（转发处理）的数据和处理逻辑，这个部分，广域网 PE 设备的要求最高。转发处理的数据和处理逻辑确定之后，根据目的地址的转发处理是相对简单的，这里的挑战是查找表的设计与组织。这种挑战体现在三个方面：1）芯片设计环节 网络芯片通常会提供多种不同的查找方法，包括严格匹配(exact match)、最长匹配查找(ALPM/LPM)、地址索引查找以及 TCAM 查找。查找表内容（包括 Key 以及结果）通常放在内存（SRAM 以及 TCAM）里面。芯片设计时候需要根据其策略确定查找表硬件资源的基本单元构成、支持的查找次数、内存大小以及布局方式。尽管不同芯片设计偏向不同，主流芯片通常使用并行查找、查找的 match key 与查找结果相分离、查找表资源跨 stage 局部或者全局共享、查找表存储和处理逻辑的分离、片下可扩展表项资源等技巧以达到在可编程硬件开放云网络之高性能网关技术白皮书 17 资源最大化的前提下能够实现功耗和成本的平衡。2）可编程应用程序开发环节 网关数据平面的开发者需要根据自己的业务诉求设计并定义各张逻辑表以及相应的转发流水线。不同的设计方法，虽然可以达到相同的系统功能，但可能逻辑表容量可能会有极大影响。所以逻辑表以及流水线设计需要非常仔细。同时为了尽量获得更大的表容量，在可编程芯片开发工具链的帮助下，需要对逻辑表以及流水线设计进一步调优。3）可编程芯片开发工具链 通常由芯片厂商提供，用以将前述可编程应用程序高效地映射到芯片的物理资源。工具链效能会极大影响开发者可见的逻辑表提供能力以及物理资源利用效率。“入方向处理”的后部分，是访问控制列表处理和 QOS 处理，访问控制列表处理结果可以影响转发结果，或者为后续的 QOS 处理提供数据流的染色；访问控制列表一般采用精确匹配或者掩码匹配，访问控制列表查找键值的组成灵活性，宽度和逻辑操作能力是数据面可编程的另外一个重点，这里的可编程并不是指程序逻辑的多样性，而是程序入数据的宽度/广度。而“出方向处理”和“入方向处理”相比，减少了转发处理部分，增加了数据包头的编辑部分。“出方向处理”数据包头的解析是网关功能的一个重要支持基础，例如，18 NAT 功能一般安排在入方向处理完成，出方向的一些功能可能需要根据 NAT 后的新的包头来处理，这样“出方向处理”数据包头的解析就是一项必不可少的步骤。“出方向处理”数据包头的编辑能力是数据面灵活性又一重点，前面的处理步骤产生了众多的状态和结果，根据这些状态和结果，生成相应的新的数据包头，体现了数据面在一个处理节点上的处理结果，同时又为数据面的下一个节点提供新的信息。上述对“入方向处理”和“出方向处理”的简而又简的描述，可以看出目前数据面可编程的着重点在数据包解析，转发查找和数据包编辑。3.2.2 基于表项资源的可编程 虽然基于流水线的可编程极大的增强了网络转发芯片的灵活性，但是实际的开发和部署中，芯片表项资源数量的限制成为了很多新型应用的性能瓶颈。比如在数据中心网关应用中，通常会需要超大规模的路由表，NAT 表以及 VxLAN封装/解封装表，而传统的可编程网络转发芯片对这种场景的支持有限。商业网络转发芯片会内置一定规模的表项存储资源用于表项查找，如SRAM 和 TCAM。然而，上一代的可编程网络芯片通常存在如下问题：1）资源规模较小 市面上常见的网络转发芯片的内置资源规模通常只能支持万级或十万级的开放云网络之高性能网关技术白皮书 19 路由规模，无法支撑现代数据中心中网关，移动网数据面功能等海量用户场景。近年来，业界已经关注到这个问题并着手解决，如博通公司的量产可编程网络转发芯片的内置资源已经可以支撑两百万以上的路由表，并计划在下一代可编程网络转发芯片中继续提升内置表项的容量。2）资源的分配的灵活性较差 在现有量产的可编程交换芯片中，一个硬件存储资源块区只能被分配到一个“Stage”中，所以用户需要对这些硬件资源进行非常仔细的管理和规划。在新一代的网络转发芯片中，芯片内部的存储资源通常被抽象为一个资源池，并可以被所有的“Stage”引用，而不再需要考虑和设置资源和“Stage”之间的映射关系，极大的提高了全局资源利用率。3）芯片资源的定义和流水线设计的耦合性较强 如上所说，当一个功能表项需要的资源数量过多时，需要在设计流水线时进行特殊的设计，如采用多次内容相同的查找来实现海量表项的功能。而这给芯片流水线设计的工程师带来了很大的困难，因为工程师可能需要定义多种不同的流水线结构来应对不同的应用场景。新一代的可编程交换芯片为了解决这个问题，将资源的可编程和流水线的可编程彻底解耦。用户可以灵活的定义芯片内部资源的分配情况，并可以独立于流水线设计进行内部资源分配模板的加载。这样带来的好处是针对不同应用场景的同类型产品，使用一套流水线模板和多套芯片资源配置模板即可完成对设 20 备的定制。比如，一个网关产品对于 NAT 需求较为强烈的场景和对路由需求较为强烈的场景，只需要准备两个不同的资源配置模板即可，而流水线模板不需要做任何变化。3.2.3 基于队列调度的可编程 以往的可编程网络转发芯片主要覆盖了数据面的流水线处理，但是对于MMU 和流量调度的可编程则支持非常有限。比如对于 MMU，并不在传统的“可编程”范畴之内 流水线的开发工程师只需要关注在入/出流水线的逻辑表项设计和资源配置即可，而 MMU 只是作为一个报文缓存和转发的单元被独立在可编程视图之外，而这带来了整个可编程逻辑的割裂。以博通的 TD4 为代表的新一代的可编程网络转发芯片，已经把 MMU 的抽象成一个加速引擎，并将其引入到整个可编程的视图之中。这样，开发工程师可以非常清楚的确认在连接到 MMU 的总线上，什么信号需要被入流水线送到MMU，以及出流水线需要得到什么样的信号。除此之外，对于很多运营商应用来说，网络转发设备需要针对不同用户等级提供对应的 SLA 保障服务，而这对网络转发设备提出了如下要求：-队列数量的要求-调度层次以及调度模式的灵活配置 开放云网络之高性能网关技术白皮书 21 -海量的计数器、流量整形器资源，并可灵活挂载到不同的用户流量上 传统的网络转发芯片通常只支持非常有限的 HQoS 调度层级，并且调度模式固化，无法通过编程的方式来自由和灵活的定义 HQoS 的调度模型。新型的可编程网络转发芯片，比如博通的 StrataDNX 系列，则同样也支持流量调度的可编程，包括可以允许用户灵活配置 HQoS 的层数，调度树状图以及灵活的限速等功能。3.2.4 基于加速引擎的模块化设计 在传统的可编程网络转发芯片中，虽然提供给了用户能够自行定义流水线的能力，但是复杂度却较高。很多时候，用户需要通过 ALU 配合流水线设计来实现很多额外的操作，比如，序列号的产生和记录，从一个流中的多层报文头中提取最终的 QoS 信息，或者当目的地是 ECMP 或者 DLB 时的处理等，都需要用户进行繁琐的设计进行实现。上述设计极大的增加了开发工程师的工作量，并且会使得流水线设计代码冗长且降低可读性。同时，当芯片的可编程架构或编程语言出现升级时，也需要对这些功能视情况进行重新设计。在新一代的可编程网络转发芯片中，一个明显的趋势是将这些常用的功能在硬件层面抽象成一个加速器模块，并且允许在可编程设计中通过可编程语言，在需要调用的流水线处直接调用这个加速器模块进行处理。这样带来的好处是，芯片的通用逻辑被抽象和屏蔽掉了，而开发工程师不再需要处理这部分内容；并 22 且由于业界主流的网络转发芯片厂商已经具有了丰富的部署经验，调用这些预定义的硬件加速器的稳定性会更好，并且效率会更为高效。以博通的 StrataXGS TD4 芯片为例，该芯片已经集成了几十个预置的加速引擎，可以被应用到入流水线，出流水线，以及一些和 MMU，Counter 关联的各个位置。从功能角度讲，这些加速引擎包涵盖了正确性检查，QoS，聚合，ECMP，DLB，MMU，大象流处理等多种常用功能。用户在设计流水线时，只需要通过 NPL 调用对应的加速引擎库函数，就可以简单而快速的实现这些功能。3.2.5 更加友好的可编程软件 网络数据面的编程与普通 CPU 应用程序的编程是截然不同的：-网络面的编程往往是覆盖数据包从入到出的全过程。-网络面的编程是数据流驱动的，而不是控制流驱动的。-网络面编程的一个典型特性是表项查找，查找表的生成是控制面预先生成的，一定程度上网络面编程和控制面编程是紧密耦合的。除了使用常用的 C 语言之外，网络数据面应用程序通常使用为网络数据面编程定制开发的编程语言以更好地描述逻辑表和报文处理转发流水线，尤其重要地是如何更高效地把网络芯片的硬件能力和开发者的易用性完美结合起来。为了到达上述目的，网络可编程语言通常需要具备如下特点：-高效、简洁和易于使用 开放云网络之高性能网关技术白皮书 23 -丰富的逻辑表定义能力-函数原语定义能力-支持并行查找-同一个报文命中多次查找时的冲突处理-报文的可视化能力-运行时的可编程能力-以简单地方式支持与控制面的高效集成-多种硬件芯片的支持能力 目前业内主流的网络可编程语言包括：-NPL(Network Programming Language,https:/nplang.org/)-P4（https:/opennetworking.org/p4/）网络数据面可编程开发工具链里，编译器无疑处于技术核心位置，但仍需要其它工具辅助，以共建一套如下图的环境。图 3-4 可编程芯片开发工具链参考 24 编译器通常分为处理语言、与目标平台无关的前端编译器和与特定硬件能力绑定的后端编译器。对于前端编译器的设计，可以借鉴成熟的 C/C 等通用编译器，此外，鉴于减少在硬件平台上出错几率的考虑，通常需要提供对仿真器的支持。与特定硬件架构耦合的后端编译器的设计，除了编译速度、编译选项等这些通常的考量点外，还需要覆盖以下：1）逻辑表的查找关键字和内容到物理表的映射与优化 可编程网关使用的查找表通常分为精确匹配表、掩码匹配表和索引匹配表，因考虑成本、功耗等因素，容量有限。编译器对物理表映射的处理方式决定了物理存储空间的使用效率。2）报文解析、逻辑变量、逻辑运算、报文编辑等至物理资源的映射和优化 基于网络芯片的可编程网关，需要解析报文、通过查找表，指明报文路径、统计、整型并编辑报文。除了表项空间这个主要点之外，其余功能亦受资源大小限制。3）对成熟通用功能的支持 尽管可编程网关因为场景不同，需求变化很大，但毕竟仍属于网络应用的一部分。已成熟的固定流水线交换芯片已经经过大规模实践应用，若将不需要变化的通用功能，提供类似于库函数的调用，即能节约成本，亦可减少出错概率。开放云网络之高性能网关技术白皮书 25 4）资源约束检查 不同芯片有各自的架构和资源限制，如何提供基于特定平台的资源约束文件并进行检查，是后端编译器设计里很重要的一个步骤。5）尽可能完善的错误提示信息 后端编译器使用前端编译器的生成文件，基本不可能如前端编译器那样提供准确的错误代码行信息，这也导致了后端编译的错误定位相对困难。因此，能否提供有效的错误定位信息，也是后端编译器设计的一个重要考虑点。26 第 4 章 开放云网络高性能网关技术路线 4.14.1 有状态网关和无状态网关解藕 当前业界针对高性能 SDN 网关实现的技术路线，通常采用将有状态网关和无状态网关功能耦合的超融合网关设计思路，这类超融合网关不仅需要维护大量的路由表项，也需要维护会话创建的会话连接表项，比如将 NAT GW 的 n:1 NAT 功能集成到 IGW 上。但是，有状态网关和无状态网关的主要功能诉求不同，有状态网关和无状态网关紧耦合的超融合网关实现导致 SDN 系统的可扩展性差，要么是（NFV 形态网关）转发性能不足，要么是（多芯片硬件网关）系统架构复杂。无状态网关（如 VGW，IGW）的核心诉求是高吞吐能力（如 Tbps 级别线速转发能力）以及超大规模硬件表项规格能力(如 10K 以上的 VRF 规格，10K 以上的隧道规格，10M 以上主机路由表项规格)。因此，无状态网关的最佳技术路线是采用具有超大规模硬件表资源且高吞吐的可编程交换芯片实现上述两个核心诉求。由此带来的好处是系统架构简单，不存在多个转发逻辑单元（比如交换芯片即 ASIC 和 FPGA）之间的协同，系统开发维护技术门槛较低。此外，由于系统开放性好，集成第三方的具备高吞吐转发能力且具备大规模路由表能力的开放云网络之高性能网关技术白皮书 27 商业路由器产品也具有一定的可行性。有状态网关（如 NAT GW，SLB）的核心诉求是超大规模新建会话（如百万甚至千万级别）和并发会话（如千万甚至亿级别）处理能力，对网络转发逻辑的灵活性要求较高（如会话状态跟踪、会话限速），部分场景也存在高吞吐需求。最大新建会话能力是指每秒最大可处理的新建会话连接数，是个性能指标，这个指标与网关的计算性能密切相关。最大并发会话能力是指网关可以维持的最大会话连接数，是个压力指标，一旦会话数量达到这个最大限制，新的会话就无法被建立起来，这个指标与网关的内存大小有关。此外，由于转发性能加速的需求，主机内存中的并发会话连接表往往会被卸载到硬件转发芯片的 SRAM 中。有状态网关的最佳技术路线是采用 NFV 形态设备，通过扩展主机内存和增加 CPU核数来解决大规模新建和并发会话处理需求，并通过 DPU/IPU 卡所具备的超大流表缓存能力，按需将流表信息加载到 DPU/IPU 以便进行硬件卸载，即将有数据转发需求的流表条目卸载到 IPU/DPU 的转发加速引擎，以此提升数据包转发性能。服务器是通用设备，DPU/IPU 通过标准的 PCIE 接口插槽加入服务器，整体系统开放解藕程度较高，可以实现快速迭代。4.24.2 有状态网关的技术路线 为解决传统 NFV 形态的 SDN 网关转发性能瓶颈，可以采用 CPU IPU 的硬件架构来实现新型的 SDN 网关。如下图所示，SDN 网关的各种核心应用运行在 CPU 上，通过慢速路径和快速路径的分离技术，将快速路径处理部分卸载 28 到 IPU 上来实现。利用 IPU 的 P4 可编程能力，可以根据上层业务需求，灵活的、有针对性的定制 IPU 上 Pipeline 转发行为，结合 IPU 千万级别的状态流表支持能力，在 IPU 上实现高性能、高复杂度、高定制化、有状态的快速转发。图 4-1 基于英特尔 CPU 和 IPU 的网关架构 从软件架构层面来讲，SDN 网关核心软件的底层由一组异构流水线控制软件构成，并面向网元业务功能做统一接口适配。网关核心软件的上层包括网络数据面软件和控制面软件。对于有状态的数据面软件，比如会话新建、流量均衡策略、连接跟踪等，提供模块化的网络功能参考设计，允许定制化模块的替换和重新组合。以 4 层流量均衡(L4LB)为例，其快速匹配转发表可以由 P4 进行描述，然后把编译器生成的资源文件加载到目标系统的包处理流水线，如：IPU 的硬件Pipeline。L4LB 网络功能模块对新会话、均衡算法及服务器选择等进行常规处开放云网络之高性能网关技术白皮书 29 理，并将结果同步下沉到加速流水线上的快速匹配转发表，而后序的相同会话将由加速流水线进行高效转发。Infrastructure Programmer Development Kit(IPDK)是一个开源的驱动和 API 框架（详细信息可参考 IPDK 网站：ipdk.io），针对基础设施提供提供卸载与管理，实现厂商和平台无关性。如下图所示，IPDK 包含多个功能组件，为网络虚拟化、存储虚拟化、Security、NFV 等多个应用场景提供软件框架支持。CPU IPU 架构的 SDN 网关可以使用 IPDK 来构建底层的软件框架，一方面屏蔽底层硬件细节，实现硬件功能抽象化、跨平台化和高复用性；另一方面，对上层应用提供统一的 API 接口。图 4-2 IPDK 架构参考 采用该架构的 SDN 网关，在延续 CPU 平台良好的通用性、扩展性和灵活 30 性的同时，还能借助 IPU 提供更高性能、更低时延的服务质量保障。4.34.3 无状态网关的技术路线 网络可编程允许用户对网络数据面进行功能定义，构建按需定制、快速匹配个性化需求的网络，可以增强云服务商的网络自主可控能力，实现包括无状态网关在内网络功能。自 2014 年 Barefoot（2019 年被 Intel 收购）推出 P4 网络编程语言之后，网络可编程技术得到了快速发展，在可编程网关、数据中心互联、带内遥测、自动化运维等方面已经有广泛实践和应用案例。实现网络编程的技术基础是可编程芯片和网络编程语言，目前基本上大部分交换芯片厂商都号称他们的芯片支持可编程，但是从业界生态和技术成熟度来看，目前主要有因特尔的“P4语言 Tofino芯片”、思科的“P4语言 Silicon One 芯片”、博通的“NPL 语言 TD/Jericho 系列芯片”三种技术路线。因特尔的 Tofino 芯片系列 在 2019 年被因特尔收购之前，Barefoot Networks 是网络可编程领域的主要贡献者，其 2014 年发布 P4 可编程语言将网络推向了可编程时代。思科（Nexus 3400 系列）、Arista（7170 系列）等顶级网络供应商均推出基于可编程交换芯片的产品，谷歌、阿里、腾讯等大型互联网公司基于 P4 Tofino 架开放云网络之高性能网关技术白皮书 31 构按需定制、快速匹配自身网络个性化需求，在数据中心互联、带内遥测、自动化运维等方面对网络数据面进行功能定义部署大规模部署可编程设备，从而增强网络的自主可控性。基于 P4 Tofino 芯片的网络编程是目前参与人员最多、经验最丰富生态最好的技术路线。图 4-3 Tofino 1 和 Tofino 2 芯片家族 Barefoot Networks 的 Tofino 芯片规划了三代产品，2016 年推出 6.4T 的Tofino 1，2018 年推出了 12.8T 的 Tofino 2，Barefoot 在 2019 年被因特尔收购之后 25.6T 的 Tofino 3 没有再发布，并且于 2023 年初因特尔对外宣布停止Tofino 芯片的演进计划。因此，目前生态最好的 P4 Tofino 技术路线陷入了无法继续演进的窘境。未来可编程技术会如何发展，该选择哪个技术路线作为未来的发现方向成为业内需要共同面对的一个问题。思科的 Silicon One 芯片系列 思科于 2019 年对外发布 Silicon One 芯片。思科 SilconOne 系列芯片具 32 备大表项、大缓存及丰富的特性，Run to complete pipeline 架构优化报文转发，基于 P4 可编程语言（NPU），转发引擎可编程。面向园区网、运营商骨干网、数据中心网络等场景的高中低端路由器和交换机产品，提供完整的芯片解决方案，提供丰富的数据通信管理、内部和外部包缓存管理和 Telemetry 等功能。思科当前发布的产品中，既有框式设备（交换网、线卡），也有丰富的盒式产品，并进一步支持 SONiC 系统。目前思科的 SilconOne 芯片只对全球六大云服务提供商提供测试支持，P4 可编程方面暂未对外开发，仅可根据需求进行定制开发。对于研发无状态网关产品来说，需提需求，通过思科支持实现。图 4-4 Cisco SiliconOne 芯片家族 博通 StrataXGS 芯片系列 博通（Broadcom）是以太网交换芯片产品的主要供应商，在大型数据中心开放云网络之高性能网关技术白皮书 33 场景博通占据了绝大多数的市场份额。博通在交换机芯片领域推出了两大产品线：StrataDNX 和 StrataXGS，其中 DNX 系列主要用于大缓存及大表项的核心交换机场景，StrataXGS 则用于常规核心交换机场景及数据中心交换机场景。根据使用场景对端口速率和端口缓存及表项大小要求的不同，StrataXGS 主要包括 Trident 和 Tomahawk 两个系列，前者功能特性丰富，后者吞吐性能强大。2017 年博通对 Trident3-X7 交换芯片升级支持网络可编程，并在后续的 TD4系列芯片均支持可编程特性。为了丰富和培育网络可编程生态，2019 年博通发布 TD4 交换芯片的同时对外发布了 NPL 网络编程语言，可基于“TD4 芯片 NPL 语言”进行网络可编程开发。图 4-5 博通 StrataXGS 芯片家族 NPL 可编程支持的 Tile-mode 模式具备很好的可编程灵活性，只需要一套代码就可以涵盖多个不同的场景。基于 Tile-mode 特性可以实现不同应用场景下表项资源的动态灵活调整，比如在 L3 模式下可以实现大的路由表，在 L2 模式下可以实现大的 MAC 地址表等，一套 NPL 代码就可以同时实现多种场景特性，通过 SDK 的动态配置就可以实现应用模式的灵活调整切换。34 随着可编程交换芯片应用的推广，博通在 2020 年针对应用最广泛的网关需求场景推出了 Trident4 SmartToR 芯片。SmartToR 芯片硬件表规格相对其他 Trident 芯片而言，提升了一个数量级，可实现数百万级的路由转发表和百万 级别的五元组流表，加上基于不同网络功能需求灵活重构转发表资源的能力（比如，灵活分配 MAC 表、主机路由表资源和流表等），Trident4 SmartToR芯片适用于 NAT 网关、DDOS 攻击检测、网络分流，负载均衡、VXLAN 网关等应用场景，特别是有大规模路由转发表需求的无状态 SDN 网关的应用场景。博通 StrataDNX 芯片系列 StrataDNX 系列芯片秉承一贯的可编程性，特别是从现已广泛部署的Jericho2 一代开始，增强了其可编程性的开放程度。该芯片家族及后续产品提供了业界独一无二的可编程架构，除了管线节点可编程外，还可以进行管线延展，在增加了处理流程的同时而没有损失任何转发性能。另外，Jericho2 支持模块化表项结构，所有表项共享同一块物理缓存，极大增加了片上资源的使用效率。管线上所有处理节点可以并行访问，根据不同的应用场景进行逻辑表项的灵活划分，使得同样的硬件可以应用在完全不同的使用场景。目前行业中量产的可编程交换芯片通常只支持固定数量的“Stage”，用户则在这些固定的“Stage”下进行流表的编程开发。但是，尽管在每个“Stage”下可以通过并行查找来增加支持的数据面协议数量，然而，当需要支持数据面协议数量较多，且复杂度较高的情况时，有限的“Stage”设计仍然无法完全满足需求，毕竟很多“Stage”的编程操作需要上一个 Stage 处理得到的结果。为了开放云网络之高性能网关技术白皮书 35 解决这个问题，Jerico2 系列芯片基于 PEM(Programmable Element Matrix)特性来延展 pipeline,增加新的 Stage，并且不会对带宽性能造成任何影响。而且可以执行算术运算（比如加法、减法、乘法），条件比较（比如=,!=,等等），逻辑以及比特操作等等。这种设计带来了两个好处：首先整个流水线的“Stage”数量可以通过引用可编程资源池被极大的扩展，解决了“Stage”数量固定的问题；除此之外，用户可以基于博通公司预置的成熟流水线设计之上，增加自己设计的功能，从而极大的降低功能风险并缩短开发时间。在传统可编程交换芯片中，一个硬件存储资源块区（通常为 SRAM 和 TCAM）只能被分配到一个“Stage”中，所以用户需要对这些硬件资源进行非常仔细的管理和规划。为了解决这个问题，博通公司开发了 MDB(Modular Database)模块化数据库架构，对 SRAM 和 TCAM 资源进行了抽象管理，允许一个网络应用的流表存储空间从另一个网络应用的存储空间中“借用”资源，来提高全局资源利用率。最为激动人心的是，这个全局的硬件存储资源池可以被所有的“Stage”引用，而不再需要考虑和设置资源和“Stage”之间的映射关系。博通公司提供了 MDB compiler 工具，通过友好的界面工具提供用户自行分配硬件资源的功能。综上所述，目前基于网络可编程芯片技术实现无状态网关有三条技术路线可供选择，分别是：“Tofino P4”、“SiliconOne P4”、“TD/JR NPL”。由于无状态网关对于大规模表项资源的需要，因此表项容量太小的可编程交换芯片无法满足大规模云网络的需求。36 缩略语列表 缩略语 英文全名 中文解释 SDN Software Defined Network 软件定义网络 NFV Network Function Virtualization 网络功能虚拟化 VPC Virtual Private Cloud 虚拟私有云 IGW Internet Gateway 互联网网关 VGW VPC Gateway VPC 网关 SLB Server Load-Balancing 服务器负载均衡 NAT Network Address Translation 网络地址翻译 DR Direct Routing 直接路由 DSR Direct Sever Return 直接服务器返回 LVS Linux Virtual Server Linux 虚拟服务器 DPDK Data Plane Development Kit 数据平面开发套件 CPU Central Processing Unit 中央处理器 DPU Data Processing Unit 数据处理器 IPU Infrastructure Processing Unit 基础设施处理器 FPGA FieldField Programmable Gate Array 现场可编程逻辑门阵列 开放云网络之高性能网关技术白皮书 37 ASIC Application Specific Integrated Circuit 专用集成电路 OVS Open Virtual Switch 开放虚拟交换机 ACL Access Control List 访问控制列表 SRAM Static Random Access Memory 静态随机存取存储器 TCAM Ternary Content Addressable Memory 三态内容寻址存储器 NP Network Processor 网络处理器 DDR Double Data Rate SDRAM 双倍数据速率 SDRAM SDK Software development kit 软件开发套件 API Application Programming Interface 应用程序编程接口 IPDK Infrastructure Programmer Development Kit 基础设施编程开发套件 DOCA Data-Center-Infrastructure-On-A-Chip Architecture 芯片架构上的数据中心基础架构开发平台 NPL Network Programming Language 网络编程语言 UPF User Plane Function 用户面功能 GTP GPRS Tunneling Protocol GPRS 隧道协议 LPM Longest Prefix Match 最长前缀匹配 MMU Memory Management Unit 内存管理单元 ECMP Equal-Cost Muti-pathing 等价多路径 38 DLB Dynamic Load-balancing 动态负载均衡 MDB Modular Database 模块化数据库 PEM Programmable Element Matrix 可编程要素矩阵 VXLAN Virtual eXtended LAN 虚拟扩展局域网 VRF Virtual Routing and Forwarding 虚拟路由转发 VPN Virtual Private Network 虚拟私有网

0人已浏览 2023-12-07 43页 5星级

点击查看更多山东大学：逆变类电源接入场景下传统方向保护适应性分析（2023）（20页）.pdf精彩内容。

0人已浏览 2023-12-07 20页 5星级

点击查看更多中国移动：2023量子密钥无线分发（Q 波）技术白皮书（22页）.pdf精彩内容。

0人已浏览 2023-12-06 22页 5星级

开放群岛开源社区跨境数据流通小组2023 年 12 月2023The White Paper on Cross-border Data Transfer Compliance and Technology Applications合规与技术应用白皮书跨境数据流通跨境数据流通跨境数据流通合规与技术应用白皮书合规与技术应用白皮书（2023 年）年）开放群岛开源社区跨境数据流通小组2023 年 12 月版权声明本白皮书版权属于开放群岛开源社区跨境数据流通小组所有，依据 CCBY-NC-SA4.0（http:/creativecommons.org/licenses/by-nc-sa/4.0/）许可证进行授权，并受法律保护。转载、编撰或利用其他方式使用本白皮书文字或观点，应注明来源。违反上述声明者，编者将追究其相关法律责任。编制说明本白皮书由开放群岛开源社区跨境数据流通小组牵头撰写，限于撰写组时间、知识局限等因素，内容恐有疏漏，烦请各位读者不吝指正。本报告在撰写过程中得到了开放群岛开源社区跨境数据流通小组各成员单位的大力支持，在此特别感谢参编单位的各位专家以及联合国世界丝路论坛数字经济研究院院长、浙江大学网络空间安全学院王春晖教授。编写单位编写单位（排名不分先后）：联易融数字科技集团有限公司、广东广和律师事务所、深圳数据交易所、深圳市星创数字研究中心、广东卓建律师事务所、北京信联数安科技有限公司、勤达睿（中国）信息科技有限公司、北京植德（深圳）律师事务所、南方科技大学深圳国家应用数学中心、江苏无锡大数据交易有限公司、数交数据经纪（深圳）有限公司、深圳职业技术大学、深圳赛西信息技术有限公司、南昌大学、万商天勤（深圳）律师事务所、万商天勤（杭州）律师事务所、华东江苏大数据交易中心股份有限公司、深圳信息通信研究院、北京中企数安咨询有限公司、大数据协同安全技术国家工程研究中心、中国电信股份有限公司研究院、邓白氏中国、北京市汉坤（深圳）律师事务所、北京市京师（深圳）律师事务所、日本野村综合研究所、广东经天律师事务所、粤港澳大湾区大数据研究院、广东际唐律师事务所、福建旭丰律师事务所、北京万商天勤律师事务所、优刻得科技股份有限公司、中诚信征信有限公司、浙江九鑫智能科技有限公司、深圳市电子商务安全证书管理有限公司、厦门海峡链科技有限公司、四川久远银海软件股份有限公司、领禹智通数据科技（上海）有限公司、三六零数字安全科技集团有限公司、腾讯科技（深圳）有限公司、贵州财经大学、青岛国创智能家电研究院有限公司、南方科技大学智能管理与创新发展研究中心、奇安信科技集团股份有限公司、南财合规科技研究院、数库（上海）科技有限公司1 编写编写组主要成员组主要成员（排名不分先后）：陈 曦李如先王 冠丁振赣周宏张巍宫仁海李兰兰刘 媛陈宁王艺郭巧真王以玮史亦言于丹丽张雅婷王鑫罗欣劳国威易海博谭瑞琥柴颖戴志敏吴朝阳周阅杨淋雨尤磊张昊杨子安王雪纯何思婷周钢李东阳陈璐王雨薇李清莲宋杰李丹袁芸夏彦廖瞰曦赵鹏飞陈慧曾铮陈嘉琪袁玥成雨杨杜瑜莫斯航王岩飞樊思琪李智慧王孝冉谢贤保李昌旺舒青云王琼彭晓燕孙红李和清侯子博刘沛郭婷程晶晶彭文琪魏倩黄念念王澜吴一吴昊马兰阮舟王志辉王超博陈建宏张长彬吴治中罗瑶邓祥静胡浩2魏安迪崔如德李坤贺志生王永霞代威丁红发杨楠梁娜黄伟周谢军蔡小芳唐鑫蔡欢马纪园肖苗苗刘岭峰蔡剑戈王青兰朱琳蒙雄发李文塔陈俊昌陆忠明1前 言随着信息技术的飞速发展，数字贸易逐步成为国际贸易发展新趋势和贸易增长新引擎。跨境数据流通是开展数字贸易的前提条件，是世界经济流动新要素。全球数据流动对经济增长有明显的拉动效应。世界贸易组织数据显示，2022 年，全球跨境数据流通规模增长 120.6%，数字服务贸易规模增长 36.9%，均高于同期的全球服务贸易和货物贸易的增速。跨境数据流通对贸易模式、贸易结构、全球贸易规则和世界贸易格局产生深刻影响。加强数据跨境流动探索，已成为打造我国在全球数字经济发展格局中优势的关键。2022 年 12 月，中共中央国务院关于构建数据基础制度更好发挥数据要素作用的意见提出，坚持开放发展，推动数据跨境双向有序流动。2023 年 9 月28 日，国家互联网信息办公室发布规范和促进数据跨境流动规定（征求意见稿），该规定在个保法以及相关数据跨境传输规定的基础上，降低了相关主体在数据出境时的合规成本，加快了我国数据出境的效率，有利于促进国际机构跨境活动的高效运营。截至目前，全国已有北京、上海、广州、深圳等 20 余地出台“数据相关条例”，推进数据跨境流动工作。在此背景下，联易融于 2022 年受邀牵头创建开放群岛跨境数据流通小组，以助力企业合法合规实现数据跨境流通，业务出海为目标；结合业务模式与技术能力推进合法合规可落地技术解决方案。去年组织三十余家境内外机构编写了跨境数据流通合规与技术应用白皮书（2022），收到广泛关注。据不完全统计，发布之初，就得到了超过 30W 次的阅读量，以及包括主流媒体在内的超过500 家媒体等机构转载。跨境数据流通对贸易模式、贸易结构、全球贸易规则和世界贸易格局产生深刻影响。加强数据跨境流动探索，已成为打造我国在全球数字经济发展格局中优势的关键。2023 年联易融继续牵头并携深数所、信通院等 40 多家机构撰写跨境数据流通合规与技术应用白皮书（以下简称白皮书（2023）。白皮书（2023）进一步拓宽国际视野和跨境场景，聚焦粤港澳大湾区优势，具有以下特点：第一，国际视野更加开阔，追踪欧美日韩最新跨境数据合规法律动态，增补我国重要贸易伙伴以及邻近国家和地区的法律环境分析，如东盟成员国、沙特阿拉伯、俄罗斯、中国台湾等地，并与中国大陆的数据跨境规则进行对比，为数据处理者与相关国家或地区开展数据跨境活动时提供参考。数据跨境的规范更需要不同国家间相互合作才能完成，白皮书（2023）对当今主要的数据跨境流通2国际条约也加以介绍，为探索跨国合作提供新的视角。第二，数据跨境场景更加丰富，在关注跨境重点行业的基础上，发掘新场景和新应用。例如，从民生出发，关注大湾区居民异地银行或证券开户的个人数据跨境流动。从工业智造出发，关注关键工业数据合规跨境提升芯片制作工艺。从公共健康出发，关注跨境就医结算服务和医疗临床研究项目的数据合规出境规范。第三，数据跨境区域更加聚焦，粤港澳大湾区具有独特的区位优势，是我国跨境数据流通的重要节点。作为一个重要的经济合作区域，涉及“一个国家、两种制度、三个关税区、三种货币”，这里具备强大的经济发展实力和跨境数据流通需求。白皮书（2023）重点关注粤港澳大湾区跨境数据流通发展现状，推进数据跨境流动安全规则研究、制定和落地的先行先试。本次白皮书成功发布，离不开“开放群岛跨境数据流通小组”各位领导专家的支持和帮助。他们在跨境数据合规与流通实践方面，拥有成熟的经验与领先的优势。在编写过程中，各位专家不吝分享自己专业领域的真知灼见，每一次讨论都是思想的碰撞，每一次交流都是思维的提升。再次感谢各参编单位的团结贡献，让我们继续为推动数据跨境安全有序流动贡献力量！1目 录版权声明.1编制说明.2前 言.1目 录.1图列表.1第一章 背景介绍.11.1.我国跨境数据流通的发展现状.11.2.港澳大湾区跨境数据流通的发展现状.41.3.全球跨境数据流通的发展趋势.41.4.我国跨境数据流通发展面临的挑战.5第二章 国际条约中的数据跨境规则.82.1.总览.82.2.具体条约中的数据跨境规则.92.2.1.基于世界贸易组织（WTO）框架下的重要多边条约.92.2.2.区域全面经济伙伴关系协定（RCEP）.122.2.3.全面与进步跨太平洋伙伴关系协定（CPTPP）.142.2.4.数字经济伙伴关系协定（DEPA）.152.3.对中国数据跨境管理的启示.16第三章 数据跨境域外法律环境分析.183.1.中国香港.183.1.1.推动数字经济发展，打造亚太地区数据中心设立首选地.183.1.2.香港数据保护及数据跨境的要点简析.193.1.3.香港与中国大陆个人信息保护法规之对比情况.213.2.中国澳门.223.2.1.完整的个人资料保护规范，但不完善的跨境规则.223.2.2.澳门数据保护及数据跨境的要点解析.223.2.3.注意敏感个人信息保护，避免行政处罚.233.3.中国台湾.243.3.1.台湾地区个人资料保护及跨境流通监管的法律环境.243.3.2.我国台湾地区数据保护及数据跨境的要点简析.253.3.3.我国台湾地区个人资料保护法与大陆个人信息保护法的衔接与差异.2723.4 东盟.273.4.1.出台系列指导性政策文件，统筹数字经济发展与数据保护.283.4.2.东盟个人数据保护框架促各成员国国内数据保护政策一致化.283.4.3.东盟数据管理框架和东盟跨境数据流动示范合同条款为企业提供数据管理和跨境数据流通的指引.293.5.新加坡.293.5.1.寻求加强监管与数据开放流动直接平衡的监管体系.293.5.2.新加坡数据保护监管框架概览及数据跨境的要点解析.303.5.3.新加坡与中国个人信息保护之比较.333.6.越南.333.6.1.越南数据保护法律体系概况.333.6.2.越南数据保护和数据跨境的要点简析.333.6.3.越南与中国数据保护法律之对比.343.7.沙特阿拉伯.353.7.1.沙特阿拉伯数据保护法律框架概述.353.7.2.沙特个人数据保护法要点简析.353.7.3.沙特数据保护与中国的对比.373.8.日本.373.8.1.日本数据跨境流通战略举措.373.8.2.日本数据跨境流通法律规制要点简析.393.8.3.与我国数据跨境法律法规对比分析.413.9.印度.423.9.1.经历多次曲折，终接近出台数据保护专门立法.423.9.2.印度数据保护及数据跨境的要点解析.423.9.3.与中国法律的对比.453.10.俄罗斯.463.10.1.俄罗斯联邦个人信息及数据法律环境分析.463.10.2.俄罗斯联邦数据跨境保护及审查要点分析.473.10.3.中俄数据保护及数据跨境合规对比.493.11.欧盟.493.11.1.棱镜事件推动的数据跨境流动立法密集时代.493.11.2.欧盟数据保护及数据跨境的要点简析.503.11.3.中国对 GDPR 的借鉴与发展.5133.12.美国.533.12.1.美国个人信息及数据法律环境分析.533.12.2.美国数据保护及数据跨境的要点解析.543.12.3.美国与中国数据保护法律之对比.563.13.尊重区域差异，做好数据跨境合规.57第四章 跨境数据流通技术解决与合规方案.584.1.跨境消费：某知名大型港资消费品企业数据跨境方案.584.1.1.案例背景.584.1.2.技术方案.594.1.3.方案创新点和亮点.594.1.4.应用效果.604.2.跨境金融：香港银行跨境电子签署.604.2.1.案例背景.604.2.2.技术方案.604.2.3.方案创新点和亮点.624.2.4.应用效果.624.3.跨境芯片研发：M2&SKC 芯片数据跨境安全计算.624.3.1.案例背景.624.3.2.技术方案.634.3.3.方案创新亮点.644.3.4.应用成效.654.4.跨境数据：中国首单场内跨境数据交易.654.4.1.案例背景.654.4.2.整体方案.654.4.3.数据产品创新点和亮点.684.4.4.应用成效.684.5.数字贸易：基于数字贸易资产的融资解决方案.694.5.1.案例背景.694.5.2.技术方案.694.5.3.方案创新点和亮点.714.5.4.应用成效.724.6.跨境金融：港股开户跨境可靠电子签署.724.6.1.案例背景.724.6.2.技术方案.7244.6.3.方案创新点和亮点.734.6.4.应用效果.734.7.卫生健康：跨境就医结算服务平台.744.7.1.案例背景.744.7.2.技术方案.744.7.3.方案创新点和亮点.774.7.4.应用效果.774.8.跨境征信：海外用户信用风险评估报告.784.8.1.案例背景.784.8.2.技术方案.784.8.3.方案创新点和亮点.804.8.4.应用效果.804.9.健康医疗：临床试验数据跨境合规.814.9.1.案例背景.814.9.2.合规方案.824.9.3.方案创新点和亮点.834.9.4.应用效果.844.10.跨境贸易：基于区块链的两岸跨境贸易商品溯源系统.844.10.1.案例背景.844.10.2.技术方案.854.10.3.方案创新点和亮点.884.10.4.应用效果.884.11.跨境电商：跨境数据推动电商企业 ESG 供应链改进.884.11.1.案例背景.894.11.2.技术方案.904.11.3.方案创新点和亮点.914.11.4.应用效果.914.12.数据合规：企业数据出境风险评估.924.12.1.案例背景.924.12.2.合规评估.924.12.3.方案创新点和亮点.944.12.4.结语建议.94第五章 数据跨境流通与技术应用发展建议.955.1.数据跨境安全管理底线坚持与便利化探索.9555.2.企业全面建成数据跨境合规体系.965.2.1.企业数据安全与隐私保护.965.2.2.企业供应链风险控制与管理.975.2.3.企业跨境数据流通合规能力建设.985.3.推动跨境数据流通合规技术产业发展.995.4.重视合规人才培养与产业共生.1015.5.深化开放合作实现跨境合规应用多样化.102参考文献.104附录 A:数据跨境流通域外法律解析.1071.香港.1072.澳门.1133.台湾.1174.新加坡.1315.越南.1406.日本.1497.印度.1508.欧盟.1609.美国.176附录 B：编写单位简介.1931图列表图 1跨境流程示意图.59图 2跨境电子签署服务平台总体架构图.61图 3跨境电子签署服务平台网络传输路径图.62图 4整体架构图.64图 5UCloud 安全屋业务流程图.64图 6数库 SmarTag 新闻分析数据产品架构图.66图 7跨境数据交易流程图.67图 8传统供应链中 DTA 的应用流程图.70图 9多级供应链中 DTA 在发行、转让、融资和兑现场景中的应用.71图 10深圳 CA 港股开户电子认证服务平台总体架构图.73图 11跨境就医结算服务平台框架结构图.76图 12平台业务流程图.76图 13跨境就医结算服务平台技术架构图.77图 14用户信用风险评估报告处理系统作业流程示意图.79图 15征信报告模板示意图.80图 16数据出境安全评估流程.82图 17自评估流程图.83图 18两岸跨境贸易商品溯源应用技术架构图.86图 19两岸跨境贸易商农品溯源应用数据上链流程.86图 20两岸跨境贸易商品溯源应用数据采集示例.87图 21两岸跨境贸易商品溯源应用案例.87图 22方案功能展示图.89图 23企业跨境数据安全技术体系架构图.961第一章 背景介绍数据是国家重要的战略资源，跨境数据的积累、精炼、加工和管控是数字经济的重要组成部分，对于促进全球经济的可持续发展具有重要的推动作用。数据跨境流通对数字丝绸之路建设具有积极的推动作用，有助于促进全球数字经济的健康发展，实现各国在数字化时代的共同繁荣。在数字化转型背景下，跨境数据流通已愈发成为全球经济增长中的关键引擎。一是跨境数据推动数字经济全球一是跨境数据推动数字经济全球化化。跨境数字业务如跨境金融、跨境医疗、跨境零售等都需要大量的数据在全世界范围内快速传输和处理，实现全球化的服务和运营；如果无法跨境传输数据，这些基于网络的数字业务将难以实现全球发展，实现数字经济的全球布局。二是二是跨境数据保障数字贸易一体化。跨境数据保障数字贸易一体化。随着数字贸易规模不断扩大,跨境数据流通将成为促进数字贸易发展的重要基础，只有实现安全高效的跨境数据流通，数字贸易才能真正实现全球一体化，这将进一步推动全球数字经济的深入发展。三是三是跨境跨境数据流通数据流通支撑产业高质量支撑产业高质量。企业通过跨境数据流通，整合全球各地区的数据资源实现资源最优化配置，这可以帮助企业缩短产品迭代周期，提高研发效率，优化全球运营决策，在全球竞争中获得先发优势，同时产业也可以利用数据优势，实现转型升级和高质量发展。四是四是跨境数据流通跨境数据流通助力企业高效益助力企业高效益。通过收集和分析来自不同国家和地区用户数据，企业可以更好地了解全球客户的需求和偏好，挖掘出新的商业机会，针对不同市场提供定制化的产品和服务，实现精准营销，拓宽全球销售渠道，这将有利于企业快速扩大市场规模。1.1.我国跨境数据流通的发展现状（1）跨境数据流通的快速发展导致新的商业模式不断涌现，产生更加紧密复杂的经济互动，从而促进数字经济外延形式上的持续扩张和内在逻辑上的持续延伸。在数字经济全球化的背景下，我国对于跨境数据流通的管理上也参考了国际先进经验，制定和实施了许多重要的管理措施。总体而言，我国跨境数据流通整体呈现管理框架更加完善、跨境数据流通行业应用更加丰富等特征。（2）数据数据跨境跨境流通流通管理规范体系愈发管理规范体系愈发完善完善为顺应跨境数据流通，融入全球化发展，近年来我国出台并施行了中国人民共和国民法典电子商务法网络安全法数据安全法个人信息保护法中华人民共和国密码法中华人民共和国外商投资法反垄断法出口管制法等法律规范。随着网络安全法数据安全法个人信息保2护法等法律的发布，我国建立了以数据保护与跨境数据流通为框架的制度体系，同时法律框架机制的设计也采取了全球共识和本土经验相融合的创新模式，积极探索跨境数据流通规则体系多样性的建设。2022 年 9 月国家互联网信息办公室发布实施数据出境安全评估办法，进一步规范了数据跨境的事前管理路径；2022 年 12 月中共中央国务院发布关于构建数据基础制度更好发挥数据要素作用的意见（以下简称“数据二十条”），进一步有利于提高数据要素治理效能；2023 年 6 月 1 日施行的个人信息出境标准合同办法及个人信息出境标准合同，是对个人信息保护法中国家层面的跨境数据流通管理制度体系的落实；2023 年 7 月国务院印发关于进一步优化外商投资环境加大吸引外商投资力度的意见，进一步提出和倡议了“为符合条件的外商投资企业高效开展重要数据和个人信息出境安全评估，提供绿色通道”；2023 年 9 月 28 日国家互联网信息办公室发布规范和促进数据跨境流动规定（征求意见稿），进一步对数据跨境流动的禁止性行为、可行性行为进行了明确的界定，并针对允许的跨境数据流通的可行性行为给予了操作指引，并强调了企业数据出境安全责任和监管要求。总体而言，我国跨境数据流通相关管理体系愈发完善。（3）我国我国跨境数据流通跨境数据流通行业应用愈发丰富行业应用愈发丰富在我国，跨境数据流通已经渗透到众多行业中，其中以金融、制造业、医疗、物流、数字贸易和数字服务等行业为国内跨境数据流通的行业代表，跨境数据流通在其中发挥了积极重要的作用。在金融行业在金融行业，对客户全球范围的金融资产进行配置和管理的过程中，包含大量的跨境数据信息需求，如金融跨境结算，反洗钱及全球风控、客户金融资产管理实时跨境同步等业务场景，都涉及到国境间的个人数据传输。例如，在风控业务中，有的外资机构帮助中国客户在全球范围内进行投资，建设全球风控系统需要掌握较敏感的数据。在制造行业在制造行业，全球化产业链发展格局下，制造业涉及大量数据协同过程，以实现优化配置和降本增效，如当前市场火热新能源领域汽车制造业，车企需要将海外数据存储在当地自有数据中心或公有云中，虽然不涉及到出口国当地个人信息跨境传输，但由于海外销售、研发等分支机构需要共用国内业务系统，会有研发、制造、销售、财务、运行等相关数据跨境流动的需求。在物流行业在物流行业，随着全球化贸易的增长和电子商务的兴起，跨境数据流通和整合为物流行业提供了高效便捷的信息管理和运营模式。通过数字化技术和跨境数据流通，全流程物流信息获取需求得以满足，物流公司可以实时获取全球运输、库存、订单等关键信息，实现供应链的可见性和精细化管理，更好地与海外供应商、制造商和客户进行合作和沟通，促进国际贸易的便捷性和可靠性。3在医疗行业，在医疗行业，药物海外研发对于多样性的个人数据跨境需求显得更为迫切，药企需要收集、处理包括临床试验数据、试验样本中包含的人类遗传资源信息、患者的健康检测和管理数据等，这些数据部分属于重要数据和敏感个人信息。如我国药企向美国申请新药上市，需要向美国食品与药品管理局（FDA）提出新药临床试验审批申请（IND）和新药注册申请（NDA），并提交临床前研究、检测结果、药物组成、药物生产与质控程序数据。在数字贸易在数字贸易，全球化产业的发展，对打通供应链、产业链、服务链从而实现三链贸易的整体打通，提出了“供应链可视化和跨境数据流通整合”的需求，其中跨境数据流通是实现供应链可视化的重要步骤。同时，伴随着数字技术的发展，通过数字技术延伸出来的数字人、元宇宙、NFT 等相关数字服务和需求也相继产生，在数字服务和产品进行全球流通的背景下，跨境数据的流动是必然性的刚性需求，形成了一种跨境数据流通的新型生态系统。（4）跨境数据流通跨境数据流通技术解决方案日趋成熟技术解决方案日趋成熟当前跨境数据流通相关技术日趋成熟并广泛应用。依据我国现有法律法规要求及相关标准规范建议，强调企业应当建立数据跨境的技术能力体系，以规范和促进数据依法有序自由流动。主要从以下几个方面：在数据资产梳理在数据资产梳理方面，数据分类分级技术将助力实现核心数据、重要数据、一般数据的高效识别以及与相应数据类别、数据安全等级的智能关联，从而大幅提升识别效率和安全性。在数据分析处理在数据分析处理方面，隐私计算技术将在助力企业实现“数据可用不可见，原始数据不出域”。已经有越来越多的企业将通过跨境部署隐私计算节点来完成重要数据或个人数据的处理分析。在数据流动管理在数据流动管理方面，区块链技术将有效助力实现跨境数据流通全生命周期的“防篡改、可追溯、可信任”，为国家及企业的个人信息保护合规审核和数据跨境流动安全监管审计工作提供有力的技术保障。（5）数据跨境措施持续促进外商投资和服务贸易发展数据跨境措施持续促进外商投资和服务贸易发展2020 年 8 月，商务部在全面深化服务贸易创新发展试点总体方案中提出，要积极开展数据跨境传输安全管理试点，并选择了北京、天津、上海、广州、深圳等 28 个省市作为试点地区。2022 年 1 月，国家发改委、商务部宣布将放宽跨境数据业务等相关领域市场准入，开展数据跨境传输（出境）安全管理试点，加速数据要素跨境市场建设。2023 年 7 月，国务院公布关于进一步优化外商投资环境，加大吸引外商投资力度的意见，其中首次提出建立数据出境的清单制度，回应了众多外商投资企业和国内企业的关注；同时在全国范围内统一适用数据出境安全评估、标准合同、认证认可的“三件套”监管措施中，另单设京津4沪粤四地“试点探索”形成“可自由流动”的“一般数据清单”，此举是国家发展大战略之一京津冀一体化的通盘考虑，覆盖环渤海、长三角、珠三角国内三个重要经济带。1.2.港澳大湾区跨境数据流通的发展现状粤港澳大湾区是我国跨境数据流通的重要节点，作为一个重要的经济合作区域，涉及“一个国家、两种制度、三个关税区、三种货币”，具备强大的经济发展实力和跨境数据流通需求。大湾区以率先探索制定数据跨境流动规则，拥有庞大的数据跨境流动应用场景和基础设施，其在数据流动方面的地位与影响力日益凸显，成为了我国跨境数据流通的重要支撑，是进行跨境数据流通研究的先行试验田。粤港澳大湾区并结合行业需求，产生了一大批的经典应用案例。在金融领在金融领域域，粤澳上线跨境数据验证平台，利用区块链技术，以金融信息为试行范畴，在个人资产信息、企业资产证明和核数证明等业务场景方面实现跨银行、跨机构间的数据验证服务。在医疗领域在医疗领域，粤港实现电子病历跨境互通，香港大学深圳医院通过电子健康纪录互通系统（简称“医健通”）实现电子病历跨境互通。在政务在政务领域领域，粤港澳实现政务“跨境通办”，江门市在香港和澳门设立“跨境通办政务服务专区”，推出“湾区政务通”可视化智慧服务柜台，通过引入线上身份核验、远程视频、数字空间、区块链等新技术促进跨境政务数据可信共享，实现涵盖商事登记、不动产登记、公积金、社保等多项高频服务的跨境办理。在科研领域在科研领域，中国澳门与欧盟实现科研数据共享，澳门与欧盟合作构建“中国澳门欧盟数据跨境流动通道”，以科研数据为突破点，探索出包括规则、技术和管理的治理机制，采用 IPV6、隐私增强、区块链等技术确保数据流动的可追溯和可管控，实现了科研数据安全有序跨境双向传输。在在教育教育领域领域，粤港澳大湾区已成为我国科研创新中心，数十家境外高校陆续在广东办学或成立实验室，其中包括香港中文大学、香港科技大学、香港浸会大学、澳门科技大学等，通过合作办学的推动，进一步推动了校区之间包括人员身份信息、实验室科研数据、管理规则技术体系的跨境数据流通共享。总体而言，粤港澳大湾区在促进数据跨境流动方面先行先试，成效显著，但当前仍面临数据跨境难以同时实现数据安全、隐私保护和自由流动三大目标的“三元悖论”，数字基础设施互联互通仍存在一定障碍。1.3.全球跨境数据流通的发展趋势伴随着产业全球协同化发展和数字经济的全面到来，在全球范围内进行的跨5境数据流通愈发变得频繁，成为全球经济发展过程中的刚性需求。通过对全球跨境数据流通的现状进行深入分析，全球跨境数据流通具有以下发展趋势：一是数一是数据跨境治理政策愈发明确据跨境治理政策愈发明确。一方面，全球数据跨境流动的政策、规则和标准存在越来越多的共同点、互补性和趋同因素，都聚焦数据跨境安全保护和自由流动双重目标。另一方面，数据跨境流动全球的监管力度、约束规则、惩戒措施，虽总体趋向严格和出现相关处罚案例，但相关的跨境数据流通的政策已愈发清晰具体。二是数据主权之争愈演愈烈二是数据主权之争愈演愈烈。数据是基础性、战略性资源，数据主权之争成为国家冲突的新形态，许多国家和国际组织积极推动数据主权战略部署和政策规制；迄今，全球近 60 个国家和地区出台了数据主权相关法律或战略；特别是美欧滥用长臂管辖进一步导致数据主权冲突加剧。三是数据跨境安全面临新技术冲三是数据跨境安全面临新技术冲击击。生成式人工智能等新技术的发展促进数据应用场景和主体日益多样化，同时也给数据安全带来新的威胁，导致隐秘在新技术外衣下的数据泄露、数据贩卖、数据侵权等数据跨境安全事件频发；如用户在使用 ChatGPT 的过程中若使用不当，将对个人隐私、商业秘密、国家安全造成严重威胁。四是数据本地化趋势上四是数据本地化趋势上升升。出于国家主权、数据安全、个人信息保护等多种因素的考虑，越来越多的国家和地区采取数据本地化措施，限制部分相关重要数据跨境流动；同时，这些措施的限制性越来越强，许多措施涉及禁止数据流动的存储要求。1.4.我国跨境数据流通发展面临的挑战我国跨境数据流通发展整体呈现出蓬勃发展之势，但综合分析现状和未来趋势，当前仍存在跨境数据流通实施标准和落地措施不足、境外主体数据安全保障能力评估受限、跨境数据流通安全评估成本高和耗时长、境外直接面向境内收集数据主体的申报难、大模型训练数据来源广泛导致监管难度加大等五个方面的问题和挑战。（1）跨境跨境数据流通数据流通实施标准和落地措施不足实施标准和落地措施不足国家发布的数据出境安全评估办法 工业和信息化领域数据安全管理办法（试行）汽车数据安全管理若干规定（试行）重要数据识别指南（征求意见稿）和规范和促进数据跨境流动规定（征求意见稿）已对数据和重要数据的范围进行了定义，明确了告知原则和解决了范围模糊的问题，并有效降低了数据处理者的合规成本；但在目前构建的数据跨境底座之上，我们仍然缺乏更加清晰的跨境数据相关标准、落地措施，以作为数据跨境流动的发展底层设施；如数据出境安全评估申报指南中对属于数据出境的行为做出了描述，但在具体业务中，企业仍缺乏更加细致统一多方互认的数据跨境标准和共通的落地执行措施。6（2）境外主体数据安全保障能力评估受限境外主体数据安全保障能力评估受限数据出境安全评估办法 个人信息出境标准合同办法等法规对境外接收方的数据安全保障能力、个人向境外接收方主张权利的途径有效性评估进行了规定，但在具体核查评估过程中，仍然存在能够进行有效评估的企业数量有限、评估事项评估标准理解不清晰、人工梳理出境活动协调难还原不准确等问题，大多数企业仍主要是靠“在合同中进行约定的方式”来完成判定境外主体履行责任义务的管理和技术措施、能力等保障出境数据的安全，也只有零星几家企业有能力“派遣公司内部人员进行实地考察判断其管理和安全防护能力”。同时在具体开展技术检测过程中，仅通过书面材料审核还是需要到境外对相应接收方进行审核的不确定性导致很难对另外主体的数据安全保障能力进行一个精确性的评估。（3）跨境数据流通跨境数据流通安全评估成本高和耗时长安全评估成本高和耗时长数据出境安全评估过程中，需对境内外双方数据出境场景规模必要性、境外接收方数据法律环境、数据安全保障能力、数据出境风险等进行评估，内容庞杂且复杂，评估内容涉及多层面、多维度，单一能力团队无法支撑。就所需要评估的内容，企业需要聘请内外部多方团队，如聘请外部律师事务所、咨询机构、技术单位进行评估申报、履行评估、整改和申报义务，总体花费的经济成本较高。同时，由于涉及的层面内容的多样性和多维度，处理评估、整改和申报相关手续及流程的时间周期较长，甚至可能经过多轮修改补充仍无法通过，在境内企业难以评估数据跨境风险和控制措施的有效性的情况下，评估周期有可能进一步拉长。（4）境外直接面向境内收集数据主体的申报难境外直接面向境内收集数据主体的申报难根据个人信息保护法五十三条规定，本法第三条第二款（分析、评估境内自然人的行为）规定的中华人民共和国境外的个人信息处理者，应当在中华人民共和国境内设立专门机构或者指定代表，负责处理个人信息保护相关事务，并将有关机构的名称或者代表的姓名、联系方式等报送履行个人信息保护职责的部门。同时，个人信息保护法明确对于数据跨境业务和场景，应当依照个保法相关规定履行数据出境安全义务，强调对于满足数据出境安全评估条件的境外个人信息处理者，应当申报数据出境安全评估，并满制度要求：仅具有独立法人资格的主体可以进行认证并持有认证证书。如境外主体或其境内不具有独立法人资格的分支机构需要进行认证，需由境外总部进行认证。现阶段而言对于境外数据处理者主体，面向境内收集数据也成为实务中难点。（5）大模型训练数据来源广泛导致监管难度加大大模型训练数据来源广泛导致监管难度加大大模型训练数据中数据类型及数据来源多元复杂，包括他人隐私、个人信息、7智力成果等，使用这些数据训练模型存在侵犯他人个人隐私、个人信息等风险。在使用过程中，境内主体通过 API 接口形式接入境外大模型，还可能会伴随数据跨境传输及数据泄露风险。如众多个人用户跨境调用大模型服务，或导致数据积累违规跨境，业内多家大模型服务科技企业由于跨境调用大模型服务而致使企业陷入合规危机。在企业内部，企业在多场景应用训练时无法使用同一个模型，需采购或研发大模型（必要场景下国内外大模型都采用），这将使得企业面临中国境内一套模型，境外一套模型的境况，无法实现系统的整体统一监控，导致跨境数据传输的风险进一步加大，同样增加了跨境数据流通监管难度。8第二章 国际条约中的数据跨境规则2.1.总览数据的跨境自由流动是当今世界经济发展必备的常态，应当在保障国家安全、经济安全和社会公共利益等少数必要情况下，尽可能促进和鼓励数据跨境流动，以便创造出更大的经济和社会价值。鉴此，产业界、学术界、社会公众对于简化和便利数据跨境流动监管手续的呼声持续高涨，国际组织、区域机构、各国政府也在积极探索和不懈推动。主要经济体基于自身立场、产业要求分别形成了两种不同的管理路径：一是倡导数据自由流动的全球主义；二是以本地化存储、数据跨境审查为主要特征的本地主义。在此情况下，条约作为国家之间、政府间国际组织之间、国家与政府间国际组织之间缔结的国际协议，便发挥了最主要的契约型约束和造法性指引。必须承认，目前数据跨境活动并未形成全球性规制体系。换言之，全球范围内暂不存在数据跨境流动监管中统一适用的“国际规则”，导致无专项性国际条约、无国际统一适用标准、无国际专业仲裁机构、无国际专项争端解决。“条约是确立国际法主体之前权利义务的书面协定，是国际法渊源最主要体现。”目前国际法按照缔约方数量的划分，针对数据跨境这一特定问题构建权利和义务的国际条约：分为双边条约、诸边条约和多边条约。由于体例和篇幅的限制，本节简要分析涉及中国出境业务或对中国国内立法具有重要影响或参与国际规则谈判发挥范例效应的主要国际条约。（1）缺有效强制但顽强推进的多边条约缺有效强制但顽强推进的多边条约目前，多边条约主要中涉及部分数据跨境内容的国际组织成员签署的条约或主要国际治理机发布的宣言，由于成员间的立场和利益分歧、经济发展水平差异、执法水平经验和机构无法对齐，导致普遍缺乏强制力保障，主要有三类：一是经济合作与发展组织（OECD）于 1980 年确立的首部关于全球数据跨境流动执法原则立法-隐私保护和个人数据跨境流动指南、2013 年制定的OECD 隐私框架，中国为观察员身份未加入；二是二十国集团积极倡导于 2019 年签署的数字经济大阪宣言，中国加入；三是世界贸易组织（WTO）于 1995 年生效的服务贸易总协定、于 1997 年生效的信息技术产品协议、于 2019 年生效的关于电子商务的联合声明，中国均已加入。值得关注的是，尽管存在数据主权、隐私安全、管辖权的政策议题争议诸多困难，国际多边组织始终在不懈努力积极推进。特别是不断有学者和产业人士呼9吁成立世界数据组织（WDO）并缔结管辖数据跨境并具备强制约束力的条约，虽目前看此提议遥遥无期，但无容置疑：统一适用的国际多边条约必是最终目标。（2）重区域适用但蓬勃发展的诸边条约重区域适用但蓬勃发展的诸边条约由于达成多边组织的广泛一致和签署具有约束效力的协商共识，近二十年来区域经贸协定和近年来的区域数字协定成为各经济体开展对外合作的主流，涉及数据跨境移动便利化规制的诸边条约主要有三类：一是中国已加入的具有相对广泛代表性的，比如亚太经合组织（APEC）各成员于 2005 年签署的隐私保护框架、2007 年签署的数据隐私探路者协议、2011 年开发的“跨境隐私规则体系”；二是针对中国正积极申请加入且具备较高水平的，包括 2018 年生效的全面与进步跨太平洋伙伴关系协定，特别是其中的数字贸易规则；2020 年新加坡、新西兰和智利（亦是 CPTPP 签署方）线上签署的 数字经济伙伴关系协定，特别是其中应对数字经济对传统商业贸易治理产生的巨大挑战规定；三是国际上一体化程度十分紧密且为各成员广泛关注的，如 2020 年，美国、墨西哥、加拿大之间新的贸易协议 美墨加协议 正式生效，该协议不仅正式承认了 APEC跨境隐私规则体系”的有效性，而且要求确保数据跨境自由传输、最大限度减少数据存储与处理地点的限制以促进全球化的数字生态系统。（3）高标准雄心但数量有限的高标准雄心但数量有限的双边条约双边条约基于美欧密切的经济联系和高科技的深度合作，2022 年 欧美数据隐私框架达成。欧盟委员会不仅扩大数据跨境移动方面的规则解释，更是更新了标准合同条款，明确确保数据进口提供同等保护的责任主体在于将个人数据提供数据跨境的数据出口方。美国也提出了修补隐私盾协议的实质性承诺。2.2.具体条约中的数据跨境规则本节将从具体的条约着手，简析其中的数据跨境规则。由于体例和篇幅的限制，我们挑选部分条约进行分析，供参考。2.2.1.基于世界贸易组织（WTO）框架下的重要多边条约在全球发展数字经济的背景下，世界贸易组织（World Trade Organization，WTO）作为全球范围内的多边贸易组织拥有 164 个经济体成员，主要通过减免数字产品关税、推动跨境数据自由流动促进全球范围内信息技术产品贸易涉及数字服务贸易的统一化、便利化、自由化。在不断涌现新兴技术的有力加持下，多种形式的国际贸易均可能涉及到相应的国际间数据跨境传输，相关成员关于数据跨境传输的法律和政策确实会影响贸10易开展。鉴于 WTO 框架目前主要针对基于贸易关切的数据跨境进行专项规制，在 WTO 体系下讨论数据跨境问题应从相关成员的国（境）内法律政策对贸易本身的影响考虑，从而援引相关贸易协定进行分析，本节侧重中国数据安全和个人信息保护开展例证。后续一节将重点讨论三个重要多边条约：服务贸易总协定（General Agreement on Trade in Services，以下简称 GATS）、信息技术产品协议（Information Technology Agreement，以下简称 ITA）、关于电子商务的联合声明（Joint Statement on Electronic Commerce，以下简称 JSEC）。（1）服务贸易总协定（服务贸易总协定（GATS）GATS 是关贸总协定（GATT）乌拉圭回合谈判达成的第一套规范国际跨境服务贸易的具有法律效力的多边条约，于 1995 年 1 月正式生效，包括美国、欧盟、日本、澳大利亚、中国等 140 多个成员，其宗旨是在透明度和逐步自由化的条件下扩大服务贸易。GATS 规定国际服务贸易具体分为四种方式：跨境交付（cross-border supply）、境外消费（consumption abroad）、商业存在（commercialpresence）、自然人流动（movement of natural persons），其核心是市场准入及具体承诺表（schedules of specific commitments）。GATS 中与数据流动有关的内容，缔约时放在计算机和相关服务（computer and related services）类别，其中包括数据处理服务（data processing services）。如前所述，目前上没有一部专门管辖数据跨境的国际条约，WTO 规则中关于数据跨境传输的规制散件于各协定、备忘录、宣言中。WTO 各项协议中都存在少量例外条款，如果符合例外条款，则有关限制数据跨境流动的国（境）内监管措施将不构成违反 WTO 规则。这些例外规则暂时替代性地构成数据跨境流动的国际法基础，其中最为重要的是，GATS 的例外包括了第 14 条的“隐私例外”和“安全例外”，第 14 条之二的“基本安全例外”，具体为：“隐私例外”系指第14条第1款的“为保护公共道德或维护公共秩序所必须的措施”；第 14 条第 3 款“为遵守法律或法规所必需的措施”及其第 2 项的“保护与个人信息（personal data）处理与传播有关的个人隐私及保护个人记录和账户的机密性”。“安全例外”系指第 14 条第 3 款第 3 项的“安全（safety）”。“基本安全例外”系指第 14 条之二第 1 款第 1 项的“（不得）要求任何成员提供其认为如披露则违背其基本安全利益（essential security interests）的任何信息（any information）”。世界各国在国内立法以及开诸边经贸谈判、区域规则谈判过程中涉及数据跨境流动章节的规则设置时，包括紧接本节讨论的 CPTTP、DEPA、RECP 等诸边条约时，总体上均未超越 GATS 中限制跨境服务贸易的上述例外。11（2）信息技术产品协议信息技术产品协议（ITA）ITA 是世界贸易组织于 1996 年 12 月 9 日至 13 日达成的协议，于 1997 年 4月 1 日生效。它由世界贸易组织成员和申请加入国或单独关税区自愿参加，作为WTO 框架下“次多边贸易协定”的新类型，ITA 的成果在最惠国待遇原则的基础上适用于所有成员，每个成员都可以从 ITA 缔约方的市场准入承诺中受益。ITA 在 2015 年完成了扩围谈判，达成了关于扩大信息技术产品贸易的部长宣言，新增了 201 项产品。扩围谈判的成功使 ITA 适应了技术发展的现实，扩围后的 ITA 涵盖了尖端技术产品，例如自动数据处理设备、计算机、网络设备、医疗磁共振成像机、高端半导体、激光技术等。ITA 扩大了作为数字贸易基础的技术产品贸易，但 ITA 的规制局限于信息技术产品的关税削减机制，不包含任何形式的非关税壁垒的有约束力的承诺。数字贸易壁垒更多涉及边境后的非关税措施，尽管存在一定谈判深入中的举步维艰，ITA 为与信息技术相关的硬件贸易提供了非常自由的体制保障，极大地推动了信息技术在全球的普及和运用，从而促进了跨境数据流通。（3）关于电子商务的联合声明（关于电子商务的联合声明（JSEC）2019 年 1 月 25 日，在瑞士达沃斯举行的 WTO 电子商务非正式部长级会议上，中国、澳大利亚、日本、新加坡、美国、欧盟、俄罗斯、巴西、尼日利亚、缅甸等共计 76 个世贸成员签署 JCEC。从多边拓展层面分析从多边拓展层面分析，JCEC 所积极倡导的 WTO 电子商务谈判已扩大到 90个成员参与，形成覆盖数字相关 7 个领域 16 项议题；从双边区域层面分析从双边区域层面分析，至2023 年上半年，全球已签署超 130 个数字协定，其中多为双边、区域自贸协定（FTA）以及数字经济专门协定。从历史演进层面分析，从历史演进层面分析，JCEC 最早可以追溯至WTO 于 1998 年成立的“电子商务工作计划”，强调将充分认识并考虑世贸组织成员在电子商务领域面临的独特机遇和挑战，鼓励所有成员参加谈判，以便使电子商务为企业、消费者和全球经济带来更大利益。从发展理念层面分析，从发展理念层面分析，WTO成员形成三排意见：一是以美国为代表的发达经济体，主张跨境数据自由流动，对电子传输永久免证关税，并禁止数据本地化；二是以中国为代表的发展中经济体，呼吁建立以货物流动为主的跨境电子商务规则；三是以非洲、加勒比和太平洋岛国等相关成员，反对将数字贸易及跨境电子商务议题纳入多边贸易框架下讨论。但近期出现重大的事件却将改变 ICEC 后续谈判的走向，2023 年 10 月 25日，在瑞士日内瓦举行的 WTO 电子商务联合声明倡议会议期间，美国贸易代表凯瑟琳-戴办公室声明，美国在 WTO 电子商务规则谈判中放弃该国长期以来坚持的部分数字贸易主张，其中包括关于跨境数据自由流动的要求，并且美国正在审12查其在数据和源代码等敏感领域的贸易规则现行举措.事态最终走向值得进一步关注。（4）WTO 涉及涉及数据跨境规则与中国数据跨境规则与中国立法的联系立法的联系我国制定的网络安全法、数据安全法、个人信息保护法等法律，关键信息基础设施管理条例、网络数据安全管理条例（征询意见稿）等行政法规，网络安全审查办法、数据出境安全评估办法等部门规章，对于重要数据跨境流动的限制、对于达到规定数量的个人信息出境从而会触发安全影响的评估，对于关基运营者在境内运营中收集和产生的个人信息和重要数据应在境内存储，这些措施都是援引 GATS 的“基本安全例外”来适度限制，其中对个人信息跨境流动的限制还会增加援引 GATS 的“隐私例外”和“安全例外”。特别指出的是，国家核心数据禁止出境、数据安全审查等事项可以援引“基本安全例外”，这两种限制措施都着眼于保障国家安全和重大公共利益，属于“基本安全”范畴。另一方面，WTO 例外条款的适用旨在协调多边贸易自由化与国内公共政策目标之间的冲突，既保障成员方善意行使例外条款的权利，又保持多边贸易规则的包容性和灵活性。例外条款毕竟是在限缩明确条件和特定少数情况下适用，从既往涉及 GATS 例外条款的争端来看，无论是美国博彩案还是中国出版物及音像产品案，争端解决机构裁决中均采取了严格解释，认为例外条款的要件没有得到充分满足。遵循这一法律逻辑，GATS 例外条款似乎也难以支持成员方限制跨境数据流通，即便是欧盟 GDPR 似乎亦未满足 GATS 例外条款的适用条件。我国在数据出境安全评估的后续地方法规和细化的部门规章出台和具体执法实践中，也应秉持审慎的原则。GATS 创设的隐私例外和安全例外存在共同的适用条件以及适用限制，即“为遵守国内法律法规所必需的措施”（称为“必要性测试”）、“实施措施不得构成任意或不合理的手段或者构成变相限制的前提下”（称为“非歧视性测试”）。目前，暂不确定主要国家和地区限制数据跨境流动的规则能够通过 GATS 第 14条的“必要性测试”和“非歧视性测试”。同时，GATS 第 6.4 条规定服务贸易理事会应制定国内管制纪律，以“保证有关资格要求和程序、技术标准和许可要求的各项措施不致构成不必要的服务贸易壁垒”。这些多边规定和纪律要求在我国深入开展数据安全和隐私保护立法及其落地实践中必须得遵守。2.2.2.区域全面经济伙伴关系协定（RCEP）区域全面经济伙伴关系协定（Regional Comprehensive EconomicPartnership，RCEP）由东盟于 2012 年发起，东盟十国和中国、日本、韩国、澳大利亚、新西兰等 15 个亚太国家共同制定的协定。2020 年 11 月 15 日，前述 1513个国家正式签署了 RCEP。2022 年 1 月 1 日，RCEP 正式生效，目前，该条约已在 15 个签约国中生效，中国是首批生效的国家之一。RCEP 的签署对我国扩大对外开放，形成国内国际双循环新发展格局，促进亚太地区区域协调均衡发展，提升区域经济一体化水平有重要意义。RCEP 由序言、20 个章节和 4 部分市场准入附件共 56 个承诺表组成，是一个现代、全面、高质量、互惠的大型区域自贸协定。其中，关于数据跨境的规定主要集中在第十二章“电子商务”。RCEP 在原则上倡导和鼓励跨境数据的自由流动，但考虑到各国在数字经济和数据治理水平方面的差异，相应的也做出了例外规定，如允许各缔约国基于“实现合法的公共政策目标”及“保护基本安全利益”采取必要措施。RCEP 关于数据跨境的具体规定如下：（1）个人信息保护的要求个人信息保护的要求对于个人信息保护，RCEP 要求各缔约国应制定法律保护电子商务用户的个人信息，且在制定相应法律时应考虑相关国际组织或机构的国际标准、原则、指南和准则，并应向电子商务用户提供“个人如何需求救济、企业如何遵守法律要求”等关于个人信息保护的信息。同时，鼓励法人公布其与个人信息保护相关的政策和程序。（2）推动各缔约国间数据跨境自由流通推动各缔约国间数据跨境自由流通围绕着“促进缔约方之间的电子商务，以及全球范围内电子商务的更广泛使用”的目标，RCEP 在第十二章第十一条规定缔约方不对电子传输征收关税；第十四条第二款规定了不得强制将数据“本地化”作为在该缔约方领土内进行商业行为的条件；第十五条第二款规定“一缔约方不得阻止涵盖的人为进行商业行为而通过电子方式跨境传输信息。”即使在监管较重的金融领域及电信领域，RCEP在其第八章服务贸易的附件一及附件二中也作出了相应规定，原则上应允许相应领域的数据自由跨境流通。（3）以以“合法的公共政策目标合法的公共政策目标”及及“基本安全利益基本安全利益”为例外的流通限制规为例外的流通限制规定定RCEP 以促进数据跨境自由流通为原则，但也为各缔约国作出了例外规定，构建一套“原则 例外”的数据跨境流通规则体系。例外情形主要有两种情形，一是基于合法的公共政策目标采取的必要措施，在 RCEP 序言中即已表明“每一缔约方为实现合法的公共福利目标而进行监管的权利”，在第十二章第十四条第三款第（一）项，第十五条第三款第（一）项做出了相应规定。在金融领域，也对数据本地化做出了例外规定，在不作为规避 RCEP 项下承诺或义务手段的前提下，可以要求金融服务提供者将数据在本地进行存储。二是基于安全采取的必要14措施。该例外主要规定于第二章第十四条第三款第（二）项，第十五条第三款第（三）项。电信领域也有类似规定，在不够成“任意的或不合理歧视或变相限制”的前提下，可以采取措施保证信息的安全性和机密性，并且保护公共电信网络或服务终端用户的个人信息。（4）灵活的争端解决方案灵活的争端解决方案RCEP 第十九章是专门的争端解决条款，但第十二章第十七条对此作出了限制规定。根据该条的规定，缔约国如果对第十二章的解释和适用存在分歧的，首先应善意的进行磋商，尽最大努力达成共同满意的解决方案。如磋商未能解决分歧的，可将分歧提交至 RCEP 联合委员会，第十二章电子商务的争议不适用第十九章关于争端解决的规定，但未来可对该条款进行一般性审议，在审议完成后，就电子商务分歧，可以在同意适用的缔约国间适用争端解决机制。2.2.3.全面与进步跨太平洋伙伴关系协定（CPTPP）全 面与 进 步跨 太 平洋 伙 伴关 系 协定（Comprehensive and ProgressiveAgreement for Trans-Pacific Partnership，CPTPP）跨太平洋伙伴关系协定（Trans-Pacific Partnership Agreement，TPP），在美国退出后，原 11 个 TPP 成员国于 2018 年 3 月在智利首都圣地亚哥共同发表声明，宣布新的协议已经达成并正式更名为 CPTPP。2021 年 9 月 16 日，中国商务部部长王文涛向 CPTPP 保存方新西兰贸易与出口增长部长奥康纳提交了中国正式申请加入 CPTPP 的书面信函。同 RCEP，CPTPP 并非专门的关于数字经济，数据贸易的协定，而是一个全面的区域贸易协定，但其中关于数字经济、数据贸易的规定是协定的重要组成部分。CPTPP 由全面与进步跨太平洋伙伴关系协定、序言、30 个章节及附件全面与进步跨太平洋伙伴关系协定委员会关于 CPTPP 加入程序的决定组成，其中关于数据跨境的规定集中于第十四章电子商务一章。与 RCEP 相同，CPTPP也采取了“原则 例外”的模式对数据跨境进行规定，两者原则上都鼓励跨境数据的自由流动，但在数据流通的自由度上有所差异，具体分析如下：（1）建立促进不同个人信息保护体制间的兼容性的机制建立促进不同个人信息保护体制间的兼容性的机制CPTPP 在个人信息保护方面的规定与 RCEP 相似，但较 RCEP 更进一步的是，考虑到缔约方可能采取不同法律方式保护个人信息，CPTPP 提出每一缔约方应鼓励建立促进这些不同体制之间兼容性的机制。这些机制可包括对监管结果的承认，无论是自主给予还是通过共同安排，或通过更广泛的国际框架。为此，缔约方应努力就其管辖范围内适用的此类机制交流信息，并探索扩大此类安排或其他适当 安排的途径以促进各机制之间的兼容性。15（2）促进各缔约国间的数据自由流通促进各缔约国间的数据自由流通CPTPP 通过不对缔约方间的电子传输征收关税，数字产品的非歧视待遇，允许通过电子方式跨境传输信息，不强制将数据本地化作为作为在其领土内开展业务的条件，不强制开放源代码等进行规定，促进数据在各缔约国间自由流通，。（3）更为自由的数据跨境自由流通规则更为自由的数据跨境自由流通规则相较于 RCEP，CPTPP 关于数据跨境流通的规则更加自由，除了前述提到的RCEP 未做规定的数字产品的非歧视待遇，不强制开放源代码等外，在海关关税上两者也存在差异，RCEP 的关税规定属于“临时性”规定，而 CPTPP 的要求则较为严格,不仅“永久性”免征电子传输关税,还明确要求涵盖电子传输的内容,即数字产品。此外，CPTPP 在例外规定方面有更严格的限制。关于“实现合法公共政策目标”的必要措施，CPTPP 在不构成任意或不合理歧视或对贸易构成变相限制之外规定了不对信息传输施加超出实现目标所需限度的限制。CPTPP 并未将“保护基本安全利益”作为例外情况进行规定。2.2.4.数字经济伙伴关系协定（DEPA）数 字 经 济 伙 伴 关 系 协 定 （DIGITAL ECONOMY PARTNERSHIPAGREEMENT，DEPA）由新西兰、智利和新加坡三国于 2020 年 6 月 12 日在线上签署，于同年 12 月 28 日生效。与 RCEP、CPTPP 不同，DEPA 是全球第一个关于数字经济的专项协定，因此，尽管该协定由三个经济体量较小的国家提出，但在一定程度上为全球数字经济制度提供了模板。中国目前正积极推动加入DEPA，已正式于 2021 年 11 月 1 日向 DEPA 保存方新西兰提交了加入申请。2022 年 8 月 18 日,根据 DEPA 联合委员会的决定,中国加入 DEPA 工作组正式成立,将全面推进中国加入 DEPA 的谈判进程。2022 年 12 月 5 日、4 月25 日，中国已就加入 DEPA 进行了两次首席谈判代表会议，并于 2023 年 3 月28 日举行第一次技术磋商。DEPA 深度借鉴了 CPTPP 中的数字贸易条款并对其进行细化归类,将文本分为了十六章，涵盖了商业和贸易便利化、数字产品待遇、数据问题、数字身份、新兴趋势和技术、创新和数字经济、数字包容性等内容。可以说，DEPA 非常全面的就数字贸易问题做出了详细规定，但限于篇幅和体例，我们主要就数据跨境的规则进行简析。（1）个人信息保护个人信息保护DEPA 第 4.2 条用了十个条款对个人信息进行了规定，除与 RCEP、CPTPP相同的地方外，主要在以下几点做出了不同的规定：16首先是对个人信息保护法律框架应包含的原则做出了规定。主要包含了八大原则，分别是收集限制、数据质量、用途说明、使用限制、安全保障、透明度、个人参与及责任。其次是不对电子商务用户违反个人信息保护规定的行为采取歧视性做法。再次，在促进不同个人信息保护体制的兼容和交互方面，相较 CPTPP，规定了在可行时，对各自法律框架下的可信任标志或认证框架所提供的相当水平的保护给予适当承认，或建立缔约方之间个人信息转移的其他途径。最后，应鼓励企业采用数据保护可信任标志，以帮助验证其符合个人数据保护标准和最佳做法，并推动各缔约国间对他国数据可信任标志的承认。（2）与与 CPTPP 相似的例外限制相似的例外限制在通过电子方式跨境传输信息、数据本地化要求方面，DEPA 第 4.3 条和第4.4 条的规定与 CPTPP 相似，对于相关规定的限制均要求不得构成任意或不合理歧视或对贸易构成变相限制且不对信息传输施加超出实现目标所需限度的限制。（3）推动数据开放，实现数据驱动开放推动数据开放，实现数据驱动开放DEPA 关于数据开放主要分为两部分。一是企业数据的开放，通过数据监管沙盒机制，可信数据共享框架和开放许可协议等推动跨境数据流通和数据共享，从而实现数据驱动的创新。其次是政府公共数据的开放，DEPA 鼓励各缔约方间就政府公共数据开放开展合作，从而扩大获取和使用公共数据的方式。合作方式包括共同确定可利用开放数据集、鼓励开发以开放数据集为基础的新产品和服务及推动使用和开发通过可在线获得的以标准化公共许可证为形式的开放数据许可模式。2.3.对中国数据跨境管理的启示推动数据的跨境有序自由流动绝非一国之力可以完成，各国间数字经济发展水平不一，利益诉求不一，法律体系不一，很难通过一国立法或标准来实现数据跨境标准和规则的统一。因此，才需诉诸于双边、诸边或多边协议来实现各国、各地区间的利益协商和标准统一，从而促进数据跨境的有序自由流动。无论是我国已经加入的 WTO，RCEP，还是正在推动加入的 CPTPP、DEPA，均是我国在这方面的尝试和探索。这条路并非一条容易的道路，相关条约的规定与我国现行法律之间存在一定的差异，对于加入相关协定，势必会对我国现有法律体系造成冲击，如何平衡好国家数据主权与数据跨境流动在未来一段时间需要重点探索。但无论如何，积极对接国际标准，促进数据跨境有序自由流动已是正在推进也应积极推进的事业。在全球范围内暂不存在数据跨境流动监管中统一适用的“国际17规则”的当下，探索并推广中国模式，发出中国声音的绝佳机会。18第三章 数据跨境域外法律环境分析本章将以“一带一路”为线索，按地理顺序对具体国家或地区的数据跨境规则进行介绍。国际条约的落地依赖于各缔约方立法的转化，相关条约也允许缔约方对条约进行例外规定，了解不同国家或地区间的数据跨境规则，对于实际开展数据跨境活动十分必要。更为重要的是，跨境数据流通双方对跨境数据具有相对一致的保护水平是当前数据跨境流动风险管控的共识。对于中国境内的数据处理者，对境外接收方所在地法律对数据跨境的影响进行评估是履行数据出境安全评估办法等规章的规定的义务。3.1.中国香港3.1.1.推动数字经济发展，打造亚太地区数据中心设立首选地香港是国际金融、贸易及物流的重要枢纽，众多跨国企业及国际机构将地区办事处或地区总部设立于此。随着数字经济发展以及网络数据体量与日俱增，有关企业及机构对高效能和安全可靠的数据中心设施和服务的需求越来越殷切。为此，香港特别行政区政府近年来积极推广香港的电讯基础设施、有利营商环境、资讯自由、人才体系、土地供应优惠政策等优势，并推出了包括设立数据中心促进组及专题网站、将工业大厦改装作数据中心用途、预留数据中心等多项促进措施，致力促进香港成为在亚太地区内设立数据中心的首选地点。为进一步促进香港的数字化经济发展，香港特别行政区政府于 2022 年 6 月成立了数字化经济发展委员会，负责制定有关鼓励不同行业采用数字化的策略和措施及推进数据服务的产业和数字化政府的发展等。该委员会特别成立了跨境数据协作小组、数码基建工作小组、数码转型工作小组及人才发展工作小组，以分析确定数据流通、数字化基建、数字化转型及人才培养方面的具体促进措施。此外，香港也抓住了国家推动建设“一带一路”数字丝绸之路和粤港澳大湾区数据中心的机遇谋求自身发展，2023 年，香港特区政府在促进大湾区数据跨境流动方面更是向前迈进了重要一步，其专门负责香港创新科技政策的创新科技及工业局携手与中国国家互联网信息办公室于 2023 年 6 月 29 日签署了 促进粤港澳大湾区数据跨境流动的合作备忘录，以期会同中国国家互联网信息办公室采取有效管理措施，推动建立粤港澳大湾区数据跨境流动安全规则，共同促进粤港澳大湾区数据跨境安全有序流动。193.1.2.香港数据保护及数据跨境的要点简析（1）亚洲最早全面保障个人资料的法域之一亚洲最早全面保障个人资料的法域之一香港在数据安全和个人信息保护方面的立法框架主要包括 香港人权法案条例香港特别行政区基本法个人资料（私隐）条例，其中涉及个人资料保护的相关规定内容概述如下：香港人权法案条例香港人权法案条例1991 年，香港法例第 383 章香港人权法案条例出台（2017 年修订）。该条例第二部第十四条“比照公民权利和政治权利国际公约第十七条”对私生活、家庭、住宅、通信、名誉及信用给予保护，规定“（一）任何人之私生活、家庭、住宅或通信，不得无理或非法侵扰，其名誉及信用，亦不得非法破坏。（二）对于此种侵扰或破坏，人人有受法律保护之权利。”香港特别行政区基本法香港特别行政区基本法1997 年，香港特别行政区基本法正式实施（后其附件经数次修订）。香港特别行政区基本法第三十九条确认了公民权利和政治权利国际公约中“适用于香港的有关规定继续有效，通过香港特别行政区的法律予以实施”。香港特别行政区基本法第三十条规定：“香港居民的通讯自由和通讯秘密受法律的保护。除因公共安全和追查刑事犯罪的需要，由有关机关依照法律程序对通讯进行检查外，任何部门或个人不得以任何理由侵犯居民的通讯自由和通讯秘密。”个人资料（私隐）条例（个人资料（私隐）条例（以下简称以下简称“私隐条例私隐条例”）1995 年，香港法律第 486 章私隐条例制定（1997 年至 2022 年期间经多次修订，现行有效版本日期是 2022 年 10 月 1 日），是亚洲最早出台的全面保障个人资料（私隐）的法例之一。私隐条例共 12 部分及 6 个附表，涵盖个人资料私隐专员职位的设立、资料使用者申报登记、个人资料的查阅和登记、转移、使用、调查等等。私隐条例适用于包括政府在内的公营机构和私营机构。（2）个人资料私隐专员个人资料私隐专员根据私隐条例第 5 条之规定，为监察私隐条例的施行，设立“个人资料私隐专员”（以下简称“私隐专员”）职位。该职位由香港特别行政区行政长官委任一人，任期为 5 年，至多连任一次。20个人资料私隐专员公署（以下简称“公署”）在私隐专员领导下执行法定职能。根据私隐条例第 8 条之规定，私隐专员的职责及权力包括就遵守私隐条例条文做出监察及监管等。（3）推行港股实名制：投资者识别码制度推行港股实名制：投资者识别码制度2022 年 12 月 12 日，香港证券及期货事务监察委员会（以下简称“香港证监会”）公布，香港证券市场的投资者识别码制度将于 2023 年 3 月 20 日推出。此后香港证监会发布了一系列公告为该制度的落地做准备，并于 2023 年 3 月 31日的通告中公布，该制度已于 2023 年 3 月 20 日成功推出。在该制度实施后，相关受规管的中介人须在取得其客户的明示同意后向香港联合交易所有限公司（以下简称“香港联交所”）提交有关识别信息（即客户的名称及身份证明文件资料），以符合香港证监会及相关的私隐法例规定的要求。如投资者不提供所需同意，则只能出售、转出或提取已持有的证券，而不得在香港联交所买入证券。因此如果境内用户需要在香港进行证券交易，需要提供相关的身份证明文件，涉及数据的跨境流动。（4）构建以跨境资料转移指引与建议合约条文范本为参考的跨境流通构建以跨境资料转移指引与建议合约条文范本为参考的跨境流通规则规则在香港，跨境个人数据保护的监管职责主要由公署承担，该公署与境外相关机构协同处理跨境个人数据的保障事宜。私隐条例的第 33 条对个人资料转移至香港以外的地方作出严谨和全面的规管，除在条例指明的情况下，明确禁止把个人资料转移到香港以外的地方，以确保该条例对个人资料被转移后所提供的保障不会被削弱。虽然该第 33 条至今尚未施行，但为了更好指引资料使用者保障个人资料跨境转移并为企业提供最佳行事方式的建议，公署于 2014 年 12 月29 日发布了保障个人资料：跨境资料转移指引（以下简称“2014 指引”），并特别拟备了一份建议范本条文，协助资料使用者制定与境外资料接收者订立的跨境资料转移协议。2014 指引明确指出，私隐条例第 33 条的适用范围：“是（i）将个人资料由香港转移至境外，及（ii）在两个其他司法区之间转移个人资料，但有关转移是由香港的资料使用者所控制；但如果一个位于香港的个人或实体经互联网向同样位于香港的接收者传输资料，但互联网路由经过香港以外的地方（在传输中资料没有被查阅或储存），则不属于第 33 条调整的范畴”。2022 年 5 月，公署发布了更新的跨境资料转移指引：建议合约条文范本（以下简称“指引”）与建议合约条文范本（以下简称“范本”）（详见附件 1.1），该等指引和范本均非强制性规范，属于自愿遵守性质。213.1.3.香港与中国大陆个人信息保护法规之对比情况（1）两地保护思路较为一致两地保护思路较为一致香港地区私隐条例的核心是 6 项信息保障原则，其中限制收集、限制利用和政策公开等原则都是为机构收集和使用个人信息的过程提供价值导向，与大陆地区个人信息保护法（以下简称“个保法”）在保护思路上有较高的一致性。（2）保护强度存在一定差异保护强度存在一定差异在个人信息保护范围、保护义务、法律责任等方面，香港地区私隐条例与大陆个保法的保护强度存在一定差异。具体而言，对于个人信息的保护范围，香港对“个人资料”的定义强调“确定性”，即强调能够确定具体个人身份的资料才属于“个人资料”，而大陆个保法则遵循了“可识别性”的定义思路，对“个人信息”的定义包含了“已识别”和“可识别”两个层面，既涵盖了具体个人身份信息，也涵盖了与个人关联的信息。此外，个保法还对敏感个人信息作出了专门的定义和明确的处理规定。相较而言，大陆对个人信息的保护范围更广。对于个人信息的保护义务，香港并无本地化存储、个人信息保护影响评估、指定个人信息保护负责人、自动化决策等相关要求，而大陆对该等方面明确地作出了规制。行政罚款权限和惩处力度方面，香港的个人信息监管机构没有罚款的权力，香港私隐条例规定的最高罚款额度仅 100 万港元，实务中，罚款额度普遍在 5 万港元以下，而根据大陆个保法规定，履行个人保护职责的有关机构最高可处违法者以五千万元以下或者上一年度营业额百分之五的罚款，对企业具有明显的震慑力。（3）个人信息跨境转移的管理规则不同个人信息跨境转移的管理规则不同根据中国大陆地区个人信息跨境的规则，企业完成个人信息保护影响评估、履行用户告知义务、取得个人单独同意（或其他合法依据）后，再履行相应的安全评估申报、个人信息保护认证或与境外接收方签订标准合同等手续，可跨境传输个人信息。香港私隐条例第 33 条关于个人资料跨境转移的规定尚未正式实施，目前仅有指引作为参考。由于存在上述差异，加上两地对个人信息的保护强度不同，在大陆与香港数据跨境流通合作中，存在着制度衔接的问题。不过，从大陆与香港地区的个人信息保护思路、保护强度来看，一般情况下，中国大陆主体向香港地区传输数据时，香港地区数据接收方的合规程度通常能够满足要求。结合粤港澳大湾区建设及数据互联互通机制深化的总体背景，香港与内地两地的数据跨境主要有赖于数据跨境流动双方的安全保障能力能力和个人信息权益保障的响应。223.2.中国澳门3.2.1.完整的个人资料保护规范，但不完善的跨境规则与中国大陆地区所采用的名称略有不同，“个人信息”在澳门特别行政区被称为“个人资料”（葡萄牙语 Dados Pessoais,英语 Personal Data）。澳门于 2005年制定澳门特别行政区第 8/2005 号法律个人资料保护法（以下简称“个资法”）,于 2019 年制定澳门特别行政区第 13/2019 号法律网络安全法。截至 2023 年 9 月，澳门并未制定数据安全领域的相关法律。根据澳门特别行政区第 83/2007 号行政长官批示，澳门于 2007 年设立专门的执法机构个人资料保护办公室（Gabinete para a Protecco de DadosPessoais），该机构在行政长官的监督下独立运作。个人资料保护办公室是澳门民法典第 79 条第 3 款及个资法所指之公共当局，行使法律赋予的职权，包括但不限于：负责监察、协调个资法的遵守和执行，制定并监察保密制度的实施。澳门对公民个人资料的保护源自于澳门民法典第 79 条,澳门个资法的制定早中国大陆个人信息保护法（以下检车“个保法”）16 年。由于历史的渊源，澳门较早地制定了完整的个人资料保护法律规范，但从实践层面上来看，澳门对公民个人资料跨境的规定并不完善，没有形成类似于欧盟白名单这样的具体标准，而主要是依据个人资料保护办公室的意见判断决定。根据个人资料保护办公室的公开信息，自 2019 年起，截至 2023 年 9 月尚未有个人资料保护相关的意见书发布。3.2.2.澳门数据保护及数据跨境的要点解析（1）个人资料保护法关于个人信息保护的要点个人资料保护法关于个人信息保护的要点澳门个资法的适用范围包括以下三种情形：1）一切自动化处理的个人资料和非自动化处理的个人资料；2）对可识别身份的人的声音和影像进行的镜像监视，以及以其他方式对其进行的取得、处理和传播（只要负责处理资料的实体的住所在澳门，或通过在澳门设立的提供资讯或电信资讯网络服务的供应商而实施）；3）以公共安全为目的处理个人资料。个资法不适用于自然人在从事专属个人或家庭活动时对个人资料的处理。负责实体在处理个人资料时，应注意区分个人资料与敏感资料。以透明的方式进行处理，遵守合法、善意、目的限定、适度、准确、限期保存等原则，保障资料当事人的资讯权、查阅权、反对权等相关权利。处理个人资料的正当性条件包括：1）当事人明确同意；2）执行合同或应当事人要求准备订立合同；3）履23行法定义务；4）保障无能力作出同意的当事人的重大利益；5）执行公共利益任务或行使公权力；6）负责实体或被告知资料的第三人具有优先的正当利益。（2）接收方需达到同等保护水平接收方需达到同等保护水平澳门对个人信息跨境的一般要求，主要规定于澳门个资法第 19 条、第20 条及第 23 条。一是适当保护程度。原则上，只有在遵守澳门个资法的规定且接收转移资料当地的法律体系能确保适当保护程度的情况下，才可将个人资料转移到特区以外的地方。根据法律规定，资料接收地是否有适当保护程度由公共当局（即个人资料保护办公室）判断及决定。通常采用的方法，是根据互惠的原则把已经达到适当保护水平的国家/地区名单列入“白名单”。但直至目前，个人资料保护办公室未将任何国家或地区列入“白名单”。二是发送通知。除上述原则外，存在以下例外情形。在通知个人资料保护办公室后，实体仍可转移个人资料：1）资料当事人明确同意转移；转移是执行资料当事人和负责实体间的合同所必需，或是应资料当事人要求执行制定合同的预先措施所必需；2）转移是执行或制定合同所必需，而该合同是为了资料当事人的利益由负责实体和第三人之间所订立或将要订立；3）转移是保护重要的公共利益，或是在司法诉讼中宣告、行使或维护权利所必需或法律所要求；4）转移是保护资料当事人的重大利益所必需；5）转移自作出公开登记后进行。根据法律或行政法规，该登记是为公众信息和可供一般公众或证明有正当利益的人公开查询之用，但需根据具体情况遵守上述法律或行政法规规定的查询条件。三是申请许可。当转移不满足上述适当保护程度原则要求且不符合上述发送通知的例外情形规定时，实体在确保有足够保障他人私人生活、基本权利和自由的机制，尤其透过适当的合同条款确保该等权利行使的情况下，可向个人资料保护办公室申请许可，并在获得许可后转移个人资料。四是无需许可。当个人资料的转移成为维护公共安全、预防犯罪、刑事侦查和制止刑事违法行为以及保障公共卫生所必需的措施时，个人资料的转移如由专门法律或适用于特区的国际法文书及区际协定所规范，则无需向个人资料保护办公室申请许可。3.2.3.注意敏感个人信息保护，避免行政处罚中国大陆个保法与澳门个资法所规范的处理个人资料的原则大致相同，但个保法对某些定义作出了更明确的规定，对违法主体的处罚更严、罚款更高、处罚手段更多。中国大陆个保法与澳门个资法,主要在以下方面有较大差异（具体法条比详见附件 2.1）:24（1）在处理敏感资料方面，两部法律有较明显的区别。在个保法中，敏感资料被称为“敏感个人信息”即一旦泄露或非法使用，容易导致自然人的人格尊严受到侵害或人身、财产安全受 到危害的个人信息，包括生物识别、宗教信仰、特定身份、医疗健康、金融账户、行踪轨迹等信息，以及未满十四周岁未成年人的个人信息。而个资法则明确规定世界观或政治信仰、政治社团或工会关系、宗教信仰、私人生活、种族和民族本源、以及与健康及性生活有关的个人资料（包括遗传资料）等六种资料为敏感资料。由此可见，个保法所规范的敏感个人信息较个资法更广，且作出了更严格的保护。值得注意的是，个保法将未成年人个人信息归入敏感个人信息，加强了对未成年人个人信息保护的力度。（2）在违法处罚方面，两部法律皆按违法情节的严重程度予以规定，但个保法的行政处罚更具威慑力，最高罚款额以违法主体的营收总额为基准，处罚力度远高于个资法的规定。且相较于个资法,个保法的处罚手段更全面，例如，没收违法所得、责令暂停相关业务、停业整顿吊销业务许可或营业执照等。当澳门个人信息出境到中国大陆时，在遵守个资法规定的同时，应注意遵守个保法对于 公民个人信息保护之规定，避免被处以高额罚款。应特别注意，对于未成年人个人信息的保护力度，应符合中国大陆的相关法律规定。3.3.中国台湾3.3.1.台湾地区个人资料保护及跨境流通监管的法律环境（1）逐步完善的逐步完善的个人个人资料保护立法资料保护立法20 世纪 90 年代起，受欧美国家的影响，我国台湾地区开始重视个人资料保护问题。为满足当地民众对于个人资料保护的主观诉求并促进对外贸易，台湾地区政府成立了专门小组研究个人资料保护相关法律问题，并于 1990 年开启了个人资料保护立法。1991 年 9 月，台湾地区法务部成立了专门小组负责起草相关法律法规，并于 1995 年 8 月公布施行了电脑处理个人资料保护法（以下简称“电资法”），于 1996 年 6 月公布了电脑处理个人资料保护法施行细则。由于面临诸多质疑，法务部于 2012 年颁布了修正后的个人资料保护法（以下简称“个资法”）及个人资料保护法施行细则（以下简称“个资法施行细则”），其于 2012 年 10 月 1 日正式实施。自此，个资法及个资法施行细则经历多次修正，至今为我国台湾地区个人资料保护的基本规范。（2）加入加入 CBPRs，促进数据跨境流通促进数据跨境流通为了促进数据跨境流通，我国台湾地区于 2018 年 12 月加入了亚太经济合作25组织（Asia-Pacific Economic Cooperation,以下简称“APEC”）框架下的跨境信息传输区域安排“跨境隐私规则体制”（Cross-Border Privacy Rules System,以下简称“CBPRs”）。CBPRs 的基本逻辑是，如果位于不同经济体的不同公司，统一承诺并遵循“APEC 隐私框架”提出的九大个人数据保护原则，则个人数据在这些公司之间的传输就不应受到阻碍，获批准加CBPRs 的成员国家或地区的政府会指定一个或多个法担任“问责代理机构”（Accountability Agents），经 CBPRs 认可的问责机构通过认证成员国家或地区内其他企业或组织使这些“认证企业”最终成为CBPRs 的真正参与者。此后，我国台湾地区资讯工业策进会于 2021 年 6 月 3 日经审查认证成为问责代理机构。截至目前，美国、日本、墨西哥、加拿大、新加坡、韩国、澳大利亚、我国台湾地区及菲律宾已加CBPRs。（3）以临床试验及海关检验为代表的数据互通探索以临床试验及海关检验为代表的数据互通探索海峡两岸在数据互通问题上进行了很多探索。例如在临床试验方面，海峡两岸关系协会与台湾海峡交流基金会签署的海峡两岸医药卫生合作协议于 2011年 6 月 26 日正式生效后，两岸展开了一系列合作。2014 年台湾“食品药物管理署”委托台北荣民总医院启动了建立两岸临床试验中心合作计划。在此框架协议下，两岸 8 家临床试验中心签署了合作意向书，承认对方所做的符合 ICH 的临床试验数据。2016 年 4 月 25 日国家食品药品监督管理总局发文两岸开展药物临床试验机构的共同认定，其中明确了大陆药品注册申请人可以委托 4 家台湾医院（台北荣民总医院、三军总医院、台湾大学医学院附设医院、林口长庚纪念医院），按照两岸有关监管要求，开展药物临床试验，符合要求的临床试验数据可用于在大陆申报药品注册。在海关检验方面，福建检验检疫局于 2015 年组织两岸检验建议数据交换测试工作，通过两岸检验检疫数据交换中心实现了与台湾关贸网的双向数据互通，双方均成功接收到了来自对方的电子通讯报文，这标志着两岸检验检疫数据的“电子跨海大桥”已经成功“对接合拢”。近期，中国工业合作协会、北京海峡两岸民间交流促进会和台湾工业合作协会于2023年9月共同举办海峡两岸数字经济交流研讨会，来自海峡两岸相关协会、科研院校、金融、制造业、互联网、文旅、数字技术等领域的 60 多位专家、学者和企业家在会上针对“海峡两岸数字经济协同发展的机遇与挑战”共同探讨了两岸数字经济发展方面的交流与合作。3.3.2.我国台湾地区数据保护及数据跨境的要点简析（1）个资法个资法的适用主体及适用范围的适用主体及适用范围在台湾发生的所有个人资料的收集、处理和使用活动（不论信息当事人是否是台湾籍、实施该活动的主体是否为台湾境内主体）均必须遵守个资法。另26外，该法区分了公务机关和非公务机关，并对它们在收集、处理和使用个人资料方面设置了不同的规定，其中非公务机关包括不属于台湾地区公务机关的任何个人或实体。根据个资法，个人资料指自然人的姓名、出生日期、身份证号码、护照号码、特征、指纹、婚姻状况、家庭信息、教育背景、职业、医疗记录、医疗保健资料、遗传资料、性生活资料、体检记录、犯罪记录、联系方式、经济状况、有关个人社会活动的资料及其他可以直接或间接用于确定自然人的资料。其中，收集、处理或使用有关自然人的医疗记录、医疗保健资料、遗传资料、性生活资料、体检记录、犯罪记录须符合更高的标准。（2）对数据跨境传输采取对数据跨境传输采取“原则允许，例外禁止原则允许，例外禁止”的立法思路的立法思路我国台湾地区在立法上对于数据传输采取“原则允许，例外禁止”的态度。在个资法 中，仅对非公务机关设置了跨境传输个人资料的限制：根据 个资法第 21 条规定，有以下情形之一的，监管机关可以对其进行限制：（1）“涉及国家重大利益”；（2）“国际条约或协定有特别规定”；（3）“接受国对个人资料的保护没有完善之法规，致有损当事人权益之虞”；（4）“以迂回方式向第三国（地区）传输个人资料以规避个资法的情形”。因此，依据个资法规定，在监管机关未限制国际传输个人资料前，非公务机关基于合法收集、处理及利用要件，即可将个人资料进行跨境传输。此外，我国台湾地区的行业主管部门可以发布适用于相关行业的个人资料跨境传输的规则和规定，对行业内的主体进行跨境资料传输方面的限制。台湾地区行政院于 2021 年 8 月进一步制定了实行个人资料保护的合作规范指引，规定各部委应修订针对受其监督的特定行业部门的现行个人资料保护法规，要求各部委应定期认真研究是否有必要制定针对受其监督的特定行业部门的新的数据保护法规，且应考虑相关行业非公务机关的规模、所保留的个人资料的数量或性质、数据泄露对数据主体的潜在影响及跨境数据传输的频率等因素。（3）数据跨境传输的监管部门数据跨境传输的监管部门在 2018 年 7 月以前，我国台湾地区法务部负责解释个资料保护法，在我国台湾地区发展委员会下属机构个人资料保护专案办公室于2018年7月4日成立以后，个人资料保护法的解释权于 2018 年 7 月 25 日正式移交给发展委员会。2023 年 5 月，台湾地区立法院通过了个资法的修正草案，补充了个资法第 1 条之 1 规定，规定由个人资料保护委员会担任个资法主管机构。未来个人资料保护委员会将作为专责机关，整体规划对于公务机关及非公务机关个人资料保护的监管机制，解决目前个资法分散式管理下的实务监管问题。273.3.3.我国台湾地区个人资料保护法与大陆个人信息保护法的衔接与差异个资法施行早于大陆个保法，两者均吸收了 GDPR 相关思路和经验，因此在保护模式上大致相同。但整体而言个资法的侧重点在敏感个人信息及弱势群体的保护，比如对敏感个人信息具体规定了特殊保护，并鼓励公益诉讼、规定团队诉讼减免诉讼费等。该法对于个人信息跨境传输原则上允许，没有设置过多的限制，对信息本地化也没有明确要求，而是通过台湾当局在 个资法的基础上通过颁布行政指令的方式规定信息本地化储存的规则，以及对特定传输进行限制。个保法虽然也规定了敏感个人信息的保护以及公益诉讼，但较为笼统，将更多的重点放在了跨境信息流动规制上，注重国家层面的信息和数据安全。此外，我国台湾地区的个资法不仅规定了民事责任，还区分主体规定了详细的行政责任和刑事责任。如第四十一条规定了违反本法收集处理个人信息导致损害他人利益的将会被判处有期徒刑或罚金的刑事责任，第五十条规定了有关主体在非公务机关受到罚款的行政处罚时，若不能证明自己尽到防止义务，也要承担与非公务机关一样数额的罚款，第二十八条规定了公务机关违反本法导致个人信息泄露或者是有其他侵害信息主体权利行为且无免责事由的，要承担损害赔偿责任。个资法甚至对特殊情况的量刑也做出了统一规定，比如第四十四条规定“公务员假借职务上之权力、机会或方法，犯本章之罪者，加重其刑至二分之一”。我国大陆境内的制度框架则结合个保法 民法典行政法和刑法等多部门法进行规制，没在个保法中进行详细的统一规定。3.4 东盟东南亚国家联盟（Association of Southeast Asian Nations，简称“东盟”）成立于 1967 年，截至 2023 年 10 月，成员国包括印度尼西亚、泰国、新加坡、菲律宾、文莱、马来西亚、越南、老挝、柬埔寨和缅甸 10 国。东帝汶是东盟候选成员国，巴布亚新几内亚是东盟观察员国。东盟稳步推进东盟共同体建设，目前已发展成为东南亚地区以经济合作为基础的政治安全、经济和社会文化一体化的合作组织，并建立起一系列的合作机制。东盟与中国、日本、韩国、印度、澳大利亚、新西兰、美国、俄罗斯、加拿大、欧盟、英国等 11 个国家和国际组织建立了对话伙伴关系。在经贸合作方面，东盟已经与中国、中国香港、日本、韩国、印度、澳大利亚及新西兰分别达成自由贸易协定或经济伙伴协定。2022 年 1 月 1 日，由东盟主导发起的区域全面经济伙伴关系协定（RCEP）正式生效实施。2023 年 6 月 2 日，RCEP 对东盟十国28和中国、日本、韩国、澳大利亚、新西兰 15 个成员全面生效，全球最大经济规模的自由贸易区进入全面实施新阶段。东盟目前是亚洲第三大经济体，世界第五大经济体，也是中国第一大贸易合作伙伴。因此，促进数据跨境流动对中国和东盟的双边贸易有及其重要的意义。3.4.1.出台系列指导性政策文件，统筹数字经济发展与数据保护东盟作为一个重要的区域性组织，基于对外经贸的需要，一方面在数据治理和数据跨境流动领域亟需建立协调统一的合规路径和机制；而另一方面，因东盟各成员国国内法针对数据保护机制的成熟度和数据治理水平差异较大，除了新加坡、泰国、马来西亚、菲律宾、印尼、越南出台数据保护的相关法律法规外，柬埔寨、老挝、缅甸和文莱等其他国家尚未出台数据保护的相关法律。因此，东盟陆续出台了一系列具有灵活性、包容性和指导性的政策文件，以帮助东盟各成员国内的企业和组织根据自身的业务情况，自愿参考适用。为此，东盟于 2016 年出台东盟个人数据保护框架，提出保护数据、支持数字贸易和创新。2018 年制定东盟数字信息治理框架，促进东盟跨境数据流通认证，推动东盟地区的数字信息互联互通。2019 年 11 月，东盟颁布东盟跨境数据流动机制的关键方法，明确将重点建立东盟示范合同条款和东盟跨境数据流动认证两个机制。2021 年出台东盟数据管理框架和东盟跨境数据流动示范合同条款，促进各成员国国内数据保护政策一致化，推进数据管理指标考核、建立跨境数据传输评估标准。3.4.2.东盟个人数据保护框架促各成员国国内数据保护政策一致化东盟个人数据保护框架确立了一系列的原则，包括同意、通知和目的，个人数据的准确性、安全保障、访问和更正、跨境数据传输、存留以及问责等 7个方面。在同意、通知和目的方面，该框架规定企业在未获同意情况下不得收集、使用和披露个人数据。在跨境数据传输方面，该框架规定在将个人数据转移到另一个国家或地区之前，企业应获得个人有关向境外传输的同意，或采取合理措施确保数据接收方将按照框架中确定的原则保护个人数据。东盟个人数据保护框架虽然是东盟出台的首个专门针对个人数据保护的区域层面的规制，但该框架对各成员国并不具有国际和国内的法律约束力，仅作为指导性文件为各成员国提供数据治理合作的框架基础，旨在灵活适应各成员国在数据保护监管方面的不同的成熟度。各成员国适用该框架可采取符合本国国情的例外措施。293.4.3.东盟数据管理框架和东盟跨境数据流动示范合同条款为企业提供数据管理和跨境数据流通的指引东盟数据管理框架和东盟跨境数据流动示范合同条款是东盟落实跨境数据流动机制的具体举措，目的是要促进数据相关的业务运营，减少谈判和合规成本，同时确保跨境数据传输过程中的个人数据保护。东盟数据管理框架为东盟企业提供指南，说明建立数据管理系统的每个步骤，包括建议的数据治理架构、防护措施及适当的风险管理。整个过程可以分为 6 个重点环节，包括治理与监督、政策与程序、数据清单、风险影响评估、数据保护控制、以及监测与持续改进。东盟跨境数据流动示范合同条款为企业之间跨境传输个人数据提供了合同条款模板，具体分为从控制者到处理者的数据传输、从控制者到控制者的数据传输两个合同模板。企业可以采纳或修改这些条文，就跨境传输个人数据拟订自己的法律协议。不过东盟数据管理框架和东盟跨境数据流动示范合同条款属于自愿性条款，并不对东盟企业具有强制的约束力，这也是考虑到东盟各成员国间数据治理水平的差异。2023 年 5 月，东盟和欧盟联合发布了东盟跨境数据流动示范合同条款（MCCs）和欧盟标准合同条款（SCCs）联合指引（“联合指引”），以利两个经济体内成员国的企业参考适用。联合指引将分为参考指引和实施指引两个部分。此次颁布的是参考指引，该指引对 MCCs 和 SCCs 条款的共性和差异性进行比较和详解，帮助企业理解相关的合同义务和数据保护要求。之后将颁布的实施指引将提供企业遵守合同条款要求的最佳实践，以供企业参考如何更便利的履行 MCCs 和 SCCs 合同义务。除了东盟跨境数据流动示范合同条款以外，东盟也承认其他的跨境数据流动机制，例如同等保护水平机制、个人信息主体的同意、行为规范（Codes ofConduct）、具有约束力的企业规则（BCR）、认证机制，如 ISO 体系或 APEC跨境隐私规则（CBPR）和处理者隐私识别体系（PRP）等。3.5.新加坡3.5.1.寻求加强监管与数据开放流动直接平衡的监管体系作为全球贸易自由化程度最高的经济体之一，新加坡在严格保护个人隐私的前提下，对数据跨境流动秉持开放的态度。整体来看，新加坡的数字跨境流动政策比欧盟宽松，对国内数据的保护比美国更为严格。新加坡通过运用双边协议或30多边协议中关于数据跨境流动的条款、在局部区域范围内试点数据跨境流动、探索沙盒监管模式等阻力更小、可行性更高的方式，积极参与区域合作机制建设和寻求区域内数据自由流动。3.5.2.新加坡数据保护监管框架概览及数据跨境的要点解析（1）新加坡数据保护监管框架概览新加坡数据保护监管框架概览2012 年 10 月，新加坡颁布个人数据保护法（Personal Data Protection Act，“PDPA”），该法确立了新加坡个人数据保护的基本制度。2021 年 12 月 1 日，新加坡对 PDPA 进行了修订，修订版本于 2021 年 12 月 31 日生效，系当前适用版本。个人数据保护条例（Personal Data Protection Regulations，“PDPR”）作为 PDPA规定的实施细则，进一步细化个人数据保护的合规要求。新加坡在 2013 年设立个人数据保护委员会（Personal Data ProtectionCommission，“PDPC”）。PDPC 隶 属 新 加 坡 信 息 通 信 媒 体 发 展 局（Info-communications Media Development Authority，“IMDA”），负责制定 PDPA合规指引、监督 PDPA 履行。在合规指引制定方面，PDPC 当前已颁布关于 PDPA 关键概念的咨询指南（Advisory Guidelines on Key Concepts in the PDPA，“PDPA Guidelines”）、关于特定合规话题的 PDPA 咨询指南（Advisory Guidelines on the Personal DataProtection Act for Selected Topics）、拒绝来电条款咨询指南（Advisory Guidelineson the Do Not Call Provisions）等。另外，对于特定专业领域的数据流动，PDPC会与各专业领域的主管部门合作，制定相关咨询指引，例如电讯行业咨询指引房地产中介行业咨询指引教育行业咨询指引医疗保健行业咨询指引等。在监督 PDPA 履行方面，PDPA 赋予 PDPC 较大的执法权，PDPC 有权对于违反 PDPA 的行为开展执法调查、作出处罚决定，采取的处罚措施包括但不限于：a.要求处罚对象停止收集、使用或披露违反 PDPA 的相关个人数据；b.要求处罚对象销毁违反 PDPA 的相关个人数据；c.对处罚对象最高处以其在新加坡年度营业额的 10%或 100 万新加坡元（以较高者为准）的罚款等。在违反 PDPA 的责任后果方面，除前述提到行政责任外，PDPA 还规定民事责任和刑事责任。PDPA 第 480 条赋予个人向法院起诉的民事救济权利。在刑事责任方面，对于未经授权故意使用、披露个人数据构成刑事犯罪的，行为人可能面临最高 2 年监禁如 PDPA 以及最高 5,000 新加坡元的罚款。企业通过故意更改、伪造、隐瞒个人数据收集、使用或披露的相关信息以逃避个人访问或更正个人数据的请求，可能面临最高 50,000 新加坡元的罚款，而行为人可能面临最高 12 个31月监禁以及最高 5,000 新加坡元的罚款。（2）数据跨境流通：不限制数据入境，但对数据出境要求数据跨境流通：不限制数据入境，但对数据出境要求“同等保护同等保护”对于不同的数据流动情形，PDPA 的监管要求不同：对于入境新加坡的数据，PDPA 不设限制；对于以新加坡作为出海各国数据集中存储地，在数据跨境合规义务方面，新加坡规定数据中转行为（intransit），即来自新加坡境外的数据通过新加坡进一步转移至第三方国家或地区过程中的个人数据，该个人数据在新加坡境内未被任何组织访问、使用或披露（传输方或传输方员工访问和使用除外），该类情形被视为已履行数据传输限制义务（PDPR 第 9-10 条）；对于由新加坡境内流向境外的数据，PDPA 第 26 条等条款规定除非根据 PDPA 相关要求确保接收方对传输的个人数据提供至少与 PDPA 同等的保护，不得将任何个人数据传输到新加坡以外的国家或地区。需注意的是，上述义务仅适用于“数据传输方”。对于数据接收方，新加坡则通过要求数据传输方确保数据接收方提供“同等保护”，通过数据传输方向数据接收方传导 PDPA 规定的数据保护义务。（3）持续传输及集团内部传输场景常见跨境传输方式持续传输及集团内部传输场景常见跨境传输方式从实践及 PDPA Guidelines 建议看，对于持续或集团内部传输场景，企业通常采用与接收方签订数据处理协议、集团内签订具有约束力的公司规则（BindingCorporate Rules，“BCRs”）的方式进行跨境传输。如传输方通过与接收方签订数据处理协议履行数据跨境传输义务，除要求接收方提供与 PDPA 相当水平的保护外，还需注意：a.协议内容：1）数据传输目的地国/地区；2）如接收方为数据中介（数据处理者）时，该合同还应包括：安全措施、留存期限限制、数据泄漏通知相关内容；以及 3）如接收方为数据中介外的其他主体（数据控制者）时，该协议还应包括：收集、使用和披露的目的、数据准确性要求、安全措施、留存期限限制、数据保护政策、访问权、更正权以及数据泄露通知相关内容（PDPR 第 11（2）（b）条及 PDPA Guidelines）。b.协议生效条件：该等协议经双方缔约即生效，无需再经新加坡政府审批或备案。新加坡主管部门也尚未像中国这样预先制定数据出境标准合同，因此数据传输方和接收方可自行起草该等数据处理协议。但新加坡作为东盟成员，PDPC明确承认东盟跨境数据流动示范合同条款（ASEAN MCCs）可满足协议要求。因此出海企业在起草数据处理协议时可参考 ASEAN MCCs。如传输方通过签订 BCRs 履行上述义务，除要求接收方提供与 PDPA 相当水平的保护外，须注意下述事项：a.适用范围限制：接收方与传输方须存在关联关系，包括传输方与接受方之32间存在控制关系或为同一主体所控制（PDPR 第 11（3）（a）条及 PDPA Guidelines）。因此，BCRs 更适合用于集团内数据传输情况；b.CRs 内容应包含：1）适用 BCRs 的接收方；2）适用 BCRs 的数据传输接收国；以及 3）数据保护权利及义务（PDPR 第 11（3）（b）条）。如传输方未能与接收方签订数据处理协议或BCRs，PDPC 在PDPA Guidelines中建议，企业可通过取得用户的同意或视为同意的方式履行数据跨境传输的义务。其中，“视为同意”情形包括：1）跨境传输为履行合同所必需：如基于该事由跨境传输数据，接收方可基于履行合同所必需向第三方再传输数据；2）用户主动提供个人数据或虽未主动提供但允许个人数据被收集使用。无论是取得同意或“视为同意”情形，传输方均须履行以下义务：a.告知义务：在请求个人同意前，传输方应向数据主体提供书面概要说明，告知其数据接收国对数据的保护措施，以及该保护水平不低于 PDPA（PDPR 第10（3）（a）条）；b.手段正当性：传输方不得以任何欺骗性或诱导性方式获得该同意（PDPR第 10（3）（c）条）；（4）积极参与区域合作机制建设和寻求区域内数据自由流动积极参与区域合作机制建设和寻求区域内数据自由流动2018 年，新加坡加入了亚太经济合作组织（Asia-Pacific Economic Cooperation，APEC）主导的亚太经合组织跨境隐私规则体系（Cross-Border Privacy RulesSystem，以下简称“CBPRs”）和亚太经合组织数据处理者隐私识别体系（PrivacyRecognition for Processors System，以下简称“PRPs”）。根据 CBPRs 的文件，想要通过 CBPRs 认证的企业需要通过 CBPRs 对于企业所在国当前的隐私保护法、隐私保护执法机构、隐私信任认证机构、隐私法的评估。新加坡个人数据保护委员会（Personal Data Protection Commission，以下简称“PDPC”）因此建立了一项与 CBPRs 对接的认证机制，如果在新加坡获得这一认证的企业，即可以在其他 CBPRs 成员内与其他认证企业自由传输个人数据。当接收方为数据中介方（Data Intermediary）1时，接收方应取得 APEC PrivacyRecognition for Processors System（APEC PRP）或 APEC Cross Border Privacy RulesSystem（APEC CBPR）认证；当接收方为数据中介外的其他组织（如数据控制者）时，该接收方应取得 APEC CBPR 认证（PDPR 第 12 条）2。1根据 PDPA 及 PDPA Guidelines 的定义，“数据中介”为代表数据传输方并为其目的处理个人数据的主体。2对此，数据出传输方可以登录 APEC 网站（www.cbprs.org）查询数据接收方是否已通过认证。333.5.3.新加坡与中国个人信息保护之比较新加坡与中国在个人信息保护方面存在诸多的异同（详见附件 4），例如不适用个人信息保护法律的规定，新加坡相较中国做出更为宽泛的规定；关于同意的规定，中国的法律要求同意必须是个人信息主体自愿、明确做出的，但新加坡规定了可以视为同意的情形。在个人信息跨境传输方面，新家坡相较于中国而言，有更为清晰的个人信息跨境规则，如前文所述的数据中转、持续跨境个人信息及跨国集团内部数据传输等情形，新加坡均做出了清晰的规定，为数据处理者提供了很好的指引。3.6.越南3.6.1.越南数据保护法律体系概况（1）数据保护相关法律法规数据保护相关法律法规越南个人数据保护法令于 2023 年 7 月 1 日起施行，是越南首部个人数据保护综合性立法，对个人数据保护原则、数据主体权利以及数据控制者和数据处理者义务、数据跨境传输等方面作出了规定。该法令同越南刑法网络安全法网络信息安全法消费权益保护法信息技术法电子交易法关于网络安全法若干条款的详细规定法令关于信息系统安全分类法令关于互联网服务及在线信息的管理、提供与使用法令电子商务管理法令关于邮政服务、电信、无线电频率、信息技术和电子转账的若干行政处罚规定法令等法律法规构成了越南现行的数据保护法律体系。（2）主要监管部门主要监管部门越南与个人数据保护相关的主要监管机构包括公安部、信息和通信部、国防部和科技部等。其中公安部负责指导和实施个人数据保护工作，保护数据主体的权利免受侵害，提出出台数据保护标准、个人数据保护和适用建议，并开展依法检查、审查、处理投诉和控告等工作，是最主要的监管机构。（3）特殊主体的克减义务特殊主体的克减义务个人数据保护法令明确规定，微型、小型、中型和初创企业在建立企业时，有权选择在注册的前两年内免于遵守相关要求。3.6.2.越南数据保护和数据跨境的要点简析（1）数据跨境传输机制数据跨境传输机制根据越南个人数据保护法令，“个人数据跨境传输”是指通过网络空间、34电子设备、电子手段或其他形式将越南公民的个人数据传输到越南境外地点或在越南境外的地点处理越南公民个人数据的任何活动。要将越南公民的个人数据转移到境外，跨境数据传输者必须进行个人数据跨境传输影响评估并持续更新和维护跨境传输影响评估档案，以供越南公安部检查和评估。跨境数据传输者应在处理数据之日起 60 天内将个人数据跨境传输影响评估档案提交给越南公安部；数据传输完成后应将相关数据传输的信息及负责组织或个人的联系方式以书面形式通知越南公安部。除特殊情况外，越南公安部将每年对个人数据跨境传输影响评估档案进行一次检查。如出现违反国家安全、提交的个人数据跨境传输影响评估档案不完整不符合要求或未根据新的变化及时更新、泄露或丢失越南公民个人数据等的情况，越南公安部可要求停止数据的跨境传输。（2）数据本地化及存储要求数据本地化及存储要求为了加强数据安全管理，越南网络安全法中纳入了数据本地化储存条款，规定“在越南提供电信网络、互联网和网络增值服务的国内外企业，其收集、挖掘、分析和处理有关个人信息的数据、服务用户关系数据、服务用户生成的数据必须在政府规定的时间内储存在越南。本款规定的外国企业必须在越南设有分支机构或代表处。”2022 年 10 月 1 日生效的关于网络安全法若干条款的详细规定法令对上述数据本地化条款进行了细化规定，特别强调对于在越南开展特定行业的外国企业，必须将上述三大类型的数据储存在本地，并在企业提供的服务被使用的情况下在越南设置分支机构或代表处。这些行业包括：电信服务；在网络空间存储和共享数据；为越南服务用户提供国内或国际域名；电子商务；在线支付；支付中介；通过网络空间传输连接服务；社交网络和社交媒体；网络视频游戏；以短信、语音通话、视频通话、电子邮件、在线聊天等形式在网络空间提供、管理或运营其他信息的服务。另外，该法令规定的数据储存期限最低为 24 个月，用于调查和处理违反网络安全法的系统日志至少保存 12 个月。3.6.3.越南与中国数据保护法律之对比中国和越南的数据保护法律法规既有相似的内容，又有基于各自国情形成的差异。中越均高度重视国家网络安全和网络空间主权，两国的网络安全法对部分数据的本地化存储都作了要求。此外，中越均高度重视保护公民个人信息安全，但因基本国情和发展状况等的不同，中越两国的个人信息保护法律法规也有诸多差异之处。如在个人信息跨境传输方面，中国个人信息保护法规定了数据出境安全评估、个人信息保护认证和个人信息出境标准合同等三条个人信息跨35境合规路径。越南的个人信息跨境合规机制则较为独特，仅要求跨境数据传输者在规定时限内向监管部门提交个人数据跨境传输影响评估档案。该影响评估档案应随时备存且依据变化情况及时更新，以供监管部门进行事后监管。在告知同意机制方面，越南个人数据保护法令对于同意的认定作了更加细致的要求：数据主体的沉默或不回应不应被视为其同意；数据主体可以给予部分或有条件的同意；如果发生争议，个人数据控制者和/或个人数据控制者和处理者应负责证明数据主体的同意。另外，越南在将个人数据用于广告营销服务和违规后的通知义务等方面也提出了更为严格的规定（详见附件 5.1）。3.7.沙特阿拉伯3.7.1.沙特阿拉伯数据保护法律框架概述目前，沙特阿拉伯规范数据治理的法律框架主要由个人数据保护法（TheSaudi Arabia Personal Data Protection Law（PDPL）和配套的个人数据保护法实施条例沙特阿拉伯境外个人数据传输规定以及适用于某些行业或部门的特定法规组成。2021 年 9 月，沙特阿拉伯部长理事会批准了沙特阿拉伯个人数据保护法。这是沙特阿拉伯第一部全面的个人数据保护法案，旨在规范该国个人数据的收集、使用和传输等个人数据处理活动。PDPL 在 2023 年 3 月进行了修订，并于 2023年 9 月 14 日正式生效。根据修订后的 PDPL 序言，自 PDPL 生效起有一年的过渡期，各实体应在过渡期内完成整改以使其个人数据处理活动符合 PDPL 的要求。2023 年 9 月 7 日，沙特数据与人工智能管理局（SDAIA）发布了沙特个人数据保护法实施条例及沙特阿拉伯境外个人数据传输规定。两部法规扩展了 PDPL（于 2023 年 3 月修订）中概述的一般原则和义务，并对数据控制者提出了新的合规要求。PDPL 适用于沙特境内以任何方式处理个人数据的实体。同时，PDPL 具有域外效力，如果外国组织处理与沙特居民有关的个人数据，则 PDPL 也将适用。3.7.2.沙特个人数据保护法要点简析（1）同意同意PDPL 立法体例参照了欧盟的通用数据保护条例（GDPR）的体例。它包括常见的关键原则和要求，如目的限制、最小必要、数据控制者责任、数据主体权利和违规处罚等。与许多国家的个人信息法案一样，对于个人数据收集和使用，PDPL 需要事先征得同意。36根据 PDPL 第 5 条，控制者必须在处理之前或处理时应“明确无误”获得个人同意。个人数据主体的同意可以以多种形式做出，包括书面、口头或电子方式等，但必须是在个人未被误导的前提下自愿做出。数据主体可以随时撤回对个人数据处理活动的同意，控制者不得要求以拒绝提供服务或福利为条件获得数据主体同意（除非服务或福利与所获同意的处理活动特别相关）。此外，如果存在多个个人数据处理活动，且分别具有不同的目的，则必须针对每个目的单独获得同意。（2）隐私政策隐私政策数据控制者必须制定隐私政策，PDPL 列明了隐私政策中必须包含的必要信息。数据控制着在收集个人数据前应当向个人数据主体提供隐私政策进行告知。（3）目的限制原则和最小必要原则目的限制原则和最小必要原则控制者必须明确收集和使用个人数据的目的，收集和使用的个人数据必须与收集和使用的目的具有相关性。另外，数据控制者必须在能实现预期目的的最小范围内收集个人数据。（4）影响评估影响评估控制者必须对处理个人数据的影响进行评估，如果预期目的不再需要某类个人数据，则数据控制者必须停止收集该类数据。（5）违规通知违规通知当发生数据泄露、未经授权访问个人数据等情况时，数据处理者必须通知监管机构；对个人数据主体造成损害的事件必须通知数据主体。（6）沙特个人数据保护法下的数据跨境传输沙特个人数据保护法下的数据跨境传输PDPL 要求数据控制者必须在沙特王国的地理边界内存储和处理个人数据。在某些情况下，如果不构成安全风险，数据可以在王国境外存储或处理。在向沙特境外提供个人数据之前，数据控制者必须进行影响评估，并获得监管机构的书面批准。监管机构将根据具体情况联系审批事宜。根据 PDPL 修订后的第 29 条，数据控制者可以将个人数据转移到王国之外或向王国之外的实体披露个人数据的前提是：1）为保护公共利益、公共卫生、公共安全或保护特定个人的生命或健康安全以防止、测试或治疗病理性感染而进行的转移；2）根据王国作为当事方的国际条约进行的转移；3）为服务于王国的利益而进行的转移；4）为履行数据主体的义务；375）根据与 PDPL 配套的个人数据跨境传输法规的允许的目的进行的数据转移。对于上述条件，PDPL 及其执行条例的草案也设置了具体的豁免情形：如果主管部门本身与其他机构合作，并经评估个人数据在沙特王国境外可以得到足够的保障，且不包括敏感个人数据的传输时，主管部门可以根据具体情况，免除控制者遵守第 29 条规定的任何其他条件。在不满足上述例外情况时，数据控制者必须向主管部门申请批准，方可将个人数据传输到沙特王国之外。批准申请必须在传输前至少 30 天提出，数据保护部门将有 30 天时间审查申请，并可酌情延长这一期限。如果这些例外都不适用，企业需创建本地的数据中心，并使用在沙特王国内处理数据的服务提供商，以满足沙特的数据本地化要求。3.7.3.沙特数据保护与中国的对比沙特个人数据保护法对个人数据跨境传输规定了严格的限制，其批准要求比 GDPR 数据转移限制更进一步，更类似于中国的个人信息保护法（以下简称个保法）。在个人数据权利方面，沙特 PDPL 与个保法一样，PDPL 赋予个人对自己的个人数据的权利，包括访问、更正和销毁/删除的权利。此外，PDPL 还授予个人知情权，要求处理者告知个人收集其个人数据的法律或实际理由和目的。违反个保法和沙特王国的 PDPL 都会引发行政或刑事处罚。沙特对违规行为的处罚相对严厉，包括对实施非法数据转移的行为的主体处以最高一年的监禁和/或 100 万里亚尔（约 25 万美元）的罚款，对实施违法披露敏感个人数据的行为处以最高两年的监禁和/或 300 万里亚尔（约 80 万美元）的罚款，以及 SDAIA能够施加最高 500 万里亚尔（约 130 万美元）的罚款。可以看到，沙特阿拉伯正在逐步对其境内的个人数据使用进行国家监管，并为法律的实施提供了宽限期，使监管对象符合 PDPL 的规定。同时需要注意的是，沙特目前关于数据合规、隐私保护的法律法规尚未完善，争议性的网络行为可能被禁止，中国企业在沙特运营应严格遵守当地法律并评估风险。3.8.日本3.8.1.日本数据跨境流通战略举措出于振兴本国经济、提高网络空间软实力、提升国际社会话语权等多重因素的考虑，日本通过修订国内立法、签订双多边国际协议、推广全球理念等战略举38措，不断推进跨境数据流通治理，倡导参与全球数据跨境流动合作。（1）通过修订和完善立法，构建与数据自由流动相匹配的数据安全机制通过修订和完善立法，构建与数据自由流动相匹配的数据安全机制日本多次修订个人信息保护法，对个人信息跨境制度规则进行动态调整。2015 年，日本修订个人信息保护法，增加了关于跨境数据流通的规定，包括设立个人信息保护委员会（PIPC）作为独立监管机构，制定向境外传输数据的规则和指南，增加数据出境须获得数据主体同意的一般性规定及例外情形。2020 年、2021 年，日本分别再次修订个人信息保护法，旨在促进大数据利用的同时解决数据的跨境流动中面临的风险。新个人信息保护法要求，在取得个人信息主体同意之前，应披露信息接收方所在国家及该国的个人信息保护体系、信息接收方采取的个人信息保护措施，同时采取必要措施确保接收方所在国家或地区持续实施了与日本个人信息保护法对个人信息的保护要求相当的保护措施。总体而言，日本多次修订个人信息保护法，强化对人信息出境行为的监管，对人信息出境提出了更为严格的要求，体现了日本通过构建数据安全机制来保障数据自由流动的战略考量。（2）积极参与双边、多边贸易协定，寻求数据跨境流动规则的广泛合作积极参与双边、多边贸易协定，寻求数据跨境流动规则的广泛合作在双边贸易协定方面，日本积极与欧美英等发达经济体签订贸易协定，对接协调数据治理规则，构建“数据流动圈”。例如，日本与欧盟经济伙伴关系协定（EPA）日美数字贸易协定，日英全面经济伙伴关系协定等双边协定均提到了促进数据自由流动的合作倡议。以日本与欧盟在数据跨境方面的合作为例，2018 年 7 月，日本与欧盟正式签署 EPA，约定建立数据流通安全区，相互将对方的数据保护体系视为同等有效；2019 年 1 月，日本与欧盟正式施行以互认为基础的个人数据跨境传输充分性框架，实现了日欧之间个人数据的双边自由传输；2022 年 10 月，日本与欧盟同意就将数据跨境流动规则纳入 EPA 进行谈判。在多边贸易协定方面，日本参与或加入亚太经合组织跨境隐私规则体系（CBPR）全面与进步跨太平洋伙伴关系协定（CPTPP）、区域全面经济伙伴关系协定（RCEP）等双多边规则体系和贸易协议，积极寻求和推动跨境数据流通规则的多边合作。以 CPTPP 为例，2017 年美国退出 TPP 后，日本接替美国开启了 CPTPP 的多边谈判，沿袭了美国在 TPP 中设置的一系列跨境数据流通规则。面对国际格局的深刻变革，日本积极参与双边、多边贸易协定，寻求数据跨境流动规则的广泛合作，不断提升其建立在高标准基础上的数据跨境国际协作水平。（3）构建和推行构建和推行“基于信任的数据自由流通基于信任的数据自由流通（DFFT）”机制机制，积极参与全球积极参与全球数据规则制定数据规则制定392019 年 1 月，日本时任首相安倍晋三首次提出 DFFT 概念。同年 5 月，安倍在第 25 届国际交流会议演讲中指出，将在 G20 峰会上启动名为“大阪轨道”的国际数据流动倡议。随后，在 G20 大阪峰会期间，“大阪轨道”正式启动，并签署 大阪数字经济宣言，标志着 DFFT 从概念提出阶段进入实践阶段。从 2021 年至今，日本通过七国集团（G7）、二十国集团（G20）等国际平台，不断推进 DFFT的制度化、机制化落地。2021 年 4 月，在英国举行的 G7 数字和技术部长级会议通过了G7 DFFT 合作路线图。同年 8 月，在意大利举行的 G20 数字经济部长级会议发布部长宣言，重申了 DFFT 的重要性和挑战。2022 年 5 月，在德国举行的 G7 数字部长会议通过了促进 DFFT 行动计划，同年 8 月，在印度尼西亚举行的 G20 数字经济部长会议发布 主席宣言，也重申了 DFFT 的重要性。今年 3 月，在日本举行的 G7 数字与技术部长会议发布了G7 数字和技术部长级宣言，提出建立新机制和通过新的伙伴关系制度安排来运作 DFFT。在全球数字贸易治理碎片化的情况下，日本通过构建和推进 DFFT 机制，倡导基于信任的数据自由流动，积极参与全球数据规则制定，不断提升全球的数字治理影响力和话语权。3.8.2.日本数据跨境流通法律规制要点简析日本数据跨境流通法律规制主要包括个人信息出境法律法规体系和多边贸易协定数据流通规则体系。其中，前者致力于规范和强化对个人信息出境行为的监管，后者致力于在高标准的基础上推进协定国之间的数据自由流通。（1）个人信息出境法律法规体系分析个人信息出境法律法规体系分析日本于 2003 年制定了日本个人信息保护法，并先后颁布了与个人信息保护法有关的施行令、施行规则，进一步细化个人信息保护规则。此外，日本政府专门设置个人信息保护委员会作为个人信息保护的主管部门，该委员会相继制定、更新了关于个人信息保护法的指南，为企业个人信息合规提供具体指导。日本个人信息保护法律法规体系如表 1 所示。表 1 日本个人信息保护法律法规体系项目项目法规名称法规名称基本法日本个人信息保护法实施法规及细则日本个人信息保护法施行令日本个人信息保护法施行规则实务指南日本个人信息保护法指南（其中，“外国第三方提供40篇”规定了个人数据出境要求）根据新修订的日本个人信息保护法及其配套制度规则，日本个人信息出境需满足以下条件：一是以事先取得个人信息主体的同意为原则，以不需要取得同意为例外。获得个人信息主体关于跨境传输个人信息的同意时，应当履行告知义务，事先向个人信息主体提供数据接收方所在国家或地区的个人信息保护的度、数据接收方采取的个人信息保护措施以及应供个人信息主体参考的其他信息，以便个人信息主体判断是否同意。此外，日本规定了无需取得个人信息主体同意的例外情形，包括向白名单国家跨境传输个人信息（如欧盟、日本），以及向已经建立了符合日本法规定的保护标准的个人信息保护机制的接收方跨境传输个人信息。二是判断接收方所在国家或地区是否拥有与日本具有同等水准的个人信息保护制度。日本个人数据跨境传输规则借鉴了欧盟 GDPR 的白名单机制，根据 GDPR 的相关规定，对于与欧盟具有同等水准的个人信息保护制度的国家，从欧盟向其跨境转移个人数据时无需另外取得个人信息主体的同意。目前，日本与欧盟、英国已建立白名单机制，认定对方的个人信息保护水平及安全措施具有同等水准，在不需要事先取得个人信息主体同意的情况下，允许个人信息在日本和欧盟、英国之间自由流动。三是判断接收方所在国家或地区是否建立了符合日本法律法规标准的制度且可持续采取同等保护措施。满足下列条件之一的可被认定为符合日本法律法规标准：1）个人信息运营商和第三方，应当以适当和合理的方法，确保第三方在处理个人资料时，实施符合日本个人信息保护法第四章个人信息运营商义务的措施；2）通过第三方获得国际体系认证，例如经合组织的隐私准则和 APEC 的跨境隐私规则（CBPR）系统的认证。（2）多边贸易协定数据流通规则分析多边贸易协定数据流通规则分析如前所述，日本参与或加入了 CBPR、CPTPP、RCEP 等双多边规则体系和贸易协议，致力于在高标准的基础上推进协定国之间的数据自由流通。一是 CBPR体系关于数据跨境流动的规则要求。CBPR 规则体系包含自评估、合规审查、承认或接受跨境规则、争端解决和执行四部分内容。在 CBPR 体系下，APEC 建立了数据处理者隐私识别（PRP）体系，并且还建立了跨境隐私执法安排（CPEA）。接受方获得 CBPR 体系的认证，是日本允许个人数据跨境传输的合法路径之一。二是 CPTPP 关于数据跨境流动规则要求。CPTPP 规定缔约方不得对数据跨境流动征收关税，要求缔约方允许包括个人信息在内的跨境数据自由流动，同时给予缔约方在不构成对其他缔约方贸易歧视和变相限制的情况下基于“合法公共政策”的豁免；允许缔约方对计算机设施的使用根据安全保障和机密保护设有不同监管要求，同时不得将数据本地化存储作为市场准入条件的强制性要求。三是 RCEP41关于数据跨境流动的规则要求。RCEP 要求缔约方不能阻止金融服务提供者进行其金融服务活动必需的相关信息传输；不得将计算机设施必须置于境内的规定，作为进入该缔约方内部市场的前提条件，不得阻止正常经营活动中的信息跨境传输活动，同时为以上约束提供了实施“合法公共政策”和保护“基本安全利益”两种豁免情形。3.8.3.与我国数据跨境法律法规对比分析在数据安全方面，我国主要遵循的上位法包括网络安全法和数据安全法，其中对数据的跨境转移和数据本地化都作出了限制；日本主要遵循的上位法为个人信息保护法，无数据本地化存储限制，但在跨境转移方面规定需取得个人同意，妥善处理数据。其中，日本侧重对个人数据的跨境保护，要求处理个人数据的经营者数据跨境转移需要满足：“事先获得个人同意的情况下，处理个人信息的经营者可向国外第三方提供个人数据”、“向个人信息保护委员会白名单中所列国家第三方提供数据时可不经个人同意直接提供（白名单欧盟、英国）”、“个人数据保护委员会有权对在日本处理个人数据的外国经营者行使处罚的权限，包括收集报告和现场检查”三个条件。中国对个人数据和公共数据的跨境均提出数据保护要求，对于关键信息基础设施运营者，数据跨境转移需要满足“应通过所在地省级网信部门向国家网信部门申报数据出境安全评估”的要求。在个人信息保护方面，中国主要遵循的上位法为个人信息保护法，对个人信息保护程度相对严厉；日本主要遵循的上位法为个人信息保护法和个人信息保护法相关指南，确立对个人信息权力保护的一体化监督机制。其中，对于个人信息的定义二者略有差别，中国认为个人信息为“以电子或者其他方式记录的与已识别或者可识别的自然人有关的各种信息”，日本方面则定义个人信息为“包括能够识别特定个体的内容及符号。内容自身无法识别特定个体，但参照其他相关信息后能够识别特定个体的信息也被纳入范畴内”，中日均规定匿名化的数据不属于个人信息范畴，但日本特别提出，对于假名化的信息（即只要不与其他信息对照就无法识别出特定个体的信息），在个人信息处理者内部使用时，可改变信息获取时的使用目的。同时，中日在个人信息保护的细节上略有偏差：例如，在管理模式上，日本实行一体化监督机制，由内阁府下设的个人信息委员会负责，个人信息委员会将原本分散在政府各个部门的各个领域的监督权回收，集中到了新设立的个人信息委员会，从而确立了对个人信息权利保护的一体化监督机制；我国实行由国家网信办统筹、各行业主管部门协同的政府主导模式，由国家网信部门负责统筹协调个人信息保护工作和相关监督管理工作。在认证机构上，日本 1998 年开始导入由经济产业省下属的日本情报处理开发协会（JIPDE）42认证的“隐私标志制度”；中国按照国家网信部门的规定经专业机构进行个人信息保护认证，如 CCRC 是 APP 个人信息安全领域的认证机构。3.9.印度3.9.1.经历多次曲折，终接近出台数据保护专门立法印度作为人口大国，超过 14 亿人口中拥有超过一半的互联网用户，且印度是全球科技巨头的重要发展市场，此前依赖的 2011 年的信息技术（合理的安全实践和程序以及敏感个人数据或信息）规则已无法解决互联网时代用户数据隐私保护和数据处理市场的平衡问题，因此制定一部专门的个人数据保护立法成为印度各界共同的呼声。然而，由于印度特殊的国情和庞大的人口基数，印度个人数据保护立法工作十分曲折，从 2018 年 7 月印度高级别专门委员会提出首版法案2018 年个人数据保护法案开始，经历了 2019 年印度电子和信息技术部提交的2019 年个人数据保护法案版本，2021 年印度议会联合委员会经历 78 次会议提交审议报告包括 81 项修正案和 12 项建议，2022 年印度政府则以议会联合委员会对法案修改过多为由，撤回了 2019 年版本，而后 2022 年 11 月，印度电子和信息技术部发布了2022 年数字个人数据保护法案草案，最终于 2023 年 8 月 9 日由电子和信息技术部长发布了印度2023 年数字个人数据保护法案（DPDP）。该法案将在印度总统批准后正式成为法律，使印度接近出台第一部数据保护专门立法。关于 2018 年、2019 年、2021 年印度议会联合委员会的建议及 2023 年法案主要内容的对比可参见附件 10.1。2023 年数字个人数据保护法案限缩了该法的适用范围，将此前采用的更为广泛的个人数据保护，替换为了更为明确、具体的“数字个人数据”（digitalpersonal data），后者使用范围更为广泛，研究规制也较为充分。同时，在境外适用方面，2023 法案相较于2022 法案删除了“特征分析”（profiling）这一情形，只保留了向印度境内数据委托人提供商品或服务相关的境外数据处理应适用法案的规定。3.9.2.印度数据保护及数据跨境的要点解析（1）确定了确定了“特定合法使用特定合法使用”的数字个人数据处理的合法性基础的数字个人数据处理的合法性基础一般而言，亚太地区的数据保护立法皆采用了“视为同意”（deemed to havegiven her consent）作为个人数据处理的合法性基础。印度2022 年法案同样采取了“视为同意”的立法技术，但是其引入了过多的“视为同意”情形引发了较大的43争议。因此，2023 法案 则创新性地采取了“特定合法使用”（certain legitimate uses）作为数字个人数据处理的合法性基础，但是保留了大部分2022 年法案中“视为同意”的情形，包括个人资源提供数据的特定目的、政府提供福利或服务、医疗紧急情况、就业等。此外，2023 年法案还特别赋予了国家处理个人数据的多项豁免，包括预防和调查范围行为、执行合法权利或索赔等，此处的国家包括中央政府、州政府、地方机构、政府设立的机关和公司等。由于国家的豁免允许国家将处理的数据用于其他目的，并允许国家将已有的个人数据用于任何目的，即消除了目的限制这一隐私保护的关键原则，因此关于国家豁免是否可能对隐私保护产生不利影响，目前仍在广泛讨论之中。（2）数据出境情形的规定更为宽松，从数据出境情形的规定更为宽松，从“必要因素评估必要因素评估”转为转为“通知限制通知限制”的的方式方式印度政府监管境外个人数据传输的目的是保护印度公民的隐私，因此若其他国家或地区缺乏健全的数据保护法，则存储在该国家或地区的数据可能更容易遭到泄露或未经授权与外国政府共享。因此，印度政府尝试对数据对外传输进行限制，四部法案（或建议）皆对数据跨境传输进行了规定，参见下表。法案名称法案名称具体内容具体内容2018 年个人数据保护法案草案每个受托人在印度至少存储一份个人数据副本如果获得同意，可以转移到印度境外的某些允许的国家或根据管理局批准的合同某些关键数据只能在印度处理2019 年个人数据保护法案敏感个人数据的副本应保留在印度仅在获得明确同意的情况下才能传输某些敏感个人数据，对其他个人数据没有限制关于关键个人数据，与 2018 年法案相同2021 年议会联合委员会的建议补充说明，未经中央政府事先批准，敏感个人数据不会与外国机构或政府共享2023 年数字个人数据保护法案删除敏感和关键的个人数据分类中央政府可能会通过通知将个人数据限制在某些国家/地区目前由于2023 年法案极有可能成为印度个人数据保护的正式立法，因此44未来在印度的数据跨境流通中特别需要关注2023 年法案的规定。其中明确，印度中央政府可以通过通知的方式限制向某些国家传输个人数据。这也意味着个人数据传输到所有其他国家在一般情况下没有任何明确的限制，除非中央政府以通知的方式予以限制，一般体现在将这些国家列入限制的清单之中。该措施相当于前三个法案（或建议）放宽了对数据跨境传输和流通的限制，此前的法案都要求对数据可能传输到的每个国家的标准进行逐案评估，而2023 年法案下则可以有选择地进行评估，可能导致传输国家评估的不充分，引发了印度业界关于该机制能否为印度公民的数据和隐私提供足够的保护的担忧。（3）业务流程外包提供商处理不在印度境内个人数据等特殊情形可不落入业务流程外包提供商处理不在印度境内个人数据等特殊情形可不落入适用范围适用范围2023 年法案规定，业务流程外包提供商在处理不在印度境内的数据主体的个人数据时，如果是根据印度境内的任何人员与印度境外的任何人员签订的任何合同进行的，则不受该法的约束。然而，2023 年法案的某些规定仍然适用，如实施 合理的安全保障措施以防止个人数据泄露 的义务。（4）对本地化存储的特殊规定对本地化存储的特殊规定对于特定行业，印度通过行业法规，对该行业的数据做出了本地化存储的要求。例如银行业，印度储备银行（RBI）依据 2007 年支付和结算系统法（thePayment and Settlement Systems Act，2007）于 2018 年 4 月 6 日发布的关于支付系统数据存储的通知，RBI 指示所有系统提供商须确保与其运营的支付系统相关的全部数据存储在印度法律管辖范围内的系统中；再比如 2020 年外国直接投资综合政策（the Consolidated Foreign Direct Investment Policy）中规定的条件之一是广播公司不得将用户数据库转移到印度法律管辖范围以外的任何实体或地方，除非得到相关法律的允许；再比 2014 年公司（账目）规则the Companies（Accounts）Rules第 3（5）条中的但书规定，以电子方式保存的账簿、公司其他账簿和文件的备份（包括在印度境外的）应存储在物理上位于印度法律管辖范围内的服务器中。（5）特别法庭特别法庭印度建立了一套专业审理信息技术相关案件的专业法庭，并在较低审级的阶段排除了普通法院体系的管辖权。为了行使印度 IT 法下的权利，个人必须向印度政府任命的、具有相关专业知识的裁决官（Adjudicating Officer）提出投诉并由裁决官审理：对裁决官的决定不服的，则应向电信争端解决和上诉法庭（TelecomDisputes Settlement and Appellate Tribunal，TDSAT）上诉；对于 TDSAT 的裁决结果，可再次上诉至相应州的高等法院。45（6）印度数据保护机构印度数据保护机构在现行立法下，印度的数据保护机构是电子和信息技术部（Ministry ofElectronics and Information Technology，MeitY）。电子和信息技术部有权就电子和信息技术领域的问题提供指导。为应对数据安全事件，电子和信息技术部成立了印度计算机应急小组（CERT），作为接收和回应所有违规通知的节点机构。根据2023 年法案，中央政府将成立印度数据保护委员会。该委员会的主要职能包括（i）监督合规情况并实施处罚，（ii）指导数据受托人在发生数据泄露时采取必要措施，（iii）听取受影响者的申诉。委员会成员的任期为两年，并可连任。中央政府将规定委员会成员人数和遴选程序等细节。对委员会决定的上诉将由 TDSAT 受理。3.9.3.与中国法律的对比印度2023 年法案对标的是我国的个保法，皆是针对个人信息或个人数据做出的综合性立法。由于国情和法域的巨大差异性，两部法律存在较多的不同之处，具体可见附表。下文将展开重点需要关注的四点不同。（1）适用范围方面适用范围方面，印度法案适用于印度法案适用于“数字个人数据数字个人数据”，相比中国相比中国“个人信息个人信息”的范围更为狭窄的范围更为狭窄印度在2023 年法案中将该法的适用范围确定为“数字个人数据”（digitalpersonal data），而将以线下方式或是非数字化形式收集的个人数据排除在规制范围外。中国个人信息保护法的适用对象为“个人信息”，并不排除如纸质收集的非数字化形式收集的个人信息，保护范围更为广泛。（2）在主体名称方面，印度法案使用了在主体名称方面，印度法案使用了“数据持有者数据持有者”和和“数据受托人数据受托人”两个两个概念，中国个保法则使用了概念，中国个保法则使用了“个人信息处理者个人信息处理者”和和“受托人受托人”的表述的表述印度2023 年法案在主体名称使用上与欧盟的“数据控制者”“数据处理者”结构较为类似，其使用“数据持有者”一词去概括“合法持有并且有一定保护义务的人”，英文翻译为 Data Fiduciary，而不同于欧盟“数据控制者”（DataController）；而对于接受委托处理数据的人，则使用“数据处理者”的概念予以概括。我国个保法则使用了“个人信息处理者”和“受托人”的表述，“个人信息处理者”是我国个保法规则的核心对象，个保法明确了个人信息处理者对受托人的个人信息处理活动的监督职责。这与印度2023 年法案确定了“数据持有者”首要和唯一的责任地位具有类似性。即，印度2023 年法案明确，数据处理者仅是代表数据持有者并按其指示或约定进行数据处理，数据持有者对数据处理者获取、使用、开发乃至删除数据的整个过程都在程序和实质上掌握着控制权和主动权。46（3）处理个人数据的合法性基础方面，印度法案采取处理个人数据的合法性基础方面，印度法案采取“合法目的合法目的 同意同意 or特定合法使用特定合法使用”的模式，特定合法使用的范围较中国个保法合法理由的范围的模式，特定合法使用的范围较中国个保法合法理由的范围更为广泛更为广泛印度2023 年法案规定处理个人数据的合法性基础是在根据本法规定并出于合法目的下处理个人数据，在此情形上满足数据委托人已同意或属于特定合法使用两个条件其一。中国的个保法则并列规定了七点处理个人数据的合法理由，除了取得个人的同意之外，其余六种情形可以视为在同意以外处理个人数据的合法事由。在具体的合法事由中，中国的个保法额外包括“处理已合法公开的个人信息”，印度2023 年法案则包括“为国家机构提供补贴、福利、服务、认证、执照或者许可目的使用”“主权和国家安全”“为履行判决等理由”等中国个保法处理个人数据合法理由中没有涵盖的情形。同时，印度特定合法使用的情形之一是“自愿提供数据并且未向数据受托人表示不同意使用其个人数据的”，该条款可以理解成个人自愿同意相当于默示同意，只要个人未明确反对，即可处理。因此，印度处理个人数据的合法性事由是宽泛于我国个保法的。（4）在向境外传输个人信息方面，印度在向境外传输个人信息方面，印度2023 年法案调整成了年法案调整成了“不限制不限制向境外传输个人数据向境外传输个人数据”的模式，但赋予了中央政府确定能否数据出境的权力，我的模式，但赋予了中央政府确定能否数据出境的权力，我国法律则对数据出境进行了较为严格的限制国法律则对数据出境进行了较为严格的限制在此前版本的印度法案中，对于印度的数据出境予以了较为严格的限制，即必须进行中央政府的“必要因素评估”后通知数据受托人方可出境。同时，印度 2022年版本的法案还提出了满足条件的强制数据本地化的要求，对于个人敏感数据，必须存储在印度境内，但其副本可以按照跨境转移的要求进行传输到印度境外。而印度2023 年法案极大地放宽了对于数据出境的限制，没有了数据本地化的强制性要求，更加鼓励数据流动，然而也为中央政府赋予了较大的权力，即数据能否出境将依赖于中央政府的通知或者其他法律的另行规定，这也为印度数据出境的宽严程度附加了更多的不确定性。我国法律则对数据出境提出了较为严格的限制，规定了数据出境应当经过安全评估、认证、签署标准合同等流程。3.10.俄罗斯3.10.1.俄罗斯联邦个人信息及数据法律环境分析（1）俄罗斯联邦数据与信息安全法律体系俄罗斯联邦数据与信息安全法律体系根据俄罗斯国家杜马发布的 关于网络与数据信息保护立法与政策发展报告（以下简称网络与数据报告），俄罗斯关于网络主权与数据保护的规范性文47件主要呈现“两大类、双层次”的分布特征，“两大类”是指传统部门法和新颁布的政策性文件；“双层次”是指对国内、国外两个层次的监管，该特征在传统部门法和政策性文件中也均有体现。网络与数据报告 指出，俄罗斯已发布了近 50 部国家层面的法律法规与政策性文件，就网络主权问题给予国家立法支持与保护，呈现出立法数量多、颁发部门层级高、涉及范围广的特征；形成了以俄罗斯联邦宪法及已经缔结的国际条约为基础，以俄罗斯联邦关于信息、信息技术和信息保护法俄罗斯联邦个人数据法和俄罗斯联邦主权互联网法案为准则，以其他联邦法律与规范性文件为补充的数据与信息安全法律体系。（2）强本地化的规定强本地化的规定目前，全球对于数据流动监管尚未形成统一的规则和方案，新兴经济体与发达国家采取了截然相反的数据监管制度。各国在选择数据流动监管制度上受地缘政治、国家安全、隐私保护、产业发展水平等因素的影响，形成了数据自由流动与数据本地化两大基本监管制度。俄罗斯作为全球化进程中重要的经济体，基于数据主权的安全需求与立场，制定了数据本地化的监管措施，表现为跨境与境内限制性措施相结合，既要求跨国企业在俄开展业务或提供服务时须在俄境内建立数据中心，也对数据存储和服务器地址提出本地化要求。3.10.2.俄罗斯联邦数据跨境保护及审查要点分析（1）信息安全要点信息安全要点俄罗斯联邦法律对信息安全的要求主要有以下几点：1）未经本人同意，禁止收集和传播有关其生活的信息。2）所有信息技术都是平等的不能强迫公司使用任何特定的技术来创建信息系统。3）对特定类型的信息传播不做限制，例如有关环境状态的信息。4）对特定类型的信息禁止传播，如宣扬暴力的信息。5）存储信息的人有责任保护信息安全。6）被禁网站的登记册。俄罗斯联邦通信、信息技术和大众传媒监督局（）可以禁止在俄罗斯联邦境内传播非法信息的网站。7）被封禁网站的所有者可以通过删除非法信息并将其报告给俄罗斯联邦通信、信息技术和大众传媒监督局（）解禁网站。（2）个人数据保护要点个人数据保护要点个人数据保护法是俄罗斯联邦关于“个人数据”保护的主要法律。该法律规范了个人数据的处理活动，对个人数据的保护主要有以下几点：1）在收集和处理个人数据之前，需征得个人的同意；482）为了保护个人数据，仅可基于特定目的收集个人数据；3）有义务保障收集的个人数据的安全；4）个人数据的主体要求删除其个人数据的，需按要求删除其个人数据；5）在俄罗斯处理个人数据，需在俄罗斯联邦境内的数据库中存储和处理这些数据。（3）公司数据保护要点公司数据保护要点1）公司可以决定某一数据是否是商业秘密并形成公司商业秘密的数据清单。2）特定类型的数据不能归类为商业秘密，例如，有关公司创始人或员工人数的数据。3）俄罗斯联邦基于充分的理由可以要求公司提供商业秘密，例如，对公司涉嫌违法的情况进行调查。4）公司有义务保护其商业秘密，并保留有权访问此数据的人员的记录。5）公司员工泄露商业秘密，可能会被解雇、罚款或起诉。（4）数据跨境监管要点数据跨境监管要点1）数据共享或转让如果个人数据不是从数据主体处直接取得，接收人（处理人）应在开始处理个人数据前向个人数据主体履行告知义务，但以下情况除外：处理人已对数据主体进行告知;个人数据是由处理人履行法定义务或数据主体作为一方当事人的合同而取得;该等个人数据是由该数据主体自行公开或由处理人从公开来源取得的;为统计或其他研究目的、或处理是由新闻记者或大众传媒作为其专业活动的一部分或为科学、文学或其他创造性活动的目的而进行的，但处理行为会损害数据主体的权利和自由的除外；若向其告知会侵犯第三者的权利和合法权益。2）数据跨境转移：提供同等保护在将个人数据转移出俄罗斯之前，处理人必须确保接收国对个人数据提供足够的保护。比如接收人所在国加入并批准了 个人数据自动化处理中的保护公约。2013 年，俄罗斯列出了被官方认可为“确保充分保护”的国家名单。除了公约成员国外，截至目前还有 26 个国家被认可为“确保充分保护”的国家名单。如果处理人向无法提供同等保护的境外主体转移个人数据，必须满足以下条件之一：取得数据主体的书面同意；俄罗斯联邦参加的国际条约中关于签证事宜另有规定的，以及国际条约中涉及提供民事、家庭和刑事案件司法协助事宜另有规定的；基于保护俄罗斯联邦宪法制度、保障国家安全目的所需；履行数据主体作为一方当事人的合同要求；在不能取得个人数据主体的书面形式同意时为保护个人数据主体或者他人的生命、健康、其他重大生存利益。493.10.3.中俄数据保护及数据跨境合规对比在个人数据层面，俄罗斯注重保护个人数据权利。在保障个人数据权利的同时，注重保障个人数据不被窃取、破坏和滥用，以及确保整体数据系统的安全可靠运行。由于个人数据隐私的属性很难界定，俄罗斯所采取的措施与美国等国家有所不同，俄罗斯在加强对科技公司使用本国用户数据的监管与限制使用搜索引擎的同时，正研究制定向数字企业征收数字税的规范。在跨境数据流通层面，俄罗斯实行严格的管控制度，对不同国家的数据主体实行差异化的法律监管。例如，对于美国等主动型数据流动国家，俄罗斯以俄罗斯联邦主权互联网法案为基础，在全球首次立法，实施“主动断网”，以识别网络主权威胁；在保护数据主权的同时，孤岛维权式地反对网络霸权成为保护性特征的重要表现形式。面对新兴经济体保守型数据流动国家，俄罗斯采取较为柔和的监管态度，在实施数据本地化存储的同时，兼顾数据流动的对等性。俄罗斯联邦信息数据安全保护的监管特点最明显的就是数据存留本地化，数据存留本地化是专门限制数据跨境传输的措施，包括禁止信息出境、跨境传输信息必须征得数据主体的同意、要求在境内留存信息副本、对数据输出征税等形式。“棱镜事件”后，俄罗斯加快了数据流动法律的修改，旨在全面限制数据流动，加强数据流动监管，从法律层面确立了数据处理本地化的基本规则。总体来看，俄罗斯的立法规定十分严格，通过对企业施加法定义务，实现了政府对数据处理、存储和跨境传输等环节的全面控制，牢牢掌握了本国数据跨境流动的主动权。我国个保法正式确立了我国个人信息跨境流动的规则体系，规定个人信息以在境内存储为原则，并确定了需要在满足法律规定的条件下可以向境外提供个人信息的规则。我国的数据治理模式和方法仍在逐步探索和完善中，鉴于我国数字经济蓬勃发展、数据要素丰裕，在借鉴他国经验的同时，更要积极寻求符合国内数据要素保护方式和跨境数据流通的规则，逐步探索出一条符合中国特色的数据治理之路。3.11.欧盟3.11.1.棱镜事件推动的数据跨境流动立法密集时代2013 年美国棱镜事件加速了欧盟对数字经济时代数据跨境流动规则的重新审视，欧盟认为与美 国签署并生效于 2000 年的安全港协议已无法充分发挥在双方数据跨境流动机制中保证欧洲公民 数据隐私的效用，于 2015 年由欧盟法院裁定该协议无效并撤销；随后，欧洲委员会在 2016 年初与美国达成新协议50“欧盟一美国隐私护盾”（EU-US Privacy Shield，以下简称“隐私盾协议”）。2016年，欧盟议会通过了 2016/679 号条例通用数据保护条例（GDPR），建立了基于充分性认定的白名单制度、约束性公司规则、标准合同条款和行为准则四项数据跨境流动体系。2020 年 7 月 16 日，欧盟法院对施雷姆斯案数据保护专员诉 Facebook 爱尔兰和 Maximillian Schrems 案,C-311/18,“Schrems II”）作出裁决,认定欧美数据跨境传输机制的隐私盾协议无效。2021 年 6 月 4 日，欧盟委员会公布了将个人数据从欧盟传输到第三国的新标准合同条款并于 2021 年 6 月 27日生效。同时，欧洲数据保护委员会于 2021 年 6 月 18 日更新了关于为确保遵守欧盟个人数据保护水平而采用的对数据跨境传输工具补充措施的建议。欧盟委员会和美国于 2022 年 3 月 25 日宣布，双方原则上已就新的跨大西洋数据隐私框架达成一致，该框架将促进跨大西洋数据流动，并解决欧盟法院在 2020 年 7月 Schrems II 裁决中提出的问题。美国总统拜登于 2022 年 10 月 7 日签署一项行政命令，指示美国将采取措施，履行跨大西洋数据隐私框架下的美国承诺。2023年 7 月 10 日，欧盟委员会通过了欧盟-美国数据隐私框架（EU-US Data PrivacyFramework,DPF）的充分性决定。DPF 规定了将个人数据从欧盟的控制者或处理者转移到第三国和国际组织的规则，包括明确了欧盟的数据控制者及处理者可以在无需获得任何进一步授权的情况下将个人数据转移到经认证的美国主体。（详见附件 8.1）3.11.2.欧盟数据保护及数据跨境的要点简析欧盟 GDPR 将个人数据作为基本人权进行保护，其规定覆盖了包括公私部门在内的各行各业的个人信息处理行为，且处罚额度可高达 2000 万欧元或年收入 4%。GDPR 及其对违反 GDPR 行为的严厉执法力度，在全球范围内带来了深远的影响（详见附件 8.3）,以下主要结合 GDPR 进行分析。（1）独立数据保护机构独立数据保护机构 EDPBGDPR 正式生效的同时，欧盟数据保护委员会（EDPB）也正式成立，总部位于布鲁塞尔，是欧盟的独立数据保护机构，负责发布关于 GDPR 核心概念解释的指南，并通过对有关跨境处理活动的争议做出具有约束力的决定来做出裁决，确保在整个欧盟范围内统一应用数据保护规则，并促进欧盟数据保护机构之间的合作，以应对欧盟众多成员国在不同主权下的政策制定、理解、执行一致性难题。EDPB 由欧盟各成员国数据保护机构（国家监督机构）的代表和欧洲数据保护监管机构（EDPS）组成，EDPS 作为 EDPB 秘书处为其提供分析、行政与后勤等支持。（2）与欧盟同等保护水平下才被允许的个人数据跨境传输与欧盟同等保护水平下才被允许的个人数据跨境传输51欧盟将个人数据保护视为一项基本权利，一直坚持高标准保护个人数据。在消除境内数据自由流动壁垒、建立统一数据保护标准的同时，欧盟要求其他国家只有在提供与欧盟同等水平保护的情况下，才允许个人数据跨境向其进行传输。允许数据跨境的具体措施和要求包括：基于充分性认定的白名单制度基于充分性认定的白名单制度。欧盟委员会对欧盟以外国家或地区数据保护的充分性进行评估，将与欧盟保护水平相当的国家或地区列入“白名单”,允许欧盟个人数据向上述国家或地区传输。欧盟委员会对获得认定的国家和地区至少每四年进行一次评估，以确保其满足同等保护水平要求。约束性公司规则约束性公司规则（Binding Corporate Rules，BCR）适用于在欧盟设立总部或分支机构的跨国公司，由跨国公司自行拟定内部机构之间数据传输和保护的规则，经欧盟成员国数据监管机构审核批准后生效。运行多年来，共有 100 多家跨国公司申请并获得通过。BCR 解决了跨国公司内部机构之间频繁传输数据的隐私保护问题，但同时也存在适用范围有限、实施成本高等弊端。标准合同条款标准合同条款（Standard Contractual Clause，SCC）是数据传输双方采用欧盟标准合同条款，通过将 GDPR 规定的义务转化为合同义务和责任，确保对数据主体权利的保护。2021 年 6 月欧盟委员会公布了两套标准合同文本，取代了之前的三个标准合同文本：一是将个人数据从欧盟转移到第三国的新标准合同文本；二是适用于欧盟境内的控制者与处理者之间的标准合同文本。SCC 为数据跨境流动提供了一个相对宽松且安全的解决方案，有助于促进数据跨境流动规则的融合与统一。行为准则行为准则（Codes of Conduct，CoC）是 GDPR 新引入的机制。当欧盟以外国家未获得充分性认定时，该国的数据控制者或处理者可作出具有约束力和可强制执行的承诺，承诺遵守经批准的行为准则，则欧盟数据可向其传输。目前欧盟委员会还未批准任何 CoC。如果欧盟以外国家未达到欧盟数据保护水平，且仍未提供适当的保障措施时，GDPR 规定数据跨境的法定例外情形，包括：数据主体同意、履行合同义务、保护重要公共利益、保护数据主体及他人的重大利益、行使或抗辩法定请求权、公共注册登记机构数据传输等情形。3.11.3.中国对 GDPR 的借鉴与发展截止目前，欧盟委员会认定的充分数据保护的国家包括：安道尔、阿根廷、52加拿大（商业组织）、法罗群岛、根西岛、以色列、马恩岛、日本、泽西岛、新西兰、韩国、瑞士和乌拉圭、英国、美国（参与 DPF 的商业组织）。另外，2022年 10 月 10 日，EDPB 公布了对 Europrivacy 认证标准的批准意见，使得该认证标准成为欧盟通用标准，经评估后符合这一标准的认证对象，证书中可以获颁欧盟数据保护印章（European Data Protection Seal）。Europrivacy 认证成为目前所有欧盟成员国唯一正式认可的 GDPR 认证机制。有看法认为，GDPR 在相当程度上扮演了贸易壁垒角色，提高了他国互联网企业进入欧洲市场的成本。同时，欧盟试图通过对外输出占据道德高地的欧盟标准，以获取与美国等数字经济领先国家在全球数字贸易谈判中的优势，扭转自身在全球数字竞争中的不利局势。在通用数据保护条例施行一周年之际，美国信息技术和创新基金会下属的数据创新中心发布的 GDPR 实施一年以来的影响报告指出，通用数据保护条例并未产生欧盟立法者预期的积极效果，反而存在对欧盟经济的消极影响。其在增加企业数据合规成本、损害科技公司创新和竞争力的同时，也增加了消费者获取在线服务的成本和不信任感。中国倡导全球数据安全，鼓励在保护个人信息权益，维护国家安全和社会公共利益的条件下，促进数据跨境安全、自由流动。对数据接受国或地区也采取同等保护水平的要求。欧盟 GDPR 的个人信息保护规定为中国制定个人信息保护法数据安全法提供了借鉴意义，同时，中国的个人信息保护法数据安全法和网络安全法也设置了知情同意制度、原则上本地化、黑名单制度和反歧视措施，在全球数字经济发展的大背景下更全面地规范了数据处理活动和数据跨境流动，以促进个人信息的自由安全的流动与合理有效的利用，推动数字经济的健康发展。2023 年 2 月 3 日，中国个人信息出境标准合同办法由国家互联网信息办公室 2023 年第 2 次室务会议审议通过并公布，自 2023 年 6 月 1 日起施行。个人信息出境标准合同办法对欧盟将个人数据从欧盟传输到第三国的新标准合同条款在一定程度上进行了借鉴，并结合中国个人信息保护与监管的特色有所创新，是中国跨境数据流通制度的又一里程碑。中国的个人信息出境标准合同办法对个人信息设置了更高级别的保护，要求境内提供方在标准合同生效之日起 10 个工作日内向所在地省级网信部门备案，提交标准合同（包含个案具体的保护措施及出境情况说明）和个人信息保护影响评估报告。欧盟虽然在 Schrems II案后对标准合同条款提出了更高要求，即境内提供方须证明个人数据出境后在实质上可以达到欧盟同等保护水平，而非形式签署标准合同即可，但并没有要求对标准合同进行备案。然而，和欧盟历史悠久且在 GDPR 实施后通过大量实践案例而不断丰富发展53的制度相比，中国个人信息出境标准合同办法仍存在需要完善的方面。比如，GDPR 中标准合同条款对于特定服务商来说并不是唯一的选择，还有公司准则、行为准则的承诺、第三方认证机制的承诺。但是根据中国个人信息出境评估办法，标准合同并不具有可选择性和任意性。其次，欧盟将个人数据从欧盟传输到第三国的新标准合同条款区分了四种可能的传输场景，包括控制器到控制器、控制器到处理器、处理器到控制器和处理器到处理器，分别规定相关义务。中国个人信息出境标准合同办法则并没有区分接收者的角色，仅规定从中国实体转移到“海外接收者”，更加强调各方数据处理者的责任义务，同等严格的要求。3.12.美国3.12.1.美国个人信息及数据法律环境分析（1）由联邦立法、州立法及行业自律组成的由联邦立法、州立法及行业自律组成的“拼凑拼凑”特色特色在美国立法体系中，数据保护框架包括数据隐私和数据安全，前者涉及个人信息的收集、使用和传播，后者涉及未经授权访问和使用个人信息。美国数据保护立法体系由联邦级立法、州级立法、行业自律准则三部分构成。美国尚未形成统一的联邦数据保护立法，但许多联邦、州的法律中均涉及隐私保护的相关法律条文。从联邦立法来看，美国数据保护法采取分行业式分散立法模式，集中于特定领域和特定对象。美国在特定政府部门、电信及网络、金融、健康、教育及儿童在线隐私等领域均有专门的数据保护立法，例如，限制州政府的机动车辆部门的1994年驾驶员隐私保护法（DriversPrivacyProtectionActof1994,DPPA）、电信及网络领域的视频隐私保护法案（VideoPrivacy ProtectionAct,VPPA）及1984 年有线通信政策法（Cable Communications Policy Act of 1984）等。同时，2023 年3 月，拜登-哈里斯政府发布了国家网络安全战略（NationalCybersecurityStrategy）。从州立法来看，各州均在积极进行数据保护领域立法。其中，2018 年 6 月28 日，加州州长批准通过 加州消费者隐私法案（California Consumer PrivacyAct，CCPA）,创设了美国历史上最为严格且全面的数据隐私保护制度，该法案于2020 年 1 月 1 日正式生效。2020 年 11 月 3 日，加州选民投票通过第 24 号提案加州隐私权法案（California Privacy Rights Act,CPRA）该法案实质性修订了此前里程碑式的 CCPA,因此CPRA 亦被称为CCPA 2.0,已于 2023 年 1 月 1日全面生效。美国加州的CCPA/CPRA 与欧盟的通用数据保护条例（GeneralData Protection Regulation,GDPR）也一并成为了当前全球最突出的数据保护立54法，事实上的数据保护全球标准。从行业自律准则来看，美国数字隐私行业自律准则的兴起与 20 世纪末美国政府提倡行业自我监管的政策息息相关。相对于政府管制，行业自我监管更具效率性和灵活性。在自我监管的理念下，通过“告知和选择”程序落实消费者信息保护，企业将隐私政策纳入服务合同供用户选择，除法律明确禁止或限制外，企业可自由收集、处理和分享从客户处获取的信息。不同于欧盟严格保护个人隐私的立法态度，美国对于数据保护的立法态度更多侧重于数据流通所带来的经济价值，以期通过促进数据跨境维护自身已建立的信息优势。（2）由由 FTC、CFPB、FCC、HHS 等组成的联邦数据保护执法机构等组成的联邦数据保护执法机构目前，美国有多个联邦机构负责数据保护执法工作，包括联邦贸易委员会（Federal Trade Commission,FTC）、消费者金融保护局（Consumer FinancialProtection Bureau,CFPB）、美国货币监理署（Offce of the Comptroller of theCurrency,OCC）、证券交易委员会（Securities and Exchange Commission,SEC）、联邦通信委员会（Federal Communications Commission,FCC）、卫生与公众服务部（Department of Health and Human Services,HHS）和商务部等。在诸多联邦机构中，FTC 在制定美国隐私标准方面发挥了突出作用，通常被视为领导性的数据保护执法机构，有权对“不公平和欺骗性贸易行为”执法，同时亦有权对儿童在线隐私和商业电子邮件营销等问题执法。近年来，FCC 亦发挥了突出的执法作用。FTC 和 FCC 外的其他机构则是根据具体的法规或条例，负责相关的隐私执法工作，例如，卫生与公众服务部（HHS）的民权办公室根据健康保险可携性和责任法案（HIPAA）负责医疗隐私的执法；美联储和货币监理署根据格雷姆一里奇一比利雷法（GLBA）负责金融隐私的执法。3.12.2.美国数据保护及数据跨境的要点解析（1）以以 CCPA 和和 CPRA 为代表的为代表的“美国标准美国标准”如前所述，美国无统一的联邦数据保护立法，因此我们选取了美国在全球最具影响力的数据隐私立法，即最具代表性的“美国标准”CCPA 和 CPRA,并结合我国个保法的相关规定，对美国 CCPA 和 CPRA 数据保护的一般要求予以比对分析（详见附件 9.1）。除已生效的 CCPA 和 CPRA 外，值得注意的是，2022 年 6 月 3 日，美国众议院和参议院商务委员会主要成员联合发布美国数据隐私和保护法案（American Data Privacy and Protection Act,ADPPA）（详见附件 9.2）草案文本，55这是首份获得美国两党、两院支持的联邦综合性隐私保护法草案。ADPPA 草案的适用范围及被涵盖主体广泛，被涵盖主体包括受其他联邦法案约束的实体，其义务范围既反映州隐私法，也存在一些例外情况。ADPPA 草案成为法律仍有很长的路要走。如 ADPPA 草案正式通过，则美国将具备联邦层面的统一数据保护立法，并将广泛地取代此前聚焦于消费者的法律，例如，加州的 CCPA/CPRA,但ADPPA 草案将保留未受影响的CCPA/CPRA法规下针对安全违规行为的私人诉讼权。（2）允许境外数据流入、限制境内数据流出允许境外数据流入、限制境内数据流出由于美国对于数据的态度是希望通过数据跨境活动维护自身的技术经济优势和所拥有的数据市场，发挥数据经济价值，占据全球领先地位。因此，在数据跨境方面，美国采取“允许境外数据流入、限制境内数据流出”的跨境数据流通政策体系。简而言之，美国对于数据跨境流动采取截然相反的两种态度强监管数据向外流动，而允许数据自由向内流动。最具代表性的“美国标准”CCPA 和 CPRA 均为州立法，故不涉及数据跨境传输。在数据跨境活动方面，美国直接相关的法案主要有：澄清海外合法使用数据法案（Clarifying Lawful Overseas Use of Data Act，CLOUD Act）、出口管理条例（Export Administration Regulations，EAR）和2023 年保护美国人的数据免受外国监视法（Protecting Americans Data From Foreign SurveillanceAct of 2023,PADFFSA）。目前，CLOUD Act 和 EAR 均已生效，但 PADFFSA尚未生效。CLOUD Act 于 2018 年 3 月 23 日生效，最核心的内容是加强美国的长臂管辖，即，无论数据是否储存在美国境内，均允许美国联邦政府强制调取服务提供者的数据，否定以数据存储位置认定数据主权的判断标准，确立以服务提供者的控制权认定数据主权的新体系，扩大美国执法机关调取海外数 据的权力。这意味着，任何在美国设有办事处或子公司的外国公司均须受 CLOUD Act 的约束。同时，其他国家若要调取存储在美国的数据，则必须通过美国“适格外国政府”的审查，需满足美国设定的人权、法治、数据自由流动标准。美国对于个人信息类型的数据跨境传输持开放态度，但对于其他重要数据则采取相应的限制，严格限制关键技术与特定领域的数据出口。EAR 严格限制部分关键技术与特定领域的数据出口，受管制的技术数据传输到位于美国境外的服务器保存或处理，需取得美国商务部产业与安全局（BIS）的出口许可。美国总统 2010 年签署的 13556 号行政令界定的“重要数据”范围，包括农业、受控技术信息、关键基础设施、应急管理、出口控制、金融、地理产品信息、信息系统漏洞信息、情报、国际协议、执法、核、隐私、采购与收购、专有商业信息、安全56法案信息、统计、税收等 17 个门类。PADFFSA 则针对敏感个人数据的跨境传输制定了严格的规则。虽尚未生效，但仍须引起中国企业注意。根据 PADFFSA，由美国商务部长联合其他联邦机构负责对数据进行分类，确定哪些数据类型可能会被外国势力利用，以及传输的数据的数量级高于特定的阈值从而损害美国的利益。对于适用范围内的数据将受到EAR 项下的相应管制。3.12.3.美国与中国数据保护法律之对比（1）中美中美跨境数据流通跨境数据流通存在政策限制存在政策限制在两国的立法中，对于数据跨境流动都有所限制。以美国数据隐私和保护法案（以下简称“法案”）为例，该法案明确要求，数据处理企业应向消费者说明，其所收集、处理、传输的数据是否会提供或者以其他方式提供给包括中国、俄罗斯、伊朗、朝鲜在内的国家。中国的个人信息保护法要求，个人信息处理者需要向境外提供个人信息的，需要进行个人信息保护影响评估，取得当事人的单独同意，具备法定条件，并确保境外接收方的处理活动符合规定。（2）以中国个保法为例对比美国数据保护立法以中国个保法为例对比美国数据保护立法美国标准 CCPA 和 CPRA 是消费者保护领域的州立法，中国的个保法是统一的综合性数据保护法，存在诸多不同之处，例如：（1）中国个保法相较于美国 CCPA/CPRA,适用的地域范围、受保护的主体范围、受规制的实体类型、适用的数据活动等均更为广泛；（2）中国 个保法 与美 国 CCPA/CPRA,在定义个人信息、敏感个人信息及分类、合法性基础范围、同意机制等规定中均存在差异（详见附件 9.1）。虽然美国尚无联邦层面的数据保护立法，但是，针对美国议院拟议的美国数据隐私保护法进展以及可能对我国企业境外合规工作的影响，我们亦加以整理（详见附件 9.2）。（3）中美数据保护立法取向不同中美数据保护立法取向不同美国与中国数据保护法律规定的不同亦体现两国对于数据保护的不同立法态度，例如，中国的个人信息保护立法趋于欧盟的 GDPR 与美国之间，在重视保护个人信息的前提寻求与数据经济发展的平衡，美国则致力于加强美国在数字经济中的领先优势。例如，就个人对数据处理的“同意”而言，中国采取须取得信息主体同意（opt-in）的模式，要求个人数据处理活动应具有合法基础，而美国CCPA/CPRA 选择退出模式（opt-out）为主要机制，仅要求特定的数据处理活动取得个人同意，其他情况下则可以不经个人事先同意而处理数据，但个人可以选择退出。573.13.尊重区域差异，做好数据跨境合规限于篇幅，我们无法全面的分析各国在数据保护及数据跨境的具体规定，只能粗浅的向各位读者展示部分国家和地区的法律要点，作为一个引子，以期让各位读者了解到不同国家和地区在数据保护及数据跨境法律环境方面是存在很大差异，即使是最基础的处理个人信息前的告知同意，不同国家和地区的规定不尽相同。我们不能闭门造车，需要了解和吸收各国和地区优秀的经验。正因不同国家和地区关于数据保护和数据跨境的理念、规范乃至数据的基本定义有很大差异，相关主体在涉及到数据跨境业务时，需要尊重不同国家和地区的差异，除了使自己的业务符合本国和地区的法律法规外，还需符合境外接收方所在国家和地区对数据保护的要求。58第四章 跨境数据流通技术解决与合规方案数字经济的发展源自与技术的进步，跨境数据流通既是法律问题，也是技术问题。如何使数据依法有序安全跨境流通，不仅需要法律在数据跨境合规中发挥积极作用，还需要新技术在新场景应用上找解决方案。4.1.跨境消费：某知名大型港资消费品企业数据跨境方案某公司，作为一家知名大型港资消费品企业，在境内与境外均有业务布局，境内境外会员相关业务相对独立。鉴于两地社会联系紧密且顾客群体中相当一部分存在交叉，为了服务好这一部分群体以及将来可能发生的跨地区经营活动。公司需要建立数据跨境通道，以实现两地会员业务数据互通并激发会员消费潜力。4.1.1.案例背景该公司在境内境外两地均维护着CRM 系统，并建立了两套独立的会员体系。在这两地，会员的消费积分、会员等级、会员信息等均未进行同步。随着两地游客往来频繁，线下门店接待的境外客户数量逐渐增多。然而，许多顾客对于两地会员体系不互通的问题产生困惑。（1）业务挑战业务挑战由于同一品牌下不同地区的会员体系不同，会员在一个地区的消费积分、会员权益在另一地区无法查看和使用。而且，由于会员权益带来的附加值较高，无法享受会员应有的会员权益会引起客户不满情绪。线下门店的店员不能便捷地查询顾客的会员账户信息，这限制了他们及时识别客户类型并提供定制化服务。若客户若在两地接受不同水平的服务，可能会产生心理落差，影响其消费意愿。后端业务分析人员由于缺少此部分交叉客户群体的消费数据，难以分析和预测消费热点和消费人群等关键业务指标，这限制了业务活力，并为供应链、生产、销售等环节增加了不确定性。（2）应用场景与需求应用场景与需求在用户层面上，改方案能满足客户在两地同步累计消费积分享受会员权益的需求；在业务层面上：前线员工应能够及时得知客户的会员账号信息，以便提供定制化服务。同时，后台业务分析人员将能获取更多关于交叉用户地消费数据，从而促使经营分析更加全面可靠，支撑业务发展。594.1.2.技术方案考虑到问题紧迫性、技术建设的时间周期、业务改造的难度、合规要求等，本跨境解决方案流程示意图如 4.1-1 所示，具体分为如下两个步骤：（1）短期补救方案实施：通过简单而高效的方法解决两地会员体系信息不互通的问题。将在原境内会员平台中增加一个新的功能区域，会员可以进入此区域来开通和绑定境外会员帐户，并同步其基础信息至境外会员系统地数据库。一旦会员完成绑定和同步操作，境外线下门店地店员就能通过会员手机号识别出会员在境内的消费情况，识别是否高价值客户，或者是新客户。并为客户提供定制化的服务。（2）长期完善方案规划：通过系统搭建和业务同步等措施，目标是使境内外的会员体系最终融合为一个高度统一的整体。在未来的计划中，更多的境内会员账户信息将被传输至境外的会员系统数据库，会员在境内消费与境外消费的积分按照一定比例统一积累至唯一会员账户。同时在线下门店终端，可以根据会员手机号或会员码，识别出完整的会员在境内与境外的消费情况，以及其他相关会员信息。用于判断会员的消费习惯、兴趣，同时便利业务部门分析产品销售情况，优化业务布局与决策。图 1 跨境流程示意图4.1.3.方案创新点和亮点为缓和数据字段最小必要性所存在的矛盾，并在合规的红线内开展高效的数据跨境活动。在跨境方案设计之初，合规团队已与业务团队、数据分析团队展开深度沟通与合作，探索数据传输最小必要可能性。60第一期数据跨境方案当中仅传输七项个人信息字段，其中两项是由消费者在注册会员账号时自行提供、与其个人强相关的个人信息字段，其余五项是会员在该品牌消费后产生的消费记录相关字段。考虑到不同字段的敏感程度以及在业务当中的重要性。对于消费者个人强相关字段，在跨境传输前进行了脱敏处理。而基于消费后产生的数据字段也剔除了个人属性而使用会员编号替代。4.1.4.应用效果采用此种方案成效是在最大程度上不影响业务正常开展的前提下，保证境外前线门店工作人员无法定位至具体的消费者，但可以了解会员的大致消费习惯以及会员等级，工作人员可以基于前述信息为消费者提供定制化的服务。后端数据分析人员开展分析工作同样基于无法定位至具体消费者的字段，同时也可以得出完整的数据分析结果，以支持业务决策。4.2.跨境金融：香港银行跨境电子签署为了实现大陆居民、香港居民在线开立香港地区商业银行账户，深圳 CA 在项目中对持不同身份证件的两地居民提供统一标准的身份核验服务、数字证书服务和电子签署服务。且本项目在大陆和香港两地电子签名互认的司法框架下合法开展，深圳 CA 依据中华人民共和国电子签名法粤港电子签名互认策略等法律法规签发的数字证书签署的文件，在中国大陆和香港具有法律效力。4.2.1.案例背景内地与香港居民在银行开户的跨境开户的需求确实受到一些监管限制，通常需要他们在银行所在地区进行面审和签署协议，以确保开户人的合规性。这种做法不仅效率低下，而且给客户带来了不便。为了解决这一痛点，在粤港两地电子签名证书互认办法的框架下，深圳 CA 结合自身产品能力，提出一套在内地和香港均合规的银行跨境电子签署方案。4.2.2.技术方案（1）方案思路方案思路为满足银行的业务需求，深圳 CA 将项目中多个标准产品进行组合，并结合银行业务系统特点进行定制化改造。主要涉及如下产品和服务：大陆居民、香港居民身份核验、跨境数字证书、嵌入客户方 APP 的身份核验 SDK、嵌入客户方web 端的电子签署页面、支持简体中文/繁体中文/英文的显示界面和短信服务等。61（2）方案实现流程方案实现流程深圳 CA 根据银行远程在线开户业务中对申请用户身份的认证需求，以及跨境电子认证服务的业务规范，以 PKI/PMI（PKI：公钥基础设施；PMI：授权管理基础设施）技术为基础，依托深圳 CA 作为第三方 CA 机构所提供的电子认证服务为核心，为银行建一个完整的电子认证服务平台。通过银行在线开户系统集成深圳 CA 的相关 SDK 控件和接口，在银行部署业务签署平台并与深圳 CA 的身份认证服务平台、证书签发系统、证书管理系统实现无缝对接，为远程开户业务提供完善的身份鉴证、在线签署、粤港互认等服务。本项目总体架构如图 2所示：图 2 跨境电子签署服务平台总体架构图4.2.3.方案创新点和亮点本项目将大陆居民身份核验SDK及香港居民身份核验SDK同时集成在银行的 APP 上，大陆香港两地客户通过同一银行 APP 办理所需的银行业务，客户通过选择不同身份证进入不同核验流程。采用 H5 签署的方式，将深圳 CA 的电子签署集成到银行的网页端，产品体量轻，实施效率高，客户体验感好。4.2.4.应用效果通过此项目，推进了大陆客户在香港银行开设商业银行账户的进程，为日后吸引更多大陆客户打下了基础。香港市场采用了香港居民身份核验平安方案，摆脱了该行只有一家供应商的局面。在电子签署方面，首次采用基于数字证书 密62码学的更安全的电子签署方案。在整个香港银行业，大陆居民线上开户仍处于一个早期发展的时期，客户借此项目，走在整个行业前面，为促进两地金融科技合作提供了范本。图 3 跨境电子签署服务平台网络传输路径图4.3.跨境芯片研发：M2&SKC 芯片数据跨境安全计算为了降低 HBM IP 流片失败的成本，国内芯片设计公司 M2 需要更专业的境外芯片设计公司 SKC 帮助其进行设计调优和制造测试。因此，两家公司需要使用对方的数据进行加密隐私计算，以获取最直接的提高流片成功率的设计方案。由于项目涉及跨境数据流通，为了保证监管合规并尽量降低数据泄露风险，两家公司需要第三方中立 IT 服务商 UCloud 安全屋数据沙箱托管数据，并提供隐私计算、算力、存储、网络和安全服务。4.3.1.案例背景（1）业务挑战业务挑战首先，由于芯片设计制造行业算法成本及隐私加密难度高，全部为定制化流程，没有任何可参考经验。隐私计算部分涉及核心数据，且不能绕过 EDA 算法层。其次，由于合规及数据风险评估需求，漫长的 POC 测试过程导致前期推进63几度停滞，商务及技术侧的对接失位导致项目受限于商务谈判能力效率滞后；合同谈判过程亦受技术侧进度和国内外数据安全政策变化影响。最后，跨境合规要求及隐私计算性需要能跟上用户交付时效性要求。（2）技术挑战技术挑战首先，由于存在数据泄露风险，芯片数据部分明文规定，需要用合同条款约束使用方行为。其次，由于数据的类型是非常规的，数据包量级基本 3T 以上，且由专业程序应用打开，相当于流通的加密数据包，EDA 算法嵌入对于安全检测有非常规要求，标准 MPC 产品难以实现。最后，隐私安全与可用性难平衡。作为巨量算力项目且有时效性要求，对于隐私计算部分的加密程度需要做出部分牺牲，且需要客户允许 MPC 介入核心算法层进行改造，对业务效率进行妥协，通过其他技术手段和流程限制来同步规避数据安全风险。4.3.2.技术方案UCloud 安全屋以成熟产品为基础核心输出第三方数据流通服务能力及 MPC服务价值，在关键数据层完成价值保护及防窃取工作。UCloud 安全屋采用私有化集群部署，物理上是分布式部署，逻辑上是去中心化协作。此项目中，国内芯片设计公司 M2 作为甲方，国外芯片设计公司 SK2 作为乙方，第三方中立 IT 服务商优得 UCloud 作为丙方，提供隐私计算、算力、存储、网络和安全服务。第三方服务商与另外两方之间不存在业务竞争性，不存在关联控股竞争性，且在原始能力上能够帮助甲乙双方完成软硬件及实时过程的整体安全合规和组织管理。芯片数据跨境安全计算应用场景的整体框架图如图 4 所示。此项目中，国内芯片设计公司 M2 作为甲方，国外芯片设计公司 SK2 作为乙方，第三方中立 IT 服务商优得 UCloud 作为丙方，提供隐私计算、算力、存储、网络和安全服务。第三方服务商与另外两方之间不存在业务竞争性，不存在关联控股竞争性，且在原始能力上能够帮助甲乙双方完成软硬件及实时过程的整体安全合规和组织管理。芯片数据跨境安全计算应用场景的整体框架图如 5 所示。64图 4 整体架构图图 5 UCloud 安全屋业务流程图4.3.3.方案创新亮点在技术升级上，超长前置调试 MPC 嵌入芯片 EDA 编译，直接对原算法进拆分编译，使数据加密本身对业务影响降到最低，使用方无感应用。在技术创新上，对原有算法进行最小程度拆分，层 SMPC 隐私计算，叠加层数据沙箱，将隐私加密计算与数据安全流通拆分进，并尽量降低性能损耗，保证业务流畅及项成果交付时效性。654.3.4.应用成效甲方收益及目前成果有，按业务约定，甲方仅获得最终 PDK 文件，用于其项目的最终流片量产对接，过程文件及数据归乙方所有，不可被取出。项目截止时，甲方可获取应用于实际生产的 PDK 文件。甲方商业侧对于目前的成果进展表示满意，从时间效率进度及流片成本层面上极大的降低了无效损耗，提高芯片设计验证能力。乙方收益有，SKC 侧的专家人力价值输出及知识产权被保护，在这个合作模式下可稳定长期收取费用，并且降低了差旅成本及人员投入数量。与此同时，在双方合作的中间过程中完整保留数据及工程经验，帮助其持续保持行业领先的工程经验值。4.4.跨境数据：中国首单场内跨境数据交易2022 年 11 月 15 日，深圳数据交易所（以下简称：深数所），与数库（上海）科技有限公司（以下简称：数库科技）实现了国内首单场内跨境数据交易，为探索跨境数据流通交易迈出了坚实的第一步，也为推进跨境数据交易制度和规则衔接提供了实践经验。这不仅意味着数库科技的整体实力再次受到权威认可，更标志着数据跨境时代的正式起航。同时，该笔交易也经过了第三方律所合规评估及深数所的交易风险评估及见证。4.4.1.案例背景2022 年 2 月 12 日，深圳市探索开展数据交易工作方案正式通过深圳市委全面深化改革委员会第二十四次会议。其中提及，到 2022 年底初步形成新型数据交易体系框架，到“十四五”期末初步形成全球数据交易市场枢纽，打造 5家左右知名跨境数据商，培育 100 家以上具有技术优势及特色应用的中小型数据商。深数所自成立以来，广泛对接央地各级部门以及跨行业多种类市场主体，开展调研与业务对接，积极探索跨境数据交易，已经与香港生产力促进局签订“跨境数据流通试点合作框架协议”，正在推进首批跨境数据交易，场景覆盖金融、电商、互联网、医疗行业。4.4.2.整体方案（1）数据产品介绍数据产品介绍此次数库科技与知名境外头部对冲基金交易的标的为“数库 SmarTag 新闻分析数据”。该数据产品属于原创数据集，是深数所重点推进首批跨境数据交易之66一，通过公司在自然语言处理领域的旗舰级新闻标签解析引擎 SmarTag 生产。SmarTag 主要通过自主研发的 NLP 算法将市场中的高频非结构化新闻资讯转化为机器可读的结构化元数据。这一产品主要通过自然语言处理算法对国内主流网站的财经及行业新闻资讯进行提取加工，形成标签化数据，在剔除个人信息、新闻标题及新闻内容后，向境外客户提供。在技术层面，SmarTag 以多种深度学习和机器学习技术为基础，将对新闻的分析转化为多种自然语言处理任务的组合。由于各任务存在一定的重合，分析过程采用有向无环图的形式调度各项算法。产品架构图如图 6 所示。图 6 数库 SmarTag 新闻分析数据产品架构图（2）数据数据出境目的与方式出境目的与方式境及境外数据接收方的数据处理在金融行业投融资领域的应用，包括为资产管理机构的量化分析、优化二级市场的策略决策提供支持等。交易数据以数据表及宇段说明的形式，上传至 SFTP 服务器，供境外接收方访问、下载及存储。相关协议中约定了数据接收方的处理方式，并且均对数据接收方的转售或对外提供限制、数据安全保护及责任承担进行了约定。（3）数据出境涉流程数据出境涉流程数库科技数据交付过程包含数据文件生产、数据文件授权、数据文件推送、67数据文件入库的环节。如图 7 所示：图 7 跨境数据交易流程图在数据存储安全方面，数库科技数据库系统使用主备模式，从库用来进行数据的备份。另外，数库科技对数据库数据进行日度备份并使用多台机器存储。对于本地的数据 NAS 服务器，硬件磁盘通过定义 raid 的不同级别来增加磁盘可靠性。此外，还通过为对象存储提供 SSE-KMS 默认加密、为数据库使用 AES-256进行数据加密来保障数据存储的安全性。在数据传输安全方面，针对数据传输过程可能面临的被中断、截获、篡改、伪造等风险，数库科技采取以下措施控制风险：1)采用负载均衡技术，通过服务冗余的方式，将相同的应用部署到多台机器上，解决访问统一入口问题，实现流量分发。这样，即使面对大量用户访问、高并发请求或非法请求/攻击时，也能保障数据传输服务的可用性。2)采取防火墙技术有效隔绝外网非法入侵内网的风险，同时使 IP 白名单策略进行身份验证，有效拒绝非授权的访问请求。3)通过 SSL、HTTPS 和 SSH 等网络加密协议，保障数据传输通道的保密性，避免数据被截获。4)通过基于 SHA256 的 Hash 校验算法，保障数据传输的完整性。5)使用基于 RSA2048 的非对称加密算法，及私钥加签、公钥验签的数宇签名68方式，保障数据传输不被篡改、伪造。（4）数据出境法律法规要求数据出境法律法规要求数库科技委托广东北源律师事务所开展合规评估，广东北源律师事务所针对交易主体、交易标的、交易流程三大维度进行客观独立地评估并出具法律意见书。同时，深数所对该交易的交易主体基本情况、交易数据情况、交易合同及风险评估情况等多项事宜进行审查并留存了相关记录。基于相关材料，深数所尚未识别到交易数据涉及个人信息及重要数据的情况，考虑到数据本身为公开数据，且经过标签化及剔除个人信息、新闻标题及新闻内容的处理，深数所认为数库科技主动防范了数据跨境交易的安全风险，该交易基本符合法律法规的要求。4.4.3.数据产品创新点和亮点SmarTag 的最大特点在于其标准化的数据体系。算法所提取的公司、行业、产品、地区等标签都与数库科技知识图谱体系中的公司图谱、产业图谱等图谱中的节点对应，并且带有唯一性的标识 ID。因此，在提取标签的同时，实体链接的问题得以解决，标签得以对应到知识图谱上的具体实体，并且在下游应用中可通过知识图谱进行进一步的图计算。SmarTag 以自然语言处理技术为基础，通过对金融资讯的解析、提取和标准化，形成了一套完整的资讯分析算法和系统。这能够实现对金融资讯的清洗和去重，得以从资讯中提取出公司、行业、产品、概念、事件、地区等多种标准化标签，分析资讯及资讯中具体主体的正负面舆情，并将标签等结果注入数库的数据体系，形成规范化、标准化的知识图谱，从而实现了对海量资讯的实时分析，为各种金融应用和计算提供了数据支撑。4.4.4.应用成效（1）量化投资应用量化投资应用数库科技的 SmarTag 可对新闻文本的结构化解析，从而实现对全篇新闻及新闻中的主体情绪解析。并且，通过各维度的标签及情绪分析数据的结合，可对各公司主体的情绪进行定量研究。同时，也可以构建 A 股全市场的新闻情绪，例如，A 股个股情绪因子、A 股行业情绪指数和 A 股市场情绪指数等，为相关量化人士提供更多 Alpha 挖掘机会。（2）荣誉奖项荣誉奖项数库科技的“智能文档资讯分析技术服务”荣获上海市高新技术成果转化项目。在首届应用算法实践典范 BPAA 中，数科科技“智能文档与资讯分析技术”荣获“金融算法赛道全球 10 强”。694.5.数字贸易：基于数字贸易资产的融资解决方案融资是中小企业的发展过程中长期面临的难题，联易融（Linklogis）基于自身在供应链科技方面的领先优势，与国际清算银行创新中心启动数字贸易资产（Digital Trade Asset，DTA）项目，共同探索数字技术在金融领域的应用，推动科技赋能和产品创新，为拓宽中小微型企业融资渠道提供有力支持。该项目提供了一个原型平台，核心买家及供应链上游供应商可利用数字贸易资产实现附条件支付。中小型企业可在未满足既定条件之前利用 DTA 向机构投资者寻求融资。4.5.1.案例背景（1）行业现状行业现状在迅速发展的全球供应链格局中，中小微企业在经济增长和技术创新中发挥着至关重要的作用，为全球经济和社会发展提供了不可或缺的力量。世界银行的研究表明，中小企业占所有企业的 90%以上，贡献了全球 50%以上的就业机会，也在全球供应链中发挥着重要作用。尽管中小企业发挥着如此重要的作用，但因为缺乏抵押品或在档的信用和运营记录而较难得到传统投资方的资金支持，面临着长期的融资难题。（2）业务挑战业务挑战在传统的供应链中，核心买家经常以赊账（Open Account，OA）的方式从一级供应商那里采购货物或服务，因为核心买家往往具有更强的议价能力。负责交付产品的一级供应商又根据 OA 或信用证（Letter of Credit,LC）条款将某些制造流程外包给二级供应商，或从二级供应商处购买零件或材料。这是供应链的基本运作模式。但由于于缺乏抵押品和/或已建立的信用和运营记录，且保理和发票等贸易融资产品不能实时更新贸易信息，投资者给中小企业的贸易融资意愿大大降低。同时企业运营规模较小，这导致中小企业贸易资金周转困难，营运风险陡增。4.5.2.技术方案（1）解决方案思路解决方案思路基于传统的供应链结构，联易融构建了一个原型平台，核心买家及其供应链上的供应商可以在该平台上使用 DTA 进行交易可编程支付。在不同的贸易阶段，DTA 有不同的状态体现，分别为：未实现的（unrealised）、“确认的（confirmed）”、和“已实现的（realised）”。核心买家根据贸易合同将基于行为、数据和时间的DTA 状态转移的条件编码到智能合约上，当供应链上贸易流程的某一环节被确认，DTA 就根据上述预设条件自动完成相应的状态转移。当 DTA 的附加条件均70已满足，下游供应商就可以向发行方兑换 DTA，获得等值的法定货币。通过区块链和智能合约等去中心化技术，充分保障供应链上各参与方之间贸易的正确执行与资产的安全转让。（2）平台功能架构平台功能架构假设必要的监管已经到位，DTA 可由平台上核心买家要求的商业银行发行。图 8 说明了 DTA 在供应链上贸易结算中的应用：图 8 传统供应链中 DTA 的应用流程图核心买家与一级供应商签订采购订单，然后从 DTA 发行方处获得 DTA，并使用（与合同金额等额的）DTA 向一级供应商进行有条件付款供应商。DTA可以由核心买家根据时间、行为和数据为条件进行编程预设，预设条件举例如下：1)基于时间的条件：仅在特定日期向 DTA 接收者付款。2)基于行动的条件：只有当核心买家表示接受付款时，才会向 DTA 的接收者付款。3)基于数据的条件：仅当某个贸易平台或承运商已发出电子提单时，才会向 DTA 的接收者付款，或者当供应商达到一定的 ESG 级别时，才会向供应商支付奖金。这些条件被编码在区块链上的智能合约上，一旦满足预设条件，付款就会自动执行。图 9 展示说明了在多层级的供应链上，DTA 如何应用在发行、转让、融资和兑现等场景中。71图 9 多级供应链中 DTA 在发行、转让、融资和兑现场景中的应用供应链上持有 DTA 的供应商可以通过兑现、转让或融资等方式来获取营运支持：1)兑现：在 DTA 发行处兑现满足条件的 DTA（见 3a/4a/5a）；2)转让：将全部或部分避免双重征税条约转让给上游供应商，以支付其欠上游供应商的全部或部分债务或应付款项（见 3b/4b/5b）；3)融资：在条件满足之前，通过 DTA 平台与投资方（机构投资方）利用全部或部分 DTA 融资。以 DTA 为预付款项去做投资。在这种情况下，投资方承担的信用风险是来自供应商的履约风险和 DTA 发行方的信用风险的（投资方不承担核心买家的信用风险，因为索赔是针对 DTA 发行方的）（见 3c/4c/5c）。4.5.3.方案创新点和亮点1)流程创新流程创新：更流畅地衔接供应链贸易与中小企业融资的场景。2)模式创新模式创新：运用 DTA 实现贸易信息的实时更新，解决了传统融资场景中投资方无法及时信息同步的问题，使得中小企业的信用评估变得更快、更容易，也提升了投资者的投资意愿。3)融资方式创新融资方式创新：核心买家可利用 DTA 实现附条件支付，中小型企业可在未满足既定条件之前利用数字资产向机构投资者寻求融资。这不仅为中小型企业开拓了空前丰富的融资选择，也为投资者开辟了新的投资机会。4)科技创新科技创新：本项目方案展示了去中心化金融技术在贸易金融行业领域的创新运用，它提供了一个突破性原型，用数字资产用与智能合约技术来促进中小企业在供应链上的融资。724.5.4.应用成效中小企业在大多数经济体中发挥着重要作用，数字贸易资产项目原型可以为以前无法获得传统融资的中小企业提供新的融资途径，从而有助于刺激经济增长。利用区块链技术，原型平台还为参与贸易交易的各方以及投资方提供透明和即时可用的贸易信息。这些中小企业基础贸易和业绩记录的信息将使中小企业的信用评估变得更快、更容易，鼓励投资者向中小企业提供融资。同时，这也是为投资方开辟新的投资机会。对于核心买家来说，财务弹性更强的供应商意味着供应链更具弹性，可以促进其建立更稳健、更绿色、更具社会责任感的供应链。4.6.跨境金融：港股开户跨境可靠电子签署为了实现大陆居民、香港居民在线开立香港地区银行账户，深圳 CA 在项目中对持不同身份证件的两地居民提供统一标准的身份核验服务、数字证书服务和电子签署服务。且本项目在大陆和香港两地电子签名互认的司法框架下合法开展，深圳 CA 依据中华人民共和国电子签名法粤港电子签名互认策略等法律法规签发的数字证书签署的文件，在中国大陆和香港具有法律效力。4.6.1.案例背景随着各行各业信息化的迅猛发展，传统的商业模式逐渐转变成互联网的方式，证券行业同样需要顺应互联网的潮流，基于互联网模式的证券网上开户业务不仅有利于证券公司快速占据客户群和拓展业务中取得先机，同时互联网业务的运行成本低、覆盖面广的优势也将很好解决证券公司网点少、分布不均问题，促进券商业务创新与发展。为了实现大陆居民远程完成港股账户开立全流程，深圳CA 港股开户电子认证服务平台对持身份证件的大陆居民提供统一标准的身份核验服务、数字证书服务和可靠电子签署服务。4.6.2.技术方案（1）方案思路方案思路港股开户电子认证服务平台是深圳 CA 依托于跨境粤港互认电子认证服务资质，基于 PKI/CA 密码技术，围绕港股无纸化网上开户业务场景与需求，建设的跨境电子认证及签署服务平台，为港股网上开户提供可靠电子签名服务，确保网上开户与传统线下纸质开户协议具备同等法律效力，为券商业务创新提供支撑与保障，实现大陆居民无需现场面签，即可远程完成港股账户开立全流程。73（2）方案流程实现方案流程实现深圳 CA 根据港股远程开户业务中对申请用户身份的认证需求，以及跨境电子认证服务的业务规范，以 PKI/PMI 技术为基础，依托深圳 CA 作为第三方 CA机构所提供的电子认证服务为核心，为券商提供一个完整的跨境电子认证及可靠电子签署服务平台。通过券商开户系统、APP 集成深圳 CA 的相关 SDK/H5 组件和接口，在券商部署签署服务系统并与深圳 CA 的身份认证服务平台、证书认证系统实现无缝对接，为大陆投资者港股远程开户业务提供完善的身份鉴证、证书签发、在线签署、电子存证、粤港互认等服务。本项目总体架构如图 10 所示：图 10 深圳 CA 港股开户电子认证服务平台总体架构图4.6.3.方案创新点和亮点本方案将大陆居民身份核验及电子签署 SDK/H5 组件集成在券商的 APP 上，大陆客户可通过券商 APP，无需现场面签，即可远程完成港股账户开立全流程。产品体量轻，实施效率高，客户体验感好。4.6.4.应用效果通过此项目，极大推动了大陆客户在香港股市开设账户，投资港股的进程，也为日后香港资本市场吸引更多大陆客户打下了基础。目前深圳 CA 已经与超过六十家国内及香港券商合作，为近 400 万客户提供港股开户在线电子认证及可靠电子签署服务。多家券商通过实施此港股远程开户项目，使得港股开户业务走在整个行业前列，也为促进两地金融科技合作提供了范本。744.7.卫生健康：跨境就医结算服务平台久远银海跨境就医结算服务平台支持跨区域和跨境接入，实现就医和结算信息共享及业务对接，平台支持机构快速接入及医疗保险快速结算赔付和机构监管等业务。跨境就医结算服务平台提供了机构间互联互通、线上一站式快赔和监管等功能，并支持多方联合确认对象资格、多方审核互认、多方整合赔付路径及确认理赔结果等业务，能够缩短报销等待期，提高结算和赔付效率，并有效支撑对骗保行为的监管等。4.7.1.案例背景随着粤港澳大湾区建设的加速，湾区内居民交流日益密切，越来越多港人到大湾区就医，也会有大陆居民赴港就医的情况，涉及基本医保和商业保险等一站式赔付和监管需求，传统理赔模式存在报销等待期长、报销手续复杂、报销需提交材料多，和个人需要对接多家保险公司等问题，并且由于数据不互通，有可能违反诚信原则，存在骗保行为，监管难度大。表 2 医保可能存在的赔付群体情况和传统理赔步骤4.7.2.技术方案（1）方案思路方案思路跨境就医结算服务平台的核心机制在于其实现了大陆医疗保障、大陆医疗机构、香港医疗机构、香港健保和香港商保公司、大陆商保公司之间的数据共享与业务协同。在严格遵守数据不出境的前提下，该平台通过患者（保险消费者）的授权，针对性地解决了理赔难、报销速度慢以及手续繁杂等长期以来的痛点。这75一创新举措不仅极大地提升了医疗保险的消费体验，也显著提高了商保赔付的准确率和效率，同时降低了管理成本和风险。（2）功能结构功能结构跨境就医结算服务平台主要由跨境就医理赔中心、跨境就医数据中心和管理规范体系三个核心部分构成。其中，跨境就医理赔中心是处理所有理赔申请的核心机构，负责确认理赔对象的资格、实施多方审核互认，并提供线上一站式快赔服务。跨境就医数据中心则是处理所有医疗保障数据、医院医疗数据、商保数据的关键机构。该中心对所有数据进行集成和治理，确保数据的准确性和共享的统一管理。这个中心包括数据处理子系统和数据监测子系统，用以实现高效的数据处理和实时监测。管理规范体系是跨境就医结算服务平台的重要组成部分，它制定了一套全面的跨境医商协同业务规范。这些规范对医疗保障、医疗机构与商保公司之间的数据共享和数据产品应用进行了严格的约束，包括保险产品登记、项目登记、数据使用申请、参保人授权等方面的详细规定。这一体系旨在确保所有数据的合法使用，保护参保人的隐私权，并进一步提升了整个平台的规范性和高效性。（3）平台架构平台架构平台的总体框架分为“五层二体系”，如图 11 所示：系统接入层包括医疗机构接口、医保系统接口、商保理赔接口，可以通过接入这些接口来连接不同的系统，实现数据的共享和交互。应用服务层包含跨境就医结算服务平台的双中心及所有应用，提供平台的所有业务处理和数据处理。应用支撑层包括任务管理引擎、控费规则引擎和风控规则引擎等，这一层为上层的应用程序提供了各种支撑服务，用于处理特定的业务需求。数据资源层包括三目病种库、医院知识库、结算清算库等，涵盖了系统运行所需的各种数据资源。基础设施层包括云计算平台、分布式存储和云虚拟网络等，提供了平台的基础运算资源和网络支持。商保理赔数据标准体系和数据安全保障体系可以提高商保理赔效率和准确性，保护保险公司信息安全和客户隐私。76图 11 跨境就医结算服务平台框架结构图（4）业务流程业务流程跨境就医结算服务平台是一个集数据处理、业务处理和医疗服务支持于一体的先进平台。该平台的核心是数据中心，它负责处理和存储来自香港的商业保险数据和理赔模型，这些数据和模型是支持跨境就医结算服务的核心组件，为平台的运行提供了重要的参考依据。参保人在深圳医院就诊后，可以通过线上申请理赔并签署授权。申请后，平台通过接口获取医疗保障数据中台及就诊医院 HIS的基础数据，在数据中心进行数据清洗、数据确权、数据加工、数据流通等处理，处理完的数据将导入一站式理赔子系统。在理赔子系统中，会根据商保数据和理赔模型进行自动化的理赔计算，减少人为错误的可能性，提高理赔处理的效率和准确性。计算得出的理赔结果将输出给香港商保公司，并经其确认无误后，商保公司即向参保人赔付相应的金额。平台业务流程图如图 12 所示。图 12 平台业务流程图77（5）技术架构技术架构跨境就医结算服务平台的技术架构能够实现高效的数据采集、处理和分析，保障数据的安全和隐私。同时具备可扩展性和灵活性，能够适应不断变化的需求和业务场景。图 13 跨境就医结算服务平台技术架构图4.7.3.方案创新点和亮点跨境就医结算服务对数据安全和隐私保护的要求较高，为此平台采用了多重安全技术与策略。首先，平台应用数据脱敏技术，包括动态脱敏和静态脱敏，以保护患者等敏感信息的真实性和隐私性；平台采用数据加密技术，以确保数据的完整性和机密性，防止未经授权的访问和泄露；平台引入了数据水印技术，能在数据中添加难以察觉的溯源信息，以便在数据发生泄露时能够迅速定位源头，及时采取应对措施；平台运用数据沙箱技术，在保证数据安全的同时，确保数据的使用和分析过程完全在安全的环境中进行；平台采用 API 安全监测与访问控制技术，能够实时监控并识别敏感数据的流动风险，从而及时发现并阻止任何可能的安全威胁，保证数据的安全与稳定传输。4.7.4.应用效果跨境就医结算服务平台对患者（保险消费者）、商保公司、医疗机构和医疗保障部门都有明显的好处。患者（保险消费者）无需再为了理赔而奔波于香港、大陆和医院、医保局、保险公司之间，大大简化了流程。商保公司不再需要投入大量的人力物力去核实理赔78申请的真实性和完整性，因为平台已经实现了对医疗数据的实时抓取和验证。这不仅提高了理赔的效率和准确率，也降低了商保公司的运营成本，提高了他们的工作效率。通过平台，医疗机构可以减轻工作负担，使其能够专注于提供医疗服务。通过与商保公司的信息共享，医疗机构可以及时获取理赔情况，这有利于提高医疗资源的合理配置。4.8.跨境征信：海外用户信用风险评估报告本案例涉及某大型贸易公司，该公司在全球范围内经营业务，业务板块涉及大量海外贸易场景。由于海外贸易的复杂性、不确定性及信息不对等，导致该公司对其海外客户及供应链上下游合作伙伴的信用风险评估存在挑战。为了有效管理这些海外客户及供应链上下游合作伙伴风险并保护自身利益，该公司决定引入中诚信征信有限公司（简称“中诚信征信”）的海外用户信用风险评估报告。4.8.1.案例背景在国际贸易中，合作客户及供应链合作伙伴信用风险是一个重要的考虑因素。由于交易双方可能存在信息不对称、资金链断裂等问题，导致交易无法按时完成或出现违约情况，应收账款违约损失常年高于 5%；信用交易订单的处理时效低于行业平均水平，也导致公司损失大量业务，限制了业务规模的增长。该大型贸易公司前期希望通过一系列海外报告来监控和管理其海外客户及供应链之间的信用违约风险，以便及时采取措施减少损失，同时为业务规模增长提供支持。4.8.2.技术方案在该案例中海外用户信用风险评估报告,是中诚信征信通过收集和整合来自不同渠道的数据，包括海外供应商和海外客户的信用评级、财务状况、经营活动、诉讼负债等数据，以及中诚信征信基于近 20 年在企业信用风险评估领域积累沉淀的风险评估维度和指标，最终生成满足客户需求的各种类型的海外信用报告，提出风险分析观点和风险评级结果；帮助用户识别其海外客户潜在信用风险，并生成相应的预警信号,方便用户监控海外客户及供应商信用风险状况并进行决策。图 14 为用户信用风险评估报告的处理系统的作业流程示意图，实际以落地系统为准。79图14 用户信用风险评估报告处理系统作业流程示意图（1）技术特点技术特点1)数据收集和整合：系统基于 CCX 编码进行数据的深度关联和检索，从多个渠道获取相关数据，包括公共数据、企业财务报告、社交媒体、生产经营等。2)机器学习算法：系统使用监督学习和无监督学习算法对数据进行分析和建模，以识别潜在的信用风险。3)知识图谱：系统通过知识图谱和 NLP 算法，挖掘各主体之间的各类关联关系，通过各类关系及关联方的串联识别与展示，排查多维度风险事件，防止风险蔓延。4)分析和评价结果可视化：系统将模型结果用可视化图表的形式展现，使用户能够快速了解信用风险状况，并做出相应决策。（2）技术架构技术架构该系统采用分布式架构，包括数据采集模块、数据处理模块、模型训练模块、风险预警模块和可视化展示模块等。各个模块之间通过 API 进行数据交换和通信。（3）工作工作/业务流程业务流程1)数据采集：系统从不同渠道收集相关数据，包括客户的信用评级、历史交易、财务状况、工商信息、司法信息、生产经营数据等。2)数据处理：系统对采集到的数据进行清洗、转换和整合，以便后续分析处理。3)模型训练：系统利用机器学习算法对数据进行训练和建模，以识别潜在80的信用风险。4)风险预警：系统根据模型的结果生成相应的预警信号，提醒用户注意潜在的信用风险。5)决策支持：用户可以查看风险评分结果，了解信用风险状况，并根据建议额度和自身需要进行相应决策。4.8.3.方案创新点和亮点该系统通过人工智能技术和大数据分析技术，搭建企业评级模型和风险监测模型。能够帮助贸易类进出口公司筛选优质的客户，实时监测和管理与客户之间的信用风险，及时发现潜在问题并采取相应措施，从而降低违约风险和损失。同时，系统提供的可视化图表使用户能够直观地了解信用风险状况，并做到决策流程和审批流程留痕，支持科学决策。4.8.4.应用效果该案例中海外用户信用风险评估报告,在该公司正式使用后取得了显著的应用成效。图 15 为报告模板示意图，实际报告以落地为准。图 15 征信报告模板示意图81（1）风险筛查，提高客户质量风险筛查，提高客户质量通过海外用户信用风险评估报告，快速完成海外客户及供应商的筛选，精准识别优质客户及供应商，极大提高准入筛选效率，提升了对其质量的判断能力，不仅从事前就降低了客户及供应商的信用违约风险，而且使业务规模提高 200%。（2）科学审批，提高效率和准确性科学审批，提高效率和准确性该公司业务审批决策流中融入海外用户信用风险评估报告，帮助补足该公司海外客户及供应商信用风险评估数据空缺，使其单位时间内的订单审批数量提高了 150%，审批效率提高 100%，决策更有科学依据。（3）动态监测，提高风险处置效率动态监测，提高风险处置效率通过对客户信用风险的定期监测和管理，该公司成功降低了违约风险和损失。（4）风险可视化，提高风险感知风险可视化，提高风险感知海外用户信用风险评估报告内，针对海外客户及供应商信用风险情况，内置多款的可视化图表和风险评估数据，使决策链各环节,能够更好地了解海外各客户及供应链合作伙伴信用风险状况，并及时做出决策。4.9.健康医疗：临床试验数据跨境合规在全球医疗创新和数字化高度发展背景下，健康医疗数据的跨境流动需求日益增多。在临床研究中，有时需要通过国内外高水平的多个医学中心合作研究和跨境数据对比分析，研究某种新技术或者新疗法的疗效。医疗机构基于临床研究跨境合作需求，开展数据出境安全评估申报，并成功获得审批，由此，该国际多中心临床研究项目成为数据合规出境示范案例。本案例介绍信联科技作为此项目的支撑单位，通过优质的数据出境咨询服务，协助医疗机构实现数据跨境合规。4.9.1.案例背景（1）法律层面难点法律层面难点根据数据出境安全评估办法第五条规定，开展数据出境风险自评估，应重点评估以下事项：1)数据出境和境外接收方处理数据的目的、范围、方式等的合法性、正当性、必要性；2)出境数据的规模、范围、种类、敏感程度，数据出境可能对国家安全、公共利益、个人或者组织合法权益带来的风险；3)境外接收方承诺承担的责任义务，以及履行责任义务的管理和技术措施、82能力等能否保障出境数据的安全；4)数据出境中和出境后遭到篡改、破坏、泄露、丢失、转移或者被非法获取、非法利用等的风险，个人信息权益维护的渠道是否通畅等；5)与境外接收方拟订立的数据出境相关合同或者其他具有法律效力的文件等（以下统称法律文件）是否充分约定了数据安全保护责任义务；6)其他可能影响数据出境安全的事项；以上评估事项涵盖临床研究、法律和数据安全等多种维度的合规性，评估报告涉及专业方向多而广，数据出境自评估难度较大。（2）业务层面难点业务层面难点健康医疗数据在跨境合规的评估过程中，医疗出境数据种类繁多，涵盖了病人的病历、诊断结果、治疗方案、药品信息等敏感信息，同时也包括了医生的学术研究、医疗系统的运营数据等重要信息。这些数据的梳理面临诸多困难，如数据量大、处理复杂度高、涉及的隐私和安全问题多等，因此需要专业的第三方数据跨境服务机构协医疗机构开展数据跨境合规建设。4.9.2.合规方案（1）数据出境安全评估具体流程数据出境安全评估具体流程依据数据出境安全评估申报指南（第一版），相关医疗数据出境评估流程如下图所示：图 16 数据出境安全评估流程（2）自评估工作流程自评估工作流程本次自评估咨询服务分为五个阶段：确定评估范围、制定评估计划、收集评估信息、开展评估工作和形成评估报告。83图 17 自评估流程图各阶段的实施过程说明如下：1)确定评估范围：首先，需要明确数据出境的范围和内容，确定需要进行安全评估的出境活动和数据类型。2)制定评估计划：根据确定的评估范围，制定详细的评估计划，包括评估时间、评估人员、评估方法等。3)收集评估信息：收集与数据出境相关的信息，包括出境活动的具体情况、数据类型、数据量、数据用途、数据安全措施等。4)开展评估工作：根据制定的评估计划，开展评估工作，对数据出境的安全性进行评估。需要评估数据出境活动是否符合法律法规的要求，是否采取了必要的措施来保护数据安全。5)形成评估报告：在评估工作结束后，形成评估报告，包括评估结果、评估结论、建议等。需要明确指出数据出境活动存在的问题和不足，并提出改进建议。4.9.3.方案创新点和亮点信联科技在数据资产梳理、数据安全保障能力评估、数据安全体系建设等方面对医疗机构（数据处理者）进行深入评估并设计相关整改方案。（1）在出境数据层面在出境数据层面，信联科技通过盘点医疗机构数据资产，梳理出境临床医疗数据的规模、范围、种类、敏感程度，识别出境数据中是否包含敏感个人信息或重要数据，是否存在不必要的出境数据等。针对出境数据风险，引导医疗机构筛除不必要的数据出境字段，对敏感个人信息和重要数据采取脱敏、去标识等必要的技术手段，以降低出境数据可能对国家安全、公共利益、个人或者组织合法权益带来的风险。（2）在业务层面在业务层面，信联科技协助医疗机构梳理业务流程，识别其是否与当前国家法律法规要求、行业主管部门规定和国家标准建议等存在差距。针对业务合规性风险，引导医疗机构在业务流程中增加数据出境合法性确认环节，例如向个人告知境外接收方的名称或者姓名、联系方式、处理目的、处理方式、个人信84息的种类以及个人向境外接收方行使本法规定权利的方式和程序等事项，并取得个人的单独同意。（3）在数据安全体在数据安全体系方面系方面，信联科技通过人员访谈、查验安全管理制度，识别医疗机构是否明确数据安全管理机构、设立数据安全负责人、建立数据安全管理制度体系、落实管理监督考核机制等。针对数据安全风险，建议医疗机构建立或完善数据安全管理组织架构，设立数据安全负责人等关键岗位，健全数据处理活动全流程、数据分类分级、应急处置、个人信息权益保护等管理制度，并建立数据安全技术保障机制，搭建数据出境风险防控体系。4.9.4.应用效果（1）强化数据跨境制度保障强化数据跨境制度保障，信联科技协助医疗机构全面建立包括但不限于明确数据跨境传输管理机制，建立数据跨境合规评估制度与流程，建立出境数据分级分类目录及重要数据目录，提升医疗机构数据跨境安全保障能力。（2）培育数据跨境合规理念培育数据跨境合规理念，以数据跨境法规为指引，推动医疗机构树立全面数据跨境合规理念，纳入机构数据治理的宏观策略管理，实现与机构高层领导、业务管理、骨干员工达成数据跨境业务合规共识。（3）赋能赋能健康健康医疗跨境合作医疗跨境合作，本次成功案例为强化医疗健康数据出境安全管理、促进国际医疗研究合作提供了参考示范和实践指引，推动医学的进步并造福于患者，为提升全人类生命健康水平作出贡献。4.10.跨境贸易：基于区块链的两岸跨境贸易商品溯源系统为促进两岸经贸文化交流深度融合，中共中央国务院和福建省政府出台了一系列政策措施，包括支持两岸企业在数字经济领域开展合作、推进数字基础设施建设、促进数字经济与实体经济深度融合等。两岸跨境贸易商品溯源应用以促进两岸数字经济融合发展为目标，厦门海峡链科技有限公司，与两岸企业携手合作，运用区块链、IPFS 分布式存储、去中心验证器等技术，构建了两岸跨境贸易商品溯源系统，助力两岸贸易合作、商品数据协同，促进两岸数字经济融合发展。4.10.1.案例背景根据海关总署的统计数据，2022 年 1 至 11 月，两岸贸易总额已达到 2943.9亿美元。随着两岸产业合作的不断深化，产业链供应链基本稳固，越来越多的商品需要在海峡两岸之间进行跨境贸易，跨境贸易需求逐年稳步增长。然而，由于两岸在政策、基础设施、行业标准、技术规范等方面存在差异，导致了数据孤岛85效应，这极大限制了两岸商品数据的跨境流通和应用，严重阻碍了两岸实体经济和数字经济的融合发展。因此，两岸企业之间迫切需要一套低成本且可信赖、多方协同的跨境贸易商品数据流通方案。这套方案需要在确保商品数据的安全性和防止篡改的前提下，高效地进行商品数据协同与应用，从而加速两岸数字经济的融合发展。4.10.2.技术方案（1）解决方案思路解决方案思路海峡链为两岸跨境贸易商品溯源应用提供了关键的技术支持，包括区块链底层平台、IPFS 分布式存储以及 SC-DValidator 去中心验证器等。这些技术的应用在很大程度上保障了贸易商品数据的安全性和共享效率。区块链技术的分布式、公开透明和防篡改特性为应用提供了坚实的基础。同时，IPFS 分布式存储基于内容的快速寻址和数据永久保存等特性，进一步增强了数据的可靠性和安全性。在两岸跨境贸易商品溯源应用的设计中，充分考虑了数据的采集、存储、验证和共享等各个环节的需求，结合区块链、物联网以及数字签名技术，对贸易商品数据进行采集、加密、上链、存证，实现安全高效的数据确权、验证和共享。通过引入去中心验证器和 IPFS 分布式存储等关键技术，应用实现了第三方系统数据的快速核验上链和分布式加密存储，从而进一步保障了贸易商品数据的安全性和可靠性。（2）系统框架与功能模块系统框架与功能模块两岸跨境贸易商品溯源应用基于区块链、IPFS 分布式存储、去中心验证器等技术构建，并结合了物联网、第三方物流系统和供应链系统。如图 18 所示，应用分为四层架构，从下到上依次是区块链层、服务层、物理层以及应用层。1)区块链层：整个系统的基础，为数据提供安全保障，确保数据的不可篡改和透明性。其中包括 P2P 网络、共识算法、智能合约、数字签名、IPFS 去中心化存储、分布式身份标识、去中心验证器等海峡链基础设施。2)服务层：连接区块链层和物理层，负责管理和操作数据，确保数据的准确性和实用性。提供从品牌到商品的精细化溯源管理服务，包括品牌商管理、信息上链管理、溯源查询、溯源统计、溯源码管理、产品管理等。3)物理层：配合应用层，结合物联网技术和物理设备，进行数据采集和数据协同。支持一物一码锚点商品，提供多标识（如条形码、二维码、RFID、NFC芯片）的全生命周期管理，包括规则配置、标识生成、查询标识、下载标识。86图 18 两岸跨境贸易商品溯源应用技术架构图4)应用层：是最接近用户的层级，主要负责数据的展示和交互，为各个应用提供数据支持。支持通过 API 接入第三方物流系统、PAD 或扫码设备的数据，可在小程序、H5、Web 多端展示商品溯源信息、客群分布热力图、扫码统计等功能。在跨境贸易业务流程中，涉及到多角色和多场景的数据协同。两岸跨境贸易商品溯源应用以区块链和 IPFS 去中心化存储技术为架构基础，确保跨境贸易业务流程中数据协同的高效、稳定和真实性。同时，支持产品从生产制造到终端销售的全流程信息记录上链，并通过微信小程序或区块链浏览器，让消费者快速查验商品。两岸跨境贸易商农品溯源应用数据上链流程如图 19 所示。图 19 两岸跨境贸易商农品溯源应用数据上链流程图 20 是台湾某有机茶厂的祈韵红茶的数据采集示例：茶园物联网设备实时采集茶叶生长环境数据，如气温、湿度、土壤 PH 值和虫情，并通过 IPFS 进行分布式存储，上链确保数据真实可追溯。平台利用区块链 NFT 作为凭证，每罐87茶叶产品都铸有专属溯源码。全链路数据上链保证了商品信息的真实和可信，实现了茶产量和商标用量的数字化精细管理，从而全面提升茶产品质量。图 21 展示了两岸跨境贸易商品溯源应用案例。图 20 两岸跨境贸易商品溯源应用数据采集示例图 21 两岸跨境贸易商品溯源应用案例884.10.3.方案创新点和亮点两岸跨境贸易商品溯源应用具备以下显著特点和创新：（1 1）数据透明可溯源数据透明可溯源：区块链的共识机制和链式结构，确保数据的透明和可溯源。（2 2）数据安全防篡改数据安全防篡改：利用区块链的不可篡改特性，结合 IPFS 去中心化存储技术，保障了数据的安全且不可篡改。（3 3）商品唯一可信商品唯一可信：每件商品都通过“一物一码”的方式进行标识，全流程信息被记录上链，确保商品从生产到销售每一个环节的唯一性和可信度。（4 4）数字签名确权数字签名确权：在信息上链的过程中，每一个环节的参与主体都对所负责的环节的上链数据进行签名，确保信息的真实性，不可抵赖和可追溯。（5 5）数据高效协同数据高效协同：贸易商品全流程信息上链，确保数据的公开透明和高效协同，解决了多方参与、信息碎片化和重复审核等问题，这大幅降低了沟通和审核成本，提升了跨境贸易的整体效率。4.10.4.应用效果两岸跨境贸易商品溯源应用已经记录多家台湾企业的商品数据信息，涵盖农业、工业、制造业等多个领域，为两岸企业在商品溯源、跨境电商等场景提供服务。通过扫描溯源码，消费者能够查看产品的真实信息，有效降低购买假货风险。应用运营的台湾企业负责人之一在接受大陆媒体采访时表示：通过两岸跨境贸易商品溯源应用，将产品信息和相关证书记录上链，从而方便客户随时查询和验证商品，提高了品牌信用和价值。两岸跨境贸易商品溯源应用是跨境数据流通的一次全新探索和尝试，其充分发挥区块链技术的优势，解决两岸商品数据孤岛问题，为两岸贸易企业创建高质量的贸易商品数据协同平台。4.11.跨境电商：跨境数据推动电商企业 ESG 供应链改进九鑫智能专注于为跨境电商卖家提供数据管理、决策辅助和智能自动化等技术手段，帮助他们应对存量竞争激烈和增量天花板的挑战。目前跨境卖家面临着建立核心竞争壁垒和与低价竞争企业抗衡的问题。本案例客户应用九鑫智能行业ESG AI 模型实现 ESG 目标的持续评估和核心指标监测，通过对全球供应链数据的分析和优化帮助跨境电商卖家大幅降低未销库存比，并引入客户全球市场销售数据跨境，整合历史和目标市场数据，利用行业 AI 模型进行分析和模拟，快速重构业务流程，抓住以价值观为导向的消费群体的新增量机会，实现可持续发展。89图 22 方案功能展示图4.11.1.案例背景（1）行业现状行业现状中国跨境电商卖家面临着存量竞争激烈和增量天花板的现实问题。一方面，低价内卷策略下的企业通过迎合全球经济下行趋势和消费者对折扣的追求，成为低价市场的领导者。另一方面，中国跨境电商卖家面临欧美等市场需求减缓的巨大挑战。在这种极端竞争下，这些卖家的生产发展空间持续受到压缩。因此企业需要寻求新增量，升级自身的核心竞争壁垒，以应对激烈竞争的局面。（2）业务挑战业务挑战1)产品多渠道出海，从“产品第一”到“多渠道出海”需要面对跨境电商的挑战。2)在不同国家和地区经营跨境电商需要遵守各自的数据、财务、税务和法律法规。确保数据合规和本土合规是一个复杂的任务。3)在可持续发展的背景下，企业需要承担社会责任。在跨境电商中，公司需要确保供应链的可持续性和社会责任的落实。4)跨境电商的快速发展可能会对环境造成负面影响，绿色生产和环境友好成为必须关注的问题，需要采取措施减少环境影响。（3）应用场景与需求应用场景与需求在不进行重构的前提下，面向后续业务变化、需要灵活调整流程和功能的场景下，客户希望实现以下需求：1)可持续供应链管理可持续供应链管理：通过全域数据和跨境数据流通，建立透明、可追溯90的供应链系统，以减少资源浪费和环境污染为目标。2)基于基于 AI 和数据驱动的产品设计和数据驱动的产品设计：与全球设计师合作，利用 AI 和数据分析预测市场需求，实现按需生产，从而降低成本和库存浪费，并减少侵权事件的发生。3)促进可持续消费和经济增长促进可持续消费和经济增长：通过降低生产成本，将成本优势回馈给全球消费者，促进负担得起的可持续消费。通过可持续转型创造就业机会，与当地消费市场融合并贡献经济增长。4.11.2.技术方案本案例技术方案思路以客户可以实现全域数据驱动的可持续发展，快速提高ESG 供应链相关评分为目标，采用了统分结合的灵活部署方式，实现数据来源授权可获取、数据分析过程可管理，以及数据执行结果和传输可记录的目标。（1）数据整合与数据整合与共享共享：建立一个统一的数据平台，整合全球供应链和业务部门的数据，实现数据的实时共享与更新。采用安全加密和身份验证机制，确保数据来源的授权获取。（2）AI 驱动的预测与优化驱动的预测与优化：建立企业 AI 模型，利用九鑫行业 AI 模型和数据分析技术对全球供应链和业务部门的数据进行实时分析和预测。通过预测市场需求、优化生产计划和库存管理，实现供应链的及时性优化。（3）按需生产模式按需生产模式：基于 AI 预测和需求信号，实现按需生产模式，减少过剩库存和资源浪费。通过实时数据分析和供应链协同，优化生产计划，提高生产效率和供应链的可持续性。（4）减少产品设计侵权事件减少产品设计侵权事件：对设计师方案内容进行内部审查，减少产品设计侵权事件风险。后继可结合区块链技术，提升知识产权保护，促进全球设计师的合作与创新。（5）供应链）供应链数据共享与协作数据共享与协作：建立实时数据共享平台，通过协作工具和沟通平台，促进企业内部和供应链合作伙伴之间的高效沟通和协作。实时数据共享和协作能够提高工作效率，优化供应链的整体协同性。（6）促进可持续消费和经济增长促进可持续消费和经济增长：为一些地区建立生产基地，为当地创造就业机会匹配市场扩张需求的项目提供生产成本可控，当地负担得起的可持续消费选择，提供可持续消费分析数据，在获取市场增长同时做好 ESG 专项评估和分析预测。914.11.3.方案创新点和亮点（1）数据整合与实时共享数据整合与实时共享通过建立统一的数据平台，整合全球供应链和业务部门的数据，并实现实时的数据共享与更新。这一特点使得企业能够获得准确、全面的数据，同时能够及时了解市场变化并做出相应的决策。（2）提高数据及时性提高数据及时性数据能够迅速在全球供应链和业务部门之间流动，实时更新和共享。这种实时性的数据流动使得企业能够更快地获取最新的市场信息和需求变化，从而能够更快地做出决策和调整策略。（3）快速响应市场变化快速响应市场变化由于数据平台的建立和连接可用技术提升数据的实时性，企业能够更快速地响应市场变化。这种快速响应能力为企业带来了竞争优势，提高了市场反应速度和决策的准确性。通过跨境数据流通实现企业内部全域数据流动互通，使得数据分析及时有效显著提升，让企业能够更好地应对市场挑战和需求变化。全域数据平台达到供应链协作支撑要求，保障在既定时间实现供应链 ESG 可持续发展的目标和具体指标。4.11.4.应用效果跨境电商在供应链 ESG 挑战中，可通过跨境数据快速实现数据整合与实时共享、及时响应市场变化，基于数据的准确分析和有效预测可大幅降低消耗对提高供应链ESG 评分至关重要，并且有机会通过更好的 ESG 表现获取新增量市场。本案例以下输出成果可以为行业应用提供参考：（1）数据整合与实时共享数据整合与实时共享：通过统一数据平台整合全球供应链和业务部门的数据，并实现实时的数据共享与更新。通过提高供应链数据的准确性和可靠性，预计可提高供应链 ESG 评分约 10%。（2）快速响应市场变化快速响应市场变化：通过准确的数据和实时的信息，该企业能够更快速地响应市场变化，能够更及时地调整供应链和生产计划，提高供应链效率约12%。（3）可持续发展可持续发展：通过分析提供可持续消费选择、提供促进可持续消费计划。预计可持续发展措施将提高整体 ESG 评分约 10%。924.12.数据合规：企业数据出境风险评估A 为中国境内外资企业，向境外 B 企业提供产品和服务，A 企业向 B 企业交付产品和服务同时通过系统提供 A 企业在中国境内运营和收集的相关数据。广东卓建律师事务所受委托评估 A 企业长期存在的数据出境活动是否合规，以及是否应当立即向网信部门申报数据出境安全评估备案需要从法律方面进行评估，以防范未履行法定义务的法律风险。4.12.1.案例背景根据我国数据安全法个人信息保护法数据出境安全评估办法规定，关键信息基础设施的运营者需要进行数据出境的应通过安全评估，数据处理者确需向中国境外提供个人信息的，需满足法定条件，数据处理者进行数据出境应履行法律规定的义务,出境数量达到法定标准还需通过所在地省级网信部门向国家网信部门申报数据出境安全评估,在申报出境安全评估之前应先进行数据出境风险自评估等。数据出境安全评估办法明确规定，在 2022 年 9 月 1日起前已经开展的数据出境活动，不符合规定的，应当在 6 个月内完成整改，否则应承担相应法律责任。4.12.2.合规评估（1）聚焦问题及分析思路聚焦问题及分析思路问题问题 1：A 企业在数据出境活动中的具体法定义务有哪些？企业在数据出境活动中的具体法定义务有哪些？个人信息保护法第五十五条的规定，向境外提供个人信息的，应当进行个人信息保护影响评估。通过梳理企业的业务流和数据流，A 企业向境外提供的数据包含个人信息，因此，A 企业应当先就个人信息出境事宜进行个人信息保护影响评估。数据出境安全评估办法第五条的规定，在申报数据出境安全评估之前，应先进行数据出境风险自评估，自评估应当对包括数据出境的合法性、正当性、必要性等内容进行评估，并制作数据出境风险自评估报告，作为申报数据出境安全评估的材料之一提交。个人信息保护法第三十八条，个人信息处理者因业务等需要，确需向中华人民共和国境外提供个人信息的，应当具备下列条件之一：（三）按照国家网信部门制定的标准合同与境外接收方订立合同，约定双方的权利和义务；数据出境安全评估办法第六条，申报数据出境安全评估应提交申报书、自评估报告、与境外接收方拟订立的法律文件、安全评估工作需要的其他材料。根据数据出境安全评估办法第八条的规定，A 企业与境外接收方签订的相应法律文件93应明确约定双方的数据安全保护责任及义务，确保出境数据的安全以及个人信息权益能够得到充分保障等。因此，除了自评估报告之外，A 企业还需要与境外接收方订立网信部门制定的标准合同和相应的法律文件。个人信息保护法第三十九条的规定，如需向中华人民共和国境外提供个人信息的，应当向个人告知境外接收方的名称或者姓名、联系方式、处理目的、处理方式、个人信息的种类以及个人向境外接收方行使本法规定权利的方式和程序等事项，并取得个人的同意。因此，针对个人信息出境的情况，A 公司应当采取适当的方式告知相关个人，并取得其同意。数据处理者数据安全保障能力包括数据安全管理能力、数据安全技术能力、数据安全保障措施有效性以及其他应当遵守数据和网络安全相关法律法规的有情况等。因此，对 A 企业与境外接收方 B 企业的数据安全保障能力需要通过尽调评估和技术测评等手段进行风险排查，以及对于不合规事项应提前予以整改。问题问题 2：A 企业主体资格企业主体资格、出境数据类型出境数据类型、数量以及敏感程度是否达到法定数量以及敏感程度是否达到法定申报评估备案的条件？申报评估备案的条件？通过 A 企业提交的材料、访谈、会议等方式调查了解，A 企业不涉及公共通信和信息服务、能源、交通、水利、金融、公共服务、电子政务、国防科技工业等重要行业和领域，未被认定关键基础设施运营者，出境数据类型未列入重要数据白名单，但属于自上年 1 月 1 日起累计向境外提供 10 万人个人信息的数据处理者。结合数据安全评估办法规定，A 企业应当进行申报备案。问题问题 3：A 企业未申报数据出境安评估的法律责任有哪些？企业未申报数据出境安评估的法律责任有哪些？根据数据出境安全评估办法第十八条、第二十条和个人信息保护法第六十六条的规定，对于已经开展的数据出境活动，应当在数据出境安全评估办法施行之日（即 2022 年 9 月 1 日）起 6 个月内完成整改；同时，违反数据出境安全评估办法对于应当向网信办申报数据出境安全评估但未申报的，可能面临责令改正、警告，拒不改正的，并处一百万以下的罚款，直接负责的主管人员或其他直接责任人员则可能被处一万元以上十万元以下罚款。如果被认定为情节严重的，可能面临责令改正、没收违法所得，并处五千万元以下或者上一年度营业额百分之五以下罚款，暂停相关业务或者停业整顿、吊销相关业务许可或者吊销营业执照；直接负责的主管人员和其他直接责任人员则可能被处以十万元以上一百万元以下罚款，并可能被禁止在一定期限内担任相关企业的董事、监事、高级管理人员和个人信息保护负责人。（2）结论结论A 企业应当对现有的数据出境活动进行全面的风险识别，开展相关评估和申报备案工作，否则直接面临如上所述相关法律责任。具体工作包括但不限于按照94法律规定进行个人信息保护影响评估以及数据出境安全自评估工作，评估内容包括数据出境及境外接收方数据处理的合法性、正当性、必要性、出境可能对国家安全、公共利益、个人或组织合法权益代来的风险等法律规定的内容；另外，还需要准备与境外接收方签订网信部门制定的标准合同和相关法律性文件；依法提交申报书等安全评估工作需要的其他材料等。4.12.3.方案创新点和亮点数据出境安全评估办法 规定了企业的数据出境活动应向监管部门进行申报的条件、提交材料、评估要点、报备流程、备案单位等，且有时限的要求。如果企业不经专项评估直接进行申报，必然造成人力、资金、时间等成本支出，企业的日常运营也会有一定影响，如果不申报，又会直接导致承担高额处罚和相关责任，对企业经济、声誉均会带来重大损失。因此，对于企业是否应当启动评估申报备案程序、何时启动显得非常重要。本专项风险评估需要投入的工作时间、人力资源、经济支出以及对业务的影响程度，相较正式的申报评估工作具有周期短、成本低的特点，如本团队在其他项目中也评估出有的企业不需要向监管部门申报备案，则可以通过认证、自评估报告、标准合同等方式达到监管对数据出境的要求，大大节省了企业的各项成本。因此，通过专业法律分析，及时解决法律施行后对企业影响的不确定性，帮助企业在合规的情形下继续开展数据出境活动。4.12.4.结语建议数据合规是企业行稳致远的基础，数据跨境的违规成本较其他情形的违规成本来说较大，因此，企业提前开展是否需要申报的风险评估，对于企业控制成本与风险具有非常重要的作用，也是充分发挥数据合规律师专业水平，提升企业的合规意识，促进企业高质量发展。95第五章 数据跨境流通与技术应用发展建议目前我国以国家安全法网络安全法数据安全法个人信息保护法和密码法等法律法规为框架，国务院、国家网信办、发改委、工信部、公安部、安全部、财政部等单位相继出台了关键信息基础设施安全保护条例商用密码管理条例网络数据管理条例（征求意见稿）网络安全审查办法数据出境安全评估办法个人信息出境标准合同办法数据出境安全评估申报指南（第一版）和规范和促进数据跨境流动规定（征求意见稿）等配套规范性文件，初步建立了数据保护与数据跨境流动管理体系，为我国企业规范数据跨境处理活动、监管单位审查和监督数据跨境处理活动提供了法律依据。数据跨境除了法律上的合规管理的保障，同时也需要在技术上维护安全可信环境，国家鼓励和支持开展数据流通相关安全技术研发和服务，目前广泛使用的技术包括但不限于区块链、联邦学习、安全多方计算等。我国现阶段存在市场主体对数据跨境评估审批认知不一、供应链风险控制与管理难、技术与标准难适应、合规人才严重不足、缺乏安全有效的流通模式等问题，既阻碍了数据跨境的安全有序流通，也影响了企业的数据安全能力建设和跨境业务的发展。现结合法律法规的现状和部分企业积极探索的实践经验，开展如下探讨并提出相关建议。5.1.数据跨境安全管理底线坚持与便利化探索为了保障数据跨境流通过程中的合法合规，同时提升数据合规出境的效率，建议可以补充以下方式辅助现有数据出境管理体系：（1）企业在向管理部门报送相关材料时，可附上由独立第三方专业机构出企业在向管理部门报送相关材料时，可附上由独立第三方专业机构出具具“安全评估风险意见安全评估风险意见”在目前的数据出境安全管理框架中，向主管机关申报数据出境安全评估时，数据处理者除了提供“数据出境风险自评估报告”之外，可事先委托独立第三方专业机构进行合规、安全和风险的评估，并出具无保留意见的“意见书”，以独立第三方专业机构的专业资质、实践经验及技术能力等为担保，增加监管对申报企业的信心，以期加快审批流程。（2）通过拟出境数据自愿预备案通过拟出境数据自愿预备案模式模式，为企业提供数据出境合规缓冲区，为企业提供数据出境合规缓冲区允许企业根据国家网信办发布的数据出境相关规定，结合实际情况，参照“互联网服务算法”等预备案制度，在正式申请数据出境安全评估前自愿向有关部门申请预备案，待正式申报数据出境安全评估时，可相应简化具体审核的内容和流96程，提高数据出境安全评估行政审核效率。预备案的主要内容可以包括企业基本情况，境外接收方基本情况，出境情况，如数据出境的目的、范围、方式等，出境数据情况，如数据的种类、来源、规模、范围、敏感程度等。预备案模式，不仅有助于国家网信部门事先对拟出境企业数据跨境处理活动的进行合规指导，也有助于提升企业后续申报过程中材料准备的效率。（3）根据申报业务场景和数据安全程度，根据申报业务场景和数据安全程度，分级分级分类设置数据出境安全评估分类设置数据出境安全评估行政审核流程，节约审批时间行政审核流程，节约审批时间根据企业申请数据出境的数据种类、来源、规模、范围、敏感程度、潜在风险，数据出境的目的、范围、方式等，可以在流程的繁简程度、审批的时间长短等方面归类处理。如针对数据类型少、敏感程度低、数据量小等数据出境活动，可以适当减化审批环节和时间；或根据数据所涉行业、用途、特点、应用领域等进行分类，适用不同的审查程序等，既帮助企业解决业务的现实合规性，又极大提高审核质量和效率。因此，建议以粤港澳大湾区为试点，在实践中探索建立数据出境监管的新模式、新方法、新手段。5.2.企业全面建成数据跨境合规体系5.2.1.企业数据安全与隐私保护涉及跨境业务的企业应当依法建立数据出境安全评估和风险监测机制，以保护个人数据、敏感数据、重要数据的跨境流动安全，保证数据出境的合规性、正当性以及必要性。建议企业构建以跨境数据资产盘点与风险识别、跨境数据安全风险监测与预警、跨境数据响应处置与数据留档为核心的跨境数据安全技术体系架构。图 23 企业跨境数据安全技术体系架构图（1）以跨境数据以跨境数据资产盘点与风险识别完善为首要资产盘点与风险识别完善为首要企业可通过跨境数据资产探测探针等工具主动探测跨境应用、FTP、各种邮件服务、文库等数据资产，梳理各类跨境数据资产的数据资产类型、跨境方式、跨境区域、跨境组织、跨境组织联系人、跨境组织地址等相关信息，并对这些资97产进行多维度管理，用于辅助企业判断数据跨境合规性；针对跨境数据敏感程度、安全防护措施、企业安全保障能力等多方面按照实际情况判断是否需要依法向国家网信办申报数据出境安全评估。（2）以跨境数据安全风险监测与预警实效为以跨境数据安全风险监测与预警实效为核心核心通过跨境数据风险监测分析引擎，对数据资产探针所采集的各类原始告警，以及各类专项检测引擎输出的告警，进行跨境数据初步关联分析，采取可信技术进行监控和存储，进而输出准确程度更高、更加多方可信的跨境数据安全告警信息。因跨境数据安全分析工作往往是动态的、多变的，需要基于各类实际应用场景灵活调整关联分析策略，以便更有效地应对跨境数据安全监管合规要求，跨境数据风险监测分析引擎类型包括合规性符合风险分析引擎、跨境数据资产脆弱性及弱点分析引擎等。（3）以跨境数据响应处置与数据留档夯实为基础以跨境数据响应处置与数据留档夯实为基础针对跨境数据安全风险监测并预警的风险，跨境数据安全运营专员结合企业自身业务发展情况，制定的安全风险等级和前期制定好的应急预案做通报与处置，相关责任部门根据安全风险预警通报情况制定合理的跨境数据安全治理方案并做相应整改，整个过程数据通过区块链等多方可信技术，全部留档，便于跟踪和安全追溯。5.2.2.企业供应链风险控制与管理供应链合规对于企业顺利安全地开展数据出境业务有重要意义。供应链风险具有关联性，传递性、复杂性和“牛鞭效应”，企业要在国内合规数据的基础上根据国家关于数据出境的相关法律法规的要求评估自身数据处理情况，按照规定流程进行数据出境，最终保障跨境数据的全流程合规。为了加强企业供应链风险评估和监控，保证数据链的畅通和完整，建议可以从以下路径改进供应链合规管理模式的实施。（1）企业应建立供应商审核和评估机制，确保潜在供应商的合规性和可靠企业应建立供应商审核和评估机制，确保潜在供应商的合规性和可靠性。性。企业针对与外部供应商的数据流动合作事宜，按照数据安全能力成熟度指南标准，根据自身已达到的标准，对外部供应商的对应能力进行评估，确认供应商在数据安全生命周期过程中可达到的数据安全能力成熟度，不低于企业自身已达到的或数据流动过程中需要达到的最低等级要求，实现对供应商的安全要求选型，降低供应商的数据安全隐患导致的数据泄露或损失。98（2）企业通过可追溯性系统对供应链进行动态合规管理和监督。企业通过可追溯性系统对供应链进行动态合规管理和监督。企业应采用信息技术工具和评估系统，加强对供应链合规情况的监控和跟踪。供应链可追溯性是指企业能够追踪和掌握供应链中产品或服务的来源、流向等信息。通过建立可追溯性系统，企业可以更好地监控供应链的合规性，及时发现和解决潜在的违规问题，并对供应商进行及时的提醒和整改。（3）企业跟进最新法律法规和行业监管动态，及时调整供应链合规管理机企业跟进最新法律法规和行业监管动态，及时调整供应链合规管理机制。制。企业根据自身多样化业务场景及流程，对不同类型的供应商开展事前、事中、事后的全面合规风险评估和整改。同时，还应深入解读和实时掌握自身所处行业相关的法律法规、规范、监管要求、查处案例等，设置“合规红线”，将合规操作要求有机嵌入供应链合规管理或指导办法中。此外，企业还应与监管机构保持良好的沟通合作关系,了解最新政策动向,及时调整内部合规规程。（4）企业与国际合作伙伴和第三方服务商建立长效合作机制。企业与国际合作伙伴和第三方服务商建立长效合作机制。企业需加强与政府、行业协会、合作企业、组织和个人等的沟通与合作，共同推动跨境数据流通合规的国际标准制定和协作机制建立。明确合作目标和原则、评估合作伙伴和第三方服务商的合规能力、签订权利义务明确的合同或条款、建立沟通渠道和协作机制、加强合规培训和教育、制定应急预案、定期审计和风险评估等，以确保跨境数据流通合规和安全得到有效保障。建议与外部专业的数据安全机构、咨询公司、律师事务所等合作，共同提升数据安全和合规能力。此外，在跨境数据流通过程中，企业与第三方进行数据共享时，可通过制定行业规则、建立合作机制、签订数据共享协议等方式，明确数据的使用范围和使用方式、各方在数据合规方面的职责与义务等，实现用户数据的跨平台流通和使用。合作期间，还应不定期对外部服务提供商的安全管理水平和措施进行监督和风险评估，保障供应链管理的有效性。5.2.3.企业跨境数据流通合规能力建设在满足日益增长的数据跨境流通需求的同时确保数据安全和合规、建立健全的跨境数据流通合规管理体系，已成为各国政府和企业共同面临的挑战。作为一个关键性的任务，跨境数据流通合规能力建设涉及到数据安全、隐私保护、合规义务等多方面的问题。（1）在战略层面重视跨境数据流通合规能力建设，充分了解并遵守目的国在战略层面重视跨境数据流通合规能力建设，充分了解并遵守目的国家和地区相关法律法规。家和地区相关法律法规。企业需在战略层面重视跨境数据流通合规性，作好整体的合规性规划，并确99保落实数据流通的合规性和安全性。由于不同国家和地区对于数据管理有着不同的法规，例如欧洲的 GDPR、美国的 CCPA 等，企业在进行数据跨境处理活动时必须要遵守业务所在国法律法规，提前全面评估数据跨境传输合规风险，包括数据泄露、数据安全事故、违反相关法规等风险，做好应对和整改措施，以确保数据跨境的合规性。此外，还应加大培养熟悉境外法律法规的数据安全和合规专业人才。（2）成立跨部门协作的企业内部数据合规成立跨部门协作的企业内部数据合规组织机构组织机构企业可以成立跨部门的数据合规组织，明确各岗位职责和任务，建立良好的沟通和协作机制。数据合规组织的成员应该来自企业的各个部门，包括但不限于法务、信息安全、合规、技术等部门,共同探讨数据跨境的业务场景、评估合规风险,制定合规政策和操作规程、开展合规意识和能力的培训和教育，必要情况下，可聘请外部专业的数据安全机构、咨询公司、律师事务所等专家进行内训。此外，数据合规组织还应制定数据跨境安全事件的应急预案（包括启动条件、响应程序、恢复措施等），以应对可能发生的数据跨境安全事件或违规行为。第五，数据合规组织还需定期开展个人信息保护风险评估和审计（包括审计内容、审计时间、审计人员等），以确保数据跨境的数据安全和隐私政策的执行符合要求。（3）建立标准、完善的数据安全管理制度，强化数据跨境传输安全保障措建立标准、完善的数据安全管理制度，强化数据跨境传输安全保障措施施企业应采用创新的数据安全和合规管理模式，如采用人工智能、区块链等技术手段，提高数据管理和监管的效率和准确性。标准、完善的数据安全管理制度包括但不限于对数据进行分类与标记、设置访问控制、开展定期审查与监测、记录操作日志、实施数据备份与恢复等。建立一套数据流通审计机制，追溯数据流通的路径；建立一套完善的数据保护机制，包括数据加密、数据脱敏、数据备份、数据访问权限控制、数据恢复等，定期评估数据风险；建立一套数据合规风险应急响应机制，及时处理风险问题；建立数据跨境传输审批和监管机制，与相关监管机构保持密切联系（及时了解相关法规和要求），明确审批流程和责任人，确保数据的合规性和安全性。5.3.推动跨境数据流通合规技术产业发展建构跨境数据流通友好型的技术与标准体系，有利于解决数据跨境风险不可见和流转不可知的问题。这套技术体系可包括跨境数据流量采集与还原技术、跨境敏感数据传输发现技术、跨境数据安全风险发现技术、大数据关联分析和事件分析技术、区块链可信确权监管技术等。沉淀在数据跨境过程中的发现敏感数据、预警和及时应对风险的能力，从技术上保障数据的跨境安全和有序流动。100（1）通过数据采集传输的技术标准，助力发现跨境场景的敏感数据通过数据采集传输的技术标准，助力发现跨境场景的敏感数据针对敏感数据发现的问题，企业可借助相关技术标准如跨境数据流量采集与还原技术、跨境敏感数据传输发现技术等予以解决。如跨境数据流量采集与还原技术，即通过对企业互联网侧或者跨境专线流量进行采集和还原，并结合单边、空洞和碎片化流量的补全检测技术，提高流量还原的能力，同时也有效提升敏感数据的检测能力和威胁分析能力。跨境敏感数据传输发现技术是通过流量还原及特征识别技术对互联网流量进行深度分析还原，利用特征分析、自然语言识别、OCR 等技术实现对传输敏感数据的应用、API 接口进行敏感数据识别、提取、去重，并记录访问时间、数据流入地址等信息。这些技术标准可以帮助企业保护敏感数据，减少不安全的访问传输导致泄露的风险，实现在相应场景下的技术标准推广，确保数据的安全性和可用性。（2）通过跨境数据安全风险发现技术标准，加强数据跨境的风险识别通过跨境数据安全风险发现技术标准，加强数据跨境的风险识别构建跨境数据安全风险发现技术标准体系，可以有效地提升数据跨境的风险识别能力。跨境数据安全风险发现技术标准体系包括：数据库漏洞发现技术、弱口令风险发现技术、数据爬取风险发现技术、接口鉴权风险发现技术、接口安全漏洞风险发现技术、接口误暴露风险发现技术等。跨境数据安全风险发现技术标准体系，支持通过技术手段识别和分析数据存储、访问、传输的过程中可能存在的安全漏洞，保障数据跨境的合规机制在技术方面落地，从而确保数据的机密性、完整性和可用性。相关技术标准的推动有助于预研措施保障数据跨境安全，发现处理任何可能的跨境数据泄露事件，避免潜在的损失和风险，提高跨境数据流通的安全性和可靠性。（3）跨境数据安全事件发现技术标准，提升数据跨境安全事件的防范能力跨境数据安全事件发现技术标准，提升数据跨境安全事件的防范能力构建跨境数据安全事件发现技术标准体系，可以有效地降低数据跨境安全事件带来的安全风险。跨境数据安全事件发现技术标准体系主要包括：利用对威胁情报、攻击事件、敏感数据传输等多维度关联分析，建立攻击者与敏感数据传输通道关联关系，基于敏感数据窃取事件发现技术挖掘攻击者窃取行为的重要信息；基于访问时间、访问源、访问账号、传输方式、传输内容等访问行为相关的多维度敏感数据，通过统计分析手段精确地追踪敏感数据违规传输事件；利用监测手段构建“境内-境外”的数据流转态势，精确追踪敏感数据全路径信息和行为的敏感数据违规出境事件。该标准的发布和推行能够支持企业和监管机构及时发现重要数据违规出境、敏感数据未通过加密链路传输出境、个人敏感数据出境数量超过申报数量或法律法规要求等违规出境传输事件，从而实现数据跨境场景安全事件的防范能力、内部核查和政府监管的能力提升。101（4）通过通过区块链及隐私计算的区块链及隐私计算的标准标准，实现跨境数据安全，实现跨境数据安全可信流通可信流通为解决数据流通中多方共治、共管的安全和隐私保护，可以通过区块链及隐私计算等新技术基础设施相关标准的指引，保障数据可用不可见，能有效降低不同地区跨境政策和法规可能导致的合规冲突可能性。如区块链作为分布式数据库技术，通过去中心化和共识机制确保数据的安全性和可信度，其分布式、点对点的特点，支持针对跨境场景数据流通和安全审查的技术基础设施层的解决方案，可实现数据不可篡改、透明和可追溯；隐私计算技术在政府管控敏感数据流动的场景下，使数据备份、流通、交易、交换更加安全和高效。数据跨境场景的区块链及隐私计算的技术标准体系，应包含数据结构标准、网络通信标准、加密算法标准、身份验证标准、隐私计算标准等。推广区块链及隐私计算的技术标准，实现不可篡改的数据链条，实现数据操作分级、确权和监控，保障数据流动的完整性、安全性和可靠性。5.4.重视合规人才培养与产业共生随着跨境数据流通日益频繁，企业对数据合规专业人才的需求也在加速增长。目前，我国数据跨境专业合规人才紧缺，高校、专业培训机构、行业协会、企业等均应重视对数据跨境专业人才的培养。高校通过设立数据合规相关专业、研究机构等，针对性的开展中国数据出境相关法规、欧盟 GDPR、美国 CCPA、中国数据出境相关法规等课程教学，培养后备力量，为企业和社会提供人才。行业协会可建立数据跨境人才培养机制，聘请行业内外部专家开展数据跨境法规和案例培训、宣讲，每年进行数据跨境合规人才和实践案例的选拔和评选等。企业可内部挖掘和培养跨境数据流通合规人才。通过聘请外部专家对数据跨境业务所涉及的国家或地区的法律法规、监管政策、实务场景和处罚案例等进行宣贯，以培训、考试等方式进行内部培养。同时，鼓励和奖励内部员工考取数据合规相关资质证书和认证资格。也可支持和安排合规人才短期出国访问或实习,了解国际最佳实践（包括参与国际项目和与国际数据传输相关的工作内容等），积累国际经验。企业可以联合高校（如南方科技大学深圳国家应用数学中心、深圳职业技术大学）、行业协会等机构建立合作共享和交流平台，开展数据跨境理论与实践的研讨与交流，互通有无，共同学习和进步。目前，各数据交易所在全国范围内培养数据合规、数据跨境、数据交易、数据价值挖掘等方面的复合人才，如深圳数据交易所开展的 DEXCO（数据交易合规师）的培训认证，帮助企业开展数据合规、数据治理、数据交易、数据资产入表等，取得较好的社会效果。1025.5.深化开放合作实现跨境合规应用多样化数据二十条提出，深入参与国际高标准数字规则制定，构建数据安全合规有序跨境流通机制。开展数据交互、业务互通、监管互认、服务共享等方面国际交流合作，推进跨境数字贸易基础设施建设，以 全球数据安全倡议 为基础，积极参与数据流动、数据安全、认证评估、数字货币等国际规则和数字技术标准制定。坚持开放发展，推动数据跨境双向有序流动，鼓励国内外企业及组织依法依规开展数据跨境流动业务合作，支持外资依法依规进入开放领域，推动形成公平竞争的国际化市场。实践中，如何建立相互信任，其实是数据跨境的最大挑战。（1）积极深入推进国际性数据跨境流通的顶层设计积极深入推进国际性数据跨境流通的顶层设计积极参与联合国、G20、上合组织等国际组织，共同制定多边国际数字规则，推选相关机构和个人参与国际数字化规则的具体制定；积极参与、主导国际、地区间的数据跨境流通协定制定，探索在东盟、一带一路、中非合作等区域性国际合作组织加入区域性国际数据跨境流动制度。推动数据跨境流动双边多边协商，在中日韩、东盟、中欧、中俄、一带一路等双边或多边国际合作中推进建立互利互惠的规则。在国际顶层设计的国际组织、国际交流中倡导反对数据霸权和数据保护主义，探索新的数据主权保护规则。（2）积极推进国际标准化和交流合作平台搭建积极推进国际标准化和交流合作平台搭建鼓励并推进国内企事业单位和标准化组织参与 ISO、IET 等国际标准组织，推进数据要素跨境、数据要素安全等国际标准的研究和制定，积极组织相关机构和个人在国际标准组织中组建、参与相关标准工作组，牵头、主导、参与数据流动、数据安全、认证评估、数字货币和数字技术标准的制定。利用现有国际贸易交流合作平台、组建新的数字贸易合作交流平台，面向国际、区域性合作、双边或多边合作，积极开展数据交互、业务互通、监管互认、服务共享等方面国际交流合作。（3）面向数据跨境开展顶层设计研究和制度建设面向数据跨境开展顶层设计研究和制度建设强化和完善数据跨境法律法规体系的构建。鼓励并组建国家级、区域性智库和研究机构对国际规则、国际数字化协定进行研究，支撑我国主导、参与国际化数字规则的制定；加强对美国、欧盟、日本等国家和国际组织的数据跨境相关规则、法律法规的研究，支撑国内相关机构开展数据跨境合作和业务开展。对影响或者可能影响国家安全的数据处理、数据跨境传输、外资并购等活动依法依规进行国家安全审查，建立能够统筹国内国外两个循环的安全审查制度、安全评估制度。按照对等原则，对维护国家安全和利益、履行国际义务相关的属于管制物项的数据建立出口管制制度，保障数据用于合法用途，防范数据出境安103全风险。探索构建多渠道、便利化的数据跨境流动监管机制，健全多部门协调配合的数据跨境流动监管体系。加强对国际主流国家相关标准规则的参考，增强我国数据跨境制度与其他国家或地区的国际协定与贸易谈判相衔接。（4）积极开展数据跨境流通试点和推广积极开展数据跨境流通试点和推广鼓励在北京、深圳、上海和海南等地面向国际贸易合作国探索数据跨境流动与合作的新途径新模式，鼓励国内外企业及组织依法依规开展数据跨境流动业务合作，支持外资依法依规进入开放领域，推动形成公平竞争的国际化市场。探索建立数据海关、数据保税区等新型跨境数字贸易基础设施。支持北京、深圳、贵阳、上海、海南等数据交易机构试点探索构建国际数据交易市场，积极与国际数据交易场所和机构开展合作，并面向国际组织和企业开展数据跨境交易活动。协同推进数据要素合法合规在各类国际组织间流通，协调好数据走出去与数据走进来的关系。针对跨境电商、跨境支付、供应链管理、服务外包等典型应用场景，探索安全规范的数据跨境流动方式，并适时面向东盟、俄罗斯、一带一路等主要贸易合作对象开展数据跨境试点，推进数据要素的高效跨境流入和流出，并在国际数字贸易具体场景中进行试点和推广。探索建立健全符合数据跨境白名单制度，适当减弱对数据跨境的严格限制，鼓励企业、社会组织积极参与数据国际流通，激活数字经济市场的活力。（5）探索粤港澳大湾区数据跨境发展的先行先试探索粤港澳大湾区数据跨境发展的先行先试数据二十条指出，积极鼓励试验探索。坚持顶层设计与基层探索结合，支持香港作为国际数据中心，辐射推广至整个大湾区，积极发挥高水平开放平台作用，支持有条件支持高端智造、生物医药、绿色低碳、合作办学的等产业加快突破数据可信流通、安全治理等关键技术，建立创新容错机制，探索完善数据要素产权、定价、流通、交易、使用、分配、治理、安全的政策标准和体制机制，更好发挥数据要素的积极作用。因此，应充分发挥粤港澳大湾区的跨境区域协调优势，从湾区的实践和需求出发，通过制定双向或多向清单、互认协议等方式促进湾区内部数据流通循环，建立重点行业如金融数据出境标准建设，积极探索数据要素跨境流通的治理协同标准化，为参与国际数据治理规则的制定作出有益的探索和总结。因此，一方面要积极主动开展国际交流合作、参与国际规则及标准制定，通过国际组织、智库平台积极开展数据安全、认证评估的相互认可，数据可信空间或者“数据可用不出境”的数据跨境流通系统等探讨，促成相互信任的机制的建立，维护国家安全和利益；另一方面在粤港澳大湾区等重要区域或城市先行先试，建立数据跨境标准体系，鼓励探索数据跨境流动与合作的新途径新模式。104参考文献1 区域全面经济伙伴关系协定,中华人民共和国商务部.http:/ CPTPP 数据跨境流动规则的难点及对策，服务外包，2023 年3 月，34-393 王蕊、潘怡辰、袁波、宋云潇，从 CPTPP 与 RC

0人已浏览 2023-12-06 214页 5星级

白皮书作者白皮书作者 This document is MulanPSL v2 licensed.龙蜥社区及龙蜥操作系统也获得了一定的行业认可，、荣获、“OSCAR 开源尖峰案例奖”等 25 项行业奖项。实验室简介 实验室设施及业务概况 实验室建设 SIG SIG 地址：https:/ 钉钉群：“龙蜥-可信计算 SIG 技术交流群”，群号： 微信群：“龙蜥-可信计算 SIG 技术交流群”1.1.3.3 futureTPM 工作组与主要目标 2.国家标准化管理委员会 ISO/IEC 11889 系列标准 TSS 规范官网入口：https:/trustedcomputinggroup.org/resource/tcg-software-stack-tss-specification/缩略语 PTP Platform TPM Profile CRB Command Response Buffer interface DDWG Device Drivers Writers Guide Certification PP Certification Protection Profile TIS TPM Interface Specification PC Client 标准及配套文档体系:缩略语 PFP Platform Firmware Profile PPI Physical Presence Interface FIM Firmware Integrity Measurement MOR Reset Attack Mitigation Memory on reset attack mitigation RIM Reference Integrity Manifest DRTM Dynamic Root of Trust for Measurement 标准编制 应用场景 标准推广 3.swtpm swtpm libtpms 1.#安装依赖包 2.yum install-y automake autoconf libtool gcc gcc-c make 3.openssl-devel pkg-config socat net-tools-deprecated 4.libtasn1-devel gnutls gnutls-devel libseccomp-devel 5.json-glib-devel expect softhsm 6.#下载 libtpms 源码 7.git clone https:/ 8.cd libtpms 9.#编译并安装 libtpms 10./autogen.sh-prefix=/usr-libdir=/usr/lib64-with-openssl 11.-with-tpm2 12.13.make-j4 14.make-j4 check 15.sudo make install 16.#下载 swtpm 源码 17.git clone https:/ 18.cd swtpm 19.#编译并安装 swtpm 20./autogen.sh-prefix=/usr-libdir=/usr/lib64-with-openssl 21.-with-tss-user=root-with-tss-group=tss-with-cuse 22.make-j4 23.sudo make check-j4 24.sudo make install 1.yum install libtpms swtpm swtpm-devel swtpm-tools swtpm 编译。1.#安装内核 cuse 模块 2.yum install kernel-modules-extra 3.modprobe cuse 1.#1.初始 tpm2 state 2.mkdir/tmp/myvtpm0;3.chown R tss:root/tmp/myvtpm0 4.swtpm_setup tpm2 tpm-state/tmp/myvtpm0 5.6.#2.创建 tpm2 字符设备 7.export TPM_PATH=/tmp/myvtpm0 8.swtpm_cuse-tpm2-n tpm0 9.#3.启动 tpm 设备 10.swtpm_ioctl-i-tpm-device/dev/tpm0 1.rootlocalhost swtpm#tpm2_pcrread 2.sha1:3.sha256:4.0:0 x0000000000000000000000000000000000000000000000000000000000000000 5.1:0 x0000000000000000000000000000000000000000000000000000000000000000 6.2:0 x0000000000000000000000000000000000000000000000000000000000000000 7.3:0 x0000000000000000000000000000000000000000000000000000000000000000 8.4:0 x0000000000000000000000000000000000000000000000000000000000000000 9.5:0 x0000000000000000000000000000000000000000000000000000000000000000 10.6:0 x0000000000000000000000000000000000000000000000000000000000000000 11.7:0 x0000000000000000000000000000000000000000000000000000000000000000 12.8:0 x0000000000000000000000000000000000000000000000000000000000000000 13.9:0 x0000000000000000000000000000000000000000000000000000000000000000 14.10:0 x0000000000000000000000000000000000000000000000000000000000000000 15.11:0 x0000000000000000000000000000000000000000000000000000000000000000 16.12:0 x0000000000000000000000000000000000000000000000000000000000000000 17.13:0 x0000000000000000000000000000000000000000000000000000000000000000 18.14:0 x0000000000000000000000000000000000000000000000000000000000000000 19.15:0 x0000000000000000000000000000000000000000000000000000000000000000 20.16:0 x0000000000000000000000000000000000000000000000000000000000000000 21.17:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 22.18:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 23.19:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 24.20:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 25.21:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 26.22:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 27.23:0 x0000000000000000000000000000000000000000000000000000000000000000 28.sha384:29.sha512:1.$mkdir$path_to_vm/mytpm0 1.$swtpm socket-tpmstate dir=$path_to_vm/mytpm0 2.-ctrl type=unixio,path=$path_to_vm/mytpm0/swtpm-sock 3.-log level=20 1.swtpm socket-tpm2-tpmstate dir=$path_to_vm/mytpm0 2.-ctrl type=unixio,path=$path_to_vm/mytpm0/swtpm-sock 3.-log level=20 X86_641.-chardev socket,id=chrtpm,path=$path_to_vm/mytpm0/swtpm-sock 2.-tpmdev emulator,id=tpm0,chardev=chrtpm 3.-device tpm-tis,tpmdev=tpm0 aarch64-chardev socket,id=chrtpm,path=$path_to_vm/mytpm0/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis-device,tpmdev=tpm0 1.2.3.4.5.1.chmod-R 777/var/lib/swtpm-localca/2.virsh start vm 1.#lsmod|grep tpm 2.#tpm_tis 16384 0 3.#4.#yum list installed|grep-E tpm2-tss|tpm2-tools 5.#6.#yum install tpm2-tss tpm2-tools 1.rootlocalhost#tpm2_pcrread 2.sha1:3.0:0 xB88919A8FA33C7A11CEB80A1B9772B499BDAABC8 4.1:0 xED92EDC2A5E26D77F83020956E1AA02140870AC3 5.2:0 xB2A83B0EBF2F8374299A5B2BDFC31EA955AD7236 6.3:0 xB2A83B0EBF2F8374299A5B2BDFC31EA955AD7236 7.4:0 x30DDAE4ED835392D81A7CE6FEF905E169BAC27A5 8.5:0 x7BC897262CAD4E3F16F5CE180F6F4B6DEE253483 9.6:0 xB2A83B0EBF2F8374299A5B2BDFC31EA955AD7236 10.7:0 xC8D7DB36A45078BA06A86DAD3A20DCFD525C1E1B 11.8:0 x26B98CA9A67B20C4E7B9C1DAFC6890234CBF6E38 12.9:0 x92B9BA924DEBF7A64AB157689AE4AC921B9E930D 13.10:0 x96E96D79512639B9A2DF577CE237D18F544BD74D 14.11:0 x0000000000000000000000000000000000000000 15.12:0 x0000000000000000000000000000000000000000 16.13:0 x0000000000000000000000000000000000000000 17.14:0 x8DF12380EDE005407EAB81DA4405321E0DA61280 18.15:0 x0000000000000000000000000000000000000000 19.16:0 x0000000000000000000000000000000000000000 20.17:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 21.18:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 22.19:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 23.20:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 24.21:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 25.22:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 26.23:0 x0000000000000000000000000000000000000000 27.sha256:28.0:0 xE3B7A76FDC83187F0233F4616FED23301B044DE62AABC0CCADE6D9468FCB4233 29.1:0 x862224F4F2B87A4DF717EB92BB828C4598C4CF411ADF83FC9BB084B6D31A5D09 30.2:0 x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969 31.3:0 x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969 32.4:0 x8D870A781FF79622E72E858B36F025428C15846ABB3D54E0EEACA33E418B9E91 33.5:0 x60EB17AA48B50CC8E78C052BAA633B0848F36B452FC4BE6C2481B525E595C8C8 34.6:0 x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969 35.7:0 x97FB0EDBE28C25A14D775090F36682D04596FDA4BF5750F275F76C1643BBDC2D 36.8:0 x62A10C0A8638B71A355AAB7C8C66BFE052EBF2F1E9C5308A430AF5FC7652B35E 37.9:0 xED743F4D59ABE8C055EA0E8CE983879D69DBE9894F42172ECFAA65E8583E9DFF 38.10:0 xF4FA23203592F54BD5E4392C84CD9591D5D8211638D128CCBE332F54BDD287B0 39.11:0 x0000000000000000000000000000000000000000000000000000000000000000 40.12:0 x0000000000000000000000000000000000000000000000000000000000000000 41.13:0 x0000000000000000000000000000000000000000000000000000000000000000 42.14:0 xA4DAD77FB3B6CACBD20F556986C5D917F5E322C123AF82D12C5E5B7EF7AE9938 43.15:0 x0000000000000000000000000000000000000000000000000000000000000000 44.16:0 x0000000000000000000000000000000000000000000000000000000000000000 45.17:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 46.18:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 47.19:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 48.20:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 49.21:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 50.22:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 51.23:0 x0000000000000000000000000000000000000000000000000000000000000000 52.sha384:53.0:0 xE0B9E19988D06E4774A33A802981E77123045D56492146A914331AA1FA49AA99DE549823515E6D862779E2F959FF5AC6 54.1:0 x1C44C67D8DD3C86ABD4BAFCC6761DDFFDA96B843F271C6D4D92F84AA8C11BF205831F33D57FB4E960A9C0E83D5C32827 55.2:0 x518923B0F955D08DA077C96AABA522B9DECEDE61C599CEA6C41889CFBEA4AE4D50529D96FE4D1AFDAFB65E7F95BF23C4 56.3:0 x518923B0F955D08DA077C96AABA522B9DECEDE61C599CEA6C41889CFBEA4AE4D50529D96FE4D1AFDAFB65E7F95BF23C4 57.4:0 xBF5307DF2DC437D1F9CB35CB1A85E00717F150C306F01ED7D1EE3565E4626242AE41E9F2F1EDAD9C3F85A34F54F1C172 58.5:0 xAAA365D0D07B6C656D4F8A78346951ECFC2D7C92D3EE475925D9900BB22A255BFFB01B3C9E5CE631CD9BB3C91BB868DE 59.6:0 x518923B0F955D08DA077C96AABA522B9DECEDE61C599CEA6C41889CFBEA4AE4D50529D96FE4D1AFDAFB65E7F95BF23C4 60.7:0 x8742CE00FA4AAB6A8C3B30584D1BB01D4BB680CD9D72923DDCD3600B25EDB9BE9B13B4714A023AE7DC57003ACFB544C1 61.8:0 xADC524F78EAE447F5068D5FCBFF0C9E235CA9903D91FCF21A753A5F7E30B50445C67D7B14184C202C56FFB0BCD55EE3A 62.9:0 xC4F3002193E307C45F62DB79640F3EE54F4738EF83C138010FCA9E47BAD92FACEC0DCADFD0A7E9AB17EDA10F772F5A66 63.10:0 x97F83AABAE79094226377E6288AD64BE6A7BEE26FB40E1846D7A2A877F569633E65CAF72C02DE0665AFE626F476A6124 64.11:0 x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 65.12:0 x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 66.13:0 x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 67.14:0 x108357C39E8DC8F150A33738567AF451908F80DDFC8C14801FBD513F307DA99082EA0ABA8CC7E042940F310E54C8AB10 68.15:0 x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 69.16:0 x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 70.17:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 71.18:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 72.19:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 73.20:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 74.21:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 75.22:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 76.23:0 x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 77.sha512:78.0:0 x0893229AF987740D78145E551F2C04D6C3A1C3FD4043EBB6BCF6C94F8EDF92EE99DC44916C6FF3AB4F4492EA3AA6C1D60C9912DD379E3B9CF9E7BCF08789720C 79.1:0 x2CCA44A4B710CFFA20EF4C10F378E63E4D2065462A69981381C9DB1BC1D0D8396A09480CC31B4102E6C29A1F3002E170B52E1BE2FEE80E565146C04A534A4BDD 80.2:0 x27EC091533C4B9EEA38DD14C3A3ECDEF0A99C1E564CBE66DFE008250154E7839B0B75228FE8DEBCC4CA330E6AEBC1ABC74070BC9C9C1E26B939C9D916E45E13C 81.3:0 x27EC091533C4B9EEA38DD14C3A3ECDEF0A99C1E564CBE66DFE008250154E7839B0B75228FE8DEBCC4CA330E6AEBC1ABC74070BC9C9C1E26B939C9D916E45E13C 82.4:0 xB9D1555BC9F1BCF7AFEAF3D60E246C6063ACF2572518FDC12CF7CD689A1E8E10D0B43CFB77CF60F898D99B5523C829849BF08CA8A882395554FECE71E618BFB2 83.5:0 x58F94888F6AC2C4CC23BFBCFF6A013BED1EFDF239EE1BF2FEF5F8C4E7443A7D2E7A90636792A1B858DC8A70C1BE077DE99992B67CC67AAF1746652FE9043A249 84.6:0 x27EC091533C4B9EEA38DD14C3A3ECDEF0A99C1E564CBE66DFE008250154E7839B0B75228FE8DEBCC4CA330E6AEBC1ABC74070BC9C9C1E26B939C9D916E45E13C 85.7:0 xD2CAB183E6A0BD48AF28C0B04DADAD16EDC21466FB1B8380546147399C42EF82F91A91F2E9D80BEF2EE691E298692775B07B4C02A0C69BD9E55D052865C38302 86.8:0 x77BA9278692B14942F7BCB5E447878D56039E5B649649039B0BBBD31B90DC23996F23213169173A4D30E466A2E98A47BFCBD80EA0E2363BF1AB292E1CB5F6C8F 87.9:0 xC2C007228B3DF18F6749EE86058EC4819833A77E6C3AFE053FBBEB1D1C474180AB9AE75E52621A4AD4E92F39234C5FB787F0576B9DCB292997C05ACEDC770DFC 88.10:0 x0DFFB841CDC6998F869A6EEF8A29E89FEC5485A6E0F00347A9D50B19B58DE98F6D66B54A8C10721DA8CC2D52CD09B81CD00F9AB266407961621E4E96E13D767A 89.11:0 x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 90.12:0 x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 91.13:0 x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 92.14:0 x795B199E04CF1A624716DC06C0352B1D8C8A57521BD8E252069E9DA04BCB0E0EA566E496FAFA959E25ACCFD47E0129E42FDCA0DBAE2E31539918B 93.15:0 x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 94.16:0 x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 95.17:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 96.18:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 97.19:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 98.20:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 99.21:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 100.22:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 101.23:0 x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 4)enum vtpm_proxy_flags 5)/*6)*常量 7)*VTPM_PROXY_FLAG_TPM2 8)*the proxy TPM uses TPM 2.0 protocol 9)*/parameter structure for the VTPM_PROXY_IOC_NEW_DEV ioctl 1.struct vtpm_proxy_new_dev 2.3./Definition:4.struct vtpm_proxy_new_dev 5._u32 flags;6._u32 tpm_num;7._u32 fd;8._u32 major;9._u32 minor;10.;11./*结构体成员说明 12.*flags:flags for the proxy TPM 13.*tpm_num:index of the TPM device 14.*fd:the file descriptor used by the proxy TPM 15.*major:the major number of the TPM device 16.*minor:the minor number of the TPM device 17.*/handler for the VTPM_PROXY_IOC_NEW_DEV ioctl 1.long vtpmx_ioc_new_dev(struct file*file,unsigned int ioctl,unsigned long arg)2.3./*函数参数说明 4.*struct file*file /dev/vtpmx 5.*unsigned int ioctl the ioctl number 6.*unsigned long arg pointer to the struct vtpmx_proxy_new_dev 7.*/8.9./*函数功能描述 10.*创建一个匿名文件，供进程作为 TPM 与客户端进程通信。11.*该函数还将添加一个新的 TPM 设备，通过该设备将数据代理到该 TPM 代理进程。12.*将为调用者提供一个文件描述符，用于与客户端通信，以及 TPM 设备的主要和次要编号。13.*/1. - 2.|Linux DomU|.3.|4.|v|5.|xen-tpmfront|6. - 7.|8.v|9. - 10.|mini-os/tpmback|11.|12.|v|13.|vtpm-stubdom|.14.|15.|v|16.|mini-os/tpmfront|17. - 18.|19.v|20. - 21.|mini-os/tpmback|22.|23.|v|24.|vtpmmgr-stubdom|25.|26.|v|27.|mini-os/tpm_tis|28. - 29.|30.v|31. - 32.|Hardware TPM|33. - Linux DomU：配置有 vTPM 的 Linux 客户机可能不止一个。xen-tpmfront.ko：Linux 内核虚拟 TPM 前端驱动。该驱动程序提供对基于 linux 的 DomU 的 vTPM 访问。mini-os/tpmback：Mini-os TPM 后端驱动程序，提供 Linux 前端驱动与后端驱动对接功能，实现 Linux DomU 与 vTPM 之间的通信。这个驱动程序也被 vtpmmgr-stubdom 用来与 vtpm-stubdom 通信。vtpm-stubdom：一个实现 vTPM 的 mini-os 存根域。在系统上运行的vtpm-stubdom 实例和逻辑 vtpms 之间存在一对一的映射关系。mini-os/tpmfront：Mini-os TPM 前端驱动程序。vTPM mini-os 域vTPM-stubdom 使用该驱动程序与 vtpmmgr-stubdom 通信。该驱动程序也用于与 vTPM 域通信的 mini-os 域，例如 pv-grub。vtpmmgr-stubdom：实现 vTPM 管理器的 mini-os 域。只有一个 vTPM管理器，它应该在机器的整个生命周期中运行。该域规范对系统物理 TPM的访问，并确保每个 vTPM 的持久状态。mini-os/tpm_tis：Mini-os TPM version 1.2 TPM Interface Specification （TIS）驱动程序。vtpmmgr-stubdom 使用这个驱动程序直接与硬件 TPM 对话。通过将硬件内存页映射到 vtpmmgr-stubdom 的方式，方便与硬件 TPM 通信。硬件 TPM:物理 TPM 模块，一般是焊接到主板上的。与 Xen 集成 https:/ ima_ascii_measurements_show()（identifier:description）d：事件的摘要（即度量文件的摘要）；用 SHA1 或 MD5 哈希算法计算；n：事件的名称(即文件名)，大小为 255 字节；d-ng：事件的摘要，用任意散列计算算法（字段格式:digest）；d-ngv2：与 d-ng 相同，但前缀为”ima”或”verity”摘要类型(字段格式:摘要)；d-modsig：事件摘要，不包含附加的 modsig；n-ng:事件的名称，没有大小限制；sig：文件签名，基于文件的/fsversity 的摘要，或 EVM 便携式签名。modsig附加文件签名；buf：用于生成哈希的缓冲区数据，没有大小限制；evmsig：EVM 便携签名；iuid：索引节点 UID；igid：索引节点的 GID；imode：索引节点模式；xattrnames：xattr 名称列表(以|分隔)，仅当 xattr 为现在；xattrlength：xattr 长度列表(u32)，仅当 xattr 存在时；xattrvalues：xattr 值的列表。“ima”：格式为“d|n”；“ima-ng”(默认)：它的格式是“d-ng|n-ng；“ima-ngv2”：格式为“d-ngv2|n-ng”；“image-sig”：格式为“d-ng|n-ng|sig”；“ima-sigv2”：格式为“d-ngv2|n-ng|sig”；“ima-buf”：格式为“d-ng|n-ng|buf”；“ima-modsig”：格式为“d-ng|n-ng|sig|d-modsig|modsig”；“evm-sig”：格式为“d-ng|n-ng|evmsig|xattrnames|xattrlength|xattrvalues|iuid|igid|imode”。ima-ng ima_template=ima_template_fmt=。一种是各个语言原生实现的：其中 tpm2-tss 是基于 TCG 标准实现的被广泛使用。一种是基于其它语言实现的 wrapper（tpm2-pytss 和 rust-tss-esapi 均基于 C 语言的 tpm2-tss 封装的 wrapper)。tpm2-tss 及配套的 tpm2-abrmd 和 tpm2-tools 来满足大部分可信计算用户的需求。python-tpm2-pytss 这个基于 tpm2-tss 的软件栈来满足可信计算Python 用户的需求。海光在龙蜥社区贡献了 tpm2-tss 和 tpm2-tools 的仓库部分组件/库的国密功能，详见 hygon-tpm2-tss 和 hygon-tpm2-tools，这些特性也都集成到 Anolis OS 对应版本的 yum 源中。龙蜥社区也在跟进和探索知名开源项目 keylime，keylime 部分组件依赖于 rust 的 TSS 软件栈 rust-tss-esapi，未来也有计划将 rust-tss-esapi引入来更好的服务可信计算 Rust 用户。FAPI:大多数的用户层引用程序基于 FAPI 开发就可以了，因为 FAPI 实现了 TPM 百分之八十的常用应用场景。使用这一层开发应用就像是使用JAVA，C#等高级语言开发应用一样方便。FAPI 对应的库为libtss2-fapi，对应的标准为 TCG Feature API(FAPI)Specification,TCG TSS 2.0 JSON Data Types and Policy Language Specification。ESAPI:往下一层是 ESAPI，它需要你对 TPM 了解很深，它实现了 TPM2命令的 1:1 映射，但是同时提供了会话管理以及加解密的辅助功能。这有点像使用 C 开发应用程序。ESAPI 对应的库为 libtss-esys,对应的标准为 TCG TSS 2.0 Enhanced System API(ESAPI)Specification。SAPI:应用程序也可以直接基于 SAPI 这一层，它实现了 TPM2 命令的1:1 映射，但这需要你对 TPM 了如指掌。这就像是使用 C 语言编写应用程序，而不是用高级语言。它提供了 TPM 的所有功能，但是要想用好它你必须对 TPM 有很深的理解。SAPI 对应的库为libtss2sys，对应的标准为 TCG TSS 2.0 System Level API(SAPI)Specification。TCTI:TCTI 层用于向 TPM 发送命令并接收 TPM 对命令的响应。应用可以直接通过 TCTI 发送命令的数据流并解析接收到的响应数据流。这就像是使用汇编语言来编写应用程序。它对应的库为libtss2tctidevice、libtss2tctitbs等，对应的标准为 TCG TSS 2.0 TPM Command Transmission Interface(TCTI)API Specification。TAB:TAB 这一层主要负责多线程环境下 TPM 资源的同步。也就是说它允许多个线程同时访问 TPM 而不发生冲突。RM:因为 TPM 内部的存储资源非常有限，所以需要一个资源管理器RM，它的原理于虚拟内存管理类似，它可以将 TPM 对象和会话换进换出 TPM。驱动：最后一层就是设备驱动，它主要是控制通信外设与 TPM 互相传输数据。如果你愿意的话，直接调用设备驱动接口来编写应用程序也是可以的，当然这就像是你用二进制数据编写程序一样。Application#1Application#2Feature APIEnhanced System API System APITCTITCTITCTITCTITABTABTABTABResource MgrResource MgrResource MgrLocal TPM driverSim TPM driverVirt TPM driverLocal TPM TPM SimulatorVirtualTPMTAB Resource MgrLocal TPM driverRemote TPMLocal TPM sendLocal TPM rcvSim TPM sendSim TPM rcvVirt TPM sendVirt TPM rcvRemote SystemRem TPM send 对于开发者和用户而言，tpm2-tss 中使用最多的是 FAPI 和 ESAPI，他们均提供了非常多的 APIs 供开发者使用。tpm2-tss 提供一个文档详细的介绍了 FAPI 和ESAPI 中各个 APIs 的用法以及参数的含义，对用户快速理解和使用这些 APIs 非常有帮助。Esys Context ESYS_CONTEXT 相关 APIs：提供一些上下文相关的接口函数，用来初始化和释放上下文、获取底层的 SAPI 和 TCTI 上下文等。Esys Tpm Resource ESYS_TR 负责管理该层 TPM 软件资源相关的ESAPI。Esys TPM Commands 与 TPM 2.0 命令 1:1 映射的 ESAPI，调用对应的 ESAPI 命令最终会转换为对应的 TPM 2.0 命令。Internals of Enhanced System API：该层内部使用的一些 ESAPI，包轮一些内部类型以及加密相关的 APIs 等。tools/tpm2_tool.h1.#include 然后参考/tpm2_tool.c的 ctx_init 函数去调用Esys_Initialize这个 ESAPI来初始化 ESAPI 的上下文，例如：1.static ESYS_CONTEXT*ctx_init(TSS2_TCTI_CONTEXT*tcti_ctx)2.3.ESYS_CONTEXT*esys_ctx;4.5.TSS2_RC rval=Esys_Initialize(&esys_ctx,tcti_ctx,NULL);6.if(rval!=TPM2_RC_SUCCESS)7.LOG_PERR(Esys_Initialize,rval);8.return NULL;9.10.11.return esys_ctx;12.lib/tpm2.ctpm2_pcr_read函数Esys_PCR_Read1.tool_rc tpm2_pcr_read(ESYS_CONTEXT*esys_context,ESYS_TR shandle1,2.ESYS_TR shandle2,ESYS_TR shandle3,3.const TPML_PCR_SELECTION*pcr_selection_in,UINT32*pcr_update_counter,4.TPML_PCR_SELECTION*pcr_selection_out,TPML_DIGEST*pcr_values,5.TPM2B_DIGEST*cp_hash,TPMI_ALG_HASH parameter_hash_algorithm)6.7.TSS2_RC rval=TSS2_RC_SUCCESS;8.tool_rc rc=tool_rc_success;9.10.11.rval=Esys_PCR_Read(esys_context,shandle1,shandle2,shandle3,12.pcr_selection_in,pcr_update_counter,pcr_selection_out,pcr_values);13.if(rval!=TSS2_RC_SUCCESS)14.LOG_PERR(Esys_PCR_Read,rval);15.return tool_rc_from_tpm(rval);16.17.最 后 当 我 们 的 所 有 操 作 完 成 后，需 要 参 考tools/tpm2_tool.c的esys_teardown 函数去调用_Finalize这个 ESAPI 来销毁 ESAPI 的上下文，比如：1.static void esys_teardown(ESYS_CONTEXT*esys_context)2.3.if(esys_context=NULL)4.return;5.if(*esys_context=NULL)6.return;7.Esys_Finalize(esys_context);持续跟进上游社区各个语言 TSS 软件栈的动态并积极参与贡献，同时也会把这些成果引入到 Anolis OS 中。接受社区各个参与方在 TSS 软件栈上的贡献，并以实践文档等方式输出到可信计算 SIG 中。提供更多的实践指南，使用文档等，便于用户更好地使用。1.yum install tpm2-tools 1.tpm2_startup-v 2.tool=tpm2_startup version=tctis=libtss2-tctildr tcti-default=tcti-device 1.tpm2_startup-v 2.tool=tpm2_startup version=tctis=libtss2-tctildr tcti-default=tcti-abrmd 1.tpm2_startup -V#执行 TPM2_SU_STATE 类型的 startup 2.INFO on line:54 in file:tools/tpm2_startup.c:3.Sending TPM_Startup command with type:TPM2_SU_STATE 4.5.tpm2_startup-c-V#执行 TPM2_SU_CLEAR 类型的 startup 6.INFO on line:54 in file:tools/tpm2_startup.c:7.Sending TPM_Startup command with type:TPM2_SU_CLEAR 1.tpm2_getcap algorithms-V#获取 TPM2.0 芯片支持的算法信息 2.INFO on line:44 in file:lib/tpm2_capability.c:3.GetCapability:capability:0 x0,property:0 x1 4.rsa:5.value:0 x1 6.asymmetric:1 7.symmetric:0 8.hash:0 9.object:1 10.reserved:0 x0 11.signing:0 12.encrypting:0 13.method:0 14.15.16.tpm2_getcap commands-V#获取 TPM2.0 芯片支持的命令码 17.INFO on line:44 in file:lib/tpm2_capability.c:18.GetCapability:capability:0 x2,property:0 x11f 19.TPM2_CC_NV_UndefineSpaceSpecial:20.value:0 x440011F mandIndex:0 x11f 22.reserved1:0 x0 23.nv:1 24.extensive:0 25.flushed:0 26.cHandles:0 x2 27.rHandle:0 28.V:0 29.Res:0 x0 30.31.32.tpm2_getcap properties-fixed-V#获取 TPM2.0 芯片固定属性信息 33.INFO on line:44 in file:lib/tpm2_capability.c:34.GetCapability:capability:0 x6,property:0 x100 35.TPM2_PT_FAMILY_INDICATOR:36.raw:0 x322E3000 37.value:2.0 38.TPM2_PT_LEVEL:39.raw:0 40.TPM2_PT_REVISION:41.value:1.16 42.TPM2_PT_DAY_OF_YEAR:43.raw:0 xF 44.TPM2_PT_YEAR:45.raw:0 x7E0 46.TPM2_PT_MANUFACTURER:47.raw:0 x564D5700 48.value:VMW 49.50.51.tpm2_getcap ecc-curves-V#获取 TPM2.0 芯片支持的椭圆曲线信息 52.INFO on line:44 in file:lib/tpm2_capability.c:53.GetCapability:capability:0 x8,property:0 x1 54.TPM2_ECC_NIST_P192:0 x1 55.TPM2_ECC_NIST_P224:0 x2 56.TPM2_ECC_NIST_P256:0 x3 57.TPM2_ECC_NIST_P384:0 x4 58.TPM2_ECC_BN_P256:0 x10 59.60.61.tpm2_getcap handles-nv-index-V#获取已定义的 NV 空间句柄 62.INFO on line:44 in file:lib/tpm2_capability.c:63.GetCapability:capability:0 x1,property:0 x1000000 64.-0 x1691D65 65.-0 x1C00002 66.-0 x1C0000A 67.68.tpm2_getcap handles-transient-V#获取暂存对象句柄 69.INFO on line:44 in file:lib/tpm2_capability.c:70.GetCapability:capability:0 x1,property:0 x80000000 71.-0 x80000000 72.-0 x80000001 1.tpm2_createprimary-C o-G rsa-c rsaprimary.ctx-V#在 TPM_RH_Owner Hierary 创建RSA 算法的 2.INFO on line:44 in file:lib/tpm2_capability.c:3.GetCapability:capability:0 x5,property:0 x0 4.name-alg:5.value:sha256 6.raw:0 xb 7.attributes:8.value:fixedtpm|fixedparent|sensitivedataorigin|userwithauth 9.|restricted|decrypt 10.raw:0 x30072 11.type:12.value:rsa 13.raw:0 x1 14.exponent:0 x0 15.bits:2048 16.scheme:17.value:null 18.raw:0 x10 19.scheme-halg:20.value:(null)21.raw:0 x0 22.sym-alg:23.value:aes 24.raw:0 x6 25.sym-mode:26.value:cfb 27.raw:0 x43 28.sym-keybits:128 29.rsa:b7a9f512d495edc54b0fae7a76c8f72a3708f0de4d6a6a08a73547c4d 30.f6fddb15e5bf9a94fb5a63ecdeb62e18138d93be4d4522ac12a091b354bab5 31.e4e36dde30b17ae4e84bf5d72a5447f2bfb3e6bc53b9ba847d85c0ec016935 32.4e301dbd9d83ba45a43747d55b541116da666bfa2fa583e317f 33.d1757309a1904c933fae6e92502a01b72bc3f46cc7665852b1a93d3b3344e9 34.5aa254ba4f7d9345916648a7a667a5ae275894a2789b46dff6a26cc8dc4cd8 35.3e848ac7e23a2fa7a0d2091eacb1cd40851eb0bdccb7ebdd1ad8057d1fbc1c 36.be54ceacba3e4a90157cfa53adf22f88a7c730b4b1584dff596c62f88ade2a 37.8a7c9d67f36f6db169b4f 38.INFO on line:190 in file:lib/files.c:39.Save TPMS_CONTEXT-savedHandle:0 x80000000 1.tpm2_create-C rsaprimary.ctx-G rsa-u rsa.public 2.-r rsa.private-V#以上一步创建的 PrimaryObject 为父密钥，3.创建 RSA 算法的密钥 4.INFO on line:44 in file:lib/tpm2_capability.c:5.GetCapability:capability:0 x5,property:0 x0 6.INFO on line:362 in file:lib/files.c:7.Assuming tpm context file 8.INFO on line:293 in file:lib/files.c:9.load:TPMS_CONTEXT-savedHandle:0 x80000000 10.name-alg:11.value:sha256 12.raw:0 xb 13.attributes:14.value:fixedtpm|fixedparent|sensitivedataorigin|userwithauth 15.|decrypt|sign 16.raw:0 x60072 17.type:18.value:rsa 19.raw:0 x1 20.exponent:0 x0 21.bits:2048 22.scheme:23.value:null 24.raw:0 x10 25.scheme-halg:26.value:(null)27.raw:0 x0 28.sym-alg:29.value:null 30.raw:0 x10 31.sym-mode:32.value:(null)33.raw:0 x0 34.sym-keybits:0 35.rsa:d01e9a0f80a79c7248b29e66535a16c43ff0ad70f5f6773d048bb6e9178 36.78f91ac53f672091b8103123123bce8603d761e7b39eb12b4a286816068c40c4 37.af5bd6296bc565913acc69fa5b4485835f1493a180cfb41ec6d18828f195941a 38.6446f55794ab8a304e78d2cf04e52d36a98ae94a70f8fa868dcbd8cf58c909df 39.684f0dc1f41ba27bcd86097cb8ae0d3cc50d5fba3ea6efd5780a605536f8a60a 40.a95350a0db6d639f5c25732ed4ab122df37d258d6786e0fbb123fc18eab71ed4 41.21c9200b1ebfc47ab5ab0e12a3566fcac5e97b1343ab022bf6ba8a94a1c4b795 42.46208806e3561d405bfdcbd7b2e7205a3fc73ed8e54cac847d32a06f0aec291e 43.fb27f 1.tpm2_create-C rsaprimary.ctx-G rsa-u rsa.public-r rsa.private#创建 RSA 算法的密钥 2.3.tpm2_load-C rsaprimary.ctx-u rsa.public-r rsa.private 4.-c rsa-enc-key.ctx-V#执行 TPM2_CC_Load 命令将创建的 RSA 密钥加 5.载至 TPM 芯片中 6.INFO on line:44 in file:lib/tpm2_capability.c:7.GetCapability:capability:0 x5,property:0 x0 8.INFO on line:362 in file:lib/files.c:9.Assuming tpm context file 10.INFO on line:293 in file:lib/files.c:11.load:TPMS_CONTEXT-savedHandle:0 x80000000 12.name:000b0b8d6e072c99c31c90856d9758ca1d2068147e028c 13.8073914e4a17a85e573fca 14.INFO on line:190 in file:lib/files.c:15.Save TPMS_CONTEXT-savedHandle:0 x80000000 16.17.echo 12345 data.txt#生成明文 18.19.tpm2_rsaencrypt-c rsa-enc-key.ctx-o cipher.bin data.txt-V 20.#使用 RSA 密钥加密 data.txt 文件，将密文输出到 cipher.bin 文件中 21.INFO on line:362 in file:lib/files.c:22.Assuming tpm context file 23.INFO on line:293 in file:lib/files.c:24.load:TPMS_CONTEXT-savedHandle:0 x80000000 25.26.tpm2_rsadecrypt-c rsa-enc-key.ctx-o data-dec.txt cipher.bin-V 27.#使用 RSA 密钥解密密文，并将密文输出到 data-dec.txt 文件 28.INFO on line:44 in file:lib/tpm2_capability.c:29.GetCapability:capability:0 x5,property:0 x0 30.INFO on line:362 in file:lib/files.c:31.Assuming tpm context file 32.INFO on line:293 in file:lib/files.c:33.load:TPMS_CONTEXT-savedHandle:0 x80000000 34.35.diff data-dec.txt data.txt#明文与解密后文件对比 1.tpm2_create-C rsaprimary.ctx-G rsa-u rsa.public 2.-r rsa.private#创建 RSA 算法的密钥 3.4.tpm2_load-C rsaprimary.ctx-u rsa.public-r rsa.private 5.-c rsa-sign-key.ctx-V#执行 TPM2_CC_Load 命令将创建的 RSA 密钥 6.加载至 TPM 芯片中 7.8.echo rsasign rsasigndata.txt#生成签名内容 9.10.tpm2_sign-c rsa-sign-key.ctx-o rsa-sig.bin rsasigndata.txt -V 11.#使用 RSA 密钥对 rsasigndata.txt 签名，将签名信息写入 rsa-sig.bin 文件 12.INFO on line:44 in file:lib/tpm2_capability.c:13.GetCapability:capability:0 x5,property:0 x0 14.INFO on line:362 in file:lib/files.c:15.Assuming tpm context file 16.INFO on line:293 in file:lib/files.c:17.load:TPMS_CONTEXT-savedHandle:0 x80000000 18.19.tpm2_verifysignature-c rsa-sign-key.ctx-s rsa-sig.bin 20.-m rsasigndata.txt#使用 RSA 密钥验签 21.22.echo rsasign1 rsasign1data.txt#构建异常数据 23.24.tpm2_verifysignature-c rsa-sign-key.ctx-s rsa-sig.bin 25.-m rsasign1data.txt-V#对异常数据签名验签 26.INFO on line:362 in file:lib/files.c:27.Assuming tpm context file 28.INFO on line:293 in file:lib/files.c:29.load:TPMS_CONTEXT-savedHandle:0 x80000000 30.WARNING:esys:src/tss2-esys/api/Esys_VerifySignature.c:302:Esys_VerifySignature_Finish()31.Received TPM Error 32.ERROR:esys:src/tss2-esys/api/Esys_VerifySignature.c:103:Esys_VerifySignature()33.Esys Finish ErrorCode(0 x000002db)34.ERROR on line:53 in file:lib/log.h:35.Esys_VerifySignature(0 x2DB)-tpm:parameter(2):36.the signature is not valid 37.ERROR on line:259 in file:tools/tpm2_verifysignature.c:38.Verify signature failed!39.ERROR on line:147 in file:tools/tpm2_tool.c:40.Unable to run tpm2_verifysignature 1.tpm2_create-C rsaprimary.ctx-G ecc-u ecc.public-r ecc.private#创建 ECC 算法的密钥 2.3.tpm2_load-C rsaprimary.ctx-u ecc.public-r ecc.private-c ecc-sign-key.ctx-V 4.#执行 TPM2_CC_Load 命令将创建的 ECC 密钥加载至 TPM 芯 片中 5.6.echo eccsign eccsigndata.txt#生成签名内容 7.8.tpm2_sign-c ecc-sign-key.ctx-o ecc-sig.bin eccsigndata.txt -V 9.#使用 ECC 密钥对 eccsigndata.txt 签名，将签名信息写入 ecc-sig.bin 文件 10.11.tpm2_verifysignature-c ecc-sign-key.ctx-s ecc-sig.bin-m eccsigndata.txt#使用ECC 密钥验签 1.tpm2_nvdefine-C o-s 100 0 x01800001-V 2.#在 TPM_RH_Owner 特权域中创建 100 字节的存储空间，空间索引为 0 x01800001 3.INFO on line:44 in file:lib/tpm2_capability.c:4.GetCapability:capability:0 x5,property:0 x0 5.nv-index:0 x1800001 6.7.echo 1234567890 nv.txt#生成存储数据 8.9.tpm2_nvwrite-i nv.txt-C o 0 x01800001-V 10.#向 NVRAM 0 x01800001 写入数据 11.INFO on line:44 in file:lib/tpm2_capability.c:12.GetCapability:capability:0 x5,property:0 x0 13.INFO on line:80 in file:tools/tpm2_nvwrite.c:14.The data(size=11)to be written:15.INFO on line:1657 in file:lib/tpm2.c:16.Success to write NV area at index 0 x1800001 offset 0 x0.17.18.tpm2_nvread-C o 0 x01800001-V 19.#读取 NVRAM 0 x01800001 中的内容 20.INFO on line:44 in file:lib/tpm2_capability.c:21.GetCapability:capability:0 x5,property:0 x0 22.1234567890 23.24.tpm2_nvundefine-C o 0 x01800001-V#释放 NVRAM 0 x1800001 25.INFO on line:44 in file:lib/tpm2_capability.c:26.GetCapability:capability:0 x5,property:0 x0 27.INFO on line:1580 in file:lib/tpm2.c:28.Success to release NV area at index 0 x1800001.1.tpm2_pcrread-V#获取当前 PCR 中的内容 2.sha1:3.0:0 xA660D212EE691C9295BBEA32A78BE89F9F27C5A9 4.1:0 xB2A83B0EBF2F8374299A5B2BDFC31EA955AD7236 5.2:0 xB2A83B0EBF2F8374299A5B2BDFC31EA955AD7236 6.3:0 xB2A83B0EBF2F8374299A5B2BDFC31EA955AD7236 7.4:0 xB0B51368B2865BD0B8B56BFE1CFE8E6177AB2465 8.5:0 x7273E316E323AAFFBFCDE3ED860DD266E0AA17EB 9.6:0 xB2A83B0EBF2F8374299A5B2BDFC31EA955AD7236 10.7:0 xDBAED2EAEFC85D2342AF7E2C7F0AD9188FF215B1 11.8:0 x16992E4CFBD1E29D5D99ADD56FC9AFAB1EFB0595 12.9:0 x3CFED51D0D507E2CDA5C996374BACAB93C6C6A16 13.10:0 x327C45F6007C43E7C6D82958EE6D18F890796A02 14.11:0 x0000000000000000000000000000000000000000 15.12:0 x0000000000000000000000000000000000000000 16.13:0 x0000000000000000000000000000000000000000 17.14:0 x8DF12380EDE005407EAB81DA4405321E0DA61280 18.15:0 x0000000000000000000000000000000000000000 19.16:0 x0000000000000000000000000000000000000000 20.17:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 21.18:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 22.19:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 23.20:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 24.21:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 25.22:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 26.23:0 x0000000000000000000000000000000000000000 27.sha256:28.0:0 xCD77123A880A51DB10BBA64BEBFF3B0AD20BA4D50F9F8B8A6B341DBD4E02F468 29.1:0 x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969 30.2:0 x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969 31.3:0 x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969 32.4:0 x76A09DC9FB1E61888B36E6C4A45C02A36B2E39FD40925506110F53586560D4B2 33.5:0 xD004B8D98FBEE7E967E9F46F55CDEE79D487FB5793AA5B1F6D7586A11AD9DEE9 34.6:0 x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969 35.7:0 x592E7099CFF05155224F26EC6F3781975A7B095F151772CB61714E32F59F6DE1 36.8:0 xE8A441D072B34D68432E00F368BCC3113315CF3707475072BAB93E3195B474C9 37.9:0 x93889BC9C705243940156FAFBD8EDB6CF820962BC45E005BBFFC90C516E991B1 38.10:0 x7ABD6A1ADAF3FA4AF27CAA9B541BDB79D535CB577C89FDED6BBF953ACB7AF29B 39.11:0 x0000000000000000000000000000000000000000000000000000000000000000 40.12:0 x0000000000000000000000000000000000000000000000000000000000000000 41.13:0 x0000000000000000000000000000000000000000000000000000000000000000 42.14:0 xA4DAD77FB3B6CACBD20F556986C5D917F5E322C123AF82D12C5E5B7EF7AE9938 43.15:0 x0000000000000000000000000000000000000000000000000000000000000000 44.16:0 x0000000000000000000000000000000000000000000000000000000000000000 45.17:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 46.18:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 47.19:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 48.20:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 49.21:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 50.22:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 51.23:0 x0000000000000000000000000000000000000000000000000000000000000000 52.53.54.echo 123 pcr.txt#生成扩展数据 55.56.sha256sum pcr.txt#计算扩展数据 sha256 摘要值 57.181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b 58.pcr.txt 59.60.tpm2_pcrextend 10:sha256=181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b-V 61.#将 pcr.txt 摘要值扩展至 PCR4 SHA-256 Bank 中 1.tpm2_getcap properties-variable-V#获取与 DA 相关的属性 2.INFO on line:44 in file:lib/tpm2_capability.c:3.GetCapability:capability:0 x6,property:0 x200 4.5.TPM2_PT_LOCKOUT_COUNTER:0 x0 6.TPM2_PT_MAX_AUTH_FAIL:0 x3 7.TPM2_PT_LOCKOUT_INTERVAL:0 x3E8 8.TPM2_PT_LOCKOUT_RECOVERY:0 x3E8 9.10.11.tpm2_dictionarylockout-s-l 300-t 300-n 10-V 12.#设定 maxTries 为 10 次，lockoutRecovery 为 300 秒，recoveryTime 为 300 秒 13.INFO on line:44 in file:lib/tpm2_capability.c:14.GetCapability:capability:0 x5,property:0 x0 15.INFO on line:1110 in file:lib/tpm2.c:16.Setting up Dictionary Lockout parameters.17.18.tpm2_getcap properties-variable-V 19.INFO on line:44 in file:lib/tpm2_capability.c:20.GetCapability:capability:0 x6,property:0 x200 21.22.TPM2_PT_LOCKOUT_COUNTER:0 x0 23.TPM2_PT_MAX_AUTH_FAIL:0 xA 24.TPM2_PT_LOCKOUT_INTERVAL:0 x12C 25.TPM2_PT_LOCKOUT_RECOVERY:0 x12C 26.27.28.tpm2_dictionarylockout-c-V#重置死锁计数器 29.INFO on line:44 in file:lib/tpm2_capability.c:30.GetCapability:capability:0 x5,property:0 x0 31.INFO on line:1099 in file:lib/tpm2.c:32.Resetting dictionary lockout state.1.yum install git automake libtool autoconf autoconf-archive 2.openssl-devel tpm2-tss-devel tpm2-tools make 3.git clone https:/ 4.pushd tpm2-tss-engine 5./bootstrap 6./configure-prefix=/usr 7.make 8.make install 9.popd 1.openssl engine-t-c tpm2tss 2.(tpm2tss)TPM2-TSS engine for OpenSSL 3.RSA,RAND 4.available 1.openssl rand-engine tpm2tss-hex 128 2.engine tpm2tss set.3.8a1b6a489fcf1b1fd8324e97cd76ff7e52617373fc43f7227145c69163 4.b85bd15bb77375a4d5a69b998c4717e7b4c8b1bdb1f3b0e3936a6f528d 5.9c90189c022cfeb94f008e35d54407c89229ef7fa338f9be0670e8d466 6.0aa61afcdb6e54dccd6079a9e2f93f3ce1528aa8124fcbbadd5bc79296 7.23ce2afe5802af2317b27a43 1.tpm2tss-genkey-a rsa-s 2048 rsakey#使用 tpm2-tss-genkey 生成 RSA 算法密钥 2.3.openssl rsa-engine tpm2tss-inform engine-in rsakey-pubout 4.-outform pem-out rsakey.pub#导出密钥公钥 5.engine tpm2tss set.6.writing RSA key 7.8.cat rsakey.pub#读取公钥信息 9.-BEGIN PUBLIC KEY-10.MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA17VGBbc3y8/ KSKJ5 K 11.MiGyY2CXpvgiYcajGZon8dEhYYLZ2d53wk6tgs19rHQl89T7h6rG2i5haaLRLTNr 12.gkxB4/OfK4dneVEtHgEZLbQmiGoI0ke4wCf9FhyrlpSRV7EUA0NYg86DE654X8Pd 13.4VsIc2Wb3Lf1MP1/lX/r5gZknyPqBe7NL5BM46m8WHS25tDf Mg/vHADgWboVGFK 14.W YpxYtubShAgOjXHc5lKuMKqG5nnIJkrxr8hgtf0ZXbVYywMt4NmaYV7Bc632ic 15.SkHk0OPGZ RMl8YQmIEmXLK9Tu0IVy58dC0wxvi4V2GQ p75uWF3K nZmYUXFl 2 16.IQIDAQAB 17.-END PUBLIC KEY-1.tpm2_createprimary-C o-G rsa2048-c rsaprimary.ctx#创建 TPM2 RSA 算法Primary Object 2.3.tpm2_create-C rsaprimary.ctx-G rsa2048-u rsa.pub-r rsa.pri#创建 TPM2 RSA 密钥 4.5.tpm2_load-C rsaprimary.ctx-u rsa.pub-r rsa.pri-c rsa.ctx#将 RSA 密钥导入 TPM2芯片 6.7.tpm2_evictcontrol-C o-c rsa.ctx#将 RSA 密钥设置为持久对象 8.persistent-handle:0 x81000000 9.action:persisted 10.11.openssl rsa-engine tpm2tss-inform engine-in 0 x81000000 12.-pubout-outform pem-out rsatpmkey.pub 13.#导出 TPM2 中持久对象 0 x81000000 的公钥 14.engine tpm2tss set.15.Enter password for user key:16.writing RSA key 17.18.cat rsatpmkey.pub#读取公钥信息 19.-BEGIN PUBLIC KEY-20.MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyA02SWyY6ZYyVR28O0R9 21.oDxxqd/RkxPa5W/4O773VkCRF8lovREKLrVV7pVHts6cxw8yrLc8Pzq5bArOTPh0 22.9M45Caxo13uhPd8H8p5UDORvrylJT7bJb5hrfJYyXyvd9FeXLqXexbJOSwPf vcD 23.yv6OKccNwCK/3s/89aEm1B8xuYU1TXFnfo/sLJ trUIiqrP3Aug/5gwB52lzTAX 24.WSCdogcbRL/AG7F2Zkn/56miZSzQ0I/o2Y/AaYrY3Oj0W/lIJmGTDiD5TbJJS3gQ 25.GdY1Tr3xf1Xsfo6ihJ0KCx2ZNBdtX7PIpErztLlllUCBGPNUt8OSVA V6eZANv9B 26.owIDAQAB 27.-END PUBLIC KEY-1.echo 123456 mydata#创建明文 2.3.openssl pkeyutl-pubin-inkey rsakey.pub-in mydata-encrypt 4.-out mycipher#使用公钥加密数据 5.6.openssl pkeyutl-engine tpm2tss-keyform engine-inkey rsakey 7.-decrypt-in mycipher-out mycipher-dec#使用私钥解密数据 8.9.diff mydata mycipher-dec#对比原文与解密后的明文 1.openssl pkeyutl-pubin-inkey rsatpmkey.pub-in mydata-encrypt 2.-out mycipher#使用公钥加密数据 3.4.openssl pkeyutl-engine tpm2tss-keyform engine-inkey 0 x81000000 5.-decrypt-in mycipher-out mycipher-dec 6.#使用 TPM2 中持久对象 0 x81000000 私钥解密数据 7.8.diff mydata mycipher-dec#对比原文与解密后的明文 1.openssl pkeyutl-engine tpm2tss-keyform engine-inkey rsakey 2.-sign-in mydata-out mysig 3.#使用 tpm2tss-genkey 生成的密钥 rsakey 签名数据 4.5.openssl pkeyutl-pubin-inkey rsakey.pub-verify-in mydata 6.-sigfile mysig#使用 rsakey 的公钥验签 7.Signature Verified Successfully 1.openssl pkeyutl-engine tpm2tss-keyform engine-inkey 0 x81000000 2.-sign-in mydata-out mysig#使用 TPM2 中持久对象 0 x81000000 签名数据 3.4.openssl pkeyutl-pubin-inkey rsatpmkey.pub-verify-in mydata 5.-sigfile mysig#使用 TPM2 中持久对象 0 x81000000 的公钥验证签名 1.tpm2tss-genkey-a ecdsa ecckey#使用 tpm2-tss-genkey 生成 ECC 算法密钥，默认椭圆曲线为 nist_p256 2.3.openssl ec-engine tpm2tss-inform engine-in ecckey-pubout 4.-outform pem-out ecckey.pub#导出 ECC 密钥公钥 5.6.cat ecckey.pub#读取公钥信息 7.-BEGIN PUBLIC KEY-8.MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwCUr6W94NwjHOQVoTdWQfxwXQ/qD 9.tuy2ZtDVL6yKkqnEJJZ0insTH uJyeM0o3qeuKuzmlY Qh053okXoA8t9w=10.-END PUBLIC KEY-1.tpm2_createprimary-C o-G ecc-c eccprimary.ctx 2.#创建 TPM2 ECC 算法 Primary Object 3.4.tpm2_create-C eccprimary.ctx-G ecc-u ecc.pub-r ecc.pri 5.#创建 TPM2 ECC 密钥 6.7.tpm2_load-C eccprimary.ctx-u ecc.pub-r ecc.pri-c ecc.ctx 8.#将 ECC 密钥导入 TPM2 芯片 9.10.tpm2_evictcontrol-C o-c ecc.ctx#将 ECC 密钥设置为持久对象 11.persistent-handle:0 x81000001 12.action:persisted 13.14.openssl ec-engine tpm2tss-inform engine-in 0 x81000001-pubout 15.-outform pem-out ecctpmkey.pub#导出 TPM2 中持久对象 0 x81000000 的公钥 16.engine tpm2tss set.17.read EC key 18.Enter password for user key:19.writing EC key 20.21.cat ecctpmkey.pub#读取公钥信息 22.-BEGIN PUBLIC KEY-23.MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEE16KNIBp/Ca7A3U38AKXcRh Ji0O 24.dSzdfR/ ogYfN/NjvlW18IhKZg0rO2PdIsS2V5neCnffzKwRiVK0CP/Xvw=25.-END PUBLIC KEY-1.echo 1234567890 mydata#创建被签名信息 2.3.openssl dgst-sha256-out mydata.sha256-binary mydata 4.#创建被签名信息的摘要值 5.6.openssl pkeyutl-engine tpm2tss-keyform engine-inkey ecckey-sign-in mydata.sha256-out mysig 7.#使用 tpm2tss-genkey 生成的密钥 ecckey 签名数据 8.9.openssl pkeyutl-engine tpm2tss-keyform engine-inkey ecckey-verify 10.-in mydata.sha256-sigfile mysig 11.#使用 tpm2tss-genkey 生成的密钥 ecckey 验证签名数据 12.engine tpm2tss set.13.Signature Verified Successfully 1.openssl pkeyutl-engine tpm2tss-keyform engine-inkey 0 x81000001 2.-sign-in mydata.sha256-out mysig#使用 TPM2 中持久对象 0 x81000001 签名数据 3.4.openssl pkeyutl-engine tpm2tss-keyform engine-inkey 0 x81000001 5.-verify-in mydata.sha256-sigfile mysig 6.engine tpm2tss set.7.Enter password for user key:8.Signature Verified Successfully 1.tpm2_createprimary-C o-G rsa2048-c rsaprimary.ctx#创建 TPM2 RSA 算法Primary Object 2.3.tpm2_create-C rsaprimary.ctx-G rsa2048-u rsa.pub-r rsa.pri 4.#创建 TPM2 RSA 密钥 5.6.tpm2_load-C rsaprimary.ctx-u rsa.pub-r rsa.pri-c rsa.ctx#将 RSA 密钥导入 TPM2芯片 7.8.tpm2_evictcontrol-C o-c rsa.ctx#将 RSA 密钥设置为持久对象 9.10.persistent-handle:0 x81000000 11.action:persisted 12.13.openssl req-new-x509-engine tpm2tss-keyform engine-key 0 x81000000 14.-out rsa.crt#使用 TPM2 芯片中持久对象 0 x81000000 生成自签名证书 15.engine tpm2tss set.16.Enter password for user key:17.You are about to be asked to enter information that will be incorporated 18.into your certificate request.19.What you are about to enter is what is called a Distinguished Name or a DN.20.There are quite a few fields but you can leave some blank 21.For some fields there will be a default value,22.If you enter.,the field will be left blank.23.-24.Country Name(2 letter code)XX:CN 25.State or Province Name(full name):Shandong 26.Locality Name(eg,city)Default City:Jinan 27.Organization Name(eg,company)Default Company Ltd:XX 28.Organizational Unit Name(eg,section):Anolis 29.Common Name(eg,your name or your servers hostname):TC 30.Email Address:31.32.openssl x509-in rsa.crt-text#查看证书详细信息 33.Certificate:34.Data:35.Version:3(0 x2)36.Serial Number:37.61:78:a3:3b:05:ec:e3:1a:ed:c0:a6:74:c5:ee:c6:60:22:7f:a5:53 38.Signature Algorithm:sha256WithRSAEncryption 39.Issuer:C=CN,ST=Shandong,L=Jinan,O=XX,OU=Anolis,CN=TC 40.Validity 41.Not Before:Aug 25 16:48:29 2023 GMT 42.Not After:Sep 24 16:48:29 2023 GMT 43.Subject:C=CN,ST=Shandong,L=Jinan,O=XX,OU=Anolis,CN=TC 44.Subject Public Key Info:45.Public Key Algorithm:rsaEncryption 46.RSA Public-Key:(2048 bit)47.Modulus:48.00:a8:27:60:bd:00:01:03:7c:d0:b4:4b:5e:44:92:49.75:fa:84:5a:8a:80:ad:17:da:e0:6d:96:e9:4e:6f:50.f6:b9:11:84:80:75:ab:66:2a:06:ce:db:59:8d:1f:51.f9:11:54:ba:45:0a:cb:be:da:39:83:53:c8:9f:39:52.9d:91:a7:37:03:9e:6a:dd:bd:89:86:e1:96:38:ff:53.8d:c5:97:d1:1c:da:16:59:dc:98:c7:48:0b:ed:9f:54.73:3f:b3:ac:8e:89:e2:c3:83:db:53:1d:9c:d3:a7:55.f1:ea:33:97:f2:2c:98:04:a8:b1:e9:61:29:d5:78:56.26:ad:d8:31:2f:d6:c6:c3:cf:87:63:4e:9d:2b:c0:57.d1:67:b9:15:51:8a:4d:a7:46:98:fe:d9:83:10:91:58.96:0e:54:cc:e7:77:05:73:0b:e9:f2:a0:18:b7:e4:59.b9:98:96:90:58:8f:6e:e4:01:e6:7e:78:91:07:df:60.04:2c:59:21:38:7e:05:56:27:2e:bf:af:77:d0:6c:61.e6:8c:d9:97:f9:0e:58:65:b0:da:d3:6f:f3:33:e2:62.c6:40:d3:9d:0c:ba:b6:78:5a:14:54:b1:89:09:9e:63.5f:d4:86:a0:d0:09:41:fa:67:4c:48:02:96:a8:a5:64.d5:f2:97:80:02:55:c1:b3:f2:b8:c2:32:82:1c:ed:65.2a:d9 66.Exponent:65537(0 x10001)67.X509v3 extensions:68.X509v3 Subject Key Identifier:69.09:34:FF:5E:CE:1F:7E:42:C3:3B:59:DA:A7:74:68:B1:65:C7:4B:28 70.X509v3 Authority Key Identifier:71.keyid:09:34:FF:5E:CE:1F:7E:42:C3:3B:59:DA:A7:74:68:B1:65:C7:4B:28 72.73.X509v3 Basic Constraints:critical 74.CA:TRUE 75.Signature Algorithm:sha256WithRSAEncryption 76.4d:02:e3:18:0f:63:1a:08:66:fb:b4:4a:86:f2:68:26:ce:bd:77.52:ac:e3:f3:95:fd:4f:44:31:f2:ce:40:33:61:a1:5e:59:67:78.76:c6:a8:4e:76:db:85:86:67:e4:ee:4c:fd:73:99:6c:12:21:79.bf:7a:71:b1:b4:ff:1a:ea:5a:f7:eb:3d:57:d7:d6:c7:73:db:80.dd:80:9f:95:ad:24:58:e5:dd:06:0a:47:c4:bc:22:2d:6c:54:81.99:1a:c9:6b:75:7e:a2:27:aa:cb:ab:4b:53:1b:be:33:08:7d:82.99:5d:67:4c:c7:4a:77:82:64:e1:30:3c:9d:17:be:88:a1:64:83.6a:c9:7e:ca:e5:48:f5:a2:cd:0e:8e:c9:9a:21:2c:fb:e4:56:84.ce:b1:cf:82:f4:b1:59:eb:a6:d8:0c:27:11:cb:2e:bf:d0:20:85.cc:d0:75:ef:12:af:34:2d:da:0d:cd:ea:a1:3c:0b:26:0f:0a:86.40:c6:9f:be:da:33:47:db:48:97:f5:5e:3b:4e:dd:3c:f8:d3:87.63:94:be:d4:98:c3:3f:8e:e7:71:85:30:71:1c:d4:0d:11:26:88.4c:ee:69:ce:18:2b:2c:16:8a:b8:02:9b:45:e9:ee:39:96:b4:89.76:93:56:e2:7c:c6:ab:1a:b0:89:c1:47:29:27:34:35:14:be:90.43:0e:92:16 91.-BEGIN CERTIFICATE-92.MIIDlzCCAn gAwIBAgIUYXijOwXs4xrtwKZ0 xe7GYCJ/pVMwDQYJKoZIhvcNAQEL 93.BQAwWzELMAkGA1UEBhMCQ04xETAPBgNVBAgMCFNoYW5kb25nMQ4wDAYDVQQHDAVK 94.aW5hbjELMAkGA1UECgwCWFgxDzANBgNVBAsMBkFub2xpczELMAkGA1UEAwwCVEMw 95.HhcNMjMwODI1MTY0ODI5WhcNMjMwOTI0MTY0ODI5WjBbMQswCQYDVQQGEwJDTjER 96.MA8GA1UECAwIU2hhbmRvbmcxDjAMBgNVBAcMBUppbmFuMQswCQYDVQQKDAJYWDEP 97.MA0GA1UECwwGQW5vbGlzMQswCQYDVQQDDAJUQzCCASIwDQYJKoZIhvcNAQEBBQAD 98.ggEPADCCAQoCggEBAKgnYL0AAQN80LRLXkSSdfqEWoqArRfa4G2W6U5v9rkRhIB1 99.q2YqBs7bWY0f RFUukUKy77aOYNTyJ85nZGnNwOeat29iYbhljj/jcWX0RzaFlnc 100.mMdIC 2fcz zrI6J4sOD21MdnNOn8eozl/IsmASoselhKdV4Jq3YMS/WxsPPh2NO 101.nSvA0We5FVGKTadGmP7ZgxCRlg5UzOd3BXML6fKgGLfkuZiWkFiPbuQB5n54kQff 102.BCxZITh BVYnLr vd9Bs5ozZl/kOWGWw2tNv8zPixkDTnQy6tnhaFFSxiQmeX9SG 103.oNAJQfpnTEgClqil1fKXgAJVwbPyuMIyghztKtkCAwEAAaNTMFEwHQYDVR0OBBYE 104.FAk0/17OH35CwztZ2qd0aLFlx0soMB8GA1UdIwQYMBaAFAk0/17OH35CwztZ2qd0 105.aLFlx0soMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAE0C4xgP 106.YxoIZvu0SobyaCbOvVKs4/OV/U9EMfLOQDNhoV5ZZ3bGqE5224WGZ TuTP1zmWwS 107.Ib96cbG0/xrqWvfrPVfX1sdz292An5WtJFjl3QYKR8S8Ii1sVJkayWt1fqInqsur 108.S1MbvjMIfZldZ0zHSneCZOEwPJ0XvoihZGrJfsrlSPWizQ6OyZohLPvkVs6xz4L0 109.sVnrptgMJxHLLr/QIMzQde8SrzQt2g3N6qE8CyYPCkDGn77aM0fbSJf1XjtO3Tz4 110.02OUvtSYwz O53GFMHEc1A0RJkzuac4YKywWirgCm0Xp7jmWtHaTVuJ8xqsasInB 111.RyknNDUUvkMOkhY=112.-END CERTIFICATE-1.openssl s_server-cert rsa.crt-key 0 x81000000-keyform engine 2.-engine tpm2tss-accept 8443#使用 TPM2 自签名证书创建 SSL 服务程序 4.1.$git clone https:/ 2.$cd hygon-devkit/tpm/pkg/tpm-1.0.0-20230331/3.$./install.sh 1.$git clone https:/ 2.$cd hygon-devkit/tdm/pkg/tdm-1.0.0-20230316/3.$make LOCAL_KERDIR=/lib/modules/uname-r/build 1.$sudo mkdir/boot/efi/bak 2.$sudo cp-fr/boot/efi/EFI/boot/efi/bak/3.$sudo cp-fr/boot/efi/boot/boot/efi/bak/4.$sudo grub2-install-efi-directory=/boot/efi-bootloader-id=anolis-boot-directory=/boot/efi/boot 5.-target=x86_64-efi-modules=tpm 6.$sudo grub2-mkconfig-o/boot/efi/boot/grub/grub.cfg 1.$wget https:/ftp.gnu.org/gnu/grub/grub-2.04.tar.gz 2.$tar-zxvf grub-2.04.tar.gz 3.$cd grub-2.04/4.$./bootstrap 5.$./configure-host=x86_64-linux-target=x86_64-with-platform=efi 6.$make 7.$sudo make install 8.$sudo cp/etc/default/grub/usr/local/etc/default/9.$sudo mkdir/boot/efi/bak 10.$sudo cp-fr/boot/efi/EFI/boot/efi/bak/11.$sudo cp-fr/boot/efi/boot/boot/efi/bak/12.$sudo/usr/local/sbin/grub-install-efi-directory=/boot/efi-bootloader-id=anolis 13.-boot-directory=/boot/efi/boot-target=x86_64-efi-modules=tpm 14.$sudo/usr/local/sbin/grub-mkconfig-o/boot/efi/boot/grub/grub.cfg 1.$sudo useradd-system-user-group tss 2.$sudo udevadm control-reload-rules&udevadm trigger 3.$sudo pkill-HUP dbus-daemon 4.$sudo systemctl daemon-reload 5.$sudo ldconfig 6.$sudo systemctl enable tpm2-abrmd 7.$sudo chown tss:tss/dev/tpm0 8.$sudo service tpm2-abrmd start 9.$systemctl status tpm2-abrmd.service 1.hygonlocalhost$tpm2_pcrread sm3_256:0,1,2,3,4,5,6,7,8,9,10,11 2.sm3_256:3.0:0 x5D25A693796A9D6060834A9FB0AF416E9C9FB4D47A22326BBC45686300B471A3 4.1:0 xFAC21DA05E1F8467972D6ABAF2CBED26FBB81B20A26A2751D32798EE574A7B1F 5.2:0 x0D72B0164E4FA67D6B43D3CB8EAD734737E479767E0D545EFF22C6FE6275B357 6.3:0 x0D72B0164E4FA67D6B43D3CB8EAD734737E479767E0D545EFF22C6FE6275B357 7.4:0 xA2381A4E30198BED49FB10A3D86274930B10D0EE788ED1121D1B83CF814362C9 8.5:0 xC71BED60766F8B89F6296C076F88E702B0E0474ACB8019AC8B8DB52E66E739ED 9.6:0 x0D72B0164E4FA67D6B43D3CB8EAD734737E479767E0D545EFF22C6FE6275B357 10.7:0 x2304AF3530A51BC03051BA7D3A2BB7B462120DF1B1D13BB55FA0B565831C19F4 11.8:0 xDEA0758622845043428A74802AABB23B53941CD216BA934FBFB5AF4D69FD7905 12.9:0 x2AEF34ABB0803C293AD390C2D9AB8B6D5FA9086E6A1ED4CD706FD 13.10:0 x0000000000000000000000000000000000000000000000000000000000000000 14.11:0 x0000000000000000000000000000000000000000000000000000000000000000 1.hygonlocalhost tests_gm$./test.sh 2.test_tpm2_activatecredential.sh.PASSED 3.test_tpm2_attest.sh.PASSED 4.test_tpm2_changeauth.sh.PASSED 5.test_tpm2_clock.sh.PASSED 6.test_tpm2_encryptdecrypt.sh.PASSED 7.test_tpm2_hash.sh.PASSED 8.test_tpm2_nv.sh.PASSED 9.test_tpm2_pcr.sh.PASSED 10.test_tpm2_policy.sh.PASSED 11.test_tpm2_random.sh.PASSED 12.test_tpm2_selftest.sh.PASSED 13.test_tpm2_sign.sh.PASSED 14.Tests passed:12 15.Tests Failed:0 1.tdm:Thread started for measurement exception handler dispatching.2.tdm:TDM driver loaded successfully!1.rootlocalhost hygon#hag tdm show_tdm_device 2.#TDM_SHOW_DEVICE#3.api_major :1 4.api_minor :4 5.buildId :1882 6.task_max :100 7.range_max_per_task:128 8.show tdm device successful.9.show_tdm_device command success!10.11.tdm Command successful!1.$sudo insmod tdm-verify.ko test_scene=0 1.$sudo rmmod tdm-verify.ko 1.$dmesg 1.-Victim module:has 3 blocks of data measured by PSP-test_scene:0 2.23048.936285 Call psp_create_measure_task to request measuring service.3.23048.936286 tdm:TDM:Cant get max_pfn,skip physical address check 4.23048.936964 Call psp_register_measure_exception_handler to register measuring exception function for task:0 5.23048.937059 Call psp_startstop_measure_task to start measuring for task:0 6.23048.980357 Call psp_create_measure_task to request measuring service.7.23048.980358 tdm:TDM:Cant get max_pfn,skip physical address check 8.23048.983682 Call psp_register_measure_exception_handler to register measuring exception function for task:1 9.23048.986755 Call psp_startstop_measure_task to start measuring for task:1 10.23049.035503 Call psp_create_measure_task to request measuring service.11.23049.035505 tdm:TDM:Cant get max_pfn,skip physical address check 12.23049.039294 Call psp_register_measure_exception_handler to register measuring exception function for task:2 13.23049.042308 Call psp_startstop_measure_task to start measuring for task:2 14.23059.357713 Call psp_startstop_measure_task to stop measuring for task:0 15.23059.402299 Call psp_destroy_measure_task to destroy measuring service for task:0 16.23059.406240 Call psp_startstop_measure_task to stop measuring for task:1 17.23059.451298 Call psp_destroy_measure_task to destroy measuring service for task:1 18.23059.457734 Call psp_startstop_measure_task to stop measuring for task:2 19.23059.502293 Call psp_destroy_measure_task to destroy measuring service for task:2 20.23059.502470 21.-end-1.$sudo insmod tdm-verify.ko test_scene=1 1.$sudo rmmod tdm-verify.ko 1.$dmesg 1.-Victim module:has 3 blocks of data measured by PSP-test_scene:1 2.23074.069910 Call psp_create_measure_task to request measuring service.3.23074.069911 tdm:TDM:Cant get max_pfn,skip physical address check 4.23074.070566 Call psp_register_measure_exception_handler to register measuring exception function for task:3 5.23074.070661 Call psp_startstop_measure_task to start measuring for task:3 6.23074.112871 Call psp_create_measure_task to request measuring service.7.23074.112872 tdm:TDM:Cant get max_pfn,skip physical address check 8.23074.116483 Call psp_register_measure_exception_handler to register measuring exception function for task:4 9.23074.119492 Call psp_startstop_measure_task to start measuring for task:4 10.23074.166990 Call psp_create_measure_task to request measuring service.11.23074.166992 tdm:TDM:Cant get max_pfn,skip physical address check 12.23074.170536 Call psp_register_measure_exception_handler to register measuring exception function for task:5 13.23074.173597 Call psp_startstop_measure_task to start measuring for task:5 14.23074.331699 Call psp_startstop_measure_task to stop measuring for task:3 15.23074.375645 Call psp_update_measure_task to update measuring for task:3 16.23074.377384 Call psp_startstop_measure_task to start measuring for task:3 17.23074.394873 tdm:-Measurement exception handler dispatching thread-18.23074.394874 tdm:Measurement exception received for task 3 19.23074.394875 tdm:Step1:Query PSP for task 3 status to confirm the error.20.23074.394876 tdm:Step2:Error confirmed,CALL measurement exception handler.21.23074.394926 Call psp_startstop_measure_task to stop measuring for task:4 22.23074.401037 tdm:Error detected for task 3,action TODO!23.23074.401039 tdm:-Measurement exception handler-24.23074.401040 ALARM!25.23074.401040 Task:3,corruption detected!26.23074.401041 Please check if its intended,or your machine may be on danger!27.23074.401041 tdm:Exit measurement exception handler.28.23074.439650 Call psp_update_measure_task to update measuring for task:4 29.23074.440293 Call psp_startstop_measure_task to start measuring for task:4 30.23074.454929 tdm:-Measurement exception handler dispatching thread-31.23074.454931 tdm:Measurement exception received for task 4 32.23074.454931 tdm:Step1:Query PSP for task 4 status to confirm the error.33.23074.454932 tdm:Step2:Error confirmed,CALL measurement exception handler.34.23074.454953 Call psp_startstop_measure_task to stop measuring for task:5 35.23074.458098 tdm:Error detected for task 4,action TODO!36.23074.458100 tdm:-Measurement exception handler-37.23074.458100 ALARM!38.23074.458101 Task:4,corruption detected!39.23074.458101 Please check if its intended,or your machine may be on danger!40.23074.458102 tdm:Exit measurement exception handler.41.23074.502635 Call psp_update_measure_task to update measuring for task:5 42.23074.502728 Call psp_startstop_measure_task to start measuring for task:5 43.23074.517418 tdm:-Measurement exception handler dispatching thread-44.23074.517420 tdm:Measurement exception received for task 5 45.23074.517420 tdm:Step1:Query PSP for task 5 status to confirm the error.46.23074.517421 tdm:Step2:Error confirmed,CALL measurement exception handler.47.23074.517477 tdm:Error detected for task 5,action TODO!48.23074.517478 tdm:-Measurement exception handler-49.23074.517478 ALARM!50.23074.517479 Task:5,corruption detected!51.23074.517479 Please check if its intended,or your machine may be on danger!52.23074.517479 tdm:Exit measurement exception handler.53.23076.730176 Call psp_destroy_measure_task to destroy measuring service for task:3 54.23076.730346 Call psp_destroy_measure_task to destroy measuring service for task:4 55.23076.730486 Call psp_destroy_measure_task to destroy measuring service for task:5 56.23076.730651 57.-end-1.$sudo insmod tdm-verify.ko test_scene=2 1.$sudo rmmod tdm-verify.ko 1.$dmesg 1.-Victim module:has 3 blocks of data measured by PSP-test_scene:2 2.23090.387377 Call psp_create_measure_task to request measuring service.3.23090.387378 tdm:TDM:Cant get max_pfn,skip physical address check 4.23090.388051 Call psp_register_measure_exception_handler to register measuring exception function for task:6 5.23090.388126 Call psp_startstop_measure_task to start measuring for task:6 6.23090.434179 Call psp_create_measure_task to request measuring service.7.23090.434181 tdm:TDM:Cant get max_pfn,skip physical address check 8.23090.437755 Call psp_register_measure_exception_handler to register measuring exception function for task:7 9.23090.440727 Call psp_startstop_measure_task to start measuring for task:7 10.23090.488312 Call psp_create_measure_task to request measuring service.11.23090.488314 tdm:TDM:Cant get max_pfn,skip physical address check 12.23090.491870 Call psp_register_measure_exception_handler to register measuring exception function for task:8 13.23090.494848 Call psp_startstop_measure_task to start measuring for task:8 14.23090.541148 Call psp_startstop_measure_task in scene2 to stop measuring for task:6 15.23090.551624 tdm:psp_startstop_measure_task exception error:0 x2 16.23091.574741 tdm:psp_startstop_measure_task exception error:0 x2 17.23091.577725 tdm:psp_startstop_measure_task exception error:0 x5 18.23091.580672 tdm:psp_startstop_measure_task exception error:0 x5 19.23093.614989 Call psp_startstop_measure_task in scene2 to stop measuring for task:7 20.23093.626034 tdm:psp_startstop_measure_task exception error:0 x2 21.23094.646682 tdm:psp_startstop_measure_task exception error:0 x2 22.23094.649850 tdm:psp_startstop_measure_task exception error:0 x5 23.23094.649913 tdm:psp_startstop_measure_task exception error:0 x5 24.23096.688192 Call psp_startstop_measure_task in scene2 to stop measuring for task:8 25.23096.695727 tdm:psp_startstop_measure_task exception error:0 x2 26.23097.720379 tdm:psp_startstop_measure_task exception error:0 x2 27.23097.720457 tdm:psp_startstop_measure_task exception error:0 x5 28.23097.723599 tdm:psp_startstop_measure_task exception error:0 x5 29.23103.104351 Call psp_destroy_measure_task to destroy measuring service for task:6 30.23103.104526 Call psp_destroy_measure_task to destroy measuring service for task:7 31.23103.104664 Call psp_destroy_measure_task to destroy measuring service for task:8 32.23103.104823 33.-end-4.6.TDM 度量任务通过虚拟地址创建运行销毁流程（1.3 固件版本后支持）1.$sudo insmod tdm-verify.ko test_scene=3 1.$sudo rmmod tdm-verify.ko 1.$dmesg 1.-Victim module:has 3 blocks of data measured by PSP-test_scene:3 2.23115.105615 Call psp_create_measure_task to request measuring service.3.23115.106269 Call psp_register_measure_exception_handler to register measuring exception function for task:9 4.23115.106351 Call psp_startstop_measure_task to start measuring for task:9 5.23115.151078 Call psp_create_measure_task to request measuring service.6.23115.154563 Call psp_register_measure_exception_handler to register measuring exception function for task:10 7.23115.157550 Call psp_startstop_measure_task to start measuring for task:10 8.23115.204366 Call psp_create_measure_task to request measuring service.9.23115.207533 Call psp_register_measure_exception_handler to register measuring exception function for task:11 10.23115.210041 Call psp_startstop_measure_task to start measuring for task:11 11.23117.109442 Call psp_startstop_measure_task to stop measuring for task:9 12.23117.153770 Call psp_destroy_measure_task to destroy measuring service for task:9 13.23117.157152 Call psp_startstop_measure_task to stop measuring for task:10 14.23117.200769 Call psp_destroy_measure_task to destroy measuring service for task:10 15.23117.204428 Call psp_startstop_measure_task to stop measuring for task:11 16.23117.247762 Call psp_destroy_measure_task to destroy measuring service for task:11 17.23117.247932 18.-end-1.$cd/lib/modules/uname-r/kernel/drivers/crypto/ccp/1.$sudo insmod tdm-verify.ko test_scene=4 验证流程如下：(1)假设 hag 工具已安装到/usr/bin/目录（具体路径请以安装为准）。(2)检查 hag 支持的 TDM 命令。1.rootlocalhost hygon#hag tdm-help 2.3.get_ak_cert get_tdm_report get_vPCR_audit show_tdm_device 4.parse_ak_cert verify_ak_cert parse_tdm_report verify_tdm_report 5.parse_vPCR_audit replay_vPCR_audit 6.7.tdm Command successful!(3)可以看到 TDM 支持 get_ak_cert、parse_ak_cert、veriry_ak_cert 三个与证书相关的命令，获取名字为 cert 的 AK 证书。结果如下所示，可以看到成功获取 ak.cert 的证书。1.rootlocalhost hygon#hag tdm get_ak_cert-out ak.cert 2.get tdm ak cert successful.3.get_ak_cert command success!4.5.tdm Command successful!6.rootlocalhost hygon#ls-l 7.总用量 4 8.-rw-r-r-1 root root 448 9 月 1 11:32 ak.cert (4)解析证书，主要将证书中的版本、chip_id、curve_id、公钥信息、证书签名等信息进行解析显示，方便用户了解证书中的内容。1.rootlocalhost hygon#hag tdm parse_ak_cert-in ak.cert 2.#TDM_CERT START#3.version:10000 4.5.chip_id_len:13 6.chip_id:7.0 x4e 0 x5a 0 x47 0 x46 0 x47 0 x30 0 x36 0 x31 0 x30 0 x31 0 x38 0 x30 0 x35 8.chip_id:NZGFG06101805 9.10.curve_id:3 11.qx:12.0 xb2 0 xcd 0 x0c 0 x07 0 x44 0 x61 0 x9d 0 x97 0 x00 0 xd0 0 xb9 0 x72 0 x65 0 xe3 0 x1a 0 xba 13.0 x21 0 x2d 0 x66 0 x40 0 x51 0 xe7 0 xf6 0 xac 0 x2f 0 x7d 0 xcb 0 x0c 0 x17 0 xd0 0 x8b 0 xb5 14.15.qy:16.0 x4a 0 x4b 0 xca 0 x88 0 xcb 0 x1d 0 xb1 0 x29 0 x2f 0 x4d 0 x50 0 xf6 0 x5c 0 xff 0 xa8 0 xdd 17.0 x1f 0 xcb 0 x4c 0 x09 0 x22 0 xf7 0 xe9 0 x5b 0 x9f 0 xe9 0 xd0 0 x8a 0 x5d 0 x0f 0 x45 0 xcd 18.19.user_id_len:15 20.user_id:21.0 x48 0 x59 0 x47 0 x4f 0 x4e 0 x2d 0 x53 0 x53 0 x44 0 x2d 0 x54 0 x44 0 x4d 0 x41 0 x4b 22.23.sig1_key_usage_id:0 x1004 24.sig1_r:25.0 x98 0 x3d 0 xeb 0 x96 0 x2e 0 x6f 0 xb8 0 xcf 0 xec 0 x5a 0 x0c 0 x5a 0 xaf 0 xf1 0 xb8 0 x2d 26.0 xdc 0 xaa 0 x55 0 x77 0 x01 0 xd0 0 x74 0 x1a 0 x66 0 x9e 0 x60 0 x3d 0 xa6 0 xf0 0 xec 0 x16 27.28.sig1_s:29.0 xd5 0 x09 0 x57 0 x7f 0 x54 0 x30 0 x0e 0 x8c 0 x7c 0 xf3 0 x34 0 x06 0 xc4 0 xa5 0 xd1 0 x46 30.0 xaf 0 x67 0 xbc 0 x8d 0 xb7 0 x19 0 xfd 0 xb5 0 xf1 0 xdc 0 x54 0 x0a 0 x41 0 xde 0 x16 0 x51 31.32.sig2_key_usage_id:0 x1000 33.sig2_r:34.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 35.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 36.37.sig2_s:38.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 39.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 40.41.ak cert origin data:42.0 x00 0 x00 0 x01 0 x00 0 x00 0 x00 0 x0d 0 x00 0 x4e 0 x5a 0 x47 0 x46 0 x47 0 x30 0 x36 0 x31 43.0 x30 0 x31 0 x38 0 x30 0 x35 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 44.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 45.0 x01 0 x20 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x03 0 x00 0 x00 0 x00 46.0 xb2 0 xcd 0 x0c 0 x07 0 x44 0 x61 0 x9d 0 x97 0 x00 0 xd0 0 xb9 0 x72 0 x65 0 xe3 0 x1a 0 xba 47.0 x21 0 x2d 0 x66 0 x40 0 x51 0 xe7 0 xf6 0 xac 0 x2f 0 x7d 0 xcb 0 x0c 0 x17 0 xd0 0 x8b 0 xb5 48.0 x4a 0 x4b 0 xca 0 x88 0 xcb 0 x1d 0 xb1 0 x29 0 x2f 0 x4d 0 x50 0 xf6 0 x5c 0 xff 0 xa8 0 xdd 49.0 x1f 0 xcb 0 x4c 0 x09 0 x22 0 xf7 0 xe9 0 x5b 0 x9f 0 xe9 0 xd0 0 x8a 0 x5d 0 x0f 0 x45 0 xcd 50.0 x0f 0 x00 0 x48 0 x59 0 x47 0 x4f 0 x4e 0 x2d 0 x53 0 x53 0 x44 0 x2d 0 x54 0 x44 0 x4d 0 x41 51.0 x4b 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 52.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 53.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 54.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 55.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 56.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 57.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 58.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 59.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x04 0 x10 0 x00 0 x00 60.0 x98 0 x3d 0 xeb 0 x96 0 x2e 0 x6f 0 xb8 0 xcf 0 xec 0 x5a 0 x0c 0 x5a 0 xaf 0 xf1 0 xb8 0 x2d 61.0 xdc 0 xaa 0 x55 0 x77 0 x01 0 xd0 0 x74 0 x1a 0 x66 0 x9e 0 x60 0 x3d 0 xa6 0 xf0 0 xec 0 x16 62.0 xd5 0 x09 0 x57 0 x7f 0 x54 0 x30 0 x0e 0 x8c 0 x7c 0 xf3 0 x34 0 x06 0 xc4 0 xa5 0 xd1 0 x46 63.0 xaf 0 x67 0 xbc 0 x8d 0 xb7 0 x19 0 xfd 0 xb5 0 xf1 0 xdc 0 x54 0 x0a 0 x41 0 xde 0 x16 0 x51 64.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 65.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x10 0 x00 0 x00 66.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 67.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 68.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 69.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 70.71.#TDM_CERT END#72.parse tdm ak cert successful.73.parse_ak_cert command success!74.75.tdm Command successful!(5)验证证书链 1.rootlocalhost hygon#hag tdm verify_ak_cert-in ak.cert 2.-2023-09-01 11:34:24-https:/ 3.正在解析主机 ().172.23.18.50 4.正在连接 ()|172.23.18.50|:443.已连接。5.已发出 HTTP 请求，正在等待回应.200 OK 6.长度：2916(2.8K)binary 7.正在保存至:“hsk_cek.cert”8.9.hsk_cek.cert 100%=10.=2.85K -.-KB/s 用时 0s 11.12.2023-09-01 11:34:24(104 MB/s)-已保存“hsk_cek.cert”2916/2916)13.14.-2023-09-01 11:34:24-https:/ 15.正在解析主机 ().172.23.18.50 16.正在连接 ()|172.23.18.50|:443.已连接。17.已发出 HTTP 请求，正在等待回应.200 OK 18.长度：832 binary 19.正在保存至:“hrk.cert”20.21.hrk.cert 100%=22.=832 -.-KB/s 用时 0s 23.24.2023-09-01 11:34:24(51.0 MB/s)-已保存“hrk.cert”832/832)25.26.hrk pubkey verify hrk cert successful 27.hrk pubkey verify hsk cert successful 28.hsk pubkey verify cek cert successful 29.30.rootlocalhost hygon#ls-l 31.总用量 20 32.-rw-r-r-1 root root 448 9 月 1 11:32 ak.cert 33.-rw-r-r-1 root root 2084 9 月 1 11:34 cek.cert 34.-rw-r-r-1 root root 832 9 月 1 11:34 hrk.cert 35.-rw-r-r-1 root root 2916 9 月 1 11:34 hsk_cek.cert 36.-rw-r-r-1 root root 832 9 月 1 11:34 hsk.cert (6)可以看到成功验证了 TDM 的证书链，该验证方式主要通过从 AK 证书中获取的 chip_id，到证书服务器下载其对应的 CEK 证书、HSK 证书、HRK证书，通过从根证书一级一级验证到 AK 证书。1.$sudo insmod tdm-verify.ko test_scene=1 (4)获取并查看用户提供的随机数文件：1.$dd if=/dev/random of=user_data.bin bs=32 count=1 2.$hexdump user_data.bin 1.rootlocalhost hygon#hag tdm get_tdm_report-report_file report.bin-report_type 1 2.-user_data_file user_data.bin 3.#Report type :1#4.#Report task id:0 xffffffff#5.get tdm report successful.6.get_tdm_report command success!7.8.tdm Command successful!9.rootlocalhost hygon#ls-l 10.总用量 28 11.-rw-r-r-1 root root 448 9 月 1 11:32 ak.cert 12.-rw-r-r-1 root root 2084 9 月 1 11:34 cek.cert 13.-rw-r-r-1 root root 832 9 月 1 11:34 hrk.cert 14.-rw-r-r-1 root root 2916 9 月 1 11:34 hsk_cek.cert 15.-rw-r-r-1 root root 832 9 月 1 11:34 hsk.cert 16.-rw-r-r-1 root root 448 9 月 1 11:45 report.bin 17.-rw-r-r-1 root root 32 9 月 1 11:45 user_data.bin 结果如下：1.rootlocalhost hygon#hag tdm parse_tdm_report-report_file report.bin 2.#TDM_REPORT START#3.#version:0 x10000 4.#fw_version:1882 5.#report_type:1 6.#task_nums:3 7.#task_bitmap:8.0 xe0 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 9.10.#task_error_bitmap:11.0 xe0 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 12.13.#task_running_bitmap:14.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 15.16.#user_supplied_data_len:32 17.#user_supplied_data:18.0 x63 0 xd6 0 xae 0 x11 0 xd9 0 x20 0 xff 0 x64 0 xac 0 x7a 0 xd9 0 x30 0 xe4 0 x9d 0 x0a 0 xeb 19.0 xad 0 x84 0 x0c 0 x39 0 x3a 0 x8d 0 x05 0 x3c 0 x0e 0 x8d 0 x08 0 x76 0 x30 0 x5f 0 x45 0 xd3 20.21.#aggregate_hash:22.0 x0f 0 x68 0 xc1 0 x01 0 x3e 0 xd9 0 x4b 0 x33 0 x7c 0 x77 0 xf8 0 x1f 0 xde 0 x9f 0 x49 0 xa3 23.0 xff 0 x76 0 xad 0 x40 0 x4b 0 xeb 0 xe4 0 x37 0 xe4 0 x80 0 x35 0 x5c 0 x03 0 x6e 0 x34 0 x60 24.25.*26.#task_id:15 27.#perios_ms:0 28.#measured_count:30 29.#last_measure_elapsed_ms:32071 30.#measured_hash:31.0 x69 0 x20 0 xde 0 x37 0 x20 0 xc7 0 x9e 0 x44 0 xba 0 x82 0 x7b 0 xcb 0 x4a 0 x72 0 xc7 0 xbd 32.0 xac 0 xe6 0 xd4 0 xf2 0 xe2 0 xf5 0 xd3 0 x06 0 x84 0 x46 0 x51 0 x12 0 x1f 0 x8c 0 xd7 0 xde 33.34.*35.#task_id:16 36.#perios_ms:0 37.#measured_count:24 38.#last_measure_elapsed_ms:32000 39.#measured_hash:40.0 x7d 0 x49 0 x86 0 x8a 0 x49 0 xc5 0 xdd 0 xd3 0 xa3 0 x3b 0 x6b 0 x42 0 x16 0 x75 0 xc6 0 x87 41.0 x78 0 xf9 0 x16 0 x36 0 x33 0 x91 0 xc0 0 x6e 0 x47 0 xbd 0 x5f 0 x55 0 x21 0 xba 0 xcb 0 xe9 42.43.*44.#task_id:17 45.#perios_ms:0 46.#measured_count:29 47.#last_measure_elapsed_ms:31946 48.#measured_hash:49.0 xe8 0 x45 0 xd4 0 x8e 0 xc1 0 x3f 0 x0c 0 xc8 0 xf5 0 x22 0 x8b 0 xf5 0 xe2 0 x25 0 x5e 0 x8e 50.0 xd7 0 x9e 0 xdd 0 x04 0 x72 0 xcb 0 xa4 0 x0d 0 x2b 0 xa4 0 xc4 0 x4c 0 x7d 0 xe2 0 xb5 0 x3e 51.52.*53.54.#sig_key_usage_id:0 x2001 55.#sig_r:56.0 x3b 0 x4a 0 xd3 0 xac 0 xae 0 xb0 0 x8e 0 x55 0 xa9 0 xb4 0 xf3 0 x5e 0 x66 0 x86 0 xf4 0 x23 57.0 xd2 0 x5d 0 x60 0 x1a 0 xee 0 x02 0 x88 0 xea 0 xc4 0 x29 0 xf0 0 x17 0 xcf 0 x82 0 x5c 0 x01 58.59.#sig_s:60.0 xc4 0 x96 0 x5f 0 xfb 0 xe9 0 xfc 0 x76 0 xd7 0 x6d 0 xea 0 xf5 0 x65 0 x83 0 x7c 0 x8f 0 x0c 61.0 xa5 0 xb1 0 x1b 0 x7e 0 xae 0 xde 0 x9f 0 x58 0 xde 0 xfd 0 xb6 0 xb0 0 xd6 0 x6f 0 x13 0 xc6 62.63.report origin data:64.0 x00 0 x00 0 x01 0 x00 0 x5a 0 x07 0 x00 0 x00 0 x01 0 x00 0 x00 0 x00 0 x00 0 x00 0 x03 0 x00 65.0 xe0 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 66.0 xe0 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 67.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 68.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 69.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x20 0 x00 70.0 x63 0 xd6 0 xae 0 x11 0 xd9 0 x20 0 xff 0 x64 0 xac 0 x7a 0 xd9 0 x30 0 xe4 0 x9d 0 x0a 0 xeb 71.0 xad 0 x84 0 x0c 0 x39 0 x3a 0 x8d 0 x05 0 x3c 0 x0e 0 x8d 0 x08 0 x76 0 x30 0 x5f 0 x45 0 xd3 72.0 x0f 0 x68 0 xc1 0 x01 0 x3e 0 xd9 0 x4b 0 x33 0 x7c 0 x77 0 xf8 0 x1f 0 xde 0 x9f 0 x49 0 xa3 73.0 xff 0 x76 0 xad 0 x40 0 x4b 0 xeb 0 xe4 0 x37 0 xe4 0 x80 0 x35 0 x5c 0 x03 0 x6e 0 x34 0 x60 74.0 x0f 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x1e 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 75.0 x47 0 x7d 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 76.0 x69 0 x20 0 xde 0 x37 0 x20 0 xc7 0 x9e 0 x44 0 xba 0 x82 0 x7b 0 xcb 0 x4a 0 x72 0 xc7 0 xbd 77.0 xac 0 xe6 0 xd4 0 xf2 0 xe2 0 xf5 0 xd3 0 x06 0 x84 0 x46 0 x51 0 x12 0 x1f 0 x8c 0 xd7 0 xde 78.0 x10 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x18 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 79.0 x00 0 x7d 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 80.0 x7d 0 x49 0 x86 0 x8a 0 x49 0 xc5 0 xdd 0 xd3 0 xa3 0 x3b 0 x6b 0 x42 0 x16 0 x75 0 xc6 0 x87 81.0 x78 0 xf9 0 x16 0 x36 0 x33 0 x91 0 xc0 0 x6e 0 x47 0 xbd 0 x5f 0 x55 0 x21 0 xba 0 xcb 0 xe9 82.0 x11 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x1d 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 83.0 xca 0 x7c 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 84.0 xe8 0 x45 0 xd4 0 x8e 0 xc1 0 x3f 0 x0c 0 xc8 0 xf5 0 x22 0 x8b 0 xf5 0 xe2 0 x25 0 x5e 0 x8e 85.0 xd7 0 x9e 0 xdd 0 x04 0 x72 0 xcb 0 xa4 0 x0d 0 x2b 0 xa4 0 xc4 0 x4c 0 x7d 0 xe2 0 xb5 0 x3e 86.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 87.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x01 0 x20 0 x00 0 x00 88.0 x3b 0 x4a 0 xd3 0 xac 0 xae 0 xb0 0 x8e 0 x55 0 xa9 0 xb4 0 xf3 0 x5e 0 x66 0 x86 0 xf4 0 x23 89.0 xd2 0 x5d 0 x60 0 x1a 0 xee 0 x02 0 x88 0 xea 0 xc4 0 x29 0 xf0 0 x17 0 xcf 0 x82 0 x5c 0 x01 90.0 xc4 0 x96 0 x5f 0 xfb 0 xe9 0 xfc 0 x76 0 xd7 0 x6d 0 xea 0 xf5 0 x65 0 x83 0 x7c 0 x8f 0 x0c 91.0 xa5 0 xb1 0 x1b 0 x7e 0 xae 0 xde 0 x9f 0 x58 0 xde 0 xfd 0 xb6 0 xb0 0 xd6 0 x6f 0 x13 0 xc6 92.93.#TDM_REPORT END#94.parse tdm report successful.95.parse_tdm_report command success!96.97.tdm Command successful!结果如下：1.rootlocalhost hygon#hag tdm verify_tdm_report-ak_cert ak.cert-report_file report.bin 2.verify tdm report successful.3.verify_tdm_report command success!4.5.tdm Command successful!(10)$sudo rmmod tdm-verify.ko 基本验证流程如下：1.hygonlocalhost hygon$tpm2_pcrread sm3_256 2.sm3_256:3.0:0 x5D25A693796A9D6060834A9FB0AF416E9C9FB4D47A22326BBC45686300B471A3 4.1:0 xFAC21DA05E1F8467972D6ABAF2CBED26FBB81B20A26A2751D32798EE574A7B1F 5.2:0 x0D72B0164E4FA67D6B43D3CB8EAD734737E479767E0D545EFF22C6FE6275B357 6.3:0 x0D72B0164E4FA67D6B43D3CB8EAD734737E479767E0D545EFF22C6FE6275B357 7.4:0 xA2381A4E30198BED49FB10A3D86274930B10D0EE788ED1121D1B83CF814362C9 8.5:0 xC71BED60766F8B89F6296C076F88E702B0E0474ACB8019AC8B8DB52E66E739ED 9.6:0 x0D72B0164E4FA67D6B43D3CB8EAD734737E479767E0D545EFF22C6FE6275B357 10.7:0 x2304AF3530A51BC03051BA7D3A2BB7B462120DF1B1D13BB55FA0B565831C19F4 11.8:0 xDEA0758622845043428A74802AABB23B53941CD216BA934FBFB5AF4D69FD7905 12.9:0 x2AEF34ABB0803C293AD390C2D9AB8B6D5FA9086E6A1ED4CD706FD 13.10:0 x0000000000000000000000000000000000000000000000000000000000000000 14.11:0 x0000000000000000000000000000000000000000000000000000000000000000 15.12:0 x0000000000000000000000000000000000000000000000000000000000000000 16.13:0 x0000000000000000000000000000000000000000000000000000000000000000 17.14:0 x0000000000000000000000000000000000000000000000000000000000000000 18.15:0 x0000000000000000000000000000000000000000000000000000000000000000 19.16:0 x8E4D2AD793AEDBA2DBFE2AE09F0A49727988DFE8F460923A75B524A7FE9CFD80 20.17:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 21.18:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 22.19:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 23.20:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 24.21:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 25.22:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 26.23:0 x0000000000000000000000000000000000000000000000000000000000000000 1.$sudo insmod tdm-verify.ko test_scene=1 1.hygonlocalhost hygon$tpm2_pcrread sm3_256 2.sm3_256:3.0:0 x5D25A693796A9D6060834A9FB0AF416E9C9FB4D47A22326BBC45686300B471A3 4.1:0 xFAC21DA05E1F8467972D6ABAF2CBED26FBB81B20A26A2751D32798EE574A7B1F 5.2:0 x0D72B0164E4FA67D6B43D3CB8EAD734737E479767E0D545EFF22C6FE6275B357 6.3:0 x0D72B0164E4FA67D6B43D3CB8EAD734737E479767E0D545EFF22C6FE6275B357 7.4:0 xA2381A4E30198BED49FB10A3D86274930B10D0EE788ED1121D1B83CF814362C9 8.5:0 xC71BED60766F8B89F6296C076F88E702B0E0474ACB8019AC8B8DB52E66E739ED 9.6:0 x0D72B0164E4FA67D6B43D3CB8EAD734737E479767E0D545EFF22C6FE6275B357 10.7:0 x2304AF3530A51BC03051BA7D3A2BB7B462120DF1B1D13BB55FA0B565831C19F4 11.8:0 xDEA0758622845043428A74802AABB23B53941CD216BA934FBFB5AF4D69FD7905 12.9:0 x2AEF34ABB0803C293AD390C2D9AB8B6D5FA9086E6A1ED4CD706FD 13.10:0 x67B124D86989268B92A26FBB88CF440FD6157475BB5472A27ADEB0D77843FDB9 14.11:0 xC4D7DDA8900CA0F784F36D9C8C95039244E842CB3FE73B5AFCCE521872D41D3F 15.12:0 x2E2D1C8F7759D7CFB57004C007FC22EB3DB340AF7CAE90D5668E3AEA5A33F6D2 16.13:0 x0000000000000000000000000000000000000000000000000000000000000000 17.14:0 x0000000000000000000000000000000000000000000000000000000000000000 18.15:0 x0000000000000000000000000000000000000000000000000000000000000000 19.16:0 x8E4D2AD793AEDBA2DBFE2AE09F0A49727988DFE8F460923A75B524A7FE9CFD80 20.17:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 21.18:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 22.19:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 23.20:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 24.21:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 25.22:0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 26.23:0 x0000000000000000000000000000000000000000000000000000000000000000 1.rootlocalhost hygon#hag tdm get_vPCR_audit-audit_file audit.bin-pcr_num 11 2.#PCR number :11#3.get vPCR audit successful.4.get_vPCR_audit command success!5.6.tdm Command successful!1.rootlocalhost hygon#hag tdm parse_vPCR_audit-audit_file audit.bin 2.#TDM_VPCR_AUDIT START#3.#pcr:11 4.#tpm2_digest:5.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 6.0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 0 x00 7.8.*9.#task_id:19 10.#hash:11.0 x7d 0 x49 0 x86 0 x8a 0 x49 0 xc5 0 xdd 0 xd3 0 xa3 0 x3b 0 x6b 0 x42 0 x16 0 x75 0 xc6 0 x87 12.0 x78 0 xf9 0 x16 0 x36 0 x33 0 x91 0 xc0 0 x6e 0 x47 0 xbd 0 x5f 0 x55 0 x21 0 xba 0 xcb 0 xe9 13.14.*15.#TDM_VPCR AUDIT END#16.parse vPCR audit successful.17.parse_vPCR_audit command success!1.rootlocalhost hygon#hag tdm replay_vPCR_audit-vPCR_file audit.bin 2.#TDM_VPCR_AUDIT_REPLAY START#3.#replay pcr:11 4.VPCR hash:5.0 xc4 0 xd7 0 xdd 0 xa8 0 x90 0 x0c 0 xa0 0 xf7 0 x84 0 xf3 0 x6d 0 x9c 0 x8c 0 x95 0 x03 0 x92 6.0 x44 0 xe8 0 x42 0 xcb 0 x3f 0 xe7 0 x3b 0 x5a 0 xfc 0 xce 0 x52 0 x18 0 x72 0 xd4 0 x1d 0 x3f 7.8.#TDM_VPCR_AUDIT_REPLAY END#9.replay vPCR audit successful.10.replay_vPCR_audit command success!11.12.tdm Command successful!1.$sudo rmmod tdm-verify.ko keylime 概述 Keylime Keylime AgentKeylime RegistrarKeylime VerifierVM/裸金属/容器vTPM/TPMPublic Key store/Agent RegistrationVerifier checks agent integrityRemote machine in cloud:needs to prove its integrity using TPM quote with KeylimeKeylime checks integrity of remote machinesUntrustednetwork 龙蜥社区在 keylime 社区的工作与探索 keylime release notesrust-keylime 开源软件名称 总计 commit 数量 总计修改行数 rust-keylime 3-19/ 20 keylime 14-24/ 156 龙蜥 Anolis OS 上 keylime 用途与实践 用 Restful API 去监控/管理 Anolis OS 上的各个 keylime 组件Anolis OS 上 keylime 安装与配置、运行 keylimecd keylime&./installer.sh-i rust-keylime：包含 keylime 的 agent 组件；tpm2-tss 软件包tpm2-tools 软件包 yum install-y libarchive-devel clang-devel rust cargo openssl-devel jq git clone https:/ cd rust-keylime cargo build make install useradd keylime mkdir-p/var/lib/keylime/cv_ca#将 keylime verifier 机器上的/var/lib/keylime/cv_ca/cacert.crt 拷贝到 agent#机器上/var/lib/keylime/cv_ca/目录下，以便于后续 Agent 侧 https RESTful APIs 的访问 chown-R keylime/var/lib/keylime /etc/keylime/verifier.conf/etc/keylime/registrar.conf/etc/keylime/agent.conf/etc/keylime/tenant.conf 3)cd keylime 4)./services/installer.sh 5)systemctl start keylime_verifier 6)systemctl start keylime_registrar 7)systemctl start keylime_agent Anolis OS 上 keylime 高级功能实践 1.keylime_tenant-v 121.43.60.253-t 120.26.100.138 2.-uuid d432fbb3-d2f1-4a97-9ef7-75bd81c00000 3.-tpm_policy 15:0000000000000000000000000000000000000000,4.0000000000000000000000000000000000000000000000000000000000000000,5.00000000000000000000000000000000000000000000000000000000000000000000000000 6.0000000000000000000000 7.-c add-cert/var/lib/keylime/cv_ca 1.DEBUG keylime_agent:quotes_handler Calling Integrity Quote with nonce:lCYwDxi2UkTIWM6Fk2aH,mask:0 x408000 2.INFO keylime_agent:quotes_handler GET integrity quote returning 200 response 3.INFO actix_web:middleware:logger GET 4./v2.1/quotes/integrity?nonce=lCYwDxi2UkTIWM6Fk2aH&mask=0 x408000&partial=1&ima_ml_entry=0 5.HTTP/1.1 from 121.43.60.253 result 200(took 1229.894715 ms)6.INFO keylime_agent GET invoked from 121.43.60.253 with uri 7./v2.1/quotes/integrity?nonce=WSn8mEpGLjN5I8mhHjPn&mask=0 x408000&partial=1&ima_ml_entry=0 AgentVerifier发送quote（包含PCRs信息）和/sys/kernel/security/tpm0/binary_bios_measurements里面的boot log12重放boot log来验证PCRs（0-9，11-14）是否正确3根据measured boot policy，比较boot log跟measured boot reference state是否一致 1.cd keylime 2./scripts/create_mb_refstate 3.-i/sys/kernel/security/tpm0/binary_bios_measurements 4./measured_boot_reference_state.json 5.cat./measured_boot_reference_state.json|jq.1.keylime_tenant-c update-t 120.26.100.138-v 121.43.60.253 2.-u d432fbb3-d2f1-4a97-9ef7-75bd81c00000 3.-mb_refstate./measured_boot_reference_state.json 4.-cert/var/lib/keylime/cv_ca 1.INFO keylime_agent GET invoked from 121.43.60.253 with uri 2./v2.1/quotes/integrity?nonce=EiRTFv9tgNBmwy6HwxAC&mask=0 xfbff&partial=1&ima_ml_entry=0 3.DEBUG keylime_agent:quotes_handler Calling Integrity Quote with nonce:EiRTFv9tgNBmwy6HwxAC,mask:0 xfbff 4.INFO keylime_agent:quotes_handler GET integrity quote returning 200 response 5.INFO actix_web:middleware:logger GET 6./v2.1/quotes/integrity?nonce=EiRTFv9tgNBmwy6HwxAC&mask=0 xfbff&partial=1&ima_ml_entry=0 7.HTTP/1.1 from 121.43.60.253 result 200(took 1452.270707 ms)1.keylime_create_policy-m/sys/kernel/security/ima/ascii_runtime_measurements-o runtime_policy.json 2.cat runtime_policy.json|jq.1.keylime_tenant-c update-uuid d432fbb3-d2f1-4a97-9ef7-75bd81c00000 2.-t 120.26.100.138-v 121.43.60.253-runtime-policy/root/runtime_policy.json 3.-runtime-policy-name=tpm-cert/var/lib/keylime/cv_ca 1.#curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt 3.-k https:/127.0.0.1:8881/v2.1/allowlists/tpm|jq.4.5.code:200,6.status:Success,7.results:8.name:tpm,9.tpm_policy:null,10.runtime_policy:.11.监控 IMA 错误 1.2023-09-07 15:20:10.295-keylime.tpm-INFO-Checking IMA measurement list on agent:2.d432fbb3-d2f1-4a97-9ef7-75bd81c00000 3.2023-09-07 15:20:10.295-keylime.ima-WARNING-Hashes for file boot_aggregate dont match 4.1aa841ace294d93414158a2f070c92d078c464da0110269d3ad1e59367cdc285 not in 5.fd2cf72bae331c6ba3db242e04f65ad5ca5c9da3f94dd5c78f5e56496e7cf0da 6.2023-09-07 15:20:10.296-keylime.ima-ERROR-IMA ERRORS:Some entries couldnt be validated.Number of 7.failures in modes:ImaSig 1.8.2023-09-07 15:20:10.357-keylime.verifier-WARNING-Agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000 failed,9.stopping polling 用 Restful API 去监控/管理 Anolis OS 上的各个 keylime 组件 GET/v2.1/agents/1.#curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt 3.-k https:/127.0.0.1:8891/v2.1/agents|jq.4.5.code:200,6.status:Success,7.results:8.uuids:9.d432fbb3-d2f1-4a97-9ef7-75bd81c00000 10.11.12.GET/v2.1/agents/agent_id:UUID 1.#curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt 3.-k https:/127.0.0.1:8891/v2.1/agents/d432fbb3-d2f1-4a97-9ef7-75bd81c00000|jq.4.5.code:200,6.status:Success,7.results:8.9.ip:121.43.60.253,10.port:9002,11.regcount:1 12.13.PUT/v2.1/agents/agent_id:UUID/activate 1.#curl-k 2.-X PUT http:/127.0.0.1:8890/v2.1/agents/d432fbb3-d2f1-4a97-9ef7-75bd81c00000/activate 3.-H Content-Type:application/json 4.-d auth_tag:166be150040c57b4e2c69ad7a5dd4c57059e5838a1df4715872f6e385e8ce1ed91 5.|jq.6.7.code:200,8.status:Success,9.results:10.DELETE/v2.1/agents/agent_id:UUID 1.#curl-k 2.-X PUT http:/127.0.0.1:8890/v2.1/agents/d432fbb3-d2f1-4a97-9ef7-75bd81c00000/activate 3.-H Content-Type:application/json 4.-d auth_tag:166be150040c57b4e2c69ad7a5dd4c57059e5838a1df4715872f6e385e8ce1ed91 5.|jq.6.7.code:200,8.status:Success,9.results:10.11.#curl-key/var/lib/keylime/cv_ca/client-private.pem 12.-cert/var/lib/keylime/cv_ca/client-cert.crt 13.-k https:/127.0.0.1:8891/v2.1/agents|jq.14.15.code:200,16.status:Success,17.results:18.uuids:19.20.POST/v2.1/agents/agent_id:UUID 1.#curl-X POST http:/127.0.0.1:8890/v2.1/agents/d432fbb3-d2f1-4a97-9ef7-75bd81c00000 2.-H Content-Type:application/json 3.-d ekcert:MIIE3DCCA8SgAwIBAgIBBDANBgkqhkiG9w0BAQsFADBvMQswCQYDVQQGEwJDTjEPMA0GA1UECgwGQWxpeXVuMTIwMA 4.aik_tpm:ARgAAQALAAUAcgAAABAAFAALCAAAAAAAAQC7R7SiAAExqqCZJ60cTJXxcYMCRsctsh96vX/f2T31DMrB6SnCMV9euHlMUCUs 5.ip:127.0.0.1,port:9002|jq.6.7.code:200,8.status:Success,9.10.11.#curl-key/var/lib/keylime/cv_ca/client-private.pem-cert/var/lib/keylime/cv_ca/client-cert.crt 12.-k https:/127.0.0.1:8891/v2.1/agents|jq.13.14.code:200,15.status:Success,16.results:17.uuids:18.d432fbb3-d2f1-4a97-9ef7-75bd81c00000 19.20.21.GET/v2.1/agents/agent_id:UUID agent_id1.#curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt 3.-k https:/127.0.0.1:8881/v2.1/agents/d432fbb3-d2f1-4a97-9ef7-75bd81c00000|jq.4.5.code:200,6.status:Success,7.results:8.9.hash_alg:sha256,10.enc_alg:rsa,11.sign_alg:rsassa,12.verifier_id:default,13.verifier_ip:121.43.60.253,14.verifier_port:8881,15.severity_level:6,16.17.PUT/v2.1/agents/agent_id:UUID/stop agent_id1.#curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt-k 3.-X PUT https:/127.0.0.1:8881/v2.1/agents/d432fbb3-d2f1-4a97-9ef7-75bd81c00000/stop 4.|jq.5.6.code:200,7.status:Success,8.results:9.DELETE/v2.1/agents/agent_id:UUID 1.#curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt 3.-k-X DELETE https:/127.0.0.1:8881/v2.1/agents/d432fbb3-d2f1-4a97-9ef7-75bd81c00000 4.|jq.5.6.code:200,7.status:Success,8.results:9.10.#curl-key/var/lib/keylime/cv_ca/client-private.pem 11.-cert/var/lib/keylime/cv_ca/client-cert.crt 12.-k https:/121.0.0.1:8881/v2.1/agents/d432fbb3-d2f1-4a97-9ef7-75bd81c00000|jq.13.14.code:404,15.status:agent id not found,16.results:17.GET/v2.1/allowlists/runtime_policy_name:string 1.curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt-k 3.https:/127.0.0.1:8881/v2.1/allowlists/tpm|jq.4.5.code:200,6.status:Success,7.results:8.name:tpm,9.tpm_policy:null,10.runtime_policy:.11.12.1.#curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt-k 3.https:/127.0.0.1:8881/v2.1/allowlists/test|jq.4.5.code:404,6.status:Runtime policy test not found,7.results:8.DELETE/v2.1/allowlist/runtime_policy_name:string runtime_policy_nametpm1.#curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt 3.-k https:/127.0.0.1:8881/v2.1/allowlists/tpm|jq.4.5.code:200,6.status:Success,7.results:8.name:tpm,9.tpm_policy:null,10.runtime_policy:.11.12.13.#curl-key/var/lib/keylime/cv_ca/client-private.pem 14.-cert/var/lib/keylime/cv_ca/client-cert.crt-X DELETE 15.-k https:/127.0.0.1:8881/v2.1/allowlists/tpm|jq.16.#curl-key/var/lib/keylime/cv_ca/client-private.pem 17.-cert/var/lib/keylime/cv_ca/client-cert.crt 18.-k https:/127.0.0.1:8881/v2.1/allowlists/test|jq.19.20.code:404,21.status:Runtime policy test not found,22.results:23.1.#curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt-X DELETE 3.-k https:/127.0.0.1:8881/v2.1/allowlists/test|jq.4.5.code:404,6.status:Runtime policy test not found,7.results:8.GET/version 1.#curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt-k 3.https:/127.0.0.1:9002/version|jq.4.5.code:200,6.status:Success,7.results:8.supported_version:2.1 9.10.GET/v2.1/keys/pubkey 1.#curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt-k 3.https:/127.0.0.1:9002/v2.1/keys/pubkey|jq.4.5.code:200,6.status:Success,7.results:8.pubkey:.9.10.GET/v2.1/quotes/identity 1.#curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt-k 3.https:/127.0.0.1:9002/v2.1/quotes/identity?nonce=1234567890ABCDEFHIJ 4.|jq.5.6.code:200,7.status:Success,8.results:9.quote:.10.hash_alg:sha256,11.enc_alg:rsa,12.sign_alg:rsassa,13.pubkey:.14.15.GET/v2.1/quotes/integrity 1.#curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt-k 3.https:/127.0.0.1:9002/v2.1/quotes/integrity?nonce=1234567890&mask=0 x10401&partial=0 4.5.code:200,6.status:Success,7.results:8.quote:.9.hash_alg:sha256,10.enc_alg:rsa,11.sign_alg:rsassa,12.pubkey:.13.ima_measurement_list:.14.mb_measurement_list:.15.ima_measurement_list_entry:0 16.17.GET/v2.1/keys/verify 1.#curl-key/var/lib/keylime/cv_ca/client-private.pem 2.-cert/var/lib/keylime/cv_ca/client-cert.crt-k 3.https:/127.0.0.1:9002/v2.1/keys/verify?challenge=1234567890ABCDEFHIJ|jq.4.5.code:400,6.status:Bootstrap key not yet available.,7.results:8.本节以一个未受保护的 loopback-mounted 文件系统为例，介绍如何通过TPM 增强基于 luks 磁盘加密的安全防护能力。1.#创建磁盘镜像，写入内容 2.#如下命令，我们在磁盘中添加了名为 plain.txt 的文件，该文件包含的内容为“this is my plain text”3.dd if=/dev/zero of=plain.disk bs=1M count=10 4.mkfs.ext4 plain.disk 5.mkdir mountpoint 6.sudo mount plain.disk mountpoint 7.sudo sh-c echo This is my plain text mountpoint/plain.txt 8.sudo umount mountpoint 9.10.#可以通过简单的 linux 命令(如下所示）即可查看文件内容 11.strings plain.disk 1.#创建一个新的 luks 卷，使用简单的密码口令作为该卷的保护密钥 2.dd if=/dev/zero of=enc.disk bs=1M count=50 3.dd if=/dev/urandom of=disk.key bs=1 count=32 4.sudo losetup/dev/loop0 enc.disk 5.sudo cryptsetup-key-file=disk.key luksFormat/dev/loop0 6.7.#基于上述方案加密后，磁盘中的文件不再可见、起到了一定的保护作用，采用如下命令无法查看明文信息 8.strings enc.disk|grep-i plain 1.#创建并保存一个密封对象，并使用它来密封一个随机字节序列作为磁盘密钥:2.tpm2_createprimary-Q-hierarchy=o-key-context=prim.ctx 3.dd if=/dev/urandom bs=1 count=32 status=none|tpm2_create-hash-algorithm=sha256-public=seal.pub-private=seal.priv-sealing-input=-parent-context=prim.ctx 4.tpm2_load-Q-parent-context=prim.ctx-public=seal.pub-private=seal.priv-name=seal.name-key-context=seal.ctx 5.tpm2_evictcontrol-hierarchy=o-object-context=seal.ctx 0 x81010002 6.7.#安装新密钥以取代旧密钥，并删除之前创建的旧密钥:8.tpm2_unseal-Q-object-context=0 x81010002|sudo cryptsetup-key-file=disk.key luksChangeKey enc.disk 9.shred disk.key 10.rm-f disk.key 11.12.#用 TPM 中密封的新身份验证挂载卷:13.sudo losetup/dev/loop0 enc.disk 14.tpm2_unseal-Q-object-context=0 x81010002|sudo cryptsetup-key-file=-luksOpen/dev/loop0 enc_volume 15.sudo mount/dev/mapper/enc_volume mountpoint 16.17.#磁盘访问被授予新的秘密:18.ls mountpoint 19.20.#卸载磁盘：21.22.sudo umount mountpoint 23.sudo cryptsetup remove enc_volume 24.sudo losetup-d/dev/loop0 1.#在 sha256 bank 中创建一个当前值为 PCR0 的 PCR 策略:2.tpm2_startauthsession-session=session.ctx 3.tpm2_policypcr-Q-session=session.ctx-pcr-list=sha256:0-policy=pcr0.sha256.policy 4.tpm2_flushcontext session.ctx 5.6.#现在将 TPM 非易失性内存中保护磁盘加密密钥的密封对象替换为一个新对象，该对象添加了我们刚刚创建的 pcr 策略，作为访问密封密钥的身份验证机制:7.tpm2_unseal-object-context=0 x81010002|tpm2_create-Q-hash-algorithm=sha256-public=pcr_seal_key.pub-private=pcr_seal_key.priv-sealing-input=-parent-context=prim.ctx-policy=pcr0.sha256.policy 8.tpm2_evictcontrol-hierarchy=o-object-context=0 x81010002 9.tpm2_load-Q-parent-context=prim.ctx-public=pcr_seal_key.pub-private=pcr_seal_key.priv-name=pcr_seal_key.name-key-context=pcr_seal_key.ctx 10.tpm2_evictcontrol-hierarchy=o-object-context=pcr_seal_key.ctx 0 x81010002 11.12.#现在尝试再次挂载加密磁盘，只不过这次密钥被密封在 TPM 对象中，其解密封操作只能通过满足PCR 策略来访问。换句话说，通过 PCR 值所反映的预期系统软件状态不变来进行身份验证。13.sudo losetup/dev/loop0 enc.disk 14.tpm2_startauthsession-policy-session-session=session.ctx 15.tpm2_policypcr-Q-session=session.ctx-pcr-list=sha256:0-policy=pcr0.sha256.policy 16.17.#此时，理想情况下，您希望在内存中解开秘密，并将其直接管道到 cryptsetup，如下所示:“tpm2_unsealauth=session:session。object-context=0 x81010002|sudo cryptsetup luksOpenkey-file=-/dev/loop0 encvolume”。18.#但是，为了在下一节演示灵活 PCR，我们将复制未密封的秘密:19.tpm2_unseal-auth=session:session.ctx-object-context=0 x81010002 disk_secret.bkup 20.cat disk_secret.bkup|sudo cryptsetup-key-file=-luksOpen/dev/loop0 enc_volume 21.tpm2_flushcontext session.ctx 22.sudo mount/dev/mapper/enc_volume mountpoint/23.ls mountpoint/24.25.#为了防止进一步开封，PCR0 将被延长。这将导致 PCR0 保持不同的值，就像在固件替换攻击期间一样。这将导致策略检查失败，从而导致打开尝试失败。26.#延长前观察 PCR 状态，延长后再次观察:27.tpm2_pcrread-sel-list=sha256:0 28.tpm2_pcrextend 0:sha256=0000000000000000000000000000000000000000000000000000000000000000 29.tpm2_pcrread-sel-list=sha256:0 30.31.#尝试用脏 PCR 打开密封的磁盘加密密匙:32.tpm2_startauthsession-policy-session-session=session.ctx 33.tpm2_policypcr-Q-session=session.ctx-pcr-list=sha256:0-policy=pcr0.sha256.policy 34.35.#以下操作将导致策略检查失败，从而阻止开封操作:36.tpm2_unseal-auth=session:session.ctx-object-context=0 x81010002 37.tpm2_flushcontext session.ctx 38.39.#卸载磁盘：40.sudo umount mountpoint 41.sudo cryptsetup remove enc_volume 42.sudo losetup-d/dev/loop0 1.openssl genrsa-out signing_key_private.pem 2048 2.openssl rsa-in signing_key_private.pem-out signing_key_public.pem-pubout 1.tpm2_startauthsession-session=session.ctx 2.tpm2_policypcr-Q-session=session.ctx-pcr-list=sha256:0-policy=set2.pcr.policy 3.tpm2_flushcontext session.ctx 4.openssl dgst-sha256-sign signing_key_private.pem-out set2.pcr.signature set2.pcr.policy 1.#在将 LUKS 加密密码口令密封到 TPM 之前，有必要创建一个策略对象，该对象指定可以解封密码口令的条件。该策略将指定一组特定的 pcr(PCR0)必须与使用特定密钥(signing_key_public.pem)签名的值匹配:2.tpm2_loadexternal-key-algorithm=rsa-hierarchy=o-public=signing_key_public.pem-key-context=signing_key.ctx-name=signing_key.name 3.tpm2_startauthsession-session=session.ctx 4.tpm2_policyauthorize-session=session.ctx-policy=authorized.policy-name=signing_key.name 5.tpm2_flushcontext session.ctx 6.7.#通过使用上述策略创建一个密封对象，将密码口令密封到 TPM。请注意，由于前面的示例扩展了PCR0 以防止密码口令的重新解密，因此使用了密码口令的备份副本:8.cat disk_secret.bkup|tpm2_create-hash-algorithm=sha256-public=auth_pcr_seal_key.pub-private=auth_pcr_seal_key.priv-sealing-input=-parent-context=prim.ctx-policy=authorized.policy 9.10.#用上面创建的对象替换旧的持久密封对象:11.tpm2_evictcontrol-hierarchy=o-object-context=0 x81010002 12.tpm2_load-Q-parent-context=prim.ctx-public=auth_pcr_seal_key.pub-private=auth_pcr_seal_key.priv-name=auth_pcr_seal_key.name-key-context=auth_pcr_seal_key.ctx 13.tpm2_evictcontrol-hierarchy=o-object-context=auth_pcr_seal_key.ctx 0 x81010002 1.#加载公钥、PCR 策略和签名，并要求 TPM 验证签名:2.tpm2_loadexternal-key-algorithm=rsa-hierarchy=o-public=signing_key_public.pem-key-context=signing_key.ctx-name=signing_key.name 3.tpm2_verifysignature-key-context=signing_key.ctx-hash-algorithm=sha256-message=set2.pcr.policy-signature=set2.pcr.signature-ticket=verification.tkt-format=rsassa 4.5.#现在请 TPM 验证 PCR 值是否与当前值匹配，并为签名验证传递一个验证票据。请注意，一次只能验证一组 PCR 值:整个过程必须重复，以便尝试验证另一组签名 PCR 值:6.tpm2_startauthsession-policy-session-session=session.ctx 7.tpm2_policypcr-pcr-list=sha256:0-session=session.ctx-policy=set2.pcr.policy 8.tpm2_policyauthorize-session=session.ctx-input=set2.pcr.policy-name=signing_key.name-ticket=verification.tkt 9.10.#解锁加密密码口令并解锁卷:11.sudo losetup/dev/loop0 enc.disk 12.tpm2_unseal-auth=session:session.ctx-object-context=0 x81010002|sudo cryptsetup-key-file=-luksOpen/dev/loop0 enc_volume 13.tpm2_flushcontext session.ctx 14.sudo mount/dev/mapper/enc_volume mountpoint/15.ls mountpoint/16.17.#卸载卷 18.sudo umount mountpoint 19.sudo cryptsetup remove enc_volume 20.sudo losetup-d/dev/loop0 1.h_ek_persistent_ecc=0 x81010002 2.3.tpm2_createak-C$h_ek_persistent_ecc-G ecc-g sm3_256 4.-s sm2-c ak_ecc.ctx-u ak_ecc.pub-n ak_ecc.name-T device 1.#grub2 系列所有组件（如 grub2、grbu2-common、grub2-efi-x64 等）均需部署 2.rpm-ivh grub2-xxx.anolis.x86_64.rpm 3.rpm-ivh iTrustMidware-3.0.1-20220827200013.kos.x86_6.rpm 1.tlcptool 2.1.Check Policy State.3.2.Turn on Supervisory Policy.4.3.Update Supervisory Policy.5.4.Turn on Interception Policy.6.5.Update Interception Policy.7.6.Turn off Policy.8.7.Export BootLoader Passphrase.9.8.Deploy Measurement File.10.9.Update Measurement File.11.10.Delete Measurement File.12.11.Export Software Trusted Report.13.O.Exit.14.Please Input the Corresponding Operations.61.0 0d818d47f8b7.S-CRTM Version 2.0 b16790da86a8.POST CODE 3.7 c3e86209704b.EV_EFI_VARIABLE_DRIVER_CONFIG SecureBoot 4.5.8 c9eef8824efb.IPL grub_cmd set gfx_payload=keep 6.8 6a1007c86dc8.IPL grub_cmd insmod gzio 7.8 eb204c91fc3d.IPL grub_cmd linux(hd0,gpt2)/vmlinuz-4.18.0 root=/dev/sda2 ro 8.9 3e9ff31a4687.IPL grub_linuxefi Kernel 9.8 603cfbaa8375.IPL grub_cmd initrd(hd0,gpt2)/initramfs-4.18.0.img 10.9 f0ba7132ccea.IPL grub_linuxefi Initrd RSA SHA256 AESECDSA SHA256 AES 3)

0人已浏览 2023-12-01 193页 5星级