首席数据官

Hi, 请登录

wcdma数据业务掉话分析及优化案例

2012253 WCDMA WCDMA WCDMA WCDMA 数据业务掉话分析及优化案例 数据业务掉话分析及优化案例 数据业务掉话分析及优化案例 数据业务掉话分析及优化案例 (中国联通北京市分公司网络优化中心) 【摘要 摘要 摘要 摘要】 分析了 WCDMA 数据业务掉话原因,着重对占比比 较大的FACH 业务掉话进行了详细的研究,提出了有效的解决方 案,最后结合现网实际案例进行验证。 【关键 关键 关键 关键词 WCDMA掉话 数据业务 FACH 信令负荷 用户感 引言引言 引言 引言 掉话率是反映WCDMA 网络质量的重要指标之一,直接影响到用户感知,是日常 网络优化面临的一个重要问题。 近年来,随着中国联通用户数的不断增长,数据业务话务量达到了历史新高, 同时数据业务掉话次数占比已远远大于语音业务,如何提升 WCDMA 网络数据用户 的感知度成了近期面临的一个重要课题。 本文详细分析了WCDMA 数据业务掉话原因及北京联通WCDMA 掉话业务分布,并 着重对占比较大的FACH 业务掉话进行了详细的研究,提出了有效的解决方案。 掉话的定义掉话的定义 掉话的定义 掉话的定义 1.1 1.1 1.1 1.1 路测掉话定义 路测掉话定义 路测掉话定义 路测掉话定义 UE侧记录的空口信令上看,在通话过程(连接状态下)中,如果空口的消 息,满足以下三个条件的任何一个即为发生掉话: 收到任何的BCH消息(即系统消息); 2012 254 收到RRCRelease 消息且释放的原因值为Not Normal; 收到CC Disconnect,CC Release Complete,CC Release 三条消息中的任何 一条,而且释放的原因为Not Normal Clearing 或者Not Normal,Unspecified。

1.2 1.2 1.2 1.2 话统掉话定义 话统掉话定义 话统掉话定义 话统掉话定义 OMCR 统计的掉话次数与 RNC 触发释放的各业务 RAB 个数有关。主要包括两个 方面: 业务建立成功后,RNC向CN 发送RAB RELEASE REQUEST 消息。 CN发送 IU RELEASE REQUEST 消息,其后收到 CN 送的IURELEASE COMMAND。 同时话统还统计了RNC 触发释放各业务RAB 的原因。 常见数据业务掉话原因分析常见数据业务掉话原因分析 常见数据业务掉话原因分析 常见数据业务掉话原因分析 通对分析 RNC 请求释放分组域 RAB 的原因,得到了无线链路失败、UE 物理信 道或RB 重配超时,RB 重配失败、小区更新资源不足是导致PS 掉话的主要原因。 2.1 2.1 2.1 2.1 无线链路失败 无线链路失败 无线链路失败 无线链路失败 无线链路失败是指系统侧的基站NodeB 收不到终端发的上行信号而向RNC 上报 此终端的上行无线链路失败。系统出现无线链路失败的原因可以分为三类。 (1)终端侧出现异常 终端侧出现异常 终端侧出现异常 终端侧出现异常。

。当终端发生异常,没有上发信号,导致基站侧检测不到上行信号而报无线链路失败。如果终端侧出现异常,要重起业务,一般要对终 端进行重启,终端重启后将会进行一次 Location Update 过程,这从系统侧后台 信令上可以观察到。 (2)无线信道环境出现深衰落或者强干扰 无线信道环境出现深衰落或者强干扰 无线信道环境出现深衰落或者强干扰 无线信道环境出现深衰落或者强干扰。 。无线信道环境出现深衰落或强干扰时,会导致基站无法正确解码终端发出的上行信号而报 RL Failure,如果是出 现深衰落,下行链路的无线信道环境跟上行链路一样,信道质量变差,下行功率 会抬升得比较高,并且UE 会上报Cell Update (3)基站侧出现异常基站侧出现异常 基站侧出现异常 基站侧出现异常。 。基站解错上行信号或接收不到上行信号而报无线链路失败。此时基站应该会出现告警,且基本上不能接入和保持住包括PS 在内的任何 业务或终端了。 2012 255 2.2 2.2 2.2 2.2 物理信道重配超时 物理信道重配超时 物理信道重配超时 物理信道重配超时 PS 掉话统计中,切换超时是导致掉话的重要原因。

以HS 切换超时为例,HS 换超时是指承载HSDPA 业务的终端从源小区向目标小区作 HS HS切换时,层 以上信息不发生改变,RNC使用物理信道重配置方式进行切换,若此时物理信道重 配超时则会导致掉话。为了确定此问题,需要对切换超时掉话相对严重的区域进 行深入跟踪,发现原因,并进行优化验证。 2.3 RB 2.3 RB 2.3 RB 2.3 RB 重配失败 重配失败 重配失败 重配失败 RB 重配失败多发生在切换时源小区和目标小区承载的信道类型不同时,例如 在源小区PS 业务承载在DCH 上wcdma数据业务掉话,切换到新小区承载在HSDSCH 上;或在源小区PS 业务承载在HSDSCH 上,切换到新小区承载在DCH 上。因为涉及到了传输信道的改 变,物理信道重配置方式不再适用,因此需要采用RB 重配置方式实现完成切换过 程。当空口下发RB 重配置消息后,RNC 的用户面在激活时刻到达时会采用新配置, 旧配置被覆盖掉。若切换失败或者空口超时,RNC 的用户面无法获取之前业务的 CTFC,也就无法实现回滚从而导致掉话 。建议对单载波小区进行扩容,配置HSDPA 共享信道,使得HS 业务的切换以物理信道重配的流程进行,降低掉话的概率。

2.4 2.4 2.4 2.4 小区更新资源不足 小区更新资源不足 小区更新资源不足 小区更新资源不足 当无线质量恶化时,终端会上报小区更新,网络侧根据小区更新的目标小区分 配无线资源,如果来自当前归属小区,出于规避下行干扰的考虑将为终端分配新 的物理资源,如果此时该小区剩余资源不足时,会出现小区更新资源不足而导致 掉话[3]。建议合理利用无线网络资源,解决网络拥塞,保持无线网络畅通。 2.5 2.5 2.5 2.5 异常终端表现 异常终端表现 异常终端表现 异常终端表现 一些终端的异常表现导致 PS 业务掉话率产生波动,如终端 RLC 层异常,终端 上报信令连接释放指示、上行业务出现无线链路失败等,且出现问题的无线环境 都较好,使用其它终端现场复测也未出现相同问题 。建议加强推动终端性能测试。 北京联通北京联通 北京联通 北京联通WCDMA WCDMA WCDMA WCDMA 掉话业务分布 掉话业务分布 掉话业务分布 掉话业务分布 通过分析北京联通爱立信设备区域的 GPEH 数据,得到了现网掉话的业务分布 情况。数据业务的掉话次数已远远超过语音业务,目前掉话次数最多的 RACH/FACH业务(用户有少量数据传输,没有给用户分配专用传输信道,上行 2012 256 数据传输使用RACH 信道,下行数据传输使用FACH 信道)、EUL/HS 业务(上行使用 HSUPA,下行使用HSDPA)及PS(64/64)业务(R99 数据业务)。

wcdma数据业务掉话_wcdma数据业务信令流程_wcdma ps业务信令流程

其中以RACH/FACH 掉话占比最高,高达42%。 FACHFACH FACH FACH 业务掉话解决方案及现网实际应用案例 业务掉话解决方案及现网实际应用案例 业务掉话解决方案及现网实际应用案例 业务掉话解决方案及现网实际应用案例 通过GPEH 分析可得FACH 业务掉话是3G 掉话中占比最高的类型。目前现网部 分RNC 的FACH 状态到IDLE 状态定时器仍维持较高水平,用户停留在FACH 状态的 概率仍较高。因此解决好FACH 业务掉话问题就能大幅改善PS 掉话指标。 4.1 FACH 4.1 FACH 4.1 FACH 4.1 FACH 业务掉话分析 业务掉话分析 业务掉话分析 业务掉话分析 FACH 状态掉话概率高的根本原因是FACH 状态没有功率控制。FACH 业务掉话主 要发生在以下两种情况下:第一,当用户驻留在FACH 状态下进行少量的数据传输 时,或者用户由于定时器原因停留在FACH 信道上时间过长时,由于没有功率控制, 大大增加了掉话概率;第二,当用户所需传送的数据变大时,用户需要从FACH 道向DCH信道转换,由于没有功率控制,FACH 状态下用户相当于盲切换到DCH 态,极易产生物理信道重配置失败或者RB重配失败,从而产生掉话。

通过UEH 踪发现,FACH状态下的掉话经常发生在用户从FACH 信道向DCH 信道转换的时刻,详见下图。 2012 257 4.2 FACH 4.2 FACH 4.2 FACH 4.2 FACH 业务掉话解决方案 业务掉话解决方案 业务掉话解决方案 业务掉话解决方案 由于 FACH 状态容易产生掉话wcdma数据业务掉话,建议在网络负荷相对较低的区域,推迟终端从 HS 信道向FACH 或IDLE 信道转换的时机,尽量使终端停留在性能较好的专用信道 上,或者直接关闭FACH 信道状态,将终端状态从3 个(DCH/FACH/IDLE)减少至2 个(DCH/IDLE),通过减少信道转换行为的发生降低掉话可能,同时降低因信道转 换增加的RNC 信令负荷。 4.3 4.3 4.3 4.3 现网实际应用案例 现网实际应用案例 现网实际应用案例 现网实际应用

试看结束,如继续查看请付费↓↓↓↓
打赏0.5元才能查看本内容,立即打赏

来源【首席数据官】,更多内容/合作请关注「辉声辉语」公众号,送10G营销资料!

版权声明:本文内容来源互联网整理,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 jkhui22@126.com举报,一经查实,本站将立刻删除。

相关推荐

评论

  • 昵称 (必填)
  • 邮箱
  • 网址
二维码
评论