doc: Document use of Osmux in IPA Abis against OsmoBTS

Related: SYS#5987
Change-Id: I41788f8d3bc29735cc30516f429311b73ba71910
This commit is contained in:
Pau Espin 2022-09-14 13:11:03 +02:00 committed by pespin
parent 57c2e68da2
commit 3dca75e1e2
1 changed files with 47 additions and 8 deletions

View File

@ -14,14 +14,14 @@ one) need to be configured explicitly.
==== {program-name} in a 3GPP AoIP network setup
Osmux usage in {program-name} in managed through the VTY command `osmux
(on|off|only)`. Once enabled (`on` or `only`), {program-name} will start
appending the vendor specific _Osmux Support_ IE in _BSSMAP RESET_ and _BSSMAP
RESET-ACK_ message towards the MSC in order to announce it supports Osmux. This
way, the MSC can decide whether to use Osmux or not based on this information
when setting up a call (this time using _Osmux CID_ IE). It should be noted that
this option should not be enabled unless MSC managing {program-name} supports
handling this extension IE (like OsmoMSC), a 3rd-party MSC might otherwise
refuse the related _RESET_/_RESET-ACK_ messages.
(on|off|only)` under the `msc` node. Once enabled (`on` or `only`),
{program-name} will start appending the vendor specific _Osmux Support_ IE in
_BSSMAP RESET_ and _BSSMAP RESET-ACK_ message towards the MSC in order to
announce it supports Osmux. This way, the MSC can decide whether to use Osmux or
not based on this information when setting up a call (this time using _Osmux
CID_ IE). It should be noted that this option should not be enabled unless MSC
managing {program-name} supports handling this extension IE (like OsmoMSC), a
3rd-party MSC might otherwise refuse the related _RESET_/_RESET-ACK_ messages.
{program-name} will behave differently during call set up based on the VTY
command presented above:
@ -41,3 +41,42 @@ command presented above:
calls on the CN-side, this is, if _BSSMAP Assign Request_ from MSC doesn't
contain an _Osmux CID_ IE, it will reject the assignment and the call set up
will fail.
==== Osmux in the ip.access Abis interface
{program-name} can also talk Osmux instead of RTP to an OsmoBTS which supports
the feature. Osmux usage agains the BTS in {program-name} in managed through the
VTY command `osmux (on|off|only)` under the `bts` node.
If a BTS supports Osmux, it may announce the _OSMUX_ BTS feature towards the BSC
over OML. This way, the {program-name} becomes aware that this BTS supports
using Osmux to transfer voice call user data when the AMR codec is selected.
It is then up to {program-name} to decide whether to use Osmux or not when
establishing a new call. If {program-name} decides to use Osmux for a given
call, it will instruct its co-located MGW to set up an Osmux connection in the
endpoint (using the `X-Osmux extension`) and then it will forward the received
Osmux CID to the BTS in the the _IPACC CRCX/MDCX_ messages by means of an extra _Osmux
CID_ IE appended to it.
The IP address and port provided in the same messages refer to the
address and port where Osmux frames with the provided CID are expected to be
received. Similarly, the BTS appends an _Osmux CID_ IE to the _IPACC
CRCX/MDCX ACK_ message it generates, this time with its own local Osmux CID,
which {program-name} will in turn forward back to the co-located MGW.
Same goes for the BTS' local IP address and port where Osmux frames are expected
to be received.
{program-name} will behave differently during call set up based on the VTY
command `use (on|off|only)` under each `bts` node presented above:
* `off`: {program-name} will never attempt use of Osmux against this BTS (default).
* `on`: {program-name} will use Osmux against the BTS if the BTS announced Osmux
support during OML bringup, and if MGW provided a valid Osmux CID during _MGCP
CRCX_. Otherwise BSC will simply automatically fall back to using RTP for each
call. For non-AMR calls, RTP will always be used.
* `only`: Same as per `on`, except that {program-name} will accept only Osmux
calls on the BTS-side. This is, if _MGCP CRCX ACK_ from MGW doesn't
contain an _Osmux CID_ IE or _IPACC CRCX ACK_ from BSC doesn't
contain an _Osmux CID_ IE, it will reject the assignment and the call set up
will fail. This means also that only AMR calls (`Channel Mode GSM3`) are
allowed.