19B3.1.2 常见原因
可能是由于 UpPch 所在位置存在干扰,。如果是特定终端出现该现象,而其他终端没有
问题,则
1) 随机接入过程出现问题,可能存在UpPCH的干扰,导致网络侧解错终端上行包,使
得RNC看不到任何消息
(1) 首先检查NODEB的RACH统计有无上行数据包,如果没有,但签名个数与
签名碰撞个数一直在不停地增加,则可能存在上行UpPCH干扰。或者是
统计LMT对UpISCP的测量(其测量与在KPI内统计的POS干扰统计一致,但
精度更高,测量为500ms一次统计,取整个测量时段内的平均值,而KPI
统计的测量为15分钟粒度取平均值)
(2) 通过CT工具检查UPPCH上的干扰
(3) 通过性能统计,查看UPPOS上的UP干扰统计
(4) 可以利用扫频仪在特定终端天线口处检测终端上行信号强度是否正常;
如果是普遍现象,则需要检查UpPch所在位置的干扰,如存在干扰则需
要考虑对UpPch位置进行漂移。
2) 终端问题,重启UE看能否接入
3) NodeB 问题:重启基站
20B3.1.3 解决办法
对各地外场的数据分析后,Up 干扰有两大类型:
1) 出现干扰平台(从当地整个网络来说,出现平台的概率并不高),但除去干扰平台
后的干扰曲线基本正常,对于这类干扰通过基带匹配是能判断出干扰信号源构成的,这
样基带可以:
(1)匹配出干扰源小区,网优调整(方位角、俯仰角或扰码、频点)
(2)基带做干扰消除,以消除干扰。
2) 干扰曲线整体抬高(从当地整个网络来说,出现干扰曲线整体抬高的概率较高)。
对于这种情况可以采集数据看看基带匹配处理后的结果,需要以 Upsfifting 的方式来克
服此问题。
5B3.2RRCConnection Reject (Congestion)
UE 上报 RRC CONNECTION REQ,但很快 RNC 就回了信令 RRE Connection Reject,并且
其所带的 Cause 值为“Congestion”,产生这种原因主要是因为 RRM 算法的进行判决的结果,
呼叫接纳控制(CAC)是无线资源管理(RRM)中的一个重要组成部分。CACM 模块根据小
区当前的无线资源和负荷情况以及呼叫的服务质量(QoS),按照一定的算法,对新的呼叫
请求可能产生的负荷增加量进行预测,然后依据一定的接入准则,决定对新的呼叫是允许接
入还是拒绝接入。CAC 的目的是在防止系统出现负荷过载和保证呼叫的服务质量(QoS)的