搜索
端到端QoS保障验证1背景为了保障集团测评时Speedtest或者翼网测速结果在各种场景下都能达到比较好的结果。需要考虑各种保障手段。由于南京使用的Speedtest为电信所有，IP固定，所以可以考虑为这种确定的业务建立专有承载，并通过参数修改提高其调度优先级。对于翼网测速业务，由于测试的网站都是TOP网站，所以暂时无法只按照业务IP进行保障。可以按照用户+IP的方式识别特定业务，建立专有承载进行保障。2QoS配置方法2.1QoS配置方法2.1.1核心网侧配置核心网按照用户+IP识别的方式，为特定用户的Speedtest业务建立QCI6的专有承载（现网默认承载是QCI9）。2.1.2基站侧配置这种情况下建立专有承载的目的只是为了保障特定的Speedtest或翼网测速这种确定的业务，测时间比较短，一般都是静止测试，在eNodeB上为不同的QCI配置不同的调度优先级加权因子，用于调整不同QCI业务的调度优先级，同时针对QCI6业务配置特定的预调度参数。其他与QCI相关的参数咱不调整。调度优先级加权因子eNodeB侧完成上行调度用户业务速率是否满足的判断后，由如下公式确定各上行调度用户的调度优先级：其中，：表示UE当前的信道质量。：表示UE历史传输的速率。：表示业务的QCI级别对应的调度优先级的加权，由参数StandardQci.UlschPriorityFactor决定，加权因子配置值越大，则调度优先级越高。QCI等级加权因子可通过标准QCI与扩展QCI配置，标准QCI即协议定义的QCI，详细内容参见2011年3月的R10版本3GPPTS23.203的第6.1.7章节。扩展QCI是在标准QCI的基础上进行等级扩展，使业务等级更加丰富。：表示EPF调度算法的容量调节因子。调节因子等于1时，上行调度遵循资源公平原则。调节因子小于1时，上行调度倾向于速率公平原则。调节因子大于1时，上行调度倾向于容量优先的原则。MO标准QCI参数IDUlschPriorityFactor参数名称上行调度优先级加权因子含义该参数表示上行调度时计算连接优先级时的加权因子。建议值QCI6：1000QCI7：900QCI8：800QCI9：700对无线网络性能的影响该参数设置的越小，上行传输带宽受限场景下或者上行流量License受限场景下为该QCI类型业务分配的上行带宽越小；该参数设置的越大，上行传输带宽受限场景或者上行流量License受限场景下为该QCI类型业务分配的上行带宽越大。下行同样修改。MO标准QCI参数IDDlschPriorityFactor参数名称下行调度优先级加权因子含义该参数表示下行调度时计算连接优先级时的加权因子。建议值QCI6：1000QCI7：900QCI8：800QCI9：700对无线网络性能的影响该参数设置的越大，对应标准QCI的下行业务调度优先级越高，其业务速率越能得到优先保证；该参数设置的越小，对应标准QCI的下行业务调度优先级越低，其业务速率越不会得到优先保证。预调度参数为了排除背景用户预调度对测试用户的影响，考虑只对包含QCI6承载的用户进行预调度，没有QCI6承载的用户不进行预调度。基于QCI的预调度，根据QCI级别配置对应的预调度参数组，包括调度的模式、数据量、最小间隔周期和持续时间等。其映射关系如图6-3所示，每个标准QCI最多关联一个预调度参数组。图基于QCI的预调度参数配置预调度流程当UE建立承载后，eNodeB遍历当前UE所有已建立承载的QCI。当有QCI配置了有效的PreallocationParaGroupId时对于该用户，优先使用QCI级的预调度参数配置，不使用小区级的预调度参数配置。如果有多个QCI配置了有效的PreallocationParaGroupId，则最终采用的预调度参数配置按照最小时延准则确定，具体如下：预调度模式选择策略：普通预调度优先级高于智能预调度优先级。即优先选择普通预调度；如果没有普通预调度，选择智能预调度。普通预调度模式的参数选择策略：预调度用户最小间隔周期选择为这几个配置的最小值，用户预调度数据量选择为这几个配置的最大值。智能预调度模式的参数选择策略：预调度用户最小间隔周期选择为这几个配置的最小值，用户预调度数据量选择为这几个配置的最大值，智能预调度每次持续时间选择为这几个配置的最大值。当没有QCI配置有效的PreallocationParaGroupId时对于该用户，使用小区级的预调度参数配置。QCI6的配置参数如下：QCI9的配置如下：3增益验证3.1测试验证-Speedtest修改上述参数后使用两部手机同时测试Speedtest，通过跟踪，确认被保障的终端建立了QCI6的承载。测试时左边手机是被保障用户，右边是正常手机。两部手机几乎同时开始测试。被保障用户由于有预调度，时延非常小；下载速率稳定在90M以上，上传速率稳定在30M以上，另一部手机在被保障用户下载时下载速率8M左右，在左边手机下载完后速率才提高到90M以上，上传速率也一直在5M以内。如果没有QoS保障，两部手机同时测试时均分资源，每部手机下载速率约50Mbps。同时预调度是小区级配置，不能配置很小的预调度间隔，时延差异无法体现。如果没有配置QoS保障策略，两部手机进行测试时资源会平均分配，速率应该是相等的，大于在50Mbps，所以配置QoS策略后的增益大约是80%。由于这个配置是基于特定的用户及特定IP识别建立专有承载，当前只针对Speedtest服务器的一个IP做了配置，因此增益验证只能用Speedtest业务做对比。地铁站测试增益：行标签下载(Mbps)上传(Mbps)Ping(ms)保障用户85.333.113.7普通用户78.832.429.6增益6.50.715.93.2对KQI三项的增益核心网PCRF修改配置，只对特定用户识别，建立专有承载，配置特殊的调度优先级和预调度参数，验证对首包时延和页面打开时延，视频下载平均速率。首包时延和页面打开时延网站首包时延(ms)增益页面打开时延(s)增益3g.163.com/touch/保障用户124.6-9.61.59.2普通用户115.010.7i.ifeng.com保障用户208.98.12.5-0.4普通用户216.92.1m.baidu.com保障用户82.82.91.1-0.1普通用户85.61.1m.sohu.com保障用户421.6-99.82.6-0.1普通用户321.92.5passport.weibo.com保障用户114.48.30.40.0普通用户122.80.4保障用户120.5-17.61.70.2普通用户103.01.9视频下载平均速率视频平均下载速率(Kbps)增益视频峰值下载速率(Kbps)增益爱奇艺保障用户9370.9164.615042.5375.7普通用户9206.414666.8搜狐视频保障用户14294.4955.814869.7-12.1普通用户13338.614881.8结果分析：搜狐网的首包时延和网易的打开时延差主要是客户端在一轮测试时打开两次网页，记录的指标都是最差的结果。客户端流程处理问题，暂时无法知道为何会连续测试两次。其他结果看不出明显的增益，对于小包业务增益有限。根据话统统计，全网仅有0.07%的小区在0.2%的小时内PRB利用率超过10%，所以负载普遍较低，所以对于非fullfuffer且小文件业务，增益不明显。视频下载平均速率增益增益明显，当前视频播放的文件大小2~3M，修改预调度参数后对于TCP慢启动阶段增益明显，所以该方案对视频下载平均速率增益比较明显。3.3对KPI的影响因为这种保障都是针对少数用户或特定的几种业务，所以对KPI的影响应该比较小。