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.