This file is raw output from pdftotext and may not be ideal for distribution. If you are a maintainer for Hackipedia, please sit down when you have time and clean this text version up. Source PDF: /mnt/main/jmc-storage/docs/DVB/TR 101 194 Guidelines for impl and use of spec of net ind protos for DVB interactive srv V1.1.1 (1997-06).pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- TR 101 194 V1.1.1 (1997-06) Technical Report Digital Video Broadcasting (DVB); Guidelines for implementation and usage of the specification of network independent protocols for DVB interactive services European Broadcasting Union Union Européenne de Radio-Télévision 2 TR 101 194 V1.1.1 (1997-06) Reference DTR/JTC-00DVB-36 (b2000ics.PDF) Keywords DVB, broadcasting, digital, video, TV, protocol ETSI Secretariat Postal address F-06921 Sophia Antipolis Cedex - FRANCE Office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 X.400 c= fr; a=atlas; p=etsi; s=secretariat Internet secretariat@etsi.fr http://www.etsi.fr Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © European Telecommunications Standards Institute 1997. © European Broadcasting Union 1997. All rights reserved. 3 TR 101 194 V1.1.1 (1997-06) Contents Intellectual Property Rights................................................................................................................................4 Foreword ............................................................................................................................................................4 1 Scope........................................................................................................................................................5 2 References................................................................................................................................................6 3 Abbreviations ...........................................................................................................................................7 4 Use of the interaction channel..................................................................................................................9 4.1 As part of a bootstrap application (at start-up)................................................................................................. 10 4.2 From within an interactive application (after start-up)..................................................................................... 10 4.3 When the interaction channel is already in use for a different telephone number............................................ 10 5 Logical channels ....................................................................................................................................11 5.1 Logical channel S1........................................................................................................................................... 11 5.2 Logical channel S2........................................................................................................................................... 11 5.3 Logical channel S3........................................................................................................................................... 11 5.4 Logical channel S4........................................................................................................................................... 11 5.5 Logical channel S5........................................................................................................................................... 11 6 Protocols.................................................................................................................................................12 6.1 TCP/IP model .................................................................................................................................................. 12 6.2 Internet Protocol (IP) ....................................................................................................................................... 12 6.3 Transmission Control Protocol (TCP) ............................................................................................................. 13 6.3.1 TCP services provided ............................................................................................................................... 13 6.3.2 TCP connections and ports......................................................................................................................... 14 6.3.3 TCP optional extensions for high performance networks........................................................................... 14 6.4 User Datagram Protocol (UDP) ....................................................................................................................... 15 6.5 Point-to-Point Protocol (PPP).......................................................................................................................... 15 6.6 Multilink Point-to-Point Protocol (MP)........................................................................................................... 15 6.7 SNMP and MIB ............................................................................................................................................... 15 6.7.1 SNMP service ............................................................................................................................................ 17 6.7.2 SNMP network management...................................................................................................................... 17 6.7.3 Structure of management information ........................................................................................................ 18 6.8 IPCP and assigned numbers............................................................................................................................. 18 6.9 CHAP and PAP................................................................................................................................................ 18 6.10 Digital Storage Media - Command and Control (DSM-CC)............................................................................ 19 6.10.1 DSM-CC User-to-User............................................................................................................................... 20 6.10.2 DSM-CC User-to-User object carousels and BIOP ................................................................................... 20 6.10.3 DSM-CC download.................................................................................................................................... 21 6.10.4 DSM-CC user compatibility....................................................................................................................... 22 6.11 UNO-RPC, UNO-CDR, IOR (GIOP and IIOP)............................................................................................... 22 6.12 Object Request Broker (ORB) ......................................................................................................................... 22 7 Use of the protocol stacks for enhanced broadcast services..................................................................23 7.1 Use of the DSM-CC User-to-User protocol..................................................................................................... 23 7.1.1 Data transfer and download........................................................................................................................ 23 7.1.1.1 Synchronized data transfer or download............................................................................................... 23 7.1.1.2 Unsynchronized data download or data transfer................................................................................... 23 8 Network congestion control ...................................................................................................................25 8.1 Traffic shaping................................................................................................................................................. 25 8.2 IDL description of traffic shaping.................................................................................................................... 26 Annex A (informative): Bibliography...................................................................................................27 History ..............................................................................................................................................................28 4 TR 101 194 V1.1.1 (1997-06) Intellectual Property Rights ETSI has not been informed of the existence of any Intellectual Property Right (IPR) which could be, or could become essential to the present document. However, pursuant to the ETSI Interim IPR Policy, no investigation, including IPR searches, has been carried out. No guarantee can be given as to the existence of any IPRs which are, or may be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by the Joint Technical Committee (JTC) of the European Broadcasting Union (EBU), Comité Européen de Normalisation ELECtrotechnique (CENELEC) and the European Telecommunications Standards Institute (ETSI). NOTE: The EBU/ETSI JTC was established in 1990 to co-ordinate the drafting of ETSs in the specific field of broadcasting and related fields. Since 1995 the JTC became a tripartite body by including in the Memorandum of Understanding also CENELEC, which is responsible for the standardization of radio and television receivers. The EBU is a professional association of broadcasting organizations whose work includes the co-ordination of its Members' activities in the technical, legal, programme-making and programme-exchange domains. The EBU has active members in about 60 countries in the European broadcasting area; its headquarters is in Geneva *. * European Broadcasting Union Case Postale 67 CH-1218 GRAND SACONNEX (Geneva) Switzerland Tel: +41 22 717 21 11 Fax: +41 22 717 24 81 Digital Video Broadcasting (DVB) Project Founded in September 1993, the DVB Project is a market-led consortium of public and private sector organizations in the television industry. Its aim is to establish the framework for the introduction of MPEG-2 based digital television services. Now comprising over 200 organizations from more than 25 countries around the world, DVB fosters market-led systems, which meet the real needs, and economic circumstances, of the consumer electronics and the broadcast industry. 5 TR 101 194 V1.1.1 (1997-06) 1 Scope The basic requirement of an interaction channel is that the user be able to respond in some way to the Interactive Service (IS). This response may take the form of "voting" for a particular participant in a competitor show, "purchasing" goods demonstrated/advertised in a shopping channel programme, etc. This would be achievable within a one-way (reverse direction) narrow-band path. A higher level of interactivity might require that a user, who has made a response to an IS, be sent an acknowledgement. This might be the case where the consumer has made a credit card purchase from a shopping channel via the basic interaction channel. That consumer would expect to receive an acknowledgement that his credit card transaction had been accepted. This level of interactivity would require a two-way interaction channel: one in the reverse direction and the other in the forward direction. A further level of interactivity would occur where in response to information in the interactive service, the consumer requests further information on particular topics from the source of the service, or from a central database via the source of the IS. This would require that the forward channel be broadband. In this particular example, the reverse path would only need to be a narrow-band one, but it is likely that applications will arise whereby the consumer will need to make a broadband response/contribution to the IS and also receive a broadband "answer" from the service source. The present document is intended to explain the ways in which the network independent protocols specified in ETS 300 802 [2] can be used in conjunction with an interaction network as specified for instance in ETS 300 801 [1] to implement the full range of Interactive Services (IS) complementing broadcast television services according to the commercial requirements defined in the "Commercial Requirements for Asymmetric Interactive Services supporting Broadcast to the Home with Narrowband Return Channels" (see bibliography). 6 TR 101 194 V1.1.1 (1997-06) 2 References References may be made to: a) specific versions of publications (identified by date of publication, edition number, version number, etc.), in which case, subsequent revisions to the referenced document do not apply; or b) all versions up to and including the identified version (identified by "up to and including" before the version identity); or c) all versions subsequent to and including the identified version (identified by "onwards" following the version identity); or d) publications without mention of a specific version, in which case the latest version applies. A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same number. [1] prETS 300 801: "Digital Video Broadcasting (DVB); Interaction channel through PSTN/ISDN". [2] prETS 300 802: "Digital Video Broadcasting (DVB); Network-independent protocols for DVB interactive services". [3] IEEE 802 (1990): "IEEE Organizational Unique Identifier". [4] ISO/IEC 13818-1, 2, 3: "MPEG-2 Systems, Video and Audio". [5] DAVIC 1.0 specification part 07 (January 1996): "High and Mid Layer Protocols (Technical Specification)". [6] ISO/IEC 13818-6 (December 1995): "MPEG-2 DSM-CC Specification". [7] ETS 300 468 (October 1994): "Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems". [8] prEN 101 192: "Digital Video Broadcasting (DVB); DVB data broadcasting specification". [9] RFC 768: "User Datagram Protocol (UDP)". [10] RFC 791: "Internet Protocol (IP)". [11] RFC 793: "Transmission Control Protocol (TCP)". [12] RFC 1332: "Internet Protocol Control Protocol (IPCP)". [13] RFC 1661 and RFC 1662: "Point-to-Point Protocol (PPP)". [14] RFC 1717: "Multilink Point-to-point protocol (MP)". [15] "Universal Network Object Specification", Version 1.0 (identical to OMG-UNO Specification for CORBA 2.0). [16] RFC 1157" "Simple Network Management Protocol (SNMP)". [17] RFC 1323: "(Transmission Control Protocol (TCP) extensions for high performance)". [18] RFC 1889: "Real Time Protocol (RTP)". [19] RFC 1334: "Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP)". [20] RFC 1340: "Point-to-Point Protocol (PPP) assigned numbers)". 7 TR 101 194 V1.1.1 (1997-06) 3 Abbreviations For the purposes of the present document, the following abbreviations apply: API Application Programming Interface ASN.1 Abstract Syntax Notation One BCD Binary Coded Decimal BER Basic Encoding Rules BIOP Broadcast Inter ORB Protocol BIOP Broadcast Inter-ORB Protocol (see DSM-CC ISO/IEC13818-6 [6]) CATV Community Antenna TeleVision CDR Common Data Representation CHAP Challenge Handshake Authentication Protocol DAVIC Digital AudioVIsual Council DSM Digital Storage Media DSM-CC U-N DSM - CC User-to-Network DSM-CC U-U Digital Storage Media - CC User-to-User DSM-CC DSM - Command and Control DVB Digital Video Broadcasting GIOP General Inter-ORB Protocol (see DSM-CC ISO/IEC13818-6 [6]) HDLC High level Data Link Control (protocol) HFC Hybrid Fibre Coax IETF Internet Engineering Task Force IIOP Internet Inter-ORB Protocol IOP Inter-ORB Protocol (see DSM-CC ISO/IEC13818-6 [6]) IOR Interoperable Object Reference (see DSM-CC ISO/IEC13818-6 [6]) IP Internet Protocol IPCP IP Control Protocol IS Interactive Service ISDN Integrated Services Digital Network ISP IS Provider LCN Local Connection Name LCP Link Control Protocol LLC Link Layer Control LSB Least Significant Bit MD Message Digest 5 (This is a hash scrambling algorithm) MIB Management Information Base MJD Modified Julian Date MMDS Multipoint Microwave Distribution System MP Multilink Point-to-point protocol MPEG TS MPEG Transport Stream MPEG Moving Picture Experts Group NCP Network Control Protocol NSAP Network Services Access Point ORB Object Request Broker (see DSM-CC ISO/IEC13818-6 [6]) OSI Open Systems Interconnection PAP Password Authentication Protocol PPP Point-to-Point Protocol PSTN Public Switched Telephone Network RFC Request For Comment RPC Remote Procedure Call RTP Real Time Protocol SI Service Information SIS Systems for Interactive Services SMATV Satellite Master Antenna TeleVision SNAP Sub Network Attachment Point SNMP Simple Network Management Protocol SRM Session and Resource Manager STB Set Top Box STU Set Top Unit 8 TR 101 194 V1.1.1 (1997-06) TCP Transmission Control Protocol TS Transport Stream TV TeleVision UDP User Datagram Protocol ULP 8-bit Upper Layer Protocol UN User-Network (see DSM-CC ISO/IEC13818-6 [6]) UNO Universal Networked Object UNO-CDR UNO - Common Data Representation UNO-RPC UNO - Remote Procedure Call UTC Universal Time Co-ordinated UU User-to-User (UU) signalling (see DSM-CC ISO/IEC13818-6 [6]) 9 TR 101 194 V1.1.1 (1997-06) 4 Use of the interaction channel Adding interactivity to the DVB environment brings on some changes in the system setup. A broadcaster is able to transfer information to the end user, using the DVB MPEG-2 transport mechanisms as defined in several DVB related ETSI deliverables. In order to make a real interactive broadcast possible, end user information has to be used. This is possible by feeding back information from the end user to an Interactive Service Provider (ISP). The ISP has contacts with the broadcaster and could even be the same organization as shown in figure 1. End User Figure 1: High level system overview for Interactive Services (IS) supporting broadcast to the home with narrowband return channels It is necessary to make a standardized way of transferring information from the end user to the ISP. This has been accomplished by on one hand a set of specifications for return channels by DVB (see e.g. ETS 300 801 [1]) for the lower layers of the OSI stack and on the other hand the specification for network independent protocols for interaction channels ETS 300 802 [2]. ETS 300 802 [2] consists of protocol stacks for: - sending data from the broadcaster or ISP to the end consumer's Set Top Box (STB) via the DVB/MPEG-2 data transmission system; - sending data from the ISP to the end consumer's STB via the interaction channel; - sending data from the ISP to the end consumer's STB via the interaction channel and vice versa. The basis of ETS 300 802 [2] is formed by part 6 of the MPEG-2 standard (ISO/IEC 13818 [4]) called Digital Storage Media Command and Control (DSM-CC) with for the interaction channel the Internet Protocol (IP) as lower layer and the MPEG-2 Data Caroussels as lower layer for the broadcast channel. Data can be content or application control/application communication or other control data such as download. Content can consist of compressed video, compressed stills, compressed audio or computer data like files or whatever other information for the end user. In clause 6 of the present document the protocol stacks used are explained. First however in clause 5 the logical channels are explained. They are also used in DAVIC for distinguishing different types of data and communication over networks. In clause 7 a particular case has been extensively described. This is the use of the protocol stacks for the "enhanced broadcast scenario" where the broadcast programme is used as a basis for interactive TV. Moreover data for managing the STB can be sent over the network. Clause 8 describes a means of providing network congestion control. 10 TR 101 194 V1.1.1 (1997-06) When an interactive TV session is to be set up, three possibilities arise (see subclauses 4.1, 4.2 and 4.3): 1) as part of a bootstrap application (at start-up) where the end user initiates the session; 2) from within an interactive application (after start-up) where the ISP asks the end user to take action; 3) when the interaction channel is already in use for a different telephone number where the ISP asks the end user to take action. 4.1 As part of a bootstrap application (at start-up) An interactive TV session is to be set up as part of a bootstrap application (at start-up) where the end user initiates the session. In this case the user controls the Server identifiers being entered into the STU. A Server identifier shall be communicated to the user possibly using a medium outside the scope of DVB, for example in an advert in a newspaper. The user then enters the number into the STU. A screen based menu (provided as part of the bootstrap application) could instruct the user to enter the number using point and click number selection. The user should be offered the opportunity to modify the number. Thus the number should be presented to the user on a screen-based system allowing him to change any codes implicit in the number, for example, the number could be modified to match the user's configuration options. 4.2 From within an interactive application (after start-up) An interactive TV session is to be set up from within an interactive application (after start-up) where the ISP asks the end user to take action. The initiation of a interaction channel during an application at (or shortly before) the point where interaction is expected, allows that application to control the semantics regarding the use of the interaction channel. It is expected that this would be done with the approval of the user, either explicitly or implicitly during the application, or by reference to configuration parameters for interaction channel use. Because the interaction channel is being used in the known semantics of an application (e.g. to place an order within a home shopping application) the telephone number can be automatically acquired by the STB. The number provided in this context may still be modified (either manually by the user or by reference to configuration options) to use the core network routing preferred by the user. 4.3 When the interaction channel is already in use for a different telephone number An interactive TV session is to be set up when the interaction channel is already in use for a different telephone number where the ISP asks the end user to take action. An application may wish to use the interaction channel when the interaction channel is already in use (either with another application running on the same STU or because the network connection is already in use). When another application on the same STU is using the interaction channel, any priority for using the channel shall be reconciled between the two applications both wishing to use the channel. If necessary, the user can be informed of the problem and asked to choose between which application takes priority in using the channel. 11 TR 101 194 V1.1.1 (1997-06) 5 Logical channels This clause explains the S1 to S5 logical channels and their use in simple terms. 5.1 Logical channel S1 The S1 logical channel is a uni-directional flow from a broadcast service provider to the STU, and a bi-directional flow between the STU and an Interactive Service Provider (ISP) carrying encoded video/audio content and associated data and binary objects to be used by the STU. MPEG-2 (ISO/IEC 13818 [4]) has been selected for the DVB coding of the video/audio content information and the Transport Stream (TS) systems layer for the multiplexing of video, audio and other data types. S1 content on the broadcast channel can be transported via a DVB specified transmission system or via TCP/IP with the return flow via an interaction channel or UDP/IP. For the mechanism used to transport TCP/IP or UDP/IP within S1 on the broadcast channel see TS 101 192 [8]. For the delivery of S1 content on the interaction channel TCP/IP or UDP/IP is used, depending on whether the S1 content is time-sensitive. 5.2 Logical channel S2 The S2 logical channel provides a bi-directional control information flow from the application layer to a destination object. MPEG-2 Digital Storage Media Command and Control (see ISO/IEC 13818-6 [6]) User-to-User Interface (DSM-CC U-U) has been chosen for the S2 interface between the STU and the service provider (Broadcast or Interactive) for application control data / application communication data and DSM-CC Download for the control of binary object and other data type information download between a service provider (broadcast or interactive) and STU. 5.3 Logical channel S3 The S3 logical channel provides a bi-directional flow used for the exchange of session information between a STU or service provider, and a session control entity in a network. The S3 logical channel is not normally required for DVB services, except in the case where session control is required e.g. when traversing multiple networks. In this case a core subset of MPEG-2 Digital Storage Media Command and Control (see ISO/IEC 13818-6 [6]) User-to-Network Interface (DSM-CC U-N) has been chosen. The resource descriptors in the session set-up messages are not required. For carrying TCP/IP or UDP/IP within the MPEG-2 stream extra DSM-CC U-N descriptors are required as specified in TS 101 192 [8]. 5.4 Logical channel S4 The S4 logical channel is a bi-directional flow supporting the call connection control and resource control functions. The S4 logical channel is network dependent and is therefore not defined in ETS 300 802 [2]. 5.5 Logical channel S5 The S5 logical channel provides a uni-directional flow used for capability transfer between a service provider and a STU, and also provides for a means of network management via the interaction channel for STU remote diagnostics. MPEG-2 Digital Storage Media Command and Control (see ISO/IEC 13818-6 [6]) User Compatibility Management for capability transfer and SNMP has been chosen for a means of optionally providing remote diagnostics. 12 TR 101 194 V1.1.1 (1997-06) 6 Protocols 6.1 TCP/IP model IP (RFC 791 [10]) has been chosen for the network layer and TCP (RFC 793 [11])/UDP (RFC 768 [9]) for the transport layer resulting in a network independent architecture. TCP/IP is used for the OSI solution for the exchange of information between heterogeneous systems. The overall TCP/IP Model is shown in figure 2 and is composed of four main layers. The internet or network layer provides for addressing, and data transfer between a source and destination host and is made up of a number of subnetworks. The network layer depends on the link layer to map to different subnetwork technologies. Applications Application High level API TCP UDP Transport IP/ICMP Network (provides addressing and data routing) Subnetworks Link e.g. ISDN, PSTN Figure 2: TCP/IP model The transport layer provides end-to-end communication between applications. Two possible transport layers are provided: - TCP: Transmission Control Protocol which provides a reliable connection-oriented transport service; - UDP: User Datagram Protocol which provides an unreliable connectionless datagram service. TCP/IP supports network management, addressing, debugging and configuration tools. The IP provides an Internet Control Message Protocol (ICMP) which reports errors between gateways and hosts. The IP is regulated by the Internet Activity Board (IAB). Relevant parts of this board are the Internet Engineering Task Force (IETF) which provides for Network Management and the Internet Architecture Task Force (IATF) which works on the Internet layer. 6.2 Internet Protocol (IP) The IP provides connectionless network-layer delivery services of packets between two endpoints. IP is specified in RFC 791 [10]. The solution to interconnection problems on heterogeneous networks is to use routers rather than bridges, as bridges cannot meet all the requirements for communicating between different networks. Therefore the use of IP attempts to solve these problems, by carrying inter-node routing and reporting information. IP also provides a global addressing system and procedures for establishing subnetworks. It also supports multiple Internet addresses for one node (multihoming) and allows multicasting. IP provides an unreliable, best effort connectionless packet delivery system. It allows hosts to send packets through the Internet system without regard to the network on which the destination host resides. IP therefore provides: - a specification for the format of a datagram; 13 TR 101 194 V1.1.1 (1997-06) - a routing specification (provides routing protocols such as the Exterior Gateway Protocol (EGP) and Open Shortest Path First (OSPF)); - a set of rules which define how hosts and gateways should process received dataframes. IP provides for "fragmentation" of packets and their re-assembly at the destination host if the packet size sent is larger than the maximum packet size of the subnetwork. The format of the IP datagram is shown in figure 3. (Provides TCP segment checksum) IP header TCP header Application data IP segment (6 to 1 500 bytes) Figure 3: IP datagram format The IP functions provided are: - Addressing: Internet Source Address, Internet Destination Address, Internet to Subnetwork Address Mapping, Destination ULP (8-bit Upper Layer Protocol) Identification e.g. TCP; - Routing: through gateway tables or source routing; - Type of Service: specifies priority, delay, throughput and reliability indications; - Time to Live: specifies number of nodes the datagram may traverse before it is destroyed; - Security Level: 16 value indication. 6.3 Transmission Control Protocol (TCP) The TCP Protocol provides for connection-oriented assured data stream delivery between two end-points. Delivery of "urgent data" is also supported. TCP is specified in RFC 793 [11] and is used for carrying control and management information. TCP provides a reliable communication platform between pairs of ULP processes in logically distinct end systems. The TCP layer provides connection-oriented data transfer which is reliable, ordered, full duplex and flow-controlled. TCP is not aware of the network topology or packet size limitations. TCP needs to only supply global addressing and control of information with each segment of data to be delivered. TCP also allows the ULP to identify the local or remote IP address in multihoming environments. 6.3.1 TCP services provided The TCP services provided are: - multiplexing service; - connection management service which provides establishment, termination and maintenance; - data transport service - full duplex, timely, flow controlled, error checked and security; - error reporting; - TCP services follow standard connection protocols i.e. open, data transfer, close, exception and status. 14 TR 101 194 V1.1.1 (1997-06) 6.3.2 TCP connections and ports TCP connection between two ULPs is a concatenation of node and port addresses. The basic connection structure is as shown in figure 4: ULP ULP Ports Ports Pa Pb TCP TCP IP(A) IP(B) Network Figure 4: TCP connection structure Four addresses are concatenated: - the local port number (source); - the local Internet address (source); - the remote port (destination); and - the remote Internet address (destination). One ULP requests through a "passive open request" that its local TCP perform a listen on a named port, indicating that the ULP is willing to accept a connection with a remote ULP. The passive open request shall provide a local port number and the local port number will assign a Local Connection Name (LCN). Remote ULP starts the connection by asking its local TCP to perform an active open to an identified remote node and port address on the remote TCP. The remote port number which is in a listen state shall be known and the concept of well known port addresses is used (port addresses are set aside for certain ULPs) e.g. specific addresses are assigned for SNMP. The TCP open sequence is followed by a TCP data phase which provides full duplex transmission, flow control and error control. This is then followed by a close sequence, which is similar to the TCP/IP open sequence. 6.3.3 TCP optional extensions for high performance networks In the case of transporting S1 content on the interaction or broadcast channel via TCP/IP, where the bit rate required is greater than 150 kbit/s, then the optional extensions as specified below may be used. TCP extensions for high performance networks in the case of long delay networks are as specified in RFC 1323 [17]. This is intended to overcome the protocol inefficiency of TCP/IP in the presence of a network with a large data rate "x" delay product. The main problem with TCP is that it exhibits poor efficiency over paths that have a large product of bit-rate and round- trip delay. The problem exists in that the TCP window size is restricted to 216 bytes and with large delay networks this will mean that the maximum transfer rate supported would be insufficient. RFC 1323 [17] provides modified versions of the TCP kernel files and utilities. The enhancements specified affect window scaling, time stamps and protection against wrapped sequences. In particular the maximum TCP window size can be set to 230 bytes. These measures give significant improvement in terms of transfer time in these types of networks. 15 TR 101 194 V1.1.1 (1997-06) 6.4 User Datagram Protocol (UDP) The UDP provides for unassured delivery of packets between two endpoints. UDP is specified in RFC 768 [9] and is used for carrying control and management information. UDP provides a simple transport service in the form of a connectionless datagram service between users. There is no guarantee that the message has been delivered, no duplicate protection and no indication that the addressed destination is available or active. UDP uses the functionality of the IP layer with a low overhead transport service. A 16-bit checksum is provided in the UDP header and data portion as an option. If the checksum is in error at the destination then the packet is discarded. If the checksum field is zero at the receiving end, it indicates that the checksum was not used by the sending end. The option not to use the checksum is controlled at the UDP/application interface. The UDP datagram is formed into an IP message and transmitted across the Internet to the destination IP. The datagram may be lost or duplicated in the Internet or at the destination node and application. Any sequencing or responses to the datagrams shall be performed by the application process and its associated protocols. In the case of real-time delivery where reliability is non-essential then UDP may be used. 6.5 Point-to-Point Protocol (PPP) PPP has been chosen for providing link layer connections to different subnetworks such as PSTN. RFC 1661 and RFC 1662 [13] specify the PPP. PPP provides a means of encapsulating IP packets over point-to-point serial links. PPP is composed of three parts: 1) High Data Link Control (HDLC): method for encapsulating IP packets over serial links; 2) Link Control Protocol (LCP): establishes, configures and tests the data link; 3) Network Control Protocols (NCP): provides for address negotiation and compression on different network layers. The following configuration for the PPP link shall be supported as recommended in appendix A of RFC 1662 [13]: - async control character map; - magic number; - address and control field compression; - protocol field compression. 6.6 Multilink Point-to-Point Protocol (MP) MP allows for the use of multiple Point-to-Point Protocol (PPP) links to be aggregated to provide a single transmission link for use by the IP layer (could be used for example in an ISDN interaction channel). It is an extension to PPP and is interoperable with PPP. MP is specified in RFC 1717 [14]. 6.7 SNMP and MIB Simple Network Management Protocol (SNMP) and implementation of the Management Information Base (MIB) is optional for DVB Interactive Services (IS). SNMP is a network management protocol which is used to remotely manage a system across a TCP/IP network. For DVB Interactive Services, SNMP is be used to exchange diagnostic information between a STU (SNMP agent) and an Interactive Service Provider ISP (SNMP manager). The data to be exchanged is defined in a MIB. 16 TR 101 194 V1.1.1 (1997-06) SNMP is specified in RFC 1157 [16]. The SNMP protocol defines a set of procedures and a protocol with which management information for a STU can be read or altered by logically remote users, such as a service provider. SNMP uses the UDP when communicating with its peers. The MIB defines the objects to be managed. Each object has a name, a syntax and an encoding. Defined object groups are related to TCP. The MIB chosen for DVB Interactive Services is the DAVIC Management Information Base (MIB) as defined in annex A of DAVIC 1.0 [5]. This allows for monitoring the capabilities of a users STU and the ability to poll different parts of the STU to monitor their operational state, using SNMP. The STU MIB is defined under the DAVIC (enterprise) node which is registered with the IETF. The naming structure for this MIB allows for future versions under this DAVIC node. Security of access shall be implemented in the STU management agent and is not explicit in the MIB definition. The MIB provides support for DSM-CC user compatibility management with the entire string incorporated as a single STU MIB object. Therefore any changes to the DSM-CC User Compatibility (see subclause 6.10.4) shall be transparent to the STU MIB. Access to the MIB information can be made by an agent in the access network or from a service provider. Examples of information which can be obtained from the MIB are: - STU General Group: - STU administrative state (locked or unlocked); - STU system-up time; - service location; - manufacturer codes; - IP address; - status information group; - security detector group; - software module group; - processor module group; - memory module group; - power module group; - user device module group; - STU notification group. 17 TR 101 194 V1.1.1 (1997-06) 6.7.1 SNMP service SNMP service: - uses UDP datagram service to exchange network management information; - groups of SNMP entities are called communities. SNMP also provides authentication capabilities; - asynchronous communication; - controls access to the MIB database through read/write access modes; - provides five services: 1) get request: retrieves a variable; 2) get response: returns a requested variable; 3) get next request: retrieves a list; 4) set request: changes a variable; 5) trap: sends unsolicited network management information to an administration centre. NOTE: SNMP v2 adds two more messages and also enhances security: - get-bulk-request: allows for bulk requests; - inform-request: for manager-manager communication. Traversal of nodes is also used to allow an efficient method of determining which variables a managed node supports and it is also a necessity to allow browsing through tables. 6.7.2 SNMP network management SNMP uses trap-directed polling. I.e. when an extraordinary event occurs, the managed node (STU) sends a single simple trap to the management station (Interactive Service Provider (ISP)) which is responsible for initiating further interactions to determine the nature and extent of the problem. Since traps may be sent unreliably then low frequency polling is also used as a backup. Traps are defined only for extraordinary events and convey little information. No support for thresholds is provided. Figure 5 summarizes this approach. Trap-directed polling Trap ISP STU Read (Write) Figure 5: SNMP network management 18 TR 101 194 V1.1.1 (1997-06) 6.7.3 Structure of management information MIB: virtual information store, holder of named objects, objects administratively identified. Managed objects: object identifier (name) - uses subset of ASN.1 syntax, BER - basic encoding ASN.1 rules. Name structure: Based on a hierarchical format. Base nodes are ISO, CCITT and ISO/CCITT. SNMP ASN.1 syntax subset: - Types: integer, octet string, object identifier, null, enumerated integer, constructor types. - Defined types: Ip address, counter, gauge, timeticks, opaque. Object type consists of five fields: object identifier, syntax, definition, access (read only, read - write or not accessible), status (one of mandatory, optional or obsolete). NOTE: A second MIB (MIB-II) has been defined which supports network monitoring and management for the transport layer and below only. 6.8 IPCP and assigned numbers The PPP Internet Protocol Control Protocol (IPCP) provides the mapping rules between IP and PPP. IPCP is specified in RFC 1332 [12]. IPCP also provides the Network Control Protocol (NCP) for PPP and provides for IP address allocation and TCP header compression in order to reduce latency on the interaction channel. The following protocols are specified in RFC 1340 [20]. Assigned numbers shall be supported. 0021 Internet Protocol (IP); 002d Van Jacobsen compressed TCP/IP; 002f Van Jacobsen uncompressed TCP/IP. 6.9 CHAP and PAP The STB may optionally support Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP) as defined in RFC 1334 [19] for authentication. The CHAP is a mechanism used to authenticate an end user over PPP. The party that wishes to authenticate sends its peer a one-time challenge. The authenticated party scrambles the challenge using its password and returns the result to the authenticating party. The authenticating party compares the result returned with the expected result. If they match, authentication is passed, if no match is found the authenticating party should clear the line. NOTE 1: Scrambling is an irreversal algorithm (MD5). NOTE 2: Password is never transmitted over the line. The Password Authentication Protocol (PAP) provides a simple method for the peer to establish its identity using a 2-way handshake. This is done only upon initial link establishment. After the link establishment phase is complete, an Id/Password pair is repeatedly sent by the peer to the authenticator until authentication is acknowledged or the connection is terminated. PAP is not a strong authentication method. Passwords are sent over the circuit "in the clear", and there is no protection from playback or repeated trial and error attacks. The peer is in control of the frequency and timing of the attempts. Any implementations which include a stronger authentication method (such as CHAP) shall offer to negotiate that method prior to PAP. This authentication method is most appropriately used where a plaintext password shall be available to simulate a login at a remote host. In such use, this method provides a similar level of security to the usual user login at the remote host. 19 TR 101 194 V1.1.1 (1997-06) 6.10 Digital Storage Media - Command and Control (DSM-CC) The DSM-CC specification (see ISO/IEC 13818-6 [6]) is a set of protocols to control and manage MPEG streams. The concepts and protocols apply to a more general use. DSM-CC is an integral part (Part 6) of the MPEG-2 standards (ISO/IEC 13818 [4]). Some of the functions supported by DSM-CC include: download of data, access to remote files, compatibility assurance between services and the user terminal, control of audio/video streams (including trick-modes), events indicated by markers in the audio/video stream and a consistent unambiguous timeline in audio/video streams. DSM-CC supports both broadcast as well as point-to-point network connections. DSM-CC does not specify the underlying physical, data link, transport or Remote Procedure Call layers of the overall protocol stack. The DSM-CC system reference model is given in figure 6. NETW ORK C onnection (U ser-to-U ser) C L IE N T SERVER S R M (note) U ser U ser to U ser to U ser to U ser N etw ork U ser U ser to to N etw ork N etw ork C onnection (U ser to N etwork) NOTE: Session ad Resource Manager (SRM) may provide session, connection, and configuration management and control. Figure 6: DSM-CC system reference model In the DSM-CC model streams and other data are sourced by a Server and delivered to a Client. Both the Server and the Client are considered to be users of the DSM-CC network. One of the functionalities provided by DSM-CC is resource management and negotiation. An example of a resource is network bandwidth. DSM-CC also manages sessions which are associated collections of resources required to deliver a service. DSM-CC defines a logical entity called the Session and Resource Manager (SRM) which provides a (logically) centralized management of the DSM-CC sessions and resources. DSM-CC refers to the combination of the underlying network and the SRM as the Network (capital N). DSM-CC signalling between the Client and SRM (network) or the Server and SRM is called User-to-Network (UN) signalling. DSM-CC signalling between the Client and Server is called User-to-User (UU) signalling. In a typical DVB narrowband interactive service there is no need for resource management since the bandwidth allocation of the broadcast channel is unilaterally determined by the broadcast service provider and the interaction channel is allocated on a per user basis. Hence, within the DVB context, the DSM-CC UN protocols are only used in special cases to provide session control (ETS 300 802 [2]). Parts of the DSM-CC specification which are specifically relevant to DVB narrowband interactive services include: User-to-User (UU), User-to-User (UU) object carousels, download and user compatibility. 20 TR 101 194 V1.1.1 (1997-06) 6.10.1 DSM-CC User-to-User The DSM-CC User-to-User primitives enable a wide-range of multimedia applications to run using the MPEG delivery system in heterogeneous environments. DSM-CC User-User provides access to multimedia objects such as streams and files. The DSM-CC User-to-User part of the standard defines two interfaces, the Application Portability Interface and the Client-Service Interoperability Interface as shown in figure 7. Application Application Portability Interface DSM-CC Library + I t f OS + Transport Client-Service Interoperability Interface Remote Service Figure 7: Application and Service Interfaces The DSM-CC User-to-User Application Portability Interface (service gateway; stream; file; directory) applies both to local interaction based services (i.e. without a return channel) as well as to services with one-way and two-way interactivity. In the former case the data is broadcasted repetitively using so called User-to-User object carousels. In the latter case the data is delivered on demand using the Client-Service Interoperability Interface. The Client-Service Interoperability Interface requires the use of Remote Procedure Calls (RPC) to invoke operations over the network. Within DAVIC and DVB Interactive Services (IS) the Internet Inter-ORB Protocol (IIOP) (see subclause 6.11) has been selected. 6.10.2 DSM-CC User-to-User object carousels and BIOP The U-U API provides Clients with a standardized mechanism to access multimedia assets. For interactive networks, the U-U API is tightly coupled to the Client-Server Interoperability Interface for interoperability purposes. The use of the U-U API is, however, not limited to interactive networks and may be used to access, for example, local objects and broadcasted objects. In order to do so, the Client has to implement a subset of the User-to-User functionality locally and has to access the broadcast network for new data when necessary. Figure 8 illustrates this situation. Application U-U API Local U-U Implementation Object Retrieval Interface Memory Broadcast Network Interface Figure 8: User-to-User API and interfaces 21 TR 101 194 V1.1.1 (1997-06) The main difference in using the U-U API in broadcast networks is that the Client cannot communicate with the Server that provides the objects. This difference implies that the Server has to periodically broadcast every object to facilitate access by Clients. Because bandwidth is generally limited in a broadcast network, Clients will experience a non-zero access-time to the objects. To limit the access time for particular key-objects (such as directories), the Server may choose to send these objects more frequently than others. The periodic transmission of application data in a Data Carousel is standardized in DSM-CC Download. In particular, it is specified how Modules can be used to broadcast application data, how these Modules are fragmented into smaller Blocks, and how coherency problems due to Module updates can be detected. However, to insure interoperability between Clients and broadcast Servers, the carriage of the U-U objects in the Modules and the transportation of the Modules in the Broadcast network is standardized also. In Broadcast networks, one Server may serve many Clients with different architectures. Therefore, a representation protocol is necessary that specifies how the U-U objects are carried on the wire. As described above, in Interactive networks, the Object data is transported via the Internet Inter ORB Protocol (IIOP) on top of TCP/IP. In IIOP, the bits- on-the-wire are defined by the Common Data Representation (CDR) to make an exchange of objects between ORB with different architectures possible. In order to avoid having two different representation protocols in hybrid Clients, U-U Object Carousels also make use of CDR. The present document is compatible with the Object Request Broker (ORB) framework as defined by CORBA [15]. Therefore, it is called the Broadcast Inter-ORB Protocol (BIOP). The BIOP specification consists of three elements: 1) Broadcast IOP profile body definition The definition of the BIOP profile body. The profile body provides a unique reference an U-U object in the broadcast network. 2) Broadcast IOP message formats BIOP consists of four messages which share a common message structure. These messages are converted to bits- on-the-wire by means of the Common Data Representation (CDR) as specified by UNO. BIOP messages convey among others the U-U objects. 3) Broadcast IOP message transport BIOP messages are conveyed in modules of the data carousel. A module may convey multiple BIOP messages. The modules are fragmented into blocks (as defined by DSM-CC download) and are conveyed in DSMCC_sections. 6.10.3 DSM-CC download DSM-CC download is intended as a fast and lightweight data or software download mechanism from a Server to a Client. A complete download operation transfers a download "image" to the Client. The image is sub-divided into one or more "modules". The entire image and each module are divided into "blocks". Various network models are supported, including both a traditional flow-controlled download as well as a broadcast download option that are both based on the same message set. The download protocol can be used to implement data carousels. The data carousel functionality embodies the periodic transmission of information to Clients by a Server. By definition, data carousels convey the information in modules. In general, the data carousel mechanism is part of a three layer stack that is necessary to construct real-world application carousels (see figure 9). Namely, above the data carousel layer, the application layer resides, which specifies the content that is conveyed in the modules (e.g. boot-images or application objects). Below the data carousel layer, the transport layer resides, which specifies how the modules are transported (e.g. DSMCC_sections in Transport Streams (TS)). 22 TR 101 194 V1.1.1 (1997-06) Application layer Data Carousel layer Transport layer Figure 9: Layering of real -world application carousel Depending on the type of the content, data carousels are divided into three types: 1) single image carousels; 2) multiple image carousels; and 3) object carousels. 6.10.4 DSM-CC user compatibility The DSM-CC user compatibility DAVIC 1.0 [5] allows for capability management between a STB and a Server. DSM-CC compatibility descriptors are used to transport the list of specific interfaces (such as hardware/software model and version numbers and additional information as specified by the organization. This specified type could be a 3-byte IEEE organizational unique identifier as described in IEEE 802 [3]) on a STB to a Server, so that the Server can make decisions as to the appropriate data to download to the STB. 6.11 UNO-RPC, UNO-CDR, IOR (GIOP and IIOP) The Client-Service Interoperability Interface of DSM-CC User-to-User requires the use of Remote Procedure Calls (RPC) to invoke operations over the network. Furthermore a standard data representation (how the data is coded as "bits-on-the-wire") is required for interoperability as well as a standard format to reference objects. Within DSM-CC the preferred and default specification for all three of the above is Universal Networked Objects (UNO) as defined in the OMG specification RFC 1717 [14]. This contains the Common Data Representation (CDR) and the Interoperable Object Reference (IOR) specifications. Together they form the General Inter-ORB Protocol (GIOP). GIOP requires a reliable message transport layer. The default choice for this is the TCP/IP protocol stack from Internet. Within the UNO specification the combination of GIOP with TCP/IP is identified as Internet Inter-ORB Protocol (IIOP). The use of IIOP is specified by DAVIC as well as by DVB Interactive Services (IS). NOTE: For large scale systems serving more than a few hundred users a multi-threaded implementation of the RPC should be used. 6.12 Object Request Broker (ORB) An ORB is a concept from the Client-Server computing field which enables interoperability between heterogeneous Clients and Servers. Implementing an ORB is not required within the context of the DVB narrowband Interactive Services. 23 TR 101 194 V1.1.1 (1997-06) 7 Use of the protocol stacks for enhanced broadcast services This clause describes how an application in the STB uses the Systems for Interactive Services (SIS) protocol stacks ETS 300 802 [2]. 7.1 Use of the DSM-CC User-to-User protocol The DVB scenario covers the use of the DSM-CC User-User primitives and DSM-CC UU Download protocol to request data. Data can be delivered in either DSM-CC Download Data Blocks or DSM-CC objects. The delivery path for requested data is either the MPEG private data channels or the interaction channel. The DSM-CC Broadcast Inter ORB Protocol (BIOP) allows a unique reference to be made to a UU object within a broadcast network. BIOP is described in Informative annex F of ISO/IEC 13818-6 [6]. 7.1.1 Data transfer and download Data transfer and download describe two techniques of loading data into the STU. These two techniques map to two DSM-CC User-User facilities available to the application control software in the STU. Data transfer can be provided by User-User interaction. Download is to be provided by the DSM-CC download protocol. The download and data transfer mechanism can be categorized by the following two cases: 1) synchronized data transfer or download; and 2) unsynchronized data download or data transfer. 7.1.1.1 Synchronized data transfer or download A synchronized data transfer (one where data is requested and specifically provided by the service provider in response to that request) can use: - a response sent over the interaction channel; - a response sent over the interaction channel which refers to data to be transmitted over a private MPEG-2 section in a broadcast MPEG-2 Transport Stream (TS). For a requested download where a small amount of data is requested data may be transferred across the interaction channel from the Server to the STU. The data is transferred in a DSM-CC User-User message in the response to an RPC from the STU. For larger data transfer the response sent over the interaction channel to the STU contains DSM-CC User-User BIOP information that uniquely identifies an object in a particular broadcast stream in a particular broadcast network. A timeout is also set, after which, the requested object shall no longer be broadcast. 7.1.1.2 Unsynchronized data download or data transfer Data requested by the STU can be transmitted on a longer term basis than for the "synchronized" download case. The user accesses or is granted access to the data transmission by first receiving a response from the Server control data which is transmitted to the user. One example of long-term data transmission is to use Object Carousels, which repeatedly broadcast data. The DSM-CC User-User download protocol includes a negotiation phase to establish the requirements for the download, followed by the download. The DSM-CC User-User download protocol informs the STU of a unique identity of the required data, the location of the required data, and the period of time over which it can be accessed. It may be necessary to supply the user with any access control mechanisms required to read the data, such as decryption keys. 24 TR 101 194 V1.1.1 (1997-06) Depending on the success of the download, it may be necessary to repeat some or all of the download. Any repetition of the download shall be co-ordinated between the service provider and STU. The DSM-CC User-User download protocol allows retransmission of selected blocks which have failed to download successfully. EXAMPLE 1: DSM-CC UU scenario 1: STU requesting data for point-to-point delivery: a) Data sent over broadcast channel to STU 1) RPC request containing DSM-CC UU primitives from STU to Server; 2) RPC reply from Server to STU RPC OK Reply identifies the network, MPEG-2 TS, channel, object (using DSMCC BIOP) which is to be delivered over the broadcast channel, together with a timeout for the receipt of the object by the STU; 3) Content transmitted in MPEG2 private sections to STB. b) Data sent over the interaction channel 1) RPC request from STU to Server; 2) RPC reply from Server to STU RPC OK including the Content/Data embedded in the response DSM-CC UU primitive response. EXAMPLE 2: DSM-CC UU scenario 2: STU requests a download: a) Data sent over broadcast channel to STU 1) Request containing DSM-CC Download Control from STU to Server; 2) DSM-CC download control dialogue between STU and Server. During the download control dialogue the Server informs the STU of the identity of the download data block(s) to be delivered over the broadcast channel. The BIOP identifies the download data block messages in which the requested data is to be sent over the broadcast channel; 3) Content transmitted inMPEG2 private sections to IP address of STB. b) Data sent over the interaction channel 1) Request containing DSM-CC Download Control from STU to Server; 2) DSM-CC download control dialogue between Server and STU. The Dialogue includes the Content/Data embedded in a response. User compatibility fields in "DownloadInfoResponse" allow the STU and Server to identify what download capability (hardware and software) the STU has. 25 TR 101 194 V1.1.1 (1997-06) 8 Network congestion control This clause considers interactive broadcast services, where the S1 broadcast signal is delivered through a distribution delivery system (e.g. cable or satellite) and the return channel for interactivity is provided through a telecommunications network (e.g. PSTN or ISDN). Typical services that can be offered via interactive broadcast are services where a large number of consumers may react on broadcast programs: tele-voting, quiz-games, reaction on commercials, ordering pizzas, etc. For this type of services the following three parameters are involved: 1) reaction time: Within what time shall all the reactions of the consumers be recorded and processed? 2) accuracy: How many consumers' reactions have to be processed? 3) investment: The number of lines (or modems) to service the reactions of consumers. In general it can be said that the service provider would like to get as many reactions in an as short as possible time with little investments, i.e. only a few lines and modems. This can not be realized in practical situations. Two extreme cases are considered: EXAMPLE 1: A service provider would like to have the opinions of an as large as possible population. The allowed time to retrieve this information may be rather long, e.g. a day. A typical example would be to have a government election polling where the service provider would like to collect the opinions of as many people as possible and he announces the results the next day. EXAMPLE 2: A service provider asks the watching audience about their favourite artist and he would like to show the results within five minutes (e.g. after the commercial break). In this case the service provider is probably satisfied if he gets an estimation of the result from of a representative population, e.g. 3 000 samples out of a much larger watching population. These two examples are two extremes of a wide range of criteria between choosing the amount of people to react and the time within these reactions have to be recorded. Figure 10 shows the two extremes. Short reaction time Reaction time interval Long reaction time Representative selection Number of reacting consumers As many as possible Selecting favourite artist Government election polling Figure 10 8.1 Traffic shaping After a question of the service provider (whether it is the government election polling or the favourite artist selection) the consumers choose right away and press their selection via the remote control. In order to prevent that all STB dial the service provider at the same time a "time randomizer" is required to spread the reactions on the query over time. For instance in the case of the government election polling application several millions of people may select their favourite political party at frankly the same time. The STB however dials the service provider to indicate the consumers choice at a random moment between two defined moments in time. This "time randomizer" function is sufficient for the first example (government election polling) where the service provider would like to have the opinion of as many people as possible over a rather long time. However, if the service provider would like to have the reaction within five minutes, the network operator can not allow that several millions STB dial within a five minute time interval. Therefore a second function a "threshold randomizer" is required. This "threshold randomizer" determines whether or not the STB will actually dial the service provider to make the response of the consumer known. If the service provider has a global idea how many people watch his programs, and he knows how many reactions will be sufficient to have a representative selection, he can determine the value of the"threshold randomizer". 26 TR 101 194 V1.1.1 (1997-06) 8.2 IDL description of traffic shaping To allow for traffic shaping an object implementing two mechanisms are defined: 1) reduce the number of callers if necessary (the "threshold randomizer"); 2) spread the responses in time (the "time randomizer"). The first point is achieved by signalling a threshold to the receiving STB. If the user wants to participate in an interactive program, the STB generates a random 16-bit number. Only if this number is higher than the threshold, the box will place a call to the service provider. The second point is implemented by giving start and stop times in between which a STB may place its call. This should happen at a random moment in this interval. If the service provider is unreachable, the STB may try again after a specified time. Again a random time in the resulting interval should be chosen. This minimum waiting time after a try is introduced to prohibit traffic explosions when there is very little response time left. The "giveNextDialTime" function of the "trafficShaping" object implements the above mentioned mechanisms. If the "giveNextDialTime" returns true then the time when the STB can dial out is given in the variable "dialTime". Otherwise false is returned and the STB is not allowed to call out. A description of the semantics of the variables involved is given in table 1. Table 1: Description of the semantics typedef short date; typedef char[3] time; struct dateTime { date aDate; time aTime; } interface trafficShaping { attribute short numResponseThreshold; attribute dateTime responseStartTime; attribute dateTime responseEndTime; attribute time retryWaitTime; attribute short responseAttemptLimit; // next time: result false -> not allowed any more boolean giveNextDialTime (out dateTime dialTime); }; numResponsesThreshold: This 16-bit field signals the threshold above which a set-top unit may initiate a call to a service provider. The STU should compare this value with an internally generated 16-bit unsigned integer random number. responseStartTime: This 40-bit field contains the start time of the responses in Universal Time Co-ordinated (UTC) and Modified Julian Date (MJD) . This field is coded as 16 bits giving the 16 Least Significant Bits (LSB) of MJD followed by 24 bits coded as 6 digits in 4-bit Binary Coded Decimal BCD (see also annex C of ETS 300 468 [7]). EXAMPLE: 93/10/13 12:45:00 is coded as "0xC079124500". responseEndTime: This 40-bit field contains the end time of the responses in UTC and MJD. This field is coded as 16 bits giving the 16 LSBs of MJD followed by 24 bits coded as 6 digits in 4-bit BCD. retryWaitTime: A 40-bit field containing the date and time after which a STB is allowed to retry. It has the same coding as the response_end_time. responseAttemptLimit: This 8-bit field signals how many times a STB may try to call to a service provider. A value of zero (0) means unrestricted calling. 27 TR 101 194 V1.1.1 (1997-06) Annex A (informative): Bibliography The following material, though not specifically referenced in the body of the present document, gives supporting information. - European Project for Digital Video Broadcasting (DVB), Interactive Services Commercial Module (ISCM), ISCM-005-rev.7, October 1995: "Commercial Requirements for Asymmetric Interactive Services supporting Broadcast to the Home with Narrowband Return Channels". 28 TR 101 194 V1.1.1 (1997-06) History Document history V.1.1.1 June 1997 Publication ISBN 2-7437-1584-7 Dépôt légal: Juin 1997