home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-12-12 | 67.3 KB | 3,017 lines
.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' .sp 1P .ce 1000 \v'3P' SECTION\ 3 .ce 0 .sp 1P .ce 1000 \fBINFRASTRUCTURE\ FOR\ AUDIOVISUAL\ SERVICES\fR .ce 0 .sp 1P .sp 2P .LP \fBRecommendation\ H.200\fR .RT .sp 2P .sp 1P .ce 1000 \fBFRAMEWORK\ FOR\ RECOMMENDATIONS\ FOR\ AUDIOVISUAL\ SERVICES\fR .EF '% Fascicle\ III.6\ \(em\ Rec.\ H.200'' .OF '''Fascicle\ III.6\ \(em\ Rec.\ H.200 %' .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP \fB1\fR \fBAudiovisual services\fR .sp 1P .RT .PP A number of services are, or will be, defined in CCITT having as their common characteristic the transmission of speech together with other information reaching the eventual user in visual form. This Recommendation concerns a set of such services which should be treated in a harmonised way; it is convenient to refer to the members of this set as \*Qaudiovisual services\*U (abbreviated to AV services). .RT .sp 2P .LP \fB2\fR \fBHarmonisation of audiovisual services\fR .sp 1P .RT .PP While the various audiovisual services may easily be distinguished in terms of their user\(hyapplication, common methods are used for the transport of signals representing speech, moving or still pictures, and associated controls/indications, and also telematic auxiliary facilities. The standardisation process seeks the greatest possible harmonisation of these common features, confining the distinction to the application layers wherever possible, in order to: .RT .LP a) Maximise the possibilities for intercommunication between terminals intended for different applications; .LP b) Maximise the commonality of hardware and software in the interests of economies of scale. The scope for commonality includes: audio and video input/output parameters, audio and video codecs, the control/indication set, frame structures and multiplexing, call control procedures (including multipoint). .PP The embodiment of this harmonisation policy will be a consistent set of Recommendations, consistent in the sense that all members of the set take into account all other members. .sp 2P .LP \fB3\fR \fBPurpose of this Recommendation\fR .sp 1P .RT .PP The purpose of this Recommendation H.200 is to define the set that shall be consistent. In fulfilling this function it is important to distinguish, at a given time, between Recommendations and draft Recommendations. .bp .PP \fIRecommendations\fR | re members of the set by virtue of their consistency with other adopted members of the set: these are listed in Annex\ A to this Recommendation. It is of course necessary to ensure continued consistency when amendments are introduced. .PP \fIDraft Recommendations\fR | ange from mere titles or outline contents through varying stages of maturity to a stable final draft. As many different intended members of the Recommendation\ H.200 set are developed in parallel to ensure consistency they should be treated as \*Qprovisional\*U members of the set. The list of set members including provisional items does not form part of Recommendation\ H.200, but this Recommendation\ H.200 should be updated in the future to include new members of the set formally adopted. .RT .sp 2P .LP \fB4\fR \fBFramework\fR .sp 1P .RT .PP Recommendations in the H.200 set are arranged in three main sections: .PP \fIService definitions\fR | These specify the service as seen by the user, including basic service, optional enhancements, quality, and intercommunication requirements, together with operational aspects; technical implementation methods are taken into account but not defined herein. .PP \fIInfrastructure\fR | This section includes all the Recommendations which are applicable to two or more distinct services: these encompass network configuration, frame structures, control/indications, communication/intercommunication, and audio/video coding. The \*Qinfrastructure\*U includes this generality of signals which flow on unrestricted digital bearers on established network connections\ \(em\ it does not include the methods of call establishment and control, orchestrated by signals outside these bearers. .PP \fISystems and terminal equipment\fR | This section deals with the technical implementation of specific services: it therefore includes service\(hyspecific equipment for the application layer, and draws upon the infrastructure Recommendations to identify the detailed processes required for the particular service. .PP A \fInetwork aspects\fR | ection is also proposed, to cover those matters which are particular to AV services but, involving out\(hyof\(hyband signals, do not come within the scope of the infrastructure section above. .RT .sp 2P .LP \fB5\fR \fBList of audiovisual services covered\fR .sp 1P .RT .PP The following audiovisual services shall be included in the harmonized set: .RT .LP \(em narrowband videophone (1 and 2 \(mu 64 kbit/s under study); .LP \(em broadband videophone (a teleservice for broadband ISDN); .LP \(em narrowband videoconferencing (\fIn\fR \ \(mu\ 384 kbit/s and\ \fIm\fR \ \(mu\ 64\ kbit/s under study); .LP \(em broadband videoconferencing (a teleservice for broadband ISDN); .LP \(em audiographic teleconferencing; .LP \(em telephony (a degenerate case of an AV service, included for intercommunication purposes); .LP \(em telesurveillance. .PP The following audiovisual services are in the process of being defined, and consideration should be given to their inclusion in the set for either of the reasons given in \(sc\ 2: .LP \(em video mail; .LP \(em videotex (including pictures and sound); .LP \(em video retrieval; .LP \(em high resolution image retrieval; .LP \(em distribution services. .bp .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation H.200) .sp 9p .RT .ce 0 .ce 1000 \fBFramework for Recommendations for audiovisual services\fR .sp 1P .RT .ce 0 .ad r \fICCITT Rec. No.\fR .sp 1P .RT .ad b .RT .sp 2P .LP A.1 \fIService definition\fR .sp 1P .RT .ad r AV100 General Recommendation for AV services F.700\ \ .ad b .RT .LP AV110 Teleconference services F.710\ \ AV111 .LP AV112 .LP AV120 (Videophone services) .ad r AV121 Basic narrow\(hyband videophone service in the ISDN F.721\ \ .ad b .RT .sp 1P .LP A.2 \fIInfrastructure\fR .sp 9p .RT .LP AV200 (General Recommendation for AV service infrastructure) .LP AV210 (Reference network configuration) .LP AV220 (General Recommendation for frame structures) .LP AV221 Frame structure for a 64 kbit/s channel .LP in audiovisual teleservices H.221\ \ AV222 Frame structure for 384\(hy1920 kbit/s channels .ad r audiovisual teleservices H.222\ \ .ad b .RT .LP AV230 (AV system control and indications) .LP AV240 (Principles for communiction between AV terminals) .LP AV241 System aspects for the use of the 7 kHz audio .LP codec within 64 kbit/s G.725\ \ AV242 .LP AV250 (Audio coding) .LP AV251 Narrow\(hyband audio coding at 64 kbit/s G.711\ \ AV252 Wideband audio coding in 64 kbit/s G.722\ \ AV253 .LP AV254 .LP AV260 (Video coding) .LP AV261 \fIn\fR \(mu 384 kbit/s video \fR codec H.261\ \ AV262 .sp 1P .LP A.3 \fISystems and terminal equipment\fR .sp 9p .RT .LP AV300 (General Recommendations for AV systems and terminals) .LP AV310 (Requirements for teleconferencing) .LP AV311 .LP AV312 .LP AV313 (Teleconference protocol) .LP AV320 (Requirements for videophone services) .sp 1P .LP A.4 \fINetwork aspects\fR .sp 9p .RT .LP AV400 .LP AV410 (Reservation systems) .LP AV420 (HLC for use in audiovisual calls) .LP AV430 (Call control command & indication) .LP AV440 (Multipoint call set\(hyup) .bp .PP \fINote\ 1\fR \ \(em\ It is intended to merge the substance of existing Recommendations\ H.100 and\ H.110 into this framework in the next study period. .PP \fINote\ 2\fR \ \(em\ Entries in parentheses are indicative of the purpose of the various positions in the framework. .PP \fINote\ 3\fR \ \(em\ Further Recommendations will be added to the list as they are formally adopted. .RT .sp 2P .LP \fBRecommendation\ H.221\fR .RT .sp 2P .sp 1P .ce 1000 \fBFRAME\ STRUCTURE\ FOR\ A\ 64\ kbit/s\ CHANNEL\ IN\ AUDIOVISUAL | fR \fBTELESERVICES\fR .EF '% Fascicle\ III.6\ \(em\ Rec.\ H.221'' .OF '''Fascicle\ III.6\ \(em\ Rec.\ H.221 %' .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .PP \fBIntroduction\fR .sp 1P .RT .PP The purpose of this Recommendation is to define a frame structure for audiovisual teleservices in a single 64\ kbit/s channel which makes the best use of the characteristics and properties of the audio/video encoding algorithms, of the transmission framing structure and of the existing CCITT Recommendations. It offers several advantages: .RT .LP \(em It takes into account Recommendations such as G.704, X.30/I.461,\ etc. It may allow the use of existing hardware or software. .LP \(em It is simple, economic and flexible. It may be implemented on a simple microprocessor, using well known hardware principles. .LP \(em It is a synchronous procedure. The exact time of a configuration change is the same in the transmitter and the receiver. Configurations can be changed at 20\ ms intervals. .LP \(em It needs no return link, since a configuration is signalled by a repeatedly transmitted codeword. .LP \(em It is very secure in case of transmission errors, since the BAS is protected by a double error correcting code. .LP \(em It allows the control of a higher multiplex configuration, into which the basis 64\ kbit/s channel is inserted (in the case of \fIn\fR \ \(mu\ 64\ kbit/s multimedia services such as videoconference). .LP \(em It can be used to derive octet synchronization in networks where this is not provided by other means. .LP \(em It can be used in multipoint configurations, where no dialogue is needed to negotiate the use of a data channel. .LP \(em It provides a variety of data bit\(hyrates (from 6.25 bit/s up to 64\ kbit/s) to the user. .sp 2P .LP \fB1\fR \fBBasic principle\fR .sp 1P .RT .PP The 64 kbit/s channel is structured into octets transmitted at 8\ kHz. The eighth bit of each octet conveys a subchannel of 8\ kbit/s. This subchannel, called service channel (SC), provides end\(hyto\(hyend signalling and consists of three parts (see Figure\ 1/H.221): .RT .LP \(em \fIFrame alignment signal\fR (FAS): This signal structures the 64\ kbit/s channel into frames of 80\ octets each and multiframes (MF) of 16\ frames each. Each multiframe is divided into eight 2\(hyframe submultiframes (SMF): In addition to framing and multiframing information, control and alarm information may be inserted, as well as error check information to control end\(hyto\(hyend error performance and to check frame alignment validity. The FAS can be used to derive octet timing when it is not provided by the network. .bp .LP \(em \fIBit\(hyrate alloction signal\fR (BAS): This signal allows the transmission of codewords to describe \fIthe capability\fR of a terminal to structure the residual 62.4\ kbit/s capacity in various ways, and to \fIcommand\fR a receiver to demultiplex and make use of the constituent signals in such structures; if other 64\ kbit/s channels are associated, as in the case of\ \fIn\fR \ \(mu\ 64\ kbit/s services (e.g.\ videoconference, videophone), this association may also be defined. .LP \fINote\fR \ \(em\ For some countries having 56 kbit/s channels, the net available bit rates will be 8\ kbit/s less. .LP \(em \fIApplication channel\fR (AC): This channel allows transmission of binary information of the insertion of message type data channel(s) (e.g.\ for telematic information) at up to 6400\ bit/s. A minimum required command and indication channel should be provided and defined as part of the application channel (for further study). The remaining bit rate for the application channel may be added to the sound data or video channel. In this context, compatibility problems among audiovisual services should be considered. .LP .rs .sp 23P .ad r \fBFigure 1/H.221 [T1.221] \ \ (\*`a traiter comme tableau MEP), p.\fR .sp 1P .RT .ad b .RT .PP The remaining 56 kbit/s capacity (with fully reserved application channel), carried in bits 1\ to\ 7 of each octet, may convey a variety of signals within the framework of a multimedia service, under the control of the BAS and possibly the AC. Some examples follow: .LP \(em Voice, encoded at 56 kbit/s using a truncated form of the PCM of Recommendation\ G.711 (A\(hylaw or \(*m\(hylaw). .LP \(em Voice, encoded at 32 kbit/s and data at 24 kbit/s or less. .LP \(em Voice, encoded at 56 kbit/s with a bandwidth 50 to 7000\ Hz (sub\(hyband ADPCM according to Recommendation\ G.722). The coding algorithm is also able to work at 48\ kbit/s. Data can then be dynamically inserted at up to 14.4\ kbit/s. .LP \(em Still pictures coded at 56 kbit/s. .LP \(em Data at 56 kbit/s inside an audiovisual session (e.g.\ file transfer for communicating between personal computers). .LP \(em Sound and video sharing the 56 kbit/s capacity. .bp .sp 2P .LP \fB2\fR \fBFrame alignment\fR .sp 1P .RT .sp 1P .LP \fB 2.1 \fIGeneral\fR .sp 9p .RT .PP An 80\(hyoctet frame length produces an 80\(hybit word in the service channel. These 80\ bits are numbered 1\ to\ 80. Bits 2\(hy8 of the service channel in every even frame contain the frame alignment word (FAW)\ 0011011. These bits are completed by bit\ 2 in the succeeding odd frame to form the complete frame alignment signal (FAS). .PP So a pattern similar to the one in Recommendation\ G.704 is used (see Figure\ 2/H.221). .RT .LP .rs .sp 18P .ad r \fBFigure 2/H.221 [T2.221] \ \ (\*`a traiter comme tableau MEP), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 2.2 \fIMultiframe structure\fR .sp 9p .RT .PP Each multiframe contains 16 consecutive frames numbered 0 to 15 divided into eight submultiframes of 2\ frames each (Figure\ 3/H.221). The multiframe alignment signal is located in bit\ 1 of frames\ 1\(hy3\(hy5\(hy7\(hy9\(hy11 and has the form\ 001011. Bits\ 1 of frames\ 8\(hy10\(hy12\(hy13\(hy14\(hy15 are reserved for future use. Their value is provisionally fixed at\ 0. .PP Bits 1 of frames 0\(hy2\(hy4\(hy6 may be used for a modulo 16 counter to number multiframes in descending order. The least significant bit is transmitted in frame\ 0, and the most significant bit in frame\ 6. The receiver may use the mutiframe numbering to determine the differential delay of separate 64\ kbit/s connections, and to synchronize the received signals. The use of an additional reserved bit in frame\ 8 to turn on and off the counting procedure is for further study. .RT .sp 1P .LP 2.3 \fILoss and recovery of frame alignment\fR .sp 9p .RT .PP Frame alignment is defined to have been lost when three consecutive frame alignment signals have been received with an error. .PP Frame alignment is defined to have been recovered when the following sequence is detected: .RT .LP \(em for the first time, the presence of the correct frame alignment word; .LP \(em the absence of the frame alignment signal in the following frame detected by verifying that bit\ 2 is a\ 1; .LP \(em for the second time, the presence of the correct frame alignment word in the next frame. .PP When the frame alignment is lost, bit 3 (A) of the next odd frame is set to\ 1 in the transmit direction. .PP If frame alignment is achieved, but multiframe alignment cannot be achieved, then frame alignment should be sought at another position. .bp .RT .LP .rs .sp 30P .ad r \fBFigure 3/H.221 [T3.221] \ \ (\*`a traiter comme tableau MEP), p.3\fR .sp 1P .RT .ad b .RT .LP .sp 20 .bp .sp 1P .LP 2.4 \fILoss and recovery of\fR \fImultiframe alignment\fR .sp 9p .RT .PP Multiframe alignment is needed to validate the bit\(hyrate allocation signal (see \(sc\ 3). The criteria for loss and recovery of multiframe alignment described below are provisional. .PP Multiframe alignment is defined to have been lost when three consecutive multiframe alignment signals have been received with an error. It is defined to have recovered when the multiframe alignment signal has been received with no error in the next multiframe. When multiframe alignment is lost, even when an unframed mode is received, bit\ 3 (A) of the next odd frame is set to\ 1 in the transmit direction. It is reset to\ 0 when multiframe alignment is regained again. .RT .sp 1P .LP 2.5 \fIProcedure to recover octet timing from frame alignment\fR .sp 9p .RT .PP When the network does not provide octet timing, the terminal may recover octet timing in the receive direction from bit timing and from the frame alignment. The octet timing in the transmit direction may be derived from the network bit timing and an internal octet timing. .RT .sp 1P .LP 2.5.1 \fIGeneral rule\fR .sp 9p .RT .PP The receive octet timing is normally determined from the FAS position. But at the start of the call and before the frame alignment is gained, the receive octet timing may be taken to be the same as the internal transmit octet timing. As soon as a first frame alignment is gained, the receive octet timing is initialized as the new bit position, but it is not yet validated. It will be validated only when frame alignment is not lost during the next 16\ frames. .RT .sp 1P .LP 2.5.2 \fIParticular cases\fR .sp 9p .RT .LP a) When, at the initiation of a call, the terminal is in a forced reception mode, or when the frame alignment has not yet been gained, the terminal may temporarily use the transmit octet timing. .LP b) When frame alignment is lost after being gained, the receive octet timing should not change until frame alignment is recovered. .LP c) As soon as frame and multiframe alignment have been gained once, the octet timing is considered as valid for the rest of the call, unless frame alignment is lost and a new frame alignment is gained at another bit position. .LP d) When the terminal switches from a framed mode to an unframed mode (by means of the BAS), the octet timing, previously gained, must be kept. .LP e) When a new frame alignment is gained on a new position, different from that previously validated, the receive octet timing is reinitialized to the new position but not yet validated and the previous bit position is stored. If no loss of frame alignment occurs in the next 16\ frames, the new position is validated; otherwise the stored old bit position is reutilized. .sp 1P .LP 2.5.3 \fISearch for frame alignment signal (FAS)\fR .sp 9p .RT .PP Two methods may be used: sequential or parallel. In the sequential method, each of the eight possible bit positions for the FAS is tried. When FAS is lost after being validated, the search must resume starting from the previously validated bit position. In the parallel method, a sliding window, shifting one bit for each bit period, may be used. In that case, when frame alignment is lost, the search must resume starting from the bit position next to the previously validated one. .RT .sp 1P .LP 2.6 \fIDescription of the\fR \fICRC4 procedure\fR .sp 9p .RT .PP In order to provide an end\(hyto\(hyend quality monitoring of the 64\ kbit/s connection, a CRC4 procedure may be used and the four bits\ C1, C2, C3 and\ C4 computed at the source location are inserted in bit positions\ 5 to\ 8 of the odd frames. In addition, bit\ 4 of the odd frames, noted\ E, is used to transmit an indication about the received signal in the opposite direction whether the most recent CRC block has been received with errors or not. .bp .PP When the CRC4 procedure is not used, bit E shall be set to\ 0, and bits\ C1, C2, C3 and\ C4 shall be set to\ 1 by the transmitter. Provisionally, the receiver may disable reporting of CRC errors after receiving eight consecutive CRCs set to all 1s, and it may enable reporting of CRC errors after receiving two consecutive CRCs each containing a 0\ bit. (This method of eanbling and disabling CRC error reporting must be verified and is for further study.) .RT .sp 1P .LP 2.6.1 \fIComputation of the CRC4 bits\fR .sp 9p .RT .PP The CRC4 bits C1, C2, C3 and C4 are computed from the whole 64\ kbit/s channel, for a block made of two frames: one even frame (containing the FAW) followed by one odd frame (not containing the FAW). The CRC4 block size is then 160\ octets, i.e.\ 1280\ bits, and the computation is performed 50\ times per second. .RT .sp 1P .LP 2.6.1.1 \fIMultiplication division process\fR .sp 9p .RT .PP A given C1\(hyC4 word located in block N is the remainder after multiplication by\ \fIx\fR \u4\d and then division (modulo\ 2) by the generator polynominal\ \fIx\fR \uD\dlFBOCAD15\fR 4\ +\ \fIx\fR \ +\ 1 of the polynomial representation of block (N\(em1). .PP When representing contents of a block as a polynominal the first bit in the block should be taken as being the most significant bit. Similarly C1 is defined to be the most significant bit of the remainder and C4 the least significant bit of the remainder. .PP This process can be realized with a four\(hystage register and two exclusive\(hyors. .RT .sp 1P .LP 2.6.1.2 \fIEncoding procedure\fR .sp 9p .RT .LP i) The CRC bit positions in the odd frame are initially set at zero, i.e.\ C1\ =\ C2 = C3 = C4 = 0. .LP ii) The block is then acted upon by the multiplication\(hydivision process referred to above in \(sc\ 2.6.1.1. .LP iii) The remainder resulting from the multiplication\(hydivision process is stored ready for insertion into the respective CRC locations of the next odd frame. .PP \fINote\fR \ \(em\ These CRC bits do not affect the computation of the CRC bits of the next block, since the corresponding locations are set at zero before the computation. .sp 1P .LP 2.6.1.3 \fIDecoding procedure\fR .sp 9p .RT .LP i) A received block is acted upon by the multiplication division process, referred above in \(sc\ 2.6.1.1, after having its CRC bits extracted and replaced by zeros. .LP ii) The remainder resulting from this multiplication\(hydivision process is then stored and subsequently compared on a bit\(hyby\(hybit basis with the CRC bits received in the next block. .LP iii) If the decoded calculated remainder exactly corresponds to the CRC bits sent from the encoder, it is assumed that the checked block is error\(hyfree. .sp 2P .LP 2.6.2 \fIConsequent actions\fR .sp 1P .RT .sp 1P .LP 2.6.2.1 \fIAction on bit E\fR .sp 9p .RT .PP Bit E of block N is set to 1 in the transmitting direction of bits C1\(hyC4 detected in the most recent block in the opposite direction have been found in error (at least one bit in error). In the opposite case, it is at zero. .RT .sp 1P .LP 2.6.2.2 \fIMonitoring for incorrect frame alignment\fR .sp 9p .RT .PP In case of a long simulation of the FAW, the CRC4 information can be used to re\(hyinvite a search for frame alignment. For such a purpose, it is possible to count the number of blocks CRC in error within 2\ s (100\ blocks) and to compare this number with\ 89. If the number of CRC blocks in error is greater than or equal to\ 89, a search for frame alignment should be re\(hyinitiated. .PP These values of 100 and 89 have been chosen in order that: .RT .LP \(em for a random transmission error rate of 10\uD\dlF261\u3\d, the probability of incorrectly re\(hyinitiating a search for frame alignment because of\ 89 or more blocks in error, be less than\ 10\uD\dlF261\u4\d; .LP \(em in case of simulation of frame alignment, the probability of not re\(hyinitiating a search of frame alignment after a 2\ s period be less than 2.5%. .bp .sp 1P .LP 2.6.2.3 \fIMonitoring for error performance\fR .sp 9p .RT .PP The quality of the 64 kbit/s connection can be monitored by counting the number of CRC blocks in error within a period of one second (50\ blocks). For instance, a good evaluation of the proportion of seconds without errors as defined in Recommendation\ G.821 can be provided. .PP For information purposes, the following proportions of CRC block in error can be computed for randomly distributed errors of error rate Pe, as shown in Table\ 1/H.221. .RT .ce \fBH.T. [T4.221]\fR .ce TABLE\ 1/H.221 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(108p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) . Pe 10\uD\dlF261\u3\d 10\uD\dlF261\u4\d 10\uD\dlF261\u5\d 10\uD\dlF261\u6\d 10\uD\dlF261\u7\d _ .T& lw(108p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) . { Proportion of CRC blocks in error } 70% 12% 1.2% 0.12% 0.012% _ .TE .nr PS 9 .RT .ad r \fBTableau 1/H.221 [T4.221], p.\fR .sp 1P .RT .ad b .RT .PP By counting the received E bits, it is possible to monitor the quality of the connection in the opposite direction. .sp 2P .LP \fB3\fR \fBBit\(hyrate allocation signal (BAS)\fR \fBand switching between configurations\fR .sp 1P .RT .PP The bit\(hyrate allocation signal (BAS) occupies bits 9\(hy16 of the service channel in every frame. An eight bit BAS code (b\d0\u, b\d1\u, b\d2\u, b\d3\u, b\d4\u, b\d5\u, b\d6\u, b\d7\u) is complemented by eight error correction bits (p\d0\u, p\d1\u, p\d2\u, p\d3\u, p\d4\u, p\d5\u, p\d6\u, p\d7\u) to implement a (16,8) double error correcting code. This error correcting code is obtained by shortening the (17,9) cyclic code with generator polynomial: \v'6p' .RT .sp 1P .ce 1000 \fIg\fR (\fIx\fR ) = \fIx\fR \u8\d + \fIx\fR \u7\d + \fIx\fR \u6\d + \fIx\fR \u4\d + \fIx\fR \u2\d + \fIx\fR + 1 .ce 0 .sp 1P .LP .sp 1 .PP The error correction bits are calculated as coefficients of the remainder polynomial in the following equation: \v'6p' .sp 1P .ce 1000 \fIp\fR\d0\u\fIx\fR \u7\d + \fIp\fR\d1\u\fIx\fR \u6\d + \fIp\fR\d2\u\fIx\fR \u5\d + \fIp\fR\d3\u\fIx\fR \u4\d + \fIp\fR\d4\u\fIx\fR \u3\d + \fIp\fR\d5\u\fIx\fR \u2\d + \fIp\fR\d6\u\fIx\fR + \fIp\fR\d7\u .ce 0 .sp 1P .ce 1000 = \fIRES\fR \d\fIg\fR (\fIx\fR ) \u [\fIb\fR\d0\u\fIx\fR \u1\d\u5\d + \fIb\fR\d1\u\fIx\fR \u1\d\u4\d + \fIb\fR\d2\u\fIx\fR \u1\d\u3\d + \fIb\fR\d3\u\fIx\fR \u1\d\u2\d + \fIb\fR\d4\u\fIx\fR \u1\d\u1\d + \fIb\fR\d5\u\fIx\fR \u1\d\u0\d + \fIb\fR\d6\u\fIx\fR \u9\d + \fIb\fR\d7\u\fIx\fR \u8\d] .ce 0 .sp 1P .LP .sp 1 where \fIRES\fR \d\fIg\fR (\fIx\fR ) \u [ \fIf\fR (\fIx\fR )] represents the residue obtained by dividing \fIf\fR (\fIx\fR ) by \fIg\fR (\fIx\fR ). .PP The BAS code is sent in the even\(hynumbered frame, while the associated error correction bits are sent in the subsequent odd\(hynumbered frame. Each bit of BAS code or the error correction is transmitted in the order shown in Table\ 2/H.221, to avoid emulation of the frame alignment signal. .ce \fBH.T. [T5.221]\fR .ce TABLE\ 2/H.221 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(54p) | cw(48p) | cw(54p) . Bit position Even frame Odd frame _ .T& cw(54p) | cw(48p) | cw(54p) . \ 9 b 0 P 2 .T& cw(54p) | cw(48p) | cw(54p) . 10 b 3 P 1 .T& cw(54p) | cw(48p) | cw(54p) . 11 b 2 P 0 .T& cw(54p) | cw(48p) | cw(54p) . 12 b 1 P 4 .T& cw(54p) | cw(48p) | cw(54p) . 13 b 5 P 3 .T& cw(54p) | cw(48p) | cw(54p) . 14 b 4 P 5 .T& cw(54p) | cw(48p) | cw(54p) . 15 b 6 P 6 .T& cw(54p) | cw(48p) | cw(54p) . 16 b 7 P 7 _ .TE .nr PS 9 .RT .ad r \fBTableau 2/H.221 [T5.221], p.\fR .sp 1P .RT .ad b .RT .LP .bp .PP The decoded BAS value is valid if: .LP \(em the receiver is in frame and multiframe alignment, and .LP \(em the FAS in the same submultiframe was received with 2 or fewer bits in error. .PP Otherwise, the decoded BAS value is ignored. When the receiver actually loses frame alignment, it should undo any changes caused by the three previously decoded BAS values and revert to the state determined by the fourth previously decoded BAS value. .PP The encoding of BAS is made in accordance with the attribute method. .PP The first three bits (b\d0\u, b\d1\u, b\d2\u) represent the attribute number, which describes the general command or capability, and the next five bits (b\d3\u, b\d4\u, b\d5\u, b\d6\u, b\d7\u) identify the specific command or capability. The following attributes are defined: .RT .LP 000 Audio coding command: values defined in Annex A .LP 001 Transfer rate command: values defined in Annex B .LP 010 Video and other command: values defined in Annex D .LP 011 Data command: values defined in Annex E .LP 100 Terminal capability: values defined in Annex C .PP Annex A defined a number of modes, according to the audio coding type and bit rate. Since a validated value of BAS command code applies to the next submultiframe, a change in configuration can occur every 20\ ms. This applies equally to the use of video and data command BAS, controlling sub\(hymodes of various configurations of the remaining capacity. .PP When the incoming bit A (see \(sc\ 2.3) is set to 1, the distant rceiver is not in multiframe alignment and will not immediately validate a new BAS value. .PP Capability BAS require a response from the distant terminal and should not be sent unnecessarily when the incoming signal is unframed. .PP See Recommendations G.725 for further information on signalling procedures. .RT .sp 2P .LP \fB4\fR \fBApplication channel (AC)\fR .sp 1P .RT .PP It occupies bits 17\(hy80 of the service channel in each frame, providing a user available bit rate of 6.4\ kbit/s. According to the application, different kinds of information may be inserted herein. In particular, information concerning forward error correction or end\(hyto\(hyend encryption which both depend on the application, could take place in the application channel. .PP The AC may be used to convey a message channel conforming to the OSI protocols where appropriate. With this message channel, a transport and a session protocol may be used to control the use of audio and data channels. For example, once the command/response procedure has agreed to open a connection, if necessary, the BAS is used to adjust the capability available for data. .PP Examples for the use of AC are given in Appendix\ I. .RT .sp 2P .LP \fB5\fR \fBAccess to non\(hyaudio information within bits 1\(hy7\fR .sp 1P .RT .PP Use of attribute (000) according to Annex A provides for the static or dynamic allocation of \*Qdata channels\*U of up to 56\ kbit/s capacity; in some applications, it may be desirable to combine the application channel with the data channel in order to have a single user\(hydata path, of capacity up to 62.4\ kbit/s. .PP Unless BAS codes (010), (011) are used to direct otherwise, the \*Qdata channel\*U is treated as a single stream of non\(hyvideo information; in this case access may be realised according to standardised procedures (e.g.\ Recommendations\ I.461, I.462, I.463). Data is transmitted in the order received from the data terminal equipment or data terminal adaptator. .PP In the presence of a non\(hyzero video command BAS (010) the data channel is assigned to moving picture information, except that some part may be subtracted for other data purposes by application of a non\(hyzero data command BAS (011). .bp .RT .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation H.221) .sp 9p .RT .ce 0 .ce 1000 \fBAttribute 000 used for BAS encoding\fR .sp 1P .RT .ce 0 .ce \fBH.T. [T6.221]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(48p) | cw(48p) | cw(132p) . { Attribute Bits b 0 | (hy | 2 } { Attribute value Bits b 3 | (hy | 7 } Meaning _ .T& cw(48p) | cw(48p) | lw(132p) . 000 Audio coding 00000 { Neutralised channel (the 62.4 kbit/s user date are unused) PCM [G.711] (truncated to 7 bits) (Note 1) PCM [G.711] (truncated to 7 bits) (Note 2) } .T& cw(48p) | cw(48p) | lw(132p) . S0010 S0011 { A\(hylaw; data at 0 or 6.4 kbit/s Mode OF \(*m\(hylaw; data at 0 or 6.4 kbit/s Mode OF } .T& cw(48p) | cw(48p) | lw(132p) . S0001 { 32 kbit/s ADPCM data at 24 or 30.4 kbit/s (Note 3) } .T& cw(48p) | cw(48p) | lw(132p) . { 64 kbit/s unframed mode (Note 4) } .T& cw(48p) | cw(48p) | lw(132p) . 00100 \ \ PCM A\(hylaw Mode 0 .T& cw(48p) | cw(48p) | lw(132p) . 00101 \ \ PCM \(*m\(hylaw Mode 0 .T& cw(48p) | cw(48p) | lw(132p) . 00110 { \ \ SB\(hyADPCM [G.722] Mode 1 \ \ SB\(hyADPCM [G.722] (Note 5) } .T& cw(48p) | cw(48p) | lw(132p) . 00111 { \ \ 0 kbit/s; data at 64 kbit/s Mode 10 } .T& cw(48p) | cw(48p) | lw(132p) . { Variable bit\(hyrate audio coding } .T& cw(48p) | cw(48p) | lw(132p) . S1000 { \ \ G.722 56 kbit/s; data at 0 or 6.4 kbit/s Mode 2 } .T& cw(48p) | cw(48p) | lw(132p) . S1001 { \ \ G.722 48 kbit/s; data at 8 or 14.4 kbit/s Mode 3 } .T& cw(48p) | cw(48p) | lw(132p) . S1010 { ?04 \ Reserved for audio coding } .T& cw(48p) | cw(48p) | lw(132p) . . | | ?05\ at bit rates less than .T& cw(48p) | cw(48p) | lw(132p) . S1110 \(rb \ 48 kbit/s (Note 6) .T& cw(48p) | cw(48p) | lw(132p) . S1111 { \ \ 0 kbit/s; data at 56 or 62.4 kbit/s Mode 9 \ \ 0 kbit/s; data at 56 or 62.4 kbit/s (Note 7) } .T& cw(48p) | cw(48p) | lw(132p) . 10000 Free .T& cw(48p) | cw(48p) | lw(132p) . 101xx Free .TE .LP \fINote\ 1\fR \ \(em\ The 8th bit is fixed to 0 in the audio PCM decoder. .LP \fINote\ 2\fR \ \(em\ The S bit set to 1 indicates that the application channel is merged with the data channel to form a single user\(hydata path. The method for merging the two channels is shown in Figure\ A\(hy1/H.221 for the 14.4\ kbit/s case. .LP \fINote\ 3\fR \ \(em\ The coding law and respective place of data and audio in each byte of the 64 kbit/s channel is under study. .LP \fINote\ 4\fR \ \(em\ Attribute values 001xx imply the switching to an unframed mode. In the receive direction, reverting to a framed mode can only be achieved by recovering frame and multiframe alignment, which might take up to 2\ multiframes (i.e.\ 320\ ms). .LP \fINote\ 5\fR \ \(em\ The allocation of bits in each byte of the 64\ kbit/s channel is as follows: .TS box center ; cw(36p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) . Audio bit\(hyrate 1 2 3 4 5 6 7 8 _ 64 kbit/s H H L L L L L L 56 kbit/s H H L L L L L S 48 kbit/s H H L L L L D S .TE .IP S Service channel .IP D Data channel .IP H High band audio .IP B Low band audio .nr PS 9 .RT .ad r \fBTableau [T6.221], p.\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 18P .ad r \fBFigure A\(hy1/H.221 [T7.221] \ \ (\*`a traiter comme tableau MEP), p.\fR .sp 1P .RT .ad b .RT .ce 1000 ANNEX\ B .ce 0 .ce 1000 (to Recommendation H.221) .sp 9p .RT .ce 0 .ce 1000 \fBAttribute 001 used for BAS encoding\fR .sp 1P .RT .ce 0 .ce \fBH.T. [T8.221]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(48p) | cw(48p) | cw(108p) . { Attribute Bits b 0 | (hy | 2 } { Attribute value Bits b 3 | (hy | 7 } Meaning _ .T& cw(48p) | cw(48p) | lw(108p) . 001 Transfert rate 00000 \ \ 64 kbit/s .T& cw(48p) | cw(48p) | lw(108p) . 00001 { \ \ 64 kbit/s (audio) + 64 kbit/s (data/video) } .T& cw(48p) | cw(48p) | lw(108p) . 00010 { \ \ 64 kbit/s (audio) + 64 kbit/s (data/video) treated \ \ as a single 128 kbit/s channel } .T& cw(48p) | cw(48p) | lw(108p) . 01010 { \ 384 kbit/s:\ 64 (audio) + 320 (video) } .T& cw(48p) | cw(48p) | lw(108p) . 01011 { \fB\ 384 kbit/s:\fR \ 64 (audio) + 256 (video) \fB\ 384 kbit/s:\ \fR + 64 (data) } .T& cw(48p) | cw(48p) | lw(108p) . 01100 { \ 768 kbit/s:\ 64 (audio) + 704 (video) } .T& cw(48p) | cw(48p) | lw(108p) . 01101 { \fB\ 768 kbit/s:\fR \ 64 (audio) + 640 (video) \fB\ 768 kbit/s:\ \fR + 64 (data) } .T& cw(48p) | cw(48p) | lw(108p) . 01110 { 1152 kbit/s:\ 64 (audio) + 1088 (video) } .T& cw(48p) | cw(48p) | lw(108p) . 01111 { \fB1152 kbit/s:\fR \ 64 (audio) + 1024 (video) \fB\ 768 kbit/s:\ \fR + 64 (data) } .T& cw(48p) | cw(48p) | lw(108p) . 10000 { 1536 kbit/s:\ 64 (audio) + 1472 (video) } .T& cw(48p) | cw(48p) | lw(108p) . 10001 { \fB1536 kbit/s:\fR \ 64 (audio) + 1408 (video) \fB1536 kbit/s:\ \fR + 64 (data) } .T& cw(48p) | cw(48p) | lw(108p) . 10010 { 1920 kbit/s:\ 64 (audio) + 1856 (video) } .T& cw(48p) | cw(48p) | lw(108p) . 10011 { \fB1920 kbit/s:\fR \ 64 (audio) + 1792 (video) \fB1920 kbit/s:\ \fR + 64 (data) } _ .TE .nr PS 9 .RT .ad r \fBTableau [T8.221], p.\fR .sp 1P .RT .ad b .RT .LP .bp .ce 1000 ANNEX\ C .ce 0 .ce 1000 (to Recommendation H.221) .sp 9p .RT .ce 0 .ce 1000 \fBAttribute 100 used for BAS encoding\fR .sp 1P .RT .ce 0 .ce \fBH.T. [T9.221]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(48p) | cw(48p) | cw(132p) . { Attribute Bits b 0 | (hy | 2 } { Attribute value Bits b 3 | (hy | 7 } Meaning _ .T& cw(48p) | cw(48p) | lw(132p) . 100 00000 \ | eutral (Note 1) .T& cw(48p) | cw(48p) | lw(132p) . Terminal 00001 { \ | .725 Type 0 \(em A\(hylaw (Note 2) } .T& cw(48p) | cw(48p) | lw(132p) . capability 00010 { \ | .725 Type 0 \(em \(*m\(hylaw } .T& cw(48p) | cw(48p) | lw(132p) . 00011 \ | .725 Type 1 \(em G.722 .T& cw(48p) | cw(48p) | lw(132p) . 00100 { \ | .725 Type 2 \(em G.722 + data } .T& cw(48p) | cw(48p) | lw(132p) . 00101 ?04 .T& cw(48p) | cw(48p) | lw(132p) . | | | { ?05\ Reserved for audio capabilities } .T& cw(48p) | cw(48p) | lw(132p) . 00110 \(rb .T& cw(48p) | cw(48p) | lw(132p) . 00111 \ | eserved for national use .T& cw(48p) | cw(48p) | lw(132p) . 01000 { \ | on\(hystandard video capability (Note 3) } .T& cw(48p) | cw(48p) | lw(132p) . 01001 ?04 .T& cw(48p) | cw(48p) | lw(132p) . . | | { ?05\ Reserved for video capabilities } .T& cw(48p) | cw(48p) | lw(132p) . 01110 \(rb .T& cw(48p) | cw(48p) | lw(132p) . 01111 \ | eserved for national use .T& cw(48p) | cw(48p) | lw(132p) . 10000 { \ | on\(hystandard system capability (Note 3) } .T& cw(48p) | cw(48p) | lw(132p) . 10001 { \ | B transfer rate capability (Note 4) } .T& cw(48p) | cw(48p) | lw(132p) . 10010 { \ | B transfer rate capability (Note 4) } .T& cw(48p) | cw(48p) | lw(132p) . 10011 { \ | B transfer rate capability (Note 4) } .T& cw(48p) | cw(48p) | lw(132p) . 10100 { \ | B transfer rate capability (Note 4) } .T& cw(48p) | cw(48p) | lw(132p) . 10101 { \ | B transfer rate capability (Note 4) } .T& cw(48p) | cw(48p) | lw(132p) . 10110 { \ | eserved for transfer rate capability } .T& cw(48p) | cw(48p) | lw(132p) . 10111 \ | eserved for national use .T& cw(48p) | cw(48p) | lw(132p) . 11000 { \ | 00 bit/s data capability (Note 5) } .T& cw(48p) | cw(48p) | lw(132p) . 11001 { \ | 200 bit/s data capability (Note 5) } .T& cw(48p) | cw(48p) | lw(132p) . 11010 { \ | 400 bit/s data capability (Note 5) } .T& cw(48p) | cw(48p) | lw(132p) . 11011 { \ | 800 bit/s data capability (Note 5) } .T& cw(48p) | cw(48p) | lw(132p) . 11100 { \ | 400 bit/s data capability (Note 5) } .T& cw(48p) | cw(48p) | lw(132p) . 11101 { \ | 000 bit/s data capability (Note 5) } .T& cw(48p) | cw(48p) | lw(132p) . 11110 { \ | 600 bit/s data capability (Note 5) } .T& cw(48p) | cw(48p) | lw(132p) . 11111 { \ | 4 | 00 bit/s data capability (Note 5) } .TE .LP \fINote\ 1\fR \ \(em\ The neutral value indicates no change in the current capabilities of the terminal. .LP \fINote\ 2\fR \ \(em\ Types 0, 1 and 2 are defined according to Recommendation G.725 \(sc 2. .LP \(em Type 0 terminal can work in mode 0 (PCM) only. .LP \(em Type 1 terminal preferably works in mode\ 1 (G.722) but is able to work in mode\ 0. .LP \(em Type 2 terminal preferably works in mode 2 (G.722 +\ H.221) but is able to work in modes\ 1 and\ 0. .LP \fINote\ 3\fR \ \(em\ If sent (additional), an improved video algorithm decoding or whole system capability is indicated; it is specified elsewhere. .LP \fINote\ 4\fR \ \(em\ A capability to use several B channels implies the capability to use fewer channels. .LP \fINote\ 5\fR \ \(em\ A data capability specifies only one rate; if multiple rates are possible the capabilities are sent individually. .nr PS 9 .RT .ad r \fBTableau [T9.221], p.\fR .sp 1P .RT .ad b .RT .LP .sp 6 .bp .ce 1000 ANNEX\ D .ce 0 .ce 1000 (to Recommendation H.221) .sp 9p .RT .ce 0 .ce 1000 \fBAttribute 010 used for BAS encoding\fR .sp 1P .RT .ce 0 .ce \fBH.T. [T10.221]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(48p) | cw(48p) | cw(132p) . { Attribute Bits b 0 | (hy | 2 } { Attribute value Bits b 3 | (hy | 7 } Meaning _ .T& cw(48p) | cw(48p) | lw(132p) . 010 00000 No video; video switched OFF .T& cw(48p) | cw(48p) | lw(132p) . Video and other 00001 { Standard video for m \(mu 64 kbit/s } .T& cw(48p) | cw(48p) | lw(132p) . command 00010 { Video ON, using improved algorithm } .T& cw(48p) | cw(48p) | lw(132p) . 00011 { Standard video to Recommendation H.261 } .T& cw(48p) | cw(48p) | lw(132p) . . | | .T& cw(48p) | cw(48p) | lw(132p) . 11111 { Transfer to non\(hystandard system mode } _ .TE .nr PS 9 .RT .ad r \fBTableau [T10.221], p.\fR .sp 1P .RT .ad b .RT .ce 1000 ANNEX\ E .ce 0 .ce 1000 (to Recommendation H.221) .sp 9p .RT .ce 0 .ce 1000 \fBAttribute 011 used for BAS encoding\fR .sp 1P .RT .ce 0 .ce \fBH.T. [T11.221]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(48p) | cw(48p) | cw(132p) . Attribute Bits b 0\(hyb 2 { Attribute value Bits b 3\(hyb 7 } Meaning _ .T& cw(48p) | cw(48p) | lw(132p) . 011 00000 { \ | o data; data switched OFF } .T& cw(48p) | cw(48p) | lw(132p) . Data command 00001 { \ | 00 bit/s in AC assigned to data \ | bit 8 of last three octets in each frame) } .T& cw(48p) | cw(48p) | lw(132p) . 00010 { \ | 200 bit/s in AC assigned to data \ | bit 8 of last 12 octets in each frame) } .T& cw(48p) | cw(48p) | lw(132p) . 00011 { \ | 800 bit/s in AC assigned to data \ | bit 8 of last 48 octets in each frame) } .T& cw(48p) | cw(48p) | lw(132p) . 00100 { \ | 400 bit/s in AC assigned to data (whole of AC) } .T& cw(48p) | cw(48p) | lw(132p) . 00101 { \ | 000 bit/s assigned to data (bit 7) } .T& cw(48p) | cw(48p) | lw(132p) . 00110 { \ | 600 bit/s assigned to data (bit 7 + bit 8 of last 16 octets \ | n each frame) } .T& cw(48p) | cw(48p) | lw(132p) . 00111 { \ | 4.4 kbit/s assigned to data (bit 7 + AC) } .T& cw(48p) | cw(48p) | lw(132p) . . | | .T& cw(48p) | cw(48p) | lw(132p) . 10000 { ?04 \ Reserved for communicating the status } .T& cw(48p) | cw(48p) | lw(132p) . to { ?05\ of the data terminal equipment } .T& cw(48p) | cw(48p) | lw(132p) . 10111 \(rb \ interfaces .T& cw(48p) | cw(48p) | lw(132p) . . | | .T& cw(48p) | cw(48p) | lw(132p) . 11111 \fR { Variable rate data; data switched ON (Note) } .TE .LP \fINote\fR \ \(em\ When video is switched on, the entire variable data capacity is used for video. .nr PS 9 .RT .ad r \fBTableau [T11.221], p.\fR .sp 1P .RT .ad b .RT .LP .bp .ce 1000 APPENDIX\ I .ce 0 .ce 1000 (to Recommendation H.221) .sp 9p .RT .ce 0 .ce 1000 \fBExamples for the use of the application channel\fR .sp 1P .RT .ce 0 .LP I.1 \fIBinary information\fR .sp 1P .RT .PP Each bit of the application channel may be used to convey the information of a 100\ kbit/s channel, repeated 100\ times per second. If odd and even frames are identified, each bit may carry the 150\ Hz bit/s channels. If multiframing is used, each bit may carry the information of 16\ channels, each at 6.25\ bit/s. .PP An example of this kind of information is, in teleconference, the use of a bit to synchronize the encoder clock on the receive clock, or to indicate the microphone number, or to signal the use of the grahics mode,\ etc. .RT .sp 1P .LP I.2 \fISynchronous message\(hytype channel\fR .sp 9p .RT .PP As each bit of the application channel represents a bit\(hyrate of 100\ bit/s, any synchronous channel working at\ \fIn\fR \ \(mu\ 100\ bit/s may be inserted in the application channel. An example is, in videoconference, the message channel at 4\ kbit/s which is used for multipoint management. .PP Another possibility is the insertion of data channels at one of the bit rates defined in Recommendation\ X.1, according to Recommendations\ X.30/I.461: \*QSupport of\ X.21 and\ X.21\fIbis\fR | ased DTEs by an ISDN\*U. The present frame structure is consistent with the Recommendations\ X.30/I.461 frame structure in a double way: .RT .LP \(em it has the same length (80 bits by bearer channel at 8\ kbit/s); .LP \(em it needs 63 bits per frame (17 bits are used for framing information not to be transmitted), which fits into the 64\ bits available in this frame structure. .sp 1P .LP I.3 \fIAsynchronous message\(hytype channel\fR .sp 9p .RT .PP In case of asynchronous terminals, Recommendation\ X.1 bit\(hyrates are relevant, too. The applicable standard is that specified in\ [1]. This standard also uses the same 80\(hybit frame structure as Recommendations\ X.30/I.461 mentioned above. The application channel will therefore allow adoption of this ECMA standard if needed. .RT .sp 1P .LP I.4 \fIError correction and encryption\fR .sp 9p .RT .PP When needed, forward error correction and encryption information may be transmitted in the application channel. The bit\(hyrate and the protocol to be used will depend on the application. .RT .sp 2P .LP \fBReference\fR .sp 1P .RT .LP [1] ECMA\(hyTAxx \fIBit\(hyrate adaption for the support of synchronous and\fR \fIasynchronous terminal equipment using the V\(hySeries interfaces on a PSTN\fR . .sp 2P .LP \fBRecommendation\ H.222\fR .RT .sp 2P .sp 1P .ce 1000 \fBFRAME\ STRUCTURE\ FOR\ 384\(hy1920\ kbit/s\ CHANNELS\ IN | fR \fBAUDIOVISUAL\ TELESERVICES\fR .EF '% Fascicle\ III.6\ \(em\ Rec.\ H.222'' .OF '''Fascicle\ III.6\ \(em\ Rec.\ H.222 %' .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 provides a mechanism to multiplex multimedia signals such as audio, video, data, control and indication,\ etc., for audiovisual teleservices using an\ \fIn\fR \ \(mu\ 384\ kbit/s (\fIn\fR \ =\ 1\(hy5) channel. .RT .sp 2P .LP \fB2\fR \fBBasic structure\fR .sp 1P .RT .PP The multiplex structure is based upon multiple octets transmitted at 8\ kHz as in Recommendation\ I.431. .bp .PP As \fIn\fR \(mu 384 kbit/s channel consists of 6\ \(mu\ \fIn\fR \ time slots of 64\ kbit/s (see Figure\ 1/H.222). The first 64\ kbit/s time slot has a frame structure conforming to Recommendation\ H.221, containing frame alignment signal (FAS), bit rate allocation signal (BAS) and application channel (AC). .RT .LP .rs .sp 30P .ad r \fBFigure 1/H.222, p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP \fB3\fR \fBBAS codes\fR .sp 1P .RT .PP Particular codes for allocating audio, video and data signals in an \fIn\fR \ \(mu\ 384\ kbit/s channel are given in Annex\ B to Recommendation\ H.221 for Attribute \*Q001\*U. .RT .sp 2P .LP \fB4\fR \fBData transmission\fR .sp 1P .RT .PP A 64 kbit/s data channel can be allocated to the fourth time slot in the \fIn\fR \ \(mu\ 384\ kbit/s channel if controlled by the corresponding BAS code. .PP Provision of more than one 64 kbit/s data channels is under study. .RT .sp 2P .LP \fB5\fR \fBBit assignment in application channel\fR .sp 1P .RT .PP Application channel conveys control and indication signals, message channel,\ etc., for audiovisual teleservices using\ \fIn\fR \ \(mu\ 384\ kbit/s transmission. Bit assignment is under study. .bp .RT .sp 2P .LP \fBRecommendation\ H.261\fR .RT .sp 2P .sp 1P .ce 1000 \fBCODEC\ FOR\ AUDIOVISUAL\ SERVICES\ AT\ n\ \(mu\ 384\ kbit/s\fR .EF '% Fascicle\ III.6\ \(em\ Rec.\ H.261'' .OF '''Fascicle\ III.6\ \(em\ Rec.\ H.261 %' .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP The\ CCITT, .sp 1P .RT .sp 1P .LP \fIconsidering\fR .sp 9p .RT .PP (a) that there is significant customer demand for videoconference service; .PP (b) that circuits to meet this demand can be provided by digital transmission using the H\d0\urate or its multiples up to the primary rate; .PP (c) that ISDNs are likely to be available in some countries that provide a switched transmission service at the H\d0\u\ rate; .PP (d) that the existence of different digital hierarchies and different television standards in different parts of the world complicates the problems of specifying coding and transmission standards for international connections; .PP (e) that videophone services are likely to appear using basic ISDN access and that some means of interconnection of videophone and videoconference terminals should be possible; .PP (f ) that Recommendation H.120 for videoconferencing using primary digital group transmission was the first in an evolving series of Recommendations, .sp 1P .LP \fIappreciating\fR .sp 9p .RT .PP that advances are being made in research and development of video coding and bit rate reduction techniques which will lead to further Recommendations for videophone and videoconferencing at multiples of 64\ kbit/s during subsequent Study Periods, so that this may be considered as the second in the evolving series of Recommendations. .sp 1P .LP \fIand noting\fR .sp 9p .RT .PP that it is the basic objective of CCITT to recommend unique solutions for international connections, .sp 1P .LP \fIrecommends\fR .sp 9p .RT .PP that in addition to those codecs complying with Recommendation\ H.120, codecs having signal processing and interface characteristics described below should be used for international videoconference connections. .PP \fINote\ 1\fR \ \(em\ Codecs of this type are also suitable for some television services where full broadcast quality is not required. .PP \fINote\ 2\fR \ \(em\ Equipment for transcoding from and to codecs according to Recommendation\ H.120 is under study. .PP \fINote\ 3\fR \ \(em\ It is recognised that the objective is to provide interworking between\ \fIn\fR \ \(mu\ 384\ kbit/s codecs and\ \fIm\fR \ \(mu\ 64\ kbit/s codecs as defined in the H\(hySeries Recommendations. Interworking will be on the basis of\ \fIm\fR \ \(mu\ 64\ kbit/s, where the values of\ \fIm\fR are under study. .RT .sp 2P .LP \fB1\fR \fBScope\fR .sp 1P .RT .PP This Recommendation describes the coding and decoding methods for audiovisual services at the rates of \fIn\fR \ \(mu\ 384\ kbit/s, where\ \fIn\fR is\ 1 to\ 5. Possible extension of this scope to meet the objective in Note\ 3 above is under study. .RT .sp 2P .LP \fB2\fR \fBBrief specification\fR .sp 1P .RT .PP An outline block diagram of the codec is given in Figure\ 1/H.261. .RT .sp 1P .LP 2.1 \fIVideo input and output\fR .sp 9p .RT .PP To permit a single Recommendation to cover use in and between\ 625 and 525\(hyline regions, pictures are coded in one common intermediate format. The standards of the input and output television signals, which may, for example, be composite or component, analogue or digital and the methods of performing any necessary conversion to and from the intermediate coding format are not subject to recommendation. .bp .RT .LP .rs .sp 26P .ad r \fBFigure 1/H.261, p.13\fR .sp 1P .RT .ad b .RT .sp 1P .LP 2.2 \fIDigital output and input\fR .sp 9p .RT .PP Digital access at the primary rate of 1544 or 2048 kbit/s is with vacated time slots in accordance with Recommendation\ I.431. .PP Interfaces using ISDN basic accesses are under study (see Recommendation\ I.420). .RT .sp 1P .LP 2.3 \fISampling frequency\fR .sp 9p .RT .PP Pictures are sampled at an integer multiple of the video line rate. This sampling clock and the digital network clock are asynchronous. .RT .sp 1P .LP 2.4 \fISource coding algorithm\fR .sp 9p .RT .PP A hybrid of inter\(hypicture prediction to utilize temporal redundancy and transform coding of the remaining signal to reduce spatial redundancy is adopted. The decoder has motion compensation capability, allowing optional incorporation of this technique in the coder. .RT .sp 1P .LP 2.5 \fIAudio channel\fR .sp 9p .RT .PP Audio is coded according to mode 2 of Recommendation G.722. This is combined with control and indication information and conveyed in one 64\ kbit/s time slot which conforms to Recommendation\ H.221. .RT .sp 1P .LP 2.6 \fIData channels\fR .sp 9p .RT .PP Recommendation H.221 permits part of the 64 kbit/s time slot carrying the audio to be used for auxiliary data transmission. .PP Additionally, one of the time slots normally used for video may be reassigned as a 64\ kbit/s data channel. The possibility of further such channels is under study. .bp .RT .sp 1P .LP 2.7 \fISymmetry of transmission\fR .sp 9p .RT .PP The codec may be used for bidirectional or unidirectional audiovisual communication. .RT .sp 1P .LP 2.8 \fIError handling\fR .sp 9p .RT .PP Under study. .RT .sp 1P .LP 2.9 \fIPropagation delay\fR .sp 9p .RT .PP Under study. .RT .sp 1P .LP 2.10 \fIAdditional facilities\fR .sp 9p .RT .PP Under study. .RT .sp 2P .LP \fB3\fR \fBSource coder\fR .sp 1P .RT .sp 1P .LP 3.1 \fISource format\fR .sp 9p .RT .PP The source coder operates on non\(hyinterlaced pictures occurring 30000/1001 (approximately 29.97)\ times per second. The tolerance on picture frequency is \(+- | 0\ ppm. .PP Pictures are coded as luminance and two colour difference components (Y,\ C\dR\uet\ C\dB\u). These components and the codes representing their sampled values are as defined in CCIR Recommendation\ 601. .PP Black = 16 .PP White = 235 .PP Zero colour difference = 128 .PP Peak colour difference = 16 and 240. .PP These values are nominal ones and the coding algorithm functions with input values of\ 0 through to\ 255. .PP For coding, the luminance sampling structure is 288 lines per picture, 352\ pels per line in an orthogonal arrangement. Sampling of each of the two colour difference components is at 144\ lines, 176\ pels per line, orthogonal. Colour difference samples are sited such that their block boundaries coincide with luminance block boundaries as shown in Figure\ 2/H.261. The picture area covered by these numbers of pels and lines has an aspect ratio of\ 4 | | and corresponds to the active portion of the local standard video input. .PP \fINote\fR \ \(em\ The number of pels per line is compatible with sampling the active portions of the luminance and colour difference signals from\ 525 to\ 625\(hyline sources at 6.75 and 3.375\ MHz, respectively. These frequencies have a simple relationship to those in CCIR Recommendation\ 601. .RT .LP .rs .sp 16P .ad r \fBFigure 2/H.261, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 3.2 \fIVideo source coding algorithm\fR .sp 9p .RT .PP The video coding algorithm is shown in generalised form in Figure\ 3/H.261. The main elements are prediction, block transformation, quantization and classification. .RT .LP .rs .sp 30P .ad r \fBFigure 3/H.261, p.\fR .sp 1P .RT .ad b .RT .PP The prediction error (INTER mode) or the input picture (INTRA mode) is subdivided into 8\ pel by 8\ line blocks which are segmented as transmitted or non\(hytransmitted. The criteria for choice of mode and transmitting a block are not subject to recommendation and may be varied dynamically as part of the data rate control strategy. Transmitted blocks are transformed and resulting coefficients are quantized and variable length coded. .sp 1P .LP 3.2.1 \fIPrediction\fR .sp 9p .RT .PP The prediction is inter\(hypicture and may be augmented by motion compensation (\(sc\ 3.2.2) and a spatial filter (\(sc\ 3.2.3). .RT .sp 1P .LP 3.2.2 \fIMotion compensation\fR .sp 9p .RT .PP Motion compensation is optional in the encoder. The decoder will accept one vector for each block of 8\ pels by 8\ lines. The range of permitted vectors is under study. .PP A positive value of the horizontal or vertical component of the motion vector signifies that the prediction is formed from pels in the previous picture which are spatially to the right or below the pels being predicted. .PP Motion vectors are restricted such that all pels referenced by them are within the coded picture area. .bp .RT .sp 1P .LP 3.2.3 \fILoop filter\fR .sp 9p .RT .PP The prediction process may be modified by a two\(hydimensional spatial filter which operates on pels within a predicted block. .PP The filter is separable into one dimensional hironzontal and vertical functions. Both are non\(hyrecursive with coefficients of 1/4, 1/2, 1/4. At block edges, where one of the taps would fall outside the block, the peripheral pel is used for two taps. Full arithmetic precision is retained with rounding to 8\ bit integer values at the 2\(hyD filter output. Values whose fractional part is one half are rounded up. .PP The filter may be switched on or off on a block by block basis. The method of signalling is under study. .RT .sp 1P .LP 3.2.4 \fITransformer\fR .sp 9p .RT .PP Transmitted blocks are coded with a separable 2\(hydimensional discrete cosine transform of size\ 8 by\ 8. The input to the forward transform and output from the inverse transform have 9\ bits. The arithmetic procedures for computing the transforms are under study. .PP \fINote\fR \ \(em\ The output from the forward and input to the inverse are likely to be 12\ bits. .RT .sp 1P .LP 3.2.5 \fIQuantization\fR .sp 9p .RT .PP The number of quantizers, their characteristics and their assignment are under study. .RT .sp 1P .LP 3.2.6 \fIClipping\fR .sp 9p .RT .PP To prevent quantization distortion of transform coefficient amplitudes causing arithmetic overflow in the encoder and decoder loops, clipping functions are inserted. In addition to those in the inverse transform, a clipping function is applied at both encoder and decoder to the reconstructed picture which is formed by summing the prediction and the prediction error as modified by the coding process. This clipper operates on resulting pel values less than\ 0 or greater than\ 255, changing them to\ 0 and\ 255 respectively. .RT .sp 1P .LP 3.3 \fIData rate control\fR .sp 9p .RT .PP Sections where parameters which may be varied to control the rate of generation of coded video data include processing prior to the source coder, the quantizer, block significance criterion and temporal subsampling. The proportions of such measures in the overall control strategy are not subject to recommendation. .PP When invoked, temporal subsampling is performed by discarding complete pictures. Interpolated pictures are not placed in the picture memory. .RT .sp 1P .LP 3.4 \fIForced updating\fR .sp 9p .RT .PP This function is achieved by forcing the use of the INTRA mode of the coding algorithm. The update interval and pattern are under study. .RT .sp 2P .LP \fB4\fR \fBVideo multiplex coder\fR .sp 1P .RT .sp 1P .LP 4.1 \fIData structure\fR .sp 9p .RT .PP \fINote\ 1\fR \ \(em\ Unless specified otherwise, the most significant bit is transmitted first. .PP \fINote\ 2\fR \ \(em\ Unless specified otherwise, bit 1 is transmitted first. .PP \fINote\ 3\fR \ \(em\ Unless specified otherwise, all unused or spare bits are set to\ `1`. .bp .RT .sp 2P .LP 4.2 \fIVideo multiplex arrangement\fR .sp 1P .RT .sp 1P .LP 4.2.1 \fIPicture header\fR .sp 9p .RT .PP The structure of the picture header is shown in Figure\ 4/H.261. Picture headers for dropped pictures are not transmitted. .RT .LP .rs .sp 5P .ad r \fBFigure 4/H.261 [T1.261] \ \ (\*`a traiter comme tableau MEP), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 4.2.1.1 \fIPicture start code (PSC)\fR .sp 9p .RT .PP A unique word of 21 bits which cannot be emulated by error\(hyfree data. Its value is under study. .RT .sp 1P .LP 4.2.1.2 \fITemporal reference (TR)\fR .sp 9p .RT .PP A five bit number derived using modulo\(hy32 counting of pictures at 29.97\ Hz. .RT .sp 1P .LP 4.2.1.3 \fIType information (TYPE1)\fR .sp 9p .RT .PP Information about the complete picture: .RT .LP Bit\ 1 Split screen indicator. `0` off, `1` on. .LP Bit\ 2 Document camera. `0` off, `1` on. .LP Bit\ 3 Freeze picture release. Under study. .LP Bit\ 4 Under study. Possible uses include signalling of the use of motion compensation and the method of switching the loop filter. .LP Bit\ 5 Number of classes. `0` one, `1` four. .LP Bits\ 6\ to\ 12 Under study. .sp 1P .LP 4.2.1.4 \fIExtra insertion information (PEI)\fR .sp 9p .RT .PP Two bits which signal the presence of the following two optional data fields. .RT .sp 1P .LP 4.2.1.5 \fIParity information (PARITY)\fR .sp 9p .RT .PP For optional use and present only if the first PEI bit is set to `1`. Eight parity bits each representing odd parity of the aggregate of the corresponding bit planes of the locally decoded PCM values of\ Y, C\dR\uand C\dB\uin the previous picture period. .RT .sp 1P .LP 4.2.1.6 \fISpare information (PSPARE)\fR .sp 9p .RT .PP Sixteen bits are present when the second PEI bit is set to `1`. The use of these bits is under study. .RT .sp 1P .LP 4.2.2 \fIGroup of blocks header\fR .sp 9p .RT .PP A group of blocks consists of 2k lines of 44 luminance blocks each, k\ lines of 22\ C\dR\ublocks and k\ lines of 22\ C\dB\ublocks. The value of\ k is under study. .PP The structure of the group of blocks header is shown in Figure\ 5/H.261. All GOB headers are transmitted except those in dropped pictures. .RT .LP .rs .sp 5P .ad r \fBFigure 5/H.261 [T2.261] \ \ (\*`a traiter comme tableau MEP), p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 4.2.2.1 \fIGroup of blocks start code (GBSC)\fR .sp 9p .RT .PP A word of 16 bits, 0000 0000 0000 0001. .RT .sp 1P .LP 4.2.2.2 \fIGroup number (GN)\fR .sp 9p .RT .PP An \fIm\fR bit number indicating the vertical position of the group of blocks. The value of \fIm\fR is the smallest integer greater than or equal to log\d2\u(18/k). GN is\ 1 at the top of the picture. .PP \fINote\fR \ \(em\ GBSC plus the following GN is not emulated by error\(hyfree video data. .RT .sp 1P .LP 4.2.2.3 \fIType information (TYPE2)\fR .sp 9p .RT .PP TYPE2 is \fIp\fR bits which give information about all the transmitted blocks in a group of blocks. The value of\ \fIp\fR is under study. .RT .LP Bit\ 1 When set to `1` indicates that all the transmitted blocks in the GOB are coded in INTRA mode and without block addressing data. .LP Bits\ 2\ to\ \fIp\fR Spare, under study. .sp 1P .LP 4.2.2.4 \fIQuantizer information (QUANT1)\fR .sp 9p .RT .PP A \fIj\fR bit code word which indicates the blocks in the group of blocks where QUANT2 code words are present. These blocks, their code words and the value of\ \fIj\fR are under study. .PP Whether QUANT1 is in the GOB header or the picture header is under study. .RT .sp 1P .LP 4.2.2.5 \fIExtra insertion information (GEI)\fR .sp 9p .RT .PP Under study. .RT .sp 1P .LP 4.2.2.6 \fIGroup of blocks global motion vector (GGMV)\fR .sp 9p .RT .PP Under study. .RT .sp 1P .LP 4.2.2.7 \fISpare information (GSPARE)\fR .sp 9p .RT .PP Under study. .RT .sp 1P .LP 4.2.3 \fIBlock data alignment\fR .sp 9p .RT .PP The structure of the data for \fIn\fR transmitted blocks is shown in Figure\ 6/H.261. The values of\ \fIn\fR and the order are under study. Elements are omitted when not required. .RT .LP .rs .sp 5P .ad r \fBFigure 6/H.261 [T3.261] \ \ (\*`a traiter comme tableau MEP), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 4.2.3.1 \fIBlock address (BA)\fR .sp 9p .RT .PP A variable length code word indicating the position of \fIn\fR blocks within a group of blocks. VLC code words using a combination of relative and absolute addressing are under study. .PP The transmission order and addressing of blocks are under study. .PP When bit 1 of TYPE2 is `1`, BA is not included and up to 132k blocks beginning with and continuing in the above transmission order are transmitted before the next GOB header. .bp .RT .sp 1P .LP 4.2.3.2 \fIBlock type information (TYPE3)\fR .sp 9p .RT .PP Variable length code words indicating the types of blocks and which data elements are present. Block types and VLC code words are under study. .RT .sp 1P .LP 4.2.3.3 \fIQuantizer (QUANT2)\fR .sp 9p .RT .PP A code word of up to q bits signifying the table(s) used to quantize transform coefficients. The value of\ q and the code words are under study. QUANT2 is present in the first transmitted block after the position indicated by QUANT1. .RT .sp 1P .LP 4.2.3.4 \fIClassification index (CLASS)\fR .sp 9p .RT .PP CLASS is present if bit 5 of TYPE1 is set to `1` and indicates which of the four available transmission sequence orders is used for luminance block coefficients. If bit\ 5 of TYPE1 is set to `0` then luminance block coefficients are transmitted in the default sequence order. .PP Chrominance block coefficients are transmitted in one sequence order. .PP The CLASS code words and sequence orders are under study. .RT .sp 1P .LP 4.2.3.5 \fIMotion vector data (MVD)\fR .sp 9p .RT .PP Calculation of the vector data is under study. .PP When the vector data is zero, this is signalled by TYPE3 and MVD is not present. .PP When the vector data is non\(hyzero, MVD is present consisting of a variable length code word for the horizontal component followed by a variable length code word for the vertical component. .PP Variable length coding of the vector components is under study. .RT .sp 1P .LP 4.2.3.6 \fITransform coefficients (TCOEFF)\fR .sp 9p .RT .PP The quantized transform coefficients are sequentially transmitted according to the sequence defined by CLASS. The DC component is always first. Coefficients after the last non\(hyzero one are not transmitted. .PP The coding method and tables are under study. .RT .sp 1P .LP 4.2.3.7 \fIEnd of block marker (EOB)\fR .sp 9p .RT .PP Use of and code word for EOB are under study. An EOB without any transform coefficients for a block is allowed. .RT .sp 2P .LP 4.3 \fIMultipoint considerations\fR .sp 1P .RT .sp 1P .LP 4.3.1 \fIFreeze picture request\fR .sp 9p .RT .PP Causes the decoder to freeze its received picture until a picture freeze release signal is received. The transmission method for this control signal is under study. .RT .sp 1P .LP 4.3.2 \fIFast update request\fR .sp 9p .RT .PP Causes the encoder to empty its transmission buffer and encode its next picture in INTRA mode with coding parameters such as to avoid buffer overflow. The transmission method for this control signal is under study. .RT .sp 1P .LP 4.3.3 \fIData continuity\fR .sp 9p .RT .PP The prototocl adopted for ensuring continuity of data channels in a switched multipoint connection is handled by the message channel. Under study. .RT .sp 2P .LP \fB5\fR \fBVide data buffering\fR .sp 1P .RT .PP The size of the transmission buffer at the encoder and its relationship to the transmittion rate are under study. .PP Transmission buffer overflow and underflow are not permitted. Measures to prevent underflow are under study. .bp .RT .sp 2P .LP \fB6\fR \fBTransmission coder\fR .sp 1P .RT .sp 1P .LP 6.1 \fIBit rate\fR .sp 9p .RT .PP The net bit rate including audio and optional data channels is an integer multiple of 384\ kbit/s up to and including 1920\ kbit/s. .PP The source and stability of the encoder output clock are under study. .RT .sp 1P .LP 6.2 \fIVideo clock justification\fR .sp 9p .RT .PP Video clock justification is not provided. .RT .sp 2P .LP 6.3 \fIFrame structure\fR .sp 1P .RT .sp 1P .LP 6.3.1 \fIFrame structure for 384\(hy1920 kbit/s channels\fR .sp 9p .RT .PP The frame structure is defined in Recommendation\ H.222. .RT .sp 1P .LP 6.3.2 \fIBit assignment in application channel\fR .sp 9p .RT .PP Under study. .RT .sp 1P .LP 6.3.3 \fITime slot positioning\fR .sp 9p .RT .PP According to Recommendation I.431. .RT .sp 1P .LP 6.4 \fIAudio coding\fR .sp 9p .RT .PP Recommendation G.722 56/48\ kbit/s audio, 0/8 kbit/s data and 8\ kbit/s service channel in the first time slot. .PP The delay of the encoded audio relative to the encoded video at the channel output is under study. .RT .sp 1P .LP 6.5 \fIData transmission\fR .sp 9p .RT .PP One or more time slots may be allocated as data channels of 64\ kbit/s each. The first channel uses the fourth time slot. .PP Positioning of the other channels, and possible restrictions on availability at lower overall bit rates are under study. The BAS codes used to signal that these data channels are in use are specified in Recommendation\ H.221. .RT .sp 1P .LP 6.6 \fIError handling\fR .sp 9p .RT .PP Under study. .RT .sp 1P .LP 6.7 \fIEncryption\fR .sp 9p .RT .PP Under study. .RT .sp 1P .LP 6.8 \fIBit sequence independence restrictions\fR .sp 9p .RT .PP Under stydy. .RT .sp 1P .LP 6.9 \fINetwork interface\fR .sp 9p .RT .PP Access at the primary rate is with vacated time slots as per Recommendation\ I.431. .PP For 1544 kbit/s interfaces the default H\d0\uchannel is time slots\ 1 to\ 6. .PP For 2048 kbit/s interfaces the default H\d0\uchannel is time slots\ 1\(hy2\(hy3\(hy17\(hy18\(hy19. .PP Interfaces using ISDN basic accesses are under study (see Recommendation\ I.420). .RT .LP .bp 
