_____________________________

During the Eibsee meeting, the Mobile Group considered a solution to the problem for exchanging long control channel messages over channels with high error rate, called AL4. AL4 introduces significant changes to the multiplex layer, whereby segmentation and reassemby functionality is added with the definition of an ARQ protocol. The AL4 solution, although based on existing protocols, is still unproven, adds a significant change, and is not guaranteed to avoid conflict with the ARQ protocol implemented in the SRP or LAPM/V.42 layer. Another issue is that this change may also bring other IPR into the H.324 and related Recommendations.

The solution proposed in this paper has the advantage of introducing minimal technical changes to the current H.324 Annex C, and no changes to H.223 Annexes A, B, and C. This is a simpler approach based on the already-proven techniques in Recommendations H.324 and H.223. Additionally, no new IPR are added to the H.324 and related Recommendations.

The following text was reviewed by correspondence by the Mobile Group and it is proposed to be added at the end of the determined H.324 Annex C, which will fully define the solution to the Control Channel problem with large packets in high bit error rate channels.

•  Control Channel Definition for Mobile Terminals

Annex A/H.324 defines the protocol stack for control channels for use with generic H.324 terminals. For mobile applications, however, a reliable link layer may not be available under certain high bit error rate channels. These high bit error rates make the successful transmission of large H.245 messages unlikely, in particular the Capability Exchange message. This problem is circumvented by defining a segmentation layer between the H.245 and SRP/LAPM layers, as illustrated in Figure C.2/H.324. This modified protocol stack shall be used for the Control Channel in terminals defined by this Annex.

FIGURE C.2/H.324

Protocol stack for H.324/C control channel

•  Control Channel Segmentation and Reassembly Layer (CCSRL)

•  Framework of CCSRL

CCSRL is designed for segmenting MultimediaSystemControlPDU messages (CCSRL-SDUs) into one or more segments (CCSRL-PDUs). The CCSRL User shall always be H.245.

•  Primitives exchanged between CCSRL and the CCSRL User

The information exchanged between CCSRL and the CCSRL User includes the following primitives:

•  CCSRL-DATA.request (CCSRL-SDU)

•  CCSRL-DATA.indication (CCSRL-SDU)

•  Description of Primitives

•  CCSRL-DATA.request: This primitive is issued by the CCSRL User to CCSRL to request the transfer of an CCSRL-SDU to a corresponding CCSRL User.

•  CCSRL-DATA.indication: This primitive is issued to an CCSRL User by CCSRL to indicate the arrival of an CCSRL-SDU.

•  Description of Parameters

•  CCSRL-SDU: This parameter specifies the information exchanged between CCSRL and the CCSRL User. The length of the CCSRL-SDU may be variable. Each transmitted CCSRL-SDU shall contain an integral number of octets. The maximum size of CCSRL-SDUs that an CCSRL receiver can accept shall be 256.

•  CCSRL-PDU: This parameter specifies the information exchanged between the CCSRL and the lower layer. The length of the CCSRL-PDU is variable.

•  Functions of CCSRL

CCSRL provides the function of segmenting an CCSRL-SDU containing one or more ASN.1 messages (encoded as defined in ITU-T Rec. X.691) into one or more CCSRL-SDU segments.

•  Format and Coding of CCSRL

The format of the CCSRL-PDU is illustrated in Figure C.3/H.324.

FIGURE C.3/H.324

CCSRL-PDU Format

•  Last Segment (LS) Field

The 8-bit LS field indicates the last segment of an CCSRL-SDU.   It shall be set to "1111 1111" on the CCSRL-PDU containing the last segment of an CCSRL-SDU.   It shall be set to "0000 0000" otherwise. All other combinations for an LS field are invalid.

•  CCSRL-PDU Payload Field

The payload field of an CCSRL-PDU shall contain an CCSRL-SDU segment of at least one octet. The first octet of the CCSRL-PDU payload field shall be the first octet of the CCSRL-SDU segment.

•  Procedures for Encoding

Information received from the CCSRL User in an CCSRL-SDU by means of an CCSRL-DATA.request primitive shall be passed to the layer below using the following procedure:

•  Break the CCSRL-SDU into an appropriate number of segments.

•  for each CCSRL-SDU segment

•  Set LS to "1111 1111" if this is the last segment of an CCSRL-SDU.   Otherwise set LS to "0000 0000".

•  Pass the generated CCSRL-PDU to the underlying layer.

•  Procedures for Error Control

An invalid CCSRL-PDU is one which:

•  does not contain an integral number of octets, or

•  is longer than the maximum CCSRL-PDU size, or

•  is equal to 0 octets, or

•  contains an invalid LS field

CCSRL-PDUs which are invalid shall be discarded.

•  Interface to H.245

Interface to H.245 is defined by Primitives defined in C. C.8.1.2 .

•  Interface to V.42/SRP

Interface to V.42/SRP defined by the delivery of CCSRL-PDUs to the lower layer, i.e. V.42 or SRP, as defined in C. C.8.2 and C. C.8.3 , respectively.

•  SRP mode

The general description of the SRP protocol given in H.324 Annex A Section A.2 shall be followed with the following exceptions: The terminal shall transmit frames generated by the segmentation layer defined above whereby complete H.245 MultimediaSystemControlPDU messages of section A.2/H.324 are replaced by CCSRL frames. This is a generalization of the SRP protocol concept, where a H.245 message no longer needs to be transmitted within a single SRP frame, but can be transmitted in segments.

•  LAPM/V.42 mode

The description of the LAPM/V42 for H.324 terminals provided in H.324 Annex A Section A.3 is also applicable, with the exception that counter N401, maximum number of octets in an information field, may be set to a value smaller than 2048, but not shorter than the size of the frames generated by the CCSRL. Moreover H.245 MultimediaSystemControlPDU messages are not necessarily transmitted within one single LAPM/V.42 frame if this Annex is used.