Internet Standards/CD2.mdf/ccitt/1992/g/g1.asc

Text File | 1993-08-15 | 171KB | 3,927 lines

C:\WINWORD\CCITTREC.DOT_______________







INTERNATIONAL  TELECOMMUNICATION  UNION







CCITT    G.763

THE  INTERNATIONAL
TELEGRAPH  AND  TELEPHONE
CONSULTATIVE  COMMITTEE











GENERAL  ASPECTS OF  DIGITAL

TRANSMISSION  SYSTEMS;

TERMINAL  EQUIPMENTS





DIGITAL  CIRCUIT  MULTIPLICATION
EQUIPMENT  USING  32  kbit/s  ADPCM
AND  DIGITAL  SPEECH  INTERPOLATION









Recommendation  G.763







Geneva, 1991













































































Printed in Switzerland







FOREWORD

    The CCITT (the International Telegraph and Telephone Consultative Committee) is the per-
manent organ of the International Telecommunication Union (ITU). CCITT is responsible for
studying technical, operating and tariff questions and issuing Recommendations on them
with a view to standardizing telecommunications on a worldwide basis.

    The Plenary Assembly of CCITT which meets every four years, establishes the topics for
study and approves Recommendations prepared by its Study Groups. The approval of Rec-
ommendations by the members of CCITT between Plenary Assemblies is covered by the pro-
cedure laid down in CCITT Resolution No. 2 (Melbourne, 1988).

    Recommendation G.763 was prepared by Study Group XV and was approved under the Resolution
No. 2 procedure on the 14 of December1990.





___________________





CCITT  NOTE

    In this Recommendation, the expression ôAdministrationö is used for conciseness to indicate
both a telecommunication Administration and a recognized private operating agency.



















πITU1991

All rights reserved. No part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in writ-
ing from the ITU.

PAGE BLANCHE

Recommendation G.763

Recommendation G.763

DIGITAL  CIRCUIT  MULTIPLICATION  EQUIPMENT  USING
32  kbit/s  ADPCM AND  DIGITAL  SPEECH  INTERPOLATION

(revised 1990)

1    General

1.1    Scope

    This Recommendation is intended as an introduction to digital circuit multiplication equip-
ment and systems, and as a base document for the specification of digital circuit multiplication equip-
ment (DCME) and digital circuit multiplication systems.

    DCME is utilized as a means of augmenting the capacity of digital transmission systems
operating between several ISCs. DCME has all of the following attributes:

û    digital speech interpolation;

û    low rate encoding;

û    dynamic load control arrangement in association with interfacing;

û    capability to accommodate the following types of bearer service requirements:

i)    speech,

ii)    3.1 kHz audio (data and speech),

iii)    64 kbit/s unrestricted (transparent),

iv)    alternate speech/64 kbit/s unrestricted.

    The link between two DCMEs is generally one where a highly efficient traffic carrying capa-
bility is required, e.g.a long-distance link.

    Compression is accomplished by active 64 kbit/s trunk channel assignment and ADPCM
encoding thereby reducing the nominal transmission channel requirements.

    This Recommendation applies to digital circuit multiplication equipment telecommunica-
tions systems and specifies the following major aspects of DCME system design:

a)    network interface requirements:

û    traffic capacities;

û    trunk and bearer facility interface;

û    signalling systems;

û    voice-band data modem support

û    echo control.

b)    functional requirements:

û    operational modes;

û    system capacity;

û    overload strategy;

û    noise level matching;

û    PCM encoding standards conversion;

û    time slot interchange;

û    64 kbit/s circuit handling;

û    ADPCM encoders and decoders;

û    timing and synchronization;

û    dynamic load control;

û    maintenance and alarm functions;

û    facsimile compression (under study);

û    tandem operation (under study).

c)    performance criteria of DCME system elements such as:

û    speech detector;

û    control channel;

û    voice-band data detector;

û    signalling detector;

û    facsimile compression (under study).

    This Recommendation specifies these elements to achieve interworking.

1.2    Purpose

    Speech signals occurring on telecommunications links are generally the product of two-way
conversations. It is customary for one talker to pause while the other speaks; thus, an active speech
signal is present on each direction of the trunk channel for only a fraction of the available time. In
addition, even when only one talker is speaking, pauses occur between utterances, so there are times
when the circuit is idle. Measurements show that speech is present on each direction of the trunk
channel approximately 30to 40% of the time, averaged over a large number of busy trunks. DCME
reduces the transmission capacity needed to handle a multiplicity of telephone trunk channels by
exploiting the low average channel activity and by transmitting active speech using ADPCM tech-
niques.

    The DCME provides a nominal 5 : 1 reduction in the transmission capacity required to carry
various mixtures of speech, voice-band data and 64kbit/s unrestricted channels. An overload strategy
consisting of variable bit rate encoding and dynamic load control techniques is utilized to limit speech
clipping. The DCME data detector discriminates between voice-band data and speech in order to
assign the voice-band data signal to a bearer channel  protected against the formation of overload
channels  which degrade the voice-band data performance.

1.3    Application

    This Recommendation is applicable to the design of digital circuit multiplication equipment
intended for, but not limited to, use in an international digital circuit. Freedom is permitted in design
details which are not covered in this Recommendation.

2    Definitions relating to digital circuit multiplication equipment (DCME)

2.1    digital circuit multiplication equipment (DCME)

    A general class of equipment which permits concentration of a number of 64 kbit/s PCM
encoded input trunk channels on a reduced number of transmission channels (see º2.7).

2.2    digital circuit multiplication system (DCMS)

    A telecommunications network comprised of two or more DCME terminals where each
DCME terminal contains a transmit unit and a receive unit.

2.3    low rate encoding (LRE)

    A voice-band signal encoding method, e.g. ADPCM, which results in a bit rate less than
64kbit/s, e.g.either 40kbit/s, 32kbit/s, 24kbit/s, or optionally 16kbit/s. Conversion between speech
signals encoded in PCM at 64kbit/s and those encoded in ADPCM must be carried out by means of
transcoding processes given in RecommendationG.726.

2.4    variable bit rate (VBR)

    The capability of the encoding algorithm to dynamically switch between either 32 and
24kbit/s or also optionally between 24and 16kbit/s for speech traffic under control of the DCME.

2.5    digital speech interpolation (DSI)

    A process which, when used in the transmit unit of a DCME, causes a trunk channel (see
º2.9) to be connected to a bearer channel (see º2.8) only when activity is actually present on the
trunk channel. This, by exploiting the probability of the speech activity factor (see º2.15) of trunk
channels being less than1.0, enables the traffic from a number of trunk channels to be concentrated
and carried by a lesser number of time shared bearer channels. The signals carried by a bearer channel
therefore represent interleaved bursts of speech signals derived from a number of different trunk
channels.

    Note û A process complementary to DSI is required in the receive unit of a DCME, i.e.
assignment of the interleaved bursts to their appropriate trunk channels.

2.6    DCME frame

    A time interval, the beginning of which is identified by a unique word in the control channel.
The DCME frame need not coincide with the multi-frames defined in RecommendationG.704. The
format specification of the DCME frame includes channel boundaries and bit position significance.

2.7    transmission channel

    A 64 kbit/s time slot within a DCME frame.

2.8    bearer channel (BC)

    A bearer channel is a unidirectional, digital, transmission path from the transmit unit of one
DCME to the receive unit of a second associated DCME used to carry concentrated traffic between
the two DCMEs.

    Note 1 û A number of bearer channels in each direction of transmission form the both-way
link required between two DCMEs. This link may be, for example, a 2048kbit/s system.

    Note 2 û A bearer channel may have any of the following instantaneous bit rates: either64,
40, 32, 24, or optionally 16kbit/s.

2.9    trunk channel (TC)

    A unidirectional, digital transmission path (generally short distance) used for carrying traffic
and which connects a DCME to other equipment, e.g.an ISC. Two such trunk channels (transmit and
receive) are needed by 4wire telephone circuits and constitute a trunk circuit.

    Note 1 û Signals carried by a trunk channel will be transmitted at a bit rate of 64 kbit/s.

    Note 2 û A number of trunk channels in each direction of transmission are required between a
DCME and, for instance, an ISC. These trunk channels may be carried by a number of 2048or
1544kbit/s systems.

2.10    intermediate trunk (IT)

    A channel mapping designation which ranges between 1 and 216 which relates each trunk
channel to an internal numbering designation used within the DCME for conveying trunk channel to
bearer channel connectivity via the control channel (see º2.13).

2.11    assignment message

    The message specifying the interconnections required between trunk channels and bearer
channels.

2.12    assignment map

    A record, held in a memory of a DCME, of the interconnections required between trunk
channels and bearer channels. This record is dynamically updated in real time in accordance with the
traffic demands made on the DCME.

2.13    control channel (CC)

    A unidirectional transmission path from the transmit unit of one DCME to the receive unit of
one or more associated DCMEs which is dedicated primarily to carrying channel assignment mes-
sages. In addition, the control channel transmits other messages such as idle noise levels, dynamic
load control, alarm messages and optionally line signalling information.

    Note û An alternative name for control channel is assignment channel.

2.14    ensemble activity

    The ratio of the time active signals and their corresponding hangover time and front end
delay occupy the trunk channels to the total measuring time, averaged over the total number of trunk
channels included in the measurement.

2.15    speech activity factor

    The ratio of the time active speech signals with their corresponding hangover time and front
end delay occupy a trunk channel to the total measuring time, averaged over the total number of trunk
channels carrying speech signals.

2.16    voice-band data ratio

    The ratio of the number of trunk channels carrying voice-band data signals to the total num-
ber of trunk channels averaged over a fixed interval of time.

2.17    64 kbit/s unrestricted digital data ratio

    The ratio of the number of trunk channels carrying 64 kbit/s unrestricted digital data signals
to the total number of trunk channels averaged over a fixed interval of time.

2.18    DCME overload (mode)

    The condition when the number of input trunk channels instantaneously active carrying
speech exceeds the number of 32kbit/s channels available for interpolation.

2.19    overload channels

    The additional bearer channel capacity which is generated using VBR encoding to minimize
or eliminate DSI competitive clipping.

2.20    average bits per sample

    The average number of encoding bits per sample computed over a given time window for the
ensemble of active interpolated bearer channels within a given interpolation pool. Only bearer chan-
nels carrying speech are included in this calculation.

2.21    transmission overload

    The condition when the average bits per sample goes below the value set in accordance with
speech quality requirements.

2.22    freeze-out

    The condition when a trunk channel becomes active and cannot immediately be assigned to a
bearer channel, due to lack of available transmission capacity.

2.23    freeze-out fraction (FOF)

    The ratio of the total time that the individual channels experience the freeze-out condition to
the total time of the active intervals and their corresponding hangover times and front end delays, for
all trunks over a fixed interval of time.

2.24    interpolation gain (IG)

    The trunk channel multiplication ratio which is achieved through DSI. The IG is the ratio of
the number of trunk channels to the number of DCME bearer channels where the same signal encod-
ing rate is used for trunk and bearer channels. The achievable gain depends on the ensemble activity
and the system size.

2.25    transcoding gain (TG)

    The transmission channel multiplication ratio which is achieved through LRE, which effec-
tively creates a number of low rate encoded bearer channels which is greater than the number of
available transmission channels. When only a transcoding process conforming to the 32kbit/s portion
of RecommendationG.726 is used, the TG will equal2. When no transcoding is used the TG will
equal1. When overload channels are created the TG will be greater than2.

2.26    DCME gain (DCMG)

    The trunk channel transmission multiplication ratio, which is achieved through application of
DCME, including LRE and DSI. Hence DCMG=TG╖IG.

2.27    clique

    A set of bearer channels which are associated with a set of trunk channels which are indepen-
dent in operation and control from other bearer channels. The set of trunk channels is directed to a
single destination.

    NoteûAn alternative term for clique is bundle.

2.28    multi-clique mode

    A DCME operational mode in which more than one clique is used when each clique is asso-
ciated with a different destination.

2.29    multi-destination mode

    A DCME operational mode where traffic is exchanged between more than two (2) corre-
sponding DCMEs simultaneously and trunk channel traffic is interpolated over a pool of available
bearer channels for all destinations having traffic in the pool. The transmit trunk channels are desig-
nated to receive trunk channels at corresponding locations.

2.30    silence elimination

    When voice-band data traffic is recognized on a trunk channel, the DCME sets a long hang-
over time to ensure that no clipping will occur in case of half-duplex transmission.

    In many cases (e.g. facsimile group 3 transmission), the backward direction is mainly used
for the transmission of acknowledgements, and the return trunk channel has therefore a very low rate
of activity. If the long hangover time was still in operation, there would be a significant waste of
bearer capacity.

    The use of a second hangover time, shorter than the initial one, will allow making the bearer
capacity on the backward direction available to the interpolation pool, and is called silence elimina-
tion.

3    DCME functions

3.1    General

    This Recommendation defines DCME which provides circuit multiplication by means of
ADPCM and DSI.

    For operation between Administrations using 2048kbit/s interfaces, the channel side (bearer)
interface to/from the DCME shall be based on the 2048kbit/s interface.

    For operation between Administrations using 2048 kbit/s interfaces and Administrations
using 1544kbit/s interfaces, the channel side (bearer) interface to/from the DCME will be based on
the 2048kbit/s interface.

    For operation between Administrations using 1544 kbit/s interfaces, the channel side (bearer)
interface to/from the DCME may be based on either the 1544kbit/s or the 2048kbit/s interface
dependent on bilateral agreement.

    There may be operational difficulties with ISC/DCME interworking depending on whether
the DCME is type1, where the DCME cannot communicate with the ISC, or type2, where it can, as
defined in RecommendationQ.50.

3.2    Purpose

    The purpose of DCME is to provide maximum effective use of transmission facilities in the
digital operating environment, using DSI and LRE techniques. At a minimum, the DCME functions
shall include:

û    interpolation of speech signals (DSI);

û    transcoding of 64 kbit/s PCM to ADPCM when applicable;

û    the means to carry the ISDN bearer services given in º1.1:

i)    speech,

ii)    3.1 kHz audio (data and speech),

iii)    64 kbit/s unrestricted;

û    one or more of the following operating modes:

i)    point-to-point,

ii)    multi-clique,

iii)    multi-destination;

û    speech detection;

û    voice-band data detection;

û    facsimile compression (under study);

û    a means for transmit detection and receive injection of background noise;

û    the means to accommodate non-interpolated pre-assigned traffic;

û    a means for interterminal communication (control channel);

û    a means for exchanging signals with an ISC for purposes of ISDN bearer services involving
64kbit/s unrestricted traffic, DLC, and alarms;

û    time slot interchange;

û    the ability to transport the following signalling systems:

i)    CCITT No. 5,

ii)    CCITT No. 6 (both analogue and digital versions),

iii)    CCITT No. 7,

iv)    R1 (Note 1 of º3.2),

v)    R2 (Note 1 of º3.2).

    Note 1 of º 3.2 û CCITT Signalling Systems R1 and R2 may be transported, but each will
require its own special interface. It is recommended that the transmission of line signals is performed
using special messages in the control channel.

    The DCME will perform processing on traffic between the trunk interface and bearer inter-
face as defined in Table1/G.763 and explained below:

    a)    Speech traffic is ADPCM encoded and subject to DSI. The bit rate of individual bearer
channels provided for speech is instantaneously either32, 24, or optionally 16kbit/s
dependent on traffic loading. If the optional 16kbit/s overload feature is activated
and being used, the bit rate of the bearer channels provided for speech is 24kbit/s or
16kbit/s dependent on traffic loading.

    b)    Voice-band data traffic is initially subject to DSI. Bearer channels provided for traffic
recognized as voice-band data are ADPCM encoded at 40kbit/s and are protected
against bit reduction and clipping.

    c)    64 kbit/s unrestricted traffic may be connected on demand to bearer channels transpar-
ently (not subjected to DSI and ADPCM) if an out-of-band control system to/from
the ISC is provided to identify the relevant trunk channel.

    d)    Alternate speech/64 kbit/s unrestricted traffic may be accommodated subject to the provi-
sion of an out-of-band control facility and in-call modification signals from the ISC.

    e)    64, 40 and 32 kbit/s channels may be pre-assigned for leased line services which are not
to be subjected to DSI. Optionally 24kbit/s or 16kbit/s pre-assigned channels may
be used for maintenance purposes only.

    f)    CCITT Signalling System No. 5 will be passed transparently through the DCME. CCITT
Signalling Systems Nos.6 and7 can be accommodated through 64kbit/s pre-
assigned channels.

    g)    If provided with optional user signalling modules (USM), the DCME will convey line
signalling information within the control channel. Two USM modules are presently
considered, R1USM and R2USM (see Note1 of º3.2 above). Requirements have
been defined for an R2USM.



    The actual circuit multiplication gain achieved will be dependent upon traffic loading, speech
activity, the percentage and type of voice-band data (e.g.facsimile traffic), the number of on-demand
unrestricted 64kbit/s channels, the number of pre-assigned channels, and the size of the interpolation
pools.

    The total delay associated with the establishment of dynamically assigned ADPCM encoded
bearer channels by the transmit DCME shall not exceed 30ms. The total delay associated with the
establishment of dynamically assigned ADPCM encoded bearer channels by the receive DCME shall
not exceed 15ms. The delay values exclude the effects of Doppler and plesiochronous buffers and
exclude the delays associated with the establishment and disestablishment of demand assigned
64kbit/s unrestricted circuits.

4    Operational modes

4.1    General

    The following modes of operation are described:

a)    point-to-point;

b)    multi-clique;

c)    multi-destination; and

d)    interoperation.

    The DCME multiple destination capability for multi-clique and multi-destination modes is
summarized in Table2/G.763.



4.1.1    Point-to-point mode

    See Figure 1/G.763.

4.1.1.1    Point-to-point

    Using Figure1/G.763 for reference, the transmit side DCME concentrates Ntrunk channels
at 64kbit/s into N/G transmission channels. The transmission channels represent a number of time
shared variable bit rate (bearer) channels which are grouped into a primary rate multiplex format.

    At the receive side, the receiving DCME simply demultiplexes the primary-rate format and
reconstitutes the Ntrunk channels from the N/G transmission channels.

Figure 1/G.763 = 5,5 cm



4.1.2    Multi-clique mode

    See Figure 2/G.763.

4.1.2.1    Multi-clique mode

    In this mode the pool of bearer channels is subdivided into two independent pools (cliques) of
fixed capacity, each being for an individual destination. While the aggregate bearer bit rates for both
the transmit side and the receive side are equal, the DCMG of each clique may be different since this
gain is a function of the number of input channels to be routed within each clique. It is desirable to
limit the number of cliques within a primary rate bearer to two. Figure2/G.763 indicates one form of
this approach in which the primary rate bearer circuit is assumed to be available to each of the DCM
nodes, but each node has the capability of preselecting the traffic that is intended for it. The multi-
clique mode may be useful to prevent qdu accumulation when DCME terminals are operated in tan-
dem. This subject is under study.

Figure 2/G.763 = 10 cm



4.1.3    Multi-destination mode

    See Figure 3/G.763.

4.1.3.1    Multi-destination mode

    In this mode, the input trunk channels are interpolated over a common pool of bearer chan-
nels, regardless of their destination. The input trunk channels are destination pre-assigned so that they
may be routed to the appropriate destination in accordance with the control channel messages. This
operational mode permits higher DCMG than the multi-clique mode but its usefulness is limited if the
DCME is located at the ISC.

Figure 3/G.763 = 10 cm



4.1.4    Interoperation

    DCME with the multi-destination option shall interwork with DCME of the point-to-point
option when the multi-destination DCME is configured with a single destination pool. The single des-
tination pool shall be used for interworking.

    DCME with the multi-destination option shall interwork with DCME of the multi-clique
option when the multi-destination DCME includes a single destination pool. The single destination
pool shall be used for interworking.

4.2    Modes of assignment of channels to the bearer structure

4.2.1    Pre-assignment

    It shall be possible to pre-assign 64kbit/s trunk channels to 64kbit/s bearer channels in the
pool (8bits within the bearer frame). The number of pre-assigned 64kbit/s trunk channels shall be
preset under operator control from zero to the maximum number of complete 8bit time slots within
the pool in increments of one 64kbit/s channel.

    It shall be possible to pre-assign 64kbit/s trunk channels to 40kbit/s bearer channels in the
pool (5bits within the bearer frame structure). The number of pre-assigned 40kbit/s bearer channels
shall be preset under operator control from zero to the maximum determined by the pool size in incre-
ments of one 40kbit/s channel.

    It shall be possible to pre-assign 64kbit/s trunk channels to 32kbit/s bearer channels in the
pool (4bits within the bearer frame). The number of pre-assigned 32kbit/s bearer channels shall be
preset under operator control from zero to a maximum determined by the pool size in increments of
one 32kbit/s channel.

    As an option it shall be possible to pre-assign 64kbit/s trunk channels to 24kbit/s or 16kbit/
s bearer channels in the pool. Each 24kbit/s or 16kbit/s bearer channel will occupy the most signifi-
cant three bits or two bits respectively of a 32kbit/s pre-assigned bearer channel and will be used for
maintenance purposes only. The number of pre-assigned 24kbit/s or 16 kbit/s bearer channels shall
be preset under operator control from zero to a maximum determined by the pool size in increments
of one 32kbit/s bearer channel.

4.2.2    Dynamic assignment

    The DCME shall be capable of assigning on-demand 64kbit/s unrestricted traffic to 64kbit/s
bearer channels in the pool (8bits within each bearer frame) using an out-of-band control facility
between the ISC and the DCME for seizure/release of 64kbit/s bearer channels as defined in º5. The
provision of the ISC control facility is at the users' option. The transmit and receive assignment pro-
cesses are described in ºº6, 7 and8.

    The DCME shall be capable of dynamically assigning voice traffic within 64kbit/s trunk
channels to bearer channels at bit rates of32, 24, and optionally 16kbit/s in each pool (4bits, 3bits or
2bits within each bearer frame). The transit and receive assignment processes are described in ºº6
and7.

    The DCME shall be capable of dynamically assigning voice-band data traffic within a
64kbit/s trunk channel to 40kbit/s bearer channels (5bits within each bearer frame). The transmit
and receive assignment processes are described in ºº6 and7.

5    Interface requirements

    The DCME shall be interconnected with a local or remote ISC(s) by means of the trunk inter-
face equipment and a DCME ISC signalling system. There is a maximum channel capacity of 216
trunk channels as a consequence of fundamental limitations in the assignment message numbering
scheme. Therefore, the trunk interface equipment shall be capable of accommodating seven
2048kbit/s primary multiplex streams or nine 1544kbit/s primary multiplex streams.

    Trunk channels (TCs) are related one-to-one to the intermediate trunks (ITs) by a TC to IT
mapping facility within the DCME to permit configuration control of the trunk time slots and to adopt
a channel numbering convention for DCME-to-DCME operation.

    Local ITs are used by the transmit DCME and are identified within the DCME-to-DCME
control channel messages. Remote ITs are received in the control channel messages from correspond-
ing DCMEs.

    In the case of interworking between the 1544 kbit/s and 2048 kbit/s hierarchies on the same
DCME, it is recommended in RecommendationG.802 that the bearer system be 2048kbit/s.

    There may be operational difficulties with ISC/DCME interworking depending on whether
the DCME is type1, where the DCME cannot communicate with the ISC, or type2, where it can, as
defined in RecommendationQ.50.

5.1    Transmission interface: trunk side

5.1.1    Trunk side interface at 2048 kbit/s

a)    The electrical characteristics shall comply with RecommendationG.703. The test load
impedance shall be either 75W unbalanced or 120W balanced depending on the user
requirement.

b)    The frame structure shall comply with RecommendationG.704.

c)    The encoding law for voice frequency signals shall conform to the A-law system described
in RecommendationG.711.

5.1.2    Trunk side interface at 1544 kbit/s

a)    The electrical characteristics shall comply with RecommendationG.703. The line code
adopted shall be either AMI or B8ZS depending on the user selection.

b)    The frame structure shall comply with RecommendationG.704. The multi-frame size shall
be either 24frames or 12frames depending on the user selection.

c)    The encoding law for voice frequency signals shall conform to the m-law system described
in RecommendationG.711.

5.2    Transmission interface: bearer side

5.2.1    Bearer side interface at 2048 kbit/s

5.2.1.1    General

    For the point-to-point and multi-clique modes, the bearer interface shall consist of one
2048kbit/s interface on the transmit side and one 2048kbit/s interface on the receive side.

    For the multi-destination mode, the bearer interface shall consist of one 2048kbit/s interface
on the transmit side and one to four 2048kbit/s interfaces on the receive side.

5.2.1.2    Electrical characteristics

    The electrical characteristics shall comply with RecommendationG.703. An optional non-
return-to-zero(NRZ) electrical interface may be provided for special applications. The test load
impedance shall be either 75W unbalanced or 120W balanced depending on the user requirement.

5.2.1.3    Bearer frame structure

    The bearer frame structure shall comply with RecommendationG.704. Time slot0 shall be
used as recommended inG.704 and time slots 1to31 shall carry control channels and traffic accord-
ing to the DCME frame structure.

5.2.2    Bearer side interface at 1544 kbit/s

5.2.2.1    General

    For the point-to-point and multi-clique modes, the bearer interface shall consist of one
1544kbit/s interface on the transmit side and one 1544kbit/s interface on the receive side.

    For the multi-destination mode, the bearer interface shall consist of one 1544kbit/s interface
on the transmit side and one to four 1544kbit/s interfaces on the receive side.

5.2.2.2    Electrical characteristics

    The electrical characteristics shall comply with RecommendationG.703. An optional non-
return-to-zero (NRZ) electrical interface may be provided for special applications.

    Due to the compressed nature of the DCME bearer interface and the necessity for 64kbit/s
unrestricted channel transmission, robbed-bit zero code suppression (ZCS) line coding techniques are
prohibited on the 1544kbit/s bearer channel interface. Only bipolar eight zero substitution (B8ZS) or
zero byte time slot interchange (ZBTSI) line coding techniques are permitted.

5.2.2.3    Bearer frame structure

    The bearer frame structure shall comply with RecommendationG.704.

    Provisions shall be included in the bearer frame structure to accommodate control channels
and traffic according to the DCME frame structure.

    The 193rd  bit shall be used for frame synchronization as recommended in
RecommendationG.704.

5.3    Signalling interfaces to switching equipment (ISC)

    The choice of interface is left for each administration to define within the constraints of their
transmission facilities and ISCs.

    The signalling interface to the switching equipment is dependent on the capability of the ISC
and the facilities between the ISC and the DCME (see RecommendationQ.50).

5.3.1    DCME-ISC signalling interface functions

    The following groups of functions are defined in RecommendationQ.50.

5.3.1.1    Transmission resource management

    Facilitates the dynamic load control process within the ISC and the DCME concurrently,
based on the status of the traffic loading on the DCME system. The requirements for this function are
given in º9.

5.3.1.2    Seizure/release of 64kbit/s circuits (see Note)

    Used in the DCME for the generation of internal assignment and disconnection messages and
in the ISCs for the validation of circuit seizure selection/release based on acknowledgement from the
DCME. The requirements for this function are given in º8.

    NoteûIf the implementation of the ISC does not permit seizure/release of 64kbit/s circuits,
the provision of 64kbit/s circuits may be accomplished under bilateral agreement by pre-assignment.

5.3.1.3    Maintenance information

    Facilitates information exchange between the DCME and the ISCs pertaining to the mainte-
nance status. Maintenance status information may be exchanged between the DCME and the ISC.
This function may include the transfer of circuit supervision and alarm conditions referred to in º15.

    The DCME-ISC signalling system consists of one or more control links, a DCME control
interface within the ISC and a switching centre interface (SCI) within the DCME. The selection of the
DCME-ISC signalling system, including the physical and electrical interface characteristics are at the
users' option. To permit this the SCI is defined with minimum functional requirements. Refer to
Figure4/G.763.

Figure 4/G.763 = 11 cm



5.3.2    External and internal messages/indications

    The SCI shall process the following external information elements (between the DCME and
the ISC) and the following internal messages/indications (within the DCME). Depending on the char-
acteristics of the chosen DCME-ISC signalling system, all of the following required external informa-
tion elements may not be used.



    External information element                    Acronym
    (Recommendation Q.50)

Capacity for speech available                    SA

Capacity for speech not available                    SNA

Capacity for 3.1 kHz data available                VDA

Capacity for 3.1 kHz data not available                VDNA

Capacity for 64kbit/s unrestricted                    UCA
available

Capacity for 64kbit/s unrestricted                    UCNA
not available

Seizure/select 64 kbit/s circuit                    S64

Seizure/select 64 kbit/s positive                    S64Ack
acknowledged

Seizure/select 64kbit/s negative                    S64NAck
acknowledged

Release 64 kbit/s circuit                         R64

Release 64 kbit/s circuit acknowledged                R64Ack

Circuit out-of-service                        Out-of-service

Circuit back-in-service                         Back-in-service


    Internal messages/indications                    Acronym

Activate DLC for voice/voice-band                 ADVD
data traffic

De-activate DLC for voice/voice-band                DDVD
data traffic

Activate DLC for 64 kbit/s traffic                    AD64

De-activate DLC for 64 kbit/s traffic                DD64

    The interaction of these external information elements with the on-demand 64kbit/s circuit
handler (TCH), the dynamic load control (DLC) function and the operations and maintenance func-
tion is described in ºº8, 9 and15, respectively.

    The format of all signals and messages is dependent upon the internal DCME design imple-
mentation and the chosen signalling interface, and is therefore not specified herein.

5.3.3    Circuit numbering translation

    The SCI will perform the translation between the internal DCME IT numbering and the trunk
channel identification used for the selected DCME ISC signalling system. This translation will be
performed for any signalling function that requires individual trunk channels to be identified.

5.3.4    Transmission resource circuit mapping

    The SCI will perform the mapping between each destination to which internal DLC messages
apply and the primary multiplex streams, trunk channels, or time slots (depending on the selected sig-
nalling system) to which the associated external information elements apply. This mapping will make
use of the TC-IT map information resident in the DCME described in º15.1.

5.4    Man-machine interface

    The DCME shall contain a system command structure which serves as a menu-driven inter-
face between internal functions and the system operator. Typically two V24 ports are necessary to
provide operator access to the equipment, one for a display terminal and one for a printer.

5.5    Operations function interface

5.5.1    Trunk side operation at 2048 kbit/s or 1544 kbit/s

    The utilization of spare bits for monitoring and error protection shall be in accordance with
RecommendationsG.704 andG.706.

5.5.2    Bearer side

5.5.2.1    Single destination mode

    The utilization of spare bits for monitoring and error protection is under study.

5.5.2.2    Multi-clique or multi-destination mode

    The utilization of spare bits for monitoring and error protection is under study.

5.6    Local alarms interface

    The DCME must present alarms to the local entity according to the user's requirement. The
choice of the physical/electrical interface is to be decided by the individual Administration. In the
case of individual voltage-free loop alarms, the categories of alarm in RecommendationG.803 should
be included. In the case of a serial alarm interface it is recommended to provide as a minimum the fol-
lowing signals:

a)    initial occurrence of an alarm in the monitored DCME;

b)    initial occurrence of a clear in the monitored DCME;

c)    receipt of a data request from the local entity;

d)    initial system power-on.

    NoteûIt is intended to study the inclusion of telecommunications management network
(TMN) protocols and interface requirements in future DCME Recommendations.

5.7    External clock interface

5.7.1    DCME working with 2048 kbit/s transmission interfaces

    The external clock interface shall comply with RecommendationG.703, º10.3. The test load
impedance shall be either 75ohms unbalanced or 120ohms balanced depending on the user require-
ment.

5.7.2    DCME working with 1544 kbit/s transmission interfaces

    The timing is normally derived from an incoming digital link at 1544kbit/s complying with
RecommendationG.703, º2. Where required an external clock interface may be provided.

5.8    DCME frame structure

5.8.1    2048 kbit/s structure

    The bearer structure shall be compatible with the format specified in
RecommendationG.704. The bearer structure shall contain 32consecutively numbered 8bit time
slots, from 0to31. Time slot0 shall be used for frame synchronization and special functions in accor-
dance with RecommendationG.704. Time slots1 through31 shall be used to carry the DCME control
channel(s) and traffic. The control channels are comprised of a unique word and a control channel
message as described in º11. In all figures used to illustrate the bearer frame structure, the left-most
bit shall be transmitted first.

    Sixteen125 msec bearer frames constitute one 2.0ms DCME frame. The DCME frame is not
required to be aligned with the multiframes defined in RecommendationG.704. The beginning of the
DCME frame is identified by a unique word in the control channel(s).

5.8.2    1544 kbit/s structure

    The bearer structure shall be compatible with the format specified in
RecommendationG.704. Alternatives for 24-frame multiframe structure or 12-frame multiframe
structure will be as agreed upon by the users. The bearer structure shall contain a framing bit (F-bit)
and 24 consecutively numbered 8bit time slots, from 1to24. The F-bit shall be used in accordance
with RecommendationG.704. Time slots1 through24 shall be used to carry the DCME control chan-
nel(s) and traffic. The control channel(s) are comprised of a unique word, and a control message as
described in º11. In all figures used to illustrate the bearer frame structure the left-most bit shall be
transmitted first.

    Sixteen 125 msec bearer frames constitute one 2.0msec DCME frame. The DCME frame is
not required to be aligned with the multiframes defined in RecommendationG.704. The beginning of
the DCME frame is identified by a unique word in the control channel(s).

5.9    Bearer BC numbering and use of the bearer frame

    As shown in Figure5/G.763 for the 2048kbit/s structure and Figure6/G.763 for the
1544kbit/s structure, one or two pools may be formed. Each pool shall contain an integer number of
8-bit time slots. The first 8-bit time slot of the first pool shall be TS1. The last 8-bit time slot of the
second pool shall be TS31 (2048kbit/s structure) or TS24(1544kbit/s structure). The upper bound-
ary of the first pool and the lower boundary of the second pool shall be independently programmable
(pre-set) at 8-bit time slot boundaries (see Note). Each pool will contain an even number of contigu-
ous 4-bit time slots. The left-most 4-bit time slot shall carry the control channel as specified in º11.
The remaining 4-bit time slots of the pool are bearer channels (BCs) and are used to carry traffic.

    NoteûThe entire bearer structure need not be utilized by the pool(s). The unused portion of
the bearer will contain an integer number of 8-bit time slots. This flexibility facilitates received pool
sorting by a PCM cross-connect.

    In the case where a bearer structure contains two pools (two control channels), transmit pools
shall be mutually DCME frame aligned. Receive pools may not be mutually DCME frame aligned.

    The normal range BCs of a pool are consecutively numbered from 1 to p, with BC No.1 being
the 4-bit slot next to the control channel andp the total number of 4-bit slots in the pool, excluding the
control channel. This numbering scheme is shown in Figures5/G.763 and6/G.763. The BC number
contained in the assignment message can either be in the range1 through61 (normal BC numbering
range) or in the range64 through83 (overload BC numbering range). If the optional 2bit encoding
mode is available and enabled, the overload BC numbering range is from 64to124. BCs in the nor-
mal range may consist of either8, 5, 4,3, or optionally 2bits. These bits are obtained from bits of the
bearer frame as described below.

    BCs in the overload range may be disconnected or connected. If disconnected, they will not
be associated with any bit of the bearer structure. If connected, they may consist of either4, 3, or
optionally 2bit channels and will be associated with bits of the bearer frame as discussed later.

    The criteria for associating the BC contained in the assignment message to bits within the
bearer structure are as follows:

Figure 5/G.763 = 10,5 cm



Figure 6/G.763 = 10,5 cm



5.9.1    8 bit (64 kbit/s) BCs

    These are used for the assignment of unrestricted 64kbit/s ITs. The BC number in the assign-
ment message indicates the bearer BC (even number) which carries the first 4bits (nibble) of the 8 bit
sample. The second nibble is carried by the next higher BC. Refer to Figure7/G.763.

Figure 7/G.763 = 6,5 cm



5.9.2    5-bit (40 kbit/s) BCs

    These are used for the assignment of voice-band data ITs. The BC number in the assignment
message indicates the bearer which carries the first 4bits of the 5-bit sample. The 5th bit (LSB) is
obtained from a different bearer which is independently assigned as a Bit Bank. The Bit Bank consti-
tutes a bit pool providing one bit for up to four data channels. The selection of the 5th bit for a data IT
is regulated by the DCME processes. Refer to Figure8/G.763.

Figure 8/G.763 = 7 cm



5.9.3    Normal range 4-bit BCs

    These BCs are used for the assignment of bit banks. The BC number in the assignment mes-
sage indicates the bearer BC performing the bit bank function.

5.9.4    Normal range 4/3-bit (32/24 kbit/s) BCs

    These BCs are used for the assignment of voice ITs. The BC number in the assignment mes-
sage indicates the bearer BC which carries the IT bits. These can be either three or four depending on
whether the bearer BC LSB is used for the creation of an overload BC during high load conditions.
Bit stealing will occur randomly for the purpose of voice quality equalization over the ensemble of
voice ITs. The bit stealing function is controlled by the DCME processes. Refer to Figure9/G.763.

Figure 9/G.763 = 16,5 cm



5.9.5    Overload range 4/3-bit (32/24 kbit/s) BCs

    These BCs are used, during heavy load conditions, for the assignment of voice ITs. These
BCs can be either 3or 4bits as determined by the DCME processes. Changes from 3to 4bit encod-
ing (and vice versa) will occur randomly for the purpose of voice quality equalization over the ensem-
ble of voice ITs. The BC number in the assignment message has no direct correspondence to any
bearer BC. Refer to Figure10/G.763.

Figure 10/G.763 = 14,5 cm



5.9.6    Normal and overload range 3/2 bit (24/16 kbit/s) BCs resulting from the optional 3/2 bit over-
load procedure

    If the optional 2 bit ADPCM encoding feature is available and enabled, normal and overload
channels may operate in 3/2 bit mode as required by the 3/2bit overload procedure (º6.1.7.2). This
procedure parallels the 4/3bit procedure and it is invoked when more overload channels are required
than provided by the 4/3 bit procedure.

5.9.7    Pre-assigned BCs

    It is possible to select certain ITs for a semi-permanent connection to the bearer resources
(pre-assigned ITs), therefore bypassing the dynamic assignment function (DAF) of the DCME.64, 40
and 32kbit/s ITs can be pre-assigned.

    The optional 24kbit/s or 16kbit/s pre-assigned channels intended for maintenance purposes
will occupy the most significant 3 or 2bits respectively of the 32kbit/s pre-assigned normal range
BCs.

    The allocation of pre-assigned ITs to portions of the bearer frame is specified by entering the
appropriate information into the DCME configuration data (see º6.1).

    The BC specified in the configuration data indicates the bearer BC carrying the first four bits
of the IT. For a 64kbit/s IT, the BC must be even numbered (the use of the next higher BC for this
64kbit/s IT is implied). A sufficient number of Bit Banks must be pre-assigned to provide the 5th bit
for the pre-assigned 40kbit/s channels.

    The bearer BCs carrying 40kbit/s pre-assigned ITs shall be contiguous starting from bearer
BCNo.1. The lowest bearer BC numbers shall be used for the Bit Banks required for 40kbit/s pre-
assigned ITs, followed by the pre-assigned 40kbit/s BCs.

    It is recommended that the pre-assigned 32kbit/s ITs (other than bit banks) and the pre-
assigned 64kbit/s ITs also utilize the lower portion of the bearer BC numbers.

6    DCME transmit unit

    The function of the DCME transmit unit structure is to provide connections between the ITs,
the ADPCM encoders and the BCs, and to generate assignment messages for correspondent DCMEs.
At initialization, the various transmit side functions are loaded with the appropriate configuration
data, and pre-assigned ITs are connected to ADPCM encoders and BCs, as required. Each dynami-
cally assigned IT is continuously monitored for detection of activity and classification as voice, data
or signalling. Active ITs are then dynamically assigned to available BCs (and ADPCM encoders). At
the request of the ISC, 64kbit/s IT are assigned to available BCs and kept connected until the ISC
releases the circuit. Assignment information is sent to the remote DCME via an assignment message
which is generated once during every 2ms DCME frame. The actual connection is implemented three
DCME frames following transmission of the message. This delay is necessary in order to provide
adequate time for processing the message before the associated ADPCM BC samples arrive at the
DCME receive unit.

    This section specifies those aspects of the DCME transmit side structure which are necessary
to accurately define the DCME transmit unit/receive unit interaction. An example of a DCME trans-
mit side structure which satisfies the interaction requirements specified in this section is given in
AnnexA.1.

6.1    Transmit channel processing function

    The transmit channel processing (TCP) function examines the input ITs and classifies them
according to their signal type and status. Service requests are placed in assignment queues as a conse-
quence of IT status and type transitions. The assignment queues are serviced and the associated
assignment messages are then generated. In servicing the assignment queues, the ADPCM encoders
are directed to operate at various bit rates under the control of the overload channel creation function,
the data/speech discriminator and the transparent circuit handler (TCH). The resulting ADPCM sam-
ples are dynamically placed in the DCME output bearer frame at specific BC locations under the con-
trol of the TCP function.

6.1.1    DCME transmit unit initialization

    At initialization, the DCME transmit unit channel connectivity map shall be set to a known
state (BCs and ITs disconnected) and the TCP parameters shall be loaded. This includes the informa-
tion necessary for the allocation of pre-assigned channels and bit banks. The pre-assigned channel
allocation (determined by the configuration data) shall be in accordance with the bearer structure
requirements (ºº5.2 and5.9).

6.1.2    Intermediate trunk classification

    The intermediate trunk signals must be continually examined to determine their activity and
their type (i.e.speech, signalling or data). The activity and type characteristics of the intermediate
trunk signals are determined by the activity detector, the data/speech discriminator and the signalling
detector. Transitions from one activity/type state to another are used by the input pre-processor func-
tion to generate service requests.

    The intermediate trunk classification process shall classify input signals as specified below.

a)    Initially, this function shall classify an IT as either pre-assigned, if so designated by the
configuration data, or as voice-inactive, if subject to dynamic assignment.

b)    Whenever a 64 kbit/s assignment request transpreq indication is received from the TCH,
the IT shall be classified as transparent and shall remain in this condition until a 64kbit/s
disconnection request transprel indication is received from the TCH, in which case the
signal classification shall change to voice-inactive.

c)    If an IT is active and of the voice/signalling type and a data-detect indication is received
from the data/speech discriminator, the IT shall be classified as data-active. The same
applies to the case of reception of a Rxdata indication from the DCME receive side. The
Rxdata indication is generated by the DCME receive unit when an assignment message is
received which establishes a voice-band data connection.

If an IT is inactive and of the data type and an act indication is received from the activity
detector, the IT shall be classified as data-active.

d)    If an IT is inactive and of the voice/signalling type and a Rxdata indication is received, the
IT shall be classified as data-inactive.

If an IT is of the data type and the hangover expires, the IT shall be classified as data-
inactive.

e)    If an IT is of the voice/signalling type and the hangover expires, the IT shall be classified as
voice-inactive.

f)    If an IT is inactive and of the voice type and an act indication is received from the activity
detector, the IT shall be classified as voice-active.

g)    If an IT is active and of the data type and a voice-detect  indication is received from the
data/speech discriminator, the IT shall be classified as voice-active.

If an IT is inactive and of the voice type and an act message is received, the IT shall be
declared voice-active.

h)    If an IT is active and of the voice type and a signaldetect indication is received from the
signalling detector, the IT shall be classified as signalling-active.

If an IT is of the signalling type and an act indication is received, the IT shall be classi-
fied as signalling-active.

i)    If an IT is active and of the data type and a signaldetect indication is received, the IT shall
be classified as signalling-active.

If an IT is active and of the voice type and a signaldetect indication is received, the IT
shall be classified as signalling-active.

    When activity terminates on an IT classified as voice-active, the voice hangover value shall be used.
When activity terminates on an IT classified as signalling-active, the signalling hangover value shall
be used. The voice and signalling hangover values shall be in accordance with the hangover masks
specified in º12.

    Provisions shall be provided to maintain channel connectivity between page changes in the forward
direction of a facsimile transmission and to release the reverse channel connection between proce-
dural signal transmissions so as to achieve a higher return link utilization for facsimile transmissions
(this feature is also referred to as silence elimination).

    The Rxdata indication which is generated by the DCME receive unit upon receiving a voice-band
data related assignment message shall be used to initiate a voice-band data connection at the DCME
transmit unit.

6.1.3    Input preprocessing

    The input preprocessing function examines the activity/type state transitions originating from
the intermediate trunk classification process and generates assignment service requests which are
placed in service request queues. The input preprocessing function shall process the intermediate
trunk state transitions as specified below.

    When a data-inact(IT) indication is received from the intermediate trunk classification pro-
cess, the BC connection to this IT shall be checked. If the type of the BC is data or voice, the BC type
shall be maintained and the BC shall be placed back into the pool of available BCs.

    When a voice-inact (IT) indication is received from the intermediate trunk classification pro-
cess, the BC connection to this IT shall be checked. If the type of the BC is data or voice, the BC type
shall be maintained and the BC shall be placed back into the pool of available BCs. If the BC is in the
overload range, a disconnect request shall be stored in the overload disconnect queue.

    When a Voice(IT) indication is received from the intermediate trunk classification process,
the type of the BC connected to this IT shall be checked. If the type of BC is voice, the BC type shall
be maintained and no request shall be generated. If the BC type is other than voice, a request shall be
stored in the voice assignment queue.

    When a data(IT) indication is received from the intermediate trunk classification process, the
type of the BC connected to this IT shall be checked. If the type of BC is data, the BC type shall be
maintained and no request shall be generated. If the BC type is other than data, a request shall be
stored in the data assignment queue.

    When a transp(IT) indication is received from the intermediate trunk classification process, a
request shall be stored in the 64kbit/s assignment queue.

6.1.4    Service request implementation

    The service request implementation function examines the service request queues and gener-
ates assignment messages in response to service requests as specified below. The priorities associated
with servicing the various queues have not been specified since they are implementation dependent
and do not affect the equipment interworking capability.

6.1.4.1    If the optional USM is used, the USM queue shall be addressed in DCME frames 0, n,
2n,etc. (i.e.every nth DCME frame) of the DCME multiframe wheren is a variable which may be
selected by the user. For optional R2USM, DCME frames0, 8, 16, 24, 32, 40, 48 and56 of the
DCME multiframe shall include 20bits comprising the synchronous part of the CC, which shall be
used to convey two IT numbers and their respective line signalling information. Upon servicing the
request, the message shall be deleted from the USM queue. The other service request queues shall be
addressed in the remaining DCME frames.

6.1.4.2    64 kbit/s disconnect request

    The request at the top of the 64kbit/s disconnect queue shall be addressed. An assignment
shall be generated which disconnects the IT. At implementation, the service request shall be deleted
from the 64kbit/s disconnect queue.

6.1.4.3    Overload disconnect request

    The request at the top of the overload disconnect queue shall be addressed. An assignment
shall be generated which disconnects the IT. At implementation, the serviced request shall be deleted
from the overload disconnect queue.

6.1.4.4    64 kbit/s assignment request

    The request at the top of the 64kbit/s assignment queue shall be addressed. The IT for which
the request was generated shall be checked to determine whether it is connected or disconnected.  If
the IT is connected, a count of the usable bits in the pool shall be taken to determine whether enough
capacity exists to accommodate the additional bits required. If no capacity exists, an assignment
which disconnects the available BC (and the associated IT) shall be generated.

    If the IT is connected and enough capacity exists to accommodate the additional bits, the BC
number of the connected bearer channel (numberk) shall be checked to determine whether it is even
or odd. Ifk is even, the next higher BC (number k+1) shall be examined. Ifk is odd, the next lower
BC (number k-1) shall be examined. The objective is to allocate the first nibble (containing the
MSB) of the 64kbit/s channel to an even numbered normal range BC. If the IT is disconnected, the
number of usable bits in the pool shall be counted to determine whether the request can be accommo-
dated (8bits are required). If sufficient capacity is available, the IT shall be assigned to the available
normal range BC pair. If sufficient capacity is not available, a refresh message shall be generated in
accordance with º6.1.5.

    If the assignment of a 64kbit/s channel requires that existing ITs be reassigned to different
BCs in order to make room in the DCME bearer frame for the 64kbit/s BC, then the reassignments
shall be done with highest assignment priority and in an orderly manner so that the connections
between assigned ADPCM encoders and ADPCM decoders are not broken. At implementation, the
service request shall be deleted from the 64kbit/s assignment queue.

6.1.4.5    Data request

    5 bit encoding is required for the transmission of a data channel. Four bits are obtained by
assigning the data IT to a 4bit BC in the normal BC range. The fifth bit (LSB) is obtained from a pool
of four bits referred to as the bit bank. Special 4bit BC channels of the bank type are created in the
bearer frame for this purpose. The criteria for creation of bank channels are specified in Table3/
G.763.



    The request at the top of the data assignment queue shall be addressed. First, it shall be deter-
mined whether a new bit bank is required. Then, the IT for which the request was generated shall be
checked to determine whether it is connected to a BC.

    If the IT is connected, a bit count shall be made to determine whether enough bearer capacity
exists for the allocation of the data IT (including the creation of an additional bank channel if
required).

    If sufficient capacity exists and a new bit bank is not required, an assignment of the data IT to
the connected BC shall be made.

    If a bit bank is required, an assignment message connecting the selected BC to IT No.250
shall be generated. At the next DCME frame, the data IT shall be assigned to the connected BC.

    If sufficient capacity is not available and the IT is connected, a disconnect message shall be
generated.

    If the IT is disconnected, a count of the usable bits in the pool shall be made to determine
whether enough capacity exists to allocate the data call. If sufficient capacity is not available, a
refreshment message shall be generated in accordance with º6.1.5. If sufficient capacity is available
and a new bit bank is not required, the data IT shall be assigned to an available BC. If the bit bank is
required, it shall be assigned first, and then the data IT shall be assigned to an available BC. If the
assignment of a voice-band data channel required that existing ITs be reassigned to different BCs in
order to make room in the DCME bearer frame for the 40kbit/s BC, then the reassignments shall be
done with highest assignment priority and in an orderly manner so that the connections between
assigned ADPCM encoders and ADPCM decoders are not broken. At implementation, the service
request shall be deleted from the data assignment queue.

6.1.4.6    Voice request

    The request at the top of the voice assignment queue shall be addressed. The IT for which the
request was generated shall be checked to determine whether it is connected to a BC.

    If connected and the BC type is available, the IT shall be assigned to the available BC.

    If the IT is disconnected, the usable bits in the pool shall be counted to determine whether
enough capacity exists to accommodate the voice call. If sufficient capacity does not exist, a refresh-
ment message shall be generated in accordance with º6.1.5.

    If sufficient capacity exists, the voice IT shall be assigned to an available BC.

    At implementation, the service request shall be deleted from the voice assignment queue.

6.1.5    Refreshment message generation

    In DCME frames when the USM queue is not to be addressed and there are no messages in
the remaining queues, a refreshment message shall be generated. A refreshment message shall also be
generated when a service request queue cannot be serviced due to unavailable bearer capacity unless
a disconnect message is generated.

    The refreshment shall be done by scanning the range of normal BCs (from BC No.1 to the
upper pool boundary) and the range of overload BCs (from BCNo.64 to the highest number permit-
ted). Pre-assigned BCs shall not be refreshed. Each dynamically assigned 64kbit/s connection shall
be refreshed but only limited to the even numbered BC (the next higher BC shall not be refreshed).
Every other refreshment message shall alternate between the normal and the overload BC range. In
each range, the BCs shall be refreshed sequentially from the lowest to the highest BC, restarting the
cycle after refreshment of the highest BC in the range. Whenever a BC is refreshed, all the required
information elements shall be inserted in the assignment message. The refreshment of a bit bank BC
shall be transmitted with IT No.250.

6.1.6    ADPCM encoder control

    Whenever a new assignment of a previously disconnected IT is made, an ADPCM encoder
shall be selected from the available encoders of the encoder pool. Whenever a reassignment of a pre-
viously connected IT is made, the ADPCM encoder currently associated with the IT shall be main-
tained.

    Whenever an IT is disconnected, the associated ADPCM encoder shall be returned to the
pool of available ADPCM encoders.

    Resetting of the ADPCM encoder shall be done when the IT connection to an ADPCM
encoder is changed. The ADPCM encoder shall be reset before establishing a new connection.

6.1.7    Bit bank handling and overload channel creation

    Inherent to the TCP function are the bit bank handling and the overload channel creation pro-
cesses. The bit bank handling process derives the LSB of each data channel from one of the existing
bit banks according to predetermined rules.

    When the overload mode is required, the overload channel creation process distributes the 3
bit encoding across the entire set of speech channels. The objective is to make the average encoding
rate almost equal for the normal voice BC (subject to bit stealing) and the overload channels. This is
achieved by stealing bits from eligible BCs in a pseudo-random fashion and by making each overload
BC alternate between 3bit and 4bit encoding (also in pseudo-random fashion).

    When the 4/3 bit overload channel creation procedure, described above, cannot provide the
required number of overload channels, the optional 3/2bit overload channel creation procedure may
be used. This procedure, similarly to the 4/3bit procedure, makes the average encoding rate almost
equal for the normal voice BCs (subject to bit stealing) and the overload channels. Pseudo-random bit
rotation and switching between two alternate overload channel sizes (3bit and 2bit channels) are also
used in this case.

6.1.7.1    Bit bank handling process

    The bit bank handling process maintains two lists of BCs which are used in allocating the
LSB of each data channel. All lists contain, in ascending order, the BC numbers that fall into the cat-
egories defined below. BCs are extracted from, or inserted into, these lists always keeping the BC
numbers in ascending order. A BC can appear only in one list at the same instant.

    Data list û This list contains all BC numbers which are connected to data channels. At initial-
ization this list contains no entries.

    Bit bank list û This list contains all BC numbers which are currently being used to form bit
banks. At initialization, this list contains no entries.

    Pre-assigned 40 list û This list contains all BC numbers that are pre-assigned as 40 kbit/s
channels. At initialization, this list contains no entries.

    A bit bank BC number shall be placed into the bank list at the generation of an assignment
message containing IT No.250, if the associated BC number does not already exist in the bit bank
list. The BC number in question shall be removed from the voice list when this occurs.

    A bit bank BC number is removed from the bank list when the bit bank BC is no longer
needed. The bit bank deletion shall be in accordance with the criterion specified in Table3/G.763.
When the conditions for the deletion of a bit bank exist, the highest numbered bit bank BC shall be
deleted. The BC number shall then be put back into the voice list.

    The bit position of the LSBs of the handled data channels (pre-assigned 40 or dynamically
assigned channels declared as data) shall be assigned in the following way:

a)    LSB of BC number in pre-assigned 40 list position 1: MSB of BC number in bank list posi-
tion 1;

b)    LSBs of BC numbers in pre-assigned 40 list positions 2 to 4: second, third and fourth bits,
respectively, at BC number in bank list position1;

c)    LSB of BC number in pre-assigned 40 list position 5: MSB of BC number in bank list
position2.

    This procedure is followed until the BC numbers in the pre-assigned 40list have been handled, after
which the BC numbers in the data list are handled in the same manner.

6.1.7.2    Overload channel creation process

    The overload channel creation process maintains two lists of BCs which are used in forming
overload channels. All lists contain, in ascending order, the BC numbers that fall into the categories
defined below.

    BCs are extracted from, or inserted into, these lists always keeping the BC numbers in
ascending order. A BC can appear only in one list at the same instant.

    Voice list û This list contains all BC numbers that are within the normal BC range and can
contribute bits for the creation of overload channels. At initialization, this list contains all normal BC
numbers subject to DSI.

    Overload list û This list contains all BC numbers that are within the overload BC range. At
initialization, this list contains no entries.

    When an assignment message is generated, the voice list or overload list is updated and the
list lengths Nv (voice list) and Nov (overload list)  are computed. If Nov is0, overload channel cre-
ation is not required.

6.1.7.2.1    4/3 bit overload channel creation procedure

    If Nov is greater than 0, but not greater than Nv/3 the number (N4) of channels in the over-
load range that will be carried at four bits per sample shall be computed as follows:

    In addition, when Nov is greater than 0, the integer variables Pv and Pov shall be computed
as follows:

Pv  = (IT modulo Nv)
Pov = (IT modulo Nov)

where, IT is the IT number contained in the assignment message (see note). Pv and Pov represent
voice and overload list positions. These positions are numbered from 0to Nv-1 and from 0to Nov-
1, respectively.

    NoteûIf an optional USM is being used, the IT number information in DCME frames 0, n, 2n,etc.
(i.e.every nth DCME frame) of the DCME multiframe shall also be used to create overload channels.

    The BCs stored in the overload list at the first N4 locations (modulo Nov) starting from the list posi-
tion Pov shall be marked as 4bit channels. The remaining BCs of the overload list shall be marked as
3bit channels.

    The 4/3 bit mode of the first BC in the overload list shall be checked to determine whether the 3bit or
4bit mode is used. If the mode is 3bit, the BCs stored in the voice list at the first three locations,
starting from the list position, Pv, shall be set to 3bit mode. The following bit associations shall be
entered into the BC bit map:

a)    MSB of BC in overload list position 0: LSB of BC in voice list position Pv;

b)    second bit of BC in overload list position 0: LSB of BC in voice list position (Pv+1 mod-
ulo Nv);

c)    LSB of BC in overload list position 0: LSB of BC in voice list position (Pv+2 modulo
Nv).

    If the first BC in the overload list is a 4 bit channel, items a) and b) above remain applicable,
c) changes andd) is added as shown below:

c)    third bit of BC in overload position 0: LSB of BC in voice list position (Pv+2 modulo
Nv);

d)    LSB of BC in overload list position: LSB of BC in voice list position (Pv+3 modulo Nv).

    The same procedure shall be applied to the second BC in the overload list, starting at either
position Pv+4 or Pv+3, depending on the 4/3 bit mode of the first BC.

    The same procedure shall be applied to the remaining BCs of the overload list. The voice list
BCs subject to bit stealing will be marked as 3bit channels, the remaining ones as 4bit channels. An
example of the procedure is illustrated in Figure11/G.763.

Figure 11/G.763 = 12 cm



6.1.7.2.2    3/2 bit overload channel creation procedure

    If Nov is greater than Nv/3 and the optional 2 bit overload feature is available and enabled,
the number (N3) of channels in the overload range that will be carried at three bits per sample shall be
computed as follows:

    The number (n2) of bearer channels in the voice list that will operate at two bits per sample
(i.e.these channels donate two bits) shall be computed as follows:

n2 = N3 - Nv + Nov ╫ 2

    In addition, the integer variables Pv and Pov shall be computed as follows:

Pv  = (IT modulo Nv)
Pov = (IT modulo Nov)

where, IT is the IT number contained in the assignment message (note). Pv and Pov represent voice
and overload list positions. These positions are numbered 0to Nv-1 and from0 to Nov-1, respec-
tively.

    NoteûIf an optional USM is being used the IT number information in DCME frames0, n, 2n, etc.
(i.e.every nth frame) shall also be used to create overload channels.

    The BCs stored in the overload list at the first N3 locations (modulo Nov), starting from the list posi-
tion Pov, shall be marked as 3bit channels. The remaining BCs of the overload list shall be marked as
2bit channels.

    The BC stored in the voice list at the first n2 locations (modulo Nv), starting from the list position Pv,
shall be marked as 2bit channels. The remaining BCs of the voice list shall be marked as 3bit chan-
nels (i.e.these channels donate one bit).

    In order to obtain the bit associations for the BC bit map, the donated bits from the channels of the
voice list shall be arranged in the following ordered sequence:





Place in the sequence
Donated Bit in voice List (see Note)
1st

2nd bit of BC at position  Pv

2nd

LSB of BC at position Pv

3rd

2nd bit of BC at position Pv+1

4th

LSB of BC at position Pv+ 1

5th

2nd bit of BC at position Pv+ 2

6th

LSB of BC at position Pv+ 2, etc.


    The 3/2 bit mode of the first BC in the overload list shall be checked to determine whether the
2 bit or 3 bit mode is used.

    If the first BC in overload list is a 2 bit channel, the following bit associations shall be entered
into the BC bit map:

a)    MSB of BC in overload list position 0: 1st bit of the sequence;

b)    LSB of BC in overload list position 0: 2nd bit of the sequence.

    If the first BC in the overload list is a 3 bit channel, the same procedure shall be applied to
item a), but itemb) changes and itemc) is added as follows:

b)    second bit of BC in overload list position 0: 2nd bit of the sequence;

c)    LSB of BC in overload list position 0: 3rd bit of the sequence.

    The same bit association procedure shall be applied to each remaining BC in the overload
list: for these BCs, the association will start from the first available bit in the donated bit sequence.

    This procedure is illustrated in Figure 12/G.763. A particular example for a pool of nine BCs,
No. 1 to BC No.9, is shown in Figure13/G.763.

    NoteûIn some cases the second bit of BC in voice list, indicated above, may not be available
depending on the value ofN2, in which case the sequence is compacted upwards.

Figure 12/G.763 = 9,5 cm





Assumptions

Computed parame-
ters

Nvo=9
ICoi=2
Nov=4

N3=3
N2=1
n2 =2

    NoteûThe overload channel bits are matched with the corresponding stolen bits of the voice
channels.



6.1.8    Connectivity implementation delay

    The IT-ADPCM Encoder-BC connection is implemented at the beginning of the DCME
frame which occurs three frames after the start of the DCME frame containing the applicable assign-
ment message. Refer to Figure14/G.763.

Figure 14/G.763 = 4,5 cm



7    DCME receive unit structure

    The function of the DCME receive unit is to provide connections between the BCs, the
ADPCM decoders and the ITs. At start-up, the various processes are loaded with the appropriate con-
figuration data, and pre-assigned BCs are connected to ADPCM decoders and ITs, as required.
Assignment messages are decoded to obtain information required for dynamic assignments of non-
pre-assigned BCs to ITs (and ADPCM decoders). A sufficient number of ADPCM decoders shall be
provided to guarantee that freeze-out due to unavailability of ADPCM decoders cannot occur (see
Note). The actual connection is implemented at the beginning of the DCME frame which occurs three
frames after the start of the DCME frame containing the applicable assignment message. This delay is
necessary in order to provide adequate time for processing the assignment message before the associ-
ated ADPCM BC samples arrive at the DCME receive unit.

    NoteûFor the point-to-point mode this condition is met if the number of ADPCM decoders
is equal to the number of ADPCM encoders. For the multi-destination mode this condition is met if
the number of ADPCM decoders provided equals the number of trunk channels receiving traffic.

    This section specifies those aspects of the DCME receive unit structure which are necessary
to accurately define the DCME transmit unit/receive unit interaction. An example of a DCME receive
unit structure which satisfies the interaction requirements specified in this section is given in
AnnexA.2.

7.1    Receive channel processing function

    The receive channel processing (RCP) function decodes the received assignment messages,
dynamically establishes BC-decoder-IT connectivity relationships and provides information to the
transparent circuit handler and the transmit channel processing functions.

7.1.1    DCME receiver unit initialization

    At initialization, the receive side channel connectivity map shall be set to a known state (BCs
and ITs disconnected) and the RCP parameters shall be loaded. These parameters include the infor-
mation necessary for the allocation of pre-assigned channels and bit banks. The pre-assigned channel
allocation (determined by the configuration data) shall be in accordance with the bearer structure
requirements (ºº5.2 and5.9). A map which identifies the remote IT numbers intended for the DCME
and associates them with the local IT numbers (making up the circuit), is included in information
loaded at initialization. The local IT numbers are used by the DCME in its transmitted assignment
message. The remote IT numbers are those associated with the individual channels received by the
local DCME receive unit from its corresponding DCME transmit units.

7.1.2    Input pre-processing

    Upon reception of an assignment message, a validity check shall be performed to ensure that
the message is consistent with the transmit side assignment rules and with the DCME configuration
data. A minimum list of conditions to be verified shall be as specified below:

a)    If the BC is in the overload range, or if the IT number is 250, the MSB of the BC identifica-
tion word in the assignment message must be0.

b)    If the synchronous data word indicates a 64 kbit/s transparent channel, the MSB of the BC
identification word must be0, and the BC number must be even.

c)    The BC number must not already be used for a pre-assigned channel.

d)    The IT number must be contained in the range which the corresponding DCME encoder
can address regardless of destination.

e)    The BC number must be in the normal range if the BC type is data or transparent, or if the
IT number is250.

f)    If the optional USM is used special checks are required for DCME frames 0, n, 2n, etc., of
the DCME multiframe.

For the optional R2 USM line signalling, messages will be delivered in DCME frames 0,
8, 16,etc. (i.e.every eighth frame of the DCME multiframe). The validity of the two IT
numbers conveyed should be checked against the permissible range.

    If any of the above conditions are not satisfied, or if DCME frame alignment is lost, no further pro-
cessing of the assignment message shall be performed. The receive IT number shall be assumed to
be0 for the purpose of providing the Pv and Pov pointer values for the overload channel derivation
process.

7.1.3    Connectivity map update

    If the assignment message validity check is successful, the received control channel message
shall be processed as follows:

a)    The IT-to-BC connection shall be logged in the channel connectivity map.

b)    If the IT number is 0, the BC shall be disconnected from the previously connected IT,
defined as ITP.

c)    If the IT number is 250, the BC shall be interpreted as a bit bank channel.

d)    If a BC of the transparent type is indicated by the assignment message, BC + 1 shall be des-
ignated as disconnected in the channel connectivity map.

e)    If the connection of a BC changes to a different IT, the previously connected IT, defined at
ITP, shall be disconnected. This is an implicit disconnection of ITP.

f)    If the connection of an IT changes to a different BC, the previously connected BC shall be
designated as disconnected in the channel connectivity map.

g)    If a BC of the transparent type changes to a different type, the other BC of the transparent
BC pair shall be designated as disconnected in the channel connectivity map. Its associ-
ated IT shall also be designated as disconnected in the channel connectivity map.

    If, as a result of the above actions, the conditions exist for the deletion of a bit bank (as per Table3/
G.763), the bit bank BC shall be disconnected.

    If the optional USM is used, the channel connectivity map shall not be updated. However, ITn shall
be used as a pointer in the overload channel derivation process.

    It should be noted that some connection/type changes are not strictly permissible under the assign-
ment rules specified for the DCME transmit unit structure (see º6). These transitions, although
abnormal, may occur at the DCME receive unit as the result of loss of assignment messages. Note
that abnormal transitions are different from erroneous assignment messages (rejected by the input
pre-processing task). The DCME receive unit shall recover from an abnormal assignment transition
within a maximum of one assignment channel refresh cycle.

7.1.4    ADPCM decoder connection control

    The following ADPCM decoder control rules shall apply only if the remote IT number is des-
tined for the DCME receive unit:

a)    When a new assignment of a previously disconnected IT is made, an ADPCM decoder
shall be connected to the corresponding local IT, thus completing the BC to ADPCM
decoder to IT path through the DCME receive unit.

b)    When a reassignment of a previously connected IT is made to a different BC, the ADPCM
decoder currently associated with the corresponding local IT shall be maintained.

c)    Whenever an IT connection changes to BC number 0 (explicit disconnection) or the IT is
implicitly disconnected, the associated ADPCM decoder shall be disconnected.

d)    The ADPCM decoder shall be reset when a new IT connection is established.

7.1.5    Bit bank handling and overload channel derivation

    The rules for bit bank handling and overload channel derivation shall be the same as those
defined for the TCP function. The only differences are that when an assignment message is erroneous
(or lost):

1)    the pointer variables Pv and Pov shall be set to 0;

2)    if there is not enough bit capacity available to service the corrupted assignment message
then the affected channels shall receive dummy bits set to0;

3)    the variable N4 (number of 4 bit overload channels) shall be set to 0 if its calculated value
is negative;

4)    the variable N3 (number of 3 bit overload channels) if used, shall be set to 0 if its calculated
value is negative.

7.1.6    Connectivity implementation delay

    The BC to ADPCM decoder to IT connection is implemented at the beginning of the DCME
frame which occurs three frames after the start of the DCME frame containing the applicable assign-
ment message. Refer to Figure14/G.763.

7.1.7    TCP and TCH interactions

    The following indications are sent to the TCP and the TCH in response to certain transitions
indicated by the assignment message.

    Rxdata(IT):        This indication shall be sent to the TCP function when an assignment message is received
which indicates a transition from a previous BC type to a data BC type. (IT is the
transmit ITnumber.)

    RxTranspreq(IT):    This indication shall be sent to the TCH when an assignment message is received
which indicates a transition from another BC type to a transparent BC type.

    RxTransprel(IT):    This indication shall be sent to the TCH when an assignment message is received
which indicates a transition from a transparent BC type to some other BC type.

8    On-demand 64 kbit/s circuit handling

8.1    Overview of establishment and disestablishment of 64 kbit/s unrestricted class connections
(transparent circuits)

    The DCME shall establish/disestablish 64 kbit/s unrestricted duplex connections under con-
trol of the seizing/releasing ISC as part of the call set-up/clearing process between exchanges. Dedi-
cated seizure/select and release messages and the associated acknowledgement messages are
exchanged between the DCME and the ISC as defined in RecommendationQ.50. The DCME-to-ISC
control interface is defined in º5.3.

    Subject to the capability of the ISC, this process is usable for performing the in-call modifica-
tions between the DCMEs during alternate speech/64kbit/s unrestricted type calls.

    Upon reception of a seizure/select message from the ISC for a trunk, the DCME shall per-
form the necessary internal checks, including the 64kbit/s unrestricted dynamic load control status,
for the accommodation of this call and an acknowledgement (positive or negative) message shall be
returned as soon as possible to the calling ISC. The calling end DCME shall initiate the establishment
of the unrestricted 64kbit/s forward connection to the called end DCME using a special identifier in
the assignment message. The called end DCME, upon receipt of this message, shall automatically ini-
tiate the establishment of the unrestricted 64kbit/s return connection. Failure to complete the estab-
lishment of a 64kbit/s circuit between DCMEs shall be reported to the ISC as soon as this has been
detected internally. This reporting shall be in the form of an out-of-service message.

    Upon receipt of a release message from the calling ISC the releasing end DCME shall initiate
the disestablishment of the unrestricted 64kbit/s forward connection, and the opposite end DCME
shall automatically initiate the disestablishment of the unrestricted 64kbit/s return connection. Upon
completion of this process, a positive release acknowledgement message shall be returned to the
releasing ISC. Failure to complete the disestablishment shall be reported to the releasing ISC using
the out-of-service message and the DCME shall put the trunk in a blocked condition.

    After manual or automatic removal of any failure condition, the DCME shall put the trunk in
an idle condition and send a back-in-service message to the ISC.

    A calling end DCME shall detect a release initiated by the opposite end (non-controlling) ISC
by the reception of a disconnect message in the control channel. This abnormal release shall be recog-
nized as a dual seizure situation being resolved between the ISCs. The detecting DCME shall first
complete the release normally and immediately attempt to re-establish the released 64kbit/s unre-
stricted duplex connection between the DCMEs.

8.2    Transparent circuit handler (TCH)

    The TCH function interacts with the switching centre interface (SCI), the DLC, the TCP and
the RCP functions. The TCH function is invoked for the execution of peer procedures in correspon-
dent DCMEs for 64kbit/s circuit handling.

    A facility by which the operator may enable or disable the interaction between the TCH and
DLC functions shall be provided (see Note).

    NoteùDisabling of the TCH/DLC interaction may degrade voice performance under high
load conditions.

    The functional partitioning of processing functions is intended to add clarity to the require-
ments of the TCH function and not to specify processing partitions within a DCME implementation.

    The end-to-end on-demand circuit establishment and on-demand circuit disestablishment
procedures have the following salient features:

a)    The generation of a positive acknowledge for a seizure/select request which is sent to the
ISC when the 64kbit/s circuit establishment process between DCMEs has been properly
initiated.

b)    Circuit handling protocols for dual seizures between DCMEs. These protocols are compat-
ible with the procedures for dual seizures in ISCs as defined in RecommendationQ.764
(signalling procedures of Signalling System No.7 ISUP).

c)    Automatic recovery of the circuit handling process following unsuccessful or delayed com-
pletion of circuit establishment.

d)    Automatic circuit blocking (for 64 kbit/s calls) after unsuccessful two-way disconnection.

    The block interaction diagram for the TCH function is shown in Figure15/G.763.

Figure 15/G.763 = 9 cm



    The TCH receives 64 kbit/s seizure/select messages and 64 kbit/s release messages from the local ISC
(through the SCI), receive transparent request and receive transparent release indications from the
RCP function and 64kbit/s dynamic load control indications from the local DLC function.

    The TCH send 64 kbit/s acknowledged and not acknowledged messages, out-of-service and back-in-
service messages to the local ISC (through the SCI) and sends transparent request and transparent
release indications to the TCP. Table4/G.763 gives nine different TCH states.



    Four timers in the TCH define time intervals within which circuit establishment, disestablish-
ment, and auto-recovery procedures are to be completed successfully.

T1:        Maximum time allowed for successful completion of 64 kbit/s circuit establishment, 1.0
s.

T2:        Maximum time allowed for successful completion of 64 kbit/s circuit disestablishment,
1.5 s.

T3:        Time assumed for completion of 64 kbit/s circuit disestablishment remotely initiated, 1.0
s.

T4:        Maximum time allowed for successful completion of 64 kbit/s circuit auto-recovery, 1.5
s.

8.2.1    External information elements

    The provision of the signalling system between the DCME and the local ISC, specified in
RecommendationQ.50, will ensure the availability of the following external information elements for
on-demand 64kbit/s circuit handling. Depending on the characteristics of the chosen DCME-ISC
control system, all of the required external information elements may not be used.

8.2.1.1    S64(TCn)

    Request for the establishment of a 64 kbit/s circuit on local TCn received from the ISC.

8.2.1.2    R64(TCn)

    Request for the disestablishment of a 64 kbit/s circuit on local TCn received from the ISC.

8.2.1.3    S64Ack(TCn)

    Acknowledgement sent to the ISC that the establishment of a 64kbit/s circuit for TCn has
been initiated.

8.2.1.4    S64NAck(TCn)

    Negative acknowledgement sent to the ISC that the request for establishment of a 64 kbit/s
circuit for TCn has been rejected.

8.2.1.5    R64Ack(TCn)

    Acknowledgement sent to the ISC that the disestablishment of a 64kbit/s circuit for TCn has
been completed.

8.2.1.6    Out-of-service (TCn)

    Indication sent to the ISC that TCn is out-of-service.

8.2.1.7    Back-in-service (TCn)

    Indication sent to the ISC that TCn is back-in-service.

8.2.2    DLC information elements

    The indications received from the DLC function are as follows:

8.2.2.1    DD64

    Indication received from the DLC function when 64 kbit/s capacity is available locally and at
the correspondent DCME. Refer to º9.4.

8.2.2.2    AD64

    Indication received from the DLC function when 64kbit/s capacity is not available locally or
at the correspondent DCME. Refer to º9.4.

8.2.3    Other information elements

    The indications sent to the TCP function and received from the RCP function are as follows:

8.2.3.1    Transpreq(ITn)

    Indication sent to the TCP to initiate the assignment of a 64kbit/s forward channel for ITn.

8.2.3.2    Transprel(ITn)

    Indication sent to the TCP to initiate the disconnection of 64kbit/s forward channel for ITn.

8.2.3.3    RxTranspreq(ITn)

    Indication received from the RCP to indicate that a 64kbit/s connection has been established.

8.2.3.4    RxTransprel(ITn)

    Indication received from the RCP to indicate that a 64kbit/s connection has been released.

8.3    On-demand circuit establishment

    All procedures described for the on-demand circuit establishment pertain to a single trunk
(circuit) denoted by TCn, and to the associated forward and return intermediate trunks ITn and ITnó,
respectively.

8.3.1    Normal circuit establishment

    The sequence chart for a normal 64 kbit/s circuit establishment cycle is shown in Figure16/
G.763.

Figure 16/G.763 = 11 cm



8.3.1.1    Actions required at the calling end SCI/TCH

    Upon reception of the external information element S64 for TCn from the ISC, the SCI shall
send S64NAck(TCn) to the ISC if the TCH is in the process of disestablishing TCn from a previous
call (see º8.4.1.4), or if the DLC ON condition (AD64 has been received) is in effect (provided that
the internal interaction with the DLC process is enabled), or if the TCH is in the connect-called-64
state. No further action shall be taken after sending S64NAck(TCn).

    If the internal DLC condition (if used) is OFF (DD64 has been received), and if the TCH is
not in the process of disestablishing ITn from a previous call, the SCI shall send S64Ack(TCn) to the
ISC and the TCH shall:

a)    send Transpreq(ITn) to the TCP;

b)    start timer T1. A subsequent reception of the RxTranspreq(ITn) indication shall signify the
completion of the circuit establishment and shall cause the TCH to reset timer T1 and to
enter the connect-calling-64 state for the circuit using ITn. The expiration of timer T1 is
described in º8.3.2.1.

8.3.1.2    Actions required at the calling end TCP/RCP

    The reception of the Transpreq(ITn) indication from the local TCH shall cause the TCP to
perform a transmit assignment (BCx,ITn) in accordance with º6 for the forward link of the circuit
being established.

    Reception of the new assignment message (BCx, ITnó) shall cause the RCP to establish the
receive connection for the return in accordance with º7 and to send the RxTranspreq(ITn) indication
to the TCH.

    Actions required on failure to receive the expected RxTranspreq(ITn) indication for the
return link are described in º8.3.2.2.

8.3.1.3    Actions required at the called end RCP/TCP

    Reception of a new assignment message (BCx, ITn) from the distant (calling) DCME shall
cause the RCP to establish the receive side connection in accordance with º7 and send the
RxTranspreq(ITn) indication to the TCH.

    Reception of the Transpreq(ITn) indication shall cause the TCP to perform a transmit assign-
ment (BCx, ITnó) in accordance with º6 for the return link of the circuit being established.

8.3.1.4    Actions required at the called end TCH

    Reception of the RxTranspreq(ITnó) indication shall cause the TCH to initiate the 64 kbit/s
transparent channel establishment in the return direction by sending a Transpreq(ITnó) indication to
the TCP and to enter the connect-called-64 state for the circuit using ITnäó.

8.3.2    Unsuccessful circuit establishment

    The sequence chart for an automatic recovery after an unsuccessful circuit establishment is
shown in Figure17/G.763.

Figure 17/G.763 = 11,5 cm



8.3.2.1    Actions required at the calling end SCI/TCH

    If the RxTranspreq(ITn) indication is not received before the expiration of timer T1, the fol-
lowing automatic recovery procedure shall be initiated.

    The TCH shall:

a)    send a Transprel(ITn) indication to the TCP;

b)    start timer T4. The subsequent reception of a RxTransprel(ITn) indication shall signify the
completion of the circuit disestablishment and shall cause the TCH to reset timerT4 and
to enter the appropriate state for the circuit using ITn. The expiration of timer T4 is
described in º8.3.2.3.

    The SCI shall:

a)    send an out-of-service (TCn) indication to the ISC;

b)    send a back-in-service (TCn) message to the ISC when the TCH has indicated the reception
of RxTransprel(ITn) from the local RCP.

8.3.2.2    Actions required at the calling end TCP/RCP

    Reception of the Transprel(ITn) indication shall cause the TCP to perform a disconnection
(BCx, IT0) in accordance with º6 for the forward link of the unsuccessfully (or delayed) established
circuit.

    If the expected new assignment message (BCx, ITnó) for the return direction is received
while the above circuit disconnection is in progress, the RCP in the calling DCME shall first establish
the receive side connection normally by executing the actions described in º8.3.1.2, º2, and then
complete the normal disconnection process by executing the actions described in º8.4.1.2, º2.

8.3.2.3    Unsuccessful automatic recovery

    If the RxTransprel(ITn) from the RCP is not received before the expiration of timer T4, the
SCI shall block circuit TCn and raise a blocking alarm for this circuit. The SCI shall be reset to the
appropriate state for the circuit using TCn only after the operator's attendance to the blocking alarm.
Upon reset of the SCI, a back-in-service (TCn) shall be sent to the ISC.

8.4    On-demand circuit disestablishment

    All procedures described for the on-demand circuit disestablishment pertain to a single trunk
(circuit) denoted by TCn, and to the associated forward and return intermediate trunks ITn and ITnó,
respectively.

8.4.1    Normal circuit disestablishment

    The sequence chart for a normal 64 kbit/s circuit disestablishment cycle is shown in
Figure18/G.763.

Figure 18/G.763 = 8 cm



8.4.1.1    Actions required at the releasing end SCI

    Upon reception of the external information element R64 for TCn at the releasing end SCI, the
TCH shall:

a)    send Transprel(ITn) to the TCP;

b)    start timer T2. A subsequent reception of RxTransprel(ITn) indicates completion of the cir-
cuit disestablishment and shall cause the TCH to reset timer T2 and enter the appropriate
state for the circuit using ITn. The expiration of timerT2 is described in º8.4.2.1,

and the SCI shall send an R64Ack(TCn) indication to the ISC when the TCH has indicated the recep-
tion of RxTransprel(ITn) from the local RCP.

8.4.1.2    Actions required at the releasing end TCP/RCP

    The reception of Transprel(ITn) from the local TCH shall cause the TCP to perform a discon-
nection (BCx,IT0) in accordance with º6 for the forward link of the circuit.

    Reception of the disconnection message (BCx, IT0) or an implied disconnection shall cause
the RCP to perform a receive disconnection for the return ITnó in accordance with º7 and to send the
RxTransprel(ITn) signal to the TCH.

8.4.1.3    Actions required at the released end RCP/TCP

    Reception of the disconnect message (BCx, IT0), or alternatively an implied disconnect from
the distant (releasing) DCME shall cause the RCP to disconnect the receive side connection in accor-
dance with º7 and send the internal signal RxTransprel(ITn') to the TCH.

    Reception of the Transprel(ITnó) signal shall cause the TCP to perform a disconnection
(BCx, IT0) in accordance with º6 for the return link of the circuit.

8.4.1.4    Actions required at the released end TCH/SCI

    Reception of RxTransprel(ITnó) from the RCP shall cause the TCH to initiate the release of
the 64kbit/s transparent channel in the return direction by sending Transprel(ITnó) to the TCP, and to
start a timer T3 (expiration of timer T3 assumes normal completion of the disconnection process ini-
tiated by the distant end).

    Prior to timer T3 expiration, any reception of S64 for the same TCn from the local ISC shall
be negatively acknowledged by forwarding S64NAck(TCn) to the ISC.

    If the RxTranspreq(ITnó) signal followed by a RxTransprel(ITnó) signal are received prior to
timer T3 expiration, a spurious disconnection condition shall be declared and the actions described in
º8.6.2 shall be taken.

    Upon expiration of T3, the TCH shall enter the appropriate state for circuit ITnó.

8.4.2    Unsuccessful circuit disestablishment

    The sequence chart for an unsuccessful 64 kbit/s circuit disestablishment cycle is shown in
Figure19/G.763.

Figure 19/G.763 = 10 cm



8.4.2.1    Actions required at the releasing end TCH

    If the RxTransprel(ITn) from the RCP is not received before the expiration of timer T2, the
TCH shall block circuit ITn and raise a blocking alarm for this circuit. The SCI shall send the out-of-
service (TCn) message to the ISC. The TCH shall be reset to the appropriate state for the circuit using
ITn only after the operator's attendance to the blocking alarm. Upon reset of the TCH, the SCI shall
send a back-in-service (TCn) message to the ISC.

8.5    Dual seizure handling

    All procedures described for the dual seizure handling pertain to a single trunk (circuit)
denoted by TCn, and to the associated forward and return intermediate trunks ITn and ITnó, respec-
tively.

8.5.1    Dual seizure condition

    Simultaneous reception of seizure requests S64 for TCn from both ISCs will cause the proce-
dures described in ºº8.3.1.1 and8.3.1.2 to be invoked from each end of the circuit. The condition
after execution of those procedures would be the connect-calling-64 state of the TCHs at both ends
for the same circuit. Refer to Figure20/G.763.

Figure 20/G.763 = 8,5 cm



8.5.2    Dual seizure resolution

    For explanation in this section, the non-controlling ISC is assumed to be at the ITnó side.
Refer to Figure21/G.763.

8.5.2.1    Actions required at the TCH (non-controlling switching centre end)

    Upon reception of the external information element R64 (TCn) from the non-controlling ISC,
the TCH shall initiate the normal circuit disestablishment procedures described in ºº8.4.1.1, 8.4.1.2
and8.4.1.3.

Figure 21/G.763 = 11 cm



8.5.2.2    Actions required at the TCH (controlling switching centre end)

    Upon reception of RxTransprel(ITn) the TCH shall respond by sending Transprel(ITn) to the
TCP. The TCP shall thereafter immediately initiate the automatic re-establishment of the circuit by
sending Transpreq(ITn) to the TCP and to start timer T1. All subsequent procedures described in
ºº8.3.1.2, 8.3.1.3 and8.3.1.4 shall proceed normally (including procedures for auto-recovery
described in º8.3.2 in case of unsuccessful circuit re-establishment).

8.6    Spurious disconnect handling

    All procedures described for the spurious disconnect handling pertain to a single trunk (cir-
cuit) denoted by TCn, and to the associated forward and return intermediate trunks ITn and ITnó,
respectively.

8.6.1    Spurious disconnect conditions

    Condition I û A spurious disconnect message or a spurious implied disconnect detected by
the called end RCP while the called end TCH is in the connect-called-64 state will cause the proce-
dures described in ºº8.4.1.3 and8.4.1.4 to be invoked. A subsequent assignment message refresh
will result in the generation of a RxTranspreq(ITnó) signal to the called end TCH after timer T3 has
started. Refer to Figure22/G.763.

    Condition II û A spurious disconnect message or a spurious implied disconnect detected by
the calling end RCP while the calling end TCH is in the connect-calling-64 state will cause the proce-
dures described in º8.5.2.2 to be invoked. The resulting disconnect message and the subsequent re-
-establishing assignment message will be recognized as spurious disconnect conditionI. Refer to
Figure23/G.763.

Figure 22/G.763 = 11, 5 cm



8.6.2    Spurious disconnect recovery

8.6.2.1    Actions required at the called-end TCH

    After timer T3 has started, upon reception of a RxTranspreq(ITnó) signal, followed by a
RxTransprel(ITnó) signal, the TCH shall enter the spurious-recovery state for the circuit using ITnó.
A subsequent reception of the internal message RxTranspreq(ITnó) shall cause the TCH to reset timer
T3, to initiate the re-establishment of the 64kbit/s transparent channel in the return direction by send-
ing Transpreq(ITnó) to the TCP, and to re-enter the connect-called-64 state for the circuit using ITnó.

    If timer T3 expires before the reception of the RxTranspreq(ITnó) signal, the TCH shall enter
the appropriate state for circuit ITnó.

8.6.2.2    Actions required at the calling end TCH

    For condition I, the actions described in º8.5.2.2 shall be taken once.

    For condition II, the actions described in º8.5.2.2 shall be taken twice.

Figure 23/G.763 = 15 cm



9    Dynamic load control

9.1    Overview

    To reduce the probability of excessive freeze-out percentages, the DCME shall have a facility
for DLC. This facility signals towards the local and distant-end ISCs that new calls should not be
established. The DCME shall communicate with the ISC in accordance with RecommendationQ.50.
A DLC facility shall be provided for voice/voice-band data and on-demand 64kbit/s traffic sepa-
rately. DLC shall not be applied to pre-assigned traffic.

    The DCME shall provide a DLC signal which may be sent to the local and distant ISCs to
limit the traffic load presented to the DCME during overload conditions. Overload conditions should
be indicated by average number of bits per sample calculated for each pool. When the value falls
below a particular previously set threshold level, the DLC message should be generated at the
DCME. DLC messages shall be sent back to the local ISC(s), and the distant DCME shall be
informed through the control channel. The distant DCME shall interpret and appropriately convey the
DLC information to its associated ISC(s).

9.1.1    DLC activation/deactivation criteria

    Voice/voice-band data DLC activation messages shall be generated when the number of bits
per sample, averaged over the voice channels of the pool, drops below a presettable threshold.

    The 64kbit/s unrestricted (transparent) DLC activation messages shall be generated when:

a)    the measured number of assigned 64kbit/s unrestricted channels exceeds a presettable
threshold; or

b)    the voice/voice-band data DLC has been activated; or

c)    the voice/voice-band data DLC is expected to be activated due to an increase of one addi-
tional channel in the 64kbit/s unrestricted traffic loading.

    Activation of DLC shall occur immediately upon transgressing the threshold criteria. Deactivation of
DLC shall occur when the average number of bits per sample exceeds a presettable threshold or the
number of 64kbit/s unrestricted channels falls below a presettable threshold. If the 64kbit/s DLC is
not active, 64kbit/s unrestricted channel requests shall not be denied. Deactivation of DLC shall not
occur earlier than a programmable interval which has a minimum of 10s in order to prevent an oscil-
lating condition.

9.1.2    Message processing and routing

    Internal DLC indications are sent on a destination selective basis to the local SCI and the
TCH for further processing and subsequent forwarding of the associated bearer service related exter-
nal information elements to the ISC(s) according to ºº9.3.2 and9.4.2. The list of DLC related exter-
nal and internal messages used by the SCI is given in º5.3.2. The external message exchange
between the SCI and the ISC is as defined in RecommendationQ.50.

    Assuming that the ISC is responding to messages originating from the DCME SCI, it is rec-
ommended that once a DLC signal has been active (i.e.new calls blocked) and then returns to an
inactive state (new calls may be established), the affected circuits be unblocked in a gradual manner
for the relevant bearer service type. Correspondent DCMEs shall exchange their respective load con-
ditions by means of the DLC support messages within the control channel asynchronous data word.
Refer to º11.3.3.2.

9.2    Load condition calculation (see Note)

    The local loading condition shall be determined using the average number of encoding bits
per sample as a measure. An example of a DLC double averaging technique is given in AnnexB.1.

    NoteûThe load calculation may be used for provision of special tandeming facilities (under
study).

9.3    Voice/voice-band data DLC

9.3.1    DCME function

    Two load conditions are defined:

a)    High Load (HL)ûIn this condition, the measured average number of encoding bits is less
than the high load threshold (e.g.3.6bits per sample).

b)    Low Load (LL)ûIn this condition, the measured average number of encoding bits is
greater than the low load threshold (e.g.3.9bits per sample).

    The HL and LL thresholds shall be operator programmable options settable between3 and
4in 0.05bits per sample steps.

    When the average number of encoding bits is between the two thresholds, the last load condi-
tion shall be maintained.

    A local HL condition shall be signalled to the corresponding DCME(s) by setting the voice/
voice-band data DLC support message (bitp) to state 1. Refer to º11.3.

    A local LL condition shall be signalled to the corresponding DCME(s) by setting the voice/
voice-band data DLC support message (bitp) to state0. Refer to º11.3.

    The DLC ON condition for voice/voice-band data traffic shall be declared when:

a)    the HL condition is detected locally; or

b)    the bit p received from a corresponding DCME is in state 1 (DLC is applicable only to
those circuits which are destined to this corresponding DCME).

    The DLC OFF condition for voice/voice-band data traffic shall be declared for each destination when:

a)    the LL condition is detected locally; and

b)    the bitp received from the relevant destination is in state 0.

    The DLC ON condition shall be declared during a system reconfiguration.

    The ADVD indication (see º5.3.2) shall be sent to the local SCI at the transition from DLC
OFF to DLC ON. The DDVD indication shall be sent to the local SCI at the transition from DLC ON
to DLC OFF.

9.3.2    SCI function

    The SCI shall send the information elements SNA and VDNA to the ISCs when the TCH
receives an ADVDindication from the DLC function.

    When the TCH receives a DDVD indication from the DLC function, the SCI shall send the
information elements SA and VDA to the ISC(s), unless an ADVD indication recurs within
Taseconds after the last detected ADVD indication.

    The Ta timer shall be operator selectable with a minimum of tenseconds.

    Depending on the characteristics of the chosen DCME - ISC control system, the SNA,
VDNA, SA and VDA information elements may not all be used.

9.4    On-demand 64 kbit/s DLC

9.4.1    DCME function

    The availability of capacity for on-demand 64kbit/s traffic is based on the predicted average
number of encoding bits for voice traffic if a pair of 4bit bearer time slots currently used for voice
traffic were to be used to accommodate one additional 64kbit/s channel.

    Two capacity availability conditions are defined:

a)    Capacity Available (UCA)ûIn this condition, the predicted average number of encoding
bits is greater than the LL threshold defined in º9.3.1.

b)    Capacity Not Available (UCNA)ûIn this condition, the predicted average number of
encoding bits is less than the HL threshold defined in º9.3.1.

    When the predicted average number of encoding bits is between the two thresholds, the last
load condition shall be maintained.

    A local UCNA condition shall be signalled to the corresponding DCME(s) by setting the on-
demand 64kbit/s DLC support message (bitq) to state1. Refer to º11.3.

    A local UCA condition shall be signalled to the corresponding DCME(s) by setting the on-
demand 64kbit/s DLC support message (bitq) to state0. Refer to º11.3.

    The DLC ON condition for on-demand 64kbit/s traffic shall be declared when:

a)    the UCNA condition is detected locally; or

b)    the bitq received from a corresponding DCME is in state1 (DLCis applicable to those cir-
cuits which are destined to this corresponding DCME).

    The DLC OFF condition for on-demand 64kbit/s traffic shall be declared for each destination when:

a)    the UCA condition is detected locally; and

b)    the bitq received from the relevant destination is in state 0.

    The DLC ON condition shall be declared during a system reconfiguration.

    The AD64 message shall be sent to the local SCI and to the TCH at the transition from DLC
OFF to DLCON.

    The DD64 message shall be sent to the local SCI and to the TCH at the transition from DLC
ON to DLCOFF. A facility to enable or disable the DLC/TCH interaction shall be provided. Refer to
º8.2.

9.4.2    SCI function

    The SCI shall send the information element UCNA to the ISC(s) when the TCH receives an
AD64indication.

    When the TCH receives a DD64 indication, the SCI shall send the information element UCA
to the ISC(s), unless the TCH receives an AD64 indication within Tb seconds after the last detected
AD64 indication.

    The Tb timer shall be operator selectable with a minimum of tenseconds.

    Depending on the characteristics of the chosen ISC control system, the UCNA and UCA
information elements may not be used.

10    Test procedures

    A means of verifying end-to-end continuity and correct assignment of channels must be pro-
vided. If an automatic procedure is implemented then it should conform to the following:

    NoteûThe channel check procedure is applied independently to each pool.

10.1    Channel check procedure

10.1.1    Test procedure

    A repetitive 20second Test time frame (TTF) shall be established. At the start of each TTF,
unless the procedure is inhibited, a test vector bit pattern sequence shall be originated on IT239 for
pool1 and IT240 for pool2. This test vector sequence shall compete for assignment to a bearer chan-
nel in accordance with º6. The ADPCM encoder for (BCn, IT239/240) shall be selected normally in
accordance with º6, except that any ADPCM encoders selected for IT239/240 shall always operate
in A-law mode. The characteristics of the test vector sequence shall be in accordance with º10.1.4.
The test vector sequence shall remain ON for approximately one second. A DCME transmit unit shall
generate one channel check test vector which shall be processed by all corresponding DCME receive
units. For this reason, IT239/240 shall be assumed to be destination directed to all destinations corre-
sponding with the DCME transmit unit.

    To inform the corresponding DCME receiver units that a channel check has commenced, a
code 1111 is transmitted in the synchronous data word in the same DCME frame as the first associ-
ated channel check assignment message (BCn, IT239/240) for each TTF. The synchronous data word
code1111 shall be transmitted once for each channel check sequence.

    If the channel check procedure has been manually inhibited at the DCME transmit unit, bit1
in DCME frame62 of the Asynchronous data word shall be set to 1, otherwise the bit shall be set to0.
The manual inhibit shall become effective at the next TTF boundary.

    All corresponding DCME receive units shall assign IT239/240 to a special test port. A spe-
cial test port is assigned for each received bearer. The special test ports are identified by the local IT
numbers241 through244 receiving bearer numbers1 through4, respectively. A test ADPCM
decoder associated with (BCn, IT239/240) shall be selected in accordance with º7. However, any
ADPCM decoder selected for IT239/240 shall operate in A--law mode. Continuous correlation shall
be performed to identify the presence of the test vector. When the test vector is identified, a test pat-
tern receiver shall determine the accuracy of the match between the received test vector and a locally
stored version of this pattern in accordance with º10.1.4. For each bearer, the result from the test pat-
tern receiver shall be disregarded if the continuous BER measurement declares a high BER condition.
Refer to º15.10.1.

10.1.2    Reporting test results (remote DCME)

    The remote DCME shall generate a local alarm when the test vector pattern is not correctly
received in accordance with º10.1.4, or if the code1111 is received from synchronous data word and
a test vector has not been synchronized on the corresponding test port.

    The remote DCME shall construct and maintain a table of test results of each BC. Separate
test result tables shall be maintained for each incoming bearer and/or pool. For each BC, an entry in
the table shall contain a0 if the test result is pass, otherwise the test result table shall contain a1. If
the result of the test pattern receiver has been disregarded, a1 shall be entered in the test result table
for the high BER yes/no condition and a1 shall be assumed for the pass/fail entry. The test result
table shall also include the identity of the ADPCM decoder currently assigned to the test port.

    It is recommended that the test result table also contain a real-time clock and date entry show-
ing the time and date that the last test result was obtained for each BC. It is further recommended that
the result tables be made accessible by the local operations and maintenance function or an equivalent
facility.

    For each bearer, the remote DCME shall send the result of the last channel check to the corre-
sponding local DCME via the Asynchronous Data Word using the format shown in Table5/G.763. A
test result consisting of a BC number, pass/fail condition, high BER yes/no condition and ADPCM
decoder number shall be sent once per DCME multiframe in DCME frames56-61. The test results
are sent in ascending numerical order of the incoming bearer number.

    If no test result exists, if the automatic procedure has not been implemented, or if more than
60seconds have elapsed since the last channel check test for that bearer, the BC number and the
ADPCM decoder number contained in DCME frames57, 58, 59 and60, respectively, shall be set to
all1s (ineffective message). The pass/fail and high BER bits shall be set to1. The message contents
shall remain latched to the last result for that bearer until a new result is available.



10.1.3    Reporting test results (local DCME)

    The local DCME shall build a result table for each corresponding DCME by accumulating
the incoming channel check result messages. The local DCME shall identify the required result mes-
sages by examining the bearer identification number contained in the first message (DCME frame56)
of each table. The traffic plan will contain the bearer identification number(s) pertaining to each
DCME.

    The local DCME shall generate a local alarm when an incoming bearer channel currently
subject to the channel check procedure is reporting an abnormal channel check result condition.

10.1.4    Test vector sequence characteristics

    The test vector sequence shall consist of the following three contiguous segments:

a)    100ms of 2400 Hz sinusoidal tone at -10dBm0;

b)    the A-law PCM initializing sequence in accordance with º10.1.5;

c)    768ms of 1254 Hz sinusoidal tone in accordance with the test vector sequence described in
º10.1.5.

    The test pattern receiver shall continuously search for a 1254 Hz sinusoidal tone pattern at an
equivalent level of 0dBm0 ▒1dB. The test pattern receiver shall be designed to synchronize to the
1254Hz sinusoidal tone pattern within 100ms at a bearer error rate of1 in 10-3 while the bearer is
operating in 3bit mode (note). Following synchronization, the test pattern receiver shall declare test
pass if the sum of the measured errors does not exceed 2000for each of the LSB and LSB+1bits,
and the sum of the errors does not exceed1000 for each of the MSB through MSB-5bits in a 600ms
measurement period measured at the PCM output stream. The determination test pass or test fail shall
be made at the end of a 600ms measurement window. The start of the measurement window shall be
located 650ms from the time of occurrence of the assignment message containing the synchronous
data code word(1111). The measurement window test time frame and 1254Hz test tone sequence are
shown in Figure24/G.763.

    NoteûOperation in 2bit mode requires further study.

Figure 24/G.763 = 8,5 cm



10.1.5    Channel check test vectors

    The complete test vector sequence comprises a 2400 Hz sinusoidal signal followed by an ini-
tializing segment followed by a 1254Hz sinusoidal signal. All segments are contiguous. The first
sequence comprises 834samples (approximately 100ms) of a 2400Hz sinusoidal sequence encoded
in accordance with RecommendationG.711 using A-law encoding. An output sequence is not pro-
vided for this input sequence. A reset is assumed prior to the start of the second sequence. The second
sequence consists of 3496samples (approximately 437ms) of A-law initializing sequence. No output
sequence is provided for this input sequence.

    The third input test sequence represents a 1254 Hz sinusoidal tone encoded in PCM in accor-
dance with RecommendationG.711 using A-law encoding. The output sequence is the corresponding
PCM A-law output obtained when the input test sequence is passed through an ADPCM encoder and
ADPCM decoder operated back-to-back.

    The output sequence assumes that the decoder ADPCM algorithm has been initialized imme-
diately prior to the reception of the test sequence.

    The test sequence format is based on 768ms of coded signal divided into a series of blocks.

    To maintain the accuracy with which the sample sequences will be incorporated in manufac-
turers' equipment, flexible disks containing these sample sequences may be obtained from the ITU.

10.2    Internal tests

    It is recommended that an internal test sequence performing a TC-BC-TC loopback test be
provided. These tests should, as a minimum, evaluate the activate level of the activity detectors
(DCME transmit unit) and the PCM-to-PCMbit integrity (for DCME transmit unit and receive unit).
The test sequence should be designed to sequentially evaluate all combinations of channels (TC, IT
and BC) and ADPCM codecs.

11    Control channel (CC)

    The CC shall be a 32kbit/s channel, and shall include provisions for accommodating the fol-
lowing categories of inter DCME terminal messages:

û    trunk-to-bearer assignment;

û    idle noise level;

û    dynamic load control;

û    alarm information;

û    self diagnostic information;

û    signal classification.

    Each pool of channels within the bearer frame shall contain a CC. The CC shall occupy the
lowest numbered 4bit BC in the pool. The first bit is a syncbit and the remaining 3bits carry a part
of the CC message.

    Control channel messages are transmitted at a rate of 3bits in each 125ms bearer frame. A
complete 48bit encoded (CC) message shall be transmitted in one DCME frame of 2ms. Prior to
encoding, the CC message shall consist of an 8bit BC identification word, an 8bit IT identification
word and 8bits for other DCME to DCME messages (Data Word). The CC message shall be pro-
tected by a (24,12) rate 1/2 Golay code. Figure25/G.763 illustrates the CC transmission scheme. In
the figures describing the CC, the left-hand bits are transmitted first.

Figure 25/G.763 = 8,5 cm



11.1    CC error protection

    A (24, 12) rate 1/2 code shall be applied to the CC for error protection. The (24, 12) code is
obtained from a (23,12) Golay code with the addition of a dummy bit and is capable of correcting 1,
2 or 3bits in error in a block of 24bits. The code generator polynomial is:

    The 24 information bits comprising 8bits for the BC number, 8bits for the IT number and
8bits for other data are transmitted in two blocks of 12information bits each. For each information
block there is a check block consisting of 11bits for the Golay code and one dummy bit as shown in
Figure26/G.763. The check bits are obtained by computing the remainder of the polynomial division
shown below:

where,

FIGURE 26/G.763 = 10 cm



11.2    CC synchronization

    A 16bit unique word shall be provided for each individual clique, to identify the beginning
of the 2ms DCME frame over which the encoded CC message of the pool is transmitted. Refer to
Figure25/G.763. The unique word shall be transmitted at the rate of one bit per bearer frame via the
sync bit. The sync bit shall occupy the most significant bit position of the CC4bit time slot.

    The 16bit unique word shall also provide a means of identifying the beginning of a 128ms
DCME multiframe (64DCME frames) for use by the asynchronous data word. Refer to º11.3.3.2.

11.2.1    Unique word pattern

    The sync bit pattern transmitted in a DCME frame shall constitute the following unique
words:

    DCME frame0 to 63001010011011110

    DCME frame 1 to 631110101100100001

    The order of transmission of the pattern shall be from the extreme left-hand bit first to the
extreme right-hand bit last. The first bit of the pattern shall be transmitted in the first nibble of the
16nibbles constituting a complete CCmessage.

11.2.2    Unique word detection

    The unique word detection shall be based on the detection of a correlation match between the
accumulated contents of the first bit of the CCnibble and a locally stored unique word pattern. The
resulting correlation matches shall be used to attain, maintain and regain the synchronization of the
CCmessage.

    In the steady state, a detection threshold of three shall be used to maintain synchronization,
and a 3bit window centred 16bits after the previous detection of the correlation match shall be used
to locate the start of the DCME frame for the proper decoding of the CC message. If the correlation
match is not achieved, the CC message bits shall be discarded and a search procedure shall be initi-
ated over a 16bit window.

11.3    CC message structure

11.3.1    BC identification word

    The MSB of the 8bit BC identification word shall be used to indicate the BCtype. For data,
the MSB shall be1. For all other BC types (bitbank, transparent, voice), the MSB shall be0.

    The sevenLSBs in binary code shall identify the BC number in accordance with º5.9. The
normal BC numbering range shall be1 through61. The overload BC numbering range shall either
be64 through83 or if the optional 2bit encoding mode is available and enabled 64to124.

    For 64kbit/s transparent channels, the BC number shall identify the first 4bit BC of a pair of
adjacent 4bit BCs used to create an 8bit BC and shall be even numbered in the range2 through60. A
channel type identifier code in the synchronous DCME to DCME Data Word shall be used, as defined
in º11.3.3.1 to indicate a 64kbit/s transparent channel.

    BC number 0 in binary code shall be used for CC messages transmitted during system start-
up or during a DCME transmit unit map change.

    BCnumber 255 in binary code shall be used to indicate an ineffective CCmessage if all traf-
fic is preassigned.

11.3.2    IT identification word

    The 8bits of the IT identification word shall be used to identify the ITs. ITs numbered
1to216 in binary code shall be available for traffic. When less than 216ITs are used, the numbering
will not necessarily be numerically consecutive.

    IT numbers 232, 233, 234 and 235 in binary code shall be used for DCME to DCME order-
wires (up to fourcorrespondents), see º15.9.

    IT numbers 239/240 in binary code shall be used for the automatic end-to-end channel check
procedure, seeº10.

    IT number 0 in binary code shall be used to indicate an explicit disconnection or shall be
transmitted in the CC during system start-up and DCME transmit unit map changes.

    IT number 250 in binary code shall be used when the associated BC is to be utilized for the
bit bank as described in ºº6 and7.

    IT number 255 in binary code shall be used to indicate an ineffective CCmessage if all traffic
is preassigned.

11.3.3    Data word

    The 8bit data word in the CC message forms two independent data channels. The first data
channel consists of the fourMSBs of the 8bit data word, and is transmitted with each assignment
message synchronously relative to the BCand IT identification.

    The second data channel consists of the remaining 4 bits of the 8bit data word transmitted in
a multi-frame structure asynchronously relative to the BC and IT identifications.

11.3.3.1    Synchronous data word

    The 4bit synchronous data word is used:

a)    to transmit background noise level information to the DCME receive unit;

b)    to indicate that the BC is the first 4bit nibble of a 64 kbit/s transparent channel;

c)    to indicate that the BC is assigned for the channel check procedure;

d)    to indicate an ineffective message;

e)    to carry user signalling bits when the optional USM is used.

    Background Gaussian noise, as determined at the transmit activity detector, will vary
between -68dBm0 and-42dBm0 (see Note). For channels subject to DSI, the background noise level
shall be encoded in accordance with Table6/G.763. The noise level code shall be transmitted with
each new assignment and refreshment message.

    NoteûFor A-law encoding the minimum noise level is -65dBm0.

    For each CC message, the DCME receive unit shall decode the 4bit data word and update the
noise level memory associated with the decoded IT according to Table6/G.763. At the DCME
receive unit, a pseudo-random 8bit PCM sequence simulating Gaussian noise shall be applied to the
disconnected IT. The simulated noise level shall match the last stored value in the noise level memory
before the disconnection.

    For channels carrying 64kbit/s transparent calls, the 4bit data word shall be 1001 and trans-
mitted with each new assignment, refreshment and disconnection message.

    If the BC in the assignment message is being subjected to the automatic channel check proce-
dure according to º10, the 4bit data word shall be1111.

11.3.3.2    Asynchronous data word

    The 4bit asynchronous data word will convey the following types of DCME-to-DCME
information:

a)    end-to-end circuit supervision and alarm indications on a per channel basis;

b)    bearer related backward alarm indication to the remote DCME;

c)    DLC support messages;

d)    BC related messages pertaining to channel check procedures.

    The data word multiframe shall consist of 64DCME frames numbered from 0to63.
FrameNo.0 is the DCME frame in which the CC unique word is inverted. The CC unique word for
the remaining 63frames shall be transmitted normally.

    Bit allocations in the data word multiframe for the various applications shall be as shown in
Table5/G.763.

11.3.4    CC structure when USM option is used

    If the optional USM is used, the BC identification word and the CCsynchronous data word
can be formatted according to the users' requirements in the DCME frames0, n, 2n,etc. (i.e.every
nth DCME frame) of the DCME multiframe.

    For the R2 USM every eighth frame of the DCME multiframe shall be used to transmit a sig-
nalling message as follows. The bits 1to8 of the signalling message shall identify ITn1. The bits
9to16 of the signalling message shall identify ITn2. Bits 17and18 shall encode the aand bbits of
ITn1. Bits19and20 shall encode the aand bbits of ITn2. The aand bbit signalling information will
be either change of signalling states, or the refreshment of existing states. Figure27/G.763 illustrates
the format for this type of message.



FIGURE 27/G.763 = 9 cm



12    Activity detection and data/speech discrimination

    This section describes the functional requirements of the transmit activity detector, data/
speech discriminator, signalling detector and receive activity detector.

    Compliance with all paragraphs of this section is mandatory with the exception of the trans-
mit activity detector threshold and operate time specification. Compliance with the threshold and
operate time specification is not required to achieve interworking between various DCME manufac-
turers. The performance of the DCME transmit unit activity detector will be assessed by conducting
MOS subjective tests on the entire DCME system. DCME testing methodologies have been specified
by CCITT Study GroupXII in RecommendationP.84.

12.1    Transmit activity detector

    For each IT, the transmit activity detector characteristics are based upon the assumption that
the amplitude frequency response of the transmission channel (up to the input of the activity detector)
is ▒0.5dB with respect to 1000Hz over the frequency band from 300 to 3400Hz. The Gaussian noise
level can typically vary over a range from -68 to -42dBm0.

    NoteûFor A-law encoding, the minimum noise level is -65dBm0.

    Functionally, the transmit activity detectors shall determine whether or not there is activity on
each transmit IT and provide an active/inactive (act/Inact) indication. Upon system start-up or map
change, the transmit activity detectors shall be reset to provide an Inact indication.

    Functionally, the transmit activity detectors shall determine the transmit idle channel noise
level on each non-pre-assigned IT in the DCME transmit unit. The idle channel noise level for each
DCME transmit unit IT is encoded and transmitted to the DCME receive unit in the 4bit synchronous
data word. The idle channel noise is regenerated in the DCME receive unit in accordance with
º11.3.3.1 and is applied to the corresponding DCME receive unit ITs when they are disconnected
from their assigned BCs.

12.1.1    Threshold and operate time

    The transmit activity detector threshold shall automatically adjust relative to the average
power of Gaussian noise band limited between 300to 3400Hz.

    The threshold and operate time of the transmit activity detector may be implementation spe-
cific. However, for guidance threshold and operate time, characteristics for the transmit activity
detector are given in AnnexB.2.

12.1.2    Hangover control

    The permissible hangover time as a function of stimulus signal duration shall be within the
mask shown in Figure28/G.763 for CCITT Signalling System No.5 and within the mask shown in
Figure29/G.763 for speech and CCITT Signalling Systems Nos.6, 7 andR2D.

FIGURE 28 y 29/G.763 = 10 cm



    It shall be possible to select the required type of hangover time mask. For voice-band data the hang-
over time should be extended so that it is sufficiently long to bridge facsimile page changes. This time
may be as long as 14s.

12.1.3    Interaction of transmit activity detector with echo control devices

    The threshold of the transmit activity detector shall not adapt to Gaussian noise level varia-
tions which are due to the actions of echo suppressors or echo cancellers. This might be accom-
plished, for example, by providing the transmit activity detector with a threshold inhibit signal from a
receive activity detector when activity is present in the receive channel (see AnnexB.5. Special
DCME networking considerations).

12.2    Data/speech discriminator

    The data/speech (D/S) Discriminator shall determine whether the activity on each IT in the
DCME transmit unit is speech or data and provide a speech/data indication to the TCP function. An
example of a data/speech Discriminator which satisfies the requirements specified in this section is
given in AnnexB.3.

    The following requirements shall be met with the modem types and bit rates given in Table7/
G.763.

12.2.1    Output conditions

    The D/S Discriminator shall analyse the activity on each transmit IT and provide the follow-
ing output conditions.

    The D/S Discriminator shall provide a continuous output condition indicating the presence of
either speech or data on the IT. The current output condition shall be maintained upon termination of
activity on the IT or until the output condition of a subsequent activity is determined. Upon system
start-up or map change, the D/S discriminator shall be reset to voice.

12.2.2    Accuracy

    The missed detection probability of data as speech or speech as data shall be less than 0.5 per
cent.

12.2.3    Response time

    The D/S Discriminator shall update its output condition within 200ms after any of the fol-
lowing changes in the IT signal characteristics:

û    inactive-to-speech;

û    inactive-to-data;

û    speech-to-data;

û    data-to-speech.

12.2.4    2100 Hz tone detector

    The D/S Discriminator shall detect the presence of the V.25 echo control disabling tone by
analysing signals on the transmit ITs. The function may be implemented separately but is here defined
as part of the D/S discriminator. Requirements for a 2100Hz tone detector are given in AnnexB.3.



12.3    Signalling detector

    Functionally, the signalling detector shall detect the presence of CCITT Signalling System
No.5 line signalling (2400Hz) on each transmit IT, provide a detection indication (signal detect/No
detect) to the TCP function and enable the signalling hangover time mask (Figure28/G.763) for the
duration of the signalling interval. Upon system start-up or map change, the Signalling Detector indi-
cation shall be reset to no Detect. Requirements for a 2400Hz tone detector are given in AnnexB.4.

    R2D inter-register signalling does not need an extended hangover and shall be classified as
voice.

12.3.1    Accuracy

    The probability of speech, voice-band data or noise being detected as CCITT Signalling Sys-
tem No.5 signalling or the probability of signalling being detected as speech, voice-band data or
noise shall be less than 0.5per cent.

12.4    Receive activity detector

    A receive activity detector may be used to recognize periods of activity on each received IT
and provide an inhibit signal to prevent interaction of the transmit activity detector with echo control
devices. Refer to º12.1.3.

13    DCME synchronization and echo control

13.1    DCME synchronization

    Timing synchronization of DCME can be achieved in many ways and care should therefore
be taken in any implementation to ensure that the configuration adopted is correct.

13.1.1    Reference clock

    The DCME reference clock shall be derived from a source which meets the requirement of
RecommendationG.811. For networks that entail one international destination, loop timing can be
used as an alternative at one end of the link. The need for an internal reference clock for use under
failure conditions is for further study.

13.1.2    Plesiochronous slips

    The slip rate shall not exceed the requirement of RecommendationG.822. Controlled slips at
2048kbit/s, on the trunk side shall be 2frames, controlled slips at 1544kbit/s on the trunk side and
for 2048kbit/s and 1544kbit/s on the bearer side require further study.

13.1.3    Buffer sizes and locations

    Table8/G.763 indicates suitable buffer sizes and locations for the 2048kbit/s hierarchy for
the various synchronization options which are detailed in AnnexB.6. A table for the 1544kbit/s hier-
archy is under study.



13.1.4    Terminal synchronization

    The DCME terminal shall be capable of deriving its timing from any of the incoming digital
links or from an external clock. When the synchronization is derived from the trunk receive side it is
recommended that a fallback trunk receive synchronization source be provided. This is for the event
of the primary synchronization link entering an alarm condition indicating a received line signal fail-
ure, loss of frame alignment, AIS or receive BER │10-3. Switching between primary and fallback
sources shall be automatic.

    NoteûSynchronization arrangements for special operation of DCME in tandem are under
study.

13.2    Echo control

    Echo control is not considered to be part of the DCME Recommendation. A network echo
control device integrated or external to the DCME and meeting or exceeding the requirements of
RecommendationsG.165,G.164, or RecommendationG.161 shall be present on all TCs carrying
speech serviced by a DCME.

    A lack of echo control on the circuits serviced by the DCME will degrade speech perfor-
mance due to the increased speech activity factor resulting from the echo signal.

    Transmit activity detector/echo control device interactions are controlled by freezing the
activity detector threshold in the presence of speech on the corresponding receive channel.

14    ADPCM encoders and decoders

    ADPCM encoders and decoders shall be capable of operation within the DCME at the fol-
lowing bearer channel transmission rates:

û    64kbit/s: 8 bit/sample transparent;

û    40kbit/s: 5 bit/sample ADPCM;

û    32kbit/s: 4 bit/sample ADPCM;

û    24kbit/s: 3 bit/sample ADPCM;

û    16kbit/s: 2 bit/sample ADPCM (optional).

    For 64kbit/s bearer channels (8-bit mode), the ADPCM encoders and decoders shall be
bypassed.

    For 40kbit/s bearer channels (5-bit mode), 32kbit/s bearer channels (4-bit mode), 24kbit/s
bearer channels (3-bit mode) and 16kbit/s bearer channels (2-bit mode), the ADPCM encoders and
decoders shall be in accordance with RecommendationG.726 and shall operate in accordance with
ºº6.1.6 and7.1.4.

    Digital sequences (test vectors) for use in the verification of correct implementation of the
ADPCM algorithms are available on flexible disks. Copies of the flexible disks may be obtained from
the ITU.

15    Operations and maintenance functions

    The following operations and maintenance functions shall be performed at the DCME. Addi-
tional operation and maintenance functions are under study:

a)    configuration of the DCME for operation in a network;

b)    traffic rearrangements under coordinated operator control;

c)    voice orderwire (VOW) communication to correspondent DCMEs;

d)    attendance to prompt maintenance alarms resulting from the channel check procedure, the
continuous BER measurement, and other fault conditions;

e)    storage and display of status information pertaining to the freeze-out fraction, DLC opera-
tion, channel check procedure, and control channel BER and fault analysis;

f)    redundancy switchover facility;

g)    display of statistical information and anomaly reports.

    The DCME should provide the following maintenance functions:

a)    Facilities for disabling (terminal out of service tests):

û    DSI: Digital Speech Interpolation;

û    LRE: Low Rate Encoding (ADPCM);

û    VBR: Variable Bit Rate Coding.

b)    Facilities for providing fixed connections of:

û    specific trunk channels to specific bearer channels, at 64kbit/s without interpolation,
40kbit/s without interpolation, 32kbit/s without interpolation and optionally at
24kbit/s or 16kbit/s without interpolation (see º4.2.1).

c)    Facilities for protected monitoring points (under study).

15.1    Configuration of the DCME for operation in a network

    Operation of DCME in a network will require bilateral or multilateral agreement between
correspondents on the use of trunk and bearer channels. Table9/G.763 outlines the operational
parameters on which bilateral or multilateral agreements are required.

    Operation of the DCME will also require configuration data which is of concern only to the
local user. Table10/G.763 outlines the unilateral operational parameters.

    The DCME shall include a capability to permit the entry of configuration data into a back-
ground mapping facility without interruption to service which is utilizing configuration data in a fore-
ground map. The configuration data shall permit operator control of:

a)    Dynamically assigned transmit and receive trunk time slots by permitting semi-permanent
TC to IT associations. TCs may be identified by digital group and time slot; ITs shall be
identified by number (1through216);

b)    Pre-assigned transmit and receive trunk time slots by permitting semi-permanent TC-to-IT-
to-BC associations. Pre-assignments of 24kbit/s bearer channels and optionally 16kbit/s
for maintenance and 64kbit/s, 40kbit/s and 32kbit/s bearer channels for maintenance or
traffic shall be possible. The number of pre-assigned channels for traffic need not be
symmetrical between transmit and receive sides.

c)    The transmit and receive order wires by permitting semi-permanent IT to correspondent
associations.

d)    The boundaries of the single (multi)-destination pool(s) for transmit and receive bearer
frames (upper bound pool1, lower bound pool2) shall be selectable in increments of one
8-bit time slot. The system does not require that the pool(s) occupy the entire bearer
frame. The bits in unused time slots should not be permitted to indicate an alarm condi-
tion in normal operation (note).

NoteûConfiguration and operation of DCME for special tandeming arrangement is for
further study.

e)    Channel check permanent associations (see Table12/G.763).





15.2    System management functions

15.2.1    Transmission facilities

    Each terminal should monitor each incoming digital link for the following conditions or
parameters and store separate cumulative counts of each type of event as required by users:

û    AIS, remote alarm indication;

û    loss of incoming signal, loss of frame alignment, reframe rate;

û    errored seconds, severely errored seconds;

û    slips, slip rate.

15.2.2    Terminal traffic handling performance

    The DCME terminals shall monitor and store records of the various parameters needed to
evaluate the traffic handling performance being provided. These shall include the statistics given in
Table11/G.763.



15.2.3    System statistics measurement

    Measurements and calculations of traffic statistics shall be done only on non-pre-assigned
trunk channels which are defined in the configuration data. The DLC ON ratio for voice/voice-band
data and the DLC ON ratio for 64kbit/s unrestricted traffic parameters shall be obtained separately
for each destination. All other parameters shall be obtained separately for each transmit pool. The
measurements of each parameter shall be made over an operator settable statistics time interval (STI).
Each statistic shall be calculated once every 1.0minute interval with the accumulated data from every
sampled DCME frame (e.g each 10th frame). The average over the STI shall be the average of the
values calculated each 1.0minute interval during the STI within the range from 10minutes to
60minutes (in 10minute steps).



    The BC states that need to be considered for the calculation of the system statistics are speci-
fied as follows:

û    Voice: The connected TC carries speech signals or in-band signalling or calling tones (and
marginally active voice-band data when not yet recognized as such), extended with their
corresponding hangover time (see Note1).

û    Data: The connected TC carries active voice-band data signals (including 2100Hz tone)
recognized as such, extended with its corresponding hangover time (and marginally
ôvoiceö signals when not yet recognized as such. (See Note2).

û    Transparent: The connected TC carries a 64kbit/s unrestricted traffic call.

û    Disconnected: No TC is connected to this BC.

û    Pre-assigned: The BC is permanently assigned to a TC.

    Note 1ûOnce a TC has been declared voice or data and the corresponding hangover time of
the connection has expired during inactivity, the TC is reputed to be declared initially as voice in both
cases when activity resumes. Furthermore when the hangover time of a voice call has not expired,
new activity in the BC is declared initially as voice.

    During low activity periods, after the above-mentioned hangover time expires, inactive voice
TCs will still be connected and coded like active ones at the rate of 4bits/sample as long as overload
BCs are not needed. (This is done to avoid front clipping when activity resumes on those TCs.)

    As a consequence, the average number of bits/sample for voice is significant only when the
result is less than 4bits/sample.

    Note 2ûWhen the hangover time of a data call has not expired, new activity in the BC is
declared initially as data.

    The system statistics monitor will deliver the results of calculations relative to the following
definitions. In the definitions, Nis the number of sampled DCME frames of the averaging period of
1.0minute.

15.2.3.1    bits/sample for voice

    Defined as the average number of encoding bits per sample for all connected TCs used for
voice. The average should be calculated to two decimal places.

15.2.3.2    voice queue freezeout fraction (voice FOF)

    Defined as the ratio of competitive clip duration to voice spurt duration. The fraction may be
determined as the ratio of the number of non-pre-assigned TCs classified as voice-active but not con-
nected, to the total number of non-pre-assigned TCs classified as voice-active connected plus not con-
nected. The ratio should be expressed as a percentage to three decimal places.



15.2.3.3    voice freezeout excess

    % of time voice FOF exceeds 0.5% when averaged over 1 minute



given to 2 decimal places.

15.2.3.4    voice activity ratio

    Defined as the ratio of the number of non-pre-assigned TCs which are classified as voice-
active, to the total number of non-pre-assigned TCs. The ratio is expressed as a percentage to the
nearest integer.



15.2.3.5    DLC voice on ratio

    Defined as the ratio of the number of DCME frames during which DLC for voice/voice-band
data (V/VBD) is ON, to the total number of DCME framesN. The ratio is expressed as a percentage
to the nearest integer.



15.2.3.6    data queue freezeout fraction (data FOF)

    Defined as the ratio of the number of non-pre-assigned TCs classified as data-active but not
connected, to the total number of non-pre-assigned TCs classified as data-active (connected + not
connected). The ratio should be expressed as a percentage to three decimal places.



15.2.3.7    data activity ratio

    Defined as the ratio of the number of non-pre-assigned TCs which are classified as data-
active, to the total number of non-pre-assigned TCs. The ratio is expressed as a percentage to the
nearest integer.



15.2.3.8    64 kbit/s failed seizures ratio

    Percentage of 64kbit/s on demand seizure (S64) attempts that receive a 64kbit/s negative
acknowledgement (S64 NACK) from the DCME



given as an integer.

15.2.3.9    64 kbit/s connected ratio

    Defined as the ratio of the number of non-pre-assigned TCs which are classified as 64 kbit/s
connect-called plus 64kbit/s connect-calling, to the total number of non-pre-assigned TCs. The ratio
is expressed as a percentage to the nearest integer.



15.2.3.10    DLC 64kbit/s on ratio

    Defined as the ratio of the number of DCME frames during which DLC for 64kbit/s unre-
stricted is ON, to the total number of DCME frames N. The ratio is expressed as a percentage to the
nearest integer.



15.2.3.11    average BER

    Average BER, as measured on the receive control channel



15.2.3.12    BER excess

    % of time average BER exceeds 1 ┤ 10-3  when averaged over 1.0 minute



given as an integer.

15.2.3.13    Severely errored seconds ratio (see RecommendationG.821)

    It is important that the voice and data performance are measured separately for the following
reasons:

û    the effect of freezeout and clipping is different on voice calls and data calls;

û    the DCME process gives priority to assigning activity classed as data and hence the freeze-
out figures for the data queue should always be less than the corresponding freezeout fig-
ures for the voice queue.

    The summary statistics calculated at the end of the STI shall be output to a statistics data file
on a secure storage medium (e.g.non-volatile RAM, hard disk,etc.).

15.3    Synchronizer

    The state of synchronization of each primary group interface, the selected clock source, and
the times of any failure or changes of clock source should be monitored.

15.4    Communication links

    The condition of all communication links should be monitored to detect failures as far as
practicable, including:

û    control channels;

û    ISC-DCME interface;

û    man-machine interface.

15.5    Reports

    The terminal should:

a)    at operator defined intervals, or when set parameters have been exceeded, or as a worst
15minutes report for any 24hour period, file operator selected parameters from those
monitored and stored plus header information such as terminal identification, date and
measurement period covered by the file;

b)    compare selected parameters, status or measurements with predetermined conditions;

c)    upon detection that predetermined conditions have been met or exceeded for a given period
of time, take the necessary action(s) which may include:

1)    filing of an anomaly report;

2)    transmission of alarm signals;

3)    blocking all new calls due to failure;

4)    switching to standby, if available;

5)    total shut down of the terminal.

15.6    System configuration

    The terminal shall include a non-volatile back-up memory containing a copy of the latest
configuration of the DCME, for use in failure situations. A non-working spare copy should also be
provided to allow changes in configuration to be made without impact upon service security. In cases
where cluster operation of terminals is used to provide additional service security, means must be pro-
vided for the standby terminal to adopt the configuration of the working terminal which it is intended
to replace.

    The configuration information shall include details of trunk side interface channel connec-
tions, modes of operation of any pre-assigned channels, and restrictions in force to any destination or
on any block of circuits (e.g.limit on the number of 64kbit/s calls) and synchronization source.

15.7    Failure protection strategy

    Upon detection of service affecting conditions the DCME shall take the appropriate actions
to protect existing traffic, such as switching to fallback timing sources or fallback units or where
redundancy is provided, transmission of DLC signals, disconnection of failed circuits, or transmission
of any appropriate alarm conditions.

15.8    Coordinated traffic rearrangements

    A map change handler (MCH) function shall be provided which the operator can manually
disable or enable. When disabled, it shall not be possible to command a map switch. When enabled, it
shall be possible to manually command a map switch. The coordination of map changes may be per-
formed between correspondents by voice orderwire.

    When the MCH is enabled, the channel check procedure shall be inhibited and the DLC ON
condition shall be automatically sent toward the local TCH and the local SCI.

    The MCH enabled condition shall be terminated by operator selection of either MCH dis-
abled or a map change command. Upon disabling, the channel check procedure shall restart and the
normal DLC conditions shall apply as defined in º9.

    During a traffic rearrangement, the BC, IT and data word contents in the CC shall be set to0.
When such an assignment message is received, no action shall be taken based on the assignment mes-
sage contents. However, the operator shall be notified.

    After the map change command is given, the foreground and background maps shall be
switched. The MCH shall initiate the MCH related processes associated with the DCME transmit
unit, the DCME receive unit and the 64kbit/s circuit handler after determining the parameters
required for their operation in accordance with the new foreground map (note). The channel check
procedure shall restart and the normal DLC conditions defined in º9 shall apply.

    NoteûThis function shall also initiate the MCH related processes which are required at
DCME system start-up.

15.9    Voice orderwire (VOW)

    It shall be possible to connect a VOW from the local DCME to any corresponding DCME by
accessing an ADPCM channel in competition with voice traffic. The voice signal and signalling tone
shall be PCM encoded using the companding law employed at the trunk interface. The off-hook con-
dition at the calling end shall generate the following signalling tone:

û    frequency:    2000Hz ▒ 10Hz;

û    duration:        1 s ▒ 0.1 s;

û    level:        -6 dBm0 ▒ 1 dB.

    ITs numbered 232, 233, 234 and 235 shall be used to route the VOW to a maximum of four
corresponding DCMEs. Detection of the signalling tone pertaining to one of the destination directed
ITs numbered232, 233, 234 and235 shall alert the operator of a pending VOW call. The destination
number cross-reference for the VOW ITs is presented in Table12/G.763.



15.10    In-service monitoring

15.10.1    Continuous BER measurements

    Continuous BER measurements shall be performed on the CC. The BER measurement shall
make use of the error syndrome of the (24/12) rate 1/2 Golay code specified for protection of the CC
in º11. When the CC BER exceeds1 in 103 (prior to correction) on the basis of a one minute mea-
surement interval, consequent actions shall be taken in accordance with Table13/G.763. When the
CCBER exceeds 1in 105 (prior to correction) on the basis of a 60s measurement interval, a high
BER condition shall be declared for use by the channel check procedure. (The CCBER threshold val-
ues are under study.)

PAGE BLANCHE POUR
TABLEAU  13/G.763

PAGE BLANCHE POUR
TABLEAU  13/G.763 (cont.)

PAGE BLANCHE POUR
TABLEAU  13/G.763  (end)

15.10.2    Channel check procedure

    The channel check procedure provides in-service verification of IT/BC channel assignments
between DCME transmit units and DCME receive units.

15.10.3    Test port

    A capability shall be provided to connect any IT to a TC test port for the purpose of injecting
or receiving externally generated test signals. For this purpose, the test port may either be subject to
DSI or may be a pre-assigned64, 40,32, or optionally 24or 16kbit/s channel.

15.11    Fault conditions and consequent actions

    The philosophy of fault conditions and consequent actions from the point of view of mainte-
nance of digital networks is consistent with that contained in the G.700-Series Recommendations in
the Red Book,
VolumeIIûFascicleIII.3, Malaga-Torremolinos,1984.

    Alarm conditions and the appropriate consequent actions are defined as follows:

15.11.1    Normal traffic carrying operating conditions

    The following shall apply when the DCME is carrying traffic, when no digital links are
exhibiting fault conditions and when the DCME is also not exhibiting a fault condition:

a)    the absence of alarm indications on the DCME terminal shall indicate a normal condition;

b)    the means used on the DCME terminal to indicate operating modes or to provide routine
information shall be of such form, colour or type that they cannot be confused with alarm
conditions.

15.11.2    Fault conditions (see Note)

    The DCME unit shall detect the following fault conditions:

a)    Failure of the incoming trunk primary group(s) û the fault conditions are loss of incoming
signal, loss of frame alignment or BER detected in frame alignment signal greater than 1
in 103 as defined in RecommendationG.736, for 2048kbit/s links, and
RecommendationG.734 for 1544kbit/s links.

b)    Alarm indication from the remote end, received from the local ISC.

c)    AIS detected on incoming primary trunk groups and/or abnormal (alarm) conditions of
associated incoming trunk circuits detected or loss of incoming supervision channel. The
circuit supervision function may be handled by the SCI.

d)    Failure of the incoming bearer signal û the fault conditions are loss of incoming signal, loss
of frame alignment or BER detected in frame alignment signal greater than 1 in 103 as
defined in RecommendationG.736.

e)    Bit error rate detected on the CC according to º15.10 exceeding 1 in 103.

f)    Loss of DCME frame or DCME multiframe alignment. (The time interval between recogni-
tion of an errored condition and a fault declaration is under study, e.g 2.5s.)

g)    Alarm indication from the remote end, received from correspondent DCME unit(s) [see
º15.11.3,f)].

h)    Alarm indication from the remote end received on any incoming bearer [see º15.11.3,g)].

i)    Indication of fault in affected TCs detected on IT related alarm bits in the incoming CC data
word [see º15.11.3,e)].

j)    DCME failure or DCME power failure.

    NoteûOptionally, a time delay selectable up to three seconds maximum shall be provided
before alarms are initiated or indications are transmitted in fault conditionsa, b,c and/ord of
º15.11.2.

15.11.3    Explanation of consequent actions

    Following the detection of a fault condition, appropriate actions shall be taken as specified in
Table13/G.763.

    The consequent actions are listed below:

a)    Backward alarm indication to the remote end (towards local ISCs) generated. For
2048kbit/s primary multiplex trunks, this is done by changing bit3 of channel time slot0
from state0 to state1 in those frames not containing the trunk frame alignment signal
(see RecommendationG.732). For 1544kbit/s primary multiplex trunks, this is done by
forcing bit2 in every channel time slot to the value0 or by modifying the S-bit for the
12frame multiframe or by sending a frame alignment alarm sequence for the 24frame
multiframe (see RecommendationG.733). This consequent action shall be effected as
soon as possible.

    The transmit activity detector shall be disabled for the ITs which are associated with the
faulty trunk interface and shall set the associated activity indication to inactive (INACT).

b)    Alarm indication signal applied on relevant trunk circuits towards local ISC(s), e.g.by AIS
on relevant time slots and by means of the out-of-service message through the SCI.

c)    AIS on primary trunk groups (all time slots).

d)    Prompt maintenance alarm indication generated to signify that performance is below
acceptable standards and maintenance attention is required locally. When the AIS (see
Note below) is detected, the prompt maintenance alarm indication, associated with loss
of frame alignment, excessive error rate in the frame alignment signal and in the bearer
assignment message (see º15.11.2,a), d) ande)), and with the loss of the synchronous
data word multiframe alignment (see º15.11.2) shall be inhibited, while the rest of the
consequent actions associated with these four fault conditions shall be followed in accor-
dance with Table13/G.763.

    NoteûThe equivalent binary content of the alarm indication signal (AIS) on the trunk groups
or time slots is a continuous stream of binary 1s. The strategy for detecting the presence
of the AIS will be such that with a high probability the AIS is detectable even in the pres-
ence of random errors having a mean error rate of 1 in 103. Nevertheless, a signal in
which all the binary elements, with the exception of the frame alignment signal, are in
state1, will not be taken as an AIS.

e)    Indication of fault in affected TCs generated on the corresponding ITs and forwarded to the
correspondent DCME receive unit on a per channel basis by setting the appropriate IT
related alarm bits in the CC data word to state1, (see Table5/G.763).

f)    Alarm indication to the remote end DCME receive unit is generated by changing the appro-
priate remote alarm indication bit(s) of the CC data word to state1, (see Table5/G.763).
This will be effected as soon as possible.

g)    Backward alarm indication to the remote end (towards remote ISCs) generated. For
2048kbit/s primary multiplex trunks, this is done by changing bit3 of Time Slot0 from
the state0 to the state1 in those frames not containing the bearer frame alignment signal
(see RecommendationG.732). For 1544kbit/s primary multiplex trunks, this is done by
forcing bit2 in every channel time slot to the value0 or by modifying the S-bit for the
12frame multiframe or by sending a frame alignment alarm sequence for the 24frame
multiframe (see RecommendationG.733). This consequent action shall be effected as
soon as possible.

h)    AIS on bearer signal (all time slots).

15.11.4    Alarm considerations specific to R2D line signalling

    When alarm conditions occur which require the signalling bits for the affected ITs to be set
a=b=1 this shall be specifically notified to the transmit R2 USM for each affected IT.

    When alarm conditions are cleared, the new signalling state conditions shall be notified as
state changed from a=b=1, for the affected ITs, in the normal manner to the R2 USM.

    When certain alarm conditions occur there is a danger of false activity being detected. For
these conditions the activity detector should be disabled for the ITs in question, and re-enabled when
the alarm condition has been cleared.

    The fault conditions and consequent action for R2D line signalling are summarized in
Table14/G.763.

PAGE BLANCHE POUR
TABLEAU 14/G.763

PAGE BLANCHE POUR
TABLEAU 14/G.763

15.11.4.1    R2D fault conditions

    The DCME unit shall detect the following fault conditions:

a)    Failure of the incoming trunk primary group(s).

The fault conditions are loss of incoming signal, loss of frame alignment, BER greater
than 1 in 103 detected in frame alignment signal, as defined in RecommendationG.736.

b)    AIS detected in incoming primary trunk groups.

c)    Loss of multiframe alignment (loss of incoming supervision channel) as defined in
RecommendationG.732.

d)    Remote alarm indication from local ISC (bit 3, TSO; bit 6, TS16).

The alarm conditions are bit 3 TSO set to 1 in those frames not containing the frame
alignment signal and bit6 TS16 set to 1 in frame0 of the PCM multiframe, as described
in RecommendationG.704.

e)    Failure of the incoming bearers primary group(s).

The fault conditions are loss of incoming signal, loss of frame alignment, BER greater
than 1 in 103 detected in frame alignment signal, as defined in RecommendationG.736.

f)    AIS detected on incoming primary bearer group(s).

g)    Remote alarm indication received on a bearer (bit 3, TSO).

The alarm condition is bit 3 TSO set to 1 in those frames not containing the frame align-
ment signal, as described in RecommendationG.704.

h)    CC decoder, high BER alarm.

The high BER alarm is raised when the BER in the assignment channel, as defined in
º15.10.1, exceeds 1 in 103 prior to correction.

i)    Loss of DCME multiframe or DCME frame alignment.

DCME frame and DCME multiframe alignment alarms shall be raised following loss of
the unique word sequence, as defined in ºº11.2 and11.2.1, in the synchronous bit pat-
tern of the CC.

j)    Remote bearer alarm

The alarm condition is the appropriate remote alarm indication bit of the CC asynchro-
nous word set to1, as defined in Table5/G.763.

k)    Remote IT alarm received in the asynchronous data word.

The alarm condition is the relevant IT identification bit set to 1 in the asynchronous data
word (see Table5/G.763).

l)    DCME functional or power supply failure.

Service affecting any internally detected fault condition.

15.11.4.2    R2D consequent actions

    Further to the detection of a fault condition, appropriate actions shall be taken as specified in
Table14/G.763. However, if redundant equipment is provided and detection of a fault condition is
effectively removed by an automatic switchover, prompt maintenance alarm (if applicable) shall be
deferred and other consequent actions shall not be taken.

a)    Backward alarm indication (bit 3 TSO) towards local ISC.

This is done by setting bit 3 TSO to 1 in those frames not containing the frame alignment
signal. This signal shall not be sent if the fault condition is AIS detected.

b)    Backward alarm indication (bit 6, TS16) towards local ISC.

This is done by setting bit 6 of TS16 to 1 in PCM frame0 of the multiframe.

c)    a=b=1 towards local ISC in circuits concerned.

The corresponding a and b bits for the affected circuits in TS16 of frames 1 to 15 of the
PCM multiframe shall be set to1. Refer to RecommendationG.704.

d)    AIS towards local ISC.

AIS = alarm indication signal as described in RecommendationG.704.

e)    Activity detector disabled.

The activity detector output shall be set to the inactive state for the ITs concerned and
remains in this state as long as the disabling applies.

f)    R2D line signalling bits, a=b=1.

The R2 USM local array a and b bits shall be set to 1 for the relevant circuits (see
º15.11.4.1).

g)    Asynchronous word. IT fault bit set in data word.

For the affected circuits the relevant IT related circuit supervision bits of the asynchro-
nous data word shall be set to 1. Refer to Table5/G.763.

h)    Asynchronous word. Bearer alarm.

For the affected bearer the relevant backward bearer alarm of the asynchronous data
word is set to1. Refer to Table5/G.763.

i)    Prompt maintenance alarm

An audible/visual alarm indication to alert the operator to the presence of a fault condi-
tion. To be specified by the users.

16    Glossary

    ADPCM        Adaptive Differential pulse code modulation

    AIS            Alarm indication signal

    BC            Bearer channel

    BER        Bit error ratio

    BMI            Bit map implementation process

    B8ZS        Bipolar eight zero substitution

    UCA        Capacity available

    CC            Control channel

    UCNA        Capacity not available

    DAF        Dynamic assignment function

    DCME        Digital circuit multiplication Equipment

    DCMG         Digital circuit multiplication Gain

    DCMS         Digital circuit multiplication System

    DDI            Direct digital interface

    DEC        Decoder control process

    DEMUX        Demultiplex

    DLC        Dynamic load control

    DNI            Digital non-interpolated

    DSH        Dual seizure handling

    DSI            Digital speech interpolation

    DW            Data word

    D/S            Data/speech

    ENC        Encoder control process

    FDX        Full duplex

    F-bit        Framing bit

    FOF         Freeze-out fraction

    HDX        Half duplex

    HL            High load

    HSC            Hangover control and signal classification process

    IDR            Intermediate data rate

    IG             Interpolation gain

    IPS            Input processing and service request generation block

    ISC             International switching centre

    ISUP         ISDN User Part

    IT            Intermediate trunk

    LL            Low load

    LRE         Low rate encoding

    LSB            Least significant bit

    MCH        Map change handler

    MOS         Mean opinion score

    MSB        Most significant bit

    MUX        Multiplex

    NRZ        Non-return-to-zero

    O&M        Operations and maintenance

    QDU         Quantization distortion unit

    QPSK        Quadrature phase shift keyed

    RAG        Request handling & assignment information generation process

    RCP            Receive channel processing block

    RUD        Receive channel status update and overload channel decoding process

    SBC            SC bit map creation process

    SCI            Switching centre interface

    SRH            Service request handling block

    SS            Signalling system

    STI            Statistics time interval

    TC            Trunk channel

    TCH        Transparent circuit handler

    TCP            Transmit channel processing

    TDMA        Time division multiple access

    TG             Transcoding gain

    TMN         Telecommunications management network

    TS            Time slot

    TTF            Test time frame

    USM        User signalling module

    UW            Unique word

    VBR         Variable bit rate

    VOW        Voice orderwire

    ZBTSI        Zero byte time slot interchange

    ZCS            Zero code suppression


List of internal/external messages/indications

    AD64        Activate DLC for 64-kbit/s traffic

    ADVD        Activate DLC for voice/voice-band data traffic

    DD64        De-activate DLC for 64-kbit/s traffic

    DDVD        De-activate DLC for voice/voice-band data traffic

    R64            Release 64-kbit/s circuit

    R64Ack        Release 64-kbit/s circuit Acknowledged

    S64            Seizure/Select 64-kbit/s circuit

    S64Ack        Seizure/Select 64-kbit/s positive Acknowledged

    S64NAck    Seizure/Select 64-kbit/s Negative Acknowledged

    SA            Capacity for speech available

    SNA        Capacity for speech not available

    UCA        Capacity for 64-kbit/s unrestricted available

    UCNA        Capacity for 64-kbit/s unrestricted not available

    VDA        Capacity for 3.1-kHz data available

    VDNA        Capacity for 3.1-kHz data not available