Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

ALU: DL PDU discarded due to congestion

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
  • #68434

    Good afternoon, dear GSM experts!

    Recently I ‘ve started with new BSS equipment – ALU (GSM). My field is GPRS/EDGE. And this field has been absolutely untouched as far as I see…

    I’ ve found several cells in the center of one city which show in the evening (BH) some increasing of counter P10 – up to 12-18% (from day to day).

    P10 – Number of DL LLC bytes discarded due to congestion.
    1) Whenever the PDU life time of a DL LLC PDU expires, the counter is incremented by the number of bytes of the LLC PDU. 2) Whenever the MFS receives a DL LLC PDU and the buffer in reception on the Gb interface is full, the counter is incremented by the number of bytes of the LLC PDU to discard.
    3) Whenever the MFS receives a DL LLC PDU that needs to be discarded due to 1st or 2nd level of GPU buffer congestion, the counter is incremented by the number of bytes of the LLC PDU to discard.
    4) When the number of DL PDU in the queue is higher than PDU_REORDER_INHIBIT_THRES_GP(U) (BTP parameter) during a TBF reestablishment following an abnormal TBF release, the remaining DL PDU are discarded and the counter is incremented by the number of bytes of the LLC PDU to discard.

    My questions:
    1) DL LLC PDU lifetime – which entity (SGSN or not) does define/change this value?
    2) Can the BVC flow control mechanism help in order to decrease P10? Now it is disable (T_Flow_Ctrl_cell = 0).
    And what is a good value for this parameter (T_Flow_Ctrl_cell)?

    Thank you very much for help in advance.

    BR, Sommer


    hi sommer,

    i’ve worked with alu equipments a lot, but my memory is not perfect..

    the pdu life time -> check out the MFS parameters. If you can see it there, then fine… otherwise it’s probably a SGSN parameter.

    BVC flow control -> i never had to use this mechanism. There are 2 levels of flow control : per MS and per cell. It is probably a fair idea to use a flow control per cell.
    the flow control is controlled by several parameters (at least 2 main parameters). Unfortunately, I forgot the way it works… 🙂 look for all parameters that contains “flow_control” and post their definitions here, i will then be able to help.

    However I must say that your main issue is a lack of GP capacity !
    If you check the indicators per GP (CPU load, Ater congestion) you might have very bad surprises. You should plan to add 1 or 2 GP boards for each BSC connected to the MFS, and add some Ater-ps interfaces.

    The mechanisms you are describing are just workaround, yet in the end the end-user throughput will still be very degraded. You’d rather work on the root cause : lack of GP, lack of Ater-PS.

    If you need, I can help you further. I’d just have to dig in my ALU documents…



    Thanks a lot for your kind help, I really appreciate it!
    According to flow control mechanism – I’ve found one parameter for MS flow control and one for BVC flow control:
    T_Flow_Contorl_Cell = 0
    T_Flow_Contorl_MS = 10

    I’m thinking of changing the first one – from 0 to 5 (taking into account a recommendation T_Flow_Contorl_Cell < T_Flow_Contorl_MS and would be very interesting in your opinion. As for Ater load and GPU load – for that particular BSC I found 9 days (not consecutive) during the last month with Ater congestion time which was about 5-19 seconds (BH).But very often I see that Aters are in high load state – so I think it’s reasonable to add at least 2 Ater PS… What do you think? Oh, and one question about Ater PS – please 🙂 We’re going to activate a new feature – BSS Paging coordination. As I understand the only dangerous is suppose GSL overload because of increasing of signaling between MFS and BSC – is it correct? I have been trying to find in NPO some indicators like GSL_load or GSL_cong – something like this but all that I’ve detected is the number of messages on GSL link – LAPD messages. So my questions: - How we can estimate the load of GSL? What is the usually used thresholds for this parameter? Once more for you detailed reply and help! Good night! BR, Sommer



    i’m afraid i can’t help further on the flow control : i will have to dig into my ALU specs, and today is not the day (i’m going on holidays 🙂 ).

    I am quite certain there are other parameters related to flow control, but maybe they are system parameters. Anyway, do try the values you show. You might be the 1st one on earth to do that 😉

    Ater in high load will VERY strongly penalize the GPRS throughput from end user perspective. By default the Ater enters the HIGH LOAD state when the load exceeds 70% (that’s changeable through the “HI ATER LOAD” parameter).
    A good thing would be to increase this threshold to 80% and add the 2 extra Ater PS. Indeed, 70% seems a bit harsh when you have many Ater PS / GP board.

    after that -> ensure that Ater high load time is < 100s at BH. (for example) As a consequence, more traffic will be handled by the GPU though. So your GPU CPU might get overloaded ! regarding the GSL - yes, there is a very simple calculation based on the GSL messages and volume indicators. I will share it here when i come back from holidays. However, keep in mind that you only need 2 or 3 GSL timeslots per GP board. Just be on the safe side, and put 3 GSL 🙂 3 GSL = 3*64kbps, and that is normally plenty enough to handle the BSS paging coordination. Check out the BSCGP indicators -> BSCGP is the protocol carried by the GSL.
    In NPO you must find 2 network objects related to GSL. One of them is contains “lapd”, and the other “GSL”. (network object = cell, BSC, TRX, etc, on the left side of the screen)

    I’ll give you more info in about 2 weeks, if you can hold on…



    Thank you for very detailed answer!

    I wish you the very best holidays 🙂 Of course, I have time and these two weeks I’ll spend in researching in the direction you’ve pointed 🙂 so I hope I’ll more interesting question when you come back!

    Just one thing – thanks for your explanation about practical meaning of parameter Ater_High _load because I didn’t worry about it before : ) I couldn’t imagine it is so dangerous. After some exploration I can say that almost all ALU BSC need additional PS Aters.

    Once more I wish you pleasant holidays!



    hi sommer, holidays are over now. I will try to help further. Do you have an email @ ?


    Hello, dear Pix!!

    I hope that your holidays were excellent 🙂

    Yes, of course !! 🙂 my e-mail is

    And, sorry but some questions 🙂

    – Does MFS as network object have an Edit menu? I can’t see it! Is it something wrong with my rights?
    – For BVC flow control I’ve found only that one parameter…. You said that it might be because all others are system ones – how can we see them?
    – According to GSLs – in NPO I’ve found an indicator NB_GSL (GGSLN) and it shows very strange values: 12, 16, 24, 32 (hourly) for different BSCs – are they OK? But as our OMC-R engineer say they always create 8 GSL for each GPU . So I’m a little bit confused…
    – And the last – is it correct if I I say that the protocol used on interface between BSC and MFS is LAPD? So we should mean it when we collect and analyze trace (for example)? Or other protocols are also used?

    Thanks a lot in advance!

    BR, Sommer!


    hi sommer,

    I’ll contact you by email now, give me one or two days 😉



    Good morning!

    Many thanks in advance

    Have a nice day!

    BR, Sommer!


    Hi Pix,

    are you still active for same kind of issue?

    in ALU 2G, we are facing ‘DL LLC Cong Bytes’ but as per NPO, we dont have congestion in Ater & GPU or any radio side,

    what do you suggest in this case?


    Hi AK

    Just replied on the other topic about this… please have a look. A colleague of yours ?

Viewing 11 posts - 1 through 11 (of 11 total)
  • The forum ‘Telecom Design’ is closed to new topics and replies.