Hi All ,
I have a question on High Paging Discard failure on LTE RAN Side.
Vendor is Ericsson.
Any Ericsson expert know about the debug MTD Counter trace analysis?
Mentioned below for your reference.
My network most of failure are pagged under “noOfPagDiscTimeout”.
Does anyone have idea why this counter is pegged and what could we do to mitigate it?
Any other suggestion also welcome.
maxNoOfPagingRecords?
And BW of the EUtranCell?
It’s already at max value 16.
That is the problem, no more space to adjust. 
20 Mhz.
Paging should be in PDCCH I think.
Maybe CCE congestion or PDCCH congestion?
For Huawei: L.Paging.Dis.PchCong
S1 links of a large number of eNodeBs in a tracking area list (TAL) are intermittently disconnected.
The number of eNodeBs in the planned TAL is too large. Precise paging is not used on the MME.
A large number of L.Paging.Dis.PchCong (number of paging messages discarded due to paging channel congestion in a cell) counter values are measured and the paging congestion cannot be resolved for a long time.
Improvement measure (Cell bandwidth is greater than 5M)
MOD PCCHCFG: LocalCellId=xx, PagingTimeoutDiscardTimer=6;
CFI mode already set auto 3.
Internal value-5.
I think its a best value for CFI Mode.
Paging discard timer currently at Ericsson default value 3 Sec.
At eNB side.
Also paging discard timer need to set equal or less then the value in MME.
Based on Ericsson guidelines.
And to change the timer at MME is always a challenge.
Btw why are you checking this counter?
Are there any complaints of missed calls or delay is voice calls?
There are always some volume of discarded-paging because a MME always page the TAC so cells in that TAC will page and only one where UE is will respond.
No Complaint.
But customer asking to reduce paging discard.
Because before they adjust the max number of paging records from 8 to 16.
And problem resolved.
But now this sites already 16. 
So no more weapon to optimize.
Paging discard per RAN should be 0.
I think is ok to improve it.
Ask for TAC split.
Near by all sites have 0 paging discard.
Only this one site have problem.
May be customer will not agree for TAC split, first he will asked find root cause.
Maybe a problem of the baseband then.
Try a diff.
nB = 1/16 … to low I think.
Check with baseline or planning data.
You can reduce paging discard but can never make it zero.
Increase the paging timer will reduce pages and will reduce discard but this will adversely affect services.
Yes, agree.
But network baseline is 1/16.
nB=T Used to calculate the number and position of Paging Occasions (PO) and Paging Frames (PF).
The numerical value of nB depends on the value of the defaultPagingCycle (T) and can be set to one of the following values:
4T, 2T, T, T/2, T/4, T/8, T/16, T/32.When nB is set to T, 2T or 4T, it determines the number of POs per PF, and the PO position in PF.
When nB is set to a value smaller than T, it affects the System Frame Number of the PF, the position of PO in the PF, and also distribution of UE into groups with the same PF.
When nB is set to smaller value, amount of groups is smaller, but amount of UEs inside each groups is larger. When nB is set to a larger value, amount of groups is larger but amount of UEs inside each groups is smaller.
If categoryMAccess is enabled and nBBr is set to the default value (NOT_PRESENT) then further restrictions apply. If highestSupportedCeLevelBr = 0 then nB should be selected from the following available options (T, T/2, T/4, T/8, T/16, T/32) due to the half duplex nature of Cat-M devices. If highestSupportedCeLevelBr = 1 then nB should be selected from the following available options (T/8, T/16, T/32) due to repetitions.
Dependencies: nB=T4 can not be used in combination with specialSubframePattern = 5 on MO EUtranCellTDD, see 3GPP TS 36.213.
Takes effect: After all the cells in the RBS have been locked, and subsequently been unlocked.
I checked near by sites. All have same setting of nb with no paging discard.
I think it not so easy to get the root cause until we review the trace from Core side.
But moreover if we have any other weapon to reduce it , even it Work
At list something we can feedback.
Yes.
But I think there is a problem with this baseband.
Did you already restart the baseband?
I did the Cell lock/unlock today, but no recovery.
Tomorrow will re-start.
Also today I have activated the priority paging. Let me see if can improve or not.
We can not increase the paging timer directly in E\\ system
Have dependency on MME side, check below discription:
pagingDiscardTimer=3{1…30} The length of time a received paging is retained or queued in the RBS before it is discarded. The timer should be set to the same (or smaller) value as the paging resend timer in MME (T3413). This setting prevents the RBS from retaining or sending an old paging after the re-sent copy is received from the MME. Specification: 3GPP Rel-13 TS 36.331
T3413 belong to MME Side need to make RAN side either equal or smaller
You was absolutely right.
This problem is related with nB setting mismatch with baseline setting 2(t).
Paging discard count turn to zero.
After i changed nB from to T.
Thanks a lot for your valuable suggestions.
Keep in touch brother.
We are working on Ericsson platforms.
It’s good to talk always. 
