https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092016-02-23T15:26:36ZOpen Source Mobile CommunicationsOpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC parthttps://projects.osmocom.org/issues/1567?journal_id=10342016-02-23T15:26:36Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-high2 closed behind-schedule" href="/issues/1565">Feature #1565</a>: Dynamic PDCH / TCH switching: BTS part</i> added</li></ul> OpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC parthttps://projects.osmocom.org/issues/1567?journal_id=10362016-02-23T15:26:42Zlaforge
<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> OpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC parthttps://projects.osmocom.org/issues/1567?journal_id=10382016-02-23T15:27:16Zlaforge
<ul></ul><p>The jolly/dyn_pdch branch contains some towards this direction. However, it needs some clean-up and generalization, as we cannot make the assumption that all (Osmo or non-Osmo)BTSs even support this dynamic switching.</p>
<p>Adding an estimate for the required time on the BSC side.</p>
<p>update: this needs to be tested against OsmoBTS and nanoBTS for compatibility reasons!</p> OpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC parthttps://projects.osmocom.org/issues/1567?journal_id=13632016-05-09T18:50:09Zlaforge
<ul><li><strong>Due date</strong> set to <i>06/10/2016</i></li></ul> OpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC parthttps://projects.osmocom.org/issues/1567?journal_id=14672016-05-24T11:32:22Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Assignee</strong> set to <i>neels</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>10</i></li></ul><p>rebased the dyn PDCH part of jolly/dyn_pdch branch,<br />starting to test.</p> OpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC parthttps://projects.osmocom.org/issues/1567?journal_id=14702016-05-24T11:33:52Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul> OpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC parthttps://projects.osmocom.org/issues/1567?journal_id=14922016-06-01T13:47:00Zlaforge
<ul><li><strong>Subject</strong> changed from <i>Dynamic PDCH / TCH switching</i> to <i>Dynamic PDCH / TCH switching: BSC part</i></li><li><strong>% Done</strong> changed from <i>10</i> to <i>60</i></li></ul><p>From <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://projects.osmocom.org/issues/1565">#1565</a>, but this actually belongs here:</p>
<p>I have tested with the ipaccess nanobts, partially successfully.</p>
<p>I have so far omitted the channel defragmentation part, and also omitted the part<br />of jolly's branch that removes the T3111 timer. (openbsc 89df8fc4e111dd2b20e06d2a11db35d7f5f540b7 )<br />The combined changes attached as patch for clarity.</p>
<p>At first it seems that the branch does not work:</p>
<p>all channels set to TCH/F_PDCH<br />GRPS does not work, in the sense of no connection available.<br />(phone does not show GPRS icon, no websites load)<br />However, placing a call works. Upon a voice call, osmo-nitb sends a PDCH DEACT (which gets ACK'd).<br />After the call has ended, osmo-nitb sends a PDCH ACT (which gets ACK'd).<br />Only then does GPRS start to work.</p>
<p>I'm not sure yet how many calls have to be placed until GPRS starts working.<br />Sometimes it was one, sometimes two. Maybe there is a grace period, need further testing.<br />Also, it seems that the very first paging after osmo-nitb startup takes longer than usual.</p>
<p>My guess is that the ipaccess BTS expects us to send PDCH ACT for each channel upon startup,<br />in order to allow GPRS to work. That's what I'll try next.</p>
<p>Adding a pcap and nitb log [removed since not so interesting anymore]:<br />In this test, I had to place two voice calls until the GPRS icon appeared<br />and loading websites started working.</p>
<p> <br />details: one call suffices to enable GPRS (due to PDCH ACT after voice call),<br />but the phone can take minutes to notice that GPRS is indeed available.</p>
<p>In one instance,</p>
<p>I waited for 10+ minutes after NITB startup without GPRS appearing<br />placed a call to another subscriber, "pushed away" on the other phone ("line busy")<br />then the phone took just over 4 minutes to notice GPRS presence.<br />After that GPRS works without problems for any amount of time.<br />So upon TRX establishment (first connect and reconnects),<br />we should send a PDCH ACT for all TCH/F_PDCH channels.<br />(At the place where SACCH filling, SI5, SI6 are sent.)</p>
<p>Another note: in a normal environment, at least one channel should be configured<br />as fixed PDCH, so that voice channels will not "push away" GPRS completely.<br />NITB should probably output a warning if a user configures all channels as TCH/F_PDCH.<br />We don't want heuristics in NITB that make sure that at least one channel is<br />kept as PDCH if all channels are dynamic (too much voodoo).</p> OpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC parthttps://projects.osmocom.org/issues/1567?journal_id=15292016-06-06T13:50:04Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>I have added code to send PDCH ACT upon RSL up.</p>
<p>With the ip.access nanobts, GPRS is now available and working right after startup.<br />Voice calls are also still working without problems.</p>
<p>Also working: If I interrupt connection between BTS and osmo-nitb,<br />the PDCH channels are activated upon TRX re-establishment.</p>
<p>Here is a debug log output from osmo-nitb:</p>
<pre>
% 'dtx-used' is now deprecated: use dtx * configuration options of BTS instead
<0005> bsc_init.c:532 VTY at 127.0.0.1 4242
<001d> input/ipaccess.c:838 enabling ipaccess BSC mode
<0017> smpp_smsc.c:978 SMPP at 0.0.0.0 2775
<0005> bsc_hack.c:305 CTRL at 127.0.0.1 4249
DB: Database initialized.
DB: Database prepared.
<0002> gsm_subscriber.c:362 Expiring inactive subscriber 901990000000038 (ID 17)
<0002> gsm_subscriber.c:362 Expiring inactive subscriber 274018000000012 (ID 19)
<001d> input/ipa.c:265 accept()ed new link from 10.9.1.170 to port 3002
<001d> input/ipa.c:265 accept()ed new link from 10.9.1.170 to port 3003
<0004> bsc_init.c:287 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 868 using MCC=1 MNC=868 LAC=1 CID=0 BSIC=63
<0004> abis_rsl.c:1997 (bts=0,trx=0,ts=2) IPAC_PDCH_ACT
<0004> abis_rsl.c:1997 (bts=0,trx=0,ts=3) IPAC_PDCH_ACT
<0004> abis_rsl.c:1997 (bts=0,trx=0,ts=4) IPAC_PDCH_ACT
<0004> abis_rsl.c:1997 (bts=0,trx=0,ts=5) IPAC_PDCH_ACT
<0004> abis_rsl.c:1997 (bts=0,trx=0,ts=6) IPAC_PDCH_ACT
<0004> abis_rsl.c:1997 (bts=0,trx=0,ts=7) IPAC_PDCH_ACT
<001a> bsc_init.c:331 Activated PDCH on 6 dynamic TCH/F_PDCH time slots for BTS 0 TRX 0
<0004> abis_rsl.c:1269 (bts=0,trx=0,ts=2,ss=0) IPAC PDCH ACT ACK
<0004> abis_rsl.c:1269 (bts=0,trx=0,ts=3,ss=0) IPAC PDCH ACT ACK
<0004> abis_rsl.c:1269 (bts=0,trx=0,ts=4,ss=0) IPAC PDCH ACT ACK
<0004> abis_rsl.c:1269 (bts=0,trx=0,ts=5,ss=0) IPAC PDCH ACT ACK
<0004> abis_rsl.c:1269 (bts=0,trx=0,ts=6,ss=0) IPAC PDCH ACT ACK
<0004> abis_rsl.c:1269 (bts=0,trx=0,ts=7,ss=0) IPAC PDCH ACT ACK
<0004> abis_rsl.c:1508 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(868) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0b ta=0
<001a> abis_rsl.c:476 rsl_chan_activate_lchan() on lchan (bts=0,trx=0,ts=0,ss=0) TS 0 in mode 2 (GSM_PCHAN_TCH_F_PDCH=7) flags 1000 (TS_F_PDCH_MODE=1000)
<0004> abis_rsl.c:1244 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK
<0002> gsm_04_08.c:1141 LOCATION UPDATING REQUEST: MI(TMSI)=2089914174 type=IMSI ATTACH
[...]
<001d> input/ipa.c:265 accept()ed new link from 10.9.1.170 to port 3002
<001f> bsc_init.c:374 Lost some E1 TEI link: 1 0x7f771d662070
<001f> bsc_init.c:374 Lost some E1 TEI link: 2 0x7f771d662070
<001d> input/ipa.c:265 accept()ed new link from 10.9.1.170 to port 3003
<0004> bsc_init.c:287 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 868 using MCC=1 MNC=868 LAC=1 CID=0 BSIC=63
<0004> abis_rsl.c:1997 (bts=0,trx=0,ts=2) IPAC_PDCH_ACT
<0004> abis_rsl.c:1997 (bts=0,trx=0,ts=3) IPAC_PDCH_ACT
<0004> abis_rsl.c:1997 (bts=0,trx=0,ts=4) IPAC_PDCH_ACT
<0004> abis_rsl.c:1997 (bts=0,trx=0,ts=5) IPAC_PDCH_ACT
<0004> abis_rsl.c:1997 (bts=0,trx=0,ts=6) IPAC_PDCH_ACT
<0004> abis_rsl.c:1997 (bts=0,trx=0,ts=7) IPAC_PDCH_ACT
<001a> bsc_init.c:331 Activated PDCH on 6 dynamic TCH/F_PDCH time slots for BTS 0 TRX 0
<0004> abis_rsl.c:1269 (bts=0,trx=0,ts=2,ss=0) IPAC PDCH ACT ACK
<0004> abis_rsl.c:1269 (bts=0,trx=0,ts=3,ss=0) IPAC PDCH ACT ACK
<0004> abis_rsl.c:1269 (bts=0,trx=0,ts=4,ss=0) IPAC PDCH ACT ACK
<0004> abis_rsl.c:1269 (bts=0,trx=0,ts=5,ss=0) IPAC PDCH ACT ACK
<0004> abis_rsl.c:1269 (bts=0,trx=0,ts=6,ss=0) IPAC PDCH ACT ACK
<0004> abis_rsl.c:1269 (bts=0,trx=0,ts=7,ss=0) IPAC PDCH ACT ACK
<0004> abis_rsl.c:1508 (bts=0,trx=0,ts=2,ss=0) Activating ARFCN(868) SS(0) lctype TCH/F r=CALL ra=0x4c ta=0
<001a> abis_rsl.c:476 rsl_chan_activate_lchan() on lchan (bts=0,trx=0,ts=2,ss=0) TS 2 in mode 7 (GSM_PCHAN_TCH_F_PDCH=7) flags 1000 (TS_F_PDCH_MODE=1000)
<001a> abis_rsl.c:480 Deactivate PDCH on lchan (bts=0,trx=0,ts=2,ss=0) TS 2
</pre>
<p>So far the PDCH ACT is in inp_sig_cb() in bsc_init.c.<br />From the logs I see the rsl_chan_activate_lchan() is called after that.<br />So maybe there is a better place for PDCH ACT? Leaving it up to code review.</p> OpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC parthttps://projects.osmocom.org/issues/1567?journal_id=15302016-06-06T13:50:35Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>see 7 commits up to <a class="external" href="https://gerrit.osmocom.org/182">https://gerrit.osmocom.org/182</a></p> OpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC parthttps://projects.osmocom.org/issues/1567?journal_id=15572016-06-10T14:19:39Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>So far the PDCH ACT is in inp_sig_cb() in bsc_init.c.<br />From the logs I see the rsl_chan_activate_lchan() is called after that.<br />So maybe there is a better place for PDCH ACT? Leaving it up to code review.</p>
</blockquote>
<p>The PDCH ACT has moved to nm_statechg_event() upon TS Enable.</p> OpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC parthttps://projects.osmocom.org/issues/1567?journal_id=15582016-06-10T14:22:19Zneelsnhofmeyr@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>60</i> to <i>100</i></li></ul><p>The current state of dynamic PDCH in openbsc is considered working.</p>
<p>See <a class="external" href="https://gerrit.osmocom.org/211">https://gerrit.osmocom.org/211</a> (and 208, 209, 210, as listed in related changes)<br />openbsc.git 253c7cec7eaea40fcd66c65478952996110ef2fa</p> OpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC parthttps://projects.osmocom.org/issues/1567?journal_id=15592016-06-10T14:23:39Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Verified with ip.access nanobts.</p>
<p>Also tested with sysmoBTS as partially functional, but sysmoBTS needs some more work.</p> OpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC parthttps://projects.osmocom.org/issues/1567?journal_id=15992016-06-14T09:40:16Zlaforge
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Closed</i></li></ul> OpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC parthttps://projects.osmocom.org/issues/1567?journal_id=19442016-07-28T14:44:47Zlaforge
<ul><li><strong>Target version</strong> set to <i>Dynamic TCH/H TCH/F PDCH</i></li></ul>