.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .LP \fBMONTAGE:\ \fR FIN DE LA REC.\ H.120 EN T\* | TE DE CETTE PAGE .sp 2P .LP \v'11P' \fBRecommendation\ H.130\fR .RT .sp 2P .ce 1000 \fBFRAME\ STRUCTURES\ FOR\ USE\ IN\ THE\ INTERNATIONAL\fR .EF '% Fascicle\ III.6\ \(em\ Rec.\ H.130'' .OF '''Fascicle\ III.6\ \(em\ Rec.\ H.130 %' .ce 0 .ce 1000 \fBINTERCONNECTION\ OF\ DIGITAL\ CODECS\fR .ce 0 .sp 1P .ce 1000 \fBFOR\ VIDEOCONFERENCING\ OR\ VISUAL\ TELEPHONY\fR .ce 0 .sp 1P .ce 1000 \fI(Malaga\(hyTorremolinos, 1984; amended at Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP \fBIntroduction\fR .sp 1P .RT .PP Videoconferencing and visual telephony are new services which require greater bit rates than telephony. In the studies in CCITT on the ISDN and on international interworking, 384\ kbit/s is emerging as an important channel capacity for wideband services. On this basis it is recommended that the videoconferencing and visual telephone services should be based on multiples of 384\ kbit/s. .PP It is noted that both the 2048 kbit/s and 1544 kbit/s primary digital levels can be expressed by the formula\ \fIy\fR \ +\ (\fIn\fR \ \(mu\ 384)\ kbit/s, where \fIn\fR \ =\ 5 or 4 and \fIy\fR \ =\ 128 or 8\ kbit/s, respectively. .PP While this Recommendation covers only frame structures for transmission at the primary digital rates, it is not intended to suggest that transmissions using other frame structures or formats at primary rates or lower are precluded. In the future, frame structures based on other multiples and/or sub\(hymultiples of 384\ kbit/s may also be considered. .RT .sp 2P .LP \fB1\fR \fBCharacteristics of a 2048 kbit/s (n = 5) frame structure for use in codecs described in \(sc 1 of Recommendation H.120\fR .sp 1P .RT .sp 1P .LP 1.1\fR \fIGeneral characteristics\fR .sp 9p .RT .PP The multiplex structure described under \(sc 1 is suitable for use on digital paths and connections which interconnect video codecs for videoconferencing or visual telephony using 2048\ kbit/s transmission. The connections may either be direct or via higher\(hyorder digital multiplex equipment compatible with the primary PCM multiplex equipment defined in Recommendation\ G.732. .PP Some of the characteristics of this multiplex structure are identical to those in Recommendation\ G.704 and are covered by cross\(hyreferences to that Recommendation. .PP The main features of the multiplex structure are that it provides: .RT .LP \(em one 64 kbit/s channel for frame alignment, alarm signals and other signals as required; .LP \(em one 64 kbit/s channel reserved for the transmission of the sound signal; .LP \(em one 32 kbit/s channel for codec\(hyto\(hycodec information; .LP \(em the option of one or two 64 kbit/s channels and/or one 32\ kbit/s channel for stereophonic sound, facsimile, data,\ etc.; .LP \(em the possibility of end\(hyto\(hyend and subscriber\(hyto\(hynetwork signalling; .LP \(em the remaining capacity (between 1664 and 1888\ kbit/s) is used for the encoded video signal. .bp .sp 1P .LP 1.1.1 \fIFundamental characteristics\fR .sp 9p .RT .PP The multiplex structure contains 32 time slots, each of 64\ kbit/s. .RT .sp 1P .LP 1.1.2 \fIBit rate\fR .sp 9p .RT .PP The nominal bit rate is 2048 kbit/s. The tolerance on this rate is \(+-\ 50\ parts per million (ppm). .RT .sp 1P .LP 1.1.3 \fITiming signal\fR .sp 9p .RT .PP The timing signal is a 2048\(hykHz signal from which the bit rate is derived. It should be possible to derive the timing signal from an internal source or from the network. .RT .sp 1P .LP 1.1.4 \fIInterfaces\fR .sp 9p .RT .PP The interfaces should comply with Recommendation G.703. .RT .sp 1P .LP 1.2 \fIFrame structure and time slot allocations\fR .sp 9p .RT .PP The frame structure is in accordance with Recommendation G.704, \(sc\ 3.3. The time slot (TS) allocations within the frame are given in Table\ 1/H.130, two options are shown according to whether or not the network is switched (under control of signals within the frame structure). .RT .sp 1P .LP 1.3\fR \fICodec\(hyto\(hycodec information\fR .sp 9p .RT .PP This information is transmitted in the 32 kbit/s channel corresponding to odd frames of TS2 (frame parity is gained from the multiframe alignment in the 8th\ bit of alternate TS2, the frames are consecutively numbered\ 0 to\ 15, forming a multiframe). .PP The 32 kbit/s channel is structured in a multiframe and supermultiframe derived from 128\ consecutive\ 256\ bit frames. The multiframe is composed of 8\ octets numbered\ 1, 3, 5, . | | ,\ 15, each from TS2 in an odd numbered\ 256\ bit frame. The supermultiframe corresponds to 8\ consecutive multiframes which are numbered\ 0, 1, 2, . | | ,\ 7. .PP The use of the bits in each octet in the odd frames is as follows: .RT .LP \(em Bit 1 for clock justification , .LP \(em Bit 2 for buffer state , .LP \(em Bit\ 3 for coding mode identification; the 8\ consecutive bits\ 3 of TS2 in a multiframe will carry the following information: .LP Bit 3.1 .FS The notation used here should be interpreted as in the following examples:\ Bit\ 3.1 means Bit\ 3 (in TS2) of frame\ No.\ 1 in each multiframe: Bit\ 3.1.0 means Bit\ 3 (in TS2) of frame No.\ 1 in multiframe\ No.\ 0 of each supermultiframe. .FE Codec facilities\fR (see below) .LP Bit 3.3 Colour transmission (1 if provided) .LP Bit 3.5 split\(hyscreen indicator (if required) .LP Bit 3.7 Fast update request (1 if required) .LP Bit 3.9 Advance warning of interruption (1 if required) .LP Bit 3.11 Sound power signal, for use with encrypted .LP multipoint (under study) .LP Bit 3.13 Data distribution (1 if required) .LP Bit 3.15 Detection of looped ports (set to 1) .PP Bit 3.1 is used to signal the availability of certain facilities in the decoder at supermultiframe rate, as follows: .RT .LP Bit 3.1.0 Graphics (mode 1) (1 if provided) .LP Bit 3.1.1 High\(hyquality speech (1 if provided) .LP Bit 3.1.2 4\ \(mu\ 384 kbit/s capability (see Note\ 1) (1 if provided) .LP Bit 3.1.3 Encryption (1 if provided) .LP Bit\ 3.1.4 System\ M (1 if 525\(hyline signal being .LP coded) .LP Bit 3.1.5 Graphics (mode 2) (1 if provided) .LP Bit 3.1.6 Spare (set to 0) .LP Bit 3.1.7 2 \(mu 384 kbit/s capability (see Note 1) (1 if provided) .bp .ce \fBH.T. [T1.130]\fR .ce TABLE\ 1/H.130 .ce \fBTimeslot allocation in 32 Timeslot frame structure .ce of Recommendation G.704\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(96p) . { Timeslot allocation (within the 256\(hybit frame) } .T& lw(48p) | lw(48p) | lw(48p) . .T& cw(48p) | cw(48p) | cw(48p) . Bit rate (kbit/s) Non switched (i) Switched (ii) .T& lw(48p) | lw(48p) | lw(48p) . .TE .TS center box ; lw(84p) | lw(48p) | cw(48p) | cw(48p) . { Frame alignment, network alarms, etc. } as in G.704 0\fR 0 .T& lw(144p) . .T& lw(84p) | lw(48p) | cw(48p) | cw(48p) . Speech information 64 1 1 .T& lw(144p) . .T& lw(84p) | lw(48p) | cw(48p) | cw(48p) . { Codec\(hyto\(hycodec information } 32 2 2 .T& lw(144p) . .T& lw(84p) | lw(48p) | cw(48p) | cw(48p) . { Signalling information (subscriber\(hynetwork) } 64 \(em 16 .T& lw(144p) . .T& lw(84p) | lw(48p) | cw(48p) | cw(48p) . Fax, data, etc. (optional) up to 2 \(mu 64 17 and/or 18 17 and/or 18 .T& lw(144p) . .T& lw(84p) | lw(48p) | cw(48p) | cw(48p) . { Encoded video information (minimum) } { (i) 27 \(mu 64 (ii) 26 \(mu 64 } { \ 3 to 16 \ \ + \ \ 19 to 31 } { \ 3 to 15 \ \ + \ \ 19 to 31 } .T& lw(144p) . .T& lw(228p) . .TE .nr PS 9 .RT .ad r \fBTableau 1/H.130 [T1.130], p.\fR .sp 1P .RT .ad b .RT .LP .bp .LP \(em Bit 4 to identify the use of time slots; the 8\ consecutive bits\ 4 of TS2 in a multiframe will carry the following information: .LP Bit 4.1 TS2 (even) is used for video (0) or other (1) .LP Bit 4.3 TS16 is used for video (0) or other (1) .LP Bit 4.5 TS17 is used for video (0) or other (1) .LP Bit 4.7 TS18 is used for video (0) or other (1) .LP Bit 4.9 TS16, 26 to 31 are not used for video (see Note 2) .LP Bit 4.11 Graphics transmission (1 if required) .LP Bit 4.13 Error correction (1 if required) .LP (see Note\ 3) .LP Bit 4.15 Use of time slots for video in conjuction with bit 4.9 (see Note 2) .LP \(em Bit 5 for multipoint conferencing; provides a 4\ kbit/s message channel (transparent through the codec) from customer to multipoint control unit, between control units and from customer to customer. (The message format and protocols are under study.) .LP When the codec is not equipped with a message channel, bit\ 5 is used to signal split\(hyscreen: 1\ =\ split\(hyscreen active, 0\ =\ split\(hyscreen inactive. .LP \(em Bit 6 free (for possible national use) (set to 0) .LP \(em Bit 7 free (for possible national use) .LP \(em Bit 8 for multiframe and supermultiframe alignment; the values of bit\ 8 in each frame of the multiframe (multiframe and supermultiframe alignment patterns) should be as detailed in Table\ 2/H.130. .PP \fINote\ 1\fR \ \(em\ Bits 3.1.2 and 3.1.7, taken together, signal the capability of the codec to operate at various bit rates, as follows: .LP .sp 1 .LP Bit 3.1.2 \ \ Bit 3.1.7 0 \ \ 0\ \ \ 2 Mbit/s only 1 \ \ 0\ \ \ 2 Mbit/s and 4 \(mu 384 kbit/s operation 0 \ \ 1\ \ \ 2 Mbit/s and 2 \(mu 384 kbit/s operation 1 \ \ 1\ \ \ 2 Mbit/s and 4, 3, and 2 \(mu 384 kbit/s operation .PP \fINote\ 2\fR \ \(em\ Bits 4.9 and 4.15, taken together, signal the time slots available (subject to the settings of bits\ 4.1, 4.3, 4.5 and\ 4.7) for video at various bit rates. The use of TS0, TS1 and TS2 (odd) is unaffected by these bits. .LP .sp 1 .LP Bit 4.9 Bit 4.15 Bit rate Time slot available for video 0 0 2 | 48 kbit/s TS2 (even), TS3\(hy31 1 0 4 \(mu 384 kbit/s TS2 (even), TS3\(hy15 and 17\(hy25 .LP 1 1 3 \(mu 384 kbit/s TS2 (even), TS3\(hy9 and 17\(hy25 0 1 2 \(mu 384 kbit/s TS2 (even), TS3\(hy6 and 17\(hy22 .LP A 2 Mbit/s codec which allows \fIn\fR \ \(mu\ 384 kbit/s working, will set to zero time slots other than those mentioned above in its transmitter and ignore them in the receiver. .bp .PP \fINote\ 3\fR \ \(em\ When set to 1, the last 64 bits of each multiframe contain the error corrector parity bits. The multiframe then appears as follows: .LP .rs .sp 12P .ad r \fBDiagramme, p.\fR .sp 1P .RT .ad b .RT .PP The conditions signalled in bits\ 3 and\ 4 can only change at supermultiframe rate. The change at the decoder will take place at the start of the first supermultiframe following the one where the change in signalling has been detected. This procedure can be used to improve the resistance to transmission errors. .LP .sp 2 .ce \fBH.T. [T2.130]\fR .ce TABLE\ 2/H.130 .ce \fBMultiframe and supermultiframe alignment on bit 8 of TS2 (odd)\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(144p) . Multiframe alignment pattern .T& lw(144p) . .TE .TS center box; lw(42p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) . Frame \ 1 1 1 1 1 1 1 1 1 \ 3 1 1 1 1 1 1 1 1 \ 5 1 1 1 1 1 1 1 1 \ 7 0 0 0 0 0 0 0 0 \ 9 0 0 0 0 0 0 0 0 11 1 1 1 1 1 1 1 1 13 0 0 0 0 0 0 0 0 15 1 1 1 0 0 1 0 (Note) .TE .nr PS 9 .RT .ad r \fBTableau 2/H.130 [T2.130], p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 2P .LP \fB2\fR \fBCharacteristics of a 1544 kbit/s (n = 4) frame structure for use with codecs described in \(sc 2 of Recommendation H.120\fR .sp 1P .RT .sp 1P .LP 2.1\fR \fIGeneral characteristics\fR .sp 9p .RT .PP The multiplex structure described under \(sc 2 is suitable for use on digital paths and connections which interconnect video codecs for videoconferencing or visual telephony using 1544\ kbit/s transmission. The connections may either be direct or via higher\(hyorder digital multiplex equipment compatible with the primary PCM multiplex equipment defined in Recommendation\ G.733. .PP Some of the characteristics of this multiplex structure are identical to those in Recommendation\ G.704 and/or in \(sc\ 1 of this Recommendation; these are covered by cross\(hyreferences to the appropriate documents. .PP The main features of the multiplex structure are that it provides: .RT .LP \(em one 8 kbit/s channel for frame alignment, alarm signals and other signals as required; .LP \(em one 64 kbit/s channel for the sound signal; .LP \(em one 32 kbit/s channel for codec\(hyto\(hycodec information; .LP \(em the option of one or two 64\ kbit/s channels and/or one 32\ kbit/s channel for auxiliary data services; .LP \(em the remaining capacity (between 1280 and 1440\ kbit/s) is used for the encoded video signal. .sp 1P .LP 2.1.1 \fIFundamental characteristics\fR .sp 9p .RT .PP The multiplex structure contains 24 time slots per frame, each of 64\ kbit/s, plus one bit per frame for frame alignment and signalling. The number of bits per frame is 193 and the nominal frame repetition rate is 8000\ Hz. .RT .sp 1P .LP 2.1.2 \fIBit rate\fR .sp 9p .RT .PP The nominal bit rate is 1544 kbit/s. The tolerance on this rate is \(+-\ 50\ parts per million (ppm). .RT .sp 1P .LP 2.1.3 \fITiming signal\fR .sp 9p .RT .PP The timing signal is a 1544 kHz signal from which the bit rate is derived. It should be possible to derive the timing signal from an internal source or from the network. .RT .sp 1P .LP 2.1.4 \fIInterfaces\fR .sp 9p .RT .PP The interfaces should comply with Recommendation G.703; the option of AMI or B8ZS should be provided as the interface code. Which of the two codes is used should be determined by bilateral agreement. .RT .sp 1P .LP 2.1.5 \fIFormat restrictions enforced by the network\fR .sp 9p .RT .PP As indicated in Recommendation G.703, runs of more than 15 \*Qzeros\*U are forbidden in some networks; also, there must be, on average, at least three \*Qones\*U in every 24\ digits. Provision is made by means of a scrambling system to ensure that forbidden patterns cannot occur. .RT .sp 2P .LP 2.2 \fIFrame structure and time slot allocations\fR .sp 1P .RT .PP The basic frame structure follows Recommendation G.704. The time slots are numbered from\ 1 to\ 24, with the 1st\ bit positioned between TS24 and\ TS1. .bp .RT .sp 1P .LP 2.2.1 \fIFrame alignment\fR .sp 9p .RT .PP The basic frame alignment is obtained at bit No. 1, as in Recommendation\ G.704, Method\ 2 (see \(sc\ 2.1.3.2). The pattern transmitted is as shown in Table\ 3/H.130. .RT .ce \fBH.T. [T3.130]\fR .ce TABLE\ 3/H.130 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(54p) | cw(54p) | cw(54p) | cw(54p) . Frame No. Frame alignment signal S\(hybit Signalling bit _ .T& cw(54p) | cw(54p) | cw(54p) | cw(54p) . \ 1 1 \(em .T& cw(54p) | cw(54p) | cw(54p) | cw(54p) . \ 2 \(em 0 .T& cw(54p) | cw(54p) | cw(54p) | cw(54p) . \ 3 0 \(em .T& cw(54p) | cw(54p) | cw(54p) | cw(54p) . \ 4 \(em 0 .T& cw(54p) | cw(54p) | cw(54p) | cw(54p) . \ 5 1 \(em .T& cw(54p) | cw(54p) | cw(54p) | cw(54p) . \ 6 \(em 1 A .T& cw(54p) | cw(54p) | cw(54p) | cw(54p) . \ 7 0 \(em .T& cw(54p) | cw(54p) | cw(54p) | cw(54p) . \ 8 \(em 1 .T& cw(54p) | cw(54p) | cw(54p) | cw(54p) . \ 9 1 \(em .T& cw(54p) | cw(54p) | cw(54p) | cw(54p) . 10 \(em 1 .T& cw(54p) | cw(54p) | cw(54p) | cw(54p) . 11 0 \(em .T& cw(54p) | cw(54p) | cw(54p) | cw(54p) . 12 \(em 0 B _ .TE .nr PS 9 .RT .ad r \fBTableau 3/H.130 [T3.130], p.\fR .sp 1P .RT .ad b .RT .LP .sp 2 .sp 1P .LP 2.2.2 \fISpeech\fR .sp 9p .RT .PP Speech is transmitted at 64 kbit/s in TS1. The coding law is the A\(hylaw of Recommendation\ G.711 or, for future applications, the law that will be recommended by CCITT for higher\(hyquality speech. In the case of stereophonic transmission, the second speech channel will be transmitted in TS17. .RT .sp 1P .LP 2.2.3 \fICodec\(hyto\(hycodec information\fR .sp 9p .RT .PP This information is transmitted in the 32\(hykbit/s channel corresponding to the odd frames of TS2. The channel is structured in multiframes of 16\ frames and supermultiframes of 8\ multiframes in exactly the same way as in the 2\(hyMbit/s version in \(sc\ 1. Multiframe and supermultiframe alignment are obtained from bit\ 8 of TS2 (odd) in the same way as in \(sc\ 1. .PP The multiframe of TS2 for codec\(hyto\(hycodec signalling is quite independent of the basic 12\(hyframe multiframe of Recommendation\ G.704. .RT .sp 1P .LP 2.2.4 \fISignalling\fR .sp 9p .RT .PP In the future, some 1.5 Mbit/s networks will allow the use of bits\ A and\ B for signalling. This facility is not available on all networks. .RT .sp 1P .LP 2.2.5 \fIFacsimile, data, etc.\fR .sp 9p .RT .PP When required, this information will be transmitted in TS16 and\ TS17 and TS2 (even). .bp .RT .sp 1P .LP 2.2.6 \fIEncoded video\fR .sp 9p .RT .PP A minimum of 20 \(mu 64 kbit/s capacity is reserved for encoded video in TS3\(hy15 and\ 18\(hy24; depending on applications, TS2 (even), TS16 and\ 17 may also be used for video, providing a maximum of 22.5\ \(mu\ 64\ kbit/s capacity. The available bit rate for video therefore lies between 1280 and 1440\ kbit/s. .RT .sp 1P .LP 2.3\fR \fICodec\(hyto\(hycodec information\fR .sp 9p .RT .PP The structure of the multiframe and supermultiframe are exactly the same as in \(sc\ 1, except that each frame contains only 24\ time slots as compared with 32 in the frames in \(sc\ 1. .PP The bit allocations [in TS2 (odd)] are identical with \(sc\ 1, with the following exceptions: .RT .LP \(em Bit 1 for clock justification; required for interworking with 625\(hyline codecs; disregarded in 525\(hyline decoders. .LP \(em Bit 3.1.2 is permanently set to 1 (see Note 1) .LP \fR \(em Bit 4.9 time slots are used for video (see Note 2) .LP \(em Bit 6 is reserved for the transmission of encryption data (see Annex\ D Recommendation\ H.120). .LP \(em Bit 7 is used for scrambler control (see \(sc 2.4). .PP \fINote\ 1\fR \ \(em\ Bits 3.1.2 and 3.1.7, taken together, signal the capability of the codec to operate at various bit rates, as follows: .LP .sp 1 .LP Bit 3.1.2 \ \ Bit 3.1.7 0 \ \ 0\ \ \ Not used in 525\(hyline codecs 1 \ \ 0\ \ \ 4 \(mu 384 kbit/s 0 \ \ 1\ \ \ 2 \(mu 384 kbit/s operation 1 \ \ 1\ \ \ 4, 3, and 2 \(mu 384 kbit/s operation .PP \fINote\ 2\fR \ \(em\ Bits 4.9 and 4.15, taken together, signal the time slots available (subject to the settings of bits\ 4.1, 4.3, 4.5 and\ 4.7) for video at various bit rates. The use of TS1 and\ TS2 (odd) is not affected by these bits. .LP .sp 1 .LP Bit 4.9 Bit 4.15 Bit rate Time slots available for video 0 0 This combinaison is not used in 525\(hyline codecs .LP 1 0 4 \(mu 384 kbit/s TS2 (even), TS3\(hy24 1 1 3 \(mu 384 kbit/s TS2 (even), TS3\(hy9 and 16\(hy24 0 1 2 \(mu 384 kbit/s TS2 (even), TS3\(hy6 and 16\(hy21 .sp 2P .LP 2.4\fR \fIScrambling\fR .sp 1P .RT .sp 1P .LP 2.4.1 \fIGeneral\fR .sp 9p .RT .PP The bit sequence produced by a videoconference codec is not subject to any limitation on the bit patterns that are generated. Therefore, reversible processing has to be carried out at the output and input ports to ensure that the format restrictions specified for some 1544\ kbit/s networks are not violated. .PP There are two typical constraints on the format: .RT .LP 1) There must not be runs of more than 15 consecutive \*Qzeros\*U. .LP 2) The average density of \*Qones\*U must be at least 12.5%. .bp .PP A classical self\(hysynchronizing or reset scrambler, based on a maximum\(hylength pseudo\(hyrandom sequence, is incapable of guaranteeing that such a bit\(hysequence never occurs. It is however possible, by judicious choice of scrambler design, to minimize the number of violations of the above rules to such an extent that the residual violations can be removed by forcibly inserting \*Qones\*U. The effect of this is to introduce transmission errors giving a residual bit\(hyerror\(hyratio of approximately 1\ \(mu\ 10\uD\dlF261\u7\d, which is imperceptible as far as the picture quality is concerned. .sp 1P .LP 2.4.2 \fIDetails of scrambling \(em first stage\fR .sp 9p .RT .PP The scrambling sequence is applied to all 24 time slots but not to bit\ 193 nor to bit\ 7 of TS2 (odd). .PP \fINote\fR \ \(em\ If data are inserted and/or extracted from TS2 (even), 16 or 17 within the network, the insertion/extraction equipments must ensure that the network constraints are not violated. .PP The 1544 kbit/s serial data from the codec are first applied to the following scrambling sequence: .RT .sp 1P .ce 1000 I\ N\ I\ N\ N\ I, .ce 0 .sp 1P .LP where .LP I = inverted and .LP N = do not invert. .LP This sequence starts from the bit following bit\ 193, and is restarted every frame. Bit\ 193 and bit\ 7 of TS2\ (odd) are not scrambled but the scrambling sequence is continuous through bit\ 7 of TS2\ (odd). .sp 1P .LP 2.4.3 \fIDetails of scrambling \(em second stage\fR .sp 9p .RT .PP Data scrambled by the above sequence are then checked for runs of more than 15\ zeros. For signalling purposes, these data are considered to be in blocks of 385\ bits. Each block starts with bit\ 8 of TS2\ (odd) and ends with bit\ 6 of TS2\ (odd). If a block of data preceding bit\ 7 of TS2\ (odd) is found \fInot\fR to contain the string of data, 1\ 00000000\ 00000000 (i.e.\ no runs of 16 or more zeros), bit\ 7 of TS2\ (odd) is set to one. .PP If a block of data preceding bit\ 7 of TS2\ (odd) is found to contain the string of data, 1\ 00000000\ 00000001 (i.e.\ a run of 15\ zeros), bit\ 7 of TS2\ (odd) remains set to one, even if one or more subsequent runs of zeros within the same block reaches or exceeds 16. However, in such a case, the 16th\ zero(s) of the run(s) are set to one. As this is not signalled to the descrambler, it causes (a) single\(hybit transmission error(s). .PP Bit 7 of TS2 (odd) is set to zero only if the preceding block of data is found to contain the string, 1\ 00000000\ 00000000 (i.e.\ a run of 16\ zeros or more), in which case the 16th\ zero is inverted to one and all subsequent strings of the form 1\ 00000000\ 0000000B within the same block have bit\ B inverted, except in the case where bit\ B\ =1 before inversion, in which case it remains unchanged. .RT .sp 1P .LP 2.4.4 \fIDetails of \fR \fIdescrambler\fR .sp 9p .RT .PP When bit 7 of TS2 (odd) is one, the preceding block of scrambled data is left unchanged. When bit\ 7 of TS2 (odd) is zero, the descrambler must detect all occurrences of the string 1\ 00000000\ 0000000B in the preceding block and invert the bit\ B. This can introduce transmission errors if the second or subsequent runs of zeros within the block (at the scrambler) contain 15\ zeros. .PP The repetitive scrambling sequence, I\ N\ I\ N\ N\ I, is then applied to the data. .PP For the purpose of counting runs of zeros, at both the scrambler and descrambler, bit\ 7 of TS2\ (odd) and bit\ 193 are both assumed to be zero. In the case where bit\ B would be on bit\ 193 or bit\ 7 of TS2\ (odd), the string 1\ 00000000\ 000000B is used instead of 1\ 00000000\ 0000000B. Only bit\ B has to be within the block of data being considered. The preceding zeros may lie partially or completely within the preceding block. .PP When bit B is inverted, the \*Qzeros\*U counter is reset to zero. .bp .RT .sp 2P .LP \fB3\fR \fBCharacteristics of a 1544 kbit/s (n = 4) frame structure for use with codecs described in \(sc 3 of Recommendation H.120\fR .sp 1P .RT .sp 1P .LP 3.1 \fIGeneral characteristics\fR .sp 9p .RT .PP The multiplex structure describes under \(sc 3 is suitable for use on digital paths and connections which interconnect video codecs for videoconferencing or visual telephony using 1544\ kbit/s transmission. The connection may either be directly via the ISDN defined in Recommendation\ I.431 or via higher order digital multiplex equipment compatible with the primary PCM multiplex equipment defined in Recommendation\ G.733. .PP The main features of the multiplex structure are that it provides: .RT .LP \(em one 8 kbit/s channel for frame alignment, alarm signals and other signals as required, .LP \(em one 64 kbit/s channel for the audio signal, .LP \(em one 32 kbit/s channel for codec\(hyto\(hycodec information, .LP \(em one optional 64 kbit/s for auxiliary data service, and .LP \(em the use of the remaining capacity (between 1376 and 1440\ kbit/s) for the encoded video signal. .sp 1P .LP 3.1.1 \fIFundamental characteristics\fR .sp 9p .RT .PP The multiplex structure contains 192 bits per frame plus one bit per frame for frame alignment and other purposes. The nominal frame repetition rate is 8000\ Hz. .RT .sp 1P .LP 3.1.2 \fIBit rate\fR .sp 9p .RT .PP The nominal bit rate is 1544 kbit/s with a tolerance of \(+- | 0\ parts per million (ppm). .RT .sp 1P .LP 3.1.3 \fITiming signal\fR .sp 9p .RT .PP The timing signal is a 1544 kHz signal from which the bit rate is derived. It should be possible to derive the timing signal either from an internal source or from the network. .RT .sp 1P .LP 3.1.4 \fIInterfaces\fR .sp 9p .RT .PP The interfaces should comply with Recommendation G.703. The interface code should be either of AMI/B8ZS described in Recommendation\ G.703, in addition to which CMI (Coded Mark Inversion) code is also applicable when the codec is installed as a part of terminal equipment. Which of the three codes is used should be determined by bilateral agreement. .RT .sp 1P .LP 3.1.5 \fIFormat restrictions enforced by the network\fR .sp 9p .RT .PP As indicated in Recommendation G.703, runs of more than 15 \*Qzeros\*U are forbidden in some networks. Additionally, on the average, there must be at least three \*Qones\*U in every 24\ digits. Provision is made by means of a stuffing system to ensure that forbidden patterns do not occur. .RT .sp 1P .LP 3.2 \fIFrame structure and bit allocation\fR .sp 9p .RT .PP The basic frame structure follows Recommendation G.704 with changes in bit allocations. The bits in a frame are numbered from 1\ to\ 193 with a transmission frame bit as numbered one. Remained 192\ bits are divided into 24\ time slots (TS) in which each time slot has 64\ kbit/s rate. Time slot number is assigned to each TS in the way that the first slot is TS1 and the last slot is TS24. Bit allocation in a frame is shown in Figure\ 1/H.130. .RT .sp 1P .LP 3.2.1 \fIFrame alignment\fR .sp 9p .RT .PP The basic frame alignment is obtained at bit No. 1 as in Recommendation\ G.704, Method\ 1 (\(sc\ 2.1.3.1). .RT .sp 1P .LP 3.2.2 \fIAudio signal\fR .sp 9p .RT .PP The audio signal is transmitted at 64 kbit/s in TS1. .bp .RT .LP .rs .sp 47P .ad r \fBFigure 1/H.130, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 3.2.3 \fICodec\(hyto\(hycodec information\fR .sp 9p .RT .PP This information is transmitted in odd numbered time slots 2 the 32\ kbit/s channel. Identification of codec\(hyto\(hycodec information is made by detecting multiframe alignment which is inserted in the eighth bit of the odd numbered TS2. .PP The channel is structured in multiframes of 16 frames each (numbered from 1\ to\ 16) and supermultiframes of 8\ multiframes each (numbered from 1\ to\ 8). Multiframe and supermultiframe alignment is obtained from bit No.\ 8 in TS2. .PP The multiframe of the codec\(hyto\(hycodec information channel is independent of the multiframe of the transmission frame generated by bit No.\ 0. .RT .sp 1P .LP 3.2.4 \fIAuxiliary data information\fR .sp 9p .RT .PP When required, this information is transmitted basically in TS16 which is used for the encoded video signal when no optional auxiliary equipment is connected. If stuffing is performed due to some channel restrictions, data alignment is as given in \(sc\ 3.4.2. .RT .sp 1P .LP 3.2.5 \fIEncoded video\fR .sp 9p .RT .PP A minimum of 64 \(mu 21.5 kbit/s capacity is primarily reserved for encoded video in even numbered TS2, TS3 through TS15 and TS17 through TS24. When the auxiliary data information channel is not set up, the capacity is increased to 64\ \(mu\ 22.5\ kbit/s with TS16 added. The available bit rate for the encoded video signal therefore lies between\ 1376 and 1440\ kbit/s. If stuffing is performed, data alignment is as given in \(sc\ 3.4.2. .RT .sp 1P .LP 3.3 \fICodec\(hyto\(hycodec information channel\fR .sp 9p .RT .PP The use of the bits in the codec\(hyto\(hycodec information channel is as follows (see Table\ 4/H.130). In the following Sections, the notation, \*Qm.n.l\*U, is used for a bit position expressing the \fIn\fR th multiframe and the \fIl\fR th supermultiframe of bit No.\ m. .RT .sp 1P .LP 3.3.1 \fIC\fR .sp 9p .RT .EF '% \fI1\ Bit'' .OF '''\fI1\ Bit %' .LP .sp 1 Bits 1.1, 1.5, 1.9, 1.13 Permanently set to 1 Bits 1.3, 1.7, 1.11 FC (sampling frequency control) .PP The lower 8 bits of the binary count for the two supermultiframe periods, i.e.\ 32\ ms, are measured with the video sampling frequency clock, the MSB first. These same 8\(hybit words are transmitted in the three bits (1.3, 1.7 and\ 1.11) as well as in the two consecutive multiframes. .RT .PP .sp 1 Bit 1.15 Spare (Note) \fINote \ \(em\ \fR Spare bits are set to 1. .sp 1P .LP 3.3.2 \fIC\fR .sp 9p .RT .EF '% \fI2\ bit:\ stuffing\ flag'' .OF '''\fI2\ bit:\ stuffing\ flag %' .LP .sp 1 Bits 2.1\(hy2.15 (odd number) 0 if not stuffed .PP The stuffing flag consists of four bits including C\d2\uand C\d7\uin each violation detection block (four frame length) which is defined in \(sc\ 3.4.2. The first three bits are used for majority decision logic at the decoder. When the result indicates \*Qstuffing\*U, the decoder undergoes destuffing. .bp .RT .ce \fBH.T. [T4.130]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(342p) . TABLE\ 4/H.130 .T& cw(342p) . { \fBCodec\(hyto\(hycodec information\fR } .TE .TS center box; cw(42p) | cw(36p) | cw(36p) | cw(36p) | cw(36p) | cw(36p) | cw(36p) | cw(36p) | cw(36p) . Multiframe frame number C 1 C 2 C 3 C 4 C 5 C 6 C 7 C 8 .TE Unable to convert rest of table. .nr PS 9 .RT .ad r \fBTableau 4/H.130 [T4.130], p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 3.3.3 \fIC\fR .sp 9p .RT .EF '% \fI3\ bit:\ codec\ facility/coding\ mode'' .OF '''\fI3\ bit:\ codec\ facility/coding\ mode %' .LP .sp 1 Bit 3.1 Codec facilities Bit 3.1.1 Graphics mode 1 (high resolution) (0 if provided) .LP Bit 3.1.2 Bit sequence independence (0 if secured) Bit 3.1.3 Monochrome mode (0 if provided) Bit 3.1.4 Video encryption (0 if provided) Bit 3.1.5 Audio encryption (0 if provided) .LP Bit 3.1.6 Pointing function (0 if provided) Bit 3.1.7 Graphics (mode 2, standard resolution) (0 if provided) Bit 3.1.8 Spare (Note 1) .LP Bit 3.3 Spare (Note) Bit 3.5 Spare (Note) Bit 3.7 Spare (Note) .LP Bit 3.9 Spare (Note) Bit 3.11 Spare (Note) Bit 3.13 Spare (Note) Bit 3.15 Coding mode .LP Bit 3.15.1 Video encryption (0 if used) Bit 3.15.2 Audio encryption (0 if used) Bit 3.15.3 Frame memory refresh request (0 if requested) .PP Bit 3.15.4 Backward path (0 if available) Bit 3.15.5\(hy3.15.8 Spare (Note) \fINote\fR \ \(em\ Spare bits are set to 1. .sp 1P .LP 3.3.4 \fIC\fR .sp 9p .RT .EF '% \fI4\ bit:\ channel\ assignment\ flag'' .OF '''\fI4\ bit:\ channel\ assignment\ flag %' .LP .sp 1 Bits 4.1, 4.3, 4.5, 4.7 Auxiliary data channel flag (0 if used) Bits 4.9, 4.11, 4.13, 4.15 Graphics mode flag (0 if used) .PP In graphics mode, video data are inhibited and their bit positions are used for graphics data transmission. These two flags consist of four bits as stuffing flag. Both auxiliary data and graphics data can be inserted or removed in a unit of multiframe (16\ frames). Flags should precede the data by a multiframe. .RT .sp 1P .LP 3.3.5 \fIC\fR .sp 9p .RT .EF '% \fI5\ bit:\ Message\ channel\ 1'' .OF '''\fI5\ bit:\ Message\ channel\ 1 %' .PP .sp 1 Bits 5.1\(hy5.15 (odd number) Message channel 1 (Note) \fINote\fR \ \(em\ Protocols for these message channels are under study. .bp .sp 1P .LP 3.3.6 \fIC\fR .sp 9p .RT .EF '% \fI6\ bit:\ Message\ channel\ 2'' .OF '''\fI6\ bit:\ Message\ channel\ 2 %' .PP .sp 1 Bits 6.1\(hy6.15 (odd number) Message channel 2 (Note) \fINote\fR \ \(em\ Protocols for these message channels are under study. .sp 1P .LP 3.3.7 \fIC\fR .sp 9p .RT .EF '% \fI7\ bit:\ Stuffing\ flag'' .OF '''\fI7\ bit:\ Stuffing\ flag %' .LP .sp 1 Bit 7.1\(hy7.15 (odd number) 0 if stuffed .sp 1P .LP 3.3.8 \fIC\fR .sp 9p .RT .EF '% \fI8\ bit:\ Multiframe\ alignment'' .OF '''\fI8\ bit:\ Multiframe\ alignment %' .PP .sp 1 Bits 8.1, 8.3, 8.7, 8.9, 8.11. 8.13 Multiframe alignment signal (1110010) Bit 8.15 Supermultiframe alignment signal (1110010*) (see Note) \fINote\fR \ \(em\ The bit * is used for future higher order multiframing. .sp 2P .LP 3.4 \fIStuffing\fR .sp 1P .RT .sp 1P .LP 3.4.1 \fIGeneral\fR .sp 9p .RT .PP The bit sequence produced by a videoconferencing codec is not subject to any limitation on the bit patterns that are generated. Therefore, reversible processing has to be carried out at the output and input ports to ensure that the format restrictions specified for some 1544\ kbit/s networks (described in \(sc\ 3.1.5 above) are not violated. .PP To ensure this, the stuffing method shuld be employed in which necessary \*Qones\*U are inserted, or stuffed, if any violations are found in a block of bit streams to be transmitted. A flag is attached to the block to identify whether or not the block is stuffed. .RT .sp 1P .LP 3.4.2 \fIDetails of stuffing\fR .sp 9p .RT .PP Each block, which consists of four transmission frame lengths, i.e.\ 4\ \(mu\ 193\ =\ 772\ bits starting from the C\d1\ubit of the codec\(hyto\(hycodec information in the (4\fIn\fR \(em3)th frame, is checked. If any violations occur with respect to the rules: .RT .LP \(em no more than 15 consecutive zeros, and .LP \(em at least 3 ones in any 24 bits, .LP ones are stuffed as follows: .LP TS1 not stuffed, .LP TS2 not stuffed in odd numbered frames, stuffed at the top bit of TS in even numbered frames, .LP TS3\(hy23 stuffed at the top bit of each time slot, .LP TS24 stuffed at the top bit and bottom bit of the time slot. .LP The stuffing position is shown in Figure 1/H.130. .PP \fINote\fR \ \(em\ When stuffing pulses are inserted, the transmisison bit rate for encoded video is reduced to 1252\ kbit/s without auxiliary data transmission and to 1188\ kbit/s with auxiliary data transmission. .PP In order to ease processing at block boundaries, the C\d1\ubit at the start of any block is assigned to be always as described in \(sc\ 3.3.1 above as shown in Table\ 4/H.130. .bp .PP To prevent 8 consecutive zeros in the codec\(hyto\(hycodec information when stuffing is carried out, the stuffing flag transmitted in the (C\d2\u, C\d7\u) bits are assigned as (1,0) for stuffing and (0,1) for no stuffing. .PP Violations are checked assuming that all transmission framing bits in bit No.\ 0 and stuffing flag bits in\ C\d2\uand\ C\d7\uare zero. .PP \fINote\fR \ \(em\ If audio data are processed in the network, corresponding bits should also be assumed as zero for violation checking. However, as this may increase the probability of stuffing, measures are necessary to prevent such stuffing from becoming excessive. .RT .sp 1P .LP 3.4.3 \fIStuffing mode operation\fR .sp 9p .RT .PP Stuffing should be operated only when necessary. To identify the network restrictions , the bit sequence independence (BSI) in the codec\(hyto\(hycodec information channel is used. A coder usually operates without stuffing, but shifts to the stuffing mode if the received BSI is \*Qone\*U. \v'6p' .RT .sp 2P .LP \fBRecommendation\ H.140\fR .RT .sp 2P .sp 1P .ce 1000 \fBA\ \fBMULTIPOINT\ INTERNATIONAL\ VIDEOCONFERENCE\ SYSTEM\fR .EF '% Fascicle\ III.6\ \(em\ Rec.\ H.140'' .OF '''Fascicle\ III.6\ \(em\ Rec.\ H.140 %' .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP \fB1\fR \fBScope\fR .sp 1P .RT .PP This Recommendation defines a multipoint videoconference system which enables three or more videoconference sites to intercommunicate simultaneously, provided that the codecs conform to Recommendations\ H.120 and\ H.130 (\(sc\ 1, Note). .PP \fINote\fR \ \(em\ Codecs conforming to \(sc 2 of Recommendations\ H.120 and\ H.130 are in principle also applicable. .RT .sp 2P .LP \fB2\fR \fBGeneral requirements\fR .sp 1P .RT .PP A multipoint control unit (MCU) is a piece of equipment located in a node of the network (terrestrial or satellite) which receives several (maximum seven) 2\ Mbit/s channels from access ports (each access port corresponding either to a local or a remote codec, or to another MCU) and, according to a certain criterion, causes some of them called selected channels to be distributed towards the connected studios (see Figure\ 1/H.140). .RT .LP .rs .sp 16P .ad r \fBFigure 1/H.140, p.\fR .sp 1P .RT .ad b .RT .LP .bp .PP The basic functions of the MCU for a terrestrial or a satellite network are identical. The MCU shall have the capability: .LP \(em To synchronise the incoming streams to a single 2048 kHz pilot clock. .LP \(em To extract frame alignment from TS0 in order to synchronise the different streams to the frame clock, to extract frame parity, multiframe and supermultiframe alignment from TS2 in order to access in each incoming stream the codec\(hyto\(hycodec signalling channel. .LP \(em To process this signalling channel. .LP \(em To process the sound channels in order to create an open sound system, in the case of an unencrypted system. .LP \(em To decide image switching and dispatching according to a selection criterion (automatic or on request). .LP \(em To signal in advance the switching decisions to the codecs so that degradation during and after the switching can be avoided. .LP \(em To multiplex the selected video channels with the open sound channel and the effective data channels. .LP \(em To distribute the reconstructed streams to the corresponding access ports. .sp 2P .LP \fB3\fR \fBSynchronisation of bit streams\fR .sp 1P .RT .sp 1P .LP 3.1 \fIClock synchronisation\fR .sp 9p .RT .PP All incoming bit streams to the MCU must be derived from the same basis 2048\ kbit/s clock. If no codec involved in a multipoint conference resides in a synchronous network, i.e.\ no signal is received with bit\ 8 in TS0 of odd frames set to zero, then the MCU acts as a master clock source. Such an MCU should have a reference clock with a short term accuracy of\ 1 in 10\u9\d, in order to avoid frame slips during a conference session. If one or more codecs are in synchronous networks (bit\ 8\ =\ 0), then their clocks are taken as the master. .PP In both cases the MCU sets on all outgoing channels bit 8 in odd TS0's to zero. .RT .sp 1P .LP 3.2 \fIFrame synchronisation\fR .sp 9p .RT .PP The MCU has the following functions: .RT .LP i) Extract from TS0 frame alignment and generate the frame clock. Frame parity should not be extracted from TS0 as it is not transparently transmitted through some networks. .LP ii) Extract from TS2 multiframe and supermultiframe alignment and generate: frame parity, multiframe clock, supermultiframe clock. .LP iii) Synchronise the bit streams at the PCM frame rate, such that switching can be performed without interrupting the Recommendation\ G.704 frame structure. .sp 2P .LP \fB4\fR \fBMCU and codec use of TS2 odd for multipoint conference applications\fR .sp 1P .RT .PP The bits are encoded according to Recommendation\ H.130, (\(sc\ 1). A majority decision of\ 5 out of\ 8 is used to provide resilience to channel errors with respect to the signals in bits\ 3 and\ 4. .RT .PP 4.1 Bits 1, 2, 6, 7 are transparently transmitted by the MCU. .sp 9p .RT .PP 4.2 Bit 8 gives multiframe and supermultiframe alignment and recovery of frame parity. .PP 4.3 Bit 3 is for coding mode identification. .PP Bit 3.1.c indicates the facilities offered by the codec (set to\ 1 if provided) and are fixed for each codec. The MCU should take account of these bits in order to set up a minimum operating mode for all the codecs involved in the conference. For each individual port on the MCU a logical AND is made between the incoming signals from all other ports. The resultant signal is then used as the outgoing signal for that specific port, the rule being that an individual ports facilities bits should not be echoed back. .bp .LP Bit 3.1.0 Graphics (mode 1) Bit 3.1.1 High quality speech Bit 3.1.3 Encryption Bit 3.1.4 System M Bit 3.1.5 Graphics (mode 2) Bit 3.1.6 Spare \(em set to zero .PP .sp 2 \fINote\ 1\fR \ \(em\ MCUs not equipped to mix Recommendation G.722 audio will set bit\ 3.1.1 to zero. .PP \fINote\ 2\fR \ \(em\ The use of bit 3.1.3 for encryption is under study. .RT .LP .sp 2 .LP Bit 3.1.2 \ \ Bit 3.1.7 0 \ \ 0\ \ \ 2 Mbit/s working only 1 \ \ 0\ \ \ 2 Mbit/s and 4 \(mu 384 kbit/s working only 0 \ \ 1\ \ \ 2 Mbit/s and 2 \(mu 384 kbit/s working only 1 \ \ 1\ \ \ 2 Mbit/s and 4, 3, 2 \(mu 384 kbit/s working .PP .sp 2 \fINote\fR \ \(em\ If the bit rate signalled by bits 3.1.2 and 3.1.7 exceeds that available at the codec digital interface, then the meaning of the facilities bits is as follows: .LP \(em with codecs having a 1.5 Mbit/s serial interface .LP 0 0 Never occurs 1 0 Means 4 \(mu 384 kbit/s working only 0 1 Means 2 \(mu 384 kbit/s working only 1 1 Means 4, 3, 2 \(mu 384 kbit/s working only .LP \(em with codecs having a 2 Mbit/s serial interface, but effective rate of 768 kbit/s .LP 0 0 Never occurs 1 0 Never occurs 0 1 Means 2 \(mu 384 kbit/s working only 1 1 Means 2 \(mu 384 kbit/s working only .sp 2 .PP Bits 3.3 (colour transmission) and 3.5 (split\(hyscreen display) are transparently transmitted by the MCU. .sp 1P .LP 4.3.1 \fIBit 3.7\fR \(em\fR \fIFast update request (FUR)\fR .sp 9p .RT .PP When set to 1, the transmitter buffer occupancy is forced to decrease and stabilise to a state of less than 6\ K by preventing coded picture elements entering the buffer. .bp .RT .sp 1P .LP 4.3.2 \fIBit 3.9\fR \(em \fIFreeze frame request (FFR)\fR .sp 9p .RT .PP Used to warn a decoder that its received signal may be interrupted after the start of the next supermultiframe for a period of no more than 2\ s. On receipt of bit\ 3.9 set to\ 1 a decoder will normally \*Qfreeze\*U the contents of its frame store for 2\ s or until a field start code is received with bit\ A set to\ 1 (see Recommendation\ H.120 \(sc\ 1). .PP Both bits 3.7 and 3.9 should pass transparently across an MCU if set on an incoming signal: this is to allow for multipoint conferencing using distributed MCU's. .PP Bit 3.11.c indicates the power of the sound channel, integrated during 16\ ms (period of the supermultiframe) and encoded with 8\ bits. It is only used with encrypted multipoint, otherwise it is set to zero. The MCU can use this bit to select the New and Previous Speaker's channels (see \(sc\ 6). .RT .sp 1P .LP 4.3.3 \fIBit 3.13 \(em Data distribution\fR .sp 9p .RT .PP When a codec received this bit set to one, it must vacate in its transmission channel the same time slots which are vacated with respect to the video signal in its receive channel and which are signalled by bits\ 4.1, 4.3, 4.5,\ 4.7. .PP The MCU uses this bit to ensure data continuity during a conference (see \(sc\ 9). .RT .sp 1P .LP 4.3.4 \fIBit 3.15 \(em Loop detection\fR .sp 9p .RT .PP Bit 3.15 may be used by the MCU to detect whether one of its bidirectional 2\ Mbit/s ports has been externally looped. It is necessary to monitor this condition since instability may result from such a configuration. The definition of bit\ 3.15 is as follows: .PP Codecs set bit 3.15 to 1 in their outgoing paths. MCUs use a number of consecutive bit 3.15s to transmit a serial random bit stream of length\ \fIn\fR , repeatedly. If the received bit sequence is the same as the transmitted random serial sequence then a loop has been detected. It should be noted that the received bit sequence may exhibit a phase delay compared with the transmitted sequence. .PP The details of the random sequence need not be rigidly specified as the sequence is only relevant when an individual MCU is in a looped configuration. However precautions must be taken to avoid false loop detection. This is likely to occur when two or more MCUs are connected together or when the transmission medium is subject to errors. A number of recommendations are given below. .PP The length of the transmitted random sequence \fIn\fR should be sufficiently large to avoid duplication when two or more MCUs are connected together. It is suggested that the total length be in excess of 15\ bits, thus the possibility of duplication is less than\ 1 in\ 65536. The sequence transmission and detection mechanism should be sufficiently resilient to channel errors. This can be achieved in a number of ways, two simple methods are suggested here. .PP First, considering the sequence as a number of individual bits, each bit may be transmitted for 8\ consecutive bit 3.15s. The receiver takes a majority\ 5 from 8\ vote as the received sequence bit. Thus to transmit a single sequence takes 8\ \(mu\ \fIn\fR \ bits. This is similar to the method adopted for bits\ 4\(mu\fIx\fR . .PP Alternatively, as the random sequence is transmitted repetitively, the decision as to whether the port is in the looped state or not is taken only when a number of sequences has been received. .RT .PP 4.4 Bit 4 is for time slot allocation. .sp 9p .RT .PP If the following bits are set to 1: .RT .LP .sp 2 .LP Bit 4.1 TS2 even is not used for video Bit 4.3 TS16 is not used for video Bit 4.5 TS17 is not used for video Bit 4.7 TS18 is not used for video Bit 4.11 Graphics transmission Bit 4.13 Use of error correcting code .bp .PP When a codec receives any of the bits 4.3/5/7 set to one, and bit\ 3.13 is set to\ 1 (see \(sc\ 4.3), it also vacates the corresponding time slots in its transmitted stream and sets to one the corresponding bits\ 4.b in its transmission channel. .PP Bit 4.1 is transmitted transparently by the MCU as the MCU cannot switch half time slots, i.e.\ the MCU takes no action. .PP Bits 4.9 and 4.15 are used for bit rate signalling. .RT .LP .sp 2 .LP Bit 4.9 \ Bit 4.15 0 \ 0\ \ \ 2 Mbit/s operation 1 \ 0\ \ \ 4 \(mu 384 kbit/s 1 \ 1\ \ \ 3 \(mu 384 kbit/s 0 \ 1\ \ \ 2 \(mu 384 kbit/s .LP At 5 \(mu 384 kbit/s Time slots 1\(hy15 and 17\(hy31 active At 4 \(mu 384 kbit/s Time slots 1\(hy15 and 17\(hy25 active At 3 \(mu 384 kbit/s Time slots 1\(hy9\ and 17\(hy25 active At 2 \(mu 384 kbit/s Time slots 1\(hy6\ and 17\(hy22 active .PP The MCU should take account of bits 4.9 and 4.15 in order to set up a minimum operating mode for all the codecs involved in the conference. For each individual port, bits\ 4.9 and\ 4.15 from every other port on the MCU are analysed to determine which is the lowest requested bit rate permitted by the facilities bits\ 3.1.2 and\ 3.1.7. The code for this bit rate is then used as the outgoing signal in bits\ 4.9 and\ 4.15 for that specific port. Again the rule is that an individual port's bit rate facilities bits should not be echoed back. .PP To avoid a lock up situation, the codec should not return its received bits\ 4.9 and\ 4.15 in its transmit path, but should generate them independently. .RT .sp 1P .LP 4.5 Bit 5 carries a 4/kbits message channel .sp 9p .RT .PP This bit is used to convey an asynchronous message channel at 4\ kbit/s for signalling between the room and the MCU or between rooms or between MCUs. .PP The protocol of this message channel is under study. .RT .sp 2P .LP \fB5\fR \fBAudio processing\fR .sp 1P .RT .PP Each terminal connected to an MCU must receive a mix of the audio from all other terminals. The audio signals should be summed at the MCU without normalisation, i.e.\ unity gain on each channel. The introduction of dynamic mixing for the suppression of ambient noise may be included but speakers would still enjoy unity gain. .PP \fINote\fR \ \(em\ Not applicable with encrypted multipoint. .RT .sp 2P .LP \fB6\fR \fBSwitching decision criteria\fR .sp 1P .RT .PP The criteria for switching to some extent depends on the philosophy of the multiconference service in each Administration. Any solution, automatic or manual, can be implemented without altering the basic arrangement of the MCU. .PP The minimum working mode or \*Qautomatic\*U mode is as follows: the MCU, by comparison of the incoming sound channels or, in case of encrypted sound channels, by the means of the sound power bit (bit\ 3.11 in TS2 odd), selects the loudest speaker (called new speaker or NS). A second channel is selected by the MCU, being the previous loudest speaker (called previous speaker or PS). The NS is sent the PS channel and the other rooms are sent the NS channel. This mode is always used when the multiconference is established. Details of the switching criterion with respect to sound levels, hangover time, etc., are under study. .bp .PP Five manual overrides are currently identified: .RT .LP a) The system remains automatic but one location is considered to be the chairman of the conference. Participants are able to transmit a \*Qrequest for the floor\*U to either the chairman or all rooms. At an appropriate time, the chairman orally gives the floor to the requesting conferee who, as he begins to speak, is automatically selected as the NS. .LP b) One location (e.g.\ NS or chairman or VIP) is able to choose the allocation of the second selected channel (normally the PS channel) by transmitting a request to the MCU. .LP c) Each location has the choice between the channels, which can be made available by the MCU connected to that location without affecting the displays of other locations. .LP d) Complete manual chairman control with no voice detection. .LP e) Manual forcing, where one location may force the MCU to regard his port as the NS. .PP This override is known as visualisation forcing. It may be used in one of two cases: .LP i) where a chairman or VIP wishes to be seen without interrruption, .LP ii) where a terminal is using a graphics camera, but is not equipped with a graphics capable codec. .PP Only the \*Qautomatic\*U mode does not require the use of the message channel in bit\ 5. .PP Modes a), b), c), d) imply the use of the message channel and extra control equipment (push\(hybuttons, lights, signalling and data connections to the codec,\ etc.) at the conference room. Mode\ e) normally makes use of the message channel, but an interim solution is available on a National basis (see \(sc\ 8.1). .RT .sp 2P .LP \fB7\fR \fBMCU procedure for source switching\fR .sp 1P .RT .PP Once the switching decision is taken, (either by monitoring the audio levels or by the message channel, the MCU must prepare the connected codecs and operate as following: .RT .LP i) it sends a FFR (bit 3.9) to all the codecs which will be affected by the switch, via the selected transmission channels connected to them. .LP ii) It performs image switching whilst maintaining the basic Recommendation\ G.704 frame structure continuity in the selected channel(s). .LP iii) It waits for at least 32 ms to allow sync recovery in all decoders. .LP iv) It sends a FUR (bit 3.7) to the codec(s) which are about to be used as a new picture source. .LP A FUR or a FFR must be set to one for at least one supermultiframe (SMF), or 256\ frames in the case of non SMF\(hysynchronous MCUs. .LP If the newly selected channels are connected to the MCU via a terrestrial link, the whole operation is likely to take no more than 100\ ms. If it is via a satellite link, switch times of 500\ ms are typical. .sp 2P .LP \fB8\fR \fBProtocols for \*Qwho is seen\*U in a multipoint conference\fR .sp 1P .RT .sp 1P .LP 8.1 \fIAutomatic mode\fR .sp 9p .RT .PP This is described in \(sc\ 6. .PP During automatic operation, it is convenient for the NS and PS to have some local indication that their picture is being transmitted. This facility is known as \*Qvisualisation status\*U or \*Qon\(hyair\*U. .bp .PP When defined, the message channel will have the capability of signalling such information together with many other useful facilities. In the short term, for existing codecs, an alternative means of signalling using TS2 odd bit\ 5 which is currently reserved for the message channel may be used for transmission of the visualisation and forcing bit by those countries who wish to implement such a simplified system. Under these circumstances, in a multiple MCU conference, the inter MCU link should be inhibited from sending the visualisation signal to avoid problems of contention. As a long term solution, the message channel is required to ensure compatibility with audioconferencing (this point is under study). In the mean time, the method of transmission should be bilateral agreement. .RT .sp 1P .LP 8.2 \fIControl using message channel\fR .sp 9p .RT .PP Initialization and addressing procedure including the following items are under study; .RT .LP \(em request for floor, .LP \(em local selection by request to view, .LP \(em chairman control. .sp 2P .LP \fB9\fR \fBTransmission of graphics during multipoint\fR .sp 1P .RT .PP This concerns the use of graphics modes 1 and 2 in the codec, not separate SPTV systems. .RT .sp 1P .LP 9.1 \fIAutomatic mode\fR .sp 9p .RT .PP The general principle is that all participants see the graphics information except the sender who sees the loudest speaker (other than himself). .PP The MCU first needs to establish whether all codecs in the conference have a graphics facility. If both the graphics facilities bits (bits\ 3.1.0 and 3.1.5) in any of the incoming channels to the MCU are set to zero, then the MCU sets both bits to zero in all its outgoing paths. This forces all codecs to use face\(hyto\(hyface type coding for graphics transmission. .PP When the MCU receives the graphics transmission bit set to 1 (bit\ 4.11), then the voice detector is overridden and the originating port (say port\ A) is made the new speaker, and hence transmitted to all other participants. Port\ A is sent the loudest speaker from the remaining ports (in the PS channel). .RT .sp 1P .LP 9.2 \fIManual Mode\fR .sp 9p .RT .PP Under study. .RT .sp 2P .LP \fB10\fR \fBTransmission of data during multipoint\fR .sp 1P .RT .PP If a participant wishes to transmit data to all other terminals then data continuity must be ensured by the simultaneous vacation of the data channels by all codecs. This involves some delay (800\ ms maximum if double satellite hops occur). .PP Time slot 2 even is not used for data distribution so it does not need to be separately switched by the MCU. .RT .sp 1P .LP 10.1 \fIFully automatic mode\fR | i.e. no message channel) .sp 9p .RT .PP The terminal \*QA\*U wishing to broadcast data sets to 1 the relevant bit\ 4 of TS2 for the data channel to be used. The MCU sets bit\ 3.13 to\ 1 in all outgoing streams except\ A and overrides the speaker detection procedure to make \*QA\*U the present speaker. .PP Other terminals on receipt of bit 3.13 and the relevant bit 4 in TS2 set to\ 1, vacate their outgoing equivalent data ports and set the corresponding bit 4's to\ 1. .PP The MCU then allows voice switching by the other ports after 2\ s. When\ A concludes the data transmission it sets its relevant outgoing bit\ 4 in TS2 to zero. The MCU in turn sets bit\ 3.13 to zero. Normal voice switched operation then continues. .RT .sp 1P .LP 10.2 \fIOperation with message channel\fR .sp 9p .RT .PP Under study. .bp .RT .sp 2P .LP \fB11\fR \fBOutline of output from MCU\fR .sp 1P .RT .PP Each location is sent a 2 Mbit/s channel reconstructed from one of the selected video channels, the corresponding TS2 odd with the possible modifications issued from the MCU in bits\ 3 or\ 5, the sound channel resulting of the mixing of the other sound channels and the effective data channels. .RT .sp 2P .LP \fB12\fR \fBMultipoint conference configurations\fR .sp 1P .RT .sp 1P .LP 12.1 \fITerrestrial configuration\fR .sp 9p .RT .PP Figure 1/H.140 shows a terrestrial multiconference using multiple MCU's. Many multiconferences may need only one MCU in a star formation. .RT .sp 1P .LP 12.2 \fIPossible satellite configurations\fR .sp 9p .RT .PP Figure 2/H.140 shows a multiconference where rooms are connected through the same earth station to a single MCU. This situation is similar to that of \(sc\ 12.1 but with a double hop between the rooms\ X and\ Y. .PP Other possibilities for satellite working are currently under study. .RT .LP .rs .sp 15P .ad r \fBFigure 2/H.140, p. 8\fR .sp 1P .RT .ad b .RT .LP .rs .sp 16P .LP .bp .LP \fBMONTAGE:\ \fR PAGE 102 = PAGE BLANCHE .sp 1P .RT .LP .bp