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

Text File | 1993-08-15 | 84KB | 1,767 lines

C:\WINWORD\CCITTREC.DOT_______________

ANNEX A

(to Recommendation G.763)

Examples of DCME transmit/receive unit structure and SDL diagrams

A.1    An example of a DCME transmit unit structure

    An example of a DCME transmit unit structure is shown in FigureA-1/G.763.
Compliance with this transmit unit structure will permit the DCME transmit function
to be tested with INTELSAT IESS-501(Rev.2) compliant DCME test equipment and
software protocol references. This structure is based on a non-mandatory partitioning
of functions and definition of signals.

    Some of the functional blocks in FigureA-1/G.763 are internal to the DCME
transmit unit structure, while others are external but provide required interface signals.
The blocks that belong to the transmit unit structure are:

a)    Transmit Activity Detector û This block produces an IT Active/Inactive input
for the Transmit Channel Processing Function. The detector has no built-in
hangover, since the hangover control task is performed by the transmit
Channel Processing function. The specification for the Transmit Activity
Detector is provided in º12.1.

b)    Data/Speech Discriminator û This block recognizes voice and single tones as
speech and recognizes data and 2100Hz tone as data. Its specifications are
provided in AnnexB.3.

c)    2400Hz Tone Detector û This block provides a detection indication when the
2400Hz signalling tone is present. The specification for this block is pro-
vided in AnnexB.4.

d)    The Transmit Channel Processing (TCP) Function û This function consists of
an ensemble of interconnected processes. Its task is to process the inputs
received from blocks a), b) and c) above as well as inputs originating from
external blocks. The TCP function produces three outputs, each directed to
the Encoder Unit, the Assignment Message Encoder, and the BC Bit Assign-
ment Unit(s). These blocks are defined below.

e)    The Encoder Unit û This unit consists of a bank of ADPCM encoders which
can be connected to any transmit IT and to any BC. Each BC can carry 8, 5,
4, 3, or optionally 2bits per PCM sampling cycle or can be disconnected
from the coders.

    The encoders can be set to 8/5/4/3/optionally 2bit mode of operation and can be
initialized to a known state. The IT and BC connection/disconnection infor-
mation for each encoder, as well as the mode of operation selection and the
initialization signal are provided by the TCP function.

f)    The Assignment Message Encoder û This unit encodes the IT-to-BC associa-
tion, and the channel type (data/speech, or 64kbit/s) into the format speci-
fied in º11. The necessary information is provided by the TCP function.

g)    The BC Bit Assignment Unit û This unit is connected to the output of the
Encoder Unit (BCs). The BC Bit Assignment Unit maps the bits of each BC
onto the bits of the bearer pool channels. The bit map for the bearer pool
channel association is provided by the TCP function.

    The blocks a), b) and c) operate on a single IT in the representation in FigureA-1/
G.763. Conceptually, these blocks must be considered as time multiplexed, scanning
all relevant ITs.

    The blocks which are external to the transmit Side Structure but provide required
inputs are the following:

a)    Assignment Message Decoder û Information on the data/speech type of the
received IT is passed to the TCP function together with the corresponding
transmit IT number. The receive IT/transmit IT association is performed by
the Receive Channel Processing Function.

b)    Transparent Circuit Handler û This process either forwards a request to the
TCP function for a transparent 64kbit/s channel or sends a message releas-
ing the channel. The Transparent Circuit Handler Process is specified in º8.

c)    Map Change Handler û The Map Change Handler (MCH) is a process which
controls the configuration data for the DCME. At start-up, this process
issues signals making it possible to configure the system correctly. The same
is done at a map change instant. Refer to ºº15.1 and 15.6.

d)    Trigger Pulse Generator û This unit provides a periodic 2ms timing reference
signal to the processing functions of the transmit unit (see Note).

e)    User Signalling Module (Optional) û This user signalling module (USM) gen-
erates signalling state change signals. The specification of the USM is at the
user's option.

    Note û The trigger pulse generator will also provide a sync trigger pulse to iden-
tify the first frame of a DCME multiframe. This permits a capability to
transfer out-of-band signalling within the control channel.

Figure A-1/G.763 = 19.5 cm





A.1.1    Transmit Channel Processing Function

    The Transmit Channel Processing Function (TCP) interfaces with the other ele-
ments of the transmit Side Structure as shown in FigureA-1/G.763. Each interface sig-
nal is identified in FigureA-1/G.763 with a specific number. The signal path
originating from the MCH carries a reset signal to five different TCP processes and,
therefore, takes five different numbers. The signal path originates from the trigger
pulse generator, carries trigger signals to four different processes, and therefore, takes
four different numbers.

    The TCP function monitors the status of each IT and takes consequent actions.
The status of each IT is used by the internal TCP processes to generate the information
required by the Encoder Unit, the Assignment Message Encoder and the BC Bit
Assignment Unit. Reset signals are provided to the internal blocks previously listed
under a), b) and c).

    The internal structure of the TCP functions is shown in FigureA-2/G.763. The
TCP function contains the Input Processing and Service Request Generation Block
(IPS) and the Service Request Handling Block (SRH).

A.1.1.1    The IPS Block

    The IPS Block input/output connections are shown in FigureA-2/G.763. The
IPS Block processes the TCP inputs (signal path 1 through 6) and generates IT status
transition information (signal path12) for the other block (SRH) of the TCP function.
The IPS Block also generates a reset signal (signal path 17) for the transmit Activity
Detector, the Data/Speech Discriminator and the 2400Hz tone detector. The IPS Block
must be considered as time multiplexed, processing all the ITs of the pool.

Figure A-2/G.763 = 13 cm



    The internal structure of the IPS Block is shown in FigureA-3/G.763. This block per-
forms the Hangover Control and Signal Classification Process (HSC) on each IT.

Figure A-3/G.763 = 8.5 cm



A.1.1.1.1    The HSC process

    The HSC input/output connection is shown in FigureA-3/G.763. The HSC Pro-
cess receives the IPS inputs 1 through 6, processes them, and provides an input (signal
path 12) to the SRH Block. The HSC Process resets (signal path17) the detectors and
discriminator. The process-reset signal from the MCH (signal path6) terminates the
HSC Process at a map change instant. The above signal paths carry the following mes-
sages:

û    Signal Path 1:    Activity detected (ôActö), Inactivity detected (ôInactö).

û    Signal Path 2:    Data Detected (ôData-detectö), Speech detected (ôVoice-
detectö).

û    Signal Path 3:    2400Hz tone detected (ôSignaldetectö).

û    Signal Path 4:    Receive data detected (ôRxdataö).

û    Signal Path 5:    Transparent channel request (ôTranspreqö), Transparent channel
release (ôTransprelö).

û    Signal Path 6:    Process-Reset signal from the MCH.

û    Signal Path 12:    The messages (related to changes of signal classification) are
ôVoice(IT)ö, ôVoiceinact(IT)ö, ôData(IT)ö, ôDatainact(IT)ö and
ôTransp(IT)ö and ôDiscreq(IT)ö.

û    Signal Path 17:    Carries the following messages:

a)    ôReset-actö (set activity detector to inactive).

b)    ôReset-Signaldetectö (reset 2400Hz detector to nodetect).

c)    ôDefault-Voiceö (set discriminator to voice).

d)    ôDefault-Dataö (set discriminator to data).

    The HSC process should perform signal classification and hangover control as speci-
fied below.

a)    Initially, this process should declare an IT either ôpre-assignedö, if so desig-
nated by the configuration data, or ôvoice-inactiveö, if subject to DSI.

b)    Whenever a ôTranspreqö message is received, the IT should be classified as
ôTransparentö and should remain in this condition until a ôTransprelö mes-
sage is received, in which case the signal classification should change to
ôVoice-inactiveö.

c)    If the IT is active and of the voice/signalling type and the ôData-detectö mes-
sage is received from the Data/Speech Discriminator, the IT should be clas-
sified as ôData-activeö. The same applies to the case of reception of
ôRxdataö from the DCME receive unit as long as the 1s delay timer (hold
mode, defined later) is not running. No action should be taken if the timer is
running.

    If the IT is inactive (hangover timer either expired or running), and of the data
type and the message ôActö is received from the Activity Detector, the IT
should also be classified as ôData-activeö.

d)    If the IT is inactive (hangover time expired) and of the voice/signalling type
and the ôRxdataö message is received, the IT should be classified as ôData-
inactiveö, as long as the 1s delay timer is not running. No action should be
taken if the timer is running (hold mode).

    If the IT is of the data type and the hangover timer expires, the IT should also be
classified as ôData-inactiveö.

e)    If the IT is inactive and in the hold mode and the 1s delay timer expires, the
IT should be classified as ôVoice-inactiveö.

    If the IT is of the voice/signalling type and the hangover time expires, the IT
should also be classified as ôVoice-inactiveö.

f)    If the IT is inactive (hangover timer either expired or running) and of the voice
type and the ôActö message is received from the Activity Detector, the IT
should be classified as ôVoice-activeö.

g)    If the IT is active and of the data type and the message ôVoice-detectö is
received from the Data/Speech Discriminator, a 1s delay timer should be
started and the IT should be classified as ôVoice-active-holdö.

    If the 1s timer is running for an inactive voice IT (hangover timer either expired
or running) and the ôActö message is received, the IT should also be
declared ôVoice-active-holdö.

h)    If the IT is active and of the voice type and the message ôSignaldetectö is
received from the signalling tone detector, the IT should be classified as
ôSignalling-activeö.

    If the IT is of the signalling type and the hangover timer is running and the mes-
sage ôActö is received, the IT should also be classified as ôSignalling-
activeö.

i)    If the IT is active and of the data type and the ôSignaldetectö message is
received, a 1s delay timer should be started and the IT should be classified
as ôSignalling-active-holdö.

    If the 1s timer is running for an active voice IT and the ôSignaldetectö message
is received, the IT should be classified as ôSignalling-active-holdö.

j)    If the IT is inactive and of the voice type, the hangover timer is running and an
ôRxdataö message is received, the data detector shall be set to data and the
IT should enter the ôWait-for-dataö state.

    If the IT is inactive and of the signalling type, the hangover timer is running and
an ôRxdataö message is received, the data detector should be set to data and
the IT should enter the ôWait-for-dataö state.

    If the hangover timer expires while the IT is in the ôWait-for-dataö state, the
ôVoiceinactö message should be sent and the IT should be classified as
ôDatainactiveö.

    When activity first terminates on an IT, classified as ôData-activeö, the ôinitial
data hangoverö value should be used. Its duration should be settable to a
maximum of 14s. After the first expiration of the ôinitial data hangoverö,
the ôsecond data hangoverö should be brought into use. This hangover
should also be settable to a maximum of 14s, but it is expected that in most
cases, it will be set to a value significantly shorter than the initial data hang-
over. This permits higher efficiency of utilization of the return link for fac-
simile transmission.

    When activity terminates on an IT classified as ôVoice-activeö or ôVoice-active
holdö, the Voice Hangover Value should be used. When activity terminates
on an IT classified as ôSignalling-activeö or ôSignalling-active holdö, the
Signalling Hangover value should be used. The Voice and Signalling Hang-
over values should be in accordance with the hangover masks specified in
º12.

    The message ôVoice(IT)ö is associated with the transition to ôVoice-activeö,
ôVoice-active-holdö and ôSignalling-active-holdö. The message ôVoice-
inact(IT)ö is associated with the transition to ôVoice-inactiveö and ôVoice-
inactive-holdö. The messages ôData(IT)ö and ôDatainact(IT)ö are associated
with the transitions to ôData-activeö and ôData-inactiveö, respectively. The
message ôDiscreq(IT)ö is generated whenever a transition occurs from
ôtransparentö to ôVoice-inactiveö.

    The reset messages carried by signal path 17 should be generated at initializa-
tion (except ôDefault-Dataö).

    The reset messages should also be generated during operation when the active/inactive
or channel type classification changes for causes other than a corresponding change in
the detector/discriminator output.

A.1.1.2    The SRH Block

    The SRH Block input/output connections are shown in FigureA-2/G.763. The
SRH Block processes the IT transition information (signal path 12) received from the
IPS block. It also generates assignment information for the Assignment Message
Encoder (signal path 8), encoder connect/disconnect and mode information for the
Encoder Unit (signal path7) and the BC Bit Map for the BC Bit Assignment Unit (sig-
nal path9).

    The internal structure of the SRH Block is shown in FigureA-4/G.763. This
block contains the Request Handling and Assignment Generation Process (RAG), the
BC Bit Map Creation Process (SBC), the Bit Map Implementation Process (BMI), and
the Encoder Unit Control Process (ENC).

Figure A-4/G.763 = 13 cm



A.1.1.2.1    The RAG Process

    The RAG Process input/output connection is shown in FigureA-5/G.763. The
RAG Process also receives an input signal (signal path21) from the MCH, which
resets the process at the map change instant. It also receives a trigger pulse (signal
path19). The trigger pulse provides a timing reference once per DCME frame for the
RAG process. When required, the RAG process will also receive a signal from the
optional USM. This signal (signal path200) contains the ôchange (IT)ö message (see
Note).

    NoteûThis signal permits a capability to transfer out-of-band signalling within
the control channel.

Figure A-5/G.763 = 14 cm



    The RAG Process receives IT transition information from the IPS Block (signal path
12) and generates the following outputs:

û    Signal Path 8:    This signal path carries the ôAssignö message which contains
assignment information needed by the Assignment Message Encoder
(and by the other processes of the block). This message is also
present on signal path13. The message contains a BC number, an IT
number, the BC type, and encoder number with the format (BC, IT,
type, encoder number). The Assignment Message Encoder extracts
the relevant information elements from the ôAssignö message and
adds additional information, as required by the control channel mes-
sage structure (specified in º11.1). In the DCME frames which are
used by the optional USM, the BC number should be 255, type data
and encoder number0.

û    Signal Path 13:    This signal path carries the following messages:

                    ôAssignö û This is the same message as in signal path8.

                ôReinsert (BC)ö û This message is used to reinsert a BC into the
overload channel generation map within the SBC process when an
implicit disconnect of a data call has occurred (see ºA.1.1.2.2).

                ôRemove (BC)ö û It removes an implicitly disconnected overload
channel from the SBC overload BC list (see ºA.1.1.2.2).

                ôSeizesc (BC, encoder no., enc. mode)ö û It generates a fixed associ-
ation between a BC number and an ADPCM encoder number, for a
pre-assigned channel in the SBC Process (see ºA.1.1.2.2). The
ADPCM encoder mode could be 8/5/4/or optionally 3 or 2bits per
sample. This message is transmitted immediately after initialization.

                ôSeizebank (BC)ö û This message notifies the SBC Process that a
certain BC has been seized as a bit bank (see ºA.1.1.2.2). It is trans-
mitted immediately after initialization.

                ôReleasesc (BC)ö û This message releases a bit bank connection and
is given to the SBC process (see ºA.1.1.2.2).

                ôRelease (enc. no.)ö û This message updates the ADPCM encoder
map within the SBC process (see ºA.1.1.2.2).

û    Signal Path 16:    This signal path carries the following messages:

                ôAssign-enc (BC, IT, type)ö û This is used to give channel connec-
tion information to an ENC process.

                    ôRelease-encö û This message causes the encoder to release any
connection.

                ôSet-pre (mode, IT)ö û This message causes seizure of an encoder for
a pre-assigned connection. The mode can be 8, 5, 4 or optionally 3, or
2 bit. This message is transmitted immediately after initialization
phase.

    The RAG Process can be functionally divided into four tasks, namely, Input
Pre-Processing, Service Request Implementation, Refreshment Message Generation,
and Map Update/Coder Selection. This is illustrated in FigureA-5/G.763.

    The Input Pre-Processing Task processes the input IT transition information,
and either updates the channel type (discussed below), or generates service requests to
be placed in prioritized queues.

    The Service Request Implementation Task services the requests in the queues
by assigning ITs to BCs or deleting the existing IT-to-BC association.

    The Map Update/Coder Selection Task updates a central Resource Map based
on the action of the Service Request Implementation Task. The Resource Map contains
information to identify the IT-to-BC association (including disconnected BCs and ITs),
the BC type, and the IT-to-ADPCM encoder association. The possible BC types are the
following:

a)    ôVoiceö û Indicates the BC carries a voice signal that is either active or in the
hangover period;

b)    ôDataö û Indicates that the BC carries a data signal that is either active or in
the hangover period;

c)    ôTransparentö û Indicates that the BC carries a transparent call;

d)    ôDisconnectedö û Indicates that the BC is not connected;

e)    ôVoice-availableö û Indicates that the BC is currently connected to a speech
IT but could be used for a new assignment;

f)    ôData-availableö û Indicates that the BC is currently connected to a data IT
but could be used for a new assignment;

g)    ôPre-assignedö û Indicates that the BC is permanently assigned to an IT, in
accordance with the DCME configuration data.

h)    ôBankö û This 4-bit BC can be used to obtain the LSBs of up to four data
channels (the bit bank concept is discussed later).

    The ADPCM encoder selection and the generation of the messages carried by signal
paths 8, 13 and 16 is functionally assigned to this task.

    The Refreshment Message Generation Task generates assignment information for the
Assignment Encoder when no higher priority Assignment message generation is
required.

A.1.1.2.1.1    Input pre-processing task

    The messages received from the IPS Block (signal path 12) contain signal tran-
sition information for each IT. When using the optional USM, messages (signal path
200) will be received. The Input Pre-Processing Task performs the following actions:

a)    processes the IT transition information and generates service requests;

b)    places the service requests in prioritized queues, which are accessed by the
Service Request Implementation Task.

    Six queues are established, each with an associated priority:

a)    Priority 0 Queue û It stores the IT number contained in a ôchange (IT)ö mes-
sage;

b)    Priority 1 Queue û It stores the 64kbit/s IT disconnect requests;

c)    Priority 2 Queue û It stores internally generated requests for disconnection of
overload BCs.

d)    Priority 3 Queue û It stores the 64kbit/s IT connection requests;

e)    Priority 4 Queue û It stores the request for assignment of data channels;

f)    Priority 5 Queue û It stores the requests for assignment of voice channels.

    When a ôdata-inact(IT)ö message is received, the type of the BC connected to the IT
shall be updated to ôdata-availableö, unless there is another request in the queue for the
same IT and the BC type is ôvoiceö. In this case, the BC type shall be changed to
ôvoice-availableö.

    When a ôvoice-inact(IT)ö message is received, the type of the BC connected to the IT
shall be updated to ôvoice-availableö, unless there is another request in the queue for
the same IT and the BC type is ôdataö. In this case, the BC shall be changed to ôdata-
availableö. If the BC is in the overload range, a disconnect request shall be stored in
Priority2 queue.

    When a ôVoice(IT)ö message is received, the type of BC connected to this IT should be
checked. If the type of BC is ôVoiceö or ôVoice-availableö, the BC type should be
changed to voice and no request shall be generated. If the BC type is other than ôVoice-
availableö, a request should be stored in the Priority5 queue.

    When a ôData(IT)ö message is received, the type of the BC connected to this IT should
be checked. If the type of BC is ôDataö or ôData-availableö, the BC type should be
changed to data and no request should be generated. If the BC type is other than ôData-
availableö, a request should be stored in the Priority4 queue.

    When a ôTransp(IT)ö message is received, a request should be stored in the Priority3
queue.

    When a request pertaining to IT arrives, and there is a request for this IT in any of the
queues, the stored request should be deleted if in Priority queues2 to 5 and should be
maintained if in Priority queue1. If the stored request is in Priority queue1 and the
new request is also for Priority queue1, the new request should be deleted. A message
for Priority0 queue should be stored in Priority0 queue without checking any other
queue.

A.1.1.2.1.2    Service request implementation task

    At the time of reception of the trigger pulse, if there are messages in the queues,
and if there are no 64kbit/s or data assignments in progress, the Priority1 Queue
should be addressed. If the message count for this queue is one or more, the RAG Pro-
cess should address the first request in the queue (first in, first-out order) and delete it
when serviced. If the message count is0, the next lower priority queue should be
addressed. The same procedure should be repeated for the other queues. At the next
trigger pulse, the cycle should restart from Priority1Queue. The actions to be taken
for the implementation of the different service requests are specified separately below.
At the first frame of a multiframe the trigger pulse is replaced by a sync trigger pulse
(refer to º11). In the case where the optional USM is not used, the Priority0 Queue
should not be addressed. In the case where the USM is used, the Priority0 Queue
should be addressed in DCME frames0, n, 2n, etc. (i.e., every nthframe), of the
DCME multiframe where n is a variable which may be selected by the user. Priority1
through 5 queues should be addressed in the remaining DCME frames.

a)    Change Message û If the optional USM is used, the Priority0 Queue should
be addressed in DCME frames0, n, 2n, etc. (i.e., every nthDCME frame) of
the DCME multiframe where n is a variable which may be selected by the
user. Upon servicing the request, the message should be deleted from the
Priority0 Queue.

b)    Discreq Requests û The request at the top of Priority1 Queue should be
addressed. An assignment should be generated which disconnects the IT.
This request should be deleted from the queue.

c)    BC Disconnect Requests û The request at the top of Priority2 Queue should
be addressed. An assignment should be generated which disconnects the IT.
The service request should be deleted.

d)    Transp Requests û The request at the top of Priority3 Queue should be
addressed. The IT for which the request was generated should be checked to
determine whether connected or disconnected.

    If the IT is connected, a count of the usable bits in the pool should be taken to
determine whether enough capacity exists to accommodate the additional
bits required. If no capacity exists, the assignment which disconnects the
available BC (and the associated IT) should be generated. The RAG Process
should address the Priority1 Queue again at the next occurrence of the trig-
ger pulse.

    If the IT is connected and enough capacity exists to accommodate the additional
bits, the BC number of the connected bearer channel (numberk) should be
checked to determine whether it is even or odd. If k is even, the next higher
BC (number k+1) should be examined. If k is odd, the next lower BC (num-
ber k-1) should be examined. The objective is to allocate the first nibble
(containing the MSB) of the 64kbit/s channel to an even numbered BC. If k
is even and BC k+1 is contained in the pool, the type of BC k+1 should be
checked. If the type is ôDisconnectedö, ôData-availableö or ôVoice-avail-
ableö, the 64kbit/s IT should be assigned to BCk (and by implication, to
BCk+1). If the type of BCk+1 is either ôDataö or ôVoiceö, a re-assignment
of this IT will be required. This should be done by invoking the

Search-Data Procedure (ºA.1.1.2.1.6) or the Search-Voice Procedure
(ºA.1.1.2.1.7), respectively. If the type of BCk+1 is either ôBankö or ôPre-
assignedö, or if BCk+1 is not contained in the pool, the Search-Transparent
Procedure should be invoked (as specified later).

    A similar approach should be taken if k is odd. In this case the BC to be exam-
ined is k-1.

    If the IT is disconnected, the number of usable bits in the pool should be
counted to determine whether the request can be accommodated (8bits are
required). If the request can be accommodated, the Search-Transparent Pro-
cedure should be invoked. If the request cannot be accommodated, a
Refreshment Message (ºA.1.1.2.1.3) should be generated.

    The Search-Transparent Procedure is invoked (ºA.1.1.2.1.5) to select a suitable
BC pair for the assignment. The Search-Transparent Procedure delivers the
encoder number to be used (see ºA.1.1.2.1.4 for the encoder selection) and
the values for 11 variables (see TableA-2/G.763). These variables consist of
the two bearer channels (bc and bc+1) selected for allocation of the 64kbit/s
IT, the two ITs (nrvl and nrv2) occupying bearer channels bc and bc+1, the
bearer channels (bcv1 and bcv2) to which nrv1 and nrv2 can be re-assigned,
the two ITs (nrv3 and nrv4) occupying bearer channel bcv1 and bcv2 and the
overload bearer channels (bcv3 and bcv4) to which the ITs nrv3 and nrv4
can be re-assigned. The bearer channel bc is an even-numbered BC. The
variable ôsuccessö gives the result of the search. If the search is successful,
success is set to TRUE, or else FALSE.



    Whenever a nrv variable (nrv1 through nrv4) is 0, re-assignment/disconnection
of the IT is not required. Whenever a bcv variable (bcv1 through bcv4) is 0,
the BC is not required for re-assignment.

    The IT nrv4 should be examined first. If nrv4 is 0 (IT re-assignment/disconnec-
tion not required), nrv3 should be examined. If nrv4 is different from 0 (IT
re-assignment/disconnection required) and bcv4 is also different from 0 (BC
required for re-assignment of nrv4), nrv4 should be re-assigned to bcv4. At
the next trigger pulse, nrv3 should be examined.

    If nrv4 is different from 0 and bcv4 is 0 (BC not required for re-assignment of
nrv4), nrv4 should be (internally) disconnected and nrv3 should be exam-
ined.

    Equivalent steps should be implemented for nrv3 and nrv2.

    When nrv1 is examined, if equal to 0 (IT re-assignment/disconnection not
required), the 64kbit/s IT should be assigned to bearer channel bc.

    If nrv1 is different from 0 (IT re-assignment/disconnection required) and bcv1
is also different from 0 (BC required for re-assignment of nrv1), nrv1 should
be re-assigned to bcv1. At the next trigger pulse, the 64kbit/s IT should be
assigned to bearer channel bc.

    If nrv1 is different from 0 (connected) and bcv1 is 0 (BC not required for re-
assignment of nrv1), nrv1 should be (internally) disconnected and the
64kbit/s IT should be assigned to bearer channel bc.

    At implementation, the service request should be deleted from Priority3 Queue.

e)    Data Requests û Five bit encoding is required for the transmission of a data
channel. Four bits are obtained by assigning the data IT to a 4-bit BC in the
normal BC range. The 5th bit (LSB) is obtained from a pool of 4bits
referred to as the bit bank. Special 4-bit BC channels of the ôBankö type are
created in the bearer frame for this purpose. The criteria for creation of bank
channels are specified in TableA-3/G.763.



    The request at the top of the Priority4 Queue should be addressed. First, it
should be determined whether a new bit bank is required. Then, the IT for
which the request was generated should be checked to determine whether
connected to a BC.

    If the IT is connected, a bit count should 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 the connected BC is in the normal range, and a
new bit bank is not required, an assignment of the data IT to the connected
BC should be made.

    If a bit bank is required, it should be assigned in the same way as a data channel
by invoking the Search Data Procedure (as specified later). An assignment
message connecting the selected BC to IT No.250 should be generated. At
the next trigger pulse, the data IT should be assigned to the connected BC.

    If sufficient capacity is available, but the connected BC is in the overload range,
the data IT should be assigned by invoking the Search Data Procedure (spec-
ified later).

    If sufficient capacity is not available and the IT is connected, a disconnect mes-
sage should be generated.

    If the IT is disconnected, a count of the usable bits in the pool should be made to
determine whether enough capacity exists to allocate the data call. If suffi-
cient capacity is not available, a refreshment message should be generated.
If sufficient capacity is available and a new bit bank is not required, the
Search Data Procedure (ºA.1.1.2.1.6) should be invoked to select a suitable
BC for the assignment of the data IT. If the bit bank is required, it should be
assigned first, and then the data IT should be assigned as specified below.
The Search Data Procedure delivers the ADPCM encoder number to be used
(see ºA.1.1.2.1.4 for the ADPCM encoder selection) and three values for
the three variables defined in ºA.1.1.2.1.6.

    The IT nrv should be examined. If nrv is 0 (BC disconnected), the data IT
should be assigned to bearer channel bc.

    If nrv is different from 0 (BC connected) and bcv is also different from 0 (re-
assignment required), nrv should be re-assigned to bcv. At the next trigger
pulse, the data IT should be assigned to bearer channelbc.

    If nrv is different from 0 (BC connected) and bcv is 0 (re-assignment not
required), nrv should be (internally) disconnected and the data IT should be
assigned to bearer channel bc.

    The service request, at implementation, should be deleted from Priority4
Queue.

f)    Voice Requests û The request at the top of Priority5 Queue should be
addressed. The IT for which the request was generated should be checked to
determine whether connected to a BC.

    If connected and the BC type is ôAvailableö, the IT should be assigned to the
available BC. If the BC type is ôDataö, an assignment should be made to that
BC.

    If the IT is disconnected, the usable bits in the pool should be counted to deter-
mine whether enough capacity exists to accommodate the voice call. If suffi-
cient capacity does not exist, a refreshment message should be generated.

    If sufficient capacity exists, the Search-Voice Procedure should be invoked to
select a suitable BC for assignment. This procedure delivers the ADPCM
encoder number to be used (see ºA.1.1.2.1.4 for the ADPCM encoder
selection) and the values of the variables nrv and bc, defined in
ºA.1.1.2.1.3.

    If nrv is 0 (BC disconnected), the voice IT should be assigned to bearer channel
bc. If nrv is different from 0 (BC connected), nrv should be (internally) dis-
connected and the voice IT should be assigned to bearer channel bc.

    The service request, at implementation should be deleted from Priority5 Queue.

g)    The Search-Transp Procedure, Search-Data Procedure and Search-Voice Pro-
cedure search for BC(s) to allocate to the IT(s) of Transp Requests, Data
Requests and Voice Requests, respectively. In each procedure, a scan of the
normal BC range shall begin at a randomized starting point which is not
specified herein.

A.1.1.2.1.3    Refreshment Message generation task

    In DCME frames when Priority0 Queue is not to be addressed and there are no
messages in queues 1 through 5, a Refreshment Message should be generated. A
Refreshment Message should also be generated when Priority3, 4 and 5 queue con-
tains a request(s) which cannot be serviced due to unavailable bearer capacity unless a
ôdisconnectö message is generated.

    The refreshment should be done by scanning the range of normal BCs (from BC
No.1 to the upper pool boundary) and the range of overload BCs (from BC No.64 to
the highest number permitted by the pool size). Pre-assigned BCs should not be
refreshed. Each dynamically assigned 64kbit/s connection should be refreshed but
only limited to the even-numbered BC (the next higher BC should not be refreshed).
Every other Refreshment Message should alternate between the normal and the over-
load range. In each range, the BCs should 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 should be inserted
in the ôASSIGNö message. The refreshment of Bit Bank BC should be transmitted
with IT No.250.

A.1.1.2.1.4    Map Update/Coder Selection

    The RAG stores information of two types:

a)    Process parameters, consisting of both numbers and indexed arrays. This
information is of static nature (derived from the configuration data);

b)    the Resource Map û this information is dynamically variable, identifies the
status of the BC, IT, IT type and ADPCM encoder connections.

    At initialization (caused by the MCH), the Resource Map should be set to a known
state (BCs, ITs and ADPCM encoders disconnected) and the process parameters should
be loaded into the RAG Process. The RAG should then generate the ôSeizescö and the
ôSeizebankö messages in order to provide the SBC process with the information neces-
sary for the allocation of pre-assigned channels and bit banks (associated with these
channels). The pre-assigned channel allocation (determined by the configuration data)
should be in accordance with the bearer structure requirements (º5.2).

    Immediately after initialization, the RAG Process should also generate the ôSet-Preö
message for the ENC Process. This message causes seizure of an ADPCM encoder for
a pre-assigned connection and the setting of the encoding mode to 8, 5, 4 or optionally
3, or 2-bit.

    The Map Update/Coder Selection Task performs the following actions as a result of
channel type changes and implementation of service requests:

a)    update the BC and IT connections, BC type and store the information in the
Resource Map;

b)    update the encoder connections and store the information in the Resource
Map;

c)    generate the output messages on signal paths 8, 13 and 16.

    The Resource Map can be represented with indexed arrays as follows:

a)    The Sat Array û This array, indexed by IT number, contains a BC number for
each IT entry, i.e., Sat(IT)=BC number. This array provides the IT-to-BC
association map. If the IT is associated to BC number 0 in the array, the IT is
disconnected.

b)    The IT Array û This array, indexed by BC number, contains an IT number for
each BC entry, i.e., IT(BC)=IT number. This array provides the BC-to-IT
association map. If the BC is associated to IT number0 in the array, the BC
is disconnected.

c)    The Type Array û This array, indexed by BC number, contains a BC type
identification for each entry, i.e., Type(BC)=BC type. The BC types are
those listed earlier in this section.

d)    The Cod Array û This array, indexed by IT number, contains the connected
encoder number for each IT entry, i.e., Cod(IT)=encoder number. When the
IT is connected to encoder number 0, the IT is disconnected.

    The BC, IT connections and the BC types should be updated in accordance with the
events occurring in the RAG Process in accordance with TablesA-4/G.763 and A-5/
G.763, respectively. The bit bank deletion should be in accordance with the criterion
specified in TableA-3/G.763. When the conditions for the deletion of a bit bank exist,
the highest numbered bit bank BC should be deleted by changing its type to ôDiscon-
nectedö. FigureA-6/G.763 provides examples of connection and BC type update (the
BC, IT connections are shown as points in the BC, IT cartesian coordinate plane).

    Whenever a new assignment of a previously disconnected IT is made (other than IT
No.250), an ADPCM encoder should be selected from the available encoders of the
ADPCM encoder pool and logged at the Cod Array for that IT entry. Whenever a re-
assignment of a previously connected IT is made, the encoder currently associated with
the IT should be maintained.

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

    Whenever an assignment request is serviced and the connection/BC type is updated,
the ôAssignö message (signals8, 13 and16) should be generated. The message format
is (BC, IT, type, encoder number). Only a subset of the BC types can appear in the
message namely: ôVoiceö, ôDataö, ôTransparentö, ôBankö, and ôDisconnectedö. If the
BC type is ôDisconnectedö, the encoder number identifies the ADPCM encoder con-
nected to the IT (and BC) prior to the disconnection.

    Whenever an implicit disconnection takes place, the action to be taken should be in
accordance with TableA-6/G.763.

    If an optional USM is being used, the MAP update/coder selection task should not be
performed in DCME frames 0, n, 2n, etc. (i.e., every nth DCME frame) of the DCME
multiframe.







Figure A-6/G.763 = 14 cm



A.1.1.2.1.5    Search-Transp Procedure

    The Search-Transp Procedure searches for capacity for the allocation of the
64kbit/s IT. The search should be limited to the normal BC range.

    The procedure should generate, as an output, 11 values for the 11 variables
defined in TableA-2/G.763 and illustrated in FigureA-7/G.763. It should also select
an ADPCM encoder number from the pool of available encoders. However, if IT is
connected, the currently used ADPCM encoder should be kept for the new connection.

    The procedure should select the bc, bc+1 pair using the priority scheme speci-
fied in TableA-7/G.763 in the normal BC range. The search should proceed from
Priority1 to Priority 10. There is a possibility that none of the 10 choices will be avail-
able. In this case, if the requesting IT is connected to a BC, the IT shall be discon-
nected. If the requesting IT is not connected, a refreshment message should be
generated.

Figure A-7/G.763 = 9.5 cm





    If bc (bc+1) contains the data IT nrv1 (nrv2), the bearer channel bcv1 (bcv2)
should be selected (in the normal BC range) for the re-assignment of nrv1 (nrv2) using
the following priorities:

Priority 1 û ôData-availö BC;

Priority 2 û ôDisconnectedö BC;

Priority 3 û ôVoice-availö BC;

Priority 4 û ôVoiceö BC.

    If the IT nrv3 (nrv4), occupying the selected BC, is of the voice type, the overload BC
bcv3 (bcv4) should be selected for re-assignment of nrv3 (nrv4).

    If bc (bc+1) contains the voice IT nrv1 (nrv2), the bearer channel bcv1 (bcv2) should
be selected for the re-assignment of nrv1 (nrv2), using the following priorities:

Priority 1 û ôDisconnectedö normal BC;

Priority 2 û ôVoice-availö or ôData-availö normal BC;

Priority 3 û ôDisconnectedö overload BC.

A.1.1.2.1.6    Search-Data Procedure

    The Search-Data Procedure searches for a BC for the allocation of a data IT.
The search should be limited to the normal BC range. The procedure should select a
BC using the following priority scheme:

Priority 1 û ôData-availö BC;

Priority 2 û ôDisconnectedö BC;

Priority 3 û ôVoice-availö BC;

Priority 4 û ôVoiceö BC.

    One of the four choices will be available.

    The procedures should select an encoder number (if IT is connected, use the current
encoder for selection) and should generate as an output, three values for the variables
defined below:

bc:    BC no. for allocation of the data IT;

nrv:    No. of the IT currently occupying bc;

bcv:    BC no. for re-allocation of nrv.

    Note that nrv=0 indicates a disconnected BC and bcv=0 indicates that a re-assign-
ment is not required.

A.1.1.2.1.7    Search-Voice Procedure

    The Search-Voice Procedure searches for a BC for the allocation of the voice IT.
The search should first scan the normal BC range and should attempt to select one of
these two types of BC based on the specified priority:

Priority 1 û ôDisconnectedö BC;

Priority 2 û ôVoice-availö or ôData-availö BC.

    If this search is unsuccessful, the overload BC range should be scanned from the lowest
BC to the highest permissible BC until a disconnected BC is found.

    The procedure should select an ADPCM encoder number and should generate, as an
output, two values for the two variables defined below:

bc:    BC no. for allocation of the voice IT;

nrv:    No. of the IT currently occupying bc.

    Note that nrv=0 indicates a disconnected BC.

A.1.1.2.2    BC Bit Map creation process

    The SBC Process input/output connection is shown in FigureA-4/G.763. The
SBC Process receives the messages in signal path 13 and generates the BC Bit Map
(signal path14) and the Mode Map (signal path15).

    One function of the SBC Process is to establish the association between the bits
of each ADPCM encoder output and the bits of the bearer frame (signal path14: BC
Bit Map). The SBC also determines the 4/3/optionally 2 bit mode of the ADPCM
encoders used for voice (signal path15: Mode Map).

    Inherent to the above two functions is the bit bank handling and the overload
channel creation. The bit bank handling consists of deriving the LSB of each channel
from one of the existing bit banks according to predetermined rules.

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

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

    The SBC Process maintains ten lists. 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 of type ôVoiceö, ôVoiceavailö or
ôDiscö that are within the normal BC range. Reception of messages on signal path13
may change the contents of the list. At initialization, this list contains all normal BC
numbers subject to DSI.

    Overload BC List û This list contains all BC numbers of type ôVoiceö that are in
the overload BC range. Reception of messages on signal path13 may change the con-
tents of this list. At initialization, this list contains no entries.

    Pre-assigned 40 List û This list contains all BC numbers that are pre-assigned as
40kbit/s channels. At initialization, this list contains no entries. The RAG process will
send information (ôSeizescö message) directly after initialization which brings the con-
tents of this list to its final state. After this has been done, the contents will not change.

    Pre-assigned 32 List û This list contains all BC numbers that are pre-assigned as
32kbit/s channels. It is treated in an analogous manner to the pre-assigned 40 list.

    Pre-assigned 24 List û This list contains all BC numbers that are pre-assigned as
24 kbit/s channels. It is treated in an analogous manner to the pre-assigned 40 list.

    Pre-assigned 16 List û This list contains all BC numbers that are pre-assigned as
16kbit/s channels. It is treated in an analogous manner to the pre-assigned 40 list.

    Pre-assigned 64 list û This list contains the even BC numbers that are pre-
assigned as 64kbit/s channels. It is treated in an analogous manner to the pre-assigned
40 list.

    Data list û This list contains all BC numbers of type ôDataö or ôData-availö.
Reception of messages on signal path 13 may change the contents of this list. At initial-
ization this list contains no entries.

    Bit Bank List û This list contains all BC numbers of type ôBankö. Reception of
messages on signal path 13 may change the contents of this list. At initialization, this
list contains no entries. The RAG Process will send information (ôSeizebankö mes-
sage) directly after initialization, which inserts the bank BCs for pre-assigned channels
into the list.

    Transplist û This list contains the even BC number of type ôTranspö. Reception
of messages on signal path 13 may change the contents of this list. At initialization, this
list contains no entries.

    The possible BC transitions between non-pre-assigned lists are illustrated in
FigureA-8/G.763. Note that for ôTransparentö BCs, only BC bc (the lower nibble) is
either put into the ôTransplistö or extracted from it. BCbc+1 (higher nibble) is
extracted from the voice list or data list at connection of the 64kbit/s call and inserted
back in the voicelist at disconnection. It is noted that a BC number appears only in one
list.

Figure A-8/G.763 = 14 cm



    FigureA-9/G.763 shows the BC transitions corresponding to the example cases a), b),
c) and d) shown in FigureA-6/G.763.

    The SBC Process also maintains the Coder Array. In this array, each index corresponds
to a possible BC number. The indexed item is the encoder number used by that BC. At
initialization, it contains all zeroes.

Figure A-9/G.763 = 14 cm



A.1.1.2.2.1    Bit bank handling

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

    A bit bank BC number is removed from the bank list at the reception of a
ôReleasescö message for that BC. The BC number should then be put back into the
voice list.

    At the occurrence of the trigger pulse, the bit position of the LSBs of the han-
dled data calls (pre-assigned 40 or DSI channels declared as data) should be generated
in the following way:

a)    LSB of BC number in pre-assigned 40 list position 1:

    MSB of BC number in bank list position 1;

b)    LSBs of BC numbers in pre-assigned 40 list positions 2 to 4:

    2nd, 3rd and 4th bits, respectively, at BC number in bank list position 1;

c)    LSB of BC number in pre-assigned 40 list position 5:

    MSB of BC number in bank list position 2.

    This procedure is followed until the BC numbers in the pre-assigned 40 list have been
handled, after which the BC numbers in the first position in the data list follows.

A.1.1.2.2.2    Overload channel creation

    When any of the signal path 13 message ôAssignö, ôReinsertö, or ôRemoveö is
received the voice list or overload list are updated and the associated list lengths Nv
(Voice list) and Nov (Overload list) computed. If Nov is 0, overload channel creation is
not required.

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

    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 ôAssignö message (see Note). Pv and Pov
represent voice and overload list positions. These positions are numbered from 0 to
Nv-1 and from 0 to Nov-1, respectively.

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

    At the occurrence of the trigger pulse, the BCs stored in the overload list at the first N4
locations (modulo Nov) starting from the list position Pov should be marked as 4-bit
channels. The remaining BCs of the overload list should be marked as 3-bit channels.

    The 4/3 bit mode of the first BC in the overload list should be checked to determine
whether it is 4 or 3-bit. If the mode is 3-bit, the BCs stored in the voice list at the first
three locations, starting from the list position, Pv, should be set to 3-bit mode. The fol-
lowing bit associations should be entered into the BC Bit Map:

a)    MSB of BC in overloadlist position 0

    LSB of BC in voicelist position Pv;

b)    2nd bit of BC in overloadlist position 0

    LSB of BC in voicelist position (Pv+1 modulo Nv);

c)    LSB of BC in overloadlist position 0

    LSB of BC in voicelist position (Pv+2 modulo Nv).

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

c)    3rd bit of BC in overload list position 0

    LSB of BC in voice list position (Pv+2 modulo Nv);

d)    LSB of BC in overload list position 0

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

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

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

Figure A-10/G.763 = 12.5 cm



    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 3bits
per sample shall be computed as follows:

    The number (n2) of bearer channels in the voicelist that will operate at 2-bits
per sample (i.e., these channels ôdonateö 2bits) 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 (see Note 1). Pv and
Pov represent voice and overload list positions. These positions are numbered 0 to Nv-
1 and from 0 to Nov-1, respectively.

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

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

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



Place in the sequence

Bit (see Note 2)

        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 bits of the overload channels shall be arranged in the following ordered
sequence:



Place in the
sequence

Bit (see Note 2)

        1st

MSB    of BC at position
0

2nd

2nd bit of BC at posi-
tion 0

3rd

LSB    of BC at position 0

4th

MSB    of BC at position
1

5th

2nd bit of BC at posi-
tion 1

6th

LSB     of BC at position
1, etc.


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

    Note2ûOne or more bits indicated below may not be available, in which case
the sequence is compacted upwards.

    The first bit, second bit, third bit, etc., of the voice list bit sequence shall be
associated with the corresponding bits of the overload bit sequence. This is
illustrated in Figure12/G.763. A particular example, for a pool of nine BCs,
from BC No.1 to BC No.9, is shown in Figure13/G.763.

A.1.1.2.2.3    Mode Map and BC Bit Map Update

    As a result of the overload channel creation, BCs in the voice and overload lists
are marked as either 4, 3 or optionally 2-bit channels. This information is stored in the
Mode Map, which is updated (or refreshed) once per DCME frame.

    The update (or refresh) of the ôMode Mapö message implies the generation of a
message intended for the ENC Process. This message should address all ADPCM
encoders connected to the BC numbers that are in existence within the voice list and
the overload list and give their associated mode (4, 3 or optionally 2). The BCs that are
disconnected will not have an ADPCM encoder number associated with their BC num-
bers in the Cod Array and should not be addressed within the ôMode Mapö message.

    The information contained in the SBC lists and array and the results of the Bit
Bank Handling and Overload Creation Procedures permit the generation of the ôBC Bit
Mapö. This map contains the bit association of all used BCs (ADPCM encoder outputs)
with all used bearer channels. This map is updated (or refreshed) once per DCME
frame.

    An update or refresh of the ôBC Bit Mapö message implies the generation of a
message intended for the BMI Process. This message should contain the bit association
of all used BCs (ADPCM encoder outputs) with all used bearer channels.

A.1.1.2.3    Bit Map Implementation Process

    The BMI Process input/output connection is shown in FigureA-4/G.763. This
process receives the ôBC Bit Mapö from the SBC Process (signal path 14) and delivers
it after a delay to the BC Bit Assignment Unit on signal path9. This output is referred
to as ôAddressmap for BCsö. The delay is such that the BC Bit Map is implemented at
the beginning of the DCME frame which occurs 3 frames after the start of the DCME
frame containing the applicable assignment message. Refer to FigureA-11/G.763.

    The BC Bit Assignment Unit uses the BC Bit Map to route the ADPCM
encoder unit output (BCs) to the appropriate bits in the bearer frame.

FIGURE A-11/G.763 = 5 cm



A.1.1.2.4    Encoder Unit Control Process

    The ENC Process input/output connection is shown in FigureA-4/G.763. At
initialization, the ENC Process received the ôSet-preö message (signal path16), which
allocates ADPCM encoders to pre-assigned channels and sets their modes to 8, 5, 4 or
optionally 3, or 2-bit. This process also receives the ôMode Mapö message from the
SBC Process (signal path15) and the ôAssign-encö and ôRelease-encö messages from
the RAG Process (signal path 16). It generates the ôSetcodö message on signal path7
for the Encoder Unit.

    The ENC Process should be considered associated with a single ADPCM
encoder so that conceptually, there are as many processes as there are ADPCM encod-
ers. In practical implementation, the process can be time-shared among ADPCM
encoders. The ENC Process sets the operating parameters of the ADPCM encoder to
which it is dedicated, based on the messages received. The ADPCM encoder operating
parameters indicate the BC and IT connection, the 8/5/4/3/optionally 2-bit mode, and
whether the ADPCM encoder needs resetting.

    Resetting will be required when the IT connection to an ADPCM encoder is
changed (the encoder must be reset before establishing a new connection).

    When the ôAssign-encö message is received, the ENC Process should determine
whether the ADPCM encoder number in the message is the same as the ADPCM
encoder number to which the process is dedicated (cod). If the number is different, no
action should be taken.

    If the ADPCM encoder number is the same as cod, the ADPCM encoder con-
nection should be set in accordance with the received BC type and IT numbers. If the
BC type is ôDisconnectedö, the encoder should be disconnected.

    Reception of the ôRelease-encö message should result in the same action as the
reception of the ôAssign-encö message, indicating a ôDisconnectedö BC type.

    The ADPCM encoder bit mode should be set to 8, 5, 4, optionally 3, or 2-bit in
accordance with the contents of the ôSet-preö message (8, 5, 4 or optionally 3 or 2-bit
pre-assigned channels), the ôAssign-encö message (5-bit for data, 8-bit for transparent
channels) or the ôMode Mapö (voice channels).

    The ôSetcodö message containing the encoder operating parameters is sent to
the Encoder Unit. Each ôSetcodö message is destination directed to an encoder (cod).
The message ôSetcodö (cod, IT, mode, reset) indicates the connection for the ADPCM
encoder as well as the 8/5/4/3/optionally 2-bit mode of operation and whether the
ADPCM encoder needs resetting. The message ôSetcodö (cod, 0, ...) indicates that the
ADPCM encoder must be disconnected.

    The ôSetcodö message for pre-assigned channels is sent immediately after ini-
tialization. The ôSetcodö message for DSI channels should be sent after the ADPCM
encoder parameters are set, such that the ADPCM encoder mode/connection is
switched at the beginning of the DCME frame which occurs 3frames after the start of
the DCME frame containing the applicable assignment message. Refer to FigureA-11/
G.763.

A.2    An example of a DCME receive unit structure

    An example of a DCME receive unit structure is shown in FigureA-12/G.763.
Compliance with this receive unit structure will permit the DCME receive unit func-
tion to be tested with INTELSAT IESS-501(Rev.2) compliant DCME test equipment
and software protocol references. This structure is based on a non-mandatory partition-
ing of functions and definition of signals.

FIGURE A-12/G.763 = 15.5 cm





    Some of the functional blocks in Figure A-12/G.763 are internal to the DCME
receive unit structure, while others are external but provide or receive required inter-
face signals. The represented structure shows a multidestination (MD) DCME, corre-
sponding with four origins. However, since the internal blocks in the figure are defined
on a single pool basis, the structure can also represent the case of a point-to-point con-
figuration receiving 1 pool. The blocks internal to the structure need to be duplicated or
shared between pools. The blocks that belong to the receive unit structure are:

a)    The Control Channel Message Decoder û This unit receives the control mes-
sage associated with the received pool and decodes it from the format speci-
fied in º11. This constitutes the input for the Receive Channel Processing
Function. The control message decoder also distributes control message
contents not pertaining to the Receive Channel Processing Function:

û    the encoded background noise level within the Synchronous Data Word is
provided to a separate unit for decoding and use in accordance with
º11.3.3.1;

û    the Asynchronous Data Word is provided to a separate unit for decoding
and use in accordance with º 11.3.3.2;

û    a channel check type indication within the Synchronous Data Word is pro-
vided to a separate unit for use in accordance with ºº11.3.3.1 and 10.

b)    The Receive Channel Processing (RCP) Function û This function consists of
an ensemble of interconnected processes. It receives an input from the
Assignment Message Decoder, provides outputs to blocks internal to the
Receive Unit Structure (Decoder Unit and BC Bit Assignment Unit) and
provides outputs to blocks which are external to the Receive Unit Structure.

c)    The BC Bit Assignment Unit û This unit is connected to the input of the
Decoder Unit (BCs). The BC Bit Assignment Unit derives the bits required
for each ADPCM decoder input from the correct bits of the received bearer
channel. The bit map for this association is provided by the RCP function.

d)    The Decoder Unit û This unit consists of a bank of ADPCM decoders which
can be connected to any allocated IT and to any BC of the pool. Each BC
can carry 8, 5, 4, 3, or optionally 2-bit samples or can be disconnected from
the ADPCM decoders. A sufficient number of ADPCM decoders must be
provided to ensure that freeze-out due to unavailability of ADPCM decoders
cannot occur.

    The ADPCM decoders can be set to an 8, 5, 4, 3, or optionally 2-bit mode of
operation and can be initialized to a known state. The IT and BC connection/
disconnection information for each ADPCM decoder, as well as the mode of
operation selection and the initialization signal are provided by the RCP
function.

    The blocks which are external to the Receive Unit Structure but which have signal
paths with the RCP are:

a)    Transmit Channel Processing Function û Information on the data connection
of received ITs is passed to the TCP function by the RCP.

b)    Transparent Circuit Handler û This process which is described in º 8 is
informed by the RCP that a 64kbit/s assignment or disconnection has been
performed for an IT.

c)    Map Change Handler û The Map Change Handler (MCH) is a process which
controls the configuration data for the DCME. At start-up, this process
issues signals making it possible to configure the system correctly. The same
is done at a map change instant. Refer to ºº15.1 and 15.6.

d)    Trigger Pulse Generator û This unit provides a periodic 2 ms timing reference
signal to the processes of the receive unit structure.

e)    User Signal Modual (optional) û This USM receives signalling state change
signals. The specification of the USM is at the users' option.

A.2.1    Receive Channel Processing Function

    The Receive Channel Processing Function interfaces with other elements of the
receive unit structure as shown in Figure A-12/G.763. The RCP function processes the
output of the Assignment Channel Decoder and takes consequent actions by providing
required information to the Decoder Unit, the BC Bit Assignment Unit, the Transparent
Circuit Handler and the Transmit Channel Processing Function. The RCP function
receives a reset signal from the Map Change Handler which terminates the processes at
the map change instant.

    The internal structure of the RCP as shown in Figure A-13/G.763 is comprised
of the Received Channel Status Update and Overload Decoding Process(RUD), the
Bit Map Implementation Process (BMI) and the Decoder Control Process (DEC).

A.2.1.1    The Receive Channel Status Update and Overload Decoding Process (RUD)

    The RUD Process is dedicated to one received pool. There will be (conceptu-
ally) as many processes as there are received pools. The RUD process analyses the
control channel message and generates the required actions based on the contents of
this message.

FIGURE A-13/G.763 = 9.5 cm



    The RUD input/output connections are shown in Figure A-13/G.763. The RUD
receives an input (signal path51) from the Assignment Channel Decoder and an input
(signal path 58) from the Map Change Handler. The contents of these signal paths are
defined below:

Signal Path 51:    This signal path carries the ôAssignö message which contains
assignment information obtained from the Assignment message
decoder. The message format is (BC, IT, Call). The last variable
defines the decoded BC type. The ôCallö variable can define three
BC types, ôVoiceö, ôDataö and ôTransparentö. Two additional BC
types, ôDisconnectedö and ôBankö are defined by the reception of
the IT No.0 and No.250, respectively.

Signal Path 58:    This signal path carries the ôProcess-resetö message. This mes-
sage is issued by the MCH in association with a map change. The
reception of this message causes the termination of the RUD Pro-
cess.

    The RUD Process generates outputs for the TCP Process (signal path 4), the DEC pro-
cess (signal path 54), BMI Process (signal path53) and the Transparent Circuit Han-
dler (signal path52). When required the RUD Process also generates a signal to the
optional USM. This signal (signal path220) contains the ôchange(IT)ö message. The
outputs are defined below:

Signal Path 4:        This signal path carries the following message ôRxdata(IT)ö. This
message is sent to the transmit unit assignment procedures when
the transition occurs from a previous BC type to a data BC (IT is
the transmit IT number).

Signal Path 52:    This signal path carries the following messages (IT is the trans-
mit IT number):

û    ôRxtranspreq(IT)öûThis message is given to the Transpar-
ent Circuit Handler when the transition occurs from another BC type
to a transparent BC type.

û    ôRxtransprel(IT)öûThis message is the reverse of the above. It is sent
when a transition occurs from a transparent BC to something else
(disconnection).

Signal Path 53:    This signal path carries the message ôBC Bit Mapö. This mes-
sage defines which bearer channel bits should be given to the differ-
ent ADPCM decoders.

Signal Path 54:    This signal path carries the following messages:

û    ôSeize (IT, Mode)öûThis message contains the local IT number and the
mode in which the ADPCM decoder should be set.

    This message is sent to the DEC Process immediately after initialization,
to establish the ADPCM decoder connections for pre-assigned
64kbit/s (transparent), 40kbit/s (data), 32kbit/s, 24kbit/s and
16kbit/s (option) calls. The decoder mode will be 8, 5, 4, 3 or
optionally 2-bit, respectively. The ôSeizeö message is also sent,
during the DCME operation, to establish decoder connections for
dynamically assigned data and transparent calls. The ADPCM
decoder mode will be 5-and 8-bit, respectively.

û    ôSeizev (IT)öûThis message is delivered in order to associate a dynam-
ically assigned voice channel with an ADPCM decoder. The same
parameter as in the signal above is given, with the exception of the
mode.

û    ôReleaseöûThis message is used to release a designated ADPCM
decoder back into the decoder pool.

û    ôMode MapöûThis message contains the modes that are to be used for
the different ADPCM decoders that are connected to voice chan-
nels.

    The RUD Process can be functionally divided into three tasks, namely the Input
Pre-Processing Task, the Map Update/Decoder Selection Task and the BC Bit Map
Creation Task (see Figure A-14/G.763).

FIGURE A-14/G.763 = 11.5 cm



    The Input Pre-Processing Task performs a validity check on the ôAssignö message and
derives the implicit BC types (determined by the BC number).

    The Map Update/Decoder Selection Task analyses the pre-processed ôAssignö mes-
sage, updates the internal maps of the RUD Process and generates messages on signal
paths 4, 52 and 54 (except the ôMode Mapö message).

    The BC Bit Map Creation Task performs the bit bank handling and overload channel
derivation functions and generates the BC Bit Map message on signal path 53 and the
ôMode Mapö message on signal path 54.

A.2.1.1.1    Input Pre-Processing Task

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

a)    if the BC is in the overload range, or if the IT number is 250, the MSB of the
BC Identification Word in the Assignment message must be 0 (ôVoiceö);

b)    if the BC type is transparent, the MSB of the BC Identification Word must be
0 (ôVoiceö) and the BC number must be even;

c)    the BC number must be contained in the range allocated to the received pool
(including overload channels) and not already used for a pre-assigned chan-
nel;

d)    the IT number must be contained in the range which the corresponding
DCME (transmit unit) can address for all destinations;

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

f)    if the optional USM is used, ôRxAMö messages of the form (BCnumber 255,
ITn) will be delivered in DCME frames 0, n, 2n, etc. (i.e. every nth DCME
frame) of the DCME multiframe.

    If any of the above conditions are not satisfied, or if the DCME frame alignment is lost,
no further processing of the assignment message shall be performed. The received IT
number shall be assumed to be 0 for the purpose of providing a pointer value for the
overload channel derivation (ºA.2.1.1.3).

    If the validity check is successful, the received assignment message should be pro-
cessed as follows:

a)    if the IT number is 0, the BC type should be set to ôDisconnectedö;

b)    if the IT number is 250, the IT number should be changed to 0 and the BC
type shall be set to ôBankö.

    The processed assignment message, referred to as ôRxAM(BC,IT,Rxtype)ö should
then be passed to the Map Update/Coder Selection Task for further processing.

A.2.1.1.2    Map Update/Decoder Selection Task

    The RUD stores information of two types:

a)    Process parameters, consisting of both numbers and indexed arraysûThis
information is of a static nature (derived from the configuration data).

b)    The Resource MapûThis information which is dynamically variable, identi-
fies the status of the BC/IT connection, BC type and ADPCM decoder con-
nections.

    At initialization (caused by the MCH), the Resource Map should be set to a known
state (BCs, ITs and ADPCM decoders disconnected) and the process parameters should
be loaded into the RUD Process. This includes the information necessary for the allo-
cation of pre-assigned channels and bit banks (associated with these channels). The
pre-assigned channel allocation (determined by the configuration data) should be in
accordance with the bearer structure requirements (º5.8). A map which identifies the
remote IT numbers intended for the DCME and associates them with the local IT num-
bers (making up the circuit), is included in the information loaded at initialization. The
local IT numbers are the numbers used by the DCME in its transmitted assignment
message. The remote IT numbers are those used in the received assignment mes-
sage(s).

    Immediately after initialization, the RUD Process should generate ôSeizeö messages to
the DEC Process. This will cause seizure of ADPCM decoders for pre-assigned con-
nections and the setting of the ADPCM decoding mode to 8, 5, 4, or optionally 3 or 2-
bit.

    The Map Update/Decoder Selection Task performs the following actions as a result of
the processing of the received assignment message (ôRxAMö):

a)    update and store the BC/IT connections and BC types in the Resource Map;

b)    select the decoder connections and store the information in the Resource
Map;

c)    generate the messages for signal paths 4, 52 and 54 (except the ôMode Mapö
message).

    The Resource Map can be represented with the four indexed arrays Sat, IT, Type and
Dec. The first three are identical to the arrays with the same name, defined in the trans-
mit unit structure (ºA.1.1.2.1.4). The BC types which can be stored in the Type Array
are ôTranspö, ôDataö, ôVoiceö, ôDiscö and ôBankö.

    The Dec Array, indexed by IT numbers, contains the connected ADPCM decoder num-
ber for each IT entry, i.e. Dec(IT)=ADPCM decoder number. When the IT is con-
nected to ADPCM decoder number 0, the IT is disconnected. The IT numbers used are
the local IT numbers.

    At the reception of the ôRxAMö message, the IT-to-BC connection should be logged in
Sat Array, the BC-to-IT connection should be logged in the IT Array and Rxtype
should be logged in the Type Array for the BC entry (the previously stored BC, IT con-
nection and the BC type will be updated). Additional changes to the information stored
in the IT, Sat and Type Arrays should be made as specified below.

a)    If the Receive Type is ôTransparentö, BC+1 should be disconnected in the IT
array if it is connected before (i.e.BC+1 connected to IT No.0) and the BC
Type Array entry for BC+1 should be logged as ôTranspö;

b)    if the connection of a BC changes to a different IT, the previously connected
IT, defined as ITp, should be disconnected in the Sat Array (i.e. ITp con-
nected to BC No.0). This is an implicit IT disconnect;

c)    if the connection of an IT changes to a different BC, the previously connected
BC should be disconnected in the IT Array and its type should be changed to
ôDiscö;

d)    if a BC of the transparent type changes to a different type, the other BC of the
transparent BC pair should be disconnected in the IT and Type Arrays. Its
associated IT should be disconnected in the Sat Array.

    If, as a result of the above actions, the conditions exist for the deletion of a bit bank (as
per TableA-3/G.763), the BC type ôBankö should be changed to ôDiscö.

    If the optional USM is used and the BC number 255 is received, the Map Update/
Decoder selection task should take no action. However, ITn should be used as a pointer
in the BC Bit Map Creation Task (refer to ºA.2.1.1.3).

    It should be noted that some of the connection/type changes are not strictly permissible
under the assignment rules specified in the DCME transmit unit structure. These transi-
tions, however, although abnormal, may occur at the DCME receive unit as a result of
loss of assignment messages. Note that the abnormal transitions are different from
erroneous assignment messages (rejected by the Input Pre-Processing Task).

    Another function of the task discussed in this section is the ADPCM decoder selection
(and consequent update of the Dec Array). The rules for the decoder selection should
be as follows:

a)    the ADPCM decoder selection should be performed only if the remote IT
number is destined forDCME;

b)    when a new assignment of a previously disconnected IT is made (this
includes the re-assignment from ôBankö type to other type), an ADPCM
decoder should be selected from the available decoders of the ADPCM
decoder pool;

c)    when a re-assignment of a previously connected IT to a different BC is made,
the ADPCM decoder currently associated with the IT should be maintained;

d)    whenever an IT connection changes to BC No. 0 (disconnection), the
ADPCM decoder associated with the IT should be released to the decoder
pool.

    The Map Update/Decoder Selection Task generates the output messages of signal path
54 (except the ôMode Mapö), signal path52 and signal path4. The rules for the gener-
ation of these messages should be as follows:

a)    The messages below should only be generated if the received remote IT num-
ber is destined for the DCME.

b)    When the IT connection changes to a different BC (not No. 0) and/or when
the BC type changes, the ôSeizeö message should be generated, if the BC
type is ôTransparentö or ôDataö. The ôSeizevö message should be generated,
if the BC type is ôVoiceö. In both cases, the BC, IT and the selected ADPCM
decoder number should be included in the message. The ADPCM decoder
mode (included in the ôSeizeö message) for ôTransparentö and ôDataö BC
types should be 8- and 5-bit, respectively.

c)    When an ADPCM decoder is released to the decoder pool, the ôReleaseö mes-
sage should be generated for that ADPCM decoder.

d)    The ôRxdataö message should be generated only when a transition occurs
from a BC type other than ôdataö to ôdataö.

e)    The ôRxtranspreqö message should be generated when the transition occurs
from another BC type to ôtransparentö.

f)    The ôRxtransprelö message should be generated when the transition occurs
from a transparent BC type to a different type.

A.2.1.1.3    BC Bit Map Creation Task

    This task performs two actions:

a)    derivation of the 5th bit of each data channel (from the bit banks),

b)    derivation of the overload BCs from the bearer BCs.

    As an output, these tasks generate the ôBC Bit Mapö and the ôMode Mapö messages.

    The type of each BC is stored in the RUD maps and updated when required. Function-
ally, this Task rearranges the pre-assigned data BCs, the ôVoiceö and ôDiscö BCs (nor-
mal range), the DSI ôDataö BCs and the connected overload BCs into the pre-assigned
40kbit/s list, the voice list, the data list and the overload list, respectively. These lists
are the same as those defined for the SBC Process (ºA.1.1.2.2). In the SDL representa-
tion in ºA.3 of the RUD process, lists other than voice lists and overload list are
assumed to be generated from the Type Array.

    The rules for insertion of the BCs into the various lists and deletion from the lists shall
be the same as those defined for the SBC Process. The rules for bit bank handling,
overload channel derivation and map update (Mode Map and BC Bit Map) shall also
be the same.

    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, the affected channels shall
receive dummy bits set to 0;

3)    the variables N4 or N3 (number of 4-bit or 3-bit overload channels) shall be
set to 0 if its calculated value is negative.

A.2.1.2    Bit Map Implementation Process (BMI)

    The BMI Process input/output connections are shown in Figure A-13/G.763.
This process receives the BC Bit Map (signal path 53) from the RUD Process, the
ôProcess-resetö signal (signal path 59) from the MCH Handler and a ôtriggerö pulse
(signal path60) which indicates that the process output message should be delivered to
the hardware.

    The function of the BMI Process is to delay the incoming BC Bit Map message
before sending the delayed contents in the ôAddressmap for BCsö message. The delay
is such that the BC Bit Map is implemented at the beginning of the DCME frame
which occurs three frames after the start of the DCME frame containing the applicable
assignment message. Refer to Figure A-11/G.763.

    The ôAddressmap for BCsö message (signal path 57) contains the exact bit
association required to connect the appropriate bits of the bearer BCs to each ADPCM
decoder.

A.2.1.3    Decoder Control Process (DEC)

    The DEC Process input/output connections are shown in FigureA-13/G.763.
The process receives ôSeizeö, ôSeizevö, ôReleaseö and ôMode Mapö messages (signal
path54) from the RUD Process, the ôProcess-resetö message (signal path 61) from the
Map Change Handler and the ôTriggerö message (signal path 55). It generates the ôSet-
codö message (signal path 56) for the Decoder Unit.

    At initialization, the DEC Process should receive ôSeizeö message for 8, 5, 4 or
optionally 3 or 2-bit pre-assigned channels from the RUD Process. This message allo-
cates ADPCM decoders to pre-assigned channels, indicating the connection to the IT
and the ADPCM decoder mode.

    The DEC Process is assumed to be associated with each ADPCM decoder of the
decoder unit so that conceptually, there are as many processes as there are ADPCM
decoders. In practical implementations, one process can be time-shared among
ADPCM decoders.

    The DEC Process sets the operating parameters of the ADPCM decoder to
which it is dedicated, based on the messages received. The ADPCM decoder operating
parameters indicate the IT connection, the 8, 5, 4, 3 or optionally 2-bit mode and
whether the ADPCM decoder needs resetting. Resetting shall be performed when the
IT connection to an ADPCM decoder is changed (the decoder must be reset before
establishing a new connection).

    When the ôSeizeö or ôSeizevö message is received, the DEC Process should
determine whether the ADPCM decoder number in the message is the same as the
ADPCM decoder number to which the process is dedicated. If the number is different,
no action should be taken. If the number is the same, the ADPCM decoder parameters
should be set in accordance with the IT number and mode (only for the ôSeizeö mes-
sage).

    The BC Mode Map (signal path 54) received from the RUD Process should be
scanned to determine the 4, 3 or optionally 2-bit mode of the ADPCM decoders con-
nected to voice BCs.

    Reception of the ôReleaseö message for an ADPCM decoder should cause the
decoder to be designated as disconnected.

    The ADPCM decoder operating parameters, established by the DEC Process,
should be sent to the Decoder Unit via the ôSetcodö message. Each ôSetcodö message
(signal path 56) is destination directed to an ADPCM decoder (decode). The message
ôSetcodö (decode, IT, mode, reset) indicates the IT connection for the ADPCM
decoder as well as the 8, 5, 4, 3, or optionally 2-bit mode of operation and whether the
ADPCM decoder needs resetting. The message ôSetcodö (decode,0,etc.) indicates
that the ADPCM decoder must be disconnected.

    The ôSetcodö message for pre-assigned channels should be sent immediately
after initialization. The ôSetcodö message for DSI channels should be sent such that the
ADPCM decoder connection/mode is switched at the beginning of the DCME frame
which occurs three frames after the start of the DCME frame containing the applicable
Assignment message. Refer to Figure A-11/G.763.