Description
The T8 Long Term Transaction Reference ID (TLTRI) is a critical identifier defined in 3GPP specifications for the T8 reference point, which connects the Service Capability Exposure Function (SCEF) to external Application Servers (AS) for Cellular Internet of Things (CIoT) services. The T8 interface uses the HTTP/2 protocol, and the TLTRI is employed within these HTTP-based API transactions. Its primary function is to uniquely label and track a 'long term transaction,' which represents an ongoing interaction between the AS and the network for a specific service request concerning a UE or group of UEs.
Architecturally, when an AS requests a network capability—such as setting up a Monitoring Event (e.g., to be notified when a device moves into a specific area), configuring a Device Trigger (a wake-up message for a power-saving device), or establishing a session for Non-IP Data Delivery (NIDD)—the SCEF creates a corresponding resource and assigns it a TLTRI. This ID is then returned to the AS in the HTTP response (e.g., in the `Location` header or response body). The TLTRI acts as a handle or key that the AS must use in all subsequent interactions related to that specific transaction. For example, to update parameters, query the status, or delete the monitoring event, the AS includes the TLTRI in the HTTP request URL or headers, allowing the SCEF to correctly identify and manipulate the correct network resource.
How it works is integral to the RESTful design of the T8 API. The TLTRI is typically embedded in the resource URI, following a structure like `/{{apiRoot}}/{{apiName}}/{{apiVersion}}/{{resourceName}}/{{tltri}}`. This design aligns with REST principles where each managed entity (the long-term transaction) is a uniquely addressable resource. The SCEF is responsible for generating the TLTRI, ensuring its uniqueness within the context of the specific API and the SCEF instance. The ID must persist for the entire lifetime of the transaction, which could be very long (e.g., a monitoring event for a stationary utility meter might last years). This persistence allows the network to maintain state for infrequent IoT communications efficiently.
Its role is to enable reliable, stateful interactions in a largely stateless HTTP protocol environment. For IoT, where sessions are long-lived and events are sparse, maintaining a lightweight reference on the AS side (the TLTRI) is more efficient than the network constantly pushing state to the AS or the AS needing to store complex network internal identifiers. It simplifies the AS logic, provides a clear audit trail, and is essential for the SCEF's resource management, allowing it to correlate incoming API requests with the internal network procedures and UE contexts they affect. The TLTRI, therefore, is a cornerstone for the scalable exposure of network capabilities to IoT verticals.
Purpose & Motivation
The TLTRI was created to address the specific management challenges of long-duration, asynchronous transactions inherent in IoT services exposed via the T8 interface. Traditional mobile network interactions, like voice calls or web browsing sessions, are relatively short-lived. In contrast, IoT applications often require the network to monitor a device for an extended period (e.g., for location changes) or hold a device trigger until the device becomes reachable, which could take hours or days. A simple transaction ID used for short HTTP request/response cycles was insufficient for correlating requests and responses that could be separated by vast stretches of time.
It solves the problem of resource correlation and lifecycle management in a RESTful API designed for machine-to-machine communication. Without a persistent, unique identifier like the TLTRI, the Application Server would have no efficient way to reference a specific monitoring event it had previously created when it later wanted to modify or cancel it. The network (SCEF) would also struggle to map incoming API requests to the correct internal session state. The TLTRI provides this stable anchor point, decoupling the long-term network state from the potentially stateless operation of the AS.
The motivation for its introduction in Release 15 was closely tied to the standardization of the SCEF and the T8 interface as the primary means for exposing CIoT network capabilities (like NIDD, Device Trigger, and Monitoring) to third-party ASs in a scalable, secure, and programmable way. As part of the broader effort to enable massive IoT, the design needed to support millions of such long-term transactions efficiently. The TLTRI, as a simple yet globally unique identifier within the SCEF's context, fulfills this need, enabling the clear, unambiguous, and efficient management of these persistent network-assisted services throughout their potentially multi-year lifespans.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (19 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-15, normative work from Rel-16.
In Release 16, the TLTRI function was enhanced to allow the SCS/AS to delete an individual ChargeableParty transaction using the correct procedure code. Furthermore, updates were made to the SCEF northbound APIs, including corrections to their aggregation behavior and the definition of a failure response structure for these APIs.
- Adding data type for the BDT Reference ID with "nullable: true" property TS 29.122CR0227
- Correction on MacAddr48 data type reference in the OpenAPI file TS 29.122CR0146
- Update reference to TS 24.250 TS 29.122CR0174
- Reference update: RFC 8259 TS 29.122CR0206
- URI of the SCEF northbound APIs TS 29.122CR0249
- Correct SCEF aggregation TS 29.122CR0208
+ 2 more changes
In Release 17, the TLTRI function was enhanced to support the PATCH method for updating both Device Triggering Transaction and PFD Management Transaction resources, providing a more efficient mechanism for partial modifications. Additionally, the release introduced clarifications and corrections for SCEF Northbound APIs, including support for redirection for pure 4G SCEF APIs and resource definition corrections. These updates improved the protocol's functionality and accuracy for the T8 reference point between the SCEF and the SCS/AS.
- Add the support of PATCH for the update of a Device Triggering Transaction resource TS 29.122CR0548
- Support PATCH for the update of a PFD Management Transaction resource TS 29.122CR0571
- Mutual exclusivity of QoS reference and individual QoS parameters TS 29.122CR0575
- Faliure authorization result of BDT reference Id for ChargeableParty API request TS 29.122CR0324
- OpenAPI reference TS 29.122CR0340
- Support redirection for pure 4G SCEF northbound APIs TS 29.122CR0406
+ 2 more changes
In Release 19, the TLTRI function saw the introduction of provisioning for the MPS for Messaging Indication parameter via the SCEF's NBI, based on the SCEF architecture and T8 reference point procedures. This was accompanied by corrections to the feature name and reference for clarity. Furthermore, the specification was refined through the removal of unused references from the NBI TS Skeleton.
Explore further
Broader topics and technologies where TLTRI plays a role.
Defining Specifications
3GPP specifications that define or reference TLTRI, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 29.122 vj40 | T8 Reference Point for Northbound APIs | Rel-19 |
| TS 32.299 vj00 | Diameter Charging Applications for 3GPP | Rel-19 |