移動網絡中流媒體業務適配承載帶寬的解決方案研究

王勇強

（中國移動通信集團上海有限公司 上海200060）

1 引言

當今網絡技術高速發展，特別是有線寬帶和互聯網技術的廣泛應用，使得流媒體業務能在廣域網上開展服務。基于流媒體技術可以提供電視/電臺直播、影視/音樂點播、音頻/視頻分享等業務。目前提供流媒體業務的熱門網站應用有YouTube、優酷、迅雷看看等，這些流媒體業務極大地豐富了人們的生活，并改變著人們娛樂、學習和交流的方式。

近年來，移動通信技術得到了飛速的發展和普及，其與互聯網技術的結合，誕生了移動互聯網。現在移動網絡的無線信道帶寬已足以承載輕量級的流媒體業務，而移動終端隨身攜帶的特點也更方便地為現代人提供快餐文化，因此YouTube、優酷等有線寬帶互聯網上的流媒體業務也就自然地遷移到了移動互聯網上。據國內某家移動運營商2011年6月統計，現網流媒體業務所產生的流量已占所有數據流量的5%，流媒體業務已經成為推動移動網絡發展的不可忽視的一股新生力量。

然而，由于移動終端用戶位置的不確定性，帶來了無線信道環境的復雜性（如：信號傳播路徑變化、阻擋情況變化、干擾情況變化）。移動網絡需要根據無線信道服務質量的變化情況，相應地改變無線信道的承載速率，以控制所傳輸業務的服務質量，從而達到有效利用移動網絡資源的目的。移動網絡的這個特點意味著它無法像有線網絡一樣保持用戶接入側穩定的信道帶寬（若兩者在網絡側都采用有線傳輸方式，業務信道穩定程度相同）。

流媒體業務采用一定的編碼速率進行業務編碼，如果業務使用過程中，無線信道的帶寬發生變化，則無法保證業務編碼速率與信道帶寬匹配。如果將高編碼速率的業務內容發送給低帶寬的網絡，就會造成業務播放時的停頓現象，從而影響用戶的業務感受；而將低編碼速率的業務發送給高帶寬的網絡，就不能充分利用網絡資源提升用戶業務感受，造成浪費。流媒體業務采用的緩存技術，可以一定程度上平滑網絡的時延和抖動，但不能較好地應對移動網絡中信道帶寬的等級變化，而信道帶寬等級變化在3G移動網絡中是常見，如PS 128 kbit/s降級為PS 64 kbit/s。

目前的標準和技術都無法確保移動網絡用戶在一次業務會話中獲取穩定的信道帶寬，也不能讓流媒體業務平臺及時、準確地知曉移動網絡的信道帶寬。本文在研究流媒體的業務特征和相關通信標準之后，提出了一種新的解決方案。

2 現有技術分析

流媒體業務（packet-switched streaming service,PSS）是指把連續的影像和聲音信息經過壓縮處理后放到網絡服務器上，使用戶終端可以邊下載邊播放。流媒體業務的關鍵技術是流傳輸技術，即首先對影像和聲音進行傳輸壓縮編碼，經過幾秒到幾十秒的緩存即可在用戶終端開始播放；后續的影像和聲音將由用戶終端繼續在后臺下載到緩存中，并保證影像和聲音的時序性和準確性。

流媒體業務傳輸協議根據IETFRFC3550、RFC2326的定義，主要有實時傳輸協議 （real-time transport protocol,RTP）、實時傳輸控制協議（real-time transport control protocol,RTCP）、實時流協議（real-timestreaming protocol,RTSP）。

RTP協議負責流媒體內容的傳輸。

RTCP協議負責反饋RTP會話質量并傳遞RTP同步時間戳。為了反饋RTP會話質量，RTCP協議中定義了周期性發送的報文SR（sender report）和RR（receiver report）。SR中 包 含 了sender’s octet count、sender’s packet count、fraction lost等字段，字段說明參見表1。

表1 SR字段說明

RR中包含了fraction lost、cumulative number of packets lost、interarrival jitter、last SR和delay since last SR字段，定義和SR中相同。RR包的接收方可以結合last SR和delay since last SR用于估算包傳輸時延。

RTSP協議負責流媒體播放的控制，如播放、暫停、快進、快退等。在RTSP協議中定義了bandwidth頭消息，bandwidth用于說明發送方估計的網絡帶寬。bandwidth可以作為請求頭消息應用于RTSP所有的方法中 （如：describe、setup、set_parameter等），協議規定接受 方對于bandwidth頭消息的支持是可選的。

3GPP根據移動網絡的特點在TS26.234規范中對RTSP協議進行了補充，在setup、play、options和set_parameter方法的請求消息中可以增加3GPP-Link-Char頭消息，3GPP-Link-Char包含3個重要的參數：GBW、MBW和MTD。GBW用于說明無線鏈路（一條無線鏈路可以由一個或多個無線信道組成）的保證速率；MBW用于說明無線鏈路的最大速率；MTD用于說明無線鏈路的最大傳輸時延。setup或play方法中的3GPP-Link-Char用于表示初始無線鏈路的質量，options或set_parameter方法中的3GPP-Link-Char用于表示更新的無線鏈路質量。3GPP-Link-Char頭消息起到了替代bandwidth頭消息的作用，并豐富了內容。

此外，3GPP還在setup、play、options和set_parameter方法的請求和應答消息中增加了3GPP-Adaptation頭消息，3GPP-Adaptation包含2個重要的參數：buffer-size-def和target-time-def。buffer-size-def表示用戶終端分配給流媒體播放器用于數據緩存的內存容量，它的作用是去除網絡抖動；target-time-def表示用戶終端的流媒體播放器需要保持的最短連續播放時間。

為了得到更詳細的流媒體業務質量，3GPP定義了QoE協議用于測量和報告流媒體業務質量。QoE協議基于RTSP和會議描述協議（session description protocol，SDP）的擴展，需要流媒體服務器和用戶終端的支持。QoE測量協商的需求在RTSP的describe或setup方法的響應消息中提出，在play方法中完成協商，在set_parameter方法中報告測量結果。QoE協議定義了針對媒體的測量指標corruption duration、successive loss of RTPpackets、frame-rate deviation、jitter duration；針對會話的測量指標content switch time、initial buffering duration、rebuffering duration。這些指標的用途參見表2。

從以上協議的分析可以了解到，當流媒體服務器和用戶終端都能支持上述協議時，流媒體服務器就能很好地掌握流媒體業務的播放質量和網絡質量，就能夠根據這些信息調整媒體編碼速率以適配網絡和終端的具體情況。流媒體服務器實現以上這些協議和能力并不難，然而對于移動網絡中的用戶終端，它們對協議的遵從度和設備能力可謂千差萬別。對于3層以上協議（如QoE協議）的統計測量，用戶終端流媒體播放器可以做到，但對于二層協議的信息，如RTSP中的bandwidth、GBW、MBW和MTD，需要用戶終端操作系統開放給應用程序。但從目前主流的幾個手機操作系統來看，都沒有提供這么一種方法或函數來獲取網絡帶寬方面的信息。

表2 3GPP QoE協議定義的測量指標用途說明

Symbian操作系統S60第5版的rconnmon.h文件提供了API方法GetUintAttribute，能獲取無線接入網類型TConnMonMobilePhoneNetworkMode，能告知應用程序無 線 接入網類型，如GSM、CDMA、cdma2000、WCDMA、TD-CDMA。雖然rconnmon.h文件定義了最大上行速率KMaximumBitrateUplink、最大下行速率KMaximumBitrate Downlink、保證上行速率KGuaranteedBitrateUplink、保證下行速率KGuaranteedBitrateDownlink，這樣的網絡帶寬信息常量，但也明確表明實際并不支持。

Android操作系統第8版的android.telephony文件的TelephonyManager類提供了API方法getNetworkType獲取無線接入網類型，類型包含GPRS、EDGE、UMTS、HSUPA、HSDPA、CDMA、EVDO等。但Android沒有提供獲取網絡帶寬的方法。

Windows Mobile 6.5系統2010年版的ril.h文件提供了API函數RIL_GetCurrentSystemType獲取無線接入網類型 ，類 型 包 含GSM、GPRS、GSM EDGE、UMTS、HSDPA、cdma2000、cdma2000 1x EV-DO、cdma2000 1x EV-DV等。但Windows Mobile 6.5也沒有提供獲取網絡帶寬的方法。

根據以上分析可以得出，由于手機操作系統沒有提供獲取網絡帶寬的方法，因此流媒體應用程序也就無法獲取網絡帶寬，更無法將網絡帶寬信息告知給流媒體服務器。所以在現有的應用中，大都是通過3層協議的統計測量來推測網絡帶寬，最常用的是基于RTCP的SR、RR報告的方案。通過測量各項傳輸指標的惡化情況，來判斷流媒體業務編碼速率與網絡帶寬的適配程度。即如果傳輸指標測量值較好，則說明網絡帶寬可以滿足當前的流媒體業務編碼速率，反之，則不滿足。3GPP定義的QoE協議可以獲取更精確的傳輸質量信息，但對于網絡帶寬也只能是采用和RTCP相同的推測方案。對于傳輸信道切換頻繁的移動網絡來說，要及時地獲取最新的網絡帶寬，采用RTCP的SR、RR報告或3GPPQoE協議就必須進行密集的測量，這對于傳輸信道帶寬較窄的移動網絡來說是額外的負荷；另外，用戶終端有限的處理能力也不適合在播放流媒體的同時提供這種密集的測量和報告，這樣流媒體服務器也就無法及時地調整流媒體內容的編碼速率來適配網絡帶寬的變化。綜上分析可以得出，現有技術不能很好地解決移動網絡中流媒體業務適配承載速率的問題。

3 基于無線承載情況通報的業務適配方案

通過分析3GPPTS23.060標準可以知道，在建立分組數據業務時，移動網絡會以PDPcontext的形式表示一個業務會話，服務GPRS支持節點 （serving GPRSsupport node，SGSN）會使用create PDP context消息告訴網關GPRS支持節點（gateway GPRSsupport node，GGSN）當前網絡為用戶分配的QoSprofile。在無線承載建立后，SSGN會用update PDPcontext消息告訴GGSN當前無線接入網與核心網協商后的QoSprofile。

在分組數據業務使用過程中，無論是發生用戶終端發起的PDPcontext修改，還是網絡側SGSN或GGSN發起的PDPcontext修改；無論修改原因是移動性管理的切換還是O&M，都由SGSN初始PDPcontext修改流程。在修改流程中，SGSN會先向GGSN發起update PDP context消息，然后再向用戶終端發起modify PDP context消息。因此，GGSN會在用戶終端之前知道網絡分配和修改的PDP context內容。GGSN在PDP context建立后，保存PDP context的 相 關 數 據QoS profile negotiated，QoS profile negotiated是當前無線接入網與核心網協商后的QoS profile，包含了當前移動網絡內該PDPcontext承載速率的配置信息，包含最大承載速率(maximum bit rate)、保證承載速率(guaranteed bit rate)、傳輸時延(transfer delay)。如果由GGSN將這些無線鏈路帶寬信息告知流媒體服務器，那么就可以解決現有技術的問題。

建議的方案為：GGSN與業務平臺服務器建立TCP或UDP的連接，用于QoS信息的實時傳送。GGSN一旦收到SGSN發出的update PDPcontext消息，就使用任何一種公開接口的通信協議，通過已經建立的TCP或UDP連接告知業務平臺服務器當前連接的QoS信息即無線鏈路帶寬信息。

該方案與現有技術相比較，優點如下。

·核心網SGSN、GGSN較用戶終端先知曉PDP上下文的QoS參數，即無線鏈路帶寬。GGSN可以第一時間將QoS的變化情況告知業務平臺服務器，實時性較好。

·SGSN發給GGSN的QoS參數包含了網絡分配的無線鏈路帶寬，業務平臺服務器無需再作估計，準確度高，效果好。

·對用戶終端無附加的軟硬件要求，滿足相關業務普及的需求。

·不針對特定業務平臺，適用范圍廣。

·無線鏈路無需傳輸附加信息，為業務的傳輸增加了資源。

方案實現原理如下所述。

在PDPcontext建立后，用戶終端會進入初始業務請求流程，見圖1。

用戶終端通過上行鏈路PDU流程將業務數據經SGSN轉發給GGSN，由GGSN進行業務數據的轉發。上行鏈路PDU流程采用GTP-U協議，GTP-U協議分為控制面消息和用戶面消息。SGSN使用用戶面消息GTP-U-UNITDATA請求向GGSN上傳上行鏈路PDU中的業務數據。根據3GPP TS23.060定義的協議棧結構，GGSN會對GTP-U的業務數據進行解析，獲取業務數據的Destination IP Address，即業務平臺應用服務器的IP地址。這個IP地址和GTP-U消息中的TEID（tunnel endpoint identifier）是本方案的兩個重要參數。TEID在一次PDPcontext中是惟一的，即可以用TEID將同一PDP context的GTP-C和GTP-U消息關聯起來。

GGSN收到首條GTP-U-UNIT-DATA請求消息后，啟動QoS初始報告程序。QoS初始報告程序判斷GTP-UUNIT-DATA請求消息的業務數據中destination IP address是否屬于簽約流媒體業務應用服務器（AS）。如果是，則根據GTP-U-UNIT-DATA請求消息的TEID找到對應的PDP context，并將destination IPaddress對應的應用服務器地址(application server address)添加到對應PDP context的application server address（為本方案新增）中，然后建立GGSN與AS的QoS報告鏈路并向AS發送QoS報告，將GTP-C類消息create PDPcontext中的QoSprofile negotiated通過QoS報告的方式告訴業務平臺。

在已經建立QoS報告鏈路的情況下，當無線鏈路需要更新時，則GGSN會收到SGSN發來的GTP-C類消息update PDPcontext。GGSN啟動QoS更新報告程序，QoS更新報告程序根據TEID找到PDPcontext，查找application server address。通過QoS報告鏈路向業務平臺的應用服務器發送QoS報告。以上QoS報告的流程示意見圖2。

通過以上方案，就可以在無線鏈路更新的第一時間將最大承載速率、保證承載速率、傳輸時延這些網絡二層信息告訴流媒體業務應用服務器，這樣應用服務器就可以根據無線鏈路的QoS來調整業務的編碼速率，對于流媒體業務來說就可以方便地根據無線鏈路的QoS來調整音、視頻內容的編碼速率了。

4 結束語

本文通過對流媒體相關標準和智能手機操作系統的分析，得出目前3GPP所定義的流媒體編碼速率適配承載鏈路帶寬的機制在實際應用中存在一定的缺陷，并在此基礎上結合3GPP的核心網標準提出了創新的解決方案。該方案可以有效解決流媒體業務適配承載鏈路帶寬的問題，并在華為公司的研發環境中得到了功能的驗證。該方案已申請發明專利，專利名稱為《UMTS或GRPS通信網絡告知業務平臺當前無線承載信息的方法》，申請號為200710043755.X，目前該專利正處于公開階段。該方案更詳細的機制和流程描述可參閱專利文件。

1 3GPP，TS 26.234 V9.3.0.Transparent end-to-end packet-switched streaming service(PSS)protocols and codecs，June，2010

2 3GPP，TS 23.060 V9.5.0.General packet radio service(GPRS)service description stage 2，June，2010

3 IETF，RFC 2326.Real time streaming protocol(RTSP)，April，1998

4 IETF，RFC 3550.RTP:A transport protocol for real-time applications，July，2003

5 Nokia Corporation.S60 5th edition API reference，2009

6 Google Inc.Android SDK reference API level 8，May，2010

7 Microsoft Corporation.Windows mobile 6.5 MSDN library，April，2010