一種寬帶集群呼叫業(yè)務的視頻流Qos控制方法
【專利摘要】本發(fā)明公開了一種寬帶集群呼叫業(yè)務的視頻流Qos控制方法，該方法對于I幀請求(IR)，定義一個關鍵幀的最小發(fā)送間隔，超過這個頻率的I幀請求丟棄不處理；對于接收報告(RP)，接收端周期性的發(fā)送自己收到的包數(shù)和丟掉的包數(shù)，主叫收到此報告后根據(jù)丟包情況動態(tài)調(diào)整發(fā)送視頻流的碼率和幀率，分辨率不變。本發(fā)明能夠有效地解決B?Trunc單呼和組呼中網(wǎng)絡覆蓋、丟包、誤碼等引起的視頻卡頓花屏的問題。
【專利說明】
一種寬帶集群呼叫業(yè)務的視頻流Qos控制方法
技術領域
[0001] 本發(fā)明涉及多媒體實時視頻技術領域，尤其涉及LTE寬帶集群系統(tǒng)中的集群視頻 呼叫的視頻流Qos控制方法。
【背景技術】
[0002] 集群系統(tǒng)是一種高效的無線通信系統(tǒng)，通過共享無線信道，以較少的無線信道數(shù) 量支持大量的無線用戶進行群組通信。
[0003] 隨著無線LTE寬帶技術的飛速發(fā)展，基于LTE寬帶技術的寬帶集群系統(tǒng)B-TrunC也 應運而生，寬帶LTE技術為集群系統(tǒng)提供了更大的信道容量，從而為集群系統(tǒng)實現(xiàn)寬帶集群 業(yè)務調(diào)度提供了有力支持。
[0004] B-TrunC標準是CCSA制定的，以LTE技術為基礎，采用了先進的下行共享信道技術 支持點對多點的傳輸機制，支持從20M到1.4M的靈活帶寬，是國際上首個支持點對多點語音 通話、點對多點視頻通話等應用的PPDR寬帶集群通信標準。目前B-TrunC中的視頻業(yè)務包括 全雙工視頻呼叫、同源視頻組呼，不同源視頻組呼、環(huán)境監(jiān)視、視頻下推、視頻上拉、視頻下 拉、視頻回傳等。在傳統(tǒng)的IP視頻通話中，即使是在丟包率很小的情況下也會對使用效果造 成較為明顯的影響。丟包造成的影響多種多樣。其中對視頻質(zhì)量的影響主要有：馬賽克現(xiàn) 象、局部變形（圖像的某些區(qū)域不清晰）、圖像模糊、屏幕頻繁刷新或閃爍、視音頻不同步、幀 率下降、圖像靜止等等。對音頻質(zhì)量的影響包括:總體音頻失真、間斷或間歇性噪音、音頻中 斷等。另外，丟包還會引起過度延遲，甚至是通話中斷。
[0005] LTE無線移動網(wǎng)絡由于方案復雜，技術難度大，高頻段相對低頻段來說路徑損耗和 繞射能力都比較差，在網(wǎng)絡覆蓋、臨區(qū)切換、越區(qū)覆蓋等方面有許多難點，例如，如何保證樓 區(qū)、山區(qū)，及其它有障礙物等易受影響地區(qū)的信號強度等問題。在移交方面也存在的技術問 題，使手機很容易在從一個基站的覆蓋區(qū)域進入另一個基站的覆蓋區(qū)域時和網(wǎng)絡失去聯(lián) 系。另外手機的速度會受到通信系統(tǒng)容量的限制，如系統(tǒng)容量有限，手機用戶越多，速度就 越慢。表現(xiàn)在數(shù)據(jù)面相比傳統(tǒng)的IP網(wǎng)絡就是在對數(shù)據(jù)傳輸帶來更多不可預測的網(wǎng)絡波動。 [0000]目前，人們采用Rtcp(RTP Control Protocol)，提供數(shù)據(jù)分發(fā)質(zhì)量反饋信息，RTP 作為傳輸協(xié)議的部分功能并且它涉及到了其它傳輸協(xié)議的流控制和擁塞控制。RTCP的主要 功能有：
[0007] (1)用反饋信息的方法來提供分配數(shù)據(jù)的傳送質(zhì)量，這種反饋可以用來進行流量 的擁塞控制，也可以用來監(jiān)視網(wǎng)絡和用來診斷網(wǎng)絡中的問題；
[0008] (2)為RTP源提供一個永久性的CNAME(規(guī)范性名字）的傳送層標志，因為在發(fā)現(xiàn)沖 突或者程序更新重啟時SSRC(同步源標識)會變，需要一個運作痕跡，在一組相關的會話中 接收方也要用CNAME來從一個指定的與會者得到相聯(lián)系的數(shù)據(jù)流(如音頻和視頻）；
[0009] (3)根據(jù)與會者的數(shù)量來調(diào)整RTCP包的發(fā)送率；
[0010] (4)傳送會話控制信息，如可在用戶接口顯示與會者的標識，這是可選功能。
[0011] 但是，上述解決方案仍然存在無線波動、丟包、誤碼情況相比傳統(tǒng)IP網(wǎng)絡來的更為 突然和嚴重的現(xiàn)象，而B-TrunC視頻調(diào)度業(yè)務一般用于公安、消防、石油、救災、政務、交通等 重要的部門，因此對視頻業(yè)務的質(zhì)量提出更為嚴苛的要求。所以，如何解決LTE無線移動網(wǎng) 絡下網(wǎng)絡波動、丟包、誤碼對視頻業(yè)務帶來的負面影響是當務之急。

【發(fā)明內(nèi)容】

[0012] 為了解決上述問題，本發(fā)明的目的在于提供一種寬帶集群呼叫業(yè)務的視頻流Q0s 控制方法，該方法能夠有效地解決B-Trunc單呼和組呼中網(wǎng)絡覆蓋、丟包、誤碼等引起的視 頻卡頓花屏的問題。
[0013] 本發(fā)明的另一目的在于提供一種寬帶集群呼叫業(yè)務的視頻流Qos控制方法，該方 法通過實時動態(tài)調(diào)整視頻碼流來進行擁塞控制和網(wǎng)絡監(jiān)控，能夠解決LTE容量受限、接入用 戶越多速度越慢的缺陷。
[0014] 為達到上述目的，本發(fā)明的目的是通過以下技術方案實現(xiàn)的。
[0 015 ] -種寬帶集群呼叫業(yè)務的視頻流Q 〇 s控制方法，其特征在于該方法對于I幀請求 (IR)，定義一個關鍵幀的最小發(fā)送間隔，超過這個頻率的I幀請求丟棄不處理;對于接收報 告(RP)，接收端周期性的發(fā)送自己收到的包數(shù)和丟掉的包數(shù)，主叫收到此報告后根據(jù)丟包 情況動態(tài)調(diào)整發(fā)送視頻流的碼率和幀率，分辨率不變。
[0016] 所述接收報告的發(fā)送周期根據(jù)需要的收斂速度設定，最好為l-4s。
[0017] 所述主叫收到IR報文后應該調(diào)用實時請求I幀的接口，要求編碼器結(jié)束當前編碼 序列，開始新的編碼序列，輸出IDR幀。
[0018] 進一步，所述IR報文收到多個時，主叫需要記錄上一個IDR幀編碼時間，設置一個 編碼保護期，在到期之前忽略IR報文，免得編碼器報錯。
[0019] 所述RP，主叫收到RP后，先緩存起來，然后周期性的處理，具體地說主叫終端需要 先緩存本周期內(nèi)收到的RP報文，然后周期性的統(tǒng)計所有的RP報文，計算出目標編碼參數(shù)。 [00 20]所述方法，使用RTP協(xié)議來傳輸I幀請求和接收報告，payload type取未定義的值， I幀IR請求為36、接收報告RP為37。
[0021] I幀請求報文占32比特，格式設計如表1所示：分0、1、2、3四個段，每個段有8個比 特；
[0022] 表 1
[0024] 接收報告報文內(nèi)容為丟包數(shù)和收包數(shù)，各占32比特，格式設計如表2所示：
[0025] 表 2
[0027] 具體地說，該方法的實現(xiàn)步驟包括：
[0028] 測試當前視頻的分辨率，找到最優(yōu)的編碼參數(shù)組合，劃分編碼參數(shù)組合表，并劃分 丟包率和編碼參數(shù)對應關系表；
[0029] 建立呼叫時，視頻呼叫初始化，使用編碼參數(shù)組合表的參數(shù)初始化媒體；
[0030] 接收媒體數(shù)據(jù)用戶統(tǒng)計接收到的rtp包數(shù)量即丟包誤碼的rtp包數(shù)量，周期性發(fā)送 RP報文給發(fā)送媒體數(shù)據(jù)用戶；
[0031] 發(fā)送媒體數(shù)據(jù)用戶收到RP報文后緩存起來，周期性處理；
[0032] 接收媒體數(shù)據(jù)用戶檢測到丟包或視頻解碼錯誤時，發(fā)送IR報文給發(fā)送媒體數(shù)據(jù)用 戶；
[0033] 發(fā)送媒體數(shù)據(jù)用戶收到IR報文，記錄當前時間time，假定上一次收到IR報文的時 間為time 1，比較time和time 1，如果time-time 1>編碼保護期，則修改當前編碼類型，編碼出 一個IDR幀發(fā)送出去。
[0034]所述的用戶收到RP報文后緩存起來，周期性處理，進一步包括:統(tǒng)計所有RP報文內(nèi) 容，計算平均丟包率，
[0035] 如果沒收到RP報文，平均丟包率= 10% ;
[0036] 如果收到 1 個RP報文，平均丟包率=lost/(lost+received)*100% ;
[0037] 如果收到多個RP報文，平均丟包率=(lostl+lost2+."+lostn)/(lostl+lost2+~ +lostn+receivedl+received2+---+receivedn)*100% ；
[0038] 然后根據(jù)丟包率和編碼參數(shù)對應關系表計算出當前平均丟包率對應的編碼參數(shù) 組合，假定為mark，假定上一次使用的編碼組合為markl，比較mark和markl:
[0039] 如果markl為-1，表示是第一次調(diào)整，當前編碼參數(shù)調(diào)整為mark;
[0040] 如果mark小于markl，當前編碼參數(shù)調(diào)整為markl-1;
[0041 ] 如果mark等于markl，當前編碼參數(shù)調(diào)整為markl+1;
[0042] 如果mark大于markl，當前編碼參數(shù)調(diào)整為markl+2;
[0043] 另外，當LTE網(wǎng)絡波動導致一段時間內(nèi)未收到RP報文時，按照丟包率>10的情況來 處理。
[0044] 本發(fā)明的技術效果是：
[0045] 1、用周期性反饋信息的方法來提供數(shù)據(jù)的傳送質(zhì)量，這種反饋可以用來進行流量 的擁塞控制，也可以用來監(jiān)視網(wǎng)絡和用來診斷網(wǎng)絡中的問題，另外還可以保證LTE無線鏈路 不進入IDEL態(tài)；
[0046] 2、當被叫端視頻解碼報錯時，傳輸一個IR給主叫，此種方法對H264碼流的快速恢 復有非常重要的作用。
[0047] 3、根據(jù)LTE無線網(wǎng)絡及視頻業(yè)務類型（比如全雙工視頻單呼、視頻組呼、視頻上拉 等)調(diào)整RP包的發(fā)送頻率。
[0048] 4、特別適用于實現(xiàn)LTE無線環(huán)境下的媒體流擁塞控制和視頻圖像的快速刷新。
【附圖說明】
[0049] 圖1為本發(fā)明所實施RP報文發(fā)送流程圖。
[0050] 圖2為本發(fā)明所實施RP報文接收處理流程圖。
[0051]圖3為本發(fā)明所實施IR報文發(fā)送流程圖。
[0052]圖4為本發(fā)明所實施IR報文接收處理流程圖。
【具體實施方式】
[0053] 為了使本發(fā)明的目的、技術方案及優(yōu)點更加清楚明白，以下結(jié)合附圖及實施例，對 本發(fā)明進行進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并 不用于限定本發(fā)明。
[0054] 以下分別以全雙工視頻單呼和同源視頻組呼場景為例說明使用步驟。
[0055] 步驟一、根據(jù)測試結(jié)果找到最優(yōu)的編碼參數(shù)組合，給當前視頻使用的三種分辨率 (cif、vga和720p)劃分編碼參數(shù)組合表，如表3所示，其中幀率單位為fps，碼率單位為kbps。
[0057] 表 3
[0058] 根據(jù)測試結(jié)果，劃分丟包率和編碼參數(shù)對應關系表，如表4:
[0060]表 4
[0061 ]步驟二、建立呼叫時，視頻呼叫初始化使用某一組編碼參數(shù)組合表的參數(shù)初始化 媒體。
[0062]步驟三、接收媒體數(shù)據(jù)用戶統(tǒng)計接收到的rtp包數(shù)量即丟包誤碼的rtp包數(shù)量，周 期性(I -4s)發(fā)送RP報文給發(fā)送媒體數(shù)據(jù)用戶。
[0063]步驟四、發(fā)送媒體數(shù)據(jù)用戶收到RP報文后緩存起來，周期性（l_4s)處理。統(tǒng)計所有 RP報文內(nèi)容，計算平均丟包率。（在單呼場景，周期內(nèi)只會收到1個RP報文，在組呼場景，可能 收到η個RP報文，如果丟包也可能收到0個RP報文）
[0064] 如果沒收到RP報文，平均丟包率= 10% ;
[0065] 如果收到 1 個RP報文，平均丟包率=lost/(lost+received)*100% ;
[0066] 如果收到多個RP報文，平均丟包率=(lostl+lost2+."+lostn)/(lostl+lost2+~ +lostn+receivedl+received2+---+receivedn)*100% ；
[0067] 然后根據(jù)丟包率和編碼參數(shù)對應關系表計算出當前平均丟包率對應的編碼參數(shù) 組合，假定為mark，假定上一次使用的編碼組合為markl，比較mark和markl:
[0068] 如果markl為-1，表示是第一次調(diào)整，當前編碼參數(shù)調(diào)整為mark;
[0069] 如果mark小于markl，當前編碼參數(shù)調(diào)整為markl-1;
[0070] 如果mark等于markl，當前編碼參數(shù)調(diào)整為markl+1;
[0071 ] 如果mark大于markl，當前編碼參數(shù)調(diào)整為markl+2;
[0072]另外，當LTE網(wǎng)絡波動導致一段時間內(nèi)未收到RP報文時，按照丟包率>10的情況來 處理。
[0073] 步驟五、接收媒體數(shù)據(jù)用戶檢測到丟包或視頻解碼錯誤時，發(fā)送IR報文給發(fā)送媒 體數(shù)據(jù)用戶；
[0074] 步驟六、發(fā)送媒體數(shù)據(jù)用戶收到IR報文，記錄當前時間time，假定上一次收到IR報 文的時間為time 1，比較time和time 1，如果time-time 1>編碼保護期，則修改當前編碼類型， 編碼出一個IDR幀發(fā)送出去。
[0075]如圖1所示，RP報文發(fā)送流程為：
[0076]開始視頻呼叫，統(tǒng)計收到的視頻包數(shù)量和丟失的視頻包數(shù)量，接收媒體數(shù)據(jù)用戶 檢測到丟包或視頻解碼錯誤時，發(fā)送RP報文給發(fā)送媒體數(shù)據(jù)用戶，如此不斷循環(huán)。該流程周 期性進行處理，通常一個周期為l_4s。
[0077]圖2所示，RP報文的接收處理流程為：
[0078]開始視頻呼叫，接收RP報文并進行緩存，然后解析所有收到的RP報文，并根據(jù)上述 步驟四的方式動態(tài)調(diào)整編碼參數(shù)，如此循環(huán)執(zhí)行，該流程周期性進行處理，通常一個周期為 l-4s〇
[0079]圖3所示，IR報文發(fā)送流程為：
[0080]開始視頻呼叫，判斷是否I幀丟包，如果是，則發(fā)送IR報文，如果否，則不進行處理。 [0081]圖4所示，IR報文的接收處理流程為：
[0082] 開始視頻呼叫，接收IR報文，記錄當前時間time;判斷IR報文是否大于編碼保護 期，如果大于編碼保護期，則修改當前編碼類型，編碼出一個IDR幀發(fā)送出去;如果小于編碼 保護期，則忽略IR請求。
[0083] 在本發(fā)明的實施中，視頻上拉流程和集群呼叫流程類似，區(qū)別是集群呼叫的視頻 流是雙向的，而視頻上拉的視頻流是單向的，僅僅是終端發(fā)給調(diào)度臺。
[0084] 以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精 神和原則之內(nèi)所作的任何修改、等同替換和改進等，均應包含在本發(fā)明的保護范圍之內(nèi)。
【主權項】
1. 一種寬帶集群呼叫業(yè)務的視頻流Qos控制方法，其特征在于該方法對于I幀請求，定 義一個關鍵幀的最小發(fā)送間隔，超過這個頻率的I幀請求丟棄不處理;對于接收報告，接收 端周期性的發(fā)送自己收到的包數(shù)和丟掉的包數(shù)，主叫收到此報告后根據(jù)丟包情況動態(tài)調(diào)整 發(fā)送視頻流的碼率和幀率，分辨率不變。2. 如權利要求1所述的寬帶集群呼叫業(yè)務的視頻流Qos控制方法，其特征在于所述接收 報告的發(fā)送周期根據(jù)需要的收斂速度設定，為l-4s。3. 如權利要求1所述的寬帶集群呼叫業(yè)務的視頻流Qos控制方法，其特征在于所述主叫 收到IR報文后應該調(diào)用實時請求I幀的接口，要求編碼器結(jié)束當前編碼序列，開始新的編碼 序列，輸出IDR幀。4. 如權利要求3所述的寬帶集群呼叫業(yè)務的視頻流Qos控制方法，其特征在于所述IR報 文收到多個時，主叫需要記錄上一個IDR幀編碼時間，設置一個編碼保護期，在到期之前忽 略IR報文。5. 如權利要求1所述的寬帶集群呼叫業(yè)務的視頻流Qos控制方法，其特征在于主叫終端 收到RP后，先緩存本周期內(nèi)收到的RP報文，然后周期性的統(tǒng)計所有的RP報文，計算出目標編 碼參數(shù)。6. 如權利要求1所述的寬帶集群呼叫業(yè)務的視頻流Qos控制方法，其特征在于，使用RTP 協(xié)議來傳輸I幀請求和接收報告，payload type取未定義的值。7. 如權利要求1所述的寬帶集群呼叫業(yè)務的視頻流Qos控制方法，其特征在于該方法的 實現(xiàn)步驟包括： 測試需要使用的各種視頻分辨率，劃分編碼參數(shù)組合表，并劃分丟包率和編碼參數(shù)對 應關系表； 建立呼叫時，視頻呼叫初始化，使用編碼參數(shù)組合表的參數(shù)初始化媒體； 接收媒體數(shù)據(jù)用戶統(tǒng)計接收到的rtp包數(shù)量即丟包誤碼的rtp包數(shù)量，周期性發(fā)送RP報 文給發(fā)送媒體數(shù)據(jù)用戶； 發(fā)送媒體數(shù)據(jù)用戶收到RP報文后緩存起來，周期性處理； 接收媒體數(shù)據(jù)用戶檢測到丟包或視頻解碼錯誤時，發(fā)送IR報文給發(fā)送媒體數(shù)據(jù)用戶； 發(fā)送媒體數(shù)據(jù)用戶收到IR報文，記錄當前時間time，假定上一次收到IR報文的時間為 time 1，比較time和time 1，如果time-time 1>編碼保護期，則修改當前編碼類型，編碼出一個 IDR幀發(fā)送出去。8. 如權利要求7所述的寬帶集群呼叫業(yè)務的視頻流Qos控制方法，其特征在于所述的用 戶收到RP報文后緩存起來，周期性處理，進一步包括：統(tǒng)計所有RP報文內(nèi)容，計算平均丟包 率， 如果沒收到RP報文，平均丟包率=10 % ; 如果收到1個RP報文，平均丟包率= l〇st/(lost+received)*100% ; 如果收到多個RP報文，平均丟包率=(l〇stl + lost2+"_ + lostn)/(lostl + lost2+~ + lostn+receivedl+received2+---+receivedn)*100% ； 然后根據(jù)丟包率和編碼參數(shù)對應關系表計算出當前平均丟包率對應的編碼參數(shù)組合， 假定為mark，假定上一次使用的編碼組合為markl，比較mark和markl: 如果markl為-1，表示是第一次調(diào)整，當前編碼參數(shù)調(diào)整為mark; 如果mark小于markl，當前編碼參數(shù)調(diào)整為markl-1; 如果mark等于markl，當前編碼參數(shù)調(diào)整為markl+1; 如果mark大于markl，當前編碼參數(shù)調(diào)整為markl+2。9.如權利要求8所述的寬帶集群呼叫業(yè)務的視頻流Qos控制方法，其特征在于當LTE網(wǎng) 絡波動導致一段時間內(nèi)未收到RP報文時，按照丟包率>10的情況來處理。
【文檔編號】H04L29/06GK105915904SQ201610343693
【公開日】2016年8月31日
【申請日】2016年5月23日
【發(fā)明人】董新平, 尹尚國, 余西, 王小平
【申請人】北京中興高達通信技術有限公司