Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.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://projects.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> OsmoMSC - Bug #6414 (Feedback): ttcn3-msc-test: TC_ho_inter_bsc_a5_[134] are failing with io_uringhttps://projects.osmocom.org/issues/64142024-03-22T07:59:15Zfixeria
<p>Since recently, we started executing ttcn3-msc-test (among with some other testsuites) with <code>LIBOSMO_IO_BACKEND=IO_URING</code> in a separate job. Compared to the "normal" job, the IO_URING one exhibits a regression since <a href="https://jenkins.osmocom.org/jenkins/view/TTCN3-io_uring/job/ttcn3-msc-test-io_uring/5/" class="external">build 5</a> (Mar 15, 2024):</p>
<ul>
<li>TC_ho_inter_bsc_a5_3 is failing "reliably",</li>
<li>TC_ho_inter_bsc_a5_<sup><a href="#fn14">14</a></sup> are alternating between pass and fail.</li>
</ul>
<p>I was unable to reproduce the problem, neither locally on my machine nor on the dedicated build server in Docker env.</p> Cellular Network Infrastructure - Bug #6349 (Feedback): example configs missing in release tarballshttps://projects.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> OsmocomBB - Feature #6132 (New): Add MS_GPRS_Tests to osmo-ttcn3-hackshttps://projects.osmocom.org/issues/61322023-08-02T18:18:57Zpespin
<p>It would be really great to have something similar to existing TTCN3 PCU_Tests, testing RLC/MAC, but for the MS side, using the "modem" app.</p> OsmoBSC - Bug #6019 (New): "PCU version PCU socket has LOST connection connected"https://projects.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://projects.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://projects.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> pySim - Bug #5878 (New): pySim shell: version fails with DistributionNotFoundhttps://projects.osmocom.org/issues/58782023-01-26T17:55:43Zlynxis
<p>I'm running into a DistributionNotFound error when running pysim.</p>
<ul>
<li>debian bullseye</li>
<li>pcsclite</li>
<li>pipenv</li>
<li>swig</li>
<li>simcard congster prepaid sim</li>
</ul>
<p>I would guess the dependencies aren't right or the pySim scripts needs to be installed by the setup.py.</p>
<pre>
git clone https://gitea.osmocom.org/sim-card/pysim.git
cd pysim
pipenv install -r requirements.txt
pipenv shell
./pySim-shell.py
version
</pre>
<pre>
(pysim-wiDMH_1-) lynxis@pysim:~/pysim$ ./pySim-shell.py -p 0
Using PC/SC reader interface
Waiting for card...
Autodetection failed
Warning: Could not detect card type - assuming a generic card type...
Info: Card is of type: UICC-SIM
AIDs on card:
USIM: a0000000871002ff4994208903100000 (EF.DIR)
Welcome to pySim-shell!
pySIM-shell (MF)> help
Documented commands (use 'help -v' for verbose/'help <topic>' for details):
ISO7816 Commands
================
activate_file deactivate_file open_channel suspend_uicc
change_chv disable_chv select unblock_chv
close_channel enable_chv status verify_chv
pySim Commands
==============
bulk_script dir equip intro tree version
desc echo export reset verify_adm
TS 102 222 Administrative Commands
==================================
create_df delete_file terminate_df
create_ef terminate_card_usage terminate_ef
pySim-shell built-in commands
=============================
alias edit history py run_pyscript set shortcuts
apdu help macro quit run_script shell
pySIM-shell (MF)> version
EXCEPTION of type 'DistributionNotFound' occurred with message: 'The 'pySim' distribution was not found and is required by the application'
To enable full traceback, run the following command: 'set debug true'
pySIM-shell (MF)> set debug true
debug - was: False
now: True
pySIM-shell (MF)> version
Traceback (most recent call last):
File "/home/lynxis/.local/share/virtualenvs/pysim-wiDMH_1-/lib/python3.9/site-packages/cmd2/cmd2.py", line 2129, in onecmd_plus_hooks
stop = self.onecmd(statement, add_to_history=add_to_history)
File "/home/lynxis/.local/share/virtualenvs/pysim-wiDMH_1-/lib/python3.9/site-packages/cmd2/cmd2.py", line 2559, in onecmd
stop = func(statement)
File "/home/lynxis/pysim/./pySim-shell.py", line 457, in do_version
self.poutput(pkg_resources.get_distribution('pySim'))
File "/home/lynxis/.local/share/virtualenvs/pysim-wiDMH_1-/lib/python3.9/site-packages/pkg_resources/__init__.py", line 481, in get_distribution
dist = get_provider(dist)
File "/home/lynxis/.local/share/virtualenvs/pysim-wiDMH_1-/lib/python3.9/site-packages/pkg_resources/__init__.py", line 357, in get_provider
return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]
File "/home/lynxis/.local/share/virtualenvs/pysim-wiDMH_1-/lib/python3.9/site-packages/pkg_resources/__init__.py", line 900, in require
needed = self.resolve(parse_requirements(requirements))
File "/home/lynxis/.local/share/virtualenvs/pysim-wiDMH_1-/lib/python3.9/site-packages/pkg_resources/__init__.py", line 786, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'pySim' distribution was not found and is required by the application
EXCEPTION of type 'DistributionNotFound' occurred with message: 'The 'pySim' distribution was not found and is required by the application'
</pre> Cellular Network Infrastructure - Bug #5749 (New): configure.ac: default CFLAGS, LT_INIT adds "-g...https://projects.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://projects.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://projects.osmocom.org/users/7">laforge</a> what do you think?</p> OsmoPCU - Bug #5696 (Stalled): RLC/MAC: poll timeout when assigning a multi-slot DL TBFhttps://projects.osmocom.org/issues/56962022-10-05T07:58:36Zfixeria
<p>One of my phones, Sony Ericsson K800i, fails to complete <code>PDP Context Activation</code> procedure. Thanks to TEMS, I found out that the phone never receives <code>Activate PDP Context Accept</code> message. Further analysis revealed that <code>Activate PDP Context Request</code> message from the phone triggers allocation of a multi-slot Downlink TBF, which includes TS6 and TS7. For some reason, <strong>the phone ACKnowledges allocation of Downlink TBF on TS7 instead of TS6</strong>, what confuses osmo-pcu and causes retransmissions of the <code>PACKET_DOWNLINK_ASSIGNMENT</code> message.</p> Core testing infrastructure - Bug #5665 (Stalled): ERROR: files left in build directory after dis...https://projects.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://projects.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://projects.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> OsmoMSC - Bug #5340 (New): ttcn3-msc-test: more memory leakshttps://projects.osmocom.org/issues/53402021-12-07T14:17:36Zfixeria
<p>We have talloc reports in the build artifacts starting from today:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/1490/artifact/logs/msc-tester/*.talloc">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/1490/artifact/logs/msc-tester/*.talloc</a></p>
<p>And here one can clearly see leaked memory (MSC_Tests_Iu.TC_mo_cc_iu_release executed last):</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/1490/artifact/logs/msc-tester/MSC_Tests_Iu.TC_mo_cc_iu_release.talloc/*view*/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/1490/artifact/logs/msc-tester/MSC_Tests_Iu.TC_mo_cc_iu_release.talloc/*view*/</a></p>
<a name="Chunk-bssmap-clear-command"></a>
<h3 >Chunk 'bssmap: clear command'<a href="#Chunk-bssmap-clear-command" class="wiki-anchor">¶</a></h3>
<pre>
msgb contains 17400 bytes in 16 blocks (ref 0) 0x563205605390
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057a0290
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057f30c0
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057e39e0
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057eca30
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057d7740
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057a4e50
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057a5e80
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057c9fe0
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057d2120
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057ed520
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057ce880
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632058004a0
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057c8940
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x563205800aa0
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057bb620
</pre>
<p>I can reproduce this leak by running MSC_Tests.TC_ho_inter_bsc manually.</p>
<a name="Chunk-struct-sgs_connection"></a>
<h3 >Chunk 'struct sgs_connection'<a href="#Chunk-struct-sgs_connection" class="wiki-anchor">¶</a></h3>
<pre>
struct osmo_stream_srv_link contains 3688 bytes in 24 blocks (ref 0) 0x563205791920
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cc010
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cc2d0
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057b0760
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cd200
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057e16c0
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057f76e0
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057fa3b0
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cc630
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057b5a00
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057d1e20
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057ddd50
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057d6b30
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057dc280
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057e3030
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057f80d0
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057e2e80
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057b4410
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057c7ad0
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cdf10
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057b0a50
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057d95e0
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x563205794760
</pre>
<p>This is weird, I would expect all SGs connections to be terminated at some point?</p>
<a name="Chunk-struct-vlr_subscr"></a>
<h3 >Chunk 'struct vlr_subscr'<a href="#Chunk-struct-vlr_subscr" class="wiki-anchor">¶</a></h3>
<pre>
struct vlr_instance contains 315472 bytes in 658 blocks (ref 0) 0x56320577c0d0
struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x563205837060
struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x563205836b10
SGs-UE(imsi:262420000001131)[0x563205836b10] contains 45 bytes in 1 blocks (ref 0) 0x563205814560
imsi:262420000001131 contains 21 bytes in 1 blocks (ref 0) 0x56320581c120
struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x563205838a50
struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x563205839130
SGs-UE(imsi:262420000001130)[0x563205839130] contains 45 bytes in 1 blocks (ref 0) 0x563205836f10
imsi:262420000001130 contains 21 bytes in 1 blocks (ref 0) 0x563205803440
struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x5632058360e0
struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x563205830410
SGs-UE(imsi:262420000001129)[0x563205830410] contains 45 bytes in 1 blocks (ref 0) 0x563205829750
imsi:262420000001129 contains 21 bytes in 1 blocks (ref 0) 0x56320581be90
struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x563205832900
struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x563205832fe0
SGs-UE(imsi:262420000001128)[0x563205832fe0] contains 45 bytes in 1 blocks (ref 0) 0x563205810490
imsi:262420000001128 contains 21 bytes in 1 blocks (ref 0) 0x5632058318e0
struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x56320582a920
struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x56320581d030
SGs-UE(imsi:262420000001127)[0x56320581d030] contains 45 bytes in 1 blocks (ref 0) 0x56320581f700
imsi:262420000001127 contains 21 bytes in 1 blocks (ref 0) 0x5632058156e0
...
</pre>
<p>This is probably not a problem, the lifetime of a VLR subscriber is controlled by T3212, which is set to 60m by default.</p> 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 - Bug #5242 (Stalled): A-bis/RSL: CRCX ACK indicates '0.0.0.0' as the local/bind addresshttps://projects.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://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> OsmoBTS - Feature #4941 (Stalled): VAMOS support in OsmoBTShttps://projects.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://projects.osmocom.org/projects/cellular-infrastructure/wiki/VAMOS">VAMOS</a> from <a class="wiki-page" href="https://projects.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://projects.osmocom.org/issues/4940">#4940</a></p> OsmoPCU - Bug #4879 (Stalled): endless pdch.cpp:809 Got CS-N RLC block: R=0, SI=0, TFI=0, CPS=0, ...https://projects.osmocom.org/issues/48792020-11-29T23:17:31Zfixeria
<p>I just upgraded all osmo-{ran,cni} components to the recent master, and now quite often run into a situation when the MS (at least Sony Ericsson K800i, TEMS) keeps sending the same Uplink block again and again. I am not sure what exactly causes it, but I can reproduce it more or less reliably by starting Opera Mini (<a class="external" href="http://people.osmocom.org/fixeria/j2me/opera_mini.jar">http://people.osmocom.org/fixeria/j2me/opera_mini.jar</a>). When started for the first time, Opera initiates the installation process, and this is where the problem usually shows up.</p>
<pre>
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACMEAS INFO gprs_rlcmac_meas.cpp:108 MS(TLLI=0xc5849e78, IMSI=901990000000021, TA=0, 10/0, UL DL) UL RSSI: -29 dBm
</pre>
<p>Please see the attached capture file. Some highlights:</p>
<pre>
43585 RACH!
43591 IMM ASS (single block)
43731 UL Packet Resource Request
43799 DL Packet Uplink Assignment (TS=6 USF=0)
...
43910 UL DATA (BSN=0 CV=15)
...
43915 UL DATA | TCP FIN,ACK (Opera Mini closes connection to the server)
...
43918 UL DATA (BSN=3 CV=15)
43955 UL DATA (BSN=5 CV=14) <-- 14 RLC blocks left
...
44070 UL DATA (BSN=14 CV=5)
...
44146 UL DATA (BSN=19 CV=0) <-- 0 RLC blocks left
...
44149 UL DATA (BSN=19 CV=0) <-- re-transmission
44152 UL DATA (BSN=19 CV=0) <-- re-transmission
</pre>
<p>starting from frame 44149, the MS keeps transmitting the same RLC/MAC block ('35bdc794cd2b631285b2d43513'O). Interestingly enough, after each re-transmission the PCU logs "GPRS DL CTRL: PACKET_UPLINK_ACK_NACK", but <strong>does not actually send it</strong> (dummy RLC/MAC frames are not recorded). And this goes like that unless I turn off the phone. At the same time, Downlink blocks are received and accepted by the MS on the same timeslot.</p>
<p>OsmoPCU 58cd1d2f8a0474de45112e8d6e460051494eba79<br />OsmoBTS def24f0d9af2463a5ef557d35f23abd5b4d07120</p> OsmoBSC - Bug #4848 (Feedback): osmo-bsc user manual shows tables with per-bts counters three (!)...https://projects.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://projects.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> OsmoBTS - Bug #4771 (Stalled): Don't log NOTICE messages on missing uplink burstshttps://projects.osmocom.org/issues/47712020-10-01T12:05:51ZlaforgeOsmocomBB - 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> 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 #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> OsmocomBB - Feature #2409 (Stalled): Add GPRS support to virt_phy and L1CTLhttps://projects.osmocom.org/issues/24092017-07-29T12:31:13Zlaforge
<p>It should be rather simple to add GPRS support to virt_phy. The more interesting question is how to strucutre the L1CTL interface.</p>
It could simply
<ul>
<li>get configuration as to which timeslots are relevant to UL/DL TBFs via L1CTL</li>
<li>forward all downlink blocks on any of the related timeslots via L1CTL</li>
<li>transmit uplink blocks as instructed by L1CTL</li>
</ul>
<p>However, the uplink transmission can be either static, dynamic or extended dynamic allocation. In the dynamic cases, uplink is transmitted whenever the USF of the current downlink block matches the USF of the TBF. This has rather tight timing, as there's only the "3 timeslot" shift between DL and UL.</p>
<p>If this is critical, the L1 (virt_phy in this case) would have to be tightly integrated with the MAC layer in order to decode the USF of the MAC header. Given the USF is the three LSB of every first octet of each downlink block, it should be rather simple to match on that.</p>
<p>Let's investigate what the 3GPP specs have in mind in terms of a L1-SAP between L1 and the MAC layer in GPRS.</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> 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>