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 Figure A-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 Figure A-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 S 12.1.

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

c)	2400 Hz Tone Detector ù This block provides a detection indication when the 2400 Hz signalling tone is present. The specification for this block is provided in Annex B.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 Assignment 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 2 bits per PCM sampling cycle or can be disconnected from the coders.

The encoders can be set to 8/5/4/3/optionally 2 bit mode of operation and can be initialized to a known state. The IT and BC connection/disconnection information 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 association, and the channel type (data/speech, or 64 kbit/s) into the format specified in S 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 Figure A-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 64 kbit/s channel or sends a message releasing the channel. The Transparent Circuit Handler Process is specified in S 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 SS 15.1 and 15.6.

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

e)	User Signalling Module (Optional) ù This user signalling module (USM) generates 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 identify 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

include 02-t01-eTABLE A-1/G.763

Legend for transmit unit signal paths

Signal path No.

Signal type/message

Definition

1

"Act", "Inact"

S A.1.1.1.1

2

"Data-detect", "Voice-detect"

S A.1.1.1.1

3

"Signaldetect"

S A.1.1.1.1

4

"Rxdata"

S A.1.1.1.1

5

"Transpreq", "Transprel"

S A.1.1.1.1

6 (and 21, 22, 24, 26)

Process-Reset from MCH

S A.1.1.1.1

7

"Setcod"

S A.1.1.2.4

8

"Assign"

S A.1.1.2.1

9

"Addressmap-for-BCs"

S A.1.1.2.3

10, 11

Not used

12

"Voice", "Voiceinact", "Data", "Datainact", "Transp", "Discreq"

S A.1.1.1.1

13

"Assign", "Reinsert", "Remove", "Seizesc", "Seizebank", "Releasesc", "Release"

S A.1.1.2.1

14

"BC Bit Map"

S A.1.1.2.2

15

"Mode Map"

S A.1.1.2.2

16

"Assign-enc", "Release-enc", "Set-pre"

S A.1.1.2.1

17

"Resetact", "Resetsignaldetect", "Default-Voice", "Default-Data"

S A.1.1.1.1

18

No used

19

Trigger Pulse, Sync Trigger Pulse

S A.1.1.2.1

20, 23, 25

Trigger Pulse

200

Change

S A.1.1.2.1

A.1.1	Transmit Channel Processing Function

The Transmit Channel Processing Function (TCP) interfaces with the other elements of the transmit Side Structure as shown in Figure A-1/G.763. Each interface signal is identified in Figure A-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 Figure A-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 Figure A-2/G.763. The IPS Block processes the TCP inputs (signal path 1 through 6) and generates IT status transition information (signal path 12) 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 2400 Hz 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 Figure A-3/G.763. This block performs 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 Figure A-3/G.763. The HSC Process 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 path 17) the detectors and discriminator. The process-reset signal from the MCH (signal path 6) terminates the HSC Process at a map change instant. The above signal paths carry the following messages:

ù	Signal Path 1:	Activity detected ("Act"), Inactivity detected ("Inact").

ù	Signal Path 2:	Data Detected ("Data-detect"), Speech detected ("Voice-detect").

ù	Signal Path 3:	2400 Hz 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 2400 Hz 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 specified below.

a)	Initially, this process should declare an IT either "pre-assigned", if so designated 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" message 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" message is received from the Data/Speech Discriminator, the IT should be classified as "Data-active". The same applies to the case of reception of "Rxdata" from the DCME receive unit as long as the 1 s 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 1 s 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 1 s 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 1 s delay timer should be started and the IT should be classified as "Voice-active-hold".

If the 1 s 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 message "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 1 s delay timer should be started and the IT should be classified as "Signalling-active-hold".

If the 1 s 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 14 s. 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 14 s, but it is expected that in most cases, it will be set to a value significantly shorter than the initial data hangover. This permits higher efficiency of utilization of the return link for facsimile 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 Hangover values should be in accordance with the hangover masks specified in S 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 initialization (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 Figure A-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 path 7) and the BC Bit Map for the BC Bit Assignment Unit (signal path 9).

The internal structure of the SRH Block is shown in Figure A-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 Figure A-5/G.763. The RAG Process also receives an input signal (signal path 21) from the MCH, which resets the process at the map change instant. It also receives a trigger pulse (signal path 19). 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 path 200) 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 path 13. 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 message structure (specified

in S 11.1). In the DCME frames which are used by the optional USM, the BC number should be 255, type data and encoder number 0.

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

"Assign" ù This is the same message as in signal path 8.

"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 S A.1.1.2.2).

"Remove (BC)" ù It removes an implicitly disconnected overload channel from the SBC overload BC list (see S A.1.1.2.2).

"Seizesc (BC, encoder no., enc. mode)" ù It generates a fixed association between a BC number and an ADPCM encoder number, for a pre-assigned channel in the SBC Process (see S A.1.1.2.2). The ADPCM encoder mode could be 8/5/4/or optionally 3 or 2 bits 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 S A.1.1.2.2). It is transmitted immediately after initialization.

"Releasesc (BC)" ù This message releases a bit bank connection and is given to the SBC process (see S A.1.1.2.2).

"Release (enc. no.)" ù This message updates the ADPCM encoder map within the SBC process (see S 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 connection 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 Figure A-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 transition 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)" message;

b)	Priority 1 Queue ù It stores the 64 kbit/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 64 kbit/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 Priority 2 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 Priority 5 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 Priority 4 queue.

When a "Transp(IT)" message is received, a request should be stored in the Priority 3 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 queues 2 to 5 and should be maintained if in Priority queue 1. If the stored request is in Priority queue 1 and the new request is also for Priority queue 1, the new request should be deleted. A message for Priority 0 queue should be stored in Priority 0 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 64 kbit/s or data assignments in progress, the Priority 1 Queue should be addressed. If the message count for this queue is one or more, the RAG Process should address the first request in the queue (first in, first-out order) and delete it when serviced. If the message count is 0, 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 Priority 1 Queue. 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 S 11). In the case where the optional USM is not used, the Priority 0 Queue should not be addressed. In the case where the USM is used, the Priority 0 Queue should be addressed in DCME frames 0, n, 2n, etc. (i.e., every nth frame), of the DCME multiframe where n is a variable which may be selected by the user. Priority 1 through 5 queues should be addressed in the remaining DCME frames.

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

b)	Discreq Requests ù The request at the top of Priority 1 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 Priority 2 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 Priority 3 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 Priority 1 Queue again at the next occurrence of the trigger pulse.

If the IT is connected and enough capacity exists to accommodate the additional bits, the BC number of the connected bearer channel (number k) 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 (number k-1) should be examined. The objective is to allocate the first nibble (containing the MSB) of the 64 kbit/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 SDisconnected", "Data-available" or "Voice-available", the 64 kbit/s IT should be assigned to BC k (and by implication, to BC k+1). If the type of BC k+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 (S A.1.1.2.1.6) or the Search-Voice Procedure (S A.1.1.2.1.7), respectively. If the type of BC k+1 is either "Bank" or "Pre-assigned", or if BC k+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 examined 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 (8 bits are required). If the request can be accommodated, the Search-Transparent Procedure should be invoked. If the request cannot be accommodated, a Refreshment Message (S A.1.1.2.1.3) should be generated.

The Search-Transparent Procedure is invoked (S 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 S A.1.1.2.1.4 for the encoder selection) and the values for 11 variables (see Table A-2/G.763). These variables consist of the two bearer channels (bc and bc+1) selected for allocation of the 64 kbit/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.

include 02-t02-eTABLE A-2/G.763

Search-Transparent Procedure Variables

nr:

No. of IT requesting a 64 kbit/s transparent channel

cd:

Selected ADPCM encoder No. for the request

bc:

BC No. for allocation of the 1st nibble of the 64 kbit/s IT

bc+1:

BC No. for allocation of the 2nd nibble of the 64 kbit/s IT

nrv1:

No. of the IT currently occupying bc

nrv2:

No. of the IT currently occupying bc+1

bcv1:

BC No. for re-assignment of nrv1

bcv2:

BC No. for re-assignmnent of nrv2

nrv3:

No. of the IT currently occupying bcv1

nrv4:

No. of the IT currently occupying bcv2

bcv3:

BC No. for re-assignment of nrv3

bcv4:

BC No. for re-assignment of nrv4

Success

Result of the search (TRUE or FALSE)

Note 1 ù nrv1, nrv2, nrv3, nrv4 = 0 indicates that IT re-assign/disconnect is not necessary.

Note 2 ù bcv1, bcv2, bcv3, bcv4 = 0 indicates that these BCs are not required for reassignment.

Note 3 ù bcv3 and bcv4 are overload BCs.

Note 4 ù bc is an even number.

Note 5 ù The first nibble of the 64 kbit/s IT contains the MSB.

Note 6 ù The variable nr is the only input variable.

Note 7 ù bc+1 is derived from the variable bc.

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/disconnection 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 examined.

Equivalent steps should be implemented for nrv3 and nrv2.

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

At implementation, the service request should be deleted from Priority 3 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 4 bits referred to as the bit bank. Special 4-bit BC channels of the "Bank" type are created in the bearer frame for this purpose. The criteria for creation of bank channels are specified in Table A-3/G.763.

include 02-t03-eTABLE A-3/G.763

Criteria for bank creation/deletion

Creation of bit bank (at new data channel assignment)

Yes

Bank not required

"Data-avail" BC present?

No

Bank required if

eq nb < \f(nd,4)

Deletion of bit bank (see Note)

eq nb \f(nd,4) + 1

Delete highest numbered bank

Note ù If bank was just created, wait 2 DCME frames before applying deletion criterion. If during the 2 DCME frame wait period a USM signalling message is sent, wait one additional DCME frame.

nd:	Number of data channels in use and requested (pre-assigned and DSI).

nd:	Number of banks in use.

The request at the top of the Priority 4 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 (specified later).

If sufficient capacity is not available and the IT is connected, a disconnect message 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 sufficient 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 (S 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 S A.1.1.2.1.4 for the ADPCM encoder selection) and three values for the three variables defined in S 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 channel bc.

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 Priority 4 Queue.

f)	Voice Requests ù The request at the top of Priority 5 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 determine whether enough capacity exists to accommodate the voice call. If sufficient 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 S A.1.1.2.1.4 for the ADPCM encoder selection) and the values of the variables nrv and bc, defined in S 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) disconnected and the voice IT should be assigned to bearer channel bc.

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

g)	The Search-Transp Procedure, Search-Data Procedure and Search-Voice Procedure 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 Priority 0 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 Priority 3, 4 and 5 queue contains 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 64 kbit/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 overload 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 necessary 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 (S 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 number 0 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 Tables A-4/G.763 and A-5/G.763, respectively. The bit bank deletion should be in accordance with the criterion specified in Table A-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 "Disconnected". Figure A-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 (signals 8, 13 and 16) 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 connected 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 Table A-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.

include 02-t04-eTABLE A-4/G.763

BC, IT connection update

Event

(RAG Process)

IT Array

Entry for BC

BC Array

Entry for IT

IT Array

Entry for BC+1

Assign IT to BC

(other than 64 kbit/s

IT

BC

No change

Direct Action

Disc. IT from BC

(other than 64 kbit/s)

0

0

No change

Assign IT to BC

(64 kbit/s)

IT

BC

0

Disc. IT from BC

(64 kbit/s)

0

0

0

Assign a "Bank" BC

0

No change

No change

Implied Disconnect

Assign ITn to BC

connected to IT

ITn

0

No change

Re-assignment of IT

from BC to BCn

0

BCn

No change

Note ù BC-to-IT No. 0 connection means disconnection of BC. IT-to-BC No. 0 connection means disconnection of IT.

include 02-t05-eTABLE A-5/G.763

BC type update

Event

(RAG Process)

BC Type

BC+1 Type

Message received:

As determined by Input Pre Processing Task

No change

"Datainact (IT)"

"Voiceinact (IT)"

"Data (IT)"

"Voice (IT)"

Assign Voice IT to BC

Voice

No change

Assign Data IT to BC

Data

No change

Assign Bit Bank to BC

Bank

No change

BC disconnection/bank deletion

Disconnected

No change

Assign 64 kbit/s IT to BC

Transparent

Transparent

Disc. 64 kbit/s IT from BC

Disconnected

Disconneted

include 02-t06-eTABLE A-6/G.763

Actions caused by implicit disconnections

Implicit Disconnect

Action

"Data" BC

Generate "Reinsert (BC)" message

Overload BC

Generate "Remove (BC)" message

"Bank" BC

Generate "Releasesc (BC)" message

IT

Generate "Release (ADPCM encoder number)" message

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 64 kbit/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 Table A-2/G.763 and illustrated in Figure A-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 specified in Table A-7/G.763 in the normal BC range. The search should proceed from Priority 1 to Priority 10. There is a possibility that none of the 10 choices will be available. In this case, if the requesting IT is connected to a BC, the IT shall be disconnected. If the requesting IT is not connected, a refreshment message should be generated.

Figure A-7/G.763 = 9.5 cm

include 02-t07-eTABLE 7/G.763

Priority scheme for search-transp procedure

Priority

BC Types

1

disc/disc

2

avail/disc

disc/avail

3

avail/avail

4

voice/disc

disc/voice

5

voice/avail

avail/voice

6

voice/voice

7

data/disc

disc/data

8

avail/data

data/avail

9

data/voice

voice/data

10

data/data

priority

voice/avail

Disc	BC disconnected.

BC types	types of candidate pair BCs (bc and bc+1).

Avail	BC available/either "Voice-avail" or "Data-avail".

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-assignment 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 Figure A-4/G.763. The SBC Process receives the messages in signal path 13 and generates the BC Bit Map (signal path 14) and the Mode Map (signal path 15).

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 path 14: BC Bit Map). The SBC also determines the 4/3/optionally 2 bit mode of the ADPCM encoders used for voice (signal path 15: 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 3 bit per sample encoding is distributed 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-random fashion and by making each overload BC alternate between 4 and 3 bit encoding (also in a pseudo-random fashion).

When the 4/3 bit overload channel creation procedure, described above, cannot provide the required number of overload channels, the optional 3/2 bit overload channel creation procedure may be used. This procedure, similarly to the 4/3 bit procedure, makes the average ADPCM encoding rate almost equal for the normal voice BCs (subject to bit stealing) and the overload channels. Pseudo-random bit rotation and switching between two alternate overload channel sizes (3-bit and 2-bit channels) are 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 path 13 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 path 13 may change the contents 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 40 kbit/s channels. At initialization, this list contains no entries. The RAG process will send information ("Seizesc" message) directly after initialization which brings the contents 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 32 kbit/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 16 kbit/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 64 kbit/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 initialization 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" message) 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 Figure A-8/G.763. Note that for "Transparent" BCs, only BC bc (the lower nibble) is either put into the "Transplist" or extracted from it. BC bc+1 (higher nibble) is extracted from the voice list or data list at connection of the 64 kbit/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

Figure A-9/G.763 shows the BC transitions corresponding to the example cases a), b), c) and d) shown in Figure A-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 handled 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:

include 02-fo-e F001	eq N4 = Integer \b\bc\[( \f(Nv 4 Nov,Nv + Nov) + \f(1,2)) ù Nov 3

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

Pv = (IT modulo Nv)

Pov = (IT modulo Nov)

where IT is the IT number contained in the "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 following 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, items a) and b) above remain applicable, c) changes and d) 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 Figure A-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 3 bits per sample shall be computed as follows:

include 02-fo-e f002	eq N3 = Integer \b\bc\[( \f(Nv 4 Nov,Nv + Nov) + \f(1,2)) ù Nov 2

The number (n2) of bearer channels in the voicelist that will operate at 2-bits per sample (i.e., these channels "donate" 2 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 (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 position 0

3rd

LSB	of BC at position 0

4th

MSB	of BC at position 1

5th

2nd bit of BC at position 1

6th

LSB	of BC at position 1, etc.

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

Note 2 ù 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 Figure 12/G.763. A particular example, for a pool of nine BCs, from BC No. 1 to BC No. 9, is shown in Figure 13/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 numbers 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 Figure A-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 path 9. 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 Figure A-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 Figure A-4/G.763. At initialization, the ENC Process received the "Set-pre" message (signal path 16), 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 path 15) and the "Assign-enc" and "Release-enc" messages from the RAG Process (signal path 16). It generates the "Setcod" message on signal path 7 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 encoders. 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 connection 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 initialization. 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 3 frames after the start of the DCME frame containing the applicable assignment message. Refer to Figure A-11/G.763.

A.2	An example of a DCME receive unit structure

An example of a DCME receive unit structure is shown in Figure A-12/G.763. Compliance with this receive unit structure will permit the DCME receive unit 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.

FIGURE A-12/G.763 = 15.5 cm

include 02-t08-eTABLE A-8/G.763

Legend for Receive Unit Signal Paths

Signal path No.

Signal type/message

Definition

4

"Rxdata"

S A.2.1.1

51

"Assign"

S A.2.1.1

52

"Rxtranspreq", "Rxtransprel"

S A.2.1.1

53

"BC Bit Map"

S A.2.1.1

54

"Seize", "Seizev", "Release", "Mode Map"

S A.2.1.1

55 (and 56)

"Trigger Pulse" from external unit

S A.2.1.1

56

"Setcod"

S A.2.1.3

57

"Addressmap for BCs"

S A.2.1.2

58 (and 59, 61)

"Process-reset" from MCM

S A.2.1.1

220

"Change" to MSU

S A.2.1.1

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 interface signals. The represented structure shows a multidestination (MD) DCME, corresponding 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 configuration 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 message associated with the received pool and decodes it from the format specified in S 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 S 11.3.3.1;

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

ù	a channel check type indication within the Synchronous Data Word is provided to a separate unit for use in accordance with SS 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 S 8 is informed by the RCP that a 64 kbit/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 SS 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 (conceptually) 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 path 51) 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 message is issued by the MCH in association with a map change. The reception of this message causes the termination of the RUD Process.

The RUD Process generates outputs for the TCP Process (signal path 4), the DEC process (signal path 54), BMI Process (signal path 53) and the Transparent Circuit Handler (signal path 52). When required the RUD Process also generates a signal to the optional USM. This signal (signal path 220) 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 transmit IT number):

ù	"Rxtranspreq(IT)" W This message is given to the Transparent Circuit Handler when the transition occurs from another BC type to a transparent BC type.

ù	"Rxtransprel(IT)" W 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 message defines which bearer channel bits should be given to the different ADPCM decoders.

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

ù	"Seize (IT, Mode)" W 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 64 kbit/s (transparent), 40 kbit/s (data), 32 kbit/s, 24 kbit/s and 16 kbit/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)" W This message is delivered in order to associate a dynamically assigned voice channel with an ADPCM decoder. The same parameter as in the signal above is given, with the exception of the mode.

ù	"Release" W This message is used to release a designated ADPCM decoder back into the decoder pool.

ù	"Mode Map" W This message contains the modes that are to be used for the different ADPCM decoders that are connected to voice channels.

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" message, 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 channel;

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 is 250;

f)	if the optional USM is used, "RxAM" messages of the form (BC number 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 (S A.2.1.1.3).

If the validity check is successful, the received assignment message should be processed 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, identifies the status of the BC/IT connection, BC type and ADPCM decoder connections.

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 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 (S 5.8). 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 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 message(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 connections 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 transmit unit structure (S 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 number for each IT entry, i.e. Dec(IT) = ADPCM decoder number. When the IT is connected 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 connection 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 connected 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 Table A-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 S 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 transitions, 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 for DCME;

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 path 52 and signal path 4. The rules for the generation of these messages should be as follows:

a)	The messages below should only be generated if the received remote IT number 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" message 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. Functionally, this Task rearranges the pre-assigned data BCs, the "Voice" and "Disc" BCs (normal range), the DSI "Data" BCs and the connected overload BCs into the pre-assigned 40 kbit/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 (S A.1.1.2.2). In the SDL representation in S 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 path 60) 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 Figure A-13/G.763. The process receives "Seize", "Seizev", "Release" and "Mode Map" messages (signal path 54) 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 "Setcod" 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 allocates 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" message).

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 connected 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.