Dear Pix, good evening!
Sorry for such a long delay with answer – we have awful weather here and one-day business trip turned out to became a five day isolation from civilization 🙂
Oh. no – it’s not me vs. TAC, it’s collective human mind vs. Alcatel’s temper 🙂 yesterday my boss said that he’s giving up because alcatel equipment has female character 🙂
We made the next step in our experiments and now I’ve just seen the results – I have no words, no words at all!
But all in order –
At first – you are absolutely right, it’s impossible – to deactivate CRC checking at BSC. All we could find and done (at that moment) was deactivation CRC between SGSN and MFS (on Aters) – although it wasn’t what we needed. My expectations were obvious: ether the problem will be solved (less probable outcome) or nothing will change (more probable end as for me). But Alcatel always can surprise you: even in the simplest situation, when you have only two hypotheses, it easily can show you the third variant. And this time wasn’t an exception 🙂 The P103 counter changed – it decreased twice!!! I checked several times – we deactivated CRC for both links from MFS to SGSN for this BSC.
After half an hour of emotions new questions came:
1) The full name of P103 (from catalog) is NB_ERROR_UL_GCH_FRAME. Only UL? Does it mean that we must consider only part from MS to MFS?
2) If – yes, then what is the second part, calculating CRC?
3) Can we deactivate CRC for that very part? Or what could be a problem with it calculation?
I’m looking for answers to these questions and many others now. I hope soon we’ll have new results.
P.S. Of course, I’ve shared all info with TAC, but they are very busy now – neighbor region of us is migrating now from B9 to B10 and the process isn’t such smooth, so guys from TAC almost every night spend near the equipment and we have authority to do what we consider to necessary to solve this problem