Dear 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 🙂