TDLTE 案例库.docx
- 文档编号:2750629
- 上传时间:2023-05-04
- 格式:DOCX
- 页数:30
- 大小:4.53MB
TDLTE 案例库.docx
《TDLTE 案例库.docx》由会员分享,可在线阅读,更多相关《TDLTE 案例库.docx(30页珍藏版)》请在冰点文库上搜索。
TDLTE案例库
TD-LTE案例库
(贝尔分册)
目录
1未接通1
1.1UE跨MSCPool回落,导致被叫失败1
1.2新天水ERAB建立成功率低问题分析2
1.3多CPE上网接入掉线问题4
2掉话7
2.1边界优化案例7
2.2关于铁道医学院等LTE站出现频繁掉站故障分析报告10
2.3青纺机械厂办公楼3扇区掉线问题13
2.4海生医院1扇区邻区漏配导致掉线14
3切换异常16
3.1青山路切换带偏移16
3.2王明殿帮教基地站下海尔路上频繁切换17
3.3台东一路切换关系调整19
4干扰21
4.1萍乡路12号1扇区质差21
4.2型材市场1扇区质差22
4.3金水路干扰质差23
5速率异常25
5.1海生医院1扇区速率差25
5.2鲁阪公司2扇区速率差26
5.3郑州路32号甲站点西侧速率差27
1未接通
1.1UE跨MSCPool回落,导致被叫失败
1.现象描述
外场测试某区域,使用两部三星CSFB终端互拨,主叫端发起呼叫后正常回落,被叫端也正常回落至2G,但一直没有来电显示,也未振铃;主叫端等待一段时间无回铃音,之后收到被叫用户无法接通的提示音。
2.问题分析
主被叫两部终端均可正确回落,说明终端在LTE网络侧的CSFB相关流程执行正常,被叫失败是在终端接入GSM网络后因某环节出现异常导致的。
通过跟踪两部终端回落后的各项操作,以及与GSM网络的信令交互过程,发现出现该问题的测试区域恰好位于MSCPooL边界。
其中终端开机初始执行LTE联合附着/位置更新时,根据MME配置的TA-LA映射表,注册在LA1对应的MSC1上,MSC1在MSCPooL1内。
而因终端拨打时位置在MSCPOOL边界,终端实际回落时选择接入的GSM小区为LA2,对应的MSC为MSC2,MSC2在MSCPooL2内。
如下图所示:
图4-7UE回落跨MSCPool示意图
由于联合注册在MSCPooL1的MSC1,被叫呼叫一定接续到PooL1的MSC1,之后用户回落到MSCPooL2的MSC2,导致被叫失败。
跨Pool失败原因:
由于用户在POOL1下oldMSC联合登记,这样做被叫时,oldMSC会发送PAGING消息到MME,激活CSFB,但用户回落到POOL2下的newMSC,由于LAC发生变化,MS首先会发送LocationUpdate流程到newMSC,如果没有激活MTRF(Mobile Terminating Roaming Retryand Forwarding)功能,oldMSC在等待pagingresponse过程中收到HLR发来的CancelLocation而终止呼叫。
而当激活MTRF后,当UE选择了新的MSC并发送LAU请求后,原先的服务MSC(发送Paging消息的MSC)会收到HSS发送的CancelLocation消息,此时该原先的服务MSC要求G-MSC为该UE重新选择新的服务MSC,并将IAM消息发送给新的MSC,从而完成后续的CS业务。
3.问题分类:
网络覆盖条件
4.解决方案
尽可能完善网络规划,合理配置GSM小区归属MSCPooL,将终端回落接入的GSM小区尽量规划在终端联合注册的MSCPooL内,避免发生回落跨PooL场景,降低被叫失败发生的概率,但这种方法无法彻底解决该问题,需通过部署MSC的MTRF功能才可真正避免回落后跨PooL的被叫失败问题。
3GPP定义的MTRF(MobileTerminatingRoamingForwarding),即可解决这种特殊场景下的异常问题。
通过引入该功能,可实现oldMSC(联合位置更新附着的MSC)和newMSC(回落的MSC)之间的呼叫前转,让被叫成功接续。
该方案实施需LTE覆盖范围内全部MSC软件升级支持,影响范围广,改造量大,实施代价高,因此目前尚未部署,只能通过无线规划的方式规避。
5.效果评估
通过优化无线规划,合理设置GSM小区归属MSCPooL,尽量保证终端回落接入的GSM小区归属于终端注册的MSCPooL,可解决多数场景下回落跨PooL的被叫失败问题。
但在边界区域由于无线信号漂移,无法保证用户在同一区域每次都选择相同小区接入;也不可能同时照顾到PooL边界范围内所有用户,因此无法彻底解决用户被叫失败的问题。
1.2
新天水ERAB建立成功率低问题分析
1.问题描述
新天水ERAB建立成功率低,RRC连接建立成功率为100%,但是ERAB的连接建立成功率为0:
2.问题分析
ERAB的建立过程包含了defaultERAB和dedicatedERAB的建立,从统计指标来看,都是
初始ERAB建立失败,且都是internalfail的counter计数:
建立失败的流程如下:
在MME发送了InitialContextSetupRequest消息后,ENB侧3秒后回送InitialContextSetupFailure消息,cause是failureinradiointerfaceprocedure。
一般情况下,是在无线侧发送了重配消息后,timer超时会发送该cause的建立失败。
从eNB内部的TRACE数据看,则是在收到建立请求消息后,ENB填充RRCConnectionReconfiguration消息时出错:
核查基站的测量配置数据,发现不同的reportConfig,配置了相同的reportConfigID,导致ERAB建立失败:
修改reportConfigID后ERAB连接建立成功率恢复到100%。
1.3
多CPE上网接入掉线问题
现象描述:
最早出现该问题是在未来城移动营业厅保障测试中发现当有两台CPE上网后,第三台上网卡接入会导致其中一台CPE掉线情况;在元月份出现过2次,但复测均正常,在其他基站下测试也正常,怀疑为单点问题已解决。
2月26日,未来城移动营业厅面向媒体演示,出现3UE问题,引起用户强烈不满。
但现场复测发现5-6台UE均可以接入。
2月27日现场在虎踞路51号站使用2台CPE上网后,一旦有UE接入,会导致CPEdrop。
3月1日测试情况:
测试设备:
CPE2套:
分别命名为CPE1(SIM卡号:
460088021100022),CPE2(SIM卡号:
460088021100021)
UE2套:
分别命名为UE1(SIM卡号:
460088021100001),UE2(SIM卡号:
460008021100009)
测试情况如下:
1,11:
45 CPE1下1个用户上网,业务正常。
2,11:
47 CPE2下3个用户上网,业务正常。
3,11:
50 CPE1下增加一个用户上网,业务正常。
4,11:
52 UE1接入,业务正常
5,12:
06 UE2接入,业务正常
6,12:
07 UE1人为中断/恢复连接,业务正常
7,12:
08 UE2人为中断/恢复连接,业务正常
8,12:
09 CPE1下的业务出现异常,UE及CPE2下业务正常
9,12:
12 UE1人为中断/恢复连接,业务正常,但是CPE1下业务还是无法无法恢复。
10:
12:
16 CPE1关开电
11,12:
18 CPE1下业务恢复正常,CPE2及2台UE还是保持正常业务。
问题分析:
鉴于在相同客观环境下测试情况的多变性,怀疑为设备性能导致。
3月3日测试情况:
场景1:
友商的站点(中央门立交附近(PCI为123))
第一次:
先接了两台CPE和一台UE,都能同时上网。
在接第二台UE时之前的一台CPE掉线。
第二次:
先接了两台UE,再接入第一台CPE的时候之前的一台UE掉线。
然后重连UE时CPE掉线,之后重复操作CPE和这一台UE不能同时上网。
分析总结:
CPE(4G-LTE)和UE(460008021100009)不能同时上网,一个上线另外一个肯定掉线。
场景2、在虎踞路51号站测试
LOCK掉附近的站点和这个站另外两个CELL。
SAM上也有同步的Trace搜集。
过程如下:
2013-3-314:
23:
01:
CPE1(460008021100022)接入正常上网。
2013-3-314:
39:
26:
CPE2(460008021100007)接入正常上网,然后CPE1掉线。
两台CPE不能同时上网。
2013-3-315:
13 UE1(460008021100009)可以接入,正常上网。
2013-3-315:
20:
07 两台CPE始终不能同时上网。
2013-3-315:
24:
05:
UE2(46008802110000)接入,正常上网。
CPE2正常上网。
CPE1掉线。
2013-3-315:
27:
42:
重启CPE1后CPE1可以正常上网,CPE2不能上网。
发现,两台CPE之间不能同时接入。
分析总结:
两台CPE之前不能同时上网,
场景3:
未来城移动营业厅
同时有核心网侧余明同事配合抓包。
过程如下:
先接入两台CPE,都能正常上网,然后再接入第三台CPE时之前的一台CPE掉线,再接入两台UE后,共有两台CPE和两台UE能同时上网。
之后将掉线CPE重启总会把另外一台CPE顶掉,其中未来城的CPE一直很稳定,只有咱们带过去的两台CPE不能同时上网。
分析总结:
两台CPE(我们带去的两台CPE)不能同时上网,一台上网另外一台肯定掉线。
场景4:
晚上回到中央门立交友商的站上复测
先接入一台CPE,在接入另外一台CPE时前面一台肯定掉线,多次将掉线CPE重启发现始终只能有一台CPE能上网
然后再接入一台CPE的情况下接入UE,UE和CPE都能正常上网。
经联合TRACE后初步分析如下:
在和核心网同事沟通后,发现应该是设备(UE或CPE)在上网时分配的资源ID重复导致两台设备不能同时上网做业务。
在UE和CPE之间、CPE和CPE之间都出现过这种问题,未发现两台UE之间不能同时上网的情况。
核心网侧回复:
发现SAE_GW当第二个CPE上线后删除了第一个CPE的session
S1/S11信令分析两台CPE具有相同的IMEI,而SAE_GW会认为其中一台非法,因此删除了第一台CPE
临时解决方案:
关闭UE->MME->SAE_GW之间的IMEI信息交互
彻底解决方案:
建议CPE改变不同终端的IMEI,避免ePC侧的混淆
考虑到现网有此类情况存在,SAE_GW侧也会提供一个补丁,以接受多个UE具有相同IMEI的情况。
2掉话
2.1边界优化案例
概述:
边界优化是全网优化的重要阶段之一,主要有以下几个关键点:
–双方准确的交接处基站信息,频点,扰码信息共享;
–边界扰码由一方统一规划,另外一方执行;
–边界区域的频点,扰码调整要事先和对方沟通;
–双方组成一个工作团队对边界进行覆盖和业务优化调整;
其中要重点关注跨不同厂家交界区域的切换问题。
以下提供几个边界优化的案例:
PCI规划不合理导致切换掉线:
问题描述:
在唐山路和中山北路的交汇处南侧,UE占用唐山路二试扩L_1小区信号,RSRP为-90dBm,此时邻区中中山码头试扩L_3为-84dBm,UE无法正常完成切换,最终掉线,导致速率为0;
告警信息:
无告警信息。
分析处理:
(1)查询唐山路二、中山码头的状态和告警,排除基站故障问题;
(2)查询唐山路二1小区和中山码头3小区存在邻区关系,排除邻区漏配;
(3)查询中山码头3小区外部邻区配置情况,经查询,中山码头邻区中存在相同PCI的不同小区如下表所示:
序号
本地小区名称
邻区小区名称
邻小区PCI
1
中山码头试扩L_3
唐山路二试扩L_1
372
2
中山码头试扩L_3
江边路二试扩L-1(友商)
372
3
中山码头试扩L_3
唐山路二试扩L_3
374
4
中山码头试扩L_3
静海寺试扩L-2(友商)
374
(4)将唐山路二的PCI做如下修改,如下所示:
参数名称
小区名
参数原值
修改值
PCI
唐山路二试扩L_1
372
0
PCI
唐山路二试扩L_2
373
1
PCI
唐山路二试扩L_3
374
2
优化效果:
优化后唐山路附近切换正常,速率30Mbps左右,无掉线现象。
邻区漏配导致切换掉线:
问题描述:
在中央路和龙蟠路交汇处附近,UE占用中央门立交2小区信号,RSRP为-90dBm,此时邻区中喜庆广场搬迁3小区RSRP为-73dBm,UE持续上发测量报告,但是一直未收到切换执行命令,无法正常完成切换,最终掉线,导致速率为0;
告警信息:
无告警信息。
分析处理:
(1)查询中央门立交、喜庆广场搬迁的状态和告警,排除基站故障问题;
(2)查询中央门立交2小区和喜庆门广场2小区没有邻区关系,确定邻区漏配导致切换失败;
(3)添加中央门立交2小区和喜庆门广场2小区的邻区关系,如下所示:
优化效果:
优化后无掉线现象。
优化总结:
对于MR不处理问题,建议按照以下步骤进行排查处理:
1、查看服务小区与邻小区有无异常告警存在;
2、查询MR上报的邻区是否存在;
3、核查服务小区间及外部邻区数据是否存在异常,主要可能存在相同PCI、PCI配置错误、TACID配置错误、小区标识配置错误等;
4、遇到邻区中存在相同PCI的问题,首先需要检查PCI规划是否合理,同时需要进行详细的路测找到不同小区间的切换带,才能更多的检查出网络的切换问题,并跟踪后台信令详细分析。
2.2
关于铁道医学院等LTE站出现频繁掉站故障分析报告
故障现象
5月18日接到无线报障,描述有一批LTE站点有严重丢包,频繁掉站,时间是从5月17日中午左右开始的,这批站都在100.68.5.0/26这个子网段。
shifuyouSKL
市妇幼
100.92.5.25
shenjixueyuanSKL
审计学院
100.92.5.14
tengfeichuangxinSKL
腾飞创新
100.92.5.47
taipingxiangSKL
太平巷
100.92.5.41
tongyuanlitangSKL
通院礼堂
100.92.5.54
suijiacangSKL
随家仓
100.92.5.37
shanghailuerSKL
上海路二
100.92.5.12
tangshanluSKL
唐山路
100.92.5.45
shuinishejiyuanSKL
水泥设计院
100.92.5.29
shimenkanSKL
石门坎
100.92.5.20
tianyigeSKL
天一阁
100.92.5.50
shipopoxiangSKL
石婆婆巷
100.92.5.22
suyuanyihexiyuanSKL
苏源颐和西园
100.92.5.36
tongrenjieSKL
同仁街
100.92.5.55
shanxilubanqianSKL
山西路搬迁
100.92.5.8
taipingshangchangTSKL
太平商场T
100.92.5.40
taipingyangdianziTSKL
太平洋电子T
100.92.5.42
shuizuogangSKL
水佐岗
100.92.5.32
taichengdashaSKL
台成大厦
100.92.5.38
tiedaoyixueyuanSKL
铁道医学院
100.92.5.51
故障处理过程
传输初步检查这批站没有明显隧道和伪线告警,且这批站点不在同一个汇聚环上。
将该故障反馈给研发分析,经过研发定位,判断是铁道医学院所在100.68.5.0/26网段有一个异常节点,这个节点PTN侧的UNI端口可能被自环了。
接下来的处理过程是将100.68.5.0/26
子网段的站点一一找出,然后用showmac命令检查UNI口学习到的mac地址正确性,如果学习到是基站MAC地址则是正常的,如果是核心网侧PTN的MAC地址则是端口自环了。
结果发现9033240-友谊河-62-接入环04基站配置了一条四方新村LTE拉远站的业务,其端口(UNI:
4,gei_1/2)学习到的是核心网侧PTN的MAC地址,将该端口闭塞后,基站频繁掉站现象丢失。
图1XX移动PTN网络LTE(100.68.5.0/26)子网段示意图
故障分析
XX移动PTN网络开通的LTE业务二层采用EVPTREE业务模型,50个LTE基站划分在一个子网段,在核心层PTN配置EVPTREE的根节点,然后做L2/L3Uei口的桥接,在基站侧PTN配置叶子节点,当一个叶子节点的UNI口出现自环后,如下图所示:
伪线PW1、PW2的业务正常接基站,伪线PW3的业务做了自环。
图2EVPTREE业务一个叶子节点UNI口环回示意图
故障产生的机理描述如下:
1)当核心层PTN设备的L3Ulei送一个到PW侧的报文,例如发送一个ARP请求报文或其它单播报文,报文源mac为L3Ulei对应的mac(例如是macA)。
2)该报文经过L2Ulei后经Tree业务实例,Tree业务实例中进行mac学习,将macA学习到核心层PTNL2Ulei端口上
3)PW1/PW2发送Tree业务实例的报文,目的mac是macA,经交换后能正常发送到三层接口。
4)如果有报文发送到PW3,因PW3做环回,则PW3接收报文的源mac为macA,Tree业务实例中进行mac学习,将macA学习到核心层PW3对应的虚端口上。
5)此时在二层交换表中,macA的地址发生震荡,PW1的报文可能转发到L2Ulei口,也可能转发到PW3对应的虚接口,造成业务时断时续。
故障规避方案
临时规避方案:
1)工程开通和网络拓扑调整时,应避免在网管不知晓的情况下,将端口用尾纤硬环。
2)可以在网管设置虚端口和基站mac地址静态绑定,这样虽然可以避免动态mac学习可能带来的隐患,但基站更换主控板或网络做调整时,需要人工更新mac地址,不灵活。
最终方案:
PTN6500设备增加虚端口环回告警检测机制,PTN6500发现环回后,主动上报告警并自动关闭环回的虚接口。
该功能在2013年4季度发布的版本中可以实现。
2.3
青纺机械厂办公楼3扇区掉线问题
问题描述:
测试车辆沿金沙路由北向南行驶,信号由大沙路3切换至日报印刷厂1随后切换至青纺机械厂办公楼3扇区,出现掉话。
问题分析:
金沙路两面为居民区,正常情况路面由于两面居民楼阻挡没有青纺机械厂办公楼3扇区信号,此次青纺机械厂办公楼3扇区占用主服小区属于偶然性事件。
但为了避免该类事件的发生需更改切换参数。
解决方案:
日报印刷厂1扇区向青纺机械厂办公楼3扇区CIO由0更改至-6
复测验证:
更改参数后金沙路未出现掉线,效果良好,如图:
2.4
海生医院1扇区邻区漏配导致掉线
问题描述:
测试车辆沿四流南路由南向北行驶,终端占用海生医院1扇区信号未发生切换最终掉线。
问题分析:
由于工程对扇区重新规划,导致之前没有切换关系的小区现在有切换需求,现网需添加邻区关系。
解决方案:
海生医院1扇区与金华路3扇区添加邻区关系
复测验证:
添加切换关系后,该路段测试正常,如图:
3切换异常
3.1青山路切换带偏移
问题描述:
测试车辆占用河南庄东山2扇区,在青山路上由北向南行到在福林万家站下拐弯处由于楼层阻挡严重,存在切换掉话风险,如下图所示.:
解决方案:
LC河南庄东山_2切换LC福林万家_2,CIO由0改为3,A3迟滞由2改为1
优化前
复测验证:
更改参数后异频切换带由西向东偏移了约50m,SINR明显提高,掉话风险有改善,如下图所示:
优化后
3.2
王明殿帮教基地站下海尔路上频繁切换
问题描述:
海尔路上王明殿帮教基地站下王明殿帮教基地3和惠合居酒店1,2切换频繁,存在掉线风险。
问题分析:
在该路段王明殿帮教基地1,惠合居酒店1和惠合居酒店2信号较强,干扰较强,可通过天馈调整结合频点修改及参数修改来解决。
解决方案:
1.惠合居酒店1方位角由30度调整为-30
2.惠合居酒店1,2频点由38100改成37900
3.A2测量门限由-82改成-86
复测验证:
更改参数后切换数量急剧缩减,大大减少了掉线风险,如下图所示:
3.3
台东一路切换关系调整
1、问题描述:
台东一路和丰盛路路口往西弱覆盖150米,速率小区10M的150米。
台东一路速率图
Googleearth截图
问题分析:
,大安电子因为业主纠纷,天线平躺房子房檐上,对该路段的有效覆盖电平比较低,而SE诺玛特_2小区由于天馈位置不合理,没有办法打出了,反而SE诺玛特_1小区信号再该位置要强雨SE诺玛特_2小区。
SE大安电子_2无法切换到SE诺玛特_1,和SE台东大酒店_2导致速率一直很低。
解决措施:
1、添加邻区SE大安电子_2和SE诺玛特_1和、SE大安电子_2和SE台东大酒店_2。
复测验证:
经过上述方案处理,该段道路信号覆盖及SINR均得到较大幅度提升,如下图所示
4干扰
4.1萍乡路12号1扇区质差
问题描述:
测试车辆沿高安路由西向东行驶,在占用萍乡路12号1扇区时出现质差。
问题分析:
在该段道路萍乡路12号1扇区PCI为159、南昌路145号3扇区PCI为39,而且两个扇区频点相同。
该处出现模3干扰,导致质差。
解决方案:
南昌路145号3扇区PCI由39更改至40
复测验证:
参数更改后效果明显,如图:
4.2
型材市场1扇区质差
问题描述:
测试车辆沿万科金色城品正门口道路由北向南行驶,在万科金色城品站点郑东处出现质差。
在该处信号由万科金色城品2扇区切换至型材市场1扇区后又切回至万科金色城品2扇区,两个扇区信号相当频点相同。
问题分析:
在该段道路型材市场1扇区和万科金色城品2扇区同频干扰,而型材市场1扇区是通过居民楼之间的空隙覆盖该处的,作为主服小区信号不够平稳在该处需要减弱该扇区信号。
解决方案:
1、型材市场1扇区频点由38100更改至37900
2、万科金色城品2扇区向型材市场1扇区CIO更改至-8
复测验证:
参数更改后效果明显,如图:
4.3金水路干扰质差
问题描述:
测试车辆沿金水路西向东行驶,过虎山路派出所后出现掉话现象。
问题分析:
该段道路是由LC虎山路派出所2扇区PCI464作为主覆盖小区,向东行驶应切换至LC春和景明二期3扇区PCI44,由于同频,PCI出现模3情况,导致掉话。
解决措施:
1、LC春和景明二期3扇区由37900频点改为38100频点。
复测验证:
经过上述方案处理,该段道路信号覆盖及SINR均得到度提升,如下图所示
5速率异常
5.1海生医院1扇区速率差
问题描述:
测试车辆沿四流南路由南向北行驶,在占用海生医院2扇区出现速率较低的现象。
问题分析:
海生医院1扇区与四流南路10号2扇区信号相当,而且同频。
虽然没出现明显
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- TDLTE 案例库 案例
![提示](https://static.bingdoc.com/images/bang_tan.gif)