Enabler for sensing entity discovery and selection

Abstract

A network node can receive sensing capability information associated with a plurality of sensing entities. The sensing capability information can include an indication of a respective sensing mode supported by each sensing entity. The network node can receive a sensing request including an indication of a sensing service requirement. The network node can select a plurality of candidate sensing entities from the plurality of sensing entities based on the sensing service requirement and / or the sensing capability information associated with each of the plurality of sensing entities. The network node can receive respective sensing information from each of the plurality of candidate sensing entities. The network node can select a subset of candidate sensing entities from the plurality of candidate sensing entities based on the respective sensing information from each of the plurality of candidate sensing entities. The network node can transmit a sensing response.

Description

[0001] Cross-references to related applications This application claims priority to U.S. Provisional Patent Application No. 63 / 617,640, filed January 4, 2024, the entire contents of which are incorporated herein by reference. Background Technology

[0002] RAN can refer to a radio access network based on 5G RAT and / or evolved E-UTRA connected to the next-generation core network. Access Control and Mobility Management Functions (AMF) may include one or more of the following functions: registration management, connection management, reachability management, mobility management, etc. Session Management Functions (SMF) may include one or more of the following functions: session management (including session establishment, modification, and / or release), WTRU IP address allocation, selection and / or UP function control, etc. User Plane Functions (UPF) may include one or more of the following functions: packet routing and forwarding, packet inspection, service usage reporting, etc. Summary of the Invention

[0003] A network node can receive sensing information associated with one or more sensing entities. The network node can receive sensing information from access and mobility management functions and / or from a second network node. The sensing information may include one or more sensing capabilities and / or one or more sensing requests. The network node can determine one or more candidate sensing entities from among the one or more sensing entities based on the received sensing information. The network node can send a sensing request request to one or more candidate sensing entities. The network node can receive a sensing request response from each of the one or more candidate sensing entities. The network node can determine one or more radio access network (RAN) nodes and / or one or more radio transmit / receive units (WTRUs) based on the sensing request responses or sensing information from one or more candidate sensing entities. Candidate sensing entities may include one or more RAN nodes or one or more WTRUs. The network node can send configuration information to one or more RAN nodes and / or one or more WTRUs to configure one or more RAN nodes and / or one or more WTRUs based on the sensing request responses and / or sensing information from one or more candidate sensing entities. The network node can send a discovery response to a second network node to update sensing information associated with one or more of the following: one or more sensing entities, one or more candidate sensing entities, one or more RAN nodes, or one or more WTRUs.

[0004] A network node can receive sensing service requests from one or more of the following: one or more Transmit / Receive Units (WTRUs) or one or more Radio Access Network (RAN) nodes. The network node can determine the authorization of one or more WTRUs or one or more RAN nodes. The network node can send a sensing capability message to a second network node. The sensing capability message can request sensing information from one or more sensing entities. The network node can receive a sensing capability response message. The sensing capability response message can include sensing information from one or more sensing entities. The sensing information can include one or more sensing capabilities and / or one or more sensing requests. The network node can determine one or more candidate sensing entities based on the sensing information of one or more sensing entities. One or more sensing entities can include one or more candidate sensing entities. The network node can send a sensing request request to one or more candidate sensing entities. The network node can receive a sensing request response from each of the one or more candidate sensing entities. The network node can send a sensing response message to one or more candidate sensing entities. The network node can send configuration information to one or more RAN nodes and / or one or more WTRUs to configure one or more RAN nodes and / or one or more WTRUs based on the sensing request responses and / or sensing information from one or more candidate sensing entities.

[0005] One or more sensing capabilities may include one or more of the following: data reporting frequency, data sampling size, sensing mode, one or more supported sensing services, one or more 3GPP RAN sensing capabilities, one or more non-3GPP sensing capabilities, sensor output data type, sensing data processing type, data compression capability, protocol information for sensing data and control data, network transmission information for sensing data and control data, sensing node role, authorization information, entity availability, entity utilization, time availability, and / or sensing area.

[0006] One or more sensing requirements may include one or more requirements associated with one or more of the following: data time validity, one or more delay requirements; proximity, location of interest, sensing data communication preferences, periodicity, frequency, sample size, time frame for performing the sensing task, or sensing speed.

[0007] A network node (e.g., a sensing network function (NF)) can receive sensing capability information associated with multiple sensing entities. The sensing capability information may include an indication of the corresponding sensing modes supported by each sensing entity. A network node (e.g., a sensing NF) can receive sensing requests. Sensing requests may include an indication of sensing service requirements. A network node (e.g., a sensing NF) can select multiple candidate sensing entities from the multiple sensing entities based on, for example, the sensing service requirements and / or sensing capability information associated with each of the multiple sensing entities. A network node (e.g., a sensing NF) can receive corresponding sensing information from each of the multiple candidate sensing entities. The sensing information may indicate the time when each candidate sensing entity can perform sensing and / or the corresponding sensing modes supported by each of the multiple candidate sensing entities. A network node (e.g., a sensing NF) can select a subset of candidate sensing entities from the multiple candidate sensing entities based on the corresponding sensing information from each of the multiple candidate sensing entities. A network node (e.g., a sensing NF) can send a sensing response. The sensing response may indicate a subset of candidate sensing entities.

[0008] A sensing response can indicate the available time for each sensing entity in a subset of sensing entities to perform sensing. A sensing request can include the desired sensing mode. A network node (e.g., a sensing NF) can select multiple candidate sensing entities based on the desired sensing mode. The sensing mode can be monostatic or bistatic.

[0009] Sensing capability information may include one or more of the following: data reporting frequency, sampling size, one or more supported sensing services, sensor output data type, sensing data processing type, one or more data compression capabilities, protocol information for sensing and control data, sensing area, sensing node role, authorization information, entity availability, entity utilization, and / or network transmission information for sensing and control data.

[0010] Sensing service requirements may include one or more of the following: data time validity, one or more latency requirements, proximity, location of interest, one or more sensing data communication preferences, data reporting frequency, sample size, time frame, sensing service, one or more quality of service (QoS) parameters, or sensing speed.

[0011] Sensing capability information can be received from the Access and Mobility Management Function (AMF). Sensing capability information may include one or more of the following: sensing waveform, coverage area, maximum distance to the sensing target, and / or maximum power used for sensing.

[0012] Network nodes can send configuration information to each sensing entity in the candidate sensing entity subset. The configuration information may include sensing task information for each sensing entity in the candidate sensing entity subset to perform sensing tasks. The sensing task information may include a corresponding timer value for each sensing entity in the candidate sensing entity subset, to initiate the sensing task based on the corresponding timer value.

[0013] A subset of candidate sensing entities may include a first sensing entity and / or a second sensing entity. Sensing task information may include an indication that the first sensing entity will communicate with the second sensing entity. Attached Figure Description

[0014] A more detailed understanding can be obtained through the following detailed description given by way of example in conjunction with the accompanying drawings. Like the detailed description, the figures in these drawings are illustrative. Similarly, the drawings and detailed description should not be considered limiting, and other equally valid examples are possible. Furthermore, the same reference numerals (“ref.”) denote the same elements, and wherein: Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented.

[0015] Figure 1B This illustrates a method according to one embodiment. Figure 1A The system diagram shown is of an example wireless transmit / receive unit (WTRU) used in the communication system.

[0016] Figure 1C This illustrates a method according to one embodiment. Figure 1A The system diagram shows an example radio access network (RAN) and an example core network (CN) used in the communication system shown.

[0017] Figure 1D This illustrates a method according to one embodiment. Figure 1A The system diagram shows another example RAN and another example CN used in the communication system shown.

[0018] Figure 2 An example reference model for 5G / next-generation networks is depicted.

[0019] Figure 3 An example of pedestrian / animal intrusion detection is depicted.

[0020] Figure 4 An example of intruder detection in a smart home environment is depicted.

[0021] Figure 5 Examples of objects sensed by base stations (BS) and / or wireless transmit / receive units (WTRU) are depicted.

[0022] Figure 6A and 6B A flowchart illustrating an exemplary process for discovery initiated by an Application Function (AF) / Network Function (NF) is provided.

[0023] Figure 7A , 7B 7C depicts a flowchart illustrating a discovery initiated by an example WTRU / RAN.

[0024] Figure 8A and 8B A flowchart illustrating an example of sensor activation and / or operation management is provided. Detailed Implementation

[0025] In the following detailed description, numerous specific details are set forth to provide a full understanding of the embodiments and / or examples disclosed herein. However, it will be understood that these embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, processes, components, and circuits have not been described in detail so as not to obscure the description below. Furthermore, embodiments and examples not specifically described herein may be practiced in place of or in combination with embodiments and other examples explicitly, implicitly, and / or inherent (collectively, the “Provided”) described, disclosed, or otherwise provided herein. Although various embodiments are described and / or claimed herein, in which apparatuses, systems, devices, etc., and / or any elements thereof perform operations, processes, algorithms, functions, etc., and / or any portions thereof, it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc., and / or any element thereof is configured to perform any operation, process, algorithm, function, etc., and / or any portion thereof.

[0026] Example communication systems, networks, and devices.

[0027] The methods, processes, apparatus, and systems provided herein are well-suited for communications involving wired and wireless networks. (See also...) Figure 1A-1D An overview of various types of wireless devices and infrastructures is provided, in which various elements of the network can be utilized, performed, arranged and / or adapted and / or configured to the methods, apparatuses and systems provided herein.

[0028] Figure 1AThis is a schematic diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messages, and broadcasts to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Spread Spectrum OFDM (ZT-UW-DTT-s-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and so on.

[0029] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.

[0030] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, eNodeBs, home node Bs, home eNodeBs, gNBs, NR NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base station and / or network elements.

[0031] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0032] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0033] More specifically, as described above, the communication system 100 can be a multi-access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0034] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0035] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using a new radio (NR).

[0036] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0037] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0038] For example, Figure 1A Base station 114b can be a wireless router, home node B, home eNodeB, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b may not need to access the Internet 110 via CN 106 / 115.

[0039] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although in Figure 1AAlthough not shown, it should be understood that RAN104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to connecting to RAN 104 / 113, which may utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0040] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

[0041] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example... Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a, which may employ cellular-based radio technology, and to communicate with base station 114b, which may employ IEEE 802 radio technology.

[0042] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1B As shown, among other things, WTRU 102 may include, in particular, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0043] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0044] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) over air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 can be, for example, a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0045] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmit / receive elements 122. More specifically, WTRU 102 may employ MIMO technology. Thus, in one embodiment, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals on air interface 116.

[0046] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, for example, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0047] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data therefrom. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 can access and store information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a user identification module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 can access and store information from memory that is not physically located on WTRU 102 (e.g., a server or home computer (not shown)).

[0048] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device that powers the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0049] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information on the air interface 116 from base stations (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0050] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors. These sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, attitude sensors, biosensors, and / or humidity sensors.

[0051] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and / or substantially eliminate self-interference via hardware (e.g., a choke) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0052] Figure 1C This diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0053] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c on air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

[0054] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other on the X2 interface.

[0055] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. While each of the foregoing elements is described as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0056] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0057] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0058] SGW 164 can connect to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks such as Internet 110, so as to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0059] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108, facilitating communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0060] Despite WTRU in Figure 1A-1D While described as a wireless terminal, it is conceivable that, in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

[0061] In a representative embodiment, another network 112 may be a WLAN.

[0062] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can access or interface with a distributed system (DS) or another type of wired / wireless network that transmits traffic to and / or out of the BSS. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined for an external BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be transmitted via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be transmitted between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to here as an "ad-hoc" communication mode.

[0063] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a wide bandwidth of 20 MHz) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, each STA, including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0064] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0065] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0066] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV whitespace (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support metering-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0067] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA among all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy, even if most of the band remains idle and available.

[0068] In the United States, the available frequency band for 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is 6 MHz to 26 MHz, depending on the country code.

[0069] Figure 1D The diagram illustrates a system diagram of RAN 104 / 113 and CN 106 / 115 according to one embodiment. As described above, RAN 104 / 113 can communicate with WTRU 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 104 / 113 can also communicate with CN 106 / 115.

[0070] RAN 104 / 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 104 / 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c on air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0071] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a variable number of OFDM symbols and / or a continuously variable absolute time).

[0072] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0073] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing user plane data to User Plane Functions (UPF) 184a and 184b, and routing control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other on the Xn interface.

[0074] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0075] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types used by WTRU 102a, 102b, and 102c. For example, different network slices can be created for different use cases, such as services relying on Ultra Reliable Low Latency Time (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, and so on. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies such as WiFi.

[0076] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure the routing of services through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, etc. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0077] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. This N3 interface provides WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and so on.

[0078] CN 115 can facilitate communication with other networks. For example, CN 115 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and PSTN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c may be connected to local DNs 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0079] Given Figure 1A-1D as well as Figure 1A-1D The functions described herein, including one or more of the following, can be performed by one or more emulation devices (not shown): WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF183a-b, DN 185a-b, and / or one or more other devices described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0080] Simulation devices can be designed to perform tests on one or more other devices in laboratory and / or carrier network environments. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device and / or use over-the-air wireless communication to perform tests for testing purposes.

[0081] One or more simulation devices may perform one or more functions, including all functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices may be used to test test scenarios in laboratory and / or non-deployment (e.g., testing) wired and / or wireless communication networks to implement the testing of one or more components. One or more simulation devices may be test devices. Simulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0082] This document describes an embodiment of a discovery process initiated by an Application Function (AF) / Network Function (NF). A WTRU can register its sensing capabilities with the 5G Core (5GC). A RAN node can register its sensing capabilities with the 5GC. Sensing can be triggered at the NF / AF and / or Application Server (AS), and can request available sensing entities from the sensing NF, and / or request sensing / discovery services from the sensing NF. This can include one or more attributes of sensing area, sensing mode, and / or sensing target. The sensing NF can obtain information about available sensing WTRUs and / or RAN nodes from an NF (e.g., Access Control and Mobility Management Function (AMF)), including the operating modes they support (e.g., dual-site, single-site) for each entity. The sensing NF can select one or more (e.g., associated) WTRUs and / or RAN sensing entities. The sensing NF can obtain sensing information from one or more (e.g., associated) RAN nodes and / or WTRUs. For example, the sensing NF can obtain sensing information from one or more RAN nodes and / or WTRUs in a sensing request message, and the entity can then accept / reject the sensing request message. The sensing NF can select (e.g., appropriate) entities and / or can send them to the initiating NF / AF / AS in a sensing service / discovery response message. The sensing server can update (multiple) local databases and / or can send information about one or more available sensing entities in the message. The NF and / or AF can configure the selected WTRU and / or one or more RAN nodes for the sensing task. The WTRU and / or one or more RAN nodes involved in the task can calibrate and / or update one or more configurations used for sensing (e.g., via direct communication). The WTRU and / or RAN entity can perform the sensing task.

[0083] This document describes an embodiment for discovery initiated by WTRU and / or RAN. WTRU and / or RAN nodes can register (e.g., via WTRU registration, via N2 registration) their respective sensing capabilities. Sensing can be triggered at WTRU and / or RAN nodes (e.g., when sensing data is consumed at the RAN), and / or a sensing service and / or available sensing entities can be requested from the sensing NF. This request may include discovery criteria / sensing requirements (e.g., location, preferred distance to the sensing target, sensing area, sensing mode, etc.). As described herein, the sensing NF can authorize the received request for sensing (e.g., using Unified Data Management (UDM)). The sensing NF can obtain information about available sensing entities from the NF, including the operating mode of each entity. The sensing NF can send sensing requests to WTRU and / or RAN entities to obtain their availability for sensing tasks. This message can be a sensing request, which the entity can (e.g., then) accept / reject. The sensing NF can select (e.g., suitable) entities and / or can respond to the WTRU and / or RAN. The sensing response may include one or more configurations (e.g., desired configurations) for connecting to the sensing entity. In the example, as described herein, if one or more (e.g., multiple) sensing candidates are received, the WTRU and / or (multiple) RAN entities can select (e.g., appropriate) sensing entities. The WTRU and / or RAN node entities can send a configuration update message to the sensing NF with the selected sensing entities and / or their configurations. In the example, the sensing NF can select (e.g., appropriate) sensing entities. The WTRU and / or RAN nodes can update their sensing configurations (e.g., establishing sender and / or receiver role configurations in dual-site sensing). The WTRU and RAN nodes can exchange sensing data.

[0084] This document describes an embodiment regarding sensor activation and / or operation management. WTRU and / or RAN sensing entities can register their capabilities (e.g., to the 5GC). This can be done through a WTRU registration process and / or an N2 RAN node registration process. One or more sensor nodes can be configured to sense and / or can initiate sensing tasks. Changes in context can be detected (e.g., via WTRU and / or RAN nodes). This could be changes in the environment and / or network. For example, the distance to a target object may change due to user mobility and / or object mobility. WTRU (e.g., via N1) and / or RAN (e.g., via N2) nodes can report one or more context changes to the 5GC (e.g., the sensing NF). This could include, for example, the distance to the target WTRU, network conditions, and / or WTRU mobility status. The sensing NF can obtain information about available RAN and / or WTRU sensing entities. For example, the sensing NF can obtain information about available RAN and / or WTRU sensing entities by communicating with the AMF. The sensing NF can discover one or more other (e.g., new) RAN and / or WTRU sensing entities (e.g., using Solution 1). In the example, after determining that one or more other (e.g., new) sensing entities (e.g., extended coverage) are to be activated, the sensing entities may discover one or more other (e.g., new) RAN and / or WTRU sensing entities. The sensing NF can determine a sensor activation / deactivation strategy, deciding which sensors to activate and deactivate. If the sensing NF determines to deactivate one or more sensing entities, the sensing NF can send a deactivation message to one or more sensing entities. For example, a first WTRU and / or a first RAN node can receive a deactivation message from a 5GC (e.g., the sensing NF). This message may specify a timer for deactivating the sensor and / or another timer for keeping the sensor deactivated. The first WTRU and / or the first RAN node can deactivate the sensor. If the sensing NF determines that one or more sensing entities are to be activated, the sensing NF can send an activation message to one or more sensing entities. For example, a third WTRU and / or a third RAN node can receive an activation message from a 5GC (e.g., the sensing NF). This message may specify a timer for activating the sensor and / or another timer for keeping the sensor activated. The third WTRU and / or the third RAN node can activate the sensor. Additionally or alternatively, one or more sensing entities may receive a message from the 5GC instructing the sensor to remain activated. For example, the third WTRU and / or the third RAN can receive a message from the 5GC (e.g., the sensing NF) indicating that the sensor continues to be activated.

[0085] Figure 2Reference Model 200 depicts a potential architecture for 5G and / or next-generation networks. RAN can refer to a radio access network based on 5G RAT and / or evolved E-UTRA connected to the next-generation core network. Access Control and Mobility Management Functions (AMF) may include one or more of the following functions: registration management, connection management, reachability management, mobility management, etc. Session Management Functions (SMF) may include one or more of the following functions: session management (including session establishment, modification, and / or release), WTRU IP address allocation, selection, and / or UP function control, etc. User Plane Functions (UPF) may include one or more of the following functions: packet routing and forwarding, packet inspection, service usage reporting, etc.

[0086] Sensors can generate data as a result of sensing physical phenomena (e.g., light, heat, motion, velocity). Sensors can be designed to sense one or more (e.g., various) properties of an environment / target object. For example, a photoelectric sensor can detect changes in one or more objects and / or surface conditions. Passive and / or active sensors can be present. For example, an active motion sensor emits a signal (e.g., such as a laser) and / or can detect one or more changes in reflected signals. For example, a passive infrared sensor (PIR) can detect infrared radiation emitted and / or reflected by one or more objects. Sensors can vary, for example, depending on the electromagnetic waves used for sensing. In contrast to the examples of IR sensing, as described herein, radio frequency (RF) sensors can utilize radio waves to detect physical phenomena by detecting their frequency response. This sensing capability can be built into existing RF devices, such as mobile devices and / or cellular base stations.

[0087] Integrated sensing can include one or more use cases and / or potential requirements for enhancements to (multiple) (e.g., 5G) systems to provide sensing services for different target verticals / applications (e.g., autonomous / assisted driving, V2X, UAV, 3D mapping, smart cities, smart homes, factories, healthcare, maritime sectors, etc.). For integrated sensing, there can be a process for collecting sensing measurement data, which is data collected for sensing purposes regarding radio / wireless signals affected by the object of interest and / or the environment (e.g., reflection, refraction, diffraction), and / or sensing results can be derived from processing the sensing measurement data. Furthermore, there can be areas defined for sensing (e.g., sensing service area locations) where the 5G system can provide sensing services of a certain quality regardless of obstruction. One or more other N3GPP entities can be considered. The sensing measurement data of one or more other N3GPP entities can be considered transparent to the 5G system (5GS), allowing data from one or more other N3GPP entities to be transmitted using standard protocols against interference defined by the 5GS.

[0088] Figure 3 and Figure 4 An example use case for integrated sensing for object detection is described. Figure 3 An example illustration depicts a pedestrian / animal intrusion detection 300 (e.g., on a highway). Figure 4 Example illustration 400 depicts intruder detection around a smart home. A base station and / or a WTRU can detect intrusions on the sensing area of ​​the base station, either independently or through cooperation between the WTRU and the base station. Sensing measurements can be transmitted to the network and / or further processed into sensing results.

[0089] Figure 5 Examples of base stations (BS) and / or WTRU sensing objects 500 are depicted. Figure 5 Another use case for integrated sensing with transparent sensing is illustrated, where sensing data can be captured and transmitted by the WTRU, enabling the 5GS to be aware of the sensing information. The user terminal can acquire sensing signals from one or more (e.g., many) 3GPP and / or non-3GPP devices. The 5GC can, for example, determine one or more (e.g., various) available sensing services by processing the processed sensing data.

[0090] For example, a base station (BS) can transmit a dedicated signal for sensing a target object (target 1, ..., or target K). WTRUs can coordinate to receive the dedicated sensing signal transmitted from the base station (BS). Each WTRU can send a message to the BS about receiving the signal via a communication signal. This message can include radio characteristics different from the original signal from the BS. After concatenating the received signals from each WTRU, the BS can identify the object based on the different received radio characteristics.

[0091] This section provides information on sensing operation types. One type of sensing operation can be monostation sensing. Monostation sensing can originate from radar-like sensing, where the sensing transmitter and sensing receiver reside in the same entity. Another type of operation can be bistation sensing, where the sensing receiver and sensing transmitter are in different entities. Multistatic sensing operation types can include one or more (e.g., multiple) sensing transmitters and / or receivers.

[0092] This section can describe one or more requirements regarding sensing. 5G systems can provide 5G wireless sensing services at target sensing service area locations using sensing transmitters and / or sensing receivers. Depending on regulations and / or operator policies, 5G networks can activate, configure, and / or deactivate 5G wireless sensing based on parameters such as location and / or network conditions (e.g., network load).

[0093] 3GPP systems may not be able to discover and / or select sensing entities within a specific target sensing service area that meet the requirements of a sensing task. The discovery and / or selection process can distinguish between sensors whose sensing transmitters and receivers are located in the same entity (e.g., monosite sensing), and / or entities whose sensing receivers and transmitters are located in one or more different entities (dualsite sensing). For example, when determining a sensing mechanism, a network (NW) entity can know the availability of the WTRU for sensing when the WTRU and / or the NW entity may be involved in sensing. How the NW knows this availability can be described here.

[0094] To coordinate sensing operations, the NW can determine a list of the WTRUs and / or NW entities involved in the sensing. How the NW can discover and / or select those entities can be addressed here.

[0095] Transmitting sensing signals may consume more energy than receiving them. Sensing entities can select the type of sensing mode based, for example, on one or more parameters, such as available power and / or distance to the sensing target. Once detected, existing processes may not be able to activate, configure, and / or deactivate sensing entities based on one or more parameters, such as location, the mobility of the target sensing object and / or the user, and / or one or more network conditions.

[0096] This paper addresses how to detect sensors while considering different sensing operation modes, distinguishing between sensors whose sensing transmitters and / or sensing receivers coexist in the same entity (e.g., monostation sensing), and / or entities whose sensing receivers and sensing transmitters reside in one or more different entities (e.g., dualstation). Once detected, how to account for one or more (e.g., various) contextual changes (e.g., in terms of the sensing target, sensor, and / or network) to allow sensing entities to be interchanged, activated, and / or deactivated while ensuring that sensing requirements are met can be addressed in this paper.

[0097] A sensing network function (sensing NF) can be another network function that provides integrated sensing. A sensing NF can refer to an integrated sensing assist NF (ISANF) and / or a sensing operation management function (SOMF). ISANF and / or SOMF can be logical entities and / or can be co-located with one or more other entities (e.g., ISANF can be co-located with a network exposure function (NEF), both ISANF and SOMF can be co-located with NEF, SOMF can be co-located with AMF, and / or SOMF can be co-located with RAN).

[0098] ISANF can monitor interactions with application functions used for sensing services. ISANF can understand service requests from application functions (AFs) and / or derive (multiple) corresponding request sensing mechanisms. Based on the sensing mechanism, for example, ISANF can forward requests to relevant NFs within the 5GC, which can serve the area of ​​interest and / or the requested entity, such as WTRU. When the application function is a third-party application, it may not be a trusted entity like the 5GS; the application function and the ISANF can communicate via NEF.

[0099] SOMF can handle the coordination of sensing operations between one or more network entities (e.g., BS and / or one or more WTRUs). For example, based on information received from AMF, SOMF can derive coordination information for sensing operations. The information received from AMF may include one or more of the following: the requested sensing area, a list of BSs and / or WTRUs, and / or a requested sensing mechanism with multiple Quality of Service (QoS) requirements. For example, SOMF can determine the roles of sensing operations, such as multiple senders of sensing signals, multiple receivers of sensing signals, entities collecting sensing measurement data, entities calculating sensing results, etc. For example, SOMF can determine the sensing period, the waveform of the sensing signal, and / or can request resource allocation from multiple BSs and / or multiple senders to transmit sensing signals during the sensing period.

[0100] A sensing task can be a process in which one or more sensors (e.g., RF, video, audio, motion) generate data about the environment (e.g., target object, user). This data can be consumed and / or stored by WTRU, 5GS, applications, and / or one or more (e.g., any) other networked entities. A 5GS system can provide means for managing sensors and / or sensing entities, processing sensing data, and transmitting sensing data and results from sensing entities to appropriate destinations / data consumers (e.g., WTRU, NF, AF, RAN).

[0101] The processes described herein may include one or more (e.g., various) sensing-related capability parameters. Sensing capabilities may include periodicity / frequency relative to data reporting frequency. Sensing capabilities may include sampling size (e.g., data sampling size). Sensing capabilities may include sensing modes (e.g., single-site sensing, dual-site sensing). Sensing capabilities may include one or more supported sensing services. Sensing capabilities may include one or more 3GPP RAN sensing capabilities (e.g., gNB). Sensing capabilities may include one or more non-3GPP sensing capabilities (e.g., LiDAR, Wi-Fi, etc.). Sensing capabilities may include sensor output data type (e.g., raw). Sensing capabilities may include the type of sensing data processing (e.g., anonymization). Sensing capabilities may include one or more data compression capabilities. Sensing capabilities may include protocol information for sensing data and / or control data (e.g., UDP for sensing data, TCP for control / metadata). Sensing capabilities may include network transport information for sensing data and / or control data (e.g., 3GPP Uu for control data and / or data plane for sensing data). Sensing capabilities may include one or more other data processing and / or analysis capabilities (e.g., object detection). Sensing capabilities can include sensing node roles (e.g., data consumer, data provider, service provider, service consumer, etc.). Sensing capabilities can include authorization information. Authorization information can include information for each sensing role. For example, each sensing role can (e.g., needs) be authorized individually. Sensing capabilities can include entity availability and / or utilization (e.g., indicating how many other sensing tasks the WTRU has performed, how many other and / or new sensing tasks the RAN node can accept, the priority the RAN node can assign to new tasks, etc.). For example, at a given time, there may be (e.g., only) one high-priority sensing task. Sensing capabilities can include time availability (e.g., specifying the duration for which a sensor can provide its (multiple) capabilities to a task). For example, a resource-scarce sensor may not provide service for a single task for an extended period. Sensing capabilities can include sensing area (e.g., specifying the location and / or area covered by the sensor).

[0102] One or more processes described herein may include one or more (e.g., various) sensing-related requirement parameters (e.g., in one or more messages). For example, such requirements(s) may be included as discovery criteria, discovery requirements, and / or sensing requirements. One or more processes described herein may include one or more (e.g., various) sensing-related requirements. Sensing requirements may be associated with data time validity (e.g., the time during which a portion of the data is valid). Sensing requirements may be associated with one or more latency requirements (e.g., the minimum latency required to transmit sensing data). Sensing requirements may be associated with one or more proximity requirements. For example, sensing one or more proximity requirements may be associated with proximity to a sensing target (e.g., a user and / or object). Sensing requirements may be associated with a location of interest (e.g., the location of the target object (if known)). Sensing requirements may be associated with sensing data communication preferences (e.g., control plane, user plane, sidelink, Uu, etc.). Sensing data communication preferences may specify how sensing data and / or control data are transmitted. For example, this may specify that control data can be transmitted via the control plane, while sensing data is sent via the data plane. Sensing requirements may be associated with periodicity / frequency (e.g., data reporting frequency). Sensing requirements can be associated with sampling size (e.g., the sample size of the data). Sensing requirements can also be associated with a time frame in which the sensing task can be performed. For example, a time frame can be specified as a precise time window of the day (e.g., 09:00–10:00), duration, start / end time, and / or one or more (e.g., any) combinations of timers. Sensing requirements may be associated with sensing speed. Sensing speed can include the speed at which the sensor captures (e.g., all the necessary) information. For example, one or more (e.g., some) sensors may be faster than one or more other sensors.

[0103] This article can describe an example of discovery initiated by AF / NF.

[0104] Figure 6A and 6B A flowchart illustrating an exemplary process for discovery 600, 650 initiated by AF / NF is depicted.

[0105] At 614, (multiple) WTRU 602s can register with the 5GS. As described herein, WTRU 602s can provide their (multiple) sensing capabilities to the 5GS. For example, sensing capability information may include one or more of the following: data reporting frequency, sample size, one or more supported sensing services, sensor output data type, sensing data processing type, one or more data compression capabilities, protocol information for sensing and control data, sensing area, sensing node role, authorization information, entity availability, entity utilization, or network transmission information for sensing and control data. The 5GS (e.g., AMF 06) may store this for future use. WTRU 692 can be authorized to perform sensing. As described herein, authorization may be for one or more (e.g., any) capability parameters. Registration can be performed in one or more ways. For example, registration can be performed through the WTRU registration process, and / or may be provided by NF (e.g., 610, 612) and / or AF 612 (e.g., via NEF). Registration can be performed through one or more other control signaling and / or periodic and / or event-based reporting.

[0106] At 616, one or more RAN nodes (e.g., 604) may register with the 5GS. As described herein, one or more RAN nodes may provide their sensing capabilities to the 5GS, and / or the 5GS (e.g., AMF) may store the sensing capabilities of each respective RAN node 604 for (e.g., future) use. For example, sensing capabilities may relate to supported sensing modes (e.g., single-site, dual-site), sensing waveforms, coverage areas, maximum distance to the sensing target, and / or maximum power used for sensing. RAN node registration and / or initialization may indicate whether sensing can be used to optimize the network. For example, it may specify that sensing data can be used to improve beamforming efficiency. RAN nodes may (e.g., subsequently) register as sensing data consumers. It may also specify which data streams, Quality of Service (QoS) streams, and / or control plane data can be consumed (e.g., when sensing results are transmitted via the control plane). The processes at 614 and / or 616 may be used to register and / or collect total available capabilities.

[0107] In 618, AMF 606 can update the local database of its RAN node capabilities.

[0108] At 620, sensing NF 608 can receive a message from AMF 606 containing information about newly registered RAN nodes and / or WTRUs. This message may include information received by AMF 606 from RAN node 604. The message may include information related to neighboring RAN nodes. For example, sensing NF 608 can use this information when selecting (e.g., suitable) sensing entities. As described herein, this may include one or more capabilities acquired by WTRU 602. For example, a network node (e.g., sensing NF 608) may receive sensing capability information associated with multiple sensing entities. The sensing capability information may include an indication of the corresponding sensing modes supported by each sensing entity. Sensing capability information can be received from Access and Mobility Management Function (AMF) 606. The sensing capability information may include one or more of sensing waveforms, coverage areas, and / or maximum power used for sensing. For example, sensing capability information may include one or more of the following: data reporting frequency, sampling size, one or more supported sensing services, sensor output data type, sensing data processing type, one or more data compression capabilities, protocol information for sensing and control data, sensing area, sensing node role, authorization information, entity availability, entity utilization, or network transmission information for sensing and control data.

[0109] At 622, a sensing task can be triggered at NF 612, AF 612, and / or application server (AS) 612. Examples of such triggering could be applications that may need to generate a real-time map of the user environment (e.g., RF environment mapping) and / or applications that may need additional information from the network. In an example, the NF may determine that sensing data is needed to optimize network resources (e.g., beam management and mobility enhancement).

[0110] At 624, NF / AF / AS 612 can send a sensing request to NF / NEF 610. For example, when AF / AS 612 is a third-party entity, AF / AS 612 can (e.g., only) communicate with (e.g., 5G) systems via NEF. The sensing request can be a sensing entity discovery message and / or a sensing service request. As described herein, a sensing request can include one or more requirement parameters specifying one or more requirements of the request. NF / NEF 610 can send a sensing request to sensing NF 608. In the example, NF / AF / AS 612 can (e.g., directly) send a sensing request to sensing NF 608.

[0111] At 626, sensing NF 608 can receive sensing requests from NF 612, AF 612, and / or AS 612. A sensing request can be a sensing entity discovery message and / or a sensing service request. As described herein, the message may include one or more requirement parameters specifying one or more requirements of the request. For example, a network node (e.g., sensing NF 608) can receive a sensing request. A sensing request may include an indication of a sensing service requirement. A sensing service requirement may include one or more of the following: data time validity, one or more latency requirements, proximity, location of interest, one or more sensing data communication preferences, data reporting frequency, sample size, time frame, sensing service, one or more quality of service (QoS) parameters, or sensing speed. A sensing request may include a desired sensing mode. A network node (e.g., sensing NF 608) may select multiple candidate sensing entities based on the desired sensing mode.

[0112] At 628, sensing NF 608 can obtain information about one or more potential (e.g., candidate) sensing entities. This information may include information about WTRU 602 and / or RAN node 604. Sensing NF 608 can communicate with AMF 606 to obtain information about WTRU 602 and / or RAN node 604. Sensing NF 608 can obtain this information from a locally stored database and / or by querying another NF and / or sensing entity. Additionally or alternatively, sensing NF 608 can receive such information from capability reports received from sensing entities.

[0113] At 630, the sensing NF 608 can select one or more (e.g., most) suitable sensing entities and / or their sensing modes that can be used to meet one or more requirements of the sensing task. For example, a network node (e.g., sensing NF 608) can select multiple candidate sensing entities from multiple sensing entities based on sensing service requirements and / or sensing capability information associated with each of the multiple sensing entities.

[0114] Sensing NF 608 may send one or more requests to selected / listed (e.g., candidate) sensing entities to request specific sensing services and / or capabilities for (e.g., sensing) tasks. For example, specific sensing services and / or capabilities may include sensing signal receiving capabilities (e.g., frequency and / or channel) from sensing transmission entities. One or more sensing entities may accept or reject the request (e.g., it may reject the request if the RAN node cannot submit resources to the task). The information in the one or more requests here may differ from the information at procedures 614 and / or 616. One or more procedures may be used to allow one or more sensing entities to accept or reject a specific task (e.g., in a sensing report) and / or reserve and / or allocate one or more resources to that specific task. In the example of reserving one or more resources, it may specify the time for which they can be reserved. Sensing NF 608 may select (e.g., suitable) sensing entities (e.g., in contrast to potentially suitable sensing entities), for example, after collecting the information here (e.g., only afterward).

[0115] At 632, sensing NF 608 can send a sensing request to one or more RAN nodes 604 selected for the task. This message may include the sensing requirements(s) selected for the sensing entity(s) as described herein. The message may include the sensing mode(s) selected(e.g., corresponding) for the sensing entity(s). The sensing mode(s) may be single-site and / or dual-site. The process may negotiate which entities(s) and / or the types of entities(s) the sensing data can be directly provided to. For example, in one or more (e.g., some) sensing scenarios, complete and / or partial sensing data(s) may (e.g., need to) be provided to the WTRU(s) for deriving sensing results.

[0116] At 634, sensing NF 608 can receive a response from (e.g., corresponding) RAN node 604. This message can indicate whether the sensing request is accepted or rejected. The message may include one or more sensing capabilities, as described herein, that can be provided to the sensing task.

[0117] At 636, sensing NF 608 can send a sensing request to one or more (e.g., candidate) WTRUs (e.g., 602) selected for the sensing task. As described herein, the message may include one or more sensing requirements selected for the sensing entity. The message may include a sensing mode selected for the sensing entity.

[0118] At 638, sensing NF 608 can receive responses from one or more (e.g., corresponding) WTRUs (e.g., 602). This message can indicate whether a sensing request is accepted or rejected. The message can include one or more sensing capabilities, as described herein, that can be provided to the sensing task. The message can be a discovery response including one or more discovered sensing entities. For example, a network node (e.g., sensing NF 608) can receive corresponding sensing information from each of a plurality of candidate sensing entities. The sensing information can indicate the time available for each of the plurality of candidate sensing entities to perform sensing and / or the corresponding sensing mode supported by each of the plurality of candidate sensing entities. The sensing response can indicate the available time for each sensing entity in a subset of the sensing entities to perform sensing. A sensing entity can accept or reject a sensing request based on the available time for the sensing entity to perform sensing.

[0119] At 640, sensing NF 608 can select one or more sensing entities for a sensing task. For example, sensing NF 608 can select one or more sensing entities based on one or more responses received for a sensing request to WTRU 602 and / or RAN node 604. If sensing NF 608 determines that the responses(s) are unsatisfactory, sensing NF 608 can perform procedures 630-638 until satisfactory. For example, when the number of responses received from WTRUs is less than the number of WTRUs used to provide sensing operations with the requested sensing quality of service or for sensing operations with a specific sensing operation mode, sensing NF 608 can perform procedures 630-638 (e.g., again). Sensing NF 608 can (e.g., only) select one or more (e.g., suitable) sensing entities after collecting this information. For example, a network node (e.g., sensing NF 608) can select a subset of candidate sensing entities from multiple candidate sensing entities based on corresponding sensing information from each of the multiple candidate sensing entities (e.g., supported sensing modes, supported quality of service for supported sensing modes, such as granularity, sensitivity, etc.).

[0120] At 642, sensing NF 608 can send a response message to the requesting NF 612, AF 612, and / or AS 612. The response message can include information about the sensing capabilities(s) provided by the network. The message can include information about the sensing entities selected for the sensing task and / or their capabilities (e.g., as described herein). For example, a network node (e.g., sensing NF 608) can send a sensing response. The sensing response can indicate a subset of candidate sensing entities.

[0121] At 644, initiating NF 612, AF 612, and / or AS 612 can update the reception information of one or more sensed entities in the local database. This message can indicate when a sensing task can be initiated. If the sensing task will be initiated by sensing NF 608 (or one or more (e.g., any) other NFs), it can indicate its status (e.g., has been requested, will be requested at time T, pending, etc.).

[0122] Once one or more entities are detected, one or more processes can be used to configure and / or initialize and / or begin the sensing task.

[0123] At 646, one or more sensing entities can be configured for a sensing task, and / or the task can be initiated. Depending on the configuration, for example, one or more of the following entities can trigger configuration and / or initiation: Sensing NF 608 can trigger the process and / or can notify the initiating NF / AF / AS of its status in a message. Initiating NF / AF / AS 612 can send a message to Sensing NF 608 indicating that (multiple) sensing entities will be configured and / or initiated.

[0124] The sensing NF 608 can send configuration and / or initiation messages to selected sensing entities(s). The configuration may include one or more parameters(s), as described herein, for the task. The sensing entities(s) may receive an indication of when to begin the sensing task. For example, this indication may be specified as a timer value. The sensing NF 608 can specify whether further configuration is required. For example, one or more sensing entities may (e.g., be required) communicate with each other to calibrate their parameters (e.g., parameters related to the dual-station receiver and / or transmitter, and / or initialize parameters related to the connectivity to be established for sharing sensing data and / or results). A network node (e.g., the sensing NF 608) can send configuration information to each sensing entity in a subset of candidate sensing entities. The configuration information may include sensing task information for each sensing entity in the subset of candidate sensing entities to perform the sensing task. The sensing task information may include a corresponding timer value for each sensing entity in the subset of candidate sensing entities to initiate the sensing task based on the corresponding timer value. The subset of candidate sensing entities may include a first sensing entity and / or a second sensing entity. The sensing task information may include an indication that the first sensing entity will communicate with the second sensing entity.

[0125] In 648, one or more configured sensing entities can communicate with each other to update their configurations. These can be RRC configurations.

[0126] At 650, the configured sensing entity can begin sensing. For example, the configured sensing entity can begin sensing based on received sensing task information (e.g., as described herein).

[0127] This article provides examples of discovery initiated by WTRU and / or RAN.

[0128] Figure 7A , 7B 7C depicts flowcharts illustrating exemplary WTRU / RAN-initiated discovery 700, 725, 775.

[0129] At 716, one or more RAN and / or WTRU sensing entities 702 can register with the 5G system. WTRU and / or RAN capabilities can be received by and / or managed by NF 712 (e.g., AMF 706). Capabilities associated with each candidate sensing entity may include an indication of the corresponding sensing mode. WTRU 702 can be configured to select one or more sensing entities based on one or more of the following: the corresponding sensing mode, one or more requirement parameters, and / or the sensing time frame associated with performing the sensing task. One or more capabilities may include one or more of the following: data reporting frequency, sample size, one or more supported sensing services, sensor output data type, sensing data processing type, one or more data compression capabilities, protocol information for sensing and control data, sensing area, sensing node role, authorization information, entity availability, entity utilization, or network transmission information for sensing and control data.

[0130] At 718, a sensing task can be triggered at WTRU 702 and / or RAN node 702. Examples of such triggering at WTRU 702 could be applications that require generating a real-time map of the user environment (e.g., RF environment mapping) and / or may (e.g., require) include additional information from the network (e.g., beam management and / or one or more mobility enhancements). Examples of such triggering at RAN node 702 could be resource monitoring in the RAN determining that sensing data is required (e.g., for optimizing network resources(s)). For example, WTRU 702 can determine that a sensing task has been triggered. WTRU 702 can determine that a sensing task has been triggered based on an application running on WTRU 702 requesting a real-time map of the environment of WTRU 702.

[0131] At 720, WTRU 702 and / or RAN node 704 can send a sensing service / discovery request to sensing NF 710 via AMF 706. This message can be a sensing entity discovery message and / or a sensing service request. The message can include one or more request parameters, as described herein, specifying the request(s). For example, this could include (e.g., required) (multiple) authorization tokens. The message can include a sensing time frame from which sensing operations can be performed. WTRU 702 can send a sensing request. The sensing request can indicate one or more request parameters, a sensing mode associated with a sensing task, and / or a sensing time frame associated with performing the sensing task. One or more request parameters can include one or more of the following: one or more authorization tokens, data time validity, one or more latency requirements, proximity, location of interest, one or more sensing data communication preferences, data reporting frequency, sample size, time frame, sensing service, one or more quality of service (QoS) parameters, or sensing speed.

[0132] At 722, the sensing NF 710 and / or AMF 706 can authorize the requesting entity. For example, the sensing NF 710 and / or AMF 706 can authorize the requesting entity to ensure that it is authorized to receive one or more sensing services. An authorization token can be verified and / or the sensing NF 710 and / or AMF 706 can communicate with UDM 714 to obtain authorization.

[0133] At 724, sensing NF 710 can request information about potential (e.g., candidate) sensing entities by communicating with NF 712 (e.g., AMF 706, NEF, and / or other NFs). This process may include one or more sensing task requirements, as described herein (e.g., the location of the target object and / or the sensing area).

[0134] At 726, sensing NF 710 can receive a sensing capability response message from NF 712. As described herein, this message may include a list of available entities (e.g., WTRU 702 and / or RAN node 702) along with their capability parameters. The information received in processes 716, 720, 724, and / or 726 can be used to register and collect available capabilities.

[0135] In 728, the sensing NF 710 can select one or more potential (e.g., candidate) sensing entities and / or their sensing modes that meet one or more requirements of the sensing task.

[0136] Sensing NF 710 can send one or more requests to a list of capability-selected / listed sensing entities, requesting specific sensing services / capabilities for a task (e.g., required). For example, sensing NF 710 can request sensing signal receiving capabilities (e.g., frequency, channel, etc.) and / or sensing signal transmitting capabilities (e.g., frequency, channel, etc.) from a sensing signal transmission entity. One or more sensing entities can accept or reject the request. For example, one or more sensing entities can reject the request using (e.g., appropriate) reason codes (e.g., unavailable, sensing service not supported due to low power). For example, it can reject the request when a RAN node (e.g., 702) cannot submit (multiple) resources for the task. Information received in processes 730 through 736 can be used to allow sensing entities to accept or reject a specific task (e.g., in a sensing response) and / or reserve and / or allocate resources for that specific task. In an example where resources are reserved, it can specify the duration for which they can be reserved. Sensing NF 710 can use the information collected here, such as in process 738, to select (e.g., suitable) sensing entities (e.g., relative to potentially suitable sensing entities). For example, when selecting a sensing WTRU, you can check the WTRU sensing capabilities, sensing mode, sensing authorization, and / or user consent from UDM 714.

[0137] At 730, the sensing NF 710 can send one or more sensing requests to one or more RAN nodes (e.g., 702) selected for the sensing task. As described herein, the message may include one or more sensing requirements selected for the sensing entity. The message may include the sensing mode selected for the sensing entity.

[0138] At 732, sensing NF 710 can receive a response from the RAN node (e.g., 702). This message can indicate whether the sensing request is accepted or rejected. The message may include one or more sensing capabilities, as described herein, that can be provided to the sensing task.

[0139] At 734, the sensing NF 710 can send one or more sensing requests to one or more WTRUs (e.g., 702) selected for the sensing task. As described herein, the message may include one or more sensing requirements selected for the sensing entity. The message may include a sensing mode selected for the sensing entity. For example, the WTRU may receive a sensing response to the sensing task. The sensing response may indicate one or more candidate sensing entities and / or one or more capabilities associated with each candidate sensing entity.

[0140] At 736, the sensing NF 710 can receive a response from the WTRU (e.g., 702). This message can indicate whether the sensing request is accepted or rejected. The message may include one or more sensing capabilities, as described herein, that can be provided to the sensing task.

[0141] In 738, for example, based on one or more responses received for a sensing request to one or more WTRUs (e.g., 702) and / or one or more RAN nodes (e.g., 702), the sensing NF 710 can select one or more sensing entities for the sensing task.

[0142] At 740, sensing NF 710 can send a response message to WTRU 702 and / or RAN node 702, the response message containing information about sensing services and / or the sensing entities(s) selected for the sensing task. As described herein, the message may include information about one or more sensing entities(s) selected for the sensing task and / or their respective capabilities(s). For example, WTRU 702 may receive an indication of at least a subset of one or more candidate sensing entities.

[0143] At 742, for example, if the list of potential sensing entities received by sensing NF 710 includes one or more (e.g., multiple) candidates to be (e.g., required) selected, WTRU 702 and / or RAN node 702 can select one or more sensing entities for the sensing task. For example, WTRU 702 can select one or more sensing entities from one or more candidate sensing entities based on the capabilities associated with each candidate sensing entity. WTRU 702 being configured to select one or more sensing entities may include WTRU 702 being configured to confirm at least a subset of the candidate sensing entities (e.g., those received at 740).

[0144] The AF can perform sensing entity selection and / or report to the sensing NF 710. In the example, procedures 738 and / or 742 can be performed. In the example, both procedures 738 and 742 can be performed.

[0145] At 744, for example, if process 742 was performed, WTRU 702 and / or RAN node 702 may update (e.g., during process 742) the selected sensing NF 710. This may include the selected sensing entity and / or its corresponding sensing mode. This may be sent as a configuration update request, and / or 5GS may send a configuration update in response, updating the configuration on the sensing entity. The configuration update may be sent to one or more (e.g., all) sensing entities. For example, WTRU 702 may send a configuration message. The configuration message may indicate the selected one or more sensing entities.

[0146] For example, once an entity is detected, one or more of the following processes can be used to configure and / or initialize and / or begin the sensing task.

[0147] At 746, one or more sensing entities can be configured for a sensing task and / or the task can be initiated by sensing NF 710. For example, if process 742 is to be performed, sensing NF 710 can wait for a message sent during process 744. Sensing NF 710 can send one or more configuration and / or initiation messages to the selected sensing entities. The configuration can include one or more parameters for the (e.g., sensing) task, as described herein. Sensing entities can receive an indication of when to start the sensing task. For example, the indication to start the sensing task can be specified as a timer value. Sensing NF 710 can specify whether further configuration can be included (e.g., required). For example, sensing entities can (e.g., required) communicate with each other (e.g., with one or more other sensing entities) to calibrate their(multiple) parameters. For example, WTRU 702 can receive sensing task configuration information. The sensing task configuration information can include information for WTRU 702 to perform the sensing task. The sensing task information can include timer values. WTRU 702 can start performing the sensing task based on the timer values. WTRU 702 can be the first sensing entity. The selected one or more sensing entities may include a first sensing entity and a second entity. The WTRU 702 can be configured to communicate with the second sensing entity, for example, based on received sensing task configuration information.

[0148] In 748, the configured sensing entities can communicate with each other to update their configurations. These can be RRC configurations. For example, configuring WTRU 702 to communicate with a second sensing entity may include configuring WTRU 702 to receive updated information from the sensing entity to update and / or calibrate at least one or more required parameters. WTRU 702 can update and / or calibrate at least one or more required parameters based on, for example, the updated information.

[0149] At 750, the sensing entity can begin sensing, for example, based on received sensing task start information.

[0150] This document describes an embodiment regarding sensor activation and / or operation management.

[0151] Figure 8A and 8B A flowchart illustrating examples of sensor activation and / or operation management 800, 850 is provided.

[0152] In 814, RAN and / or WTRU sensing entities (e.g., 802, 804, 806) can register with the 5G system.

[0153] One or more (e.g., all) sensing entities involved can receive one or more sensing configurations for the sensing tasks(s). A sensing entity can be configured to be active, for example, when the sensing entity can begin sensing. For example, in 816a, sensing NF 810 can send a sensing configuration to WTRU / RAN node #2 806. The sensing configuration can indicate that WTRU / RAN node #2 806 is active. For example, in 816b, sensing NF 810 can send a sensing configuration to WTRU / RAN node #1 804. The sensing configuration can indicate that WTRU / RAN node #1 804 is active. One or more sensing entities can be configured to be inactive, for example, when the sensing entity can remain active until it becomes active. For example, in 816c, sensing NF 810 can send a sensing configuration to WTRU / RAN node #3 802. This sensing configuration can indicate that WTRU / RAN node #3 802 is inactive. This configuration can include a sensor activation policy that specifies how to activate the sensor. Sensor activation policies can specify whether a sensor can be activated based on timer values ​​(e.g., timers), network conditions, multiple other environmental changes, and / or upon receiving an activation message. This configuration can specify one or more policies regarding sending reports about context changes to the network (e.g., a sensing NF). The policy can specify one or more parameters to monitor and / or send reports based on conditions (e.g., thresholds) that may (e.g., may be required) be met for each parameter. It can specify how these reports are sent. For example, it can specify parameters associated with the reports, such as the frequency, data, and / or control plane to be used.

[0154] At 818, the sensing task can begin. One or more (e.g., all) active sensors can begin sensing the target object.

[0155] In 820, one or more changes in the sensing context (e.g., the user's location, the target object's location, the sensor's location, the distance to the target object, interference, or (multiple) resources) can be detected at the sensor entity.

[0156] In 822a, 822b, and / or 822c, (multiple) sensing entities can send their respective transmission reports. For example, WTRU / RAN node #3 802 can send a report to sensing NF 810 in 822c. For example, WTRU / RAN node #1 804 can send a report to sensing NF 810 in 822a. For example, WTRU / RAN node #2 806 can send a report to sensing NF 810 in 822b. The report can include a corresponding detected context change by sensing NF 810. The message can specify the type and / or extent of the change (e.g., a change in distance to the target object of ~2m). This can be similar to (e.g., an existing) ProSe remote WTRU report, another (e.g., a new) sensing report, which can include (e.g., allow) one or more sensing entities to send one or more (e.g., various) reports, such as context updates and / or activation / deactivation updates for the 5GS.

[0157] At 824, the sensing NF 810 can obtain information about one or more potential (e.g., candidate) sensing entities. This information may include information about WTRUs and / or RAN nodes (e.g., 802, 804, 806). The sensing NF 810 can communicate with the AMF 808 to obtain information about WTRUs and / or RAN nodes (e.g., 802, 804, 806).

[0158] In 826, the sensing NF 810 can determine whether the currently known sensing entities(s) are satisfactory for satisfying (e.g., ensuring) one or more sensing requirements of a sensing task. If the sensing NF 810 determines that one or more other (e.g., new) sensing entities can be incorporated into the task, it can trigger a discovery process (e.g., as described herein).

[0159] At 828, the sensing NF 810 can select and / or update the sensing entities used for the sensing task. For example, the sensing NF 810 can incorporate one or more other (e.g., newly discovered) sensing entities. The sensing NF 810 can (e.g., then) determine activation and / or deactivation strategies for one or more (e.g., all) sensing entities. For example, when the target object is moving, the sensing NF 810 can determine to activate one or more sensing entities within its coverage area and / or deactivate one or more sensing entities outside its coverage area. In the example, one or more (e.g., existing) sensing modes among the previously selected / used sensing modes can be changed based on one or more other (e.g., newly discovered) sensing entities. In the example, one or more (e.g., existing) sensing nodes among the previously selected and / or used sensing nodes can be changed based on one or more other (e.g., newly discovered) sensing entities.

[0160] At 830, based on the decision made therein (e.g., in process 828), the sensing NF 810 can send a sensor deactivation message to one or more sensing entities that have been decided to be deactivated. This message may include one or more conditions for deactivation. For example, the message may specify one or more deactivation start conditions and / or one or more deactivation stop conditions that can (e.g., need to) be met when the sensor changes its state. For example, once one or more conditions are met, one or more sensing entities can enter a deactivated state because the sensor can only be deactivated for a period of time. Additionally or alternatively, it can enter a non-active ready state, in which it can wait for another (e.g., a new) activation request to be activated. For example, the deactivation start condition could be a timer value that, when it expires, allows the sensor to be deactivated for a specific duration. In the example where the same entity hosts one or more (e.g., multiple) sensors, the message may specify which sensor will be deactivated.

[0161] In 832, a sensing entity that receives a sensor deactivation message may deactivate the sensor, for example, based on one or more conditions (e.g., as described herein). The sensing entity may report back to the sensing NF 810 that it has deactivated the sensor (e.g., with relevant parameters such as timer information).

[0162] At 834, the sensing NF 810 can send a sensor activation message to one or more sensing entities that have been determined to be activated, for example, based on a determination made during process 828. This message can include one or more conditions for activation. For example, it can specify one or more activation start conditions and / or one or more activation stop conditions, which can include (for example, the requirement) for the sensor to be met when it changes its state. For example, the activation start condition could be a timer value that, upon expiration, allows the sensor to be activated for a specific duration. In the example, where the same entity hosts one or more (e.g., multiple) sensors, the message can specify which sensor will be activated.

[0163] In 836, a sensing entity that receives a sensor activation message may activate the sensor, for example, based on one or more conditions (e.g., as described herein). The sensing entity may report back to the sensing NF 810 that it has activated the sensor (e.g., with relevant parameters such as timer information).

[0164] At point 838, one or more sensing entities determined to have no change in their state can receive a message indicating that they can continue sensing using the existing configuration. This message may indicate whether there are one or more changes to the existing configuration, and if so, it may include one or more configuration changes.

[0165] When sensor activation and deactivation are involved, the activation and / or deactivation of the sensor itself may be involved. For example, a small shape factor and / or resource scarcity may, for instance, cause the sensor to be turned off and / or enter an idle mode upon receiving a deactivation message, and be turned back on upon receiving an activation message (e.g., an activation message). There may be one or more other examples where sensor behavior may differ. In the examples, activation and / or deactivation messages may (e.g., only) act on processes associated with a specific sensing task. For example, it may (e.g., only) activate and / or deactivate the transmission of one or more measurement reports belonging to that specific task, while the sensor itself may remain on and, in the example, continue to sense the environment. This can be applied to one or more examples where a single sensor is shared among one or more (e.g., multiple) sensing tasks; for example, if the base station acts as an RF sensor, the deactivation message may (e.g., only) affect the corresponding sensing task. In the examples, activation and / or deactivation messages may be sent (e.g., or) to the sensor itself and / or the logical entity to which the sensing output is passed. In the example, sensor activation and / or deactivation may require filtering in and / or out received sensing data from the sensor, and / or sensing and / or stopping sensing reports to the corresponding entity / sensing data consumer.

[0166] The processes and / or embodiments described herein can illustrate examples of how a RAN node can be used as a sensing entity. For example, if a non-3GPP access network is used, the processes and / or embodiments described herein can also be used. For example, a non-3GPP access node can communicate with a 5G system via an N3IWF (e.g., for registering its (multiple) capabilities) to communicate with an AMF (e.g., 808) and / or a sensing NF (e.g., 810).

Claims

1. A network node, comprising: The processor is configured as follows: Receive sensing capability information associated with multiple sensing entities, wherein the sensing capability information includes an indication of the corresponding sensing modes supported by each sensing entity; Receive a sensing request, wherein the sensing request includes an indication of a sensing service request; Based on the sensing service requirements and the sensing capability information associated with each of the multiple sensing entities, multiple candidate sensing entities are selected from the multiple sensing entities; Receive corresponding sensing information from each of the plurality of candidate sensing entities, wherein the sensing information indicates the time when each of the plurality of candidate sensing entities can perform sensing and the corresponding sensing mode supported by each of the plurality of candidate sensing entities; Based on the corresponding sensing information from each of the multiple candidate sensing entities, a subset of candidate sensing entities is selected from the multiple candidate sensing entities; as well as Send a sensing response, wherein the sensing response indicates a subset of candidate sensing entities.

2. The network node according to claim 1, wherein, The sensing mode is either single-station or dual-station.

3. The network node according to claim 1, wherein, The sensing response indicates the available time for each sensing entity in a subset of sensing entities to perform sensing.

4. The network node according to claim 1, wherein, The sensing request includes a desired sensing mode, and the processor is configured to select the plurality of candidate sensing entities based on the desired sensing mode.

5. The network node according to claim 1, wherein, The sensing capability information includes one or more of the following: data reporting frequency, sampling size, one or more supported sensing services, sensor output data type, sensing data processing type, one or more data compression capabilities, protocol information for sensing and control data, sensing area, sensing node role, authorization information, entity availability, entity utilization, or network transmission information for sensing and control data.

6. The network node according to claim 1, wherein, The sensing service requirements include one or more of the following: data time validity, one or more latency requirements, proximity, location of interest, one or more sensing data communication preferences, data reporting frequency, sample size, time frame, sensing service, one or more quality of service (QoS) parameters, or sensing speed.

7. The network node according to claim 1, wherein, The sensing capability information is received from the Access and Mobility Management Function (AMF), and the sensing capability information includes one or more of the following: sensing waveform, coverage area, maximum distance to the sensing target, or maximum power used for sensing.

8. The network node according to claim 1, wherein, The processor is further configured to send configuration information to each sensing entity in a subset of candidate sensing entities, wherein the configuration information includes sensing task information for each sensing entity in the subset of candidate sensing entities to perform a sensing task.

9. The network node according to claim 8, wherein, The sensing task information includes a corresponding timer value for each sensing entity in a subset of candidate sensing entities, so that the sensing task can be started based on the corresponding timer value.

10. The network node according to claim 8, wherein, The subset of candidate sensing entities includes a first sensing entity and a second sensing entity, and the sensing task information includes an indication that the first sensing entity will communicate with the second sensing entity.

11. A method performed by a network node, the method comprising: Receive sensing capability information associated with multiple sensing entities, wherein the sensing capability information includes an indication of the corresponding sensing modes supported by each sensing entity; Receive a sensing request, wherein the sensing request includes an indication of a sensing service request; Based on the sensing service requirements and the sensing capability information associated with each of the multiple sensing entities, multiple candidate sensing entities are selected from the multiple sensing entities; Receive corresponding sensing information from each of the plurality of candidate sensing entities, wherein the sensing information indicates the time when each of the plurality of candidate sensing entities can perform sensing and the corresponding sensing mode supported by each of the plurality of candidate sensing entities; Based on the corresponding sensing information from each of the multiple candidate sensing entities, a subset of candidate sensing entities is selected from the multiple candidate sensing entities; as well as Send a sensing response, wherein the sensing response indicates a subset of candidate sensing entities.

12. The method according to claim 11, wherein, The sensing mode is either single-station or dual-station.

13. The method according to claim 11, wherein, The sensing response indicates the available time for each sensing entity in a subset of sensing entities to perform sensing.

14. The method according to claim 11, wherein, The sensing request includes a desired sensing mode, and the processor is configured to select the plurality of candidate sensing entities based on the desired sensing mode.

15. The method according to claim 11, wherein, The sensing capability information includes one or more of the following: data reporting frequency, sampling size, one or more supported sensing services, sensor output data type, sensing data processing type, one or more data compression capabilities, protocol information for sensing and control data, sensing area, sensing node role, authorization information, entity availability, entity utilization, or network transmission information for sensing and control data.

16. The method according to claim 1, wherein, The sensing service requirements include one or more of the following: data time validity, one or more latency requirements, proximity, location of interest, one or more sensing data communication preferences, data reporting frequency, sample size, time frame, sensing service, one or more quality of service (QoS) parameters, or sensing speed.

17. The method according to claim 11, wherein, The sensing capability information is received from the Access and Mobility Management Function (AMF), wherein the sensing capability information includes one or more of the following: sensing waveform, coverage area, maximum distance to the sensing target, or maximum power used for sensing.

18. The method of claim 11, further comprising sending configuration information to each sensing entity in a subset of candidate sensing entities, wherein, The configuration information includes sensing task information for each sensing entity in a subset of candidate sensing entities to perform sensing tasks.

19. The method according to claim 18, wherein, The sensing task information includes a corresponding timer value for each sensing entity in a subset of candidate sensing entities, so that the sensing task can be started based on the corresponding timer value.

20. The method according to claim 18, wherein, The subset of candidate sensing entities includes a first sensing entity and a second sensing entity, and the sensing task information includes an indication that the first sensing entity will communicate with the second sensing entity.

Images