Configuring SIGTRAN M3UA as an Application Server Process
M3UA enables SS7 user parts such as ISUP and SCCP to operate across an IP network. Instead of sending signaling over traditional TDM links, an Application Server Process (ASP) uses SCTP to reach a Signaling Gateway (SG) or another signaling endpoint.
A reliable configuration depends on more than entering point codes and IP addresses. The administrator must define the Application Server, assign a routing key, establish SCTP associations, and move the M3UA process through its signaling states in the correct order.
This guide presents a vendor-neutral method for building an M3UA ASP. Exact commands vary between products, but the logical objects and operational sequence remain broadly consistent.
Understand The M3UA Roles
An Application Server represents a logical destination for a specific signaling service. For example, an AS may handle ISUP traffic for a destination point code, service indicator, or network appearance. The ASP is the active software process that provides that service over SCTP.
The Signaling Gateway Process receives SS7 traffic from a circuit-switched network and forwards it toward the ASP. A single AS can contain one or several ASPs, allowing active, standby, or load-sharing designs. The relationship should be documented before configuration begins because M3UA state management depends on it.
The routing key connects incoming SS7 traffic to the correct AS. It can include a destination point code, originating point code, service indicator, circuit identification code range, or other supported criteria. The routing key must match the signaling traffic that the ASP is expected to process.
Define The Core Parameters
Begin by collecting the values required by both signaling endpoints. These normally include local and remote IP addresses, SCTP port numbers, local and remote point codes, network appearance, routing context, and the M3UA traffic mode.
The following model separates values that identify the IP transport from values that identify SS7 signaling:
| Configuration Element | Purpose | Typical Example |
|---|---|---|
| Local IP address | Identifies the ASP interface | 192.0.2.20 |
| Remote IP address | Identifies the SG or peer | 192.0.2.30 |
| SCTP port | Carries M3UA messages | 2905 |
| Local point code | Identifies the ASP-side signaling node | 2-10-1 |
| Destination point code | Selects the remote SS7 destination | 3-20-4 |
| Network appearance | Separates signaling domains | 1 |
| Routing context | Maps traffic to an AS | 1001 |
| Traffic mode | Controls ASP distribution | Override or Loadshare |
Point-code format differs by national or carrier standard, so do not copy a point code without confirming its numbering plan. The same applies to network appearance and routing context: both values must be consistent across the relevant SG and ASP configuration.
Establish SCTP Before M3UA
SCTP provides the transport association used by M3UA. Configure the local and peer addresses, association port, heartbeat behavior, retransmission limits, and optional multihoming parameters before attempting to activate the application server.
SCTP multistreaming can reduce head-of-line blocking, while multihoming can preserve an association after an interface or path failure. Administrators should understand how SCTP sequence handling affects ordered signaling delivery before selecting stream and failover settings.
Confirm that firewalls and access-control lists permit SCTP, not only TCP and UDP. A successful IP ping does not prove that SCTP can establish an association. Check association state, verification tags, heartbeat responses, and negotiated addresses in the endpoint logs or packet capture.
Build The Application Server
Create the AS as a logical object and assign its routing key. The routing key should describe the traffic that belongs to the service, such as ISUP messages for one destination point code. If the platform supports routing contexts, assign a unique value and record it in the network design.
Next, create the ASP process and bind it to the SCTP association. Set the local signaling identity, peer identity, protocol version, network appearance, and supported user adaptation layer. The ASP must advertise the same service scope that the AS expects to receive.
Some implementations require an explicit association between the ASP and AS objects. Others infer the relationship from the routing context or routing key. Verify the product behavior rather than assuming that an established SCTP connection automatically activates M3UA traffic.
Activate M3UA Signaling
M3UA activation normally follows a defined state sequence. SCTP reaches an established state first, then the ASP exchanges ASPUP and ASPUP-ACK messages. After that, ASPAC and ASPAC-ACK activate the process for one or more routing contexts.
The SG may send management messages such as DUNA, DAVA, SCON, or DUPU. These messages report destination availability, congestion, or unavailable user parts. The ASP should interpret them according to its role instead of treating every management message as a transport failure.
Traffic mode is important when several ASPs serve one AS. Override usually makes one ASP primary, while loadshare distributes traffic across active processes. Broadcast is appropriate only where the network design explicitly requires copies of the same signaling traffic. Confirm that both sides support the selected mode and apply it to the same routing context.
Verify Routing And Service Behavior
After activation, test signaling in layers. First confirm SCTP association stability, then verify M3UA state, routing-context registration, destination availability, and finally the user-part traffic such as ISUP or SCCP. This sequence prevents an application-layer fault from being mistaken for an IP transport problem.
Use packet captures and protocol traces to inspect message direction and acknowledgment behavior. Useful indicators include repeated ASPUP messages, missing ASPAC acknowledgments, invalid routing contexts, destination-unavailable notifications, and unexpected point-code values.
Check timers and recovery behavior during controlled tests. Stop the primary ASP, observe whether the standby becomes active, and restore the failed process to confirm that traffic returns according to the selected mode. Also test SCTP path failure if multihoming is part of the design.
Operational Checks For Production Readiness
Use the following checks before placing the M3UA ASP into live service:
- Confirm that local and remote point codes use the correct numbering plan.
- Match routing keys, routing contexts, and network appearances at both ends.
- Verify SCTP reachability, firewall rules, heartbeats, and multihoming paths.
- Confirm ASPUP, ASPAC, and acknowledgment exchanges in protocol traces.
- Test failover, destination availability, congestion handling, and service restoration.
Keep a configuration record containing every address, point code, timer, stream setting, and traffic-mode decision. Correlate M3UA logs with SCTP events and SS7 message traces so that transport, adaptation, and user-part faults can be separated quickly.
Apply changes during a controlled maintenance window and preserve the previous working configuration. Once the ASP is active, monitor association state, retransmissions, M3UA management messages, signaling load, and failover events continuously.
Use this workflow to configure the AS and ASP in a lab first, validate each protocol state, and then promote the tested configuration to production with documented rollback steps.
