SPT

Service Point Trigger

Services →
Introduced in Rel-5

SPT is a logical point within service logic execution where a trigger condition is evaluated to determine whether to invoke specific, dynamic service behavior based on subscriber state or network events.

Category
Services
Introduced
Rel-5
Where
Radio Access Network › E-UTRAN (LTE)
Specifications
6 specs
SPT Description Purpose Related Classification Detected Changes Specifications

Description

A Service Point Trigger (SPT) is a fundamental concept in intelligent network (IN) and IP Multimedia Subsystem (IMS) service architecture, defined within 3GPP specifications for Customised Applications for Mobile network Enhanced Logic (CAMEL) and IMS Service Control (ISC). It represents a specific, well-defined event or condition during the processing of a call, session, or subscriber interaction that can be used to 'trigger' the invocation of external service logic. Think of it as a hook or a decision point embedded within the basic call/session state model. When the network element (like a Mobile Switching Centre (MSC) or a Serving-Call Session Control Function (S-CSCF)) reaches an SPT, it evaluates whether the configured trigger conditions are met for a particular subscriber. If they are, it suspends normal processing and forwards the session control to an external application server (AS), such as a CAMEL Service Environment (CSE) or an IMS AS, which executes the customized service logic.

SPTs are defined in a subscriber's service profile, which is downloaded to the network element (e.g., from the HSS/HLR). This profile contains a set of Initial Filter Criteria (iFC) in IMS or CAMEL Subscription Information (CSI) in circuit-switched domains. Each criterion includes one or more SPTs and the address of the AS to contact if the condition is satisfied. An SPT can be based on various aspects: the Request-URI of a SIP message, the SIP method (INVITE, MESSAGE, SUBSCRIBE), the presence or value of specific SIP headers, the session case (originating/terminating), the subscriber's registration state, or the media type involved. For example, an SPT could be defined for the event 'SIP Method is MESSAGE' and 'Request-URI contains 'conference''. When a user sends a message to a conference URI, the S-CSCF hits this SPT, evaluates it as true, and routes the MESSAGE to a messaging application server.

The operation is sequential and priority-based. The network element evaluates the list of triggers (iFCs) in a defined order of priority. When it finds the first SPT condition that matches, it forwards the session to the corresponding AS. The AS then executes its service logic, which may modify the session (e.g., redirecting the call, playing an announcement, modifying headers) and then return control to the S-CSCF. The S-CSCF may then continue evaluating subsequent triggers. This mechanism allows for the composition of complex services from simpler building blocks hosted on different ASs. Key components are the trigger detection point in the network element, the subscriber's filter criteria profile, and the standardized interface (e.g., CAP, IMS ISC) to the AS.

SPTs are the core enablers of service personalization and third-party service provision. They decouple service logic from core network switching/routing functions, allowing services to be developed and deployed independently. This architecture is central to the value-added service ecosystem in both legacy circuit-switched networks and modern IMS-based networks for services like prepaid billing, call screening, number translation, multimedia conferencing, and instant messaging.

Purpose & Motivation

The Service Point Trigger concept originated from the Intelligent Network (IN) principles adopted by 3GPP, primarily to solve the problem of monolithic, inflexible network switches. In traditional telephony, new services (like call forwarding or prepaid) required expensive and time-consuming software upgrades to the switch from a single vendor. This stifled innovation and led to long service deployment cycles. The IN architecture, and by extension SPTs in CAMEL and IMS, introduced a standardized way to externalize service logic, allowing it to reside on separate, more easily updatable application servers.

The primary problem SPTs solve is enabling dynamic, subscriber-specific service invocation without hard-coding logic into every network node. They provide the mechanism for 'service awareness' in the core network. Without SPTs, a switch or S-CSCF would have no standardized way to know when to interrupt its basic call/session processing to involve a specialized service. SPTs define the 'when' and 'why' based on a combination of the session signaling and the subscriber's profile. This allows for mass customization—where each subscriber can have a unique set of active services—which is fundamental to modern telecommunications.

Historically, SPTs were formalized in 3GPP with CAMEL for GSM circuit-switched services (starting in Rel-4/5) to enable operator-specific services like prepaid roaming. Their role became even more critical with the introduction of IMS in Rel-5, which used SIP as the session control protocol. IMS needed a flexible, SIP-aware triggering mechanism to build a multimedia service layer. SPTs, as part of the Initial Filter Criteria, became the cornerstone of the IMS service delivery platform, enabling the convergence of voice, video, and messaging services over IP. They continue to be essential for enabling network APIs (like CAPIF) and service exposure, bridging the core network with the over-the-top application layer in a controlled manner.

Classification

Part ofCAMEL

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-15 2 changes

In Release 15, the primary changes to the Service Point Trigger (SPT) function involved corrections and clarifications to capability reporting for short Transmission Time Interval (sTTI) and sPT band parameters. These corrections ensured accurate signaling of UE capabilities related to sTTI and the associated Service Point Trigger parameters. The updates focused on refining the technical specifications for these capability reporting mechanisms.

  • Corrections to sTTI-SPT band parameters capabilities TS 36.306CR1692
  • Correction to sTTI and sPT capability reporting TS 36.331CR4072

Explore further

Broader topics and technologies where SPT plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 23.218 vj00 IMS Call Model Specification Rel-19
TS 29.562 vj40 HSS Services for IMS & GBA Interworking Rel-19
TS 36.300 vj00 E-UTRAN Radio Interface Protocol Architecture Overview Rel-19
TS 36.302 vj00 E-UTRA Physical Layer Services Rel-19
TS 36.306 vj00 E-UTRA UE Radio Access Capability Parameters Rel-19
TS 36.331 vj00 LTE RRC Protocol Specification 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.