Apparatus and method for requesting and reporting wireless communication sensing

Abstract

There is provided an apparatus in a wireless communication system, the apparatus comprising: a processor; and a memory coupled with the processor, the memory containing instructions that, when executed by the processor, cause the device to receive a service request issued by a consumer entity, wherein the service request is a subscription request to cause the consumer entity to subscribe to receive a sensing result or a request to receive a single response comprising a sensing result to the consumer entity; collecting sensing data according to the service request; processing the sensing data to create the sensing result; and transmitting the sensing result for use by the consumer entity.

Description

Technical Field

[0001] The topics disclosed in this document generally relate to the field of sensing using wireless communication systems. This document defines devices and methods for sensing using wireless communication. Background Technology

[0002] Integrated Sensing and Communication (ISAC) combines sensing and communication systems. It enables the inclusion of sensing capabilities, such as radar and radar-like sensing, within a communication network. This sensing capability can be used to obtain information related to, for example, shape, size, orientation, speed, position, distance, or relative motion between objects, using New Radio Interface (NR) radio frequency (RF) signals and, in some cases, previously defined information available in the Evolved Packet Core (EPC) and / or Evolved Universal Terrestrial Radio Access (E-UTRA) as described in TR 22.837. Summary of the Invention

[0003] The benefits of integrated sensing and communication in 5G lie in the fact that its operation is based on existing wireless infrastructure that provides coverage to take advantage of the benefits of radio signal sensing. Moreover, the 5G core can often assist in collecting other information related to user equipment (UE), policies, and analytics, and can facilitate sensing exposure to external network consumers (e.g., application functions (AF)).

[0004] Currently, TR 22.837 and 5G Advanced IMT-2020 have introduced some preliminary requirements related to requesting sensing services and reporting sensing results (i.e., processed sensing output information). Assume a sensing consumer should issue a sensing request to the sensing function (SF), indicating the type of sensing service, the sensing area or sensing target, and providing details of the sensing object (e.g., size details), the desired format of the sensing results, the sensing confidence level, and details about how the sensing results will be delivered, i.e., which protocol will be used and through which node the sensing results should be made available to the consumer.

[0005] However, there is no clear description of the request and response mechanism (i.e., the subscription or request operation process) that includes a list of potentially sensing-specific attributes. Specifically, in many cases, sensing processing involves mobile objects as described in TR 22.837, for example, considering vehicles or drones. Sensing requests need to reflect potential mobility-specific attributes related to the mobile UE, object, or environmental conditions. Furthermore, the request and response do not consider any Network Open Function (NEF) extensions related to handling sensing requests and opening sensing results to untrusted AFs.

[0006] The aspects provided in this document are: (i) a sensing process for subscribing to and requesting sensing services considering trusted and untrusted consumers, (ii) sensing openness focusing on, for example, mobility aspects, and (iii) sensing operations for subscribing to, requesting, notifying, reporting, and retrieving sensing results in the context of a sensing process for subscribing to and requesting sensing services.

[0007] This document discloses a process for requesting and reporting wireless communication sensing. This process can be implemented by the devices disclosed herein.

[0008] A device is provided in a wireless communication system, the device comprising: a processor; and a memory coupled to the processor, the memory containing instructions, when executed by the processor, to cause the device to: receive a service request from a consumer entity, wherein the service request is a subscription request to cause the consumer entity to subscribe to receiving sensing results or a request for the consumer entity to receive a single response including sensing results; collect sensing data according to the service request; process the sensing data to create sensing results; and transmit the sensing results for use by the consumer entity.

[0009] A method in a device within a wireless communication system is further provided, the method comprising: receiving a service request from a consumer entity, wherein the service request is a subscription request to enable the consumer entity to subscribe to receiving sensing results, or a request for the consumer entity to receive a single response including the sensing results; collecting sensing data according to the service request; and transmitting the sensing results for use by the consumer entity.

[0010] A further provision provides an apparatus in a wireless communication system, the apparatus comprising: a processor; and a memory coupled to the processor, the memory containing instructions, when executed by the processor, to cause the apparatus to: receive a service request from a consumer entity, wherein the service request is a subscription request to cause the consumer entity to subscribe to receiving sensing results, or a request for the consumer entity to receive a single response including sensing results; process the service request to enforce one or more restrictions on one or more parameters of the service request; and transmit the processed service request to a sensing function in the wireless communication system.

[0011] A further provision provides an apparatus in a wireless communication system, the apparatus comprising: a processor; and a memory coupled to the processor, the memory containing instructions, when executed by the processor, to cause the apparatus to perform the following operations: receiving sensing results from a sensing function for transmission to a consumer entity; processing the sensing results to enforce one or more restrictions on one or more parameters of the sensing results; and transmitting the processed sensing results to the consumer entity.

[0012] A method in a device within a wireless communication system is further provided, the method comprising: receiving a service request from a consumer entity, wherein the service request is a subscription request to enable the consumer entity to subscribe to receiving sensing results, or a request for the consumer entity to receive a single response including sensing results; processing the service request to enforce one or more restrictions on one or more parameters of the service request; and transmitting the processed service request to a sensing function in the wireless communication system.

[0013] A method in a device within a wireless communication system is further provided, the method comprising: receiving sensing results from a sensing function for transmission to a consumer entity; processing the sensing results to enforce one or more restrictions on one or more parameters of the sensing results; and transmitting the processed sensing results to the consumer entity. Attached Figure Description

[0014] To illustrate the advantages and features of this disclosure, the description of the disclosure is presented with reference to certain apparatuses and methods illustrated in the accompanying drawings. Each of these drawings depicts only certain aspects of the disclosure and should therefore not be construed as limiting its scope. For clarity, the drawings may have been simplified and are not necessarily drawn to scale.

[0015] A method and apparatus for requesting and reporting wireless communication sensing will now be described by way of example only with reference to the accompanying drawings, in which:

[0016] Figure 1a This is a schematic illustration of a tightly coupled ISAC network architecture;

[0017] Figure 1b This is a schematic illustration of a tightly coupled ISAC network architecture with control plane / user plane (CP / UP) segmentation;

[0018] Figure 1c This is a schematic illustration of the architecture where SF and LMF are co-located;

[0019] Figure 1d This is a schematic illustration of a loosely coupled ISAC network architecture (not drawn to scale);

[0020] Figure 2 An embodiment of a wireless communication system in which request and report wireless communication sensing is implemented is described;

[0021] Figure 3 Describe user equipment devices that can be used to implement the methods described herein;

[0022] Figure 4Further details of the network nodes that can be used to implement the methods described in this paper are provided.

[0023] Figure 5 This is a flowchart illustrating the sensing subscription and / or unsubscription process in a wireless communication system;

[0024] Figure 6 This is a flowchart illustrating the process of subscribing to and / or canceling a sensor involving untrusted AF and NEF.

[0025] Figure 7 This is a flowchart illustrating the sensing request process in a wireless communication system;

[0026] Figure 8 This is a flowchart illustrating the sensing request process involving untrusted AF and NEF;

[0027] Figure 9 This document describes a flowchart illustrating the process of a method in a device within a wireless communication system.

[0028] Figure 10 A flowchart illustrating the process of a method in a device within a wireless communication system; and

[0029] Figure 11 This describes a flowchart illustrating the process of a method in a device within a wireless communication system. Detailed Implementation

[0030] For the purposes of this disclosure, the following definitions from TR 22.837 have been adopted:

[0031] -3GPP Sensing Data: Data derived for sensing purposes from 3GPP radio signals affected by the object of interest or environment (e.g., reflection, refraction, and / or diffraction) and optionally processed within a 5G system.

[0032] -Sensing results: Processed 3GPP sensing data requested by the service consumer.

[0033] - Sensing service area: The service area where sensing services will rely solely on infrastructure and sensing technology, which can be assumed to exist anywhere 5G is present. This includes both indoor and outdoor environments.

[0034] - Target area to be sensed: The area to be sensed by deriving the dynamic characteristics of the area from any moving obstacle (e.g., a car, a human, an animal) from the affected (e.g., reflected, refracted, and / or diffracted) wireless signals.

[0035] There can be two types of target regions, including:

[0036] Static sensing target area: A predefined area that does not move from the perspective of the sensing transmitter.

[0037] Motion sensing target area: A reliable area of ​​a moving target as seen from the perspective of the sensing transmitter.

[0038] - Confidence level: This describes the percentage of all possible measured sensing results that can be expected to contain the true sensing results, taking into account accuracy.

[0039] - Sensing resolution: This describes the minimum difference in the measured values ​​of a target object (e.g., range, velocity) that allows the detection of objects with different values.

[0040] -Maximum Sensing Service Latency: The time elapsed between the definite event that triggers the sensing result and the availability of the sensing result at the sensing system interface.

[0041] - Refresh rate: The rate at which the sensing system generates sensing results. It is the reciprocal of the time elapsed between two consecutive sensing result reports sent to the application server.

[0042] Sensing can be associated with a target UE, i.e., an object without network connectivity, such as an object without a SIM card, or with an object used to obtain environmental characteristics, such as sensing weather conditions to determine whether it is raining. Sensing can utilize radio signals from one or more base stations, i.e., a group of sensors whose locations are known and whose sensing measurement data can be collected synchronously. The collected sensing data can then be provided to a mobile core network, which determines the sensed target and its corresponding characteristics.

[0043] Integrated sensing and communication can enhance the 5G core architecture by introducing new sensing functions (SF). IMT-2020 considers four recommendations to enhance the 5G core by introducing SF as a dedicated or logical network function (NF). These are in... Figure 1a The illustration is shown in section d.

[0044] Figure 1a This is a schematic illustration of a tightly coupled ISAC network architecture. In this architecture, the SF (Specialized Network Function) acts as a dedicated network function (NF) that handles both: (i) the sensing control plane aspect for collecting UE information (e.g., UE-related policies from the Access and Mobility Management Function (AMF), Unified Data Management (UDM), Location Management Function (LMF), UE-related policies from the Policy Control Function (PCF), and analysis from the Network Data Analysis Function (NWDAF), such as interaction with sensing consumers via the NEF and information exchange with other NFs; and (ii) sensing radio signals for performing analysis or prediction to determine sensing targets.

[0045] Figure 1bThis is a schematic illustration of a tightly coupled ISAC network architecture with control plane / user plane (CP / UP) segmentation. In this architecture, the SF has two dedicated NF counter sections: (i) SF-C, which handles the control plane aspect as described above (regarding...). Figure 1a (ii) the tightly coupled ISAC network architecture, and (iii) the SF-U, which is responsible for collecting sensed radio signals via the user plane (i.e., via the Radio Access Network (RAN) and User Plane Function (UPF)). The idea behind this architecture is to segment and offload the large amount of data associated with sensed radio signals to the user plane to ensure low traffic in the control plane, i.e., signaling only.

[0046] Figure 1c This is a schematic illustration of the architecture where SF and LMF are co-located. SF is represented by logical NF embedded in LMF to perform sensing using knowledge of the UE's location.

[0047] Figure 1d This is a schematic illustration of a loosely coupled ISAC network architecture (not drawn to scale). In this architecture, the SF (Surface Standby) is independent of the 5G core. For example, the SF can be used in local field scenarios or dedicated networks, and its interaction with the 5G core is minimal. The main idea is to use the SF close to the RAN, for example, to collect and process sensed radio signals locally, and to interact with the 5G core via NEF (Network Window) to obtain UE location from the AMF (Active Location Function) for analysis (NWDAF).

[0048] The benefits of integrated sensing and communication in 5G lie in its operation based on existing wireless infrastructure that provides coverage to leverage the benefits of radio signal sensing. Furthermore, the 5G core can assist in collecting additional information related to UEs, policies, and analytics, and can facilitate sensing openness to external network consumers (e.g., AFs).

[0049] Currently, TR 22.837 and 5G Advanced IMT-2020 introduce some preliminary requirements related to requesting sensing services and reporting sensing results (i.e., processed sensing output information). It can be assumed that the sensing consumer should issue a sensing request to the SF, indicating the type of sensing service, the sensing area and / or the sensing target, providing detailed information about the sensing object (e.g., size details), the desired format of the sensing results, the sensing confidence level, and details on how the sensing results should be delivered, i.e., which protocol to use and through which node the sensing results should be made available to the consumer.

[0050] However, there is typically no request and response mechanism, such as a subscription or request procedure, that includes a clear description of a list of potentially sensing-specific attributes. Specifically, in many cases, sensing processing involves mobile objects as described in TR 22.837, such as vehicles or drones. Sensing requests preferably reflect potential mobility-specific attributes related to the mobile UE, object, and / or environmental conditions. Furthermore, the request and response do not consider any NEF extensions related to handling sensing requests and opening sensing results to untrusted AFs.

[0051] This disclosure describes: (i) a sensing process for subscribing to and requesting sensing services considering trusted and untrusted consumers, (ii) sensing open content primarily focused on mobility, and (iii) sensing operations for subscribing to, requesting, notifying, reporting, and retrieving sensing results in the context of the sensing process for subscribing to and requesting sensing services.

[0052] Before delving further into the details of the techniques presented herein, it should be noted that, as those skilled in the art will understand, aspects of this disclosure can be embodied as systems, devices, methods, or program products. Therefore, the arrangements described herein can be implemented entirely in hardware, entirely in software (including firmware, resident software, microcode, etc.), or in a combination of software and hardware aspects.

[0053] For example, the disclosed methods and apparatus can be implemented as hardware circuitry, including custom-designed very large-scale integration (“VLSI”) circuitry or gate arrays, off-the-shelf semiconductors, such as logic chips, transistors, or other discrete components. The disclosed methods and apparatus can also be implemented in programmable hardware devices, such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed methods and apparatus may include one or more physical or logical blocks of executable code, which may, for example, be organized as objects, processes, or functions.

[0054] Furthermore, the method and apparatus may take the form of a program product embodied in one or more computer-readable storage devices storing machine-readable code, computer-readable code, and / or program code (hereinafter referred to as "code"). The storage device may be tangible, non-transitory, and / or non-transferable. The storage device may not embody signals. In some arrangements, the storage device employs only signals for accessing the code.

[0055] Any combination of one or more computer-readable media may be used. The computer-readable media may be a computer-readable storage medium. The computer-readable storage medium may be a storage device for storing code. The storage device may be (e.g., but not limited to) an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, device, or apparatus, or any suitable combination thereof.

[0056] More specific examples of storage devices (a non-exhaustive list) will include the following: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (“RAM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM” or flash memory), portable optical disc read-only memory (“CD-ROM”), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, computer-readable storage media can be any tangible medium that can contain or store programs for use by or in connection with an instruction execution system, device, or apparatus.

[0057] Throughout this specification, references to instances of a particular method or apparatus or similar terminology mean that a particular feature, structure, or characteristic described in connection with that instance is included in at least one embodiment of the method or apparatus described herein. Therefore, references to features of instances of a particular method or apparatus or similar terminology may, but do not necessarily all refer to the same instance, but rather mean "one or more, but not all, instances," unless otherwise expressly specified. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise expressly specified. An enumerated list of items does not imply that any or all items are mutually exclusive unless otherwise expressly specified. The terms "a," "an," and "described" also mean "one or more," unless otherwise expressly specified.

[0058] As used herein, a list containing the conjunction “and / or” includes any single item in the list or a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one or more of…” includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one of…” includes one and only one of any single item in the list. For example, “one of A, B, and C” includes only A, only B, or only C, excluding combinations of A, B, and C. As used herein, “selected as a member of the group consisting of A, B, and C” includes one and only one of A, B, or C, excluding combinations of A, B, and C. As used in this article, “selecting members of a group consisting of A, B, and C and their combinations” includes only A, only B, only C, combinations of A and B, combinations of B and C, combinations of A and C, or combinations of A, B, and C.

[0059] Furthermore, the features, structures, or characteristics described herein can be combined in any suitable manner. Numerous specific details (e.g., examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc.) are provided in the following description to provide a thorough understanding of this disclosure. However, those skilled in the art will recognize that the disclosed methods and apparatus can be practiced without one or more of the stated specific details, or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of this disclosure.

[0060] The following description of aspects of the disclosed methods and apparatus is based on schematic flowcharts and / or block diagrams of methods, apparatus, systems, and program products. It should be understood that each block of the schematic flowcharts and / or block diagrams, and combinations of blocks in the schematic flowcharts and / or block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that instructions executed via the processor of the computer or the other programmable data processing apparatus create components for implementing the functions / actions specified in the schematic flowcharts and / or block diagrams.

[0061] The code may also be stored in a storage device, and the code may instruct a computer, other programmable data processing equipment or other devices to function in a particular manner, causing the instructions stored in the storage device to produce an article of writing, including instructions to implement the functions / actions specified in the schematic flowchart and / or schematic block diagram.

[0062] The code may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the code executing on the computer or other programmable device provides a process for implementing the functions / actions specified in the schematic flowchart and / or schematic block diagram.

[0063] The schematic flowcharts and / or block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of the devices, systems, methods, and program products. In this regard, each box in the schematic flowcharts and / or block diagrams may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing the specified logical function.

[0064] It should also be noted that in some alternative implementations, the functions mentioned in the boxes may not appear in the order shown in the figures. For example, in fact, depending on the functionality involved, two boxes shown consecutively may be performed substantially simultaneously, or the boxes may sometimes be performed in reverse order. Other steps and methods that are functionally, logically, or effectively equivalent to one or more boxes or portions thereof in the illustrated figures are conceivable.

[0065] The description of the components in each figure can be found in the previous figure. Similar numbers in all figures refer to similar components.

[0066] Figure 2 An embodiment of a wireless communication system 100 in which requesting and reporting wireless communication sensing is implemented is depicted. In one embodiment, the wireless communication system 100 includes a remote unit 102 and a network unit 104. Although a specific number of remote units 102 and network units 104 are depicted in FIG. 1, those skilled in the art will recognize that any number of remote units 102 and network units 104 may be included in the wireless communication system 100. The wireless communication system may include a wireless communication network and at least one wireless communication device. The wireless communication device is typically a 3GPP user equipment (UE). The wireless communication network may include at least one network node. The network node may be a network unit.

[0067] In one embodiment, remote unit 102 may include a computing device, such as a desktop computer, laptop computer, personal digital assistant (“PDA”), tablet computer, smartphone, smart TV (e.g., a TV connected to the Internet), set-top box, game console, security system (including security cameras), in-vehicle computer, network device (e.g., router, switch, modem), aircraft, drone, etc. In some embodiments, remote unit 102 includes a wearable device, such as a smartwatch, fitness tracker, optical head-mounted display, etc. Furthermore, remote unit 102 may refer to subscriber unit, mobile device, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, UE, user terminal, device, or other terms used in the art. Remote unit 102 may communicate directly with one or more of network units 104 via UL communication signals. In some embodiments, remote unit 102 may communicate directly with other remote units 102 via sidelink communication.

[0068] Network unit 104 can be distributed across a geographical area. In some embodiments, network unit 104 may also be referred to as access point, access terminal, base station, base station, Node B, eNB, gNB, home Node B, relay node, device, core network, air server, radio access node, AP, NR, network entity, access and mobility management function (“AMF”), unified data management function (“UDM”), unified data repository (“UDR”), UDM / UDR, policy control function (“PCF”), radio access network (“RAN”), network slice selection function (“NSSF”), operation management and maintenance (“OAM”), meeting The terms used refer to: Voice Management Function (“SMF”), User Plane Function (“UPF”), Application Function, Authentication Server Function (“AUSF”), Security Anchor Function (“SEAF”), Trusted Non-3GPP Gateway Function (“TNGF”), Application Function, Service Enablement Architecture Layer (“SEAL”) Function, Vertical Application Enablement Server, Edge Enablement Server, Edge Configuration Server, Mobile Edge Computing Platform Function, Mobile Edge Computing Application, Application Data Analytics Enablement Server, SEAL Data Delivery Server, Middleware Entity, Network Slicing Capability Management Server, or any other terminology used in the art. Network Unit 104 is typically part of a radio access network that includes one or more controllers communicatively coupled to one or more corresponding network units 104. The radio access network is typically communicatively coupled to one or more core networks that may be coupled to other networks, such as the Internet and the Public Switched Telephone Network, and other networks. These and other elements of the radio access and core networks are not described but are generally well known to those skilled in the art.

[0069] In one implementation, the wireless communication system 100 is compatible with the New Radio (NR) protocol standardized in 3GPP, wherein network unit 104 transmits using an Orthogonal Frequency Division Multiplexing (“OFDM”) modulation scheme on the downlink (DL) and remote unit 102 transmits using a Single Carrier Frequency Division Multiple Access (“SC-FDMA”) scheme or an OFDM scheme on the uplink (UL). However, more generally, the wireless communication system 100 may implement other open or proprietary communication protocols, such as WiMAX, IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, etc.

[0070] ZigBee, Sigfox, LoraWAN, and other protocols. This disclosure is not intended to limit implementations to any particular wireless communication system architecture or protocol.

[0071] Network unit 104 can provide services to several remote units 102 within a service area (e.g., a cell or cell sector) via a wireless communication link. Network unit 104 transmits DL communication signals to serve the remote units 102 in the time domain, frequency domain, and / or spatial domain.

[0072] Figure 3 User equipment device 200 is depicted that can be used to implement the methods described herein. User equipment device 200 is used to implement one or more of the solutions described herein. User equipment device 200 corresponds to one or more of the user equipment devices described in the embodiments herein. User equipment device 200 includes processor 205, memory 210, input device 215, output device 220, and transceiver 225.

[0073] Input device 215 and output device 220 may be combined into a single device, such as a touchscreen. In some embodiments, user equipment device 200 may not include any input device 215 and / or output device 220. User equipment device 200 may include one or more of the following: processor 205, memory 210, and transceiver 225, and may not include input device 215 and / or output device 220.

[0074] As depicted, transceiver 225 includes at least one transmitter 230 and at least one receiver 235. Transceiver 225 can communicate with one or more cells (or radio coverage areas) supported by one or more base units. Transceiver 225 can operate on unlicensed spectrum. Furthermore, transceiver 225 may include multiple UE panels supporting one or more beams. Additionally, transceiver 225 may support at least one network interface 240 and / or application interface 245. Application interface 245 may support one or more APIs. Network interface 240 may support 3GPP reference points, such as Uu, N1, PC5, etc. Other network interfaces 240 may be supported, as will be understood by those skilled in the art.

[0075] Processor 205 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 205 may be a microcontroller, microprocessor, central processing unit (“CPU”), graphics processing unit (“GPU”), auxiliary processing unit, field-programmable gate array (“FPGA”), or similar programmable controller. Processor 205 may execute instructions stored in memory 210 to perform the methods and routines described herein. Processor 205 is communicatively coupled to memory 210, input device 215, output device 220, and transceiver 225.

[0076] Processor 205 can control user equipment device 200 to perform the user equipment device behaviors described herein. Processor 205 may include an application processor (also referred to as the "main processor") that manages application domain and operating system ("OS") functions and a baseband processor (also referred to as the "baseband radio processor") that manages radio functions.

[0077] Memory 210 may be a computer-readable storage medium. Memory 210 may include volatile computer storage media. For example, memory 210 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). Memory 210 may include non-volatile computer storage media. For example, memory 210 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. Memory 210 may include both volatile and non-volatile computer storage media.

[0078] Memory 210 may store data related to the implementation of business category fields as described herein. Memory 210 may also store program code and related data, such as the operating system or other controller algorithms operating on device 200.

[0079] Input device 215 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. Input device 215 may be integrated with output device 220, for example, as a touchscreen or similar touch-sensitive display. Input device 215 may include a touchscreen, enabling text input using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. Input device 215 may include two or more different devices, such as a keyboard and a touch panel.

[0080] Output device 220 may be designed to output visual, auditory, and / or tactile signals. Output device 220 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 220 may include, but is not limited to, a liquid crystal display (“LCD”), a light-emitting diode (“LED”) display, an organic LED (“OLED”) display, a projector, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, output device 220 may include a wearable display, such as a smartwatch, smart glasses, a head-up display, etc., that is separate from but communicatively coupled to the rest of the user equipment device 200. Furthermore, output device 220 may be a component of a smartphone, personal digital assistant, television, tablet computer, laptop computer, personal computer, vehicle dashboard, etc.

[0081] Output device 220 may include one or more speakers for generating sound. For example, output device 220 may generate an auditory alarm or notification (e.g., a beep or ring). Output device 220 may include one or more tactile devices for generating vibration, motion, or other tactile feedback. All or part of output device 220 may be integrated with input device 215. For example, input device 215 and output device 220 may form a touchscreen or similar touch-sensitive display. Output device 220 may be located near input device 215.

[0082] Transceiver 225 communicates with one or more network functions of a mobile communication network via one or more access networks. Transceiver 225 operates under the control of processor 205 to transmit and receive messages, data, and other signals. For example, processor 205 may selectively activate transceiver 225 (or a portion thereof) at specific times to send and receive messages.

[0083] Transceiver 225 includes at least one transmitter 230 and at least one receiver 235. One or more transmitters 230 may be used to provide uplink communication signals to a base unit of a wireless communication network. Similarly, one or more receivers 235 may be used to receive downlink communication signals from a base unit. Although only one transmitter 230 and one receiver 235 are described, user equipment device 200 may have any suitable number of transmitters 230 and receivers 235. Furthermore, transmitters 230 and receivers 235 may be of any suitable type. Transceiver 225 may include a first transmitter / receiver pair for communicating with a mobile communication network via licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network via unlicensed radio spectrum.

[0084] A first transmitter / receiver pair for communicating with a mobile communication network via licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network via unlicensed radio spectrum may be combined into a single transceiver unit, for example, a single chip that performs both licensed and unlicensed radio spectrum communication. The first transmitter / receiver pair and the second transmitter / receiver pair may share one or more hardware components. For example, some transceivers 225, transmitters 230, and receivers 235 may be implemented to access shared hardware resources and / or software resources, such as, for example, physically separate components of network interface 240.

[0085] One or more transmitters 230 and / or one or more receivers 235 may be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an application-specific integrated circuit (“ASIC”), or other type of hardware component. One or more transmitters 230 and / or one or more receivers 235 may be implemented and / or integrated into a multi-chip module. Other components, such as network interface 240 or other hardware components / circuit, may be integrated with any number of transmitters 230 and / or receivers 235 into a single chip. Transmitters 230 and receivers 235 may be logically configured as transceivers 225 using one or more common control signals, or configured as modular transmitters 230 and receivers 235 implemented in the same hardware chip or multi-chip module.

[0086] Figure 4 Further details are provided regarding the network node 300 that may be used to implement the methods described herein. Network node 300 may be an implementation of an entity in a wireless communication network (e.g., one or more of the wireless communication networks described herein). Network node 300 may include SF, SF service consumer, NEF, and / or AF, as referenced later below. Figures 5 to 8 Those implemented in the method described in more detail. Network node 300 includes processor 305, memory 310, input device 315, output device 320, and transceiver 325.

[0087] Input device 315 and output device 320 may be combined into a single device, such as a touchscreen. In some embodiments, network node 300 may not include any input device 315 and / or output device 320. Network node 300 may include one or more of the following: processor 305, memory 310, and transceiver 325, and may not include input device 315 and / or output device 320.

[0088] As depicted, transceiver 325 includes at least one transmitter 330 and at least one receiver 335. Here, transceiver 325 communicates with one or more remote units 200. Additionally, transceiver 325 may support at least one network interface 340 and / or application interface 345. Application interface 345 may support one or more APIs. Network interface 340 may support 3GPP reference points, such as Uu, N1, N2, and N3. Other network interfaces 340 may be supported, as will be understood by those skilled in the art.

[0089] Processor 305 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 305 may be a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or similar programmable controller. Processor 305 may execute instructions stored in memory 310 to perform the methods and routines described herein. Processor 305 is communicatively coupled to memory 310, input device 315, output device 320, and transceiver 325.

[0090] Memory 310 may be a computer-readable storage medium. Memory 310 may include volatile computer storage media. For example, memory 310 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). Memory 310 may include non-volatile computer storage media. For example, memory 310 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. Memory 310 may include both volatile and non-volatile computer storage media.

[0091] Memory 310 may store data related to establishing multipath unicast links and / or mobility operations. For example, memory 310 may store parameters, configurations, resource assignments, policies, etc., as described herein. Memory 310 may also store program code and related data, such as operating systems or other controller algorithms operating on network node 300.

[0092] Input device 315 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. Input device 315 may be integrated with output device 320, for example, as a touch screen or similar touch-sensitive display. Input device 315 may include a touch screen, enabling text input using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. Input device 315 may include two or more different devices, such as a keyboard and a touch panel.

[0093] Output device 320 may be designed to output visual, auditory, and / or tactile signals. Output device 320 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 320 may include, but is not limited to, LCD displays, LED displays, OLED displays, projectors, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, output device 320 may include a wearable display, such as a smartwatch, smart glasses, head-up display, etc., separate from but communicatively coupled to the rest of network node 300. Furthermore, output device 320 may be a component of a smartphone, personal digital assistant, television, tablet computer, laptop computer, personal computer, vehicle dashboard, etc.

[0094] Output device 320 may include one or more speakers for generating sound. For example, output device 320 may generate an auditory alarm or notification (e.g., a beep or ring). Output device 320 may include one or more tactile devices for generating vibration, motion, or other tactile feedback. All or part of output device 320 may be integrated with input device 315. For example, input device 315 and output device 320 may form a touchscreen or similar touch-sensitive display. Output device 320 may be located near input device 315.

[0095] Transceiver 325 includes at least one transmitter 330 and at least one receiver 335. One or more transmitters 330 may be used to communicate with the UE, as described herein. Similarly, one or more receivers 335 may be used to communicate with network functions in the PLMN and / or RAN, as described herein. Although only one transmitter 330 and one receiver 335 are described, network node 300 may have any suitable number of transmitters 330 and receivers 335. Furthermore, transmitters 330 and receivers 335 may be of any suitable type.

[0096] The embodiments described herein include procedures for implementing sense subscriptions and / or sense requests between a sense consumer (referred to as an SF service consumer) and an SF. For example, if the SF service consumer is an untrusted AF, then the SF service consumer and the SF can interact via a NEF. Additionally, the embodiments described herein define the content of sense openings and the service operations associated with sense subscriptions and notifications, as well as sense requests. The embodiments described herein consider both trusted and untrusted SF service consumers.

[0097] Figure 5 This is a flowchart illustrating the sensing subscription and / or unsubscription process 500 in a wireless communication system.

[0098] The sensing subscription and / or cancellation process 500 involves SF service consumers 502 and SF 504. Sensing subscription or cancellation can be performed by SF service consumer 502.

[0099] SF service consumer 502 and / or SF 504 may be identical or consistent with any network entity, function, or node described herein. For example, SF service consumer 502 and / or SF 504 may be identical or consistent with any network entity, function, or node described herein. Figure 4 The network node 300 shown here is the same as that described in more detail above.

[0100] The sensing subscription and / or unsubscription process 500 can be used by any SF service consumer (e.g., including NF, OAM, Trusted AF, etc.) to subscribe to or unsubscribe from receiving sensing result notifications using the Nsf_SensingSubscription service. This service can also be used by sensing consumers to modify existing sensing subscriptions.

[0101] At s506, process 500 may optionally include a preparation step, whereby the SF service consumer 502 checks whether the SF 504 can support sensing subscription in terms of being able to collect the required 3GPP sensing data in the area of ​​interest or the area associated with the target UE at the requested time. This can be deployed prior to subscription by invoking a new service operation Nsf_SensingSubscription_Preparation. The parameters that can be provided by the SF service consumer 502 are described in more detail later in the discussion of “What is Open to Sensing”.

[0102] In some embodiments, the sensing preparation process may alternatively use the Nsf_SensingSubscription_Subscribe message to introduce a preparation flag (e.g., a Boolean variable) to indicate when the subscription operation is used for sensing preparation purposes or for sensing subscription.

[0103] In some embodiments, if all one or more requirements of the sensing subscription can be satisfied by SF 504, then SF 504 may transmit a confirmation message confirming that all one or more requirements of the sensing subscription can be satisfied back to SF service consumer 502. Alternatively, if one or more of the requirements of the sensing subscription cannot be satisfied by SF 504, then SF 504 may transmit a notification (e.g., an error message) indicating that one or more requirements of the sensing subscription cannot be satisfied by SF 504, and optionally also defining or specifying a reason (i.e., justification) for use by SF service consumer 502.

[0104] At s508, the SF service consumer 502 subscribes to or unsubscribes from sensing results by invoking either the new service operation Nsf_SensingSubscription_Subscribe or Nsf_SensingSubscription_Unsubscribe. The parameters that can be provided by the SF service consumer in Nsf_SensingSubscription_Subscribe or Nsf_SensingSubscription_Unsubscribe are described in more detail later in the discussion of “Sensing Open Content”.

[0105] When a subscription to sensing results is received, SF 504 determines whether it needs to collect radio signals (i.e., sensing data) to identify sensing targets and / or determine their corresponding characteristics.

[0106] If the service call from SF service consumer 502 is for subscription modification (i.e., change or update of an existing subscription), then SF service consumer 502 preferably includes an identifier (e.g., subscription transaction ID) of the subscription to be modified in the call to Nsf_SensingSubscription_Subscribe.

[0107] At s510, if SF service consumer 502 subscribes to the sensing results, then SF 504 notifies SF service consumer 502 of the sensing results by calling the new service operation Nsf_SensingSubscription_Notify based on the sensing result report parameter request from SF service consumer 502.

[0108] Depending on the established subscription, multiple Nsf_SensingSubscription_Notify messages can be periodically sent from SF 504 to SF service consumer 502. Figure 5 The dashed arrows from SF 504 to SF service consumer 502 schematically depict these Nsf_SensingSubscription_Notify messages.

[0109] If SF 504 provides a sensing termination notification (e.g., because the sensing target object has moved out of its service area), then consumer 502 can cancel the sensing result subscription by calling the new service operation Nsf_SensingSubscription_Unsubscribe.

[0110] Figure 6 This is a flowchart illustrating the process 600 of sensing subscription and / or unsubscription by an untrusted AF via NEF.

[0111] The sensing subscription and / or unsubscription process 600 involves SF 602, NEF 604, and AF 606 (which is an untrusted AF in this embodiment). By using a sensing subscription to SF 602, sensing access to the untrusted AF 606 can be performed via NEF 604.

[0112] SF 602, NEF 604, and / or AF 606 may be identical or consistent with any network entity, function, or node described herein. For example, SF 602, NEF 604, and / or AF 606 may be consistent with... Figure 4 The network node 300 shown here is the same as that described in more detail above.

[0113] At s608, NEF 604 uses an identifier (e.g., a subscription transaction ID) with allowed sensing IDs (i.e., identifying which sensing types are allowed for this particular untrusted AF 606), associated inbound restrictions (i.e., applied to the subscription of sensing IDs of the untrusted AF, such as sensing services and / or sensing of a service area that this particular untrusted AF 606 cannot request) and / or outbound restrictions (e.g., applied to notifying the untrusted AF 606 of sensing IDs, such as limiting or preventing the provision of sensing results associated with a specific event ID to AF 606).

[0114] The untrusted AF 606 can be configured with the appropriate NEF 604 to subscribe to sensing results, and can be configured to subscribe to each sensing ID with allowed sensing IDs and allowed inbound restrictions (i.e., parameters and / or parameter values).

[0115] At s610, the untrusted AF 606 may optionally use a preparation step to determine whether the SF 602 can support sensing subscription in terms of its ability to collect the required 3GPP sensing data in the area of ​​interest or the area associated with the target UE at the requested time. This can be deployed as an additional step prior to subscription, for example, by introducing a new service operation Nnef_SensingSubscription_Preparation. The parameters that can be provided by the untrusted AF 606 are described in more detail later in the discussion of “What is Open to Sensing”.

[0116] At s612, if the preparation step request (i.e., Nnef_SensingSubscription_Preparation) meets the inbound restrictions in the sensing open map, then NEF 604 directs the request to the corresponding SF 602 by invoking the new service operation Nsf_SensingSubscription_Preparation.

[0117] In some embodiments, if all one or more requirements of the sensing subscription can be satisfied by SF 602, then SF 602 may (via NEF 604) transmit a confirmation message confirming that all one or more requirements of the sensing subscription can be satisfied, or in other words, that the sensing service can be supported, back to AF 606. Alternatively, if one or more of the requirements of the sensing subscription cannot be satisfied by SF 602, then SF 602 may (via NEF 604) transmit a notification (e.g., an error message) indicating that one or more requirements of the sensing subscription cannot be satisfied by SF 604 and optionally additionally including a reason (i.e., justification) back to AF 606.

[0118] The sensing preparation process can alternatively use the Nnef_SensingSubscription_Subscribe and Nsf_SensingSubscription_Subscribe messages, introducing preparation flags (e.g., boolean variables) to indicate when the subscription operation is used for sensing preparation purposes or for sensing subscription.

[0119] The parameters available in Nnef_SensingSubscription_Preparation and / or Nsf_SensingSubscription_Preparation will be described in more detail later in the discussion of “Sensing Open Content”.

[0120] At s614, the untrusted AF 606 subscribes to or unsubscribes from sensing results via NEF 604 by invoking either the new service operation Nnef_SensingExposure_Subscribe or Nnef_SensingExposure_Unsubscribe. The parameters available to AF 606 in Nnef_SensingExposure_Subscribe or Nnef_SensingExposure_Unsubscribe are described in more detail later in the discussion of “Sensing Open Content”.

[0121] If it is untrusted that AF 606 needs to modify an existing sensing subscription at NEF 604, then AF 606 can include an identifier (e.g., a subscription transaction ID) in the call to Nnef_SensingExposure_Subscribe to identify the subscription to be modified. If the sensing subscription is authorized by NEF 604, then NEF 604 can proceed with the following steps.

[0122] At s616, based on a request from the untrusted AF 606, NEF 604 subscribes to or unsubscribes from sensing results by calling the Nsf_SensingSubscription_Subscribe or Nsf_SensingSubscription_Unsubscribe service operations respectively.

[0123] If the parameters and / or parameter values ​​of an untrusted AF request meet the inbound restrictions in the Sensing Open Map, then NEF604 will forward the subscription to the corresponding SF 602 that supports the Sensing ID, including the parameters and / or parameter values ​​from the untrusted AF request.

[0124] If a request from an untrusted AF 606 does not comply with the restrictions in the sensing open mapping, then NEF 604 may apply restrictions to subscription requests to SF 602 based on operator configuration (e.g., apply restrictions to parameters or parameter values ​​of the Nsf_SensingSubscription_Subscribe service operation), and / or may apply parameter mapping (e.g., geographic ordered coordinate mapping to TA / Cell-id).

[0125] NEF 604 records the association between sensing subscriptions from untrusted AF 606 and sensing subscriptions sent to SF 602. NEF 604 can use, for example, the procedures defined in TS23.501 (i.e., assuming the ability of SFs to register them with the Network Repository Function (NRF), which assists the discovery process) to select the appropriate SF 602 to support the requested sensing results of untrusted AF 606.

[0126] If the untrusted AF request is intended to modify an existing sensing subscription, then NEF 604 may invoke Nsf_SensingSubscription_Subscribe to modify the sensing subscription identified by the identifier (i.e., the subscription transaction ID) associated with the untrusted AF 606.

[0127] At s618, if NEF 604 has subscribed to SF 602 with a specific sensing ID for certain sensing results, then SF 602 notifies NEF 604 of the sensing results or sensing termination notification by calling a new service operation named Nsf_SensingSubscription_Notify.

[0128] At s620, when NEF 604 receives a notification from SF 602, NEF 604 notifies the untrusted AF 606 of the sensing result or sensing termination notification by calling Nnef_SensingExposure_Notify. NEF 604 can apply outbound restrictions to notifications to the untrusted AF 606 based on sensing open mapping (e.g., apply restrictions to parameters or parameter values ​​of the Nnef_SensingExposure_Notify service operation), and can apply parameter mappings for external use (e.g., convert TA, Cell-id to geographic area coordinates).

[0129] Untrusted AF 606 can check if a sensing termination notification exists in Nnef_SensingExposure_Notify. If a sensing termination notification exists, Untrusted AF 606 can unsubscribe from sensing results by calling the new service operation Nsf_SensingSubscription_Unsubscribe.

[0130] Figure 7 This is a flowchart illustrating the sensing request process 700 in a wireless communication system.

[0131] The sensing request process 700 involves SF service consumers 702 and SF 704. The sensing request can be made by SF service consumer 702.

[0132] SF service consumer 702 and / or SF 704 may be identical or consistent with any network entity, function, or node described herein. For example, SF service consumer 702 and / or SF 704 may be identical or consistent with any network entity, function, or node described herein. Figure 4 The network node 300 shown here is the same as that described in more detail above.

[0133] The sensing request process 700 can be used by any SF service consumer (e.g., including NF, OAM, trusted AF, etc.) to request and receive sensing results using the Nsf_SensingInfo service.

[0134] At s706, the SF service consumer 702 may optionally check whether the SF 704 can support the sensing request in terms of the SF 704 being able to collect the required 3GPP sensing data in the area of ​​interest or the area associated with the target UE at the requested time. This can be deployed by invoking the new service operation Nsf_SensingInfo_Preparation. The parameters that can be provided by the SF service consumer 702 are described in more detail later in the discussion of “What is Open to Sensing”.

[0135] In some embodiments, if all one or more requirements of the sensing request can be satisfied by SF 704, then SF 704 may transmit a confirmation message confirming that all one or more requirements of the sensing request can be satisfied, or in other words, that the sensing service can be supported, back to SF service consumer 702. Alternatively, if one or more of the requirements of the sensing request cannot be satisfied by SF 704, then SF 704 may transmit a notification (e.g., an error message) indicating that one or more requirements of the sensing request cannot be satisfied by SF 704 and optionally additionally specifying or defining a reason (i.e., a justification) back to SF service consumer 702.

[0136] The sensing preparation process can alternatively use Nsf_SensingInfo_Request, introducing a preparation flag (i.e., a boolean variable) to indicate when the sensing request operation is used for sensing preparation purposes or for sensing requests.

[0137] At s708, SF service consumer 702 requests the sensing results by invoking a new service named Nsf_SensingInfo_Request. The parameters that can be provided by the SF service consumer in Nsf_SensingInfo_Request are described in more detail later in the discussion of “Sensing Open Content”.

[0138] When SF 704 receives a request for sensing results, SF 704 determines whether it needs to collect radio signals (i.e., sensing data) to identify sensing targets and / or determine their corresponding characteristics.

[0139] At s710, SF 704 responds to SF service consumer 702 with sensing results based on the requested sensing result report parameters by invoking a new service named Nsf_SensingInfo_Request. SF 704 may check whether a sensing termination request was indicated by SF service consumer 702 before providing the sensing results.

[0140] Figure 8 This is a flowchart illustrating the sensing request process 800 from an untrusted AF via NEF.

[0141] The sensing request process 800 involves SF 802, NEF 804, and AF 806 (which is an untrusted AF in this embodiment). Sensing access to the untrusted AF 806 can be performed via NEF 804.

[0142] SF 802, NEF 804, and / or AF 806 may be identical or consistent with any network entity, function, or node described herein. For example, SF 802, NEF 804, and / or AF 806 may be consistent with... Figure 4The network node 300 shown here is the same as that described in more detail above.

[0143] At s808, NEF 804 uses an identifier (e.g., a transaction ID or a generic mapping identifier) ​​that has an allowed sensing ID, associated inbound restrictions (i.e., applied to the sensing ID requested by the untrusted AF), and / or outbound restrictions (i.e., applied to the response to the sensing result associated with the sensing ID toward the untrusted AF 806).

[0144] An untrusted AF 806 can be configured with an appropriate NEF 804 to request sensing results, configured with allowed sensing IDs and allowed inbound restrictions (i.e., parameters and / or parameter values) to request sensing results from each sensing ID.

[0145] At s810, the untrusted AF 806 may optionally use a preparation step to check whether the SF 802 can support the sensing request in terms of the SF 802 being able to collect the required 3GPP sensing data in the area of ​​interest or the area associated with the target UE at the requested time. This can be deployed as an additional step before sending the sensing request, i.e., by introducing a new service operation Nnef_SensingExposure_Preparation. The parameters that can be provided by the untrusted AF 806 are described in more detail later in the discussion of “What is Sensing Open”.

[0146] At step s812, if the preparation steps meet the inbound restrictions in the sensing open mapping, then NEF 804 directs the request to the corresponding SF 802 by invoking the new service operation Nsf_SensingInfo_Preparation.

[0147] In some embodiments, if all one or more requirements of the sensing request can be satisfied by SF 802, then SF 802 may (via NEF 804) transmit a confirmation message confirming that all one or more requirements of the sensing request can be satisfied back to AF 806. Alternatively, if one or more of the requirements of the sensing request cannot be satisfied by SF 802, then SF 802 may (via NEF 804) transmit a notification (e.g., an error message) indicating that one or more requirements of the sensing request cannot be satisfied by SF 802 and optionally additionally specifying or defining a reason (i.e., justification) back to AF 806.

[0148] The sensing preparation process can alternatively use the Nnef_SensingExposure_Fetch and / or Nsf_SensingInfo_Request messages, which introduce a preparation flag (i.e., a boolean variable) to indicate when the sensing request operation is used for sensing preparation purposes or for sensing request purposes.

[0149] At s814, the untrusted AF 806 requests to receive sensing results via NEF 804 by invoking Nnef_SensingExposure_Fetch, a new service defined similarly to the fetch service operation specified in TS23.502. The parameters that can be provided by the untrusted AF 806 are described in more detail later in the discussion of “Sensing Open Content”.

[0150] If the sensing request is authorized by NEF 804, then NEF 804 continues with the following steps.

[0151] At s816, based on a request from the untrusted AF 806, NEF 804 requests the sensing results by invoking a new service operation named Nsf_SensingInfo_Request.

[0152] If the parameters and / or parameter values ​​of the untrusted AF request meet the inbound restrictions in the sensing open mapping, then NEF804 will forward the request or send it to the corresponding SF 802 that supports the sensing ID, including the parameters and / or parameter values ​​from the untrusted AF 806.

[0153] If a request from an untrusted AF 806 does not comply with the restrictions in the sensing open mapping, then NEF 804 may apply restrictions to the request to SF based on the operator configuration (e.g., apply restrictions to parameters or parameter values ​​of the Nsf_SensingInfo_Request service operation), and / or may apply parameter mapping (e.g., geographic ordered coordinate mapping to TA / Cell-id).

[0154] NEF 804 can record the association between sensing requests from untrusted AF 806 and sensing requests sent to SF 802. NEF 804 can use, for example, the discovery process defined in TS23.501 (i.e., assuming the ability of SFs to register with the NRF, which assists the discovery process) to select the appropriate SF 802 to support the sensing results requested by untrusted AF 806.

[0155] At s818, SF 802 responds to NEF 804 by invoking the Nsf_SensingInfo_Request response containing the sensing result or sensing termination notification.

[0156] At s820, NEF 804 responds to the untrusted AF 806 with the sensing result or sensing termination notification. NEF 804 can apply outbound restrictions to the response toward the untrusted AF 806 based on operator configuration (e.g., apply restrictions to parameters or parameter values ​​of the Nnef_SensingExposure_Fetch response service operation), and can apply parameter mappings for external use (e.g., convert TA, Cell-id to geographic area coordinates).

[0157] Therefore, processes are provided for sensing data subscription or subscription cancellation and sensing data request, for example, both trusted and untrusted AF.

[0158] The content of sensing openness will now be discussed. Sensing openness includes: (i) parameters used by SF service consumers (e.g., SF service consumers 502, 702, or AF 606, 806) to subscribe to, modify, or request sensing services from SF; and (ii) the content of notifications or responses from SF to SF service consumers (e.g., SF service consumers 502, 702, or AF 606, 806).

[0159] The sensing access information used to subscribe to or request sensing services may contain one or more parameters selected from the following parameter groups:

[0160] - "Sensing ID". This parameter identifies the requested sensing "job" (or sensing type), such as "verify object route", "detect object", "estimate object location", "estimate object speed", "estimate object mechanical periodicity", etc. This assumes that some sensing "job" identifier is publicly specified. Using this parameter, when an SF service consumer requests, for example, a "detect object" sensing job, it knows what the expected sensing result or target is (e.g., detection of shape, size, orientation associated with the sensing target). Alternatively, since sensing "jobs" can be numerous and new jobs can be defined at any time, the Sensing ID parameter can be used as a field or container that allows the SF service consumer to communicate the desired sensing "job" to the SF, assuming that the sensing "job" name or ID is known between the involved entities based on a Service Level Agreement (SLA), i.e., pre-configured.

[0161] - "Sensing Description". This parameter provides the size or shape (e.g., 3D shape) of the object of interest to be sensed and / or

[0162] Environmental conditions and / or other relevant characteristics used for detecting and separating objects. In some embodiments, the sensing description may further include object location information, expected velocity, orientation, direction of travel or movement, or a subset or combination thereof. In some embodiments, the sensing description may further include information related to the background environment, such as the location or shape information of other objects or environmental parts that are different from the object of interest. Alternatively, the sensing object or environmental condition description may be provided via an AI / ML model that is prepared, i.e., trained to recognize certain object or environmental conditions and other relevant attributes. Typically, it is provided as a set of values ​​by an SF service consumer, or in the case of an AI / ML model, it may be provided by a link that helps the SF obtain (e.g., download) the AI / ML model or download or obtain the AI / ML model via model serialization or containerization.

[0163] - "Object Type ID". This parameter can be provided to objects of distinctly different categories and can be associated with each different sensing profile.

[0164] In related terms, for example, for a sensing ID equivalent to "road safety", different object type IDs can be implemented to distinguish between cars, animals and humans.

[0165] - "Transaction ID". This reference identifier can be used when an SF service consumer subscribes to or requests a sense ID. Example

[0166] For example, when providing notification of sensing results or when an SF consumer needs to modify its subscription, the transaction ID parameter can be used to identify and verify subscription request sessions or sensing requests in one or more related transactions.

[0167] - "Notification Address". This parameter specifies the address to which the sensing results are sent, for example, in a case where an SF service consumer issues a sensing request on behalf of another node consuming the sensing results.

[0168] - "Use Case Context". This parameter indicates the use context of the sensing service (sensor ID), i.e., the purpose of using sensing (e.g., to identify cars or animals approaching the road to ensure road safety or to check the accuracy of a route taken by a drone). When several models are available here, this parameter can be used to select the most relevant AI / ML model in SF. The value of this parameter can be public (i.e., from a list of predefined use case context identifiers) or private, but this field can still be used to carry these private parameters.

[0169] - "Detection Filtering Information". This parameter indicates the conditions that will be met to notify or report the sensing results. Typically,

[0170] These are optional parameters that can help you choose when and what type of sensing results should be reported and may include the following:

[0171] • Region of interest. This can be expressed based on a geographic region, for example, represented as a set of ordered coordinates or as neighbors in a town with predetermined boundaries.

[0172] • Time window of interest. If this parameter is defined, then only sensing events created within the specified time interval will be considered for generating sensing results. The time window can be in the past (i.e., using collected radio signals) or in the future. • UEs of interest. If this parameter is specified, then sensing can be applied only to one(s) of the specified UEs.

[0173] For example, a UE of interest in a sensing subscription / request can be used to define an event ID, i.e., when such indicated UEs are closer to each other (e.g., less than a 10m threshold) or closer to any other known / detected object. A UE of interest can be used to indicate a co-located and / or attached sensing target, or a sensing target in which the UE of interest is contained, for example, sensing an object within a truck track. A UE of interest can be associated with the following characteristics or conditions:

[0174] i) Slice connectivity, i.e., S-NSSAI (e.g., only for UEs in vehicle slices).

[0175] ii) Subscribe to profiles (e.g., sensing as a value-added service for the UE).

[0176] iii) DNN connectivity (e.g., when the UE, i.e., the security operator, consumes surveillance video from an application server and needs to combine it with sensing).

[0177] iv) Application type identifier (e.g., used only by the UE when a specific application type is running, such as for emergency rescue).

[0178] v) UE type (e.g., only for vehicle or drone UE).

[0179] • Event of Interest (ROI). This parameter identifies at least one or a set of conditions that trigger the initiation of sensing within the context of a specific sensing ID; that is, conditions that the SF needs to base its start of collecting sensing data to prepare sensing results. These conditions may be related to a sensing target and may be defined based on one or more of the following: geographic area or location, speed, direction, relative distance, size change, and / or detection of another object. For example, an ROI can be defined when a sensing target is detected at a speed greater than 20 m / s or when the sensing target is within 10 m of an indicated reference location. ROI can also define common conditions among a set of sensing targets, such as entering a region of interest or being associated with another sensing target, for example, the distance between the two objects is less than 2 m. Alternatively, an ROI can define a sensing trigger condition when another sensing target is detected at a specified location, for example, to begin sensing other target sensing objects at the same location. For reference purposes, different ROIs can be associated with different event IDs. The trigger conditions defined by ROIs can be categorized as follows:

[0180] i) Threshold conditions. These can be measured as values ​​based on velocity, direction, and / or distance, a set of coordinates, or three-dimensional coordinates. Thresholds can be defined based on a given limit in a certain direction, i.e., below, above, or above. Typically, a threshold is defined as having an acceptable deviation and hysteresis, i.e., it is triggered not only when a given threshold level is reached or exceeded, but also when the deviation exceeds or falls below the indicated acceptable deviation from that given threshold level. In this way, the "ping-pong" effect around the threshold level can be limited.

[0181] ii) Matching conditions. These are measurable when there are values ​​or a set of values ​​related to the sensed target, or when the sensed target is a subset of a given set. For example, when the sensed target is located within a specified region of interest, or when the sensed target moves (i.e., its trajectory is within the specified region of interest).

[0182] iii) Target detection conditions. These can be measured via the activity of another sensing target, i.e., when another object is detected, for example, when a goat is detected approaching the road, then sensing begins for the next 10 minutes.

[0183] The designated area of ​​interest is used to detect the presence of a herd of goats nearby and to send risk alerts to passing drivers. • "Mobility Profile". This profile can be associated with the target sensing UE or object type and can be referenced.

[0184] Consider one or more of the following parameters:

[0185] i) Interested movement - Once the sensed target begins to move.

[0186] ii) Speed ​​of interest (or velocity) - Once the sensed target moves within a certain speed range or above / below the specified limit.

[0187] iii) Path of Interest (POI): Sensing a specified trajectory (i.e., a set of 2D or 3D coordinates) along which a target is expected to move, for example, a planned route for a drone, to sense whether it is being followed accurately. The POI can be provided by a GPS system.

[0188] iv) Direction of interest - Once the sensed target begins to move in a certain direction.

[0189] v) Preferred travel distance for sensing resolution, for example, specified in meters or at the cell level.

[0190] vi) Distance of interest around a reference point. This parameter can be a fixed value or a set of fixed values ​​(e.g., a table with different fixed value options), or it can be a function that assists in calculating distance considering the velocity associated with a moving sensing target. Relative distance can be measured in three dimensions, or two dimensions (e.g., excluding zenith / elevation), or one dimension (e.g., an area with a maximum distance of 2 meters in the x-axis direction of a known coordinate system). The distance of interest around a reference point can be used, for example, for safety related to a moving vehicle considering its velocity to calculate the sensing distance around it. The reference point can be a static or moving sensing target object (e.g., associated with an object ID), a static or moving known object (e.g., again associated with an object ID), a static or moving UE (e.g.,

[0191] One or more of the UE IDs (associated with the UE ID indicated by the SF service consumer).

[0192] vii) The relative distance of interest between two or more reference points. This parameter can be a fixed value or a set of fixed values ​​(e.g., a table with different fixed value options), or it can be a function that assists in calculating the distance by taking into account the velocity associated with a moving sensed target. The relative distance can be measured in three dimensions or two dimensions (excluding zenith /

[0193] The distance can be measured in one dimension (e.g., an area with a maximum distance of 2 meters in the x-axis direction of a known coordinate system) or in an elevation angle. The relative distance of interest can be used, for example, for safety in moving vehicles. The reference point can be one or more of the following: a static or moving sensing target object (e.g., associated with an object ID), a static or moving known object (e.g., again associated with an object ID), or a static or moving UE (e.g., associated with a UE ID indicated by an SF service consumer).

[0194] viii) Abnormal behavior associated with the sensed target, such as when the target suddenly stops while it is moving, collides with another object, or moves away. These conditions can be defined as fixed or vary based on correlation values ​​between sensed targets, such as zero speed, zero distance between vehicles, and changes in previous shape. Relative deviation from a known road or route, or deviation from the expected speed, can also be used as an indication of abnormal movement.

[0195] - "Target of the Sensing Report". This parameter indicates the target of the UE, object, and / or environment that requested the sensing information.

[0196] The parameters may indicate entities such as: (i) a specific UE or object type, (ii) a group of UEs or objects, (iii) any UE or object type (i.e., all UEs or objects), and / or (iv) environmental conditions.

[0197] The UE or non-object type is unrelated to the UE or a specific object.

[0198] - The target time period for the sensing subscription. This parameter can be specified as, for example, [start time, stop time] or (start, stop time).

[0199] Duration) to indicate the time associated with the sensing subscription.

[0200] - Sensing key performance indicators (KPIs) associated with a specific sensor ID. These may include:

[0201] • "Preferred resolution level". This parameter indicates the nature of the sensed data, such as the position or velocity resolution of an object in a defined 2D plane or a defined 1D direction in 3D space. The resolution can vary depending on the movement of the sensed target, such as the movement of the target object or UE, and / or the movement of the sensed radio equipment, combined with the sensor's capabilities. Four resolutions are available for consideration for any dataset, including the following:

[0202] i) Radiometric resolution. This is the amount of information that each pixel can carry; that is, higher radiometric resolution allows for greater availability of storing information related to the sensed target.

[0203] ii) Spatial resolution. This is defined by the size of each pixel from which a sensing device can scan or collect information and represent it in a digital image.

[0204] iii) Spectral resolution. This refers to the ability of a radio sensor to use finer wavelengths, i.e., to support more and / or narrower frequency bands. The narrower the wavelength range for a given frequency band, the finer the spectral resolution achieved.

[0205] iv) Temporal resolution is the time required to revisit the same observation point or area assuming the sensing equipment rotates or moves in a regular pattern.

[0206] • "Preferred Sensing Accuracy Level". This can take values ​​of "Low", "Medium", "High", or "Highest". This parameter describes or indicates how close the estimate should be to the expected ground truth value. This parameter can be applied to estimating the location or velocity of a sensing target. For example, sensing accuracy can indicate the position or velocity estimate of an object in 3D space within a defined 2D plane or a defined 1D direction.

[0207] • "Preferred Reliability Level". This parameter indicates the expected consistency of the sensing data collected per sensing ID, taking into account the probability of consistent and good performance per sensing device (e.g., per base station) and / or the probability of replacing the currently performing sensing "job" with other sensing devices (e.g., other base stations) in the event of a failure.

[0208] • "Preferred Maximum False Alarm Probability". This parameter represents the ratio of each Sensing ID event that does not indicate a characteristic or state of the sensed target or environment (e.g., the target object did not enter the indicated region of interest) to a large number of all events during a pre-configured period when SF determines sensing results. False alarm probability helps SF service consumers select SF.

[0209] • "Preferred maximum missed detection probability". This parameter represents the ratio of each sensing ID event that misses acquiring sensing results related to the sensing target or environment (e.g., missing sensing when the speed of the sensing target exceeds a limit indicated by the corresponding sensing event) to all events during the pre-configured period in which SF determines the sensing results.

[0210] The probability of missed detection can help SF service consumers choose SF.

[0211] - "Sensing Results Report", which may include one or more of the following parameters:

[0212] • Time scheduling, which may be related to the following:

[0213] i) The refresh rate for collecting sensing data and generating sensing results.

[0214] ii) Preferred reporting periodicity for reporting sensing results to consumers. If several sensing results need to be included in a single sensing report, then it may have a value equal to or lower than the refresh rate.

[0215] iii) The time until sensing results are needed (maximum sensing delay). This indicates the latest time a sensing consumer expects to receive sensing results from the SF. It can be used to indicate delay tolerances to assist SF time scheduling and should not be set to a value less than the sensing delay supported by the selected SF. If the time expires, the SF may send an error notification.

[0216] iv) Used for immediate reporting of sensing results or for generating sensing results as quickly as possible.

[0217] • "Per-Sensed ID Reporting Threshold". These thresholds indicate when network conditions (e.g., load limits, throughput, energy saving) should be adjusted to notify SF service consumers of sensing results. This adjustment may comply with operator policies related to back-end network service control or network openness. The reporting threshold is defined based on a given limit in a specific direction (i.e., below, above, or above acceptable deviation and hysteresis) to ensure that the threshold is triggered when the deviation exceeds or falls below the indicated acceptable deviation, for example, to avoid a "ping-pong" effect around the threshold level.

[0218] • “Each sensing ID event complete” is generated once the sensing results associated with a specific event ID are ready in SF. The conditions for characterizing an event as complete depend on how the event is defined. For example, in the case of a threshold condition, an event can be considered complete when a sensed target exceeds a velocity limit and then falls back after the period in which sensing was performed. Alternatively, considering a matching condition, an event can be considered complete when a sensed target that has entered a given region of interest has left. In the case of target detection, an event can be considered complete after a certain period of time or when another target detection event occurs.

[0219] • The maximum number of UEs or objects to be included in the sensing list for each notification or request response can be limited by the consumer's request.

[0220] • The preferred order of the sensing results when returning to the list may have criteria for identifying the nature of the results to which the preferred order has been applied.

[0221] - "Sensing Results Provision Strategy". This parameter indicates when one or more of the following should be considered when reporting sensing results: (i) a binary strategy, which reports sensing results only when a preferred accuracy level is achieved or a threshold condition is met, and

[0222] / or (ii) a gradient strategy that periodically reports sensing results regardless of other factors.

[0223] - "Preparation Flag". This indicates whether the subscription or request for sensing open is issued for the purpose of checking whether the SF can support the sensing subscription in terms of being able to collect the required 3GPP sensing data in the area of ​​interest or the area associated with the target UE at the requested time. The preparation flag can be implemented by using a Boolean variable to indicate whether the subscription or request operation is for sensing preparation purposes, i.e., whether it is used for regular sensing subscription or request.

[0224] The sensing access information included in notifications or responses to SF service consumers may contain one or more parameters selected from the following parameter groups:

[0225] - "Sensing Results", which can be per sensing ID and / or per event ID. Sensing results contain the sensing output as requested. If no sensing termination notification is provided, the sensing results are included in the notification or response.

[0226] - "Sense termination notification". This parameter informs consumers that their subscription has been canceled or that the service is no longer available because SF is unable to serve them, for example, because the target object has moved out of SF's service area.

[0227] - "Transaction ID". This parameter indicates the subscription or request identity in all corresponding transactions toward the SF service consumer (it can only be applied / valid if a subscription or request is sensed).

[0228] - "Timestamp of the generated sensing result". This parameter indicates to SF service consumers when the sensing result was created.

[0229] This can help SF service consumers understand how to use the sensing results.

[0230] - The location of the target object contained in the sensing results.

[0231] - "Object ID". This parameter identifies different objects of interest that are part of the same object type ID category within the sensing results. The object ID can be a combined identifier containing an object type ID or a separate identifier that complements the object type ID. For example, the object type ID "Car" can contain different object IDs associated with different cars sensed within the same region of interest. The object ID can then be used to reference specific objects in several sensing results reports. For example, the object ID of a detected car indicated in a previous sensing report can be used in a subsequent report, along with the location information associated with that object ID, to indicate the updated location information of the previously detected car to SF service consumers.

[0232] - "Environmental Condition ID". This parameter identifies different environmental conditions included in the sensing results as part of the sensing description. For example, rain or snow may be associated with different corresponding IDs in the sensing results report.

[0233] - Confidence level of sensing prediction based on the amount of collected radio signal data (i.e., sensing data).

[0234] - "Revised Waiting Time". This parameter indicates to the consumer the suggested waiting time value for when the sensing results will be ready once an error response or error notification is issued.

[0235] The following information is useful for understanding instances of the new sensing service, which can be implemented in some embodiments using the devices and methods described herein.

[0236] Nsf_SensingSubscription service

[0237] Service Description: This service enables consumers to subscribe to / unsubscribe from sensor results.

[0238] When a subscription to sensing is accepted by SF, the SF service consumer receives from SF an identifier (e.g., a transaction ID) that allows further management (modification, deletion) of the subscription. Modifications to the analytics subscription can be enforced by SF based on operator policies and configurations.

[0239] Nsf_SensingSubscription_Preparation service operation

[0240] Service operation name: Nsf_SensingSubscription_Preparation.

[0241] Description: Optional preparation before subscribing to SF sensing results with specific parameters.

[0242] Inputs, required: (i) a set of sense IDs, (ii) sense filtering information (e.g., region of interest, interested UEs, etc.), and (iii) the target time period for sense subscription.

[0243] Inputs, optional: (i) use case context, (ii) target of the sensing report (per sensing ID), (iii) sensing filtering information, (iv) sensing result report, (v) sensing result delivery strategy, (vi) if the sensing focuses on an object, then: (vi.a) sensing description, (vi.b) sensing object type ID, (vii) sensing KPI.

[0244] Output, required: A positive acknowledgment when subscription readiness is accepted. Otherwise, a negative response indicating the reason, such as insufficient wireless resources, object out of range, etc., if subscription readiness cannot be fulfilled.

[0245] Output, optional: None.

[0246] Nsf_SensingSubscription_Subscribe service operation

[0247] Service operation name: Nsf_SensingSubscription_Subscribe.

[0248] Description: Subscribe to SF sensing results with specific parameters.

[0249] Inputs, required: (i) (a set) sensor ID / event ID, (ii) the target of the sensor report (per sensor ID and / or event ID), (iii) the target time period of the sensor subscription, and (iv) the transaction ID (if the subscription has been established and the intent is to request modification).

[0250] Inputs, optional: (i) use case context, (ii) notification address, (iii) sensing filter information, (iv) sensing result report, (v) sensing result delivery strategy, (vi) if sensing focuses on an object, then: (vi.a) sensing description, (vi.b) sensing object type ID, (vii) sensing KPI, (viii) result delivery strategy, (ix) preparation tag.

[0251] Output, Required: When the subscription is accepted: Transaction ID (required for any subscription transaction). When ready to mark an activity, the response indicates whether the ready conditions are met. When the subscription is not accepted, it is an error response or a sensed termination notification. Output, Optional: None.

[0252] Note that when using Nsf_SensingSubscription_Subscribe, it may contain at least, but not limited to, the following parameters: (i) a set of sensing IDs, (ii) region of interest, (iii) target UE (if applicable), and (iv) the target time period for sensing subscription. Nsf_SensingSubscription_Unsubscribe service operation

[0253] Service operation name: Nsf_SensingSubscription_Unsubscribe.

[0254] Description: Unsubscribe from SF Sensing Service, i.e., unsubscribe from sensing results.

[0255] Input, required: Transaction ID.

[0256] Input, optional: None.

[0257] Output, required: Indicator of the result of the operation execution.

[0258] Output, optional: None.

[0259] Nsf_SensingSubscription_Notify service operation

[0260] Service operation name: Nsf_SensingSubscription_Notify.

[0261] Description: SF notifies SF service consumers of the sensing results that have been subscribed for each sensing ID / event ID.

[0262] Input, required: If the request is accepted, then: (i) the sensing ID / event ID, (ii) the sensing result, and (iii) the transaction ID assigned by the SF service consumer during the subscription period. If the request is not accepted, then an error response or sensing termination notification.

[0263] Inputs, optional: (i) timestamp of the sensing result, (ii) location of the target object, (iii) confidence level of the sensing prediction, (iv) revised wait time, (v) object ID of the different objects contained in the sensing result with respect to object type ID (if the sensing is focused on an object) or (vi) environmental condition ID.

[0264] Output, required: Indicator of the result of the operation execution.

[0265] Output, optional: None.

[0266] Nsf_SensingInfo service

[0267] Service Description: This service enables SF service consumers to request and obtain SF sensing results.

[0268] Nsf_SensingInfo_Preparation service operation

[0269] Service operation name: Nsf_SensingInfo_Preparation.

[0270] Description: Optional preparations before issuing SF sensing results with specific parameters.

[0271] Inputs, required: (i) (a set) sensing IDs, (ii) sensing filtering information (e.g., region of interest, interested UE, time window of interest).

[0272] Inputs, optional: (i) use case context, (ii) target of the sensing report (per sensing ID), (iii) sensing filtering information, (iv) sensing result report, (v) sensing result delivery strategy, (vi) if the sensing focuses on an object, then: (vi.a) sensing description, (vi.b) sensing object type ID, (vii) sensing KPI.

[0273] Output, required: A positive acknowledgment when subscription readiness is accepted. Otherwise, a negative response indicating the reason, such as insufficient wireless resources, object out of range, etc., if subscription readiness cannot be fulfilled.

[0274] Output, optional: None.

[0275] Nsf_SensingInfo_Request service operation

[0276] Service operation name: Nsf_SensingInfo_Request.

[0277] Description: SF service consumers request specific sensing results.

[0278] Inputs, required: (i) (a set) of sensor IDs / event IDs, (ii) the target of the sensor report (per sensor ID and / or event ID), and (iii) the time window of interest.

[0279] Inputs, optional: (i) use case context, (ii) notification address, (iii) sensing filtering information, (iv) sensing result report, (v) sensing result delivery strategy, (vi) if sensing focuses on an object, then: (vi.a) sensing description, (vi.b) sensing object ID, (vii) sensing KPI, (viii) preparation tag.

[0280] Output, required: If the request is accepted, then: (i) Sensing ID / Event ID, (ii) Sensing result. When preparing to tag an activity, then the response indicates whether the preparation conditions are met. If the request is not accepted, then it is an error response or a sensing termination notification.

[0281] Outputs, optionally: (i) timestamp of the sensing result, (ii) location of the target object, (iii) confidence level of the sensing prediction, (iv) revised wait time, (v) object ID of the different objects contained in the sensing result with respect to object type ID (if the sensing is focused on an object) or (vi) environmental condition ID.

[0282] Note that when using Nsf_SensingInfo_Request, it may contain at least one, but not limited to, the following parameters: (i) (a set) sensing ID, (ii) region of interest, (iii) target UE (if applicable), and (iv) time window of interest. Nnef_SensingExposure service

[0283] This service allows SF service consumers (i.e., untrusted AFs) to subscribe to or request sensing results via NEF.

[0284] Nnef_SesningExposure_Subscribe operation

[0285] Service operation name: Nnef_SensingExposure_Preparation.

[0286] Description: Optional preparation for untrusted AF before subscribing to SF sensing results with specific parameters.

[0287] Inputs, required: (i) a set of sense IDs, (ii) sense filtering information (e.g., region of interest, interested UEs, etc.), and (iii) the target time period for sense subscription.

[0288] Inputs, optional: (i) use case context, (ii) target of the sensing report (per sensing ID), (iii) sensing filtering information, (iv) sensing result report, (v) sensing result delivery strategy, (vi) if the sensing focuses on an object, then: (vi.a) sensing description, (vi.b) sensing object type ID, (vii) sensing KPI.

[0289] Output, required: A positive acknowledgment when subscription readiness is accepted. Otherwise, a negative response indicating the reason, such as insufficient wireless resources, object out of range, etc., if subscription readiness cannot be fulfilled.

[0290] Output, optional: None.

[0291] Nnef_SensingExposure_Subscribe operation

[0292] Service operation name: Nnef_SensingExposure_Subscribe.

[0293] Description: SF service consumers (i.e., untrusted AFs) subscribe to or modify existing subscriptions regarding sensing results.

[0294] Inputs, required: (i) (a set) sensor ID / event ID, (ii) the target of the sensor report (per sensor ID and / or event ID), (iii) the target time period of the sensor subscription, and (iii) the transaction ID (if the subscription has been established and the intent is to request modification).

[0295] Inputs, optional: (i) use case context, (ii) notification address, (iii) sensing filtering information, (iv) sensing result report, (v) sensing result delivery strategy, (vi) if sensing focuses on an object, then: (vi.a) sensing description, (vi.b) sensing object ID, (vii) sensing KPI, (viii) preparation tag.

[0296] Output, required: When the subscription is accepted: Transaction ID (required for any subscription transaction) and expiration time (required if the subscription expires based on the operator's policy). When ready to flag an activity, a response indicating whether the readiness conditions are met. When the subscription is not accepted, an error response or a sensed termination notification.

[0297] Output, optional: includes the first corresponding sensing report (if available).

[0298] Note that when using Nnef_SensingExposure_Subscribe, it may contain at least, but not limited to, the following parameters: (i) a set of sensing IDs, (ii) the region of interest, (iii) the target UE (if applicable), and (iv) the target time period for sensing subscription. Nnef_SensingExposure_Unsubscribe service operation

[0299] Service operation name: Nsf_SensingExposure_Unsubscribe

[0300] Description: SF service consumers cancel their existing SF subscriptions regarding sensing results.

[0301] Input, required: Transaction ID.

[0302] Output, required: Indicator of the result of the operation execution.

[0303] Nnef_SensingExposure_Notify service operation

[0304] Service operation name: Nnef_SensingExposure_Notify.

[0305] Description: NEF reports sensing results to consumers who have previously subscribed to SF services.

[0306] Input, required: If the request is accepted, then: (i) the sensing ID / event ID, (ii) the sensing result, and (iii) the transaction ID assigned by the SF service consumer during the subscription period. If the request is not accepted, then an error response or sensing termination notification.

[0307] Inputs, optional: (i) timestamp of the sensing result, (ii) location of the target object, (iii) confidence level of the sensing prediction, (iv) revised wait time, (v) object ID of the different objects contained in the sensing result with respect to object type ID (if the sensing is focused on an object) or (vi) environmental condition ID.

[0308] Output, required: Indicator of the result of the operation execution.

[0309] Nnef_sensing exposure_Preparation service operation

[0310] Service operation name: Nnef_SensingExposure_Preparation.

[0311] Description: Optional preparation for untrusted AF before issuing a request for SF sensing results with specific parameters. Input, required: (i) (a set) sensing IDs, (ii) sensing filtering information (e.g., region of interest, interested UE, time window of interest).

[0312] Inputs, optional: (i) use case context, (ii) target of the sensing report (per sensing ID), (iii) sensing filtering information, (iv) sensing result report, (v) sensing result delivery strategy, (vi) if the sensing focuses on an object, then: (vi.a) sensing description, (vi.b) sensing object type ID, (vii) sensing KPI.

[0313] Required output: A positive confirmation if subscription readiness is accepted. Otherwise, a negative response indicating the reason, such as insufficient wireless resources or object out of range, if subscription readiness cannot be fulfilled.

[0314] Output, optional: None.

[0315] Nnef_SensingExposure_Fetch service operation

[0316] Service operation name: Nnef_SensingExposure_Fetch.

[0317] Description: SF service consumer request sensing results.

[0318] Required inputs: (i) (a set) Sensing ID / Event ID, (ii) Target of the sensing report (per Sensing ID and / or Event ID), (iii) Time window of interest.

[0319] Inputs, optional: (i) use case context, (ii) notification address, (iii) sensing filtering information, (iv) sensing result report, (v) sensing result delivery strategy, (vi) if sensing focuses on an object, then: (vi.a) sensing description, (vi.b) sensing object ID, (vii) sensing KPI, (viii) preparation tag.

[0320] Output, required: If the request is accepted, then it is: (i) the sensor ID / event ID, (ii) the sensing result; if the activity is ready to be marked, then the response indicates whether the preparation conditions are met. If the request is not accepted, it is an error response or a sensing termination notification.

[0321] Outputs, optionally: (i) timestamp of the sensing result, (ii) location of the target object, (iii) confidence level of the sensing prediction, (iv) revised wait time, (v) object ID of the different objects contained in the sensing result with respect to object type ID (if the sensing is focused on an object) or (vi) environmental condition ID.

[0322] Note that when using Nnef_SensingExposure_Fetch, it may contain at least one of the following parameters, but not limited to: (i) (a set) sensing ID, (ii) region of interest, (iii) target UE (if applicable), and (iv) time window of interest.

[0323] The inputs and outputs associated with the newly proposed sensing service operation described above should be considered as instances. The new sensing service operation can be implemented by including at least one of the proposed listed parameters, and is not limited to the list of parameters included in each different service operation instance.

[0324] On one hand, a device (e.g., SF) in a wireless communication system is provided, the device comprising: a processor; and a memory coupled to the processor. The memory contains instructions, when executed by the processor, to cause the device to: receive a service request from a consumer entity (e.g., an SF service consumer and / or an AF), wherein the service request is: a subscription request to cause the consumer entity to subscribe to receiving sensing results (e.g., according to one or more subscription parameters specified in the service request or as specified by one or more subscription parameters specified in the service request); or a request for the consumer entity to receive a single (e.g., one-time) response including sensing results (e.g., a request to receive only a single set of sensing data in a single response); collect sensing data according to the service request; process the sensing data and transmit the sensing results for use by the consumer entity.

[0325] In an embodiment where the service request is a subscription request to cause the consumer entity to subscribe to receive sensing results, the memory may further contain instructions, when executed by the processor, to cause the device to subscribe the consumer entity to receive sensing results in accordance with the service request.

[0326] The memory may further contain instructions, when executed by the processor, to cause the device to receive a preparation message including one or more requirements of the service request before receiving the service request. In some embodiments, if all one or more requirements of the service request can be satisfied by the device, then the device may transmit an acknowledgment message confirming that all one or more requirements of the service request can be satisfied by the device and / or that the service request can be supported for use by the consumer entity. In some embodiments, if one or more of the one or more requirements of the service request cannot be satisfied by the device, then the device may transmit a notification indicating that the service request cannot be supported and / or that the one or more requirements of the service request cannot be satisfied by the device, and optionally also defining possible reasons (i.e., reasons why the one or more requirements of the service request cannot be satisfied by the device) for use by the consumer entity.

[0327] The service request may be received from the consumer entity (which may be an AF, for example, an untrusted AF) via an intermediary entity (e.g., the NEF). The service request received via the intermediary entity (e.g., the NEF) may have been processed by the intermediary entity to apply one or more restrictions or filters to the service request.

[0328] The service request may contain one or more parameters selected from the following parameter groups:

[0329] - Sensing ID, which identifies the type of sensing to be performed in order to collect the sensing data;

[0330] - Sensing event identifier, i.e., an event ID that can identify the event that triggers the collection, generation or sensing of the sensing results;

[0331] - Sensing description, which provides the sensed size or shape of a target entity or object or environmental conditions, including the object's location information, expected velocity, orientation, direction of travel or movement, or a subset or combination thereof.

[0332] - An AI / ML model that is prepared (i.e. trained) to identify the sensed size or shape of a target entity or object or environmental condition, including the object’s location information, expected velocity, orientation, direction of travel or movement, or a subset or combination thereof.

[0333] - A target entity or object, such as an interested UE, requesting sensing results about, toward, or for it. This can be specified by per-sensing ID and / or event ID. For example, the service request may include a request to perform sensing of one or more target objects (in the target area) and to collect sensing data;

[0334] -The target area to be sensed, for example, can be the geographic area in which one or more target entities will be sensed / measured;

[0335] - The mobility profile of the target entity;

[0336] - The time period during which sensing data will be collected, processed and / or transmitted, for example, the target time period for sensing results subscription in the case of sensing and subscription;

[0337] - Transaction ID, which can be an identifier identifying a successful subscription to receive sensing data by the consumer entity, for example...

[0338] If a subscription has already been established and the intention is to request modifications;

[0339] - Object ID or environment condition ID, which can be used to identify previously sensed (i.e., discovered) objects or environment conditions.

[0340] - Use case context;

[0341] - The notification address to which the sensing results will be transmitted;

[0342] - Sensing filtering information, which may indicate one or more conditions to be met before the sensing results are collected and / or transmitted;

[0343] - A parameter indicating how the sensing results will be reported, i.e., sensing result reporting parameters;

[0344] -The strategy for providing the sensing results, i.e., the strategy for providing sensing results;

[0345] - Key performance indicators (KPIs) or QoS requirements of the sensed data; and / or

[0346] - Licensing, restrictions and / or preferences regarding sensor technology.

[0347] The memory may further contain instructions that, when executed by the processor, cause the device to transmit one or more parameters selected from a group of parameters for use by the consumer:

[0348] - The timestamp of the sensing result indicates when the sensing result was generated and / or transmitted;

[0349] - Target ID or object ID, which identifies the target entity about, toward, or for which the sensing data is collected;

[0350] - Target entity or target object, for example, the location of the UE of interest;

[0351] -Environmental Condition ID, which identifies the conditions of the environment in which the sensed data was collected;

[0352] - Transaction ID, for example, an identifier that identifies a successful subscription to receive sensing results by the consumer entity, e.g.

[0353] If a subscription has already been established and the intention is to request modifications;

[0354] - The confidence level associated with the sensing result, i.e., the confidence level of the sensing prediction; and / or

[0355] - Provides an indication of the (e.g., revised) waiting time for the sensing results.

[0356] The device may be a sensing function (SF). The consumer entity may be a service consumer (AF) or application function (AF) of the SF.

[0357] On the other hand, a method is provided in a device (e.g., SF) in a wireless communication system. Figure 9The illustration shows a process flowchart of certain steps of this method 900. Method 900 includes: receiving 902 a service request from a consumer entity (e.g., an SF service consumer and / or an AF), wherein the service request is: a subscription request to enable the consumer entity to subscribe to receiving sensing results (e.g., based on one or more subscription parameters specified in the service request), or a request for the consumer entity to receive a single (e.g., one-time) response including sensing results (e.g., a request to receive only a single set of sensing results in a single response); collecting 904 sensing data according to the service request; and processing the sensing data to create sensing results and transmitting the sensing results for use by the consumer entity 906.

[0358] In an embodiment where the service request is a subscription request to enable the consumer entity to subscribe to receive sensing data, the method may further include enabling the consumer entity to subscribe to receive sensing results based on the service request.

[0359] Method 900 may further include receiving a preparation message including one or more requirements of the service request before receiving the service request. If all or more of the requirements contained in the service subscription can be satisfied by the device, then the device may send a confirmation message confirming that the sensing service can be satisfied by the device for use by the consumer entity. If one or more of the requirements of the service request cannot be satisfied by the device, then the device may send (e.g., in an error message) a notification indicating that the one or more requirements of the service request cannot be satisfied by the device and optionally indicating the corresponding reason for the failure to satisfy the one or more requirements for use by the consumer entity.

[0360] The service request may be received from the consumer entity (which may be an AF, for example, an untrusted AF) via an intermediary entity (e.g., the NEF). The service request received via the intermediary entity (e.g., the NEF) may have been processed by the intermediary entity to apply one or more restrictions to the service request.

[0361] In some embodiments, method 900 may be executed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0362] In another aspect, a device (e.g., NEF) is provided in a wireless communication system, the device including a processor and a memory coupled to the processor. The memory contains instructions, when executed by the processor, to cause the device to: receive a service request from a consumer entity (e.g., an AF, such as an untrusted AF), wherein the service request is: a subscription request to cause the consumer entity to subscribe to receiving sensing results (e.g., according to one or more subscription parameters specified in the service request); or a request for the consumer entity to receive a single (e.g., one-time) response including sensing results (e.g., a request to receive only a single set of sensing results in a single response); process the service request to enforce one or more restrictions on one or more parameters of the service request; and transmit the processed service request to a sensing function in the wireless communication system.

[0363] The memory may further contain instructions, when executed by the processor, to cause the device to perform the following operations: in response to the processed service request, receive a sensing result from the sensing function; process the sensing result to enforce one or more restrictions on one or more parameters of the sensing result; and transmit the processed sensing result to the consumer entity.

[0364] In another aspect, a device (e.g., NEF) is provided in a wireless communication system, the device including a processor and a memory coupled to the processor. The memory contains instructions, when executed by the processor, to cause the device to: receive sensing results from a sensing function for transmission to a consumer entity (e.g., an AF, such as an untrusted AF); process the sensing results to enforce one or more restrictions on one or more parameters of the sensing results; and transmit the processed sensing results to the consumer entity. The one or more restrictions may, for example, be determined by the device from a service request received by the device from the consumer entity. The service request may be: a subscription request causing the consumer entity to subscribe to receiving sensing results (e.g., based on one or more subscription parameters specified in the service request); or a request for the consumer entity to receive a single (e.g., one-time) response including the sensing results (e.g., a request to receive only a single set of sensing results in a single response).

[0365] In any of the foregoing aspects, the memory may further contain instructions that, when executed by the processor, cause the device to map a transaction ID to a service request (e.g., a successfully satisfied service request).

[0366] In any of the foregoing aspects, the memory may further contain instructions, when executed by the processor, to cause the device to map a transaction ID to a successful subscription by the consumer entity to receive sensing data from the sensing function.

[0367] In any of the foregoing aspects, the memory may contain instructions that, when executed by the processor, cause the device to maintain one or more mappings of records. Each mapping may identify a transaction ID associated with a successful subscription by the consumer entity to receive sensing results from the sensing function.

[0368] On the other hand, a method is provided in a device (e.g., NEF) in a wireless communication system. Figure 10 The illustration shows a process flowchart of certain steps of this method 1000. Method 1000 includes: receiving 1002 a service request from a consumer entity (e.g., an AF, such as an untrusted AF), wherein the service request is: a subscription request to enable the consumer entity to subscribe to receiving sensing results (e.g., according to one or more subscription parameters specified in the service request); or a request for the consumer entity to receive a single (e.g., one-time) response including the sensing results; processing 1004 the service request to enforce one or more restrictions on one or more parameters of the service request; and transmitting 1006 the processed service request to a sensing function in the wireless communication system.

[0369] In some embodiments, method 1000 may be executed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0370] On the other hand, a method is provided in a device (e.g., NEF) in a wireless communication system. Figure 11 The illustration shows a flowchart of some steps of this method 1100. Method 1100 includes: receiving 1102 sensing results from a sensing function for transmission to a consumer entity (e.g., an AF, such as an untrusted AF); processing 1104 the sensing results to enforce one or more restrictions on one or more parameters of the sensing results; and transmitting 1106 the processed sensing results to the consumer entity. The one or more restrictions may be determined from a service request received by the device from the consumer entity, wherein the service request is: a subscription request to enable the consumer entity to subscribe to receiving sensing results (e.g., based on one or more subscription parameters specified in the service request); or a request for the consumer entity to receive a (e.g., only) single (e.g., one-time) response containing the sensing results.

[0371] In some embodiments, method 1100 may be executed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0372] The method according to any of the foregoing aspects may further include maintaining a record of one or more transaction IDs, each transaction ID identifying a successful subscription by the consumer entity to receiving sensing results from the sensing function.

[0373] Currently, the sensing service lacks a formal definition for subscription or request service operations that allow sensing service consumers to request sensing results. If this sensing consumer is an untrusted AF (Automatic Sensor Provider), then the NEF service operation needs to be enhanced to handle sensing subscriptions or requests. In many cases, sensing processes mobile UEs or objects, for example, consider vehicles or drones. The sensing request preferably reflects potential mobility-specific attributes associated with the mobile UE or object. Additionally, the sensing request should preferably be able to handle environmental conditions.

[0374] The apparatus and methods described herein propose: (i) a sensing process for preparing, subscribing to, and requesting sensing services considering trusted and untrusted consumers; (ii) sensing open content with particular focus on objects, environmental conditions, and mobility; and (iii) sensing operations for subscribing to, requesting, notifying, reporting, and retrieving sensing results in the context of the sensing process for subscribing to and requesting sensing services.

[0375] Current state-of-the-art technologies have not yet been developed for the formal process of subscribing to and requesting sensing results, especially for consumers of untrusted sensing services. Furthermore, when issuing a sensing subscription or request, there are no means to capture information about the object, environmental conditions, and mobility.

[0376] The devices and methods described herein provide means for requesting sensing services, such as: i) subscribing to and unsubscribing from sensing services considering trusted and untrusted consumers, specifying all relevant service operations; and ii) requesting sensing services considering trusted and untrusted consumers, specifying all relevant service operations.

[0377] The present invention provides an apparatus and method that enables sensing or logical sensing functions contained in a mobile operator network to receive and respond to requests from service consumers and provide sensing results to service consumers.

[0378] Consumers can subscribe or unsubscribe to receive the sensing results.

[0379] Consumers can request the sensing results.

[0380] A subscription or sensing request may contain at least one of the following parameters: a set of sensing IDs and / or event IDs; the target of the sensing report for each sensing ID and / or event ID; a sensing description; the target time period for the sensing subscription (if the sensing is related to the subscription); a transaction ID (if the subscription has been established and the intent is to request modification); a use case context; a notification address; sensing filtering information; sensing result reporting information; a sensing result delivery strategy; sensing KPIs; and / or, if the sensing focuses on an object, the sensing object type ID.

[0381] Preparation steps can be performed before issuing / sending a subscription or request.

[0382] Subscription notifications may contain sensing results per sensing ID / event ID, transaction ID, and / or at least one of the following parameters: timestamp of the sensing result; location of the target object; transaction ID (e.g., if the subscription has been established and the intent is to request modification); confidence level of the sensing prediction; revised wait time; object ID that identifies the different objects contained in the sensing results for the object type ID (if the sensing is focused on an object); and / or environmental condition ID.

[0383] SF can issue a sensing termination notice to sensing consumers to cancel their subscription to the sensing feature service.

[0384] Sensing subscriptions and notifications can be controlled by open functions that can: authorize untrusted sensing service consumers; track transaction IDs associated with successful subscriptions; enforce inbound restrictions related to service parameters permitted for use by untrusted consumers; and / or enforce outbound restrictions related to service parameters permitted for use by untrusted consumers.

[0385] It should be noted that the above methods and apparatus are illustrative and not limiting of the invention, and those skilled in the art will be able to devise many alternative arrangements without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in the claims, and "a (or an)" does not exclude a plurality, and a single processor or other unit may perform the functions of several units recited in the claims. Any reference numerals in the claims should not be construed as limiting their scope.

[0386] Furthermore, while examples have been given in the context of specific communication standards, these examples are not intended to limit the communication standards to which the disclosed methods and devices can be applied. For example, although specific examples have been given in the context of 3GPP, the principles disclosed herein can also be applied to another wireless communication system, and in fact, to any communication system that uses routing rules.

[0387] The method may also be embodied as a set of instructions stored on a computer-readable medium, which, when loaded into a computer processor, digital signal processor (DSP), etc., causes the processor to execute the aforementioned method.

[0388] The described methods and apparatus may be practiced in other specific forms. The described methods and apparatus should be considered in all respects as illustrative only and not restrictive. Therefore, the scope of the invention is indicated by the appended claims rather than the foregoing description. All modifications within the meaning and scope of the equivalents of the claims should be covered within the scope of the claims.

[0389] The following abbreviations are relevant to the fields covered in this document:

[0390] 3GPP Third Generation Partnership Project

[0391] 5G (Fifth Generation Mobile Communication)

[0392] AI / ML (Artificial Intelligence / Machine Learning)

[0393] AF application functions

[0394] AMF Access and Mobility Management Functions

[0395] CP control plane

[0396] EPC Evolution Group Core

[0397] E-UTRA Evolutionary Universal Terrestrial Radio Access

[0398] GLMC Gateway Mobile Location Center

[0399] GPS Global Positioning System

[0400] IMT-2000 International Mobile Telecommunications Standard (IMT) 2020

[0401] ISAC Integrated Sensing and Communication

[0402] LMF location management function

[0403] NEF Network Open Functions

[0404] NF Network Functions

[0405] NR New Radio

[0406] NRF Network Repository Functionality

[0407] NEDAF network data analysis function

[0408] OAM Operation Management and Maintenance

[0409] PCF policy control function

[0410] RAN (Radio Access Network)

[0411] RF (Radio Frequency)

[0412] SF sensing function

[0413] S-NSSAI Single Network Slice Selection Auxiliary Information

[0414] TA tracking area

[0415] UDM User Data Manager

[0416] UE User Equipment

[0417] UP User Plane.

Claims

1. A device in a wireless communication system, the device comprising: processor; and A memory coupled to the processor, the memory containing instructions that, when executed by the processor, cause the device to perform the following operations: Receive a service request from a consumer entity, wherein the service request is: The subscription request that enables the consumer entity to subscribe to receive the sensing results; or The consumer entity receives a request to receive a single response including the sensing results; Collect sensing data according to the service request; The sensing data is processed to create the sensing result; and The sensing results are transmitted for use by the consumer entity.

2. The device according to claim 1, wherein: The service request is a subscription request that causes the consumer entity to subscribe to receive the sensing results; and The memory further contains instructions, when executed by the processor, to cause the device to subscribe the consumer entity to receive the sensing results in accordance with the service request.

3. The device according to claim 1 or 2, wherein the memory contains instructions, when executed by the processor, to cause the device to perform the following operations before receiving the service request: Receive a preparation message including one or more requests related to the service request; and: If all one or more of the requirements of the service request can be met by the device, then a confirmation message indicating that all one or more of the requirements of the service request can be met by the device is transmitted for the consumer entity to use; or If one or more of the requirements of the service request cannot be met by the device, then a notification indicating that the one or more requirements of the service request cannot be met by the device is transmitted for the consumer entity to use.

4. The device according to any one of claims 1 to 3, wherein: The service request is received from the consumer entity via an intermediary entity; and The service request received via the intermediate entity has been processed by the intermediate entity to apply one or more restrictions or filters to the service request.

5. The device according to claim 4, wherein: The consumer entity is the application function AF; and / or The intermediate entity is the Network Open Function (NEF).

6. The device according to any one of claims 1 to 5, wherein the service request contains one or more parameters selected from the group consisting of: Sensor ID; Sensing event identifier; Sensing descriptions related to the target entity or object or environmental conditions; Artificial intelligence or machine learning (AI / ML) models related to the target entity, object, or environmental conditions; Regarding the target entity for which it requests the sensing results; The target area to be sensed; Mobility profile of the target entity; The time period during which the sensing results will be transmitted; Transaction ID; The object ID associated with the previously sensed and reported object; Environmental condition ID associated with previously sensed and reported environmental conditions; Use case context; The address to which the sensing results will be transmitted; Sensing filtering information that indicates one or more conditions to be met before collecting sensing data and / or transmitting the sensing results; Parameters indicating how the sensing results will be reported; The strategy for providing the sensing results; The key performance indicators (KPIs) of the sensed data; and / or Permissions, restrictions and / or preferences regarding sensor technology.

7. The device according to any one of claims 1 to 6, wherein the memory contains instructions, when executed by the processor, to cause the device to transfer one or more parameters selected from a group of parameters for use by the consumer: The timestamp of the sensing results; Regarding the object ID and / or environmental condition ID for which the sensing data is collected; The location of the target entity; Identify the environmental condition ID of the environment in which the sensing data is collected during the collection of the sensing data; Transaction ID; The confidence level associated with the sensing results; and / or An indication of the waiting time used to provide the sensing results.

8. The device according to any one of claims 1 to 7, wherein: The device is a sensing function SF; and / or The consumer entity is either an SF service consumer or an application function AF.

9. A method in a device of a wireless communication system, the method comprising: Receive a service request from a consumer entity, wherein the service request is: The subscription request that enables the consumer entity to subscribe to receive the sensing results; or The consumer entity receives a request to receive a single response including the sensing results; Collect sensing data according to the service request; The sensing data is processed to create the sensing result; and The sensing results are transmitted for use by the consumer entity.

10. The method according to claim 9, wherein: The service request is a subscription request that causes the consumer entity to subscribe to receive the sensing results; and The method further includes causing the consumer entity to subscribe to receive the sensing results based on the service request.

11. The method of claim 9 or 10, further comprising, before receiving a service request: Receive a preparation message including one or more requests related to the service request; and: If all one or more of the requirements contained in the service subscription can be met by the device, then a confirmation message indicating that the sensing service can be met by the device is sent for the consumer entity to use; or If one or more of the requirements of the service request cannot be met by the device, then a notification indicating that the one or more requirements of the service request cannot be met by the device is sent for the consumer entity to use.

12. The method according to any one of claims 9 to 11, wherein: The service request is received from the consumer entity via an intermediary entity; and The service request received via the intermediate entity has been processed by the intermediate entity to apply one or more restrictions to the service request.

13. A device in a wireless communication system, the device comprising: processor; and A memory coupled to the processor, the memory containing instructions that, when executed by the processor, cause the device to perform the following operations: Receive a service request from a consumer entity, wherein the service request is: The subscription request that enables the consumer entity to subscribe to receive the sensing results; or The consumer entity receives a request to receive a single response including the sensing results; Process the service request to enforce one or more restrictions on one or more parameters of the service request; and The processed service request is transmitted to the sensing function in the wireless communication system.

14. The device of claim 13, wherein the memory contains instructions that, when executed by the processor, cause the device to perform the following operations: In response to the processed service request, the sensing result is received from the sensing function; Process the sensing results to enforce one or more restrictions on one or more parameters of the sensing results; and The processed sensing results are transmitted to the consumer entity.

15. A device in a wireless communication system, the device comprising: processor; and A memory coupled to the processor, the memory containing instructions that, when executed by the processor, cause the device to perform the following operations: Receive sensing results from the sensing function for transmission to the consumer entity; Process the sensing results to enforce one or more restrictions on one or more parameters of the sensing results; and The processed sensing results are transmitted to the consumer entity.

16. The device according to any one of claims 13 to 15, wherein: The consumer entity is the application function AF; and / or The device in question is a Network Open Function (NEF).

17. The device according to any one of claims 13 to 16, wherein the memory contains instructions that, when executed by the processor, cause the device to map a transaction ID to a service request.

18. The device according to any one of claims 13 to 17, wherein the memory contains instructions, when executed by the processor, to cause the device to map a transaction ID to a successful subscription by the consumer entity to receiving sensing results from the sensing function.

19. The device according to any one of claims 13 to 18, wherein the memory contains instructions for maintaining one or more mappings of records when executed by the processor, each mapping identifying a transaction ID associated with a successful subscription by the consumer entity to receiving sensing results from the sensing function.

20. A method in a device of a wireless communication system, the method comprising: Receive a service request from a consumer entity, wherein the service request is: The subscription request that enables the consumer entity to subscribe to receive the sensing results; or The consumer entity receives a request to receive a single response including the sensing results; Process the service request to enforce one or more restrictions on one or more parameters of the service request; and The processed service request is transmitted to the sensing function in the wireless communication system.

21. A method in a device of a wireless communication system, the method comprising: Receive sensing results from the sensing function for transmission to the consumer entity; Process the sensing results to enforce one or more restrictions on one or more parameters of the sensing results; and The processed sensing results are transmitted to the consumer entity.

22. The method of claim 20 or 21, further comprising maintaining a record of one or more transaction IDs, each transaction ID identifying a successful subscription by the consumer entity to receiving sensing results from the sensing function.

Images