Sensing architecture

Abstract

The present disclosure provides a system of one or more servers for handling sensing jobs for a sensing client. The system includes a core network and an access network communicating with external sensing clients. The system includes a Sensing Core Controller (SCC) in the core network for handling sensing request for sensing task. The SCC is configured to receive sensing request to perform sensing job originated by sensing client via an exposure platform, provide sensing results towards the sensing client or instruct a core network Sensing Processing Function (SPF) to provide the sensing results towards the sensing client, assign Internal Transaction ID to sensing request making it possible to align the requested sensing job with the sensing result, configure a Sensing Processing Function in the core network, and interact with sensing radio access network (RAN) controller to setup sensing measurement based on the sensing requests. The system includes a Sensing Processing Function (SPF) in the core network configured to receive sensing data from RAN SPF, process the received sensing data and convert into sensing result to be transmitted towards the consumer, and receive processing measurement for the sensing task from the SCC in the core network.

Description

P113409W0011SENSING ARCHITECTURECROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application No. 63 / 779978, titled Sensing architecture, filed 28th March 2025, which is hereby incorporated by reference in its entirety.TECHNICAL FIELD

[0002] The present disclosure relates to systems and methods for handling sensing jobs in cellular communications networks, and more particularly to a sensing architecture comprising a Sensing Core Controller and Sensing Processing Function for managing sensing requests and processing sensing data in core networks.BACKGROUND

[0003] Integrated Sensing and Communication (ISAC), also referred to as Joint Communication and Sensing (JCAS), is a technology that integrates sensing and spatial location of passive (not connected) objects into the mobile communication network, expanding the network's functionality beyond just communication. Reusing most of the network equipment deployed for communication can enable a smooth introduction of ISAC.

[0004] The standardization body 3GPP has also taken the initial steps toward standardization of ISAC - notably, the 3GPP technical specification group “Service and System Aspects” released a technical report TR 22.837 on use cases and requirements in their Release 19.

[0005] The sensing architecture is however not yet defined in 3GPP but discussed in prestandard meetings. There are quite many sensing use cases that require besides functionality in RAN also functionality that is better placed in core network (called sensing core in this document), especially the workflow management and the interaction of the core network functionality with one or more base stations. Therefore, it is an object of this disclosure to provide a sensing architecture that enables integrated sensing and communication capabilities in cellular networks.P113409W0012SUMMARY

[0006] A summary of aspects of certain examples disclosed herein is set forth below. It should be understood that these aspects are presented merely to provide the reader with a brief summary of these certain embodiments and that these aspects are not intended to limit the scope of this disclosure. Indeed, this disclosure may encompass a variety of aspects and / or a combination of aspects that may not be set forth.

[0007] In one aspect, a system of one or more servers for handling sensing jobs or tasks for a sensing client is provided. The system comprises a core network and an access network communicating with external sensing clients. The system comprises a Sensing Core Controller (SCC) in the core network for handling sensing request for a sensing task, the SCC configured to receive sensing request to perform sensing job / task originated by sensing client via an exposure platform, provide sensing results towards the sensing client or instruct a core network Sensing Processing Function (SPF) to provide the sensing results towards the sensing client, assign Internal Transaction ID to sensing request, making it possible to align the requested sensing job / task with the sensing result, configure a Sensing Processing Function in the core network, and interact with sensing radio access network (RAN) controller to setup sensing measurement based on the sensing requests. The system further comprises a Sensing Processing Function (SPF) in the core network configured to receive sensing data from RAN SPF, process the received sensing data and convert into sensing result to be transmitted towards the consumer, and receive processing measurement for the sensing task from the SCC in the core network.

[0008] In another aspect, a method performed by a core network controller function is provided. The method comprises receiving from an exposure platform a sensing request for a sensing job / task originated from a sensing client, creating an internal transaction id for the sensing job / task and providing it in a response to the exposure function, and initiating sensing measurement configuration in Radio Access Network Sensing Unit Controller (RAN SUC) and sensing measurement processing configuration in a sensing processing function in the core network.

[0009] In yet another aspect, a method performed by an exposure platform is provided. The method comprises receiving from an Application Function a sensing request for a sensing task, the sensing request comprising a sensing type, assigning an external transaction ID forP113409W0013the request, sending a second sensing request based on the received sensing request to a sensing request handler (SRH) in a sensing core controller (SCC) in a core network, the second sensing request comprising the sensing type and a source URI to be used for receiving sensing results from a Sensing Processing Function in the core network, obtaining from the SRH a first response comprising an internal transaction ID, mapping the internal transaction ID to the external transaction ID, and sending to the AF a second response comprising the external transaction ID.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0011] Figure 1 illustrates one example of a cellular communications system 100 in which embodiments of the present disclosure may be implemented;

[0012] Figures 2 and 3 illustrate example embodiments of the cellular communication system of Figure 1;

[0013] Figure 4 and 5 illustrate examples of sensing use cases;

[0014] Figures 6a-6c illustrate different sensing methods;

[0015] Figure 7 illustrates a proposed end to end architecture for sensing including the SCC functionality in the core network in accordance with embodiments herein;

[0016] Figure 8 illustrates an end to end control and data flow of sensing using the sensing architecture of Figure 7 according to embodiments of the present disclosure; it further illustrates a more detailed flow diagram of the end to end control and data flow in accordance with some embodiments;

[0017] Figures 9a and 9b illustrate the different identifiers used in the end to end data and control flows in accordance with some embodiments;

[0018] Figure 10 illustrates a more detailed flow diagram of the service exposure in support of the end to end control and data flow of Figures 8 in accordance with embodiments herein;P113409W0014

[0019] Figure Ila) to 11c) illustrates examples of Target sensing area assigned by SCC according to embodiments of the present disclosure;

[0020] Figure 12 illustrates interaction between SCC functionalities and the 6G-RAN when a primary and secondary SUC is used according to embodiments of the present disclosure;

[0021] Figure 13 illustrates the different sensing area topologies according to the embodiments herein;

[0022] Figure 14 illustrates a flow diagram of area mapping based on deployment time alternative, i.e. areas are defined at deployment time in accordance with embodiments herein;

[0023] Figure 15 illustrates the result of the area mapping deployment of Figure 14 in accordance with the embodiments herein;

[0024] Figure 16 illustrates a flow diagram of a procedure using area definitions in run time in accordance with some embodiments herein;

[0025] Figure 17 illustrates the result of the procedure of Figure 16 in accordance with the embodiments herein;

[0026] Figure 18 illustrate flow diagram corresponding to the embodiment of Figure 16 in a different representation;

[0027] Figures 19a, 19b, 20 and 21 are schematic block diagrams of example embodiments of a network node;

[0028] Figures 22 and 23 are schematic block diagrams of example embodiments of a wireless device.

[0029] The figures are intended for illustrative purposes only, and do not serve as restriction of the scope of the protection as laid down by the claims.DETAILED DESCRIPTION

[0030] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these conceptsP113409W0015and applications fall within the scope of the disclosure. Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0031] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features, and advantages of the enclosed embodiments will be apparent from the following description.

[0032] Radio Node: As used herein, a “radio node” is either a radio access node or a wireless communication device.

[0033] Radio Access Node: As used herein, a “radio access node” or “radio network node” or “radio access network node” is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and / or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3 GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pi co base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station (e.g., a network node that implements a gNB Central Unit (gNB-CU) or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.P113409W0016

[0034] Core Network Node: As used herein, a “core network node” is any type of node in a core network or any node that implements a core network function. The node can be a server or system of distributed servers. Some examples of a core network node in an exemplary 5G system include, e.g., an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), a Network Exposure Function (NEF). The Core network functions may be virtualized / containerized on a node, server, distributed servers, or implemented as a dedicated function on a dedicated physical node (compute, memory, and network). Other future core network functions in future core networks such as 6G and beyond are also applicable for this invention.

[0035] Communication Device: As used herein, a “communication device” is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and / or data via a wireless or wireline connection.

[0036] Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and / or data via a wireless connection.

[0037] Network Node: As used herein, a “network node” is any node that is either part of the RAN or the core network of a cellular communications network / system.P113409W0017

[0038] Note that the description given herein focuses on a 3 GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0039] Note that, in the description herein, reference may be made to the term “cell”; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

[0040] Figure 1 illustrates one example of a cellular communications system 100 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 100 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC); however, as indicated above the present disclosure is not limited thereto. In this example, the RAN includes base stations 102-1 and 102-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC), controlling corresponding (macro) cells 104-1 and 104-2. The base stations 102-1 and 102-2 are generally referred to herein collectively as base stations 102 and individually as base station 102. Likewise, the (macro) cells 104-1 and 104-2 are generally referred to herein collectively as (macro) cells 104 and individually as (macro) cell 104. The RAN may also include a number of low power nodes 106-1 through 106-4 controlling corresponding small cells 108-1 through 108-4. The low power nodes 106-1 through 106-4 can be small base stations (such as pico or femto base stations) or RRHs, or the like. Notably, while not illustrated, one or more of the small cells 108-1 through 108-4 may alternatively be provided by the base stations 102. The low power nodes 106-1 through 106-4 are generally referred to herein collectively as low power nodes 106 and individually as low power node 106. Likewise, the small cells 108-1 through 108-4 are generally referred to herein collectively as small cells 108 and individually as small cell 108.

[0041] In particular when the NG-RAN consists of gNBs (5G or beyond) connected to the 5GC through the NG interface, a gNB may further consist of a gNB-control unit (CU) and one or more gNB -Distribution Unit(s) (DU(s)). A gNB-CU and a gNB-DU is connected via Fl interface as illustrated in Figure 1 A.P113409W0018

[0042] The cellular communications system 100 also includes a core network 110, which in the 5G System (5GS) is referred to as the 5GC. The base stations 102 (and optionally the low power nodes 106) are connected to the core network 110.

[0043] The base stations 102 and the low power nodes 106 provide service to wireless communication devices 112-1 through 112-5 in the corresponding cells 104 and 108. The wireless communication devices 112-1 through 112-5 are generally referred to herein collectively as wireless communication devices 112 and individually as wireless communication device 112. In the following description, the wireless communication devices 112 are oftentimes UEs and as such sometimes referred to herein as UEs 112, but the present disclosure is not limited thereto.

[0044] Figure 2 illustrates a wireless communication system represented as a 5G network architecture composed of core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point / interface. Figure 2 can be viewed as one particular implementation of the system 100 of Figure 1. The embodiments in the reminder of these document are described within the context of 5G network architecture using the 5G terminology, but the embodiments are also applicable to other systems / networks using sensing and network exposure. Example of those systems / networks may be 6G systems / networks and beyond.

[0045] Seen from the access side the 5G network architecture shown in Figure 2 comprises a plurality of UEs 112 connected to either a RAN 102 or an Access Network (AN) as well as an AMF 200. Typically, the R(AN) 102 comprises base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5GC NFs shown in Figure 2 includes but not limited to AMF 200, a SMF 208, a PCF 210, NEF, UPF and an Application Function (AF) 212.

[0046] Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. For example, the N1 reference point is defined to carry signaling between the UE 112 and AMF 200. The reference points for connecting between the AN 102 and AMF 200 and between the AN 102 and UPF 214 are defined as N2 and N3, respectively. An AN 102 selects an AMF 200 to connect a UE to the core network in 5G. N4 is used by the SMF 208 and UPF 214 so that the UPF 214 can be set using the control signal generated by the SMF 208, and the UPF 214 can report its state to the SMF 208. N9 is the reference point for the connection between different UPFs 214, and N33P113409W0019is the reference point connecting between different external AFs and network exposure function (NEF).

[0047] The 5GC network aims at separating UP and CP. The UP carries user traffic while the CP carries signaling in the network. In Figure 2, the UPF 214 is in the UP and all other NFs, i.e., the AMF 200, SMF 208, NEF, and UDM 206, are in the CP. Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.

[0048] The 5G core network architecture is composed of modularized functions. For example, the AMF 200, SMF 208 and for example NEF are independent functions in the CP. Separated AMF 200 and SMF 208 allow independent evolution and scaling. Modularized function design enables the 5GC network to support various services flexibly.

[0049] Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the CP, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The UP supports interactions such as forwarding operations between different UPFs.

[0050] Figure 3 illustrates a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points / interfaces used in the 5G network architecture of Figure 2. However, the NFs described above with reference to Figure 2 correspond to the NFs shown in Figure 3. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In Figure 3 the service based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service based interface of the AMF 200 and Nsmf for the service based interface of the SMF 208, Nnef for service based interface exposing services of the 5GC through the NEF, etc. Any NFs depicted in Figure 2 can interact with the NEF 216 and / or NRF 218 of Figure 3 as necessary, though not explicitly indicated in Figure 2.

[0051] Some properties of the NFs shown in Figures 2 and 3 may be described in the following manner. The AMF 200 provides UE-based authentication, authorization, mobility management, etc. A UE 112 even using multiple access technologies is basically connected to a single AMF 200 because the AMF 200 is independent of the access technologies. The SMFP113409W00110208 is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF 214 for data transfer. If a UE 112 has multiple sessions, different SMFs 208 may be allocated to each session to manage them individually and possibly provide different functionalities per session. The Network Exposure Function (NEF) supports external exposure of capabilities of network functions. External exposure can be categorized as Monitoring capability, Provisioning capability, Policy / Charging capability, Analytics reporting capability and Member UE selection capability. The Data Network (DN), not part of the 5GC network, provides Internet access or operator services and similar.

[0052] An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

[0053] As stated in the introduction, there currently exist certain challenges for support of an end to end architecture for sensing. The sensing architecture is not yet defined in 3GPP but discussed in pre-standard meetings. There are quite many sensing use cases that require besides functionality in RAN also functionality that is better placed in core (called sensing core in this document), especially the workflow management and the interaction of the core functionality with one or more base stations.

[0054] In addition, in many of the use cases under discussion there need to be a mapping between areas used when requesting sensing (by an external or internal client) and the target sensing areas used for control purposes inside the network. The target sensing areas are expected to be Communication Service Provider CSP internal (could even be a 3 GPP-specific representation), and the area definitions that exist outside the CSP domain so that an external party can specify which area should be sensed e.g., for Geofencing. The latter area could be specified in a publicly available area format.

[0055] Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Embodiments of the solutions describe an end to end architecture by adding core network functionalities for supporting the end to end sensing flows and use cases. Such core network is also referred herein as Sensing Core (SC). For example, the interaction between Sensing Clients and Sensing RAN functionalities via Sensing Core Functionalities, requiring the Sensing Core to know, or be able to acquire knowledge of 5G or 6G-NBs (but not limited thereto) with sensing capabilities, e.g., from a registry. Note that in today’s mobile systems (such as 5G of Figure 2 and 3) the base station isP113409W00111configured with the address of the first node to contact in the core (i.e., AMF in 5GC, MME in EPC and SGSN / MSC in 2G / 3G). The Sensing Core also provides aggregation of results from multiple base stations and use case specific processing (which can require a lot of processing power) prior sending results to the Sensing Client. This avoids exposure use case specific processing in RAN. This would enable clear separation of RAN specific sensing functionalities and Sensing Core functionalities including workflow management provided by Sensing Core. Sensing Core is enabled to determine the base stations needed for each sensing task.

[0056] Figure 4 illustrates examples of sensing definition and categories of use cases for ISAC and shows different sensing scenarios in an exemplary urban environment 400, illustrating various applications for detecting physical objects and sensing non-physical properties across different environments including air, ground, and urban settings. The figure categorizes sensing capabilities into four main scenarios that demonstrate the breadth of ISAC applications.

[0057] The first group of scenarios relates to detecting physical objects. Scenario 401 focuses on detecting moving objects, which includes aerial applications such as drone detection and ground-based applications including people counting, train track monitoring, and intruder detection. Moving objects are easier to detect due to the Doppler effect, and detecting flying objects is generally easier due to less clutter in the air environment. Scenario 402 addresses mapping the local environment with applications including flooding detection, creation of digital twins of local environments, immersive experiences, and detection of structural damages. This scenario demonstrates how sensing can be used to create comprehensive environmental awareness and monitoring capabilities.

[0058] The second group of scenarios relates to sensing non-physical properties. Scenario 403 covers sensing propagation properties, including weather monitoring and air quality monitoring applications. These use cases leverage the sensing capabilities to detect environmental conditions that affect radio wave propagation. Scenario 404 focuses on detecting RF interference with applications for improving communication performance, threat detection such as jamming, and detection of interference for spectrum sharing purposes. This scenario highlights how sensing can enhance the communication system's own performance and security.

[0059] Figure 5 shows a list from the 3GPP technical report TR 22.837 which lists 32 potential use cases for ISAC. Among them are use cases related to uncrewed aerial vehiclesP113409W00112(UAVs), transportation, and industries. Figure 2 illustrates the 3GPP use cases as described in 3GPP TR 22.837.

[0060] Figure 6a) to Figure 6c) illustrates how sensing is performed. As described in https: / / www.ericsson.com / en / blog / 2024 / 6 / integrated-sensing-and-communication, herein reproduced.

[0061] As shown in Figure 6a, the traditional radar topology is monostatic where the same node is used as transmitter and receiver. Depending on the distance (delay) to the target, the sensing signal transmission might still be ongoing when the earliest echo arrives. In an ISAC system, it is typically desired to detect close targets. With a distance of 50 m, for example, to the target, the reflected signal arrives 333ns later. This can be compared with the OFDM symbol duration of 33 ps used in midband TDD deployments. The ongoing transmission creates strong self-interference during the reception of the weak target reflection. To cope with strong self-interference, the receiver must be capable of full-duplex operation, requiring complex radio and antenna solutions. Otherwise a blind zone the TX node may occur. Alternatively, a short sensing pulse combined with rapid transmit-receive switching ensures sensing signal transmission concludes before the target echo arrives. It is believed that both full-duplex and fast transmit-receive switches are more suitable for FR2 than FR1, making monostatic ISAC more attractive for FR2 than FR1.

[0062] Figure 6b shows a bistatic sensing system that avoids self-interference by using different nodes as transmitters and receivers. Accurate target location and velocity estimation require tight time synchronization and frequency synchronization between transmitter and receiver, typically much tighter than what is needed for communication. To avoid much tighter per-node synchronization than what is needed for communication, it is proposed to use over-the-air synchronization. The receiver listens to a signal received over a reference path (preferably an LoS or stable and well-characterized non-LoS path) and obtains synchronization from this signal. A similar method is radio-interface based synchronization, which is already used today to synchronize base stations over the air.

[0063] Figure 6c shows multistatic sensing is an extension to bistatic sensing which combines multiple bistatic sensing links.

[0064] Figure 7 illustrates a proposed architecture to support end to end sensing workflow in accordance with embodiments of this disclosure. Figure 7 describes the Sensing Core Functionalities and the interaction with 6G-RAN and especially a 6G-NB . While a 6G-NB isP113409W00113depicted here other options may also apply and it is not yet clear whether 3GPP specifications will include a 6G-NB as part of 6G-RAN. The architecture is equally applicable to 5G NG-RAN and gNB. The RAN functionalities is described in this document for completeness, the description of the RAN functionality is exemplary and not limited thereto, the new functionalities are depicted in the core or Sensing Core.

[0065] A serving 6G-NB and / or base station (BS) supports the assisting UEs involved in the sensing with connectivity, may also be involved in determining or verifying the physical location of assisting UEs. It is possibly involved in sensing measurement reporting from an assisting UE.

[0066] A Sensing Unit Controller, SUC, maintains a registry of SUs and BB SPFs under the control of the Sensing RAN controller. This includes the information whether a UE is willing and allowed to assist. It maintains registry of Sensing RAN controllers / SUCs, each controlling a neighboring sensing area, receives requests from RAN SRH and from (SRH in) Sensing Core Controller, performs splitting and merging requests on the resource level, translates requested sensing areas into necessary SUs (base stations and, possibly UEs) and / or selects and configures the SUs and BB SPFs to be involved in sensing. In case of Assisting UE, this configuration is for Tx, Rx or TxRx and, if supported, for sensing processing. Furthermore, it coordinates resource sharing between sensing and communication, e.g., sharing in time, frequency, sharing available antennas, transmission power, processing capabilities, etc. It may act as primary SUC and coordinates with secondary SUCs into the request.

[0067] A Base Band Sensing Processing Function, BB SPF, has the function of basic processing, incl. raw data refinement to Radar Cubes and peak detection. It provides sensing data, after basic processing, to Core Use Case sensing Processing Function (UC SPF). It May receive and combine data from multiple SUs (FFS).

[0068] A Sensing Unit (SU) comprises one or multiple sensing capable RAN entities and UEs and includes e.g., base stations and UEs having the capability to send and receive sensing radio signals used for ISAC as well as reporting measurement results. It supports or perform sensing data collection. SUs are in 6G-NBs (or the like) and participates in assisting UEs and an assisting UE must have a UICC.

[0069] The sensing client describes the entity sending requests to and receiving results from Sensing Core Functionalities. This Sensing client can be a network function, e.g. the NEF.P113409W00114In case of the NEF, an external application function AF (external sensing client) interacts with the NEF to provide sensing requests and to receive sensing results. However, there are also other possible realizations of a sensing client, like trusted AF or LMF directly interacting with the Sensing Core Functionalities.

[0070] The Sensing Core Controller (SCC) according to the embodiments of this invention in general supports the workflow management with one or multiple Base Stations, e.g., 6G-NBs. It converts Sensing Requests received from a Sensing Client into Sensing Measurement Requests sent to a particular target 6G-NB (or the like). It also configures and controls the CN Use case Sensing Processing Function (UC SPF) to receive the results from the 6G-NB (BB-SPF, Base Band Sensing Processing Function); possibly applying additional processing before finally sending the processed sensing results to the Sensing Client.

[0071] The transmission of the sensing result could be either directly via a data transmission interfaces or via the SCC and the control plane interface with the Sensing Client.

[0072] The SCC is aware about (may be locally configured with) the addresses of the base stations for the control plane and with the target sensing area per base station. Furthermore, the SCC is configured with the information about connectivity between the 6G-NB(s) and the CN UC Sensing Processing Function.

[0073] In particular, the SCC includes the Core SRH (Sensing Request Handler) which - receives requests to perform a sensing task from sensing clients for internal or external exposure■ each request includes at least1. Sensing task2. The target sensing area and / or rough location of the sensing target 3. Time span4. The size and / or sensing target object type, e.g., a UAV or AGV5. Timing of result■ The sensing task can include one or more of the following list of examples:1. Raw (IQ) data2. Entire radar cube or parts of it (radar imaging)3. Objection detection and tracking: Peak analysis1. There might be different peak detection algorithms, e.g.P113409W001151. standard ’’peak analysis” (no other info needed)2. custom “peak analysis” or “more info around the peaks” is needed (e.g., to learn / math object profiles)4. Matching: e.g. related detected peaks5. Matched observations:6. Object / peaks with location, speed and direction7. Characteristics- provides sensing results either directly to the requestor (e.g. via notify) or by instructing SPF - maintains registry of 6G-NBs (Sensing RAN controllers), each controlling a particular target sensing area, wherein• the sensing area of one 6G-NB may overlap with the sensing area of other 6G-NB; in this case the SCC can select amongst the candidate 6G-NB,• this information is configured on the SCC. Use of Network registry function, NRF, to find 6G-NB may be optionally implemented,• alternatively, the registry is in a separate entity (part of the CN or the RAN) that the SRH queries to acquire the knowledge of Sensing RAN Controllers and their sensing areas.- manages the workflow of sensing requests including,• splitting and merging of sensing requests received from the sensing client at the request level,• determining the Sensing RAN controllers to be used for each request, whereino if needed, the SCC subdivides the target sensing area in subareas that can be mapped to the configured 6G-NBs,o the SCC determines the list of 6G-NBs to be contacted, and which 6G-NBs to contact in parallel and in sequence; this includes the possibility to have a sequence where in each step multiple 6G-NBs are contacted,o based on the received sensing results, e.g., from the Core UC SPF, the SCC may determine the need to contact additional 6G-NBs and to stop the sensing task for already contacted 6G-NBs,P113409W00116• interaction with selected Sensing RAN controllers e.g. sending sensing requests and receiving sensing results,• configures and may receive feedback from Core UC SPF, whereino feedback includes, e.g., sensing results, whether sensing results have been provided to Sensing Client, and status of sensing processing,- handle authorization and privacy aspects related to sensing,- assign Internal Transaction IDs, making it possible to align the requested sensing job with the result; it is used by the sensing Client or Exposure layer to map towards and external Transaction Identifier so that the result is sent to the correct AF, Application Function (in case of external exposure), and / or- assign Measurement ID used to map results coming from the CN UC SPF to Internal Transaction IDs in the SRH as well as to the relevant workflows (e.g., for possible decision on contacting new 6B-NBs, as described above).

[0074] Additional functionality may be highlighted in relation to Figures 8a) to c) and 9.

[0075] A Core UC SPF receives sensing data from BB SPF and / or interprets sensing measurements and converts them into a sensing result in a format meaningful for internal or external exposure. Use case specific processing may involve, e.g., data refinement, creation of maps, processing for exposure wherein the data can be measurements, reported events, etc. Furthermore, it handle privacy processing related to sensing.

[0076] Figures 8a) and Figure 9 show additional functionalities. They illustrate an end to end data flow with exposure to support a sensing use case (UC) using the architecture of Figure 7 in accordance with the embodiments herein. Figure 9 represents a more detailed view of Figure 8. The functionalities depicted in Figure 7 and Figure 8 can be understood in the same manner despite minor differences in naming conventions. The core architectural components and their relationships remain consistent between the two figures, with Figure 8 providing a more detailed view of the data flow and control mechanisms that were conceptually introduced in Figure 7, e. g. SHR and Core SRH.

[0077] Figure 8 illustrates an end-to-end data flow and control for sensing operations using the sensing architecture of Figure 7. The figure demonstrates control plane actions and data flows in a comprehensive sensing system. The control plane actions for sensing control includes receiving at the SCC a sensing request from a sensing client or a sensing dataP113409W00117consumer via the service exposure and as a result the SCC initiates sensing measurement setup at the sensing RAN controller which configures the sensing measurement at the SU and BB SPF in the RAN / 6G NB or gNB and at the UE. It is understood by a person skilled in the art that the SCC can also be part of the Sensing Core Functionalities as showin in Figure 7. In addition, the SUC in the sensing RAN controller configures the sensing processing at the BB SPF and the SRH in the SCC configures the sensing processing at the CN SPF (also denoted CNUC SPF).

[0078] Figure 8 further illustrates the data flows and processing steps (i.e., sensing data flow) where the BB SPF receives the data flow A from UE and / or SU, the BB SPF performs a partial processing B of the sensing data flow, sends over C2 from the BB SPF the partially processed sensing results to the CN SPF where final processing D of the sensing results is performed. Once final processing is performed, the CN (UC) SPF reports the sensing results to CN SRH over E3 and to the service exposure over E2 for further forwarding to the sensing client / sensing data consumer over step or data F representing results in the exposure API.

[0079] Further details of Figure 8 are described herein. The sensing data flow encompasses several key steps from data collection to result delivery. Step A represents the collection of raw sensing data from user equipment and sensing units, which flows to the Baseband Sensing Processing Function. Step B involves partial processing of this raw data within the BB SPF, including refinement to Radar Cubes and peak detection. Steps Cl and C2 represent the transmission of partially processed sensing results from the BB SPF to the Core Network Sensing Processing Function. Step D encompasses the final processing of sensing data within the CN SPF, including use case specific processing, data refinement, and privacy processing. Step E2 involves the delivery of processed sensing results from the CN SPF to the service exposure layer, while step E3 represents workflow feedback results sent to the CN SRH. Finally, step F represents the delivery of sensing results through the exposure API to external sensing clients or data consumers.

[0080] The control plane actions are represented by steps 810 through 813. Step 810 indicates sensing measurement configuration, step 811 represents sensing processing configuration, step 812 denotes sensing measurement setup, and step 813 signifies the initial sensing request. These control steps establish the necessary configurations and coordination between network functions to enable the sensing operations.P113409W00118

[0081] The diagram uses different arrow types to distinguish between control and data flows. The thin lines with hollow arrow heads represent sensing control signaling, indicating the control plane interactions for configuring and coordinating sensing operations. The thick lines with double arrow heads represent sensing data flows, showing the actual transmission of sensing data and results through the system from collection to final delivery.

[0082] Figures 9a and 9b further illustrate the different identifiers used in the end to end data and control flows. Figure 9a shows a data flow for a data plane approach whereas Figure 9b shows the data flow for a non-data plane approach. Raw Measurement ID 850 (one per SU) is used to identify the data flow of a particular SU in step A, created by the SUC, provided to the SUs. Measurement ID 851 is used to identify the data flow in step C1 / C2, created by the SRH, provided to the SUC (for “forwarding” to the BB SPF) and the CN SPF. IntResult ID 852 is used to identify the data flow in step E1 / E2, created by the SRH, provided to the “network exposure” and the CN SPF. ExtResult ID 853 is used to identify the data flow in step F, created by “network exposure”, provided to the external sensing client. The identifier used for the data flow at step E3 of Figure 8, 9a or 9b could be the Measurement ID, the IntResult ID, or some other ID that is useful to the SRH.

[0083] With reference to Figure 8, a more detailed flow diagram of the end to end control and data flow of in accordance with some embodiments is described in the following.

[0084] Step 1. Sensing requested by sensing client / sensing data consumer, for example sending by the sensing client / sensing data consumer to an exposure platform (e.g., NEF, CAPIF, API gateway, etc) a Create ExtResult ID to identify a sensing task and identify the data flow over F.

[0085] Step 2. The exposure platform sends a Sensing request to the SRH in SCC, for example a Create IntResult ID, to request creating an internal transaction ID (IntResult ID) indicating the requested sensing task is based on the external request from the sensing client and is also used to identify the data flow over E2 and El (El used over the data plane illustrated in Figure 9a)). IntResult ID may be used over E3, albeit other identifier may be used over E3, eg. Measurement ID or some other IS useful for SCC SRH. The SRH provides the IntResult ID back to the exposure platform in response to the request.

[0086] Step 3. Void.

[0087] Step 4a. The SRH in SCC configures the CN (UC) SPH in SCC, where the configuration provided to CN SPH (sometimes referred to as SPF) includes Measurement ID,P113409W00119IntResult ID, processing configuration to be used for final processing of the sensing data flows (D - CN SPF processing in figure 8).

[0088] Step 4b. The SRH in SCC (simultaneously or subsequently to step 4a) requests setup of the sensing measurement at RAN controller (SUC) and provides Measurement ID used to identify the sensing data flow in step C1 / C2 of Figures 9a and 9b as created by the SRH in SCC. (Cl is data plane illustrated in Figure 9a, where C2 is non-data plane)

[0089] Step 5. Void.

[0090] Step 6a. The RAN controller (SUC) configures the UE and the SU with measurement configuration and provides Raw Measurement ID(s) used to identify the data flow of a particular UE / SU in step A, created by the SUC.

[0091] Step 6b. The RAN controller (SUC) also configures the BB SPF by sending measurement processing configuration (to be applied in step B - BB-SPF processing of Figure 8), Raw Measurement ID(s), Measurement ID, and may include Measurement Configuration.

[0092] Step A. Raw measurements are sent from UEs and / or SUs to BB SPF.

[0093] Step B. Partial processing of the measurements in BB-SPF is carried out .

[0094] Step 8. Void.

[0095] Step C. BB-SPF dat is passed to CN SPF.

[0096] Step 9. Void.

[0097] Step 10. Void.

[0098] Step El . Void.

[0099] Step 11. Void.

[0100] Step E2 . CN SPF fowards sensing result to Network Exposure.

[0101] Step E3. CN SPF provides sensing result feedback to the SRH, e.g. for workflow management.

[0102] Step F. Network Exposure forwards results to the sensing data customer.

[0103] The person skilled in the art will understand that the present description does not imply that all steps must be carried out in a sequential order.P113409W00120

[0104] Figure 10 illustrates a more detailed flow diagram of the exposure service and API as used in the end to end flow based on the architecture and end to end flow of Figure 8. Figure 10 illustrates the flow for one sensing job (i.e., one sensing result) in a given time window. This doesn’t fit all use cases. If subscription is needed for a certain time window an option could be to use the “start / stop” function. The timer logic is suggested to be in the exposure.

[0105] Step 1. AF (Sensing Client) sends a sensing request to an Exposure platform (e.g., NEF, CAP IF, API Gateway, etc) and includes any one of:■ AF Identifier,■ Geographical Area (map positions, need Exposure to resolve into understandable values i.e., Sensing Area)■ Sensing type (which UC),■ Measurement time (opt. time window),■ Action (start / stop)■ Report interval (Conditional, only if Action == Start)■ Source URI (address to the AF, for the result)

[0106] The sensing request may be a one time request or subscription to receive sensing result over a time period or over an area, or potentially other criteria.

[0107] The AF, Application Function, includes a Geographical Area in which a sensing job shall be initiated (step 1). The Area could be pre-agreed between the CSP and the external AF i.e., both parties know which area it is about and aliases could be used to make it easier to understand or the AF could provide Geo-Coordinates that the CSP later need to resolve to Target Sensing Area(s).

[0108] This sensing request in Figure 10, step 1, is normally received (possibly via aggregators) to the API GW inside the CSP domain or directly to a NEF / CAPIF. The API GW / NEF / CAPIF may authenticate the AF before it forwards the sensing job initiation (including the Area in which the job is requested) to e.g., a NEF, Network Exposure Function, (or similar function).

[0109] The NEF (or any other exposure handling function, if not the NEF) maps the area input from an AF i.e., in which the job is requested to the CSP internal Sensing Area(s) in order to send the sensing job request to the correct Core SRH instance (step 3 below).P113409W00121

[0110] Step 2. The Exposure platform assigns an external transaction ID identified as ExtResultld for tracking the data flow associated with the sensing task towards the AF and returns it to the AF (Sensing Client) in a response (for e.g., 200 OK or other appropriate response such as 201).

[0111] Step 3. The Exposure platform sends to the Core SRH (inside Sensing Core Controller) a sensing task related message comprising one or more of:■ Georgraphical area / Area identification (Sensing Area)■ Sensing type (indicating the sensing Use Case),■ Report interval (Conditional, only if Action == Start)■ Source URI (address of Exposure GW (e.g., NEF, CAPIF) for the result)

[0112] In response to the message, the Core SRH assigns the Internal Transaction Id identified as IntResultld and sends a response to the Exposure platform comprising the IntResultld. The response may be a 200 Ok or 201 Ok.

[0113] Step 4. After the sensing result are received from the RAN and further processed at the Core UC SPF and finalizing the processing of the sensing result, the Core UC SPF sends to the Exposure platform the sensing result in a report message or notification message or appropriate sensing result message using the Source URI of step 3 as target address. The UC SPF obtained the IntResultld and Source URI from the Core SRH). The message comprises one or more of■ IntResultld■ Area information (target Sensing Area)■ Time information■ Sensing result

[0114] Step 5. The Exposure platform maps the Internal transaction ID (IntResultld) to External Transaction Id (ExtResultld) and sends to the AF (sensing client / consumer) a Notification / report comprising ExtResultld, Area information (Optional), Time information (Optional) and Sensing result.

[0115] Target Sensing area management. As stated above, in many of the use cases there need to be a mapping between areas used when requesting sensing (by an external or internal client) and the target sensing areas used for control purposes inside the network as describedP113409W00122in Figure 10. The target sensing areas are expected to be Communication Service Provider CSP internal, and the area definitions that exist outside the CSP domain so that an external party can specify which area should be sensed e.g., for Geofencing. The latter area could be specified in a publicly available area format. Prior to proceeding a few definitions are useful to highlight.

[0116] Target sensing area: The area targeted for a certain sensing measurement. Typically used between the Core sensing workflow manager (SRH) and the sensing unit coordinator (SUC) in RAN. It also encompasses the geographical area specified in the sensing request sent by the client (via the exposure platform) to the Core SRH . For one-off or periodic sensing request this may be stationary or static for the duration of the entire sensing process - or can be updated by the Sensing Client. For tracking requests, the target sensing area may be updated by the Sensing Control Plane as the detected object moves within the coverage area of the Base station’s cells or based on a new sensing request from client. The target sensing area is not necessarily expressed as tracking areas. Target sensing area can be two or three dimensional geo-coordinates. The following assumptions may apply:■ A particular Sensing RAN Controller / SUC can be used to perform sensing in a particular target sensing area.■ If needed, the Sensing RAN Controller / SUC coordinates wrt to resources to be used for the sensing measurement with Secondary Sensing RAN controllers / SUCs.■ A sensing request from a sensing client can be split into multiple sensing measurement requests from Sensing Core Controller / SRH to the RAN SUC, each with an own target sensing area.■ Multiple Sensing RAN controllers / SUC are involved either in sequence or in parallel for the sensing task.

[0117] Exposed Serving Sensing Area: A pre-determined area used in the exposure interface with external sensing clients, e.g., to be used in SLAs with sensing clients. This area may or may not be based on the network-internal Serving Sensing Areas.

[0118] Geofencing: the ability to create a virtual fence or imaginary boundary on a specific geographic area. After the boundary is created, alerts can be set to notify when a device moves into or out of the boundary.P113409W00123

[0119] Figure 1 la to 11c illustrates examples of Target sensing area assigned by SCC and Figure 12 illustrates interaction between Sensing Core functionalities and the 6G-RAN when a primary and secondary SUC is used.

[0120] Figures 1 la-11c illustrate examples of target sensing area assignments by the Sensing Core Controller (SCC). Fig. Ila illustrates a Sensing Core Controller (SCC) utilizing a single SUC / Sensing RAN Controller for sensing a designated target sensing area, wherein the SCC communicates directly with the SUC. Fig. 11b depicts the SCC using a primary SUC / Sensing RAN Controller for a target sensing area, with a secondary SUC attached to the primary SUC. Fig. 11c shows the SCC leveraging several SUC / Sensing RAN Controllers in parallel or sequence for target sensing areas, enabling distributed sensing through networked SUCs connected to the SCC for comprehensive coverage across multiple areas.

[0121] Figure 12 illustrates interaction between SCC functionalities and the 6G-RAN when a primary and secondary SUC is used according to embodiments of the present disclosure, and provides a more detailed view of the example as shown in Figure 1 lb.

[0122] The figure shows a system architecture with two 6G-NB nodes, each containing various components for sensing operations. The upper 6G-NB includes a Primary SUC connected to a UE RxTx, an SU, and a BB SPF. The Primary SUC also connects to a RAN UC SPF within the same node. The lower 6G-NB contains a Second SUC that connects to another UE RxTx, SU, and BB SPF configuration.

[0123] The system shows connections between the RAN SRH and Core SRH components, with the Core SRH connecting to a Core UC SPF. The RAN SRH and the Core SRH may include target sensing area into the request. The BB SPF in the secondary SUC provides sensing results either to RAN UC SPF or to Core UC SPF, depending on the use case.

[0124] The diagram includes sensing control and results pathways, with sensing results flowing through the system. Dashed lines represent certain control connections, while solid lines show other operational connections. The architecture demonstrates coordination between primary and secondary sensing unit controllers in a distributed sensing network configuration. The use of assisting UE implies the use of AMF, UDM and AUSF which are not depicted for brevity.

[0125] To solve the above challenge, embodiments herein enable creation a new set of Area definitions for sensing which makes it possible to identify which SRHs that should beP113409W00124contacted to trigger a sensing job, called Serving Sensing Area and hence create an automatic way to construct said Area definitions.

[0126] Figure 13 illustrates the different sensing area topologies according to the embodiments herein. The different areas may be overlapping.

[0127] A SU Area (SU1, SU2, etc.) comprises the area where an SU can be used for sensing measurement, i.e., the area a certain SU “covers”. This area may be a 2D or 3D representation.

[0128] A SUC Area comprises the area controlled by a certain SUC, i.e., the area in which the SUC is in direct control of one or more SUs.

[0129] A Serving Sensing Area (SSA) comprises the area for which a certain SRH can handle a sensing job / task. The area may be described as a geographical area (in 2D or 3D) or even be represented by a geographical point representing, e.g., its deployment location or a point in the area where it can handle a sensing job / task.

[0130] As an exemplary illustration, Figure 13 shows a hierarchical relationship where 6 individual Sensing Units (SU1-SU6) are organized under 2 Sensing Unit Controllers (SUC1, SUC2), which are managed by 1 Serving Sensing Area (SSA1), demonstrating a 3: 1:0.5 ratio structure. The disclosure encompasses other hierarchical ratios and organizational structures for sensing area topologies, including different distributions of sensing units per sensing unit controller and sensing unit controllers per serving sensing area.

[0131] Figure 14 illustrates a flow diagram of area mapping based on deployment time alternative, i.e. areas are defined at deployment time. It 14 depicts beginning with individual Sensing Units (SUs) registering with their respective Sensing Unit Controllers (SUCs), progressing through SUC registration with Core Sensing Request Handlers (SRHs), and culminating in the creation of Serving Sensing Areas and their registration with network repositories and exposure platforms, shown with the NRF, Exposure and AF linked to the SHR.

[0132] Step 1. Upon startup, update or discovery, each SU registers in SUC (RAN) and share Geo-coordinates, i.e., it’s location and SU area. The address of SUC is either configured or discovered.

[0133] Step 2. The SUC map each individual SU towards the registered SU areas and could optionally build “SUC Areas” per SUC. This information is kept until the SU is deregistered.P113409W00125

[0134] Step 3. Then the SUC register in the Core SRH including all SU areas or its “SUC Area”.The address of Core SRH is either configured or discovered. Alternatively, the SUC registers in a, e.g. separate, registry where the SRH can later discover the SUC(s).

[0135] Step 4. The Core SRH creates (and persistently keeps) the Serving Sensing Area (SSA) based on SU / SUC input, the area could include the “outer” geo-coordinates. The SSA is inside the Core SRH mapped towards SUC and respective SUs and kept until the SUC is deregistered.

[0136] Step 5. If required, registering the SRH may include Serving Sensing Area (SSA), SRH identity and SRH address in an SRH Registry. This registry could be realized by the NRF or other future similar entity as part of SRH profile.

[0137] Step 6. If required, the Core SRH may “Register” SRH including Serving Sensing Area, SRH identity and SRH address in the exposure layer / platform (NEF / CAPIF / API GW, etc.)

[0138] Step 7. Optionally, the exposure layer may create pre-defined Exposed Serving Sensing Areas and have and may enforce SLA agreements based on pre-agreed Exposed Serving Sensing Area.

[0139] Another alternative is that the addresses of SUCs are configured in the Core SRH. The SRH will then regularly check with i.e., pull information from each SUC for the particular SUC Area and store this information in its registry and / or subscribe to SUC Area updates via subscription / notification scheme, i.e., the SUC may notify the SRH in case the SUC area is changed i.e., push information.

[0140] The information pulled or pushed need to include the geo-coordinates supported by all SUC(s) and SU(s). It would then be up to the Core SRH to continue with step 5 or 6 above. It may occur that there is an overlap in the SUC Areas. The end result of above actions in Figure 14 and alternative would result in a picture illustrated in Figure 15.

[0141] Figure 15 illustrates the result of the deployment-time area mapping procedure described in Figure 14, showing the hierarchical registration and discovery architecture for sensing areas. The figure depicts the Network Repository Function (NRF) containing an NF Profile Registered table that stores information about registered Sensing Request HandlersP113409W00126(SRHs) and their associated Serving Sensing Areas (SSAs). The architecture shows the following elements and their hierarchical relationships.

[0142] Individual Sensing Units (SUs) such as SU1, SU2, SU3, etc., each covering specific geographical areas, register with their respective Sensing Unit Controllers (SUCs). For example, SUC-A may control SU1, SU2, and SU3 within its coverage area, while SUC-B controls SU4, SU5, and SU6 in a different geographical region.

[0143] The SUCs (SUC-A, SUC-B, etc.) then register with Core Sensing Request Handlers (SRHs). For instance, SRH-1 may coordinate with SUC-A and SUC-B to establish a comprehensive Serving Sensing Area that encompasses the combined coverage of all associated SUs. This creates a hierarchy where SU1— > SUC-A— > SRH-1 represents the complete chain from individual sensing unit to core network handler.

[0144] The Core SRHs (SRH-1, SRH-2, etc.) register their profiles with the NRF, including their SRH identity, SRH address, and the Serving Sensing Area coordinates that define the geographical coverage where each SRH can handle sensing jobs. The NF Profile Registered table maintains this registry information to enable discovery and selection of appropriate SRHs based on geographical area requirements during runtime operations. The table structure contains the following information:SRH Identity SRH Address Serving Sensing AreaSRH a 1.2.3.4 {a, d, e, f, x, y}SRH b 2.3.4.5 {c, z, q}SRH c 3.4.5.6 {b, g, h, i, r, s}Table 1 : NF Profile Registered TableThis registry enables the exposure layer or other network functions to query the NRF during runtime operations to discover and select appropriate SRHs that can handle sensing requests for specific geographical areas based on the stored Serving Sensing Area coordinates.

[0145] Alternative implementations may replace the NRF with other registry functions such as the Exposure layer itself or a dedicated SRH Registry, while maintaining the same fundamental registration and discovery mechanisms for sensing area management.

[0146] In case the Core SRH “registers” in the Exposure layer, the end result would look like Figure 15 apart from that the NRF is replaced by “Exposure”. The Exposure layer then hasP113409W00127the information that is depicted in the “NF Profile Registered” table and can execute the SRH Di scovery / S el ection itself, see step 2 in figure 16.

[0147] In case the SRH “Registers” in a separate registry it could look like Figure 15 apart from that the NRF is replaced by “SRH Registry”. The Exposure layer will in such case query the SRH Registry in the same way as it would query the NRF in the “NRF case”.

[0148] Figure 16 illustrates a flow diagram of use of area definitions in run time and the operational workflow that occurs when sensing requests are made during normal system operation. It shows the operational flow from sensing request initiation through to the final configuration of sensing units, including the mapping and transformation of geographical coordinates into Target Sensing Areas. The process begins with an AF making a sensing request with specific geographical coordinates, triggering a real-time discovery mechanism where the exposure layer queries the NRF or registry to find appropriate SRHs based on their registered Serving Sensing Areas. The procedure demonstrates how the pre-established area definitions from Figure 14 are utilized during runtime to enable automatic SRH selection and sensing resource allocation. Additionally, Figure 16 includes coordination mechanisms between primary and secondary SUCs when target sensing areas exceed individual SUC capabilities, showing the dynamic resource coordination that occurs during actual sensing operations rather than the static area establishment shown in Figure 14.

[0149] Step 1. AF (sensing client / sensing consumer) requests a sensing job, e.g. via a sensing request, on a specific Geolocation, using Geo-coordinates or, if used, one or more Exposed Serving Sensing Areas as input.

[0150] Step 2. Unless the Core SRH has registered or is configured in the exposure layer during deployment time the NRF, or an alternative registry, the exposure requests NRF to provide suitable SRH(s) previously registered using the geo-coordinates as input key, e.g., discovery request.

[0151] Step 3. The NRF or other registry function uses the input from the exposure layer and returns the Core SRHs which Serving Sensing Area(s) cover / best matches the requested geo-coordination area. Alternatively, the NRF or an alternative registry could return a list of Core SRHs together with their Serving Sensing Areas and let the Exposure layer choose the SRH.

[0152] Step 4. The Exposure function forwards the sensing request to the Core SRH(s) that fits the request including the original geo-coordinates provided by the AF.P113409W00128

[0153] Step 4b. The Core SRH use the received geo-coordinates to find SUC(s) that can control sensing measurements in respective area(s) defined by the geo-coordinates, either based on local information or querying a registry, as described above. The SRH maps / transforms the geo-coordinates to Target Sensing Area(s) used towards the selected SUC(s).

[0154] Step 5. The Core SRH sends a sensing measurement request to the SUC(s) that fits the request, including the Target Sensing.

[0155] Step 6. The target Sensing Area sent to a SUC may be larger than the SUC Area, triggering the SUC to make use of a Secondary SUC.

[0156] Step 7. The SUC(s) selects the SU(s) in the Target Sensing Area(s) and configures these SU(s) for sensing measurement.

[0157] This may include communicating with Secondary SUC(s) as described in Figure 12 and in step 6 above.

[0158] Figure 17 illustrates the result of the above procedure. It illustrates the result of the runtime area mapping procedure described in Figure 16, showing the operational flow and hierarchical coordination during actual sensing operations. The figure demonstrates how geographical coordinates provided by an AF are progressively mapped and refined through the sensing architecture hierarchy. At the lowest level, multiple Sensing Units (SUs) provide the fundamental sensing capabilities within specific geographical areas. These SUs register with and are controlled by Sensing Unit Controllers (SUCs), which coordinate groups of SUs and manage their collective sensing operations within larger geographical regions. The SUCs, in turn, register with Core Sensing Request Handlers (SRHs) that operate at the core network level. The SRHs aggregate the capabilities of multiple SUCs to create comprehensive Serving Sensing Areas and handle high-level sensing job coordination and workflow management. At the highest level, the SRHs register their profiles and capabilities with network registry functions such as the Network Repository Function (NRF) or directly with exposure platforms. The exposure layer interfaces with external Application Functions and sensing clients, providing service discovery and request routing capabilities.

[0159] Step a. Upon a request an AF provides geographical coordinates as input to initiate a sensing request.

[0160] Step b) NRF matches them towards the Serving Sensing Area to find Core SRH candidates.P113409W00129

[0161] Step c) Core SRH uses them towards the SUC Area(s) to find SUC candidates.

[0162] Step d) SUC uses them to find or exclude SUs

[0163] Steps b to d all include the original geo-coordinates that was provided in step a.

[0164] As an example, SRH a with address 1.2.3.4 is registered in the NF Profile Registered table with a Serving Sensing Area covering geographical coordinates {a, d, e, f, x, y}. When an AF requests sensing services for any location within these coordinates, the NRF can identify SRH a as a suitable candidate based on the geographical area match. The SRH a would then coordinate with its associated SUC b and SUs a, x and y to provide sensing coverage for the requested geographical area, demonstrating how the registry enables efficient resource discovery and allocation during runtime operations.

[0165] The runtime area mapping results in a comprehensive registry structure that enables efficient sensing resource allocation. Table 2 below illustrates the hierarchical mapping relationships established during the operational flow:SRH Identity SRH Address Serving Sensing AreaSRH a 1.2.3.4 {a, d, e, f, x, y}SRH b 2.3.4.5 {c, z, q}SRH c 3.4.5.6 {b, g, h, i, r, s}Table 2: Runtime Area Mapping Results

[0166] Additionally, one can consider the area definitions (especially relevant for the SU Area) to not only describe a specific geographical area, but also the quality of sensing possible there. E.g., the area description may contain several area definitions, one for a specific quality level. For example, 3 areas could be provided for each SU, one for really good sensing coverage, e.g. close to the antenna, line-of-sight, one for modest sensing quality, e.g. more distant, non-line-of-site, but with a good reflector, and one with poor, but possible sensing, e.g. further away. This would help the SUC select the appropriate set of SUs.

[0167] Figure 18 illustrates a step-by-step procedure for area handling in sensing services that corresponds to the runtime area mapping embodiment described in Figure 16. The procedure demonstrates the operational workflow from external sensing request to 6G or NG-RAN sensing measurement execution.P113409W00130

[0168] Step 1. An AF provides an External Target Sensing Area to the NEF in the sensing service request that it invokes to the network. The AF specifies the geographical area where sensing operations are required using externally defined area coordinates or identifiers.

[0169] Steps 2-3. The NEF maps the External Target Sensing Area to a Target Sensing Area using internal network area definitions. The Target Sensing Area is then used to discover an SnCF instance, SCC or SRH, capable of handling the sensing service request. For the SnCF discovery, the NEF queries the NRF based on the information provided during the SnCF registration with NRF, using the Target Sensing Area as the discovery key.

[0170] Step 4. The NEF sends the corresponding sensing service request to the selected SnCF, including the Target Sensing Area information in the request. This enables the SnCF to understand the geographical scope of the requested sensing operation.

[0171] Step 5. The SnCF uses the received Target Sensing Area to select the NG-RAN nodes that can perform sensing measurements in the area that includes the Target Sensing Area. The area where an NG-RAN node can perform sensing measurements is denoted as the NG-RAN node Serving Sensing Area. The SnCF matches the Target Sensing Area against the registered NG-RAN node Serving Sensing Areas to identify suitable candidates.

[0172] Step 6. The SnCF sends the corresponding sensing service request to the selected NG-RAN node, including the information about the Target Sensing Area. This request instructs the NG-RAN node to prepare for sensing operations within the specified geographical boundaries.

[0173] Step 7. Based on the received sensing service request from the SnCF that included the Target Sensing Area information, the NG-RAN performs the relevant sensing measurements for this specific sensing request. The NG-RAN node configures its sensing units and processing functions to execute the requested sensing operations within the Target Sensing Area.

[0174] Further details to the sensing procedures as disclosed above are described in the following. An Application Function (AF), acting as a sensing service consumer, invokes a sensing exposure service to request the network to perform either object detection or object tracking within a certain geographical area. In the request, AF includes attributes specified in Table 3.P113409W00131Attribute DescriptionAF Identifier AF identifier of the AF requesting sensing service from the networkSensing ServiceRequirements> External Target It specifies the area where the AF requests to obtain a sensing result; the area is Sensing Area defined in clause 3.1» Altitude information Information about altitude range (min-max values with the respect to the sea level) (optional) can be additionally added in the request to complement (External) Target Sensing Area in order to specify the area about which the AF request a sensing result > Sensing Type It specifies whether the AF requests ‘Object Detection’ or ‘Object T racking’ » Object Type It indicates a type ofthe object the sensing entity is expected to detect orto perform (NOTE X1) the tracking ofthe object» Expected Velocity It indicates the expected velocity ofthe object(optional)» Expected Position It indicates the expected position in cartesian coordinates where ofthe object can (optional) be located within the Target Sensing Area> Sensing Time It indicates the time period for which the sensing result shall contain information Window (optional)> Sensing Reporting It indicates whether the AF requests to receive the sensing result as a one-time Mode (optional) report (optionally indicating a specific time of day at which the report is expects), as periodic report (in which case the AF may include either a reporting interval value, in seconds, between two consecutive reports, or the number of reports within the sensing time window)Sensing ResultCharacteristics(optional)> Requested Accuracy value in meters that the AF requests to determine object’s position with Positioning Accuracy a certain confidence level, e.g., 90%> Requested Velocity Accuracy value in m / s that the AF requests to determine object’s velocity with a Accuracy certain confidence level, e.g., 90%> Requested Probability value in percent (%) that the object is reported as detected when the Probability of False object is not present in the Target Sensing AreaDetection> Requested Probability value in percent (%) that the object is not detected when the object is Probability of Missed present in the Target Sensing AreaDetectionNOTE X1 : In this release, ‘Object Type’ is set to ‘Drone’.Table 3: Parameters in the sensing service request from AFs

[0175] The AF’s request is sent to the NEF, which then performs authorization of the AF.

[0176] The NEF discovers a Sensing Core Function (SnCF) that can handle the sensing service request and invokes the corresponding sensing service operation to the selected SnCF.P113409W00132The SnCF performs the service-level authorization of the requested sensing services as described in clause A.B. The SnCF selects sensing-capable NG-RAN node(s) and sends the sensing service request(s) that contains Sensing Service Assistance Information (see Table 6.1-2) that describes RAN-relevant sensing service requirements that the SnCF provides to the NG-RAN for determination of sensing measurements and sensing result.Assistance Information DescriptionTarget Sensing Area It specifies the area where a selected NG-RAN node is requested to perform information (optional) sensing measurements; it can be the entire Target Sensing Area or a part of it depending on NG-RAN node Serving Sensing Area. If not provided, the sensing measurements are being requested for the entire NG-RAN node Serving Sensing Area.Altitude information Information about altitude range (min-max values with the respect to the sea (optional) level) can be additionally added in the request to complement Target Sensing Area information fora selected NG-RAN nodeSensing Type It specifies whether the SnCF requests to provide sensing measurements / sensing results for ‘Object Detection’ or ‘Object Tracking’ > Object Type (NOTE X2) It indicates a type of the object the sensing entity is expected to detect or to perform the tracking of the object> Expected Velocity It indicates the expected velocity of the object(optional)> Expected Position It indicates the expected position in cartesian coordinates where of the object (optional) can be located within the Target Sensing AreaSensing Time Window It indicates the time period for which the sensing result shall contain (optional) informationSensing Result Reporting It is determined by the SnCF based on the ‘Sensing Reporting Mode’ (see information (optional) Table 6.1-1) and indicates whether the SnCF requests to receive the sensing result as a one-time report (optionally indicating a specific time of day at which the report is expects), as periodic report (in which case the SnCF may include either a reporting interval value, in seconds, between two consecutive reports, or the number of reports within the sensing time window)Sensing ResultCharacteristics (optional)> Requested Positioning It indicates the accuracy value, in meters, that the AF requests to determine Accuracy object’s position with a certain confidence level, e.g., 90%> Requested Velocity It indicates the accuracy value, in m / s, that the AF requests to determine Accuracy object’s velocity with a certain confidence level, e.g., 90%> Requested Probability of It indicates the probability value, in percent (%), that the object is reported as False Detection detected when the object is not present in the Target Sensing Area> Requested Probability of It indicated the probability value, in percent (%), that the object is not detected Missed Detection when the object is present in the Target Sensing AreaNOTE X1 : In this release, ‘Object Type’ is set to ‘Drone’.P113409W00133Table 4: Sensing Service Assistance Information (SSAI)

[0177] Based on the SSAI, the NG-RAN determines the sensing measurement configuration, collects sensing data, and applies a defined level of processing to derive a sensing result, which is reported to the SnCF in a sensing report.

[0178] Based on the received sensing reports from the NG-RAN nodes, the SnCF determines the final sensing result for exposure to the AF, considering the sensing parameters in Table 3.

[0179] Figure 19a is schematic block diagram of a network node 1100 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 1100 may be, for example, a core network node that implements a NF (e.g., one or more of the 5G / 6G network functions, e.g. a NEF, or the Core SRH, Core UC SPF). As illustrated, the network node 1100 includes a one or more processors 1104 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 1106, and a network interface 1108. The one or more processors 1104 are also referred to herein as processing circuitry. The one or more processors 1104 operate to provide one or more functions of the network node 1100 as described herein (e.g., one or more functions of the e.g., one or more of the 5G network functions, or the like, as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 1106 and executed by the one or more processors 1104.

[0180] Figure 19b is a schematic block diagram of a network node corresponding to a radio access node 1100 according to some embodiments of the present disclosure. The network node being the radio access node 1100 may be, for example, abase station 6GNB or NG RAN gNB. As illustrated, the radio access node 1100 includes a control system 1102 that includes one or more processors 1104 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 1106, and a network interface 1108. The one or more processors 1104 are also referred to herein as processing circuitry. In addition, the radio access node 1100 includes one or more radio units 1110 that each includes one or more transmitters 1112 and one or more receivers 1114 coupled to one or more antennas 1116. The radio units 1110 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 1110 is external to the control system 1102 and connected to the control system 1102 via, e.g., a wiredP113409W00134connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) 1110 and potentially the antenna(s) 1116 are integrated together with the control system 1102. The one or more processors 1104 operate to provide one or more functions of a radio access node 1100 as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 1106 and executed by the one or more processors 1104.

[0181] Figure 20 is a schematic block diagram that illustrates a virtualized embodiment of the network node 1100 according to some embodiments of the present disclosure. Again, optional features are represented by dashed boxes. As used herein, a “virtualized” network node is an implementation of the network node 1100 in which at least a portion of the functionality of the network node 1100 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node 1100 includes one or more processing nodes 1200 coupled to or included as part of a network(s) 1202. Each processing node 1200 includes one or more processors 1204 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 1206, and a network interface 1208. In this example, functions 1210 of the network node 1100 described herein (e.g., one or more of the 5G network functions, or the like, as described herein) are implemented at the one or more processing nodes 1200 or distributed across the two or more processing nodes 1200 in any desired manner. In some particular embodiments, some or all of the functions 1210 of the network node 1100 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1200.

[0182] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 1100 or a node (e.g., a processing node 1200) implementing one or more of the functions 1210 of the network node 1100 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0183] Figure 21 is a schematic block diagram of the network node 1100 which may also be a radio access node 1100 according to some other embodiments of the presentP113409W00135disclosure. The network node 1100 includes one or more modules 1300, each of which is implemented in software. The module(s) 1300 provide the functionality of the network node 1100 described herein. This discussion is equally applicable to the processing node 1200 of Figure 19 where the modules 1300 may be implemented at one of the processing nodes 1200 or distributed across multiple processing nodes 1200.

[0184] Figure 22 is a schematic block diagram of a UE 1000 or SU according to some embodiments of the present disclosure. As illustrated, the UE 1000 or SU includes one or more processors 1002 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 1004, and one or more transceivers 1006 each including one or more transmitters 1008 and one or more receivers 1010 coupled to one or more antennas 1012. The transceiver(s) 1006 includes radio-front end circuitry connected to the antenna(s) 1012 that is configured to condition signals communicated between the antenna(s) 1012 and the processor(s) 1002, as will be appreciated by on of ordinary skill in the art. The processors 1002 are also referred to herein as processing circuitry. The transceivers 1006 are also referred to herein as radio circuitry. In some embodiments, the functionality of the UE 1000 described above may be fully or partially implemented in software that is, e.g., stored in the memory 1004 and executed by the processor(s) 1002. Note that the UE 1000 may include additional components not illustrated in Figure 10 such as, e.g., one or more user interface components (e.g., an input / output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and / or the like and / or any other components for allowing input of information into the UE 1000 and / or allowing output of information from the UE 1000), a power supply (e.g., a battery and associated power circuitry), etc.

[0185] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the UE 1000 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0186] Figure 23 is a schematic block diagram of the UE 1000 according to some other embodiments of the present disclosure. The UE 1000 includes one or more modules 1100, each of which is implemented in software. The module(s) 1100 provide the functionality of the UE 1000 described herein.P113409W00136

[0187] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0188] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0189] While processes in the figures (flow charts, procedures) may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0190] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

[0191] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

[0192] The sensing architecture and area topology described in this disclosure may be understood in relation to emerging 3 GPP standardized terminology for sensing areas. While this patent application introduces novel hierarchical structures and implementationP113409W00137mechanisms, it may be beneficial to understand how the disclosed concepts relate to standardized 3 GPP terminology.

[0193] The 3 GPP standards define several sensing area types including External Target Sensing Area (used between NEF and third-party AF), Target Sensing Area (internal CSP area for sensing services), NG-RAN node Serving Sensing Area (area where NG-RAN can perform sensing measurements), and SnCF Serving Sensing Area (geographical area where a Sensing Core Function instance can perform sensing tasks). The terminology used in this disclosure may be mapped to these standardized terms while maintaining the novel hierarchical structure described herein.

[0194] The Sensing Core Controller (SCC) and Sensing Request Handler (SRH) described in this disclosure may correspond functionally to the Sensing Core Function (SnCF) in 3GPP terminology. However, the SCC / SRH architecture provides additional workflow management capabilities and hierarchical area coordination not explicitly defined in current 3GPP standards. The Serving Sensing Area (SSA) as defined herein may align conceptually with the SnCF Serving Sensing Area in 3 GPP terminology, while providing enhanced granularity through the disclosed SU and SUC area hierarchy.

[0195] The SU Area represents the finest granularity of sensing coverage for individual sensing units, the SUC Area provides intermediate coordination for groups of sensing units, and the SSA provides the highest-level area management for sensing job coordination. This hierarchical structure enables scalable sensing area management and may be implemented within or alongside 3 GPP-compliant sensing architectures.

[0196] The deployment-time area mapping procedures described in Figures 14-17 provide specific implementation mechanisms for establishing and maintaining these hierarchical area relationships. These procedures may complement 3 GPP sensing procedures by providing detailed area registration, discovery, and mapping capabilities. The disclosed architecture supports both the standardized NG-RAN node to SnCF communication patterns while adding the novel SU / SUC coordination layer for enhanced sensing area management and resource coordination.P113409W001ABBREVIATIONS3 GPP 3rd Generation Partnership Project5GS 5G SystemAF Application FunctionAPI Application Programming InterfaceBB BasebandBS Base StationCN Core NetworkCP Control PlaneDL DownLinkDP Data PlaneISAC Integrated Sensing and Communication: Synonymous to JCAS JCAS Joint Communication and Sensing: Synonymous to ISAC NEF Network Exposure FunctionNF Network FunctionNG-RAN Next Generation Radio Access NetworkNW NetworkOAM Operations, Administration, and ManagementOFDM Orthogonal Frequency Division MultiplexingRAN Radio Access NetworkRNTI Radio Network Temporary IdentifierRU Radio UnitRx ReceptionSCC Sensing Core ControllerSnCF Sensing Core FunctionSRH Sensing Request HandlerSRC Sensing RAN ControllerSU Sensing Unitsue Sensing Unit ControllerSensing CP Sensing Control PlaneSPF Sensing Processing FunctionSSAI Sensing Service Assistance InformationTx TransmissionP113409W00139UC Use CaseUE User Equipment UL UpLinkUP User Plane

Claims

P113409W00140CLAIMS1. A system of one or more servers for handling sensing jobs or task for a sensing client, the system comprising a core network and an access network communicating with external sensing clients, the system comprising:a Sensing Core Controller (SCC) in the core network for handling sensing request for a sensing task, the SCC configured to:receive sensing request to perform sensing job or task originated by sensing client via an exposure platform;provide sensing results towards the sensing client or instruct a core network Sensing Processing Function (SPF) to provide the sensing results towards the sensing client; assign Internal Transaction ID to sensing request, making it possible to align the requested sensing job or task with the sensing result;configure a Sensing Processing Function in the core network;interact with sensing radio access network (RAN) controller to setup sensing measurement based on the sensing requests; anda Sensing Processing Function (SPF) in the core network configured to:receive sensing data from RAN SPF;process the received sensing data and convert into sensing result to be transmitted towards the consumer;receive processing measurement for the sensing job or task from the SCC in the core network.

2. The system of claim 1 wherein the SCC in the core network is further configured to:create Serving Sensing Area (SSA) based on area information from one or more RAN Sensing Unit Controller (SUC);register the SSA in a registry function or the exposure platform.P113409W001413. The system of claim 2 wherein the area information from each RAN SUC comprises at least one of one or more Sensing Unit (SU) areas associated to one or more SUs in the RAN or SUC area of the RAN SUC.

4. The system of claim 1 wherein the SCC is further configured to maintain registry of sensing RAN controllers, each controlling a particular target sensing area.

5. The system of claim 1 wherein the SCC is further configured to manage workflow of sensing requests including splitting and merging of sensing requests at a request level.

6. The system of claim 1 wherein the SCC is further configured to determine sensing RAN controllers to be used for each sensing request.

7. The system of claim 1 wherein the sensing request comprises at least one of sensing task, target sensing area, time span, size of sensing target object type, and timing of result.

8. A method performed by a core network controller function, the method comprising:receiving from an exposure platform a sensing request for a sensing task originated from a sensing client;creating an internal transaction id for the sensing task and providing it in a response to the exposure function;initiating sensing measurement configuration in Radio Access Network Sensing Unit Controller (RAN SUC) and sensing measurement processing configuration in a sensing processing function in the core network.

9. The method of claim 8 wherein the step of initiating sensing measurement configuration in RAN SUC comprises sending to the RAN SUC a sensing measurement setup comprising an assigned measurement identifier.P113409W0014210. The method of claim 8 wherein the step of initiating sensing measurement processing configuration in core network SPF comprises sending to the SPF a sensing measurement configuration request comprising at least one of an assigned measurement identifier or the internal transaction id.

11. The method of claim 8 wherein the method further comprises receiving information area from one or more RAN SUCs and determining a Sensing Serving Area (SSA) based on the received information area.

12. The method of claim 11 wherein the method further comprises registering a profile of the SRH comprising the supported SSA.

13. The method of claim 8 further comprising maintaining registry of sensing RAN controllers, each controlling a particular target sensing area.

14. The method of claim 8 further comprising managing workflow of sensing requests including splitting and merging of sensing requests at a request level.

15. A method performed by an exposure platform, the method comprising:receiving from an Application Function a sensing request for a sensing task, the sensing request comprising a sensing type;assigning an external transaction ID for the request;sending a second sensing request based on the received sensing request to a sensing request handler (SRH) in a sensing core controller (SCC) in a core network, the second sensing request comprising the sensing type and a source URI to be used for receiving sensing results from a Sensing Processing Function in the core network; obtaining from the SRH a first response comprising an internal transaction ID; mapping the internal transaction ID to the external transaction ID; andsending to the AF a second response comprising the external transaction ID.P113409W0014316. The method of claim 15 wherein the sensing request comprises at least one of geographical area, a measurement time, or an action parameter indicating start or stop.

17. The method of claim 16 wherein the geographical area comprises geographical coordinates.

18. The method of claim 16 further comprising discovery of an SRH based on the geographical area in the sensing request.

19. The method of claim 18 wherein the discovery further comprises sending a discovery request for SRH to a registry function wherein the discovery request comprises the geographical area received in the sensing request.

20. The method of claim 15 further comprising receiving sensing results from the Sensing Processing Function and forwarding the sensing results to the Application Function using the external transaction ID.

21. A network node configured to perform the method of any of claims 8-14 or 15-20.

22. A network node comprising one or more processors and memory comprising instructions which when executed by the one or more processors enable the network node to perform the method of any of claims 8-14 or 15-20.

23. A computer readable memory comprising instructions which when executed by one or more processors of one or more servers configures the one or more servers to perform the method of any of claims 8-14 or 15-20.

Images