Cellular Network Infrastructure » cni-legacy » OpenBSC

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

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).

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.

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

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.

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

Verified with ip.access nanobts.

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