Paging Capacity Analysis

London 3G Paging Analysis
Simon Browne
November 12th 2009
For internal use only

1 © Nokia Siemens Networks Presentation / Author / Date
Introduction
BTS capacity analysis has shown that the current paging load
in Central London is becoming a concern. It is approaching
the 30% level that has previously been assumed to be a
working limit before paging loss occurs.
This analysis considers an analysis of the paging load and
performance.
It uses network statistics and RNC monitoring for the period
1800-1900 on Nov 5th 2009, on London RNC81.
The RNC was at RAS06 level and Cell-PCH was
implemented.

Paging and RRC States
The paging method used depends on the UE RRC state.

Paging across the Location/Routing area is required for a UE in idle state, while for a
UE in RRC connected state the paging can be performed at either Cell or URA level,
as appropriate. If in Cell-DCH or Cell-FACH state the paging will be done over the
existing SRB and will not use the paging channel. URA-PCH is implemented in
RU10.
Paging channel, Paging channel, cell-

URA-level. URA_PCH CELL_PCH level.
Type 1 Type 1
SRB. Type 2 CELL_DCH SRB. Type 2.

CELL_FACH
Paging channel, LA/RA-level.

Type 1

Idle Mode
Idle Paging
If the UE is in idle state the Paging Type 1 is sent out over the
PCH, as below, and the UE responds by initiating RRC
connection establishment and subsequently sending an Initial
Direct Transfer message indicating paging response.
The paging is generally RNC-wide – since the LA and RA
boundaries are per RNC in O2 UK – thus this type of paging
can place significant load on the PCH.
UE BTS RNC CN
UE In Idle mode
RANAP: PAGING
PICH
(FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TYPE 1
RRC connection establishment
Paging response

Connected Mode Paging: Cell-FACH/Cell-DCH
In this case the UE already has an established SRB the paging

is sent over this as a Paging Type 2 message. Hence, there is
no impact to the PCH.
The response is sent as a Direct Transfer message from the
UE. MM Connected MM Idle
UE 4 BS RNC CN 1 CN 2
UE has signallingconnection to CN1
UE is in CELL_FACH or CELL_DCH state RANAP:PAGING
RRC:PAGING TYPE 2
Paging response to CN 2

Connected Mode Paging: Cell/URA-PCH
Paging for UEs in the Cell/URA-PCH states can result from core-network originated
paging (from the core with which an existing connection does not exist) or from
downlink data transfer when a RAB exists with the PS core.
The example below shows the case of CN-originated paging: the Paging Type 1 is
sent over the PCH channel and the UE responds with a Cell Update message,
indicating paging response.
In URA-PCH state the paging is sent over each cell belonging to the URA, while in
Cell-PCH state it is sent only over the relevant cell.
MM Connected
UE BTS RNC CN 1 CN 2
UE has signalling connection to CN1
UE is in URA_PCH or CELL_PCH state
RANAP:PAGING
PICH
(FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TYPE 1
(RACH) RRC Cell Update : Paging Response
Paging response to CN 2
Connected Mode Paging: Cell/URA-PCH
The case below is where data is received from the PS core when a PS RAB exists
and the UE is in Cell/URA-PCH state.
The Paging Type 1 (RNC-originated) is sent over the PCH channel and the UE
responds with a Cell Update message, indicating paging response.
In URA-PCH state the paging is sent over each cell belonging to the URA, while in
Cell-PCH state it is sent only over the relevant cell.
UE RNC SGSN
The MACd- (RLC) in RNC

indicates that there is
downlink user data in RLC 1.PDP PDU
buffers then the RRC
signaling entity initiates
the paging procedure
2. Paging Request -TMSI)
(P
RRC: PAGING TYPE 1 with PICH BTS
-> UE
MM Cell Update
(RACH) RRC Cell Update : Paging Response

Paging – DRX Cycle Definition
The RNC determines the DRX cycle length value for an idle UE based on the default value
of a "CN domain specific DRX cycle length coefficient", in the radio network database
The RNC uses the CS or PS domain specific DRX cycle length coefficient, depending on
which CN domain the RANAP:PAGING message is received from
• Parameter: RNC: CNDRXLength, range: (640, 1280, 2560, 5120) ms. This parameter is
given for CS domain and PS domain separately. In the O2 UK case the value is 640ms
for both.
• If the RANAP: PAGING message includes an individually assigned CN specific DRX
cycle length coefficient, the RNC uses this value to page the idle mode UE.
The UTRAN broadcasts CN domain specific DRX cycle length information in SIB 1
The UE may be attached to different CN domains with different CN domain specific DRX
cycle lengths. The UE must store each CN domain specific DRX cycle length for each CN
domain the UE is attached to and use the shortest of those DRX cycle lengths.
In UTRAN connected mode (applicable for a UE in URA/Cell_PCH states) the RNC shall
use the DRX cycle length according to the following rules:
• for UTRAN originated pages: UTRAN_DRX_length, range: (80, 160, 320, 640, 1280,
2560, 5120) ms, default: 320 ms;
• for CN originated pages: the shorter of UTRAN_DRX_length and CNDRXLength of the
CN from which the page is originated
In O2UK UTRAN_DRX_length is set to 320ms, thus this represents the length to be used
for URA/Cell-PCH states.

DRX Cycle Blocking
There is a buffer for each paging group, the size of which depends on the DRX cycle length.
In the O2 case, the buffer size is 4 cycles for the 640ms DRX length and 9 cycles for the 320ms length.
With the greater buffer size, ‘clashes’ of pages to the same paging group are likely to result in less page loss
since there is increased probability of the delayed pages being sent in a future DRX cycle. Therefore higher
load levels can be tolerated for the same paging loss.
The graph below shows the performance based on paging arrival rate having a Poisson distribution. Loss
begins to occur with the 640ms cycle above 30% load; 1% blocking is reached at 58% load and 2% at 68%
load.
From a target maximum load perspective it is therefore felt that a maximum target loading in the range 58% -
68% is appropriate, depending on the allowed loss rate.
Lost Pagings v Paging Load
14.0%
12.0%
10.0%
8.0% 320ms buffer=9

6.0% 640ms buffer=4
4.0%
2.0%
0.0%
20%
10%
30%
40%
50%
60%
70%
80%
90%
100%

Paging Repetition: CS Core
In the O2 UK case, paging repetition from the CS core network

is with a single retransmission after 4 seconds.
An example is shown below where there are four unsuccessful
paging cycles.
Time cn_domain IMSI TMSI srnti Message
17:55:53.53 CS - 07707643 - Idle Paging
17:55:57.72 CS - 07707643 - Idle Paging
17:57:02.53 CS - 07707643 - Idle Paging
17:57:07.02 CS - 07707643 - Idle Paging
18:02:02.59 CS - 07707643 - Idle Paging
18:02:06.96 CS - 07707643 - Idle Paging
18:17:02.63 CS - 07707643 - Idle Paging
18:17:07.02 CS - 07707643 - Idle Paging

Paging Response Timing – Idle CS
The delay between the idle paging request being generated within the RNC
and the UE paging response being received has been measured.
The graphs below show the distribution for successful 1st pagings. It can be
seen that the 50% CDF point is at ~1.5s.
The repetition time of 4s is seen to occur after >95% of responses to the 1st
page have been received.
Paging Response Delay Distribition - CS CDF of CS Paging Response Delay
700 1
0.9
600
0.8
500 0.7
0.6
Samples
400
CDF 0.5
300 0.4
200 0.3
0.2
100
0.1
0 0
0 500 1000 1500 2000 2500 3000 3500 4000 0 1000 2000 3000 4000 5000
Delay (ms) Delay (ms)

Paging Repetition: PS Core
In the O2 UK case, paging repetition from the PS core network

is with two retransmissions on an interval of 8 seconds.
An example is shown below where there are three successful
paging cycles and one unsuccessful. Paging responses occur
4.0s, 1.7s and 4.1s, respectively, after the page is sent by the
RNC (the timing includes the delay associated with the sending
of the page in the relevant DRX cycle)
Time cn_domain PTMSI srnti Message
18:26:31.71 PS DD1F8182 - Idle Paging
18:26:51.73 PS DD1F8182 102485 Initial Direct Transfer (page resp)
Paging Response Timing – Idle PS
The delay between the idle paging request being generated within the RNC
and the UE paging response being received has been measured.
The graphs below show the distribution for successful 1st pagings. As might
be expected the profile is similar to that of CS with the 50% CDF point at
~1.5s.
Paging Response Delay Distribition - PS CDF of PS Paging Response Delay
300 1
0.9
250
0.8
200 0.7
0.6
Samples
CDF
150 0.5
0.4
100
0.3
50 0.2
0.1
0 0
0 500 1000 1500 2000 2500 3000 3500 4000 0 1000 2000 3000 4000 5000
Delay (ms) Delay (ms)

Paging Repetition: URA/Cell-PCH State
In the URA/Cell-PCH case retransmissions are initially

performed by the RNC. The intervals are set by:
•PageRep1stInterv (default 700ms)
•PageRep2ndInterv (default 2s)
This means that after the RNC sends out the first paging
message, if no reply is forthcoming within 700ms a
retransmission occurs, and after a further 2s without reply a
second retransmission is made. This can be seen in the
example below and a further retransmission is made due to a
repetition from the core network (~4s after first page).
Time cn_domain IMSI TMSI srnti Message

18:32:31.57 CS 234102153399170 - 61107 Connected Paging (RRC)

Paging Response Measurement: Cell-PCH State
The distribution of the delay between the connected mode paging type 1 message being
generated within the RNC and the paging response (Cell Update) being received has
been calculated.
The results are presented in terms of the delay from the 1st page. Beyond ~900ms there is
ambiguity as to which page the UE has responded to; the ‘resurgence’ at around 1-1.1s
could be a result of responses to the retransmission at 700ms.
The response shows that the 700ms repetition is occurring in the main peak of the
responses to the first page. Based on the curve, a more appropriate retransmission time
would be 900ms – this would reduce the number of un-necessary repetitions while
minimising the increase in PS interruption time in the cases where the first page has not
been received.
Paging Response Delay Distribition - Connected Mode Type 1
1400
1200
1000
Samples
800
600
400
200
0
0 500 1000 1500 2000
Delay (ms)
Paging Repetition: Cell-PCH State
The example below shows the un-necessary retransmissions occurring to a

single UE - these are highlighted.
Time IMSI TMSI srnti Message

14:29:37.18 234106173192875 - 34453 Connected Paging (RRC)
14:29:37.72 - - 34453 Cell Update (page resp)
15:13:46.94 234106173192875 070008E8 34453 Connected Paging (RC3)
15:13:48.46
For internal use only - 070008E8 34453 Initial Direct Transfer (page resp)
Paging Volumes
For the measurement period monitored the overall paging volumes are
shown below. The values have been produced from a mixture of counters
and RNC monitoring.
It can be seen that the PS paging is contributing ~44% of the load.
Of the total pages sent, >99% are sent at LA/RA level rather than cell level.
The proportion is so high because even though idle pagings represent only
~36% of the overall proportion they are each sent on all 353 cells, thus the
total idle paging proportion at cell level is very heavily dominated by these.
The above indicates that to improve the paging capacity it will be necessary
to tackle the level of idle-mode paging.
Core Pages from CN Pages from RNC Total (over % of Total Pages/cell/s LA/RA %
UE Idle UE Connected 353 cells)
CS 57580 25157 0 20350897 56.2% 16.0 99.88%
PS 44564 599 157895 15889586 43.8% 12.5 99.00%

PCH Capacity
Up to and including the RU10 release, the paging capacity on any cell is 100
messages per second. This is because a single paging message can be sent in one
radio frame (10ms) - an 8kb/s transport channel.
The graph below shows the average paging load per minute per cell during the
measurement hour. It can be seen to peak at ~37% at the start of the hour and then
reduce over time.
Note that the paging capacity will increase in the RU20 release where a 24kb/s PCH
can be deployed; this allows up to an eight-fold increase in capacity.
Paging Load
40
35
30
25
Load (%)
20
15
10
0
18:00
18:04
18:08
18:12
18:16
18:20
18:24
18:28
18:32
18:40
18:44
18:48
18:52
18:56
18:36
19:00
Time
Success Rates: Idle
The table below shows the various success rate metrics for idle paging, calculated for
CS and PS from the RNC monitoring. Note that the period of measurement extends
beyond the hour used for the previous calculations.
The trends for CS and PS are almost identical, although only PS has a third paging
attempt.
Overall paging success rate is ~86%/87%, with the success rate of the first paging
being 78%. 2nd paging success rate drops to ~36% and the third paging, for PS, has
a success rate of only 12%.
If the third paging for PS were not performed, the success rate would reduce to
85.5% and the volume of idle PS paging would reduce by 10.6%. This could be an
acceptable trade-off where PCH capacity is of concern.
Measure CS PS
Response to 1st page 47560 30736
Response to 2nd page 4920 3138
Response to 3rd page n/a 690
No response 8502 5027
Overall success rate 86.1% 87.3%
Success rate at 1st page 78.0% 77.6%
Success rate at 2nd page 36.7% 35.4%
Success
For internal use only rate at 3rd page n/a 12.1%
Success Rates: Connected Mode Type 1
The table below shows the various success rate metrics for connected mode Paging
Type 1 pages, calculated from the RNC monitoring.
An estimation has been made of the 1st and 2nd page success rates using the
assumption that 40% of the 1st page responses arrive after the 1st retransmission
occurs, i.e. these would otherwise be counted as a 2nd page success.
The net result is that the overall success rate is ~92%, with success rates at the 1st,
2nd and 3rd pages being 75%, 52% and 35%, respectively.
Measure Result
Response to 1st page 49490
Response to 2nd page 8457
Response to 3rd page 2756
No response 5149
Overall success rate 92.2%
Success rate at 1st page 75.2%
Success rate at 2nd page 51.7%
Success rate at 3rd page 34.9%

RU10 Paging Changes
C ore N etw ork
With RU10 a level of prioritisation of paging

is introduced, with feature RAN1318 Paging P aging m essage (R A N AP: Paging)
Queuing.
Paging messages are set to either high or
low priority, depending whether they are first L3
page attempts or retransmissions.

First page attempts will be prioritised over
repeat attempts, both for core-originated and
for RNC-originated cases. H igh priority paging Low priority paging
The effect will be to improve the overall m essages m essages
paging success rate for high PCH loads,

since the first pages are those with the
highest success rates.
M A C -c
PC H data
C ell

Recommendations
The paging load in Central London is reaching levels at which it is possible that paging loss may
begin to occur as a result of DRX cycle blocking. The paging traffic has been shown to be
dominated by idle paging.
Any blocking will be very low at these levels, however, and should not reach 1% until a loading
of ~ 58% occurs. This could be used as a target load level for the RAS06 environment.
In RU10 the impact of high load will be reduced as a result of the prioritisation functionality,
hence higher loads can be tolerated for a given paging success rate. The target load could then
increase to a higher level, such as 68%, which corresponds to 2% blocking (of each page, the
first pages would experience lower blocking). Any such benefits should be monitored from the
core network, however, to confirm the benefits.
It is seen that connected mode paging is currently experiencing a greater than required
retransmission rate as a result of the setting of parameter PageRep1stInterv. This parameter
could be increased slightly (for example, to 900ms) to reduce the retransmission rate, although
this is unlikely to have a significant impact on the overall paging load with only Cell-PCH
implemented, With URA-PCH the gain would be greater and would offset to some extent the
increased paging traffic resulting from the introduction of the feature.
Overall idle paging could be reduced by ~5% if the third paging attempt for PS is disabled, at
the expense of a very small reduction in overall PS paging success rate.
It is likely that the PS paging load is particularly high on those devices that use fast dormancy,
which will require more frequent idle paging than connected mode paging. Optimisation of this
functionality could offer significant benefits to paging capacity. If this can not be achieved then
the largest potential reductions prior to RU20 are likely to involve a reduction in the LA/RA sizes.
Paging success rate should be measured from the core networks and correlated with the
measured RNC load periodically to confirm that the paging performance is at satisfactory levels.


Paging Capacity Analysis

Uploaded by

Document Information

Original Title

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

Paging Capacity Analysis

Uploaded by

Copyright:

Available Formats

London 3G Paging Analysis

For internal use only

For internal use only

The paging method used depends on the UE RRC state.

Paging channel, Paging channel, cell-

SRB. Type 2 CELL_DCH SRB. Type 2.

Paging channel, LA/RA-level.

For internal use only

(FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TYPE 1

RRC connection establishment

For internal use only

In this case the UE already has an established SRB the paging

UE has signallingconnection to CN1

UE is in CELL_FACH or CELL_DCH state RANAP:PAGING

For internal use only

The MACd- (RLC) in RNC

For internal use only

For internal use only

Lost Pagings v Paging Load

8.0% 320ms buffer=9

For internal use only

In the O2 UK case, paging repetition from the CS core network

For internal use only

Paging Response Delay Distribition - CS CDF of CS Paging Response Delay

For internal use only

In the O2 UK case, paging repetition from the PS core network

Paging Response Delay Distribition - PS CDF of PS Paging Response Delay

For internal use only

In the URA/Cell-PCH case retransmissions are initially

Time cn_domain IMSI TMSI srnti Message

For internal use only

The example below shows the un-necessary retransmissions occurring to a

Time IMSI TMSI srnti Message

For internal use only

For internal use only

With RU10 a level of prioritisation of paging

page attempts or retransmissions.

The effect will be to improve the overall m essages m essages

paging success rate for high PCH loads,

For internal use only

For internal use only

You might also like