- This topic has 24 replies, 1 voice, and was last updated 7 years, 8 months ago by
.
-
Posts
-
As said below
No respnse from MS caused by:
– Invalid assignment (no valid RLC/MAC block)
– cell change or radio failure
– timer expiry befor MS responseAnd after investigation:
*The last causes can be results of frequency interference,
*We found this kind of fail (No response from MS) generally where no hopping is activated for EDGE TRX
*Set a new cleare frequency is one of solutions.
Best Regards & Sorry for late.
Please to enrich with your coments.
loss of communication happened during dl tbf establishment . Plese let me know if any one has idea about this issue
hi kaushik, do you mean TBF Drop?
Hello
SUPPORT IN TBF COUNTER DEFINATION
IN ZTE FORMULA THERE IS NO RELATION BETWWEN TBF EST RATIO AND PDTCH CONGESTION AND CELL AVALIBLTLITY
I.E. TEX AVA =70 % AND CONGESTIN 15% tbf est % 99 , while in huawei formula there is relation , so we push zte to modify their formula
So your advice !Ayat,
please provide more details on the formula.
Normally availability issue implies PDCH congestion (if remaining PDCH are not enough) and therefore TBF congestion. having TBF congestion means TBF assignment failure due to no resource. so for sure there is a relation between PDCH congestion and TBF success rate but not necessarily availabity…LEMAURE
Ratio of Uplink TBF Establish Link successfully (%)
=([Number of GPRS UL signaling TBF establishment]+[Number of EGPRS UL signaling TBF establishment]+[Number of GPRS UL data TBF establishment]+[Number of EGPRS UL data TBF establishment]+([ Number of GPRS UL TBF resource reallocation requests due to LLC transmission]-[ Number of GPRS UL TBF resource reallocation failure due to LLC transmission])+([ Number of EGPRS UL TBF resource reallocation requests due to LLC transmission]-[ Number of EGPRS UL TBF resource reallocation failure due to LLC transmission])+([ Number of GPRS UL TBF resource reallocation requests due to DL TBF establishment]-[ Number of GPRS UL TBF resource reallocation failure due to DL TBF establishment])+([ Number of EGPRS UL TBF resource reallocation requests due to DL TBF establishment]-[ Number of EGPRS UL TBF resource reallocation failure due to DL TBF establishment])+[ Number of GPRS UL TBF resumption in extend uplink state]+[ Number of EGPRS UL TBF resumption in extend uplink state])/ ([Number of GPRS UL TBF establishments in release state]+[Number of GPRS UL TBF establishment with existing UL resource]+[Number of GPRS UL TBF establishment requests on PACCH]+[Number of GPRS UL TBF establishment requests on request CCCH/PCCCH]+[Number of EGPRS UL TBF establishments in release state]+[Number of EGPRS UL TBF establishment with existing UL resource]+[Number of EGPRS UL TBF establishment requests on PACCH]+[Number of EGPRS UL TBF establishment requests on CCCH/PCCCH]+[ Number of GPRS UL TBF resource reallocation requests due to LLC transmission]+[ Number of EGPRS UL TBF resource reallocation requests due to LLC transmission]+[ Number of GPRS UL TBF resource reallocation requests due to DL TBF establishment]+[ Number of EGPRS UL TBF resource reallocation requests due to DL TBF establishment]+[ Number of GPRS UL TBF resumption in extend uplink state]+[ Number of EGPRS UL TBF resumption in extend uplink state])Hi Ayat,
PDCH congestion is related to assigning the physical timeslot to PDCH usage. But a TBF is only a “logical” allocation on an existing PDCH.
In other words, TBF can still be established on existing PDCH, (I forgot how many TBF can be allocated to one PDCH, it’s between 8 and 12 I believe)
Of course it impacts the end-user throughput but prevent congestion.
It’s also possible to change the PDCH allocation of a TBF : TBF will be changed from using 3 PDCH to 2 PDCH for example.
That will allow the 3rd PDCH to be used for a new TBF.ZTE formula looks correct. Maybe their counters are not trigerring properly ?
Cheers
pixHello pix
I am still confused about the relation as i understand In huawei performance there are clear relation between bad Trx Ava% and pdch congestion and tbf est. Rate%
and huawei fromula is not like zte there is no more detils in huawei just tbf success / tbf request
In zte tbf est success % is alawys good > 96%
I hope you got my ideahi ayat,
Yes i understand what you mean. I agree it is very surprising, and the most probable answer is that ZTE is not properly pegging the number of TBF request. They may be pegging a TBF request (counter) only after the TBF has been allocated (hence, no congestion).
That’s the obvious answer.
Now there’s another possibility : it may be that ZTE default GPRS parameters allow for a huge piling up of TBF over the same PDCH, which allows to minimize TBF congestion at the cost of TBF throughput.
You can look at followning kpi to be sure :
* avg PDCH per TBF during BH (will be around 1)
* avg TBF per PDCH during BH (will be higher than 6)
* avg throughput per TBF (will be around 10kbps)
* avg throughput per cell & dl volume transmitted (will be comparable with huawei cells)Other thoughts :
– check the specific counter that pegs when there is tbf congestion (like a number of tbf block, or a time during which there is tbf congestion). Compare that value with number of tbf success, and do you own ratio.
– maybe all tbf congestion is counted in Uplink, and you’re looking at downlink Kpi.That’s all i can think of 😉
Cheers
- The forum ‘Telecom Design’ is closed to new topics and replies.
