Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092016-02-23T15:38:30ZOpen Source Mobile Communications
Redmine 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 #1568 (New): Move various code bits to libosmocorehttps://osmocom.org/issues/15682016-02-23T15:28:32Zlaforge
<p>There are plenty of FIXMEs in src/common.c about code that should be moved to libosmocore as a clean-up</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 #1558 (New): Generate BSSGP LLC Discarded messages on TBF/MS freehttps://osmocom.org/issues/15582016-02-23T15:15:01Zlaforge
<p>If a TBF is freed (e.g. caused by timeout or replacement), the dropped (unsent/unacknowledged) RLC frames are silently dropped. If an MS object is freed (TBF creation failed during the timeout interval), the dropped LLC frames are also not reported. At least counters should be implemented for these cases.</p>
<p>It's a violation of the spec. OsmoSGSN doesn't care, but if you interface with other SGSNs, they might expect to receive such messages in order to optimize their flow control and/or QoS.</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 #1533 (Feedback): Separate the window handling from the TBF more clearlyhttps://osmocom.org/issues/15332016-02-22T21:07:23Zzecke
<p>**The window handling can be more clearly separated from the TBF. This includes clean-ups to the ::assemble_forward_llc. The general multitude of calling dir.dl.window.m_v_b anddir.dl.window.increment_send.</p> OsmoPCU - Bug #1532 (New): Increased number of poll timeouts on shared PDCHshttps://osmocom.org/issues/15322016-02-22T21:06:14Zzecke
<p>**There seems to be an increased number of poll timeouts if TBFs share a single PDCH in comparison to completely separated TBFs (no common PDCH). Interestingly there haven't been any SBA timeouts (at least I did not see any in the statistics I have looked at so far).</p>
<p>The MS recover without problems, at least when using 2 MS only. This might be different with a large number of MS and an increased probability for collisions.</p>
<p>It might be a frame usage/allocation issue, e.g. 2 MS sending frames simultaneously.</p>
<p>More testing and analysis is needed.</p>
<pre><code>Osmo-PCU> show bts statistics<br />BTS Statistics:<br /> TBF DL Allocated : 13 (0/s 0/m 0/h 0/d)<br /> TBF DL Freed : 12 (0/s 0/m 0/h 0/d)<br /> TBF UL Allocated : 363 (0/s 0/m 0/h 0/d)<br /> TBF UL Freed : 363 (0/s 0/m 0/h 0/d)<br /> TBF Reused : 1 (0/s 0/m 0/h 0/d)<br /> RLC Sent : 36706 (0/s 0/m 0/h 0/d)<br /> RLC Resent : 10385 (0/s 0/m 0/h 0/d)<br /> RLC Restarted : 4304 (0/s 0/m 0/h 0/d)<br /> RLC Stalled : 93 (0/s 0/m 0/h 0/d)<br /> RLC Nacked : 40 (0/s 0/m 0/h 0/d)<br /> RLC Assign Timeout : 8 (0/s 0/m 0/h 0/d) <<<<br /> RLC Ack Timeout : 63 (0/s 0/m 0/h 0/d) <<< <br /> RLC Release Timeout : 0 (0/s 0/m 0/h 0/d)<br /> Decode Errors : 0 (0/s 0/m 0/h 0/d)<br /> SBA Allocated : 8 (0/s 0/m 0/h 0/d)<br /> SBA Freed : 8 (0/s 0/m 0/h 0/d)<br /> SBA Timeout : 0 (0/s 0/m 0/h 0/d) <<<<br /> Timedout Frames : 3 (0/s 0/m 0/h 0/d)<br /> Dropped Frames : 3 (0/s 0/m 0/h 0/d)<br /> Scheduled Frames : 2782 (0/s 0/m 0/h 0/d)<br /> RACH requests : 8 (0/s 0/m 0/h 0/d)</code></pre> 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> OsmoPCU - Bug #1528 (New): Find a real fix for EGPRS_AckNack_w_len_t decodinghttps://osmocom.org/issues/15282016-02-22T21:01:50Zzecke
<p>Refers to commit: 'edge: Workaround to fix decoding of EGPRS_AckNack_w_len_t'</p>
<p>The presence of the LENGTH field adds an additional offset which breaks the related M_SERIALIZE in gsm_rlcmac.cpp. In that case, the Desc in EGPRS_AckNack_t is being cast to EGPRS_AckNack_w_len_t and then ((EGPRS_AckNack_w_len_t *)Desc)->Desc is filled with the<br />parsed data, which is a platform dependant number of bytes apart the real Desc struct.</p>
<p>That commit removes the LENGTH field from EGPRS_AckNack_w_len_t so that the Desc field is the first field.</p>
<p>Note that this is not a real fix. The rlcmac wireshark dissector<br />still has the same declaration but doesn't seem to suffer from this<br />problem. So there is probably some other bug.</p> OsmoPCU - Feature #1527 (New): Set correct values of the puncturing scheme and the retransmission...https://osmocom.org/issues/15272016-02-22T21:00:53Zzecke
<p>The puncturing scheme and the RBS flag must be set according to certain rules in TS 44.060 (9.1.3.2, 9.3.2.1, ...). Currently they puncturing scheme 1 is always used and RBS is always 0. It must be updated and remembered per BSN. The RBS flag must be set, if at least one BSN data block in the RLC block is being retransmitted.</p> SIMtrace 2 - Feature #1457 (New): Spacing between JTAG and JP1/JP2https://osmocom.org/issues/14572016-02-19T22:48:42Z
<p>On v1.0 and v1.1 the spacing between JTAG and JP1/JP2 (erase, test) could be higher. Right now the JTAGkey is a bit blocked by JP1/JP2.</p> SIMtrace 2 - Feature #1463 (New): Add VCC current sensing circuit for SPA & DPA attackshttps://osmocom.org/issues/14632016-02-19T22:48:42Z
<p>It would be pretty good to be able to sense current going to the SIM.</p>
<p>The simple idea is to measure current like this :</p>
<pre>
A B
o o
| |
pwr >----/\/\/\----> to SIM
|
=
|
#
</pre>
<ul>
<li>Ideally use a '4 wire' resistor to make sure you have precision measurement.</li>
<li>Choose value appropriately depending on a typical smart card power consumption.</li>
</ul>
<p>Now, I would include added circuitery to make measurements easier.<br />Because in the simple form there are a couple of issue:</p>
<p>First the signal is gonna be pretty small.<br />Second is that to measure the current across the resistor you can't just put the gnd of your probe on A and the tip on B. That's because the GND of the scope is connected to earth of the mains supply, which in turn is connected to the GND on the PC and so the GND of the simtrace ...</p>
<p>You can either:<br /> - Use two scope probe and use A - B function but this has often less functions that a single probe channel. Also if you only have a 2 channel scope you can't monitor anything else (like the clk line or something).<br /> - Simply probe one point: But then you have the supply noise added to your measurement noise and you don't have absolute values.<br /> - Use a differential probe: Great option ... if you have a couple more k$ to buy one.</p>
<p>So ... all of these suck.</p>
<p>We could have an difference amplifier onboard, however, finding one with multi-MHz bandwidth isn't trivial and they all need dual power rails.</p>
<p>(sorry for the rambling, I'm thinking while writing the ticket ...)</p>
<p>Note that since this feature in its more advanced form may involve expensive / complex components and only be used by very few people. so it could be mounted as a simple 0R with other pad left to be mounted manually by the interested parties.</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>