ABIS时隙释放定时器长度对速率的影响

ABIS时隙释放定时器长度对下载速率的影响ABIS时隙有如下几个用途：信令链路（OML，每个基站一条；RSL，每个载频一条）统计复用；语音信道（每个信道需要一条16kbps的时隙，）；PDCH信道（每个信道需要若干条16kbps的时隙，其中一条称为主链路，其它称之为副链路）。在ABIS口时隙为非FlexABIS的情况下，语音信道和PDCH信道在信道配置时就固定绑定一条16kbps的时隙。然后对于正在做分组业务的手机，如果需要调整编码方式，且需要ABIS资源，则去申请ABIS口空闲时隙，申请成功后，进行编码方式调整。当编码方式下调时，不会触发ABIS资源释放。在信道空闲时，在“ABIS时隙释放定时器长度”超时时进行释放，华为的ABIS口资源采用基站为单位的资源池，同站小区ABIS资源共享。问题描述：分析邯郸市区数据拉网测试LOG时发现当MS占用DCS食品厂_2小区信号进行FTP下载过程中编码方式一直为MCS2，接收电平为-60dbm，MEANBEP8PSK均为31，但下载速率不理想，MS占用国税局_0小区信号下载时情况类似。图1MS占用DCS食品厂_2下载测试截图图2MS占用国税局_0下载测试截图问题分析：测试优化的重点是EDGEFTP下载速率的提升，在对测试数据进行分析时关注指标如下：第一指标：App.ThroughputDL（应用层下载速率）第二指标：下行时隙占用情况、下行编码使用情况、下行每时隙复用度第三指标：EGPRSBEP、RLCBLERDL、RxLev_Sub在对此类问题的描述中知道这两个小区都是由于空闲时隙不足导致编码方式偏低，从而影响应用层的平均下载速率，MS占用DCS食品厂_2小区编码方式一直为MCS2且持续时间达到2.5分钟，而占用国税_0小区下载过程中MCS2的编码方式停留只有1分钟，随着编码方式的上升，相应的下载速率最高达到180kb/s，这种现象在FTP测试中经常发生。查询PS域信道管理参数设置发现，DCS食品厂_2小区“ABIS时隙释放定时器长度”设置为20，而国税局_0小区“ABIS时隙释放定时器长度”设置为10。由于ABIS口资源采用基站为单位的资源池，一个站下面的所有小区进行ABIS资源共享，如果定时器周期过大，空闲ABIS时隙不能被充分利用，造成资源的浪费，如果定时器周期过小，释放比较快，对于同站址不同小区可以更好的申请空闲时隙，但是可能需要频繁申请ABIS时隙。国税局_0小区由于设置值比较小，能够较短时间内重新申请到空闲时隙，但同时在较短的时间内空闲时隙被其它用户抢占。问题处理：对于修改相关参数无法解决问题的基站建议增加传输，从后台提取的无空闲时隙导致ABIS时隙申请失败次数也验证了这两个基站的确存在空闲时隙不足。提取3天6忙时平均值，DCS食品厂基站平均ABIS时隙申请失败次数为3919次，现网配置145个空闲时隙，计算实际所需ABIS空闲时隙数目为293个；国税局基站平均ABIS时隙申请失败次数为8447，现网配置150个空闲时隙，计算实际所需ABIS空闲时隙数目为411个。结合上述统计数据，在两个基站原有4条传输的基础上再增加两条传输并已提交扩容申请表，避免因空闲时隙不足导致FTP下载速率低。统计数据及扩容需求如下表：总结：ABIS空闲时隙不足不仅影响后台高阶编码比例指标，更对前台测试指标产生较大影响，降低了用户感知。统计全网空闲时隙不足基站250个，平均高编码比例为25.43%，平均ABIS空闲时隙申请失败次数为2390个，计划共扩容E1传输284条，详表见附件《市区及郊县基站E1传输扩容需求》（已提交）：市区及郊县基站E1传输扩容需求.xls