简介《2021空天地一体化通信系统》白皮书V7.0由紫光展锐、中山大学、中兴通讯、中国空间技术研究院等多家单位联合编制面向6G通信、卫星互联网与星地融合网络领域的研究人员、工程师及高校师生系统梳理了空天地一体化通信系统的发展脉络与关键技术方向。资源包内含1个PDF文件大小约3.63MB内容完整呈现白皮书正文便于通读与检索。白皮书从发展驱动与愿景、需求与挑战、立体融合网络架构、潜在关键技术四个角度展开提出空天地一体化是6G典型体系架构具备统一空口、统一网络架构与统一智能管控三大特征并深入探讨无线传输、网络协议、新型星上载荷、智能化融合终端及业务应用五大技术方向涵盖SCMA、MUSA多址、星载多波束天线、通导一体化等具体议题。目前已有450人学习下载适合作为6G与卫星通信方向的技术参考与方案设计依据。1. 从一份 2020 年的白皮书说起空天地一体化到底在解决什么问题2020 年 11 月紫光展锐、中山大学、中兴通讯、中国空间技术研究院、北邮、小米、天大、三大运营商、大唐移动、天锐星通、东南大学、西安空间无线电技术研究所、电子科大、三星通信研究院、中科晶上、北京信息科技大学等近二十家单位联合发布了一份白皮书标题就叫《空天地一体化通信系统》版本号 WHITE PAPER V7.0。这不是一篇论文也不是某个开源项目的 README而是一份产业界和学术界坐在一起、把 6G 时代卫星通信与地面通信如何融合这件事讲清楚的系统性文档。它要回答的核心问题是地面蜂窝网和卫星通信网各自独立发展了几十年到了 5G 时代靠网关勉强打通了业务层但面向未来广域万物智联和全球随遇接入这种“两张皮”的模式已经撑不住了怎么办这份白皮书给出的答案是构建空间网络与地面网络相融合的空天地一体化通信系统实现统一高效的资源调度与网络管控。它从发展驱动与愿景、需求与挑战、立体融合网络架构、潜在关键技术四个角度展开覆盖了无线传输、网络协议、星上载荷、终端、业务应用五个技术方向。适合谁读如果你在做卫星通信、6G 预研、星地融合网络架构设计或者你是一个想从地面通信转向空天通信的工程师这份文档能帮你把整个技术版图看清楚。它不是操作手册但它决定了你后面看的所有技术方案、选的每一套协议、设计的每一个载荷到底站在哪个框架里。2. 白皮书的骨架四层逻辑与五个技术方向怎么拆2.1 从驱动力到架构白皮书的四段式推演这份白皮书的结构不是随便排的它遵循一条很清晰的推演链先讲为什么做再讲做成什么样然后讲难在哪最后讲怎么干。发展驱动部分指出双重驱动力——业务需求和技术发展。业务需求体现在广域万物智联和全球随遇接入两方面技术发展则来自卫星技术、运载技术的创新以及 AI 与通信的深度融合、区块链为异构系统提供的安全解决途径。发展愿景部分把空天地一体化定位为 6G 的典型体系架构提出三大典型特征统一的空口技术、统一的网络架构、统一的智能管控。需求与挑战部分梳理了网络能力需求——通信能力是基本需求AI 能力是核心能力包括感知、学习、推理、预测、决策五个维度。立体融合网络架构部分给出了物理架构、逻辑架构、实现架构三层含义实现架构上借鉴微服务思想用资源虚拟化技术实现接入网、承载网、核心网的星地一体虚拟化。这条推演链的价值在于它让你在动手做任何一个子系统之前先想清楚它在整个体系里的位置。比如你要设计一个星间组网协议白皮书告诉你组网协议的发展趋势是借鉴地面成熟的 TCP/IP 协议体系把 DTN 和 CCSDS 逐渐统一到以 TCP/IP 为核心的组网体系中也就是 IP over X 的思路。这个判断直接决定了你选协议栈时的方向。2.2 五个关键技术方向的权重与依赖关系白皮书从五个方向探讨关键技术这五个方向不是并列的它们之间有依赖关系。无线传输技术是底层解决的是卫星载荷中大功率射频器件非线性特性和星地链路非理想特性带来的调制难题白皮书点名了 SCMA 和 MUSA 作为潜在多址技术同时指出大规模星座卫星部署为 MIMO 提供基础通过星间协作建立虚拟多天线系统实现多星多波束协作传输。网络技术是中层解决组网协议统一、认知干扰协调、动态频谱共享、端到端网络切片等问题。新型星上载荷技术是硬件基础星载多波束天线不再是独立的天线分系统而是与系统工作模式紧密耦合智能化载荷以软件定义的计算能力和重构能力为基础结合 AI 完成频谱认知和网络认知。智能化融合化终端是用户侧入口泛在化和智能化是关键特征低成本平板相控阵天线是核心部件其成本与芯片工艺技术密切相关。业务与应用技术是价值出口通导一体化设计、低轨导航增强专用星座、精密单点定位、安全定位授时、天基监测、抗干扰定位等功能都在这个方向下。理解这五个方向的依赖关系对你做技术选型很关键。比如你要做一个终端侧的 AI 推理功能它依赖终端芯片的异构计算能力而终端芯片的能力又受制于相控阵天线的成本约束相控阵天线的成本又与芯片工艺技术挂钩。这条链上的每一环都会影响你最终能落地的方案。2.3 网络架构的三层含义物理、逻辑、实现白皮书对网络总体架构的拆解值得单独拿出来说。物理架构讲的是各星座卫星高、中、低轨、临近空间平台热气球、无人机等和地面节点如何共同形成多重覆盖。逻辑架构讲的是这些节点在功能上如何分层、如何协作。实现架构讲的是怎么用工程手段把逻辑架构落地白皮书给出的答案是借鉴微服务思想采用资源虚拟化技术实现接入网、承载网和核心网的星地一体虚拟化。这三层含义的拆法在实际工作中很有用。当你拿到一个星地融合网络的设计方案时先看它的物理架构是否合理——星座配置、覆盖能力、链路预算是否成立再看逻辑架构是否自洽——功能分层、接口定义、协议栈是否闭环最后看实现架构是否可落地——虚拟化方案、资源调度、运维体系是否可行。很多方案在物理层就站不住或者逻辑层自洽但实现层根本没有可用的虚拟化平台支撑。3. 关键技术方向落地从无线传输到业务应用的工程化拆解3.1 无线传输SCMA 与 MUSA 的选型逻辑与参数考量白皮书在无线传输技术方向明确指出必须发展新型载波调制技术以对抗卫星载荷中大功率射频器件的非线性特性以及星地链路传输的非理想特性。在多种候选方案中SCMA稀疏码多址和 MUSA多用户共享接入被点名为适用于空天地一体化系统的潜在多址技术。这个判断背后的逻辑是卫星链路的功率受限、非线性失真严重传统 OFDMA 在高功率放大器接近饱和点时性能急剧恶化而 SCMA 和 MUSA 通过码域扩展和序列设计在非理想条件下有更好的鲁棒性。如果你要在仿真环境中验证 SCMA 在卫星链路下的性能常见的做法是搭建一个包含非线性功放模型的链路级仿真。下面是一个简化的 Python 仿真框架用于对比 SCMA 和 OFDMA 在 Saleh 非线性模型下的误码率表现import numpy as np def saleh_nonlinearity(signal, alpha_a2.1587, beta_a1.1517, alpha_p4.0033, beta_p9.1040): Saleh 行波管放大器非线性模型 alpha_a, beta_a: AM/AM 转换参数 alpha_p, beta_p: AM/PM 转换参数 amplitude np.abs(signal) phase np.angle(signal) # AM/AM 和 AM/PM 转换 amp_out (alpha_a * amplitude) / (1 beta_a * amplitude**2) phase_out (alpha_p * amplitude**2) / (1 beta_p * amplitude**2) return amp_out * np.exp(1j * (phase phase_out)) def scma_sparse_codebook(num_users, spreading_factor, num_resources): 生成 SCMA 稀疏码本 num_users: 用户数 spreading_factor: 扩频因子 num_resources: 资源块数 codebook np.zeros((num_users, spreading_factor, num_resources), dtypecomplex) for u in range(num_users): for r in range(num_resources): # 每个用户在每个资源块上只占用部分维度 active_dims np.random.choice(spreading_factor, sizespreading_factor // 2, replaceFalse) for d in active_dims: codebook[u, d, r] np.exp(1j * 2 * np.pi * np.random.rand()) return codebook # 参数设置 num_users 6 spreading_factor 4 num_resources 4 snr_range np.arange(0, 16, 2) # 生成 SCMA 码本 codebook scma_sparse_codebook(num_users, spreading_factor, num_resources) # 仿真主循环简化示意 for snr_db in snr_range: snr_linear 10**(snr_db / 10) # 生成发送信号、叠加、加噪、非线性处理、检测 # 此处省略具体调制解调与消息传递算法细节 pass这段代码的关键点在于 Saleh 非线性模型的参数设置。alpha_a 和 beta_a 控制幅度失真alpha_p 和 beta_p 控制相位失真不同频段、不同功放型号的参数差异很大实际使用时需要根据你手头的功放 datasheet 来标定。SCMA 码本的生成逻辑中每个用户在每个资源块上只占用部分维度这是稀疏性的来源也是 SCMA 能在过载条件下工作的基础。仿真时要注意卫星链路的信噪比通常比地面蜂窝低得多SNR 范围建议从 -5dB 开始扫而不是从 0dB 开始。3.2 网络技术IP over X 的协议栈融合与网络切片实现白皮书在网络技术方向给出了一个非常明确的判断组网协议的发展趋势是借鉴地面成熟的 TCP/IP 互联网协议体系将 DTN 和 CCSDS 等各协议体系逐渐统一到以 TCP/IP 为核心的组网体系中即 IP over X。这个判断的工程含义是你不需要为卫星网络重新发明一套协议栈而是要在 TCP/IP 的基础上做适配和扩展。DTN 的 Bundle Protocol 解决的是长时延、间歇连接的问题CCSDS 解决的是空间链路的数据格式问题但它们的上层应用接口最终要收敛到 IP 体系。在实际工程中实现 IP over X 的常见做法是在卫星网关和地面网关之间做协议转换。下面是一个用 Python 模拟 DTN Bundle 到 TCP/IP 转换的简化示例import socket import struct import time class DTNBundle: 简化的 DTN Bundle 结构 def __init__(self, source_eid, dest_eid, payload, ttl3600): self.source_eid source_eid self.dest_eid dest_eid self.payload payload self.ttl ttl self.creation_time time.time() def is_expired(self): return (time.time() - self.creation_time) self.ttl def to_bytes(self): 序列化为字节流模拟 Bundle Protocol 封装 header struct.pack(!II, len(self.source_eid), len(self.dest_eid)) return header self.source_eid.encode() self.dest_eid.encode() self.payload class BundleToTCPGateway: DTN Bundle 到 TCP/IP 的网关转换 def __init__(self, listen_port, forward_host, forward_port): self.listen_port listen_port self.forward_host forward_host self.forward_port forward_port def start(self): # 监听来自卫星链路的 Bundle 数据 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((0.0.0.0, self.listen_port)) while True: data, addr sock.recvfrom(65535) bundle self.parse_bundle(data) if bundle and not bundle.is_expired(): # 转换为 TCP 流并转发到地面网络 self.forward_to_tcp(bundle.payload) def parse_bundle(self, data): 解析 Bundle 字节流 try: src_len, dst_len struct.unpack(!II, data[:8]) offset 8 source_eid data[offset:offsetsrc_len].decode() offset src_len dest_eid data[offset:offsetdst_len].decode() offset dst_len payload data[offset:] return DTNBundle(source_eid, dest_eid, payload) except Exception: return None def forward_to_tcp(self, payload): 将 payload 通过 TCP 转发到地面网络 with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as tcp_sock: tcp_sock.connect((self.forward_host, self.forward_port)) tcp_sock.sendall(payload)这段代码的核心逻辑是卫星链路侧使用 UDP 承载 Bundle 数据网关解析出 Bundle 的源 EID、目的 EID 和 payload然后通过 TCP 转发到地面网络。参数方面listen_port 是网关在卫星链路侧的监听端口forward_host 和 forward_port 是地面网络的目标地址和端口。TTL 的设置需要根据卫星链路的传播时延来定低轨卫星单跳时延在几毫秒到几十毫秒之间GEO 卫星单跳时延约 250 毫秒TTL 至少要覆盖端到端最坏情况下的传播时延加上处理时延。网络切片方面白皮书指出实现空天地端到端一体化网络切片需要在网络拓扑结构预测、人工智能 SLA 保障、接入网和核心网一体虚拟化等方面展开研究。拓扑结构预测是因为卫星星座的拓扑是时变的切片的路由路径需要提前预测和调整。AI SLA 保障是因为不同切片对时延、带宽、可靠性的要求不同需要智能化的资源分配策略。接入网和核心网一体虚拟化是基础没有虚拟化就没有切片的资源隔离。3.3 星上载荷与终端智能化载荷的软件定义能力与相控阵天线成本约束白皮书对新型星上载荷技术的描述有一个关键判断星载多波束天线在未来通信卫星系统中将与系统工作模式紧密联系在一起不再是独立的天线分系统。这意味着天线设计不再是天线工程师单独的事而是要和系统工程师一起根据波束规划、频率复用、干扰协调等系统级需求来联合设计。智能化卫星载荷以软件定义的计算能力和重构能力为基础结合 AI 技术完成频谱认知和网络认知进行业务预测和资源分配使载荷具备自主应对业务和流量变化的能力。星上容错设计方面白皮书给出的技术路线是功能模块高效容错与系统级故障恢复相结合。这个思路的工程含义是不要试图让每个模块都做到绝对可靠而是在模块级做高效容错比如冗余设计、错误检测与纠正在系统级做故障恢复比如重构、降级运行、任务迁移。这种分层容错策略比单点追求高可靠更务实因为空间环境的辐射、温度循环、单粒子翻转等问题无法完全消除。终端侧白皮书指出泛在化和智能化是空天地一体化终端的关键特征。适应终端芯片异构计算能力的开源深度学习框架和轻量化的边缘人工智能算法是终端智能化的基础。低成本平板相控阵天线作为终端核心部件对空天地一体化通信系统能否成功商业应用有直接影响。终端相控阵天线的成本与芯片工艺技术密切相关。这句话的潜台词是如果相控阵天线的成本降不下来整个空天地一体化通信系统的商业闭环就跑不通。因为终端用户不会为一个天线付出比手机还贵的价格。3.4 业务与应用通导一体化的融合路径与低轨导航增强白皮书在业务与应用技术方向指出了一个现实问题目前存在通导系统分立、融合程度低的问题。通信系统和导航系统各自建设、各自运维终端需要两套硬件、两套协议栈成本和功耗都上去了。解决路径是通导一体化设计通过低轨通信星座载荷搭载、建设低轨导航增强专用星座等手段实现精密单点定位、安全定位授时、天基监测、抗干扰定位等功能。通导一体化的工程落地常见做法是在低轨通信卫星上搭载导航增强载荷利用通信链路的测距信息辅助导航定位同时利用导航信息辅助通信链路的波束对准和切换管理。这种双向辅助的架构比单向增强更有价值。低轨导航增强专用星座的建设则是另一种路径专门发射一批低轨卫星用于导航增强不承载通信业务专注于提供高精度定位服务。两条路径各有优劣前者复用通信星座的基础设施成本低但性能受通信载荷约束后者性能优化空间大但需要独立建设星座。4. 避坑与排查读这份白皮书和做空天地一体化项目时容易翻车的几个地方4.1 把白皮书当操作手册用现象拿到这份 PDF 后试图在里面找到具体的协议参数、代码实现、配置命令翻了几十页发现全是架构描述和技术方向没有一行可以直接抄的代码或配置。原因这份文档的定位是白皮书不是技术规范或实现指南。它的价值在于帮你建立技术版图和判断方向而不是告诉你某个参数设多少。白皮书里提到的 SCMA、MUSA、IP over X、网络切片、通导一体化都是方向性判断不是具体方案。解决把白皮书当作技术选型的参考框架而不是实现手册。读完白皮书后针对你关心的具体技术方向去找对应的技术规范比如 3GPP 的 NTN 相关文档、CCSDS 的协议规范和开源实现比如 OpenAirInterface 的 NTN 扩展、NS-3 的卫星模块。白皮书告诉你“做什么”规范告诉你“怎么做”开源实现告诉你“别人怎么做的”。4.2 忽略时空尺度对协议设计的影响现象把地面蜂窝网的协议栈直接搬到卫星链路上发现 TCP 吞吐量急剧下降重传率飙升连接建立时间长得无法接受。原因空天地一体化系统的时空尺度和地面网络完全不同。GEO 卫星单跳传播时延约 250 毫秒低轨星座的拓扑时变周期在几分钟到十几分钟量级星间链路的距离变化导致传播时延动态波动。TCP 的拥塞控制算法假设 RTT 在毫秒量级在几百毫秒的 RTT 下慢启动过程会极其漫长丢包重传的代价也大得多。解决针对卫星链路常见的做法是使用性能增强代理PEP来拆分 TCP 连接或者在协议栈层面使用 DTN 的 Bundle Protocol 来容忍长时延和间歇连接。如果必须用 TCP考虑使用 TCP Hybla、TCP Peach 等针对长时延链路优化的拥塞控制算法。参数方面初始拥塞窗口可以适当增大重传超时RTO的最小值需要根据链路 RTT 来调整不能沿用地面网络的默认值。4.3 低估星上资源受限的约束现象在星上载荷上部署 AI 推理模型发现推理时间远超预期或者模型根本跑不起来内存不够、算力不够、功耗超标。原因空间节点的资源受限程度远超地面设备。星载处理器的算力通常比同代地面处理器低一到两个数量级内存容量受限于抗辐射器件的工艺水平功耗受限于卫星的供电能力和散热能力。白皮书明确指出空间节点资源受限是空天地一体化系统面临的挑战之一。解决星上 AI 模型必须做轻量化设计。常见做法包括模型剪枝、量化把 FP32 降到 INT8 甚至更低、知识蒸馏用大模型教小模型。推理框架要选择支持异构计算和低精度推理的比如 TensorFlow Lite、ONNX Runtime 的量化版本。如果星上算力实在不够可以考虑把推理任务卸载到地面或临近空间平台星上只做数据采集和预处理。但卸载会引入额外的传输时延需要根据业务时延要求来权衡。4.4 忽视卫星广播链路的易攻击性现象在仿真环境中一切正常但在实际链路测试中发现数据被篡改、信令被伪造、服务被拒绝。原因白皮书明确指出卫星广播传输链路易受攻击。卫星信号的覆盖范围大攻击者可以在任何覆盖区域内接收和发射信号不像地面基站有物理边界保护。广播链路的信令如果缺乏认证和加密很容易被伪造。区块链被白皮书点名为解决数据传输安全问题的潜在技术但区块链本身在资源受限的星上节点上部署也有挑战。解决链路层要加认证和加密信令面要加完整性保护数据面要根据业务安全等级做差异化保护。区块链的使用要权衡——不是所有数据都需要上链只有需要多方信任、不可篡改的记录才适合上链。星上节点的区块链轻节点方案是常见做法完整节点部署在地面或算力充足的平台。4.5 把通导一体化简单理解为“加个导航模块”现象在通信卫星上搭载了一个导航信号发生器就认为实现了通导一体化结果发现定位精度没有提升通信性能也没有改善。原因通导一体化不是简单的硬件叠加而是要在信号设计、协议栈、数据处理层面做深度融合。通信链路和导航链路的信号体制不同、频段可能不同、处理流程不同如果只是物理上放在同一颗卫星上各自独立工作那只是“共星”而不是“一体化”。解决通导一体化的融合点在于利用通信链路的测距信息辅助导航定位通信信号本身可以作为测距信号利用导航信息辅助通信链路的波束对准和切换管理知道终端位置可以更精准地调度波束。信号设计上要考虑通信和导航信号的兼容性避免相互干扰。数据处理上要融合通信和导航的观测量做联合解算。这些都需要在系统设计阶段就考虑而不是后期打补丁。5. 从白皮书到工程落地一份技术方向清单的验证方法与使用习惯读完这份白皮书你手里应该有一张技术方向清单无线传输方向的 SCMA/MUSA 和多星多波束协作、网络方向的 IP over X 和网络切片、星上载荷方向的软件定义和智能化、终端方向的低成本相控阵和边缘 AI、业务方向的通导一体化。这张清单怎么用我的习惯是把它当作技术选型的检查表每做一个方案逐条对照这个方案涉及清单里的哪些方向每个方向上的技术选择是否和白皮书的判断一致如果不一致是我有更好的理由还是我漏掉了什么约束验证方法上我一般会分三步走。第一步是仿真验证用 NS-3 或 MATLAB 搭建链路级和系统级仿真验证关键参数比如 SCMA 在非线性信道下的误码率、TCP 在长时延链路下的吞吐量、网络切片的资源隔离效果。第二步是半实物验证用信道模拟器模拟卫星链路的时延、多普勒、衰落把星上载荷和终端的关键模块接入测试。第三步是外场试验如果有条件的话用临近空间平台或低轨卫星做实际链路测试。每一步的侧重点不同仿真验证看算法和协议的正确性半实物验证看工程实现的可行性外场试验看真实环境下的性能边界。参数设置上有几个关键值需要根据你的具体场景来定。低轨卫星的单跳传播时延在 2 到 15 毫秒之间取决于轨道高度和仰角GEO 卫星的单跳传播时延约 250 毫秒星间链路的时延波动范围取决于星座构型和星间距离变化。多普勒频移在低轨场景下可以达到几十 kHzL 频段和 Ka 频段的数值差异很大。这些参数直接决定了你的协议栈设计、缓冲区大小、重传策略。从那以后我每次拿到一份新的技术白皮书都强制走一遍“方向清单化、参数表格化、验证分步化”的流程。方向清单化是把文档里的技术方向抽出来变成可检查的条目参数表格化是把关键参数和取值依据整理成表验证分步化是把仿真、半实物、外场三步的验证计划和通过标准写清楚。这套习惯让我少走了很多“读完文档觉得懂了、一动手就翻车”的弯路。希望帮到你。本文还有配套的精品资源点击获取
