Supplementary Services
This document describes the supplementary services implemented in OmniMSC, covering the SS dispatch mechanism, call forwarding, call barring, call waiting, line identification, call hold, multi-party conferencing, and HLR interaction. For call flow sequences, see Call Flow Diagrams. For configuration parameters, see Configuration Reference. For advanced call features such as ECT and CCBS, see Advanced Call Features. For the MAP operations used to relay SS changes to the HLR (RegisterSS, ActivateSS), see MAP Operations. For MPTY conference bridge details at the media layer, see Media Control.
SS Dispatch Overview
A mobile station interacts with supplementary services by sending DTAP messages from the SS message group: SS REGISTER, SS FACILITY, and SS RELEASE COMPLETE, as defined in 3GPP TS 24.010. Each message carries a facility information element containing ASN.1-encoded component(s) with an operation code and SS code that identify the target service. The provisioned supplementary services for each subscriber, along with their status badges, are visible in the Subscribers page of the control panel — see Control Panel Guide.
When OmniMSC receives one of these messages, the CC/SS dispatcher extracts the SS code from the facility IE and routes the request to the appropriate service handler. The SS code is a single-byte value defined in 3GPP TS 29.002 that uniquely identifies the supplementary service being invoked.
SS Operations
Every supplementary service supports a subset of the five standard operations:
| Operation | Description |
|---|---|
| Register | Provision the service with parameters (e.g., forwarded-to number, no-reply timer) |
| Erase | Remove a previously registered service |
| Activate | Enable a registered service so that it takes effect |
| Deactivate | Disable an active service without removing the registration |
| Interrogate | Query the current status and parameters of a service |
The MS encodes these operations using invoke components within the facility IE. OmniMSC processes the request, determines whether HLR involvement is required, and returns a return result or return error component in the response.
Call Forwarding
OmniMSC implements the four 3GPP call forwarding variants defined in TS 24.082. Each variant can be provisioned per subscriber via MAP INSERT SUBSCRIBER DATA from the HLR, or managed by the subscriber using SS Register, Activate, Deactivate, Erase, and Interrogate operations.
| Variant | SS Code | Trigger | 3GPP Reference |
|---|---|---|---|
| Call Forwarding Unconditional (CFU) | 0x21 | All incoming calls | TS 24.082 Sec 4.1 |
| Call Forwarding on Busy (CFB) | 0x29 | Called subscriber busy | TS 24.082 Sec 4.2 |
| Call Forwarding on No Reply (CFNRy) | 0x2A | No answer within timer | TS 24.082 Sec 4.3 |
| Call Forwarding on Not Reachable (CFNRc) | 0x2B | Subscriber not reachable | TS 24.082 Sec 4.4 |
CFU (Call Forwarding Unconditional)
All calls to the subscriber are unconditionally forwarded to the configured forwarded-to number. When CFU is active, the MSC does not page the subscriber. CFU takes priority over all other forwarding variants.
CFB (Call Forwarding on Busy)
Calls are forwarded when the subscriber is busy (all traffic channels occupied or user-determined user busy). The MSC detects the busy condition from either the radio interface (UDUB) or the CC FSM state.
CFNRy (Call Forwarding on No Reply)
Calls are forwarded when the subscriber does not answer within a configurable timer (default 20 seconds, range 5-30 seconds per 3GPP TS 24.082). The no-reply timer starts when the paging response or alerting indication is received.
CFNRc (Call Forwarding on Not Reachable)
Calls are forwarded when the subscriber cannot be reached: IMSI detached, no paging response, or radio link failure. The MSC determines reachability from the VLR subscriber state and paging outcome.
Call Forwarding Operations
A subscriber manages call forwarding through the standard SS operations:
| Operation | Effect |
|---|---|
| Register | Store forwarded-to number and optional no-reply timer; implicitly activates the service |
| Erase | Remove forwarded-to number and deactivate the service |
| Activate | Enable a previously registered forwarding variant |
| Deactivate | Disable forwarding without removing the registered number |
| Interrogate | Return current status (active/inactive) and forwarded-to number |
Registration and erasure operations are relayed to the HLR via MAP, since the forwarding data is part of the subscriber profile. Activation, deactivation, and interrogation can be handled locally from VLR data when the information is already available, or relayed to the HLR otherwise.
Call Forwarding State Diagram
Call Barring
OmniMSC implements call barring services per 3GPP TS 24.088. Barring categories are provisioned by the HLR via MAP INSERT SUBSCRIBER DATA and are enforced by the MSC during call setup. The subscriber cannot override operator-provisioned barring.
| Category | SS Code (within barring group) | Direction | Effect |
|---|---|---|---|
| Barring of All Outgoing Calls (BAOC) | 0x21 | MO | Block all outgoing calls |
| Barring of Outgoing International Calls (BAOIC) | 0x22 | MO | Block international outgoing calls |
| Barring of Outgoing International Calls except to Home Country (BAOIC-ExC) | 0x23 | MO | Block international outgoing calls except to home PLMN country |
| Barring of All Incoming Calls (BAIC) | 0x24 | MT | Block all incoming calls |
| Barring of Incoming Calls when Roaming (BAIC-Roam) | 0x25 | MT | Block incoming calls when subscriber is roaming outside HPLMN |
Barring Provisioning
Call barring data arrives from the HLR as part of the subscriber profile in the MAP INSERT SUBSCRIBER DATA operation during Location Update. The VLR stores the active barring categories and the MSC evaluates them at call setup time. Since barring is operator-controlled, activation and deactivation by the subscriber require HLR authorization via a barring password.
Barring Evaluation -- Outgoing Calls
Barring Evaluation -- Incoming Calls
Call Waiting
OmniMSC implements Call Waiting (CW) per 3GPP TS 24.083. Call Waiting has SS code 0x41. The subscriber can activate or deactivate Call Waiting using the standard SS Activate and Deactivate operations.
When a subscriber with CW active is engaged in a call and receives a second incoming call, the MSC includes a Signal information element in the SETUP message sent to the mobile station. The Signal IE instructs the MS to play a call-waiting tone, alerting the subscriber to the incoming call. Without CW active, the MSC returns a busy indication to the second calling party, which may trigger CFB if configured.
The subscriber may then accept the waiting call by placing the current call on hold (HOLD message) and answering the new call, or reject the waiting call, which proceeds to normal busy handling.
Line Identification
OmniMSC implements Calling Line Identification Presentation (CLIP) and Calling Line Identification Restriction (CLIR) per 3GPP TS 24.081 and TS 24.083.
CLIP (Calling Line Identification Presentation) -- SS Code 0x11
CLIP provides the called party with the calling party number. The MSC includes the calling number in the SETUP message sent to the mobile station on the MT leg, and in the IAM or SIP INVITE on the outgoing trunk for MO calls. CLIP is a network-provisioned service: when CLIP is provisioned for the called subscriber, the network presents the calling number subject to CLIR restrictions of the calling party.
CLIR (Calling Line Identification Restriction) -- SS Code 0x12
CLIR allows the calling party to restrict presentation of their number to the called party. The HLR provisions the default CLIR mode, and the subscriber can invoke per-call overrides where permitted.
| Mode | Behavior |
|---|---|
| Permanent | Number is always restricted; per-call override not available |
| Temporary (default restricted) | Number restricted unless subscriber invokes per-call presentation |
| Temporary (default allowed) | Number presented unless subscriber invokes per-call restriction |
The MSC evaluates the CLIR setting of the calling subscriber when populating the Calling Party Number in outgoing signaling. A network operator override can force presentation regardless of CLIR setting, for scenarios such as lawful intercept and emergency callback.
Call Hold
OmniMSC handles Call Hold per 3GPP TS 24.083. The mobile station places an active call on hold by sending a HOLD message and retrieves it by sending a RETRIEVE message. Both are CC messages handled directly by the CC FSM within the MSC.
When the MSC receives a HOLD message, the CC FSM transitions the call leg to the held state, instructs the media gateway to set the held leg to receive-only, and sends a HOLD ACKNOWLEDGE back to the MS. On RETRIEVE, the CC FSM reverses the process: the media gateway leg returns to send-receive mode, and the MSC responds with RETRIEVE ACKNOWLEDGE.
Call Hold is a prerequisite for several other supplementary services including Call Waiting (accepting a second call), Multi-Party conference (bridging held and active calls), and Explicit Call Transfer (connecting held and active remote parties).
Multi-Party (MPTY) Conference
OmniMSC implements Multi-Party calling per 3GPP TS 24.084. MPTY allows a subscriber to bridge multiple calls into a conference. The conference bridge is hosted on the media gateway, with the MSC controlling participation through CC FACILITY invoke and return result exchanges.
MPTY Operations
| Operation | SS Code | Description |
|---|---|---|
| BuildMPTY | 0x51 | Create or extend the conference by merging the held and active calls |
| HoldMPTY | 0x52 | Place the entire conference on hold |
| RetrieveMPTY | 0x53 | Retrieve a held conference |
| SplitMPTY | 0x54 | Extract one party from the conference into a private call |
BuildMPTY Flow
The subscriber first establishes two calls (one active, one held) using normal call setup and the HOLD procedure, then sends a BuildMPTY invoke in a CC FACILITY message. OmniMSC creates a conference context on the media gateway, redirects all call legs into the conference bridge, and returns a BuildMPTY return result to the MS. Subsequent calls can be added to the conference by repeating the hold-and-dial pattern followed by another BuildMPTY invoke.
HoldMPTY and RetrieveMPTY
HoldMPTY places all conference legs into receive-only mode on the media gateway, allowing the subscriber to make a private call outside the conference. RetrieveMPTY reverses this, restoring all legs to send-receive mode and reconnecting the subscriber to the conference.
SplitMPTY
SplitMPTY extracts a single party from the conference into a private two-party call with the subscriber. The remaining conference participants are placed on hold. The MS identifies the party to be split by call reference in the SplitMPTY invoke.
Conference Bridge on MGW
The media gateway maintains the conference context with one termination per participant. OmniMSC uses CRCX to create terminations and MDCX to add or remove them from the conference context. The gateway performs audio mixing for all participants in the context.
HLR Relay
Several SS operations require interaction with the HLR, since the subscriber profile is the authoritative source for supplementary service state. When the MSC receives an SS operation that modifies persistent state (Register, Erase, Activate, Deactivate for forwarding, barring password verification), the request is relayed to the HLR via the appropriate MAP operation. The HLR processes the request, updates the subscriber profile, and returns the result, which the MSC forwards to the mobile station.
Operations relayed via MAP include:
- RegisterSS / EraseSS for call forwarding numbers
- ActivateSS / DeactivateSS for service state changes that must persist beyond the current VLR registration
- RegisterPassword for call barring password management
- InterrogateSS when the VLR does not hold the requested data
Local Interrogation
When the VLR already holds current supplementary service data (received during Location Update via INSERT SUBSCRIBER DATA), interrogation requests can be answered locally without contacting the HLR. This reduces signaling load and response time. The MSC queries the VLR subscriber record for the requested SS code and returns the current status directly to the mobile station.
Local interrogation is used for status queries where the VLR data is known to be fresh, such as immediately after a Location Update or after a successful Register/Activate/Deactivate operation that updated the local VLR copy.
3GPP Specification References
| Specification | Title | Relevance |
|---|---|---|
| TS 24.010 | Mobile Radio Interface Layer 3 -- Supplementary Services | SS message structure, facility IE, component types |
| TS 24.080 | Mobile Radio Interface Layer 3 SS Specification -- Formats and Coding | ASN.1 encoding of SS operations and components |
| TS 24.081 | Line Identification Supplementary Services | CLIP, CLIR |
| TS 24.082 | Call Forwarding Supplementary Services | CFU, CFB, CFNRy, CFNRc |
| TS 24.083 | Call Waiting and Call Hold Supplementary Services | CW, HOLD, RETRIEVE |
| TS 24.084 | Multi-Party Supplementary Services | BuildMPTY, HoldMPTY, RetrieveMPTY, SplitMPTY |
| TS 24.088 | Call Barring Supplementary Services | BAOC, BAOIC, BAOIC-ExC, BAIC, BAIC-Roam |
| TS 29.002 | MAP Specification | SS code assignments, MAP operations for SS provisioning |