> 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
Hello fellow Osmocomers,
I just recently came across and watched Harald's ODC 2018 presentation
about Ericsson RBS 6000. The part that intrigued me: Harald said in
that year that this hardware was available quite inexpensively and
plentifully; he said that a DUG10+RUG pair could be had for around
300 EUR in that year.
My question to the community: what is the current situation 6 y later?
Is there still any above-zero supply of either DUG10+RUG or DUG20+RUS
surplus hardware? If a nonzero supply does exist, what is the typical
price these days?
In that 2018 presentation Harald also mentioned that the successor to
DUG20 was DUS31/DUS41, and that those DUS units (which support GSM,
WCDMA and LTE all in one box) have integrated SIU02 equivalent instead
of native E1 interfaces. Hence question: has anyone in Osmocom cracked
the E1-over-IP protocol spoken by SIU02 and its later incarnations,
allowing Osmocom CNI to drive the GSM part of DUS31 etc, or is such
operation beyond our current community capabilities?
There are rumors going around that T-Mobile USA may be shutting down
some Ericsson 2G equipment (though I still never got any clear answers
as to what equipment it might be, if any), hence I am trying to brush
up on my knowledge of this platform.
M~
Hello, I tried using the osmocom stack with the usrp1 and I
encountered this error :
DMAIN NOTICE Starting the transceiver (Transceiver.cpp:287)
DDEV NOTICE Setting TX gain to 0 dB. (USRPDevice.cpp:265)
DDEV NOTICE Setting RX gain to 20 dB. (USRPDevice.cpp:292)
DDEV NOTICE Setting TX gain to 0 dB. (USRPDevice.cpp:265)
DDEV NOTICE Setting TX gain to 0 dB. (USRPDevice.cpp:265)
DDEV NOTICE Setting TX gain to 0 dB. (USRPDevice.cpp:265)
DMAIN NOTICE Stopping the transceiver (Transceiver.cpp:345)
after that the osmo-trx-usrp1 seems to crash.
I know it is not supported anymore but any possible fix would be appreciated.
here is my system and log files together with a pcap :
System : Debian 12 amd64
using osmocom-nightly repo (the stable repo still gives the same error)
