Feature #4940
openVAMOS support in OsmoBSC
60%
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:- how to represent the second user for each lchan
- how to configure VAMOS via OML
- how to represent the VAMOS channels on RSL
- 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
Updated by laforge over 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
Updated by laforge over 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
Updated by laforge over 3 years ago
- Related to Feature #4941: VAMOS support in OsmoBTS added
Updated by laforge over 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
Updated by laforge almost 3 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/
Updated by neels almost 3 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
Updated by neels almost 3 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.
Updated by neels almost 3 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
Updated by neels almost 3 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.