1 out of 1 members found this post helpful.
Re: PS Paging Improvment on E//
Hi Dear,
Reports of PS paging SR from RAN and from CS core would be different. From CS core ,Paging SR would be higher than the paging SR report collected from RAN.
I will concentrate on how to optimize paging at RAN level when having a smartphone profile
Imp counters
a. pmCnInitPagingToIdleUe
b. pmCnInitPagingToIdleUeLa
c. pmCnInitPagingToIdleUeRa
a. pmNoPageDiscardCmpLoadC - deletion to due high processing in MPLoad
b. pmNoPagingAttemptUtranRejected - rejected by UTRAN
The networks where you have high number of smartphone users, then you need to be very technical while designing the number of Routing areas per RNC
Increasing RA per RNC wourld reduce the paging load per cell per sec but too many RA per RNC may increase the signalling load of SGSN
Here are the general recommendations:
Keep the paging load per cell per sec < 100 ( check the value of pagetype1 counter and divide by number of cells in that RA and divide again by the value of parameter "pageretransmission" which is generally set to 2 "
Keep 1 LAC for 60000 VLR subscribers per LAC in an RNC otherwise have 2 LAC
In Networks where smartphone users are in good count, the 1st thing to suspect the dimensioning of Paging parameters at RAN level are below
pmNoPageDiscardCmpLoadC - deletion to due high processing in MPLoad
b. pmNoPagingAttemptUtranRejected - rejected by UTRAN
If both these above counters are pegging high especially pmnopagingattemptutranrejected, then you need to reduce the paging load per cell per sec and the solution is to split RA further
In smartphone dominated networks, generally 85% percent of Paging (pmCnInitPagingToIdleUeRa) is on RA and 15% is on pmCnInitPagingToIdleUeLa.
SGSN pages on basis of LAC+RA
CS core pages on basis of LAC only
hence splitting RA only would give you more releif from paging load at cell level
For more details send me e=mail at deepakels@gmail.com
Please add to reputations if you like this post
BR//Deepak
Bookmarks