License过期受限导致E-RAB连接成功率低案例
- 格式:docx
- 大小:137.11 KB
- 文档页数:5
IP PTAH配置错误导致E-RAB建立失败/切换失败案例一、【问题描述】深圳LTE网络中突然出现小区的E-RAB建立失败总次数大幅增加,最严重的小区一天的E-RAB建立失败达到28583次,而失败原因值基本都为“传输层问题导致E-RAB建立失败”。
严重影响用户感知和整网E-RAB建立成功率指标,全网E-RAB建立成功率由99.8%跌落到97.14%左右。
切换成功率由98%以上跌到最低的97.12%。
●MME割接后全网KPI指标:●下面是TOPN小区列表:二、【问题分析】经过检查,这部分站点E-RAB建立失败TOPN小区全都是属于华为MME的站点割接到爱立信MME上的。
经过核查数据,发现爱立信SGW配置了两段IP地址,对于现网割接到爱立信EPC的站点,每个站点需要配置14条S1口的IPPATH。
但是从现网站点只检查到了100.65.251.49-55共7条IP地址,从基站上分析SGW侧还有100.65.251.65-71共7个IP地址需要添加。
由于割接站点的IPPATH漏配,导致了UE无法实现E-RAB的建立,邻区之间的切换链路也无法建立,出切换失败的目标小区全部为MME割接中IP PATH配置错误的站点。
例如下面MML检查:横岗变电FE漏配前的IP PATH设置:三、 【处理结果】3月6日完成了全网检查和错误IP PATH 配置站点的纠正,基站IP PATH 从原有的100.65.251.49~55共7个IP 地址,再添加100.65.251.65~71,共14个IP 地址。
3月6日、7日全网的KP 指标恢复正常水平,E-RAB 建立成功率达到99.78%,无线接通率达到99.55%,切换98.26%。
◆ 检查方法:在MML 中使用命令LST IPPATH 查询,如果站点有数据出来的就是LINK 传输方式,如果提示没有找到相应的站点为EP 传输方式。
而LINK 传输方式的站点中只配置了100.65.251.49~55段的确定为IP 地址漏配,全部需要再添加100.65.251.65~71这7个IP 段。
深圳ERAB成功率低问题处理报告-V1.01 问题现象2012年5月初深圳TD-LTE项目日常话统监控显示ERAB建立成功率仅为8%-10%,通过话统分析发现,ERAB建立失败主要为QCI=3的专有承载,如下表所示。
2 问题分析2.1 QCI介绍QCI是QoS Class Identifier的缩写,即服务等级分类标示,用来作为各项业务承载功能(如调度、准入、队列管理等)的指示(定义见23.401 4.7.3)。
从业务类型、优先级、时延需求、误码率需求等几个方面,协议规定了QCI 分9类(23.203 6.1.7.2),见下表。
从承载业务对资源需求的角度,QCI分为两大类,GBR和non-GBR,及需要保证速率和不需要保证速率。
通常对时延要求高(对最低速率有要求)的业务,如VoIP、实时游戏,建议以GBR类型的QCI承载;而对时延不敏感,对最低速率无要求的业务,如Ftp下载、可缓冲的视频浏览等业务,建议以non-GBR承载。
深圳项目导致ERAB建立失败的承载类型为QCI=3,即GBR类业务。
2.2 信令分析通过跟踪S1口的信令可以进一步确认深圳ERAB建立成功率低的直接原因是QCI=3的专用承载反复建立失败,如下图所示。
UE附着过程中已建立了QCI=6的默认承载(蓝色框),随后MME发起建立QCI=3的专有承载,反复建立失败(红色框)。
对应的ERAB建立失败原因为“reduce load in serving cell”,即小区负荷超限,此原因表示该问题为准入算法模块生效导致。
上下行保证速率均为100Mbps。
2.3 原因分析(1)对比杭州的信令发现,杭州并未发现“专有承载”建立的信令,初步确认杭州没有开启“FTP业务触发专有承载”的功能,所以杭州并未出现大量ERAB建立失败的问题;(2)问题与终端无关;从后台信令分析,失败流程仅在S1口出现,没有涉及UU口信令交互,使用了最新版本的E398s和CPE测试,问题现象一致。
5G共建共享小区切换及回落问题案例总结XX目录1概述 (1)2电信小区向联通共享小区切换问题 (1)2.1常见问题 (1)2.2问题案例 (1)2.2.1案例1:电信网元外部小区配置错误 (1)问题描述 (1)问题分析 (3)问题定位 (4)问题处理 (4)2.2.2案例2:联通承建共享站点license 到期 (7)问题描述 (7)问题分析 (8)问题定位 (9)问题处理 (9)2.2.3案例3:联通承建共享站点告警 (10)问题描述 (10)问题分析 (10)问题定位 (11)问题处理 (12)2.3问题总结 (12)3电信小区向联通共享锚点小区切换问题 (15)3.1常见问题 (15)3.2问题案例 (15)3.2.1同时添加联通4G 普通共享小区与4G 共享锚点小区频繁切换问题 (15)问题描述 (15)问题分析 (16)问题定位 (17)问题处理 (19)3.2.2电信小区向联通4G 共享锚点小区切换失败问题 (21)问题描述 (21)问题分析 (21)问题定位 (21)问题处理 (23)3.3经验总结 (23)4电信共享小区回落联通GSM/WCDMA 失败问题 (23)4.1常见问题 (23)4.2问题案例 (24)4.2.1案例1:CSFB 开关设置问题 (24)问题描述 (24)问题分析 (25)优化调整 (26)优化效果 (26)4.2.2案例2:EnodeB 邻接频点问题 (28)问题描述 (28)问题分析 (28)优化调整 (29)优化效果 (29)4.2.3案例3:网元版本问题 (30)问题描述 (30)问题分析 (30)优化调整 (30)4.3CSFB 配置方法 (30)4.3.1公共参数(基于覆盖的重定向算法启动开关) (30)4.3.2CSFB 至WCDMA 网络 (33)全局业务开关 (33)测量参数 (33)EnodeB 邻接频点 (34)CSFB 配置 (35)运营商自定义用户策略配置表 (36)测量参数 (37)4.3.3CSFB 至GSM 网络 (38)全局业务开关 (38)测量参数 (38)EnodeB 邻接频点(站点周边最强GSM 频点) (40)CSFB 配置 (40)运营商自定义用户策略配置表 (41)测量参数 (42)1概述随着电信与联通方共建共享站点的部署及大量开通,出现一系列共享小区与非共享小区间移动性问题,本文针对目前已发现的问题从电信小区向联通 4G 共享小区切换,电信小区向联通共享锚点小区切换,电信共享小区回落联通小区三个方面进行问题总结,梳理问题原因及处理方法,为后期定位问题提供指导性建议及方案,便于快速定位,及时处理。
E-RAB建立失败优化
一、问题描述
在日常指标监控发现,809601_51_HNTDX丽唐小区 E-RAB建立成功率低,情况如下:
二、问题分析
提取小区指标发现该小区(增加ERAB建立失败次数,由于eNodeb 接纳失败导致)次数较多,为造成小区E-RAB建立成功率低的主要原因
“增加ERAB建立失败次数,由于eNodeb接纳失败导致”主要是QCI8增加的建立请求,应该为一个UE并发建立的DRB的失败个数;
查询系统关于此类参数设置erabSwitch为关闭,指示为eNodeB 最多允许一个UE并发建立4个DRB,如果UE需要并发建立的DRB是数量超过4个,则增加的DRB会出现接纳失败;
三、解决措施
将该小区配置erabSwitch参数为打开状态后,eNodeB最多允许一个UE并发建立8个DRB;小区指标“增加ERAB建立失败次数,由于eNodeb接纳失败导致”次数为0,E-RAB建立成功率提升到正常水平。
传输问题导致E-RAB建立失败案例沈星宇中国移动通信集团舟山分公司摘要:舟山从3月底开始出现大量因传输层问题导致E-RAB建立失败的情况。
舟山区域所有基站均下挂在诺西SAE,E-RAB建立失败的信令中诺西MME给基站指配的却是华为SAE的IP地址,舟山基站与华为SAE传输未做通,导致E-RAB建立失败。
而诺西MME给基站指配华为SAE的原因为诺西核心网不支持同时跨MME和SGW的切换,所以从华为MME切到诺西MME时,SGW不会变。
这样后续建立E-RAB时,诺西MME就会下发之前的SGW的地址给eNodeB。
关键字:传输问题 E-RAB建立失败诺西MME一、背景3月29日开始,舟山定海区域部分基站不定时出现传输问题导致ERAB建立失败的情况,次数从几百次到上万次不定。
时间全网完整度ERAB建立成功率(ALL)(%)传输层问题导致E-RAB建立失败次数03/27/2014 全网99% 98.8612 703/28/2014 全网99% 99.3622 803/29/2014 全网98% 99.1294 338203/30/2014 全网99% 98.6764 003/31/2014 全网97% 99.3125 004/01/2014 全网99% 99.3107 89504/02/2014 全网99% 99.3939 44804/03/2014 全网98% 99.7946 101404/04/2014 全网99% 98.848 195004/05/2014 全网99% 98.9919 465604/06/2014 全网98% 98.5184 11716二、问题分析传输问题导致ERAB建立失败占比较高的站点分布全部集中在从宁波到舟山城区的高速沿线。
选取指标差的站点,查询基站是否有告警,发现这些基站均不定时出现用户面承载链路告警:与该站点ERAB建立指标对比,发现告警出现时间和传输问题导致ERAB建立失败的时间点吻合。
地址漏配导致E-RAB建立成功率低优化案例摘要:E-RAB连接陈功率低有很多影响因素,例如基站故障、核心网问题、传输问题等,本案例通过分析找出界首大黄郭店基站E-RAB连接成功率低的原因是地址漏配,为4G异常小区的优化提供了一定参考。
关键字:E-RAB连接成功率、地址漏配【故障现象】:FY-界首-大黄郭店-HFTA-436590-57 ERAB建立成功率低,异常小区告警,需处理。
地理位置:【告警信息】:无区域性批量退服或告警【原因分析】:E-RAB是承载用户业务数据的接入层承载,它在小区内的建立成功率,直接反映了小区为用户提供E-RAB承载建立的能力。
“E-RAB 建立测量(E-RAB.Est.Cell)”统计小区不同QCI(Quality Class Indication)类型的E-RAB建立尝试次数、成功次数。
以E-RAB的个数为单位,一个E-RAB的建立统计为一次。
E-RAB建立流程如下所示:(1)E-RAB建立失败常见原因1)基站故障查看基站是否存在故障,若存在进行排障。
2)UE无响应需排查覆盖,干扰,质差,ENODEB参数设置错误,终端及用户行为异常等原因。
3)核心网问题需上报核心网专业人员进行排查。
4)传输层问题需上报传输专业人员查询是否有故障,高误码,闪断,传输侧参数设置问题。
5)无线侧问题(弱覆盖/SINR过低)网管统计为无线层问题时,主要判断为UE没有驻留在最优小区发起接入,如果信号快速变化导致驻留小区信号快速下降,驻留小区的更新只能等待E-RAB建立完成后进行,导致E-RAB建立过程在弱信号小区进行,容易出现失败。
6)无线资源不足当后台统计指标统计出小区的E-RAB建立失败原因主要为无线资源不足时,处理建议:排查TOP小区资源是否足够,是否故障引起,若存在资源不足问题,可考虑参数调整,流量均衡。
通过现网跟踪S1口信令,发现该小区ERAB建立失败主要是因核心网下发的IP地址基站无法ping通,导致建立失败。
E-RAB连接建立成功率低优化案例摘要:如上图所示,LTE的E-RAB从SGW开始到UE结束,由S1-U承载和DRB(Data Radio Bearer)串联而成,进入LTE系统的业务数据主要通过E-RAB进行传输,因此LTE对于业务的管理主要是在E-RAB层次上进行的。
为了管理E-RAB,在LTE系统内需要相应的信令连接传输网元间的控制信令来完成,LTE的信令主要包括三个部分,就是NAS信令、RRC信令和S1 AP信令以及用来传输信令的各种实际的承载。
另外,ERAB的管理主要体现在S1接口的信令中,包括ERAB的建立、修改和释放。
E-RAB是指用户平面的承载,用于UE和核心网之间传送语音、数据及多媒体业务。
E-RAB的建立由核心网发起,当E-RAB建立成功后,eNB为UE分配了用户面的承载,一个基本业务即建立,UE进入业务使用过程。
E-RAB建立成功率反映了业务建立的成功概率(相对信令),体现了小区或eNB接纳业务的能力。
同时,E-RAB建立成功率也反映了小区内用户发起业务的感受,也可用于考察系统负荷。
关键字:E-RAB建立成功率、承载、拥塞1、问题描述在5月2号进行KPI工单处理的时候,发现崇川-园博园3小区的E-RAB建立成功率指标异常。
通过网优平台发现崇川-园博园3小区在5月1号的18点至21点的E-RAB建立成功率严重恶化,如下图所示:2、问题分析由于问题点呈现为短时间的突发事件,怀疑由于用户激增,拥塞导致指标恶化。
通过对崇川-园博园3小区的用户数指标核查,发现在当时确实出现了拥塞问题(目前,一个小区RRC 最大用户数支持200个)。
如下图所示:E-RAB建立信令流程,如下图所示:我们通过E-RAB连接建立统计点的分类,可以大致确认是何种原因导致的E-RAB连接建立。
E-RAB成功次数对应的counter对应M8006C0,统计点“The number of EPS bearer setup attempts. Each bearer of the "E-RAB to Be Setup List" IE is counted.”。
L网厂家误操作导致小区E-RAB连接失败优化处理1.问题描述12月23日发布“天翼网TOPN问题表”显示,东山网格的L网基站【东山分局-新建小灵通改造-1】E-RAB连接失败519次,引起片区监控指标的波动性预警。
2.问题分析2.1、性能指标分析经性能指标查询,发现L网基站【东山分局-新建小灵通改造-1】在12月18日起,该站的E-RAB建立成功率一直是0,而RRC连接建立成功率都在99%以上,引起网优人员的重点关注:通过U2000网管数据分析发现【东山分局-新建小灵通改造-1】E-RAB建立成功率为0,其中E-RAB建立失败具体原因值为“无线资源不足导致E-RAB建立失败次数 (无)”,初步定为E-RAB连接异常为无线资源不足导致E-RAB建立失败的。
2.2、告警查询分析常见的小区建立失败原因有以下几大类:资源数据错误:涉及有小区功率配置、小区带宽配置、小区频点配置、共LBBP单板配置、小区BF算法开关配置、小区天线配置、时钟模式配置、小区运营商信息配置等;规格类限制:容量License的限制、CPRI光口速率限制等;共模配置问题;射频相关资源问题;传输资源故障;维护硬件资源故障;经华为U2000网管告警系统查询,12月18日凌晨【东山分局-新建小灵通改造-1】出现“系统超出License容量限制告警”、“配置数据超出License限制告警”等,告警清处时间为12月20日,与指标异常的时间相吻合,怀疑是基站License更新出现异常问题导致E-RAB建立失败。
对于华为的L网基站,出现的告警为“系统超出License容量限制告警”、“配置数据超出License限制告警”,从华为B侧工程师处了解到,12月18日有License文件更新,因为超过6个后License就会失效,一般需通过人为检查发现,人为加载后才能继续生效并提供服务。
但是一样的更新后,其他的基站运行正常,而【东山分局-新建小灵通改造-1】E-RAB 建立成功率为0,查询工参发现【东山分局-新建小灵通改造-1】为TDD制式基站,而周边基站多为FDD制式基站,得出结论:更新License文件时,误把FDD的容量License文件更新进TDD的基站里,导致指标异常。
E-RAB建立成功率案例分析1、发现问题:提取7月1日青岛差小区E-RAB建立成功率差小区,发现LEE0270S9S领海公馆酒店1 (碧海山庄)站点的2小区E-RAB建立成功率低,如下:为了更加明确问题出现的时间点,用xnow提取7月1日8:00-23:00该小区E-RAB建立成功率如下:ffwt AjeporlJhan Target : 电国警屈曙二> Surb "isrg-r 2〒 Chart ge: jne ▼ 土 砧ow d^ta .妙je LptiaieLtft <■' Mun t : ■] MghLKFI ntmE :CELL HOUR - LEE0270S9S - 2由上图可以看出,该小区在 7月1日8点-12点的时候E-RAB 建立成功 率较低;2、 分析问题:(1)从计算counter 入手E-RAB 建立成功率= (pmErabEstabSuccI ni t+pmErabEstabSuccAdded)/ (pmErabEstabAttl nit+pmErabEstabAttAdded) * 100% 由上公式可知:E-RAB 建立成功率可分为两部分: Part a :■ E r no 1-30•PD Q Q 叮 叮a DoE.i —!"士 砖u Acflr.-r-'匚gre 」l.ulh2Sign alii ng connection setup triggered by in itial UE message ;相关counter咅E分: pmErabEstabSuccI nit/ pmErabEstabAtt InitE-RAB setup triggered by MME sending E-RAB setup request toRBS;相关counter咅E分: pmErabEstabSuccAdded/ pmErabEstabAttAdded⑵定位E-RAB建立成功率低是因为 Part a还是Part b通过xnow分别提取了这两部分建立申请和建立成功次数对比数据如下:Part a:由上图可以看出,Init 的建立成功次数基本上等于建立申请次数,成功率很 高,没有问题;Part b :CELL HOUR 一 LEEQ270S9S- 2■ …H E T aH.EstfltaSuc.^Addc 5 B rwi£r abEsi-iibA^tAddcdJU:-上;Tj- ac-tL=OZ7I1E>£insQtJ «ra3e&tabAttlrii -L严■ii・ IW-T m r jineCELL HOUR - LEEO27QS9S - 2■ iC'T. ge t :一二」■D U J W 」®"!岀J l q F •TargetR^rt^Lrare□WEt/M:IS71ft弔2<一;-_=一禽_<电_丄由上图可以看出,8:00-12 : 00点时Added的E-RAB建立申请次数很高, 最高达235次,但建立成功次数为0,导致整体E-RAB建立成功率低;(3)分析信令触发counter的流程Counter :pmErabEstabSuccAdded 和pmErabEstabAttAdded 的触发流程如下图:由上图可知:如果E-RAB建立失败,pmErabEstabSuccAdded 不被触发的基础原因就有3个,如上图所示:1、License not ok,会触发counter : pmErabEstabFailAddedLic ;2、上行GBR 资源过载:触发counter : pmErabEstabFaiIGbrDIEnb3、下行GBR 资源过载:触发counter : pmErabEstabFaiIGbrUIEnb⑷提取以上三个E-RAB建立失败原因的3个counter,定位原因提取了7月1日8:00-23:00该三个counter的取值,如下图:由上图可知:E-RAB建立申请次数等于pmErabEstabFailAddedLic 的取值,也就是说申请多少次,就因为license问题失败多少次。
LTE高级面试知识点整理一、KPI指标优化1、省网优考核指标(各省份有差异,但是不会太大):2、RRC连接建立成功率优化2.1 指标定义RRC建立成功率= [RRC连接建立完成次数]/[RRC连接请求次数(不包括重发)];RRC建立成功率(包括重发)= [RRC连接建立完成次数]/[RRC连接请求次数(包括重发)];2.2RRC连接建立失败话统统计小区内不同原因的RRC连接建立失败的次数。
RRC Connection Reject消息是eNodeB 发送给UE的RRC信令消息,目的是通知UE本次接入过程被eNodeB拒绝。
2.3 可能原因影响RRC连接建立成功率的因素主要有:➢覆盖问题(空口信号质量);➢参数配置(定时器、功率控制等);➢干扰问题(时钟失步、器件故障、外部干扰等);➢设备故障;➢网络拥塞;➢其他原因2.4 分析流程及优化方法从话统统计到的RRC建立失败原因值来看,主要存在两种场景:由于资源失败导致的RRC连接建立拒绝(L.RRC.SetupFail.ResFail)及由于空口无响应导致的RRC连接建立失败(L.RRC.SetupFail.NoReply);eNB发送RRC Connection Reject消息次数主要有以下几种场景:(1)小区准入失败导致发送RRC REJ;(2)激活用户数受限导致发送RRC REJ;(3)CPU占用率过高,流控导致发送RRC REJ;处理方法,调整以下参数:MML命令:MOD SRSCFG: SrsCfgInd=BOOLEAN_TRUE, TddSrsCfgMode=ACCESS_FIRST;配比2场景下,体验优先SRS和PUCCH的规格是120用户,改为接入优先,规格放大为400用户。
当小区流量过高或CPU负载过高时,ENB会启动流控,话统中主要由以下两个指标:L.RRC.SetupFail.Rej.FlowCtrl流控导致的发送RRC Connection Reject消息次数;L.RRC.ConnReq.Msg.disc.FlowCtrl流控导致的RRC Connection Request消息丢弃次数。
License过期受限导致北京工商大学等E-RAB连接成功率低案例
1、问题描述
4月8日,KPI指标监控的时候发现,从凌晨2点开始全网的E-RAB建立成功率指标出现恶化,跟之前的连续几天对比发现,指标下降了2%左右,具体如下图所示:
2、问题分析
对全网的E-RAB建立失败原因进行分析发现,失败原因“无线资源不足导致E-RAB建立失败”次数在凌晨2点后开始剧增,导致具体如下图所示:
由于该问题为凌晨突发事件,有可能为现网操作导致,询问网管相关人员,发现凌晨未重大操作,排除人为操作导致。
排除人为操作可能,特通过对“无线资源不足导致E-RAB建立失败”次数最多的小时8:00进行钻取到小区级进行分析发现,存在大量由该原因导致E-RAB建立成功率低的TOP小区,TOP小区的E-RAB建立成功率只有3.34%,且主要聚焦在北京工商大学以及周边几个基站,
E-RAB建立失败次数占比高达93.57%,排除TOP小区后,全网的E-RAB建立成功率为99.86%,具体如下图所示:
TOP小区中的TOP1为室外站北京工商大学_1小区,对该小区进行深入分析发现,该小
区的E-RAB建立成功率在凌晨2:00开始恶化,“无线资源不足导致E-RAB建立失败”次数在2:00后开始剧增,与全网现象一致,具体如下图:
通过以上分析,怀疑该小区存在告警,通过U2000对小区的告警进行核查,发现该基站在凌晨2:45产生了“系统无License运行告警”,导致该基站进入“默认状态”,使得系统定义的License控制项和可选功能项受到限制,最直观的表现为用户接入数受限和基站支持的最大速率受限,最终导致E-RAB建立失败。
通过TOP小区分析,核查全网基站告警发现,现网还有59个基站在凌晨2点后出现“系统无License运行告警”告警,与全网核查的出来的问题TOP小区一致。
3、问题跟因
License文件为基站功能项的授权文件,license文件超过license文件截止日期后,首先是进入宽限状态,在“宽限状态”下,网元可以继续按照License文件的授权值运行,使用期
限为60天,在此期间网元业务不受影响,超过60天宽限期后,则网元进入“默认状态”。
在默认状态下,网元按照系统定义的License控制项缺省容量运行,且所有可选功能项都关闭,且会上报“ALM-26818 系统无License运行告警”。
、
网元处于缺省容量下,支持的RRC 连接用户数为6个超过6个RRC Connected时新用户将无法接入,RRC建立成功率会受到影响;其次受基站流量(FDD)licnese的控制(基站缺省支持的流量能力为5Mbit/s),当已经接入的用户eNodeB为其分配的上下行流量达到基站缺省的流量支持能力时,新接入的用户级切换入的用户e_RAB都会建立失败,会影响e_RAB建立成功率以及切换成功率等指标。
4、解决方案
对有“系统无License运行告警”告警的基站,进行新Licnese重打操作。
5、建议与总结
4月8号9:13左右无线侧对“系统无License运行告警”的基站进行了License重打操作,9:15该告警确认已清楚,具体如下图所示:
License重打告警得到清除后,进行KPI指标监控对比发现,全网E-RAB建立成功率指标9:00后开始恢复,11点左右基本恢复正常,“无线资源不足导致E-RAB建立失败”次数在9:00后开始减少,到11点后次数降到0次,具体如下图所示:
建议现网定期对影响基站运行业务的License进行定期维护,提前知晓License到期日期,从而来预防此类问题的再次发生。