rnc paging engineering guidelines ua8.1[1]

8/19/2019 RNC Paging Engineering Guidelines UA8.1[1]

http://slidepdf.com/reader/full/rnc-paging-engineering-guidelines-ua811 1/90

COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED. ALCATEL-LUCENT — INTERNAL PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION

1

WELCOMETIS ONE ENGINEERING GUIDELINES




PAGING ENGINEERING GUIDELINES UA08.1UMT/IRC/INF/35601 V01/EN

Didier Bouvrande TIS ONE – Internal Document

August 2011




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




5

1.1 Paging Mechanisms

If the UE is in idle mode, UTRAN doesn’t know them and can just forward the pagingmessage 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 thepaging message just to this RNC

The RNC knows the UE uses the dedicated or common channel to send the pagingmessage




6

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,96seconds. 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 UEuses its IMSI and others parameters send on the SIB.


http://slidepdf.com/reader/full/rnc-paging-engineering-guidelines-ua811 7/90COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

ALCATEL-LUCENT — INTERNAL PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION

7

1.1 Paging Mechanisms (follow)

• When a passing message is received from RANAP, the paging occasion (PO, i.e. occurrenceat which a paging has to be sent for that user) is determined by the RNC using the mobileIMSI 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 decideswhether 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 occasionsaccording 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 makerecommendations in terms paging strategy and dimensioning.

• The overall paging strategy is comprised of:

CN (Core Network) paging strategy

UTRAN paging strategy


http://slidepdf.com/reader/full/rnc-paging-engineering-guidelines-ua811 8/90COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

ALCATEL-LUCENT — INTERNAL PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION

8

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 thisprocedure by transmitting a PAGING-TYPE-1 on a appropriate paging occasion (PO) onPCCH.

Theoretical throughput of PCCH is 240 bits (one transport block) every 10 ms = 24 kbits/s. 7bits from 240 bits Transport block are used for header, so only 233 bits are available totransport 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

One UTRAN Paging Transport Block (Paging message) can accommodate up to 5 pagingrecords depending on their IMSI/TMSI structure.

Please see the channel transport composition on the next slide

1.2 Paging Channel Configuration




9

1.2 Paging Channel Configuration

PCCH Channel Composition

RLCLogical Channel

type

PCCH

RLC Mode TM

Payload sizeq, bit 240

Max data rate, bps 24000

AMD/UMD/TrD PDU

header, bit

0

MAC MAC header, bit 0MAC Multiplexing N/A

Layer 1TrCH type PCH

TB sizes, bit 240

TFS – TFO, bits 0x240

TFS – TF1, bits 1x240

TFS – TF2, bits N/ATTI, ms 10

Coding Type CC 1/2

CRC, bit 16Max number of bits/TTIbefore rate matching 520

RM attribute 210-250




10

1.3 Paging Cycles CN part and UTRAN part

Overall Paging Repetitions on Core and UTRAN

Paging Repetition

timeline in UTRAN

Example of PagingParameters on Core

and UTRAN

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

PS Core number of pages 7

UTRAN Paging Parameters

DRX length CS csDrxCynLngCoef 6 (640 ms)

DRX length PS psDrxCynLngCoef 6 (640 ms)

UTRAN Paging Repetition nrOfPagingRepetition 1

Paging

Paging

RNC RNC

MSC/SGSN MSC/SGSN

BTS BTS

Paging

Paging

Paging Response

T3313 (SGSN)/T3113 WCS

At timer expiry, the

paging is repeated

RNC RNC

MSC/SGSN MSC/SGSN

Paging

BTS BTS

Paging

Paging

Paging

DRX cyclelentgh Paging Response

Paging

Core Network repetition

UTRAN repetition

Paging

Paging

RNC RNC

MSC/SGSN MSC/SGSN

BTS BTS

Paging

Paging

Paging Response

T3313 (SGSN)/T3113 WCS

At timer expiry, the

paging is repeated

RNC RNC

MSC/SGSN MSC/SGSN

Paging

BTS BTS

Paging

Paging

Paging

DRX cyclelentgh Paging Response

Paging

Core Network repetition

UTRAN repetition




11

1.3 Paging Cycles CN part and UTRAN part UTRAN DRX Cycle Length

DRX Cycle

Length (s)

UTRAN

Coefficient

Number of DRX

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 lengthcoefficient.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 lengthrange 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 thelonger the delay before the UE can respond to a paging message. The DRX cyclelength could impact the Paging success rate.




12

1.4 Paging ParametersRefer 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 ControlThe DRX cycle (interval during which the paging occasion has to be monitored by themobile), is configurable independently for the CS and PS networks.

Number of additional repetitions that UTRAN performs in response to a single page invokefrom the core. The paging repetition on UTRAN is performed even on receipt of successfulpage response to the first page.

S-CCPCH configuration –> Mono S-CCPCH (PCH & FACH transport multiplexed on the sameS-CCPCH), Bi S-CCPCH (PCH & FACH transport on separate S-CCPCH). See Slide chapter 1.5




13

1.4 Paging Parameters 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 witha certain time then the core network repeats the paging. The time interval for the repetitionand 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 statethen 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 thepaging request.

• If the time to the next free PO is longer than the time until paging repetition by the corenetwork then the paging is repeated unnecessarily. The duplicated paging again increases

the load on the paging channel (PCH) which will cause further duplications and furtherincreased load. Finally, it could happen that paging need to be discarded because no free POcan be found.




14

• Utran DrxCycLngCoef 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 psDr xCynLngCoef and isapplied 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 consideronly POs within the time given by the new parameter tpageVal . If no free PO is found within this timethen 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 thepaging type 1 are repeated. There is no real relation ship with the nrOfPagingRepetition value but werecommand 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 featureat RNC level.

1.4 Paging ParametersListing of parameters linked to Core/UTRAN paging




15

• 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.

• 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

1.5 S-CCPCH Configuration




16

1.5 S-CCPCH Configuration

Bi - SCCPCH Configuration




17

• On the UTRAN side (Access Network), paging repetition is performed for all type 1 pagesirrespective 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. Unnecessarypaging repetitions lead to high paging load.

• The parameter nrOfPagingRepetition indicates the number of retransmissions of the pagingby 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 flesh one)

• If no repetition (value 0) on UTRAN side for real networks, the number of paging records bythe CN will increase slightly in order to compensate UTRAN repetition and improve pagingsuccess rate. This could be acceptable on a customer point of view in case of too high PCH

channel load.

• If repetition value is to high, that will increase the PCCH usage

1.6 Paging Repetition on UTRAN Principles




18

1.6 Paging Repetition on UTRAN 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 5times

• 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.




19

1.6 Paging Repetition on UTRAN 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




20

1.6 Paging Repetition on UTRAN

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 SuccessRate for the first Paging sent by Core Network thus having essentially an impacton user latency rather than on overall success rate.




21

For Access Network, paging record is systematically repeated (even if answered)

because based on the value nrOfPagingRepetition.

Cases to examine

If Value = 0 then the number of paging records repeated by the Core Networks willincrease in order to compensate UTRAN repetition.

If value = 1 then there is one repetition after the fresh one. It’s the best approachused by customers for avoid important increase of PCCH load and to have a goodpaging success rate.

If value = 2 then there are two repetitions after the fresh one. The paging successrate will be at a high level but there will be an important increase of PCCH Load.

If value = 3, three paging repetitions means an important increase of PCCH withoutbetter paging success rate

1.6 Paging Repetition on UTRAN Value Adjustment




22

1.6 Paging Repetition on UTRAN Value Adjustment

• Diagram vs Success Rate

Paging Repetition

N+1

Paging SuccessRate < 80%

Paging SuccessRate

No

Fallback

Yes

Yes

StopRecommended value

for Paging repetition =1. If Paging Success Rate

is not in the range, itshows the paging type 1

success rate is not efficient

Value should be >90%




23

1.6 Paging Repetition on UTRAN Value adjustment

• The number of UTRAN paging repetitions has to be adjusted to limit the load on PCH and PMC

RAB 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 framesof 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




24

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




25

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 tohandle 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.




26

The main advantage of URA_PCH versus CELL_PCH is to limit the amount of mobilityprocedures. But URA_PCH generates paging procedures which are limiting from 2points 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 someprerequisites. (refer to slide chapter 3.4)

• In URA_PCH state, the UE will not perform a Cell Update each time moving to a newcell 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, inURA_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 incase of new service establishment from the Core Network. (see fig on slide chapter2.2)

2.2 URA Size vs Paging Repetition 1/2




27

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 theprevious 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 LACs and to design efficiently the cells numberby RNC.

• As write on chapter 3.4, the association of eURA_PCH and direct PCH

DCHtransition ensures a direct transition for CS calls and for PS calls with high trafficvolume and decrease the paging load.




28

Mobility in CELL_PCH and URA_PCH states

2.2 URA Size VS Paging Repetition 2/2




29

We can see an important dependency between the paging record arrival rate and thePCH 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. With nrOfPagingRepetition = 3 we could have only 40 pagesrecord per second and about 60 pages records per sec with nrOfPagingRepetition = 2.

If we use configuration with multiple S-CCPCH (2 is recommended), PCH load can go

up to 100% with no restrictions. With nrOfPagingRepetition = 3 we could reach 70 pagesrecords per sec without significant PCH limitation and about 90 pages records par secwith nrOfPagingRepetition = 1.

In both cases, the maximum recommended pages records per sec (100 pagesrecords/sec) 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 oftoo important paging records per cell/per sec as important paging load (refer to slide

chapter 2.4)

Thanks to look at the table on the next slide

2.3 PCH Load Result interpretation




30

2.3 PCH Load Result interpretation

Pag Records/sec

Average Value

PagingRepetition =0

PagingRepetition =1

PagingRepetition =2

PagingRepetition =3

Mono S-CCPCH

PCH Load max =75%

Up to 100 80 60 40

Bi S-CCPCH

PCH Load Max =

100%

Up to 100 90 80 70

This configuration may concern network with

overloaded LAC and PCH channel. Slight impacton Paging Success Rate




31

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 decideif 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 around40% 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 isrecommended.

And a certain processing cost is to be considered.

A normal paging success rate should be above 90%. In case of trouble, monitor the CNpaging success rate ( verify PO and the paging repetition flags – Slides of part 1.2, 1.3, 1.4)

and activate the UTRAN paging repetition. As indicated on the previous slides, the PCH load occupancy should be limited to 75% in

mono-SCCPCH configuration and regarding the UTRAN paging repetition, take care ofnumber of paging records per sec.




32

2.4 PCH Load occupancy (following)

• ORF Trial has launched some actions to decrease the PCH load occupancy.

• This test has been made on a high loaded RNC in Paris area.

Decrease the UTRAN Paging Repetition from 1 to 0 which mean only the flesh UTRANpaging is sent.

UTRAN Repetition could be reduce to 0 in some critical cells where the pagingvolume is very high (over 200 paging records per cell and per sec) and where thenumber of Cells per RNC is above (+50%) the other ALU customers (around 400).

Results:

1. Paging Success Rate type 1 decrease of about 4 pts (but 0.4 pt on the customer view)

2. Paging Record per cell /per sec decrease of 45% on busy hours

3. No more Paging Cancelled

4. Paging Delayed decrease of 25%

5. And the global PCH channel occupation decrease from 80% to 50%.

This result is dependant of the RNC load (huge nbe of cells/RNC ..) and of the pagingrepetition failure over the network

Index Return




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)




34

• The purpose of this feature deliver in UA07.1.2 release is to avoid the duplication ofpaging 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 whichthe RNC will try to find a PO. If the RNC is not able for a paging type 1 request to find afree 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 afree PO as:

maxTransmissions = 4096/drxCycleLength – 1

• The PO occur every DRX cycle length (parameter utranDrxCycLngCoef ) in terms of framesof 10 ms duration. For the calculation of the time drxCycleLength can be reduced resultingin:

Maxtime = 4096 frames = 40.96 s

• The hardcoded value of 4096 is define. When searching for the next free PO the RNCaborts the loop after maxSpanWindow (internal value). The RNC calculatesmaxSpanWindow from the new parameter tpageVal

maxSpanWindow [frames] = tpageVal [ms] / 10

3.1 Improvement of PCH Scheduling (feature 79036) 1/2




35

3.1 Improvement of PCH Scheduling (feature 79036) 2/2




36

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 featureintroduces 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 ifthe 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 inone Location Area (e.g. New York or Paris), in order to reduce the quantity of paging.




37

3.2 Feature integration and transition overview

• A simplified transition summary, highlighting the integration of the new RRCpseudo-state in the Always-on mechanism is presented below.

• Once in the eURA_PCH pseudo-state, the RNC will keep the UE in thatpseudo-state until:

A. The UE sends a periodic URA update, the eURA_PCH pseudo-state will beterminated 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 updateindicating good communications between the RNC and the UE, that UE will betransitioned to the idle state when the T3 timer (PchToIdleTime r ) expires, or ifthe RNC has not detected activity from the UE for a period up to twice thesupervTimerPchAndCellFach timer.

Refer to the diagram below for the state described here.

When does user equipment (UE) go to URA PCH? Answer: upon inactivity expiry.




38

•Idle

•Cell-FACH •Cell-DCH

•URA-PCH

•URA Update

•Confirm

•CellUpdateConfirm

•RRC ConnectionRelease

•RB Reconfig

•( •DBC •)

•RRC

•Connection

•

Release

•RB Reconfig

•RB Reconfig

•RBReconfig

•Cell UpdateConfirm

q p ( ) g p y p yWhen does UE go to eURAPCH? Answer: upon paging failure from URAPCH.

•TRAFFIC LOW/T1

Idle: In order to re-establish dataservices from idle mode, the UE,RNC and SGSN all have to go

through RRC establishment,Security procedures, NAS Signalingand RAB establishment.

* The transition from URA-PCH &eURA-PCH states to Cell-DCH arevia the Cell-FACH as a transient.

URA PCH and eURAPCH: UTRANis in PMM_connected state. To CScore, UE is in CMM_idle state.

Cell_FACH and Cell_DCH for packettransfer is fast.

•eURA-PCH

NoPageResp for CS/PS

CellUpdateConfirme.g.responseto paging

Periodic URA updateconfirm

•Inactivity T3 / audittimer for no periodicURA update expires

•RB/PhyReconfig

NoPageResp for CS/PS

Inactivity T3 / audittimer for no

periodic URAupdate expRRC

Connection establish




39

3.2 Feature Value and Benefits

• The enhanced URA_PCH feature improve the high paging degradation observed bycustomer and the complain about calls which were going to voicemail without thephone even ringing with the existing URA_PCH.

• The main improvement concern the paging load drop off because of no transitionfrom eURA_PCH to idle after CS or PS paging failed. This can be used even withUTRAN 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




40

3.3 Paging Repetition per Domain (FRS 125177)

• This feature is for enhance the paging repetition and be able to differentiate thenrofpagingrepetitions 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 PCCHchannel occupancy could be reduce by 65% if only CS Speech and the SMS paging requestsare repeated.

• This feature differentiates the paging repetition at RNC based on paging cause. A newparameter (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 benrOfPagingRepetitions for following paging causes: Terminating Conversational Call,Terminating Low Priority Signalling; number of paging repetition is zero for following pagingcauses: 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 theother paging causes.




41

3.3 Paging Repetition per Domain

• 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. Thisnew feature (FSD 125177) has the overall control regarding the paging repetitionsregardless whether feature FRS 108388 is enabled or not. There is a restrictionwhen FRS 108388 is enabled and only options PagingRepetitionDomain = 0 and 1are allowed (i.e. value 2 is forbidden). This is required to allow correctfunctionality of FRS 108388.

i i i f ( )




42

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 transitionfor 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 transitionfrom URA_PCH or CELL_PCH to CELL_DCH is supported only for multi RAB casesi.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 theEstablishment Cause and/or the Traffic Volume Indicator (TVI) included in the CellUpdate message.

3 4 Di T i i f PCH DCH




43

3.4 Direct Transition from PCH to DCH

URA_PCH to HSPA no direct trasitionDelay (ms)

URA_PCH to HSPA with direct trasitionDelay (ms)

Cell Update 94 Cell Update 94Cell 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 comparablewith a transition from Cell_Fach (~550 ms)

3 4 Di t T iti f PCH t DCH




44

3.4 Direct Transition from PCH to DCH

The TVI if present when the cause for the Cell Update is ―Uplink DataTransmission‖ and is set to TRUE if, among other conditions, the Transport

Channel Traffic Volume (TCTV) is larger than the threshold defined forTraffic 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 todecide the target RRC State.

CELL_DCH

PS callCELL_FACH

CELL_PCH or

URA_PCH

Est. Cause

& TVI

TVI = FALSE & Est. Cause

<> MO/MT Conv/Str./I/B

TVI = TRUE

or

TVI = FALSE & Est. Cause

= MO/MT Conv/Str./I/B

Down Inactivity

Up

3 5 F t D h dli b UTRAN (FRS 97425)




45

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 itstransfer. 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 modewhich provides a latency gain when traffic resumes: 550ms. Moreoversignaling load is reduced on the RNC (control plane) when combined withdirect PCH to DCH transition

• Fast Dormancy is attractive for UE battery saving as well as for baseband and uplink radio resources.

3 5 F t D h dli b UTRAN




46

3.5 Fast Dormancy handling by UTRAN

Avoid UL DPCCH tx until T1 timer

expiration

CELL_DCH

URA_PCH /

CELL_PCH

•T1•HSDPAactivity

Fast Transition enabled fromCELL_DCH to URA_PCH justafter the end of download

Direct transitionfrom PCH to DCH in

UA08

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 FastDormancy)

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

Index Return




4. Paging Monitoring

• 4.1 Counters of Paging in NPO• 4.2 Counters Definition• 4.3 Radio Side Paging Position

4 1 Co nte s of paging in NPO




48

4.1 Counters of paging in NPO

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

4 2 Counters Definition




49

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

• 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





50


• 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 ofpaging record)

• invalid information (eg. unsupported LAC, RAC, PLMN), reset in progress (in case of RANAPreset)

• internal resources not available (no memory to allocate messaging buffers)

• RNC overload controls, other causes (not used)





51


• 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)

• 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 onURA_PCH orv Cell_PCH)

4 3 Radio Side Paging Position




52

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 records (fresh and repetition) sent on the PCCH per paging cause

• 812 VS.PagingRecordsSentOnPcchCs (Cell)

• 813 VS.PagingRecordsSentOnPcchPs (Cell)

4 3 Radio Side Paging Position




53

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)

Index Return




5. Paging Optimization • 5.1 Methodology• 5.2 Paging Success Rate Counters• 5.3 Paging Success Rate per LAC

5 1 Methodology




55

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 beenattempted 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:

highest average paging success rate > 90 %

highest max paging success rate about 98%

5 2 Paging Success Rate Counters




56

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 ( inidle 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

5 3 Paging Success Rate per LAC




57

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

5 3 Paging Success Rate per LAC




58

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




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




60


• In order to transform 1 Core Network request to 1 message per cell on the givenLA/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. TMUCPU cost is minimal and only depends on Paging Record arrival rate

– PMC-RAB : The chosen RAB multicast the Request to each RAB managing a concernedPCCH 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:

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 isuseful 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





61


6.2 Simulation one with Cell-PCH & URA PCH validated




62

6.2 Simulation one with Cell PCH & URA_PCH validated

• Aim is to verify the PMC_RAB occupancy usingRCT without CN paging request and up to 3 CNpaging request. High loaded network for this

simulation. Parameters for this template:

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

SMP5 TGEN call profile

CPU PMC-RAB Load 60,7 %

Template parameters Value

SMS 2

AO FACH to URA 0,5

AO PCH TO URA 0,4

AO URA TO FACH 0,5

Cells per LAC 1000

NodeB per RNC 500

Cells per RNC 1000

Cells per URA 200

Freq per Cell 2

CN Paging Request 0

10 x PS2, MS3+GE, CP4 V7,2 Processor Occupancy Distribution

at Committed Capacity

Simulation Profile with URA PCH activated

0%

10%

20%

30%

40%

50%

60%

70%

80%

Node

P r o c e s s o r O c c u p a n c y

Processor Occupancies

Engineering Limit

Processor Occupancies 54,7% 18,8% 16,5% 14,7% 60,7% 54,3% 0,0% 6,7% 0,0%

Engineering Limit 80% 70% 70% 70% 80% 80% 80% 80% 80%

PMC-TMU PMC-NI PDC-NI PMC-M PMC-RB PMC-PC Maker PS-PQC ATM-PQC

6 2 Simulation One following with CN Paging Request = 1




63

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.

CPU PMC-RAB Load 65,9%


SMS

2

AO FACH to URA 0,5

AO PCH TO URA 0,4

AO URA TO FACH 0,5

Cells per LAC 1000

NodeB per RNC

500

Cells per RNC 1000

Cells per URA 200

Freq per Cell 2

CN Paging Request 1


at Committed Capacity Simulation Profile with URA PCH activated

0%

10%

20%

30%

40%

50%

60%

70%

80%

Node



Engineering Limit








64

6.2 Simulation One following with CN Paging Request 2



SMS

2

AO FACH to URA 0,5

AO PCH TO URA 0,4

AO URA TO FACH 0,5

Cells per LAC 1000

NodeB per RNC 500

Cells per RNC 1000

Cells per URA 200

Freq per Cell 2

CN Paging Request 2



Simulation with URA_PCH activated

0%

10%

20%

30%

40%

50%

60%

70%

80%

Node

P r o c e s s o r O c c u p a

n c y


Engineering Limit








65

g g g q

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)



SMS 2

AO FACH to URA 0,5

AO PCH TO URA 0,4

AO URA TO FACH 0,5

Cells per LAC 1000

NodeB per RNC

500

Cells per RNC 1000

Cells per URA 200

Freq per Cell 2

CN Paging Request 3



Simulation with URA_PCH Activated

0%

10%

20%

30%

40%

50%

60%

70%

80%

Node



Engineering Limit




6.3 Results concerning PMC-RAB CPU Load




66

g

CN PagingRequest

PMC-RAB PMC-TMU

URA-PCHactivated

URA-PCH off

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 perRNC=500, Cells per RNC=1000.

Paging impact point through a high increase of PMC-RAB CPU load vs CN Paging Requestvalue. PMC-TMU CPU load is not impacted by paging. URA-PCH activation with multichannel S-CCPCH allows a moderation of the increase.

This evaluation is made with RCT 29.56, which actually don’t take UTRAN Pagingrepetition in account.

CN Paging Request = # of paging requests coming from Core Network (including CNrepetitions) per attached sub per busy hour.

6.4 Simulation two with less aggressive call profile




67

gg p

10 DCPS, CP4 -- UA07.1.2 release versionand SMP5 TGEN Call profile. Must becompared with Slide chapter 6.2 wherePMC-RAB = 76,5%

CPU PMC-RAB Load 68%


SMS 2

ASU 0,1

Cells per LAC 500

NodeB per RNC 500

Cells per RNC 500

Cells per URA 500

Freq per Cell 1

CN Paging Request 3



SMP5 TGEN v11test Profile

0%

10%

20%

30%

40%

50%

60%

70%

80%

Node

P r o c e s s o r O c c u p a n

c y


Engineering Limit




6.5 Analyse RCT result vs Network Load and Release




68

6.5 Analyse RCT result vs Network Load and Release

Capacity vs release PMC-RAB with CNPAGING Request = 0

PMC-RAB with CNPAGING Request = 1

PMC-RAB with CNPAGING Request = 3

UA07.1 64,2% 68,3% 76,5%

UA07.1.2 58,2% 61,5% 68%

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.

Index Return




7. Guidelines for LAC splitting

• 7.1 Guideline for Split Action• 7.2 LA Dimensioning Assessment• 7.3 Figure for Paging Load on PCH Channels

7.1 Guideline for LAC Split action 1/3




70


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 mobilecrosses the boarder between two Las, a location updating is performed. The LAupdate has an effect on the signaling sub-channels load, S-CCPCH in the LA

border cells





71

• If you want to launch split LAC on the existing RNCs, it is mandatory to take carefor 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 TMUload is expected if border choice is optimal.

• When the ratio 1 RNC = 1 LAC is applied, there is equivalent number of cells/RNCand 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:

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

Number of PMC-RAB

7.1 Guideline for split action 3/3




72

• Concerning the previous formula

Paging Rate is the global value of paging success. It can be measure with the KPIPagingType1SuccessRate_Paging006_R (NPO view with extended – paging menu)

• Paging CPU cost is the processing time cost for paging. This processor estimation is 36 ms.

7.2 LA Dimensioning Assessment 1/2




73

• 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%, norestrictions 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 (around 300 cells) the rules can be modified either by doublingthe number of RNCs / LAC or by doubling the recommended URA/LA size ratio

7.2 LA Dimensioning Assessment 2/2




74

Check about PCCH load

These 2 counters concern the number of paging records sent on PCCH of the cell (forPS and CS domain)

812 / 813 VS.PagingRecordsSentOnPcchCs/Ps

Σ VS.PagingRecordsSentOnPcchCs/Ps at RNCx < 100 per cell per second for each RNC

3600* Cell numbers in the RNCx

The result value of this count refer to the number of paging record / sec on the previoustable.

In case of too high PCH load, objective is first to redesign LAC by splitting the high runner

LAs with high paging occupancy.

7.3 Figure for paging load on PCH channels evaluation




75

• Paging Success Rate must be higher than 90%. If lower values are monitoredUTRAN Paging repetition must be adjusted.

• 812 / 813 VS.PagingRecordsSentOnPcchCs/Ps

∑ 812 + ∑ 813

3600 * Cells Number< 100 * 90%

PCH Load evaluation

NoIf Mono S-CCPCHthen pass to bi S-

CCPCH

No

If pagingrepetition > 1

then reduces it

No

Split LAC

LAC OK

The LAC splitwill decreasethe PCH load

with cellsnumber ratio

Yes

Yes

Yes

Index Return




8. Impact for 2 RNCs per LAC

• 8.1 Overview• 8.2 Dimensioning Method Overall Precheck• 8.3 Radio Occupancy

8.1 Overview




77

8 O e e

Paging Rate




78

• 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 signalingoverload is supported.

• RANAP paging request may be trashed only when RNC is reacting to overloadcondition.

• For a given call profile, if 2 RNC are equal to one LA, the maximum arrival pagingrate is proportional to the number of paging located under the coverage of the 2RNCs.

• Combined CN paging/sec = max CN paging RNC1 + max CN paging RNC2 per sec

CN Paging Rate VS Paging Record Rate




79

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 PagingRNC2 per sec)

These combined paging rates are used for estimate

• Radio Occupancy (PCCH Occupancy)

• PMC RAB CPU Load

8.2 Dimensioning Method Overall Prechecks 1/3




80

1. Check that each RNC are not already with high PCCH load

• Counters :

• 812 / 813 VS.PagingRecordsSentOnPcchCs/Ps

Σ VS.PagingRecordsSentOnPcchCs/Ps at RNCx < 100 per cell per seconds for each RNC


• 809 VS.PagingDelayedRecords

VS. PagingDelayedRecords at RNCx < 0.03 per cell per second or less to be adjusted


Prechecks 2/3




81

2. Check that the two RNCs are not in CPU overload before LAC merged

Counter: 20202 VS.ApCpuUtilizationAvg

• 810.4 VS.UnhandledPagingRequestsCs_OverloadControls

• 811.4 VS_UnhandledPagingRequestsPs_OverloadControls

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

And all PSFP CPU

70% 70% 70%

Prechecks 3/3




82

3. For the two RNCs check the Configuration. Methodology done for similarconfiguration as follow.

10 DCPS or 10 PSFP

Configuration bi-S-CCPCH

Paging Repetition = 2 (including the flesh one)

8.3 Radio Occupancy Computation of the paging record rate




83

• Counters:

• 812 / 813 VS.PagingRecordsSentOnPcchCs/Ps (RNC, Hourly)

Paging record rate RNCx = Σ VS.PagingRecordsSentOnPcchCs/Ps at RNCx Per cell


Paging record rate (record/s) = Paging record rate RNC1 + Paging record rate RNC2

per cell

Radio Occupancy




84

• Decision Tree:

Note: 80% is a proposed engineering margin for the average value

100% is a proposed engineering margin for the max value

PMC RAB CPU LOAD




85

• Occupancy estimation:

BH CPU BH Paging

Paging CPU cost abacus

ReportGeneration RNC1

Report

Generation

RNC2

PMC RAB CPULoad Max RNC1

PMC RAB CPULoad Max RNC2

+CPU Load Paging

Of RNC1

+CPU Load Paging

Of RNC2

> Threshold

Inputs:

CPU Counters

Input:

•RNC Configuration

•Cells Number

•Paging Record Rate RNCx

PMC RAB CPU LOAD




86

• Dimensioning Method

PMC RAB CPU Load estimation

RAB Max CPULoad

RNC1 + RNC2 paging Contribution CPUcost

RNC1 + RNC2 paging Contribution CPU

cost

Compare to CPU threshold Max

PSFP 70% and DCPS 80%

Paging and CPU Load Monitoring 1/2




87

• The maximum PMC RAB CPU load is determined with the counter

20202: VS.ApCpuUtilizationAvg

• With a configuration with 10 DCPS and nbPagingRepetition = 2 theabacus is as follow:

Paging and CPU Load Monitoring 2/2




88

Index Return




89

rnc paging engineering guidelines ua8.1[1]

Documents