Audio/Visual over ATM

A number of standards have been developed to assist in the transfer of Audio and video signals over ATM.

MPEG-2

H.222 http://www.itu.int/itudoc/itu-t/rec/h/h222_30166.html
H.262 http://www.itu.int/itudoc/itu-t/rec/h/h222_30166.html

MPEG-2 is a generic method for compressed representation of video and audio sequences using a common coding syntax defined in the document ISO/IEC 13818 by the International Organization for Standardization. The MPEG-2 Video Standard specifies the coded bit stream for high-quality digital video. As a compatible extension, MPEG-2 Video builds on the completed MPEG-1 Video Standard (ISO/IEC IS 11172-2), by supporting interlaced video formats and a number of other advanced features, including support for applications such as Direct Broadcast Satellite, Cable Television and HDTV.

The ability of ATM to support voice, video and data simultaneously, makes it an excellent candidate for MPEG implementations. In December 1995, the ATM forum issued the Video on Demand (VoD) Specification 1.0, which specifies the implementation of MPEG-2 over ATM. This implementation supports the transport stream MPEG coding, using AAL5 for user data and Signalling 4.0 stack for call control.

MPEG-2 Transport Stream Header Structure

The structure of the MPEG-2 Transport Stream header is shown in the following illustration

Sync byte
Fixed 8-bit field with the value of 0100 0111.

TError (Transport error indicator)
Indicates the presence of at least 1 uncorrectable bit error in the associated transport stream packet.

Pay (Payload unit start indicator)
1-bit flag with normative meaning for transport stream packets.

Trans (Transport priority)
1-bit priority of the packet compared to other packets of the same PID.

PID
13-bit field indicating the type of data stored in the packet payload.

TSC (Transport scrambling control)
Indicates the scrambling mode of the Transport stream packet payload.

AFC (Adaptation field control)
Indicates whether this transport stream packet header is followed by an adaptation field and/or payload.

Continuity counter
4-bit field incremented with each Transport Stream packet of the same PID.

Data byte
8-bit field containing data.

MPEG-2 Program Stream Header Structure

The structure of the MPEG-2 Program Stream header is shown in the following illustration:

Pack start code
The string 0X000001BA identifying the beginning of a pack.

System clock reference base
Indicates the intended time of arrival of the byte. Contains the last bit of the system clock reference base as the input of the program target decoder.

System clock reference extension field
Indicates the number of periods of a 27 MHz clock after a 90 kHz start.

Marker bit
1-bit field with the value 1.

Program mux rate
22 bit integer specifying the rate at which the P-STD receives the program stream during the pack in which it is included. This is measured in units of 50 bytes per second.

Pack stuffing rate
Number of stuff bytes following this field.

Stuffing byte
Fixed value that can be inserted by the encoder to meet the requirements of the channel (for example). It is discarded by the decoder.

Interested in more details about testing this protocol?

MPEG-4

http://www.iso.org/ ISO/IEC 14496

ISO/IEC 14496 defines MPEG-4. It specifies a system for the communication of interactive audio-visual scenes. This specification includes the following elements:

1. The coded representation of natural or synthetic, two-dimensional (2D) or three-dimensional (3D) objects that can be manifested audibly and/or visually (audio-visual objects.).
2. The coded representation of the spatio-temporal positioning of audio-visual objects as well as their behavior in response to interaction.
3. The coded representation of information related to the management of data streams.
4. A generic interface to the data stream delivery layer functionality.
5. An application engine for programmatic control of the player: format, delivery of downloadable Java byte code as well as its execution lifecycle and behavior through.
6. A file format to contain the media information of an ISO/IEC 14496 presentation in a flexible, extensible format to facilitate interchange, management, editing, and presentation of the media APIS.

The overal operation of a system communicating audio-visual scenes can be paraphrased as follows:

At the sending terminal, the audio-visual scene information is compressed, supplemented with synchronization information and passed to a delivery layer that multiplexes it into one or more coded binary streams that are transmitted or stored. At the receiving terminal, these streams are demultiplexed and decompressed. The audiovisual objects are composed according to the scene description and synchronization information and presented to the end user. The end user may have the option to interact with this presentation. Interaction information can be processed locally or transmitted back to the sending terminal. ISO/IEC 14496 defines the syntax and semantics of the bitstreams that convey such scene information, as well as the details of their decoding processes.

The MPEG-4 header appears as follows:

The following Class tags for commands exist:

Class Tags for descriptors:
The following are class tags for descriptors

Interested in more details about testing this protocol?

DOCSIS

http://www.scte.org/standards/index.cfm?pID=102

Cable operators are interested in deploying high-speed data communications systems on cable television systems. Cable Television Laboratories Inc., and its member companies, have prepared a series of interface specifications known Data over Cable System (DOCSIS) that permit the early definition, design, development and deployment of data-over-cable systems on a uniform, consistent, open, non-proprietary, multi-vendor interoperable basis.

The intended service will allow transparent bi-directional transfer of Internet Protocol (IP) traffic, between the cable system headend and customer locations, over an all-coaxial or hybrid fiber/coax (HFC) cable network.

The transmission path over the cable system is realized at the headend by a Cable Modem Termination System (CMTS), and at each customer location by a Cable Modem (CM). At the headend (or hub), the interface to the dataover- cable system is called the Cable Modem Termination System - Network-Side Interface (CMTS-NSI). At the customer locations, the interface is called the cable-modem-to-customer-premises equipment interface (CMCI). The intent is for the operators to transparently transfer IP traffic between these interfaces, including but not limited to datagrams, DHCP, ICMP, and IP Group addressing (broadcast and multicast).

MAC_PARM
Parameter field whose use is dependant on the FC field.

LEN
The length of the MAC frame.

EHDR
Extended MAC Header.

HCS
MAC Header Check Sequence.

FC Field
The contents of the FC field are as follows:

FC_Type
MAC Frame Control Type field.
It can contain the following values:
00 Packet PDU MAC Header
01 ATMPDU MAC Header
10 Reserved PDU MAC Header
11 MAC Specific Header

FC_PARM
Parameter bits, their use is dependant on the FC_Type.

EHDR_ON
When the value is one, the EHDR field is present.

Interested in more details about testing this protocol?

DVB

ETS 800 300

Certain implementations suitable for Digital Video Broadcasting (DVB) broadcasting systems are supported by CATV infrastructures. Specifically, implementations of the Return Channel for interactive services are supported by CATV. DVB involves a standard link.

The format of the DVB packet is shown in the following illustration:

Mpeg header
4 byte Mpeg-2 transport stream header as defined in ISO 13818-1 with a specific PID designated for MAC messages. The value of this PID is 0 x 1C. The transport scrambling control field of the MPEG header is set to 00.

Upstream marker
24 bit field, 3 byte marker that provides upstream QPSK synchronization information. At least one packet with synchronization information must be sent in every period of 3 msec. The definition of the field is as follows:

• Bit 0: Upstream Marker Enable:
  Possible valuues
  1Slot marker pointer is valid.
  0Slot marker pointer is not valid.
• Bits 1 - 3: MAC Message Framing - Bit 1 relates to the first MAC message slot within the MPEG frame, bit 2 to the second MAC message within the MPEG frame, and bit 3 to the last MAC message within the MPEG frame. Possible values:

0 - A MAC message terminates in this slot.
1 - A MAC message continues from this slot into the next, or the slot is unused. If the slot is unused, the first two bytes of the slot are
0 x 0000.

• Bits 4 - 7: Reserved
• Bits 8 - 23: Upstream Slot Marker Pointer - A 16 bit unsigned integer which indicates the number of downstream ?symbol? clocks between the next Sync byte and the next 3 msec time marker. Bit 23 is considered the most significant bit of this field.

Slot Number4
A 16 bit field which is defined as follows:

• Bit 0: Slot Position Register Enable (msb)
  Possible valuues
  1Slot marker pointer is valid.
  0Slot marker pointer is not valid.
• Bits 1-3: Reserved
• Bit 4: Set to the value ?1.? This bit is equivalent to M12 in the case of OOB downstream.
• Bit 5: Odd Parity - This bit provides odd parity for upstream slot position register. It is equivalent to M11 in the case of OOB downstream.
• Bits 6 - 15: Upstream Slot Position Register - 10 bit counter which counts from 0 to n with bit 6 the msb. These bits are equivalent to M1 - M10 in the case of OOB downstream.

MAC flag control
24 bit field (b0 (msb), b1, b2 . . . b23) that provides control information used in conjunction with the ?MAC Flags? and ?Extension Flags? fields. The definition of the MAC Flag Control field is as follows:

• b0 - b2 - Channel 0 control field.
• b3 - b5 - Channel 1 control field.
• b6 - b8 - Channel 2 control field.
• b9 - b11 - Channel 3 control field.
• b12 - b14 - Channel 4 control field.
• b15 - b17 - Channel 5 control field.
• b18 - b20 - Channel 6 control field.
• b21 - b23 - Channel 7 control field.

MAC flags
26 byte field containing 8 slot configuration fields (24 bits each) which contain slot configuration information for the related upstream channels followed by two reserved bytes. The first 3 bytes correspond to MAC Flag Set 1, the second 3 bytes to MAC Flag Set 2, etc.

Ext. flags
A 26 byte field used when one or more 3.088 Mbit/s or 6.176 Mbit/s upstream QPSK links are used. The definition of the Extension Flags field is identical to the definition of the MAC Flags field (above). The Extension Flags field contains the MAC Flags from 9 to 16.

MAC message
The MAC Message field contains a 40 byte message in hexadecimal code.

Reserved field C (Rsrvc.)
Reserved Field C is a 4 byte field reserved for future use.

Interested in more details about testing this protocol?

DSM-CC

The Digital Storage Media Command and Control (DSM-CC) specification is a set of protocols which provides the control functions and operations specific to managing ISO/IEC 11172 (MPEG-1) and ISO/IEC 13818 (MPEG-2) bit streams. The concepts and protocols are, however, considered to apply to more general applications.
(Compliant with ISO standard 13818-6 6/12/95.)

The format of the header is shown in the following illustration:

Protocol discriminator
This field indicates that the message is an MPEG-2 message.

Dsmcc type
MPEG-2 DSMCC type. Possible types are:
UN configuration.
UN primitive.
UU configuration.
UU primitive.

Message ID
The message type.

Transaction ID
A field used for session integrity and error processing.

Download ID
An optional field replacing the transaction ID fields if the message type is a download message.

Reserved
A reserved field, the value of which is always set to zero.

Adaptation length
This field indicates the length of the adaptation part.

Message length
The length of the message including the adaptation part.

 Interested in more details about testing this protocol?

ATM Circuit Emulation

Circuit Emulation was developed to facilitate the transmission of constant bit rate (CBR) traffic over ATM networks. Since ATM is a packet- rather than circuit-oriented transmission technology, it must emulate circuit characteristics in order to provide support for CBR traffic. The goal of Circuit Emulation is to connect between CBR equipment across an ATM network, without the CBR equipment realizing it.

Interested in more details about testing this protocol?