Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-08-27T18:28:35ZOpen Source Mobile Communications
Redmine OsmoMSC - Bug #6152 (In Progress): built-in MNCC: forward the @Low layer compatibility I@ IE to t...https://osmocom.org/issues/61522023-08-27T18:28:35Zfixeria
<p>The <code>Low layer compatibility I</code> IE is usually present in mobile-originated (CC) Setup messages related to date calls (CSD). According to 3GPP TS 24.008, section 9.3.23.1.7, this IE shall be included in the mobile-terminated (CC) Setup message if the calling user specified it. Currently this IE is simply ignored by the built-in osmo-msc's MNCC and not forwarded to the called party.</p> OsmoMGW - Feature #6136 (Stalled): libosmo-mgcp-client should ignore unknown codecs in SDPhttps://osmocom.org/issues/61362023-08-08T16:46:58Zneelsnhofmeyr@sysmocom.de
<p>When mgcp_client receives an MGCP response that has an unknown codec in the SDP part, it aborts with an error.<br />Instead, it should simply ignore entries that are unknown, and carry on with other, known, codecs.<br />An error should occur only when none of the SDP codec entries is valid.</p> OsmoMGW - Bug #6060 (New): osmo-mgw: Implement MGCP RestartInProgress (RSIP)https://osmocom.org/issues/60602023-06-13T12:02:02Zpespin
<p>We could delay exit() of the osmo-mgw process during SIGINT, to transmit RestartInProgress to all active endpoints, so that the call agent (bsc, msc, etc.) knows it has to terminate the calls.<br />This could perhaps even be used by Call agent to keep calls working by signalling peer BSC/BTS/MSC/etc. to change to another MGW if there's an MGW pool with more available MGW, providing higher reliability?</p>
<p>This could also be used to signal disconnect or temporary unavailability to E1 timeslots, etc.</p>
<p><a class="external" href="https://datatracker.ietf.org/doc/html/rfc3435#section-2.3.12">https://datatracker.ietf.org/doc/html/rfc3435#section-2.3.12</a><br /><a class="external" href="https://datatracker.ietf.org/doc/html/rfc3435#section-3.3.8">https://datatracker.ietf.org/doc/html/rfc3435#section-3.3.8</a><br /><a class="external" href="https://datatracker.ietf.org/doc/html/rfc3435#appendix-F.10">https://datatracker.ietf.org/doc/html/rfc3435#appendix-F.10</a></p>
<pre>
* The Gateway can use the RestartInProgress command to notify the
Call Agent that a group of endpoints managed by the gateway is
being taken out-of-service or is being placed back in-service.
</pre>
<pre>
2.3.12 RestartInProgress
The RestartInProgress command is used by the gateway to signal that
an endpoint, or a group of endpoints, is put in-service or out-of-
service.
</pre>
<pre>
Gateways SHOULD send a "graceful" or "forced" RestartInProgress
message (for the relevant endpoints) as a courtesy to the Call Agent
when they are taken out-of-service, e.g., by being shutdown, or taken
out-of-service by a network management system, however the Call Agent
cannot rely on always receiving such a message. Gateways MUST send a
"restart" RestartInProgress message (for the relevant endpoints) with
a null delay to their Call Agent when they are back in-service
according to the restart procedure specified in Section 4.4.6 - Call
Agents can rely on receiving this message. Also, gateways MUST send
a "disconnected" RestartInProgress message (for the relevant
endpoints) to their current "notified entity" according to the
"disconnected" procedure specified in Section 4.4.7.
The RestartInProgress message will be sent to the current "notified
entity" for the EndpointId in question. It is expected that a
default Call Agent, i.e., "notified entity", has been provisioned so
that after a reboot/restart, the default Call Agent will always be
the "notified entity" for the endpoint. Gateways SHOULD take full
advantage of wild-carding to minimize the number of RestartInProgress
messages generated when multiple endpoints in a gateway restart and
the endpoints are managed by the same Call Agent.
</pre>
<pre>
8) RestartInProgress MUST always be the first command sent by an
endpoint as defined by the restart procedure. Any other command
or non-restart response (see Section 4.4.6), except for responses
to auditing, MUST be delivered after this RestartInProgress
command (piggybacking allowed).
</pre>
<pre>
In some cases, many gateways may decide to restart operation at the
same time. This may occur, for example, if an area loses power or
transmission capability during an earthquake or an ice storm. When
power and transmission are reestablished, many gateways may decide to
send "RestartInProgress" commands simultaneously, leading to very
unstable operation.
</pre>
<pre>
A virtual endpoint may be created as the result of using the "any of"
wildcard. Similarly, a virtual endpoint may cease to exist once the
last connection on the virtual endpoint is deleted. The definition
of the virtual endpoint MUST detail both of these aspects.
When a <virtual-endpoint-type> creates and deletes virtual endpoints
automatically, there will be cases where no virtual endpoints exist
at the time a RestartInProgress command is to be issued. In such
cases, the gateway SHOULD simply use the "all of" wildcard in lieu of
any specific <endpoint-#> as in, e.g.:
ann/*@mygateway.whatever.net
If the RestartInProgress command refers to all endpoints in the
gateway (virtual or not), the <virtual-endpoint-id> can be omitted as
in, e.g.:
*@mygateway.whatever.net
</pre>
<p>It seems we must also be sending that message for each available endpoint at startup AFAIU (or 1 with wildcard "*"). We seem to be missing a "default Call Agent" in osmo-mgw though":<br /><pre>
It is expected that a
default Call Agent, i.e., "notified entity", has been provisioned so
that after a reboot/restart, the default Call Agent will always be
the "notified entity" for the endpoint.
....
Note that as mentioned earlier, the default "notified entity" is
provisioned and may include both domain name and port. For small
gateways, provisioning may be done on a per endpoint basis. For much
larger gateways, a single provisioning element may be provided for
multiple endpoints or even for the entire gateway itself. In either
case, once the gateway powers up, each endpoint MUST have its own
"notified entity", so provisioned values for an aggregation of
endpoints MUST be copied to the "notified entity" for each endpoint
in the aggregation before operation proceeds. Where possible, the
RestartInProgress command on restart SHOULD be sent to the
provisioned "notified entity" based on an aggregation that allows the
"all of" wild-card to be used. This will reduce the number of
RestartInProgress messages.
</pre></p> OsmoBSC - Bug #5991 (New): Forward TSNS-PROV bsc->[bts->]pcuhttps://osmocom.org/issues/59912023-03-31T16:42:23Zpespin
<p>Currently, we pass 3 types of GPRS related timer IEs BSC->BTS through OML, which are then forwarded to osmo-pcu through PCUIF: RLCMAC, BSSGP and NS timers</p>
<p>This ticket is about the 3rd type, NS timers.<br />In osmo-bsc:<br /><pre>
/* BTS Site Manager */
struct gsm_bts_sm {
struct gsm_bts *bts[1]; /* only one bts supported so far */
struct gsm_abis_mo mo;
/* nanoBTS and old versions of osmo-bts behaves this way due to
broken FSMs not following TS 12.21: they never do
Dependency->Offline transition, but they should be OPSTARTed
nevertheless during Dependnecy state to work. This field is
used by all dependent NM objects. */
bool peer_has_no_avstate_offline;
struct {
struct gsm_gprs_nse nse;
struct gsm_gprs_nsvc nsvc[2];
} gprs;
};
struct gsm_gprs_nse {
struct gsm_abis_mo mo;
uint16_t nsei;
uint8_t timer[7];
};
</pre></p>
<pre>
DEFUN_USRATTR(cfg_bts_gprs_ns_timer,
cfg_bts_gprs_ns_timer_cmd,
X(BSC_VTY_ATTR_RESTART_ABIS_OML_LINK),
"gprs ns timer " NS_TIMERS " <0-255>",
GPRS_TEXT "Network Service\n"
"Network Service Timer\n"
NS_TIMERS_HELP "Timer Value\n")
{
struct gsm_bts *bts = vty->index;
int idx = get_string_value(gprs_ns_timer_strs, argv[0]);
int val = atoi(argv[1]);
GPRS_CHECK_ENABLED(bts);
if (idx < 0 || idx >= ARRAY_SIZE(bts->site_mgr->gprs.nse.timer))
return CMD_WARNING;
bts->site_mgr->gprs.nse.timer[idx] = val;
return CMD_SUCCESS;
}
</pre>
<pre>
struct msgb *nanobts_gen_set_nse_attr(struct gsm_bts_sm *bts_sm)
{
...
/* all timers in seconds */
OSMO_ASSERT(ARRAY_SIZE(bts_sm->gprs.nse.timer) < sizeof(buf));
memcpy(buf, bts_sm->gprs.nse.timer, ARRAY_SIZE(bts_sm->gprs.nse.timer));
msgb_tl16v_put(msgb, NM_ATT_IPACC_NS_CFG, 7, buf);
</pre>
<p>The NS_TIMERS(_HELP) from osmo-bsc VTY actually come from libosmcore:<br /><pre>
#define NS_TIMERS_COUNT 8
#define NS_TIMERS "(tns-block|tns-block-retries|tns-reset|tns-reset-retries|tns-test|tns-alive|tns-alive-retries|tsns-prov)"
#define NS_TIMERS_HELP \
"(un)blocking Timer (Tns-block) timeout\n" \
"(un)blocking Timer (Tns-block) number of retries\n" \
"Reset Timer (Tns-reset) timeout\n" \
"Reset Timer (Tns-reset) number of retries\n" \
"Test Timer (Tns-test) timeout\n" \
"Alive Timer (Tns-alive) timeout\n" \
"Alive Timer (Tns-alive) number of retries\n" \
"SNS Provision Timer (Tsns-prov) timeout\n"
</pre></p>
<p>First thing to notice: There are 8 timers in libosmocore, but the arrays of osmo-bsc are of size 7.<br />That's because the TSNS-PROV (3GPP TS 48.016 grep for "Tsns-prov") is missing, which is the 8ht one.</p>
<p>That's neither copied to the IE sent over Abis OML to the BTS, allegedly because ipaccess nanoBTS never supported SNS.</p>
<p>In our case, we do support SNS, and we want to pass that SNS timer (and maybe more timers if they exist in the same SNS spec?).</p>
Hence, what needs to be done:
<ul>
<li>osmo-bsc: Update struct gsm_gprs_nse "uint8_t timer<sup><a href="#fn7">7</a></sup>;" to be of size NS_TIMERS_COUNT (maybe even better, update osmo-bsc to use new gprs_ns2.h?)</li>
<li>osmo-bsc: In nanobts_gen_set_nse_attr(), if BTS is nanoBTs keep sending 7 bytes (it's what nanoBTS expects). If it's an osmo-bts, then send the entire list of timers (8 bytes).</li>
<li>osmo-bts: Handle both 7-byte and 8-byte cases when receiving the OML IE.</li>
<li>osmo-bts/osmo-pcu: Update PCUIF to make the timer 8 bytes long (<a class="user active" href="https://osmocom.org/users/30">daniel</a> , it would be great if you can provide feedback whether we may want to send more still not implemented timers later on, so that we can maybe extend the PCUIF array now to be 16 bytes).</li>
</ul>
<p>So there's 2 independent steps here:<br />- Support passing TSNS-PROV BSC->BTS over Abis OML for osmo-bts<br />- Support passing TSNS-PROV BSC/BTS->PCU over PCUIF.</p> OsmoBTS - Bug #5957 (New): not all osmo-bts variants respond to abisip-findhttps://osmocom.org/issues/59572023-03-22T09:20:14Zlaforge
<p>The abisip-find utility uses brodcast UDP packets to obtain a list of all BTSs reachable via the local network segment using the <code>abisip-find</code> utility (part of osmo-bsc source code).</p>
<p>For some reason unknown to me, this functionality is implemented as part of osmobts-{sysmo,lc15,oc2g}-mgr, and not part of the normal osm-bts-* program. This means that osmo-bts-trx doesn't suppport the feature.</p>
<p>Looking at <code>{oc2g,lc15,sysmo}bts_mgr_nl.c</code> in the sourec code, the only difference is the code obtaining parameters such as serial number, BTS model name and Ethernet MAC adress.</p>
IMHO, the code could be unified to have
<ul>
<li>one common/shared implementation, that
<ul>
<li>becomes part of the normal osmo-bts binary</li>
<li>gets passed in the model-specific information via some struct from the model-specific part when initialized</li>
</ul></li>
</ul>
<p>Assigning to <a class="user active" href="https://osmocom.org/users/42">jolly</a> (for after april 1st)</p>
<p>Afterwards, <a class="external" href="https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/32004">https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/32004</a> can be merged to update documentation</p> libosmocore - Bug #5915 (New): gprs: ns2: convert timers into osmo-timershttps://osmocom.org/issues/59152023-02-20T22:01:55Zlynxis
<p>gprs_ns2 isn't using osmo-timers for the internal timers.</p>
<pre>
# libosmocore/src/gb/gprs_ns2_vty.c:93
/* TODO: this should into osmo timer */
static const struct value_string gprs_ns_timer_strs[] = {
{ 0, "tns-block" },
{ 1, "tns-block-retries" },
{ 2, "tns-reset" },
{ 3, "tns-reset-retries" },
{ 4, "tns-test" },
{ 5, "tns-alive" },
{ 6, "tns-alive-retries" },
{ 7, "tsns-prov" },
{ 8, "tsns-size-retries" },
{ 9, "tsns-config-retries" },
{10, "tsns-procedures-retries" },
{ 0, NULL }
};
</pre> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> OsmoHLR - Feature #5865 (New): Automate selection of LU Reject Causehttps://osmocom.org/issues/58652023-01-20T13:59:07Zkeith
<p>There is some suggestion in <a class="external" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16808">https://gerrit.osmocom.org/c/osmo-hlr/+/16808</a> that osmo-hlr could use some criteria to decide what cause/reason to send to the GSUP client when rejecting a Location/Routing Update</p>
<p>Possibly, sending "IMSI Unknown in HLR" is wrong when the SIM is foreign to our network.</p>
<p>We could have a regex config option to let osmo-hlr know what is "our" SIM or not. Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP? I'm not familiar with GSUP.</p> OsmoBTS - Bug #5774 (Feedback): Drop pcu_sock conn if queue length grows up to a given thresholdhttps://osmocom.org/issues/57742022-11-18T18:45:46Zpespin
<pre>
<pespin_> we seem to have some memleak or mem-kept problem with osmo-bts-trx after a while when the pcu is paused in gdb
<pespin_> my osmo-bts-trx was taking 35% of my 16GB RAM
<LaF0rge> pespin_: well, probably lots of primitives queued for the pcu socket ;)
<pespin_> probably osmo-bts-trx sees the PCU socket still alive (process paused by gdb) and keeps queueing stuff forever in the PCUIF queue
<pespin_> yeah
<fixeria> maybe it's queueing the PCUIF messages somewhere?
<pespin_> we should block the queue from growing like that
<pespin_> keep it at a meaningful maximum size and drop older messages when adding new ones if the threshold is reached
<pespin_> I'll create a ticket to remind us
<fixeria> libosmocore's write_queue allows to set the limit, AFAIR
<pespin_> yeah but it's probably not dropping the old ones
<Hoernchen_> just drop all, no point trying to fix it by keeping "recent" messages, since the whole relationship of messages is fucked up anyway
<fixeria> but it will be rejecting new messages, not old
<pespin_> Hoernchen_, still it may be able to recover that way
<Hoernchen_> how?
<pespin_> just by keeping processing new messages?
<Hoernchen_> yeah,new ones, but why bother with the ones in the queue?
<pespin_> that's why I said "up to a meaningul length"
<Hoernchen_> it just adds complexity keping track without actually affecting the probability of the "catching up" part after missing a lot of messages
<pespin_> no need to keep 1000 of them
<fixeria> the messages are queued because the fd is not writeable, so by processing out-of-queue you'll simply block the process
<pespin_> not much complexity: if (len > 10), llist_del(list_head->next); llist_add_tail(new_msg)
<LaF0rge> i would probably simply close the pcu_socket if we detect long queue lengths
<LaF0rge> let the pcu reconnect if it recovers/restarts
<LaF0rge> so have a osmo_wqueue, and if it overflows, close the fd, done.
<LaF0rge> [and flush the queue of course when closing]
<pespin_> ack makes sense
</pre>
<p>So let's establish a good threshold (configurable to allow debugging pcu without breaking the conn?) at which osmo-bts-trx can decide the PCU is stuck and can close the conn and drop the messages until it can reconnect again successfuly.</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> OsmoBSC - Bug #5335 (In Progress): osmo-bsc: Add VTY commands to configure T3.. and N3.. timers c...https://osmocom.org/issues/53352021-11-30T17:32:18Zpespin
<p>nanobts_attr_cell_get() in src/osmo-bsc/bts_ipaccess_nanobts_omlattr.c:<br /><pre>
/* all timers in seconds, unless otherwise stated */
buf[0] = 20; /* T3142 */
buf[1] = 5; /* T3169 */
buf[2] = 5; /* T3191 */
buf[3] = 160; /* T3193 (units of 10ms) */
buf[4] = 5; /* T3195 */
buf[5] = 10; /* N3101 */
buf[6] = 4; /* N3103 */
buf[7] = 8; /* N3105 */
buf[8] = 15; /* RLC CV countdown */
</pre></p>
<p>Similarly for the NS side of the PCU in nanobts_attr_nse_get():<br /><pre>
/* all timers in seconds */
buf[0] = 3; /* blockimg timer (T1) */
buf[1] = 3; /* blocking retries */
buf[2] = 3; /* unblocking retries */
buf[3] = 3; /* reset timer (T2) */
buf[4] = 3; /* reset retries */
buf[5] = 10; /* suspend timer (T3) in 100ms */
buf[6] = 3; /* suspend retries */
buf[7] = 10; /* resume timer (T4) in 100ms */
buf[8] = 3; /* resume retries */
buf[9] = 10; /* capability update timer (T5) */
buf[10] = 3; /* capability update retries */
</pre></p>
<p>Some of those are already being applied by osmo-pcu from what it receives in PCUIF INFO.ind, see T_defs_bts in osmo-pcu.git/src/src/bts.cpp and pcu_rx_info_ind().</p> Osmocom Analog - Bug #5247 (New): AMPS Segmentation faulthttps://osmocom.org/issues/52472021-10-04T23:45:33Zfoxrf
<p>I have built osmocom analog as described in the documentation with the latest git release and amps seg faults as soon as it opens the SDR via soapySDR. <br />I do not have any logs or documents to show at this time as I am unable to obtain a core dump. I have tried this on both an x86 system and ARM (raspberry pi)</p>
<p>There were some build issues related to Devices.h in SoapySDR however I was able to resolve that by replacing the file with the most current version in their git repo.</p> Osmocom Analog - Feature #5143 (New): Using ADALM PLUTO SDR with osmocom-analoghttps://osmocom.org/issues/51432021-05-05T17:01:16ZArmin
<p>Hi,<br />I tried different Soapy SDR device strings with nmt app to start it work with Pluto SDR, but no success.<br />Can you help me construct the device string, to make it work with pluto SDR?</p> Osmocom Analog - Feature #4971 (New): OsmoCC Socket Documentation https://osmocom.org/issues/49712021-01-22T22:28:11Zfoxrf
<p>It appears that the MNCC socket has been replaced with OSMOCC which does not appear to have ANY documentation around how you are actually supposed to configure call routing with this thing. More specially the osmo-cc-router package attempts to call a bash script "routing.sh" for which there is no sample or documentation going over the syntax. Please add full documentation on how this bash script is supposed to route calls and or provide a detailed example script.</p> Osmocom Analog - Feature #3672 (New): Custom announcement and toneshttps://osmocom.org/issues/36722018-10-25T17:10:01ZArmin
<p>Hi,</p>
<p>how it's possible to change the announce in NMT?<br />I see there is file with hex data (announcement.c).<br />How can I convert usual raw audio or WAV to the same HEX format?</p> Cellular Network Infrastructure - Feature #3142 (New): Further simplification of "NITB like" setupshttps://osmocom.org/issues/31422018-04-05T20:09:38Zlaforge
<p>Running the post-NITB network is quite a lot more complex than the old code.</p>
<p>There are some ideas on how to make it simpler to run small, self-contained networks while removing some complexity</p>
<ul>
<li>I was also wondering if we should spend time on "MGW-less operation". In theory, you only need OsmoMGW if you have no IP-level routing between your Abis / A / core network [like any decent network operator for security reasons]. But then, if you run everything on one machine, and don't need/want transcoding, and have transparent routing between all components, we could do without the MGW.</li>
</ul>
<ul>
<li>stp-less operation should also be possible (but make configuration actually more complicated), as both the "ASP" (client) and "SG" (server) role are inside libosmo-sigtran, and hence the server could run inside the MSC without the need of an external stp (osmo-stp is just a thin wrapper with vty around libosmo-sigtran)</li>
</ul>
<p>Let's keep this as a reminder and create sub-tasks as ideas materialize more</p> OsmoMSC - Feature #1974 (New): VLR: high water mark on subscriber storagehttps://osmocom.org/issues/19742017-03-08T14:54:50Zneelsnhofmeyr@sysmocom.de
<p>In libvlr, we (will) keep every subscriber in RAM as long as it still has valid auth tuples (3GPP TS 33.102 Annex C.2.3).<br />Most subscribers will still have auth tuples left upon detaching, so we would store <strong>all</strong> subscribers.</p>
<p>Implement a configurable way of limiting the number of subscribers kept in RAM, e.g. a fixed max size.<br />If this is reached, discard those subscribers that have been inactive for the longest time first.</p> OsmoMSC - Feature #1973 (New): VLR: efficient subscriber lookuphttps://osmocom.org/issues/19732017-03-08T14:52:10Zneelsnhofmeyr@sysmocom.de
<p>In libvlr, we (will) keep every subscriber in RAM as long as it still has valid auth tuples (3GPP TS 33.102 Annex C.2.3).<br />Most subscribers will still have auth tuples left upon detaching, so we would store <strong>all</strong> subscribers.<br />Storing numerous subscribers in a linear list is inefficient, implement a hash table for faster access times.</p> OsmoBTS - Feature #1755 (New): osmo-bts-sysmo L1: unify hLayer3 handlinghttps://osmocom.org/issues/17552016-06-16T11:27:40Zneelsnhofmeyr@sysmocom.de
<p>In <a class="external" href="https://gerrit.osmocom.org/264">https://gerrit.osmocom.org/264</a> , some hLayer3 use was added.<br />However, some of the messages were already using hLayer3.</p>
<p>After the patch, the prim_init() sets a hLayer3 which is overwritten<br />shortly after that, so the other functionality is not affected by this patch.</p>
<p>Some functions to generate hLayer3 for a timeslot and similar already existed,<br />and also to retrieve a timeslot and similar back from a hLayer3 handle.</p>
<p>And also, the other hLayer3 functions use a "magic" byte<br />(like the most significant byte always set to 0xbb).</p>
<p>So in fact, we should have rejected this patch, and we should follow up with<br />a merger of my hLayer3 to the existing hLayer3 infrastructure.<br />The priority is low though, since no harm is done.</p>
<p>See:</p>
<ul>
<li>osmo-bts/src/osmo-bts-sysmo/oml.c
<ul>
<li>mph_send_activate_req()</li>
<li>mph_send_config_logchpar()</li>
<li>mph_send_config_ciphering()</li>
<li>mph_send_deactivate_req()</li>
</ul></li>
</ul> OsmoBTS - Feature #1576 (New): consider using hLayer2 as a pointer storagehttps://osmocom.org/issues/15762016-02-23T15:38:30Zlaforge
<p>This would speed up the l1if_hLayer_to_lchan lookup. Not sure if it's worth the extra risk.</p>