Cellular Network Infrastructure » Radio Access Network » OsmoBTS

• parse the IPA specific RSL message for dynamic PDCH activation/deactivation
• perform the required timeslot configuration changes towards the L1 (for all supported PHYs)
  *|send the PCU_IF_MSG_INFO_IND message with the updated PDCH timeslot bit-map once the number of PDCH changes

(comment moved to #1567)

(comment moved to #1567)

(comment moved to #1567)

(comment moved to #1567)

First, I will take a look at how sysmoBTS may handle TCH/F_PDCH.
(Starting with getting to know the sysmoBTS code.)
Hints at specific code may be helpful.

• in oml_rx_set_chan_attr() we receive the user's pchan conf
• TCH/F_PDCH chans should probably be set to GsmL1_LogChComb_II initially,
  so they come up as TCH/F like in the ip.access nanobts.
  (osmo-bsc then sends PDCH ACT upon RSL UP, making them PDTCH)
• in rsl_rx_dchan() we receive an IPACC_PDCH_DEACT at some point
• in the common/ part, we should check whether the original config was indeed TCH/F_PDCH
• then using bts_model_* phy-specific API, we
  • probably need to MPH-DISCONNECT-REQ and
  • MPH-CONNECT-REQ with logChComb == PDTCH/F+PACCH/F+PTCCH/F
• possibly followed by pdtch_sapis[] activation

initial implementation for sysmo-bts is complete and up for testing
(not yet pushed anywhere).

The openbsc code that works for the ip.access nanobts doesn't work for sysmoBTS so far,
because the initial PDCH ACT for each TCH/F_PDCH TS is sent before the SET_CHAN_ATTR is even sent.

So the BTS can't know yet that the PDCH ACT sent for a given TS is indeed for a TCH/F_PDCH TS.

osmo-bts-sysmo complains about it.

So far I couldn't find a neat hook to send the PDCH ACT at the right time,
because it would be an RSL message depending on the NM message for setting
PCHAN types to be completed.

Also, for ip.access and sysmoBTS, the SET_CHAN_ATTR part is apparently "hidden"
in bts_ipaccess_nanobts.c, but I would prefer to keep it more general.

I don't really like this solution that much, but it seems the best way is to have
a "PDCH ACT pending" flag in sysmoBTS to allow receiving PDCH ACT even before the
PCHAN types are received.

Today's SysmoBTS testing concluded partially successfully.
I got both voice and GPRS to work with a TCH/F_PDCH configuration.
There is still the following problem with voice:

(TS 0 CCCH+SDCCH4 and TS 1 SDCCH8, when I say "all", I mean the remaining six TS)

With only TCH/F_PDCH channels available

• initially, voice calls can be placed
• GPRS is functional
• as soon as GPRS is used, however, further voice calls are not possible
  

  <0004> abis_rsl.c:1458 BTS 0 CHAN RQD: no resources for TCH/F 0x2b
  

This makes sense if one expects all channels to be grabbed by GPRS.

However, I'm kind of expecting voice to start working again when GPRS is no longer in use,
not really sure yet how this would work, though.

Also, this seems to not be entirely reproducable.

With one TS as TCH/F and all others as TCH/F_PDCH:

• I have the exact same situation.

I'm expecting voice to always work now,
since one TS is reserved for TCH/F, yet voice stops working completely
as soon as data has been used once.

With at least two TCH/F and at least one TCH/F_PDCH:

• both voice and data work well regardless of GPRS being used.

Todo: check these cases on the ip.access nanobts

Todo:

<0002> tbf.cpp:340 TBF(TFI=0 TLLI=0xca6de331 DIR=DL STATE=RELEASING) Software error: Pending uplink assignment. This may not happen, because the assignment message never gets transmitted. Please be sure not to free in this state. PLEASE FIX!

Todo: It seems not all TCH/F_PDCH are enabled properly.
In a situation where 3..7 are TCH/F_PDCH, random ones, like TS 3 and 5, don't list as PDCH.
Is there some race?

Todo: the code is on a private branch and still needs to be groomed & submitted.

neels wrote:

However, I'm kind of expecting voice to start working again when GPRS is no longer in use,
not really sure yet how this would work, though.

There is no notion of "GPRS no longer in use". You either

a) always have to keep at least one TCH/F free/available, and reduce the number of PDCH every time you allocate the last TCH/F, or

b) modify the channel alloctor in the BSC to DEACTIVATE a PDCH when we try to allocate a TCH channel in response ot a RACH request (= RSL CHAN REQUIRED), i.e. in lchan_alloc. Please note there are several reasons why we would want to allocate a circuit-switched channel, e.g. hand-over, CHAN RQD, ... As none of the related code expects to be delayed (i.e. a synchronous response to lchan_alloc() is expected), it might be best to go for option a).

With one TS as TCH/F and all others as TCH/F_PDCH:

• I have the exact same situation.

I'm expecting voice to always work now,
since one TS is reserved for TCH/F, yet voice stops working completely
as soon as data has been used once.

this sounds like you're not properly releasing channels after use? Please confirm in "show lchan" and RSL protocol traces.

Todo: It seems not all TCH/F_PDCH are enabled properly.
In a situation where 3..7 are TCH/F_PDCH, random ones, like TS 3 and 5, don't list as PDCH.
Is there some race?

It definitely sounds like three are some bugs left...

Testing ip.access nanobts:

1x TCH/F, 5x TCH/F_PDCH
and
5x TCH/F, 1x TCH/F_PDCH

behave the same as described in #1747:

• both voice and data bascially work

• however, while a phone keeps using GPRS (continuously downloading),
  the other phone cannot place calls.

I first thought this was due to dyn pdch changes, but since the same behavior
happens with a master branch build, I now assume that the dyn pdch changes to
openbsc don't break normal ip.access nanobts behavior.

Typically, I expect GPRS service to be stopped when a phone is being called,
as seen yesterday with a sysmoBTS:

• The active web page download was stopped and the phone started ringing;
• after the call was done, a web page reload completed the download.

neels wrote:

The openbsc code that works for the ip.access nanobts doesn't work for sysmoBTS so far,
because the initial PDCH ACT for each TCH/F_PDCH TS is sent before the SET_CHAN_ATTR is even sent.

This was resolved by sending PDCH ACT upon the OPSTART a State Change to Enabled for a TS is received by the BSC,
separately for each TS.

Today I verified that the ip.access nanobts' dyn pdch is still working with this fix.

neels wrote:

Todo: It seems not all TCH/F_PDCH are enabled properly.
In a situation where 3..7 are TCH/F_PDCH, random ones, like TS 3 and 5, don't list as PDCH.
Is there some race?

The problem is in the cb & data arguments for l1if_gsm_req_compl(fl1h, msg, opstart_compl_cb, data);
When l1if_gsm_req_compl calls interleave, data args returned to cb() get mixed up.
Debug output shows that TS 6's data arg is passed to TS 5's callback:

▶ grep -i '[ <]--[> ]' bts.log.5
<0006> oml.c:521 --> TS 0 data 0xb0080 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 0 data 0xb0080 dyn_pdch (nil)
<0006> oml.c:521 --> TS 1 data 0xb00f0 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 1 data 0xb00f0 dyn_pdch (nil)
<0006> oml.c:521 --> TS 2 data 0xb0160 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 2 data 0xb0160 dyn_pdch (nil)
<0006> oml.c:521 --> TS 2 data 0xb0218 dyn_pdch 0xb0160
<0006> oml.c:271 <-- TS 2 data 0xb0218 dyn_pdch 0xb0160
<0006> oml.c:521 --> TS 3 data 0xb1590 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 3 data 0xb1590 dyn_pdch (nil)
<0006> oml.c:521 --> TS 3 data 0xb3768 dyn_pdch 0xb1590
<0006> oml.c:271 <-- TS 3 data 0xb3768 dyn_pdch 0xb1590
<0006> oml.c:521 --> TS 4 data 0xb28a8 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 4 data 0xb28a8 dyn_pdch (nil)
<0006> oml.c:521 --> TS 5 data 0xb28a8 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 5 data 0xb28a8 dyn_pdch (nil)
<0006> oml.c:521 --> TS 4 data 0xb2758 dyn_pdch 0xb28a8
<0006> oml.c:271 <-- TS 4 data 0xb2758 dyn_pdch 0xb28a8
<0006> oml.c:521 --> TS 5 data 0xb5860 dyn_pdch 0xb1720 [<- this]
<0006> oml.c:521 --> TS 6 data 0xb4ac8 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 5 data 0xb4ac8 dyn_pdch (nil) [<- mismatches this]
<0006> oml.c:271 <-- TS 6 data 0xb5860 dyn_pdch 0xb1720
<0006> oml.c:521 --> TS 7 data 0xb39d0 dyn_pdch (nil)
<0006> oml.c:271 <-- TS 7 data 0xb39d0 dyn_pdch (nil)
<0006> oml.c:521 --> TS 6 data 0xb5690 dyn_pdch 0xb1720
<0006> oml.c:271 <-- TS 6 data 0xb5690 dyn_pdch 0xb1720

Will try to find the cause now.

neels wrote:

Will try to find the cause now.

osmo-bts/src/osmo-bts-sysmo/l1_if.c:

static inline int is_prim_compat(GsmL1_Prim_t *l1p, struct wait_l1_conf *wlc)
{
        /* the limitation here is that we cannot have multiple callers
         * sending the same primitive */

neels wrote:

neels wrote:

Will try to find the cause now.

osmo-bts/src/osmo-bts-sysmo/l1_if.c:
[...]

We agreed on using the hLayer3 handle to identify primitive confirmations (todo).

sysmoBTS is partially working.

Some Bugs need to be resolved, but the dynamic PDCH feature is working in principle.

The code is still in a private git repository.
I will groom over it once more and push to gerrit soon.

litecell and osmo-trx: not started yet.

neels wrote:

sysmoBTS is partially working.

Some Bugs need to be resolved, but the dynamic PDCH feature is working in principle.

Above conclusion was based on bad initialisation of channels. After this fix: https://gerrit.osmocom.org/264
the TCH/F_PDCH channels are set up properly, and proper PDCH deactivation + TCH/F activation are actually
required for the first time. (Before, wrongly initialized channels took over the TCH/F.)

Data service is functional with TCH/F_PDCH channels, but dynamic switchover to TCH/F is not working yet with sysmoBTS.

In the current state, the order of messages is wrong.
I was hoping to get switchover working with some broken edge cases,
but indeed I need to fix so that:

• when the BSC asks for PDCH deactivation,
• first store PDCH deact state on that timeslot and send pcu_tx_info_ind(),
• when the PCU answers with a channel deactivation, look up the PDCH deact state,
• only then start the phy channel deactivation,
• and finally after successful deact, respond to the BSC with a PDCH DEACT ACK,
• so that the BSC carries on to activate the new state after that.

(For simplicity, I tried to first switch off phy, then tell the PCU and BSC
about it at the same time; thus the BSC already carries on to activate the
new state while the PCU still asks to deactivate the old state... doesn't work.)

neels wrote:

neels wrote:

neels wrote:

Will try to find the cause now.

osmo-bts/src/osmo-bts-sysmo/l1_if.c:
[...]

We agreed on using the hLayer3 handle to identify primitive confirmations (todo).

update: this is fixed in https://gerrit.osmocom.org/264

sysmoBTS: on TCH/F_PDCH TS, dynamic switchover from PDCH to TCH/F is now working.
Per default, dynamic TCH/F_PDCH channels operate as PDCH for data services.
As voice calls come up, they are converted to TCH/F, and back to PDCH on hangup.

Most of the switchover logic is in fact implemented in the common/ part of osmo-bts.
Two simple functions need to be added specific to BTS models -- bts_model_ts_disconnect()
and bts_model_ts_connect() -- and two hooks need to be called after connect/disconnect.

Commits preparing the implementation are waiting for approval in gerrit,
5 patches up to https://gerrit.osmocom.org/295.

The implementation itself is still in a private repository as one large change;
while the acceptance of the preparing patches is pending, I will split it into
smaller bits for review.

I would also like to do some further testing of cases where the amount of available
channels is exhausted. If all TS were TCH/F_PDCH, I expect voice calls to "push away"
GPRS until data service is stopped completely, but haven't tested yet.

the sysmoBTS implementation of dyn PDCH is now completely submitted for review:
https://gerrit.osmocom.org/311

The sysmoBTS dyn PDCH feature has been merged to osmo-bts master.

The most recent developments on osmo-bts-lc15 on the master branch don't
work with our litecell 1.5 hardware as it is configured right now.
In particular, the numbering scheme of /dev/msgq/litecell15_dsp2arm_trx*
has changed from 1,2 to 0,1. Until an update on the firmware arrives
with us, I'm branching off an earlier revision to implement dyn PDCH.

dynamic PDCH is now implemented for litecell 1.5,
highly similar to the sysmoBTS implementation.

The implementation is waiting for approval at https://gerrit.osmocom.org/396
(and preceding submissions on the same topic)

The osmo-bts-trx implementation of this turns out to be less straightforward than the others.
#1770 got in the way, next I need to find out why my patch so far is not sufficient.
(branch osmo-bts.git:neels/dyn_pdch_trx)

Finally, the problem that stalled dynamic PDCH on osmo-trx has been resolved.
Left to do: polish the patches and submit for review.

I believe this should have been closed. Please make sure tickets alwas reflect reality.

I still had some things waiting in the queue, the 90% was intentional.
More accurate would be 99%, but indeed TCH/F_TCH/H_PDCH for osmo-trx is not yet in master.

While testing the last 1%, I noticed that a recent commit actually breaks dynamic
timeslots on SysmoBTS. See https://gerrit.osmocom.org/671

So I'm reopening this until all issues are resolved and all features merged.

The regression that breaks dyn ts is discussed in #1796.
Only marginal patches are still waiting for merge to master.
So I'd say this is 99.9% Done...

I must say I am slightly confused by which ticket refers to which kind of dynamic timeslots.
Anyway:

• TCH/F_TCH/H_PDCH has been committed for osmo-bts-trx, so now working for lc15 and trx.
• TCH/F_PDCH also working for lc15, trx.
• sysmo is working with the revert proposed in #1796.
• The patches still waiting for submission concern
  • channel load indication https://gerrit.osmocom.org/667
  • ts measurement https://gerrit.osmocom.org/675
    • which depends on https://gerrit.osmocom.org/669
  • correct pchan handling in ph_data_req(), actually without known misbehavior https://gerrit.osmocom.org/677
    • which follows 675 and thus also indirectly depends on https://gerrit.osmocom.org/669

All patches discussed above are merged.
Another about stability in absence of a PCU is still waiting, https://gerrit.osmocom.org/748
but closing this issue (new details should be new issues).