SPT

Service Point Trigger

Services
Introduced in Rel-5
A logical point within a service logic execution (e.g., in an IMS Application Server or CAMEL service) where a trigger condition is evaluated. It determines whether to invoke specific service logic, enabling dynamic, event-driven service behavior based on subscriber state, session events, or network conditions.

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.

Key Features

  • Defines specific events or conditions (SIP methods, URI, headers) in a session flow that can trigger external service logic.
  • Configured per-subscriber in service profiles (e.g., iFC in IMS) downloaded from HSS.
  • Enables sequential, priority-based evaluation of multiple triggers for service chaining.
  • Decouples service execution (in Application Servers) from basic session control (in CSCF/MSC).
  • Supports both circuit-switched (CAMEL) and packet-switched (IMS) service architectures.
  • Fundamental for enabling personalized value-added services like prepaid, call screening, and multimedia conferencing.

Evolution Across Releases

Rel-5 Initial

Service Point Trigger was formally defined within the IP Multimedia Subsystem (IMS) architecture introduced in Rel-5. The initial architecture established SPTs as part of the Initial Filter Criteria (iFC) in the subscriber's service profile. It defined trigger points based on SIP protocol elements (method, Request-URI, SIP header) to allow the S-CSCF to invoke services on IMS Application Servers via the ISC interface.

Defining Specifications

SpecificationTitle
TS 23.218 3GPP TS 23.218
TS 29.562 3GPP TS 29.562
TS 36.300 3GPP TR 36.300
TS 36.302 3GPP TR 36.302
TS 36.306 3GPP TR 36.306
TS 36.331 3GPP TR 36.331