LTE接入问题分析
- 格式:doc
- 大小:43.00 KB
- 文档页数:8
一、掉话问题两类
1、异常RRC connection Release,网络设备异常。
2、RRC重建失败。
二、掉话问题具体原因:
1、弱覆盖
2、干扰
3、切换失败,邻区参数配置不正确,目标小区工作不正常(传输误码,负荷高接纳拒绝)
4、邻区漏配,无法切换
5、越区覆盖,导致参考信号污染或邻区漏配引起切换掉话。
6、拥塞,引起多项指标恶化。
7、设备异常,终端或网络设备异常。
三、RRC重建立触发的原因有如下几种情况:
(1)UE检测到无线链路失败,主要包括:上下行RLC达到最大重传次数;上/下行失步,随机接入失败等原因
(2)切换失败(包括同系统、异系统切换)
如果切换失败,UE会发起RRC重建立请求,并将重建立原因封装在RRC重建立请求消息中。
(3)底层指示完整性保护失败
由于信令的完整性保护失败发生RRC重建立,例如UE和基站的加密以及完整性保护算法不一致,这类原因不常见,通常为终端的问题。
(4)RRC重配失败
RRC重配置的目的是修改RRC连接,在如下场景会发生RRC重配置:建立、修改或者释放无线承载时;执行切换时;建立、修改或释放测量配置等。
异常事件典型案例分析未接通对第四轮测试数据进行分析发现未接通常见案例如下:未接通原因分类求和项:统计次数测试软件问题 6被叫振铃未接听 2测试设备断链 4端到端问题 4TAU与QCI建立流程冲突 1TCP链路问题 1切换与QCI1建立流程冲突 1终端在2G侧无响应 1核心网问题 5TAU与切换流程冲突导致TAU失败 4同一个MME下NAS消息sequence number不连续导致承载未建立 1其他原因 3人为挂断 3终端问题 2跨TAC但未发TAU导致服务拒绝 2总计201、测试软件问题(1)11月25日网格8 被叫振铃未接听主叫号码:136******** 被叫号码:136********(Time: 13:57:00.354,Latitude: 39.92886,Lontitude: 116.52397)13:56:25.184主叫占用朝阳平房乡政府南公园西北HLG-3发起呼叫,RSRP -78 dBm,SINR 17dB,无线环境良好,13:56:27.776主叫收到网络侧转发的被叫的invite 180后,由于被叫一直没有摘机导致在13:56:47.988被叫主动挂机上报invite 603,携带原因为decline,主叫判断为未接通,被叫判断为掉话。
此处属于测试软件问题,应该予以剔除。
(2)11月19日网格55 测试设备断链主叫号码:136******** 被叫号码:136********(Time: 12:57:39.940,Latitude: 39.86454,Lontitude: 116.43406) 12:57:30.631主叫占用丰台左安门桥南HLG-5发起呼叫,RSRP -99 dBm,SINR 6dB 空口良好,由于被叫终端设备断链导致未接通,应该予以剔除。
2、端到端问题(1)11月16日网格67 QCI1与TAU流程冲突主叫号码:136******** 被叫号码:136********(Time: 13:13:21.299,Latitude: 39.92329,Lontitude: 116.41997)13:13:11.358主叫占用东城语文出版社HL-1发起呼叫,被叫于13:13:13.870上发invite 183之后,开始建立QCI1承载,UL information transfer还没有上发时发起TAU,流程冲突导致被叫主动上发invite 580,属于端到端问题,需要集团规范协议流程。
LTE端到端分析思路及案例分析LTE(Long Term Evolution)是第四代移动通信技术,广泛应用于现代的移动网络通信中。
LTE端到端分析是对LTE系统中从用户设备到目标服务器的数据传输进行全面、深入的分析和诊断。
下面将介绍LTE端到端分析的思路以及一个实际案例的分析。
一、LTE端到端分析思路:1.确定测试目标:确定需要分析的LTE网络中的哪一部分,比如用户设备、基站、核心网等。
2.收集数据:使用抓包工具,收集LTE系统中的网络流量数据,包括用户设备与基站之间的无线通信数据、基站与核心网之间的协议数据等。
3. 数据解析:对收集到的数据进行解析,将其转换为可读的数据格式,如Wireshark等流行的抓包工具可以对LTE协议进行解析。
4.数据分析:对解析后的数据进行分析,统计关键指标,如网络延迟、数据丢包率、带宽利用率等,以评估网络性能。
5.问题定位:根据分析结果,定位网络问题的具体位置,确定是用户设备、基站还是核心网的问题。
6.问题解决:根据问题定位结果,采取相应的措施解决网络问题,如调整用户设备的配置、优化基站的信号覆盖、调整核心网的负载等。
7.监控与优化:持续监控LTE网络的性能,不断优化网络配置,以提升用户的通信体验。
二、LTE端到端分析案例分析:假设一个LTE网络中存在用户设备连接问题,用户设备在连接到基站时出现频繁掉线的情况。
以下是一个LTE端到端分析案例的分析步骤:1.收集数据:使用抓包工具对用户设备与基站之间的无线通信数据进行抓包,收集通信过程中的数据包。
2. 数据解析:使用Wireshark对抓包数据进行解析,查看LTE协议中的消息内容,了解设备与基站之间的通信过程。
3.数据分析:通过统计解析后的数据包,计算用户设备连接成功率和掉线率等关键指标,以判断问题的严重程度。
4.问题定位:通过分析抓包数据中的消息内容,查看设备与基站之间的握手过程、认证过程等,确定问题出现在哪个环节。
LTE的随机接⼊及接⼊失败原因分析LTE的随机接⼊随机接⼊是终端在开始和⽹络通信之前的接⼊过程,是保证通信建⽴的决定性环节,随机接⼊过程直接影响到系统的性能。
随机接⼊过程的⽬的是为数据传输分配资源或者取得上⾏同步。
随机接⼊过程分为两种类型:同步随机接⼊过程和⾮同步接⼊过程。
当UE已经和系统取得上⾏同步时,UE的随机接⼊过程称为同步随机接⼈;当UE没有和系统取得上⾏同步时,或者在丢失上⾏同步的情况下称为⾮同步随机接⼊。
LTE中随机接⼊过程的场景在LTE中,有5种情况将会触发随机接⼊过程:1. 从RRC_IDLE状态开始初始接⼊。
2. RRC连接重建⽴过程。
3. 切换。
4. UE处于RRC_CONNECTED状态,UE要接收新的下⾏数据,但是上⾏⾮同步,需要随机接⼊过程建⽴同步。
5. UE处于RRC_CONNECTED状态,UE要发送新的上⾏数据,但是上⾏⾮同步或者是没有PUCCH资源可以传输SR信息,此时需要随机接⼊过程。
LTE随机接⼊过程的模式LTE随机接⼊过程有两种模式:竞争接⼊和⾮竞争接⼊。
1. 基于竞争接⼊对于前⾯提到的随机接⼊应⽤的5种场景,都可以触发基于竞争的随机接⼊过程。
在这个过程中,UE随机的选择⼀个前导序列,这可能导致多个UE同时选择相同的前导序列发送,结果发⽣碰撞,所以需要⼀个竞争解决过程来处理。
2. 基于⾮竞争接⼊对于前⾯提到的随机接⼊应⽤的场景3(切换)和场景4(接收新的下⾏数据),eNodeB可以通过分配⼀个特定的前导序列给UE,来避免竞争。
正常的下⾏链路或者上⾏链路的数据传输出现在随机接⼊过程之后。
LTE接⼊失败原因分析⽬前FDD LTE常见接⼊失败主要包括:RRC连接建⽴失败鉴权失败ERAB建⽴问题FDD LTE接⼊失败分析流程RRC连接建⽴失败原因1. 弱信号起呼导致呼叫信令流程未能完成2. 上⾏RACH问题3. ⼩区重选问题4. 设备异常5. 拥塞问题鉴权加密失败原因1. MAC Failure2. Synch failureE-RAB建⽴失败原因1. 弱信号起呼2. 来⾃UE/MME侧的拒绝3. 参数配置不合理4. 拐⾓效应5. 设备异常。
CIO设置不合理导致RRC连接重建问题处理【现象描述】进行TD-LTE网络DT测试过程中,车辆行至某两个小区边缘区域时,终端发起原因值为otherfailure的RRC重建,之前无RRC异常释放、RRC重建失败、切换失败等事件。
【原因分析】使用Assistant对测试Log进行分析,信令RRCReestablishAttempt原因值为otherfailure。
上图所示为RRC重建事件点,可看出重建发生在两小区边缘地带,不存在掉线等异常事件。
但此时主服务小区RSRP值为-69,而邻区RSRP值为-53,电平差值较大。
【分析流程】首先需要检查基站、传输等状态是否异常,排查基站、传输等问题后再进行分析。
整个切换过程异常情况我们分为几个阶段:测量报告发送后是否收到切换命令,收到重配命令后是否成功在目标测发送MSG1,成功发送MSG1之后是否正常收到MSG2;在某一环节出现问题我们可查询相应处理流程进行排查。
由于终端未收到切换命令,可能有两种情况:1、基站未收到测量报告(可通过后台信令跟踪检查):检查覆盖点是否合理,主要是检查测量报告点的RSRP,SINR等覆盖情况,确认终端是否在小区边缘,或存在上行功率受限情况(根据下行终端估计的路损判断)。
如果是该情况,按照现场情况调整覆盖,及切换参数,解决异常情况2、基站收到了测量报告:2.1基站未向终端发送切换命令情况:(1)确认目标小区是否为漏配邻区(2)需要检查是否目标小区未向源小区发送切换响应,或者发送HANDOVER PREPARATION FAILUE信令,在这种情况下源小区也不会向终端发送切换命令。
2.1基站向终端发送切换命令情况:主要检查测量报告上报点的覆盖情况,是否为弱场,或强干扰区域,优先建议通过工程参数解决覆盖问题,若覆盖不易调整则通过调整切换参数优化具体分析流程图如下:图1 流程图【分析过程】根据Serving+nighboring Cell图中显示,虽然服务小RSRP值还处于正常水平,但此时邻区电平值已高于服务小区16dBm,服务小区RSRQ已降低到-20。
1、无线接通率指标无线接通率=RRC连接建立成功率*E-RAB建立成功率=(RRC连接建立完成次数/RRC连接请求次数(不包括重发))*E-RAB建立成功总次数/E-RAB建立尝试总次数*100%、 RRC连接建立成功率RRCSetupSuccessRate=()/话统统计方法:RRC建立统计点【A点】(1)指标加1,不统计重发的次数。
Case1:eNB下发RRC_Conn_Setup消息后,在T300定时器超时前,收到相同的UeID发起的RRC_Conn_Req(Setup丢失,UE MAC冲突解决定时器超时后重发RRC_Conn_Req,UeID 不变),记为一次重发RRC_Conn_Req消息。
Case2:T300超时后,UE仍未收到RRC_Conn_Setup,UE重新搜网,发起初始接入,UeID 是取0~239的随机值或上层下发的TMSI。
eNB侧记为新的一次初始接入,加1。
Case3:发起Attach后会启动T3410定时器。
如果UE发出RRC_Conn_Setup_Cmp后,ENB 没有收到,UE会在定时器超时后重新发起Attach,ENB侧记为新的一次初始接入;RRC_Conn_Setup_Cmp丢失不会触发重建,发起重建的前提是安全已经激活。
(2)如果RRC Connection Request消息信元Establishment Cause为“emergency”,指标加1。
(3)如果RRC Connection Request消息信元Establishment Cause为“highPriorityAccess”,指标加1。
(4)如果RRC Connection Request消息信元Establishment Cause为“mt-Access”,指标加1。
(5)如果RRC Connection Request消息信元Establishment Cause为“mo-Singnalling”,指标加1。
(6)如果RRC Connection Request消息信元Establishment Cause为“mo-Data”,指标加1。
【B点】当eNodeB下小区接收到UE发送的RRC Connection Request消息并下发RRC ConnectionSetup消息给UE时,指标加1。
【C点】当eNodeB收到UE返回的RRC Connection Setup Complete消息时统计相应指标,加1。
、ERAB建立成功率ErabSetupSuccessRate=()/话统统计方法:图4如上图中A点所示,当eNodeB收到来自MME的E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST(初始上下文设置请求)消息时统计该指标。
如果E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息中要求同时建立多个E-RAB,则相应指标按各个业务的QCI分别进行累加。
2、接入性能优化流程接入失败通常有三大类原因:无线侧参数配置问题、信道环境影响以及核心网侧配置问题。
因此无线接通率优化流程可以按以下步骤进行:(1)通过话统分析是否出现接入成功率低的问题,当前RRC\eRAB接通率指标一般为98%,也可根据对接入成功率指标的特殊要求启动问题定位。
(2)确认是否全网指标恶化,如果是全网指标恶化,需要检查操作,告警,是否存在网络变动和升级行为。
检查无线侧以及核心网侧参数配置是否合理,如定时器T300、T302、T3410,以及参数小区接入禁止、小区最小接入电平、IPPATH、Ncs等。
(3)如果是部分站点指标恶化,影响全网指标,需要找出TOP站点。
(4)查询RRC连接建立和ERAB建立成功率最低的TOP10站点和TOP时间段。
(5)查看TOP站点告警,检查单板状态,RRU状态,小区状态,OM操作,配置是否异常。
(6)针对TOP站点进行针对性的标准信令跟踪、干扰检测进行分析。
(7)如果标准信令和干扰检测无异常,将一键式日志,标口跟踪,干扰检测结果返回给厂家技术人员分析。
接入问题优化流程图如下图所示:接入问题优化流程图3、接入问题排查分析、E_NB配置问题排查PDCCH符号数配置问题测试局点为了尽可能提高下行吞吐率, PDCCH通常固定1符号,但在20M带宽以下,可能出现无法接入的问题。
5M小区,PDCCH固定1符号,总共能使用的CCE个数为3,由于CCE资源受限接入不了。
10M小区,PDCCH固定1符号,总共能使用的CCE个数为8个,受上下行配比约束,下行最多能用5个,而10M小区公共信令的聚合级别为8,需要8个,因此CCE资源受限所以接入不了。
15M小区,PDCCH固定1符号,总共能使用的CCE个数为12,受上下行配比约束,下行最多能用8个,PDCCH功控开关关闭时可以接入。
PDCCH符号数配置IPPATH配置问题基站在完成了安全的配置与UE能力的获取后并向小区申请资源,会向TRM申请GTPU资源,如果申请资源失败则会向核心网返回初始上下文建立失败响应INIT_CONTEXT_SETUP_FAIL;原因值填写transport resource unavailable(0);如下图所示:初始上下文建立失败响应信令截图在这种情况下,对照开站summary首先查看一下MML中的IPPATH是否配置正确,如果已经配置正确,则查看请初始上下文建立请求消息(INIT_CONTEXT_SETUP_REQ消息)中transportlayeraddress的信元值是否为配置的IPPATH值,如果不一样则需要确认一下是我们配置错误还是核心网填写错误。
同时查看路由信息配置是否正确,如果IPPATH正确,但路由错误,同样会出现传输资源不可用的错误信息。
如果以上都不符合则需要把IFTS打开,将跟踪发给厂家技术人员来确认问题的原因。
初始上下文建立请求消息信令、top小区分析处理、TOP小区筛选通过U2000导出全网每日话统文件,按照()次数从高到低排序,结合接入成功率,选出TOP10站点接入成功率低的小区。
按照()次数从高到低排序,结合ERAB建立成功率选出TOP10 ERAB建立成功率低的站点。
目前TOP小区提取暂按以下方式操作:①RRC请求次数大于50次②接通率小于98%。
③在一周之类重复出现2次以上的小区。
若前三种无法提取出TOP小区,可按RRC,ERAB建立失败次数,分开求和后降序排列筛选RRC 和ERAB建立失败的TOP小区。
、TOP小区状态检查检查TOP小区的状态是否正常,可以在U2000上,通过MML命令“DSP CELL”能查看到小区的总体信息。
如果小区状态显示不是“正常”,可以按如下方法进行简单排查:如果存在S1链路异常告警,请检查S1链路配置是否正确。
如果存在RSSI/RSRP通道不平衡,需要检查天馈互调干扰,如果存在驻波告警,需要通过DSP TXBRANCH,DSP RXBRANCH查看RRU发射和接收通道状态。
如果存在小区不可用告警,需要返回主控和基带板一键式日志。
、TOP小区指标分析通过话统可以得出TOP小区原因分布,TOP小区中RRC和ERAB建立失败次数原因值说明:①对小区RRC建立失败次数:资源分配失败而导致RRC连接建立失败的次数,指标ID:83;重点关注top资源是否足够,包括top用户数,传输、PRB等;UE无应答而导致RRC连接建立失败的次数,指标ID:84;关注质差、干扰、无线环境等;小区发送RRC Connection Reject消息次数,指标ID:69;关注传输问题、是否拥塞、干扰;因为SRS资源分配失败而导致RRC连接建立失败的次数,指标ID:85;重点关注SRS带宽、配置指示、配置方式、SRS ACK/NACK设置是否合理等;因为PUCCH资源分配失败而导致RRC连接建立失败的次数,指标ID:86;关注PUCCH信道相关参数设置是否合理,CQI RB数配置是否合理等;流控导致的RRC Connection Request 消息丢弃次数,指标ID:89;关注拥塞,业务流控相关参数是否设置正确等;流控导致的发送RRC Connection Reject消息次数,指标ID:90;关注拥塞,业务流控相关参数是否设置正确等;②对小区E-RAB建立失败次数:因未收到UE响应而导致E-RAB建立失败的次数,指标ID:17;处理建议:需排查覆盖,干扰,质差,ENODEB参数设置错误,终端及用户行为异常等原因。
核心网问题导致E-RAB建立失败次数,指标ID:76;处理建议:需跟踪信令,排查核心网问题(EPC参数设置,TAC码设置的一致性,对用户开卡限制,硬件故障方面排查);传输层问题导致E-RAB建立失败次数,指标ID:77;处理建议:需查询传输是否有故障,高误码,闪断,传输侧参数设置问题。
无线层问题导致E-RAB建立失败次数,指标ID:78;处理建议:处理建议:需排查覆盖,干扰,质差,ENODEB参数设置错误,终端及用户行为异常等原因。
无线资源不足导致E-RAB建立失败次数,指标ID:79;处理建议:1、排查TOP小区资源是否足够,是否故障引起,若存在资源不足问题,可考虑参数调整,流量均衡(小区选择,重选和切换类参数);2、结合现场调整天馈,流量均衡;3、热点区域,增补基站等;安全模式配置失败导致E-RAB建立失败次数,指标ID:80;处理建议:需排查覆盖,干扰,质差,ENODEB参数设置错误,终端及用户行为异常等原因。
、TOP用户分析通过CHR日志分析可以获取RRC建立失败和ERAB建立失败TOP用户的TMSI。
在CHR数据中,可以通过TMSI来确定是否为同一个用户,具体方法如下:当前华为核心网TMSI分配的机制是对于同一个IMSI用户,TMSI的右起第三个byte的数据进行随机赋值,即某用户的TMSI中只有第三个字节的8bit发生变化(如AA ** BB CC)就是同一用户。
如下图所示,C0 ** 00 05就是同一个用户。
使用INSIGHTSHARP工具分析同一TMSI用户的多个接入流程,查看L2_SRB_LOG字段记录的接入时上行信道质量DMRS_SINR和DMRS_RSRP,可以初步确认用户是否处于上行弱覆盖区域:DMRS_SINR<0db或DMRS_RSRP<-131dbm可以认为终端处于弱覆盖区域。
CHR字段说明截图、TOP小区跟踪通过话统分析出TOP小区和TOP时间段后,在对应的小区和时间段,打开Uu口,S1口,X2口跟踪,查看接入流程在哪一步失败。
通过TOP用户的TMSI在核心网侧获取到IMSI,可以启动该用户的全网跟踪。