9 Apr
2016
9 Apr
'16
12:55 a.m.
Hi Harald,
On Wed, Apr 6, 2016 at 12:59 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
Can you or somebody else interested in getting this
resolved provide a
full bug report, including
* debug log output on OsmoNITB side for for the rsl and nm
* debug log output on OsmoBTS side for oml / transceiver interface or
anything else related
* pcap file of A-bis traffic between OsmoBTS and OsmoNITB, as well as
the control commands between osmo-bts-trx and osmo-trx
Attached are the logs for master branches of OpenBSC, OsmoBTS, and
OsmoTRX leading up to the following RACH access behavior.
<0004> abis_rsl.c:1423 BTS 0 CHAN RQD: no resources for SDCCH 0x2
Hopefully, somebody more familiar than myself with A-bis and related
L1/L2 dependencies can provide some insight on why the above is
happening or where to start debugging. I'll be happy to test any
subsequent changes or look into specific parts of the A-bis code.
-TT
9 Apr
9 Apr
10:49 a.m.
Hi Tom and list,
On Fri, Apr 08, 2016 at 03:55:42PM -0700, Tom Tsou wrote:
Hopefully, somebody more familiar than myself with
A-bis and related
L1/L2 dependencies can provide some insight on why the above is
happening or where to start debugging.
Everything seems fine up and until frame 225, but in frame 226, the BSC
is sending another "Set BTS Attributes". This message re-sets a lot of
the other managed objects and results in the transceiver (and channels)
being disabled again(Frame 230..233), which means the BSC cannot
activate any logical channel.
"Set BTS Attributes" is originally sent in frame 23, and at the moment
Im not quite sure yet why that happens.
So basically everythign looks fine and is brought up correctly,
including all the channels (aka timeslots), but then one message
destroys it all.
I'll be happy to test any subsequent changes or
look into specific
parts of the A-bis code.
Thanks in advance.
--
- 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)
12:25 p.m.
On Sat, Apr 09, 2016 at 10:49:41AM +0200, Harald Welte wrote:
"Set BTS Attributes" is originally sent in
frame 23, and at the moment
Im not quite sure yet why that happens.
Actually, it's more complicated than that
The entire block of
* Baseband Transceiver: Change Admin State Unlocked + ACK
* Baseband Transceiver: Opstart + ACK
* Baseband Transceiver: State Chg Event Report Enabled OK
* Baseband Transceiver: IPA RSL Connect + ACK
happens once at frame 73...84, but then is repeated at frame 212..221.
In that second occurrence, it is followed immediatey by the surplus "Set
BTS Attributes" in frame 226.
There is only a single location in the BSC code where we send a "Change
Administrative State Unlocked" for the "Baseband Transceiver" MO, and
that is triggered by a Software Activation Report for the Baseband
Transceiver from the BTS to BSC, see sw_activ_rep() in
bts_ipaccess_nanobts.c, around line 450.
However, there is also only a single instance of a "Software Activation
Report" for the "Baseband Transceiver" in the protocol trace, and
that's
in frame 26. So I currently fail to see why it would happen again from
frame 212 on. Or rather, why would it happen already in frame 26?
According to Chapter Figure 4 of our A-bis/IP protocol specification at
http://ftp.osmocom.org/docs/latest/osmobts-abis.pdf
the software activated erport should only happen after
* the BTS/MO requesting to activate the software (SW Activate Req)
* the BSC acknowledging that (SW Activate Req Ack)
* the BSC instructing the BTS to activate the software (Activate SW)
* the BTS/MO acknowledging that (Activate SW Ack)
So the root question is: What is it, that osmo-bts-trx could possibly do
to cause this. "oml_mo_tx_sw_act_rep(&trx->bb_transc.mo);" is what
sends the software activation report on the baseband transceiver.
Looking at the got log, the above function call of
oml_mo_tx_sw_act_rep() for the baseband transceiver was always sent
unconditionally from within check_tranceiver_availability() even in
Jolly's original osmo-bts-trx code from February 2013, see commit
acc71ffb4b61b3354bbb2fa14981e4e6a46946e6. THe code even states that iti
s a HACK and it should only be done once we receive CLOCK indications
from osmo-trx. However, even that is wrong, as CLOCK is already
received in Frame 11, too soon to make that a criterion.
In the osmo-bts-{sysmo,litecell15,octphy} backends, the related
oml_mo_tx_sw_act_rep() is generated from activate_rf_compl_cb(), i.e.
after the transceiver hardware has confirmed activation of the radio
carrier, which is again the result of asking for activation via
l1if_activate_rf(), which in turn is called from info_compl_cb() which
is called from l1if_get_info(), which is called from reset_compl_cb(),
which is ther result of l1if_reset(), which is called from l1if_open(),
which is called from bts_model_phy_link_open(), which is called from
main. So we also don't do it properly with regard to the 'software
activate request / ... state machine, but it apparently happens in any
case at a much later point in the initialization sequence.
Summary:
* all osmo-bts backends are cheating in terms of OML initialization
and don't go through the full sequence
* osmo-bts-trx seems to send the sowftware activation report for the
baseband transceiver at a much too early point, before other MO's
higher up in the hierarchy (BTS MO, Site Manager) MOs have even been
started.
* osmo-bts-sysmo is "lucky" in that due to the long code path and plenty
of L1 interactions before sendding the SW activation report take
sufficiently long that all the other initialization has already passed
until then.
Solution:
* OML initialization (the most complex part of Abis) needs to be
more properly handled. No part of the code should do something like
dynamically sending software activation reports at runtime. In
osm-bts-trx, every time 'transceiver_available' goes from 0->1 (which
apparently can happen even after start), a software activation report
is sent to the BSC. This is wrong. The software is only activated
once during boot, and it is activated not before the parent MOs for
BTS and Site Manager are enabled.
Unrelated to that, osmo-bts-trx desparately needs to avoid the use of
global variables. Each gsm_bts_trx / gsm_bts / phy_link / phy_instance
has private data store for implementation-specific state. global
variables have always been discouraged.
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)
12 Apr
12 Apr
2:04 a.m.
Harald,
Thank you for the thorough log analysis which is greatly helpful.
On Sat, Apr 9, 2016 at 3:25 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
Looking at the got log, the above function call of
oml_mo_tx_sw_act_rep() for the baseband transceiver was always sent
unconditionally from within check_tranceiver_availability() even in
Jolly's original osmo-bts-trx code from February 2013, see commit
acc71ffb4b61b3354bbb2fa14981e4e6a46946e6. THe code even states that iti
s a HACK and it should only be done once we receive CLOCK indications
from osmo-trx. However, even that is wrong, as CLOCK is already
received in Frame 11, too soon to make that a criterion.
I noticed the behavior surrounding check_transceiver_availability()
seemed suspect, but I wasn't sure about related effects. Indeed, if I
restrict sections of check_transceiver_availability() containing
oml_mo_tx_sw_act_rep() to running once, I am able to reach a
functional OML setup (sometimes to the point of TCH channel
establishment).
Related is the question of when osmo-trx should send CLOCK
indications. Right now a CLOCK indications is sent with arrival of
commands on the control interface. After starting, CLOCK indications
are sent at an one second interval (216 frames). The indications sent
from the control interface are why osmo-bts is receiving CLOCK so
early.
Solution:
* OML initialization (the most complex part of Abis) needs to be
more properly handled. No part of the code should do something like
dynamically sending software activation reports at runtime. In
osm-bts-trx, every time 'transceiver_available' goes from 0->1 (which
apparently can happen even after start), a software activation report
is sent to the BSC. This is wrong. The software is only activated
once during boot, and it is activated not before the parent MOs for
BTS and Site Manager are enabled.
I can confirm that the sending of SW activation reports is currently
broken and prevents usable operation with osmo-bts-trx. To start, I'll
look into a better approach to the 'transceiver_available' state and
limiting SW activation messages. Hopefully that can at least get us to
a usable state with osmo-bts-trx.
Unrelated to that, osmo-bts-trx desparately needs to
avoid the use of
global variables. Each gsm_bts_trx / gsm_bts / phy_link / phy_instance
has private data store for implementation-specific state. global
variables have always been discouraged.
Agreed and noted.
-TT
13 Jun
13 Jun
5:08 p.m.
Hi.
I'd like to get back to the status of this one. Are there any patches
available somewhere which I could try? Do we have a ticket to track this
or shall I make one?
On 04/12/2016 02:04 AM, Tom Tsou wrote:
Harald,
Thank you for the thorough log analysis which is greatly helpful.
On Sat, Apr 9, 2016 at 3:25 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
--
Max Suraev <msuraev(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
Looking at the got log, the above function call
of
oml_mo_tx_sw_act_rep() for the baseband transceiver was always sent
unconditionally from within check_tranceiver_availability() even in
Jolly's original osmo-bts-trx code from February 2013, see commit
acc71ffb4b61b3354bbb2fa14981e4e6a46946e6. THe code even states that iti
s a HACK and it should only be done once we receive CLOCK indications
from osmo-trx. However, even that is wrong, as CLOCK is already
received in Frame 11, too soon to make that a criterion.
I noticed the behavior
surrounding check_transceiver_availability()
seemed suspect, but I wasn't sure about related effects. Indeed, if I
restrict sections of check_transceiver_availability() containing
oml_mo_tx_sw_act_rep() to running once, I am able to reach a
functional OML setup (sometimes to the point of TCH channel
establishment).
Related is the question of when osmo-trx should send CLOCK
indications. Right now a CLOCK indications is sent with arrival of
commands on the control interface. After starting, CLOCK indications
are sent at an one second interval (216 frames). The indications sent
from the control interface are why osmo-bts is receiving CLOCK so
early.
Solution:
* OML initialization (the most complex part of Abis) needs to be
more properly handled. No part of the code should do something like
dynamically sending software activation reports at runtime. In
osm-bts-trx, every time 'transceiver_available' goes from 0->1 (which
apparently can happen even after start), a software activation report
is sent to the BSC. This is wrong. The software is only activated
once during boot, and it is activated not before the parent MOs for
BTS and Site Manager are enabled.
I can confirm that the sending of SW
activation reports is currently
broken and prevents usable operation with osmo-bts-trx. To start, I'll
look into a better approach to the 'transceiver_available' state and
limiting SW activation messages. Hopefully that can at least get us to
a usable state with osmo-bts-trx.
Unrelated to that, osmo-bts-trx desparately needs
to avoid the use of
global variables. Each gsm_bts_trx / gsm_bts / phy_link / phy_instance
has private data store for implementation-specific state. global
variables have always been discouraged.
Agreed and noted.
-TT
6:04 p.m.
Hi Tom and others,
On Mon, Apr 11, 2016 at 05:04:13PM -0700, Tom Tsou wrote:
Related is the question of when osmo-trx should send
CLOCK
indications. Right now a CLOCK indications is sent with arrival of
commands on the control interface. After starting, CLOCK indications
are sent at an one second interval (216 frames). The indications sent
from the control interface are why osmo-bts is receiving CLOCK so
early.
I don't know, to be honest. I didn't write osmo-bts-trx. Other PHY
layers we interact send us information on the GSM frame number with
every frame number increment.
We also receive PH-ReadyToSend.ind in line with GSM PHY layer
specifications for each frame to be sent. osmo-bts simply responds to
those and all clock handling is entirely in the PHY.
As osmo-trx dosen't do that (it's only half of a PHY layer), the
missing part (scheduler) is implemented inside osmo-bts-trx. This
scheduler is then generating the equivalent of the PH-ReadyToSend.ind
towards the L1SAP and the common part of OsmoBTS.
So in osmo-bts-trx it seems that there is code in trx_sched_clock() that
tries to generate the frame numbers locally in between perios of no
"CLOCK IND" from osmo-trx by starting an osmo_timer for it. This seems
a bit ugly but of course reduces the number of UDP packets that we need
to process.
If osmo-bts-trx users have not experienced any timing related issues, I
think there is no reason to introduce any changes itno this part, i.e.
keep the frequency of the "CLOCK IND" frames as-is, to also remain
compatible with other OpenBTS-like transceiver implementations.
--
- 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)
8:39 p.m.
On Mon, Jun 13, 2016 at 7:04 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
On Mon, Apr 11, 2016 at 05:04:13PM -0700, Tom Tsou
wrote:
I don't remember issues with this part, but looking into the code I
don't see much log printing there, so even if we encountered them,
they probably wen unnoticed. Which is not a good behavior.
I personally think that sending CLOCK IND every frame is a good idea.
if we do this, we only need to check for lost CLOCK IND's and the code
becomes much simpler. We're already sending 8 times more UDP packets
even in idle mode (8 downlink bursts per frame), and 16 times more in
fully loaded mode (downlink + uplink), and if we're running multi-TRX
system, than proportion is even higher. We can do more 'perf'
monitoring, but my feeling is that the impact will be a minor. If we
find that UDP adds significant overhead, we can switch to a more
efficient IPC (UNIX sockets?), but I seriously doubt that this will be
needed.
As a side note, we (Fairwaves) will be able to look into these issues
deeply only in a few months in the best case. So if there are any
volunteers who want to get all these issues fixes before that, don't
hold your breath.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
Related is the question of when osmo-trx should
send CLOCK
indications. Right now a CLOCK indications is sent with arrival of
commands on the control interface. After starting, CLOCK indications
are sent at an one second interval (216 frames). The indications sent
from the control interface are why osmo-bts is receiving CLOCK so
early.
I don't know, to be honest. I didn't write osmo-bts-trx. Other PHY
layers we interact send us information on the GSM frame number with
every frame number increment.
We also receive PH-ReadyToSend.ind in line with GSM PHY layer
specifications for each frame to be sent. osmo-bts simply responds to
those and all clock handling is entirely in the PHY.
As osmo-trx dosen't do that (it's only half of a PHY layer), the
missing part (scheduler) is implemented inside osmo-bts-trx. This
scheduler is then generating the equivalent of the PH-ReadyToSend.ind
towards the L1SAP and the common part of OsmoBTS.
So in osmo-bts-trx it seems that there is code in trx_sched_clock() that
tries to generate the frame numbers locally in between perios of no
"CLOCK IND" from osmo-trx by starting an osmo_timer for it. This seems
a bit ugly but of course reduces the number of UDP packets that we need
to process.
If osmo-bts-trx users have not experienced any timing related issues, I
think there is no reason to introduce any changes itno this part, i.e.
keep the frequency of the "CLOCK IND" frames as-is, to also remain
compatible with other OpenBTS-like transceiver implementations.
14 Jun
14 Jun
10:07 a.m.
Which branch is used in practice? I've looked at gerrit/fairwaves/master
and the difference seems pretty small so I'm puzzled as to which commit
fixes it.
On 06/13/2016 08:39 PM, Alexander Chemeris wrote:
On Mon, Jun 13, 2016 at 7:04 PM, Harald Welte
<laforge(a)gnumonks.org> wrote:
--
Max Suraev <msuraev(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
On Mon, Apr 11, 2016 at 05:04:13PM -0700, Tom
Tsou wrote:
I don't
remember issues with this part, but looking into the code I
don't see much log printing there, so even if we encountered them,
they probably wen unnoticed. Which is not a good behavior.
I personally think that sending CLOCK IND every frame is a good idea.
if we do this, we only need to check for lost CLOCK IND's and the code
becomes much simpler. We're already sending 8 times more UDP packets
even in idle mode (8 downlink bursts per frame), and 16 times more in
fully loaded mode (downlink + uplink), and if we're running multi-TRX
system, than proportion is even higher. We can do more 'perf'
monitoring, but my feeling is that the impact will be a minor. If we
find that UDP adds significant overhead, we can switch to a more
efficient IPC (UNIX sockets?), but I seriously doubt that this will be
needed.
As a side note, we (Fairwaves) will be able to look into these issues
deeply only in a few months in the best case. So if there are any
volunteers who want to get all these issues fixes before that, don't
hold your breath.
Related is the question of when osmo-trx should
send CLOCK
indications. Right now a CLOCK indications is sent with arrival of
commands on the control interface. After starting, CLOCK indications
are sent at an one second interval (216 frames). The indications sent
from the control interface are why osmo-bts is receiving CLOCK so
early.
I don't know, to be honest. I didn't write osmo-bts-trx. Other
PHY
layers we interact send us information on the GSM frame number with
every frame number increment.
We also receive PH-ReadyToSend.ind in line with GSM PHY layer
specifications for each frame to be sent. osmo-bts simply responds to
those and all clock handling is entirely in the PHY.
As osmo-trx dosen't do that (it's only half of a PHY layer), the
missing part (scheduler) is implemented inside osmo-bts-trx. This
scheduler is then generating the equivalent of the PH-ReadyToSend.ind
towards the L1SAP and the common part of OsmoBTS.
So in osmo-bts-trx it seems that there is code in trx_sched_clock() that
tries to generate the frame numbers locally in between perios of no
"CLOCK IND" from osmo-trx by starting an osmo_timer for it. This seems
a bit ugly but of course reduces the number of UDP packets that we need
to process.
If osmo-bts-trx users have not experienced any timing related issues, I
think there is no reason to introduce any changes itno this part, i.e.
keep the frequency of the "CLOCK IND" frames as-is, to also remain
compatible with other OpenBTS-like transceiver implementations.
2:21 p.m.
On Tue, Jun 14, 2016 at 11:07 AM, Max <msuraev(a)sysmocom.de> wrote:
Which branch is used in practice? I've looked at
gerrit/fairwaves/master
and the difference seems pretty small so I'm puzzled as to which commit
fixes it.
We're using fairwaves/master, but there is no special "fix" for this
bug there. Something has changed in the generic code (i.e. unrelated
to osmo-trx cupport) since we branched off, and that generic change
broke a (fragile) working state of the code. As Harald mentioned,
A-bis procedures are still pretty much a hack still.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
7:19 p.m.
Hi Max,
On Tue, Jun 14, 2016 at 1:07 AM, Max <msuraev(a)sysmocom.de> wrote:
Which branch is used in practice? I've looked at
gerrit/fairwaves/master
and the difference seems pretty small so I'm puzzled as to which commit
fixes it.
The issue is command timing and improperly handled order of events.
Some time back I checked the diff's between fairwaves/master and
master, but wasn't able to find where the difference in sequencing was
taking place. I'm puzzled about this as well, but, as Harald says, the
real solution is not resolving the differences between fairwaves and
master branches, but properly handling the OML initialization in
master.
The workaround for osmo-bts-trx master is as follows:
1. Remove CLK IND from the osmo-trx control loop
2. Start osmo-trx
3. Start osmo-bts-trx
4. Externally Issue the POWERON command to osmo-trx
This delays CLK IND packets from prematurely reaching osmo-bts and
allows the OML sequencing to take place. This is obviously a hack I
suspect a real fix will involve some modification to the osmo-trx
socket interface.
-TT
7:23 p.m.
I see. Will give it a shot tomorrow. If you have any patches/branches I
can use as a starting point - let me know.
On 06/14/2016 07:19 PM, Tom Tsou wrote:
Hi Max,
On Tue, Jun 14, 2016 at 1:07 AM, Max <msuraev(a)sysmocom.de> wrote:
--
Max Suraev <msuraev(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
Which branch is used in practice? I've looked
at gerrit/fairwaves/master
and the difference seems pretty small so I'm puzzled as to which commit
fixes it.
The issue is command timing and improperly handled order of events.
Some time back I checked the diff's between fairwaves/master and
master, but wasn't able to find where the difference in sequencing was
taking place. I'm puzzled about this as well, but, as Harald says, the
real solution is not resolving the differences between fairwaves and
master branches, but properly handling the OML initialization in
master.
The workaround for osmo-bts-trx master is as follows:
1. Remove CLK IND from the osmo-trx control loop
2. Start osmo-trx
3. Start osmo-bts-trx
4. Externally Issue the POWERON command to osmo-trx
This delays CLK IND packets from prematurely reaching osmo-bts and
allows the OML sequencing to take place. This is obviously a hack I
suspect a real fix will involve some modification to the osmo-trx
socket interface.
-TT
7:43 p.m.
On Tue, Jun 14, 2016 at 10:23 AM, Max <msuraev(a)sysmocom.de> wrote:
I see. Will give it a shot tomorrow. If you have any
patches/branches I
can use as a starting point - let me know.
This branch will remove the CLK IND sending from the non-receive frames.
git://git.osmocom.org/osmo-trx clkind
OML initialization needs to happen on osmo-bts-trx before it starts
receiving CLK IND packets. This means that the osmo-trx POWERON
command needs to be delayed from osmo-bts-trx or sent to osmo-trx
externally. I tested with the latter.
-TT
15 Jun
15 Jun
7:08 p.m.
I've tried it with manually sending POWERON - the issue with CHAN RQD is
gone but the phone still does not work. I'll look into OML/RSL/whatever
is preventing it from working.
On 06/14/2016 07:43 PM, Tom Tsou wrote:
On Tue, Jun 14, 2016 at 10:23 AM, Max
<msuraev(a)sysmocom.de> wrote:
--
Max Suraev <msuraev(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
I see. Will give it a shot tomorrow. If you have
any patches/branches I
can use as a starting point - let me know.
This branch will remove the CLK IND
sending from the non-receive frames.
git://git.osmocom.org/osmo-trx clkind
OML initialization needs to happen on osmo-bts-trx before it starts
receiving CLK IND packets. This means that the osmo-trx POWERON
command needs to be delayed from osmo-bts-trx or sent to osmo-trx
externally. I tested with the latter.
-TT
9:38 p.m.
On Wed, Jun 15, 2016 at 10:08 AM, Max <msuraev(a)sysmocom.de> wrote:
I've tried it with manually sending POWERON - the
issue with CHAN RQD is
gone but the phone still does not work. I'll look into OML/RSL/whatever
is preventing it from working.
Make sure that the static variable 'settsc_enabled' is set.
diff --git a/src/osmo-bts-trx/trx_if.c b/src/osmo-bts-trx/trx_if.c
index a4c16dc..8c9a839 100644
--- a/src/osmo-bts-trx/trx_if.c
+++ b/src/osmo-bts-trx/trx_if.c
@@ -47,7 +47,7 @@
//#define TOA_RSSI_DEBUG
int transceiver_available = 0;
-int settsc_enabled = 0;
+int settsc_enabled = 1;
int setbsic_enabled = 0;
-TT
16 Jun
16 Jun
10:45 a.m.
Neat, the test call passed through. Now we got to find a place to send
poweron automatically at the right moment instead of manual activation.
On 06/15/2016 09:38 PM, Tom Tsou wrote:
On Wed, Jun 15, 2016 at 10:08 AM, Max
<msuraev(a)sysmocom.de> wrote:
--
Max Suraev <msuraev(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
I've tried it with manually sending POWERON -
the issue with CHAN RQD is
gone but the phone still does not work. I'll look into OML/RSL/whatever
is preventing it from working.
Make sure that the static variable
'settsc_enabled' is set.
diff --git a/src/osmo-bts-trx/trx_if.c b/src/osmo-bts-trx/trx_if.c
index a4c16dc..8c9a839 100644
--- a/src/osmo-bts-trx/trx_if.c
+++ b/src/osmo-bts-trx/trx_if.c
@@ -47,7 +47,7 @@
//#define TOA_RSSI_DEBUG
int transceiver_available = 0;
-int settsc_enabled = 0;
+int settsc_enabled = 1;
int setbsic_enabled = 0;
-TT
10:52 a.m.
Curiously I've noticed following error messages while testing osmo-bts-trx:
<0010> lapd_core.c:1508 N(S) sequence error: N(S)=0, V(R)=1
<0010> lapd_core.c:1508 N(S) sequence error: N(S)=1, V(R)=2
<0010> lapd_core.c:1508 N(S) sequence error: N(S)=2, V(R)=3
<0010> lapd_core.c:1508 N(S) sequence error: N(S)=3, V(R)=4
<0010> lapd_core.c:1508 N(S) sequence error: N(S)=4, V(R)=5
<0010> lapd_core.c:1508 N(S) sequence error: N(S)=5, V(R)=6
Not sure if it's related.
On 06/15/2016 09:38 PM, Tom Tsou wrote:
On Wed, Jun 15, 2016 at 10:08 AM, Max
<msuraev(a)sysmocom.de> wrote:
--
Max Suraev <msuraev(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
I've tried it with manually sending POWERON -
the issue with CHAN RQD is
gone but the phone still does not work. I'll look into OML/RSL/whatever
is preventing it from working.
Make sure that the static variable
'settsc_enabled' is set.
diff --git a/src/osmo-bts-trx/trx_if.c b/src/osmo-bts-trx/trx_if.c
index a4c16dc..8c9a839 100644
--- a/src/osmo-bts-trx/trx_if.c
+++ b/src/osmo-bts-trx/trx_if.c
@@ -47,7 +47,7 @@
//#define TOA_RSSI_DEBUG
int transceiver_available = 0;
-int settsc_enabled = 0;
+int settsc_enabled = 1;
int setbsic_enabled = 0;
-TT
14 Jun
14 Jun
2:32 p.m.
Hi Harald,
On Sat, Apr 9, 2016 at 1:25 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
On Sat, Apr 09, 2016 at 10:49:41AM +0200, Harald Welte
wrote:
Solution:
* OML initialization (the most complex part of Abis) needs to be
more properly handled. No part of the code should do something like
dynamically sending software activation reports at runtime. In
osm-bts-trx, every time 'transceiver_available' goes from 0->1 (which
apparently can happen even after start), a software activation report
is sent to the BSC. This is wrong. The software is only activated
once during boot, and it is activated not before the parent MOs for
BTS and Site Manager are enabled.
If we or someone else is to fix this - do you have a suggestion on the
best way to do that? E.g. should relevant state checks be added into
oml_* functions, or should the whole OML part rewritten as a proper
state machine. I'm trying to understand how much effort is required to
fix this once and for all.
Unrelated to that, osmo-bts-trx desparately needs to
avoid the use of
global variables. Each gsm_bts_trx / gsm_bts / phy_link / phy_instance
has private data store for implementation-specific state. global
variables have always been discouraged.
Is there something where use of global variable in osmo-bts is a real
issue? I completely agree that using global variables is a punishable
practice, but the question for me is what is the impact of it in this
specific case and is there any immediate benefits from getting this
fixed. That would greatly help us justify the effort to clean it up.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
16 Jun
16 Jun
12:48 p.m.
Hi.
I've pushed fix which works with both master and clkind branches of
osmo-trx into gerrit #296 - please have a look. Note: I've only tested
it with USRP B200. It's far from complete OML implementation but at
least I can get call through.
On 04/09/2016 12:55 AM, Tom Tsou wrote:
Hi Harald,
On Wed, Apr 6, 2016 at 12:59 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
--
Max Suraev <msuraev(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
Can you or somebody else interested in getting
this resolved provide a
full bug report, including
* debug log output on OsmoNITB side for for the rsl and nm
* debug log output on OsmoBTS side for oml / transceiver interface or
anything else related
* pcap file of A-bis traffic between OsmoBTS and OsmoNITB, as well as
the control commands between osmo-bts-trx and osmo-trx
Attached are the logs for
master branches of OpenBSC, OsmoBTS, and
OsmoTRX leading up to the following RACH access behavior.
<0004> abis_rsl.c:1423 BTS 0 CHAN RQD: no resources for SDCCH 0x2
Hopefully, somebody more familiar than myself with A-bis and related
L1/L2 dependencies can provide some insight on why the above is
happening or where to start debugging. I'll be happy to test any
subsequent changes or look into specific parts of the A-bis code.
-TT
21 Jun
21 Jun
6:05 p.m.
Hi.
A little update: the current master works with fr codec but not with
amr. I'm looking into it but in general - is there some version
somewhere which works with amr for somebody on some hw?
--
Max Suraev <msuraev(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
2872
days inactive
2946
days old
18 comments
4 participants
participants (4)
-
Alexander Chemeris -
Harald Welte -
Max -
Tom Tsou