PoC中发言权控制机制的分布式改进

刘海鹏，廖建新，朱晓民

(1. 北京邮电大学 网络与交换技术国家重点实验室，北京 100876；2. 东信北邮信息技术有限公司，北京 100191)

1 引言

随着重叠网络(overlay network)技术以及协作式多媒体应用(CMA, collaborative multimedia applications)[1]类业务的快速发展，基于IMS (IP multimedia subsystem)平台的 PoC (push to talk over cellular)业务日益引起业界的广泛关注[2]。半双工是PoC的基本业务属性之一，在会话中任意时刻，最多只允许有一个用户发言，其他用户处于接听状态。有发言需求的用户通过按键来竞争会话中唯一的一个发言权。OMA (open mobile alliance) 为PoC定义了一套基于集中式控制思想的发言权控制机制 TBCP (talk burst control protocol)[3～5]。其具有集中式机制[6～8]固有的缺点：中心节点维护成本高、容易产生控制瓶颈、健壮性不好、扩展性差等。由于当前可用的分布式机制[1,9～12]都不能很好地支持请求等待，所以也不能被直接应用于PoC系统。本文基于PoC会话的网络架构和特点，对TBCP进行了分布式改进，并提出了2种分布式发言权控制机制：TBCP/DQ（distributed queue）和 TBCP/MQ（mobile queue），以满足PoC乃至所有CMA业务的需要。

2 PoC会话网络架构简介

在PoC会话中，客户端表示位于用户移动终端上的PoC软件实体。文中用UE（user equipment）来代表PoC客户端。服务器表示会话中完成会话集中控制、媒体流转发控制、呼叫权控制等功能的网络实体。PoC服务器有2种工作模式，分别是控制模式（controlling mode）和参与模式（participating mode）[3～5]。服务器在控制模式下对会话进行集中控制、信令转发等操作；参与模式下则更多地是转发各种控制信令和媒体流。为讨论方便，文中定义工作在控制模式的服务器为CS（controlling server），工作在参与模式的服务器为 PS（participating server）。PoC会话可看成由PoC服务器作为上层节点SN（super node）和UE作为下层节点ON（ordinary node）的2层网络架构，如图1所示。

图1 PoC会话网络架构

3 PoC中分布式的发言权控制机制

对TBCP进行的分布式改进使得在会话过程中发言权请求队列并不始终由某一服务器来维护，而是由多个服务器共同维护（TBCP/DQ）或者按照特定的规则交替维护（TBCP/MQ）。新机制下请求队列项的格式定义如图2所示。

图2 新机制下请求等待队列项格式

UE标识是每个UE在会话中的全局唯一标识。位置标识是发言权请求在全局队列中的位置信息（取值为非负整数），从0开始递增。0表示当前用户正在发言，1表示处于第一位的等待用户，2表示处于第二位的等待用户，以此类推。时间戳是该请求被UE发出时的绝对时间标识。

3.1 基于分布式全局队列的控制机制(TBCP/DQ)

通过分布式全局队列[13]把原来位于CS处的发言权请求队列划分成若干子队列并分布到不同子网的PS处（CS可看成特殊的PS）来维护。发言权请求插入操作的算法如下。

步骤1 UE向所属PS发送请求发言权消息，该PS向其他PS转发该插入请求。

步骤2 每个PS收到别的PS发来的请求发言权消息后，将该请求同本地队列中所有请求根据其时间戳按照既定策略（先来先服务）进行逐一对比，确定本地请求在全局队列中应该排在该新请求前面的请求数目，将该数目返回给请求PS。

步骤3 当请求PS收到别的PS返回的消息后，汇同本地请求在全局队列中应该排在该请求前面的请求数目和其他各 PS中在全局队列中应该排在该请求前面的请求数目再加 1（如果当前发言权没有被占用则不用加 1）就得到该请求在全局请求队列中的位置，将位置标识记录在新请求项并插入到本地队列中。

步骤4 请求PS向请求UE返回插入位置信息。

3.2 基于可迁移全局队列的控制机制(TBCP/MQ)

可迁移全局队列是指请求队列位置随当前发言者所属子网变化而动态变化，可以随之迁移到下一发言者所属子网PS处（CS可看成特殊的PS）。发言权请求插入操作的步骤如下。

步骤1 UE向所属PS发送请求发言权消息，如果该 PS处不存在全局队列，则向全局队列所在PS转发；否则跳到下一步。

步骤2 全局队列所在PS收到插入请求后，将该请求同队列中所有请求根据其时间戳按照既定策略（先来先服务）进行逐一对比，确定该请求在全局队列中相应位置并插入队列，然后将该位置返回给请求PS（如果请求PS就是本身，则不用返回）。

步骤3 请求PS向请求UE返回插入位置信息。

4 性能评估

4.1 机制效率建模

这里采用文献[1]和文献[14]中定义的效率模型和算法，机制的效率定义如下：

其中，δ为发言权的使用时间，即UE的发言时间。W为发言权的竞争时间，即UE为了得到发言权等待的时间[14]。相关参数定义如表1所示。

表1 变量定义

参照文献[1]中方法，根据TBCP/DQ算法描述可得DQS为

根据TBCP/MQ算法描述可得MQS为

根据参数定义可知：

下面借助MATLAB仿真工具对2种新机制的效率进行分析。令δ=1，σ=0.1，γ=0.02，T=0.2，λ=5，并且n从4变化到16，得到η随n变化的曲线如图3所示。

图3 机制效率同会话中PS数目关系

通常情况下，2种机制的效率大体接近。在n取值相同的情况下，TBCP/MQ的效率略高于TBCP/DQ。随着n的增大，2种机制的效率都随之增大，但是增大的速度越来越缓慢。由于TBCP/MQ的处理方式更加接近于 TBCP，所以对请求的处理效率更高一些。TBCP/DQ则由于不同PS之间需要通过协作来实现对分布式队列的维护，处理效率则会偏低，这也是可以理解的。

令δ=1，σ=0.05，γ=0.01，n= 4，λ=2并且T从0.1增大到0.5，得到η随T变化的曲线如图4所示。随着T的增大，2种机制的效率都随之减小，而且其差值一直保持在很小的范围。由于一般情况下T可以大致表示PS之间的物理距离。PS之间传输距离的增大，导致UE等待发言权请求响应的时延增大，从而机制的效率降低，这也是不难理解的。同时可知，2个PS之间的距离远近对选择哪种发言权控制机制并没有太大的影响。

图4 机制效率同PS 之间传输时延的关系

4.2 机制效率实验

本节借助仿真工具 SIMPROCESS (Version4.3.1)[15]对实际网络中 RTP（real-time transport protocol）媒体流和 RTCP（RTP control protocol）控制信令分组共享传输信道和控制节点处理资源的情景进行了模拟。首先构建一个PoC会话，包含3个服务器，分别为PS1、PS2和PS3，每个服务器下属2个UE。当选择TBCP作为控制机制时，PS3作为 CS。服务器之间消息传输时延为 0.05s，UE到服务器之间传输时延为0.05s。每个服务器处的发言权到达率和消息处理时延服从负指数分布，且采用先来先服务策略。测试主机基本配置为：CPU Intel Pentium双核，主频2.16GHz；内存952 MB；操作系统Windows XP Professional with SP3。

4.2.1 机制效率同RTP到达率关系

将每个服务器处RTCP分组到达率设为exp(5)，CS处RTP分组到达率从exp(0.2)变化到exp(0.1)，其他2个PS处RTP分组到达率保持exp(0.2)不变。测试发言时长为300s，每隔30s变换一次发言UE所在子网。3种机制进行比较，得到如图5所示一条发言权请求的一个平均竞争周期同CS处RTP分组到达率变化的关系曲线。

图5 一个竞争周期长度同CS处RTP到达率关系

可以看出，当CS负载没有超过特定阈值（CS处RTP分到达率为8.5），3种机制下的请求等待时延基本相同，这同4.1节分析基本相符。当超过阈值后，TBCP下的时延急剧增大，TBCP/MQ次之，而TBCP/DQ基本不变。原因在于TBCP下请求队列始终由CS来维护队列并处理请求，TBCP/MQ下则每隔一段时间变换为不同服务器来处理，TBCP/DQ下则始终由3个服务器协作处理。显然当CS超载产生控制瓶颈后会依据各机制对CS的不同依赖程度影响到相应机制的效率。

4.2.2 机制效率同网络规模关系

重新构建一个PoC会话，令服务器数目从小到大变化依次为5、10、20、40，每个服务器下属10个UE。相关参数设置为：每个服务器处RTCP包到达率为 exp(5)，每个 UE发出请求的到达率为exp(100)，CS处RTP到达率为exp(0.2)，其他服务器RTP到达率为exp(10)，测试发言时长为300s，每隔 30s变换一次发言 UE所在子网，其他参数同4.2.1节。得到表2所示的3种机制下一条发言权请求的一个竞争周期同会话中服务器数目变化的关系。

表2 请求的一个周期长度同会话中服务器数目的关系

可见当网络规模不大（服务器数目小于20）时，选用何种机制并无明显差别。当网络规模较大（如表中服务器数目为40）时，TBCP由于集中式的控制方式导致CS处负载超重，请求消息的平均等待时延急剧增大。TBCP/DQ由于分布式的队列维护机制，其性能稳定性最好。TBCP/MQ由于在一定时间内是由 CS来处理新的请求，所以性能比TBCP/DQ要差一些，但是比TBCP要好。

4.3 控制信令开销

消息复杂度是指特定时间内控制消息交互的总数目[1]，可作为机制性能评价的参考指标。这里定义一个PoC会话中共有n个服务器参与，每个服务器发出请求的到达率为λ，根据各机制的控制原理可知TBCP和TBCP/MQ下每秒钟各产生λ×(n-1)条请求消息，TBCP/DQ下每秒钟产生(1)nλ×-×( 1)n- 条请求消息。可知TBCP/DQ的复杂度最大。

4.4 异常情况处理

4.4.1 单点故障对机制的影响

假设TBCP下CS处发生故障的概率为K，那么由于实验中各个服务器下 UE数目相同，每个UE发出请求的概率相同，可认为全局请求队列位于每个服务器的概率是相同的。那么TBCP/MQ下保存队列的服务器发生故障导致会话失败的概率则降低为K/n，其中，n为会话中服务器的数目。TBCP/DQ下则可采用类似文献[16]中的心跳机制来检测到故障服务器，然后通过同步消息来进行不同子队列的同步操作。具体故障恢复的时间同心跳消息发送的间隔相关并可在系统中动态配置。3种机制的健壮性按照从高到低依次为 TBCP/DQ、TBCP/MQ、TBCP。

4.4.2 消息异常对机制效率的影响

消息在传输过程中可能产生丢失或者差错。由于3种机制中都存在服务器同UE之间的消息交互，所以只需重点关注TBCP/DQ中引入的服务器之间的消息交互。当服务器每发出一条控制消息，可采用定时器超时机制来判定应答消息的丢失与否。显然，消息丢失或者错传引起的超时必然导致TBCP/DQ机制效率的降低。

5 结束语

本文对OMA的集中式发言权控制机制TBCP进行了改进，提出了TBCP/DQ和TBCP/MQ 2种分布式控制机制。通过理论分析以及仿真对比可知，新机制能够很好地被应用到PoC中。

[1] BANIK S M, RADHAKRISHNAN S, SARANGAN V,et al. Implementation of distributed floor control protocols on overlay networks[J].IEEE Transactions on Parallel and Distributed Systems, 2008,19(8):1057-1070.

[2] 刘海鹏，廖建新，朱晓民. PoC中一种负载均衡与时延优化的RTP媒体流转发机制[J]. 通信学报, 2010, 31(8): 105-113.LIU H P, LIAO J X, ZHU X M. RTP stream transferring scheme with load balancing and delay optimization in PoC[J]. Journal on Communications, 2010, 31(8):105-113.

[3] Open Mobile Alliance. OMA-AD-PoC-V2_1-20090224-D: Push to Talk Over Cellular (PoC)-Architecture[S]. 2009.

[4] Open Mobile Alliance. OMA-TS-PoC_System_Description-V2_1-20090305-D: OMA PoC System Description[S]. Open Mobile Alliance, 2009.

[5] Open Mobile Alliance. OMA-TS-PoC_UserPlane-V2_1-20090211-D:PoC User Plane[S]. 2009.

[6] CAMARILLO G,et al. The Binary Floor control Protocol (BFCP).RFC4582[S]. 2006.

[7] BORMANN C, OTT J, REICHERT C. SCCP: Simple Conference Control Protocol, Internet Draft Draft-Ietf-Mmusic-Sccp-01[S]. 2001.

[8] HANDLEY M, WAKEMAN I, CROWCROFT J. The conference control channel protocol (CCCP): a scalable base for building conference control applications[A]. Proceedings of ACM SIGCOMM 95[C].1995.275-287.

[9] KATRINIS K, PARISSIDIS G, PLATTNER B. Activity sensing floor control in multimedia collaborative applications[A]. The 10th International Conference on Distributed Multimedia Systems(DMS)[C]. 2004.

[10] LIN J R, PANG A C, WANG Y C. iPTT: peer-to-peer push-to-talk for VoIP[J]. Wireless Communications and Mobile Computing, 2008,8(10):1331-1343.

[11] RONNHOLM V. Push-to-talk over Bluetooth[A]. Proceedings of the 39th Hawaii International Conference on System Sciences-2006[C].2006.232-241.

[12] GAN C H, LIN Y B. Push-to-talk service for intelligent transportation systems[J]. IEEE Transactions on Intelligent Transportation Systems,2007, 8(3):391-399.

[13] TIRTHAPURA S. Distributed Queuing and Applications[D]. Brown University, 2002.

[14] DOMMEL H P, GARCIA J J. Efficacy of floor control protocols in distributed multimedia environment[J]. Cluster Computing, 1999,2(1):17-33.

[15] SIMPROCESS simulator[EB/OL]. http://simprocess.com.

[16] FU C Y, GLITHO R H, KHENDEK F. Signaling for multimedia conferencing in stand-alone mobile ad hoc networks[J]. IEEE Transactions on Mobile Computing, 2009, 8(7):991-1005.