6 Procedures
3GPP48.061In-band control of remote transcoders and rate adaptors for half rate traffic channelsRelease 17TS
For AMR speech on 8 kBit/s submultiplexing the procedures are very much identical to the ones described in 3GPP TS 48.060 for AMR speech on 16 kBit/s submultiplexing. In the present recommendation (48.061) therefore only the procedures are defined that differ from that.
6.1 Remote Control of Transcoders and Rate Adaptors
When the TRAU is positioned remote from the BTS, the CCU in the BTS has to control some of the functions in the remote TRAU.
This remote control is performed by in‑band signalling carried by the control bits in each TRAU frame.
The following functions in the TRAU are remotely controlled by the CCU:
‑ change between speech and data;
‑ downlink frame timing for speech frames;
‑ transfer of DTX information.
In addition the following is transferred in case of AMR speech:
– control of Codec Mode Adaptation;
– transfer of TFO Configuration Parameters (optional, see 3GPP TS 48.062);
– downlink Phase Alignment (optional, see 3GPP TS 48.060);
– transfer of Information on TFO and Handover Status (optional, see 3GPP TS 48.060 and 48.062).
In addition, the in‑band signalling also provides means for transfer of O&M signals between the TRAU and the BSC/BTS.
6.2 Resource Allocation
In case of AMR speech see 3GPP TS 48.060.
At reception of the 3GPP TS 48.008 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 3GPP TS 48.058 CHANNEL ACTIVATION message to the BTS.
When receiving the CHANNEL ACTIVATION message, the BTS allocates the appropriate radio resources and a CCU to be used.
The CCU now starts sending uplink TRAU frames with the appropriate frame type.
When receiving the first frame, the TRAU sets the mode of operation as indicated by the CCU and starts sending downlink TRAU frames with the corresponding frame type.
6.3 Resource Release
In case of AMR speech see 3GPP TS 48.060.
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. Two methods may be used for either submultiplexing scheme.
i) The BSC indicates the call release to the TRAU by inserting the PCM idle bit pattern described in 3GPP TS 48.054 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 Trelease = 1 second. If, when Trelease expires, the idle bit pattern is detected, the TRAU shall terminate the operation (go idle) until a valid frame is again received. Trelease is reset every time the frame synchronization is again obtained.
ii) It is handled by BSC internal signals (e.g. if the BSC and TRAU are collocated).
6.4 In Call Modification
In case of AMR speech see 3GPP TS 48.060.
At reception of the 3GPP TS 48.058 MODE MODIFY message from the BSC indicating a change between speech and data, the BTS orders the corresponding CCU to modify its mode of operation. The CCU sets the frame type in the uplink TRAU frames to the new mode of operation.
When the TRAU receives an uplink TRAU frame with the frame type, different from the current mode but without errors detected (see clause 6.9.1.2), the current mode is kept and speech/data bits are handled as erroneous. When receiving the next TRAU frame with the same frame type, the TRAU changes the mode of operation accordingly and sets the new frame type in the downlink frames.
6.5 Transfer of Idle Frames, Handling of missing data
In case of AMR speech see 3GPP TS 48.060.
If no speech is received from the MS (uplink direction) in case of Half Rate speech, the CCU shall send TRAU speech frames with BFI flag set to 1 (bad frame). If no data is received from the MS (uplink direction), the CCU shall send idle TRAU data frames.
For Half Rate speech calls, the CCU shall transmit a speech frame with the three parity bits inverted (protection of the most significant 22 class 1 bits, see 3GPP TS 45.003) on the air interface:
‑ if frame synchronization has been lost in the downlink direction;
‑ if a CRC error is detected (bits CRC0‑CRC2) in a downlink TRAU speech frame;
‑ if an O&M TRAU frame is received (see clause 6.10).
For data calls, the CCU shall react towards the air interface as if an idle TRAU data frame has been received:
‑ when frame synchronization has been lost in the downlink direction;
‑ when an O&M TRAU frame is received (see clause 6.10).
An idle TRAU data frame is a TRAU data frame with all data bits set to binary "1".
6.6 Procedures for Speech Frames
6.6.1 Time Alignment of Speech 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 TRAU frames at an arbitrary or default time. In the case of 16 kbit/s submultiplexing, each TRAU frame is 320 bits (20 ms) and will in the worst case be received at the BTS 318 bits out of phase. In the case of 8 kbit/s submultiplexing, each TRAU frame is 160 bits (20 ms) and will in the worst case be received at the BTS 159 bits out of phase;
‑ the different timeslots and half rate subchannels on one carrier are sent at different times (max. 8.66 ms which equals 15 radio time slots);
‑ 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 procedure between radio frames and TRAU frames is specified in clauses 6.6.1.1 and 6.6.1.2 for the 16 kbit/s submultiplexing and the 8 kbit/s submultiplexing respectively.
In order to achieve optimum timing between the radio TDMA frames and the frames on the transmission side, the speech coding and decoding function in the transcoder should not be synchronized.
6.6.1.1 16 kbit/s submultiplexing
For AMR speech see 3GPP TS 48.060.
6.6.1.1.1 Downlink Time Alignment
6.6.1.1.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 6.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 state, the frames shall only be delayed or no change is applied (see note below). 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.
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".
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 6.1.
6.6.1.1.1.2 Static Time Alignment state
In the Static Time Alignment state, the TRAU performs timing adjustments in single steps of 250 µs. The timing may either be delayed (time alignment code 111110, advanced (time alignment code 111111) or not changed (time alignment code 000000).
When receiving an order for adjusting the timing, the transcoder skips or repeats two speech samples in order to achieve the correct timing.
If the timing is to be advanced 250 µs, the TRAU sets the "Time Alignment" field in the next downlink frame as ordered and then the 4 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 four 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, the TRAU detects a change in the timing of the uplink frames greater than 1ms, 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.
Figure 3GPP TS 48.061/6.1: Initial Time Alignment procedure, 16 kbit/s submultiplexing
6.6.1.1.2 Uplink Time Alignment
In order to achieve optimum timing between the Air interface and the terrestrial link, the tail bits of the uplink speech frames may be used for uplink time alignment.
To advance 125 µs, the CCU removes the last two tail bits of the uplink TRAU speech frame.
To delay 125 µs, the CCU inserts two binary "1" between two uplink TRAU speech frames.
6.6.1.1.3 Initiation at Resource Allocation
When the BTS receives the 3GPP TS 48.058 CHANNEL ACTIVATION message from the BSC, with Channel Mode IE indicating speech, it allocates the appropriate radio resources and a Channel Codec Unit (CCU). The CCU then initiates sending of speech frames (or applies the procedure specified in clause 6.5 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 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.
6.6.1.1.4 Time Alignment during Handover
6.6.1.1.4.1 BSS External Handover
For BSS external handover, the procedure described in clause 6.6.1.1.3 should be used by the new BSC/BTS at resource allocation.
6.6.1.1.4.2 BSS Internal Handover
If a BSS internal handover has been performed, the timing of the downlink frames may have to be adjusted several steps of 250/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 6.6.1.1.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.
6.6.1.2 8 kbit/s submultiplexing
For AMR speech on 8 kBit/s submultiplexing the same procedures as for AMR speech on 16 kBit/s submultiplexing shall be applied, see 3GPP TS 48.060. Note: For 8 kBit/s submultiplxing the Time Alingment commands are defined only for No_Speech frames and therefore speech frames may need to be stolen to perform time and phase alignment.
6.6.1.2.1 Downlink Time Alignment
The TRAU must be able to adjust the time for transmitting the downlink TRAU frames in steps of 250 µs.
The CCU must be able to calculate the required Time Alignment (TA) with a resolution of 250 µs.
The TA requests are in the range of 250 µs to 19,75 ms. The CCU calculates the required TA, sends a TA compound request to the TRAU and then starts timer Tta.
A TA compound request consists of up to five consecutive TA requests. The allowed values of TA requests are given in table 6.1.
The CCU does not send TA requests when timer Tta is running. Tta is reset by the CCU when the TRAU has applied the TA compound request. The TRAU performs time adjustment corresponding to the TA compound request.
The CCU can send a new TA compound request as soon as the TRAU has applied the previous TA compound request or Tta has expired.
Tta is a parameter settable by O&M.
NOTE: The timer Tta shall be set taking into account the transmission delay and the TRAU reaction time for the application of the TA compound request.
Table 3GPP TS 48.061/6.1: Allowed values of TA requests
|
TA2 |
TA1 |
TA0 |
Value |
|
1 |
1 |
1 |
no change |
|
1 |
1 |
0 |
‑ 250 µs |
|
1 |
0 |
1 |
+ 250 µs |
|
0 |
1 |
1 |
+ 500 µs |
|
1 |
0 |
0 |
+ 1 ms |
|
0 |
1 |
0 |
+ 3 ms |
|
0 |
0 |
1 |
+ 6 ms |
|
0 |
0 |
0 |
+ 9 ms |
When the TRAU detects an uplink transmission error, it ignores the possible TA request contained in the erroneous TRAU frame.
If the timing is to be advanced by 250 µs, the TRAU shall not transfer the last two bits of the next downlink TRAU frame (bits T1, T2).
If the timing is to be delayed, the TRAU shall delay the next downlink TRAU frame by inserting the appropriate number of binary "1".
An example of the procedure is illustrated in figure 6.2.
If the TRAU detects a change in the timing of the uplink frames greater than 1 ms, it may perform an adjustment on the downlink equal to the change detected on the uplink.
Figure 3GPP TS 48.061/6.2: Time Alignment procedure, 8 kbit/s submultiplexing
6.6.1.2.2 Uplink Time Alignment
In order to achieve optimum timing between the Air interface and the terrestrial link, the tail bits of the uplink speech frames may be used for uplink time alignment.
To advance 125 µs, the CCU removes the last tail bit (T2) of the uplink TRAU speech frame.
To delay 125 µs, the CCU inserts one binary "1" between two uplink TRAU speech frames.
In case of AMR two tail bits (D126 .. T) are defined for No_Speech frames, one tail bit (T) for the three lower codec modes (4,75, 5,15 and 5,90) and no tail bits for the higher modes (6,70 and 7,40). To advance by 125 µs in the higher codec mode , the CCU may either remove the last data bit (small distortion of the speech signal) or replace a speech frame by a No_Speech frame (also speech distortion) and then remove the T bit. To delay 125 µs, the CCU inserts one binary "1" between two uplink TRAU speech frames.
6.6.1.2.3 Initiation at Resource allocation
When the BTS receives the 3GPP TS 48.058 CHANNEL ACTIVATION message from the BSC, with Channel Mode IE indicating speech, it allocates the appropriate radio resources and a CCU. The CCU then initiates sending of TRAU speech frames towards the TRAU with normal frame phase for the TDMA channel in question.
When receiving the first frame, the TRAU shall start sending speech frames towards the CCU 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 sends a timing adjustment request to the TRAU according to the procedure described in clause 6.6.1.2.1.
6.6.1.2.4 Time Alignment during handover
6.6.1.2.4.1 BSS External Handover
For BSS external handover, the procedure described in clause 6.6.1.2.3 should be used by the new BSC/BTS at resource allocation.
6.6.1.2.4.2 BSS Internal Handover
The timing of the downlink frames may have to be adjusted if a BSS internal handover has been performed. 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 6.6.1.2.1. The TRAU may consequently perform an adjustment on the downlink equal to the change detected on the uplink.
6.6.2 Procedures for Discontinuous Transmission (DTX)
For Adaptive Multi-Rate speech see 3GPP TS 48.060.
The procedures for comfort noise are described in 3GPP TS 46.022, the overall operation of DTX is described in 3GPP TS 46.041 and the Voice Activity Detector is described in 3GPP TS 46.042.
The downlink 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 3GPP TS 46.041.
6.6.2.1 DTX procedures in the uplink direction
In the comfort noise generation state, the MS will transmit a new traffic frame only every 240 ms (which corresponds to 12 TRAU speech frames). These traffic frames are transferred in the normal way between the CCU and the TRAU. If no valid traffic frames are received, the CCU shall apply the procedure described in clause 6.5. Furthermore the frame classification is done according to the following paragraphs.
16 kbit/s submultiplexing
In all uplink 320 bit TRAU frames, the BFI (Bad Frame Indicator) indicator, the SID (Silence Descriptor) indicator and the TAF (Time Alignment Flag) indicator are set as output from the Radio Subsystem (Error correction & detection and SID frame detection, see 3GPP TS 46.041).
8 kbit/s submultiplexing
The frame classification is set as output from the Radio Subsystem (Error correction and detection and SID frame detection, see 3GPP TS 46.041) in the uplink 160 bit TRAU speech frame (SID frame, see clauses 5.2.1 and 5.2.4.1).
6.6.2.2 DTX procedures in the downlink direction
To inform the DTX handler in the remote transcoder whether downlink DTX shall be applied or not, the DTXd bit in the uplink TRAU speech frame is used. The coding is as follows:
DTXd = 0: Downlink DTX shall not be applied;
DTXd = 1: Downlink DTX shall be applied.
Though this parameter is linked with the resource allocation in the BTS at call setup, its value may vary during the connection.
Two consecutive TRAU frames without detected errors and with the same DTXd flag value shall be considered as an indication to change DTX mode.
The SP (Speech) indicator is set as output from the Tx DTX handler (voice activity detection, see 3GPP TS 46.041) in the downlink TRAU speech frames (see clause 5.2.4.2).
6.7 Procedures for Data Frames
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 3GPP TS 48.020. This is illustrated in figure 6.3.
Figure 3GPP TS 48.061/6.3: Rate adaption when performed at the BTS
When sub‑64 kbit/s traffic channels are used, two modified ITU‑T V.110 frames are transferred in each TRAU data frame. An additional intermediate rate adaption function, RAA, is applied in order to perform the adaption between the TRAU data frame format and the ITU‑T V.110 80 bits frame format. This is illustrated in figure 6.4.
Figure 3GPP TS 48.061/6.4: Rate adaption when sub‑64 kbit/s traffic channels are used
6.7.1 The RAA Function
The RAA function performs the adaption between the ITU‑T V.110 80 bits frame format and the TRAU data frame format.
When going from the V.110 format to the TRAU data frame format, the synchronization pattern (first octet with all bits coded binary "0" and the 9 bits coded binary "1" in the position 1 of the following octets) of the ITU‑T V.110 80 bits frame is stripped off. Two modified V.110 63 bits frames are then transferred in each TRAU data frame as shown in clause 5.1.2 for 16 kbit/s submultiplexing and clause 5.2.2 for 8 kbit/s submultiplexing.
When going from the TRAU data frame format to the V.110 80 bits frame format, the two modified V.110 63 bits frames are separated and the synchronization pattern is again included.
The 80 bits V.110 frame is illustrated in figure 6.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 |
D2 |
D3 |
D4 |
D5 |
D6 |
D7 |
|
2 |
1 |
D8 |
D9 |
D10 |
D11 |
D12 |
D13 |
D14 |
|
3 |
1 |
D15 |
D16 |
D17 |
D18 |
D19 |
D20 |
D21 |
|
4 |
1 |
D22 |
D23 |
D24 |
D25 |
D26 |
D27 |
D28 |
|
5 |
1 |
D29 |
D30 |
D31 |
D32 |
D33 |
D34 |
D35 |
|
6 |
1 |
D36 |
D37 |
D38 |
D39 |
D40 |
D41 |
D42 |
|
7 |
1 |
D43 |
D44 |
D45 |
D46 |
D47 |
D48 |
D49 |
|
8 |
1 |
D50 |
D51 |
D52 |
D53 |
D54 |
D55 |
D56 |
|
9 |
1 |
D57 |
D58 |
D59 |
D60 |
D61 |
D62 |
D63 |
Figure 3GPP TS 48.061/6.5: ITU‑T V.110 80 bits frame
16 kbit/s submultiplexing
The modified V.110 63 bits frame is illustrated in clause 5.1.2 with:
‑ the D‑bits of the modified V.110 63 bits frame in position 1 of the TRAU data frame;
‑ the D’‑bits of the modified V.110 63 bits frame in position 3 of the TRAU data frame,
corresponding respectively to the D‑bits of the V.110 80 bits frame (see figure. 6.5).
8 kbit/s submultiplexing
The modified V.110 63 bits frame is illustrated in clause 5.2.2 with:
‑ the D‑bits of the modified V.110 63 bits frame in position 1 of the TRAU data frame;
‑ the D’‑bits of the modified V.110 63 bits frame in position 2 of the TRAU data frame,
corresponding respectively to the D‑bits of the V.110 80 bits frame (see figure. 6.5).
6.7.2 The RA1/RA1′ Function
This function is described in 3GPP TS 44.021.
6.7.3 The RA2 Function
This function is described in 3GPP TS 44.021.
6.7.4 Procedures for 8 kbit/s intermediate rate adaption rate
For 8 kbit/s intermediate rate adaption rate, two modified ITU‑T V.110 72 bits frames are transferred in each TRAU data frame. If the data transfer terminates before the TRAU data frame has been completed, the remaining data bit positions in the TRAU data frame should be coded binary "1".
If V.110 frame synchronization has been lost in the downlink direction, the TRAU shall react as if V.110 frames with all data bits coded binary "1" had been received (bits D1 to D63, see clause 6.7.1).
6.7.5 Support of Non‑Transparent Bearer Applications
The procedures for transfer of non‑transparent bearer applications are specified in 3GPP TS 48.020. 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 data frame. The TRAU data frames are coded as specified in clause 6.7.4.
6.8 Frame Synchronization
6.8.1 16 kbit/s submultiplexing
6.8.1.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. 3, 5, 7, 9, … 39 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 |
6.8.1.2 Frame Synchronization After Performing Downlink Timing Adjustments
If the timing of the downlink TRAU speech frames is adjusted, the adjustment is indicated in bits C6 ‑ C11 as described in clauses 6.6.1.1.1.1 and 6.6.1.1.1.2. The frame synchronization unit of the CCU shall change its frame synchronization window accordingly.
6.8.1.3 Frame Synchronization Monitoring and Recovery
The monitoring of the frame synchronization shall be a continuous process using the same procedure as for initial detection.
Loss of frame synchronization shall not be assumed unless at least three consecutive frames, each with at least one framing bit error, are detected.
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 synchronization pattern and the control bits, it starts a timer TsyncU.
If loss of frame synchronization is detected by the CCU it starts a timer TsyncD. If TsyncD or TsyncU expires before frame synchronization is again obtained the call shall be released as specified in 3GPP TS 48.058 with the cause field set to "Remote Transcoder Failure".
TsyncD is reset every time frame synchronization is again obtained.
TsyncU 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).
6.8.2 8 kbit/s submultiplexing
6.8.2.1 Search for Frame Synchronization
6.8.2.1.1 For Half Rate speech and data
The frame synchronization is obtained by a 28 bit pattern which is indicated below by all the bits set to binary "0" or binary "1".
|
0 0 0 0 0 0 0 0 |
1 x x x x x x x |
0 1 x x x x x x |
1 x x x x x x x |
|
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
|
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
|
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
|
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
6.8.2.1.2 For Adaptive Multi-Rate speech
The frame synchronisation for No_Speech frames and the speech frames of the three lower codec modes is obtained by a 28 bit pattern, which is indicated below by all the bits set to binary "0" or binary "1".
Initial Synchronisation is started after resource allocation and after loss of synchronisation. Initial Synchronisation shall be a continuous process. Synchronisation shall be regarded as obtained if at least one complete frame is detected with all 28 synchronisation bits and all control and CRC bits correct:
|
0 0 0 0 0 0 0 0 |
1 x x x x x x x |
1 x x x x x x x |
0 1 x x x x x x |
|
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
|
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
|
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
|
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
The frame synchronisation for the speech frames for codec mode 6,70 kBit/s is obtained by a 21 bit pattern, which is indicated below by all the bits set to binary "0" or binary "1". This codec mode may be used for Initial Synchronisation, the preferred solution is, however, to user a lower code mode or No_Speech frames. Initial Synchronisation is started after resource allocation and after loss of synchronisation. Initial Synchronisation shall be a continuous process. Synchronisation shall be regarded as obtained if at least one complete frame is detected with all 21 synchronisation bits and all control and CRC bits correct:
|
0 0 0 0 0 0 0 0 |
1 x x x x x x x |
1 x x x x x x x |
1 x x x x x x x |
|
1 x x x x x x x |
0 x x x x x x x |
1 x x x x x x x |
x x x x x x x x |
|
1 x x x x x x x |
x x x x x x x x |
1 x x x x x x x |
x x x x x x x x |
|
1 x x x x x x x |
x x x x x x x x |
1 x x x x x x x |
x x x x x x x x |
|
1 x x x x x x x |
x x x x x x x x |
1 x x x x x x x |
x x x x x x x x |
The frame synchronisation for the speech frames for codec mode 7,40 kBit/s is obtained by a 6 bit pattern, which is indicated below by all the bits set to binary "0" or binary "1". This codec mode shall not be used for Initial Synchronisation, the recommended solution is to user a lower code mode or No_Speech frames:
|
0 0 1 x x x x x |
0 x x x x x x x |
1 x x x x x x x |
0 x x x x x x x |
|
x x x x x x x x |
x x x x x x x x |
x x x x x x x x |
x x x x x x x x |
|
x x x x x x x x |
x x x x x x x x |
x x x x x x x x |
x x x x x x x x |
|
x x x x x x x x |
x x x x x x x x |
x x x x x x x x |
x x x x x x x x |
|
x x x x x x x x |
x x x x x x x x |
x x x x x x x x |
x x x x x x x x |
6.8.2.2 Frame Synchronization Monitoring and Recovery
6.8.2.2.1 For Half Rate speech and data
Same as clause 6.8.1.3.
6.8.2.2.2 For Adaptive Multi-Rate speech
The monitoring of the frame synchronisation shall be a continuous process. A frame, respectively a subframe, shall be regarded as correctly received, if synchronisation was established before the beginning of the frame (subframe) and all synchronisation, control and CRC bits within the frame (subframe) are correct. Since the Adaptive Multi-Rate codec may change its codec mode every 40 ms, the monitoring of frame synchronisation shall take these possible changes into account.
Loss of frame synchronisation shall not be assumed unless at least three consecutive frames, each with at least one framing bit error, are detected. However, for every frame with detected errors a No_Speech frame shall be sent back with the UFE (DFE) bits set, see clause 6.9.2.1. The receiver shall in addition check, whether the synchronisation pattern can be detected plus or minus one position shifted with respect to the expected position within the bit stream. If synchronisation can not be found by this within three frames, then Initial Synchronisation shall be performed.
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 synchronization pattern and the control bits, it starts a timer TsyncU.
If loss of frame synchronization is detected by the CCU it starts a timer TsyncD. If TsyncD or TsyncU expires before frame synchronization is again obtained the call shall be released as specified in 3GPP TS 48.058 with the cause field set to "Remote Transcoder Failure".
TsyncD is reset every time frame synchronization is again obtained.
TsyncU 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).
6.9 Correction/detection of bit errors
6.9.1 16 kbit/s submultiplexing
In case of AMR speech see 3GPP TS 48.060.
6.9.1.1 Error Detection on the Control Bits
In order to reduce the possibility of misinterpretation of control information due to bit errors, the following procedure should be followed:
6.9.1.1.1 General Procedure
If any undefined combination of the C‑bits is received (see clause 5.1.4), the TRAU frame shall be handled as defined in clause 6.9.1.2.
6.9.1.1.2 Frames for Half Rate speech
In addition to the general procedure described in the previous clause, the following procedure should be followed for the speech frames:
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 6.6.1.1.1.1 and 6.6.1.1.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 (101000 … 111101), this value should be interpreted as "no change".
6.9.1.2 Handling of frames received with errors for Half Rate speech and data
If a TRAU frame is received in the uplink or downlink with detectable errors in the control bits, then the control information shall be ignored and the control information from the previous received TRAU frame shall be used to handle the speech or data bits as if no error had been detected.
If frame synchronization has been lost in the uplink direction, the TRAU shall:
‑ for speech, mute the decoded speech as if it has received TRAU frames with errors (cf. 3GPP TS 46.021);
‑ for data, send idle V.110 frames as defined in 3GPP TS 48.020 to the MSC interworking unit.
The CCU shall follow the procedure specified in clause 6.5:
‑ if frame synchronization has been lost in the downlink direction;
‑ if a CRC error is detected (bits CRC0‑CRC2) in a downlink TRAU speech frame.
If a CRC error is detected (bits CRC0‑CRC2) in a uplink TRAU speech frame, the TRAU speech frame shall be regarded as bad and the TRAU shall apply the procedure defined in 3GPP TS 46.021.
6.9.2 8 kbit/s submultiplexing
6.9.2.1 Error Detection on the Control Bits
In case of Half Rate speech and Data:
Error detection is made on control bits C1‑C4 with the parity bit C5 (see clause 5.2.4) for all types of 160 bit TRAU frames. Additionally, for TRAU speech frames, error detection is made on control bits XC1‑XC5 with the parity bit XC6.
If the following occurs:
‑ parity bit C5 and/or parity bit XC6 are wrong;
‑ any undefined combination of the control bits is received (see clause 5.2.4) with a correct parity bit.
The TRAU frame shall be handled as defined in clause 6.9.1.2.
In case of Adaptive Multi-Rate speech:
If errors are detected within the Sync bits, the Control bits or by the CRC bits, then the frame shall be regarded as invalid. If the error is detected in uplink direction, then the TRAU shall perform error concealment as for any No_Data frame (see 3GPP TS 26.092). If the error is detected in downlink direction, then the BTS shall handle this with respect to the air interface as described in clause 6.5, respectively in 3GPP TS 48.060.
A No_Speech frame with the UFE set to "Uplink Frame Received with Errors" (if the error is detected in uplink), respectively a No_Speech frame with DFE set to "Downlink Frame Received with Errors" (if the error is detected in downlink) shall be sent back for every detected invalid frame. The other side, when receiving a No_Speech frame with the UFE, respectively DFE bit set shall respond with a No_Speech Frame, too, where the DFE respectively UFE bit is not set (unless the error occurred in both directions). In this way the fastest possible re-synchronisation shall be ensured. In case of ongoing TFO these frames may transmit the configuration parameters in addition (see 3GPP TS 48.062).
6.9.2.2 Handling of frames received with errors
In case of Half Rate speech and Data: Same as clause 6.9.1.2.
In case of Adaptive Multi-Rate speech: Same as clause 6.9.2.1.
6.10 Procedures for Operation & Maintenance
The general procedures for Operation and Maintenance are described in 3GPP TS 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.
6.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 for 16 kbit/s submultiplexing in clauses 5.1.3 and 5.1.4.3 and for 8 kbit/s submultiplexing in clauses 5.2.3 and 5.2.4 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.
6.10.2 Procedures in the TRAU
If O&M information between the TRAU and the BSC is transferred using O&M TRAU frames between the CCU in a BTS and the TRAU, the TRAU sends O&M TRAU frames periodically until the identical O&M TRAU frame is received as an acknowledgement. The period is at least 64*20ms (1,28 sec).
In case of fault conditions, when no immediate action is required, the TRAU may send O&M frames indicating the fault.
6.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.
6.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 in case of 16 kbit/s submultiplexing;
‑ 120 data bits in case of 8 kbit/s submultiplexing.
Any corresponding O&M message between the BSC and the BTS shall always carry:
‑ all 264 O&M data bits in case of 16 kbit/s submultiplexing;
‑ 120 data bits in case of 8 kbit/s submultiplexing.
6.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 all the data bits from the received frames into an appropriate O&M message and send it to the BSC.
If the CCU receives O&M TRAU frames during a speech or data call then the procedure described in clause 6.5 shall apply.
If receiving an O&M message from the BSC, carrying TRAU O&M information, the BTS puts all the 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 3GPP TS 12.21
In case of a faulty CCU, the O&M procedures are BTS internal.
Annex A (informative):
Change History
|
Change history |
|||||
|
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
New |
|
GP-04 |
– |
– |
– |
April 2001. Conversion to 3GPP layout and number. References have been updated. |
48.061 v4.0.0 |
|
GP-08 |
GP-020179 |
001 |
Correct synchronisation description for HR_AMR |
4.1.0 |
|
|
Editorial |
4.1.1 |
||||
|
GP-09 |
GP-020524 |
002 |
Generic Configuration Frames for TFO |
5.0.0 |
|
|
GP-23 |
Version for Release 6 |
6.0.0 |
|||
|
GP-35 |
Version for Release 7 |
7.0.0 |
|||
|
GP-40 |
Version for Release 8 |
8.0.0 |
|||
|
GP-44 |
Version for Release 9 |
9.0.0 |
|||
|
GP-49 |
Version for Release 10 |
10.0.0 |
|||
|
GP-55 |
Version for Release 11 |
11.0.0 |
|||
|
GP-63 |
Version for Release 12 (frozen at SP-65) |
12.0.0 |
|||
|
GP-68 |
Version for Release 13 (frozen at SP-70) |
13.0.0 |
|||
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2017-03 |
RP-75 |
– |
– |
– |
– |
Version for Release 14 (frozen at TSG-75) |
14.0.0 |
|
2018-06 |
RP-80 |
– |
– |
– |
– |
Update to Rel-15 version (MCC) |
15.0.0 |
|
2020-07 |
RP-88e |
– |
– |
– |
– |
Upgrade to Rel-16 version without technical change |
16.0.0 |
|
2022-03 |
RP-95e |
– |
– |
– |
– |
Upgrade to Rel-17 version without technical change |
17.0.0 |