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
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (16 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-5, normative work from Rel-15.
In Release 15, the Service Point Trigger (SPT) function saw corrections and clarifications to its operation, specifically for triggering idle mode measurements and for measurement triggering based on the number of cells. Additionally, corrections were made to the field description and a typo within the `aperiodicCSI-Trigger` parameter, refining the precise conditions under which these triggers are activated.
- Triggering UE capability info retrieval using DL NAS TRANSPORT (Stage 2) TS 36.300CR1160
- Corrections to sTTI-SPT band parameters capabilities TS 36.306CR1692
- Correction for sidelink measurement periodical triggering condition TS 36.331CR3544
- Correction on measurement triggering based on number of cells TS 36.331CR3657
- Correction on triggering idle mode measurement TS 36.331CR3658
- Correction to sTTI and sPT capability reporting TS 36.331CR4072
+ 3 more changes
In Release 16, the Service Point Trigger (SPT) function was enhanced to clarify and secure its operation during specific bearer procedures. This included a correction for conditional reconfiguration execution to handle cases where only one cell is triggered and the addition of clarification for RSRP measurement triggering criteria concerning the number of cells, particularly for UAVs. Furthermore, the release addressed a security risk associated with SPTs during a termination point change for RLC AM and RLC UM bearers.
In Release 17, the SPT (Service Point Trigger) function was enhanced by the introduction of an event-based trigger for LTE Minimization of Drive Tests (MDT) logging. This provides a new, specific condition under which logging and reporting can be initiated for network optimization purposes. Additionally, corrections and clarifications were made, including a correction on NR serving frequency results reporting for event-triggered measurement.
- Introduction of event-based trigger for LTE MDT logging [LTE-Event-MDT] TS 36.306CR1830
- Introduction of event-based trigger for LTE MDT logging [LTE-Event-MDT] TS 36.331CR4752
- Clarify the reference point for timing info in SIB16(-NB) and DLInformationTransfer in IoT NTN TS 36.331CR4937
- Correction on NR serving frequency results reporting for event-triggered measurement (R17) TS 36.331CR4850
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.
| Specification | Title | Release |
|---|---|---|
| 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 |