paging capacity analysis

For internal use onlyPresentation / Author / Date 1 © Nokia Siemens Networks

Simon Browne

November 12th 2009

London 3G Paging Analysis


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.

URA_PCH CELL_PCH

CELL_FACH CELL_DCH

Idle Mode

Paging channel, cell-level.

Type 1

Paging channel, URA-level.

Type 1

SRB. Type 2.SRB. Type 2

Paging channel, LA/RA-level.Type 1


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

UE In Idle mode

RRC connection establishment

PICH

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

CN

RANAP: PAGING

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.

UE BS RNC

RRC:PAGING TYPE 2

CN 1

RANAP:PAGING

UE has signallingconnection to CN1

UE is in CELL_FACH or CELL_DCH state

Paging response to CN 2

CN 24MM Connected MM Idle

UE BS RNC

RRC:PAGING TYPE 2

CN 1

RANAP:PAGING


UE is in CELL_FACH or CELL_DCH state


CN 24MM Connected MM Idle


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.

UE BTS RNC CN 1

RANAP:PAGING


UE is in URA_PCH or CELL_PCH state

CN 2MM Connected


PICH


(RACH) RRC Cell Update : Paging Response

UE BTS RNC CN 1

RANAP:PAGING


UE is in URA_PCH or CELL_PCH state

CN 2MM Connected


PICH




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

2. Paging Request (P-TMSI)

MM Cell Update

RRC: PAGING TYPE 1 with PICH BTS -> UE

SGSN

1.PDP PDU

The MAC-d (RLC) in RNC indicates that there is downlink user data in RLC buffers then the RRC signaling entity initiates the paging procedure


UE RNC

2. Paging Request (P-TMSI)

MM Cell Update

RRC: PAGING TYPE 1 with PICH BTS -> UE

SGSN

1.PDP PDU

The MAC-d (RLC) in RNC indicates that there is downlink user data in RLC buffers then the RRC signaling entity initiates the paging procedure



Paging – DRX Cycle DefinitionThe 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 databaseThe 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 1The 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 originatedIn 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

0.0%

2.0%

4.0%

6.0%

8.0%

10.0%

12.0%

14.0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

320ms buffer=9

640ms buffer=4


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 Message17:55:53.53 CS - 07707643 - Idle Paging17:55:57.72 CS - 07707643 - Idle Paging17:57:02.53 CS - 07707643 - Idle Paging17:57:07.02 CS - 07707643 - Idle Paging18:02:02.59 CS - 07707643 - Idle Paging18:02:06.96 CS - 07707643 - Idle Paging18:17:02.63 CS - 07707643 - Idle Paging18: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

0

100

200

300

400

500

600

700

0 500 1000 1500 2000 2500 3000 3500 4000

Delay (ms)

Sam

ple

s

CDF of CS Paging Response Delay

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1000 2000 3000 4000 5000

Delay (ms)

CD

F


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 Message18:26:31.71 PS DD1F8182 - Idle Paging18:26:39.71 PS DD1F8182 - Idle Paging18:26:47.72 PS DD1F8182 - Idle Paging18:26:51.73 PS DD1F8182 102485 Initial Direct Transfer (page resp)18:28:31.71 PS DD1F8182 - Idle Paging18:28:39.71 PS DD1F8182 - Idle Paging18:28:47.71 PS DD1F8182 - Idle Paging18:30:48.32 PS DD1F8182 - Idle Paging18:30:50.02 PS DD1F8182 29445 Initial Direct Transfer (page resp)18:31:09.86 PS DD1F8182 - Idle Paging18:31:13.96 PS DD1F8182 33014 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

0

50

100

150

200

250

300

0 500 1000 1500 2000 2500 3000 3500 4000

Delay (ms)

Sam

ple

s

CDF of PS Paging Response Delay

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1000 2000 3000 4000 5000

Delay (ms)

CD

F


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 Message18:32:31.57 CS 234102153399170 - 61107 Connected Paging (RRC)18:32:32.28 CS 234102153399170 - 61107 Connected Paging (RRC)18:32:34.29 CS 234102153399170 - 61107 Connected Paging (RRC)18:32:36.16 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

0

200

400

600

800

1000

1200

1400

0 500 1000 1500 2000

Delay (ms)

Sam

ple

s


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 Message14:29:37.18 234106173192875 - 34453 Connected Paging (RRC)14:29:37.72 - - 34453 Cell Update (page resp)14:36:12.48 234106173192875 - 34453 Connected Paging (RRC)14:36:13.19 234106173192875 - 34453 Connected Paging (RRC)14:36:13.24 - - 34453 Cell Update (page resp)14:40:08.01 234106173192875 - 34453 Connected Paging (RRC)14:40:08.72 234106173192875 - 34453 Connected Paging (RRC)14:40:08.76 - - 34453 Cell Update (page resp)14:50:25.44 234106173192875 - 34453 Connected Paging (RRC)14:50:26.04 - - 34453 Cell Update (page resp)15:00:44.19 234106173192875 - 34453 Connected Paging (RRC)15:00:44.90 234106173192875 - 34453 Connected Paging (RRC)15:00:44.91 - - 34453 Cell Update (page resp)15:11:03.63 234106173192875 - 34453 Connected Paging (RRC)15:11:04.34 234106173192875 - 34453 Connected Paging (RRC)15:11:04.43 - - 34453 Cell Update (page resp)15:13:46.94 234106173192875 070008E8 34453 Connected Paging (RC3)15:13:46.94 234106173192875 - 34453 Connected Paging (RRC)15:13:47.65 234106173192875 - 34453 Connected Paging (RRC)15:13:48.46 - 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 RNC % of Total Pages/cell/s LA/RA %UE Idle UE Connected

CS 57580 25157 0 20350897 56.2% 16.0 99.88%PS 44564 599 157895 15889586 43.8% 12.5 99.00%

Pages from CN Total (over 353 cells)


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

0

5

10

15

20

25

30

35

40

18

:00

18

:04

18

:08

18

:12

18

:16

18

:20

18

:24

18

:28

18

:32

18

:36

18

:40

18

:44

18

:48

18

:52

18

:56

19

:00

Time

Lo

ad

(%

)


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 PSResponse to 1st page 47560 30736Response to 2nd page 4920 3138Response to 3rd page n/a 690No response 8502 5027Overall 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 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 ResultResponse to 1st page 49490Response to 2nd page 8457Response to 3rd page 2756No response 5149Overall 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

With RU10 a level of prioritisation of paging is introduced, with feature RAN1318 Paging Queuing.Paging messages are set to either high or low priority, depending whether they are first page attempts or retransmissions.First page attempts will be prioritised over repeat attempts, both for core-originated and for RNC-originated cases.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

Low priority paging messages

High priority paging messages

L3

Core Network

Cell

Paging message (RANAP: Paging)

PCH data


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

Documents