4 Transmission characteristics

3GPP43.005Release 16Technical performance objectivesTS

4.1 General

4.1.1 BS-MSC path

The performance objectives of BS-MSC path are dependent on length of the link and therefore they will be decided on national basis. However, they should be fixed taken into account ITU-T Recommendation G.921.

4.1.2 MSC

The MSC should meet the transmission objectives of digital exchanges as specified in ITU-T Recommendation Q.551 and Q.554.

4.2 System delay distribution

3GPP TS 03.50 specifies an overall transmission delay objective throughout the PLMN for speech channels for reasons of subjective speech quality. Since this transmission delay objective includes several physical network elements, this section specifies transmission delay values allocated to each of them. Due to in-band protocols implemented in the GSM PLMN with timers running across several network entities, also the transmission delay for data channels must be limited and allocated to the physical network elements.

4.2.1 Speech channel delay

The main problem arising from an excessive delay occurs in a speech channel because of subjective effects of echo and simultaneous speech in both directions. To minimise these effects a both way speech delay of 180 ms between the Mouth Reference Point (MRP)/ Ear Reference Point (ERP) in the MS and the Point Of Interconnection (POI) with the PSTN/ISDN has been specified in 3GPP TS 03.50 as an objective for the GSM PLMN operator when constructing his network.

This delay for the full rate speech channel has been loosely allocated to the various system entities as follows and illustrated in fig 4/1 and fig 4/2. The detailed delay figures internal to a system entity are only indicative. The total delay allowance allocated to any of the system entities should, however, not be exceeded. The propagation delay through the PLMN is not included. It should be noted that even if the sum of allocated delay values may exceed 180 ms in some cases, the long-term objective is still to keep the overall PLMN transmission round-trip delay below 180 ms.

The allocated delay allowances are indicated as either system dependent or implementation dependent. By system dependent it is meant that the delay values are worst-case delay values given by system-given units of time, and cannot be changed. By implementation dependent it is meant that the values depend on the technology used, and that the values allocated have been fixed as upper bounds by realistic judgement.

NOTE: The various figures allocated to the various network entities given in these delay budgets are for guidance to network operators for network planning. It is up to the operator to provide other figures, if required.

MSC BSC BTS MS
│Techo margin│Tbsc Tsps margin│Tbuff margin│Trftx│Trxproc margin │
│ Tmsc │ Tsample Tabisd │ Tencode │ │ Tproc Td/a│
│……………│…………………….│……………│…..│………………│
├<───><───><───>┼<───><───><───><───><───>┼<───><───><───>┼<───>┼<───><───><───><─>┤
│ 1.0 0.5 0.5 │ 0.5 20.0 1.6 17.4 0.5 │ 1.25 1.6 0.45│ 37.5│ 8.8 1.5 3.0 1.0│
│ │ │ │ │ │
├<─────────────>┼<───────────────────────>┼<───────────────────>┼<────────────────>┤
│ 2.0 40.0 40.8 14.3 │
│ │
├<────────────────────────────────────────────────────────────────────────────────>┤
│ 97.1 │
NOTE: all figures in ms

Figure 4/1a: Downlink delay distribution for TCH/FS (16Kbit/s Abis)

MSC BSC BTS MS
│Tmsc │Tbsc margin │Tabisu margin│Trftx│Tencode Tsample Ta/d │
│ margin│ Tproc │ Trxproc │ │ Ttransc margin │
│……….│……………│……………│…..│…………………….│
├<───><───>┼<───><───><───>┼<───><───><───>┼<───>┼<───><───><───><───><───>┤
│ 0.5 0.5 │ 0.5 1.5 0.5 │ 4.0 8.8 3.0 │ 37.5│ 1.6 8.0 20.0 3.0 2.0 │
│ │ │ │ │ │
├<────────>┼<─────────────>┼<─────────────>┼<─────────────────────────────>┤
│ 1.0 2.5 15.8 72.1 │
│ │
├<────────────────────────────────────────────────────────────────────────>┤
│ 91.4 │
NOTE: all figures in ms

Figure 4/1b: Uplink delay distribution for TCH/FS (16 Kbit/s Abis)

MSC BSC BTS MS
│Techo margin│Tbsc │Tsample Tencode │Trftx│Trxproc margin │
│ Tmsc │ margin│ Ttransc margin│ │ Tproc Td/a │
│……………│……….│………………..│…..│………………..│
├<───><───><───>┼<───><───>┼<───><───><───><───>┼<───>┼<───><───><───><───>┼
│ 1.0 0.5 0.5 │ 0.5 0.5 │20.0 8.0 1.6 3.0 │ 37.5│ 8.8 1.5 3.0 1.0 │
│ │ │ │ │ │
├<─────────────>┼<────────>┼<────────────────────────>┼<──────────────────>┼
│ 2.0 │ 1.0 70.1 │ 14.3 │
│ │ │ │
│ ├<───────────────────────────────────>┤ │
│ 71.1 │
│ │
├<────────────────────────────────────────────────────────────────────────>┤
│ 87.4 │
NOTE: all figures in ms

Figure 4/2a: Downlink delay distribution for TCH/FS (64 Kbit/s Abis)

MSC BSC BTS MS
│Tmsc │Tbsc │Tproc margin│Trftx│Tencode Tsample Ta/d │
│ margin│ margin │ Trxproc │ │ Ttransc margin │
│……….│……….│……………│…..│…………………….│
├<───><───>┼<───><───>┼<───><───><───>┼<───>┼<───><───><───><───><───>┤
│ 0.5 0.5 │ 0.5 0.5 │ 1.5 8.8 3.0 │ 37.5│ 1.6 8.0 20.0 3.0 2.0 │
│ │ │ │ │ │
├<────────>┼<────────>┼<─────────────>┼<─────────────────────────────>┤
│ 1.0 │ 1.0 13.3 │ 72.1 │
│ │ │ │
│ ├<────────────────────────>┤ │
│ 14.3 │
│ │
├<───────────────────────────────────────────────────────────────────>┤
│ 87.4 │
NOTE: all figures in ms

Figure 4/2b: Uplink delay distribution for TCH/FS (64 Kbit/s Abis)

BSS internal delay values (indicative):

Tsample: The duration of the segment of PCM speech operated on by the full-rate speech transcoder (system dependent).

Trftx: The time required for transmission of a TCH radio interface frame over the air interface due to the interleaving and de-interleaving (given in table 4/2) (system dependent).

Tabisu: The time required to transmit the first 56 speech frame data bits (bits C12-C15, D1-D56 and 4 synchronization bits – 64 bits) over the 16 kbit/s A-bis-interface in the uplink direction (system dependent).

Tabisd: The time required to transmit the 260 speech frame data bits (bits D1-D260, C16 and 17 synchronization bits – 278 bits) over the 16 kbit/s A-bis-interface in the downlink direction (system dependent).

Tbuff: Due to the time alignment procedure for inband control of the remote transcoder in case of a 16 kbit/s A-bis-interface in the downlink direction, it is required to have a buffer in the BTS of 1 ms + one 250 us regulation step (system dependent).

Tbsc: Switching delay in the BSC (implementation dependent).

Ttransc: The speech encoder processing time, from input of the last PCM sample to output of the final encoded bit (implementation dependent).

Tsps: Delay of the speech encoder after reception of the last PCM sample until availability of the first encoded bit (implementation dependent).

Tencode: The time required for the channel encoder to perform channel encoding (implementation dependent).

Trxproc: The time required after reception over the radio interface to perform equalization, channel decoding and SID-frame detection (implementation dependent).

Tproc: The time required after reception of the first RPE-sample to process the speech encoded data for the full-rate speech decoder and to produce the first PCM output sample (implementation dependent).

BSS external delay values (indicative):

Techo: Delay due to the echo canceller.

Tmsc: Switching delay in the MSC.

4.2.2 Data channel delay

The service requirements on excessive transmission delays for data channels are not as stringent as for speech channels. However, two overall requirements apply:

1. Proper operation of the RLP protocol with the timers T1 and T2 residing in the MSC/IWF and in the MS/TA must be ensured, and thus the round-trip delay between those network entities must be low enough to avoid time-outs of the RLP retransmission timer T1 (Round-trip delay < T1 – T2). This applies to non-transparent data only.

2. Proper operation of any end-to-end acknowledged protocols must be ensured in a similar manner. This applies to all data channels.

The transmission delay requirements for data channels have been allocated to the various system entities as follows and as illustrated in figures 4/3 and 4/4, for transparent and non-transparent data separately, and the requirements in the budgets should apply to all full-rate or half-rate channels, whether synchronous or asynchronous. The contributions to the round-trip transmission delay seen by the RLP are also indicated. It should be noted that these concern the transmission delay part only, and that the timer T2 must be added in order to find the limits for T1. The detailed delay figures internal to a system entity are only indicative. The total delay allowance allocated to any of the system entities should, however, not be exceeded. The propagation delay through the PLMN is not included.

The allocated delay allowances are indicated as either system dependent or implementation dependent. By system dependent it is meant that the delay values are worst-case delay values given by system-given units of time, and cannot be changed. By implementation dependent it is meant that the values depend on the technology used, and that the values allocated have been fixed as upper bounds by realistic judgement.

It should be noted that the actual delay distribution for a specific data channel in most cases will have a lower total transmission delay than indicated in the budgets, which show the worst-cases.

It should also be noted that the budgets apply to perfect conditions, i.e. no errors over the radio path (implying no re-transmissions) and no flow control. It should be noted, however, that in a real life situation any errors on the radio path may increase the transmission delay and/or decrease the RLP throughput, and that the flow control buffer limits for XON/XOFF will under continuous flow control have a direct impact on the transmission delay, giving an additional delay contribution directly given by these buffer limits.

The following delay values are specific to data traffic channels:

Transparent data only:

Tchar: The time needed in the IWF and TA to receive a character at the user bit-rate in the transmit direction for bit-to-character conversion (given in table 4/3) (system dependent).

Tra0: The time required for buffering in the IWF and TA in the transmit direction for asynchronous-to-synchronous conversion and overspeed/underspeed detection and correction. This delay corresponds to Tchar above (given in table 4/3) (system dependent).

Tnic: The time needed in the IWF in each direction for buffering for Network Independent Clocking. This time corresponds to one V.110 frame (system dependent).

Non-transparent data only:

Tl2runit: The necessary time in the IWF and TA in the transmit direction to convert the incoming user data bit stream into interpretable data units, e.g. characters (character oriented without framing) or data frames (e.g. bit oriented data like HDLC) (system dependent).

Tl2rbuft: Worst-case delay in the IWF and TA in the transmit direction required for buffering in the L2R in order to assemble one PDU (system dependent).

Tprotpr: Processing time used in the IWF and TA by the L2R and the RLP in the transmit or receive direction (implementation dependent).

Trlpbuft: Worst-case buffering delay in the IWF and TA required by the RLP in the transmit direction in order to synchronize one PDU towards the radio interface transmission (system dependent).

Trlpbufr: Worst-case delay in the IWF in the receive direction required for buffering in the RLP in order to assemble one PDU, before checksum calculation can be carried out (system dependent).

Tl2rbufr: Worst-case buffering delay in the IWF and TA required by the L2R in the receive direction in order to synchronize one PDU with the L2R user (system dependent).

Transparent and non-transparent data:

Tiwfpr: Processing time in the IWF in the downlink or in the uplink direction (implementation dependent).

Tabisf: Worst-case delay over the A-bis-interface due to non-synchronized A-bis-interface transmission. This delay corresponds to one TRAU frame (system dependent).

Tdframe: Additional delay to Tabisf in the downlink direction in order to receive a full radio interface data TCH frame over the A-bis-interface, so that channel encoding can start. The data TCH frame length is given in table 4/1and Tdframe is summarized in table 4/4 (system dependent).

Talignd: The time needed to wait in the downlink in order to align the received data over the A-bis-interface to the radio interface TDMA frame structure. This time corresponds to one TDMA-frame for full-rate channels and two for half-rate channels (system dependent).

Tframe: Delay in the uplink direction in the MS in order to receive a full radio interface data TCH frame over the user interface, so that channel encoding can start. The data TCH frame length is given in table 4/1 (system dependent).

Tdbuff: Additional buffering needed in the TA in the uplink direction with respect to Tframe allowing a total buffering of four V.110 frames. The V.110 frame length is given in table 4/1, and Tdbuff is summarized in table 4/4 (system dependent).

Talignu: The time needed to wait in order to align the received uplink data over the user interface to the radio interface TDMA frame structure. This time corresponds to one TDMA-frame for full-rate channels and two for half-rate channels (system dependent).

Ttaprocd: Processing time required in the TA in the downlink direction for terminal adaptation (implementation dependent).

Ttaprocu: Processing time required in the TA in the uplink direction for terminal adaptation (implementation dependent).

Other delay values indicated in the budgets for data traffic channels are defined as for speech channels. Margins are allocated to each system entity for the total implementation dependent part of the delay contributions, considering the amount of processes in each entity and the amount of data processed. Those operations not included explicitly in the budget are considered only to add minimal delays and are thus considered to be covered by the margins.

The data channel delay budgets for a 64 kbit/s and a 16 kbit/s A-bis-interface are essentially the same, the only difference being a reduction in rate adaptation functions in the 64 kbit/s case and a possible non-synchronized transmission over the 16 kbit/s A-bis-interface (Tabisf). Thus only the 16 kbit/s A-bis-interface is illustrated, and for this option only the worst-cases. The budgets in figures 4/3 and 4/4 apply, hence, also to the case of a 64 kbit/s A-bis-interface. For the case of the integrated BSS the delay budget for the BSS shall contain the sum of the allowances for the BSC and the BTS.

Table 4/1: Radio interface and V.110 frame lengths for traffic channels

Traffic channel:

Frame length (ms):

Radio int. (z):

V.110 (r):

TCH/FS

20

TCH/HS

[tbd]

TCH/F9.6

20

5

TCH/F4.8

20

10

TCH/H4.8

40

10

TCH/F2.4

0

10

TCH/H2.4

40

10

Table 4/2: Interleaving/de-interleaving delay for traffic channels

Traffic channel:

Interleaving/deinterleaving

(TDMA-frames/timeslots):

delay (y) (ms)

TCH/FS

7+1/1

37,5

TCH/HS

[tbd]

[tbd]

TCH/F9.6

18+3+2/1

106,8

TCH/H4.8

18+3+2/1

106,8

TCH/F4.8

36+6+4/1

212,9

TCH/F2.4

7+1/1

37,5

TCH/H2.4

36+6+4/1

212,9

NOTE: As an example, the TCH/F9.6 has an interleaving depth of 19, resulting in a delay of 18 TDMA-frames and 1 timeslot. Due to the block diagonal interleaving scheme where 4 user data blocks are channel encoded together, it may in the worst-case be necessary to wait for all the 4 subblocks spread over 3 additional TDMA-frames before channel decoding. The channel encoded block will also span a maximum of 2 SACCH frames.

It may be possible, in practice, to reduce the interleaving delay, Trftx, by processing information before the complete data block is received over the air interface. It may also be possible, in practice, to reduce the impact of Tframe by transmitting information over the air interface before the complete data block is encoded. However, due to the less stringent delay requirements on data transmission than on speech transmission, this is considered to unnecessarily constrain the implementation options.

Table 4/3: Delays for bit/character conversion (11 bits)

Ruser

Tchar (x):

75 bit/s

146,7 ms

300 bit/s

36,7 ms

1 200 bit/s

9,2 ms

2 400 bit/s

4,6 ms

4 800 bit/s

2,3 ms

9 600 bit/s

1,2 ms

Table 4/4: Tdframe and Tdbuff given for various TCH types

Traffic channel:

Tdframe (u):

Tdbuff (v):

TCH/FS

TCH/HS

TCH/F9.6

0 ms

0 ms

TCH/F4.8

0 ms

20 ms

TCH/H4.8

20 ms

0 ms

TCH/F2.4

0 ms

20 ms

TCH/H2.4

20 ms

0 ms

NOTE: The various figures allocated to the various network entities given in these delay budgets are for guidance to network operators for network planning. It is up to the operator to provide other figures, if required.

The delay value TL2runit has been included in figure 4/4b as "w" ms. No table with values for "w" has been included in the present document since these values will depend on the type of data units the incoming user data bit stream shall be converted into (e.g. conversion into characters or HDLC frames).

Figure 4/3a: Worst-case downlink delay distribution for data TCH (transparent data)

Figure 4/3b: Worst-case uplink delay distribution for data TCH (transparent data)

NOTE: All figures are in ms. The values of x, y, r, u and v depend on the user bitrate, ranging from 75 – 9600 bit/s, and the data TCH type.

Figure 4/4a: Worst-case downlink delay distribution for data TCH (non-transparent data)

Figure 4/4b: Worst-case uplink delay distribution for data TCH (non-transparent data)

NOTE: All figures are in ms. The values of y, z, u, v and w depend on the data TCH type and the L2R user protocol. TRLP, diwf and TRLP, uiwf are the transmission delays seen by the RLP in the IWF in the downlink and uplink respectively. It should be noted that the corresponding transmission delays seen by the TA are given by a symmetrical assessment, but are not identical. The sum of the two, however, is the same.

Annex A (informative):
Change Request History

Date

TSG #

TSG Doc.

CR

Rev

Subject/Comment

New

2004-12

SP#26

Upgraded to Release 6

6.0.0

2007-06

CT#36

Upgraded unchanged from Rel-6

7.0.0

2008-12

CT#42

Upgraded unchanged from Rel-7

8.0.0

2009-12

Update to Rel-9 version (MCC)

9.0.0

2011-03

Update to Rel-10 version (MCC)

10.0.0

2011-03

Update to Rel-11 version (MCC)

11.0.0

2014-09

Update to Rel-12 version (MCC)

12.0.0

2015-12

CT#70

Update to Rel-13 version (MCC)

13.0.0

2017-03

CT#75

Update to Rel-14 version (MCC)

14.0.0

2018-06

CT#80

Update to Rel-15 version (MCC)

15.0.0

2020-07

CT#88e

Update to Rel-16 version (MCC)

16.0.0