UA08 1 RNC Paging Engineering Guidelines V02

WELCOME
TIS ONE ENGINEERING GUIDELINES
1
COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT — INTERNAL PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION
PAGING ENGINEERING GUIDELINES UA08.1
UMT/IRC/INF/35601 V02/EN
Didier Bouvrande TIS ONE – Internal Document
February 2012

1 | Paging Principles
2 | Engineering Recommendations
3 | UA7.x and UA8.1 New Features
4 | Paging Monitoring
5 | Paging Optimization
6 | Simulation Templates for Paging Occupancy
7 | Guidelines for LAC Splitting
8 | Impact for 2 RNCs per LAC
3
1. Paging Principles
• 1.1 Paging Mechanisms

• 1.2 Paging Channel Configuration
• 1.3 Paging Cycles CN part and UTRAN part
• 1.4 Paging Parameters
• 1.5 S-CCPCH Configuration
• 1.6 Paging Repetition on UTRAN

1.1 Paging Mechanisms
If the UE is in idle mode, UTRAN doesn’t know where it camps and can just forward the
paging message coming from CN to all the cell belonging to the Location of Routing
Area.
The UE monitors periodically a channel to check if it is paged or not
If the UE is in connected mode, The CN knows the Serving RNC of the UE and sends the
paging message just to this RNC
The RNC knows the UE uses the dedicated or common channel to send the paging
message
5
1.1 Paging Mechanisms (Radio Channels)
The period of the cycle (DRX cycle) is between 4 and 4096 radio frames. That means
the UE can monitor the PICH every X seconds, with X between 40 ms and 40,96
seconds. If the period is too short the UE uses too much power.
It is a trade-off between the delay and the consumption.
To determine the radio frame number into the cycle and the Paging Indication, the UE
uses its IMSI and others parameters send on the SIB.
6
1.1 Paging Mechanisms (follow)
• When a passing message is received from RANAP, the paging occasion (PO, i.e. occurrence
at which a paging has to be sent for that user) is determined by the RNC using the mobile
IMSI and DRX cycle length, as described in the 3GPP specifications.
• The DRX cycle procedure only applies to mobile in the following states: Idle mode,
Connected mode URA_PCH, Connected mode CELL_PCH.
• When RNC receives a paging message from CN, together with an IMSI, it first decides
whether to send a paging type 1 or a paging type 2
- Paging type 1 is used to send information on the paging channel. One or several UEs, in idle or connected mode
(CELL_PCH or URA_PCH State) can be paged in one message.
- Paging type 2 is used to page an UE in connected mode
• In case of paging type 1, RNC prepares a paging record and computes its paging occasions
according to IMSI and 3GPP rules. The number of POs depends of the DRX cycle coefficient.
• From UTRAN point of view, the paging mechanism is exposed to two kind of bottlenecks:
- « Radio » limitation (PCCH channel limitation)
- RNC Processing limitation
• The purpose of this study is to analyze both PCH and RNC limitations and to make
recommendations in terms paging strategy and dimensioning.
• The overall paging strategy is comprised of:
- CN (Core Network) paging strategy
- UTRAN paging strategy
7
1.2 Paging Channel Configuration
The RRC paging procedure is used to transmit paging information to selected UEs in idle mode,
CELL_PCH or URA_PCH state using the paging control channel (PCCH). UTRAN initiates this
procedure by transmitting a PAGING-TYPE-1 on a appropriate paging occasion (PO) on
PCCH.
Theoretical throughput of PCCH is 240 bits (one transport block) every 10 ms = 24 kbits/s. 7
bits from 240 bits Transport block are used for header, so only 233 bits are available to
transport Paging Records.
The Paging Request from CN (named Paging Records in UTRAN) can be:
Paging Record Using IMSI – 72 bits size
Paging Record Using TMSI – 40 bits size
So in IMSI structure  233 / 72 = 3.2 which set 3 records per message max and
in TMSI structure  233 / 40 = 5.82 which set 5 records par message max
One UTRAN Paging Transport Block (Paging message) can accommodate up to 5 paging
records depending on their IMSI/TMSI structure.
Please see the channel transport composition on the next slide
8
1.2 Paging Channel Configuration
PCCH Channel Composition
RLC Logical Channel PCCH

type
RLC Mode TM
Payload sizeq, bit 240
Max data rate, bps 24000
AMD/UMD/TrD PDU 0
header, bit
MAC MAC header, bit 0
MAC Multiplexing N/A
Layer 1 TrCH type PCH
TB sizes, bit 240
TFS – TFO, bits 0x240
TFS – TF1, bits 1x240
TFS – TF2, bits N/A
TTI, ms 10
Coding Type CC 1/2
CRC, bit 16
Max number of bits/TTI
before rate matching 520
RM attribute 210-250
9
1.3 Paging Cycles CN part and UTRAN part
Overall Paging Repetitions on Core and UTRAN
BTS RNC MSC/SGSN

BTS RNC MSC/SGSN
Paging
Core Network repetition
Paging
T3313 (SGSN)/T3113 WCS
Paging At timer expiry, the

paging is repeated
Paging Repetition
timeline in UTRAN
Paging
Paging Response
BTS RNC MSC/SGSN

BTS RNC MSC/SGSN
UTRAN repetition
Paging
Paging
DRX cycle
Paging
lentgh
Paging Response
Paging
Paging
Core Paging Parameters Current Value

CS Core Paging Timeout T3113 8 Seconds
CS Core number of pages 2
PS Core Paging Timeout T3313 4 Seconds Example of Paging
PS Core number of pages 7 Parameters on Core
UTRAN Paging Parameters and UTRAN
DRX length CS csDrxCynLngCoef 6 (640 ms)
DRX length PS psDrxCynLngCoef 6 (640 ms)
UTRAN Paging Repetition nrOfPagingRepetition 1
10
1.3 Paging Cycles CN part and UTRAN part
UTRAN DRX Cycle Length
DRX Cycle UTRAN Number of DRX

Length (s) Coefficient cycles
0.08 3 2.56
0.16 4 2.56
0.32 5 5.12
0.64 6 5.12
1.28 7 6.4
2.56 8 7.68
5.12 9 10.24
DRX cycle length = 2^k frames for FDD mode, where k is DRX cycle length
coefficient.
The value of k is controlled in Alcatel-Lucent’s solution by two parameters, one per
Core Network Domain: csDrxCynLngCoef and psDrxCynLngCoef.
According the UTRAN DRX cycle length coefficient (values 3-9), the cycle length
range will be from 80 ms to 5.12 sec.
Note: The longer the DRX cycle, the longer the UE is in a sleep state, but the
longer the delay before the UE can respond to a paging message. The DRX cycle
length could impact the Paging success rate.
11
1.4 Paging Parameters
Refer to Slide chapter 1.3
CN Control
The number of times to page (CN pages)
The type of the first page and subsequent pages, (ie to use last seen information to trigger
the first page to the LAC last known or flood type paging is adopted)
Timeout between the pages (T3113 on CS Core and T3313 on PS Core)
The first page of the Core network is performed using TMSI and subsequent pages are
performed using IMSI.
UTRAN Control
The DRX cycle (interval during which the paging occasion has to be monitored by the
mobile), is configurable independently for the CS and PS networks.
Number of additional repetitions that UTRAN performs in response to a single page invoke
from the core. The paging repetition on UTRAN is performed even on receipt of successful
page response to the first page.
S-CCPCH configuration –> Mono S-CCPCH (PCH & FACH transport multiplexed on the same
S-CCPCH), Bi S-CCPCH (PCH & FACH transport on separate S-CCPCH). See Slide chapter 1.5
12
Interaction between UTRAN repetition and CORE repetition
• UTRAN repetition is controlled by DRX and Core repetition is controlled by T3113.

• If the core network (MSC/SGSN) sends a paging and receives no response from the UE with
a certain time then the core network repeats the paging. The time interval for the repetition
and the number of repetitions is dependent on the core network implementation.
• When the RNC receives a paging of type 1, i.e. for a UE being in idle or Cell_/URA_PCH state
then in each cell to that the paging should be sent the RNC allocates the next free Paging
Occasion (PO) based on TMSI/IMSI and DRX cycle length.
• If the paging rate is high or in case of temporary accumulation of paging requests for the
same POs it can happen that the next free PO occurs several seconds after receipt of the
paging request.
• If the time to the next free PO is longer than the time until paging repetition by the core
network then the paging is repeated unnecessarily. The duplicated paging again increases
the load on the paging channel (PCH) which will cause further duplications and further
increased load. Finally, it could happen that paging need to be discarded because no free PO
can be found.
13
Listing of parameters linked to Core/UTRAN paging
• UtranDrxCycLngCoef used to monitor the paging occasion when the UE is in CELL_PCH or
in URA_PCH (See Slide chapter 1.3)
• DRX cycle calculation is controlled by 2 parameters csBrxCynLngCoef and

psDrxCynLngCoef and is applied only with the UE is in Idle mode, or CELL_PCH /
URA_PCH Mode. (See slide chapter 1.3)
• When searching for the next free Paging Occasion (PO) for a paging type 1, the RNC shall
consider only POs within the time given by the new parameter tpageVal. If no free PO is
found within this time then the RNC shall discard the paging.
• The parameter nrOfPagingRepetition indicates the number of retransmissions of the

paging by UTRAN. (See Slide chapter 1.4 UTRAN Control)
• The parameter sysinfochangePagingRepetitions Controls the number of DRX cycles during

which the paging type 1 are repeated. There is no real relation ship with the
nrOfPagingRepetition value but we recommend to adapt the 2 values. This control will not
increase the number of paging records sent.
• The parameter isPagingRepetitionAllowed is the flag to activate or deactivate paging

repetition feature at RNC level.
14
1.5 S-CCPCH Configuration
• From UA5.0 Multiple SCCPCH channels configurations could be used for obtain a good
level of paging reliability and robustness. This feature avoid a PCH transport channel
congestion and allow capacity increase for paging and FACH channels.
• Mono SCCPCH is maintained for iso-functionality with releases before UA5.0 This
function carrying two FACH Channels and paging channel.
• The Bi - SCCPCH configuration allows having:
One SCCPCH (SCCPCH/0) SF 128 to carry paging channel (PCH)
One SCCPCH (SCCPCH/1) SF 64 to carry all FACH traffic.
• It is recommended to use the Bi-SCCPCH configuration, since this configuration

provides higher capacity for paging and FACH channel compared to Mono-SCCPCH
Configuration.
• Moreover, this configuration is highly recommended when paging repetition is activated
due to increased PCH capacity. Mandatory also for using URA_PCH feature.
• It has also been noticed a positive effect on RRC Establishment Success Rate indicator
when using Bi-SCCPCH configuration in live networks.
See figure on the next slide
15
1.5 S-CCPCH Configuration
Bi - SCCPCH Configuration
16
1.6 Paging Repetition on UTRAN
Principles
• On the UTRAN side (Access Network), paging repetition is performed for all type 1 pages
irrespective of the service being paged. The benefit of the Paging Repetition is to improve the
Paging Type 1 success rate. Paging repetition is performed at interval of DRX. Unnecessary
paging repetitions lead to high paging load.
• The parameter nrOfPagingRepetition indicates the number of retransmissions of the paging

by UTRAN. Hence the value 0 means that the paging will not be repeated (only the “fresh”
paging is sent). The Paging Repetition is always sent even if answer from the UE. That means
if nrOfPagingRepetition = 2, there will be always 3 sending (2 + the fresh one)
• If no repetition (value 0) on UTRAN side for real networks, the number of paging records by
the CN will increase slightly in order to compensate UTRAN repetition and improve paging
success rate. This could be acceptable on a customer point of view in case of too high PCH
channel load.
• If UTRAN paging repetition value is to high, that will increase the PCCH usage
17
Mechanism
 Paging Repetition mechanism allows to decrease call establishment failure rate

- Two different repetition mechanisms.
• Repetition by Core Network: Paging Record is resent if no response received
 Controlled by Core timer
 Maximum 2 repetitions, typically one. Bur for some CN (Nokia, Ericsson), can be extended up to 5
times
• Repetition by Access Network: Paging Record systematically repeated (even if
answered)
 To overcome sporadic RF problems
 Short timers (minimum one DRX cycle length => 0.64s)
 Controlled by nrOfPagingRepetition parameter value
 If value = 0 is maintained in the real network, the number of paging records repeated by the CN
will increase to compensate UTRAN repetition.
• Impact of repetition on Access Network
 Will seriously increase the PCCH usage
 Repetition being performed by RNC, a certain processing cost is to be considered.
18
Paging 3GPP Parameters
3GPP parameter : Number of paging repetition
Configured at RNC : Used by the RNC to automatically repeat the paging Record
Short timers (minimum one DRX cycle length => 0.64 s, higher in case of load)
Goal : To overcome sporadic RF problems
19
The benefit of the Paging Repetition is to improve the Paging Type 1 success rate.
It has been noticed that UTRAN paging repetition impacts basically the Success
Rate for the first Paging sent by Core Network thus having essentially an impact
on user latency rather than on overall success rate.
20
Value adjustment
• The number of UTRAN paging repetitions has to be adjusted to limit the load on PCH and PMC
RAB CPU load.
• With no repetition, the cost of paging is proportional to paging rate.
• The difference in CPU cost between with paging repetition and without repetition is almost
constant.
• If the accessibility is degraded due to reduction of UTRAN paging repetition, then the Core
Paging Repetition Timer
(T3313 for SGSN or T3113/GSM_PAGING_INTRVL_TIMER for MSC) can be reduced to improve
accessibility with the condition that:
Core Paging Repetition Timer > T352 + nrOfPagingRepetition x UtranDrxCycLngCoef.
• The POs occur every DRX Cycle Length (parameter utranDrxCycLngCoef) in terms of frames
of 10ms duration. (Remind slides part 1.3)
• T352: guard timer between RRC connection setup and RRC connection setup complete
received from the UE
 Index Return
21
2. Engineering Recommendations
• 2.1 RNC Dimensioning vs Expected Paging Rate

• 2.2 URA Size vs Paging Repetition
• 2.3 PCH Load Result Interpretation
• 2.4 PCH Load occupancy vs paging repetition
22
2.1 RNC Dimensioning vs expected Paging Rate
• The arrival paging rate depends entirely on call profile ( CS&PS sessions MT,
Signaling Proc. generating paging as SMS MT, .. )
• For a given call profile and taking into account that RNC area is equal to one LA
(*), the maximum arrival paging rate is proportional to the total number of
subscribers located under the coverage of the RNC :
max paging / sec = RefSubs × nb of paging generated for each subs per sec
• This is an acceptable and simplified formula to estimate roughly the expected
paging flow to handle by RNC, for a given profile. In post sales, with customer’s
traffic, the paging rate is derivable from RNC counters.
• ( * ) From only RNC point of view, the LA/RNC and Cell/LA dimensioning optimization is
mainly driven by the trade off between CPU cost for Location Update traffic and CPU cost for
Paging procedure. In that sense, the new HW added in RNC ( DCPS, CP4 , .. etc .. ) doesn’t
provide more capacity to handle more Location Update than Paging and vice
versa. Consequently, the RNC HW has no effect on general recommendation rule 1 RNC = 1
LA.
23
2.2 URA Size vs Paging Repetition 1/2
The main advantage of URA_PCH versus CELL_PCH is to limit the amount of mobility
procedures. But URA_PCH generates paging procedures which are limiting from 2
points of view:
- Radio limitation (PCCH channel limitation)
- RNC processing limitation
• And if more capacity on PCCH channel is needed, it is more efficient to use
bi S-CCPCH configuration. (See slide chapter 1.5 )
• It is more convenient to use now eURA_PCH feature (UA07.1.2) which could be
associated to direct PCH  DCH transition (UA08.1) with respect to some
prerequisites. (refer to slide chapter 3.4)
• In URA_PCH state, the UE will not perform a Cell Update each time moving to a new
cell but only an URA Update each time it is changing of URA.
• Then, it will decrease the number of signaling procedures due to mobility but, in
URA_PCH state, as the UE will only be localized at URA level and no more at Cell level,
the UTRAN will have to page it over the whole in case of traffic resuming or also in
case of new service establishment from the Core Network. (see fig on slide chapter
2.2)
24
2.2 URA Size VS Paging Repetition 2/2
Mobility in CELL_PCH and URA_PCH states
25
2.2 Recommendations on URA size and paging occupancy
• If using X_PCH and Paging Repetition, then multi S-CCPCH is mandatory.

• The URA size dimensioning depends mainly on the constraints mentioned on the
previous slides, once the CELL/URA_PCH is used the paging traffic will increase,
which means a higher capacity needed for paging channel.
• It is necessary to avoid too large URAs and to design efficiently the cells number
by RNC.
• As write on chapter 3.4, the association of eURA_PCH and direct PCH  DCH
transition ensures a direct transition for CS calls and for PS calls with high traffic
volume and decrease the paging load.
26
2.3 PCH Load Result interpretation
 We can see an important dependency between the paging record arrival rate and the
PCH load. This impact also FACH capacity.
 If we use configuration with mono S-CCPCH, the PCH load has to be limited to 75%
because of impact on FACH. That mean the number of paging records par sec will be
limited depending on nrOfPagingRepetition value.
If we use configuration with multiple S-CCPCH (2 is recommended), PCH load can go
up to 100% with no restrictions. That mean we can reach more number of records per
sec with nrOfPagingRepetition set to 1.
In both cases, the recommended pages records per sec as defined on the threshold
values (See Chapter 4.4) can be reached for 1 RNC / LA and URA = LA (URA/LA size
ratio = 100%)
Configuration with S-CCPCH = 2 and nrOfPagingRepetition = 0 could be used in case of
too important paging records per cell/per sec as important paging load. This action could
lead an impact on the paging success rate.
27
2.4 Summary of PCH Load occupancy vs Paging repetition on CN and
UTRAN
If 1 RNC = 1 LA, following metric can be used to evaluate the paging success rate and decide
if UTRAN Paging Repetition is to be activated. ( ref Slide chapter 1.6 )
Paging success rate (LAC) = ΣRRC.AttConnEstabLastperProc (scr 5, 6, 7, 8,17, 18 & 19)
UPaging003_R
• Repetition on Core Networks
Paging Repetition factor on CN level is 10% if UTRAN paging repetition is used and around
40% if UTRAN paging repetition is deactivated.
• Repetition on Access Networks
The UTRAN repetition will seriously increase the PCCH usage. This is why the value of 1 is
recommended.
And a certain processing cost is to be considered.
• A normal paging success rate should be above 90%. In case of trouble, monitor the CN
paging success rate ( verify PO and the paging repetition flags – Slides of part 1.2, 1.3, 1.4)
and activate the UTRAN paging repetition.
• PCH load occupancy could be retrieved with the metric UPaging017_CR which provide the
PCCH throughput in bits/sec.
Index Return
28
3. UA7.1.x and UA8.1 New Features
• 3.1 Improvement of PCH Scheduling (79036)

• 3.2 Enhanced URA_PCH Paging (108388)
• 3.3 Paging Repetition per Domain (125177)
• 3.4 Direct transition from PCH to DCH (108389)
• 3.5 Fast Dormancy handling by UTRAN (97425)

3.1 Improvement of PCH Scheduling (feature 79036) 1/2
• The purpose of this feature deliver in UA07.1.2 release is to avoid the duplication of
paging records in situations of high paging load. Then the total number of paging is
reduced and allows for faster paging and increased the number of successful paging.
• The current implementation will allow the RNC to configure the time duration for which
the RNC will try to find a PO. If the RNC is not able for a paging type 1 request to find a
free PO within the configurable time then the RNC discards the paging request.
• On the new feature, the RNC calculates the maximum number of POs to be checked for a
free PO as:
- maxTransmissions = 4096/drxCycleLength – 1
• The PO occur every DRX cycle length (parameter utranDrxCycLngCoef) in terms of frames
of 10 ms duration. For the calculation of the time drxCycleLength can be reduced resulting
in:
- Maxtime = 4096 frames = 40.96 s
• The hardcoded value of 4096 is define. When searching for the next free PO the RNC
aborts the loop after maxSpanWindow (internal value). The RNC calculates
maxSpanWindow from the new parameter tpageVal
- maxSpanWindow [frames] = tpageVal [ms] / 10
30
3.1 Improvement of PCH Scheduling (feature 79036) 2/2
31
3.2 Feature Enhanced URA_PCH Paging (eURA_PCH) FRS 108388
This feature provided from UA07.1.2 resolves the lack of synchronization that
may occurs between the UE and RNC during CS paging, allowing the URA_PCH
feature to be enabled in the field.
To fix this synchronization problem between UE and RNC, the enhanced
URA_PCH feature introduces a pseudo-state, eURA_PCH.
This feature specifies the enhanced URA_PCH paging requirements to secure the
Alcatel-Lucent UA07 introduction of URA_PCH feature (and its intrinsic capacity
improvements on RNC9370 and power savings on the Node Bs). Due to
standards holes, when it is unclear if the UE is in URA_PCH state or idle, the RNC
shall page both ways for CS paging (RNTI + IMSI).
- For this feature, Paging Repetition of 1 is the expected setting.
- Paging Repetition of 0 is a possibility to consider for regions where there are
two RNCs in one Location Area (e.g. New York or Paris), in order to reduce the
quantity of paging.
32
3.2 eURA-PCH Feature integration and transition overview
• A simplified transition summary, highlighting the integration of the new RRC

pseudo-state in the Always-on mechanism is presented below.
• Once in the eURA_PCH pseudo-state, the RNC will keep the UE in that
pseudo-state until:
- A. The UE sends a periodic URA update, the eURA_PCH pseudo-state will be
terminated and the UE will be in the URA_PCH state alone.
- B. The UE responds to a paging request, the UE will transition to the FACH state,
as it does when simply in the URA_PCH state.
- C. The UE does not respond to pages for a time nor sends a periodic URA update
indicating good communications between the RNC and the UE, that UE will be
transitioned to the idle state when the T3 timer (PchToIdleTimer) expires, or if
the RNC has not detected activity from the UE for a period up to twice the
supervTimerPchAndCellFach timer.
Refer to the diagram below for the state described here.
33
When does user equipment (UE) go to URA PCH? Answer: upon inactivity expiry.
When does UE go to eURAPCH? Answer: upon paging failure from URAPCH.
URA PCH and eURAPCH: UTRAN •URA Update

is in PMM_connected state. To CS •Confirm NoPageResp for CS/PS
core, UE is in CMM_idle state. NoPageResp for CS/PS
Cell_FACH and Cell_DCH for packet •URA-PCH •eURA-PCH
transfer is fast. Periodic URA update
confirm
Cell
•RB/Phy •Cell Update Update
Reconfig Confirm
•RB Confirm
Reconfig e.g.
response
to paging
•RB Reconfig
•(•DBC•) •RB Reconfig
•TRAFFIC LOW/T1
•Cell-DCH •Cell-FACH
•Cell
UpdateConfirm
•RB Reconfig
Idle: In order to re-establish data •RRCRelease
Connection
•Inactivity T3 / audit
services from idle mode, the UE, Inactivity T3 / audit •RRC
timer for no periodic
URA update expires
RNC and SGSN all have to go timer for no •Connection
through RRC establishment, RRC
periodic URA
update exp
•Release
Security procedures, NAS Signaling Connection
and RAB establishment. establish
•Idle
* The transition from URA-PCH &
eURA-PCH states to Cell-DCH are
via the Cell-FACH as a transient.
34
3.2 Feature Value and Benefits
• The enhanced URA_PCH feature improve the high paging degradation observed by
customer and the complain about calls which were going to voicemail without the
phone even ringing with the existing URA_PCH.
• The main improvement concern the paging load drop off because of no transition
from eURA_PCH to idle after CS or PS paging failed. This can be used even with
UTRAN paging repetition = 0.
• The 2 principals issues observed on field were the following
- Either the UE changes its state to idle without telling the RNC
- Either the RNC moves UE to idle without confirmation from the UE
35
3.3 Paging Repetition per Domain (FRS 125177)
• This feature is for enhance the paging repetition and be able to differentiate the
nrofpagingrepetitions for CS and PS. It will be deliver on UA07.1.3.8 release
• This allow the operator to configure the number of paging record repetition for each domain
differently, based on CN domain Indicator Information Element and/or Paging cause
Information Element of RANAP PAGING message.
• According to the first estimation provided by TIS team, on Orange network, the PCCH
channel occupancy could be reduce by 65% if only CS Speech and the SMS paging requests
are repeated.
• This feature differentiates the paging repetition at RNC based on paging cause. A new
parameter (called PagingRepetitionDomain) is introduced to perform paging repetition
differently for paging causes as follows
• 0: all paging record are repeated – iso-functionality as PM24075; all CS and PS paging
messages are repeated based on nrOfPagingRepetitions parameter
• 1: CS Speech and SMS are repeated – number of paging repetitions will be
nrOfPagingRepetitions for following paging causes: Terminating Conversational Call,
Terminating Low Priority Signalling; number of paging repetition is zero for following paging
causes: Terminating Streaming Call, Terminating Interactive Call, Terminating Background
Call, Terminating High Priority Signalling.
• 2: CS Speech only is repeated – number of paging repetition will be nrOfPagingRepetitions
only for paging cause Terminating Conversational Call; the paging repetition is zero for the
other paging causes.
36
3.3 Paging Repetition per Domain (FRS 125177)
• There is interaction with feature “FRS 108388 UA07 enhanced URA_PCH

(eURA_PCH) Paging” which controls the CS paging when UE is in URA state. This
new feature (FSD 125177) has the overall control regarding the paging repetitions
regardless whether feature FRS 108388 is enabled or not. There is a restriction
when FRS 108388 is enabled and only options PagingRepetitionDomain = 0 and 1
are allowed (i.e. value 2 is forbidden). This is required to allow correct
functionality of FRS 108388.
37
3.4 Direct Transition from PCH to DCH (FRS 108389)
• The URA_PCH feature introduced in UA05 has reduced the PS RRC connections.
But some UEs in URA_PCH don’t answer to UTRAN paging, thus leading to PS
drops and call setup failure at CN level.
• Feature PM108388 – Enhanced URA_PCH Paging (UA7.1.2) has provide a
workaround for these UEs
• 108389 - Direct transition from PCH to DCH (UA08.1) ensures a direct transition
for CS calls and for PS calls with high traffic volume expectation while keep alive
can be handled in CELL_FACH. Before this feature, direct RRC State transition
from URA_PCH or CELL_PCH to CELL_DCH is supported only for multi RAB cases
i.e. UE in PCH State with PS I/B + PS I/B + (PS I/B).
• The decision to go directly to CELL_DCH or through CELL_FACH is based on the
Establishment Cause and/or the Traffic Volume Indicator (TVI) included in the Cell
Update message.
38
3.4 Direct Transition from PCH to DCH
URA_PCH to HSPA no direct trasition URA_PCH to HSPA with direct trasition

Delay (ms) Delay (ms)
Cell Update 94 Cell Update 94

Cell Update Confirm/RB Reconf to FACH 167 Cell Update Confirm/RB Reconf to FACH
RB Reconfiguration Complete 94 RB Reconfiguration Complete
RACH Measurement Report 94 RACH Measurement Report
NBAP RL Setup Request 74 NBAP RL Setup Request 74
NBAP RL Setup Response 4 NBAP RL Setup Response 4
Iub ALCAP and DCH setup BTS/RNC 51 Iub ALCAP and DCH setup BTS/RNC 51
RB Reconfiguration/CELL DCH 322 Cell Update Confirm/CELL DCH 322
RB Reconfiguration Complete 55 RB Reconfiguration Complete 55
Total Delay 955 ms Total Delay 599 ms

Direct Transition Gain 356 ms
 Direct transition vs. two step transition reduces the signaling message by 30%
(RNC processing load)
 Direct transition reduces the transition time by 350ms, i.e. becomes comparable
with a transition from Cell_Fach (~550 ms)
39
3.4 Direct Transition from PCH to DCH
The TVI if present when the cause for the Cell Update is “Uplink Data
Transmission” and is set to TRUE if, among other conditions, the Transport
Channel Traffic Volume (TCTV) is larger than the threshold defined for
Traffic Volume Measurement (TVM) in "all states except CELL_DCH".
• When set to TRUE → volume of signaling/traffic data to be sent is
higher than the TCTV threshold (configurable parameter); in this case,
the UE is ordered to CELL_DCH State directly.
• When set to FALSE → volume of signaling/traffic data to be sent is
below the TCTV threshold. The Establishment Cause is then checked to
decide the target RRC State.
Down Inactivity
CELL_PCH or
CELL_DCH CELL_FACH URA_PCH
PS call
Up
TVI = FALSE & Est. Cause
<> MO/MT Conv/Str./I/B
Est. Cause
& TVI
TVI = TRUE
or
TVI = FALSE & Est. Cause
= MO/MT Conv/Str./I/B
40
3.5 Fast Dormancy handling by UTRAN (FRS 97425)
• Fast dormancy behavior can be enhanced with Rel 8 UE.

• Before this feature, UTRAN ignores whether an inactive UE has completed its
transfer. Therefore the UE is kept in CELL_DCH until an inactivity timer T1
expires. The UE is not sent to CELL_FACH or URA_PCH  Users in idle mode
experience longer call setup time and generate higher signaling load when
traffic resumes than users in CELL_FACH or URA_PCH.
• Introduce a new cause" in Signaling Connection Release Indication (SCRI)
to indicate to the network that the UE has concluded active PS data transfer.
UTRAN triggers upon reception of this IE an RRC State transition to a more
battery efficient state: URA_PCH (or CELL_PCH).
• 3GPP based Fast Dormancy triggers transition to URA_PCH inst. of idle mode
which provides a latency gain when traffic resumes: 550ms. Moreover
signaling load is reduced on the RNC (control plane) when combined with
direct PCH to DCH transition
• Fast Dormancy is attractive for UE battery saving as well as for baseband
and uplink radio resources.
41
3.5 Fast Dormancy handling by UTRAN
Fast Transition enabled from Direct transition

CELL_DCH to URA_PCH just from PCH to DCH in
after the end of download UA08
CELL_DCH
URA_PCH /
CELL_PCH
•T1
•HSDPA
activity
Avoid UL DPCCH tx until T1 timer

expiration
Current UE, especially Smartphone, in CELL_DCH triggers a release indication

before T1 time elapses and are thus moved in Idle instead of PCH state Fast
Dormancy)
97425 - Fast Dormancy support in UTRAN allows direct transition to PCH.
 Index Return
42
4. Paging Monitoring
• 4.1 Counters of Paging in NPO

• 4.2 Counters Definition
• 4.3 Radio Side Paging Position
• 4.4 KPI and thresholds

4.1 Counters of paging in NPO
On NPO, take the view with Indicator and Basic -- Paging
44
4.2 Counters Definition
• 801 (VS.ReceivedPagingRequest) per RNC and per domain (CS/PS)

• Number of received paging requests (type 1 and type 2)
• 802 (VS.ReceivedPagingRequestType2CellDch) per Fddcell and per domain (CS/PS)
• Number of received paging requests received for UEs in Cell_DCH state
• 803 (VS.ReceivedPagingRequestType2CellFach) per Fddcell and Type of Core
• Number of received paging requests received for UEs in Cell_FACH state
• 805 (VS.PagingMessagesSentOnPcch) per Fddcell
• Number of paging messages sent on the PCCH of the cell. Counter used for calculate the
Paging Rate
• 807 (VS.PagingCancelledRecords) per Fddcell
• Number of paging type 1 records that are cancelled after having been scheduled but before
being sent.
• Reason could be:
• Pre-emption by paging records of higher priority (“fresh” paging records)
• A timing adjustment with the Node B introduced a gap in the sequence of CFNs
45
• 808 (VS.PagingRejectedRequests) per Fddcell
• Number of CN paging requests type 1 that are rejected.
• C-Node counter incremented if anything in a paging request is invalid (the IMSI, domain id,
DRX cycle length coefficient, Record length are invalid).
• 809 (VS.PagingDelayedRecords) per Fddcell
• Number of paging records type 1 that are delayed before being sent.
• 810 / 811 (VS.UnhandledPagingRequestsCs/Ps) per RNC and per Paging failure cause
• Number of CS/PS paging request not sent to the I-Node to be broadcast
• This measurement provides the number of CS paging type 1 requests that have been not
handled by RNC
• Decision to discard a paging request:
• invalid format (eg. ASN.1 decoding error of RANAP message or ASN.1 encoding error of
paging record)
• invalid information (eg. unsupported LAC, RAC, PLMN), reset in progress (in case of RANAP
reset)
• internal resources not available (no memory to allocate messaging buffers)
• RNC overload controls, other causes (not used)
46
• 812 / 813 (VS.PagingRecordsSentOnPcchCs/Ps) per Fddcell and per paging cause

• Number of paging records sent on the PCCH of the cell (for CS and PS domain)
• Calculation formula will be Σ (812 + 813) / (3600 * Numbers of Cells) for 1H granularity
• 814 / 815 (VS.PagingRecordsUnscheduledCs/Ps) per Fddcell and per paging cause
• Number of paging type 1 records that have invalid format or cannot be scheduled because
the paging occasion is full (for CS and PS domain).
• 816 / 817 (VS.PagingRecordsType2SentCs/Ps) per Fddcell and per paging cause
• Number of paging records Type2 sent for UEs in Cell_DCH state (for CS and PS domain)
• 818 / 819 (VS.PagingRequestsIuPagCauseCs/Ps) per RNC and per paging cause
• Number of received paging requests type 1 and type 2 (for CS and PS domain). It is the
equivalent of 801 but screened per paging cause.
• 820 (VS.UtranPagingRecSentOnPcch) per Fddcell and per URA or Cell
• Number of UTRAN initiated paging type 1 sent on the PCCH of the cell (when UE on
URA_PCH orv Cell_PCH)
47
4.3 Radio Side Paging Position
• To do study at the radio side, the following information are needed from the node Bs:
- Iu paging rate from the core network: Fresh paging count
• 801 VS.ReceivedPagingRequest (type 1+ type 2) (Cell)
• 802 VS.ReceivedPagingRequestType2CellDch (Cell) Paging type1 = 801-(802+803)
• 803 VS.ReceivedPagingRequestType2CellFach (Cell)
- All paging messages sent on the PCCH

• 805 VS.PagingMessagesSentOnPcch
- All paging messages (fresh and repetition) sent on the PCCH per paging cause
• 812 VS.PagingRecordsSentOnPcchCs (Cell) Paging Record Rate =
• 813 VS.PagingRecordsSentOnPcchPs (Cell) Σ (812 + 813) / (3600 * Numbers of Cells) for 1H
48
4.3 Radio Side Paging Position
- Number of fresh paging records type 1 that have been delayed before
being sent
• 809 VS.PagingDelayedRecords (Cell)
- All paging records type 1 (fresh and repetition) due to scheduler not
sent on the PCCH
• 807 VS.PagingCancelledRecords (Cell)
• 814 VS.PagingRecordsUnscheduledCs (Cell)
• 815 VS.PagingRecordsUnscheduledPs (Cell)
- Repeated Paging Failure
• Paging008 (RepeatedPagingFailure_Paging008_CR(UPaging008_CR)(%) =
Σ (Cancelled + Unscheduled) – Delayed Records / Σ Paging Records
This counter value recommendation is around 1%
49
4.4 KPI and thresholds
1. Paging005R (NumberofPagingRecordonPCCH_Paging005_CR): This

counter show the total number of paging records on PCCH for a given
granularity. The threshold should be < 150 paging records per cell / per sec
2. Paging003 (PagingType1sentbyCoreNetwork): This counter show the
paging message type1 sent by CN on the Iu. The threshold should be < 70
paging messages per sec. This counter help to estimate the PMC RAB CPU load
consume by paging.
3. Paging delayed records (VS_PagingDelayedRecords(U809)): The threshold
per sec should be < 0,02 paging record / sec
4. Paging Cancelled records (VS_PagingCancelledRecords(U807): The
threshold per sec should be < 1 paging record / sec
An operational guideline is now available  Operational Paging Engineering
Guidelines for giving the up to date recommendations to avoid paging
channel overload.
• Index Return
50
5. Paging Optimization
• 5.1 Methodology
• 5.2 Paging Success Rate Counters
• 5.3 Paging Success Rate per LAC

5.1 Methodology
• The paging optimization is based on the KPI paging success rate.

• This KPI shows the ratio of UE terminating call procedures that have been
attempted compare to the
• number of paging sent by the core network in one LAC.
Paging success Rate = ΣRRC.AttConnEstab(Mobiled terminating) U409
Σ CoreNetwork paging
NPO counter as defined on chapter 7.1 pagingType1SuccessRate_Paging006_R
Paging success rate, defined as number of RRC connection attempts for
terminating reasons, divided by total number of paging received by the RNC.
• The goal of the optimization is to have:
- average paging success rate > 90 %
52
5.2 Paging Success Rate Counters
• The monitoring of the paging is based on the KPI:
• UPaging003_R PagingType1sentbyCoreNetwork_Paging003_R
• Extended performance monitoring indicators library, Number of Paging type 1 requests ( in
idle mode)
• 433 VS.RRC.AttConnEstab.LastperProc RRC.AttConnEstabLastperProc
• RRC connection establishment attempts split up per individual establishment cause.
Repeated attempts from the same UE on the same or a different cell - due to cell reselection
- are excluded.
• RRC CONNECTION REQUEST counters excluding UE repetitions feature (34668)
• 5 terminating conversational call
• 6 terminating streaming call
• 7 terminating interactive call
• 8 terminating background call
• 17 terminating high priority signalling
• 18 terminating low priority signalling
• 19 terminating cause unknown
53
5.3 Paging Success Rate per LAC
• The monitoring of the paging is based on the KPI: Paging success rate per LAC
• The following definition assumes that 1 RNC = 1 LAC = 1 RAC
Paging success rate (LAC) = ΣRRC.AttConnEstabLastperProc (scr 5, 6, 7, 8,17, 18 & 19

UPaging003_R
– 5 terminating conversational call

– 6 terminating streaming call
– 7 terminating interactive call
– 8 terminating background call
– 17 terminating high priority signalling
– 18 terminating low priority signalling
– 19 terminating cause unknown
54
5.3 Paging Success Rate per LAC
• The monitoring of the paging is based on the KPI: Paging success rate per LAC
• The following definition assumes that 2 RNCs = 1 LAC = 1 RAC
Paging success rate (LAC) = ΣRRC.AttConnEstabLastperProc (scr 5, 6, 7, 8,17, 18 & 19) of RNC1+RNC2
UPaging003_R of RNC1 or RNC2
– 5 terminating conversational call

– 6 terminating streaming call
– 7 terminating interactive call
– 8 terminating background call
– 17 terminating high priority signalling
– 18 terminating low priority signalling
– 19 terminating cause unknown
 Index Return
55
6. Simulation Templates for Paging Occupancy
• 6.1 RNC Paging Multicasting

• 6.2 Simulation one with Cell_PCH & URA_PCH validated
• 6.3 Results for PMC-RAB CPU Load
• 6.4 Simulation two with less aggressive call profile
• 6.5 RCT Result vs Network Load and Release

6.1 RNC Paging Multicasting
• In order to transform 1 Core Network request to 1 message per cell on the given
LA/RA, RNC needs to multicast the paging. Paging multiplication involves:
– PMC-TMU : the TMU which receives the CN Paging request sends it to one PMC-RAB. TMU
CPU cost is minimal and only depends on Paging Record arrival rate
– PMC-RAB : The chosen RAB multicast the Request to each RAB managing a concerned
PCCH entity (PGS=Paging Scheduler). In average, each PMCRAB will manage
(Cells/LA)/RAB cells
• Repetition is different from multicasting and is managed locally by each RAB
In average a UTRAN repeated paging costs 60% of a fresh paging
• Conclusion
PMC-RAB is the card mostly impacted by paging, its CPU cost is approximately:
CN Pag_rate*(Cells/LA)*PagCPUcost*(1+0.6*Repetition)/Nb_PMC-RAB
- As RAB CPU is global for traffic, signaling, paging, internal messaging, this formula is
useful for evaluate the paging RAB CPU cost versus the global CPU value.
- In case of RNC overload, paging requests are among the first messages to be discarded
57
6.1 RNC Paging Multicasting
58
6.2 Simulation one with Cell-PCH & URA_PCH validated
• Aim is to verify the PMC_RAB occupancy using

RCT without CN paging request and up to 3 CN
paging request. High loaded network for this
simulation.
10 x PS2, MS3+GE, CP4 V7,2 Processor Occupancy Distribution
 Parameters for this template: at Committed Capacity

Simulation Profile with URA PCH activated Processor Occupancies
Engineering Limit
Market Model with 10 PS2, CP4 UA07.1.2 release and

SMP5 TGEN call profile 80%
70%
CPU PMC-RAB Load 60,7 % 60%
Processor Occupancy
50%
Template parameters Value
SMS 2 40%
AO FACH to URA 0,5

30%
AO PCH TO URA 0,4
AO URA TO FACH 0,5 20%
Cells per LAC 1000

NodeB per RNC 500 10%
Cells per RNC 1000

0%
Cells per URA 200 PMC-TMU PMC-NI PDC-NI PMC-M PMC-RB PMC-PC Maker PS-PQC ATM-PQC
Processor Occupancies 54,7% 18,8% 16,5% 14,7% 60,7% 54,3% 0,0% 6,7% 0,0%
Freq per Cell 2 Engineering Limit 80% 70% 70% 70% 80% 80% 80% 80% 80%
Node
CN Paging Request 0
59
6.2 Simulation One following with CN Paging Request = 1
This is the most used because of good success paging rate and appropriate load of PCH channel vs loaded
network.
at Committed Capacity
Simulation Profile with URA PCH activated Processor Occupancies
Engineering Limit
CPU PMC-RAB Load 65,9% 80%
70%

60%
Processor Occupancy
SMS 2
50%
AO FACH to URA 0,5
AO PCH TO URA 0,4 40%
Cells per LAC 1000

20%
NodeB per RNC 500
Cells per RNC 1000 10%
Cells per URA 200 0%

PMC-TMU PMC-NI PDC-NI PMC-M PMC-RB PMC-PC Maker PS-PQC ATM-PQC
Freq per Cell 2 Processor Occupancies 55,1% 18,9% 16,8% 14,7% 65,9% 56,8% 0,0% 6,7% 0,0%
Engineering Limit 80% 70% 70% 70% 80% 80% 80% 80% 80%
Node
CN Paging Request 1
60

Simulation with URA_PCH activated Processor Occupancies
Engineering Limit
70%

60%
SMS 2
Processor Occupancy
AO FACH to URA 0,5 50%
AO PCH TO URA 0,4

40%
AO URA TO FACH 0,5

30%
Cells per LAC 1000
Cells per RNC 1000

10%
Cells per URA 200
Freq per Cell 2 0%

CN Paging Request 2 Engineering Limit 80% 70% 70% 70% 80% 80% 80% 80% 80%
Node
61
Not very used now because of high PCH channel load. We can estimate the PMC_RAB CPU load dedicated to
paging go from 10% to 25% (all paging merged and until CN Paging Request = 3)

Simulation with URA_PCH Activated Processor Occupancies
Engineering Limit
70%

60%
SMS 2
Processor Occupancy
50%
AO FACH to URA 0,5
AO PCH TO URA 0,4 40%
Cells per LAC 1000

20%
NodeB per RNC 500

10%
Cells per RNC 1000
Cells per URA 200 0%

Freq per Cell 2 Engineering Limit 80% 70% 70% 70% 80% 80% 80% 80% 80%
Node
CN Paging Request 3
62
6.3 Results concerning PMC-RAB CPU Load
CN Paging PMC-RAB PMC-TMU

Request
URA-PCH URA-PCH off
activated
0 60,7 61,8 54,7
1 65,9 67 55,1
2 71,2 72,3 55,4
3 76,5 77,6 55,7
The evaluation concern a network with important load. Cells per LAC=1000, NodeB per
RNC=500, Cells per RNC=1000.
Paging impact point through a high increase of PMC-RAB CPU load vs CN Paging Request
value. PMC-TMU CPU load is not impacted by paging. URA-PCH activation with multi
channel S-CCPCH allows a moderation of the increase.
This evaluation is made with RCT 29.56, which actually don’t take UTRAN Paging
repetition in account.
CN Paging Request = # of paging requests coming from Core Network (including CN

repetitions) per attached sub per busy hour.
63
6.4 Simulation two with less aggressive call profile
10 DCPS, CP4 -- UA07.1.2 release version 10 x PS2, MS3+GE, CP4 V7,2 Processor Occupancy Distribution
and SMP5 TGEN Call profile. Must be

SMP5 TGEN v11test Profile Processor Occupancies
compared with Slide chapter 6.2 where Engineering Limit
PMC-RAB = 76,5%
80%
70%
CPU PMC-RAB Load 68% 60%
Processor Occupancy
Template parameters Value 50%
SMS 2
40%
ASU 0,1
30%
Cells per LAC 500
Cells per RNC 500 10%
Cells per URA 500

0%
Freq per Cell 1 Processor Occupancies 52,7% 19,3% 16,6% 13,3% 68,0% 57,9% 0,0% 6,7% 0,0%
Engineering Limit 80% 70% 70% 70% 80% 80% 80% 80% 80%
Node
CN Paging Request 3
64
6.5 Analyse RCT result vs Network Load and Release
If using same call profile as before with comparison between 2 recent
software release, we can remark the important paging capacity in release
UA07.1.2 (Better Cells dimensioning with CP4). RNC Capacity Roadmap
document point for 20% capacity increase.
Capacity vs release PMC-RAB with CN PMC-RAB with CN PMC-RAB with CN

PAGING Request = 0 PAGING Request = 1 PAGING Request = 3
UA07.1 64,2% 68,3% 76,5%
UA07.1.2 58,2% 61,5% 68%
Index Return
65
7. Guidelines for LAC splitting
• 7.1 Guideline for Split Action
• 7.2 LA Dimensioning Assessment

7.1 Guideline for LAC Split action 1/3
- Too large LAs may lead to a too high paging load in the NodeB resulting in
congestion and lost pages
- Smaller LAs reduce the paging load in the NodeB as well on the RNC. However,
smalls LA also means a larger number of LA border cells. Each time a mobile
crosses the boarder between two Las, a location updating is performed. The LA
update has an effect on the signaling sub-channels load, S-CCPCH in the LA
border cells
67
7.1 Guideline for LAC Split action 2/3
• If you want to launch split LAC on the existing RNCs, it is mandatory to take care
for all the borders cells between two LACs. There will be more LA update for these
cells and a slight increase of call setup time.
• Nevertheless, the global paging occupancy is reduced and no increase on TMU
load is expected if border choice is optimal.
• When the ratio 1 RNC = 1 LAC is applied, there is equivalent number of cells/RNC
and cells/LAC.
• When 1 RNC is splitted with 2 LACs, number of Cells/LAC is divided by 2
(theoretical value depend of the cells number).
• But the numbers of users supported could increase.
• Remind the PMC RAB CPU cost of paging is driven with:
CN Paging Rate * (Cells/LAC) * Paging CPU cost *(1+0,6 * repetition)

Number of PMC-RAB
68
7.1 Guideline for split action 3/3
 Concerning the previous formula 

- CN Paging Record Rate can be measure with the KPI:
• PagingType1sentbyCoreNetwork_Paging003_R(UPaging003_R)(Event).
Value should be show the number of paging messages by sec
• Paging CPU cost is the processing time cost for paging.
This processor estimation is 36 µs.
• Repetition is the value of nbofPagingRepetition parameter
• For the Paging Rate per LAC, respect the laws below:
Combined CN paging/sec = (max CN paging RNC1 + max CN paging RNC2) per
sec
Combined paging record rate/sec = (Paging Record rate RNC1 + Paging Record
rate RNC2) per sec
69
7.2 LA Dimensioning Assessment 1/2
• Some comments about PCH load

• We can see an important dependency between the paging record arrival rate and
the PCH load. This is impacting especially FACH capacity if mono S-CCPCH is used.
- Mono S-CCPCH configuration  PCH load has to be limited to 75% for avoid
potential impact on FACH traffic capacity.
- Multiple S-CCPCH configuration. In this case the PCH load can go up to 100%, no
restrictions are foreseen from PCH point of view.
- NB : Refer to the slides chapter 2.3 for the PCH load result
interpretation
• The most useful value for nrOfPagingRepetition is 1

• In case of less loaded RNCs (below 300 cells) the rules can be modified either by
doubling the number of RNCs / LAC or by doubling the recommended URA/LA size
ratio
70
7.2 LA Dimensioning Assessment 2/2
Check about PCCH load

Each LAC should respect the same rules
number of paging records sent on PCCH of the cell (for PS and CS domain).
Paging Record Rate
812 / 813 VS.PagingRecordsSentOnPcchCs/Ps
Σ VS.PagingRecordsSentOnPcchCs/Ps at RNCx
3600* Cell numbers in the RNCx
It is more convenient to use the NumberofPagingRecordonPCCH_Paging005_CR
counter and to calculate also at cell level per sec
As write for the threshold, this rate should not exceed 150 paging records for
avoid paging performance degradation.
In case of too high PCH load, objective is first to redesign LAC by splitting the
high runner LAs with high paging occupancy.
71
8. Impact for 2 RNCs per LAC
• 8.1 Overview
• 8.2 Dimensioning Method Overall Precheck
• 8.3 Radio Occupancy

8.1 Overview
73
Paging Rate
• There is no hard-coded product limitation on the RNC, related to the amount of

paging.
• As far as the RNC is not in overload situation, the generated paging signaling
overload is supported.
• RANAP paging request may be trashed only when RNC is reacting to overload
condition.
• For a given call profile, if 2 RNC are equal to one LA, the maximum arrival paging
rate is proportional to the number of paging located under the coverage of the 2
RNCs.
• Combined CN paging/sec = max CN paging RNC1 + max CN paging RNC2 per sec
74
CN Paging Rate VS Paging Record Rate
Combined CN paging/sec = (max CN paging RNC1 + max CN paging RNC2) per sec
Combined record paging/sec = (1 + repetition) X (CN Paging RNC1 + CN Paging

RNC2 per sec)
Estimation made with repetition = 1 means the combined record paging/sec = 2 X

combined CN paging/sec
These combined paging rates are used for estimate
• Radio Occupancy (PCCH Occupancy)
• PMC RAB CPU Load
75
8.2 Dimensioning Method Overall Prechecks 1/3
1. Check that each RNC are not already with high PCCH load
• Counters :
 Paging record rate per Second per Cell = Paging005 / (3600* Cell
numbers in the RNC) – if data collected hourly. The threshold should be < 150
paging records per cell / per sec
 Paging request Type 1 sent by Core Network per Second = Paging003 /
(3600) - if data collected hourly. The threshold should be < 70 paging
messages per sec
 Paging 008R RepeatedPagingFailure must be below 1%
76
Prechecks 2/3
2. Check that the two RNCs are not in CPU overload before LAC merged
Counter: 20202 VS.ApCpuUtilizationAvg
Release
CPU Type UA6.0 UA7.0 UA7.1
PMC RAB (DCPS) 80% 80% 80%
PMC PC (DCPS) 70% 70% 80%
PMC TMU (DCPS) 70% 70% 80%
All Others DCPS CPU 70% 70% 70%
And all PSFP CPU
• 810.4 VS.UnhandledPagingRequestsCs_OverloadControls
• 811.4 VS_UnhandledPagingRequestsPs_OverloadControls
77
Radio Occupancy
3. For the two RNCs check the Configuration. Methodology done for similar
configuration as follow.
 10 DCPS or 10 PSFP
 Configuration bi-S-CCPCH
 UTRAN Paging Repetition = 1
RNC x and RNC y can not be

Combined Paging combined on the same LAC
Record Rate per sec < No
150
Yes The max value for each RNC must not exceed 200
and the combined average value should be < 150
RNC x and RNC y can be combined

on the same LAC
78
PMC RAB CPU LOAD
• Occupancy estimation:
BH CPU BH Paging
Paging CPU cost abacus
+
Report PMC RAB CPU CPU Load Paging
Generation RNC1 Load Max RNC1 Of RNC1
> Threshold
+
Report CPU Load Paging
Generation PMC RAB CPU
Load Max RNC2 Of RNC2
RNC2
Input:
•RNC Configuration
Inputs:
•Cells Number
CPU Counters
•Paging Record Rate RNCx
79
PMC RAB CPU LOAD
• Dimensioning Method
PMC RAB CPU Load estimation
RAB Max CPU

Load
RNC1 + RNC2 paging RNC1 + RNC2 paging

Contribution CPU Contribution CPU
cost cost
Compare to CPU threshold Max
PSFP 70% and DCPS 80%
80
Paging and CPU Load Monitoring 1/2
• The maximum PMC RAB CPU load is determined with the counter
20202: VS.ApCpuUtilizationAvg
• With a configuration with 10 DCPS and nbPagingRepetition = 2 the
abacus is as follow:
81
Paging and CPU Load Monitoring 2/2
This estimation show the PMC RAB CPU load for paging and is made with UTRAN Repetition
= 1 and a configuration of 10 DCPS. We recommend to never touch the red values.
Cells number / 100 200 300 400 500 600 700

LAC
CN Paging Rate/s
20 0.3% 0,7% 1.08% 1.44% 1.8% 2.16% 2,52%

30 0.54% 1,08% 1.6% 2.16% 2.7% 3.2% 3.78%
40 0.72% 1.44% 2.16% 2.79% 3.6% 4.32% 5.04%
50 0.9% 1.8% 2.7% 3.6% 4.5% 5.4% 6.3%
60 1.08% 2.16% 3.24% 4.32% 5.4% 6.48% 7.56%
70 1.26% 2.52% 3.78% 5.04% 6.3% 7;56% 8.82%
80 1.44% 2.8% 4.32% 5.76% 6.98% 8.64% 10.08%
90 1.66% 3.24% 4.86% 6.48% 8.1% 9.72% 11.34%
100 1.8% 3.6% 5.4% 7.2% 9% 10.8% 12.6%
Index Return
82
83
84

UA08 1 RNC Paging Engineering Guidelines V02

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UA08 1 RNC Paging Engineering Guidelines V02

Uploaded by

Copyright:

Available Formats

WELCOME

TIS ONE ENGINEERING GUIDELINES

COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

3 | UA7.x and UA8.1 New Features

6 | Simulation Templates for Paging Occupancy

7 | Guidelines for LAC Splitting

8 | Impact for 2 RNCs per LAC

• 1.1 Paging Mechanisms

COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

RLC Logical Channel PCCH

BTS RNC MSC/SGSN

T3313 (SGSN)/T3113 WCS

Paging At timer expiry, the

BTS RNC MSC/SGSN

Core Paging Parameters Current Value

DRX Cycle UTRAN Number of DRX

• UTRAN repetition is controlled by DRX and Core repetition is controlled by T3113.

• DRX cycle calculation is controlled by 2 parameters csBrxCynLngCoef and

• The parameter nrOfPagingRepetition indicates the number of retransmissions of the

• The parameter sysinfochangePagingRepetitions Controls the number of DRX cycles during

• The parameter isPagingRepetitionAllowed is the flag to activate or deactivate paging

• It is recommended to use the Bi-SCCPCH configuration, since this configuration

• The parameter nrOfPagingRepetition indicates the number of retransmissions of the paging

 Paging Repetition mechanism allows to decrease call establishment failure rate

3GPP parameter : Number of paging repetition

Goal : To overcome sporadic RF problems

• 2.1 RNC Dimensioning vs Expected Paging Rate

Mobility in CELL_PCH and URA_PCH states

• If using X_PCH and Paging Repetition, then multi S-CCPCH is mandatory.

• 3.1 Improvement of PCH Scheduling (79036)

COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

• A simplified transition summary, highlighting the integration of the new RRC

URA PCH and eURAPCH: UTRAN •URA Update

• There is interaction with feature “FRS 108388 UA07 enhanced URA_PCH

URA_PCH to HSPA no direct trasition URA_PCH to HSPA with direct trasition

Cell Update 94 Cell Update 94

Total Delay 955 ms Total Delay 599 ms

• Fast dormancy behavior can be enhanced with Rel 8 UE.

Fast Transition enabled from Direct transition

Avoid UL DPCCH tx until T1 timer

Current UE, especially Smartphone, in CELL_DCH triggers a release indication

97425 - Fast Dormancy support in UTRAN allows direct transition to PCH.

• 4.1 Counters of Paging in NPO

COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

On NPO, take the view with Indicator and Basic -- Paging

• 801 (VS.ReceivedPagingRequest) per RNC and per domain (CS/PS)

• 812 / 813 (VS.PagingRecordsSentOnPcchCs/Ps) per Fddcell and per paging cause

- All paging messages sent on the PCCH

1. Paging005R (NumberofPagingRecordonPCCH_Paging005_CR): This

COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

• The paging optimization is based on the KPI paging success rate.

Paging success rate (LAC) = ΣRRC.AttConnEstabLastperProc (scr 5, 6, 7, 8,17, 18 & 19

– 5 terminating conversational call

– 5 terminating conversational call

• 6.1 RNC Paging Multicasting

COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

• Aim is to verify the PMC_RAB occupancy using

 Parameters for this template: at Committed Capacity

Market Model with 10 PS2, CP4 UA07.1.2 release and

CPU PMC-RAB Load 60,7 % 60%

AO FACH to URA 0,5

Cells per LAC 1000

Cells per RNC 1000

CPU PMC-RAB Load 65,9% 80%

CN Paging Rate * (Cells/LAC) * Paging CPU cost (1+0,6 repetition)