企业官网建设流程全解析

每次拿到一台需要做外场验证的终端样机，我第一件事不是看吞吐，也不是看信令流程，而是把物理层日志打开，盯着小区搜索这一段看它从开机到驻留花了多久、中间有没有反复重搜。LTE小区搜索这个过程，协议文本摊开来看并不算多——36.211管同步信号，36.212和36.213管PBCH，36.331管小区选择和驻留——但真落到代码里，它是整个物理层最"脏"的一段。没有先验信息、没有信道估计、没有反馈，你要在一堆噪声里把定时、频率、小区身份、系统带宽、天线端口数一个一个抠出来，抠错一个后面全盘皆输。

这篇文章我打算按工程实现的顺序把这条链路拆开讲：PSS怎么在未知频偏下把5ms定时抓住，SSS怎么把小区组、帧定时和CP类型一起解出来，CRS和PBCH怎么把PCI变成能用的MIB，最后怎么判断这个小区到底能不能驻留。刚接触物理层的新人可以把这当成一份实现路线图，做了很久上层协议的同行也能从这里看清楚"底下到底发生了什么"。文中涉及的参数取值和门限都是我实际调过的，不同芯片平台会有差异，但思路是通的。

1. 小区搜索到底在解决什么问题

1.1 一台终端从"两眼一抹黑"到"能解一个比特"

终端刚上电那一刻，它对网络的认知基本是零：不知道中心频点在哪、不知道子帧边界在哪、不知道自己的晶振偏了多少、不知道小区ID是几、不知道带宽是1.4MHz还是20MHz、不知道是TDD还是FDD、不知道基站几个天线端口。这些量全都得从空口那点广播信号里"猜"出来，而且不能瞎猜，得按协议规定好的层次一层一层剥。

LTE设计者在这里做了一个很聪明的取舍：PSS和SSS只占用中心62个子载波，也就是大约1.08MHz。这个决定意味着无论系统带宽是6个RB还是100个RB，同步信号永远落在频谱正中间，终端可以用一个固定的低采样率去做搜索，根本不需要先知道带宽。反过来想，如果同步信号铺满整个带宽，终端在不知道带宽的前提下就没法做相关，整个流程会陷入死循环。

同步信号还承担了另一个隐含任务：给终端一个"频率锚点"。终端本振的初始偏差可能达到十几ppm，在2GHz频段就是几十kHz，而LTE子载波间隔只有15kHz，频偏超过7.5kHz就会开始破坏子载波正交性。所以小区搜索的第一要务不是解出信息，而是先把频率拉回到能解调的范围内，然后再谈其他。

1.2 四个阶段和各自的产出物

把整条链路摊开，小区搜索可以分成四级台阶，每一级都建立在前一级的产出之上，顺序不能乱。我把每一级的输入、输出和典型耗时整理成下面这张表，方便对照自己的实现看卡在哪一步。

为什么这个顺序不能调换？因为SSS的检测需要知道PSS给出的5ms边界和N_ID_2，PBCH的解调需要知道PCI才能生成解扰序列和CRS位置，SIB1的调度又依赖MIB里的带宽和PHICH配置。每一级都在给下一级"解锁"一个未知量。我见过有团队为了省时间，想跳过SSS直接从PSS硬解PBCH，结果就是解扰序列错了，CRC永远过不了。

还有一个容易被忽略的点：这四级台阶并不是严格串行的。实际实现里，PSS检测通常会保留多个候选峰，每个峰都往下走一遍SSS，最后按PBCH的CRC通过率反选。这种"多假设并行、末端校验"的结构比"一级一级往下传单一结果"要稳得多，尤其是在多径严重或者存在同频邻区干扰的场景下。

2. PSS检测：把5ms定时和N_ID_2先攥在手里

2.1 ZC序列的三个根和它的好脾气

PSS用的是频域Zadoff-Chu序列，长度63，实际映射62个点，中间那个直流子载波空着不用。序列由根索引u决定，LTE定义了三个根：25、29、34，分别对应N_ID_2等于0、1、2。这三个根不是随便挑的，它们之间的互相关峰值明显低于自相关峰值，终端做三路并行相关时不容易互相串扰。

ZC序列有两个性质对同步特别友好。第一是恒幅，频域上每个点的模都是1，这意味着PSS在时域上的峰均比可控，基站的功放压力小。第二是理想周期自相关，序列和自己的循环移位正交，除了零点之外相关值都是零。第二条直接决定了定时估计的精度——相关峰极窄，多径环境下主峰和次峰能分得开。

更关键的是，ZC序列在存在频偏时相关峰不会立刻塌掉。频偏会造成峰值幅度的轻微下降和相位的匀速旋转，但峰的位置基本不动。这就是为什么LTE敢让终端在频偏完全未知的情况下先做定时同步——先抓住时间，再慢慢修频率，两件事解耦了。

三个根的具体生成方式，我按协议写了一段生成代码，实际工程里可以直接查表，没必要每次现算：

import numpy as np def gen_pss_freq(u): """生成 62 点频域 PSS 序列，u 取 25 / 29 / 34""" d = np.zeros(62, dtype=complex) for n in range(31): d[n] = np.exp(-1j * np.pi * u * n * (n + 1) / 63) for n in range(31, 62): d[n] = np.exp(-1j * np.pi * u * (n + 1) * (n + 2) / 63) return d def map_to_grid(d, n_fft=128): """把 62 点映射到 128 点 IFFT 的中心，跳过直流""" grid = np.zeros(n_fft, dtype=complex) half = len(d) // 2 # 31 grid[1:1 + half] = d[:half] # 正频率 grid[n_fft - half:] = d[half:] # 负频率 return grid

这段代码里有个细节值得说：正负频率的映射顺序必须和协议一致，否则生成出来的时域序列和基站侧对不上，相关峰直接消失。我自己就被这个问题坑过一次，排查了大半天才发现是频谱搬移的方向搞反了。

2.2 时域滑动相关的采样率取舍

PSS只占1.08MHz，理论上用1.92MHz采样就够了（对应128点FFT，子载波间隔15kHz）。实际产品里几乎都是这个配置：先把宽带信号降采样到1.92MHz，在这个低速率上做全窗口滑动相关，找到候选位置之后再升采样做精处理。

这么做的好处很直接。以20MHz带宽为例，30.72MHz采样下5ms窗口有153600个点，直接做时域相关运算量惊人；降到1.92MHz之后只有9600个点，运算量降了256倍，而PSS的信息一点没丢。这是典型的"用带宽换算力"，代价是对定时精度的分辨率下降到约0.52微秒，不过这个损失在后面用CRS精同步能补回来。

滑动相关的实现有两种常见写法。一种是直接时域卷积，用三个本地PSS模板分别和接收数据做相关，取模平方；另一种是转到频域做乘法再IFFT。后者在长窗口下更快，尤其是用FFT做分段重叠的时候。我一般倾向于频域实现，代码更短，而且天然支持批量处理多个候选频点。

搜索窗的长度至少要覆盖一个PSS周期，也就是5ms。但实际实现里通常取10ms，原因是要覆盖完整的无线帧，方便后续和SSS做联合判决。如果终端刚上电时频偏极大，我甚至见过取20ms窗口做多次非相干累加的做法，牺牲一点时延换检测概率。

门限的设定是个经验活。教科书上写的是"取相关峰最大值"，但实际信号里经常出现多个幅度接近的峰，单纯取最大值很容易锁到邻区或者噪声上。我的做法是归一化：把每个位置的峰值功率除以窗口内的平均功率，得到一组比值，然后取比值超过某个绝对门限的所有峰作为候选，通常保留前4到8个。这个门限在不同场景要调——空旷外场可以设高一点，室内或者强干扰环境要放低，否则真实小区会被漏掉。

提示：多径环境下同一个PSS的相关峰会扩展成一簇，主峰旁边跟着几个衰减的次峰，间隔通常在一个CP长度以内。做候选选取时必须先做峰合并，把CP窗内的所有峰归并成一个，否则后面的SSS检测会重复处理同一小区，白白浪费算力。

2.3 频偏粗估：相关峰的相位怎么用

定时抓到了，接下来要解决频率。频偏粗估有几种常用手段，各有各的适用区间。

第一种是利用PSS在时域上的重复性。PSS每5ms出现一次，两次之间隔了5毫秒，用相邻两个PSS相关峰的相位差可以估频偏，公式是Δf = Δφ / (2π·T)，T等于5ms。这个方法的精度很高，理论上能做到几十Hz，但测量范围被相位卷绕限制住了——相位差超过π就分不清是正偏还是负偏，对应最大可测频偏只有100Hz。它适合在已经粗同步之后做微调，不适合初始捕获。

第二种是利用PSS序列自身的结构。时域PSS具有一定程度的对称性，把接收到的PSS分成前后两半做相关，相位差能反映频偏，可测范围扩大到±7.5kHz左右，正好覆盖一个子载波间隔的一半。这是初始搜索阶段最常用的做法。

第三种是频域移位搜索。检测到PSS位置后，对那一段做FFT，观察62个非零子载波的频谱是否整体偏移，偏移量就是频偏的估计。这个方法的范围可以做到±15kHz以上，代价是要多做几次FFT，复杂度高一些。

实际工程里通常是组合使用：先用频域移位或者半段相关做粗估，把频偏压到±2kHz以内，再用CRS做精估。我调过的平台大多在粗估阶段就能把残余频偏控制在1kHz以下，后面CRS精估只是锦上添花。

这里有一个必须注意的边界条件：当真实频偏接近或超过7.5kHz时，PSS相关峰会明显降低，超过15kHz时可能完全检测不到。所以初始搜索必须假设一个较大的频偏范围，不能想当然认为晶振是准的。我遇到过一批样机，晶振批次一致性差，常温下就偏了12kHz，用标准流程死活搜不到小区，最后是把粗估范围放大到±20kHz才解决。

3. SSS检测：10ms帧定时、CP类型和小区组

3.1 交织的m序列结构和168个假设

PSS只告诉了终端"每5ms有个边界"和"小区ID模3的余数"，剩下的小区组信息、10ms帧边界、CP类型全在SSS里。SSS和PSS占同样的频域位置——中心62个子载波——但它是频域交织结构：偶数子载波上放一个长度31的m序列，奇数子载波上放另一个，两个序列各自做循环移位，移位量由小区组编号N_ID_1决定。

N_ID_1的取值范围是0到167，一共168个小区组，乘以PSS给出的3个N_ID_2，正好凑成504个物理小区ID。这个数字不是随便定的——504在保证相邻小区PCI不同的前提下，还能让终端做相关时的复杂度可控。

SSS在时域上的位置是子帧0和子帧5的倒数第二个OFDM符号（常规CP下），也就是每个无线帧出现两次。但这两次的序列并不相同：子帧0和子帧5的SSS在第二个m序列上做了不同的加扰，这个差异正是终端区分半帧、进而确定10ms帧边界的依据。

我见过不少人第一次看这段协议会绕进去，觉得"既然PSS已经给了5ms，为什么还要SSS来定10ms"。原因是PSS每5ms重复一次，从PSS本身根本分不出这是帧头还是帧中。SSS的两次不同版本才提供了这个区分度。这也是为什么小区搜索必须PSS和SSS配合，缺一不可。

3.2 相干还是非相干：先活下来再谈性能

SSS的检测算法分两派：非相干和相干。

非相干检测的做法是分别对偶数子载波和奇数子载波上的序列做相关，两路结果取模平方再相加。它不需要任何信道相位信息，所以对残余频偏和定时误差都不敏感，鲁棒性极好。代价是损失了约2到3dB的检测性能，因为两路信号的能量没有做相干合并。

相干检测则先用PSS或者CRS做信道估计，把接收信号的信道相位补偿掉，再做相关。性能能提升几个dB，但对定时精度和频偏残余非常敏感——如果精同步没做好，相干合并反而会互相抵消，效果比非相干还差。

初始小区搜索阶段的现实是：此时还没有CRS可用（因为PCI还没定），PSS给出的相位参考又受频偏影响，所以绝大多数实现都选非相干。等到PCI解出来、CRS能生成了，后面做邻区测量或者重选时可以切到相干检测提升灵敏度。

我的建议是不要在初始搜索阶段追求那2dB。真正决定成败的是能不能在弱信号下把小区搜出来，而不是搜出来之后解得多干净。与其在算法上抠相干合并，不如把非相干的相关窗口做长一点、做几次跨帧累加，收益更明显。

3.3 半帧判决与CP类型盲检的联合处理

SSS检测要处理的假设空间比PSS大得多：168个小区组、2个半帧位置、2种CP类型，理论上672种组合。如果再加上TDD和FDD的盲检，假设数还要翻倍。

但实际实现不会真的穷举。PSS已经给出了N_ID_2，SSS的相关只需要在168个N_ID_1上做，半帧位置只有两种，可以用一次相关同时得到两个位置的度量。CP类型的处理稍微麻烦一点，因为常规CP和扩展CP下SSS与PSS的相对符号间隔不同：常规CP下SSS在PSS前一个符号，扩展CP下间隔也不一样。

一个实用的简化是：先按常规CP做检测，因为现网绝大多数宏站和小站都用常规CP，扩展CP主要出现在特定场景（比如多径时延特别大的覆盖场景）。只有常规CP下所有假设都失败，才去试扩展CP。这样能把平均搜索时间压下来。

TDD和FDD的盲检也类似。FDD下PSS在子帧0和5的最后一个符号，TDD下PSS在子帧1和6的特殊时隙里，两者在帧内的绝对位置不同。终端在初始搜索时确实不知道网络制式，必须两种都试。好在两种制式下PSS的序列完全一样，区别只在相对位置，所以可以在PSS检测阶段就让每个候选峰同时保留FDD和TDD两种解释，交给SSS去甄别。

注意：CP类型判错的后果很隐蔽。你会看到PSS和SSS都能解出来，PCI也是对的，但后面解PBCH时CRC一直不过，因为OFDM符号的边界整体偏了。排查时不要只盯着PBCH的编码链路，先把CP类型打出来确认一下。

4. CRS与PBCH：把PCI变成可用的系统信息

4.1 CRS精同步与频偏精估

到这一步，终端手里已经有了PCI和10ms帧定时，接下来可以用小区专用参考信号做精细化处理。CRS的序列由PCI和时隙号共同决定，在频域上是伪随机的QPSK符号，终端本地可以完全复现。

用本地CRS和接收信号做最小二乘信道估计，能得到几样东西。第一是精定时：把频域信道估计变换到时域，冲激响应的第一个有效抽头位置就是精确的符号边界，精度可以做到采样点级别。第二是精频偏：同一时隙内不同CRS符号之间的相位差反映了频率偏差，公式还是Δf = Δφ/(2π·Δt)，只不过这里的Δt是两个CRS符号的间隔，大约是0.286毫秒，对应的可测范围约±1.75kHz，精度能到几十Hz。第三是RSRP，用CRS上的接收功率做线性平均，这就是终端上报的参考信号接收功率。

这套流程里有个容易踩的坑：定时精度的基准。PSS相关给出的定时精度受采样率限制，在1.92MHz下是半个采样点量级，换算成时间大概0.26微秒，对应距离约78米。这个误差在普通场景下无所谓，但在多小区交界处会影响后续的测量上报。所以精同步这一步不能省，尤其是要做邻区测量和切换的场景。

另外一个细节是多普勒。高速移动下，CRS的相位在每个符号之间都在旋转，简单的相邻符号相位差会低估频偏（因为相位卷绕了）。这时候要用多个符号做联合估计，或者用PSS的5ms间隔做粗估、CRS做细调的级联结构。我处理过高铁场景的数据，时速300公里下多普勒频移能到2kHz以上，单靠CRS的短间隔估计会误判方向。

4.2 PBCH盲检：天线端口、SFN和带宽

PBCH是小区搜索里最后一个"硬骨头"。它承载MIB，位置固定在子帧0的第二个时隙，占用中心6个RB的前4个OFDM符号，扣除CRS占用的资源后剩下240个资源粒子，QPSK调制后每帧480比特，四个无线帧凑成1920比特做一次完整的速率匹配。

终端要解PBCH，必须同时猜对三件事：天线端口数、加扰序列版本、以及部分编码参数。

天线端口数的盲检靠CRC掩码实现。协议规定用不同的掩码对PBCH的CRC做异或，1端口、2端口、4端口各对应一种掩码组合。终端把这三种（实际上是四种，还有一种保留）假设都试一遍，哪个CRC能过就是哪个。这个设计很巧妙，用一次CRC校验同时完成了信道解码和数据校验。

加扰序列版本对应的是SFN的低2位。PBCH的加扰序列由PCI和SFN模4的结果共同决定，所以40ms周期内的四个帧虽然承载相同的MIB内容，但加扰不同。终端通过尝试不同的解扰序列，可以反推出当前帧在40ms周期里的位置，从而补齐SFN的低位。

带宽信息则直接编码在MIB的前3个比特里，编码规则是固定的六档：6个RB、15个RB、25个RB、50个RB、75个RB、100个RB，对应000到101。终端解出这3个比特，立刻就知道后面PDCCH该按多大的带宽去盲检。

实测下来，PBCH的盲检是整条链路里最耗时的一步。40ms的周期意味着终端最坏要等四个帧才能凑齐一次完整解码，加上前面的同步和SSS，从开机到拿到MIB，快的话一百多毫秒，慢的话能到五六百毫秒。优化手段主要是复用已解码的软比特做增量合并，而不是每个40ms都从头解。

4.3 从MIB到SIB1，驻留判决的最后一公里

MIB只是入场券，真正决定能不能驻留的是SIB1。SIB1的调度信息隐含在MIB的PHICH配置里，终端按固定规则算出SI-RNTI加扰的PDCCH搜索空间，在子帧5上盲检，解出PDSCH，才能拿到PLMN列表、跟踪区码、小区禁止标志、接入等级禁止列表这些关键参数。

拿到这些之后，驻留判决按S准则做：

Srxlev = Qrxlevmeas - (Qrxlevmin + Qrxlevminoffset) - Pcompensation Squal = Qqualmeas - (Qqualmin + Qqualminoffset) Pcompensation = max(PEMAX - PPowerClass, 0)

举个实际算例。假设测得的RSRP是-85 dBm，SIB1里广播的Qrxlevmin是-60（信令单位是2dBm，实际是-120 dBm），Qrxlevminoffset为0，PEMAX和终端功率等级都是23dBm，那么Pcompensation等于0，Srxlev = -85 - (-120) - 0 = 35 dB，大于0，判决通过。

这套公式看起来简单，实际配置里有不少门道。比如Qrxlevminoffset只在周期性搜索高优先级PLMN时才用，平时是0；Pcompensation在终端功率等级低于基站允许的最大发射功率时才非零，这时候弱覆盖边缘的终端会更难驻留，这是设计意图——避免上行受限的终端死抱着一个小区不放。

还有一类情况容易被忽略：小区禁止和PLMN选择是两回事。S准则通过只代表射频条件够，如果这个小区的PLMN不在终端的等效PLMN列表里，或者cellBarred标志置位，照样不能驻留。我在外场调过一台样机，死活驻不上某个小区，查了半天射频指标都正常，最后发现是这个小区广播了cellBarred，属于规划内的禁止接入，跟终端没关系。

5. 常见问题速查与实测避坑

5.1 一张表对完大部分现场问题

小区搜索的问题表现得很"集体"：要么啥也搜不到，要么搜到了但后面解不开。我把这些年遇到过的高频问题整理成下表，按现象倒查原因，能省不少时间。

这张表里最值得展开的是第二行。PSS有峰而SSS全失败，十有八九是CP类型的问题。因为PSS的检测本身对CP不敏感（它只关心序列相关），但SSS的位置依赖CP类型，一旦判错，采集窗口就整体偏了，相关值自然上不去。我的经验是：只要SSS全军覆没，第一件事就是把CP类型强制成另一种再跑一遍，五分钟能定位的问题不要花五小时。

第四行也常见。频偏残余会让PBCH的星座点缓慢旋转，短时间内CRC可能还能过，但误码率会明显偏高。这种情况下不要怀疑编码链路，先去看频偏估计是不是收敛了。我一般会在日志里同时打印粗估和精估的结果，两者的差值如果超过500Hz，基本可以确定是估计环节出了问题。

5.2 几个只有踩过才知道的细节

第一个细节是关于相关峰的门限归一化。很多人用绝对功率做门限，结果换一个增益档位就要重新调参。正确做法是用窗口内的平均功率做归一化，得到一个无量纲的比值，这样增益变化不会影响判决。但归一化的分母也有讲究：如果用整个窗口的平均功率，强干扰环境下门限会被抬高，弱小区漏检；我的做法是用中值滤波后的噪声底估计做分母，抗突发干扰能力强一些。

第二个细节是采样时钟偏差。终端晶振和基站晶振的频率不可能完全一致，采样时钟的偏差会在长时间接收中累积成定时漂移。小区搜索阶段通常只有几百毫秒，影响不明显，但如果要做长时间的测量或者多小区联合处理，就必须做采样时钟跟踪。我见过一个案例，终端在弱信号下反复重搜，最后定位到是采样时钟偏差导致定时逐渐滑出CP窗口，加了一个简单的定时跟踪环就解决了。

第三个细节是关于多假设的排序。假设空间大的时候，先试哪个后试哪个直接影响平均搜索时间。合理的顺序是：先试概率最高的组合（常规CP、FDD、半帧0），再逐步扩展到低概率组合。现网里TDD和扩展CP的占比都不高，把它们排在后面能显著降低平均时延。当然这个顺序要根据目标网络的实际情况调整，不能照搬。

第四个细节是RSRP的测量带宽。协议允许在多个带宽上做RSRP测量，窄带测量的结果和宽带测量可能差好几个dB。做驻留判决时要用和SIB1里配置一致的测量带宽，否则会出现"测量值够但驻不上"的诡异现象。这个问题在异构网络里特别容易碰到，因为宏站和小站的发射功率、带宽配置都不一样。

6. 一套可复现的验证方案

6.1 采样率、搜索窗与门限的工程取值

如果要在自己的平台上复现这套流程，下面这组参数可以直接拿来当起点，我调过的几个平台基本都是在这个附近微调。

采样率的选择有一个权衡：1.92MHz足够覆盖PSS和SSS，但做不了全带宽的RSRP测量。实际实现通常是双速率结构——低速率做同步搜索，同步完成后切到高速率做PBCH解调和测量。切换的时机要选在SSS解出PCI之后，因为PBCH的解调需要PCI来生成解扰序列。

门限的设定没有普适值，必须结合自己平台的噪声系数和AGC策略来调。一个比较稳妥的办法是先在实验室用信号源做灵敏度扫描，把不同SNR下的相关峰比值统计出来，画一条ROC曲线，然后按目标检测概率反推门限。这个过程看起来繁琐，但一次做完能管很久。

6.2 用软件无线电搭一个最小闭环

想真正搞明白这套流程，光看协议不够，得自己跑一遍。用一块通用的软件无线电板卡加一台信号源，就能搭出最小验证环境。

第一步是产生基带信号。可以自己按协议生成PSS、SSS、CRS和PBCH，也可以抓一段现网的空口数据回放。自己生成的好处是所有参数都可控，能很方便地构造极端场景，比如人为加大频偏、改CP类型、换天线端口数。

第二步是接收和解调。把板卡采到的数据降采样到1.92MHz，按前面说的顺序做PSS相关、SSS相关、CRS信道估计、PBCH盲检。建议把每一步的中间结果都存下来，包括相关峰的位置和幅度、SSS的度量值、PBCH各假设的CRC结果。这些数据在排查问题时比最终结果有用得多。

第三步是做参数扫描。把频偏从-20kHz扫到+20kHz，步进500Hz，记录每个点的PSS检测概率；把SNR从-10dB扫到10dB，记录PCI正确率和MIB正确率。这两条曲线做出来，你对这套流程的理解会比读十遍协议都深。

我自己做这套验证的时候，最大的收获不是算法本身，而是发现了几个协议里没写、但实际实现必须处理的边界情况。比如当两个候选PSS峰的间隔恰好等于CP长度时，峰合并的逻辑会失效，导致同一个小区被当成两个；又比如当频偏接近子载波间隔的一半时，SSS的非相干检测会出现系统性的偏差，需要用频偏补偿后的数据重做一遍。这些问题在仿真里很难复现，只有在真实信号上跑才会暴露。

如果手上没有硬件，退一步用开源的空口数据集做离线分析也行，虽然少了射频链路的影响，但同步和盲检的逻辑是一样的。关键是不要只看最终结果，要把中间量都打出来，搞清楚每一步的判决是怎么来的。小区搜索这段代码，写出来容易，调稳定难，绝大部分功夫都花在那些看起来"应该没问题"的地方。