5 Nov
2017
5 Nov
'17
4:26 p.m.
Hello everyone,
I'm trying to setup OpenBSC to use GPRS on Ettus hardware with (B210).
I followed what's written here more or less: https://osmocom.org/projec
ts/cellular-infrastructure/wiki/OpenBSC_GPRS
however for some reason I cannot get this to work. This is the first
time that I try to setup GPRS with OpenBSC and even though I have a lot
of experience working with OpenBSC for 2G stuff, this time I cannot
figure out what's wrong.
Here's the log from osmo-bts-trx when osmo-pcu connects:
<0001> oml.c:76 Sending PCU version report to BSC: 0.4.0.2-bfc5
<0009> pcu_sock.c:336 Sending data indication: sapi=BCCH arfcn=0
block=0 data=01 06 00 90 00 19 5a 6f c9 e0 84 10 ab 2b 2b 2b 2b 2b 2b
2b 2b 2b 2b
<0009> pcu_sock.c:588 Activate request received: TRX=0 TX=2
<0000> rsl.c:669 (bts=0,trx=0,ts=2,ss=0) not sending CHAN ACT ACK
<0009> pcu_sock.c:588 Activate request received: TRX=0 TX=3
<0000> rsl.c:669 (bts=0,trx=0,ts=3,ss=0) not sending CHAN ACT ACK
<0009> pcu_sock.c:588 Activate request received: TRX=0 TX=4
<0000> rsl.c:669 (bts=0,trx=0,ts=4,ss=0) not sending CHAN ACT ACK
<0009> pcu_sock.c:588 Activate request received: TRX=0 TX=5
<0000> rsl.c:669 (bts=0,trx=0,ts=5,ss=0) not sending CHAN ACT ACK
<0009> pcu_sock.c:588 Activate request received: TRX=0 TX=6
<0000> rsl.c:669 (bts=0,trx=0,ts=6,ss=0) not sending CHAN ACT ACK
<0009> pcu_sock.c:588 Activate request received: TRX=0 TX=7
<0000> rsl.c:669 (bts=0,trx=0,ts=7,ss=0) not sending CHAN ACT ACK
<0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=0
<0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514
block=0 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b 2b 2b 2b
<0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=1
<0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514
block=1 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b 2b 2b 2b
<0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=2
<0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514
block=2 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b 2b 2b 2b
<0009> pcu_sock.c:307 Sending rts request: is_ptcch=1 arfcn=1 block=0
<0009> pcu_sock.c:487 Data request received: sapi=PTCCH arfcn=1 block=0
data=2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b
<0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=3
<0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514
block=3 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b 2b 2b 2b
<0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=4
<0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514
block=4 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b 2b 2b 2b
the last part (Sending rts request: ...) just repeats over and over.
Here's the log from osmo-pcu:
<000b> telnet_interface.c:101 telnet at 127.0.0.1 4240
<0001> osmobts_sock.cpp:229 Opening OsmoPCU L1 interface to OsmoBTS
<0001> osmobts_sock.cpp:288 osmo-bts PCU socket /tmp/pcu_bts has been
connected
<0001> osmobts_sock.cpp:292 Sending version 0.4.0.2-bfc5 to BTS.
<0001> pcu_l1_if.cpp:107 Sending 0.4.0.2-bfc5 TXT as PCU_VERSION to BTS
<0001> pcu_l1_if.cpp:427 BTS available
<0008> gprs_ns.c:263 NSVCI=65534 Creating NS-VC
<0008> gprs_ns.c:1619 Listening for nsip packets from 127.0.0.1:23000
on 0.0.0.0:23000
<0008> gprs_ns.c:1638 NS UDP socket at 0.0.0.0:23000
<0008> gprs_ns.c:263 NSVCI=1800 Creating NS-VC
<0008> gprs_ns.c:1656 NSEI=1800 RESET procedure based on API request
<0008> gprs_ns.c:446 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M
intervention)
<0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=2
<0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=2
<0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=3
<0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=3
<0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=4
<0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=4
<0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=5
<0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=5
<0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=6
<0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=6
<0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=7
<0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=7
<0008> gprs_ns.c:887 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800,
cause=O&M intervention)
<0008> gprs_ns.c:707 NSEI=1800 Tx NS RESET ACK (NSVCI=1800)
<0008> gprs_ns.c:995 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800)
<0008> gprs_ns.c:1004 NS RESET ACK Discarding unexpected message for
NS-VCI 1800 from SGSN NSEI=1800
<0008> gprs_ns.c:555 NSEI=1800 Tx NS UNBLOCK (NSVCI=1800)
<0008> gprs_ns.c:1411 NSEI=1800 Rx NS UNBLOCK
<000a> gprs_bssgp_pcu.cpp:541 NS-VC 1800 is unblocked.
<0009> gprs_bssgp_pcu.cpp:820 Sending reset on BVCI 0
<0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=0) Tx BVC-RESET CAUSE=O&M
intervention
<0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M
intervention
<0008> gprs_ns.c:1417 NSEI=1800 Rx NS UNBLOCK ACK
<0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK
<0009> gprs_bssgp_pcu.cpp:828 Sending reset on BVCI 1800
<0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M
intervention
<0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800
<0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M
intervention
<0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800
<0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M
intervention
<0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK
<0009> gprs_bssgp_pcu.cpp:836 Sending unblock on BVCI 1800
<0009> gprs_bssgp_bss.c:270 BSSGP (BVCI=1800) Tx BVC-BLOCK
<0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800
<0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M
intervention
<0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK
<0009> gprs_bssgp_pcu.cpp:836 Sending unblock on BVCI 1800
<0009> gprs_bssgp_bss.c:270 BSSGP (BVCI=1800) Tx BVC-BLOCK
<0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800
<0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M
intervention
<0009> gprs_bssgp_pcu.cpp:349 Rx BSSGP BVCI=0 (SIGN) PDU type BVC-
UNBLOCK unknown
<0009> gprs_bssgp_util.c:236 BSSGP BVCI=0 Tx STATUS, cause=Protocol
error - unspecified
<0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK
<0009> gprs_bssgp_pcu.cpp:836 Sending unblock on BVCI 1800
<0009> gprs_bssgp_bss.c:270 BSSGP (BVCI=1800) Tx BVC-BLOCK
<0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800
<0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M
intervention
<0009> gprs_bssgp_pcu.cpp:349 Rx BSSGP BVCI=0 (SIGN) PDU type BVC-
UNBLOCK unknown
<0009> gprs_bssgp_util.c:236 BSSGP BVCI=0 Tx STATUS, cause=Protocol
error - unspecified
<0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK
and like osmo-bts-trx, the last part (Sending unblock ...) repeats
forever. Basically the two processes are stuck like these and nothing
works, only 2G.
The other components (ggsn, osmo-sgsn and osmo-nitb) seems to be fine,
I'm not getting any error output in the their logs.
The configuration should be fine, I just followed the mentioned link
and all the components can talk to each other, so it's not an ip/port
issue on my local system.
Any help in this would be appreciated. Reading this ML seems like GPRS
works for everyone except me...might be related to Ettus B210, I don't
know to be honest, but I had no issue so far with OpenBSC and 2G.
Eventually I can debug the source and provide more information if
required.
Everything was built from latest git repositories, might be related to
recent split in osmo-nitb and gprs?
Thanks for your help!
Lorenzo
7 Nov
7 Nov
12:33 p.m.
Hi Lorenzo,
please note that that wiki page hasn't been updated in a while. Most of it
should have remained the same though.
On Sun, Nov 05, 2017 at 04:26:10PM +0100, Lorenzo Cavallini wrote:
<0008> gprs_ns.c:263 NSVCI=65534 Creating NS-VC
[...]
<0008> gprs_ns.c:707 NSEI=1800 Tx NS RESET ACK
(NSVCI=1800)
<0008> gprs_ns.c:995 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800)
<0008> gprs_ns.c:1004 NS RESET ACK Discarding unexpected message for
NS-VCI 1800 from SGSN NSEI=1800
looking at the source code for this, it seems that your setup is not
expecting a RESET ACK for that particular NSEI / NSVCI. Maybe some setting
still mismatches?
If you can't find anything, do also send your config files along.
I'll also point you at the new wiki page for the split setup that includes
GPRS -- but it isn't fully verified yet and doesn't include PCU setup:
https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I…
~N
8 Nov
8 Nov
10:07 a.m.
Hi,
thanks for your answer.
You are right, it was a configuration problem related to the SGSN. In
particular, the encapsulation local-ip parameter in the ns section. I was
using the same value used for gtp localip, but this was creating the issue.
Now I set this ip to some random local ip (127.0.0.10) and it works fine.
Can you explain what the encapsulation setting is actually doing? The
documentation is not very clear on this, I thought this was supposed to be
the same value as the gtp localip. Everything else is working fine anyway.
By the way, do you recommend to switch to the "split" architecture right
now? Or is there a timeline for when OsmoNITB will be deprecated? Thanks!
Lorenzo
On Tue, Nov 7, 2017 at 12:33 PM, Neels Hofmeyr <nhofmeyr(a)sysmocom.de> wrote:
Hi Lorenzo,
please note that that wiki page hasn't been updated in a while. Most of it
should have remained the same though.
On Sun, Nov 05, 2017 at 04:26:10PM +0100, Lorenzo Cavallini wrote:
<0008> gprs_ns.c:263 NSVCI=65534 Creating
NS-VC
[...]
<0008> gprs_ns.c:707 NSEI=1800 Tx NS RESET
ACK (NSVCI=1800)
<0008> gprs_ns.c:995 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800)
<0008> gprs_ns.c:1004 NS RESET ACK Discarding unexpected message for
NS-VCI 1800 from SGSN NSEI=1800
looking at the source code for this, it seems that your setup is not
expecting a RESET ACK for that particular NSEI / NSVCI. Maybe some setting
still mismatches?
If you can't find anything, do also send your config files along.
I'll also point you at the new wiki page for the split setup that includes
GPRS -- but it isn't fully verified yet and doesn't include PCU setup:
https://osmocom.org/projects/cellular-infrastructure/wiki/
Osmocom_Network_In_The_Box
~N
2:33 p.m.
On Wed, Nov 08, 2017 at 10:07:11AM +0100, Lorenzo Cavallini wrote:
Can you explain what the encapsulation setting is
actually doing?
It's the address where the PCU talks to the SGSN, so it needs to be reachable
by your BSS. If you're on a single box (using osmo-trx or everything on one
sysmoBTS) it can be a loopback (like you picked), otherwise it needs to be an
IP on a public interface. The address is passed to osmo-bts, which in turn
tells osmo-pcu where to find the SGSN.
I thought this was supposed to be the same value as
the gtp localip.
GTP is from the SGSN to the GGSN side:
BSS | Core Network
PCU <--GRPS-NS--> SGSN <--GTP--> GGSN
By the way, do you recommend to switch to the
"split" architecture right now?
Or is there a timeline for when OsmoNITB will be deprecated? Thanks!
It certainly doesn't make sense to set up a long term installation based on the
OsmoNITB anymore: our development focus has already moved away from OsmoNITB,
and as of now it will mainly sit there and age.
The main remaining issue for the split components now is that the OsmoMSC still
needs the old osmo-bsc_mgcp instead of the new osmo-mgw -- but that is going to
change pretty soon and will be trivial to adjust. The other detail is that I am
still busy verifying that the wiki pages that help you set up the split
components are indeed accurate.
So, you may still experience minor challenges finding your way across to a
split installation, which we will be more than happy to help out with and iron
out our documentation in the process.
Infrastructure wise we have the split components tested in the osmo-gsm-tester
every day, we have sysmoBTS images running the split components (201705 feed),
we have nightly builds for all the programs in the form of Debian and Ubuntu
feeds. The split components get you various juicy benefits, like one central
HLR for MSC and SGSN, seamless 3G support and UMTS authentication (Milenage).
And congratulations to your working setup :)
~N
2367
days inactive
2370
days old
3 comments
2 participants
participants (2)
-
Lorenzo Cavallini -
Neels Hofmeyr