Capacity_CCH Load and Paging
Short Description
Common Channel load monitoring...
Description
WCDMARANOptimisation CommonChannelsmonitoring Asli Tokgoz Tokgoz Nov 2016
GS NPO Radio
Introduction • This material Covers Uplink and Downlink common channel monitoring issues , some optimization aspects are also discussed . • A comprehensive comprehensive list of impacting parameters and optimization is in wiki here
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
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
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
Uplink Channel Mapping
CCCH
RACH
DCCH
PRACH
E-DPDCH E-DPCCH EDCH
HS-DPCCH DPDCH
DTCH
DCH
DPCCH
• AsingleRACHtransportchannelisused forboth,controlplanesignalinganduser planedata. • RACHismappedtoPRACHontoPRACH physicalchannelwhichmakesuseof contentionbasedaccessprocedurei.e. thereisprobabilitythatcollisionsoccur whenmultipleUEattempttomakeuseof thePRACH. • PRACHisseparatedinthepreamblepart andamessagepart.Preamblesareused togainaccesstoPRACHmessagetime slotandtoensurethatthemessageis transmittedwithsufficientuplinkpower.
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 r ounded 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)
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
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
R NC _978b A verag e PR A C H Mess ag e Load can be used to measure PRACH message load •
The maximum preamble capacity is 60 preambles per RACH frame of 20 ms
RNC_ 978b_AverageP RACHMessag eLoad
SUM_RACH_ ACK_PREAMB LES
DENOM_RACH _ACK_PREAM BLES
Measuring the PRACH Preamble capacity •
•
The RACH message decoding blocking can be estimated with Erlang B equation (although this is not 100% correct for slotted system like RACH and to system with re-transmission). Blocking will cause the BTS to send a negative acknowledgement and UE to apply N300 and T300 for re-transmission. A load of 1 preamble per 20 ms (about 2% preamble blocking according to the Erlang table ) = 25% total BTS decoding load)
RNC_978b =1 can be used as triggering point for RACH_capacity parameter increase.
30 %
RACH message decoding blocking probability 25 %
g 20 % n i k c o l b e g a s 15 % s e m H C A R
P(Capacity=2) P(Capacity=3) P(Capacity=4)
10 %
5%
0% 1 2 4 6 7 9 1 2 4 6 7 9 1 2 4 6 7 9 1 2 4 6 7 9 1 2 4 6 7 9 0 . 1 . 2 . 3 . 4 . 5 . 7 . 8 . 9 . 0 . 1 . 2 . 4 . 5 . 6 . 7 . 8 . 9 . 1 . 2 . 3 . 4 . 5 . 6 . 8 . 9 . 0 . 1 . 2 . 3 . 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 3 3 3 3
Number of RACH preamles per frame (RNC_978b)
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 1000C 60 AVE_RACH_ THROUGHPUT
RACH _ throughput
M 1000C 61 RACH_DENO M_ 3
• R NC _2032a R A C H-u Load R atio provides RACH transport channel User Plane data throughput RACH-u throuhgput
M 1000C 62 AVE_RACH_ DATA_THROU GHPUT
M 1000C 63 RACH_DENO M_ 4
• R NC _2033a R A C H-c Load R atio provides RACH transport channel Control Plane data throughput M 1000C 60 AVE_RACH_ THROUGHPUT M 1000C 62 AVE_RACH_ DATA_THROU GHPUT RACH-c throughput
M 1000C 61 RACH_DENO M_ 3
M 1000C 63 RACH_DENO M_ 4
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
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
Example: RACH-c and RACH-u loading • Examples of RACH load (TP / TP_max) in high traffic cells (R A CH_capacity = 2, TP =R NC _16c A verage RA C H Throug hput, TP _max =72kbps ) • In extreme load the RACH throughput drops even though ack preample load
(RNC_978 )is
high
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 RA CHCapacity (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
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
Impact of RAN1637/RAN1913 RAN1637 RAN1913
RAN1637 Not activated
Activated HSPA also on common channels
HSPA only on dedicated channels
Common channels
Common channels Dedicated channels
Common channels Dedicated channels
Data transmission Cell_PCH to Cell_DCH
Transmission on HSPA in Cell_DCH
Cell_PCH to Cell_FACH
Transmission on HSPA in Cell_FACH
RAN 1913 HS-RACH reduces need for RACH procedure ( RU40) Rel99 RACH vs. E-DCH procedure
TheusageofthePRACHchanges,uplinkchannelsaremappedforHS;Cell _FACHandPRACHchannelsarenotusedafterfirstaccess AICH response
AICH response
AICH response
Common E-DCH resource assigned UE specific E-RNTI on E-AGCH
D L
AICH
10 ms
AICH
10 ms
D
AICH
L
U
E-AGCH
U
L PRACH
PRACH
PRACH
Collision probability
PRACH Collision probability
Rel99 UL RACH procedure
L
PRACH
E-DPDCH E-DPDCH E-DPDCH E-DPCCH E-DPCCH E-DPCCH Collision probability
Common E-DCH resources exclusively used by this UE
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
RAN1913 Channel mapping in High Speed Cell_FACH Requires 3GPP Rel-8
CCCH
DCCH
DTCH
Logical channels
Transport channels
E-DCH
RACH
3GPP Rel8
Physical channels PRACH
E-DPDCH
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 M5000C 423 - DE NI E D C OMMO N E DC H R E S OUR CE S , can be used until WCDMA16 after that; M5000C423 is replaced by M5000C 462 UNSUCC_HS_RACH_PREAMBLE .
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://workspacesemea.int.nokia.com/sites/nporadio/Radio%20Wiki/WCDMA%20NPO%20feature%20materials%20and%20references.aspx
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
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.
RAN2902 RACH Capacity Increase ( WCDMA 16) Impact of RAN2902 • Increased network accessibility but increased the RACH load as well •
Decreased uplink interferences due to less RACH cycles (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 .
Could help with : • Highly loaded cells • Cells with bursty traffic (e.g. airport) • HS RACH capable cells
RAN2902: Parameters A llowedPreambleSig natures (WC E L) : old parameter is deleted starting WCDMA16 R AC HPreambleSig natures (WCE L) : 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.
B TSR AC HCapaIncCapability (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)
NumberofRACHSignaturespercellisincreasedfrom4 to16withRAN2902 Lesscollisionsoccursespeciallyin highlyloadedcells(wheremore collisionsareexpected) PossibilityfordifferentRACHand HS-RACHsignaturescombinations Configurations3+3,4+4,4+8and 4+12notallowedifRAN1913 isdisabled
RACHPreambleSignatures
setting
RAN1913 not activated #RACH signatures
RAN1913 activated #HS#RACH RACH signatures signatures
1 RACH signature
1
1
1
2 RACH signatures
2
2
1
3 RACH signatures
3
3
1
4 RACH signatures
4
3
1
3+3 RACH and HS RACH signatures
N/A
3
3
8 RACH signatures
8
7
1
4+4 RACH and HS RACH signatures
N/A
4
4
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
•
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
•
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
• RNC_5560a HS RACH Preambles Utilization Ratio
• RNC_5559a R99 RACH Decode Success Ratio
M5000C464 UNSUCC_DECODED_ HS_RACH
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 .
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
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
Downlink Channel Mapping for S-CCPCH Logical Channels
Transport Channels
Physical Channels
P-CPICH
• Two main use cases • PCH • FACH
BCC H
BCH
P-CCPCH
PCC H
PCH
S-CCPCH PICH AICH P/S-SCH
CCC H
FACH
CTCH DCCH
DTCH
HS-DSCH
E-HICH HS-PDSCH* HS-SCCH
DCH
DPDCH DPCCH
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 t o 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
RNC_ 979a_SCCPCHAverageLoad
M 1000C 64 AVE_SCCPC H_INC_PCH_ LOAD
M 1000C 65 SCCPCH_LO AD_DENOM_ 0
%
•
If a single S-CCPCH is configured then this KPI is applicable to that channel
•
If two S-CCPCH are conf igured 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 m easurement
•
Denom is incremented by the number of measurements
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
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
Paging Channel capacity •
NSN RAN, until RU10 (RN4.0) sw release, provides an 8 kbps PCH transport channel on the S-CCPCH.
•
The PCH TBS is 80 bits allowing to carry a single paging record per TTI (10ms) 100 paging records per second a single cell can thus page maximum 100 UEs per second
•
This capacity could get exhausted due to a combination of reasons (high traffic, LAC oversize,…). In case of too high Paging Load a considerable percentage of paging messages could get lost causing a bad user experience (‘nonreachability’ of UEs due to missing pages).
•
It should be taken into account that SCCPCH can be shared with the FACH-c and FACH-u but PCH always has priority. This means that a high Paging load has an impact upon FACH capacity when single S-CCPCH is configured.
Max PCH Throughput 8 kbps max 100 Pages/s per cell
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
Transport channel
Physical channel
DTCH
FACH-u
DCCH
CCCH
FACH-c
SCCPCH 1 SF 64
BCCH
PCCH
PCH
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 SF 164
SCCPCH SF 2128
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
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:
• PtxSC CP CH1 (PC H/FAC H or only FAC H)
HS-SCCH Cch,16, 0
Cch,128,4
• PtxS CC PC H2 (Standalone PC H)
S-CCPCH 2
• PtxSC CPCH3 (S-CCPC H for S AB )
PICH
Cch,64,1
• PtxS C CP C H2S F128 (S tandalone PC H SF 128 / 24kbps )
AICH P-CCPCH
• The PtxSCCPCH2SF128 parameter defines the transmit
Cch,256,3
power of the S-CCPCH used to transfer the 24 kbps PCH
CPICH S-CCPCH 1
• All parameters define the transmit power o f the data bits
Cch,256,2 Cch,256,1
(rather than the transmit power of the TFCI and Pilot bits) Cch,256,0
RNC KPIs for Paging attempts • Below counters can be used to monitor the number of paging messages per cell ( no official KPI): E_ 1 _ATT_CN_OR IG M 1006 C 25 _ PAGING_TYP Paging Att empts per Cell M 1006 C 25 PAGING_TYP E_ 1 _ATT_RNC_O RIG M 1006 C 27 _ PAGING_TYP E_ 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): PE_ 1 _ATT_CN_OR IG M 1006 C 25 _PAGING_TY Paging Type 1 Attempts per Cell M 1006 C 26 _PAGING_TY PE_ 1 _ATT_RNC_O RIG
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 in ternal message with common channel information to the Radio Resource Management in the RNC MAC-c sends this message at 2-second intervals
Average PC H Throughput
M 1000C 70 AVE PCH THROUGHPU T
M 1000C 71 PCH THROU GHPUT DENO M
0 * 1000000
bps
Not suitable if 24 kbps paging CH
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:
RNC_ 2031a_PCH Load 100
Average PC H Throughput bps 8000
%
Not suitable if 24 kbps paging CH
Average PCH throughput daily distribution • The average PCH Throughput approaches 7kbps several times per day • This can be assumed as a clear symptom of PCH congestion during the traffic peak hour.
RNC
≡
LAC
PCH physical limit
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
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
VLR Paging SR vs RNC_18c Average PCH Throughput : no congestion • Interesting to compare the correlation shown by a nearly unloaded RNC
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 more paging (i.e. re-paging) 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
M1003C36 – Received paging messages from CN (s)
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 bloc ks. In fact the best way to measure paging channel utilization is based on ( ref TS-RNC-SW-148)
PE_ 1 _ATT_CN_OR IG M 1006 C 25 _PAGING_TY Paging Type 1 Attempts per Cell PE_ 1 _ATT_RNC_O RIG M 1006 C 26 _PAGING_TY 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. nominal capacity = 50*3600= 180 000 msg/h (M1006C25 PA GING _TYPE _1_ATT_CN_OR IG + M1006C26 PA GING _TYPE _1_ATT_RNC_ORIG ) /180 000 • 50 msg/s for 8 kbps PCH
• 250 msg/s for 24 kbps PCH
nominal capacity = 250*3600= 900 000 msg/h (M1006C25
PA GING _TYPE _1_ATT_CN_OR IG + M1006C26 PA GING _TYPE _1_ATT_RNC_ORIG ) /900 000
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
Actual value
new value
RNC
Low utilization time to trigger of the MAC-d flow
Abbreviated Name 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
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 + P AGING_TYPE_1_ATT_RNC_ORIG)/3600
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, for the same NW on Nov 5th
Results using PCH utilization based on paging messages , for the same NW on Nov 5th
PCH utilisation Nov 5 1400
120 %
1200
100 %
1000
t n u o c 800 r u o h l l 600 e c W
80 %
60 %
40 %
400
20 %
200
0
0% 11 13 15 1 7 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 7 1 73
Utilisation [%]
Paging utalization calculated as Pagings per second according to the formula below : (M1006C25 PAGING_TYPE_1_ATT_CN_ORIG + M1006C26
% F D C
Example: Paging success rate from LAC350 (MSS counters) msc_511a Paging attempt success ratio, per LAC Paging Succesrate per LAC
100 99 98 97 96 95 94 93 92 91 90
LA C 35 0
Improved paging success rate after feature activation
9 2 / 1 1 / 0 1 0 2
0 3 / 1 1 / 0 1 0 2
1 0 / 2 1 / 0 1 0 2
2 0 / 2 1 / 0 1 0 2
3 0 / 2 1 / 0 1 0 2
4 0 / 2 1 / 0 1 0 2
5 0 / 2 1 / 0 1 0 2
6 0 / 2 1 / 0 1 0 2
7 0 / 2 1 / 0 1 0 2
8 0 / 2 1 / 0 1 0 2
9 0 / 2 1 / 0 1 0 2
2nd SCCPCH and 24 kbps PCH activated
0 1 / 2 1 / 0 1 0 2
1 1 / 2 1 / 0 1 0 2
2 1 / 2 1 / 0 1 0 2
3 1 / 2 1 / 0 1 0 2
4 1 / 2 1 / 0 1 0 2
5 1 / 2 1 / 0 1 0 2
6 1 / 2 1 / 0 1 0 2
7 1 / 2 1 / 0 1 0 2
8 1 / 2 1 / 0 1 0 2
9 1 / 2 1 / 0 1 0 2
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 20.00 0.00
2nd SCCPCH and 24 kbps 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
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 2nd SCCPCH and 24 kbps PCH
RNC-15
RNC-18
2nd SCCPCH and 24 kbps PCH activated in
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
L3detectsfirst-timeandrepeatedpaging’sfor IdleandConnectedmodeUEsandattachesthe informationintopagingmessagessenttotheL2. Thefirst-timepaging'saremarkedashaving “highpriority”andrepeatedpaging’sashaving “lowpriority”. L2prioritises pagingrecordsmarkedashaving “highpriority”overtheonesmarkedwith“low priority”initsschedulingdecisions
Paging drop counters (2/3) When RNC receives paging message RANAP: Paging from the CN, counter: M1003C36 REC_PAG_MSG is incremented
Paging for UE’s in IDLE state BTS
UE
RNC
CN
UE In Idle mode
1
RANAP: PAGING PICH (FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TYPE 1 RRC connection establishment
M1006C251 PAGING_DROP_LOW_PRIORITY : The number of low priority paging records dropped in L2 scheduling. Counter is updater when the L2 entity of RNC drops low priority paging message due to congestion. M1006C252 PAGING_DROP_HIGH_PRIORITY : The number of high priority paging records dropped in L2 scheduling. 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) originated paging amount: When RNC sends Paging Type 1 through cells, counter M1006C25 PAGING_TYPE_1_ATT_CN_ORIG
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
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.
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
Paging messages dropped due to overload are not included.
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 .
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
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 states 2 UE
BTS
RNC
MM Connected CN 1
MM Idle CN 2
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 i s incremented
UE has signalling connection to CN1 UE is in URA_PCH or CELL_PCH state PICH
M1006C155 PAGING_OCCASION_CELL_PCH : When the UE is in Cell-PCH state and RANAP: PAGING is received or downlink data transfer is needed 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
RANAP:PAGING
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
(FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TYPE 1 (RACH) RRC Cell Update : Paging Response
CN (RANAP: PAGING Message received from CN = UE does not have signalling 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 When RNC receives Cell Update with cause Paging Response the counter M1006C37 CELL_UPD_ATT_PAGING_RESP
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 M1006C161CELL_UPD_AFTER_PAG_URA_PCH : The number of Cell updates counted as a paging response received from the UE after paging in URA-PCH state. This counter is also used as a denominator when average paging delay is calculated using M1006C166. updated when message RRC: CELL UPDATE is received after paging from a UE in Cell-PCH state: 'Paging response', 'Cell reselection', 'Periodic update', 'Data transmission' and 'Re-entering service area'
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. 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 the UE response is received or before paging is stopped due to no response from the UE. 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 activ ity
M1006C158 FAIL_PAG_NO_RESP_CELL_PCH: T he number of unsuccessful paging occasions when the RNC judges the whole paging occasion unsuccessful due to no response from the UE 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 expires, the counter is increased by one M1006C162FAIL_PAG_NO_RESP_URA_PCH: The number of unsuccessful 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
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
LAC splitted
Answered pagings are shown in the graph , 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
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.
Paging Load Optimization action example : Paging Parameter Recommendations (1/2) Implicit Detach (VLR) = 8h CS_T3212 = 40dh (decihours) = 240min = 4hours TMSI page repetition in voice call = Used Paging Attempts (AT) = 0 or 1 Repaging Interval (INT) = 3.5 s or 4.5s
UTRAN DRX cycle length = 640 ms IuCS DRX cycle length = 640 ms
IuPS2 DRX cycle length = 640 ms
Parameter Name (Cell level)
Def/Current
Recommended Value
N300
3
2
T300
2000ms
2000ms (10)
Parameter Name (RNC level)
Current
Recommended Value
WaitTimeRRCconversational
3
2
WaitTimeRRCstreaming
3
2
WaitTimeRRCinteractive
5
8
WaitTimeRRCbackground
5
8
WaitTimeRRCsubscribed
3
3
WaitTimeRRCemergency
1
1
WaitTimeRRCinterRATreselection
3
3
WaitTimeRRCregistration
5
5
WaitTimeRRChighPrioritySignalling
1
2
WaitTimeRRClowPrioritySignalling
5
2
WaitTimeRRCunknown
1
2
WaitTimeRRCother
0
2
Paging Load Optimization action example : Paging Parameter Recommendations (2/2) Voice call
SMS Initial Page
1st Re-Page
2nd Re-Page
3rd
No Paging Response
Re-Page
VLR sends to RNC & RNC sends to UE No Paging Response
Paging interval4. 5s
1st Re-Page
Initial Page
SMS
UE listens pages and establishes RRC
Two pages received from RNC
RRC Connection Request Paging Response Wait Time 2s Initial Page
Wait Time 2s
1st Re-Page
2nd Re-Page
3rd Re-Page Four pages received from RNC
Voice
UE listens pages and establishes RRC
RRC Connection Request Paging Response W ait Ti me 2s
W ait Time 2s
W ait Time 2s
W ai t Time 2s
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, SUCCESSFUL
The number of paging attempt with IMSI for successful pagings (ATT#(SUCC)) counters 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 LAC, SUCCESSFUL
The number of paging attempt with TMSI for successful pagings (ATT#(SUCC)) counters 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, FAILED
The number of paging attempt with IMSI for failed pagings (ATT#(FAIL)) counters show how 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 LAC, FAILED
The number of paging attempt with TMSI for failed pagings (ATT#(FAIL)) counters show how many paging requests were sent to the A and Iu interfaces (from the MSC) per LAC when the paging failed.
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
Paging Counters signaling flows (1/4) Paging for UEs in IDLE state BTS
UE
RNC
CN
UE In Idle mode RANAP: PAGING
1
When RNC receives paging message RANAP: Paging from the CN, counter: M1003C36 REC_PAG_MSG is incremented
PICH (FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TY PE 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 h igh 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.
Paging Counters signaling flows (2/4) Paging for UEs in CELL_PCH or URA_PCH states 2 UE
BTS
RNC
MM Connected CN 1
MM Idle CN 2
UE has signalling connection to CN1 UE is in URA_PCH or CELL_PCH state
M1006C163 PAG_DELAY_C PAG_DELAY_CU_CELL_PCH: U_CELL_PCH: The sum of Cell-PCH paging delays defined as the time between the first sent RRC: PAGING TYPE 1 message and the RRC: CELL UPDATE received from the UE. This counter, divided by M1006C157, provides the average paging delay. M1006C165 DENOM_PAG_DEL DENOM_PAG_DELAY_RESP_CEL_ AY_RESP_CEL_PCH: PCH: The number of paging delay values updated to counter M1006C164. Used as a denominator in average calculation.
RANAP:PAGING
PICH (FP/AAL2/PCCH/PCH/S-CCPCH) (FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TYPE 1 (RACH) RRC Cell Update : Paging Response
Paging response to CN 2
M1006C169PRACH_DELAY_RANGE_VALUE: The value of WCEL parameter PRACHDelayRange PRACHDelayRange when t he last RRC Connection Request or Cell Update of the measurement interval was received.
M1006C166 SUM_PAG_DELA SUM_PAG_DELAY_CU_URA_PC Y_CU_URA_PCH: H: The sum of URA-PCH paging delays defined as the time between the first sent RRC: PAGING TYPE 1 message and the RRC: CELL UPDATE received from the UE. This counter, divided by M1006C161, provides the average paging delay. M1006C167 SUM_PAG_DELA SUM_PAG_DELAY_RESP_URA_P Y_RESP_URA_PCH: CH: The sum of URA-PCH paging delays defined as the time between the f irst sent RRC: PAGING TYPE 1 message and the RRC: UTRAN MOBILITY INFORMATION CONFIRM or any other UL DCCH received from the UE after a successf ul connection establishment procedure. This counter, divided by M1006C168, provides the average paging delay. M1006C168 DENOM_PAG_DEL DENOM_PAG_DELAY_RESP_URA AY_RESP_URA_PCH: _PCH: The number of paging delay values updated to counter M1006C167. Used as a denominator in average calculation.
Paging Counters signaling flows (3/4) Paging for UEs in CELL_PCH or URA_PCH states due to arriving data packet from SGSN
UE
3
The MAC-d (RLC) in RNC indicates that there is downlink user data in RLC buffers then the RRC signaling entity initiates the paging procedure
A number of RNC originated paging type 1 attempts (UE in PCH/URA substate): When RNC sends Paging Type 1 through a cell, cell, counter M1006C26 PAGING_TYPE_1_ATT_RNC_ORIG PAGING_TYPE_1_ATT _RNC_ORIG Paging messages dropped due to overload are not included. M1006C156 PAGING_MESSAGES_C PAGING_MESSAGES_CELL_PCH ELL_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. 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 the UE response is received or before paging is stopped due to no response from the UE. 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
SGSN
RNC
M1006C155 PAGING_OCCA PAGING_OCCASION_CELL_PCH SION_CELL_PCH : When the UE is in Cell-PCH state and RANAP: PAGING is received or downlink data transfer is needed 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
1.PDP PDU
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
M1006C158 FAIL_PAG_ FAIL_PAG_NO_RESP_CELL_PCH NO_RESP_CELL_PCH:: T he number of unsuccessful paging occasions when the RNC j udges the whole paging occasion unsuccessful due to no response from the UE 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 expires, the counter is increased by one M1006C162FAIL_PAG_NO_RESP_URA_PCH: The number of unsuccessful paging occasion when the RNC j udges 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
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 M1006C161CELL_UPD_AFTER_PA M1006C161C ELL_UPD_AFTER_PAG_URA_PCH G_URA_PCH : The number of Cell updates counted as a paging response received from the UE after paging in URA-PCH state. This counter is also used as a denominator when average paging delay delay is calculated using M1006C166. updated when message RRC: CELL UPDATE is received after paging from a UE in CellPCH state: 'Paging response', 'Cell reselection', 'Periodic update', 'Data transmission' and 'Re-entering service area' The counter is updated for the cell where the UE responds to paging
Paging Counters signaling flows (4/4) Paging for UEs in CELL_FACH or CELL_DCH states UE
4
BS
RNC
MM Connected
MM Idle
CN 1
CN 2
UE has signalling connection to CN1 UE is in CELL_FACH or CELL_DCH state
Paging response to CN 2
RANAP:PAGING
When RNC receives paging message RANAP: Paging from the CN, counter: M1003C36 REC_PAG_MSG is incremented CN (RANAP: PAGING Message received from CN = UE in CELL_FACH or CELL_DCH states) originated paging amount: When RNC sends Paging Type 2 through a cell M1006C27 PAGING_TYPE_2_ATT
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
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.
RNC_ 2029b_FACH u
•
100*
Sum AVE_FACH_U DATA_TP_SC CPCH Sum FACH_U_DAT A_TPUT_DEN OM_ 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.
RNC_ 2030b
AVE_FACH_U SER _ TOT _ TPUT (AVE_FACH_ UDATA_TP_S CCPCH) 100* 1 1 FACH_USER_ TOT_TPUT_D ENOM_ FACH_U_DAT A_TPUT_DEN OM_ 33600
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%)
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
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
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 o nto 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)
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
FACH
FACH
DTCH
PCCH
Logical channels
Transport channels
BCH
FACH
HS-DSCH
FACH
PCH
3GPP Rel7
Physical channels P-CCPCH
S-CCPCH
HS-PDSCH
S-CCPCH
S-CCPCH
RAN 1637 Simulation Results
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
S-CCPCH occupation with HS-FACH functionality
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 RNC_5368a
KPI NAME Average downlink user data throughput in Enhanced CELL_FACH
Unit kbit/s
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
M5000C438
NUMBER OF CONTROL DATA FRAMES PROCESSED DL EFACH
Integer number
M5002C51 CONTROL DATA VOLUME DL EFACH
Kilobyte
M5002C53 CONTROL DATA TRANSMITTED TIME DL EFACH
ms
All counters and Kpis are in JUMP , below are the main Reporting Suite reports
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
View more...
Comments
