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.