企业官网建设流程全解析

简介：这份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 或专用加速器上，信创替代的可行路径是“通用处理器 + 加速卡”的异构方案。

实际拆解时，我习惯把协议栈画成一张五层表格，每一列标出“替代难度”“主要改造对象”“风险点”。这比泛泛读白皮书有用得多。表格大概是这样：

这张表的落点是：白皮书里讲“信创 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 仿真环境。比如基于 OAI（OpenAirInterface）这类开源 5G 协议栈实现，在通用服务器上加装 USRP 软件无线电设备，可以跑通从终端、基站到核心网的完整信令流程。这类仿真环境的优势是架构透明，代码和信令都可见，适合用来验证协议流程、做教学演示，也适合在没有设备到货前让团队先熟悉 5G 信令过程。

仿真环境不能替代真实设备做性能验收，但它能帮助团队回答三类问题：信令流程走得通吗、接口消息和标准一致吗、某个协议行为在异常条件下会触发什么后果。这些问题如果等到设备进场后才开始研究，项目节奏会被拖慢。我见过不少团队靠仿真环境提前完成了交付文档中“信令流程说明”和“异常处理机制”两个章节，正式调测时只需做参数校准即可。技术方向上的探索成本不高，但收益往往是提前规避一次返工。

关于 PDF 本身，还顺手建议一点：这本白皮书如果是扫描版，检索起来很痛苦。可以用支持 OCR 的 PDF 工具把文字层提取出来，再按协议栈、核心网、适配、安全这几个关键词做索引。处理后你会发现，查“信创适配”和“安全要求”这两个词的使用频率变得极高——因为它们才是项目评审里被反复追问的部分。

做这类项目多了之后，我养成了一个习惯：接到白皮书先看年份，再看目录，然后直接跳到与自身项目相关的两张表上，其他部分快速过。不是其他内容不重要，而是白皮书这种文档，它的价值不在“读得全”，而在“用得准”。希望这个读法帮到你。

本文还有配套的精品资源，点击获取