PoC中發(fā)言權(quán)控制機(jī)制的分布式改進(jìn)

劉海鵬，廖建新，朱曉民

(1. 北京郵電大學(xué) 網(wǎng)絡(luò)與交換技術(shù)國(guó)家重點(diǎn)實(shí)驗(yàn)室，北京 100876；2. 東信北郵信息技術(shù)有限公司，北京 100191)

1 引言

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

2 PoC會(huì)話(huà)網(wǎng)絡(luò)架構(gòu)簡(jiǎn)介

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

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

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

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

圖2 新機(jī)制下請(qǐng)求等待隊(duì)列項(xiàng)格式

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

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

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

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

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

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

步驟4 請(qǐng)求PS向請(qǐng)求UE返回插入位置信息。

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

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

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

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

步驟3 請(qǐng)求PS向請(qǐng)求UE返回插入位置信息。

4 性能評(píng)估

4.1 機(jī)制效率建模

這里采用文獻(xiàn)[1]和文獻(xiàn)[14]中定義的效率模型和算法，機(jī)制的效率定義如下：

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

表1 變量定義

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

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

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

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

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

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

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

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

4.2 機(jī)制效率實(shí)驗(yàn)

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

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

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

圖5 一個(gè)競(jìng)爭(zhēng)周期長(zhǎng)度同CS處RTP到達(dá)率關(guān)系

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

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

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

表2 請(qǐng)求的一個(gè)周期長(zhǎng)度同會(huì)話(huà)中服務(wù)器數(shù)目的關(guān)系

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

4.3 控制信令開(kāi)銷(xiāo)

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

4.4 異常情況處理

4.4.1 單點(diǎn)故障對(duì)機(jī)制的影響

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

4.4.2 消息異常對(duì)機(jī)制效率的影響

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

5 結(jié)束語(yǔ)

本文對(duì)OMA的集中式發(fā)言權(quán)控制機(jī)制TBCP進(jìn)行了改進(jìn)，提出了TBCP/DQ和TBCP/MQ 2種分布式控制機(jī)制。通過(guò)理論分析以及仿真對(duì)比可知，新機(jī)制能夠很好地被應(yīng)用到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中一種負(fù)載均衡與時(shí)延優(yōu)化的RTP媒體流轉(zhuǎn)發(fā)機(jī)制[J]. 通信學(xué)報(bào), 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.