IPTV前端概述
       本文將重點討論IP前端系統。一個IP前端的主要功能如下：
       數字節目采集：來自衛星或地面的節目源，以及為將這些內容進行數字傳送（全國的或本地的）所做的準備。
       數字節目存儲：保存并插入其它的非實況廣播電視節目，例如本地內容、視頻點播或廣告節目等。
       數字節目分配和傳送：將各類節目綜合在一起，并進行速率調整、調制、封裝（編碼）、加密和其它技術處理，以用于節目傳送。
       在這樣的前端系統中，需要通過各種方式采集大量的節目，例如來自有線、衛星或地面無線廣播電視等各種RF源信號，也可能有使用SDI或IP接 口傳送來的節目。在多種信號格式輸入并采用多種接口（如IP、SDI和RF接口）的情況下，為使系統提供可靠的、高質量的IPTV服務，就要對那些可能會對系統的完整性帶來影響的一些重要因素予以足夠的重視。因此，在對前端信號作進一步處理以及將信號送往電信網絡之前，對被采集信號實行QoS監視就是十分必要的。為了保證質量，可利用全面的監視，如圖1“關鍵監視點”中，給出了一些重要的信號監視點。
       前文提及的前端的三項主要功能在本文中可分別進行考慮，實際上，僅用一個單獨的硬件組合，就可以進行多項處理。由于我們前端節目內容的主要部分來自地面電視和衛星的射頻節目，我們必須著重考慮如何確定并保持地面和衛星信號的質量。以下將介紹一些關鍵的RF測量，這樣我們就能夠在觀眾無法正常收看節目之前及時發現問題。

IP廣播電視輸出—關鍵監視參數
      電信運營商面臨的重大運營挑戰是如何有效地提供優異的服務質量（QoS）等級，使他們能夠在當今競爭激烈的市場中保持他們的優勢地位。因此，提供一種直觀而又簡明的視頻質量和診斷信息顯示，為在日益復雜的廣播電視環境中提交優異的服務質量提供支持成為一項重要的需求。為了獲得高等級的QoS，我們必須為運營商和工程技術人員提供準確而又及時的系統性能信息。
     我們已經認識到，為了保持系統的高性能等級，必須提高我們系統的服務質量。但問題是，在IP環境中，當我們談及服務質量時它究竟指的是什么？

什么是QoS？
     服務質量，即QoS，從技術觀點來看，在ITU標準X.902中定義為“對一個或多個對象集體行為質量要求的集合”。在網絡通信工程中，QoS可以用來為不同的數據流提供不同的優先級，或者說，為某一數據流提供某種性能等級的保證。在IPTV系統中，這種優先級對于實現良好的質量視頻傳送是十分重要的。
  ‘QoS的主要目標是提供包括專用帶寬、可受控的抖動和時延……以及改善的損耗特性的優先級。’

關鍵性能指標
     如果對上述定義作進一步的說明，很明顯，當我們談及QoS時，必然涉及到服務提供商支持用戶需求的能力，這至少包括以下4個方面：
        帶寬
        等待時間或延遲
        抖動
        通信業務量損失
     如果對這4個方面作更細致的說明，還可以作如下表述：
        帶寬- 網絡應當具有足夠的通信容量以支持用戶對業務吞吐量的需求。
        等待時間或延遲- 將任意數據包從某一給定的傳輸節點發送到另一給定的接收節點的所需時間。
        抖動 - 數據包到達接收節點期間延時量的變化。
        通信量或數據包丟失- 多長時間丟失一次數據包？- 受影響的數據包有多少？

     以上4個方面可以稱為KPI（關鍵性能指標），它常用來測量傳輸系統的性能。現在我們知道我們能夠測量什么，但問題是我們為什么要測量？
IPTV系統是建立在一個“盡力傳送”的網絡上，因為按照定義，IPv4和IPv6協議是“盡力傳送”的傳輸系統協議。這兩個協議均依賴于其它協議如TCP的支持，才能為用戶提供QoS服務。然而，一個簡單的事實是數據和話音業務可以在有抖動和延遲的情況下正常地復制，但是視頻業務卻不能這樣處理。視頻業務是按照UDP/RTP協議傳送的，它要求網絡有較高的可用性（帶寬和時間），并要求執行強健的網絡管理機制。在一種“盡力傳送”的網絡中它是不能正常傳送的，因為攜帶視頻數據的IP包不能準時并按照正確的順序依次到達接收節點。這就給我們帶來一個問題，我們怎樣才能有效地檢測IPTV傳送網絡中所出現的問題。
     前面我們已經將可以用來監視系統QoS的關鍵性能指標歸結為4項，其中有關帶寬的含義還可以討論，在系統的設計階段就應當考慮到該系統能否提供適當的通信業務量管理機制。我們所進行的運行測量，例如在網絡中任一節點處測量當前的話路數以及每一話路或所有話路的占用帶寬是非常有用的，可以把這些測量結果作為當前系統是否過載的指示。通過監視其它參數以獲知問題的癥狀表現，就能夠對任何過載進行預測。這些監測參數包括了前文所提及的另外三項關鍵性能指標。
     在其它的三項關鍵性能指標中，前兩項是很難分開的，即時間等待/延時和IP抖動這兩項。應當對鏈路中所有話路的這兩項指標進行監視。作為一個例子，我們考慮傳送某一個4.7Mb/s傳送流的單個話路：

     假定每幀含有7個MPEG包，即每幀共有7×188字節=1316字節

     假定以太網幀采用IP/UDP/RTP封裝，那么該以太網幀的大小為1370字節，對應的以太網的比特速率為4.886Mb/s：
     以太網速率（每秒傳送的以太網幀數）=4886000[比特率]/(8[每字節的比特數]×1370[每幀字節數])=445.80幀/秒
     幀之間的時間間隔為1/445.8[以太網幀速率]=0.00224秒
     這就是說，理想的包到達時間應當是2.24ms。偏離這一理想值的任何變動均可能給接收設備帶來數據緩沖問題。即便是固定的偏離也會有問題。不過IP包之間的可變定時即所謂IP抖動，如果尚未診斷出并且未被糾正的話，可能會引起更為嚴重的問題。IP包抖動對終端用戶的影響與網絡的設計部件例如路由器中緩存的容量大小有關，而且終端用戶的接收設備采用什么樣的設計方案也會對他接收的QoS帶來明顯的影響。如果用戶的機頂盒采用了容量較大的輸入緩存器，那么可能會消除大多數網絡抖動帶來的影響。然而，與那些較為保守的設計方案相比較，這種大容量緩存器的設計方案肯定會提高成本。因此，更可取的方案是測量并消除網絡中的任何過大的IP包抖動。我們設置的網絡監測點應當能夠在較長的時間段內進行測量并能夠顯示數據包到達時間間隔（PIT）的變化，以確保不會給用戶帶來潛在的質量問題而引起用戶的抱怨。

圖2 包到達時間間隔的圖示

     能否準確地測量并顯示網絡中的PIT是能否對該網絡實行良好的診斷和管理的一個關鍵。在圖2中，給出了包到達時間間隔的圖示。
     在監測儀器中可以設置包到達時間間隔的容限區（圖2中的紅區），由圖2可見，在剛過去的一段時間內，有幾處的PIT指示進入了容限區。這種簡明的圖形顯示給運營商或工程師提供了一種快速、便捷的方法，從而能夠了解該網絡的QoS相關重要信息，并可據此采取相應的校正措施。

跨層定時問題
     在通過IP網絡傳送MPEG流的過程中，這里還有一個相關聯的、有時卻被忽略的問題，即這些傳送流包還要被封裝到IP包（更確切地說，是UDP包或基于UDP協議的RTP包）中。通常情況下，每一IP包中含有7個TS包。這樣，在處理某一IP包時，會影響到在同一時間進入到MPEG解碼器端緩存器中的所有7個TS包。由于這些TS包在緩存器的輸入端均具有相同的到達時間標記，那么，任何攜帶有PCR信息的TS包的時間標記均會出現錯誤，這將對PCR的定時測量帶來影響。
     PCR準確度（PCR_AC）與到達時間無關，因此它不會受到影響。然而，PCR漂移率（PCR_DR）、頻率偏置（PCR_FO）和總抖動（PCR_OJ）卻與到達時間相關。基于IP的視頻解碼器把經過緩存后輸出的IP包送入到MPEG解碼器，在MPEG解碼器中將數據流恢復為恒定的比特率。使用泰克公司MPEG傳送流符合性分析儀并開啟PCR內插值時可以模擬這一過程，它會把一個IP包中的多個TS包展開到兩個IP包之間的時間段內。
     還有一點值得注意的是，在可變比特率的碼流中是無法進行PCR測量的。這是因為在不能為每個TS包繼續提供定時信息的情況下，重建TS包的到達時間也是不可能的。
     為了確保良好的視頻質量，即使有了正確的PCR定時也是不夠的。利用PCR可以使解碼器的系統時鐘與編碼器的系統時鐘保持同步，在一般情況下，通過插入在打包的基本流（PES）包頭中的顯示時間標記（PTS）來實現幀同步。PTS是一個33比特的數值，它以90kHz時鐘頻率（27MHz時鐘除以300）為計時單位。PTS值指示的是數據幀在解碼器端的顯示時間。解碼器端與編碼器端的PCR以及二者之間的PTS/DTS均應當始終保持同步關系，如果解碼器端與編碼器端的PCR或PTS數值出現了任何變化，均可能造成緩存器的上溢或下溢，這樣就會引起諸如彩色丟失之類的解碼錯誤，這些錯誤是很容易被觀眾察覺的。實踐證明，為了解決系統的定時故障，進行跨層時間相關的定時測量，如PIT、PCR和PTS定時測量等是十分有用的。

圖3 RTP包統計圖示

     接著我們還要討論下一項KPI指標即數據包丟失。前文我們已經提到了路由器的緩存容量問題，正是網絡路由器輸出端口的緩存器問題可能會引起數據包的丟失。特別是處于網絡集聚點的路由器，當進入該路由器端口的數據量接近它的緩存器的最大輸入容量時，將會因為路由器緩存數據的溢出而導致其輸出接口處的包丟失。雖然這一過程也許不是一個瞬時事件，然而卻會造成數據通信量的逐步增加，這種情況通常會出現在傍晚電視收看的高峰時段。如果沒有適當的通信業務量管理機制和通信量儲備，或者通信量的儲備已被耗盡，那么數據包的丟失可能會通過網絡擴散而激增，從而影響到終端用戶的觀看效果。正因為如此，網絡監視系統的一項基本功能就是必須能夠發現包丟失或包無序的錯誤。如圖3所示，監視系統提供了RTP包的統計數據。由網絡引入的延時會導致包無序，不過，如果終端用戶的接收設備采用了大容量的緩存器，它能在機頂盒中對數據包重新排列并恢復數據包的正常順序，從而可以消除包延時帶來的影響。盡管如此，監視設備必須能夠檢測到包無序事件并能夠及時地為運營商和工程師提供診斷信息，以便在用戶抱怨之前排除這種故障。

媒體交付指數（Media Delivery Index）
     包延遲和包丟失均已納入IETF RFC 4445的定義之中，RFC引入了媒體交付指數（MDI）的概念，并將它定義為單一的品質因數，它可用來量化兩類IP傳輸損傷，即包抖動（或包延遲）以及包丟失。可以把這兩個測試參數定義為媒體延遲因子（Media Delay Factor，MDI-DF）和媒體丟失率（Media Loss Rate，MDI-MLR）。
     延遲因子用來指示在正常比特率下必須緩存（即延遲）多長（多少比特）的數據流以防止包丟失。
     媒體丟失率是在1秒的周期內丟失的數據包數。
     盡管MDI已普遍地為業界所接受，并將它作為“事實上”的包延遲和包丟失的測量項目，然而它并非是沒有任何問題的。其中一個主要問題是MDI沒有考慮被測IP包中的有效載荷。這就是說，無論IP包的有效載荷是什么，是音頻，是數據還是視頻，它均用同樣的方式予以處理。這樣，當通信業務是按照基本UDP協議（也即非RTP協議）傳輸時，這個問題就暴露出來了。在原始的UDP協議中，并沒有提供檢測包丟失的任何方法。因此，對于原始的UDP協議，MDI的包丟失部分必須從MPEG的連續性計數錯誤的指示中導出。至于任何其它錯誤，例如傳送流的語法錯誤，則是MDI無法檢測的。

結語
     很明顯，通過IP網絡傳送高質量的數字視頻是一項富有挑戰性的任務。細分后的IP業務，如高速數據、VolP和視頻有著完全不同的帶寬和QoS需求。傳輸視頻需要高度的可用性（帶寬和時間），它要求執行強健的網絡管理機制以及采用適當的監視工具，以確保24/7全天候地保持這種傳輸管理機制。可以看出，IP視頻不能幸存在“盡力傳送”的環境中——視頻包必須順次到達且無丟失。
     如果要在這樣的環境中傳輸視頻，必需使用測試設備，并在整個網絡中正確地配置儀器監測點的位置，用來提供系統的KPI重要數據。利用這種方法，運營商和工程師就能夠有效地管理好網絡系統，防止信號質量的劣化，避免可能影響終端用戶觀看體驗的錯誤發生。
泰克公司的MTM400A傳送流監視器為基于RF、IP和ASI接口的MPEG傳送流的實時傳送流監視提供了完整的解決方案。它將強大的置信度監視功能和深入的診斷測量組合在一起，成為單一的整體解決方案。它具有獨特的FlexVuPlus用戶接口，可以提供視頻質量和診斷信息的簡明指示，從而能夠在日益復雜的廣播電視傳輸環境中確保優異的QoS等級。