In this section:

Overview

When configured as a Signaling Gateway (SG) node, the DSC offers the unparalleled performance and functionality demanded from VoIP, wireline, and mobile networks of today and tomorrow. This powerful SG has all the standard features and functionality expected to support the convergence of legacy SS7 and IP networks.

The DSC may be engineered and configured to serve as a bridge between traditional time division multiplexed (TDM) networks and IP-enabled signaling endpoints. These systems provide complete SG functionality, terminating SS7 Message Transfer Part level 2 (MTP2), MTP3, and Signaling Connection Control Part (SCCP) protocol layers and incorporating the SIGTRAN MTP3 User Adaptation Layer (M3UA), SUA, and Stream Control Transmission Protocol (SCTP) standards to deliver the SS7 payload to the IP-enabled endpoint.

Up to 1,024 individual routing keys or Application Servers (ASs) are available for SS7 message filtering and routing, extending the traditional call control functionality and in-service capabilities to the IP-enabled soft switches and application servers.

The SG supports an N-peer routing architecture for Circuit Identification Code (CIC) UA, M3UA, and SUA protocols. SS7 traffic received on any of the MTP3 or SCCP NAs that are routed for the Destination Point Code (DPC) of an Application Server Process (ASP) which contains routing key information that matches the SG Application Server (AS) routing information, is sent to the Routing CPU (Routing and Management VM or Routing VM) to which the ASP is registered. The SG on the SS7 Routing CPU (Routing and Management VM or Routing VM) converts the SS7 traffic into M3UA, SUA, or CIC UA messages and sends these messages to the M3UA or SUA ASP over the SCTP Association, or to the CIC UA ASP over the TCP connection.

All AS data configured on the SG is fully distributed among all available Routing CPUs (Routing and Management VMs or Routing VMs); therefore, it is the responsibility of the ASP to determine which Routing CPUs (Routing and Management VMs or Routing VMs) the ASP registers with based on the IP address of the TCP or SCTP servers established on each Routing CPU (Routing and Management VMs or Routing VMs).

The Signaling Gateway (SG) allows the provisioning of up to 32 SUA and 32 M3UA SCTP Servers on each Routing CPU (or Routing VM) to accept SCTP Associations initiated by Application Server Processes (ASPs) to route SUA and M3UA messages between the SG and user applications. 

Note

The DSC supports up to 500 SCTP Associations for each Routing CPU (Routing VM). For more information about SCTP Associations, refer to Capacity and Performance.

For more information about SUA and M3UA SCTP Servers, refer to Configuring an SUA SCTP Server and Configuring an M3UA SCTP Server, respectively.

For information about configuring SG, refer to Configuring the Signaling Gateway.

Signaling Gateway Components

This section provides information about the various SG components.

Application Server Process

An ASP is an IP-based network element that convey M3UA or SUA SS7 signaling traffic over SCTP Associations to and from the SG while CIC UA performs this functionality over TCP connections. The SG converts these messages so the messages are 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 CPU (Routing and Management VM or Routing VM) on the DSC based on the IP addresses associated with the SCTP or TCP servers created on each CPU (VM) to support CIC UA, M3UA, or SUA traffic.

Application Server and SS7 Stack Registration

Before communication can occur, an ASP registers with an Application Server (AS) on the SG. An SG AS can be dynamically or manually configured with specific routing data that matches the routing  key contained in the ASP registration request. 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 for IP services.

Signaling Gateway Connections

M3UA

M3UA supports the transport of any SS7 MTP3 user signals [for example, Integrated Service Digital Network (ISDN) User Part (ISUP) and SCCP messages] to an AS. Messages are exchanged over SCTP.

M3UA routes the contents of an incoming SS7 MSU based on a routing key or AS that map to a relevant M3UA ASP. When using M3UA, ASPs may or may not require a point code (PC) depending on the application. If the application uses, for example, Service Control Point (SCP) functionality, the Application ID (AppID) may be used to address the required ASP without a need for PCs. Alternatively, if the application is a Voice over IP (VoIP) gateway [a Service Switching Point (SSP)] whose PC is visible within the SS7 network, a PC is required at the ASP.

The SG can operate simultaneously as an SCTP Server and as an SCTP Client. If the SG is configured as an SCTP Server, the M3UA ASP initiates connection of the SCTP association. If the SG is configured as an SCTP Client, then the SG initiates the connections.

The following figure depicts the graphical representation of M3UA on the DSC. 

M3UA on the DSC

anchorSUA

SUA is a protocol for the transport of any SS7 SCCP user signaling message such as Transaction Capabilities Application Part (TCAP), Radio Access Network Application Part (RANAP), or Mobile Application Part (MAP) over IP using STCP services. The ASP appears as a remote subsystem on the SG and the content of incoming SS7 MSUs is routed based on routing keys or ASs. The DSC takes on the role of a server and expects the ASP to be the client, initiating the connections and registering with an App ID.

The following figure depicts the graphical representation of SUA on the DSC.

SUA on the DSC

CIC UA

The Ribbon Circuit Identification Code (CIC) UA layer is a Ribbon proprietary protocol used to exchange Integrated Services Digital Network User Part (ISUP) messages over TCP/IP using CIC ranges and originator. User Applications or ASPs connect and send registration requests. The SG dynamically creates routing keys or ASs. These routing keys are used to route MTP ISUP messages to registered ASPs.

CIC UA is used for CIC range application registration and can be registered on the SG allowing ASPs with the appropriate CIC ranges and PCs to route traffic to and from the SS7 network and the IP network.

SFG UA

The SS7 Database Application (SDA) Features Gateway (SFG) UA is an internal protocol for SDA services. SFG UA is only available on the Web UI if an SDA service, such as Number Portability, is licensed.

The SFG UA MTP3 ASs are configured to register with MTP3 using either the PC and Service Indicator (SI) combination or the Application ID attributes on a given NA. The key distinction for the SFG UA integration is the Service Handler ID attribute that determines which SDA service receives the associated traffic.

 

  • No labels