In SS7 signaling, a transaction is typically defined as one MSU transmitted and one MSU received, and assumes a worst-case scenario of that many MSUs both transmitted and received simultaneously per second.

IP signaling capacity is not usually constrained by the IP network (bandwidth), but rather by the processing platform (CPU or memory). The cost of a given transaction varies based upon the feature set triggered by the transaction. Not all MSUs are the same, and not all configurations are the same. Rather than to continue to engineer product capacity for the worst case and thereby penalizing customers who are not using worst-case scenarios, Oracle is providing the Transaction Unit (TU) model to allow customers flexibility in how to use application or card capacity.

Under the TU model, a transaction unit indicates the relative cost of an IP signaling transaction; the base transaction unit is 1.0. Some transactions are more expensive than others in terms of IP signaling card capacity. A transaction that is less expensive than the base has a transaction unit less than 1.0, and a transaction that is more expensive is greater than 1.0. The total transaction units consumed by an MSU are the sum of the base transaction unit value and the additional transaction unit value. Transaction Units per Second (TPS) are then calculated with the total transaction unit value and the Advertised Card capacity.

For detailed information on how to calculate IP signaling TPS and the number of cards required to carry MSU traffic, see How to calculate transaction units per second (TPS) and Calculate the Number of Cards Required.

Table 5-1 and Table 5-2 show Link Equivalency for IPSG on E5-ENET-B.

Table 5-3 and Table 5-4 show Link Equivalency for IPSG on SLIC.

For SS7-over-IP networks, Oracle Communications uses E5-ENET-B and SLIC cards to achieve IP connectivity, using the IPSG application.

The IPSG application implements the M2PA and M3UA protocols, which are used for A-links (IPSG-M3UA) and B-, C-, and D-links (IPSG-M2PA) signaling links. Once the card is loaded with the IPSG application, it is referred to as an IPSG card.

The number of MSU/s supported by each card is dependent on various factors including MSU size, percentage of MSUs triggering the SCCP Class 1 sequencing feature, and the Integrated Monitoring feature.

The EAGLE is engineered to support a system total capacity as defined in this section where:

• Each E5-ENET-B card running the IPSG application when the E5-ENET-B IPSG High Throughput feature is OFF has a maximum capacity of 6500 TPS.
• Each E5-ENET-B card running the IPSG application when the E5-ENET-B IPSG High Throughput feature is ON has a maximum capacity of 9500 TPS.
• Each SLIC card running the IPSG application has a maximum capacity of 12000 TPS. This capacity is applicable for both of the following scenarios:
  • When the IPSG High Throughput feature is OFF
  • When the IPSG High Throughput feature is ON

The system total depends on the system TPS. The total maximum allowed system TPS is 10,000,00.

When considering other factors or additional configurations that impact the IMT, contact your Sales Representative for more information.

The following factors affect the IP application’s Advertised Capacity:

• Host card

  Performance Characteristics of the host card can impact the capacity.

• CPU utilization

  Various factors determine the processing resources required by IP applications to manage a given traffic load, and cause the processing of each MSU to be more expensive. For example, the EAGLE provides a feature that enables support of Class-1 Global Title traffic. When the feature is enabled and a triggering message is received by an IP signaling application, the application sends the MSU to an SCCP card for translation, and after translation, the MSU is sent back to the originating IP signaling card for post-translation routing. This extra IMT hop results in significant processing overhead in the receiving IP signaling card.

• Message buffers

  The amount of memory allocated for traffic buffers determines the maximum traffic rate and average message size that can be sustained for a certain network configuration. The buffer size is configurable through associations. For example, within the constraints of memory on the card, each association can have from 8 kb up to 400 kb of send-and-receive buffer space for SCTP.

• Card communication interfaces

  The capacity of the card's external interfaces can become a constraint for certain configurations. For example, the IMT interface capacity is affected by high-utilizing features, or the Ethernet interface configurable capacity is set to half-duplex (not 100Mb/sec full-duplex).

• E5-ENET-B IPSG High Throughput feature

  Turning on the E5-ENET-B IPSG High Throughput feature impacts the baseline configuration for the E5-ENET-B IPSG card as shown in Table 5-5

  Table 5-5 Baseline Configuration Changes for the E5-ENET-B IPSG High Throughput Feature

  E5-ENET-B Card Baseline Configuration	E5-ENET-B when IPSG High Throughput Feature OFF	E5-ENET-B IPSG High Throughput feature ON
  Maximum TPS for the card	6500	9500
  Average MSU size (bytes)	0-272	0-120
  Max RTT (MS)	120	50
  Max number of links/associations	16	4
  Protocol	M2PA and M3UA	M2PA

  Table 5-6 Baseline Configuration Changes for SLIC

  SLIC Card Baseline Configuration	SLIC
  Maximum TPS for the card	10000
  Average MSU size (bytes)	0-272
  Max RTT (MS)	120
  Max number of links/associations	16
  Protocol	M3UA or M2PA

• Card de-rating

  If the E5-ENET-B IPSG High Throughput feature is turned on, the traffic rate is greater than 6500 TPS, and the E5-ENET-B IPSG card exceeds the limits shown in Table 5-5, then the card is de-rated according to the following calculations:

  • SLK TU cost factor = 1+ (RoundDown (((Number of links - 1)/4) * 0.025)
  • MSU size TU cost factor for M2PA links = 1+ (RoundUp(((Average MSU size - 120)/10) * 0.012)
  • MSU size TU cost factor for M3UA links = 1+ (RoundUp(((Average MSU size - 120)/10) * 0.02)
  • Association RTT cost factor (if greater than 50) = 1+ (RoundDown((Association RTT/25) * 0.04)
  • Protocol TU cost factor for M3UA links = 1.05

Given the derating factors, a derived SLK IP TPS for an MSU would be calculated as follows:

Derived SLK IP TPS for an MSU = 1 TU (Actual SLK IP TPS) + 
(RoundDown (((Number of links - 1)/4) * 0.025) (for number of links > 4) + 
(RoundUp(((Average MSU size - 120)/10) * 0.012) (for M2PA) OR 
+ (RoundUp(((Average MSU size - 120)/10) * 0.02) (for M3UA) 
+ (RoundDown((Association RTT/25) * 0.04) (for RTT>50 ms) +
0.05 (for M3UA)

For detailed descriptions of factors that affect advertised card capacity, see Engineering Rules for Determining IP7 Application Throughput.

The base IP signaling transaction unit involves an MSU sent and an MSU received. If using the E5-ENET-B when the IPSG High Throughput Feature is turned OFF, then each MSU has a Service Information Field (SIF) of less than or equal to 160 bytes. If the E5-ENET-B IPSG High Throughput feature is turned on, then each MSU has a SIF of less than or equal to 120 bytes.

The base Advertised Capacity of EAGLE IP signaling cards assumes an average transaction unit cost of 1.0, so a TPS rating of 2,000 = 2,000 Transaction Units per Second (TPS), each having a cost of 1.0. If the average transaction cost increases above 1.0, then the Advertised Capacity (TPS rating) of the IP signaling card decreases proportionally.

Table 5-7 shows the base Advertised Capacity for IPSG application on applicable cards.

^Footnote 1 12K TPS requires EAGLE SW Release 46.6 or greater. Release 46.5 provides 10K TPS.

Exceeding the Advertised Capacity may result in signaling congestion, and in combination with the E5IS Data Feed feature, may result in the application discarding E5IS Data Feed messages.

The adjusted transaction unit is the value calculated and tested by Oracle that represents additional cost per base transaction unit when the configuration deviates from the base configuration.

Additional Transaction Units cost enforced by the IPSG application per Transaction for an E5-ENET-B card when the E5-ENET-B IPSG High Throughput feature is turned off is shown in Table 5-10.

Additional Transaction Units cost enforced by IPSG application per Transaction when the E5-ENET-B IPSG configuration deviates from the configuration described in Table 5-5 and the E5-ENET-B IPSG High Throughput feature is turned on are shown in Table 5-11.

^Footnote 2 Rounded to the next ten if the delta is not multiple of ten.

^Footnote 3 Quotient from the division is used in formula Derating formula applied only for RTT above 50 ms. Dearting factor for RTT <= 50 ms is 0.

^Footnote 4 If card TPS rate is > 6500 and copied by Fast Copy, De-rating factor is 0.1.

The amount of memory allocated for traffic buffers determines the maximum traffic rate and average message size that can be sustained for a specific network configuration. Memory is a constraint in achieving advertised capacity due to queuing, message storing and packet retention for retransmission over the Ethernet physical transport. As a general rule, the greater the Round Trip Time (RTT) for a packet, the greater the need for memory to store the unacknowledged packets being sent to the peer. Since each card has a finite amount of memory, the allocation is spread across all the links or connections on the card. This means that as a card’s hosted-association(s) buffer sizes increase, the maximum number of associations that can be hosted by the card decrease.

The SCTP buffer size is configurable per association. Within the constraints of memory on the card, each association can have 8 kb to 400 kb of send-and-receive buffer space for SCTP.

Table 5-14 lists the maximum memory available for SCTP buffers on each card type.

For any given combination of Window Size and RTT between 2 devices, there exists an inherent limitation on the maximum throughput that can be achieved. Devices with larger buffer sizes supports a higher TPS rate and RTT combination. The equation to calculate the minimum required receive buffer size under ideal network conditions for the remote SCTP peer is:

Minimum SCTP receive buffer size (in bytes) required for an 
association on remote SCTP node = ((Number of messages per 
second/1000) * Network RTT in ms) * average SCTP payload size in bytes

Depending on specific network characteristics including packet loss, RTT, or level of jitter, doubling or quadrupling the calculated remote receive window value may be required to avoid buffer exhaustion and sustain the association.

The BUFSIZE parameter for the association will allocate memory for both transmit and receive buffers. If the advertised receive window from the remote peer is greater than the configured value for the association BUFSIZE parameter, the transmit buffer size on the Eagle will be limited to the provisioned value for BUFSIZE. Likewise, this will be the largest value that the congestion window minimum (CWMIN) variable will be allowed to take on while the association is established.

The BUFSIZE parameter will also set the maximum value for the advertised receive window (a_rwnd) that Eagle will send to the remote peer.

If value of the configured SCTP receive buffer size for an association on remote node is smaller than the SCTP transit buffer on EAGLE, then the maximum possible value of the receive window (rwnd) get reduced to the configured receive buffer size on the remote side. This effectively reduces the amount of data that can be transmitted on the association and causes high Tx buffer occupancy on EAGLE side during high traffic events. The data held in buffers can cause data transition delays between the nodes and may result in M2PA link failures reporting T7/T6 timeouts.

The following table shows an example of the required SCTP buffer size for a 140-byte MSU based on traffic rate and the round trip time calculated at the SCTP layer:

The following table shows an example of the required SCTP buffer size for a 272-byte MSU based on traffic rate and the round trip time calculated at the SCTP layer:

The allocation of SCTP message buffer memory must be of sufficient size on the Eagle card, as well as the peer network element(s), to sustain the traffic for the network's round-trip time and worst-case packet loss.

Previous sections focused on the Maximum and Advertised Capacity of particular applications on particular cards for various configurations. This section focuses on constraints involved in using multiple IP signaling cards and applications.

Below are examples of calculations to determine how many cards are needed. These are somewhat simplified; precise calculations require data about the specific network and the traffic running over it.

EAGLE can be deployed with completely redundant IP network paths, each of which must be capable of sustaining the worst-case traffic load. Either of these two methods can be applied, depending on the application used:

• Unihomed links (for M2PA links)
• Multihomed links (for M2PA, M3UA links)

Multihoming

For multihoming, a set of IPSG cards, which are configured for worst-case traffic load, is hosting one signaling link per linkset. Each signaling link is assigned to a multihomed SCTP association, which is mapped to an IP network having at least two completely redundant paths. Each network path must have dedicated bandwidth sufficient to sustain the worst-case traffic load.

Multihoming is very important for M3UA connections because it is the only means of lossless handover in the event of a path failure.

Multihoming provides network-level resilience for SCTP associations by providing information on alternate paths to a signaling end point for a single association.

SCTP multihoming supports only communication between two end points, of which one or both are assigned with multiple IP addresses on possibly multiple network interfaces. Each IPx card maintains a single static IP route table, utilized by both Ethernet interfaces or ports. By checking the destination address in this IP route table, the router determines the port from which the message is transmitted by the IPx card.

This means that it is not possible to have a route to a single destination from both ports of an IP card – it must be one port or the other. SCTP multihoming does not support communication ends that contain multiple end points (i.e., clustered end points) that can switch over to an alternate end point in case of failure of the original end point.

Figure 5-3 Unihoming versus multihoming

Multi-homing can be used for M2PA links if the M2PA linkset has only one link.

If the M2PA linkset has more than one link, then the value of the M2PA Timer T7 should be lower than RMIN * RTIMES in order for the MTP3 level to trigger a Change Over procedure for MTP3 links.

Note:

RMIN*RTIMES is the minimum time required for an association to restart due to the RTIMES retransmission (via the primary and alternate path in round robin fashion) for an association without receiving any SACK. If the association is closed before the T7 expiration, then the buffer is cleared before the Change Over procedure is triggered by the MTP3 level.

Unihoming is simpler to configure but more expensive than multihoming, in terms of computational power and network bandwidth to handle worst-case failure. Unihoming requires change-over procedures and rerouting if a network path is interrupted, whereas a multihomed SCTP association will simply switch to the alternate network path.

SCTP multihoming, in general, is less mature than MTP3 change-over procedures. In addition, the lack of ARHOST configurability in the EAGLE can result in asymmetrical traffic on a multihomed connection when both paths are available, which may be undesirable.

The EAGLE fully supports both options for M2PA, but Oracle recommends unihoming.

If a completely redundant IP network path is not available, then a redundancy model that relies on a mate Signal Transfer Point for IP path redundancy is supported by Oracle. This model is less robust but also less expensive.

Figure 5-4 Mated Signaling Transfer Point Redundancy With 4-Port SLIC Cards

An IPSG mateset is an IPSG card linkset configuration with a setting of mated, meaning two IPSG linksets are allowed in a mateset by using the matelsn linkset parameter. The limitation of this approach is that each linkset can have only one card. This configuration for IPSG is supported to be backward compatible with previous EAGLE software versions.

A Signaling Link Selection (SLS) value is a 5- or 8-bit integer (ANSI) or 4-bit integer (ITU) that is used to identify the linkset and link to which a message is to be transported.

The SLS value is included in the SLS field, which is part of the MSU’s MTP routing label. The SLS is used to evenly distribute traffic across routes and links, assuming that the SLS values are randomly distributed by the originating node.

The Oracle Communications SS7-over-IP solution follows standard SLS load sharing with IPSG. With IPSG, SLS values are distributed over the associations in the Application Servers.

When transmitting data on a multihomed association, the initial transmission is made to the primary address on the primary path. If the initial transmission times out, then the first retransmission is made to an alternate destination in a round-robin, consecutive fashion. The SCTP layer continues to send the initial transmission of new data arriving for transmission from upper layers on the primary path.

If a unihomed SCTP endpoint is not in contact after the RTIMES errors, the end point address is marked as unreachable. For multihomed associations, if an endpoint’s address is not in contact after the RTIMES/2 errors, the address is marked as unreachable.

An error is a failure to Selectively Acknowledge (SACK) a transmitted packet or acknowledge a heartbeat within a Retransmission Time Out (RTO). Alternate paths exchange heartbeats as a means of confirming connectivity, and failure to acknowledge heartbeats would cause an alternate destination to be marked as unreachable.

Oracle provides two retransmission modes: RFC and Linear. The SCTP retransmission control feature allows the tailoring of retransmissions to detect a network fault in a timely fashion through these configuration parameters:

• RMODE: Desired retransmission mode (RFC or LIN) selected.
• RTIMES: Maximum number of retransmits attempted before the connection is declared lost (3 to 12). The default is 10.
• RTO: Time to wait before the current retransmit attempt is declared a failure. This time is dynamic because it is a moving average of the network.
• RMAX: Upper bound of calculated RTO (10 ms to 1,000 ms); the default is 800. Oracle suggests 3 * RMIN.
• RMIN: Lower bound of calculated RTO (10 ms to 1,000 ms). The default is 120. Oracle suggests the greater of (1.2 * average RTT) or (10 ms + average RTT).
• CWMIN: Minimum Congestion Window Size (1,500 to 192K). The default is 3K.

The CWMIN parameter is important in managing the traffic flow and retransmissions under varying network conditions. Changing the congestion window by setting CWMIN to a higher value affects how long it takes to recover from the retransmit event. This limits how far the window gets closed in a retransmit-event condition. In the extreme case, one could set CWMIN to the configured buffer size, which allows the entire buffer bandwidth to be used. As a general rule, setting CWMIN to a value equal to half of the traffic rate in an RTT interval should allow adequate retransmit-recovery time while preventing excessive load to the peer.

CWMIN = (Bytes/Sec * RTT) / 2 bytes