Signaling Gateway Components

The SG interacts with the following elements.

Application Server Processes

An Application Server Process (ASP) is an IP-based network element that conveys CIC UA, M3UA, or SUA SS7 signaling traffic over a STCP Association or a TCP connection to and from the SG. The SG converts these messages so they can be sent from the IP network to the SS7 network, or from the SS7 network to the IP network. An ASP can connect to any Routing VM on the DSC - SP2000 Platform based on the IP addresses associated with the TCP or SCTP servers created on each card to support CIC UA, M3UA, and SUA traffic.

For information about the Routing VMs, refer to the appropriate sections in the Installation Guides.

Application Servers and SS7 Stack Registrations

Before communication can occur between the SG and an ASP, the ASP must register with an Application Server (AS) on the SG.

An SG AS can be dynamically or manually configured with specific routing data that must match the routing data contained in the ASP registration request before the ASP can register.

When the ASP to AS registration has occurred, the SG then uses a subset of the AS routing data attributes to register to the associated MTP3 or SCCP NA. CIC UA, M3UA, and SFG UA Application Servers use a Destination Point Code (DPC) and Service Indicator (SI) combination or an Application ID (App ID) to register with an MTP3 NA. SUA Application Servers use a DPC and subsystem number (SSN) combination or an App ID to register with an SCCP NA.

When an ASP is registered with both the SG and the SS7 stack, SS7 traffic can be routed to and from the IP network.

The following figure shows the main components of the DSC - SP2000 Platform for IP services.

IP Services

The SS7 stack uses Network Appearances (NAs) to define multiple (up to 32) distinct SS7 networks. An SG Application Server is associated with an NA specifically configured to receive SG traffic.

All SS7 signaling messages from the IP network that are destined for the SS7 network must pass through MTP3 or SCCP. Using the SG UI, you must configure the connection between the SG and the SCCP for SUA or between the SG and the MTP3, for CIC UA, M3UA, and SFG UA. For information about configuring the MTP3 NA connections, refer to Configuring MTP3 NAs. For information about configuring the SCCP NA connections, refer to Configuring SCCP NAs.

The following table lists the default IP ports for the individual protocol servers. It is recommended that you do not change these ports.

CIC UA enables a TCP/IP Server on each Routing VM for the provided port on the CIC UA TCP/IP Server activation. M3UA and SUA require the creation of an SCTP/IP Server on each VM. SCTP/IP Servers are enabled on M3UA/SUA SCTP Server activation.

Distributed Routing Architecture

The SG supports an N-Peer routing architecture for the CIC UA, M3UA, SUA, and SFG UA protocols. SS7 traffic received on any of the MTP3 or SCCP NAs that is destined for the Destination Point Code (DPC) or App ID of an ASP and contains routing data that matches the SG AS routing information, is sent to the Routing VM to which the ASP is registered. The SG on the Routing VM converts the SS7 traffic into CIC UA, M3UA, SUA, or SFG UA messages and sends these messages to the associated ASP.

All Application Server data configured on the SG is fully distributed among all available SG VMs; therefore, it is the responsibility of the ASP to determine which Routing VM(s) the ASP registers with based on the IP address of the TCP or SCTP servers that are established on each of these VMs.

Incoming App ID

The Incoming Application ID feature enables incoming user traffic to trigger the Gateway Screening (GWS) and Redirection feature (refer to GWST Tables) when the MSU is received at MTP3. This feature is available for M3UA (refer to Configuring M3UA), SUA ( refer to Configuring SUA), and SFG UA (refer to Configuring SFG UA).

The Incoming AppID uses the standard Application ID format as defined in the M3UA, SUA, and SFG UA Application Servers. The Incoming AppID is defined by a 16 character string which includes the null character. Case insensitive alphanumeric characters, dashes, and underscores are supported. An empty string is used to disable the feature.

The Incoming AppID is integrated in the Configured ASP object for both M3UA (refer to Configuring an M3UA Configured ASP) and SUA (refer to Configuring an SUA Configured ASP) and in the generic SFG UA object (refer to Configuring SFG UA). The configured ASPs are correlated to the concept of a linkset at MTP3. This matches the concept in GWS of an incoming linkset for an entry point to screening and redirection. The SFG UA has no ASP concept, therefore, the incoming AppID is applied to all the traffic received from the SDA.

Default values are assigned on creation; M3UA_DEFAULT, SUA_DEFAULT, and SFGUA_DEFAULT for M3UA, SUA, and SFG UA, respectively. These values can be modified as required.