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/SCTE/ANSI SCTE 019 Methods for Isochronous Data Services Transport (2006).pdf
Like all conversions the text below should be fully readable as UTF-8 unicode text.
---------------------------------------------------------------

    ENGINEERING COMMITTEE
   Interface Practices Subcommittee




AMERICAN NATIONAL STANDARD

       ANSI/SCTE 19 2006


 METHODS FOR ISOCHRONOUS
 DATA SERVICES TRANSPORT
                                       NOTICE


The Society of Cable Telecommunications Engineers (SCTE) Standards are intended to serve the
public interest by providing specifications, test methods and procedures that promote uniformity
of product, interchangeability and ultimately the long term reliability of broadband
communications facilities. These documents shall not in any way preclude any member or
nonmember of SCTE from manufacturing or selling products not conforming to such documents,
nor shall the existence of such standards preclude their voluntary use by those other than SCTE
members, whether used domestically or internationally.

SCTE assumes no obligations or liability whatsoever to any party who may adopt the Standards.
Such adopting party assumes all risks associated with adoption of these Standards or
Recommended Practices, and accepts full responsibility for any damage and/or claims arising
from the adoption of such Standards or Recommended Practices.

Attention is called to the possibility that implementation of this standard may require use of
subject matter covered by patent rights. By publication of this standard, no position is taken with
respect to the existence or validity of any patent rights in connection therewith. SCTE shall not
be responsible for identifying patents for which a license may be required or for conducting
inquires into the legal validity or scope of those patents that are brought to its attention.



Patent holders who believe that they hold patents which are essential to the implementation of
this standard have been requested to provide information about those patents and any related
licensing terms and conditions. Any such declarations made before or after publication of this
document are available on the SCTE web site at http://www.scte.org.



                                       All Rights Reserved

                     © Society of Cable Telecommunications Engineers, Inc.

                                         140 Philips Road

                                        Exton, PA 19341




                                                                                                      i
                                                                  Contents


1. INTRODUCTION .......................................................................................................... 1
     1.1 Purpose ..................................................................................................................................1

2. APPLICABLE DOCUMENTS ......................................................................................... 2

3. ACRONYMS AND ABBREVIATIONS ........................................................................... 2

4. ISOCHRONOUS DATA SERVICE SPECIFICATION ...................................................... 3
     4.1 Isochronous Data Rate Specification ..................................................................................3
     4.2 Syntax Conventions and Definitions...................................................................................3
       4.2.1 Method of Describing Bitstream Syntax ..........................................................................3
       4.2.2 Abbreviations & Symbols ................................................................................................4
     4.3 Isochronous Data Bitstream Syntax ...................................................................................5
       4.3.1 Isochronous Data Sequence..............................................................................................5
       4.3.2 Isochronous Data Header .................................................................................................6
     4.4 Isochronous Data Bitstream Semantics ..............................................................................6
       4.4.1 Reserved Fields ................................................................................................................6
       4.4.2 Isochronous Data Sequence..............................................................................................6
       4.4.3 Isochronous Data Header .................................................................................................7

5. DECODER MODEL ...................................................................................................... 8
     5.1 Low Bit Rate Model..............................................................................................................8
     5.2 High Bit Rate Model.............................................................................................................9
     5.3 Smoothing Buffer Descriptor ..............................................................................................9




ii
1. Introduction



1.1 Purpose
This proposal represents transmission format for the carriage of isochronous data services
compatible with digital multiplex bitstreams constructed in accordance with ISO/IEC 13818-1
(MPEG-2 Systems). Bit rates for the data services extend from 19.2 kbps to 9.0 Mbps.




                                                                                              1
   2. Applicable Documents


The following documents are applicable to this standard:

   •    ITU-T Rec. H. 222.0 | ISO/IEC 13818-1:1994, Information TechnologyCoding of moving
        pictures and associated audioPart 1: Systems.

   •    ATSC Standard A/53(1995), ATSC Digital Television Standard.




   3. Acronyms and Abbreviations


   The following acronyms and abbreviations are used in this standard.
   bps        bits per Second
   bslbf      bit sequence, leftmost bit first
   CRC        Cyclic Redundancy Check
   DDS        Direct Digital Synthesis
   Hz         Hertz
   ISO        International Standards Organization
   k          kilo
   M          Mega
   MPEG       Moving Picture Experts Group
   PCR        Program Clock Reference
   PES        Packetized Elementary Stream
   PID        Packet Identifier
   ppm        parts per million
   PTS        Presentation Time Stamp
   rpchof     remainder polynomial coefficients, highest order first
   SI         System Information
   uimsbf     unsigned integer, most significant bit first
   µ          micro


   2
4. Isochronous Data Service Specification



4.1 Isochronous Data Rate Specification
Isochronous data services support rates ranging from 19.2 kbps to 9.0 Mbps. Since the syntax is
biased towards a Direct Digital Synthesis (DDS) implementation, jitter is better than T1
specifications at rates below 2 Mbps.

4.2 Syntax Conventions and Definitions

4.2.1 Method of Describing Bitstream Syntax

The method of describing isochronous data bitstream syntax is the same as that used in the
IEC/ISO 13818-1. The bitstream retrieved by the decoder is specified by the syntax definitions
given in Section 0 of this standard.
As exemplified in Table 0.1, each data item in the bitstream appears in bold type.




                                                                                                  3
Table 0.1. Bitstream Data Elements and Conditions
    while ( condition ) {                 If the condition is true, then the group of data elements
        data_element                      occurs next in the data stream. This repeats until the
        ...                               condition is not true.
    }
    do {
        data_element                      The data element always occurs at least once.
        ...
    } while ( condition )                 The data element is repeated until the condition is not
                                          true.
    if ( condition) {                     If the condition is true, then the first group of data
        data_element                      elements occurs next in the data stream.
        ...
    } else {                              If the condition is not true, then the second group of data
        data_element                      elements occurs next in the data stream.
        ...
    }
    for ( i = 0; i < n; i++) {            The group of data elements occurs n times. Conditional
        data_element                      constructs within the group of data elements may depend
        ...                               on the value of the loop control variable i, which is set to
    }                                     zero for the first occurrence, incremented to one for the
                                          second occurrence, and so forth.
    /* comment ... */                     Explanatory comment that may be deleted entirely
                                          without in any way altering the syntax.


Each data item is described by its name, its length in bits, and a mnemonic for its type and order
of transmission. The action caused by a decoded data element in a bitstream depends on the value
of that data element and on data elements previously decoded. The constructs in normal type in
the table are used to express the conditions when data elements are present.

4.2.2 Abbreviations & Symbols

The mathematical operators used to describe this specification are similar to those used in the C
programming language. Numbering and counting loops generally begin from zero.

4.2.2.1 Relational Operators

>                Greater than.
>=               Greater than or equal to.
<                Less than.
<=               Less than or equal to.
==               Equal to.



4
!=          Not equal to.

4.2.2.2 Bitwise Operators

&           AND
|           OR

4.2.2.3 Assignment

=           Assignment operator.

4.2.2.4 Mnemonics

The following mnemonics are defined to describe the different data types used in the coded
bitstream:
bslbf
             Bit string, left bit first, where “left” is the order in which bit strings are written in the
             specification. Bit strings are written as a string of 1s and 0s within single quote
             marks, e.g. ‘1000 0001’. Blanks within a bit string are for ease of reading and have
             no significance.
uimsbf
             Unsigned integer, most significant bit first.

4.3 Isochronous Data Bitstream Syntax
Isochronous data is carried as a Packetized Elementary Stream (PES). The PES payload, which
follows the PES header specified by MPEG-2, begins with an isochronous data header, which is
followed by isochronous data access units. The isochronous data header is present even when the
PES header does not include a Presentation Time Stamp (PTS). Each isochronous data access
unit is 16 bits (2 bytes; 1 word). Additionally, isochronous data access units are aligned with the
PES syntax in that the first byte of the isochronous data header immediately follows the last byte
of the PES header. Finally, isochronous data access units are aligned with transport packet
payloads such that the first payload byte of an isochronous data transport packet is the first byte
of an isochronous data access unit (following any adaptation, PES header, and isochronous data
header fields), and the last byte of an isochronous data transport packet is the last byte of an
isochronous data access unit. Stuffing bytes in the adaptation or PES header may be included to
accomplish this. The syntax of isochronous data is as specified in the following paragraphs.

4.3.1 Isochronous Data Sequence

The syntax for isochronous data sequences is specified in Figure 0.1.




                                                                                                         5
        isochronous_data_sequence {                          No. of bits       Mnemonic
                isochronous_data_header( ) {
                for ( i=0 ; i<N ; i++) {
                  isochronous_data_access_unit               16                bslbf
            }
        }
Figure 0.1. Isochronous Data Sequence Syntax

4.3.2 Isochronous Data Header

To constrain each isochronous data sequence to an even number of bytes, the last reserved field
in the isochronous data header, if present, is required to be an even number of bytes. The syntax
for isochronous data headers is specified in Figure 0.2.


            isochronous_data_header {                       No. of bits      Mnemonic
                       pts_ext8                             8                bslbf
                       data_rate_flag                       1                bslbf
                       reserved                             3                bslbf
                       isochronous_data_header_length       4                uimsbf (H)
                       if (data_rate_flag) {
                           reserved                         4                bslbf
                           increment                        28               uimsbf
                        reserved                            16*(H-2)         bslbf
                   } else {
                           reserved                         16*H             bslbf
                   }
            }
Figure 0.2. Isochronous Data Header Syntax

4.4 Isochronous Data Bitstream Semantics

4.4.1 Reserved Fields

reserved—Fields    in this standard marked “reserved” are reserved for future use. Decoders shall
    disregard reserved fields for which no definition exists that is known to the unit. Fields
    marked “reserved” shall be set to a value of zero until such time as they are defined and
    supported.

4.4.2 Isochronous Data Sequence

isochronous_data_access_unit—A        16 bit access unit of isochronous data where the first (left) bit
    is presented (output) before the second bit, etc.


6
4.4.3 Isochronous Data Header

pts_ext8—An   8-bit field extending the PTS conveyed in the PES header of this PES as defined in
  ISO/IEC 13818-1. This field is the 8 most significant bits of the 9 bit Program Clock
  Reference (PCR) extension defined in ISO/IEC 13818-1 that extends the time resolution of
  isochronous data PTSs from the MPEG-2 standard resolution of 11.1 µseconds (90 kHz) to 74
  nanoseconds (13.5 MHz) for unambiguous determination of the correct access unit
  presentation time referenced by an isochronous data PTS. This unambiguous determination of
  presentation time supports each recovery without “bit slips”.

data_rate_flag—A  one bit flag which, when set to “1”, indicates that an increment field is present
  in the isochronous data header.

isochronous_data_header_length—A      4 bit field indicating the number of words (16 bits) of
  isochronous data header which follow this field including the reserved words, (units of 16 bits
  forces the isochronous data header to be an even number of bytes which, coupled with
  isochronous data access units, adaptation fields, and PES headers also being an even number
  of bytes, allows isochronous data transport packets to be generated without any padding bytes
  and thus higher efficiency)

increment—A   28 bit unsigned even integer which indicates the isochronous data clock increment
  value and takes on values that describe the ratio of the isochronous data rate to a 27 MHz
  reference. Specifically, increment is:

   increment   = isochronous data rate *536,868,000/system_clock_frequency

where

   system_clock_frequency is   specified in ISO/IEC 13818-1 as 27 MHz ± 30 ppm.

4.5 Stream Type Assignment
The stream type code for isochronous data conforming to this specification shall be 0xC2.




                                                                                                  7
5. Decoder Model


The following decoder model does not specify a required architecture for the isochronous data
decoder. It is used to ensure that data streams are constructed with similar minimum buffer
parameters in order to ensure interoperability between devices. The model is similar to the one
used in the construction of MPEG 2 streams detailed in ITU-T Rec. H. 222.0 | ISO/IEC 13818-1.

The model is divided into two parts to allow less costly implementation at low bit rates. Each of
the models can be described with the following diagram. Encoders should only assume the High
Bit Rate Model if the data service exceeds 64 K bits per second.




                        TBn                                             Bn
 n                                          Rxn                                             Rn


Figure 5-1 - Decoder Buffer Model

5.1 Low Bit Rate Model
This model is used where the data service is less than or equal to 64 K bits S-1.

Table 0.1. Low Bit Rate Model
    Parameter                       Name                         Value

n               nth stream from a transport multiplex

TBlow           Transport Buffer size                   512 bytes

Rxlow           Transport Buffer Leak Rate              10 M bits S-1

Blow            Smoothing Buffer                        1562 bytes

Rlow            Removal Rate                            as specified in service




8
5.2 High Bit Rate Model
This model is used where the data service is greater than 64 K bits S-1.

Table 0.2. Low Bit Rate Model
Parameter                       Name                            Value

n             nth stream from a transport multiplex

TBhigh        Transport Buffer size                    512 bytes

Rxhigh        Transport Buffer Leak Rate               10 M bits S-1

Bhigh         Smoothing Buffer                         4500 bytes
Rhigh         Removal Rate                             as specified in service



5.3 Smoothing Buffer Descriptor
A smoothing buffer descriptor in the Program Map Table can be specified which allows the
modification of the Rx and B parameters for future enhanced services or non-standard variations
in the buffer model. Data Services which use the standard buffer models above need not include
the smoothing buffer descriptor and may use the default values. However for future compatibility
the use of the descriptor is recommended.




                                                                                               9