4 Transition Planning
The purpose of transitioning from an existing traditional SS7 network to an SS7-over-IP SIGTRAN network is to access valuable IP services at a reasonable cost and within the desired time frame, without losing any current functionality. While the transition can occur in phases and at the desired pace of the customer, the transition must be well planned to minimize impact on existing operations. This chapter provides guidelines on how to approach such a transition and points to the detailed information provided in this document.
Transition guidelines
The following steps should be followed in making the transition to a SS7-over-IP network.
Resolve high-level network design
Determine any issues by looking at the current network design compared to the new network architecture. Consider the protocols to be used, specific implementations, mated-pair redundancy and link engineering, unihoming versus multihoming, and IP redundancy.
General considerations about the overall network include the following topics:
Be aware of Oracle-specific implementations or deviations and how they will impact your new network. Read about these implementations:
- Protocol deviations
- Overview of products
- “Scalability”
- IPGW/M3UA deployment scenarios and IPSG Deployment Scenario
- “IPGWx congestion management options”
- “IPGWx mateset”
- “Signaling Link Selection (SLS) routing”
Redundancy is achieved through linkset engineering, leveraging unihoming or multihoming, and IP network redundancy. Read about redundancy, links, linksets, and associations:
Collect network information
Developing a physical and logical diagram of the network will help organize the information clearly. Detailed documentation should include:
- Hardware data of the infrastructure's physical structure
- Software data including the existence and configuration of protocols used on the network
- Logical organization of the network
- Name and address resolution methods
- The existence and configuration of services used
- Location of the network sites and the available bandwidth
The physical network diagram should present the following information about your existing network:
- Details of physical communication links, such as cable length, grade, and approximation of the physical paths of the wiring, analog, and ISDN lines
- Servers with name, IP address (if static), server role, and domain membership. A server can operate in many roles.
- Location of devices such as hubs, switches and routers that are on the network
- WAN communication links and the available bandwidth between sites (this could be an approximation or the actual measured capacity)
The logical network diagram should show the network architecture, including the following information:
- Domain architecture including the existing domain hierarchy, names, and addressing scheme.
- Server roles including primary and backup
IP addresses, subnet masks, default gateways and LAN parameters (e.g. Full/Half Duplex, 10/100 Speed, MAC Layer) will also be needed for implementation. Refer to Database Administration - IP7 User's Guide manual of the current EAGLE documentation for affected parameters and detailed information.
Before an association is established, the exact RTT is impossible to measure accurately because only the transmitter’s SCTP will be able to measure the exact amount of elapsed time from each transmit until the acknowledgment. A good estimate can be gained using a number of ping requests at different times of the day or from a network analyzer. Remember, however, that ping uses ICMP echo packets that are often given a lower QoS in IP networks.
To gather the information required to determine configuration parameters of the M2PA and M3UA association(s) between an EAGLE node and each Signaling End Point (SEP), a spreadsheet per EAGLE node can be very helpful. Every node connected by a SIGTRAN link should appear as a row in the spreadsheet, with the headings listed in the table along the top row.
Table 4-1 M2PA and M3UA configuration parameter data
| Heading Text | Explanation |
|---|---|
| Node Name | The unique network name for the node |
| Node ID | The unique network ID for the node |
| Site Name | The unique network name for the site in which the node resides |
| Node Type | STP, MSC, HLR, SMSC, IN, MSS, MGC, etc. |
| Connected SGW(s) | The EAGLE node connection to which this data refer |
| Total # SGWs | Total number of STPs to which this node connects |
| SIGTRAN Protocol | M2PA, M3UA or SUA |
| RTT to STP | Measured or estimated RTT between the two nodes |
| Jitter % | The percentage variation in RTT |
| Dim % | The normal designed maximum utilization of a link (20%, 40%, etc.) |
| Avg. MSU Size | The expected average MSU size between this node and the EAGLE |
| % SCCP Class 1 | The percentage of SCCP Class 1 traffic expected to be sent to this node |
| Peak MSU/s | The planned number of MSU/s expected to be sent to this node from all EAGLEs in worst-case conditions |
| Max Assoc | The maximum number of associations that this node supports to this EAGLE |
- Configure the IPGWx Application
- Configure the IPLIMx Application
- Configure the IPSG Application
- Database Administration - IP7 User's Guide of your current EAGLE documentation
Analyze data
Follow the guidelines in Engineering Rules for Determining IP7 Application Throughput (TR005007) to determine expected throughput from IPLIMx and IPGWx applications, and for details on other criteria to achieve these advertised capacities.
Additional information on card throughput (MSU/s) can be found in “Achieving IPLIMx and IPGWx applications’ Advertised Capacity”.
Oracle has guidelines for implementing SS7-over-IP, which can be found at:
Prepare configurations
Once card and association throughput are determined, they can be compared to the traffic dimensioning required for signaling end points (from customers) to determine the number of linksets to use, number of cards in a linkset, and number of associations per card. Consider other factors such as limitations enforced by the connected node (e.g., limits to the number of supported associations).