27 Mar
2024
27 Mar
'24
4:55 p.m.
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_I…),
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.
27 Mar
27 Mar
6:09 p.m.
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.
--
- Pau Espin Pedrol <pespin(a)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
* Geschaeftsfuehrer / Managing Director: Harald Welte
11:29 p.m.
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/
30 Mar
30 Mar
12:09 a.m.
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
3 Apr
3 Apr
2:37 a.m.
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(a)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
7 Apr
7 Apr
7:37 a.m.
Hi,
this will help
http://zhixun-wireless.top/10mhz-001ppm-ocxo-compatible-with-b210<http:/…
www.zhixun-wireless.top<http://www.zhixun-wireless.top/>
provide SDR PA LNA duplexer
Best Regards
________________________________
From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Sent: Wednesday, April 3, 2024 8:37
To: JPichel <jonathanpc(a)protonmail.com>
Cc: openbsc(a)lists.osmocom.org <openbsc(a)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(a)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
27
days inactive
38
days old
5 comments
5 participants
participants (5)
-
john wu -
JPichel -
Keith -
Neels Hofmeyr -
Pau Espin Pedrol