4 Procedures

08.603GPPIn-band control of remote transcoders and rate adaptors for Enhanced Full Rate (EFR) and full rate traffic channelsTS

4.1 Remote Control of Transcoders and Rate Adaptors

When the transcoder is positioned remote to the BTS, the Channel Codec Unit (CCU) in the BTS has to control some of the functions in the remote Transcoder/Rate Adaptor Unit (TRAU) in the BSC.

This remote control is performed by inband signalling carried by the control bits (C-bits) in each TRAU frame.

The following functions in the TRAU are remotely controlled by the CCU:

– Shift between speech and data.

– Control of the rate adaption functions for data calls.

– Downlink frame timing for speech frames.

– Transfer of DTX information.

In addition, the following functions are provided in case of AMR speech:

– Control of Codec Mode adaptation

– Transfer of TFO Configuration Parameters (optional, see GSM 08.62)

– Downlink Phase Alignment (optional)

– Transfer of Information on TFO Status (optional, see GSM 08.62)

– Transfer of Information on Pre-Handover Warning (optional)

In addition, the inband signalling also provides means for transfer of O&M signals between the TRAU and the BSC/BTS.

4.2 Resource Allocation

At reception of the ASSIGNMENT REQUEST message, e.g. at call setup, when a circuit switched connection is required, the BSC provides an appropriate TRAU to the circuit to be used between the BSC and the BTS and sends the CHANNEL ACTIVATION message to the BTS.

When receiving the CHANnel ACTIVation message, the BTS allocates the appropriate radio resources and a Channel Codec Unit (CCU) to be used.

In case of FR and EFR Speech or Data (except 14.5 kbit/s):

– The CCU now starts sending uplink frames with the appropriate "Frame Type" and, for data calls, the intermediate rate adaption bit rate set.

– When receiving the first frame, the TRAU sets the mode of operation accordingly and starts sending downlink frames with the "Frame Type" and, for data calls, the intermediate rate adaption bit rate set as an acknowledgement indication.

In case of Adaptive Multi-Rate speech: see clause 4.6.1.3.

In case of Data 14.5 kbit/s:

– The CCU starts sending uplink Data TRAU Frames with the appropriate "Frame Type" set to establish initial synchronization.

– When receiving the first frame, the TRAU sets the mode of operation accordingly and as an acknowledgement starts sending downlink Data TRAU Frames with the same "Frame Type".

– The CCU starts sending uplink Extended Data TRAU Frames with the appropriate "Frame Type" set upon reception of that acknowledge indication.

– When receiving the first frame, when the "Frame Type" is set to Extended Data TRAU frame, the TRAU sets the mode of operation accordingly and as an acknowledgement starts sending downlink Extended Data TRAU frames with the same "Frame Type".

4.3 Resource Release

At release of circuit switched resources, e.g. at call release, the connection between the CCU and the TRAU will be released by the BSC. The BSC has to indicate that the connection has been released. How this is performed is a BSC internal matter. However, three methods have been identified.

i) The BSC indicates the call release to the TRAU by inserting the PCM idle bit pattern described in GSM 08.54 on the circuits towards the TRAU. The TRAU shall be able to detect this idle bit pattern. When received at the TRAU, the TRAU will loose frame synchronization and will start timer Tsync (see clause 4.8.2). If, when Tsync expires, the idle bit pattern has been detected, the TRAU shall terminate the operation (go idle) until a valid frame is again received.

ii) This second alternative does not apply to Enhanced Full Rate Speech, Adaptive Multi-Rate speech and Data 14.5 kbit/s cases.

After a call release, the TRAU downlink channel is switched to the TRAU uplink channel (16 kbit/s side).

The TRAU shall be able to detect the looped downlink frame. When it is detected, the TRAU shall terminate the normal operation (go idle) until a valid uplink TRAU frame is again received.

iii) It is handled by BSC internal signals (e.g. if the BSC and TRAU are collocated).

4.4 In Call Modification

If the subscriber orders "In Call Modification", the CCU sets the "Frame Type" and, for data calls, the inter mediate rate adaption bit rate in the uplink frames to the new mode of operation. When receiving this information, the TRAU changes the mode of operation accordingly and sets the new "Frame Type" and, for data calls, the intermediate rate adaption bit rate in the downlink frames. The same procedure applies for mode change between Data 14,5 kbit/s.

In case of mode change to data 14,5 kbit/s from Speech or Data (other than 14.5 kbit/s) the same procedure as for "Resource Allocation" is performed.

In case of mode change from any other speech or data service to AMR speech, the same procedure as for "Resource Allocation" shall be performed. In case of mode change within AMR speech, i.e. a change of the AMR Configuration, the BSC should take care that a smooth transition from the old AMR configuration into the new one is performed, see GSM 05.09 and GSM 08.62.

4.5 Transfer of Idle Frames, Handling of Missing Data

Between the TRAU and the CCU a TRAU frame shall be transferred every 20 ms.

4.5.1 In Full Rate data case

If no data is received from the MS (uplink direction) or no data is received from the MSC side of the interface (downlink direction), idle data frames shall be transferred instead of data frames. Idle data frames are data frames with all data bit positions set to binary "1". In addition, for data 14,5 kbit/s; the C6 bit shall be set to ‘1’ in the uplink extended data frame. For each idle frame sent downlink for data 14.5 kbit/s the C7 bit is set to ‘1’.

4.5.2 In Full Rate speech case

If no speech is received from the MS (uplink direction), the CCU shall send TRAU speech frames with BFI flag set to 1 (bad frame) or idle speech frames.If no speech is received from the MSC side of the interface (downlink direction), idle speech frames shall be transferred instead of speech frames.

4.5.3 In Enhanced Full Rate speech case

If no speech is received from the MS (uplink direction), the CCU shall send TRAU speech frames with BFI flag set to 1 (bad frame). If no speech is received from the MSC side of the interface (downlink direction), idle speech frames shall be transferred instead of speech frames.

4.5.4 In Adaptive Multi-Rate speech case

If no speech is received from the MS (uplink direction), or a speech frame is stolen on the radio interface (e.g. by FACCH) the CCU shall send TRAU No_Speech frames with Frame_Type set to "AMR" and with No_Speech_Classification set to "No_Data". The Code_Mode_Indication shall be set to the previously used value. CMI and CMR shall be set to the Initial_Codec_Mode, if at resource allocation.

If no speech is received from the MSC side (downlink direction), i.e. the "PCM_Idle" pattern is received instead, the TRAU shall send TRAU No_Speech frames with Frame_Type set to "AMR", and with No_Speech_Classification set to "No_Data". The Codec_Mode_Indication shall be set to the previously used value or to the Initial_Codec_Mode, if at resource allocation.

4.6 Procedures for Speech Services

4.6.1 Time Alignment of Speech Service Frames

The time alignment needed for obtaining minimum buffer delay will differ from call to call. The reasons for this are:

– The BSC will have no information about the radio timing at the BTS, and will start sending frames at an arbitrary or default time. Each TRAU frame is 320 bits (20 ms) long and will in the worst case be received at the BTS 318 bits out of phase.

– The different timeslots on one carrier are sent at different times (max 4.04 ms which equals 7 timeslots in a TDMA radio frame).

– Different channels may be transferred on different transmission systems using different routes in the network. The transmission delay may therefore differ.

The required time alignment between radio frames and TRAU frames is considered to be an internal BTS matter for uplink frames. However, the buffer delay for these frames should be kept to a minimum.

For downlink frames, the procedures in the following clauses should apply. In order to describe the time alignment procedure in the TRAU, two time alignment states are described (Initial Time Alignment state and Static Time Alignment state).

In order to achieve optimum timing between the radio TDMA frames and the frames on the Abis transmission side, the speech coding and decoding functions in the transcoder should not be synchronized.

4.6.1.1 Initial Time Alignment State

The TRAU shall enter the Initial Time Alignment state at the switching-on of the system, when it goes idle (e.g. when receiving the PCM idle pattern after a call release as described in clause 4.3), if loss of frame synchronization is detected, in call modification from data to speech is performed or if BSS internal handover is detected.

In the Initial Time Alignment state, the frames shall only be delayed (or no change)(see note). The transcoder is able to adjust the time for transmitting the speech frames in steps of 125 µs (one speech sample). The CCU calculates the required timing adjustment and returns a frame including the number of 250/500 µs steps by which the frames in the downlink direction have to be delayed (binary number in the "Time Alignment" field).

When receiving this information, the TRAU processes this data and sets the "Time Alignment" field in the next downlink frame as ordered and then delays the subsequent frame accordingly.

NOTE: If the TRAU, in this state, receives an order to advance the next frame 250 µs, this order shall be interpreted as "Delay frame 39*500 µs".

When a frame is delayed due to timing adjustments, the TRAU shall fill in the gap between the frames with the appropriate number of binary "1" (T-bits).

After having adjusted the timing, the TRAU shall receive at least three new frames before a new adjustment is made. This in order to avoid oscillation in the regulation.

The TRAU shall change from the Initial Time Alignment state to the Static Time Alignment state when it has performed two subsequent timing adjustments which are less than 500 µs (including no change).

The procedure is illustrated in figure 4.1.

Optionally, in case of AMR speech, two additional bits (TAE) may be used in an uplink No_Speech frame to code a time alignment command with a precision of 125 µs. When receiving this information, the TRAU processes this data and sets the "Time Alignment" field in the next downlink frame as ordered and then delays the subsequent frame accordingly. It needs to send the TAE bits back only if the downlink frame is a No_Speech frame, too.

4.6.1.2 The Static Time Alignment State

In the Static Time Alignment state, the TRAU performs timing adjustments in single steps of 250 µs or 125 µs (AMR only). The timing may either be delayed (time alignment code "Delay frame by 250 µs (125 µs)"), advanced (time alignment code "Advance frame by 250 µs (125 µs)") or not changed (time alignment code "No Change in Time Alignment" or all other codes that result in no change).

When receiving an order for adjusting the timing, the transcoder skips or repeats two (one) speech samples in order to achieve the correct timing.

If the timing is to be advanced 250 µs (125 µs), the TRAU sets the "Time Alignment" field in the next downlink frame as ordered and then the 4 (2) last bits of the frame are not transferred (the T-bits).

If the timing is to be delayed, the TRAU sets the "Time Alignment" field in the next downlink frame as ordered and then delays the subsequent frame by adding the appropriate number of binary "1" between the frames.

After having adjusted the timing, the TRAU shall receive at least three new frames before a new adjustment is made.

If, in this state and TFO is not ongoing (see GSM 08.62), the TRAU detects a change in the timing of the uplink frames bigger than n x 250 µS, where n = 4, it shall enter the Initial Time Alignment state and in that state it may perform an adjustment on the downlink equal to the change detected on the uplink.

In case of AMR speech the time alignment may be done in steps of 125 µs by using the TAC and TAE. If TFO is ongoing in case of AMR speech the TRAU shall not perform any time alignment in downlink direction.

4.6.1.2.1 Phase Alignment of Codec_Mode_Indication for AMR

In the Static Time Alignment state for Adaptive Multi-Rate speech, it might be necessary to align the phase of the Codec_Mode_Indication and Codec_Mode_Request as indicated in downlink TRAU frames by the RIF bit, to the phase of CMI / CMR on the radio interface. One of the following four alternative methods shall be applied:

Alternative 1: If TFO is not ongoing (see GSM 08.62), then the CCU may send one "Phase Alignment Command" (PAC) uplink (see 3.5.1.2.1). The TRAU shall send two consecutive TRAU frames with Codec_Mode_Indication (RIF set to "0" two times) and by this shall invert the phase of Codec_Mode_Indication and Codec_Mode_Request in downlink on the Abis/Ater interface (consider the round trip delay).

Alternative 2: Similar to Alternative 1: If TFO is not ongoing (see GSM 08.62), then the CCU may send one No_Speech frame with the Phase Alignment Bit (PAB) set accordingly. This may be done already within the initial time alignment state together with the initial time alignment command (TAC and TAE). By this the DL TRAU frames can be aligned in time and phase within one step to a precision of 125 µs.

Alternative 3: If TFO is ongoing (see GSM 08.62) no time and phase alignment shall be performed on the Abis/Ater interface. Instead, the CCU shall buffer (up to 40ms) the downlink speech frames, until they can be sent on the radio interface. If the TRAU receives a time or phase alignment command while in TFO it may ignore it.

Alternative 4: The CCU may send a specific RATSCCH Message downlink to the mobile station (see GSM 05.09) and by that invert the phase of the CMI / CMC on the radio interface and thus avoid the buffer delay (20ms). This alternative is especially useful in TFO, but may be used also without TFO.

Figure 4.1: Initial Time Alignment procedure

4.6.1.3 Initiation at Resource Allocation

When the BTS receives the CHANNEL ACTIVATION message from the BSC, it allocates the appropriate radio resources and a Channel Codec Unit (CCU). In case of FR or EFR the CCU then initiates sending of speech frames (or idle speech frames if speech is not received from the MS) towards the transcoder with normal frame phase for the TDMA channel in question. The "Time Alignment" field in these frames is set to "no change".

The TRAU will now be in the Initial Time Alignment state. When receiving the first frame it shall start sending speech frames (or idle speech frames) towards the BTS with arbitrary or default phase related to the uplink frame phase.

When receiving these frames the CCU calculates the timing adjustment required in order to achieve minimum buffer delay and sets the "Time Alignment" field in the uplink frames accordingly.

The procedures described for the Initial and for the Static Time Alignment states are then followed during the call.

In case of AMR the CCU shall initiate sending of TRAU No_Speech frames towards the transcoder with normal frame phase for the TDMA channel in question unless speech is received on the radio interface. The "Time Alignment" field shall be set to "no change", the TAE shall be set to "0.0" and PAB shall be set to "0". The RIF shall correspond to the phase of the uplink radio interface. The CMI / CMR shall be set to "Initial_Codec_Mode". Consequently, speech transmission will start in uplink and downlink in this mode. In case the BTS supports TFO it shall send the TFO Configuration parameters uplink (see GSM 08.62). The TRAU will now be in the Initial Time Alignment state. When receiving the first UL TRAU frame it shall start sending No_Speech frames (or speech frames, if speech is received from the MSC side) towards the BTS with arbitrary or default phase related to the uplink frame phase. After receiving downlink TRAU frames the CCU may perform time alignment and phase alignment (optionally using TAC, TAE and PAB). The CCU shall keep the Codec_Mode in uplink and downlink fixed to the Initial_Codec_Mode until the correct time and phase alignment in downlink TRAU frames is achieved. Then the Codec_Mode adaptation may be enabled, see also GSM 05.09.

4.6.1.4 Time Alignment During Handover

4.6.1.4.1 BSS External Handover

For BSS external handover, the procedure described in clause 4.6.1.3 should be used by the new BSC/BTS at resource allocation.

4.6.1.4.2 BSS Internal Handover

If TFO is not ongoing and a BSS internal handover has been performed, the timing of the downlink frames may have to be adjusted several steps of 125, 250 or 500 µs. In order to speed up the alignment of the downlink frames, this must be detected by the TRAU, e.g. by detecting the change in the uplink frame timing as described in clause 4.6.1.2. The TRAU should then enter the Initial Time Alignment state and in that state it may perform an adjustment on the downlink equal to the change detected on the uplink.

In case of AMR, when TFO is ongoing, the BTS shall not send any time alignment or phase alignment commands and the TRAU shall not perform any time or phase alignment in downlink direction. Instead the BTS shall buffer the speech frames accordingly (see clause 4.6.1.2.1, alternative 3). Alternatively the BTS may perform a phase alignment on the radio interface by sending a RATSCCH message (see clause 4.6.1.2.1, alternative 4), thus avoiding the buffer delay (20ms).

Please note that optionally before and after handover the AMR link adaptation should be frozen to the Intial_Codec_Mode, until all necessary time and phase alignments have been performed. CMI and CMC should therefore be identical during that period. Consequently a phase mismatch does not matter until the adaptation is enabled.

4.6.2 Procedures for Discontinuous Transmission (DTX)

The procedures for comfort noise are described in GSM 06.12, for Full rate speech and in GSM 06.62 for Enhanced Full rate speech, the overall operation of DTX is described in GSM 06.31 and in GSM 06.81 for respectively Full rate speech and Enhanced Full rate speech and the Voice Activity Detector is described in GSM 06.32 and GSM 06.82 for respectively Full rate speech and Enhanced full rate speech. The relevant procedures for Adaptive Multi-Rate speech are described in GSM 06.92, GSM 06.93 and GSM 06.94. For the case of DTX in ongoing TFO see GSM 08.62.

The DTX Handler function is considered as a part of the TRAU when remote transcoders are applied. The specification of the DTX Handler is given in GSM 06.31 for Full rate speech, in GSM 06.81 for Enhanced Full Rate speech and in GSM 06.93 for Adaptive Multi-Rate speech.

4.6.2.1 DTX procedures in the uplink direction

In case of the Full Rate and Enhanced Full Rate speech: In all frames in the uplink direction, the BFI (Bad Frame Indicator), the SID (Silence Descriptor) indicator and the TAF (Time Alignment Flag) indicator is set as output from the RSS (see GSM 06.31 and GSM 06.81).

In the comfort noise states, the MS will transmit a new frame only every 480 ms (24 frames). These frames are transferred in the normal way between the CCU and the TRAU. Between these frames the CCU shall transfer uplink idle speech frames in case of Full Rate Speech and speech frames with BFI set to "1" in case of Enhanced Full rate Speech.

In case of the Adaptive Multi-Rate speech all frames are classified by the Rx_Type, see also GSM 06.93. In the comfort noise states, the MS will transmit a new SID_Update frame only about every 160 ms (8 frames). These frames are transferred in the normal way between the CCU and the TRAU. Between these SID_Update frames the CCU and TRAU shall transfer "No_Data" frames uplink.

4.6.2.2 DTX procedures in the downlink direction

To inform the DTX handler in the remote transcoder whether downlink DTX may be applied or not, the DTXd bit (C17 in case of Full Rate and Enhanced Full Rate, C19 in case of Adaptive Multi-Rate) in the uplink speech frame is used. The coding is as follows:

DTXd = 0 : downlink DTX is not applied ("not requested" in case of AMR);

DTXd = 1 : downlink DTX is applied ("requested" in case of AMR).

Though this parameter is linked with the resource allocation in the BTS at call setup, its value may vary during the connection.

In case of Full Rate and Enhanced Full Rate speech in the downlink frames the SP (Speech) indicator is set as output from the TX DTX handler (see GSM 06.31 and GSM 06.81).

If downlink DTX is not used, the SP indicator should be coded binary "1".

In case of the Adaptive Multi-Rate speech all downlink frames are classified by the Tx_Type, see also GSM 06.93. In ongoing TFO, in case the distant side uses uplink DTX, downlink DTX may be applied by the TRAU, although DTXd is set to "not requested". For handling in the downlink BTS see GSM 06.93 and 08.62.

4.7 Procedures for Data Frames

4.7.1 9.6 and 4.8 kbit/s channel coding

When rate adaption to 64 Kbit/s is performed at the BTS (sub‑64 kbit/s traffic channels are not used), the rate adaption between the format used on the radio interface and the 64 Kbit/s format is made by the RA1/RA1′ and the RA2 function as described in GSM. 08.20. This is illustrated in figure 4.2.

+——+ +————-+

-┼-| RA2 +—–┼——| RA1 | RA1′ +—┼—-

| +——+ | +——┴——+ |

64 Kbit/s ITU-T V.110 Channel

80 bits codec

frame frame

Figure GSM 08.60/4.2: Rate adaption when performed at the BTS.

When sub‑64 kbit/s traffic channels are used, up to four data frames are transferred in each TRAU frame. In order to convert between the TRAU frame format and the ITU-T 80 bits frame format an additional intermediate rate adaption function, RAA, is applied. This is illustrated in figure 4.3.

+——+ +—+ Abis +—+ +———+

-┼-| RA2 +—┼—-|RAA+—┼—|RAA+-┼-| RA1|RA1’+–┼–

| +——+ | +—+ | +—+ | +—-┴—-+ |

64 Kbit/s ITU-T TRAU ITU-T Channel

V.110 4 X 72 + 32 V.110 codec

80 bits bits 80 bits frame

frame frame frame

Figure GSM 08.60/4.3: Rate adaption when 16 kbit/s traffic channels are used

4.7.1.1 The RAA Function

The RAA function is used to convert between the ITU-T V.110 80 bits frame format and the TRAU frame format. When going from the V.110 format to the TRAU frame format the first octet (all bits coded binary "0") in the ITU-T V.110 80 bits frame is stripped off. Up to four such frames are then transferred in each TRAU frame as shown in clause 3.3.

When going from the TRAU frame format to the V.110 format the data frames are separated and the synchronization octet (all bits coded binary "0") is again included.

The 80 bits V.110 frame is illustrated in figure 4.4, and the modified 72 bits frame is illustrated in figure 4.5.

Bit number

 

Octet no.

1

2

3

4

5

6

7

8

0

0

0

0

0

0

0

0

0

1

1

D1

X

X

X

X

X

X

2

1

X

X

X

X

X

X

X

3

1

X

X

X

X

X

X

X

4

1

X

X

X

X

X

X

X

5

1

X

X

X

X

X

X

X

6

1

X

X

X

X

X

X

X

7

1

X

X

X

X

X

X

X

8

1

X

X

X

X

X

X

X

9

1

X

X

X

X

X

X

X

Figure GSM 08.60/4.4: ITU-T V.110 80 bits frame

Bit number

Octet no.

1

2

3

4

5

6

7

8

0

1

D1

X

X

X

X

X

X

1

1

X

X

X

X

X

X

X

2

1

X

X

X

X

X

X

X

3

1

X

X

X

X

X

X

X

4

1

X

X

X

X

X

X

X

5

1

X

X

X

X

X

X

X

6

1

X

X

X

X

X

X

X

7

1

X

X

X

X

X

X

X

8

1

X

X

X

X

X

X

X

Figure GSM 08.60/4.5: Modified ITU-T V.110 72 bits frame transferred
in a TRAU data frame position

4.7.1.2 The RA1/RA1′ Function

This function is described in GSM 04.21.

4.7.1.3 The RA2 Function

This function is described in GSM 04.21.

4.7.1.4 Procedures for 8 kbit/s intermediate rate adaption rate

For 8 kbit/s intermediate rate adaption rate up to two data frames are transferred in each TRAU frame. The first data frame is transferred in TRAU data frame position 1 and the subsequent data frame is transferred in TRAU data frame position 3 (see clause 3.3).

In TRAU data frame position 2 and 4, all bits are coded binary "1".

If the data transfer terminates before the TRAU frame has been completed, the remaining data bit positions in the TRAU frame should be coded binary "1".

4.7.1.5 Procedures for 16 kbit/s intermediate rate adaption rate

For 16 kbit/s intermediate rate adaption rate, up to four data frames are transferred in each TRAU frame. The first data frame is transferred in TRAU data frame position 1, the next in data frame position 2 etc.

If the data transfer terminates before the TRAU frame has been completed, the remaining data bit positions in the TRAU frame should be coded binary "1".

4.7.1.6 Support of Non-Transparent Bearer Applications

In GSM 08.20, the procedures for transfer of non-transparent bearer applications are specified. The 240 bit RLP frame is converted to four modified V.110 80 bit frames.

The same conversion is applied when transferred in a TRAU frame. The frames are coded as specified in clauses 4.7.4 and 4.7.5.

4.7.2 14.5 kbit/s channel coding

When rate adaption to 64 Kbit/s is performed at the BTS (sub‑64 kbit/s traffic channels are not used), the rate adaption between the format used on the radio interface and the 64 Kbit/s format is as described in GSM 08.20.

When sub‑64 kbit/s traffic channels are used, up to eight 36 bits frames are transferred in each E-TRAU frame. In order to convert between the E-TRAU frame format and the 36 bits frame format used for the radio interface an additional intermediate rate adaption function, RA1’/RAA’, is applied. This is illustrated in figure 4.3.1 (see also GSM 08.20).

+——+ +—-+ Abis +———-+

-┼-| RA2 +—┼—-|RAA’+—┼———-| RAA’|RA1’+–┼–

| +——+ | +—-+ | +—–┴—-+ |

64 Kbit/s A-TRAU E-TRAU Radio

8 X 36 + 32 320 Interface

bits bits frame

frame frame

Figure GSM 08.60/4.3.1: Rate adaption when 16 kbit/s traffic channels are used

4.7.2.1 The RAA’ Function

See GSM 08.20

4.7.2.2 The RA1’/RAA’ Function

This function is described in GSM 08.20.

4.7.2.3 The RA2 Function

This function is described in GSM 04.21.

4.8 Frame Synchronization

4.8.1 Search for Frame Synchronization

The frame synchronization is obtained by means of the first two octets in each frame, with all bits coded binary "0", and the first bit in octet no. 2, 4, 6, 8, … 38 coded binary "1". The following 35 bit alignment pattern is used to achieve frame synchronization:

00000000 00000000 1XXXXXXX XXXXXXXX 1XXXXXXX XXXXXXXX 1XXXXXXX XXXXXXXX
1XXXXXXX XXXXXXXX 1XXXXXXX XXXXXXXX 1XXXXXXX XXXXXXXX 1XXXXXXX XXXXXXXX
1XXXXXXX XXXXXXXX 1XXXXXXX XXXXXXXX 1XXXXXXX XXXXXXXX 1XXXXXXX XXXXXXXX
1XXXXXXX XXXXXXXX 1XXXXXXX XXXXXXXX 1XXXXXXX XXXXXXXX 1XXXXXXX XXXXXXXX
1XXXXXXX XXXXXXXX 1XXXXXXX XXXXXXXX 1XXXXXXX XXXXXXXX 1XXXXXXX XXXXXXXX

4.8.2 Frame Synchronization After Performing Downlink Timing Adjustments

If the timing of the downlink speech frames is adjusted, the adjustment is indicated in bits C6 – C11 as described in clauses 4.6.1.1 and 4.6.1.2. The frame synchronization unit shall change its frame synchronization window accordingly.

4.8.3 Frame Synchronization Monitoring and Recovery

The monitoring of the frame synchronization shall be a continuous process.

Loss of frame synchronization shall not be assumed unless at least three consecutive frames, each with at least one framing bit error, are detected.

In case of Full Rate speech:

If the TRAU looses its frame synchronization it starts a timer Tsync = 1 second. If Tsync expires before frame synchronization is again obtained the TRAU initiates sending of the urgent alarm pattern described in clause 4.10.2.

The exception from this procedure is when "Resource Release" is detected while Tsync is running (see clause 4.3). In this case, the procedure in clause 4.3 shall be followed.

If loss of frame synchronization is detected by the CCU it starts a timer Tsync. If Tsync expires before frame synchronization is again obtained the call shall be released and an indication given to O&M.

Tsync is reset every time frame synchronization is again obtained.

In case of Enhanced Full Rate speech and Adaptive Multi-Rate speech:

When it detects a framing bit error, the TRAU uses the control bit UFE (uplink Frame Error) in the next downlink TRAU frame to indicate it to the CCU. When the CCU receives a TRAU frame indicating an Uplink Frame Error and which has no errors on the sychronization pattern and the control bits, it starts a timer TsyncU.

If loss of frame sychronization is detected by the CCU it starts a timer TsyncD. If TsyncD or TsyncU expires before frame sychronization is again obtained, the call shall be released as specified in GSM 08.58 with the case field set to " Remote Transcoder Failure".

TsyncD is reset every time frame synchronisation is again obtained.

TsychU is reset every time three consecutive TRAU frames are received without Uplink Frame Error indication, without errors on the frame synchronisation pattern and on the control bits.

TsyncD and TsyncU are parameters set by O&M (default value = 1 second).

In case of Data 14.5 kbit/s:

The following 17 bit alignment pattern of the Extended Data TRAU Frame is used for Frame Synchronization Monitoring:

00000000 00000000 1XXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

When it detects a framing bit error, the TRAU uses the control bit UFE (uplink Frame Error) in the next downlink Extended Data TRAU Frame to indicate it to the CCU. When the CCU receives an Extended Data TRAU Frame indicating an Uplink Frame Error and which has no errors on the synchronization pattern and the control bits, it starts a timer TsyncU and TsyncR.

If loss of frame synchronization is detected by the CCU it starts a timer TsyncD and starts sending Data TRAU Frames in the uplink direction to trigger the TRAU to start sending Data TRAU Frames in the downlink direction to be used for downlink Synchronization Recovery.

If TsyncR expires before frame synchronization is again obtained, the CCU starts sending Data TRAU Frames in the uplink direction to be used for uplink Synchronization Recovery.

If TsyncD or TsyncU expires before frame synchronization is again obtained, the call shall be released as specified in GSM 08.58 with the case field set to " Remote Transcoder Failure".

TsyncD is reset every time frame synchronization is again obtained.

TsychU and TsyncR is reset every time three consecutive TRAU frames are received without Uplink Frame Error indication, without errors on the frame synchronization pattern and on the control bits.

TsyncD and TsyncU are parameters set by O&M (default value = 1 second)

TsyncR are a parameter set by O&M (default value = 60 milliseconds).

4.9 Correction/detection of bit errors on the terrestrial circuits

4.9.1 Error Detection on the Control Bits

For the control bits, (C-bits), no error coding is made. Exception: In case of AMR the C-Bits are protected by CRC. However, in order to reduce the possibility of misinterpretation of control information due to bit errors, the following procedure should be followed.

4.9.1.1 General Procedure

If any undefined combination of the C-bits is received (see clause 3.5), the frame should be reacted upon as received with errors.

4.9.1.2 Frames for Speech Services

In addition to the general procedure described in the previous clause, the following procedure should be followed:

Bits C6 – C11: Time Alignment.

The full range of the time alignment adjustment should only be applied when the TRAU is in the Initial Time Alignment state (see clauses 4.6.1.1 and 4.6.1.2).

If, in the Static Time Alignment state, a time alignment order is received indicating an adjustment of more than 250 µs, the next downlink frame should be delayed only one 250 µs step.

If an uplink frame is received with the "Time Alignment" field set to an unused value, this value should be interpreted as "no change".

4.9.2 Handling of frames received with errors

If TRAU frame is received in the uplink or downlink with detectable errors in the control bits, then the control information shall be ignored. The speech or data bits may be handled as if no error had been detected.

If frame synchronisation has been lost (see clause 4.8.3) in the uplink direction the TRAU shall:

– for speech, mute the decoded speech as if it has received frames with errors (cf. GSM 06.11 and GSM 06.61 and GSM 06.91);

– for data, send idle frames as defined in GSM 08.20 to the MSC/interworking.

4.9.2.1 In case of Full Rate speech

If frame synchronisation has been lost in the downlink direction then the same procedure shall be followed as when frame synchronisation is lost on the PCM link.

4.9.2.2 In case of Enhanced Full Rate and Adaptive Multi-Rate speech

For speech calls, the CCU shall transmit a layer two fill frame on the air interface if frame synchronization has been lost in the downlink direction.

If a CRC error is detected in a downlink TRAU speech frame a solution can be to transmit a layer two fill frame on the air interface, another solution can be to replace the bad part of the TRAU speech frame only. The choice of the solution is left open.

If a CRC error is detected in a uplink TRAU speech frame, the TRAU speech frame shall be regarded as bad or partly bad and the TRAU shall apply the procedure defined in GSM 06.61, respectively GSM 06.91.

4.10 Procedures for Operation & Maintenance

The general procedures for Operation and Maintenance are described in GSM 12.21.

If the transcoders are positioned outside the BTS, some O&M functions will be required for the TRAU and the CCU. In particular this applies for transcoders positioned at the MSC site.

The transcoders outside the BTS are considered a part of the BSC, and the O&M functions for the TRAU should therefore be implemented in the BSC.

The CCU is a part of the BTS and the O&M functions for this unit should therefore be implemented in the BTS.

4.10.1 Transfer of O&M Information Between the TRAU and the BSC

The transfer of O&M information between the BSC and the TRAU is possible to do in two ways. Either it is handled directly between the BSC and the TRAU or a BTS is used as a message transfer point. The choice between the two methods is up to the manufacturer of the BSC:

i) The transfer of O&M information between the BSC and the TRAU is handled internally by the BSC. The O&M signalling between the TRAU and the BSC may either be handled by proprietary BSC solutions or the O&M TRAU frames defined in clauses 3.2 and 3.5.2 could be used. In the latter case, the BSC has to act as a terminal for the O&M TRAU frames sent between the TRAU and the BSC.

ii) The O&M information between the TRAU and the BSC is transferred using O&M TRAU frames between the TRAU and the CCU in a BTS. The BTS then acts as a relay function between the O&M TRAU frames and the associated O&M messages sent between the BTS and the BSC.

4.10.2 Procedures in the TRAU

In case of urgent fault conditions in the TRAU, e.g. loss of frame synchronization, non-ability of the transcoder to process data etc., this should if possible, be signalled to the BTS/BSC as an urgent alarm pattern. The urgent alarm pattern is a continuous stream of binary "0".

If O&M TRAU frames information between the TRAU and the BSC is transferred using O&M frames between the CCU in a BTS and the TRAU, the TRAU sends O&M frames periodically until the identical O&M TRAU frame is received for acknowledgement. The period is at least 64*20ms (1,28 sec).

In case of minor fault conditions, when no immediate action is required, the TRAU may send O&M frames indicating the fault instead of the urgent alarm pattern.

4.10.3 Procedures in the BSC

The BSC should be able to detect a faulty TRAU, take it out of service and give an indication to O&M. A faulty TRAU could be detected e.g. by routine tests, alarms from the TRAU, release of call initiated by the BTS due to remote transcoder failure etc. How this is handled by the BSC is regarded as a BSC internal matter.

4.10.3.1 Use of O&M Frames

The use and coding of O&M TRAU frames is left to the implementor of the BSC/TRAU.

If O&M TRAU frames are used, they are always carrying 264 data bits.

Any corresponding O&M message between the BSC and the BTS shall always carry all 264 O&M data bits.

4.10.4 Procedures in the BTS

If a CCU in a BTS receives O&M TRAU frames from the TRAU, the BTS shall:

– send the identical frame to the TRAU for acknowledgement; and

– put the 264 data bits from the received frames into an appropriate O&M message and send it to the BSC.

If the CCU receives O&M frames during a call then "stolen frames" shall be indicated to the MS and layer 2 frames of format A (see GSM 04.06) shall be transmitted.

If the CCU receives O&M frames during a data call, then the same procedure shall be used as when V.110 frame is lost.

If receiving an O&M message from the BSC, carrying TRAU O&M information, the BTS puts the 264 data bits from the received message into an O&M TRAU frame and then the CCU allocated to the addressed connection sends the frame to the TRAU in one single O&M TRAU frame. Repetition is done according to GSM 12.21.

In case of a faulty CCU, the O&M procedures are BTS internal.

If the CCU receives the urgent alarm pattern, the BTS shall initiate release of the call as specified in GSM 08.58 with the cause field set to "Remote Transcoder Failure".

Annex A (informative):
Change History

Change history

SMG No.

TDoc. No.

CR. No.

Clause affected

New version

Subject/Comments

SMG#07

4.1.3

ETSI Publication

SMG#13

027
028
029
030

4.6.1.2, 4.6.1.4.2

4.2.0

Remote management of the loss of synch by transcoder
Improvement of the transcoder time alignment process
Clarification of clauses 4.6.1.2 and 4.6.1.4.2
Initial Time Alignment

SMG#22

434/97

A004

4.3.0

Provide an option to handle missing data in case of full rate in the same way as for enhanced full rate

SMG#23

97-770

A007

4.4.0

Update of inband control of the remote TRAU to handle the frames of the new codec EFR (Phase 2)

SMG#19

5.0.1

Release 1996 version

SMG#22

434/97

434/97
459/97

A005

A006
A007

5.1.0

Provide an option to handle missing data in case of full rate in the same way as for enhanced full rate
Introduction of 14.5 kbit/s channel coding
WI 14.4 kbit/s user data

SMG#22

5.1.1

ETSI version change

SMG#27

6.0.0

Release 1997 version

SMG#29

7.0.0

Release 1998 version

SMG#30

580/99

A010

7.1.0

Introduction of AMR

SMG#30

616/99

A009

8.0.1

Asymmetrical Channel Codings for ECSD

SMG#30bis

806

A012

3.5.1.2.1, 3.5.1.2.2 and 4.6.2.2

8.1.0

Support of AMR-TFO

8.1.1

Editorial

N.B Draft version 8.0.0 exists without CR 0860-A010.

Change history

Date

TSG GERAN#

TSG Doc.

CR

Rev

Subject/Comment

Old

New

2002-02

08

GP-020181

A014

Handover_Complete

8.1.1

8.2.0

2003-01

Replacement of corrupted Figure 2.1

8.2.0

8.2.1