TDO

Triggered Declarative Object

Services
Introduced in Rel-13
A Triggered Declarative Object (TDO) is a data structure defined in 3GPP for service capability exposure. It represents a specific piece of information or a network event that can be requested by an external application. Its primary role is to enable Application Programming Interfaces (APIs) to declaratively request network data, simplifying integration for third-party services.

Description

The Triggered Declarative Object (TDO) is a fundamental concept within the 3GPP framework for network exposure, specifically detailed in TS 26.953. It functions as a standardized data model or object that encapsulates a specific type of information or a detectable event within the mobile network. This object is 'declarative' because an external Application Server (AS) or Service Capability Server (SCS) requests it by describing *what* data it needs, not *how* the network should obtain it. The network entity responsible for exposure (like the Network Exposure Function, NEF, in 5G) interprets this declaration, maps it to internal network monitoring or reporting functions, and manages the delivery of the corresponding data.

Architecturally, a TDO is defined by a set of attributes, conditions, and a delivery mechanism. Key components include the object identifier, the triggering event or condition (e.g., a UE entering a specific area, a change in connectivity status), the data payload to be reported (e.g., location, status), and subscription parameters like validity time and reporting frequency. The TDO request is typically part of a subscription dialogue between the AS and the exposure function. Once subscribed, the network monitors for the specified trigger condition. Upon detection, it instantiates the TDO with the current relevant data and delivers it to the requesting application via a callback or notification.

Its role is central to the Service Enabler Architecture Layer (SEAL) and the broader Capability Exposure framework. By providing a structured, abstracted view of network information, TDOs shield application developers from the complexities of underlying network protocols and internal state management. They enable a wide range of services, from location-based alerts and quality of experience monitoring to IoT device management. The TDO mechanism ensures that network data is provided in a consistent, secure, and controlled manner, adhering to operator policies and user privacy regulations.

Purpose & Motivation

The TDO was introduced to address the growing need for standardized and efficient network exposure to third-party applications. Prior to its definition, exposing network events and information often required custom, point-to-point integrations that were complex, non-scalable, and prone to inconsistencies. This hindered innovation and the rapid deployment of new services that relied on real-time network intelligence. The TDO concept provides a declarative model that abstracts network capabilities.

Its creation was motivated by the industry shift towards open APIs and network programmability, particularly for IoT and vertical market applications. By allowing applications to declaratively request specific triggered information, it simplifies the developer experience, reduces integration time, and ensures interoperability across different operator networks. It solves the problem of how to safely and efficiently grant external entities access to dynamic, event-driven network data without compromising network security, stability, or user privacy. The TDO framework establishes a clear contract between the network and the application.

Key Features

  • Declarative data model for requesting network information
  • Event-triggered or condition-based data reporting
  • Standardized object structure defined in 3GPP specifications
  • Enables asynchronous notifications to applications
  • Abstracts underlying network complexity from service developers
  • Supports subscription management with validity and frequency controls

Evolution Across Releases

Rel-13 Initial

Initial introduction of the Triggered Declarative Object concept within the Service Enabler Architecture Layer (SEAL) for vertical services. Defined the core architectural model for declarative request of network-triggered information, establishing the foundational API mechanisms for capabilities like device triggering and location reporting.

Defining Specifications

SpecificationTitle
TS 26.953 3GPP TS 26.953