C:\WINWORD\CCITTREC.DOT_______________ INTERNATIONAL TELECOMMUNICATION UNION CCITT G.763 THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE GENERAL ASPECTS OF DIGITAL TRANSMISSION SYSTEMS; TERMINAL EQUIPMENTS DIGITAL CIRCUIT MULTIPLICATION EQUIPMENT USING 32 kbit/s ADPCM AND DIGITAL SPEECH INTERPOLATION Recommendation G.763 Geneva, 1991 Printed in Switzerland FOREWORD The CCITT (the International Telegraph and Telephone Consultative Committee) is the per- manent organ of the International Telecommunication Union (ITU). CCITT is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The Plenary Assembly of CCITT which meets every four years, establishes the topics for study and approves Recommendations prepared by its Study Groups. The approval of Rec- ommendations by the members of CCITT between Plenary Assemblies is covered by the pro- cedure laid down in CCITT Resolution No. 2 (Melbourne, 1988). Recommendation G.763 was prepared by Study Group XV and was approved under the Resolution No. 2 procedure on the 14 of December1990. ___________________ CCITT NOTE In this Recommendation, the expression “Administration” is used for conciseness to indicate both a telecommunication Administration and a recognized private operating agency. ãITU1991 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writ- ing from the ITU. PAGE BLANCHE Recommendation G.763 Recommendation G.763 DIGITAL CIRCUIT MULTIPLICATION EQUIPMENT USING 32 kbit/s ADPCM AND DIGITAL SPEECH INTERPOLATION (revised 1990) 1 General 1.1 Scope This Recommendation is intended as an introduction to digital circuit multiplication equip- ment and systems, and as a base document for the specification of digital circuit multiplication equip- ment (DCME) and digital circuit multiplication systems. DCME is utilized as a means of augmenting the capacity of digital transmission systems operating between several ISCs. DCME has all of the following attributes: – digital speech interpolation; – low rate encoding; – dynamic load control arrangement in association with interfacing; – capability to accommodate the following types of bearer service requirements: i) speech, ii) 3.1 kHz audio (data and speech), iii) 64 kbit/s unrestricted (transparent), iv) alternate speech/64 kbit/s unrestricted. The link between two DCMEs is generally one where a highly efficient traffic carrying capa- bility is required, e.g.a long-distance link. Compression is accomplished by active 64 kbit/s trunk channel assignment and ADPCM encoding thereby reducing the nominal transmission channel requirements. This Recommendation applies to digital circuit multiplication equipment telecommunica- tions systems and specifies the following major aspects of DCME system design: a) network interface requirements: – traffic capacities; – trunk and bearer facility interface; – signalling systems; – voice-band data modem support – echo control. b) functional requirements: – operational modes; – system capacity; – overload strategy; – noise level matching; – PCM encoding standards conversion; – time slot interchange; – 64 kbit/s circuit handling; – ADPCM encoders and decoders; – timing and synchronization; – dynamic load control; – maintenance and alarm functions; – facsimile compression (under study); – tandem operation (under study). c) performance criteria of DCME system elements such as: – speech detector; – control channel; – voice-band data detector; – signalling detector; – facsimile compression (under study). This Recommendation specifies these elements to achieve interworking. 1.2 Purpose Speech signals occurring on telecommunications links are generally the product of two-way conversations. It is customary for one talker to pause while the other speaks; thus, an active speech signal is present on each direction of the trunk channel for only a fraction of the available time. In addition, even when only one talker is speaking, pauses occur between utterances, so there are times when the circuit is idle. Measurements show that speech is present on each direction of the trunk channel approximately 30to 40% of the time, averaged over a large number of busy trunks. DCME reduces the transmission capacity needed to handle a multiplicity of telephone trunk channels by exploiting the low average channel activity and by transmitting active speech using ADPCM tech- niques. The DCME provides a nominal 5 : 1 reduction in the transmission capacity required to carry various mixtures of speech, voice-band data and 64kbit/s unrestricted channels. An overload strategy consisting of variable bit rate encoding and dynamic load control techniques is utilized to limit speech clipping. The DCME data detector discriminates between voice-band data and speech in order to assign the voice-band data signal to a bearer channel protected against the formation of overload channels which degrade the voice-band data performance. 1.3 Application This Recommendation is applicable to the design of digital circuit multiplication equipment intended for, but not limited to, use in an international digital circuit. Freedom is permitted in design details which are not covered in this Recommendation. 2 Definitions relating to digital circuit multiplication equipment (DCME) 2.1 digital circuit multiplication equipment (DCME) A general class of equipment which permits concentration of a number of 64 kbit/s PCM encoded input trunk channels on a reduced number of transmission channels (see §2.7). 2.2 digital circuit multiplication system (DCMS) A telecommunications network comprised of two or more DCME terminals where each DCME terminal contains a transmit unit and a receive unit. 2.3 low rate encoding (LRE) A voice-band signal encoding method, e.g. ADPCM, which results in a bit rate less than 64kbit/s, e.g.either 40kbit/s, 32kbit/s, 24kbit/s, or optionally 16kbit/s. Conversion between speech signals encoded in PCM at 64kbit/s and those encoded in ADPCM must be carried out by means of transcoding processes given in RecommendationG.726. 2.4 variable bit rate (VBR) The capability of the encoding algorithm to dynamically switch between either 32 and 24kbit/s or also optionally between 24and 16kbit/s for speech traffic under control of the DCME. 2.5 digital speech interpolation (DSI) A process which, when used in the transmit unit of a DCME, causes a trunk channel (see §2.9) to be connected to a bearer channel (see §2.8) only when activity is actually present on the trunk channel. This, by exploiting the probability of the speech activity factor (see §2.15) of trunk channels being less than1.0, enables the traffic from a number of trunk channels to be concentrated and carried by a lesser number of time shared bearer channels. The signals carried by a bearer channel therefore represent interleaved bursts of speech signals derived from a number of different trunk channels. Note – A process complementary to DSI is required in the receive unit of a DCME, i.e. assignment of the interleaved bursts to their appropriate trunk channels. 2.6 DCME frame A time interval, the beginning of which is identified by a unique word in the control channel. The DCME frame need not coincide with the multi-frames defined in RecommendationG.704. The format specification of the DCME frame includes channel boundaries and bit position significance. 2.7 transmission channel A 64 kbit/s time slot within a DCME frame. 2.8 bearer channel (BC) A bearer channel is a unidirectional, digital, transmission path from the transmit unit of one DCME to the receive unit of a second associated DCME used to carry concentrated traffic between the two DCMEs. Note 1 – A number of bearer channels in each direction of transmission form the both-way link required between two DCMEs. This link may be, for example, a 2048kbit/s system. Note 2 – A bearer channel may have any of the following instantaneous bit rates: either64, 40, 32, 24, or optionally 16kbit/s. 2.9 trunk channel (TC) A unidirectional, digital transmission path (generally short distance) used for carrying traffic and which connects a DCME to other equipment, e.g.an ISC. Two such trunk channels (transmit and receive) are needed by 4wire telephone circuits and constitute a trunk circuit. Note 1 – Signals carried by a trunk channel will be transmitted at a bit rate of 64 kbit/s. Note 2 – A number of trunk channels in each direction of transmission are required between a DCME and, for instance, an ISC. These trunk channels may be carried by a number of 2048or 1544kbit/s systems. 2.10 intermediate trunk (IT) A channel mapping designation which ranges between 1 and 216 which relates each trunk channel to an internal numbering designation used within the DCME for conveying trunk channel to bearer channel connectivity via the control channel (see §2.13). 2.11 assignment message The message specifying the interconnections required between trunk channels and bearer channels. 2.12 assignment map A record, held in a memory of a DCME, of the interconnections required between trunk channels and bearer channels. This record is dynamically updated in real time in accordance with the traffic demands made on the DCME. 2.13 control channel (CC) A unidirectional transmission path from the transmit unit of one DCME to the receive unit of one or more associated DCMEs which is dedicated primarily to carrying channel assignment mes- sages. In addition, the control channel transmits other messages such as idle noise levels, dynamic load control, alarm messages and optionally line signalling information. Note – An alternative name for control channel is assignment channel. 2.14 ensemble activity The ratio of the time active signals and their corresponding hangover time and front end delay occupy the trunk channels to the total measuring time, averaged over the total number of trunk channels included in the measurement. 2.15 speech activity factor The ratio of the time active speech signals with their corresponding hangover time and front end delay occupy a trunk channel to the total measuring time, averaged over the total number of trunk channels carrying speech signals. 2.16 voice-band data ratio The ratio of the number of trunk channels carrying voice-band data signals to the total num- ber of trunk channels averaged over a fixed interval of time. 2.17 64 kbit/s unrestricted digital data ratio The ratio of the number of trunk channels carrying 64 kbit/s unrestricted digital data signals to the total number of trunk channels averaged over a fixed interval of time. 2.18 DCME overload (mode) The condition when the number of input trunk channels instantaneously active carrying speech exceeds the number of 32kbit/s channels available for interpolation. 2.19 overload channels The additional bearer channel capacity which is generated using VBR encoding to minimize or eliminate DSI competitive clipping. 2.20 average bits per sample The average number of encoding bits per sample computed over a given time window for the ensemble of active interpolated bearer channels within a given interpolation pool. Only bearer chan- nels carrying speech are included in this calculation. 2.21 transmission overload The condition when the average bits per sample goes below the value set in accordance with speech quality requirements. 2.22 freeze-out The condition when a trunk channel becomes active and cannot immediately be assigned to a bearer channel, due to lack of available transmission capacity. 2.23 freeze-out fraction (FOF) The ratio of the total time that the individual channels experience the freeze-out condition to the total time of the active intervals and their corresponding hangover times and front end delays, for all trunks over a fixed interval of time. 2.24 interpolation gain (IG) The trunk channel multiplication ratio which is achieved through DSI. The IG is the ratio of the number of trunk channels to the number of DCME bearer channels where the same signal encod- ing rate is used for trunk and bearer channels. The achievable gain depends on the ensemble activity and the system size. 2.25 transcoding gain (TG) The transmission channel multiplication ratio which is achieved through LRE, which effec- tively creates a number of low rate encoded bearer channels which is greater than the number of available transmission channels. When only a transcoding process conforming to the 32kbit/s portion of RecommendationG.726 is used, the TG will equal2. When no transcoding is used the TG will equal1. When overload channels are created the TG will be greater than2. 2.26 DCME gain (DCMG) The trunk channel transmission multiplication ratio, which is achieved through application of DCME, including LRE and DSI. Hence DCMG=TG·IG. 2.27 clique A set of bearer channels which are associated with a set of trunk channels which are indepen- dent in operation and control from other bearer channels. The set of trunk channels is directed to a single destination. Note–An alternative term for clique is bundle. 2.28 multi-clique mode A DCME operational mode in which more than one clique is used when each clique is asso- ciated with a different destination. 2.29 multi-destination mode A DCME operational mode where traffic is exchanged between more than two (2) corre- sponding DCMEs simultaneously and trunk channel traffic is interpolated over a pool of available bearer channels for all destinations having traffic in the pool. The transmit trunk channels are desig- nated to receive trunk channels at corresponding locations. 2.30 silence elimination When voice-band data traffic is recognized on a trunk channel, the DCME sets a long hang- over time to ensure that no clipping will occur in case of half-duplex transmission. In many cases (e.g. facsimile group 3 transmission), the backward direction is mainly used for the transmission of acknowledgements, and the return trunk channel has therefore a very low rate of activity. If the long hangover time was still in operation, there would be a significant waste of bearer capacity. The use of a second hangover time, shorter than the initial one, will allow making the bearer capacity on the backward direction available to the interpolation pool, and is called silence elimina- tion. 3 DCME functions 3.1 General This Recommendation defines DCME which provides circuit multiplication by means of ADPCM and DSI. For operation between Administrations using 2048kbit/s interfaces, the channel side (bearer) interface to/from the DCME shall be based on the 2048kbit/s interface. For operation between Administrations using 2048 kbit/s interfaces and Administrations using 1544kbit/s interfaces, the channel side (bearer) interface to/from the DCME will be based on the 2048kbit/s interface. For operation between Administrations using 1544 kbit/s interfaces, the channel side (bearer) interface to/from the DCME may be based on either the 1544kbit/s or the 2048kbit/s interface dependent on bilateral agreement. There may be operational difficulties with ISC/DCME interworking depending on whether the DCME is type1, where the DCME cannot communicate with the ISC, or type2, where it can, as defined in RecommendationQ.50. 3.2 Purpose The purpose of DCME is to provide maximum effective use of transmission facilities in the digital operating environment, using DSI and LRE techniques. At a minimum, the DCME functions shall include: – interpolation of speech signals (DSI); – transcoding of 64 kbit/s PCM to ADPCM when applicable; – the means to carry the ISDN bearer services given in §1.1: i) speech, ii) 3.1 kHz audio (data and speech), iii) 64 kbit/s unrestricted; – one or more of the following operating modes: i) point-to-point, ii) multi-clique, iii) multi-destination; – speech detection; – voice-band data detection; – facsimile compression (under study); – a means for transmit detection and receive injection of background noise; – the means to accommodate non-interpolated pre-assigned traffic; – a means for interterminal communication (control channel); – a means for exchanging signals with an ISC for purposes of ISDN bearer services involving 64kbit/s unrestricted traffic, DLC, and alarms; – time slot interchange; – the ability to transport the following signalling systems: i) CCITT No. 5, ii) CCITT No. 6 (both analogue and digital versions), iii) CCITT No. 7, iv) R1 (Note 1 of §3.2), v) R2 (Note 1 of §3.2). Note 1 of § 3.2 – CCITT Signalling Systems R1 and R2 may be transported, but each will require its own special interface. It is recommended that the transmission of line signals is performed using special messages in the control channel. The DCME will perform processing on traffic between the trunk interface and bearer inter- face as defined in Table1/G.763 and explained below: a) Speech traffic is ADPCM encoded and subject to DSI. The bit rate of individual bearer channels provided for speech is instantaneously either32, 24, or optionally 16kbit/s dependent on traffic loading. If the optional 16kbit/s overload feature is activated and being used, the bit rate of the bearer channels provided for speech is 24kbit/s or 16kbit/s dependent on traffic loading. b) Voice-band data traffic is initially subject to DSI. Bearer channels provided for traffic recognized as voice-band data are ADPCM encoded at 40kbit/s and are protected against bit reduction and clipping. c) 64 kbit/s unrestricted traffic may be connected on demand to bearer channels transpar- ently (not subjected to DSI and ADPCM) if an out-of-band control system to/from the ISC is provided to identify the relevant trunk channel. d) Alternate speech/64 kbit/s unrestricted traffic may be accommodated subject to the provi- sion of an out-of-band control facility and in-call modification signals from the ISC. e) 64, 40 and 32 kbit/s channels may be pre-assigned for leased line services which are not to be subjected to DSI. Optionally 24kbit/s or 16kbit/s pre-assigned channels may be used for maintenance purposes only. f) CCITT Signalling System No. 5 will be passed transparently through the DCME. CCITT Signalling Systems Nos.6 and7 can be accommodated through 64kbit/s pre- assigned channels. g) If provided with optional user signalling modules (USM), the DCME will convey line signalling information within the control channel. Two USM modules are presently considered, R1USM and R2USM (see Note1 of §3.2 above). Requirements have been defined for an R2USM. The actual circuit multiplication gain achieved will be dependent upon traffic loading, speech activity, the percentage and type of voice-band data (e.g.facsimile traffic), the number of on-demand unrestricted 64kbit/s channels, the number of pre-assigned channels, and the size of the interpolation pools. The total delay associated with the establishment of dynamically assigned ADPCM encoded bearer channels by the transmit DCME shall not exceed 30ms. The total delay associated with the establishment of dynamically assigned ADPCM encoded bearer channels by the receive DCME shall not exceed 15ms. The delay values exclude the effects of Doppler and plesiochronous buffers and exclude the delays associated with the establishment and disestablishment of demand assigned 64kbit/s unrestricted circuits. 4 Operational modes 4.1 General The following modes of operation are described: a) point-to-point; b) multi-clique; c) multi-destination; and d) interoperation. The DCME multiple destination capability for multi-clique and multi-destination modes is summarized in Table2/G.763. 4.1.1 Point-to-point mode See Figure 1/G.763. 4.1.1.1 Point-to-point Using Figure1/G.763 for reference, the transmit side DCME concentrates Ntrunk channels at 64kbit/s into N/G transmission channels. The transmission channels represent a number of time shared variable bit rate (bearer) channels which are grouped into a primary rate multiplex format. At the receive side, the receiving DCME simply demultiplexes the primary-rate format and reconstitutes the Ntrunk channels from the N/G transmission channels. Figure 1/G.763 = 5,5 cm 4.1.2 Multi-clique mode See Figure 2/G.763. 4.1.2.1 Multi-clique mode In this mode the pool of bearer channels is subdivided into two independent pools (cliques) of fixed capacity, each being for an individual destination. While the aggregate bearer bit rates for both the transmit side and the receive side are equal, the DCMG of each clique may be different since this gain is a function of the number of input channels to be routed within each clique. It is desirable to limit the number of cliques within a primary rate bearer to two. Figure2/G.763 indicates one form of this approach in which the primary rate bearer circuit is assumed to be available to each of the DCM nodes, but each node has the capability of preselecting the traffic that is intended for it. The multi- clique mode may be useful to prevent qdu accumulation when DCME terminals are operated in tan- dem. This subject is under study. Figure 2/G.763 = 10 cm 4.1.3 Multi-destination mode See Figure 3/G.763. 4.1.3.1 Multi-destination mode In this mode, the input trunk channels are interpolated over a common pool of bearer chan- nels, regardless of their destination. The input trunk channels are destination pre-assigned so that they may be routed to the appropriate destination in accordance with the control channel messages. This operational mode permits higher DCMG than the multi-clique mode but its usefulness is limited if the DCME is located at the ISC. Figure 3/G.763 = 10 cm 4.1.4 Interoperation DCME with the multi-destination option shall interwork with DCME of the point-to-point option when the multi-destination DCME is configured with a single destination pool. The single des- tination pool shall be used for interworking. DCME with the multi-destination option shall interwork with DCME of the multi-clique option when the multi-destination DCME includes a single destination pool. The single destination pool shall be used for interworking. 4.2 Modes of assignment of channels to the bearer structure 4.2.1 Pre-assignment It shall be possible to pre-assign 64kbit/s trunk channels to 64kbit/s bearer channels in the pool (8bits within the bearer frame). The number of pre-assigned 64kbit/s trunk channels shall be preset under operator control from zero to the maximum number of complete 8bit time slots within the pool in increments of one 64kbit/s channel. It shall be possible to pre-assign 64kbit/s trunk channels to 40kbit/s bearer channels in the pool (5bits within the bearer frame structure). The number of pre-assigned 40kbit/s bearer channels shall be preset under operator control from zero to the maximum determined by the pool size in incre- ments of one 40kbit/s channel. It shall be possible to pre-assign 64kbit/s trunk channels to 32kbit/s bearer channels in the pool (4bits within the bearer frame). The number of pre-assigned 32kbit/s bearer channels shall be preset under operator control from zero to a maximum determined by the pool size in increments of one 32kbit/s channel. As an option it shall be possible to pre-assign 64kbit/s trunk channels to 24kbit/s or 16kbit/ s bearer channels in the pool. Each 24kbit/s or 16kbit/s bearer channel will occupy the most signifi- cant three bits or two bits respectively of a 32kbit/s pre-assigned bearer channel and will be used for maintenance purposes only. The number of pre-assigned 24kbit/s or 16 kbit/s bearer channels shall be preset under operator control from zero to a maximum determined by the pool size in increments of one 32kbit/s bearer channel. 4.2.2 Dynamic assignment The DCME shall be capable of assigning on-demand 64kbit/s unrestricted traffic to 64kbit/s bearer channels in the pool (8bits within each bearer frame) using an out-of-band control facility between the ISC and the DCME for seizure/release of 64kbit/s bearer channels as defined in §5. The provision of the ISC control facility is at the users' option. The transmit and receive assignment pro- cesses are described in §§6, 7 and8. The DCME shall be capable of dynamically assigning voice traffic within 64kbit/s trunk channels to bearer channels at bit rates of32, 24, and optionally 16kbit/s in each pool (4bits, 3bits or 2bits within each bearer frame). The transit and receive assignment processes are described in §§6 and7. The DCME shall be capable of dynamically assigning voice-band data traffic within a 64kbit/s trunk channel to 40kbit/s bearer channels (5bits within each bearer frame). The transmit and receive assignment processes are described in §§6 and7. 5 Interface requirements The DCME shall be interconnected with a local or remote ISC(s) by means of the trunk inter- face equipment and a DCME ISC signalling system. There is a maximum channel capacity of 216 trunk channels as a consequence of fundamental limitations in the assignment message numbering scheme. Therefore, the trunk interface equipment shall be capable of accommodating seven 2048kbit/s primary multiplex streams or nine 1544kbit/s primary multiplex streams. Trunk channels (TCs) are related one-to-one to the intermediate trunks (ITs) by a TC to IT mapping facility within the DCME to permit configuration control of the trunk time slots and to adopt a channel numbering convention for DCME-to-DCME operation. Local ITs are used by the transmit DCME and are identified within the DCME-to-DCME control channel messages. Remote ITs are received in the control channel messages from correspond- ing DCMEs. In the case of interworking between the 1544 kbit/s and 2048 kbit/s hierarchies on the same DCME, it is recommended in RecommendationG.802 that the bearer system be 2048kbit/s. There may be operational difficulties with ISC/DCME interworking depending on whether the DCME is type1, where the DCME cannot communicate with the ISC, or type2, where it can, as defined in RecommendationQ.50. 5.1 Transmission interface: trunk side 5.1.1 Trunk side interface at 2048 kbit/s a) The electrical characteristics shall comply with RecommendationG.703. The test load impedance shall be either 75W unbalanced or 120W balanced depending on the user requirement. b) The frame structure shall comply with RecommendationG.704. c) The encoding law for voice frequency signals shall conform to the A-law system described in RecommendationG.711. 5.1.2 Trunk side interface at 1544 kbit/s a) The electrical characteristics shall comply with RecommendationG.703. The line code adopted shall be either AMI or B8ZS depending on the user selection. b) The frame structure shall comply with RecommendationG.704. The multi-frame size shall be either 24frames or 12frames depending on the user selection. c) The encoding law for voice frequency signals shall conform to the m-law system described in RecommendationG.711. 5.2 Transmission interface: bearer side 5.2.1 Bearer side interface at 2048 kbit/s 5.2.1.1 General For the point-to-point and multi-clique modes, the bearer interface shall consist of one 2048kbit/s interface on the transmit side and one 2048kbit/s interface on the receive side. For the multi-destination mode, the bearer interface shall consist of one 2048kbit/s interface on the transmit side and one to four 2048kbit/s interfaces on the receive side. 5.2.1.2 Electrical characteristics The electrical characteristics shall comply with RecommendationG.703. An optional non- return-to-zero(NRZ) electrical interface may be provided for special applications. The test load impedance shall be either 75W unbalanced or 120W balanced depending on the user requirement. 5.2.1.3 Bearer frame structure The bearer frame structure shall comply with RecommendationG.704. Time slot0 shall be used as recommended inG.704 and time slots 1to31 shall carry control channels and traffic accord- ing to the DCME frame structure. 5.2.2 Bearer side interface at 1544 kbit/s 5.2.2.1 General For the point-to-point and multi-clique modes, the bearer interface shall consist of one 1544kbit/s interface on the transmit side and one 1544kbit/s interface on the receive side. For the multi-destination mode, the bearer interface shall consist of one 1544kbit/s interface on the transmit side and one to four 1544kbit/s interfaces on the receive side. 5.2.2.2 Electrical characteristics The electrical characteristics shall comply with RecommendationG.703. An optional non- return-to-zero (NRZ) electrical interface may be provided for special applications. Due to the compressed nature of the DCME bearer interface and the necessity for 64kbit/s unrestricted channel transmission, robbed-bit zero code suppression (ZCS) line coding techniques are prohibited on the 1544kbit/s bearer channel interface. Only bipolar eight zero substitution (B8ZS) or zero byte time slot interchange (ZBTSI) line coding techniques are permitted. 5.2.2.3 Bearer frame structure The bearer frame structure shall comply with RecommendationG.704. Provisions shall be included in the bearer frame structure to accommodate control channels and traffic according to the DCME frame structure. The 193rd bit shall be used for frame synchronization as recommended in RecommendationG.704. 5.3 Signalling interfaces to switching equipment (ISC) The choice of interface is left for each administration to define within the constraints of their transmission facilities and ISCs. The signalling interface to the switching equipment is dependent on the capability of the ISC and the facilities between the ISC and the DCME (see RecommendationQ.50). 5.3.1 DCME-ISC signalling interface functions The following groups of functions are defined in RecommendationQ.50. 5.3.1.1 Transmission resource management Facilitates the dynamic load control process within the ISC and the DCME concurrently, based on the status of the traffic loading on the DCME system. The requirements for this function are given in §9. 5.3.1.2 Seizure/release of 64kbit/s circuits (see Note) Used in the DCME for the generation of internal assignment and disconnection messages and in the ISCs for the validation of circuit seizure selection/release based on acknowledgement from the DCME. The requirements for this function are given in §8. Note–If the implementation of the ISC does not permit seizure/release of 64kbit/s circuits, the provision of 64kbit/s circuits may be accomplished under bilateral agreement by pre-assignment. 5.3.1.3 Maintenance information Facilitates information exchange between the DCME and the ISCs pertaining to the mainte- nance status. Maintenance status information may be exchanged between the DCME and the ISC. This function may include the transfer of circuit supervision and alarm conditions referred to in §15. The DCME-ISC signalling system consists of one or more control links, a DCME control interface within the ISC and a switching centre interface (SCI) within the DCME. The selection of the DCME-ISC signalling system, including the physical and electrical interface characteristics are at the users' option. To permit this the SCI is defined with minimum functional requirements. Refer to Figure4/G.763. Figure 4/G.763 = 11 cm 5.3.2 External and internal messages/indications The SCI shall process the following external information elements (between the DCME and the ISC) and the following internal messages/indications (within the DCME). Depending on the char- acteristics of the chosen DCME-ISC signalling system, all of the following required external informa- tion elements may not be used. External information element Acronym (Recommendation Q.50) Capacity for speech available SA Capacity for speech not available SNA Capacity for 3.1 kHz data available VDA Capacity for 3.1 kHz data not available VDNA Capacity for 64kbit/s unrestricted UCA available Capacity for 64kbit/s unrestricted UCNA not available Seizure/select 64 kbit/s circuit S64 Seizure/select 64 kbit/s positive S64Ack acknowledged Seizure/select 64kbit/s negative S64NAck acknowledged Release 64 kbit/s circuit R64 Release 64 kbit/s circuit acknowledged R64Ack Circuit out-of-service Out-of-service Circuit back-in-service Back-in-service Internal messages/indications Acronym Activate DLC for voice/voice-band ADVD data traffic De-activate DLC for voice/voice-band DDVD data traffic Activate DLC for 64 kbit/s traffic AD64 De-activate DLC for 64 kbit/s traffic DD64 The interaction of these external information elements with the on-demand 64kbit/s circuit handler (TCH), the dynamic load control (DLC) function and the operations and maintenance func- tion is described in §§8, 9 and15, respectively. The format of all signals and messages is dependent upon the internal DCME design imple- mentation and the chosen signalling interface, and is therefore not specified herein. 5.3.3 Circuit numbering translation The SCI will perform the translation between the internal DCME IT numbering and the trunk channel identification used for the selected DCME ISC signalling system. This translation will be performed for any signalling function that requires individual trunk channels to be identified. 5.3.4 Transmission resource circuit mapping The SCI will perform the mapping between each destination to which internal DLC messages apply and the primary multiplex streams, trunk channels, or time slots (depending on the selected sig- nalling system) to which the associated external information elements apply. This mapping will make use of the TC-IT map information resident in the DCME described in §15.1. 5.4 Man-machine interface The DCME shall contain a system command structure which serves as a menu-driven inter- face between internal functions and the system operator. Typically two V24 ports are necessary to provide operator access to the equipment, one for a display terminal and one for a printer. 5.5 Operations function interface 5.5.1 Trunk side operation at 2048 kbit/s or 1544 kbit/s The utilization of spare bits for monitoring and error protection shall be in accordance with RecommendationsG.704 andG.706. 5.5.2 Bearer side 5.5.2.1 Single destination mode The utilization of spare bits for monitoring and error protection is under study. 5.5.2.2 Multi-clique or multi-destination mode The utilization of spare bits for monitoring and error protection is under study. 5.6 Local alarms interface The DCME must present alarms to the local entity according to the user's requirement. The choice of the physical/electrical interface is to be decided by the individual Administration. In the case of individual voltage-free loop alarms, the categories of alarm in RecommendationG.803 should be included. In the case of a serial alarm interface it is recommended to provide as a minimum the fol- lowing signals: a) initial occurrence of an alarm in the monitored DCME; b) initial occurrence of a clear in the monitored DCME; c) receipt of a data request from the local entity; d) initial system power-on. Note–It is intended to study the inclusion of telecommunications management network (TMN) protocols and interface requirements in future DCME Recommendations. 5.7 External clock interface 5.7.1 DCME working with 2048 kbit/s transmission interfaces The external clock interface shall comply with RecommendationG.703, §10.3. The test load impedance shall be either 75ohms unbalanced or 120ohms balanced depending on the user require- ment. 5.7.2 DCME working with 1544 kbit/s transmission interfaces The timing is normally derived from an incoming digital link at 1544kbit/s complying with RecommendationG.703, §2. Where required an external clock interface may be provided. 5.8 DCME frame structure 5.8.1 2048 kbit/s structure The bearer structure shall be compatible with the format specified in RecommendationG.704. The bearer structure shall contain 32consecutively numbered 8bit time slots, from 0to31. Time slot0 shall be used for frame synchronization and special functions in accor- dance with RecommendationG.704. Time slots1 through31 shall be used to carry the DCME control channel(s) and traffic. The control channels are comprised of a unique word and a control channel message as described in §11. In all figures used to illustrate the bearer frame structure, the left-most bit shall be transmitted first. Sixteen125 msec bearer frames constitute one 2.0ms DCME frame. The DCME frame is not required to be aligned with the multiframes defined in RecommendationG.704. The beginning of the DCME frame is identified by a unique word in the control channel(s). 5.8.2 1544 kbit/s structure The bearer structure shall be compatible with the format specified in RecommendationG.704. Alternatives for 24-frame multiframe structure or 12-frame multiframe structure will be as agreed upon by the users. The bearer structure shall contain a framing bit (F-bit) and 24 consecutively numbered 8bit time slots, from 1to24. The F-bit shall be used in accordance with RecommendationG.704. Time slots1 through24 shall be used to carry the DCME control chan- nel(s) and traffic. The control channel(s) are comprised of a unique word, and a control message as described in §11. In all figures used to illustrate the bearer frame structure the left-most bit shall be transmitted first. Sixteen 125 msec bearer frames constitute one 2.0msec DCME frame. The DCME frame is not required to be aligned with the multiframes defined in RecommendationG.704. The beginning of the DCME frame is identified by a unique word in the control channel(s). 5.9 Bearer BC numbering and use of the bearer frame As shown in Figure5/G.763 for the 2048kbit/s structure and Figure6/G.763 for the 1544kbit/s structure, one or two pools may be formed. Each pool shall contain an integer number of 8-bit time slots. The first 8-bit time slot of the first pool shall be TS1. The last 8-bit time slot of the second pool shall be TS31 (2048kbit/s structure) or TS24(1544kbit/s structure). The upper bound- ary of the first pool and the lower boundary of the second pool shall be independently programmable (pre-set) at 8-bit time slot boundaries (see Note). Each pool will contain an even number of contigu- ous 4-bit time slots. The left-most 4-bit time slot shall carry the control channel as specified in §11. The remaining 4-bit time slots of the pool are bearer channels (BCs) and are used to carry traffic. Note–The entire bearer structure need not be utilized by the pool(s). The unused portion of the bearer will contain an integer number of 8-bit time slots. This flexibility facilitates received pool sorting by a PCM cross-connect. In the case where a bearer structure contains two pools (two control channels), transmit pools shall be mutually DCME frame aligned. Receive pools may not be mutually DCME frame aligned. The normal range BCs of a pool are consecutively numbered from 1 to p, with BC No.1 being the 4-bit slot next to the control channel andp the total number of 4-bit slots in the pool, excluding the control channel. This numbering scheme is shown in Figures5/G.763 and6/G.763. The BC number contained in the assignment message can either be in the range1 through61 (normal BC numbering range) or in the range64 through83 (overload BC numbering range). If the optional 2bit encoding mode is available and enabled, the overload BC numbering range is from 64to124. BCs in the nor- mal range may consist of either8, 5, 4,3, or optionally 2bits. These bits are obtained from bits of the bearer frame as described below. BCs in the overload range may be disconnected or connected. If disconnected, they will not be associated with any bit of the bearer structure. If connected, they may consist of either4, 3, or optionally 2bit channels and will be associated with bits of the bearer frame as discussed later. The criteria for associating the BC contained in the assignment message to bits within the bearer structure are as follows: Figure 5/G.763 = 10,5 cm Figure 6/G.763 = 10,5 cm 5.9.1 8 bit (64 kbit/s) BCs These are used for the assignment of unrestricted 64kbit/s ITs. The BC number in the assign- ment message indicates the bearer BC (even number) which carries the first 4bits (nibble) of the 8 bit sample. The second nibble is carried by the next higher BC. Refer to Figure7/G.763. Figure 7/G.763 = 6,5 cm 5.9.2 5-bit (40 kbit/s) BCs These are used for the assignment of voice-band data ITs. The BC number in the assignment message indicates the bearer which carries the first 4bits of the 5-bit sample. The 5th bit (LSB) is obtained from a different bearer which is independently assigned as a Bit Bank. The Bit Bank consti- tutes a bit pool providing one bit for up to four data channels. The selection of the 5th bit for a data IT is regulated by the DCME processes. Refer to Figure8/G.763. Figure 8/G.763 = 7 cm 5.9.3 Normal range 4-bit BCs These BCs are used for the assignment of bit banks. The BC number in the assignment mes- sage indicates the bearer BC performing the bit bank function. 5.9.4 Normal range 4/3-bit (32/24 kbit/s) BCs These BCs are used for the assignment of voice ITs. The BC number in the assignment mes- sage indicates the bearer BC which carries the IT bits. These can be either three or four depending on whether the bearer BC LSB is used for the creation of an overload BC during high load conditions. Bit stealing will occur randomly for the purpose of voice quality equalization over the ensemble of voice ITs. The bit stealing function is controlled by the DCME processes. Refer to Figure9/G.763. Figure 9/G.763 = 16,5 cm 5.9.5 Overload range 4/3-bit (32/24 kbit/s) BCs These BCs are used, during heavy load conditions, for the assignment of voice ITs. These BCs can be either 3or 4bits as determined by the DCME processes. Changes from 3to 4bit encod- ing (and vice versa) will occur randomly for the purpose of voice quality equalization over the ensem- ble of voice ITs. The BC number in the assignment message has no direct correspondence to any bearer BC. Refer to Figure10/G.763. Figure 10/G.763 = 14,5 cm 5.9.6 Normal and overload range 3/2 bit (24/16 kbit/s) BCs resulting from the optional 3/2 bit over- load procedure If the optional 2 bit ADPCM encoding feature is available and enabled, normal and overload channels may operate in 3/2 bit mode as required by the 3/2bit overload procedure (§6.1.7.2). This procedure parallels the 4/3bit procedure and it is invoked when more overload channels are required than provided by the 4/3 bit procedure. 5.9.7 Pre-assigned BCs It is possible to select certain ITs for a semi-permanent connection to the bearer resources (pre-assigned ITs), therefore bypassing the dynamic assignment function (DAF) of the DCME.64, 40 and 32kbit/s ITs can be pre-assigned. The optional 24kbit/s or 16kbit/s pre-assigned channels intended for maintenance purposes will occupy the most significant 3 or 2bits respectively of the 32kbit/s pre-assigned normal range BCs. The allocation of pre-assigned ITs to portions of the bearer frame is specified by entering the appropriate information into the DCME configuration data (see §6.1). The BC specified in the configuration data indicates the bearer BC carrying the first four bits of the IT. For a 64kbit/s IT, the BC must be even numbered (the use of the next higher BC for this 64kbit/s IT is implied). A sufficient number of Bit Banks must be pre-assigned to provide the 5th bit for the pre-assigned 40kbit/s channels. The bearer BCs carrying 40kbit/s pre-assigned ITs shall be contiguous starting from bearer BCNo.1. The lowest bearer BC numbers shall be used for the Bit Banks required for 40kbit/s pre- assigned ITs, followed by the pre-assigned 40kbit/s BCs. It is recommended that the pre-assigned 32kbit/s ITs (other than bit banks) and the pre- assigned 64kbit/s ITs also utilize the lower portion of the bearer BC numbers. 6 DCME transmit unit The function of the DCME transmit unit structure is to provide connections between the ITs, the ADPCM encoders and the BCs, and to generate assignment messages for correspondent DCMEs. At initialization, the various transmit side functions are loaded with the appropriate configuration data, and pre-assigned ITs are connected to ADPCM encoders and BCs, as required. Each dynami- cally assigned IT is continuously monitored for detection of activity and classification as voice, data or signalling. Active ITs are then dynamically assigned to available BCs (and ADPCM encoders). At the request of the ISC, 64kbit/s IT are assigned to available BCs and kept connected until the ISC releases the circuit. Assignment information is sent to the remote DCME via an assignment message which is generated once during every 2ms DCME frame. The actual connection is implemented three DCME frames following transmission of the message. This delay is necessary in order to provide adequate time for processing the message before the associated ADPCM BC samples arrive at the DCME receive unit. This section specifies those aspects of the DCME transmit side structure which are necessary to accurately define the DCME transmit unit/receive unit interaction. An example of a DCME trans- mit side structure which satisfies the interaction requirements specified in this section is given in AnnexA.1. 6.1 Transmit channel processing function The transmit channel processing (TCP) function examines the input ITs and classifies them according to their signal type and status. Service requests are placed in assignment queues as a conse- quence of IT status and type transitions. The assignment queues are serviced and the associated assignment messages are then generated. In servicing the assignment queues, the ADPCM encoders are directed to operate at various bit rates under the control of the overload channel creation function, the data/speech discriminator and the transparent circuit handler (TCH). The resulting ADPCM sam- ples are dynamically placed in the DCME output bearer frame at specific BC locations under the con- trol of the TCP function. 6.1.1 DCME transmit unit initialization At initialization, the DCME transmit unit channel connectivity map shall be set to a known state (BCs and ITs disconnected) and the TCP parameters shall be loaded. This includes the informa- tion necessary for the allocation of pre-assigned channels and bit banks. The pre-assigned channel allocation (determined by the configuration data) shall be in accordance with the bearer structure requirements (§§5.2 and5.9). 6.1.2 Intermediate trunk classification The intermediate trunk signals must be continually examined to determine their activity and their type (i.e.speech, signalling or data). The activity and type characteristics of the intermediate trunk signals are determined by the activity detector, the data/speech discriminator and the signalling detector. Transitions from one activity/type state to another are used by the input pre-processor func- tion to generate service requests. The intermediate trunk classification process shall classify input signals as specified below. a) Initially, this function shall classify an IT as either pre-assigned, if so designated by the configuration data, or as voice-inactive, if subject to dynamic assignment. b) Whenever a 64 kbit/s assignment request transpreq indication is received from the TCH, the IT shall be classified as transparent and shall remain in this condition until a 64kbit/s disconnection request transprel indication is received from the TCH, in which case the signal classification shall change to voice-inactive. c) If an IT is active and of the voice/signalling type and a data-detect indication is received from the data/speech discriminator, the IT shall be classified as data-active. The same applies to the case of reception of a Rxdata indication from the DCME receive side. The Rxdata indication is generated by the DCME receive unit when an assignment message is received which establishes a voice-band data connection. If an IT is inactive and of the data type and an act indication is received from the activity detector, the IT shall be classified as data-active. d) If an IT is inactive and of the voice/signalling type and a Rxdata indication is received, the IT shall be classified as data-inactive. If an IT is of the data type and the hangover expires, the IT shall be classified as data- inactive. e) If an IT is of the voice/signalling type and the hangover expires, the IT shall be classified as voice-inactive. f) If an IT is inactive and of the voice type and an act indication is received from the activity detector, the IT shall be classified as voice-active. g) If an IT is active and of the data type and a voice-detect indication is received from the data/speech discriminator, the IT shall be classified as voice-active. If an IT is inactive and of the voice type and an act message is received, the IT shall be declared voice-active. h) If an IT is active and of the voice type and a signaldetect indication is received from the signalling detector, the IT shall be classified as signalling-active. If an IT is of the signalling type and an act indication is received, the IT shall be classi- fied as signalling-active. i) If an IT is active and of the data type and a signaldetect indication is received, the IT shall be classified as signalling-active. If an IT is active and of the voice type and a signaldetect indication is received, the IT shall be classified as signalling-active. When activity terminates on an IT classified as voice-active, the voice hangover value shall be used. When activity terminates on an IT classified as signalling-active, the signalling hangover value shall be used. The voice and signalling hangover values shall be in accordance with the hangover masks specified in §12. Provisions shall be provided to maintain channel connectivity between page changes in the forward direction of a facsimile transmission and to release the reverse channel connection between proce- dural signal transmissions so as to achieve a higher return link utilization for facsimile transmissions (this feature is also referred to as silence elimination). The Rxdata indication which is generated by the DCME receive unit upon receiving a voice-band data related assignment message shall be used to initiate a voice-band data connection at the DCME transmit unit. 6.1.3 Input preprocessing The input preprocessing function examines the activity/type state transitions originating from the intermediate trunk classification process and generates assignment service requests which are placed in service request queues. The input preprocessing function shall process the intermediate trunk state transitions as specified below. When a data-inact(IT) indication is received from the intermediate trunk classification pro- cess, the BC connection to this IT shall be checked. If the type of the BC is data or voice, the BC type shall be maintained and the BC shall be placed back into the pool of available BCs. When a voice-inact (IT) indication is received from the intermediate trunk classification pro- cess, the BC connection to this IT shall be checked. If the type of the BC is data or voice, the BC type shall be maintained and the BC shall be placed back into the pool of available BCs. If the BC is in the overload range, a disconnect request shall be stored in the overload disconnect queue. When a Voice(IT) indication is received from the intermediate trunk classification process, the type of the BC connected to this IT shall be checked. If the type of BC is voice, the BC type shall be maintained and no request shall be generated. If the BC type is other than voice, a request shall be stored in the voice assignment queue. When a data(IT) indication is received from the intermediate trunk classification process, the type of the BC connected to this IT shall be checked. If the type of BC is data, the BC type shall be maintained and no request shall be generated. If the BC type is other than data, a request shall be stored in the data assignment queue. When a transp(IT) indication is received from the intermediate trunk classification process, a request shall be stored in the 64kbit/s assignment queue. 6.1.4 Service request implementation The service request implementation function examines the service request queues and gener- ates assignment messages in response to service requests as specified below. The priorities associated with servicing the various queues have not been specified since they are implementation dependent and do not affect the equipment interworking capability. 6.1.4.1 If the optional USM is used, the USM queue shall be addressed in DCME frames 0, n, 2n,etc. (i.e.every nth DCME frame) of the DCME multiframe wheren is a variable which may be selected by the user. For optional R2USM, DCME frames0, 8, 16, 24, 32, 40, 48 and56 of the DCME multiframe shall include 20bits comprising the synchronous part of the CC, which shall be used to convey two IT numbers and their respective line signalling information. Upon servicing the request, the message shall be deleted from the USM queue. The other service request queues shall be addressed in the remaining DCME frames. 6.1.4.2 64 kbit/s disconnect request The request at the top of the 64kbit/s disconnect queue shall be addressed. An assignment shall be generated which disconnects the IT. At implementation, the service request shall be deleted from the 64kbit/s disconnect queue. 6.1.4.3 Overload disconnect request The request at the top of the overload disconnect queue shall be addressed. An assignment shall be generated which disconnects the IT. At implementation, the serviced request shall be deleted from the overload disconnect queue. 6.1.4.4 64 kbit/s assignment request The request at the top of the 64kbit/s assignment queue shall be addressed. The IT for which the request was generated shall be checked to determine whether it is connected or disconnected. If the IT is connected, a count of the usable bits in the pool shall be taken to determine whether enough capacity exists to accommodate the additional bits required. If no capacity exists, an assignment which disconnects the available BC (and the associated IT) shall be generated. If the IT is connected and enough capacity exists to accommodate the additional bits, the BC number of the connected bearer channel (numberk) shall be checked to determine whether it is even or odd. Ifk is even, the next higher BC (number k+1) shall be examined. Ifk is odd, the next lower BC (number k-1) shall be examined. The objective is to allocate the first nibble (containing the MSB) of the 64kbit/s channel to an even numbered normal range BC. If the IT is disconnected, the number of usable bits in the pool shall be counted to determine whether the request can be accommo- dated (8bits are required). If sufficient capacity is available, the IT shall be assigned to the available normal range BC pair. If sufficient capacity is not available, a refresh message shall be generated in accordance with §6.1.5. If the assignment of a 64kbit/s channel requires that existing ITs be reassigned to different BCs in order to make room in the DCME bearer frame for the 64kbit/s BC, then the reassignments shall be done with highest assignment priority and in an orderly manner so that the connections between assigned ADPCM encoders and ADPCM decoders are not broken. At implementation, the service request shall be deleted from the 64kbit/s assignment queue. 6.1.4.5 Data request 5 bit encoding is required for the transmission of a data channel. Four bits are obtained by assigning the data IT to a 4bit BC in the normal BC range. The fifth bit (LSB) is obtained from a pool of four bits referred to as the bit bank. Special 4bit BC channels of the bank type are created in the bearer frame for this purpose. The criteria for creation of bank channels are specified in Table3/ G.763. The request at the top of the data assignment queue shall be addressed. First, it shall be deter- mined whether a new bit bank is required. Then, the IT for which the request was generated shall be checked to determine whether it is connected to a BC. If the IT is connected, a bit count shall be made to determine whether enough bearer capacity exists for the allocation of the data IT (including the creation of an additional bank channel if required). If sufficient capacity exists and a new bit bank is not required, an assignment of the data IT to the connected BC shall be made. If a bit bank is required, an assignment message connecting the selected BC to IT No.250 shall be generated. At the next DCME frame, the data IT shall be assigned to the connected BC. If sufficient capacity is not available and the IT is connected, a disconnect message shall be generated. If the IT is disconnected, a count of the usable bits in the pool shall be made to determine whether enough capacity exists to allocate the data call. If sufficient capacity is not available, a refreshment message shall be generated in accordance with §6.1.5. If sufficient capacity is available and a new bit bank is not required, the data IT shall be assigned to an available BC. If the bit bank is required, it shall be assigned first, and then the data IT shall be assigned to an available BC. If the assignment of a voice-band data channel required that existing ITs be reassigned to different BCs in order to make room in the DCME bearer frame for the 40kbit/s BC, then the reassignments shall be done with highest assignment priority and in an orderly manner so that the connections between assigned ADPCM encoders and ADPCM decoders are not broken. At implementation, the service request shall be deleted from the data assignment queue. 6.1.4.6 Voice request The request at the top of the voice assignment queue shall be addressed. The IT for which the request was generated shall be checked to determine whether it is connected to a BC. If connected and the BC type is available, the IT shall be assigned to the available BC. If the IT is disconnected, the usable bits in the pool shall be counted to determine whether enough capacity exists to accommodate the voice call. If sufficient capacity does not exist, a refresh- ment message shall be generated in accordance with §6.1.5. If sufficient capacity exists, the voice IT shall be assigned to an available BC. At implementation, the service request shall be deleted from the voice assignment queue. 6.1.5 Refreshment message generation In DCME frames when the USM queue is not to be addressed and there are no messages in the remaining queues, a refreshment message shall be generated. A refreshment message shall also be generated when a service request queue cannot be serviced due to unavailable bearer capacity unless a disconnect message is generated. The refreshment shall be done by scanning the range of normal BCs (from BC No.1 to the upper pool boundary) and the range of overload BCs (from BCNo.64 to the highest number permit- ted). Pre-assigned BCs shall not be refreshed. Each dynamically assigned 64kbit/s connection shall be refreshed but only limited to the even numbered BC (the next higher BC shall not be refreshed). Every other refreshment message shall alternate between the normal and the overload BC range. In each range, the BCs shall be refreshed sequentially from the lowest to the highest BC, restarting the cycle after refreshment of the highest BC in the range. Whenever a BC is refreshed, all the required information elements shall be inserted in the assignment message. The refreshment of a bit bank BC shall be transmitted with IT No.250. 6.1.6 ADPCM encoder control Whenever a new assignment of a previously disconnected IT is made, an ADPCM encoder shall be selected from the available encoders of the encoder pool. Whenever a reassignment of a pre- viously connected IT is made, the ADPCM encoder currently associated with the IT shall be main- tained. Whenever an IT is disconnected, the associated ADPCM encoder shall be returned to the pool of available ADPCM encoders. Resetting of the ADPCM encoder shall be done when the IT connection to an ADPCM encoder is changed. The ADPCM encoder shall be reset before establishing a new connection. 6.1.7 Bit bank handling and overload channel creation Inherent to the TCP function are the bit bank handling and the overload channel creation pro- cesses. The bit bank handling process derives the LSB of each data channel from one of the existing bit banks according to predetermined rules. When the overload mode is required, the overload channel creation process distributes the 3 bit encoding across the entire set of speech channels. The objective is to make the average encoding rate almost equal for the normal voice BC (subject to bit stealing) and the overload channels. This is achieved by stealing bits from eligible BCs in a pseudo-random fashion and by making each overload BC alternate between 3bit and 4bit encoding (also in pseudo-random fashion). When the 4/3 bit overload channel creation procedure, described above, cannot provide the required number of overload channels, the optional 3/2bit overload channel creation procedure may be used. This procedure, similarly to the 4/3bit procedure, makes the average encoding rate almost equal for the normal voice BCs (subject to bit stealing) and the overload channels. Pseudo-random bit rotation and switching between two alternate overload channel sizes (3bit and 2bit channels) are also used in this case. 6.1.7.1 Bit bank handling process The bit bank handling process maintains two lists of BCs which are used in allocating the LSB of each data channel. All lists contain, in ascending order, the BC numbers that fall into the cat- egories defined below. BCs are extracted from, or inserted into, these lists always keeping the BC numbers in ascending order. A BC can appear only in one list at the same instant. Data list – This list contains all BC numbers which are connected to data channels. At initial- ization this list contains no entries. Bit bank list – This list contains all BC numbers which are currently being used to form bit banks. At initialization, this list contains no entries. Pre-assigned 40 list – This list contains all BC numbers that are pre-assigned as 40 kbit/s channels. At initialization, this list contains no entries. A bit bank BC number shall be placed into the bank list at the generation of an assignment message containing IT No.250, if the associated BC number does not already exist in the bit bank list. The BC number in question shall be removed from the voice list when this occurs. A bit bank BC number is removed from the bank list when the bit bank BC is no longer needed. The bit bank deletion shall be in accordance with the criterion specified in Table3/G.763. When the conditions for the deletion of a bit bank exist, the highest numbered bit bank BC shall be deleted. The BC number shall then be put back into the voice list. The bit position of the LSBs of the handled data channels (pre-assigned 40 or dynamically assigned channels declared as data) shall be assigned in the following way: a) LSB of BC number in pre-assigned 40 list position 1: MSB of BC number in bank list posi- tion 1; b) LSBs of BC numbers in pre-assigned 40 list positions 2 to 4: second, third and fourth bits, respectively, at BC number in bank list position1; c) LSB of BC number in pre-assigned 40 list position 5: MSB of BC number in bank list position2. This procedure is followed until the BC numbers in the pre-assigned 40list have been handled, after which the BC numbers in the data list are handled in the same manner. 6.1.7.2 Overload channel creation process The overload channel creation process maintains two lists of BCs which are used in forming overload channels. All lists contain, in ascending order, the BC numbers that fall into the categories defined below. BCs are extracted from, or inserted into, these lists always keeping the BC numbers in ascending order. A BC can appear only in one list at the same instant. Voice list – This list contains all BC numbers that are within the normal BC range and can contribute bits for the creation of overload channels. At initialization, this list contains all normal BC numbers subject to DSI. Overload list – This list contains all BC numbers that are within the overload BC range. At initialization, this list contains no entries. When an assignment message is generated, the voice list or overload list is updated and the list lengths Nv (voice list) and Nov (overload list) are computed. If Nov is0, overload channel cre- ation is not required. 6.1.7.2.1 4/3 bit overload channel creation procedure If Nov is greater than 0, but not greater than Nv/3 the number (N4) of channels in the over- load range that will be carried at four bits per sample shall be computed as follows: In addition, when Nov is greater than 0, the integer variables Pv and Pov shall be computed as follows: Pv = (IT modulo Nv) Pov = (IT modulo Nov) where, IT is the IT number contained in the assignment message (see note). Pv and Pov represent voice and overload list positions. These positions are numbered from 0to Nv-1 and from 0to Nov- 1, respectively. Note–If an optional USM is being used, the IT number information in DCME frames 0, n, 2n,etc. (i.e.every nth DCME frame) of the DCME multiframe shall also be used to create overload channels. The BCs stored in the overload list at the first N4 locations (modulo Nov) starting from the list posi- tion Pov shall be marked as 4bit channels. The remaining BCs of the overload list shall be marked as 3bit channels. The 4/3 bit mode of the first BC in the overload list shall be checked to determine whether the 3bit or 4bit mode is used. If the mode is 3bit, the BCs stored in the voice list at the first three locations, starting from the list position, Pv, shall be set to 3bit mode. The following bit associations shall be entered into the BC bit map: a) MSB of BC in overload list position 0: LSB of BC in voice list position Pv; b) second bit of BC in overload list position 0: LSB of BC in voice list position (Pv+1 mod- ulo Nv); c) LSB of BC in overload list position 0: LSB of BC in voice list position (Pv+2 modulo Nv). If the first BC in the overload list is a 4 bit channel, items a) and b) above remain applicable, c) changes andd) is added as shown below: c) third bit of BC in overload position 0: LSB of BC in voice list position (Pv+2 modulo Nv); d) LSB of BC in overload list position: LSB of BC in voice list position (Pv+3 modulo Nv). The same procedure shall be applied to the second BC in the overload list, starting at either position Pv+4 or Pv+3, depending on the 4/3 bit mode of the first BC. The same procedure shall be applied to the remaining BCs of the overload list. The voice list BCs subject to bit stealing will be marked as 3bit channels, the remaining ones as 4bit channels. An example of the procedure is illustrated in Figure11/G.763. Figure 11/G.763 = 12 cm 6.1.7.2.2 3/2 bit overload channel creation procedure If Nov is greater than Nv/3 and the optional 2 bit overload feature is available and enabled, the number (N3) of channels in the overload range that will be carried at three bits per sample shall be computed as follows: The number (n2) of bearer channels in the voice list that will operate at two bits per sample (i.e.these channels donate two bits) shall be computed as follows: n2 = N3 - Nv + Nov × 2 In addition, the integer variables Pv and Pov shall be computed as follows: Pv = (IT modulo Nv) Pov = (IT modulo Nov) where, IT is the IT number contained in the assignment message (note). Pv and Pov represent voice and overload list positions. These positions are numbered 0to Nv-1 and from0 to Nov-1, respec- tively. Note–If an optional USM is being used the IT number information in DCME frames0, n, 2n, etc. (i.e.every nth frame) shall also be used to create overload channels. The BCs stored in the overload list at the first N3 locations (modulo Nov), starting from the list posi- tion Pov, shall be marked as 3bit channels. The remaining BCs of the overload list shall be marked as 2bit channels. The BC stored in the voice list at the first n2 locations (modulo Nv), starting from the list position Pv, shall be marked as 2bit channels. The remaining BCs of the voice list shall be marked as 3bit chan- nels (i.e.these channels donate one bit). In order to obtain the bit associations for the BC bit map, the donated bits from the channels of the voice list shall be arranged in the following ordered sequence: Place in the sequence Donated Bit in voice List (see Note) 1st 2nd bit of BC at position Pv 2nd LSB of BC at position Pv 3rd 2nd bit of BC at position Pv+1 4th LSB of BC at position Pv+ 1 5th 2nd bit of BC at position Pv+ 2 6th LSB of BC at position Pv+ 2, etc. The 3/2 bit mode of the first BC in the overload list shall be checked to determine whether the 2 bit or 3 bit mode is used. If the first BC in overload list is a 2 bit channel, the following bit associations shall be entered into the BC bit map: a) MSB of BC in overload list position 0: 1st bit of the sequence; b) LSB of BC in overload list position 0: 2nd bit of the sequence. If the first BC in the overload list is a 3 bit channel, the same procedure shall be applied to item a), but itemb) changes and itemc) is added as follows: b) second bit of BC in overload list position 0: 2nd bit of the sequence; c) LSB of BC in overload list position 0: 3rd bit of the sequence. The same bit association procedure shall be applied to each remaining BC in the overload list: for these BCs, the association will start from the first available bit in the donated bit sequence. This procedure is illustrated in Figure 12/G.763. A particular example for a pool of nine BCs, No. 1 to BC No.9, is shown in Figure13/G.763. Note–In some cases the second bit of BC in voice list, indicated above, may not be available depending on the value ofN2, in which case the sequence is compacted upwards. Figure 12/G.763 = 9,5 cm Assumptions Computed parame- ters Nvo=9 ICoi=2 Nov=4 N3=3 N2=1 n2 =2 Note–The overload channel bits are matched with the corresponding stolen bits of the voice channels. 6.1.8 Connectivity implementation delay The IT-ADPCM Encoder-BC connection is implemented at the beginning of the DCME frame which occurs three frames after the start of the DCME frame containing the applicable assign- ment message. Refer to Figure14/G.763. Figure 14/G.763 = 4,5 cm 7 DCME receive unit structure The function of the DCME receive unit is to provide connections between the BCs, the ADPCM decoders and the ITs. At start-up, the various processes are loaded with the appropriate con- figuration data, and pre-assigned BCs are connected to ADPCM decoders and ITs, as required. Assignment messages are decoded to obtain information required for dynamic assignments of non- pre-assigned BCs to ITs (and ADPCM decoders). A sufficient number of ADPCM decoders shall be provided to guarantee that freeze-out due to unavailability of ADPCM decoders cannot occur (see Note). The actual connection is implemented at the beginning of the DCME frame which occurs three frames after the start of the DCME frame containing the applicable assignment message. This delay is necessary in order to provide adequate time for processing the assignment message before the associ- ated ADPCM BC samples arrive at the DCME receive unit. Note–For the point-to-point mode this condition is met if the number of ADPCM decoders is equal to the number of ADPCM encoders. For the multi-destination mode this condition is met if the number of ADPCM decoders provided equals the number of trunk channels receiving traffic. This section specifies those aspects of the DCME receive unit structure which are necessary to accurately define the DCME transmit unit/receive unit interaction. An example of a DCME receive unit structure which satisfies the interaction requirements specified in this section is given in AnnexA.2. 7.1 Receive channel processing function The receive channel processing (RCP) function decodes the received assignment messages, dynamically establishes BC-decoder-IT connectivity relationships and provides information to the transparent circuit handler and the transmit channel processing functions. 7.1.1 DCME receiver unit initialization At initialization, the receive side channel connectivity map shall be set to a known state (BCs and ITs disconnected) and the RCP parameters shall be loaded. These parameters include the infor- mation necessary for the allocation of pre-assigned channels and bit banks. The pre-assigned channel allocation (determined by the configuration data) shall be in accordance with the bearer structure requirements (§§5.2 and5.9). A map which identifies the remote IT numbers intended for the DCME and associates them with the local IT numbers (making up the circuit), is included in information loaded at initialization. The local IT numbers are used by the DCME in its transmitted assignment message. The remote IT numbers are those associated with the individual channels received by the local DCME receive unit from its corresponding DCME transmit units. 7.1.2 Input pre-processing Upon reception of an assignment message, a validity check shall be performed to ensure that the message is consistent with the transmit side assignment rules and with the DCME configuration data. A minimum list of conditions to be verified shall be as specified below: a) If the BC is in the overload range, or if the IT number is 250, the MSB of the BC identifica- tion word in the assignment message must be0. b) If the synchronous data word indicates a 64 kbit/s transparent channel, the MSB of the BC identification word must be0, and the BC number must be even. c) The BC number must not already be used for a pre-assigned channel. d) The IT number must be contained in the range which the corresponding DCME encoder can address regardless of destination. e) The BC number must be in the normal range if the BC type is data or transparent, or if the IT number is250. f) If the optional USM is used special checks are required for DCME frames 0, n, 2n, etc., of the DCME multiframe. For the optional R2 USM line signalling, messages will be delivered in DCME frames 0, 8, 16,etc. (i.e.every eighth frame of the DCME multiframe). The validity of the two IT numbers conveyed should be checked against the permissible range. If any of the above conditions are not satisfied, or if DCME frame alignment is lost, no further pro- cessing of the assignment message shall be performed. The receive IT number shall be assumed to be0 for the purpose of providing the Pv and Pov pointer values for the overload channel derivation process. 7.1.3 Connectivity map update If the assignment message validity check is successful, the received control channel message shall be processed as follows: a) The IT-to-BC connection shall be logged in the channel connectivity map. b) If the IT number is 0, the BC shall be disconnected from the previously connected IT, defined as ITP. c) If the IT number is 250, the BC shall be interpreted as a bit bank channel. d) If a BC of the transparent type is indicated by the assignment message, BC + 1 shall be des- ignated as disconnected in the channel connectivity map. e) If the connection of a BC changes to a different IT, the previously connected IT, defined at ITP, shall be disconnected. This is an implicit disconnection of ITP. f) If the connection of an IT changes to a different BC, the previously connected BC shall be designated as disconnected in the channel connectivity map. g) If a BC of the transparent type changes to a different type, the other BC of the transparent BC pair shall be designated as disconnected in the channel connectivity map. Its associ- ated IT shall also be designated as disconnected in the channel connectivity map. If, as a result of the above actions, the conditions exist for the deletion of a bit bank (as per Table3/ G.763), the bit bank BC shall be disconnected. If the optional USM is used, the channel connectivity map shall not be updated. However, ITn shall be used as a pointer in the overload channel derivation process. It should be noted that some connection/type changes are not strictly permissible under the assign- ment rules specified for the DCME transmit unit structure (see §6). These transitions, although abnormal, may occur at the DCME receive unit as the result of loss of assignment messages. Note that abnormal transitions are different from erroneous assignment messages (rejected by the input pre-processing task). The DCME receive unit shall recover from an abnormal assignment transition within a maximum of one assignment channel refresh cycle. 7.1.4 ADPCM decoder connection control The following ADPCM decoder control rules shall apply only if the remote IT number is des- tined for the DCME receive unit: a) When a new assignment of a previously disconnected IT is made, an ADPCM decoder shall be connected to the corresponding local IT, thus completing the BC to ADPCM decoder to IT path through the DCME receive unit. b) When a reassignment of a previously connected IT is made to a different BC, the ADPCM decoder currently associated with the corresponding local IT shall be maintained. c) Whenever an IT connection changes to BC number 0 (explicit disconnection) or the IT is implicitly disconnected, the associated ADPCM decoder shall be disconnected. d) The ADPCM decoder shall be reset when a new IT connection is established. 7.1.5 Bit bank handling and overload channel derivation The rules for bit bank handling and overload channel derivation shall be the same as those defined for the TCP function. The only differences are that when an assignment message is erroneous (or lost): 1) the pointer variables Pv and Pov shall be set to 0; 2) if there is not enough bit capacity available to service the corrupted assignment message then the affected channels shall receive dummy bits set to0; 3) the variable N4 (number of 4 bit overload channels) shall be set to 0 if its calculated value is negative; 4) the variable N3 (number of 3 bit overload channels) if used, shall be set to 0 if its calculated value is negative. 7.1.6 Connectivity implementation delay The BC to ADPCM decoder to IT connection is implemented at the beginning of the DCME frame which occurs three frames after the start of the DCME frame containing the applicable assign- ment message. Refer to Figure14/G.763. 7.1.7 TCP and TCH interactions The following indications are sent to the TCP and the TCH in response to certain transitions indicated by the assignment message. Rxdata(IT): This indication shall be sent to the TCP function when an assignment message is received which indicates a transition from a previous BC type to a data BC type. (IT is the transmit ITnumber.) RxTranspreq(IT): This indication shall be sent to the TCH when an assignment message is received which indicates a transition from another BC type to a transparent BC type. RxTransprel(IT): This indication shall be sent to the TCH when an assignment message is received which indicates a transition from a transparent BC type to some other BC type. 8 On-demand 64 kbit/s circuit handling 8.1 Overview of establishment and disestablishment of 64 kbit/s unrestricted class connections (transparent circuits) The DCME shall establish/disestablish 64 kbit/s unrestricted duplex connections under con- trol of the seizing/releasing ISC as part of the call set-up/clearing process between exchanges. Dedi- cated seizure/select and release messages and the associated acknowledgement messages are exchanged between the DCME and the ISC as defined in RecommendationQ.50. The DCME-to-ISC control interface is defined in §5.3. Subject to the capability of the ISC, this process is usable for performing the in-call modifica- tions between the DCMEs during alternate speech/64kbit/s unrestricted type calls. Upon reception of a seizure/select message from the ISC for a trunk, the DCME shall per- form the necessary internal checks, including the 64kbit/s unrestricted dynamic load control status, for the accommodation of this call and an acknowledgement (positive or negative) message shall be returned as soon as possible to the calling ISC. The calling end DCME shall initiate the establishment of the unrestricted 64kbit/s forward connection to the called end DCME using a special identifier in the assignment message. The called end DCME, upon receipt of this message, shall automatically ini- tiate the establishment of the unrestricted 64kbit/s return connection. Failure to complete the estab- lishment of a 64kbit/s circuit between DCMEs shall be reported to the ISC as soon as this has been detected internally. This reporting shall be in the form of an out-of-service message. Upon receipt of a release message from the calling ISC the releasing end DCME shall initiate the disestablishment of the unrestricted 64kbit/s forward connection, and the opposite end DCME shall automatically initiate the disestablishment of the unrestricted 64kbit/s return connection. Upon completion of this process, a positive release acknowledgement message shall be returned to the releasing ISC. Failure to complete the disestablishment shall be reported to the releasing ISC using the out-of-service message and the DCME shall put the trunk in a blocked condition. After manual or automatic removal of any failure condition, the DCME shall put the trunk in an idle condition and send a back-in-service message to the ISC. A calling end DCME shall detect a release initiated by the opposite end (non-controlling) ISC by the reception of a disconnect message in the control channel. This abnormal release shall be recog- nized as a dual seizure situation being resolved between the ISCs. The detecting DCME shall first complete the release normally and immediately attempt to re-establish the released 64kbit/s unre- stricted duplex connection between the DCMEs. 8.2 Transparent circuit handler (TCH) The TCH function interacts with the switching centre interface (SCI), the DLC, the TCP and the RCP functions. The TCH function is invoked for the execution of peer procedures in correspon- dent DCMEs for 64kbit/s circuit handling. A facility by which the operator may enable or disable the interaction between the TCH and DLC functions shall be provided (see Note). Note—Disabling of the TCH/DLC interaction may degrade voice performance under high load conditions. The functional partitioning of processing functions is intended to add clarity to the require- ments of the TCH function and not to specify processing partitions within a DCME implementation. The end-to-end on-demand circuit establishment and on-demand circuit disestablishment procedures have the following salient features: a) The generation of a positive acknowledge for a seizure/select request which is sent to the ISC when the 64kbit/s circuit establishment process between DCMEs has been properly initiated. b) Circuit handling protocols for dual seizures between DCMEs. These protocols are compat- ible with the procedures for dual seizures in ISCs as defined in RecommendationQ.764 (signalling procedures of Signalling System No.7 ISUP). c) Automatic recovery of the circuit handling process following unsuccessful or delayed com- pletion of circuit establishment. d) Automatic circuit blocking (for 64 kbit/s calls) after unsuccessful two-way disconnection. The block interaction diagram for the TCH function is shown in Figure15/G.763. Figure 15/G.763 = 9 cm The TCH receives 64 kbit/s seizure/select messages and 64 kbit/s release messages from the local ISC (through the SCI), receive transparent request and receive transparent release indications from the RCP function and 64kbit/s dynamic load control indications from the local DLC function. The TCH send 64 kbit/s acknowledged and not acknowledged messages, out-of-service and back-in- service messages to the local ISC (through the SCI) and sends transparent request and transparent release indications to the TCP. Table4/G.763 gives nine different TCH states. Four timers in the TCH define time intervals within which circuit establishment, disestablish- ment, and auto-recovery procedures are to be completed successfully. T1: Maximum time allowed for successful completion of 64 kbit/s circuit establishment, 1.0 s. T2: Maximum time allowed for successful completion of 64 kbit/s circuit disestablishment, 1.5 s. T3: Time assumed for completion of 64 kbit/s circuit disestablishment remotely initiated, 1.0 s. T4: Maximum time allowed for successful completion of 64 kbit/s circuit auto-recovery, 1.5 s. 8.2.1 External information elements The provision of the signalling system between the DCME and the local ISC, specified in RecommendationQ.50, will ensure the availability of the following external information elements for on-demand 64kbit/s circuit handling. Depending on the characteristics of the chosen DCME-ISC control system, all of the required external information elements may not be used. 8.2.1.1 S64(TCn) Request for the establishment of a 64 kbit/s circuit on local TCn received from the ISC. 8.2.1.2 R64(TCn) Request for the disestablishment of a 64 kbit/s circuit on local TCn received from the ISC. 8.2.1.3 S64Ack(TCn) Acknowledgement sent to the ISC that the establishment of a 64kbit/s circuit for TCn has been initiated. 8.2.1.4 S64NAck(TCn) Negative acknowledgement sent to the ISC that the request for establishment of a 64 kbit/s circuit for TCn has been rejected. 8.2.1.5 R64Ack(TCn) Acknowledgement sent to the ISC that the disestablishment of a 64kbit/s circuit for TCn has been completed. 8.2.1.6 Out-of-service (TCn) Indication sent to the ISC that TCn is out-of-service. 8.2.1.7 Back-in-service (TCn) Indication sent to the ISC that TCn is back-in-service. 8.2.2 DLC information elements The indications received from the DLC function are as follows: 8.2.2.1 DD64 Indication received from the DLC function when 64 kbit/s capacity is available locally and at the correspondent DCME. Refer to §9.4. 8.2.2.2 AD64 Indication received from the DLC function when 64kbit/s capacity is not available locally or at the correspondent DCME. Refer to §9.4. 8.2.3 Other information elements The indications sent to the TCP function and received from the RCP function are as follows: 8.2.3.1 Transpreq(ITn) Indication sent to the TCP to initiate the assignment of a 64kbit/s forward channel for ITn. 8.2.3.2 Transprel(ITn) Indication sent to the TCP to initiate the disconnection of 64kbit/s forward channel for ITn. 8.2.3.3 RxTranspreq(ITn) Indication received from the RCP to indicate that a 64kbit/s connection has been established. 8.2.3.4 RxTransprel(ITn) Indication received from the RCP to indicate that a 64kbit/s connection has been released. 8.3 On-demand circuit establishment All procedures described for the on-demand circuit establishment pertain to a single trunk (circuit) denoted by TCn, and to the associated forward and return intermediate trunks ITn and ITn¢, respectively. 8.3.1 Normal circuit establishment The sequence chart for a normal 64 kbit/s circuit establishment cycle is shown in Figure16/ G.763. Figure 16/G.763 = 11 cm 8.3.1.1 Actions required at the calling end SCI/TCH Upon reception of the external information element S64 for TCn from the ISC, the SCI shall send S64NAck(TCn) to the ISC if the TCH is in the process of disestablishing TCn from a previous call (see §8.4.1.4), or if the DLC ON condition (AD64 has been received) is in effect (provided that the internal interaction with the DLC process is enabled), or if the TCH is in the connect-called-64 state. No further action shall be taken after sending S64NAck(TCn). If the internal DLC condition (if used) is OFF (DD64 has been received), and if the TCH is not in the process of disestablishing ITn from a previous call, the SCI shall send S64Ack(TCn) to the ISC and the TCH shall: a) send Transpreq(ITn) to the TCP; b) start timer T1. A subsequent reception of the RxTranspreq(ITn) indication shall signify the completion of the circuit establishment and shall cause the TCH to reset timer T1 and to enter the connect-calling-64 state for the circuit using ITn. The expiration of timer T1 is described in §8.3.2.1. 8.3.1.2 Actions required at the calling end TCP/RCP The reception of the Transpreq(ITn) indication from the local TCH shall cause the TCP to perform a transmit assignment (BCx,ITn) in accordance with §6 for the forward link of the circuit being established. Reception of the new assignment message (BCx, ITn¢) shall cause the RCP to establish the receive connection for the return in accordance with §7 and to send the RxTranspreq(ITn) indication to the TCH. Actions required on failure to receive the expected RxTranspreq(ITn) indication for the return link are described in §8.3.2.2. 8.3.1.3 Actions required at the called end RCP/TCP Reception of a new assignment message (BCx, ITn) from the distant (calling) DCME shall cause the RCP to establish the receive side connection in accordance with §7 and send the RxTranspreq(ITn) indication to the TCH. Reception of the Transpreq(ITn) indication shall cause the TCP to perform a transmit assign- ment (BCx, ITn¢) in accordance with §6 for the return link of the circuit being established. 8.3.1.4 Actions required at the called end TCH Reception of the RxTranspreq(ITn¢) indication shall cause the TCH to initiate the 64 kbit/s transparent channel establishment in the return direction by sending a Transpreq(ITn¢) indication to the TCP and to enter the connect-called-64 state for the circuit using ITn„¢. 8.3.2 Unsuccessful circuit establishment The sequence chart for an automatic recovery after an unsuccessful circuit establishment is shown in Figure17/G.763. Figure 17/G.763 = 11,5 cm 8.3.2.1 Actions required at the calling end SCI/TCH If the RxTranspreq(ITn) indication is not received before the expiration of timer T1, the fol- lowing automatic recovery procedure shall be initiated. The TCH shall: a) send a Transprel(ITn) indication to the TCP; b) start timer T4. The subsequent reception of a RxTransprel(ITn) indication shall signify the completion of the circuit disestablishment and shall cause the TCH to reset timerT4 and to enter the appropriate state for the circuit using ITn. The expiration of timer T4 is described in §8.3.2.3. The SCI shall: a) send an out-of-service (TCn) indication to the ISC; b) send a back-in-service (TCn) message to the ISC when the TCH has indicated the reception of RxTransprel(ITn) from the local RCP. 8.3.2.2 Actions required at the calling end TCP/RCP Reception of the Transprel(ITn) indication shall cause the TCP to perform a disconnection (BCx, IT0) in accordance with §6 for the forward link of the unsuccessfully (or delayed) established circuit. If the expected new assignment message (BCx, ITn¢) for the return direction is received while the above circuit disconnection is in progress, the RCP in the calling DCME shall first establish the receive side connection normally by executing the actions described in §8.3.1.2, §2, and then complete the normal disconnection process by executing the actions described in §8.4.1.2, §2. 8.3.2.3 Unsuccessful automatic recovery If the RxTransprel(ITn) from the RCP is not received before the expiration of timer T4, the SCI shall block circuit TCn and raise a blocking alarm for this circuit. The SCI shall be reset to the appropriate state for the circuit using TCn only after the operator's attendance to the blocking alarm. Upon reset of the SCI, a back-in-service (TCn) shall be sent to the ISC. 8.4 On-demand circuit disestablishment All procedures described for the on-demand circuit disestablishment pertain to a single trunk (circuit) denoted by TCn, and to the associated forward and return intermediate trunks ITn and ITn¢, respectively. 8.4.1 Normal circuit disestablishment The sequence chart for a normal 64 kbit/s circuit disestablishment cycle is shown in Figure18/G.763. Figure 18/G.763 = 8 cm 8.4.1.1 Actions required at the releasing end SCI Upon reception of the external information element R64 for TCn at the releasing end SCI, the TCH shall: a) send Transprel(ITn) to the TCP; b) start timer T2. A subsequent reception of RxTransprel(ITn) indicates completion of the cir- cuit disestablishment and shall cause the TCH to reset timer T2 and enter the appropriate state for the circuit using ITn. The expiration of timerT2 is described in §8.4.2.1, and the SCI shall send an R64Ack(TCn) indication to the ISC when the TCH has indicated the recep- tion of RxTransprel(ITn) from the local RCP. 8.4.1.2 Actions required at the releasing end TCP/RCP The reception of Transprel(ITn) from the local TCH shall cause the TCP to perform a discon- nection (BCx,IT0) in accordance with §6 for the forward link of the circuit. Reception of the disconnection message (BCx, IT0) or an implied disconnection shall cause the RCP to perform a receive disconnection for the return ITn¢ in accordance with §7 and to send the RxTransprel(ITn) signal to the TCH. 8.4.1.3 Actions required at the released end RCP/TCP Reception of the disconnect message (BCx, IT0), or alternatively an implied disconnect from the distant (releasing) DCME shall cause the RCP to disconnect the receive side connection in accor- dance with §7 and send the internal signal RxTransprel(ITn') to the TCH. Reception of the Transprel(ITn¢) signal shall cause the TCP to perform a disconnection (BCx, IT0) in accordance with §6 for the return link of the circuit. 8.4.1.4 Actions required at the released end TCH/SCI Reception of RxTransprel(ITn¢) from the RCP shall cause the TCH to initiate the release of the 64kbit/s transparent channel in the return direction by sending Transprel(ITn¢) to the TCP, and to start a timer T3 (expiration of timer T3 assumes normal completion of the disconnection process ini- tiated by the distant end). Prior to timer T3 expiration, any reception of S64 for the same TCn from the local ISC shall be negatively acknowledged by forwarding S64NAck(TCn) to the ISC. If the RxTranspreq(ITn¢) signal followed by a RxTransprel(ITn¢) signal are received prior to timer T3 expiration, a spurious disconnection condition shall be declared and the actions described in §8.6.2 shall be taken. Upon expiration of T3, the TCH shall enter the appropriate state for circuit ITn¢. 8.4.2 Unsuccessful circuit disestablishment The sequence chart for an unsuccessful 64 kbit/s circuit disestablishment cycle is shown in Figure19/G.763. Figure 19/G.763 = 10 cm 8.4.2.1 Actions required at the releasing end TCH If the RxTransprel(ITn) from the RCP is not received before the expiration of timer T2, the TCH shall block circuit ITn and raise a blocking alarm for this circuit. The SCI shall send the out-of- service (TCn) message to the ISC. The TCH shall be reset to the appropriate state for the circuit using ITn only after the operator's attendance to the blocking alarm. Upon reset of the TCH, the SCI shall send a back-in-service (TCn) message to the ISC. 8.5 Dual seizure handling All procedures described for the dual seizure handling pertain to a single trunk (circuit) denoted by TCn, and to the associated forward and return intermediate trunks ITn and ITn¢, respec- tively. 8.5.1 Dual seizure condition Simultaneous reception of seizure requests S64 for TCn from both ISCs will cause the proce- dures described in §§8.3.1.1 and8.3.1.2 to be invoked from each end of the circuit. The condition after execution of those procedures would be the connect-calling-64 state of the TCHs at both ends for the same circuit. Refer to Figure20/G.763. Figure 20/G.763 = 8,5 cm 8.5.2 Dual seizure resolution For explanation in this section, the non-controlling ISC is assumed to be at the ITn¢ side. Refer to Figure21/G.763. 8.5.2.1 Actions required at the TCH (non-controlling switching centre end) Upon reception of the external information element R64 (TCn) from the non-controlling ISC, the TCH shall initiate the normal circuit disestablishment procedures described in §§8.4.1.1, 8.4.1.2 and8.4.1.3. Figure 21/G.763 = 11 cm 8.5.2.2 Actions required at the TCH (controlling switching centre end) Upon reception of RxTransprel(ITn) the TCH shall respond by sending Transprel(ITn) to the TCP. The TCP shall thereafter immediately initiate the automatic re-establishment of the circuit by sending Transpreq(ITn) to the TCP and to start timer T1. All subsequent procedures described in §§8.3.1.2, 8.3.1.3 and8.3.1.4 shall proceed normally (including procedures for auto-recovery described in §8.3.2 in case of unsuccessful circuit re-establishment). 8.6 Spurious disconnect handling All procedures described for the spurious disconnect handling pertain to a single trunk (cir- cuit) denoted by TCn, and to the associated forward and return intermediate trunks ITn and ITn¢, respectively. 8.6.1 Spurious disconnect conditions Condition I – A spurious disconnect message or a spurious implied disconnect detected by the called end RCP while the called end TCH is in the connect-called-64 state will cause the proce- dures described in §§8.4.1.3 and8.4.1.4 to be invoked. A subsequent assignment message refresh will result in the generation of a RxTranspreq(ITn¢) signal to the called end TCH after timer T3 has started. Refer to Figure22/G.763. Condition II – A spurious disconnect message or a spurious implied disconnect detected by the calling end RCP while the calling end TCH is in the connect-calling-64 state will cause the proce- dures described in §8.5.2.2 to be invoked. The resulting disconnect message and the subsequent re- -establishing assignment message will be recognized as spurious disconnect conditionI. Refer to Figure23/G.763. Figure 22/G.763 = 11, 5 cm 8.6.2 Spurious disconnect recovery 8.6.2.1 Actions required at the called-end TCH After timer T3 has started, upon reception of a RxTranspreq(ITn¢) signal, followed by a RxTransprel(ITn¢) signal, the TCH shall enter the spurious-recovery state for the circuit using ITn¢. A subsequent reception of the internal message RxTranspreq(ITn¢) shall cause the TCH to reset timer T3, to initiate the re-establishment of the 64kbit/s transparent channel in the return direction by send- ing Transpreq(ITn¢) to the TCP, and to re-enter the connect-called-64 state for the circuit using ITn¢. If timer T3 expires before the reception of the RxTranspreq(ITn¢) signal, the TCH shall enter the appropriate state for circuit ITn¢. 8.6.2.2 Actions required at the calling end TCH For condition I, the actions described in §8.5.2.2 shall be taken once. For condition II, the actions described in §8.5.2.2 shall be taken twice. Figure 23/G.763 = 15 cm 9 Dynamic load control 9.1 Overview To reduce the probability of excessive freeze-out percentages, the DCME shall have a facility for DLC. This facility signals towards the local and distant-end ISCs that new calls should not be established. The DCME shall communicate with the ISC in accordance with RecommendationQ.50. A DLC facility shall be provided for voice/voice-band data and on-demand 64kbit/s traffic sepa- rately. DLC shall not be applied to pre-assigned traffic. The DCME shall provide a DLC signal which may be sent to the local and distant ISCs to limit the traffic load presented to the DCME during overload conditions. Overload conditions should be indicated by average number of bits per sample calculated for each pool. When the value falls below a particular previously set threshold level, the DLC message should be generated at the DCME. DLC messages shall be sent back to the local ISC(s), and the distant DCME shall be informed through the control channel. The distant DCME shall interpret and appropriately convey the DLC information to its associated ISC(s). 9.1.1 DLC activation/deactivation criteria Voice/voice-band data DLC activation messages shall be generated when the number of bits per sample, averaged over the voice channels of the pool, drops below a presettable threshold. The 64kbit/s unrestricted (transparent) DLC activation messages shall be generated when: a) the measured number of assigned 64kbit/s unrestricted channels exceeds a presettable threshold; or b) the voice/voice-band data DLC has been activated; or c) the voice/voice-band data DLC is expected to be activated due to an increase of one addi- tional channel in the 64kbit/s unrestricted traffic loading. Activation of DLC shall occur immediately upon transgressing the threshold criteria. Deactivation of DLC shall occur when the average number of bits per sample exceeds a presettable threshold or the number of 64kbit/s unrestricted channels falls below a presettable threshold. If the 64kbit/s DLC is not active, 64kbit/s unrestricted channel requests shall not be denied. Deactivation of DLC shall not occur earlier than a programmable interval which has a minimum of 10s in order to prevent an oscil- lating condition. 9.1.2 Message processing and routing Internal DLC indications are sent on a destination selective basis to the local SCI and the TCH for further processing and subsequent forwarding of the associated bearer service related exter- nal information elements to the ISC(s) according to §§9.3.2 and9.4.2. The list of DLC related exter- nal and internal messages used by the SCI is given in §5.3.2. The external message exchange between the SCI and the ISC is as defined in RecommendationQ.50. Assuming that the ISC is responding to messages originating from the DCME SCI, it is rec- ommended that once a DLC signal has been active (i.e.new calls blocked) and then returns to an inactive state (new calls may be established), the affected circuits be unblocked in a gradual manner for the relevant bearer service type. Correspondent DCMEs shall exchange their respective load con- ditions by means of the DLC support messages within the control channel asynchronous data word. Refer to §11.3.3.2. 9.2 Load condition calculation (see Note) The local loading condition shall be determined using the average number of encoding bits per sample as a measure. An example of a DLC double averaging technique is given in AnnexB.1. Note–The load calculation may be used for provision of special tandeming facilities (under study). 9.3 Voice/voice-band data DLC 9.3.1 DCME function Two load conditions are defined: a) High Load (HL)–In this condition, the measured average number of encoding bits is less than the high load threshold (e.g.3.6bits per sample). b) Low Load (LL)–In this condition, the measured average number of encoding bits is greater than the low load threshold (e.g.3.9bits per sample). The HL and LL thresholds shall be operator programmable options settable between3 and 4in 0.05bits per sample steps. When the average number of encoding bits is between the two thresholds, the last load condi- tion shall be maintained. A local HL condition shall be signalled to the corresponding DCME(s) by setting the voice/ voice-band data DLC support message (bitp) to state 1. Refer to §11.3. A local LL condition shall be signalled to the corresponding DCME(s) by setting the voice/ voice-band data DLC support message (bitp) to state0. Refer to §11.3. The DLC ON condition for voice/voice-band data traffic shall be declared when: a) the HL condition is detected locally; or b) the bit p received from a corresponding DCME is in state 1 (DLC is applicable only to those circuits which are destined to this corresponding DCME). The DLC OFF condition for voice/voice-band data traffic shall be declared for each destination when: a) the LL condition is detected locally; and b) the bitp received from the relevant destination is in state 0. The DLC ON condition shall be declared during a system reconfiguration. The ADVD indication (see §5.3.2) shall be sent to the local SCI at the transition from DLC OFF to DLC ON. The DDVD indication shall be sent to the local SCI at the transition from DLC ON to DLC OFF. 9.3.2 SCI function The SCI shall send the information elements SNA and VDNA to the ISCs when the TCH receives an ADVDindication from the DLC function. When the TCH receives a DDVD indication from the DLC function, the SCI shall send the information elements SA and VDA to the ISC(s), unless an ADVD indication recurs within Taseconds after the last detected ADVD indication. The Ta timer shall be operator selectable with a minimum of tenseconds. Depending on the characteristics of the chosen DCME - ISC control system, the SNA, VDNA, SA and VDA information elements may not all be used. 9.4 On-demand 64 kbit/s DLC 9.4.1 DCME function The availability of capacity for on-demand 64kbit/s traffic is based on the predicted average number of encoding bits for voice traffic if a pair of 4bit bearer time slots currently used for voice traffic were to be used to accommodate one additional 64kbit/s channel. Two capacity availability conditions are defined: a) Capacity Available (UCA)–In this condition, the predicted average number of encoding bits is greater than the LL threshold defined in §9.3.1. b) Capacity Not Available (UCNA)–In this condition, the predicted average number of encoding bits is less than the HL threshold defined in §9.3.1. When the predicted average number of encoding bits is between the two thresholds, the last load condition shall be maintained. A local UCNA condition shall be signalled to the corresponding DCME(s) by setting the on- demand 64kbit/s DLC support message (bitq) to state1. Refer to §11.3. A local UCA condition shall be signalled to the corresponding DCME(s) by setting the on- demand 64kbit/s DLC support message (bitq) to state0. Refer to §11.3. The DLC ON condition for on-demand 64kbit/s traffic shall be declared when: a) the UCNA condition is detected locally; or b) the bitq received from a corresponding DCME is in state1 (DLCis applicable to those cir- cuits which are destined to this corresponding DCME). The DLC OFF condition for on-demand 64kbit/s traffic shall be declared for each destination when: a) the UCA condition is detected locally; and b) the bitq received from the relevant destination is in state 0. The DLC ON condition shall be declared during a system reconfiguration. The AD64 message shall be sent to the local SCI and to the TCH at the transition from DLC OFF to DLCON. The DD64 message shall be sent to the local SCI and to the TCH at the transition from DLC ON to DLCOFF. A facility to enable or disable the DLC/TCH interaction shall be provided. Refer to §8.2. 9.4.2 SCI function The SCI shall send the information element UCNA to the ISC(s) when the TCH receives an AD64indication. When the TCH receives a DD64 indication, the SCI shall send the information element UCA to the ISC(s), unless the TCH receives an AD64 indication within Tb seconds after the last detected AD64 indication. The Tb timer shall be operator selectable with a minimum of tenseconds. Depending on the characteristics of the chosen ISC control system, the UCNA and UCA information elements may not be used. 10 Test procedures A means of verifying end-to-end continuity and correct assignment of channels must be pro- vided. If an automatic procedure is implemented then it should conform to the following: Note–The channel check procedure is applied independently to each pool. 10.1 Channel check procedure 10.1.1 Test procedure A repetitive 20second Test time frame (TTF) shall be established. At the start of each TTF, unless the procedure is inhibited, a test vector bit pattern sequence shall be originated on IT239 for pool1 and IT240 for pool2. This test vector sequence shall compete for assignment to a bearer chan- nel in accordance with §6. The ADPCM encoder for (BCn, IT239/240) shall be selected normally in accordance with §6, except that any ADPCM encoders selected for IT239/240 shall always operate in A-law mode. The characteristics of the test vector sequence shall be in accordance with §10.1.4. The test vector sequence shall remain ON for approximately one second. A DCME transmit unit shall generate one channel check test vector which shall be processed by all corresponding DCME receive units. For this reason, IT239/240 shall be assumed to be destination directed to all destinations corre- sponding with the DCME transmit unit. To inform the corresponding DCME receiver units that a channel check has commenced, a code 1111 is transmitted in the synchronous data word in the same DCME frame as the first associ- ated channel check assignment message (BCn, IT239/240) for each TTF. The synchronous data word code1111 shall be transmitted once for each channel check sequence. If the channel check procedure has been manually inhibited at the DCME transmit unit, bit1 in DCME frame62 of the Asynchronous data word shall be set to 1, otherwise the bit shall be set to0. The manual inhibit shall become effective at the next TTF boundary. All corresponding DCME receive units shall assign IT239/240 to a special test port. A spe- cial test port is assigned for each received bearer. The special test ports are identified by the local IT numbers241 through244 receiving bearer numbers1 through4, respectively. A test ADPCM decoder associated with (BCn, IT239/240) shall be selected in accordance with §7. However, any ADPCM decoder selected for IT239/240 shall operate in A--law mode. Continuous correlation shall be performed to identify the presence of the test vector. When the test vector is identified, a test pat- tern receiver shall determine the accuracy of the match between the received test vector and a locally stored version of this pattern in accordance with §10.1.4. For each bearer, the result from the test pat- tern receiver shall be disregarded if the continuous BER measurement declares a high BER condition. Refer to §15.10.1. 10.1.2 Reporting test results (remote DCME) The remote DCME shall generate a local alarm when the test vector pattern is not correctly received in accordance with §10.1.4, or if the code1111 is received from synchronous data word and a test vector has not been synchronized on the corresponding test port. The remote DCME shall construct and maintain a table of test results of each BC. Separate test result tables shall be maintained for each incoming bearer and/or pool. For each BC, an entry in the table shall contain a0 if the test result is pass, otherwise the test result table shall contain a1. If the result of the test pattern receiver has been disregarded, a1 shall be entered in the test result table for the high BER yes/no condition and a1 shall be assumed for the pass/fail entry. The test result table shall also include the identity of the ADPCM decoder currently assigned to the test port. It is recommended that the test result table also contain a real-time clock and date entry show- ing the time and date that the last test result was obtained for each BC. It is further recommended that the result tables be made accessible by the local operations and maintenance function or an equivalent facility. For each bearer, the remote DCME shall send the result of the last channel check to the corre- sponding local DCME via the Asynchronous Data Word using the format shown in Table5/G.763. A test result consisting of a BC number, pass/fail condition, high BER yes/no condition and ADPCM decoder number shall be sent once per DCME multiframe in DCME frames56-61. The test results are sent in ascending numerical order of the incoming bearer number. If no test result exists, if the automatic procedure has not been implemented, or if more than 60seconds have elapsed since the last channel check test for that bearer, the BC number and the ADPCM decoder number contained in DCME frames57, 58, 59 and60, respectively, shall be set to all1s (ineffective message). The pass/fail and high BER bits shall be set to1. The message contents shall remain latched to the last result for that bearer until a new result is available. 10.1.3 Reporting test results (local DCME) The local DCME shall build a result table for each corresponding DCME by accumulating the incoming channel check result messages. The local DCME shall identify the required result mes- sages by examining the bearer identification number contained in the first message (DCME frame56) of each table. The traffic plan will contain the bearer identification number(s) pertaining to each DCME. The local DCME shall generate a local alarm when an incoming bearer channel currently subject to the channel check procedure is reporting an abnormal channel check result condition. 10.1.4 Test vector sequence characteristics The test vector sequence shall consist of the following three contiguous segments: a) 100ms of 2400 Hz sinusoidal tone at -10dBm0; b) the A-law PCM initializing sequence in accordance with §10.1.5; c) 768ms of 1254 Hz sinusoidal tone in accordance with the test vector sequence described in §10.1.5. The test pattern receiver shall continuously search for a 1254 Hz sinusoidal tone pattern at an equivalent level of 0dBm0 ±1dB. The test pattern receiver shall be designed to synchronize to the 1254Hz sinusoidal tone pattern within 100ms at a bearer error rate of1 in 10-3 while the bearer is operating in 3bit mode (note). Following synchronization, the test pattern receiver shall declare test pass if the sum of the measured errors does not exceed 2000for each of the LSB and LSB+1bits, and the sum of the errors does not exceed1000 for each of the MSB through MSB-5bits in a 600ms measurement period measured at the PCM output stream. The determination test pass or test fail shall be made at the end of a 600ms measurement window. The start of the measurement window shall be located 650ms from the time of occurrence of the assignment message containing the synchronous data code word(1111). The measurement window test time frame and 1254Hz test tone sequence are shown in Figure24/G.763. Note–Operation in 2bit mode requires further study. Figure 24/G.763 = 8,5 cm 10.1.5 Channel check test vectors The complete test vector sequence comprises a 2400 Hz sinusoidal signal followed by an ini- tializing segment followed by a 1254Hz sinusoidal signal. All segments are contiguous. The first sequence comprises 834samples (approximately 100ms) of a 2400Hz sinusoidal sequence encoded in accordance with RecommendationG.711 using A-law encoding. An output sequence is not pro- vided for this input sequence. A reset is assumed prior to the start of the second sequence. The second sequence consists of 3496samples (approximately 437ms) of A-law initializing sequence. No output sequence is provided for this input sequence. The third input test sequence represents a 1254 Hz sinusoidal tone encoded in PCM in accor- dance with RecommendationG.711 using A-law encoding. The output sequence is the corresponding PCM A-law output obtained when the input test sequence is passed through an ADPCM encoder and ADPCM decoder operated back-to-back. The output sequence assumes that the decoder ADPCM algorithm has been initialized imme- diately prior to the reception of the test sequence. The test sequence format is based on 768ms of coded signal divided into a series of blocks. To maintain the accuracy with which the sample sequences will be incorporated in manufac- turers' equipment, flexible disks containing these sample sequences may be obtained from the ITU. 10.2 Internal tests It is recommended that an internal test sequence performing a TC-BC-TC loopback test be provided. These tests should, as a minimum, evaluate the activate level of the activity detectors (DCME transmit unit) and the PCM-to-PCMbit integrity (for DCME transmit unit and receive unit). The test sequence should be designed to sequentially evaluate all combinations of channels (TC, IT and BC) and ADPCM codecs. 11 Control channel (CC) The CC shall be a 32kbit/s channel, and shall include provisions for accommodating the fol- lowing categories of inter DCME terminal messages: – trunk-to-bearer assignment; – idle noise level; – dynamic load control; – alarm information; – self diagnostic information; – signal classification. Each pool of channels within the bearer frame shall contain a CC. The CC shall occupy the lowest numbered 4bit BC in the pool. The first bit is a syncbit and the remaining 3bits carry a part of the CC message. Control channel messages are transmitted at a rate of 3bits in each 125ms bearer frame. A complete 48bit encoded (CC) message shall be transmitted in one DCME frame of 2ms. Prior to encoding, the CC message shall consist of an 8bit BC identification word, an 8bit IT identification word and 8bits for other DCME to DCME messages (Data Word). The CC message shall be pro- tected by a (24,12) rate 1/2 Golay code. Figure25/G.763 illustrates the CC transmission scheme. In the figures describing the CC, the left-hand bits are transmitted first. Figure 25/G.763 = 8,5 cm 11.1 CC error protection A (24, 12) rate 1/2 code shall be applied to the CC for error protection. The (24, 12) code is obtained from a (23,12) Golay code with the addition of a dummy bit and is capable of correcting 1, 2 or 3bits in error in a block of 24bits. The code generator polynomial is: The 24 information bits comprising 8bits for the BC number, 8bits for the IT number and 8bits for other data are transmitted in two blocks of 12information bits each. For each information block there is a check block consisting of 11bits for the Golay code and one dummy bit as shown in Figure26/G.763. The check bits are obtained by computing the remainder of the polynomial division shown below: where, FIGURE 26/G.763 = 10 cm 11.2 CC synchronization A 16bit unique word shall be provided for each individual clique, to identify the beginning of the 2ms DCME frame over which the encoded CC message of the pool is transmitted. Refer to Figure25/G.763. The unique word shall be transmitted at the rate of one bit per bearer frame via the sync bit. The sync bit shall occupy the most significant bit position of the CC4bit time slot. The 16bit unique word shall also provide a means of identifying the beginning of a 128ms DCME multiframe (64DCME frames) for use by the asynchronous data word. Refer to §11.3.3.2. 11.2.1 Unique word pattern The sync bit pattern transmitted in a DCME frame shall constitute the following unique words: DCME frame0 to 63001010011011110 DCME frame 1 to 631110101100100001 The order of transmission of the pattern shall be from the extreme left-hand bit first to the extreme right-hand bit last. The first bit of the pattern shall be transmitted in the first nibble of the 16nibbles constituting a complete CCmessage. 11.2.2 Unique word detection The unique word detection shall be based on the detection of a correlation match between the accumulated contents of the first bit of the CCnibble and a locally stored unique word pattern. The resulting correlation matches shall be used to attain, maintain and regain the synchronization of the CCmessage. In the steady state, a detection threshold of three shall be used to maintain synchronization, and a 3bit window centred 16bits after the previous detection of the correlation match shall be used to locate the start of the DCME frame for the proper decoding of the CC message. If the correlation match is not achieved, the CC message bits shall be discarded and a search procedure shall be initi- ated over a 16bit window. 11.3 CC message structure 11.3.1 BC identification word The MSB of the 8bit BC identification word shall be used to indicate the BCtype. For data, the MSB shall be1. For all other BC types (bitbank, transparent, voice), the MSB shall be0. The sevenLSBs in binary code shall identify the BC number in accordance with §5.9. The normal BC numbering range shall be1 through61. The overload BC numbering range shall either be64 through83 or if the optional 2bit encoding mode is available and enabled 64to124. For 64kbit/s transparent channels, the BC number shall identify the first 4bit BC of a pair of adjacent 4bit BCs used to create an 8bit BC and shall be even numbered in the range2 through60. A channel type identifier code in the synchronous DCME to DCME Data Word shall be used, as defined in §11.3.3.1 to indicate a 64kbit/s transparent channel. BC number 0 in binary code shall be used for CC messages transmitted during system start- up or during a DCME transmit unit map change. BCnumber 255 in binary code shall be used to indicate an ineffective CCmessage if all traf- fic is preassigned. 11.3.2 IT identification word The 8bits of the IT identification word shall be used to identify the ITs. ITs numbered 1to216 in binary code shall be available for traffic. When less than 216ITs are used, the numbering will not necessarily be numerically consecutive. IT numbers 232, 233, 234 and 235 in binary code shall be used for DCME to DCME order- wires (up to fourcorrespondents), see §15.9. IT numbers 239/240 in binary code shall be used for the automatic end-to-end channel check procedure, see§10. IT number 0 in binary code shall be used to indicate an explicit disconnection or shall be transmitted in the CC during system start-up and DCME transmit unit map changes. IT number 250 in binary code shall be used when the associated BC is to be utilized for the bit bank as described in §§6 and7. IT number 255 in binary code shall be used to indicate an ineffective CCmessage if all traffic is preassigned. 11.3.3 Data word The 8bit data word in the CC message forms two independent data channels. The first data channel consists of the fourMSBs of the 8bit data word, and is transmitted with each assignment message synchronously relative to the BCand IT identification. The second data channel consists of the remaining 4 bits of the 8bit data word transmitted in a multi-frame structure asynchronously relative to the BC and IT identifications. 11.3.3.1 Synchronous data word The 4bit synchronous data word is used: a) to transmit background noise level information to the DCME receive unit; b) to indicate that the BC is the first 4bit nibble of a 64 kbit/s transparent channel; c) to indicate that the BC is assigned for the channel check procedure; d) to indicate an ineffective message; e) to carry user signalling bits when the optional USM is used. Background Gaussian noise, as determined at the transmit activity detector, will vary between -68dBm0 and-42dBm0 (see Note). For channels subject to DSI, the background noise level shall be encoded in accordance with Table6/G.763. The noise level code shall be transmitted with each new assignment and refreshment message. Note–For A-law encoding the minimum noise level is -65dBm0. For each CC message, the DCME receive unit shall decode the 4bit data word and update the noise level memory associated with the decoded IT according to Table6/G.763. At the DCME receive unit, a pseudo-random 8bit PCM sequence simulating Gaussian noise shall be applied to the disconnected IT. The simulated noise level shall match the last stored value in the noise level memory before the disconnection. For channels carrying 64kbit/s transparent calls, the 4bit data word shall be 1001 and trans- mitted with each new assignment, refreshment and disconnection message. If the BC in the assignment message is being subjected to the automatic channel check proce- dure according to §10, the 4bit data word shall be1111. 11.3.3.2 Asynchronous data word The 4bit asynchronous data word will convey the following types of DCME-to-DCME information: a) end-to-end circuit supervision and alarm indications on a per channel basis; b) bearer related backward alarm indication to the remote DCME; c) DLC support messages; d) BC related messages pertaining to channel check procedures. The data word multiframe shall consist of 64DCME frames numbered from 0to63. FrameNo.0 is the DCME frame in which the CC unique word is inverted. The CC unique word for the remaining 63frames shall be transmitted normally. Bit allocations in the data word multiframe for the various applications shall be as shown in Table5/G.763. 11.3.4 CC structure when USM option is used If the optional USM is used, the BC identification word and the CCsynchronous data word can be formatted according to the users' requirements in the DCME frames0, n, 2n,etc. (i.e.every nth DCME frame) of the DCME multiframe. For the R2 USM every eighth frame of the DCME multiframe shall be used to transmit a sig- nalling message as follows. The bits 1to8 of the signalling message shall identify ITn1. The bits 9to16 of the signalling message shall identify ITn2. Bits 17and18 shall encode the aand bbits of ITn1. Bits19and20 shall encode the aand bbits of ITn2. The aand bbit signalling information will be either change of signalling states, or the refreshment of existing states. Figure27/G.763 illustrates the format for this type of message. FIGURE 27/G.763 = 9 cm 12 Activity detection and data/speech discrimination This section describes the functional requirements of the transmit activity detector, data/ speech discriminator, signalling detector and receive activity detector. Compliance with all paragraphs of this section is mandatory with the exception of the trans- mit activity detector threshold and operate time specification. Compliance with the threshold and operate time specification is not required to achieve interworking between various DCME manufac- turers. The performance of the DCME transmit unit activity detector will be assessed by conducting MOS subjective tests on the entire DCME system. DCME testing methodologies have been specified by CCITT Study GroupXII in RecommendationP.84. 12.1 Transmit activity detector For each IT, the transmit activity detector characteristics are based upon the assumption that the amplitude frequency response of the transmission channel (up to the input of the activity detector) is ±0.5dB with respect to 1000Hz over the frequency band from 300 to 3400Hz. The Gaussian noise level can typically vary over a range from -68 to -42dBm0. Note–For A-law encoding, the minimum noise level is -65dBm0. Functionally, the transmit activity detectors shall determine whether or not there is activity on each transmit IT and provide an active/inactive (act/Inact) indication. Upon system start-up or map change, the transmit activity detectors shall be reset to provide an Inact indication. Functionally, the transmit activity detectors shall determine the transmit idle channel noise level on each non-pre-assigned IT in the DCME transmit unit. The idle channel noise level for each DCME transmit unit IT is encoded and transmitted to the DCME receive unit in the 4bit synchronous data word. The idle channel noise is regenerated in the DCME receive unit in accordance with §11.3.3.1 and is applied to the corresponding DCME receive unit ITs when they are disconnected from their assigned BCs. 12.1.1 Threshold and operate time The transmit activity detector threshold shall automatically adjust relative to the average power of Gaussian noise band limited between 300to 3400Hz. The threshold and operate time of the transmit activity detector may be implementation spe- cific. However, for guidance threshold and operate time, characteristics for the transmit activity detector are given in AnnexB.2. 12.1.2 Hangover control The permissible hangover time as a function of stimulus signal duration shall be within the mask shown in Figure28/G.763 for CCITT Signalling System No.5 and within the mask shown in Figure29/G.763 for speech and CCITT Signalling Systems Nos.6, 7 andR2D. FIGURE 28 y 29/G.763 = 10 cm It shall be possible to select the required type of hangover time mask. For voice-band data the hang- over time should be extended so that it is sufficiently long to bridge facsimile page changes. This time may be as long as 14s. 12.1.3 Interaction of transmit activity detector with echo control devices The threshold of the transmit activity detector shall not adapt to Gaussian noise level varia- tions which are due to the actions of echo suppressors or echo cancellers. This might be accom- plished, for example, by providing the transmit activity detector with a threshold inhibit signal from a receive activity detector when activity is present in the receive channel (see AnnexB.5. Special DCME networking considerations). 12.2 Data/speech discriminator The data/speech (D/S) Discriminator shall determine whether the activity on each IT in the DCME transmit unit is speech or data and provide a speech/data indication to the TCP function. An example of a data/speech Discriminator which satisfies the requirements specified in this section is given in AnnexB.3. The following requirements shall be met with the modem types and bit rates given in Table7/ G.763. 12.2.1 Output conditions The D/S Discriminator shall analyse the activity on each transmit IT and provide the follow- ing output conditions. The D/S Discriminator shall provide a continuous output condition indicating the presence of either speech or data on the IT. The current output condition shall be maintained upon termination of activity on the IT or until the output condition of a subsequent activity is determined. Upon system start-up or map change, the D/S discriminator shall be reset to voice. 12.2.2 Accuracy The missed detection probability of data as speech or speech as data shall be less than 0.5 per cent. 12.2.3 Response time The D/S Discriminator shall update its output condition within 200ms after any of the fol- lowing changes in the IT signal characteristics: – inactive-to-speech; – inactive-to-data; – speech-to-data; – data-to-speech. 12.2.4 2100 Hz tone detector The D/S Discriminator shall detect the presence of the V.25 echo control disabling tone by analysing signals on the transmit ITs. The function may be implemented separately but is here defined as part of the D/S discriminator. Requirements for a 2100Hz tone detector are given in AnnexB.3. 12.3 Signalling detector Functionally, the signalling detector shall detect the presence of CCITT Signalling System No.5 line signalling (2400Hz) on each transmit IT, provide a detection indication (signal detect/No detect) to the TCP function and enable the signalling hangover time mask (Figure28/G.763) for the duration of the signalling interval. Upon system start-up or map change, the Signalling Detector indi- cation shall be reset to no Detect. Requirements for a 2400Hz tone detector are given in AnnexB.4. R2D inter-register signalling does not need an extended hangover and shall be classified as voice. 12.3.1 Accuracy The probability of speech, voice-band data or noise being detected as CCITT Signalling Sys- tem No.5 signalling or the probability of signalling being detected as speech, voice-band data or noise shall be less than 0.5per cent. 12.4 Receive activity detector A receive activity detector may be used to recognize periods of activity on each received IT and provide an inhibit signal to prevent interaction of the transmit activity detector with echo control devices. Refer to §12.1.3. 13 DCME synchronization and echo control 13.1 DCME synchronization Timing synchronization of DCME can be achieved in many ways and care should therefore be taken in any implementation to ensure that the configuration adopted is correct. 13.1.1 Reference clock The DCME reference clock shall be derived from a source which meets the requirement of RecommendationG.811. For networks that entail one international destination, loop timing can be used as an alternative at one end of the link. The need for an internal reference clock for use under failure conditions is for further study. 13.1.2 Plesiochronous slips The slip rate shall not exceed the requirement of RecommendationG.822. Controlled slips at 2048kbit/s, on the trunk side shall be 2frames, controlled slips at 1544kbit/s on the trunk side and for 2048kbit/s and 1544kbit/s on the bearer side require further study. 13.1.3 Buffer sizes and locations Table8/G.763 indicates suitable buffer sizes and locations for the 2048kbit/s hierarchy for the various synchronization options which are detailed in AnnexB.6. A table for the 1544kbit/s hier- archy is under study. 13.1.4 Terminal synchronization The DCME terminal shall be capable of deriving its timing from any of the incoming digital links or from an external clock. When the synchronization is derived from the trunk receive side it is recommended that a fallback trunk receive synchronization source be provided. This is for the event of the primary synchronization link entering an alarm condition indicating a received line signal fail- ure, loss of frame alignment, AIS or receive BER ³10-3. Switching between primary and fallback sources shall be automatic. Note–Synchronization arrangements for special operation of DCME in tandem are under study. 13.2 Echo control Echo control is not considered to be part of the DCME Recommendation. A network echo control device integrated or external to the DCME and meeting or exceeding the requirements of RecommendationsG.165,G.164, or RecommendationG.161 shall be present on all TCs carrying speech serviced by a DCME. A lack of echo control on the circuits serviced by the DCME will degrade speech perfor- mance due to the increased speech activity factor resulting from the echo signal. Transmit activity detector/echo control device interactions are controlled by freezing the activity detector threshold in the presence of speech on the corresponding receive channel. 14 ADPCM encoders and decoders ADPCM encoders and decoders shall be capable of operation within the DCME at the fol- lowing bearer channel transmission rates: – 64kbit/s: 8 bit/sample transparent; – 40kbit/s: 5 bit/sample ADPCM; – 32kbit/s: 4 bit/sample ADPCM; – 24kbit/s: 3 bit/sample ADPCM; – 16kbit/s: 2 bit/sample ADPCM (optional). For 64kbit/s bearer channels (8-bit mode), the ADPCM encoders and decoders shall be bypassed. For 40kbit/s bearer channels (5-bit mode), 32kbit/s bearer channels (4-bit mode), 24kbit/s bearer channels (3-bit mode) and 16kbit/s bearer channels (2-bit mode), the ADPCM encoders and decoders shall be in accordance with RecommendationG.726 and shall operate in accordance with §§6.1.6 and7.1.4. Digital sequences (test vectors) for use in the verification of correct implementation of the ADPCM algorithms are available on flexible disks. Copies of the flexible disks may be obtained from the ITU. 15 Operations and maintenance functions The following operations and maintenance functions shall be performed at the DCME. Addi- tional operation and maintenance functions are under study: a) configuration of the DCME for operation in a network; b) traffic rearrangements under coordinated operator control; c) voice orderwire (VOW) communication to correspondent DCMEs; d) attendance to prompt maintenance alarms resulting from the channel check procedure, the continuous BER measurement, and other fault conditions; e) storage and display of status information pertaining to the freeze-out fraction, DLC opera- tion, channel check procedure, and control channel BER and fault analysis; f) redundancy switchover facility; g) display of statistical information and anomaly reports. The DCME should provide the following maintenance functions: a) Facilities for disabling (terminal out of service tests): – DSI: Digital Speech Interpolation; – LRE: Low Rate Encoding (ADPCM); – VBR: Variable Bit Rate Coding. b) Facilities for providing fixed connections of: – specific trunk channels to specific bearer channels, at 64kbit/s without interpolation, 40kbit/s without interpolation, 32kbit/s without interpolation and optionally at 24kbit/s or 16kbit/s without interpolation (see §4.2.1). c) Facilities for protected monitoring points (under study). 15.1 Configuration of the DCME for operation in a network Operation of DCME in a network will require bilateral or multilateral agreement between correspondents on the use of trunk and bearer channels. Table9/G.763 outlines the operational parameters on which bilateral or multilateral agreements are required. Operation of the DCME will also require configuration data which is of concern only to the local user. Table10/G.763 outlines the unilateral operational parameters. The DCME shall include a capability to permit the entry of configuration data into a back- ground mapping facility without interruption to service which is utilizing configuration data in a fore- ground map. The configuration data shall permit operator control of: a) Dynamically assigned transmit and receive trunk time slots by permitting semi-permanent TC to IT associations. TCs may be identified by digital group and time slot; ITs shall be identified by number (1through216); b) Pre-assigned transmit and receive trunk time slots by permitting semi-permanent TC-to-IT- to-BC associations. Pre-assignments of 24kbit/s bearer channels and optionally 16kbit/s for maintenance and 64kbit/s, 40kbit/s and 32kbit/s bearer channels for maintenance or traffic shall be possible. The number of pre-assigned channels for traffic need not be symmetrical between transmit and receive sides. c) The transmit and receive order wires by permitting semi-permanent IT to correspondent associations. d) The boundaries of the single (multi)-destination pool(s) for transmit and receive bearer frames (upper bound pool1, lower bound pool2) shall be selectable in increments of one 8-bit time slot. The system does not require that the pool(s) occupy the entire bearer frame. The bits in unused time slots should not be permitted to indicate an alarm condi- tion in normal operation (note). Note–Configuration and operation of DCME for special tandeming arrangement is for further study. e) Channel check permanent associations (see Table12/G.763). 15.2 System management functions 15.2.1 Transmission facilities Each terminal should monitor each incoming digital link for the following conditions or parameters and store separate cumulative counts of each type of event as required by users: – AIS, remote alarm indication; – loss of incoming signal, loss of frame alignment, reframe rate; – errored seconds, severely errored seconds; – slips, slip rate. 15.2.2 Terminal traffic handling performance The DCME terminals shall monitor and store records of the various parameters needed to evaluate the traffic handling performance being provided. These shall include the statistics given in Table11/G.763. 15.2.3 System statistics measurement Measurements and calculations of traffic statistics shall be done only on non-pre-assigned trunk channels which are defined in the configuration data. The DLC ON ratio for voice/voice-band data and the DLC ON ratio for 64kbit/s unrestricted traffic parameters shall be obtained separately for each destination. All other parameters shall be obtained separately for each transmit pool. The measurements of each parameter shall be made over an operator settable statistics time interval (STI). Each statistic shall be calculated once every 1.0minute interval with the accumulated data from every sampled DCME frame (e.g each 10th frame). The average over the STI shall be the average of the values calculated each 1.0minute interval during the STI within the range from 10minutes to 60minutes (in 10minute steps). The BC states that need to be considered for the calculation of the system statistics are speci- fied as follows: – Voice: The connected TC carries speech signals or in-band signalling or calling tones (and marginally active voice-band data when not yet recognized as such), extended with their corresponding hangover time (see Note1). – Data: The connected TC carries active voice-band data signals (including 2100Hz tone) recognized as such, extended with its corresponding hangover time (and marginally “voice” signals when not yet recognized as such. (See Note2). – Transparent: The connected TC carries a 64kbit/s unrestricted traffic call. – Disconnected: No TC is connected to this BC. – Pre-assigned: The BC is permanently assigned to a TC. Note 1–Once a TC has been declared voice or data and the corresponding hangover time of the connection has expired during inactivity, the TC is reputed to be declared initially as voice in both cases when activity resumes. Furthermore when the hangover time of a voice call has not expired, new activity in the BC is declared initially as voice. During low activity periods, after the above-mentioned hangover time expires, inactive voice TCs will still be connected and coded like active ones at the rate of 4bits/sample as long as overload BCs are not needed. (This is done to avoid front clipping when activity resumes on those TCs.) As a consequence, the average number of bits/sample for voice is significant only when the result is less than 4bits/sample. Note 2–When the hangover time of a data call has not expired, new activity in the BC is declared initially as data. The system statistics monitor will deliver the results of calculations relative to the following definitions. In the definitions, Nis the number of sampled DCME frames of the averaging period of 1.0minute. 15.2.3.1 bits/sample for voice Defined as the average number of encoding bits per sample for all connected TCs used for voice. The average should be calculated to two decimal places. 15.2.3.2 voice queue freezeout fraction (voice FOF) Defined as the ratio of competitive clip duration to voice spurt duration. The fraction may be determined as the ratio of the number of non-pre-assigned TCs classified as voice-active but not con- nected, to the total number of non-pre-assigned TCs classified as voice-active connected plus not con- nected. The ratio should be expressed as a percentage to three decimal places. 15.2.3.3 voice freezeout excess % of time voice FOF exceeds 0.5% when averaged over 1 minute given to 2 decimal places. 15.2.3.4 voice activity ratio Defined as the ratio of the number of non-pre-assigned TCs which are classified as voice- active, to the total number of non-pre-assigned TCs. The ratio is expressed as a percentage to the nearest integer. 15.2.3.5 DLC voice on ratio Defined as the ratio of the number of DCME frames during which DLC for voice/voice-band data (V/VBD) is ON, to the total number of DCME framesN. The ratio is expressed as a percentage to the nearest integer. 15.2.3.6 data queue freezeout fraction (data FOF) Defined as the ratio of the number of non-pre-assigned TCs classified as data-active but not connected, to the total number of non-pre-assigned TCs classified as data-active (connected + not connected). The ratio should be expressed as a percentage to three decimal places. 15.2.3.7 data activity ratio Defined as the ratio of the number of non-pre-assigned TCs which are classified as data- active, to the total number of non-pre-assigned TCs. The ratio is expressed as a percentage to the nearest integer. 15.2.3.8 64 kbit/s failed seizures ratio Percentage of 64kbit/s on demand seizure (S64) attempts that receive a 64kbit/s negative acknowledgement (S64 NACK) from the DCME given as an integer. 15.2.3.9 64 kbit/s connected ratio Defined as the ratio of the number of non-pre-assigned TCs which are classified as 64 kbit/s connect-called plus 64kbit/s connect-calling, to the total number of non-pre-assigned TCs. The ratio is expressed as a percentage to the nearest integer. 15.2.3.10 DLC 64kbit/s on ratio Defined as the ratio of the number of DCME frames during which DLC for 64kbit/s unre- stricted is ON, to the total number of DCME frames N. The ratio is expressed as a percentage to the nearest integer. 15.2.3.11 average BER Average BER, as measured on the receive control channel 15.2.3.12 BER excess % of time average BER exceeds 1 ´ 10-3 when averaged over 1.0 minute given as an integer. 15.2.3.13 Severely errored seconds ratio (see RecommendationG.821) It is important that the voice and data performance are measured separately for the following reasons: – the effect of freezeout and clipping is different on voice calls and data calls; – the DCME process gives priority to assigning activity classed as data and hence the freeze- out figures for the data queue should always be less than the corresponding freezeout fig- ures for the voice queue. The summary statistics calculated at the end of the STI shall be output to a statistics data file on a secure storage medium (e.g.non-volatile RAM, hard disk,etc.). 15.3 Synchronizer The state of synchronization of each primary group interface, the selected clock source, and the times of any failure or changes of clock source should be monitored. 15.4 Communication links The condition of all communication links should be monitored to detect failures as far as practicable, including: – control channels; – ISC-DCME interface; – man-machine interface. 15.5 Reports The terminal should: a) at operator defined intervals, or when set parameters have been exceeded, or as a worst 15minutes report for any 24hour period, file operator selected parameters from those monitored and stored plus header information such as terminal identification, date and measurement period covered by the file; b) compare selected parameters, status or measurements with predetermined conditions; c) upon detection that predetermined conditions have been met or exceeded for a given period of time, take the necessary action(s) which may include: 1) filing of an anomaly report; 2) transmission of alarm signals; 3) blocking all new calls due to failure; 4) switching to standby, if available; 5) total shut down of the terminal. 15.6 System configuration The terminal shall include a non-volatile back-up memory containing a copy of the latest configuration of the DCME, for use in failure situations. A non-working spare copy should also be provided to allow changes in configuration to be made without impact upon service security. In cases where cluster operation of terminals is used to provide additional service security, means must be pro- vided for the standby terminal to adopt the configuration of the working terminal which it is intended to replace. The configuration information shall include details of trunk side interface channel connec- tions, modes of operation of any pre-assigned channels, and restrictions in force to any destination or on any block of circuits (e.g.limit on the number of 64kbit/s calls) and synchronization source. 15.7 Failure protection strategy Upon detection of service affecting conditions the DCME shall take the appropriate actions to protect existing traffic, such as switching to fallback timing sources or fallback units or where redundancy is provided, transmission of DLC signals, disconnection of failed circuits, or transmission of any appropriate alarm conditions. 15.8 Coordinated traffic rearrangements A map change handler (MCH) function shall be provided which the operator can manually disable or enable. When disabled, it shall not be possible to command a map switch. When enabled, it shall be possible to manually command a map switch. The coordination of map changes may be per- formed between correspondents by voice orderwire. When the MCH is enabled, the channel check procedure shall be inhibited and the DLC ON condition shall be automatically sent toward the local TCH and the local SCI. The MCH enabled condition shall be terminated by operator selection of either MCH dis- abled or a map change command. Upon disabling, the channel check procedure shall restart and the normal DLC conditions shall apply as defined in §9. During a traffic rearrangement, the BC, IT and data word contents in the CC shall be set to0. When such an assignment message is received, no action shall be taken based on the assignment mes- sage contents. However, the operator shall be notified. After the map change command is given, the foreground and background maps shall be switched. The MCH shall initiate the MCH related processes associated with the DCME transmit unit, the DCME receive unit and the 64kbit/s circuit handler after determining the parameters required for their operation in accordance with the new foreground map (note). The channel check procedure shall restart and the normal DLC conditions defined in §9 shall apply. Note–This function shall also initiate the MCH related processes which are required at DCME system start-up. 15.9 Voice orderwire (VOW) It shall be possible to connect a VOW from the local DCME to any corresponding DCME by accessing an ADPCM channel in competition with voice traffic. The voice signal and signalling tone shall be PCM encoded using the companding law employed at the trunk interface. The off-hook con- dition at the calling end shall generate the following signalling tone: – frequency: 2000Hz ± 10Hz; – duration: 1 s ± 0.1 s; – level: -6 dBm0 ± 1 dB. ITs numbered 232, 233, 234 and 235 shall be used to route the VOW to a maximum of four corresponding DCMEs. Detection of the signalling tone pertaining to one of the destination directed ITs numbered232, 233, 234 and235 shall alert the operator of a pending VOW call. The destination number cross-reference for the VOW ITs is presented in Table12/G.763. 15.10 In-service monitoring 15.10.1 Continuous BER measurements Continuous BER measurements shall be performed on the CC. The BER measurement shall make use of the error syndrome of the (24/12) rate 1/2 Golay code specified for protection of the CC in §11. When the CC BER exceeds1 in 103 (prior to correction) on the basis of a one minute mea- surement interval, consequent actions shall be taken in accordance with Table13/G.763. When the CCBER exceeds 1in 105 (prior to correction) on the basis of a 60s measurement interval, a high BER condition shall be declared for use by the channel check procedure. (The CCBER threshold val- ues are under study.) PAGE BLANCHE POUR TABLEAU 13/G.763 PAGE BLANCHE POUR TABLEAU 13/G.763 (cont.) PAGE BLANCHE POUR TABLEAU 13/G.763 (end) 15.10.2 Channel check procedure The channel check procedure provides in-service verification of IT/BC channel assignments between DCME transmit units and DCME receive units. 15.10.3 Test port A capability shall be provided to connect any IT to a TC test port for the purpose of injecting or receiving externally generated test signals. For this purpose, the test port may either be subject to DSI or may be a pre-assigned64, 40,32, or optionally 24or 16kbit/s channel. 15.11 Fault conditions and consequent actions The philosophy of fault conditions and consequent actions from the point of view of mainte- nance of digital networks is consistent with that contained in the G.700-Series Recommendations in the Red Book, VolumeII–FascicleIII.3, Malaga-Torremolinos,1984. Alarm conditions and the appropriate consequent actions are defined as follows: 15.11.1 Normal traffic carrying operating conditions The following shall apply when the DCME is carrying traffic, when no digital links are exhibiting fault conditions and when the DCME is also not exhibiting a fault condition: a) the absence of alarm indications on the DCME terminal shall indicate a normal condition; b) the means used on the DCME terminal to indicate operating modes or to provide routine information shall be of such form, colour or type that they cannot be confused with alarm conditions. 15.11.2 Fault conditions (see Note) The DCME unit shall detect the following fault conditions: a) Failure of the incoming trunk primary group(s) – the fault conditions are loss of incoming signal, loss of frame alignment or BER detected in frame alignment signal greater than 1 in 103 as defined in RecommendationG.736, for 2048kbit/s links, and RecommendationG.734 for 1544kbit/s links. b) Alarm indication from the remote end, received from the local ISC. c) AIS detected on incoming primary trunk groups and/or abnormal (alarm) conditions of associated incoming trunk circuits detected or loss of incoming supervision channel. The circuit supervision function may be handled by the SCI. d) Failure of the incoming bearer signal – the fault conditions are loss of incoming signal, loss of frame alignment or BER detected in frame alignment signal greater than 1 in 103 as defined in RecommendationG.736. e) Bit error rate detected on the CC according to §15.10 exceeding 1 in 103. f) Loss of DCME frame or DCME multiframe alignment. (The time interval between recogni- tion of an errored condition and a fault declaration is under study, e.g 2.5s.) g) Alarm indication from the remote end, received from correspondent DCME unit(s) [see §15.11.3,f)]. h) Alarm indication from the remote end received on any incoming bearer [see §15.11.3,g)]. i) Indication of fault in affected TCs detected on IT related alarm bits in the incoming CC data word [see §15.11.3,e)]. j) DCME failure or DCME power failure. Note–Optionally, a time delay selectable up to three seconds maximum shall be provided before alarms are initiated or indications are transmitted in fault conditionsa, b,c and/ord of §15.11.2. 15.11.3 Explanation of consequent actions Following the detection of a fault condition, appropriate actions shall be taken as specified in Table13/G.763. The consequent actions are listed below: a) Backward alarm indication to the remote end (towards local ISCs) generated. For 2048kbit/s primary multiplex trunks, this is done by changing bit3 of channel time slot0 from state0 to state1 in those frames not containing the trunk frame alignment signal (see RecommendationG.732). For 1544kbit/s primary multiplex trunks, this is done by forcing bit2 in every channel time slot to the value0 or by modifying the S-bit for the 12frame multiframe or by sending a frame alignment alarm sequence for the 24frame multiframe (see RecommendationG.733). This consequent action shall be effected as soon as possible. The transmit activity detector shall be disabled for the ITs which are associated with the faulty trunk interface and shall set the associated activity indication to inactive (INACT). b) Alarm indication signal applied on relevant trunk circuits towards local ISC(s), e.g.by AIS on relevant time slots and by means of the out-of-service message through the SCI. c) AIS on primary trunk groups (all time slots). d) Prompt maintenance alarm indication generated to signify that performance is below acceptable standards and maintenance attention is required locally. When the AIS (see Note below) is detected, the prompt maintenance alarm indication, associated with loss of frame alignment, excessive error rate in the frame alignment signal and in the bearer assignment message (see §15.11.2,a), d) ande)), and with the loss of the synchronous data word multiframe alignment (see §15.11.2) shall be inhibited, while the rest of the consequent actions associated with these four fault conditions shall be followed in accor- dance with Table13/G.763. Note–The equivalent binary content of the alarm indication signal (AIS) on the trunk groups or time slots is a continuous stream of binary 1s. The strategy for detecting the presence of the AIS will be such that with a high probability the AIS is detectable even in the pres- ence of random errors having a mean error rate of 1 in 103. Nevertheless, a signal in which all the binary elements, with the exception of the frame alignment signal, are in state1, will not be taken as an AIS. e) Indication of fault in affected TCs generated on the corresponding ITs and forwarded to the correspondent DCME receive unit on a per channel basis by setting the appropriate IT related alarm bits in the CC data word to state1, (see Table5/G.763). f) Alarm indication to the remote end DCME receive unit is generated by changing the appro- priate remote alarm indication bit(s) of the CC data word to state1, (see Table5/G.763). This will be effected as soon as possible. g) Backward alarm indication to the remote end (towards remote ISCs) generated. For 2048kbit/s primary multiplex trunks, this is done by changing bit3 of Time Slot0 from the state0 to the state1 in those frames not containing the bearer frame alignment signal (see RecommendationG.732). For 1544kbit/s primary multiplex trunks, this is done by forcing bit2 in every channel time slot to the value0 or by modifying the S-bit for the 12frame multiframe or by sending a frame alignment alarm sequence for the 24frame multiframe (see RecommendationG.733). This consequent action shall be effected as soon as possible. h) AIS on bearer signal (all time slots). 15.11.4 Alarm considerations specific to R2D line signalling When alarm conditions occur which require the signalling bits for the affected ITs to be set a=b=1 this shall be specifically notified to the transmit R2 USM for each affected IT. When alarm conditions are cleared, the new signalling state conditions shall be notified as state changed from a=b=1, for the affected ITs, in the normal manner to the R2 USM. When certain alarm conditions occur there is a danger of false activity being detected. For these conditions the activity detector should be disabled for the ITs in question, and re-enabled when the alarm condition has been cleared. The fault conditions and consequent action for R2D line signalling are summarized in Table14/G.763. PAGE BLANCHE POUR TABLEAU 14/G.763 PAGE BLANCHE POUR TABLEAU 14/G.763 15.11.4.1 R2D fault conditions The DCME unit shall detect the following fault conditions: a) Failure of the incoming trunk primary group(s). The fault conditions are loss of incoming signal, loss of frame alignment, BER greater than 1 in 103 detected in frame alignment signal, as defined in RecommendationG.736. b) AIS detected in incoming primary trunk groups. c) Loss of multiframe alignment (loss of incoming supervision channel) as defined in RecommendationG.732. d) Remote alarm indication from local ISC (bit 3, TSO; bit 6, TS16). The alarm conditions are bit 3 TSO set to 1 in those frames not containing the frame alignment signal and bit6 TS16 set to 1 in frame0 of the PCM multiframe, as described in RecommendationG.704. e) Failure of the incoming bearers primary group(s). The fault conditions are loss of incoming signal, loss of frame alignment, BER greater than 1 in 103 detected in frame alignment signal, as defined in RecommendationG.736. f) AIS detected on incoming primary bearer group(s). g) Remote alarm indication received on a bearer (bit 3, TSO). The alarm condition is bit 3 TSO set to 1 in those frames not containing the frame align- ment signal, as described in RecommendationG.704. h) CC decoder, high BER alarm. The high BER alarm is raised when the BER in the assignment channel, as defined in §15.10.1, exceeds 1 in 103 prior to correction. i) Loss of DCME multiframe or DCME frame alignment. DCME frame and DCME multiframe alignment alarms shall be raised following loss of the unique word sequence, as defined in §§11.2 and11.2.1, in the synchronous bit pat- tern of the CC. j) Remote bearer alarm The alarm condition is the appropriate remote alarm indication bit of the CC asynchro- nous word set to1, as defined in Table5/G.763. k) Remote IT alarm received in the asynchronous data word. The alarm condition is the relevant IT identification bit set to 1 in the asynchronous data word (see Table5/G.763). l) DCME functional or power supply failure. Service affecting any internally detected fault condition. 15.11.4.2 R2D consequent actions Further to the detection of a fault condition, appropriate actions shall be taken as specified in Table14/G.763. However, if redundant equipment is provided and detection of a fault condition is effectively removed by an automatic switchover, prompt maintenance alarm (if applicable) shall be deferred and other consequent actions shall not be taken. a) Backward alarm indication (bit 3 TSO) towards local ISC. This is done by setting bit 3 TSO to 1 in those frames not containing the frame alignment signal. This signal shall not be sent if the fault condition is AIS detected. b) Backward alarm indication (bit 6, TS16) towards local ISC. This is done by setting bit 6 of TS16 to 1 in PCM frame0 of the multiframe. c) a=b=1 towards local ISC in circuits concerned. The corresponding a and b bits for the affected circuits in TS16 of frames 1 to 15 of the PCM multiframe shall be set to1. Refer to RecommendationG.704. d) AIS towards local ISC. AIS = alarm indication signal as described in RecommendationG.704. e) Activity detector disabled. The activity detector output shall be set to the inactive state for the ITs concerned and remains in this state as long as the disabling applies. f) R2D line signalling bits, a=b=1. The R2 USM local array a and b bits shall be set to 1 for the relevant circuits (see §15.11.4.1). g) Asynchronous word. IT fault bit set in data word. For the affected circuits the relevant IT related circuit supervision bits of the asynchro- nous data word shall be set to 1. Refer to Table5/G.763. h) Asynchronous word. Bearer alarm. For the affected bearer the relevant backward bearer alarm of the asynchronous data word is set to1. Refer to Table5/G.763. i) Prompt maintenance alarm An audible/visual alarm indication to alert the operator to the presence of a fault condi- tion. To be specified by the users. 16 Glossary ADPCM Adaptive Differential pulse code modulation AIS Alarm indication signal BC Bearer channel BER Bit error ratio BMI Bit map implementation process B8ZS Bipolar eight zero substitution UCA Capacity available CC Control channel UCNA Capacity not available DAF Dynamic assignment function DCME Digital circuit multiplication Equipment DCMG Digital circuit multiplication Gain DCMS Digital circuit multiplication System DDI Direct digital interface DEC Decoder control process DEMUX Demultiplex DLC Dynamic load control DNI Digital non-interpolated DSH Dual seizure handling DSI Digital speech interpolation DW Data word D/S Data/speech ENC Encoder control process FDX Full duplex F-bit Framing bit FOF Freeze-out fraction HDX Half duplex HL High load HSC Hangover control and signal classification process IDR Intermediate data rate IG Interpolation gain IPS Input processing and service request generation block ISC International switching centre ISUP ISDN User Part IT Intermediate trunk LL Low load LRE Low rate encoding LSB Least significant bit MCH Map change handler MOS Mean opinion score MSB Most significant bit MUX Multiplex NRZ Non-return-to-zero O&M Operations and maintenance QDU Quantization distortion unit QPSK Quadrature phase shift keyed RAG Request handling & assignment information generation process RCP Receive channel processing block RUD Receive channel status update and overload channel decoding process SBC SC bit map creation process SCI Switching centre interface SRH Service request handling block SS Signalling system STI Statistics time interval TC Trunk channel TCH Transparent circuit handler TCP Transmit channel processing TDMA Time division multiple access TG Transcoding gain TMN Telecommunications management network TS Time slot TTF Test time frame USM User signalling module UW Unique word VBR Variable bit rate VOW Voice orderwire ZBTSI Zero byte time slot interchange ZCS Zero code suppression List of internal/external messages/indications AD64 Activate DLC for 64-kbit/s traffic ADVD Activate DLC for voice/voice-band data traffic DD64 De-activate DLC for 64-kbit/s traffic DDVD De-activate DLC for voice/voice-band data traffic R64 Release 64-kbit/s circuit R64Ack Release 64-kbit/s circuit Acknowledged S64 Seizure/Select 64-kbit/s circuit S64Ack Seizure/Select 64-kbit/s positive Acknowledged S64NAck Seizure/Select 64-kbit/s Negative Acknowledged SA Capacity for speech available SNA Capacity for speech not available UCA Capacity for 64-kbit/s unrestricted available UCNA Capacity for 64-kbit/s unrestricted not available VDA Capacity for 3.1-kHz data available VDNA Capacity for 3.1-kHz data not available