Project

General

Profile

Actions

Feature #4940

open

VAMOS support in OsmoBSC

Added by laforge about 3 years ago. Updated over 2 years ago.

Status:
Stalled
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
01/12/2021
Due date:
% Done:

60%

Spec Reference:

Description

This ticket should document what needs to be done in terms of supporting VAMOS from OsmoBSC, and to track its status via check-lists and possibly sub-issues.

3GPP unfortuantely doesn't provide any specifications for VAMOS beyond the radio interface. Neither A-bis OML nor RSL specs did receive any related updates.

On an abstract level, we (IMHO) have the following problem domains:
  1. how to represent the second user for each lchan
  2. how to configure VAMOS via OML
  3. how to represent the VAMOS channels on RSL
  4. how to include VAMOS decisions in the channel allocator for assignment and hand-over

as for the "representation" and "RSL" side, my idea would be to use the concept of "shadow TRX", i.e. introduce a second, logical TRX for each real TRX. Then one subscriber is on the "real" TRX and the other subscriber on the "shadow" TRX. Our data structures and RSL currently have at leaset uint8_t for the TRX number, and in reality no more than 12 TRX are ever expected in one BTS. This means we could e.g. use one of the higher-order bits to decide between real / shadow. So e.g.

  • TRX number (and IPA stream ID) 0x00: TRX 0 (real)
  • TRX number (and IPA stream ID) 0x01: TRX 1 (real)
  • TRX number (and IPA stream ID) 0x80: TRX 0 (shadow)
  • TRX number (and IPA stream ID) 0x81: TRX 1 (shadow)
  • ...

Checklist

  • parse VAMOS capabilities from CM3 and store in subscr_conn
  • specify in detail how "shadow" TRX will be handled inside BSC and on Abis
  • implement whatever is needed for "RR assignment, Channel Mode Modify + Handover Command" of a VAMOS channel
  • learn VAMOS capabilities of BTS via newly-invented OML attributes
  • define how admin can configure whether VAMOS shall be used or not; only use when MS CM3 + BTS capabilites + config permit
  • make channel allocator VAMOS-aware
  • TTCN3 tests for Abis related bits; unit tests for channel allocator

Related issues

Related to OsmoBTS - Feature #4941: VAMOS support in OsmoBTSStalledfixeria01/12/2021

Actions
Actions #1

Updated by laforge about 3 years ago

  • Checklist item parse VAMOS capabilities from CM3 and store in subscr_conn added
  • Checklist item specify in detail how "shadow" TRX will be handled inside BSC and on Abis added
  • Checklist item implement whatever is needed for "RR assignment" of a VAMOS channel added
  • Checklist item learn VAMOS capabilities of BTS via newly-invented OML attributes added
  • Checklist item define how admin can configure whether VAMOS shall be used or not; only use when MS CM3 + BTS capabilites + config permit added
  • Checklist item make channel allocator VAMOS-aware added
  • Checklist item TTCN3 tests for Abis related bits; unit tests for channel allocator added
Actions #2

Updated by laforge about 3 years ago

  • Checklist item changed from implement whatever is needed for "RR assignment" of a VAMOS channel to implement whatever is needed for "RR assignment, Channel Mode Modify + Handover Command" of a VAMOS channel
Actions #3

Updated by laforge about 3 years ago

Actions #4

Updated by laforge about 3 years ago

In OS#4941, @ewild has referred to https://opus4.kobv.de/opus4-fau/files/5533/DissertationMichaelRuder.pdf chapter 4 where different radio resourece allocation schemes are discussed. The simplest approach seems to be to go for SCPIR=0 (equal power on both MS in the pair) and "random" pairing of users.

I think OsmoBSC should also have a configurable overlal pairing strategy,
  • do not use VAMOS
  • always use VAMOS (when possible by UE + MS), even if we have plenty of free channels (nice for testing of VAMOS without having to establish dozens of calls)
  • only start to use VAMOS once we run out of channels
Actions #5

Updated by laforge over 2 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 60

neels, I think this ticket is in desparate need of update/

Actions #6

Updated by neels over 2 years ago

  • Checklist item parse VAMOS capabilities from CM3 and store in subscr_conn set to Done
  • Checklist item specify in detail how "shadow" TRX will be handled inside BSC and on Abis set to Done
  • Checklist item implement whatever is needed for "RR assignment, Channel Mode Modify + Handover Command" of a VAMOS channel set to Done
  • Checklist item learn VAMOS capabilities of BTS via newly-invented OML attributes set to Done
Actions #7

Updated by neels over 2 years ago

VAMOS support in OsmoBSC is in a state that allows manual testing (provided a VAMOS capable BTS is available, so far only osmo-bts-trx; so far there is VAMOS support in osmo-trx though).
So it is possible to connect a BTS that indicates BTS_FEAT_VAMOS, and then issue manual VTY commands to:

  • change an active voice call into VAMOS mode (in-place);
  • move another active voice call onto the secondary shadow lchan of the first voice call.

The above is merged to OsmoBSC master branch.

There is no work at all yet on activating VAMOS in the automatic channel allocation / congestion resolution.

Actions #8

Updated by neels over 2 years ago

On Fri, Jul 02, 2021 at 05:06:52PM +0000, neels [REDMINE] wrote:

so far there is VAMOS support in osmo-trx though

so far there is NO VAMOS support in osmo-trx though

Actions #9

Updated by neels over 2 years ago

  • Status changed from In Progress to Stalled

VAMOS implementation in OsmoBSC is ready for manual testing: switch channels to VAMOS via telnet VTY.
Waiting for a VAMOS capable phy to confirm basic VAMOS operation.
When basic testing is successful, we'll look into automatic switching to/from VAMOS mode in OsmoBSC.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)