- This topic has 7 replies, 1 voice, and was last updated 12 years, 9 months ago by pix.
14th July 2008 at 16:15 #53060OptimGuest
I have an Ericsson cell with low SD setup success rate. I did VSWR test, no problem mentioned. I changed the dTRU and no change. No problem found after Abis capture. What could be the problem?15th July 2008 at 19:03 #53061peyoGuest
sds are on BCCH?
what do you exactly call sd setup SR?16th July 2008 at 07:17 #53062OptimGuest
SD are on other timeslot. SD setup SR is (No on SD attemps)/(No of SD request – (SD fail due to cong))
NB: We have 2 TRX on this cell, 1 TS BCCH, 3 TS SDCCH (24 SDCCH) and 12 TCH16th July 2008 at 07:21 #53063OptimGuest
Sorry the formula oF sd ssr is No of SD success/ (No SD attemps – (SD fail due to cong)).16th July 2008 at 13:07 #53064PixGuest
the qos counters are based on timers and messages generated on the Abis interface.
Therefore, the SDCCH failures you’re measuring MUST be seen on the Abis trace you have done ! If you can’t see the problem in the trace, then you have to look better 🙂 Or throw away your QoS tool…23rd July 2008 at 07:58 #53065cyclopsGuest
Since SCDCCH congestion has been excluded so the main focus is on air interface and abis interface. You have said that there is no problem after abis capture, my reccomendation are:
1. Please check quality of air interface e.g interference level, there is possibility that SDCCH loss due to bad quality of air interface.
2. Check access paramater e.g accmin, too low value accmin allows low signal MS to access the network. at this case there is possibility in SDCCH loss.
3. Move the SDCCh channel in better quality of TRX. As reference you can use measurement from mrr in ericsson.
4. from the SDCCH channel allocation (24 channel), i guess that there is a high load of using SDCCH (maybe it is caused by high LUP or high SMS or others), so please also do checking congestion on abis, due to implementation same feature such as abis multiplexing or abis concentration
rgds,24th July 2008 at 11:16 #53066OptimGuest
Pix and Cyclops, thanks for your response.
Here are the actions I did:
1. Abis capture: Subscriber are taking traffic near the cell, good RxQual, good RxLev. Note that HSN is activated. So I suspect hardware issue.
2.Change dTRU: no change on stats.
3.Check VSWR: no problem on feeders.
4.Swap 2 SD on 1800: No change on stats.
5.Change dTRU position (Slot): The TCH assign get low, so need to revert back.
6.Drive test: I don’t have good knowledge on TEMS but I got 2 blocked calls over 40 calls attemps and many others call are switched on 1800 during call setup (As I have 2 SD on 1800). But on stats I still have 20% of SD setup success.
7. Revert back all the SD on 900 and change the combiner.
Now I’m waiting combiner to be changed and see the stats.
We also have some issues on the transmission (Abis freezing) but it is very rare.
I didn’t check access parameter as the problem appeared without any change made on the cells or its neighbours.
BR24th July 2008 at 11:37 #53067pixGuest
to summary your problem : (No on SD attemps)/(No of SD request – (SD fail due to cong)) = 20%
it means that for instance, there are 1000 CHANNEL REQUIRED on the ABIS interface, and only 200 IMMEDIATE ASSIGNMENT.
Did you see this in the Abis trace ?
If that’s the case : could you isolate the CHANNEL REQUIRED that are not followed by the IMMEDIATE ASSIGNMENT (check the request reference in the channel required -> the same reference should be used in the I.A. that answers this C.R.)
In those un-answered Channel required :
— >are they a retransmission of a previous channel required ? (you know that the MS will transmit the same channel request max three times)
–> what is the cause value (emergency call ? normal call ? GPRS ?)
–> what is the time advance ?
… frankly the solution to your problem lies in the Abis interface ! just look deeper…