Annex 7 to AVC-553R

	ISO/IEC JTC1/SC29/WG11
	MPEG 93/698
	July 12, 1993
SOURCE	:	ITU-TS SG15 Experts Group on ATM Video Coding
TITLE	:	Report of discussion on ATM/AAL and MPEG-2 Systems
0.	Introduction
The relationship of ATM/AAL and MPEG-2 Systems was addressed in two distinct parts, as follows,
•	system functionality required for the H.32X terminal
•	adaptation of MPEG-2 Systems Transport Stream to ATM.
1.	H.32X terminal
1.1.	Functions required between elementary streams and ATM layer
System functions required to transport a number of elementary streams in the H.32X terminal, to a receive H.32X terminal were identified as follows, 
•	transfer of variable length data units.  Interval between data units may be fixed or variable.
•	multiplexing and synchronisation of elementary streams
•	capability to synchronise source and receiver clocks 
•	error detection capability
In the H.32X terminal these functions are to be distributed between
•	H.22X - nominally MPEG-2 Systems 
•	I.363 - the ATM Adaptation Layer
It is noted that MPEG-2 Systems may have some of the functions of a generic AAL type 2 i.e. source and receiver synchronisation.
1.1.	Error strategy
Some error detection capabilities are required.  Possibilities to deal with errored data units include,
•	discard of whole data unit
•	delivery of errored data units, with indication of error position
The former strategy enables simpler error detection procedures, but causes error multiplication.  The latter allows parts of the data unit already received to be used by the decoder.  Examples of both strategies are discussed in a following section.
1.2.	Alignment between elementary stream structure and packet boundary
Alignment between some structure in the elementary stream may not be mandatory, but H.22X and I.363 functionality should not prohibit it.  For example alignment of the start of the video slice to the start of a cell payload has been shown to provide good spatial error localisation.
1.3.	H.22X and ATM/AAL alternatives
Three options regarding distribution of functionality between H.22X and ATM/AAL were considered.  In all cases the MPEG-2 Systems PES stream was nominated for inclusion in H.22X.
The PES layer is assumed to include the following functions
•	multiplex - 8 bit stream_id field is considered adequate capacity
•	receiver clock synchronisation - ESCR field
•	elementary stream synchronisation - PTS and DTS
The following issues are raised in relation to the PES syntax
•	packet_length field occurs at start of PES packet, and causes segmentation of the PES packet to be delayed until the complete PES packet has been assembled.  
	Proposal - make PES packet length field optional, and don't use in H.32X.  Equivalent error detection can be provided by SAR sublayer.
•	packet_start_code_prefix is redundant.
	Proposal - code it, but ignore it in H.32X.  This framing function can be provided by SAR sublayer.
•	in the cases where multiplexing is done at the PES level, PES packet length must be constrained so as to limit multiplex delay
In the following sections reference to existing AALs indicates possible use of the respective mechanisms in AAL type 2, which is the appropriate AAL for the H.32X terminal. 
1.3.1.	Case A: PES packet + modified AAL type 4 SAR
Figure 1.  Case A:  PES packet + modified AAL type 4 SAR sublayer.
Features
•	can detect cell loss location.  Hence errored PES packets, with error location information coded as side information or as embedded error codes, can be delivered to decoders
•	low delay - multiplexing and error are done on a segment basis
•	has bit error detection
Problems
•	less efficient than other methods
1.3.2.	PES packet + modified Transport Stream packet + AAL type 5 CPCS/SAR

Figure 2.  Case B:  PES packet + modified Transport Stream packet + AAL type 5 CPCS/SAR
H.32X Transport Stream  packet is modified MPEG-2 Systems Transport Stream syntax.  H.32X Transport Stream packet length should be variable, and able to be selected on a call by call basis.
Scenario:  H.32X terminal communicating with video data base.  PES packet on data base may be long.  H.32X Transport packet needs to be chosen according to error parameters for a particular call i.e.
•	high quality link - map one PES packet to one Transport Stream packet
•	low quality link - map one PES packet to a number of smaller Transport Stream packets
Features
•	efficient
Problems
•	cannot determine location of error in case of cell loss.  Cell loss causes whole Transport Stream packet to be discarded
1.3.3.	PES packet plus + AAL type 5 CPCS/SAR
Features
•	efficient
Problems
•	cell loss causes whole PES packet to be discarded.  
•	PES packet size is dependent upon multiplexing delay constraint. 
1.3.3.	Discussion
Of all these cases case A provides the shortest delay as well as the most robust performance.  The other cases are more efficient but cause the whole data unit to be discarded.
AAL type 1 mechanisms were also considered but no clear solution could be found.
1.4.	H.32X and time base
Only one time base is required in the H.32X terminal.  Hence the H.32X terminal corresponds to one program.
2.	Transport stream and B-ISDN
Given that it is required to deliver a Transport Stream across a number of systems, one part of which may be ATM/B-ISDN, what is the best way to adapt Transport Stream packets to the ATM/B-ISDN part of the link?
For the B-ISDN connection
•	some error detection capability is required
•	it is believed that SAR/CS mechanisms common to other AALs should be used if possible. 
Consideration is given to the use of AAL type 1 and AAL type 5 mechanisms.
A suitable error correcting code for the length of Transport Packet under consideration is a shortened RS(255,251) code.  This is able to correct 2 bytes.  This code, and CRC32, is referred to in the following figures.
Figure 3 shows the Transport Stream packet and AAL type 1.  Sequence numbers are available in SAR-PDU headers.  In the case of cell loss the unerrored part of the Transport Stream may be forwarded to the decoder when the shortened RS(255,251) is used.  The Transport Stream packet should have a length of 184 bytes.  A length of 232 bytes may also be suitable.
Figure 3.  Transport Stream packet and AAL type 1.
Figure 4 shows the Transport Stream packet and AAL type 5.  The Transport Stream packet length is n x 48 - 8, which is 184 or 232 for n=3 and 4 respectively.  In the case of cell loss the whole Transport Stream packet is discarded.

Figure 4.  Transport Stream packet and AAL type 5
Figure 5 shows the Transport Stream packet and use of an AAL type 5 structure, but which uses only error detection/correction.
Figure xx.  Transport Stream packet and new AAL.
- end -