企业官网建设流程全解析

简介：这份文档面向电信运营商网络维护人员、无线通信工程师及移动通信科研工作者，聚焦5G网络运维中信道质量指示（CQI）优良率偏低的实际问题。以上饶市篁岭景区两处物理站点为案例，完整呈现从告警核查、MR覆盖与TA距离分析，到辅同步信号RE功率偏移调整的排查与优化思路，最终将CQI优良率提升至98%左右，可作为景区及类似场景5G覆盖优化的实操参考。资源包内含1个docx文档，约193KB，内容涵盖问题描述、分析优化过程与参数配置说明，结构紧凑、便于按步骤对照阅读。目前已有193人学习下载，适合希望掌握信道质量调优技巧、提升弱覆盖与边缘用户感知的从业者借鉴。

1. 景区5G网络优化：CQI指标为什么总在关键时候掉链子

节假日景区里，游客扎堆在观景台、索道口、游客中心，手机信号满格但视频发不出去、扫码要转好几圈。后台一看，基站没挂，功率没降，但CQI均值从平时的12掉到6以下，调度器只能给用户分配低阶调制，速率直接腰斩。CQI（Channel Quality Indicator）是终端上报给gNB的信道质量指示，取值0到15，直接决定MCS阶数和编码效率。景区场景的特殊性在于：用户分布随游览路线潮汐式迁移，下行干扰随人流密度剧烈波动，加上山体、水面、玻璃幕墙的反射折射，CQI波动比城区密集组网大得多。这篇笔记拆的是景区5G网络优化中CQI指标优化的完整落地路径——从数据采集、问题定位到参数调整和效果验证，适合做无线网优、5G基站运维、景区通信保障的一线工程师参考。

2. 景区CQI采集与基线建模：先把黑匣子打开

2.1 CQI上报机制与景区场景的映射关系

CQI不是终端随便报的，它基于下行参考信号（CSI-RS或CRS）的SINR测量，经过终端内部映射表量化成0-15的索引。gNB收到CQI后查表得到MCS，再结合BLER目标做外环调整。景区场景下，这个链路有三个薄弱点：一是参考信号在复杂地形下多径叠加，SINR测量本身就不稳；二是人流密集时上行反馈信道（PUCCH/PUSCH）拥塞，CQI上报周期被拉长或丢失；三是终端类型杂，从旗舰机到千元机，CQI映射表实现差异大，同一位置不同终端报的CQI能差3-4阶。

我一般先在网管侧把CQI相关计数器拉全，包括cqi_report_num、cqi_mean、cqi_stddev、cqi_high_proportion（CQI≥10占比）、cqi_low_proportion（CQI≤6占比），按小区、按小时、按PRB粒度导出。景区场景要额外关注cqi_stddev，这个值超过3就说明信道质量波动剧烈，调度器很难做稳定决策。

2.2 用Python做CQI基线建模与异常检测

拿到数据后别急着调参数，先建基线。景区网络有很强的周期性：工作日、周末、节假日、淡旺季，CQI分布完全不同。我通常用分位数回归做基线，再用残差检测异常。

import pandas as pd import numpy as np from sklearn.linear_model import QuantileRegressor # 读取网管导出的CQI小时级数据 # 字段：cell_id, timestamp, cqi_mean, cqi_stddev, cqi_low_ratio, prb_util, user_num df = pd.read_csv('cqi_scenic_hourly.csv', parse_dates=['timestamp']) # 构造时间特征：小时、是否周末、是否节假日 df['hour'] = df['timestamp'].dt.hour df['is_weekend'] = df['timestamp'].dt.dayofweek.isin([5, 6]).astype(int) df['is_holiday'] = df['timestamp'].dt.date.isin(holiday_list).astype(int) # 对每个小区单独建基线，用0.5分位数回归拟合中位CQI baselines = {} for cell_id, group in df.groupby('cell_id'): X = group[['hour', 'is_weekend', 'is_holiday', 'prb_util', 'user_num']] y = group['cqi_mean'] model = QuantileRegressor(quantile=0.5, alpha=0.01) model.fit(X, y) group['cqi_baseline'] = model.predict(X) group['residual'] = group['cqi_mean'] - group['cqi_baseline'] baselines[cell_id] = model # 残差超过-2.5认为异常恶化，标记出来 df['anomaly'] = df['residual'] < -2.5 print(df[df['anomaly']][['cell_id', 'timestamp', 'cqi_mean', 'cqi_baseline', 'residual']])

这段代码的逻辑是：用分位数回归拟合每个小区在正常状态下的CQI中位数，把小时、周末、节假日、PRB利用率、用户数作为解释变量。残差就是实际CQI偏离基线的程度，低于-2.5说明该时段CQI异常恶化。参数上，quantile=0.5是中位数回归，对异常值鲁棒；alpha=0.01是L2正则强度，防止过拟合。景区场景建议按小区粒度建模，因为不同观景台、不同方向的覆盖环境差异太大，混在一起建基线会掩盖局部问题。

注意：基线建模至少要用30天以上的数据，且要剔除已知的故障时段和割接窗口，否则基线本身就被污染了。

2.3 景区CQI恶化的三类根因定位

基线建好后，异常时段拉出来，按三类根因排查：第一类是覆盖问题，RSRP低于-105dBm的区域CQI必然差，用MR数据做栅格化看弱覆盖占比；第二类是干扰问题，景区里常见的是同频邻区干扰和外部干扰，看上行RSSI和下行SINR的分布，如果SINR均值正常但CQI低，多半是终端测量或上报环节的问题；第三类是容量问题，PRB利用率超过70%后调度延迟增大，CQI上报周期被拉长，外环调整跟不上，CQI会虚低。

我习惯用一张表把三类根因的判据列清楚：

定位到根因后，优化手段完全不同：覆盖问题调天馈和功率，干扰问题调PCI和频点，容量问题做负载均衡和调度策略调整。景区场景往往是多根因叠加，需要按优先级排序。

3. 景区5G CQI参数调优：从天线到调度器的实操路径

3.1 天馈与功率调整对CQI的直接影响

景区基站的天馈调整是最直接的手段，但也是最容易翻车的地方。山体场景下，机械下倾角每增加1度，近端覆盖增强但远端可能直接脱网。我一般先用射线追踪做仿真，确定调整方向，再到现场用扫频仪验证。

具体操作：先导出当前小区的工程参数（方位角、下倾角、天线挂高、发射功率），结合MR数据里的TA分布判断用户主要分布距离。如果TA集中在200-400米，说明用户主要在近端，下倾角可以适当加大；如果TA分布到800米以上，下倾角要收着调。

# 通过网管北向接口批量查询小区工程参数 # 假设使用curl调用网管API，实际接口以设备商文档为准 curl -X GET "https://网管IP:端口/api/v1/cell/engineering_params?cell_id=SCENIC_001" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -o cell_params.json # 解析返回的JSON，提取关键字段 cat cell_params.json | jq '.data | {azimuth, downtilt, height, tx_power, pci, earfcn}'

这段命令的逻辑是通过网管北向接口拉取小区工程参数，用jq提取方位角、下倾角、挂高、发射功率、PCI和频点。参数说明：cell_id是小区标识，景区场景建议按扇区逐个拉取，不要批量操作，因为每个扇区的覆盖环境不同。拿到参数后，结合MR的TA分布和RSRP栅格，确定调整量。一般每次调整下倾角不超过2度，调整后观察至少24小时的CQI变化。

提示：景区基站很多是美化天线或一体化基站，调整空间有限，动手前先确认天馈类型和可调范围，别到了现场发现调不了。

3.2 调度器参数与CQI外环调整策略

CQI外环调整是gNB根据BLER反馈动态修正CQI的过程。景区场景下，外环调整的步长和门限需要特别设置，因为信道波动大，默认参数会导致CQI震荡。

关键参数包括：cqi_adjust_step_up（BLER低于目标时CQI上调步长）、cqi_adjust_step_down（BLER高于目标时CQI下调步长）、bler_target（目标误块率）、cqi_filter_coeff（CQI滤波系数）。景区场景我一般把bler_target从默认的10%降到5%，因为景区用户对速率敏感，宁可保守一点；cqi_filter_coeff从默认的0.5调到0.7，增强滤波平滑波动；cqi_adjust_step_down从1调到2，让CQI在干扰突增时快速回落，避免连续误块。

# 模拟CQI外环调整过程，验证参数设置效果 import numpy as np def cqi_outer_loop(sinr_series, bler_target=0.05, step_up=1, step_down=2, filter_coeff=0.7): cqi_reported = [] cqi_filtered = 10.0 # 初始CQI for sinr in sinr_series: # 根据SINR查表得到原始CQI（简化映射） cqi_raw = max(0, min(15, int(sinr * 0.8 + 4))) # 滤波 cqi_filtered = filter_coeff * cqi_filtered + (1 - filter_coeff) * cqi_raw # 模拟BLER反馈：SINR低于阈值时BLER高 bler = 0.2 if sinr < 5 else 0.02 if bler > bler_target: cqi_filtered = max(0, cqi_filtered - step_down) else: cqi_filtered = min(15, cqi_filtered + step_up) cqi_reported.append(round(cqi_filtered)) return cqi_reported # 模拟景区场景SINR波动序列 np.random.seed(42) sinr_scenic = np.concatenate([ np.random.normal(12, 2, 50), # 平稳段 np.random.normal(4, 3, 30), # 干扰突增段 np.random.normal(10, 2, 50) # 恢复段 ]) cqi_out = cqi_outer_loop(sinr_scenic) print(f"CQI序列前20个: {cqi_out[:20]}") print(f"干扰段CQI均值: {np.mean(cqi_out[50:80]):.1f}")

这段代码模拟了CQI外环调整的全过程：根据SINR查表得到原始CQI，经过滤波后，再根据BLER反馈做上调或下调。参数说明：bler_target=0.05是景区场景的保守设置；step_down=2比默认值大，让CQI在干扰突增时快速回落；filter_coeff=0.7增强平滑。运行后可以看到，干扰段CQI均值被压制在较低水平，避免了调度器分配过高MCS导致连续误块。实际调参时，这些值要通过网管配置下发，然后观察至少一周的BLER和吞吐量变化。

3.3 负载均衡与CQI分层调度

景区容量问题导致的CQI恶化，靠调天馈和功率解决不了，必须做负载均衡。5G的负载均衡可以从两个层面做：一是频段间均衡，把用户从2.6GHz迁到4.9GHz或700MHz；二是小区间均衡，通过切换参数把边缘用户导向邻区。

我一般先用PRB利用率和用户数识别高负载小区，再看这些小区的CQI分布。如果高负载小区里CQI≤6的占比超过30%，说明容量已经影响到信道质量了。这时候优先做频段间均衡，因为景区基站通常有多频段配置。

-- 从网管数据库中查询高负载小区的CQI分布 -- 假设表结构：cell_kpi(cell_id, timestamp, prb_util, user_num, cqi_low_ratio, cqi_mean) SELECT cell_id, AVG(prb_util) AS avg_prb_util, AVG(user_num) AS avg_user_num, AVG(cqi_low_ratio) AS avg_cqi_low, AVG(cqi_mean) AS avg_cqi FROM cell_kpi WHERE timestamp BETWEEN '2025-01-01' AND '2025-01-07' GROUP BY cell_id HAVING AVG(prb_util) > 0.7 AND AVG(cqi_low_ratio) > 0.3 ORDER BY avg_cqi_low DESC;

这条SQL的逻辑是筛选出PRB利用率超过70%且CQI≤6占比超过30%的小区，按CQI恶化程度排序。参数说明：时间范围选一周，覆盖工作日和周末；prb_util > 0.7是容量受限的经验门限；cqi_low_ratio > 0.3说明信道质量已经明显恶化。查出来的小区就是负载均衡的重点对象。调整时，通过修改频段间切换门限（如A2事件门限）和负载均衡偏置，把用户导向低负载频段。调整后观察CQI_low_ratio是否下降，如果没降，说明问题不在容量，要回到覆盖或干扰排查。

4. 景区CQI优化避坑：五条血泪经验

4.1 避坑一：只看CQI均值，忽略分布和波动

现象：CQI均值从12调到13，但用户投诉没减少。原因：均值提升可能来自少数高端用户，大量边缘用户的CQI仍然很低，且波动大。解决：同时看CQI的P5、P50、P95分位数和标准差，P5低于6说明底部用户体验差，标准差大于3说明波动剧烈。优化目标应该是提升P5和降低标准差，而不是单纯拉均值。

4.2 避坑二：天馈调整后不做验证，直接批量推广

现象：一个扇区调整后CQI改善，批量调整其他扇区后部分区域反而恶化。原因：景区不同扇区的覆盖环境差异大，一个扇区的调整方案不能直接复制。解决：每个扇区单独仿真、单独调整、单独验证，至少观察24小时。调整记录要详细，包括调整前后的工程参数、CQI分布、RSRP栅格对比。

4.3 避坑三：外环调整步长设得太大，导致CQI震荡

现象：CQI在6和12之间来回跳，调度器频繁切换MCS，吞吐量不升反降。原因：cqi_adjust_step_up和step_down设得太大，BLER反馈稍有波动就大幅调整CQI。解决：步长从1开始试，观察CQI时间序列的稳定性，如果震荡明显就减小步长或增大滤波系数。景区场景建议step_up=1、step_down=2、filter_coeff=0.7起步。

4.4 避坑四：忽略终端差异，用单一CQI映射表

现象：同一位置，旗舰机CQI报12，千元机报8，调度器按平均值分配MCS，旗舰机浪费、千元机误块。原因：不同终端芯片的CQI映射表实现不同，对SINR的量化精度和滤波策略有差异。解决：按终端类型（TAC前几位）分组统计CQI分布，如果差异超过3阶，考虑在调度器里做终端类型感知的CQI修正，或者对低端终端适当保守调度。

4.5 避坑五：优化后不跟踪长期效果，节假日又翻车

现象：平时优化效果很好，一到节假日CQI又崩。原因：优化方案是按平时负载设计的，节假日用户密度翻倍，PRB利用率飙升，CQI恶化。解决：优化方案要分场景验证，平时、周末、节假日分别看效果。节假日来临前提前做压力测试，必要时启用临时载波或调整调度策略。景区网络优化没有一劳永逸，必须跟着人流节奏走。

5. 用CQI时间序列预测做景区网络预优化

前面讲的都是事后优化，但景区网络最怕的是节假日突发流量。我后来养成了一个习惯：用CQI历史数据做时间序列预测，提前识别可能恶化的小区和时段，在问题发生前就把参数调好。

具体做法是用Prophet或SARIMA对每个小区的CQI均值做预测，输入特征包括历史CQI、用户数、PRB利用率、节假日标记。预测未来24小时的CQI走势，如果预测值低于基线2个点以上，就提前触发优化流程。下面是一个用Prophet做预测的示例：

from prophet import Prophet import pandas as pd # 准备数据：ds是时间戳，y是CQI均值 df = pd.read_csv('cqi_cell_001.csv', parse_dates=['timestamp']) df = df.rename(columns={'timestamp': 'ds', 'cqi_mean': 'y'}) # 添加节假日和周末作为额外回归量 df['is_weekend'] = df['ds'].dt.dayofweek.isin([5, 6]).astype(int) df['is_holiday'] = df['ds'].dt.date.isin(holiday_list).astype(int) # 构建Prophet模型 model = Prophet( changepoint_prior_scale=0.05, # 控制趋势变化灵活度 seasonality_prior_scale=10, # 控制季节性强度 daily_seasonality=True, weekly_seasonality=True ) model.add_regressor('is_weekend') model.add_regressor('is_holiday') model.fit(df) # 预测未来24小时 future = model.make_future_dataframe(periods=24, freq='H') future['is_weekend'] = future['ds'].dt.dayofweek.isin([5, 6]).astype(int) future['is_holiday'] = future['ds'].dt.date.isin(holiday_list).astype(int) forecast = model.predict(future) # 输出预测结果，标记可能恶化时段 result = forecast[['ds', 'yhat', 'yhat_lower', 'yhat_upper']].tail(24) result['risk'] = result['yhat'] < baseline_cqi - 2 print(result[result['risk']])

这段代码的逻辑是用Prophet拟合CQI的时间序列，把周末和节假日作为额外回归量，预测未来24小时的CQI走势。参数说明：changepoint_prior_scale=0.05让趋势变化不过于敏感，避免过拟合；seasonality_prior_scale=10增强日周期和周周期的季节性；daily_seasonality和weekly_seasonality分别捕捉日内和周内规律。预测结果里yhat_lower是下界，如果下界低于基线2个点，就标记为风险时段。实际使用时，我一般提前一天跑预测，把风险时段和对应小区列出来，赶在游客到来前完成参数预调整。

这个方法的边界在于：Prophet对突发事件的预测能力有限，比如临时封路、天气突变导致的人流异常，它捕捉不到。所以预测结果只能作为参考，不能替代实时监控。我一般把预测和实时KPI告警结合使用，预测负责提前布局，告警负责兜底。

做了这么多年景区网优，最大的教训就是：别指望一套参数打天下。景区的人流像潮水，CQI跟着潮水涨落，优化方案也得跟着变。我现在每次节假日保障前都会把预测跑一遍，提前把该调的调了，该备的备了，比事后救火从容得多。希望帮到你。

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