HUAWEI TECHNOLOGIES CO., LTD.

HUAWEI TECHNOLOGIES CO., LTD.

www.huawei.com

PAGING SOLUTIONS

25 NOVEMBER 2012

PAGING

• To page a UE, the CN sends a PAGING message to the RNC. Then, the RNC sends a PAGING TYPE 1

message or a PAGING TYPE 2 message to the UE according to the status of the UE.

• PAGING TYPE 1 : If the paged UE is in idle mode, CELL_PCH state or

URA_PCH state, the RNC shall send a PAGING TYPE 1 message on the

PCH to the cell in the paged area.

• PAGING TYPE 2 : If the UE is in CELL_FACH or CELL_DCH state, the

RNC shall send a PAGING TYPE 2 message to the UE on the DCCH.

• In addition, the UTRAN can send a PAGING TYPE 1 message to a UE in idle mode, CELL_PCH state or URA_PCH state for system

information update. Also, the UTRAN can send a PAGING TYPE 1 message to a UE in CELL_PCH or URA_PCH state for UE state transition to

support data transmission. If the paged UE is in idle mode, it will send a RRC CONNECTION REQUEST message to the RNC after receiving a

PAGING TYPE 1 message. If the UE is in CELL_PCH or URA_PCH state, it will send a CELL UPDATE message with the cell update cause of

"paging response" to the RNC after it receives a PAGING TYPE 1 message

PAGING

AUH RNC - Paging Distribution

• As can be observed from the plot below, the PS Paging is far more in number than the CS Paging attempts. The dip in PS Paging attempts is due to LAC split on RNC 330-332 and site migration in RNC 331

Paging Congestion KPIs

1) Paging Success Rate (RNC) =

([VS.UTRAN.SuccPage1]/[VS.UTRAN.Paging1.Att])*{100}

2) IU Paging Congestion Ratio (RNC)=

(VS.RANAP.CsPaging.Loss+ VS.RANAP.PsPaging.Loss)/(VS.RANAP.CsPaging.Att+

VS.RANAP.PsPaging.Att)] x 100%

3) lU Paging Congestion Ratio (Cell) =

(VS.RRC.Paging1.Loss.PCHCong.Cell/VS.UTRAN.AttPaging1) x100%

4) PCH Utilization Ratio (Cell) =

(([VS.MAC.CRNCIubBytes.PS.CCH.TX])/(([VS.CRNC.IUB.PCH.Bandwidth])*{3600}))*{100}

Following slides offer a description of the above counters

Paging Success Rate (RNC Level)

Paging Success Rate (RNC)

• The Paging Success Rate is stable since last month but there has been a decrease of about 2% if compared with earlier period.

IU Paging Congestion (RNC Level)

VS.RANAP.Cs/PS Paging.Loss (RNC Counter)

Description

• When the RNC receives from the CN a PAGING message, the measurement of this counter is triggered

if the RNC does not send a Paging type 1 or Paging type 2 message. The reason why the RNC does not

send a Paging type 1 or Paging type 2 message might be Iu flow control, or high CPU usage. If the

RNC does not respond to a paging message that is consecutively retransmitted, the RNC counts it only

once

VS.RANAP.Cs/PS Paging.Loss (RNC Counter)

IuB Paging Congestion was always high on RNC 1416 due to huge traffic. This was

reduced after RNC re-homing activity which helped balance the paging load to the new

RNC. RNC 6501 had little congestion which was resolved after RAN 13 upgrade and

SPU/GoU Board additions. Currently – Zero Paging losses!

IU Paging Congestion (CELL)

VS.RRC.Paging1.Loss.PCHCong.Cell (Cell

Counter)

• This measurement item takes statistics of the number of losses of PAGING

TYPE 1 message due to PCH congestion in a cell

• Measurement point

The measurement is triggered when the RNC discards a paging message due to

PCH congestion.

VS.RRC.Paging1.Loss.PCHCong.Cell (Cell Counter)

The Cell level PCH congestion is based on the counter shown below which provides the

number of losses of PAGING TYPE 1 message due to PCH congestion in a cell. These

numbers had always been high for All RNCs. However, after LAC Splits on RNC 330-

332 (16th-19th October, 2012 and Site Migration in RNC 331 (19th Oct, 2012) , this

value has greatly reduced.

Paging Congestion Ratio

The reduction in Paging Congestion ratio is largely due to LAC Splits on RNC 330, 331

and 332

PCH Utilization (CELL Level Counters)

Paging Load (Cell level Counters)

• Paging load calculation is based on the number of bytes sent on PCH channel Iub interface with indicator

(VS.CRNCIubBytesPCH.Tx ), and paging bandwidth on the Iub interface using indicator

(VS.CRNC.IUB.PCH.Bandwidth).

• VS.CRNCIubBytesPCH.Tx

– This measurement item provides the number of DL MAC PDU bytes received by the CRNC on the PCH FP over the

Iub interface. These bytes include paging data transport blocks and paging Indication (PI) data.

• VS.CRNC.IUB.PCH.Bandwidth

– The measurement items provide the channel bandwidth on the Iub interface in a cell

• Following slides will show PAGING LOAD on Hourly CELL LEVEL

Paging Load – AUH6501

Paging Load – AUH1416

Paging Load – AAN5002

Paging Load (Cell level Counters)

• Before Cell PCH was implemented, PAGING Load could be considered per

LAC/RAC

• After Cell PCH implementation, since paging is done on Cell Level instead of

LAC/RAC level, hence, we get the paging load or PCH load on cell level. Every

cell’s PCH load capacity will be different from other cell.

• After Cell PCH, we cannot really know the contribution made to PCH load,

whether it is by Cell PCH Paging (where UE is paged on cell level) or

LAC/RAC paging (where all cells in the LAC/RAC are paged). So PAGING

LOAD calculated by IUB PCH Bandwidth counters don’t reflect the correct

PAGING LOAD

Observation

The following is observed after checking the stats on

AUH RNCs

• RANAP Paging losses are ZERO

• Cell PCH Congestion exists on 3 RNCs but

much less in number now

• Paging Load/Utilization can now only be calculated

on per cell basis. A page on a cell could be either

for a UE in IDLE Mode or it could be for a UE in

PCH mode. For IDLE mode, the paging is done on

whole LAC/RAC while for UE in PCH mode,

paging is done on cell level.

WHAT do WE need to SOLVE?

• We need to solve the Cell PCH congestion which is being

denoted by the counter VS.RRC.Paging1.Loss.PCHCong.Cell

Can we do LAC/RAC splits?

• There are currently 4 LACs in RNC 330 and 1 RAC

• PS Paging is done on RAI which is a combination of LAC-RAC

• Hence, with 4 LACs, we have 4 RAIs – (In RNC 330, we have LAC 3301, 3302, 3303 &

3304 while RAC is 3

• So RAIs will be 3301-3 and 3302-3, 3303-3, 3304-3

• So logically, we have 4 LACs and 4 RACs.

• If we think about defining another RAC, we need to see where exactly do we need the

SPLIT

• After checking cell level stats we see that following cells in RNC 6501 are contributing to

PCH Congestion

LAC/RAC Dimensioning

LAC/RAC Dimensioning

NE Name Cell Name CellID

AUH6501 AUH54445:AUH:Marina Mall 54445

AUH6501 AUH20188:AUH:Al Hosn Area Cornish West Urban Park H.Q 20188

AUH6501 AUH20187:AUH:Al Hosn Area Cornish West Urban Park H.Q 20187

AUH6501 AUH20206:AUH:Al Khalidiya Area Khalidiya Finance Department 20206

AUH6501 AUH54542:AUH:Al-Bateen Tower - C1 54542

AUH6501 AUH20137:AUH:Near Capital Garden Khalifa Street 20137

AUH6501 AUH45091:AUH:Khalidiya Palace Rotana Hotel & Residence Block C 45091

AUH6501 AUH20909:AUH:Al Moroor Area WOMENS POLICE TRAINING INST 20909

AUH6501 AUH20134:AUH:Near Capital Garden Khalifa Street 20134

• Cells given below are main contributors of PCH Congestion

• Even if additional RAC is defined, it will come under 1 single LAC and won’t be much useful

for other cells defined under other LACs

Summary & Potential Solution

• The Paging Congestion caused by PCH is very low in percentage and

has reduced quite much in number after the recent actions on 19th

October, 2012 (LAC Splits)

• Compared to DXB and NE, Abu Dhabi has fewer PCH Congestion

numbers

• To reduce the remnant cell PCH Congestion, we need to enable

ENHANCED FAST DORMANCY – Enabling EFD has resulted in

relieving PCH Congestion on various Networks.

Thank you