Television systems; Data transmission within Teletext

The former EACEM Project Team 1.4 (Data Services), the originator of the ETSI standard ETS 300 708, prepared some corrections and additions. The most significant addition is a new format of independent data line (IDL) (format B) which contains a forward error correcting (FEC) protocol rather than a cyclic redundancy check (CRC) as used with the current format A.  The requirements for this new packet are described in detail in EACEM technical report TR-039. The details are given in document J23d06, submitted to the 23rd meeting of JTC Broadcast.

Televizijski sistemi – Prenos podatkov v sistemu Teletext

General Information

Status
Published
Publication Date
30-Nov-2003
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
01-Dec-2003
Due Date
01-Dec-2003
Completion Date
01-Dec-2003
Standard
SIST EN 300 708 V1.2.1:2003
English language
48 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)


2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Televizijski sistemi – Prenos podatkov v sistemu TeletextTelevision systems; Data transmission within Teletext33.170Televizijska in radijska difuzijaTelevision and radio broadcasting33.050.30Oprema za teleks, teletekst, telefaksEquipment for telex, teletext, telefaxICS:Ta slovenski standard je istoveten z:EN 300 708 Version 1.2.1SIST EN 300 708 V1.2.1:2003en01-december-2003SIST EN 300 708 V1.2.1:2003SLOVENSKI
STANDARD
ETSI ETSI EN 300 708 V1.2.1 (2003-04) 2
Reference REN/JTC-TTEXT-DT-R1 Keywords broadcasting, data, Teletext, TV ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - 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
Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, send your comment to: editor@etsi.org 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 2003. © European Broadcasting Union 2003. All rights reserved.
DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTM and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. SIST EN 300 708 V1.2.1:2003

ETSI ETSI EN 300 708 V1.2.1 (2003-04) 3
Contents Intellectual Property Rights.6 Foreword.6 1 Scope.7 2 References.7 3 Definitions and abbreviations.7 3.1 Definitions.7 3.2 Abbreviations.8 4 Page Format - Clear.9 4.1 Introduction.9 4.1.1 General points.9 4.1.2 Advantages.9 4.1.3 Disadvantages.9 4.2 Data streams.10 4.2.1 Application data blocks.10 4.2.2 Structure Header.10 4.2.3 Bundle Information structure.11 4.2.3.1 Format.11 4.2.3.2 Structure Header.11 4.2.3.3 Checksum.12 4.2.3.4 Number of Applications.12 4.2.3.5 Application Type.12 4.3 Coding of the Teletext page.12 4.3.1 Page header.12 4.3.1.1 Page number.13 4.3.1.2 Subcode.13 4.3.1.3 Control bits C4 to C14.14 4.3.1.4 Data Bytes.14 4.3.2 Packets 1 to 25.14 4.3.2.1 Valid packets.14 4.3.2.2 Packet encoding.14 4.3.2.3 Block Separator.15 4.3.2.4 Block Pointer.15 4.3.2.5 Filler Byte.15 4.3.2.6 Mapping.15 4.3.2.7 Byte coding.16 4.3.3 Packet 28.16 4.3a Page Transmission.16 4.4 Coding of the packets.17 4.4.1 Page header.17 4.4.2 Packets 1 to 25.19 4.4.2.1 Transmission order.19 4.4.2.2 The Structure Header (SH).20 4.4.2.3 Packing the data into the pages.20 4.4.3 Packet 28.21 4.5 Providing a service according to Page Format - Clear.21 4.5.1 General points on Page Format - Clear.21 4.5.2 Encoding scheme for electronic data transmission.22 5 Page Format - CA.22 5.1 General points.22 5.2 Advantages.22 5.3 Disadvantages.22 5.4 Method of coding.22 5.4.1 Teletext page data.23 SIST EN 300 708 V1.2.1:2003

ETSI ETSI EN 300 708 V1.2.1 (2003-04) 4
5.4.1.1 Scrambled Data Pages.24 5.4.1.2 Pages containing Reformatted Data.24 5.4.2 The Page Key Packet.24 5.4.2.1 Service Mode bits.25 5.4.2.2 Service Identification.25 5.4.2.3 Continuity and Repeat Indicators.26 5.4.2.4 Packet Flags.26 5.4.2.5 Data Length.26 5.4.2.6 Scrambling Method.26 5.4.2.7 The Cyclic Redundancy Check (CRC) word.27 5.4.3 Terminal Equipment Addressing Pages.27 5.4.3.1 System Key Packet.27 5.4.3.2 Shared User Packets.28 5.4.3.3 Unique User Packets.28 5.4.3.4 Service/Page Link packets.29 5.4.3.5 Link to Independent Data Line Services.29 5.5 Security of Page Format - CA.29 5.5.1 Cipher feedback algorithm.30 5.5.2 One-way function.30 5.5.3 Text scrambling.31 6 Independent Data Lines (IDL).31 6.1 General points.31 6.2 Advantages.31 6.3 Disadvantages.31 6.4 Methods of coding.32 6.4.1 Designation code.32 6.4.1.1 Transmission multiplexing.32 6.4.2 Data Channel addressing.32 6.5 IDL Format A.33 6.5.1 Format Type (FT).33 6.5.2 Interpretation and Address Length (IAL).33 6.5.3 Service Packet Address (SPA).34 6.5.4 Repeat Indicator (RI).34 6.5.5 Continuity Indicator (CI).34 6.5.6 Data Length (DL) byte.34 6.5.7 User Data Group.35 6.5.7.1 Dummy bytes.35 6.5.8 Cyclic Redundancy Check (CRC) word.35 6.5.8.1 Check word generation.35 6.5.8.2 Check result.35 6.5.9 Transmission sequence.36 6.6 Datavideo format.36 6.6.1 Packet address.36 6.6.2 Control Bytes (CB).36 6.6.2.1 Packet Continuity Indicator (CI).36 6.6.3 Masking indicator.36 6.6.4 Packet type indicator.37 6.6.5 User data group.37 6.6.6 Cyclic Redundancy Check (CRC) word.37 6.6.6.1 Check word generation.37 6.6.6.2 Check result.37 6.7 Low bit-rate audio.37 6.7.1 Method of coding.38 6.7.1.1 Decoder action.38 6.7.2 Programme-related audio service.38 6.7.2.1 Service Byte (SB).38 6.7.2.2 Control Byte (CB).38 6.7.2.3 Audio data.39 6.7.3 Programme independent audio service.39 6.7.3.1 Service Byte (SB).39 6.7.3.2 Control Byte (CB).39 SIST EN 300 708 V1.2.1:2003

ETSI ETSI EN 300 708 V1.2.1 (2003-04) 5
6.7.3.3 Audio data.39 6.8 IDL Format B.39 6.8.1 Packet structure.39 6.8.1.1 Format Type.40 6.8.1.2 Application Identifier.40 6.8.1.3 Continuity Index.40 6.8.1.4 User Data.40 6.8.1.5 FEC.40 6.8.2 Forward Error Correcting algorithm.41 6.8.2.1 Introduction.41 6.8.2.2 Encoding.41 6.8.2.3 Calculating FEC suffix bytes.41 6.8.2.4 Decoding.42 6.8.2.5 Detecting and correcting single byte errors.42 6.8.2.6 Correcting data blocks.43 6.8.3 Effective data rate.43 7 IDL - CA (type A).43 7.1 General points.43 7.2 Advantages.43 7.3 Disadvantages.44 7.4 Methods of coding.44 7.4.1 Block Separator.44 7.4.2 Block Formats.44 7.4.3 Block Format A.44 7.4.3.1 Block Types.44 7.4.3.2 Primary Block Key Messages.45 7.4.3.3 Secondary Block Messages and Scrambled User Data.45 7.4.3.4 System-Key Message Block.45 7.4.3.5 Shared-User Message Block.45 7.4.3.6 Unique User Message Block.46 7.4.3.7 Service Address Message Block - Independent Data Service.46 7.4.3.8 Service Address Message Block - Link to Page Format - CA.46 Annex A (informative): Additional information for Page Format - Clear.47 A.1 Use of Block Pointer, Block Separator and Block Length information.47 History.48
ETSI ETSI EN 300 708 V1.2.1 (2003-04) 6
Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://webapp.etsi.org/IPR/home.asp). All published ETSI deliverables shall include information which directs the reader to the above source of information. Foreword This European Standard (Telecommunications series) has been produced by Joint Technical Committee (JTC) Broadcast 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 Broadcast was established in 1990 to co-ordinate the drafting of standards in the specific field of broadcasting and related fields. Since 1995 the JTC Broadcast 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 CH-1218 GRAND SACONNEX (Geneva) Switzerland Tel: +41 22 717 21 11 Fax: +41 22 717 24 81
National transposition dates Date of adoption of this EN: 11 April 2003 Date of latest announcement of this EN (doa): 31 July 2003 Date of latest publication of new National Standard or endorsement of this EN (dop/e):
31 January 2004 Date of withdrawal of any conflicting National Standard (dow): 31 January 2004
ETSI ETSI EN 300 708 V1.2.1 (2003-04) 7
1 Scope The present document describes the various ways in which Teletext may be used to carry non-Teletext services. It should be used in conjunction with EN 300 706 [1]. An example is fully described in EN 300 707 [2]. The present document includes additional practical information on implementing a data service of this type. Hooks into existing Teletext services may be provided from within the application which is carried as a non-Teletext service. A data broadcast application may be pointed to from the Magazine Inventory Page (MIP) or it may be allocated a specific page number. A Code of Practice (CoP) shall ensure that services destined for the consumer may be found quickly by "low-end" Teletext decoders but this is outside the scope of the present document. There are two methods available for carrying data services. The first method carries the data within Teletext pages. The data in these pages is not suitable for direct display by a Teletext decoder and shall normally be allocated a special page number and/or have the display inhibited. The second method carries the data within Independent Data Lines (IDL) and these are independent of the page service. With both Page and IDL formats there exist versions which offer Conditional Access (CA). There are other specific IDL data services which have been defined but it is beyond the scope of the present document to cover all of these. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. • References are either specific (identified by date of publication and/or edition number or version number) or non-specific. • For a specific reference, subsequent revisions do not apply. • For a non-specific reference, the latest version applies. Referenced documents which are not found to be publicly available in the expected location might be found at http://docbox.etsi.org/Reference. [1] ETSI EN 300 706: "Enhanced Teletext specification". [2] ETSI EN 300 707: "Electronic Programme Guide (EPG); Protocol for a TV Guide using electronic data transmission". [3] ETSI EN 300 231: "Television systems; Specification of the domestic video Programme Delivery Control system (PDC)". [4] ETSI TR 101 231: "Television systems; Register of Country and Network Identification (CNI) and of Video Programming System (VPS) codes". 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: 20 ms rule: insertion of a one field period delay (20 ms) between the transmission of the Teletext page header and the next packet for that page NOTE: The delay provides sufficient time for all existing decoders to implement a memory clear. SIST EN 300 708 V1.2.1:2003

ETSI ETSI EN 300 708 V1.2.1 (2003-04) 8
application data: raw data from the service provider prior to encoding in the format of the chosen transmission method bit numbering within bytes: in common with earlier and existing Teletext specifications, the bits of a Teletext data byte are numbered 1 to 8 (LSB to MSB) data stream: sequence of bytes carried in a uniquely addressable data service encryption: process whereby a sequence of data is made secret NOTE: See clause 5.5 for further information. Hamming 8/4: coding scheme which adds four protection bits to four message bits such that a receiver can correct a single bit error and detect a double bit error in the resulting 8-bit byte NOTE: Defined in full in EN 300 706 [1]. network operator: organization responsible for the compilation of the Teletext service for insertion into the available Vertical Blanking Interval (VBI) lines scrambling: process whereby a sequence of data is made unintelligible NOTE: See clause 5.5 for further information. service provider: organization responsible for the creation and supply of the data service application transmitted bit order: unless otherwise stated, the bits of a Teletext byte are transmitted least significant bit first 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AUDETEL AUdio DEscription of TELevision BL Block Length BP Block Pointer BS Block Separator BT Block Type CA Conditional Access CI Continuity Index CoP Code of Practice EPG Electronic Programme Guide FB Filler Bytes IDL Independent Data Lines LSB Least Significant Bit MIP Magazine Inventory Page MSB Most Significant Bit RI Repeat Indicator SH Structure Header VBI Vertical Blanking Interval
ETSI ETSI EN 300 708 V1.2.1 (2003-04) 9
4 Page Format - Clear 4.1 Introduction 4.1.1 General points The application data is broadcast within uniquely addressable Teletext pages. Unlike the Page Format - CA method described in clause 5, any conditional access requirements must be included in the data prior to encoding. It is possible to carry several independent applications within a page identified by a 3-digit page number. Up to 15 separate data streams can be accommodated within one such page, individual streams being uniquely addressable via part of the subcode component of the page header. Each data stream can carry multiple applications. Within each stream, blocks of application data are preceded by service identifier and length information. Pointers placed at the start of each packet indicate the location of block boundaries within the page. Data streams can be broadcast with or without adherence to the 20 ms rule. It is possible to provide a total service, which is constructed from more than one data stream, requiring the receiver to handle more than one data page. An example is an electronic programme guide service as defined in EN 300 707 [2]. One stream, carrying "now and next" type information, is intended for reception by all receivers and is transmitted obeying the 20 ms rule. A second stream, providing details on future programmes, is aimed at more sophisticated receivers which do not require the 20 ms delay. The two streams can be interleaved implying a suitable receiver may have to acquire and process two or more separate data pages simultaneously.
4.1.2 Advantages This method is appropriate for reception by all existing Teletext decoders. A default coding scheme is defined in order that services may be offered using standard Teletext systems. To allow for future applications, the default method can be overridden by including an additional packet 28 per page to define the coding scheme in use.
The network operator requires no knowledge of the application data he is transporting apart from knowing where each block commences and how long it is. Each of the application data bytes is assumed to contain 8 usable bits and it is up to the data service provider to determine how they are used. It is also left to the data service provider to apply access control or any additional protection to those parts of his service that require it. It is possible to sub-divide a service into those parts which will be required by all decoders and those parts which will only be required by some, perhaps more sophisticated, decoders. It is not necessary to synchronize the application data to the Teletext page format. Block level synchronization at the decoder is assured by means of a simple but robust method of dual pointing to each block start location. 4.1.3 Disadvantages This method is not efficient for sending a small amount of data as there is always the overhead of including a page header and the optional, but useful, packet 28. Also, data transmission efficiency is further reduced if the pages are sent in a fragmented way in order to interleave the data service with the primary Teletext service. SIST EN 300 708 V1.2.1:2003

ETSI ETSI EN 300 708 V1.2.1 (2003-04) 10 4.2 Data streams An application data block is prepared for transmission by the addition of service identifier and block length information known as a Structure Header. Ultimately such entities are concatenated to form a data stream that is then mapped to Teletext pages. It is also necessary to include additional data in the stream in the form of a Bundle Information Structure to identify the different applications that may be present. A representative data stream is shown in figure 1. Application DataBlock NApplication DataBlock N+1Transmitted Data StreamApplication Data BlocksStructureHeaderBundle InformationStructureApplication DataBlock NStructureHeaderApplication DataBlock N+1StructureHeaderData added prior to transmission Figure 1: Formation of a data stream from application data blocks 4.2.1 Application data blocks The application data is assumed to exist in the form of individual blocks of up to 2 047 bytes. The application data is broadcast without further error protection or access control data being added to the data stream during the encoding and transmission process. 4.2.2 Structure Header A 16-bit Structure Header (SH), figure 2, shall be added to the start of each application data block. The first 5 data bits provide the Application ID value. This allows up to 31 different services to be interleaved within a particular data stream identified by a 3 digit page number and a specific value for the S3 component of the page sub-code (see clause 4.3.1.2). The actual value for the Application ID is allocated by the overall service provider. The Application ID value of 0 is reserved for the Bundle Information structure, clause 4.2.3, which provides the system with information about the services carried in this data stream. The remaining 11 data bits of the Structure Header define the Block Length (BL). This indicates the size in bytes of the following block of application data. The maximum block length is 2 047 bytes. The 16 bits of the Structure Header are Hamming 8/4 encoded prior to transmission. SIST EN 300 708 V1.2.1:2003

ETSI ETSI EN 300 708 V1.2.1 (2003-04) 11
Application ID bits 1 to 4 Application ID bit 5 Block Length bits 1 to 3 Block Length bits 4 to 7 Block Length bits 8 to 11 Structure Header Four Hamming 8/4 encoded bytes
NOTE: Fields shown in transmission order from left to right.
LSB transmitted first. Only the message bits of the Hamming 8/4 encoded bytes are shown.
Figure 2: The Structure Header 4.2.3 Bundle Information structure A Bundle Information structure (BI) shall be inserted in the data stream at periodic intervals to identify the different applications present. For each application (except for itself) the structure defines an identifier and links it to a code that indicates the application type. Once a receiver has this information, it can identify the data blocks in the stream belonging to a particular application by the Application ID value carried in the Structure Header. An application may specify a minimum rate at which BI structures should be inserted in the data stream. 4.2.3.1 Format The format of a BI structure is shown in figure 3 and the syntax is described in table 1. All the data is Hamming 8/4 encoded before transmission. All bits are transmitted LSB first. Structure HeaderApplication ID= 0x00BlockLengthChecksumNumber ofApplications (N)ApplicationType - 2ApplicationType - NApplicationType - 1 Figure 3: Format of the Bundle Information structure Table 1: Syntax for the Bundle Information structure
Bundle Information Structure No. of data bits No. of transmitted bytes Application ID (= 0x00) } Structure Block Length
} Header 5 11 4 Checksum 8 2 Number of Applications 8 2 for (i = 1; i < = Number of Applications; i++) {
Application Type 16 4 }
NOTE: All bits are Hamming 8/4 encoded prior to transmission.
4.2.3.2 Structure Header As defined in clause 4.2.2. The Application ID value is fixed at 0x00. SIST EN 300 708 V1.2.1:2003

ETSI ETSI EN 300 708 V1.2.1 (2003-04) 12 4.2.3.3 Checksum The checksum shall be calculated before the data bits have been Hamming 8/4 encoded. The checksum includes the contents of the Application ID, Block Length, Number of Applications and Application Type fields. It is calculated as follows: The data bits of these fields are concatenated and divided into 4-bit nibbles. The nibbles are then expanded into 8-bit bytes with the four most significant bits set to 0. These bytes are summed (modulo 256) and the checksum is (0x100 - sum of bytes) modulo 256. The checksum is split into two nibbles and each is Hamming 8/4 encoded prior to transmission. 4.2.3.4 Number of Applications This Number of Applications field defines the number of applications carried in the data stream. The maximum number permitted is 31. The 3 most significant bits in this 8-bit field shall be set to 0. The field is split into two nibbles and each is Hamming 8/4 encoded prior to transmission. 4.2.3.5 Application Type The code for an application as allocated in TR 101 231 [4]. The Application ID in the Structure Headers for the data blocks belonging to this application is assigned the current loop index value, i, as defined in table 1. The field is split into two nibbles and each is Hamming 8/4 encoded prior to transmission. 4.3 Coding of the Teletext page A data stream, as defined in clause 4.2, is transmitted by mapping it to successive versions of a Teletext page. The page consists of a page header, packets 1 up to 25 carrying the data and an optional packet 28. 4.3.1 Page header The transmission of a page commences with a page header (packet 0), figure 4. The byte coding is fully defined in EN 300 706 [1]. The bytes are numbered 1 to 45. The page header is essential but it shall not contain any application data. Other than the page address and control bytes, it may be identical to all others in the same magazine.
Byte 6
13 Bytes 1 - 5
6 - 13
14 - 45 Control Bits C11 - C14 Page Number Units Page Number Tens Subcode S1 Subcode S2 + C4 Subcode S4 + C5, C6 Subcode S3 Control Bits C7 - C10 Page Address & Control Bits Prefix 32 Data Bytes (odd parity coded) Packet 0 Magazine Number Bytes 1 - 2
5 Packet
Number (0) Clock Run-In Framing Code Packet Address
Figure 4: Page Header SIST EN 300 708 V1.2.1:2003

ETSI ETSI EN 300 708 V1.2.1 (2003-04) 13 4.3.1.1 Page number Since a Page Format - Clear encoded page does not contain data intended for direct display by standard Teletext decoders, the use of a page number which includes at least one hexadecimal digit for Page Number Tens or Page Number Units is recommended. The reserved page number value of FF is not permitted for any data service.
Individual applications may suggest the use of a particular page number. However, it is recommended that the page number in use is always defined in the Magazine Inventory Page (MIP) for that magazine, see EN 300 706 [1]. 4.3.1.2 Subcode The subcode fields of the page header convey data stream identity, continuity and page length information, figure 5. NOTE: The coding of the subcode fields given here is different from that defined in EN 300 706 [1] for both normal Teletext pages and enhancement data pages.
S2 (3 bits) Last Transmitted S4 (2 bits) S1 (4 bits) Continuity S3 (4 bits) Data Stream
Figure 5: Function of the Teletext page subcode bytes S3 - Data Stream Identifier: This 4-bit field allows up to 15 different data streams to share the same 3-digit page number, table 2. The value 0xF is reserved for future use. Thus the location of a particular data stream within the total Teletext transmission is defined uniquely by a 3-digit page number and a Data Stream Identifier value. If the LSB is set to 0, the 20 ms transmission rule (see EN 300 706 [1]) must be applied before any further packets belonging to the page can be transmitted. If the LSB is set to 1, the next packet for the page may be transmitted on the next TV line.
Table 2: Values of S3 - Data Stream Identifier Hex value of S3 Interpretation 0 20 ms rule applies - data stream 1 1 No 20 ms rule - data stream 2 2 20 ms rule applies - data stream 3 3 No 20 ms rule - data stream 4 4, 6, 8, A, C and E 20 ms rule applies - data stream 5, 7, 9, 11, 13 and 15 respectively 5,7,9,B and D No 20 ms rule - data stream 6, 8, 10, 12 and 14 respectively F Reserved for future use, no 20 ms rule applies
S1 - Continuity Index (CI): This 4-bit field increments modulo 16 for each page which contains different application data. The value is data stream specific and must be sequential in the range 0 to F, with no missing values. If a page is transmitted in fragments (see clause 4.4), the same CI value shall be used for each page header required. S2 and S4 - Last Transmitted Packet: The S2 and S4 fields are combined to make a 5-bit field (S2 providing the thr
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...