ISUP CGB/CGU and Interface Management in Trunk Group Maintenance
Operating a national voice network across Australia means juggling thousands of circuits between Tandem switches in Sydney, Melbourne, Brisbane, and Perth. When carriers such as Telstra or Optus need to take a bundle of circuits offline for hardware swaps, ducting works, or regulatory audits, the change is rarely dramatic enough to warrant tearing down the whole bundle. Instead, engineers rely on narrow but precise ISUP maintenance messages to keep traffic flowing.
The Circuit Group Blocking (CGB) and Circuit Group Unblocking (CGU) messages form part of ISUP's maintenance toolkit, working alongside the Group Reset (GRS) and interface-aware state machines. For anyone stepping into carrier-grade voice engineering, getting comfortable with these messages is what separates a reactive operator from one who can plan a controlled maintenance window. The wider protocol stack is documented in detail across the SS7 Training portal, which remains a useful starting reference for newer engineers.
Understanding CGB and CGU in ISUP
CGB is sent by the exchange that owns the circuits in order to prevent a far-end switch from seizing them. The message carries a range and status field, allowing the sending side to block a contiguous block of circuits in a single transaction. CGU is the inverse: a controlled release that returns a previously blocked group back to service, again in one message rather than circuit by circuit.
Both messages sit inside the standard ISUP message envelope and inherit the underlying MTP3 transport. They are formally defined in ITU-T Q.764 and behave consistently across most vendor implementations, although proprietary extensions occasionally add localised range types. From an Australian perspective, this matters because Telstra's Melbourne transit tandems and the Sydney international gateway often interoperate with smaller regional switches from different vendors, so consistency in maintenance signalling is critical.
Local Blocking and Interface State Coordination
The blocking concept has two distinct flavours. Local blocking stops a circuit from being used by the originating switch only; the far-end can still seize the circuit for an incoming call. Remote blocking, by contrast, prevents the far-end from seizing as well. CGB targets remote blocking, so a "blocked" circuit in commercial billing terms might map differently depending on which side initiated the procedure.
Interface management sits at a higher level, tracking trunk group state across all circuits within the bundle. When ACMA-mandated tests are performed, or when a planned outage affects a Point of Interconnect between two network operators, the interface state machine records whether all circuits in a group are available. A loss of all circuits triggers an "all circuits busy" condition, which has implications for alternate routing tables in places like Adelaide or the Gold Coast, where overflow paths are limited.
The Reset Procedure Using GRS
When a group of circuits has been returned to service, the receiving switch may not always know the exact state of each circuit. The Group Reset (GRS) message is used to release every circuit in a group, regardless of whether it was idle, blocked, or in some transient state. After a GRS is acknowledged, all circuits in the group are treated as initially blocked from the far-end's perspective, ready for normal selection again.
In practice this matters when a major modernisation rolls out, such as the migration of legacy PSTN interconnect points onto the NBN's transit infrastructure. A controlled GRS ensures no call is orphaned mid-conversation and that the upgraded switch can sequence its way back into service safely. Operators in regional hubs like Hobart or Darwin typically schedule such resets overnight to avoid the bulk of daytime traffic.
Comparing Common ISUP Maintenance Messages
| Message | Direction | Purpose | Typical Trigger |
|---|---|---|---|
| CGB | Outgoing toward far-end | Block a range of circuits from far-end seizure | Maintenance, hardware fault |
| CGU | Outgoing toward far-end | Release a previously blocked range | End of maintenance window |
| GRS | Outgoing toward far-end | Reset all circuits in a group | Major change, initialisation |
| BLO | Per-circuit | Block one circuit only | Localised fault |
| UBL | Per-circuit | Unblock one circuit only | Recovery from localised fault |
The trade-off between group and circuit-level messages is essentially a balance of bandwidth against granularity. A single CGB covering 24 circuits is far cheaper on the signalling links than 24 individual BLO messages, but it sacrifices the ability to release smaller subsets later. Operators in dense regions around Perth or Sydney frequently use group-level messages for planned maintenance, reserving per-circuit messages for unplanned faults.
Coordinating Multi-Vendor Maintenance Windows
Australia has several active switching vendors deployed across major carriers, including legacy Ericsson AXE alongside newer softswitches. When one operator needs to block circuits that route through another operator's exchange, the CGB and CGU handshake must complete correctly across vendor boundaries. Most outages tied to failed maintenance procedures can be traced back to mismatched interpretation of the range and status indicator.
Establishing shared runbooks, joint test plans, and consistent interpretation of ISUP timers helps avoid this. Engineers can review the SCCP side of inter-operator signalling using this number porting guide to understand how global title translation interacts with ported numbers during the same maintenance window.
Troubleshooting Common Blocking Faults
The most common CGB/CGU faults fall into three groups. First, range mismatches, where the sending switch uses a different circuit range coding than the receiver expects, often due to a missed firmware upgrade. Second, stale blocking, where CGU is sent but never acknowledged because of an MTP3 link outage, leaving the circuits unavailable long after the maintenance has ended. Third, timer interactions, particularly T5 and T7, which can cause calls to be released prematurely during a group reset sequence.
Each of these can be diagnosed using standard SS7 trace tools, but faster resolution comes from a baseline configuration captured during normal operation. Without that baseline, distinguishing a fault from a deliberately applied blocking state is largely guesswork.
Practical recommendations
- Capture a "known good" trace of every critical trunk group during a quiet weekend window, and store it centrally for comparison during incidents.
- Document the CGB range and status indicator expectations for each interconnect partner, ideally embedded in the technical schedule of the interconnection agreement.
- Schedule group resets through a change advisory board, with explicit acknowledgement from the far-end operations team before issuing GRS.
- Run an annual cross-vendor tabletop exercise covering simulated CGB, CGU, and GRS sequences to confirm both sides interpret ranges consistently.
- Verify MTP3 link health using traffic and link-state telemetry in the hours before initiating any group-level maintenance, to avoid stranded CGU messages.
A clean interface state depends less on any single message and more on the discipline surrounding them. Maintainers who treat CGB, CGU, and GRS as part of a coordinated interface contract, rather than ad-hoc commands, find that trunk group availability across their Australian footprint holds steady even during the busiest maintenance cycles.
