MEMO TNP/APAC Thomas Quick

1 (4)

13.7.2000

"SDCCH drop" problem solved in Nokia Area

1. INTRODUCTION
Since it was agreed with AIS that the SDCCH drop rate will be reported as a KPI (key performance indicator) figure, it has been recognized that this value is rather high compared to other suppliers, typically at a regional level of ca. 1015%. Nokia has performed a series of tests to investigate the problem. One finding was that the value was very high in satellite Abis connections, what was explainable due to the satellite Abis settings. Another investigation showed that this problem typically occurs in road coverage sites, where the majority of the drops are caused by failed location update calls. Recent trials have now revealed the general nature of the problem. This memo explains this and gives some suggestions for its solution.

2. CALL SETUP PROCEDURE IN GSM

To understand the problem explanation, it is needed to review the initial call setup procedure (layer 3 protocol) in GSM. It is sketched in Figure 1. CHANNEL_REQUEST CHANNEL_REQUIRED CHANNEL_ACTIVATION CHANNEL_ACTIVATION_ACK IMMEDIATE_ASSIGNMENT_COMMAND IMMEDIATE_ASSIGNMENT SABM: CALL SETUP T3101 ESTABLISH_INDICATION

MS

BTS

BSC

Figure 1: Initial call setup phase in GSM

The call setup starts with the CHANNEL_REQUEST message which is sent by the mobile station (MS) on the random access channel (RACH). This is the case both for a mobile originating call and in response to a paging message. The request is received as CHANNEL_REQUIRED message in the BSC, which in turn activates the SDCCH resource in the BTS (through the CHANNEL_ACTIVATION command which is acknowledged by the BTS). From this point onwards, the SDDCH channel is occupied by the base station system (whether it will be used or not). To tell the MS to tune to the related SDCCH, the BSC sends the IMMEDIATE_ASSIGNMENT command on the access grant channel (AGCH) to the MS, which finally establishs the signalling connection by returning the reason for the establishment on the SDCCH (in the figure above, this is

MEMO TNP/APAC Thomas Quick

2 (4)

13.7.2000

shown for a call setup; another reason might be answer to paging or location update). This is done by means of a SABM (set asynchronous balance mode) message as part of the LAPD protocol. Hence, this is the very first time the reserved SDCCH will be used. As can be seen further, the BSC monitors the protocol by starting a timer (called T3101 in GSM) upon sending the IMMEDIATE_ASSIGNMENT command. T3101 checks the expected answer from the MS which is forwarded by the BTS as ESTABLISH_INDICATION message.

3. PERFORMANCE MEASUREMENT OF THE SDCCH DROP RATE

If the traffic measurement is activated in BSC and NMS/2000, the correct functioning of the LAPD protocol (this is the layer 2 protocol) while using an SDCCH is watched by a performance measurement counter called sdcch_abis_fail_call, which counts the failures in the protocol in case it led to an SDCCH drop. It is used in the agreed KPI formula for the SDCCH drop rate [1]. This counter has been seen to be responsible of the majority of the experienced SDCCH drops. In case if the T3101 counter expires, meaning that the BSC sends an IMMEDIATE_ASSIGNMENT message, but the MS doesn't reply with a establish indication, this is also considered as a failure counted by sdcch_abis_fail_call, though the SDCCH hasn't been used at all in this particular case. Since BSS SW version S7, a new counter is available as part of the service level measurement, which counts the T3101 expiries extra. The name of this counter is t3101_expired. A recent investigation revealed that the counts of t3101_expired is very close to the ones of sdcch_abis_fail_call, meaning that most of the drops are coming from T3101 expiries. As an example, Figure 2 shows the KPI data for the recent days for the complete Western region, whereas Figure 3 gives the situation with the t3101_expired counter minused from the number of SDCCH drops in the KPI formula. The results show clearly that the described problem case is dominant in the whole Western region. With the modification in the KPI formula, the SDCCH drop rate (SDR) is lower than the TCH drop rate (call drop rate, CDR). Tests in the Northern and Southern region revealed the same findings.
12 50 45 10 8 6 4 2 0 40 35 30 25 20 15 10 5 0
Erlmin/drop

CDR, SDR, HOFR [%]

00

00

00

00

00

00

00

00

00

00

.2 0

.2 0

.2 0

.2 0

.2 0

.2 0

.2 0

.2 0

.2 0

.2 0

CDR SDR HOFR

.0 6

.0 6

.0 6

.0 6

.0 6

.0 7

.0 7

.0 7

.0 7

26

27

28

29

30

01

02

03

04

Figure 2: KPI measurements based on the agreed KPI formulas

05

.0 7

Erlang minutes per drop

MEMO TNP/APAC Thomas Quick

3 (4)

13.7.2000

12

50 45 40 35 30 25 20 15 10 5 0
Erlmin/drop

CDR, SDR, HOFR [%]

10 8 6 4 2 0

00

00

00

00

00

00

00

00

00

00

.2 0

.2 0

.2 0

.2 0

.2 0

.2 0

.2 0

.2 0

.2 0

.2 0

CDR SDR HOFR

.0 6

.0 6

.0 6

.0 6

.0 6

.0 7

.0 7

.0 7

.0 7

26

27

28

29

30

01

02

03

04

Figure 3: KPI measurements with modified KPI formula for SDCCH drop rate

4. PROBLEM EXPLANATION
There are three major causes which lead to T3101 expiries: 1. Handover RACH bursts: in networks with very tight frequency re-use, it can happen that the BTS accidentally receives RACH bursts which have been send by the MS to another target BTS during a handover procedure. They are interpreted as CHANNEL_REQUEST messages for a call setup. This can be avoided through careful BSIC planning. Anyway, in our case, this cause can be excluded, as the problem appears in rural areas as well. 2. "Ghost" accesses: increased noise in an BTS receiver, uplink interference etc. can be interpreted by the BTS as CHANNEL_REQUEST message, if a certain bit pattern is recognized. The Nokia BSC is capable to distinguish bit patterns which indicate invalid establishment causes and supports a counter which registers this events as ghost accesses. This cause can also be excluded as the counted ghosts are, in general, negligible compared to the T3101 expiry counts. 3. Multiple RACH sent by MS: in case the MS doesn't receive an IMMEDIATE_ASSIGNMENT command within a certain period after sending the CHANNEL_REQUEST message, it sends further RACHs (depending on the network settings; the related parameter controls the maximum number of RACH retransmissions: MAX_RETRANS). The BSC might complete the protocol for one of the sent RACH, but another one might be interpreted as another call setup where the MS will never answer the IMMEDIATE_ASSIGNMENT message. This is the case which serves as a general SDCCH problem explanation for the AIS network. In general, the T3101 expiries can not be counted as SDCCH drops, as the SDCCH has not even yet been established. The unsuitable recognized RACHs could, however, lead to SDCCH blocking.

5. PROPOSED SOLUTION
As the described problem is not in conjunction with real SDCCH drops, it is required to make the mentioned modification in the SDCCH drop formula. The modified script is already available and can be replaced. The additional occupied SDCCH are not causing any harm to the system unless they are leading to SDCCH blocking. Thus, the SDCCH blocking will be monitored as part of the optimization process.

05

.0 7

Erlang minutes per drop

MEMO TNP/APAC Thomas Quick

4 (4)

13.7.2000

Generally, a suitable way to avoid SDCCH blocking is using Nokia's dynamically SDCCH feature, which configures additional SDCCH timeslots automatically if required. This feature is available in all regions. Another option is modifiying the control channel (CCCH) parameters. In Nokia, the default setting of the MAX_RETRANS parameter mentioned above is set to 4, so it might be reduced to values down to 2 or even 1. Further parameters might be considered for modification as well. As the multiple RACH problem occurs typically under weak radio conditions, it is likely that a modification of the MAX_RETRANS parameter leads to an exclusion of cell fringe subscribers, though in a more gentle way than compared to a modification of the RX_LEV_ACCESS_MIN value which blocks subscribers in accessing the network by requiring a minimum received signal strength. In either way, the number of calls should be carefully monitored before and after implementation of the change, and on the actual result, it can be decided to accept improvements in quality with compromises in subscriber numbers, or reverting back to the old settings and accepting the blocking unless this can be catered by measures like sectorization or additional sites.

6. REFERENCES
[1] [2] [3] Customized Network doctor script #779 Nokia document (Thomas Quick, Version 1.3) Nokia NMS/2000: Database description for BSC measurements Nokia document NTC TAN 0422/3 en Network doctor: User's guide Nokia document NTC TAN 0935/2.1 en