Hi all,
Today I'm working on updating my NuRAN unit with the new osmo stack in
order to try to reproduce the same behavior of old osmo-nitb we use in
production in Rhizomatica (with subscriber_create_on_demand feature on).
I'm writing just in case someone already put online a set of config
files with the parameters needed by such behavior set?
; )
ps: I have the new splip stack working fine here, I just need to modify
my setup with new features to support subscriber_create_on_demand.
Best regards,
Rafael Diniz
FYI. I don't see any commit until the last one from Pau on August 13. It
could of course also be a change in libosmocore?
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all,
as some of you know, I've been working on a small diameteer to GSUP translator,
which allows us to connect a MME like nextepc-mme against osmo-hlr.
The code is still a big ugly hack and needs cleanup, but today I finally
got it to work for authentication and location update.
In case anyone is curious how this looks like, I've attached a pcap file that
includes the S1AP, DIAMETER, GSUP and GTPv2C traffic of an initial LTE registration
happening on a setup running the following programs:
* nextepc MME, SGW, PGW, PCRF
* osmo_diameter2gsup
* osmo-hlr
The point of this is to enable networks to run a shared subscriber
database for 2G, 3G and 4G, which is a very typical use case if you have
existing Osmocom based network and want to extend it with LTE.
We will test this translator extensively at the upcoming CCC Camp, where
all three (2G, 3G and 4G) networks will be running.
The sad part is that we don't yet have a common GGSN and P-GW, which
means that the PDP/PDN context including the IP address will not persist
when moving between 2G+3G on the one hand side and 4G on the other hand
side.
I expect to get the commit history cleaned up and plan to push the
[Erlang] code to git.osmocom.org tomorrow.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello, dear Community,
Has anybody tested how cell handover works in 3G with Osmocom software?
3G network was set up for 35C3: I would like to ask whether anybody
noticed if a cell was reselected "smoothly" by the phone when the user
was moving or it was like a drop of a connection and reconnection to a
different cell afterwards?
So, basically, the question is: Does the handover work in 3G Osmocom?
(single HNBGW and MSC/SGSN)
Thanks.
Kind regards,
Mykola
Hi,
I have been releasing new tagged versions of Osmocom CNI (Osmocom
Cellular Network Infrastructure) related projects over last days this week.
New released versions:
libosmocore 1.2.0
libosmo-abis 0.7.0
libosmo-netif 0.6.0
libusrp 3.4.4
libgtpnl 1.2.1
osmo-trx 1.1.1
osmo-pcu 0.7.0
osmo-ggsn 1.4.0
osmo-pcap 0.1.1
libasn1c 0.9.32
libsmpp34 1.14.0
osmo-bts 1.1.0
osmo-hlr 1.1.0
libosmo-sccp 1.1.0
osmo-mgw 1.6.0
osmo-iuh 0.5.0
osmo-bsc 1.5.0
osmo-msc 1.5.0
osmo-sgsn 1.5.0
openbsc 1.3.1
osmo-sip-connector 1.3.0
Some patch releases may come tomorrow in the event some unexpected error
shows up during repository build process.
Please, to get the latest tags applied, remember to fetch them and clean
up the .version related files. Something like this will do the job (be
careful, git clean may remove some of your changes in the git repo):
$ git fetch --tags; git clean -fxd
Updated tags in OE meta-telephony 201705 will come during current ot
next week.
Regards,
--
- 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
Hi,
I’m trying to configure osmo-bsc to connect to an IPA based MSC and get a
failure when activating the sigtran stack.
Here’s the log:
root@sysmobts-v2:/etc/osmocom# osmo-bsc -c /etc/osmocom/osmo-bsc.cfg
<001d> ../../git/src/osmo_ss7.c:1269 0: ASP Restart for server not
implemented yet!
% Ignoring deprecated logging level everything
% Ignoring deprecated logging level everything
% dyn_ts_allow_tch_f is deprecated, rather use msc/codec-list to pick codecs
<0011> ../../../git/src/vty/telnet_interface.c:104 telnet at 0.0.0.0 4242
<0013> ../../git/src/input/ipaccess.c:853 enabling ipaccess BSC mode on
0.0.0.0 with OML 3002 and RSL 3003 TCP ports
<0018> ../../../git/src/ctrl/control_if.c:866 CTRL at 0.0.0.0 4249
<0008> ../../../git/src/osmo-bsc/osmo_bsc_sigtran.c:427 Initializing SCCP
connection to MSC msc-0
<0008> ../../../git/src/osmo-bsc/osmo_bsc_sigtran.c:437 CS7 Instance
identifier, A-Interface: 0
<001e> ../../git/src/sccp_user.c:397 msc-0: Using SS7 instance 0, pc:0.23.3
<001e> ../../git/src/sccp_user.c:411 msc-0: Creating AS instance
<0005> ../../../git/src/osmo-bsc/osmo_bsc_main.c:504 Failed to initalize
sigtran backhaul.
I used the configuration posted by Harald part of ticker
https://osmocom.org/issues/2544https://osmocom.org/attachments/3154/osmo-bsc.cfg.ipa
and get the same result.
How can I troubleshoot further in order to know what’s happening?
Best regards
Roch.
Hi all,
Doing some testing recently with osmo-sip-connector, I noticed a few
things that seem to be important regarding the user experience of a
network with osmo-sip-connector.
* The osmo-sip-connector is an external MNCC handler interface for one
MSC. The MSC doesn't have any information about what is in the HLR.
When the osmo-sip-connector sends a call towards the MSC, the msc does a
VLR lookup: vlr_subscr_find_by_msisdn() in gsm_04_08_cc.c around line 1860.
if that returns false we are doing mncc_release_ind() with
GSM48_CC_CAUSE_UNASSIGNED_NR. That is getting translated into a SIP
404, which informs the caller that the number was not found. Logical but
it's not correct if the subscriber does actually exist in the HLR.
Actually the same problem exists when using the internal MNCC, If you
call a subscriber that has just switched off their phone, you'll get an
Un Assigned Number error cause. That would be incredibly confusing for
the users. In rhizomatica's case, the audio played back to the caller
would be "The number you have dialed does not exist, please verify it",
while it should obviously be "The number you have dialed is temporarily
unavailable, please try again later."
What we have done there is send the caller to go physically ask ask the
callee why they canceled their phone service, when all they did was
switch off the phone.
SO:
There was some discussion about this at the devcon, I want to outline
some points here, hopefully I understand it right.
* The osmo-sip-connector should ask the HLR if the number exists before
forwarding the call to MNCC.
* There may be more than one MSC, in which case the HLR would inform
osmo-sip-connector about which MSC to use.
* The osmo-sip-connector could either be SIP associated, or MSC
associated, that is to say:
a) one osmo-sip-connector per SIP UA, sip-connector talks to HLR, and
has multiple connections to MSCs (UDP then, not Unix Socket?)
or
b) one osmo-sip-connector per MSC, in which case the SIP UA would have
to somehow query the HLR to ask where to send the call.
Does that all sound correct?
and then.. still a doubt:
IIUC, in the traditional core network. When an MSC receives a MO SETUP
from a local MS, and it does not have this number in the VLR, it should
be querying HLR for routing info, (which may subsequently query another
HLR) no? why are we only doing VLR lookup in the MSC? Is it simply "To
be implemented" ?
thanks!
k/
Dear all,
I've been asked by a number of pepole about a possible Osmocom village at the
CCC Camp 2019. I personally didn't really have any plans, but given related
e-mails and "encouragement" I went ahead and registered an "Osmocom Village",
see
https://signup.c3assemblies.de/assembly/3b8f7aa2-95d5-4c44-aadc-de8f2680e9c3
I also created a wiki page (as nobody else did, despite earlier discussion on IRC,
SCNR) for coordinating related efforts at
https://osmocom.org/projects/osmo-dev-con/wiki/CCC_Camp_2019
One of the bigger questions is about having a tent as well as some tables/benches
to sit on and work. The Camp orga team nas been negotiating rates with a tent
rental company, but to be honest I'm rather surprised by the extremely steep
pricing. The smallest possible tent (6m x 3m) would cost 825 EUR. I'm not
sure we want to raise that amount of money? Even if we'd be 10 people sharing
it, its still 82.50 EUR per person. And that excludes any tables/chairs.
I'm attaching the relevant parts of a mail from the assemblies orga team FYI.
Please note there also is some kind of fragmentation / overlap with the
team planning to run the GSM/3G networks at the camp, see Lynxis'
related post at
https://lists.osmocom.org/mailman/private/osmocom-event-orga/2019-June/0003…
It's questionable whether it makes sense to have tow distinct
'villages', but given that e.g. I don't know anyone of that singularity
city, I'm not sure if we'd either be welcome there, nor whether we'd
want to associate us with them? Also, while the GSM network operation
for sure has good reasons to mingle with the POC and whatever facilities
they have, I'm not sure if the wider Osmocom community attendees
unrelated to the GSM network operation wouldn't just be a
disturbance/nuisance.
In the end, to be honest, I personally do not feel I have the time and
mental capacity to take on any additional tasks in terms of organizing
anything. I just created the entry in c3assemblies as I was asked to,
and I similarly created the related mailing list and wiki page.
So please, anyone interested in making an Osmocom village happen one way
or another, step up [and continue this discussion on the
camp2019-village(a)lists.osmocom.org mailing list, without crossposting
everywhere else :)
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello Vadim,
I'm working on the TTCN3 tests for OsmoPCU. Harald told me, that there
are a few tests existing tests (such as TC_ul_tbf), that had been
developed with osmo-bts-virtual/virt_phy.
He also said that since there is trxcon/fake_trx nowadays, it would be
better to use that instead, if it supports PDCH. From a quick "git
grep", it looks like PDCH is supported in trxcon.
What do you think, should it work well enough to do the switch?
Thanks,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://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
Hello All,
I am working on get OpenBSC connected to a 3rd party MSC, I read from the
Osmo document that I can use the bsc only mode and the osm-bsc instead of
the osmo-nitb.
Currently I had osmo-trx-uhd, osmo-bts-trx, osmo-bsc, and osmo-stp
configured and and running, but I see a lot of below error logs in the
osmo-stp console:
```````````````````````````
DLSS7 <000c> osmo_ss7.c:1468 asp-asp-dyn-0: xua_srv_conn_cb():
sctp_recvmsg() returned 56 (flags=0x80)
DLM3UA <000f> m3ua.c:722 asp-asp-dyn-0: Received M3UA Message (XFER:DATA)
DLM3UA <000f> m3ua.c:541 asp-asp-dyn-0: m3ua_rx_xfer
DLM3UA <000f> m3ua.c:580 asp-asp-dyn-0: m3ua_rx_xfer(): M3UA data header:
opc=337=0.42.1 dpc=185=0.23.1
DLSS7 <000c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=185=0.23.1 not
local, message is for routing
DLSS7 <000c> osmo_ss7_hmrt.c:258 MTP-TRANSFER.req for DPC 185: no route!
````````````````````````````
On the BSC console, I am seeing a lot of:
```````````````````````````````
<0007> a_reset.c:106 A-RESET(msc-0)[0xb76ce0]{DISC}: (re)sending BSSMAP
RESET message...
<0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC:
RI=SSN_PC,PC=0.23.1,SSN=BSSAP
```````````````````````````````
Can anyone identify what is the issue here?
Appreciates!
Regards,
Weiqi
