> I don't understand. This callback will be called with data you need to
write
> to the network. In case of MTP Level3 you will need to wrap that around
the
> msgb you got.
I means: is the interaction with mtp3 layer implemented (is sending sccp
data by mtp3 implemented by the library?)?
Also, what about the reception of data from mtp3 layer. is that implemented
in the sccp lib.
I am asking these questions because I see the code of mtp3 in the lib but no
significant call is present in the sccp part of the lib.
Thank you for your help.
On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote:
> [translated from german]
> is it certain that we switch a channel to PDCH only when
> gprs mode != none?
A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we
send a PDCH ACT message.
We send a PDCH ACT message
- during init (CHANNEL OML's state changed to enabled -> send PDCH ACT),
- and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH.
So the question is, when we receive a channel release ack, could that be
the PDCH release and we switch PDCH right back on by accident? No, because
we only receive a chan rel ack when the *TCH/F* is being released.
That is because the PDCH release is initiated "internally" from the PDCH
DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches
on, which existed before dyn PDCH:
if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) {
LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n",
gsm_lchan_name(lchan));
return 0;
}
In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but
not in the rsl_rx_dyn_pdch().
This is analogous to the ip.access way -- the ip.access nanobts replies to
a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel
release ack.
Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH
for clarity? (But we shouldn't actually send a release ack, to stay
compatible.)
Even though it works as-is, we should indeed add another flag check:
- We do check the flags that no ACT/DEACT is already pending;
- And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE;
- But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE.
This should never happen, but it would make sense to ensure that.
~Neels
Hi,
My name is Brackley Cassinga Form DRC, we run a community network called
pamoja net where we offer gsm services using osmocom open source software
and OC Base station.
Recently I have tried to install another base station as the same installed
but I could not find any resource guiding through all the steps to take to
run NIB on a base station.
I'm currently running Ubuntu and I will appreciate if you could guide me on
the installation of BSC,hlr,MSC , in order to run a basic gsm network.
Thank you. Regards
--
*Ir Brackley heshima Casinga **Pacifique*
*CEO and Founder of kwanzatechnologie*
KwanzaTechnologies ,GlobalElectronics
+243977265291 | +243977265291 | Pcassinga(a)gmail.com/
brackley(a)ensemblepourladifference.org
www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> |
Skype: Brackley cassinga <https://webapp.wisestamp.com/#>
Av Semliki N 43
Hi Neels,
some week[s] ago, you mentioned that the D-GSM merge is blocked around
the question on how the Global Title vs. IPA-name is to be resolved.
Sorry for not getting back any sooner, but I am simply not finding the
required amount of time to investigate this topic at the moment.
My personal opinion is that it should be a binary blob (buffer + length)
and nobody should make any assumptions about the contents. This way we
can store whatever we want in it, and I believe we're increasing possible
use cases where our HLR would have to work with "stateless" translators
between GSUP and MAP. After all, let's say we receive a LU from a subscriber
roaming in MAP-land, then that request arrives with the GT of the MSC/VLR.
If we can natively "digest" such values, then the translator would not require
any state beyond the currently processed transaction (LU/ISD). If we can not,
then the translator would have to keep long-term state such as tables to map
MAP-GT to IPA name or the like. And that's of course more effort there,
and volatile state that you'd need to synchronize in case of high availability
or fail-over scenarios, etc.
I of course also know none of this is any current use case that any of
the sysmocom customers is funding sysmocom (and hence you) to spend time
on.
So in the end, I'll leave it to you to decide. If you think the effort
for becoming "buffer+length" aware is relatively minimal (let's say up
to two days?) then by all means, implement that. If you think it's more
work, then please go for the faster route of not considering
non-NUL-terminated strings as identifiers for "GSUP" peers.
In any case, I am happy to merge the D-GSM patch series once you think
it should be merged. I put it in your trusted hands. After all, we had
a tagged release only 7 commits ago (well, 5 of those are actually
already D-GSM related) in osmo-hlr, and should there be any fall-out
from the merge, we still have quite some time until some new tagged
release will happen a few months down the road.
Thanks!
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)
Hi All,
I have been dealing with a weird issue in the past couple of days. I needed to quickly check something about some phones, therefore I created an Osmocom CNI based 2G network. I have done this multiple times in the past even with OsmocomBB transceiver, however in the past some years I was not active in 2G, was more focused on 4G.
I was very happy to see, that all familiar things I initially liked about osmocom are still in place/improved a lot (meaningful config files, simple VTY interface, a LOT more and better documentation). So the network is up and running fine, the setup consists of a laptop and a USRP B210 without GPSDO.
Then I tried to attach some phones to it, and hit an issue:
* Samsung S6, S7 - does not detect the network, even if I put in a SIM card that has previously been in a phone that was already attached
* iPhone X - does not detect the network
I first fiddled with the power settings, basically trying to turn it down a little bit (initially tx attenuation was at 0, so I turned it 10-20), because range is not needed, but I know distortion can happen when driving SDR HW to its max capacity.
No change in the above.
Then I turned quickly to gr-gsm and rtl-sdr to see if I'm transmitting properly, the network was detected and C0 decoded properly.
Next I tried with a Motorola C115 (yeah, I still have some lying around :)), and it attached to the network without any issue. Finally something that works as expected, right?
Last but not least I tried with a Nokia 4.2 phone, which also attached to the network immediately without any issue.
So the bottom line is: what could cause this behavior? Is it possible that the USRP B210's accuracy is just not enough for newer phones? If yes how come the Nokia still attached, it is quite a recent phone with Qcomm chipset. I was also thinking if it is a Samsung vs Qualcomm thing, but then the iPhone should have at least detected the network. I tried with different SIM cards as well (not that it would make any difference...but I didn't have any better idea), and also with different bands and ARFCNs (900 and 1800). Antenna used is a VERT900.
Configuration: unmodified standard config that came with the binary packages - except for MCC, MNC, rx gain, tx attenuation and max_power_red.
I also tried to specify valid and also 'invalid' (unknown) MCC-MNC combinations to see if maybe newer Android/iOS only lists networks that advertise a known combination (again this would be very weird, but I just had no better ideas in the end).
Anybody have any recent experience with COTS MSs and OsmoBTS(-TRX) based network?
Any input is much appreciated, thanks.
Cheers,
Domi
p.s. It is simply awesome to experience the power of opensource when dealing with 2G. Every step of the way above I was using software created and shared by you guys. It is a great feeling, had to share it :-).
Hi,
I follow this tutorial : Version 10 - History - Cell Broadcast - Cellular Network Infrastructure - Open Source Mobile Communications for doing CBS with limesdrmini but it doesn't run , is it due to that limesdrmini doesn't support the command telnet to osmo-bsc at port 4242, and enter something likeor i do something wrong.
Chears,
|
|
| |
Version 10 - History - Cell Broadcast - Cellular Network Infrastructure ...
Redmine
|
|
|
The commercial MS see the network and i could send sms and call with it.
the Limesdrmini doesn't support CBS?
Le mercredi 12 février 2020 à 20:57:52 UTC, openbsc-request(a)lists.osmocom.org <openbsc-request(a)lists.osmocom.org> a écrit :
Send OpenBSC mailing list submissions to
openbsc(a)lists.osmocom.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osmocom.org/mailman/listinfo/openbsc
or, via email, send a message with subject or body 'help' to
openbsc-request(a)lists.osmocom.org
You can reach the person managing the list at
openbsc-owner(a)lists.osmocom.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenBSC digest..."
Today's Topics:
1. CBS + Osmocom + LimeSDR-Mini (Radiarisainana Sitraka)
2. CBS + ETWS + CMAS + Limesdrmini (Radiarisainana Sitraka)
3. Re: Commercial MSs do not see the network (Tomcs?nyi)
4. Re: Commercial MSs do not see the network (Joachim Steiger)
----------------------------------------------------------------------
Message: 1
Date: Wed, 12 Feb 2020 19:12:17 +0000 (UTC)
From: Radiarisainana Sitraka <radiarisainanasitraka(a)yahoo.fr>
To: "openbsc(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org>
Subject: CBS + Osmocom + LimeSDR-Mini
Message-ID: <647375309.3679103.1581534737485(a)mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I'm testing CBS LimeSDR-Mini with osmocom by following this
Version 10 - History - Cell Broadcast - Cellular Network Infrastructure - Open Source Mobile Communications
|
|
| |
Version 10 - History - Cell Broadcast - Cellular Network Infrastructure ...
Redmine
|
|
|
h4. make sure your related BTS is configured to use a channel combination with CBCH For using a combined CCCH with SDCCH/4 and CBCH you can use the following example snippet as part of osmo-bsc.cfg:
network bts 0 trx 0 timeslot 0 phys_chan_config CCCH+SDCCH4+CBCH
Hello,
I'm testing CBS LimeSDR-Mini with osmocom by following this
Version 10 - History - Cell Broadcast - Cellular Network Infrastructure - Open Source Mobile Communications
|
|
| |
Version 10 - History - Cell Broadcast - Cellular Network Infrastructure ...
Redmine
|
|
|
h4. make sure your related BTS is configured to use a channel combination with CBCH For using a combined CCCH with SDCCH/4 and CBCH you can use the following example snippet as part of osmo-bsc.cfg:
network bts 0 trx 0 timeslot 0 phys_chan_config CCCH+SDCCH4+CBCH
