Annex 3 to AVC-632R

	ISO/IEC JTC1/SC29/WG11
	MPEG 94/134
	21 March 1994
SOURCE	:	ITU-T Study Group 15 Experts Group for Video Coding and Systems in ATM and 
		Other Network Environments
TITLE	:	Report on ATM Network Adaptation in the H.32X terminal
PURPOSE	:	Information
1.	Introduction
The H.32X ATM network adaptation protocol model [1] has been further developed, and is shown in Figure 1.  The model is a reference which identifies service boundaries and likely location of functions.  It does not address a number of issues that a real terminal would have to deal with, nor does it constrain terminal implementation.
In Figure 1 a number of ATM Adaptation Layers (AAL) are shown.  This indicates possible alternatives.  A terminal is not meant to implement all choices.  It is supposed that H.22X will be required to work with AAL type 1.  For VBR (and CBR) operation AAL type 2 and 5 are proposed.  It is anticipated that the two will be distinguished by their actions in the case of errors.  Data with errors in unknown locations should not be passed to the video decoder.  In this case AAL type 5 can only discard an errored service data unit.  It is anticipated that AAL type 2 may be able to pass the unerrored part of an errored service data unit to the video decoder.
Concerning AAL type 5, it is assumed that for audio and video services, a Video and Audio Service Specific Convergence Sublayer (VASSCS) is required to supplement the service provided by the AAL type 5 Common Part Convergence Sublayer.  This VASSCS might also be common to AAL type 2.
2.	Service boundaries
It will be convenient to define a Service Access Point (SAP) at the H.22X/AAL boundary.  However it is not clear at the moment that this will be easy to do at the elementary stream/H.22X boundary due to the interaction between these two parts.
While AAL type 1 provides a bit or byte transport service, an AAL type 2, and a possible AAL type 5, would notionally provide a packet transport service.
3.	Reference points
In Figure 1, reference points at which each of the Program Stream and the Transport Stream must be logically valid are shown.  At these points the Program Stream and Transport Stream are abstractions: there physical form is not specified.
4.	Multiplexing
No multiplexing is required in the AAL as it duplicates one of the main functions of H.22X.  Multiplexing at the ATM layer is also available.
5.	Timing related issues
Timing recovery at the receiver is concerned with two aspects: one is recovery of the send terminal frequency, while the second deals with recovery of the time of day information.  These two aspects may sometimes be achieved simultaneously.
It is not clear at the moment how clock recovery is performed in the case of delay jittered VBR signals.  An understanding between the send and receive terminal of something being constant may be required.  One proposal is to use a separate CBR VC carrying coded data, or possibly only timing information, for synchronisation of the receiver clock.  The audio channel might be suitable for this purpose.
In the case of a network clock common to both the send and receive terminal, the SRTS can provide synchronisation between terminal clocks.  The SRTS method is insensitive to delay jitter, and the issue of CBR or VBR is not important.
With respect to VBR, MPEG-2 Systems considers the signal to be stepwise constant: between two clock references the stream rate is considered to be constant.  The frequency of clock reference insertion determines the degree to which the variable rate can be preserved.  It is not possible to reconstruct the VBR signal beyond this stepwise constant model.
Study is required as to the compatibility of this step wise constant model with UPC mechanisms.
It is not clear as to whether explicit mechanisms to deal with delay jitter removal should be placed in new AALs, or whether jitter removal is performed within H.22X.
6.	Rate control buffer
Rate control principally effects the video coder.  While it is not certain that H.32X need say anything about the location of the rate control buffer, it seems clear that rate control is logically performed on the aggregate traffic within a VC.  This does not restrict the location of the rate control buffer, provided that the terminal uses additional rules to satisfy the traffic contract.
7.	Error detection/correction
The general principle is that some minimum form of error detection is required.  While the video decoder can detect some invalid codes, no guarantees can be made about what will happen in the case of errors.  Received data in error should be discarded, or where the position of the error can be determined, passed to the decoder with error position information. 
The view was expressed that error detection/correction is best performed at the Physical Layer, where mechanisms can be tailored to the actual medium.  Mechanisms might also be applied within the user application, where there is knowledge about what is required.  The AAL might be the last place to apply such techniques.  Presumably however AAL mechanisms may be selected for a particular call or application.
Known block forward error correction methods may be inappropriate for variable bit rate operation, for two reasons.  Firstly such a structure would give variable delay, although this may be tolerable.  Secondly it may be that cell loss in a variable bit rate ATM connection occurs in bursts, which makes interleaving for cell loss compensation difficult.  Burst lengths my depend upon terminal rate control mechanisms which are determined, perhaps partially, by the network UPC procedures.
Reference
[1]	ITU-T Study Group 15 Exerts Group for Video Coding and Systems in ATM and Other Network Environments, Annex 5 to AVC-598R, Daejeon/Seoul meeting report (MPEG93/968).

Figure 1.  Proposed H.32X network adaptation protocol reference model.
- end -