1 files changed, 107 insertions, 0 deletions
diff --git a/doc/manuals/chapters/aoip-flows.adoc b/doc/manuals/chapters/aoip-flows.adoc
new file mode 100644
index 000000000..dd9f809c3
--- /dev/null
+++ b/doc/manuals/chapters/aoip-flows.adoc
@@ -0,0 +1,107 @@
+== AoIP message flow examples
+
+The flow diagrams / ladder diagrams of this section are intended to
+provide some examples on how AoIP procedures work.  We hope they will be
+useful in understanding the interface better and aid in debugging any
+related issues.
+
+=== AoIP interface bring-up
+
+This Figure shows the exchange of messages of a BSC when it is
+establishing its AoIP interface from scratch, for example because it has
+just been started up.  We assume the BSC/CN has already been fully
+brought up, so no SCTP/M3U*A bring-up between MSC and STP is dieplayed.
+
+The diagram shows only one possible scenario.
+
+Depending on the MSC implementation, in between the BSC and the MSC
+there may be either
+
+* a dedicated STP (or multiple replicated STPs)
+* no dedicated STP, as the functionality is implemented inside the MSC
+* an entire SS7 network between BSC and MSC, with multiple STP, SGW,
+  elements switching messages from the BSCs to the MSCs.
+
+The configuration details that need to be known to the BSC at start-up
+time are:
+
+* at SCTP level
+** remote IP addresses to which it should establish a SCTP association
+** SCTP port number for M3UA at the STP
+* at M3UA level
+** routing key (0 for none)
+** local BSC-side SS7 point code
+** remote MSC-side SS7 point code
+
+There possibly may be more configuration details, such as
+
+* multiple local and/or remote IP addresses for SCTP multi-homing
+* a fixed local (BSC side) IP address and/or SCTP port (default:
+  dynamic/random)
+
+.AoIP interface bring-up between BSC and MSC
+[mscgen]
+----
+include::../message-sequences/a_interface_bringup.msc[]
+----
+
+For the purpose of clairty, SCTP-level acknowledgement chunks are not
+shown.  Those are automatically generated by the receiver for every
+DATA chunk received in order to confirm its reception and to allow the
+transmitter to re-transmit in case of packet loss.
+
+==== SCTP multi-homing
+
+If SCTP multi-homing is used, the additional IP addresses are typically
+exchanged via additional information elements in the INIT/INIT_ACK
+chunks at connection establishment.  They may also change at a later
+point.
+
+==== MSC pooling
+
+If there is MSC pooling configured, there is typically still only one
+M3UA ASP / SCTP association.  The different MSCs are addressed on the
+SCCP point-code level.  It's the STPs job to route the messages based
+on point codes to the respective MSC.
+
+The BSC will try to establish BSSAP to each of the MSCs in the pool,
+using a separate BSSAP reset procedure to each of the pool members
+point code.
+
+See the Chapter _MSC Pooling_ in the OsmoBSC user manual for
+configuration examples of this situation.
+
+
+=== MO call establishment on AoIP with user plane
+
+The following figure shows a simplified version of the messages between
+MS, OsmoBTS, OsmoBSC, OsmoMGW@BSC, MSC[-Server] and MSC-MGW in during
+the establishment and release of a MO voice call.  Particular focus
+is given on messages related to the establishment of the RTP based
+user plane.
+
+The fact whether or not the RAN or the CN use media gateways, how they
+control their respective media gateway, and whether there are multiple
+media gateways for load distribution is a private implementation detail
+of either RAN or CN.  Either side does not need to know the
+internal structure of the other side, since the RTP endpoint parameters
+are signaled for each call individually over the A interface.
+
+The signaling between the BSC-colocated MGW and OsmoBSC is IETF MGCP
+(Media Gateway Control Protocol).
+
+The signaling between the MSC[-Server] and the MGW is internal to the
+CN. It is typically based on MEGACO/H.248.
+
+As only the BSC and the MSC exchange 3GPP specified signaling messages,
+there is no direct interaction between the RAN and the CN side MGW.
+They only exchange RTP and associated RTCP.
+
+In many real deployments, OsmoMGW will have a different IP address on
+the BTS/Abis facing interface than on the MSC/A facing interface.  As
+a simplification, this has been omitted in the figure.
+
+[mscgen]
+----
+include::../message-sequences/mo_call-bsc-msc-mgw-aoip.msc[]
+----