BACKGROUND

3GPP currently studies use cases and requirements to support sensing utilizing the New Radio (NR) cellular radio with aim at acquiring information about a remote object or environment and its characteristics without physically contacting it. The perception data of the object and its surrounding can be utilized for analysis. With this technique, meaningful information about the object or environment and its characteristics can be obtained.

The current definition of wireless 5G sensing, taken from 3GPP TR 22.837 is:

“5G Wireless sensing: 5GS feature providing capabilities to get information about characteristics of the environment and/or objects within the environment (e.g. shape, size, speed, location, distances or relative motion between objects, etc.) using NR RF signals and, in some cases, previously defined information available in EPC and/or E-UTRA.”

Most use cases of such sensing services address different target verticals/applications, e.g. autonomous/assisted driving, V2X, UAVs, 3D map reconstruction, smart city, smart home, factories, healthcare, maritime sector.

For example, sensing in smart home is one of the typical scenarios of indoor/local-area sensing. Considering people spends most of lifetime indoor, how to improve the user experience for indoor scenario is important. Current 5G networks allow user applications to employ various 5G UEs in various smart home platforms and environments. The UEs can be wearable devices, sensors, smart phones or a customer premise equipment (CPE). In order to enable a more comfortable and convenient indoor life, various of these devices can be connected via wireless signals to build a smart home platform.

In addition to communication purposes, wireless signals from various 5G UEs (e.g., wearable devices, sensors, smart phones, customer premise equipment (CPE), etc.) can also be used for sensing, e.g., monitoring the home environment continuously. For example, due to the activities of indoor objects or human, the 3GPP signal measured by UEs or the network would be influenced, allowing intruder detection in smart homes. By analyzing and collecting the sensing information such as Doppler frequency shift, amplitude change and phase change, the behavior of indoor objects or humans can be detected. SUMMARY

An aspect of the invention is to provide an improved computer-implemented method in a mobile telecommunications network and a mobile telecommunications network apparatus for providing access to network functions in a mobile telecommunications network.

According to an aspect, a computer-implemented method in a mobile telecommunications network is provided. The method comprises a step of receiving, by a network function, a sensing request comprising sensing requirement parameters. The sensing requirement parameters comprise a sensing event type and a location area of interest. The method further comprises identifying, by the network function, one or more sensing radio nodes of the mobile telecommunications network having a sensing capability that meets the sensing requirement parameters. A sensing monitoring request is transmitted to each of the sensing radio nodes to provide a sensing measurement based on the sensing event type. The method further comprises aggregating sensing measurements from the sensing radio nodes and validating that the sensing measurements correspond to the sensing event type. The network function then transmits a response based on the sensing measurements. The network function can be a sensing function or a gateway function.

According to a further aspect, a mobile telecommunications network apparatus is provided that comprises a processor configured to execute computer-readable instructions for implementing a sensing function. The sensing function performs the following steps. It receives a sensing request comprising sensing requirement parameters. The sensing requirement parameters comprise a sensing event type and a location area of interest. The sensing function then identifies one or more sensing radio nodes of the mobile telecommunications network having a sensing capability that meets the sensing requirement parameters. Thereafter, it transmits a sensing monitoring request to each of the selected sensing radio nodes to provide a sensing measurement based on the sensing event type. The sensing function aggregates sensing measurements from the selected sensing radio nodes and validates that the sensing measurements correspond to the sensing event type. The network function then and transmits a response based on the sensing measurements.

According to a further aspect, a mobile telecommunications network apparatus is provided that comprises a processor configured to execute computer-readable instructions for implementing a gateway function. The gateway function receives a sensing request comprising sensing requirement parameters. The sensing requirement parameters comprise a sensing event type and a location area of interest. The gateway function further identifies one or more sensing radio nodes of the mobile telecommunications network having a sensing capability that meets the sensing requirement parameters. It then discovers an access and mobility function (AMF) that supports the sensing requirement parameters of the sensing request. The gateway function forwards to the AMF a sensing measurement request based on the sensing requirement parameters. The sensing measurement request indicates the identified one or more sensing radio nodes. Then the gateway function receives a sensing response from the AMF. The sensing response comprises sensing measurements from the sensing radio nodes and a validation result indicating that the sensing measurements correspond to the sensing event type. Then, the gateway function transmits a response based on the sensing response from the AMF.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments and aspects of the invention will be described in the following description and together with the accompanying drawings, wherein

Fig. 1 is a diagram showing a 3GPP network providing sensing services;

Fig. 2 is a diagram showing an exemplary basic architecture diagram for supporting sensing services within 3GPP network;

Fig. 3 is an exemplary flow diagram of a sensing measurement request from an application function to a 3GPP network; and

Fig. 4 is an alternative exemplary flow diagram of a sensing measurement request from an application function to a 3GPP network using a gateway function.

DETAILED DESCRIPTION

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings.

The 3GPP started discussing use cases and potential requirements for localized metaverse services. The metaverse is an open, shared, and persistent virtual world that offers access to the 3D virtual spaces, solutions, and environments created by users. The metaverse is a digital reality that combines aspects of social media, online gaming, augmented reality (AR), virtual reality (VR), and cryptocurrencies to allow users to interact virtually. Some use cases can be the following: 1 . Mobile Metaverse Based Selective Multi-modal Feedback Service

Mobile metaverse based multi-modal feedback service describes a case of multiphysical entities or their digital avatars interacting with each other. New feedback modalities are also introduced in this use case to satisfy new scenarios and requirements in the mobile metaverse. The mobile metaverse may be a cyberspace parallel to the real world, which makes the virtual world more real and makes the real world richer. The service should better utilize different feedback cues and achieve multi-modal feedback cues to adapt to different scenarios, satisfy the accuracy of the task and user experience, and so on. More modalities should be explored to meet more immersion requirements of the physical entities in the real world such as smell and taste. To realize a more immersive requirement of different scenarios in the mobile metaverse, it is important to explore these temporal in-sync or out-of-sync boundaries for audio, video, haptic, scent, taste, and so on.

The mobile metaverse based multi-modal feedback service may be deployed at the edge/cloud server for different scenarios. During the application running period, the physical entities may achieve an immersive experience with their avatars, and the multi-modal feedback data may be exchanged with each other, whether the physical entities are in proximity or nonproximity.

2. Mobile Metaverse for 5G-enabled Traffic Flow Simulation and Situational Awareness

With support of 5GS, real-time information and data about the real objects can be delivered the virtual objects of the road infrastructure and traffic participants including vulnerable road users who can form a smart transport metaverse. Real-time processings computing can be conducted to support traffic simulation and also situational awareness and real time path guidance and real-time safety, or security alerts can be generated for ICVs as well as the driver and passengers.

To support traffic flow simulation and situational awareness service, the 5G network needs to provide low latency, high data rate and high reliability transmission, and in addition, the 5G network may also need to be further enhanced to meet the service requirements for 5G-enabled traffic flow simulation and situation awareness. Meanwhile, in addition to the real objects which may host the UE for cellular system, their corresponding virtual objects are also capable of interacting with each other and interact with physical objects via 5GS.

3. Spatial Mapping and Localization Service Enabler Use Case

A service provider or operator needs to provide and use spatial map information, i.e. a created and employed, both as service enablers. The creation and maintenance of the spatial map is referred to as Spatial Mapping Service and the employment of the map to identify the customer's Localization is termed Spatial Localization Service.

Spatial mapping will classify objects into modelling and tracking of stationary and moving objects. For stationary object, spatial mapping has to estimate the number of objects, type of object and position. Whereas for moving objects, spatial mapping has to determine the position, type of object, direction, speed. Once the spatial mapping service has sufficient information, it has to map all the stationary and moving objects related to UE’s environment. This information may be provided to the UE, service providers and surrounding subscribed users.

It may be a difficult task to perform the mapping of the entire city using a vehicle by traversing various roads and spaces. It also may require a lot of time and effort (for data conversion, etc.) if the work is performed offline. If multiple capturing devices are used in parallel, the spatial map data in the same location could be synthesized over different cameras and input devices to generate the spatial map.

A mobile capturing device, a vehicle or a robot equipped with multiple stereo/mono RGB cameras and multiple LiDAR sensors may be used to capture various qualities of images and depth information of the environments. As an example, a mobile indoor robot may be equipped with two LiDARs, six industrial cameras and four smartphone cameras.

For all scenarios, sensor data are required at the application provider side (e.g. a metaverse application server), which may include sensor data from multiple sources and multiple technologies. There can be a variety of sensing that can be used according to the device capabilities:

• Non-3GPP-based sensors like radar, camera and Lidar sensors, UWB

• NR-based (New radio based) sensing, where the UE and BS senses for stationary and moving objects around the UE. This may involve using time- difference-of-arrival (TDoA), angle-of-arrival (AoA), angle-of-departure (AoD) measurements, RSSI etc.

At the same time, there may be device limitations (e.g. low power nodes) for performing sensing processing, access limitations (bandwidth, latency) for providing the sensing outputs via Uu interfaces, and also processing requirements to fuse/combine sensing data from multiple sources to derive e.g. a spatial map. In addition, different application services may have different requirements in terms of required granularity and accuracy of sensing, and a way may be needed to make the sensing communication optimal so as to avoid wasting network resources.

Some example KPIs for media used for sensor information communication are the following:

As such, collecting real world data for providing an immersive metaverse is a crucial task. The present invention provides an approach of integrating 5G Wireless sensing technology to content providing systems. In particular, the present invention provides techniques for a third party to determine sensing services supported by a 3GPP network and allows requesting a sensing service comprising specific sensing requirements.

The claimed invention allows a third party application to be notified of a sensing event (or a specific sensing event type) in a particular area of interest utilizing the RF sensing capabilities of the 3GPP network as shown in Fig. 1 .

A sensing event can be defined as the 3GPP network detecting an object using RF sensing measurement that meets certain sensing event type criteria. A sensing event type is a sensing event that meets certain sensing criteria (e.g. size of object, moving direction of object etc.). Each sensing event type may be identified by a specific sensing event type identifier. It is expected that the 3GPP network will standardize one or more sensing event types and corresponding identifiers.

In addition, a sensing request may include an indication to report the location of a sensing event of specific sensing event type with specific location accuracy requirements (either horizontal accuracy (in meters) , vertical accuracy (in meters) or both.

According to Fig. 1 , a content provider 116 as an application (such as a metaverse application) may submit a sensing request to a 3GPP sensing function 110. The sensing request may comprise specific sensing requirements, such as the type of sensing required (i.e. determine if a car is in a parking slot), the accuracy (or confidence of the sensing measurement), the accuracy of the location of the sensing event and the latency of responding a sensing event. In a further embodiment, the sensing request may further comprise a location request. Alternatively, the location request can be separate to the sensing request. A location request may be a request for ranging (i.e. range from the sensor node) or a request for positioning (coordinates and height) with specific location accuracy (horizontal accuracy (in meters) or vertical accuracy (height in meters)). In addition, the location request may further include a request for measuring a speed and/or a direction of the object of interest. According to current version of standard 3GPP TR 22.837, an accuracy of positioning estimate is defines that describes the closeness of the measured sensing result (i.e. position) of the target object (object of interest) to its true position value. It can be further derived into a horizontal sensing accuracy - referring to the sensing result error in a 2D reference or horizontal plane, and into a vertical sensing accuracy - referring to the sensing result error on the vertical axis or altitude.

The 3GPP network may then identify which 3GPP-enabled sensing devices would be able support sensing measurements and report a sensing event of specific sensing event type at the particular location and select and configure such devices with sensing configuration in order to report the sensing event requested by the application. For example, the sensing function 110 in Fig. 1 may identify the sensing nodes (which may be sensing radio nodes 126 and/or a RAN 124 as described later) which are available in the area of interest to sense an object of interest 101. After selecting one or more sensing nodes 124/126, the sensing function 110 may send sensing configuration data to the selected sensing nodes 124/126 such that the sensing nodes operate appropriately and may sense the object of interest 101 .

The present invention provides additional details on the 3GPP network to be able to identify which sensing nodes that support sensing capabilities can be used to assist in sensing measurements based on a sensing request by a third party.

Exemplary steps of the invention may be summarized as follows. A service requirement may be obtained from an XR/AI/Metaverse application. This requirement may include the required QoS/QoE for the service, the sensing event criteria in an area of interest, report location of the sensing event, etc. Thereafter, a (third party) application function may discover the sensing services supported by a 3GPP network, where a sensing service is identified by a sensing event type supported (e.g. identification of human, animal, size of object to be determined).

The (third party) application function may send a request to a function in the 3GPP network that supports a sensing service for the request. In this regard, information comprising a sensing event type, a location area, an accuracy of sensing, an indication to report location of the sensing event including location accuracy requirements may be included in the request.

Thereafter, the sensing function 110 in the 3GPP network may determine one or more sensing nodes 124 that can provide sensing information for the requested sensing event at the particular location where each node can be a RAN node, a sensing reference UE, or a UE. The sensing function 110 may send a configuration request to the identified node(s) to provide sensing information. The configuration may be an Al ML model or a pattern that needs to be reported. The sensing function 110 may then collect sensing information from the identified nodes and may determine validity of the sensing measurements (e.g. type of object etc.) corresponding to the criteria of the sensing event requested by the third party.

Additional details that may be required for implementing the third party application requests are shown in Fig. 2.

The sensing function 110 according to the claimed invention may supports the following:

• it may handle all sensing requests.

• it may identify and select the sensing radio nodes 124/126 that can assist in providing sensing event notifications for a sensing event type in a particular location. A sensing radio node can be a Reference UE 126 or a RAN node 124.

• it may configure the sensing radio nodes 124/126 with the sensing event type notification required. The configuration may be an RF pattern to report or providing a trained Al model that assist the sensing radio nodes 124/126 to identify the object 101 based on the RF pattern detected or triggering the sensing radio node to use a specific ML model according to the sensing radio node reported ML model capabilities.

• it may validate that the sensing event notifications provided by each sensing radio nodes 124/126 meets the criteria of the sensing event type requested by the third party 116.

The sensing function 110 may interface with a network repository function (NRF) 120 to register its sensing capabilities. The sensing capabilities may be an area of interest where sensing measurements can be provided and/or sensing event type(s) supported (e.g. sensing a pedestrian). Each sensing event type can be identified by a sensing event identifier.

In an alternative embodiment, all sensing requests may be sent to a GMLC-like function that handles both "legacy" location and sensing requests. The GMLC-like function then requests from the sensing function to report sensing information.

An exemplary procedure and flow of operations for providing a sensing measurement is shown in Figs. 3 and 4. According to an embodiment, Fig. 3 discloses an exemplary scenario, where an application function (AF) 112 is used for generating a sensing request for a sensing event of the 5G network.

A sensing function (SF) 1 10 may initially register its sensing capabilities to the network repository function (NRF) 120 in step S1 . The sensing function 110 may be a network function that may be part of the 5G network. Exemplary capabilities of the sensing function (SF) 120 may comprise one or more of an area of interest (loE) where sensing measurement can be provided by the respective SF 110, a list of Sensing Event Type Identifiers handled or provided by the SF 110 and sensing accuracy provided by the SF 110. However, there may be additional parameters available that may be used in the registration process step S1 . In step S2, the NRF 120 may optionally acknowledge the registration request of the SF 110.

Steps S1 and S2 may be regarded as optional pre-steps before a request for sensing is received.

In step S3 (S3a and S3b), a content provider 116 and/or a user via a user equipment (UE) 114 may require a sensing measurement from the application function (AF) 112. The sensing request may be for a specific use case and the AF 112 may be a third party application function. In step S4, the AF 112 may determine one or more sensing measurement requirements, which may include a sensing event type, an area of interest, an accuracy of sensing measurement. However, the sensing requirements as described above may be exemplary and more or less sensing requirements may be determined by the SF 112.

After the AF 112 determines the requirements, the AF 1 12 may discover, in step S5, an appropriate sensing function that may be able to provide sensing events that conform the request from the content provider 116 or the UE 114. In the example of Fig. 3, it is assumed that the SF 110 is a sensing function that fulfils the requirements.

If the AF 112 is trusted the AF 112 may interface with the NRF 120 to discover the Sensing Function, such as SF 110 in step S5. Alternatively the AF 112 may contact a network exposure function (NEF, not shown) and the NEF may discover the sensing function on behalf of the AF 112 based on the requested sensing event.

Trusted means that the AF 112 may be part of the network and/or may be able and allowed to directly communicate with the different network functions provided by the network. If the AF 112 is not trusted, it may be limited in directly interacting with the network functions and may use/interface an NEF instead. As will be later discussed with regard to Fig. 4, in an alternative embodiment, the request may be sent to a gateway mobile location centre- (GMLC-) like function that may handle location and sensing requests. The GMLC-like function may then send a request to the Sensing Function via an access and mobility function (AMF) 122. More details concerning this alternative scenario are shown in Fig. 4.

In step S6, the AF 112 may send a sensing request (or a sensing measurement request) to the Sensing Function SF 110 that has the sensing measurement requirements identified in step S4. In some cases, if the AF 112 is a third party, the request may be sent to the NEF (not shown) and the NEF forwards it to the SF 110 (the request may also be received via a GMLC-like function, as shown in Fig. 4). the sensing request (or sensing measurement request) may comprise one or more sensing requirement parameters. Exemplary sensing requirement parameters may be a sensing event type, a location area of interest, an accuracy of sensing, an indication to provide a location of the sensing event indication, and a corresponding location accuracy requirement. The request may comprise one or more of these parameters and may also comprise additional or other parameters.

In step S7, the SF 110 may determine one or more sensing radio nodes 126 and/or radio access networks 124 that may be able to provide a sensing event notification according to the sensing measurement requirements in step S4 or as specified in the sensing requirement parameters. For example, each SRN 126 may comprise a specific sensing capability, which may include one or more Al ML models stored in the sensing radio node that support monitoring of one or more sensing event types. In the following, the description refers to sensing radio nodes (SRNs) 126 only, but it is to be understood that RAN 124 may always be an alternative to SRNs 126 and may likewise be used. The step S7 of determining SRNs in the Ao I may comprise the sub-steps S8 to S10.

For example, in step S8, the SF 110 may interface with a sensing location register (SLR) 118 to discover sensing radio nodes and/or a RAN in the area of interest that may be able to provide a sensing event notification according the sensing event type requested. The sensing location register 118 may be a location management function (LMF), an access and mobility function (AMF) or a unified data management (UDM) that may have information on the location of the sensing radio nodes in the area of interest where sensing is requested. The discovery request may include an area of interest and a sensing event type. In an alternative embodiment each sensing radio node 126 or RAN 124 may register its sensing capabilities to the sensing function 110 directly. In such case the sensing function 110 may cover a specific area of interest. In step S9, the sensing location register 118 may retrieve the sensing radio nodes (e.g. SRN 126 and/or RAN 124) that can assist in providing sensing measurement in the area of interest. The sensing location register 118 may respond with the requested information in step S10.

After discovering the appropriate SRNs 126, i.e. either by the procedure of steps S8 to S10 or via other mechanisms, such as each SRNs 126 registering itself at the sensing function 110, the sensing function 110 may select one or more SRNs 126 for providing a sensing measurement at step S11 . According to an embodiment, the selection may simply include using all SRNs 126 as discovered in steps S8 to S10. In another embodiment, the selection of step S11 may include selecting the SRNs 126 based on their capabilities. The sensing function 110 may in some embodiments further determine the configuration for the SRNs 126 and/or the selected RAN 124. The Configuration may be a radio pattern to monitor or use a specific Al model for tracing RF measurements.

In steps S12 and S13, the sensing function 110 may send a sensing monitoring request to the selected SRNs 126 (and/or RAN 124). The request may include a specific ML model or the sensing type to report. This may include transmitting the corresponding configuration data determined in step S11 to the respective one or more SRNs 124 that have been selected for sensing. In addition, the sensing function 110 may use a sensing correlation identification/identifier for the sensing monitoring request and may transmit the sensing correlation identifier to the selected SRNs 126.

After receiving the sensing monitoring request from the sensing function 110, the SRNs 126/124 may detect a sensing event of the specific event type in steps S14 and/or S15. This may include applying the configuration data received from the sensing function 110 and operating according to the configuration data. When the SRNs 126 identify a pattern, the sensing radio nodes 126 may report the measurement to the sensing function 110 in step S16 and/or S17. The sensing measurement may include the RF measurements collected. The information may include the sensing correlation identifier as described above.

In step S18, the sensing function may aggregate the sensing measurements from the selected sensing radio nodes 126. The sensing function 110 may be able to correlate all sensing and location information using the sensing correlation identifier provided by the sensing radio nodes 126. In some embodiments, where enhanced location data are also to be provided by the SRNs 126, a location management function (LMF) may further be involved and the LMF may also provide the sensing correlation identifier. The sensing function 110 may validate that the reported sensing measurement correspond to the sensing event type requested by the application function 112. The sensing function 110 may use an artificial intelligence (Al) model to validate the sensing measurement.

According to an embodiment, the validation may refer to a confidence level of the sensing result. For example, if the validation results in a positive validation, the sensing event may be with a high certainty (such as 95%) of the sensing event type that has been specified in the sensing request. If the validation results in a negative validation, the confidence level may be lower, such as 50% or less.

The sensing function 110 may then in step S19 report the sensing event of the sensing measurement to the application function 112. The report in S19 may include an indication of accuracy of a location of the sensing event. The report may in some embodiments further include the confidence level that has been determined in step S18. The application function 112 may then forward the sensing measurement to the content provider 116 or the UE 114 in steps S20a and/or S20b.

An alternative procedure where a GMLC-like function handles both location and sensing request is shown in Fig. 4. The operational flow of Fig. 4 is similar to the operational flow of Fig. 3, but contains some additional steps, additional functions and some of the operations may differ from Fig. 3.

A sensing function 110 may initially register its sensing capabilities to the network repository function (NRF) 120 in step ST. The sensing function 110 may be a network function that may be part of the 5G network. Exemplary capabilities of the sensing function 120 may comprise one or more of an area of interest (loE) where sensing measurement can be provided by the respective SF 110, a list of Sensing Event Type Identifiers handled or provided by the SF 110 and sensing accuracy provided by the SF 110. However, there may be additional parameters available that may be used in the registration process step ST. In step S2’, the NRF 120 may optionally acknowledge the registration request of the SF 110.

Steps ST and S2’ may be regarded as optional pre-steps before a request for sensing is received.

In step S3’ (S3a’ and S3b’), a content provider 116 and/or a user via a user equipment (UE) 114 may require a sensing measurement from the application function (AF) 112. The sensing request may be for a specific use case and the AF 112 may be a third party application function. In step S4’, the AF 112 may determine one or more sensing measurement requirements, which may include a sensing event type, an area of interest, an accuracy of sensing measurement. However, the sensing requirements as described above may be exemplary and more or less sensing requirements may be determined by the sensing function 112. In some embodiments, the application function 112 may itself identify sensing radio nodes 126 in the area of interest.

After the AF 112 determines the requirements, the AF 112 may, in step S5’, discover a gateway function 202 that may be able to provide the sensing event. If the AF 112 is trusted the AF 112 may interface with the NRF 120 to discover the gateway function 202. Alternatively the AF 112 may contact a network exposure function first (NEF, not shown) and the NEF may discover the gateway function on behalf of the AF 112 based on the requested sensing measurement requirements. Trusted means that the AF 112 may be part of the network and/or may be able and allowed to directly communicate with the different network functions provided by the network. If the AF 112 is not trusted, it may be limited in directly interacting with the network functions and may use/interface an NEF instead.

The AF 112 sends, in step S6’, a sensing measurement request to the gateway function 202 that may include the sensing measurement requirements identified in step S4’. If the AF 112 is a third party, the request may be sent to the NEF and the NEF may forward the request to the gateway function 202. If this sensing measurement request does not contain any information on sensing radio nodes 126 (or 124), the gateway function may interface with a sensing location register 118. in step S7’ to retrieve information of available sensing radio nodes 126 and/or RAN 124. The gateway function 202 may then send a discovery request to the sensing location register 118.

At this point, or in some embodiments even before that point, at step S8’, the sensing location register 118 may retrieve information about available SRNs 126 in the location of interest. In step S9’, the sensing location register 118 may provide a list of sensing radio nodes 124/126.

In step S10’, the gateway function 202 may select sensing radio nodes (i.e. one or more of the SRNs 126 and/or the RAN 124) that support the sensing request. For example, each SRN 126 may comprise a specific sensing capability, which may include one or more Al ML models stored in the sensing radio node that support monitoring of one or more sensing event types. According to an embodiment, the selection may simply include using all SRNs 126 as discovered. In another embodiment, the selection may include selecting the SRNs 126 based on their capabilities. If the above steps S7’ to S10’ occurred, the gateway function 202 may then in step S11’ discover the access and mobility function (AMF) 122 serving the area of interest for sensing and the selected sensing radio nodes. The gateway function 202 may then forward the sensing measurement request to the AMF 122 in step S12’. The sensing measurement request may include a list of sensino radio nodes 124/126, such as one or more SRN identifiers. Alternatively the gateway function 202 may send separate requests per identified sensing radio node.

In step S13’, the AMF 122 may discover a sensing function 110 that serves the area of interest and supports the sensing event type(s) requested. This may include discovering the sensing function 110 via the NRF 120. The AMF 122 may then, in step S14’ select a sensing function that serves at the area of interest and supports the sensing event type(s) requested. In the illustration of Fig. 4, the sensing function 110 is selected.

In step S15’, the AMF 122 may send a sensing request to the selected sensing function 110. The request may include the sensing measurement requirements received by the gateway function 202, such as the sensing requirement parameters. The request may further include a sensing correlation identifier that the AMF 122 may have assigned or received by the gateway function 202. If the sensing request in step S12’ includes a sensing radio node identifier then the AMF 122 may send separate request to the sensing function 110 per sensing radio node granularity.

If the request of step S12’ does not contain a SRN identifier, the sensing function 110 may send a request to the sensing location register 118 to retrieve information on the available sensing radio nodes in the area of interest in step S16’. Thus, steps S16’ to S18’ may be an alternative procedure of discovering appropriate SRNs 126 in the area of interest and may therefore be optional. According to an embodiment, the selection may simply include using all SRNs 126 as discovered above. In another embodiment, the selection of step S11 may include selecting the SRNs 126 based on their capabilities In an alternative embodiment, the sensing radio nodes may have registered their capabilities to the sensing function 110. In step S17’ the sensing location register may retrieve the information on the SRNs (e.g. SRN 126 and/or RAN 124) that can assist in providing sensing measurement in the area of interest. The sensing location register 118 may respond with the requested information in step S18’.

After discovering the appropriate SRNs 126, i.e. either by the procedure of steps S16’ to S18’ or via other mechanisms, such as each SRNs 126 registering itself at the sensing function 110, or identification of the SRNs 126 at the gateway function 202, the sensing function 1 10 may select one or more SRNs 126 for providing a sensing measurement in step S19’. According to an embodiment, the selection may simply include using all SRNs 126 as discovered. In another embodiment, the selection may include selecting the SRNs 126 based on their capabilities. The SF 110 may in some embodiments further determine the configuration for the SRNs 126 and/or the selected RAN 124. The Configuration may be a radio pattern to monitor or use a specific Al model for tracing RF measurements. In steps S20’ and S2T, the sensing function 110 may send a sensing monitoring request to each selected SRN 126 (and/or RAN 124). The request may include a specific ML model or the sensing type to report. The request may be sent to the sensing radio nodes 126 via control plane signaling via the AMF 122 or via user plane using a new protocol. Steps S20’ and S2T may further include transmitting the corresponding configuration data determined in step S19’ to the respective one or more SRNs 124 that have been selected for sensing. In addition, the sensing function 110 may use the sensing correlation identifier for the sensing monitoring request and may transmit the sensing correlation identifier to the selected SRNs 126.

After receiving the sensing monitoring request from the sensing function 110, the SRNs 126/124 may detect a sensing event of the specific event type in steps S22’ and/or S23’. This may include applying the configuration data received from the sensing function 110 and operating according to the configuration data. When the SRNs 126 identify a pattern, the sensing radio nodes 126 may report the measurement to the sensing function 110 in step S24’ and/or S25’. For example, when the sensing radio nodes 126 identify a pattern that meets criteria of the sensing event type, the sensing radio nodes 126 may report the measurement to the sensing function 110. The sensing measurement may include the RF measurements collected. The information may include the sensing correlation identifier as described above.

In step S26’, the sensing function 110 may aggregate the sensing measurements from the selected sensing radio nodes 126. The sensing function 110 may be able to correlate all sensing measurements using the sensing correlation identifier. The sensing function 110 may validate that the reported sensing measurement(s) correspond to the sensing event type requested by the application function 112. The sensing function 110 may use an Al model to validate the sensing measurement(s). Alternatively, the validation and/or the aggregation may be performed by the gateway function 202.

According to an embodiment, the validation may refer to a confidence level of the sensing result. For example, if the validation results in a positive validation, the sensing event may be with a high certainty (such as 95%) of the sensing event type that has been specified in the sensing request. If the validation results in a negative validation, the confidence value may be lower, such as 50% or less.

In step S27’, the sensing function 110 may provide the sensing information to the AMF 122. The sensing information may include the sensing correlation identifier. The AMF 122 may then in step S28’ report the sensing event of the sensing measurement to the gateway function 202. The report may in some embodiments further include the confidence level that has been determined in step S26’. The report in S28’ mav further include an indication of accuracy of a location of the sensing event. Separate signaling may be used for sensing and location measurements, if separate requests (i.e. for location and sensing) were sent from the gateway function 202. The gateway function 202 may then provide the information to the application function 112 in step S29’ and the application function 112 may forward the sensing measurement to the content provider 116 or the LIE 114 in steps S30a’ and/or S30b’.

In alternative embodiments to the ones discussed above, the gateway function 202 may interface with a sensing location register (not shown) to discover sensing radio nodes in the area of interest. The sensing location register may be an LMF, AMF or UDM that has information on the location of the sensing radio nodes in the area, where sensing is requested. The request/interfacing may include an area of interest and a sensing event type. In an alternative embodiment, each sensing radio node 126 may register its sensing capabilities to the sensing location register 118. In such embodiment, once the identity of a sensing radio node 126 is retrieved, the gateway function 202 determines which sensing radio nodes 126 are in the area of interest as received in step S4 (S4’). The gateway function 202 may interface with the UDM to find the serving radio nodes 126 available in the area of interest.

As a further alternative embodiment for both scenarios (i.e. Fig. 3 and Fig. 4), instead of a sensing location register 118, the sensing radio nodes 126 may registers their capabilities directly to the sensing function 110 using user plane signaling or the sensing radio nodes 126 may provide an indication to the AMF 122 during registration that the AMF 122 may forward to the sensing function 110 or the AMF 122 may store the sensing capabilities of each sensing radio node 126 and forward to the sensing function 110 when sensing a sensing request.

The above described features may be implemented as a computer-implemented method in a mobile telecommunications network. All the above described network functions may be computer functions that run on either on a standalone computer server that implements the corresponding functions or different network functions may share one or more computer servers. The computer server comprise respective computer hardware, such as at least one processor, at least one memory for saving computer-readable instructions that may be executed by the processor. The computer server may additionally comprise components for communicating with other computers or network devices, such as a network interface card.