https://osmocom.org/https://osmocom.org/favicon.ico?16647414092018-07-27T20:57:00ZOpen Source Mobile CommunicationsOsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=105082018-07-27T20:57:00Zfixeria
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>Assignee</strong> set to <i>fixeria</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>10</i></li></ul><p>With a bit more detailed logging it's clean that the counting of lost<br />bursts is implemented in a wrong way:</p>
<pre>
<0012> input/ipa.c:131 127.0.0.1:3003 connection done
<0012> input/ipaccess.c:704 received ID get from 1801/0/0
Too many (2427 >= 10) contiguous elapsed bursts, last fn=0, dropping fn=2427
<0000> common/rsl.c:741 (bts=0,trx=0,ts=1,pchan=SDCCH8) (ss=0) SDCCH Tx CHAN ACT ACK
Too many (2495 >= 10) contiguous elapsed bursts, last fn=0, dropping fn=2495
Too many (16 >= 10) contiguous elapsed bursts, last fn=2498, dropping fn=2514
<0011> lapd_core.c:920 Store content res. (dl=0x7f779e72fd68)
Too many (48 >= 10) contiguous elapsed bursts, last fn=2517, dropping fn=2565
Too many (29 >= 10) contiguous elapsed bursts, last fn=2568, dropping fn=2597
Too many (16 >= 10) contiguous elapsed bursts, last fn=2600, dropping fn=2616
Too many (48 >= 10) contiguous elapsed bursts, last fn=2619, dropping fn=2667
Too many (29 >= 10) contiguous elapsed bursts, last fn=2670, dropping fn=2699
Too many (16 >= 10) contiguous elapsed bursts, last fn=2702, dropping fn=2718
Too many (48 >= 10) contiguous elapsed bursts, last fn=2721, dropping fn=2769
Too many (29 >= 10) contiguous elapsed bursts, last fn=2772, dropping fn=2801
Too many (16 >= 10) contiguous elapsed bursts, last fn=2804, dropping fn=2820
Too many (48 >= 10) contiguous elapsed bursts, last fn=2823, dropping fn=2871
Too many (29 >= 10) contiguous elapsed bursts, last fn=2874, dropping fn=2903
Too many (16 >= 10) contiguous elapsed bursts, last fn=2906, dropping fn=2922
Too many (48 >= 10) contiguous elapsed bursts, last fn=2925, dropping fn=2973
Too many (29 >= 10) contiguous elapsed bursts, last fn=2976, dropping fn=3005
Too many (16 >= 10) contiguous elapsed bursts, last fn=3008, dropping fn=3024
Too many (48 >= 10) contiguous elapsed bursts, last fn=3027, dropping fn=3075
Too many (29 >= 10) contiguous elapsed bursts, last fn=3078, dropping fn=3107
Too many (16 >= 10) contiguous elapsed bursts, last fn=3110, dropping fn=3126
Too many (48 >= 10) contiguous elapsed bursts, last fn=3129, dropping fn=3177
Too many (29 >= 10) contiguous elapsed bursts, last fn=3180, dropping fn=3209
Too many (16 >= 10) contiguous elapsed bursts, last fn=3212, dropping fn=3228
Too many (48 >= 10) contiguous elapsed bursts, last fn=3231, dropping fn=3279
Too many (29 >= 10) contiguous elapsed bursts, last fn=3282, dropping fn=3311
Too many (16 >= 10) contiguous elapsed bursts, last fn=3314, dropping fn=3330
Too many (48 >= 10) contiguous elapsed bursts, last fn=3333, dropping fn=3381
<0000> ../../../src/common/rsl.c:720 (bts=0,trx=0,ts=1,pchan=SDCCH8) (ss=0) SDCCH Tx CHAN REL ACK
</pre> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=105092018-07-28T10:36:08Zfixeria
<ul><li><strong>% Done</strong> changed from <i>10</i> to <i>20</i></li></ul><p>Let's have a look at the following line:</p>
<pre>
Too many (29 >= 10) contiguous elapsed frames, last fn=2568, dropping fn=2597
</pre>
<p>OsmoBTS thinks that 29 frames elapsed since the last_fn=2568.<br />What does it mean? Let's have a look at the multiframe layout:</p>
<pre>
static const struct trx_frame frame_sdcch8[102] = {
/* dl_chan dl_bid ul_chan ul_bid */
{ TRXC_SDCCH8_0, 0, TRXC_SACCH8_5, 0 },
{ TRXC_SDCCH8_0, 1, TRXC_SACCH8_5, 1 },
{ TRXC_SDCCH8_0, 2, TRXC_SACCH8_5, 2 },
{ TRXC_SDCCH8_0, 3, TRXC_SACCH8_5, 3 },
{ TRXC_SDCCH8_1, 0, TRXC_SACCH8_6, 0 },
{ TRXC_SDCCH8_1, 1, TRXC_SACCH8_6, 1 },
{ TRXC_SDCCH8_1, 2, TRXC_SACCH8_6, 2 },
{ TRXC_SDCCH8_1, 3, TRXC_SACCH8_6, 3 },
{ TRXC_SDCCH8_2, 0, TRXC_SACCH8_7, 0 },
{ TRXC_SDCCH8_2, 1, TRXC_SACCH8_7, 1 },
{ TRXC_SDCCH8_2, 2, TRXC_SACCH8_7, 2 },
{ TRXC_SDCCH8_2, 3, TRXC_SACCH8_7, 3 },
{ TRXC_SDCCH8_3, 0, TRXC_IDLE, 0 },
{ TRXC_SDCCH8_3, 1, TRXC_IDLE, 0 },
{ TRXC_SDCCH8_3, 2, TRXC_IDLE, 0 },
/**
* last_fn=2568 % mf_period=102 == 18,
* so here are the previous 4 bursts
* SDCCH/8 (ss=0)
*/
{ TRXC_SDCCH8_3, 3, TRXC_SDCCH8_0, 0 },
{ TRXC_SDCCH8_4, 0, TRXC_SDCCH8_0, 1 },
{ TRXC_SDCCH8_4, 1, TRXC_SDCCH8_0, 2 },
{ TRXC_SDCCH8_4, 2, TRXC_SDCCH8_0, 3 }, // <--- last_fn=2568 (18)
/* SDCCH/8 (ss=1), another subscriber */
{ TRXC_SDCCH8_4, 3, TRXC_SDCCH8_1, 0 },
{ TRXC_SDCCH8_5, 0, TRXC_SDCCH8_1, 1 },
{ TRXC_SDCCH8_5, 1, TRXC_SDCCH8_1, 2 },
{ TRXC_SDCCH8_5, 2, TRXC_SDCCH8_1, 3 },
/* SDCCH/8 (ss=2), another subscriber */
{ TRXC_SDCCH8_5, 3, TRXC_SDCCH8_2, 0 },
{ TRXC_SDCCH8_6, 0, TRXC_SDCCH8_2, 1 },
{ TRXC_SDCCH8_6, 1, TRXC_SDCCH8_2, 2 },
{ TRXC_SDCCH8_6, 2, TRXC_SDCCH8_2, 3 },
/* SDCCH/8 (ss=3), another subscriber */
{ TRXC_SDCCH8_6, 3, TRXC_SDCCH8_3, 0 },
{ TRXC_SDCCH8_7, 0, TRXC_SDCCH8_3, 1 },
{ TRXC_SDCCH8_7, 1, TRXC_SDCCH8_3, 2 },
{ TRXC_SDCCH8_7, 2, TRXC_SDCCH8_3, 3 },
/* SDCCH/8 (ss=4), another subscriber */
{ TRXC_SDCCH8_7, 3, TRXC_SDCCH8_4, 0 },
{ TRXC_SACCH8_0, 0, TRXC_SDCCH8_4, 1 },
{ TRXC_SACCH8_0, 1, TRXC_SDCCH8_4, 2 },
{ TRXC_SACCH8_0, 2, TRXC_SDCCH8_4, 3 },
/* SDCCH/8 (ss=5), another subscriber */
{ TRXC_SACCH8_0, 3, TRXC_SDCCH8_5, 0 },
{ TRXC_SACCH8_1, 0, TRXC_SDCCH8_5, 1 },
{ TRXC_SACCH8_1, 1, TRXC_SDCCH8_5, 2 },
{ TRXC_SACCH8_1, 2, TRXC_SDCCH8_5, 3 },
/* SDCCH/8 (ss=6), another subscriber */
{ TRXC_SACCH8_1, 3, TRXC_SDCCH8_6, 0 },
{ TRXC_SACCH8_2, 0, TRXC_SDCCH8_6, 1 },
{ TRXC_SACCH8_2, 1, TRXC_SDCCH8_6, 2 },
{ TRXC_SACCH8_2, 2, TRXC_SDCCH8_6, 3 },
/* SDCCH/8 (ss=7), another subscriber */
{ TRXC_SACCH8_2, 3, TRXC_SDCCH8_7, 0 },
{ TRXC_SACCH8_3, 0, TRXC_SDCCH8_7, 1 },
{ TRXC_SACCH8_3, 1, TRXC_SDCCH8_7, 2 },
{ TRXC_SACCH8_3, 2, TRXC_SDCCH8_7, 3 },
/**
* current_fn=2597 % mf_period=102 == 47
*
* so here are the current 4 bursts
* SACCH/8 (ss=0), here MS sends Measurement Reports
*
* current_fn=2597 - last_fn=2568 == elapsed_fn=29
*/
{ TRXC_SACCH8_3, 3, TRXC_SACCH8_0, 0 }, // <--- current_fn=2597 (47)
{ TRXC_IDLE, 0, TRXC_SACCH8_0, 1 },
{ TRXC_IDLE, 0, TRXC_SACCH8_0, 2 },
{ TRXC_IDLE, 0, TRXC_SACCH8_0, 3 },
{ TRXC_SDCCH8_0, 0, TRXC_SACCH8_1, 0 },
{ TRXC_SDCCH8_0, 1, TRXC_SACCH8_1, 1 },
{ TRXC_SDCCH8_0, 2, TRXC_SACCH8_1, 2 },
{ TRXC_SDCCH8_0, 3, TRXC_SACCH8_1, 3 },
{ TRXC_SDCCH8_1, 0, TRXC_SACCH8_2, 0 },
{ TRXC_SDCCH8_1, 1, TRXC_SACCH8_2, 1 },
{ TRXC_SDCCH8_1, 2, TRXC_SACCH8_2, 2 },
{ TRXC_SDCCH8_1, 3, TRXC_SACCH8_2, 3 },
{ TRXC_SDCCH8_2, 0, TRXC_SACCH8_3, 0 },
{ TRXC_SDCCH8_2, 1, TRXC_SACCH8_3, 1 },
{ TRXC_SDCCH8_2, 2, TRXC_SACCH8_3, 2 },
{ TRXC_SDCCH8_2, 3, TRXC_SACCH8_3, 3 },
/* ... */
};
</pre>
<p>Actually "29 elapsed frames" is an expected behaviour, because<br />they belong to other subscribers (ss != 0)! If all sub-slots are<br />allocated and actively used by subscribers, this warning wouldn't<br />appear, because the 'l1ts->mf_last_fn' variable would be updated<br />on each received frame. Excluding IDLE frames, which anyway would<br />cause this warning...</p>
<p>So, I think this is not a good idea to track lost bursts/frames<br />using this 'l1ts->mf_last_fn', which is global for all logical<br />channels on the current time-slot.</p>
<p>I suggest to change the logic, and track lost bursts/frames<br />individually for each allocated logical channel.</p>
<p>Do you guys agree?</p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=105602018-08-01T22:37:35Zfixeria
<ul><li><strong>% Done</strong> changed from <i>20</i> to <i>40</i></li></ul><p>Just introduced some helpful commands for path loss simulation in <a class="wiki-page" href="https://osmocom.org/projects/baseband/wiki/FakeTRX">FakeTRX</a>.<br />In particular, now it's possible to ask <a class="wiki-page" href="https://osmocom.org/projects/baseband/wiki/FakeTRX">FakeTRX</a> to drop some amount of UL/DL bursts at runtime.</p>
<p>Please see: <a class="external" href="https://gerrit.osmocom.org/10305/">https://gerrit.osmocom.org/10305/</a></p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=105612018-08-01T22:41:04Zfixeria
<ul></ul><p>Also, I have some draft implementation (still cleaning up..) of per logical channel<br />TDMA frame loss tracking for OsmoBTS. I am going to write some TTCN-3 test cases<br />and upload everything to Gerrit...</p>
<p>P.S. I am finally going to drop this hackish while (42) { ... } ;)</p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=105672018-08-02T11:35:18Zfixeria
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li><li><strong>Target version</strong> set to <i>osmo-bts-trx refresh</i></li><li><strong>% Done</strong> changed from <i>40</i> to <i>80</i></li></ul><p>Please see: <a class="external" href="https://gerrit.osmocom.org/10309/">https://gerrit.osmocom.org/10309/</a></p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=105902018-08-04T03:49:56Zfixeria
<ul></ul><p>It was noticed that TDMA frame loss detection becomes crazy on PDTCH logical channels.<br />Most likely, because they are always active (when OsmoPCU is connected), and since I've<br />increased the detection period, multiple false-positive detections (noise) from OsmoTRX<br />do trigger the logic more often than on other channels.</p>
<p>A possible solution is not to track the frame loss on PDTCH channels...<br />Any ideas?</p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=105912018-08-05T09:30:07Zlaforge
<ul></ul><p>On Sat, Aug 04, 2018 at 03:49:57AM +0000, fixeria [REDMINE] wrote:</p>
<blockquote>
<p>It was noticed that TDMA frame loss detection becomes crazy on PDTCH logical channels.<br />Most likely, because they are always active (when OsmoPCU is connected), and since I've<br />increased the detection period, multiple false-positive detections (noise) from OsmoTRX<br />do trigger the logic more often than on other channels.</p>
<p>A possible solution is not to track the frame loss on PDTCH channels...<br />Any ideas?</p>
</blockquote>
<p>I think there's two good solutions:</p>
<p>a) make sure we send information for every block on every active timeslot, whether osmo-trx<br />has received something, or not. I think optimizing this by dropping blocks in case nothing<br />was received is a false optimization anyway. The CPU of the BTS must be able to handle all<br />logical channels active at the same time anyway. And not sending the blocks creates an<br />ambiguity: Were the blocks lost on the UDP/IP/socket_buffer level, or were they simply<br />below the detection threshold in osmo-trx? The first would be an important problem to resolve,<br />the second is normal operation.</p>
<p>b) remove the 'lost block' detection in osmo-bts-trx. But then, we don't know if that was due<br />to loss on the RF path, or whether itw as due to local UDP/IP/socket issues between osmo-trx<br />and omso-bts-trx</p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=105932018-08-05T17:12:58Zfixeria
<ul></ul><p>Hi Harald,</p>
<blockquote>
<p>I think there's two good solutions:</p>
</blockquote>
<p>to be honest, I am not sure both are 100% good solutions. Let's discuss?</p>
<blockquote>
<p>a) make sure we send information for every block on every active<br />timeslot, whether osmo-trx has received something, or not</p>
</blockquote>
<p>We can go this way, but I think it would complicate the logic of OsmoTRX.<br />At least, we need to make OsmoTRX distinguish between logical channels,<br />as sending such indications on RACH and PD{T|C}CH doesn't make sense.<br />I am not familiar with DTX, but this may also be affected...</p>
<blockquote>
<p>The CPU of the BTS must be able to handle all logical channels active<br />at the same time anyway. And not sending the blocks creates an ambiguity:<br />were the blocks lost on the UDP/IP/socket_buffer level, or were they simply<br />below the detection threshold in osmo-trx?</p>
</blockquote>
<p>I think sending such "dummy" bursts would only increase the<br />chances that some meaningful bursts will be lost, especially<br />on embedded systems. Furthermore, in case of PD{T|C}CH channels,<br />which are always active, so every 4th burst will trigger<br />a decoding attempt...</p>
<p>If a burst or even a few bursts are lost, they are lost. No matter,<br />due to CPU load, UDP/IP packet loss, or RSSI/ToA treshold,<br />we are unable to recover them anyway...</p>
<p>And finally, this approach assumes the compatibility problems.</p>
<blockquote>
<p>b) remove the 'lost block' detection in osmo-bts-trx.<br />But then, we don't know if that was due to loss on the RF path,<br />or whether itw as due to local UDP/IP/socket issues<br />between osmo-trx and omso-bts-trx</p>
</blockquote>
<p>Yep, and additionally if one or even a few blocs (e.g. 4 bursts<br />for xCCH) are lost, we wouldn't even reflect this in the Uplink<br />measurements...</p>
<p>At the moment, I would prefer not to modify the logic of OsmoTRX,<br />and keep the burst loss detection in OsmoBTS. Also, instead<br />of sending zero-filled bursts to compensate a gap in OsmoBTS,<br />I would modify the measurements logic to account the amount<br />of received vs lost bursts (I was WIP on this)...</p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=105942018-08-05T18:00:09Zlaforge
<ul></ul><p>On Sun, Aug 05, 2018 at 05:12:58PM +0000, fixeria [REDMINE] wrote:</p>
<blockquote><blockquote>
<p>The CPU of the BTS must be able to handle all logical channels active<br />at the same time anyway. And not sending the blocks creates an ambiguity:<br />were the blocks lost on the UDP/IP/socket_buffer level, or were they simply<br />below the detection threshold in osmo-trx?</p>
</blockquote>
<p>I think sending such "dummy" bursts would only increase the<br />chances that some meaningful bursts will be lost, especially<br />on embedded systems.</p>
</blockquote>
<p>As indicated before, if your BTS CPU is not able to decode all blocks/bursts,<br />you are running a broken setup anyway. If we sent all bursts from osmo-trx<br />to osmo-bts-trx, then it would be visible immediataly at start-up. By not<br />sending all bursts to osmo-bts, you are only hiding/delaying the visibility<br />of having insufficient CPU until you're actually under load.</p>
<p>In fact, at the moment it's rather hard (without a "GSM air interface load generator")<br />to establish whether your BTS CPU is sufficient for a fully loaded BTS or not.</p>
<p>The only argument in favor of skipping/supressing bursts is to save<br />power (and heat dissipation), which may really be a valid point in case<br />of solar powerd systems, where you can use any excess energy to charge<br />batteries for night time operation.</p>
<blockquote>
<p>Furthermore, in case of PD{T|C}CH channels,<br />which are always active, so every 4th burst will trigger<br />a decoding attempt...</p>
</blockquote>
<p>You could still skip the attempt to decode (viterbi) in osmo-bts-trx, if the<br />receive level is below a certain thershold. What does osmo-trx<br />currently use to determine whether or not to send a burst?</p>
<blockquote>
<p>If a burst or even a few bursts are lost, they are lost. No matter,<br />due to CPU load, UDP/IP packet loss, or RSSI/ToA treshold,<br />we are unable to recover them anyway...</p>
</blockquote>
<p>yes. But, as indicated, one type of loss is normal, the other<br />(TCP/IP/socket) is a clear indication of a problem with your<br />hardware/software setup, which should never ever happen during<br />production.</p>
<blockquote>
<p>And finally, this approach assumes the compatibility problems.</p>
</blockquote>
<p>ACK.</p>
<blockquote><blockquote>
<p>b) remove the 'lost block' detection in osmo-bts-trx.<br />But then, we don't know if that was due to loss on the RF path,<br />or whether itw as due to local UDP/IP/socket issues<br />between osmo-trx and omso-bts-trx</p>
</blockquote>
<p>Yep, and additionally if one or even a few blocs (e.g. 4 bursts<br />for xCCH) are lost, we wouldn't even reflect this in the Uplink<br />measurements...</p>
</blockquote>
<p>this is definitely an even worse bug. Uplink measurements must be<br />correctly computed, whether or not burst data was receivd on all<br />frames of a given logical chanenl, or not.</p>
<blockquote>
<p>At the moment, I would prefer not to modify the logic of OsmoTRX,<br />and keep the burst loss detection in OsmoBTS. Also, instead<br />of sending zero-filled bursts to compensate a gap in OsmoBTS,<br />I would modify the measurements logic to account the amount<br />of received vs lost bursts (I was WIP on this)...</p>
</blockquote>
<p>Fine with me. All non-trx osmo-bts backends receive some kind of<br />message from the PHY every frame number, which is actually rather nice<br />in order to drive all the various logic bits...</p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=106002018-08-06T12:45:10Zfixeria
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Stalled</i></li><li><strong>% Done</strong> changed from <i>80</i> to <i>40</i></li></ul><p>I think we can merge the current change, as it helps to avoid the original problem of this issue.</p>
<p>As was noted at #osmocom:</p>
<blockquote>
<p>There is a problem of the current TDMA frame loss tracking approach: we calculate the amount<br />of lost/processed bursts only when something is received on Uplink, so the algorithm is being<br />driven by 'unstable source'. As a result, Uplink measurements may not reflect the actual values...</p>
</blockquote>
<p>So, it really makes sense to send some kind of indications from TRX that nothing was detected.</p>
<p>At the moment, I have no enough time, so setting to 'Stalled', but will resume ASAP.</p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=106012018-08-06T12:50:19Zfixeria
<ul></ul><blockquote>
<p>What does osmo-trx currently use to determine whether or not to send a burst?</p>
</blockquote>
<p>There are several threads, which share a queue of detected bursts in OsmoTRX.<br />I had a quick look at the source code, and I think it should be easy to<br />implement the indications we are talking about, please see:</p>
<p><a class="external" href="https://git.osmocom.org/osmo-trx/tree/Transceiver52M/Transceiver.cpp#n922">https://git.osmocom.org/osmo-trx/tree/Transceiver52M/Transceiver.cpp#n922</a></p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=106072018-08-06T13:20:06Zlaforge
<ul></ul><p>On Mon, Aug 06, 2018 at 12:50:19PM +0000, fixeria [REDMINE] wrote:</p>
<blockquote>
<p>There are several threads, which share a queue of detected bursts in OsmoTRX.<br />I had a quick look at the source code, and I think it should be easy to<br />implement the indications we are talking about, please see:</p>
<p><a class="external" href="https://git.osmocom.org/osmo-trx/tree/Transceiver52M/Transceiver.cpp#n922">https://git.osmocom.org/osmo-trx/tree/Transceiver52M/Transceiver.cpp#n922</a></p>
</blockquote>
<p>FYI, AFAICT there are the following cases where pullRadioBurst returns NULL:</p>
<ul>
<li>nothing can be pulled out of the FIFO (really bad)</li>
<li>timeslot is off (cannot legally happen if there's an active lchan, as<br />it is switched on/off by osmo-bts-trx)</li>
<li>energy low (energyDetect() <= -1.0)</li>
<li>type == IDLE</li>
<li>unable to detect NORMAL or RACH burst (including clipping)</li>
</ul> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=115442018-09-21T10:32:03Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-3 priority-high3 closed" href="/issues/2700">Bug #2700</a>: Odd RTP behavior in case of bad / missing speech frames</i> added</li></ul> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=115762018-09-24T16:48:13Zfixeria
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-1 priority-lowest closed" href="/issues/3370">Bug #3370</a>: osmo-bts "substituting all-zero burst" and osmo-pcu "Link quality (0dB) left window [5, 8], modifying uplink CS levels: CS-2 -> CS-1"</i> added</li></ul> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=123642018-10-24T16:03:03Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-2 priority-default closed" href="/issues/3665">Bug #3665</a>: TTCN3 BTS_Tests last SACCH burst received too late -> wrong fake uplink measurement report</i> added</li></ul> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=123822018-10-25T09:41:15Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/2975">Bug #2975</a>: OsmoBTS doesn't generate measurement indications in absence of uplink bursts</i> added</li></ul> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=123842018-10-25T09:41:22Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-7 priority-2 priority-default" href="/issues/2977">Feature #2977</a>: OsmoBTS measurment processing at L1SAP too complex / pass measurements along with data</i> added</li></ul> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=146952019-06-03T10:46:38Zfixeria
<ul><li><strong>Blocked by</strong> <i><a class="issue tracker-2 status-7 priority-2 priority-default" href="/issues/4006">Feature #4006</a>: TRX protocol: wind of change</i> added</li></ul> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=151752019-07-16T20:02:22Zfixeria
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>40</i> to <i>60</i></li></ul><p>Thanks to the new version of the TRXD protocol, we can send such NOPE / IDLE indications from OsmoTRX:</p>
<p><a class="external" href="https://gerrit.osmocom.org/r/I46404f6e4055b6d3af3afffb0dfe4a19502917aa">https://gerrit.osmocom.org/r/I46404f6e4055b6d3af3afffb0dfe4a19502917aa</a></p>
<p>we just need to implement a proper handling of them in OsmoBTS.</p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=161472019-10-03T17:27:35Zfixeria
<ul><li><strong>Tracker</strong> changed from <i>Bug</i> to <i>Feature</i></li><li><strong>Subject</strong> changed from <i>Too many contiguous elapsed fn, dropping...</i> to <i>Implement handling of NOPE / IDLE indications from Transceiver</i></li><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=164182019-11-11T19:20:41Zfixeria
<ul><li><strong>Related to</strong> deleted (<i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/2975">Bug #2975</a>: OsmoBTS doesn't generate measurement indications in absence of uplink bursts</i>)</li></ul> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=164192019-11-11T19:20:44Zfixeria
<ul><li><strong>Blocks</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/2975">Bug #2975</a>: OsmoBTS doesn't generate measurement indications in absence of uplink bursts</i> added</li></ul> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=169942020-01-06T01:26:16Zfixeria
<ul><li><strong>% Done</strong> changed from <i>60</i> to <i>90</i></li></ul><p>At the moment of writing this status update, OsmoTRX is capable to send IDLE / NOPE indications to the BTS. OsmoBTS in its turn started to use these indications to ensure continuous Uplink measurement reporting (see [1]).</p>
<p>[1] <a class="external" href="https://gerrit.osmocom.org/r/Idfa8ef94e8cf131ff234dac8f93f337051663ae2">https://gerrit.osmocom.org/r/Idfa8ef94e8cf131ff234dac8f93f337051663ae2</a></p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=174692020-02-17T09:27:04Zfixeria
<ul><li><strong>Blocked by</strong> deleted (<i><a class="issue tracker-2 status-7 priority-2 priority-default" href="/issues/4006">Feature #4006</a>: TRX protocol: wind of change</i>)</li></ul> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=174702020-02-17T09:28:32Zfixeria
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>Resolved</i></li></ul> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=177922020-03-19T21:55:13Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-3 priority-high3 closed" href="/issues/4461">Bug #4461</a>: RTP clock out of sync with lower layer</i> added</li></ul> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=177942020-03-19T22:00:57Zfixeria
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>New</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>80</i></li></ul><p>We actually need to handle NOPE indications for other logical channels too, not only SACCH.</p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=177952020-03-19T22:02:18Zfixeria
<ul><li><strong>Assignee</strong> deleted (<del><i>fixeria</i></del>)</li></ul><p>Unfortunately, I have no time to work on this.</p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=177972020-03-20T08:41:01Zlaforge
<ul><li><strong>Assignee</strong> set to <i>dexter</i></li></ul><p>I would guess this is rather straight forward. The simplest approach would AFAICT simply to call rx_tch{h,f}_fn() as nope_fn for all channels...?</p> OsmoBTS - Feature #3428: Implement handling of NOPE / IDLE indications from Transceiverhttps://osmocom.org/issues/3428?journal_id=179472020-04-05T17:49:31Zfixeria
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>80</i> to <i>100</i></li></ul><p>Please see <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/17539">https://gerrit.osmocom.org/c/osmo-bts/+/17539</a> by <a class="user active" href="https://osmocom.org/users/15">dexter</a>. After some minor changes it has been merged.</p>