Hi,
I am trying to setup a simple Network In The Box 2G network. I am only interested in CS capabilities (voice calls, SMS, USSD). I am currently running the following elements with the default configurations: - osmo-bts-trx (connecting to osmo-trx-uhd driving a USRP B205mini-i) - osmo-bsc - osmo-msc - osmo-hlr - osmo-mgw - osmo-stp
I built all the programs from source on Ubuntu 22.04. Everything is running locally on one machine.
Everything seems to function correctly at first, but I noticed that sometimes when I try to execute an USSD code or make a call, my Channel Requests are not being responded. I noticed when this happens, osmo-bts shows the following notice:
DPCU notice PCU socket not connected, dropping message (pcu_sock.c:1018)
As I understand from the documentation (https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In...), this component is not required for circuit switched services as the ones I am requesting, so I do not understand why this is happening. I assume something in the configuration files is telling the BTS or some network element that the PS side of the network is active, but I haven't found anything related to PCU in any of configuration files.
Hi,
that log message could happen for tons of reasons and it's really not saying much alone.
I don't think GPRS is needed at all or has any relation with USSD.
Please provide a full pcap file with gsmtap and logs of the full run, otherwise it's almost impossible to guess what the problem may be.
Hi,
First, what Pau said.
I would add that I think it's unlikely you're actually seeing a direct correlation between your ignored RACH and the notification that the PCU is not connected. Ah, If only I had a satoshi or go on, even a penny, for everytime I've seen an assumption that a "normal" log message is related to a problem being observed.
Normally I would expect to see that log due to a RACH for packet access, (more logging at level debug would tell you) and I was going to ask if you have GPRS configured in your osmo-bsc config to something other than none, but then thinking about it, IIRC, we modify the System Info when the PCU is disconnected and don't advertise GPRS on the cell anyway, so you shouldn't be getting packet access requests. Doesn't matter anyway, It's not the cause of your lack of success with USSD
Ah!!.. second thing just jumped into my memory from osmo-trx days, if you turn up rx-gain enough or have some RF noise generation around, you might be getting a whole lot of fake "RACH" in the logs.
I don't have and have never used a B205-mini, and I haven't even read the specs, but the B200 was just mentioned on IRC and so I thought it might be worth telling you that years ago, I used the USRP N210 with osmo-trx-uhd/osmo-bts-trx and my observation was:
GPS Locked clock = reliable operations.
No GPS locked clock = all kind of problems, not least of which being, precisely what you describe, BTS not "seeing" the RACH. (or maybe no UE response to the assign)
I wonder, come to think of it now, maybe you have set osmotrx maxdly? I'm not sure what the default is, but maybe, you might have more luck increasing it. but that's just something that occurs to me right now. Probably not going to help if you're that far off.
In the end, you need to do what Pau said. In fact, if you log the relevant levels at debug and capture and inspect some traffic, you'll probably have a much more clear idea of what is happening.
Also, then you can inspect your SI, either with gsmtap or off-the air with osmocom-bb or an rtl-sdr/grgsm_livemon, you will confirm if you are advertising PS or not.
k/
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
On Fri, Mar 29, 2024 at 11:09:24PM -0000, JPichel wrote:
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.
This sounds like the time I was using a B210 without a solid external clock. Randomness to the point of sometimes seeming reliable.
Funny part is, it didn't get better when I connected a GPS antenna. Then learned that the B210 had only the external connector without a GPS receiver inside.
Connecting the 10MHz external oscillator made things work nicely. (Or a sysmoBTS also does.)
~N
Hi, this will help http://zhixun-wireless.top/10mhz-001ppm-ocxo-compatible-with-b210http://zhixun-wireless.top/10mhz-001ppm-ocxo-compatible-with-b210
www.zhixun-wireless.tophttp://www.zhixun-wireless.top/ provide SDR PA LNA duplexer
Best Regards
________________________________ From: Neels Hofmeyr nhofmeyr@sysmocom.de Sent: Wednesday, April 3, 2024 8:37 To: JPichel jonathanpc@protonmail.com Cc: openbsc@lists.osmocom.org openbsc@lists.osmocom.org Subject: Re: Channel Requests not being responded when running CS-only 2G network
On Fri, Mar 29, 2024 at 11:09:24PM -0000, JPichel wrote:
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.
This sounds like the time I was using a B210 without a solid external clock. Randomness to the point of sometimes seeming reliable.
Funny part is, it didn't get better when I connected a GPS antenna. Then learned that the B210 had only the external connector without a GPS receiver inside.
Connecting the 10MHz external oscillator made things work nicely. (Or a sysmoBTS also does.)
~N
-- - Neels Hofmeyr nhofmeyr@sysmocom.de http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte
-
john wu -
JPichel -
Keith -
Neels Hofmeyr -
Pau Espin Pedrol