osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master
Hi Harald, On Wed, Apr 6, 2016 at 12:59 AM, Harald Welte <laforge@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
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Harald, Thank you for the thorough log analysis which is greatly helpful. On Sat, Apr 9, 2016 at 3:25 AM, Harald Welte <laforge@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
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@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
-- Max Suraev <msuraev@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 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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Mon, Jun 13, 2016 at 7:04 PM, Harald Welte <laforge@gnumonks.org> wrote:
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.
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
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@gnumonks.org> wrote:
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. 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.
-- Max Suraev <msuraev@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 Tue, Jun 14, 2016 at 11:07 AM, Max <msuraev@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
Hi Max, On Tue, Jun 14, 2016 at 1:07 AM, Max <msuraev@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
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@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
-- Max Suraev <msuraev@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 Tue, Jun 14, 2016 at 10:23 AM, Max <msuraev@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
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@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
-- Max Suraev <msuraev@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 Wed, Jun 15, 2016 at 10:08 AM, Max <msuraev@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
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@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
-- Max Suraev <msuraev@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
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@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
-- Max Suraev <msuraev@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 Harald, On Sat, Apr 9, 2016 at 1:25 PM, Harald Welte <laforge@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
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@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
-- Max Suraev <msuraev@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. 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@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
participants (4)
-
Alexander Chemeris -
Harald Welte -
Max -
Tom Tsou