2024年1月7日发(作者：褒俊驰)
第五章 切换问题
概述及总结（陈洲）
LTE技术中小区间的切换不再像在GSM和3G时代，切换不是在用户的专用信道中发生，而是使用PRACH过程来切换，这就使得切换问题分成了两大类，一是切换请求没触发，二是触发后切换失败。
5.1总结了切换不触发的原因和案例，5.2提出了切换失败的分析和案例，5.3提供了切换问题的其他案例
5.1 切换不触发（陈洲）
在LTE中，手机不再需要从系统消息中得到邻区的信息，而是完全由手机本身不断检测邻区码。切换请求没触发是指手机在运动过程中检测到新小区的信号，然后向基站发送measurement report要求切换，但由于基站没有相邻基站的IP地址而不知道切换请求应该发往何处，导致手机保持在现服务小区直到干扰太大而掉话。切换不触发原因包括：
1. 在源基站中没有建立邻站的数据。
对每一个邻站要创建一个LNADJ,指明邻站的ENB ID 和IP地址。通常情况下，要登陆基站手工创建每一个LNADJ.在工具的章节中，我们开发了通过OSS一次为多个基站通过脚本的方式批量创建邻站LNADJ,详见工具章节。
2. 在源基站中存在重复的LNADJ
每一个邻站只允许建一个LNADJ,但有时会发现在源基站中建了两个LNADJ,一个是CONNECTED 连接方式是OAMCONTROLLED,一个DISCONNECT,连接方式是ENB
CONTROLLED, 重复的LNADJ导致切换不触发。
3. 邻站的LNADJ数据已经存在，但链路状态是DISCONNECTED.
是由于邻站IP地址定义错误，或者源基站和邻站链路连接方式均为ENB 基站和邻站是通过SCTP协议连接，连接的两端，一端为SERVER端，一端为CLIENT.在创建LNADJ时，定义为OAM CONTROLLED,表明是SCTP协议的CLIENT,可以主动发起到邻站的SCTP连接，在对端基站收到连接请求后为自己建立一个ENB CONTROLLED LNADJ.如果两端均为ENB CONTROLLED,链路就没办法建立起来。
切换不触发案例1：（陈洲）
路测时发现从中航技1基站左转到湖里大道时接收到湖里基站的PCI 18，信号很强但切换一直不发生，通过工具将湖里基站的commission文件下载并导出LNADJ到EXCEL表，可以看到该站建立了以下邻站LNADJ.
源基站名源基站簇号源基站ID邻站名湖里19477百乐园湖里19477顺发工业园监控杆湖里19477凤湖街湖里19477湖里信源湖里19477福隆员工宿舍湖里19477象屿保税市场邻站ID326564邻站现有IP地址100.77.38.69100.77.38.56100.77.38.84100.77.38.72100.77.38.25100.77.39.6邻站控制类型邻站链路状态邻站LNADJ ID邻站工作状态oamControlledavailable0YesoamControlledavailable1YesoamControlledavailable2YesoamControlledavailable3YesoamControlledavailable4YesoamControlledavailable5Yes
表中没有中航技1基站，可见切换所需的LNADJ没有定义，由于以前优化的时候已经建立，不知为何不在了。了解到由于此站在进行双载波测试，基站的邻站信息已被删除并重新创建，部分邻站信息遗漏导致 。
切换不触发案例2：(郑国锋)
问题描述：
驾车在公益路由北向南行驶中，UE占用华鞍花园（老干局）-2小区，当华鞍花园（老干局）-2小区的RSRP衰减到 -96dbm时，邻区列表中最强小区为三山中学-1小区，该小区RSRP为-90dbm，UE上报多次Report，基站侧无响应。
问题分析：
华鞍花园（老干局）-2小区方位角为130度，三山中学-1小区 方位角为30度，在邻小区RSRP（-96dbm）大于服务小区RSRP（-90dbm）3dbm时，满足A3事件的上报条件，UE上报多次但无法切换。首先核查邻区参数，发现该站未添加三山中学站点邻区。
优化建议：
华鞍花园（老干局）与三山中学添加双向邻区。
复测验证：
华鞍花园（老干局）-2小区（PCI=11）向三山中学-1小区（PCI=48）切换成功，不切换问题消失。
切换不触发案例3：（陈洲）
湖里信源到到湖里，华昌路监控杆没有办法触发切换。用SITE MANAGER 登陆到湖里信源发现到湖里的邻区已经有了但不知为何不能触发切换。将commission文件的LNADJ导出到EXCEL 如下表：
源基站名湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源源基站簇号源基站ID37837837018370邻站名邻站ID湖里477百乐园326象屿大厦471湖里商贸217象屿新创码头436百乐园326湖里南山670华昌路监控杆841凤湖街732顺发工业园监控杆560福隆员工宿舍558湖里联检476湖里477象屿新创码头436湖里商贸217湖里联检476象屿大厦471邻站IP地址100.77.38.13100.77.38.69100.77.38.109100.77.38.161100.77.38.83100.77.38.69100.77.38.58100.77.38.100100.77.38.84100.77.38.56100.77.38.25100.77.38.153100.77.38.13100.77.38.83100.77.38.161100.77.38.153100.77.38.109邻站控制类型oamControlledoamControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlled邻站链路状态邻站LNADJ IDavailableavailableavailableavailableavailableunavailableavailableunavailableunavailableunavailableavailableunavailableunavailableunavailableunavailableavailableunavailable5960616263
可以看到湖里信源到湖里有两个LNADJ,一个是oamControlled,available,一个是enbControlled,unavailable.同样的情况发生在其他标黄色的LNADJ。删除多余的enbControlled-unavailable的LNADJ.切换正常
切换不触发案例3：
簇20优化时，从嘉禾工贸往北到实业公司时切换一直不发生。检查邻站LNADJ配置正常，链路状态available.但切换就是不发生。实业公司是RL15基站，检查基站状态良好，无告警。
为了找到原因，到实业公司基站下要切换的区域，发现可以占用基站其他两个小区，但切换目标小区就是占用不上。用CDS锁目标小区PCI码发现RRC建立过程T300超时。说明小区虽然没有告警但不能正常服务了。用SITE MANAGER 重启基站,故障依旧。然后通过IE界面重启基站TRS单元，小区起来后切换正常了。
5.2切换掉话（陈洲）
第二类是切换已经发生但是切换到目标小区的过程中失败。这一类又分为两种情况：
1. 网络配置不合理（PCI 在邻站中重复或PCI复用距离太短），
2. 切换点处手机接收的SINR太差导致不能在目标小区继续切换信令。
5.2.1 网络配置不合理
在基站中每一个邻站由一个LNADJ定义，通过LNADJ源基站知道了邻站的IP地址就可以X2接口和邻站交换基站配置数据，比如无线接口配置，PCI等等，交换信息后由源基站在LNADJ下建立LNADJL.。每一个LNADJL中的PCI必须在一个基站下是唯一的，否则当基站收到手机的measurement report 报告的PCI后，将没有办法映射到正确的邻站已便于往邻站发送切换请求，下图示出了过程：
正常切换
PCI在邻站重复导致掉话
切换掉话案例1：(陈洲)
路测从交通委南向到鹭江BRT监控杆附近掉话。掉话是手机由交通委切换到东方旅社PCI495时T304超时造成的。分析掉话时SINR 5db,不会太坏。检查切换发生时RRC RECO，NFIGURATION.发现要切换到的目标小区PCI=495,Root Sequence=724,而东方旅社虽然PCI=495，但root sequence=0,说明这次切换到的目标小区不是东方山庄。怀疑是由于PCI在邻站中重复导致的。登陆到交通委逐个检查，发现交通委做了到海后二楼2和东方山庄的邻站关系但东方山庄S1和海后二楼2 的PCI均为495, 说明切换的RRC RECONFIGURATION是指示手机切换到海后二楼2,但掉话地点根本收不到海后二楼2的信号导致掉话。更改海后二楼2的PCI为0，重新测试，切换成功。
5.2.2 PCI复用距离短掉话
PCI复用距离短会使基站在某点检测到某PCI但这个PCI是定义给其他邻基站的，这种情况虽然PCI在LNADJL的定义中没有重复但同样会切换失败，因为HANDOVER REQUEST 发给错误的基站了。
切换掉话案例2：（陈洲）
从雪梨星光山脚下往小东山方向往北掉话，由于小东山S1测试时小区故障退出服务，所以切换是从雪梨星光到厦华联想PCI=372掉话的。检查雪梨星光邻站定义实际上并没有厦华联想，这种情况是不应该发起切换的。同时发现在雪梨星光中有一个LNADJL 的PCI=372，它是属于明德花园监控杆的。说明掉话地点手机报告的PCI 372基站以为发现了明德花园监控杆的信号而把HANDOVER REQUEST发往它了，而实际上是厦华联想的信号。基站内PCI在邻站中并没有重复，切换失败是由于PCI复用距离太短（明德花园监控杆和厦华联想仅1.2KM）
，导致手机在中间的某个位置产生误会。修改明德花园监控杆PCI为477，切换成功。
所以建议复用距离不应该小于2KM。
5.3 切换的其它问题
案例1 干道切换序列絮乱 （刘波）
主干道上如果缺少主覆盖，将导致切换絮乱。通过CDS里的Statistic by LTE cell统计表可以找出切换序列絮乱的小区。调整天线，加强主控小区，减少越区覆盖，将使切换序列明晰。
问题描述：
在五一北路-古田路附近，UE由北往南走，在友谊商厦、于山堂两个站反复切换，切换序列比较絮乱。
优化分析：
于山堂覆盖过远，能覆盖到五一北路-古田路北一带；东面楼宇较多，信号透过楼间到路面上的信号波动较大，因此会切换絮乱。
通过CDS上的Statistic by LTE cell统计表，我们可以看到该路段几个小区占用时间只有几秒，持续距离只有几米，RSRP差异不大，都在-100dBm以下。可见这些路段无主控小区，切换絮乱。
PCI Cell Name Start Time
433 友谊商厦_2
477 于山堂_3
16:05:39.8
16:06:05.3
16:06:16.6
16:06:18.9
16:06:23.2
16:06:25.0
16:06:44.0
16:06:45.8
Duration
Mileage(m)
(sec)
25.4
11.3
2.3
4.3
1.9
19.0
1.8
4.6
235.3
56.5
1.1
5.1
2.0
65.2
17.6
36.7
RSRP ave
(dBm)
-90.83
-97.97
-105.36
-105.76
-107.00
-102.84
-101.00
-99.44
SINR ave
(dB)
13.28
10.13
3.13
4.01
-6.23
2.41
-3.10
-0.13
433 友谊商厦_2
477
478
于山堂_3
于山堂_1
433 友谊商厦_2
478 于山堂_1
433 友谊商厦_2
478 于山堂_1 16:06:50.5
16:07:11.5
21.1
27.0
186.9
312.8
-102.26
-84.39
1.34
18.52 164 集邮大厦_2
优化建议：
调整附近的基站，明确主控小区，排除冗余小区信号。
a) 控制于山堂1、2小区覆盖，避免干扰五一北路；
b) 加强帝景豪庭小区覆盖，使其成为主控小区；
具体的调整清单如下：
小区信息 参数类型 调整前 调整后
于山堂-1
于山堂-1
帝景豪庭-1
帝景豪庭-2
帝景豪庭-2
于山堂-2
方位角
下倾角
下倾角
方位角
下倾角
下倾角
50
4
-2
40
10
0
45
10
6
65
8
12
调整原因
避免在五一北路覆盖
避免在五一北路覆盖
加强覆盖，与友谊商厦形成覆盖衔接
加强覆盖，与集邮大厦形成覆盖衔接
加强覆盖，与集邮大厦形成覆盖衔接
避免在五一北路覆盖
时间
2013/4/9
2013/4/9
2013/5/3
2013/5/3
2013/5/3
2013/5/7
复测验证：
从上图看，调整天线后切换序列很明确，在友谊商厦和帝景豪庭之间只有两次切换。
PCI
433
81
83
163
Cell Name
友谊商厦_2
帝景豪庭_1
帝景豪庭_2
集邮大厦_3
Start
Time
10:01:16.5
10:01:31.8
10:02:52.1
10:03:12.1
Duration
(sec)
15.3
80.3
20.0
21.1
Mileage(m)
165.0
266.6
234.2
248.3
RSRP ave
(dBm)
-88.35
-89.18
-89.73
-81.95
SINR ave
(dB)
19.47
15.71
16.50
18.91
Statistic by LTE cell统计表上，可以看到该路段由帝景豪庭覆盖，友谊商厦_2、帝景豪庭_2、帝景豪庭_1、集邮大厦_3覆盖，切换序列比较简洁，每个小区的持续距离有150米以上。
案例2跨厂家邻区优化 (刘波)
福州仓山城区由NSN和大唐两个厂家共同覆盖，需要对边界邻区进行完整性检查，补全邻区
问题描述：
在仓山NSN与大唐的交界区域，由于双方的开站进度不一致，双方的邻区关系欠缺比较多。
在交界区域进行测试，发现李厝山路、鳌头凤岭路一带完全不切换，导致该路段RSRP很差。
优化建议：
与大唐协调，分步骤完善邻区关系：
a) 把双方开通基站清单列出来，通过自动邻区规划工具规划出第一层邻区；
b) 后台把邻区添加完成后，优化组在交接区测试；
c) 根据测试文件中MeasumentReport上报的PCI，补齐疏漏的邻区。
复测验证：
再次在交界区测试，发现这条路上的切换完全正常，覆盖有较大提高。
同频切换尝试总次数
90
141
同频切换成功总次数
83
140
同频切换失败总次数
7
1
同频切换成功率（%）
92.22%
99.29%
同频切换平均时延（ms）
0.050
0.064
LTE测试总里程（km）
28.29
26.27
切换频次（km）
3.2
5.4
从切换统计里也可以看到：在相同的测试路段，切换尝试次数由90次提到到141次，切换频次由3.2次/km提高到5.4次/km。
2024年1月7日发(作者：褒俊驰)
第五章 切换问题
概述及总结（陈洲）
LTE技术中小区间的切换不再像在GSM和3G时代，切换不是在用户的专用信道中发生，而是使用PRACH过程来切换，这就使得切换问题分成了两大类，一是切换请求没触发，二是触发后切换失败。
5.1总结了切换不触发的原因和案例，5.2提出了切换失败的分析和案例，5.3提供了切换问题的其他案例
5.1 切换不触发（陈洲）
在LTE中，手机不再需要从系统消息中得到邻区的信息，而是完全由手机本身不断检测邻区码。切换请求没触发是指手机在运动过程中检测到新小区的信号，然后向基站发送measurement report要求切换，但由于基站没有相邻基站的IP地址而不知道切换请求应该发往何处，导致手机保持在现服务小区直到干扰太大而掉话。切换不触发原因包括：
1. 在源基站中没有建立邻站的数据。
对每一个邻站要创建一个LNADJ,指明邻站的ENB ID 和IP地址。通常情况下，要登陆基站手工创建每一个LNADJ.在工具的章节中，我们开发了通过OSS一次为多个基站通过脚本的方式批量创建邻站LNADJ,详见工具章节。
2. 在源基站中存在重复的LNADJ
每一个邻站只允许建一个LNADJ,但有时会发现在源基站中建了两个LNADJ,一个是CONNECTED 连接方式是OAMCONTROLLED,一个DISCONNECT,连接方式是ENB
CONTROLLED, 重复的LNADJ导致切换不触发。
3. 邻站的LNADJ数据已经存在，但链路状态是DISCONNECTED.
是由于邻站IP地址定义错误，或者源基站和邻站链路连接方式均为ENB 基站和邻站是通过SCTP协议连接，连接的两端，一端为SERVER端，一端为CLIENT.在创建LNADJ时，定义为OAM CONTROLLED,表明是SCTP协议的CLIENT,可以主动发起到邻站的SCTP连接，在对端基站收到连接请求后为自己建立一个ENB CONTROLLED LNADJ.如果两端均为ENB CONTROLLED,链路就没办法建立起来。
切换不触发案例1：（陈洲）
路测时发现从中航技1基站左转到湖里大道时接收到湖里基站的PCI 18，信号很强但切换一直不发生，通过工具将湖里基站的commission文件下载并导出LNADJ到EXCEL表，可以看到该站建立了以下邻站LNADJ.
源基站名源基站簇号源基站ID邻站名湖里19477百乐园湖里19477顺发工业园监控杆湖里19477凤湖街湖里19477湖里信源湖里19477福隆员工宿舍湖里19477象屿保税市场邻站ID326564邻站现有IP地址100.77.38.69100.77.38.56100.77.38.84100.77.38.72100.77.38.25100.77.39.6邻站控制类型邻站链路状态邻站LNADJ ID邻站工作状态oamControlledavailable0YesoamControlledavailable1YesoamControlledavailable2YesoamControlledavailable3YesoamControlledavailable4YesoamControlledavailable5Yes
表中没有中航技1基站，可见切换所需的LNADJ没有定义，由于以前优化的时候已经建立，不知为何不在了。了解到由于此站在进行双载波测试，基站的邻站信息已被删除并重新创建，部分邻站信息遗漏导致 。
切换不触发案例2：(郑国锋)
问题描述：
驾车在公益路由北向南行驶中，UE占用华鞍花园（老干局）-2小区，当华鞍花园（老干局）-2小区的RSRP衰减到 -96dbm时，邻区列表中最强小区为三山中学-1小区，该小区RSRP为-90dbm，UE上报多次Report，基站侧无响应。
问题分析：
华鞍花园（老干局）-2小区方位角为130度，三山中学-1小区 方位角为30度，在邻小区RSRP（-96dbm）大于服务小区RSRP（-90dbm）3dbm时，满足A3事件的上报条件，UE上报多次但无法切换。首先核查邻区参数，发现该站未添加三山中学站点邻区。
优化建议：
华鞍花园（老干局）与三山中学添加双向邻区。
复测验证：
华鞍花园（老干局）-2小区（PCI=11）向三山中学-1小区（PCI=48）切换成功，不切换问题消失。
切换不触发案例3：（陈洲）
湖里信源到到湖里，华昌路监控杆没有办法触发切换。用SITE MANAGER 登陆到湖里信源发现到湖里的邻区已经有了但不知为何不能触发切换。将commission文件的LNADJ导出到EXCEL 如下表：
源基站名湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源湖里信源源基站簇号源基站ID37837837018370邻站名邻站ID湖里477百乐园326象屿大厦471湖里商贸217象屿新创码头436百乐园326湖里南山670华昌路监控杆841凤湖街732顺发工业园监控杆560福隆员工宿舍558湖里联检476湖里477象屿新创码头436湖里商贸217湖里联检476象屿大厦471邻站IP地址100.77.38.13100.77.38.69100.77.38.109100.77.38.161100.77.38.83100.77.38.69100.77.38.58100.77.38.100100.77.38.84100.77.38.56100.77.38.25100.77.38.153100.77.38.13100.77.38.83100.77.38.161100.77.38.153100.77.38.109邻站控制类型oamControlledoamControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlledenbControlled邻站链路状态邻站LNADJ IDavailableavailableavailableavailableavailableunavailableavailableunavailableunavailableunavailableavailableunavailableunavailableunavailableunavailableavailableunavailable5960616263
可以看到湖里信源到湖里有两个LNADJ,一个是oamControlled,available,一个是enbControlled,unavailable.同样的情况发生在其他标黄色的LNADJ。删除多余的enbControlled-unavailable的LNADJ.切换正常
切换不触发案例3：
簇20优化时，从嘉禾工贸往北到实业公司时切换一直不发生。检查邻站LNADJ配置正常，链路状态available.但切换就是不发生。实业公司是RL15基站，检查基站状态良好，无告警。
为了找到原因，到实业公司基站下要切换的区域，发现可以占用基站其他两个小区，但切换目标小区就是占用不上。用CDS锁目标小区PCI码发现RRC建立过程T300超时。说明小区虽然没有告警但不能正常服务了。用SITE MANAGER 重启基站,故障依旧。然后通过IE界面重启基站TRS单元，小区起来后切换正常了。
5.2切换掉话（陈洲）
第二类是切换已经发生但是切换到目标小区的过程中失败。这一类又分为两种情况：
1. 网络配置不合理（PCI 在邻站中重复或PCI复用距离太短），
2. 切换点处手机接收的SINR太差导致不能在目标小区继续切换信令。
5.2.1 网络配置不合理
在基站中每一个邻站由一个LNADJ定义，通过LNADJ源基站知道了邻站的IP地址就可以X2接口和邻站交换基站配置数据，比如无线接口配置，PCI等等，交换信息后由源基站在LNADJ下建立LNADJL.。每一个LNADJL中的PCI必须在一个基站下是唯一的，否则当基站收到手机的measurement report 报告的PCI后，将没有办法映射到正确的邻站已便于往邻站发送切换请求，下图示出了过程：
正常切换
PCI在邻站重复导致掉话
切换掉话案例1：(陈洲)
路测从交通委南向到鹭江BRT监控杆附近掉话。掉话是手机由交通委切换到东方旅社PCI495时T304超时造成的。分析掉话时SINR 5db,不会太坏。检查切换发生时RRC RECO，NFIGURATION.发现要切换到的目标小区PCI=495,Root Sequence=724,而东方旅社虽然PCI=495，但root sequence=0,说明这次切换到的目标小区不是东方山庄。怀疑是由于PCI在邻站中重复导致的。登陆到交通委逐个检查，发现交通委做了到海后二楼2和东方山庄的邻站关系但东方山庄S1和海后二楼2 的PCI均为495, 说明切换的RRC RECONFIGURATION是指示手机切换到海后二楼2,但掉话地点根本收不到海后二楼2的信号导致掉话。更改海后二楼2的PCI为0，重新测试，切换成功。
5.2.2 PCI复用距离短掉话
PCI复用距离短会使基站在某点检测到某PCI但这个PCI是定义给其他邻基站的，这种情况虽然PCI在LNADJL的定义中没有重复但同样会切换失败，因为HANDOVER REQUEST 发给错误的基站了。
切换掉话案例2：（陈洲）
从雪梨星光山脚下往小东山方向往北掉话，由于小东山S1测试时小区故障退出服务，所以切换是从雪梨星光到厦华联想PCI=372掉话的。检查雪梨星光邻站定义实际上并没有厦华联想，这种情况是不应该发起切换的。同时发现在雪梨星光中有一个LNADJL 的PCI=372，它是属于明德花园监控杆的。说明掉话地点手机报告的PCI 372基站以为发现了明德花园监控杆的信号而把HANDOVER REQUEST发往它了，而实际上是厦华联想的信号。基站内PCI在邻站中并没有重复，切换失败是由于PCI复用距离太短（明德花园监控杆和厦华联想仅1.2KM）
，导致手机在中间的某个位置产生误会。修改明德花园监控杆PCI为477，切换成功。
所以建议复用距离不应该小于2KM。
5.3 切换的其它问题
案例1 干道切换序列絮乱 （刘波）
主干道上如果缺少主覆盖，将导致切换絮乱。通过CDS里的Statistic by LTE cell统计表可以找出切换序列絮乱的小区。调整天线，加强主控小区，减少越区覆盖，将使切换序列明晰。
问题描述：
在五一北路-古田路附近，UE由北往南走，在友谊商厦、于山堂两个站反复切换，切换序列比较絮乱。
优化分析：
于山堂覆盖过远，能覆盖到五一北路-古田路北一带；东面楼宇较多，信号透过楼间到路面上的信号波动较大，因此会切换絮乱。
通过CDS上的Statistic by LTE cell统计表，我们可以看到该路段几个小区占用时间只有几秒，持续距离只有几米，RSRP差异不大，都在-100dBm以下。可见这些路段无主控小区，切换絮乱。
PCI Cell Name Start Time
433 友谊商厦_2
477 于山堂_3
16:05:39.8
16:06:05.3
16:06:16.6
16:06:18.9
16:06:23.2
16:06:25.0
16:06:44.0
16:06:45.8
Duration
Mileage(m)
(sec)
25.4
11.3
2.3
4.3
1.9
19.0
1.8
4.6
235.3
56.5
1.1
5.1
2.0
65.2
17.6
36.7
RSRP ave
(dBm)
-90.83
-97.97
-105.36
-105.76
-107.00
-102.84
-101.00
-99.44
SINR ave
(dB)
13.28
10.13
3.13
4.01
-6.23
2.41
-3.10
-0.13
433 友谊商厦_2
477
478
于山堂_3
于山堂_1
433 友谊商厦_2
478 于山堂_1
433 友谊商厦_2
478 于山堂_1 16:06:50.5
16:07:11.5
21.1
27.0
186.9
312.8
-102.26
-84.39
1.34
18.52 164 集邮大厦_2
优化建议：
调整附近的基站，明确主控小区，排除冗余小区信号。
a) 控制于山堂1、2小区覆盖，避免干扰五一北路；
b) 加强帝景豪庭小区覆盖，使其成为主控小区；
具体的调整清单如下：
小区信息 参数类型 调整前 调整后
于山堂-1
于山堂-1
帝景豪庭-1
帝景豪庭-2
帝景豪庭-2
于山堂-2
方位角
下倾角
下倾角
方位角
下倾角
下倾角
50
4
-2
40
10
0
45
10
6
65
8
12
调整原因
避免在五一北路覆盖
避免在五一北路覆盖
加强覆盖，与友谊商厦形成覆盖衔接
加强覆盖，与集邮大厦形成覆盖衔接
加强覆盖，与集邮大厦形成覆盖衔接
避免在五一北路覆盖
时间
2013/4/9
2013/4/9
2013/5/3
2013/5/3
2013/5/3
2013/5/7
复测验证：
从上图看，调整天线后切换序列很明确，在友谊商厦和帝景豪庭之间只有两次切换。
PCI
433
81
83
163
Cell Name
友谊商厦_2
帝景豪庭_1
帝景豪庭_2
集邮大厦_3
Start
Time
10:01:16.5
10:01:31.8
10:02:52.1
10:03:12.1
Duration
(sec)
15.3
80.3
20.0
21.1
Mileage(m)
165.0
266.6
234.2
248.3
RSRP ave
(dBm)
-88.35
-89.18
-89.73
-81.95
SINR ave
(dB)
19.47
15.71
16.50
18.91
Statistic by LTE cell统计表上，可以看到该路段由帝景豪庭覆盖，友谊商厦_2、帝景豪庭_2、帝景豪庭_1、集邮大厦_3覆盖，切换序列比较简洁，每个小区的持续距离有150米以上。
案例2跨厂家邻区优化 (刘波)
福州仓山城区由NSN和大唐两个厂家共同覆盖，需要对边界邻区进行完整性检查，补全邻区
问题描述：
在仓山NSN与大唐的交界区域，由于双方的开站进度不一致，双方的邻区关系欠缺比较多。
在交界区域进行测试，发现李厝山路、鳌头凤岭路一带完全不切换，导致该路段RSRP很差。
优化建议：
与大唐协调，分步骤完善邻区关系：
a) 把双方开通基站清单列出来，通过自动邻区规划工具规划出第一层邻区；
b) 后台把邻区添加完成后，优化组在交接区测试；
c) 根据测试文件中MeasumentReport上报的PCI，补齐疏漏的邻区。
复测验证：
再次在交界区测试，发现这条路上的切换完全正常，覆盖有较大提高。
同频切换尝试总次数
90
141
同频切换成功总次数
83
140
同频切换失败总次数
7
1
同频切换成功率（%）
92.22%
99.29%
同频切换平均时延（ms）
0.050
0.064
LTE测试总里程（km）
28.29
26.27
切换频次（km）
3.2
5.4
从切换统计里也可以看到：在相同的测试路段，切换尝试次数由90次提到到141次，切换频次由3.2次/km提高到5.4次/km。