Functionality of call related DX causes in BSC

Each DX cause element consists of the following information:

the cause code that describes the event (see List of call related DX causes in BSC)
a call phase that corresponds with a phase in the signalling scenario or procedure and
defines when the event has occurred (see Call phases of call related DX causes in BSC).
There are two types of DX causes: success causes and failure causes.
A success cause is set when the MS receives access to the network with a relevant establishment
cause, or when a handover starts with a relevant handover setup cause.
Correspondingly, a failure cause is set when a failure occurs during a call or a handover. It
indicates the error that caused the channel release. Some failures result in call clearing, while
others, such as failures during a handover, do not.
Failure detection
The handling of a DX cause is located on GSM layer 3 and failures can be detected in the A
interface, Abis interface, and inside the BSC.
The BSC is responsible for the following functional parts on layer 3:
base transceiver station management (BTSM)
radio resource management (RR)
base station system application part (BSSAP)
BTSM and RR are parts of the Abis interface and BSSAP is a part of the A interface.
Since signalling on the mobility management (MM) layer is transparent to the BSC, it can
detect only some of the failures on that layer. Such failures are, for example a timer expiry on the
lower layer, corrupted messages and other protocol errors. The rest of the failures can be seen as
the release of the MSC. The BSC cannot observe these failures if the phase is MM signalling (2)
or conversation (15), because the BSC interprets this as a successful call. If the failure occurs on
layer 1 or 2, the failure can be detected on layer 3 as a timer expiry or as different kinds of block
causes.
For more information on BTSM, see 3GPP TS 48.058 Base Station Controller - Base
Transceiver Station (BSC - BTS) Interface Layer 3 specification.
For more information on RR, see 3GPP TS 44.018 Mobile radio interface layer 3 specification.
For more information on BSSAP, see 3GPP TS 48.008 Mobile Switching Centre - Base Station
System (MSC - BSS) interface Layer 3 specification.
Handling of DX causes
DX causes are handled as follows:
1. When the program block A detects a failure, it sets the cause and sends the appropriate message, either
directly or through another program block, to program block B that is responsible for the phase during
which the error occurred. This internal message includes the DX cause element.
The DX cause is set by the program block that initiates the channel release. When another network
element sends a clearing to the BSC, it is transformed into a DX cause by the program block that receives
the clearing indication.
2. When program block B receives the DX cause, it sets the phase value in the DX cause element.

3. When a program block responsible for updating the failure counter has performed the update, it also sets a
flag in the DX cause element which indicates that the counter has already been updated. The counter is
updated only once during call signalling, such as a location update, an SMS or a call.

Prioritisation of conflicting failures

Since only one DX cause can be set for one transaction, only the first failure is generally set as
the DX cause. In a conflict situation, the program block that has the highest priority defines the
appropriate failure cause.
When two different failures are in conflict, the list of priorities is, as follows:
1. AIVPRB (because it also sets the cause of failure for the MSC)
2. HASPRB
3. other program blocks

The priority handling is implemented in the ABIPRB and the HASPRB. The A interface is only
responsible for setting the appropriate cause values.
The following program blocks are involved in the handling of DX causes:
ABIPRB

Abis Interface Program Block is responsible for the normal call phases including basic call, SMS,
ciphering and FACCH call setup. It also updates the successful establishment counters and sets
the causes mainly for Abis signalling failures.

AIVPRB

A Interface Signalling Program Block in BSC sets the causes mainly for A interface signalling
failures.

HASPRB

Handover Attempt Supervisor Program Block is responsible for the handover phases including
external, internal intra and internal inter handover signalling. It also updates the successful
handover counters and sets the causes mainly for handover signalling failures.

RC0PRB

The main purpose of the Resource Control Program Block in BSC is to implement the interface
between the marker and the call control program blocks of the BSC. It sets the causes mainly for
RC0PRB signalling failures.

RCSPRB

Radio Connection Supervision Program Block takes care of the preprocessing of the
measurement samples, determines the RF output power of the MS and BTS, indicates whether
a handover is required and performs supervision of the LAPD link by supervising the flow of
measurement results coming from the BTS.

RRMPRB

Radio Resource Management Program Block controls the use of the radio channels. The
program block also sets the failures that have occurred in RRMPRB signalling.

SC7PRB

Speech Circuit Control in GSM BSC A Interface takes care of the administration of the A
interface speech circuits. It also sets the causes for SC7PRB signalling failures.

For an overview, see Overview of call related DX causes in BSC.

DN9814277

Id: 0900d805805a24b9

2009 Nokia Siemens Networks

Paging/initial MS on CCCH (phase 1)

This phase covers the starting signalling of the mobile originating and the mobile terminating
call establishment. The dedicated channel can be a stand-alone dedicated control channel
(SDCCH) or a traffic channel (TCH).
The ABIPRB is responsible for this phase. When the MS gains access to the network, the
ABIPRB sets the establishment cause to the cause field of a DX cause element. The success
cause is conveyed to the next phase if the signalling is finished successfully in this phase.
If a failure occurs, the success cause is overwritten with the failure cause and the signalling
continues as call clearing. The failure counter is updated by the RRMPRB (Radio Resource
Management Program Block) or, in some cases, by the ABIPRB.

Figure 1:

Paging/initial MS on CCCH (phase 1)