Documente Academic
Documente Profesional
Documente Cultură
Accessibility in Ericsson
CONTENTS
1 INTRODUCTION.............................................................................................................................3
2 ACCESSIBILITY..............................................................................................................................4
2.1 Idle Mode..................................................................................................................................................4
2.2 Call Establishment Process.....................................................................................................................4
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
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
1 INTRODUCTION
This series of Optimization Guidelines covers all the main topics regarding
Date
13-Nov-2009
Author
QCES/Ericsson
Changes
First Release of the document
Update from P7 to P7.1:
Corrections/Additions::
01
12-Mar-2010
QCES/Ericsson
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.
The UE in Idle mode performs next 5 main tasks [Refer to ANNEX I for a brief review]:
PLMN selection and reselection
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.1
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)
pmNoRabEstablishSuccess(RAB)
pmTotNoRrcConnectReqPsSucc
(RAB)
100 *
*
(pmTotNoRrcConnectReqPs - pmNoLoadSharingRrcConnPs) pmNoRabEstablishAttempt(RAB)
(RAB)
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
pmTotNoRrcConnectReqCsSucc
* pmNoIuSigEstablishSuccessCs *
(pmTotNoRrcConnectReqCs - pmNoLoadSharingRrcConnCs) pmNoIuSigEstablishAttemptCs
[ pmNoRabEstablishSuccess(RAB) ] + pmNoDirRetrySuccess + pmNoInCsIratHoSuccess
1 pmNoSystemNasSignReleaseCs * (RAB)
pmTotNoRrcConnectReqCsSucc
[ pmNoRabEstablishAttempt(RAB)] + pmNoInCsIratHoAtt
(RAB)
100 *
3.1.1.4
*
(pmTotNoRrcConnectReqPs - pmNoLoadSharingRrcConnPs) + pmTotNoRrcConnectAttIratCellResel + pmTotNoRrcConnectAttIratCcOrder
pmNoRabEstablishSuccess(RAB)
pmNoIuSigEstablishSuccessPs * 1 pmNoSystemNasSignReleasePs * (RAB)
100 *
3.1.2
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
+
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
pmTotNoRrcConnectReqSuccess
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 estmate 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.
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).
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)
pmNoSystemNasSignRel easePs
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
pmNoRabEstablishSuccess(RAB)
pmNoRabEstablishAttempt(RAB)
Low value (e.g. <95%) indicates problems to establish a RAB after the RAB assignment coming from the CORE
network.
3.2.5
100 *
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
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 -
GoS can be estimated for other RABs in a similar way: CS, PS Streaming DCH, PS Streaming HS.
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.
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.
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
DL and UL ASE
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
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
You must compare the RAB establishments blocked by admission control with the RAB attempts:
100 *
100 *
pmNoOfNonHoReqDeniedSpeech
pmNoRabEstablishAttemptSpeech
pmNoOfNonHoReqDeniedCs
(pmNoRabEstablishAttemptCs64 + pmNoRabEstablishAttemptCs57)
100 *
pmNoOfNonHoReqDeniedInteractive
pmNoRabEstablishAttemptPacketInteractive
100 *
100 *
100 *
pmNoOfNonHoReqDeniedPsStreaming
pmNoRabEstablishAttemptPacketStream
pmNoOfNonHoReqDeniedHs
pmNoRabEstablishAttemptPacketInteractiveHs
pmNoOfNonHoReqDeniedEul
pmNoRabEstablishAttemptPacketInteractiveEul
100 *
pmNoOfNonHoReqDeniedPsStr128
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.3.1
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)
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
Similar analysis can be done for RABs Blocked due to transport network congestion including:
Speech:
100 *
pmNoRabEstBlockTnSpeechBest
pmNoRabEstablishAttemptSpeech
Videocall:
100 *
PS R99:
100 *
pmNoRabEstablishAttemptCs64
pmNoRabEstBlockTnPsIntNonHsBest
(pmNoRabEstablishAttemptPacketInteractive - pmNoRabEstablishAttemptPacketInteractiveHs)
HSDPA:
100 *
4.3.2
pmNoRabEstBlockTnCs64Best
pmNoRabEstBlockTnPsIntHsBest
pmNoRabEstablishAttemptPacketInteractiveHs
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
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
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
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.
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
users claims or
drive test activities or
variations of the traffic level.
Typical causes are:
4.4.1
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
Cell Unavailability
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
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.
4.
5.
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.1
Cell Selection
6.3.2
Cell Reselection
6.3.3
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.
6.3.4
Paging Procedure
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
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.
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.
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 messagewhich contains SRB information including the
mapping details of dedicated logical, transport, and physical channelsis 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.
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
Layer 1. Spreading Factor (SF), OVSF code, Scrambling Code, frame offset, power control parameters
(TFCS)
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.