Sensing in 6G: Use cases and architecture

Wireless sensing is a technology that enables a mobile system to acquire information about characteristics of an environment and/or objects within that environment. A key advantage of wireless sensing is the ability to observe the environment without requiring the objects in the environment to participate in the process by, for example, carrying user equipment (UE) that can connect to a mobile network.

When sensing is integrated into a communication system such as a mobile system, it is known as integrated sensing and communication (ISAC). Sensing in a mobile system relies on radio frequency (RF) to detect objects and determine object characteristics such as distance (range), angle, velocity and shape [1]. 3GPP (3rd Generation Partnership Project) is currently studying how to include initial sensing capabilities for a limited number of use cases in 5G Advanced, while the plans for 6G encompass the full power of integrated sensing for a much wider range of use cases. There are significant market opportunities for wireless sensing, most notably for applications such as:

• ensuring public safety by, for example, detecting and tracking drones
• monitoring automated guided vehicles and ensuring collision avoidance
• improving communication by, for example, tracking signal-blocking objects.

To enable communication service providers (CSPs) to monetize these new uses cases, the future mobile system must have new functionalities in both the radio access network (RAN) and the core network, as well as new exposure functionality. To address these needs, Ericsson has developed a novel end-to-end (E2E) architecture for 6G sensing.

Examples of sensing use cases

Sensing use cases have great potential to deliver benefits for consumers, enterprises and governments (especially public safety organizations such as fire and police departments).Some sensing use cases are internal to networks – aimed at optimizing network performance through communication improvements or using sensing to further improve the accuracy of UE positioning services, for example. Most sensing use cases are external to networks, however, consisting of diverse applications that benefit from sensing information in various ways. Some external use cases consist merely of simple alarms that go off when a given condition is detected (movement in a given area, for example), while others involve more complex processing, such as the trajectories of vehicles, object classification, map creation and so on.

Standardized mechanisms are needed for the network and the application to set up the sensing process and use an application programming interface (API) to provide the results to the application. Sensing may also be combined with other services. For example, sensing can be combined with positioning, SIM (subscriber identity module) density and other types of information for the benefit of applications that require comprehensive situational awareness.

Figure 1 illustrates the main types of capabilities under discussion for sensing, including the ability to detect objects and sense properties such as weather phenomena. The most obvious capability is detecting moving objects (A in Figure 1) through radio-based sensing mechanisms such as Doppler analysis and similar techniques. A prime example of a use case enabled by this capability is the detection of drones that may not be collaborative and adhere to drone identification practices. This can be of great value in the protection of no-fly zones such as airports or stadiums.

Figure 1: Sensing capability categories

Using mobile networks for drone detection is beneficial due to the broad reach of networks, making the technique a good complement to other detection mechanisms. Networks can also be useful in assisting drones and other unmanned aerial vehicles with collision avoidance. Ground-based examples of moving object use cases include counting or statistical analysis of people and vehicle movements, monitoring roads and train tracks, and intruder detection.

Sensing can also be used to map and understand changes in the environment (B in Figure 1). For example, it can be used to complement existing maps with updated real-time information for immersive experiences, to improve navigation, or to detect flooding and other potentially dangerous environmental conditions.

It is also possible to use sensing to detect properties that are not associated with physical objects. By observing the propagation properties of radio waves (C in Figure 1), rain and other weather phenomena can be detected, for example. The use of sensing to measure air quality is under discussion as well.

Sensing can also be used to analyze the radio environment (D in Figure 1). The communication improvements mentioned earlier were one example of this, but the same capability could be used for detecting interference for spectrum sharing and other purposes. Sensing is also closely related to the emerging ability of networks to detect threats such as jamming and false base stations. This becomes particularly useful when considering broader situational awareness by CSPs to further improve the overall condition of their networks.

New functionalities required for sensing

To support a sensing service offered by a mobile network, sensing-capable base stations with new sensing functionalities and new sensing network functions will be required. These functions include workflow handling, controlling and performing sensing measurements, processing sensing data and delivering the obtained results. In addition, network exposure needs to be enhanced for sensing. Figure 2 illustrates the E2E control and data flows for sensing.

Figure 2: Control and data flows related to the high-level functionalities for sensing

A sensing client (on the right) initiates a sensing service. The sensing request from the client, received by network exposure, always relates to a particular area where the sensing is requested to be performed (the requested sensing area). A requested sensing area can be explicitly specified (with geo-coordinates, for example) or indirectly referenced. An example of the latter is “sense around me” type applications such as collision warning for a moving vehicle that needs information about its current surroundings. Such arrangements also need some kind of tie-in to positioning mechanisms either within the network or elsewhere.

The sensing workflow

Once the network exposure functionality has authorized the sensing request invoker, a workflow will be set up for the actions required to fulfill the request. The sensing workflow will include the initiation of one or more sensing measurements. Each of these sensing measurements is for a subset of the target area received from the sensing client – that is, the requested sensing area needs to be mapped to the target sensing areas for each of the sensing measurements. Furthermore, adjustment and coordination of the workflow may be required. For example, new sensing measurements may need to be initiated in the same target sensing area or in a new one due to the movement of a tracked object toward the border of the target sensing area of that sensing measurement. In general, it is vital to ensure that the received sensing measurement results are connected to the correct sensing request. Workflow management is dependent on appropriate and timely feedback from sensing processing to adapt the sensing workflow to the original sensing request from the sensing client/application.

Controlling and performing sensing measurements

Once the target sensing areas have been identified, base stations that can cover them are selected and requests to perform a sensing measurement are sent to those base stations. The selected sensing-capable base stations subsequently configure the respective sensing measurements, including the frequency, time and beam selection for the measurements, as well as optional muting of neighboring base stations that are not executing the sensing measurements. This configuration therefore requires coordination with the handling of radio scheduling of communication resources in the respective base stations. The base station selected for the sensing measurement is responsible for the coordination of the radio resources to be used among multiple base stations. Furthermore, the necessary sensing processing capabilities must be secured and configured to suit the sensing workflow and its measurements, while taking into account other sensing measurements that are being executed in parallel.

Sensing processing

Sensing processing occurs stepwise, refining the raw data resulting from the sensing measurements performed by the base station into useful results that can be exposed to the client/application requesting the sensing service. Sensing processing passes through multiple steps from the raw IQ samples via radar cubes, object detection and localization, applying potential privacy-protecting processing and so on. Depending on the use case, this may include combining multiple sensing measurements into refined results that may require different types of processing to suit the needs of different applications.

Our end-to-end sensing architecture proposal

To ensure optimal radio resource utilization, we propose that sensing measurements are both executed and handled in the RAN. An additional benefit of this approach is that it ensures the availability of RAN internal processing resources to handle the sensing measurements. The logical placement of sensing workflow handling and exposure is outside the RAN in the sensing part of the core network.

In our E2E sensing architecture, shown in Figure 3, we denote the sensing workflow and the applicable parts of sensing processing as core functionalities for sensing, or simply sensing core functionalities. These functions must handle policies related to the external sensing request (allowed areas, privacy policies and so on) when initiating a sensing measurement throughout workflow handling.

Figure 3: End-to-end sensing architecture including management, exposure and business support system

Sensing workflow handling also includes setting up the necessary processing resources in the sensing core and configuring them for relevant use-case-related processing. To the extent possible, exposure should occur according to the existing exposure frameworks (API handling) and authorization functionalities, but extended capabilities may also be required for purposes such as discovering suitable sensing functions for the requested sensing area.

It is reasonable for a sensing-capable base station to both process raw radio measurements as well as to process them into radar cubes, peak detection and so on, as this approach significantly reduces the amount of sensing data that needs to be sent further. A sensing-capable base station may also collect sensing measurements from neighboring base stations and combine them before sending sensing data further to the core.

Under certain circumstances, such as when the sensing workflow requests sensing measurements from more than one base station, the sensing core functionalities may receive sensing measurement data from multiple sensing base stations. In these cases, the sensing core functionalities can refine the measurement results and modify the sensing data into something that matches the request by the sensing client. The sensing client may also perform additional processing steps, such as data fusion with network-external data or processing for the display of detected objects. Overall, our proposed architecture is flexible regarding where to place a particular processing step.

If UE that can support sensing is present in the target sensing area, it can assist in the execution of a sensing measurement. A base station could identify assisting UE and configure them for sensing. The measurement data collected by an assisting UE would need to be preprocessed in the UE to reduce the amount of data sent over the radio interface.

How to monetize sensing capabilities

Sensing capabilities have the potential to deliver significant new revenue streams for CSPs. To explore these opportunities across the full range of potential use cases, there is a need for flexibility in the exposure architecture and the business support system for different business models.

Service exposure framework capabilities

A CSP can offer a sensing service to an application in multiple ways based on the needs of the application. This could be in the form of a request for a single sensing result in a specific area, an event-triggered sensing result or a continuous stream of sensing results. A sensing client (the consumer of the sensing results) is connected to the mobile network via an API that exposes the sensing service. The service exposure functionalities include receiving requests from clients/applications, authenticating and authorizing the requests, applying policies (privacy, client-specific policies and so on), and sending the message with the requested sensing area to the sensing workflow function for execution, via the network exposure function. Finally, service exposure is responsible for delivering the sensing results to the sensing client.

In practice, different exposure APIs may be needed to serve various application needs. The API gateway is responsible for exposing the different APIs and acting as an enforcement point for access control and throttling, as well as serving as the integration point with the other service exposure functions. Access controls and other security mechanisms are necessary to ensure that sensitive sensing information is only provided to authorized receivers. In addition, there is a need for privacy management.

The existing service exposure framework, including API management, usage control and monitoring, is the logical starting point to support sensing service exposure, both for the sake of reusing the existing exposure architecture and ecosystem efficiently and ensuring the ability to charge properly for the usage of the sensing services [2].

The sensing service also places new requirements on the exposure function. Specifically, the sensing service requires the ability to request sensing for a certain area, and it may also demand an exposure solution with particular attention to capacity. In the latter case, this is because the throughput of the exposed streaming data can be significant depending on the use case and the offered sensing service.

Business support system capabilities

The sensing service also requires functionality to manage business relationships with partners and the integration of add-on services specific to the sensing use cases. An example of this would be interaction with a system integrator with expertise in a certain vertical, adding additional services or insights to the basic sensing service. The capabilities to manage partners and monetize the sensing service are labeled party management and commerce management [2] as defined by TM Forum’s Open Digital Architecture.

Another example of a business relationship would be integration with an aggregator to increase the reach of the sensing area beyond a single CSP’s network. The aggregator is situated between the CSP’s service exposure and the sensing client itself, aggregating APIs from multiple CSPs. This could be the case when the area of interest of the sensing use case is covered by more than one public land mobile network in one or multiple countries. This aggregator model could build on the ongoing work of API specifications in industry forums like CAMARA [3].

Management capabilities

Efficient management of the large amount of data that the sensing service produces in the network is of critical importance. As explained earlier, the sensing measurement data generated by the base stations is refined in a stepwise manner by the sensing processing functionality in the RAN and in the sensing core.

For each step, there can be benefits to storing data such as radar cubes or intermediate sensing results for later use during sensing processing. Data management includes aspects such as data life-cycle management, data authorization and access control.

Finally, the new sensing functionalities in the RAN and the sensing core need to be managed in the same way as any other network function in the mobile network, including software life-cycle management. The ability to deploy the sensing functionality in a flexible manner to support the requested sensing area with adequate performance of the deployed sensing solution is key, as is the ability to monitor the deployed sensing system to meet associated sensing service level agreements and ensure a reliable sensing service.

Conclusion

Sensing represents one of the most transformative emerging capabilities on the path from 5G Advanced to 6G. By extending the role of radio waves beyond communication into environmental awareness, mobile networks can deliver entirely new classes of services from drone detection and collision avoidance to enhanced public safety and richer immersive experiences. Realizing this vision requires new functionalities across the radio access network, core and exposure layers, supported by flexible workflows, robust privacy safeguards and business models that enable monetization from the outset.

While 5G Advanced will introduce the first standardized sensing features, it is in 6G that integrated sensing and communication will reach its full potential. For communication service providers, this evolution offers not only a chance to strengthen network intelligence and resilience, but also to open up new revenue streams and societal value. With the right architecture and ecosystem collaboration, sensing in 6G will become a foundation for smarter, safer and more connected environments.