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

Release 4

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #50065

    BSCs in our network (Siemens equipment) have been rehomed from R99 to R4. Eversince this rehoming there has been a jump like increase in Assigment requests queried from the MSC to the BSC.

    Everytime this message is sent the counter TASSATT is triggered. The problem is that TASSSUCC and TASSFAIL have not increased in magnitude similar to TASSATT. So teh difference between TASSATT and sum of TASSSUCC and TASSFAIL has widened, what could cause this? Is it some synchronization problem, if so, how can one confirm it?



    could you give me the trigger event for these 3 counters ?

    i would suggest you perform an A interface trace, and check if there is any counter (BSS or NSS) that has increased. The main question is :
    – where are going the excessive TASSATT ? Something must be happening to them…

    Synchronization could be the cause, along with wrong A/Ater timeslot definition, yes.



    Trigger events:

    1. Measurement is triggered (at BSC) after receipt of a valid Assignment Request from MSC to BSC. ( When the MS sends the CM service request, after authentication and ciphering processes are completed the MSC sends the Assignment request – to BSC , the BSC then queries for free TCH for alottment)


    1.Triggered by the transmission of a valid Assignment complete message.


    1. Triggered by transmission of a valid Assignment Failure message. (That is everytime the callsetup is not successful)

    The jump in TASSATT is synonymous for all BScs that were rehomed to R4. If there was wrong A/Ater timeslot definitions then this wrong definitions error is repeated in 5 such rehomings. I will consider this assumption after other options are exhausted.:)



    I shall be performing an A interface trace based on your suggestion. Lets see what that result would yield.

    Thanks for your input.



    ok, let’s wait and see…


    The traces were not conclusive. But had some interesting points:
    1. Since the traces were taken at night, there wasnt much difference between Assignment Attempt and its corresponding success and failures. This difference could have been due to non completion of calls during the trace interval.
    2. In messages I saw a re-attempt of Assreq from MSC whenever a Assignmentfailure_protocol error was recieved.
    3. Assignmentfailure_protocol error varies in the day and is maximum at BH.
    4. The difference visible in our counters is also maximum at BH.
    5. After rehoming we do see in the counters an increase in Assignmentfailures_protocol error.
    6. Vendor responded that the imbalance is due to unavailability of late assignment faeture in new NSS entity and has early assignment instead, but should not the assignment request only be sent out once the B party circuit is siezed or destination engaged and hence this logic does not sustain?

    Any input is welcome.



    i’ll give it a closer look tomorrow, i need to see the call setup message flow.
    If you have K12 logs, could you send them to me ?



    Sure, I will require your email.
    Send your ID to

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