DIY编程器网

 找回密码
 注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 695|回复: 0
打印 上一主题 下一主题

[待整理] IMS体系结构中的QoS问题

[复制链接]
跳转到指定楼层
楼主
发表于 2014-10-13 14:33:33 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
摘要 完整的服务质量(QoS)解决方案是通信网络融合中的重要课题,引入基于IP多媒体子系统(IMS)框架的、具有QoS保证的资源控制架构是解决融合网络QoS问题的重要方法。本文在介绍基于综合服务与区分服务相结合的IMS QoS服务模型的基础上,详细讨论IMS网络中的QoS控制结构、资源控制和QoS授权等问题。
  IP多媒体核心子系统(IMS)是第三代移动通信合作伙伴项目(3GPP)提出的支持IP多媒体业务的子系统。它可以提供多种媒体业务,顺应了通信网络融合的大趋势,并将逐渐成为下一代网络(NGN)的核心控制体系结构。IMS是实现网络融合和业务融合的核心标准,基于IMS的NGN体系架构必将成为通信行业未来发展的重要目标。
  然而,由于NGN体系的复杂性,多方面的约束条件使其标准化举步维艰。QoS保证问题是NGN能否成为未来统一平台的关键,而这很大程度上取决于NGN所基于的分组承载网络。目前基于分组承载网的各种QoS解决方案主要关注承载网络设备的QoS处理能力,更多的是基于分组承载网络设备的承诺访问速率CAR、整形、队列调度、优先级标记等实现技术,这些具体技术是所有QoS实施的基础,但NGN还需要从网管、资源管理与控制等方面实施相应的QoS控制策略,以形成一个全网的QoS解决方案。另外,NGN的QoS问题主要是集中在接入网和城域网,开放的接入网面临满足电信级网络和IPTV业务要求的挑战,例如要达到IPTV单路很高的可靠性、可用性目标和网络的50ms业务恢复时间的要求,接入网和为现有IP数据业务设计的城域数据网都很难满足,需要采用必要的策略加以解决,同时宽带设备对解决QoS也提出了要求。IP网络本身是“尽力而为”地将数据包从某个源端点高效传送到某个目的端点,不提供端到端的可靠性、低时延和时延抖动、低丢包率等QoS保证。
  在标准化方面,人们将会从端用户对QoS的感受出发,定义电话和多媒体业务的端到端QoS类型与要求,明确多媒体业务中的各业务类型分别登记QoS类别的方法,给出域间低层QoS的控制规范和利用低层QoS的机理以保证上层QoS的规范。在多个异构网相连时,可能涉及不同的QoS机制,如何将端到端的QoS指标分解和采用不同的QoS措施以保证这些指标,将是NGN标准化的一项艰巨任务。
1、IMS中的QoS问题
  提供具有严格QoS保证的数据、语音、图像、视频等多种移动多媒体业务是第三代移动通信走向成熟的关键,也是面临的挑战之一。首先,3G承诺的多种具有应用数据业务模型具有各自不同的流量特征,对带宽和时延等服务质量参数有严格的要求;其次,无线信道的带宽受限、差错率高和移动性等特点使得多媒体业务在接入控制、资源分配等方面的要求更为苛刻;最后,如果采用全IP网络架构,传统的IP网络仅能提供尽力而为服务,这在UMTS移动网络下更难以满足要求。
  在3G网络中引入IP多媒体子系统(IMS)为支持未来业务的QoS提供了新的空间。IMS提供的端到端QoS机制是终端通过协商如下参数实现:如媒体类型、业务流方向和媒体类型的比特率、分组大小、分组传输频率、各媒体类型的RTP净荷的用法和带宽的自适应等。终端采用适当的协议(例如RTP)将各个媒体类型进行编码和分组,并通过IP上的某种传输层协议将这些媒体分组传递到接入网和核心网。IMS只是一个控制的网络,IMS中的接入网和骨干网与IMS一起提供端到端QoS,其提供给终端用户的业务质量取决于承载网络的服务质量和承载网络能力。
  在IMS的框架下,核心网络的信令和数据都基于IP网承载,而IP网的无连接和不保证QoS的特性使得QoS难以达到电信级水平。IP网络QoS保证不是某一单项技术所能解决的,它需要业务平面、数据平面、控制平面和管理平面的配合,涉及多平面多层次的综合技术。
  首先,需要解决控制颗粒度和可扩展性之间的矛盾。要确保电信业务的QoS,基于可用资源的接纳控制必不可少,但对每一个呼叫都执行复杂的接纳控制算法相当于回归传统交换的做法,违背了IP网的设计原则;其次,需要解决NGN分层结构中QoS层间垂直控制问题。QoS在本质上从属于具体应用,故QoS的实现必然涉及业务层、控制层和传送层之间的交互,必须定义层间QoS映射和控制信令标准,而目前QoS研究大多局限于传送层,未很好考虑上层机制;再次,需要解决多域QoS控制的问题。QoS是端到端的性能,因此必然涉及用户驻地网、接入网、城域网和核心网,还可能跨越不同的运营商网络,每一类网络域都具有其不同的技术机制和服务环境,因此应采用不同的解决方案,这些也是IMS急待解决的问题。
  基于以上这些问题,本文先介绍了常用的QoS解决方案——IntServ模型和DiffServ模型,再详细讨论IMS中QoS控制架构、媒体授权及资源预留等问题。
2、IMS QoS服务模型
  2.1 综合服务(IntServ)模型
  综合服务模型被设计用于提供端到端QoS,其基本思想是对属于不同数据流的分组在路由器中进行不同的处理。该模型应用资源预留协议RSVP(RFC2205)作为资源预留协议。端点发送RSVP消息为一个数据流请求确定的QoS,路由器从接收到的RSVP消息中获得关于该数据流的描述,并据此对所有属于该数据流的包进行正确操作。在路由不改变时,数据流的包将遵循与PATH消息一样的路径。而当拓扑改变时,如果在规定时间内由RESV消息产生的原预留状态没有被新的RSVP消息更新,路由器将删除该状态。
  综合服务模型的主要问题是网络需要存储大量的状态信息。当一个包到达路由器时,路由器需要检查它目前正处理的所有预留,来判断这些包是否属于相应的预留。这就意味着路由器需要保存每一个数据流的状态细节,并且对任何一个包分配路由前都要进行检查。即使RSVP能支持多播会话的预留集合从而减少网络需保持的状态数,但一般仍然认为核心网应用RSVP不能做到很好的均衡。
  2.2 区分服务(DiffServ)模型
  区分服务(RFC 2475和RFC 3260)模型解决了综合服务模型中存在的一些问题。区分服务路由器应保持最小状态以便能够快速决定数据包所需要的处理。而逐跳处理的依据则是逐跳特性PHB(Per Hop Behavior),它们由8bit区分服务代码点(DSCP)标识。网络节点通过识别DSCP字段,把复杂的QoS保证转化为PHB。DiffServ网络定义了4类PHB,但是最合适在IMS中实现的有以下3类。
  (1)加速转发EF(Expedited Forwarding)PHB:这种方式不用考虑其它流量是否分享其链路,适用于低时延、低丢失、低抖动和确保带宽的端对端业务;
  (2)确保转发AF(Assured Forwarding)PHB:每个AF类又分为3个优先级,可以对相应业务进行等级细分,QoS性能参数低于EF类型;
  (3)默认或尽力而为型BE(Best Effort)PHB:没有任何QoS保证,AF类超限后可以降级为BE类,现有IP网络流量也都默认为此类。
  DiffServ不需要基于流的端到端的资源预留机制,它在域的范围内工作,把QoS控制推到网络边缘进行。一个区分服务DS域采用统一的定义和资源管理,进入DS域的不同类的负载由边界路由器控制。这一结构与IntServ/RSVP模型相比,实现简单,其缺点是当前的实现结构无法实现严格的端到端的QoS保证,只能实现相对的服务类别。
  2.3 综合服务与区分服务相结合的服务模型
  IntServ/RSVP模型虽然支持点对点通信和组广播,能提供有保证QoS,但要求所有路由器都支持RSVP,而每个路由器还要耗费大量存储空间和处理开销以维护和更新端到端的资源预留,因此只适用于网络边界处,不适用于骨干网。与之相比,DiffServ发送报文前无需通知路由器,也不必为每个流维护状态,且它是对流聚合后的类进行QoS控制。从对路由器的要求来说,DiffServ比IntServ/RSVP更简单,适用于骨干网路由器。
  基于以上比较,图1给出将IntServ/RSVP和DiffServ技术结合起来的服务模型。在接入网内及其与核心网边界处使用RSVP,根据已定义的IP服务框架对数据包进行处理。核心网入口的边界路由器负责把RSVP控制信令中的QoS服务等级信息映射到DiffServ中用DSCP位指示的相应的服务等级,从而在核心网内使用DiffServ,采用相应的PHB对数据包进行处理。在核心网的输出端到接入网的用户接收端,再次使用基于RSVP的QoS分级过滤机制,并借助具体的路由器调度策略保证接收方的QoS。

图1 综合服务与区分服务相结合

3、IMS中的QoS支持方法
  在SIP会话体系中,核心网的边缘路由器完成QoS保证的处理,它负责执行与接入控制和决策功能相关的所有机制。公共开放策略服务COPS(Common Open Policy Service)协议用来向QoS接入点发出QoS预留请求,UE通过SDP协议为实时业务、非实时业务请求相应的编码方案、媒体类型、带宽等媒体参数。SIP会话控制根据用户的个人业务、媒体信息以及所应用的本地策略控制,进行相应媒体参数的授权,所授权的参数返回给用户终端,为建立传输承载作资源预留。
  3.1 IMS中的QoS控制架构
  IMS网络中的IMS会话控制并不直接控制承载网络的资源分配,这需要在IMS会话层和传输承载层之间建立一套交互机制。图2为IMS网络中QoS控制接口的结构模型。IMS网络中的QoS机制完成IMS媒体业务流将要使用的承载业务的授权和控制,它基于在IMS会话中所协商的SDP参数,这种交互被称为基于业务的本地策略。该模型所包含的主要功能实体及其作用如下。

图2 QoS控制的结构模型

  (1)GGSN:为用户提供IMS接入的IP连接,它作为PEP的逻辑功能存在于GGSN的IP承载管理中。UE和GGSN中有如下类似功能部件:IP承载管理:使用标准IP机制进行IP承载业务管理,该逻辑功能存在于GGSN中,UE中可选;转换/映射功能:对UMTS承载业务中用于IP承载业务中的机制和参数进行关联协调,该逻辑功能存在于GGSN中,在UE中可选;UMTS承载业务管理:处理来自UE的资源预留请求,该逻辑功能存在于GGSN和UE中;
  (2)策略决择功能(PDF):是一个逻辑策略决择单元,使用标准IP机制在IP媒体层中实现基于业务的本地策略;
  (3)应用功能(AF):提供应用层对IP承载资源的QoS需求,它在IMS网络中就是P-CSCF网元。
  PDF与GGSN之间的Go接口提供IMS会话层中的PDP与传输承载层中的PEP间的连接,从而实现本地QoS策略控制从IMS会话层映射到传输层。在一个SIP会话中,SIP服务器实现PDP的功能,路由器的作用相当于PEP;IMS网络中PDF完成PDP的功能,而PEP的功能由GGSN完成。
  PEP充当策略网管系统中策略消费者的角色,作为一个逻辑功能组件驻留在GGSN中。PEP可以向PDP提出与策略相关的接入控制请求,并执行PDP返回的策略决定,即把策略信息转化为具体网络设备的配置和操作命令,并加以执行。当不再需要策略时,它可以向PDP提出请求删除该策略。对任何时候PDP发出的策略决定,PEP必须严格执行。PDP和PEP之间通信采用COPS协议,它由IETF组织定义,用来支持IP QoS环境中的策略控制。
  3.2 IMS中的QoS授权
  在UMTS的IMS网络中,媒体和信令可以使用不同的PDP场景。UE请求GGSN建立媒体PDP场景的过程称为资源预留,主被叫UE执行该过程是完全相互独立的。各网元之间的媒体QoS控制的配合原理如图3所示,具体步骤如下。

图3 QoS授权的网络实体和原理图

  (1a)AF(P-CSCF)针对新会话的建立请求,向PDF传递会话信息,并向PDF请求一个授权Token;
  (1b)PDF生成一个授权Token并返回给AF;
  (2)UE收到Token后,向PEP(GGSN)发起PDP场景激活请求;
  (3)PEP收到资源预留请求后,向PDF请求授权,请求中包含授权Token;
  (4)PDF收到授权请求后,根据与AF的事先约定,此时可能通知AF。该步骤和步骤(5)为可选;
  (5)AF收到PDF的授权指示后,返回业务信息给PDF;
  (6)PDF根据AF的业务信息和本地策略,进行策略决择,将授权的QoS和包分类器参数等结果返回给PEP;
  (7)PEP将PDF返回的策略信息与UE请求的信息进行比较,最后向UE返回资源预留请求的执行结果;
  (8)此时UE完成一次会话所需的资源预留,可以继续应用层的业务处理。
  UMTS业务分类与QoS参数之间存在一种映射关系。用户设备UE通过SDP将终端应用层的QoS需求映射到PDP参数中,提出UMTS QoS要求,UMTS QoS管理功能根据UTRAN、SGSN和GGSN中的资源预留情况决定是否接受该请求。一旦允许接入,IntServ/RSVP边界节点将根据已定义的IP服务框架,对数据流进行相应的操作,并在区分服务区将不同QoS类业务映射到不同的PHB。
4、结束语
  网络融合是电信网络发展的必然趋势,对QoS也提出了一些新的要求。引入基于IMS框架的QoS资源控制架构是解决融合网络QoS问题的一个重要方向和方法。本文介绍了基于综合服务和区分服务相结合的IMS的QoS服务模型,分析了IMS中基于策略的QoS架构,讨论了媒体授权和资源控制等问题。3G时代已经来临,IMS的QoS控制技术一定会在全IP的UTMS R5网络有所作为。但同时我们也应该看到,IMS面临的挑战还有很多,IMS技术本身尚在完善之中,真正要投入实际运营还有很多问题需要解决,例如如何解决跨越多个管理域的基于策略的QoS控制机制,如何改进现有QoS模型的不足等,因此还有很多的研究工作和标准制定工作需要完成。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友 微信微信
收藏收藏 分享分享 支持支持 反对反对
您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|文字版|手机版|DIY编程器网 ( 桂ICP备14005565号-1 )

GMT+8, 2024-6-28 10:34 , 耗时 0.081552 秒, 18 个查询请求 , Gzip 开启.

各位嘉宾言论仅代表个人观点,非属DIY编程器网立场。

桂公网安备 45031202000115号

DIY编程器群(超员):41210778 DIY编程器

DIY编程器群1(满员):3044634 DIY编程器1

diy编程器群2:551025008 diy编程器群2

QQ:28000622;Email:libyoufer@sina.com

本站由桂林市临桂区技兴电子商务经营部独家赞助。旨在技术交流,请自觉遵守国家法律法规,一旦发现将做封号删号处理。

快速回复 返回顶部 返回列表