346 lines
11 KiB
Plaintext
346 lines
11 KiB
Plaintext
[[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)
|