第1章基站系统概述

1. 基站系统概述：硬件架构、软件架构、基站通信协议栈简介

各位同学，咱们今天聊聊基站。说实话，很多人干了几年运维，对基站的认知还停留在“铁塔上挂个箱子”的阶段。这不行。你想想看，一个基站出故障，你连它里面长什么样、跑什么软件、怎么跟手机对话的都不清楚，那排查起来就像盲人摸象。

我个人习惯，每次接手一个新站型，第一件事就是翻它的硬件框图和软件分层图。为什么？因为故障定位的本质，就是“猜”哪个模块出了问题。你猜得准不准，取决于你对这个系统的理解有多深。

核心观点：基站是一个“软硬结合”的实时嵌入式系统。硬件是骨架，软件是灵魂，协议栈是沟通的语言。三者缺一不可。

先看硬件。一个典型的宏基站，从物理上可以拆成三大部分：

基带处理单元（BBU）： 这是基站的大脑。负责信号调制解调、协议栈处理、资源调度。说白了，所有“算”的活都在这里。
射频拉远单元（RRU）： 这是基站的嘴巴和耳朵。负责把数字信号转成射频信号发出去，再把收到的射频信号转回来。嗯，这里要注意，RRU和天线之间还有馈线，很多驻波比故障就出在这根线上。
天线系统： 这是基站的“嗓子眼”。负责把电磁波辐射出去。MIMO天线、波束赋形，都是在这上面做文章。

我记得有一次，一个站点频繁掉线，查了三天没结果。最后我亲自上塔，发现RRU的光模块接口松了。你说这算硬件故障吗？算，但更算“物理接触不良”。所以硬件架构不只是看框图，还得懂物理连接。

避坑指南： 我曾经遇到一个案例，BBU和RRU之间的光纤损耗过大，导致CPRI链路频繁失锁。排查时，别光看光模块告警，拿光功率计测一下，往往能发现“隐形杀手”。

硬件架构的演进方向也很明确：从“BBU+RRU+天线”的三级结构，向“AAU（有源天线单元）”的一体化结构发展。说白了，就是把RRU和天线塞到一个盒子里，减少馈线损耗，提升性能。

硬件是舞台，软件才是演员。基站的软件架构，我习惯把它分成三层：

为什么这么分？因为故障定位时，你得先判断是“应用层配置错了”，还是“协议栈跑飞了”，还是“操作系统死机了”。方向错了，越查越远。

我个人经验，80%的软件故障其实出在应用层。比如参数配错、版本不兼容、License过期。协议栈层的故障相对少，但一旦出现，往往很棘手，比如RRC连接成功率低、切换失败率高。操作系统层的故障最要命，通常是内存泄漏、任务死锁，得靠抓dump分析。

警告： 千万别小看操作系统层的故障。我曾经在一个项目中，基站运行一个月后自动重启。查了两个月，最后发现是某个驱动模块的内存池设计不合理，导致碎片化严重。这种问题，日志里往往只有一句“Watchdog timeout”，但背后的原因可能很深。

协议栈，说白了就是基站和手机之间“约法三章”的规矩。没有规矩，不成方圆。你想想看，手机在空中乱发信号，基站怎么知道它想干嘛？

咱们以4G LTE的协议栈为例，从上到下分三层：

L3（网络层）： 包括RRC（无线资源控制）和NAS（非接入层）。RRC负责连接管理、移动性管理。NAS负责鉴权、附着、承载建立。我经常跟新人说，RRC信令是“基站的户口本”，所有用户的状态都在里面。
L2（数据链路层）： 包括PDCP、RLC、MAC三个子层。PDCP负责头压缩和加密，RLC负责分段和重传，MAC负责调度和HARQ。这一层是性能优化的关键。为什么你的基站吞吐量上不去？多半是MAC调度算法没调好。
L1（物理层）： 负责编码、调制、MIMO处理、资源映射。这一层离硬件最近，也是最容易出“硬故障”的地方。比如信道估计不准、同步失败，都会导致物理层失步。

举个例子，手机打电话时，流程是这样的：

手机 -> RRC连接请求 (L3) 
     -> MAC调度资源 (L2) 
     -> 物理层发送前导码 (L1) 
     -> 基站物理层检测到前导码 
     -> MAC分配上行资源 
     -> RRC建立连接

你看，一个简单的呼叫，就涉及了三个层的协同。任何一个层出问题，电话都打不通。

实战经验： 我排查故障时，习惯先看L3的信令流程。如果RRC连接建立成功，那问题大概率在L2或L1。如果RRC连接都建立不了，那问题就在L3或核心网。这叫“分层排查法”，效率极高。

5G的协议栈在LTE基础上做了增强，比如引入了SDAP层（服务数据适配协议），用于QoS流管理。但核心思想没变：分层、解耦、标准化。你只要把4G的协议栈吃透了，5G上手会很快。

好了，这一章咱们把基站的硬件、软件、协议栈过了一遍。下一章，咱们会深入具体的故障排查方法。记住，基础不牢，地动山摇。这些概念，你最好烂熟于心。