&%PAGE&

-  &%page&  -
Annex 4 to Doc. AVC-256R
Annex 4 to Doc. AVC-256R

Liaison statement to SGXVIII

CCITT SGXVIII
June 1992
Geneva
Questions XVIII/2, 13, 22

Source: CCITT SGXV Experts Group on Video Coding for ATM Networks
Title : Liaison to CCITT SGXVIII from SGXV Video Coding Experts Group

Abstract

This liaison represents a brief report of aspects of the Experts Group work 
at the Stockholm meeting that is considered relevant to SGXVIII.  Comments 
on the issues raised and answers to specific questions are requested.


1. Introduction

The SGXV Experts Group on Video Coding for ATM Networks held its sole 
sessions of the 6th meeting in Stockholm 18-20 March 1992.  The 
comprehensive liaisons from SGXVIII were welcomed and provided important 
input to our continuing work.

The following Sections provide an update of the work of the Experts Group 
that may be of interest to SGXVIII, as well as additional network related 
queries on which we request guidance.

2. Timing Requirements

The need for end-to-end timing recovery has been recognised by the Experts 
Group.  Precise requirements are under consideration.  The availability of a 
network reference clock will be essential to ensure timing recovery 
necessary for high quality video applications.

8 kHz structured data reference will be required for circuit emulation 
support of existing audiovisual systems based on Rec. H.221.

The SRTS timing recovery approach, adopted by SGXVIII at its Melbourne 
meeting, has been investigated.  It appears to be appropriate for timing 
recovery for CBR video services.  Some extension may be necessary for VBR, 
and this is currently a topic for study.  Whether timing recovery is 
achieved using AAL functionality or as part of the video codec function is 
also under consideration.

3. Access Networks

The Experts Group recognises that access to the B-ISDN may, at least for a 
considerable interim period, be via other networks such as LANs and MANs.  
Video services must also be supported over these access networks.  The 
implications of the differing network characteristics, in terms of resource 
allocation, timing requirements, protocol conversions, UPC control, etc., 
require study.  Comments are requested from SGXVIII on this subject.

4. AAL

The Experts Group is studying requirements for support of video services by 
both AAL Type 1 and Type 2.  While we believe that the details of AAL Type 2 
are likely to differ from those of Type 1, we recognise the value of 
maintaining common types of function, and will identify this in future 
recommendations concerning AAL requirements.

Possible AAL functions identified by the Experts Group are:

	-  Multiplexing capabilities;
	-  Sequence number;
	-  Cell payload length indication;
	-  Requests for priority level;
	-  Alignment of packet data to cell boundary.

Work is ongoing to define precise requirements, and other functions may be 
added to this list.  It is possible to avoid the use of a cell payload length 
indicator by using embedded end-of-data code words, and both options are 
under study.

Detailed requirements for sequence number cannot be determined without 
more knowledge of anticipated cell burst lengths.  The differing cell loss 
tolerance of video data from that of other data types suggests that a 3-bit 
sequence number may not be sufficient.

It is also recognised that functions of AAL Type 1 for video signal 
transport require further consideration.  Use of AAL Type 1 or 2 may depend 
on decisions regarding video coding in VBR or CBR for H.26X.

5. Multiplexing

The Experts Group is considering audiovisual and other multimedia services 
support on the B-ISDN, and therefore the possible multimedia multiplexing 
alternatives.  VC-based multiplexing has been identified as a long-term 
target, but early service implementation may have to use other means of 
multiplexing, since 

    -	interworking with audiovisual equipment on other networks (64
kbit/s ISDN) will require a user multiplex mode of operation;

    -	we understand that the network will not be able to support
VC-based multimedia multiplexing at the early stages of
standardisation.

For your information and comment, we have included Table 1, which 
summarises our current perceptions regarding multiplexing approaches.

We have also developed a reference terminal configuration (Figure 1) which 
shows where the alternative multiplexing operations are performed, and we 
hope this will be useful to identify the division of responsibilities.  The 
Experts Group has some concern about the measurement of Traffic 
Descriptors by the user at the AAL-SAP and by the network at the T 
reference point, and of the effect on CDV from multiplexing and the NT2.

In supporting multiple media and different streams representing the one 
medium (e.g. different layers of a layered video signal representation), the 
Experts Group recognises the value of matching the channel QoS to the 
characteristics of the signal being carried.

Though there appears to be some ambiguity, our understanding is that all 
VCs in a given VP will have the same QoS, though two different CLRs will be 
available according to the selected value of the CLP bit.  It would 
therefore seem that there is no advantage to support of the different bit 
streams in different VCs of the one VP.  Furthermore, for efficient delivery 
of layered video signals in configurations that provide for interworking 
between terminals of different capabilities, the different signal streams may 
need to be routed over different parts of the network.

These considerations imply that optimum service support will require the 
establishment of multiple VPs, each carrying a subset of the total number of 
multiplexed signal streams.  Is this scenario attractive, or even possible, 
from the network point of view? Are there plans to develop a signalling 
system to allow a single end-to-end call to be allocated multiple VPs? Or 
are there any other methods suitable for supporting audiovisual/multimedia 
multiplexing?

6. UPC/NPC Algorithm Standardisation

The Experts Group remains concerned about the issue of UPC/NPC algorithm 
standardisation.  The network Parameter Control technique must be mirrored 
in the terminal to ensure that no violation of the network agreement (which 
could lead to discarded cells) occurs.  It is therefore essential that, for 
anything other than peak rate monitoring, the UPC/NPC algorithm must be 
standardised; it cannot be left to individual operators to choose.

The Experts Group seeks comment on this issue from SGXVIII, and wishes to 
express its interest in receiving information on the details of UPC/NPC 
algorithm development as they emerge.  These algorithms have a significant 
impact on video service provision and efficient utilisation of network 
resources from the service point of view.  It would be impractical to 
consider that terminals could adapt to different Parameter Control 
algorithms depending on which network, or combination of networks, is used.

The Experts Group continues to study UPC mechanisms from the video 
services viewpoint.  Current indications are that leaky bucket techniques 
have some advantages in terms of efficient implementation. 

7. Conclusion

An update of some of the activities within the Experts Group that are 
relevant to the activities of SGXVIII has been provided in this liaison.  
Comments on any of this material are welcome, and answers to specific 
queries requested.  The Experts Group continues to benefit from close 
liaison with SGXVIII, and in particular welcomed the presence of Mr. Yamazaki 
(SGXVIII SWP 8-3 chairman), who provided valuable tutorial information and 
other advice at the Stockholm meeting.  Future reciprocal representations 
are seen as beneficial to both groups.


END