Annex 2 to AVC-707R

SOURCE	:	Small group coordinated by Mr. S. Dunstan
TITLE	:	Group discussion on H.32X call phases and H.222.1 signalling
PURPOSE	:	Report

1.	H.24X
A proposal for H.24X was presented in AVC-677.  The outline presented was reasonable, and was a good basis for progress.  A variation on the description of capability sets was presented using ASN.1 notation in AVC-699.  ASN.1 notation was agreed to be an acceptable method of specification.  The nested structure described in AVC-699 is to be considered.
H.24X should be restricted to describe the H.32X terminal capabilities, and procedures for determination of the capabilities at the remote terminal.  Other H.32X terminal to terminal signalling should be described elsewhere.
While AVC-677 presented common syntax for H.24X and H.24P, this approach needs careful consideration because of the different requirements; e.g. H.24P may be critical in the field length but H.24X is not.
2.	T.120 protocols.
AVC-675 expressed SG8's concern regarding multiplexing of the T.120 signals in H.222.1.  T.120 signals may be very bursty.  H.222.1 could provide a transparent service for T.120 signals, but this would be at the expense of audio and video bandwidth.  The meeting confirmed that T.120 signals may be handled through use of a separate VC, or through H.222.1.  Both cases will be supported.
3.	Layered VIDEO and Multiple Virtual CHannels
Two possibilities exist for placing elementary streams, such as layered video signals, into multiple VCs, as shown in Figure 1.  The first, as outlined in AVC-664, is shown in Figure 1a) and employs one instance of H.222.0.  A compliant H.222.0 bitstream is formed and split in a suitable manner for ATM transmission.  In the second case, shown in Figure 1b), multiple instances of H.222.0 are used.  H.222.1 includes signalling to associate H.222.0 bitstreams carried within the two VCs.

Figure 1.  Choices in handling layered video in multiple Virtual Channels.
A comment made during the meeting was that VCs carrying enhancement video may not need to be H.222.0 compliant i.e. PCR/SCRs may only need to be carried in the VC carrying baseband video.
4.	PS/TS selection
Two methods for determining the H.222.1 mode of operation i.e. Program Stream or Transport Stream were considered.  They were,
•	out of band signalling using Q.2931 information elements at initial VC set up
•	H.24X capability exchange
In the former case the information could be conveyed in a new AV information element, or lower layer information element.  It was noted that delivery of the user-to-user information element is not guaranteed.  The specification of this method would require coordination with other study groups.
In the second method the H.222.1 protocol would remain inactive until after a first capability exchange has been completed.  H.222.1 might then become active on the same initial VC, resulting in establishment of a H.222.1 sub channel for conveyance of further H.24X information exchanges.  Alternatively, H.222.1 might become active on a second VC, allowing H.24X exchanges to continue in the initial VC, without use of H.222.1.  A H.24X protocol stack, and these events, are shown in Figure 2.

Figure 2.  H.24X protocol stack.  a) before H.222.1 becomes active in initial VC, b) after H.222.1 becomes active in initial VC.
The meeting agreed upon the second method.
In Figure 2 "protocol X" is a protocol which provides a reliable transport service for H.24X.  Possibly protocols include X.224, or SSCOP.  In the case of AAL type 1 a CRC32 and a framing function may be required.  Commonality with the T.120 protocol stack should be considered.
5.	Types of C&I
Three types of C&I information were recognised.  The three types, and their proposed methods of transport, are shown in table 1.
C&I signal	transport	described in	
frame synchronous	ITU-T auxiliary	H.32X	
mode switching	PSI/PSM	H.222.1	
capabilities exchange	ITU-T auxiliary	H.24X	
Table 1.  Types of C&I signals
H.222.1 will describe the method of achieving frame synchronous signalling.
6.	Call phases
Possible H.32X call phases, and possible H.222.1 sub channel set up and release acknowledgment procedures, were examined in AVC-702.  Following the outcomes described above, a modified call phase diagram is as shown in Figure 3.
7.	sub channel setup/release.
H.222.1 sub channel acknowledge procedures may be appropriate in the case of a bi-directional service.  This may be advantageous for the following reasons,
•	error conditions can be defined e.g. undefined multiplexing identifier.
•	synchronisation especially in the case where the remote user is not a human i.e. a computer.  Transmission cannot begin on a sub channel until it has been correctly established.
The following presents an incomplete description of possible sub channel setup and release procedures.
7.1.	Interface states
RELEASED - the sub channel is idle
AWAITING ESTABLISHMENT - a transitory state
ESTABLISHED - data may be transmitted/received in this sub channel
AWAITING RELEASE - a transitory state
7.2.	Interface signals
ESTABLISH request - request to establish a sub channel
RE ESTABLISH request - request to perform mode change on an existing sub channel
ESTABLISH response - response to a sub channel establish request
ESTABLISH confirm - the remote terminal has acknowledged the establishment/re establishment request
ESTABLISH indication - a remote terminal has requested establishment of a new sub channel
RELEASE request - request to release an existing sub channel
RELEASE confirm - the remote terminal has acknowledged the release request
RELEASE indication - a remote terminal has requested release of an existing sub channel
7.3.	State transition diagram

Figure 4.  Proposed state transition diagram for H.222.1 sub channel establishment and release
7.4.	Protocol Data Units
peer to peer action	Program Stream	Transport Stream	
request establishment	PMT req	PSI req	
confirm establishment	PMT ack	PSI ack	
release connection	PMT req	PSI req	
confirm release	PMT ack	PSI ack	
Table 2.  H.222.1 syntax to support indicated peer to peer action
7.5.	Examples

Figure 5.  Normal procedure.

Figure 6.  PSM/PSI CRC32 error detected.
8.	H.32X scenarios
8.1.	Symmetrical

Figure 7
8.2.	Server

Figure 8
8.3.	Broadcast

Figure 9
8.4.	Pay per view

Figure 10
- end -