- This topic is empty.
15th May 2017 at 10:03 #70017winnieGuest
Need help on this matter
Planning to reduce TRX in the NW to reduce the power consumption
Need to know if there is any counter related to PDTCH available channels just like the TCH available channel
Need to make the dimensionning accordind to TCH & PDTCH need to make sure it won’t cause any congestion after.
Is there anyway to relate the Data volume and the nber of PTCH that were in use? This is urgent. Thanks18th May 2017 at 05:48 #70018pixGuest
well the first thing to do is tell us which vendor you’re using. Yes, each vendor provides several counters related to the number of pdch_used and tch_used, and perhaps even the number of peak tch/pdch used in the hour.
How mature is your network ? Do you have U2100 and U900 deployed continuously along your 2G sites ?
If that’s the case, you could probably decide to reserve only 2 static PDCH (in your capa analysis) on top of the required nb of TCH. That provides enough capacity for the few users that are still connected to 2G.
On the note of power reduction, there are features that switch off TRX when they are not used, and decrease by few dB’s the TRX0 whenever possible. So you may want to consider that as well.
pix21st May 2017 at 18:50 #70019winnieGuest
Thank you so much Pix
Vendor is Huawei and yes we have U2000 deployed
“reserve 2 static PDCHs + number of required TCH” my question on this point is what about the dynamic PDCHs? Am I not going to create congestion on the data side as I will have reduced the TCH that could potentially switch into PDCH in case they are needed?
I actually want to reduce the TCH to the minimum needed taking into consideration a potential increase of 30% of traffic…24th May 2017 at 22:26 #70020pixGuest
I’m not totally clear about what you want to achieve. If you want to minimize TCH occupancy, you must switch-on Half Rate as much as possible. HR will halve the TCH occupancy.
VAMOS is also another feature, but much more controversial. You have to try it out first. 4 calls are allocated onto 1 ts, at best.
Static PDCH cannot be preempted by TCH, but dynamic PDCH can. So whenever TCH traffic gets too high, PDCH will be deallocated. This will not impact the GPRS that much because one user transfer (TBF) is actually using several PDCH (let’s say 4).
What I’m saying is that removing 1 PDCH just means this TBF will be re-allocated onto 4 different PDCH. Those PDCH are not providing as much throughput as the previous ones because other users (TBF) will already be used them.
So our user will experience some throughput reduction (due to pdch sharing), but nothing horrible.
It’s not congestion, see it more like “compacting” all gprs users onto less timeslots.
btw I’m currently doing some GPRS optimization right now, and here are what we’re trying :
100% half rate
increasing the amount of TBF that are packed on a PDCH (call it “increasing the PDCH utilization”)
forcing small volumes TBF to be allocated on only one PDCH (One Slot TBF reservation), the goal here is to allocate all the Routing Area Updates on 1 PDCH. Beautiful results.
Ensure that MCS9 is available, and ensure your Abis is not congested.
Basically, read huawei doc about all their GPRS features, and turn them all on 🙂