Dear all,
I'm pleased to announce new tagged releases for Osmocom Cellular Network
Infrastructure components.
libosmocore 1.3.0
osmo-gsm-manuals 0.3.0
osmo-pcap 0.1.2
osmo-ggsn 1.5.0
libosmo-abis 0.8.0
libosmo-netif 0.7.0
libosmo-sccp 1.2.0
osmo-sip-connector 1.4.0
osmo-hlr 1.2.0
osmo-trx 1.2.0
osmo-bts 1.2.0
osmo-pcu 0.8.0
osmo-mgw 1.7.0
osmo-iuh 0.6.0
osmo-bsc 1.6.0
osmo-msc 1.6.0
osmo-sgsn 1.6.0
openbsc 1.3.2
Tags for related Openembedded meta layers have also been updated and are
waiting to be merged, hopefully today, and will be available in branch
201705.
Other related components such as libgtpnl or libsmpp34 had no
development at all since last release cycle so they don't show up here.
As a reminder, last release cycle was done around August 2019.
Have fun,
--
- 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 All
I've used osmo-bsc in non standalone mode ie seperate components and all
works fine voice and sms work as should. However when introducing. sip
connector with asterisk the handsets will not make voice calls they just
constantly respond network busy. I'm using osmo bts-trx with osmo-trx-lms
on raspbian 10 below is Asterisk config. Any help would be appreciated.
Gar
[GSM]
type=friend
host=127.0.0.1
dtmfmode=rfc2833
canreinvite=no
disallow=all
allow=gsm
context=gsmsubscriber
port=5062
HI
I just tried to use limesd mini with osmocom cni and i used this script to
launch all the items :
#!/bin/sh cmd="${1:-start}" set -ex systemctl $cmd
<https://twitter.com/search?q=%24cmd&src=cashtag_click> osmo-hlr osmo-msc
osmo-mgw osmo-ggsn osmo-sgsn osmo-stp osmo-bsc osmo-hnbgw osmo-pcu
osmo-trx-lms osmo-bts-trx
everything seems work fine,only the osmo-trx-lms :
osmo-trx-lms[7995]: Sun Dec 8 18:02:03 2019 DLMS <0003> LMSDevice.cpp:94
> [tid=140437169072832] Reference clock 40.00 MHz
> osmo-trx-lms[7995]: Sun Dec 8 18:02:03 2019 DDEV <0002>
> LMSDevice.cpp:192 [tid=140437169072832] Init LMS device
> osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DDEV <0002> LMSDevice.cpp:99
> [tid=140437169072832] Sample Rate: Min=100000 Max=3.072e+07 Step=0
> osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DDEV <0002>
> LMSDevice.cpp:228 [tid=140437169072832] Setting sample rate to 1.08333e+06 4
> osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DDEV <0002>
> LMSDevice.cpp:234 [tid=140437169072832] Sample Rate: Host=1.08333e+06
> RF=3.46667e+07
> osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DMAIN <0000>
> LMSDevice.cpp:209 [tid=140437169072832] Antennas configured successfully
> osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DMAIN <0000> Threads.cpp:117
> [tid=140437098583808] Thread 140437098583808 (task 8127) set name:
> CtrlService0
> osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DMAIN <0000>
> osmo-trx.cpp:528 [tid=140437169072832] -- Transceiver active with 1
> channel(s)
> osmo-trx-lms[7995]: Sun Dec 8 18:02:05 2019 DTRXCTRL <0001>
> Transceiver.cpp:773 [tid=140437098583808][chan=0] command is 'POWEROFF'
> osmo-trx-lms[7995]: Sun Dec 8 18:02:05 2019 DTRXCTRL <0001>
> Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP POWEROFF
> 0'
>
i am using the default .cfg files !
Thanks.
Hi Oliver, Neels, community,
I had some comments on the D-GSM work that didn't really fit directly to
the gerrit code review, and I thought I'd post it here.
== DNS zone / .msisdn suffix ===
One question I had was regarding the use of the .{msisdn,imsi} TLD. I would argue
it is probably besser to use something that fits within the existing DNS hierarchy
without contesting IANA's authority on gTLDs.
Historically, ETSI/3GPP made the mistake of using ".gprs" for resolving APNs
on the GRX. This was later changed to something with 3gppnetwork.com or the like,
hwere that domain would actually be registered by 3GPP with normal domain registrars,
but without any publicly accessible zone records. This way the name is reserved
in the public hierarchy and no risk of clashes.
I'm not sure how much of a concern this is to us, given that our use
case is much more niche than the GRX. However, the "cost" is probably
rather small to change this to something like
.{msisdn,imsi}.dgsm.osmocom.org ? Sure, the packets will get larger by
a few bytes, but given all the other overhead I think it's not really
going to have any impact?
What are your thoughts on that?
== MSISDN format ==
Another thought is whether or not there are any concerns regarding the
MSISDN format. Historically, this is one of the weaknesses of OsmoMSC,
inherited from the OpenBSC days where we just thought in terms of PBX
extension numbers. In reality, a MSISDN consist of a TON (type of
number), NPI (numbering plan indicator) and the related digits. IIRC,
in the TON one can also specify if it's supposed to be national or
international, i.e. if it's prefixed with the country code or not.
It would be great to make sure that the format used in the mDNS queries
is somewhat standardized, if not at least only by the documentation
requiring that all queries should be done in fully qualfiied form with
country code present. NPI is sort-of bogus as IMOH E.164 is the only
one applicable for MSISDN.
Any thoughts?
== The use of 'age' vs. absolute timestamp ==
In my original D-GSM idas I always thought we'd send an absolute UTC
timestamp when a given HLR/MSC has ever seen that subscriber. The idea
here being that any rural GSM network will have some kind of GNSS
recevier for clock stability in the BTS anyway, and one can hence assume
that timestamps are synchronized.
The advantage of a relative 'age' is obvious: You don't care about the
absolute clock value being correct anymore. The potential downside is
that propagation delay might matter. If you have a rather slow / loaded
geostationary sattelite link from one village, but a faster terrestrial
link from another village, the 'age' will be ambiguous while an absolute
timesetamp wouldn't have that.
Given that the delays we're talking about are probably all sub-second or
maybe possible about 1s, it's probably not a problem.
== GSUP keepalives / connection loss detection ==
In the presence of unreliable back-haul mesh between villages, the GSUP
connection can also not be seen as reliable. We would expect to see TCP
stalls due to packet loss, etc.
Have you considered this in your implementation and/or done any testing
based on simulated lossy networks to ensure we properly use either TCP
keepalives or IPA application-level PING/PONG to detect lost connections
and recover from such situations (by closing the old and
re-establishing)?
Unreliable networks can be easily simulated by Linux built-in 'tc netem'
for providing configurable packet loss / latency / jitter.
I also saw some comments / code related to "if a second connection using
the same IPA ID arrives, we're screwed" (paraphrasing here). I would
expect this not to be uncommon even if every MSC/HLR out there is
configred correctly exactly because e.g .the remote MSC/HLR has already
decided that the TCP/GSUP is dead and starts to reconnect by performing
a local-end release, while the "local" MSC/HLR still thinks the old
connection is alive. If the old connection "wins" (i.e. is preferred)
I see potential trouble here.
Situations like that probably warrant some carefully designed tests to
create exactly those situations.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hey,
yes, I ll drop one NanoBTS in Berlin, at Afra or Sysmocom before the first day of the conference.
Im not sure, if Ill be able to do so this week.
It actually belongs to Sysmocom / Harald.
Best regards,
circle
------
Dear all,
36c3 is going to happen soon, and as usually we're planing to setup
our own GSM/UMTS network (LTE is to be discussed). While we do have
enough UMTS NodeB units, we're looking for heroes who could sacrifice
their GSM base stations (preferably sysmoBTS or nanoBTS) for the
duration of the congress. Note that we're not considering SDRs (unless
somebody with a strong aspiration wants to ensure proper clock
distribution, filtering, power amplification, etc).
Please let us know 1) how many (and what kind of) units we could
borrow from you, 2) can you bring them to Leipzig before the first
day, or can you drop them somewhere in Berlin (Sysmocom? AfRa?).
Thanks!
On behalf of the GSM team,
Vadim Yanitskiy.
Dear fellow Osmocom developers,
I would like to invite all developers and contributors to Osmocom [sub]projects
to register for OsmoDevCon 2020 (held on April 24th-27th, 2020 in Berlin).
For details known so far, please check
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020
Please enter your name at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020#Requested
in case you would like to attend. Registering early allows proper
planning. Thanks!
Looking forward to meeting old and new Osmocom developers in April 2020.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom developers,
the number of branches in many repositories (most notably libosmocore)
is growing to a rather large number, and I would like to encourage everyone
to have a quick look about which branches can be deleted by now (and delete
them, if no longer needed).
Thanks!
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear all,
36c3 is going to happen soon, and as usually we're planing to setup
our own GSM/UMTS network (LTE is to be discussed). While we do have
enough UMTS NodeB units, we're looking for heroes who could sacrifice
their GSM base stations (preferably sysmoBTS or nanoBTS) for the
duration of the congress. Note that we're not considering SDRs (unless
somebody with a strong aspiration wants to ensure proper clock
distribution, filtering, power amplification, etc).
Please let us know 1) how many (and what kind of) units we could
borrow from you, 2) can you bring them to Leipzig before the first
day, or can you drop them somewhere in Berlin (Sysmocom? AfRa?).
Thanks!
On behalf of the GSM team,
Vadim Yanitskiy.
Somehow osmo-hlr is no longer building in OBS for a variety of targets
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
I noticed the MSC test that wants osmo-msc to repeat a Paging to the BSC and
hNodeB.
After fixing the Iu tests, I wanted to get this last ttcn3-msc-test working, so
I was about to implement repeated Paging from osmo-msc, but the more I think
about it, the less it makes sense to me.
The commit log in osmo-ttcn3-hacks says:
Repeating will improve the reachability of MS when a Paging is lost
or not received because the MS is moving between states.
This reasoning seems flawed to me, because the BSC / hNodeB is between the MSC
and the MS, and the BSC *does* repeat Paging. That should cover MS moving
between states.
The link between MSC and {BSC,hNodeB} is considered reliable, and AFAICT
nothing really gets better when repeating a Paging request to the BSS.
It could make sense to maybe repeat Paging with a larger/more general Cell
Identifier List? But why not send the full list in the first place?
Also 3GPP TS 48.008 3.1.10 Paging says:
A single PAGING message across the MSC to BSS interface contains information
on the cells in which the page shall be broadcast.
I interpret the "A single" as: there is no repetition of Paging requests toward
the BSS, and that's also what makes most sense to me infrastructurally.
Is there any spec indicating repeated Paging from the MSC?
I would actually remove the test TC_lu_and_mt_sms_paging_repeated.
If that's the wrong call, we should specify how osmo-msc should repeat Paging.
Before that, having the test makes little sense...
What do you guys think?
~N
