一種無線流媒體服務解決的方法
2023-04-29 05:38:41 2
專利名稱：一種無線流媒體服務解決的方法
技術領域：
本發明涉及移動通信技術，特別是一種無線流媒體服務平臺搭建的方法。
背景技術：
目前流媒體技術越來越多地應用在手機終端，相對於有線流媒體被稱之為「無線流媒體」或「移動流媒體」，是3G的重點業務之一，也是介於會話業務和交互業務之間的一類業務。它對實時性的要求比會話業務低，同時它又不同於MMS(移動多媒體簡訊)，不是基於消息方式的異步地向用戶傳送多媒體內容，而是邊下載邊播放，所以必須能夠保持流內信息與實體之間的時間關聯。但是，無線網絡的不穩定性和速率限制使得目前移動流媒體的實現還不理想。
流媒體的基本業務一般分為以下三種典型模式(1)流媒體點播內容提供商將預先錄製好的多媒體內容編碼壓縮成相應格式，存放在內容伺服器上並把內容的描述信息以及連結放置在流媒體門戶上，最終用戶可以通過訪問門戶，發現感興趣內容有選擇播放。
(2)流媒體直播流媒體編碼伺服器將實時信號編碼壓縮成相應格式，經由流媒體伺服器分發到用戶的終端播放器。根據實時內容信號源，可以分為電視直播、遠程監控等。
(3)下載播放對於這個的主要限制指標是終端的處理能力和存儲能力，還需要考慮到下載時間。
移動流媒體業務功能要求移動流媒體業務必須向用戶提供內容發現和業務使用兩個基本功能，還必須具備與其他服務或應用的接口功能。內容發現是指用戶使用支持流媒體業務的手機或其他移動終端，訪問流媒體業務平臺Portal(入口)，通過頁面瀏覽、分類查找或直接搜索功能發現流媒體內容的過程。不同終端處理能力有很大區別，所支持協議也各不相同，所以流媒體業務必須具備對終端適配的功能。
對於移動用戶來說，在同一地點的不同時間或在同一時間的不同地點，所能使用的網絡帶寬會有很大不同，所以如果用統一帶寬壓縮的內容無法滿足不同用戶的實時播放要求。而流媒體業務需要則能根據終端的實際情況，提供帶寬適配的功能。
流媒體業務應具有可以傳送多種通用流媒體文件格的功能，因為終端的播放器不盡相同，使其可以選擇點播和下載。
另外，流媒體業務還必須具有認證和管理的能力，能夠為客戶提供安全可信的服務。
移動流媒體業務的協議結構如圖1所示，主要由用於網絡上針對多媒體數據流的實時傳輸協議RTP(Real-time Transport Protocol)、與RTP一起提供流量控制和擁塞控制服務的實時傳輸控制協議RTCP(Real-time TransportControl Protocol)、定義了一對多的應用程式如何有效地通過IP網絡傳送多媒體數據的實時流協議RTSP(Real-time Streaming Protocol)組成。除上述協議之外，流媒體技術還包括對於流媒體類別的識別。
(1)實時傳輸協議RTPRTP被定義在一對一或一對多傳輸情況下工作，目的是提供時間信息和實現流同步。RTP通常使用用戶數據協議(UDP)來傳送數據，也可以在傳輸控制協議(TCP)等其他協議上工作。當應用程式開始一個RTP會話時，使用兩個埠，一個給RTP，一個給RTCP，RTP本身不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制和擁塞控制，依靠RTCP提供這些服務。RTP的機理主要是實現端到端的多媒體同步控制，不需要建立連結也不需要中間點的參與，為其保留資源。通常RTP算法並不作為一個獨立的網羅層來實現，而是作為應用程式代碼的一部分。
(2)實時傳輸控制協議RTCP和RTP一起提供流量控制和擁塞控制服務。在RTP會話期間，各參與者周期性地傳送RTCP包，其中包括已發送的數據包的數量、丟失的數據包的數量等統計資料，因此伺服器可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型(發送速率、帶寬)，達到對服務質量(QoS)的保證。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，特別適合傳送網上實時數據。
(3)實時流協議RTSPRTSP是由Real Networks和Netscape同時提出的，定義了一對多應用程式如何有效地通過IP網絡傳送多媒體數據，RTSP協議在體系結構上位於RTP和RTCP之上，使用TCP或RTP完成數據傳輸。RTSP屬於應用級協議，提供了一個可擴展框架，使實時數據(如音頻、視頻)的受控，點播成為可能，目的是控制多個數據控制連接，為選擇發送通道(如UDP)組播UDP與TCP提供途徑，並為選擇基於RTP上發送機制提供方法。
(4)資源預定協議RSVP在一定程度上為流媒體的傳輸提供Qos，不傳輸數據，可預留一部分網絡資源(即帶寬)，正在開發中。
(5)服務質量Qos由發送端定時發送Qos測量包，在大多數網絡性能實時判斷中，有選擇地將延遲、抖動、丟包率、吞吐量和亂序程度等參數中的全部或幾個作為評價Qos的指標。
根據現有的無線網絡情況，有幾種無線流媒體業務的實現方法1、如圖2所示的三部分流媒體服務平臺、流媒體管理平臺和流媒體編碼伺服器。流媒體服務平臺完成流媒體平臺基本業務功能，如下載、實時播放等。流媒體管理平臺完成用戶管理、CP管理、計費管理、網管、門戶管理等相應的管理功能。流媒體編碼伺服器完成流媒體的實時播放的編碼功能。該系統的主要功能支持3GPP的視頻流(比如MPEG-4)，具有和3GPP協同工作能力，兼容範圍覆蓋了音頻流和視頻流，MP4文件格式，RTP/RTCP以及RTSP/SDP。通過單傳播流對同一個存儲文件或者實時輸入數據流進行同時流處理，輸入到多pvPlayers中。無線傳輸接口獨立性(Air InterfaceIndependence)(比如專門設計的多重無線傳輸接口，所支持的網絡包括GSM、GPRS、UMTS、CDMA、802.11、wireline等等)。適合行動網路大規模商用。全面符合3GPP和3GPP2行業標準，提供MPEG-4和H.263編碼。可以動態帶寬適配(FrameTrack)，邊下載邊播放(FastTrack)，擁有超強糾錯能力(QualityTrack)和終端能力自適應性。該方法的優點在於對現有網絡不需要增加新的接入點，從而降低了用戶的使用門檻。由於通過WAP GPRS接入，系統可以從WAP網關上提取用戶的手機號碼，然後把該號碼傳給後臺流媒體伺服器，使系統伺服器能夠對用戶計費。該系統的缺點在於該系統中，在行動網路中最接近用戶的網元是GGSN(Gateway GPRS Support Node，網關GSN)，它主要起網關作用，可以和多種不同的數據網絡連接，如ISDN、PSPDN和LAN等，又被稱為GPRS路由器，它可以把GSM網中的GPRS分組數據包進行協議轉換，從而把這些分組數據包傳送到遠端的TCP/IP或X.25網絡。因此，終端用戶每次所接受的數據包都是通過中繼轉發，直接來自於遠端Internet中的內容伺服器，無線網絡和有線網絡的不穩定都會造成數據包的丟失和延時，從而造成流媒體實時服務質量的下降。而且GGSN網關將承受大量的數據流。再者，伺服器將數據包發送出去的時間間隔要能實時地調整好也存在一定的困難，間隔時間很長會導致信息包傳輸負擔過重，引發網絡出現故障。而短的時間間隔又會增加前後線程的切換頻率，從而導致伺服器的效率降低。
2、另外一種移動流媒體業務解決方法如圖3所示，其中的主要模塊功能(1)Stream Media Server這是infoxTM-OpenStream的核心部分，主要進行流式媒體的編解碼、連接管理、優先級調度、會話管理等工作。它通過實時傳輸會話管理協議接收CP/SP的視音頻源，實現數據壓縮，並實時傳輸媒體格式，與GGSN/PDSN組網，進行視音頻源的傳遞，系統具有高性能的處理能力。
(2)Presentation Server實現用戶瀏覽內容的入口和導航功能，可進行用戶個性化設置、QoS設置等，並可實現業務推薦和排行、業務預覽和查詢界面、終端適配等功能，可為不同類型的終端提供不同的業務界面和業務集合。(3)Content Storage內容存儲伺服器，可為編輯的視頻、音頻剪輯提供存儲，並支持大容量並發用戶的視音頻處理。
(4)DRM Manager數字版權管理模塊，負責包裝內容、生成應用License、限制終端內容的轉發和多次播放等。
(5)Service Publisher業務發布窗口，是一種面向CSP的業務發布門戶。
(6)SP代理實現SP流媒體節目源的實時傳輸，並支持向SP實時發送流媒體內容的計費信息，以便SP與運營商結算。
該方法在整個系統中，集成進了完善的功能，和現有的無線網絡實現了很好的結合。但是，考慮到無線數據服務的特點，數據包在網絡上的存在周期長將不適合實時服務的要求，節目流化時延和丟失出錯的可能性將比較大。
3、一種基於RealSystem的移動流媒體平臺實現方法RealSystem支持目前聯通CDMA網和中國移動GSM網要求的所有流媒體格式。
RealSystem的編碼有其獨有的特點RealSystem採用可擴展視頻技術作為其主要視頻編解碼，利用基於小波變換技術的Real專用算法，如連接速率低於編碼時採用的速率，播放時伺服器端丟棄不重要的信息，播放器解碼儘可能還原視頻質量。通過CVT(callable video technology)技術可以讓速度較慢的電腦或手機不需要解開所有的原始圖像數據也能流暢地觀看節目；雙向編碼技術類似於可變化特率(VBR)，根據帶寬的限制選擇最優化壓縮碼率。為了更好地適應在網上傳播，它還可以根據帶寬來選擇最佳壓縮比率的Real文件，RealSystem的編碼工具能將多媒體信息記錄成不同碼率存在同一個文件，這就是所謂的SureStream(智能流)技術。用RealSystem搭建的流媒體平臺實現如圖4，根據不同的業務內容，在交換機上劃分不同的網段管理網段設置了2臺SUN F480作為多媒體管理平臺伺服器，採用SUN3510磁碟陣列，形成HA架構。設置一臺SUN F240作為PORTAL SERVER。
點播/直播網段設置了16臺點播/直播伺服器，8臺備份點播/直播伺服器，伺服器採用PC SERVER，REDHAT LINUX作業系統，通過4層交換機實現業務的負載均衡。
下載網段設置8臺下載伺服器，4臺備份下載伺服器，伺服器採用PCSERVER，REDHAT LINUX作業系統，通過4層交換機實現業務的負載均衡。
內容分發網段設置2臺內容分發伺服器，1臺備份內容分發伺服器，伺服器採用SUN F240，配置了SUN 3510磁碟陣列作為內容存儲設備，通過4層交換機實現業務的負載均衡。
採編伺服器設置一臺PC SERVER作為採編伺服器，配置視頻捕捉卡，對直播節目源進行編碼。
採用上面的配置，在單節點情況下能滿足2萬用戶並發使用下載服務，3萬用戶並發使用點播/直播服務，採用50％的冗餘伺服器。如果有更多用戶，則要擴展多節點模式，用戶連接時使系統尋找最近的流媒體伺服器，如果該伺服器上沒有才從中心伺服器複製。實況直播時採用這種結構進行分流；Vod點播時流媒體伺服器具有Cache功能。
這種搭建方式可以減輕中心伺服器的壓力，而且智能流的實現將大大提高移動流媒體服務的質量。但是，高效的服務以伺服器的冗餘為一定的代價，在現有的網絡環境和應用需求下，這樣的搭建無疑是很耗費的，而且如果用這種方式來組建未來的流媒體服務網絡，在數據交互中將出現共享衝突和資源浪費的問題，還有很多的實現細節需要考慮。
基於無線網絡的特點，以及現有的移動流媒體服務性能上存在的一些問題，需要提出一種高效地無線流媒體服務解決的方法，充分利用網絡資源，提供更可靠的服務，提高服務質量。
發明內容
本發明所要解決的技術問題是提出一種無線流媒體服務平臺的解決方法，引入接入網關，將接入網關作為一個流媒體服務平臺的代理，使之在提供有線與無線網絡數據包協議轉換等功能之外，能夠具有存儲、實時探測無線網絡可用帶寬等能力，從而可以在相互之間通過有線網絡的連接協同工作，為客戶端提供高質量的服務。
為解決上述技術問題，本發明是這樣實現的本發明提供一種無線流媒體服務的解決方法，具有一種無線流媒體服務平臺，包括以下步驟引入接入網關，將接入網關作為一個流媒體服務平臺的代理；尋找最佳接入網關，將移動終端與最優接入網關之間建立起相應的連接；移動終端與新的接入網關建立連接，改變提供服務的無線信道，實現無縫切換；實時地探測無線帶寬的改變，由接入網關和主伺服器協同實現探測無線網絡帶寬，並基於速率控制模塊的服務質量。
與現有技術相比較，本發明的優點在於在不對當前網絡狀況和網絡架構作改動的前提下，通過在無線與有限網段之間加入一個接入網關，集成多個功能模塊，以及各算法機制，充分克服現有技術中出現的種種問題，有效提高無線流媒體的服務質量。
圖1是現有技術採用的移動流媒體系統的協議結構示意圖。
圖2是現有技術中的一種移動流媒體業務解決方法的結構示意圖。
圖3是現有技術中另一種移動流媒體業務解決方法的結構示意圖。
圖4是現有技術中的一種基於RealSystem的移動流媒體平臺實現的結構示意圖。
圖5是本發明中流媒體服務網絡的示意圖。
圖6是本發明中加入接入網關後的流媒體實現示意圖。
圖7是本發明中接入網關的主要模塊及功能示意圖。
圖8是本發明中最佳接入網關的第一次握手的示意圖。
圖9是本發明中最佳接入網關的第二次握手的示意圖。
圖10是本發明中最佳接入網關的第三次握手的示意圖。
圖11是本發明無縫切換方法前後的數據流向示意圖。
圖12是本發明實時探測所用數據包的示意圖。
圖13是本發明速率控制模塊的功能實現流程圖。
具體實施例方式本發明提出一種流媒體服務平臺的搭建方法，主要是引入了接入網關，同時將它作為一個流媒體服務平臺的代理，使之在提供有線與無線網絡數據包協議轉換等功能之外，能夠具有存儲、實時探測無線網絡可用帶寬等能力，以及可以在相互之間通過有線網絡的連接協同工作，為客戶端提供高質量的服務，如圖5所示。
在本實施例中，具體實現方法如下1、如圖6所示，流媒體接入網關的主要接口、相應功能及實現方法數據接口該接口負責與流媒體主伺服器和其他的接入網關之間進行會話，與它們之間的連接基於有線網絡(網際網路)。在以數據接口為埠的連接中，流媒體接入網關可以看作接收數據的客戶端(當然，在與其他接入網關進行交互時又可以作為提供數據的服務端)，由於是基於有線網絡，所以在網絡狀態良好的條件下，它們之間的數據傳輸方式可以採用基於TCP之上的RTP/RTCP，由於TCP自身具有重傳機制，所以可以保證有線網絡傳輸段數據接收的性能是最優的，並且無線網段傳回的反饋有丟包等信息的RTCP包通過這裡的中轉及相應的算法(相應算法如後述)，轉發回主伺服器，實現重傳，保證可以更好地保證服務質量。當用戶點播一個文件時，通過代理網關的中轉，與主伺服器之間實現連接及相應的反饋。
無線接口該接口負責與無線終端之間進行對話，在無線網段中，可以看作是向無線終端發送數據的服務端。由於無線網段帶寬不穩定，所以在該段中的數據傳輸方式採用基於UDP之上的RTP/RTCP，而且在帶寬探測上使用一些改進的方法(改進方法如後述)，以節約現有無線網絡資源，為客戶提供更流暢的服務。
速率控制模塊負責實時探測帶寬，並且分析無線終端反饋的RTCP包，生成反饋給主伺服器的反映無線網絡帶寬和當前服務狀況的RTCP包。這是基於無線網段和有線網段的差異，並不將終端返回的所有RTCP包都中轉回主伺服器，如果都不加區別地反饋回去，伺服器將不能判斷其反映的是有線網段的性能變化還是無線網段的，無法採取相應的措施。比如如果是來自有線網段的丟包，那麼將重發該數據包，如果是來自無線網段探測帶寬時的丟包則不希望其直接反饋給主伺服器。
磁碟陣列及緩存機制代理網關在轉發數據包之後，在自己的磁碟陣列中仍然有相應文件數據包的備份隊列，這樣對於客戶點播率高的文件，不需要每次都與主伺服器進行交互，分流其負擔。並且由於該接入網關相對而言，離用戶最近，所以它們之間的數據傳輸受網絡狀況的影響小，故接入網關此時在一定意義上可以看作是移動終端的緩存系統。磁碟陣列中保存著的相應文件的備份隊列，保存的時間按照文件的點播率等相應參數進行配置，在下次有移動終端點擊相應連結的時候，可以不需要再次與主伺服器聯繫，同時，這種機制也利於後面提到的終端與不同代理網關之間的無縫切換，可以儘量控制傳輸時延抖動和包倒序。所以，從這種角度來看，接入網關充當了移動流媒體主伺服器的代理的角色。
參見圖7所示，基於以上的功能描述，流媒體接入網關必須能夠完成有線網絡與無線網絡之間協議的解析、TCP數據報文的解析、UDP包的封裝、存儲功能以及與鄰近接入網關的協調交互。
2、尋找最佳接入網關的三次握手方法由於移動終端當前位置的不確定性，所以不能固定與一個接入網關建立連接，所以終端必須具有尋找最佳接入點的能力，這可以通過與接入點的交互來實現。方法如圖8至圖10所示第一次握手如圖8所示，當移動終端點擊一個連結，向遠端流媒體伺服器發起一個請求的同時，發出多個REQUEST數據包，裡面有相應的請求連結以及移動終端信息，同時打開接受埠，進入等待狀態。
第二次握手如圖9所示，當位於無線網絡邊緣的接入網關檢測到這樣的REQUEST數據包之後，檢查自己是否有可用埠，如果此時處於鏈連接滿的狀態則不作任何回應，而現在仍有可用埠的接入網關則首先獲取終端信息，寫入自己的相應信息，並檢查自己的磁碟陣列中是否有相應連結的緩存文件，如果有則向該終端回復一個級別最高的ANSWER數據包，如果當時磁碟陣列中並沒有相應連結的緩存文件，則向終端回復一個次高級別的ANS數據包。
第三次握手如圖10所示，處於等待狀態的移動終端將接收到不同接入網關的回覆數據包，根據接受到的時序及不同ANSWER的優先級別按照一定的判別機製作出相應的判斷，向此時能提供最優服務的接入網關回復一個CONFIRM(/CFM)數據包，並且使播放器等待接收由該網關發送來的RTP數據包。
至此，三次握手機制完成，移動終端與最優接入網關之間建立起相應的連接。
3、無縫切換技術基於無線帶寬的不穩定性，無線終端和某個網關之間的連接不是固定的不可變的。因為如果收看直播，接收節目的時間可能很長，加上無線終端的移動性，該終端不一定總與最初的那個接入網關之間有最優的連接。因此在移動終端接收的服務質量不佳並且探測到更優服務質量的接入網關時，在不影響當前觀看的前提下，與新的接入網關建立連接，實現無縫切換，改變提供服務的無線信道。
基於各無線網關之間通過數據接口相互連接，它們之間可以通過有線網段進行數據交換，而有線網段相對穩定，加上向移動終端提供的流媒體數據並不佔用太多帶寬(圖像的解析度和視頻流的碼率均比有線流媒體低)，所以它們之間的數據交換很快。
當移動終端在接收流媒體服務期間發生較大的位置移動，或者是連接時間超過一個門限的時候，用三次握手的方法搜尋最佳接入點(在接收媒體數據的同時發送出多個REQ數據包)。但是在它確定了最佳接入點後，改動三次握手的第三步不是向最佳點發送CFM包，而是把最佳接入點的信息用一個數據包TSF(/TRANSFER)反饋給現有的接入網關，接入網關在收到這樣的數據包後，解析出新接入網關的地址，將移動終端的地址信息、當前和之後的數據包轉發給它，同時停止向移動終端發送數據。這樣，將向移動終端發送數據的任務轉交給新的接入點。
通過這樣的方法，新接入點不需要再次與流媒體主伺服器之間進行初始連接，可以減少用戶的等待時間，在用戶端看來是並不影響服務質量。
4、實時探測無線網絡帶寬方法及基於速率控制模塊的Qos方法不同的移動終端，其處理能力有較大的差異，無線網絡帶寬在不同時段也是相當不穩定的，相鄰的時間內可能發生很大的變化，而帶寬的改變將導致流媒體數據包的延時和丟失，影響實時流媒體服務的質量，所以提出一種方法，實時地探測無線帶寬的改變，該方法是基於網關中轉RTCP包的方法實現，判斷丟包發生在什麼網段，以相應地進行重傳，保證用戶端獲得穩定的流媒體服務質量。
正如在前面的協議部分提到的那樣，現在的探測方法一般是基於RTP和RTCP信息包對實現的，向客戶端發送多個信息包對，交互後得到當前的信道容量，這種方法對於無線網絡上的實時流媒體服務來說不是什麼適合，因為在探測過程中將產生很多附加的信息包，在無線網絡帶寬本就不是很富裕的現狀下，這種方法很浪費帶寬。
本發明提出一種更高效的探測方法將一個RTP包分成兩個大小相等的部分，用這樣的RTP信息包對來完成對可用帶寬的探測。其中一個包用來傳輸流媒體數據，另一個包用來對帶寬進行探測。這樣可以在不影響發送的數據包長度和數量的前提下，既保證了流媒體數據的傳輸又達到探測帶寬的目的。該功能由無線網關的速率控制模塊實現，並分析終端返回的RTCP包，分析後生成反饋給主伺服器的RTCP包。
在初始探測階段，任務是得到當前的可用帶寬，以選擇合適碼率的媒體流，但是為了不增加用戶的等待連接和緩衝時間，總是默認先讓主伺服器發送最低比特率的媒體流，然後由接入網關實現初始帶寬的探測，它利用探測RTP數據包對中的一個發送全1的探測比特，不斷地增加發送比特率，一旦移動終端返回的RTCP包顯示出的丟包率超過了一定的門限，即停止探測，並將當時的比特率用一個RTCP包反饋給主伺服器(採用智能流技術)，由主伺服器判斷是否改變所發送的媒體流的碼率，或者認為當前帶寬無法實現終端的點播請求，中斷服務。
當主伺服器選擇了合適的發送碼率後，將適配無線帶寬的任務交給接入網關中的速率控制模塊。該模塊通過分析無線終端返回的RTCP包來得到當前信道的丟包率λb，並與所選碼率媒體流的最大允許丟包率λc相比較，一旦λb＞λc，則說明現有碼率的媒體流不適合在現有信道上傳輸，接入網關向主伺服器反饋一個RTCP，要求重新選擇低碼率的媒體流；當λb≤λc的時候只需要根據實時探測到的無線網絡帶寬控制接入網關磁碟隊列中的媒體數據的發送速率，具體做法是比較當前帶寬Ab和初始帶寬Ac，Ab＜Ac時，降低發送的比特率，Ab＞Ac時，適當增加發送的比特率，相等是保持碼率不變。
在所提出的解決方法中，儘可能地減輕流媒體主伺服器的負荷，而把調整碼率的任務交給接入網關來完成。考慮到無線網絡狀況與有線網絡之間的差異，以儘量高效地感應到無線網絡段的帶寬變化更實時地作出調整。
與現有技術相比較，本發明的優點在於在不對當前網絡狀況和網絡架構作改動的前提下，通過在無線與有限網段之間加入一個接入網關，集成多個功能模塊，以及各算法機制，充分克服現有技術中出現的種種問題，有效提高無線流媒體的服務質量。
綜上所述僅為本發明的較佳實施例而已，並非用來限定本發明的實施範圍。即凡依本發明申請專利範圍的內容所作的等效變化與修飾，都應為本發明的技術範疇。
權利要求
1.一種無線流媒體服務的解決方法，具有一種無線流媒體服務平臺，其特徵在於包括以下步驟引入接入網關，將接入網關作為一個流媒體服務平臺的代理；尋找最佳接入網關，將移動終端與最優接入網關之間建立起相應的連接；移動終端與新的接入網關建立連接，改變提供服務的無線信道，實現無縫切換；實時地探測無線帶寬的改變，由接入網關和主伺服器協同實現探測無線網絡帶寬，並基於速率控制模塊的服務質量。
2.根據權利要求1所述的一種無線流媒體服務的解決方法，其特徵在於所述流媒體接入網關的主要接口包括數據接口、無線接口、速率控制模塊和磁碟陣列及緩存機制。
3.根據權利要求2所述的一種無線流媒體服務的解決方法，其特徵在於所述數據接口負責與流媒體主伺服器和其他的接入網關之間進行會話，與它們之間的連接基於有線網絡，在以數據接口為埠的連接中，流媒體接入網關可以看作接收數據的客戶端，在與其他接入網關進行交互時又可以作為提供數據的服務端，由於是基於有線網絡，所以在網絡狀態良好的條件下，它們之間的數據傳輸方式可以採用基於TCP之上的RTP/RTCP，由於TCP自身具有重傳機制，所以可以保證有線網絡傳輸段數據接收的性能是最優的，並且無線網段傳回的反饋有丟包等信息的RTCP包通過這裡的中轉及相應的算法，轉發回主伺服器，實現重傳，保證可以更好地保證服務質量，當用戶點播一個文件時，通過代理網關的中轉，與主伺服器之間實現連接及相應的反饋。
4.根據權利要求2所述的一種無線流媒體服務的解決方法，其特徵在於所述無線接口負責與無線終端之間進行對話，在無線網段中，可以看作是向無線終端發送數據的服務端，由於無線網段帶寬不穩定，所以在該段中的數據傳輸方式採用基於UDP之上的RTP/RTCP，而且在帶寬探測上使用一些改進的方法，以節約現有無線網絡資源，為客戶提供更流暢的服務。
5.根據權利要求2所述的一種無線流媒體服務的解決方法，其特徵在於所述速率控制模塊負責實時探測帶寬，並且分析無線終端反饋的RTCP包，生成反饋給主伺服器的反映無線網絡帶寬和當前服務狀況的RTCP包。
6.根據權利要求2所述的一種無線流媒體服務的解決方法，其特徵在於所述磁碟陣列及緩存機制，代理網關在轉發數據包之後，在自己的磁碟陣列中仍然有相應文件數據包的備份隊列，這樣對於客戶點播率高的文件，不需要每次都與主伺服器進行交互，分流其負擔，並且由於該接入網關相對而言，離用戶最近，所以它們之間的數據傳輸受網絡狀況的影響小，故接入網關可看作是移動終端的緩存系統，磁碟陣列中保存著的相應文件的備份隊列，保存的時間按照文件的點播率等相應參數進行配置，在下次有移動終端點擊相應連結的時候，可以不需要再次與主伺服器聯繫，同時，這種機制也利於後面提到的終端與不同代理網關之間的無縫切換，可以儘量控制傳輸時延抖動和包倒序。
7.根據權利要求1所述的一種無線流媒體服務的解決方法，其特徵在於通過類似TCP三次握手方式的方法，與接入點的交互來實現用戶在接受流媒體服務過程中，因為位置的移動或者服務質量問題需要在網關之間進行切換時，不影響服務質量的無縫切換方法。
8.根據權利要求1或7所述的一種無線流媒體服務的解決方法，其特徵在於所述在移動終端與最優接入網關之間建立起相應的連接是通過三次握手的方法實現的，包括以下步驟第一次握手當移動終端點擊一個連結，向遠端流媒體伺服器發起一個請求的同時，發出多個REQUEST數據包，裡面有相應的請求連結以及移動終端信息，同時打開接受埠，進入等待狀態；第二次握手當位於無線網絡邊緣的接入網關檢測到這樣的REQUEST數據包之後，檢查自己是否有可用埠，如果此時處於鏈連接滿的狀態則不作任何回應，而現在仍有可用埠的接入網關則首先獲取終端信息，寫入自己的相應信息，並檢查自己的磁碟陣列中是否有相應連結的緩存文件，如果有則向該終端回復一個級別最高的ANSWER數據包，如果當時磁碟陣列中並沒有相應連結的緩存文件，則向終端回復一個次高級別的ANS數據包；第三次握手處於等待狀態的移動終端將接收到不同接入網關的回覆數據包，根據接受到的時序及不同ANSWER的優先級別按照一定的判別機製作出相應的判斷，向此時能提供最優服務的接入網關回復一個CONFIRM/CFM數據包，並且使播放器等待接收由該網關發送來的RTP數據包。
9.根據權利要求1或7所述的一種無線流媒體服務的解決方法，其特徵在於所述無縫切換是指當移動終端在接收流媒體服務期間發生較大的位置移動，或者是連接時間超過一個門限的時候，用三次握手的方法搜尋最佳接入點亦即在接收媒體數據的同時發送出多個REQ數據包，其中三次握手的第三步是把最佳接入點的信息用一個數據包TSF/TRANSFER反饋給現有的接入網關，接入網關在收到這樣的數據包後，解析出新接入網關的地址，將移動終端的地址信息、當前和之後的數據包轉發給它，同時停止向移動終端發送數據，從而將向移動終端發送數據的任務轉交給新的接入點。
10.根據權利要求1所述的一種無線流媒體服務的解決方法，其特徵在於所述實時探測的方法是將一個RTP包分成兩個大小相等的部分，用這樣的RTP信息包對來完成對可用帶寬的探測，其中一個包用來傳輸流媒體數據，另一個包用來對帶寬進行探測，該功能由無線網關的速率控制模塊實現，並分析終端返回的RTCP包，分析後生成反饋給主伺服器的RTCP包。
11.根據權利要求1或10所述的一種無線流媒體服務的解決方法，其特徵在於所述實時探測的方法在初始探測階段，總是默認先讓主伺服器發送最低比特率的媒體流，然後由接入網關實現初始帶寬的探測，它利用探測RTP數據包對中的一個發送全1的探測比特，不斷地增加發送比特率，一旦移動終端返回的RTCP包顯示出的丟包率超過了一定的門限，即停止探測，並將當時的比特率用一個RTCP包反饋給主伺服器，由主伺服器判斷是否改變所發送的媒體流的碼率，或者認為當前帶寬無法實現終端的點播請求，中斷服務；當主伺服器選擇了合適的發送碼率後，將適配無線帶寬的任務交給接入網關中的速率控制模塊，該模塊通過分析無線終端返回的RTCP包來得到當前信道的丟包率λb，並與所選碼率媒體流的最大允許丟包率λc相比較，一旦λb＞λc，則說明現有碼率的媒體流不適合在現有信道上傳輸，接入網關向主伺服器反饋一個RTCP，要求重新選擇低碼率的媒體流；當λb≤λc的時候只需要根據實時探測到的無線網絡帶寬控制接入網關磁碟隊列中的媒體數據的發送速率，具體做法是比較當前帶寬Ab和初始帶寬Ac，Ab＜Ac時，降低發送的比特率，Ab＞Ac時，適當增加發送的比特率，相等是保持碼率不變。
全文摘要
本發明提出了一種無線流媒體服務平臺的解決方法，引入接入網關，將接入網關作為一個流媒體服務平臺的代理，使之在提供有線與無線網絡數據包協議轉換等功能之外，能夠具有存儲、實時探測無線網絡可用帶寬等能力，從而可以在相互之間通過有線網絡的連接協同工作，為客戶端提供高質量的服務。
文檔編號H04L12/56GK1835482SQ20051011224
公開日2006年9月20日 申請日期2005年12月29日 優先權日2005年12月29日
發明者蔡群 申請人:上海貝豪通訊電子有限公司