第3章小基站软件架构

小基站软件架构：操作系统选型、协议栈分层、管理平面与数据平面

聊到小基站的软件架构，很多刚入行的朋友容易把它想得太神秘。其实说白了，它跟咱们家里那台路由器在思路上有几分相似——只不过复杂度高了几个数量级。我这些年拆过不少小基站的软件系统，今天就把核心的三个维度掰开揉碎了讲清楚。

小基站的操作系统选型，我个人习惯把它比作「选地基」。地基没打好，上面盖的楼再漂亮也白搭。

目前主流的选择就两个方向：

Linux 发行版（如 Yocto、Buildroot）：占了小基站市场的 80% 以上。为什么？因为开源、可裁剪、驱动生态好。我在项目中遇到过用 Yocto 定制内核的场景，那叫一个折腾——但一旦调通了，后面就非常省心。
实时操作系统（RTOS，如 FreeRTOS、VxWorks）：主要用于基带处理这种对时延极其敏感的场景。你想想看，LTE 的 TTI 是 1ms，5G NR 更是低至 0.5ms，Linux 的调度抖动有时候真扛不住。

我的建议：控制面和管理面用 Linux，数据面（尤其是 L1 物理层）用 RTOS。这是目前最成熟的「双系统」架构。

嗯，这里要注意一点——别盲目追求最新内核版本。小基站讲究的是长期稳定支持（LTS）。我曾经见过一个团队为了尝鲜用了 5.15 内核，结果某个网卡驱动在特定流量下会死锁，排查了整整两周。后来切回 5.10 LTS，问题消失。

避坑指南：选内核时，优先看它有没有针对 ARM Cortex-A 系列的 PREEMPT_RT 补丁。没有这个，你的实时性就是空谈。

小基站的协议栈，严格遵循 3GPP 定义的分层结构。我习惯把它拆成三层来看：

为什么会这样分层？说白了，就是「把硬实时的事交给硬件，把软实时的事交给软件，把非实时的事交给 Linux」。

我记得有一次排查一个掉线问题，现象是 UE 频繁 RRC 重建。抓了日志发现是 L2 的 RLC 重传超时，但 L3 的 RRC 还在傻等。这就是典型的层间耦合没处理好——L2 应该主动通知 L3「我撑不住了」，而不是让 L3 一直等。

注意：层间接口的时延预算一定要留够。我见过不少方案，L2 到 L3 的 IPC 通信用了共享内存，但没做优先级反转处理，结果高优先级的调度消息被低优先级的日志打印给堵住了。

小基站的软件架构里，最核心的一个设计思想就是「控制与承载分离」。你想想看，如果管理流量和数据流量混在一起，一旦网络拥塞，连远程重启都发不出去——那运维就彻底抓瞎了。

具体来说：

管理平面（Management Plane）：负责 OAM（操作、管理、维护）。包括配置下发、告警上报、软件升级、性能统计。走的是 TR-069 或 NETCONF/YANG 协议。我个人习惯把管理平面跑在一个独立的 Linux 网络命名空间里，跟数据面完全隔离。
数据平面（Data Plane）：负责用户数据的转发。从 S1-U（或 N3）接口进来，经过 PDCP 解密、RLC 重组、MAC 调度，最后到物理层发出去。这一路不能有任何阻塞。

关键点：管理平面和数据平面之间，通常通过一个「代理进程」来交互。比如管理平面要修改某个无线参数，它不会直接写寄存器，而是通过代理进程向数据平面发一个消息。这样做的好处是——数据平面崩溃了，管理平面还能上报告警。

我曾经在现网中遇到过这么个事：某个小基站的数据平面因为内存泄漏挂了，但管理平面还活着。运维平台收到了「数据面异常」的告警，远程下发了一个复位命令，基站就恢复了。你想想看，如果当时管理平面和数据平面是紧耦合的，那这个基站就只能等人去现场拔电了。

我的经验：管理平面和数据平面之间，一定要设计心跳机制。心跳超时后，管理平面主动复位数据平面。这个机制我建议用独立的硬件看门狗来实现，别依赖软件定时器——软件都挂了，定时器还能准吗？

讲到这里，你可能会问：「那我到底该怎么选？」

我个人的建议是分场景：

家庭级小基站（Femto）：用单芯片 SoC，Linux 跑全部协议栈。成本优先，性能够用就行。管理平面和数据平面通过进程间通信隔离。
企业级小基站（Enterprise）：用 ARM + FPGA 架构。Linux 跑 L3 和管理面，RTOS 跑 L2，FPGA 跑 L1。这是目前最主流的方案。
室外型小基站（Metro）：用多核 ARM + 专用加速器。管理平面独立跑在一个核上，数据平面跑在其他核上，核间通过 RPMsg 通信。

嗯，最后说一句——架构设计没有银弹。我见过用纯 Linux 跑出 5ms 时延的牛人，也见过用 RTOS 跑得一塌糊涂的团队。关键还是看你对每一层的理解深度，以及踩过多少坑。

下一章我们会深入 L2 调度器的实现细节，到时候再聊。