简介这份PDF文档是《5G新型智慧城市-信创白皮书2021》聚焦数字经济与国产化替代大背景面向信创产业从业者、规划决策者及技术研究者系统梳理信息技术应用创新产业的演进脉络与实践路径。内容从全球IT生态格局与“十四五”高质量发展切入围绕信创政策、行业趋势、愿景内涵、整体架构、应用场景和典型案例展开重点介绍中国移动在信创领域的生态赋能实践包括生态实验室、信创示范营业厅以及党政、金融等重点行业的国产化迁移策略为理解核心技术“卡脖子”问题提供了多角度参考。资源为单个PDF文件共6.49MB便于直接阅读与重点摘录。目前已有479人学习下载。读者可借此快速掌握信创产业政策导向、关键环节国产软硬件适配方法及5G智慧城市融合方案适合用于行业调研、方案编写或知识普及。1. 先别急着翻页5G-信创白皮书2021.pdf 到底值不值得读做政企项目的人手上多半会收到这样一份 PDF标题是“5G-信创白皮书2021”文件不小封面挺正式但翻开之后容易懵——它不像协议规范那样逐条可查也不像产品手册那样直接对着下单。它更像一份“地图”把 5G 通信系统和信创底座之间的关系按规划、建设、运维三个阶段重新梳理了一遍。你真正能从中拿到的不是某一款设备的参数而是一套判断依据哪些 5G 组件在信创体系里能直接用哪些要适配哪些短期根本替代不了。这份白皮书适合集成商售前、政企信息化负责人、院校实训室建设牵头人读目的是在立项和选型之前先用一份公开材料把技术边界和替代深度对齐避免方案做到一半才发现底座选错。2. 读这本白皮书的三个前置判断时间、边界与阅读视角拿任何一份 PDF 当工作依据第一步都不是翻正文而是搞清楚它的“坐标系”在哪里。5G-信创白皮书2021这份文档从标题就能拆出三个前提时间是 2021 年对象是 5G 和信创两个技术域的结合载体是“白皮书”这种非强制、偏方向性的文档。把这三点想清楚后面读起来才不会把方向性描述当成硬性标准。2.1 2021 这个时间点5G 规模建网与信创落地阶段的交汇处2021 年前后5G 正处于从“规模建网”转向“行业应用”的窗口期运营商网络建设已经铺开行业侧开始关注 5G 到底能给垂直场景带来什么信创这边则从“目录清单”逐步走向“适配落地”各地项目从办公系统替换延伸到更复杂的基础设施。这个交汇点决定了白皮书里讨论的 5G不会只讲峰值速率和空口技术它一定会把“信创”作为约束条件写进方案里。读者容易犯的一个错是用 2025 年的产业状态去套 2021 年的结论。比如白皮书里提到的国产化替代深度、可采购设备范围、适配产品的成熟度都是基于当时的产业供给。2021 年可行的替代方案放到今天可能已经有了更优选择反过来2021 年标注“暂不可替代”的组件今天可能已经出现可用的国产选项。所以读这份 PDF 的第一步是在阅读时标注“数据时点”把每个结论都当成“截至 2021 年的状态”而不是永久结论。另一个容易忽略的点是“信创”二字的时空差异。不同年份、不同省份对信创目录的界定不完全一致白皮书里列出的分类和名录可能与读者所在地区的现行目录有出入。读的时候要把白皮书当方法论把当地最新目录当事实依据两者对照而不是只信其中一个。2.2 白皮书的技术边界协议栈、接入网、核心网与终端的覆盖范围从标题看5G-信创白皮书2021覆盖的是 5G 技术栈在信创体系下的落地可能性这意味着它至少会涉及四个层面5G 协议栈空口和上层信令、接入网设备形态AAU/DU/CU、核心网控制面与用户面、以及终端侧的通信能力。不同的读者对这四个层面的关注点完全不同白皮书通常不会平均用力而是按可替代性权重来分配篇幅。读这份文档时我一般会在纸上画一条横向链路终端 → 空口 → 基站AAU/DU/CU→ 承载网 → 核心网 → 应用平台。然后沿着链路逐个标“信创替代度”。终端侧看芯片和通信模组空口看物理层算法和射频器件接入网看通用服务器和操作系统核心网看 NFV 架构下的虚拟化层应用平台看国产数据库和中间件适配。白皮书的作用就是告诉你这条链路上哪些环节已经具备替代条件、哪些还在依赖特定硬件或闭源算法。这里要特别提醒白皮书不是协议规范。它不会像 3GPP 标准那样逐条定义 RRC 状态迁移或 MAC 调度的时序也不会像设备安装指导书那样告诉你 AAU 的抱杆扭矩。它是一份导读材料帮你建立“5G 系统有哪些可替换部件”的整体认知。真到调试协议或用设备做配置的时候还得回到具体的标准文档和设备手册。能分清“方向性描述”和“可执行规范”是读这类资料的基本功。2.3 写给三类读者的三种读法规划、建设与运维同一份白皮书不同角色读出来的东西完全不一样。做规划的人关心的是“信创 5G 网络能覆盖哪些业务场景”读的时候重点放在技术能力清单和部署架构上把白皮书里提到的应用场景与自己的业务需求做映射做建设的人关心的是“设备怎么选、机房怎么改、布线怎么做”读的时候要盯着设备形态、接口类型、部署条件这些工程信息做运维的人关心的是“适配怎么测、安全怎么管、故障怎么查”读的时候要把白皮书里关于信创适配及安全管理的内容单独抽出来形成自己的检查清单。我见过最常见的阅读失误是三类需求互相混淆。售前拿白皮书里的场景描述去回答实施问题实施人员拿白皮书里的架构图去回答运维问题最后项目交付时才发现口径对不上。白皮书的定位本来就是“给出统一语境”它适合作为项目启动时的对齐材料而不适合作为某一方的工作手册。如果你正在负责一个信创 5G 项目的立项建议先组织项目组把白皮书快速过一遍每个人写下自己关注的部分再开会对齐这样后续工作才会有共同参照物。3. 把 5G 拆成信创改造点协议栈、AAU/DU/CU 与核心网换底5G 是一套庞大系统信创改造不可能一次性全做完。实际项目中最常见的做法是把 5G 技术栈按“替代难度”分成三档能直接替换的通用软硬件、需要深度适配的协议和算法层、以及短期内必须依赖存量供应链的专用器件。白皮书的价值恰恰在于帮你完成这个分类。下面按协议栈、接入网设备、核心网和终端三个维度来拆。3.1 5G 协议栈详解信创视角下最关心的四个层级5G 协议栈通常按从下到上分为物理层、MAC/RLC/PDCP、RRC以及上层应用。从信创改造的角度看越往上层越靠近软件替代成本相对可控越往下层越依赖硬件算法和专用芯片适配难度显著上升。以 RRC 层为例它负责连接管理、移动性管理和系统消息广播逻辑上是一个典型的状态机软件只要按协议规范实现理论上可以运行在任何 RTOS 或嵌入式 Linux 环境上信创改造的主要工作集中在操作系统选型和编译工具链适配。PDCP 层负责加解密和头压缩这里会涉及密码算法而密码算法在信创体系里有明确的合规要求改造时不是“能不能实现”的问题而是“算法和密钥管理是否合规”的问题。再往下到 MAC 层涉及调度器、HARQ、逻辑信道优先级管理实时性要求高通常需要绑定特定硬件平台做性能调优这部分改造往往要连同底层加速器件一起评估。物理层则是重灾区信道编解码、FFT、波束管理这些计算密集算法通常跑在 FPGA 或专用加速器上信创替代的可行路径是“通用处理器 加速卡”的异构方案。实际拆解时我习惯把协议栈画成一张五层表格每一列标出“替代难度”“主要改造对象”“风险点”。这比泛泛读白皮书有用得多。表格大概是这样协议层级主要功能信创改造重点风险点物理层编解码、调制、波束管理加速硬件、底层算法库实时性能验证周期长MAC 层调度、HARQ、信道映射实时操作系统、驱动适配时延抖动难达标RLC/PDCP分段、重传、加解密密码算法、内存管理合规审查卡进度RRC连接管理、移动性管理操作系统、软件框架状态机测试用例多这张表的落点是白皮书里讲“信创 5G 设备”你真正实施的时候要追问到具体层级。只说“支持信创 CPU”是不够的还要问清楚支持到协议栈哪一层、物理层算法跑在什么硬件上、密码模块是否通过合规检测。能问出这三个问题说明白皮书读到位了。3.2 AAU/DU/CU 的安装与选型算力底座怎么换5G 接入网从形态上分成三类设备AAU有源天线处理单元、DU分布式单元和 CU集中式单元。这个划分不仅是功能上的更是部署位置和算力需求上的。AAU 靠近天线负责射频收发和部分物理层处理环境条件苛刻通常部署在室外或塔顶DU 负责实时性要求高的协议栈处理一般放在边缘机房CU 负责非实时的 RRC 和 PDCP 层以及和核心网的接口可以集中部署。从信创改造的角度看三类设备的改造空间完全不同。AAU 里包含大量射频器件、功放和天线阵列这些属于通信专用硬件短期内国产化替代的主要方式是器件国产化设备整机形态不会因为信创而改变你很难在 AAU 里“换掉操作系统”因为大多数射频处理根本不跑通用操作系统。DU 和 CU 的情况不一样它们越来越多地基于通用计算平台构建运行在 x86 或 ARM 服务器上配合加速卡完成高性能计算这就给信创改造留出了空间替换 CPU、替换操作系统、替换数据库甚至在虚拟化层注入国产云平台。在“5G 设备 AAU/DU/CU 安装指导书”这类文档里看到的基本是机械安装、线缆连接、上电调测这些内容但把视角切到信创上来选型时就多了一个维度算力底座的自主可控程度。我一般会要求供应商在投标时明确三件事——DU/CU 的计算芯片型号、操作系统版本、以及加速卡是否支持信创生态的驱动。这三个参数直接决定了设备能否纳入信创目录也决定了后期运维时补丁和安全加固能不能跟上。这部分白皮书只会给方向不会给选型清单真正落到纸面上要靠采购需求文档去约束。3.3 5G 核心网与终端的信创化两张清单怎么勾核心网是 5G 系统里信创改造优先级最高、也最容易出成绩的部分。因为 5G 核心网从标准制定之初就走 NFV网络功能虚拟化路线控制面和用户面功能都跑在通用服务器上天然适合叠加信创底座。一个典型的信创 5G 核心网会包含国产服务器、国产操作系统、国产中间件以及基于这些基础软件运行的 AMF、SMF、UPF 等网元。网元软件本身是 5G 协议栈的一部分厂商需要做的是把原来的 Linux 依赖换成信创环境并重新完成性能测试。做核心网信创化时要分清两张清单。第一张是“网元功能清单”包括 AMF接入和移动性管理、SMF会话管理、UPF用户面功能、PCF策略控制等这张清单决定你部署哪些逻辑网元。第二张是“基础设施清单”包括服务器型号、操作系统、虚拟化平台、数据库、监控系统这张清单决定你用什么底座去承载网元。很多项目在评审时会发现网元清单没问题但基础设施清单里有一项不满足信创目录要求导致整个方案被卡住。所以读白皮书时建议把核心网部分单独抽出来对照着列这两张表缺什么一目了然。终端侧则是另一番景象。5G 终端涉及芯片、基带、射频前端、操作系统、应用生态其中基带芯片是技术门槛最高的环节信创化的难度不在软件而在半导体工艺和 IP 积累。白皮书在终端部分通常只能给出产业趋势和生态建议很难给出短期可执行的替换路径。落到实际项目里终端信创往往是从行业终端如工业网关、CPE、车载终端切入而不是从手机切入因为行业终端的应用生态可控、批量小、定制程度高更容易走通适配和认证流程。4. 用白皮书反向映射信创目录适配清单与实训场景落地读完技术拆解下一步就是把白皮书里提到的设备形态、软件组件映射到信创产品目录上。这个环节最考验经验因为白皮书不会给你一张“信创 5G 采购清单”它只提供技术描述而信创目录又是按产品品类组织的两者之间存在一个翻译过程。做不好这个翻译方案评审时就会被一句“这个设备不在名录里”打回来。4.1 信创产品目录里与 5G 相关的三类条目各地信创产品目录虽然存在差异但大体上分为基础硬件、基础软件、应用软件和信息安全几类。与 5G 建设相关的条目通常集中在三类里面。第一类是整机与服务器对应 DU/CU 和核心网运行的硬件平台关注点包括 CPU 型号、内存扩展能力、支持的操作系统版本第二类是操作系统与数据库对应协议栈软件和核心网网元的运行环境关注点在于是否通过兼容性认证以及厂商是否提供针对该系统的调优支持第三类是网络安全设备对应 5G 网络的信令安全和数据安全防护关注点包括防火墙、入侵检测、日志审计等产品是否支持 5G 接口和协议解析。做映射时我常用的方法是把白皮书里的技术组件按“硬件层、软件层、安全层”三列铺开然后逐一去信创目录里查对应条目。能直接匹配的标注候选产品不能匹配的标注“需适配/需专项测试”。这个过程也会暴露白皮书的一个特点它对技术形态的描述偏理想化而信创目录是现实清单两者之间常有落差。比如白皮书推荐的虚拟化平台可能不在目录里但同生态的另一个版本在——这时候就需要做兼容性确认而不是简单替换。另外要提醒的是信创目录是动态更新的白皮书 2021 年出版时基于的目录和当前目录一定不同。所以做映射时要以当地主管部门发布的最新目录为准白皮书只作为理解产品关系的参考。一个实用的习惯是每次项目启动前重新拉一遍现行目录的增量变化看看是否有新增的 5G 相关品类。4.2 家庭 5G 网络布线与 5G 实训室方案白皮书转成工程图纸的两种典型做法白皮书虽然以系统级视角为主但也经常被用来指导具体的网络设计和场景建设。两种最常见的转化是家庭/小型办公场景的 5G 网络布线以及院校的 5G 实训室建设。这两个场景刚好处于规模的两个极端前者小到一台 CPE 就能解决后者大到需要一套完整的核心网和接入网设备。家庭或小型办公场景布置 5G 网络时核心设备是 5G CPE客户终端设备它把 5G 信号转成 Wi-Fi 或有线网络。这个场景里白皮书能提供的帮助是“信号覆盖的基本判断方法”——先确认室外 5G 基站的覆盖方向和强度再决定 CPE 挂在哪个位置、天线朝向哪里、网线走哪条路径。实际操作中经常遇到的情况是用户把 CPE 放在窗边但信号仍不理想原因是窗户玻璃镀膜对信号衰减明显或者 CPF 天线方向刚好背对基站。这时候调整天线朝向比增加放大器更有效也是“5G 天线参数”里最值得关注的方位角和增益两个指标。5G 实训室则完全是另一套逻辑。院校建实训室采购的不只是设备而是一套可以用来教学和科研的完整环境。一个常见方案是“核心网 基站 终端”的小型化部署核心网跑在国产服务器和操作系统上基站用一体化小基站终端用 5G CPE 或测试终端再配一套信令分析软件。白皮书在这里的作用是帮你确认实训室的拓扑结构与真实 5G 网络的一致性——教学场景不要求设备容量大但要求协议流程完整、信令可见、接口开放。搭建时还要预留出不少于 20% 的机柜空间用于后续扩展因为在实训过程中经常需要加装边缘计算节点或额外的核心网网元。这两个场景看起来差别很大但共通的要点是白皮书只告诉你“系统由哪些部分组成”而工程落地需要你自己补齐“具体放哪里、线怎么走、电怎么供、网络怎么管”。如果你带着白皮书去和弱电施工方沟通对方大概率听不懂你需要先把白皮书的内容翻译成弱电图纸——标清楚设备位置、网线类型、供电方式、接地要求施工方才能动手。4.3 信创适配与安全管理验收前最容易延迟的两个动作信创项目验收有一个显著特点功能测试往往很顺利但适配性测试和安全检查往往会消耗比预期多得多的时间。这背后是两个常被低估的动作——兼容性适配和合规性检查。兼容性适配的典型场景是核心网网元软件在新装的国产操作系统上能启动但运行一段时间后出现内存泄漏或性能下降。原因是厂商原来的开发测试环境是 CentOS 或 Ubuntu切换到信创操作系统之后内核参数、库文件版本、驱动行为都有差异这些差异在短时间功能测试里看不出来只有在长稳测试中才会暴露。解决的方法不是等出了问题再调而是在项目计划里提前安排“适配性专项测试”周期至少从两周起步内容包括压力测试、长稳测试、故障注入、重启恢复。安全管理的场景则更复杂。5G 网络本身就有信令风暴、用户面滥用等安全风险叠加信创环境之后又增加了供应链安全、漏洞管理、日志合规等新要求。白皮书在安全部分通常会给出原则性要求但验收时主管部门是按具体标准来查的——日志留存多久、密码算法用什么、远程运维通道是否加密、安全审计是否覆盖所有网元每一项目都要有据可查。如果你在方案阶段没有为这些工作预留时间和预算到验收阶段就很容易出现“功能全部达标安全检查没过”的尴尬局面。我的一般做法是在项目排期里把“信创适配及安全管理”单独作为一个里程碑来管理而不是把它塞在测试阶段的最后一周。5. 5G-信创白皮书2021阅读与落地避坑五个易翻车的判断围绕这份白皮书过去几年里我在项目评审和方案复核中反复见过几类问题。这些问题不一定是白皮书本身写错了更多是读者使用方式出了问题。把它们列出来算是给后来者的一份“踩坑地图”。5.1 现象把 2021 年的数据当作 2025 年的决策依据项目讨论时有人拿出白皮书里的性能指标或替代清单言之凿凿地说“白皮书里写了可以国产化替代”。但这份白皮书的出版时间是 2021 年技术迭代和产业供给在这几年间变化非常大特别是芯片供给、操作系统版本和适配工具链。原因白皮书天然是一个时间切片的快照它反映的是 2021 年产业可达的状态不是永恒的承诺。任何技术文档都有时效性白皮书尤甚。解决引用白皮书数据时一定带上“截至 2021 年”的前置说明做采购决策之前用当前信创目录和厂商最新适配清单复核一遍。把白皮书当“历史基线”用而不是当“现行标准”用。5.2 现象把白皮书里的指标当成验收标准白皮书里会出现“核心网用户面时延 XX 毫秒”“系统可用性达到 XX%”这类指标。有人直接把这类数值抄进招标文件作为硬性验收标准。原因白皮书指标通常来自理想环境下的实验室测试或厂商提供的数据没有附带测试条件、网络拓扑和配置参数。它描述的是能力上限不是工程承诺。解决如果真的需要性能指标应该要求投标方提供“在指定拓扑和配置下的实测数据”并在验收方案中明确测试工具、测试时长、负载模型。白皮书的数值只能作为参考区间不能作为合同条款。5.3 现象按图索骥把白皮书里的产品分类当成信创目录有人照着白皮书里的分类去采购结果发现部分产品不在当地现行的信创产品目录中导致项目无法通过审批或无法享受相关支持政策。原因白皮书的分类逻辑是技术逻辑信创目录的分类逻辑是管理和产业逻辑两者并不一一对应。白皮书说“这类设备可以国产化”不等于某个具体型号已经进入名录。解决采购前按“白皮书分类 → 技术参数 → 厂商型号 → 目录比对”四步走每一款设备都去现行信创目录里确认。对于目录里查不到但技术上可行的产品先走适配测试或专项评审再决定是否纳入采购范围。5.4 现象只关注硬件清单忽略了软件适配栈方案里把服务器、交换机、加速卡列得很详细但操作系统用什么版本、数据库用哪个、中间件是否兼容一概没提。评审时被问到“这套核心网网元在国产操作系统上跑过没有”答不上来。原因5G 设备表面上是硬件形态实际上是由软件定义的。尤其是核心网和 DU/CU对底层软件的依赖度极高。硬件进了信创目录只代表芯片平台合规不代表软件栈能跑通。解决在方案中把“软件适配栈”单独成章至少写清楚操作系统、容器/虚拟化平台、数据库、中间件、运维监控五个组件的选型和适配状态。每个组件都标注“已适配/适配中/待测试”。这条做好了项目交付阶段的稳定性会有明显提升。5.5 现象拿白皮书当安装图纸用现场还是抓瞎一个真实发生过的场景工程队带着白皮书里的架构图去现场部署到了机房发现机柜空间不够、供电回路不足、网线类型不匹配甚至天线安装位置和现场承重条件冲突。“5G 设备 AAU/DU/CU 安装指导书”这类文档才是施工依据白皮书解决不了物理世界的约束。原因白皮书描述的是逻辑架构和系统组成不是物理实施细节。所有涉及机械安装、线缆规格、供电要求、接地防雷的内容都必须以设备厂商的安装指导书和相关工程规范为准。解决项目开工前把白皮书中的系统架构图与设备安装指导书逐项对照生成一份“逻辑节点到物理位置”的映射表。哪种设备放哪个机柜、走哪路电、用什么类型的光模块和网线全部落实到表格里再交给施工方。提前做这一步比在现场改设计节省的时间要以周计。6. 白皮书没写透的部分自己动手补两件事白皮书能帮你建立认知框架但真正让项目顺利交付的往往是框架之外自己补的功课。这里分享两个我常用的进阶做法一个是把白皮书转成可执行的验收基线另一个是用仿真环境验证白皮书提到的技术“可能性”。两者都不复杂但对项目质量和团队信心帮助很大。6.1 把白皮书翻成一张可以打勾的验收基线白皮书里会大量出现“支持”“具备”“可按需提供”这类描述。如果你不把它们转成可验证的条目验收阶段就缺依据。我通常在项目启动时带着团队把白皮书里每一条与项目相关的陈述提取出来整理成一张“验收基线表”包含四列原文描述、验证方法、通过标准、责任方。举例来说白皮书如果描述“核心网支持基于服务化架构的网元通信”验证方法就是“在测试环境抓包确认 AMF 与 SMF 之间的 HTTP/2 信令交互”通过标准是“接口消息格式符合 3GPP TS 29.5xx 系列规范的字段要求”。如果白皮书提到“设备支持远程运维和日志审计”通过标准就是“运维通道经过加密认证、日志留存不少于 6 个月、审计记录不可篡改”。把这些内容在项目初期做出来相当于把白皮书从“参考材料”升级成了“项目资产”团队每个人都知道什么算做完。6.2 在仿真环境里验证白皮书提的“可能”另一件值得做的事是在没有真实设备的情况下用开源项目搭建一套 5G 仿真环境。比如基于 OAIOpenAirInterface这类开源 5G 协议栈实现在通用服务器上加装 USRP 软件无线电设备可以跑通从终端、基站到核心网的完整信令流程。这类仿真环境的优势是架构透明代码和信令都可见适合用来验证协议流程、做教学演示也适合在没有设备到货前让团队先熟悉 5G 信令过程。仿真环境不能替代真实设备做性能验收但它能帮助团队回答三类问题信令流程走得通吗、接口消息和标准一致吗、某个协议行为在异常条件下会触发什么后果。这些问题如果等到设备进场后才开始研究项目节奏会被拖慢。我见过不少团队靠仿真环境提前完成了交付文档中“信令流程说明”和“异常处理机制”两个章节正式调测时只需做参数校准即可。技术方向上的探索成本不高但收益往往是提前规避一次返工。关于 PDF 本身还顺手建议一点这本白皮书如果是扫描版检索起来很痛苦。可以用支持 OCR 的 PDF 工具把文字层提取出来再按协议栈、核心网、适配、安全这几个关键词做索引。处理后你会发现查“信创适配”和“安全要求”这两个词的使用频率变得极高——因为它们才是项目评审里被反复追问的部分。做这类项目多了之后我养成了一个习惯接到白皮书先看年份再看目录然后直接跳到与自身项目相关的两张表上其他部分快速过。不是其他内容不重要而是白皮书这种文档它的价值不在“读得全”而在“用得准”。希望这个读法帮到你。本文还有配套的精品资源点击获取