Registration and discovery via network functions

Abstract

A wireless transmit / receive unit (WTRU) may, for example, send a sensing request message to a network. The sensing request message may include, for example, an indication of a sensing criterion associated with a device-to-device (D2D) sensing service. The WTRU may receive a sensing response message, for example, from the network. The sensing response message may include an indication associated with another WTRU. The WTRU may, for example, send a discovery request to the network. The discovery request may include an indication of one or more D2D sensing capabilities of the other WTRU. The WTRU may receive a Proximity Service (ProSe) code, for example, in response to the discovery request. The ProSe code may be associated with the other WTRU. The ProSe code may include an indication of the at least one D2D sensing capability of the other WTRU.

Description

Cross-references to related applications

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 578,784, filed August 25, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0002] The Radio Access Network (RAN) may be based on fifth-generation (5G) Radio Access Technology (RAT) and / or Evolved Universal Terrestrial Radio Access (UTRA) connected to a Next-Gen core network. Access Control and Mobility Management Functions (AMF) may include one or more of registration management, connection management, reachability management, and / or mobility management. Session Management Functions (SMF) may include one or more of session management (e.g., including session establishment, modification, and release), Radio Transmit / Receive Unit (WTRU) Internet Protocol (IP) address allocation, selection, and / or User Plane (UP) function control. User Plane Functions (UPF) may include one or more of packet routing and forwarding, packet inspection, and / or traffic usage reporting. Integrated sensing can be used and / or leveraged to enhance 5G systems to provide sensing services for various target vehicles / applications, such as autonomous / assisted driving, vehicle-to-everything (V2X), unmanned aerial vehicles (UAVs), 3D mapping, smart cities, smart homes, factories, healthcare, and / or maritime sectors. Summary of the Invention

[0003] A Wireless Transmit / Receive Unit (WTRU) can send registration messages, such as to a Network Function (NF). The registration message may include one or more WTRU sensing capabilities. The WTRU can receive response messages, such as those from the NF. The response message may include authorization instructions, such as authorization instructions for one or more sensing and configuration parameters. The WTRU can send a registration complete message. The WTRU can receive configuration information, such as configuration information associated with one or more sensing and configuration parameters.

[0004] One or more sensing and provisioning parameters may include one or more of the Proximity Service (ProSe) parameters and / or discovery codes. One or more sensing capabilities may include indications of one or more of the sensing type, sensing service, and / or sensing role.

[0005] A WTRU can, for example, send a sensing request message to the network. The sensing request message may include, for example, an indication of a sensing standard associated with a device-to-device (D2D) sensing service. A WTRU can, for example, receive a sensing response message from the network. The sensing response message may include an indication associated with another WTRU.

[0006] A WTRU may, for example, send a discovery request to the network. This discovery request may include an indication of one or more D2D sensing capabilities of another WTRU. A WTRU may, for example, receive a ProSe code in response to the discovery request. The ProSe code may be associated with another WTRU. The ProSe code may include an indication of at least one D2D sensing capability of the other WTRU. D2D sensing capabilities may include sensing capabilities associated with one or more of sensing types, sensing services, and / or sensing roles.

[0007] Indications of sensing standards associated with D2D sensing services may include one or more of the following: data time validity, latency requirements, proximity, location, location of interest, sensing data communication preferences, data storage destination, periodicity, frequency, and sampling size associated with the D2D sensing service.

[0008] A WTRU may, for example, determine to request D2D sensing services from one or more other WTRUs based on a trigger. This trigger may include one or more of a real-time map, an indication of congestion associated with a sensor, and / or an indication of data associated with the sensor. The sensor may be included in the WTRU.

[0009] A WTRU can receive, for example, authorization and configuration information for D2D sensing services. A sensing response message can include an indication of whether a sensing request has been accepted. The sensing response message can include indications of information associated with multiple (e.g., other) WTRUs. A WTRU can select another WTRU from multiple (e.g., other) WTRUs. Indications of information associated with multiple (e.g., other) WTRUs can include indications of sensing services for each of the multiple (e.g., other) WTRUs. A WTRU can select another WTRU from multiple (e.g., other) WTRUs based on indications of sensing services for one or more of the multiple (e.g., other) WTRUs. Multiple (e.g., other) WTRUs can be included in a list of WTRUs. For example, a WTRU can select (e.g., another) WTRU based on indications of a list of (e.g., other) WTRUs.

[0010] The base station may, for example, receive a sensing request message from a WTRU. This sensing request message may include an indication of the sensing standard associated with the D2D sensing service. The base station may, for example, send a sensing response message to a WTRU. This sensing response message may include an indication associated with another WTRU.

[0011] The base station may, for example, receive a discovery request from a WTRU. This discovery request may include an indication of at least one D2D sensing capability of the other WTRU. The base station may, for example, send a ProSe code associated with the other WTRU in response to the discovery request. Attached Figure Description

[0012] Figure 1A This is a system diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments.

[0013] Figure 1B This illustrates that, according to an embodiment, it is possible to Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown.

[0014] Figure 1C This illustrates that, according to an embodiment, it is possible to Figure 1A The diagram shows an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system.

[0015] Figure 1D This illustrates that, according to an embodiment, it is possible to Figure 1A The system diagram shown is another exemplary RAN and another exemplary CN used in the communication system.

[0016] Figure 2 This is a diagram illustrating an exemplary 5G network.

[0017] Figure 3 This is a diagram illustrating an exemplary pedestrian / animal intrusion detection method.

[0018] Figure 4 This is a diagram illustrating an exemplary intruder detection in the surrounding environment of a smart home.

[0019] Figure 5 This is a diagram illustrating an exemplary base station and WTRU with target detection.

[0020] Figure 6 An exemplary flowchart of the policy configuration and authorization process is shown.

[0021] Figure 7A and Figure 7B An exemplary flowchart is shown for the process of network-based WTRU sensing discovery.

[0022] Figure 8A and Figure 8B An exemplary flowchart is shown for a process of server-based device-to-device (D2D) sensing. Detailed Implementation

[0023] Figure 1AThis diagram illustrates an exemplary communication system 100 that may implement one or more of the disclosed embodiments. The communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through shared system resources including wireless broadband. 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 Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

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

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

[0026] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a specific geographic area that may be relatively fixed or may change over time. A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In embodiments, 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.

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

[0028] More specifically, as described above, the communication system 100 can be a multiple access system and can 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 can implement radio technologies, such as using Wideband CDMA (WCDMA) to establish Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) for air interfaces 115 / 116 / 117. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0029] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies, such as using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro) to establish Evolved UMTS Terrestrial Radio Access (E-UTRA) for air interface 116.

[0030] In the embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies, such as using New Radio (NR) to establish NR radio access for air interface 116.

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

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

[0033] Figure 1A Base station 114b can be, for example, 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 localized areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

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

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

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

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

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

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

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

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

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

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

[0044] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via 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 understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable location determination method.

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

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

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

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

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

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

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

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

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

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

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

[0056] In a representative embodiment, the other network 112 may be a WLAN.

[0057] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP can have an interface to a Distribution System (DS) or another type of wired / wireless network that loads traffic into and / or loads traffic out of the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the AP. Traffic from a STA to a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send 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 a source STA and a destination STA using a Direct Link Setup (DLS) (e.g., directly between them). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a "self-organizing" communication mode in this document.

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

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

[0060] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which can be referred to as an 80+80 configuration. In the 80+80 configuration, data, after channel coding, can be passed through a fragment parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each stream separately. The streams can be mapped onto the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

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

[0062] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include 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 limited by the STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to STAs (which only support the 1 MHz operating mode) transmitting to the AP, the entire available band may be considered busy even if most of the band remains idle and potentially available.

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

[0064] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

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

[0066] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable digital architecture. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can be varied for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes of various lengths or scalable lengths, or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or absolute times of varying durations).

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

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

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

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

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

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

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

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

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

[0076] One or more simulation devices may perform one or more (including all) functions when implemented / deployed without being part of a wired and / or wireless communication network. For example, simulation devices may be used to test scenarios in laboratory and / or undeployed (e.g., tested) wired and / or wireless communication networks to perform tests on one or more components. One or more simulation devices may be test rigs. Simulation devices may transmit and / or receive data using direct RF connections and / or wireless communication via RF circuitry systems (e.g., which may include one or more antennas).

[0077] Systems and methods are provided for integrating sensing, communication, and / or Proximity Services (ProSe). Features and / or functions may include one or more of registration, authentication and authorization, direct discovery, and / or direct integration discovery and communication. Registration and / or discovery can be performed via Network Functions (NFs). Policy configuration and authorization exist via NFs for Device-to-Device (D2D) sensing and / or WTRU discovery, for example, via NFs used for D2D sensing. WTRUs and / or parameters configured for D2D sensing can be discovered via a sensing server.

[0078] Registration and / or discovery can be provided via network functions (NFs). Policy provisioning and / or authorization can be provided, for example, via an NF for D2D sensing. The WTRU can send non-access stratum (NAS) messages, such as to the NF. NAS messages can contain, for example, a registration request to the AMF. NAS messages can contain the WTRU's D2D sensing capabilities (e.g., Uu-based and / or PC5-based sensing capabilities, which can be used together or separately).

[0079] For example, for localized D2D sensing services, the NAS message may include the location of the WTRU and / or the location of interest. Additionally or alternatively, the NAS message may include a list of requested sensing service types and / or requested sensing data types (e.g., 3GPP / Non-3GPP and any other Quality of Service (QoS) parameters). The WTRU may share one or more supported sensing service types and / or a list of supported sensing data types, for example, if it acts as a sensing data sharing WTRU. The WTRU may share one or more supported sensing service types and / or a list of supported sensing data types, for example, as part of registration (as a supplement or alternative to D2D sensing capabilities). For example, the WTRU may send one or more supported sensing service types via a NAS message (e.g., to an NF).

[0080] The WTRU can receive NAS messages, for example, from the NF. The NAS message may contain a registration response from the AMF. The registration response may indicate authorization for D2D sensing and / or configuration parameters. The indication of authorization for D2D sensing and / or configuration parameters may include one or more Proximity-Based Service (ProSe) parameters for discovering the WTRU and / or any discovery code or other relevant parameters for sensing operations.

[0081] The WTRU can receive a UE (e.g., WTRU) configuration update (UCU) for configuring policy parameters for D2D sensing. The UCU may include one or more of the ProSe parameter and / or any discovery code or other relevant parameters for discovering the WTRU for D2D sensing operation. The WTRU may (e.g., has already) configured sensing services via the Uu. One or more additional or alternative parameters may be sent to the WTRU, for example, for D2D sensing via the Uu or PC5.

[0082] Network functions such as AMF / Policy Control Function (PCF) can be provided. AMF can examine WTRU subscription data, such as data used to authorize the use of NF for D2D sensing (e.g., UDM / UDR, which refers to sensing capabilities stored in NF). Additionally or alternatively, AMF can examine the authorized sensing server for D2D sensing, for example by providing the sensing server with one or more sensing capabilities of the WTRU and / or the WTRU ID.

[0083] The AMF can, for example, send an AM (Access Management) policy request to the PCF. The AM policy request may contain a D2D sensing service indication and / or one or more requested data types. The PCF may (e.g., subsequently) coordinate with the UDM / UDR, for example, to extract standardized 3GPP / N3GPP sensing capabilities for parameter configuration. The PCF may derive QoS policies and / or parameters, for example, for D2D sensing data collection. The PCF may send an AM policy response to the AMF. The AM policy response may contain authorization for D2D sensing and / or policy parameters.

[0084] An NF (e.g., an AMF) can send a NAS message to the WTRU. The NAS message may contain a registration response indicating authorization for D2D sensing. A PCF can send one or more configuration parameters to the WTRU. An AMF can send a UCU (User Configuration Unit) for configuring policy parameters for D2D sensing. For example, UCU policy parameters may include one or more of the ProSe parameter for discovering the WTRU used for sensing operations, any discovery code, and / or other relevant parameters. The WTRU may (e.g., has already) been configured for sensing services, for example, via a Uu. Additionally or alternatively, parameters may be sent to the WTRU, for example, for D2D sensing via PC5.

[0085] WTRUs can perform discovery, for example, via an NF used for D2D sensing. A WTRU can send a request to an NF (e.g., a sensing NF) for network assistance to discover nearby available WTRUs. This request may include the requested sensing service type, the requested sensing data type, standardized N3GPP data, QoS, the WTRU's location, and / or locations of interest associated with the WTRU.

[0086] A WTRU can, for example, receive a list of discovered WTRUs from an NF. A WTRU can (e.g., subsequently) select one or more WTRUs, for example, based on a request (e.g., a requested sensing service). A WTRU can request to establish a connection with the selected WTRUs (e.g., via AMF / SMF, via CP, or UP, respectively). A WTRU can, for example, send a discovery request to a Direct Discovery Name Management Function (DDNMF). A WTRU can send a discovery request after selecting one or more WTRUs from a list provided by the sensing NF (e.g., selected by the DDNMF). This discovery request can include one or more D2D sensing capabilities of the WTRU, for example, for obtaining one or more ProSe codes. The DDNMF can interact with an application server to authorize the discovery request.

[0087] Alternatively, WTRUs can discover one or more nearby WTRUs, for example, via PC5 discovery. WTRUs can discover one or more nearby WTRUs that provide sensing data sharing. WTRUs can report the NW of the requested sensing service and / or the list of discovered WTRUs to the sensing NF, which can, for example, coordinate with the sensing server to select one or more WTRUs from the discovered WTRUs for D2D sensing based on the requested sensing service.

[0088] An NF (e.g., an AMF / SMF / sensing NF) can receive requests from WTRUs, such as to assist in discovering WTRUs capable of sensing for a requested sensing service. The request may include one or more of the following: the type of sensing service requested, the type of sensing data requested, standardized N3GPP data, QoS, the location of the WTRU, and / or the location of interest of the WTRU.

[0089] A sensing NF can determine a target area, for example, based on the location of a WTRU, to discover available WTRUs that support the requested sensing service and / or data type. The available WTRUs may be equipped with D2D sensing services and / or authorized to exchange sensing data. The sensing NF can coordinate with Network Exposure Functions (NEF) and / or AMFs, for example, to discover available WTRUs within a given area. The sensing NF can coordinate with Network Exposure Functions (NEF) and / or AMFs to discover available WTRUs within a given area based on sensing requirements and / or capabilities.

[0090] An NF (e.g., a sensing NF) can select one or more WTRUs for D2D sensing from the discovered WTRUs. The NF can select one or more WTRUs for D2D transmission from the registered sensing capabilities of the WTRUs and / or the discovered WTRUs, based on the requested sensing service. The NF can (e.g., then) generate a list of discovered WTRUs and / or select one or more WTRUs that meet the requirements. The NF can (e.g., subsequently) send these WTRU IDs (e.g., from the list of WTRUs) to the WTRUs.

[0091] The DDNMF can receive one or more D2D sensing capabilities from the WTRU. The DDNMF can coordinate with another DDNMF in another PLMN. The DDNMF can request authorization from a sensing NF or application server. The DDNMF can assign one or more ProSe codes to the WTRU, for example, based on the WTRU's D2D sensing capabilities (e.g., as received in a discovery request).

[0092] A WTRU can send a sensing service request message. A WTRU can receive a sensing service response message. The sensing service response message may contain a list of one or more second WTRUs. A WTRU can send a sensing authorization request message. This authorization request message may, for example, contain a list of one or more selected second WTRUs based on the list of one or more second WTRUs. A WTRU can receive a sensing authorization response message. A WTRU may (e.g., subsequently) establish a connection with the selected second WTRU.

[0093] The WTRU can perform a direct discovery and connection establishment process with a selected second WTRU. The WTRU can trigger a sensing service request message based on one or more of the following: an application based on a real-time map of the generated environment, sensor congestion information, and / or sensing data from the second WTRU. The sensing service request message may contain a list of target WTRUs or target service areas. For example, sensor congestion may occur when objects such as buildings or vehicles and / or environmental conditions obstruct / interfere with the sensors. The real-time map may include processing and / or communication delays.

[0094] Server-based D2D sensing can be provided. The WTRU can register its D2D sensing capabilities with, for example, a sensing server (e.g., based on Uu and / or PC5 sensing capabilities, which can be registered together or separately). The WTRU can establish a connection with the sensing server and / or send a sensing service request to the sensing server. This sensing service request can be a general request. The sensing service request can, for example, be based on the WTRU's location and / or location of interest, and include localized D2D sensing services. The sensing service request message can include one or more of the following: the requested sensing service type, a list of requested sensing data types, the WTRU's location, the WTRU's location of interest, and / or any other QoS parameters.

[0095] The WTRU can receive a list of WTRUs with D2D capability and / or located in the area of ​​interest. The WTRU can receive a list of supported sensing services and / or supported sensing data sharing for each located WTRU. The WTRU can select one or more WTRUs from the list, for example, those matching the request. The WTRU can send an authorization and / or authentication request to the server to access those WTRUs in the list that match the request. The authorization and / or authentication request can include one or more of the following: WTRU ID, the requested sensing service, and / or the requested sensing data type (e.g., 3GPP / N3GPP data type).

[0096] The sensing server can send sensing service requests, for example, to a sensing NF (e.g., an Integrated Sensing Assist Network Function (ISANF) / SOFM / Sensing Network Function (SNF)). The sensing service request can be used to check the availability of another WTRU in the vicinity of the requested WTRU (e.g., WTRU discovery) and / or at a location of interest. The sensing server can collect the WTRU ID from the sensing NF that supports the requested sensing service and / or data type of the WTRU. The WTRU can be D2D equipped with sensing services and / or authorized, for example, to exchange sensing data for a corresponding area requested by a first WTRU (e.g., WTRU1).

[0097] Alternatively, the sensing server may check its database to find any available WTRUs that support the requested sensing service and data type, such as WTRUs with D2D sensing services and / or authorized to exchange sensing data. The sensing server may send a sensing service response message to a first WTRU (e.g., WTRU1). The sensing service response may include one or more of the WTRU IDs of available WTRUs, supported sensing services, and / or a list of N3GPP data that the WTRUs can share. The server may send a sensing data collection request, for example, to a selected WTRU. For example, once approval is obtained from the terminal WTRU, the server may authorize the WTRU to access the sensing data.

[0098] The sensing NF can determine a target area, for example, based on the location of one or more WTRUs. The sensing NF can determine the target area to discover one or more available WTRUs that support the requested sensing service and data type. The one or more WTRUs may be equipped with D2D sensing services and / or authorized to exchange sensing data. The sensing NF can coordinate with the NEF to, for example, discover one or more available WTRUs within a given area based on sensing requirements. The sensing NF can coordinate with the UDM / UDR for the corresponding target area, for example, to learn about the serving AMF, which can (e.g., subsequently) assist in discovering available devices supporting D2D sensing services (e.g., D2D capabilities) and / or shared data as requested by the WTRU.

[0099] Figure 2This is an example diagram of a 5G network 200. This diagram may include a reference model of a potential architecture for 5G and / or next-generation networks. RAN 202 may refer to a radio access network, such as a radio access network based on a 5G RAT and / or evolved E-UTRA connected to a next-generation core network. Access control and mobility management functions (AMF) 204 may include one or more of registration management, connection management, reachability management, and / or mobility management. Session management functions (SMF) 206 may include one or more of session management (e.g., including session establishment, modification, and release), WTRU IP address allocation, selection, and UP function control. User plane functions (UPF) 208 may include one or more of packet routing and forwarding, packet inspection, and / or traffic usage reporting.

[0100] Integrated sensing may exist. Integrated sensing can be used and / or leverage enhancements to 5G systems to provide sensing services for different target vehicles / applications (e.g., autonomous / assisted driving, V2X, UAV, 3D mapping, smart cities, smart homes, factories, healthcare, maritime sectors). For integrated sensing, there may be a process for collecting sensing measurement data. Sensing measurement data may include data collected from radio / wireless signals affected by objects and / or the environment of interest (e.g., reflection, refraction, diffraction), for example, for sensing purposes. Sensing results may be obtained, for example, from processing the sensing measurement data. An area for sensing (e.g., a sensing service area location) may be defined, which may be an area with or without obstacles (e.g., objects). 5G systems can provide sensing services with a certain quality. N3GPP entities (e.g., other N3GPP entities) may be considered. Sensing measurement data may be transparent to 5GS, for example, enabling the data to be transmitted to an interface defined by 5GS using standard protocols.

[0101] Figure 3This is an example diagram 300 for pedestrian / animal intrusion detection. Core network 302 can receive sensing measurement data, for example, from one or more base stations 304. Base station 304 can collect sensing measurement data, including data collected from radio / wireless signals affected by object 306 and / or the environment of interest (e.g., reflection, refraction, diffraction). Exemplary object 306 may include vehicles, animals, and / or people. Area 308 (e.g., around residence 311) and / or road 312 can be defined for sensing (e.g., sensing service area location). Area 310 and / or road 312 may contain one or more objects 306 that can be sensed (e.g., detected). Base station 304 can sense object 306 in area 310 or road 312, for example, by collecting radio / wireless signals affected by object 306 (e.g., reflection, refraction, diffraction). Base station 304 can (e.g., subsequently) transmit the sensing measurement data to core network 302. Core network 302 can be configured to derive sensing results, for example, by processing the sensing measurement data. Alternatively, the core network 302 may send measurement data to the detection element 314 (e.g., intrusion detection) for processing.

[0102] Figure 4 Figure 400 illustrates intrusion detection in the surrounding environment of a smart home. Base station 404 and / or WTRU 401 can detect intrusions, for example, within a sensing area. Base station 404 can, for example, cooperate with one or more WTRUs 401 to detect intrusions within the sensing area. For example, base station 404 and / or WTRU 401 can collect sensing measurement data, including data collected from radio / wireless signals affected by object 406 and / or the environment of interest. Base station 404 and / or WTRU 401 can transmit sensing signal 403, for example, to the sensing area. The radio / wireless signals affected by object 406 may include reflected signal 405 (e.g., a reflected signal of sensing signal 403). Base station 404 and / or WTRU 401 can, for example, transmit the sensing measurement to a network. The network can process the sensing measurement, for example, to detect intrusion.

[0103] Figure 5 Figure 500 shows an example of object detection performed by base station 502 and WTRU 501. The system and method can be configured for transparent sensing. In transparent sensing, sensing data can be captured and / or communicated by WTRU 501, for example, so that 5GS can be aware of the sensing information. The user terminal (e.g., WTRU 501) can acquire sensing signals from (e.g., multiple) 3GPP and / or non-3GPP devices. 5GC can determine (e.g., various) available sensing services, for example, by processing the collected sensing data.

[0104] For example, the sensing capabilities of WTRU 501 may be insufficient and / or unusable for performing sensing tasks (e.g., the sensing device is blocked by environmental conditions). The provided systems and methods may utilize the sensing capabilities of another WTRU 501 that communicates directly via Uu and / or ProSe, and / or utilize the sensing capabilities of, for example, a RAN entity capable of performing sensing tasks (e.g., as described herein).

[0105] Some systems may not allow WTRU 501 to use and / or utilize the sensing capabilities of another WTRU 501 for sensing services. To enable sensing services using the sensing capabilities of another WTRU 501, information about the sensing capabilities of the other WTRU 501 can be made available (e.g., to make it usable) to the entity requesting the sensing services (e.g., WTRU 501). For example, for security reasons, sensing data can be (e.g., only) collected from legitimate entities. Sensing data from another entity (e.g., an illegitimate entity) can be used to attack that entity. The systems and methods disclosed herein address how WTRU 501 is authorized and / or configured to access sensing data from another WTRU 501 for sensing operations, and / or how another WTRU 501 is discovered and / or selected, for example, by providing sensing data sharing to provide sensing services in the vicinity of WTRU 501.

[0106] A sensing network function (NF) may exist. To achieve integrated sensing, new network functions may exist (e.g., new ones). A sensing NF may contain multiple network functions. For example, these network functions (e.g., functions contained within a sensing NF) may be an Integrated Sensing Assist NF (ISANF) and / or a Sensing Operation Management Function (SOMF). ISANF and / or SOMF may be logical entities, and / or may be co-located with another entity. For example, ISANF may be co-located with NEF, ISANF and SOMF may (e.g., both) be co-located with NEF, SOMF may be co-located with AMF, and / or SOMF may be co-located with RAN.

[0107] ISANF can monitor and interact with application functions (AFs) of sensing services. ISANF can understand service requests from AFs and / or deduce the corresponding request sensing mechanism. For example, based on this sensing mechanism, ISANF can forward the request to the relevant NF within the 5GC. (For example, the relevant NF can serve the area of ​​interest and / or the requesting entity, such as a WTRU.) For example, when the AF is a third-party application and not a trusted entity in the 5GS, the AF and ISANF can communicate through the Network Exposure Function (NEF).

[0108] SOMF can handle the coordination of sensing operations, such as those within base stations and / or WTRUs. SOMF can determine (e.g., derive) coordination information for sensing operations. Based on information received from the AMF, such as the requested sensing area, the list of BS and WTRUs, and / or one or more of the requested sensing mechanisms with QoS requirements, SOMF can derive coordination information for sensing operations.

[0109] SOMF can determine the role of the sensing operation. For example, this role can be one or more of the following: a sender of the sensing signal, a receiver of the sensing signal, an entity that collects sensing measurement data, and / or an entity that calculates the sensing results. SOMF can determine one or more of the sensing period and / or the waveform of the sensing signal. SOMF can send messages, such as to the BS and / or sender resource allocation, to transmit the sensing signal within the sensing period.

[0110] Sensing capabilities may exist. Systems and methods may communicate sensing-related capability parameters as described herein (e.g., in messages). Parameters may include information about the sensing capabilities of another WTRU (e.g., obtained via ProSe direct communication) and / or information about the sensing capabilities of a RAN entity (e.g., gNB).

[0111] Parameters (e.g., sensing-related capability parameters) may include one or more of the following: sensing type (e.g., monostatic sensing and / or bistatic sensing), requested sensing service, supported sensing service, 3GPP side walkway sensing capability, 3GPP Uu sensing capability, 3GPP RAN sensing capability (e.g., gNB), non-3GPP sensing capability (e.g., LiDAR, Wi-Fi), sensor output data type (e.g., raw data), type of sensing data processing (e.g., anonymization), data compression capability, protocol information for sensing data and control data (e.g., UDP for sensing data, TCP for control / metadata), network transport information for sensing data and control data (e.g., 3GPP Uu for control data and Wi-Fi for sensing data), other data processing and analysis capabilities (e.g., object detection), sensing node role (e.g., data consumer, data provider, service provider, service consumer), and / or device availability / utilization. Device availability / utilization can include one or more of the following indicators: how many (e.g., other) sensing tasks the WTRU performs, how many (e.g., new) sensing tasks the WTRU can accept, and / or the priority level the WTRU can determine for (e.g., new) tasks. For example, at a given time, there may be only one high-priority sensing task.

[0112] Sensing requirements / data requirements may exist. The systems and methods described herein may (e.g., in a message) include communication of sensing-related requirement parameters. Parameters (e.g., sensing-related requirement parameters) may include one or more of the following: data time validity (e.g., the time during which a portion of the data is valid), latency requirements (e.g., the minimum latency that must be met to send sensing data), proximity (e.g., proximity to a user or object), location (e.g., the location of the WTRU), location of interest (e.g., it may not be the location of the WTRU, but rather the location where the consumer WTRU needs sensing data), sensing data communication preferences (e.g., control plane, user plane, sidelink, Uu), data buffer / storage destination (e.g., specifying whether data should be sent to a different location than the requesting WTRU; for example, data may be requested to be sent to the AF), periodicity / frequency (e.g., data reporting frequency), and / or sample size (e.g., the sample size of the data).

[0113] Sensing data communication preferences can indicate how sensing data and / or control data can be transmitted. For example, sensing data communication preferences can indicate that control data can be transmitted via a side link, and / or sensing data can be transmitted via a Uu reference point.

[0114] A Wireless Transmit / Receive Unit (WTRU) can, for example, send a registration message to a Network Function (NF). The registration message may contain one or more WTRU sensing capabilities. The WTRU can receive response messages, such as those from the NF. The response message may contain authorization indications, such as authorization indications for one or more sensing and configuration parameters. The WTRU can send a registration complete message. The WTRU can receive configuration information, such as configuration information associated with one or more sensing and configuration parameters.

[0115] One or more sensing and configuration parameters may include one or more of the Proximity Service (ProSe) parameters and / or discovery codes. One or more sensing capabilities may include indications of one or more of the sensing type, sensing service, and / or sensing role. For example, the sensing type may include one or more of monostatic sensing and / or bistatic sensing. For example, the sensing service may include one or more of radar, camera, proximity, location, and / or temperature services. The sensing role may include one or more of the transmitter and / or receiver.

[0116] Registration and / or discovery may occur, for example, via an NF. Policy configuration and / or authorization may occur, for example, via an NF used for D2D sensing. A WTRU with D2D sensing capabilities can obtain authorization and / or policy parameter configuration, for example, to access sensing data from another WTRU. To obtain D2D authorization, a WTRU may send its sensing capabilities to a CN. The CN may (e.g., subsequently) authorize the WTRU to perform D2D sensing and / or provide policy configuration.

[0117] Figure 6 An exemplary flowchart of the policy provisioning and authorization process is shown at 600. At 622, WTRU 620 may send a registration message. The registration message may include its D2D sensing capabilities, such as those described herein. At 624, the RAN 602 node may select the corresponding AMF 604 associated with WTRU 620. At 626, AMF 604 may send a subscription data request message to the Unified Data Management (UDM) and / or Unified Data Repository (UDR) 616. The subscription data request message may indicate that the request is for sensing authorization.

[0118] Alternatively or additionally, AMF 604 may request 620 authorization from the sensing server for the WTRU used for D2D sensing. The request message may include the WTRU's 620 sensing capabilities and / or the WTRU's 620 ID (e.g., GPSI). At 628, AMF 604 may send a message / configuration notification to PCF 612. This message may include a sensing service indication and / or the data type requested and / or other information as described herein. PCF 612 may coordinate with UDM / UDR 616 to extract standardized 3GPP / N3GPP sensing capabilities, for example, for parameter configuration. PCF 612 may, for example, derive QoS policies and / or parameters for sensing based on received sensing configuration information.

[0119] At 630, PCF 612 and / or AMF 604 can perform policy generation and / or association processes. PCF 612 can send the generated policy information to AMF 604. The generated policy information may include authorization of sensing and / or policy parameters. At 632, WTRU 620 can receive a response message (e.g., registration acceptance) from the network. This response message may include authorization of sensing and / or configuration parameters (e.g., as described herein).

[0120] At 634, WTRU 620 may, for example, send a registration completion message 634 to AMF 604. At 636, WTRU may receive a UCU for policy parameter configuration for D2D sensing. These parameters may include one or more of the ProSe parameters for discovering WTRU 620 for sensing operations, any discovery codes, and / or other relevant parameters. WTRU 620 may (e.g., has already) been configured for sensing services via UU. Additional or alternative parameters may be sent to WTRU 620 via PC5 (e.g., by another WTRU) for D2D sensing.

[0121] NF-based WTRU discovery may exist, for example, for sensing. Figure 7A and Figure 7B An exemplary flowchart 700 illustrates a process for network-based WTRU sensor discovery. At 732, WTRUs 720 and 722 can be authorized and / or configured for D2D sensing. AMF / SMFs 704 and 706 can coordinate with UDM / UDR and / or sensing NF 724, for example, to identify WTRUs that support sensing capabilities (e.g., WTRU 720 and / or WTRU 722). At 734, WTRU 720 can be triggered to request sensing services from one or more WTRUs (e.g., 722). This trigger can include: an application generating a real-time map of the user's environment, additional information related to sensor congestion at WTRU 720, and / or environmental changes (e.g., any changes detected by the sensors). The application can include sensing data from another nearby WTRU (e.g., 722).

[0122] At 736, WTRU 720 can, for example, send a sensing request message to sensing NF 724. The sensing request message may indicate / contain a device discovery request for D2D sensing. The sensing request message may contain criteria, such as the criteria that a discovered device must meet. This document presents examples of parameters used for such criteria.

[0123] Alternatively, WTRU 720 can discover any WTRU (e.g., 722) that supports D2D sensing, for example, via PC5 discovery. The WTRU can report the requested sensing service and / or a list of discovered WTRUs to the NW. For example, the WTRU can send information to sensing NF 724 and / or to AMF 704 via NAS signaling. AMF 704 can (e.g., subsequently) coordinate with sensing NF 724 to select a WTRU for D2D sensing from the discovered WTRUs based on the requested sensing service. At 738, sensing NF 724 can send a sensing capability query message to NEF 728, for example, to obtain a list of WTRUs in the area. This area can be the area where WTRU 720 is located, and / or any area of ​​interest where WTRU 720 expects to perform sensing operations. The sensing capability query message can contain the sensing capabilities and / or sensing requirements of WTRU 720 (e.g., location information).

[0124] At 740, NEF 728 can collect the WTRU IDs of registered WTRUs within the area, and / or send a list of WTRU IDs and / or their supported sensing services to sensing NF 724. NEF 728 can collect WTRU IDs based on received sensing capabilities and requirements.

[0125] At 742, the sensing NF can, for example, match the available sensing capabilities of each WTRU in the list with the requested sensing requirement based on information received from NEF 728 and / or information available to sensing NF 724 of previously known WTRUs (e.g., previously discovered, registered, or configured WTRUs). For example, sensing NF 724 can query AMF 704 to obtain information on D2D sensing-enabled WTRUs available at the requested location and / or registered within the same PLMN. At 744, sensing NF 724 can send a sensing response message, for example, with / containing information about the discovered WTRUs. The sensing response message can contain the WTRU IDs and / or the capabilities of these WTRUs (e.g., as described herein). The sensing response message can indicate whether the available sensing capabilities can satisfy the sensing requirement. For example, when the D2D sensing service is controlled by the network, the sensing response message can indicate whether the sensing request is accepted.

[0126] The sensing NF 724 can indicate whether the available sensing capabilities can fully and / or partially satisfy the requested sensing requirements. Partial satisfaction of requirements may include (e.g., only) a corresponding WTRU that supports some requirements (e.g., not all requirements). Alternatively, partial satisfaction of requirements may include a corresponding WTRU that is a WTRU with D2D sensing capabilities.

[0127] The sensing NF 724 can determine whether the sensing capability of the available WTRU meets the requirements for reception, and / or (e.g., whether D2D sensing can be performed). At 746, once the WTRU 720 has received one or more WTRU IDs provided by the sensing NF 724, the WTRU 720 can send a discovery request to the DDNMF 726. The discovery request may include the D2D sensing capability of the selected WTRU and / or the WTRU ID (e.g., for obtaining the ProSe code).

[0128] WTRU 720 can receive a list of selected WTRUs that provide the required D2D sensing services. Sensing NF 724 can make a selection (e.g., based on a list) from a request from WTRU 720. Alternatively or additionally, WTRU 720 can receive a detailed list of WTRUs from sensing NF 724, including, for example, WTRU IDs associated with full and / or partial D2D sensing capabilities. WTRU 720 can select one or more WTRUs from the list.

[0129] At 748, DDNMF 726 can interact with the application server to authorize the discovery request. This request may include the D2D sensing capabilities of the WTRU. DDNMF 726 can receive D2D sensing capabilities from WTRU 720. Alternatively, DDNMF 726 can coordinate with another DDNMF in another PLMN (e.g., if the WTRU providing the sensing service is not in the same PLMN as WTRU 720), and / or can request authorization from sensing NF 724 and / or application server 730.

[0130] At 750, DDNMF 726 can assign a ProSe discovery code and / or discovery filter to the WTRU (e.g., depending on the type A or B discovery type), for example, based on the WTRU's D2D sensing capability received in the discovery request. DDNMF 726 can assign the code and / or filter based on authorization information (e.g., information received at 748). At 752, WTRU 720 can receive a ProSe code (e.g., assigned by DDNMF 726). The ProSe code may contain (e.g., additional) indications of whether other WTRUs (e.g., WTRU 722) are discoverable. If, for example, a WTRU (e.g., WTRU 722) has performed a discovery process with DDNMF 726, then that WTRU can be discoverable. There may be other WTRUs (e.g., WTRU 722) that have not yet received their discovery code and / or filter from DDNMF 726. In this scenario, for example, after another WTRU (e.g., WTRU722) has received its discovery code and / or discovery filter, DDNMF 726 can send a trigger message to WTRU 720 to initiate PC5 discovery.

[0131] For example, prior to 754, (e.g., other) WTRUs may have already performed a discovery process with DDNMF 726, and / or may have received the corresponding ProSe discovery code and / or discovery filter from DDNMF 726. At 754, WTRU 720 may perform a discovery process on a list of WTRUs (e.g., received at 746), and / or may establish a connection with the discovered and / or selected WTRU (WTRU 722) for example, via PC5 using the ProSe code received at 752.

[0132] Alternatively, the PC5 discovery message may include the requested sensing service type and / or the requested sensing data type. A WTRU can use information about supported sensing service types and / or supported sensing data types to discover other WTRUs. For example, once a WTRU has discovered another nearby WTRU, it can send a request to the 5GC. This request can confirm whether (e.g., whether) the supported sensing service type and / or supported sensing data type of the discovered WTRU are verified.

[0133] WTRU 720 (e.g., after discovering WTRU 722) can send an authorization request (e.g., another) to 5GC for the selected WTRU 722, which may have more discrete parameters (e.g., a list of requested sensing services or sensing data). For example, once authorization is successful, WTRU 720 can initiate connection establishment. This ensures that WTRU 722 confirms the sharing of the required sensing service data at the location of interest. For example, WTRU 722 may agree to provide WTRU 720 video capabilities in a city center but not at its home address. Alternatively or additionally, DDNMF 726 can be co-located with D2D sensing based on a sensing NF server, such as... Figure 7A and Figure 7B The process is shown in the diagram.

[0134] Figure 8A and Figure 8B An exemplary flowchart of a server-based D2D sensing process is shown at 800. At 834, WTRUs 820, 822 may register with sensing server 832, for example, by sending a sensing service request message to sensing server 832. The sensing service request message may contain some or all of the information elements (e.g., as shown herein).

[0135] At point 836, WTRU 820 can be triggered to request sensing services from one or more WTRUs. This trigger may include: an application generating a real-time map of the user's environment, and / or additional information about WTRU 820 sensor congestion, and / or sensing data from another nearby WTRU.

[0136] At 838, WTRU 820 can establish a connection with sensing server 832 and / or send a sensing service request to perform sensing services. The sensing service request may contain some and / or all of the parameters (e.g., as described herein).

[0137] The WTRU 820 can perform PC5-based discovery (e.g., after 836), such as using ProSe to discover nearby available WTRUs with D2D sensing capabilities and / or providing the required sensing services. The WTRU 820 can include a list of target WTRUs in the sensing service request.

[0138] The WTRU 820 can utilize network assistance to locate WTRUs with D2D sensing capabilities within a region. The WTRU 820 can include location information, such as the location of the WTRU 820 and / or the target service area, in the sensing service request.

[0139] At 840, the sensing server 832 may, for example, send a sensing capability query to the sensing NF 824. The sensing capability query may include one or more input parameters (e.g., parameters received at 838) to check the availability of WTRUs that match the criteria specified at 838. The sensing server 832 may determine the target area, for example, based on the reported location of the WTRU 820 and / or according to the target service area requested in the sensing capability query message. Depending on the input parameters, the sensing NF 824 may take different actions. Some examples are provided herein.

[0140] WTRU IDs can be collected from the HPLMN (e.g., at 842, 844, and / or 846). At 842, the sensing NF 824 can send a sensing capability query to the UDM and / or UDR 816, for example, to obtain information about the serving AMF and / or a list containing the target WTRU and / or target service area information. For example, if requested by WTRU 820, the serving AMF 804 can assist in discovering available devices with D2D sensing services and / or data sharing. For example, if a list of target WTRUs is contained at 842, the request (e.g., subsequently) could be to locate the serving AMF 804 of the target WTRU. For example, if the target service area is contained at 842, the request (e.g., subsequently) could be to locate one or more (e.g., all) available AMFs 804 providing services in the target area. The list of AMFs 804 may, for example, have been configured in the sensing NF 824 by the operator. The sensing NF 824 can, for example, determine the serving AMF 804 based on location information.

[0141] At 844, sensing NF 824 can receive a sensing capability response. The sensing capability response may contain information from the serving AMF 804 of UDM / UDR 816. At 846, if location information is provided (e.g., at 838) and / or sensing NF 824 has received a list of serving AMFs for the target area (e.g., at 844), then (e.g., subsequently) sensing NF 824 can send a request to serving AMF 804. This request may contain a sensing requirement to collect a list of available WTRUs supporting the D2D sensing service. AMF 804 can respond with a WTRU ID for WTRUs registered to serving AMF 804.

[0142] WTRU IDs can be collected from (e.g., another) PLMN (e.g., at 848 and / or 850). At 848, sensing NF 824 can send a sensing capability query message to NEF 828, for example, to obtain a list of WTRUs in the area. For example, NEF 828 can collect the WTRU IDs of registered WTRUs in the area, and / or send the list to sensing NF 824, for example, based on sensing capabilities and requirements. At 850, NEF 828 can collect the WTRU IDs of registered WTRUs in the area, and / or send the list of WTRU IDs to sensing NF 824. NEF 828 can collect the WTRU IDs of registered WTRUs in the area based on available sensing capabilities and requirements.

[0143] At 852, the sensing NF 824 can select WTRUs that can meet some or all of the sensing requirements received, for example, from the sensing server 832. The sensing NF 824 can be populated with WTRUs and / or their sensing capabilities. For example, the sensing NF 824 can coordinate with the UDM / UDR 816 to verify WTRU subscriptions and / or identify WTRUs that support D2D sensing capabilities.

[0144] At 854, the sensing server 832 may receive information about the selected WTRU. This information may include the WTRU's ID and / or its capabilities (e.g., as described herein). At 856, the sensing server 832 may, for example, use the received information from the WTRU to update its local sensing capability database. The sensing server 832 may alternatively or additionally select and / or determine WTRUs that meet, for example, the sensing requirements sent by WTRU 820 at 838.

[0145] Sensing server 832 can be aware of the proximity and / or sensing capability of another WTRU. Sensing server 832 can use this information (e.g., the proximity and / or sensing capability of another WTRU) to select a suitable list of WTRUs. The suitable list of WTRUs can be sent to WTRU 820 (e.g., at 858).

[0146] At 858, WTRU 820 may receive a sensing service response message, for example, from sensing server 832. The sensing service response message may contain the WTRU ID of the available WTRUs and / or the capabilities of the WTRUs (e.g., as described herein). The sensing service response message may indicate whether the capabilities of the available WTRUs (e.g., as described herein) fully and / or partially meet the sensing requirements. For example, sensing server 832 may (e.g., only) select one or more of the most suitable WTRUs and / or rank the WTRUs in the list. The ranking can range from most suitable to least suitable WTRUs. WTRU 820 may select WTRUs from the list, for example, based on the ranking.

[0147] At 860, WTRU 820 can select one or more WTRUs from the list, for example, those matching the requirements. This selection can be based on parameters (e.g., as described herein) and / or any other information available to the WTRU. Other information may include the WTRUs in the list and / or their associated information (e.g., supported sensing services and / or supported sensing data). For example, WTRU 820 can filter out (e.g., not select) WTRUs that WTRU 820 (e.g., recently) determined are out of coverage. Additionally or alternatively, WTRU 820 can filter out (e.g., not select) WTRUs that may have temporarily terminated sensing data sharing support and / or may experience (e.g., higher) latency in communicating with those WTRUs.

[0148] At 862, WTRU 820 can send an authorization request message to the server to access these WTRUs. The authorization request message may contain WTRU authorization information for the relevant service and / or WTRU, and / or some or all of the sensing requirements (e.g., as described herein). Alternatively or additionally, the authorization request message may contain WTRU authentication information. The authentication information may contain the WTRU ID of the selected WTRU.

[0149] At 864, sensing server 832 may send a sensing data collection request message to the requesting WTRU (e.g., WTRU 822). The sensing data collection request message may contain data requirements (e.g., as described herein). At 866, WTRU 822 may, for example, send a data collection response message to sensing server 832. The data collection response message may contain conditions that allow the request to be approved. Exemplary conditions may include one or more of the following: the duration for which WTRU 822 can provide its sensing service; the periodicity of reporting data (e.g., to reduce bandwidth consumption / QoS or for energy-saving reasons, the periodicity may be reduced); the sampling size (e.g., to reduce bandwidth consumption or for energy-saving reasons, the sampling size may be reduced); any other parameters specified as sensing requirements that WTRU 822 cannot satisfy (e.g., at 864) (e.g., latency requirements, enabled partial sensing data sharing); and / or the sensing type (e.g., 3GPP-based sensing or non-3GPP-based sensing).

[0150] At 868, WTRU 820 may receive a sensing authorization message. The sensing authorization message may contain an indication of whether the sensing request for each requesting WTRU is accepted. The sensing authorization message may also contain conditions (e.g., conditions received in step 866). Alternatively or additionally, sensing server 832 may (e.g., already) have approved data collection for the selected WTRU (e.g., at 860), and (e.g., therefore) sensing server 832 may skip / ignore (864 and / or 866) the corresponding WTRU. Alternatively or additionally, the sensing authorization message may contain WTRU authentication information. The authentication information may contain the WTRU ID of the selected WTRU.

[0151] At 870, WTRU 820 can perform a direct discovery and / or connection establishment process with a selected WTRU (e.g., WTRU 822), for example, according to a negotiated sense data communication mode. Data can (e.g., subsequently) be exchanged at the application layer between WTRU 820 and WTRU 822, for example, via (e.g., a buffered) sense server. For example, once the peer WTRU establishes a PC5 connection using authorization information, data can (e.g., subsequently) be exchanged directly between WTRU 820 and WTRU 822 via PC5. Discovery and / or connection establishment via PC5 can follow the procedures specified herein (e.g., at 848, 850, 852, 854, and / or 856).

[0152] Sensing server 832 can track the location of WTRUs, for example, based on reported WTRU locations and / or by subscribing to an LMF to obtain location updates for selected WTRUs. Peer WTRUs (e.g., using a prose proximity service) can track the locations of other (e.g., peer) WTRUs. For example, when WTRU 822 is not near the WTRU and / or is no longer within the target service area, sensing server 832 can notify WTRU 820 that the WTRU is not in the indicated area. Alternatively or additionally, sensing server 832 can be co-located with sensing NF 824, for example, based on... Figure 8A and Figure 8B The process is shown.

Claims

1. A wireless transmit / receive unit (WTRU) including a processor, the processor being configured to: Send a sensing request message to the network, the sensing request message including an indication of the sensing standard associated with the device-to-device (D2D) sensing service; Receive a sensing response message from the network, the sensing response message including an indication associated with the second WTRU; Send a discovery request to the network, the discovery request including an indication of at least one D2D sensing capability of the second WTRU; and In response to the discovery request, a ProSe code associated with the second WTRU is received.

2. The WTRU of claim 1, wherein the indication of the sensing standard associated with the D2D sensing service includes: At least one of the following associated with D2D sensing services: data time validity, latency requirements, proximity, location, location of interest, sensing data communication preferences, data storage destination, periodicity, frequency, and sampling size.

3. The WTRU of claim 1, wherein the ProSe code includes an indication of the at least one D2D sensing capability of the second WTRU.

4. The WTRU of claim 1, wherein the processor is configured to: determine, based on a trigger, to request the D2D sensing service from one or more second WTRUs.

5. The WTRU of claim 4, further comprising a sensor, wherein the triggering includes: At least one of a real-time map, an indication of congestion associated with the sensor, and an indication of data associated with the sensor.

6. The WTRU of claim 1, wherein the processor is configured to receive a discovery code for the D2D sensing service.

7. The WTRU of claim 1, wherein the sensing response message includes an indication of whether a sensing request is accepted.

8. The WTRU of claim 1, wherein the sensing response message includes an indication of a WTRU list, and wherein the processor is configured to select the second WTRU from the WTRU list.

9. The WTRU of claim 8, wherein the indication of the WTRU list includes an indication of sensing services for each of the WTRUs in the WTRU list, and wherein the processor is configured to select the second WTRU from the WTRU list comprising: The processor is configured to select a second WTRU from the WTRU list based on an instruction from the sensing service for at least one of the second WTRUs in the WTRU list.

10. The WTRU of claim 1, wherein the at least one D2D sensing capability includes: Sensing capabilities associated with at least one of sensing type, sensing service, and sensing role.

11. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Send a sensing request message to the network, the sensing request message including an indication of the sensing standard associated with the device-to-device (D2D) sensing service; Receive a sensing response message from the network, the sensing response message including an indication associated with the second WTRU; Send a discovery request to the network, the discovery request including an indication of at least one D2D sensing capability of the second WTRU; and In response to the discovery request, a ProSe code associated with the second WTRU is received.

12. The method of claim 11, wherein the indication of the sensing standard associated with the D2D sensing service includes: At least one of the following associated with D2D sensing services: data time validity, latency requirements, proximity, location, location of interest, sensing data communication preferences, data storage destination, periodicity, frequency, and sampling size.

13. The method of claim 11, wherein the ProSe code includes an indication of the at least one D2D sensing capability of the second WTRU.

14. The method of claim 11, comprising: The D2D sensing service is requested from one or more second WTRUs based on triggers, wherein the triggers include at least one of: a real-time map, an indication of congestion associated with the sensor, and an indication of data associated with the sensor.

15. The method of claim 11, comprising: Receive the discovery code for the D2D sensing service.

16. The method of claim 11, wherein the sensing response message includes an indication of a WTRU list, and wherein the method includes selecting the second WTRU from the WTRU list.

17. The method of claim 16, wherein the indication of the WTRU list includes an indication of sensing services for each of the WTRUs in the WTRU list, and wherein selecting the second WTRU from the WTRU list includes: The second WTRU is selected from the WTRU list based on the indication of the sensing service for at least one of the WTRUs in the WTRU list.

18. A base station, comprising a processor, the processor being configured to: A sensing request message is received from the first wireless transmit / receive unit (WTRU), the sensing request message including an indication of a sensing standard associated with a device-to-device (D2D) sensing service; Send a sensing response message to the first WTRU, the sensing response message including an indication associated with the second WTRU; Receive a discovery request from the first WTRU, the discovery request including an indication of at least one D2D sensing capability of the second WTRU; as well as In response to the discovery request, a Proximity Service (ProSe) code associated with the second WTRU is sent.

19. The base station of claim 18, wherein the ProSe code includes an indication of the at least one D2D sensing capability of the second WTRU.

20. The base station of claim 18, wherein the sensing response message includes an indication of information associated with a plurality of second WTRUs.

Images