PaperlayerView exact revision on arXiv

Source-linked AI summary

SESO-ISAC: Service-Aware End-to-End Sensing Orchestration for 6G ISAC

Youbin Jeon, Laeyoung Kim, Myungjune Youn, Sangheon Pack

arXiv:2609.06089v1cs.NI

TL;DR

ISAC services need sensing operations that extend beyond connectivity to measurement, processing, and result delivery, but existing work has not sufficiently composed interdependent decisions into complete operations. SESO-ISAC jointly maps service requests to end-to-end configurations and evaluates them against QoS requirements and execution context. Two case studies illustrate that multi-dimensional preferences can differ from single-dimension choices and can change as context changes.

  • Problem

    Existing work has not sufficiently composed interdependent sensing decisions into complete, executable end-to-end operations for requests with service-specific QoS requirements.

    Source: §I · p. 1

  • Method

    SESO-ISAC jointly composes end-to-end sensing configurations and evaluates feasible candidates across applicable QoS dimensions under the sensing execution context.

    Source: §I · p. 1, B. SESO-ISAC Procedure · p. 3

  • Results

    The case studies show that a candidate preferred across applicable QoS dimensions may differ from one favored by a single dimension, and context change can make another candidate preferred.

    Source: A. Case 1: factory robot collision… · pp. 5–6, B. Case 2: UAV flight trajectory… · p. 6

  • Takeaways & Limitations

    The preferred end-to-end sensing configuration depends on service requirements and execution context, so it may need re-evaluation as context changes.

    Source: §VI · p. 7

Abstract

from arXiv · show

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 re- evaluates 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.

I. INTRODUCTION

ISAC services require sensing execution and processing before results reach the consumer, so requests must be mapped to executable end-to-end configurations. SESO-ISAC addresses the gap in composing interdependent sensing decisions and evaluates configurations against service requirements as context changes.

I. INTRODUCTION

  • ISAC requests specify a service type and QoS requirements, which the network maps to a configuration using available SenEs, capabilities, and processing and reporting paths.Unlike conventional connectivity setup, sensing services execute and process sensing before delivering results to the consumer.Source: §I · p. 1
  • Existing work addresses radio-level or other partial decisions, leaving interdependent decisions insufficiently composed into complete, executable end-to-end sensing operations.The required orchestration jointly determines SenE participation, Tx/Rx roles, sensing mode, processing point, and reporting/exposure path.Source: §I · p. 1
  • SESO-ISAC jointly orchestrates end-to-end configuration elements, compares feasible candidates across applicable QoS dimensions, and re-evaluates them as execution context changes.The framework may retain or reselect an operation when structural or performance conditions change.Source: §I · p. 1

II. 6G ISAC SERVICE MODELS

The section introduces service profiles and sensing entities, modes, and configurations. Its profiles organize representative sensing requirements around the QoS dimensions most relevant to service objectives.

II. 6G ISAC SERVICE MODELS

  • The service-model section introduces sensing service profiles alongside sensing entities, modes, and configurations.The supplied profile discussion groups requirements by the QoS dimension most directly affecting a result's suitability for its service objective.Source: §II · p. 2, A. Sensing Service Profiles · p. 2

A. Sensing Service Profiles

  • Time-critical services emphasize latency, detection and tracking emphasize reliability, continuous monitoring emphasizes freshness, and detailed characterization emphasizes sensing quality.The stated indicators are latency; missed-detection and false-alarm performance; required refresh interval; and sensing accuracy and resolution, respectively.Source: A. Sensing Service Profiles · p. 2
  • The profiles are representative service-level abstractions, not an exhaustive taxonomy or a complete set of QoS requirements for every request.Table I summarizes profiles based on the characteristic QoS dimensions.Source: A. Sensing Service Profiles · p. 2

B. Sensing Entities, Modes and Configurations

The section describes the entities and sensing modes that can form an operation. SenE combinations and Tx/Rx roles vary with the service, target, requirements, and available entities, while each mode has distinct coordination and data-transfer considerations.

B. Sensing Entities, Modes and Configurations

  • The SSC requests and consumes results, the SenF coordinates sensing operations, and SenEs transmit or receive sensing signals as assigned per operation.An SSC may be a UE, application function, or network function; a SenE may be a UE or RAN node and support Tx, Rx, or both roles.Source: B. Sensing Entities, Modes and… · p. 2
  • Mono-static sensing assigns both Tx and Rx to one SenE, while bi-static sensing separates those roles and may improve observability under suitable geometry.Bi-static arrangements require inter-SenE coordination and, when processing is outside the receiving SenE, transfer of collected data to the processing point.Source: B. Sensing Entities, Modes and… · p. 2
  • Multi-static sensing uses multiple SenEs for multiple observations, but requires coordination, data collection and association, and increasingly important processing-point and transfer-path choices.The illustrated modes include mono-static, bi-static, and multi-static sensing.Source: B. Sensing Entities, Modes and… · p. 2, Figure 1 · p. 3

III. SESO-ISAC FRAMEWORK

SESO-ISAC maps a sensing request to a complete operation, from configuration through measurement and result delivery. For repeated services, it monitors execution context and performance so that configuration re-evaluation can be considered as conditions change.

III. SESO-ISAC FRAMEWORK

  • The framework's stated focus is composing, evaluating, selecting, and re-evaluating complete end-to-end sensing configurations.The section introduces the orchestration framework for these operations.Source: §III · p. 3

A. Sensing Lifecycle and Orchestration

  • The sensing lifecycle maps a request to a configuration, configures participating SenEs and paths, collects measurements, processes data into a result, and delivers it to the SSC.The request specifies service type, target or area, and QoS requirements; the configuration includes SenE participation, Tx/Rx roles, sensing mode, processing point, and reporting/exposure path.Source: A. Sensing Lifecycle and Orchestration · p. 3
  • For periodic or event-triggered services, SESO-ISAC monitors context and performance to determine whether re-evaluation is required.Structural context includes sensing geometry and participating SenEs; performance context includes processing and reporting conditions.Source: A. Sensing Lifecycle and Orchestration · p. 3

B. SESO-ISAC Procedure

SESO-ISAC composes and evaluates complete end-to-end sensing configurations against request-specific QoS requirements and the sensing execution context. It retains a selected configuration while it remains feasible and preferred, and re-evaluates it when context changes.

B. SESO-ISAC Procedure

  • The five-step procedure characterizes requirements, composes candidates, evaluates performance, filters infeasible candidates, and selects among those remaining.The SenF is assumed to coordinate the configuration decision.Source: B. SESO-ISAC Procedure · p. 3
  • Requirements select applicable latency, reliability, freshness, and sensing-quality dimensions, whose service-specific metrics define mandatory QoS boundaries.Applicable dimensions vary across sensing service requests.Source: B. SESO-ISAC Procedure · p. 3
  • Candidate composition jointly links SenE participation and Tx/Rx roles to sensing mode, processing point, and reporting/exposure path.Available processing options depend on where measurements are performed and data collected; reporting paths depend on processing point, SSC location, and path availability.Source: B. SESO-ISAC Procedure · pp. 3–4
  • Candidates are evaluated under the execution context, and their performance can vary as that context changes.Latency, freshness, reliability, or quality can also be affected by changes in processing or reporting conditions.Source: B. SESO-ISAC Procedure · p. 4
  • Any candidate violating a mandatory QoS boundary is excluded; if none remain feasible, the request cannot be satisfied in that context.Better performance in other dimensions cannot compensate for a boundary violation.Source: B. SESO-ISAC Procedure · p. 4
  • Among feasible candidates, SESO-ISAC selects the one with the minimum normalized distance across applicable QoS dimensions.Metrics are normalized to their mandatory boundaries, multiple metrics within a dimension are aggregated by RMS, and dimension scores are combined using a normalized Euclidean norm.Source: B. SESO-ISAC Procedure · pp. 4–5
  • When context changes, SESO-ISAC repeats composition after structural changes or performance evaluation after performance-context changes, retaining the current configuration only if it remains feasible and preferred.Otherwise, it selects a new configuration.Source: B. SESO-ISAC Procedure · p. 5

IV. CASE STUDIES

Two representative ISAC use cases illustrate SESO-ISAC's configuration selection under a given execution context and its re-evaluation in response to mobility.

IV. CASE STUDIES

  • The case studies cover factory robot collision avoidance and UAV flight trajectory tracking.Source: §IV · p. 5
  • Their mandatory QoS boundaries are derived from 3GPP sensing KPIs, and representative candidate performance values illustrate the procedure.Source: §IV · p. 5
  • The factory case demonstrates multidimensional selection in a given context, while the UAV case demonstrates mobility-driven re-evaluation.Source: §IV · p. 5

A. Case 1: factory robot collision avoidance

For factory robot collision avoidance, SESO-ISAC selects RC3 by comparing feasible configurations across the applicable QoS dimensions rather than latency alone.

A. Case 1: factory robot collision avoidance

  • RC1 uses UE mono-static sensing; RC2 and RC3 use RAN-UE bi-static sensing with UE-local and network-side processing, respectively.RC4 combines observations from multiple SenEs with network-side processing; RC1 and RC2 deliver locally, while RC3 and RC4 use network-to-UE delivery.Source: A. Case 1: factory robot collision… · p. 5
  • RC1's lowest latency comes with violations of multiple sensing-quality requirements, while RC4's highest sensing quality violates the latency requirement.Both are excluded, leaving RC2 and RC3 feasible.Source: A. Case 1: factory robot collision… · p. 5
  • A latency-only choice would favor RC2, but the multidimensional comparison selects RC3 for the requested service.Source: A. Case 1: factory robot collision… · pp. 5–6
  • 0.503 for RC3 versus 0.734 for RC2; SESO-ISAC selects RC3 based on the normalized Euclidean distances.RC2 has lower latency, whereas RC3 offers better reliability, freshness, and sensing-quality performance.Source: A. Case 1: factory robot collision… · pp. 5–6, Figure 3 · p. 6

B. Case 2: UAV flight trajectory tracking

For UAV trajectory tracking, the preferred feasible configuration changes as the execution context changes: UC2 is selected at t0, then UC3 at t1.

B. Case 2: UAV flight trajectory tracking

  • The service tracks a UAV's position and velocity along a predefined route using three candidates with different sensing and processing arrangements.UC1 is RAN mono-static with RAN-local processing; UC2 is RAN–RAN bi-static with processing at the receiving RAN; UC3 combines multiple SenE observations through network-side processing.Source: B. Case 2: UAV flight trajectory… · p. 6
  • At t0, UC1 is infeasible; among feasible UC2 and UC3, UC2 has lower latency while UC3 has better reliability, freshness, and sensing-quality performance.Their normalized distances are 0.475 for UC2 and 0.506 for UC3, so UC2 is selected under the current context.Source: B. Case 2: UAV flight trajectory… · p. 6
  • As the UAV moves, changes in sensing geometry and SenE availability may require re-evaluating SenE participation, Tx/Rx roles, and sensing modes.Source: B. Case 2: UAV flight trajectory… · p. 6
  • At t1, UC3 becomes preferred as its normalized distance falls to 0.489 while UC2's rises to 0.803, prompting a switch from UC2 to UC3.The re-evaluation reflects the changed sensing execution context.Source: B. Case 2: UAV flight trajectory… · p. 6

V. OPEN RESEARCH ISSUES

Open research issues concern coordination among sensing-lifecycle functions and integration of heterogeneous sensing data.

A. AI Agent and Data Framework Integration

B. Heterogeneous Sensing Data Integration

  • Heterogeneous SenE and non-3GPP sensing data may differ in measurement characteristics, timing, representation, and quality.Source: B. Heterogeneous Sensing Data… · p. 6
  • Joint processing and fusion require mechanisms to represent, align, and combine data across sensing sources.SESO-ISAC can compose configurations involving multiple SenEs, but heterogeneous data introduces these additional requirements.Source: B. Heterogeneous Sensing Data… · p. 6

C. Security and Privacy for Sensing Services

Sensing services raise privacy and authorization concerns because they may involve information about people and objects, and protections can depend on the selected configuration. The conclusion presents SESO-ISAC as composing and re-evaluating end-to-end configurations, with future work addressing heterogeneous data, QoS priorities, and performance uncertainty.

C. Security and Privacy for Sensing Services

VI. CONCLUSION

  • SESO-ISAC composes, evaluates, and selects complete end-to-end configurations using service requirements and execution context, then re-evaluates candidates as context changes.Source: §VI · p. 7
  • Two case studies illustrate multi-dimensional selection and mobility-driven re-evaluation; future work includes heterogeneous data, service-specific QoS priorities, and candidate-performance uncertainty.Source: §VI · p. 7
Loading 2609.06089v1…