陳 園

（中國電信股份有限公司廣東研究院 廣州 510630）

1 引言

集群通信系統(tǒng)，是指由多個用戶共用一組無線信道并動態(tài)地使用這些信道的移動通信系統(tǒng)。集群通信系統(tǒng)主要用于調(diào)度通信，它包括模擬集群通信系統(tǒng)和數(shù)字集群通信系統(tǒng)。從20世紀60年代到現(xiàn)在，集群通信從模擬系統(tǒng)發(fā)展到數(shù)字系統(tǒng)，并在公共事業(yè)、應(yīng)急通信、交通、物流等多個行業(yè)得到了廣泛應(yīng)用。

雖然市場需求依然迫切，但當(dāng)前從國內(nèi)和國際集群通信系統(tǒng)的發(fā)展來看，集群通信系統(tǒng)的發(fā)展遠遠落后于公共蜂窩寬帶接入網(wǎng)的發(fā)展。其原因既有產(chǎn)業(yè)鏈較為薄弱，也包括數(shù)據(jù)傳輸能力和多媒體支持能力弱的因素，同時政府對于頻率資源的管制趨嚴也間接限制了集群通信系統(tǒng)的發(fā)展。

隨著蜂窩寬帶接入技術(shù)的飛速發(fā)展，LTE已經(jīng)能夠提供下行為100 Mbit/s、上行為50 Mbit/s的峰值速率，借助LTE技術(shù)，集群通信將迎來寬帶化的的最好契機。在此背景下，本文首先對寬帶集群系統(tǒng)演進的技術(shù)路線進行了分析，指出了集群通信系統(tǒng)與LTE融合將是發(fā)展趨勢，隨后對LTE網(wǎng)絡(luò)下寬帶集群通信系統(tǒng)涉及的一系列關(guān)鍵技術(shù)進行了研究和分析。

2 寬帶集群通信系統(tǒng)技術(shù)演進路線探討

2.1 集群系統(tǒng)發(fā)展歷程

圖1給出了集群通信系統(tǒng)的發(fā)展歷程以及各階段集群通信系統(tǒng)的典型特征。

當(dāng)前集群系統(tǒng)正經(jīng)歷由窄帶數(shù)字集群系統(tǒng)向?qū)拵Ъ合到y(tǒng)的演進，寬帶集群通信系統(tǒng)應(yīng)可支持“話音+視頻”的單呼、組呼等調(diào)度方式[1]，并具備較強的數(shù)據(jù)傳輸能力，能夠?qū)崿F(xiàn)文件共享、網(wǎng)絡(luò)瀏覽、圖像回傳、視頻會議、視頻監(jiān)控等功能。同時系統(tǒng)性能應(yīng)得到提升：支持大話務(wù)量能力，呼叫建立時間降低。

2.2 寬帶集群系統(tǒng)技術(shù)演進路徑

從蜂窩寬帶接入技術(shù)及集群通信系統(tǒng)的發(fā)展歷程來看，集群系統(tǒng)由窄帶系統(tǒng)向?qū)拵到y(tǒng)演進共有3種路徑。

·路徑1：蜂窩寬帶接入網(wǎng)絡(luò)上疊加集群應(yīng)用，即集群通信系統(tǒng)借助蜂窩寬帶接入網(wǎng)絡(luò)的網(wǎng)絡(luò)能力，實現(xiàn)集群系統(tǒng)的寬帶化，在2G/3G時代，典型的例子就是 QChat。

·路徑2：通過對蜂窩寬帶接入網(wǎng)絡(luò)增強實現(xiàn)集群功能，即對蜂窩寬帶接入網(wǎng)絡(luò)根據(jù)集群通信的業(yè)務(wù)特征進行改造升級支持集群業(yè)務(wù)，在2G/3G時代，典型的例子是GOTA。

·路徑3：集群系統(tǒng)自身的升級換代，即對原有的集群通信系統(tǒng)進行升級，支持寬帶業(yè)務(wù)。目前業(yè)界在集群系統(tǒng)增強方面也有一些案例，如Tetra2系統(tǒng)，但由于集群系統(tǒng)產(chǎn)業(yè)鏈較弱，相關(guān)標準發(fā)展相對滯后。

2.3 寬帶集群系統(tǒng)技術(shù)演進路徑比較

表1從組網(wǎng)方式、數(shù)據(jù)傳輸能力、建網(wǎng)模式、產(chǎn)業(yè)鏈支持程度、組網(wǎng)成本的角度出發(fā)，對3種演進方式做了比較。

表1 3種演進路徑對比

通過表1的分析，結(jié)合集群通信發(fā)展的現(xiàn)狀發(fā)現(xiàn)，路徑3在產(chǎn)業(yè)鏈的支持方面較弱，同時數(shù)據(jù)傳輸能力方面尚不能滿足寬帶集群系統(tǒng)的要求；路徑2在產(chǎn)業(yè)鏈支持力度上較弱，對網(wǎng)絡(luò)標準改動大，不同設(shè)備廠商間互通難度非常大；而路徑1將蜂窩寬帶接入網(wǎng)絡(luò)與集群通信相融合，可借助蜂窩寬帶接入網(wǎng)絡(luò)的高數(shù)據(jù)傳輸能力，對網(wǎng)絡(luò)標準改動小，能夠獲得較強的產(chǎn)業(yè)鏈支持。另外由于依托于蜂窩寬帶接入網(wǎng)絡(luò)，既可采用專網(wǎng)的組網(wǎng)方式，向?qū)I(yè)性要求較高的客戶提供服務(wù)；也可采用公網(wǎng)的組網(wǎng)方式，向公眾及對專業(yè)性要求一般的客戶提供基礎(chǔ)集群服務(wù)。隨著LTE技術(shù)的逐步商用，可以預(yù)見，路徑1——將LTE網(wǎng)絡(luò)與集群通信相疊加，是寬帶集群系統(tǒng)演進的趨勢。以下將對采用疊加方式的基于LTE的寬帶集群系統(tǒng)涉及的關(guān)鍵技術(shù)進行分析和探討。

3 采用疊加方式的LTE寬帶集群系統(tǒng)關(guān)鍵技術(shù)及應(yīng)用建議

對于路徑1，目前業(yè)界較為常見的方式是將基于VoIP的類PoC應(yīng)用疊加在蜂窩寬帶接入網(wǎng)分組域上，這種方式的優(yōu)勢是組網(wǎng)成本低，同時易于與其他基于分組域的視頻、數(shù)據(jù)類業(yè)務(wù)進行融合。以中國電信QChat制式為例，當(dāng)前QChat制式是疊加在Ev-Do Rev.A網(wǎng)絡(luò)上的VoIP應(yīng)用，通過一系列的網(wǎng)絡(luò)優(yōu)化措施，系統(tǒng)性能能夠滿足集群通信系統(tǒng)的要求。以下將說明在LTE網(wǎng)絡(luò)下，該方式涉及的關(guān)鍵技術(shù)及其應(yīng)用建議。

3.1 LTE寬帶集群系統(tǒng)呼叫時延分析及優(yōu)化建議

3.1.1 呼叫時延構(gòu)成

在LTE網(wǎng)絡(luò)中，集群呼叫時延主要由以下部分構(gòu)成。

·TItoC：終端從 idle轉(zhuǎn)為 connected的時延（包括主被叫）。

·Tb：空口建立時延（包括主被叫）。

·Tp：平均尋呼時延。這部分時延主要取決于DRX尋呼周期，尋呼周期越小，被叫的尋呼時延越小。

·終端的處理時延：包括主被叫（定義為Tu）以及SIP信令的傳輸及處理時延（定義為Ts）。

3.1.2 呼叫時延優(yōu)化建議及估算

LTE網(wǎng)絡(luò)中集群呼叫時延優(yōu)化建議如下。

·TItoC、Tb由LTE技術(shù)體制決定，以FDD為例，TItoC約為35 ms[2],與2G/3G網(wǎng)絡(luò)相比，LTE網(wǎng)絡(luò)中TItoC已經(jīng)大大縮短；Tb約為60 ms[2]。這兩部分由LTE技術(shù)體制決定?？紤]到投入/產(chǎn)出比，不建議進一步采取優(yōu)化措施。

·Tp優(yōu)化的主要措施是在保證終端續(xù)航能力的前提下，設(shè)置合理的尋呼周期。為獲得最小尋呼時延，同時考慮到終端的續(xù)航能力問題，可將集群終端尋呼周期設(shè)置為320 ms,Tp=160 ms。

·Ts、Tu這兩部分時延受終端性能、網(wǎng)絡(luò)性能影響較大，因此這兩部分時延需要通過提升網(wǎng)絡(luò)傳輸質(zhì)量以及終端性能實現(xiàn)。一般來說，根據(jù)經(jīng)驗值Ts=200 ms,Tu=100 ms。

因此可得到總體時延=TItoC×2+Tb×2+Tp+Tu×2+Ts=750 ms。能夠基本滿足專業(yè)集群客戶的要求，同時如果運營商提高網(wǎng)絡(luò)質(zhì)量，強化終端性能，時延還將進一步縮小。

3.2 LTE寬帶集群系統(tǒng)容量分析及容量提升方案建議

3.2.1 系統(tǒng)容量

LTE中集群通信系統(tǒng)容量可參考VoIP業(yè)務(wù)，表2給出FDD-LTE系統(tǒng)VoIP業(yè)務(wù)的容量[2]。

表2 FDD-LTE系統(tǒng)VoIP業(yè)務(wù)容量

可以看出，雖然LTE相對于3G網(wǎng)絡(luò)在系統(tǒng)容量上有了較大提升（以QChat為例，單載扇承載約40個用戶），但對于小范圍區(qū)域內(nèi)集中了大量用戶的情形（如重大賽事調(diào)度任務(wù)），容量仍顯不足。

3.2.2 系統(tǒng)容量提升方案

集群業(yè)務(wù)的特征是半雙工，對于群組呼叫而言，同一時間只有一部終端有上行數(shù)據(jù)，其他所有終端均為下行數(shù)據(jù)，因此多播技術(shù)特別適用于解決小范圍區(qū)域內(nèi)集中了大量用戶的容量問題，圖2給出了基于EMBMS和LTE的寬帶集群通信系統(tǒng)架構(gòu)[3]。

在大群組組呼的情況下，對于上行數(shù)據(jù)（講話，獲取話權(quán)）采用單播，對于下行數(shù)據(jù)采用多播技術(shù)?；贓MBMS和LTE的寬帶集群通信系統(tǒng)可重用EPC網(wǎng)元，同時需對相應(yīng)網(wǎng)元在標準EMBMS的基礎(chǔ)上，針對集群業(yè)務(wù)做一定增強，主要要求如下。

·PDN GW：能夠根據(jù)業(yè)務(wù)類型區(qū)分是多播業(yè)務(wù)還是單播業(yè)務(wù)，以決定數(shù)據(jù)流向（SGW或BM-SC）。

·BM-SC：需要為每個多播群組配置多播的區(qū)域，即多播涉及的eNode B，該區(qū)域可以靜態(tài)配置，也可以根據(jù)終端附著的情況動態(tài)生成。在實際應(yīng)用中，由于動態(tài)多播會造成無線資源的浪費，從投入/產(chǎn)出比的角度考慮，建議使用靜態(tài)配置。

·MME：需要獲得終端的簽約信息以及終端所屬的集群業(yè)務(wù)群組信息。這些信息可以通過HSS增強獲得，也可以向集群應(yīng)用獲得。

表3 基于LTE的集群通信系統(tǒng)QCI建議

·eNode B：支持MBSFN傳輸，可以通過優(yōu)化MBMS控制信道的修改周期和重復(fù)周期改進集群通信系統(tǒng)性能。

基于集群通信業(yè)務(wù)的特性，通過引入多播技術(shù)，能夠大大提升系統(tǒng)容量 （理論上無窮大）。但在實際部署過程中，為避免網(wǎng)絡(luò)資源的浪費，建議可針對特殊場景的需求（如大型集會的通信保障）單獨配置固定多播區(qū)域和群組。

3.3 QoS保障機制在LTE寬帶集群系統(tǒng)中的應(yīng)用建議

3.3.1 QoS參數(shù)選擇建議

EPC系統(tǒng)中，不同的QoS等級需要不同類型的承載來提供。其中QCI是最重要的QoS參數(shù)。QCI是一個QoS級別的標號，它同時應(yīng)用于GBR和Non-GBR承載，用于指定訪問節(jié)點內(nèi)定義的控制承載級分組轉(zhuǎn)發(fā)方式 (如調(diào)度權(quán)重、接納門限、隊列管理門限、鏈路層協(xié)議配置等)，這些都由運營商預(yù)先配置到接入網(wǎng)節(jié)點中[4]。在接口上使用QCI而不是傳輸一組QoS參數(shù)，主要是為了減少接口上的控制信令數(shù)據(jù)傳輸量，并且在多廠商互連環(huán)境和漫游環(huán)境中使得不同設(shè)備/系統(tǒng)間的互連互通更加容易。

對于基于LTE網(wǎng)絡(luò)承載的集群業(yè)務(wù)，建議使用表3所示的 QCI。

3.3.2 網(wǎng)絡(luò)側(cè)發(fā)起的專用承載建立

在2G/3G網(wǎng)絡(luò)中，業(yè)務(wù)的QoS資源申請往往由終端發(fā)起，存在QoS資源被盜用的風(fēng)險。而在LTE網(wǎng)絡(luò)中，結(jié)合PCC架構(gòu)，可實現(xiàn)網(wǎng)絡(luò)側(cè)發(fā)起專用承載，如圖3所示。使用該特性，便于運營商的QoS策略管控與調(diào)整以及減少客戶端開發(fā)的難度。

4 結(jié)束語

集群通信系統(tǒng)在公共事業(yè)、物流、交通等領(lǐng)域有著廣泛的應(yīng)用，但由于產(chǎn)業(yè)鏈薄弱，政府頻率管制等原因，造成了集群通信系統(tǒng)發(fā)展遠遠滯后于蜂窩寬帶接入網(wǎng)絡(luò)。當(dāng)前集群系統(tǒng)正經(jīng)歷由窄帶數(shù)字集群系統(tǒng)向?qū)拵Ъ合到y(tǒng)的演進，本文在對3種演進路徑進行分析的基礎(chǔ)上，指出與LTE網(wǎng)絡(luò)疊加將是寬帶集群通信系統(tǒng)的最佳演進路線，并給出了該演進路線涉及的關(guān)鍵技術(shù)以及應(yīng)用建議，包括呼叫時延的分析和優(yōu)化建議、系統(tǒng)容量分析及容量提升方案建議以及QoS保障機制在LTE寬帶集群系統(tǒng)中的應(yīng)用建議。隨著LTE的逐步成熟和商用，集群通信系統(tǒng)也將借助LTE網(wǎng)絡(luò)強大的數(shù)據(jù)傳輸能力實現(xiàn)向?qū)拵Щ?、IP化的演進，從而為用戶提供更為快捷、可靠、豐富的集群通信業(yè)務(wù)。

1 CCSA SR 122-2012.基于TD-LTE的寬帶數(shù)字集群通信系統(tǒng)的研究,2012

2 3GPP TR 36.912.Feasibility Study for Further Advancements for E-UTRA(LTE-Advanced),2011

3 3GPP TS 36.440.General Aspects and Principles for Interfaces SupportingMultimediaBroadcastMulticastService(MBMS)Within E-UTRAN,2012

4 3GPP TS 23.203.Policy and Charging Control Architecture,2011