SIGTRAN Load Latency: Measuring Delay in SCTP over IP Networks
SIGTRAN carries traditional SS7 signalling across IP infrastructure, allowing protocols such as MTP3 and ISUP to operate through adaptation layers including M3UA. In production, however, signalling performance depends on more than whether an SCTP association remains established. Delay, jitter, retransmissions and queueing can all affect call setup and service reliability.
Load latency is the time signalling takes to move through an SCTP path while the network is handling realistic traffic. A quiet test may show excellent results, then fail to reveal congestion between a carrier site in Sydney and a signalling platform in Melbourne. Testing should therefore examine normal, busy and failure conditions rather than relying on a single average round-trip figure.
For Australian operators, geography matters. A link between Brisbane and Perth has a different risk profile from one inside a metropolitan data centre, while NBN access, 4G or 5G backhaul and carrier-grade Ethernet can introduce different queues. Even the “arvo” traffic peak can produce useful evidence if tests are scheduled during genuine busy periods.
What Latency Means In SCTP
SCTP latency is commonly measured as the interval between transmitting an SCTP DATA chunk and receiving the corresponding SACK. This produces a round-trip measurement that includes IP transport, remote processing, acknowledgement behaviour and possible queueing. It is useful for trend analysis, but it is not the same as the time required for an ISUP message to complete its full application path.
A clean test should record the SCTP stream, transmission sequence number, message size, timestamp and acknowledgement status. SCTP supports multiple streams, so a busy stream can suffer application delay without every stream showing the same result. Payload size also matters: small signalling messages may behave differently from bundled chunks or larger diagnostic packets.
One-way delay is harder to establish because clocks at both endpoints must be synchronised. Precision Time Protocol can be appropriate in controlled networks, while Network Time Protocol may be sufficient for broader operational monitoring. If clock accuracy is uncertain, use round-trip time and clearly label it instead of presenting an estimated one-way value as fact.
Why Load Changes The Result
Under load, latency often rises before packet loss becomes obvious. Buffers fill at routers, firewalls or virtual switches, creating queueing delay. CPU contention on a signalling gateway can add another layer of delay, especially when the host is handling M3UA messages, logging, encryption or health checks at the same time.
SCTP retransmissions are a critical separate metric. A delayed SACK may trigger a retransmission timeout, making an individual message appear extremely slow even when the average path remains acceptable. Track the retransmission count, SACK gaps, advertised receiver window, congestion window and association state alongside latency.
Path management can also alter results. SCTP may detect a failing destination address and move traffic to an alternate path, producing a short period of disruption or a sudden latency step. The operational meaning of these events is covered in SCTP path checks, particularly when M3UA application server processes depend on redundant routes.
A Practical Measurement Model
A useful test separates transport delay from application delay. Capture timestamps at the sender, at the receiver where possible, and when the M3UA or ISUP layer accepts the message. This helps identify whether time is being lost in the IP network, the SCTP stack, the adaptation layer or the application process.
Report percentiles rather than only the mean. A mean of 35 milliseconds can hide a p99 of 400 milliseconds, which may matter more to call control than the typical transaction. Include jitter, loss, retransmissions and timeout events, then compare them against the service’s signalling timers and failover design.
| Measure | What it shows | Useful interpretation |
|---|---|---|
| Mean RTT | Typical SCTP acknowledgement delay | Good for trend tracking, weak for outliers |
| p95 and p99 RTT | Busy-period and worst-case behaviour | Reveals queueing and intermittent congestion |
| Jitter | Variation between observations | Highlights unstable paths and scheduling effects |
| Retransmission rate | Chunks requiring another attempt | Indicates loss, severe delay or path problems |
| SACK delay | Time before acknowledgement | Helps identify receiver or host processing pressure |
| Failover interval | Time to use an alternate path | Measures resilience during address or route failure |
Test traffic should resemble the real system. Generate a realistic mixture of signalling messages, use the expected number of SCTP streams and apply the intended M3UA routing context. A lab test that sends uniform packets at a low rate will not represent a national carrier environment with bursty mobile traffic, number portability queries and interconnect signalling.
Designing Tests For Australian Networks
Run baseline tests inside each site first, then test the actual inter-site paths. Compare Sydney–Melbourne, Brisbane–Sydney and longer routes such as Perth–Melbourne where relevant. If the service uses public or managed IP transport, repeat measurements over different access providers and during evening demand, when consumer traffic may compete with operational traffic.
Do not mistake geographic distance for the only source of delay. An efficient fibre path can outperform a congested shorter route, while a poorly configured security appliance can dominate the result. Record VLANs, QoS markings, MTU, firewall inspection, virtual machine placement and whether traffic crosses an NBN, mobile or private carrier segment.
Legacy SS7 knowledge remains valuable because SCTP performance ultimately supports signalling procedures and timers inherited from circuit-switched networks. When validating a gateway or interworking design, review MTP2 proving periods alongside IP measurements so that link behaviour and higher-layer expectations are assessed together.
Operational Checks For Reliable Results
Use these controls before collecting production evidence:
- Synchronise endpoint clocks and document the time source.
- Capture SCTP counters, SACKs, retransmissions and path changes.
- Run tests at idle, normal and engineered peak load.
- Preserve packet captures with test timestamps and message identifiers.
When interpreting the results, separate these categories:
- Transport delay caused by queueing or routing.
- Host delay caused by CPU, memory or virtualisation pressure.
- Protocol delay caused by retransmission or path failover.
- Application delay caused by M3UA, ISUP or service processing.
A practical acceptance report should include percentile latency, jitter, loss, retransmission rate and failover duration for every tested path. It should also state the traffic rate, message mix, packet size, SCTP stream count and test window, allowing engineers to reproduce the result rather than debate an unexplained average.
Begin with a one-hour baseline on each production SCTP route, then repeat it during the busiest measured Australian traffic period and compare the p99 latency with retransmission and failover records.
