Cellular Network Infrastructure » Radio Access Network » OsmoPCU

(While testing on Monday keith noticed that the GPS sync was lost. To be sure that this is not the problem he has re-tested it with proper GPS sync, unfortunately with the same result.)

Meanwhile I have analyzed the problem a bit further. I am very sure that the problem is not due to an unreliable E1 connection. In fact the connection and the TRAU sync seems to be ok. When filtering the log with

cat ./pcu-startup-64k.log | grep "CCU-\|LOST\|PCU-\|555555555555555555\|LOST\|synchronized" 

One can see that it goes through the sync procedure. But even though we send TRAU frames to the CCU, it does not stop sending SYNC indications. That is why we see an "In sync with CCU" message in response to every data indication we send. The CCU on the other end also seems to understand the frame since dbe and dfe are 0. If there were problems with the frame format we should get at least dfe=1 in the log. Also when looking at both logs we see the exact same behavior. So I think we can rule out a frame format problem.

I have the impression that the sync procedure somehow fails. Maybe the CCU fails to finish the procedure and still thinks that it is not synced yet. Maybe it tries to tell: "You sending me data frames, but I am not synced, here is a SYNC indication!"

One must also take into account that the latency of the E1 line is about 13 TRAU frames, so when we send a CCU_SYNC_IND, it will take some frames until it reaches the CCU, then the CCU has to respond and this also takes time. Maybe we have to send the SYNC indications longer. I have hacked up osmo-pcu so that it does not immediately stop the synchronization. Once in sync it will continue to send CCU-SYNC-IND for a few more TRAU frames.

The changes can be found on osmo-pcu.git pmaier/ccuhacks

keith: can you try the modified osmo-pcu version and attach the log output to this ticket?

I think checking with osmo-e1d and icE1usb is something we can do. It would be helpful if you could provide the configuration files. I haven't used the icE1usb before so known-to-work config files would be helpful.

Honestly, my osmo-e1d.cfg was created with

touch osmo-e1d.cfg

$ ls -l osmo-e1d.cfg 
-rw-r--r-- 1 root root 0 Feb  7 04:57 osmo-e1d.cfg

I have now tested what happens when we try to use our setup (RUS 02 B3 with DUG 20 01) with icE1usb (GPS synced). The behavior I see is indeed the same. I have tested with 64kbps and 16kbps. I also tried out the pmaier/ccuhacks branch but the hacks (relax the sync procedure) did not help to fix the problem.

Since I have tried it with a temporary setup on my laptop, to investigate this further I would say we should setup a more permanent testbed with an icE1usb in the testrack. We also should try the dahdi kernel driver, maybe this one offers better performance than osmo-e1d.

I only had a very brief look at this, so I am not sure if this relates to the problem that we are facing here:
https://discourse.osmocom.org/t/octoi-bit-errors/134
https://osmocom.org/issues/6169

On Fri, Sep 08, 2023 at 08:22:31AM +0000, dexter wrote:

I only had a very brief look at this, so I am not sure if this relates to the problem that we are facing here:

it is not, as we are not using OCTOI but just icE1usb in this case. Furthermore, libosmo-abis is using the
correct buffer policy for B-channels.

Well, I finally got around to getting the icE1usb up and running with the dahdi driver. Indeed I was able to use both configs that dexter supplied in the examples configs, GPRS and EGPRS. It was not very reliable when getting a lot of traffic from a lot of MS, but it's a working start.

Might as well note here that while trying to use osmo-e1d now (todays nightly/master of everything), I'm unable to establish TCH for voice, I get this

TS read underflow: We had 8 bytes to read, but socket returned only -1