SSC

Supplementary Service Control string

Services →
Introduced in R99 Also in: Services, User Equipment, Radio Access Network

SSC is a standardized character string, starting with '*' or '#', used by a mobile subscriber to directly activate, deactivate, or interrogate a supplementary service like call forwarding from their handset.

Category
Services
Introduced
R99
Where
Core Network › 5G Core
Also touches
3 segments
Specifications
21 specs
SSC Description Purpose Related Classification Detected Changes Specifications

Description

The Supplementary Service Control string (SSC) is a user-friendly, dialable string format standardized across 3GPP specifications (e.g., TS 24.526, TS 29.508) for the control of supplementary services. It is the human-machine interface that allows a subscriber to issue commands to the network to manage services like Call Forwarding Unconditional (CFU), Call Barring (BAOC), or Call Waiting (CW). A typical SSC has a structured syntax: a prefix (often '*' or '#'), a service code (a two-digit number identifying the service, e.g., 21 for CFU), an operation code (a single digit for activate, deactivate, register, erase, or interrogate), and optionally, supplementary information such as a target phone number or a password. For example, **21*+123456789# might activate CFU to the number +123456789.

When a user dials an SSC and presses the send/call button, the mobile handset does not treat it as a normal phone call. Instead, it packages the string into a signaling message, specifically a FACILITY or REGISTER message within a call control protocol like DTAP (Direct Transfer Application Part). This message is sent over the radio interface to the MSC (Mobile Switching Centre). The MSC's Call Control function receives the message, parses the SSC according to the standardized syntax, and interprets the requested operation. The MSC then interacts with the relevant network databases—primarily the VLR (Visitor Location Register) and the HLR (Home Location Register)—to execute the command. For registration or interrogation, the MSC may communicate with the HLR via MAP (Mobile Application Part) to update or retrieve the subscriber's service profile.

The SSC mechanism works in conjunction with the network's service logic. For basic services, the MSC can process the SSC directly. For more advanced services or those involving CAMEL control, the MSC may involve the gsmSCF. The standardization of the SSC syntax ensures interoperability between handsets from any manufacturer and networks from any operator, providing a consistent user experience globally. It is a key part of the Man-Machine Interface (MMI) for telecommunications services. While modern smartphones often manage these services through graphical menus or apps, those interfaces ultimately generate the standardized SSC strings for transmission to the network, ensuring backward compatibility.

Purpose & Motivation

The Supplementary Service Control string was created to provide a simple, uniform, and subscriber-empowering method for controlling network-based features. Before its standardization, the activation of services like call forwarding might have required a call to customer service or the use of proprietary, operator-specific codes, leading to a poor user experience and hindering subscriber mobility across different networks. The SSC standard solved this by defining a universal, dialable code language that works on any GSM/UMTS/LTE/5G phone on any compliant network.

Its primary purpose is to enable subscriber self-provisioning and management of supplementary services. This reduces operational costs for network operators by minimizing calls to customer support centers for simple service changes. It also empowers users, giving them immediate control over their telephony features. The structured syntax, with distinct fields for service, operation, and parameters, allows for a wide range of services to be controlled through a consistent and memorable pattern (e.g., *21* for forwarding, *33* for barring).

Historically, the SSC concept was introduced in the early GSM standards (R99) and has been maintained through every subsequent release, including 5G. Its longevity is a testament to its effectiveness as a simple yet powerful user interface mechanism. While new provisioning methods like OMA DM (Open Mobile Alliance Device Management) or HTTP-based interfaces (for 5G) have emerged, the SSC remains a fundamental fallback and a widely understood method for service control, ensuring accessibility and interoperability across decades of mobile technology evolution.

Classification

Related approachesMMI

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (15 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 6 changes

In Release 15, the specifications for SSC (Session and Service Continuity) mode selection were clarified and refined. This included defining the relationship between SSC mode 3 and the PDU session type, as well as providing further details on remaining IP address lifetime for SSC mode 3. The release also introduced miscellaneous corrections and clarifications regarding SSC mode handling within session management and URSP rules.

  • Remaining IP address/prefix lifetime with SSC mode 3 TS 23.501CR0018
  • Relation between the SSC mode 3 and the PDU type TS 23.501CR0028
  • SSC Mode Selection TS 23.501CR0173
  • SSC Mode Selection clarification TS 23.501CR0403
  • Miscellaneous Corrections to SM specifications (SSC mode, PCFP reference, etc.) TS 23.501CR0547
  • Clarification on URSP traffic descriptor and SSC mode TS 24.526CR0013
Rel-16 5 changes

In Release 16, the enhancements for the SSC function focused on refining PDU session management and charging. Specifically, the release introduced offline-only charging triggers for SSC modes and defined procedures for handling PDU sessions using SSC modes 2 and 3. It also added rules for matching and allowing SSC modes when associating an application with a PDU session, as well as handling unsupported SSC modes in route selection descriptors.

  • Add offline only charging triggers for SSC modes TS 32.255CR0043
  • PDU Session with SSC mode 2/3 TS 23.501CR1842
  • Handling of unsupported SSC mode in route selection descriptor TS 24.526CR0056
  • Matching of SSC mode for association between an application and a PDU session TS 24.526CR0069
  • Allowed SSC mode for association between an application and a PDU session TS 24.526CR0075
Rel-17 3 changes

In Release 17, the standardization work focused on refining and clarifying the Supplementary Service Control (SSC) function. The corrections and enhancements specifically addressed the definition and behavior of the SSC mode and its associated triggers. Furthermore, the release explicitly defined the requirements for SSC mode support by User Equipment (UEs), ensuring consistent implementation and operation.

Rel-19 1 change

In Release 19, the standardization work for the SSC (Supplementary Service Control string) function focused on correcting an erroneous specification statement. The specific correction addressed inaccuracies related to the behavior of SSC modes 2 and 3 during the procedure for I-SMF (Intermediate Session Management Function) insertion.

  • Correcting wrong statemen w.r.t SSC modes 2/3 for I-SMF insertion TS 23.501CR6379

Explore further

Broader topics and technologies where SSC plays a role.

Defining Specifications

3GPP specifications that define or reference SSC, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TS 23.501 vk00 5G System Architecture Stage 2 Rel-20
TS 24.526 vj30 UE Policies for 5GS; Stage 3 Rel-19
TS 25.211 vj00 UTRA FDD Layer 1: Transport & Physical Channels Rel-19
TS 25.213 vj00 UTRA FDD Spreading and Modulation Rel-19
TR 26.803 vh00 5G Media Streaming Extensions for Edge Processing Rel-17
TS 26.891 vg00 Media Distribution Services in 5G System Rel-16
TR 28.844 vi00 Technical Report on Charging Aspects of Satellite in 5GS Rel-18
TS 29.109 vj00 GAA Bootstrapping Interfaces (Zh, Dz, Zn, Zpn) Rel-19
TS 29.508 vj40 5G Session Management Event Exposure Service Rel-19
TS 29.512 vj40 5G Session Management Policy Control Service Rel-19
TS 29.514 vj40 5G System; Policy Authorization Service; Stage 3 Rel-19
TS 29.520 vj40 5G Network Data Analytics Services Stage 3 Rel-19
TS 29.525 vj40 5G UE Policy Control Service Stage 3 Rel-19
TS 29.561 vj30 5G Interworking with External Data Networks Rel-19
TS 29.890 vg00 CT3 5G System Technical Report Rel-16
TS 31.111 vj30 USIM Application Toolkit (USAT) Specification Rel-19
TS 32.255 vk10 Telecom Management; Charging for 5G Data Connectivity Rel-20
TS 32.291 vj40 Charging Management: Service-Based Interface Protocol Rel-19
TS 32.899 vf10 5G Charging Architecture Study Rel-15
TR 33.919 vj00 GAA Overview TR Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.