Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092016-02-23T16:22:14ZOpen Source Mobile Communications
Redmine Cellular Network Infrastructure - Bug #1612 (New): more configuration consistency checkinghttps://osmocom.org/issues/16122016-02-23T16:22:14Zlaforge
<p>Right now it is possible to configure various things that wouldn't work, like an ARFCN that is outside the band of the BTS, or even the TRX.</p>
<p>More consistency checks would make sense, together with reasonable error messages.</p> OsmoMSC - Feature #1603 (New): Interfacing the MSC with other networks: Roaming interfaces / MAPhttps://osmocom.org/issues/16032016-02-23T15:57:00Zlaforge
<p>The classic Osmo{BSC,BTS,PCU,SGSN,NITB} etc. projects have no direct interface to SS7, SIGTRAN, TCAP, MAP or CAP.</p>
<p>At the same time we have plenty of projects in various states of maturity for the core network side, including independent TCAP/MAP implementations written in Smalltalk and Erlang, as well as simple core network elements like HLR/AUC.</p>
<p>In order to keep the TCAP/MAP/SCCP complexity away from the C language Osmo* components, we came up with the strategy to implement simpler protocols/interfaces on the same level of the interface. One such step can be seen with the GSUP protocol in OsmoSGSN, which can be proxied to a real MAP protocol for InsertSubscriber and SendAuthenticationInfo towards a real HLR.</p>
<p>No such interfaces for the NITB have been developed yet. The question is how realistic it is to operate a real core network on this basis. The NITB as it is will not likely receive a gsmSSF required for CAMEL, and most real/public telecom networks today require full CAMEL support for accepting inbound prepaid roaming subscribers.</p>
<p>Would a NITB with MAP gateway make sense without a gsmSSF/smsSSF?</p> OsmoBSC - Feature #1600 (New): BSC: Make SI / rest octests more configurablehttps://osmocom.org/issues/16002016-02-23T15:54:03Zlaforge
<p>There are tons of parameters in the system information messages that we don't yet expose via the VTY. The respective parameters are right now hard-coded.</p> Cellular Network Infrastructure - Feature #1598 (New): Scripting language interfacehttps://osmocom.org/issues/15982016-02-23T15:52:29Zlaforge
<p>For lab-type setups and testing of M2M devies, it would be useful to have some kind of script language bindings so the NITB could be instructed to perform certain actions under control of external software. Actions include triggering a hand-over, sending SMS, startin silent call, ...</p> Cellular Network Infrastructure - Feature #1596 (New): Generation of accounting/billing datahttps://osmocom.org/issues/15962016-02-23T15:51:42Zlaforge
<p>There should be some interface by which we generate simple accounting/billing data of some form.</p> Cellular Network Infrastructure - Feature #1590 (New): Extension of Control Interface / external ...https://osmocom.org/issues/15902016-02-23T15:47:47Zlaforge
<p>The request to configure most (or all?) NITB parameters not only by VTY but also via an external SNMP agent via the control interface has come up several times.</p>
<p>The control interface would have to be extended with all relevant (which are those?) parameters.</p>
<p>An external SNMP agent would have to be developed, attaching to the control interface. python snmp might be a good candidate as basis for that.</p> OsmoSGSN - Feature #1585 (New): Gn interface for inter-SGSN MM Context transferhttps://osmocom.org/issues/15852016-02-23T15:44:50Zlaforge
<p>Currently, we support mobility between multiple PCUs attached to one SGSN, but we don't support transfer of the MM context from one SGSN to another SGSN. The latter would require an implementation of the GTP-C based Gn interface.</p> OsmoBTS - Feature #1579 (New): Use epollhttps://osmocom.org/issues/15792016-02-23T15:41:31Zlaforge
<p>For the PHY msg queue we select a lot and we would be better off using epoll.</p> 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> OsmoBTS - Feature #1573 (New): ENHANCED MEASUREMENT REPORThttps://osmocom.org/issues/15732016-02-23T15:36:07Zlaforge
<p>We don't support this yet, neither the associated Bter frame format</p>
<p>Whether or not this message is needed is primarily dependent on whether<br />the BSC instructs the MS to use ENHANCED MEASUREMENT REPORT.</p>
<p>The same topic exists with EXTENDED MEAUSUREMENT REPORT / EXTENDED<br />MEASUREMENT ORDER.</p>
<p>OsmoBSC / OsmoNITB use neither, so it is not a requirement to OsmoBTS,<br />unless you want to use it with a different BSC.</p> OsmoBTS - Feature #1571 (New): Support RTP multiplexing instead of per-call RTP streamshttps://osmocom.org/issues/15712016-02-23T15:32:53Zlaforge
<p>The IPA Abis/IP protocol allows for multiplexing of RTP frames of multiple calls in one message. Should we implement this?</p>
<p>OsmoBSC has support for a more comprehensive Osmux protocol on the A interface. Not sure if it makes sense to put effort on Abis optimization.</p> OsmoBTS - Feature #1570 (New): Select RTP payload identifier based on requested speech modehttps://osmocom.org/issues/15702016-02-23T15:31:08Zlaforge
<p>Right now the RTP payload identifier is static, which is a deviation from the standard IPA RSL protocol behavior. It should be chosen dynamically and represent the respective voice codec.</p>
<p>This has no implication to OpenBSC. But it is a difference to how ip.access Abis/IP is implemented. So it's a limitation in compatibility to ip.access Abis/IP.</p> OsmoBTS - Feature #1561 (New): Multi-TRX support (one osmo-bts process per TRX)https://osmocom.org/issues/15612016-02-23T15:18:12Zlaforge
<p>This requires some more work, including an OML router that will route the OML messages to the respective transceiver-specific osmo-bts process. The latter processes can be on different CPUs with different IP addresses.</p>
<p>The individual transceiver-specific osmo-bts processes then need to establish each their own RSL link to the BSC.</p> OsmoPCU - Feature #1555 (New): Add support for unacknowledged RLC Modehttps://osmocom.org/issues/15552016-02-23T15:12:44Zlaforge
<p>OsmoPCU currently only supports acknowledged RLC mode. Unacknowledged mode should be possible to add without too much effort. The question is: Is it needed/used ?</p>
<p>The selection of acknowledged/unacknowledged RLC mode should be based on the QoS requirements of the PDP context.</p> OsmoPCU - Feature #1546 (New): closed loop uplink power controlhttps://osmocom.org/issues/15462016-02-23T15:04:06Zlaforge
<p>OsmoPCU currently only implements open loop power control, where the uplink power is based on the signal loss in the downlink direction with the assumption that uplink loss equals downlink loss.</p>
<p>GPRS optionally specifies closed loop power control, which works more like what we know from circuit-switched GSM. To make things complicated, it can even be a combination of open loop and closed loop.</p>
<p>Whatever we do in this area is an optimization problem and we'd need a good test/simulation case in order to benchmark any changes in the implementation.</p> OsmoPCU - Feature #1537 (New): Move the BSSGP handling to libosmocorehttps://osmocom.org/issues/15372016-02-22T21:15:17Zzecke
<p>Currently the BSSGP stack is cut into two halves. The SGSN side is implemented as a part of libosmocore the BSS side is implemented within the PCU (protocol) and libosmocore (tx functions, bctx allocation).</p>
<p>In libosmocore, incoming messages are just decoded, the protocol handling is done (mainly sending acknowledges or status messages), the corresponding bctx is updated, and further processing is passed to the upper layer via BSSGP primitives. Only the BVC RESET code does a bit more, since it automatically allocates bctx for unknown BVCIs.</p>
<p>The PCU contains the full protocol handling for the BSS side. Since only BVC RESET and STATUS may be sent in either direction, there is not much code duplication. But the BSS side implementation cannot be used for other projects that way (e.g. for intermediaries like the gbproxy).</p>
<p>The bssgp_rcvmsg() can already be used by the BSS side to process BSSGP messages, which only makes sense for BSSGP STATUS currently.</p>
<p>TODO:</p>
<ul>
<li>Adapt the PCU functions to invoke BSSGP primaries instead of doing the PCU related action directly from within the rx functions</li>
<li>Integrate the BSS side message dispatcher into libosmocore's BSSGP stack, the cases are already there</li>
<li>Delegate the creation of BSSGP contexts (bctx) in bssgp_rx_bvc_reset to the higher layers by using (and inventing) a primary call or by modifying the semantics of the existing one (e.g. using the rc of bssgp_prim_cb to decide, whether to send ACK or STATUS)</li>
</ul> OsmoPCU - Feature #1530 (New): Assign same TFI number in downlink/uplinkhttps://osmocom.org/issues/15302016-02-22T21:03:42Zzecke
<pre>
// 12-22-2011: It looked like the Blackberry abandoned an uplink TBF when
// a downlink TBF was established using the same TFI. This seems like a horrible
// bug in the MS, but to work around it, I added the gFixTFIBug which uses
// a single TFI space for both uplink and downlink. This eliminated
// a bunch of msStop calls with cause T3101, so I think this is a genuine
// problem with MSs and we need this fix in permanently.
// Update: The TFI is reserved during the time after a downlink ends, so the MS
// may have been justifiably upset about seeing it reissued for an uplink too soon.
</pre>
<p>The above is from the OpenBTS code and we should assume this to be a valid issue. In general Jolly's code can also end-up in the situation where DL/UL think they have a common control_ts but in fact they are different. One way to resolve this would be to create a "MS" structure that holds IMSI, TLLI, TFI a pointer to the UL TBF and one to the DL (we don't support multiple TBF anyway). This way we could make sure the reservation is done in the right way.</p> OsmoBSC - Bug #68 (New): ipaccess-config should work with -u ID -o IP -r BTS_IPhttps://osmocom.org/issues/682016-02-19T22:47:33Z
<p>Right now setting both the unit id and the OML address does not work. The BTS is restarted after the first ack. There should be some kind of job queue.. or at least an ACK counter.</p> OsmoBSC - Bug #69 (New): No timers for various callshttps://osmocom.org/issues/692016-02-19T22:47:33Z
<p>Testing with the <a class="wiki-page new" href="https://osmocom.org/projects/osmobsc/wiki/FakeBTS">FakeBTS</a> has shown various issues. This could be split into several tickets if we ever start to do something about it:</p>
<p>1.) It is possible to send MDCX without a CRCX (in case the bts/ms does not respond to the channel mode modify)</p>
<p>2.) Not sending mode modify ack from the BTS triggers T10 but the channel is not taken down.</p> OsmoNITB - Bug #70 (New): nitb crashes in the rtp_proxy when a phone on a MT-call sends a 'CONNEC...https://osmocom.org/issues/702016-02-19T22:47:33Z
<p>Using the <a class="wiki-page new" href="https://osmocom.org/projects/osmonitb/wiki/FakeBTS">FakeBTS</a> it is possible to crash nitb on a MT-call. It appears to that if the MS sends a CALL CONFIRMED and then a CONNECT the rtp_socket is not fully setup and when one attempts to bridge them we have a crash.</p> OsmoNITB - Bug #72 (New): struct gsm_call can leak..https://osmocom.org/issues/722016-02-19T22:47:33Z
<p>During BTS testing I saw that gsm_call appears to be leaked.</p>
<p>Setup:<br />sysmoBTS... configure the bind IP wrongly so the CRCX will be NACKED..</p>
<p>Place a call to an unattached subscriber. Hangup immediately after placing the call, sometimes wait for the network error indication. This was tested with a E71.</p>
<pre>
gsm_call contains 560 bytes in 29 blocks (ref 0) 0x865d318
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x87c7040
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8711a90
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x87c7428
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8781168
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8716218
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8711ea8
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x87c9d28
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x87aed50
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x87819e0
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8711c28
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8711f28
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8713a20
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x87139d8
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8713990
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8713948
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8716e88
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8716e40
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8716df8
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8787668
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x872b1d8
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8781da0
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8716090
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8713b90
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x872bf70
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8713a98
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8716048
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x87289c8
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8711fe8
</pre> OsmoBSC - Bug #73 (New): Kill the paging_init_if_needed method in paging.chttps://osmocom.org/issues/732016-02-19T22:47:33Z
<p>We should call this function after the bts is created. This needs to work even when adding BTS during the runtime of the application.</p> OsmoBTS - Bug #57 (New): sysmobts L1 is not properly closed, DSP firmware reload is requiredhttps://osmocom.org/issues/572016-02-19T22:47:32Zlaforge
<p>We should investigate what is not properly closed and try to make it work again without requiring DSP firmware reload before osmo-bts restart</p> OsmoBTS - Feature #61 (New): osmo-bts: split TRAU/RTP frame handling into separate processhttps://osmocom.org/issues/612016-02-19T22:47:32Zlaforge
<p>it would be great to only deal with signalling inside the osmo-bts process, pushing all RTP/TCH handling into a separate process similar to a media gateway.</p>
<p>The main process then just sends control commands to the RTP/TCH process, particularly once the BSC instructs us to change/bind/connect the RTP socket related settings.</p>
<p>Our sysmobts L1 can already put the TCH related messages into a separate queue, keeping control with the main queue.</p> OsmoNITB - Bug #21 (New): we don't see CHANnel ReQireD from motorola EZX phones at call setuphttps://osmocom.org/issues/212016-02-19T22:47:31Zlaforge
<p>This is very weird. The EZX phones like E6, A1200, etc. can do a successful LOCATION UPDATING procedure, but after they are registered they can only process incoming calls.</p>
<p>so paging request is working, and the channel request procedure is working as part of the paging request and the location updating.</p>
<p>IF you want to start a MO call, we never see any channel required (i.e. RACH burst).</p> OsmoMSC - Feature #25 (New): Call HOLD / RETRIEVE support for internal MNCChttps://osmocom.org/issues/252016-02-19T22:47:31Zlaforge
<p>We don't do HOLD/RETRIEVE of calls so far.</p> OsmoNITB - Bug #28 (New): Old siemens phones cannot make voice calls (04.08 channel mode)https://osmocom.org/issues/282016-02-19T22:47:31Zlaforge
<p>Some older Siemens phones, notably the S11, implicitly reject the 04.08 CHANNEL MODE MODIFY from signalling to VOICE mode, thus all<br />voice calls fail.</p>
<p>Either they do not support very early assignment, or we are sending the mode modify a bit too soon for their state machines.</p> OsmoSGSN - Feature #33 (New): real LLC implementation with fragmentation and re-transmissionshttps://osmocom.org/issues/332016-02-19T22:47:31Zlaforge
<p>real LLC implementation with fragmentation and re-transmissions</p> OsmoBSC - Feature #39 (New): Logging filter on bts/trx or suchhttps://osmocom.org/issues/392016-02-19T22:47:31Z
<p>Be able to filter messages for a certain BTS/GSM/TRX...</p> OsmoNITB - Feature #18 (New): store last location identity to databasehttps://osmocom.org/issues/182016-02-19T22:47:30Zlaforge
for every location update request we get, we should store the info in the db:
<ul>
<li>the previous TMSI, if it is contained</li>
<li>the mnc/mcc/location area of the previous registration</li>
<li>a timestamp</li>
</ul>
<p>it would be great to introduce a new table for this, so we can store any number of those events<br />for any given IMEI and thus create a history.</p>