NorDig-IP Broadcast of NorDig compliant signals to NorDig compliant IRDs via IP based networks A whitepaper by NorDig

Transcription

1 NrDig-IP Bradcast f NrDig cmpliant signals t NrDig cmpliant IRDs via IP based netwrks A whitepaper by NrDig

2 - 2-1 Intrductin Dcument histry Abbreviatins References Overview General characteristics f IP-based netwrks Service requirements Transmitting DVB services ver IP based netwrks Transprt stream encapsulatin Netwrk requirements Mandatry cnstraints Recmmended cnstraints IP address allcatin Quality f Service Frward Errr Crrectin Service Discvery SD&S Data Mdel Service Discvery Entry Pints Service Prvider Discvery Infrmatin DVB-IP Service Discvery Recrd Bradcast Discvery Recrd TS Full SI Bradcast Discvery Recrd TS Optinal SI COD (Cntent On Demand) Discvery Recrd Service frm ther Service Prvider Recrd Package Discvery Recrd Service selectin Transmissin f SD&S infrmatin Multicast delivery f SD&S Unicast delivery f SD&S SW dwnlad Summary... 15

3 - 3-1 Intrductin NrDig is an assciatin f the majr Nrdic bradcasters, peratrs, and service prviders with intent t establish cmmn minimum requirements fr bradcasting and receptin f digital televisin and related services fr the varius bradcast platfrms used by NrDig members in the Nrdic regin (Denmark, Finland, Iceland, Nrway and Sweden). The NrDig assciatin was funded in 1997, and has released minimum requirements fr IRDs, Test specificatins fr IRDs and Rules f Operatin fr the bradcast f NrDig cmpliant signals. The specificatins cver digital televisin and related services via cable, satellite, terrestrial, and IP based netwrks and are available frm This white paper prvides an verview f recmmended netwrk cnfiguratin fr carrying digital televisin signals t NrDig-IP cmpliant IRD. 1.1 Dcument histry revisin date remarks First release 1.2 Abbreviatins AIT Applicatin Infrmatin Table BAT BER Buquet Assciatin Table Bit Errr Rate CA Cnditinal Access CAT Cnditinal Access Table COD Cntent On Demand DHCP Dynamic Hst Cnfiguratin Prtcl DNS Dmain Name Server DTD Data Type Definitin DVB Digital Vide Bradcasting DVB-ASI DVB Asynchrnus Serial Interface DVBSTP DVB SD&S Transprt Prtcl ECM Entitlement Cntrl Message EIT Event Infrmatin Table EMM Entitlement Management Message EPG Electrnic Prgram Guide ETSI Eurpean Telecmmunicatin Standardisatin Institute FEC Frward Errr Crrectin FTTH Fiber T The Hme HTTP Hyper Text Transfer Prtcl IGMP Internet Grup Management Prtcl IP Internet Prtcl IRD Integrated Receiver Decder itv Interactive TV MHP Multimedia Hme Platfrm MPEG Mving Pictures Expert Grup MPTS Multiple Prgram Transprt Stream NIT Netwrk Infrmatin Table PAT Prgram Assciatin Table PMT Prgram Map Table PSI Prgram Specific Infrmatin QEF Quasi Errr Free RTCP Real Time Cntrl Prtcl RTP Real Time Prtcl RTSP Real Time Streaming Prtcl SD&S Service Discvery & Selectin SDT Service Descriptin Table SPTS Single Prgram Transprt Stream STB Set Tp Bx

4 - 4 - TCP TDT TOT TV UDP VDSL VOD XML Transmissin Cntrl Prtcl Time Date Table Time Offset Table Televisin Unified Datagram Prtcl Very high-speed Digital Subscriber Line Vide On Demand extended Markup Language 1.3 References [1] TS , Digital Vide Bradcasting (DVB): Transprt f DVB Services ver IP, v1.1.1, [2] NrDig-IP TV ver. 1.0, Requirements t NrDig cmpliant IRDs fr IP-based netwrks, addendum t the NrDig Unified Requirements (ver ) fr Integrated Receivers Decders fr use in cable, satellite, terrestrial and IP-based netwrks [3] EN , Digital Vide Bradcasting (DVB): Specificatin fr Service Infrmatin (SI) in DVB systems, v1.6.1, [4] ISO/IEC , Infrmatin technlgy Generic cding f mving pictures and assciated audi infrmatin: Systems [5] RFC 1889, RTP: A Transprt Prtcl fr Real-Time Applicatins [6] RFC 2250, RTP Paylad Frmat fr MPEG1/MPEG2 Vide [7] ISO/IEC , Infrmatin technlgy Generic cding f mving pictures and assciated audi infrmatin - Part 9: Extensin fr real time interface fr system decders [8] RFC 2474, Definitin f the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers [9] RFC 2782, A DNS RR fr specifying the lcatin f services (DNS SRV) 2 Overview 2.1 General characteristics f IP-based netwrks Recent develpments in the bradband netwrks market shw that there are a multitude f netwrk types, and als a wide variety f technlgies being used t implement them. An IPTV netwrk ffers bradcasters and service prviders yet anther netwrk access t ptential subscribers. Bradcasters and service prviders shall be able t prvide cntent independently f the specific transmissin methd, meaning that riginal infrmatin frm bradcasters can be made available fr subscribers in varius access netwrks with unaltered cntent and user experience. In particular three main types f IP-based access netwrks are used fr transmissin f digital televisin: Fiber-T-The-Hme (FTTH) CAT5 twisted pair netwrks xdsl netwrks (in particular VDSL) As a minimum the access line t each subscriber shuld be capable f ffering a bitrate f 8 10 Mbps, allwing fr ne MPEG-2 (MP@ML) encded televisin service alng with sme capacity fr Internet and telephny. As the interest fr higher definitin televisin is emerging, the bit rate requirements are even stricter. This is t sme extent balanced when new and mre efficient encding standards (i.e. MPEG-4) are intrduced. As televisin is a real-time service, the access netwrks have t ffer adequate quality f service t enable apprximately errrfree decding. In mst cases, an IPTV head end receives its signals frm satellite. The IPTV head-end may be quite simple, e.g. with a satellite antenna, a cntent prcessr and a netwrk adaptatin unit, but may als cntain additinal functins.

5 - 5 - In additin t the pure TV related infrastructure, IPTV netwrk peratrs shuld als prvide administratin and prvisining servers 1 (administratin f IRDs, sftware prvisining, etc). Optinally ther value-added services may be ffered, e.g. Internet access, , news etc. The head-end may therefre als cntain ne r mre servers and shuld act as the service aggregatin pint as well as the netwrk administrative hub. A typical headend is shwn in Figure 1. NrDig has specified requirements fr IRDs with cable, satellite, terrestrial and IP-based frnt-ends. NrDig has als specified cmmn Rules f Operatin fr NrDig cmpliant bradcasts, cvering the same media (still pending fr IP-based netwrks). The NrDig specificatins are based n DVB specificatins/etsi standards and ther pen specificatins/standards. The IRDs are specified with a cmmn cre that is independent f transmissin media, allwing cntent t be distributed ver several media while prviding the same service at the end-user s receiver equipment. The NrDig specificatin fr bradcast ver IP-based netwrks is based n the ETSI standard TS ( Transprt f DVB Services ver IP ) [1]. On these netwrks IP is used as the netwrk layer prtcl between the head-end and end-user. The IRD is based n a kernel that is identical with the kernel fr ther bradcast netwrks, while the physical IP interface is assumed t be Ethernet (the NrDig-IP specificatin [2] des nt specify requirements fr the physical layer and data link layer prtcls). Satellite Satellite receiver / transpr receiver / strea Transprt descramble t stream m descrambler r Cntent Prcess Cntent prcessr r Netwrk adaptati k n n DHCP Serve DHCP Server r Prvisinin Prvisinin g Serve g Server r II P Multicastenabled access netwrk EPG Multicaste EP Multicaste G r r SD&S Serve r Firewal l l Interne t Serve r VOD Serve r Figure 1: Illustratin f typical headend 2.2 Service requirements The fllwing services will be required in the IPTV netwrks: Bradcast quality televisin and radi services Access t assciated prgram infrmatin (i.e. applicatins and/r infrmatin transmitted alng and assciated with particular TV prgrams). In additin the fllwing services are regarded as valuable add-ns in IPTV netwrks: Persnalised services like VOD, EPG suited fr individual subscriber need, walled garden, etc. 1 Netwrk Prvisining [1] is ptinal, but there must be a mechanism fr IRD administratin (a.. DHCP). Hwever, these functins may be prvided by a different peratr.

6 - 6 - In rder t achieve the subscriber requirements, the MPEG encding is nt altered and MPEG-2 transprt stream is used as the transprt cntainer fr bradcast services. In sme cases access netwrks with very cnstrained bandwidth will cause an exceptin t this, e.g. variable bit rate (VBR) signals must be re-encded t CBR (when accepted by the bradcaster) t suit the characteristics f xdsl lines. The PSI signalling tables are als transmitted as part f the MPEG-2 transprt stream, hence standard chipsets and sftware filters can be used in IRDs. Further details are prvided in fllwing sectins. The main architecture f IP-based netwrks is utlined in sectin 2.1, assuming that the bradcast infrmatin is brught t the head-end by a NrDig cmpliant bradcast netwrk (cable, satellite r terrestrial) r as baseband DVB-ASI signals directly frm the peratr. The transprt streams (MPTS) received frm a bradcast netwrk may cntain the fllwing types f services and applicatins: Individual televisin services and crrespnding data streams (e.g. assciated CA-streams, applicatins/metadata) Services and applicatins cmmn fr the entire bradcast netwrk (e.g. EPG, sftware btlad) Service Infrmatin tables cmmn fr all services in the transprt stream (e.g. CA-related data) When relaying the bradcast services int IP-based netwrks, the fllwing assumptins are made: The individual service with assciated prgram service infrmatin (PSI) is sent transparently via the IP netwrk t the end-user s IRD, which shall supprt these data. The PSI includes the tables PAT, PMT, and CAT. Supprt fr these tables with assciated data is mandatry fr NrDig IRDs. As a cnsequence, the cnditinal access system used in the bradcast netwrk can be used in IP-based netwrks as well. Cnditinal access data, i.e. ECM and EMM, are retransmitted transparently as reflected by the PMT and CAT. Service Infrmatin (SI) shall be transmitted t the end-user, either as retransmissin f SI-tables (see TS Full SI in chapter 4, belw) r via alternative transmissins (see TS Optinal SI in chapter 4, belw). Supprt fr TS Full SI is mandatry fr NrDig IRDs, while supprt fr TS Optinal SI is recmmended. The SI includes the tables SDT, TDT and TOT, which shuld be transmitted, tgether with EIT present/fllwing and EIT Schedule, unless available in ther frms, as described belw. The supprt f these tables is mandatry fr NrDig IRDs. The time and date functins may als be prvided via the NTP prtcl. Hwever, if TDT/TOT is transmitted, TDT/TOT shall take precedence prir t NTP (the IRD shall supprt bth mdes). EIT present/fllwing may be retransmitted transparently whenever the DVB_triplet (riginal_netwrk_id transprt_stream_id service_id) remains unchanged. Otherwise the EIT present/fllwing must be regenerated t reflect the new DVB_triplet values. EIT schedule may als be retransmitted whenever present. Hwever, since the EIT schedule stream may ccupy several Mbps, it will be mre efficient t transmit EIT schedule n a dedicated multicast address rather than t transmit EIT schedule alng with a few rdinary services. Bth actual and ther subtables (SDT and EIT) may be retransmitted whenever the DVB_triplet is unaltered fr the services. Otherwise actual and ther subtables must be regenerated in the head-end t reflect the new DVB_triplet values. Netwrk Infrmatin tables are nt used in the IP-based netwrks; relevant netwrk infrmatin shall be sent via the SD&S-structure, see chapter 4 belw. Supprt fr the SD&S-structure is mandatry fr NrDig IRDs fr IP-netwrks. Any incming NIT may thus be ignred by the IRD r remved at the head-end f the IP-netwrk. The use f PSI, SI and netwrk/peratr related infrmatin is specified in [2], chapters 12 and 13. Sme NrDig specific data, e.g. NrDig btlader, may be retransmitted transparently. The reference fr the NrDig btlader (cntained in the NIT fr ther bradcast netwrks) is signalled accrding t chapter 5. Other NrDig specific data, e.g. the NrDig lgic_channel_descriptr (ver 2) may be retransmitted via the SD&S structures.

7 - 7 - Service related applicatin(s) data is retransmitted transparently, including the Applicatin Infrmatin Table 2 (AIT) assciated with MHP applicatins. 3 Transmitting DVB services ver IP based netwrks 3.1 Transprt stream encapsulatin NrDig-IP cmpliant IRDs assume DVB services are transmitted accrding t the DVB-IPI specificatin [1]. The list belw summarises the main items: DVB services may be transmitted as multiple prgram transprt streams (MPTS) r decmpsed int single prgram transprt streams (SPTS). This is an peratinal issue, hwever sufficient access bandwidth must be ensured if MPTS is t be transmitted. Nte that MPTS require that the ptinal MPTS functin is prvided in the IRDs. NrDig-IP accepts services transmitted ver UDP and UDP/RTP. There is n requirement t cntain the same number f transprt stream packets in each RTP (UDP) packet. The IRD shall use the length field in the UDP header t determine the number f transprt stream packets. The maximum size f ne IP datagram (65535 ctets fr IPv4) shall nt be exceeded. IP fragmentatin shuld be avided; hence care shuld be taken nt t exceed the maximum transmissin unit (MTU) f the underlying netwrk. In case Ethernet is used (MTU f 1492 r 1500 bytes), the number f transprt stream packets per IP datagram shuld be limited t seven (r less if IP and/r RTP header ptins are transmitted). It is recmmended that cntent service prviders set the DF (Dn t Fragment) bit in the IP header. Calculatin f the UDP checksum is ptinal. If nt calculated, the checksum value shall be set t zer. In case RTP is used, the fllwing rules apply: The Paylad Type parameter in the RTP header shall be set t MP2T. The timestamp in the RTP header shall be derived frm a 90 khz clck surce that may be lcked t the clck reference f ne f the prgrams in the transprt stream. This clck shall cnfrm t the accuracy and slew cnstraints fr MPEG-2 system clcks as defined in ISO/IEC [4]. Other fields in the RTP header shall be cmpleted as per RFC 1889 [5] and RFC 2250 [6]. Header cmpressin shall nt be used. In case RTP is used, the IRDs shall als supprt the RTCP prtcl accrding t the fllwing rules: Sender Reprts shall be supprted, but nt Receiver Reprts. The cntent service prvider is recmmended t send Sender Reprts t enable IRDs t synchrnise independent transprt streams accurately (e.g. fr picture-in-picture r ther applicatins). Receiver Reprts may generate a large vlume f traffic at the Sender, hence shall nt be supprted due t scalability reasns. Each Sender Reprt shall cntain tw timestamps taken at the same instance; ne f the RTP clck surce and the ther f the NPT clck. The IRD shall use these tw timestamps t synchrnise tw streams (e.g. fr picture-in-picture). 3.2 Netwrk requirements The DVB-IPI specificatin states sme mandatry and sme recmmended netwrk cnstraints Mandatry cnstraints The verall requirement fr TV transmissin in IPTV netwrks is n mre than ne nticeable artefact per hur. The maximum RTP packet jitter shall be 40 ms peak-t-peak. This means that the IRD shall cmply with the MPEG-2 Real Time Interface Specificatin (ISO/IEC [7]) with t_jitter = 20 ms. The TM-IPI wrking grup f DVB is currently wrking n a prpsal fr FEC fr MPEG transmissin in IPbased netwrks. NrDig will adhere t the requirements set frth by DVB as sn as they are fficial. 2 AIT is signalled as an elementary stream in the Prgram Map Table (PMT).

8 Recmmended cnstraints Recmmended cnstraints are infrmative nly, but failure t meet these cnstraints may significantly degrade the user s experience. There shuld be maximum ne nticeable artefact per hur. The crrespnding IP packet errr rate depends n the transprt stream bit rate. The recmmended multicast jin and leave times are as fllws: LEAVE time: maximum 500 ms JOIN time: maximum 500 ms It is emphasized that this is maximum levels. Ideally the jin and leave time shuld be significantly less in rder t minimise verall channel change time. Jining and leaving multicast grups shall be dne accrding t the IGMPv3 prtcl. The surce filtering functinality shall be used. The netwrk shuld supprt service transmissin ver bth multicast and unicast. Multicast is generally used fr transmitting bradcast services, while unicast is used fr persnalised services (e.g. VOD). Service transmissin ver unicast shall be initiated and cntrlled using the DVB prfile f the Real Time Streaming Prtcl (RTSP) accrding t the DVB-IPI specificatin [1]. 3.3 IP address allcatin IP addresses shall be allcated using the DHCP prtcl nly. Static addressing shall nt be used, meaning that there shall be n mechanism fr the end-user t enter an IP address manually (nt supprted in minimum requirements fr NrDig-IP IRDs [2]). The requirements fr the DHCP functinality are given in the DVB-IPI specificatin [1]. 3.4 Quality f Service NrDig IP-based netwrks shall supprt the Differentiated Services mdel with regards t classificatin f type f data cntained in each datagram. The 8-bit Type f Service (TS) field in the IP packet header is used fr marking accrding t the fllwing rules: Netwrks cmpliant with RFC 2474 [8] use 6 bit f the TS field Netwrks nt cmpliant with RFC 2474 [8] use 3 bit f the TS field The markings shall be as listed in the DVB-IPI specificatin [1]. 3.5 Frward Errr Crrectin FEC is an nging area fr standardisatin within IPTV in DVB. This is ne area that will be cnsidered t be included in future NrDig specificatins when agreed in DVB. The quality requirement fr delivery t the end user shuld be based n QEF receptin (nt mre than ne visible artefact per hur). This requirement may translate t max ne MPEG packet lss per hur, and a BER better than ne in bits (after errr crrectin, when available). Fr the cncentrated (backbne) traffic, even stricter requirements shuld apply. 4 Service Discvery Service Discvery & Selectin is the mechanism t prvide infrmatin abut service ffering and hw services can be accessed. Cmpared t traditinal DVB netwrks (e.g. satellite) SD&S is very much like the SI mechanism. Relevant infrmatin in the SI tables may be transferred t apprpriate SD&S structures. SD&S infrmatin can be delivered in a push (multicast) and pull (unicast) mdel. Bth live bradcasts (e.g. bradcast TV) and cntent n demand (e.g. VOD) shall be supprted. Tw SD&S types are defined fr live bradcast: 1. TS Full SI: This scheme allws transparent retransmissin f transprt streams frm ther delivery netwrks (e.g. satellite). LIVE BROADCAST CONTENT ON DEMAND Hence all inbund MULTICAST PSI and SI tables TS Full SI TS Optinal SI UNICAST

9 - 9 - are retransmitted withut any change. Due t the fact that the NIT table is replaced by SD&S structures in DVB-IP netwrks, NIT shall be ignred by IRDs and the DVB-IP service prvider must generate service discvery infrmatin specifically. The TS Full SI scheme is supprted by NrDig-IP IRDs. 2. TS Optinal SI: In this scheme retransmissin f the SI tables is ptinal. Hence it is assumed that the DVB-IP service prvider has ther mechanisms fr relaying apprpriate service infrmatin. If SI tables are present, the SD&S infrmatin shall take precedence. It is nt mandatry fr NrDig-IP IRDs t supprt TS Optinal SI. T summarise, mst PSI/SI infrmatin in DVB netwrks are either retransmitted transparently r transferred int SD&S structures befre being transmitted int IPTV netwrks. Figure 2 shws hw the mst relevant PSI/SI tables are treated. DVB TS Full SI TS Optinal SI PSI PAT PAT PAT PMT PMT PMT CAT CAT CAT NIT Delivery system descriptrs Service Prvider Discvery Recrd + Bradcast Delivery Recrd Service Prvider Discvery Recrd + Bradcast Delivery Recrd SI Linkage descriptr Linkage_descriptr in Bradcast Discvery Recrd Linkage_descriptr in Bradcast Discvery Recrd SDT SDT SDT / Bradcast Discvery Recrd EIT EIT EIT / Bradband Cntent Guide 1 TDT TDT TDT / NTP TOT TOT TOT / NTP 1 Bradband Cntent Guide is an XML frmat subject fr future standardisatin within DVB Figure 2: Transfer f PSI/SI infrmatin int IPTV netwrks (the mst relevant tables are shwn nly) Figure 3: Fragmentatin f SD&S recrds SD&S infrmatin is represented with xml recrds, and the DTDs f the different recrds are specified [1]. A maximum cycle time (f the entire SD&S infrmatin) is specified t 30 secnds, meaning that IRDs will wait n lnger than 30 secnds t acquire the entire SD&S infrmatin set. An SD&S recrd may be f substantial size; hence they may be fragmented int segments and sectins as indicated in figure 3. The versining mechanism is similar t DVB PSI/SI, meaning that a change t a SD&S segment causes the segment versin_id t be incremented. Hence IRDs can mnitr the segment versin_id t decide whether an update has been perfrmed. Different cycle rates can als be set t allw certain data t be transmitted mre ften than ther data.

10 The different steps in Service Discvery are given in Figure 4. Figure 4: Steps in Service Discvery 4.1 SD&S Data Mdel The SD&S data mdel is cmprised f several recrds in a specific rder. The verall data mdel is shwn in Figure 5. Figure 5: SD&S data mdel The mdel is described in mre detail in the fllwing sectins.

11 Service Discvery Entry Pints The IRD will lk fr SD&S entry pints in the pririty rder defined belw: 1. SD&S entry pints cntained in the Netwrk Prvisining ptin [1]. If the Netwrk Prvisining ptin is implemented, then the sdentries element in the Cnfiguratin DTD shall list the SD&S entry pints. This means that the IRD can be prvided with entry pints as part f the cnfiguratin data received n a prvisined netwrk. If this ptin is nt implemented, the IRD shall g t the next step. 2. A list f SD&S entry pints may be acquired via DNS (which is acquired via DHCP ptin 15). A list f SD&S entry pints is then acquired via DNS accrding t RFC 2782 [9]. The service name is _dvbservdsc, the prtcl may be TCP r UDP, while the rest f the name is the dmain name prvided via DHCP Optin 15. An example f a pssible lkup may be: _dvbservdsc._tcp.example.cm, r _dvbservdsc._udp.example.cm 3. A list f SD&S entry pints may be acquired via DNS accrding t the service lcatin RFC 2782 [9]. The service name is _dvbservdsc, the prtcl may be TCP r UDP, while the rest f the name is the dmain name maintained by DVB fr service discvery (services.dvb.rg). Hence the lkup shall be ne f the fllwing: _dvbservdsc._tcp.services.dvb.rg _dvbservdsc._udp.services.dvb.rg 4. SD&S entry pints are transmitted in an IANA registered multicast address ( , DvbServDisc). If the IRD has nt received any valid SD&S packets within a perid f tw maximum cycle time (i.e. 60 secnds), the IRD shall g t the next step. 5. The user shall be allwed t enter an URL f an SD&S entry pint manually. 4.3 Service Prvider Discvery Infrmatin The SD&S entry pints discvered in sectin 4.2 prvide infrmatin abut the available service prviders. This infrmatin is carried in the Service Prvider Discvery Recrd. The fields in the Service Prvider Discvery Recrd are specified in TS [1]. The recrd describes a.. the fllwing tw imprtant fields: Lcatin(s): Prvides the lcatin f the DVB IP Offering Recrd(s) which describes the fferings f the particular Service Prvider. Paylad Id: The paylad_id indicates the type f service discvery infrmatin available at the lcatin(s) prvided. The valid values fr paylad_id are defined in Table 1. Table 1: Available paylad_id values paylad id 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0xEF 0xF0 0xFF SD&S recrd carried Reserved Service Prvider Discvery Infrmatin Bradcast Discvery Infrmatin COD Discvery Infrmatin Services frm ther SP s Package Discvery Infrmatin Reserved User Private Hence typical values fr the paylad_id field in the Service Prvider Discvery Recrd is 0x02 (Bradcast Discvery Recrd) r 0x03 (COD Discvery Recrd). 4.4 DVB-IP Service Discvery Recrd The DVB-IP Service Discvery Recrd is the parent fr the fllwing recrds: Bradcast Discvery Recrd TS Full SI TS Optinal SI

12 COD Discvery Recrd Service frm ther Service Prvider Recrd Package Discvery Recrd The DVB-IP Service Discvery Recrd cntains the service prvider dmain name (an internet DNS dmain name registered by the Service Prvider) and a versin_number Bradcast Discvery Recrd TS Full SI The TS Full SI Bradcast Discvery Recrd prvides all necessary infrmatin t find available live media bradcast transprt streams that is transmitted with embedded SI infrmatin (i.e. meaning that the SI tables are part f the verall transprt stream). Infrmatin abut the individual services are acquired frm the transprt stream itself by classical interpretatin f the DVB-SI tables (EN [3]). The NrDig-IP IRDs shall supprt TS Full SI Bradcast Discvery Recrd TS Optinal SI The TS Optinal SI Bradcast Discvery Recrd must prvide all the necessary infrmatin t create a list f available services with sufficient infrmatin fr the user t select a channel [1]. This recrd is t be transmitted in case the SI tables are nt prvided embedded int the transprt stream carrying the actual service. Hwever, if this recrd is transmitted, and the SI tables are embedded int the transprt stream, the Bradcast Discvery Recrd will take precedence. The NrDig-IP specificatin [2] states that supprt fr TS Optinal SI is nt mandatry fr NrDig-IP IRDs COD (Cntent On Demand) Discvery Recrd The COD Discvery Recrd prvides all the necessary infrmatin t discver the COD servers (e.g. VOD servers) available n the netwrk and the lcatin f their catalgue f cntent. The NrDig-IP IRD specificatin states that this mde is nt mandatry fr NrDig-IP IRDs Service frm ther Service Prvider Recrd A service prvider may reference individual services r cmplete fferings frm ther service prviders. T reference an individual service, the textual service identifier is supplied. T reference a cmplete ffering, the service prvider s DNS dmain name is supplied. The NrDig-IP IRD specificatin states that this mde is nt mandatry fr NrDig-IP IRDs Package Discvery Recrd A service prvider may wish t grup particular services int a single entity, e.g. fr marketing purpses. The Package Discvery Recrd is used fr this purpse. Nte that the Package Discvery Recrd des nt enable discvery f new services. All services included in a Package Discvery Recrd must be identified thrugh Bradcast Discvery Recrd, COD Discvery Recrd, r Service frm ther Service Prvider Recrd. The Package Discvery Recrd is very similar t the BAT table defined in the DVB SI specificatin [3]. The NrDig-IP IRD specificatin states that this mde is nt mandatry fr NrDig-IP IRDs. 4.5 Service selectin Tw prtcls are defined fr selecting a service in a DVB-IP netwrk: IGMP (versin 3): used t select Live Media Bradcast services transmitted in a multicast grup, usually live TV. Such services are streamed cntinuusly and d nt need t be initiated by each IRD. The Service Lcatr attribute in service discvery recrds prvides all infrmatin needed t issue an IGMP request. An example is prvided in Figure 6.

13 Service Lcatr IGMP prtcl Address Prt Surce address RTSP prtcl IGMP request t :8208 Figure 6: Example f service selectin using IGMP RTSP: Optinally the Live Media Bradcast services may be ffered as unicast services. In this case the IRD is engaged in explicit set up and tear dwn f the services, and the RTSP prtcl is used. The Service Lcatr attribute in service discvery recrds signals the use f RTSP and prvides all infrmatin needed t issue the apprpriate RTSP methd. An example is prvided in Figure 7. It must be emphasised that RTSP is mst ften used fr cntent n demand type f service, e.g. VOD. Service Lcatr IGMP prtcl 0 Surce address RTSP prtcl RTSP SETUP t Figure 7: Example f service selectin using RTSP 4.6 Transmissin f SD&S infrmatin The SD&S recrds can be transmitted either as multicast r unicast. In case multicast is used, the DVB SD&S Transprt Prtcl (DVBSTP) is used t transprt the recrds. In case unicast is used, the HTTP prtcl is used t transprt the recrds Multicast delivery f SD&S The DVBSTP prtcl is specified in the DVB-IP specificatin [1] and is used when the SD&S infrmatin is transmitted using multicast UDP packets Unicast delivery f SD&S When SD&S infrmatin is available nly via unicast, the IRD must use HTTP t cmmunicate with the SD&S server(s). In rder t retrieve SD&S infrmatin, the IRD issues a HTTP GET request: GET /dvb/sdns <request> HTTP/1.1 CRLF Hst: hst CRLF Tw different requests are defined: sp_discvery_request: Request fr discvery infrmatin relating t service prviders. The hst address will in this case specify the IP address f the SD&S server btained when searching fr the SD&S entry pints (refer t sectin 4.2)

14 service_discvery_request: Request fr discvery infrmatin relating t the service ffering f a service prvider. The hst address in this case refers t the URI that cntains a DVB-IP Offering Recrd (which describes the fferings frm a service prvider). The return frm the SD&S server n these requests is the apprpriate XML recrds as defined in [1]. 5 SW dwnlad There are basically tw different mechanisms fr sftware dwnlad in DVB-IP netwrks. One mechanism is sftware dwnlad thrugh the Netwrk Prvisining ptin [1]. The secnd mechanism is thrugh an n-air btlader service, i.e. a dedicated sftware dwnlad service that has been retransmitted frm bradcast netwrks int the IPTV netwrk. The latter mechanism is specifically defined by NrDig and is used t uplad sftware t NrDig cmpliant IRDs. In bradcast netwrks, the btlader service is transmitted as an individual MPEG2 service with a data stream as the nly elementary stream. I.e. the btlader service is identified thrugh a unique DVB triplet (riginal_netwrk_id transprt_stream_id service_id). A linkage_descriptr in the NIT table identifies the btlader service fr bradcast IRDs. This is shwn in Figure 8. S_id = 100 vide audi teletext S_id = 101 vide audi teletext NIT linkage_descriptr() { ts_id = 1 s_id = 103 linkage_type = 0x81 } S_id = 102 S_id = 103 vide audi teletext data (btlader) Figure 8: Signalling f NrDig btlader in bradcast netwrks In this example fur services are transmitted, three TV services and ne btlader service. Each service is identified thrugh a unique DVB_triplet. The NIT cntains a linkage_descriptr referring t a NrDig btlader service (linkage_type = 0x81). The DVB_triplet in the linkage_descriptr uniquely identifies the actual NrDig btlader service. Due t the fact that the NIT table is replaced by SD&S structures in DVB-IP netwrks, the NIT table shuld be mitted. Instead, a linkage_descriptr may be inserted int the Bradcast Discvery Recrd, referring t a NrDig btlader service exactly as is dne fr bradcast netwrks, i.e. using the DVB triplet as identifier.

15 Bradcast Discvery Recrd ts_id = 1 s_id = 100 IGMP prtcl = 1 address = prt = 8208 ts_id = 1 s_id = 101 IGMP prtcl = 1 address = prt = 8208 ts_id = 1 s_id = 102 IGMP prtcl = 1 address = prt = 8208 ts_id = 1 s_id = 103 IGMP prtcl = 1 address = prt = 8208 linkage_descriptr() { ts_id = 1 s_id = 103 linkage_type = 0x81 } S_id = 100 Address: Prt: 8208 S_id = 101 Address: Prt: 8208 S_id = 102 Address: Prt: 8208 S_id = 103 Address: Prt: 8208 vide audi teletext vide audi teletext vide audi teletext data (btlader) Figure 9: Using linkage_descriptr in Bradcast Discvery Recrd t signal NrDig btlader In this example fur services are transmitted int the IPTV netwrk. The DVB_triplets are preserved frm the bradcast netwrk, and each service is mapped nt a multicast grup. The Bradcast Discvery Recrd identifies all services (using the DVB_triplet) and the assciated service lcatr(s). A NrDig linkage_descriptr is inserted int the Bradcast Discvery Recrd, referring t the NrDig btlader service using the DVB_triplet. Furthermre, the service lcatr(s) fr the actual DVB_triplet refers t the actual NrDig btlader service. Hence, the IRD may issue an IGMP jin cmmand t the actual multicast address (i.e. IGMP jin t :8208). 6 Summary The NrDig-IP specificatin is based n the ETSI Technical Specificatin Digital Vide Bradcasting (DVB): Transprt f DVB Services ver IP (TS [1]). The specificatin was apprved in ETSI in March 2005 and will hpefully prvide the fundament fr all cmmercial IPTV deplyments. The NrDig-IP specificatin extends the ETSI specificatin n a few issues, e.g. the presence f a linkage_descriptr in the Bradcast Discvery Recrd (SD&S) t signal a NrDig btlader stream. The intentin fr NrDig is t align with DVB when slutins t these items are agreed n in DVB.