cssr abd sdcch drops updated-libre

8/9/2019 CSSR Abd SDCCH Drops Updated-libre

1/48

"SDCCH Success Rate" formula definition

Number/Version Date Page

DN00284467/1.0 eng 23/11/2000 2(49)

Company Confidential

CONTENTS

1 PURPOSE OF THIS DOCUMENT 4

2 INTRODUCTION 5

2.1 SDCCH channel and "service setup" 5

2.2 Logical meaning of the indicator 5

2.3 Two different approachs 6

2.3.1 SDCCH Success Rate for call 6

2.3.2 SDCCH Success Rate in overall case 6

2.4 Analysis method 7

3 MAIN CALL PHASES 8

4 CALL SIGNALLING AND COUNTERS INCREMENTED 9

4.1 Overview 9

4.2 Signalling analysis 9

4.2.1 PART 1: channel request (#1) and channel required

(#2) 13

4.2.2 PART 2: from channel activation (#3) to immediate

assignment (#6) 16

4.2.2.1 Automatic retransmission of the RACH 17

4.2.3 PART 3: from CM service request (#7) to physical

context confirm (#39) 19

4.2.4 PART 4: TCH activation (#40) and assignment

command (#42) 23

4.2.5 PART 5: TCH seizure 23

5 SMS SIGNALLING 24

6 SDCCH Blocking 26

7 SDCCH Success Rate for call 27

7.1 Notes 29

8 SDCCH success rate in overall case 30

8.1 Overview 30

8.2 Counter 1075 "sdcch_abis_fail_call" 31

8.3 Ghost random accesses 32

8.4 Double reservations: RACH repetition (congestion or

coverage problem) 33


2/48



DN00284467/1.0 eng 23/11/2000 3(49)


8.5 BCCH frequency-BSIC reuse 35

8.6 Bursts of random accesses (HO access), frequency-BSIC

reuse distance 35

8.7 "channel activation not acknowledgement" message failure 36

8.8 FORMULA 37

9 APPENDIX: Counter 1078 "sdcch_a_if_fail_call" and A interface

blocking 41

10 Table 2: Counters involved in the SDCCH Success Rate for call 42

11 Table 3: Counters involved in the SDCCH Success Rate in the

overall case 43

12 Table 4: Counters indicated in the flowchart of the SDCCH

assignment with the features dynamic SDCCH allocation andFACCH call setup 46

13 References 48

14 DOCUMENT REVISION HISTORY 49


3/48



DN00284467/1.0 eng 23/11/2000 4(49)


1 PURPOSE OF THIS DOCUMENT

This document is aimed at analysing the behaviour of BSC statisticalcounters concerning the SDCCH signalling during a service. The purpose is

to define an indicator that can be utilized to monitor the performance of the

network during the signalling on the SDCCH channel, providing a proposal

of new formulas aimed at getting near the subscriber viewpoint as much as

possible.


4/48



DN00284467/1.0 eng 23/11/2000 5(49)


2 INTRODUCTION

2.1 SDCCH channel and "service setup"

The signalling transported on the SDCCH channel is aimed at

reaching the service requested by the Mobile Station; in some cases this

represents only the setup of the service, in other cases the service is

completely performed on the SDCCH channel.

Considering a call for example, the SDCCH signalling contains the

messages for the setup of the service required, that is the exchange of

information between the Mobile Station and the network in order to create

the call scenario; considering a SMS, all the signalling during the service istransported on the SDCCH channel. In both of the cases the initial signalling

for accessing the network by a Mobile Station requiring a service is

transported on the SDCCH channel.

In this document the expression "service setup" is referred generally to

the phase of signalling in which the information between the MS and the

BTS is transported on the SDCCH channel.

The percentage of service dropped during the setup is an important

indicator to monitor the quality of a network because it can show how well

the network is able to lead the subscriber to access the service. Many

scenarios may occur to a mobile subscriber hampering the access to the

network; the coverage, the interference level and the efficiency of the

equipment in the signalling are the main responsible of the value assumed

by the indicator.

The indicator is reliable if it shows what the subscriber perceives. In

the present document the estimation of the drops occurred during the service

setup phase is made; the aim is to evaluate the goodness of the accessibility

as perceived by the subscriber. Not a unique definition is found for this

indicator because of the different observation points of view.

2.2 Logical meaning of the indicator

The logical meaning of the indicator is the ratio between the amount

of service setups correctly terminated in the network and the amount of

service requests:

requestsserviceof N.

correctlyperformedsetupsserviceof N.=indicator


5/48



DN00284467/1.0 eng 23/11/2000 6(49)


The service setup leads to access the service requested by the

subscriber and it consists of the signalling on SDCCH channel. This is

always the first step for accessing the network by a Mobile Station.

The indicator that will be defined measures the successful transactions

on SDCCH channel allocated for the request of a new service.

2.3 Two different approachs

The SDCCH phase is a wide part of the signalling because it is the

first step for accessing the network for all the services requested by a MS.

Considering the performance of the network during the setup of a

service, it is possible to distinguish between the success of the setup in case

the service is a call or in case it is whatever service. By this way it is

possible to monitor the failure rate perceived only by the subscribersrequiring a call rather than all the subscribers independently of the service

they required.

In this document two different formulas will be defined in order to

monitor the SDCCH signalling in the two mentioned cases.

2.3.1 SDCCH Success Rate for call

The first case will consider the performance of the SDCCH signalling

only when the service is a call, that is the MS requires the service for a call

and the aim of the SDCCH transaction is the setup of the call. The indicatormonitoring this case will be named "SDCCH Success Rate for call":

requestscallof N.

callforsactionsSDCCH transuccessfulof N.

requestscallof N.

setupscallsuccessfulof N. callfor

=

== SSR

2.3.2 SDCCH Success Rate in overall case

The second case will consider the SDCCH signalling working for all

the possible services (call included); in this case the MS could require a

service as call, SMS, Location Update, IMSI detach and Supplementary

Service.

The name of the indicator that will be defined in this case is "SDCCH

Success Rate in overall case" or, simply, "SDCCH Success Rate":


6/48



DN00284467/1.0 eng 23/11/2000 7(49)



sactionsSDCCH transuccessfulof N.


setupsservicesuccessfulof N.

=

==SSR

2.4 Analysis method

In order to implement the definition and make operative the indicator,

it will be necessary to "translate" its definition into a formula composed by

the counters of the NMS database. In order to understand the meaning of a

counter it is necessary to know the condition incrementing the counter.

It is necessary to find a formula counting all events in a certain points

of the signalling phase of the service.

For this purpose an analysis concerning the signals exchanged during

the SDCCH phase among the equipment MS, BTS, BSC and MSC will be

performed (chapter 4); the counters triggered in correspondence of the

meaningful (for the definition of the indicator) signals will be described.

Moreover, the description of the critical cases incrementing the

SDCCH failure counters will be provided (chapter 8.2 and 9) in order to

make clearness about the inputs of the formula.


7/48



DN00284467/1.0 eng 23/11/2000 8(49)


3 MAIN CALL PHASES

Our analysis will start considering the signalling related to a call,because it is the service required by the subscriber most frequently.

Considering the call service, it is possible to divide it in logical phases

in order to monitor the performance of the network in correspondence of the

most critical steps.

In Figure 1 these phases are reported together with the name of the

related statistic monitoring the performance in the specific phase. The call

phases reported in the figure concern the SDCCH and TCH blocking, the

success rate during the SDCCH signalling related to a call and the drop call

rate.

Figure 1: Main call phases

As mentioned above, purpose of this document is to define the

SDCCH success rate both considering only the SDCCH related to a call(SDCCH Success Rate for call) and considering all the SDCCH channels

managed by the Radio Resource Manager in obtaining the service (SDCCH

Success Rate in overall case).

In order to achieve the aim, the signalling of the phase marked by dark

grey in Figure 1 (indicated as "establish SDCCH connection") will be

analysed in detail in chapter 4.

For completeness, also the definition of the indicator SDCCH blocking

(related to the phase "get SDCCH", marked by clear grey) will be provided

during the analysis in chapter 6.


8/48



DN00284467/1.0 eng 23/11/2000 9(49)


4 CALL SIGNALLING AND COUNTERS INCREMENTED

4.1 Overview

In order to define the SDCCH indicators mentioned in the chapter 3,

our investigation starts from the analysis of SDCCH signalling flow during

the Mobile Originated.

The SDCCH analysis that will be performed considering the MOC

signalling could be done also by considering the Mobile Terminated Call

protocol; the only difference is the paging message sent from the BTS to the

MS before the channel request (Figure 2, signal 1) is sent from the MS, but

this kind of message doesn't affect the SDCCH logical channel because it is

transported on the PCH channel.By this way the indicator related to the SDCCH success rate during the

call setup will be defined.

Some messages of the call protocol are common to the signalling of

the other services; starting from the signalling related to the call, it will be

possible to mark these signals and the related counters in order to introduce

also the definition of the indicator related to the overall case (i.e. not only

call related).

4.2 Signalling analysis

In the following three figures (Figure 2, Figure 3, Figure 4) theprotocol of the MOC signalling from the SDCCH up to the seizure of the

TCH is reported.

The signalling has been divided in five logical parts in order to

individuate the most meaningful signals depending on the indicator to be

defined and on the counters we want to study. The five parts include:

PART 1: radio access part up to SDCCH blocking

PART 2: radio access part after SDCCH blocking

PART 3: establishment part, authentication, ciphering and encryption

PART 4: TCH request

PART 5: TCH seizure

The meaning of the logical parts individuated within the signalling

(PART 1, .., PART 5) is described in the following sections (from 4.2.1 to

4.2.5).

The counters involved in the definition of the indicators are reported

in correspondence of the signal in which they are incremented. The counters

are indicated by the name and the number of the NMS2000 database.


9/48



DN00284467/1.0 eng 23/11/2000 10(49)


Figure 2: Signalling of Mobile Originated Call


10/48



DN00284467/1.0 eng 23/11/2000 11(49)


PART 3

Figure 3: Signalling of Mobile Originated Call


11/48



DN00284467/1.0 eng 23/11/2000 12(49)


Figure 4: Signalling of Mobile Originated Call up to "TCH seized" phase


12/48



DN00284467/1.0 eng 23/11/2000 13(49)


4.2.1 PART 1: channel request (#1) and channel required (#2)

The PART 1 of the signalling reported in Figure 2 consists of the

beginning of the radio access to the network required by the MS. Thechannel request message is sent from the MS to the BTS and the BTS sends

the channel required message to the BSC.

This is always the first step for accessing the network. This part of

signalling is performed for every MS accessing a service, independently

on the kind of service required, meaning that it is valid also for all the

other services (not call) the MS can ask: SMS, Location Update, IMSI

detach, Supplementary Service.

The channel request (#1) message is used by the MS for requesting a

dedicated signalling channel SDCCH. The MS sends the channel request

message to the BTS on the RACH channel, and then this message is notinvolved in the SDCCH signalling. Its content will be described because

needed in order to understand the "ghost rach" during the definition of the

SDCCH blocking (chapter 6).

The content of this message consists of 8 bits; 3 bits are reserved for

the establishment cause and 5 bits for the random reference:

• establishment cause (3 out of 8 bits)among the 8 possible combinations of these 3 bits, 5 are valid as

establishment causes:- answer for paging (Mobile Terminated Call)

- emergency call- call re-establishment

- user requests (Mobile Originated Call, Short Message Service,

supplementary services)

- other services (Location Update, IMSI detach indication)

the other 3 combinations are not valid and then refused by the

network;

• random reference selected by the MS (5 out of 8 bits)- these 5 bits are randomly selected by MS. The usage of random reference

is when two MSs access the network exactly the same time; they can be separated

by using the random reference.

After the channel request has been received, the BTS forwards the

channel request generated by MS to the BSC sending the channel required

message (#2). The channel required contains the same information as

channel request with additional information added by the BTS.

The channel required message from the BTS includes the following

data:

- message discriminator: common channel management;

- message type: channel required;

- channel nr: uplink CCCH (RACH);


13/48



DN00284467/1.0 eng 23/11/2000 14(49)


- request reference: establishment cause, random reference received in the access

request and the frame number on which it was received;

- access delay: delay of the access burst as measured by the BTS.

After the BSC received the channel required message it proceeds inthis way:

• if the establishment cause is valid (5 valid cases out of 8 casesmentioned above) the BSC starts searching for a SDCCH channel

and the counters sdcch_seiz_att #1000 is incremented:

• if the channel is available in the cell where the originalaccess came from, it is reserved; the counter sdcch_assign

#1007 is triggered and the signalling described in the PART

2 starts;

• if the SDCCH channel is not available, the MS cannot accessthe service, the immediate assignment rejected message (see

PART 2) will be sent to the MS (if SDCCH dynamic

allocation and/or FACCH call setup are active, see Figure 5),

and the counter sdcch_busy_att #1001 is incremented;

• if the establishment cause is not valid (3 cases out of 8 casesmentioned above) the BSC doesn't proceed with the signalling and

the counter ghost_ccch_res #3030 is incremented.

If the SDCCH channel is not available, the research can be extended

by using the two features SDCCH dynamic allocation (S7) and FACCH call

setup (S5). The flowchart describing the steps followed by the process incase these features are activated is reported in Figure 5. On the arrows the

most important counters incremented after the signals moving to a new

condition of the flowchart are indicated. The logical steps performed by the

signalling described in this section are within the dashed block named

"PART 1". The block of the flowchart named "PART 2, PART 3" means

that all the signalling of the logical parts 2 and 3 of Figure 2 is performed in

that point.

Note that in case queuing and/or direct retry started, no SDCCH HO is

possible for leaving the cell.

Considering the signalling and the counters analysed in this section it

is possible to define the SDCCH blocking indicator; in the chapter 6 the

formula evaluating the block on the SDCCH channel met by the MS

accessing the network is provided.


14/48



DN00284467/1.0 eng 23/11/2000 15(49)


est. cause

valid?

RACH is a

ghost detected

SDCCH

available?

dyn. SDCCH

allocation?FACCH?

FACCH

successful?

OUT

TCHPART 2,

PART 3TCH

congestion?

queuing or/and

DirRetry?queuing or DR

successful?

dyn. SDCCHallocation

successful?

RACH

3004

YES1000

NO

3030

NO

YES

1007

NO

1001

YES

1154

YES

1007

NO

1001,1155

NO

YES

1010,1043,

1098

YES1099,

1125(fullrate)

1126(halfrate)

NO

NO1009

YES

NO

YES

NO

YES

1010,

1026

PART 1

SDCCH HO not possible

at this point

Figure 5: Flowchart of the call setup with SDCCH dynamic allocation and FACCH call

setup

Here the name of the counters indicated by the number in the

flowchart is reported, a more accurate explanation is provided in the chapter

12.

COUNTER NUMBER COUNTER NAME

1000 sdcch_seiz_att

1001 sdcch_busy_att

1009 tch_norm_seiz

1010 tch_request1026 tch_call_request

1125 tch_succ_full_seiz_fast_call

1126 tch_succ_half_seiz_fast_call

1043 tch_fast_req

1154 sddch_dynamic_reconf_att

1155 sdcch_unsucc_imm_assign_att

1098 tch_seiz_att_due_sdcch_con

1099 tch_seiz_due_sdcch_con

3004 ch_req_msg_rec

3030 ghost_ccch_res


15/48



DN00284467/1.0 eng 23/11/2000 16(49)


4.2.2 PART 2: from channel activation (#3) to immediate assignment (#6)

In this section the signals included in PART 2 of Figure 2, needed for

concluding the radio access to the network, will be described.After a successful reservation of a new SDCCH channel, the BSC

activates it by sending the channel activation message (#3) to the BTS

including the following data:

- message discriminator: dedicated channel management;

- message type: channel activation;

- channel number;

- activation type;

- channel mode: DTX control and channel type;

- MS power: maximum MS power level authorised in the cell.

Three events may happen:

1) A successful case is acknowledged by the BTS with channel

activation acknowledgement message (#4). The BTS will starts the

transmission and reception on the associated SACCH using the power levels

and the timing advance received in the channel activation message.

2) The BTS refuses to activate the new channel, it sends the channel

activation not acknowledgement message to the BSC with the reason of the

failure. Possible failure causes are the following:

- radio resource not available;

- radio channel already activated/allocated;

- protocol error and subclause, such as mandatory information error;

- O&M intervention in cases when the channel cannot be used for O&M

reasons;

- ciphering algorithm not supported;

- Equipment failure;

- Service or option not available.

In this case the counter sdcch_act_fail_call #1072 is incremented;

note that this failure can occur before the SDCCH channel is obtained by the

MS, so it won't be included in the SDCCH failure causes.

3) The GSM timer T9103 is used for supervising the channel

activation procedure. If the BSC does not receive the channel activation

ack/nack message within the time limit of the timer T9103, the timer expires

and the counter sdcch_abis_fail_call #1075 will be incremented (see Figure

14). An accurate analysis of the cases incrementing this counter will be

performed in the chapter 8.2.


16/48



DN00284467/1.0 eng 23/11/2000 17(49)


If the timer T9103 expires or if it has received the channel activation

not acknowledgement message, it releases the allocated channel by sending

the procedure of assignment failure to the MSC.

After a successful SDCCH channel activation, the BSC sends the

immediate assignment command message (#5) to the BTS (see Figure 2).

The information transported in this message contains the complete

immediate assignment message (#6) which is sent by the BTS to the MS on

the AGCH channel containing the following data:

- SDCCH channel number.

- message header;

- page mode: normal paging;

- channel description of the SDCCH allocated and the associated SACCH and

hopping frequency;

- request reference as sent by the MS in the Channel Request;

- initial timing advance;- mobile allocation if frequency hopping is used;

- rest octet only for the GSM phase 2.

The BSS informs the MS on AGCH channel about the SDCCH

channel to be used by using immediate assignment message. In practice, this

message is an order from the network to the MS to move to the SDCCH

channel defined before.

The GSM timer T3101 is used to supervise the immediate assign

procedure. If the SDCCH channel reservation or activation has failed, the

BSC sends the immediate assignment reject message to the MS.

4.2.2.1 Automatic retransmission of the RACH

When the mobile has sent the channel request message (#1) on the

RACH channel, it expects an answer from the network within a certain

period. The MS starts the timer T3120 and waits for the answer ( immediate

assignment or immediate assignment reject ).

If the MS doesn't receive the answer within the time limit defined by

the timer T3120, the MS makes a new attempt and sends another channel

request message with a new random reference on the next time slot. A new

value of timer T3120 is computed and used. The MS repeats this process

either until it is granted access or until the maximum number of repetitionsis reached; the network broadcasts the maximum repetition number.

If the service has been requested by the user pressing the "request

button" on the phone (4th

case of the establishment cause mentioned in the

section 4.2.1), the subscriber doesn't perceive these retransmissions of the

RACH channel.


17/48



DN00284467/1.0 eng 23/11/2000 18(49)


For example, if the maximum number of automatic retransmissions is

5, after the user pressed the button on the MS in order to obtain the service,

the MS will try automatically to access the network (up to 5 consecutive

times) if it doesn't receive the answer on the AGCH (Access Grant Channel)

within the period fixed by the timer T3120.

The subscriber doesn't perceive the first four failures, he will have to

push again the button the phone only after the last failure.

This phenomenon leads to a big value of a counter related to SDCCH

failures in Abis interface that are not perceived by the subscriber. This

subject will be discussed also in the chapter 8.4 considering the issue of the

SDCCH failure in Abis interface.


18/48



DN00284467/1.0 eng 23/11/2000 19(49)


4.2.3 PART 3: from CM service request (#7) to physical context confirm (#39)

When the MS has performed the radio access phase (i.e. it received the

immediate assignment from the BTS), the signalling proceeds with theestablishment phase, the authentication procedure, the ciphering and

encryption reported in the PART 3 (Figure 2, Figure 3, Figure 4).

In this section the establishment part will be analysed in detail in order

to mark the messages and the counters needed for the SDCCH success rate

formula.

After receiving the immediate assignment (#6) message, the MS tunes

to the assigned SDCCH and starts to establish the signalling link across the

network. The MS sends the layer 2 SABM to the BTS on the SDCCH. The

SABM contains the layer 3 CM service request message (#7) in which the

MS specifies the service type required to the network.The service request message includes one of the following

informations:

1.CM Service Request - for Mobile Originated calls and Mobile originated SMS- header;

- CM service type: mobile originated call, short message service, supplementary

services, emergency call;

- Ciphering key sequence number;

- MS classmark 2;

- mobile identity.

2. Location Update Request

3. IMSI Detach Request

4. Paging Response - mobile terminated call or SMS mobile terminated:

- header;

- Ciphering key sequence number;

- MS classmark 2;

- mobile identity.

5. CM_Re-establishment Request

The BTS forwards the MS service request to the BSC in the establish

indication message (#8) which includes the following data:

- message discriminator - radio link layer management;

- message type - establishment indication;

- channel number - SDCCH + AGCH;

- link identifier - main signalling channel SDCCH;

- L3 Information - complete L3 service request as received from the MS.


19/48



DN00284467/1.0 eng 23/11/2000 20(49)


This message indicates to the BSC that MS is now on the SDCCH

channel. If this message is not received by the BSC, the counter

sdcch_abis_fail_call #1075 will be incremented and the setup of the service

will be interrupted. A depth study of this case will be performed in the

chapter 8.2.

The BSC decodes the cause of the service request from the content of

the establish indication message.

In Figure 6 the signalling chart with the counters incremented at the

establish indication message is reported.

MS BTS BSC MSC VLR

Figure 6: counters incremented at the establish indication message

(Nokia Electronic Documentation, S9)

In correspondence of this signal the BSC increments always one of the

following six counters indicating the reason of the service setup (the same

counters are indicated in Figure 2):

• 3013: call or SMS or suppl. service originated

• 3012: call or SMS or suppl. service terminated

• 3020: call re-establishment

• 3021: emergency call

• 3019: location update

• 3033: imsi detach (S7 release)


20/48



DN00284467/1.0 eng 23/11/2000 21(49)


In Figure 2 other three counters (3028, 3029, 3044) are indicated in

brackets because they are not triggered during the call setup but it is

important to remember their use further. These counters are incremented

later in the signalling (i.e. after the establish indication, see chapter 5) if the

service is a SMS (3028, 3029) or Supplementary Service (3044). This

allows extracting the number of SDCCH requested for call subtracting their

value from the counter 3013 and 3012.

That means, for example, that when a Mobile Originated Call service

or a originated SMS service is requested the counter "succ_seiz_orig

(3013)" is incremented; in case the service is a originated SMS the counter

"succ_sdcch_sms_est (3028)" or "unsucc_sdcch_sms_est (3029)" is also

incremented.

This will be the method followed during the definition of the SDCCH

success rate indicators in order to distinguish how many service requests are

aimed at creating a call.In the following step of the signalling the service request is forwarded

to the MSC by the CR (CM service request) message (#9), then the BSC

starts to initiate the signalling connection control part (SCCP) connection

for the MS for the SDCCH establishment from the BTS. The GSM timer

T9105 is used to supervise this procedure.

If the SCCP link establishment fails, the BSC releases all resources

related to this transaction.

The BTS acknowledges the SABM (CM_service_request) by sending

to the MS the layer 2 UA (establish_indication) frame (#10). UA

(unnumbered acknowledgement) is normal Layer 2 level acknowledgement

when setting up the Layer 2 level link in LAPDm -protocol.

By the process access request message (#11) the MSC forward the

MS request to the VLR for access management. After that the procedures of

authentication, ciphering and encryption are performed in sequence. We

omit to describe the signalling of these procedures because no counter is

involved in the indicator we are defining.

For the definition of the SDCCH Success Rate for call the next signals

to be considered are the last two of PART 3: the physical context request

(#38), with which the BSC requests the BTS for the timing advance of

mobile transmission used in the SDCCH required by the mobile to move

onto the new radio channel, and the physical context confirmation (# 39).On receiving the physical context confirm message the BSC searches

for the relevant TCH channel using channel reservation procedure; at this

point the following counters are incremented (see Figure 4):

• tch_req #1010 triggered when a TCH is requested in the BTS (calland HO);

• tch_call_req #1026 triggered when the TCH is requested for a call;this counter will be considered the goal of the SDCCH transaction in

the SDCCH success rate for call indicator formula;


21/48



DN00284467/1.0 eng 23/11/2000 22(49)


• tch_norm_seiz #1009 triggered when the TCH is reserved for acall (no for HO).

If the BSC fails to receive the physical context confirmation message

within the T9108, or the message does not contain all the information

expected, the BSC returns an assignment failure message to the MSC with

the cause "equipment failure". The MSC either aborts with a clear command

or retries.

If the request cannot be acted on because all radio channels are

reserved, the queue is full, the request has been in the queue for too long, or

because of exceptional conditions such as restart/reset, then the BSC returns

an assignment failure with the cause "no radio resource available".


22/48



DN00284467/1.0 eng 23/11/2000 23(49)


4.2.4 PART 4: TCH activation (#40) and assignment command (#42)

The PART 4 of the signalling includes the last message transported on

the SDCCH channel toward the MS.After a successful TCH reservation, the BSC sends the channel

activation message (#40) to the BTS. In this message it tells the BTS to

activate the radio channel required. The message contains the following

data:

- message type;

- channel number = Lm/Bm + AGCH;

- activation type = normal assignment;

- channel mode = DTX indication and channel type. The channel type is either a

speech or data channel. If it is a speech channel, GSM speech encoding algorithm

is included; if it is a data channel, the transparent or the non-transparent mode isincluded. The data rate is also given.

The BSC starts the timer T9103 waiting for the channel activation

acknowledgement message (#41). If no response is received from the BTS

within the timer T9103, the BSC will send the MSC an assignment failure

message with the cause "equipment failure". The MSC either aborts or

retries.

For the TCH radio channel to be assigned, the BSC sends the

assignment command message (#42) to the MS.

This command is transparent to the BTS and it is the last command on

the SDCCH channel. It gives the MS all the information necessary for it tochange over to the TCH. The message consists of:

- header- channel description

- power command - max. MS power

- channel mode - speech full rate or data

- mobile allocation

On receiving the Assignment Command over the Air Interface, the MS

changes over from the SDCCH to the TCH it has been assigned to.

After a successful assignment procedure, the BSC releases theSDCCH channel.

4.2.5 PART 5: TCH seizure

The signals reported in PART 5 of Figure 4 represent the TCH seizure

oriented to create the conversation on the TCH channel.


23/48



DN00284467/1.0 eng 23/11/2000 24(49)


5 SMS SIGNALLING

In this section we consider the signalling in case the service requested

is a SMS. The setup of the SMS service is the same of the call until the

setup message sent from the MS to the network (signal #31 of call

signalling, Figure 3).

In case of a Mobile originated SMS the setup message is not sent by

the MS and it is replaced with a layer 2 message, a SABM containing the

message SAPI=3. The BTS acknowledges the MS with the Unnumbered

Acknowledgement signal of layer 2.

After that the BTS sends to the BSC a second establish indication (the

first est. ind. has been described as message #8 in the call signalling) by

which the BSC decodes the cause as "SMS". The final step is the

transmission of the data.

In the following three figures the signalling in case of Mobileoriginated/terminated SMS is represented. In case of success the counter

succ_sdcch_sms_est #3028 is incremented, in case of failure the counter

incremented is uns_sdcch_sms_est #3029. As mentioned in the section

4.2.3, in case of SMS service also the counters 3012 or 3013 are triggered

after the establish indication message (signal #8) of Figure 2.

Figure 7: successful Mobile originated SMS signalling


24/48



DN00284467/1.0 eng 23/11/2000 25(49)


Figure 8: successful Mobile terminated SMS signalling

Figure 9: unsuccessful Mobile originated SMS


25/48



DN00284467/1.0 eng 23/11/2000 26(49)


6 SDCCH Blocking

Before studying the SDCCH success rate, for completeness another

formula is provided which takes into account the number of SDCCH

channels not allocated because of lack of resources.

The definition of the SDCCH blocking formula is based on the

signalling and on the counters described in the section 4.2.1 (PART 1);

considering the signalling of Figure 2 this indicator is related to the first two

signals, until channel required message.

The SDCCH request is the first step during the service setup, if the

SDCCH is not obtained the subscriber cannot access the service.

As mentioned in the section 4.2.1, the signalling related to this phase

is common for all the services required. Therefore the formula will evaluate

the overall SDCCH blocking, meaning that the result is not referred only to

the SDCCH channels requested for a call but to all the SDCCH requests.Further than the cases mentioned in the section 4.2.1, the counter

#1000 sdcch_seiz_att is incremented also during SDCCH HO attempt.

This indicator calculates the percentage of SDCCH requests blocked

because of lack of resources on the total number of SDCCH requests (MOC,

MTC, call re-establishment, emergency call, SMS, location update, IMSI

detach, supplementary service, HO).

The denominator will be the sum of the SDCCH requests and the

numerator will be the sum of the SDCCH not seized because of lack of

resources. In the numerator the number of SDCCH busy channel has been

reduced by the number of successful FACCH call setup (Figure 5), because

in this case the MS reaches the service (i.e. TCH for call) after passing

through the SDCCH blocking.

The formula of the SDCCH blocking indicator is the following:

1001000

1099

1001

*)_att (sdcch_seiz

)con (due_sdcch_-tch_seiz_

)_att (sdcch_busy

king %SDCCH bloc+

+

=

Formula 1: SDCCH blocking formula

The description of the counters involved in this formula is provided in

the chapter 12 together with the counter description of the Figure 5.

If the dynamic SDCCH allocation feature is active, the FACCH

feature operates only in case of dynamic SDCCH allocation failure.


26/48



DN00284467/1.0 eng 23/11/2000 27(49)


7 SDCCH Success Rate for call

The formula of the SDCCH success rate for call is defined as the ratio

between the number of successful transactions on SDCCH channel during

call setup and the number of transactions started for a call request.

The numerator will be the number of traffic channel requests, because

the goal of the SDCCH signalling for call is the reservation of the TCH; the

denominator will be the number of times that the BSC decodes as type of

service request a call plus the difference between the incoming and outgoing

SDCCH HO.

Considering the five parts individuated in dividing the SDCCH

signalling of a call in the chapter 4, this definition is related to the PART 3

(section 4.2.3).

The transaction is defined as successful if it reaches the physical

context confirmation, signal #39 in Figure 4.The causes originating the service are counted with the establish

indication message, signal #8 in Figure 2. These causes are:

• Mobile Originated Call

• Mobile Terminated Call

• Call Re-establishment

• Emergency Call

The following causes are excluded:

• Location Update

• Short Message Service

• IMSI detach

• Supplementary Service

The signalling PART 2 is not involved in the definition of this

indicator because in that part it is not possible to isolate the factors related to

a call and, moreover, it includes the signals exchanged during the possible

RACH retransmission procedure mentioned above (section 4.2.2.1). This

part will be considered during the definition of SDCCH Success Rate in the

overall case.With the comments described in the chapters 4 and 5 it is now

possible to define the indicator monitoring the SDCCH Success Rate for call

by the following formula:


27/48



DN00284467/1.0 eng 23/11/2000 28(49)


100

4066

4051

4058

4045

3044sup

3029

3028

3021

3020

3013

3012

1026

100

*

)ch (-bsc_o_sdc

)ch (-msc_o_sdc

)h (bsc_i_sdcc

)h (msc_i_sdcc

)ce ( plem_servi_-succ_seiz

)t (cch_sms_es-unsucc_sd

)(h_sms_est-succ_sdcc

)g_call (sdcch_emer

)_re_est (sdcch_call

)orig (succ_seiz_

)term (succ_seiz_

)eq (tch_call_r

* H HOs)(net SDCC new calls) zures for(SDCCH sei

requests)(TCH call

%e for callsucc. rat SDCCH

+

+

+

+

+

+

+=

=

+

=

=

Formula 2: SDCCH success rate for call

At the denominator the counters 3028, 3029, 3044 are subtracted

because, as explained in section 4.2.3, their increments are already included

in the counters 3012, 3013. By this way only the number of SDCCH

requested for call is taken into account.

This formula involves measurements from Traffic Measurements,

Resource Access Measurements and HO Measurements. A summary

description of the counters is reported in the chapter 10.

The previous formula is defined on BTS basis. On BSC basis the

terms 4058 and 4066 (SDCCH HOs controlled by the BSC) have to beremoved from the denominator and, on PLMN level, also the terms 4045

and 4051 (SDCCH HOs controlled by the MSC) have to be removed.


28/48



DN00284467/1.0 eng 23/11/2000 29(49)


7.1 Notes

In the following two notes the considerations about the impact in the

formula of the SDCCH HO during SMS signalling are described. For

simplicity we consider the originated SMS and the SDCCH HO BSCcontrolled. The observations are valid also in case of terminated SMS and

SDCCH HO MSC controlled.

• NOTE 1: SMS signalling in the cell

If an originated SMS signalling is dropped before the establish

indication message for SMS (see Figure 7), the counter succ_sdcch_sms_est

#3028 (or #3029) will not be incremented in the cell but the counter

succ_seiz_orig #3013 or bsc_i_sdcch #4058 has been triggered.

In this case the denominator of the formula will be incremented of one

unit because of an establish indication not related to call, decreasing the

value of the indicator (i.e. of the success rate) in comparison to the reality.

Therefore the result of the indicator will fluctuate around the real

value depending on the weight of this phenomenon.

• NOTE 2: SMS signalling during HO

The SDCCH HO can be performed for every kind of service, and it is

not possible to distinguish between handovers related or not related to call.In this note we want to consider the impact of that on the indicator

when SDCCH HO is performed during SMS signalling (i.e. from establish

indication message #8 of Figure 2 up to establish indication message for

SMS of Figure 7):

• in the source cell the counters succ_seiz_orig #3013 andbsc_o_sdcch #4066 will be triggered: they cancel their effect in the

formula above; this doesn't affect the indicator;

• in the destination cell the counters bsc_i_sdcch #4058 andsucc_sdcch_sms_est #3028 (or #3029) will be triggered: they

cancel their effect in the formula above; also in this case thismeans that it doesn't affect the indicator.

The conclusion is that the value of SDCCH success rate for call has no

fluctuation around the real information if SDCCH HO is performed

successfully during SMS service.

Note that if the outgoing SDCCH HO during SMS has been successful

in a cell and then the signalling is dropped in the new cell, we are in the case

of the previous NOTE 1.


29/48



DN00284467/1.0 eng 23/11/2000 30(49)


8 SDCCH success rate in overall case

8.1 Overview

Aim of this indicator is to evaluate how many SDCCH transactions

started at the establish indication message (signal #8 in Figure 2) arrive

successfully at the end of the SDCCH signalling.

In this case all the SDCCH transactions will be considered, that is all

the SDCCH signalling originated with every establishment cause or by

incoming SDCCH HO.

In order to evaluate the performance in this case, counters for the

failures on SDCCH channel will be used in the formula. If a message is lost

or corrupted during the SDCCH signalling phase, a failure counter related tothe SDCCH part will be incremented. All the counters counting the failures

during the SDCCH phase are described in the chapter 11.

The SDCCH success rate will be obtained as complement of the

failure rate. The failure rate is calculated as ratio between the total number

of SDCCH failures and the total number of establishment causes plus the

incoming SDCCH HOs.

Among the SDCCH failures, a specific analysis will be performed in

the next sections regarding the SDCCH failures counted in the Abis

interface. Concerning the causes incrementing the number of these failures,

there is a part of signalling in which a wide number of Abis failures is

counted but the subscriber doesn't perceive them.

The part of signalling involved in this analysis is the PART 2 of

Figure 2; this part is the end of the radio access part. The most critical point

will be the immediate assign message sent from the BTS to the MS on

AGCH channel and the answer from the MS in the cm_service request

message on SDCCH.

As already mentioned in the section 4.2.2.1, the causes incrementing

the counter related to the failure in the Abis interface need an accurate

analysis in order to understand how many of the failures counted are really

detected by the user. This is very important for defining an indicator

showing what the subscribers are really perceiving.


30/48



DN00284467/1.0 eng 23/11/2000 31(49)


8.2 Counter 1075 "sdcch_abis_fail_call"

The purpose of this section is to explain the possible reasons for thecounter 1075 sdcch_abis_fail_call being updated and when the subscriber

perceives the failure. In the real statistics it is common that this counter

makes up most of the failures in the SDCCH signalling.

In the following table the DX causes composing this counter are

reported.

Cause name Cause number

abis_fail_block_c 304

abis_msg_corrup_to_bts_c 305

block_slave_c 307

ch_act_fail_c 314

data_ind_corrup_c 319

estab_ind_fail_c 321

estab_conf_fail_c 322

mode_mod_ack_fail_c 326

no_meas_result_c 327

no_resp_from_copro_c 328

phy_cont_conf_fail_c 329

rcs_alg_start_ack_fail_c 330

rcs_alg_cl_ack_fail_c 331

rf_ch_rel_ack_fail_c 333rel_ind_fail_c 335

signalling_error_c 336

sapi_3_fail_c 343

sub_timer_c 367

estab_ind_corrupted_c 370

has_state_conflict_c 505

Table 1: DX causes of the counter 1075

One of the reasons why counter 1075 is incremented is when the BSC

receives an establish indication which contents have been corrupted (DX

cause 370), or more commonly when a timer (T3101, default 3 sec) expires

while waiting for the establish indication (DX cause 321). In the real

statistics it has been found that the biggest contribution to the value of the

counter 1075 is exaclty in the DX cause 321.

Purpose of the following sections is to analyse when the failure due to

missed establish indication is really perceived by the subscriber.


31/48



DN00284467/1.0 eng 23/11/2000 32(49)


The establish indication is the first message sent from the BTS to the

BSC after the MS has successfully accessed the SDCCH (signal #8 in Figure

2).

The reasons because the MS would not appear on the granted SDCCH

are multiple; the following issues will be covered in the next paragraphs:

• ghost random accesses

• double reservations: RACH repetition (congestion or coverage problem)

• BCCH frequency-BSIC reuse

• bursts of random accesses (HO access)

• "channel activation not acknowledgement" message failure

8.3 Ghost random accesses

The BTS is continuously monitoring the UL Random Access Channel

slots in order to find whether or not there has been a random access from a

mobile. The information contents of a random access burst are rather

limited, thus it is possible the BTS detects a random access from

background noise. This kind of a "ghost random access" contains a random

Establishment Cause, and it is detected with a random timing advance.

There will always be a certain number of ghost accesses in the

network. If the number of SDCCH seizures per site is very small, then it is

possible that the majority of the accesses are ghost accesses. If this is the

case, then the result will be a high failure rate, and nothing can really be

done except to ignore the SDCCH Abis fail on sites where there is very little

traffic.One would expect (after BTS SW B9/D2) to receive maximum

somewhere around a few tens of ghost seizures per day per site. The amount

of ghost seizures can be studied with the counter ghost_ccch_res #3030; this

counter is incremented each time a ghost reservation is rejected on the

CCCH. The rejection is based on the Establishment Cause. Since the

Establishment Cause is random, in some cases the Establishment Causes in

the ghost random accesses will not be valid. Since this request is rejected it

will not result in 1075 being augmented. However we can expect a random

distribution of Establishment causes on ghost random accesses, thus a

certain amount of ghost random accesses will contain a valid establishment

cause and be granted a SDCCH. This SDCCH reservation will eventually

time out (timer T3101) and result in sdcch_abis_fail_call. The counter 3030

contains also accesses rejected due to excessive timing advance in the

random access (feature Distance verification in resource allocation), but

these can be subtracted by the counter rej_seiz_att_due_dist #3031.


32/48



DN00284467/1.0 eng 23/11/2000 33(49)


Figure 10: RACH ghosts

Considering the 8 bits of information in the RACH burst, 3 bits are

related to the establishment cause and 5 bits are related to the random

reference (see section 4.2.1). Among the 8 combinations obtained by the 3

bits of the establishment cause, 5 are legal (valid est. cause) and 3 are not

valid. Supposing the same probability for every establishment cause in a

ghost RACH, it can be deduced that the 3/8 part of the ghost are recognised

by the network incrementing the counter 3030. Therefore the amount of

ghost accesses that finally result in sdcch_abis_fail_call #1075 can be

estimated around 5/3*(3030-3031).The subscriber does NOT perceive all these failures.

Since the distribution is random, this is only estimation and should

only be used with relatively large sample numbers.

8.4 Double reservations: RACH repetition (congestion or coverageproblem)

This phenomenon is based on the procedure described in section

4.2.2.1 about the automatic RACH retransmission by a MS.

When the mobile has sent a random access, it will expect an answer

from the network within a certain time period. If the answer (ImmediateAssignment or Immediate Assignment Reject) is not received, the mobile

will repeat the random access. The repetition timers are explained in GSM

specification 04.08. The maximum amount of repetitions is defined in the

BCCH information, BSC parameter RET (max number of retransmission). If

the MS has to send multiple random accesses for a call or location update, it

is possible that there will be multiple reservations of SDCCH for one

mobile; naturally the mobile can use only one of these and the rest will

eventually time out and result in sdcch_abis_fail_call counter.


33/48



DN00284467/1.0 eng 23/11/2000 34(49)


Figure 11: automatic RACH retransmission

The MS can send multiple random accesses in the following

situations:

• The mobile could not receive the immediate assignment (signal #6in Figure 2). This can be due to several reasons: either the BTS has

not received the random access, or it has problems sending the

Immediate Assignment, or the MS is not capable of receiving the

Immediate Assignment.

• If there is UL interference, or the coverage is weak, the RandomAccess may be lost. In this case the SDCCH will not be seized,

and counter 1075 will not be augmented.

• If there is overload on the Access Grant channel, the ImmediateAssignment may be deleted by the BTS. The amount of deleted

Immediate Assignments (and Immediate Assignment Rejects) can

be found from counter del_ind_msg_rec #3005. In case the

immediate assignment is deleted, the MS will send a new Random

Access after timer expiration – the first seizure of SDCCH will

result in sdcch_abis_fail_call. In case the Immediate Assignment

Reject is deleted, the SDCCH was not reserved because of

congestion, and sdcch_abis_fail_call will not be augmented.

• If there is interference on the DL access grant channel, or coverageis weak, it is possible that the MS can not receive the Immediate

Assignment, and thus will make repetitions. For all the sent and

not received Immediate Assignments, sdcch_abis_fail_call will be

augmented.

The subscriber does not perceive the increments of the

sdcch_abis_fail_call due to RACH retransmission by the MS.


34/48



DN00284467/1.0 eng 23/11/2000 35(49)


8.5 BCCH frequency-BSIC reuse

If there are two sites with the same BCCH frequency and the same

BSIC, then the training sequence codes used in the random access message

by the MS and the decoding process at the BTS will be identical for thesesites. Limited only by the radio propagation environment, the random

accesses from one MS will be heard on both sites. Based on the frame

timing differences between the two sites, some of these accesses may result

in SDCCH reservations on two sites simultaneously. The MS will receive

the Immediate Assignment for one of these reservations, and access the

SDCCH. The second reservation will time out and sdcch_abis_fail_call will

be augmented but the subscriber does not perceive the failure.

Figure 12: same RACH detected by two BTSs

8.6 Bursts of random accesses (HO access), frequency-BSIC reusedistance

Sometimes burst like occurrences of sdcch_abis_fail_call have been

evidenced, together with sudden SDCCH congestion, and possibly also

Access Grant channel overflow. So far the only explanation found for thisphenomena is the frequency-BSIC reuse distance.

Consider that we have (Figure 13):

BTS1 as serving cell;

BTS2 with TCH on TRX1 frequency 1, BSIC 1;

BTS3 with BCCH frequency 1, BSIC 1.


35/48



DN00284467/1.0 eng 23/11/2000 36(49)


Now, limited only by signal attenuation, the handover access bursts to

BTS2 TRX1 will be overheard on BTS3 BCCH frequency 1. The handover

access burst is exactly like a random access burst (as electromagnetic

shape); the fields in the handover access burst may be interpreted as the

Establishment Cause and the random reference of the Random Access burst.

Most probably some of the timeslots of BTS2 TRX1 will overlap the RACH

of BTS3. So, if we do not have adequate distance between BTS2 and BTS3,

some of the handovers to BTS2 may result in sudden bursts of random

accesses to BTS3, resulting in sdcch_abis_fail_call, SDCCH congestion and

possibly also access grant channel overflow. The distance between BTS2

and BTS3 may easily be tens of kilometres, depending on the radio

propagation environment, and is not limited by the GSM specific 35 km

timing advance limits (the frame timing of BTS2 and BTS3 not being

synchronised).

Figure 13: HO access confused with the RACH by a third BTS

8.7 "channel activation not acknowledgement" message failureAfter the BSC has sent the channel activation message (#3) to the

BTS, it waits for the answer; three different events may happen:

1. the BTS sends the channel activation acknowledgement ,successful case (Figure 2);

2. the BTS sends the channel activation not acknowledgement because of a failure; in this case the counter sdcch_act_fail_call

#1072 is incremented;


36/48



DN00284467/1.0 eng 23/11/2000 37(49)


3. the BSC doesn't receive any signal from the BTS; in this case(after the timer T9103 expires, Figure 14) the counter

sdcch_abis_fail_call #1075 is incremented.

Figure 14: Channel activation acknowledgement not received by the BSC

8.8 FORMULA

Considering the previous issues it is clear that a big part of the failuresmapped in the counter 1075 are not perceived by the subscriber; therefore it

is reasonable to introduce a factor in order to weight the value of the

"sdcch_abis_fail_call" in the formula of the SDCCH failure rate.

The critical point is the establish indication (see Figure 2) message

sent from the BTS to the BSC. All the failures in Abis happened after this

message (both during a call and HO) are detected by the subscriber because

the SDCCH signalling is dropped. Considering the failures in Abis

happened before this message, only a small part of them will be perceived

by the user; in fact a lot of them are generated by ghost RACHs, RACH

repetitions, HO access bursts or RACH felt by more than one BTS.


37/48



DN00284467/1.0 eng 23/11/2000 38(49)


From real statistics it has been found that the value of the failure

mapped as Abis failure before the establish indication message is around the

95% of the whole value of the counter 1075 sdcch_abis_fail_call.

All the messages lost between the channel activation and the establish

indication (except the negligible number of "channel activation not

acknowledgement" message, described in par. 8.7) are represented by the

following difference:

)ach (i_-sdcch_ims

)_upd (-sdcch_loc

)rg_call (-sdcch_eme

)l_re_est (-sdcch_cal

)_orig (-succ_seiz

)_term (-succ_seiz

)gn (sdcch_assi

3033det

3019

3021

3020

3013

3012

1007+

This is the number of failures mapped as Abis failures collected

because of missed establish indication message (signal #8 of Figure 2).

A solution could be to include in the sum of the SDCCH failures only

the Abis failure occurred after the establish indication, defining a coefficient

C in order to modify the impact of the counter sdcch_abis_fail_call #1075

with the following weight:

)1075(___

3033det

3019

3021

3020

3013

3012

1007

1call failabissdcch

)ach (i_-sdcch_ims

)_upd (-sdcch_loc

)rg_call (-sdcch_eme

)l_re_est (-sdcch_cal

)_orig (-succ_seiz

)_term (-succ_seiz

)gn (sdcch_assi

C

+

−=

With the comments described in the previous sections it is possible to

define the SDCCH Success Rate formula which seem to match the

perception of the subscriber:

ure rate %SDCCH failrate %essSDCCH succ −= 100

where:


38/48



DN00284467/1.0 eng 23/11/2000 39(49)


100

4058

4045

3033det

3019

3021

3020

3013

3012

1079

1078

1076

1075

1039

1038

1037

1036

1035

1004

1003

100*min

*

)h (bsc_i_sdcc

)h (msc_i_sdcc

)ach (_sdcch_imsi

)upd (sdcch_loc_

)g_call (sdcch_emer

)_re_est (sdcch_call

)orig (succ_seiz_

)term (succ_seiz_

)(_fail_oldsdcch_a_if

)(_fail_callsdcch_a_if

)(_fail_oldsdcch_abis

)ll (is_fail_caC*sdcch_ab

)_act (sdcch_netw

)_reset (sdcch_bcsu

)_act (sdcch_user

) fail (sdcch_bts_

)_fail (sdcch_lapd

)ld_ho (sdcch_rf_o

)o_fail (sdcch_radi

sg SDCCH HOincosindicationestablish

uresSDCCH fail ure rate %SDCCH fail

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

=

=

+

=

Formula 3: SDCCH failure rate in the overall case

where C is the coefficient (between 0% and 100%) introduced for the

failure in Abis interface during the SDCCH signalling in order to consider

how many Abis failures mapped in this counter are really detected by the

subscriber.This formula involves measurements from Traffic Measurements

(failures), Resource Access Measurements and HO Measurements.

The counters involved in this formula are described in the chapter 11.

Another comment (see chapter 9) must be added regarding the counter

"sdcch_a_if_fail_call" (1078). Between the causes incrementing this

counter, that is all the signalling failures in the A interface, there is also the

block in the A interface. This condition is verified when the MSC doesn't

find the resource on the PCM link.


39/48



DN00284467/1.0 eng 23/11/2000 40(49)


The previous formula is defined on cell basis. On BSC basis the terms

4058 (SDCCH HOs controlled by the BSC) have to be excluded from the

denominator and, on PLMN level, also the term 4045 (SDCCH HOs

controlled by the MSC) have to be excluded.

At the denominator the counters for SMS and supplementary services

are subtracted for the reason described in the SSR for call and in the section

4.2.3 .

In the following figure the scenario of the counters involved in the

SDCCH request is reported; the Abis failures are divided in the ghost

contribute and in the failures after the establish indication (small part of abis

failures).

Figure 15: scenario and counter relations during SDCCH request


40/48



DN00284467/1.0 eng 23/11/2000 41(49)


9 APPENDIX: Counter 1078 "sdcch_a_if_fail_call" and A interfaceblocking

The counter 1078 is defined as the number of SDCCH transaction

failures due to an A interface failure during call attempt. By definition, in

these failures the block in the A interface is also included.

Considering the signalling between MSC and BSC defined in the

specification ETSI 08.08 ver 8.5, one of the possible message type (08.08,

3.2.2.1) is the "overload " message (3.2.1.26). This message is sent from the

BSS to the MSC or from the MSC to the BSS. There can be several causes

for sending this message (the cause values are listed in 08.08 – 3.2.2.5);

typical cause values are: processor overload, O&M. For example, when the

processor is overload at the MSC, the MSC can indicate to the BSS that it is

in a congested state and it is not able to process new service requests. One of

the cause value for the "overload " message is "Requested terrestrial resourceunavailable", that is sent as overload cause from the MSC to the BSC when

the MSC doesn't find the resource in the A interface. This can happen if no

free slot is found in the PCM line.

This event is included in the DX causes of the counter 1078 (NED S9)

as "m_req_terr_res_unava_c" (DX cause number 916). This means that a

congestion in the A interface is mapped as a failure in the A interface by the

SDCCH BSS counter failure 1078.

Considering the same call between two MSs, if no resources in the A

interface are free on the both sides it is not possible to have two increments

of the sdcch_a_if_fail_call (related to the two cells in which the MS are

located); the counter 1078 will be incremented only in the source cell.

In fact, in order for the MSC to be able to perform the pre-analysis

(i.e. dialled number validity check), in the source cell the resource in the A

interface has been already allocated. Without this condition (free PCM slot

in the A source side) the process cannot proceed, the routing with the

destination number doesn't start and the resource in the destination A if is

not requested.


41/48



DN00284467/1.0 eng 23/11/2000 42(49)


10 Table 2: Counters involved in the SDCCH Success Rate for call

Database NMS counter

name and number

Description Table

tch_call_request1026

Number of TCH requests for normal assignment(successful + unsuccessful). Updated when the Radio

Resource Manager receives a TCH request in a call attempt.

Traffic

succ_seiz_term

3012

Successful SDCCH seizures for a mobile terminated

call (MTC). This counter is increased by one every time that

an ESTABLISH INDICATION containing a paging

response is received on SDCCH from the BTS.

succ_seiz_orig

3013

Successful SDCCH seizures for a mobile originating

call (MOC). This counter is increased by one every time that

an ESTABLISH INDICATION containing a CM service

request is received on SDCCH from the BTS.

sdcch_call_re_est

3020

The number of successful SDCCH seizures for call

re-establishment. This counter is augmented by one every

time that an ESTABLISH INDICATION containing a call

re-establishment is received on the SDCCH from the BTS.

sdcch_emerg_call

3021

The number of successful SDCCH seizures for an

emergency call. This counter is augmented by one every time

that an ESTABLISH INDICATION containing a emergency

call is received on the SDCCH from the BTS.

succ_sdcch_sms_est

3028

Number of the SMSs successfully established on an

SDCCH.

UPDATED: When an ESTABLISH INDICATION

message (mobile originating SMS) or an ESTABLISH

CONFIRM message (mobile terminating SMS) is received

on SDCCH from the BTS.

unsucc_sdcch_sms_est3029

Number of the unsuccessful establishments of SMSson an SDCCH.

UPDATED: When establishment of SMS fails on

SDCCH.

succ_seiz_supplem_serv

3044

Number of the successful seizures of SDCCHs for

supplementary service (S9).

UPDATED: When an ESTABLISH_INDICATION

message with CM service request and service type

supplementary service is received on SDCCH from the BTS.

ResourceAccess

msc_i_sdcch

4045

Number of the successful incoming SDCCH to

SDCCH HOs controlled by the MSC.

UPDATED: When the HO is completed.

bsc_i_sdcch

4058

Number of the successful incoming SDCCH to

SDCCH HOs controlled by the BSC.


msc_o_sdcch

4051

Number of the successful outgoing SDCCH to

SDCCH HOs controlled by the MSC.


bsc_o_sdcch

4066

Number of the successful outgoing SDCCH to

SDCCH HOs controlled by the BSC.


Handover

BSC

Table 2: Counters involved in the SDCCH Success Rate for call


42/48



DN00284467/1.0 eng 23/11/2000 43(49)


11 Table 3: Counters involved in the SDCCH Success Rate in the overallcase

Database NMS

counter name andnumber

Description Table

sdcch_assign 1007 Successful SDCCH seizures for immediate assignment

UPDATED: When the Radio Resource Manager allocates

an SDCCH for immediate assignment (call attempt).

sdcch_radio_fail 1003 Number of the SDCCH transactions ended due to a

radio failure.

UPDATED: When an SDCCH transaction ends due

to a radio failure (radio link timeout) and the RRM releases

the SDCCH. Also if MS user clears the call during the

SDCCH phase, this counter will be updated.

sdcch_rf_old_ho

1004

Number of the SDCCH transactions ended due to a

radio failure on the source channel during HO betweenSDCCH-SDCCH or SDCCH-TCH.


to a radio failure (HO failure) on the source channel during

HO attempt and the RRM releases the SDCCH.

sdcch_user_act

1037

Number of the SDCCH transactions ended due to

user actions. (The TRX/TSL is in substate blocked by the

user.)

UPDATED: When the user disconnects a busy

SDCCH by blocking the TSL/TRX with an MML

command. The transaction ends and the SDCCH is

released.

sdcch_bcsu_reset

1038


BCSU restart.UPDATED: When an SDCCH transaction ends due

to a TRX blocked by a BCSU restart and the RRM releases

the SDCCH.

sdcch_netw_act

1039


reconfiguration of the radio network. (The TRX blocked is

in substate blocked by the system.)


to a TRX blocked by a failure which leads to TRX

reconfiguration. The failure may occur both during call and

HO attempts.

sdcch_bts_fail

1036


BTS failure. (The TRX blocked is in one of thesesubstates: FU fault, CU fault, BTS reset, BCF reset, both

CU and FU fault, BCF fault.)


to a TRX blocked by a BTS failure and the RRM releases

the SDCCH.

sdcch_lapd_fail

1035


an LAPD failure. (The TRX blocked is in one of these

substates: signalling link fault or PCM fault.)


to a TRX blocked by an LAPD failure and the RRM

releases the SDCCH.

Traffic


43/48



DN00284467/1.0 eng 23/11/2000 44(49)


sdcch_abis_fail_call

1075


failure in the Abis interface during a call in progress. There

is no acknowledgement of channel activation, no indication

of call establishment received, i.e., ghosts.

UPDATED: When an SDCCH transaction ends dueto signalling problems in the Abis interface and the RRM

releases the SDCCH.

Reasons that trigger the counter: see chapter 8.2):

Phantom RACHs that have a valid establihment

cause.

The BTS can hear the MS, but the MS cannot hear

the BTS, and so the MS does not respond to the

IMMEDIATE ASSIGNMENT message with a SABM.

MS is accessing the network at the limit of

sensitivity and messages are lost.

Poor Radio conditions.

MS is accessing network through another BTS (co-

channel, co-BSIC interference).sdcch_abis_fail_old

1076


failure in the Abis interface on the source channel during

SDCCH-SDCCH or SDCCH-TCH HO.


to a failure in the Abis interface on the source channel

during an HO and the RRM releases the SDCCH.

sdcch_a_if_fail_call

1078


failure in the A interface during call attempt.


to signalling problems in the A interface during a call

attempt and the RRM releases the SDCCH.

sdcch_a_if_fail_old

1079


failure in the A interface failure on the source channel

during an SDCCH-SDCCH or SDCCH-TCH HO.


to signalling problems in the A interface during an

SDCCH-SDCCH or SDCCH-TCH HO and the RRM

releases the SDCCH.

sdcch_loc_upd

3019


location update.

UPDATED: When an ESTABLISH INDICATION

message with request for a location update is received on

SDCCH from the BTS.

imsi_detach_sdcch

3033


IMSI detach (S7).UPDATED: When an ESTABLISH INDICATION

message for an IMSI detach is received on SDCCH from

the BTS.

succ_seiz_term

3012

See Table 2 description.

succ_seiz_orig

3013

See Table 2 description

sdcch_call_re_est

3020


sdcch_emerg_call

3021


Resource

Access


44/48



DN00284467/1.0 eng 23/11/2000 45(49)


msc_i_sdcch

4045


bsc_i_sdcch

4058


Handover BSC

Table 3: Counters involved in the SDCCH Success Rate in the overall case


45/48



DN00284467/1.0 eng 23/11/2000 46(49)


12 Table 4: Counters indicated in the flowchart of the SDCCHassignment with the features dynamic SDCCH allocation and FACCH

call setup

Database NMS counter name

and number

Description Table

sdcch_seiz_att

1000

Number of the times when an MS attempts to

seize an SDCCH.

UPDATED: When the RRM receives requests

for SDCCH from an MS as the MS needs a channel

for either a call or a HO.

sdcch_busy_att

1001

Number of the times when an MS attempts to

seize an SDCCH unsuccessfully because all SDCCHs

are busy.

UPDATED: When the RRM has no SDCCHs

to allocate for a call or HO attempts.

tch_norm_seiz1009

Number of the successful requests for a TCHin a normal assignment.

UPDATED: When the RRM allocates a TCH

as a response to a TCH request in a call attempt.

tch_request

1010

Total number of the requests for a TCH

(successful and unsuccessful).

UPDATED: When the RRM receives a

request for a TCH either in a call or an HO attempt.

tch_call_request

1026

Number of TCH requests for normal

assignment (successful + unsuccessful)

UPDATED: When the Radio Resource

Manager receives a TCH request in a call attempt.

tch_succ_full_seiz_fast_call

1125

Number of the successful Full Rate TCHs

seizures for a FACCH call setup.

UPDATED: When the RRM allocates an FR

TCH as a response to an SDCCH request as part of

the FACCH call setup during SDCCH congestion.

tch_succ_half_seiz_fast_call

1126

Number of the successful Half Rate TCHs

seizures for a FACCH call setup.

UPDATED: When the RRM allocates an HR

TCH as a response to an SDCCH request as part of

the FACCH call setup during SDCCH congestion.

tch_fast_req

1043

Number of the TCH requests for FACCH call

setup during SDCCH congestion (both successful and

unsuccessful).

UPDATED: When the RRM receives arequest for an SDCCH but there are no SDCCHs idle

and a TCH is tried to be allocated as part of the

FACCH call setup. It is indicated in the received

SDCCH request whether FACCH setup is allowed or

not.

Traffic


46/48



DN00284467/1.0 eng 23/11/2000 47(49)


sddch_dynamic_reconf_att

1154

Number of the SDCCH reconfiguration

attempts for immediate assignment.

UPDATED: When a SDCCH channel is

needed for an immediate assignment and no free

SDCCH is available and the request is sent forreconfiguring a TCH channel to a SDCCH channel.

This counter is not updated if reconfiguration is done

from SDCCH to TCH channel.

sdcch_unsucc_imm_assign_att

1155

Number of the unsuccessful SDCCH

allocation attempts for immediate assignment.

UPDATED: When the SDCCH channel

allocation does not succeed due to lack of SDCCH

resources at the time of the immediate assignment.

When SDCCH is released with the dx-cause

rtsl_reconf_fail_c.

tch_seiz_att_due_sdcch_con

1098

Number of the attempts to seize a TCH due to

SDCCH congestion.

UPDATED: When the RRM attempts toallocate a TCH as a response to a request for an

SDCCH seizure during SDCCH congestion. The

RRM does this if the TCH allocation (=FACCH

setup) is allowed in the message carrying the request

for the SDCCH seizure.

tch_seiz_due_sdcch_con

1099

Number of the successful TCH seizures due to

congestion on the SDCCH.

UPDATED: When the RRM allocates a TCH

as a response to a request for SDCCH seizure during

congestion on the SDCCHs. The RRM allocates a

TCH if the TCH allocation (=FACCH setup) is

allowed in the message carrying the request for the

SDCCH seizure.

ch_req_msg_rec

3004

Number of CHANNEL REQUIRED messages

received from the BTS.

UPDATED: When a CHANNEL REQUIRED

message is received from the BTS.

ghost_ccch_res

3030

Number of the ghost reservations on a CCCH.

UPDATED: When a ghost reservation is

detected on a CCCH because the establishment cause

is not valid. This kind of random access can be

caused by, for example, white noise or co-channel

interference.

Resource

Access

Table 4: Counters indicated in the flowchart of the SDCCHassignment with the features dynamic SDCCH allocation and FACCH call

setup


47/48


48/48

cssr abd sdcch drops updated-libre

Documents