精品案例_UE多承载建立导致ERAB建立成功率低分析案例

UE多承载建立导致ERAB建立成功率低

分析案例

目录

UE多承载建立导致ERAB建立率成功率低分析案例 (3)

1问题描述 (3)

2分析过程 (3)

3优化措施 (8)

4经验总结 (8)

UE多承载建立导致ERAB建立率成功率低分析案例

【摘要】一般基站允许UE同时建立做多5个承载，而随着LTE业务越来越广泛，PCRF 在根据业务制定相应策略，会把某类流量单独建立新的DRB承载，其次ue进行一些特殊业务比如volte，就要建立一些特定的承载QCI1/QCO5/QCI2等，这样有时候UE就会建满5个承载，再有业务需要建立时，就会被拒，造成ERAB失败。诺基亚通过LTE520功能，支持每个ue最大建立8个承载，可有效缓解以上问题

【关键字】承载、ERAB建立成功率、LTE520

1 问题描述

7月10日，在日常指标监控重发现LA-金安区-和谐园酒店NFBBU01-914614-50小区，断时间内发生大量ERAB失败，如下：

如上：该小区在7月10日8点-9点时刻，15分钟粒度，ERAB建立失败约300-400次，ERAB建立成功率仅有75%左右。

2 分析过程

1、核查改小区当前无告警。

2、核查无线侧指标，RRC连接成功率、切换成功率、掉线率正常，排除无线

侧原因：

3、抓取EMIL log分析：

分析Emil LOG发现，该小区存在大量的E-RAB Setup Reponse（cause=invalid qos combination）：

以UEID=770的用户为例：

EPC每隔约8s发起一次E-RAB Setup Request，典型情况下会发送5次请求，但都会被eNB 拒绝。

该用户在Initial Context Setup Request中共申请建立5个承载，分别是QCI9/QCI9/QCI1/QCI2/QC5的E-RAB（E-RAB ID分别为5~9）：

value E-RABToBeSetupListCtxtSUReq : {

{

id 52,

criticality reject,

value E-RABToBeSetupItemCtxtSUReq : {

e-RAB-ID 5,

e-RABlevelQoSParameters {

qCI 5,

allocationRetentionPriority {

priorityLevel highest,

pre-emptionCapability shall-not-trigger-pre-emption,

pre-emptionVulnerability pre-emptable

}

},

transportLayerAddress '01100100 01001001 01111111 10110100'B, gTP-TEID '00 D0 6C 9A'H

}

},

----------中间省略-------

{

id 52,

criticality reject,

value E-RABToBeSetupItemCtxtSUReq : {

e-RAB-ID 9,

e-RABlevelQoSParameters {

qCI 9,

allocationRetentionPriority {

priorityLevel highest,

pre-emptionCapability shall-not-trigger-pre-emption,

pre-emptionVulnerability pre-emptable

}

},

transportLayerAddress '01100100 01001001 01111111 10110100'B, gTP-TEID '00 D0 F7 A3'H

}

}

}

eNB侧能够成功建立这5个E-RAB（Initail Context Setup Reponse）：

value E-RABSetupListCtxtSURes : {

{

id 50,

criticality ignore,

value E-RABSetupItemCtxtSURes : {

e-RAB-ID 5,

transportLayerAddress '01100100 01001001 11001111 01001111'B, gTP-TEID '00 00 80 11'H

}

},

---------中间省略--------

{

id 50,

criticality ignore,

value E-RABSetupItemCtxtSURes : {

e-RAB-ID 9,

transportLayerAddress '01100100 01001001 11001111 01001111'B,

gTP-TEID '00 00 80 15'H

}

}

}

但此后EPC 发送E-RAB Setup Request再次请求建立一个QCI=9的E-RAB（E-RAB ID为10）：value E-RABSetupRequest : {

protocolIEs {

{

id 0,

criticality reject,

value MME-UE-S1AP-ID : 192959513

},

{

id 8,

criticality reject,

value ENB-UE-S1AP-ID : 2050

},

{

id 16,

criticality reject,

value E-RABToBeSetupListBearerSUReq : {

{

id 17,

criticality reject,

value E-RABToBeSetupItemBearerSUReq : {

e-RAB-ID 10,

e-RABlevelQoSParameters {

qCI 9,

allocationRetentionPriority {

priorityLevel highest,

pre-emptionCapability shall-not-trigger-pre-emption,

pre-emptionVulnerability pre-emptable

}

},

transportLayerAddress '01100100 01001001 01111111 10110100'B,

gTP-TEID '00 D0 54 18'H,

nAS-PDU '27 0E FE 0C E1 83 A2 01 C1 01 08 19 05 43 4D 57 41 50 06 4D 4E 43

30 30 30 06 4D 43 43 34 36 30 04 47 50 52 53 05 01 0A 1A 8B 59 5D 01 40 30 10 1B 91 1F 71 96 FE FE 74 4B FF FF 00 FA 00 7A 00 32 03 82 5E 04 FE FE FA 7A 58 32 27 1B 80 80 21 10 03 01 00 10 81 06 B7

DD FD 64 83 06 D3 88 14 CB 00 0D 04 B7 DD FD 64'H

}

}

}

}

此时，eNB会以原因invalid-qos-combination拒绝E-RAB建立请求。

经以上分析，判定问题原因：该用户在volte视频业务下，已经建立了QCI1/5/2/9/9;5条承载，而LTE587仅支持每用户最多只能建立5个AM DRB（一个QCI=9的E-RAB对应一个唯一的RLC_AM的DRB）。EPC在Initial Context Setup Request中请求建立5个QCI=9的E-RAB能够成功，但如果再次请求多建立一个QCI=8的E-RAB就会被eNB拒绝。LTE520支持8 EPS bearers per UE，开启后可以有效解决此问题。

3 优化措施

如上，开启基站级参数：act8EpsBearers，ERAB建立成功率恢复，如下：

4 经验总结

volte业务近来发展迅速，而volte业务的承载特点是同时建立多个承载，如一个volte 视频业务会同时建立QCI1、QCI5、QCI2、QCI9等，在volte业务时UE若产生其他特定的流量业务（如家庭卡、校园卡等），就会再建立新的DRB，这样ue就比较建立超过5个承载，

由于目前小区设置UE最大同时建立5个承载，当超过5个时，ERAB建立就会被拒绝，造成ERAB建立成功率低，现通过LTE520功能：act8EpsBearers，UE最多建立8承载，有效解决，建议全网开启。