ITU Telecommunication Standardization Sector	Document AVC-743R
Study Group 15	January 27, 1995
Experts Group for Video Coding and Systems
in ATM and Other Network Environments

Source:	RAPPORTEUR (Sakae OKUBO)	
Title:	REPORT OF THE EIGHTEENTH EXPERTS GROUP MEETING IN KAMIFUKUOKA (24-27 January 1995)	
Purpose:	Report	

-----------------------

1. General

The eighteenth meeting of the Experts Group was held under chairmanship of Rapporteur (Mr. Sakae Okubo) during 24-27 January 1995 in KDD R&D Laboratories, Kamifukuoka, Japan, at the kind invitation of Ministry of Posts and Telecommunications.  At the start of the meeting, Dr. Yoshiyori Urano, Director of KDD R&D Laboratories, gave a welcoming address on behalf of the hosting organization.

It is noted that the discussion session for H.222.1, H.32X, H.32Y, H.32Z and related matters was co-chaired by Rapporteur and each Editor; Mr. Stuart Dunstan, Mr. Chia-Chang Li, Mr. Hayder Radha and Mr. Geoff Morrison.  It is also noted that the network adaptation related sections of this report were provided by Mr. S. Dunstan.

In addition to the meeting sessions at large, we had two small group discussions regarding requirements to the signalling and network adaptation in the Wednesday evening, and organized ten editing teams to draft Recommendations and correspondence to other groups.

At the end of the sessions, Rapporteur thanked the hosting organization and its staff for providing excellent facilities and services to support the meeting.  The participation of Mr. K. Yamazaki, Rapporteur for Q.6/13, and Mr. S. Kuribayashi, active member of SG11, was highly appreciated to liaise the work of this Experts Group with that of SG13 and SG11.

2. Documentation (TD-2)

For this meeting, 36 AVC-numbered documents and 23 temporary documents have been made available as listed in Annex 1.

3. Review of the previous meetings 

3.1 Experts Group Singapore meeting in November 1994 (AVC-707R, 708R)

Rapporteur drew attention to §13.2 which reported the work plan discussion at the closing session in Singapore, which was suspended due to lack of time.

There were no comments on the two meeting reports.

3.2 Meetings of related organizations

Progress of the meetings related to the activities of this Experts Group was briefly presented as follows:

•	SG13 meeting in November 1994 by Mr. H. Radha
•	SA&A meeting in November 1994 by Mr. T. Kasahara
•	SG15 Rapporteur meeting in November 1994 by Mr. S. Okubo
•	DAVIC meetings in December 1994 and January 1995 by Mr. O. Poncin
•	DAVIC liaison meetings in December 1994 and January 1995 by Mr. S. Okubo and Mr. O. Poncin

3.3 List of open issues (AVC-713)

AVC-713 provided a list of open issues which were identified after the Singapore meeting. Rapporteur requested to use it as a check list of this week achievements.

4. Common text Recommendations

4.1 H.222.0|ISO/IEC 13818-1 Systems (AVC-709; TD-5)

AVC-709 provided the disposition of ITU-T comments on the DIS version of Systems specifications.  It also contained a list of further corrections to the Singapore IS version.  The meeting decided to send the list of corrections to the Editing Group which is finalizing the text.  This was put into action during the meeting and an acknowledgment of receipt was obtained from Mr. S. MacInnis.

We will review the final text referring to AVC-709.   If we find necessity of further corrections, we will make an input to the March MPEG meeting to apply the Defect Report procedure as set out in TD-5.

4.2 Input to SG15 meeting for approval

Rapporteur advised the meeting that delta documents for H.222.0 and H.262 between Singapore IS version and DIS version have been sent to Geneva for the SG15 February meeting, and the final text of H.262 has been completed.

5. Video coding matters and VBR (AVC-732, 733, 734)

AVC-732 and 733 proposed pre-transmission of High Priority data when data partitioning is used and inclusion of frame numbers in the transport stream packets both of which are useful in high packet loss environments.  The meeting requested further review of the members by the next meeting and also further clarification of the proposer regarding necessary actions in related ITU-T Recommendations and/or ISO/IEC Standards.

AVC-734 proposed additional syntax for multiple picture presentation.  The meeting appreciates further clarification of the system configuration where the proposed technique is effective.

6. Network adaptation

6.1 C&I and DSM-CC channels

	6.1.1 C&I signals (AVC-725)

AVC-725 considered different types of C&I signalling for the H.32X terminal; 

•	Video frame synchronous signals
•	H.24X capability exchange signals
•	H.230 like signals
•	DSM-CC signals
•	Mode change control signals

During the discussion on C&I categories, specific signals and channels to convey respective C&I signals, the following clarification and questions were obtained:

•	The MPEG DSM group view is that DSM-CC be carried in PES if MPEG System is available.
•	Server to network communication is also relevant to C&I if we define sending only terminals in H.32X.
•	A question raised on the required bandwidth of the control channel when it is separate from the channel transporting audiovisual signal.
•	A separate control channel is useful for communicating stored information because no recoding of PCRs etc. is necessary.
•	With respect to the video frame asynchronous H.230 like signals, it was explained that H.200 series Recommendations describe a generic set of C&I signals, while H.300 series Recommendations choose a necessary sub-set form the generic lists.

After the discussion, the meeting concluded as follows:

•	The framework for type of C&I signal categories with specific examples has been agreed as in AVC-725, leaving the linkage with possible channels to further discussion.
•	H.222.1 defines channels for each of these signals, the exact method is to be clarified.
•	As agreed to in Singapore the method of transporting the video frame synchronous signals will be described in H.222.1.  However, the actual signals will be described in H.32X.
•	Since the exact relationship between DSM-CC and H.24X is unclear, the development of H.24X will proceed independently of DSM-CC at this stage.

	6.1.2 Channel for H.24X capability signals (AVC-724)

AVC-724 advocated the use of a separate VC for use by H.24X.  The meeting discussed whether H.24X signalling be inside or outside the H.222.1 multiplex and relevance to user-network signalling.  

As to the fist aspect, the following was discussed:

•	In addition to the two solutions considered in AVC-724, the “look ahead procedure” may be the third solution.
•	A question was raised to the necessity of a residential channel for H.24X; it is only necessary at the start of the call.  It was responded that renegotiation may be necessary during the communication.
•	Switching cost should be counted.  Multiple VCs need additional cost, but how much can not be known.
•	Single VC solution is better for hybrid network where multiple VCs may not always be available.
•	Use of user-to-user signalling is a possibility for transporting H.24X signalling; its capacity is up to 4Kbyte.
•	H.24X may be supported by an asymmetrical connection in that selection of PS, TS or no H.222.1 multiplex may be determined independently in each direction.

As to the Q.2931 signalling capabilities, the following was clarified:

•	SG11 will make necessary user-network signalling specifications if user requirements are clarified; delay, data length, bandwidth for the message.
•	The negotiation capabilities of Q.2931 was explained.  A called terminal can only indicate something less than the calling terminal’s capabilities.  An example is the selection of AAL5 PDU size.
•	There was much discussion regarding signalling support for multiple VCs.  Q.2931 release 1 does not support multiple connections, hence multiple VC case could result in different physical paths through the network.  In addition the signalling set up time for the additional VCs may not be tolerable.  
•	In the separate VC solution, the second VC has a chance of blocking.
•	A question was raised regarding the delay of the second VC setup after the request from the terminal; if it is not quick, human users will not accept.  The call set up delay was explained to be largely due to the detection of the end of dials.
•	The time to renegotiate traffic parameters on a VC may be of similar order to the time to establish additional connections.
•	H.24X should tolerate this delay of establishing the second call or change of bandwidth.

A representative from SG11 explained that SG11 is producing draft Q.2931 release 2, which will allow multiple connections within one call.  SG11 requires input on what is a real scenario under which multiple VCs would be used, and what are the requirements of this scenario.  The meeting identified the following requirements:

•	Additional connection should be routed in a way that minimizes VC differential delay.
•	It should be possible to establish additional connections in less time than that required to establish the call.  It is noted that additional connections do not require to gather called party digits.

The meeting decided to send a liaison statement describing the above to SG11 as contained in Annex 5.  The former might be satisfied by routing the call through the same Virtual Paths or simply through the same ATM nodes.

After the discussion, the meeting obtained the following conclusion:

•	Speech should be made available as soon as the called user responds to the incoming call in conversational services, as occurs in H.320.
•	H.32X must support the use of one VC.
•	H.32X should also support the use of multiple VCs, as required by the user or application.

	6.1.3 DSM-CC (AVC-730, 731)

AVC-730 and 731 considered architectures and protocols for DSM-CC.  The meeting appreciated this input to clarify the audiovisual system configuration.  During the discussion, the following was found:

•	Adding something (like H.24X signalling) to pre-stored MPEG multiplex is not a good idea because restamping is involved.
•	We first concentrate on the definition of H.24X capability messages, then we further consider common parts with DSM-CC messages.  It was confirmed that H.24X covers only the capability exchange, including the protocols and procedures to achieve this.  H.24X appears to be something different from DSM-CC.
•	We need to make distinction between capability and other C&I messages; the former is necessary for starting a communication.
•	Clarification is needed for the control protocol configuration when H.32X A2 type includes the capability of A1 where DSM-CC may be involved.

As a conclusion, the meeting agreed to include the three configurations in AVC-730 in the meeting report as reference material.  This is contained in Annex 2 to this report.

6.2 Error free transport for H.24X and T.120 data (AVC-721; AVC-640, 675; TD-19, 20)

AVC-721 provided protocol stack options for the reliable support of H.24X capability exchange.  It was questioned and confirmed that H.24X is applicable to the receive only terminal.  It would appear that H.24X is still applicable here.  It may be that a capability exchange takes place out of band, before the main audio visual VC has been established.  The meeting also confirmed that the protocol stack must work with different underlying networks in each direction.

Though the document advocated X.224 class 0 with SSCF and SSCOP, a question was raised whether X.224 is really necessary in the interest of commonality with different underlayers other than ATM.

It was noted that in the Low Bitrate Coding audiovisual recommendations, V.42 is employed as the support for H.24P and that H.24X and H.24P should be as common as possible since both are operating on packet based systems.  It was also noted that in addition to the options shown in AVC-721, a method of using the H.24X protocol stack with H.222.1 must be decided and that this method might also support the T.120 series data transfer protocol.

LAPM was suggested for error free transport of H.24X signals; it is bit stream oriented with flags and close to V.42, thus also suitable to be on top of AAL1.  SSCOP is packet oriented, thus suitable for being on top of AAL5.

As to the multiple VC use for T.120 data which was communicated between SG8 and SG15 as reported in AVC-640 ad AVC-675, the meeting confirmed that we consider both cases of using a dedicated VC and H.222.1 subchannel for T.120 series data.

After the discussion, the meeting asked Mr. K. Hibi to coordinate a small group to further discuss and conclude on the protocol stack for error free transport of H.24X signalling and to produce a liaison statement to SG8 on this matter and use of multiple VCs in broadband audiovisual communication.  During the review of its draft (TD-19, 20), the following comments were obtained and resolved:

•	A single VC non-ATM case should be added in Figure 1/TD-19, where “non-ATM” means bit oriented network.
•	PSTN stacks, one in H.24P and another we recommend, should be included.
•	Probably SG8 will not accept the stack for separate VC in Figure 1 because they are supportive of SSCOP.  In any case we seek their views.

The outcome is contained in Annex 3 (protocol stack) and Annex 4 (liaison statement to SG8).

6.3 Requirements to the user-network signalling (AVC-737)

AVC-737 proposed that indications of PS or TS selection should be placed in the Q.2931 B_LLI information element and requested a liaison to SG11 which is going to meet next week.  The requirement is that the session should be started up in a reasonable way without re-establishment of some layers of the session.  AVC-726 also addressed indication of terminal type (see §6.6 below).

The following comments were obtained:

•	We need a philosophy to split the terminal identification messages between Q.2931 use-network signalling and H.24X end-end signalling; a whole picture need be drawn covering the both procedures.
•	Q.2931 should cover global identification pointers, H.24X should cover further details.
•	A framework for terminal identification should be given to SG11 together with specific requests, otherwise there will be a confusion in the future when more terminal types are involved.
•	Definition of LLC messages should be in Q.2931, but the procedures to use them should be in H-series terminal specifications.

A small group discussion on Wednesday coordinated by Mr. V. Balabanian resolved some of these issues regarding the use of Q.2931 information elements.  A guiding rule, however, was that only essential elements should be indicated in Q.2931 which were determined to be terminal type and the start up options as shown in Table 1.

Table 1.  Terminal type indication and start up indications in Q.2931

Terminal type	Start up options2	
H.32X A1 & B11	PS
TS	
H.32X A2 & B2	no multiplex3
PS
TS	
H.32Y	-4	
H.320	-4	

Notes:

1)	The H.32X receive only terminal does not use H.24X.  This may not always be true.
2)	If the FEC is used with the PS or TS, then it is assured that it is always used at the transmitter.  It may of course be another option to be indicated.
3)	“no multiplex” implies that only the H.24X protocol stack uses the VC.
4)	H.32Y and H.320 use H.221 by default.

It is important to note that the start up parameters for H.32X A2 & B2 can by asymmetrical; e.g. the send side indicates to the receive side that it will use the TS multiplex, while the receive side indicates to the send terminal that it will use no multiplex.

It is also noted that the choice of AAL type, as currently defined, can not be asymmetrical.  In one VC (which is by definition bi-directional) the AAL must be the same in the forward and backward directions. This concern should be expressed to SG11 and SG13. (A typical scenario might be TS on AAL type 1 in one direction, with H.24X protocol stack and AAL type 5 in the return direction).

Even if the AAL type can not be asymmetrical, there is still the requirement to have different AAL parameters in each direction.  This appears to be currently included in AAL type 3/4 and type 5, but not type 1.  It is noted that the traffic descriptor information element in Q.2931 currently defines a forward and backward peak cell rate.

For each terminal type default modes should be selected for those parts of H.32X not explicitly indicated by Q.2931; e.g. default audio and video coding algorithms.  Default H.222.1 multiplex channels might also be assigned.  This solution allows audio (and video) communications to begin as soon as the VC is established, and even before the first H.24X capability exchange.

These results are  to be contained in the liaison statement to SG11.

After the discussion, the meeting asked Mr. V. Balabanian to continue the small group work to make further discussions and produce a liaison statement to SG11 and its outcome is contained in Annex 5 which the meeting at large approved.  During the review of its draft, it was recognized necessary to seek advice of SG11 and SG13 on the use of asymmetrical traffic descriptors, asymmetrical AALs and asymmetrical AAL1 parameters.  This aspect is also included in Annex 5.  Correspondence to SG13 is to be produced towards the SG13 AAL meeting in May.

6.4 H.222.1 specific functions

	6.4.1 Network performance (AVC-712; TD-6)

AVC-712 provides the SG13 response to the Experts Group ATM network performance parameters assumptions, asking a few questions to the Experts Group.  The following was found:

•	SG13 advice on the worst case bit error rate (<10-7) does not affect our conclusion that error correction is required somewhere in the network adaptation layers.
•	Mr. H. Radha undertakes to update AVC-635 reflecting the SG13 advice.
•	Two views were expressed to the question with which we are more concerned; short term CDV or long term CDV.  In the lack of quantitative data, we will state that both should be as small as possible to reduce the terminal equipment complexity.
•	Mr. K. Yamazaki gave us a tutorial on the mechanism of CDV occurrence; 1) multiplexing in the CPE, 2) statistical multiplexing in the network which is expressed in terms of the number of cells, 3) insertion of OAM and Resource Management cells which is only a problem if the UPC mechanism is applied to the aggregate user plus OAM traffic. He also stressed that the absolute CDV value is highly dependent on the channel rate.

Based on this discussion, Mr. H. Radha undertook to coordinate an editing team to produce a liaison response to SG13 and to ask further questions.  The outcome is contained in Annex 6.

	6.4.2 Bit error correction (AVC-727, 742; TD-22)

AVC-727 presented hardware experiment results on the effect of bit errors on coded HDTV pictures when a modest error concealment technique is applied to the H.261 based algorithm.  The reconstructed HDTV sequences were demonstrated.  The results confirmed previous contributions that some bit error correction is required even in the case of low bit error rates.

AVC-742 proposed H.222.1 specific functions to deal with bit error correction and timing recovery.  It was generally agreed that the 255 byte frame is appropriate.  However, the exact RS code, and the required bit error capability needs further study.  It was emphasized that scramblers used in the physical layers cause multiple (correlated) bit errors in the user data.

It was unclear as to whether such an error correction function should be in H.222.1 or in the AAL.  The opinion was expressed that FEC of any kind should be in the physical layer, and not done end to end.  However, as far as we take the network performance scenario approach, end to end bit error correction is necessary.  This was considered to be a safer approach since various transmission environments are foreseen in the future.

During the discussion, the following views and information were also stated:

•	The FEC solution should be single in the interest of securing interoperability.
•	Information was given on availability of RS chips for blocksize <=255.
•	Indication of lost cell from AAL is useful for the user to conceal the error; AAL1 allows this indication at the start of cell, AAL5 allows error indication at the end of AAL SDU.

The meeting asked Mr. R. terHorst to coordinate a small group to further discuss and conclude  regarding allocation of this function in the network adaptation (H.222.1 or AAL) and alignment of the FEC frame to the ATM cell.

The outcome is contained in Annex 7 (see §6.7.1 below).

	6.4.3 CDV reduction (AVC-742, 735; TD-22)

AVC-742 discussed the CDV reduction with respect to its position in the network adaptation model and a specific scheme. The technical details were further discussed in Mr. R. terHorst’s small group.  The outcome is contained in Annex 7 (see §6.7.1 below).

AVC-735 proposed that receiver estimates of network jitter be fed back to the transmitter, so as to use the VBV in an effective manner.  The meeting agreed to consider inclusion of the proposed C&I signals, awaiting further review of the members by the next meeting.  It was pointed out that this kind of signals are also useful in the H.320 and H.32Z.2 systems where rate or flow control is involved in multipoint or point-to-point communications.

	6.4.4 Mapping between TS packet and AAL (AVC-738, 736)

AVC-738 reported on decisions taken by the ATM Forum with regard to packing of TS packets in the AAL5 CPCS PDU.  When a PCR appears in the TS, then that TS packet is always placed nearest the AAL5 CPCS trailer.  This eliminates jitter due to AAL5 packing.

The meeting agreed to reflect the ATM Forum solution in H.222.1, noting that this particular mapping is for VOD services.  Some comments were obtained during the discussion:

•	MTU size negotiation is for two channels; calling to called and called to calling.
•	If one TS packet to 5 cells mapping and two TS packets to 8 cells mapping are mixed, additional jitter of up to 3 cells occurs in the terminal.
•	“CBR” has a particular meaning in the ATM network with respect to traffic management, it should be carefully used if it addresses video coding in the MPEG sense.
•	Impact of FEC discussed above on this mapping needs further consideration in a small group.

AVC-736 discussed possible merging of some fields which have similar functions in TS and AAL.  However, Mr. J-S. Kim expressed to withdraw the comment considering the interest of commonality among applications to allow bitstream interchange.

6.5 AAL (AVC-711, 741; TD-22)

AVC-711 contained SG13 liaison documents, including one to the Experts Group clarifying the use of the STATUS and PRIORITY parameters.  It was also stressed that while the AAL1 SAR is common, the AAL1 CS should be viewed as a toolkit.  Details of the next meeting were included.

AVC-741 proposed an AAL for real time audiovisual services.  “piecewise constant bit rate” is through the use of VBR network service.  The timestamping proposed here needs to be resolved with what proposed in AVC-742.  This was a subject of Mr. R. terHorst’s small group discussion.  See §6.7 of this report.

Mr. K. Yamazaki gave a status report on the traffic control work; the parameters to be policed in VBR include the peak cell rate (PCR) with parameters (T, t), where T is minimum time interval and t is its tolerance, and the sustainable cell rate (SCR) with parameters (T0, t0).  PCR and SCR both specify a leaky bucket algorithm of depth t/t0, and of token generation rate T/T0.  He also stressed that implementation of VBR can not be obtained unless traffic control is clarified, and that definition of AAL2 is under joint responsibility of SG13 and SG15.

It should be noted that the real time delivery schedule at the transmitter of a VBR bitstream can be done independent of timestamping, which allows regeneration of a piecewise constant rate signal implied by at the receiver.  A piecewise constant rate is the only thing that the timestamping can regenerate in the presence of jitter.

6.6 Network aspects (AVC-726; AVC-712, 723, 727, 737)

AVC-726 discussed identification of H.32X, H.32Y and H.320 terminals at the start of the communication.  It highlighted indication of terminal type and interworking problems, providing alternatives of indication via Q.2931 and redialing.

The meeting recognized that support of Q.2931 user-network signalling is required for identification of H.32X/Y/0.  Possible difficulty for this method of identification was raised for configuring H.32Y as a combination of TA plus existing H.320.  If Q.2931 includes this specification in due time, TA products may support it.

These aspects will be communicated with SG11 as contained in Annex 5 (see §6.3 above).

6.7 Summary of the network adaptation discussion

	6.7.1 H.222.1 and AAL functions (TD-22)

After the first round discussion on the network adaptation related agenda items, the meeting asked Mr. R. terHorst to coordinate a small group to obtain deeper insight and agreements regarding H.222.1 and AAL functions.  During the review of its draft report (TD-22), specification for the use of FEC was clarified as follows:

•	Its use is mandatory at the encoder for communications between A2-A2, A2-B2 and B2-B2 type terminals.  Use of FEC is optional at the decoder as agreed in Singapore (see §6.2.3/AVC-707R).
•	Other cases need further consideration.  Contributions are solicited by the next meeting.
•	Two different RS polynomials are used in available chips.  Choice of a polynomial also needs contributions by the next meeting.

The final report is contained in Annex 7.  The meeting agreed on sending correspondence to SA&A/The ATM Forum and SAM/ETSI NA5 as in Annex 8 to obtain harmonized solutions for the network adaptation between SG15 , The ATM Forum and ETSI.

	6.7.2 Network adaptation protocol reference model (TD-18)

The network adaptation protocol reference model as in TD-3 (Singapore) was updated by incorporating this week achievements, particularly discussion on AAL and H.222.1 specific functions as given in Annex 7.  The outcome is contained in Annex 9.  The meeting considered that this useful information should appear in some Recommendation and concluded that H.222.1 is the most appropriate.

7. Draft H.222.1

7.1 stream_id definition (AVC-719, 740, TD-6)

AVC-719 and AVC-740 examined use of ITU-T stream types.  

The former proposed use of a stream_id_extension field as the first byte of the PES packet payload, and proposed in its annex coding for this field and allocation of each of the four ITU-T stream_ids to control, audio, video and auxiliary data.

The latter, together with TD-6, similarly proposed the first byte of the PES packet payload to be a multiplexing identification field, in the case of Program Stream.  However, the Transport Stream required no such field.  A flat codespace of H.32X elementary stream types was proposed.  PSI/PSM signalling maps these stream types to multiplex identified values. Further discussion is requires to choose one or integrate the two proposals.

The meeting agreed to include the outcome in H.222.1.

7.2 Descriptors (AVC-720)

AVC-720 proposed semantic constraints on program and program element descriptors usage.  The meeting agreed to include §2/AVC-720 in H.222.1.

7.3 Acknowledged signalling procedures (AVC-739)

AVC-739 proposed subchannel establishment and release protocol procedures for inclusion in H.222.1, with respect to H.222.1 acknowledged signalling procedures.  The meeting agreed to include these specifications in H.222.1, with review required by the next meeting.

During the discussion, it was clarified that two tools are in H.222.1, acknowledged and unacknowledged procedures and that use of them should be defined in H.300 series Recommendations.

7.4 Text for input to the SG15 meeting (AVC-715, AVC-713, TD-4; TD-13)

The H.222.1 text in AVC-715 was further elaborated by a editing team which Mr. S. Dunstan coordinated.  During the review of its outcome TD-13, the following comments were obtained and resolved:

•	Term “H.222.1 elementary stream” should be defined in §3.
•	Specifications which are mandatory to H.222.1 implementation may be derived from Conformance Part of the MPEG Systems standard.  Definition of capabilities is needed for other optional specifications.
•	Reference to the use of time stamps should be made in §§7.1, 8.1.
•	It may induce criticism at the SG15 meeting that such an essential content as §10 is left to further study.  The intention was explained to specify how the primitives at AAL-SAP be related to the H.222.1 data unit, but we need coordination with The ATM Forum solution which currently addresses specifically VOD.  Contributions are requested to fill this section.
•	Coding rule of H.222.1 specific descriptors should be included in §13.2.
•	Table 2 on p.12 should be moved to H.32X.  The current table indicates a framework, providing specific combination of “multiplex_id field” and “meaning” for understanding how to specify the default channel.

The updated text for the SG15 meeting is issued as a separate document AVC-744.

8. Draft H.24X (AVC-710, 722; AVC-713, TD-4, 7; TD-14)

AVC-710 provided a new text for H.24X capability exchange using ASN.1 representation, while AVC-722 proposed some amendments for the text.

During the discussion, the following comments were obtained:

•	We should clarify C&I signals and their transmission channels before deciding in which Recommendation to house C&I signals other than capability.  A support was expressed for including those C&I signals in a separate Recommendation.
•	We should seek alignment between H.24P and H.24X.  Rapporteur will contact Mr. R. Schaphorst.  It was pointed out that bitstreams become different when one uses ASN.1 representation and the other uses table representation even if the message definition is the same.

After the discussion, the meeting concluded as follows:

•	ACK/NACK procedures are introduced in the capability exchange.  This is useful to confirm the state (sleeping or not) of the higher layer even if the transport is error free.
•	Top level definition is included.
•	Tagging is added to OPTIONAL and CHOICE elements.
•	BITSTRING is employed instead of BOOLEAN for indication of specific capabilities in the message.

The H.24X text in AVC-710 was further elaborated by an editing team which Mr. D. Beaumont coordinated with the support of Mr. M. Nilsson back home.  During the review of its outcome TD-14, addition of “vintage” (year of establishment or revision of this Recommendation) indication was proposed and agreed.  Participants are requested to review the text further and advise Mr. Beaumont by Tuesday, January 31 of their findings.  

The updated text for the SG15 meeting is issued as a separate document AVC-745.

9. Draft H.32X 

9.1 Transfer rate representation (AVC-723)

AVC-723 discussed definition of transfer rate for the H.32X capability and operational parameter, proposing to represent transfer rate as the value n of n x 64 kbit/s.  The meeting accepted this proposal.  

The meeting confirmed that the calling side decides operational transfer rates of both channels (calling side to called side, called side to calling side) in terms of value n, and that asymmetry of transfer rate is allowed; service logic of the caller decides appropriate transfer rates taking into account transmit capability, receive capability and requested transfer rate from the remote end.  Bit rate at the start up of the call still needs resolution as discussed in §6.3 above.

The meeting discussed relationship between the transfer rate and traffic descriptor parameters.  The following needs further study and actions:

•	Request for definition of necessary AAL parameter values to use AAL1 SAR for piecewise constant bit rate operation; e.g. “undefined” bit rate value.
•	Examination of the impact of projected traffic parameter definition on the piecewise constant VBR operation.
•	Algorithm in the terminal to decide necessary minimum values of traffic descriptor parameters (peak cell rate, etc.) to accommodate variable bit rate source information.

The meeting recognized the necessity to define sending only terminals in H.32X.  Contributions are solicited by the next meeting.

In this context, requirements of mandatory support of B, 2B, H0, H11 and H12 rates were questioned; if a two way terminal is a combination of sending only and receiving only terminals and one way terminal is not required to support interworking modes, then eventually two way terminals conforming to H.32X need not support interworking modes.  Rapporteur requested to discuss these matters independently.

9.2 Text for input to the SG15 meeting (AVC-716; AVC-713, TD-4; TD-15)

The H.32X text in AVC-716 was further elaborated by an editing team which Mr. C-C. Li coordinated.  During the review of its outcome TD-15, the following comments were obtained and resolved:

•	In Table 1, video frame asynchronous signals -1, -2, 3 should be given concrete names.
•	In §4.3, a general description should be given to indicate that the encoder should produce a bitstream compliant to the specifications for a given capability but needs not support whole tools of the defined capability, whereas the decoder should be able to accept any bit streams conforming to the specifications.
•	Multipoint capabilities should be included in A2 and B2 terminals.
•	In Figure 2, phase names in alphabet and number should better be aligned with those of H.320 in the next version.  Indication of default audio(visual) channel need be considered.  Two modes of subchannel setup should be reflected in the diagram.
•	Intercommunication diagrams such as those in H.32Y should be included in §7.
•	In §7.2, mandatory interworking modes of operation are specified as B, 2B, H0, H11 and H12.  Some members expressed concern of extra hardware burden for H.32X terminals.  This specification still awaits firm consensus as discussed in Singapore, thus an Editor’s note is included to reflect this situation.

The updated text for the SG15 meeting is issued as a separate document AVC-746.

10. Draft H.32Y

10.1 Use of AAL5 for H.320 terminal adaptation (AVC-728; TD-4)

This document discusses H.320 adaptation to the ATM environments by using AAL5.  After some discussion the meeting recognized the need to study this configuration in the Experts Group; members are requested to respond to this proposal and comment on how to map this configuration in H.300 series Recommendations.  

Related to this input, the issue of network synchronization has been raised.  It was clarified that the current H.32Y takes into account asynchronous environments as an option (use of AAL1 adaptive clock instead of synchronous transfer).

10.2 Text for input to the SG15 meeting (AVC-717; AVC-713; TD-16)

The H.32Y text in AVC-717 was further elaborated by an editing team which Mr. H. Radha coordinated.  During the review of its outcome TD-16, the following comments were obtained and resolved:

•	Mr. K. Yamazaki clarified the use of SDT in B-N interworking situations.
•	Multipoint description should be included.
•	Description of H.32Y interworking with H.32X, H.32Z.1, H.32Z.2 should be included.
•	Q.2931 related questions should be sent to SG11 regarding specific Q.2931 values, interworking parameters, necessary call progress indications for interworking.

The updated text for the SG15 meeting is issued as a separate document AVC-747.

11. Draft H.32Z

11.1 Scope (AVC-714, 729, TD-7)

AVC-714 discussed that the guaranteed bandwidth LAN solution is not sufficient, that ITU-T should make Recommendation(s) to accommodate non-guaranteed bandwidth LAN systems as well by defining QoS and implicitly exclude transcoding which causes extra end-to-end delay.  It also provided some ideas to advise users that poor quality is caused by network problem, not ITU-T standard or terminal equipment and to automatically reject calls if QoS is too low.  As a conclusion, it proposed to split H.32Z into two Recommendations; H.32Z.1 for guaranteed bandwidth and H.32Z.2 for non-guaranteed bandwidth systems.

AVC-729 discussed that the issue is not in whether the LAN is bandwidth guaranteed or not, and provided a concept of virtual H.320 terminals (combination of terminal, LAN and gateway) for Recommendation H.32Z.

Mr. D. Skran provided information on PCWG, an industry group, for open personal conferencing specification.

During the discussion, the following views were expressed:

•	Defining QoS is not practical if we consider the fact that QoS has not been specified in H.320, leaving cost and complexity trade-off to design, and that technically defining QoS is not straightforward.
•	Users select acceptable QoS, not QoS fixed by ITU-T.
•	There is no mechanism for informing H.320 terminals on ISDN about problems on LAN.
•	For interoperability between H.32Z to H.32Z on the same LAN, we need more than the “virtual H.320” specifications.  Issue is open for the H.32Z terminal specification to allow different vendors.
•	Some members suggested to request PCWG to bring information to our meeting, but some other members thought it unlikely.
•	It should be our objective to seek maximum interoperability of audiovisual terminals regardless of the difference in networks where respective terminals are accommodated.
•	ITU-T should indicate its intention to standardize the visual telephone in LAN environments by issuing H.32Z as scheduled.

After considerable discussion, the meeting concluded as follows:

•	H.32Z is split into H.32Z.1 for GBW (guaranteed QoS) LANs and H.32Z.2 for NGBW (other than guaranteed QoS) LANs.
•	H.32Z.1 indicates examples of guaranteed QoS LANs; Iso-Ethernet, FDDI, etc.
•	We freeze H.32Z.1 in February, indicating the plan to subsequently generate H.32Z.2 in the scope.
•	Further commitments are solicited for producing H.32Z.2 and possibly H.22Z; some members informally expressed possibility.

The meeting also reviewed shortly the clocking issue in the LAN environments; AVC-728 gives an example solution for N-ISDN (synchronous) and LAN(asynchronous) interconnection.  This matter should be further studied towards the next meeting.

11.2 Text for input to the SG15 meeting (AVC-718, AVC-714; TD-17)

The H.32Z.1 text in AVC-718 was further elaborated by an editing team which Mr. G. Morrison coordinated.  During the review of its outcome TD-17, the following comments were obtained and resolved:

•	The title should indicate guaranteed QoS instead of original "guaranteed delivery", where guaranteed QoS is defined to be equivalent to that of N-ISDN.
•	Inclusion of ATM LAN in H.32Z.1 is not appropriate; H.320 adaptation to ATM environments has already been defined as H.32Y.
•	Standard interface of H.32Z.1 terminal and gateway with QoS guaranteed LAN, particularly with respect to user-to-network signalling, should be given to allow interoperability among different equipment manufactured by different providers, otherwise H.32Z.1 becomes a Recommendation addressing a black box of gateway, LAN and terminal combined, then the specifications become identical to H.320 and H.32Z.1 loses its raison d’etre.  In this sense, listing FDDI as an example of H.32Z.1 system is not appropriate because it does not have a signalling standard.  This comment was resolved by specifying that such LANs should conform to the terminal addressing specification which is to appear in the projected H.32Z.2.
•	In Figure 1, an H.32Z.2 regime should be included.
•	Possible support of MCU by the gateway should be mentioned in §3.  It is noted that such MCU may incorporate H.331 type (broadcasting type) facilities.

The updated text for the SG15 meeting is issued as a separate document AVC-748.

12. Work plan and work method

12.1 H.32X hardware trials

Four organizations (GCL, KDD, NTT, Sharp) in Japan are preparing for the field trial.  New volunteers are encouraged to participate as stated in Singapore (see §9.3/AVC-707R).

12.2 Second phase work (TD-3)

Rapporteur requested to consider the future work plan on the expectation that basic specifications and verification of core technology will be obtained by November 1995. Enhanced functionalities such as continuous presence multipoint utilizing the B-ISDN features are to be studied among others.

Correspondence and discussions at the next meetings are needed to help SG15 to identify its tasks in audiovisual / multimedia areas during and beyond the next study period (1997-2000).

12.3 Harmonization with other group activities (TD-3)

As a continuation of the Singapore closing session, the meeting discussed how to collaborate with MPEG on DSM-CC and RTI.  

We identified that DSM-CC will constitute an essential element of H.32X A1 and B1 terminals and need alignment with H.24X signalling.  Though some members expressed concern for lack of expertise in the current Experts Group regarding application protocols, the meeting concluded that ITU-T SG15 should make commitments in the development of DSM-CC specifications.  We will seek advice of SG15 in this respect, suggesting tentatively to seek the common text approach.

As to RTI, the meeting concluded it appropriate for us to seek another common text Recommendation which complements H.222.0.

Since it is not practical to have synchronized meetings this year, the meeting decided to collaborate with MPEG by sending delegates to the MPEG meetings.

12.4 Future meetings till November 1995

Meeting	Date	Place	
19th	15-18 May 1995	Telia Research, Stockholm	
20th	week of 23 or 30 October 1995	to be determined	

END

Annexes

Annex 1	Documents for the Kamifukuoka meeting	
Annex 2	DSM-CC over ATM architectures and session descriptions	
Annex 3	Protocol stack for H.24X	
Annex 4	Liaison to SG8 on multiple VCs and error free transport protocol for H.24X	
Annex 5	Requirements for Q.2931 signalling in form of liaison statement	
Annex 6	Liaison on ATM performance assumptions	
Annex 7	Network adaptation for the broadband audiovisual communication	
Annex 8	Correspondence to SA&A/The ATM Forum and SAM / ETSI NA5	
Annex 9	Network adaptation Protocol Reference Model	

Participants of the eighteenth meeting of the Experts Group 
for Video Coding and Systems in ATM and Other Network Environments
held in Kamifukuoka, Japan

Country 	Name	Organization	
Australia	Mr. Stuart Dunstan	Siemens	
Belgium	Mr. Olivier Poncin	BELGACOM	
Canada	Mr. Vahe  Balabanian	BNR	
Korea	Mr. Jin-Soo Kim	KAIST	
USA	Mr. Chia-Chang Li	AT&T	
	Mr. Jeffrey J. Lynch	IBM	
	Mr. Hayder Radha	AT&T	
	Mr. Dale Skran	AT&T	
	Mr. Gary A. Thom	DIS	
	Ms. Andria Wong	Bellcore	
Finland	Mr. Ron Brown	Nokia	
France	Mr. Eric Gonfia	CNET	
Japan	Mr. Keiichi Hibi	Sharp	
	Mr. Takao Kasahara	GCL	
	Mr. Masahisa Kawashima	NTT	
	Mr. Takayuki Kobayashi	GCL	
	Mr. Yasuhiro Kosugi	Tokyo Electric Power Company	
	Mr. Shin-ichi Kuribayshi	NTT	
	Mr. Takayuki Kushida	IBM Japan	
	Mr. Kazuhiro Matsuzaki	Mitsubishi	
	Mr. Yuichiro Nakaya	Hitachi	
	Mr. Sakae Okubo	GCL	
	Mr. Kiyoshi Sakai	Fujitsu	
	Mr. Shigeyuki Sakazawa	KDD	
	Mr. Yasuhiro Takishima	KDD	
	Mr. Tomoaki Tanaka	NTT	
	Mr. Hideyuki Ueno	Toshiba	
	Mr. Masahiro Wada	KDD	
	Mr. Tsutomu Washida	NITUAJ	
	Mr. katsuyuki Yamazaki	KDD	
Netherlands	Mr. Roel ter Horst	KPN-PTT	
UK	Mr. David Beaumont	BT	
	Mr. Geoff Morrison	BT	
Sweden	Mr. Sven O. Akerlund	Ericsson Business Networks