Project

General

Profile

Feature #1757

determine strategy for fully dynamic PDCH, TCH/F and TCH/H channel

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

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

100%

Spec Reference:

Description

After we now have TCH/F and PDCH dynamic switching, the next step is to go fully dynamic.

The question is how to do this best. One way would be to extend on the way how it is done in Abis/IP for the existing TCH/F+PDCH switching. So we'd not only have an "ACTIVATE/DEACTIVATE PDCH" message, but also something like a more generic proprietary "SET CHANNEL COMBINATION" message.

In theory, I believe all of this should also be possible in a much more interoperable way by OML. The procedure would be:
  • ensure that RSL has all logical channels released on the timeslot
  • take the CHANNEL (timeslot) MO offline
  • change the channel combination by OML SET CHANNEL ATTRIBUTE to the MO
  • bring the MO online again (OPSTART)

The advantage of the latter solution is that it should in principle work with any BTS model, and it doesn't even require any special support fro that BTS. However, it involves of course many more transactions and is thus the more complex operation.

There's also a lot more complexity to the lchan allocator, as a PDCH mode can of course only be enabled if both TCH/H on the timeslot are free, but that complexity exists irrespective of the mechanism we use for performing the actual switching.

Neels, please think about this in the context of your current exposure to the related code base and make a proposal how you'd think is a good way to implement the related feature. Please also estimate the amount of time you think it takes for development and testing.


Related issues

Related to OsmoBTS - Bug #1564: dynamic TCH/F + TCH/H allocation Closed 02/23/2016

History

#1 Updated by neels over 1 year ago

Indeed, the current implementation of TCH/F_PDCH switching shows that the only
BTS-specific thing needed is disconnecting and reconnecting a channel with any
desired GsmL1_LogChComb_*.

Also added to the BTS was the messaging of the IPAC_PDCH_ACT and DEACT, i.e. the
RX as well as ACK TX. In the light of more general OML messages, these would
become obsolete.

One problem that I already know of: it seems that before dyn PDCH as it
is now, our BTS implementations did not have any code to disconnect a TS
(the GsmL1_PrimId_MphDisconnectReq was not used anywhere before).
So the taking down of a CHANNEL OML is probably not implemented anywhere.
The dyn PDCH so far does it only for the IPAC_PDCH_DE/ACT messages, so
all BTS implementations would need to be adjusted for that.

A note on TCH/H: jolly's dyn PDCH branch also features some channel defrag
code, which triggers handovers from one TS to another to maximize the number
of consequtive TS used. This would make a lot of sense when two TCH/H are
spread across two TS and could be combined to make way for a PDCH, for example.
But first, I would go for simply taking the TS as they are -- iff a TS is
unused, it may be switched. The defrag feature would be benificial for
dynamic switching but is essentially independent, implementation wise.

The OML proposal makes a lot of sense to me, but I'll come back with estimations
when I've had a closer look.

#2 Updated by laforge over 1 year ago

I just studied Ericsson OM2000 again over the weekend, and they only have one "TCH/F or TCH/H or PDCH" channel configuration that is set by OML. see also the pchan2comb() function in abis_om2000.c

Such timeslots can then receive RSL CHAN ACT for TCH/F or TCH/H. Even PDCH actiavation seems to be using a RSL CHAN ACT with a non-standard Channel Number IE (we don't implement any GPRS support for Ericsson/Nokia/Siemens yet, but that might be something on our agenda at some point).

So it seems like they're closer to what IPA is doing, but in a more elegant and generic way - which speaks more for a solution that doesn't touch the more complex OML transactions. So even if I believe that an OML based solution would be the proper way, I'm not convinced it will do us any good, if the other BTS models (we know of) don't do it :/

#3 Updated by neels over 1 year ago

Currently, we can switch TCH/F <-> PDCH on sysmoBTS and lc15.
Switchover state is by fixed "TCH/F_PDCH" pchan config
and two bits indicating PDCH ACT and DEACT, respectively.
Switchover itself is so far by the IPAC_PDCH_ACT and _DEACT messages,
where a DEACT always goes back to TCH/F implicitly.

Now, we would also like to switch to/from TCH/H.
One could want to also switch SDCCH dynamically; we're not really interested in that now,
but it would make sense to allow for more channel types when planning TCH/H now.

In the light of IPAC_PDCH_ACT and _DEACT messages, it would be easiest to have a fixed
config of either TCH/F_PDCH or TCH/H_PDCH, so that the ACT and DEACT is a bump operation
to go to or back from PDCH mode with the TCH/* type fixed.

Above RSL CHAN ACT with an added IE to indicate which type to switch to is indeed
more elegant: during runtime, one could switch between TCH/H and TCH/F as well.

Even more elegant would be to switch a TS using OML, but it seems that there is no standard
"OPSTOP" like OML message to take down a TS, like the opposite of an OPSTART. This would explain
why there are vendor specific additions to the protocol to do channel pchan switching.

I will thus plan for a new TS type and RSL CHAN ACT with nonstandard Channel Number IE,
as described above.

#4 Updated by neels over 1 year ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Things to be done and working hours needed as estimated:

1. Adjust general structures (1h)

1.1 enum gsm_phys_chan_config: GSM_PCHAN_DYN

1.2 struct gsm_lchan: state machine for chan type transitions

2. openbsc (12h total, optional +16h)

2.1 initialization as PDCH: question: implicit or explicit?

  • For reference: in ip.access TCH/F_PDCH, default type is TCH/F, and
    nm_statechg_event() sends PDCH ACT immediately after init.
    We could do the same: in the BTS code, initialize as TCH/F, and in
    nm_statechg_event() trigger a channel state transition to PDCH.
  • This feels very heavy on messages though, we could just imply on the
    BTS side that a DYN channel always starts off as PDCH --> no further
    initialization messages needed from the BSC side.
  • How does the ericsson BTS expect this?

2.2 lchan_alloc(): pick and switch dyn channels (4h)

The initial strategy for picking channels will be fairly straightforward in
that a TS will be picked iff it is fully available. More complex scenarios may
be solved by implementing the TS defragmentation as in 2.4 below.

  • pick matching dedicated pchan first if available
  • TCH/H: pick second TCH/H if such TS is used only by half
  • otherwise pick DYN TS that is in PDCH mode and switch to TCH/*

2.3 channel type transition steps from BSC perspective (8h)

  • BTS indicates the need for a TCH/* channel
  • rsl_rx_chan_rq() calls lchan_alloc() and gets a DYN channel in PDCH mode
  • rsl_rx_chan_rq() then invokes rsl_chan_activate_lchan()
  • rsl_chan_activate_lchan(): detect need to change type, send chan rel
  • BTS releases channel
  • rsl_rx_rf_chan_rel_ack(): register release, send chan act in TCH/* type
  • BTS activates channel
  • rsl_rx_chan_act_ack(): register act, continue in rsl_chan_activate_lchan()
  • TCH/* is used...
  • BTS sends rel ind as usual
  • BSC sends chan rel as usual
  • rsl_rx_rf_chan_rel_ack(): notices a DYN channel is released in TCH/* mode
    • If half a TCH/H TS is still used, do not continue with PDCH act
  • rsl_rx_rf_chan_rel_ack(): sends chan act in PDCH type
  • rsl_rx_chan_act_ack(): register act as PDCH, DYN available for lchan_alloc()

2.4 Optional: TS defragmentation (16h)

  • Upon each channel release, do handover within TRX to eliminate gaps
  • There is some untested defrag code adjusted from jolly in branch
    neels/dyn_pdch_extra
  • Possibly combine two half-used TCH/H TS

3. osmo-bts common implementation (8h total)

3.2 channel type switching: implicit TS disconnect (4h)

  • rsl_rx_chan_rel(): usual release will lead to l1sap_info_rel_cnf()
  • l1sap_info_rel_cnf(): disconnect DYN TS in L1, to be able to switch type
    • use new bts_model_ts_disconnect(), expecting disconnect callback
      (dyn_pdch_ts_disconnected(), probably rename to dyn_ts_disconnected)
    • in callback, continue l1sap_info_rel_cnf() to send RSL_RF_CHAN_REL ACK

3.3 channel type switching: implicit TS connect (4h)

  • rsl_rx_chan_activ(): first connect DYN TS in different type
    • use new bts_model_ts_connect() with callback
      (dyn_pdch_ts_connected(), probably rename to dyn_ts_connected)
    • in callback, continue with rsl_rx_chan_activ() procedure
      leading to RSL_CHAN_ACTIV ACK

4. BTS model specific implementations (6h total + optional 4h)

  • Implement:
    • bts_model_opstart(): start DYN channels in default mode (PDCH? see above)
    • ensure bts_model_ts_connect() and bts_model_ts_disconnect() are implemented
  • on these models:
    • sysmoBTS (1h, because bts_model_ts_* already implemented)
    • litecell15 (1h, because bts_model_ts_* already implemented)
    • osmo-trx (4h)
    • octphy? (4h)

5. Testing (19.5h + optional 6.5h)

  • Test these things (1.5h / 2.5h)
    • a) GPRS initially working? (.5h)
    • b) TCH/F voice working? (.5h)
    • c) TCH/H voice working? (.5h)
    • d) PDCH TS still working after it switched back from TCH/*? (.5h)
    • e) dedicated pchan preferred over DYN TS? (.5h)
  • In these scenarios (6.5h)
    • 1 No DYN channels (test against regressions) (a-c: 1.5h)
    • 2 All channels as DYN (a-e: 2.5h)
    • 3 realistic: few dedicated PDCH, all others DYN (a-e: 2.5h)
  • On these models
    • sysmoBTS
    • litecell15
    • osmo-trx
    • octphy?

6. Effort estimation

Summing up, I have

1. 1h
2. 12h + 16h TS defrag
3. 8h
4. 6h + 4h octphy
5. 19.5h + 6.5h octphy

Some things may not work as expected or take longer to implement, thus I would
like to add a grace of three days (+24h). Highest uncertainty in decreasing
order: octphy, osmo-trx, TS defrag, general testing, channel allocator.

Total: 46.5h + 24h grace + 16h TS defrag + 10.5h octphy

My final estimation is thus two of my working weeks (70.5h)
plus two days for TS defrag and another generous day for octphy,
say three weeks for the whole package.

I hope this estimate makes sense to you. It is hard to estimate software
engineering progress in advance; while I don't want to stop the show with huge
numbers, it usually turns out realistic to estimate generously.

I am mildly optimistic in this case since I'm familiar with most of the
implementations from the recent addition of IPAC_PDCH_[DE]ACT on ip.access
nanobts, SysmoBTS and litecell15.

OTOH I am not yet familiar with osmo-trx at all and have minimal experience
with octphy. I would still need to set up a tool chain and test environment
for both.

#5 Updated by neels over 1 year ago

neels wrote:

Even more elegant would be to switch a TS using OML, but it seems that there is no standard
"OPSTOP" like OML message to take down a TS, like the opposite of an OPSTART. This would explain
why there are vendor specific additions to the protocol to do channel pchan switching.

Disclaimer: I'm not really sure that this conclusion is accurate.

To be precise, this is about an OPSTART of a CHANNEL object as in:

<0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)·
<0005> bts_ipaccess_nanobts.c:359 Rx NM_OC_CHANNEL for TRX 0 TS 0
<0005> abis_nm.c:1658 Set Chan Attr (bts=0,trx=0,ts=0)
<0005> abis_nm.c:1765 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART
<0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)·
<0005> bts_ipaccess_nanobts.c:359 Rx NM_OC_CHANNEL for TRX 0 TS 1
<0005> abis_nm.c:1658 Set Chan Attr (bts=0,trx=0,ts=1)
<0005> abis_nm.c:1765 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART
<0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)·
<0005> bts_ipaccess_nanobts.c:359 Rx NM_OC_CHANNEL for TRX 0 TS 2
<0005> abis_nm.c:1658 Set Chan Attr (bts=0,trx=0,ts=2)
[...]

#6 Updated by neels over 1 year ago

neels wrote:

it seems that there is no standard "OPSTOP" like OML message to take down a TS,
like the opposite of an OPSTART.

In 3GPP TS 12.21, there's the 8.9.3 Reinitialize message. So we could SET CHAN ATTR
followed by this Reinitialize, though it's unlikely that this works with any BTS.

In our own BTS implementations we could of course also just send a SET CHAN ATTR
to switch a channel, even though the OPSTART has already been issued...

With a complex object model like OML I would have expected a kind of OPSTOP to
exist. It is hard to believe that this is plainly missing.

#7 Updated by neels over 1 year ago

To clarify the scopes of dynamic channel switching:

  • The ip.access PDCH ACT (#1565, #1567) feature is independent of the
    more general dynamic feature discussed here. We will keep the ip.access
    messaging regardless, because we would like to be able to e.g. operate
    a SysmoBTS in ip.access compatibility mode with a different kind of BSC,
    and OpenBSC will keep the ip.access messages to operate a nanobts with it.
  • This more general channel switching feature would be implemented in
    parallel to the ip.access PDCH switching, with a new, proprietary pchan
    type to distinguish.

@Harald, in a private mail you mention "bts_type == 'sysmobts'", but so
far I'm assuming that we want to have this on lc15, osmo-trx and octphy(?)
as well. Please confirm -- thanks!

#8 Updated by laforge over 1 year ago

On Tue, Jun 28, 2016 at 12:49:38PM +0000, neels [REDMINE] wrote:

@Harald, in a private mail you mention "bts_type 'sysmobts'", but so
far I'm assuming that we want to have this on lc15, osmo-trx and octphy(?)
as well. Please confirm -- thanks!

As you may have noticed, you generally use 'bts_type sysmobts' in
openbsc.cfg when talking to osmo-bts as BTS implementation, no matter
if you use osmo-bts-{sysmo,trx,octphy}. This is of course not correct,
and just for historical reasons. There's #1614 about this.

basically osmo-bts should start to notify the BSC about the detailed bts
variant as well as some kind of feature matrix, so the BSC can then
adjust its behavior accordingly.

So getting back to your question: Of course it should work for
sysmobts/lc15/octphy/trx, but all of those are 'bts_type symsobts' from
OpenBSC point of view at this point.

--
- Harald Welte &lt;&gt; http://laforge.gnumonks.org/
==========================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)

#9 Updated by laforge over 1 year ago

  • Related to Bug #1564: dynamic TCH/F + TCH/H allocation added

#10 Updated by neels over 1 year ago

neels wrote:

With a complex object model like OML I would have expected a kind of OPSTOP to
exist. It is hard to believe that this is plainly missing.

As a side note, I have now seen a situation where a RADIO-CARRIER and CHANNEL objects
received a second OPSTART. However, the BTS announced the OP_STATE = Disabled,
followed by the BSC sending another OPSTART. (the default osmo-bts-trx startup sequence)

We were looking for a state change initiated by the BSC, so that's still no "OPSTOP"
that would be useful here.

#11 Updated by laforge over 1 year ago

  • Status changed from Resolved to Closed

#12 Updated by laforge over 1 year ago

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

Also available in: Atom PDF