- This topic has 7 replies, 1 voice, and was last updated 13 years, 2 months ago by Frood.
18th December 2007 at 07:49 #50065FroodGuest
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?18th December 2007 at 09:47 #50066pixGuest
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.
Pix18th December 2007 at 11:02 #50067FroodGuest
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.:)18th December 2007 at 17:10 #50068FroodGuest
I shall be performing an A interface trace based on your suggestion. Lets see what that result would yield.
Thanks for your input.19th December 2007 at 09:22 #50069pixGuest
ok, let’s wait and see…21st February 2008 at 11:03 #50070FroodGuest
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.21st February 2008 at 18:44 #50071pixGuest
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 ?22nd February 2008 at 06:09 #50072FroodGuest
Sure, I will require your email.
Send your ID to email@example.com