Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

E2E CSSR in ALU

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #63342
    Pix
    Guest

    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
    Pix

    #63343
    Guybrush
    Guest

    Hi,

    Can you share the counter level formula for this indicator?


    Threepwood

    #63344
    FR
    Guest

    Hi,

    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.

    #63345
    pix
    Guest

    hi fr,

    thanks for the very useful input !

    regards
    pix

    #63346
    ALU
    Guest

    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 🙂

    #63347
    pix
    Guest

    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
    pix

    #63348
    FR
    Guest

    Hello,

    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,
    FR

    #63349
    ALU
    Guest

    Dear 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.
    Thanx

    #63350
    Pix
    Guest

    ALU,

    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,
    Pix

    #63351
    Khoalv
    Guest

    Hi 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

    #63352
    pix
    Guest

    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

    #63353
    Khan
    Guest

    Hello Experts,
    Can anyone shed some light on the end to end CSSR(E2ECSSR)on Nokia and Huawei 2G.
    Regard,

Viewing 12 posts - 1 through 12 (of 12 total)
  • The forum ‘Telecom Design’ is closed to new topics and replies.