Project

General

Profile

Feature #1567

Dynamic PDCH / TCH switching: BSC part

Added by laforge over 1 year ago. Updated 11 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
OpenBSC
Start date:
02/23/2016
Due date:
06/10/2016
% Done:

100%

Estimated time:
24.00 h
Resolution:
Spec Reference:

Description

this involves PCU, BTS and BSC.

The core decision making happens in the BSC (or NITB), specifically in libbsc.

Basically, at the time we want to allocate a TCH, we might need to disable a PDCH first, and then enable the same slot as TCH/F or TCH/H


Related issues

Related to OsmoBTS - Feature #1565: Dynamic PDCH / TCH switching: BTS part Closed 02/23/2016 06/10/2016
Related to OsmoPCU - Feature #1566: Dynamic PDCH / TCH switching: PCU part Closed 02/23/2016 06/10/2016

History

#1 Updated by laforge over 1 year ago

  • Related to Feature #1565: Dynamic PDCH / TCH switching: BTS part added

#2 Updated by laforge over 1 year ago

  • Related to Feature #1566: Dynamic PDCH / TCH switching: PCU part added

#3 Updated by laforge over 1 year ago

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.

Adding an estimate for the required time on the BSC side.

update: this needs to be tested against OsmoBTS and nanoBTS for compatibility reasons!

#4 Updated by laforge about 1 year ago

  • Due date set to 06/10/2016

#5 Updated by neels about 1 year ago

  • Assignee set to neels
  • % Done changed from 0 to 10

rebased the dyn PDCH part of jolly/dyn_pdch branch,
starting to test.

#6 Updated by neels about 1 year ago

  • Status changed from New to In Progress

#7 Updated by laforge about 1 year ago

  • Subject changed from Dynamic PDCH / TCH switching to Dynamic PDCH / TCH switching: BSC part
  • % Done changed from 10 to 60

From #1565, but this actually belongs here:

I have tested with the ipaccess nanobts, partially successfully.

I have so far omitted the channel defragmentation part, and also omitted the part
of jolly's branch that removes the T3111 timer. (openbsc 89df8fc4e111dd2b20e06d2a11db35d7f5f540b7 )
The combined changes attached as patch for clarity.

At first it seems that the branch does not work:

all channels set to TCH/F_PDCH
GRPS does not work, in the sense of no connection available.
(phone does not show GPRS icon, no websites load)
However, placing a call works. Upon a voice call, osmo-nitb sends a PDCH DEACT (which gets ACK'd).
After the call has ended, osmo-nitb sends a PDCH ACT (which gets ACK'd).
Only then does GPRS start to work.

I'm not sure yet how many calls have to be placed until GPRS starts working.
Sometimes it was one, sometimes two. Maybe there is a grace period, need further testing.
Also, it seems that the very first paging after osmo-nitb startup takes longer than usual.

My guess is that the ipaccess BTS expects us to send PDCH ACT for each channel upon startup,
in order to allow GPRS to work. That's what I'll try next.

Adding a pcap and nitb log [removed since not so interesting anymore]:
In this test, I had to place two voice calls until the GPRS icon appeared
and loading websites started working.

 
details: one call suffices to enable GPRS (due to PDCH ACT after voice call),
but the phone can take minutes to notice that GPRS is indeed available.

In one instance,

I waited for 10+ minutes after NITB startup without GPRS appearing
placed a call to another subscriber, "pushed away" on the other phone ("line busy")
then the phone took just over 4 minutes to notice GPRS presence.
After that GPRS works without problems for any amount of time.
So upon TRX establishment (first connect and reconnects),
we should send a PDCH ACT for all TCH/F_PDCH channels.
(At the place where SACCH filling, SI5, SI6 are sent.)

Another note: in a normal environment, at least one channel should be configured
as fixed PDCH, so that voice channels will not "push away" GPRS completely.
NITB should probably output a warning if a user configures all channels as TCH/F_PDCH.
We don't want heuristics in NITB that make sure that at least one channel is
kept as PDCH if all channels are dynamic (too much voodoo).

#8 Updated by neels about 1 year ago

I have added code to send PDCH ACT upon RSL up.

With the ip.access nanobts, GPRS is now available and working right after startup.
Voice calls are also still working without problems.

Also working: If I interrupt connection between BTS and osmo-nitb,
the PDCH channels are activated upon TRX re-establishment.

Here is a debug log output from osmo-nitb:

% '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

So far the PDCH ACT is in inp_sig_cb() in bsc_init.c.
From the logs I see the rsl_chan_activate_lchan() is called after that.
So maybe there is a better place for PDCH ACT? Leaving it up to code review.

#9 Updated by neels about 1 year ago

see 7 commits up to https://gerrit.osmocom.org/182

#10 Updated by neels about 1 year ago

neels wrote:

So far the PDCH ACT is in inp_sig_cb() in bsc_init.c.
From the logs I see the rsl_chan_activate_lchan() is called after that.
So maybe there is a better place for PDCH ACT? Leaving it up to code review.

The PDCH ACT has moved to nm_statechg_event() upon TS Enable.

#11 Updated by neels about 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 60 to 100

The current state of dynamic PDCH in openbsc is considered working.

See https://gerrit.osmocom.org/211 (and 208, 209, 210, as listed in related changes)
openbsc.git 253c7cec7eaea40fcd66c65478952996110ef2fa

#12 Updated by neels about 1 year ago

Verified with ip.access nanobts.

Also tested with sysmoBTS as partially functional, but sysmoBTS needs some more work.

#13 Updated by laforge about 1 year ago

  • Status changed from Resolved to Closed

#14 Updated by laforge 11 months ago

  • Target version set to Dynamic TCH/H TCH/F PDCH

Also available in: Atom PDF