Integrated Sensing and Communication (ISAC) is one of the representative usage scenarios of IMT-2030. The basic idea is to let a mobile communication system use radio signals not only to transfer information but also to observe the physical environment. By processing the reflected and scattered components of a transmitted signal, the network may estimate the presence, range, direction, velocity, shape, or motion of an object. The sensed object does not necessarily carry a UE or actively cooperate with the network.

At first glance, ISAC may look like simply putting a radar and a base station together. However, the interesting research problems start when the two functions share sites, spectrum, antennas, radio resources, waveforms, computing resources, and network interfaces. Communication wants a high and reliable data rate, whereas sensing wants signals and observation intervals that make range, angle, and Doppler estimation accurate. How much should be shared, and how should the system resolve the conflict between these objectives? Those questions are at the center of ISAC research.

• Executive Summary
• Basic Concept
• What Can Be Measured ?
• Sensing Modes and Topologies
• Levels of Integration
• Signal Processing Chain
• System and RAN Architecture
• Representative Use Cases
• Communication-Sensing Tradeoffs
• Network Architecture
• Procedures for end-to-end sensing service operations
• Major Research Challenges
• Security, Privacy, Trustworthiness and Sustainability
• Standardization Status

Executive Summary

Basic Concept

In a normal communication system, the main goal of the receiver is to recover the transmitted data as correctly as possible. The radio channel between transmitter and receiver is usually treated as something that distorts the signal. For example, the transmitted signal may arrive through multiple paths due to reflection, diffraction, or scattering from buildings, vehicles, people, or other objects. These multipath components may cause fading, delay spread, inter-symbol interference, Doppler shift, or phase rotation. From the communication point of view, the receiver usually tries to estimate this channel and compensate for it so that the original data can be decoded reliably.

ISAC starts from a slightly different way of looking at the same phenomenon. The multipath components are not only unwanted distortion. They are also evidence of the surrounding environment. If a reflected signal arrives later than the direct signal, the delay tells us something about the distance traveled by that reflected path. If the reflected signal has a frequency shift or phase change over time, it may indicate that the reflecting object is moving, and the amount of Doppler shift is related to the radial velocity of the object. If the same reflected signal is received by multiple antenna elements with different phases, the phase difference across the antenna array can be used to estimate the direction or angle of arrival. In this sense, the radio channel is not just a problem to be corrected. It is also a source of sensing information.

This is the basic idea of ISAC. The same transmitted waveform that carries user data can also illuminate the surrounding space. The receiver can then process the received signal for two purposes. One purpose is communication, where the system extracts bits, symbols, transport blocks, or packets. The other purpose is sensing, where the system extracts physical information such as presence, range, velocity, angle, shape, or motion pattern. The communication receiver asks, “What data was transmitted?” The sensing receiver asks, “What kind of environment caused this received signal?”

A simple way to understand this is to compare it with radar. Radar transmits a known signal and observes the echo from objects. From the echo delay, it estimates range. From Doppler shift, it estimates velocity. From antenna array phase, it estimates angle. ISAC uses a similar principle, but the transmitted signal is not necessarily a pure radar waveform. It may be a 5G or 6G communication waveform such as OFDM. Therefore, the challenge is to design and process the signal so that it can still support high-throughput communication while also providing useful sensing measurements.

This also means that the propagation channel has two meanings at the same time. For communication, the channel is usually represented as a mathematical response that must be estimated for equalization, beamforming, link adaptation, and decoding. For sensing, the same channel response can be interpreted as a physical signature of the environment. Delay is related to distance, Doppler is related to motion, phase across antennas is related to direction, and the combination of these features can describe more complex properties such as object shape, motion pattern, or class. In short, ISAC changes the role of the radio channel from something to be only compensated into something to be measured and understood.

• Communication function : Delivers user or control data with the required throughput, latency, reliability, and coverage.
• Sensing function : Detects an object or event and estimates physical properties such as range, angle, velocity, size, or motion pattern.
• Integration : Coordinates or reuses infrastructure, spectrum, hardware, signals, processing, and network functions so that the two services can operate efficiently.

ISAC should also be distinguished from conventional positioning. Positioning usually estimates the location of a cooperative UE by processing signals exchanged with that UE. Sensing can detect a passive or non-cooperative object such as a pedestrian, vehicle, obstacle, or drone. The boundary is not always sharp because positioning information, sensing results, maps, and data from cameras or other sensors can be fused in the same application.

What Can Be Measured ?

In ISAC, the radio signal is used not only to carry communication data but also to observe the surrounding environment. When the transmitted signal hits an object, part of the signal is reflected back or scattered, and the receiver can analyze this returned signal to estimate different properties of the object. Depending on what part of the received signal is observed, the system may detect whether an object exists, estimate its range from propagation delay, derive its radial velocity from Doppler shift, infer its direction from phase differences across antenna elements, or classify its shape and motion from combined range, angle, and Doppler patterns. However, these measurements are not determined by a single parameter. They are strongly affected by bandwidth, transmit power, antenna aperture, synchronization accuracy, clutter, noise, blockage, target reflectivity, and the stability of the radio hardware. This is why ISAC design is not just a matter of adding a sensing algorithm on top of a communication system. It requires careful joint design of waveform, bandwidth, antenna configuration, beam pattern, calibration, observation time, and signal processing so that the same radio system can support both reliable communication and meaningful sensing.

Sensing Modes and Topologies

In ISAC, sensing is not defined only by the waveform or the signal processing algorithm. It is also strongly determined by the topology, meaning where the sensing signal is transmitted, where the reflected or scattered signal is received, and where the sensing result is processed. This topology changes the difficulty of the measurement because it changes the geometry, synchronization requirement, interference condition, coverage area, and amount of information that must be shared between nodes. A simple monostatic structure may be easier to understand because the same node transmits the signal and receives its echo, but it may suffer from strong transmitter leakage and nearby reflections. A bistatic or multistatic structure can observe the environment from different positions and viewing angles, but it requires more coordination between nodes. Network-based sensing can reuse base station sites and edge processing resources, while UE-based sensing can provide observations closer to the target. Therefore, choosing a sensing mode is not just a matter of preference. It is a design decision that depends on deployment scenario, target type, required accuracy, available radio nodes, synchronization capability, backhaul capacity, UE capability, privacy constraints, and how the sensing result will be used by the network or application.

• Monostatic sensing : The same node transmits the signal and receives its echo. This resembles a conventional monostatic radar and makes the geometry relatively simple. The major difficulty is receiving a weak echo in the presence of strong transmitter leakage and nearby reflections.
• Bistatic sensing : One node transmits and another node receives the reflected signal. Transmitter self-interference is reduced, but accurate time, frequency, phase, and location information must be shared between the nodes.
• Multistatic or cooperative sensing : Multiple transmitters and/or receivers observe the same area. Different viewing angles can improve coverage, detection probability, and localization, but coordination and transport of sensing data become more demanding.
• Network-based sensing : Base stations or dedicated network sensing nodes perform most of the radio measurement. Existing site locations, antenna arrays, and edge computing resources may be reused.
• UE-based or UE-assisted sensing : A UE transmits, receives, or helps process sensing signals. This can provide observations close to the target but introduces battery, hardware, mobility, privacy, and reporting constraints.

Levels of Integration

The word integration in ISAC should not be understood as a single fixed architecture where every communication signal is always reused for sensing. In practice, integration can happen at many different levels, and each level gives a different balance between implementation complexity, deployment cost, performance gain, and operational flexibility. At the simplest level, communication and sensing systems may only share the same site, power, transport, or edge computing facility while still using separate radios. At a deeper level, they may share spectrum, time-frequency resources, antenna arrays, RF chains, clocks, or baseband processing. At the most integrated level, the same transmitted signal may be used both for data communication and for sensing measurement, and the resulting sensing information may be combined with network context, positioning information, maps, cameras, or other sensors.

This gradual view is important because ISAC does not have to be introduced all at once. A practical deployment may start from infrastructure sharing or spectrum coordination, then move toward hardware sharing, waveform sharing, and finally service-level data integration as the technology becomes more mature. Also, different use cases may require different levels of integration. For example, a traffic monitoring application may benefit from network-based sensing and edge processing, while a short-range device interaction scenario may rely more on UE-assisted sensing. Therefore, the level of integration should be chosen based on the required sensing accuracy, communication impact, hardware capability, synchronization quality, spectrum availability, privacy constraints, and how the sensing result will be consumed by the final application.

• Site or infrastructure sharing : Communication and sensing equipment use the same tower, power, transport, or edge-computing location while remaining separate radio systems.
• Spectrum and resource coordination : The systems share a band or coordinate time-frequency resources to control mutual interference.
• Hardware sharing : Antenna arrays, RF chains, clocks, converters, and processing platforms are reused by both functions.
• Signal and waveform sharing : Communication reference signals or data-bearing signals are also processed for sensing. Dedicated sensing signals can still be scheduled when a communication waveform does not provide the required bandwidth, direction, power, or repetition pattern.
• Service and data integration : Sensing results are combined with positioning, communication context, maps, cameras, or other sensors and exposed to an authorized application through network APIs.

Signal Processing Chain

The signal processing chain of ISAC can be understood as the path from a sensing intention to a sensing result. It does not start only at the receiver algorithm. Before any echo is analyzed, the network first has to know what kind of sensing is requested, where the sensing area is, what target or event should be observed, how accurate the result should be, how often the result should be updated, and how long the sensing operation should continue. Based on this request, the system selects suitable radio nodes, beams, time-frequency resources, waveform types, and processing locations.

After the sensing resources are configured, one or more nodes transmit a known or decodable signal, and one or more receivers collect the received signal. This received signal may contain many components at the same time. Some parts may be the direct path from transmitter to receiver, some parts may be useful reflections from the target, and other parts may be static clutter, communication interference, thermal noise, or unwanted leakage from the transmitter. Therefore, the first practical challenge is not yet object detection itself, but separating useful sensing information from all the other signal components mixed together in the received waveform.

Synchronization and calibration are especially important in this process. Timing error directly affects range estimation, frequency error affects Doppler estimation, phase error affects angle estimation, and antenna or RF-chain mismatch affects spatial processing. In a distributed sensing topology, this becomes even more critical because different nodes may have different clocks, locations, oscillator offsets, RF delays, and calibration errors. Without proper synchronization and calibration, the signal may still be received, but the extracted sensing result can be biased or unstable.

Once the signal is synchronized and calibrated, the receiver can remove or compensate for the known transmitted signal and estimate the echo-related parameters. From delay, the system can estimate range. From Doppler or phase evolution over time, it can estimate radial velocity. From phase and amplitude differences across antenna elements, it can estimate direction or angle. By combining these dimensions, the system can build intermediate representations such as a range-Doppler map, angle spectrum, point cloud, or other feature map. These are not yet always the final sensing result, but they provide a structured view of what the radio signal has observed.

The next step is to interpret these measurements. A single peak in a range-Doppler map may indicate a possible target, but real environments are usually more complicated. Multiple reflections, blockage, weak targets, moving clutter, and measurement noise can make detection and estimation difficult. Therefore, the system may apply tracking filters, target association, clustering, classification, or AI/ML-based inference. Measurements from different times, beams, cells, UEs, or even other sensors may be fused together to produce a more stable and meaningful result.

Finally, the sensing result should be exposed in a controlled way. In many cases, the application does not need raw IQ samples or unrestricted sensing data. It may only need information such as object presence, position, velocity, trajectory, occupancy, or an event indication. This is important because ISAC sensing data may contain sensitive information about people, vehicles, and environments. Therefore, the processing chain should not only consider radio accuracy, but also authorization, privacy, data abstraction, and how much detail should be delivered to the requesting application.

1. Sensing request and configuration : An authorized client specifies the sensing area, target type, required accuracy, update rate, and duration. The network selects suitable sensing nodes, signals, beams, and radio resources.
2. Transmission and reception : A node transmits a known or decodable waveform. One or more receivers capture the direct path, target reflections, clutter, interference, and noise.
3. Synchronization and calibration : Timing, frequency, phase, antenna, and RF-chain offsets are estimated or corrected. This step is especially important for coherent distributed sensing.
4. Channel and echo extraction : The receiver removes known transmitted symbols and estimates delay, Doppler, and spatial channel responses. Static clutter and communication interference may be suppressed.
5. Detection and estimation : Algorithms produce a range-Doppler map, angle spectrum, point cloud, or other intermediate representation and estimate target states.
6. Association, tracking, and fusion : Measurements obtained at different times or nodes are associated with targets. Filters or AI/ML models track motion and fuse RF sensing with other data sources.
7. Result exposure : The network provides only the authorized result and required level of detail to the requesting application, rather than exposing unrestricted raw sensing data.

System and RAN Architecture

ISAC should not be understood as only a new PHY-layer receiver function or a radar-like algorithm added inside the base station. If the sensing result is used as a real service, the system has to support the complete path from service request to radio configuration, measurement collection, sensing data processing, result exposure, policy control, privacy protection, charging, and lifecycle management. In other words, ISAC becomes an end-to-end system function, not just a signal processing block.

At the RAN level, the network has to decide which radio nodes will participate in sensing, which nodes will transmit, which nodes will receive, which beams and waveforms will be used, and how sensing resources will be coordinated with normal communication traffic. This is important because sensing should not blindly consume radio resources or degrade user data service. The RAN scheduler, beam management, power control, synchronization, reporting, and measurement configuration may all become part of the sensing operation.

At the system level, the network also needs a service control function. An application may request a sensing result, but the network must check whether the request is authorized, whether the requested area can be sensed, what resolution and update rate are allowed, how long the task can continue, and what level of detail can be exposed. The request then has to be translated into a concrete sensing task that the RAN and processing functions can execute.

The sensing data itself may be processed in different locations. Some processing may happen close to the radio unit or baseband to reduce latency and transport load, especially when raw or near-raw radio data is large. Other processing may happen at an edge cloud, core network, or application platform where observations from multiple cells, UEs, maps, cameras, or other sensors can be combined. Therefore, the architecture has to support both local processing for fast response and more centralized processing for wider-area fusion.

Finally, ISAC architecture must include controlled result exposure. The application usually should not receive unrestricted raw sensing data. It may only need an abstracted result such as object presence, location, velocity, occupancy, trajectory, or event indication. This is closely related to privacy, security, policy, and charging. The network must control who can sense which area, for what purpose, at what resolution, for how long, and with what accountability. This is why 6G ISAC architecture is studied not only from the radio perspective, but also from the service, policy, exposure, and lifecycle management perspective.

• Sensing service control : Authorizes a request, translates application requirements into a sensing task, selects sensing entities, and manages the task lifecycle.
• RAN sensing coordination : Configures participating transmitters and receivers, beams, waveforms, radio resources, power, and reporting. It must coordinate sensing with normal communication scheduling.
• Sensing data processing : Converts raw or partially processed measurements into a useful sensing result. Processing close to the radio can reduce transport load and latency, while centralized processing can combine observations from a wider area.
• Sensing result exposure : Delivers results through controlled APIs to vertical applications such as traffic management, factory automation, or public safety.
• Policy, privacy, and charging : Restricts who can sense which area, at what resolution, for how long, and for what declared purpose. It also provides accounting and charging support for a commercial sensing service.

Representative Use Cases

The use cases of ISAC are very wide because the basic sensing principle can be applied to many different environments. If the network can observe reflection, delay, Doppler, angle, and motion-related features from radio signals, it can provide information not only about communication links but also about objects, people, vehicles, drones, machines, and surrounding spaces. This makes ISAC useful in indoor, outdoor, and mixed deployments, but the value of sensing is different for each scenario.

For UAV and low-altitude airspace monitoring, the main value is wide-area observation. A drone may be difficult to detect from a single point, but a cellular network already has many distributed sites, antennas, and coverage areas. If these sites can perform sensing together, the network may detect and track flying objects around airports, stadiums, borders, or critical infrastructure. For road and railway safety, the value is complementary awareness. Vehicles and trains may already have cameras, lidar, or radar, but network sensing can observe areas outside the field of view of a single vehicle, such as blocked intersections, curves, tunnels, platforms, or trackside obstacles.

In industrial automation, ISAC can support both machine control and situational awareness. A factory may need to know the position and movement of robots, automated guided vehicles, workers, tools, and materials. If the same wireless infrastructure can provide communication and sensing, the system can reduce the gap between connectivity and environmental awareness. In emergency and public safety scenarios, the value is even more direct. Radio sensing may help search for motion or human presence in smoke, darkness, blocked areas, or places where visual sensors are limited, although the achievable performance depends heavily on propagation condition, bandwidth, geometry, and deployment density.

Human activity and fine-motion sensing is another important but sensitive area. Small movements such as gesture, posture change, breathing-like motion, or room occupancy may be useful for assisted living, health-related monitoring, smart homes, and smart buildings. However, this kind of sensing can also reveal private behavior, so privacy and authorization become as important as radio performance. ISAC can also support digital twins and spatial computing by continuously updating the representation of buildings, roads, factories, or extended-reality spaces. In this case, sensing is not only used for detecting a single target, but for maintaining a live model of the environment.

There are also use cases where sensing is used by the network itself. This is sometimes called network self-improvement. If the network can sense blockage, mobility, object movement, or environmental change, it may improve beam management, handover preparation, interference management, radio-map construction, and blockage prediction. In this case, the sensing result does not necessarily have to be exposed to an external application. It can be used internally to make the communication system more adaptive and robust. Therefore, ISAC use cases can be grouped not only by vertical industry, but also by the kind of value they add: public safety, automation, mobility safety, environmental awareness, human activity monitoring, digital representation, or improvement of the radio network itself.

• UAV and low-altitude airspace monitoring : Detects and tracks cooperative or non-cooperative drones around airports, borders, stadiums, or critical infrastructure. A cellular network can provide observations from multiple geographically distributed sites.
• Road and railway safety : Detects vehicles, pedestrians, debris, or obstacles outside the field of view of an individual vehicle or train. The sensing result can complement cameras, lidar, and onboard radar.
• Industrial automation : Tracks robots, automated guided vehicles, workers, tools, or material in a factory. Communication and sensing from the same infrastructure can support both machine control and situational awareness.
• Emergency and public safety : Searches for motion or human presence in smoke, darkness, or obstructed areas and supports situational awareness for rescue teams. The achievable result depends strongly on propagation, frequency, bandwidth, and deployment geometry.
• Human activity and fine-motion sensing : Detects gestures, posture, respiration-like motion, or occupancy for assisted living, health-related applications, and smart spaces. These use cases have particularly sensitive privacy implications.
• Digital twins and spatial computing : Supplies updated object and environment information to a digital representation of a factory, road, building, or extended-reality space.
• Network self-improvement : Uses environmental awareness to support beam management, blockage prediction, mobility, interference management, or radio-map construction.

Communication-Sensing Tradeoffs

One of the key points in ISAC is that communication and sensing do not always prefer the same radio configuration. In a pure communication system, the main objective is usually to deliver data with high throughput, good reliability, low latency, and efficient use of spectrum and power. In a sensing system, the objective can be different. The system may need wide bandwidth for range resolution, long observation time for Doppler estimation, stable phase information for angle estimation, repeated illumination for tracking, or wide-area coverage for target search. Because of this, a configuration that is very efficient for communication may not automatically produce good sensing performance.

For example, communication scheduling normally follows user traffic demand. If a UE has data, the network schedules resources. If there is little traffic, the network may reduce transmission. However, sensing may need periodic or continuous observation even when there is no communication traffic in the area. Similarly, a narrow beam can improve communication link budget and reduce interference, but it only observes a small spatial region. If the sensing task is to search a wide area, the system may need beam sweeping, multiple beams, or cooperation between several nodes. This can consume time, power, and radio resources that would otherwise be used for data service.

Bandwidth is another important example. Larger bandwidth gives finer delay resolution, so it helps the system distinguish two objects that are close in distance. However, very wide bandwidth is often easier to obtain at higher frequency bands, where coverage, penetration, and blockage can be more difficult. Transmit power also creates a tradeoff. Higher power can improve echo detection and sensing range, but it may increase interference, energy consumption, exposure concerns, and coordination burden with neighboring cells or communication users.

There is also a tradeoff in where the sensing data is processed. Processing close to the radio node can reduce latency and avoid transporting large amounts of raw data, but it may only see a local part of the environment. Centralized processing can combine observations from many cells, UEs, or sensors and produce a wider-area result, but it requires transport capacity, synchronization, storage, and protection of more sensitive sensing information. Therefore, the best processing location depends on whether the application needs fast local reaction, broad spatial awareness, or long-term fusion.

Finally, ISAC introduces a tradeoff between sensing accuracy and privacy. Higher resolution, longer observation time, finer classification, and longer data retention may improve the sensing result, but they can also reveal more information about people, behavior, movement, and sensitive locations than the application really needs. For this reason, ISAC optimization is not only a radio problem. The scheduler and system architecture have to balance communication performance, sensing quality, resource usage, interference, latency, deployment cost, and privacy. A practical ISAC system has to decide not only how well it can sense, but also how much sensing is necessary and acceptable for the given service.

• Bandwidth versus coverage : Wide bandwidth improves range resolution but is easier to obtain at higher frequencies, where coverage and blockage can become more challenging.
• Data rate versus sensing observation : Communication scheduling follows traffic demand, while sensing may require periodic transmissions, long coherent observation intervals, or illumination of an area with little communication traffic.
• Beamforming gain versus field of view : A narrow beam improves link budget and angular selectivity but covers only a small region. Wide-area search requires beam scanning or multiple simultaneous beams.
• Transmit power versus interference : More power can improve echo detection, but it increases energy consumption and interference to communication users and neighboring sensing receivers.
• Local processing versus central fusion : Local processing reduces latency and the amount of transported raw data. Central processing provides a broader view but requires fronthaul/backhaul capacity, synchronization, and protection of more sensing information.
• Accuracy versus privacy : Higher resolution and longer retention may improve an application but can also reveal more about people, behavior, or sensitive locations than the service actually requires.

Network Architecture

ISAC should not be understood as simply adding a sensing algorithm or radar-like processing block inside the gNB. The gNB is important because it transmits and receives the radio signals used for sensing, but the complete ISAC operation is wider than the gNB itself. A sensing service has to start from a service request, check whether the requester is authorized, determine the target sensing area, select one or more gNBs that can act as Sensing Entities, configure the sensing operation, collect sensing data, process or aggregate the results, and finally expose the sensing result to the application in a controlled way.

In other words, the gNB performs the radio-facing part of sensing, but the service logic is handled at the network level. The SenF manages the sensing service, the NEF exposes the service safely to external applications, and the AF consumes the sensing result. This is why the architecture includes reference points such as SEN1, SEN2, SEN3, and N33. They show that ISAC involves interaction between RAN, core network functions, and application functions, not only internal processing inside a base station.

This network-service view is important because sensing results may be requested by different applications, such as drone detection, traffic monitoring, public safety, or factory automation. Each request may have different requirements in terms of sensing area, accuracy, reporting mode, duration, privacy, and authorization. If sensing were only a local gNB feature, it would be difficult to manage these service-level requirements consistently. By treating ISAC as a network service, the system can control who is allowed to sense, where sensing can be performed, what level of detail can be exposed, and how the sensing result is delivered to the application.

In this architecture, The gNB acts as the Sensing Entity that performs radio-level sensing operation, while the Sensing Function, or SenF, handles the sensing service control and sensing data processing in the core network side. The SenF may be logically divided into SenF-C for control and SenF-P for processing, although the interface between them is not standardized in this release. A sensing request can come from an Application Function either through the NEF when the AF is outside the trusted operator domain, or directly through SEN3 when the AF is inside the trusted domain. The sensing result is then returned back to the requesting AF through the corresponding reference point. In this way, the architecture separates radio sensing execution, sensing service control, result processing, and service exposure, so that ISAC can be managed as an end-to-end 5G system service rather than just a PHY-layer measurement function.

< 23.137 - Figure 4.2-1: 5G Sensing architecture in reference point representation >

• Overall Architecture: This figure shows the 5G sensing architecture in reference point representation, where the sensing service is handled through interaction between the gNB, SenF, NEF, and AF. The main idea is that sensing is not performed as an isolated gNB feature, but as a service involving RAN, core network functions, and applications.
• gNB as Sensing Entity: The gNB acts as the Sensing Entity. It is the radio-side node that performs sensing-related transmission, reception, or measurement using 3GPP radio signals. In practical terms, the gNB is the entity closest to the actual RF sensing operation.
• SenF as Sensing Function: The SenF, or Sensing Function, is the core-network-side function that manages the sensing service. It communicates with the gNB over SEN2 and handles sensing service control, sensing data handling, result generation, and result exposure toward applications.
• SenF-C and SenF-P: Inside the SenF, the diagram shows two logical parts: SenF-C and SenF-P. SenF-C can be understood as the sensing control functionality, while SenF-P can be understood as the sensing processing functionality. The document notes that there is no standardized interface between SenF-C and SenF-P in this release.
• SEN2 Reference Point: SEN2 is the reference point between the gNB and the SenF. This reference point supports interaction between the SenF and the gNB acting as a Sensing Entity. Through this interface, the SenF can coordinate sensing operation with the radio node, and the gNB can provide sensing-related data or results back toward the SenF.
• SEN1 Reference Point: SEN1 is the reference point between the SenF and the NEF. It supports sensing service requests from the NEF toward the SenF and also supports transfer of sensing results back to the requesting NEF.
• NEF Role: The NEF, or Network Exposure Function, is used when the Application Function is outside the trusted operator domain. It works as a controlled exposure point so that external applications do not directly access internal network functions.
• N33 Reference Point: N33 is the reference point between the NEF and the AF. When an external AF requests sensing service, the request goes through N33 to the NEF, then through SEN1 to the SenF. The sensing result can return through the reverse path.
• SEN3 Reference Point: SEN3 is the reference point between the SenF and an AF inside the trusted domain. In this case, the AF can interact with the SenF more directly without passing through the NEF.
• External AF Path: The upper AF in the diagram represents an external or NEF-mediated application path. The request path is AF → N33 → NEF → SEN1 → SenF → SEN2 → gNB, and the sensing result follows the reverse direction.
• Trusted AF Path: The lower AF in the diagram represents a trusted-domain AF path. The request path is AF → SEN3 → SenF → SEN2 → gNB, and the sensing result is returned through SEN3.
• Service-Level Control: This separation is important because different applications may request different sensing services, such as drone detection, tracking, or area monitoring. The network has to check the request, select the sensing entity, configure the sensing operation, collect sensing data, process the result, and expose only the allowed result.
• Key Interpretation: In short, the gNB performs the radio sensing part, the SenF controls and processes the sensing service, the NEF provides controlled external exposure, and the AF consumes the sensing result. This is why the architecture is service-oriented rather than simply gNB-internal.

At this point, we can think of several different options for the transport stack used to carry NsAP messages between the gNB and the SenF. These options should be understood as candidate approaches being considered during the study phase, not as a final requirement that all of them must be supported. The purpose of comparing these stacks is to understand which lower-layer transport mechanism is more suitable for sensing-related signalling or sensing data transfer in terms of reliability, implementation complexity, reuse of existing telecom protocols, security, and future standardization direction. In this comparison, SCTP-based transport, GTP-U-based transport, and WebSocket-based transport represent different design choices, but the current study conclusion points toward the SCTP-based option as the preferred direction for a potential future normative phase.

The key idea is that NsAP defines what sensing-related information is exchanged, while SCTP, GTP-U, or WebSocket defines how that information is transported. The choice of transport stack affects reliability behavior, security model, implementation complexity, compatibility with existing telecom infrastructure, and whether the interface feels more like telecom signaling, user-plane data transport, or application/service communication.

• In the SCTP-based option, NsAP is carried over SCTP/IP. This is close to the style used by many telecom control-plane interfaces, where reliable message delivery, ordered or partially ordered delivery, multihoming, and association-based communication are useful. This kind of stack is suitable when NsAP is mainly used for control signaling between network nodes.
• In the GTP-U-based option, NsAP is carried as payload over GTP-U/UDP/IP. This looks more like a user-plane transport model. It may be considered when sensing information is treated as transported data, especially if the system wants to reuse existing user-plane transport mechanisms, tunneling behavior, or packet forwarding infrastructure. Compared with SCTP, this option is more payload-transport oriented than signaling-connection oriented.
• In the WebSocket-based option, NsAP is carried over WebSocket, protected by TLS, and transported over TCP/IP. This gives a more application-layer-friendly model. It can be useful when the interface needs easier integration with software platforms, service-based systems, cloud-native components, or application-facing environments. TLS also provides a built-in security layer for protecting the exchanged NsAP messages.

Procedures for end-to-end sensing service operations

Procedures for end-to-end sensing service operations describe how a sensing request is handled from the application side down to the radio network and then back to the application as a sensing result. The important point is that ISAC is not triggered only by a local gNB decision. It starts from a Sensing Service Consumer, such as an AF, requesting a sensing service for a target area or object. The request is then authorized, routed to the Sensing Function, translated into sensing service parameters, and delivered to one or more gNBs acting as Sensing Entities. After the gNB performs the sensing operation and reports sensing data or sensing results, the SenF processes the information and returns the final sensing result to the requesting application, either directly or through the NEF. In this way, the procedure connects service request, authorization, sensing entity selection, radio sensing execution, result processing, and service exposure into one end-to-end operation.

Sensing establishment

This procedure shows how an end-to-end ISAC sensing service is established from the application side down to the radio network. The sensing service is requested by the Sensing Service Consumer, normally an AF, either through the NEF when the AF is outside the trusted operator domain or directly toward the SenF when the AF is inside the trusted domain. Before the actual request handling, the gNB and SenF may already have a signalling connection, and the SenF may already be registered in the NRF so that it can be discovered and selected.

Once the request arrives, the network checks authorization, selects the proper SenF, and then the SenF authorizes the sensing service request and selects one or more gNBs that can act as Sensing Entities. After that, the SenF interacts with the selected gNB to perform the actual sensing operation. The gNB provides the radio-side sensing capability, but the service is controlled at the network level by the SenF. When the sensing result is generated, it is delivered back to the requesting AF either directly or through the NEF. So the main idea of this procedure is to connect application-level sensing request, network authorization, sensing entity selection, radio sensing execution, result generation, and result notification into one end-to-end service flow.

< 23.137-Figure 6.2.1-1: End to End Sensing establishment Procedure  >

• Precondition: Before the service request starts, the gNB has already established a signalling connection with the SenF. This means the radio-side sensing entity and the core-side sensing function are already prepared to communicate. The SenF may also register or update its NF profile in the NRF so that it can later be discovered and selected.
• Service Request from AF: The sensing service is initiated by the Sensing Service Consumer, which is the AF in this procedure. If the AF is outside the trusted operator domain, it sends `Nnef_SensingService_Subscribe` to the NEF. If the AF is inside the trusted domain, it may send `Nsenf_SensingService_Subscribe` directly to the SenF.
• NEF Authorization: When the request comes through the NEF, the NEF first authorizes the AF for the received sensing subscribe request. If the authorization fails, the request is rejected and the rest of the procedure is skipped.
• SenF Discovery and Selection: If the AF is successfully authorized through the NEF path, the NEF discovers and selects an appropriate SenF. This allows the request to be routed to the sensing function that can handle the requested sensing service.
• Request Forwarding to SenF: After selecting the SenF, the NEF invokes `Nsenf_SensingService_Subscribe` toward the SenF using the parameters received from the AF. In the trusted-domain case, this forwarding through NEF is skipped because the AF contacts the SenF directly.
• SenF Authorization: The SenF performs its own authorization of the AF sensing request. This is a second level of checking at the sensing service control side. If this authorization fails, the SenF rejects the subscribe request with an appropriate cause code.
• Option 1 Response Timing: In Option 1, the SenF may accept the subscribe request and return the subscribe response before selecting or interacting with the gNB. If the request came through NEF, the response goes from SenF to NEF and then from NEF to AF. If the request came directly from a trusted AF, the response goes directly from SenF to AF.
• gNB Discovery and Selection: The SenF discovers and selects one or more gNBs that can act as Sensing Entities. This selection may consider the target sensing area, available gNB sensing capability, and other service parameters. If no suitable gNB can be selected, the subscription may be rejected or a status notification may be sent depending on whether the earlier response has already been sent.
• SenF and gNB Interaction: After selecting the gNB, the SenF interacts with the selected gNB or gNBs to perform the sensing operation. The detailed interaction is coordinated with RAN WGs, but conceptually this is where the SenF asks the gNB to carry out the radio sensing task.
• Option 2 Response Timing: In Option 2, the subscribe response may be delayed until after gNB discovery/selection and interaction with the gNB. This means the AF receives the acceptance response only after the network has progressed further in preparing the sensing operation. The document marks the exact response timing as FFS.
• Sensing Result Generation: Once the radio sensing operation is performed, the SenF generates the sensing result. This may involve processing sensing data received from the gNB and producing a result suitable for the requested service.
• Result Notification: The SenF sends the sensing result using `Nsenf_SensingService_Notify`. If the request path includes NEF, the NEF then sends `Nnef_SensingService_Notify` to the AF. If the AF is in the trusted domain, the SenF may notify the AF directly.
• Key Interpretation: The AF triggers the end-to-end sensing service request, the NEF provides exposure and authorization for external AFs, the SenF controls the sensing service and selects the gNB, and the gNB performs the radio-side sensing operation.

Sensing Service Modification

The Sensing Service Modification procedure describes how an already established sensing service can be updated after the initial sensing session has started. Unlike the initial establishment procedure, this flow is not only triggered by the AF. The modification can be initiated by the Sensing Service Consumer, such as the AF, when the application wants to change the sensing request, or it can be initiated by the SenF itself, for example when the sensing result or network condition indicates that the current sensing configuration needs to be adjusted.

In this procedure, the modification request is handled again through the same service-oriented architecture. If the AF is outside the trusted operator domain, the request goes through the NEF before reaching the SenF. If the AF is trusted, it may interact with the SenF more directly. The SenF then authorizes the updated sensing request, performs discovery or re-selection of gNBs if needed, and interacts with the selected gNBs to apply the modified sensing operation. After the sensing operation is updated and a new sensing result is generated, the result is notified back to the AF either directly or through the NEF. So the main idea of this procedure is to allow an ongoing sensing service to be dynamically adjusted without treating every change as a completely new sensing service establishment.

< 23.137-Figure 6.2.2-1: Sensing Service Modification  >

• Trigger Point: The modification procedure can be triggered either by the AF or by the SenF. If it is triggered by the AF, the request follows the service request path toward the SenF. If it is triggered by the SenF, for example based on an existing sensing result, the AF request and response steps at the beginning are skipped.
• AF-Initiated Modification via NEF: If the AF is outside the operator trusted domain, it sends the modification request through the NEF using the `Nnef_SensingService_Subscribe` service operation. In this case, the NEF forwards the corresponding `Nsenf_SensingService_Subscribe` request to the SenF.
• AF-Initiated Modification Directly to SenF: If the AF is inside the operator trusted domain, it can interact directly with the SenF using `Nsenf_SensingService_Subscribe`. In that case, the NEF path is not used.
• SenF-Initiated Modification: If the modification is triggered at the SenF, the SenF does not need to receive a new AF request first. This may happen when the SenF determines from the sensing result or current sensing condition that the ongoing sensing service needs to be updated.
• Authorization Check: When the modification request comes from the AF, the SenF may perform further authorization of the AF sensing service request. If the updated request is not allowed, the SenF can reject the request or revoke the previously authorized sensing service.
• Subscribe Response: After handling the request authorization, the SenF sends a response. If the request came through the NEF, the SenF responds to the NEF and the NEF sends the response back to the AF. If the request came directly from a trusted AF, the SenF responds directly to the AF.
• gNB Discovery or Re-selection: The SenF performs discovery and possibly re-selection of gNBs. This is needed when the modified sensing request changes the target area, reporting behavior, required performance, or sensing configuration enough that the previously selected gNBs may no longer be suitable.
• Interaction with gNBs: The SenF interacts with the selected gNBs to apply the modified sensing operation. At the RAN-CN level, this corresponds to the SenF requesting the gNB to change a previously configured sensing measurement, using a sensing measurement ID and the sensing parameters to be modified.
• gNB Response to Modification: After receiving the modification request, the gNB confirms whether the modification has been accepted. If it cannot accept the modification, it sends a sensing modification failure indication instead.
• Sensing Result Generation: After the updated sensing operation is applied, the SenF generates the sensing result based on the received sensing data.
• Result Notification through NEF: If the request path used the NEF, the SenF sends `Nsenf_SensingService_Notify` to the NEF, and the NEF sends `Nnef_SensingService_Notify` to the AF.
• Direct Result Notification: If the AF is inside the trusted domain and directly interacts with the SenF, the SenF can send `Nsenf_SensingService_Notify` directly to the AF.

Key Interpretation: This procedure allows an ongoing sensing service to be adjusted after establishment. The AF may request the change, or the SenF may initiate it based on sensing results or network-side conditions. The SenF remains the control point that authorizes the change, re-selects gNBs if needed, updates the radio sensing operation, and reports the resulting sensing information back to the AF.

Sensing Service Unsubscription

The Sensing Service Un-Subscription procedure describes how an ongoing sensing service is terminated and how the related network and radio resources are released. Unlike the initial establishment procedure, the termination does not have to come only from the AF. It may be initiated by the AF when the application no longer needs the sensing service, by the SenF when the network decides to stop the service, or by the gNB when the radio-side sensing operation can no longer continue.

If the un-subscription is triggered by the AF, the request follows the same service exposure path used during establishment. An external AF sends the unsubscribe request through the NEF, while a trusted-domain AF may send it directly to the SenF. The SenF then determines whether the associated sensing resources should be released, interacts with the involved gNBs if radio-side sensing needs to be stopped, notifies the AF or NEF about the termination, and finally deletes or releases the subscription context.

In short, this procedure is the cleanup and release phase of the sensing service lifecycle. It makes sure that the AF subscription, SenF service context, and gNB sensing operation are all terminated in a controlled way, instead of leaving sensing resources active after the service is no longer needed.

< 23.137-Figure 6.2.3-1: Sensing service un-subscription procedure  >

• Trigger Point: The un-subscription procedure can be triggered by three different entities: AF, SenF, or gNB. This is different from the establishment procedure, which is mainly service-request driven by the AF. Here, termination may happen because the application no longer needs the sensing service, the SenF decides to stop it, or the gNB can no longer continue the sensing operation.
• AF-Initiated Release: If the AF triggers the release, the AF sends an unsubscribe request. For an external AF, the request goes through the NEF using `Nnef_SensingService_Unsubscribe`. For a trusted-domain AF, the request can go directly to the SenF using `Nsenf_SensingService_Unsubscribe`.
• NEF-Mediated Unsubscribe: When the AF is outside the trusted domain, the NEF receives the unsubscribe request and forwards the corresponding `Nsenf_SensingService_Unsubscribe` request to the SenF. The NEF is still acting as the controlled exposure point between the external AF and the internal sensing service function.
• Direct AF-to-SenF Unsubscribe: If the AF is inside the trusted operator domain, the NEF path is skipped. The AF sends the `Nsenf_SensingService_Unsubscribe` request directly to the SenF.
• SenF-Initiated Release: If the release is triggered by the SenF, the SenF does not need to receive an unsubscribe request from the AF first. This may happen when the SenF determines that the sensing service should be stopped, for example due to policy, authorization revocation, sensing service condition, or internal service control decision.
• gNB-Initiated Release: If the release is triggered by the gNB, it means the radio-side sensing entity is indicating that the ongoing sensing operation should be terminated or cannot continue. In the diagram, this is shown as trigger 0c from the gNB side.
• Unsubscribe Response: After the unsubscribe request is handled, the SenF sends an unsubscribe response. If the request came through NEF, the SenF responds to the NEF and the NEF forwards the response to the AF. If the request came directly from a trusted AF, the SenF responds directly to the AF.
• Resource Release Decision: After the un-subscription handling, the SenF determines whether the sensing-related resources should be released. This includes the service context in the SenF and any sensing operation resources associated with the selected gNBs.
• Interaction with gNBs: If radio-side resources need to be released, the SenF interacts with the involved gNB or gNBs. This step stops the corresponding sensing operation at the RAN side and releases the sensing resources associated with that service.
• Termination Notification via NEF: If the external AF path is used, the SenF sends `Nsenf_SensingService_Notify` to the NEF, and the NEF sends `Nnef_SensingService_Notify` to the AF. The NEF notify operation can report sensing result or service termination to the consumer.
• Direct Termination Notification: If the trusted-domain AF path is used, the SenF can send `Nsenf_SensingService_Notify` directly to the AF to indicate the termination or final status of the sensing service.
• Subscription Context Cleanup: After the release and notification steps, the SenF deletes or releases the subscription context. This is the final cleanup step so that the network does not keep unnecessary sensing service state after the sensing service has ended.
• Key Interpretation: This procedure is the controlled termination phase of the ISAC service lifecycle. It makes sure that the AF subscription, SenF service context, and gNB radio sensing resources are all released consistently, regardless of whether the termination was initiated by the AF, SenF, or gNB.

Major Research Challenges

ISAC is attractive because it tries to extract sensing information from a radio network that already exists for communication. However, this also makes the problem much more difficult than simply adding a radar function to a base station. A communication receiver mainly tries to recover the transmitted data, while an ISAC receiver must often detect weak reflections, estimate physical parameters, separate useful target echoes from clutter, and still preserve normal communication performance. These two objectives share the same radio resources, hardware, and propagation environment, so many new design problems appear.

One of the first challenges is dynamic range. In monostatic sensing, the same node transmits the signal and receives the echo, so the receiver may have to detect a very weak target reflection while the transmitter leakage, direct coupling, and nearby static reflections are much stronger. Even when the receiver is not saturated, the weak target echo can be hidden under stronger unwanted components. This is why self-interference cancellation, RF isolation, calibration, and clutter suppression become very important.

Another major challenge is the interpretation of multipath. In communication, multipath is usually treated as a channel effect to be estimated and compensated. In sensing, some multipath components are useful because they contain information about objects and geometry, but other components from walls, ground, vegetation, vehicles, and static structures may look similar to target reflections. The system has to decide which part of the received signal corresponds to the object of interest and which part is only background clutter. This becomes especially difficult in dense urban, indoor, factory, or road environments.

Channel modeling is also more complicated for ISAC. A conventional communication channel model mainly describes the link between transmitter and receiver. For sensing, the model also has to consider target reflectivity, object size, shape, material, orientation, motion, blockage, and bistatic or multistatic geometry. A model that is good enough for link-level throughput simulation may not be enough to evaluate detection probability, false alarm rate, range accuracy, angle accuracy, or tracking stability. This is why ISAC needs channel models and evaluation methods that connect radio propagation with physical objects and sensing tasks.

Distributed sensing creates another layer of difficulty. If multiple base stations, UEs, or sensing nodes cooperate, their timing, frequency, phase, location, and calibration errors can directly affect the sensing result. Non-coherent cooperation may be more tolerant, but coherent processing can require much stricter synchronization. At the same time, the network has to allocate resources across ordinary communication users and sensing tasks without creating unacceptable interference, latency, or capacity loss. Therefore, ISAC resource allocation is not only a scheduler problem, but also a joint optimization problem across communication, sensing, synchronization, transport, and processing.

Waveform and hardware limitations are also important. A waveform that is efficient for communication may not have ideal ambiguity properties for sensing, and a waveform that is good for sensing may create overhead or compatibility problems for communication. Hardware impairments such as phase noise, power-amplifier nonlinearity, antenna coupling, quantization, beam squint, and imperfect calibration can create false targets or biased estimates. These effects may be small enough for communication demodulation but still serious for precise sensing.

Finally, ISAC needs reliable AI/ML and clear evaluation methodology. AI/ML may help with detection, classification, tracking, and fusion, but learned models can be sensitive to deployment changes, incomplete training data, domain mismatch, or intentional manipulation. For safety-related applications, the system must know not only the estimated result but also the confidence, failure condition, and boundary of validity. In addition, communication KPIs such as throughput, latency, and BLER are not enough to evaluate ISAC. The evaluation should also include probability of detection, false-alarm rate, range/velocity/angle accuracy, resolution, update rate, sensing service range, privacy impact, and end-to-end latency. This is why ISAC research has to cover radio design, signal processing, hardware, architecture, AI reliability, and service-level evaluation together.

• Self-interference and dynamic range : In monostatic operation, the receiver must find weak reflections while its own transmitter and nearby static objects can produce much stronger signals.
• Clutter and multipath interpretation : Reflections that complicate communication can contain useful sensing information, but separating target echoes from walls, ground, vegetation, and other objects is difficult.
• ISAC channel models : A communication channel model focuses mainly on the link between transmitter and receiver. Sensing also needs target reflectivity, object dimensions, material, orientation, motion, and bistatic or multistatic geometry. ETSI GR ISC 002 addresses these modelling and evaluation gaps.
• Distributed synchronization : Cooperative sensing requires precise timing and frequency alignment, and some coherent techniques also require phase synchronization across nodes.
• Waveform and frame design : The design should balance data transmission, ambiguity properties, peak-to-average power ratio, hardware constraints, sensing coverage, and backward compatibility.
• Hardware impairments : Phase noise, power-amplifier nonlinearity, antenna coupling, quantization, beam squint, and imperfect calibration can create false targets or bias estimates.
• Resource allocation : The network has to schedule communication and sensing across cells and operators without generating unacceptable interference or starving either service.
• AI/ML reliability : Learned detection and classification can be sensitive to deployment changes, incomplete training data, adversarial manipulation, and domain mismatch. Confidence and failure behavior are important for safety-related applications.
• Evaluation methodology : Communication KPIs such as throughput and BLER are not enough. ISAC evaluation also needs probability of detection, false-alarm rate, range/velocity/angle accuracy, resolution, sensing service range, update rate, and end-to-end latency.

Security, Privacy, Trustworthiness and Sustainability

Security and privacy become much more important in ISAC because sensing changes what a mobile network is able to observe. In conventional communication, the network mainly protects subscribers, devices, signaling messages, user traffic, and service access. In ISAC, the network may also detect objects, vehicles, movements, occupancy, or even human activity in the surrounding environment. Some of these sensed targets may not be connected to the network and may have no direct relationship with the operator. Therefore, ISAC cannot treat security and privacy as a small application-layer issue added at the end. They have to be part of the sensing service design from the beginning.

The first requirement is authorization and purpose limitation. A sensing client should not be allowed to request arbitrary sensing anywhere, at any resolution, for any duration. The system should check who is requesting the sensing task, what area is involved, what target class is being sensed, what resolution is needed, how long the task will run, and whether the declared purpose is allowed. This is important because sensing capability can become intrusive if it is too fine, too frequent, or applied to an inappropriate area.

The sensing data itself also needs protection. A sensing request, raw measurement, processed feature, map, object track, or final exposed result may all reveal sensitive information. For this reason, confidentiality and integrity are needed not only during transport, but also during processing, storage, logging, and result exposure. The network should also protect the sensing operation against signal-level attacks. An attacker may try to inject, replay, jam, spoof, or manipulate radio signals in order to hide a real target, create a false target, distort a position estimate, or corrupt a classification result.

Data minimization is another important principle. The application should receive only the result and precision that it actually needs. For example, an application may only need to know whether an area is occupied, not the detailed motion trace of each person. A traffic application may need vehicle flow information, not long-term identity-like movement histories. Raw sensing data and long-term sensing records should not be retained without a justified reason. This reduces privacy risk and also reduces storage and processing burden.

Transparency and accountability are also required because sensing can affect people and places outside the traditional subscriber relationship. The operator may need mechanisms to record who requested sensing, where it was performed, what information was produced, how it was exposed, and how long it was retained. This kind of auditability is important for trust, regulation, dispute handling, and commercial service management.

Sustainability is another practical concern. ISAC may reuse deployed base station sites, antennas, RF chains, power, transport, and edge computing resources, which can avoid building a completely separate sensing network. However, sensing is not free. Continuous illumination, wideband sampling, high-resolution processing, multi-node cooperation, storage, and AI/ML inference can consume significant energy and computing resources. Therefore, sensing should be activated, scaled, and stopped according to actual service need. A trustworthy ISAC system should not only sense accurately, but also sense with proper authorization, controlled exposure, clear accountability, and reasonable energy consumption.

• Authorization and purpose limitation : A sensing client should be allowed to request only an approved sensing area, resolution, duration, target class, and purpose.
• Confidentiality and integrity : Sensing requests, measurements, maps, target tracks, and exposed results require protection in transport, processing, storage, and audit logs.
• Signal-level attacks : An attacker may inject, replay, jam, or manipulate radio signals to hide a target, create a ghost target, or corrupt an estimate.
• Data minimization : The application should receive only the result and precision necessary for its function. Raw data and long-term histories should not be retained without a justified need.
• Transparency and accountability : Operators need mechanisms to record who requested sensing, where it was performed, what information was produced, and how it was used.
• Sustainability : Reusing deployed sites and hardware can avoid a separate sensor network, but continuous illumination, wideband sampling, computing, and storage can consume substantial energy. Sensing should be activated and scaled according to service need.

ETSI GR ISC 004 organizes these concerns into security, privacy, trustworthiness, and sustainability issues and identifies potential requirements for future 6G systems.

Standardization Status

ISAC is an active research and pre-standardization area, and it is important not to describe every proposed architecture or waveform as an agreed 6G solution. As of mid-2026, the main activities can be summarized as follows.

• ITU-R : Recommendation ITU-R M.2160 identifies ISAC as one of the six IMT-2030 usage scenarios. ITU-R WP 5D is developing the technical performance requirements and evaluation process for candidate IMT-2030 radio interfaces.
• 3GPP Release 19 : TS 22.137 specifies Stage 1 service requirements for Integrated Sensing and Communication. Release 19 also introduced ISAC channel modelling into TR 38.901. This work establishes requirements and evaluation foundations rather than a complete radio and system implementation.
• 3GPP Release 20 : Work includes the draft Stage 2 architecture specification TS 23.137 and the RAN study TR 38.765 for ISAC in NR. This represents an initial, scoped step toward standardized sensing capabilities while broader 6G studies proceed.
• ETSI ISG ISAC : ETSI has published reports on use cases and deployment scenarios (GR ISC 001), channel modelling and evaluation (GR ISC 002), system and RAN architectures (GR ISC 003), and security, privacy, trustworthiness, and sustainability (GR ISC 004). These reports provide pre-standardization input to organizations such as 3GPP.

Reference

• Framework and overall objectives of the future development of IMT for 2030 and beyond (Recommendation ITU-R M.2160) - ITU-R, Nov 2023
• 3GPP TS 22.137: Integrated Sensing and Communication - 3GPP
• 3GPP TS 23.137: Integrated Sensing and Communication; Stage 2 - 3GPP
• 3GPP TR 38.765: Study on Integrated Sensing And Communication (ISAC) for NR - 3GPP
• ETSI GR ISC 001: Use Cases and Deployment Scenarios - Mar 2025
• ETSI GR ISC 002: Channel Modelling, Measurements and Evaluation Methodology - Aug 2025
• ETSI GR ISC 003: System and RAN Architectures - Feb 2026
• ETSI GR ISC 004: Security, Privacy, Trustworthiness and Sustainability - Feb 2026
• Integrated Sensing and Communication (ISAC) - Ericsson
• Transforming Industries with Integrated Sensing and Communication - 5G Americas
• ETSI issues new Report on Security, Privacy, Trustworthiness and Sustainability for 6G Integrated Sensing and Communications - Mar 2026
• ETSI accelerates next-generation 6G technology with new ISAC work items - Dec 2025
• ETSI ISAC industry specification group sets strategic direction for 6G with renewed leadership  - Oct 2025
• ETSI publishes first Report on ISAC Use Cases for 6G  - Apr 2025

YouTube/Other Videos

• Integrated sensing and communication (ISAC) from 5G-advanced to 6G - R&S
• Lecture 1 Introduction to ISAC by Prof Fan Liu | Fundamentals of Integrated Sensing & Communications - chaspark (Sep 2025)
• Introduction to Integrated Sensing and Communication (ISAC) - Wireless Future (Feb 2026)
• Ep 47. Everyone Talks About Integrated Sensing and Communications [Wireless Future Podcast] - Wireless Future (Feb 2026)
• Integrated Sensing and Comms (ISAC) with MATLAB and SDR - MATLAB (Jul 2026)
• Shorts/Demos
• Huawei 6G demo ISAC-OW - one6G summit - one6G Association (Jan 2022)
• Keysight Demonstrates Joint Communications and Sensing for 6G - Microwave Journal (Oct 2024)
• Sensing-enhanced communications - Qualcomm (Feb 2025)
• Integrated Sensing and Communication - Interdigital (Mar 2025)
• Indoor 5G Sensing including GITEX Global Demo - Tiami Networks (Dec 2025)
• ISAC Drone & People Tracking (Tiami Keysight Vodafone) - AI RAN Alliance (Feb 2026)
• 5G ISAC Spatial Intelligence - BubbleRAN (Jun 2026)
• Towards 6G: integrated sensing and communication (ISAC) - R&S