M2PA is used primarily to replace B-, C-, and D-links. When used with A-links, M2PA connects to Service Switching Points, Signaling Control Points, Home Location Registers and other endpoints. M2PA is a direct replacement for channelized TDM circuits because it provides specific controls for assurance of in-sequence delivery of messages. As such, M2PA is used to connect points that pass call-related data that is time-sensitive, such as ISUP calling data.

Congestion procedures conform to those specified by the ANSI/ITU standards. The M2PA protocol can coexist in a linkset with other link types such as low-speed links and ATM high speed links. When using other link types, the throughput will always match the lowest-speed link in the linkset.

Oracle implemented the M2PA protocol through its IPSG application. For more information on the IPSG application, see IPSG application.

Figure 2-2 M2PA Network

M3UA seamlessly transports SS7 MTP3 user part signaling messages over IP using SCTP. M3UA-connected IP endpoints do not have to conform to standard SS7 topology, because each M3UA association does not require an SS7 link; there are no 16-link-per-linkset restrictions. Each M3UA-connected IP endpoint can be addressed by an SS7 point code unique from the signaling gateway’s point code. Oracle offers one type topology for M3UA: IPSG using IPSG-M3UA links.

M3UA is implemented using IPSG, supporting routing keys in the form of SS7 Routes referencing IPSG M3UA linksets rather than as distinct ‘routing key’ managed elements. Instead, it performs similarly to the M2PA protocol. Each M3UA association is viewed as a link by the core EAGLE, and each IPSG card can have up to 128 associations/links per card. MTP Origin-Based Routing cannot be used with adjacent point codes.

M3UA does not have a 272-octet Signaling Information Field (SIF) length limit as specified by some SS7 MTP3 variants. Larger information blocks can be accommodated directly by M3UA/SCTP without the need for an upper layer segmentation or re-assembly procedure, as specified by the SCCP and ISUP standards. However, a Signaling Gateway will enforce the maximum 272-octet limit when connected to a SS7 network that does not support the transfer of larger information blocks to the destination.

At the Signaling Gateway, M3UA indicates to remote MTP3 users at IP end points when an SS7 signaling point is reachable or unreachable, or when SS7 network congestion or restrictions occur.

The following figure and description show how SS7 messages are encapsulated and sent over an IP network to a host in another network.

Figure 2-3 Transmitting an SS7 Message using IP

1. A signaling point issues an SS7 message, unaware that there is IP signaling in the network. The message contains Link Status Signaling Units (LSSU), Fill In Signal Units (FISU), Final Signal Units (FSU), and Message Signal Units (MSUs).
2. The Signaling Gateway receives the SS7 packet and encapsulates all necessary SS7 information into the data section of the IP packet. The packet includes the data, source and destination IP addresses.
3. The packet travels across the IP network. The network is unaware that it is delivering SS7 data. There is no need to modify the routers or gateways along the way.
4. The packet is delivered to the Signaling Gateway on the receiving network. The SS7 information is recovered from the IP packet.
5. A well-formed SS7 packet is sent to the destination Signaling Point.

The following figure and description show the routing inside the Wide Area Network (WAN).

Figure 2-4 Communication inside the WAN

1. The Source Host (Signaling Gateway) builds a packet with a destination IP address.
2. A router on the LAN converts the packet to the WAN protocol and places it on the WAN.
3. Each router on the WAN looks at the destination IP address and determines the port to which it forwards the packet. Each router needs to know only how to get the packet closer to the destination.
4. The final router converts the packet to the local LAN format and delivers it to the Destination Host.

SS7-over-IP networks lower network capital and operational expenditures. SIGTRAN is based on the IP protocol; these networks use industry standard, off-the-shelf network interfaces, cables, switches, and software. Improvements in technology and reductions in cost found in the general computer industry can be applied readily in signaling applications. As an industry standard, SIGTRAN allows customers to interoperate in a multi-vendor environment.

Replacing long-haul point-to-point SS7 links between network elements with IP connectivity can reduce recurring signaling transport costs and the need for dedicated TDM lines. IP-based network monitoring and provisioning improve operation efficiencies.

SS7-over-IP networks offer increased capacity. The bandwidth overall is greater, both due to inherent capacity and to dynamic bandwidth sharing. Data traffic, including Short Message Service (SMS), can run more efficiently over SIGTRAN. For example, SMS data is saturating some SS7 networks. Using devices such as the EAGLE with its gateway functions, operators can have a Short Message Service Center communicate directly to Home Location Registers (HLR) and Mobile Switching Centers (MSCs) using SIGTRAN.

Enabling a network with IP does not require expensive investments or costly upgrades for existing end nodes; it enables migration to packet-based architecture without adding new point codes or reconfiguring the network.

For M2PA, there are no architectural changes. When using SIGTRAN, SS7 routing translations are the same for TDM or IP linksets.

An SS7-over-IP network is the first step to an all-IP network. Figure 2-5 shows the diversity of solutions that are possible using SIGTRAN protocols. For example, M3UA support an IP-enabled Short Message Service Center (SMSC) or Home Location Register (HLR). SS7-over-IP solves the throughput limitations that were inherited from the SS7 standards, thus allowing Short Message Service Center, Home Location Register, and other equipment to support heavy SS7 traffic needs.

Figure 2-5 Typical EAGLE SS7-over-IP Deployment

While a dedicated IP network offers inherent security and minimal routing, a converged network carrying both voice and data also will satisfy these needs at a lower cost, provided that the QoS attributes such as Round Trip Time (RTT), Packet Loss, and Jitter are satisfied. These attributes should always be given the highest priority on the IP network.

Implementing SS7-over-IP on an SS7 system creates a converged IP network that allows quick, cost-effective implementation of IP-based services using existing network elements. The EAGLE, with its Signaling Transfer Point and Signaling Gateway functions, offers a reliable solution for this transition.

Decisions regarding the customization of the IP network are left up to the customer, but Oracle Professional Services can provide recommendations based on their experiences with previous SIGTRAN deployments.

When transitioning to an SS7-over-IP network, consider these strategies:

• Replacement of out-phased (end of life) TDM equipment
• Gradual replacement, which means coexistence of the two technologies: there is no need to retire an existing switch if you are deploying purely for additional capacity
• Full accelerated replacement with a short transition period based on cost, efficiency, and fault management. Even if complete transition is desired, it is unrealistic to expect to instantaneously cut over, unless the subscriber base is very small.

  There is enormous leverage when one platform provides both TDM and SS7-over-IP. The issue is more than cost savings. A combined platform can support new multimodal voice, data and video services that utilize a combination of IP data with diverse messaging capabilities, location and presence information, voice connections, speech recognition and Intelligent Network control. Of course, not every application requires every capability, so flexibility is key.

• Maintaining the existing PSTN network, and use Next Generation Network (NGN) equipment to satisfy growing demands: legacy switches have many features and services.
• Operators may have to wait until new switches support all required features and services
• Out-of-region or in-region expansion of traditional services or new features

Supporting businesses with critical operations, such as banking, requires strategies for predictable recovery, not only from regular network faults, but also from attacks on signaling networks. When planning to move to an SS7-over-IP network, the operator should consider equipment and connection diversity to assist in recovery.

The range of diversity will differ from customer to customer and it may include a multitude of factors:

• Entry diversity offers more than one cable entrance into a building
• Pair and cable diversity provides a local loop connection through multiple, nonadjacent pairs in more than one cable
• Path or route diversity provides end-to-end, physically or logically separate routes for a circuit
• Central office diversity provides local loops that terminate in more than one central office
• Site diversity provides alternative or backup locations