Corresponding author: ZHANG Wei, E-mail: zhangwei1@ise.neu.edu.cn
IMS(IP multimedia subsystem)是3GPP(3rd generation partnership project)引入的多媒体通信标准体系,目前已被确认为下一代网络(next generation network,NGN)的核心架构[1].IMS体系结构强调 “业务网和承载网相分离、信令过程和媒体传输相分离”,主要依赖承载网络提供服务质量保障的媒体传输业务[2, 3].IMS采用SIP(session initiation protocol)[4]等协议,定义了较为完善的会话信令控制消息和过程.从目前运营商部署和运营IMS业务的情况看,IMS应用总体上还处于初级阶段且进展缓慢,其技术层面还存在诸多问题,特别是IMS媒体传输技术模式落后,难以适应和支撑快速成长的宽带通信应用需求.随着IMS标准的推进,IMS已被认为是包括移动、固网、固移融合网络在内的各类电信业务网络的核心技术支撑.此时承载网进行端到端的QoS控制变得更加复杂,而且基于传统路由技术构建的单径传输模式也限制了高带宽需求的IMS应用的发展.
若业务媒体满足并发传输条件,相比单径传输模式,多径传输模式可显著提升媒体业务服务质量保证能力[5].传统IP网络中数据传输主要依赖基于网络层缺省路由的单一路径,如果在网络层或者传输层实现多径传输,则需要对现有大量的网络或者终端设备进行硬件升级或者网络协议栈更新,面临着大规模部署的问题[6, 7, 8].实现多径传输的一种有效方式是基于应用层重叠网络方式.作者前期提出了基于应用层中继的多径传输系统框架MPTS-AR[9, 10, 11],通过在网络中部署大量中继节点为终端之间的媒体传输提供多径条件.MPTS-AR是一种基于IP网络的与业务无关的多径传输方案.
目前,IMS尚不支持媒体多径中继传输模式.本文提出一种支持媒体多径中继传输的IMS会话协商管控机制,通过在IMS系统中引入多径传输业务,将MPTS-AR融入到IMS系统中,使得IMS网络侧能够对媒体传输进行管理,比如授权管理、路径管理、计费管理等.一方面,最大程度地重用IMS现有网络架构,保护IMS系统的已有资金投入,提高方案可实施性;另一方面,通过对注册过程和会话建立过程进行多径传输业务授权,使得IMS网络侧有能力为用户提供差异化的媒体传输服务.
1 MPTS-ARMPTS-AR框架如图 1所示,定义了3种逻辑实体,包括控制服务器、中继服务器和用户代理;还定义了相关协议,包括控制平面的中继服务控制协议OpenPath和数据平面的多径传输控制协议(multipath transport protocol,MPTP).OpenPath用于管理中继服务器组成的重叠网络以及中继路径;MPTP规范经由中继路径进行多径传输的行为,采用协议族的形式,包括多个特定应用MPTP,旨在满足多种上层应用的传输需求.
控制服务器和中继服务器组成了中继服务系统,联合起来为通信端点提供多径传输服务.控制服务器是MPTS-AR框架的核心,负责管理中继服务系统中的所有中继服务器,并为有通信需求的终端分配一条或多条经由中继服务器的中继路径.控制服务器与其他组件之间的通信遵循中继服务控制协议OpenPath.中继服务器根据本地存储的路径表进行数据包的路由以及转发.中继服务器无需关心端到端的传输需求,仅需提供UDP转发服务,不但其行为得到大大简化,而且使得MPTS-AR框架能够支持多种应用类型的端到端传输需求.
用户代理是一个位于终端设备的逻辑实体,负责为上层应用提供数据的多径传输功能.如图 1所示,用户代理可采用2种可选方式收集备选的中继路径:一种方式,用户代理利用在通信端点之间建立会话的带外信令获取备选路径,带外信令服务器需要加以扩展以支持OpenPath协议所提供的接口;另一种方式,用户代理使用OpenPath协议直接与控制服务器交互,从而获得备选中继路径.第一种方式的优点是可以避免控制服务器和用户代理之间的大量连接,节省资源同时保证了系统可扩展性,另外,通过限制只与可信任的带外信令服务器之间通信,可以提升控制服务器的安全性.
2 支持多径传输的IMS协商机制 2.1 多径传输业务由于业务的需求是不断变化和增加的,IMS体系结构通过会话控制与业务处理相分离实现了业务开放性,加速新业务的引入.IMS核心网只提供基本业务连通功能以及完善的业务触发管理机制.
为了最大程度地重用现有网络系统,本文将媒体多径中继传输的功能以一种IMS通用业务的形式加以提供,称之为多径传输业务.多径传输业务是指为IMS 客户端之间或者IMS客户端与应用服务器之间的媒体传输提供多径传输而设置的业务.IMS网络中的终端用户和应用服务器可以选择是否签约多径传输业务,签约了多径传输业务的终端用户也可以为每次注册在线或者每次会话选择是否使用多径传输业务.
2.2 支持多径传输业务的IMS网络架构支持多径传输业务的IMS网络架构如图 2所示,为简单起见,图中仅给出了与多径传输业务相关的功能组件,包括多径传输业务控制功能(multipath transport service control function,MPT-SCF)、媒体中继控制功能(media relay control function,MRCF)、媒体中继处理功能(media relay process function,MRPF)和IMS核心(IMS core).
MRCF和MRPF分别对应MPTS-AR框架中的控制服务器和中继服务器.根据网络拓扑和用户规模,运营商决定在每个IMS核心网中部署MRPF的位置和个数.IMS核心在原有基础上增加对多径传输业务的触发功能,在终端或者应用服务器注册和会话建立拆除过程中,将SIP消息路由至MPT-SCF.MPT-SCF是IMS支持媒体多径传输功能的执行点,包括对注册和会话建立过程进行多径传输业务的授权、与MRCF交互进行中继路径的分配和释放、利用信令交互过程向通信双方发布中继路径信息等.IMS 客户端和应用服务器需要在已有基础上扩展MPTS-AR用户代理的功能.
IMS系统基于归属域中的业务控制来实现业务提供,即所有信令消息均通过归属域中的S-CSCF进行路由.MPT-SCF与S-CSCF之间采用ISC接口相连.MRCF与MPT-SCF和MRPF之间分别采用新定义的Xx和Rr接口,遵循MPTS-AR中的OpenPath.终端和应用服务器与MRPF之间采用Xd接口,遵循MPTP协议.
2.3 多径传输业务控制功能MPT-SCFMPT-SCF的功能结构如图 3所示.
在注册过程中,注册授权模块从SIP REGISTER消息中获取多径传输能力标签,进行多径传输业务的注册授权.注册授权策略可以根据用户签约信息和/或者本地策略进行制定.SIP协议易于扩展新的属性或者头域用于支持新的需求,本文选用扩展新SIP头域方式用于表明多径传输能力,格式为
P-Capability-Set: label [,label].
其中label参数为能力标签,多径传输业务的标签值为mpts-ar.后续工作只需扩展新能力标签即可扩展新的处理能力.具有多径传输能力的IMS 客户端或者应用服务器需要在SIP协议的REGISTER,INVITE/200OK,BYE等消息中携带此头域.
2.3.2 会话授权模块在会话建立过程中,会话授权模块获取会话发起方和会话接收方的用户标识,进行多径传输业务的会话授权.在会话拆除过程中,会话授权模块从会话拆除请求消息中提取会话标识,检查此会话是否使用了多径传输业务.会话授权策略可以根据会话双方用户的签约信息和/或者此会话所协商的媒体流信息和/或者本地策略进行判断.
2.3.3 路径管理模块当会话授权成功时,此模块为会话分配中继路径:①从INVITE消息中获取会话标识,以及需要使用多径传输业务的一个或多个媒体流信息,媒体流信息包括流标识、流类型、流方向、会话发起方地址和端口、会话接收方地址和端口等;②请求MRCF为每个单向的媒体流分配一条或多条中继路径,MRCF将中继路径信息回送给MPT-SCF.中继路径信息包括路径标识符、路径优先级、源端的对端地址和端口、目的端的对端地址和端口等.在会话拆除过程中,此模块请求MRCF释放中继路径.路径管理模块可以一次性地、逐个媒体流地或者逐条路径地释放为此会话分配的中继路径.
2.3.4 路径发布模块路径发布模块通过会话建立过程中的信令消息将中继路径信息传递给会话双方.IMS系统利用SIP协议的INVITE/200OK/ACK三次握手过程与SDP协议的Offer/Answer机制,完成会话和媒体协商过程.本文扩展一个新的SDP媒体级属性用于携带中继路径信息,格式如下:
relay-path-attrib = ″a=″ relay-path-label ″:″ direction SP priority SP path-id SP nh-address CRLF
relay-path-label = ″relay-path″
direction = ″s″ | ″r″
nh-address = addrtype ″:″ address ″:″ port
addrtype=″IP4″ | ″IP6″
其中:direction表示中继路径的传递方向;“s”代表信令接收者作为媒体源端的中继路径信息;“r”代表信令接收者作为目的端的中继路径信息;priority表示路径优先级;path-id表示路径标识符;当direction值为“s”时,nh-address表示源端发送媒体的目的地址,当direction值为“r”时,nh-address表示目的端接收媒体的来源地址.
3 原型系统及实验分析 3.1 原型系统本文给出支持媒体多径中继传输IMS原型系统的一种实现.其中,MRCF和MRPF即为MPTS-AR中的控制服务器和中继服务器.IMS客户端除了在已有基础上扩展MPTS-AR用户代理的功能之外,还需要按照2.3节对原有SIP和SDP协议加以扩展,协议栈结构如图 4所示.
MPT-SCF选用开源项目Kamailio.Kamailio是一个高性能的可配置的SIP服务器,采用灵活的模块化机制,可方便扩展新模块来实现特定功能.本文扩展一个新模块multipath,提供MPT-SCF特有的多径传输处理功能,包括以下几个函数:
1) register_mpts_auth().负责对注册消息REGISTER进行多径传输业务授权,并根据授权结果生成并回送注册响应消息.
2) session_mpts_auth().负责对会话建立消息INVITE进行多径传输业务授权.负责对会话拆除消息BYE进行检查来判断此会话是否使用了多径传输业务.
3) start_mpts_session().若会话建立过程中的多径传输业务授权通过,则对相应的INVITE及其200OK调用此函数.从INVITE或200OK中提取会话标识以及需要使用多径传输业务的一个或多个媒体流信息,向MRCF请求分配中继路径并将中继路径信息写入SIP消息.
4) end_mpts_session().若会话使用了多径传输业务,则对该会话的BYE调用此函数,请求MRCF释放中继路径.
3.2 信令流程图 5给出了支持多径传输业务的IMS系统注册和会话建立拆除过程.在注册过程中,IMS核心对REGISTER进行常规处理,然后依据REGISTER中是否携带多径传输能力标签或者其他策略来决定是否将其转发给MPT-SCF.MPT-SCF对REGISTER进行多径传输业务的注册授权.
在会话建立过程中,IMS核心对INVITE进行常规处理,然后依据INVITE是否携带多径传输能力标签或者其他策略来决定是否将其转发给MPT-SCF.MPT-SCF对INVITE进行多径传输业务的会话建立授权.若授权失败,MPT-SCF将不做修改的INVITE回送给IMS核心;否则,与MRCF交互为此会话分配中继路径,并将中继路径信息插入到INVITE回送给IMS核心.IMS系统对INVITE的200OK响应作同样的处理.在会话拆除过程中,IMS核心依据BYE中是否携带多径传输能力标签或者其他策略来决定是否将其转发给MPT-SCF.MPT-SCF与MRCF交互释放所分配的中继路径.
3.3 媒体多径传输性能分析本文探讨IMS系统中多径带宽容量和带宽差异对媒体多径传输性能的影响.用S表示源端的带宽需求,xj表示源端第j条可用中继路径的网络带宽.设α=x1/S,即α表示第1条中继路径的带宽与源端的带宽需求之间的比值,α值越大表明第1条中继路径具有越多的带宽资源.第j条中继路径的带宽是第1条中继路径带宽的1/jβ倍,0≤β≤1,β称为倾斜因子.β=0,各路径带宽资源相同.随β的增加,路径带宽分布越不均匀.其他路径传输质量参数相同,丢包率为1%,传输延时服从正态分布模型,其标准差和均值分别为2 ms和20 ms.
图 6给出了目的端用户代理所接收媒体数据的总丢包率随α和中继路径个数k的变化情况,包括倾斜因子β分别取值0,0.5和1的3种情况.从图 6a可以看出:对于给定的k,总丢包率随α的增加而降低,这是因为α的增加意味着所有中继路径的带宽均增加,同时总丢包率的降低幅度随α的增加而变小,意味着多条路径并发传输所带来的带宽聚合功能对于带宽受限的应用场景是非常重要的;对于给定的α,总丢包率均随着k的增加而降低,这是因为多条路径并发传输可以有效地提供带宽聚合功能,同时丢包率的降低幅度随k的增加而变小,意味着较小的k值(比如2或3)即可获得多径传输的大部分性能增益.以上结论对图 6b和图 6c依然成立,意味着不管多条中继路径的带宽分布是否均匀,多径传输带来的带宽聚合功能依然表现良好.
针对IMS媒体传输技术限制了高带宽需求应用发展的问题,提出了支持媒体多径中继传输的IMS会话协商机制.充分利用IMS体系所具有的会话控制与业务处理相分离的业务开放性特点,将媒体多径传输功能以一种通用业务的形式引入至IMS系统.通过引入多径传输业务,IMS网络侧能够对媒体多径传输进行管理,比如授权管理、路径管理、计费管理等.通过对注册过程和会话建立过程进行多径传输业务授权,使IMS网络侧能够为用户提供差异化的媒体传输服务质量.
[1] | 3GPP.TS 23.228 IP multimedia subsystem (IMS) stage 2[EB/OL].(2014-09-22)[2014-10-09].http://www.3gpp.org/DynaReport/23228.htm.(1) |
[2] | 3GPP.TS 23.207 End-to-end quality of service (QoS) concept and architecture[EB/OL].(2012-09-14)[2014-10-09].http://www.3gpp.org/DynaReport/23207.htm.(1) |
[3] | 3GPP.TS 23.203 Policy and charging control architecture[EB/OL].(2014-06-24)[2014-10-09].http://www.3gpp.org/DynaReport/23203.htm.(1) |
[4] | Rosenberg J,Schulzrinne H,Camarillo G,et al.IETF RFC 3261 SIP:session initiation protocol[EB/OL].(2002-06-12)[2014-09-18].https://www.ietf.org/rfc/rfc3261.txt.(1) |
[5] | Akella A,Maggs B,Seshan S,et al.A measurement-based analysis of multihoming[C]//Proceedings of ACM SIGCOMM.Karlsruhe:ACM,2003:353-364.(1) |
[6] | Thaler D,Hopps C.IETF RFC 2991 multipath issues in unicast and multicast next-hop selection[EB/OL].(2000-11-01)[2014-08-15].https://www.ietf.org/rfc/rfc2991.txt.(1) |
[7] | Ford A,Raiciu C,Handley M,et al.IETF RFC 6182 architectural guidelines for multipath TCP development[EB/OL].(2011-03-12)[2014-08-19].https://www.ietf.org/rfc/rfc6182.txt.(1) |
[8] | Sarkar D,Paul S.Architecture,implementation,and evaluation of cmpTCP westwood[C]//Proceedings of IEEE GLOBECOM.San Francisco,2006:1-5.(1) |
[9] | Lei W M,Zhang W,Liu S.A framework of multipath transport system based on application-level relay (MPTS-AR)[EB/OL].(2014-07-25)[2014-09-03].https://tools.ietf.org/html/draft-leiwm-tsvwg-mpts-ar-02.(1) |
[10] | Lei W M,Zhang W,Liu S.Multipath real-time transport protocol based on application-level relay (MPRTP-AR)[EB/OL].(2014-07-25)[2014-09-03].https://tools.ietf.org/html/draft-leiwm-avtcore-mprtp-ar-02.(1) |
[11] | Zhang W,Lei W M,Liu S,et al.A general framework of multipath transport system based on application-level relay[J].Computer Communications,2014,51:70-80.(1) |