Optimization Guidelines:
Accessibility in Ericsson
CONTENTS
1 INTRODUCTION.............................................................................................................................3
2 ACCESSIBILITY..............................................................................................................................4
2.1 Idle Mode..................................................................................................................................................4
2.2 Call Establishment Process.....................................................................................................................4
3 ACCESSIBILITY KPIs (Key Performance Indicators)...................................................................5
3.1 High Level KPIs.......................................................................................................................................5
3.1.1 Call Setup Success Rate - CSSR (%)..................................................................................................................5
3.1.1.1 CS CSSR (%).........................................................................................................................................5
3.1.1.2 PS CSSR (%).........................................................................................................................................5
3.1.1.3 CS CSSR (%) –from P7.1-....................................................................................................................6
3.1.1.4 PS CSSR (%) – from P7.1-....................................................................................................................6
3.1.2 Overall Service Accessibility - OSAC (%).........................................................................................................7
3.2 Medium Level KPIs.................................................................................................................................8
3.2.1 RRC Connection Success Rate (%).....................................................................................................................8
3.2.1.1 RRC Connection Success Rate CS (%).................................................................................................8
3.2.1.2 RRC Connection Success Rate PS (%).................................................................................................8
3.2.2 Iu Signalling Establishment Success Rate (%)....................................................................................................8
3.2.2.1 Iu-CS Signalling Establishment Success Rate (%)................................................................................9
3.2.2.2 Iu-PS Signalling Establishment Success Rate (%)................................................................................9
3.2.3 NAS Signalling Establishment Success Rate (%) –from P7.1-...........................................................................9
3.2.3.1 NAS CS Signalling Establishment Success Rate (%) – from P7.1-......................................................9
3.2.3.2 NAS PS Signalling Establishment Success Rate (%) – from P7.1-......................................................9
3.2.4 (RAB) Establishment Success Rate (%)..............................................................................................................9
3.2.5 Sending Paging Failure Rate (%)......................................................................................................................10
3.2.6 Blocking Probability..........................................................................................................................................10
3.2.6.1 GoS Speech (%)...................................................................................................................................10
3.2.6.2 GoS PS (%)..........................................................................................................................................10
3.3 Failures after Admission Rate (%):......................................................................................................11
4 PERFORMANCE ANALYSIS.......................................................................................................12
4.1 Admission Control.................................................................................................................................12
4.1.1 Admission Policy...............................................................................................................................................12
4.1.2 Resources to be monitored................................................................................................................................13
4.1.2.1 RF Power.............................................................................................................................................13
4.1.2.2 Code Tree Consumption......................................................................................................................13
4.1.2.3 DL and UL ASE..................................................................................................................................13
4.1.2.4 SF Code Limit (Code Hystogram).......................................................................................................13
4.1.2.5 HSDPA and EUL connections Limit...................................................................................................13
4.1.2.6 UL and DL Channel Elements.............................................................................................................13
4.1.3 RRC Admission Blocks.....................................................................................................................................13
4.1.4 RAB Admission Blocks....................................................................................................................................14
4.2 MP Load (High processor Load)..........................................................................................................14
4.3 After Admission.....................................................................................................................................14
4.3.1 Failure after Admission: Iub Congestion.........................................................................................................15
4.3.1.1 Low RRC Success Rate.......................................................................................................................15
4.3.1.2 Low RAB Success Rate.......................................................................................................................15
4.3.2 Failure after Admission: Core Transport Network Congestion.......................................................................15
4.3.3 Failure after Admission: Hardware Usage (Channel Elements)......................................................................16
4.3.4 Failure after Admission: Channelization Codes...............................................................................................16
4.3.5 Failure after Admission: Others.......................................................................................................................16
4.4 Accessibility issues not detected by counters.......................................................................................17
4.4.1 HW Problems in the RBS..................................................................................................................................17
4.4.2 UL Interference.................................................................................................................................................17
4.4.3 RACH misconfiguration....................................................................................................................................17
4.4.4 Cell Unavailability.............................................................................................................................................17
4.4.5 Node Blocking...................................................................................................................................................17
5 REFERENCES...............................................................................................................................18
6 ANNEX I: UE Idle Mode Procedures............................................................................................19
6.1 PLMN Selection and Reselection..........................................................................................................19
6.2 Reading System Information................................................................................................................20
6.3 Cell Selection and Reselection...............................................................................................................21
6.3.1 Cell Selection.....................................................................................................................................................21
6.3.2 Cell Reselection.................................................................................................................................................21
6.3.3 Location/Routing Area Update..........................................................................................................................22
6.3.4 Paging Procedure...............................................................................................................................................23
7 ANNEX II: Call Establishment Procedure....................................................................................24
7.1 Voice Call Establishment ......................................................................................................................24
7.2 PS Data Call Establishment .................................................................................................................24
7.3 Radio Resource Control (RRC) ...........................................................................................................24
7.3.1 RRC connection Request & Setup....................................................................................................................25
7.4 Core Network Negotiation ....................................................................................................................27
7.5 Radio Access Bearer (RAB) Setup and Reconfiguration....................................................................27
1 INTRODUCTION
This series of Optimization Guidelines covers all the main topics regarding
•
•
•
Performance Monitoring & Analysis
Configuration settings
Troubleshooting
Refer to the internal Claro document “Optimization Process” (DEO.OTM.IOP3000), for a summary of 3G WCDMA Radio
Access Network Optimization Basics.
This specific document focuses on ACCESSIBILITY and its specifics within ERICSSON infrastructure (Release P7.1).
Target users for this document are all personnel requiring a detailed description of this process (Accessibility
Optimization), as well as configuration managers who require details to control the functions and optimize parameter
settings. It is assumed that users of this document have a working knowledge of 3G telecommunications and are
familiar with WCDMA.
Document Revision Control
Revision
Draft 01
Date
13-Nov-2009
Author
QCES/Ericsson
Changes
First Release of the document
Update from P7 to P7.1:
•
NAS signalling phase counters added, both to CSSR
KPIs and Medium Level KPIs
Corrections/Additions::
01
12-Mar-2010
QCES/Ericsson
•
•
•
•
•
pmNoLoadSharingRrcConnCs/Ps added to CSSR KPIs
Iu Signalling connection phase added to CSSR KPIs
CS and PS CSSR now correctly expressed in terms of
SUM of all CS / PS RAB types
Additional formulas for GoS metrics
New sections added in Annex for Core Negotiation
and RAB Setup and Reconfiguration phases
2 ACCESSIBILITY
Accessibility is the ability of a service to be obtained within specific tolerances and other given conditions, when
requested by the user. In other words, the ability of a user to obtain the requested service from the system.
•
•
•
•
Target is to get a 100% Accessibility, i.e., all users always get the service they request.
Poor Accessibility is typically due to
some form of congestion (before or after Admission Control?)
hardware/software fault (Check ALARMS, Cells Downtime, tickets in REMEDY…)
misconfiguration (AUDIT the settings in RNC)
other reasons (for instance, it is also possible that there is some external source of interference (such as a
microwave link on the same frequency) affecting the accessibility)
Accessibility is to be monitored independently for the different RAB types (e.g. Speech, CS Video, PS Interactive R99,
PS Interactive HSDPA, etc.) as in certain situations only one of the RAB types will be affected.
2.1 Idle Mode
Accessibility issues may occur related to the UE idle mode behavior.
•
•
The UE in Idle mode performs next 5 main tasks [Refer to ANNEX I for a brief review]:
PLMN selection and reselection
•
Reading system information (MIB, SIB)
Cell selection and reselection
•
Location area (LA) and routing area (RA) registration/update
Paging procedure
•
Settings should guarantee that the UE in idle mode is always in the best conditions to access the network (i.e., to
initiate a Mobile Originated call, MO) and be reached by the network (i.e., to receive a Mobile Terminated call, MT).
2.2 Call Establishment Process
Each step in the Call Establishment process should be monitored in order to clearly identify where the accessibility
issue is located. For a more complete review of the Call Establishment Process, refer to ANNEX II.
3 ACCESSIBILITY KPIs (Key Performance Indicators)
Below the main metrics used for Accessibility Monitoring of a 3G WCDMA/UMTS Network, and their implementation
with Ericsson counters.
•
•
•
•
•
•
Refer to “SMART Documentation” for further details on the actual implementation of these KPIs in the tool, together
with the additional considerations regarding:
Treatment of zeros in the denominators
Cell Reselection during RRC Establishment Phase
RRC Redirections (Load Sharing feature)
RRC Repetitions
Incoming HHO and SRNS Relocations
RAB Load Sharing features (Inter-frequency and Directed Retry to gsm)
3.1 High Level KPIs
3.1.1
Call Setup Success Rate - CSSR (%)
This is the first “overall” metric we are considering to monitor Accessibility as a whole.
Up to P7.1, this KPI was typically calculated by considering just 2 steps in Call Establishment: RRC Connection Setup
and RAB Establishment. They are assumed to be independent processes, and therefore CSSR was hence calculated as
product of the Success Rates of each of these 2 phases (described later in section 3.2):
CS/PS_CSSR = 100 * CS/PS_RRC_SSR * CS/PS_RAB_ESR
where:
CS/PS_RRC_SSR = RRC Setup Success Rate (with CS/PS Establishment Causes) =
( # CS/PS RRC Connection Setup Complete / # CS/PS RRC Connection Request)
CS/PS_RAB_ESR = RAB Establishment Success Rate (for CS/PS RABs, both R99 and HS) =
( # CS/PS RAB Assignment Complete / # CS/PS RAB Assignment Request)
3.1.1.1 CS CSSR (%)
(For CS connection requests)
∑ pmNoRabEstablishSuccess(RAB)


pmTotNoRrcConnectReqCsSucc
(RAB)




100 *
*
 (pmTotNoRrcConnectReqCs - pmNoLoadSharingRrcConnCs)  [ ∑ pmNoRabEstablishAttempt(RAB)] - pmNoDirRetryAtt 
 (RAB)

where (RAB) = Speech, Cs64, Cs57
Low value (e.g. <95%) indicates problems to establish a CS call between UEs and CS domain CORE.
Similar formulas can be used for each specific RAB CSSR, i.e., Speech CSSR (%) or CS64 CSSR (%).
Note that by removing pmNoDirRetryAtt from the denominator, those redirected speech calls attempts are excluded
from the calculation. So if their establishments succeed or fail in GSM is not taken into account in this KPI
3.1.1.2 PS CSSR (%)
(For PS connection requests, both R99 PS and HS)
 ∑ pmNoRabEstablishSuccess(RAB) 
pmTotNoRrcConnectReqPsSucc


 (RAB)

100 *
*
 (pmTotNoRrcConnectReqPs - pmNoLoadSharingRrcConnPs)   ∑ pmNoRabEstablishAttempt(RAB) 
 (RAB)

where (RAB) = PacketStream, PacketStream128, PacketInteractive
Low value (e.g. <95%) indicates problems to establish a PS call between UEs and PS domain CORE.
Similar formulas can be used for each specific RAB CSSR, i.e., PS Streaming CSSR (%) or PS Interactive CSSR (%).
Refer to the internal Claro doc. “Optimization Guidelines: Capacity in Ericsson” (DEO.OTM.IOP3041) for further details
regarding the Ericsson features Load Sharing and Directed Retry.
From P7.1 (P7 FP), current release in Claro, new counters are available for monitoring the performance of the NAS
Signalling phase (i.e. after IU Signalling Connection establishment and before RAB Assignment Request).
New formulas will also cover the Iu Signalling Connection phase performance through counters already available
before P7.1 in MO RNCFunction; therefore, the same Iu Sig. Conn. Success Rate value is to be applied to all UtranCells
under the same RNC.
As the new formulas below will compute failures in these 2 additional phases (see next figure), a slight degradation in
these KPIs might be observed after their introduction when comparing to old formulas above.
3.1.1.3
CS CSSR (%) –from P7.1-
pmTotNoRrcConnectReqCsSucc

 *  pmNoIuSigEstablishSuccessCs  *
 (pmTotNoRrcConnectReqCs - pmNoLoadSharingRrcConnCs)   pmNoIuSigEstablishAttemptCs 
 [ ∑ pmNoRabEstablishSuccess(RAB) ] + pmNoDirRetrySuccess + pmNoInCsIratHoSuccess 
1 −  pmNoSystemNasSignReleaseCs  *  (RAB)

  pmTotNoRrcConnectReqCsSucc  

[ ∑ pmNoRabEstablishAttempt(RAB)] + pmNoInCsIratHoAtt


(RAB)
100 *
where (RAB) = Speech, Cs64, Cs57
Note that 2 important additions have been made to this KPI:
1.
By adding pmNoDirRetrySuccess in the RAB term numerator, this KPI does take into account the success rate of the
speech calls redirected to gsm by the Directed Retry mechanism.
2.
By adding pmNoInCsIratHoSuccess/Att counters in the RAB term, this KPI now also takes into account the success
rate of the Speech Calls entering the 3G network via Incoming CS IRAT HO.
3.1.1.4
PS CSSR (%) – from P7.1-
pmTotNoRrcConnectReqPsSucc + pmTotNoRrcConnectSuccessIratCellResel + pmTotNoRrcConnectSuccessIratCcOrder

*
 (pmTotNoRrcConnectReqPs - pmNoLoadSharingRrcConnPs) + pmTotNoRrcConnectAttIratCellResel + pmTotNoRrcConnectAttIratCcOrder 
 ∑ pmNoRabEstablishSuccess(RAB) 
 pmNoIuSigEstablishSuccessPs  * 1 −  pmNoSystemNasSignReleasePs  *  (RAB)



 pmNoIuSigEstablishAttemptPs    pmTotNoRrcConnectReqPsSucc   ∑ pmNoRabEstablishAttempt(RAB) 
 (RAB)

100 *
where (RAB) = PacketStream, PacketStream128, PacketInteractive
Note that one important addition has been made to this KPI:
1.
By adding pmTotNoRrcConnectSuccess(Att)IratCellResel(CcOrder) counters in the RRC term, this KPI now also takes
into account the success rate of the PS Calls entering the 3G network via Incoming IRAT Cell Change Order or IRAT Cell
Reselection.
[Pending Confirmation from Ericsson]
3.1.2
Overall Service Accessibility - OSAC (%)
Since there are many different services defined in UMTS and each one can have a different accessibility at any time,
an overall service accessibility can be defined to obtain an overall measure of network accessibility averaged over all
services. This metric can be used in case one single measurement is to be applied to sort out the worst overall
inaccessible cells.
The OSAC criterion will be based on a weighted averaging of the accessibility for the CS and PS services supported by
the cell. The weighting factors will be chosen to be the demand for the service given by the number of RAB Establish
attempt for that service.
OSAC = 100 * [(CS CSSR * CS RAB Assignment Request) + (PS CSSR * PS RAB Assignment Request)] /
Sum(# CS & PS RAB Assignment Request)
where:
CS/PS CSSR = Call Setup Success Rate, as described in the previous section.
Or simplifying:
100 * [(CS_RRC_SSR * CS RAB Assignment Complete) + (PS_RRC_SSR * PS RAB Assignment Complete)] /
Sum(# CS & PS RAB Assignment Request)
where:
CS/PS_RRC_SSR = RRC Setup Success Rate (with CS/PS Establishment Causes) =
(# CS/PS RRC Connection Setup Complete / # CS/PS RRC Connection Request)
The KPI can be built for Ericsson in the following way
(load sharing, directed retry, Iub Sign. & NAS connection establishments have been omitted for simplicity):

 pmNoRabEstablishSucc essSpeech 








 + pmRabEstablishEcSucc ess
 

  pmTotNoRrcConnectReqCsSucc   + pmNoRabEstablishSuccessCs64  pmNoRabEstablishAttemptSpeech  

 +
  pmTotNoRrcConnectReqCs  *  pmNoRabEstablishAttemptSpeech  * + pmRabEstablishEcAttempt


 + pmNoRabEstablishAttemptCs64  



 + pmRabEstablishEcAttempt







 + pmNoRabEstablishAttemptCs64 

 


 
  pmTotNoRrcConnectReqPsSucc  *  pmNoRabEstablishSuccessPacketInteractive  * [pmNoRabEstablishAttemptPacketInteractive ]  

  pmTotNoRrcConnectReqPs   pmNoRabEstablishAttemptPacketInteractive 

100 *
pmNoRabEstablishAttemptSpeech + pmRabEstablishEcAttempt +

pmNoRabEstablishAttemptCs64 + pmNoRabEstablishAttemptPacketInteractive 
Simplifying:
100 *
  pmTotNoRrcConnectReqCsSucc  pmNoRabEstablishSuccessSpeech  
 * + pmRabEstablishEcSucc ess
 
 +
  pmTotNoRrcConnectReqCs  + pmNoRabEstablishSuccessCs64  

 

  pmTotNoRrcConnectReqPsSucc  * [pmNoRabEstablishSuccessPacketInteractive ]
  pmTotNoRrcConnectReqPs 
pmNoRabEstablishAttemptSpeech + pmRabEstablishEcAttempt +

pmNoRabEstablishAttemptCs64 + pmNoRabEstablishAttemptPacketInteractive 








3.2 Medium Level KPIs
3.2.1 RRC Connection Success Rate (%)
(For all connection requests)
100 *
pmTotNoRrcConnectReqSuccess


 pmTotNoRrcConnectReq - (pmNoLoadSharingRrcConn - pmNoOfReturningRrcConn) 
Low value (e.g. <95%) indicates problems to establish a generic radio connection between UEs and RNC starting from
idle mode state.
Notes:
•
pmNoOfReturningRrcConn (number of Load Sharing diversions when establishing an RRC connection that returns to
the first frequency) is not available per domain (CS, PS), so next two metrics are missing this correction.
•
RRC
connection
attempts
are
not
corrected
for
emergency
calls
redirections.
Counters
pmNoOfRedirectedEmergencyCalls and pmNoOfReturningEmergencyCalls (MO RNCFunction) could be used to estímate their
contribution at RNC level.
•
Due to the fact that the UE may perform cell re-selection during the RRC Connection establishment (it may repeat
RRC Connection Request message N300 times which may arrive at different cell) and the fact that WCDMA RAN (the RNC)
does not double count the duplicated RRC Connection Request messages received, there is a chance that the RRC access
success rate for some cells may show values above 100%. The access success rate better than 100% happens when the
attempt is registered in a cell different to the cell where the success is registered. The end result is a slightly better success
rate for the cell that completes the access and a slightly worst success rate for the cell where the access was
attempted/started.
3.2.1.1 RRC Connection Success Rate CS (%)
(For CS connection requests)
100 *
pmTotNoRrcConnectReqCsSucc


 pmTotNoRrcConnectReqCs - pmNoLoadSharingRrcConnCs 
Low value (e.g. <95%) indicates problems to establish a radio connection between UEs and RNC starting from idle
mode state in particular affecting CS services (speech and video calls).
3.2.1.2 RRC Connection Success Rate PS (%)
(For PS connection requests)
100 *
pmTotNoRrcConnectReqPsSucc


 pmTotNoRrcConnectReqPs - pmNoLoadSharingRrcConnPs 
Low value (e.g. <95%) indicates problems to establish a radio connection between UEs and RNC starting from idle
mode state in particular affecting PS services.
3.2.2 Iu Signalling Establishment Success Rate (%)
(For all connection requests)
100 *
 pmNoIuSigEstablishSuccessCs + pmNoIuSigEstablishSuccessPs 
 pmNoIuSigEstablishAttemptCs + pmNoIuSigEstablishAttemptPs 
Low value (e.g. <95%) indicates problems to establish the Iu part of the Control Plane between the RNC and CORE.
Note these counters are in MO RNCFunction (hence, only available at RNC level).
3.2.2.1 Iu-CS Signalling Establishment Success Rate (%)
(For CS connection requests)
100 *
 pmNoIuSigEstablishSuccessCs 
 pmNoIuSigEstablishAttemptCs 
Low value (e.g. <95%) indicates problems to establish the Iu part of the Control Plane between the RNC and CS
domain CORE.
3.2.2.2 Iu-PS Signalling Establishment Success Rate (%)
(For PS connection requests)
100 *
 pmNoIuSigEstablishSuccessPs 
 pmNoIuSigEstablishAttemptPs 
Low value (e.g. <95%) indicates problems to establish the Iu part of the Control Plane between the RNC and PS
domain CORE.
3.2.3 NAS Signalling Establishment Success Rate (%) –from P7.1(For all connection requests)


 pmNoSystemNasSignReleaseCs + pmNoSystemNasSignReleasePs 

 pmTotNoRrcConnectReqCsSucc + pmTotNoRrcConnectReqPsSucc 
100 * 1 − 
Low value (e.g. <95%) indicates problems to establish the Iu part of the Control Plane between the RNC and CORE.
Note these counters are in MO RNCFunction.
3.2.3.1 NAS CS Signalling Establishment Success Rate (%) – from P7.1(For CS connection requests)


 pmNoSystemNasSignReleaseCs 

 pmTotNoRrcConnectReqCsSucc 
100 * 1 − 
Low value (e.g. <95%) indicates problems to establish the Iu part of the Control Plane between the RNC and CS
domain CORE.
3.2.3.2 NAS PS Signalling Establishment Success Rate (%) – from P7.1(For PS connection requests)


 pmNoSystemNasSignReleasePs 

 pmTotNoRrcConnectReqPsSucc 
100 * 1 − 
Low value (e.g. <95%) indicates problems to establish the Iu part of the Control Plane between the RNC and PS
domain CORE.
3.2.4
(RAB) Establishment Success Rate (%)
100 *
 pmNoRabEstablishSuccess(RAB) 
 pmNoRabEstablishAttempt(RAB) 
Where (RAB) = Speech, Cs64, Cs57, PacketInteractive, PacketInteractiveHs, PacketInteractiveEul, PacketStream,
PacketStream128 or PacketStreamHs.
Note that these counters for PacketInteractive include also PacketInteractiveHs, and counters for PacketInteractiveHs
include also PacketInteractiveEul.
For Speech RAB, please refer to comments on Section 3.1.1.3 regarding different possibilities to modify this formula
for RAB Establishment Success Rate so it can also cover as 3G access failures those directed retries to gsm and
incoming IRAT HO’s that fail.
Low value (e.g. <95%) indicates problems to establish a RAB after the RAB assignment coming from the CORE
network.
3.2.5
100 *
Sending Paging Failure Rate (%)
pmNoPageDiscardCmpLoadC + pmNoPagingAttemptUtranRejected


 pmCnInitPagingToIdleUe + pmCnInitPagingToIdleUeRa + pmCnInitPagingToIdleUeLa + pmNoPageDiscardCmpLoadC 
High value (e.g. >2%) indicates problems to send paging through the radio network due to overload.
Formula above is valid if URA_PCH state is disabled (current situation in Claro). In case it is enabled, the Formula
should be replaced by the following one:
100 *
( pmNoPageDiscardCmpLoadC + pmNoPagingAttemptUtranRejected )
 pmCnInitPagingToIdleUe + pmCnInitPagingToIdleUeRa + pmCnInitPagingToIdleUeLa + 
 pmCnInitPagingToUraUe + pmUtranInitPagingToUraUe + pmNoPageDiscardCmpLoadC 
[Pending Confirmation from Ericsson]
3.2.6
Blocking Probability
Implemented through the GRADE OF SERVICE (GoS): Probability of a call in a circuit group being blocked or delayed
for more than a specified interval, expressed as a common fraction or decimal fraction.
3.2.6.1 GoS Speech (%)
[Check this at cell level].
   pmNoRrcCsReqDeniedAdm     pmNoOfNonHoReqDeniedSpeech   
  * 1 − 
 
1 − 
   pmTotNoRrcConnectReqCs     pmNoRabEstablishAttemptSpeech   
100 * 1 -
High value (e.g. >2%) indicates problems to establish a Voice call mainly related to Admission Control, i.e., due to
some kind of capacity shortage (DL TX Power, CE, OVSF codes,…).
This metric could be used to identify a wider range of reasons behind access failures: not only RN admission blocking
(as above), but also TN congestion or TN failure (as in the alternative formula below):
   pmNoRrcCsReqDeniedAdm + pmNoRrcConnReqBlockTnCs  

 *
  1 − 

pmTotNoRrcConnectReqCs

100 * 1 - 

pmNoOfNonHoReqDeniedSpeech + pmNoRabEstBlockTnSpeechBest  
  1 − 
  
pmNoRabEstablishAttemptSpeech
  
  
3.2.6.2 GoS PS (%)
[Check this at cell level].
   pmNoRrcPsReqDeniedAdm     pmNoOfNonHoReqDeniedInteractive   
  * 1 − 
 
1 − 
   pmTotNoRrcConnectReqPs     pmNoRabEstablishAttemptPacketInteractive   
100 * 1 -
High value (e.g. >2%) indicates problems to establish a Voice call mainly related to Admission Control, i.e., due to
some kind of capacity shortage (DL TX Power, CE, OVSF codes,…).
This metric could be used to identify a wider range of reasons behind access failures: not only RN admission blocking
(as above), but also TN congestion or TN failure (as in the alternative formula below):
   pmNoRrcPsReqDeniedAdm + pmNoRrcConnReqBlockTnPs  

 *
  1 − 

pmTotNoRrcConnectReqPs

100 * 1 - 

pmNoOfNonHoReqDeniedInteractive + pmNoRabEstBlockTnPsIntNonHsBest + pmNoRabEstBlockTnPsIntHsBest  
  1 − 
  
pmNoRabEstablishAttemptPacketInteractive
  
  
GoS can be estimated for other RABs in a similar way: CS, PS Streaming DCH, PS Streaming HS.
3.3 Failures after Admission Rate (%):
This KPI provides the number of Radio Resource Control (RRC) or Radio Access Bearer (RAB) establishment requests
failed after being admitted by Admission Control (AC).
100 *
 pmNoFailedAfterAdm 
 pmTotNoRrcConnectReq 
High value (e.g. >5%) indicates problems accessibility problems happening once the RRC or RAB has been admitted
by AC. These issues are analyzed later in this document.
4 PERFORMANCE ANALYSIS
Following the Hierarchical KPIs
methodology described in the internal Claro doc. “Optimization Process”
(DEO.OTM.IOP3000), once identified areas/nodes/cells showing bad performance through the overall KPIs defined
above, analysis to find out the cause root of the problem should be performed. To do so, we move towards an indepth analysis based in more detailed and specific raw counters (Low Level KPIs).
In the case of Ericsson infra, this analysis for Accessibility issues will explore in 3 different directions:
Note: A 4th line of investigation has been added at the end of the section to cover those Accessibility issues not
detected by counters.
4.1 Admission Control
The purpose of the Admission Control is to limit the traffic that is admitted in order to ensure that all traffic that is
admitted meets the requirements on the quality of the service.
4.1.1
Admission Policy
When new resources are needed for a radio connection, the RN Admission Control function receives a request for
admission. The request specifies the estimated amount of system resources that the radio connection needs.
In Ericsson, a request can be guaranteed or non-guaranteed:
•
A request is guaranteed when requesting minimum amount of resources for a radio connection satisfying the QoS
(this is referred to lowest retainable rate). Example of a guaranteed request is Speech, CS conversational, CS or PS streaming
and PS interactive 8/8.
•
When the request is for resources exceeding the minimum needed for satisfying the QoS (for example up-switch
interactive PS to a higher dedicated rate), the request is non-guaranteed. Example of a non-guaranteed request is PS
interactive.
4.1.2
4.1.2.1
Resources to be monitored
RF Power
Lack of Downlink Power (pmNoFailedRabEstAttemptLackDlPwr)
Note: The RF power is measured and regulated at the reference point and also the power limits have to be calculated
at the reference point.
4.1.2.2
Code Tree Consumption
Lack of Canalization Code (pmNoFailedRabEstAttemptLackDlChnlCode)
Note: The code tree consumption is measured in percentage of the total tree size by excluding the fixed codes
allocated for HSDPA (i.e. the higher the number of codes allocated for HSDPA the smaller will be the available tree and
higher the relative consumption).
The admission limit is set by dlCodeAdm (as a percentage).
4.1.2.3
DL and UL ASE
Lack of Downlink ASE (pmNoFailedRabEstAttemptLackDlAse)
Lack of Uplink ASE (pmNoFailedRabEstAttemptLackUlAse)
Note: ASE is used as an overall measurement of the cell load on the air interface but ASE is not a real cell resource. It
intends to express the static load on the air-interface caused by radio bearers in a cell, relative to the static load
caused by a set of conversational.
4.1.2.4
SF Code Limit (Code Hystogram)
Exceed SF histogram (pmNoFailedRabEstAttemptExceedConnLimit)
Note: In order to limit the number of high codes and HW consumption RABs specific thresholds are set for each SF.
4.1.2.5
HSDPA and EUL connections Limit
RN Admission Control blocks new radio link admission requests which involve the allocation to HS-DSCH/HS-SCCH
when the number of users assigned to the HS-DSCH in the cell exceeds the load control level hsdpaUsersAdm. RN
Admission Control shall reject an EUL user, requesting the cell as serving cell if the total number of serving cell EUL
users including the requested is above eulServingCellUsersAdm.
4.1.2.6
UL and DL Channel Elements
Lack of DL Channel Elements (pmNoFailedRabEstAttemptLackDlHw)
Lack of UL Channel Elements (pmNoFailedRabEstAttemptLackUlHw)
Note: The HW resources are monitored by Admission Control as ay other physical resource. Soft congestion is used to
control the overload. The following thresholds are used: dlHwAdm, ulHwAdm
4.1.3
RRC Admission Blocks
It is possible also to check separately CS and PS RRCs and evaluate the success:
If low pmTotNoRrcConnectCsReqSucc / pmTotNoRrcConnectReqCs, then check: pmNoRrcCsReqDeniedAdm
If low pmTotNoRrcConnectPsReqSucc / pmTotNoRrcConnectReqPs, then check: pmNoRrcPsReqDeniedAdm
4.1.4
RAB Admission Blocks
You must compare the RAB establishments blocked by admission control with the RAB attempts:
100 *
pmNoOfNonHoReqDeniedSpeech
pmNoRabEstablishAttemptSpeech
100 *
pmNoOfNonHoReqDeniedCs
(pmNoRabEstablishAttemptCs64 + pmNoRabEstablishAttemptCs57)
pmNoOfNonHoReqDeniedInteractive
100 *
pmNoRabEstablishAttemptPacketInteractive
100 *
pmNoOfNonHoReqDeniedPsStreaming
pmNoRabEstablishAttemptPacketStream
pmNoOfNonHoReqDeniedHs
100 *
pmNoRabEstablishAttemptPacketInteractiveHs
pmNoOfNonHoReqDeniedEul
100 *
pmNoRabEstablishAttemptPacketInteractiveEul
pmNoOfNonHoReqDeniedPsStr128
100 *
pmNoRabEstablishAttemptPacketStream128
Note: RAB admission blocks could have more impact on accessibility compared to RRC blocks, especially for PS
services, since the required resources during the RAB assignment are higher.
4.2 MP Load (High processor Load)
Check pmNoRejRrcConnMpLoadC - Number of rejected RRC connections due to MP load control.
Note: The module MP handles signalling associated with traffic events.
Connection setup and release (Speech, PS R99, HS, LA update, SMS).
4.3 After Admission
Number of Radio Resource Control (RRC) or Radio Access Bearer (RAB) establishment requests failed after being
admitted by admission control.
If either a RRC or RAB establishment procedure fails AFTER the admission has been granted for the establishment
(RRC or RAB), counter pmNoFailedAfterAdm will be incremented at the cell or cells where the UE is located.
•
•
•
Follows a list of causes for failures after admission:
• Transport failures
TN failure reasons
AAL2 setup failure (due to congestion or miss configuration)
• Code allocation failures
• Channel elements allocation failures
NBAP RL setup failure (RAX or TXB congestion)
• HW fault in the RBS
• UE failures
• Timeout in the UE, RNC or RBS
• Invalid parameter settings
4.3.1
Failure after Admission: Iub Congestion
Iub congestion is a common reason for high number of failures after admission events.
Depending on the volume of traffic per service or RAB, certain QoS could be congested at the AAL2: All RABs
excluding HSDPA are configured to use Class A or Class B being these two mostly impacted by congestion. Most of the
time Class B is the first QoS to get congested leading to failures after admission events.
Iub congestion could also be caused by E1 issues.
Misconfiguration of AAL2 profile at the Node B, RNC or RXI/MSN can lead to Iub congestion as well.
•
•
Possible indicators:
Check for congestion at the Iub link (See below)
Check for E1 issues and history of alarms of E1s (for intermittent E1 alarms)
Possible solutions for Iub congestion:
Enable Directed retry (short term solution).
Correct possible AAL2 miss configuration at Node B, RNC and RXI (AAL2 profile must match in all entities)
Order new E1s (long term solution).
Change AAL2 QoS configuration depending on services request volume (CS voice, R99 data, HSDPA, etc).
4.3.1.1
Low RRC Success Rate
In case a poor RRC Success Rate is detected and neither Admission Blocks nor MP Load rejections can explain such a
degradation of the RRC Accessibility, then check these 2 counters:
pmNoRrcConnReqBlockTnCs
RRC CS failures due to congestion on the user plane (AAL2) or control plane (UniSaal or SCTP) of the transport
network.
pmNoRrcConnReqBlockTnPs
RRC PS failures due to congestion on the user plane (AAL2) or control plane (UniSaal or SCTP) of the transport
network.
If none of the above counter values can explain the poor RRC success rate more traces have to be considered e.g.
UETR (AAL2) or control plane (UniSaal or SCTP) of the transport network.
4.3.1.2
Low RAB Success Rate
Similar analysis can be done for RABs Blocked due to transport network congestion including:
•
Speech:
pmNoRabEstBlockTnSpeechBest
100 *
pmNoRabEstablishAttemptSpeech
•
Videocall:
100 *
pmNoRabEstBlockTnCs64Best
pmNoRabEstablishAttemptCs64
•
PS R99:
pmNoRabEstBlockTnPsIntNonHsBest
100 *
(pmNoRabEstablishAttemptPacketInteractive - pmNoRabEstablishAttemptPacketInteractiveHs)
•
HSDPA:
100 *
pmNoRabEstBlockTnPsIntHsBest
pmNoRabEstablishAttemptPacketInteractiveHs
4.3.2
Failure after Admission: Core Transport Network Congestion
Accessibility issues are observed on all sites at the RNC without major issues with Iub congestion (especially at peak
hour): Congestion will be observed at Iu-CS (RNC<-->MGW) or Iu-PS (RNC<-->SGSN) links.
•
Possible indicators:
Degradation of KPIs Iu(CS/PS) Signalling Establishment Success Rate (%) would be expected in this case.
Note: Congestion will be observed at Aal2 access point (Aal2Ap) entity starting with “g”.
(Aal2Ap entities starting with “b” correspond to node b, starting with “r” corresponds for Iur links, etc)
•
Possible solutions:
This issue will require support from the Operation and Maintenance department (OMC) in order to determine the
reasons for that high utilization over Iu-CS and Iu-PS links.
4.3.3
Failure after Admission: Hardware Usage (Channel Elements)
Lack of channel elements could be due to insufficient UL (RAX board) or DL (TX board) hardware capacity. Channel
element capacity could be also software limited. Admission control is restricted by ulHwAdm and dlHwAdm
parameters. They should be set at 100% so no hardware is limited for RRC/RAB setup.
•
•
Possible indicators:
High number of AC block events on LackDlHw would indicate issues with TX board and LackUlHw would indicate
issues with RAX board.
Congestion at RAX or TX could be indicated by RBS counters pmUlCredits and pmDlCredits respectively.
Congestion per spreading factor (SF) can be also measured using pmSetupFailureSfXX RBS counters from the
BasebandPool (BBP) on the uplink (UL BBP) and the downlink (DL BBP).
Possible solutions:
Check that ulHwAdm and dlHwAdm parameters are set to 100%
Check numHsResources, numEulResources at the node B (long term solution)
Reduce value of sf8Adm to 0 (short term solution)
Check for hardware failures on RAX and TXB boards and given the case, order its replacement.
Order an additional new RAX or TXB board, depending on the specific case.
4.3.4
Failure after Admission: Channelization Codes
This could also be a reason for Failures after Admission, but it is expected to be correlated with high figures also in the
counter for admission blocks due to lack of channelization codes (pmNoFailedRabEstAttemptLackDlChnlCode).
•
Possible solutions:
Reduce the AC threshold for connections with low SF (specially 8 in DL, 4 in UL). Short Term Solution.
Real need for additional OVSF codes (purely due to increase in traffic) will require of new carrier/sector/site
analysis. [Refer to doc. “Optimization Guidelines: Capacity in Ericsson” (DEO.OTM.IOP3041), for further details
regarding the methodology to decide the best option between New Carrier or New Sector or New Site].
4.3.5
Failure after Admission: Others
If a site shows none of the previously described issues, then it is likely to be a more complicated problem to solve;
often relating to a software/hardware fault, or perhaps an external source of interference in the area.
Check for neighboring sites: Remember that neighboring sites having AAL2 congestion can cause other cells to have
high number of failures after admission (due to soft handover)
Check that software revisions are up to date at the Node B
Check for unexpected figures in counter pmNoInvalidRabEstablishAttempts.
RANAP RAB Assignment message is received for RABs to be setup/modified and the received QoS parameters
cannot be mapped to a supported RAB type or if the data in the message contains a critical logical error.
4.4 Accessibility issues not detected by counters
•
•
•
Some kinds of RRC failures could not be detected by counters or other traces. This typically happens when the RRC
Connection Request messages from the UE cannot reach the RNC. In this case the accessibility KPIs are not able to
reveal the problem, but it could be reported by
user’s claims or
drive test activities or
variations of the traffic level.
Typical causes are:
4.4.1
•
•
•
HW Problems in the RBS
Antenna system failures
RAX boards failures
Cell unavailability
Most of the related problems should raise an alarm.
4.4.2
UL Interference
Strong UL Interference could also be the cause of some Accessibility issues not clearly detected by counters described
so far. It can be monitored by checking:
90th percentile of pmAverageRssi > -90 dBm or (pmSumUlRssi / pmSamplesUlRssi) > -95 dBm
4.4.3
RACH misconfiguration
Check RACH parameters to look for a wrong setting:
aichPower
powerOffsetP0
powerOffsetPpm
preambleRetransMax
maxPreambleCycle
constantValueCprach
maxTxPowerUl
4.4.4
Cell Unavailability
Check Cell unavailability through the following counters:
pmcellDownTimeAuto
pmCellDownTimeMan
4.4.5
Node Blocking
Counters: pmNoRabEstBlockNode<RAB>, where <RAB> = Speech, Cs64, Cs57, PsIntNonHs, PsIntHs, PsStrHs
These counters are stepped when the establishment of a RAB fails due to node configuration error, node limitation, or
transport network layer service unavailability.
Additional detail can be obtained for the impact of Node blocking on RRC:
pmNoRrcConnReqBlockNodeCs
pmNoRrcConnReqBlockNodePs
5 REFERENCES
[1] WCDMA (UMTS) Deployment Handbook. Planning and Optimization Aspects. Christophe Chevallier, Christopher
Brunner, Andrea Garavaglia, Kevin P. Murray, Kenneth R. Baker (All of QUALCOMM Incorporated California, USA). Ed.
John Wiley & Sons. 2006
[2] Radio Network Planning and Optimisation for UMTS. Jaana Laiho and Achim Wacker [Both of Nokia Networks,
Nokia Group, Finland] & Toma´ sˇ Novosad [Nokia Networks, Nokia Group, USA]. Ed. John Wiley & Sons. 2006
[3] WCDMA Radio Access Network Optimization. LZT 123 8297 R1C. Ericsson 2006.
[4] Accessibility-Analysis and Monitor Rev4. Guidelines delivered by Ericsson Brazil to Claro in Nov.2009
[5] Introduction to UMTS Optimization. Wray Castle, 2004
•
•
•
•
[6] ALEX libreries, Ericsson Documentation. P7 & P7.1.
Radio Network Controller (RNC) 3810 (CXP 901 2011 RXX)
RXI 820 ATM R4.1 (CXP 901 102/3 RXX)
Radio Base Station (RBS) 3202/3206/3402/3412 (CXP 901 0811/X RXX)
WCDMA RAN (CXS 101 06/4 RXX)
6 ANNEX I: UE Idle Mode Procedures
PLMN selection is the first step in the registration process that allows a UE to initiate or receive services from an
operator. The UE normally operates on its Home PLMN. However, a Visited PLMN (VPLMN) may be selected if the UE
loses coverage.
A UE successfully registers on a PLMN if it finds a suitable cell to camp on within the selected PLMN. The UE will then
obtain a location or routing registration acknowledgement in the area of the cell on which it is camped. The UE
displays to the user that this PLMN is registered.
When a UE does not find a suitable cell in the selected PLMN, it tries to camp on any other acceptable cell within an
allowed PLMN.
When there is a suitable cell available normal services can be obtained in the cell. If there is an acceptable cell
available only emergency calls are available, and if in automatic mode, new PLMN selection.
6.1 PLMN Selection and Reselection
•
o
o
o
•
PLMN selection is a NAS function, but the AS provides the list of available PLMNs from which the selection is made.
AS reports all successfully read PLMN identities to the NAS, in 2 groups:
Those that meet the high quality criterion:
RSCP CPICH >= -95 dBm, for FDD cells
RSCP CPICH >= -84 dBm, for TDD cells
RSSI CPICH >= -85 dBm, for GSM cells
Those that do not. These ones together with their measured CPICH RSCP value, so they can be ranked.
The standard allows for the optimization of this measuring and reporting process through the use of stored information
in the UE regarding carrier frequencies and other cell parameters as scrambling codes.
Once a suitable list of available PLMNs is compiled, it is up to the NAS to select a PLMN for registration. This may be
done automatically or manually. IN automatic mode the available PLMNs are listed in priority order and the highest
priority PLMN is selected. In manual mode a list of the available PLMNs is presented to the user in priority order, but
the user may select any PLMN from the list.
Prioritization for both modes is as follows:
1.
2.
3.
Home PLMN (HPLMN)
PLMNs in the “User Controlled PLMN Selector with Access Technology” data field in the SIM in priority order.
PLMNs in the “Operator Controlled PLMN Selector with Access Technology” data field in the SIM in priority order.
4.
5.
Other PLMNs that meet the high-quality criterion in random order.
Other PLMNs that do not meet the high-quality criterion in order of decreasing signal quality.
Once a PLMN is selected this is indicated to the AS along with the selected radio access technology.
6.2 Reading System Information
•
•
The System Information Block (SIB) messages are sent on BCCH logical channel, which can be mapped:
to the BCH for UEs in idle mode, Cell_PCH and URA_PCH
or the FACH transport channel for UEs in Cell_FACH.
To inform the UE if a change in System information has occurred, the MIB also delivers a value tag for each SIB.
To inform UEs in idle mode, Cell_PCH and URA_PCH of a change in the system information, paging (“Paging type 1”)
is used to deliver the IE “BCCH modification info” to notify the new value tag for the MIB. WCDMA RAN can also
inform of the change in the system information with a System Information Change Indication message on the FACH
transport channel.
6.3 Cell Selection and Reselection
Refer to the “Configuration Guideline: Idle Mode Settings” for a more detailed description.
6.3.1
Cell Selection
Next figures summarize the process.
6.3.2
Cell Reselection
Next figure summarizes the process.
6.3.3
Location/Routing Area Update
LA and RA updating is necessary to inform the CN of the current LA or RA of the UE, so that the network can send a
paging message to the UE.
•
•
•
There are three types of LA and RA registration updates:
International Mobile Subscriber Identity (IMSI) attach or detach
Normal LA and RA updating
Periodic LA and RA updating (T3212, T3312)
A border RBS can handle less traffic than an RBS placed inside the LA, due to the increased signalling load. Therefore,
it is recommended that he LA/RA borders should be placed in areas with low traffic.
If the LAs/RAs are small, there will be more LAUs/RAUs in the system and a high number of border RBSs. On the other
hand, if the LAs/RAs are large the number of paging messages will increase.
If the same LAI/RAI is used for the GSM and WCDMA networks, the consequence is heavy paging load in 3G arising
from the GSM subscribers.
RRC MODES and STATES
LA/RA UPDATE vs. CELL UPDATE vs. URA UPDATE
6.3.4
•
•
•
Paging Procedure
Paging Type 1 (to UE in idle mode or dormant state: Cell_PCH/URA_PCH)
UE terminating service request for PS or CS services (CN initiated).
UTRAN initiated broadcast to inform UEs when SI is modified.
Channel switch from state URA_PCH to CELL_FACH (UTRAN initiated)
Two different physical channels are used in order to exchange proper information between the WCDMA RAN and the
UE: the PICH and the S-CCPCH (carries the PCH). There is a fixed timing relation between a PICH frame and the
associated S-CCPCH frame.
Discontinuous Reception (DRX): The UE listens to the PICH only at certain predefined times, reducing power
consumption.
The paging record varies in length depending on whether it includes the UE identity in terms of IMSI, TMSI, or PTMSI. A PCH frame can carry one “Paging Type 1” message of 10 ms and may contain between 3-5 paging records,
depending on whether the paging uses IMSI or TMSI/P-TMSI.
•
Paging Type 2 (to UE in Cell_DCH or Cell_FACH)
UE terminating service request for PS or CS services (CN initiated).
When a connection exists between the WCDMA RAN and the UE, the SRNC determines that a RRC connection has
already been established by this UE and the RRC message "Paging type 2" is used to carry paging information. Since it
is sent on a dedicated control channel, this message is intended only for one particular UE.
For paging, the capacities of the FACH and the RACH are assumed to be enough, but there is a risk of congestion in
the PCH due to heavy paging load. Therefore, the probability of congestion in the PCH must be calculated in order to
dimension the LA/RA.
7 ANNEX II: Call Establishment Procedure
7.1 Voice Call Establishment
7.2 PS Data Call Establishment
7.3 Radio Resource Control (RRC)
RRC is the overall controller of the Access Stratum, responsible for configuring all other layers in the Access Stratum
and providing the control and signalling interface to the NAS layer.
•
•
•
•
Broadcast of System Information
RRC Connection Management
Radio Bearer Management
RRC Mobility Functions
•
•
•
•
•
Paging and Notification Functions
Routing of Higher Layer Messages
Control of Ciphering and Integrity Protection
Measurement Control and Reporting
Power Control Functions
RRC manages radio resources, including allocation, deallocation, and configuration of Logical, Transport, and Physical
Channels, measurement reporting, security procedures, and overall management of the Access Stratum.
7.3.1
RRC connection Request & Setup
The RRC Connection Setup establishes SRBs (Signalling Radio Bearers) to carry dedicated signalling.
This phase of the call establishment is identical for CS and PS calls (both MO and MT) and it is always composed by
next three messages:
1.
2.
3.
RRC Connection Request (RACH, in UL)
RRC Connection Setup (FACH, in DL)
RRC Connection Setup Complete (DCH, in UL)
It is important to note that this signalling is also needed when the UE performs Periodic Registration/ LAU/RAU/Detach
as part of the Mobility Management. In these cases, the purpose of the RRC connection setup is not to establish a call
(CS or PS), and therefore, there will not be RAB setup phase.
The RRC connection request contains the UE identity, optional cell measurement results, and the establishment cause.
3GPP TS 25.331 V8.3.1
Radio Resource Control (RRC); Protocol Specification (Release 8)
Section. 10.3.3.11. ESTABLISHMENT CAUSE
Originating Conversational Call,
Originating Streaming Call,
Originating Interactive Call,
Originating Background Call,
Originating Subscribed traffic Call,
Terminating Conversational Call,
Terminating Streaming Call,
Terminating Interactive Call,
Terminating Background Call,
Emergency Call,
Inter-RAT cell re-selection,
Inter-RAT cell change order,
Registration,
Detach,
Originating High Priority Signalling,
Originating Low Priority Signalling,
Call re-establishment,
Terminating High Priority Signalling,
Terminating Low Priority Signalling,
Terminating – cause unknown,
MBMS reception,
MBMS ptp RB request
For speech AMR service, this cause is recorded as either “Originating Conversational Call” or “Terminating
Conversational Call”. For PS service, this cause is recorded as “Originating/Terminating Interactive/Background Call”.
Successfully establishing the RRC connection is the most challenging part of call setup. This can be attributed to two
factors: the admission control implementation and the size of the RRC Connection Setup message. The latter is the
main challenge. During admission control implementation, an RRC connection reject is sent if no resources are
available for allocation, or if the call should be redirected to a different system or carrier.
After successful resource allocation, the RRC Connection Setup message–which contains SRB information including the
mapping details of dedicated logical, transport, and physical channels–is sent on the Forward Access Channel (FACH)
(over [Downlink Secondary Common Control Physical Channel] [DL SCCPCH]). This RRC Connection Setup message
contains a significant amount of information, and it spans multiple frames while not yet operating in closed loop
power-controlled condition. This makes it difficult for the UE to receive the message, especially if the SCCPCH power
allocation is not set to accommodate low geometry.
After the RRC Connection Setup message is received, the UE can set up the low data rate DCH according to the RRC
Connection Setup message. First, only the PDCCH containing Transmit Power Control (TPC) and Pilot bits are sent to
allow the inner loop power control to converge. Afterwards, the RRC Connection Setup Complete message is used to
acknowledge the setup message and send UE-capability information to the network. At this point, the UE should have
transitioned from Idle state to CELL DCH state. At this time, the connection is power-controlled and may support
handover, depending on the Universal Terrestrial Radio Access Network (UTRAN) implementation. Both features
improve the reliability of the connection.
7.4 Core Network Negotiation
The low data rate DCH facilitates upper layer signaling with the NAS layer, which performs all authentication and
security procedures along with additional processes in the CN to establish the end-to-end connection.
To initiate the connection request to the upper layers, MO calls use the Connection Management (CM) Service Request
and MT calls use the paging response. In the CM Service Request message, the CM Service Type field indicates
“Mobile originating call establishment” as the cause for a MO AMR call. The Paging Response message does not need
to carry service information because the NAS layer already knows what service is being set up for the MT call.
To perform two-way authentication, the UE checks the Authentication Token (AUTN) nd the network checks the
Signed Authentication Response (SRES), which is calculated from the RAND number from the network. Depending on
the supported security capabilities, ciphering and integrity protection are switched on to enable encryption of user data
and signaling messages.
For MO calls, the UE sends main parameters such as bearer capabilities and dialed digits to the network using the Call
Control (CC) Setup message. For MT calls, the network uses the Setup message to send the same, or similar,
information to the UE. The next step is similar; MO calls use Call Proceeding messages (UTRAN to UE), while MT calls
use Call Confirmed messages (UE to UTRAN) as a Layer 3 acknowledgment.
7.5 Radio Access Bearer (RAB) Setup and Reconfiguration
After the CN negotiation, the UE can establish the DCH(s) for the requested service. Existing DCHs also may be
reconfigured to meet the requirements, depending on the current configuration. Before sending the RB Setup
message, call admission control must be checked and resource allocation performed for every resource involved in a
call.
•
•
For AMR voice, the UE typically sets up three dedicated logical/transport channels mapped onto one CCTrCh.
Information in the RB Setup message is similar to the RRC Connection Setup:
NAS Layer 2. Radio Bearer/logical/transport channel mapping
Layer 2. Channel coding, Radio Link Control (RLC) parameters, TTI, BLER targets, Transport Format Combination Set
(TFCS)
•
Layer 1. Spreading Factor (SF), OVSF code, Scrambling Code, frame offset, power control parameters
At this point, the radio link is completely established; however, the end-to-end connection is not yet fully established:
•
•
•
The Alerting message is sent from the network to the UE for MO calls, or from the UE to the network for MT calls.
The directions for Connect and Connect ACKnowledge (ACK) are reversed, depending on the call type.
The Connect message is sent by the UTRAN for MO calls, but by the UE for MT calls.
The RB Setup message can also be used as a reconfiguration message because the existing SRBs are, from this point
forward, multiplexed with RAB onto a single physical dedicated channel.