企业官网建设流程全解析

简介：面向TETRA数字集群通信系统基站与移动台物理层实现，重点覆盖发射/接收链路、LAPDm与LMAC链路接入控制层，适合通信工程专业学生、研究人员及协议算法开发者参考。压缩包共71个文件，以60个Matlab脚本（.m）为主体，包含调制、编解码、交织扰码、突发生成、同步解调等关键模块；另有8个.dat数据文件用于仿真输入输出，2个doc中文步骤说明和1个zip历史工程附件，整体大小3.59MB。资源按BS_Tx、BS_Rx、MS_Tx等目录组织，便于对照系统配置脚本和MAC数据生成逻辑进行链路级仿真。目前已有190人学习下载，是理解TETRA基站信号处理流程、开展二次开发或教学演示的实用参考资料。

1. TETRA基站的LMAC：到底是干什么的，为什么它一乱整台基站就哑火

上个月处理一个TETRA基站的线上问题：后台统计MAC层吞吐为零，但物理层上报的接收强度一直很稳。现场的对讲机抢不上信道，调度员在控制台把基站复位了两次才恢复。检查了一圈，最后发现是LMAC的子帧调度计数器走偏，把所有上行突发错排到了另一个时隙。LMAC就是TETRA协议栈里夹在物理层和LLC之间的那一层，负责时隙级的接入、调度和资源分配，但这个模块出的问题往往不会直接报错，而是让基站不知道怎么就把“听力”给丢了。

这篇文章不铺标准，直接讲基站侧LMAC怎么拆、怎么实现状态机、哪些参数值得调、以及调试时最容易踩的坑。适合正在做TETRA基站协议栈、或者接手了基站MAC层维护但还没完全摸清LMAC的开发者。如果你只是跑终端侧协议，这篇文章同样能帮你理解基站侧为什么有时候对你的接入请求“装睡”。

2. 先看懂LMAC在TETRA协议栈里的位置：上下层接口与三类核心职责

2.1 从PHY到LLC：LMAC被夹在哪一层，接口上跑什么消息

TETRA基站侧协议栈最常见的是四层：物理层（PHY）、媒体接入控制层（MAC）、逻辑链路控制层（LLC）以及上层的呼叫控制。MAC层在有些实现里还会再切一刀，分为Upper MAC和Lower MAC，也就是我们说的LMAC。Upper MAC管逻辑信道复用、加密和LLC的数据封装，LMAC则更贴近物理层，管时隙调度、突发组装、随机接入检测和资源分配。基站开发者往往把LMAC做成一个独立任务，跑在DSP或主控CPU上，与PHY通过硬件中断和共享内存交互。

LMAC和PHY之间的消息远看就两类：时间基准消息和数据突发消息。时间基准消息是PHY在每一个TDMA帧边界产生的中断或脉冲，LMAC拿它来校对自己的帧号计数。数据突发消息分上行和下行，上行是PHY解调完的数据连同信号质量参数交给LMAC，下行是LMAC把待发送的比特加上时隙号、功率等级交给PHY去调制发射。LMAC和Upper MAC之间则跑的是逻辑信道数据单元，例如SCH/HU、AACH、通知消息等，这些在LMAC眼里只是“要排进哪个时隙的载荷”。

很多人第一次看LMAC代码会觉得它没有“业务逻辑”，只有一堆状态赋值和定时器，不像呼叫控制那样有清晰的消息流。这是因为LMAC把业务逻辑压缩成了三个字：时隙对不对。它所有的工作都围绕着一个TDMA帧里那四个时隙展开。所以调LMAC的bug，第一步不是看消息，而是看你打印出来的帧号、时隙号和自己心里想的对不对得上。

2.2 帧调度、随机接入、资源分配：LMAC的三条主线

LMAC最重的活是下行帧调度。来自Upper MAC的各类逻辑信道数据，比如广播控制信道（BCCH）、公共控制信道（CCH）、话务信道（TCH）映射下来的分组，都会排队进入LMAC。LMAC要按优先级在下一帧的四个时隙里找出合适的位置，给每个分组打上时隙号，并且保证不在同一时隙放两个冲突的突发。这个调度策略直接用函数指针表实现最方便，不同业务对应不同的调度函数，而不是在同一个函数里堆if-else。

随机接入是LMAC的第二条主线。终端要入网或者要建立呼叫，会在随机接入信道（RACH）上发一个接入前缀加请求消息。LMAC这边由PHY随时检测，一旦发现能量超过门限，就上报一个“接入检测”事件。LMAC收到这个事件后要先确认当前帧有没有可用的上行时隙，有的话就在下行控制信道上回一个授权（Grant），没找到空闲时隙就延迟到下一帧。这部分最怕的就是检测事件来晚了，因为Grant一般要求紧跟接入请求，拖一帧就可能让终端等待超时重传。

资源分配是第三条主线，也是最容易被低估的。TETRA一个载波的上下行带宽有限，每个时隙被谁占用、分配给哪一个业务、什么时候释放，LMAC都记在同一张资源表里。这张表在基站里通常是16个时隙周期滚动占用情况，因为一个复帧里可能有18帧，每帧4个时隙。分配时不仅要看当前是否空闲，还要看目标驻留时间是否和已有业务冲突。LMAC资源表一旦脑子不清醒，就表现为某个用户的呼叫平时正常，另一个用户一进来，前者就被“踢下线”，而日志里看不到任何资源冲突记录。

基站侧的LMAC还要额外处理主从同步。TETRA基站组网时，不同基站在同一频点上必须严格保持帧同步，偏差控制在几百微秒以内。LMAC作为基站内时间基准的维护者，需要周期性从系统时钟模块读取基准时间，并校正自己的本地帧计数器。这个工作看起来只是个加减法，但现场故障里，因为LMAC本地帧号和交换中心侧帧号偏差导致切换失败的案例不少，后面避坑章节再展开。

3. 用状态机把LMAC落成可维护的代码：同步、业务、释放与异常处理

3.1 LMAC主状态机的四态迁移与最小实现

我自己在接手某公司TETRA基站项目的LMAC模块时，第一件事就是重画它的状态机。原代码把状态全堆在函数里，用一堆布尔变量判断“是否同步”“是否忙”，结果一个临界条件漏判就让整个调度停摆。后来重构成了四个显式状态：SYNC、IDLE、BUSY、FAIL。SYNC表示正在等待系统帧同步；IDLE是同步建立、没有业务；BUSY是至少有一个时隙正在被业务占用；FAIL是检测到内部异常，需要重建。

这四个状态的最小实现可以用C写成一个状态机结构体：

typedef enum { LMAC_STATE_SYNC = 0, LMAC_STATE_IDLE, LMAC_STATE_BUSY, LMAC_STATE_FAIL } lmac_state_t; typedef struct { lmac_state_t state; uint32_t frame_cnt; // 当前帧号，0~(N-1) uint32_t active_slots; // 当前忙时隙位图，bit0~3 uint32_t fail_retry_cnt; // FAIL状态下重建次数 } lmac_fsm_t; static lmac_fsm_t lmac_fsm; int lmac_handle_frame_start(void) { lmac_fsm.frame_cnt++; lmac_fsm.frame_cnt %= FRAMES_PER_MULTIFRAME; switch (lmac_fsm.state) { case LMAC_STATE_SYNC: // 连续收到N个有效帧脉冲才认为同步建立 if (lmac_fsm.frame_cnt == 0) { lmac_fsm.state = LMAC_STATE_IDLE; lmac_fsm.active_slots = 0; } break; case LMAC_STATE_IDLE: // 有业务分配请求时进入BUSY if (lmac_has_sched_request()) { lmac_fsm.state = LMAC_STATE_BUSY; lmac_fsm.active_slots = lmac_get_alloc_bitmap(); } break; case LMAC_STATE_BUSY: // 每个帧边界检查忙时隙释放情况 lmac_fsm.active_slots &= lmac_update_released_slots(); if (lmac_fsm.active_slots == 0) { lmac_fsm.state = LMAC_STATE_IDLE; } break; case LMAC_STATE_FAIL: if (++lmac_fsm.fail_retry_cnt >= MAX_FAIL_RETRY) { lmac_reset_all_hardware(); lmac_fsm.fail_retry_cnt = 0; lmac_fsm.state = LMAC_STATE_SYNC; } break; default: lmac_fsm.state = LMAC_STATE_SYNC; break; } return 0; }

这个状态机的关键在于：帧边界事件是唯一的驱动源，所有状态迁移都发生在帧脉冲中断里，而不是业务消息到达的时候。这样能避免多线程里“处理到一半被帧中断打断”的竞争条件。active_slots用位图记录四个时隙占用情况，释放一个时隙只需要把对应位置0，比遍历数组快得多，也方便排查问题，因为任何时刻打印这个位图就知道哪些时隙被占。

参数方面，FRAMES_PER_MULTIFRAME按TETRA复帧长度设，一般是18或者它的约数。MAX_FAIL_RETRY是故障重建次数，现场经验建议设3次，太少容易在瞬时干扰下误复位，太多会让基站长时间处于不可用状态。需要特别注意的是SYNC状态不要只等待一个帧脉冲就切出去，因为第一个脉冲可能来自不稳定的时钟，至少等一个完整的复帧周期再宣布同步成功。

3.2 和PHY的时隙对齐：TETRA帧结构里的定时接口怎么设计

TETRA的TDMA结构是一个载波上按时隙循环发射，一帧四个时隙，帧和帧之间几乎无间隔。LMAC必须保证自己发出的“时隙开始”命令精确落在真实射频时隙的起点上。这个对齐在软件里不是靠延时等待，而是靠“锁相”：PHY在时隙边界产生硬件脉冲，LMAC在脉冲中断里提前预判下一个时隙的起始时刻。

我常用的接口设计是两层：硬件层产生一个高精度定时器，设置在每个时隙起点触发；LMAC软件层在收到中断后立即读取当前状态，并把下一时隙需要的参数写入寄存器。伪代码如下：

void phy_slot_pulse_isr(uint32_t slot_idx) { // 记录当前时隙号，供调度逻辑对齐 lmac_cur_slot = slot_idx; // 提前读取下一时隙需要发射的突发描述子 lmac_burst_t *bd = lmac_get_next_burst(slot_idx); // 将突发参数写入PHY硬件寄存器，等待发射 phy_write_tx_regs(bd->modulation, bd->power, bd->freq_adj); } lmac_burst_t *lmac_get_next_burst(uint32_t cur_slot_idx) { uint32_t next_slot = (cur_slot_idx + 1) % 4; if (lmac_tx_queue[next_slot].valid) { return &lmac_tx_queue[next_slot]; } return &null_burst; // 无业务时发射填充突发 }

这段代码的核心思想是“提前一个时隙准备”。如果LMAC在时隙脉冲来了之后才开始查队列、拼突发，那么所有计算都会落在脉冲之后，造成发射抖动。提前一个时隙准备还有一个好处：可以把复杂的加密、扰码运算分散在一个时隙周期里完成，而不是集中在中断里。参数上，PHY寄存器的写入时机要留出硬件生效时间，不同PHY芯片不一样，一般是时隙起始点前几十微秒，具体得看芯片手册里的建立时间。这个值如果设太小，突发会“迟到”，导致下行突发和上行时隙轻微重叠，产生同频干扰；设太大，则又会占住上一时隙的发射窗口。

3.3 上行随机接入的应答时机：从Detect到Grant的时延预算

随机接入是LMAC里对时延最敏感的一环。终端在RACH上发出接入请求，基站LMAC需要在一定时间窗内给出Grant，否则终端就会按指数退避重试。估算这个时延预算时，我一般拆成三段：PHY检测时延、LMAC调度处理时延、下行Grant发射等待。

PHY检测时延取决于实现方式。有的基站在FPGA里做能量检测和码相关，检测完成后直接置位一个寄存器，时延通常在几毫秒以内；有的用DSP做全软解调，这时延可能拉到十几毫秒。LMAC调度处理时延是把接入检测事件放到调度队列，再在下一个下行时隙发出Grant。这里最常见的坑是：LMAC把接入检测当普通业务消息处理，经过消息队列排队，导致时延波动。实际上，接入响应应该走“快速通道”——在PHY中断里直接读取检测结果，标记一个pending接入标志，然后在下行调度函数里优先处理这个标志。

下面是一个简化的快速通道实现思路：

static bool pending_rach_detected; void phy_rach_detect_isr(void) { pending_rach_detected = true; } void lmac_schedule_downlink(uint32_t free_slot) { if (pending_rach_detected) { lmac_build_grant(free_slot); pending_rach_detected = false; return; } // 普通下行调度 ... }

这个设计牺牲了一点普通业务的公平性，但换来的是接入响应时延稳定。参数上，Grant消息必须在检测到接入后的下一帧或下下一帧内发出，具体看终端实现的上限。现场验证时，可以用一个在终端侧打点的方法：终端发RACH后本地记录时刻，收到Grant后记录另一个时刻，两者差就是整体接入响应时延。如果该时延波动超过一帧时间，多半是LMAC没有走快速通道，还在公平排队。

4. 基站侧LMAC必调的5个参数：取值参考与调优顺序

4.1 与调度时序强相关的4个参数

LMAC的参数不像业务层那么多，但每一个都和现场性能直接挂钩。我把最常调的几个整理成了下表，按重要性排序。

下行帧偏移尤其关键。TETRA基站一般工作在同一载波的上下行方向交替占用时隙，终端侧需要知道基站下行时隙相对上行时隙的偏移规律，这个信息通过广播告诉终端。如果基站LMAC实际发射的下行位置和它广播给终端的偏移不一致，终端就会一直收不到控制信道。所以调这个参数时，必须在基站侧用频谱仪实测下行突发出现的位置，再和配置的偏移值比对，不要只看软件配置。

RACH接入前缀长度在弱覆盖工程里经常被提到。实际做法是先用默认值5符号，然后在最远覆盖点做接入测试，发现检测不到就逐步增加前缀长度。代价是RACH一个时隙能容纳的接入尝试次数下降，因为前缀长了，可用空间就少了。这个参数需要和物业管理协商好覆盖半径再定，不能一刀切。

4.2 参数文件的组织与热加载校验

LMAC参数一般放在一个独立的配置结构体里，不要散落到各个函数里硬编码。我习惯用一个全局配置实例，加载时做范围和校验检查：

typedef struct { uint32_t frame_offset; // 0~3 uint32_t rach_preamble_len; // 符号数 uint32_t rach_max_retrans; // 最大重传次数 uint32_t sched_advance_us; // 调度提前量 uint8_t tx_power_step_db; // 功率控制步长 uint32_t cfg_crc; // 配置校验值 } lmac_config_t; static lmac_config_t g_lmac_cfg; int lmac_config_load(const uint8_t *buf, uint32_t len) { memcpy(&g_lmac_cfg, buf, sizeof(g_lmac_cfg)); if (g_lmac_cfg.frame_offset > 3) return -1; if (g_lmac_cfg.rach_preamble_len < 5 || g_lmac_cfg.rach_preamble_len > 9) return -1; if (g_lmac_cfg.rach_max_retrans > 7) return -1; if (g_lmac_cfg.sched_advance_us > 200) return -1; // 计算CRC并存储，运行时周期性校验 g_lmac_cfg.cfg_crc = calc_crc32(buf, len - 4); return 0; }

这里每个参数的范围校验来自实际协议和硬件限制。比如frame_offset超过3就从时隙级变成帧级，终端侧无法识别；rach_preamble_len小于5时，设备在覆盖边缘检测概率很低；sched_advance_us超过200又可能导致写入PHY时已经是下一时隙的起始点。校验完后把CRC存起来，运行时每秒钟重算一次配置区，防止内存翻转或误写导致LMAC行为突变。这个习惯救过我一次，某次现场电磁干扰把配置区的数值打坏了，LMAC随机分配时隙，如果没有CRC周期性校验，根本定位不到是配置坏了。

4.3 调参之后的验证方法：别只看“能入网”

调完参数后，很多测试人员只看终端能不能注册入网，然后就说“效果正常”。这远远不够，LMAC参数调整的影响往往是统计性的，单次入网成功说明不了问题。我一般会做一轮持续10分钟以上的接入压力测试，统计接入成功率、平均接入时延、重传次数分布。

现场可以用一个简单的终端侧日志脚本来抓这类数据。假设终端日志每行包含时间戳和事件类型，提取RACH_SENT和GRANT_RECEIVED事件：

import re from collections import deque events = deque() with open("terminal_log.txt") as f: for line in f: m = re.match(r"(\d+)\s+(\w+)", line.strip()) if not m: continue ts, evt = m.groups() events.append((int(ts), evt)) success_cnt = 0 retx_cnt = 0 last_sent = 0 for ts, evt in events: if evt == "RACH_SENT": last_sent = ts retx_cnt += 1 elif evt == "GRANT_RECEIVED": delay = ts - last_sent if delay < 3000: # 以毫秒为单位 success_cnt += 1 retx_cnt = 0 print("access_success_delay_avg_ms", ...) print("retrans_rate", ...)

这个脚本不追求精确，但能快速看出两个指标：接入成功时延是否都在终端重传定时器范围内，以及重传次数是否集中在一两次内。如果重传率高且Grant时延接近超时门限，基本可以确定是LMAC的快速通道没生效或者响应时延预算超了。

5. LMAC调试避坑指南：5个让基站翻车的常见问题与排查路径

5.1 现象：上行突发解调失败率飙高，但PHY指标全绿

某个室外基站出现单向故障：终端上报下行接收正常，但基站侧解调上行凭空多出许多误码。查PHY层的AGC、信噪比都正常，射频线缆也换过，问题依旧。后来抓了LMAC的调度日志，发现时隙脉冲到来时，LMAC总比预期晚几十微秒才把接收解调参数写入PHY的寄存器窗口。原因是LMAC任务里有一个耗时很长的下行加密计算，把后面的上行配置写入挤到了时隙边界之后。

解决方法是把加密计算挪到下行突发已经发射之后、下一时隙脉冲之前，并给上行配置写入加上一个“超时保护”：如果在时隙脉冲到达前还没有写完配置，就强制放弃该时隙的上行接收，而不是写一半。这样至少不会因为寄存器状态错乱把后续所有时隙都带偏。

5.2 现象：呼叫接入正常，但持续掉话，间隔特别规律

有一次模拟项目里，基站下的终端每次通话到约30秒就掉。掉话间隔非常规律，像打卡一样。一开始怀疑是交换侧释放，后来发现终端掉话的时候，LMAC日志里有一条“帧号不连续”的警告。根源是LMAC每30秒会从一个外部时间源校准一次本地帧号，但校准逻辑写成了直接赋值，导致帧号跳变。终端在下一帧收不到预期广播信息，认为失步就释放了呼叫。

正确做法是校准帧号时做“步进式调整”，每次只补偿一帧的偏差，而不是一次性跳变。现场改完后再也没有规律掉话。

5.3 现象：LMAC与LLC之间消息积压，复位后恢复

基站长时间运行后，LLC发来的下行数据在LMAC的队列里越堆越多，导致新到的高优先级接入响应排不进去，最终接入请求全部超时。复位后队列清了，一切恢复。查代码发现LMAC把队列设计成无界链表，LLC没有背压反馈。真正的问题是LMAC处理完一个帧后，会一口气向队列写出这一帧允许发送的最大字节数，但如果当前有高优先级调度要做，它就把普通数据暂时压下，而不会给LLC一个暂停信号。

解决方法是给队列设上限，达到80%时向LLC发送“暂停发送”的流控原语，同时把高优先级调度并入同一帧调度函数，减少排队的义务。这样能保证LMAC永远不会因为数据积压而忽略接入响应。

5.4 现象：多基站组网时，邻区同步偏差导致切换失败

组网环境里，各基站LMAC的帧号同步来自同一个PTP时钟源，但检查发现相邻基站的帧偏移相差超过半个时隙，导致终端跨基站切换时，候选目标基站在预期时刻收不到终端的信号。LMAC里维护帧号的代码独占一个定时器，没有跟随系统时钟的平滑校正，PTP在网络上跳变一次，基站本地帧号就跟着跳变一次。

解决办法是LMAC不再直接读取系统时钟计数，而是用低通滤波的方式跟踪：每帧计算系统时钟与本地时钟的偏差，按一个很小的系数修正本地帧计数器。这样既能保持相位对齐，又不会因为时钟源的瞬时扰动造成跳变。

5.5 现象：随机接入回退参数改了不生效

现场调大最大重传次数后，观察终端行为还是老样子。查LMAC配置加载函数发现，参数文件被读取后只是校验了CRC，但真正写入寄存器用的是另一份编译期常量。改配置文件永远碰不到那个常量，所以不生效。这类“改了个假参数”的问题比逻辑bug更隐蔽。解决方法是把配置来源统一，让运行时配置区覆盖编译期默认值，并且在LMAC启动日志里打印当前生效的参数值和CRC，方便维护时一眼看出到底加载的是哪份配置。

6. 进阶：用一对时间戳把LMAC调时延调到“卡点”

LMAC的时延问题，尤其是时隙级抖动，只靠软件日志很难定量。我最终的调试习惯是在基站主控板上找两个GPIO：一个在PHY帧脉冲到来时拉高，另一个在LMAC把下一时隙参数写入PHY寄存器时拉高。把这两个信号同时接到逻辑分析仪上，就能直接量出“调度处理时延”和“提前量余量”，比任何日志都准。

操作上，先测量正常帧时的时延基线，比如30微秒，然后故意加大负载，比如同时发起多路呼叫，再看这个时延有没有被拉长到超过你设定的提前量。如果超过，说明提前量配置太小，或者调度函数里出现了不该有的串行计算。调优时，把sched_advance_us设成基线时延的两倍以上，再留一点余量给温度漂移。这样能在大部分工况下稳定运行，而不是只在实验室环境正常。

有一次我在现场就靠这个办法定位了一个棘手问题：基站时钟源偶发跳变，但只有逻辑分析仪才看到帧脉冲之间的间隔从标准的4时隙周期突然变成3个半，日志里完全看不出来。顺着这个线索找到是参考时钟锁相环失锁导致间隔抖动，而不是LMAC逻辑问题。从那以后，我养成了一个习惯：任何LMAC改动都必须先打点测一次时序，再谈功能验证。没有时序证据的改动，和玄学没区别。

如果你也正在被TETRA基站调度问题折磨，建议先从GPIO打点开始，用一对时间戳把LMAC的“看不见的时延”变成看得见的波形，少走很多弯路。希望帮到你。

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