王勇強

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

1 引言

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

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

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

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

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

2 現(xiàn)有技術分析

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

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

RTP協(xié)議負責流媒體內(nèi)容的傳輸。

RTCP協(xié)議負責反饋RTP會話質量并傳遞RTP同步時間戳。為了反饋RTP會話質量，RTCP協(xié)議中定義了周期性發(fā)送的報文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協(xié)議負責流媒體播放的控制，如播放、暫停、快進、快退等。在RTSP協(xié)議中定義了bandwidth頭消息，bandwidth用于說明發(fā)送方估計的網(wǎng)絡帶寬。bandwidth可以作為請求頭消息應用于RTSP所有的方法中 （如：describe、setup、set_parameter等），協(xié)議規(guī)定接受 方對于bandwidth頭消息的支持是可選的。

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

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

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

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

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

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

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

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

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

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

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

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

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

該方案與現(xiàn)有技術相比較，優(yōu)點如下。

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

·SGSN發(fā)給GGSN的QoS參數(shù)包含了網(wǎng)絡分配的無線鏈路帶寬，業(yè)務平臺服務器無需再作估計，準確度高，效果好。

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

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

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

方案實現(xiàn)原理如下所述。

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

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

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

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

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

4 結束語

本文通過對流媒體相關標準和智能手機操作系統(tǒng)的分析，得出目前3GPP所定義的流媒體編碼速率適配承載鏈路帶寬的機制在實際應用中存在一定的缺陷，并在此基礎上結合3GPP的核心網(wǎng)標準提出了創(chuàng)新的解決方案。該方案可以有效解決流媒體業(yè)務適配承載鏈路帶寬的問題，并在華為公司的研發(fā)環(huán)境中得到了功能的驗證。該方案已申請發(fā)明專利，專利名稱為《UMTS或GRPS通信網(wǎng)絡告知業(yè)務平臺當前無線承載信息的方法》，申請?zhí)枮?00710043755.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