- This topic has 11 replies, 1 voice, and was last updated 9 years, 2 months ago by
.
-
Posts
-
Hi,
Does anyone have some feedback about this indicator (available from B10 onwards only) :
– sometime this indicator is way worse than the normal CSSR : for which reason ?If anyone troubleshooted such issues before, please share !
Thanks
PixHi,
Can you share the counter level formula for this indicator?
–
ThreepwoodHi,
we are using same formula for E2ECSSR and it is showing normal values.
According to my troubleshooting, Alcatel’s indicator for E2ECSSR (B10) is having missing values for one of its counter MC191. Replace it by C191 and it will show normal values. This issue needs to be checked at Alcatel for missing values of MC191.
Regards,
F.R.hi fr,
thanks for the very useful input !
regards
pixDear FR/Pix,
I am sorry but that is not true.MC191 is a new counter in B10 and it tells u the Mobile Terminating SMS connections on SDCCH(previously we couldnt not have the split of MT SDCCH(MC01) like we have for Mobile originating(MC02)but now with this new counter we can subtract this from MC01 to give us all the Mobile Terminating SDCCH’s used for only Call Establishment and thats what is used in the new E2E CSSR Formula.In my network, one can find that this counter MC191 is giving correct values.
Now coming back to original query, for understanding purposes you can simplify this E2E CSSR Formula as equivalent to
(No of RTCH Assign Success/ No Of All SD Assign Success for Call establishment). This also takes into consideration all the problems occurring at the Core End.Lets say that after a successful SD Assignment Procedure, due to some problem at Core End, the RTCH Assignment Request is lost(MC140a), then this will result in lower value of our E2E CSSR but our old formula of CSSR would not be impacted as it takes into consideration RTCH Assign Unsuccess.
Now normally the value for this indicator is around 92% for a cell having CSSR 99% which is fine.But i have seen a few cases in which this was having very low values like 30%-40%. In one instance, it was a problem of incorrect definition at the MSC End.We escalated the issue to Core and after that it got fine(they didnt share with us what was the problem 😛 …whether it was defined under wrong lac or duplicate definition(but it was strange that why is it having MOC/MTC if its having wrong definition).On another instance, we observed alot of blocked calls during drive test in a remote area.When we checked the cells, it was found that they are having low E2E CSSR(50%) whereas other CSSR is fine. On DT, we used to get blocked call and some message about ciphering(A52) not supported or something(i dont remember the exact message).So, i think the best solution is to send for a drive test for the cells having low E2E CSSR and check the layer 3 messages 🙂thanks alu !
about the MC191, it might be faulty in some early release of B10. I’m not saying it is the case, but that would explain FR’s findings.
again, thanks for sharing, it’s very useful for me.
regards
pixHello,
I believe earlier releases do have counter for MT SMS connections on SDCCH i.e. C191.
In my case, MC191 is showing no values that is cause of degraded E2ECSSR. Same time, C191 do show values and replacing MC191 makes E2ECSSR fine.
In your case, MC191 must be showing some values.
You are right that normal values for E2ECSSR is 92-94%.Regards,
FRDear Guyz,
I observed one very strange thing in this E2E CSSR indicator.I was checking many cells which are having very high SD Drop Rate and corresponding decrease in the normal CSSR but the E2E CSSR indicator is not impacted at all.Can someone tell me that howcome SD Drop is not impacting the E2ECSSR?
As already discussed, the formula can be simplified as
E2E CSSR=(No of RTCH Assign Success/ No Of All SD Assign Success for Call establishment).
Now, if there is an SD Drop due to radio conditions, the denominator would be incremented by 1(as SD was already successfully seized) but numerator would be still the same(as no RTCH Assignment was successful corresponding to this SD).So, overall the value should be decreased!
The only reason that comes to my mind for this problem is that maybe the drops are occurring either due to Location updates or SMS and as these are not taken into account in SD phase so the indicator not impacted.But still probability of this phenomenon occurring everywhere in the network is not that much.Kindly shed some light into the matter.
ThanxALU,
As you suggested, the problem is probably focused on LU only. During Location Updates, the SDCCH is dropped.
Please please please, investigate this issue with traces and
1/ confirm the drops occur only during LU or IMSI ATTACH
2/ isolate the IMEI / IMSI of those mobiles
3/ see if there is a correlation (always same brands / models of phones, for example)The E2E CSSR is great for this alternative use, as you did : you can isolate sd drops during call setup and sd drops during other procedures.
(note: i think these sd drops during LU are a worldwide issue, there are some threads about this in this forum… some ZTE phones seem to have some issues (based on older threads), but perhaps others too)
Have a good day,
PixHi all,
Look through your discussion on low E2ECSSR, It is really an useful and interesting topic. I share my points as following:
1. Fully agreed with ALU’points. There is only SDCCH drop and RTCH assignment failure which will contribute to CSSR. In 2E2CSSR, these two factors are also effected, however we will see that CSSR and E2ECSSR will be degraded in parallel. Our concern is diffent. We have sucsessfull SDCCH assignment (For MTC/MOC only) but there is no RTCH assignment accordingly without any relevant trigged counters in BSS.
2. I found that some BSCs have poor 2E2CSSR, they have poor PSR as well and mostly located in mountainous area with poor coverage.
3. The problem must be investigated in core side as well.
4. After working with core team, we found that some E/// MSC now is using late assignment technique. It mean that serving BSC will only assign RTCH for calling MS if it’s end side is connected (be paged successfully). So if called MS can not be paged successfully (out of coverage or turn-off), RTCH assignment will not happened and result to poor 2E2CSSR
hi Khoalv
thanks for sharing !!
in late TCH assignment, if the tch is not assigned, there is no specific message sent on Abis ? this kind of scenario should not be seen as a failure.
rgds
Hello Experts,
Can anyone shed some light on the end to end CSSR(E2ECSSR)on Nokia and Huawei 2G.
Regard,
- The forum ‘Telecom Design’ is closed to new topics and replies.
