pmNoFailedRabEstAttemptExceedConnLimit // pmNoFailedRabEstAttemptLackDlChnlCode

[islam wagih]

Dear Experts,
kindly support as I have been conflicted between these two counters;

pmNoFailedRabEstAttemptExceedConnLimit // pmNoFailedRabEstAttemptLackDlChnlCode

also how we can solve rejections due to "pmNoFailedRabEstAttemptExceedConnLimit" ?

[wolverine]

These are caused by the admission limits controlled by the parameters..

sf8Adm (384 kbps)
sf16Adm (128 kbps)
sf32Adm (64 kbps)

or

sf4AdmUl (384 kbps)
sf8AdmUl (128 kbps)
sf16AdmUl (64 kbps)
sf64AdmUl (16 kbps)

depending if it is UL or DL. But my understanding is that this is not real blocking. If a particular Admission limit for SFx is reached the connection should still be set up on SFy. Even when all SFs are full, we could still set up on FACH.

As such a more accurate Accessibility formula would subtract pmNoFailedRabEstAttemptExceedConnLimit from the failed attempts.

[islam wagih]

Dear Wolverine,
thank you for your reply, I'm still conflicted; how does it differ from "pmNoFailedRabEstAttemptLackDlChnlCode"?

[wolverine]

pmNoFailedRabEstAttemptLackDlChnlCode or the equivalent in the UL peg when there is generic SF shortage related to traffic and not the admission limits described above.

Assume this example.

sf8Adm = 6. So you allow up to 6 SF8 in the DL.

You currently have on the system 5 x SF8 + 5 x SF16.

Another request for SF8 comes in. This will be blocked because there are no SF8 branches free. Counter pmNoFailedRabEstAttemptLackDlChnlCode will peg. Counter pmNoFailedRabEstAttemptExceedConnLimit will not peg as you are still below the limit of 6 x SF8.

[islam wagih]

thank you sir, I'm about to get the idea but if there is more clarification about "pmNoFailedRabEstAttemptExceedConnLimit" I will be very grateful.