Integrated sensing frame with region-based sensing

Abstract

The first network node may include a processor and a memory. A processor and memory of a first network node may be configured to receive a service request indicating a request for a sensing service. The processor and memory of the first network node may be configured to determine a sensing mechanism based on the service request. The sensing mechanism may be associated with one or more base stations and / or one or more wireless transmit receive units (WTRUs) to be used to perform sensing operations. A processor and memory of a first network node may be configured to send a sensing mechanism request to a second network node. The sensing mechanism request may indicate a request for the second network node to configure at least one of the one or more base stations and / or the one or more WTRUs to perform a sensing operation.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 422,293, filed on November 03, 2022, the entire content of which is incorporated herein by reference. Background Art

[0003] A RAN (Radio Access Network) based on 5G RAT (Radio Access Technology) or evolved E - UTRA (Evolved Universal Terrestrial Radio Access) can be connected to a NextGen (Next Generation) core network. The Access and Mobility Management Function (AMF) can control the registration management, connection management, reachability management, and mobility management of the 5G network. The Session Management Function (SMF) can control the session management of the 5G network (including session establishment, modification, and release), WTRU IP address allocation, selection, and control of the UP function. The User Plane Function (UPF) can control packet routing & forwarding, packet inspection, and traffic usage reporting in the 5G network. Sensing is not a traditional service considered in 3GPP systems, and there is no network entity dedicated to sensing services. Summary of the Invention

[0004] A first network node can include a processor and a memory. The processor and memory of the first network node can be configured to receive a service request from an Application Function or a source Wireless Transmit / Receive Unit (WTRU). The service request can indicate a request for a sensing service at a target WTRU or a target sensing area. The service request can include a Quality of Service (QoS) requirement that indicates the sensing frequency at which sensing is to be performed.

[0005] The processor and memory of the first network node can be configured to determine a sensing mechanism in the target WTRU based on the service request. The sensing mechanism can include one or more base stations and / or one or more Wireless Transmit / Receive Units (WTRUs) to be used to perform sensing operations.

[0006] The processor and memory of the first network node can be configured to send a sensing request to a second network node. The sensing request can include the sensing mechanism to be used to perform sensing operations in the target area and can include the QoS requirement. The sensing request can include a request to the second network node to configure at least one of one or more base stations or one or more WTRUs to perform sensing operations in the target sensing area.

[0007] The processor and memory of the first network node may be configured to receive sensing results from a second network node. The sensing results may include sensing data associated with sensing operations from at least one of one or more base stations or one or more WTRUs. The processor and memory of the first network node may be configured to receive a service request from an application function. The processor and memory of the first network node may be configured to send the sensing results to an application function (AF).

[0008] The sensing operations may include target sensing, motion sensing, object tracking, or environmental sensing. The processor and memory of the first network node may be configured to receive a service request that indicates a sensing type. The sensing type may include one or more of intrusion detection, rainfall detection, or drone detection. The target sensing area may indicate the geographical area where the sensing operation is to be performed. The first network node may indicate quality of service information for the sensing service. The quality of service (QoS) information may include one or more of sensing accuracy information, latency information, sensing frequency information, or sensing resolution information.

[0009] The first network node may include an integrated sensing assistance network function (ISANF), and the second network node may include an access and mobility management function (AMF). BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1A is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented.

[0011] Figure 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the illustrated communication system in accordance with an embodiment Figure 1A is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the illustrated communication system in accordance with an embodiment

[0012] Figure 1C is a system diagram illustrating an example RAN and an example CN that may be used within the illustrated communication system in accordance with an embodiment Figure 1A is a system diagram illustrating an example RAN and an example CN that may be used within the illustrated communication system in accordance with an embodiment

[0013] Figure 1D is a system diagram illustrating an example RAN and an example CN that may be used within the illustrated communication system in accordance with an embodiment Figure 1A is a system diagram illustrating an example RAN and an example CN that may be used within the illustrated communication system in accordance with an embodiment

[0014] Figure 2 illustrates an example reference model of a 5G / next generation network architecture

[0015] Figure 3 illustrates an example of integrated sensing applied to pedestrian / animal intrusion detection

[0016] Figure 4 An example of integrated sensing applied to intruder detection in a smart home environment is illustrated.

[0017] Figure 5 It is a system diagram illustrating a base station and WTRU sensing objects.

[0018] Figure 6 An example process of an integrated sensing service with a service request from an application function is illustrated.

[0019] Figure 7 An example process of an integrated sensing service with a service request from an application function is illustrated.

[0020] Figure 8 An example process of an integrated sensing service coordinated by a sensing operation management function is illustrated.

[0021] Figure 9 An example process of an integrated sensing service coordinated by a sensing operation management function is illustrated. Detailed implementation

[0022] Figure 1A It is a 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, messaging, broadcasting, etc.) to multiple wireless users. The communication system 100 may enable 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 OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0023] As Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 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 a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automation processing chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.

[0024] The communication system 100 may also include base station 114a and / or base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a home NodeB, a home eNode B, a gNB, an NR NodeB, a site controller, an access point (AP), a wireless router, etc. Although each of the base stations 114a, 114b is depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0025] 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 114b may be configured to transmit and / or receive wireless 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 for a specific geographical area for wireless services, which may be relatively fixed or may change over time. A 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 an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0026] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 may be established using any suitable radio access technology (RAT).

[0027] More specifically, as described above, communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 104 / 113 and WTRUs 102a, 102b, 102c may implement radio technologies, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. 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).

[0028] In an embodiment, the base station 114a and the 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 LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro) to establish an air interface 116.

[0029] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies, such as NR radio access, which may use New Radio (NR) to establish an air interface 116.

[0030] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Accordingly, the air interface utilized by the WTRUs 102a, 102b, 102c may 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).

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

[0032] For example, Figure 1AThe base station 114b therein can be a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business premise, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement radio technologies, such as IEEE 802.11, to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement radio technologies, such as IEEE 802.15, to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As Figure 1A shown, the base station 114b can have a direct connection to the Internet 110. Thus, it may not be required for the base station 114b to access the Internet 110 via the CN 106 / 115.

[0033] The RAN 104 / 113 can communicate with the CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or voice over Internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The 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. The CN 106 / 115 can provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc. and / or perform advanced security functions, such as user authentication. Although Figure 1A not shown, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 can communicate directly or indirectly with other RANs, which employ the same RAT or a different RAT as the RAN 104 / 113. For example, in addition to being connected to the RAN 104 / 113 that can utilize NR radio technology, the CN 106 / 115 can also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0034] CN 106 / 115 can also act as a gateway for WTRU 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN that is connected to one or more RANs, and the one or more RANs may employ the same RAT or a different RAT as the RAN 104 / 113.

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

[0036] Figure 1B is a system diagram illustrating an example WTRU 102. As Figure 1B shown, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It will be appreciated that the WTRU 102 may include any sub-combination of the above elements while remaining consistent with the embodiments.

[0037] The processor 118 can be a general-purpose processor, a dedicated 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. The processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120, which can be coupled to a transmit / receive element 122. Although Figure 1B the processor 118 and the transceiver 120 are depicted as separate components, it will be appreciated that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0038] The transmit / receive element 122 can be configured to transmit signals to a base station (e.g., base station 114a) or receive signals therefrom via an air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In an embodiment, for example, the transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF signals and optical signals. It will be appreciated that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

[0040] The transceiver 120 can be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 can have multi-mode capabilities. Thus, for example, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

[0041] The processor 118 of the WTRU 102 may be coupled to the speaker / microphone 124, the keyboard 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, the keyboard 126, and / or the display / touchpad 128. Additionally, the processor 118 may access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132), and store data therein. The 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. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from a memory that is not physically on the WTRU 102 (such as on a server or a home computer (not shown)), and store data in that memory.

[0042] The processor 118 may receive power from a power source 134, and may be configured to distribute power to other components in the WTRU 102 and / or control the power. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 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 cell units, fuel cell units, etc.

[0043] 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) regarding 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 from a base station (e.g., base stations 114a, 114b) via an air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with the embodiments.

[0044] The processor 118 can be further coupled to other peripheral devices 138, which can include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, the peripheral devices 138 can include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, modules, a Frequency Modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, etc. The peripheral devices 138 can include one or more sensors, which can be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geographical location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

[0046] Figure 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 can employ E-UTRA radio technology to communicate with the WTRU 102a, 102b, 102c via the air interface 116. The RAN 104 can also communicate with the CN 106.

[0047] The RAN 104 may include eNode-Bs 160a, 160b, 160c, although it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c via the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may transmit wireless signals to and / or receive wireless signals from the WTRU 102a using multiple antennas.

[0048] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. As Figure 1C shown, the eNode-Bs 160a, 160b, 160c may communicate with each other via the X2 interface.

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

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

[0051] The SGW 164 can be connected via the S1 interface to each of the eNode Bs 160a, 160b, 160c in the RAN 104. The SGW 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions such as anchoring the user plane during handovers between eNode Bs, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

[0052] The SGW 164 can be connected to the PGW 166, which can provide the WTRUs 102a, 102b, 102c with access to a packet switched network (such as the Internet 110) to facilitate communication between the WTRUs 102a, 102b, 102c and IP enabled devices.

[0053] The CN 106 can facilitate communication with other networks. For example, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to a circuit switched network (such as the PSTN 108) to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, the CN 106 can include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or can communicate with such an IP gateway, which acts as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to other networks 112, which can include other wired and / or wireless networks owned and / or operated by other service providers.

[0054] Although the WTRU is described as a wireless terminal in Figures 1A to 1D it is contemplated that in some representative embodiments, such a terminal can use (e.g., temporarily or permanently) a wired communication interface to the communication network.

[0055] In a representative embodiment, the other network 112 can be a WLAN.

[0056] A WLAN in infrastructure basic service 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 have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS and destined for an STA can reach the STA through the AP and can be delivered to the STA. Traffic originating from an STA and destined for a destination outside the BSS can be sent to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS can be sent through the AP. For example, the source STA can send the traffic to the AP, and the AP can deliver the 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 sent between the source STA and the destination STA (e.g., directly between them) using direct link setup (DLS). In some representative embodiments, DLS can use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using independent BSS (IBSS) mode can have no AP, and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode can sometimes be referred to in this document as the "ad-hoc" communication mode.

[0057] When using 802.11ac infrastructure operation mode or a similar operation 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., 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In some representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs including the AP (e.g., each STA) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. One STA (e.g., only one station) can transmit at any given time in a given BSS.

[0058] High throughput (HT) STAs can communicate using 40 MHz wide channels, for example, via a combination of the primary 20 MHz channel and an adjacent or non-adjacent 20 MHz channel to form a 40 MHz wide channel.

[0059] A very high throughput (VHT) STA can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 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, data can be passed through a segment parser that can split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time - domain processing can be done separately on each stream. The streams can be mapped to two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80 + 80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0060] Sub - 1 GHz operation modes are supported by 802.11af and 802.11ah. The channel operation bandwidths and carriers in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz bandwidth, 10 MHz bandwidth, and 20 MHz bandwidth in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz bandwidth, 2 MHz bandwidth, 4 MHz bandwidth, 8 MHz bandwidth, and 16 MHz bandwidth using non - TVWS spectrum. According to a representative embodiment, 802.11ah can support meter - type control / machine - type communication, such as MTC devices in a macro - coverage area. MTC devices can have certain capabilities, for example, limited capabilities, including supporting (e.g., only supporting) certain and / or limited bandwidths. MTC devices can include a battery with a battery life higher than a threshold (e.g., for maintaining a very long battery life).

[0061] A WLAN system that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) includes a channel that can be designated as the primary channel. The primary channel can have a bandwidth 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 restricted by the STA that supports the minimum bandwidth operation mode among all STAs operating in the BSS. In the example of 802.11ah, for an STA that supports (e.g., only supports) the 1MHz mode (e.g., an MTC-type device), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the state of the primary channel. If the primary channel is busy transmitting to the AP, e.g., due to an STA (which only supports the 1MHz operation mode), then the entire available frequency band can be considered busy, even if most of the frequency band remains idle and can be available.

[0062] In the United States, the available frequency band that 802.11ah can use is from 902MHz to 928MHz. In Korea, the available frequency band is from 917.5MHz to 923.5MHz. In Japan, the available frequency band is from 916.5MHz to 927.5MHz. Depending on the country code, the total available bandwidth for 802.11ah is 6MHz to 26MHz.

[0063] Figure 1D is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can adopt NR radio technology to communicate with WTRU102a, 102b, 102c via the air interface 116. RAN 113 can also communicate with CN 115.

[0064] The RAN 113 may include gNBs 180a, 180b, 180c, although it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with the embodiments. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c via the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and the gNB 180b (and / or gNB 180c).

[0065] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or lasting for different lengths of absolute time).

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

[0067] Each of gNBs 180a, 180b, 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support for network slicing, dual connectivity, networking between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As Figure 1D shown, gNBs 180a, 180b, 180c can communicate with each other via the Xn interface.

[0068] 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 data networks (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0069] The AMF 182a, 182b may be connected via an N2 interface to one or more of the gNBs 180a, 180b, 180c in the RAN 113 and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions according to different requirements), selecting a particular SMF 183a, 183b, managing the registration area, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize the CN support for the WTRUs 102a, 102b, 102c based on the type of service utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low-latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 162 may provide control plane functions for handovers between the 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).

[0070] The SMF 183a, 183b may be connected via an N11 interface to the AMF 182a, 182b in the CN 115. The SMF 183a, 183b may also be connected via an N4 interface to the UPF 184a, 184b in the CN 115. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 182b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0071] UPF 184a and 184b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface, which can provide access to a packet switched network (such as the Internet 110) for WTRU 102a, 102b, and 102c to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184a 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, etc.

[0072] CN 115 can facilitate communication with other networks. For example, CN 115 can include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or can communicate with the IP gateway, which serves as an interface between CN 115 and the PSTN 108. Additionally, CN 115 can provide access to other networks 112 for WTRU 102a, 102b, and 102c, and other networks 112 can include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU 102a, 102b, and 102c can be connected to local data networks (DN) 185a and 185b via the N3 interface to UPF 184a and 184b and the N6 interface between UPF 184a and 184b and DN 185a and 185b, passing through UPF 184a and 184b.

[0073] In view of Figures 1A to 1D and Figures 1A to 1D In view of the corresponding descriptions, one or more or all of the functions described herein with respect to one or more of the following may be performed by one or more emulation devices (not shown): WTRU 102a to 102d, base stations 114a to 114b, eNode-Bs 160a to 160c, MME 162, SGW 164, PGW 166, gNBs 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other device(s) described herein. An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, emulation devices can be used to test other devices and / or simulate network and / or WTRU functions.

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

[0075] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be utilized in a test scenario in a test laboratory and / or a non-deployed (e.g., test) wired and / or wireless communication network in order to perform tests on one or more components. One or more simulation devices can be test devices. Direct RF coupling and / or wireless communication via an RF circuit (e.g., which can include one or more antennas) can be used by the simulation device to transmit and / or receive data.

[0076] This document can describe an integrated sensing assisted network function (NF). The integrated sensing assisted NF (ISANF) can be responsible for understanding a service request from an application function (AF) and deriving it into a requested sensing mechanism. After determining the requested sensing mechanism, when an entity requests to execute the mechanism, the ISANF can determine whether the indicated entity has the ability to execute the requested mechanism.

[0077] When the WTRU registers, the WTRU can report its sensing capabilities, its mobility state (e.g., fixed, mobile), and / or the supported N3GPP sensing (if any). In some examples, the ISANF can refer to the sensing capabilities reported by the WTRU when deciding whether to accept or reject a sensing request from the AF and determining an appropriate sensing mechanism for the requested service level.

[0078] This document can describe a sensing operation management function (SOMF). The sensing operation management function (SOMF) can be responsible for handling interested entities (e.g., WTRU and / or base station) for the requested sensing mechanism and communicating with these interested entities to perform sensing operations. In some embodiments, the SOMF can be centralized, distributed at various locations, or collocated with other network entities (such as the AMF or base station). After collecting sensing measurement data from the WTRU and / or base station, the SOMF can perform a sensing result determination and report the result to the ISANF.

[0079] The WTRU may perform a sensing operation based on an instruction from the SOMF. The radio resources and signals used by the WTRU to perform the sensing operation on the base station and / or other WTRUs may be indicated by the SOMF and / or the base station.

[0080] Figure 2 A reference model illustrating a potential architecture of a 5G or next-generation network 200 is shown. The RAN 202 may be a radio access network based on 5G RAT (radio access technology) or an evolved E-UTRA (evolved universal terrestrial radio access) connected to the next-generation core network. The access and mobility management function (AMF) 204 may include the following functions: registration management, connection management, reachability management, mobility management, etc. The session management function (SMF) 206 may include the following functions: session management (e.g., session establishment, modification, and release), WTRU IP address allocation, selection, and control of the UP function, etc. The user plane function (UPF) 208 may include the following functions: packet routing & forwarding, packet inspection, traffic usage reporting, etc.

[0081] The solutions described herein may be applicable to integrated sensing of an enhanced 5G system 200. The sensing service may address different target verticals / applications, e.g., autonomous / assisted driving, V2X, UAV, 3D map reconstruction, smart city, smart home, factory, healthcare, maritime management.

[0082] For integrated sensing, sensing measurement data may be collected. The sensing measurement data may be data on radio / wireless signals affected (e.g., reflected, refracted, diffracted) by an object or environment of interest for sensing purposes, and a sensing result is obtained by processing the sensing measurement data. There may be a region defined for sensing (e.g., the location of the sensing service area). The location of the sensing service area may be an area location where the 5G system can provide a sensing service of a certain quality (e.g., with or without obstacles).

[0083] For integrated sensing, N3GPP entities may be considered. The sensing measurement data in the N3GPP entities may be collected and be considered transparent to the 5GS. For example, the sensing measurement data may be transferred using a standard protocol to an interface defined by the 5GS. An example of integrated sensing may be object detection, e.g., pedestrian / animal intrusion detection on a highway or intruder detection in a smart home environment.

[0084] Sensing may not be a traditional service in 3GPP and there may not be any network entity dedicated to the (one or more) sensing services. To provide sensing services, the 5GS (5th Generation System) may be able to expose sensing services to the AF (Application Function) such that the 5GS can exchange requests and responses and provide the application function with the results. The 5GS can understand service requests from the application function and can trigger actions of entities within the 5GS.

[0085] Figure 3 An integrated sensing example of pedestrian / animal intrusion 300 is illustrated. In such an example, base stations 302a, 302b and / or the WTRU 304 may detect intrusions 306a, 306b within a sensing area (e.g., the location of the sensing service area). The sensing area may be a highway 308. The intrusions may be animals 306a and / or pedestrians 306b.

[0086] Figure 4 An integrated sensing example 400 of intruder detection in a smart home is illustrated. In such an example, base station 402 and / or the WTRU 404 may detect intrusion 406 within the sensing area of base station 408. Intrusion 406 may be detected by base station 402 or the WTRU 404 itself, and / or through cooperation between the WTRU 404 and base station 402. The sensing measurements may be transmitted to the network and further processed into sensing results.

[0087] An example of integrated sensing may be transparent sensing. Transparent sensing may be a process in which sensing data is captured and transmitted by the WTRU such that the 5GS is aware of the sensing information.

[0088] Figure 5 An example environment 500 is illustrated, which includes base station 502 and WTRUs 504a, 504b that perform sensing operations. Base station 502 and WTRUs 504a, 504b may sense objects 506a, 506b. For example, a user terminal may obtain sensing signals from many 3GPP and non-3GPP devices. The 5GC may determine various available sensing services by processing the collated sensing data.

[0089] The 5GS can understand a service request for sensing from the application function. If the 5GS understands a service request for sensing from the application function, the 5GS can trigger an operation to support sensing (e.g., a sensing operation). Based on the service scenario, different entities may be included (e.g., required). The entities may be involved in different types of sensing services. For example, in Figure 3 the highway intruder detection scenario 300, a base station (e.g., only a base station) may be involved. For Figure 4The home intrusion detection scenario 400 can involve both a wireless transmit / receive unit (WTRU) and a base station (BS). For the sensing service scenario, different actions may be required between the WTRU and the base station to collect sensing measurement data. Based on the sensing service scenario, determining the sensing result according to the collected sensing measurement data may be different.

[0090] 5GS can handle operations related to sensing (e.g., selecting entities, collecting data, deriving results). For traditional communication services, entities perform communication (e.g., door-to-door communication, client- and server-based communication). In 5GS, the service can involve the (one or more) WTRUs indicated by a service request from the AF.

[0091] From the perspective of the service, the sensing service can involve activities for detection (e.g., intruder detection, rainfall detection) and the area where the activities for detection should be performed. The request from the AF may not include actions of the (one or more) specific WTRUs. The request from the AF may include actions at a specific location (e.g., sensing service). 5GS can convert the request from the AF into actions of entities within the 3GPP system. If 5GS converts the request from the AF into actions of entities within the 3GPP system, 5GS can trigger actions of some base stations or some WTRUs.

[0092] In 5GS (5G system), interaction between the application function and 5GS can be possible according to the service-based interface. For example, if there is a trust relationship between the application function and 5GS, the application function and 5GS can interact according to the service-based interface. When the application function is not trusted by 5GS (e.g., third-party application), the interaction can be carried out via the NEF (Network Exposure Function). For the sensing service, the request from the application function to 5GS can reuse the existing mechanism.

[0093] The benefits of the proposed solution can include that 5GS can provide a scalable framework for unified sensing. 5GS can support new mechanisms by updating the conversion rules from the service request from the application function to the internal actions of 5GS in the sensing assistance function. For example, based on the proposed solution, even if new sensing requirements or new sensing methods are introduced or updated, 5GS can support new mechanisms by updating the conversion rules from the service request from the application function to the internal actions of 5GS in the sensing assistance function. The solution can also support integrated sensing involving sensing data from non-3GPP entities.

[0094] The Integrated Sensing Assistance Network Function (ISANF) can be responsible for interacting with the application function for sensing services. ISANF can understand the service requests from the application function and can derive the corresponding requested sensing mechanism. ISANF can determine the corresponding requested sensing mechanism based on the service request. ISANF can forward the request to the AMF (Access Control and Mobility Management Function). The AMF can serve the requested area or entity. ISANF can receive sensing reports from the AMF or other network entities. For example, ISANF can receive sensing reports from the Sensing Operation Management Function (SOMF). ISANF can report the results to the application function.

[0095] The application function and ISANF can communicate through the NEF (Network Exposure Function). For example, when the application function is a third-party application (which is not a trusted entity of 5GS), the application function and ISANF can communicate through the NEF (Network Exposure Function).

[0096] ISANF can determine the sensing mechanism. For example, ISANF can determine the sensing mechanism based on the service request from the application function (e.g., sensing service request). The service request (e.g., request for sensing service) can include Quality of Service (QoS) requirements. The QoS requirements can indicate the sensing frequency of the sensing service (e.g., the sensing frequency at which sensing is to be performed). In an example, the QoS requirements of the sensing service can include sensing accuracy, latency, sensing frequency, resolution, etc. For example, an intrusion detection service may require 95% sensing accuracy, 5-meter-level sensing resolution, and 100-millisecond sensing latency in an area of 5 meters vertically and 5 meters horizontally. An object tracking service (e.g., UAV tracking) may require 95% sensing accuracy, 1-meter-level sensing resolution, and 1-millisecond sensing latency in an area of 1 meter vertically and 1 meter horizontally.

[0097] In some examples, ISANF can determine whether periodic sensing reports or event-triggered sensing reports are required for each different sensing frequency. ISANF can determine the periodicity of sensing measurements and / or the periodicity of sensing reports based on different sensing frequencies.

[0098] In some examples, the ISANF may determine one or more sensing mechanisms. For example, the ISANF may determine the sensing mechanism based on the sensing scenario, sensing range, speed accuracy, and / or sensing resolution. The sensing mechanism may include only base station sensing (e.g., sensing a target or environment by exchanging signals between base stations and detecting the signals). The sensing mechanism may include sensing based on cooperation between the base station and the WTRU (e.g., sensing a target or environment by exchanging signals between the base station and the WTRU and detecting the signals). The sensing mechanism may include PC5-based sensing (e.g., sensing a target or environment by exchanging signals between base stations on the PC5 channel and detecting the signals). Static sensing (e.g., sensing performed by static / stationary 3GPP-compliant devices such as base stations, WTRUs, IoT devices, MTC devices, etc.). The sensing mechanism may include how many entities should be involved (e.g., the number of base stations and / or WTRUs).

[0099]

[0100] Table 1

[0101] The ISANF may further indicate the sensing mechanism in the sensing request to the AMF. For example, if there are multiple sensing mechanisms available, the ISANF may indicate the sensing mechanism in the sensing request to the AMF. There may be multiple sensing mechanisms available. For example, if the sensing operation involves the same entities, there may be multiple sensing mechanisms to complete a single sensing operation. In an example, if different sensing mechanisms and different sensing configurations are available for a group of base stations and the expected results of sensing will be different according to different mechanisms or configurations, the ISANF may determine the sensing mechanism and indicate the sensing mechanism in the request. For example, the mechanism or configuration may include sensing accuracy, sensing latency, sensing range, etc.

[0102] The ISANF may check whether the capabilities of the entity can perform the requested sensing mechanism. The ISANF may check whether the capabilities of the entity meet the requested QoS by querying subscription data or other registration capability data from other network functions (e.g., UDM, AMF, or other NFs). In an example, when the ISANF identifies an entity (e.g., a WTRU or a base station) to perform a request from an application function, the ISANF may check whether the capabilities of the entity can perform the requested sensing mechanism and meet the requested QoS by querying subscription data or other registration capability data from other network functions.

[0103] If the WTRU or the base station is restricted to perform sensing for a specific application, in one example, the WTRU or the base station may not be selected to perform sensing for other sensing applications. The 5GS may store a list of allowed / restricted applications for sensing using the WTRU. What is stored in the 5GS may include, for example, being stored in the UDM (Unified Data Management) as subscription data and / or being stored in other NFs (Network Functions) as capability or privacy information. A list of allowed / restricted applications for sensing using the base station may be stored in the 5GS. What is stored in the 5GS may include being stored in the network function as a base station capability parameter.

[0104] The WTRU may report sensing capabilities for sensing support. For example, when the WTRU registers with the 5GS, the WTRU may report sensing capabilities. The WTRU may include a mobility state (e.g., fixed, mobile) and support N3GPP sensing. When the ISANF checks the capabilities of an entity, the ISANF may consider the reported information regarding the sensing capabilities.

[0105] The sensing capabilities of the base station may be preconfigured, recorded, and / or maintained by some network entities (e.g., UDR, ISANF, or OAM) for sensing support. For example, if the base station supports a specific sensing type (e.g., only base station sensing; sensing based on the cooperation of both the base station and the WTRU), the sensing capabilities of the base station may be preconfigured, recorded, and / or maintained by some network entities. The sensing capabilities support of the base station may be available for reference by the ISANF.

[0106] The ISANF may determine a sensing mechanism based on the capabilities of the WTRU to support a service request from an application function. For example, to support a service request from an application function, when the ISANF refers to the reported sensing capabilities of the WTRU, the ISANF may decide on an appropriate sensing mechanism based on the capabilities of the WTRU. In an example, if the WTRU notifies the ISANF that the WTRU can support N3GPP sensing (e.g., 3D lidar, RGB camera, or smartphone camera), the ISANF may consider the N3GPP (Non-3rd Generation Partnership Project) sensing capabilities when determining the sensing mechanism.

[0107] In an example, the functions of the ISANF may be deployed in an existing NF (e.g., NEF). Separate functions may be deployed in different NFs. For example, the conversion of the sensing mechanism may be deployed in the NEF, and the derived list of the base station and / or the WTRU may be deployed in the AMF and / or the SOMF (Sensing Operation Management Function).

[0108] In some examples, the functionality of the ISANF can be deployed as an application server. The ISANF can determine the sensing mechanism and the requested sensing area, and the selection of the selected base station(s) and / or WTRU(s) can be performed by the AMF and / or SOMF. The AMF and / or SOMF can perform the selection based on various factors including, for example, the requested sensing area, the requested sensing mechanism, and the capabilities and allowed / restricted application lists of the BS and / or WTRU.

[0109] In some examples, the process of an integrated sensing service having a service request from an application function can include a 5GS integrated sensing process having a request from an application function. Figure 6 FIG. 600 illustrates a process of an integrated sensing service having a service request from an application function (AF) 602.

[0110] At 610, the AF can send a service request (e.g., for sensing) to the ISANF 604. The service request for sensing can include a specific type of sensing request (e.g., intrusion detection, rainfall detection, and / or drone detection, etc.). The service request for sensing can include area information that indicates the area for the sensing to be performed. In an example, the service request for sensing from the AF 602 can include a specific type of sensing and area information (e.g., a geographical area) where the sensing should be performed.

[0111] The service request for sensing can request a sensing service at a target WTRU or at the area where the target WTRU is located. The service request for sensing can include WTRU information. The WTRU information can indicate a list of WTRU(s) to perform the sensing operation(s) (e.g., collect sensing measurement data).

[0112] The service request can include specific QoS requirements for the sensing service. The QoS requirements can indicate the sensing frequency for the sensing service (e.g., the sensing frequency at which the sensing should be performed). In an example, the QoS requirements for the sensing service can include sensing accuracy, latency, sensing frequency, resolution, etc.

[0113] At 612, the ISANF 604 can convert the service request 610 into the requested sensing mechanism to be performed in the 5GS. For example, the requested sensing mechanism can include sensing based only on the BS, sensing based on the cooperation of the BS and WTRU, sensing based only on the WTRU, etc.

[0114] In some examples, the ISANF 604 may refer to a Policy Control Function (PCF) to check the SLA (Service Level Agreement) of the service requested from the AF 602. The ISANF 604 may determine whether the requested sensing service is supported. The ISANF may determine which (if any) QoS requirements of the requested sensing service should be supported.

[0115] The ISANF 604 may derive an additional candidate list of BSs and WTRUs for performing the sensing mechanism. For example, in addition to the specified WTRU in the service request, the ISANF 604 may also derive an additional candidate list of BSs and / or WTRUs that perform the sensing mechanism based on the requested area. The ISANF 604 may decide on the sensing mechanism and the list of (one or more) BSs and / or (one or more) WTRUs for performing the sensing mechanism. For example, the ISANF 604 may decide on the sensing mechanism and the list of (one or more) BSs and / or (one or more) WTRUs for performing the sensing mechanism based on the capabilities of each BS and WTRU. If the ISANF 604 determines the list of (one or more) BSs and / or (one or more) WTRUs for performing the sensing mechanism, the ISANF 604 may include the WTRU specified in the service request. In one example, if there are any WTRUs that support the N3GPP sensing method, the N3GPP sensing capability may select an appropriate sensing mechanism that can utilize the N3GPP sensing data.

[0116] At 614, the ISANF may send a Nisanf_sensing request message to the AMF 606. The AMF 606 may serve the requested area. The AMF 606 may be connected to and / or control the BSs and / or (one or more) WTRUs in the list of BSs and / or WTRUs for performing the sensing. The sensing request may include the application ID of the application requesting the sensing service, the requested sensing area information, the list of (one or more) BSs and / or (one or more) WTRUs, and the requested sensing mechanism with QoS requirements.

[0117] The AMF 606 may receive the Nisanf_sensing request from the ISANF 604. At 616, the AMF 606 may send the sensing request message to one or more individual entities 608 (such as (one or more) base stations and / or WTRUs) via corresponding connections (such as the N1 connection for the WTRU, the N2 connection for the gNB (next-generation Node B)). The sensing request message may include the requested sensing mechanism with QoS requirements and the list of BSs and / or WTRUs involved.

[0118] The sensing request message for the WTRU and the sensing request message for the BS may include different information. For example, the sensing request message for the WTRU may include, for example, the sensing area indicating the WTRU sensing, the information of the BS that the WTRU listens to, etc. The sensing request message for the BS may include configuration information (e.g., frame structure, resource allocation information, etc.). The sensing request message for the BS may include a list of information of the base stations for coordinated transmission of sensing signals.

[0119] The operation coordination between the BS and the WTRU may be performed in a distributed manner via negotiation between the involved BS and WTRU. The operation coordination between the BS and the WTRU may be performed in a centralized manner via BS coordination. For example, the operation coordination between the BS and the WTRU may include decisions on roles such as sender / receiver, decisions on sensing periods, resource scheduling for receiving sensing signals, waveforms of sensing signals, etc. In the example, the AMF 606 may perform coordination through the corresponding connection and include coordination instructions in the sensing requests for individual entities 608 (e.g., base stations and / or WTRUs).

[0120] At 618, the BS and / or the WTRU 608 may collect sensing measurement data. For example, the BS and / or the WTRU 608 may collect sensing measurement data based on requests from the AMF 606 and coordination for sensing operations.

[0121] At 620, the BS and / or the WTRU 608 may calculate the sensing result. When calculating the sensing result, the collected sensing measurement data may be sent to the entity that will calculate the sensing result. For example, at 622, the calculated sensing result may be sent to the AMF 606 via a sensing response. At 624, after receiving the sensing response at 622, the AMF 606 reports the sensing result to the ISANF 604 via Nisanf_sensing response. At 626, the ISANF 604 may report the sensing result to the AF via a service response.

[0122] In some examples, the calculation of the sensing result can be performed by other entities (e.g., AMF 606, ISANF 604, or SOMF). The calculation of the sensing result can be performed after receiving the collected sensing measurement data (e.g., by an entity other than the WTRU and / or BS 608). For example, if the ISANF calculates the sensing result, the ISANF 604 can report the calculated sensing result to the AF 602 based on the collected sensing measurement data. For example, if at 622 and 624, the BS and / or the WTRU 608 send the collected sensing measurement data to the AMF 606, the ISANF 604 can report the calculated sensing result to the AF 602 based on the collected sensing measurement data. If the AMF 606 sends the collected sensing measurement data to the ISANF via the Nisanf_sensing response, the ISANF 606 sends the calculated sensing result to the AF 602 based on the collected sensing measurement data. In the example, the calculation of the sensing result is done at the ISANF 604. The data collected by the BS and the WTRU can be sent directly to the ISANF 604 using signaling messages (e.g., NAS signaling messages or the data path for sensing data exchange via the relevant PDU session).

[0123] In an example, the process of an integrated sensing service with a service request from an application function can include a 5GS integrated sensing process from an application function with the ISANF as the application function. Figure 7 Process 700 of an integrated sensing service with a service request from an application function (AF) 702 is illustrated.

[0124] At 712, the AF 702 can send a service request for sensing to the ISANF 704. The ISANF 704 can be implemented as an application function outside of 5GS. In an example, the ISANF 704 can be triggered via a service request for sensing (e.g., by an application, a server, other entities, etc.). At 714, the ISANF 704 can determine the required sensing mechanism. In an example, the ISANF 704 can determine the sensing mechanism based on the service request for sensing (e.g., from the AF 702).

[0125] If the ISANF 704 is outside the 5GS, at 716, the ISANF 704 may send a service request for sensing to the NEF 706. The ISANF 704 may be directly connected to an NF (e.g., AMF, PCF, UDM, etc.) for making the service request. For example, if the ISANF 704 is an application function within the 5GS, the ISANF 704 may be directly connected to other NFs for making the service request. The service request from the ISANF 704 may include the application ID of the application requesting the sensing service, the requested sensing area information, the BS and WTRU lists, and the requested sensing mechanism with QoS requirements. The QoS requirements may indicate the sensing frequency for the sensing service (i.e., the sensing frequency at which the sensing is to be performed). In an example, the QoS requirements for the sensing service may include sensing accuracy, latency, sensing frequency, resolution, etc. The service request from the ISANF 704 may include WTRU information. The WTRU information may indicate that the WTRU performs (one or more) sensing operations (e.g., collects sensing measurement data).

[0126] The NEF 706 may receive the service request for sensing from the ISANF 704. The NEF 706 may derive an additional candidate list of BSs and / or WTRUs for performing the sensing mechanism. For example, the NEF 706 may derive an additional candidate list of BSs and / or WTRUs for performing the sensing mechanism based on the requested sensing area. If a WTRU is specified in the service request from the ISANF 704, that WTRU may be included in the list of BSs and / or WTRUs. If there are WTRUs that support the N3GPP sensing method, the N3GPP sensing capabilities may be considered.

[0127] The NEF may refer to the PCF to check the SLA for the service requested from the AF. The NEF may determine whether the requested sensing service should be supported. The NEF may determine which QoS requirements on the requested sensing service should be supported.

[0128] The NEF 706 may respond to the service request from the ISANF 704 in case of service rejection. For example, if the requested sensing mechanism cannot be supported by the requested QoS requirements, the NEF 706 may respond to the service request from the ISANF 704 in case of service rejection. For example, if the request does not conform to the SLA, or there is not enough availability in the requested sensing area to support the BSs and / or WTRUs, the NEF 706 may determine that the requested sensing mechanism cannot be supported by the requested QoS requirements. If the requested sensing mechanism cannot be supported, the NEF 706 may include the reason for the rejection (e.g., does not conform to the SLA, unsupported service area, no available entities, etc.).

[0129] At 718, the NEF 706 may send an Nnef_SensingRequest message to the AMF 708. The AMF 708 may serve the requested area. The AMF 708 may be connected to and / or control the BSs and / or (one or more) WTRUs in the list of BSs and / or WTRUs used to perform sensing. The sensing request may include an application ID of the application requesting the sensing service, the requested sensing area information, the list of BSs and WTRUs, and the requested sensing mechanism with QoS requirements.

[0130] The AMF 708 may receive an Nnef_SensingRequest from the NEF 706. At 720, the AMF 708 may send the sensing request message to one or more individual entities 710 (e.g., base stations and / or WTRUs) via the corresponding connections (e.g., N1 connection for the WTRU, N2 connection for the gNB). The sensing request message may include the requested sensing mechanism with QoS requirements and / or the list of BSs and / or WTRUs involved.

[0131] The operation coordination between the BSs and / or WTRUs may be performed in a distributed manner by negotiation between the involved BSs and / or WTRUs. The operation coordination between the BS and the WTRU may be performed in a centralized manner via base station coordination. For example, the operation coordination between the BSs and / or WTRUs may include decisions on roles such as sender / receiver, decisions on sensing periods, resource scheduling for receiving sensing signals, waveforms of sensing signals, etc. In an example, the AMF 708 may perform the coordination. The AMF 708 may include coordination instructions in the sensing requests to individual entities (e.g., base stations and / or WTRUs) via the corresponding connections. The sensing request message for the WTRU 710 and the sensing request message for the BS 710 may include different information. For example, the sensing request message for the WTRU may include the sensing area where the WTRU 710 is instructed to sense, information on the BSs listened to by the WTRU, etc. The sensing request message for the BS 710 may include configuration information (e.g., frame structure, resource allocation information, etc.). The sensing request message for the BS 710 may include a list of base station information for coordinated transmission of sensing signals.

[0132] At 722, the BS and / or the WTRU 710 may collect sensed measurement data. For example, the BS and / or the WTRU 710 may collect sensed measurement data based on a request 720 from the AMF 708 and coordination of the sensing operation. At 724, the BS and / or the WTRU 710 may calculate a sensing result based on the collected sensed measurement data. Alternatively or additionally, the collected sensed measurement data may be sent to an entity to calculate the sensing result. At 726, the BS and / or the WTRU 710 may send the calculated sensing result to the AMF 708.

[0133] The AMF 708 may receive the sensing result. At 728, the AMF 708 may send the sensing result to the NEF 706 (e.g., via Nnef_Sensing Response). The AMF 708 may report the sensing result to the NEF 706 after receiving the sensing result. At 730, the NEF 706 may send the sensing result to the ISANF 704 (e.g., via a service response). The ISANF 704 may receive the service response. The service response may include the sensing result. At 732, the ISANF 704 may send the sensing result to the AF 702 (e.g., via a service response).

[0134] In some examples, the calculation of the sensing result may be performed by other entities (e.g., the AMF, the ISANF, or the SOMF). The calculation of the sensing result may be performed after receiving the collected sensed measurement data (e.g., by an entity other than the WTRU and / or the BS 710). For example, if the NEF 706 calculates the sensing result, the NEF 706 may report the calculated sensing result to the ISANF 704. The BS and / or the WTRU 710 may send the collected sensed measurement data to the AMF 708. The NEF 706 may report the calculated sensing result to the ISANF 704 based on the collected sensed measurement data. The AMF 708 may send the collected sensed measurement data to the NEF 706 via Nnef_Sensing Response. The NEF may report the calculated sensing result to the ISANF 704 based on the collected sensed measurement data.

[0135] In some examples, the ISANF 704 may calculate the sensing result. The data collected by the BS and / or the WTRU 710 may be sent to the ISANF 704 using signaling messages (e.g., via NAS signaling messages, the NEF's exposed functions, the data path for sensing data exchange using the relevant PDU session, etc.).

[0136] To coordinate the sensing operations between the BS and the WTRU, there may be a sensing operation management function (SOMF). The SOMF may determine the coordination information for the (one or more) sensing operations. For example, the SOMF may derive the coordination information for the sensing operations based on the information received from the AMF. The information received from the AMF may include the requested sensing area, a list of BSs and / or WTRUs, and / or the requested sensing mechanism and QoS requirements.

[0137] The SOMF may determine the role(s) of the (one or more) sensing operations: the (one or more) sender(s) of the (one or more) sensing signals, the (one or more) receiver(s) of the (one or more) sensing signals, the entity for collecting sensing measurement data, the entity for calculating the sensing result. The SOMF may determine the sensing period and the waveform of the sensing signal. The SOMF may ask the (one or more) BSs or the (one or more) senders for resource allocation to transmit the sensing signal during the sensing period.

[0138] In some examples, the SOMF may calculate the sensing result after receiving the collected sensing measurement data from the BS and the WTRU. With or without the help of another analysis function, the SOMF may provide further analysis of the sensing result. In an example, the response from the SOMF to the AMF may include the analysis result. The response of the SOMF to the AMF may be reported to the AF via the ISANF.

[0139] The SOMF may refer to the capabilities of the WTRU and / or the BS to coordinate the sensing operations. Based on the requested sensing area, the SOMF and / or the AMF may derive a list of BSs and / or WTRUs for performing the sensing mechanism. For example, the AMF or the SOMF may derive a list of BSs and WTRUs according to the requested sensing area and the sensing capabilities of the referenced BSs and WTRUs. The ISANF and / or the AMF may not include a list of BSs and / or WTRUs for the sensing mechanism.

[0140] When there are several available sensing mechanisms for the list of BSs and / or WTRUs, the detailed sensing mechanism may be indicated by the ISANF. The detailed sensing mechanism that may be indicated by the ISANF may be included in the sensing request from the ISANF. In an example, the detailed sensing mechanism may be determined by the SOMF. In one example, the detailed sensing mechanism may be indicated according to the channel conditions, resource availability, the status of the BS and / or WTRU (e.g., computational load, resource load, power, battery status, etc.).

[0141] The SOMF can be centralized, distributed at various locations, or collocated with other network entities such as the AMF or the base station. When the SOMF and the AMF are collocated, the signaling between the AMF and the SOMF can be replaced by the internal logic and signaling of the AMF. When the SOMF and the base station are collocated, for different sensing operation scenarios, one of the base stations can be determined as the coordination function.

[0142] In an example, the process of an integrated sensing service with a service request from an application function can include an integrated sensing process of the 5GS coordinated by the SOMF. Figure 8 FIG. illustrates a process 800 of an integrated sensing service coordinated by the SOMF 808. At 812, the AF 802 can send a service request for sensing to the ISANF 804. The ISANF 804 can receive the service request for sensing.

[0143] The service request for sensing can include a specific type of sensing request (e.g., intrusion detection, rainfall detection, drone detection, etc.) and / or area information. The area information can include an indication of the area in which sensing is to be performed. The service request can include WTRU information. The WTRU information can indicate the target WTRU for which (one or more) sensing operations (e.g., collecting sensing measurement data) are to be performed. The service request for sensing can include specific QoS requirements for the sensing service (e.g., sensing accuracy, latency, sensing frequency, resolution, etc.). The QoS requirements can indicate the sensing frequency for the sensing service (e.g., the sensing frequency at which sensing is to be performed).

[0144] At 814, the ISANF 804 can convert the service request into the requested sensing mechanism that can be executed in the 5GS. For example, the requested sensing mechanism can include BS-only sensing, BS- and WTRU-collaboration-based sensing, WTRU-only sensing, etc.

[0145] In some examples, the ISANF 804 can communicate with the PCF to check the SLA of the service requested by the AF 802. Based on the information received from the PCF, the ISANF 804 can decide whether the requested sensing service should be supported and which (if any) of the QoS requirements of the requested sensing service should be supported. Based on the requested area, the ISANF 804 can derive a list of BSs and / or WTRUs for performing the sensing mechanism. The ISANF 804 can determine the sensing mechanism and / or the list of BSs and / or WTRUs for performing the sensing mechanism based on the capabilities of each BS and / or WTRU.

[0146] If the BS and / or WTRU support N3GPP sensing capabilities, the N3GPP sensing capabilities can be considered. The N3GPP sensing capabilities can be considered to determine an appropriate sensing mechanism that can utilize N3GPP sensing data. For example, if there are any WTRUs that support the N3GPP sensing method, the N3GPP sensing capabilities can be considered to select an appropriate sensing mechanism that supports N3GPP sensing data.

[0147] At 816, the ISANF 804 can send a Nisanf_sensing request message to the AMF 806. The AMF 806 can serve the requested area. The AMF 806 can be connected to and / or control the BS and / or (one or more) WTRUs in the list of BSs and / or WTRUs used to perform sensing. The sensing request can include an application ID, the requested sensing, the requested sensing area information, the list of BSs and / or WTRUs, and the requested sensing mechanism and (one or more) QoS requirements.

[0148] At 816, the AMF can receive a Nisanf_sensing request from the ISANF 804. At 818, the AMF 806 can send a Namf_sensing request message to the SOMF 808. The Namf_sensing request message can include the requested sensing mechanism with (one or more) QoS requirements, the list of BSs and / or WTRUs involved, the application ID, and the target area.

[0149] The SOMF 808 and / or the AMF 806 can determine the sensing mechanism and / or the list of BSs and / or WTRUs. If the AMF806 and / or the SOMF 808 decide on the sensing mechanism, the AMF 806 and / or the SOMF 808 can determine a list of candidate BSs and / or WTRUs based on the requested sensing area information. The list of BSs and / or WTRUs can be based on the requested sensing area information, the sensing mechanism, and (one or more) QoS requirements.

[0150] The AMF 806 and / or the SOMF 808 can determine the sensing mechanism and the list of target BSs and / or WTRUs based on the requested sensing mechanism with (one or more) QoS requirements, the capabilities of the entities, and the list of allowed or restricted applications for each entity in the sensing candidate list. For example, the ISANF 804 and / or the AMF 806 may not include the list of BSs and / or WTRUs and / or the sensing mechanism in the Nisanf_sensing request and / or the Namf_sensing request message.

[0151] The Namf_Sensing Request Message may include a list of BSs and / or WTRUs. The list of BSs and / or WTRUs may be different from the list of BSs and / or WTRUs in the Namf_Sensing Request Message. The AMF 806 may filter according to the status and / or condition of the WTRU and / or BS. If filtering is performed, the AMF 806 may consider factors such as resource load and / or mobility status (e.g., idle mode, connected mode, or connected but RRC inactive mode).

[0152] At 820, the SOMF 808 may develop coordination information (e.g., the SOMF 808 may determine the role of the sensing operation, such as the (one or more) sender(s) of the (one or more) sensing signals, the (one or more) receiver(s) of the (one or more) sensing signals, etc.) for controlling the sensing operations of the BSs and / or WTRUs in the control list according to the requested sensing mechanism and the (one or more) QoS requirements. The SOMF 808 may determine the sensing period. The sensing period may be based on the transmission or reception of the waveform of the sensing signal. The SOMF 808 may request resource allocation from the (one or more) BSs to transmit the sensing signal during the sensing period. In an example, the resource allocation for transmitting the sensing signal may be determined by the (one or more) BS sensing signals. The resource allocation for transmitting the sensing signal may be notified to another entity (e.g., the BSs and / or WTRUs in the list).

[0153] At 822, the SOMF 808 may send the sensing request to one or more entities 810 involved in the sensing operation. In an example, when the SOMF 808 sends the sensing request to the involved WTRU, it uses a NAS container to send the sensing request through the AMF.

[0154] The sensing request message for the WTRU 810 and the sensing request message for the BS 810 may include different information. For example, the sensing request message for the WTRU 810 may include sensing area information and BS information, etc. The sensing area information may include the target sensing area where the WTRU is instructed to perform sensing and / or collect sensing data. The BS information may provide the WTRU with the ability to listen to the BS. The sensing request message for the BS 810 may include configuration information. In an example, the configuration information may be frame structure or resource allocation information. The sensing request message for the BS 810 may include a list of BS information to coordinate the transmission of signals. At 824, the BS and / or WTRU 810 may collect sensing measurement data. For example, the BS and / or WTRU 810 may collect sensing measurement data based on the coordination information from the SOMF 808.

[0155] At 826, the BS and / or the WTRU 810 may send the collected sensed measurement data to the SOMF 808. At 828, the SOMF 808 may calculate a sensing result based on the collected sensed measurement data. At 830, the SOMF 808 may send the sensing result to the AMF 806 via Namf_Sensing Response. In some examples, an entity or other dedicated network function may calculate the sensing result based on the collected sensed measurement data (e.g., the BS, the WTRU, and / or other dedicated network functions). In an example, the BS and / or the WTRU 810 may calculate the sensing result. If the BS and / or the WTRU 810 calculates the sensing result, the collected sensed measurement data may be sent to the BS and / or the WTRU 810 that calculates the sensing result before sending the sensing response. At 826, the BS and / or the WTRU 810 may send the sensing calculation result to the SOMF 808 in the sensing response. If the BS 810 or other entity calculates the sensing result, the SOMF may not perform the calculation of the sensing result.

[0156] At 830, the AMF 806 may receive the calculated sensing result from the SOMF 808. At 832, the AMF 806 may report the calculated sensing result to the ISANF 804 via Nisanf_Sensing Response. At 834, the ISANF 804 may send the sensing result to the AF 802 via a service response.

[0157] In some examples, the calculation of the sensing result is performed by the AMF 806 or the ISANF 804, and the calculation of the sensing result may not be performed by the SOMF 808. If the calculation of the sensing result is performed by the AMF 806 or the ISANF 804, the collected sensed measurement data may be sent to the AMF 806 via Namf_Sensing Response.

[0158] In some examples, the process of an integrated sensing service with a service request from an application function may include a 5GS integrated sensing process coordinated by the SOMF and the ISANF application functions. Figure 9 The process 910 of an integrated sensing service coordinated by the SOMF 910 is illustrated.

[0159] The ISANF 904 may be implemented as an AF 902 outside the 5GS. At 914, the ISANF 904 may receive a service request for sensing from the AF 902. The ISANF 904 may also be triggered by other servers, other entities, etc. (e.g., receive a service request from other servers, other entities, etc.). At 916, the ISANF 904 may determine a sensing mechanism for the sensing service request based on the service request for sensing.

[0160] If the ISANF 904 is outside the 5GS, at 918, the ISANF 904 may send a service request for sensing to the NEF 906. If the ISANF 904 is an application function within the 5GS, the ISANF 904 may directly connect to one or more other NFs (e.g., AMF, PCF, UDM, etc.) for service requests. The request from the ISANF 904 may include the application ID of the application requesting the sensing service, a specific type of sensing mechanism with one or more QoS requirements, and / or area information indicating the area where the sensing is to be performed. The one or more QoS requirements may indicate the sensing frequency for the sensing service (e.g., the sensing frequency at which the sensing is to be performed). In an example, the QoS requirements for the sensing service may include sensing accuracy, latency, sensing frequency, resolution, etc.

[0161] At 918, the NEF 906 may receive a server request for sensing from the ISANF 904. The service request for sensing may include WTRU information. The WTRU information may indicate that the WTRU can perform sensing (e.g., collect sensing measurement data). The NEF 906 may derive a candidate list of BSs and / or WTRUs that can perform the sensing mechanism. The candidate list may be based on the requested sensing area. If a target WTRU is specified in the service request from the ISANF 904, that WTRU may be included in the candidate list of BSs and / or WTRUs. If there are any WTRUs that support the N3GPP sensing method, those N3GPP sensing capabilities may be considered.

[0162] In some examples, the NEF 906 may refer to the PCF and / or check the SLA on the service requested from the AF 902. The NEF 906 may refer to the PCF to determine whether the requested sensing service can be supported and which of the one or more QoS requirements of the requested sensing service can be supported.

[0163] The NEF 906 may respond to the service request from the ISANF 904 in case of service rejection. In an example, if the requested sensing mechanism does not support the one or more requested QoS requirements, the NEF 906 may respond to the service request from the ISANF 904 in case of service rejection. The sensing mechanism may not support the one or more requested QoS requirements due to, for example, the SLA in the requested sensing area or the (un)availability of BS and / or WTRU capabilities. If the NEF 906 responds to the service request from the ISANF 904 in case of service rejection, the NEF 906 may include the reason for the rejection (e.g., SLA, unsupported service area, unavailable available entities, etc.).

[0164] At 920, the NEF 906 may send an Nnef_SensingRequest message to the AMF 908. The AMF 908 may serve the requested sensing area. The AMF 908 may be connected to and / or control the BSs and / or WTRUs in the list of BSs and / or WTRUs used to perform the sensing. The sensing request may include an application ID of the application requesting the sensing service, sensing area information, a list of BSs and / or WTRUs, and the requested sensing mechanism with (one or more) QoS requirements.

[0165] At 920, the AMF 908 may receive an Nnef_SensingRequest from the NEF 906. At 922, the AMF 908 may send a Namf_SensingRequest message to the SOMF 910. The Namf_SensingRequest message may include the requested sensing mechanism with (one or more) QoS requirements, a list of BSs and / or WTRUs, an application ID, and / or a target area. In some examples, the SOMF 910 and / or the AMF 908 may determine additional candidate BSs and / or WTRUs to be included in the list. The additional candidate BSs and / or WTRUs may be based on the requested sensing area information, the requested sensing mechanism, and / or (one or more) QoS requirements. The additional candidate BSs and / or WTRUs may also be based on the capabilities of the entities and the list of allowed / restricted sensing applications for each entity in the candidate list. In an example, the NEF 906 and / or the AMF 908 may or may not include a list of BSs and / or WTRUs in the Nnef_SensingRequest or the Namf_SensingRequest.

[0166] The list of BSs and / or WTRUs involved in the Namf_SensingRequest may be different from the list of BSs and / or WTRUs in the Nnef_SensingRequest message. For example, the AMF 908 may filter in response to the status and / or condition of the WTRU and / or BS. In an example, the AMF 908 may filter based on resource load and / or mobility status (e.g., idle mode, connected mode, or connected but RRC inactive mode).

[0167] At 924, the SOMF 910 may develop coordination information according to the requested sensing mechanism and (one or more) QoS requirements for controlling the sensing operations of the BS and / or WTRU. The coordination information may include the roles of the sensing operations of the WTRU and / or BS (e.g., (one or more) senders of (one or more) sensing signals, (one or more) receivers of (one or more) sensing signals, etc.). The coordination information may include a sensing period related to the transmission and reception of the waveform of the sensing signal. The SOMF 910 may request resource allocation from (one or more) base stations to transmit the sensing signal during the sensing period. In an example, the resource allocation for transmitting the sensing signal may be determined by the (one or more) BS sensing signals and may be notified to other entities (e.g., BSs and / or WTRUs in a list).

[0168] At 926, the SOMF 910 may send a sensing request to one or more entities 912 involved in the sensing operation (e.g., BS and / or WTRU). When sending the sensing request to the WTRU 912, the SOMF 910 may use a NAS container to send the sensing request via the AMF 908. The sensing request message for the WTRU 912 and the sensing request message for the BS 912 may include different information. For example, the sensing request message for the WTRU 912 may include the sensing area in which the WTRU is required to perform sensing, BS information that may provide the WTRU with listening capabilities, etc. In an example, the sensing request message for the BS 912 may include configuration information (e.g., frame structure, resource allocation information, etc.) and / or BS information to coordinate the transmission of the sensing signal.

[0169] At 926, one or more WTRUs and / or (one or more) BSs 912 may receive a sensing request message from the SOMF 910. At 928, one or more BSs and / or WTRUs 912 may collect sensing measurement data based on the coordination information and the sensing request from the SOMF 910. In an example, the BS and / or WTRU perform sensing in response to the configuration and information provided by the SOMF 910. At 930, the BS and / or WTRU may send the collected sensing measurement data to the SOMF 910 in a sensing response message. At 932, the SOMF 910 may calculate a sensing result based on the collected sensing measurement data received from the (one or more) WTRUs and / or (one or more) BSs in the sensing response message. At 934, the SOMF 910 may send the sensing result to the AMF 908 via Namf_sensing response.

[0170] Other entities may calculate the sensing result (e.g., the BSs and / or WTRUs 912 in the list, other dedicated network functions). For example, if the BS calculates the sensing result, the collected sensing measurement data may be sent to the BS before sending the sensing response. The calculated result may be sent by the BS and / or WTRU 912 in the sensing response message and received by the SOMF 910. The SOMF 910 may not perform the calculation of the sensing result.

[0171] At 934, the AMF 908 may receive the sensing result. At 936, the AMF 908 may send the sensing result to the NEF 906 via Nnef_Sensing Response. At 938, the NEF 906 may send the sensing result to the ISANF904 via the service response.

[0172] In some examples, the calculation of the sensing result may be performed by the ISANF 904. The BS and / or WTRU 912 may directly send the collected sensing data to the ISANF 904 via a signaling message (e.g., a NAS signaling message, the exposed function of the NEF 906, or the data path for sensing data exchange using the relevant PDU session).

[0173] The sensed service area may be defined based on the service area of the AMF and / or based on the service area of the BS. When a sensing service is requested for some areas (e.g., a service request for sensing is received), without indicating any involved entities (e.g., the target WTRU), the ISANF may map the requested area into the sensed service area. The ISANF may determine a list of candidate BSs and / or WTRUs available for the sensing service. The ISANF may determine the sensing mechanism and the list of WTRUs and / or BSs that may be involved in the sensing operation based on the capabilities of the entities in the list, the transformed sensing mechanism, and / or the SLA.

[0174] Based on the reported capabilities of the BSs and / or WTRUs and the known locations of the BSs and / or WTRUs, a list of BSs and / or WTRUs may be derived for the sensed service area. When the BS is connected to the 5GS, the BS may report its sensing capabilities. The reported sensing capabilities may be stored together with the location of the BS and / or the sensed service area of the BS. When the WTRU registers with the 5GS, the WTRU may report the capabilities that the WTRU supports sensing, the mobility type of the WTRU (e.g., fixed, mobile, etc.), and / or the location of the WTRU (e.g., if the WTRU is a fixed device). The network entity (e.g., ISANF, SOF, or AMF, etc.) that determines the list of WTRUs and / or BSs that can support the sensing service may refer to the capabilities of the BSs and / or WTRUs whose locations and / or service areas are known.

[0175] In some examples, the AMF may inform of the location of the WTRU that supports sensing. If the mobility type of the WTRU is mobile and the WTRU is in a connected state, the WTRU may be considered in the list of area-based sensing services. The WTRU may not wish to participate in the sensing service for area-based sensing services. To avoid non-cooperative operation, the 5GS may only consider the WTRUs that reported support for area-based sensing services during registration.

[0176] The ODSC (Operator-Defined Sensing Category of the supported sensing mechanism) may be defined based on the capabilities of the WTRU and assigned to the WTRU. During registration, the WTRU may provide its sensing capabilities. The ODSC may be assigned based on the sensing capabilities provided by the WTRU via a registration response, a WTRU configuration update procedure, a WTRU policy update procedure, and / or via other NAS control plane signaling. The ODSC may be pre-configured in the USIM / NVM and, in some examples, updated via the HPLMN during registration and via the SOR in a roaming scenario. The base station may assign the ODSC through pre-configuration, OAM, or signaling from the 5GS.

[0177] When receiving a service request for sensing from an application function, the ISANF may convert the service request into an ODSC. For the requested sensing mechanism of the service request, the WTRU and / or the BS may be selected for sensing operations based on the ODSC in the requested sensing area.

[0178] In some examples, the ISANF may map a given service request to an ODSC. The ODSC value may be forwarded to the (one or more) AMFs that serve the requested sensing area. The ODSC may be provided to the WTRU via the system information block (SIB) of the base station in the service area of the AMF, provided to multiple WTRUs through multicast and broadcast services, and / or provided to the WTRU through separate NAS signaling. By providing the requested ODSC, the AMF may activate the sensing operation in a pre-configured manner. The activated ODSC may be enabled via the SIB through cell-level broadcast information. The sensing periodicity and sensing period may be sent together with the ODSC, notified in different ways, or pre-configured (e.g., for each ODSC, each AMF, etc.).

[0179] The sensing measurement data of the WTRU and / or the BS may be received by the SOMF, and the SOMF may calculate the sensing result. The sensing result may be reported to the AMF and the ISANF via the methods of other solutions. In some examples, the SOMF may be the entity for determining the SIB content, which enables the sensing operation for a given sensing service request in a specific area (e.g., a geographical area).

Claims

1. A first network node, comprising: a processor and a memory, the processor and the memory being configured to: receive a sensing service request from an Application Function (AF) or a source Wireless Transmit / Receive Unit (WTRU), the service request indicating a request for a sensing service at a target WTRU or in a target sensing area, and the service request including a Quality of Service (QoS) requirement, the QoS requirement indicating a sensing frequency at which the sensing is to be performed; determine a sensing mechanism in the target sensing area based on the service request, the sensing mechanism including one or more base stations or one or more WTRUs to be used to perform sensing operations in the target sensing area; and send a sensing request to a second network node, wherein the sensing request includes the sensing mechanism to be used to perform the sensing operations in the target sensing area, wherein the sensing request includes the QoS requirement, and wherein the sensing request includes a request to the second network node to configure at least one of the one or more base stations or one or more WTRUs to perform the sensing operations in the target sensing area.

2. The first network node according to claim 1, wherein the processor and the memory are further configured to: receive a sensing result from the second network node, the sensing result including sensing data associated with the sensing operations from the at least one of the one or more base stations or the one or more WTRUs.

3. The first network node according to claim 2, wherein the processor and the memory are further configured to: send the sensing result to the AF.

4. The first network node according to claim 1 or 2, wherein the sensing operations include target sensing, motion sensing, object tracking, or environmental sensing.

5. The first network node according to any one of claims 1 to 4, wherein the service request indicates a sensing type.

6. The first network node according to claim 5, wherein the sensing type includes one or more of intrusion detection, rainfall detection, or drone detection.

7. The first network node according to any one of claims 1 to 6, wherein the target sensing area indicates a geographical area where the sensing operations are to be performed.

8. The first network node according to any one of claims 1 to 7, wherein the service request includes WTRU information, the WTRU information indicating the target WTRU to perform the sensing operations.

9. The first network node according to any one of claims 1 to 8, wherein the QoS requirement includes sensing accuracy information, latency information, sensing frequency information, or sensing resolution information.

10. The first network node according to any one of claims 1 to 9, wherein the first network node includes an Integrated Sensing Assistance Network Function (ISANF), and the second network node includes an Access and Mobility Management Function (AMF).

11. A method performed by a first network node comprising a processor and a memory, the method comprising: Receive a service request for sensing from an application function (AF) or a source wireless transmit / receive unit (WTRU), the service request indicating a request for a sensing service at a target WTRU or in a target sensing area, and the service request including a quality of service (QoS) requirement, the QoS requirement indicating a sensing frequency at which sensing is to be performed; Determine a sensing mechanism in the target sensing area based on the service request, the sensing mechanism including one or more base stations or one or more WTRUs to be used to perform sensing operations in the target sensing area; And Send a sensing request to a second network node, wherein the sensing request includes the sensing mechanism to be used to perform the sensing operations in the target sensing area, wherein the sensing request includes the QoS requirement, and wherein the sensing request includes a request to the second network node to configure at least one of the one or more base stations or one or more WTRUs to perform the sensing operations in the target sensing area.

12. The method performed by the first network node according to claim 11, the method further Comprises: Receive a sensing result from the second network node, the sensing result including sensing data associated with the sensing operations from at least one of the one or more base stations or the one or more WTRUs.

13. The method performed by the first network node according to claim 12, wherein the processor and the memory are further configured to: Send the sensing result to the AF.

14. The method performed by the first network node according to claim 11 or 12, wherein the sensing operations include target sensing, motion sensing, object tracking or environmental sensing.

15. The method performed by the first network node according to any one of claims 11 to 14, wherein the service request indicates a sensing type.

16. The method performed by the first network node according to claim 15, wherein the sensing type includes one or more of intrusion detection, rainfall detection or drone detection.

17. The method performed by the first network node according to any one of claims 11 to 16, wherein the target sensing area indicates a geographical area where the sensing operations are to be performed.

18. The method performed by the first network node according to any one of claims 11 to 17, wherein the service request includes WTRU information, the WTRU information indicating that the target WTRU performs the sensing operation(s).

19. The method performed by the first network node according to any one of claims 11 to 18, wherein the QoS requirement includes one or more of sensing accuracy information, latency information, sensing frequency information or sensing resolution information.

20. The method performed by the first network node according to any one of claims 11 to 19, wherein the first network node includes an integrated sensing assistance network function (ISANF), and the second network node includes an access and mobility management function (AMF).

Images