Number one consultant for number one vendor 😉
Ater CS congestion… wow, i’ve never seen this. Actually, Ater CS is mapped statically to the A interface, therefore you can either look at A or Ater CS KPIs.
For example, look at the object “AIC” (A interface channel), which can give you the overall usage of each TTCH.
For a more global indicator, I’m pretty sure you can find TCH CONGESTION due to A congestion, located at cell level.
Well, let me know if you need more detailed info, in which case i’d need to go through the counters dictionnary. It’s no big trouble for me, just let me know.
A interface has 2 kind of channels :
(1) AIC (or TTCH) which are mapped to the Radio TCH. 1 TTCH = 1 RTCH.
(2) SS7 which carry the call signalling (call setup messages, ie. messages that go through the SDCCH, call release messages, etc.).
For congestion of AIC, refer to above. consequence is TCH Congestion.
Congestion of SS7 is even rarer, and I guess the consequence is NOT SDCCH congestion. The MS would get the SDCCH before the A interface is tested for a SS7 channel.
If SS7 is congested, then the BSC should release the SDCCH after a while. Again, I’m not sure such case can occur : SS7 is only busy for few milliseconds per call setup, and the capacity is enormous.
You can find SS7 or N7 or LAPD counters in NPO. CR = Call Request (BSC to MSC), CC = Call Confirm (MSC to BSC), which are the 2 first messages on A itnerface for a call. If they go through, then the SS7 channel is allocated for the call.
Good luck ! If you want to share more info, please give me an email or something to contact you.
Regards
pix