1
SESO-ISAC: Service-Aware End-to-End Sensing Orchestration for 6G ISAC
arXiv:2609.06089v1 [cs.NI] 5 Sep 2026
Youbin Jeon, Laeyoung Kim, Myungjune Youn, and Sangheon Pack, Senior Member, IEEE
Abstract—Unlike conventional communication services, 6G Integrated Sensing and Communication (ISAC) services require complete end-to-end sensing operations, from data collection to processing, result generation, and exposure. In this article, we propose SESO-ISAC, a service-aware end-to-end sensing orchestration framework that maps a sensing service request to a complete sensing configuration under the sensing execution context. Rather than treating sensing configuration decisions independently, SESO-ISAC captures their interdependence across the end-to-end sensing operation, evaluates candidate configurations according to the applicable QoS requirements, and reevaluates the selected configuration as the sensing execution context changes. Through two representative case studies, we show that the preferred sensing configuration depends on the overall performance across the applicable QoS dimensions and can change during operation. Index Terms—6G ISAC, sensing orchestration, sensing service, service configuration, 3GPP.
I. I NTRODUCTION Integrated Sensing and Communication (ISAC) is considered a key technology for 6G. It extends the role of mobile networks from data delivery to environmental awareness by integrating sensing capability into communication systems [1]. The Third Generation Partnership Project (3GPP) first defined ISAC use cases and service requirements in Release 19 [2]. In Release 20, 3GPP SA WG2 has been studying the architecture and end-to-end procedures to support ISAC [3]. The 5GAdvanced ISAC architecture mainly focuses on aerial-object detection and tracking based on gNB-based sensing [4]. In contrast, the 6G ISAC architecture study considers broader sensing scenarios, including the participation of user equipment (UE) as well as radio access network (RAN) nodes in sensing operations [5]. This broader architectural scope is motivated by diverse 6G ISAC use cases, such as industrial automation, vulnerable pedestrian protection, and environmental monitoring, which are often associated with safety-critical or mission-critical services [6], [7]. For such services, the network needs to provide sensing results with the required latency, reliability, freshness, and sensing quality. In a conventional communication service, the network focuses on the connectivity configuration and path setup to deliver data from a source to a destination [8]. In contrast, an ISAC sensing service needs to perform sensing execution and processing before delivering the sensing results to the Y. Jeon, L. Kim, and M. Youn are with LG Electronics, Seoul, South Korea. E-mail: {youbin.jeon, laeyoung.kim, m.youn}@lge.com. S. Pack is with the School of Electrical Engineering, Korea University, Seoul 02841, South Korea. E-mail: [email protected] (Corresponding author: Youbin Jeon and Sangheon Pack.)
sensing service consumer (SSC). A sensing service request specifies the sensing service type and quality of service (QoS) requirements requested by the SSC. The network then needs to map the request to an executable end-to-end sensing configuration by considering the available sensing entities (SenEs), their capabilities, and the available processing and reporting paths. In the literature, existing work has addressed individual aspects of this request-to-configuration mapping problem. Existing ISAC studies have mainly focused on radio-level problems, such as waveform design, beamforming, radio resource allocation, and sensing accuracy [9]–[11]. Recent studies have also investigated service-aware resource allocation and sensingtopology switching with processing architectures [12], [13]. These studies consider only a subset of the decisions required to form an end-to-end sensing configuration. Meanwhile, 3GPP SA2 has been discussing functional entities and endto-end procedures for ISAC. However, existing work has not sufficiently addressed how interdependent sensing decisions can be composed into complete and executable end-to-end sensing operations. This mapping is particularly challenging because individual configuration decisions are tightly coupled. Therefore, satisfying diverse service requirements requires holistic and fine-grained sensing orchestration that jointly determines SenE participation, Tx/Rx roles, sensing mode, processing point, and reporting/exposure path across the entire sensing lifecycle. To address this problem, we propose SESO-ISAC, a serviceaware end-to-end sensing orchestration framework for ISAC. The main contributions are summarized as follows: 1) SESOISAC defines an end-to-end sensing lifecycle and jointly orchestrates SenE participation, Tx/Rx role assignment, sensing mode, processing point, and reporting/exposure path to form a complete end-to-end configuration; 2) our case studies illustrate a multi-dimensional configuration selection method that filters candidates against mandatory QoS boundaries and compares the feasible candidates across applicable QoS dimensions; and 3) SESO-ISAC supports re-evaluation in response to structural and performance changes, enabling the end-to-end sensing operation to be retained or reselected as the execution context changes. The remainder of this article first introduces 6G ISAC service models, including sensing service profiles, sensing entities, modes, and configurations. It then presents the SESOISAC framework and applies it to two representative sensing services. Finally, we discuss open research issues and conclude the article.
2
TABLE I: Sensing requirement profiles for 3GPP SA1 ISAC use cases. Sensing profile
Latency-critical interaction
Representative use cases ▷ AMR collision avoidance in smart factories ▷ Enhanced XR user navigation ▷ Safety assistance for vulnerable pedestrians
▷ UAV flight trajectory tracking Reliability-critical ▷ AGV detection and tracking in factories detection and tracking ▷ UAV intrusion detection
Characteristic QoS dimension
Defining criterion
▷ Sensing latency
▷ Result availability within the service deadline
▷ Sensing reliability
▷ Missed-detection and false-alarm requirements
Freshness-sensitive continuous sensing
▷ Real-time traffic flow monitoring ▷ Rainfall and flooding monitoring ▷ Health and sports monitoring
▷ Sensing freshness
▷ Sensing-result updates at the service-required refresh interval
Quality-intensive sensing
▷ High-resolution topographical mapping ▷ Environmental object reconstruction ▷ Gesture recognition in industrial environments
▷ Sensing quality
▷ Task-usable sensing accuracy and resolution
II. 6G ISAC S ERVICE M ODELS In this section, we describe 1) sensing service profiles and 2) sensing entities, modes, and configurations. A. Sensing Service Profiles 3GPP SA1 ISAC use cases exhibit heterogeneous sensing requirements [2], [14]. From a service-level perspective, these requirements can be grouped according to the QoS dimension that most directly affects the suitability of a sensing result for its intended service objective. For time-critical interaction services, delayed sensing results can reduce their usefulness for the intended service action, making sensing latency a key requirement. For detection and tracking services, service continuity depends on reliable target observation over time, making missed-detection and false-alarm performance the principal indicators of sensing reliability. For continuous monitoring services, service usability depends on sensingresult updates at a rate sufficient to reflect the current state of the monitored target or environment, making the servicerequired refresh interval the primary freshness criterion. For sensing tasks requiring detailed characterization of a target or environment, service usability depends on the fidelity of the generated sensing result, making sensing accuracy and resolution the defining quality requirements. Table I summarizes representative sensing requirement profiles based on these characteristic QoS dimensions. These profiles are not intended to be an exhaustive taxonomy of all 3GPP SA1 and 6G ISAC use cases, nor do they prescribe the complete set of QoS requirements for a sensing request. Instead, they provide a service-level abstraction of representative sensing requirement characteristics. B. Sensing Entities, Modes and Configurations As shown in Fig. 1(a), from a 3GPP SA2 perspective, an ISAC sensing service is supported through interactions among SSC, sensing function (SenF), and SenEs. The SSC requests a sensing service and consumes the provided sensing result.
The SSC can be a UE, an application function (AF), or a network function (NF). In the current 3GPP SA2 work, the SenF is considered a core network function that handles the sensing service request and coordinates the functions involved in sensing operation configuration, sensing-data processing, result reporting, and exposure. A SenE is an entity that transmits or receives sensing signals, which can be a UE or a RAN node. Each SenE may support a sensing transmitter (Tx) role, a sensing receiver (Rx) role, or both roles. The sensing role is assigned per sensing operation. Even for the same sensing service type, different SenE combinations and Tx/Rx role assignments may be selected depending on the SSC type, sensing target or area, sensing requirements, and the capabilities and locations of available SenEs.
Figure 1(b)–(d) illustrate mono-static, bi-static, and multistatic sensing modes. In mono-static sensing (see Fig. 1(b)), one SenE performs both Tx and Rx roles. This reduces inter-SenE coordination and sensing-data transfer, while the achievable sensing performance depends on the capability and location of that SenE. In bi-static sensing (see Fig. 1(c)), different SenEs perform the Tx and Rx roles. Thus, UE–UE, UE–RAN, RAN–UE, and RAN–RAN configurations can be considered, where the first and second terms denote the SenETx and the SenE-Rx. Separating the Tx and Rx locations can improve target observability under suitable sensing geometry but requires inter-SenE coordination. When sensing-data processing is performed outside the receiving SenE, the collected sensing data also need to be transferred to the selected processing point. In multi-static sensing (see Fig. 1(d)), multiple SenEs participate as Tx and/or Rx in a sensing operation. The 1:N, N:1, and N:N configurations can provide multiple observations of the same sensing target or area, but require coordination among participating SenEs as well as sensingdata collection and association. As the number of participating SenEs increases, the selection of the processing point and the associated sensing-data transfer paths becomes increasingly important.
3
Fig. 1: 6G ISAC architecture and sensing modes: (a) 6G ISAC architecture; (b) mono-static sensing; (c) bi-static sensing; (d) multi-static sensing.
III. SESO-ISAC F RAMEWORK This section presents SESO-ISAC for composing, evaluating, selecting, and re-evaluating complete end-to-end sensing configurations. A. Sensing Lifecycle and Orchestration Figure 2 shows the end-to-end sensing lifecycle. The SSC sends a sensing request that specifies the sensing service type, sensing target or area, and QoS requirements (see (A) in Fig. 2). The SESO-ISAC framework selects an end-toend sensing configuration considering the sensing execution context (see (B)–(C) in Fig. 2). Based on the selected configuration, the network configures the participating SenEs, Tx/Rx roles, sensing mode, processing point, and reporting/exposure path (see (D) in Fig. 2). The selected SenEs perform sensing measurements and collect sensing data according to the assigned Tx/Rx roles (see (E)-⃝ 1 in Fig. 2). The collected data are processed at the configured processing point to generate a sensing result (see (E)-⃝ 2 in Fig. 2). After that, the sensing result is delivered to the SSC through the configured reporting/exposure path (see (E)-⃝ 3 in Fig. 2). For periodic or event-triggered services, sensing execution and result reporting are repeated. During repeated sensing operations, the sensing execution context can change. Specifically, the structural context captures the sensing geometry and participating SenEs, which can be affected by mobility and SenE availability. The performance context captures processing and reporting conditions that can affect the performance of the current configuration. Therefore, SESO-ISAC monitors the sensing performance and execution context (see (E)-⃝ 4 in Fig. 2) to determine whether a configuration re-evaluation is required.
B. SESO-ISAC Procedure Figure 2(C) shows the SESO-ISAC framework for determining an end-to-end sensing configuration based on the sensing request and sensing execution context. In this article, the SenF is assumed to coordinate the configuration decision. SESOISAC is designed around three key considerations: interdependence among end-to-end configuration elements, multidimensional QoS evaluation, and configuration re-evaluation under a changing sensing execution context. To address these considerations, SESO-ISAC consists of five steps, as shown in Fig. 2(C): 1) service requirement characterization, 2) end-toend candidate composition, 3) candidate performance evaluation, 4) candidate feasibility filtering, and 5) multi-dimensional configuration selection. In the first step (see (C)-⃝ 1 in Fig. 2), SESO-ISAC characterizes the sensing request to identify the applicable QoS dimensions and their requirement boundaries. The applicable dimensions are selected from latency, reliability, freshness, and sensing quality. The set of applicable dimensions varies across sensing service requests according to the QoS requirements specified in each request. Each dimension is represented by one or more service-specific metrics, whose specified requirements define the mandatory QoS boundaries used for subsequent candidate evaluation. In the second step (see (C)-⃝ 2 in Fig. 2), SESO-ISAC composes end-to-end candidate configurations based on the sensing service context and sensing execution context. SESOISAC identifies available SenEs and derives possible Tx/Rx role assignments and sensing modes based on the SenE types and sensing role capabilities. Each SenE–role–mode combination determines where sensing measurements are performed and where sensing data are collected, thereby constraining the
4
Fig. 2: SESO-ISAC Orchestration.
available processing options. SESO-ISAC identifies available processing options based on their processing performance. Available reporting/exposure paths are determined based on the processing point, SSC location, and path availability. These dependencies are considered jointly so that each candidate forms a complete end-to-end configuration consisting of SenE participation, Tx/Rx role assignment, sensing mode, processing point, and reporting/exposure path. In the third step (see (C)-⃝ 3 in Fig. 2), SESO-ISAC evaluates the performance of each candidate under the sensing execution context. Each candidate is characterized by the applicable elements of p = [L, R, F, Q], where L and F denote sensing latency and freshness, respectively, while R and Q contain the applicable reliability metrics (e.g., misseddetection and false-alarm probabilities) and sensing-quality metrics (e.g., positioning/velocity accuracy and sensing resolution). The candidate performance can vary as the execution context changes over time. For example, the mobility of a SenE or sensing target can alter sensing geometry, while
changes in processing or reporting conditions can affect latency, freshness, reliability, or quality. In the fourth step (see (C)-⃝ 4 in Fig. 2), SESO-ISAC filters the candidates against the mandatory QoS boundaries. A candidate that violates any mandatory QoS boundary is excluded because superior performance in other dimensions cannot compensate for the violation. Candidates satisfying all mandatory QoS boundaries proceed to the final selection step. If no feasible candidate remains, the sensing service request cannot be satisfied under the sensing execution context. In the fifth step (see (C)-⃝ 5 in Fig. 2), SESO-ISAC compares the remaining feasible candidates across the applicable QoS dimensions. Each performance metric is normalized with respect to its mandatory QoS boundary, such that the boundary is mapped to one and better performance approaches zero. When a QoS dimension contains multiple metrics, their normalized values are aggregated using the root mean square (RMS) to obtain a single dimension score. SESOISAC then computes the Euclidean norm of the applicable
5
TABLE II: Performance comparison and configuration selection for (a) factory robot collision avoidance and (b) UAV flight trajectory tracking. Sensing latency [ms]
Positioning error [m]
Velocity error [m/s]
Range resolution [m]
False alarm [%]
Refresh interval [s]
Feasible
Normalized distance
3GPP requirement RC1
< 500
≤ 1.0
≤ 1.0
≤ 1.0
≤ 5.0
≤ 0.05
–
–
80
1.20
1.10
1.15
4.0
0.050
✗ No
–
RC2
150
0.75
0.80
0.80
4.0
0.045
✓ Yes
0.734
RC3
230
0.45
0.55
0.55
2.5
0.0265
✓ Yes
0.503
RC4
520
0.20
0.20
0.25
1.0
0.020
✗ No
–
Configuration
(a) Sensing latency [ms]
Positioning error [m]
Velocity error [m/s]
Missed detection [%]
False alarm [%]
Refresh interval [s]
Feasible
Normalized distance
3GPP requirement U C1 (t0 )
≤ 1000
≤ 2.0
≤ 2.0
≤ 5.0
≤ 5.0
≤ 1.0
–
–
150
2.50
2.20
6.0
4.0
1.10
✗ No
–
U C2 (t0 )
220
1.00
1.10
2.5
2.75
0.55
✓ Yes
0.475
U C3 (t0 )
900
0.50
0.60
1.25
1.50
0.25
✓ Yes
0.506
U C1 (t1 )
170
2.80
2.60
7.0
4.5
1.20
✗ No
–
U C2 (t1 )
300
1.80
1.70
4.5
4.0
1.00
✓ Yes
0.803
U C3 (t1 )
900
0.40
0.40
1.0
1.0
0.26
✓ Yes
0.489
Configuration
(b)
QoS-dimension scores and normalizes it by the square root of the number of applicable dimensions. The candidate with the minimum normalized distance is selected. The final selection determines the end-to-end sensing configuration (see (D) in Fig. 2), which is then used for executing the sensing operation (see (E) in Fig. 2). During operation, SESO-ISAC monitors sensing performance and the execution context to determine whether re-evaluation is required. If a structural-context change affects candidate composition, SESO-ISAC repeats the procedure from the candidate composition step (see (C)-⃝ 2 in Fig. 2). If a performance-context change affects candidate performance, SESO-ISAC repeats the procedure from the performance evaluation step (see (C)-⃝ 3 in Fig. 2). The current configuration is retained when it remains feasible and preferred. Otherwise, SESO-ISAC selects a new configuration.
IV. C ASE S TUDIES In this section, we apply SESO-ISAC to two representative ISAC use cases: 1) factory robot collision avoidance and 2) UAV flight trajectory tracking. For these case studies, the mandatory QoS boundaries are derived from 3GPP sensing KPIs [15]. Representative candidate performance values are used to illustrate the SESO-ISAC procedure. The first case illustrates multi-dimensional configuration selection under a given execution context, while the second case illustrates configuration re-evaluation in response to mobility.
A. Case 1: factory robot collision avoidance We consider a continuous sensing service in which a moving autonomous mobile robot (AMR) acts as the SSC and detects workers or obstacles to avoid collisions. In this use case, the limited sensing range of a single AMR and the blockage caused by factory equipment are identified as sensing challenges [15]. SESO-ISAC considers four candidate configurations: 1) RC1 uses UE mono-static sensing with local processing; 2) RC2 uses RAN-UE bi-static sensing with UElocal processing; 3) RC3 uses the same sensing mode as RC2 with network-side processing; and 4) RC4 uses observations from multiple SenEs with network-side processing. For result delivery, RC1 and RC2 use local delivery, while RC3 and RC4 use network-to-UE delivery. Table II(a) compares the illustrative performance of the four candidate configurations across the applicable QoS dimensions. RC1 provides the lowest latency but violates multiple sensing quality requirements, while RC4 provides the highest sensing quality but violates the latency requirement. Thus, both are excluded, leaving RC2 and RC3 as feasible candidates. RC2 has lower latency, whereas RC3 provides better reliability, freshness, and sensing-quality performance. If the selection were based only on sensing latency, RC2 would be preferred over RC3 . However, SESO-ISAC evaluates the feasible candidates across all applicable QoS dimensions of the requested sensing service. Figure 3(a) compares the feasible candidates after normalizing each performance metric and aggregating them within the corresponding QoS dimensions. The normalized Euclidean distances are 0.734 for RC2 and 0.503
6
(a)
(b)
(c)
Fig. 3: Normalized performance comparison of feasible sensing configurations: (a) factory robot collision avoidance; (b) UAV flight trajectory tracking at t0 ; (c) UAV flight trajectory tracking at t1 .
for RC3 , so SESO-ISAC selects RC3 . This case illustrates that a configuration favored by a single QoS dimension is not necessarily preferred when complete end-to-end sensing configurations are evaluated across multiple applicable QoS dimensions.
B. Case 2: UAV flight trajectory tracking We consider a sensing service in which a network-side SSC continuously tracks the position and velocity of a UAV moving along a predefined flight route. In this use case, the sensing operation may change as the UAV moves to maintain sensing service continuity [15]. SESO-ISAC considers three candidate configurations: 1) U C1 uses RAN mono-static sensing with RAN-local processing; 2) U C2 uses RAN–RAN bi-static sensing with local processing at the receiving RAN; and 3) U C3 combines observations from multiple SenEs through networkside processing. The reporting path is RAN-to-network for U C1 and U C2 and network-local for U C3 . At the initial time t0 , Table II(b) shows that U C1 is infeasible, leaving U C2 and U C3 as feasible candidates. U C2 has lower latency, whereas U C3 provides better reliability, freshness, and sensing-quality performance. Figure 3(b) compares the feasible candidates after normalizing each performance metric and aggregating them within the corresponding QoS dimensions. The resulting normalized distances are 0.475 for U C2 and 0.506 for U C3 . Accordingly, U C2 is selected under the current sensing execution context. As the UAV moves, changes in sensing geometry and SenE availability may require re-evaluation of SenE participation, Tx/Rx role assignments, and sensing modes. At time t1 , SESO-ISAC re-evaluates the candidates under the changed sensing execution context. U C2 remains feasible, but its normalized distance increases to 0.803, while that of U C3 decreases to 0.489. As shown in Fig. 3(c), U C3 becomes the preferred candidate, and SESO-ISAC changes the configuration from U C2 to U C3 . This case illustrates that a context change can alter the relative performance of feasible
configurations, triggering re-evaluation and configuration reselection when another candidate becomes preferred. V. O PEN R ESEARCH I SSUES In this section, we discuss open research issues for serviceaware sensing operation orchestration in 6G ISAC. A. AI Agent and Data Framework Integration The 6G sensing lifecycle may involve the SenF, an artificial intelligence (AI) agent, and the 6G data framework. The AI agent may interpret intent-based sensing requests and coordinate sensing with other 6G services, while the data framework may support sensing-data and result management. When these functions jointly support a sensing service, orchestration responsibility and coordination of service states and QoS remain unclear. Future studies should investigate integrated orchestration mechanisms across the SenF, AI agent, and data framework. B. Heterogeneous Sensing Data Integration 6G ISAC may use sensing data generated by heterogeneous SenEs and potentially non-3GPP sensing sources. Such sensing data may differ in measurement characteristics, timing, data representation, and quality. Although SESO-ISAC can compose end-to-end configurations involving multiple SenEs, the use of heterogeneous sensing data introduces additional requirements for joint processing and fusion. Future studies should investigate mechanisms for representing, aligning, and combining heterogeneous sensing data across different sensing sources. C. Security and Privacy for Sensing Services Sensing services may involve information about the locations, movements, and behaviors of people and objects, necessitating security and privacy protection throughout the sensing lifecycle. Service authorization, UE authorization, and protection of sensing-data paths may depend on the selected
7
sensing configuration and processing point. Future extensions of SESO-ISAC should therefore incorporate authorization and privacy policies as constraints for candidate generation and feasibility evaluation.
LAEYOUNG KIM received the Ph.D. in computer science from Yonsei University, Seoul, Republic of Korea, and is working for LG Electronics. Her work focuses on system architecture standardization, mainly covered by 3GPP SA WG2 and SA. Contact her at [email protected].
VI. C ONCLUSION This article proposed SESO-ISAC for service-aware sensing operation orchestration in 6G ISAC. SESO-ISAC composes, evaluates, and selects complete end-to-end sensing configurations based on sensing service requirements and the sensing execution context, and re-evaluates candidate configurations as the context changes. Through two case studies, we illustrated multi-dimensional configuration selection and mobility-driven re-evaluation. Future work will investigate adaptive configuration selection that accounts for heterogeneous sensing data, service-specific QoS priorities, and uncertainty in candidate performance. R EFERENCES [1] X. Luo et al., “ISAC—A survey on its layered architecture, technologies, standardizations, prototypes and testbeds,” IEEE Communications Surveys & Tutorials, vol. 28, pp. 485–526, Apr. 2025. [2] 3GPP SA WG1 TS 22.137 Release 19, “Integrated Sensing and Communication,” version 19.1.0, Apr. 2024. [3] X. Lin, “A Tale of Two Mobile Generations: 5G-Advanced and 6G in 3GPP Release 20,” IEEE Communications Standards Magazine, Early Access. [4] 3GPP SA WG2 TS 23.137 Release 20, “Integrated Sensing and Communication; Stage 2,” version 0.3.0, June 2026. [5] 3GPP SA WG2 TR 23.801-01 Release 20, “Study on Architecture for 6G System; Stage 2,” version 0.8.0, July 2026. [6] J. Lee et al., “Operator’s Perspective on 6G ISAC: From Standards to Services,” IEEE Communications Standards Magazine, Early Access. [7] M. Nabati et al., “Opportunities and Challenges of Native Sensing in 6G: A Survey on Research and Standardization,” IEEE Internet of Things Journal, vol. 12, no. 24, pp. 52042–52066, Dec. 2025. [8] 3GPP SA WG2 TS 23.501 Release 20, “System architecture for the 5G System (5GS),” version 20.2.0, June 2026. [9] Z. Liu et al., “Performance Trade-Off for Ultra-Reliable and LowLatency Service in Multi-Functional ISAC Network,” IEEE Transactions on Network Science and Engineering, vol. 13, pp. 7429–7447, Mar. 2026. [10] Y. Ge et al., “Sensing with Mobile Devices through Radio SLAM: Models, Methods, Opportunities, and Challenges,” IEEE Communications Magazine, vol. 63, no. 12, pp. 80–87, Nov. 2025. [11] Z. Li et al., “Chirp Delay-Doppler Domain Modulation: A New Paradigm of Integrated Sensing and Communication for Autonomous Vehicles,” IEEE Network, vol. 39, no. 6, pp. 119–127, Mar. 2025. [12] F. Dong et al., “Sensing as a Service in 6G Perceptive Mobile Networks: Architecture, Advances, and the Road Ahead,” IEEE Network, vol. 38, no. 2, pp. 87–96, Mar. 2024. [13] Y. Lyazidi et al., “ISAC Architecture for 6G Cellular Networks With Sensing Topology Switching,” IEEE Communications Standards Magazine, vol. 10, no. 2, pp. 365–371, June 2026. [14] 3GPP SA WG1 TR 22.870 Release 20, “Study on 6G Use Cases and Service Requirements,” version 20.0.0, Mar. 2026. [15] 3GPP SA WG1 TR 22.837 Release 19, “Study on Integrated Sensing and Communication,” version 19.4.0, June 2024.
YOUBIN JEON received the B.S. degree from Myongji University, Korea, in 2015, and the Ph.D. degree from Korea University, Korea, in 2025. In 2019, she worked as a software engineer at Shinhan DS. She is currently with the 6G Communication Standard Task at LG Electronics. Her research interests include 5G/6G integrated sensing and communication (ISAC), mobile core networks, network automation, and AI-enabled networking. Contact her at [email protected].
MYUNGJUNE YOUN received the Ph.D. in Electrical and Electonic Engineering from Yonsei University, Seoul, Republic of Korea, and is working for LG Electronics. His work focuses on system architecture standardization, mainly covered by 3GPP SA WG2. Contact him at [email protected].
SANGHEON PACK received the B.S. and Ph.D. degrees from Seoul National University, Korea, in 2000 and 2005, respectively. In 2007, he joined the faculty of Korea University, Korea. He is currently a professor at the School of Electrical Engineering. His research interests include network softwarization and mobile edge computing. Contact him at [email protected].