Speaker:尹培鑫 指導教授:吳和庭 教授 DVB-H介紹 Speaker:尹培鑫 指導教授:吳和庭 教授

DVB-PROJECT-(I) DVB, Digital Video Broadcasting，是由「DVB Project」維護的一系列為國際所承認的數位電視公開標準。「DVB Project」是一個由300多個成員組成的工業組織，它是由歐洲電信標準化組織（European Telecommunications Standards Institute, ETSI）、歐洲電子標準化組織（European Committee for Electro technical Standardization, CENELEC）和歐洲廣播聯盟（European Broadcasting Union, EBU）聯合組成的「聯合專家組」（Joint Technical Committee, JTC）發起的。幾項DVB子標準的關係在《DVB指南》（DVB-Cook）中描述之。

DVB-HISTORY

Mobile TV 系統狀況 Region Fixe Standard Portable/Mobile Standard Europe DVB-T DVB-H Korea ATSC T-DMB Japan ISDB-T ISCB-T(1-seg) North America DVB-H/MediaFLO China DMB-T DMB-TH/CMMB India Taiwan

DVB/T

DVB-PROJECT-(II) DVB系統傳輸方式有如下幾種： 衛星電視（DVB-S 及 DVB-S2） 有線電視（DVB-C） 無線電視（DVB-T） 手持式數位視訊廣播（DVB-H）

What is DVB-H?-(I) DVB-H標準全名稱爲Digital Video Broadcasting -Handheld 。 針對手持終端機提供多媒體服務所制定的傳輸標準，也是DVB-T標準的延伸及擴展應用 。 DVB-H終端機，適用於行動電話、手持電腦及PDA 通過地面數位電視廣播,可接收IP及電視信號. 在進行IP廣播時,所有內容均以IP資料封包的形式發出。

What is DVB-H?-(II)

What is DVB-H?-(III)

New features in DVB-H OFDM 4K mode In-depth interleaving Inner interleaver exchange data in 8 k range Additional info in TPS(Transmission Parameter Signaling) to singal 4k mode Time-slicing MPE-FEC

DVB-H PSI/SI Information PSI (Program Specific Information): 節目特定資訊, defined in MPEG-2 SI (Service Information): 服務資訊, defined in DVB 縮寫 全名 PID table_id PAT Program Association Table 0x0000 0x00 PMT Program Map Table * 0x02 NIT Network Information Table 0x0010 0x40 INT IP/MAC Notification Table 0x4C SDT Service Description Table 0x0011 0x42

PSI/SI表格用途 縮寫 用途說明 PAT 列出傳輸串流中所有的節目，並提供每一個節目對應的 PMT表格的PID。 PMT 其他描述(descriptors)。 NIT 描述網路的特徵、傳輸參數，以及服務的類型。 INT 說明PID、service_id 與IP addresses (及port numbers)相互 對應之關係。 說明MPE (MPE-FEC) section 的 Row no. SDT 提供每一個服務更進一步的資訊，包含time-slicing資訊。

DVB-H的ID id 存在/定義 用途 PID MPEG-2 TS packet header MPEG-2 TS packet的識別碼 network_id 由NIT定義 網路編號(network provider 的識別碼) transport_stream_id 由PAT定義 TS的識別碼 (一個network provider可能會提供好幾條TS) platform_id 由INT定義 IP/MAC platform 的識別碼 service_id 由NIT(PMT)定義 節目(即服務) 的識別碼 = program number in PMT。 table_id first byte of a section section的識別碼

DVB networks

PSI/SI 首先必須先解析Program Association Table (PAT)表，並由表中得知每一個節目的Program Map Table(PMT)表單 是由哪組傳輸串流Packet Identifier(PID)所表示，再經由傳輸串流中找出PMT表，依據PMT表中的資料廣播識別描述子是屬於IP/MAC Notification Table(INT)表或是MPE表單，再逐步解出INT表與MPE表，並分別將其值記錄於IP資料結構表與MPE資料結構表中

MPE-FEC 最後在回到框架左上角，再以行的順序依序輸出各個的IP資料封包且封裝成MPE Section。而RS data table則以每行為單位(1024 or 768 or 512 or 256)，依序的封裝成MPE-FEC Section。如此一來，讓原本RS編碼後所形成的碼字位元組(Codeword)的各個位元組在時間軸上被分散傳輸，達到時間間插的效果。 若緊接而來的封包長度大於剩餘的空間位元組長度，則將此IP封包資料儲放至緩衝區，留待在下一個MPE-FEC框架再填裝。若是所有IP封包資料均已填入但仍有部分的Application data table未填入IP資料封包時，則進行填塞機制，將 未被填入的位元組以0填入，直到完整填滿Application data table為止。

Time Slicing-(I) DVB-H DVB-T DVB-H Time Slices Regular DVB-T Multiplex(TV) Sleep Mode Always ON – 沒用到的DATA則忽略掉 data data

Time Slicing –(II) Maximum Burst Duration是Burst最大的持續時間，此資訊被實作在於PSI/SI表單之中告知接收端。為確保接收端可靠的識別每一個Burst，下一個Burst不應在目前的Maximum Burst Duration時間內傳送，即目前的Burst中所夾帶的Delta-T所指示的時間應超過Maximum Burst Duration的區間。藉由以上的三個時間參數，接收端便能正確的由Timer-Slicing的服務中將Burst資料接收並組回MPE-FEC框架資料。

DVB-H Bootstrap

DVB-H IPDC Protocol

RTP RTP(real-time transport protocol) 用來攜帶具有即時特性的資料 包含Sequence number 和 timestamp 不保證QoS Router不能辨識RTP

RTP Format (Ver)Version : (PT)Payload type: 0x2 (P)Padding: In use = 1 ; otherwise = 0 (X)Extension: In use = 1; otherwise = 0; (CC)CSRC count: # of CSRC (M)Marker: Frame boundary (PT)Payload type: GSM,LPC,MPEG audio,H.264,etc Sequence Number: 每送一個RTP封包則加一 Timestamp: Time instance of First byte in RTP packet Synchronization source identifier (SSRC): Identify source of RTP stream; Each stream in RTP session has distinct SSRC SSRC is randomly assigned CSRC: Source identifier

RTP Header Extension 如果(X)值為一，表示在RTP Header後CSRC正後方 用來給應用程式新增其他所需要的資訊，而Length欄 為除了前面保留的4個Bytes之外，之後有幾個words Defined by Profile的欄位則保留給要用的應用程式定義

RTCP RTCP(RTP control protocol) in DVB-H 用來監控服務的品質，並傳達會議中的參與者的資料 在DVB-H中 RTCP是用來做Lip Sync 提供Audio 和 Video 對應的Wall clock 和time stamps 只需要考慮到Sender report RTCP Port number = RTP Port number +1

RTCP Sender Report Packet 正常來說分為四個部分 Header Sender Info 零到多個Report Block 延伸出來的部分 但是後面兩塊在DVB-H中是沒再用的 由於主要的用途為做Sync 最主要的欄位就是看Time Stamp NTP timestamp : timestamp of wall clock MS word = sec; LS word = 2的-32次方sec RTP timestamp : 與NTP timestamp對應的RTP time stamp， 就是說這個時間是以NTP的時間為基礎再使用 RTP的時間COUNT計算出來的時間 把兩個時間做比較用來做同步

FLUTE Basic File Delivery over Unidirectional Transport (FLUTE) protocol RFC 3926 [1] 單向檔案傳輸 檔案被當成一個物件再傳送，也許內容可以會經過一些編碼(e.g. gzip) Distribution to large number of receivers可以發送給大量的接收者 接收端不用回傳，所以接收端可以說是沒有限制的，不管是幾萬個還是幾百萬個都沒有問題 支援IPv4 和 IPv6 在Flute的Header並沒有特別關於IP version的部分 在Multicast 和 unicast下的UDP傳輸都適用 特別是適用於multicast networks Supports Any Source Multicast(ASM) and Source Specific Multicast(SSM) models 透過Retransmissions和Forward Error Correction機制來保證其可靠度

FLUTE Building Block Structure FLUTE是建構於另一個 IETF 通信協定 - ALC (Asynchronous Layered Coding,非同步分層編碼) 之上發展的ALC，甚至可以說ALC才是FLUTE的主體 ALC與FLUTE的差別 ALC是一套單向的”Object”多點傳送通訊協定 FLUTE是一套單向的”FILE”多點傳送通訊協定 因為Object本身不具有任何的attribute,所以Flute針對這點擴充，將Object當作檔案來傳送，並且加上屬性；e.g.檔案名稱 ,類型,長度；存放屬性的表格為FLUTE定義的FDT Instance中 ALC包含了三個Building Block: LCT ,CC.FEC等部分Building Block LCT為ALC的主體，負責Session management部分 CC為Optional的功能，不過在DVB-H中不會有壅塞的機會發生故不使用。 DVB-IPDC CDP 標準中,僅定義了兩種 FEC 組成元件,第一種是必備的 Compact No-Code FEC (意即沒有 FEC),第二種則是非必備的 Raptor FEC。

FLUTE Session 一個FLUTE session代表一個FLUTE傳送端在一個時間間隔內傳送一群物件的行為 FLUTE session的ID是由傳送端的IP加上TSI組成 一個session內會有一個或多個channel Channel 來源IP是傳送端，但不同的channel會有各自的目標IP和Port，而其中傳送的封包之IP與PORT都會與channel相同 FLUTE 接收端可以選擇加入一個FLUTE Channel來接受封包 要停止接收封包的方式則是離開這個Channel 傳送的每個檔案都是一個ALC 物件(每個物件都會有UNIQUE的TOI (Transport Object ID)) File Delivery Table (FDT)是一個資料結構，裡面記錄了被傳送的ALC物件的檔案屬性用以接收端可以靠這些資訊辨識，定位，和回覆這些檔案，至於如何將FDT傳送之接收端則需要靠FDT Instance 檔案ID 檔案內容 檔案編碼方式 檔案原始長度 檔案編碼後的長度 檔案安全資訊 FDT Instance 的TOI值永遠為0，裡面包含此session部分或全部的檔案資訊，且可以在此session中重複被傳送，為了區別同一個session傳送的FDT Instance，LCT有擴充的Header來記錄其FDT instance ID,所以TOI=0才會有這個擴充的Header

FLUTE Session Channel 物件、檔案、FDT Instance … Flute/ALC/LCT Session 由於FLUTE/ALC原本是設計在Internet上使用的，因此，一個 FLUTE session可提供多個傳輸率不同的FLUTE channel，讓FLUTE接收端依其接收狀況與合適的傳輸率，選擇要接收哪些FLUTE channel。不過，在 DVB-H廣播網路上，由於每個FLUTE接收端的接收狀況，遠比在Internet上要相近得多，因此，DVB-IPDC CDP標準，只把FLUTE session僅包含一個 FLUTE channel的選項，定義為FLUTE傳送端與FLUTE接收端必備的功能。至於FLUTE session內包含多個FLUTE channel，僅被定義成一種選擇性的功能。 FLUTE session的SDP檔案中，第一個出現的 FLUTE channel，稱之為基礎FLUTE channel(base FLUTE channel)。由於FLUTE接收端可能僅能接收基礎FLUTE channel，因此，若FLUTE傳送端希望在一個FLUTE session內，包含一個以上的FLUTE channel，FLUTE 傳送端必須能確保前述的FLUTE接收端，可以透過基礎FLUTE channel收到足夠的資料。另外，在基礎FLUTE channel內所傳送的FDT insatnce，也不能包含在其他FLUTE channel內傳送之ALC物件的屬性。  Flute/ALC/LCT Session Channel … 物件、檔案、FDT Instance Packet

FLUTE session 參數 FLUTE標準(RFC 3926)中，只提出了FLUTE session傳輸參數應包含的種類 FLUTE session傳送端的IP位址 FLUTE session的TSI  FLUTE session所包含的FLUTE channel數 每個FLUTE channel的目的IP位址與Port number FLUTE session的開始與結束時間 FLUTE session或FLUTE channel預設的FEC演算法  但是在RFC3926中並無明確定義用什麼方式去記錄這些參數，所以在DVB-IPDC CDP標準中，定義了基於SDP(Session Description Protocol)

SDP(Session Description Protocol) Type Description Example v protocol version v=0 o originator and session identifier o=1221269…, IN IP4 192.168.16.23 s session name s=EinsExtra i session information i=Live TV-Stream EinsExtra c connection information c=<nettype><addrtype> <connection-address> c=IN IP4 228.228.1.3/3 Internet IPv4 destination IP/time to live/(number of addresses) m media name and transport address m=<media> <port> <transport protocol> <format> ... format 96-127 is defined dynamically. Therefore, attribute fields must be parsed m=video 6000 RTP/AVP 96 m=audio 6002 RTP/AVP 97 6000,6002代表port numbers RTP/AVP: RTP Audio/Video Profile 96,97代表RTP payload types a attributes a=<attribute>:<value> a=rtpmap (rtp payload type map) a=fmtp (format parameter) a=source-filter(IP address) a=flute-tsi(TSI of this session) a=FEC-delclaration (FEC format) a=content-desc(傳送目的位址) a=rtpmap:96 H264/90000 format (rtpmap) 96: H.264 with clock rate 90 kHz. a=fmtp:96 packetization-mode=1; profile_level_id=42e00c; … more descriptions about format 96

SDP Example

FDT instance Example 一個FDT-Instance可以描述全部或是部分這個FLUTE session

FLUTE Header V:為ALC與LCT的版本號碼，目前版本(RFC 3450) 的值為1。 C(CC flag)與CCI:C的值決定CCI的長度 ,C=0則CCI 32bit ;C= 1,CCI = 64bit…但是DVB-H不做CC所以用不到，但是根據DVB-IPDC CDP規定CCI = 32bit , C = 0; R(reserved): 值為0 S(TSI flag): TSI length = 32 * S + 16 *H O: TOI length = 32*O+16*H H: Half word(0b0 in DVB-H) T與SCT:T 為Sender Current Time present flag(0b0),決定SCT是某存在，SCT為SESSION開始之後經過的時間單位為1ms R與ERT:R為Expected Residual Time Present flag(0b0),決定ERT是某否存在，ERT用來表示TOI所選的ALC OBJECT會被繼續傳多久 A:Closing session flag B:Closing object flag HDR_LEN: Header length(unit 32 bits)包含原本的HEADER和擴充的HEADER長度 LCT Header 只有在TOI = 0的時候會顯示 Codepoint(CP) :記錄ALC所採用的FEC演算的ENCODING ID

Reference ETSI EN 302 304: "Digital Video Broadcasting (DVB); Transmission System for Handheld Terminals". ETSI EN 300 744: "Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for digital terrestrial television". IETF RFC 0791: "Internet Protocol". ETSI TR 102 469: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Architecture". ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems". ETSI EN 301 192: "Digital Video Broadcasting (DVB); DVB specification for data broadcasting". ETSI TS 102 468: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Set of Specifications for Phase 1". ETSI TS 102 472: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocols". ETSI TS 102 470: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Program Specific Information PSI)/Service Information (SI)". ETSI TS 102 474: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Service Purchase and Protection". ETSI TS 102 005: "Digital Video Broadcasting (DVB); Specification for the use of Video and Audio Coding in DVB services delivered directly over IP protocols". IETF RFC 3550: "RTP: A Transport Protocol for Real-Time Applications". IETF RFC 3926: "FLUTE - File Delivery over Unidirectional Transport". IETF RFC 3452: "Forward Error Correction (FEC) Building Block".

THANKS