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
Top Related