企业官网建设流程全解析

前阵子和一个做无线优化的朋友争论了很久：某地市打算把一段1800MHz存量LTE频谱清出来给5G用，另一波人则主张在原载波上直接上Dynamic Spectrum Sharing（DSS），两边吵得不可开交。这种争论在5G建设进入深水区之后特别常见——频谱资源就这么点，高频段覆盖撑不起来，低频段还被4G和VoLTE占着，NR/5G动态频谱共享就成了看上去最省事的折中方案。这篇文章我就把自己从DSS方案评估、参数配置到实际排障的完整经历整理出来，尽量说清楚DSS到底解决了什么问题、底层资源是怎么让出来的、实测中会遇到哪些坑。适合无线网优工程师、核心网信令分析人员，以及给行业客户做5G模组和CPE集成的朋友参考。

1. 为什么运营商愿意在低频段上折腾DSS：频谱现状与部署动机

1.1 低频段重耕的现实约束

5G覆盖最缺的不是带宽，而是低于1GHz的频段。700MHz、800MHz、900MHz这些频段的传播特性好、穿透力强，一个站的覆盖半径可以做到中频段的几倍。问题在于，这些低频段几乎都被存量LTE网络和VoLTE语音占着，你想让5G用，就得先把里面运行的4G用户迁走、把设备频率改掉，这就是频谱重耕。听起来简单，实际牵一发动全身：终端更换周期、物联网卡存量、语音业务的连续性、原有网络的容量消化，每一项都要花几个月甚至更长时间推进。

从投资角度看更直白：中频段3.5GHz覆盖半径小，市区站间距可能只有两百米到五百米，农村和郊区更夸张。如果没有低频打底，5G覆盖成本是一个根本没法向管理层交代的数字。所以很多运营商把DSS当作过渡期的“缓兵之计”：不着急清频，先在现网LTE载波上把NR开起来，用低频解决连续覆盖，用中频解决热点容量。

1.2 静态共享与动态共享的根本差异

很多人把DSS和静态频谱共享混为一谈，这是第一个容易踩的误区。静态共享的做法很暴力：在LTE侧固定配置一部分MBSFN子帧留给NR用，LTE再饿也不能碰这些子帧。好处是配置简单、干扰可控，坏处是NR没有业务的时候这些子帧也是空的，频谱利用率反而下降。

DSS强调的是“动态”两个字，调度器会根据LTE和NR两边的实时业务量来判决每个子帧归谁用。同样是10MHz带宽、10ms一个无线帧，如果当前NR用户正好有大数据包要下发，调度器可以连续把大部分子帧分给NR；如果NR侧空闲而LTE用户挤成一片，资源又可以全部还给LTE。这个灵活的逐帧切换能力，才是DSS和普通频谱共享的本质区别。

1.3 DSS不是万能药：适用地图

在我接触过的项目里，DSS真正适合的是下面这几类场景。

第一类是5G终端渗透率还不高的区域。低频载波上LTE用户仍然占大头，通过DSS把一小部分资源分给NR用户，既给新终端提供5G覆盖标识，又不牺牲存量4G体验。第二类是乡村、国道、海域这类连续覆盖场景，专门建中频5G基站投入产出比太低，用DSS把低频载波“一鱼两吃”最为划算。第三类是车联网和工业园区等广域物联场景，车跑在路上的时候不可能只依赖密集城区的中频覆盖，低频DSS能保证跨区域的连续性，这点在港口、物流园区也适用。

但DSS不是万能药。它的短板同样明显：LTE和NR在同一个载波上并存，两者都需要发送各自的同步信号和公共控制信息，频谱开销和功率开销是叠加的。同一段频谱里双制式同时活跃的时候，单用户峰值速率比独立载波要低，绝对容量也有限。指望靠DSS撑起大带宽、大容量的高端用户场景，至少在现阶段不太现实。

2. 把LTE和NR塞进同一段频段：资源避让与信号共存原理

2.1 LTE CRS与PDCCH：绕不开的“钉子户”

DSS在物理层面临的最大挑战，是LTE的参考信号CRS像钉子户一样扎在每个下行子帧里。普通LTE子帧中，CRS几乎每个时隙都存在，终端靠它做测量、解调和信道估计。如果NR的PDSCH在传输时没有避开CRS所在的RE，LTE终端收到的CRS会被NR数据干扰，RSRP测量值、信道估计结果全会乱掉，整个LTE链路就直接劣化。

PDCCH的情况类似。LTE的PDCCH占用每个下行子帧最前面的1到3个OFDM符号，后面还跟着PCFICH和PHICH，这些控制区域是LTE终端盲检调度信息的必经之路，同样不能随意占用。可以这么理解：LTE在这个载波上有一堆固定的“生活习惯”，DSS必须先把这些习惯摸清楚，再在剩下的时间缝隙里把NR信号塞进去。

2.2 NR SSB和CORESET #0如何与LTE错开

NR侧要在共享载波上让终端完成小区搜索，必须周期发送SSB（同步信号块）。SSB占4个OFDM符号，这在纯NR载波上没什么问题，但在共享载波上就麻烦了：如果SSB的时频位置刚好和LTE CRS重合，会导致两类信号互相污染。实际工程中通常会对SSB做RE级的打孔避让，并且把SSB的RB起始位置做偏置，让它的资源网格和LTE CRS不重叠。这个配置一旦出错，终端搜索小区就极其困难，表现出来的症状就是手机能看到5G信号但迟迟注册不上。

更麻烦的是CORESET #0。NR的PDCCH配置和SSB是关联的，终端在读取SSB之后会去监听CORESET #0里的PDCCH，获取系统信息和后续控制信道配置。在DSS载波上，CORESET #0的搜索空间同样要避开LTE的控制区域和CRS。厂家网管里通常有一整套“DSS资源模板”，模板内的时频结构经过芯片级验证，普通优化人员不建议手动改动里面的RE偏移参数，除非你对LTE和NR的RE级映射做过完整推演。

2.3 15kHz子载波间隔为何成为DSS的事实标准

NR支持多种子载波间隔，15kHz、30kHz、60kHz都能用，但在DSS载波上我几乎没见过不用15kHz的。原因不复杂：LTE本身固定15kHz子载波间隔，NR也用15kHz时，两者的OFDM符号长度、时隙边界、RE栅格能完全对齐，资源避让的计算量会降到最低。换到30kHz后，NR的符号长度只有LTE的一半，时隙边界和LTE帧结构错位，虽然也能通过复杂的偏置实现共存，但把BBU的实时调度计算复杂度拉高了不止一个量级，出问题的概率也更高。

所以在实际配置时，DSS载波的NR部分一般固定为15kHz子载波间隔、Normal CP，时隙结构按LTE帧结构对齐来配。这也是为什么很多厂家的DSS特性只支持低频FDD频段的原因，因为NR侧要配合LTE的帧结构限制，灵活性大打折扣。

3. 子帧级资源博弈：DSS调度器的判决逻辑与关键参数

3.1 调度器到底在争夺什么

DSS的核心决策发生在调度器内部。每个10ms无线帧有10个子帧，调度器要决定每个下行子帧是发给LTE终端还是发给NR终端，同时还要决定每个子帧里的PDCCH/PDSCH资源怎么划分。

我拆解过某个厂家的调度策略，大致遵循几个原则。第一是保护LTE控制信息，PDCCH、PCFICH这些信道优先级最高，CRS的避让规则在任何子帧都不能破坏。第二是优先保障实时性业务，VoLTE的语音包如果碰到资源紧张，调度器会强制把对应子帧判给LTE，哪怕NR侧有大量数据排队。第三才是公平竞争，在保障控制信道和实时业务的前提下，按照LTE和NR各自待调度的数据量、信道质量、用户公平性来做子帧分配。

这里容易被忽略的是反馈信道。NR终端在下行子帧收到数据后，需要在特定上行时频位置反馈HARQ ACK/NACK，如果DSS调度器把下行资源分配出去但没有为上行ACK/NACK预留足够的PUCCH资源，就会导致重传率飙升。很多DSS初期站点RLC层重传率异常，排查了半天，最后发现是调度器在低负荷模式下没有为NR侧调度预留上行PUCCH资源。

3.2 MBSFN子帧模板的配置与容量代价

MBSFN机制原本用于LTE多媒体广播，但在DSS里它是一个重要的资源工具。LTE在MBSFN子帧里不发送CRS（某些端口只在起始符号发送），对NR来说相当于多出一块相对“干净”的下行区域。实际配置中，FDD制式常用3ms、6ms、8ms这几组MBSFN模板，对应不同的子帧索引集合。

我以一个10MHz、1800MHz频段、15kHz子载波间隔的实测项目为例。初期配置3ms模板（子帧1、2、3），NR侧可用子帧比例约为30%，LTE几乎无感知。扩大到6ms模板（子帧1、2、3、6、7、8）后，NR可用子帧比例提升至约60%，但LTE峰值吞吐量下降了约20%到30%。如果8ms模板全开，LTE的速率劣化就会比较明显，尤其是对PDCCH容量和HARQ重传的反馈通道影响很大。

实际操作时我不建议一上来就切大模板。稳妥的做法是先切3ms，配合NR终端的现网拉测确认SSB解调和接入正常，再逐步扩展到6ms。每次改动后至少观察24小时的LTE和NR双端KPI，重点看LTE的CQI平均值、下行MCS平均值和VoLTE丢包率有没有恶化。

3.3 功率共享：看起来是频谱问题，其实是功率问题

DSS载波的总发射功率是恒定的，LTE和NR需要共享这台“功率池”。如果LTE侧有10个用户的PDSCH在调度，NR又想在同一个子帧占用另一部分RB，那么两个系统的功率不可避免会互相挤压。为了保证LTE的CRS和NR的SSB始终被终端稳定检测到，网络侧必须为这两类固定信号预留功率，可变调度的PDSCH只能“吃剩下的”。

这个约束在实际中经常被低估。我见过一个站点，NR侧SSB做了3dB功率提升，结果LTE下行MCS均值掉了5个等级，VoLTE上行丢包率上升。原因就是NR SSB功率提升后，在功率池里挤占了LTE PDSCH的功率余量，LTE链路自适应被迫降低了编码效率。后来把SSB功率提升从3dB降到1.5dB，让出一部分功率给PDSCH，LTE侧指标就恢复正常了。

DSS网络的功率规划原则，我总结一句话：优先保LTE的CRS和VoLTE，其次保NR的SSB，最后才轮到两种制式的共享PDSCH去争抢剩余功率。只要这个优先级不乱，排障就能省很多事。

4. 接入、随机接入与移动性：DSS网络里的连接建立和切换

4.1 从LTE迁移到NR的两种常见路径：重定向与切换

DSS网络里，终端从一个制式迁到另一个制式最常见的有两条路。一条是空闲态重选加重定向：终端驻留在LTE小区，根据频率优先级和重选门限判定5G信号足够好，读取系统消息里配置的NR频点后直接发起RRC连接，这个过程信令简单，依赖RRC Connection Release消息里带的redirection信息。另一条是连接态切换：终端先和LTE建立RRC连接，网络下发异系统测量配置，终端上报测量报告后，网络发切换命令把终端切到NR小区。

我一般会把初始接入的负荷放到重选和重定向上，因为DSS共享载波上的NR覆盖和LTE覆盖高度重合，没必要让每个用户都先建立连接再做测量切换，太浪费信令资源。到了连接态，如果用户有持续的大流量业务，再通过测量事件把它们迁到NR或者合适的载波上去。

4.2 邻区关系配置里容易翻车的地方

DSS场景下，LTE小区和NR小区往往是同一个物理站点，甚至共用RRU和天线，很多人觉得邻区配置就简单了。恰恰是这个“觉得简单”最容易翻车。

我遇到过一个典型的5G邻区添加案例。某站点LTE和NR共用1800MHz天线，但从后台看LTE到NR的切换尝试次数几乎是零。最后抓信令发现，后台在添加NR邻区时，把NR的ARFCN配成了中频段3.5GHz的频点，和实际射频上的1800MHz完全对不上。终端侧收到的异系统测量配置要求去测3.5GHz，实际信号根本没从那根天线发出来，测量永远不触发。这类低级错误在DSS站点里非常普遍，因为一个物理站上同时配了多个频段，人很容易选错。

另一个翻车点是GAP（测量间隔）没有打开。NSA/SA共存的网络里，终端要测量异系统频点就得在连接态配置测量GAP，GAP不配或者配得太短，终端根本没有时间去测量DSS载波上的SSB，切换当然也触发不了。建议在开通DSS站点后，先做一次LTE到NR的空闲态重选测试，确认终端能在空闲态找到NR小区，再验证连接态切换，这样能快速把“无线环境问题”和“参数配置问题”剥离开。

4.3 T304定时器与切换失败案例

切换过程中有一个定时器非常关键：T304。终端收到RRC Connection Reconfiguration切换命令后开始计时，在目标小区完成随机接入并收到RRC重配置完成，定时器才会停止。如果超时，终端就判定切换失败，回源小区发起重建。

DSS载波上的T304超时率普遍要比纯NR载波高，原因就是随机接入时机受到LTE资源避让的限制。如果PRACH时机配置得比较稀疏，终端要等到下一个可用的上行子帧才能发preamble，切换完成时间自然被拉长。我在某个DSS站点做过对比测试，把T304从默认的512ms调整到1024ms，切换失败率从0.8%下降到0.2%以内。

4.4 随机接入preamble格式选择

随机接入这块，很多新手会纠结preamble格式怎么选。先说一个热门的细节：38.211里长序列preamble的格式有Format 0、1、2、3共4种，长度都是839位；短序列Format更多，A系列、B系列、C系列组合下来有近20种，长度是139位。DSS低频15kHz场景下，我推荐用短序列，比如Format A1、A2或者B4，因为短序列占用的时域资源更少，更容易塞进LTE留出来的上行空隙，而且对频偏和覆盖的适应范围也能满足大多数低频站点的需求。

选格式不是拍脑袋。Format A2相比之下覆盖半径较大，抗时延扩展能力强，适合郊区广覆盖；但如果站间距很小或者小区半径不大，选A1就够了，占用更少的上行时频资源，给PUSCH省资源。一个DSS站点的PRACH配置要结合LTE侧PUCCH的时频位置一起看，如果NR的PRACH和LTE的PUCCH打架，上行误码率就会异常，RRC建立成功率也会被拖垮。

5. 终端侧行为与兼容性：DSS只有网络侧根本跑不通

5.1 UE能力上报：终端如何告诉网络我支持DSS

DSS从网络侧实现，但终端必须配合。终端在RRC连接建立流程中会上报自己的无线能力，包括支持哪些频段、哪些子载波间隔、是否支持DSS相关的测量特性。如果终端上报的band信息不包含DSS载波对应的频段，网络侧就不会给它配置异系统测量或者把DSS小区作为目标小区。

这个问题的典型症状是手机在LTE上信号满格，也显示“5G”图标，但始终无法建立5N信号。原因很可能是终端上报的频段列表不完整，或者网络侧没有根据UE能力打开对应的DSS频段开关。处理办法是抓RRCConnectionSetupComplete消息，看UE Capability Information里上报的band组合是否覆盖DSS频段。

5.2 DSS载波上的CA和SCG添加流程

在NSA组网里，DSS载波经常作为SCG辅小区角色存在，主小区还是中频段或者宏站LTE。SCG添加流程大概是这样：网络给终端下发测量控制；终端上报包含DSS频点SSB测量结果的测量报告；网络决策后发起SN Addition流程，下发RRCConnectionReconfiguration，里面携带NR SCG配置；终端在DSS载波上发起随机接入，完成SCG添加。

这里容易出问题的是SCG的“添加成功率”。很多DSS站点调测时，主小区上的数据业务正常，但只要一触发NR SCG添加，终端就开始上报SCG Failure。我在现场抓信令分析过，几类原因最常见：一是NR小区PCI配置和邻区表不一致；二是PRACH配置时机太少，导致随机接入受限；三是DSS载波的上行PUCCH资源和LTE上行产生交叉干扰，终端在SCG上发送的测量报告根本传不上去。

5.3 老式LTE终端在DSS载波上会怎样

DSS系统对老式LTE终端是透明的——它在LTE调度器里正常排队、正常调度，并不知道自己所在的载波还跑着NR信号。这个特性保证了存量终端的体验，但也带来一个让运营商头疼的问题：老终端占用共享频谱后，NR分到的资源就变少。

如果某个DSS站点覆盖区域里有大量老旧LTE终端活跃，NR用户的感知速率会明显下降。解决思路不是限制老终端接入，而是通过业务调度策略做资源倾斜。比如把VoLTE语音、公网对讲这类确定性业务优先放在LTE，把视频下载、文件传输这类弹性业务尽可能迁移到NR侧，避免老终端长时间霸占PDSCH资源导致新终端迁不进来。

6. 实测复盘与决策建议：速率上不去、切换失败这类坑怎么处理

6.1 一个典型的“速率上不去”排查链路

有一次现场反馈，DSS载波上的NR终端显示5G网络，但测速只有10Mbps左右。从路测软件的RSRP和SINR看，信号质量很好，不太像覆盖问题。我用Ping包测时延，发现往返时延波动很大，明显反映出调度周期不稳定，而不是链路质量问题。

随后看后台统计，NR的可用子帧比例一直在50%以下，而且大部分下行子帧里NR只分到了很少的RB。最终定位到原因是PDCCH的搜索空间周期配置得太稀疏，终端虽然能解调到下行数据，但控制信道资源不够，调度器不敢给NR分配更多资源。调整之后，把NR侧PDCCH的搜索空间密度提上去，MBSFN模板从3ms扩展到6ms，该站点NR吞吐量直接翻了近三倍。

这个例子说明，DSS站点速率上不去很多时候不是硬件故障，而是“DSS给了资源，但终端控制信道没跟上”这种系统性不匹配。排查时不要一上来就怀疑设备，先把调度器的分配统计和终端侧物理层调度情况对应起来看。

6.2 SSB功率提升与CRS干扰的平衡

DSS站点普遍想在低频段提升SSB功率来增强NR覆盖显示，但SSB功率提升是一把双刃剑。我在不同站点反复做过测试，结论是：提升3dB以上时，LTE侧CRS受到的干扰会明显增加，表现为LTE终端的RSRQ下降、下行CQI均值走低、TCP吞吐量出现锯齿状波动。

工程上建议分两步操作。第一步先把SSB功率提升到1.5dB，观察LTE下行MCS均值和NR接入成功率的变化；第二步确认LTE侧没有明显劣化后，再尝试提升到3dB。如果LTE侧出现劣化，优先回调SSB功率，而不是去优化LTE链路。毕竟DSS的初衷是让两个制式都活得不错，而不是牺牲一个去喂另一个。

6.3 DSS站点的KPI监控指标与阈值建议

DSS站点的监控不能照搬普通5G站点的指标体系，尤其是要增加几个和资源分配、子帧调度强相关的指标。

建议重点关注这几项：

• NR可用子帧比例：这个指标直观反映DSS的资源让渡效果。一般要求至少在50%以上，如果低于这个值，用户感知会明显变差。
• RRC建立成功率：如果低于98%，优先排查NR PRACH和LTE PUCCH的冲突。
• T304超时率：在DSS载波区域超过0.5%就需要关注，先调长T304再排查随机接入资源。
• LTE侧下行MCS均值：和DSS开通前做对比，如果下降超过5个等级，大概率是SSB功率或NR调度挤占了LTE功率资源。
• SCG添加成功率：NSA组网下重点看这个指标，低于95%就要排查邻区参数、PCI混淆和PRACH配置。

6.4 部署决策：DSS不是唯一答案

最后聊几句部署决策层面的个人感受。DSS非常适合作为5G建设早期的低成本打底方案，尤其是低频广覆盖、行业终端还不成规模、LTE存量业务又清不掉的过渡阶段。它让频谱资产不闲置，让5G覆盖指标能提前达标，同时不影响老用户体验。

但如果你面对的场景是高校、商圈、交通枢纽这类高容量热点，或者5G终端渗透率已经很高，就不要硬撑着用DSS了。直接清频重耕，把低频作为5G独立载波，配合中频CA，容量和速率会好很多。我见过一些项目为了“省事”在热点区域也用DSS，结果用户投诉反而上升，最后还得返工重耕，反倒花了两倍时间。至于车联网、港口、驾考等广域行业场景，我的建议是业务本身建议放在独立5G载波上承载，DSS当作覆盖保障层来兜底，别让关键业务去承担共享资源带来的调度不确定性。

在实际操作中我一直留着一个习惯：DSS站点的每一次资源模板调整，都要记录下来调整前后的LTE感知速率、NR感知速率和VoLTE丢包率。几次版本迭代后你会发现，不同频段、不同LTE负载率的最优参数并不相同，没有哪一套配置能通吃所有站点。这个表一旦积累起来，后期扩容和重耕决策都会轻松很多。