Design of a DetNet Framework in a 3GPP 5G System

Abstract

Ultra-low latency communication is fundamentally required to reduce end-to-end (E2E) latency related to the transportation of time-critical or time-sensitive traffic in 5G networks. Time-sensitive networking has significant prospects in factory automation and Industrial Internet of Things (IIoT) as a key technology that can provide low-latency, highly reliable, and deterministic communications over Ethernet, whereas IETF deterministic networking (DetNet) seeks to provide a complementary network layer to support ultra-low latency communications. DetNet, as standardized in the IETF, provides time-sensitive characteristics that assure extremely low packet loss and latency for ultra-reliable low-latency communications. This study develops a novel framework to enable 3GPP support for DetNet functionalities. First, the proposed framework seeks to support IP-based DetNet traffic and urgent data transmission in the network overload conditions of 3GPP 5G systems. Additionally, the proposed design supports DetNet service connectivity between non-DetNet and DetNet service areas. Based on simulation results, the proposed framework can guarantee deterministic latency requirements and critical data transmission for DetNet compared with conventional approaches. The proposed scheme can achieve more effective performance for moving DetNet devices.

1. Introduction

The rapid paradigm shift toward Industry 4.0 and the Industrial Internet of Things (IIoT) has fundamentally transformed the requirements for wireless communication infrastructures. In modern industrial ecosystems, such as smart factories, automated warehouses, and remote robotic surgery, the demand for ultra-reliable and low-latency communication (URLLC) is no longer a peripheral requirement but a core necessity. To support these mission-critical applications within the 3GPP 5G System (5GS), it is essential to provide deterministic communication capabilities that guarantee bounded end-to-end (E2E) latency, extremely low jitter, and near-zero packet loss for time-sensitive traffic [1,2].

Traditionally, time-sensitive networking (TSN), standardized by the IEEE 802.1 task group, has served as the primary technology for deterministic communication over Layer 2 Ethernet. However, as industrial networks expand across heterogeneous domains and cross-regional boundaries, the limitations of Layer 2-based determinism become apparent. This has led to the emergence of deterministic networking (DetNet) by the IETF, which extends deterministic properties to Layer 3 IP and multi-protocol lable switching (MPLS) networks [3]. As emphasized in the recent comprehensive study by Cuozzo et al. [4], the seamless convergence of 5G access and DetNet-based wide-area networks is critical for creating a unified E2E deterministic path. This convergence is particularly vital for vertical industries where diverse traffic types—ranging from periodic control messages to bursty high-definition video streams—must be managed under strict Quality of Service (QoS) constraints [4,5].

Time-sensitive networking (TSN) and deterministic networking (DetNet) address deterministic communication at different layers and scopes. TSN primarily operates at Layer 2, providing bounded latency and low jitter for Ethernet-based local area networks, such as factory floors. In contrast, DetNet focuses on Layer 3 deterministic forwarding, enabling end-to-end deterministic guarantees across routed IP networks. Within the 3GPP 5G System, TSN support is mainly used for integration with Ethernet-based industrial networks, while DetNet is essential for extending deterministic services across the 5G core and wide-area network segments.

From a QoS perspective, TSN relies on time-aware scheduling, traffic shaping, and frame preemption at Layer 2. DetNet, on the other hand, provides deterministic guarantees through explicit path control, resource reservation, packet replication and elimination, and bounded-delay forwarding at Layer 3. These mechanisms make DetNet suitable for large-scale and multi-hop 5G network environments beyond the scope of TSN.

In Industrial Internet of Things (IIoT) scenarios, deterministic communication requirements often extend beyond isolated factory networks. Typical examples include collaborative smart manufacturing equipment, where multiple robots and controllers must exchange time-critical data with bounded latency, and industrial control command transmission, which requires ultra-high reliability and predictable delay across the entire communication path. Such requirements cannot be fully satisfied by TSN alone when traffic traverses routed 5G networks, highlighting the necessity of DetNet support within 5GS.

Despite its importance, the integration of DetNet into the 3GPP 5G architecture faces several significant technical hurdles that have not been fully addressed in the existing literature. Most prior research has focused on the 5GS acting as a transparent bridge for TSN, largely ignoring the specific signaling and session management requirements of Layer 3 DetNet flows [6]. Furthermore, conventional 5G mechanisms for access control and resource allocation often introduce unpredictable delays during network congestion, which directly contradicts the principles of determinism. As noted in current research challenges by Cuozzo et al. [4], there is a lack of practical frameworks that can dynamically map DetNet flow requirements to 5G internal resources while minimizing signaling redundancy. Moreover, many existing proposals rely on static configurations that do not account for the high mobility and dynamic link quality inherent in wireless environments.

Motivated by these challenges, this paper proposes a novel DetNet-integrated framework specifically designed for the 3GPP 5G System. Our framework aims to fulfill the rigorous 3GPP DetNet service requirements while optimizing performance for urgent service connectivity scenarios. Unlike previous studies that treat the 5G network as a simple bit-pipe, our approach introduces a DetNet-aware architectural design that deepens the interaction between the UE and the core network functions. The primary contributions of this paper are summarized as follows:

First, we propose a new PDU session type specifically tailored for DetNet traffic, which ensures seamless compatibility with existing IPv4/v6 and Ethernet sessions while providing dedicated resources for deterministic flows. Second, we extend the 3GPP Unified Access Control (UAC) mechanism to include a “DetNet-specific access category”, allowing for prioritized network access and reduced signaling latency for critical IIoT commands. Third, we implement a resource reservation and scheduling logic that interacts with the Policy Control Function (PCF) and User Plane Function (UPF) to guarantee bandwidth and minimize E2E delay. Finally, we validate our framework through extensive simulations using diverse traffic models and high-density UE scenarios to prove its technical soundness and scalability in realistic industrial environments.

By addressing the limitations identified by both the academic community and standardization bodies, this work provides a robust foundation for the future deployment of deterministic services in 5G-enabled vertical industries. The remainder of this paper is structured as follows: Section 2 reviews the related work and standardization status. Section 3 details the proposed DetNet framework. Section 4 evaluates the performance, and Section 5 concludes the paper.

2. Related Studies on 3GPP

2.1. Time-Sensitive Communications

In 3GPP Release 17, the 5GS supports time synchronization and time-sensitive communication (TSC) for IIoT applications. As shown in Figure 1, a 5GS is integrated with an external network as a TSN bridge in an IEEE 802.1 TSN [7,8,9,10].

Figure 1. System architecture for TSC and time synchronization services with 5GS in 3GPP TS 23.501.

The 5GS bridge supports TSC, as defined in the IEEE Std 802.1 TSN. The 5GS architecture allows any application function (AF) to provide its quality of service (QoS) requirements and traffic characteristics for QoS scheduling optimization, time synchronization, activation, and deactivation [8]. If the AF is in a trust domain different from the 5GS, it provides input via the exposure framework (network exposure function (NEF) API). If the AF is in the same trust domain as a 5GS, it provides input directly via a time-sensitive communication time synchronization function (TSCTSF).

The (logical) TSN bridge includes the TSN translator functionality for interoperation between TSN systems and the 5GS for the user and control planes. The 5GS TSN translator functionality comprises a device-side TSN translator (DS-TT) and a network-side TSN translator (NW-TT). The TSN AF is part of the 5G core network (5GC) and provides control plane translator functionality for integrating a 5GS with a TSN network. The 5GS-specific procedures in 5GC, RAN, and wireless communication links remain hidden from the TSN network. To achieve such transparency in the TSN network, so that the 5GS appears as any other TSN Bridge, the 5GS provides TSN ingress and egress ports via DS-TT and NW-TT.

2.1.1. Time Synchronization

Two main synchronization methods are supported in 3GPP 5GS, 5GS clock synchronization, and the generalized Precision Time Protocol ((g)PTP) synchronization [9]. The 5GS clock synchronization is used for next-generation radio access network (NG RAN) synchronization and is distributed to user equipment (UE). The (g)PTP synchronization provides a time synchronization service to the (g)PTP network.

2.1.2. Time-Sensitive Communication QoS

TSC assistance information (TSCAI) describes traffic characteristics that may be provided for use by the gNB to allow more efficiently scheduled radio resources for periodic traffic and applies them to the protocol data unit (PDU) session-type Ethernet and IP. TSCAI was defined and used for TSC traffic characteristics in the 3GPP 5GS [9].

The 5GS decides the TSC assistance container based on information provided by an AF/NEF and may provide it to the PCF for IP- and Ethernet-type PDU sessions. The AF may provide traffic pattern parameters, such as burst arrival time with reference to the ingress port, periodicity, flow direction, survival time, and time domain, to the NEF. NEF forwards the received traffic pattern parameters to the TSCTSF.

2.2. Deterministic Networking

Currently, 3GPP is working on the DetNet functionalities in Release 18. DetNet support in 3GPP is achieved by reusing the TSC framework for deterministic QoS and time synchronization services included in Release 17 [9,11].

The 3GPP support for DetNet provides mapping between the central DetNet controller entity (as defined in IETF) and the 5GS [12]. Mapping involves translating the DetNet traffic profile and flow specifications to 5GS QoS parameters and TSCAI. The mapping functionality of DetNet was realized using the TSCTSF.

2.3. Access Control

Access control is fundamentally used to alleviate and control congestion in a radio access network (RAN). In a 5GS, the network can prevent access attempts from the UEs using unified access control (UAC) functionality under high network overload conditions [8,9,13,14]. The UAC is a mechanism that decides whether to allow the UE for certain services or state changes. For UAC, depending on the network configuration, the network decides whether certain access attempts should be passed or prevented based on the access categories and identities. Access categories are a type of access attempt by the UE for mobile-originated data/signaling, and access identities are a set of UE configurations for special services, similar to access classes in 4G/LTE systems [15,16,17].

Under a RAN overload situation, the RAN broadcasts barring control information via system information block 1 (SIB 1). Barring control information includes a list of barring parameters associated with the access identity and category.

As shown in Figure 2, when the UE NAS detects mobile-originated data/signaling or a certain stage change request, the UE NAS performs the mapping of the type of request to one or more access identities and one access category, and provides the mapped access identity and the category to the user equipment (UE) radio resource control (RRC). The UE RRC performs access barring checks for requests based on the decided access identities and categories. If the request is barred from access-barring checks, the UE RRC indicates to the UE NAS that the request is barred owing to access-barring checks. If the request is barred, the mobile-originated data/signaling or a certain stage change request cannot be signaled to the RAN; however, the mobile-originated data/signaling or a certain stage change request can be signaled to the RAN, provided that the request is unbarred. Consequently, through the UAC functionality, the UE’s attempts to access the RAN can be controlled.

Figure 2. Unified access control in a 3GPP 5G system (left) and NAS level congestion control in a 3GPP 5G system (right).

Meanwhile, for UAC, mobile-originated data/signaling requests for paging responses or emergency calls should not be barred, irrespective of access identities. In addition, mobile-originated data/signaling requests with special access identities cannot be barred.

2.4. Congestion Control

As shown in Figure 2, NAS-level congestion control is achieved based on a back-off time mechanism for congestion control in the 3GPP 5GS [8,9,13] and it comprises two functionalities: NAS mobility management (MM) and NAS session management (SM). The NAS MM and SM congestion controls operate independently in the UE [8,9,13,15,16].

2.4.1. Mobility Management Congestion Control

For NAS MM congestion control [13], under 5G mobility management (5GMM) signaling congestion conditions, AMF (Access and Mobility Function) in the 5GC rejects 5GMM signaling requests from the UEs. When a NAS request is rejected, the MM back-off time is sent by the AMF to the UE. While the MM back-off timer (T3346) is running, the UE shall not initiate any NAS request except for deregistration procedures and procedures not subject to congestion control, such as high-priority access, emergency services, and mobile-terminated services (paging responses).

When the general NAS-level congestion control is active, the AMF includes a value for the MM back-off timer T3346, with a reject cause value (#22: congestion) in the reject message. The UE starts timer T3346 with the value received in the 5GMM reject messages. If the UE receives the paging or notification message when timer T3346 is running, the UE stops the timer T3346 and responds to the paging or notification message. If the UE enters a new public land mobile network (PLMN) while timer T3346 is running and the new PLMN is not equivalent to the PLMN where the UE started timer T3346, the UE stops timer T3346 when initiating the 5GMM procedures in the new PLMN. If timer T3346 is running, and the UE is configured for high-priority access in the selected PLMN, or the UE must initiate signaling for emergency services, the UE is allowed to initiate 5GMM procedures.

2.4.2. Session Management Congestion Control

For NAS SM congestion control (data network name (DNN)-based congestion control, single-network slice selection assistance information (S-NSSAI)-based congestion control, and S-NSSAI and DNN-based congestion control) [13], SMF (Session Management Function) in the 5GC rejects 5G session management (5GSM) signaling requests from UEs under 5GSM signaling congestion conditions. When a NAS request is rejected, the SM back-off time is sent by the SMF to the UE. While the SM back-off timer (T3396) is running, the UE shall not initiate any NAS request, except for a network-initiated SM procedure and procedures not subject to congestion control, such as high-priority access and emergency services. In that case, the UE stops the back-off timer and responds to the 5G core network.

When the DNN-based congestion control is active, the network includes a value for the SM back-off timer T3396 associated with the DNN and a rejection cause value (#26: insufficient resources) in the reject messages. The UE starts timer T3396 with the value received in the 5GSM reject messages, and the UE shall not initiate any SM procedures for the congested DNN. However, the UE can initiate the SM procedures for other DNNs. If no DNN is associated with the back-off timer, the UE can initiate only the SM requests of any PDU session type for a specific DNN. Upon a tracking area (TA), radio access technology (RAT), or PLMN change, the UE does not stop the back-off timer and maintains a separate SM back-off timer for each DNN.

On the other hand, as described previously, the congestion control has no relationship with the access control (i.e., UAC). The congestion control is operated independently from UAC. Thus, if the DetNet traffic passes the congestion control in the UE NAS layer, it can be barred because of UAC operation in the UE RRC layer. Therefore, both the congestion control and access control should be considered together for the urgent DetNet traffic transmission.

3. Detnet Framework for 3GPP 5G System

3.1. Proposed DetNet Framework

The proposed DetNet framework operates based on existing 5G protocols (such as NAS, RRC, and IP protocols). Four new functionalities exist in the proposed DetNet framework: support for the IP-based DetNet PDU session, support for DetNet in UAC, support for urgent DetNet transmission, and support for DetNet service connectivity. It assumes presence of the existing 3GPP Release 17/18 architecture and does not introduce modifications to the physical layer or radio scheduling mechanisms. Instead, the framework extends existing NAS and RRC procedures to support deterministic traffic handling while maintaining backward compatibility with legacy 3GPP systems.

The proposed DetNet PDU session type is designed as a logical extension of existing IPv4/IPv6 and Ethernet PDU sessions. It reuses the standard PDU session establishment, modification, and release procedures defined in 3GPP, without introducing new user-plane protocols or radio-layer changes. As a result, legacy PDU session types and DetNet PDU sessions can coexist within the same 5G system.

A UE can smoothly migrate from a non-DetNet PDU session to a DetNet PDU session by either triggering a standard PDU session modification procedure or establishing a parallel DetNet PDU session. This migration does not disrupt ongoing services and allows gradual adoption of deterministic communication when required.

When multiple PDU sessions are active simultaneously, resource isolation is achieved through existing 5G QoS mechanisms. DetNet traffic is mapped to dedicated QoS flows with reserved resources and bounded-delay characteristics, while non-DetNet traffic follows conventional best-effort or QoS-aware scheduling. This ensures that deterministic services are protected from interference caused by other concurrent PDU sessions.

3.1.1. Support for IP-Based DetNet PDU Session

To support IP-based DetNet PDU sessions for 3GPP 5GS, a new PDU session type for DetNet must be defined as “DetNet” in the proposed DetNet framework.

When a UE must establish a PDU session for a DetNet service or application, the UE NAS sets “DetNet” to the PDU session setup request message as the IP PDU session type for DetNet and sends this PDU session setup request message to the 5GC. If the network supports the DetNet PDU session requested by the UE, the network responds that the PDU session setup has accepted the message from the UE. If the network does not support the DetNet PDU session requested by the UE, the network responds to the PDU session setup by rejecting messages with a cause value. Thus, the UE cannot use a DetNet PDU session with the network but can use other PDU sessions (e.g., IPv4 or IPv6) if applicable.

The introduction of a DetNet PDU session type is designed to be fully backward-compatible with existing 3GPP systems. The proposed session type reuses the standard PDU session establishment and management procedures, and does not require modifications to the radio access protocol stack or user-plane packet forwarding mechanisms. From an implementation perspective, the required adaptation is mainly limited to NAS signaling interpretation and policy control functions (e.g., SMF and PCF) in the 5G Core network.

If the serving network does not support the DetNet PDU session type, the PDU session establishment request is rejected using existing 3GPP-defined cause values, allowing the UE to fall back to conventional IP or Ethernet PDU sessions when applicable. As a result, legacy networks and UEs can coexist without service disruption. Compared to introducing new user-plane protocols or radio scheduling mechanisms, the adaptation cost of the proposed approach is relatively low, as it relies on control-plane extensions and configuration-level support rather than fundamental architectural changes.

The proposed framework does not redefine bandwidth reservation or resource scheduling mechanisms. Instead, it is designed to operate in coordination with existing 5G core network functions, particularly the Policy Control Function (PCF) and the User Plane Function (UPF), which are responsible for policy management and resource enforcement.

For DetNet services, deterministic transmission requirements, such as latency bounds and minimum bandwidth guarantees, are translated into policy rules managed by the PCF. These rules define the QoS parameters and resource reservation policies associated with DetNet PDU sessions. The UPF enforces the resource allocation decisions by mapping DetNet traffic to dedicated QoS flows with reserved bandwidth and appropriate scheduling priority. This ensures isolation between DetNet and non-DetNet traffic at the user-plane level.

Bandwidth and computing resource allocation can be dynamically adjusted based on network load and service priority. When congestion is detected, policy updates from the PCF allow the UPF to adapt resource allocation while preserving the deterministic performance requirements of DetNet services.

A dedicated DetNet PDU session type is introduced to explicitly distinguish DetNet traffic from conventional IP and Ethernet traffic. This separation enables independent policy control, precise QoS mapping, and clear interaction with access and congestion control mechanisms, which would be difficult to guarantee when reusing existing PDU session types.

3.1.2. Support for DetNet in UAC

To support DetNet in UAC, a new access category “MO DetNet” and RRC establishment cause “mo-DetNet” must be defined for the NAS layer, and the new barring control information must also be defined for the RRC layer in the proposed DetNet framework.

When a UE detects mobile-originated DetNet signaling/data, it decides on an access category and identity for the mobile-originated DetNet signaling/data, and provides this access category and identity to the RRC layer. The UE RRC performs a UAC check for mobile-originated DetNet signaling/data with the provided access category and access identity from the NAS layer and barring control information from the network. If the UAC check passes, the RRC initiates an RRC connection setup request message to the network with RRC establishment cause “mo-DetNet” for the mobile-originated DetNet signaling/data. If the UAC check does not pass, the RRC informs the NAS that the access attempt for the mobile-originated DetNet signaling/data is barred.

3.1.3. Support for Urgent DetNet Transmission

To support urgent DetNet transmissions, the UAC skip and back-off time overriding indications are introduced in the proposed DetNet framework.

(i) UAC skip for urgent DetNet transmission: When a UE detects urgent mobile-originated DetNet signaling/data, the UE NAS decides an access category and identity for the urgent mobile-originated DetNet signaling/data with a UAC skip indication, and provides this access category and identity with a UAC skip indication to the RRC layer. If the UE RRC is provided with the UAC skip indication from the NAS layer, the UE RRC skips the UAC check for mobile-originated DetNet signaling/data. Thus, the RRC initiates an RRC connection setup request message to the network with the RRC establishment cause “mo-DetNet” for urgent mobile-originated DetNet signaling/data.

(ii) Back-off time overriding for urgent DetNet transmission: During registration, the DetNet-capable UE provides the DetNet signaling configuration to the 5GC, indicating that the signaling of the UE can provide the DetNet data service. Under network congestion, if the back-off time is provided by the network, the UE operates the back-off timer with the provided back-off time and does not initiate any NAS signaling to the network.

When a UE detects an urgent DetNet signaling/data transmission, but the back-off timer is running, the UE NAS can initiate NAS signaling for urgent DetNet signaling/data with a DetNet signaling overriding indication and sends the NAS signaling message to the network. The network processes this NAS signaling message with the DetNet signaling overriding indication as the meaning of exceptional handling for urgent DetNet data transmission even if network congestion occurs. If the network receives a NAS signaling message without the DetNet signaling overriding indication, then the network rejects the NAS signaling message and does not process it. Therefore, urgent DetNet signaling and data can be promptly transmitted and processed.

(iii) UAC skip and back-off time overriding for urgent DetNet transmission: As explained earlier, the congestion control is operated independently from UAC. It means even if the back-off time overriding mechanism is performed to transmit urgent DetNet traffic in the NAS layer, the urgent DetNet traffic could be barred because of UAC operation in the RRC layer. Therefore, both the back-off time overriding and UAC skip mechanism should be considered to promptly transmit urgent DetNet traffic.

Under network congestion, if a UE detects an urgent DetNet signaling/data transmission, but the back-off timer is running, the UE NAS can initiate NAS signaling for urgent DetNet signaling/data with a DetNet signaling overriding indication and UAC skip indication, and passes the NAS signaling message to the RRC layer. The RRC layer passes UAC check based on the UAC skip indication and sends the NAS signaling message to the network. The network processes this NAS signaling message with the DetNet signaling overriding indication for urgent DetNet data transmission even if network congestion occurs. Therefore, with the UAC check and back-off timer running, urgent DetNet signaling and data can be promptly transmitted and processed.

When urgent DetNet data is generated at the UE, the NAS layer classifies the traffic as urgent DetNet traffic and attaches both a UAC skip indication and a back-off time overriding indication. This NAS message is then passed to the RRC layer, which bypasses the access barring check based on the received indication and initiates the RRC connection establishment procedure. Subsequently, the NAS signaling message containing the overriding indication is delivered to the 5GC for exceptional processing under congestion conditions.

3.1.4. Support for DetNet Service Connectivity

According to the current requirements of 5GS, there is no support for DetNet service connectivity. DetNet service connectivity means that a UE can obtain a DetNet-PDU session connectivity to get a DetNet service promptly.

To support timely DetNet services in between DetNet and non-DetNet service areas, the DSA indication and information are defined in the proposed DetNet framework. The DSA indication implies that the DetNet-capable UE requests DSA information from the network and the DSA information means the network informs the UE of the DSAs, which consists of tracking area identity (TAI) lists.

A DSA-capable UE requests DSA information with the DSA indication from the network during registration or UE configuration update procedure. If the network supports the DetNet service, it provides DSA information to the UE. Therefore, the UE is aware of the DSAs.

Using the DSA information, the UE can recognize which the DetNet areas are among the service areas using the TAI lists. When the DetNet capable UE moves from the non-DSA to the DSA, the DetNet-capable UE can be aware of this DSA using the stored DSA information; thus, the UE can perform the DetNet PDU session setup procedure to immediately obtain the DetNet service. DSA information can be provided from the network to UE during the (periodic) registration or UE configuration update procedure. The overall proposed DetNet framework for 3GPP 5GS is shown in Figure 3.

Figure 3. Proposed DetNet framework for 3GPP 5G system.

DSA information is provided to the UE during existing registration or UE configuration update procedures, avoiding additional signaling overhead. The information is semi-static and updated only when necessary, making the proposed service connectivity mechanism lightweight and suitable for practical deployment.

3.2. UAC-Based Access Control Extension

The proposed UAC extension does not introduce additional signaling procedures or new message types. It relies on existing system information broadcasting (e.g., SIB1) and standard RRC connection establishment procedures defined in 3GPP. As a result, the signaling overhead in terms of message frequency and message size remains unchanged compared to the legacy UAC mechanism.

By enforcing access barring decisions at an earlier stage, the proposed mechanism prevents unnecessary RRC connection attempts and subsequent NAS signaling exchanges during congestion. This early filtering effect reduces redundant signaling toward both the RAN and the 5G Core network, especially under high access load conditions.

From a network perspective, the reduction of failed or rejected access attempts translates into lower processing load at the gNodeB and core network functions. Therefore, although the UAC mechanism itself remains lightweight, its extension contributes to an overall reduction in network burden during congestion scenarios.

The newly introduced MO DetNet access category is assigned a priority level lower than emergency calls and high-priority access categories, but higher than regular mobile-originated traffic. This priority ordering ensures that critical emergency services are always protected while still enabling preferential access for deterministic DetNet traffic.

The barring control parameters for the MO DetNet category, such as barring probability thresholds and activation conditions, are configured by the network based on congestion levels and operator policies. For example, MO DetNet access may be barred only under severe overload conditions, using a lower barring probability compared to regular mobile-originated traffic.

The UAC skip and back-off time overriding mechanism does not bypass or weaken existing 5G security procedures. It is applied only to UEs that have successfully completed standard authentication and authorization procedures. All access decisions remain under network control and are enforced based on validated subscription and policy information.

Before enabling UAC skip or back-off overriding, the network verifies the legitimacy of the DetNet service request. This verification includes UE identity authentication, subscription profile inspection, and DetNet service authorization through control-plane functions such as AMF, SMF, and PCF.

Although a UE may indicate an urgent DetNet transmission request, the final decision to apply UAC skip or back-off override is made exclusively by the network. This network-centric decision model prevents malicious terminals from abusing the mechanism to unfairly occupy network resources. Furthermore, the application of the UAC skip mechanism is subject to operator-defined policies, such as limited activation frequency, strict trigger conditions, and congestion-aware restrictions. These constraints further reduce the risk of resource abuse.

Therefore, the proposed urgent DetNet access mechanism operates within the existing 3GPP security framework and introduces no additional security vulnerabilities.

3.3. Emergency Transmission Mechanism

The proposed emergency transmission mechanism does not modify or relax existing 5G security procedures. All emergency-related transmissions are protected by standard 3GPP security mechanisms, including mutual authentication, NAS security, and integrity and ciphering protection. The mechanism operates within the authorized PDU session context and does not allow unauthorized traffic prioritization.

The activation of emergency transmission is based on predefined and well-defined conditions rather than heuristic or ad hoc decisions. Typical trigger conditions include emergency service indication, operator-configured policy rules, or explicit congestion state information provided by the network. The proposed framework assumes that the validity of emergency traffic is verified by existing control-plane functions (e.g., AMF and PCF).

While the UE may indicate an emergency service request, the final decision on enabling emergency transmission is made by the network based on policy and authorization checks. This separation prevents misuse of the emergency mechanism and ensures controlled operation.

Therefore, the proposed emergency transmission mechanism is policy-driven, securely controlled, and activated only under clearly defined conditions, eliminating ambiguity in both security handling and trigger logic.

4. Performance Evaluation

The performance of the proposed framework was evaluated for the latency of DetNet data transmission and compared with the existing approach using MATLAB 2023A. The latency of DetNet data transmission indicates the transmission latency of the NAS signaling message that is used to obtain PDU session connectivity for urgent DetNet traffic transmission. In this work, the performance evaluation primarily focuses on transmission delay as a representative metric. This choice is motivated by the fact that the proposed framework operates at the access control and PDU session management levels, which have a direct impact on access latency and congestion-induced delay rather than packet-level forwarding behavior. In the evaluation, an exponential distribution with mean 60 s was used as a traffic model and the number of UEs was 50. Also, the value of UE processing delay was set to 3 ms; the value of RAN processing delay was set to 2 ms; the value of transmission delay of NAS signaling message was set to 1 ms; and the value of 5GC delay was set to 1 ms.

The simulation environment adopts a simplified and controlled model to focus on the procedural effects of the proposed DetNet framework. Specifically, fixed processing delays and a limited number of UEs are used to eliminate confounding factors and ensure fair, repeatable comparisons with the existing 3GPP mechanisms. The purpose of this evaluation is to assess the relative latency behavior introduced by access control and congestion control procedures, rather than to model absolute end-to-end latency under fully realistic traffic conditions.

The processing delay values at the UE and RAN are fixed for all evaluated schemes and do not affect the relative performance comparison. Since both the proposed framework and the baseline 3GPP approach share the same delay configuration, the latency reduction observed in the results is attributable solely to the proposed procedural enhancements.

On the other hand, ultra-high reliability requirements (e.g., 10⁻⁹ transmission success rate) are typically achieved through a combination of physical-layer techniques, packet replication, and redundancy mechanisms. The proposed framework complements these mechanisms by reducing congestion-related failures at the access and session levels, thereby contributing to end-to-end reliability in a complementary manner.

When high-priority DetNet traffic coexists with ordinary traffic, their interaction is regulated by existing 5G QoS mechanisms. DetNet traffic is mapped to dedicated QoS flows with reserved resources, while ordinary traffic follows conventional scheduling. This separation prevents performance degradation of DetNet services while maintaining controlled fairness for non-DetNet traffic.

4.1. Latency for Urgent DetNet Transmission

As described previously, when a back-off timer runs in the UE, the UE cannot initiate NAS signaling to transmit DetNet signaling/data. However, urgent DetNet signaling/data should be transmitted immediately to the network even if the back-off timer is running in the UE because it is important in the network (e.g., alarm/warning processing, security management, and incident response).

In the simulation, we assumed that an MM or SM back-off time was provided by the network and was running in the UE [13,16]. In addition, the values of the SM back-off timer were set to 10, 15, 20, and 30 min and those of the MM back-off timer were set to 10 and 20 min respectively. Furthermore, a barring timer was running for UAC in the UE separately and the value of the barring timer was set to 128 s. In the 3GPP standards, the registration update timer for the initial registration was T3512 [13] and was set to 10, 15, 20, and 30 min. Compared with the existing 3GPP approach, the latency of DetNet data transmission was evaluated.

The latency for urgent DetNet data transmission with the SM back-off time is shown in Figure 4. Assuming the network is congested, the network provides an SM back-off time for the UE and the UE runs the provided SM back-off time. Also, the barring time is provided by the network. In the existing 3GPP approach (marked as 3GPP), if an urgent DetNet data/signaling is generated, the UE cannot initiate a PDU session setup request to the network to transmit urgent DetNet data/signaling because the SM back-off timer is running. However, in the proposed DetNet framework, called the novel DetNet framework (NDF), the UE can initiate a PDU session setup request through overriding the indication to the network in order to transmit the urgent DetNet data/signaling, even if the SM back-off timer is running. Moreover, the PDU session setup request signaling passes UAC with UAC skip indication. Therefore, urgent DetNet data/signaling can be transmitted immediately to the network using the NDF mechanism. When the SM back-off time was set to 10 min, the latency of the NDF was 29.75 ms; however, the latency of the 3GPP approach was 329.75 ms. The latency of the 3GPP approach was worse when the SM back-off time was longer. We can see NDF outperformed the existing 3GPP approach in this case.

Figure 4. Latency for urgent DetNet data transmission with SM back-off time.

The latency for urgent DetNet data transmission with MM and SM back-off times is shown in Figure 5. Assuming network congestion occurs, the network separately provides the MM and SM back-off times for the UE. In the existing 3GPP approach (marked as 3GPP), if urgent DetNet data/signaling is generated and the UE is in idle mode, the UE cannot initiate a service request to the network so that it is first in the connected mode because the MM back-off timer is running. However, in the proposed NDF, the UE can initiate a service request to the network to be in the connected mode and can initiate a PDU session setup request to the network to transmit urgent DetNet data/signaling, even if the MM and SM back-off timer are running. Moreover, the service request and PDU session setup request signaling pass UAC with UAC skip indication. Therefore, urgent DetNet data/signaling can be immediately transmitted to the network using the NDF mechanism. When the MM and SM back-off times were set to 10 min, the latency of the NDF was 29.75 ms; however, the latency of the 3GPP approach was 329.75 ms. When the MM and SM back-off times were set to 20 and 10 min, respectively, the UE could transmit the urgent DetNet data/signaling after the SM back-off timer expired first and MM back-off timer expired in the existing 3GPP approach, whereas the NDF could transmit the urgent DetNet data/signaling immediately. The latency of the NDF was 29.75 ms, whereas that of the 3GPP approach was 659.5 ms. When the MM and SM back-off times were set to 10 and 20 min, respectively, the same simulation results were obtained. In this case, the UE could transmit the urgent DetNet data/signaling after the MM back-off timer expired first and the SM back-off timer expired in the existing 3GPP approach, whereas the NDF could transmit the urgent DetNet data/signaling immediately. Clearly, NDF outperformed the existing 3GPP approach.

Figure 5. Latency for urgent DetNet data transmission with MM and SM back-off times.

4.2. Latency for DetNet Service Connectivity

Currently, no method exists to support DetNet service connectivity using the existing 3GPP approach. This implies that only a homogeneous service area exists (e.g., all DetNet service areas or all non-DetNet service areas in a network). We assume that a DSA and non-DSA exist in the network and that the UE can be aware of the DSA or non-DSA through only the initial registration request procedure in the existing 3GPP approach. Also, we assume that the UE moves from a non-DSA to a DSA in the network and initiates a PDU session setup request to obtain a PDU session connectivity for DetNet service in the simulation scenario.

The latency of DetNet data transmission in a DetNet service scenario in which the UE moves from a non-DSA to a DSA is shown in Figure 6. In this case, according to the current 3GPP 5GS, the UE cannot transmit DetNet data/signaling to obtain the DetNet service because it was not aware that the UE is presently in the DSA. The UE can be aware that the UE is now in the DSA when it performs an initial registration request procedure by allowing the registration update timer to expire (T3512 [13]). Thus, the UE must wait to perform the initial registration request procedure using the network. Upon the completion of the initial registration request procedure, the UE becomes aware of its position in the DSA and initiates DetNet data transmission. The network provides a registration update timer for the UE during the registration request.

Figure 6. Latency for DetNet data transmission in a DetNet service scenario.

However, in the NDF scheme, the UE performs a registration request for mobility updates in a new TA (DSA) and is aware that the UE presently resides in the DSA because the UE has DSA information for DetNet service areas in advance. Therefore, the UE can transmit DetNet data/signals to obtain the DetNet service immediately. As shown in Figure 6, T3512 was set to 10, 15, 20, and 30 min. When T3512 was set to 10 min, the latency of NDF was 36.75 ms whereas the latency of the 3GPP approach was 340.75 ms. The latency of the 3GPP approach was worse when the registration update timer ran for a long time. We can see NDF outperformed the existing 3GPP approach in this case.

5. Conclusions

This study proposed a novel DetNet framework to support efficient IP-based DetNet data transmission in a 3GPP 5GS while satisfying the QoS requirements. In the proposed framework, four functionalities were implemented: IP PDU session-type support, UAC support for DetNet traffic, NAS-level congestion control support for urgent DetNet traffic transmission, and service connectivity support for DetNet traffic. Through simulations in a 5G standard environment, we observed that our framework design outperformed existing 3GPP schemes by a large margin in terms of the latency of DetNet data transmission. By eliminating unnecessary access and signaling attempts at an early stage, the proposed UAC extension reduces signaling redundancy and network burden while maintaining full compatibility with existing 3GPP procedures. Considering the deterministic networking of 3GPP 5G, we believe that the proposed DetNet framework can serve as an essential approach for various IIoT services and applications. While this study focuses on standard-compliant procedural enhancements, future work may include large-scale system-level evaluations and implementation-based validation to further assess deployment aspects.