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

T_NETWORK_RESPONSE_TIME in Alcatel

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #63032
    lily
    Guest

    Good evening!

    Dear Alcatel experts!
    Dear Pix!

    Recently we got recommendation (= instruction) from our main head-quarter to change parameter T_NETWORK_RESPONSE_TIME from its default value = 1,6 sec to 0,6 .. 0,7 sec. As they said it should be done to decrease TBF drop rate (DL). To be true, I don’t see clear interconnection between these two issues. Correct me, please, if I’m wrong. Of course, we’ll test it at first in a small area, but as for me it’s bad idea anyway :))

    So, I have 2 questions:
    1) Which value is the most widely used (except default = 1,6 sec)?
    Maybe someone have experience in tuning this parameter – I would be very very grateful for such information ๐Ÿ™‚
    2) Dear Pix, in the docs from that course you taught in kiev this year on page 129 I found the next comment:
    “T_NETWORK_RESPONSE_TIME corresponds to the time difference between a command sent to the SGSN and the response received at the MFS. The default value is 700ms but it can be set at OMC-R level and can be tuned according to Gb traces”.

    But 700ms isn’t a default value, maybe it is a recommended value?

    And about Gb traces – could you, please, explain in more details – how should we performed those traces in order to get the objective value for parameter T_NETWORK_RESPONSE_TIME?

    Thanks a million!
    Best regards,
    Lily

    #63033
    Pix
    Guest

    Dear Lily,

    T Network Response Time is used to delay the DL TBF release. If it is = 1.6s, it means the TBF DL is kept 1.6s even though the last packet have been sent.

    It is a good feature. Almost a mandatory feature..

    Basically, after the MS received DL data, the TBF stays open so that DL or UL data can be sent again quickly. It greatly improves the subscriber’s perception of the service : high reactivity, quick response…

    It could increase TBF drop, because , basically , the TBF is used for a longer time. The chances of drop are increased proportionally to the duration of the TBF. I guess you get the point ๐Ÿ™‚

    In the training, you get the detailed procedure of the delayed DL TBF release.
    The comments are probably a little old, and the value 0.7s is perhaps an old one. It is the minimum value : it is usually the round trip time between MS and Internet. Keeping the TBF open for this time is the least you can do, to avoid releasing and reestablishing TBF’s all the time. (most downloads are followed by other uploads and again, other dwloads)

    I’ll try to dig it further if you need, and as usual, kindly let me know about your experiments. (I never fine-tuned this parameter)

    regards,
    pix

    #63034
    lily
    Guest

    Dear Pix,
    Thanks a lot for such a quick reply!

    Yes, I understood your thought (and absolutely agree) – that the only reason for TBF drop decrease (with T_NETWORK_RESPONSE_TIME < 1,6) is the fact that probability for TBF drop is lower for shorter TBF delay time. And we’re going to find out it’s true or not :))))) We decided to test the next set: 1,6 sec – was used 1,2 sec 1 sec 0,8 sec 0,6 sec Each value will be used during 7-8 days. I’m also wonder why nothing was said about throughput and resources utilization – it would be logical (as for me) because if we released resources of the cell earlier, we could use them more effectively. But we’ll see it with our own eyes:) … Those docs are excellent, I was delighted when I saw them ๐Ÿ™‚ The best from Alcatel (in contrast with docs for B7 / B8 and B9).Nice to read before bed ๐Ÿ™‚ I’m just kidding, they’re really good :)))) Yes, of course, I’ll share all our results. I think after all changes we’ll see, need we Gb traces or not. Good night! Once more – many thanks! Best regards, Lily

    #63035
    pix
    Guest

    hi lily ๐Ÿ™‚

    i’m in a hurry…
    Gb traces are used to find out the real network response time, that’s all… IMO, it is useless ๐Ÿ™‚

    The TBF is not a physical resource ! When it is released, it doesn’t provide more capacity to other users… If no data is sent, delayed TBF is active but “empty” = not using any of its PDCH. The PDCH are therefore used by other TBF.

    So, no, the quicker TBF deallocation will only decrease the drop. I must emphasize that you will degrade the QoS from subscriber point of view.
    Drop = better
    Subscriber = unhappy because service is slower

    Unfortunately this “reactivity” is not seen in the NPO’s KPI. (however, have a look to GPRS indicators with the name “active” “delayed” “optimal”), whereas the drops are clearly seen.
    Drops are not everything !

    I’m going to russia on monday, but it is not for your company ๐Ÿ™‚

    regards
    pix

    #63036
    michel
    Guest

    hi lily.
    i am new in gsm.
    i really need a good documentation about gsm and NOKIA BSC3i.
    please send me.
    jack_erlang@hotmail.com

    #63037
    lily
    Guest

    Dear Pix,
    Thanks a million ๐Ÿ™‚
    I wish you good luck in your trip! But another company… ๐Ÿ˜‰

    and the greatest shame on me ๐Ÿ™‚ I mixed up everything: Two (no, three) peaces of homework :)))) until the morning :))))

    I wish you a pleasant stay in Russia. Oh, have you been there before? (It would be very interesting to hear your impressions:)

    Dear Michele,
    Unfortunately, I can’t help you with docs about Nokia BSC – we use only Alcatel BSS.
    But I sent you some *vendor-independent* books – introduction to GSM and some basics.

    Best regards,
    Lily

    #63038
    michel
    Guest

    hi lily
    i never get your docs!!!

    #63039
    michel
    Guest

    thanx a lot lily
    i got it
    i am very very happy

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