Вы находитесь на странице: 1из 79

WCDMA RAN Optimisation

Common Channels monitoring


Asli Tokgoz GS NPO Radio
Nov 2016

1 © Nokia 2016 Nokia Internal Use


Introduction

• This material Covers Uplink and Downlink common channel monitoring issues , some
optimization aspects are also discussed .
• A comprehensive list of impacting parameters and optimization is in wiki here

4 © Nokia 2016 Nokia Internal Use


Content

Common Channel Load Monitoring


Uplink Channel Monitoring
RAN1913 HS-FACH UL
RAN 2902 RACH capacity increase
Downlink Channel Monitoring
SCCPCH
Paging
FACH
RAN1637 HS-FACH DL
5 © Nokia 2016
CCH Load - Introduction

• Common Channel load monitoring includes different aspects of :


- RACH
- Paging
- FACH
- SCCPCH

• From efficient traffic scheduling point of view the CCH load of each cell needs to be measured,
for example FACH-c, FACH-u and PCH transport channels can be multiplexed into same
SCCPCH which causes some prioritization of the RLC SDUs
• This prioritization might lead to deletion of other transport channel’s RLC SDUs therefore it is
important to measure the loads of the individual transport channels

6 © Nokia 2016 Nokia Internal Use


Content

Common Channel Load Monitoring


Uplink Channel Monitoring
RAN1913 HS-FACH UL
RAN 2902 RACH capacity increase
Downlink Channel Monitoring
SCCPCH
Paging
FACH
RAN1637 HS-FACH DL
7 © Nokia 2016
Uplink Channel Mapping

Logical Transport Physical


Channels Channels Channels • A single RACH transport channel is used
for both, control plane signaling and user
CCCH RACH PRACH plane data.
• RACH is mapped to PRACH onto PRACH
physical channel which makes use of
contention based access procedure i.e.
DCCH there is probability that collisions occur
E-DPDCH when multiple UE attempt to make use of
E-DPCCH the PRACH.
HS-DPCCH • PRACH is separated in the preamble part
EDCH and a message part. Preambles are used
to gain access to PRACH message time
DPDCH
DTCH DCH
slot and to ensure that the message is
DPCCH transmitted with sufficient uplink power.

8 © Nokia 2016 Nokia Internal Use


Measuring the PRACH Channel

• Random access channel load (RACH) can be measured at the RACH preamble and transport channel levels.
• WBTS measures the number of acknowledged (ACK/NACK) PRACH preambles per 20 ms RACH frame, averages
over RRI period and sends the measurement to RNC. NOTE: the averaged value is rounded to closest integer,
thus low PRACH load is not measured accurately
• The maximum preamble capacity is 60 preambles(4 preamble signatures * 15 slots) per RACH frame of 20 ms .
- If RAN2902 RACH Capacity Increase ( WCDMA16) is used preamble signatures are increased from 4 to 16 ( more later)
• RNC_978b Average PRACH Message Load kpi indicates the preamble load per RACH frame as absolute number of
messages .
- The RACH preamble load and transport channel load are inter-connected.
- Every positively acknowledged preamble will correspond one sent RACH message (RACH-c of RACH-u).
- The BTS can acknowledge in one second 60 * 1/20ms = 3000 preambles/sec. (with RAN2902 up to 12 000
preambles/sec)
- BTS can decode at maximum RACH_capacity messages per 10 ms frame = 200 RACH messages/sec (with
RACH_capacity = 2, default)

9 © Nokia 2016 Nokia Internal Use


Measuring the PRACH Channel

The limiting factor is BTS PRACH message decoding capacity. We can only measure the BTS
acknowledged preamble load, but we can estimate the PRACH message decoding load based in this
• Example if RNC_978b=2.5 and RACH_capacity=2 per 10 ms ; number of signatures is 4
Preamble Load in percentage is
= 100* (RNC_978b*/60)
= 100*2.5/60=4.16%
Load on BTS PRACH message decoding capacity in percentage is
= 100 *RNC_978b*50/200
= 62.5 %
• This means when the Preamble load measured by RNC_978b is around 4.16%, load on the BTS
PRACH message decoding capacity is already at 62.5 % level

10 © Nokia 2016 Nokia Internal Use


Measuring the PRACH Preamble capacity

The number of acknowledged PRACH preambles per 20ms frame during averaged over the RRI
period can be calculated based on the counters below
• M1000C176 SUM_RACH_ACK_PREAMBLES
• M1000C177 DENOM_RACH_ACK_PREAMBLES

RNC_978b Average PRACH Message Load can be used to measure PRACH message load
• The maximum preamble capacity is 60 preambles per RACH frame of 20 ms
SUM_RACH_ACK_PREAMBLES
RNC_ 978b_AveragePRACHMessag eLoad 
DENOM_RACH _ACK_PREAMBLES

11 © Nokia 2016 Nokia Internal Use


Measuring the PRACH Preamble capacity

• The RACH message decoding blocking 30 %

can be estimated with Erlang B equation RACH message decoding blocking probability
(although this is not 100% correct for 25 %
slotted system like RACH and to system
with re-transmission).

20 %
Blocking will cause the BTS to send a

RACH message blocking


negative acknowledgement and UE to
apply N300 and T300 for re-transmission. 15 % P(Capacity=2)

A load of 1 preamble per 20 ms (about 2% P(Capacity=3)

preamble blocking according to the Erlang 10 %


P(Capacity=4)

table ) = 25% total BTS decoding load)


5%
RNC_978b =1 can be used as
triggering point for RACH_capacity
0%
parameter increase.

0.01

0.36
0.47
0.59

0.94
1.06

1.41
1.52

1.87
1.99
2.11

2.34
2.46
2.57

2.92
3.04

3.39
0.12
0.24

0.71
0.82

1.17
1.29

1.64
1.76

2.22

2.69
2.81

3.16
3.27
Number of RACH preamles per frame (RNC_978b)

12 © Nokia 2016 Nokia Internal Use


RACH channel throughput

• Both data (RACH-u) and signaling data (RACH-c) throughput can be measured
• The counters are incremented when the MAC-c sends to the RRM an internal message (every 2
seconds, including 4 samples) with the common channel information
• RACH throughput, does not have an official KPU in jump but it can be calculated as below :
M 1000C60 AVE_RACH_THROUGHPUT
RACH _ throughput 
M 1000C61 RACH_DENOM_ 3

• RNC_2032a RACH-u Load Ratio provides RACH transport channel User Plane data throughput
M 1000C62 AVE_RACH_DATA_THROU GHPUT
RACH-u throuhgput 
M 1000C63 RACH_DENOM_ 4

• RNC_2033a RACH-c Load Ratio provides RACH transport channel Control Plane data
throughput M 1000C60 AVE_RACH_THROUGHPUT M 1000C62 AVE_RACH_DATA_THROU GHPUT
RACH-c throughput  
M 1000C61 RACH_DENOM_ 3 M 1000C63 RACH_DENOM_ 4

13 © Nokia 2016 Nokia Internal Use


Impact of RACHCapacity parameter

The Random Access Channel capacity depends on the RACHCapacity parameter


• The RACHCapacity defines the HW capacity reserved for a RACH transport channel in the BTS
• RACH Capacity is indicated as the number of decoded RACH messages in a 10 ms radio frame
• Defines also the number of used PRACH preamble signatures used
• It is recommeded to use parameter value 4 if functionality RRC connection setup on common
channels and/or HS Cell_FACH feature are configured to be used in this cell. ( EFS 1913)
• Range 1,2,3,4 (messages) and default = 2

For example if the RACHCapacity = 2 (def) then it means that the BTS can decode 2 RACH
messages in every 10ms radio frame and therefore the decoding capacity is 2 RACH PDUs *
45B/10ms = 9kBps = 72kbps i.e. 2 RACH TBs * 360bit/10ms = 72kbps= TP _max

14 © Nokia 2016 Nokia Internal Use


Impact of RACHCapacity parameter cont…

Iub capacity is according to the table below, depending on the RACHCapacity parameter (1,2,3,4)

• Note the capacity impact on Iub as the capacity above is required as per each cell so there is a
clear impact on how many e.g. voice users 1*E1 can support in case capacity for RACH is
increased

15 © Nokia 2016 Nokia Internal Use


Example: RACH-c and RACH-u loading

• Examples of RACH load (TP / TP_max) in high traffic cells (RACH_capacity = 2, TP =RNC_16c
Average RACH Throughput, TP _max =72kbps)
• In extreme load the RACH throughput drops even though ack preample load (RNC_978 )is high

16 © Nokia 2016 Nokia Internal Use


PRACH Channel load optimization

• The PRACH load is dependent upon the number of UE making use of the RACH transport
channel. The RACH transport channel may be used for the transfer of either user plane or
control plane information.
• The PRACH load can be reduced by:
• Increasing the RACHCapacity (WCEL) parameter
• Evaluate whether or not there are large quantities of signaling generated by cell, URA, location area or
routing area updates. If so, consider adjusting the area boundaries
• Evaluate whether or not there is excessive user plane data transfer within CELL_FACH. If so, consider
reducing the RLC buffer thresholds that trigger the transition to CELL_DCH
• Upgrading the Node B configuration in terms of an additional carrier
• RAN1913 HS-RACH feature activation
• RAN2902 RACH capacity increase feature activation

17 © Nokia 2016 Nokia Internal Use


Content

Common Channel Load Monitoring


Uplink Channel Monitoring
RAN1913 HS-FACH UL
RAN 2902 RACH capacity increase
Downlink Channel Monitoring
SCCPCH
Paging
FACH
RAN1637 HS-FACH DL
18 © Nokia 2016
Impact of RAN1637/RAN1913
RAN1637
RAN1637 RAN1913
Not activated
Activated

HSPA only on HSPA also on


dedicated channels common channels

Common channels

Common channels
Dedicated channels Common channels
Dedicated channels

Data transmission
Cell_PCH to Transmission on HSPA Cell_PCH to Transmission on HSPA
Cell_DCH in Cell_DCH Cell_FACH in Cell_FACH

19 © Nokia 2016 Nokia Internal Use


RAN 1913 HS-RACH reduces need for RACH procedure ( RU40)
Rel99 RACH vs. E-DCH procedure
The usage of the PRACH changes , uplink channels are mapped for HS; Cell
_FACH and PRACH channels are not used after first access
AICH AICH AICH Common E-DCH resource assigned
response response response UE specific E-RNTI on E-AGCH

D
L AICH 10 ms AICH 10 ms
D AICH E-AGCH
L
U
L U
PRACH PRACH PRACH PRACH L PRACH E-DPDCH E-DPDCH E-DPDCH
E-DPCCH E-DPCCH E-DPCCH
Collision Collision
probability Collision Common E-DCH
probability
probability resources exclusively
used by this UE

Rel99 UL RACH procedure E-DCH procedure (RAN1913)


RACH procedure performed before every data block RACH procedure performed once for data block sequence
Possibility of collision during transmission Possibility of collision only in initial transmissions phase

20 © Nokia 2016 Nokia Internal Use


RAN1913 Channel mapping in High Speed Cell_FACH
Requires 3GPP Rel-8

CCCH DCCH DTCH

Logical channels

Transport channels RACH E-DCH

3GPP Rel8
Physical channels

PRACH E-DPDCH

21 © Nokia 2016 Nokia Internal Use


Simulation Results for HS-FACH features –RACH and S-CCPCH occupation with
HS-FACH functionality
Unfortunately there is not field experience with the impact of the feature

• Same PRACH utilization with HS-FACH


as in non-HS-FACH case with high
Traffic Volume TVM setting. Other
benefits of HS-FACH are more visible in
simulations

• We use the same KPIs to monitor RACH capacity as mentioned before when the HS-FACH
features are active , so there is no change there .
• Additionally , Counter M5000C423 - DENIED COMMON EDCH RESOURCES , can be used
until WCDMA16 after that; M5000C423 is replaced by M5000C462
UNSUCC_HS_RACH_PREAMBLE .

22 © Nokia 2016 Nokia Internal Use


More on RAN1913

• There are several parameters impacting the feature functionality , Please have a look at BDNE
feature materials
• Please have a look at here in Radio Wiki for lab and Five results :
https://workspaces-
emea.int.nokia.com/sites/nporadio/Radio%20Wiki/WCDMA%20NPO%20feature%20materials%20and%20references.aspx

23 © Nokia 2016 Nokia Internal Use


Content

Common Channel Load Monitoring


Uplink Channel Monitoring
RAN1913 HS-FACH UL
RAN 2902 RACH capacity increase
Downlink Channel Monitoring
SCCPCH
Paging
FACH
RAN1637 HS-FACH DL
24 © Nokia 2016
RAN2902 RACH Capacity Increase ( WCDMA 16)

• Earlier, without this feature, it was possible to allocate 1..4 preamble signatures for RACH, out of which 1
was available for HS RACH (Provided, RAN1913 is activated).
• With the increasing number of Cell FACH state UEs, (aided by more HS FACH/RACH capable terminals)
more signatures and detection capability at BTS are necessary to avoid collisions and reduce interference
which is caused due to re-transmissions and failed RACH attempts.
• Thus, the feature introduces additional signature preambles for both R99 and HS-RACH. This feature could
help especially when the penetration of Enhanced Cell FACH capable UEs increases and Cell FACH state is
used more.
• RACH or HS-RACH peak throughputs are not increased by this feature, but the average utilization of RACH /
HS-RACH can be expected to be improved. Although the amount of RACH signatures is increased, the
amount of RACH messages (=RACH throughput = RACH capacity) is kept the same, which is max 4
messages per cell per Rel’99 radio frame. Therefore the amount of UEs that can in parallel access the
network will not increase.

25 © Nokia 2016 Nokia Internal Use


RAN2902 RACH Capacity Increase ( WCDMA 16)
Impact of RAN2902 Could help with :
• Increased network accessibility but increased the RACH • Highly loaded cells
load as well • Cells with bursty traffic (e.g. airport)
• Decreased uplink interferences due to less RACH cycles • HS RACH capable cells
(fewer collisions in high load conditions)
• Increased end-user experience by faster network access
• With more signatures, more UEs are to be access the
network.

Drawback : For BTS, scanning the RACH channels to check if


there are preambles sent it requires certain amount of processor
work. This processing amount depends on cell Rx-diversity,
number of preamble signatures to be scanned and on the cell
range. Increasing the cell range also increases the possible
delay spread of the received preambles. With RAN2902, legacy
BTS dimensioning principles are applied. That means, if number
of signatures is increased, the cell range may need to be
reduced or additional CCH license keys are required.

Please have a look at the BB dimensioning aspects if


this feature is active. This can be found in BDNE BB
dimensioning guidelines .

26 © Nokia 2016 Nokia Internal Use


RAN2902: Parameters
AllowedPreambleSignatures (WCEL) :old parameter is deleted starting WCDMA16
RACHPreambleSignatures (WCEL) : The parameter specifies how many preamble signatures are used in a
cell.(NEW)
- Without RAN2902 , this parameter is also used with maximum allowed 4 signatures per WCEL.
- With RAN2902 RACH capacity increase feature, up to 16 preamble signatures can be used.

BTSRACHCapaIncCapability (WBTS) This parameter shows BTS's capability for RACH capacity increase. When BTS's
capability for RACH capacity increase is enabled, more than four RACH/HS-RACH Preamble Signatures can be configured to
the BTS. This is set by system , it can not be modified , based on the feature (NEW)
RAN1913 RAN1913
 Number of RACH Signatures per cell is increased from 4 RACHPreambleSignatures
not activated activated
#HS-
to 16 with RAN2902 setting #RACH #RACH
RACH
signatures signatures
 Less collisions occurs especially in signatures
highly loaded cells (where more 1 RACH signature 1 1 1
collisions are expected) 2 RACH signatures 2 2 1
 Possibility for different RACH and 3 RACH signatures 3 3 1
HS-RACH signatures combinations 4 RACH signatures 4 3 1
 Configurations 3+3, 4+4, 4+8 and
3+3 RACH and HS RACH
4+12 not allowed if RAN1913 signatures
N/A 3 3
is disabled 8 RACH signatures 8 7 1
4+4 RACH and HS RACH
N/A 4 4
signatures

27 © Nokia 2016 Nokia Internal Use 4+8 RACH and HS RACH


N/A 4 8
signatures
RAN2902 RACH Capacity Increase: Monitoring aspects

Alarm 7775 INCONSISTENCY IN WCEL CONFIGURATION PARAMETERS indicate problems with RAN2902 feature.
Condition that triggers alarm:
• BTS is incapable to support RACH Capacity Increase feature but RNC has the configuration to enable it (“INCAPA”)
• The RACH signature number and cell range configured by operator can't be supported in the BTS local cell. (“PSIG_FAIL” )
COUNTERS and KPIS , same KPIs mentioned before for monitoring RACH load are still valid after RAN 2902 , below here
are the additional KPIs and counters;
• M5000C465..70 R99_RACH_UTIL_CLASS_1..6
• RNC_5560a HS RACH Preambles Utilization Ratio
• M5000C471..76 HS_RACH_UTIL_CLASS_1..6
• RNC_5561a HS RACH Decode Success Ratio • M5000C455 CONF_R99_RACH_SIGNATURES

• RNC_5558a R99 RACH Preambles Utilization Ratio • M5000C456 SUCC_R99_RACH_PREAMBLE


• M5000C457 UNSUCC_R99_RACH_PREAMBLE
• RNC_5559a R99 RACH Decode Success Ratio
• M5000C458 SUCC_DECODED_R99_RACH
• M5000C459 UNSUCC_DECODED_R99_RACH
• M5000C460 CONF_HS_RACH_SIGNATURES
• M5000C461 SUCC_HS_RACH_PREAMBLE
• M5000C462 UNSUCC_HS_RACH_PREAMBLE
• M5000C463 SUCC_DECODED_HS_RACH
• M5000C464 UNSUCC_DECODED_HS_RACH
28 © Nokia 2016 Nokia Internal Use
RAN2902 trial result
• Signatures were increased from 4 to 8 in a small cluster in the NW . This has reduced the preamble signature utilization.
• Other RACH related performance did not change .

29 © Nokia 2016 Nokia Internal Use


Content

Common Channel Load Monitoring


Uplink Channel Monitoring
RAN1913 HS-FACH UL
RAN 2902 RACH capacity increase
Downlink Channel Monitoring
SCCPCH
Paging
FACH
RAN1637 HS-FACH DL
30 © Nokia 2016
Content

Common Channel Load Monitoring


Uplink Channel Monitoring
RAN1913 HS-FACH UL
RAN 2902 RACH capacity increase
Downlink Channel Monitoring
SCCPCH
Paging
FACH
RAN1637 HS-FACH DL
31 © Nokia 2016
Downlink Channel Mapping for S-CCPCH
Logical Channels Transport Channels Physical
Channels

P-CPICH
BCC BCH P-CCPCH
H
• Two main use cases S-CCPCH
PCC PCH
• PCH H PICH
• FACH AICH
CCC
P/S-SCH
H FACH
E-HICH
CTCH
HS-DSCH HS-PDSCH*
DCCH
HS-SCCH

DPDCH
DTCH DCH
DPCCH

32 © Nokia 2016 Nokia Internal Use


Common Channel Load - SCCPCH

SCCPCH load is used by PS in downlink channel type selection algorithm


• Average SCCPCH load is given as percentage value (defined as ratio between the SCCPCH transmission power and the
CPICH power)
• incremented when the MAC-c sends to the RRM an internal message (every 20 seconds, including 0.5s sampling period)
with the common channel information
• SCCPCH load is one criteria for switching from common channel (FACH) to dedicated channel

M 1000C 64 AVE_SCCPCH_INC_PCH_LOAD
RNC_ 979a_SCCPCHAverageLoad  %
M 1000C 65 SCCPCH_LOAD_DENOM_ 0

• If a single S-CCPCH is configured then this KPI is applicable to that channel


• If two S-CCPCH are configured then this KPI is applicable to the S-CCPCH encapsulating the PCH transport channel( more
on SCCPCH configurations later …)
Both counters are incremented every CCH Load Measurement Period
• Num is incremented by the value received in the measurement
• Denom is incremented by the number of measurements

33 © Nokia 2016 Nokia Internal Use


Content

Common Channel Load Monitoring


Uplink Channel Monitoring
RAN1913 HS-FACH UL
RAN 2902 RACH capacity increase
Downlink Channel Monitoring
SCCPCH
Paging
FACH
RAN1637 HS-FACH DL
34 © Nokia 2016
Paging Types and PCH Load

When the network needs to contact a certain user a Paging procedure will take place.
• The paging method used depends on the UE RRC state:
- IDLE: Paging Type 1 - over PCH - LA/RA level - CN originated
- Cell/URA-PCH: Paging Type 1 - over PCH - Cell/URA level - CN/RNC origin.
- Cell-DCH/Cell-FACH: Paging Type 2 / over SRB / Cell level

Only Paging
Type 1 affects
the PCH Load

35 © Nokia 2016 Nokia Internal Use


Paging Channel capacity
• NSN RAN, until RU10 • This capacity could get exhausted due to
(RN4.0) sw release, a combination of reasons (high traffic,
provides an 8 kbps PCH LAC oversize,…). In case of too high
transport channel on the Paging Load a considerable percentage
S-CCPCH. of paging messages could get lost
causing a bad user experience (‘non-
• The PCH TBS is 80 bits reachability’ of UEs due to missing
allowing to carry a single pages).
paging record per TTI
(10ms)  100 paging • It should be taken into account that S-
records per second  a CCPCH can be shared with the FACH-c
single cell can thus page and FACH-u but PCH always has priority.
maximum 100 UEs per This means that a high Paging load has
second an impact upon FACH capacity when
single S-CCPCH is configured.

Max PCH Throughput 8 kbps  max 100 Pages/s per cell

36 © Nokia 2016 Nokia Internal Use


Paging with S-CCPCH Configuration 1

• This configuration limits the PCH bit rate to 8 kbps


• The PCH is multiplexed with the FACH-u and FACH-c
• The PCH always has priority
• SF64 is required to transfer the FACH-u and FACH-c bit rates

Logical channel DTCH DCCH CCCH BCCH PCCH

Transport channel FACH-u FACH-c PCH

Physical channel SCCPCH 1


SF 64
37 © Nokia 2016 Nokia Internal Use
Paging with S-CCPCH Configuration 2

• PCH24kbpsEnabled is Logical channel DTCH DCCH CCCH BCCH PCCH


configured to enabled
with this configuration

• Increases the PCH bit


rate to 24 kbps
Transport channel FACH-u FACH-c PCH
• The PCH is allocated its
own S-CCPCH

• SF128 is allocated to
the PCH to support the
increased bit rate Physical channel SCCPCH SCCPCH
SF 164 SF 2128

38 © Nokia 2016 Nokia Internal Use


24kbps Paging Channel

• Earlier versions support a PCH bitrate of 8 Kbps , in this case transport block size of 80 bits & 10
ms TTI . 8 kbps PCH bitrate limits the capacity of paging messages to a single paging record, i.e.
single paging record can be broadcasted per 10 ms TTI
• Starting with RU20 , PCH bitrates of 8 and 24 kbps are supported .
- Transport block size increased to be 240 bits & 10 ms TTI
- 24kbps paging channel requires activation of second SCCPCH channel

Paging Type 1 message

maxPage = 8
3GPP allows up to 8
paging records per
paging message

39 © Nokia 2016 Nokia Internal Use


24 paging Channel - Impact to Code and power capacity
Cch,256,14

• Channelisation code for 24 kbps PCH uses a larger


E-AGCH
section of the code tree
Cch,128,6
• HSDPA cannot use 15 HS-PDSCH codes when HSUPA Cch,128,5

2 ms TTI is enabled with 24 kbps PCH


E-HICH & E-RGCH
• The transmit power of the S-CCPCH is defined using the
parameters: HS-SCCH
Cch,16,
0 Cch,128,4
• PtxSCCPCH1 (PCH/FACH or only FACH)
• PtxSCCPCH2 (Standalone PCH) S-CCPCH 2

• PtxSCCPCH3 (S-CCPCH for SAB) PICH


Cch,64,1
• PtxSCCPCH2SF128 (Standalone PCH SF128 / AICH
24kbps)
P-CCPCH
• The PtxSCCPCH2SF128 parameter defines the transmit Cch,256,3

power of the S-CCPCH used to transfer the 24 kbps PCH Cch,256,2


CPICH
S-CCPCH 1

• All parameters define the transmit power of the data bits Cch,256,1

(rather than the transmit power of the TFCI and Pilot bits)
Cch,256,0

40 © Nokia 2016 Nokia Internal Use


RNC KPIs for Paging attempts

• Below counters can be used to monitor the number of paging messages per cell ( no official
KPI):
 M 1006 C 25 _ PAGING_TYPE_1_ATT_CN_ORIG 
 
Paging Attempts per Cell    M 1006 C 25 PAGING_TYPE_1_ATT_RNC_ORIG 
  M 1006 C 27 _ PAGING_TYPE_ 2 _ATT 
 

• In order to count only the amount of pages sent on PCH channel the following KPI can be used
(Paging Type 2 excluded) ( no official KPI):

 M 1006 C 25 _PAGING_TYPE_1_ATT_CN_ORIG 
Paging Type 1 Attempts per Cell   
  M 1006 C 26 _PAGING_TYPE_1_ATT_RNC_ORIG 

41 © Nokia 2016 Nokia Internal Use


RNC KPI for Paging Load ( NOT WIDELY USED ANYMORE)

RNC_18c Average PCH Throughput The AVE_PCH_THROUHGPUT counter, divided by the denominator,
gives Average PCH throughput
UPDATED: When the RNC/MAC-c sends an internal message with common channel information to the Radio
Resource Management in the RNC
MAC-c sends this message at 2-second intervals
Not suitable
if 24 kbps

bps
M 1000C 70 AVE PCH THROUGHPUT paging CH
Average PCH Throughput 
M 1000C 71 PCH THROUGHPUT DENOM 0 * 1000000

Taking into account that the PCH physical limit is 8kbps the Average PCH Throughput can be normalized to this
value providing PCH Load in percentage:

Average PCH Throughp ut bps 


Not suitable

RNC_ 2031a_PCH Load  100  % if 24 kbps


paging CH
8000

42 © Nokia 2016 Nokia Internal Use


Average PCH throughput daily distribution

• The average PCH Throughput PCH physical limit

approaches 7kbps several times per


day
• This can be assumed as a clear
symptom of PCH congestion during
the traffic peak hour.

RNC ≡ LAC

43 © Nokia 2016 Nokia Internal Use


Average PCH Load daily distribution( RNC_2031a)

• Average PCH Load equal to


80..90% at RNC≡LAC level
• In a such highly congested
situation a high rate of missing
pages is expected and a LAC
splitting needs to be planned

44 © Nokia 2016 Nokia Internal Use


VLR Paging SR (msc_511a Paging attempt success ratio, per LAC) vs
RNC_18c Average PCH Throughput ) congestion :
• The Paging success rate
starts to decrease when
PCH throughput exceeds
4-4.5kbps, that is a PCH
Load of 50-55%
approximately and is below
90% when PCH throughput
exceeds 6kbps

45 © Nokia 2016 Nokia Internal Use


VLR Paging SR vs RNC_18c Average PCH Throughput : no congestion

• Interesting to compare the


correlation shown by a nearly
unloaded RNC

46 © Nokia 2016 Nokia Internal Use


Received Page/s by CN vs PCH Load

• A quasi-linear relation exists up to


45% PCH load and starts to
become non-linear at 50%
meaning that CN needs to send M1003C36 – Received paging messages
more paging (i.e. re-paging) from CN (s)
because RAN is not able to
properly serve them.
• Threshold of 50% PCH Load
(RNC_2013a) confirmed as Rule
of Thumb to trigger PCH Load
optimization

47 © Nokia 2016 Nokia Internal Use


TS-RNC-SW-148 - PCH throughput increase – 24 kbps PCH

When 24 kbps CH is used throughput measured by below formula can not be used anymore. It’s because the counters are based
on measuring physical transport blocks in the Iub interface and those blocks are sent with same size even if there isn't paging
messages to fill in all the blocks.
In fact the best way to measure paging channel utilization is based on ( ref TS-RNC-SW-148)

 M 1006 C 25 _PAGING_TYPE_1_ATT_CN_ORIG 
Paging Type 1 Attempts per Cell   
  M 1006 C 26 _PAGING_TYPE_1_ATT_RNC_ORIG 

These counters tell the amount of paging messages successfully scheduled in the Iub interface
-8 kbps PCH can transfer about 100 paging messages per second,
-24 kbps channel capacity is about 400...500 messages per second (depends on paging type).
When the amount of paging messages exceeds 50% of the nominal capacity, its good time to start thinking about actions to
reduce paging channel load to avoid degradation in paging success rate.
• 50 msg/s for 8 kbps PCH  nominal capacity = 50*3600= 180 000 msg/h (M1006C25
PAGING_TYPE_1_ATT_CN_ORIG + M1006C26 PAGING_TYPE_1_ATT_RNC_ORIG) /180 000
• 250 msg/s for 24 kbps PCH  nominal capacity = 250*3600= 900 000 msg/h  (M1006C25
PAGING_TYPE_1_ATT_CN_ORIG + M1006C26 PAGING_TYPE_1_ATT_RNC_ORIG) /900 000

48 © Nokia 2016 Nokia Internal Use


Example: Upgrading paging channel from 8 kbps to 24 kbps PCH

Configuration changes
• 08.11.2010
- 24 kbps PCH, 2nd SCCPCH
• 09.11.2010
- Inactivity parameter changes (this is not releated to 24 kbps PCH changes)
Object Parameter Name Abbreviated Name Actual value new value
RNC Low utilization time to trigger of the MAC-d flow MACdflowutilTimetoTrigger 2 sec 0 sec *
RNC Window size of the MAC-d flow throughput measurement MACdflowthroughputAveWin 3 sec 2 sec
RNC Low throughput time to trigger of the E-DCH MAC-d flow EDCHMACdFlowThroughputTimetoTrigger 5 sec 1 sec
RNC Window size of E-DCH MAC-d flow throughput measurement EDCHMACdFlowThroughputAveWin 3 sec 2 sec
RNC Uplink traffic volume measurement low threshold TrafVolThresholdULLow 128 bytes 256 bytes
RNC UL/DL activation timer UL_DL_activation_timer 2 sec 1 sec
RNC Inactivity timer for uplink 8kbps DCH InactivityTimerUplinkDCH8 5 sec 2 sec
RNC Inactivity timer for uplink 16kbps DCH InactivityTimerUplinkDCH16 5 sec 2 sec

RNC Inactivity timer for uplink 32kbps DCH InactivityTimerUplinkDCH32 5 sec 2 sec

49 © Nokia 2016 Nokia Internal Use


Example: Upgrading paging channel from 8 kbps to 24 kbps PCH
PCH Loading ,
Number of sites per load level with 8 kbps and 24 kbps PCH, using number of paging messages per period, we can see the
number of sites with high levels of load decreased

=(PAGING_TYPE_1_ATT_CN_ORIG
+ PAGING_TYPE_1_ATT_RNC_ORIG)/3600/4
• 8 kpbs PCH -> 100 pages/s
• 24 kbps PCH -> 400-500 pages/s

=(PAGING_TYPE_1_ATT_CN_ORIG
+ PAGING_TYPE_1_ATT_RNC_ORIG)/3600

50 © Nokia 2016 Nokia Internal Use


Example: Upgrading paging channel from 8 kbps to 24 kbps PCH
comparing monitoring methods ; results are quite similar
Results using RNC_2031a PCH Load Ratio - PCH, Results using PCH utilization based on paging
for the same NW on Nov 5th messages , for the same NW on Nov 5th

PCH utilisation Nov 5

1400 120 %

1200
100 %

1000
80 %

Wcell hour count


800

CDF %
60 %
600

40 %
400

20 %
200

0 0%
11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73
Utilisation [%]

Paging utalization calculated as Pagings per second according to the


formula below :
(M1006C25 PAGING_TYPE_1_ATT_CN_ORIG + M1006C26
PAGING_TYPE_1_ATT_RNC_ORIG)/180 000
51 © Nokia 2016 Nokia Internal Use
Example: Paging success rate from LAC350 (MSS counters)
msc_511a Paging attempt success ratio, per LAC

100
Paging Succesrate per LAC
99
98
97
96
95
94 Improved paging success LA
rate after feature activation C
93
35
92 0
91
90

2010/12/10
2010/11/29
2010/11/30
2010/12/01
2010/12/02
2010/12/03
2010/12/04
2010/12/05
2010/12/06
2010/12/07
2010/12/08
2010/12/09

2010/12/11
2010/12/12
2010/12/13
2010/12/14
2010/12/15
2010/12/16
2010/12/17
2010/12/18
2010/12/19
2nd SCCPCH
and 24 kbps
PCH activated
52 © Nokia 2016 Nokia Internal Use
Example: msc_514a Paging messages per paging attempt from VLR ratio
from VLR LAC350
Pag msg per pag from VLR (%)
180.00
160.00
140.00
120.00
100.00
80.00
60.00
40.00 2nd SCCPCH
20.00 and 24 kbps
0.00 PCH activated

Pag msg per pag from VLR MSC_514A

After feature activation less paging messages per paging is send. Hence paging load has decreased and
paging capacity increased while paging success rate is improved

53 © Nokia 2016 Nokia Internal Use


Example: PS NRT active failures RNC15, 13 and 18
2nd SCCPCH included , improved paging paging success and more capacity for FACH reduced
drops due to radio in this case . RNC_1959b RAB Active FR for PS due to RADIO can be used for this
analysis

RAB active fail PS background RADIO


18000
16000
14000
12000
10000
8000
6000
4000
2000
0

RNC-13 RNC-15 RNC-18

2nd SCCPCH and 2nd SCCPCH and 24


24 kbps PCH kbps PCH activated in
activated in RNC15 RNC13 and 18
54 © Nokia 2016 Nokia Internal Use
Paging drop counters (1/3)

RNC Counters to measure the amount of dropped paging records in L2.


• Previously this information was available only in DMPG computer logs
Counter id Counter Name Updated
M1006C251 PAGING DROP LOW PRIORITY When the L2 entity of RCN drops low priority paging message due to congestion
M1006C252 PAGING DROP HIGH PRIORITY When the L2 entity of RNC drops high priority paging message due the congestion

L3 detects first-time and repeated paging’s for


Idle and Connected mode UEs and attaches the
information into paging messages sent to the L2.

The first-time paging's are marked as having


“high priority” and repeated paging’s as having
“low priority”.

L2 prioritises paging records marked as having


“high priority” over the ones marked with “low
priority” in its scheduling decisions

55 © Nokia 2016 Nokia Internal Use


Paging drop counters (2/3)

When RNC receives paging message RANAP: Paging from


Paging for UE’s in IDLE state the CN, counter: M1003C36 REC_PAG_MSG is incremented
UE BTS RNC CN
M1006C251 PAGING_DROP_LOW_PRIORITY : The number of
UE In Idle mode low priority paging records dropped in L2 scheduling.
RANAP: PAGING Counter is updater when the L2 entity of RNC drops low priority
1 PICH
paging message due to congestion.

(FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TYPE 1 M1006C252 PAGING_DROP_HIGH_PRIORITY : The number of


high priority paging records dropped in L2 scheduling.
RRC connection establishment
Counter is updated when the L2 entity of RNC drops high priority
paging message due to congestion.
Paging response

CN (RANAP: PAGING Message received from CN = UE in idle mode) If RNC cannot process the paging messages and forward those to the UE
originated paging amount: When RNC sends Paging Type 1 through cells, due to high ICSU load, counter M1003C47
counter M1006C25 PAGING_TYPE_1_ATT_CN_ORIG DEL_PAG_MSG_ICSU_OVERLOAD is incremented

Counter is updated when the RNC L2 entity has successfully scheduled If RNC cannot process the paging messages and forward those to the UE
PAGING TYPE 1 message for sending to the BTS and the paging procedure due to high RRMU load, counter M1003C48
is triggered by the CN.
DEL_PAG_MSG_RRMU_OVERLOAD is incremented
Paging messages dropped due to overload are not included.

56 © Nokia 2016 Nokia Internal Use


Paging drop counters( 3/3)

Upon receiving of the paging message from Core Network, L3 determines priority of the message
• The idea is that first time paging and paging messages related to system information update would be given
high priority and repetition of an earlier received paging message would be set as low priority
• Prioritisation will be done for both Idle and Connected mode UE related pagings
• L3 passes the paging message to the cell-specific MAC-c entity
• The message includes information of the priority of the paging
• Based on this, the message is placed to the corresponding paging queue to be scheduled at the appropriate
time
• MAC-c schedules the paging messages so that the high priority queue is prioritised over the low priority
queue whenever possible
• Paging messages that could not be scheduled on time are discarded.
• A good rule of thump is : page drops should not be more than 0.5% for high priority pages , and
should not be more than 15-20 % for low priority pages .

57 © Nokia 2016 Nokia Internal Use


Paging success KPIs

Other paging KPIs which are showing paging success

KPI ID KPI Name and definition

mob_vlr86c ( Core NW)) Paging success ratio (CS only) , target > 97%

msc_2067a( Core NW) EPS Paging Success Ratio, target > 97%

RNC_1215b Paging - Cell PCH - success ratio, based on Cell Updates

RNC_1216a Paging - Cell PCH - Failure ratio, Paging procedure Failure Ratio Cell PCH based on failed paging occasions

RNC_1217a Average Paging Delay, Average delay of paging procedure

58 © Nokia 2016 Nokia Internal Use


Counters for Paging Success KPIs When RNC receives paging message RANAP: Paging from the CN, counter:
M1003C36 REC_PAG_MSG is incremented

Paging for UEs in CELL_PCH or URA_PCH M1006C155 PAGING_OCCASION_CELL_PCH : When the UE is in Cell-PCH state
and RANAP: PAGING is received or downlink data transfer is needed
states M1006C159PAGING_OCCASION_URA_PCH: The number of occasions when
paging is required for UE in URA-PCH state, i.e. the RNC starts paging.
The counter is updated for the cell where the UE responds to paging, or if the UE
2 MM MM Idle
does not respond the counter is updated to last cell with activity

UE BTS RNC Connected


CN 1 CN 2
If RNC cannot process the paging messages and forward those to the UE
UE has signalling connection to CN1 due to high ICSU load, counter M1003C47
DEL_PAG_MSG_ICSU_OVERLOAD is incremented
UE is in URA_PCH or CELL_PCH state
RANAP:PAGING If RNC cannot process the paging messages and forward those to the UE due to
PICH high RRMU load, counter M1003C48 DEL_PAG_MSG_RRMU_OVERLOAD is
incremented
(FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TYPE 1
CN (RANAP: PAGING Message received from CN = UE does not have signalling
(RACH) RRC Cell Update : Paging Response connection to that CN) originated paging amount: When RNC sends Paging Type 1 thourgh
a cell, counter M1006C25 PAGING_TYPE_1 ATT_CN_ORIG
Paging response to CN 2

M1006C156 PAGING_MESSAGES_CELL_PCH : The number of paging messages sent to


When RNC receives Cell Update with cause Paging Response the UE in Cell-PCH state. This counter contains all sent pages, not only repeated ones, before
counter M1006C37 CELL_UPD_ATT_PAGING_RESP the UE response is received or before paging is stopped due to no response from the UE.
M1006C160PAGING_MESSAGES_URA_PCH: The number of paging messages sent to
UE in URA-PCH state. This counter contains all sent pages, not only repeated ones, before
M1006C157CELL_UPD_AFTER_PAG_CELL_PCH: The number of the UE response is received or before paging is stopped due to no response from the UE.
Cell updates counted as a paging response received from the UE The counter is updated for the cell where the UE responds to paging, or if the UE does not
after paging in Cell-PCH state. respond the counter is updated to last cell with activity
This counter is also used as a denominator when average paging
delay is calculated from M1006C163
M1006C161CELL_UPD_AFTER_PAG_URA_PCH : The number of
Cell updates counted as a paging response received from the UE M1006C158 FAIL_PAG_NO_RESP_CELL_PCH: The number of unsuccessful paging occasions when the
after paging in URA-PCH state. This counter is also used as a RNC judges the whole paging occasion unsuccessful due to no response from the UE
denominator when average paging delay is calculated using In case of UTRAN paging, after the whole UTRAN originated paging occasion is executed (including
M1006C166. UTRAN originated paging repetitions). The RRC entity sets 2 second timer to wait for a paging response
updated when message RRC: CELL UPDATE is received after from the UE. If the 2 second timer expires, the counter is increased by one
paging from a UE in Cell-PCH state: 'Paging response', 'Cell M1006C162FAIL_PAG_NO_RESP_URA_PCH: The number of unsuccessful paging occasion when the
reselection', 'Periodic update', 'Data transmission' and 'Re-entering RNC judges the whole paging occasion unsuccessful due to no response from the UE.
service area' The counter is updated to the cell for/from which the UE had last activity
The counter is updated for the cell where the UE responds to paging In case of UTRAN paging, after the whole UTRAN originated paging occasion is executed (including
59 © Nokia 2016 Nokia Internal Use UTRAN originated paging repetitions). The RRC entity sets 2 second timer to wait for a paging response
from the UE. If the 2 second timer expires, the counter is increased by one.
Paging Load Optimization action example : LAC splitting

• Enabling a 2nd S-CCPCH without 24 kbps paging channel will not increase the PCH capacity
(8kbps), but only FACH capacity.
• LAC splitting is needed to reduce the Paging Load
• LAC split methodology is based on the number of BH MTCs: the target is to balance BH MTC on
hour level

Answered pagings are shown in the graph ,


LAC splitted
Answered Pagings (CS) 
M1001C56 MTC_LOW_PR IOR_SIGN_A TTS 
M1001C60 MTC_CAUSE_UNKNOWN_AT TS 
M1001C32 MTC_CONV_C ALL_ATTS

Weekend normal traffic decrease

60 © Nokia 2016 Nokia Internal Use


Paging Load Optimization action example : DRX Cycle Length

• DRX Cycle Length changed from 1280ms to 640ms


• Linear region increased from 45% to 58%
• Higher number of received Paging messages per second can be tolerated for the same Paging load
level without re-Paging.

61 © Nokia 2016 Nokia Internal Use


Paging Load Optimization action example : Paging Parameter
Recommendations (1/2)
Implicit Detach (VLR) = 8h Parameter Name (Cell level) Def/Current Recommended Value

CS_T3212 = 40dh (decihours) = 240min = N300 3 2

4hours T300 2000ms 2000ms (10)

Parameter Name (RNC level) Current Recommended Value


TMSI page repetition in voice call = Used
WaitTimeRRCconversational 3 2
Paging Attempts (AT) = 0 or 1 WaitTimeRRCstreaming 3 2
WaitTimeRRCinteractive 5 8
Repaging Interval (INT) = 3.5 s or 4.5s WaitTimeRRCbackground 5 8
WaitTimeRRCsubscribed 3 3
WaitTimeRRCemergency 1 1

UTRAN DRX cycle length = 640 ms WaitTimeRRCinterRATreselection 3 3


WaitTimeRRCregistration 5 5
IuCS DRX cycle length = 640 ms WaitTimeRRChighPrioritySignalling 1 2
WaitTimeRRClowPrioritySignalling 5 2
IuPS2 DRX cycle length = 640 ms
WaitTimeRRCunknown 1 2
WaitTimeRRCother 0 2

62 © Nokia 2016 Nokia Internal Use


Paging Load Optimization action example : Paging Parameter
Recommendations (2/2) Voice call

SMS
No Paging
Initial Page 1st Re-Page 2nd Re-Page 3rd Re-Page Response
VLR sends to RNC & RNC
sends to UE
No Paging
Paging interval4. 5s Response

Initial Page 1st Re-Page


Two pages received from RNC
UE listens pages and
SMS establishes RRC RRC Connection
Request
Paging
Response
Wait Time 2s Wait Time 2s

Initial Page 1st Re-Page 2nd Re-Page 3rd Re-Page


Four pages received from RNC
UE listens pages and
Voice establishes RRC RRC Connection
Request
Paging
Response
Wait Time 2s Wait Time 2s Wait Time 2s Wait Time 2s

63 © Nokia 2016 Nokia Internal Use


MSS/VLR counters for Paging

MSS/VLR counters for Paging attempts (originated by MSC only), successes and failures per LAC in
measurement table M353.
• Available in VLR measurement report, paging per LAC (353/161H)
Counter id Counter name Description
M353B3C1 PAGING ATTEMPTS PER LAC Number of initiated Pagings from the VLR to the specific LA.
M353B3C2 SUCCESSFUL PAGINGS PER LAC Number of successful Pagings in the VLR in the specific LA
M353B3C3 PAGING ATTEMPT WITH IMSI PER LAC, The number of paging attempt with IMSI for successful pagings (ATT#(SUCC)) counters
SUCCESSFUL show how many paging requests were sent to the A and Iu interfaces (from the MSC) per
LAC when the paging was successful.
M353B3C4 PAGING ATTEMPT WITH TMSI PER The number of paging attempt with TMSI for successful pagings (ATT#(SUCC)) counters
LAC, SUCCESSFUL show how many paging requests were sent to the A and Iu interfaces (from the MSC) per
LAC when the paging was successful
M353B3C5 PAGING ATTEMPT WITH IMSI PER LAC, The number of paging attempt with IMSI for failed pagings (ATT#(FAIL)) counters show how
FAILED many paging requests were sent to the A and Iu interfaces (from the MSC) per LAC when
the paging failed.
M353B3C6 PAGING ATTEMPT WITH TMSI PER The number of paging attempt with TMSI for failed pagings (ATT#(FAIL)) counters show
LAC, FAILED how many paging requests were sent to the A and Iu interfaces (from the MSC) per LAC
when the paging failed.

64 © Nokia 2016 Nokia Internal Use


Paging - Core Network Parameters

AT (MSS) Use of TMSI (VLR) Page Repetition (VLR) Result


0 Yes Yes TMSI+IMSI
0 Yes No TMSI
1 Yes Yes TMSI+TMSI+IMSI+IMSI
2 Yes Yes TMSI+TMSI+TMSI+IMSI+IMSI+IMSI
2 Yes No TMSI+TMSI+TMSI
2 No Yes IMSI+IMSI+IMSI
2 No No IMSI+IMSI+IMSI

• Search procedure is performed only if MS location is not found


- Search is always an IMSI page which will be repeated SCOUNT times with SINTER intervals

65 © Nokia 2016 Nokia Internal Use


Paging Counters signaling flows (1/4)

Paging for UEs in IDLE state


UE BTS RNC CN
When RNC receives paging message RANAP:
UE In Idle mode Paging from the CN, counter: M1003C36
RANAP: PAGING REC_PAG_MSG is incremented
1 PICH
(FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TYPE 1 These two counters are discontinued
RRC connection establishment

Paging response If RNC cannot process the paging messages and forward
those to the UE due to high ICSU load, counter M1003C47
DEL_PAG_MSG_ICSU_OVERLOAD is incremented

If RNC cannot process the paging messages and forward


those to the UE due to high RRMU load, counter M1003C48
DEL_PAG_MSG_RRMU_OVERLOAD is incremented

CN (RANAP: PAGING Message received from CN = UE in idle mode)


originated paging amount: When RNC sends Paging Type 1 through cells,
counter M1006C25 PAGING_TYPE_1_ATT_CN_ORIG

Counter is updated when the RNC L2 entity has successfully scheduled


PAGING TYPE 1 message for sending to the BTS and the paging procedure
is triggered by the CN.

Paging messages dropped due to overload are not included.

66 © Nokia 2016 Nokia Internal Use


Paging Counters signaling flows (2/4)
M1006C163 PAG_DELAY_CU_CELL_PCH:
The sum of Cell-PCH paging delays defined as the time between
Paging for UEs in CELL_PCH or the first sent
RRC: PAGING TYPE 1 message and the
URA_PCH states RRC: CELL UPDATE received from the UE.
This counter, divided by M1006C157, provides the average paging
2 MM MM Idle
delay.
M1006C165 DENOM_PAG_DELAY_RESP_CEL_PCH: The
UE BTS RNC Connected
CN 1 CN 2 number of paging delay values updated to counter M1006C164.
Used as a denominator in average calculation.
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 M1006C166 SUM_PAG_DELAY_CU_URA_PCH:


The sum of URA-PCH paging delays defined as the time between
(RACH) RRC Cell Update : Paging Response the first sent
RRC: PAGING TYPE 1 message and the
Paging response to CN 2 RRC: CELL UPDATE received from the UE.
This counter, divided by M1006C161, provides the average paging
delay.
M1006C167 SUM_PAG_DELAY_RESP_URA_PCH: The sum of
URA-PCH paging delays defined as the time between the first sent
RRC: PAGING TYPE 1 message and the
RRC: UTRAN MOBILITY INFORMATION CONFIRM or any other
UL DCCH received from the UE after a successful connection
establishment procedure.
M1006C169PRACH_DELAY_RANGE_VALUE: The value of
This counter, divided by M1006C168, provides the average paging
WCEL parameter PRACHDelayRange when the last RRC
delay.
Connection Request or Cell Update of the measurement interval
M1006C168 DENOM_PAG_DELAY_RESP_URA_PCH: The
was received.
number of paging delay values updated to counter M1006C167.
Used as a denominator in average calculation.

67 © Nokia 2016 Nokia Internal Use


M1006C155 PAGING_OCCASION_CELL_PCH : When the UE is in Cell-PCH state
and RANAP: PAGING is received or downlink data transfer is needed
Paging Counters signaling flows (3/4) M1006C159PAGING_OCCASION_URA_PCH: The number of occasions when
paging is required for UE in URA-PCH state, i.e. the RNC starts paging.
The counter is updated for the cell where the UE responds to paging, or if the UE
does not respond the counter is updated to last cell with activity

Paging for UEs in CELL_PCH or URA_PCH


states due to arriving data packet from A number of RNC originated paging type 1 attempts (UE in PCH/URA
SGSN substate): When RNC sends Paging Type 1 through a cell, counter M1006C26
PAGING_TYPE_1_ATT_RNC_ORIG Paging messages dropped due to
overload are not included.

UE RNC SGSN M1006C156 PAGING_MESSAGES_CELL_PCH : The number of paging messages sent to UE


in Cell-PCH state. This counter contains all sent pages, not only repeated ones, before the UE
response is received or before paging is stopped due to no response from the UE.
The MAC-d (RLC) in M1006C160PAGING_MESSAGES_URA_PCH: The number of paging messages sent to UE in
RNC indicates that there
3 is downlink user data in 1.PDP PDU
URA-PCH state. This counter contains all sent pages, not only repeated ones, before the UE
response is received or before paging is stopped due to no response from the UE. The counter
RLC buffers then the is updated for the cell where the UE responds to paging, or if the UE does not respond the
RRC signaling entity counter is updated to last cell with activity
initiates the paging
procedure
2. Paging Request (P-TMSI)

RRC: PAGING TYPE 1 with PICH BTS -> UE When RNC receives Cell Update with cause Paging Response the counter M1006C37
CELL_UPD_ATT_PAGING_RESP
MM Cell Update

(RACH) RRC Cell Update : Paging Response M1006C157CELL_UPD_AFTER_PAG_CELL_PCH: The number of Cell updates
counted as a paging response received from the UE after paging in Cell-PCH state.
This counter is also used as a denominator when average paging delay is calculated from
M1006C163
M1006C158 FAIL_PAG_NO_RESP_CELL_PCH: The number of unsuccessful M1006C161CELL_UPD_AFTER_PAG_URA_PCH : The number of Cell updates
paging occasions when the RNC judges the whole paging occasion unsuccessful counted as a paging response received from the UE after paging in URA-PCH state. This
due to no response from the UE counter is also used as a denominator when average paging delay is calculated using
In case of UTRAN paging, after the whole UTRAN originated paging occasion is M1006C166.
executed (including UTRAN originated paging repetitions). The RRC entity sets 2 updated when message RRC: CELL UPDATE is received after paging from a UE in Cell-
second timer to wait for a paging response from the UE. If the 2 second timer PCH state: 'Paging response', 'Cell reselection', 'Periodic update', 'Data transmission' and
expires, the counter is increased by one 'Re-entering service area'
M1006C162FAIL_PAG_NO_RESP_URA_PCH: The number of unsuccessful The counter is updated for the cell where the UE responds to paging
paging occasion when the RNC judges the whole paging occasion unsuccessful
due to no response from the UE.
The counter is updated to the cell for/from which the UE had last activity
In case of UTRAN paging, after the whole UTRAN originated paging occasion is
executed (including UTRAN originated paging repetitions). The RRC entity sets 2
second timer to wait for a paging response from the UE. If the 2 second timer
68 © Nokia expires,
2016 the counter is increased by one. Nokia Internal Use
Paging Counters signaling flows (4/4)
Paging for UEs in CELL_FACH or
CELL_DCH states When RNC receives paging message
MM Connected MM Idle
UE 4 BS RNC CN 1 CN 2
RANAP: Paging from the CN, counter:
M1003C36 REC_PAG_MSG is
incremented
UE has signalling connection to CN1
CN (RANAP: PAGING Message
UE is in CELL_FACH or CELL_DCH state RANAP:PAGING received from CN = UE in
CELL_FACH or CELL_DCH states)
originated paging amount: When
RNC sends Paging Type 2 through a
Paging response to CN 2 cell
M1006C27 PAGING_TYPE_2_ATT

69 © Nokia 2016 Nokia Internal Use


Content

Common Channel Load Monitoring


Uplink Channel Monitoring
RAN1913 HS-FACH UL
RAN 2902 RACH capacity increase
Downlink Channel Monitoring
SCCPCH
Paging
FACH
RAN1637 HS-FACH DL
70 © Nokia 2016
FACH-u and FACH-c

 The load of different transport channels (FACH-u, FACH-c and PCH) can be monitored separately
 FACH-u and FACH-c load can be calculated using Formulas below
• RNC_2029b FACH-u Load Ratio provides information about the FACH transport channel User Plane data load, by dividing
the FACH channel throughput by the corresponding transport channel max bit rate to get the load ratio.

Sum AVE_FACH_UDATA_TP_SCCPCH 
RNC_ 2029b_FACH  u  100*
SumFACH_U_DATA_TPUT_DENOM_1*36000

• RNC_2030b FACH-c Load Ratio provides information about the FACH transport channel Control Plane data load, by dividing
the FACH channel control data throughput by the corresponding transport channel max bit rate to get the load ratio.

  AVE_FACH_USER _ TOT _ TPUT   (AVE_FACH_UDATA_TP_S CCPCH)  


100*    
  FACH_USER_TOT_TPUT_D ENOM_1   FACH_U_DAT A_TPUT_DEN OM_1  
RNC_ 2030b 
33600

71 © Nokia 2016 Nokia Internal Use


Example: FACH-c and FACH-u loading

• FACH and S-CCPCH load from two high traffic cells


• RACH-c and FACH-c have higher priority, also the user plane allocation is limited when RACH or
FACH load reaches load threshold (default 75%)

72 © Nokia 2016 Nokia Internal Use


PCH loading affect on FACH throughput

One SCCPCH and 8 kbps


PCH.
•When SCCPCH is heavily loaded
there is risk that FACH messages
are delayed or even dropped.
• High load may cause :
- RRC connection setup failures
- RB reconfiguration failures
- RRC state changes failures
- Cell update failures

73 © Nokia 2016 Nokia Internal Use


Content

Common Channel Load Monitoring


Uplink Channel Monitoring
RAN1913 HS-FACH UL
RAN 2902 RACH capacity increase
Downlink Channel Monitoring
SCCPCH
Paging
FACH
RAN1637 HS-FACH DL
74 © Nokia 2016
RAN 1637 HS-FACH DL feature changes how common channels work

• Before RAN 1637 CELL_FACH is suitable for “always on” type services which
have frequent but small data packets
– UE in CELL_FACH use the FACH transport channel mapped onto a S-CCPCH for transmission of small
downlink data packets
– HSPA could only be used in CELL_DCH
• 3GPP Rel7 specifies the use of HSDPA in CELL_FACH, CELL_PCH and
URA_PCH
– RAN1637 High Speed FACH (DL); HSDPA not supported in CELL_PCH and URA_PCH
• 3GPP Rel8 specifies the use of HSPA in CELL_FACH
– RAN1913 High Speed FACH (UL/DL)

75 © Nokia 2016 Nokia Internal Use


Mapping of FACH on HS-PDSCH reduces load on S-CCPCH
• Downlink channels mapping for High Speed Cell _FACH (DL)
– 2xS-CCPCH assumed
– downlink logical channels can be mapped onto the HS-DSCH transport channel and HS-PDSCH physical channel
– PCCH mapping onto HS-DSCH not supported in Nokia

BCCH CCCH DCCH DTCH PCCH


Logical channels

Transport channels BCH FACH FACH FACH HS-DSCH FACH PCH

3GPP Rel7
Physical channels
P-CCPCH S-CCPCH HS-PDSCH S-CCPCH S-CCPCH

76 © Nokia 2016 Nokia Internal Use


RAN 1637 Simulation Results S-CCPCH occupation with HS-FACH functionality

Much lower S-CCPCH


occupation due to lower
FACH channel utilization
Here again we are only
looking at the common
channels relevant benefits of
the RAN1637 feature

77 © Nokia 2016 Nokia Internal Use


Some of the KPIs to monitor HS-FACH load

HS-FACH features have many more counters to monitor other aspects of the features

KPI ID KPI NAME Unit


Average downlink user data throughput in Enhanced
RNC_5368a kbit/s
CELL_FACH
RNC_5457a Enh FACH DL load %
RNC_5462a HS-FACH data volume downlink Mbit
RNC_5367a Average downlink control data throughput in HS CELL_FACH kbit/s
RNC_5367a Average downlink control data throughput in HS CELL_FACH kbit/s
NUMBER OF CONTROL DATA FRAMES PROCESSED DL
M5000C438 Integer number
EFACH
M5002C51 CONTROL DATA VOLUME DL EFACH Kilobyte
M5002C53 CONTROL DATA TRANSMITTED TIME DL EFACH ms

78 © Nokia 2016 Nokia Internal Use


All counters and Kpis are in JUMP , below are the main Reporting Suite
reports

79 © Nokia 2016 Nokia Internal Use


References

• Please check relevant feature docs from BDNE enablings depository here .
• RAN 1913 here
• TS-RNC-SW-148
• Cell Capacity optimization guideline
• 3G Radio Planning Guideline
• RAN 1637 HS-FACH DL tests from Italy here
https://sharenet-ims.int.net.nokia.com/livelink/livelink/overview/D503811447

80 © Nokia 2016 Nokia Internal Use