Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092021-10-27T22:35:37ZOpen Source Mobile Communications
Redmine OsmoTRX - Feature #5283 (New): Implement TRXDv2 supporthttps://projects.osmocom.org/issues/52832021-10-27T22:35:37Zfixeria
<p>At the moment, only TRXDv0 and TRXDv1 are supported. Given that osmo-bts-trx does support TRXDv2, it would be nice to have it in osmo-trx too.</p> OsmoBTS - Feature #5025 (New): Missing TTCN-3 coverage for the Timing Advance loophttps://projects.osmocom.org/issues/50252021-02-15T16:36:08Zfixeria
<p>As we figured out in <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: Timing Advance loop is broken for SDCCH channels (Resolved)" href="https://projects.osmocom.org/issues/5024">#5024</a>, there seems to be no TTCN-3 test case(s) for continuous Timing Advance control:</p>
<p>Harald Welte wrote:</p>
<blockquote>
<p>Regarding TTCN3 tests: We also only test the correct TA usage on initial channel establishment (BTS_Tests.TC_rsl_chan_initial_ta) and no tests yet for the TA loop during an active channel.</p>
</blockquote> libosmocore - Bug #4993 (New): gsm_septets2octets: warning: use of NULL ‘rdata’ where non-null ex...https://projects.osmocom.org/issues/49932021-01-29T20:49:14Zlaforge
<p>When using gcc-10 with "-fanalyzer", we get the following report:</p>
<pre>
gsm_utils.c: In function ‘gsm_septets2octets’:
gsm_utils.c:340:3: warning: use of NULL ‘rdata’ where non-null expected [CWE-690] [-Wanalyzer-null-argument]
340 | memcpy(data, rdata, septet_len);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
‘gsm_7bit_encode_n’: events 1-3
|
| 378 | int gsm_7bit_encode_n(uint8_t *result, size_t n, const char *data, int *octets)
| | ^~~~~~~~~~~~~~~~~
| | |
| | (1) entry to ‘gsm_7bit_encode_n’
|......
| 385 | uint8_t *rdata = calloc(strlen(data) * 2, sizeof(uint8_t));
| | ~~~~~~~~~~~~
| | |
| | (2) allocated here
| 386 | y = gsm_septet_encode(rdata, data);
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (3) calling ‘gsm_septet_encode’ from ‘gsm_7bit_encode_n’
|
+--> ‘gsm_septet_encode’: events 4-8
|
| 292 | int gsm_septet_encode(uint8_t *result, const char *data)
| | ^~~~~~~~~~~~~~~~~
| | |
| | (4) entry to ‘gsm_septet_encode’
|......
| 296 | for (i = 0; i < strlen(data); i++) {
| | ~~~ ~~~~~~~~~~~~
| | | |
| | | (5) following ‘false’ branch (when ‘data’ is non-NULL)...
| | | (6) ...to here
| | (7) following ‘false’ branch...
|......
| 318 | return y;
| | ~
| | |
| | (8) ...to here
|
<------+
|
‘gsm_7bit_encode_n’: events 9-10
|
| 386 | y = gsm_septet_encode(rdata, data);
| | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (9) returning to ‘gsm_7bit_encode_n’ from ‘gsm_septet_encode’
|......
| 396 | o = gsm_septets2octets(result, rdata, y, 0);
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (10) calling ‘gsm_septets2octets’ from ‘gsm_7bit_encode_n’
|
+--> ‘gsm_septets2octets’: events 11-19
|
| 327 | int gsm_septets2octets(uint8_t *result, const uint8_t *rdata, uint8_t septet_len, uint8_t padding)
| | ^~~~~~~~~~~~~~~~~~
| | |
| | (11) entry to ‘gsm_septets2octets’
|......
| 334 | if (padding) {
| | ~
| | |
| | (12) following ‘false’ branch (when ‘padding == 0’)...
|......
| 340 | memcpy(data, rdata, septet_len);
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (13) ...to here
| | (14) following ‘false’ branch (when ‘data’ is non-NULL)...
| | (15) ...to here
| | (16) assuming ‘rdata’ is NULL
| | (17) following ‘true’ branch (when ‘rdata’ is NULL)...
| | (18) ...to here
| | (19) argument 2 (‘rdata’) NULL where non-null expected
|
In file included from ../../include/osmocom/core/utils.h:6,
from gsm_utils.c:82:
/usr/include/string.h:43:14: note: argument 2 of ‘memcpy’ must be non-null
</pre>
<p>There's also a couple of others in that file:<br /><pre>
gsm_utils.c:340:3: warning: use of NULL ‘data’ where non-null expected [CWE-690] [-Wanalyzer-null-argument]
gsm_utils.c: In function ‘gsm_7bit_encode_n’:
gsm_utils.c:401:2: warning: double-‘free’ of ‘rdata’ [CWE-415] [-Wanalyzer-double-free]
gsm_utils.c:369:9: warning: leak of ‘rdata’ [CWE-401] [-Wanalyzer-malloc-leak]
</pre></p> OsmocomBB - Bug #4798 (Feedback): fake_trx send TRXC responses from wrong source addresshttps://projects.osmocom.org/issues/47982020-10-11T15:59:10Zlaforge
<p>I'm starting fake_trx.py like this:<br /><pre>
./fake_trx.py -R 127.0.0.21 -r 127.0.0.21 --trx TRX1@127.0.0.21:5700/1 --trx TRX2@127.0.0.21:5700/2 --trx TRX3@127.0.0.21:5700/3
</pre></p>
<p>And then osmo-bts-trx is sending TRXC commands from 127.0.0.20 to 127.0.0.21, and fake_trx.py responds. However, the response originates from 127.0.0.1 instead of the 127.0.0.21 that was configured.</p>
<p>Subsequently, osmo-bts-trx rejects those UDP responses as (presumably) the socket is fully connected and hence only accepts packets with correct source ip+port.</p>
<p><img src="https://projects.osmocom.org/attachments/download/4309/fake_trx_wrong_source.png" alt="" /></p>
<p>pcap file attached.</p> libosmocore - Bug #4797 (Feedback): vty: the output of 'show ns' command is confusinghttps://projects.osmocom.org/issues/47972020-10-09T23:38:34Zfixeria
<p>This looks cryptic, at least to me:</p>
<pre>
OsmoPCU# show ns
UDP bind: 0.0.0.0:22000 dcsp: 0
1 NS-VC:
udp)[0.0.0.0]:22000<1234>[127.0.0.1]:23000
NSEI 1234
:0 <> 127.0.0.1:23000Remote: udp)[0.0.0.0]:22000<1234>[127.0.0.1]:23000 UDP
</pre>
<p>Let's print something more readable.</p> libosmocore - Bug #4731 (Stalled): LAPDm does not implement SAPI priorities between data link layershttps://projects.osmocom.org/issues/47312020-08-26T19:34:40Zlaforge
<p>AFAIR, The 3GPP specifications contain some very strict rules regarding priorities among different concurrent LAPDm data links for the same subscriber. For example, SAIP0 always has higher priority than SAPI3.</p>
<p>We've just encountered a situation where in MT-SMS, the SAPI3 SABM from BTS to MS was sent <strong>before</strong> the BTS replied with the UA for SAPI0 (contetion resolution procedure, where we echo the PAGING RESPONSE back to the MS).</p>
<p>A quick look at the LAPDm code in libosmocore reveals that it is doing a round-robin rather than implementing the rules.</p>
<p>TS 44.005 Section 4.2.2 states the priorities for SDCCH and SACCH. I guess we can think of FACCH == SDCCH in this context.</p> OsmocomBB - Bug #4658 (Stalled): Wrong burst order in a multi-trx setuphttps://projects.osmocom.org/issues/46582020-07-08T11:45:30Zfixeria
<p>While running the existing test cases from ttcn3-bts-test on hopping channels (see <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: baseband frequency hopping support for osmo-bts-trx (Resolved)" href="https://projects.osmocom.org/issues/4546">#4546</a>), I noticed that sometimes trxcon starts to consume a lot of CPU power. As it turned out, this happens because the burst loss detection logic in trxcon somehow detects that the whole TDMA hyper-frame is lost, so it tries to substitute ~2715647 allegedly lost TDMA frames with a dummy burst. Of course it's a bug, because we're not supposed to compensate more than one TDMA multi-frame period. So the problem was a missing 'return' statement:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/19183">https://gerrit.osmocom.org/c/osmocom-bb/+/19183</a> trxcon/scheduler: subst_frame_loss(): print current TDMA fn<br /><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/19184">https://gerrit.osmocom.org/c/osmocom-bb/+/19184</a> trxcon/scheduler: fix subst_frame_loss(): do not compensate too much</p>
<p>However, I was interested to know what exactly tricks the burst detection logic to think that so many frames are lost.</p>
<pre><code class="c syntaxhl"><span class="cm">/*! Return the difference of two specified TDMA frame numbers (subtraction) */</span>
<span class="cp">#define GSM_TDMA_FN_SUB(a, b) \
((a + GSM_TDMA_HYPERFRAME - b) % GSM_TDMA_HYPERFRAME)
</span>
<span class="cm">/* How many frames elapsed since the last one? */</span>
<span class="n">elapsed</span> <span class="o">=</span> <span class="n">GSM_TDMA_FN_SUB</span><span class="p">(</span><span class="n">fn</span><span class="p">,</span> <span class="n">lchan</span><span class="o">-></span><span class="n">tdma</span><span class="p">.</span><span class="n">last_proc</span><span class="p">);</span>
<span class="k">if</span> <span class="p">(</span><span class="n">elapsed</span> <span class="o">></span> <span class="n">mf</span><span class="o">-></span><span class="n">period</span><span class="p">)</span> <span class="p">{</span>
<span class="n">LOGP</span><span class="p">(</span><span class="n">DSCHD</span><span class="p">,</span> <span class="n">LOGL_NOTICE</span><span class="p">,</span> <span class="s">"Too many (>%u) contiguous TDMA frames elapsed (%u) "</span>
<span class="s">"since the last processed fn=%u (current %u)</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span>
<span class="n">mf</span><span class="o">-></span><span class="n">period</span><span class="p">,</span> <span class="n">elapsed</span><span class="p">,</span> <span class="n">lchan</span><span class="o">-></span><span class="n">tdma</span><span class="p">.</span><span class="n">last_proc</span><span class="p">,</span> <span class="n">fn</span><span class="p">);</span>
<span class="k">return</span> <span class="o">-</span><span class="n">EIO</span><span class="p">;</span>
<span class="p">}</span> <span class="k">else</span> <span class="nf">if</span> <span class="p">(</span><span class="n">elapsed</span> <span class="o">==</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
<span class="n">LOGP</span><span class="p">(</span><span class="n">DSCHD</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="s">"No TDMA frames elapsed since the last processed "</span>
<span class="s">"fn=%u, must be a bug?</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">lchan</span><span class="o">-></span><span class="n">tdma</span><span class="p">.</span><span class="n">last_proc</span><span class="p">);</span>
<span class="k">return</span> <span class="o">-</span><span class="n">EIO</span><span class="p">;</span>
<span class="p">}</span>
</code></pre>
<p>And slightly more informative logging message gives us a hint:</p>
<pre>
sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647) since the last processed fn=633 (current fn=632)
</pre>
<p>so, a burst with TDMA fn=632 is for some reason received <strong>late</strong>, since we already received a burst with TDMA fn=633.</p>
<p>This is definitely unexpected, and of course subtraction would result in a huge number: ((632 + 2715648) - 633) % 2715648 == 2715647.</p> OsmoBTS - Bug #4592 (Stalled): osmo-bts-trx: make sure that handover detection workshttps://projects.osmocom.org/issues/45922020-06-07T08:18:06Zfixeria
<p>While investigating <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: osmo-bts-trx leaks memory (Resolved)" href="https://projects.osmocom.org/issues/4586">#4586</a>, I noticed that <strong>osmo-bts-trx never sends <em>TRXC HANDOVER</em> command</strong>. It looks like <em>TRXC NOHANDOVER</em> is being sent twice.</p>
<pre>
1401 3.835299624 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
1404 3.835525858 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
1673 3.947655470 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
1674 3.947925293 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
2028 4.071425165 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
2031 4.071810374 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
2334 4.186607520 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
2337 4.187177856 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
2648 4.295164236 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
2649 4.295823750 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
10759 7.367793910 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
10762 7.368688082 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
11205 7.532400900 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
11206 7.532637365 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
</pre>
<p>The purpose of these TRXC commands is to control handover detection in transceiver. By default, handover detection is enabled on all inactive channels. As soon as the BSC activates a logical channel, osmo-bts-trx needs to send <em>TRXC NOHANDOVER</em> to the transceiver, so handover detection is disabled for that channel. As soon as a logical channel is deactivated, osmo-bts-trx needs to send <em>TRXC HANDOVER</em> to the transceiver, so handover detection is on again.</p>
<p>I quickly checked the source code, and indeed there is a bug:</p>
<pre><code class="c syntaxhl"><span class="cm">/* setting all logical channels given attributes to active/inactive */</span>
<span class="kt">int</span> <span class="nf">trx_sched_set_lchan</span><span class="p">(</span><span class="k">struct</span> <span class="n">l1sched_trx</span> <span class="o">*</span><span class="n">l1t</span><span class="p">,</span> <span class="kt">uint8_t</span> <span class="n">chan_nr</span><span class="p">,</span> <span class="kt">uint8_t</span> <span class="n">link_id</span><span class="p">,</span> <span class="n">bool</span> <span class="n">active</span><span class="p">)</span>
<span class="p">{</span>
<span class="cm">/* Skipped code here... */</span>
<span class="cm">/* disable handover detection (on deactivation) */</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">active</span><span class="p">)</span>
<span class="n">_sched_act_rach_det</span><span class="p">(</span><span class="n">l1t</span><span class="p">,</span> <span class="n">tn</span><span class="p">,</span> <span class="n">ss</span><span class="p">,</span> <span class="mi">0</span><span class="p">);</span>
<span class="k">return</span> <span class="n">rc</span><span class="p">;</span>
<span class="p">}</span>
</code></pre>
<p>Even the comment near the 'if' statement is wrong.</p> OsmoHLR - Bug #4565 (New): TTCN-3 testsuite: mDNS_UDP: maximum number of open file descriptors is...https://projects.osmocom.org/issues/45652020-05-26T07:12:54Zosmith
<p>I'm analyzing why the TTCN-3 tests for DGSM are failing now, although they have been working before the dgsm code was merged into OsmoHLR. I think we've upgraded the ttcn-3 version inbetween, maybe that is why it worked before and does not work anymore now.</p>
<p>The tests run into a timeout at mDNS.receive calls, such as:<br /><pre>
/* [mDNS] TS-HLR <= HLR proxy: query for GSUP server who knows the IMSI */
mDNS.receive(tr_MSLookup_mDNS_query(domain)) -> value mdns_msg;
</pre></p>
<p>While executing the tests (and even while running non-dgsm tests), the testsuite prints a new message (this was not printed when I wrote and tested the tests initially):<br /><pre>
07:14:22.466652 5 MSLookup_mDNS_Emulation.ttcn:23 Warning: The maximum number of open file descriptors (1048576) is greater than FD_SETSIZE (1024). Ensure that Test Ports using Install_Handler do not try to wait for events of file descriptors with values greater than FD_SETSIZE (1024). (Current caller of Install_Handler is "mDNS_UDP")
</pre></p>
<p>So for some reason, a huge number of file descriptors is allocated. This happens even if just one test is enabled.</p> OsmoBTS - Bug #4500 (Stalled): osmo-bts-{sysmo,oc2g,litecell15}: PTCCH/U is not enabled on PDCH t...https://projects.osmocom.org/issues/45002020-04-17T20:05:03Zfixeria
<p>Enabling <em>GsmL1_Sapi_Ptcch</em> on direction <em>GsmL1_Dir_RxUplink</em> fails for the black-box DSP based models:</p>
<pre>
<0006> oml.c:511 activating (bts=0,trx=0,ts=7,ss=0) pchan=PDCH ts_connect_as(PDCH) logChComb=pdtch
<0006> oml.c:808 Successful activation of L1 SAPI PDTCH on TS 7 <-- Downlink
<0006> oml.c:808 Successful activation of L1 SAPI PTCCH on TS 7 <-- Downlink
<0006> oml.c:808 Successful activation of L1 SAPI PRACH on TS 7 <-- Uplink
<0006> oml.c:808 Successful activation of L1 SAPI PDTCH on TS 7 <-- Uplink
<0006> oml.c:813 Error activating L1 SAPI PTCCH on TS 7: Invalid parameter <-- Uplink
</pre>
<p>This is needed in order to support Continuous Timing Advance procedures on PDCH (see <a class="issue tracker-2 status-7 priority-2 priority-default" title="Feature: continuous timing advance loop using PTCCH (Stalled)" href="https://projects.osmocom.org/issues/1545">#1545</a>).</p>
<p>At the moment we can only send PTCCH blocks on Downlink, while the Access Burst (PTCCH/U) detection task is not enabled:</p>
<pre><code class="c syntaxhl"><span class="k">static</span> <span class="k">const</span> <span class="k">struct</span> <span class="n">sapi_dir</span> <span class="n">pdtch_sapis</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Pdtch</span><span class="p">,</span> <span class="n">GsmL1_Dir_TxDownlink</span> <span class="p">},</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Pdtch</span><span class="p">,</span> <span class="n">GsmL1_Dir_RxUplink</span> <span class="p">},</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Ptcch</span><span class="p">,</span> <span class="n">GsmL1_Dir_TxDownlink</span> <span class="p">},</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Prach</span><span class="p">,</span> <span class="n">GsmL1_Dir_RxUplink</span> <span class="p">},</span>
<span class="c">#if 0
{ GsmL1_Sapi_Ptcch, GsmL1_Dir_RxUplink }, // <-- PTCCH/U
{ GsmL1_Sapi_Pacch, GsmL1_Dir_TxDownlink },
#endif
</span><span class="p">};</span>
</code></pre>
<p>This SAPI has been disabled on purpose, because the error indication breaks dynamic timeslots in the BSC (see <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: PTCCH activation breaks dyn TS (Closed)" href="https://projects.osmocom.org/issues/1796">#1796</a>).</p>
<p>My best guess is that the DSP does not allow to enable both <em>GsmL1_Sapi_Prach</em> (Uplink) and <em>GsmL1_Sapi_Ptcch</em> (Uplink) at the same time. As was pointed out by Max, according to the DSP's docs the only channel combination with PTCCH support is <em>GsmL1_LogChComb_XIII</em>. As per 3GPP TS 45.002, this combination XIII includes the following channels:</p>
<ul>
<li>PDTCH/F</li>
<li>PACCH/F</li>
<li>PTCCH/F</li>
</ul>
<p>and PRACH is not a part of it! Perhaps we should enable <em>GsmL1_Sapi_Pacch</em> on <em>GsmL1_Dir_RxUplink</em> instead of <em>GsmL1_Sapi_Prach</em> in order to support Packet Control Ack in form of four Access Bursts, and try enabling <em>GsmL1_Sapi_Ptcch</em> on <em>GsmL1_Dir_RxUplink</em>:</p>
<pre><code class="c syntaxhl"><span class="k">static</span> <span class="k">const</span> <span class="k">struct</span> <span class="n">sapi_dir</span> <span class="n">pdtch_sapis</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Pdtch</span><span class="p">,</span> <span class="n">GsmL1_Dir_TxDownlink</span> <span class="p">},</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Pdtch</span><span class="p">,</span> <span class="n">GsmL1_Dir_RxUplink</span> <span class="p">},</span>
<span class="cm">/* PTCCH/D and PTCCH/U for Continuous Timing Advance loop */</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Ptcch</span><span class="p">,</span> <span class="n">GsmL1_Dir_TxDownlink</span> <span class="p">},</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Ptcch</span><span class="p">,</span> <span class="n">GsmL1_Dir_RxUplink</span> <span class="p">},</span>
<span class="cm">/* Packet Control Ack in form of four Access Bursts */</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Pacch</span><span class="p">,</span> <span class="n">GsmL1_Dir_RxUplink</span> <span class="p">},</span>
<span class="p">};</span>
</code></pre>
<p>I don't have a possibility to verify my (potentially wrong) assumption, so waiting for remote access to be provided by <a class="user active" href="https://projects.osmocom.org/users/7">laforge</a>.</p> Cellular Network Infrastructure - Feature #4006 (Stalled): TRX protocol: wind of changehttps://projects.osmocom.org/issues/40062019-05-16T19:54:33Zfixeria
<p>We are using TRX protocol in <a class="wiki-page" href="https://projects.osmocom.org/projects/osmobts/wiki">OsmoBTS</a> in order to "speak" with transceiver (e.g. <a class="wiki-page" href="https://projects.osmocom.org/projects/osmotrx/wiki">OsmoTRX</a>, FakeTRX). Basically it defines three interfaces: clock for TDMA frame clock indications, control (we agreed to call it TRXC) for transceiver management, and data (TRXD) for exchanging Rx/Tx bursts. It was first introduced in <a href="http://openbts.org/" class="external">OpenBTS</a> project, from which we forked <a class="wiki-page" href="https://projects.osmocom.org/projects/osmotrx/wiki">OsmoTRX</a>. For more information, please see: <a class="external" href="https://github.com/RangeNetworks/openbts/blob/master/TRXManager/README.TRXManager">https://github.com/RangeNetworks/openbts/blob/master/TRXManager/README.TRXManager</a>.</p>
<p>The protocol is being used for years, and it still serves us for good. However, it is extremely inflexible. For example, there is no way to send more information about received bursts on TRXD interface, than the fixed-size header already has (TDMA frame number, timeslot number, RSSI, ToA256). On TRXC interface, which is working over UDP as the other ones, there is no way to distinguish command retransmission, which may happen due to timeout, from a regular command. There is no way to notify the L1 (i.e. <a class="wiki-page" href="https://projects.osmocom.org/projects/osmobts/wiki">OsmoBTS</a>) about some events (e.g. device has been disconnected), no way to indicate transceiver version, and so on...</p>
<p>During <a class="wiki-page" href="https://projects.osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019">OsmoDevCon2019</a> (and before too) we have been discussing the idea of introducing the new version of TRX protocol, which would allow us to solve the mentioned problems. In order to keep backwards compatibility, both L1 and transceiver would initially use the old TRX protocol, while the new version can be optionally enabled by sending a command on TRXC interface. If the transceiver does support the new protocol, it would acknowledge the command. Otherwise, the command is rejected, so L1 would continue to work in "backwards compatibility" mode.</p>
<p>Finally, we need to write a proper protocol description like we already have for GSUP in <a class="external" href="https://git.osmocom.org/osmo-gsm-manuals/">https://git.osmocom.org/osmo-gsm-manuals/</a>. But before starting to work on this, let's create some kind of a wish list - what would you like to see in the new version of TRX protocol?</p> OsmoHLR - Bug #3717 (Stalled): SS/USSD: fix SS session inactivity timeouthttps://projects.osmocom.org/issues/37172018-11-29T23:57:23Zfixeria
<p>I just discovered that SS session inactivity timeout is never being rescheduled.</p>
<p>See ss_session_alloc() in 'src/hlr_ussd.c':</p>
<pre>
osmo_timer_setup(&ss->timeout, ss_session_timeout, ss);
/* NOTE: The timeout is currently global and not refreshed with subsequent messages
* within the SS/USSD session. So 30s after the initial SS message, the session will
* timeout! */
osmo_timer_schedule(&ss->timeout, 30, 0);
</pre>
<p>The correct behaviour would be to reschedule the timer on any activity.<br />Also, makes sense to have a possibility to configure this timer from the VTY.</p> OsmocomBB - Feature #3666 (New): trxcon: Introduce VTY interfacehttps://projects.osmocom.org/issues/36662018-10-24T12:16:08Zfixeria
<p>Having the VTY interface would allow one to configure various logging<br />parameters, observe some statistics, and moreover to configure<br />multiple L23 <-> TRX connections.</p>
<pre>
log stderr
logging filter all 1
logging print category 1
...
! One transceiver connection
trxcon foo
! TRX interface configuration
trx ip local 127.0.0.1
trx base-port local 5800
trx ip remote 127.0.0.1
trx base-port remote 5700
trx fn-advance 20
...
! L23 interface configuration
layer2-socket /tmp/osmocom_l2.foo
...
! Another transceiver connection
trxcon bar
...
! Another transceiver connection
trxcon zoo
...
</pre> Cellular Network Infrastructure - Feature #3628 (New): document nanoBTS calibration procedure usi...https://projects.osmocom.org/issues/36282018-10-04T11:13:31Zlaforge
<p>The nanoBTS has the capability to OCXO calibration against another (macro) BTS. We had implemented this in ipaccess-config, but we apparently never documented how it works.</p>
<p>Let's add it somewhere to the nanoBTS related wiki pages.</p>
<p>Without trying, I remember that it was part of the "Tests" that can be triggered via OML.</p>
<pre>
static const struct value_string test_names[] = {
»·······{ NM_IPACC_TESTNO_CHAN_USAGE, "Channel Usage" },
»·······{ NM_IPACC_TESTNO_BCCH_CHAN_USAGE, "BCCH Channel Usage" },
»·······{ NM_IPACC_TESTNO_FREQ_SYNC, "Frequency Synchronization" },
»·······{ NM_IPACC_TESTNO_BCCH_INFO, "BCCH Info" },
»·······{ NM_IPACC_TESTNO_TX_BEACON, "Transmit Beacon" },
»·······{ NM_IPACC_TESTNO_SYSINFO_MONITOR, "System Info Monitor" },
»·······{ NM_IPACC_TESTNO_BCCCH_MONITOR, "BCCH Monitor" },
</pre>
<p>I think you start with a CHAN_USAGE to see the receive level per ARFCN. You then proceed to a FREQ_SYNC to see which of those have a FCCH (and hence are BCCH/CCCH carrying).</p> OsmocomBB - Bug #3557 (New): trxcon: decoding errors after applying a new TCH modehttps://projects.osmocom.org/issues/35572018-09-16T09:52:18Zfixeria
<p>There are also some decoding errors after applying a new TCH mode from Channel Mode Modify:</p>
<pre>
<0005> sched_trx.c:263 (Re)configure TDMA timeslot #2 as TCH/H+SACCH
<0005> sched_trx.c:420 Activating lchan=TCH/H(0) on ts=2
<0005> sched_trx.c:420 Activating lchan=SACCH/TH(0) on ts=2
<0006> sched_lchan_xcch.c:96 Received incomplete data frame at fn=0 (0/104) for SACCH/TH(0)
<0006> sched_lchan_xcch.c:106 Received bad data frame at fn=0 (0/104) for SACCH/TH(0)
<0005> sched_clck.c:138 Clock indication: fn=22389
<0005> sched_clck.c:138 Clock indication: fn=22440
<0001> l1ctl.c:695 Received L1CTL_TCH_MODE_REQ (tch_mode=1, audio_mode=10)
<0005> sched_clck.c:138 Clock indication: fn=22491
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22513 on TCH/H(0) (rc=-1)
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22518 on TCH/H(0) (rc=-1)
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22522 on TCH/H(0) (rc=-1)
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22526 on TCH/H(0) (rc=-1)
<0005> sched_clck.c:138 Clock indication: fn=22542
<0005> sched_clck.c:138 Clock indication: fn=22593
<0005> sched_clck.c:138 Clock indication: fn=22644
<0005> sched_clck.c:138 Clock indication: fn=22695
<0005> sched_clck.c:138 Clock indication: fn=22746
<0005> sched_clck.c:138 Clock indication: fn=22797
</pre> libosmocore - Feature #3522 (New): libosmocoding: move TCH ordering functions to libosmocodec and...https://projects.osmocom.org/issues/35222018-09-04T20:49:08Zfixeria
<p>The GSM 05.03 implementation present in libosmocoding is using the RTP speech frame format for TCH coding functions. It is implemented in a way of performing 'canonical -> RTP' bit reordering in decoding functions, and 'RTP -> canonical' bit reordering in encoding functions. At the moment, the RTP format bit reordering implementation is not exposed.</p>
<p>This API could be used by some other projects (at least by osmo-gapk), moreover libosmocoding is already being linked against libosmocodec.</p> libosmocore - Feature #3521 (New): core/utils: engineering notation helpershttps://projects.osmocom.org/issues/35212018-09-04T20:32:52Zfixeria
<p>It would be great to have some auxiliary API to parse numbers written in the engineering notation (e.g. 945.6M, -33k) to the regular numbers (float?), and, vice versa, the regular numbers to engineering notation. This is useful in the cases where a user should provide some input, such as frequency (e.g. in osmo-arfcn) or sample rate.</p>
<p>Inspired by GNU Radio: <a class="external" href="https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/python/gnuradio/eng_notation.py">https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/python/gnuradio/eng_notation.py</a></p>
<p>If this feature also looks useful for others, I would implement it.</p> OsmocomBB - Feature #3399 (Stalled): mobile: refactor / finish external MNCC handler implementationhttps://projects.osmocom.org/issues/33992018-07-16T22:38:44Zfixeria
<p>In general, it is possible to connect <a class="wiki-page" href="https://projects.osmocom.org/projects/baseband/wiki/Mobile">mobile</a> application to an external MNCC-handler, such as LCR and <a class="wiki-page" href="https://projects.osmocom.org/projects/osmo-sip-conector/wiki">osmo-sip-conector</a>.<br />In case of the second one, <a class="wiki-page" href="https://projects.osmocom.org/projects/baseband/wiki/Mobile">mobile</a> can be even connected to a PBX, e.g. FreeSWITH or Asterisk:</p>
<p><div class="flash error">Error executing the <strong>graphviz_link</strong> macro (Missing template wiki_graphviz/macro with {:locale=>[:en], :formats=>[:atom], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, :ruby, :rsb]}. Searched in:
* "/usr/src/redmine/plugins/wiki_mscgen_plugin/app/views"
* "/usr/src/redmine/plugins/wiki_graphviz_plugin/app/views"
* "/usr/src/redmine/plugins/redmine_tags/app/views"
* "/usr/src/redmine/plugins/redmine_openid_provider/app/views"
* "/usr/src/redmine/plugins/redmine_mentions/app/views"
* "/usr/src/redmine/plugins/redmine_lightbox2/app/views"
* "/usr/src/redmine/plugins/redmine_checklists/app/views"
* "/usr/src/redmine/plugins/redmine_banner/app/views"
* "/usr/src/redmine/plugins/clipboard_image_paste/app/views"
* "/usr/src/redmine/app/views"
* "/usr/local/bundle/gems/redmine_crm-0.0.61/app/views"
)</div></p>
<p>The current implementation has the following problems:</p>
<ul>
<li>impossible to configure MNCC-socket path per MS instance,</li>
<li>TCH FR codec only,</li>
<li>no RTP support.</li>
</ul> GSM Audio Pocket Knife - Bug #3398 (New): build: configure fails if (optional) libalsa wasn't foundhttps://projects.osmocom.org/issues/33982018-07-16T20:45:23Zfixeria
<p>ALSA is optional dependency, which is only required for audio capture and playback.<br />We should not enforce this optional dependency as a mandatory one.</p> Cellular Network Infrastructure - Feature #3142 (New): Further simplification of "NITB like" setupshttps://projects.osmocom.org/issues/31422018-04-05T20:09:38Zlaforge
<p>Running the post-NITB network is quite a lot more complex than the old code.</p>
<p>There are some ideas on how to make it simpler to run small, self-contained networks while removing some complexity</p>
<ul>
<li>I was also wondering if we should spend time on "MGW-less operation". In theory, you only need OsmoMGW if you have no IP-level routing between your Abis / A / core network [like any decent network operator for security reasons]. But then, if you run everything on one machine, and don't need/want transcoding, and have transparent routing between all components, we could do without the MGW.</li>
</ul>
<ul>
<li>stp-less operation should also be possible (but make configuration actually more complicated), as both the "ASP" (client) and "SG" (server) role are inside libosmo-sigtran, and hence the server could run inside the MSC without the need of an external stp (osmo-stp is just a thin wrapper with vty around libosmo-sigtran)</li>
</ul>
<p>Let's keep this as a reminder and create sub-tasks as ideas materialize more</p> GSM Audio Pocket Knife - Bug #2514 (Stalled): GSM HR encoding result does not match the referencehttps://projects.osmocom.org/issues/25142017-09-15T14:39:13Zfixeria
<p>Implementing the automake transcoding tests, I found that GSM HR related<br />encoding tests are always fail, while decoding from the reference files<br />is ok.</p>
<p>Regression tests summary:</p>
<pre><code>1: procqueue ok<br /> 2: io/pq_file ok<br /> 3: io/pq_rtp ok<br /> 4: conv/enc/amr_efr ok<br /> 5: conv/enc/gsm ok<br /> 6: conv/enc/racal_hr FAILED (testsuite.at:49)<br /> 7: conv/enc/racal_fr ok<br /> 8: conv/enc/racal_efr ok<br /> 9: conv/enc/ti_hr FAILED (testsuite.at:79)<br /> 10: conv/enc/ti_fr ok<br /> 11: conv/enc/ti_efr ok<br /> 12: conv/enc/rtp_efr ok<br /> 13: conv/enc/rtp_hr_etsi FAILED (testsuite.at:119)<br /> 14: conv/enc/rtp_hr_ietf FAILED (testsuite.at:129)<br /> 15: conv/dec/amr_efr ok<br /> 16: conv/dec/gsm ok<br /> 17: conv/dec/racal_hr ok<br /> 18: conv/dec/racal_fr ok<br /> 19: conv/dec/racal_efr ok<br /> 20: conv/dec/ti_hr ok<br /> 21: conv/dec/ti_fr ok<br /> 22: conv/dec/ti_efr ok<br /> 23: conv/dec/rtp_efr ok<br /> 24: conv/dec/rtp_hr_etsi ok<br /> 25: conv/dec/rtp_hr_ietf ok</code></pre>
<p>The same problem can be discovered using the built-in shell<br />script named 'test_all_formats.sh'.</p>
<p>I have also attempted to compare the encoding results with<br />the reference files and found, that the mismatching bytes are<br />starting from 128th until 352 bytes.</p> OsmoPCU - Bug #2400 (Stalled): transmit SI13 on PACCH during long TBFshttps://projects.osmocom.org/issues/24002017-07-25T14:48:22Zlaforge
<pre>
5.5.1.3.3
SI13 reception failure If the mobile station has not received the SI13 or the PSI13 message within the
last 60 s, a SI13 reception failure has occurred. An SI13 reception failure shall result in a cell reselection.
5.5.2.1.3 System information on PACCH (and other logical channels)
The network may broadcast PSI and SI messages on PACCH. In particular, if a mobile station is busy in packet
transfer mode or MAC-Shared state and thus unable to receive the relevant blocks on the broadcast channels
(PBCCH or BCCH) for a period longer than 15 seconds, the following requirements apply: [...]
- If PBCCH is not present in the cell, the network may broadcast the PSI13 message on PACCH such that the
mobile station may receive the PSI13 messages at least every 15 s.
</pre>
<p>So basically this means that on a TBF that has a duration longer than 60s since the last SI13 was received on BCCH, a spec-compliant MS shall start cell re-selection, which will of course interrupt the transmission. We hence must periodically schedule SI13 in PACCH.</p> OsmoMSC - Feature #1973 (New): VLR: efficient subscriber lookuphttps://projects.osmocom.org/issues/19732017-03-08T14:52:10Zneelsnhofmeyr@sysmocom.de
<p>In libvlr, we (will) keep every subscriber in RAM as long as it still has valid auth tuples (3GPP TS 33.102 Annex C.2.3).<br />Most subscribers will still have auth tuples left upon detaching, so we would store <strong>all</strong> subscribers.<br />Storing numerous subscribers in a linear list is inefficient, implement a hash table for faster access times.</p> OsmoBTS - Feature #1755 (New): osmo-bts-sysmo L1: unify hLayer3 handlinghttps://projects.osmocom.org/issues/17552016-06-16T11:27:40Zneelsnhofmeyr@sysmocom.de
<p>In <a class="external" href="https://gerrit.osmocom.org/264">https://gerrit.osmocom.org/264</a> , some hLayer3 use was added.<br />However, some of the messages were already using hLayer3.</p>
<p>After the patch, the prim_init() sets a hLayer3 which is overwritten<br />shortly after that, so the other functionality is not affected by this patch.</p>
<p>Some functions to generate hLayer3 for a timeslot and similar already existed,<br />and also to retrieve a timeslot and similar back from a hLayer3 handle.</p>
<p>And also, the other hLayer3 functions use a "magic" byte<br />(like the most significant byte always set to 0xbb).</p>
<p>So in fact, we should have rejected this patch, and we should follow up with<br />a merger of my hLayer3 to the existing hLayer3 infrastructure.<br />The priority is low though, since no harm is done.</p>
<p>See:</p>
<ul>
<li>osmo-bts/src/osmo-bts-sysmo/oml.c
<ul>
<li>mph_send_activate_req()</li>
<li>mph_send_config_logchpar()</li>
<li>mph_send_config_ciphering()</li>
<li>mph_send_deactivate_req()</li>
</ul></li>
</ul> OsmoMSC - Feature #1597 (Stalled): External interface for USSDhttps://projects.osmocom.org/issues/15972016-02-23T15:52:03Zlaforge
<p>we already have SMPP for SMS, but don't have similar functionality for USSD, i.e. a way in which external applications can exchange USSD with MSs.</p>
<p>There are some provisions for USSD in SMPP, but I think they don't really appreciate the session-oriented nature of USSD.</p>
<p>In either case, I'm not aware of any standard to hand USSD to external applications. Of course there's MAP, but nobody wants to implement that in an external application...</p> OsmoBTS - Feature #1576 (New): consider using hLayer2 as a pointer storagehttps://projects.osmocom.org/issues/15762016-02-23T15:38:30Zlaforge
<p>This would speed up the l1if_hLayer_to_lchan lookup. Not sure if it's worth the extra risk.</p> OsmoBTS - Feature #1568 (New): Move various code bits to libosmocorehttps://projects.osmocom.org/issues/15682016-02-23T15:28:32Zlaforge
<p>There are plenty of FIXMEs in src/common.c about code that should be moved to libosmocore as a clean-up</p> OsmoPCU - Feature #1545 (Stalled): continuous timing advance loop using PTCCHhttps://projects.osmocom.org/issues/15452016-02-23T15:02:54Zlaforge
<p>We currently only implement the "initial TA" where the TA of a MS is determined at time the TBF is established. If the MS moves more than 1 TA during a TBF being active, this leads to problems.</p>
GPRS has the PTCCH for this, a special channel in the PDCH channel combination multiplex, using which we can instruct a sub-set of 16 MS (whether TBFs are active or not) to adjust their timing advance continuously. What needs to be done is
<ul>
<li>code to generate the PTCCH/D messages</li>
<li>code to parse the PTCCH/U messages</li>
<li>code to determine which 16 MS will be part of the current PTCCH subset</li>
<li>unit tests for the above</li>
</ul>
<p>We also need to see how we can test this with actual hardware, in a way that TA exists (and changes) over time. Unfortuantely we don't have a MS-side GPRS implementation for OsmocomBB, because then we could simply artificially delay the transmit burst timing to make the network determine a higher TA.</p> OsmoPCU - Feature #1526 (Stalled): Acquire/update timing advance (TA)https://projects.osmocom.org/issues/15262016-02-22T20:59:31Zzecke
<p>Currently the TA is derived from the initial RACH request and never updated during the lifetime of a TBF.</p>
<p>Is this handled correctly for network initiated DL TBF establishment?</p>
<p>TS 44.018, 3.5.3.1.2 asks for TA determination on DL TBF establshment if the MS is idle and the TA is not known (see "If the network does not have a valid timing advance ...").</p>
<p>Other related issues:</p>
<ul>
<li>The burst timing info (qta) should be applied (see <a class="issue tracker-1 status-7 priority-3 priority-high3" title="Bug: re-integrate tracing + card reader modes into SIMtrace2 firmware (SAM3S) (Stalled)" href="https://projects.osmocom.org/issues/1705">#1705</a>)</li>
<li>Support access bursts on PDCH which can be requested by the PCU if the current TA is unknown (44.060)</li>
</ul> OsmocomBB - Feature #1461 (Stalled): include some version information / negotiation in the L1CTL ...https://projects.osmocom.org/issues/14612016-02-19T22:48:42Zlaforge
<p>The host software should have a way to determine the firmware build/version, as well as the enabled features (TX support or not, burst_ind, ...).</p>