深圳华为ERAB成功率低问题处理报告-V1_0.docVIP

深圳ERAB成功率低问题处理报告-V1.0 2012年5月初深圳TD-LTE项目日常话统监控显示ERAB建立成功率仅为8%-10%，通过话统分析发现，ERAB建立失败主要为QCI 3的专有承载，如下表所示。 问题分析 QCI介绍 QCI是QoS Class Identifier的缩写，即服务等级分类标示，用来作为各项业务承载功能（如调度、准入、队列管理等）的指示（定义见23.401 4.7.3）。 从业务类型、优先级、时延需求、误码率需求等几个方面，协议规定了QCI分9类（23.203 ），见下表。从承载业务对资源需求的角度，QCI分为两大类，GBR和non-GBR，及需要保证速率和不需要保证速率。通常对时延要求高（对最低速率有要求）的业务，如VoIP、实时游戏，建议以GBR类型的QCI承载；而对时延不敏感，对最低速率无要求的业务，如Ftp下载、可缓冲的视频浏览等业务，建议以non-GBR承载。 深圳项目导致ERAB建立失败的承载类型为QCI 3，即GBR类业务。 QCI Resource Type Priority Packet Delay Budget Packet Error Loss Rate Example Services 1 2 100?ms 10-2 Conversational Voice 2 GBR 4 150?ms 10-3 Conversational Video Live Streaming 3 3 50?ms 10-3 Real Time Gaming 4 5 300?ms 10-6 Non-Conversational Video Buffered Streaming 5 1 100?ms 10-6 IMS Signalling 6 6 300?ms 10-6 Video Buffered Streaming TCP-based e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc. 7 Non-GBR 7 100?ms 10-3 Voice,Video Live Streaming Interactive Gaming 8 8 300?ms 10-6 Video Buffered Streaming TCP-based e.g., www, e-mail, chat, ftp, p2p file 9 9 sharing, progressive video, etc. 信令分析 通过跟踪S1口的信令可以进一步确认深圳ERAB建立成功率低的直接原因是QCI 3的专用承载反复建立失败，如下图所示。 UE附着过程中已建立了QCI 6的默认承载（蓝色框），随后MME发起建立QCI 3的专有承载，反复建立失败（红色框）。对应的ERAB建立失败原因为“reduce load in serving cell”，即小区负荷超限，此原因表示该问题为准入算法模块生效导致。 通过信元分析发现，核心网侧针对专有承载QCI 3，配置上下行最大速率及上下行保证速率均为100Mbps。 原因分析 对比杭州的信令发现，杭州并未发现“专有承载”建立的信令，初步确认杭州没有开启“FTP业务触发专有承载”的功能，所以杭州并未出现大量ERAB建立失败的问题； 问题与终端无关； 从后台信令分析，失败流程仅在S1口出现，没有涉及UU口信令交互，使用了最新版本的E398s和CPE测试，问题现象一致。 准入算法核查 核心网侧开启业务识别触发专有承载建立功能，以该问题为例，终端发起FTP业务后，UGW实时解析用户面的数据，通过端口号等关键信息识别出FTP业务后，UGW通知MME触发建立QCI 3的专有承载，期望将建立在默认承载上的FTP业务迁移到专有承载上,同时指配的上下行速率均为100M。 eRAN3.0版本在eNodeB侧合入了“基于UE能力集合的GBR业务准入”功能，该功能默认开启，优先于准入算法各原则先行判断。 该原则的基本要求是： UE上行最大速率 该UE已承载的GBR上行业务速率+新发起的GBR上行业务速率 UE下行最大速率 该UE已承载的GBR下行业务速率+新发起的GBR下行业务速率 其中UE上下行最大速率取决于终端类别及上下行子帧配比、特殊子帧配比，各种场景下终端最大速率如下表. 1/7上行 1/7下行 2/5上行 2/5下行 CAT3 20Mbps 59Mbps 10Mbps 61Mbps CAT4 20Mbps 72Mbps 10Mbps 90Mbps 深圳网络中核心网侧指配速率高于UE的上下行最大速率，导致ENODEB拒绝建立专