第三章 5G和后5G——不仅仅是移动通信网络

说起5G，很多人第一个反应就是“手机网速变快了”。没错，确实是快，而且快得有点离谱——以前下载一部电影需要几分钟，现在眨个眼可能就下完了。但如果你以为5G的使命就是让刷剧不卡，那真的是低估它了。5G的野心，远不止此。它是整个信息通信技术（ICT）体系的“集大成者”，甚至可以说，它是我们目前所有新技术的大型“实战场”。

5G 和后5G（例如6G研究阶段）不仅是通信网络的演进，更是整个 IT 和 ICT 技术体系融合落地、验证和进化的最大“实战战场”，比如云计算、边缘计算、AI、大数据、SDN/NFV、DevOps、虚拟化、开源架构以及目前的卫星通信等等，都已经在这个领域已不同的方式和不同的场景分布应用开来。

这样看来，5G和后5G整个产业就完全不是一个孤立的和封闭的产业。首先5G项目本身会细分出很多模块，而大多数这里涉及到的模块也都是整个ICT行业的通用的部分，比如数据通信技术，cloud技术，K8s技术等等；另一方面，这些5G内部的模块又与其他行业的技术和支持密不可分，比如边缘计算，比如自动化测试、DevOps、Agile开发等等。

在大型的5G整体的开发和交付项目中，可能涉及和包含的部门包括：

1． 产品规划设计和架构team

2． RAN产品开发team（可能分成多个子开发团队，比如CU team，DU team，L1 team, eCPRI team, ORU team, 或者分基带Baseband team，用户面数据开发team， 控制面team等）

3． OAM开发team（可能包含多个子开发团队，比如PM/CM/Fm team，NM platform team, M-plane team, 以及可能还有SMO团队，包括ORAN AI开发团队）

4． 核心网开发或集成team

5． 网络基础设施team

6． Cloud基础设施team

7． DevOps与自动化测试team（可能还有细分的子团队，比如tester，integration， CI/CD，Automation test）

8． xFT及新Feature验证team

9． Agile开发管理团队

10． 其他辅助team，如开发、测试工具开发，开发环境搭建和维护团队，开发和产品文档团队等等

11． 完整的产品交付和维护团队以及市场部门等

当然，5G产品部署到现场，还需要专门的交付部门来负责交付和支持，还需要进行长期的维护以及工程优化和专项优化，需要维护和优化团队等等

具体的团队的只能和分工，在本章的具体章节中会详细分析。

3.1 从5G的初始设计目标说起

3.1.1 传统的移动通信行业的岗位需求

传统的移动通信行业实际就是包括整个4G前的移动通信行业。岗位需求：

少数几个垄断企业称霸全球的网络，从业人员大多数是进入这些厂家或者是以contractor的身份参与到产品的开发当中。

更多的岗位是在运营商，运营商为了建设和运营移动网络，需要引入大量的上下游厂家和技术，包括网络基础设施，WAN，PON网络，传输网络（BH和FH），网络建设力量，网络规划力量。当然，运营网络，需要一整套客户经营人员。

推动行业发展的移动应用开发

终端行业的跟进和更新

3.1.2 从4G到5G的演进

4G是我们的“移动互联网”年代，它成就了今天的直播、短视频、社交平台和打车软件。我们每个人都变成了“移动互联网节点”，躺在沙发上就能完成衣食住行，生活节奏被拉到极致。

所以4G实际上已经充分践行了移动互联网的应用。

而5G？人们一开始就畅想着，把它变成“人-机-物”三位一体共舞的舞台；4G是给人打电话、看视频用的，而5G，是让自动驾驶的车能“看见前方”、远程医疗的医生能“摸到器官”、工厂的机械臂能“自己思考”的。

如果说4G是“让世界进入你的手机”，那5G就是“让手机进入整个世界”。

最直接的5G的“饼”就是散发着香味的AR/VR游戏、自动驾驶这些跟每个人的生活娱乐密切相关的应用场景。

3.1.3 5G的“三朵云”

一开始的美好构想明确、具体并且“好看”，这就是所谓的“三朵云”。

1. 增强型移动宽带（eMBB）

eMBB：给你速度与激情

是大家最熟悉的那一朵云，说白了就是网速爆表。它为4K、8K视频、AR/VR、云游戏这些“大胃王”级应用提供高吞吐和稳定连接。

你在地铁上刷短视频不卡顿、在VR里开赛车不延迟，这背后都是eMBB在支撑。它就像一个“高速公路工程师”，不停拓宽网络的车道，保证数据洪流可以畅行无阻。

2. 大规模机器类通信（mMTC）

mMTC：让万物开口说话

就像是给世界加了一万个“小耳朵”。你可以想象：智能水表、共享单车、路边的交通灯、田间地头的传感器，全都变成了“会说话的东西”。

这一场景的关键不是速度，而是连接密度和低功耗。5G让一个基站能同时容纳百万级的设备接入，而且让这些“小家伙”可以靠一粒钮扣电池用上好几年。

3. URLLC：关键任务的守门员

mMTC是物联网的土壤，是智慧城市的底座。

最“硬核”的还是第三朵云：超可靠低时延通信（URLLC）。这玩意儿可以做到“1毫秒以内的延迟”和“接近100%的可靠率”，简直像是让网络拥有了“神经反射”。

这朵云的用武之地，不是娱乐，而是“不能出错”的地方：远程手术、工业控制、车联网……任何一个通信延迟或丢包都可能造成“灾难”的场景。

URLLC像一个特别敏锐、绝不走神的守门员，它的使命就是“我不快点反应，就可能出人命”。

3.2 5G到后5G的实际道路与设计目标发生偏离

如果我们把5G的诞生看作一场科幻大片的开头，那开篇的愿景简直太令人兴奋了：自动驾驶的车队在城市中自如穿梭，远程医生挥着手术刀精准操作千里之外的病人，亿万传感器无处不在，构建起一张“感知世界的数字神经网”。但电影终归是电影，现实中的5G走到2024年，确实给了我们一些“这剧情好像跑偏了？”的感受。不是说5G失败了，而是它经历了一场从“理想派”向“实用派”的蜕变。这节里，我们就来聊聊：这条偏离轨道的路，是怎么一步步走出来的。

3.2.1 eMBB的现实：家里的长子，扛下全家经济重担

在5G的三朵云中（增强移动宽带eMBB、超可靠低时延通信URLLC、大规模机器通信mMTC），eMBB 是第一个真正跑通商业闭环的场景。你每天刷短视频、开高清视频会议、玩云游戏，其实早就用了5G的eMBB能力。而更低调但实际意义更大的，是运营商用5G做家庭宽带替代（FWA），在很多地区把光纤都没铺下去的地方，用5G就“无线地”把网连上了。但是，FWA毕竟不适合在国内的发展现状，但是在西方等其他国家有线宽带无法普及的情况下，FWA还是起了一个非常重要的有线宽带的补充作用。

我们可以说，eMBB是那个在5G家庭里最稳重的长子，没什么太多酷炫的梦想，但负责赚钱养家，表现非常靠谱。

3.2.2 URLLC的落差：天赋异禀但“签证没办好”的奥运选手

当年标准化时，URLLC 被定义为可以实现 1毫秒时延 + 五个9的可靠性（99.999%） 的超能力战士。可一走入真实世界，才发现这位“超人”要面对的现实问题比想象复杂得多。比如你想让一台自动驾驶车依赖公网5G做反应控制？太冒险了！出了事责任怎么算？再比如远程手术？一边是医生的手速和判断，一边是千公里外的机器人手臂，哪怕只迟了一帧画面，都是极限挑战。

因此很多本该用URRLC的场景，最后都选择了“次优但可用”的方式——用高带宽配合边缘计算、用专网降低干扰，实用为王。说白了，URLLC就像个奥运选手，但办不下来出国签证，最后只能在市级比赛中露一手。

3.2.3 mMTC的遭遇：“百万设备连接”还是停留在PPT里？

再来说说mMTC，它原本被视为“物联网时代的关键承载”，要支撑起万物互联的世界，几乎承包了我们对智慧城市、智能农业、智慧物流的所有幻想。但结果是，低功耗广域连接的大头，还是落在NB-IoT和LoRa等“旧人”头上，真正5G New Radio上的mMTC芯片贵、模组贵、网络贵，终端厂家直摇头。而RedCap（简化版5G）直到2023年后才刚刚开始商用，生态建设缓慢。

于是，mMTC被活生生地边缘化，成了三朵云里最冷的一朵，甚至被人误以为“下雨了”。

3.2.4 毫米波：理想的高铁，现实的短途电动车

在5G的设计蓝图中，毫米波（也叫 FR2 频段）几乎是“终极武器”级别的存在。你看它频率高、带宽宽、速率猛，一口气搞上去就是几个Gbps，听着就让人热血沸腾。初衷是啥？就是为了打造未来“随时随地都能8K直播、云游戏、AR眼镜不卡顿”的超带宽世界。

但等到2024年再回头看毫米波这位“高端选手”，你会发现，它活得也挺不容易的。高开低走，从主角逐渐变成了“偶尔出场的嘉宾”。

理论上，毫米波是光速马车，快得让人兴奋。优点非常明显，的确有它梦幻的一面，比如：

 带宽巨大：动辄几百MHz甚至上GHz，是Sub-6GHz频段的数十倍。

 吞吐率惊人：实验室环境轻松实现数Gbps。

 支持密集连接：为大流量场景（比如体育馆、演唱会）量身定制。

所以当初毫米波被安排得明明白白——负责那种“科技感爆棚”的未来应用，比如沉浸式虚拟现实、无缝的边缘计算互动，甚至某些极端工业应用。

但这都是“理论上”，实际上这把水里的快刀并不能施展其本领。问题在哪？现实给了毫米波一记“物理的耳光”：

 传播能力差：毫米波在空气中衰减太快，一堵墙、一个人甚至一只树叶都能挡住它。你在家门口有信号，进门就断。

 穿透能力弱：别说穿楼了，穿个玻璃都要“绕个弯”。

 部署成本高：要想覆盖一个街区，得部署大量小基站，运营商的钱包直呼“受不了”。

所以从实际来看，毫米波更像是个“短途冲刺选手”，需要在视距清晰、基站密集、设备稀少的环境中才能发挥实力。

也就是说，它是个超级跑车，但只能在跑道上开两圈，一上高速堵车就白搭了。

另外，从整体的市场策略上看，在5G刚商用的那几年，不少国家都高调拍卖毫米波频谱，美国尤其激进，还搞了“毫米波优先”的政策，搞得好像“未来人人头上都要装一个毫米波天线”。但很快，各国运营商就冷静了。现实告诉他们，毫米波部署要命贵、收益难回。最终形成的市场共识是——毫米波不是主力，而是“补丁”，在如下场景才有其应用的可能：

 在体育馆、车展、机场、展览馆这些“高价值、局部密集”的场所里，用毫米波做热点覆盖。

 给家庭宽带FWA提供大容量支撑，但依然是小规模。

 少数企业园区、工业园实验性部署，用作“专网增强”。

你可以把毫米波理解为——不是公共交通，而是高端社区里的高尔夫球车，只在“特殊地形”里来回跑。

那么，毫米波作为5G初设计时的主打场景和技术，未来的发展和应用机会在哪里？

随着AI的发展，网络能更聪明地预测信道质量、动态分配资源，甚至智能波束追踪，毫米波或许能“更聪明地跑起来”。而RedCap/6G可能会通过硬件微缩、能耗优化、信号处理增强，让毫米波模组更小更便宜，最终变成像Wi-Fi那样的“近场高速通信工具”。这也许就是毫米波未来的最可能的应用方向，但一切还是预测，在如此日新月异、变幻莫测的年代，一切皆有可能。

3.2.5 关键场景的幻灭与转向

5G被寄予厚望的那些“杀手级场景”呢？我们来逐个击破。

自动驾驶：虽然5G车联网标准做得漂亮，但L2+/L3自动驾驶根本不敢全靠5G，车上感知+本地计算才是王道，5G最多当个“气象播报员”。实际上，目前的自动驾驶应用中领先的如特斯拉的FSD与用不用5G、用什么样的5G没有毛关系。

远程医疗：偶尔能看到5G超声、远程探视的试点，但法律合规、医生信任、稳定性要求高，远程手术依然是“科学家的演示项目”。

XR/元宇宙：终端太贵、网络没铺够、应用内容没跟上，一切都卡在“未来一定很美”的阶段。

倒是AI，悄悄“反向赋能”了5G自己。

最意想不到的是，AI并不是5G的“终端应用”，反而成了5G网络本身的加速器。今天越来越多的运营商在用AI优化网络参数、预测设备故障、甚至自动调节基站能耗。这像不像是，主角跑偏了，结果助理却意外出圈？

3.3 新5G生态徐徐展开

不知不觉中，新5G生态已经慢慢地在我们面前展开。新5G生态是把5G和后5G乃至6G又有机地关联起来了。这是纵向，而横向，新5G生态又像植物的根须跟其他的生态纠缠在了一起。

3.3.1 5G网络的“云原生”

随着5G网络向大规模商用迈进，网络架构日益呈现“软化、轻量化、弹性化”的趋势。云原生（Cloud Native）理念作为支撑现代应用高效部署与运维的核心方法，正在成为5G乃至后5G、6G网络演进的关键基础。

因此很多本该用URRLC的场景，最后都选择了“次优但可用”的方式——用高带宽配合边缘计算、用专网降低干扰，实用为王。说白了，URLLC就像个奥运选手，但办不下来出国签证，最后只能在市级比赛中露一手。

首先应该明确，到底什么叫做云原生（cloud native）？实际上就是相对于以前COTS通用服务器的应用生态和之前基于虚拟化的“传统的”云，Cloud Native就是这些应用（比如5G的MAC层调度器开发的逻辑和方法）是基于云原生架构本身的应用。在5G核心网中，云原生技术已率先落地，AMF、SMF、UPF 等功能模块被重构为微服务，运行在容器中，通过 Kubernetes 实现自动部署、弹性伸缩与高可用保障。这种架构极大提升了网络功能的灵活性与运维效率，为实现网络切片、边缘计算、按需部署等5G特性提供了支撑。K8s已经形成了云原生平台的事实的标准。

向后5G和6G演进过程中，网络将面临更多实时、高可靠、高动态性的挑战，云原生技术的价值将进一步放大。6G网络预计将采用更加极致的分布式部署模式，接入点将更加靠近用户终端，网络功能将“无处不在”，而这正需要云原生架构的高弹性与强自治特性。同时，随着AI原生网络、自适应网络策略等概念的出现，云原生还将与AI、自动化运维系统深度融合，实现网络功能的智能化协同。

在这样的“万物皆Kubernetes”的大环境下，自然行业内外不甘寂寞的家伙便不失时机地开始计划着给5G和后5G的系统动一个大手术。所以，在原来5G核心网的SBA结构的基础上，无线测的C-RAN，Cloud RAN以及O-RAN相继被推上了历史舞台。这些都或多或少进行了云原生的引入和尝试。逐渐地，业界增加了不少新的玩家，这些新的玩家纷纷从零开始，做起了Cloud RAN或O-RAN的5G产品。而传统的几大4G/5G的垄断大厂意识到不能在传统的私有设备的网络一条路走到黑，不参与这些新5G的角逐肯定会有严重的后果。于是，他们一方面不放弃传统的私有网络架构，另一方面又会去同步搭建Cloud RAN或O-RAN，可能会形成多套产品线齐头并进。

。。。未完待续