Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092019-07-26T13:04:49ZOpen Source Mobile Communications
Redmine Cellular Network Infrastructure - Bug #4131 (Stalled): osmo-gsm-manuals: Use leveloffset attribut...https://osmocom.org/issues/41312019-07-26T13:04:49Zpespin
<p>Right now, all documents under osmo-gsm-manuals.git/commons/ start with title level 1 (==). However, if one wishes to add a document with level 2 (===) so it can also be included in other repository document, it will make osmo-gsm-manuals.git "make check" fail due to osmo-gsm-manuals/tests/Makefile.am:22:<br /><pre>
echo "include::$${chapter}[]" >> $@; \
</pre></p>
<p>Which includes stuff under a test document with level 0 (=). If a document with level different than 1 (==) is added, then it will fail on some versions (like jenkins):<br /><pre>
"asciidoc: WARNING: mgcp_extension_osmux.adoc: line 2: section title out of sequence: expected level 1, got level 2"
</pre></p>
<p>See for instance commit osmo-gsm-manuals.git 061cca4d7345bc4f496324d0b4d30bc51e1f8d23, which had to be fixed up later.</p>
<p>The solution here is to use "leveloffset" attribute. To make our life easier in the future, we need to move all documents under common/ to start with level 0 (=), and then use "leveloffset" on all includes in all other repositories using them. This way same document can easily be added on different levels on different documents.</p>
<p>Important! It seems this syntax doesn't work for me:<br /><pre>
include::chapter2.adoc[leveloffset=+1]
</pre></p>
<p>However, this does and it's basically the same:<br /><pre>
:leveloffset: 1
include::chapter1.adoc[]
:leveloffset: 0
</pre></p>
<p>Related information:<br /><a class="external" href="https://github.com/asciidoctor/asciidoctor.org/blob/master/docs/_includes/include-directive.adoc">https://github.com/asciidoctor/asciidoctor.org/blob/master/docs/_includes/include-directive.adoc</a><br /><a class="external" href="https://mrhaki.blogspot.com/2016/09/awesome-asciidoctor-change-level-offset.html">https://mrhaki.blogspot.com/2016/09/awesome-asciidoctor-change-level-offset.html</a><br /><a class="external" href="http://asciidoc.org/userguide.txt">http://asciidoc.org/userguide.txt</a></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> libosmo-netif - Bug #3812 (Stalled): stream_test fails depending on where it is runhttps://osmocom.org/issues/38122019-02-21T15:18:52Zneelsnhofmeyr@sysmocom.de
<p><a class="user active" href="https://osmocom.org/users/119">msuraev</a>, your new stream_test fails for me.<br />On my home laptop sporadically, on my office box reliably.</p>
<pre>
1: stream_test FAILED (testsuite.at:8)
▶ cat tests/testsuite.dir/1/testsuite.log
# -*- compilation -*-
1. testsuite.at:4: testing stream_test ...
../../../src/libosmo-netif/tests/testsuite.at:8: $abs_top_builddir/tests/stream/stream_test
--- experr 2019-02-21 16:12:24.956776809 +0100
+++ /n/s/dev/make/libosmo-netif/tests/testsuite.dir/at-groups/1/stderr 2019-02-21 16:12:33.984665754 +0100
@@ -12,8 +12,7 @@
autoreconnecting test step 6 [client OK, server OK], FD reg 1
autoreconnecting test step 5 [client OK, server OK], FD reg 1
-[ CONNECTED] osmo_stream_cli_recv(): connection closed with srv
-[ NONE] osmo_stream_cli_reconnect(): retrying in 9 seconds...
+connection closed with srv
autoreconnecting test step 4 [client OK, server OK], FD reg 0
@@ -37,7 +36,6 @@
non-reconnecting test step 2 [client OK, server OK], FD reg 1
non-reconnecting test step 1 [client OK, server OK], FD reg 1
-[ CONNECTED] osmo_stream_cli_recv(): connection closed with srv
-[ NONE] osmo_stream_cli_reconnect(): not reconnecting, disabled.
+connection closed with srv
-non-reconnecting test step 0 [client OK, server OK], FD reg 0
+non-reconnecting test step 0 [client OK, server OK], FD reg 1
1. testsuite.at:4: 1. stream_test (testsuite.at:4): FAILED (testsuite.at:8)
</pre> OsmoMSC - Bug #3735 (Stalled): call arriving during another call has no voicehttps://osmocom.org/issues/37352018-12-16T13:25:50Zneelsnhofmeyr@sysmocom.de
<p>during testing for 35c3 POC reports:</p>
<ul>
<li>be on a voice call.</li>
<li>second call comes in and knocks.</li>
<li>hang up the first call and answer the second call.</li>
</ul>
<p>Now the second call has no voice.</p> OsmoHLR - Bug #3717 (Stalled): SS/USSD: fix SS session inactivity timeouthttps://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> OsmoMSC - Feature #3620 (Stalled): Implement TTCN-3 testsuite for Inter-MSC HOhttps://osmocom.org/issues/36202018-10-02T18:23:34Zlaforge
<p>Implementation of TTCN-3 test cases as part of MSC_Tests.ttcn in osmo-ttcn3-hacks.git which emulate one external BSC and MSC to test basic and subsequent Inter-MSC hand-over of OsmoMSC.</p> OsmoBTS - Bug #3569 (Stalled): Some phones don't receive SMSCBhttps://osmocom.org/issues/35692018-09-19T09:23:20Zlaforge
<p>Reported so far to be affected of this:</p>
<ul>
<li>Samsung Galaxy Note 4</li>
<li>Huawei P10</li>
<li>Samsung Galaxy S9</li>
<li>iPhone 8</li>
<li>Huawei Honor 9</li>
</ul> OsmoBTS - Bug #3568 (Stalled): CBCH on SDCCH/8 not working for osmo-bts-sysmohttps://osmocom.org/issues/35682018-09-18T20:54:03Zlaforge
<p>During manual testing I observed that while sms arrived on my test phone when using CBCH on SDCCH/4, they were not arriving when using CBCH on SDCCH/8.</p>
<p>SI4 CBCH location was updated properly, so that was not the cause...</p> OsmoGSMTester - Bug #3560 (Stalled): nanoBTS multiTRX tests in osmo-gsm-tester Prod setup failinghttps://osmocom.org/issues/35602018-09-17T14:26:44Zlaforge
<p>A sysmocom customer has reported that operationg with two TRX used to work some weeks/months ago, but is failing with current master of osmo-trx/bts/bsc.</p>
<p>It's not clear in which component exactly the bug was introduced, but my guess would be probably the many BSC FSM related changes that were introduced.</p>
<p>This may also be related to the issue discovered in context with osmo-gsm-tester, where the 2nd TRX of a two-trx nanoBTS setup wasn't operating as expected</p> OsmoMSC - Feature #3445 (Stalled): SS/USSD: clean up the local GSM 04.80 APIhttps://osmocom.org/issues/34452018-08-03T09:43:56Zfixeria
<p>Since the SS/USSD related changes have been merged, OsmoMSC doen't process the<br />SS/USSD requests internally. This is why some part of the local GSM 04.80 API<br />has become useless. Would be great to clean it up, and keep only the most<br />important functions there...</p> OsmocomBB - Feature #3399 (Stalled): mobile: refactor / finish external MNCC handler implementationhttps://osmocom.org/issues/33992018-07-16T22:38:44Zfixeria
<p>In general, it is possible to connect <a class="wiki-page" href="https://osmocom.org/projects/baseband/wiki/Mobile">mobile</a> application to an external MNCC-handler, such as LCR and <a class="wiki-page" href="https://osmocom.org/projects/osmo-sip-conector/wiki">osmo-sip-conector</a>.<br />In case of the second one, <a class="wiki-page" href="https://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> OsmoMSC - Bug #3294 (Stalled): transaction: refactor callref allocationhttps://osmocom.org/issues/32942018-05-26T17:51:04Zfixeria
<p>Each transaction has a field called 'callref', that should contain an unique identifier. This identifier is being assigned either by OsmoMSC itself, either by an external application (e.g. LCR), and is used to distinguish between multiple allocated transactions.</p>
<p>In case of a new callref generation on the MSC side, there are the following sources for that:</p>
<pre>
$ git grep "static uint32_t new_callref"
src/libmsc/gsm_04_08.c:static uint32_t new_callref = 0x80000001;
src/libmsc/gsm_04_11.c:static uint32_t new_callref = 0x40000001;
src/libmsc/mncc_builtin.c:static uint32_t new_callref = 0x00000001;
</pre>
<p>So, we have a few ranges for different types of communication:</p>
<pre><code>- from 0x00000001 to 0x40000000 - Call Control, internal MNCC;<br /> - from 0x40000001 to 0x80000000 - SMS messages;<br /> - from 0x80000001 to 0xffffffff - Call Control, external MNCC;</code></pre>
<p>And this is how a new 'callref' value is generated:</p>
<pre>
new_callref++
</pre>
<p>I see the following problems:</p>
<p>1) Imagine that we have a network, which is running for some long time. What if the amount of calls ever made would reach 0x40000000? The next values will be 0x40000001, 0x40000002, 0x40000003, etc. At some point, this may result into collisions, e.g. two transactions with same 'callref' value.</p>
<p>Possible solution: instead of doing `new_callref++` manually, create a function (e.g. trans_gen_ref), which would prevent overlaps between ranges, and flush the source to initial value.</p>
<p>2) The trans_alloc(), which is used to allocate a new transactions, doesn't check if passed 'callref' value is not used. In other words, it is possible to allocate a few transactions with not unique 'callref'. In this case the trans_find_by_callref() would work incorrectly.</p>
<p>Possible solution: before allocation, check if given 'callref' is already used.</p>
<p>3) The 'callref' as a field name itself looks/sounds like something call related, while this feature will be also used as soon as we implement SMS and SS/USSD over GSUP. It would be better to rename it to something more generic, e.g. just 'ref'.</p>
<p>4) Both sides, i.e. MSC and an external application, are involved in 'callref' generation. There is no master-slave relation... This may result in a situation, when an external application asks to allocate a new transaction with 'callref', which is already used.</p>
<p>Possible solution: inspire by GSM TS 04.07, section 11.2.3 "Transaction identifier" and introduce the direction bit. Probably, this can be a bit simplified, e.g. '0' means allocated by the MSC itself, '1' - by an external application.</p> OsmoTRX - Bug #3222 (Stalled): include (tested) example config files for usrp1, uhd/b200 as well ...https://osmocom.org/issues/32222018-04-28T14:50:47Zlaforge
<p>Let's make sure we ship example configs for the various SDR hardware, just like we do in other osmocom projects that use vty / config files.</p> OsmoTRX - Feature #3054 (Stalled): Extended (11-bit) RACH support in OsmoTRXhttps://osmocom.org/issues/30542018-03-10T07:22:35Zlaforge
<p>OsmoTRX is currently only correlating with one of the three RACH sync sequences indicated in TS 05.02 5.2.7. We need to define TS1+TS2 as well as correlated against thosee during RACH detection</p>
<pre>
const BitVector GSM::gRACHSynchSequence("01001011011111111001100110101010001111000");
+const BitVector GSM::gRACHSynchSequenceTS1("01010100111110001000011000101111001001101"); /* EGPRS with 8PSK in uplink */
+const BitVector GSM::gRACHSynchSequenceTS2("11101111001001110101011000001101101110111"); /* EGPRS without 8PSK in uplink */
</pre> OsmoBTS - Bug #2979 (Stalled): osmo-bts-virtual reports bogus measurement valueshttps://osmocom.org/issues/29792018-02-21T23:25:35Zlaforge
<p>Despite the GSMTAP header containing RSSI information, we do not report those measurement values up to L1SAP.</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> OsmoMSC - Bug #2851 (Stalled): a_iface.c:534 Unhandled SIGTRAN primitive: 3:2https://osmocom.org/issues/28512018-01-21T19:52:32Zlaforge
<p>Every so often I'm seeing the following error message:<br /><pre>
<000a> a_iface.c:534 Unhandled SIGTRAN primitive: 3:2
</pre></p>
We should
<ul>
<li>investigate and resolve this</li>
<li>make sure we print string values rather than numeric ones.</li>
</ul> Z-Netz - Bug #2807 (Stalled): Obtain ZERBERUS software build[s] and manual[s]https://osmocom.org/issues/28072018-01-01T13:08:48Zlaforge
<p>I've sent mail to padeluun + rena about this.</p> 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> 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> OsmoGSMTester - Support #2497 (Stalled): Set up SIM cards with auth algo other than comp128v1https://osmocom.org/issues/24972017-09-06T15:16:58Zneelsnhofmeyr@sysmocom.de
<p>It appears all SIM cards currently in the osmo-gsm-tester rnd and prod setup are configured to use XOR auth.</p>
<p>(Edited)</p>
<p>We saw auth failing, but succeeding when setting the HLR to XOR.<br />XOR is currently not available, and the only reason that choosing XOR would lead to success is that the HLR does not provide any auth data and the MSC continues <strong>without</strong> authentication.</p>
<p>For authentication related test runs, we need to set 'network' / 'authentication required' in the osmo-msc.cfg,<br />and we should probably also set 'encryption a5 3' to see that the negotiated kc works for encryption.</p>
<p>We do not support XOR, and we should have more diverse auth algos in place.<br />Best would be one using Milenage (the 2G variant), one using comp128v1, one using comp128v3.</p>
<p>We then need to adjust the resources.conf and can set up different auth tests for the various algos.</p> OsmoGSMTester - Feature #2197 (Stalled): osmo-gsm-tester: use MNCC interfacehttps://osmocom.org/issues/21972017-04-26T15:29:52Zneelsnhofmeyr@sysmocom.de
<p>the MNCC interface present in the old osmo-gsm-tester code is not yet present in the new osmo-gsm-tester.<br />Add test API to interact with the NITB (future OsmoMSC) using MNCC.</p> OsmoPCU - Bug #1838 (Stalled): Nokia E52 doest reply to PUAN message properlyhttps://osmocom.org/issues/18382016-11-09T12:27:17Zarvind.sirsikar
<p>When we indicate MS that we have Nack in receiving window(in PUAN). Nokia E52 MS doesn’t honor that and keeps sending the new RLC blocks even when it crosses its transmit window in UL. causing the reception of RLC blocks outside RLC window.</p>
<p>below is PCU log snippet for one such example:</p>
<p>encoding.cpp:676 - EGPRS URBB, len = 11, SSN = 671, ESN_CRBB = 670, SNS = 2048, WS = 64, V(Q) = 670, V(R) = 682, BOW, EOW</p>
<p>message = 40 24 01 1f 3e 90 00 92 f0 8d 35 3e ff c3 2b 2b 2b 2b 2b 2b 2b 2b 2b</p>
<p>Below is the decoded message.</p>
<pre><code>EGPRS_AckNack<br /> 1... .... = ACKNACK: (Union)<br /> Desc<br /> .000 1101 0... .... = ACKNACK Dissector length: 26<br /> Desc<br /> .0.. .... = FINAL_ACK_INDICATION: False<br /> ..1. .... = BEGINNING_OF_WINDOW: 1<br /> ...1 .... = END_OF_WINDOW: 1<br /> .... 0101 0011 111. = STARTING_SEQUENCE_NUMBER: 671<br /> .... ...0 = CRBB Exist: 0<br /> 1111 1111 110. .... = URBB_BITMAP: 2046</code></pre>
<p>Other MS like LG F70 and Lenovo K4 note behaves properly for this kind of PUAN with nacked bits present in it.<br />further investigation needs to be done</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 #1794 (Stalled): support random IV for GEA (via XID)https://osmocom.org/issues/17942016-08-09T14:21:57Zmsuraev
<p>Current implementation of GPRS encryption uses hardcoded IV = 0 while according to spec it should be random. This random value is communicated to client as part of XID negotiation.</p> OsmoNITB - Bug #1725 (Stalled): iPhone6 network selection issue with GSM1900https://osmocom.org/issues/17252016-05-17T20:07:23Zzecke
<p>We have some form of issue with the iPhone 6S (we can use messenger to move it around). Now the iPhone is a really bad phone (manual network selection not re-scanning, selecting it not trying to access the network in a reasonable amount of time). But what I can re-produce:</p>
<ul>
<li>Put customer IMSI in the phone</li>
<li>Wait for the network to be selected</li>
<li>Enter airplane mode</li>
<li>Leave airplane mode</li>
</ul>
<p>Theory:</p>
<p>The LU should lead to the <abbr title="+band?">ARFCN</abbr> be written to the SIM card. This ARFCN should be tried <em>after</em> the airplane mode (or reboot) is used. But the phone ends up in "No Service". I make my tests with with a RevA hardware and maybe slightly incorrect calibration but other phones behave a lot better.</p>
<p>Reality:</p>
<p>What happens is that after the airplane mode.. the phone does <em>not</em> select a network (It goes to Searching and then prints No Network). Toggling "Automatic" to "Manual" network seaearch it sometimes starts to connect it (after many many minutes).</p>
<p>Stats:<br /><pre>
iPhone 6s
Version 9.3.2 (14F69)
Carrier 24.0
Model MKQK2ZD/A
Modem Firmware 1.60.00
</pre></p>
<p>For reference the SIs of another small network at 1900</p>
<pre>
SI1 5506198f0e0000000000000000000000000000bb00006b
SI2 59061a00000000000000000000000000000000ffbb0000
SI3 49061b9c4072f480101949030f07c346bb00008000832b
SI4 41061c72f4801019c346bb00006430021c80008b2b2b2b
SI13 <empty>
SI5 49061d10000000000000000000000000000000
SI6 2d061e9c4072f480101997ff3b2b2b2b2b2b2b
</pre> OsmoNITB - Bug #1671 (Stalled): Combined 850/1800 NITB not seen by Option Icon2 stickhttps://osmocom.org/issues/16712016-03-24T06:53:41Zzecke
<p>When having a NITB with one GSM1800 BTS on ARFCN 877 and one on GSM850 on ARFCN 130 (that is not broadcasting), the Icon2 stick failed to join the network. When removing this cell (and hence the neighborcell information) it works immediately. The test was done with a nanoBTS.</p>
<p>Tests:</p>
<ul>
<li>Make this stable, I had issued another AT+CFUN=0/CFUN=1 today morning and while I did this yesterday it is not a clear call</li>
<li>Test with sysmoBTS and the nanoBTS (e.g. maybe some SIs are not scheduled)</li>
<li>Look if all generated SIs are being sent</li>
<li>Look at the spec if such config is legal..</li>
<li>Look at the generated SIs</li>
</ul>
<p>BTS 1 config<br /><pre>
bts 1
type sysmobts
band GSM850
cell_identity 0
location_area_code 1
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
periodic location update 30
radio-link-timeout 32
channel allocator ascending
rach tx integer 9
rach max transmission 7
channel-descrption attach 1
channel-descrption bs-pa-mfrms 5
channel-descrption bs-ag-blks-res 1
ip.access unit_id 1802 0
oml ip.access stream_id 255 line 0
neighbor-list mode automatic
codec-support fr
gprs mode none
no force-combined-si
trx 0
rf_locked 0
arfcn 130
nominal power 23
max_power_red 22
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config SDCCH8
hopping enabled 0
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
timeslot 4
phys_chan_config TCH/F
hopping enabled 0
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
</pre></p> OsmocomBB - Support #1627 (Stalled): DCS_8BIT and DCS_UCS2 encoding supprothttps://osmocom.org/issues/16272016-02-29T03:46:52Zfixeria
<p>Currently it is impossible to send/receive SMS messages and USSD encoded in 8-bit or 16-bit alphabet.</p> OsmoMSC - Feature #1597 (Stalled): External interface for USSDhttps://osmocom.org/issues/15972016-02-23T15:52:03Zlaforge
<p>we already have SMPP for SMS, but don't have similar functionality for USSD, i.e. a way in which external applications can exchange USSD with MSs.</p>
<p>There are some provisions for USSD in SMPP, but I think they don't really appreciate the session-oriented nature of USSD.</p>
<p>In either case, I'm not aware of any standard to hand USSD to external applications. Of course there's MAP, but nobody wants to implement that in an external application...</p> OsmoSGSN - Feature #1587 (Stalled): SMS over GPRS supporthttps://osmocom.org/issues/15872016-02-23T15:46:03Zlaforge
<p>Currently, the SGSN doesn't support the transmission of SMS via the packet-switched plane. However, this is much more efficient in terms of air interface resource usage than to do this over circuit-switched GSM/SDCCH.</p>