Common API Framework (CAPIF) in 5G
- CAPIF is a standardized API framework that facilitates registration, discovery, and controlled access to 5G network exposure functions.
- It integrates NEF APIs for QoS monitoring, policy negotiation, and traffic steering, enabling adaptive real-time video streaming from vehicles.
- The automotive PoC highlights CAPIF’s role in securely mediating API consumption to support on-demand QoS upgrades and efficient edge routing.
Common API Framework (CAPIF) is a standardized API exposure, discovery, and access framework that sits between application logic and underlying 5G network exposure capabilities. In the implementation reported in “Enabling On-demand Guaranteed QoS for Real Time Video Streaming from Vehicles in 5G Advanced with CAPIF & NEF APIs,” CAPIF is not the function that creates Quality of Service (QoS) adaptation or traffic steering behavior; rather, it mediates how an automotive application discovers and consumes 3GPP Network Exposure Function (NEF) APIs for monitoring network conditions, requesting on-demand QoS changes, and influencing traffic routing toward the edge (Piscione et al., 3 Aug 2025). The reported proof of concept (PoC) is therefore significant less as a protocol specification than as an integration case study: it shows CAPIF operating as the common exposure and consumption framework for NEF-provided capabilities in a 5G Advanced automotive video-streaming scenario.
1. Concept and architectural position
Within the reported PoC, CAPIF is explicitly aligned with the 3GPP model described in TS 23.222, “Service Exposure Architecture,” version 17.4.0 from September 2023. Its function is described in terms of “service and APIs registration, discovery, and access control,” and it is characterized as “standardized, secure, and scalable.” In practical terms, this means that CAPIF mediates onboarding and publication of APIs, discovery of exposed services, and controlled invocation by the client application.
The paper’s architecture places CAPIF in the “Telco Cloud” virtual machine together with the NEF emulator. CAPIF Core Functions are implemented using ETSI OpenCAPIF. The APIs being published are NEF APIs, so the NEF side acts as the API exposing side, while the enhanced VLC client acts as the application-side API Invoker. The strongest implementation statement is that the VLC-based video client was “extended and complemented with a CAPIF API invoker to consume the NEF APIs” (Piscione et al., 3 Aug 2025).
A central conceptual clarification follows from this deployment. CAPIF does not replace NEF and does not itself implement policy negotiation, monitoring, or traffic steering logic. The NEF or extended NEF emulator provides the service logic and interfaces; CAPIF publishes them for standardized application-side use. This distinction is especially important because CAPIF can otherwise be misconstrued as a network-control function. The reported PoC instead treats it as the exposure and consumption framework around network APIs.
2. Relationship to NEF and exposed API families
The interaction with NEF is direct and central. The network “integrates NEF capabilities, supporting NEF APIs for Policy Decision and Traffic Quality (PDTQ) Policy Negotiation, Application Server Session with QoS and Event Monitoring,” implemented through an extended NEF emulator, “as well as Traffic Influence API implemented in the Free5GC software.” All of these NEF APIs are exposed via CAPIF (Piscione et al., 3 Aug 2025).
The exposed API families can be organized as follows:
| API family | Functional role in the PoC | Exposure path |
|---|---|---|
| Policy Decision and Traffic Quality (PDTQ) Policy Negotiation | Request on-demand QoS upgrades | NEF API exposed via CAPIF |
| Application Server Session with QoS and Event Monitoring | Represent session state and monitor QoS- or cell-related events | NEF API exposed via CAPIF |
| Traffic Influence API | Influence routing or steering toward edge resources | NEF API exposed via CAPIF |
The paper does not provide raw REST resource paths, JSON schemas, HTTP verbs, or complete payload examples. It likewise does not enumerate callbacks or resource URIs. What is established at the functional level is that the application discovers these APIs through CAPIF, invokes monitoring-related NEF APIs to obtain connectivity or QoS status, uses event monitoring related to the target cell and session, and invokes policy or QoS adaptation APIs when a lower threshold in performance is crossed.
This division of labor has broader significance. CAPIF standardizes the application-facing exposure model, while NEF remains the locus of network-exposed functionality. A plausible implication is that CAPIF’s value becomes most evident in deployments where multiple NEF capabilities must be made available to a vertical application through a single common framework rather than through bespoke point-to-point integrations.
3. System realization in the automotive video-streaming PoC
The PoC is built around a real-time uplink video-streaming scenario from a 5G-connected vehicle. A camera on the vehicle sends video over the 5G network, and a remote user views the feed. The emulated system uses Free5GC for the 5G core and UERANSIM for the UE and gNB/RAN emulation. On top of that 5G system, the authors add NEF capabilities and expose those APIs through CAPIF using ETSI OpenCAPIF (Piscione et al., 3 Aug 2025).
The deployment spans four virtual-machine domains in an OpenStack environment: an access network VM for the emulated RAN, an edge segment VM representing the Telco Edge Cloud, a centralized core network VM representing the Telco Cloud, and a final user/application VM containing the enhanced VLC client. On the vehicle side, a Raspberry Pi 4 connected to a camera runs UERANSIM UE software. That UE attaches to a UERANSIM gNB in the RAN VM.
The interface structure makes the control-plane and data-plane separation evident. The gNB connects over N2 to the AMF in the telco cloud and over N3 to an intermediate UPF at the edge. The edge VM contains an I-UPF and an edge RTMP server. The I-UPF connects upstream over N9 to the PSA-UPF in the central core and also to a local N6 network for local breakout or edge communication. The central cloud contains the 5G core control-plane functions, the PSA-UPF, the NEF emulator, and OpenCAPIF. The public-internet-facing client side contains the enhanced VLC application that consumes CAPIF-exposed NEF APIs.
This arrangement also supports traffic redirection to the edge. The paper states that “traffic flows are redirected to the edge to improve latency and optimize network resource utilization,” and identifies the Traffic Influence API as implemented in Free5GC. The text does not provide detailed policy objects or route-selection semantics, but the architecture strongly indicates local breakout or service routing through the edge I-UPF and local N6 connectivity.
4. Operational workflow and invocation model
The reported workflow begins with API publication and onboarding. The demonstration “starts with an initial workflow for the publication of NEF APIs in CAPIF and their discovery by the API invoker in the enhanced video client application.” The NEF-side provider publishes its APIs into the CAPIF framework via OpenCAPIF, and the application-side invoker is onboarded sufficiently to discover them.
The second phase is API discovery. The enhanced VLC client queries CAPIF to discover the available NEF APIs relevant to QoS negotiation, event monitoring, and traffic influence. The third phase is invocation during service operation. When a remote user starts viewing video from the vehicle camera, the client begins using the discovered APIs. In a congested-at-start scenario, the client “detects the poor quality of the connectivity to the car UE” and “immediately requests the QoS upgrade for guaranteed data rate in uplink.” In a dynamic-congestion scenario, the client uses NEF APIs “for QoS monitoring in the target cell” and requests a QoS upgrade dynamically when congestion is later detected (Piscione et al., 3 Aug 2025).
The paper does not report protocol traces, but it permits a high-level reconstruction of the logical sequence. The application first authenticates or gets authorization under CAPIF access control, although the exact security flow is omitted. It discovers API metadata, may create or reference an application server session associated with the streaming service and the vehicle UE, and then polls or subscribes for event or QoS monitoring associated with the target cell or UE session. It evaluates observed performance against a user-defined lower threshold. When that threshold is violated, it invokes a QoS or policy negotiation API to request upgraded uplink treatment for the video flow. Separately, it may invoke traffic influence to steer the corresponding traffic toward the edge RTMP server through the edge UPF.
Several boundaries remain explicit. The paper does not specify a concrete token format, OAuth profile, certificate exchange, or mutual TLS flow. It also does not explicitly state whether event monitoring uses asynchronous callbacks or polling. These omissions matter because they delimit what can be inferred about CAPIF’s security and signaling realization from this PoC.
5. QoS-on-demand and edge steering behavior
The technical heart of the PoC is continuous monitoring of mobile network performance affecting the vehicle’s uplink video stream and on-demand QoS adaptation for selected 5G User Equipment (UE) video traffic flows. The target stream is described as having a maximum of 4.5 Mbps, while additional background traffic is generated through iperf up to 10 Mbps. The principal KPI shown in the results is “Uplink Data Rate for Video Streaming,” plotted as a function of network congestion (Piscione et al., 3 Aug 2025).
In the benchmark case with no guaranteed QoS, the video stream shares bandwidth with increasing numbers of other users, and its uplink data rate degrades as congestion grows. In the adaptive case, the stream initially suffers under congestion as well, but only until a “user-defined lower threshold in performance is reached,” at which point the application automatically invokes QoS-on-Demand through the NEF APIs. The corrective action is a QoS upgrade that provides “guaranteed data rate in uplink,” restoring the stream to a pre-defined acceptable performance level.
The monitored condition is therefore network congestion and the resulting application or network performance of the uplink stream. The paper does not define the lower threshold numerically and does not state whether it is configured directly in bitrate, throughput, packet loss, latency, or an abstract QoE score. Based on the text and figure caption, the measured and controlled variable is uplink data rate. The paper also does not name a GBR bearer or QFI configuration, 5QI values, PCC rule details, or slice/S-NSSAI-based differentiation. There is no mention of network slicing as the mechanism.
Traffic steering complements QoS adaptation. The architecture and abstract indicate that selected traffic can be redirected to the edge to improve latency and optimize resource utilization. A plausible implication is that the combination of Traffic Influence API, I-UPF placement, and local N6 connectivity provides the operational path for steering video-related flows toward an edge-local RTMP server rather than forcing exclusive traversal through a centralized path. The paper, however, does not formalize this with a route-selection algorithm or a detailed policy schema.
6. Experimental scenarios, evidence, and limitations
The methodology compares a no-guaranteed-QoS benchmark against adaptive scenarios under congestion. The paper presents at least three scenarios: Scenario 1 benchmark with no guaranteed QoS; Scenario 2, where congestion already exists when streaming begins and the application immediately requests a QoS upgrade; and Scenario 3, where congestion appears after streaming starts and the application monitors conditions and dynamically requests an upgrade only when needed (Piscione et al., 3 Aug 2025).
The quantitative reporting is limited but informative. In Scenario 1, uplink video throughput drops as congestion increases because the video traffic shares cell bandwidth with more users. In Scenario 3, throughput initially degrades as congestion rises, but after the lower threshold is crossed and QoS-on-Demand is triggered, throughput is brought back to the predefined level. The performance graph further distinguishes vehicle positions near the cell edge and near the cell center. Degradation is reported as more severe at the cell edge, but in both cases the QoS-on-Demand invocation overcomes the degradation.
The evidentiary character of the paper is therefore architectural and scenario-based rather than exhaustive or protocol-level. No exact adaptation delay, packet loss percentage, end-to-end latency, API call latency, or success probability is given in the text excerpt. There are no optimization problems, formal state machines, timing diagrams, or KPI formulas. The paper is explicit about being a short architectural and PoC report rather than a full protocol specification.
These limitations are consequential for interpretation. The implementation uses emulation and open-source prototypes; some NEF functionality comes from an extended NEF emulator rather than a commercial core; and detailed CAPIF security and onboarding procedures are not reported. Accordingly, the work is best understood as an open-source PoC realization of CAPIF concepts rather than a conformance-validation study or a full operational-security reference design.
7. Significance for CAPIF in 5G Advanced verticals
As a CAPIF case study, the paper’s principal contribution is to make CAPIF concrete in a vertical application setting. CAPIF is shown as the common exposure and consumption framework through which an automotive application can discover and invoke NEF APIs for QoS monitoring, event monitoring, policy negotiation, and traffic influence in a standardized manner. Its practical value in this implementation lies in API publication, discovery, and access control, rather than in replacing underlying 5G functions (Piscione et al., 3 Aug 2025).
The interoperability significance follows directly from that role. The video application does not integrate point-to-point against bespoke NEF exposure. Instead, NEF APIs are published into a common exposure framework and consumed by an application-side invoker in a standardized way. This suggests two concrete benefits within the reported design: one common discovery and invocation framework for multiple exposed APIs, and unified handling of security and access control at the CAPIF framework level, at least conceptually.
The paper is equally useful for delimiting what CAPIF is not. It does not claim full conformance validation against TS 23.222, does not discuss deviations from that standard, and does not compare OpenCAPIF behavior against a production CAPIF deployment. It does not provide exact CAPIF onboarding procedures, low-level protocol traces, or complete API payload specifications. CAPIF therefore emerges not as a substitute for NEF or policy control, but as the standardized mediator between vertical applications and network-exposed capabilities.
Taken together, the reported PoC presents CAPIF as an operational layer for secure, controlled, and standardized API consumption in 5G Advanced. In the specific automotive video-streaming scenario, its value is demonstrated by enabling an application-side invoker embedded in an enhanced VLC client to discover and consume NEF APIs that support monitoring, on-demand uplink QoS upgrades, and edge-oriented traffic steering. The result is a deployment-oriented view of CAPIF: not a theoretical abstraction, but a practical exposure framework situated between application logic and NEF-provided network assistance.
