Dear Pix, good evening!
At last I can continue and finish this story which dragged on too long.
So where should I start?
Oh, we had been having a long frozen zone (because of preparation for migration to B10), so we could only watch our poor BSCs and did nothing. But one accident put the lid on that precise correlation between TBF drops due to BSS failure and P103 counter. One morning after unsuccessful attempt to move one of BSCs from old OMC-R to new one (it meant of course moving from one MFS to another) I noticed on that BSC the problem with abnormal TBF drops due to BSS appeared!!! But in this case it wasn’t accompanied by the P103 counter – it remained close to zero. And – no other changes, no other hints – just enormous values of TBF drops due to BSS. Still we could do nothing – frozen zone + a fault report on that BSC. But some time later we needed very badly one more BSC for our highly loaded region, we had one MX in test mode which could be easily used. We started moving BTSs into it, and again – I noticed that we had a problem – abnormal P103 (>200000 per our) this time, and no TBF drops due to BSS at all. Our theory failed so we started to solve these problems separately and first was that one with P103 counter (bad CRC). It was peculiar situation – we’re absolutely sure about our links (either Aters or Gb), BER was better than 10^-8, but the checksums that had been calculated from the same data were different for two ends. Obviously, the problem was in calculation process on those two ends. As we suggested it could be something like different type of CRC, only one-end calculation or some problem with CRCRR (CRC result register – one of them for example) where the result of checksum calculation was put. But we use only CRC4 and as for other hypothesis – we didn’t see the way to check them directly, so we started to check all standard “alcatel solution”: from resetting and changing GPU board to changing settings on SGSN. It didn’t help.
But the thing that really helped and solved that problem was the favorite procedure of deactivation -> activation the feature back again. This time the feature was CRC checking which can be enabled or disabled only from local terminal. So one day we (after a long pondering) decided to do it – deactivated and than activated back CRC checking on Aters. To be true – it was terrible few hours – we thought we lost our BSC – the process was so long. But fortunately it didn’t happen, although we had to reset lots of HW, including cprc board after all. That was the solution for high P103 (without any other problems) 🙂
Than we started to work at TBF drops due to BSS problem – another long chain of hypotheses and experiments – at last after rebooting whole MFS it vanished.
For those BSCs where we saw both problems we started from disabling/enabling CRC but after all we had to reset almost everything – and after such actions all problems have gone.
I was watching for all those treated BSCs for some hours but then we lost NPO (due to migration), so I wasn’t absolutely sure about the results. Today we’ve been given this tool back – and now I can see that since that day everything is excellent. Graphs from NPO are really astonishing 🙂
… and they lived happily ever after …
Best regards, Lily