Project

General

Profile

Feature #1565

Dynamic PDCH / TCH switching: BTS part

Added by laforge almost 2 years ago. Updated over 1 year ago.

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

100%

Estimated time:
12.00 h
Spec Reference:

Description

this involves PCU, BTS and BSC. This ticket is about the BTS part of it.


Related issues

Related to OsmoPCU - Feature #1551: dynamic timeslot allocations (TCH / SDCCH vs PDCH) 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
Related to OpenBSC - Feature #1567: Dynamic PDCH / TCH switching: BSC part Closed 02/23/2016 06/10/2016
Related to OsmoBTS - Bug #1796: PTCCH activation breaks dyn TS Closed 08/10/2016

History

#1 Updated by laforge almost 2 years ago

  • Estimated time set to 12.00
OsmoBTS needs to be extended to
  • 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

#2 Updated by laforge almost 2 years ago

  • Related to Feature #1551: dynamic timeslot allocations (TCH / SDCCH vs PDCH) added

#3 Updated by laforge almost 2 years ago

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

#4 Updated by laforge almost 2 years ago

  • Related to Feature #1567: Dynamic PDCH / TCH switching: BSC part added

#6 Updated by laforge over 1 year ago

  • Priority changed from Normal to High

#8 Updated by laforge over 1 year ago

  • Due date set to 06/10/2016

#9 Updated by laforge over 1 year ago

  • Priority changed from High to Urgent

#10 Updated by laforge over 1 year ago

  • Assignee set to neels

#11 Updated by neels over 1 year ago

  • Subject changed from Dynamic PDCH / TCH switching to Dynamic PDCH / TCH switching: BTS part

#12 Updated by neels over 1 year ago

  • File two_calls_then_gprs_starts_working.patch added
  • File two_calls_then_gprs_starts_working.nitb.log added
  • File two_calls_then_gprs_starts_working.pcapng added
  • % Done changed from 0 to 20

(comment moved to #1567)

#13 Updated by neels over 1 year ago

  • Status changed from New to In Progress

#14 Updated by neels over 1 year ago

(comment moved to #1567)

#15 Updated by neels over 1 year ago

  • % Done changed from 20 to 30

(comment moved to #1567)

#16 Updated by neels over 1 year ago

(comment moved to #1567)

#17 Updated by neels over 1 year ago

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.

#18 Updated by neels over 1 year ago

  • % Done changed from 30 to 10
  • 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

#19 Updated by neels over 1 year ago

  • File deleted (two_calls_then_gprs_starts_working.patch)

#20 Updated by neels over 1 year ago

  • File deleted (two_calls_then_gprs_starts_working.nitb.log)

#21 Updated by neels over 1 year ago

  • File deleted (two_calls_then_gprs_starts_working.pcapng)

#22 Updated by neels over 1 year ago

  • % Done changed from 10 to 30

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

#23 Updated by neels over 1 year ago

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.

#24 Updated by neels over 1 year ago

  • % Done changed from 30 to 50

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.

#25 Updated by laforge over 1 year ago

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

#26 Updated by neels over 1 year ago

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.

#27 Updated by neels over 1 year ago

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.

#28 Updated by neels over 1 year ago

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.

#29 Updated by neels over 1 year ago

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 */

#30 Updated by neels over 1 year ago

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

#31 Updated by neels over 1 year ago

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.

#32 Updated by neels over 1 year ago

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.

#33 Updated by neels over 1 year ago

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

#34 Updated by neels over 1 year ago

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

#35 Updated by neels over 1 year ago

  • % Done changed from 50 to 80

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.

#36 Updated by neels over 1 year ago

  • Checklist item sysmoBTS added
  • Checklist item litecell15 added
  • Checklist item trx added

#37 Updated by neels over 1 year ago

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

#38 Updated by neels over 1 year ago

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

#39 Updated by neels over 1 year ago

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.

#40 Updated by neels over 1 year ago

  • Checklist item litecell15 set to Done
  • % Done changed from 80 to 90

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)

#41 Updated by neels over 1 year ago

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)

#42 Updated by neels over 1 year ago

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

#43 Updated by laforge over 1 year ago

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

#44 Updated by laforge over 1 year ago

  • Checklist item trx set to Done
  • % Done changed from 90 to 100

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

#45 Updated by laforge over 1 year ago

  • Status changed from In Progress to Closed

#46 Updated by neels over 1 year ago

  • Status changed from Closed to In Progress
  • % Done changed from 100 to 90

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.

#47 Updated by neels over 1 year ago

  • Related to Bug #1796: PTCCH activation breaks dyn TS added

#48 Updated by neels over 1 year ago

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:

#49 Updated by neels over 1 year ago

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

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

#50 Updated by laforge over 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF