5. CALL SETUP
5.4. C ALL SETUP – RAB ESTABLISHMENT
5.4.1. Dynamic bearer control (DBC)
Dynamic bearer control (DBC) is used to prevent overload of the R99 system in case new radio resources or radio resources requiring more power are requested. DBC takes place
• During the RAB establishment after the RNC is receiving the RAB Assignment Request on RANAP
6 There are a huge amount of failure causes, but not all related to RAB assignment failure.
• During the transition of CELL_PCH/URA_PCH to CELL_DCH mode (see also subsection 6.6) after the RNC is receiving the corresponding RACH messages
• In case service based data rate increase is triggered (see also subsection 7.2.3) after the RNC receives a corresponding RRC Measurement Report from the UE
DBC thresholds can be defined for UL and DL load separately and DBC failure can also occur at stages other than RAB establishment.
In case DBC grants the requested service the call handling proceeds as specified (depending on the phase of the call), otherwise the call handling is as follows:
• During the RAB establishment the RNC sends a RAB Assignment Response message on RANAP with specified cause “No resource available” under “miscellaneous” class. On Uu the following messages/outcomes will be indicating that DBC has not granted the requested service:
o The assigned PS RB is smaller than the default one or the one requested in the PDP Context Activation message7; the default PS RB is configurable
OR the PDP Context Activation is rejected with an appropriate specified cause like “QoS not accepted” or “Insufficient resources”
o The VT call is not granted or instead a voice call is setup
o The Voice call receives a CC Disconnect message with specified cause “resource unavailable”
• During the transition of CELL_PCH/URA_PCH to CELL_DCH mode:
o The RNC sends back the UE to idle mode with the RRC Connection Release message and specified cause “congestion”
OR
o The RNC sends back to the UE either a Cell Update Confirm / URA Update Confirm message, but the RRC State Indicator is set to CELL_PCH/URA_PCH.
• In case of service based data rate increase: the RRC Measurement Report message is just ignored so the UTRAN is keeping the current RB and Transport Channels
Not granting the requested service by DBC indicates either high cell loading or an area of high interference. The optimisation approach in the later case is to optimise the RF environment in terms of reducing pilot pollution, improving RF coverage, neighbour list optimisation etc.
DBC uses a QoS parameter in order to prioritise different user when downgrading, see also [20] for details.
5.4.1.2. Failure symptoms, identification and fixes for improvement
Table 28 is listing the identification techniques in traces in case DBC is not granting the requested service:
7 The requested QoS profile in the PDP Context Activation message might be ignored and only a default one is assigned
Problem Trace Trigger
DBC RAB not granted on Iu
Iu Any occurrence of a RAB Assignment Response message on RANAP with specified cause “No resource available”
DBC RAB not granted on Iu and Uu
Iu, Uu Cross-correlation Uu/Iu trace: Any occurrence of a RAB Assignment Response message on RANAP with specified cause “No resource available”
DBC RAB PS not granted
Iu or Iub, or Uu
Any occurrence of a SM Activate PDP Context Reject message sent by the CN to the UE and the specified cause is “Insufficient resources”
DBC RB Setup PS
Uu On Uu, in the RRC RB Setup Message the IE “Spreading Factor” is larger than the default one and a PDP Context Activation message was sent within the last x seconds with the requested bit rate in the DL higher than the granted one DBC RB Setup
VT
Uu The VT call has been requested, the called entity is also a UE with VT capabilities but a voice RB is setup
DBC RRC
Release
Uu Any occurrence of an RRC Cell Update/URA Update message following within x seconds a RRC Connection Release message with specified cause “congestion”
and the UE is in either CELL_PCH or URA_PCH mode DBC RB Setup
voice
Uu The UE is sending a CC Setup message and within x seconds gets a CC Disconnect with cause “resource unavailable”
DBC Cell/URA update failed
Uu The UE is sending a Cell Update/URA Update message and the RNC is sending back within x seconds a Cell Update Confirm/URA Update Confirm message with RRC State Indicator set to CELL_PCH/URA_PCH.
Table 28: Identification of DBC rejections in interface traces For DBC related PM counters see [20] with a summarized version shown below.
Note that <Cause> can be UL interference or DL power.
PM system
Counter / KPI Name / Description
UtranCell RAB.FailEstabCSNoQueuing .<Cause>
Number of RAB Establishment Failures due to a given cause for CS domain.
UtranCell RAB.FailEstabPSNoQueuing .<Cause>
Number of RAB Establishment Failures due to a given cause for PS domain.
Table 29: PM Counters indicating potential R99 DBC failures 5.4.2. Radio Link Reconfiguration
5.4.2.1. Concept
After DBC has taken place the RLs on the Iub have to be reconfigured using the Radio Link Reconfiguration procedure on NBAP. The flowchart can be seen in Figure 10.
The RNC tries to allocate resources on the Iub by sending a RL Reconfiguration Prepare message on NBAP. The NodeB is answering by either sending a Radio Link Reconfiguration Ready (successful case) or Radio Link Reconfiguration Failure (unsuccessful case). The successful case ends in the RNC sending a Radio Link Reconfiguration Commit to the NodeB. This procedure is used to order the Node B to switch to the new configuration for the Radio Link(s) within the Node B. The whole procedure is described in [7].
5.4.2.2. Failure symptoms, identification and fixes for improvement For the failure analyses please refer to subsection 5.1.5.2.
Table 30 below is listing the identification triggers for network interface traces, Table 31 the corresponding UTRAN KPIs.
Problem Trace Trigger
Radio Link
Reconfiguration Iub
Iub Any occurrence of the NBAP Radio Link Reconfiguration Failure message on Iub x seconds after there was a Radio Link Reconfiguration Prepare on NBAP
Table 30: Identification of RL reconfiguration failures in traces
PM system
Counter / KPI KPI Name / Description
UtranCell (VS.RLM.AttRLReconfig – VS.RLM.FailRLReconfig.sum) / VS.RLM.AttRLReconfig * 100
Total radio link reconfiguration success rate
Table 31: PM KPIs for RL reconfiguration failures 5.4.3. Radio Bearer Establishment
5.4.3.1. Concept
Once the required resources have been successfully reconfigured in the NodeBthe RNC sends the Radio Bearer Setup message to the UE that sends back the Radio Bearer Setup Complete message upon successfully allocating resources for the new RB. The Radio Bearer Establishment procedure may fail for different reasons (see below); in that case the UE sends back a Radio Bearer Setup Failure message to the RNC.
When a physical dedicated channel establishment is initiated by the UE, the UE shall start a timer T312 and wait for N312 successive “in sync” indications. On receiving N312 successive “in sync” indications, the physical channel is considered established and the timer T312 is stopped and reset. If the timer T312 expires before the physical channel is established, the UE shall consider this as a “physical channel establishment failure”. The whole procedure is explained in [6].
Table 32 below is listing the parameters for the RB Establishment:
Parameter Description
t312 The UTRAN parameter is configuring timer T312 n312 The UTRAN parameter is configuring N312
Table 32: Parameter important for the RB Establishment 5.4.3.2. Failure symptoms, identification and fixes for improvement
In case the UE sends back the Radio Bearer Setup Failure message to the RNC and the Radio Bearer Establishment procedure fails.
Main reason for the failure can be subdivided as follows:
• Physical Channel Failure (i.e. T312 expiry)
• Unsupported or invalid configuration in the UE
• Code starvation (the required channelisation code is not available anymore from the code tree)
• Protocol Error
In general, the physical channel failure occurs when there is loss of synchronisation between UE and NodeB. This is mainly caused by poor RF conditions; see also subsection 6.1 and 6.4 for details. The other two causes are expected to occur infrequently and in general are not related to RF issues.
The causes of the Radio Bearer Setup Failure message are listed in chapter 10.3.3.13 in [6]. Again it is up to the UTRAN vendor, which cause out of this list is chosen for the particular failure that has occurred.
Table 33 is listing the identification techniques in traces, Table 34 the corresponding PM KPIs for failures in the Radio Bearer Setup procedure:
Problem Trace Trigger
RB setup failure Uu Any occurrence of the RRC Radio Bearer Setup Failure message
Table 33: Identification of Radio Bearer Setup failures in traces
PM system
Counter / KPI8 KPI Name /
Description
RNC / Utrancell
RAB.FailEstabCSNoQueuing.RBSetupFail / CS RAB Attempts * 100
CS RAB establishment failure rate due to RB setup failure RNC /
Utrancell
RAB.FailEstabPSNoQueuing.RBSetupFail / PS RAB Attempts * 100
PS RAB establishment failure rate due to RB setup failure
Table 34: PM KPIs for Radio Bearer Setup failures
8 For corresponding definitions of CS RAB Attempts and PS RAB Attempts see [42].
6. Call Reliability (Retainability)
This section is describing failures and occurrences that might happen after the call has been successfully setup. This might endanger the single particular call to drop, but also the overall quality of the UMTS network as well as user perceived quality (section 7) might be degraded.
6.1. Call reliability – Radio Link Failure (RLF)
6.1.1. Concept
According to [11] the PHY in the NodeB and UE checks every radio frame the synchronisation status. The status is indicated to higher layers using the CPHY-Sync-IND and CPHY-Out-of-CPHY-Sync-IND primitives indicating in-sync state and out-of-sync state respectively.
In the following the UL and DL are treated separately.
RLF and RL Restore in the UL
The RLF and restore procedures in the UL are supervised in the NodeB on NBAP; the UL radio link sets are monitored to trigger if necessary RLF and RL Restore procedures. When the radio link set is in the in-sync state and the NodeB is receiving consecutive N_OUTSYNC_IND out-of-sync indications, NodeB starts timer T_RLFAILURE. The NodeB stops and resets timer T_RLFAILURE upon receiving successive N_INSYNC_IND in-sync indications.
If timer T_RLFAILURE expires, the NodeB triggers the RLF procedure and indicates which radio link set is out-of-sync. In that case, the state of the radio link set changes to the out-of-sync state and the NodeB indicates the RLF to the RNC by sending a Radio Link Failure Indication on NBAP with the cause
“Synchronisation Failure” (see [7]).
Upon reception of this message the RNC starts timer T_RL_RESYNC (internal RNC timer defined by the UTRAN vendor). This timer is stopped and no further action is taken if the RNC receives from the NodeB the NBAP Radio Link Restore Indication message. The NodeB sends this message if the radio link set is in the out-of-sync state and the NodeB is receiving successive N_INSYNC_IND in-sync indications. The NodeB indicates which radio link set has re-established synchronisation. When the RL Restore procedure is triggered, the state of the radio link set changes to the in-sync state again.
Upon expiration of timer T_RL_RESYNC, the RNC removes the particular RL in the NodeB via the NBAP Radio Link Deletion procedure. After the deletion of the RL the RNC starts either
• With the Active Set Update procedure on RRC in case the UE is in soft/softer HO mode; note that this is not a dropped call (in terms RAB or RRC drop)
• Timer T314/T315 (configured by parameter T314rnc for CS / T315rnc for PS, see also Figure 17) giving the UE the possibility to re-establish the RRC connection. In case timer T314/T315 is expired the RNC releases the call by sending RANAP Iu Release Request message with specified cause “Release due to UTRAN generated reason” to the CN.
Afterwards the RNC also releases the RRC connection by sending the RRC Connection Release message with cause other than “normal event”. The identification of this event only with Uu traces is difficult because it is up to the UTRAN vendor of what kind of specified cause is
sent in case of an UL RLF. Finally the UE sends back a RRC Connection Release Complete and the procedure ends.
Figure 11 below is showing the call handling of the RAB release in case of a dropped call:
CN
Figure 11: RLF is resulting in RAB drops RLF and RL Restore in the DL:
The RLF procedure in the DL is supervised on RRC on the UE side.
In CELL_DCH state, the UE starts timer T313 after receiving N313 consecutive out-of-sync indications for the established DPCCH physical channel. The UE stops and resets timer T313 upon receiving successive N315 in-sync indications.
If T313 expires, the RRC connection is dropped and the UE goes to idle mode.
In idle mode the UE will select a suitable cell according to the cell reselection criteria and will initiate a Cell Update procedure with specified cause “radio link failure” (chapter 8.5.6 in [6]).
Subsequently the RLF in the UL will be triggered when the UE is in idle mode by the UTRAN on its own accord.
Figure 12 below is showing the transitions between the different states; the initial state of a RL is defined as the state when a new RL is to setup:
Figure 12: Transitions between different states
Table 35 below is listing the parameters that are configuring the RLF and RL Restore procedure:
Parameter Description
tRLFailure This parameter is defining the setting of T_RLFAILURE noOutSyncInd This parameter is defining the setting of N_OUTSYNC_IND noInSyncInd This parameter is defining the setting of N_INSYNC_IND radioLinkFailureResynchronisationR
esponseTimer
Configure guard timer T_RL_RESYNC to allow time for re-synchronization to occur when a loss of re-synchronization is detected on the last or only radio link associated with a UE connection.
RadioLinkFailureDeletionResponse Timer
Configure guard timer T_RL_RESYNC to allow time for the normal operation of the handover and power control algorithm to delete a radio link affected by a loss of synchronization or for re-synchronization to occur when the radio link is one of several associated with a UE connection.
t313 This parameter is defining the setting of T313 n313 This parameter is defining the setting of N313 t314 This parameter is defining the setting of T314 t315 This parameter is defining the setting of T315 n315 This parameter is defining the setting of N315
Table 35: Parameter configuring the RLF and RL Restore procedure 6.1.2. Failure symptoms, identification and fixes for improvement
There are a variety of causes responsible for RLFs possibly resulting in dropped calls:
• Pilot pollution and around-the-corner effect (subsection 6.4.1)
• Weaknesses in the neighbour planning (subsection 6.4.4)
• Problems during (or before) the call establishment phase (section 5)
• Problems with the RF coverage (subsection 6.4.5)
• Problems with the SC plan (subsection 0)
For more information please take a look in these subsections.
A RLF in the UL that is causing a removal of a radio leg can be indirectly identified if there is no Measurement Report with type 1b/1c sent previously.
Problem is that it can be that the Measurement Report message may not have been recorded resulting in false identification.
Identification of a dropped call due to RLF in the UL only with Uu traces is difficult because the RRC Connection Release message sent by the RNC has not a unique cause id. For a reliable identification additional Iub tracing is required.
Dropped calls due to RLF in the DL can be easily identified in Uu traces with the Cell Update message sent by the UE. There might be an optional failure cause specified. Please review the status of the IE AM_RLC error indication, which can be set to True. Other cell update failures are covered in subsection 6.3 and 6.14.2.
Table 36 below is listing the identification possibilities for network interface traces.
Problem Trace Trigger
Dropped call due to RLF in the DL on Uu
Uu Any occurrence of a RRC Cell Update message with specified cell update cause (not failure cause) “radio link failure”. Note that the dropped call is the previous call and not the current one! There might be an optional failure cause specified.
RLF and RL Restore on Iub and Uu
Iub and Uu
Cross-correlation of Uu/Iub traces: Any occurrence of an Radio Link Failure Indication on NBAP with the cause “Synchronisation Failure” and after x seconds a Radio Link Restore Indication on NBAP
RLF and RL Deletion on Iub and Uu
Iub and Uu
Cross-correlation of Uu/Iub traces: Any occurrence of an Radio Link Failure Indication on NBAP with the cause “Synchronisation Failure” and after x seconds a Radio Link Deletion on NBAP and the number of radio legs is more than one RLF and dropped
call on Iub and Uu
Iub and Uu
Cross-correlation of Uu/Iub traces: Any occurrence of an Radio Link Failure Indication on NBAP with the cause “Synchronisation Failure” and after x seconds a Radio Link Deletion on NBAP and the number of radio legs is equal to one UL RLF and leg
removal on Uu
Uu Any occurrence of an Active Set Update containing any entries in the group
“RemovalInformationList” and there was no Measurement Report within x seconds before either with specified event id 1b/1c or without any specified event id9 High UE Tx power Uu Any occurrence if the UE is transmitting with maximum allowed power for x
seconds
High DL BLER Uu Any occurrence if the UE is reporting a BLER higher than x% for y seconds
Table 36: Identification of RLF in traces
Table 37 below is listing the identification possibilities using KPIs retrieved by the UTRAN PM system. Refer to Figure 13 that shows at what point during the call flow the PM counters are updated.
9 To be noted: the group “eventResults” containing the IE “eventID” is optional, for example when periodic reporting is enabled.
PM system
Counter / KPI KPI Name / Description
UtranCell VS.RAB.Drop.CS.DL_RLF/(RAB.SuccEstabCSNoQueuing.CSV
UtranCell VS.RAB.Drop.PS.DL_RLF/RAB.SuccEstabPSNoQueuing.PS*100 PS RAB Drop Rate due to DL RLF UtranCell VS.RAB.Drop.PS.DCH.CauseULRLF+
Total PS Dropped RABs cause UL RLF
UtranCell VS.RRC.AttConnRel.Drop.ULRLF/RRC.SuccConnEstab.sum*100 RRC connection drop rate caused by RLF
Table 37: PM KPIs indicating RLF
6.2. Call reliability – drop of the RAB
6.2.1. Concept
RAB drop due to UTRAN reasons
The drop of the RAB that is caused by a failure within the UTRAN is always initiated by an Iu Release Request message on RANAP with cause “Release due to UTRAN generated reason”; the call handling is shown in Figure 11. The CN will send back an Iu Release Command message on RANAP with the same specified cause (chapter 9.2.1.4 in [9]). After sending this message the UTRAN will release the RRC connection (subsection 6.3).
To be noted that this does not mean the PDP context is removed, but e.g. a FTP session that is up and running might time out. The UE can re-establish the RRC connection after doing a cell reselection by sending RRC Connection
To be noted that this does not mean the PDP context is removed, but e.g. a FTP session that is up and running might time out. The UE can re-establish the RRC connection after doing a cell reselection by sending RRC Connection