Annex 6 to AVC-598R

SOURCE:	Stuart Dunstan
TITLE:	Report of meeting to discuss ATM Network Adaptation - H.22X/AAL
DATE:	28 October, 1993.

1.	User data alignment and pipelining
Figure 1 was offered to illustrate the possible combinations of user data alignment and pipelining.

Figure 1.  Illustration of possibilities of user data alignment and pipelining.
The difficulties in relation to the PES_packet_length field needing to be always valid relates to the last case in Figure 1; the PES_packet_length field in the PES packet header is not known before the complete PES packet is available, hence pipelining is not allowed.

It is noted that the current MPEG-2 Systems Working Draft allows this field to be coded as zero, indicating that the PES packet length is unspecified.  No further conditions are attached.  This definition is desirable.  Without it the last case in Figure 1 can not be supported.  It is hoped that this definition will not change.

The usefulness of user data and network adaptation structure alignment, which provides spatial error localisation, is questioned.  Are there experimental results to indicate that it gives superior performance to the case where the data is unaligned?  The conclusion is that if it is not difficult to support then it should be made available, and used if desired.

2.	Packetised Elementary Stream and H.22X
The view was expressed that the Packetised Elementary Stream (PES) is a convenient interworking point between MPEG-2 Systems on different transport mediums.  The Brussels meeting report (AVC-579R) states that it is a convenient mechanism for constructing a Program Stream (PS) from a Transport Stream (TS) and vice versa.  This supports the idea of the PES being a generic (transport medium independent) syntax.  Figure 2 illustrates this.  In Figure 2 the shaded blocks are alternative transport mediums over which the PES might be carried.

Figure 2.  PES as interworking point in MPEG-2 Systems.
3.	Program Stream and H.22x
The program stream is a concatenation of PES packets, with the insertion of a pack header.  If the PES stream cannot be used as proposed in Figure 2, then the Program Stream might be suitable.  The implications of using the Program Stream in the telecommunications application needs to be considered e.g. is the Program Map required in the audio visual terminal?

4.	Transport stream AND H.22X
The Transport Stream might be adopted as part of H.22X for reasons of compatibility.  However the following reservations about this were raised:
•	the Transport Stream requires large PES packets for good packing efficiency (PES packet headers are aligned with Transport Stream packets).  This prohibits alignment of user data (slice) with the PES packet.
•	the Transport Stream does not appear to be "generic" i.e. top box in Figure 2, since it would not be suitable for carrying coded audio and video on ethernet networks, or on ATM using AAL type 5.

5.	Transport stream on ATM
Quite apart from H.22X/AAL for the audio visual terminal, given a Transport Stream how would one carrying it on ATM?  AAL type 1 is one solution.  Other considerations involve alignment of Transport Stream packet with ATM cells.  Discussions within the ATM Forum have suggested that where alignment is required, removal of redundant Transport Stream packet header fields allows greater capacity for AAL functions.

It is suggested that jitter introduced to the Transport Stream by an ATM connection should be removed by an AAL on that connection.  Figure 3 illustrates this.  In Figure 3, on the ATM part of the connection it is proposed that the AAL remove ATM cell jitter, rather than allow the jitter to propagate to the MPEG receive terminal.  This emphasises the issue that an AAL for the transport packet should have methods to remove cell delay jitter.

Figure 3.  Example of Transport Stream on different networks.
6.	Applications
Selection of H.22X and AAL mechanisms may be assisted by recognition of applications.  It may not be necessary to optimise all network adaptation aspects simultaneously.  For example a high quality application may require good source clock synchronisation, but may tolerate some delay.

7.	TOWARDS Joint SG13 meeting
Proposals towards H.22X and AAL type 2 functionality and mechanisms need to be made in preparation for the joint ITU-TS SG13 meeting in March 1994.

- end -