- This topic has 16 replies, 1 voice, and was last updated 15 years, 4 months ago by
.
-
Posts
-
Hi,
We have seen a considerable increase in SDCCH drops after TMSI activation on the ///MSS (approx 25%). Is this to be expected?
What can be done to correct this?Many thanks
Author,
Oooch… that’s bad ! Not normal, for sure.
You’re having a configuration issue somewhere. I don’t think the BSS can be causing the trouble here (maybe it does ? you have to check if anything is related to IMSI / TMSI in the BSC or in the BTS).So probably it’s a problem in MSC/VLR.
If you want to investigate : perform a drive test, do a call setup, and see if you can detect a failure during the SDCCH phase.
Or, better, do a trace on the A-interface. Check the Authentication / Ciphering / TMSI Reallocation procedures on this trace. You can check that for many mobiles, that’s why it is certainly better than a drivetest, that shows result for only one mobile station.Hi Pix, Thanks for your reply.
We have monitored the A interface but nothing there. No cause codes in the MSC either. The MSC does not notice anything difference than before. We have noticed also a huge increase in T200 timeouts. My theory is that the TMSI allocation procedure increases the SDCCH MHT and in areas with low SS the chance is therefore higher that an SDCCH drop (due to low SS) will occur. Any suggestions on what we can do to bring down the SDCCH drops? Could we increase the T200 timer for example?Many thanks
Author,
I am very surprised. You say you see no difference on the A interface, yet you say the TMSI reallocation might cause the SDCCH to last longer.
But … you should have cleared that out by now : the TMSI reallocation procedure is visible on the A interface. Why don’t you simply check the duration of this procedure ? Maybe it does not impact the duration of the whole SDCCH phase at all ?
In alcatel system, the tmsi reallocation is performed in parallel to the authentication/ciphering/call setup. It doesn’t add any delay.
Dear, Pix! Not in parallel with other procedures! At least for location updating (normal, periodic, attach).
1)First of all there is Authentication
2)When Authentication procedure is comleted the network sends Ciphering Command to MS, and MS responds by Ciphering complete message.
3)After that the Tmsi reallocation procedure is started.
Hence, the TMSI reallocation procedure really increases the SDCCH occupancy rate (aproximately on 10-20%)Dear pix
also our vendor does not prefer to paing by using TMSI , they said it makes many porblem in the network especillay in the core network .
Pan, I just read your message 🙂 Well, the reallocation is happening in between the messages. I think the request is sent early, and the answer is received later…
I could check exactly, but I’m too lazy. It’s not important 🙂Ayat, many operators are using TMSI paging. If your operator have an issue with it, it’s probably a configuration problem.
it is intrested issue
Oh, Pix:). I was a teenager in 2008 and went to school.
Ciphering Mode Establishment takes some time. Isn’t it? The only need in Ciphering mode during Location Updating procedure – is User Identity Confidentiality (TMSI). There is no need in Ciphering mode establishment during Location Updating procedure when TMSI reallocation isn’t used.
I’m a teacher, but i hope never to have a “student” like you :)) your questions would be such a p* in the a* !
cheers,
pixHi, If anyone of you have observed this problem and /or have its solution, I would be grateful!!
In our Network, SDCCH Drops due to other reasons increase randomly on some cells of the network and automatically comes back.
It has also been observed that the cells on LAC border (having more location updates) are experiencing this issue more than the other cells.
Unfortunately, my client is not capable of running the A-Interface traces….Is there any ideas from any one of you.
Thanks
It looks like a problem happening on every network in the world (all brands included). It is either a MS fault or a 3GPP spec mistake…
The A interface trace is probably the only way to troubleshoot it. Or a Drivetest ?
Are you certain the radio conditions of the SDCCH ts are fine ? Have you tried moving the SDCCH TS onto other TRX, just to be sure ?
Hi Pix,
Thanks for the quick reply. As I said the operator is not able to run the A-inteface traces at the time being…
As far as the SDCCH Radio conditions are concerned…everything is fine like BCCH plan, Idle Channel Interference…all find And you are right that changing TS or TRX can be helpful and I have already done that…As I said, it happens only in certain hours not for the whole day…depicting something beyond Radio…
Anyways…I would try to find something via Drive Test again…Meanwhile can you let me know about any common thing which has been recently obsreved regarding this problem as you are saying its happening in all brands..
Thanks
Well, many people are asking the same question as yours, with same details.. and some of the people I met at work are also experiencing those (location update drops)
Maybe i got it all wrong, it is just my feeling that something is going on there…Let me know about your findings…
Pix
Hi,
Does anyone knows about the parameter to turn off TMSI Re-allocation during location updates.I need to know the MSC parameter name and if there is any associated BSS parameter linked with that to be changed accordningly. Is there any negative impact of that on the network.
- The forum ‘Telecom Design’ is closed to new topics and replies.
