ETSI GR ISC 003 V1.1.1 (2026-02)
Integrated Sensing And Communications (ISAC); System and RAN Architectures
Integrated Sensing And Communications (ISAC); System and RAN Architectures
DGR/ISC-003
General Information
- Status
- Not Published
- Technical Committee
- ISAC - Integrated Sensing And Communications
- Current Stage
- 12 - Citation in the OJ (auto-insert)
- Due Date
- 04-Mar-2026
- Completion Date
- 24-Feb-2026
Frequently Asked Questions
ETSI GR ISC 003 V1.1.1 (2026-02) is a standard published by the European Telecommunications Standards Institute (ETSI). Its full title is "Integrated Sensing And Communications (ISAC); System and RAN Architectures". This standard covers: DGR/ISC-003
DGR/ISC-003
ETSI GR ISC 003 V1.1.1 (2026-02) is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
GROUP REPORT
Integrated Sensing And Communications (ISAC);
System and RAN Architectures
Disclaimer
The present document has been produced and approved by the Integrated Sensing And Communications (ISAC) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.
2 ETSI GR ISC 003 V1.1.1 (2026-02)
Reference
DGR/ISC-003
Keywords
ISAC, RAN architecture, system architecture
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871
Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.
Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2026.
All rights reserved.
ETSI
3 ETSI GR ISC 003 V1.1.1 (2026-02)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Executive summary . 5
Introduction . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Identified sensing modes, integration levels and system terminology . 9
4.0 Introduction . 9
4.1 Sensing modes . 9
4.2 Integration levels . 10
4.3 System terminology for sensing-enabled 6G systems . 10
5 System architectures . 11
5.0 System reference model . 11
5.1 Identified considerations and challenges . 13
5.1.1 Sensing Function (SF) considerations . 13
5.1.2 Sensing service request and configuration . 14
5.1.3 Sensing input data request definition . 14
5.1.4 Sensing input data response . 15
5.1.5 Considerations and challenges on network payload related to sensing data . 15
5.1.6 Sensing results exposure and transport . 16
5.1.7 Charging and incentives . 16
5.1.8 Disaggregation of sensing control and processing . 17
5.1.9 Considerations for mobility of sensing entities . 17
5.1.10 Considerations for managing sensing entities in an ISAC system . 17
5.1.11 CN-RAN interaction for sensing task control . 17
5.1.12 Considerations and challenges on multi-operator network sharing for sensing . 18
5.2 Potential approaches . 18
5.2.1 Sensing function . 18
5.2.2 Approaches for sensing service request and configuration . 20
5.2.3 Approaches for sensing input data request . 22
5.2.3.1 SIDP(s) . 22 ®
5.2.3.2 Non-MNO controlled Wi-Fi enabled 3-SIDP(s) . 23
5.2.4 Approaches for sensing input data response . 24
5.2.5 Approaches for efficient sensing data selection, reporting and collection . 25
5.2.5.1 Use of multiple phases . 25
5.2.5.2 Efficient sensing data reporting and selection . 27
5.2.5.3 Efficient sensing task management . 29
5.2.5.4 Efficient SIDP selection using sensing measurements utilization score . 34
5.2.6 Approaches for sensing results exposure and transport . 35
5.2.7 Approaches for charging and incentives . 37
5.2.8 Approaches for disaggregation of sensing control and processing . 38
5.2.9 Approaches for UE centric monostatic sensing . 39
5.2.10 Approaches for mobile sensing entity discovery and selection . 40
6 Radio Access Network (RAN) . 42
6.1 RAN architecture and related network interfaces . 42
ETSI
4 ETSI GR ISC 003 V1.1.1 (2026-02)
6.1.1 Identified considerations and challenges . 42
6.1.1.1 Considerations for ISAC RAN architecture and additional RAN functionalities . 42
6.1.2 Potential approaches . 42
6.1.2.1 Approaches for ISAC RAN architecture and additional RAN functionalities . 42
6.2 Lower layer RAN (PHY, MAC and RRC) . 44
6.2.1 Identified considerations and challenges . 44
6.2.1.1 Interference considerations . 44
6.2.1.2 Power control considerations . 47
6.2.1.3 Sensing signal design considerations . 47
6.2.1.4 Cooperative scheduling and resource allocation . 48
6.2.2 Potential approaches . 48
6.2.2.1 Approaches for ISAC interference . 48
7 Conclusions and recommendations . 50
History . 52
ETSI
5 ETSI GR ISC 003 V1.1.1 (2026-02)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Integrated Sensing And
Communications (ISAC).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
The present document identifies considerations and challenges related to system architecture, RAN architecture and
lower layer RAN to support advanced ISAC use cases for a future 6G system. A total of 17 considerations and
challenges are identified and described in the present document.
In addition to the identified challenges, the present document also presents various potential approaches for the
identified considerations and challenges. These include various system and RAN architectural approaches, top level
procedures and signalling between entities, and also selected message definitions and formats.
Finally, the present document draws conclusions and formulates recommendations for further ISAC work on integration
of computing with ISAC and ISAC work on security, privacy, trustworthiness, and sustainability aspects. These
recommendations also relate to ISAC work items which may be approved at a later time for subsequent phases of this
ISG.
ETSI
6 ETSI GR ISC 003 V1.1.1 (2026-02)
Introduction
There is an increasing interest in ISAC around the world from a wide range of global research and industrial
communities. This includes worldwide Standardization Bodies, industrial stakeholder associations, academia, national
and regional funded cooperation projects and individual industrial companies. In this context, the present document
provides a study on system and RAN architectural challenges to support ISAC in future 6G systems.
ETSI
7 ETSI GR ISC 003 V1.1.1 (2026-02)
1 Scope
The present document studies and defines a System and RAN architectural framework for 6G ISAC. To this aim, the
focus is on identifying considerations and challenges, with related potential approaches in the following key areas:
• System architecture.
• RAN architecture.
• Lower layer RAN.
The goal is to support future ISAC use cases and in particular the identified 6G ISAC use cases in ETSI
GR ISC 001 [i.1] with their related sensing modes, integration levels and deployments.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] ETSI GR ISC 001 (V1.1.1): "Integrated Sensing And Communications (ISAC); Use Cases and
Deployment Scenarios".
[i.2] Report ITU-R M.2516-0 (11/2022): "Future technology trends of terrestrial International Mobile
Telecommunications systems towards 2030 and beyond", November 2022.
[i.3] ETSI TS 122 137 (V19.1.0): "5G; Integrated Sensing and Communication (3GPP TS 22.137
version 19.1.0 Release 19)".
[i.4] 3GPP TR 23.700-14: "Study on Integrated Sensing and Communication; Stage 2 (Release 20)".
[i.5] Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the
protection of natural persons with regard to the processing of personal data and on the free
movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation).
[i.6] ETSI GR ISC 004: "Integrated Sensing And Communications (ISAC); Security, Privacy,
Trustworthiness and Sustainability".
TM
[i.7] IEEE 802.11bf -2025: "IEEE Standard for Information Technology -- Telecommunications and
Information Exchange Between Systems Local and Metropolitan Area Networks -- Specific
Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications - Amendment 4: Enhancements for Wireless LAN Sensing".
[i.8] SP-250833: "Revised SID on Study on Stage 2 for Integrated Sensing and Communication".
[i.9] RP-251861: "New SID: Study on Integrated Sensing And Communication (ISAC) for NR".
[i.10] SP-241391: "New Study on 6G Use Cases and Service Requirements".
ETSI
8 ETSI GR ISC 003 V1.1.1 (2026-02)
[i.11] 3GPP TR 22.870: "Study on 6G Use Cases and Service Requirements; Stage 1".
[i.12] RP-251881: "New Study on 6G Radio".
[i.13] ETSI GR ISC 005: "Integrated Sensing And Communications (ISAC); Integration of Computing
with ISAC".
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
rd
3GPP 3 Generation Partnership Project
rd
3-SIDP 3 party Sensing Input Data Provider
rd
3-SSC 3 party Sensing Service Consumer
th
5G 5 Generation
5G NR 5G New Radio
5GA 5G Advanced
th
5GS 5 Generation System
th
6G 6 Generation
th
6GS 6 Generation System
AAA Authentication, Authorization and Accounting
AF Application Function
AI Artificial Intelligence
AN Access Node
AP Access Point
BS Base Station
CAPEX Capital Expenditure
CDR Charging Data Record
CEF Capability Exposure Function
CM Connection Management
CN Core Network
CPU Central Processing Unit
CSI Channel State Information
DL Downlink
DN Data Network
eMBB enhanced Mobile Broadband
GDPR General Data Protection Regulation
GPS Global Positioning System
GPU Graphics Processing Unit
HTTP Hypertext Transfer Protocol
ID Identifier
IDR Incentive Data Record
IMT International Mobile Telecommunications
ISC Integrated Sensing and Communications
KPI Key Performance Indicator
MAC Medium Access Control
ML Maximum Likelihood
ETSI
9 ETSI GR ISC 003 V1.1.1 (2026-02)
mMTC massive Machine Type Communication
MNO Mobile Network Operator
NEF Network Exposure Function
NF Network Function
NPN Non-Public Networks
PHY Physical
PNI-NPN Public Network-Integrated NPN
PoA Point of Attachment
QoS Quality of Service
RAD Range, Angle, Doppler
RAM Random Access Memory
RAN Radio Access Network
R-CPS Real time Cyber-Physical System
RF Radio Frequency
RRC Radio Resource Control
RS Reference Signal
RSU Road Side Unit
SA System Architecture
SAF Sensing Analytics Function
SBA Service-Based Architecture
SCF Sensing Control Function
SCIM Sensing Charging and Incentive Management
SDSF Sensing Data Storage Function
SEF Sensing Exposure Function
SF Sensing Function
SGW Sensing Gateway
SIDP Sensing Input Data Provider
SL Sidelink
SMUS Sensing Measurements Utilization Score
SPA Sensing Paging Area
SSC Sensing Service Consumer
SSP Sensing Service Producer
STID Sensing Task Identifier
STM Sensing Task Management
TDD Time Division Duplex
TR Technical Report
TRP Transmission/Receive Point
TSSA Target Sensing Service Area
UAV Unmanned Aerial Vehicle
UE User Equipment
UL Uplink
URLLC Ultra Reliable Low Latency Communications
4 Identified sensing modes, integration levels and
system terminology
4.0 Introduction
Definitions of sensing modes, integration levels and system terminology build on definitions already agreed in ETSI
GR ISC 001 [i.1]. Sensing modes and integration level definitions are repeated here again, to facilitate reading of the
present document in a standalone way.
4.1 Sensing modes
The term "sensing mode" describes the topology consisting of one or more sensing nodes and their role. Sensing nodes
may be User Equipment's (UEs) or Transmit/Receive Points (TRPs) that may act as a sensing transmitter and/or sensing
receiver.
ETSI
10 ETSI GR ISC 003 V1.1.1 (2026-02)
There are six unique sensing modes:
• TRP-TRP bistatic;
• TRP monostatic;
• TRP-UE bistatic;
• UE-TRP bistatic;
• UE-UE bistatic; and
• UE monostatic.
These basic modes may be extended to multi-static variants by adding additional UE(s) or TRP(s) to any of the six basic
modes as sensing transmitter(s) and/or receiver(s).
4.2 Integration levels
The term "integration level" describes how communication and sensing functionalities are combined in one system. It is
commonly categorized in multiple levels, reaching from loose integration to tight integration with variable granularity
[i.2].
Loose integration refers to the case where the two functionalities are realized rather on a standalone basis with some
level of coordination, e.g. on application level, or by combining dedicated sensors and communication hardware on a
site.
Tight integration refers to a joint waveform or joint signal design that is suitable for both tasks.
Intermediate integration may refer to anything in between.
4.3 System terminology for sensing-enabled 6G systems
For the purposes of the present document, the following terms apply:
• Sensing signal is a transmitted signal from a sensing transmitter for the purpose of sensing. The signal can be
6G or non-6G.
• A sensing transmitter is a 6G or non-6G entity that transmits a sensing signal.
• A sensing receiver is a 6G or non-6G entity that receives a sensing signal and produces sensing data. A
sensing receiver can be co-located with a sensing transmitter.
• Sensing data is the 6G or non-6G data produced for sensing purposes.
• A sensing entity is an entity referring to a sensing transmitter or to a sensing receiver.
• A sensing service is a feature of the 6GS that is offered to service consumers. A sensing service provides
sensing results based on communicated requirements and KPIs.
• Sensing function: indicates the logical function, which is involved to support a Sensing Service.
NOTE 1: The sensing function cannot be a sensing entity.
• A sensing task is communicated from a sensing function to sensing entities and functions and consists of
configuration information of the required sensing transmitter(s) and sensing receiver(s) (if applicable), the
collection of sensing data, the processing of the sensing data and the exposure of the sensing results. Each
sensing task fulfils a Sensing Service request.
• A Target Sensing Service Area (TSSA) is defined as a cartesian location area that needs to be sensed by
deriving characteristics of the environment and/or objects within the environment with certain sensing service
quality from the impacted (e.g. reflected, refracted, diffracted) 6G or non-6G sensing signals. This includes
both indoor and outdoor environments.
ETSI
11 ETSI GR ISC 003 V1.1.1 (2026-02)
• The sensing results are processed or non-processed sensing data which may include characteristics of objects
(e.g. type, distance, velocity, trajectory, size, shape, material), or other contextual information (e.g. time of
generation, environmental information) about objects in the Target Sensing Service Area.
rd
NOTE 2: It is not precluded that the sensing result exposed to an entity within 6GS or to an authorized 3 party
may in some cases consist of the sensing data itself.
• Sensing contextual information is information that is exposed with the sensing results which provides
context to the conditions under which the sensing results were derived (e.g. time of generation, environmental
information). This information does not contain sensing data or sensing results.
• Fusion refers to a process to join two or more streams of sensing data or sensing results together to form one
or more sensing data or sensing result stream(s). Fusion can take place at the origin of the sensing data, along
the system entities of a 6GS. The fusion of sensing results can also take place along all 6GS system entities.
Fusion can also take place in non-6GS entities.
Figure 4.3-1 uses the terminology defined above and illustrates the described information flow.
Figure 4.3-1: Workflow of conducting sensing using the terminology above
5 System architectures
5.0 System reference model
To derive a reference model for the 6GS system architecture at a top level, the requirements of the 18 identified 6G
ISAC use cases accepted in ETSI GR ISC 001 [i.1] were analysed. Specifically, the required sensing input data sources
(or sensing input data providers) and the expected sensing service results consumers for each of these use cases were
studied. The results of this analysis are shown in Table 5.0-1.
ETSI
12 ETSI GR ISC 003 V1.1.1 (2026-02)
Table 5.0-1: Sensing input data providers and sensing service consumers for
each of the use cases in ETSI GR ISC 001 [i.1]
6G ISAC use case in ETSI GR ISC 001 [i.1] Source / Provider of Consumer of the
the sensing input data sensing service
Human motion recognition 6GS entities (UEs, ANs) 6G UEs,
rd
3 party application(s)
Airborne-based sensing for environmental 6GS entities (UEs, ANs) 6GS entities (UEs, ANs, NFs),
rd
reconstruction 3 party application(s)
Real-time monitoring of health hazard and 6GS entities (UEs, ANs), 6G UEs,
rd rd
disaster risk 3 party sensing input(s) 3 party application(s)
Emergency search and rescue 6G UEs 6G UEs,
rd
3 party application(s)
rd
Remotely controlled robots for 6GS entities (UEs, ANs), 3 party application(s)
rd
senior citizen monitoring and care 3 party sensing input(s)
Precise localization for robot grasping 6GS entities (UEs, ANs), 6GS entities (UEs, ANs, NFs),
rd rd
3 party sensing input(s) 3 party applications(s)
rd
Micro-deformation sensing 6GS entities (UEs, ANs) 3 party application(s)
rd
Traffic throughput and safety on road 6GS entities (UEs, ANs) 3 party application(s)
intersections
Collaborative robots based on 6GS entities (UEs, ANs) 6GS entities (UEs, ANs, NFs),
rd
digital twinning 3 party application(s)
Body proximity sensor 6GS entities (UEs, ANs) 6GS entity (UEs, ANs)
rd
High resolution topographical maps 6GS entities (UEs, ANs), 3 party application(s)
rd
3 party sensing input(s)
rd
Outdoor healthcare sensing and monitoring 6GS entities (UEs, ANs) 3 party application(s)
rd
R-CPS in industrial worksites 6GS entities (UEs, ANs), 3 party application(s)
rd
3 party sensing input(s)
rd
Use case on safe & economic UAV transport 6GS entities (UEs, ANs), 3 party application(s)
rd
3 party sensing input(s)
rd
Use case on emergency vehicle route planning 6GS entities (UEs, ANs), 3 party application(s)
rd
3 party sensing input(s)
Sensing-aided communications 6GS entities (UEs, ANs), 6GS entities (UEs, ANs, NFs),
rd
3 party application(s)
rd
Use case for automated guided vehicles 6GS entities (UEs, ANs), 3 party application(s)
rd
travelling in airports 3 party sensing input(s)
rd
Vison-aided sensing 6GS entities (UEs, ANs), 3 party application(s)
rd
3 party sensing input(s)
Based on this analysis a reference model for the definition of 6GS architecture is introduced. This model supports all of
the identified 6G ISAC use cases in [i.1]. This reference model is illustrated in Figure 5.0-1.
Figure 5.0-1: 6GS reference model
The reference model includes the following definitions:
• 6GS Sensing Service Producer (SSP): a 6GS entity providing the 6G Sensing Service(s);
• 6GS Sensing Service Consumer (SSC): a 6GS entity which can be authorized to request and consume 6G
Sensing Service(s). SSC may include UEs, Access Nodes, and Core Network Functions;
ETSI
13 ETSI GR ISC 003 V1.1.1 (2026-02)
rd
• 3 party Sensing Service Consumer (3-SSC): an entity, not part of 6GS, which can be authorized to request
and consume 6G Sensing Service(s);
• 6GS Sensing Input Data Provider (SIDP): a 6GS entity which can provide input data needed to provide the 6G
Sensing Service. SIDP may include UEs and Access Nodes;
rd
• 3 party Sensing Input Data Provider (3-SIDP): an authorized entity, not part of 6GS, which can provide input
sensing data needed to provide the 6G Sensing Service.
The Sensing Service Consumer and the 6GS Sensing Service Producer interact according to service-based
request/response paradigm, e.g. via Sensing Service request/response (ss_req/ss_res).
rd
The 3 party Sensing Service Consumer and the 6GS Sensing Service Producer interact according to service-based
request/response paradigm, e.g. via Sensing Service request/response (ss_req/ss_res).
The 6GS Sensing Service Producer and the 6GS Sensing Input Data Provider interact (possibly according to
service-based request/response paradigm), e.g. via Sensing Input Data request/response (sid_req/sid_res).
rd
The 6GS Sensing Service Producer and the 3 party Sensing Input Data Provider interact (possibly according to
rd
service-based request/response paradigm), e.g. via 3 party Sensing Input Data request/response (3sid_req/3sid_res).
NOTE 1: The defined entities and messages do not necessarily correspond to 6GS network entities, 6GS network
functions, 6GS interfaces, 6GS protocol messages and relating interfaces.
NOTE 2: The defined entities and messages do not necessarily correspond to 3GPP defined [i.3], [i.4] network
entities, network functions, interfaces, protocol messages and relating interfaces.
NOTE 3: When sensing data is requested from a SIDP for 3-SIDP or sensing results, regulatory requirements
regarding user privacy and sharing of personally identifiable information (including as a result of fused
sensing data from multiple sources) should be maintained.
5.1 Identified considerations and challenges
5.1.1 Sensing Function (SF) considerations
The ability to enable sensing in mobile networks addresses one of the three newly added IMT 2030 usage scenarios and
numerous 6G use cases have been studied in ETSI ISG ISAC and is published as ETSI GR ISC 001 [i.1]. ETSI
GR ISC 001 [i.1] identifies the need to add new functionality across the entire 6G system to enable sensing, with the
need for 6G RF sensing capabilities in 6G UEs and 6G BSs are foundational towards enabling sensing in a mobile
network. Furthermore, non-RF sensing capabilities may be present at 6G UEs and 6G BSs and/or sensing data from
non-6GS sources may be available either within the 6GS or connected from trusted or untrusted domains. In several use
cases described in ETSI GR ISC 001 [i.1], fusion of 6GS and non-6GS sensing data is assumed. Thus, the sheer
complexity of coordinating sensing tasks based on sensing capabilities requires new functionality in the 6GS.
Additionally, requests for a new Sensing Service may arrive from within the 6GS [i.1], e.g. from an application server
in the DN or an application on the UE. These Sensing Service requests will carry more detailed data describing what is
expected from the Sensing Service, e.g. KPIs for sensing results, TSSA or specific 6G UE IDs that should be used in the
Sensing Service. Also, the consumer of the sensing results can be either an SSC [i.1] or a 3-SSC which requires
coordination. This increases the complexity of coordinating sensing tasks to fulfil a requested Sensing Service.
The majority of sensing use cases presented in [i.1] indicate the movement of either the target object(s) and/or the 6G
UEs that are part of a sensing task. In many use cases these movements require a change of involved Sensing
Transmitter or Receiver, as they are no longer suitable to maintain the requested Sensing Service sensing results. And
given the nature of mobile networks, a handover of a sensing task to Sensing Transmitters and/or Receivers that are
attached to a different 6G BS requires coordination across 6G BSs for continuous execution of sensing tasks.
Sensing data is of significant sensitive nature, as it theoretically allows facial recognition, behavioural human pattern
building and tracking of individuals without their knowledge. To protect the privacy of individuals and allowing them
to understand who collects, processes and exposes private data to whom, the 6GS should implement official General
Data Protection Regulation (GDPR) [i.5] and be consistent with the practices and principles captured in [i.6].
ETSI
14 ETSI GR ISC 003 V1.1.1 (2026-02)
In 5G, 3GPP adopted Service-Based Architecture (SBA) principles for a range of reasons:
1) multi-vendor deployments of operator CNs, allowing to choose the best vendor for a specific NF based on the
operator needs;
2) flexibility in which NF is selected and deployed against the service requirements the mobile network is
supposed to serve;
3) leveraging cloud-native software approaches of CN NFs for developing, deploying and managing NFs
on-demand in an agile fashion.
Furthermore, the proposition of mobile networks being used as private networks (NPNs or PNI-NPN) requires
customized but still standard-compliant deployments of 5G networks, yielded by SBA principles of the 5GS. Similar to
eMBB, URLLC and mMTC, sensing should be seen as a unique service which not all 6G networks will need in their
service offering and any system approaches to enable sensing should follow SBA principles.
5.1.2 Sensing service request and configuration
Sensing service request:
• From the reference model of Figure 5.0-1, the 6GS sensing service is exposed by the Sensing Service Producer
(SSP) via a service-based interface. A sensing service request (ss_req) can be issued by a 6GS Sensing Service
rd
Consumer (SSC) (which may include UEs, Access Nodes, Core Network Functions) and by 3 party Sensing
Service Consumer (3-SSC).
The challenges for sensing service request therefore include:
rd
• the definition of which 6GS entities and which 3 party entities may be authorized to invoke the sensing
service requests;
• the definition of the supported sensing results types by 6GS (e.g. sensing data, processed sensing data, others);
• for processed sensing data type, the definition of the supported sensing results by 6GS (e.g. object recognition,
motion recognition, deformation recognition, others);
• the definition of the supported sensing results timing by 6GS (e.g. single instance, interrupt, periodic, stream,
others);
• the definition of the QoS profiles for the sensing service supported by 6GS (QoS profiles e.g. including
accuracy, latency, resolution, others);
• the definition of the interface to invoke the sensing service requests;
• the definition of the format of the sensing service requests;
• the definition of possible data formats and their structures for describing the Target Sensing Service Area.
5.1.3 Sensing input data request definition
From the reference model of Figure 5.0-1, upon reception and processing of a sensing service request, the Sensing
Service Producer (SSP) selects SIDP(s) and 3-SIDP(s), the SSP configures the parameters of SIDP(s) and the SSP
configures (if possible) the parameters of 3-SIDPs. The purpose of selecting and configuring (if possible) (3-)SIDP(s) is
to execute a sensing task and for the SSP to collect sensing data in order to provide the requested sensing service. The
SSP generates and sends the sensing input data request (sid_req) to the selected SIDP(s) and 3-SIDP(s).
The quality of the sensing data is assessed based on the Sensing Service KPI requirements of the sensing results
communicated from the SSC/3-SSC.
The challenges of the sensing input data request definition include:
• The definition of SSP functionalities to discover and select the SIDP(s) and 3-SIDP(s) to provide the requested
sensing service, and means to coordinate the processing of sensing data provided by the (3-)SIDP.
ETSI
15 ETSI GR ISC 003 V1.1.1 (2026-02)
• The definition of interfaces, procedures and protocol stacks to interact with other 6GS components to discover
and select the SIDP(s) and 3-SIDP(s).
• The supported sensing data format by SIDP(s) and 3-SIDP(s).
• SIDP(s) and 3-SIDP(s) sensing data provisioning options.
• The sensing input data request message format(s) supported by SIDP(s) and 3-SIDP(s). This includes the
terminology definition of the content of the sensing input data request message formats, for flexible
configuration of 6G RF sensing receivers.
• Mechanisms to configure SIDPs for efficient sensing data management purposes (i.e. selective measurement
and reporting) allowing the SSP to meet the KPI requirements of the sensing results provided by the (3-)SSC
in the sensing service request.
NOTE: Other aspects relating to the sensing input data request (e.g. authorization, authentication security, etc.)
may be in the scope of ETSI GR ISC 004 [i.6] and may need to be addressed therein.
5.1.4 Sensing input data response
From the reference model of Figure 5.0-1, upon reception and processing of a sensing input data request (sid_req), the
SIDP and the 3-SIDP, if capable, may configure radio resources to generate the requested sensing data, and may
process, filter, format the sensing data to generate the sensing input data response (sid_res).
The challenges of the sensing input data response definition include:
• the definition of sensing data characteristics supported by SIDP and 3-SIDP;
• the definition of sensing data format supported by SIDP and 3-SIDP;
• the definition of SIDP and 3-SIDP sensing data exposure options;
• the definition of SIDP and 3-SIDP functionalities needed to generate the supported sensing data;
• the definition of the sensing input data response format, including:
- the message format and terminology definitions of the content of sensing input data response;
- the interfaces, procedures and protocol stacks SIDP/3-SIDP - SSP to transfer the Sensing Input Data
Response messages.
NOTE: Other aspects relating to the sensing input data response (e.g. authorization, authentication, security, etc.)
may be in the scope of ETSI GR ISC 004 [i.6] and may need to be addressed therein.
5.1.5 Considerations and challenges on network payload related to
sensing data
Collecting and transferring through the 6G network data related to sensing will likely generate a large payload.
Reducing redundancy by selecting in a smart way sensing data to be collected and/or reported in multi-sensor 6G
systems can significantly reduce the payload carrying sensing data for ISAC systems and allow more efficient
operations.
Smart data selection solutions (e.g. SIDP selection, data selection, etc.) need to be designed to reduce the payload
associated with carrying sensing data. Smart data selection may consist of, for example, selecting a specific angle of
view among several redundant ones, or a most representative angle of interest among complementary ones, or a
sufficient subset of measurements in the context of cooperative data fusion. Only relevant data should be effectively
transferred through the network, thus leading to efficient sensing data collection and reporting procedures. Additionally,
such data collection would be beneficial for sensing data fusion allowing efficient utilization of processing resources.
In the process of SIDP and/or data selection, particular attention should be given to factors such as the occlusion
phenomena, sensor capability, network load, and operator policy.
ETSI
16 ETSI GR ISC 003 V1.1.1 (2026-02)
The challenges for reducing the network payload related to carrying sensing data include:
• Design of efficient sensing data collection and reporting protocols:
- Including impacts on procedures for sensing data request/response, transport of sensing results, etc.
• Procedures to identify relevant data and/or relevant sensors and/or appropriate processing resources:
- To control the overall payload from system perspective while ensuring service requirements of specific
applications/sensing tasks.
- In challenging environments, e.g. in the presence of occlusion phenomena, and subject to sensor
capability, network load, operator policy.
5.1.6 Sensing results exposure and transport
From the reference model of Figure 5.0-1, the Sensing Service Producer (SSP) processes sensing data (received via
sid_res/3sid_res) to generate sensing results which are then provided (ss_res) to the Sensing Service Consumer (SSC) or
rd
3 party Sensing
...




Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...