Annex 3 to AVC-673R

Source:	Stuart Dunstan
Title:	Summary of discussions on H.222.0 and H.222.1
Purpose:	Report

1)	As proposed in AVC-636 and AVC-658, parameters relating to primitives at the ATM Adaptation Layer Service Access Point (AAL-SAP) were defined.  Table 1 shows the required primitives and parameters for use with H.222.1.

side	primitive	direction	parameters	
send	AAL_request	user to AAL	DATA, PRIORITY	
	AAL_response	AAL to user	STATUS	
receive	AAL_indication	user to AAL	DATA, STATUS	
	AAL_command	AAL to user	STATUS	
Table 1.  Proposed definition of primitives for use with H.222.1 at AAL-SAP

In the case of the Transport Stream, the PRIORITY parameter will not be tightly coupled to the transport_priority bit in the Transport Stream packet header.  In the case of an integrated H.32X terminal, the entity which might set the transport_priority bit has access to the AAL-SAP, and can set the PRIORITY parameter as required.  In the case of a Transport Stream being accessed remotely, it remains the users option as to how priority should be implemented, and as to whether it should or should not be used.  Such choices depend on cost, and network Quality Of Service offerings.  Priority may as well be implemented using multiple virtual channels.

The primitive names and the exact meaning of the parameters in Table 1 require further study.  There may be a STRUCTURE parameter associated with the AAL_request and AAL_indication primitives.  

It is not clear whether the primitives definitions should reside in Rec. I.363 or Draft Rec. H.222.1.  For the moment they will be placed in Draft Rec. H.222.1, to indicate what is expected from the AAL.

2)	The ATM performance assumptions, in AVC-635, were reviewed.  The quoted figures represent the feeling of a group of experts.  The meeting expressed some concern at the rather high end-to-end delay figure, and its consequences.  The figure was not changed.  The document is to be forwarded to the ATM Forum, and to ITU-T SG13 for information.

3)	AVC-657 considered the Mean Error Free Time, and concluded that bit error correction was required, even for bit error rates of 10-9.  As a result the performance of AAL type 5 for audio and video is sensible only for low error environments.  Of the error correction proposals shown in AVC-657, generic proposals are preferable.  The meeting did not recommend a particular solution.

[Note:  While the MEFT is a reasonable measure of channel performance, the effect of bit error may not be significant due to concealment].

4)	AVC-656 discussed the need for a H.222.1 control channel for terminal-to-terminal and terminal-to-MCU signalling.  Discussion based on the proposal in AVC-656 led to the following solution:

•	request ISO/IEC MPEG to allocate a specific stream_id value for ITU-T purposes.  An ITU-T stream_type value already exists.

•	in H.222.1 define descriptors, for use in the Transport Stream PSI or the Program Stream PSM tables, which identify the nature of the ITU-T stream.  Only descriptor values greater than or equal to 64 shall be used.  These ITU-T defined descriptors apply only to individual streams and not to whole programs.

AVC-665 considered closed captions.  It is believed that closed captions can be handled within the above method of C&I signalling.

The method of mode switching presented in AVC-656 was reviewed.  Further thought is required as to how mode switching is best achieved in the Program Stream and the Transport Stream.

5)	It is believed that H.222.1 should support the following modes of communication:

acknowledged- this method is only appropriate in bi-directional point to point communications.  It may offer the most robust performance.

unacknowledged - this method is the only alternative in unidirectional communications.  Information is transmitted repeatedly.  The required bandwidth to do so may not be great.

In contrast to H.320, H.32X should allow the receive terminal to set a preferred mode of operation.  Higher level error conditions in Rec. H.32X need to be identified.

6)	The means to set the H.222.1 mode should be provided by out of band signalling i.e. by the user data fields in Q.2931.  This includes selection of the Program Stream or Transport Stream.

7)	Liaison with ITU-T SG8 was reviewed.  SG8 deal with the T.120 series of audiographic conferencing recommendations.  They are concerned that multiplexing in H.222.1, and the use of real time AALs, may not be appropriate for their purposes.  Their preferred option is for use of a separate VC for T.120 purposes.

8)	AVC-664 illustrated the use of H.222.1, with multiple VCs.  The contribution illustrated the fact that while H.222.0 provides support for hierarchical coding, it says nothing about how to carry hierarchical coded signals in multiple channels.  H.222.1 should define how this is to be done.

9)	A contribution on how to speed up the locking of the phase locked loop, for removal of jittered clock references in H.222.0, was reviewed.  The method was based upon knowledge of the rate of the incoming stream.

10)	The text in the current version of H.222.0 relating to multiple program, variable bit rate Transport Streams, was questioned.  The meeting agreed that a variable bit rate Program Stream, or a single program Transport Stream was not difficult to construct.  However the issue, stated in H.222.0, that a variable bit rate Transport Stream, was "generally not possible", was disputed.  While it may or may not be easy to do, there appears to be nothing that prohibits such a Transport Stream.

11)	The draft text for H.222.1 was reviewed.  It was agreed that ISO protocol layering principles, are a convenient means of specifying the H.222.1 protocol.  Some text changes were incorporated.

12)	The protocol model used to identify network adaptation functions in H.32X was reviewed.  The model is still relevant, though some minor changes were made.

- end -