I don’t know the specifics of the Gemeni cells, but the symptoms you are describing lead me to think that the problem is localized only on the TRX that carries the SDCCH timeslot, and not on the TRX that carries most of the TCH traffic.
For example, in a cell with 2 trx, only one TS is configured as SDCCH, and it is located on TRX1. On the other hand, the TRX2 is the one which is “preferred” when it comes to carry TCH traffic.
So you have to look at which frequency is used by TRX1, and ensured it is not interfered.
Then check the path balance of TRX1, compared to the Path Balance of TRX2.
And then, if you don’t find anything suspect, lock TRX2. Doing this will push the TCH traffic on TRX1. And there you should see that TCH also are getting drops!
You can further confirm this by doing a drivetest.
If TCH drop % does not increase after locking TRX2, then it means that it is perhaps an issue that comes from a MS / NSS problem. It seems that the Location Update procedure is not correctly handled by some MS on the market nowadays. As a result, every time such MS sends a LU, the SDCCH will be seized for more than 10s and then it will drop. I forgot what’s happening exactly. But one way to diagnose this is to prevent LU in the cell by setting the parameter “ATT” (=IMSI_ATTACH) to disable. After doing that you might see a decrease of SDCCH Drop %. If that’s the case, then it means there are “crazy” MS in this cell. You should therefore turn the ATT parameter back to “enable”. And trace the A-interface to detect which IMSI is going crazy. Then change the MS of this customer…
Woow, what a long post…