[[cs7_config]]
== Configure SCCP/M3UA

All CNI programs using SCCP/M3UA act as M3UA ASP role and SCTP client,
expecting to connect to a Signalling Gateway (STP/SG) implementing the M3UA
SG role as SCTP server. The STP/SG then routes M3UA messages between its
ASPs, typically by point-codes.

For an introduction about SCCP/M3UA/SS7/SIGTRAN technology, please see
the chapter _Signaling Networks: SS7 and SIGTRAN_ in the OsmoSTP user
manual.

In an all-Osmocom CNI, the typical simple/minimal usage is:

- OsmoSTP acts as the STP/SG (server role) and routes between the ASP,
- All other Osmocom CNI programs act as SCTP client and provide ASP
  implementations.

For example, in an all-Osmocom minimal setup,

- OsmoMSC contacts an OsmoSTP and subscribes its point-code 0.23.1;
- then OsmoBSC also contacts the same OsmoSTP, subscribes with its own
  point-code 1.23.3.
- Using these established links, OsmoBSC initiates an A-interface link by
  directing a BSSAP RESET message to the MSC's point-code 0.23.1,
- and the RESET ACK response from the MSC is routed back to the BSC's
  point-code 1.23.3.

The details of SCCP/M3UA are configured in the 'cs7' section of the VTY
configuration.

Osmocom programs automatically configure missing SCCP/M3UA configuration, by
assuming sane defaults for small/minimal all-Osmocom installations, which may
not be what you want in larger networks integrating with non-Osmocom core
network elements.

If no explicit `routing-key` is set, it may be determined at runtime by
negotiation with OsmoSTP -- see OsmoSTP manual chapter "Osmocom M3UA Routing
Key Management Extensions", regarding config option `accept-asp-connections
dynamic-permitted`.

The complete active configuration of an Osmocom program can be obtained by the
VTY command `show cs7 config` (the usual `show running-config` omits
automatically configured items). Here is an example of OsmoMSC's default
configuration:

----
OsmoMSC> show cs7 config
cs7 instance 0
 point-code 0.23.1
 asp asp-clnt-OsmoMSC-A-Iu 2905 0 m3ua
  remote-ip 127.0.0.1
  sctp-role client
 as as-clnt-OsmoMSC-A-Iu m3ua
  asp asp-clnt-OsmoMSC-A-Iu
  routing-key 2 0.23.1
----

At the time of writing, SCCP/M3UA links involving Osmocom program are:

- A-interface: OsmoBSC to OsmoMSC
- IuCS-interface: OsmoHNBGW to OsmoMSC
- IuPS-interface: OsmoHNBGW to OsmoSGSN
- Lb-interface: OsmoSMLC to OsmoBSC

On the SCTP/IP level, those connections are actually all established from
the respective program (BSC, MSC, HNBGW, SGSN, SMLC) to OsmoSTP.  Hence,
if you look at the traffic in a protocol analyzer like wireshark, at IP
level, you will see each of those programs establishing an SCTP
association from a random local IP to the well-known SCTP port for M3UA
(2905) at the OsmoSTP.

Those star-connections for M3UA/SCTP then are the transport network for
higher level protocols like SCCP.  OsmoSTP then acts as central router
for SCCP-level message exchange between all the connected programs.

=== Connect to STP Instance

Establishing an SCCP/M3UA link towards a remote STP instance can be configured
as:

----
cs7 instance 0
 asp my-asp 2905 0 m3ua
  # IP address of the remote STP:
  remote-ip 10.23.24.1
  # optional: local bind to a specific IP
  local-ip 10.9.8.7
----

Be aware that such an `asp` needs to be linked to an `as`, see <<as_and_asp>>.

By default, an STP instance is assumed to listen on the default M3UA port
(2905) on the local host. That means in general `127.0.0.1` will be used as
default remote SCTP address, and `::1` will be added to the SCTP association if
IPv6 support is available on the system.

NOTE: OsmoSTP listens by default on `::` if IPv6 is enabled on the system,
and on `0.0.0.0` otherwise. Address `::` actually superseeds `0.0.0.0`, meaning
it will listen on all IPv4 and IPv6 addresses available on the system.

CAUTION: Some applications overwrite the default target remote address to
be `localhost`. If IPv6 support is available on the system, `localhost` will
usually resolve to `::1`, otherwise it will usually resolve to `127.0.0.1`.

=== Local Point-Code

Each CNI program on an SCCP/M3UA link typically has a local point-code,
configurable by:

----
cs7 instance 0
 point-code 7.65.4
----

If an explicit routing context is configured, this point-code is repeated in
the `routing-key` configuration:

----
cs7 instance 0
 point-code 0.23.1
 as my-as m3ua
  routing-key 2 0.23.1
----

See also <<point_code_format>>.

=== Remote Point-Code

Programs establishing communication across SCCP links need a remote SCCP
address, typically by point-code, to contact.

For example,

- OsmoBSC needs to know the MSC's point-code, to be able to establish the A-interface.
- OsmoHNBGW needs to know the MSC's point-code, to be able to establish the IuCS-interface.
- OsmoHNBGW needs to know the SGSN's point-code, to be able to establish the IuPS-interface.

To maintain remote SCCP addresses, each `cs7` instance maintains an SCCP address book:

----
cs7 instance 0
 sccp-address remote-pc-example
  point-code 1.23.1
----

This address book entry on its own has no effect. It is typically referenced by
specific configuration items depending on the individual programs.

Examples:

- An OsmoBSC configures the MSC's remote SCCP address:

----
cs7 instance 0
 sccp-address my-remote-msc
  point-code 1.23.1
msc 0
 msc-addr my-remote-msc
----

- An HNBGW configures both the remote MSC's and SGSN's SCCP addresses:

----
cs7 instance 0
 sccp-address my-msc
  point-code 0.23.1
 sccp-address my-sgsn
  point-code 0.23.2
hnbgw
 iucs
  remote-addr my-msc
 iups
  remote-addr my-sgsn
----

Besides a point-code, an SCCP address can have several routing indicators:

- PC: routing by point-code is the default for Osmocom.
- GT: routing by Global Title is configurable by `routing-indicator GT`.
- IP: routing by IP address is configurable by `routing-indicator IP`.

In OsmoSTP, only routing by point-code is currently implemented.

[[point_code_format]]
=== Point-Code Format

Point-codes can be represented in various formats. For details, see OsmoSTP
manual, chapter "Point Codes".

By default, Osmocom uses a point-code representation of 3.8.3, i.e. first digit
of 3 bit, second digit of 8 bit, and third digit of 3 bit.

----
cs7 instance 0
 point-code format 3 8 3
 point-code 0.23.1
----

Often, point-codes are also represented as a single decimal number:

----
cs7 instance 0
 point-code format 24
 point-code 185
----

It is also possible to use a dash as delimiter.

----
cs7 instance 0
 point-code delimiter dash
 point-code 0-23-1
----


[[as_and_asp]]
=== AS and ASP

Each CNI program needs at least one Application Server `as` and one Application
Server Process `asp` configured on its `cs7` to be able to communicate on
SCCP/M3UA. An `asp` needs to be part of at least one `as`. For details, see the
OsmoSTP manual, chapters "Application Server" and "Application Server Process".

In Osmocom's `cs7`, any amount of `as` and `asp` can be configured by name, and
an `as` references the `asp` entries belonging to it by their names.

In a simple/minimal Osmocom setup, an Osmocom CNI program would have exactly
one `as` with one `asp`.

For example:

----
cs7 instance 0
 asp my-asp 2905 0 m3ua
  # where to reach the STP:
  remote-ip 127.0.0.1
  sctp-role client
 as my-as m3ua
  asp my-asp
----

In Osmocom CNI programs, it is possible to omit the `as` and/or `asp` entries,
which the program will then attempt to configure automatically.

When configuring both `as` and `asp` manually, make sure to link them by name.
For example, the following configuration will *fail*, because `as` and `asp`
are not linked:

----
cs7 instance 0
 asp my-asp 2905 0 m3ua
  remote-ip 127.0.0.1
 as my-as m3ua
  routing-key 2 0.23.1
----

To *fix* above config, link the `asp` to an `as` by adding `asp my-asp`:

----
cs7 instance 0
 asp my-asp 2905 0 m3ua
  remote-ip 127.0.0.1
 as my-as m3ua
  asp my-asp
  routing-key 2 0.23.1
----

=== Subsystem Number (SSN)

Osmocom CNI programs typically route SCCP/M3UA messages by PC+SSN: each ASP,
having a given SCCP address, receives messages for one or more specific
subsystems, identified by a Subsystem Number (SSN).

For example, the A-interface between BSC and MSC uses SSN = BSSAP (254). In
Osmocom programs, SSNs do not need to be configured; they implicitly, naturally
relate to the interfaces that a program implements.

For example, OsmoBSC takes the configured remote MSC's SCCP address and adds
the SSN = BSSAP to it in order to contact the MSC's A-interface. To receive
A-interface messages from the MSC, OsmoBSC subscribes a local user for this SSN
on the ASP.

=== Routing Context / Routing Key

In SCCP/M3UA, messages can be routed by various Routing Indicators (PC+SSN, PC,
GT, ...). Osmocom CNI programs typically use PC+SSN as Routing Indicator.

On the SG (for example OsmoSTP), each ASP's distinct Routing Indicator needs to
be indexed by a distinct Routing Context (a simple index number scoped per SG),
to forward M3UA to the correct peer.

The Osmocom SG implementation employs Routing Key Management (RKM, see OsmoSTP
manual) to automatically determine a distinct Routing Context index for each
connected ASP. Routing Contexts can also be configured manually -- some
non-Osmocom SG implementations require this.

Each Routing Context is associated with a Routing Indicator and address; this
association is called a Routing Key.

For example, to configure an OsmoBSC with a local point-code of 1.23.3 to
receive M3UA with Routing Context of 2 and RI=PC:

----
cs7 instance 0
 point-code 1.23.3
 as my-as m3ua
  routing-key 2 1.23.3
----

Osmocom programs so far implement Routing Keys by Destination Point Code (DPC),
plus optional Subsystem Number (SSN) and/or Service Indicator (SI):

----
routing-key RCONTEXT DPC
routing-key RCONTEXT DPC si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)
routing-key RCONTEXT DPC ssn SSN
routing-key RCONTEXT DPC si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup) ssn SSN
----

==== M3UA without Routing Context IE / Routing Context '0'

As per the M3UA specification, the use of the routing context IE is
optional as long as there is only one AS within an ASP.  As soon as
there are multiple different AS within one ASP, the routing context IE
is mandatory, as it is the only clue to differentiate which of the ASs a
given message belongs to.

In the Osmocom M3UA implementation, it is generally assumed that a
routing context IE is always used, for the sake of clarity.

However, the routing context ID of '0' has the special meaning of _do
not encode a routing context IE on transmit_.

So if you configure an application like OsmoBSC to use routing context
0, then no routing context IE will be included in outbound M3UA
messages.

This special interpretation of '0' within the Osmocom M3UA
implementation however means that we can not represent M3UA with a
routing context IE that actually contains '0' as a numeric identifier.

So you only have the following options:
* Using M3UA with routing context (1..N)
* Using M3UA without routing context (0)
