Re: Channel Requests not being responded when running CS-only 2G network

Thank you both, you were absolutely right. Looking at the logs I see these "PCU socket not connected" messages where being produced because of the arrival of PAGING COMMAND from the BSC. Looking at the code is the normal behavior, so it has nothing to do with my problem. My SI messages were in fact not announcing PS services. I would provide logs and captures, but right now I don't have with me my test uSIM so I would be leaking my personal SIM information. Looking at the osmoBTS and osmoBSC logs I haven't managed to find a reason to this behaviors, but they are the following: 1. Executing an USSD code - Wireshark capture shows the multiple Channel Request tries, no Inmediate Assignment - Wireshark capture shows Channel Request and Inmediate Assignment, but the terminal doesn't seem to receive this and instead of sending a Service Request it tries to send do a Channel Request again 2. Making a voice call - The caller UE successfully makes the phone call but the other UE doesn't respond to the Paging Request This are some examples of the problems I am experiencing, and they all seem to involve one of the radio not responding to some messages. Also I noticed this mainly happens the more I wait without making any connection between a terminal and the network, so if I connect the terminal to the network, then wait 10 minutes, and try to execute an USSD code, it is more likely than there is a error establishing the connection. Looking at the BTS logs, these are some of the values I am getting: <0006> scheduler_trx.c:562 TRX Clock Ind: elapsed_us= 998040, elapsed_fn=216, error_us=+1200 <0006> scheduler_trx.c:581 GSM clock jitter: -3279us (elapsed_fn=0) <0006> scheduler_trx.c:562 TRX Clock Ind: elapsed_us= 999923, elapsed_fn=217, error_us=-1532 <0006> scheduler_trx.c:581 GSM clock jitter: -1666us (elapsed_fn=0) <0006> scheduler_trx.c:562 TRX Clock Ind: elapsed_us=1000060, elapsed_fn=216, error_us=+3220 <0006> scheduler_trx.c:581 GSM clock jitter: -4800us (elapsed_fn=-1) <0006> scheduler_trx.c:591 We were 1 FN faster than TRX, compensating <0006> scheduler_trx.c:562 TRX Clock Ind: elapsed_us= 998031, elapsed_fn=217, error_us=-3424 <0006> scheduler_trx.c:581 GSM clock jitter: 3533us (elapsed_fn=1) <0006> scheduler_trx.c:591 We were 1 FN slower than TRX, compensated So I think it is possible these problems are related to the USRP clock. The B205mini has +-2ppm accuracy. It doesn't provide the option to mount an internal GPSDO but it does have a reference port for a 10MHz/1 PPS signal. I will try to get access to some lab equipment that can provide this, and if it improves the stability of the system, I will try to find something small factor, since my application requires mounting the system on a drone (also the reason why we chose the mini series). If GPSDO is required, probably the B210 with the internal GPSDO module weights less than the B205mini + external oscillator. Thanks again, Jonathan Pichel