https://osmocom.org/https://osmocom.org/favicon.ico?16647414092016-06-24T14:37:55ZOpen Source Mobile CommunicationsOsmoBTS - Feature #1757: determine strategy for fully dynamic PDCH, TCH/F and TCH/H channelhttps://osmocom.org/issues/1757?journal_id=16932016-06-24T14:37:55Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Indeed, the current implementation of TCH/F_PDCH switching shows that the only<br />BTS-specific thing needed is disconnecting and reconnecting a channel with any<br />desired GsmL1_LogChComb_*.</p>
<p>Also added to the BTS was the messaging of the IPAC_PDCH_ACT and DEACT, i.e. the<br />RX as well as ACK TX. In the light of more general OML messages, these would<br />become obsolete.</p>
<p>One problem that I already know of: it seems that before dyn PDCH as it<br />is now, our BTS implementations did not have any code to disconnect a TS<br />(the GsmL1_PrimId_MphDisconnectReq was not used anywhere before).<br />So the taking down of a CHANNEL OML is probably not implemented anywhere.<br />The dyn PDCH so far does it only for the IPAC_PDCH_DE/ACT messages, so<br />all BTS implementations would need to be adjusted for that.</p>
<p>A note on TCH/H: jolly's dyn PDCH branch also features some channel defrag<br />code, which triggers handovers from one TS to another to maximize the number<br />of consequtive TS used. This would make a lot of sense when two TCH/H are<br />spread across two TS and could be combined to make way for a PDCH, for example.<br />But first, I would go for simply taking the TS as they are -- iff a TS is<br />unused, it may be switched. The defrag feature would be benificial for<br />dynamic switching but is essentially independent, implementation wise.</p>
<p>The OML proposal makes a lot of sense to me, but I'll come back with estimations<br />when I've had a closer look.</p> OsmoBTS - Feature #1757: determine strategy for fully dynamic PDCH, TCH/F and TCH/H channelhttps://osmocom.org/issues/1757?journal_id=16952016-06-27T10:04:00Zlaforge
<ul></ul><p>I just studied Ericsson OM2000 again over the weekend, and they only have one "TCH/F or TCH/H or PDCH" channel configuration that is set by OML. see also the pchan2comb() function in abis_om2000.c</p>
<p>Such timeslots can then receive RSL CHAN ACT for TCH/F or TCH/H. Even PDCH actiavation seems to be using a RSL CHAN ACT with a non-standard Channel Number IE (we don't implement any GPRS support for Ericsson/Nokia/Siemens yet, but that might be something on our agenda at some point).</p>
<p>So it seems like they're closer to what IPA is doing, but in a more elegant and generic way - which speaks more for a solution that doesn't touch the more complex OML transactions. So even if I believe that an OML based solution would be the proper way, I'm not convinced it will do us any good, if the other BTS models (we know of) don't do it :/</p> OsmoBTS - Feature #1757: determine strategy for fully dynamic PDCH, TCH/F and TCH/H channelhttps://osmocom.org/issues/1757?journal_id=16982016-06-27T15:08:51Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Currently, we can switch TCH/F <-> PDCH on sysmoBTS and lc15.<br />Switchover state is by fixed "TCH/F_PDCH" pchan config<br />and two bits indicating PDCH ACT and DEACT, respectively.<br />Switchover itself is so far by the IPAC_PDCH_ACT and _DEACT messages,<br />where a DEACT always goes back to TCH/F implicitly.</p>
<p>Now, we would also like to switch to/from TCH/H.<br />One could want to also switch SDCCH dynamically; we're not really interested in that now,<br />but it would make sense to allow for more channel types when planning TCH/H now.</p>
<p>In the light of IPAC_PDCH_ACT and _DEACT messages, it would be easiest to have a fixed<br />config of either TCH/F_PDCH or TCH/H_PDCH, so that the ACT and DEACT is a bump operation<br />to go to or back from PDCH mode with the TCH/* type fixed.</p>
<p>Above RSL CHAN ACT with an added IE to indicate which type to switch to is indeed<br />more elegant: during runtime, one could switch between TCH/H and TCH/F as well.</p>
<p>Even more elegant would be to switch a TS using OML, but it seems that there is no standard<br />"OPSTOP" like OML message to take down a TS, like the opposite of an OPSTART. This would explain<br />why there are vendor specific additions to the protocol to do channel pchan switching.</p>
<p>I will thus plan for a new TS type and RSL CHAN ACT with nonstandard Channel Number IE,<br />as described above.</p> OsmoBTS - Feature #1757: determine strategy for fully dynamic PDCH, TCH/F and TCH/H channelhttps://osmocom.org/issues/1757?journal_id=17032016-06-27T18:48:56Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><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 #1757: determine strategy for fully dynamic PDCH, TCH/F and TCH/H channelhttps://osmocom.org/issues/1757?journal_id=17042016-06-27T19:02:56Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>Even more elegant would be to switch a TS using OML, but it seems that there is no standard<br />"OPSTOP" like OML message to take down a TS, like the opposite of an OPSTART. This would explain<br />why there are vendor specific additions to the protocol to do channel pchan switching.</p>
</blockquote>
<p><strong>Disclaimer</strong>: I'm not really sure that this conclusion is accurate.</p>
<p>To be precise, this is about an OPSTART of a CHANNEL object as in:<br /><pre>
<0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)·
<0005> bts_ipaccess_nanobts.c:359 Rx NM_OC_CHANNEL for TRX 0 TS 0
<0005> abis_nm.c:1658 Set Chan Attr (bts=0,trx=0,ts=0)
<0005> abis_nm.c:1765 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART
<0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)·
<0005> bts_ipaccess_nanobts.c:359 Rx NM_OC_CHANNEL for TRX 0 TS 1
<0005> abis_nm.c:1658 Set Chan Attr (bts=0,trx=0,ts=1)
<0005> abis_nm.c:1765 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART
<0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)·
<0005> bts_ipaccess_nanobts.c:359 Rx NM_OC_CHANNEL for TRX 0 TS 2
<0005> abis_nm.c:1658 Set Chan Attr (bts=0,trx=0,ts=2)
[...]
</pre></p> OsmoBTS - Feature #1757: determine strategy for fully dynamic PDCH, TCH/F and TCH/H channelhttps://osmocom.org/issues/1757?journal_id=17052016-06-27T19:13:20Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>it seems that there is no standard "OPSTOP" like OML message to take down a TS,<br />like the opposite of an OPSTART.</p>
</blockquote>
<p>In 3GPP TS 12.21, there's the 8.9.3 Reinitialize message. So we could SET CHAN ATTR<br />followed by this Reinitialize, though it's unlikely that this works with any BTS.</p>
<p>In our own BTS implementations we could of course also just send a SET CHAN ATTR<br />to switch a channel, even though the OPSTART has already been issued...</p>
<p>With a complex object model like OML I would have expected a kind of OPSTOP to<br />exist. It is hard to believe that this is plainly missing.</p> OsmoBTS - Feature #1757: determine strategy for fully dynamic PDCH, TCH/F and TCH/H channelhttps://osmocom.org/issues/1757?journal_id=17102016-06-28T12:49:38Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>To clarify the scopes of dynamic channel switching:</p>
<ul>
<li>The ip.access PDCH ACT (<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>, <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>) feature is independent of the<br /> more general dynamic feature discussed here. We will keep the ip.access<br /> messaging regardless, because we would like to be able to e.g. operate<br /> a SysmoBTS in ip.access compatibility mode with a different kind of BSC,<br /> and OpenBSC will keep the ip.access messages to operate a nanobts with it.</li>
</ul>
<ul>
<li>This more general channel switching feature would be implemented in<br /> parallel to the ip.access PDCH switching, with a new, proprietary pchan<br /> type to distinguish.</li>
</ul>
<p>@Harald, in a private mail you mention "bts_type == 'sysmobts'", but so<br />far I'm assuming that we want to have this on lc15, osmo-trx and octphy(?)<br />as well. Please confirm -- thanks!</p> OsmoBTS - Feature #1757: determine strategy for fully dynamic PDCH, TCH/F and TCH/H channelhttps://osmocom.org/issues/1757?journal_id=17122016-06-29T18:15:09Zlaforge
<ul></ul><p>On Tue, Jun 28, 2016 at 12:49:38PM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<p>@Harald, in a private mail you mention "bts_type 'sysmobts'", but so<br />far I'm assuming that we want to have this on lc15, osmo-trx and octphy(?)<br />as well. Please confirm -- thanks!</p>
</blockquote>
<p>As you may have noticed, you generally use 'bts_type sysmobts' in<br />openbsc.cfg when talking to osmo-bts as BTS implementation, no matter<br />if you use osmo-bts-{sysmo,trx,octphy}. This is of course not correct,<br />and just for historical reasons. There's <a class="issue tracker-1 status-7 priority-2 priority-default" title="Bug: better identification of BTS model / capabilities to BSC (Stalled)" href="https://osmocom.org/issues/1614">#1614</a> about this.</p>
<p>basically osmo-bts should start to notify the BSC about the detailed bts<br />variant as well as some kind of feature matrix, so the BSC can then<br />adjust its behavior accordingly.</p>
<p>So getting back to your question: Of course it should work for<br />sysmobts/lc15/octphy/trx, but all of those are 'bts_type symsobts' from<br />OpenBSC point of view at this point.</p>
<p>-- <br />- Harald Welte &lt;<a class="email" href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>&gt; <a class="external" href="http://laforge.gnumonks.org/">http://laforge.gnumonks.org/</a><br />==========================================================================<br />"Privacy in residential applications is a desirable marketing option." <br />(ETSI EN 300 175-7 Ch. A6)</p> OsmoBTS - Feature #1757: determine strategy for fully dynamic PDCH, TCH/F and TCH/H channelhttps://osmocom.org/issues/1757?journal_id=17382016-07-04T18:32:02Zlaforge
<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 #1757: determine strategy for fully dynamic PDCH, TCH/F and TCH/H channelhttps://osmocom.org/issues/1757?journal_id=17632016-07-07T22:40:17Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>With a complex object model like OML I would have expected a kind of OPSTOP to<br />exist. It is hard to believe that this is plainly missing.</p>
</blockquote>
<p>As a side note, I have now seen a situation where a RADIO-CARRIER and CHANNEL objects<br />received a second OPSTART. However, the BTS announced the OP_STATE = Disabled,<br />followed by the BSC sending another OPSTART. (the default osmo-bts-trx startup sequence)</p>
<p>We were looking for a state change initiated by the BSC, so that's still no "OPSTOP" <br />that would be useful here.</p> OsmoBTS - Feature #1757: determine strategy for fully dynamic PDCH, TCH/F and TCH/H channelhttps://osmocom.org/issues/1757?journal_id=18242016-07-12T17:14:45Zlaforge
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Closed</i></li></ul> OsmoBTS - Feature #1757: determine strategy for fully dynamic PDCH, TCH/F and TCH/H channelhttps://osmocom.org/issues/1757?journal_id=19432016-07-28T14:44:39Zlaforge
<ul><li><strong>Target version</strong> set to <i>Dynamic TCH/H TCH/F PDCH</i></li></ul>