基于3g信令协议与实验推导的qchat多流分析.doc

基于3G信令协议与实验推导的QChat多流分析 刘 瑞关键词： 图5-DO Rev A QoS协商流程 从AT～AAA，可以归纳出如下QoS绑定流程 （1）空口侧：引入了多IP 流及多RLP 流的思想，定义了相应的QoS 请求机制。 （2）RAN侧：重点解决多个IP 流、RLP 流、A8 及A10 连接情况下彼此间的映射关系。 （3）PDSN侧：为解决每个IP 流的IP QoS 的资源申请，提出了业务流模板（Traffic Flow Template，TFT）、QoS 规格等概念，规定了基于IP 流的资源申请流程。 （4）AAA侧：为区别不同用户的QoS 等级，存储每个用户的QoS 规格。这样，在用户进行QoS 申请时，RAN会根据AAA 的QoS 规格来决定是否响应及授权该用户所申请的QoS 等级。 要实现PDSN到AT的QoS资源绑定与空口激活，期间必须完成多流映射与绑定，从IP～MAC多流映射与总体流程如下图6所示： 图6-IP－RLP－MAC多流映射 流程详解： （1）IP flow的QoS协商：如下图，通过实验抓取现网QChat信令分析得知：IP流协商时包括前、反向的QoS协商，两者通过MFPA Attribute Update Requset完成，只是消息中所带的属性有所不同；Verbose：现网为off，即：采用简单的Profile ID的形式；AT通过GAUP消息中的Sub_Blob属性指示了不同IP流的Qos需求 。 图7-QChat IP流协商信令 （2）RLP FLOW的激活与绑定：AN由GAUP的FlowIdentification激活3个RLP流，并通过Reservation Label将3个IP流绑定至RLP流。 （3）MAC FLOW的QoS绑定：RLP流先至Stream，再由SubStream映射至MAC Flow，如下图实验抓取信令： 图8-QChat MAC FLOW QoS绑定信令 至此，已完成Qchat多流绑定，下一步准备QoS资源激活吧。 （4）QoS资源激活与释放：AT通过Reservation On消息激活空口QoS资源。 在基于QChat多流的QoS实现过程中，需要关注一下QoS的下发细节和现网呼应的网管配置，如下图9所示： 图9-基于QChat多流的QoS下发与现网QoS配置 由上可以看出：标准ProfileID由AAA的QoS规格设定，BSC定义了与之对应的速率和时延等参数。4010、503、118属于Qchat辅助流的QoS ProfileID，分别对应“呼叫建立信令流”、“通话中信令流”、“媒体流”。经实验论证：没有以上ProfileID配置，Qchat只会运行在普通默认BE流上，即体现不出QoS！ 通过以上系统配置和完整协商，现在通过实验来体验一下现网QChat多流的QoS保障。如下图10为基于高通协议、抓取信令和T2P曲线理论给出的推导；图11为本论文实验数据，可以充分验证QChat多流的QoS保障。 图10-QChat多流QoS效果（高通协议＋信令＋T2P） 图11-QChat多流QoS效果（实验论证） 3 提升QChat接入感知－－实验推敲现网QoS参数配置 （1）EIDP ProfileID是否要打开：经实验论证，打开ProfileID，AN才允许Qchat终端进行EIDP GAUP协商，有助于Qchat快速接入，提升用户接入感知。 图12-ProfileID参数实验信令与协议[2] （2）反向流DOS是否要打开：经实验论证，打开DOS（Data Over Signaling）后，允许AT为Link Flow发送DOS消息，即使用控制信道、接入信道等非业务信道传送数据，使得Qchat起呼信令在TCC之前就开始交互，规避了由先建立业务信道，再传送起呼信令这种串行排队模式所带来的延迟，有助于提升QChat用户呼叫感知。 图13-反向DOS参数实验信令 4 基于Qchat多播的QoS展望 Qchat单/多播：单播即传输数据仅为一个用户接收，若10个用户需相同数据，服务器要逐一传送，重复10次相同工作（优点：组网简单，仅需AN侧软件升级和核心侧增设QAS/RLS；缺点：当扇区多用户同时需接收相同数据时，将占用大量系统资源）。多播即一组用户共享一个空口信道（优点：满足用户密集的专业群PTT需求；缺点：开通较为复杂，除AN侧软件升级和增加多播数据外，还需在现网基础上增加QAS、BSN、RLS等多个网元）。 QChat单/多播原理如下图： 图14-QChat单/多播 现网配置：目前Qchat部署多为满足用户相对分散的公网集群需求，尚处于初始发展阶段（淮安Qchat用户分布于航道管理），现网Qchat配置为基于VoIP的QoS单播业务伴随DO行业应用快速发展，以校园为代表