- This topic has 9 replies, 1 voice, and was last updated 9 years, 5 months ago by blackhole.
12th August 2011 at 09:26 #66916blackholeGuest
Is there anyone have experience in the ratio UL TBF request/DL TBF request. The ratio is around 2.5-3 for other vendors, but in Alcatel network in our country, this ratio is from 4.5-5 . I cannot explain why the number of UL TBF request is always higher than DL TBF request? And what should be the mean ratio between them?13th August 2011 at 07:46 #66917pixGuest
the dl tbf might not be released in ALU as often as it is in other vendors. This is due to specific algorithms that tend to “stabilize” the usage of TBF.
I don’t know about a typical value for the ratio ul/dl though.
pix13th August 2011 at 15:19 #66918blackholeGuest
Can you make clear about the algorithm and the difference between the other vendor? Because in our network, the ratio number of TBF/traffic is quite high, so subcriber request many TBFs but the traffic only the same with other vendor ( Huwei to be specific), which has much lower TBF requests than us, so is it also a algorithm of ALU? In fact, I don’t know much about GPRS system as well as other vendor but ALU.
Anyway, thank you for always reply to my question in this forum. It’s very happy to log into the webpage and see your answer. 🙂14th August 2011 at 17:36 #66919pixGuest
i’m always interested in your questions, so thank YOU for posting your questions ! 🙂
at this point i think you need to post numerical examples of number of UL TBF and DL TBF in each network, at the same hour of the day (a typical rounded value is enough)
then check the average TBF duration, in ul and in dl (in Huawei and in ALU).
In which release of ALU are you? B10?
If you have such a big difference with Huawei, then I would suspect that there is more “core” signalling in ALU than in Huawei.
–> it might be interesting to check the amount of GMM/SM signalling on both networks. Could you check that with your NSS qoS colleagues?
Then I could help you investigate the “TBF delayed release” timers in ALU, and ensure they are set at the same values than in huawei… it might be tedious…
pix17th August 2011 at 03:50 #66920blackholeGuest
Let see the statistics of 2 centers of our network ( which the same traffic for GPRS/EDGE) for example:
Center4 ( Huawei and Ecrisson equipment):
– Number of DL TBF Requests: 44,294,095
– Number of UL TBF Requests: 80,865,806
– Traffic: 289,651
– Traffic/TBF: 2.3142
– TBF UL/DL: 1.8256566
Center6: ( almost ALU equipment):
– Number of DL TBF Requests: 47,930,728
– Number of UL TBF Requests: 214,679,689
– Traffic: 242,707
– Traffic/TBF: 0.9242
– TBF UL/DL: 4.4789574
I’ve checked some other BSCs in detail and ALU UL/DL TBF is always from 4.5-5, why other BSCs belong to other vendor is much smaller. Do you think such a ratio should be considered? Our KPI is a bit less than other vendor, that’s why our customer ask : why too many TBF established why traffic is the same.17th August 2011 at 08:56 #66921pixGuest
ok, there is too much UL TBF requests in ALU, and I would suspect:
1/ too much GMM/SM signalling -> can you check this with SGSN QoS team?
2/ UL TBF which are (normally) released too early. They should be extended. Can you verify the settings of these parameters:
I assume you are in B10?
pix18th August 2011 at 10:02 #66922blackholeGuest
Yes, we are using B10 and don’t activate Extended_Ul_TBF.
The value of your required Paramters:
EN_EXTENDED_UL_TBF: eutm NOT USE
N_POLLING_EUTM_LIMIT ( i cannot find this paramter 🙁
So is it the reason that we have so many UL TBF (because UL TBF is release so early?). Should we enable this Feature (because I see some topic in this forum says that TBF behaviour will be worse when we enable Extended UL TBF.
About the signaling, I will try to ask them to check.
Thanks for your advice.18th August 2011 at 12:09 #66923pixGuest
yes, you should use EUTM, but first you must check if EUTM is already used in your other vendors’ networks. If it is not, then it is fair to compare ALU and the others as they are. And in this case, yes, there are too many UL TBF in ALU.
But if the others have it activated, then it is not fair to compare ALU kpi with the others 🙂
EUTM can degrade UL TBF KPI, but by reducing the UL extension time, you can strongly limit the KPI degradation. I think it is really a feature that should be enabled.
pix29th August 2011 at 03:39 #66924blackholeGuest
We activate this feature and TBF Request number for UL decrease a lot.
However, I notice that from that time, the number of TBF UL and DL reallocation Success rate for trigger T3 and T4 decrease a lot. Before the overall success rate is 45%, now only 20% for both ul and DL. But trigger T1 and T2 is OK. Do you think TBF reallocation success rate is too bad? And how to increase this?29th August 2011 at 10:32 #66925blackholeGuest
As information from NPO, the T3 and T4 resource allocation success rate is very low are mostly because of Preparation fail.