Methods, architectures, apparatuses, and systems for synchronization of sensing operations and connection management state

Abstract

Methods, architectures, apparatuses, and systems for synchronization of perception operations and connection management states are described herein. In one embodiment, a method implemented in a WTRU can include sending, to a first network element, a perception request message for a synchronized perception associated with a perception task, receiving, from the first network element, a perception accept message, receiving a synchronization message including configuration information associated with the perception task, updating (e.g., locally) synchronization information based on the configuration information, performing sensor fusion based on the updated synchronization information, and sending, to the first network element, a fusion result of the performed sensor fusion.

Description

[0001] Cross-reference to related applications This application claims the benefit of European Patent Application No. 24160661,5, filed on 29 February 2024, which is incorporated herein by reference in its entirety. Technical Field

[0002] This disclosure generally relates to the fields of communications, software, and coding, including methods, architectures, apparatuses, and systems relating to the synchronization of sensing operation and connection management states. Background Technology

[0003] Sensing capabilities allow the use of various sensors to independently perceive various properties of physical objects or the environment (e.g., position, velocity, orientation). The embodiments described herein have been designed with the foregoing in mind. Summary of the Invention

[0004] This document describes methods, architectures, apparatuses, and systems for synchronizing sensing operations and connection management states. In one embodiment, a Wireless Transmit / Receive Unit (WTRU) is described. The WTRU may include circuitry comprising a transmitter, a receiver, a processor, and memory. The circuitry may be configured to send a sensing request message to a first network element for synchronized sensing associated with a sensing task, and to receive a sensing acceptance message from the first network element. The circuitry may be configured to receive a synchronization message including configuration information associated with the sensing task, update the synchronization information (e.g., locally) based on the configuration information, perform sensor fusion based on the updated synchronization information, and send the fusion result of the performed sensor fusion to the first network element.

[0005] In one embodiment, a network element is described. The network element may include circuitry comprising a transmitter, a receiver, a processor, and memory. The circuitry may be configured to receive a sensing request message from a wireless transmit / receive unit (WTRU) for synchronized sensing associated with a sensing task, send a sensing acceptance message to the WTRU, and send a synchronization message including configuration information associated with the synchronization of the sensing task.

[0006] In one embodiment, a first method implemented in a WTRU is described. The first method may include sending a perception request message to a first network element for synchronous perception associated with a perception task, receiving a perception acceptance message from the first network element, receiving a synchronization message including configuration information associated with the perception task, updating the synchronization information based on the configuration information (e.g., locally), performing sensor fusion based on the updated synchronization information, and sending the fusion result of the performed sensor fusion to the first network element.

[0007] In one embodiment, a second method implemented in a network element is described. The second method may include receiving a perception request message from a WTRU for synchronized perception associated with a perception task, sending a perception acceptance message to the WTRU, and sending a synchronization message including configuration information associated with the synchronization of the perception task. Attached Figure Description

[0008] A more detailed understanding can be obtained from the following detailed description, given by way of example in conjunction with the accompanying drawings. Like this detailed description, the figures in such drawings are exemplary. Therefore, the figures (each figure) and the detailed description should not be considered limiting, and other equally valid examples are possible and likely to occur. Furthermore, similar reference numerals (“reference numerals”) in the figures indicate similar elements, and wherein: Figure 1A This is a system diagram illustrating an example communication system.

[0009] Figure 1B It's shown in the diagram. Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

[0010] Figure 1C It's shown in the diagram. Figure 1A The diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system.

[0011] Figure 1D It's shown in the diagram. Figure 1A The diagram shows another example RAN and another example CN used in the communication system.

[0012] Figure 2 This is a diagram illustrating an example architecture for 5G / next-generation networks; Figure 3 This is an example of pedestrian / animal intrusion detection; Figure 4 This is an illustration of an example of intruder detection; Figure 5 These are two examples of diagrammatic perception patterns; Figure 6 This is a diagram illustrating an example of sensor fusion classification based on a data source; Figure 7A and Figure 7B These are two diagrams illustrating an example of architecture-based sensor fusion classification; Figure 8 This is a diagram illustrating an example of sensor fusion classification based on intermediate steps; Figure 9 This is a diagram illustrating an example use case of sensor fusion; Figure 10 This is a diagram illustrating an example method for synchronizing sensing operations; Figure 11 This is a diagram illustrating an example method for synchronizing sensing operations implemented in WTRU; and Figure 12 This is a diagram illustrating an example method for synchronizing sensing operations implemented in network elements. Detailed Implementation

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

[0014] Example communication system.

[0015] The methods, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. Regarding Figure 1A-1D An overview of various types of wireless devices and infrastructures is provided, wherein various elements of the network may be utilized, performed, arranged, and / or adapted and / or configured for use with the methods, apparatuses, and systems provided herein.

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

[0017] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the 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, 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 (or be) 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, and so on. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0018] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b can be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d, for example, to facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or Network 112. For example, base stations 114a and 114b can be any of a base transceiver station (BTS), Node-B (NB), eNode-B (eNB), home Node-B (HNB), home eNode-B (HeNB), gNode-B (gNB), New Radio (NR) NodeB (NR NB), 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 can include any number of interconnected base station and / or network elements.

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

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

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

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

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

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

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

[0026] For example, Figure 1A Base station 114b can be a wireless router, home Node-B, home eNode-B, or 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 drone use), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In one 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 any of the following: small cells, picocells, or femtocells. Figure 1A As shown, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b may not need to access the Internet 110 via CN 106 / 115.

[0027] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although in Figure 1A As not shown, but to be understood, RAN104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs employing 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 utilize NR radio technology, CN106 / 115 can also communicate with another RAN (not shown) employing any of GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi radio technologies.

[0028] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). 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 / 114 or a different RAT.

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

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

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

[0032] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) on air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 can be, for example, a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In one embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF 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.

[0033] 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. For example, WTRU 102 may employ MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals on air interface 116.

[0034] 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. Thus, for example, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via multiple RATs such as NR and IEEE 802.11.

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

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

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

[0038] Processor 118 may be further coupled to other components / peripherals 138, which may include one or more software and / or hardware modules / units providing additional features, functions, and / or wired or wireless connectivity. For example, components / peripherals 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (e.g., for photos and / or video), 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, and so on. Components / peripherals 138 may include one or more sensors, such as gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, attitude sensors, biosensors, and / or humidity sensors.

[0039] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for both uplink (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 to reduce and / or substantially eliminate self-interference via hardware (e.g., chokes) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for either uplink (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

[0041] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, 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 on air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and receive radio signals from WTRU 102a.

[0042] 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 the uplink (UL) and / or downlink (DL), etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other on the X2 interface.

[0043] 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 the CN operator.

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

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

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

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

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

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

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

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

[0052] 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.

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

[0054] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV whitespace (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support metering-type control / machine-type 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).

[0055] 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 bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA among all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, for a STA that supports (e.g., only supports) the 1 MHz mode (e.g., an MTC type device), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy, even if most of the band remains idle and can be available.

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

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

[0058] RAN 113 may include gNBs 180a, 180b, and 180c; however, 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 on air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from WTRUs 102a, 102b, and 102c. Thus, for example, gNB 180a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

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

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

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

[0062] 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 at least one Data Network (DN) 185a, 185b. Although each of the foregoing elements is depicted 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 the CN operator.

[0063] 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 Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, and so on. AMF 182a and 182b can use network slicing, for example, to customize CN support for WTRU 102a, 102b, and 102c based on the service type used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency Time (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, and / or so on. AMF 182a, 182b can provide control plane functions for handover between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as Wi-Fi.

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

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

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

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

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

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

[0070] Throughout the embodiments described herein, the terms “base station,” “network,” and “gNB” (collectively, “network”) are used interchangeably to refer to any network element, such as a network element that acts as a serving base station, for example. The embodiments described herein are not limited to gNBs and are applicable to any other type of base station.

[0071] For clarity, throughout the embodiments described herein, met conditions, unmet conditions, and configuration(s) condition parameters are described relative to threshold values ​​(e.g., greater than or less than a threshold), configuration values ​​(e.g., thresholds), etc. For example, met conditions may be described as being above a value (e.g., threshold), and unmet conditions may be described as being below a value (e.g., threshold). The embodiments described herein are not limited to threshold-based conditions. Any other kind of conditions and(s) parameters (such as, for example, belonging to or not belonging to a range of values) may be applicable to the embodiments described herein.

[0072] Throughout the embodiments described herein, (e.g., configuration) information can be described as being received by the WTRU from the network, for example, via system information or via any kind of protocol message. Although not explicitly mentioned throughout the embodiments described herein, the same (e.g., configuration) information can be pre-configured in the WTRU (e.g., via any kind of pre-configuration method, such as, for example, via factory settings) so that this (e.g., configuration) information can be used by the WTRU without being received from the network.

[0073] Throughout the embodiments described herein, the statement "the WTRU may be configured with a set of parameters" is equivalent to "the WTRU may (e.g., from another network element (e.g., a gNB)) receive configuration information indicating a set of parameters" or can be used interchangeably therewith. Throughout the embodiments described herein, the statements "the WTRU may report something" and "the WTRU may be configured to report something" are equivalent to "the WTRU may transmit (e.g., report) information indicating something" or can be used interchangeably therewith.

[0074] In the embodiments described herein, 'a' and 'one', as well as similar phrases, are interpreted as 'one or more' and 'at least one'. Similarly, any term ending with the suffix '(one or more)' will be interpreted as 'one or more' and 'at least one'. The term 'may' is to be interpreted as 'can, for example'.

[0075] The symbol ' / ' (e.g., a forward slash) can be used in this article to represent 'and / or', where, for example, 'A / B' can imply 'A and / or B'.

[0076] In the embodiments described herein, a network element can refer to any kind of device that includes computing resources and networking capabilities and can be connected to a network. The terms "node" and "network element" are used interchangeably. A network element can be any kind of network infrastructure device and / or WTRU. Figure 1B The architecture described for WTRU 102 can be applied more generally to any kind of network element.

[0077] This document describes an example of synchronizing sensing operations and connectivity management states for sensor fusion. In one embodiment, an Integrated Sensing Function (ISF) network element is described.

[0078] In one example, ISF network elements can trigger synchronous sensing (e.g., sensing fusion).

[0079] In one example, an ISF network element can send a notification to a 5GC (e.g., an AMF) to inform (e.g., indicate) (e.g., anticipate) sensing tasks and related services.

[0080] In one example, an ISF network element can receive a perception request message from a WTRU. The perception request message can indicate whether synchronous perception (e.g., perception fusion) can be requested (e.g., required) and / or the type of fusion requested (e.g., required). The perception request message can also indicate whether the sensor node can support synchronization messages.

[0081] In one example, an ISF network element can send a Sensing Request Acceptance message to the WTRU. The Sensing Request Acceptance message (e.g., also) can indicate that any sensor fusion and synchronization can be supported.

[0082] In one example, an ISF network element can determine that a synchronization notification message can be sent to the node associated with the sensing task (e.g., any one of a RAN node, fusion node, or sensor node). This determination can take into account (e.g., it can be based on) sensor requests that can be received from either the WTRU or the Application Function / Application Server (AF / AS).

[0083] In one example, an ISF network element can send a synchronization message to either the sensor node or the fusion node. The synchronization message can include configuration information related to the synchronization of the sensing task.

[0084] In one embodiment, this document describes a WTRU.

[0085] In one example, the WTRU can send a perception request message to an ISF network element. The perception request message can specify (e.g., indicate) that synchronous perception (e.g., perception fusion) can be requested (e.g., require) and / or the requested (e.g., require) type of fusion. The perception request message can indicate that the sensor node can support synchronization messages.

[0086] In one example, the WTRU can receive a Sensing Request Acceptance message from an ISF network element. The Sensing Request Acceptance message (e.g., also) can indicate that sensor fusion and synchronization can be supported.

[0087] In one example, the WTRU can receive synchronization messages from the network. These synchronization messages may include configuration information related to the synchronization of the sensing task.

[0088] In one example, WTRU can update (e.g., locally) synchronization-related configurations based on received (e.g., configuration) information (e.g., synchronization information can be updated locally).

[0089] In one example, WTRU can perform sensing tasks and collect sensing data.

[0090] In one example, the WTRU can receive the sensing data to be fused at either the Uu reference point or the PC5 reference point.

[0091] In one example, the WTRU can perform sensor fusion. After generating the fusion result, it can be sent to a network (e.g., ISF).

[0092] This article describes a reference model for 5G networks.

[0093] Figure 2 This is a diagram illustrating an example architecture for 5G / next-generation networks.

[0094] RAN 21 can refer to a radio access network based on 5G Radio Access Technology (RAT) or evolved E-UTRA (which can connect to the next-generation core network).

[0095] Access control and mobility management functions (AMF) 22 may include any one of registration management, connection management, reachability management, mobility management, etc.

[0096] Session management function (SMF) 23 may include any of the following: session management (including any of session establishment, modification and release), WTRU Internet Protocol (IP) address allocation, selection and control of user plane (UP) functions, etc.

[0097] User plane functions (UPF) 24 may include any of the following: packet routing & forwarding, packet inspection, service usage reporting, etc.

[0098] In the embodiments described herein, the terms RAN node, gNodeB, base station, access network (AN), NG-RAN, and RAN are used interchangeably.

[0099] In the embodiments described herein, the term "Uu reference point" may be used to refer to the uplink / downlink between the WTRU and the gNB.

[0100] In the embodiments described herein, the term "PC5" may refer to a reference point that the WTRU can (e.g., directly) communicate with another WTRU via, for example, a side link.

[0101] This article describes an example of integrated perception.

[0102] The 3GPP Technical Specification (TS) 22.837 v19.0.0, titled "Study on Integrated Sensing and Communication," describes integrated sensing use cases and potential requirements for 5G system enhancements. Such enhancements can provide sensing services for different target vertical sectors / applications (e.g., autonomous / assisted driving, vehicle-to-everything (V2X), unmanned aerial vehicles (UAVs), 3D mapping, smart cities, smart homes, factories, healthcare, maritime sectors, etc.).

[0103] For integrated sensing, there may be a process for collecting sensing measurement data, which may include data on radio / wireless signals of the object of interest and / or environmental influences (e.g., any one of reflection, refraction, diffraction) collected for sensing purposes and to derive sensing results from the processing of the sensing measurement data. There may be areas defined for sensing, sensing service area locations, which may be areas where the 5G system can provide sensing services with (e.g., specific) quality, with or without obstacles.

[0104] Other non-3GPP (N3GPP) entities could be considered. That sensed measurement data could be considered transparent to the 5G system (5GS), allowing that data to be transmitted to the interface defined by 5GS using protocols.

[0105] One use case for integration awareness can be object detection.

[0106] Figure 3 This is an illustration of an example, such as pedestrian / animal intrusion detection on a highway.

[0107] Figure 4 This is a diagram illustrating an example of intruder detection, such as in a smart home environment.

[0108] In these examples, the RAN node / BS and / or WTRU can detect intrusions on the base station's sensing area either on its own (e.g., by itself) or through cooperation (e.g., interaction) between the WTRU and the base station (BS). Sensing measurements can be transmitted (e.g., broadcast) to the network and further processed into sensing results.

[0109] Transparent sensing can be another example of integrated sensing (e.g., use cases). In transparent sensing, sensing data can be captured and communicated by the WTRU, allowing the 5GS to be aware of the sensing information.

[0110] In this scenario, the WTRU can acquire sensing signals from either 3GPP or non-3GPP equipment. In one example, the 5GC can determine various available sensing services by processing the compiled sensing data.

[0111] Different perception modes can be used.

[0112] Figure 5 These are diagrams illustrating two examples of sensing modes. In a first mode 51, which can be called single-station sensing, the sensing signal transmitter and the sensing signal receiver can be the same node. In a second mode 52, which can be called dual-station sensing, the sensing signal transmitter and the sensing signal receiver can be two different nodes (e.g., included in two different nodes).

[0113] This article describes sensor fusion.

[0114] Figure 6 This is a diagram illustrating an example of sensor fusion classification based on data source. One classification of sensor fusion techniques can be based on how sensor data sources can be used for data fusion.

[0115] In complementary fusion, the information provided by the input source can represent different parts of the scene and can be used to obtain more complete global information.

[0116] In redundant fusion, two or more input sources can provide information about the same target and can be fused to increase confidence.

[0117] In collaborative fusion, provided information can be combined into new information, which can be, for example, more complex than the original information. For instance, multimodal (audio and video) data fusion can be considered collaborative.

[0118] Sensor fusion types can be categorized based on the architectures described in this article. Another classification of sensor fusion technologies can be based on the architectures used in distributed systems.

[0119] Figure 7A and Figure 7B These are two diagrams illustrating an example of architecture-based sensor fusion classification.

[0120] In distributed convergence, (for example, each) node can have its own processing capabilities and there may be no single point of data fusion.

[0121] In a distributed architecture, measurements from (e.g., each) source node can be processed independently before the information can be sent to the fusion node.

[0122] A layered architecture can be another architecture that combines distributed and decentralized nodes to generate a layered scheme, in which the data fusion process can be performed at different levels in the layered structure.

[0123] Sensor fusion types can be categorized based on the intermediate steps described in this paper. Sensor fusion techniques can be classified based on the different levels of intermediate steps used in generating the fused results.

[0124] Figure 8 This is a diagram illustrating an example of sensor fusion classification based on intermediate steps.

[0125] This article describes the PDU set header fields.

[0126] Nokia's S4-231026, "pCR of TS 26.522 on PDU Set HE, a study on architectural enhancements for XR and Media Services Phase 2," describes header fields that can be associated with a PDU set. The PDU Set Serial Number (PSSN) can be defined as a header field that encodes the sequence number of the PDU set to which (e.g., the current PDU) may belong, acting as a ten-bit numeric identifier for the PDU set.

[0127] Current systems may not be able to achieve the synchronized device functionality described herein. Multiple data sources / sensors can be used to sense the same environment. In one example, data from sensors can be combined (fused) in a way that makes the sensing results understandable. For example, in complementary sensor fusion, each sensor node can sense (e.g., only sense) a partial view of the scene containing different features (e.g., the whole). In another example, in cooperative fusion, sensing data from different modes can be combined into (e.g., new) information that may be more complex than the original information (e.g., may include more information). In one example, to combine different streams into a fusion result, any of the sensing processes, components, and procedures can be synchronized to (e.g., be able to) identify (e.g., correctly and effectively) the interrelated (e.g., temporally) data from different sensor streams. Available 3GPP systems may not be able to achieve sensor fusion and procedures on synchronized devices.

[0128] As described in this article, current systems may not be able to synchronize sensing and fusion tasks across multiple nodes. In one example, sensor traffic can be processed across nodes that may belong to the same sensing task and can be synchronized. If the internal reference clocks, timers, and the data itself are not synchronized, there is a risk that the traffic transmitted for fusion and / or the fusion results may be incomprehensible and / or useless. This could stem from the loss of relevant (e.g., time) information in different sensor streams. Current 3GPP systems do not provide procedures for synchronizing sensing operations involving multiple nodes that may belong to the same sensing task.

[0129] The embodiments described herein can allow for the synchronization of relevant information and sensing operations across multiple nodes.

[0130] Perception capabilities allow, for example, the independent use of various sensors to perceive various properties of physical objects or environments (such as, for example, position, velocity, or orientation).

[0131] Throughout the embodiments described herein, an entity with local sensing capabilities (e.g., a network element) may be referred to as a sensing node, a sensing entity, a sensor, and a WTRU (e.g., if the sensor is associated with a WTRU).

[0132] Sensor fusion can have limitations in sensing mechanisms (hardware and algorithm / software), such as limited coverage (e.g., sensing nodes may have coverage limitations), single dimension / modality (e.g., a sensor may use (e.g., only) a single modality to sense at (e.g., given) time - e.g., video, audio), limited confidence improvement (e.g., the confidence level of the results a sensor may have produced may be limited to its own data), basic information level of the sensed object, or incomplete / limited information (e.g., a sensor may not be able to sense (e.g., all) attributes of an object with high confidence).

[0133] The embodiments described herein can allow data from multiple (capable) different sensors to achieve (e.g., ultimately) generate a more complete perception result.

[0134] Figure 9 This is a diagram illustrating an example use case of sensor fusion. Figure 9 Two scenarios are illustrated where multiple sensing nodes can be used to sense a target object 900. In one example, the attributes available at each sensor node (such as any one of orientation, azimuth, position, and sensing capability, such as sensing frequency) can differ. In another example, the characteristics of the data being collected on the target object (such as shape, distance) can differ. For example, to obtain a more complete result for the target object, the data collected from the sensor nodes can be fused. In the first example shown at 90A, partial sensor results for each sensor node can be collected at network 90 and fused at network 90. ​​In the second example shown at 90B, sensor fusion can be performed at sensor node 91 before sending the final fused result to network 90.

[0135] This paper describes sensing features. Sensing features can refer to the physical characteristics and / or attributes of a sensing target (e.g., an object, an environment), which can be reflected in sensing data. The features and attributes sensed by a sensor node can change depending on various factors associated with the same sensing target. For example, the position of the sensor node relative to the sensing target can determine which parts of the sensing object are visible to the sensor and which parts are hidden. In one example, (e.g., only) a portion of the object's features can be detected by the sensor.

[0136] Features that can be reflected in the sensing data can (e.g., also) vary based on the sensing capabilities of the sensor nodes. For example, two sensor nodes can be placed in the same location relative to a target object. The first sensor can be a radio sensor that can (e.g., accurately) sense the material used on the surface of the target object, and the second sensor can be a lidar sensor that can (e.g., accurately) sense the relative distance between the second sensor and the target object.

[0137] Throughout the embodiments described herein, nodes that can use local awareness capabilities for sensing are referred to as any of a sensing node, a sensing WTRU, and a sensing RAN node. These nodes may be (e.g., may include) WTRUs. These nodes may be (e.g., may include) RAN nodes, or a combination of WTRUs and RAN nodes.

[0138] Throughout the embodiments described herein, the fusion unit can be any of a sensing node, a WTRU, and a RAN node.

[0139] Throughout the embodiments described herein, the terms “synchronization notification message,” “synchronization message,” and “synchronization information” are used interchangeably to refer to any information / message that can be used for synchronization purposes.

[0140] Throughout the embodiments described herein, the terms "sensing request acceptance message," "sensing acceptance message," and "sensing response message" are used interchangeably.

[0141] This article describes architectural considerations and awareness functions.

[0142] This document describes (e.g., new) functions in 5GS that can assist in the management and coordination of sensing operations. Logical functions (which may be collectively referred to herein as Integrated Sensing Functions (ISFs)) can be viewed as a collection of functions that can be implemented in parallel within a single function (e.g., a network element), or as a separate function (e.g., a network element). For example, an ISF can be co-located with any of the Network Exposure Function (NEF), AMF, SMF, and RAN. In scenarios where the ISF may not be trusted by 5GS, it can communicate with the CN function via the NEF and can function similarly to an AF or AS.

[0143] ISF may be able to receive and / or store storage requests and can identify any sensing capabilities in 5G, WTRU (Sense Node), or non-3GPP sensing capabilities that can meet those requirements. Based on these capabilities, it can communicate with other network functions.

[0144] This article describes the various capabilities of the ISF.

[0145] This article describes the synchronization of sensing operations and connection management states.

[0146] Figure 10 This is a diagram illustrating an example method for synchronizing sensing operations.

[0147] The processes shown at 1010 and 1020 can occur before (e.g., the actual sensing task can be triggered), as shown at 1030. The process shown at 1010 can be viewed as triggering the initialization of sensing resources (e.g., any sensing entity, network entity).

[0148] As shown at 1010, ISF can trigger synchronous sensing (e.g., sensory fusion). Triggering can be based on any combination of the following two examples.

[0149] In the first example, the trigger can be based on a request for network optimization (e.g., a need) (e.g., to reduce bandwidth utilization in the network or on the air interface). This request can be received from any of the AMF, SMF, or NF that can hold network analysis functions such as Network Data Analysis Functions (NWDAF).

[0150] In the second example, triggering can be based on a received perception request with perception parameters (e.g., requirements). Such parameters (e.g., requirements) can indicate whether sensor fusion can be requested (e.g., required). In another example, the ISF can determine that sensor fusion may be necessary (e.g., sensor fusion needs to be performed). For example, the ISF can determine that sensor fusion can be synchronized to (e.g., a certain) level. This can be indicated as a value (e.g., latency value / range) and / or category (low, medium, high).

[0151] The sensing task initialization trigger shown at 1010 may include configuring the RAN and participating in the WTRU with configuration information such as a QoS profile for processing the sensing flow, any processing performed by the node before transmitting sensing data, and any markings performed on the data or on data packets carrying the data (e.g., indicating one of the QoS profiles for processing the sensing flow, any processing performed by the node before transmitting sensing data, or any markings performed on the data or on data packets carrying the data). This configuration information may include any synchronization parameters (e.g., requirements), such as, for example, delay requirements between interrelated data in two or more flows.

[0152] As shown at 1020, the ISF can send configuration information (e.g., in one or more notification / configuration messages) to 5GC (e.g., AMF) and / or sensing entities (WTRU and / or fusion network elements) to notify any anticipated sensing tasks and related services (e.g., associated with sensing tasks).

[0153] One or more notification / configuration messages may include timing information to inform the AMF when service can be anticipated. The timing information may be indicated as a timer and / or a time value. The timing information may be derived based on when a sensing task is intended to be performed at the sensor node (it itself may be indicated as (e.g., a second) timer and / or (e.g., a second) time value). For example, the timing information included in a notification / configuration message may indicate the time period during which service associated with a sensing task may be anticipated.

[0154] In one example, the AMF may send a request to the RAN (e.g., including information indicating that it may be part of the same sensing task) to page nodes that may be part of the same sensing task (e.g., the request includes information indicating that it may be paged nodes that may be part of the same sensing task). This request may be sent by the AMF to the RAN as a configuration message, which may have already been received by the AMF from the SMF and forwarded to the RAN. In some examples, the AMF may be able to delay paged nodes until the start time of the expected service is likely to be received at the RAN. In one example, the start time may be indicated in a request (e.g., a configuration message) that the AMF may send to the RAN.

[0155] Configuration messages can configure the RAN to send (e.g., received) synchronization notifications to the WTRU. The RAN can send the synchronization notifications as Radio Resource Control (RRC) messages to the WTRU. In one example, the RAN can be configured by the core network (e.g., SMF) to send synchronization notifications based on any of the following: a clock value, a timer, a trigger message received from the NF in the control plane, and a signal received in the user plane (e.g., a header value).

[0156] Configuration messages can configure participant WTRUs (and / or fusion network elements) with configuration information (e.g., required) for a sensing task (e.g., associated with the sensing task). Configuration information may include (e.g., indicating any one of) (i) the sensor devices to be used, (ii) location information associated with the sensing target, and (iii) time information associated with the sensing task. Any piece of configuration information may be sent to any of the participant WTRU, fusion network element, AMF, and RAN. Configuration information may not be limited to the multiple pieces of information described.

[0157] In one example, the first piece of information that can be included in the configuration information may indicate the sensor device to be used. For example, the WTRU may accommodate more than one sensor device. This may include the sensor configuration to be used (such as, for example, the frequency of the sensing signal, dual-station and single-station configurations, etc.).

[0158] In one example, the second piece of information that can be included in the configuration information may include either the location information or the orientation information of the perceived target (e.g., a billboard).

[0159] In one example, a third piece of information that can be included in the configuration information can indicate the time when the sensing task may be performed (such as, for example, any of the following: start time and end time, duration, period, etc.). For example, the configuration information can indicate a time trigger, such as to trigger a WTRU to perform the sensing task.

[0160] In one example, the network can be configured with WTRUs for sensing tasks to help 5G systems improve beamforming.

[0161] For example, a configuration message that can be sent by either the ISF or the SMF may include (e.g., an indication) a time trigger. For example, a sensor may be configured to wake up at (e.g., a certain) time.

[0162] As shown at 1030, a sensor node can send a perception request message 1031 to the ISF (e.g., via the AMF). The perception request message 1031 can be sent as a Non-Access Stratum (NAS) message (e.g., included within a NAS message) and can include perception service parameters (e.g., requests). The perception request message 1031 can include information indicating that synchronous perception (e.g., perception fusion) and / or (e.g., requested, required) fusion type can be requested (e.g., demanded). In one example, the WTRU can (e.g., be triggered) send the request based on any of (e.g., a pre-configured) time trigger, a message received by the Network Function (NF), and a message received from the fusion node.

[0163] In the first example, the WTRU can (e.g., be triggered) send a request via a pre-configured time trigger. For example, a sensor can be configured to wake up at (e.g., a certain) time (e.g., after (e.g., a configurable) amount of time has elapsed).

[0164] In the second example, the WTRU can (e.g., be triggered) send a request via a message (e.g., a message received from it) from one of the NFs such as, for example, AMF, ISF, AS, and RAN. For example, a sensor can send a sensing request message 1031 after knowing that the RAN can support sensing.

[0165] In the third example, the WTRU can (e.g., be triggered) send a request via a message from the fusion node (e.g., received from the fusion node). For example, after receiving a message from the fusion node indicating (e.g., instructing) to perform a sensing task, the sensor node can send a sensing request message 1031.

[0166] The perception request message 1031 can indicate that the perception task can expect (e.g., can request) a result that can be synchronized with (e.g., a certain) level. This can be indicated as either a value (e.g., a delay value / range) or a category (low, medium, high).

[0167] The perception request message 1031 can indicate, for example, that a sensor node can support a synchronization message from the network. In another example, the perception request message 1031 can request synchronization support from the network (e.g., it can indicate that synchronization support can be requested).

[0168] In one example, the ISF can send a Sensing Request Acceptance Message 1040 to the WTRU. The Sensing Request Acceptance Message 1040 (e.g., also) can indicate that sensor fusion can be supported.

[0169] The perception request acceptance message 1040 may indicate that the network can assist in the synchronization of the perception task, and includes (e.g., indicating) perception synchronization capabilities (e.g., it may indicate that the network may be able to support (e.g., certain, specific) application or service synchronization, which may also indicate the synchronization accuracy and / or precision information that can be supported). In one example, the perception request acceptance message 1040 may indicate that the network can send a synchronization notification message (e.g., individually or during task execution).

[0170] As shown at 1050, the ISF can determine that the synchronization notification message 1060 can (e.g., needs) be sent to the node associated with the sensing task (e.g., any one of the RAN node, fusion node, and sensor node). In one example, the determination to send the synchronization notification message 1060 may be based on a sensing request message 1031 that may have already been received from the WTRU and / or AF / AS. In another example, the determination to send the synchronization notification message 1060 may be based on information received from another NF (e.g., subscriber information).

[0171] The determination to send the synchronization notification message 1060 can also be based on analysis. In one example, a network function (e.g., NWDAF) can determine (e.g., due to clock drift) that the sensed data to be received may be out of sync and / or the sensor fusion task may not have started, restarted, or updated synchronously. For example, the ISF can determine that a notification message with (e.g., including) synchronization information 1060 (e.g., indicating that a clock start / update has been triggered) can be sent to the node. In another example, the NWDAF can notify the ISF that the sensed service may be consuming more bandwidth than the required level and / or may be causing additional latency. In one example, the ISF can decide (e.g., determine) that fusion can be performed before data is received in the network.

[0172] The information included in the synchronization notification message 1060 (e.g., configuration information) may include any one of the following: (i) information about the updated reference clock, (ii) a timer for initiating a sensing task, (iii) a timer for initiating sensor fusion, (iv) an indication of whether connection management (CM) state coordination can be enabled (as described herein), and (v) information about CM state coordination.

[0173] In one example, updated reference clock information can be included in synchronization notification message 1060. For example, sensor devices can be updated with reference clock information hosted in the fusion node, and clock synchronization messages such as clock start triggers (e.g., clock start triggers—triggers sent by the master clock to other clocks to start in phase) can be exchanged via proximity-based service (ProSe) communication.

[0174] In one example, information regarding CM state coordination can be included in the synchronization notification message. For instance, this information could indicate that a sensor node can wake up in a connected state (e.g., CM-CONNECTED), such as when a synchronization timer (e.g., a sensing timer, a timer that initiates a sensing task) might stop (e.g., expire). Information regarding CM state coordination can include any of the following: (i) the CM state change trigger and conditions (e.g., time or timer), (ii) the CM state to be changed, and (iii) the CM state to which the change originates.

[0175] In the first example shown at 1065, the ISF may send a synchronization message 1061 (e.g., a first) to either the sensor node or the fusion node. In the second example shown at 1066, the RAN node may send a synchronization message 1062 (based on received configuration information as shown at 1020) to (e.g., sensor and / or fusion) nodes. Synchronization messages 1060, 1061, and 1062 may include configuration information related to the synchronization of the sensing task, such as any of the following: (i) information on an updated reference clock, (ii) a timer for initiating the sensing task, (iii) a timer for initiating sensor fusion, (iv) an indication of whether CM state coordination can be enabled (as described herein), and (v) information regarding CM state coordination, as described herein.

[0176] As shown at 1071 and 1072, sensor nodes and fusion nodes can update their configurations based on information received in synchronization messages 1060, 1061, and 1062. For example, any sensor node and fusion node can update synchronization information, for instance, locally based on configuration information received in the synchronization message.

[0177] (Sensor / fusion) nodes can use the information received in synchronization messages 1060, 1061, and 1062 for power-saving procedures. For example, computing and / or communication resources can be placed in idle mode before sensing can be initiated and can be activated before (e.g., sensing) timers may expire. This (also) can, for example, allow for reduction of any latency caused by the time spent changing states, allocating, and preparing resources.

[0178] If other devices are tethered to these nodes, the information received in synchronization messages 1060, 1061, and 1062 can be used to manage the tethered connectivity (e.g., activating the tethered connectivity when a timer may expire (e.g., afterward).

[0179] As shown at 1080, the sensor node can perform sensing tasks and collect sensing data.

[0180] In one example, the sensor node can send sensing data 1090 to the fusion node for fusion. In one example, the sensing data 1090 can be sent via either the Uu reference point (e.g., the interface) or the PC5 reference point (e.g., the interface).

[0181] As shown at 1091, the fusion node can perform sensor fusion and can generate a fusion result (e.g., based on sensing data 1090 received from one or more sensing devices, and sensing data generated locally, for example). After generation, the fusion result (e.g., data) 1092 can be sent to the network.

[0182] Sensing data can be received by any of the AF, AS, ISF, NF and another WTRU (via sidelink communication and / or via RAN / CN).

[0183] In some examples, intermediate nodes (e.g., RAN nodes) can consume data before it is received at the destination (e.g., AF / AS, ISF).

[0184] The processing shown at 1060-1092 can be repeated throughout the entire duration of the perception / fusion task execution.

[0185] This article describes the synchronization of CM states.

[0186] In one example, for sensing and fusion tasks that may have low latency expectations (e.g., requirements), changes in service transmission and / or alterations to the connection management state can be anticipated in advance to avoid delays caused by changes in the connection management state (e.g., waking up and receiving sensor data for fusion). Based on knowledge of nodes that may be part of the same sensing task, coordination and / or synchronization of the CM state across (e.g., all) nodes can be performed.

[0187] (For example, even if) one or more WTRUs do not receive this flow, these one or more WTRUs can be removed from the idle (e.g., CM-IDLE) state. If multiple nodes (e.g., any of the sensor nodes or fusion nodes) are used for the same sensing task, there may be instances where some sensor nodes may not send or receive data (either sensing signals or data signals). It may be beneficial for those nodes to be prepared to send or receive signals. For example, not all sensor nodes can perform sensing simultaneously, and changing the CM state (e.g., from CM-IDLE to CM-CONNECTED) in anticipation of upcoming data transmission may be useful. In another example, after a sensing task, the fusion node may not receive data from other sensor nodes (e.g., directly) because there may be (e.g., small) delays in collecting and preprocessing sensing data at the sensor nodes. For example, the fusion node can prepare (e.g., change) the CM state when it anticipates receiving sensing data from other nodes.

[0188] The interface that can coordinate with (e.g., new) state information can also depend on the communication model and architecture assumed by the sensor or fusion task. For example, in Figure 9 In the scenario shown at 90A, the connection state can be updated (e.g., only for the Uu reference point). Figure 9 In the scenario shown at 90B, the state of PC5 connectivity (e.g., also) can be coordinated based on the expected sensor data at fusion node 91.

[0189] It is possible to introduce (one or more) new connection states (e.g., in the future) for use when performing perception tasks (e.g., CM-SENSE-TX CM-SENSE-RX), and those states can be used accordingly.

[0190] This document has described embodiments using examples of CM states, such as CM-IDLE and CM-CONNECTED states. The embodiments described herein are not limited to the described CM state examples. The embodiments described herein can be applied to any other kind of state for any communication stack managing one or more connections.

[0191] Figure 11 This is a diagram illustrating an example method 1100 for synchronization of sensing operations implemented in a WTRU. The WTRU may include circuitry including a transmitter, a receiver, a processor, and memory. The WTRU (e.g., circuitry) may be configured to perform method 1100. As shown at 1110, method 1100 may include sending a sensing request message to a first network element. In various embodiments, the sensing request message may indicate a request for synchronized sensing associated with a sensing task. As shown at 1120, method 1100 may include receiving a sensing acceptance message from the first network element. As shown at 1130, method 1100 may include receiving a synchronization message that includes configuration information associated with the sensing task. As shown at 1140, method 1100 may include updating the synchronization information (e.g., locally) based on the configuration information. As shown at 1150, method 1100 may include performing sensor fusion based on the updated synchronization information. As shown at 1160, method 1100 may include sending the fusion result of the performed sensor fusion to a first network element.

[0192] In various embodiments, the perception request message may indicate either (i) the type of fusion and (ii) support for synchronization messages.

[0193] In various embodiments, the perceived reception message can indicate support for either fusion or synchronization.

[0194] In various embodiments, the method may further include performing a sensing task to collect first sensing data.

[0195] In various embodiments, the method may further include receiving second sensing data to be fused.

[0196] In various embodiments, performing sensor fusion may include fusing first sensing data and second sensing data.

[0197] In various embodiments, the method may further include receiving configuration information indicating any one of (i) the sensor to be used, (ii) the location of the target to be sensed, (iii) the orientation of the target to be sensed, and a time trigger for performing the sensing task.

[0198] In various embodiments, sending a sense request message may include triggering the WTRU to send the sense request message based on time triggering.

[0199] In various embodiments, synchronization messages can be received from the first network element.

[0200] In various embodiments, the first network element may include integrated sensing capabilities.

[0201] Figure 12 This is a diagram illustrating an example method 1200 for synchronizing sensing operations implemented in a network element. The network element may include circuitry comprising a transmitter, a receiver, a processor, and memory. A WTRU (e.g., circuitry) may be configured to perform method 1200. As shown at 1210, method 1200 may include receiving a sensing request message from the WTRU. In various embodiments, the sensing request message may indicate a request for synchronized sensing associated with a sensing task. As shown at 1220, method 1200 may include sending a sensing acceptance message to the WTRU. As shown at 1230, method 1200 may include sending a synchronization message. In various embodiments, the synchronization message may include configuration information associated with the synchronization of the sensing task.

[0202] In various embodiments, the perception request message may indicate either (i) the type of fusion and (ii) support for synchronization messages.

[0203] In various embodiments, the perceived reception message can indicate support for either fusion or synchronization.

[0204] In various embodiments, the method may further include sending a notification associated with the sensing task.

[0205] In various embodiments, the notification can be sent to the AMF network element.

[0206] In various embodiments, the notification may indicate any one of a sensing task, a service associated with the sensing task, or an indication of when the service associated with the sensing task may be expected.

[0207] In various embodiments, the notification can be sent to the WTRU.

[0208] In various embodiments, the notification may indicate any of (i) the sensor to be used, (ii) the location of the target to be sensed, (iii) the direction of the target to be sensed, and a time trigger for performing the sensing task (e.g., triggering the WTRU to perform the sensing task).

[0209] In various embodiments, synchronization messages can be sent to any of the WTRU, sensor network elements, and fusion network elements.

[0210] In various embodiments, network elements may include integrated sensing capabilities.

[0211] Although not explicitly described, the embodiments described herein can be employed in any combination or sub-combination. For example, the principles are not limited to the described variations, and any arrangement of variations and embodiments can be used.

[0212] Furthermore, any features, variations, or embodiments described for the method are compatible with apparatus devices including means for processing the disclosed method, compatible with devices including circuitry comprising any one of a transmitter, receiver, processor, and memory, operable (e.g., configured) to process the disclosed method, compatible with computer program products including program code instructions, and compatible with non-transitory computer-readable storage media that store program instructions.

[0213] Although features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in combination with other features and elements. This disclosure is not limited to the specific embodiments described herein, which are intended to illustrate various aspects. Many modifications and variations can be made without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. No element, action, or instruction used in the description of this application should be construed as critical or essential to the invention unless expressly provided so. Based on the foregoing description, functionally equivalent methods and apparatuses within the scope of this disclosure will be apparent to those skilled in the art, in addition to those methods and apparatuses listed herein. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the terms of the appended claims and the full scope of equivalents thereof. It should be understood that this disclosure is not limited to specific methods or systems.

[0214] For simplicity, the foregoing embodiments are discussed in terms of the terminology and structure of devices with infrared capabilities (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0215] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" can refer to any of a snapshot, a single image, and / or multiple images displayed on a time-based basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE," the term "remote," and / or the term "head-mounted display" and its abbreviation "HMD" can mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of several embodiments of a WTRU; (iii) a device particularly configured with some or all of the constructs and functions of a WTRU and having wireless and / or wired capabilities (e.g., tetherable); (iv) a device configured with fewer than all the constructs and functions of a WTRU and having wireless and / or wired capabilities; or (iv) something like that. Figure 1A-1D Details of an example WTRU, which may represent any WTRU described herein, are provided. As another example, the various embodiments disclosed above and below are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be utilized, and some or all of this disclosure and the various disclosed embodiments can be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adaptive, realistic experience.

[0216] Furthermore, the methods provided herein can be implemented in computer programs, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROMs and digital multifunction discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0217] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the appended claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery, etc.) providing any suitable voltage.

[0218] Furthermore, in the embodiments provided above, a processing platform, computing system, controller, and other devices, including a processor, are mentioned. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be executed by various CPUs and memories. Such actions and operations or instructions may be referred to as being “executed,” “computer-executed,” or “CPU-executed.”

[0219] Those skilled in the art will understand that the actions and symbols representing operations or instructions include the CPU's manipulation of electrical signals. Electrical systems represent data bits that can cause a final transformation or reduction of electrical signals, and data bits are maintained in memory locations within memory systems, thereby reconfiguring or otherwise altering the CPU's operation and other signal processing. The memory location maintaining the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the provided methods.

[0220] Data bits can also be maintained on a computer-readable medium, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system. The computer-readable medium can include cooperative or interconnected computer-readable media that reside exclusively on the processing system or are distributed across multiple interconnected processing systems, which may be local or remote within the processing system. It should be understood that the embodiments are not limited to the above-described memories, and other platforms and memories may support the provided methods.

[0221] In the illustrative embodiments, any of the operations, processes, etc., described herein can be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions can be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0222] There is little difference between the hardware and software implementations of the various aspects of the system. The use of hardware or software is often (but not always, as the choice between hardware and software may become important in certain contexts) a design choice representing a cost-efficiency trade-off. Various means can exist to implement the processes and / or systems and / or other technologies described herein (e.g., hardware, software, and / or firmware), and the preferred means can vary depending on the context of the deployment of the processes and / or systems and / or other technologies. For example, if the implementer determines that speed and accuracy are of paramount importance, the implementer may choose a primarily hardware and / or firmware approach. If flexibility is of paramount importance, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0223] The foregoing detailed description has illustrated various embodiments of the apparatus and / or processes using block diagrams, flowcharts, and / or examples. Within the scope of such block diagrams, flowcharts, and / or examples encompassing one or more functions and / or operations, those skilled in the art will understand that each function and / or operation in such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide variety of hardware, software, firmware, or virtually any combination thereof. In one embodiment, several portions of the subject matter described herein can be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be implemented, in whole or in part, equivalently in an integrated circuit, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing circuitry and / or writing code for software and / or firmware in accordance with this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein can be distributed as a program product in various forms, and that the illustrative embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media, such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc.; and transmission media, such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0224] Those skilled in the art will recognize that it is common practice in the art to describe devices and / or processes in the manner set forth herein, and subsequently integrate such described devices and / or processes into data processing systems using engineering practice. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable number of experiments. Those skilled in the art will recognize that a typical data processing system typically includes one or more of the following: a system unit housing, a video display device, a memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, drivers, a graphical user interface and applications, one or more interactive devices such as a touchpad or screen, and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or speed, control motors for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0225] The topics described herein sometimes illustrate different components included within or connected to other components. It should be understood that the architectures depicted are merely examples, and many other architectures can indeed be implemented to achieve the same functionality. Conceptually, any arrangement of components that achieve the same functionality is effectively “associated” to achieve the desired functionality. Therefore, any two components combined in this document to achieve a particular function can be considered “associated” with each other to achieve the desired functionality, regardless of the architecture or intermediate components. Similarly, any two components so associated can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be so associated can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of operational coupling include, but are not limited to, physically matable and / or physically interactive components and / or wirelessly interactive components and / or logically interactive components.

[0226] Regarding the use of virtually any plural and / or singular terms in this document, those skilled in the art may appropriately translate from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural arrangements may be explicitly described herein.

[0227] Those skilled in the art will understand that, generally, the terminology used herein, and especially in the appended claims (e.g., the body of the appended claims), is generally intended as “open” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “at least having,” the term “comprising” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will further understand that if the intent is to describe a specific number of items in the appended claims, such intent will be explicitly detailed in the claims, and if no such description is provided, such intent does not exist. For example, the term “single” or similar language may be used where the intent is to describe only one item. To aid understanding, the appended claims and / or the description herein may include the use of introductory phrases “at least one” and “one or more” to introduce the description of the claims. However, the use of such phrases should not be construed as implying that a claim recitation introduced by the indefinite article "a" or "an" limits any particular claim to include only one such recitation, even when the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "an" or "a" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce a claim recitation. Furthermore, even if the specific number of recitations in an introduced claim is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the number of recitations (e.g., the simple statement "two recitations" without other modifiers means at least two recitations, or two or more recitations). Furthermore, in cases where conventions such as "at least one of A, B, and C" are used, generally, such a construction is intended to be based on the meaning of the convention as would be understood by a person skilled in the art (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In cases where conventions such as "at least one of A, B, or C" are used, generally, such a construction is intended to be based on the meaning of the convention as would be understood by a person skilled in the art (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Those skilled in the art will further understand that any transition words and / or phrases that actually represent two or more alternative terms, whether in the specification, claims, or drawings, should be understood to imply the possibility of including one, any, or both terms.For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”. Furthermore, as used herein, the term “any one of…” following a list of multiple items and / or multiple item categories is intended to include, alone or in combination with other items and / or other item categories, “any one,” “any combination,” “any multiple,” and / or “any combination of multiples.” Furthermore, as used herein, the term “set” is intended to include any number of items, including zero. Furthermore, as used herein, the term “quantity” is intended to include any number, including zero. And as used herein, the term “multiple” is intended to be synonymous with “multiple.”

[0228] Furthermore, in cases where features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is therefore also described in accordance with any individual member of the Markush Group or a subgroup of its members.

[0229] As those skilled in the art will understand, for any and all purposes, such as for providing a written description, all scopes disclosed herein also include any and all possible subscopes and combinations thereof. Any listed scope can be readily considered sufficiently descriptive and makes it possible to decompose the same scope into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily decomposed into a lower third, a middle third, and an upper third, etc. Those skilled in the art will also understand that all language (such as “up to,” “at least,” “greater than,” “less than,” etc.) includes the stated numbers and refers to a scope that can subsequently be decomposed into subscopes as discussed above. Finally, as those skilled in the art will understand, a scope includes each individual member. Thus, for example, a group having 1-3 subscopes refers to a group having 1, 2, or 3 subscopes. Similarly, a group having 1-5 subscopes refers to a group having 1, 2, 3, 4, or 5 subscopes, and so on.

[0230] Furthermore, the claims should not be construed as being limited to the provided order or elements unless expressly stated otherwise. Additionally, the use of the term "means for..." in any claim is intended to refer to... The claim format is either device plus function, and any claim without the term "device for..." is not intended to be so.

Claims

1. A wireless transmit / receive unit (WTRU) comprising circuitry including any one of a transmitter, a receiver, a processor, and a memory, the wireless transmit / receive unit being configured to: Send a perception request message to the first network element, wherein, The perception request message indicates a request for synchronous perception associated with the perception task; Receive sensing and receiving messages from the first network element; Receive a synchronization message, wherein the synchronization message includes configuration information associated with the sensing task; The synchronization information is updated locally based on the configuration information. Sensor fusion is performed based on updated synchronization information; and The fusion result of the sensor fusion performed is sent to the first network element.

2. The WTRU according to claim 1, wherein, The perception request message indicates either (i) the type of fusion or (ii) support for synchronization messages.

3. The WTRU according to claim 1 or 2, wherein, The perception receiving message indicates support for either fusion or synchronization.

4. The WTRU according to any one of claims 1 to 3, further configured to perform the sensing task to collect first sensing data.

5. The WTRU according to any one of claims 1 to 4 is further configured to receive second sensing data to be fused.

6. The WTRU according to claims 4 and 5, wherein, Being configured to perform sensor fusion includes being configured to fuse the first sensing data and the second sensing data.

7. The WTRU according to any one of claims 1 to 6 is further configured to receive configuration information indicating (i) any one of the following: the sensor to be used, (ii) the location of the sensing target, (iii) the orientation of the sensing target, and a time trigger for performing the sensing task.

8. The WTRU according to claim 7, wherein, The configuration to send the perception request message includes being triggered based on the time trigger to send the perception request message.

9. The WTRU according to any one of claims 1 to 8, wherein, The synchronization message is received from the first network element.

10. The WTRU according to any one of claims 1 to 9, wherein, The first network element includes integrated sensing capabilities.

11. A network element comprising circuitry, said circuitry including any one of a transmitter, a receiver, a processor, and a memory, said network element being configured to: Receive a sensing request message from the wireless transmit / receive unit (WTRU), wherein, The perception request message indicates a request for synchronous perception associated with the perception task; Send a sensing and receiving message to the WTRU; and Send a synchronization message, wherein the synchronization message includes configuration information associated with the synchronization of the sensing task.

12. The network element according to claim 11, wherein, The perception request message indicates either (i) the type of fusion or (ii) support for synchronization messages.

13. The network element according to claim 11 or 12, wherein, The perception receiving message indicates support for either fusion or synchronization.

14. The network element according to any one of claims 11 to 13 is further configured to send a notification associated with the sensing task.

15. The network element according to claim 14, wherein, The notification is sent to the access and mobility management function network element.

16. The network element according to claim 15, wherein, The notification indicates any one of the sensing task, the service associated with the sensing task, or an indication of when the service associated with the sensing task is expected.

17. The network element according to claim 14, wherein, The notification is sent to the WTRU.

18. The network element according to claim 17, wherein, The notification indicates (i) the sensor to be used, (ii) the location of the target to be sensed, (iii) the direction of the target to be sensed, and a time trigger for the WTRU to perform the sensing task.

19. The network element according to any one of claims 11 to 17, wherein, The synchronization message is sent to any one of the WTRU, sensor network element, and fusion network element.

20. The network element according to any one of claims 11 to 19, wherein, The network element includes integrated sensing capabilities.

21. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: Send a perception request message to a first network element, wherein the perception request message indicates a request for synchronous perception associated with the perception task; Receive sensing and receiving messages from the first network element; Receive a synchronization message, wherein the synchronization message includes configuration information associated with the sensing task; The synchronization information is updated locally based on the configuration information. Sensor fusion is performed based on updated synchronization information; and The fusion result of the sensor fusion performed is sent to the first network element.

22. A method implemented in a network element, the method comprising: Receive a sensing request message from a wireless transmit / receive unit (WTRU), wherein the sensing request message indicates a request for synchronous sensing associated with a sensing task; Send a sensing and receiving message to the WTRU; and Send a synchronization message, wherein the synchronization message includes configuration information associated with the synchronization of the sensing task.

Images