doc: Document use of Osmux in IPA Abis against OsmoBTS

Related: SYS#5987
Change-Id: I41788f8d3bc29735cc30516f429311b73ba71910

1 files changed, 47 insertions, 8 deletions

diff --git a/doc/manuals/chapters/osmux_bsc.adoc b/doc/manuals/chapters/osmux_bsc.adoc
index 0a11d17bf..268ffdfc8 100644
--- a/doc/manuals/chapters/osmux_bsc.adoc
+++ b/doc/manuals/chapters/osmux_bsc.adoc
@@ -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.