Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-26T13:03:08ZOpen Source Mobile Communications
Redmine OsmoBSC - Bug #6422 (Feedback): latest: BSC_Tests.TC_ctrl_location started fo fail on March 15thhttps://osmocom.org/issues/64222024-03-26T13:03:08Zlaforge
<ul>
<li><a class="external" href="https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/ttcn3-bsc-test-sccplite/test_results_analyzer/">https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/ttcn3-bsc-test-sccplite/test_results_analyzer/</a></li>
</ul>
<p>This test used to pass and started failing since March 15. It fails consistently ever since. Interestingly, master is not affected.</p>
<p>I don't see any commits to osmo-ttcn3-hacks.git touching the BSC code which were merged on March 14th.</p>
<p>Does anyone have any ideas?</p> Cellular Network Infrastructure - Bug #6349 (Feedback): example configs missing in release tarballshttps://osmocom.org/issues/63492024-01-28T15:42:07Zfixeria
<p>Today I created a release <code>osmo-bts v1.7.2</code> package for Arch Linux:</p>
<p><a class="external" href="https://aur.archlinux.org/packages/osmo-bts">https://aur.archlinux.org/packages/osmo-bts</a><br /><a class="external" href="https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=osmo-bts">https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=osmo-bts</a></p>
<p>which downloads, unpacks, and builds the latest release tarball:</p>
<p><a class="external" href="https://downloads.osmocom.org/releases/osmo-bts/osmo-bts-1.7.2.tar.bz2">https://downloads.osmocom.org/releases/osmo-bts/osmo-bts-1.7.2.tar.bz2</a></p>
<p>Unfortunately, I am hitting a build error when running <code>makepkg</code>:</p>
<pre>
Making all in doc
make[2]: Entering directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc'
Making all in examples
make[3]: Entering directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc/examples'
make[3]: *** No rule to make target 'trx/osmo-bts-trx.cfg', needed by 'all-am'. Stop.
make[3]: Leaving directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc/examples'
make[2]: *** [Makefile:387: all-recursive] Error 1
make[2]: Leaving directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc'
make[1]: *** [Makefile:446: all-recursive] Error 1
make[1]: Leaving directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2'
make: *** [Makefile:378: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...
</pre>
<p>The problem can be reproduced by downloading and building the tarball manually (make sure to build with <code>--enable-trx</code>).</p>
<p>Surprisingly, <code>trx/osmo-bts-trx.cfg</code> is not present in the release tarball:</p>
<pre>
$ tar -tvf osmo-bts-1.7.2.tar.bz2 | grep doc/examples
drwxr-xr-x 1000/1000 0 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/
-rw-r--r-- 1000/1000 23617 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/Makefile.in
drwxr-xr-x 1000/1000 0 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/virtual/
-rw-r--r-- 1000/1000 1271 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/virtual/osmo-bts-virtual.cfg
-rw-r--r-- 1000/1000 1501 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/Makefile.am
</pre>
<p>I believe the problem is that in <code>doc/examples/Makefile.am</code> we add config files to <code>EXTRA_DIST</code> conditionally:</p>
<pre><code class="shell syntaxhl"><span class="k">if </span>ENABLE_TRX
doc_trxdir <span class="o">=</span> <span class="si">$(</span>docdir<span class="si">)</span>/examples/osmo-bts-trx
doc_trx_DATA <span class="o">=</span> <span class="se">\</span>
trx/osmo-bts-trx.cfg <span class="se">\</span>
trx/osmo-bts-trx-calypso.cfg
EXTRA_DIST +<span class="o">=</span> <span class="si">$(</span>doc_trx_DATA<span class="si">)</span>
OSMOCONF_FILES +<span class="o">=</span> trx/osmo-bts-trx.cfg
endif
</code></pre>
<p>So if the project is configured without <code>--enable-foo</code>, then <code>make dist-bzip2</code> will produce a tarball without those files added conditionally.</p> OsmoBSC - Bug #6019 (New): "PCU version PCU socket has LOST connection connected"https://osmocom.org/issues/60192023-04-28T12:17:03Zfixeria
<p>This is what I see in the output of <code>show bts</code> command:</p>
<pre>
OsmoBSC> show bts 0
BTS 0 is of osmo-bts type in band GSM900, has CI 0 LAC 1, BSIC 63 (NCC=7, BCC=7) and 1 TRX
Description: (null)
ARFCNs: 85
PCU version PCU socket has LOST connection connected
...
</pre>
<p>what means that somehow <code>bts->pcu_version[]</code> contains <code>PCU socket has LOST connection</code>. I am also seeing this in logging:</p>
<pre>
апр 28 19:14:07 DELL osmo-bsc[543401]: DNM NOTICE abis_nm.c:348 OC=BTS(01) INST=(00,ff,ff): Reported connected PCU version 1.2.0.31-33a1bf3
...
апр 28 19:14:10 DELL osmo-bsc[543401]: DNM NOTICE abis_nm.c:348 OC=BTS(01) INST=(00,ff,ff): Reported connected PCU version PCU socket has LOST connection
</pre>
<p>This looks a bit confusing, maybe we should just say "PCU state"?</p> OsmoBTS - Bug #5953 (Feedback): ttcn3-bts-test: TC_ms_pwr_ctrl_{constant,pf_ewma} are failinghttps://osmocom.org/issues/59532023-03-21T12:57:05Zfixeria
<p>These two testcases were added by me back in 2020 and have been passing until recently:</p>
<pre>
commit c7ef03057fe6644372b8bf08c165afef29fc600f
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Sun Oct 18 19:24:18 2020 +0700
BTS_Tests: introduce TC_ms_pwr_ctrl_constant()
Unexpected MS Power level change: 7 -> 13
BTS_Tests.ttcn:9052 BTS_Tests control part
BTS_Tests.ttcn:8111 TC_ms_pwr_ctrl_constant testcase
</pre>
<pre>
commit 652e60eb83f928036a649fa45f7a4a4eb8207eac
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Sun Oct 18 19:43:27 2020 +0700
BTS_Tests: add TC_ms_pwr_ctrl_pf_ewma: test EWMA based power filtering
Unexpected MS Power level change: 7 -> 13
BTS_Tests.ttcn:9053 BTS_Tests control part
BTS_Tests.ttcn:8178 TC_ms_pwr_ctrl_pf_ewma testcase
</pre>
<p>The "red age" of both TCs is 102 days ago for both -master and -latest.<br />I guess this might be related to the recent changes in osmocom-bb.git/trxcon.</p> OsmoBTS - Bug #5952 (New): ttcn3-bts-test: TC_ho_physical_info failshttps://osmocom.org/issues/59522023-03-21T12:35:13Zfixeria
<p>The testcase was added by me and is failing since the very beginning:</p>
<pre>
commit 1ab332ff86117e7aa22ca973993ea16bedbf63b7
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Sat Mar 12 15:31:23 2022 +0300
BTS_Tests: add new test case TC_ho_physical_info
</pre>
<p>The problem is explained in the commit message:</p>
<pre>
Currently the new test case fails for several reasons:
* osmo-bts-trx starts transmitting on DCCH before the handover
Access Burst is received, this is wong;
* trxcon immediately starts sending dummy frames on Uplink
DCCH, causing osmo-bts to stop sendig RR Physical Info.
</pre> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> Cellular Network Infrastructure - Bug #5749 (New): configure.ac: default CFLAGS, LT_INIT adds "-g...https://osmocom.org/issues/57492022-11-08T18:04:34Zfixeria
<p>Today I spent quite some time trying to figure out why am I seeing <code>-g -O2</code> present in <code>CFLAGS</code> by default when building some projects. As it turned out, it's the <code>LT_INIT</code> (called in <code>configure.ac</code>) adding <code>-g -O2</code> to <code>CFLAGS</code> if they're empty. I could not find anything in documentation describing this behavior. The problem is that this behavior is inconsistent across the Osmocom projects: for some you get empty CFLAGS by default, for some you get <code>CFLAGS=-g -O2</code>. Most likely this inconsistency was introduced when we started to specify the <code>-std=gnu11</code> explicitly: in some projects (e.g. libosmocore.git, libosmo-abis.git, osmo-bsc) we set <code>CFLAGS</code> before calling the <code>LT_INIT</code>, in some (osmo-hlr, osmo-iuh, osmo-sgsn) after.</p>
<p>We need to decide on whether we want to have empty <code>CFLAGS</code> or <code>CFLAGS=-g -O2</code> set by default. Personally I prefer the former approach, because explicit is better then implicit. <a class="user active" href="https://osmocom.org/users/52">Hoernchen</a> also prefers the former and does not want "magical flags out of nowhere". Either way, the default behavior should be consistent across all Osmocom projects. <a class="user active" href="https://osmocom.org/users/7">laforge</a> what do you think?</p> Core testing infrastructure - Bug #5665 (Stalled): ERROR: files left in build directory after dis...https://osmocom.org/issues/56652022-08-28T09:21:41Zfixeria
<p>Since recently we're observing sporadic master-* job failures on Jenkins. There is always a coredump file, which makes 'distcleancheck' target fail:</p>
<pre>
ERROR: files left in build directory after distclean:
./tests/core
make[1]: Leaving directory '/build/libosmocore-1.7.0.26-862dd/_build/sub'
make[1]: *** [Makefile:1010: distcleancheck] Error 1
make: *** [Makefile:941: distcheck] Error 1
</pre>
<p>This is not specific to libosmocore, I saw master-osmo-{bsc,msc} failing with the same verdict too.</p> libosmocore - Bug #5570 (New): coding: decode in-band data in AMR's special DTX frames (SID_FIRST...https://osmocom.org/issues/55702022-05-21T14:21:38Zfixeria
<p>Whenever gsm0503_tch_a[fh]s_decode_dtx() detects a special AMR's DTX frame (e.g SID_FIRST, SID_UPDATE, SID_ONSET) it immediately jumps out and ignores the coded in-band data (CMI, CMC/CMR). A hard-coded default value=0 is assigned instead of the actual value(s) indicated by the MS. This basically breaks rate adaptation when DTXu is employed.</p> OsmoBTS - Bug #5517 (New): ttcn3-bts-test: new sporadic test case failureshttps://osmocom.org/issues/55172022-04-07T21:37:29Zfixeria
<p>Since recently, the following testcases sporadically fail:</p>
<ul>
<li>BTS_Tests.TC_tx_power_ramp_adm_state_change,</li>
<li>BTS_Tests.TC_rsl_ms_pwr_dyn_ass_updown,</li>
<li>BTS_Tests.TC_rsl_ms_pwr_dyn_up.</li>
</ul>
<p>We should investigate why and try to fix them.</p> OsmoBTS - Bug #5242 (Stalled): A-bis/RSL: CRCX ACK indicates '0.0.0.0' as the local/bind addresshttps://osmocom.org/issues/52422021-09-30T09:25:47Zfixeria
<p>Currently both TC_speech_rtp_tchf and TC_speech_rtp_tchh fail, because CRCX ACK from osmo-bts indicates '0.0.0.0' as the local/bind address. The local/bind address of osmo-bts is needed in order to know where to send RTP packets for the RTP_Emulation component, and of course '0.0.0.0' cannot be used as the remote address for send(). See the attached PCAP file.</p> OsmoBTS - Feature #5025 (New): Missing TTCN-3 coverage for the Timing Advance loophttps://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://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://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> OsmoBTS - Feature #4941 (Stalled): VAMOS support in OsmoBTShttps://osmocom.org/issues/49412021-01-12T14:05:15Zlaforge
<p>This ticket should document what needs to be done in terms of supporting <a class="wiki-page" href="https://osmocom.org/projects/cellular-infrastructure/wiki/VAMOS">VAMOS</a> from <a class="wiki-page" href="https://osmocom.org/projects/osmobts/wiki/OsmoBTS">OsmoBTS</a>, and to track its status via check-lists and possibly sub-issues.</p>
<p>Our implementation will be focusing <code>on osmo-bts-trx</code> as none of the "proprietary PHY" we support implement any VAMOS support.</p>
This likely includes (at least)
<ol>
<li>Indication of [which level of] VAMOS support the BTS has via OML attributes to BSC</li>
<li>Implementation of "shadow TRX" concept in data structures</li>
<li>Implementation of VAMOS related RSL extensions on Abis</li>
<li>Implementation of a new TRXDv2 protocol from/to the TRX</li>
<li>VAMOS-aware uplink + downlink power control</li>
<li>generation of one set of downlink symbols from the real + shadow timeslot/lchan</li>
</ol>
<p>The corresponding BSC related work is tracked in <a class="issue tracker-2 status-7 priority-3 priority-high3" title="Feature: VAMOS support in OsmoBSC (Stalled)" href="https://osmocom.org/issues/4940">#4940</a></p> OsmoBSC - Bug #4848 (Feedback): osmo-bsc user manual shows tables with per-bts counters three (!)...https://osmocom.org/issues/48482020-11-04T16:14:28Zlaforge
<p>The current PDF file (attached for reference) contains the "implemented counters" three times. Tables 8 + 9 appear to be identical copies of Table 7.</p> OsmoBTS - Bug #4801 (Stalled): BTS_Tests.TC_tch_sign_l2_fill_frame_dtxd failshttps://osmocom.org/issues/48012020-10-11T19:52:01Zlaforge
<p>The tests fails with the sttement</p>
<pre>
TC_tch_sign_l2_fill_frame_dtxd(6)@nataraja: received only 2+0 (SACCH+other) out of 3 expected fill frames
MTC@nataraja: Test case TC_tch_sign_l2_fill_frame_dtxd finished. Verdict: fail reason: "BTS_Tests.ttcn:6675 : Not enough fill frames received"
</pre>
<p>So it seems like the SACCH in downlink is received, but the fill frames that should be sent by the related code in osmo-bts (<a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/10415">https://gerrit.osmocom.org/c/osmo-bts/+/10415</a>) are either not sent, or somehow lost, or not detected by the test case.</p> libosmocore - Bug #4797 (Feedback): vty: the output of 'show ns' command is confusinghttps://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> OsmoBTS - Bug #4771 (Stalled): Don't log NOTICE messages on missing uplink burstshttps://osmocom.org/issues/47712020-10-01T12:05:51Zlaforgelibosmocore - Bug #4731 (Stalled): LAPDm does not implement SAPI priorities between data link layershttps://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> OsmoBTS - Bug #4592 (Stalled): osmo-bts-trx: make sure that handover detection workshttps://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://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> OsmoBTS - Bug #4500 (Stalled): osmo-bts-{sysmo,oc2g,litecell15}: PTCCH/U is not enabled on PDCH t...https://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://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://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://osmocom.org/users/7">laforge</a>.</p> Cellular Network Infrastructure - Feature #4006 (Stalled): TRX protocol: wind of changehttps://osmocom.org/issues/40062019-05-16T19:54:33Zfixeria
<p>We are using TRX protocol in <a class="wiki-page" href="https://osmocom.org/projects/osmobts/wiki">OsmoBTS</a> in order to "speak" with transceiver (e.g. <a class="wiki-page" href="https://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://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://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://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> Cellular Network Infrastructure - Feature #3628 (New): document nanoBTS calibration procedure usi...https://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> libosmocore - Feature #3522 (New): libosmocoding: move TCH ordering functions to libosmocodec and...https://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://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> GSM Audio Pocket Knife - Bug #3398 (New): build: configure fails if (optional) libalsa wasn't foundhttps://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://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://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> OsmoBTS - Feature #1576 (New): consider using hLayer2 as a pointer storagehttps://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://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>