5G共建共享网络中的性能劣化告警：基于因果推断的故障定位方案

1次阅读

没有评论

共计 1589 个字符，预计需要花费 4 分钟才能阅读完成。

5G 共建共享网络中，运营商 A 和运营商 B 的设备混合部署已成常态。上周处理的一个案例：某基站突然出现用户面时延从 15ms 飙升至 80ms，但检查设备状态全部显示正常。传统基于固定阈值的告警系统会产生三种误判：

幽灵告警 ：因对端运营商核心网拥塞触发的本端指标劣化
漏告警 ：共享 CU（中央单元）的缓存溢出被 DU（分布单元）的流量波动掩盖
误定位 ：将光纤劣化误判为 AAU（有源天线单元）硬件故障

我们对比过三种主流分析方法：

基于规则 ：if-else 判断指标是否超过阈值
优点：实时性高（<100ms）
缺点：无法处理控制面过载引发的连锁反应
机器学习 ：LSTM 预测指标异常
优点：可发现隐性关联（AUC 0.82）
缺点：需要 6 个月历史数据训练
因果推断 ：Granger 检验 + 贝叶斯网络
优势点：可解释性强（能输出因果强度系数）
实测时延：比规则引擎慢 300ms，但准确率高 40%

用 NetworkX 库建立包含三类节点的有向图：

import networkx as nx
topology = nx.DiGraph()
topology.add_edges_from([('AAU1', 'DU3'),  # 前传链路
    ('DU3', 'CU5'),   # 中传链路  
    ('CU5', '运营商 A_核心网')  # 回传链路
])

采用 5 分钟窗长、1 分钟滑动的分段策略：

from statsmodels.tsa.stattools import grangercausalitytests

def calc_granger(data_series, maxlag=3):
    """data_series 格式: {'AAU1_rxpower': [23,24,...],'DU3_cpu': [58,62,...]}"""
    gc_results = {}
    for src, target in topology.edges():
        test_result = grangercausalitytests(np.column_stack([data_series[target], data_series[src]]),
            maxlag=maxlag,
            verbose=False
        )
        # 取最小 p 值作为因果强度
        gc_results[(src,target)] = min([test_result[i+1][0]['ssr_ftest'][1] for i in range(maxlag)]
        )
    return gc_results

对共享载波场景特别处理：

# 当检测到非对称时延补偿时
if (gc_results[('DU3','CU5')] < 0.01) and \
   (abs(du3_latency - cu5_latency) > 15ms):
    adjust_alarm_threshold(factor=0.7)  # 降低灵敏度

在 30 个共享基站部署后：