1. Database Administration - IP7 User's Guide
  2. IP7 Secure Gateway Overview
  3. Point-to-Multipoint Connectivity (SS7IPGW and IPGWI)

Point-to-Multipoint Connectivity (SS7IPGW and IPGWI)

The following sections describe the types of point-to-multipoint connectivity, how routing is accomplished, and the MTP status functions provided by the ss7ipgw and ipgwi applications:

Connecting to SCPs with SCCP/TCAP Messages Sent Over the IP Network

This functionality allows SS7 nodes to exchange SCCP/TCAP queries and responses with an SCP residing on an IP network. Figure 2-9 shows a diagram of this type of network.

Figure 2-9 IP Network (SCP Connectivity via TCAP-over-IP)

img/c_point_point_connectivity_ss7ipgw_ipgwi_overview_dbadmin_ip7_fig1.jpg

The EAGLE manages the virtual point codes and subsystem numbers for the IP-SCP. From the SS7 network perspective, the TCAP queries are routed using these virtual point codes/SSNs. The EAGLE maps the virtual point code/SSN to one or more TCP sessions (point-to-multipoint connection), converts the SS7MSUs to IP packets by embedding the SCCP/TCAP data inside IP packets, and routes them over an IP network. The EAGLE also manages application subsystem status from an IP network's perspective and an SS7 network's perspective.

The following sequence of events illustrates this functionality:

  1. Traditional SS7 devices route MSUs (such as TCAP Queries) to the EAGLE.
  2. The EAGLE performs a global title translation and forwards the translated MSU to the correct IP device based on Point Code and SCCP Subsystem information in the MSU.
  3. The TCAP query is processed at the IP-SCP, and the IP-SCP sends a TCAP reply back to the EAGLE.
  4. The EAGLE forwards the TCAP reply back to the sender of the original query.

Connecting SEPs Using ISUP, Q.BICC, and TUP Messages Over the IP Network

This point-to-multipoint functionality allows SS7 nodes to exchange ISUP, Q.BICC, and TUP protocol messages with one or more signaling end points (class 4 switches, class 5 switches, VoIP gateways, Media Gateway Controllers, or Remote Access Servers) residing on an IP network. Figure 2-10 shows an example of this type of network.

Figure 2-10 IP Network (SEP connectivity via ISUP, Q.BICC, and TUP-over-IP)

img/c_point_point_connectivity_ss7ipgw_ipgwi_overview_dbadmin_ip7_fig2.jpg

The EAGLE maps the originating point code, destination point code, and circuit identification code to an IP connection. The SEP is provided the originating and destination point codes in the MTP level 3 routing label as part of the passed protocol.

Connecting SCPs and SEPs Using Non-ISUP, Non-SCCP, Non-Q.BICC, and Non-TUP Messages Over the IP Network

This point-to-multipoint functionality allows SS7 nodes to exchange non-ISUP, non-SCCP, non-Q.BICC, and non-TUP protocol messages with one or more IP-based devices residing on an IP network. The network example is similar to the SCP connectivity via SCCP/TCAP-over-IP functionality example shown in Figure 2-9. The EAGLE maps the destination point code, and service indicator (non-ISUP, non-SCCP, non-Q.BICC, non-TUP) to an IP connection.

Understanding Routing for SS7IPGW and IPGWI Applications

The ss7ipgw and ipgwi applications can use a single point code, called a virtual point code. This code is assigned to a set of IP devices that it connects to. The EAGLE distinguishes between the devices within the set by using application routing keys and application servers.

Application routing associates SS7 routing keys with application servers. SS7 routing keys define a filter based on SS7 message data. Application servers define the connection between the IP local host/local transport protocol port and IP remote host/remote transport protocol port.

An application server is a logical entity serving a specific routing key. The application server contains a set of one or more unique application server processes, of which one or more is normally actively processing traffic. An application server process is a process instance of an application server and contains an SCTP association. For more information on application servers, application server processes, and SCTP associations, see the IETF Adapter Layer Support section.

If the routing key filter matches the SS7 message presented for routing to the IP network, the SS7 message is sent to the associated application server.

Only one application server can be associated with each SS7 routing key. One application server can have up to 16 associations. SS7 messages delivered to the IP network using a routing key are distributed over the available application server based on the SLS (signaling link selector) value in the SS7 message.

Routing keys can be fully or partially specified, or specified by default.

Full Routing Keys

For this routing application, all applicable fields in the Message Signaling Unit (MSU) must match the contents of the full routing key. Table 2-3 defines which SS7 message parameters are used to search for a match for full routing keys for each of the functions supported by the ss7ipgw and ipgwi applications (IPGWx functionality).

Table 2-3 SS7 Full Routing Keys per IPGWx Functionality

IPGWx Functionality (ANSI and ITU) SS7 Routing Keys

SCP connectivity via TCAP-over-IP

Destination Point Code

Service Indicator (=3)

Subsystem Number

SEP connectivity via ISUP-over-IP

Destination Point Code

Service Indicator (=5)

Originating Point Code

CIC Range Start

CIC Range End

SEP connectivity via Q.BICC-over-IP

Destination Point Code

Service Indicator (=13)

Originating Point Code

CIC Range Start

CIC Range End

SEP connectivity via TUP-over-IP (ITU only)

Destination Point Code

Service Indicator (=4)

Originating Point Code

CIC Range Start

CIC Range End

SCP/SEP connectivity via non-ISUP, non-SCCP, non-Q.BICC, non-TUP-over-IP

Destination Point Code

Service Indicator (any value other than 3, 4*, 5, and 13)

* The service indicator value of 4 can be used in this instance if the DPC is an ANSI point code.

Partial Routing Keys

Partially specified routing keys are explicitly, but not completely defined. These routing keys ignore some of the contents of the MSU. The parts of the MSU that are ignored are specific. For example, for the ‘ignore cic’ partial-key type, the destination point code (dpc), service indicator (si), and originating point code (opc) must be configured, but the circuit identification code (cic) field does not have to be configured. The other types of SS7 partial routing keys are as follows:

  • dpc, si, and opc specified (ignore cic for CIC-based messages)
  • dpc and si specified (ignore ssn for sccp messages)
  • dpc and si specified (ignore opc and cic for CIC-based messages)
  • dpc specified (ignore all but the dpc field)
  • si specified (ignore all but the si field)

Default Routing Keys

Default routing keys do not need any part of the MSU specified. This routing key can be used to carry any SS7MSU, regardless of the type of MSU or the fields that make up the MSU.

Routing Key Tables

Each IP card has a Routing Key table that maps SS7 routing keys to IP connections, as illustrated by the example in Table 2-4. MSUs that match the parameters in a given row are sent over one of the IP connections shown for that row (up to 16 IP connections can be defined for a single routing key). Multiple IP connections for a given row allow load sharing. In addition, multiple routing keys can be used to send traffic to a single IP connection.

Each IP card’s Routing Key table can contain up to 2500 entries. Entries in the Routing Key table are defined by the ent-appl-rtkey command entered through the OAM, saved on disk, and reloaded to each IP card upon reset. The routing key entries can be full, partial, or default routing keys. The entries in one IP card’s Routing Key table are identical to the entries in the other IP card’s table. The entries can be changed by the chg-appl-rtkey command or removed by the dlt-appl-rtkey command.

Table 2-4 shows a sample Routing Key table that has one entry for an SSCP/TCAP-over-IP connection; one entry each for an ISUP, Q.BICC, and TUP-over-IP connection; and a non-SCCP/non-ISUP/ non-Q.BICC/non-TUP connection.

Table 2-4 Example SS7 Routing Key Table

SS7 DPC Routing Key Parameter SS7 SI Routing Key Parameter SS7 SSN Routing Key Parameter SS7 OPC Routing Key Parameter CIC START Routing Key Parameter CIC END Routing Key Parameter Name of IP Connections that carry traffic for that Routing Key
DPC-SI-SSN routing key for SSCP/TCAP-over-IP connectivity
5-5-5 03 6 - - - kchlr11201 kchlr21201 kchlr11203 kchlr21203
ISUP-CIC routing key for ISUP-over-IP connectivity

5-5-6

05

-

4-4-4

1

100

dnmsc11201

dnmsc21201

dnmsc11203

dnmsc21203

Q.BICC-CIC routing key for Q.BICC-over-IP connectivity

4363

13

-

5834

48486

48486

lpmsg11204

lpmsg21204

lpmsg31204

TUP-CIC routing key for TUP-over-IP connectivity

1-44-2

04

-

2-5-1

3948

3948

lpmsg11205

lpmsg21205

lpmsg31205

DPC-SI routing key for non-SCCP/non-ISUP/non-Q.BICC/non-TUP connectivity

5-5-7

02

        sfhlr11204

Routing Key Lookup Hierarchy

To facilitate the delivery of Message Signaling Units (MSUs) that do not match full routing key entries in the Routing Key table, each MSU is processed and delivered according to a specific routing key lookup hierarchy. The hierarchy guarantees that the MSU is delivered to the best possible location based on the MSU’s closest match in the Routing Key table, and also prevents MSUs without full routing key matches from being discarded. Table 2-5 defines the routing key lookup hierarchy.

Table 2-5 Routing Key Lookup Hierarchy

Type of MSU Lookup Order per MSU Type Segment of MSU that Must Match Routing Key Routing Key Type

CIC

1

dpc + si+ opc+cic

Full

2

dpc + si + opc (ignore cic)

Partial

3

dpc + si (ignore opc & cic)

Partial

4

dpc (ignore si, opc & cic)

Partial

5

si (ignore dpc, opc & cic)

Partial

6

None

Default

SCCP

1

dpc + si + ssn

Full

2

dpc + si (ignore ssn)

Partial

3

dpc (ignore si & ssn)

Partial

4

si (ignore dpc & ssn)

Partial

5

None

Default

OtherSI

1

dpc + si

Full

2

dpc (ignore si)

Partial

2

si (ignore dpc)

Partial

3

None

Default

When an MSU has an si value of 5, 13, or 4 (ITU only), it is a CIC message. Messages with an si value of 3 are SCCP messages. All other MSUs are considered OtherSI messages. The EAGLE first tries to match each MSU with a full routing key and second with one of the partial keys as numbered in ascending order in the table. Third, if no segment of the routing key matches either full or partial routing keys, the EAGLE assigns the MSU a default routing key.

Support for MTP Status Functions

This feature, available only on IP cards that support the ss7ipgw and ipgwi applications, allows the Message Transfer Part (MTP) status of point codes in the SS7 networks to be made available to IP-connected media gateway controllers (MGCs) and IP-SCPs. This feature is similar to the MTP3 network management procedures used in an SS7 network.

This feature enables an IP device to:

  • Divert traffic from a secure gateway that is not able to access a point code that the mated secure gateway can access
  • Audit point code status
  • Build up routing tables before sending traffic
  • Be warned about network congestion
  • Abate congestion (ss7ipgw application only)
  • Obtain SS7 User Part Unavailability status