Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-08T13:33:39ZOpen Source Mobile Communications
Redmine OsmoUPF - Feature #6394 (Stalled): Basic URR (Usage Reporting Rule) support for tunnel mappinghttps://osmocom.org/issues/63942024-03-08T13:33:39Zlaforge
<p>Implement basic support for URR (Usage Reporting Rule).</p>
The goal here is to
<ul>
<li>count the number of packets and bytes within each TEID (ul/dl separately)</li>
<li>periodically report those counters via PFCP to the control plane</li>
<li>report the final counters when the tunnel is closed</li>
</ul>
<p><a class="user active" href="https://osmocom.org/users/30187">pespin</a> had implemented something like this for open5gs-upf in<br /><pre>commit fb8ebcdbeae0648e30d04fd016a956642131dddd
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date: Fri Apr 8 16:10:42 2022 +0200
[UPF] Add initial support for URR Usage Report (#1476)
</pre><br />and following commits.</p>
<p>Now sadly, open5gs-upf is more like a lab-grade upf and nothing that scales at all, and we hence have users of osmo-upf that use it for its fast kernel path.</p>
<p>The primary goal for this feature is the <em>tunnel mapping</em> case in a osmo-hnbgw co-located osmo-upf. The packet and byte counters hence will have to be added to the nftables rules.</p> OCTOI - Osmocom Community TDM over IP - Bug #5693 (Stalled): no progress tones in yatehttps://osmocom.org/issues/56932022-09-30T13:04:16Zlaforge
<p>We've never had call progress tones from yate in our network and had ignored that until now.</p>
This is the case in
<ul>
<li>any outbound call setup from a phone, where there are no dial tones, alerting tones, etc.</li>
<li>calls routed to tone/*</li>
</ul>
<p>The respective ToneSource() class instances are created and provide the respective quantity of samples. It works for SIP, but not for ISDN.</p>
<p>I think it's related to the Q.931 signaling side. It states:</p>
<blockquote>
<p><strong>5.4 In-band tones and announcements</strong></p>
<p>When in-band tones/announcements not associated with a call state change are to be provided by the network before reaching the Active state, a PROGRESS message is returned simultaneously with the application of the in-band tone/announcement. The PROGRESS message contains the progress indicator No. 8, in-band information or appropriate pattern is now available.</p>
<p>When tones/announcements have to be provided together with a call state change, then the appropriate message [e.g. for ALERTING, DISCONNECT, etc., (see clause 3)] with progress indicator No. 8, in-band information or appropriate pattern is now available, is sent simultaneously with the application of the in-band tone/announcement.</p>
</blockquote> OCTOI - Osmocom Community TDM over IP - Feature #5434 (Stalled): more statistics / countershttps://osmocom.org/issues/54342022-01-30T11:09:45Zlaforge
<p>For some more long-term testing or later operation, we need good statistics, such as</p>
<ul>
<li>re-ordered or missing IP packets</li>
<li>Rx/Tx byte/packet count</li>
<li>RTT</li>
<li>frame underflows in IP -> E1 direction</li>
</ul>
<p>Those stats could be interrogated via VTY, but ideally also exposed via our libosmocore statsd exporter.</p> osmo-ccid-firmware - Bug #4822 (Stalled): sysmoOCTSIM with osmo-ccid-firmware sometimes fails to ...https://osmocom.org/issues/48222020-10-20T19:48:41Zlaforge
<p>I've never had this before, for many months. However, with recent firmware (0.2.48) I've observed this:<br /><pre>
[179007.559048] usb 1-4.4.3: new full-speed USB device number 32 using xhci_hcd
[179007.639242] usb 1-4.4.3: device descriptor read/64, error -32
[179007.827237] usb 1-4.4.3: device descriptor read/64, error -32
[179008.015187] usb 1-4.4.3: new full-speed USB device number 33 using xhci_hcd
[179008.095235] usb 1-4.4.3: device descriptor read/64, error -32
[179008.283233] usb 1-4.4.3: device descriptor read/64, error -32
[179008.391179] usb 1-4.4-port3: attempt power cycle
[179008.995200] usb 1-4.4.3: new full-speed USB device number 34 using xhci_hcd
[179008.995416] usb 1-4.4.3: Device not responding to setup address.
[179009.203351] usb 1-4.4.3: Device not responding to setup address.
[179009.411047] usb 1-4.4.3: device not accepting address 34, error -71
[179009.491114] usb 1-4.4.3: new full-speed USB device number 35 using xhci_hcd
[179009.491311] usb 1-4.4.3: Device not responding to setup address.
[179009.699411] usb 1-4.4.3: Device not responding to setup address.
[179009.907037] usb 1-4.4.3: device not accepting address 35, error -71
[179009.907219] usb 1-4.4-port3: unable to enumerate USB device
[179039.515037] usb 1-4.4.3: new full-speed USB device number 36 using xhci_hcd
[179039.595097] usb 1-4.4.3: device descriptor read/64, error -32
[179039.782880] usb 1-4.4.3: device descriptor read/64, error -32
[179039.971039] usb 1-4.4.3: new full-speed USB device number 37 using xhci_hcd
[179040.051067] usb 1-4.4.3: device descriptor read/64, error -32
[179040.239072] usb 1-4.4.3: device descriptor read/64, error -32
[179040.347191] usb 1-4.4-port3: attempt power cycle
[179040.954828] usb 1-4.4.3: new full-speed USB device number 38 using xhci_hcd
[179040.954974] usb 1-4.4.3: Device not responding to setup address.
[179041.167074] usb 1-4.4.3: Device not responding to setup address.
[179041.374849] usb 1-4.4.3: device not accepting address 38, error -71
[179041.454915] usb 1-4.4.3: new full-speed USB device number 39 using xhci_hcd
[179041.455125] usb 1-4.4.3: Device not responding to setup address.
[179041.667065] usb 1-4.4.3: Device not responding to setup address.
[179041.879032] usb 1-4.4.3: device not accepting address 39, error -71
[179041.879256] usb 1-4.4-port3: unable to enumerate USB device
</pre></p>
<p>twice in a row while attaching the same sysmoOCTSIM using the same cable attached to the same USB hub, ... that has litrally worked hundreds of times before.</p>
<p>As sysmocom also received a similar report on raspi a few days ago, there may be something wrong.</p>
<p>I removed one SIM card and re-plugged it, and it worked. Unforunately it currently also works with that SIM card re-inserted. Weird.</p> OsmoPCU - Bug #4452 (Stalled): manual testing of osmo-pcuhttps://osmocom.org/issues/44522020-03-10T15:46:02Zroh
<p>these are manual testruns with osmo-pcu and osmo-bts-sysmo from -nightly and the cni running on debian on an apu.</p>
<p>attached are the configs for the sysmobts (osmo-pcu and osmo-bts-sysmo) as well as the remaining cni (on debian9 from -nightly)</p>
<p>the pcap files are generated by dumping the complete interface on the bsc. in addition to that the gsmtap for -bts and -pcu sends its debug there.<br />the pcap file(s) are single runs: getting the phone from airplane mode - register - do a network request - airplane mode.</p> IMSI Pseudonymization - Feature #4404 (Stalled): Research: Make sure that we can silently detach ...https://osmocom.org/issues/44042020-02-19T10:34:18Zosmith
<p>laforge wrote:</p>
<blockquote>
<p>neels wrote:</p>
<blockquote>
<p>The usefulness of the project seems to pivot on the visibility of the IMSI Detach.<br />If we can't omit the IMSI Detach message, then we either introduce an interruption in network service,<br />or we make it easy to correlate old and new IMSIs by time correlation of Detach and Attach.</p>
</blockquote>
<p>I doublt IMSI DETACH is used much in real-world networks these days as it is unauthenticated<br />and hence subject to spoofing.</p>
</blockquote>
<p>Here's a checklist to prove whether this works or not.</p> OsmoTRX - Feature #4362 (Stalled): osmo-trx-lms: Support multi-arfcn featurehttps://osmocom.org/issues/43622020-01-13T17:04:18Zpespin
<p>According to [1], we cannot use the two channels of LimeSDR devices on different frequencies. However, we may still be able to serve several TRX using multi-arfcn feature in osmo-trx, by muxing them into the same physical channel.</p>
<p>[1] <a class="external" href="https://github.com/myriadrf/LimeSuite/issues/276">https://github.com/myriadrf/LimeSuite/issues/276</a></p> Distributed GSM - Feature #4306 (Stalled): GSUP proxy cache: store data persistentlyhttps://osmocom.org/issues/43062019-12-04T13:58:28Zneelsnhofmeyr@sysmocom.de
<p>when we store auth tuples (<a class="issue tracker-2 status-7 priority-1 priority-lowest" title="Feature: GSUP proxy: cache auth tuples to re-use / fall back to simpler auth methods (Stalled)" href="https://osmocom.org/issues/4305">#4305</a>), even a local power outage should retain those tuples in the proxy.</p>
<p>options:<br />- store in the HLR DB<br />- just dump to a local .csv file to recover on startup</p> Distributed GSM - Feature #4305 (Stalled): GSUP proxy: cache auth tuples to re-use / fall back to...https://osmocom.org/issues/43052019-12-04T13:56:41Zneelsnhofmeyr@sysmocom.de
<p>if a link goes away, we'd like to still allow continued operation for some time.</p>
<p>Goals:</p>
<p>- we don't want to replicate the auth keys themselves; just ask for tuples from the home HLR.<br />- for a later attach, assume the link to home hlr is broken.<br />- we have cached the previous auth tuples and attempt to re-use them.<br />- Maybe we have asked for N more tuples on auth tuple request.<br />- milenage sqn: use a separate SQN IND bucket for each site, so going back to a previous site will be fine with SQN number jumps.<br />- if that doesn't work, fall back to 2G auth if possible.<br />- if that doesn't work, fall back to no auth (for some time/during link failure, for continued service)</p> OsmoGSMTester - Bug #4151 (Stalled): osmo-gsm-tester: osmo-trx-lms process sometimes kept forever...https://osmocom.org/issues/41512019-08-14T09:56:49Zpespin
<p>It was spotted several times that all osmo-trx-lms tests in osmo-gsm-tester fail with message:<br /><pre>
socket.c:367 unable to bind socket:10.42.42.117:4237: Address already in use
</pre></p>
<p>Close lookup shows osmo-trx-lms stil running but idle (not consuming CPU):<br /><pre>
# ps -ef | grep osmo-trx-lms
root 14643 14604 0 11:47 pts/1 00:00:00 grep osmo-trx-lms
jenkins 55210 1 0 Aug06 ? 00:00:53 /osmo-gsm-tester-trx/last_run/osmo-trx/bin/osmo-trx-lms -C /osmo-gsm-tester-trx/last_run/osmo-trx.cfg
</pre></p>
<p>In order to get process creation time (too see which test caused the issue and if logs around it provide more information):<br /><pre>
# ls -ld --time-style=full-iso /proc/$(pidof osmo-trx-lms)
dr-xr-xr-x 9 jenkins jenkins 0 2019-08-06 10:37:14.274166715 +0200 /proc/55210
</pre></p>
<p>At that time, following run was in place:<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run-prod/1926/">https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run-prod/1926/</a></p>
<p>And the test: <code>trial-1926 gprs:trx-lms+mod-bts0-numtrx2+mod-bts0-chanallocdescend cs_paging_gprs_active.py</code></p>
<p>The test runs and at some fails (expected since multi-trx is not yet supported in osmo-trx-lms) and then osmo-gsm-tester goes over regular procedure to kill all processes (in the case of osmo-trx-lms, it kills the ssh client, which should end up killing its child through the script handler):<br /><pre>
10:38:00.558825 --- ParallelTerminationStrategy: DBG: Scheduled to terminate 22 processes. [process.py:108]
10:38:00.560001 --- ParallelTerminationStrategy: DBG: Starting to kill with SIGTERM [process.py:116]
...
10:38:00.669914 run osmo-trx-lms(pid=1883): Terminating (SIGTERM) [trial-1926↪gprs:trx-lms+mod-bts0-numtrx2+mod-bts0-chanallocdescend↪osmo-bts-trx↪osmo-trx-lms↪osmo-trx-lms(pid=1883)] [process.py:236]
...
10:38:00.773158 --- ParallelTerminationStrategy: PID 1883 died... [process.py:75]
10:38:00.773706 run osmo-trx-lms(pid=1883): DBG: Cleanup [trial-1926↪gprs:trx-lms+mod-bts0-numtrx2+mod-bts0-chanallocdescend↪osmo-bts-trx↪osmo-trx-lms↪osmo-trx-lms(pid=1883)] [process.py:265]
10:38:00.776101 run osmo-trx-lms(pid=1883): Terminated {rc=36608} [trial-1926↪gprs:trx-lms+mod-bts0-numtrx2+mod-bts0-chanallocdescend↪osmo-bts-trx↪osmo-trx-lms↪osmo-trx-lms(pid=1883)] [process.py:270]
</pre></p>
<p>So my guess is not that ssh killing its child process is not working, but rather than when running with multi-trx we may end up in some race condition which somehow blocks osmo-trx-lms and prevents it from exiting.</p> OsmoBTS - Bug #4023 (Stalled): Missing coverage of PCU interface in osmo-btshttps://osmocom.org/issues/40232019-05-24T20:19:52Zlaforge
<p>let's use this as a separate ticket from <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Extension of BTS_Tests.ttcn test coverage (Resolved)" href="https://osmocom.org/issues/3750">#3750</a> to provide a more verbose list of the tests related to the PCU interface</p> OsmoBTS - Support #3863 (Stalled): setup testing of osmo-bts-oc2g on real hardware with ttcn3 and...https://osmocom.org/issues/38632019-03-26T16:21:06Zdexter
<p>In order to be able to debug problems with automatic interop testing a local instance of an osmocom-bb phone and BTS is required. TRXCONT/FAKETRX are exchanged with a real BTS/PHONE.</p> OsmoBSC - Bug #3806 (Stalled): OsmoBSC accepts BSSAP with wrong length fieldhttps://osmocom.org/issues/38062019-02-18T13:17:55Zlaforge
<p>As seen in <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: OsmoMSC sends invalid BSSMAP length field on CSFB CLEAR COMMAND (Resolved)" href="https://osmocom.org/issues/3805">#3805</a>, OsmoBSC would happily accept BSSMAP CLEAR COMMAND messages with IEs that extend beyond the length field of the BSSAP header.</p>
<p>This is definitely wrong. We should</p>
<ul>
<li>parse the length field</li>
<li>ensure we have a minimum of that number of bytes of payload as specified by the length field</li>
<li>truncate the msgb to a payload length as specified</li>
</ul>
<p>This way any additional garbage at the end of a message would simply be ignored, with us only parsing the specified "length" number of bytes.</p>
<p>Let's also make sure to add TTCN-3 tests for this, intentionally sending length field values too large and too short.</p>
<p>Once implemented in OsmoBSC, we should also implement it on the MSC side.</p> OsmoTRX - Bug #3775 (Stalled): properly debug limesdr usb and limesdr mini clocking requirements ...https://osmocom.org/issues/37752019-01-31T16:45:21Zroh
<p>limesdr usb and limesdr mini need a external reference clock to be used for gsm applications properly since the internal oscillator is sadly not of the required performance class.</p>
<p>limesdr usb has an extra internal pll (ADF4002 and Si5351C as well as LMK00105) and can handle different external clocks quite flexible<br />limesdr mini has no pll chip, but only a clock buffer (LMK00105) and needed some help from the fpga to make clocks possible which are not 40MHz</p> OsmocomBB SDR PHY - Bug #3459 (Stalled): apps/grgsm_trx: AssertionError: packe t_info.packet_coun...https://osmocom.org/issues/34592018-08-09T19:10:03Zfixeria
<p>Despite actual burst transmission works, I see the following messages repeated multiple times:</p>
<pre>
[i] Recv POWEROFF cmd
[i] Stopping transceiver...
[i] Setting TA value 0
[i] Recv ECHO cmd
[i] Recv SETSLOT cmd
[i] Configure timeslot filter to: drop all
[i] Recv MEASURE cmd
[i] Recv POWEROFF cmd
[i] Recv ECHO cmd
[i] Recv SETSLOT cmd
[i] Configure timeslot filter to: TS 0
[i] Recv POWERON CMD
[i] Starting transceiver...
thread[thread-per-block[15]: <block gr uhd usrp sink (8)>]: EnvironmentError: IOError: Radio ctrl (0) packet parse error - AssertionError: packe
t_info.packet_count == (seq_to_ack & 0xfff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at /build/libuhd/src/uhd-3.11.1.0/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:254
</pre>
<p>Observed within a Docker image wit the recent software:</p>
<ul>
<li>UHD_3.11.1.0-0-unknown</li>
<li>GNU Radio 3.7.11-6</li>
<li>GR-GSM TRX from fixeria/trx</li>
</ul>
<p>Could you please have a look?<br />Do you see this too?</p> OsmocomBB SDR PHY - Bug #3458 (Stalled): apps/grgsm_trx: [ERROR] [STREAMER] recv packet demuxer u...https://osmocom.org/issues/34582018-08-09T18:29:31Zfixeria
<p>Sometimes, while running the following output appears:</p>
<pre>
[i] Recv ECHO cmd
[i] Recv POWEROFF cmd
[i] Recv ECHO cmd
[i] Recv SETSLOT cmd
[i] Configure timeslot filter to: TS 0
[i] Recv RXTUNE cmd
[i] Recv TXTUNE cmd
[i] Recv POWERON CMD
[i] Starting transceiver...
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x4a000f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xe0024
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x37ffe7
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1b0005
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff530020
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xcff6d
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x7ffc8
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffbeff95
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x65000f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffb20072
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x16ffc9
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff5fff1
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffc400bb
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xcffdd
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffdcffcb
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffb2fff5
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffd5ffc4
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x38fff2
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffcf0000
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xbb0069
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x12ffcc
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffb6001f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffd7001e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x14004c
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffa6ffe8
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xa002a
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff76003f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff96ffd3
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x130013
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffd5ffe3
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x4001e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff8c0075
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff0000f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xdffee
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff40011
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1afff9
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff9aff5d
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff9afffa
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x7ffce
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffcb0008
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff7ffdd
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x5a005e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x38ffca
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x6ffa2
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x4ffcc
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffba00ab
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff420029
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1effe2
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x70067
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1a001e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1a0016
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xb00a5
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffbe0008
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffe6001a
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffcfffc3
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x130003
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffceff44
</pre> OsmocomBB SDR PHY - Bug #3425 (Stalled): Receiver: missing AGC (Automatic Gain Control)https://osmocom.org/issues/34252018-07-26T20:25:52Zfixeria
<p>When the signal becomes too strong, we need to decrease the gain to avoid saturation.<br />When the signal becomes less powerful, we need to increase the gain...</p> OsmocomBB SDR PHY - Feature #3424 (Stalled): Transceiver: implement automatic TX delay measurementhttps://osmocom.org/issues/34242018-07-26T20:22:05Zfixeria
<p>As we all know, the world is not perfect, and there is some delay on the TX path of SDR devices.<br />At the moment, we know that for USRP B2X0 this delay is constant, so we take it into account.</p>
<p>But since we are going to extend the hardware compatibility, it makes sense to implement<br />some automatic measurement of delay for a particular device.</p> OsmocomBB SDR PHY - Feature #3423 (Stalled): Receiver: hard-coded GSM 05.02 channel configurationhttps://osmocom.org/issues/34232018-07-26T20:15:46Zfixeria
<p>Unlike <a class="wiki-page" href="https://osmocom.org/projects/osmotrx/wiki">OsmoTRX</a>, it's impossible to configure the desired channel configuration.<br />Please see GSM 05.02, section 6.4 "Permitted channel combinations".</p>
<p>In order to reduce the recourse consumption, it makes sense to implement some API,<br />which would allow both initial and dynamic timeslot configuration...</p> OsmocomBB SDR PHY - Bug #3422 (Stalled): Receiver: sample / burst buffering problemhttps://osmocom.org/issues/34222018-07-26T20:08:47Zfixeria
<p>The problem appears when one stops the flow-graph, changes some parameters (e.g. freq.) and starts it again.<br />As soon as the flow-graph is started, Receiver block will still output some bursts from the past for some time.</p>
<p>Please note that <strong>I just assume</strong> that this is a problem of Receiver block.<br />It might be also a problem of any other block(s), such as 'TRX Interface'.</p> OsmoTRX - Bug #3341 (Stalled): osmo-trx-lms RF Envelope FAIL on LimeSDR, but not on LimeSDR-minihttps://osmocom.org/issues/33412018-06-13T13:46:18Zlaforge
<p>I'm observing a strange behavior when comparing the RF envelope of osmo-trx-lms on a LimeSDR and a LimeSDR-mini.</p>
<p>The LimeSDR-mini envelope is within spec. Specifically, the transmit power level is at full strength before the start of the next burst.</p>
<p><img src="https://osmocom.org/attachments/download/3215/SCREEN1.BMP" title="RF envelope on LimeSDR-mini" alt="RF envelope on LimeSDR-mini" /> <img src="https://osmocom.org/attachments/download/3216/SCREEN2.BMP" title="RF envelope on LimeSDR-mini (zoom)" alt="RF envelope on LimeSDR-mini (zoom)" /></p>
<p>On the LimeSDR however, the next burst/timeslot starts too late, (or the slew rate is too low?):</p>
<p><img src="https://osmocom.org/attachments/download/3217/SCREEN3.BMP" title="RF envelope on LimeSDR" alt="RF envelope on LimeSDR" /> <img src="https://osmocom.org/attachments/download/3218/SCREEN4.BMP" title="RF envelope on LimeSDR (zoom)" alt="RF envelope on LimeSDR (zoom)" /></p>
<p>This is using the exact same versions of LimeSuite (f1e5444496923890ad7d030abef9c224c37c46cf) and osmo-trx (70621b74844a6ea08d6da5f5b1e1835b9af91771). All I'm doing is swapping the hardware and re-starting osmo-trx-lms and osmo-bts.</p>
<p>It's very odd, and I currently have no clue of what might be going on here.</p> OsmoSGSN - Bug #2958 (Stalled): OsmoSGSN doesn't authenticate on second/further ATTACH REQUESThttps://osmocom.org/issues/29582018-02-17T17:29:12Zlaforge
<p>When a new/unknown MS performs an ATTACH REQUEST for the first time, it is authenticated.</p>
<p>However, if that same MS later performs a second ATTACH REQUEST, even with new P-TMSI/TLLI, it is not authenticated and we simply send an ATTACH ACCEPT. This is a security problem, as it means anyone can impersonate other known-existing IMSIs.</p> OsmoBSC - Feature #2893 (Stalled): automatic simulator for large LU load https://osmocom.org/issues/28932018-01-27T16:43:22Zlaforge
<p>Every so often we see systems suffering a lot from large LU load.</p>
<p>There are many tunables like each tx delay/integer, access control class ramping, ms-acces-lv-min ramping, doewnlink poweer ramping, im ass reejct timer, etc</p>
<p>In order to be able to test different configurations and possible patches, we need a reproducible test scenario for benchmarking our performance.</p>
Ideally this shoiuld be possible with osmocombb and virtphy. For just performing a LU, we don't even need scripting. However, we need
<ul>
<li>starting large number of "mobile" </li>
<li>realistic timing for network scan / cell search (virtphy is too fast)</li>
<li>implementation of downlink attenuation</li>
<li>detection of RACH collisions in bts-virtual</li>
</ul> OsmoBSC - Support #2622 (Stalled): Prepare automatic interop testing of OmsoBSC against NG40 core...https://osmocom.org/issues/26222017-11-07T21:46:30Zlaforge
<p>Please create a setup where the signaling tests (LU, MO-SMS, MT-SMS, USSD) can be done with osmocombb-mobile + virt_phy + osmo-bts-virtual + osmo-bsc against NG40.</p>
<p>This is in preparation of automatizing this task as soon as we have a scripting interface towards OsmocomBB "mobile"</p>
<p>Building all components should be automatic / scripted. It might be an idea to do this via Dockerfiles. Execution of the tests + checking results is not automatic yet, as this is pending the OsmocomBB "mobile" script interface.</p>
The goal is basically to have a single command/script to
<ul>
<li>build/install osmo-bsc, osmo-bts-virtual, virt-phy + mobile</li>
<li>might make sense to have
<ul>
<li>one docker image for osmo-bsc</li>
<li>one docker image for osmo-bts-virtual + virt_phy</li>
</ul></li>
</ul>
and then have another scripted way to
<ul>
<li>start N instances of each of them (except "mobile"), where the number of BSCs is different from the number of BTSs and again different from the number of virt-phy instances</li>
</ul> Cellular Network Infrastructure - Feature #2558 (Stalled): Scripts to manage thousands of "mobile...https://osmocom.org/issues/25582017-10-06T14:53:38Zlaforge
<p>The goal here is to be able to run a network with hundreds of BTSs, several hundreds of TRXs and thousands of MSs from a single command, in order to perform load testing against OsmoBSC.</p>
<p>The scripts should make sure all related processes are started reliably, their termination is recorded, and somehow their result / error / logging is aggregated and reported.</p> OsmoPCU - Feature #1823 (Stalled): Ericsson PCU TRAU frame encoding/decodinghttps://osmocom.org/issues/18232016-10-15T15:42:23Zlaforge
<p>It is not yet clear if this code will be part of OsmoPCU internally, or if it is better kept in an external process.</p>
The general idea is as follows:
<ul>
<li>open the E1 time-slots used for PCU TRAU frames
<ul>
<li>try to use only full 64k slots. If 16k sub-slots required, the subchan_mux code of libosmo-abis should be reused.</li>
</ul>
</li>
<li>synchonize on the PCU-TRAU frames (frame_sync.c which I already wrote but never tested)</li>
<li>receive + decode the TRAU frames. We need at least
<ul>
<li>PCU_TRAU_ER_FT_CCU_SYNC_IND</li>
<li>PCU_TRAU_ER_FT_DATA_IND for CS1, CS2, CS3, CS4</li>
</ul>
</li>
<li>encode + transmit the TRAU frames. We need at least
<ul>
<li>PCU_TRAU_ER_FT_PCU_SYNC_IND</li>
<li>PCU_TRAU_ER_FT_DATA_IND for CS1, CS2, CS3, CS4</li>
</ul></li>
</ul>
<p>The SYNC procedure is the starting point. The *-SYNC-IND messages are always sent in case the link is idle and nothing else is to be sent.</p>
<p>See <a class="wiki-page" href="https://osmocom.org/projects/openbsc/wiki/Ericsson_RBS2000_GPRS">Ericsson_RBS2000_GPRS</a> for more information.</p> OsmoSGSN - Bug #1768 (Stalled): VTY show llc displays State TLLI Unassigned permanentlyhttps://osmocom.org/issues/17682016-07-07T11:48:18Zdexter
<p>Expecting at least some assigned TLLI states in in SAPI list on globally Assigned TLLI state.</p>
<pre>
TLLI e625e4fb (Old TLLI ffffffff) BVCI=2 NSEI=101 Age=0: State TLLI Assigned
SAPI 1 State TLLI Unassigned (1) VUsend=4, VUrecv=5 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=400, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 2 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 3 State TLLI Unassigned (1) VUsend=91, VUrecv=64 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=500, N201-I=1503, mD=1520, mU=1520, kD=16, kU=16
SAPI 5 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=10, N200=3, N201-U=500, N201-I=1503, mD=760, mU=760, kD=8, kU=8
SAPI 7 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 8 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 9 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=500, N201-I=1503, mD=380, mU=380, kD=4, kU=4
SAPI 11 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=40, N200=3, N201-U=500, N201-I=1503, mD=190, mU=190, kD=2, kU=2
</pre>
<p>Already checked if the get_value_string(gprs_llc_state_strs, lle->state) returns the right string. Seems to work, numerical state is always 1 as well.</p> OsmoPCU - Bug #1759 (Stalled): Wrong calculation of DL window size for DL assignmenthttps://osmocom.org/issues/17592016-06-28T10:27:21Zarvind.sirsikar
<p>Hi,</p>
<p>When we create DOWNLINK TBF without existing UPLINK TBF i.e DL assignment on PCH case, The calculation of window size is found to be incorrect.</p>
<p>Description:<br /> 4 time slots is configured for DL and osmo-pcu.cfg is configured as window-size 64 104.</p>
<pre><code>When we try to do IPERF in DL direction, PCU allocates window-size as 160 but configures 4 time slots<br /> as seen by PCU VTY. Below is the result of VTY output.</code></pre>
<pre><code>DL TBFs<br /> TBF: TFI=0 TLLI=0xf73d2ece (valid) DIR=DL IMSI=901555000001280<br /> created=1095 state=0000000a 1st_TS=4 1st_cTS=6 ctrl_TS=6 MS_CLASS=0/1<br /> TS_alloc=4 5 6! 7 CS=MCS-9 WS=160 V(A)=12 V(S)=12 nBSN=138</code></pre>
<pre><code>But we see proper calculation of window-size when DL assignement is done on PACCH. as seen by VTY interface below</code></pre>
<pre><code>DL TBFs<br /> TBF: TFI=0 TLLI=0xf73d2ece (valid) DIR=DL IMSI=901555000001280<br /> created=1095 state=0000000a 1st_TS=4 1st_cTS=6 ctrl_TS=6 MS_CLASS=0/1<br /> TS_alloc=4 5 6! 7 CS=MCS-9 WS=480 V(A)=138 V(S)=139 nBSN=138</code></pre>
<p>Thanks,<br />Aravind Sirsikar</p> OsmoSGSN - Feature #1655 (Stalled): KPIs for OsmoSGSNhttps://osmocom.org/issues/16552016-03-11T09:53:30Zlaforge
<ul>
<li>overall GPRS DL and UL IP payload throughput (mbps) : waits for compression</li>
<li>overall GPRS DL and UL IP compression gain (%) : waits for compression</li>
<li>overall GPRS DL and UL LLC througput (mbps) : via global rate counters</li>
<li>GPRS Attach attempts (number) : gprs.attempts_request</li>
<li>GPRS Attach success rate (%) : gprs.attempts_accepted / gprs.attempts_request</li>
<li>PDP context attempts (number) : pdp.activate_requests</li>
<li>PDP context establish success rate (%) : pdp.activate_requests / pdp.activate_accept</li>
<li>PDP context cut-off (%) : ?</li>
</ul> OsmoBSC - Bug #1614 (Stalled): better identification of BTS model / capabilities to BSChttps://osmocom.org/issues/16142016-02-23T16:24:51Zlaforge
Right now, there is a lot of implied knowledge at the BSC level about the BTS, i.e.
<ul>
<li>the BSC needs to be told which BTS model it is</li>
<li>the BSC needs to be told the nominal transmit power of each TRX</li>
<li>the BSC needs to be told about the codec capabilities, etc.</li>
</ul>
<p>In order to reduce the currently seemingly endless possbilities how somebody can end up with a non-working<br />configuration, it would be good if the BTS would express its capabilities towards the BSC. As there is<br />no standard in the Abis specs for this, we have to come up with a mechanism of our own.</p>
<p>It might be a vendor-specific OML request from BSC to BTS, which we could use to determine from BSC side if the BTS supports this request at all (if not, proceed as usual). This would also ensure backwards compatibility with nanoBTS or older OsmoBTS versions.</p>