Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-12-07T14:48:04ZOpen Source Mobile Communications
Redmine OsmoSGSN - Feature #6294 (New): Support GN/Gp interoperation procedures between SGSN and MMEhttps://osmocom.org/issues/62942023-12-07T14:48:04Zdaniel
<p>In an Inter-RAT setup a UE could perform a RAU coming from a 4G network. In that case the UE/MS is unknown to the SGSN and it should request the SGSN context from the MME.<br />Similarly the MME needs to request the SGSN context from the SGSN if it receives a Tracking Area Update from an unknown UE.</p>
<p>If this succeeds then the PDP context at the pgw needs to be modified. <br />See diagrams TS 23.401 D 3.5-1 and D 3.6-1 for details.</p> Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - Feature #6290 (In Progress): Organize Os...https://osmocom.org/issues/62902023-12-06T14:17:47Zlaforge
<p>We already wanted to re-start 2023 but somehow I didn't manage to ever find the time and energy to do it. But let's make sure we definitely have an OsmoDevCon in 2024 again.</p>
<p>The date and venue are still TBD, as is pretty much anything else.</p> OsmoGGSN (former OpenGGSN) - Feature #6223 (In Progress): TTCN3 unit test[s] for GTPv1U with exte...https://osmocom.org/issues/62232023-10-18T15:03:43Zlaforge
<p>Let's generate GTPv1U trffic with one or even multiple extension headers and see if osmo-ggsn (in both kernel and userspace case) pass the user data as normally expected.</p> OsmoGGSN (former OpenGGSN) - Feature #6096 (In Progress): add support for kernel-GTP IPv6https://osmocom.org/issues/60962023-07-12T20:37:17Zlaforge
<p><a class="user active" href="https://osmocom.org/users/21027">pablo</a> has implemented [inner] IPv6 support in the kernel GTP driver and libgtpnl, see <a class="issue tracker-1 status-2 priority-3 priority-high3" title="Bug: IPv6 support for inner (user) IP layer missing (In Progress)" href="https://osmocom.org/issues/1952">#1952</a></p>
<p>In order to end-to-end test it in our TTCN3 test suite (which already tests ipv6 when used with userspace GTP), we would need to add supprot for it to osmo-ggsn</p>
<p>I think <a class="user active" href="https://osmocom.org/users/30187">pespin</a> is currently too busy to look at this, hence assigned to <a class="user active" href="https://osmocom.org/users/301771">osmith</a>, but that's not mandatory. Feel free to pass around as needed.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #5861 (In Progress): extend charon with ...https://osmocom.org/issues/58612023-01-17T15:53:09Zlaforge
<p>right now there's a charon plugin for eap-aka. It uses a local CSV file for storage of K/OP values, and it assumes it can synchronously access that and use it to derive AUTN challenges. so basically it includes a mini-hss/hlr.</p>
<p>We need to modify/replace that with a system where we get an asynchronous request for authentication over some external interface (currently called CEAI in my diagram at <a class="wiki-page" href="https://osmocom.org/projects/osmo-epdg/wiki/EPDG_implementation_plan">EPDG_implementation_plan</a>), like a unix domain socket. Charon then needs to wait until whatever external application has obtained auth tuples, and proceed with EAP-AKA only once a tuple has been received.</p>
<p>This can be developed and tested independent of the actual ePDG by implementing a small stub program that for example reas key material from a local CSV file (again), or possibly even by asking osmo-hlr via GSUP (we do have all the related libraries in place for C and python, AFAIR). So the latter might actually be easier than the CSV approach, where again one needs to do key derviation etc.</p> OsmoBSC - Feature #5755 (In Progress): io_uring support in osmo-bschttps://osmocom.org/issues/57552022-11-09T12:56:54Zlaforge
<p>Once libosmocore provides the new API for the upcoming io_uring backend (<a class="issue tracker-2 status-3 priority-3 priority-high3 closed" title="Feature: io_uring support in libosmocore (Resolved)" href="https://osmocom.org/issues/5751">#5751</a>) we will need to port osmo-bsc over to this new API.</p>
<p>Some I/O is done directly by osmo-bsc, while other I/O is done via libaries such as libosmo-sigtran, libosmo-netif, libosmo-mgcp-client. There are separate tickets for porting over those libraries. Once that has happened, there might also be API changes for osmo-bsc to catch up with.</p>
<p>Currently we're using the following code-paths for I/O</p>
<table>
<tr>
<th>osmo-bsc function</th>
<th>I/O function</th>
<th>provided by</th>
</tr>
<tr>
<td>bsc_sccplite_mgcp_proxy_cb</td>
<td>recv</td>
<td>-</td>
</tr>
<tr>
<td>bsc_sccplite_rx_mgcp</td>
<td>send</td>
<td>-</td>
</tr>
<tr>
<td>cbsp_srv_cb/cbsp_client_read_cb</td>
<td>osmo_cbsp_recv_buffered</td>
<td>libosmocore</td>
</tr>
<tr>
<td>cbsp_tx_decoded</td>
<td>osmo_stream_{cli,srv}_send</td>
<td>libosmo-netif</td>
</tr>
<tr>
<td>Abis interface</td>
<td>-</td>
<td>libosmo-abis</td>
</tr>
<tr>
<td>A+Lb interface</td>
<td>-</td>
<td>libosmo-sigtran</td>
</tr>
<tr>
<td>VTY interface</td>
<td>-</td>
<td>libosmo-vty</td>
</tr>
<tr>
<td>CTRL interface</td>
<td>-</td>
<td>libosmo-ctrl</td>
</tr>
</table>
<p>We need to analyze each of those and migrate, if possible.</p>
<p>There is also some other I/O like meas_feed, pcu_sock rf_ctrl which are not performance critical and hence can stay like they are and are not further discussed here.</p> Osmocom Libraries - Bug #5683 (New): How to install osmocom in Chinahttps://osmocom.org/issues/56832022-09-18T10:18:56Z914068469@qq.com
<p>Is it necessary to <a class="external" href="ftp://sources.redhat.com/pub/newlib">ftp://sources.redhat.com/pub/newlib</a> Download newlib-1.19.0.tar.gz</p> OsmoBSCNAT - Bug #5574 (New): OsmoBSCNAT testsuite running in jenkinshttps://osmocom.org/issues/55742022-06-01T10:38:54Zosmith
<p>As discussed earlier, OsmoBSCNAT ttcn3 tests should be running in jenkins, like for other Osmocom projects.</p> OsmoMSC - Bug #5559 (Stalled): OsmoMSC at 100% CPU and unresponsive for up to several minutes!https://osmocom.org/issues/55592022-05-12T23:22:09Zkeith
<p>Not much more to say than the title I'm afraid.</p>
<p>So far, I've actually only noticed it on a system using the RBS and osmo-e1d. But I do not have conclusive proof that it is exclusively happening here.</p>
<p>I'm assuming a culprit might be the sms queue, but I'm not convinced because I'm not seeing it on other systems with more messages in the queue in the sqlite db - and this can be upwards of 1,000 SMS queued.</p> OsmoTRX - Feature #5516 (In Progress): BladeRF 2.0 Supporthttps://osmocom.org/issues/55162022-04-07T08:12:04Zakibsayyed
<p>Dear OSMOCOM Community</p>
<p>I was looking to purchase LimeSDR/Mini but it's been discontinued and coming up with a newer 2.0 version</p>
<p>Can we put efforts in adding support for bladerf as well.</p>
<p>Link for new LimeSDR Mini Page<br /><a class="external" href="https://www.crowdsupply.com/lime-micro/limesdr-mini-2-0">https://www.crowdsupply.com/lime-micro/limesdr-mini-2-0</a></p> Open Source IMS Client - Feature #5481 (New): SIM card interface for doubangohttps://osmocom.org/issues/54812022-03-07T10:53:16Zlaforge
<p>The pre-existing <a class="wiki-page" href="https://osmocom.org/projects/foss-ims-client/wiki/Doubango">doubango</a> library code assumes that the IMS client has knowledge of the secret key material (K + OP/OPc) in order to perform the authentication and IPsec key establoshment to the P-CSCF.</p>
<p>This may be the case in <em>some</em> testing/lab setups, but in general this key material is stored on the ISIM or USIM application of a SIM card.</p>
<p>If we want to use doubango with such standard cards, we need some kind of interface how doubango can perform authentication via ISIM/USIM.</p>
The interface should be rather generic, as the detailed interface for SIM access will be highly platform specific:
<ul>
<li>For development on a normal Linux laptop, a pcsc-lite based interface to a smart card reader will be used.</li>
<li>For execution inside a specific phone, phone specific interfaces for SIM card access may be used (QMI, AT+CSIM, ...)</li>
</ul> Open Source IMS Client - Feature #5480 (In Progress): Linux kernel IPsec plugin for doubangohttps://osmocom.org/issues/54802022-03-07T10:49:03Zlaforge
<p>This task is about creating an IPsec plugin for the <a class="wiki-page" href="https://osmocom.org/projects/foss-ims-client/wiki/Doubango">doubango</a> library, allowing doubango to control IPsec policies and security associations in the kernel IPsec stack.</p>
<p>Doubango already has a related plugin architecture and a sample plugin for Windows 10</p> OsmoBTS - Feature #5256 (New): support for random padding in LAPDm downlink messageshttps://osmocom.org/issues/52562021-10-12T11:17:43Zlaforge
<p>See GP-081417, GP-081418 for the details, see also <a class="issue tracker-1 status-1 priority-3 priority-high3" title="Bug: Random LAPDm MAC-block padding is not deployed yet (New)" href="https://osmocom.org/issues/1481">#1481</a></p> OsmoBSC - Feature #5106 (Feedback): Watchdog that would try to un-BORKE BORKen timeslotshttps://osmocom.org/issues/51062021-04-04T20:21:26Zkeith
<p>In <a class="issue tracker-1 status-3 priority-2 priority-default closed behind-schedule" title="Bug: rbs2000 ALL BORKEN Channels (Resolved)" href="https://osmocom.org/issues/5096">#5096</a> that discussed lchans ending up borken on a busy ericsson bts:</p>
<p>"What would probably make sense is some kind of watchdog that would try to un-BORKE BORKen timeslots after a certain time. This can be done by activating a broken sub-slot and releasing it immediately. If the BTS still refuses to activate it, then it's completely BORKen and the second attempt to un-BORKE can be postponed further."</p>
<p>(<a class="external" href="https://osmocom.org/issues/5096#note-12">https://osmocom.org/issues/5096#note-12</a>)</p> OsmoBSC - Feature #4940 (Stalled): VAMOS support in OsmoBSChttps://osmocom.org/issues/49402021-01-12T13:52:23Zlaforge
<p>This ticket should document what needs to be done in terms of supporting <a class="wiki-page" href="https://osmocom.org/projects/cellular-infrastructure/wiki/VAMOS">VAMOS</a> from <a class="wiki-page" href="https://osmocom.org/projects/osmobsc/wiki">OsmoBSC</a>, and to track its status via check-lists and possibly sub-issues.</p>
<p>3GPP unfortuantely doesn't provide any specifications for VAMOS beyond the radio interface. Neither A-bis OML nor RSL specs did receive any related updates.</p>
On an abstract level, we (IMHO) have the following problem domains:
<ol>
<li>how to represent the second user for each lchan</li>
<li>how to configure VAMOS via OML</li>
<li>how to represent the VAMOS channels on RSL</li>
<li>how to include VAMOS decisions in the channel allocator for assignment and hand-over</li>
</ol>
<p>as for the "representation" and "RSL" side, my idea would be to use the concept of "shadow TRX", i.e. introduce a second, logical TRX for each real TRX. Then one subscriber is on the "real" TRX and the other subscriber on the "shadow" TRX. Our data structures and RSL currently have at leaset uint8_t for the TRX number, and in reality no more than 12 TRX are ever expected in one BTS. This means we could e.g. use one of the higher-order bits to decide between real / shadow. So e.g.</p>
<ul>
<li>TRX number (and IPA stream ID) 0x00: TRX 0 (real)</li>
<li>TRX number (and IPA stream ID) 0x01: TRX 1 (real)</li>
<li>TRX number (and IPA stream ID) 0x80: TRX 0 (shadow)</li>
<li>TRX number (and IPA stream ID) 0x81: TRX 1 (shadow)</li>
<li>...</li>
</ul> osmo-gbproxy - Feature #4522 (Stalled): gbproxy: Redundancy within proxy pairhttps://osmocom.org/issues/45222020-05-01T13:40:49Zlaforge
<p>A gbproxy pair features a redundant connection between the BSS and SGSN side.</p>
<p>Should either of the two proxies within a pair be inoperational, the NS-VCs over the E1 circuits on the BSS side of that one proxy are getting BLOCKED and traffic between BSS and SGSN transparently continues to flow via the other proxy of the pair.</p> Distributed GSM - Support #4308 (New): thoughts about incorporating credit / billing in D-GSMhttps://osmocom.org/issues/43082019-12-04T14:04:46Zneelsnhofmeyr@sysmocom.de
<p>it is not a priority to really implement a working setup, but we should have a bit of a plan for the future, to not block progress later.</p>
<p>- how could credit management be standardized?<br />- how to handle link loss? keep a set amount of credit on each site to use even if the subscriber's home village is unreachable?<br />- think about credit for: voice, sms, data connections.<br />- Look at DIAMETER accounting specs, CCR / CCA <a class="external" href="https://en.wikipedia.org/wiki/Diameter_Credit-Control_Application">https://en.wikipedia.org/wiki/Diameter_Credit-Control_Application</a></p> Qualcomm Linux Modems by Quectel & Co - Support #4206 (New): Unbrick cpe router without web ui in...https://osmocom.org/issues/42062019-09-16T10:41:38Zjahcultura
<p>I have a router 4G cpe modem with linux embedded without web access and terminal does anyone know how to recover? I checked on the board has the points RX, TX, DLOAD, RESET_N, so I saw here only have SMD components so the only way to rewrite the firmware would be for these communication points. Note: I tried access via serial but stops at bootloader.</p>
<p>SERIAL LOG:<br />Format: Log Type - Time(microsec) - Message - Optional Info<br />Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic<br />S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.1.2-00075<br />S - IMAGE_VARIANT_STRING=LAATANAZA<br />S - OEM_IMAGE_VERSION_STRING=ubuntu<br />S - Boot Config, 0x000002e0<br />B - 1216 - PBL, Start<br />B - 3723 - bootable_media_detect_entry, Start<br />B - 4454 - bootable_media_detect_success, Start<br />B - 4458 - elf_loader_entry, Start<br />B - 6701 - auth_hash_seg_entry, Start<br />B - 6923 - auth_hash_seg_exit, Start<br />B - 59917 - elf_segs_hash_verify_entry, Start<br />B - 107892 - PBL, End<br />B - 97478 - SBL1, Start<br />B - 146003 - pm_device_init, Start<br />B - 163114 - PM_SET_VAL:Skip<br />D - 15890 - pm_device_init, Delta<br />B - 164120 - boot_config_data_table_init, Start<br />D - 174948 - boot_config_data_table_init, Delta - (420 Bytes)<br />B - 342576 - CDT version:3,Platform ID:8,Major ID:1,Minor ID:0,Subtype:0<br />B - 348767 - sbl1_ddr_set_params, Start<br />B - 352580 - Pre_DDR_clock_init, Start<br />D - 244 - Pre_DDR_clock_init, Delta<br />D - 0 - sbl1_ddr_set_params, Delta<br />B - 365237 - pm_driver_init, Start<br />D - 4544 - pm_driver_init, Delta<br />B - 371642 - cpr_init, Start<br />D - 91 - cpr_init, Delta<br />B - 376156 - cpr_cx_mx_apc_vol_update, Start<br />D - 91 - cpr_cx_mx_apc_vol_update, Delta<br />B - 391071 - sbl1_qhsusb_al_do_fast_enum, Start<br />D - 0 - sbl1_qhsusb_al_do_fast_enum, Delta<br />B - 394060 - clock_init, Start<br />D - 152 - clock_init, Delta<br />B - 399855 - boot_flash_init, Start<br />D - 28670 - boot_flash_init, Delta<br />B - 500230 - Image Load, Start<br />D - 78172 - QSEE Image Loaded, Delta - (490820 Bytes)<br />B - 580049 - sbl1_efs_handle_cookies, Start<br />D - 0 - sbl1_efs_handle_cookies, Delta<br />B - 585661 - Devcfg Partition does not exist<br />B - 589839 - Image Load, Start<br />D - 518 - SEC Image Loaded, Delta - (2048 Bytes)<br />B - 597800 - Image Load, Start<br />D - 31994 - RPM Image Loaded, Delta - (152400 Bytes)<br />B - 629825 - Image Load, Start<br />D - 58804 - APPSBL Image Loaded, Delta - (367664 Bytes)<br />B - 688690 - QSEE Execution, Start<br />D - 152 - QSEE Execution, Delta<br />B - 694393 - SBL1, End<br />D - 599203 - SBL1, Delta<br />S - Throughput, 3000 KB/s (1013352 Bytes, 321860 us)<br />S - DDR Frequency, 240 MHz<br />Android Bootloader - UART_DM Initialized!!!<br />[0] welcome to lk<br />-----------------------------------------------------------------------<br />DMESG PART :</p>
<p>[ 0.000000] Booting Linux on physical CPU 0x0<br />[ 0.000000] Initializing cgroup subsys cpu<br />[ 0.000000] Initializing cgroup subsys cpuacct<br />[ 0.000000] Linux version 3.18.20 (wangshihong@ubuntu-238) (gcc version 4.9.2 (GCC) ) <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a> PREEMPT Mon Oct 22 19:35:14 CST 2018<br />[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d<br />[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache<br />[ 0.000000] Machine model: Qualcomm Technologies, Inc. MDM <br />------------------------------------------------------------------------------------------------<br />Technical Specifications</p>
<p>LTE Support Bands FDD Band 1/3/5/7/8/28<br />WCDMA 850Mhz and 2100MHz<br />CPU frequency 533MHz<br />Flash + Memory 4Gb + 2 Gb DDR2<br />WIFI<br />2T2R 2.4GHz<br />802.11b/g/n, 300Mbps<br />Interface<br />1 x Power DC Port :<br />DC12V/1A<br />1 x RJ11<br />1x RJ45<br />10Mbps/100Mbps/1000<br />Mbps WAN/LAN Port<br />1x Power Button<br />1x Reset Button<br />1x WPS Button<br />1x 2FF Standard SIM card slot<br />1x USB port</p> Cellular Network Infrastructure - Feature #4107 (Stalled): Start systemd services as non-root userhttps://osmocom.org/issues/41072019-07-15T06:56:35Zosmith
<p><a class="user active" href="https://osmocom.org/users/7">laforge</a> wrote in <a href="https://osmocom.org/issues/3369#note-12" class="external">OS#3369</a>:</p>
<blockquote>
<p>Ideally, as far as possible, we should start them as non-root user<br />(which may require changes to our systemd service files, etc. in the<br />individual git repos - but that is fine!). Starting them as non-root<br />will also means that any writes to unintended directories like '/'will<br />be discovered as they then would make the program start fail.</p>
</blockquote> OsmoCBC - Feature #3977 (New): SABP stream delineation routineshttps://osmocom.org/issues/39772019-05-06T13:52:08Zlaforge
<p>SABP is not only specified as ASN.1 with APER encoding, but 3GPP in their infinite wisdom specified that it will run directly inside a TCP stream.</p>
<p>As TCP, like any stream, doesn't preserve message boudaries, there's no length field or other framing that would tell us once a given SABP PDU is fully received. Instead, we have to implement something like an "incremental APER length determinant parser" which will parse the outer length of the APER encoded data, and then use the result of that to determine the length of one binary/encoded SABP PDU.</p>
<p>See <code>dissect_per_length_determinant()</code> from wireshark <code>packet-per.c</code> which is actually used by the wireshark SABP dissector, facing the same problem.</p> gr-osmosdr - Support #3819 (New): OSMO SDR blocks for GNUradiohttps://osmocom.org/issues/38192019-02-28T18:00:07Zchesir
<p>I installed GNUradio, and its GUI, gnuradio-companion, using pybombs. The use of pybombs for installation requires that one set up a prefix point, or directory, so that all installation files are under that directory. When I use the method outlined in <a class="external" href="https://osmocom.org/projects/gr-osmosdr/wiki/GrOsmoSDR">https://osmocom.org/projects/gr-osmosdr/wiki/GrOsmoSDR</a>, many files, including the RTL SDR Source block file, are installed, but I do not know which files, aside from (obviously) the block file, should be copied from the default installation locations to a directory under my prefix point for the blocks to actually work. Having copied only the RTL SDR Source block file, and attempting to execute the GRC flowgraph (which contains that one block), I am greeted with the error "Import Error: No module named osmosdr" What do I do?</p> OsmoBSC - Feature #3659 (Stalled): handover during LCLS directly between BTSshttps://osmocom.org/issues/36592018-10-17T09:22:23Zlaforge
<p>So far, we have implemented LCLS on the BSC level, i.e. in case of a local switch, the RTP stream still goes from BTS A to the BSC-colocated MGW and from there to BTS B. This removes the RTP/voice from A, but not from the Abis side.</p>
<p>In deployments where there are e.g. 3 BTS (A,B,C) at one site, back-hauled via Abis to a BSC in a remote data center, we want the voice to go directly between BTS A and BTS B, without going to the MGW at the BSC.</p>
<p>This basically means that we close the loop not inside our osmo-mgw via MGCP, but that we close it between the two involved BTSs.</p>
<p>Even in a single-remote-BTS use case, this helps in cases where both calling and called subscribers are attached to that same BTS.</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> OsmoBTS - Feature #3155 (Stalled): execute BTS_Tests.ttcn with real (C123) phone hardware in LTHW...https://osmocom.org/issues/31552018-04-10T16:28:12Zlaforge
<p>We want to execute the BTS_Tests.ttcn against all real hardware BTS models of our LTHW setup.</p>
<a name="Hardware-Setup"></a>
<h2 >Hardware Setup<a href="#Hardware-Setup" class="wiki-anchor">¶</a></h2>
On the hardware side, his means, we need to
<ul>
<li>add a C123 with RF cabling to the "modem ports" of the setup</li>
<li>be able to power cycle this C123 from software</li>
<li>attach the C123 UART via CP2103 USB-UART to the main unit</li>
</ul>
<a name="Software-Setup"></a>
<h2 >Software Setup<a href="#Software-Setup" class="wiki-anchor">¶</a></h2>
<p>We will need to be able to execute the BTS_Tests.ttcn on the gsm tester main unit. This could be done either natively or via the existing docker containers. In any case, we don't want to <strong>build</strong> the ttcn source on the low-power APU, but we want that the compiled test suite is copied/transferred to the APU and then executed there.</p>
<p>We also want to make sure that we have proper locking/exclusivity with the osmo-gsm-tester stack, so that we either run osmo-gsm-tester or BTS_Tests.ttcn.</p>
<p>Finally, this should all be started from jenkins.osmocom.org.</p>
<p>It probably makes sense (as usual) to start with the R&D setup and then replicate the setup in production.</p> Cellular Network Infrastructure - Feature #2623 (New): SCCP/M3UA: detect restart of osmo-msc and ...https://osmocom.org/issues/26232017-11-07T23:25:36Zneelsnhofmeyr@sysmocom.de
<p>Connecting osmo-bsc and osmo-hnbgw to the MSC and SGSN via an OsmoSTP instance, it is currently not possible to detect that the MSC or SGSN has restarted.</p>
<p>Scenario: using a sysmoBTS as a NITB, change MSC config, restart MSC -- now osmo-bsc happily continues to run and does not even notice that it is an entirely new MSC instance running in the core net now.</p>
<p>In the old days, the SCCPlite link would go down, but since now OsmoSTP is in-between and has no concept of who depends on who, no-one is notifying BSC or HNBGW that MSC or SGSN have gone down. Find out how this is intended to be solved if at all, and devise a way how osmo-bsc will restart and/or reconnect to a new MSC instance, and so forth.</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> Cellular Network Infrastructure - Feature #2604 (Stalled): GSUP-to-DIAMETER converter / IWFhttps://osmocom.org/issues/26042017-10-29T23:01:06Zlaforge
<p>In order to support a single subscriber database for 2G/3G and LTE, operators normally use a single HSS. HSS is the EPC successor of the LTE.</p>
<p>Instead of MAP over SS7, HSS's speak DIAMETER over SCTP or TCP (with optional TLS). The types of procedures / transactions are pretty much the same as before, but the encoding and the protocol changed completely.</p>
<p>There are a couple of (at least minimal) HSS implementations out there, from freeDiameter to nextepc, to name some examples.</p>
<p>If we were to implement a converter between GSUP and DIAMETER, then the OsmoMSC and OsmoSGSN could access an external HSS - and that same HSS could be accessed from nextepc or even openair-cn for LTE access.</p>
<p>3GPP TS 29.305 specifies the MAP-to-DIAMETeR InterWorkingFunction (IWF), which is pretty much the same device, with the exception that we'd use GSUP instead of MAP.</p> OsmocomBB - Feature #2409 (Stalled): Add GPRS support to virt_phy and L1CTLhttps://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> OP25 - Feature #2175 (New): Update code for GNURadio 3.6 and laterhttps://osmocom.org/issues/21752017-04-22T16:04:15Z
<p>GNURadio 3.6 introduces a lot of improved functionality. We are already suffering because not all of this code is backwards compatible nor is it particularly easy to get things working.</p>
1. Using cmake to build the C++ blocks.
<ul>
<li>Integrate all C++ blocks (repeater, decoder, etc.) into single build.</li>
<li>Rename blocks so they comply with new namespace rules.</li>
<li>Add support for message passing and metadata.</li>
<li>Ensure that grc is supported for all blocks.<br />1. Remove IT++ or, at the very minimum, fix the problems with the changes to BCH decoding.</li>
<li>IT++ has changed how it decodes BCH and this breaks packet decoding.<br />1. Refactoring code so we can pass messages and structured data between blocks.<br />1. Update top-level python code to use argparse, update GUI etc..<br />1. Flesh out some top-level C++ code as alternative to Python scripts.</li>
</ul> OsmocomBB - Feature #1461 (Stalled): include some version information / negotiation in the L1CTL ...https://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>