https://osmocom.org/https://osmocom.org/favicon.ico?16647414092016-07-13T13:29:06ZOpen Source Mobile CommunicationsOsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18332016-07-13T13:29:06Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>I thought <a class="issue tracker-1 status-5 priority-4 priority-high2 closed" title="Bug: dynamic TCH/F + TCH/H allocation (Closed)" href="https://osmocom.org/issues/1564">#1564</a> was about this?</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18362016-07-13T17:27:46Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>(copying from <a class="issue tracker-2 status-5 priority-4 priority-high2 closed" title="Feature: determine strategy for fully dynamic PDCH, TCH/F and TCH/H channel (Closed)" href="https://osmocom.org/issues/1757">#1757</a>)</p>
<p>Things to be done and working hours needed as estimated:</p>
<p>1. <strong>Adjust general structures</strong> (1h)</p>
<p>1.1 enum gsm_phys_chan_config: GSM_PCHAN_DYN</p>
<p>1.2 struct gsm_lchan: state machine for chan type transitions</p>
<p>2. <strong>openbsc</strong> (12h total, optional +16h)</p>
<p>2.1 initialization as PDCH: question: implicit or explicit?</p>
<ul>
<li>For reference: in ip.access TCH/F_PDCH, default type is TCH/F, and<br /> nm_statechg_event() sends PDCH ACT immediately after init.<br /> We could do the same: in the BTS code, initialize as TCH/F, and in<br /> nm_statechg_event() trigger a channel state transition to PDCH.</li>
<li>This feels very heavy on messages though, we could just imply on the<br /> BTS side that a DYN channel always starts off as PDCH --> no further<br /> initialization messages needed from the BSC side.</li>
<li>How does the ericsson BTS expect this?</li>
</ul>
<p>2.2 lchan_alloc(): pick and switch dyn channels (4h)</p>
<p>The initial strategy for picking channels will be fairly straightforward in<br />that a TS will be picked iff it is fully available. More complex scenarios may<br />be solved by implementing the TS defragmentation as in 2.4 below.</p>
<ul>
<li>pick matching dedicated pchan first if available</li>
<li>TCH/H: pick second TCH/H if such TS is used only by half</li>
<li>otherwise pick DYN TS that is in PDCH mode and switch to TCH/*</li>
</ul>
<p>2.3 channel type transition steps from BSC perspective (8h)</p>
<ul>
<li>BTS indicates the need for a TCH/* channel</li>
<li>rsl_rx_chan_rq() calls lchan_alloc() and gets a DYN channel in PDCH mode</li>
<li>rsl_rx_chan_rq() then invokes rsl_chan_activate_lchan()</li>
<li>rsl_chan_activate_lchan(): detect need to change type, send chan rel</li>
<li>BTS releases channel</li>
<li>rsl_rx_rf_chan_rel_ack(): register release, send chan act in TCH/* type</li>
<li>BTS activates channel</li>
<li>rsl_rx_chan_act_ack(): register act, continue in rsl_chan_activate_lchan()</li>
<li>TCH/* is used...</li>
<li>BTS sends rel ind as usual</li>
<li>BSC sends chan rel as usual</li>
<li>rsl_rx_rf_chan_rel_ack(): notices a DYN channel is released in TCH/* mode
<ul>
<li>If half a TCH/H TS is still used, do not continue with PDCH act</li>
</ul>
</li>
<li>rsl_rx_rf_chan_rel_ack(): sends chan act in PDCH type</li>
<li>rsl_rx_chan_act_ack(): register act as PDCH, DYN available for lchan_alloc()</li>
</ul>
<p>2.4 Optional: TS defragmentation (16h)</p>
<ul>
<li>Upon each channel release, do handover within TRX to eliminate gaps</li>
<li>There is some untested defrag code adjusted from jolly in branch<br /> neels/dyn_pdch_extra</li>
<li>Possibly combine two half-used TCH/H TS</li>
</ul>
<p>3. <strong>osmo-bts common implementation</strong> (8h total)</p>
<p>3.2 channel type switching: implicit TS disconnect (4h)</p>
<ul>
<li>rsl_rx_chan_rel(): usual release will lead to l1sap_info_rel_cnf()</li>
<li>l1sap_info_rel_cnf(): disconnect DYN TS in L1, to be able to switch type
<ul>
<li>use new bts_model_ts_disconnect(), expecting disconnect callback<br /> (dyn_pdch_ts_disconnected(), probably rename to dyn_ts_disconnected)</li>
<li>in callback, continue l1sap_info_rel_cnf() to send RSL_RF_CHAN_REL ACK</li>
</ul></li>
</ul>
<p>3.3 channel type switching: implicit TS connect (4h)</p>
<ul>
<li>rsl_rx_chan_activ(): first connect DYN TS in different type
<ul>
<li>use new bts_model_ts_connect() with callback<br /> (dyn_pdch_ts_connected(), probably rename to dyn_ts_connected)</li>
<li>in callback, continue with rsl_rx_chan_activ() procedure<br /> leading to RSL_CHAN_ACTIV ACK</li>
</ul></li>
</ul>
<p>4. <strong>BTS model specific implementations</strong> (6h total + optional 4h)</p>
<ul>
<li>Implement:
<ul>
<li>bts_model_opstart(): start DYN channels in default mode (PDCH? see above)</li>
<li>ensure bts_model_ts_connect() and bts_model_ts_disconnect() are implemented</li>
</ul>
</li>
<li>on these models:
<ul>
<li>sysmoBTS (1h, because bts_model_ts_* already implemented)</li>
<li>litecell15 (1h, because bts_model_ts_* already implemented)</li>
<li>osmo-trx (4h)</li>
<li>octphy? (4h)</li>
</ul></li>
</ul>
<p>5. <strong>Testing</strong> (19.5h + optional 6.5h)</p>
<ul>
<li>Test these things (1.5h / 2.5h)
<ul>
<li>a) GPRS initially working? (.5h)</li>
<li>b) TCH/F voice working? (.5h)</li>
<li>c) TCH/H voice working? (.5h)</li>
<li>d) PDCH TS still working after it switched back from TCH/*? (.5h)</li>
<li>e) dedicated pchan preferred over DYN TS? (.5h)</li>
</ul></li>
</ul>
<ul>
<li>In these scenarios (6.5h)
<ul>
<li>1 No DYN channels (test against regressions) (a-c: 1.5h)</li>
<li>2 All channels as DYN (a-e: 2.5h)</li>
<li>3 realistic: few dedicated PDCH, all others DYN (a-e: 2.5h)</li>
</ul></li>
</ul>
<ul>
<li>On these models
<ul>
<li>sysmoBTS</li>
<li>litecell15</li>
<li>osmo-trx</li>
<li>octphy?</li>
</ul></li>
</ul>
<p>6. <strong>Effort estimation</strong></p>
<p>Summing up, I have</p>
<p>1. 1h<br />2. 12h + 16h TS defrag<br />3. 8h<br />4. 6h + 4h octphy<br />5. 19.5h + 6.5h octphy</p>
<p>Some things may not work as expected or take longer to implement, thus I would<br />like to add a grace of three days (+24h). Highest uncertainty in decreasing<br />order: octphy, osmo-trx, TS defrag, general testing, channel allocator.</p>
<p>Total: 46.5h + 24h grace + 16h TS defrag + 10.5h octphy</p>
<p>My final estimation is thus two of my working weeks (70.5h)<br />plus two days for TS defrag and another generous day for octphy,<br />say three weeks for the whole package.</p>
<p>I hope this estimate makes sense to you. It is hard to estimate software<br />engineering progress in advance; while I don't want to stop the show with huge<br />numbers, it usually turns out realistic to estimate generously.</p>
<p>I am mildly optimistic in this case since I'm familiar with most of the<br />implementations from the recent addition of IPAC_PDCH_[DE]ACT on ip.access<br />nanobts, SysmoBTS and litecell15.</p>
<p>OTOH I am not yet familiar with osmo-trx at all and have minimal experience<br />with octphy. I would still need to set up a tool chain and test environment<br />for both.</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18372016-07-13T17:33:04Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>2.1 initialization as PDCH: question: implicit or explicit?</p>
<ul>
<li>For reference: in ip.access TCH/F_PDCH, default type is TCH/F, and<br />nm_statechg_event() sends PDCH ACT immediately after init.<br />We could do the same: in the BTS code, initialize as TCH/F, and in<br />nm_statechg_event() trigger a channel state transition to PDCH.</li>
<li>This feels very heavy on messages though, we could just imply on the<br />BTS side that a DYN channel always starts off as PDCH --> no further<br />initialization messages needed from the BSC side.</li>
<li>How does the ericsson BTS expect this?</li>
</ul>
</blockquote>
<p>The channel-activation message has been expanded to include a PDCH type.<br />So I expect the channel to be initially unusable and waiting for a channel<br />activation of TCH/F, TCH/H or PDCH; i.e. BSC shall send explicit CHAN ACT.</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18382016-07-13T17:33:30Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18392016-07-13T17:38:41Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
2.2 lchan_alloc(): pick and switch dyn channels (4h)
<ul>
<li>TCH/H: pick second TCH/H if such TS is used only by half</li>
</ul>
</blockquote>
<p>To clarify, even if a dynamic TS is running in TCH/H mode and still<br />has a free TCH/H channel, the picking algorithm should <strong>always</strong> favor<br />a dedicated and available TCH/H channel over a dynamic one.</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18412016-07-14T00:46:28Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-4 priority-high2 closed" href="/issues/1564">Bug #1564</a>: dynamic TCH/F + TCH/H allocation</i> added</li></ul> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18442016-07-14T01:14:43Zlaforge
<ul></ul><p>On Wed, Jul 13, 2016 at 05:33:04PM +0000, neels [REDMINE] wrote:</p>
<blockquote><blockquote>
<ul>
<li>How does the ericsson BTS expect this?</li>
</ul>
</blockquote>
<p>The channel-activation message has been expanded to include a PDCH type.<br />So I expect the channel to be initially unusable and waiting for a channel<br />activation of TCH/F, TCH/H or PDCH; i.e. BSC shall send explicit CHAN ACT.</p>
</blockquote>
<p>correct. Just like it is with any other classic circuit-switched<br />channel: The channel is unused for traffic (not unusable) until<br />activated. FYI: The otherwise channel might meanwhile be performing<br />uplink interference measurements and report them to the BTS, yet again<br />something we don't do yet (and are not implementing as part of this<br />ticket, for sure).</p>
<p>-- <br />- Harald Welte <<a class="email" href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> <a class="external" href="http://laforge.gnumonks.org/">http://laforge.gnumonks.org/</a>
============================================================================<br />"Privacy in residential applications is a desirable marketing option." <br />(ETSI EN 300 175-7 Ch. A6)</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18462016-07-14T13:18:58Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>10</i></li></ul><p>commenced branches named neels/dyn_ts in libosmocore and openbsc.</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18512016-07-14T23:32:33Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>10</i> to <i>30</i></li></ul> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18652016-07-18T09:50:31Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>30</i> to <i>50</i></li></ul><p>Progress is looking good so far.</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18802016-07-21T12:20:45Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Currently stuck on a detail that one of two TCH/H is not initializing properly,<br />but should find that bug soon...</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18812016-07-21T14:25:26Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>50</i> to <i>80</i></li></ul><p>Feature tested as working on SysmoBTS for the first time.<br />litecell15 should work with trivial patch.</p>
<p>Now focusing on polishing up the patch.</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18822016-07-21T14:39:23Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>80</i> to <i>70</i></li></ul> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18842016-07-21T16:51:34Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>70</i> to <i>80</i></li></ul><p>Trivial patch for litecell15 confirmed working.</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18852016-07-21T16:56:43Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Related problem: <a class="issue tracker-2 status-3 priority-1 priority-lowest closed" title="Feature: avoid mismatching TCH/F vs TCH/H pchan types (Resolved)" href="https://osmocom.org/issues/1778">#1778</a></p>
<p>With fully dynamic TS, we're implicitly allowing both TCH/H and TCH/F,<br />so if an MS asks for a TCH/F, it will get one before even considering a<br />TCH/H, even if that mismatches the MS peer.</p>
<p>So in a dynamic TS configuration where one phone favors a TCH/F and the<br />other favors a TCH/H, we will end up with:</p>
<pre>
DCC <0001> gsm_04_08.c:1649 Cannot patch through call with different channel types: local = TCH_F, remote = TCH_H
</pre>
<p>Until that is resolved, I will make the channel allocator actually skip the TCH/F option<br />of TCH/F_TCH/H_PDCH dynamic slots. (This matches a specific user's expectation to be<br />able to use dynamic TCH/H <-> PDCH, which this will then offer.)</p>
<p>We could also offer an explicit TCH/H_PDCH type (or some other config to disable<br />TCH/F on dyn TS, for example).</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18862016-07-21T16:56:56Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-1 priority-lowest closed" href="/issues/1778">Feature #1778</a>: avoid mismatching TCH/F vs TCH/H pchan types</i> added</li></ul> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18892016-07-21T17:03:20Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>remaining tasks:</p>
<ul>
<li>clean up the patch to be worthy for submission, handle review comments</li>
<li>test and improve dynamic switchover error recovery</li>
<li>resolve <a class="issue tracker-2 status-3 priority-1 priority-lowest closed" title="Feature: avoid mismatching TCH/F vs TCH/H pchan types (Resolved)" href="https://osmocom.org/issues/1778">#1778</a> with respect to dynamic TS</li>
</ul> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=18992016-07-24T21:08:35Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>80</i> to <i>90</i></li></ul><p>The commits have been prepared for submission for merge to master.<br />After clean up/refactoring, I need to do a final testing round to verify<br />before actually submitting the core code. Expecting no problems there.</p>
<p>The first preparatory and cosmetic patches have already been submitted.</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=19052016-07-25T12:25:11Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>dyn TS implementations for osmo-nitb and osmo-bts-sysmo and -litecell15 are complete,<br />polished and tested, and waiting on branches named 'neels/dyn_ts' in openbsc.git and<br />osmo-bts.git.</p>
<p>To not flood gerrit with too many patches, waiting for the first preparatory patches<br />to be accepted.</p>
<p>Particularly, an osmo-bts commit depends on <a class="external" href="https://gerrit.osmocom.org/569">https://gerrit.osmocom.org/569</a> in openbsc<br />(same commit log summary), so that's a good point to split patch submission.</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=19072016-07-25T20:17:01Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>All commits are now submitted for review in gerrit.</p>
<p>(Due to a problem with gerrit, some commits were submitted twice in<br />osmo-bts.git, so that the second submissions are actually empty patches.<br />Look for a previous commit with the same log message instead.)</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=19102016-07-26T17:20:10Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>All osmo-bts commits have been merged.<br />Most openbsc commits have been approved, but three still need a +1.</p>
<p>osmo-trx: dyn PDCH <a class="issue tracker-2 status-5 priority-4 priority-high2 closed behind-schedule" title="Feature: Dynamic PDCH / TCH switching: BTS part (Closed)" href="https://osmocom.org/issues/1565">#1565</a> has just been resolved for osmo-trx, which uses<br />the same internal API as fully dynamic TS. So TCH/F_TCH/H_PDCH should need<br />only minimal effort to also work on osmo-trx, once <a class="issue tracker-2 status-5 priority-4 priority-high2 closed behind-schedule" title="Feature: Dynamic PDCH / TCH switching: BTS part (Closed)" href="https://osmocom.org/issues/1565">#1565</a> is committed.</p>
<p>The remaining issue for TCH/F on dyn TS is <a class="issue tracker-2 status-3 priority-1 priority-lowest closed" title="Feature: avoid mismatching TCH/F vs TCH/H pchan types (Resolved)" href="https://osmocom.org/issues/1778">#1778</a> (dyn TCH/F is implemented<br />and works well, but is disabled on purpose because of <a class="issue tracker-2 status-3 priority-1 priority-lowest closed" title="Feature: avoid mismatching TCH/F vs TCH/H pchan types (Resolved)" href="https://osmocom.org/issues/1778">#1778</a>).</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=19412016-07-28T14:44:34Zlaforge
<ul><li><strong>Target version</strong> set to <i>Dynamic TCH/H TCH/F PDCH</i></li></ul> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=19612016-07-29T17:28:40Zlaforge
<ul></ul><p>all related patches have been merged to master meanwhile. What's pending is the documentation update. Let's keep the ticket open as reminder.</p> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=19732016-08-01T07:37:58Zlaforge
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Closed</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul> OsmoBTS - Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switchinghttps://osmocom.org/issues/1776?journal_id=20422016-08-10T17:34:03Zneelsnhofmeyr@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>