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 permanent 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 Recommendations by the members of CCITT between Plenary Assemblies is covered by the procedure 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 December 1990.

___________________

CCITT  NOTE
	In this Recommendation, the expression “Administration” is used for conciseness to indicate both a telecommunication Administration and a recognized private operating agency.

ã  ITU  1991
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 writing 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 equipment and systems, and as a base document for the specification of digital circuit multiplication equipment (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 capability 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 telecommunications 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 30 to 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 techniques.
	The DCME provides a nominal 5 : 1 reduction in the transmission capacity required to carry various mixtures of speech, voice-band data and 64 kbit/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 64 kbit/s, e.g. either 40 kbit/s, 32 kbit/s, 24 kbit/s, or optionally 16 kbit/s. Conversion between speech signals encoded in PCM at 64 kbit/s and those encoded in ADPCM must be carried out by means of transcoding processes given in Recommendation G.726.
2.4	variable bit rate (VBR)
	The capability of the encoding algorithm to dynamically switch between either 32 and 24 kbit/s or also optionally between 24 and 16 kbit/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 than 1.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 Recommendation G.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 2048 kbit/s system.
	Note 2 – A bearer channel may have any of the following instantaneous bit rates: either 64, 40, 32, 24, or optionally 16 kbit/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 4 wire 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 2048 or 1544 kbit/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 messages. 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 number 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 32 kbit/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 channels 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 encoding 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 effectively 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 32 kbit/s portion of Recommendation G.726 is used, the TG will equal 2. When no transcoding is used the TG will equal 1. When overload channels are created the TG will be greater than 2.
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 independent 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 associated with a different destination.

2.29	multi-destination mode
	A DCME operational mode where traffic is exchanged between more than two (2) corresponding 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 designated 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 hangover 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 elimination.
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 2048 kbit/s interfaces, the channel side (bearer) interface to/from the DCME shall be based on the 2048 kbit/s interface.
	For operation between Administrations using 2048 kbit/s interfaces and Administrations using 1544 kbit/s interfaces, the channel side (bearer) interface to/from the DCME will be based on the 2048 kbit/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 1544 kbit/s or the 2048 kbit/s interface dependent on bilateral agreement.
	There may be operational difficulties with ISC/DCME interworking depending on whether the DCME is type 1, where the DCME cannot communicate with the ISC, or type 2, where it can, as defined in Recommendation Q.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 64 kbit/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 interface as defined in Table 1/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 either 32, 24, or optionally 16 kbit/s dependent on traffic loading. If the optional 16 kbit/s overload feature is activated and being used, the bit rate of the bearer channels provided for speech is 24 kbit/s or 16 kbit/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 40 kbit/s and are protected against bit reduction and clipping.
	c)	64 kbit/s unrestricted traffic may be connected on demand to bearer channels transparently (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 provision 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 24 kbit/s or 16 kbit/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 and 7 can be accommodated through 64 kbit/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, R1 USM and R2 USM (see Note 1 of § 3.2 above). Requirements have been defined for an R2 USM.
TABLE  1/G.763
DCME traffic handling
Bearer service 	Dynamic assignment 	Pre-assignment	
Speech

3.1 kHz Audio
(Voice-band data
(Note 1)

64 kbit/s 
unrestricted

Alternate speech
64 kbit/s

	32 kbit/s ADPCM  with DSI

24 kbit/s ADPCM  with DSI
optionally 16 kbit/s
ADPCM  with DSI

40 kbit/s ADPCM

64 kbit/s on-demand
(Note 2)

64 kbit/s on-demand
and 32/34 kbit/s (and optionally
16 kbit/s) ADPCM with DSI
(Note 3)	32 kbit/s ADPCM

(Note 4)

40 kbit/s ADPCM
or
32 kbit/s ADPCM 

64 kbit/s
Pre-assigned

64 kbit/s
Pre-assigned	
Note 1 – 40 kbit/s ADPCM will accommodate voice-band data at rates £ 9.6 kbit/s. 32 kbit/s ADPCM will accommodate voice-band data at rates £ 4.8 kbit/s.
Note 2  – Subject to the provision of a dedicated control system to/from the ISC.
Note 3 – Subject to the provisions for in-call modification from the ISC.
Note 4 – 24 or 16 kbit/s ADPCM pre-assignment may be used for maintenance purposes only.
Note 5 – Special arrangements for prevention of quantization distortion unit (QDU) accumulation when DCMEs are operated in tandem are under study.

	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 64 kbit/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 30 ms. The total delay associated with the establishment of dynamically assigned ADPCM encoded bearer channels by the receive DCME shall not exceed 15 ms. The delay values exclude the effects of Doppler and plesiochronous buffers and exclude the delays associated with the establishment and disestablishment of demand assigned 64 kbit/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 Table 2/G.763.
TABLE  2/G.763
DCME multiple destination capability
for multi-clique and multi-destination modes
a)  Transmit
	Total No.
destinations	No. of pools
in bearer	No. of
destinations
in  pool	
Multi-clique	1
2	1
2	1
1, 1	
Multi-destination	4 max.	1
2	1 to 4
111 to 3, 1	

b)  Receive
	Total No.
of origins
	No. of received 
bearers
	No. of pools in 
each bearer
	
Multi-clique	2 max.	1	1 or 2	
Multi-destination	4 max.	4 max.	1	

4.1.1	Point-to-point mode
	See Figure 1/G.763.
4.1.1.1	Point-to-point
	Using Figure 1/G.763 for reference, the transmit side DCME concentrates N trunk channels at 64 kbit/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 N trunk 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. Figure 2/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 tandem. 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 channels, 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 destination 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 64 kbit/s trunk channels to 64 kbit/s bearer channels in the pool (8 bits within the bearer frame). The number of pre-assigned 64 kbit/s trunk channels shall be preset under operator control from zero to the maximum number of complete 8 bit time slots within the pool in increments of one 64 kbit/s channel.
	It shall be possible to pre-assign 64 kbit/s trunk channels to 40 kbit/s bearer channels in the pool (5 bits within the bearer frame structure). The number of pre-assigned 40 kbit/s bearer channels shall be preset under operator control from zero to the maximum determined by the pool size in increments of one 40 kbit/s channel.

	It shall be possible to pre-assign 64 kbit/s trunk channels to 32 kbit/s bearer channels in the pool (4 bits within the bearer frame). The number of pre-assigned 32 kbit/s bearer channels shall be preset under operator control from zero to a maximum determined by the pool size in increments of one 32 kbit/s channel.
	As an option it shall be possible to pre-assign 64 kbit/s trunk channels to 24 kbit/s or 16 kbit/s bearer channels in the pool. Each 24 kbit/s or 16 kbit/s bearer channel will occupy the most significant three bits or two bits respectively of a 32 kbit/s pre-assigned bearer channel and will be used for maintenance purposes only. The number of pre-assigned 24 kbit/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 32 kbit/s bearer channel.
4.2.2	Dynamic assignment
	The DCME shall be capable of assigning on-demand 64 kbit/s unrestricted traffic to 64 kbit/s bearer channels in the pool (8 bits within each bearer frame) using an out-of-band control facility between the ISC and the DCME for seizure/release of 64 kbit/s bearer channels as defined in § 5. The provision of the ISC control facility is at the users' option. The transmit and receive assignment processes are described in §§ 6, 7 and 8.
	The DCME shall be capable of dynamically assigning voice traffic within 64 kbit/s trunk channels to bearer channels at bit rates of 32, 24, and optionally 16 kbit/s in each pool (4 bits, 3 bits or 2 bits within each bearer frame). The transit and receive assignment processes are described in §§ 6 and 7.
	The DCME shall be capable of dynamically assigning voice-band data traffic within a 64 kbit/s trunk channel to 40 kbit/s bearer channels (5 bits within each bearer frame). The transmit and receive assignment processes are described in §§ 6 and 7.
5	Interface requirements
	The DCME shall be interconnected with a local or remote ISC(s) by means of the trunk interface 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 2048 kbit/s primary multiplex streams or nine 1544 kbit/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 corresponding DCMEs.
	In the case of interworking between the 1544 kbit/s and 2048 kbit/s hierarchies on the same DCME, it is recommended in Recommendation G.802 that the bearer system be 2048 kbit/s.
	There may be operational difficulties with ISC/DCME interworking depending on whether the DCME is type 1, where the DCME cannot communicate with the ISC, or type 2, where it can, as defined in Recommendation Q.50.
5.1	Transmission interface: trunk side
5.1.1	Trunk side interface at 2048 kbit/s
a)	The electrical characteristics shall comply with Recommendation G.703. The test load impedance shall be either 75 W unbalanced or 120 W balanced depending on the user requirement.
b)	The frame structure shall comply with Recommendation G.704.
c)	The encoding law for voice frequency signals shall conform to the A-law system described in Recommendation G.711.

5.1.2	Trunk side interface at 1544 kbit/s
a)	The electrical characteristics shall comply with Recommendation G.703. The line code adopted shall be either AMI or B8ZS depending on the user selection.
b)	The frame structure shall comply with Recommendation G.704. The multi-frame size shall be either 24 frames or 12 frames depending on the user selection.
c)	The encoding law for voice frequency signals shall conform to the m-law system described in Recommendation G.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 2048 kbit/s interface on the transmit side and one 2048 kbit/s interface on the receive side.
	For the multi-destination mode, the bearer interface shall consist of one 2048 kbit/s interface on the transmit side and one to four 2048 kbit/s interfaces on the receive side.
5.2.1.2	Electrical characteristics
	The electrical characteristics shall comply with Recommendation G.703. An optional non-return-to-zero (NRZ) electrical interface may be provided for special applications. The test load impedance shall be either 75 W unbalanced or 120 W balanced depending on the user requirement.
5.2.1.3	Bearer frame structure
	The bearer frame structure shall comply with Recommendation G.704. Time slot 0 shall be used as recommended in G.704 and time slots 1 to 31 shall carry control channels and traffic according 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 1544 kbit/s interface on the transmit side and one 1544 kbit/s interface on the receive side.
	For the multi-destination mode, the bearer interface shall consist of one 1544 kbit/s interface on the transmit side and one to four 1544 kbit/s interfaces on the receive side.
5.2.2.2	Electrical characteristics
	The electrical characteristics shall comply with Recommendation G.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 64 kbit/s unrestricted channel transmission, robbed-bit zero code suppression (ZCS) line coding techniques are prohibited on the 1544 kbit/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 Recommendation G.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 Recommendation G.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 Recommendation Q.50).
5.3.1	DCME-ISC signalling interface functions
	The following groups of functions are defined in Recommendation Q.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 64 kbit/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 64 kbit/s circuits, the provision of 64 kbit/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 maintenance 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 Figure 4/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 characteristics of the chosen DCME‑ISC signalling system, all of the following required external information 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 64 kbit/s unrestricted					UCA
available
Capacity for 64 kbit/s unrestricted					UCNA
not available
Seizure/select 64 kbit/s circuit					S64
Seizure/select 64 kbit/s positive					S64Ack
acknowledged
Seizure/select 64 kbit/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 64 kbit/s circuit handler (TCH), the dynamic load control (DLC) function and the operations and maintenance function is described in §§ 8, 9 and 15, respectively.
	The format of all signals and messages is dependent upon the internal DCME design implementation 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 signalling 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 interface 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 Recommendations G.704 and G.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 Recommendation G.803 should be included. In the case of a serial alarm interface it is recommended to provide as a minimum the following 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 Recommendation G.703, § 10.3. The test load impedance shall be either 75 ohms unbalanced or 120 ohms balanced depending on the user requirement.
5.7.2	DCME working with 1544 kbit/s transmission interfaces
	The timing is normally derived from an incoming digital link at 1544 kbit/s complying with Recommendation G.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 Recommendation G.704. The bearer structure shall contain 32 consecutively numbered 8 bit time slots, from 0 to 31. Time slot 0 shall be used for frame synchronization and special functions in accordance with Recommendation G.704. Time slots 1 through 31 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.
	Sixteen 125 msec bearer frames constitute one 2.0 ms DCME frame. The DCME frame is not required to be aligned with the multiframes defined in Recommendation G.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 Recommendation G.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 8 bit time slots, from 1 to 24. The F-bit shall be used in accordance with Recommendation G.704. Time slots 1 through 24 shall be used to carry the DCME control channel(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.0 msec DCME frame. The DCME frame is not required to be aligned with the multiframes defined in Recommendation G.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 Figure 5/G.763 for the 2048 kbit/s structure and Figure 6/G.763 for the 1544 kbit/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 (2048 kbit/s structure) or TS24 (1544 kbit/s structure). The upper boundary 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 contiguous 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 and p the total number of 4-bit slots in the pool, excluding the control channel. This numbering scheme is shown in Figures 5/G.763 and 6/G.763. The BC number contained in the assignment message can either be in the range 1 through 61 (normal BC numbering range) or in the range 64 through 83 (overload BC numbering range). If the optional 2 bit encoding mode is available and enabled, the overload BC numbering range is from 64 to 124. BCs in the normal range may consist of either 8, 5, 4, 3, or optionally 2 bits. 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 either 4, 3, or optionally 2 bit 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 64 kbit/s ITs. The BC number in the assignment message indicates the bearer BC (even number) which carries the first 4 bits (nibble) of the 8 bit sample. The second nibble is carried by the next higher BC. Refer to Figure 7/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 4 bits 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 constitutes 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 Figure 8/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 message 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 message 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 Figure 9/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 3 or 4 bits as determined by the DCME processes. Changes from 3 to 4 bit encoding (and vice versa) will occur randomly for the purpose of voice quality equalization over the ensemble of voice ITs. The BC number in the assignment message has no direct correspondence to any bearer BC. Refer to Figure 10/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 overload 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/2 bit overload procedure (§ 6.1.7.2). This procedure parallels the 4/3 bit 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 32 kbit/s ITs can be pre‑assigned.
	The optional 24 kbit/s or 16 kbit/s pre-assigned channels intended for maintenance purposes will occupy the most significant 3 or 2 bits respectively of the 32 kbit/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 64 kbit/s IT, the BC must be even numbered (the use of the next higher BC for this 64 kbit/s IT is implied). A sufficient number of Bit Banks must be pre-assigned to provide the 5th bit for the pre-assigned 40 kbit/s channels.
	The bearer BCs carrying 40 kbit/s pre-assigned ITs shall be contiguous starting from bearer BC No.1. The lowest bearer BC numbers shall be used for the Bit Banks required for 40 kbit/s pre-assigned ITs, followed by the pre‑assigned 40 kbit/s BCs.
	It is recommended that the pre-assigned 32 kbit/s ITs (other than bit banks) and the pre-assigned 64 kbit/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 dynamically 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, 64 kbit/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 2 ms 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 transmit side structure which satisfies the interaction requirements specified in this section is given in Annex A.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 consequence 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 samples are dynamically placed in the DCME output bearer frame at specific BC locations under the control 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 information 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 and 5.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 function 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 64 kbit/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 classified 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 procedural 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 process, 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 process, 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 64 kbit/s assignment queue.
6.1.4	Service request implementation
	The service request implementation function examines the service request queues and generates 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 where n is a variable which may be selected by the user. For optional R2 USM, DCME frames 0, 8, 16, 24, 32, 40, 48 and 56 of the DCME multiframe shall include 20 bits 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 64 kbit/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 64 kbit/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 64 kbit/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 (number k) shall be checked to determine whether it is even or odd. If k is even, the next higher BC (number k + 1) shall be examined. If k 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 64 kbit/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 accommodated (8 bits 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 64 kbit/s channel requires that existing ITs be reassigned to different BCs in order to make room in the DCME bearer frame for the 64 kbit/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 64 kbit/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 4 bit 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 4 bit 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 Table 3/G.763.
TABLE  3/G.763
Criteria for bit bank creation/deletion 
a)  Creation of bit bank
(At new data channel assignment)			

Data BC
Available
	Yes

No	Bank not required

Bank required if

Bannb < nd (Note 1)
Bannb < 4d (Note 2)	
b)  Deletion of bit bank
(Note 3)			
nb  ³ nd + 1
nb  ³ 4d + 1		Delete highest
numbered bank	
Note 1 – nd = No. of data channels in use and requested (pre-assigned and dynamic assigned).
Note  2 – nb = No. of banks in use.
Note 3 – If bank was just created, wait two DCME frames before applying deletion criterion. If during the 2 DCME frame wait period a USM signalling message is sent, wait one additional DCME frame.

	The request at the top of the data assignment queue shall be addressed. First, it shall be determined 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 40 kbit/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 refreshment 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 BC No. 64 to the highest number permitted). Pre-assigned BCs shall not be refreshed. Each dynamically assigned 64 kbit/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 previously connected IT is made, the ADPCM encoder currently associated with the IT shall be maintained.
	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 processes. 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 3 bit and 4 bit 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/2 bit overload channel creation procedure may be used. This procedure, similarly to the 4/3 bit 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 (3 bit and 2 bit 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 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.
	Data list – This list contains all BC numbers which are connected to data channels. At initialization 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 Table 3/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 position 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 position 1;
c)	LSB of BC number in pre-assigned 40 list position 5: MSB of BC number in bank list position 2.
	This procedure is followed until the BC numbers in the pre-assigned 40 list 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 is 0, overload channel creation 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 overload range that will be carried at four bits per sample shall be computed as follows:
			N4 = Integer  - Nov ´ 3
	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 0 to Nv - 1 and from 0 to 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 position Pov shall be marked as 4 bit channels. The remaining BCs of the overload list shall be marked as 3 bit channels.
	The 4/3 bit mode of the first BC in the overload list shall be checked to determine whether the 3 bit or 4 bit mode is used. If the mode is 3 bit, the BCs stored in the voice list at the first three locations, starting from the list position, Pv, shall be set to 3 bit 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 modulo 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 and d) 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 3 bit channels, the remaining ones as 4 bit channels. An example of the procedure is illustrated in Figure 11/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:
			N3 = Integer  - Nov ´ 2
	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 0 to Nv-1 and from 0 to 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 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 position Pov, shall be marked as 3 bit channels. The remaining BCs of the overload list shall be marked as 2 bit 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 2 bit channels. The remaining BCs of the voice list shall be marked as 3 bit channels (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 item b) changes and item c) 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 Figure 13/G.763.
	Note – In some cases the second bit of BC in voice list, indicated above, may not be available depending on the value of N2, in which case the sequence is compacted upwards.
Figure 12/G.763 = 9,5 cm

Assumptions	Computed parameters	
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.

No. of bits	63	62	63	63	
Overload list	64	65	66	67	
			| Pov111
| Pov111		

Overload channel			64			65		66			67	
		*			*		*			*		
	*	*		*		*	*	*	*	*	*	
Voice lis
	1	2	3		4		5	6	7	8	9	
				Pv								
* = LSB												
FIGURE  13/G.763
Example of 3/2 bit overload channel creation

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 assignment message. Refer to Figure 14/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 configuration 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 associated 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 Annex A.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 information 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 and 5.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 identification word in the assignment message must be 0.
b)	If the synchronous data word indicates a 64 kbit/s transparent channel, the MSB of the BC identification word must be 0, 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 is 250.
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 processing of the assignment message shall be performed. The receive IT number shall be assumed to be 0 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 designated 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 associated 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 Table 3/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 assignment 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 destined 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 to 0;

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 assignment message. Refer to Figure 14/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 IT number.)
	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 control of the seizing/releasing ISC as part of the call setup/clearing process between exchanges. Dedicated seizure/select and release messages and the associated acknowledgement messages are exchanged between the DCME and the ISC as defined in Recommendation Q.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 modifications between the DCMEs during alternate speech/64 kbit/s unrestricted type calls.
	Upon reception of a seizure/select message from the ISC for a trunk, the DCME shall perform the necessary internal checks, including the 64 kbit/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 64 kbit/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 initiate the establishment of the unrestricted 64 kbit/s return connection. Failure to complete the establishment of a 64 kbit/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 64 kbit/s forward connection, and the opposite end DCME shall automatically initiate the disestablishment of the unrestricted 64 kbit/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 recognized 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 64 kbit/s unrestricted 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 correspondent DCMEs for 64 kbit/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 requirements 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 64 kbit/s circuit establishment process between DCMEs has been properly initiated.
b)	Circuit handling protocols for dual seizures between DCMEs. These protocols are compatible with the procedures for dual seizures in ISCs as defined in Recommendation Q.764 (signalling procedures of Signalling System No. 7 ISUP).
c)	Automatic recovery of the circuit handling process following unsuccessful or delayed completion 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 Figure 15/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 64 kbit/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. Table 4/G.763 gives nine different TCH states.
TABLE  4/G.763
List of states of the transparent
circuit handler
00

01

02

03

04

05

06

07

08

09	Not-64

Established-forward-64

Disestablished-forward-64

Disestablished-backward-64

Auto-recovery-64

Connect-calling-64

Connect-called-64

Out-of-service

Blocked (DLC64)

Spurious recovery	

	Four timers in the TCH define time intervals within which circuit establishment, disestablishment, 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 Recommendation Q.50, will ensure the availability of the following external information elements for on-demand 64 kbit/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 64 kbit/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 64 kbit/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 64 kbit/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 64 kbit/s forward channel for ITn.
8.2.3.2	Transprel(ITn)
	Indication sent to the TCP to initiate the disconnection of 64 kbit/s forward channel for ITn.
8.2.3.3	RxTranspreq(ITn)
	Indication received from the RCP to indicate that a 64 kbit/s connection has been established.
8.2.3.4	RxTransprel(ITn)
	Indication received from the RCP to indicate that a 64 kbit/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 Figure 16/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 assignment (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 Figure 17/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 following 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 timer T4 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 Figure 18/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 circuit disestablishment and shall cause the TCH to reset timer T2 and enter the appropriate state for the circuit using ITn. The expiration of timer T2 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 reception 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 disconnection (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 accordance 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 64 kbit/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 initiated 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 Figure 19/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¢, respectively.
8.5.1	Dual seizure condition
	Simultaneous reception of seizure requests S64 for TCn from both ISCs will cause the procedures described in §§ 8.3.1.1 and 8.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 Figure 20/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 Figure 21/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 and 8.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 and 8.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 (circuit) 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 procedures described in §§ 8.4.1.3 and 8.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 Figure 22/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 procedures 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 condition I. Refer to Figure 23/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 64 kbit/s transparent channel in the return direction by sending 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 Recommendation Q.50. A DLC facility shall be provided for voice/voice-band data and on-demand 64 kbit/s traffic separately. 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 64 kbit/s unrestricted (transparent) DLC activation messages shall be generated when:
a)	the measured number of assigned 64 kbit/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 additional channel in the 64 kbit/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 64 kbit/s unrestricted channels falls below a presettable threshold. If the 64 kbit/s DLC is not active, 64 kbit/s unrestricted channel requests shall not be denied. Deactivation of DLC shall not occur earlier than a programmable interval which has a minimum of 10 s in order to prevent an oscillating 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 external information elements to the ISC(s) according to §§ 9.3.2 and 9.4.2. The list of DLC related external 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 Recommendation Q.50.
	Assuming that the ISC is responding to messages originating from the DCME SCI, it is recommended 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 conditions 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 Annex B.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.6 bits 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.9 bits per sample).
	The HL and LL thresholds shall be operator programmable options settable between 3 and 4 in 0.05 bits per sample steps.
	When the average number of encoding bits is between the two thresholds, the last load condition 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 (bit p) 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 (bit p) to state 0. 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 bit p 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 ADVD indication 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 Ta seconds after the last detected ADVD indication.
	The Ta timer shall be operator selectable with a minimum of ten seconds.
	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 64 kbit/s traffic is based on the predicted average number of encoding bits for voice traffic if a pair of 4 bit bearer time slots currently used for voice traffic were to be used to accommodate one additional 64 kbit/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 64 kbit/s DLC support message (bit q) to state 1. Refer to § 11.3.
	A local UCA condition shall be signalled to the corresponding DCME(s) by setting the on-demand 64 kbit/s DLC support message (bit q) to state 0. Refer to § 11.3.
	The DLC ON condition for on-demand 64 kbit/s traffic shall be declared when:
a)	the UCNA condition is detected locally; or
b)	the bit q received from a corresponding DCME is in state 1 (DLC is applicable to those circuits which are destined to this corresponding DCME).
	The DLC OFF condition for on-demand 64 kbit/s traffic shall be declared for each destination when:
a)	the UCA condition is detected locally; and 
b)	the bit q 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 DLC ON.
	The DD64 message shall be sent to the local SCI and to the TCH at the transition from DLC ON to DLC OFF. 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 AD64 indication.
	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 ten seconds.
	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 provided. 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 20 second 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 IT 239 for pool 1 and IT 240 for pool 2. This test vector sequence shall compete for assignment to a bearer channel in accordance with § 6. The ADPCM encoder for (BCn, IT 239/240) shall be selected normally in accordance with § 6, except that any ADPCM encoders selected for IT 239/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, IT 239/240 shall be assumed to be destination directed to all destinations corresponding 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 associated channel check assignment message (BCn, IT 239/240) for each TTF. The synchronous data word code 1111 shall be transmitted once for each channel check sequence.
	If the channel check procedure has been manually inhibited at the DCME transmit unit, bit 1 in DCME frame 62 of the Asynchronous data word shall be set to 1, otherwise the bit shall be set to 0. The manual inhibit shall become effective at the next TTF boundary.
	All corresponding DCME receive units shall assign IT 239/240 to a special test port. A special test port is assigned for each received bearer. The special test ports are identified by the local IT numbers 241 through 244 receiving bearer numbers 1 through 4, respectively. A test ADPCM decoder associated with (BCn, IT 239/240) shall be selected in accordance with § 7. However, any ADPCM decoder selected for IT 239/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 pattern 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 pattern 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 code 1111 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 a 0 if the test result is pass, otherwise the test result table shall contain a 1. If the result of the test pattern receiver has been disregarded, a 1 shall be entered in the test result table for the high BER yes/no condition and a 1 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 showing 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 corresponding local DCME via the Asynchronous Data Word using the format shown in Table 5/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 frames 56-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 60 seconds have elapsed since the last channel check test for that bearer, the BC number and the ADPCM decoder number contained in DCME frames 57, 58, 59 and 60, respectively, shall be set to all 1s (ineffective message). The pass/fail and high BER bits shall be set to 1. The message contents shall remain latched to the last result for that bearer until a new result is available.
TABLE  5/G.763
4 bit asynchronous data word bit allocation
DCME frame	Data word bit No.				Message
(s = spare bit set to 0)	
	1	2	3	4		
0
1
·
·
·
·	1
5	2
6	3
7	4
8	Type: IT-related  circuit
Type: supervision/alarm condition

Designation: The No. represents 
Designation:  the IT No.	
53	213	214	215	216	Content:
Content:0 =  normal condition
Content:1 =  alarm condition	
54	A	A	A	A	Type: DCME bearer backward alarm

Designation: The data word bit No.
Designation:  represents the Rx 
Designation:  bearer No. (see
Designation: Notes 1 and  2)

Content:
Content:A: 0 = normal condition 
Content: A:1 = alarm condition 	
55	p	q	x	x	Type: DLC support message

Designation:
Dep = Voice/voice-band data
Deq = Unrestricted 64 kbit/s 
Dex = Do not care

Content:
Content:0 = LL or UCA
Content:1 = HL or UCNA	
56	b1	b2	R	x	Type: Identification of  Rx bearer
Type: to which channel check 
Type: results apply if channel 
Type: check is progressing
Type: normally

Designation and content:
b1 b2: Represents the Rx bearer
b1 b2: No. in binary code
b1 b2: (see Note 1)
R: 1 = channel check disregarded
R: 1 R: (high BER)
R: 0 = channel check progressing
R: 1R:  normally
x: Do not care	
	(MSB)					

TABLE  5/G.763 (cont.)
DCME frame	Data word bit No.				Message
(s = spare bit set to 0)	
	1	2	3	4		
57

58	x

BC
(MSB)	BC

BC	BC

BC	BC
(LSB)
BC	Type: BC-related channel check
Type: results  transmitted one
Type: BC  per DCME multiframe	
59

60	D

D	D

D	D

D	D
(LSB)
D	
Designation and content:
DBC: 7-bit code represents
DBC: theNo. of the BC for which 
DBC: the result applies
DBD: 8-bit code represents the 
DBD: No. of the decoder for  
DBD: which the result applies	
61	Y	x	x	x	 DBY: Channel check alarm
DBY : 0 normal,
DBD: 1 alarm
DB x: Do not care	
62	T	x	x	x	Type: Transmit channel check inhibit
Type: 
Designation and content:
DeT: 1 channel check  interrupted
DeT:  0 channel check normal
Dex: Do not care	
63	x	x	x	x	 Dex:Spare (Note 3)	
Note 1 – There is a fixed association between the Rx bearer number in DCME frame 54, the Rx bearer number in DCME frame 56, the VOW IT number, and the local channel IT number. Refer to Table 12/G.763.
Note 2 – In two pool multi-clique operation there is one Rx bearer number associated with each pool.
Note 3 – The unused codes are reserved for implementation of facsimile compression and special tandeming facilities.						

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 messages by examining the bearer identification number contained in the first message (DCME frame 56) 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)	100 ms of 2400 Hz sinusoidal tone at -10 dBm0;
b)	the A-law PCM initializing sequence in accordance with § 10.1.5;
c)	768 ms 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 0 dBm0 ± 1 dB. The test pattern receiver shall be designed to synchronize to the 1254 Hz sinusoidal tone pattern within 100 ms at a bearer error rate of 1 in 10-3 while the bearer is operating in 3 bit mode (note). Following synchronization, the test pattern receiver shall declare test pass if the sum of the measured errors does not exceed 2000 for each of the LSB and LSB + 1 bits, and the sum of the errors does not exceed 1000 for each of the MSB through MSB-5 bits in a 600 ms measurement period measured at the PCM output stream. The determination test pass or test fail shall be made at the end of a 600 ms measurement window. The start of the measurement window shall be located 650 ms from the time of occurrence of the assignment message containing the synchronous data code word (1111). The measurement window test time frame and 1254 Hz test tone sequence are shown in Figure 24/G.763.
	Note – Operation in 2 bit 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 initializing segment followed by a 1254 Hz sinusoidal signal. All segments are contiguous. The first sequence comprises 834 samples (approximately 100 ms) of a 2 400 Hz sinusoidal sequence encoded in accordance with Recommendation G.711 using A-law encoding. An output sequence is not provided for this input sequence. A reset is assumed prior to the start of the second sequence. The second sequence consists of 3496 samples (approximately 437 ms) 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 accordance with Recommendation G.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 immediately prior to the reception of the test sequence.
	The test sequence format is based on 768 ms of coded signal divided into a series of blocks.
	To maintain the accuracy with which the sample sequences will be incorporated in manufacturers' 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‑PCM bit 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 32 kbit/s channel, and shall include provisions for accommodating the following 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 4 bit BC in the pool. The first bit is a sync bit and the remaining 3 bits carry a part of the CC message.
	Control channel messages are transmitted at a rate of 3 bits in each 125 ms bearer frame. A complete 48 bit encoded (CC) message shall be transmitted in one DCME frame of 2 ms. Prior to encoding, the CC message shall consist of an 8 bit BC identification word, an 8 bit IT identification word and 8 bits for other DCME to DCME messages (Data Word). The CC message shall be protected by a (24, 12) rate 1/2 Golay code. Figure 25/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 3 bits in error in a block of 24 bits. The code generator polynomial is:
			
	The 24 information bits comprising 8 bits for the BC number, 8 bits for the IT number and 8 bits for other data are transmitted in two blocks of 12 information bits each. For each information block there is a check block consisting of 11 bits for the Golay code and one dummy bit as shown in Figure 26/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 16 bit unique word shall be provided for each individual clique, to identify the beginning of the 2 ms DCME frame over which the encoded CC message of the pool is transmitted. Refer to Figure 25/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 CC 4 bit time slot.
	The 16 bit unique word shall also provide a means of identifying the beginning of a 128 ms DCME multiframe (64 DCME 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 frame 0 to 63     0 0 1 0 1 0 0 1 1 0 1 1 1 1 0
	DCME frame 1 to 63     1 1 1 0 1 0 1 1 0 0 1 0 0 0 0 1
	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 16 nibbles constituting a complete CC message.
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 CC nibble and a locally stored unique word pattern. The resulting correlation matches shall be used to attain, maintain and regain the synchronization of the CC message.

	In the steady state, a detection threshold of three shall be used to maintain synchronization, and a 3 bit window centred 16 bits 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 initiated over a 16 bit window.
11.3	CC message structure
11.3.1	BC identification word
	The MSB of the 8 bit BC identification word shall be used to indicate the BC type. For data, the MSB shall be 1. For all other BC types (bit bank, transparent, voice), the MSB shall be 0.
	The seven LSBs in binary code shall identify the BC number in accordance with § 5.9. The normal BC numbering range shall be 1 through 61. The overload BC numbering range shall either be 64 through 83 or if the optional 2 bit encoding mode is available and enabled 64 to 124.
	For 64 kbit/s transparent channels, the BC number shall identify the first 4 bit BC of a pair of adjacent 4 bit BCs used to create an 8 bit BC and shall be even numbered in the range 2 through 60. 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 64 kbit/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.
	BC number 255 in binary code shall be used to indicate an ineffective CC message if all traffic is preassigned.
11.3.2	IT identification word
	The 8 bits of the IT identification word shall be used to identify the ITs. ITs numbered 1 to 216 in binary code shall be available for traffic. When less than 216 ITs 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 orderwires (up to four correspondents), 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 and 7.
	IT number 255 in binary code shall be used to indicate an ineffective CC message if all traffic is preassigned.
11.3.3	Data word
	The 8 bit data word in the CC message forms two independent data channels. The first data channel consists of the four MSBs of the 8 bit data word, and is transmitted with each assignment message synchronously relative to the BC and IT identification.
	The second data channel consists of the remaining 4 bits of the 8 bit data word transmitted in a multi-frame structure asynchronously relative to the BC and IT identifications.

11.3.3.1	Synchronous data word
	The 4 bit 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 4 bit 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 -68 dBm0 and -42 dBm0 (see Note). For channels subject to DSI, the background noise level shall be encoded in accordance with Table 6/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 -65 dBm0.
	For each CC message, the DCME receive unit shall decode the 4 bit data word and update the noise level memory associated with the decoded IT according to Table 6/G.763. At the DCME receive unit, a pseudo-random 8 bit 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 64 kbit/s transparent calls, the 4 bit data word shall be 1001 and transmitted with each new assignment, refreshment and disconnection message.
	If the BC in the assignment message is being subjected to the automatic channel check procedure according to § 10, the 4 bit data word shall be 1111.
11.3.3.2	Asynchronous data word
	The 4 bit 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 64 DCME frames numbered from 0 to 63. Frame No. 0 is the DCME frame in which the CC unique word is inverted. The CC unique word for the remaining 63 frames shall be transmitted normally.
	Bit allocations in the data word multiframe for the various applications shall be as shown in Table 5/G.763.
11.3.4	CC structure when USM option is used
	If the optional USM is used, the BC identification word and the CC synchronous data word can be formatted according to the users' requirements in the DCME frames 0, 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 signalling message as follows. The bits 1 to 8 of the signalling message shall identify ITn1. The bits 9 to 16 of the signalling message shall identify ITn2. Bits 17 and 18 shall encode the a and b bits of ITn1. Bits 19 and 20 shall encode the a and b bits of ITn2. The a and b bit signalling information will be either change of signalling states, or the refreshment of existing states. Figure 27/G.763 illustrates the format for this type of message.
TABLE  6/G.763
4 bit synchronous data word encoding
Transmit DCME action
Measure noise level
n (dBm0) (Notes 1, 2)	
Code
Word	Receive DCME Reaction
Store noise level
m (dBm0)	
BC –68 £ n < –68	0 0 0 1	–68 (m-law only)	
BC –68 £ n < –62	0 0 1 0	–65	
BC –62 £ n < –57	0 0 1 1	–60 (default)	
BC –57 £ n < –52	0 1 0 0	–55	
BC –52 £ n < –47	0 1 0 1	–50	
BC –47 £ n < –44	0 1 1 0	–46 (Note  3)	
BC –44 £ n < –42	0 1 1 1	–43 (Note 3)	
BC –42 £ n < –62	1 0 0 0	–42 (Note  3)	
BC identifies 64 kbit/s 
channel	1 0 0 1	BC indicates first 4 bit 
nibble of 8 bit channel	
BC is under channel
check test	1 1 1 1	BC is under channel
check test	
Ineffective message	0 0 0 0	Ineffective	
Unused codes 
(Note 4)	1 0 1 0
1 0 1 1
1 1 0 0
1 1 0 1
1 1 1 0	No action required	
Note 1 – It is suggested that because the noise inserted at the receive unit is broadband, the transmit unit noise measurement should also be broadband.
Note 2 – The DCME transmit unit noise intervals are implementation specific, a tolerance of ± 2 dB is suggested.
Note 3 – When the background noise level is high (-46 dBm0 or greater) some administrations have indicated there may be a subjective benefit in inserting lower values of noise at the receive unit than those measured at the transmit unit. The contrast is most apparent when the noise spectral density at the DCME transmit unit is substantially different from the noise inserted at the receive unit. Since the noise inserted at the receive unit does not affect DCME interoperability the selection of the noise level is left as an option (-50 dBm0 is being considered).
Note 4 – The unused codes are reserved for implementation of facsimile compression and special tandeming facilities (for further study).

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 transmit activity detector threshold and operate time specification. Compliance with the threshold and operate time specification is not required to achieve interworking between various DCME manufacturers. 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 Group XII in Recommendation P.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.5 dB with respect to 1000 Hz over the frequency band from 300 to 3400 Hz. The Gaussian noise level can typically vary over a range from -68 to -42 dBm0.
	Note – For A-law encoding, the minimum noise level is -65 dBm0.
	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 4 bit 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 300 to 3400 Hz.
	The threshold and operate time of the transmit activity detector may be implementation specific. However, for guidance threshold and operate time, characteristics for the transmit activity detector are given in Annex B.2.
12.1.2	Hangover control
	The permissible hangover time as a function of stimulus signal duration shall be within the mask shown in Figure 28/G.763 for CCITT Signalling System No. 5 and within the mask shown in Figure 29/G.763 for speech and CCITT Signalling Systems Nos. 6, 7 and R2D.
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 hangover time should be extended so that it is sufficiently long to bridge facsimile page changes. This time may be as long as 14 s.
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 variations which are due to the actions of echo suppressors or echo cancellers. This might be accomplished, 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 Annex B.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 Annex B.3.
	The following requirements shall be met with the modem types and bit rates given in Table 7/G.763.
12.2.1	Output conditions
	The D/S Discriminator shall analyse the activity on each transmit IT and provide the following 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 200 ms after any of the following 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 2100 Hz tone detector are given in Annex B.3.
TABLE  7/G.763
Types of modem and bit rates which shall be supported
Modem	Bit rate (Bit/s)	Operating mode 	
V.21
V.22
V.22bis
V.23

Group 1, 2
V.26
V.26bis
V.26ter
V.27bis
V.27ter

V.29

V.32
V.33	300 bit/s
600, 1200
2400
1200
HDX, continu
Analogue
2400
1200, 2400
1200, 2400
2400, 4800
2400, 4800

4800, 7200, 9600

2400, 4800, 9600
9600	FDX
FDX
FDX
HDX, character mode 
HDX, continuous
FAX
FDX
HDX
FDX
HDX
HDX
Group 3, FAX
HDX/FDX
Group 3, FAX
FDX
FDX	

Activity	Output condition 	
Speech
Tones and tone pairs (Note 1)
Data signal (Note 2)
2100 Hz	Voice
Voice
Data
Data	
Note 1 – Where a signal frequency tone i.e. an unmodulated carrier, is part of a voice‑band data modem signal exchange, once the signal is classified as data the classification should not return to voice within the data call. This may be accomplished by either:
a)	specific recognition of those tones which are used in the modems specified in Table 7/G.763; or
b)	delaying the transition from data to speech for a specified minimum time (0.5 to 1.0 sec.).
Note 2 – V.21 modem signals must be classified as data to ensure that facsimile signals will not be corrupted.

12.3	Signalling detector
	Functionally, the signalling detector shall detect the presence of CCITT Signalling System No. 5 line signalling (2400 Hz) on each transmit IT, provide a detection indication (signal detect/No detect) to the TCP function and enable the signalling hangover time mask (Figure 28/G.763) for the duration of the signalling interval. Upon system start-up or map change, the Signalling Detector indication shall be reset to no Detect. Requirements for a 2400 Hz tone detector are given in Annex B.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 System No. 5 signalling or the probability of signalling being detected as speech, voice-band data or noise shall be less than 0.5 per 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 Recommendation G.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 Recommendation G.822. Controlled slips at 2048 kbit/s, on the trunk side shall be 2 frames, controlled slips at 1544 kbit/s on the trunk side and for 2048 kbit/s and 1544 kbit/s on the bearer side require further study.
13.1.3	Buffer sizes and locations
	Table 8/G.763 indicates suitable buffer sizes and locations for the 2048 kbit/s hierarchy for the various synchronization options which are detailed in Annex B.6. A table for the 1544 kbit/s hierarchy is under study.
TABLE  8/G.763
Buffer sizes and locations for the 2048 kbit/s hierarchy
Synchronization
type
(Note 3)	Buffer 
size
(Note  1)	Slip
size
(Note 2)	Location
(Note 4)	
Figure No.	
1.  No buffering					
1.  A Asynch	No buffer	–	–	B-4/G.763	
1.  B Synch	No buffer	–	–	B-5/G.763
B-18/G.763
B-15/G.763	
1.  C Synch
1.  B analogue to
1.  B digital	No buffer	–	–	B-8/G.763	
2.  Plesiochronous/
2.  buffering					
1.  A Asynch	0.5 ms	2 frames	Trunk side	B-6/G.763	
1.  B Synch	0.5 ms	2 frames	Bearer side	B-7/G.763
B-16/G.763
B-19/G.763	
3.  Plesiochronous/
2.  Doppler
3.  buffering					
1.  A Synch	1.7 ms	2 frames	Bearer side	B-9/G.763
B-14/G.763
B-17/G.763
B-20/G.763
B-22/G.763	
1.  B Synch	2.4  ms
1.7 ms		Bearer side
and trunk side	B-10/G.763	
1.  C Asynch	1.7 ms	2 frames	Trunk side	B-12/G.763	
1.  D Synch	2.4 ms
1.7 ms		Trunk side	B-11/G.763	
1.  E Synch	1.7 ms	2 frames	Trunk side	B-13/G.763
B-21/G.763	
Note 1 – Buffer sizes are derived from the following:
–	single Doppler with plesiochronous buffer:
(0.6 ms ´ 2) + 0.5 = 1.7 ms;
–	double link Doppler buffer: 1.2 ms ´ 2 = 2.4 ms;
–	plesiochronous buffer for 2 PCM  (2048 kbit/s) frames:
(2 ´ 0.125 ms) ´ 2 = 0.5 ms.
The Doppler buffer size used is an example for a specific satellite. These buffer sizes may need to be adjusted taking into account the orbital parameters of the satellite in use.
Note 2 – The slip size of 2 PCM frames is based upon the requirement in the 2048 kbit/s frame to maintain frame alignment.
Note 3 – Asynch refers to the case where the transit unit and receive unit of the same DCME terminal derive their timing from different clock sources.
Note 4 – In general it is preferable to avoid placing the plesiochronous slip buffers on the bearer side of the DCME to minimize disruptions caused by slips. This may not be possible under all circumstances.					

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 failure, 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 Recommendations G.165, G.164, or Recommendation G.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 performance 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 following bearer channel transmission rates:
–	64 kbit/s: 8 bit/sample transparent;
–	40 kbit/s: 5 bit/sample ADPCM;
–	32 kbit/s: 4 bit/sample ADPCM;
–	24 kbit/s: 3 bit/sample ADPCM;
–	16 kbit/s: 2 bit/sample ADPCM (optional).
	For 64 kbit/s bearer channels (8-bit mode), the ADPCM encoders and decoders shall be bypassed.
	For 40 kbit/s bearer channels (5-bit mode), 32 kbit/s bearer channels (4-bit mode), 24 kbit/s bearer channels (3-bit mode) and 16 kbit/s bearer channels (2-bit mode), the ADPCM encoders and decoders shall be in accordance with Recommendation G.726 and shall operate in accordance with §§ 6.1.6 and 7.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. Additional 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 operation, 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 64 kbit/s without interpolation, 40 kbit/s without interpolation, 32 kbit/s without interpolation and optionally at 24 kbit/s or 16 kbit/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. Table 9/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. Table 10/G.763 outlines the unilateral operational parameters.
	The DCME shall include a capability to permit the entry of configuration data into a background mapping facility without interruption to service which is utilizing configuration data in a foreground 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 (1 through 216);
b)	Pre-assigned transmit and receive trunk time slots by permitting semi-permanent TC-to-IT-to-BC associations. Pre-assignments of 24 kbit/s bearer channels and optionally 16 kbit/s for maintenance and 64 kbit/s, 40 kbit/s and 32 kbit/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 pool 1, lower bound pool 2) 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 condition in normal operation (note).
Note – Configuration and operation of DCME for special tandeming arrangement is for further study.
e)	Channel check permanent associations (see Table 12/G.763).
TABLE  9/G.763
DCME operational parameters subject to
multi– (bi) – lateral agreements
Mode of operation

Number of destination	Point-to-point,

1	Multi-destination

2-4	Multi-clique

2	
Destination identification		Name/number		
Optional USM activated		Yes/no		
Optional USM repetition interval 		R		
a)  Dynamically assigned correspondents				
Tx pool boundaries

Rx pool boundary
per Rx bearer

Tx TC/Local IT mapping

Rx remote IT/local IT mapping
per Rx bearer		Pool boundary shall coincide with 
an 8-bit TS boundary

Pool boundary shall coincide with
an 8-bit TS boundary

TC (primary group No., 
TS No.)/Local IT (No.)

Remote IT (No.)/local IT (No.)
Remote IT (No.)/to other 
destination		
b)  Pre-assigned correspondents				
Tx pre-assigned mapping
64 kbit/s, 40 kbit/s, 32 kbit/s
Rx pre-assigned mapping 
64 kbit/s, 40 kbit/s 32 kbit/s		TC (group, No., TS No.)/
local IT (No.)/BC (No.)
BC No./remote IT (No.)/
local IT (No.)		
c)  Clock source				
Provided on trunk group, bearer clock or external				

TABLE  10/G.763
DCME operational parameters unilaterally determined
Parameter	Note	
No. of primary trunk groups

DLC timers

DLC thresholds

DLC averaging (Note)

DCME TC-trunk identification
mapping

TCH/DLC interaction

Bearer backward alarm mapping

Circuit supervision TC-trunk
identification mapping

Channel check procedure

Statistic time interval (STI)	No. of 1544 kbit/s or 2048 kbit/s

Adjustment of Ta, Tb

Low load, high load

See Annex B.1

For DLC  and seizure/release
 in TCH

Enabled/disabled 

For the local DCME alarm

For SCI

ON/OFF

See § 15.2.3	
Note – Non-mandatory (implementation specific)

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 Table 11/G.763.
TABLE  11/G.763
DCME management statistics
Service to be
measured	Quality of service
statistics	Offered traffic
statistics	
Voice

Data

64 kbit/s
on demand

All services	11)  Bits per sample

12)  Voice queue
4)......freezeout fraction

13)  Voice freezeout 
3)......excess.

16)  Data queue
 14)  freezeout fraction
11
18)  64 failed seizures
11)  ratio

11)  Average BER

12) BER excess

13)  Severely errored
13)..seconds	14)  Voice activity ratio

15)  DLC voice on ratio
4

17)  Data activity ratio

19)  64 connected ratio

10)  DLC 64 on ratio

Note – Statistics 1) to 4) and 6) to 9) shall be calculated separately for each transmit pool.
Statistics 5) and 10) shall be calculated separately for each destination.
Statistics 11) and 12) shall be calculated for each receive control channel.
Statistic 13) shall be calculated separately for each incoming digital link (trunk and bearer).

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 64 kbit/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.0 minute 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.0 minute interval during the STI within the range from 10 minutes to 60 minutes (in 10 minute steps).

	The BC states that need to be considered for the calculation of the system statistics are specified 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 Note 1).
–	Data: The connected TC carries active voice-band data signals (including 2100 Hz tone) recognized as such, extended with its corresponding hangover time (and marginally “voice” signals when not yet recognized as such. (See Note 2).
–	Transparent: The connected TC carries a 64 kbit/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 4 bits/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 4 bits/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, N is the number of sampled DCME frames of the averaging period of 1.0 minute.
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 connected, to the total number of non-pre-assigned TCs classified as voice-active connected plus not connected. 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 frames N. 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 64 kbit/s on demand seizure (S64) attempts that receive a 64 kbit/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 64 kbit/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 64 kbit/s on ratio
	Defined as the ratio of the number of DCME frames during which DLC for 64 kbit/s unrestricted 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 Recommendation G.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 freezeout figures for the data queue should always be less than the corresponding freezeout figures 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 15 minutes report for any 24 hour 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 provided 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 connections, 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 64 kbit/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 performed 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 disabled 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 to 0. When such an assignment message is received, no action shall be taken based on the assignment message 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 64 kbit/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 condition at the calling end shall generate the following signalling tone:
–	frequency:	2000 Hz ± 10 Hz;
–	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 numbered 232, 233, 234 and 235 shall alert the operator of a pending VOW call. The destination number cross-reference for the VOW ITs is presented in Table 12/G.763.
TABLE  12/G.763
Destination number cross-reference

Destination	Rx number
in
Frame 56	Bit number
for backward
alarm in
Frame 54	IT number
used
for VOW	Local IT number
for received
channel check	
1

2

3

4	1

2

3

4	1

2

3

4	232

233

234

235	241

242

243

244	

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 exceeds 1 in 103 (prior to correction) on the basis of a one minute measurement interval, consequent actions shall be taken in accordance with Table 13/G.763. When the CC BER exceeds 1 in 105 (prior to correction) on the basis of a 60 s measurement interval, a high BER condition shall be declared for use by the channel check procedure. (The CC BER threshold values 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-assigned 64, 40, 32, or optionally 24 or 16 kbit/s channel.
15.11	Fault conditions and consequent actions
	The philosophy of fault conditions and consequent actions from the point of view of maintenance of digital networks is consistent with that contained in the G.700-Series Recommendations in the Red Book,
Volume II – Fascicle III.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 Recommendation G.736, for 2048 kbit/s links, and Recommendation G.734 for 1544 kbit/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 Recommendation G.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 recognition of an errored condition and a fault declaration is under study, e.g  2.5 s.)
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 conditions a, b, c and/or d 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 Table 13/G.763.
	The consequent actions are listed below:
a)	Backward alarm indication to the remote end (towards local ISCs) generated. For 2048 kbit/s primary multiplex trunks, this is done by changing bit 3 of channel time slot 0 from state 0 to state 1 in those frames not containing the trunk frame alignment signal (see Recommendation G.732). For 1544 kbit/s primary multiplex trunks, this is done by forcing bit 2 in every channel time slot to the value 0 or by modifying the S-bit for the 12 frame multiframe or by sending a frame alignment alarm sequence for the 24 frame multiframe (see Recommendation G.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) and e)), 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 accordance with Table 13/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 presence 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 state 1, 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 state 1, (see Table 5/G.763).
f)	Alarm indication to the remote end DCME receive unit is generated by changing the appropriate remote alarm indication bit(s) of the CC data word to state 1, (see Table 5/G.763). This will be effected as soon as possible.
g)	Backward alarm indication to the remote end (towards remote ISCs) generated. For 2048 kbit/s primary multiplex trunks, this is done by changing bit 3 of Time Slot 0 from the state 0 to the state 1 in those frames not containing the bearer frame alignment signal (see Recommendation G.732). For 1544 kbit/s primary multiplex trunks, this is done by forcing bit 2 in every channel time slot to the value 0 or by modifying the S-bit for the 12 frame multiframe or by sending a frame alignment alarm sequence for the 24 frame multiframe (see Recommendation G.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 Table 14/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 Recommendation G.736.
b)	AIS detected in incoming primary trunk groups.
c)	Loss of multiframe alignment (loss of incoming supervision channel) as defined in Recommendation G.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 bit 6 TS16 set to 1 in frame 0 of the PCM multiframe, as described in Recommendation G.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 Recommendation G.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 alignment signal, as described in Recommendation G.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 and 11.2.1, in the synchronous bit pattern of the CC.
j)	Remote bearer alarm
The alarm condition is the appropriate remote alarm indication bit of the CC asynchronous word set to 1, as defined in Table 5/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 Table 5/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 Table 14/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 frame 0 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 to 1. Refer to Recommendation G.704.
d)	AIS towards local ISC.
AIS = alarm indication signal as described in Recommendation G.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 asynchronous data word shall be set to 1. Refer to Table 5/G.763.
h)	Asynchronous word. Bearer alarm.
For the affected bearer the relevant backward bearer alarm of the asynchronous data word is set to 1. Refer to Table 5/G.763.
i)	Prompt maintenance alarm
An audible/visual alarm indication to alert the operator to the presence of a fault condition. 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