Project

General

Profile

Feature #4940

VAMOS support in OsmoBSC

Added by laforge about 2 months ago. Updated about 2 months ago.

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

0%

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 OsmoBTSIn Progress01/12/2021

History

#1 Updated by laforge about 2 months 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

#2 Updated by laforge about 2 months 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

#3 Updated by laforge about 2 months ago

#4 Updated by laforge about 2 months 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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)