Thanks Thanks:  1
Page 2 of 2 FirstFirst 12
Showing results 11 to 12 of 12

Thread: PS Paging Improvment on E//

  1. #11
    Junior Member Reputation: 6
    Join Date
    2011-10-01
    Posts
    55


    Default Re: PS Paging Improvment on E//

    Quote Originally Posted by Muhammad Imran Rafique View Post
    For PS, reduce your DRX cycle length to 6 as for CS. then definitely there will be improvement.
    Thanks Muhammad, can you be more specific about the impact of changing the DRX cycle to 6?
    Knowledge is the true organ of sight, not the eyes. Kindly give me reputations.

  2. #12
    Junior Member Reputation: 18
    Join Date
    2012-08-04
    Posts
    10


    1 out of 1 members found this post helpful.

    Default 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

Bookmarks

Posting Rules

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •