https://osmocom.org/https://osmocom.org/favicon.ico?16647414092016-02-23T15:21:16ZOpen Source Mobile CommunicationsOsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=10292016-02-23T15:21:16Zlaforge
<ul><li><strong>Estimated time</strong> set to <i>12:00 h</i></li></ul>OsmoBTS needs to be extended to
<ul>
<li>parse the IPA specific RSL message for dynamic PDCH activation/deactivation</li>
<li>perform the required timeslot configuration changes towards the L1 (for all supported PHYs)<br />*|send the PCU_IF_MSG_INFO_IND message with the updated PDCH timeslot bit-map once the number of PDCH changes</li>
</ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=10302016-02-23T15:21:39Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-high2 closed behind-schedule" href="/issues/1551">Feature #1551</a>: dynamic timeslot allocations (TCH / SDCCH vs PDCH)</i> added</li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=10332016-02-23T15:23:01Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-high2 closed behind-schedule" href="/issues/1566">Feature #1566</a>: Dynamic PDCH / TCH switching: PCU part</i> added</li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=10352016-02-23T15:26:36Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-2 priority-default closed behind-schedule" href="/issues/1567">Feature #1567</a>: Dynamic PDCH / TCH switching: BSC part</i> added</li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=13232016-05-04T14:20:58Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=13652016-05-09T18:50:46Zlaforge
<ul><li><strong>Due date</strong> set to <i>06/10/2016</i></li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=13942016-05-09T19:38:21Zlaforge
<ul><li><strong>Priority</strong> changed from <i>High</i> to <i>Urgent</i></li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=14082016-05-10T11:44:29Zlaforge
<ul><li><strong>Assignee</strong> set to <i>neels</i></li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=14682016-05-24T11:32:53Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Subject</strong> changed from <i>Dynamic PDCH / TCH switching</i> to <i>Dynamic PDCH / TCH switching: BTS part</i></li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=14802016-05-31T15:00:24Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>File</strong> <i>two_calls_then_gprs_starts_working.patch</i> added</li><li><strong>File</strong> <i>two_calls_then_gprs_starts_working.nitb.log</i> added</li><li><strong>File</strong> <i>two_calls_then_gprs_starts_working.pcapng</i> added</li><li><strong>% Done</strong> changed from <i>0</i> to <i>20</i></li></ul><p>(comment moved to <a class="issue tracker-2 status-5 priority-2 priority-default closed behind-schedule" title="Feature: Dynamic PDCH / TCH switching: BSC part (Closed)" href="https://osmocom.org/issues/1567">#1567</a>)</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=14852016-05-31T15:02:26Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=14872016-05-31T15:50:47Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>(comment moved to <a class="issue tracker-2 status-5 priority-2 priority-default closed behind-schedule" title="Feature: Dynamic PDCH / TCH switching: BSC part (Closed)" href="https://osmocom.org/issues/1567">#1567</a>)</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15132016-06-02T10:11:37Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>20</i> to <i>30</i></li></ul><p>(comment moved to <a class="issue tracker-2 status-5 priority-2 priority-default closed behind-schedule" title="Feature: Dynamic PDCH / TCH switching: BSC part (Closed)" href="https://osmocom.org/issues/1567">#1567</a>)</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15142016-06-02T11:55:06Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>(comment moved to <a class="issue tracker-2 status-5 priority-2 priority-default closed behind-schedule" title="Feature: Dynamic PDCH / TCH switching: BSC part (Closed)" href="https://osmocom.org/issues/1567">#1567</a>)</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15152016-06-02T12:55:57Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>First, I will take a look at how sysmoBTS may handle TCH/F_PDCH.<br />(Starting with getting to know the sysmoBTS code.)<br />Hints at specific code may be helpful.</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15312016-06-06T14:03:40Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>30</i> to <i>10</i></li></ul><ul>
<li>in oml_rx_set_chan_attr() we receive the user's pchan conf</li>
<li>TCH/F_PDCH chans should probably be set to GsmL1_LogChComb_II initially,<br /> so they come up as TCH/F like in the ip.access nanobts.<br /> (osmo-bsc then sends PDCH ACT upon RSL UP, making them PDTCH)</li>
<li>in rsl_rx_dchan() we receive an IPACC_PDCH_DEACT at some point</li>
<li>in the common/ part, we should check whether the original config was indeed TCH/F_PDCH</li>
<li>then using bts_model_* phy-specific API, we
<ul>
<li>probably need to MPH-DISCONNECT-REQ and</li>
<li>MPH-CONNECT-REQ with logChComb == PDTCH/F+PACCH/F+PTCCH/F</li>
</ul>
</li>
<li>possibly followed by pdtch_sapis[] activation</li>
</ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15322016-06-06T14:12:43Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>File</strong> deleted (<del><i>two_calls_then_gprs_starts_working.patch</i></del>)</li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15332016-06-06T14:12:46Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>File</strong> deleted (<del><i>two_calls_then_gprs_starts_working.nitb.log</i></del>)</li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15342016-06-06T14:12:49Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>File</strong> deleted (<del><i>two_calls_then_gprs_starts_working.pcapng</i></del>)</li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15372016-06-07T00:13:33Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>10</i> to <i>30</i></li></ul><p>initial implementation for sysmo-bts is complete and up for testing<br />(not yet pushed anywhere).</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15442016-06-08T15:42:39Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>The openbsc code that works for the ip.access nanobts doesn't work for sysmoBTS so far,<br />because the initial PDCH ACT for each TCH/F_PDCH TS is sent before the SET_CHAN_ATTR is even sent.</p>
<p>So the BTS can't know yet that the PDCH ACT sent for a given TS is indeed for a TCH/F_PDCH TS.</p>
<p>osmo-bts-sysmo complains about it.</p>
<p>So far I couldn't find a neat hook to send the PDCH ACT at the right time,<br />because it would be an RSL message depending on the NM message for setting<br />PCHAN types to be completed.</p>
<p>Also, for ip.access and sysmoBTS, the SET_CHAN_ATTR part is apparently "hidden" <br />in bts_ipaccess_nanobts.c, but I would prefer to keep it more general.</p>
<p>I don't really like this solution that much, but it seems the best way is to have<br />a "PDCH ACT pending" flag in sysmoBTS to allow receiving PDCH ACT even before the<br />PCHAN types are received.</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15452016-06-09T16:49:02Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>30</i> to <i>50</i></li></ul><p>Today's <strong>SysmoBTS</strong> testing concluded partially successfully.<br />I got both voice and GPRS to work with a TCH/F_PDCH configuration.<br />There is still the following problem with voice:</p>
<p>(TS 0 CCCH+SDCCH4 and TS 1 SDCCH8, when I say "all", I mean the remaining six TS)</p>
<p><strong>With only TCH/F_PDCH channels available</strong></p>
<ul>
<li>initially, voice calls can be placed</li>
<li>GPRS is functional</li>
<li>as soon as GPRS is used, however, further voice calls are not possible<br /><pre>
<0004> abis_rsl.c:1458 BTS 0 CHAN RQD: no resources for TCH/F 0x2b
</pre></li>
</ul>
<p>This makes sense if one expects all channels to be grabbed by GPRS.</p>
<p>However, I'm kind of expecting voice to start working again when GPRS is no longer in use,<br />not really sure yet how this would work, though.</p>
<p>Also, this seems to not be entirely reproducable.</p>
<p><strong>With one TS as TCH/F and all others as TCH/F_PDCH:</strong></p>
<ul>
<li>I have the exact same situation.</li>
</ul>
<p>I'm expecting voice to always work now,<br />since one TS is reserved for TCH/F, yet voice stops working completely<br />as soon as data has been used once.</p>
<p><strong>With at least two TCH/F and at least one TCH/F_PDCH:</strong></p>
<ul>
<li>both voice and data work well regardless of GPRS being used.</li>
</ul>
<p>Todo: check these cases on the ip.access nanobts</p>
<p>Todo:<br /><pre><0002> tbf.cpp:340 TBF(TFI=0 TLLI=0xca6de331 DIR=DL STATE=RELEASING) Software error: Pending uplink assignment. This may not happen, because the assignment message never gets transmitted. Please be sure not to free in this state. PLEASE FIX!</pre></p>
<p>Todo: It seems not all TCH/F_PDCH are enabled properly.<br />In a situation where 3..7 are TCH/F_PDCH, random ones, like TS 3 and 5, don't list as PDCH.<br />Is there some race?</p>
<p>Todo: the code is on a private branch and still needs to be groomed & submitted.</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15462016-06-09T19:31:23Zlaforge
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>However, I'm kind of expecting voice to start working again when GPRS is no longer in use,<br />not really sure yet how this would work, though.</p>
</blockquote>
<p>There is no notion of "GPRS no longer in use". You either</p>
<p>a) always have to keep at least one TCH/F free/available, and reduce the number of PDCH every time you allocate the last TCH/F, or</p>
<p>b) modify the channel alloctor in the BSC to DEACTIVATE a PDCH when we try to allocate a TCH channel in response ot a RACH request (= RSL CHAN REQUIRED), i.e. in lchan_alloc. Please note there are several reasons why we would want to allocate a circuit-switched channel, e.g. hand-over, CHAN RQD, ... As none of the related code expects to be delayed (i.e. a synchronous response to lchan_alloc() is expected), it might be best to go for option a).</p>
<blockquote>
<p><strong>With one TS as TCH/F and all others as TCH/F_PDCH:</strong></p>
<ul>
<li>I have the exact same situation.</li>
</ul>
<p>I'm expecting voice to always work now,<br />since one TS is reserved for TCH/F, yet voice stops working completely<br />as soon as data has been used once.</p>
</blockquote>
<p>this sounds like you're not properly releasing channels after use? Please confirm in "show lchan" and RSL protocol traces.</p>
<blockquote>
<p>Todo: It seems not all TCH/F_PDCH are enabled properly.<br />In a situation where 3..7 are TCH/F_PDCH, random ones, like TS 3 and 5, don't list as PDCH.<br />Is there some race?</p>
</blockquote>
<p>It definitely sounds like three are some bugs left...</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15472016-06-10T12:10:57Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Testing ip.access nanobts:</p>
<p>1x TCH/F, 5x TCH/F_PDCH<br />and<br />5x TCH/F, 1x TCH/F_PDCH</p>
<p>behave the same as described in <a class="issue tracker-1 status-6 priority-1 priority-lowest closed" title="Bug: ip.access nanobts: phone cannot be called while actively downloading (Rejected)" href="https://osmocom.org/issues/1747">#1747</a>:</p>
<ul>
<li>both voice and data bascially work</li>
</ul>
<ul>
<li>however, while a phone keeps using GPRS (continuously downloading),<br /> the other phone cannot place calls.</li>
</ul>
<p>I first thought this was due to dyn pdch changes, but since the same behavior<br />happens with a master branch build, I now assume that the dyn pdch changes to<br />openbsc don't break normal ip.access nanobts behavior.</p>
<p>Typically, I expect GPRS service to be stopped when a phone is being called,<br />as seen yesterday with a sysmoBTS:</p>
<ul>
<li>The active web page download was stopped and the phone started ringing;</li>
<li>after the call was done, a web page reload completed the download.</li>
</ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15482016-06-10T12:13:31Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>The openbsc code that works for the ip.access nanobts doesn't work for sysmoBTS so far,<br />because the initial PDCH ACT for each TCH/F_PDCH TS is sent before the SET_CHAN_ATTR is even sent.</p>
</blockquote>
<p>This was resolved by sending PDCH ACT upon <del>the OPSTART</del> a State Change to Enabled for a TS is received by the BSC,<br />separately for each TS.</p>
<p>Today I verified that the ip.access nanobts' dyn pdch is still working with this fix.</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15512016-06-10T12:52:52Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>Todo: It seems not all TCH/F_PDCH are enabled properly.<br />In a situation where 3..7 are TCH/F_PDCH, random ones, like TS 3 and 5, don't list as PDCH.<br />Is there some race?</p>
</blockquote>
<p>The problem is in the cb & data arguments for l1if_gsm_req_compl(fl1h, msg, opstart_compl_cb, data);<br />When l1if_gsm_req_compl calls interleave, data args returned to cb() get mixed up.<br />Debug output shows that TS 6's data arg is passed to TS 5's callback:</p>
<pre>
▶ grep -i '[ <]--[> ]' bts.log.5
<0006> oml.c:521 --> TS 0 data 0xb0080 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 0 data 0xb0080 dyn_pdch (nil)
<0006> oml.c:521 --> TS 1 data 0xb00f0 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 1 data 0xb00f0 dyn_pdch (nil)
<0006> oml.c:521 --> TS 2 data 0xb0160 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 2 data 0xb0160 dyn_pdch (nil)
<0006> oml.c:521 --> TS 2 data 0xb0218 dyn_pdch 0xb0160
<0006> oml.c:271 <-- TS 2 data 0xb0218 dyn_pdch 0xb0160
<0006> oml.c:521 --> TS 3 data 0xb1590 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 3 data 0xb1590 dyn_pdch (nil)
<0006> oml.c:521 --> TS 3 data 0xb3768 dyn_pdch 0xb1590
<0006> oml.c:271 <-- TS 3 data 0xb3768 dyn_pdch 0xb1590
<0006> oml.c:521 --> TS 4 data 0xb28a8 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 4 data 0xb28a8 dyn_pdch (nil)
<0006> oml.c:521 --> TS 5 data 0xb28a8 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 5 data 0xb28a8 dyn_pdch (nil)
<0006> oml.c:521 --> TS 4 data 0xb2758 dyn_pdch 0xb28a8
<0006> oml.c:271 <-- TS 4 data 0xb2758 dyn_pdch 0xb28a8
<0006> oml.c:521 --> TS 5 data 0xb5860 dyn_pdch 0xb1720 [<- this]
<0006> oml.c:521 --> TS 6 data 0xb4ac8 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 5 data 0xb4ac8 dyn_pdch (nil) [<- mismatches this]
<0006> oml.c:271 <-- TS 6 data 0xb5860 dyn_pdch 0xb1720
<0006> oml.c:521 --> TS 7 data 0xb39d0 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 7 data 0xb39d0 dyn_pdch (nil)
<0006> oml.c:521 --> TS 6 data 0xb5690 dyn_pdch 0xb1720
<0006> oml.c:271 <-- TS 6 data 0xb5690 dyn_pdch 0xb1720
</pre>
<p>Will try to find the cause now.</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15522016-06-10T13:01:31Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>Will try to find the cause now.</p>
</blockquote>
<p>osmo-bts/src/osmo-bts-sysmo/l1_if.c:<br /><pre>
static inline int is_prim_compat(GsmL1_Prim_t *l1p, struct wait_l1_conf *wlc)
{
/* the limitation here is that we cannot have multiple callers
* sending the same primitive */
</pre></p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15602016-06-10T14:25:47Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>neels wrote:</p>
<blockquote>
<p>Will try to find the cause now.</p>
</blockquote>
<p>osmo-bts/src/osmo-bts-sysmo/l1_if.c:<br />[...]</p>
</blockquote>
<p>We agreed on using the hLayer3 handle to identify primitive confirmations (todo).</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15612016-06-10T14:33:02Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>sysmoBTS is partially working.</p>
<p>Some Bugs need to be resolved, but the dynamic PDCH feature is working in principle.</p>
<p>The code is still in a private git repository.<br />I will groom over it once more and push to gerrit soon.</p>
<p>litecell and osmo-trx: not started yet.</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=15902016-06-13T23:08:47Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>sysmoBTS is partially working.</p>
<p>Some Bugs need to be resolved, but the dynamic PDCH feature is working in principle.</p>
</blockquote>
<p>Above conclusion was based on bad initialisation of channels. After this fix: <a class="external" href="https://gerrit.osmocom.org/264">https://gerrit.osmocom.org/264</a><br />the TCH/F_PDCH channels are set up properly, and proper PDCH deactivation + TCH/F activation are actually<br />required for the first time. (Before, wrongly initialized channels took over the TCH/F.)</p>
<p>Data service is functional with TCH/F_PDCH channels, but dynamic switchover to TCH/F is not working yet with sysmoBTS.</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=16042016-06-14T10:08:02Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>In the current state, the order of messages is wrong.<br />I was hoping to get switchover working with some broken edge cases,<br />but indeed I need to fix so that:</p>
<ul>
<li>when the BSC asks for PDCH deactivation, </li>
<li>first store PDCH deact state on that timeslot and send pcu_tx_info_ind(),</li>
<li>when the PCU answers with a channel deactivation, look up the PDCH deact state,</li>
<li>only then start the phy channel deactivation,</li>
<li>and finally after successful deact, respond to the BSC with a PDCH DEACT ACK,</li>
<li>so that the BSC carries on to activate the new state after that.</li>
</ul>
<p>(For simplicity, I tried to first switch off phy, then tell the PCU and BSC<br />about it at the same time; thus the BSC already carries on to activate the<br />new state while the PCU still asks to deactivate the old state... doesn't work.)</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=16052016-06-14T10:11:39Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>neels wrote:</p>
<blockquote>
<p>neels wrote:</p>
<blockquote>
<p>Will try to find the cause now.</p>
</blockquote>
<p>osmo-bts/src/osmo-bts-sysmo/l1_if.c:<br />[...]</p>
</blockquote>
<p>We agreed on using the hLayer3 handle to identify primitive confirmations (todo).</p>
</blockquote>
<p>update: this is fixed in <a class="external" href="https://gerrit.osmocom.org/264">https://gerrit.osmocom.org/264</a></p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=16132016-06-16T03:16:00Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>50</i> to <i>80</i></li></ul><p>sysmoBTS: on TCH/F_PDCH TS, dynamic switchover from PDCH to TCH/F is now working.<br />Per default, dynamic TCH/F_PDCH channels operate as PDCH for data services.<br />As voice calls come up, they are converted to TCH/F, and back to PDCH on hangup.</p>
<p>Most of the switchover logic is in fact implemented in the common/ part of osmo-bts.<br />Two simple functions need to be added specific to BTS models -- bts_model_ts_disconnect()<br />and bts_model_ts_connect() -- and two hooks need to be called after connect/disconnect.</p>
<p>Commits <strong>preparing</strong> the implementation are waiting for approval in gerrit,<br />5 patches up to <a class="external" href="https://gerrit.osmocom.org/295">https://gerrit.osmocom.org/295</a>.</p>
<p>The implementation itself is still in a private repository as one large change;<br />while the acceptance of the preparing patches is pending, I will split it into<br />smaller bits for review.</p>
<p>I would also like to do some further testing of cases where the amount of available<br />channels is exhausted. If all TS were TCH/F_PDCH, I expect voice calls to "push away" <br />GPRS until data service is stopped completely, but haven't tested yet.</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=16142016-06-16T03:16:51Zneelsnhofmeyr@sysmocom.de
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>sysmoBTS</i> added</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>litecell15</i> added</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>trx</i> added</li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=16252016-06-17T02:28:46Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>the sysmoBTS implementation of dyn PDCH is now completely submitted for review:<br /><a class="external" href="https://gerrit.osmocom.org/311">https://gerrit.osmocom.org/311</a></p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=16282016-06-17T18:15:54Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>The sysmoBTS dyn PDCH feature has been merged to osmo-bts master.</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=16322016-06-21T16:35:32Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>The most recent developments on osmo-bts-lc15 on the master branch don't<br />work with our litecell 1.5 hardware as it is configured right now.<br />In particular, the numbering scheme of /dev/msgq/litecell15_dsp2arm_trx*<br />has changed from 1,2 to 0,1. Until an update on the firmware arrives<br />with us, I'm branching off an earlier revision to implement dyn PDCH.</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=16332016-06-21T20:09:44Zneelsnhofmeyr@sysmocom.de
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>litecell15</i> set to Done</li><li><strong>% Done</strong> changed from <i>80</i> to <i>90</i></li></ul><p>dynamic PDCH is now implemented for litecell 1.5,<br />highly similar to the sysmoBTS implementation.</p>
<p>The implementation is waiting for approval at <a class="external" href="https://gerrit.osmocom.org/396">https://gerrit.osmocom.org/396</a><br />(and preceding submissions on the same topic)</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=17762016-07-11T13:35:35Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>The osmo-bts-trx implementation of this turns out to be less straightforward than the others.<br /><a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: osmo-bts-trx goes through OML initialization twice (Closed)" href="https://osmocom.org/issues/1770">#1770</a> got in the way, next I need to find out why my patch so far is not sufficient.<br />(branch osmo-bts.git:neels/dyn_pdch_trx)</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=19092016-07-26T17:10:02Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Finally, the problem that stalled dynamic PDCH on osmo-trx has been resolved.<br />Left to do: polish the patches and submit for review.</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=19462016-07-28T14:44:59Zlaforge
<ul><li><strong>Target version</strong> set to <i>Dynamic TCH/H TCH/F PDCH</i></li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=19592016-07-29T17:26:52Zlaforge
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>trx</i> set to Done</li><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul><p>I believe this should have been closed. Please make sure tickets alwas reflect reality.</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=19722016-08-01T07:37:39Zlaforge
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Closed</i></li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=20362016-08-09T18:48:42Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>Closed</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>100</i> to <i>90</i></li></ul><p>I still had some things waiting in the queue, the 90% was intentional.<br />More accurate would be 99%, but indeed TCH/F_TCH/H_PDCH for osmo-trx is not yet in master.</p>
<p>While testing the last 1%, I noticed that a recent commit actually breaks dynamic<br />timeslots on SysmoBTS. See <a class="external" href="https://gerrit.osmocom.org/671">https://gerrit.osmocom.org/671</a></p>
<p>So I'm reopening this until all issues are resolved and all features merged.</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=20432016-08-10T17:35:52Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-2 priority-default closed" href="/issues/1796">Bug #1796</a>: PTCCH activation breaks dyn TS</i> added</li></ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=20452016-08-10T17:45:54Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>The regression that breaks dyn ts is discussed in <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: PTCCH activation breaks dyn TS (Closed)" href="https://osmocom.org/issues/1796">#1796</a>.<br />Only marginal patches are still waiting for merge to master.<br />So I'd say this is 99.9% Done...</p>
<p>I must say I am slightly confused by which ticket refers to which kind of dynamic timeslots.<br />Anyway:</p>
<ul>
<li>TCH/F_TCH/H_PDCH has been committed for osmo-bts-trx, so now working for lc15 and trx.</li>
<li>TCH/F_PDCH also working for lc15, trx.</li>
<li>sysmo is working with the revert proposed in <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: PTCCH activation breaks dyn TS (Closed)" href="https://osmocom.org/issues/1796">#1796</a>.</li>
<li>The patches still waiting for submission concern
<ul>
<li>channel load indication <a class="external" href="https://gerrit.osmocom.org/667">https://gerrit.osmocom.org/667</a></li>
<li>ts measurement <a class="external" href="https://gerrit.osmocom.org/675">https://gerrit.osmocom.org/675</a>
<ul>
<li>which depends on <a class="external" href="https://gerrit.osmocom.org/669">https://gerrit.osmocom.org/669</a></li>
</ul>
</li>
<li>correct pchan handling in ph_data_req(), actually without known misbehavior <a class="external" href="https://gerrit.osmocom.org/677">https://gerrit.osmocom.org/677</a>
<ul>
<li>which follows 675 and thus also indirectly depends on <a class="external" href="https://gerrit.osmocom.org/669">https://gerrit.osmocom.org/669</a></li>
</ul></li>
</ul></li>
</ul> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=20992016-08-30T12:06:39Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul><p>All patches discussed above are merged.<br />Another about stability in absence of a PCU is still waiting, <a class="external" href="https://gerrit.osmocom.org/748">https://gerrit.osmocom.org/748</a><br />but closing this issue (new details should be new issues).</p> OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS parthttps://osmocom.org/issues/1565?journal_id=21092016-08-30T17:04:31Zlaforge
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Closed</i></li></ul>