扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
在本页阅读全文(共2页)
1 融合网络的QoS问题和运营商的业务转型
固定网络、移动网络以及各种接入网络的融合是网络发展的必然趋势,下一代网络(NGN)将基于统一的IP分组承载网,为用户提供各种各样的融合业务。
服务质量(QoS)是融合网络中的一个重要问题。有关QoS的研究工作已经进行了很长时间,更多的是在传输网络的QoS机制方面。但QoS问题不仅涉及通信机制和网络管理,还是一个经营问题,这是因为:各种业务都有其不同的QoS要求,QoS是与业务相关的,同时,QoS的实施和部署需要一定的通信资源和大量的网络管理工作,故QoS是有代价的。因此,QoS应该与业务提供和收费关联起来,成为一种运营商可运营的增值服务。
当前,许多运营商,特别是固网运营商都面临通信量增加而业务收入下降的难题。运营商希望从粗放的带宽运营向精细的有QoS保证的多业务运营转变,转型为通信业务服务商。这样,运营商就不只收取通信(带宽)费,而是可以将业务和通信资源(QoS)进行“捆绑”,将需要QoS保证的通信服务和收费“捆绑”起来,为用户提供需要QoS保证的业务和通信服务,如IP电话、3D实时游戏和网络电视(IPTV)等实时业务,提供有QoS保证的增值通信服务,增加通信带宽的收益和新的业务增长点。
当前现网上还没有一套完整的由业务控制和触发的QoS传输资源控制机制。国际电信联盟(ITU)和TISPAN组织正在基于IP多媒体子系统(IMS)架构,研究业务相关的QoS策略、资源控制、业务保障和业务记费的解决方案和标准[1-2]。
2 融合网络的QoS控制架构
QoS的控制架构如图1所示,关键部件是处于业务层和传输网络之间的接入资源接纳控制功能(RACF)实体,它通过控制传输网系统资源来保障业务层业务控制功能的QoS需求。
RACF是为各类业务在各种传输网络提供实时应用驱动的基于策略的传输资源管理功能。RACF为SCF提供一个抽象的传输网络架构,从而使业务层不需要知道传输网络的网络拓朴、网络链接、资源使用情况及所采用的QoS机制和技术等具体情况。RACF不局限于支持IMS应用业务。
RACF按照SCF的请求,执行基于策略的传输资源控制,确定可用的传输资源,作出接纳决策,将控制策略应用到传输功能实体上执行。RACF和传输层的功能实体交互,以执行下列功能:带宽预留与分配、分组过滤、数据流分类、进行QoS标记、流量整形、优先级调度、网络地址转换控制和防火墙控制等功能。RACF和网络附着控制功能(NACF)交互以获取用户信息,并综合考虑当前传输网络资源状况,从而做出传输资源控制策略。
RACF完成以下的QoS控制功能:
在分组网中和网络边缘控制QoS相关的传输资源;
支持各种接入网、核心网传输技术(如xDSL、UMTS、CDMA2000、Cable、LAN、WLAN、Ethernet、MPLS、IP、ATM等),同时对SCF屏蔽传输技术和网络管理的细节(如网络拓朴、网络链接、控制机制);
支持各种具有QoS能力的用户设备;
支持单管理域和跨管理域的资源接纳控制;
仲裁SCF和传输实体间有关QoS传输资源的协商;
支持相对QoS控制(如DiffServ)和严格QoS控制(如InterServ);
验证端到端的传输资源的可用性;
支持针对不同媒体流不同用户的多样的QoS策略;
支持QoS信令;
审批QoS请求,并只处理批准了的QoS请求;
支持地址端口转换(NAPT)控制和各种防火墙模式;
支持NAT穿越;
输出信息以支持基于资源使用情况和QoS处理的计费;
支持各种基于资源的接纳控制模式;
支持业务优先级处理。
3 融合网络的QoS业务模式和资源控制
3.1 用户设备的QoS能力
用户设备按照QoS协商能力可以分为以下3类:
(1)类型1
类型1是没有QoS协商能力的用户设备(如游戏终端)。用户设备没有传输层和业务层的QoS协商能力,只能和SCF连接以启动业务,不能直接要求QoS资源。
(2)类型2
类型2是有业务层QoS协商能力的用户设备(如SIP电话)。用户设备通过业务信令来进行QoS协商,但不感知传输层QoS。业务QoS只关注与应用相关的QoS。
(3)类型3
类型3是有传输层QoS协商能力的用户设备(如UMTS用户终端)。用户设备支持类似资源预留协议(RSVP)的传输信令,因而能直接和传输设备协商传输层QoS。
3.2 资源控制模式
RACF需要支持下列两种QoS资源控制模式以应对上述3种用户设备类型和不同的传输层QoS能力:
(1)推模式
RACF按照策略规则授权和制订资源控制决策,并下指令给传输层功能实体执行策略决策。
(2)拉模式
RACF基于策略规则进行授权,然后根据传输层功能实体的请求进行再授权,回应最终决策并使之执行。
3.3 QoS控制流程
下面介绍两种资源控制模式的QoS控制流程以及相关层面实体间的交互。
3.3.1 推模式的QoS资源控制流程
推模式适合所有3类用户设备,而前2类用户设备只能采用推模式。
第一类用户设备,没有QoS协商能力。SCF替用户决定业务相关的QoS要求,发送给RACF进行授权和资源预留。
第二类用户设备,支持业务层QoS协商,通过业务信令提出业务层QoS要求。SCF从业务信令中抽取出QoS要求,发送给RACF进行授权和资源预留。
第三类用户设备,采用和第二类用户设备一样的QoS资源控制流程,但要求RACF预先将授权和QoS资源预留信息下到传输层功能实体中。用户设备发出的传输层QoS信令用于调用传输实体中QoS资源和QoS策略的执行。
具体控制流程如图2所示,描述如下:
(1)用户设备向SCF发出业务请求(如,SIP请求),业务请求中有可能包括QoS需求参数。
(2)SCF从业务请求中推导出或抽取出QoS需求参数,发送一个包含QoS需求参数的资源预留请求给RACF,请求QoS授权和资源预留。
(3)RACF基于策略原则、资源状况和存储在NACF中的用户资料进行授权和接纳控制。一旦RACF批准了SCF来的资源预留请求,它就将门控信息、分组QoS标记和带宽分配等信息推到传输层功能实体中。
3.3.2 拉模式的QoS资源控制模式
拉模式只适合第三类用户设备,用户设备显式地通过传输层QoS信令,按照特定传输路径直接向传输层功能实体请求QoS资源预留。但传输QoS资源的预留需要先得到SCF的预授权。
具体控制流程如图3所示,描述如下:
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。