劉海鵬，廖建新，朱曉民

(1. 北京郵電大學 網(wǎng)絡與交換技術(shù)國家重點實驗室，北京 100876；2. 東信北郵信息技術(shù)有限公司，北京 100191)

1 引言

隨著重疊網(wǎng)絡(overlay network)技術(shù)以及協(xié)作式多媒體應用(CMA, collaborative multimedia applications)[1]類業(yè)務的快速發(fā)展，基于IMS (IP multimedia subsystem)平臺的 PoC (push to talk over cellular)業(yè)務日益引起業(yè)界的廣泛關(guān)注[2]。半雙工是PoC的基本業(yè)務屬性之一，在會話中任意時刻，最多只允許有一個用戶發(fā)言，其他用戶處于接聽狀態(tài)。有發(fā)言需求的用戶通過按鍵來競爭會話中唯一的一個發(fā)言權(quán)。OMA (open mobile alliance) 為PoC定義了一套基于集中式控制思想的發(fā)言權(quán)控制機制 TBCP (talk burst control protocol)[3～5]。其具有集中式機制[6～8]固有的缺點：中心節(jié)點維護成本高、容易產(chǎn)生控制瓶頸、健壯性不好、擴展性差等。由于當前可用的分布式機制[1,9～12]都不能很好地支持請求等待，所以也不能被直接應用于PoC系統(tǒng)。本文基于PoC會話的網(wǎng)絡架構(gòu)和特點，對TBCP進行了分布式改進，并提出了2種分布式發(fā)言權(quán)控制機制：TBCP/DQ（distributed queue）和 TBCP/MQ（mobile queue），以滿足PoC乃至所有CMA業(yè)務的需要。

2 PoC會話網(wǎng)絡架構(gòu)簡介

在PoC會話中，客戶端表示位于用戶移動終端上的PoC軟件實體。文中用UE（user equipment）來代表PoC客戶端。服務器表示會話中完成會話集中控制、媒體流轉(zhuǎn)發(fā)控制、呼叫權(quán)控制等功能的網(wǎng)絡實體。PoC服務器有2種工作模式，分別是控制模式（controlling mode）和參與模式（participating mode）[3～5]。服務器在控制模式下對會話進行集中控制、信令轉(zhuǎn)發(fā)等操作；參與模式下則更多地是轉(zhuǎn)發(fā)各種控制信令和媒體流。為討論方便，文中定義工作在控制模式的服務器為CS（controlling server），工作在參與模式的服務器為 PS（participating server）。PoC會話可看成由PoC服務器作為上層節(jié)點SN（super node）和UE作為下層節(jié)點ON（ordinary node）的2層網(wǎng)絡架構(gòu)，如圖1所示。

圖1 PoC會話網(wǎng)絡架構(gòu)

3 PoC中分布式的發(fā)言權(quán)控制機制

對TBCP進行的分布式改進使得在會話過程中發(fā)言權(quán)請求隊列并不始終由某一服務器來維護，而是由多個服務器共同維護（TBCP/DQ）或者按照特定的規(guī)則交替維護（TBCP/MQ）。新機制下請求隊列項的格式定義如圖2所示。

圖2 新機制下請求等待隊列項格式

UE標識是每個UE在會話中的全局唯一標識。位置標識是發(fā)言權(quán)請求在全局隊列中的位置信息（取值為非負整數(shù)），從0開始遞增。0表示當前用戶正在發(fā)言，1表示處于第一位的等待用戶，2表示處于第二位的等待用戶，以此類推。時間戳是該請求被UE發(fā)出時的絕對時間標識。

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

通過分布式全局隊列[13]把原來位于CS處的發(fā)言權(quán)請求隊列劃分成若干子隊列并分布到不同子網(wǎng)的PS處（CS可看成特殊的PS）來維護。發(fā)言權(quán)請求插入操作的算法如下。

步驟1 UE向所屬PS發(fā)送請求發(fā)言權(quán)消息，該PS向其他PS轉(zhuǎn)發(fā)該插入請求。

步驟2 每個PS收到別的PS發(fā)來的請求發(fā)言權(quán)消息后，將該請求同本地隊列中所有請求根據(jù)其時間戳按照既定策略（先來先服務）進行逐一對比，確定本地請求在全局隊列中應該排在該新請求前面的請求數(shù)目，將該數(shù)目返回給請求PS。

步驟3 當請求PS收到別的PS返回的消息后，匯同本地請求在全局隊列中應該排在該請求前面的請求數(shù)目和其他各 PS中在全局隊列中應該排在該請求前面的請求數(shù)目再加 1（如果當前發(fā)言權(quán)沒有被占用則不用加 1）就得到該請求在全局請求隊列中的位置，將位置標識記錄在新請求項并插入到本地隊列中。

步驟4 請求PS向請求UE返回插入位置信息。

3.2 基于可遷移全局隊列的控制機制(TBCP/MQ)

可遷移全局隊列是指請求隊列位置隨當前發(fā)言者所屬子網(wǎng)變化而動態(tài)變化，可以隨之遷移到下一發(fā)言者所屬子網(wǎng)PS處（CS可看成特殊的PS）。發(fā)言權(quán)請求插入操作的步驟如下。

步驟1 UE向所屬PS發(fā)送請求發(fā)言權(quán)消息，如果該 PS處不存在全局隊列，則向全局隊列所在PS轉(zhuǎn)發(fā)；否則跳到下一步。

步驟2 全局隊列所在PS收到插入請求后，將該請求同隊列中所有請求根據(jù)其時間戳按照既定策略（先來先服務）進行逐一對比，確定該請求在全局隊列中相應位置并插入隊列，然后將該位置返回給請求PS（如果請求PS就是本身，則不用返回）。

步驟3 請求PS向請求UE返回插入位置信息。

4 性能評估

4.1 機制效率建模

這里采用文獻[1]和文獻[14]中定義的效率模型和算法，機制的效率定義如下：

其中，δ為發(fā)言權(quán)的使用時間，即UE的發(fā)言時間。W為發(fā)言權(quán)的競爭時間，即UE為了得到發(fā)言權(quán)等待的時間[14]。相關(guān)參數(shù)定義如表1所示。

表1 變量定義

參照文獻[1]中方法，根據(jù)TBCP/DQ算法描述可得DQS為

根據(jù)TBCP/MQ算法描述可得MQS為

根據(jù)參數(shù)定義可知：

下面借助MATLAB仿真工具對2種新機制的效率進行分析。令δ=1，σ=0.1，γ=0.02，T=0.2，λ=5，并且n從4變化到16，得到η隨n變化的曲線如圖3所示。

圖3 機制效率同會話中PS數(shù)目關(guān)系

通常情況下，2種機制的效率大體接近。在n取值相同的情況下，TBCP/MQ的效率略高于TBCP/DQ。隨著n的增大，2種機制的效率都隨之增大，但是增大的速度越來越緩慢。由于TBCP/MQ的處理方式更加接近于 TBCP，所以對請求的處理效率更高一些。TBCP/DQ則由于不同PS之間需要通過協(xié)作來實現(xiàn)對分布式隊列的維護，處理效率則會偏低，這也是可以理解的。

令δ=1，σ=0.05，γ=0.01，n= 4，λ=2并且T從0.1增大到0.5，得到η隨T變化的曲線如圖4所示。隨著T的增大，2種機制的效率都隨之減小，而且其差值一直保持在很小的范圍。由于一般情況下T可以大致表示PS之間的物理距離。PS之間傳輸距離的增大，導致UE等待發(fā)言權(quán)請求響應的時延增大，從而機制的效率降低，這也是不難理解的。同時可知，2個PS之間的距離遠近對選擇哪種發(fā)言權(quán)控制機制并沒有太大的影響。

圖4 機制效率同PS 之間傳輸時延的關(guān)系

4.2 機制效率實驗

本節(jié)借助仿真工具 SIMPROCESS (Version4.3.1)[15]對實際網(wǎng)絡中 RTP（real-time transport protocol）媒體流和 RTCP（RTP control protocol）控制信令分組共享傳輸信道和控制節(jié)點處理資源的情景進行了模擬。首先構(gòu)建一個PoC會話，包含3個服務器，分別為PS1、PS2和PS3，每個服務器下屬2個UE。當選擇TBCP作為控制機制時，PS3作為 CS。服務器之間消息傳輸時延為 0.05s，UE到服務器之間傳輸時延為0.05s。每個服務器處的發(fā)言權(quán)到達率和消息處理時延服從負指數(shù)分布，且采用先來先服務策略。測試主機基本配置為：CPU Intel Pentium雙核，主頻2.16GHz；內(nèi)存952 MB；操作系統(tǒng)Windows XP Professional with SP3。

4.2.1 機制效率同RTP到達率關(guān)系

將每個服務器處RTCP分組到達率設(shè)為exp(5)，CS處RTP分組到達率從exp(0.2)變化到exp(0.1)，其他2個PS處RTP分組到達率保持exp(0.2)不變。測試發(fā)言時長為300s，每隔30s變換一次發(fā)言UE所在子網(wǎng)。3種機制進行比較，得到如圖5所示一條發(fā)言權(quán)請求的一個平均競爭周期同CS處RTP分組到達率變化的關(guān)系曲線。

圖5 一個競爭周期長度同CS處RTP到達率關(guān)系

可以看出，當CS負載沒有超過特定閾值（CS處RTP分到達率為8.5），3種機制下的請求等待時延基本相同，這同4.1節(jié)分析基本相符。當超過閾值后，TBCP下的時延急劇增大，TBCP/MQ次之，而TBCP/DQ基本不變。原因在于TBCP下請求隊列始終由CS來維護隊列并處理請求，TBCP/MQ下則每隔一段時間變換為不同服務器來處理，TBCP/DQ下則始終由3個服務器協(xié)作處理。顯然當CS超載產(chǎn)生控制瓶頸后會依據(jù)各機制對CS的不同依賴程度影響到相應機制的效率。

4.2.2 機制效率同網(wǎng)絡規(guī)模關(guān)系

重新構(gòu)建一個PoC會話，令服務器數(shù)目從小到大變化依次為5、10、20、40，每個服務器下屬10個UE。相關(guān)參數(shù)設(shè)置為：每個服務器處RTCP包到達率為 exp(5)，每個 UE發(fā)出請求的到達率為exp(100)，CS處RTP到達率為exp(0.2)，其他服務器RTP到達率為exp(10)，測試發(fā)言時長為300s，每隔 30s變換一次發(fā)言 UE所在子網(wǎng)，其他參數(shù)同4.2.1節(jié)。得到表2所示的3種機制下一條發(fā)言權(quán)請求的一個競爭周期同會話中服務器數(shù)目變化的關(guān)系。

表2 請求的一個周期長度同會話中服務器數(shù)目的關(guān)系

可見當網(wǎng)絡規(guī)模不大（服務器數(shù)目小于20）時，選用何種機制并無明顯差別。當網(wǎng)絡規(guī)模較大（如表中服務器數(shù)目為40）時，TBCP由于集中式的控制方式導致CS處負載超重，請求消息的平均等待時延急劇增大。TBCP/DQ由于分布式的隊列維護機制，其性能穩(wěn)定性最好。TBCP/MQ由于在一定時間內(nèi)是由 CS來處理新的請求，所以性能比TBCP/DQ要差一些，但是比TBCP要好。

4.3 控制信令開銷

消息復雜度是指特定時間內(nèi)控制消息交互的總數(shù)目[1]，可作為機制性能評價的參考指標。這里定義一個PoC會話中共有n個服務器參與，每個服務器發(fā)出請求的到達率為λ，根據(jù)各機制的控制原理可知TBCP和TBCP/MQ下每秒鐘各產(chǎn)生λ×(n-1)條請求消息，TBCP/DQ下每秒鐘產(chǎn)生(1)nλ×-×( 1)n- 條請求消息?？芍猅BCP/DQ的復雜度最大。

4.4 異常情況處理

4.4.1 單點故障對機制的影響

假設(shè)TBCP下CS處發(fā)生故障的概率為K，那么由于實驗中各個服務器下 UE數(shù)目相同，每個UE發(fā)出請求的概率相同，可認為全局請求隊列位于每個服務器的概率是相同的。那么TBCP/MQ下保存隊列的服務器發(fā)生故障導致會話失敗的概率則降低為K/n，其中，n為會話中服務器的數(shù)目。TBCP/DQ下則可采用類似文獻[16]中的心跳機制來檢測到故障服務器，然后通過同步消息來進行不同子隊列的同步操作。具體故障恢復的時間同心跳消息發(fā)送的間隔相關(guān)并可在系統(tǒng)中動態(tài)配置。3種機制的健壯性按照從高到低依次為 TBCP/DQ、TBCP/MQ、TBCP。

4.4.2 消息異常對機制效率的影響

消息在傳輸過程中可能產(chǎn)生丟失或者差錯。由于3種機制中都存在服務器同UE之間的消息交互，所以只需重點關(guān)注TBCP/DQ中引入的服務器之間的消息交互。當服務器每發(fā)出一條控制消息，可采用定時器超時機制來判定應答消息的丟失與否。顯然，消息丟失或者錯傳引起的超時必然導致TBCP/DQ機制效率的降低。

5 結(jié)束語

本文對OMA的集中式發(fā)言權(quán)控制機制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中一種負載均衡與時延優(yōu)化的RTP媒體流轉(zhuǎn)發(fā)機制[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.