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
