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.

For internal use only

2 Nokia Siemens Networks
 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_FACH CELL_DCH SRB. Type 2.

Paging channel, LA/RA-level.

Type 1

For internal use only

Idle Mode
3 Nokia Siemens Networks
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

For internal use only

4 Nokia Siemens Networks
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

Paging response to CN 2

For internal use only

5 Nokia Siemens Networks
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
For internal use only
6 Nokia Siemens Networks
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 MAC-d (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

For internal use only

7 Nokia Siemens Networks
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.

For internal use only

8 Nokia Siemens Networks
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.

For internal use only

9 Nokia Siemens Networks
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.

For internal use only

10 Nokia Siemens Networks
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 1 st 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 1 st
page have been received.

For internal use only

11 Nokia Siemens Networks
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)

For internal use only

12 Nokia Siemens Networks
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.

For internal use only

13 Nokia Siemens Networks
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).

For internal use only

14 Nokia Siemens Networks
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 1 st 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.

For internal use only

15 Nokia Siemens Networks
Paging Repetition: Cell-PCH State

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

single UE - these are highlighted.

For internal use only

16 Nokia Siemens Networks
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.

For internal use only

17 Nokia Siemens Networks
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.

For internal use only

18 Nokia Siemens Networks
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.

For internal use only

19 Nokia Siemens Networks
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.

For internal use only

20 Nokia Siemens Networks
RU10 Paging Changes
Core Network

With RU10 a level of prioritisation of paging

is introduced, with feature RAN1318 Paging Paging message (RANAP: 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. High priority paging Low priority paging
messages messages
The effect will be to improve the overall
paging success rate for high PCH loads,
since the first pages are those with the
highest success rates.
MAC-c

PCH data

Cell

For internal use only

21 Nokia Siemens Networks
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.

For internal use only

22 Nokia Siemens Networks