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.
Key Features
- Uniquely identifies a long-term transaction resource on the T8 interface
- Generated and assigned by the SCEF upon creation of a network resource (e.g., monitoring event)
- Used by the Application Server as a handle for all subsequent operations (GET, UPDATE, DELETE) on that resource
- Embedded within the HTTP request URI for resource addressing in RESTful API calls
- Persists for the entire lifetime of the transaction, which can be days, months, or years
- Essential for managing asynchronous, long-duration IoT services like device monitoring and triggering
Evolution Across Releases
Introduced alongside the formal definition of the Service Capability Exposure Function (SCEF) T8 Application Programming Interface (API). The TLTRI was established as the mandatory identifier for long-term transaction resources, such as those for Monitoring Events and Device Triggers, to enable lifecycle management of these persistent IoT services over the HTTP/2-based T8 reference point.
Defining Specifications
| Specification | Title |
|---|---|
| TS 29.122 | 3GPP TS 29.122 |
| TS 32.299 | 3GPP TR 32.299 |