Method for ambient power-enabled IoT device positioning in wireless system

Abstract

A wireless transmit / receive unit (WTRU) may establish a connection with an ambient power-enabled Internet of Things (AIoT) device. The WTRU may receive a location update request. For example, the WTRU may receive a location update request from the AIoT device via the connection. The WTRU may send a mobile originating location request (MO-LR). The WTRU may send the MO-LR to the network, such as based on the received location update request. The MO-LR may include an identifier associated with the AIoT device and / or an indication that a location is requested for the AIoT device. The WTRU may determine to perform positioning with respect to the network. The WTRU may perform positioning. For example, with respect to a network, a location of the AIoT device is indicated. The connection may be a side chain connection and / or a backscatter connection.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 63 / 444,332, filed February 9, 2023, the entire contents of which are incorporated herein by reference. Background Art

[0002] Ambient power enabled Internet of Things (IoT) devices can be IoT devices that can collect energy from the environment (e.g., wireless radio waves, motion, vibration, piezoelectricity, solar energy, and wind power, etc.). Ambient power enabled IoT (A_IoT) devices can be battery-free and / or may have limited energy storage (e.g., using capacitors). Ambient power enabled IoT devices can be used in industrial wireless sensor networks where, for example, the environment may be harsh (e.g., extremely high or low temperatures) and / or where the devices may be battery-free, maintenance-free, and / or have a long service life. These devices can additionally or alternatively play an important role in smart logistics and / or smart warehousing. Low cost, small size, battery-free nature, and / or durability may contribute to the suitability of these devices for attachment to a certain amount (e.g., a large amount) of goods, and / or may promote more efficient goods identification, sorting, tracking, and / or inventory. Summary of the Invention

[0003] A wireless transmit / receive unit (WTRU) may be configured to transmit a first WTRU identifier to a second WTRU. The first WTRU may be a positioning partner WTRU (PC_WTRU). The second WTRU may be an ambient power enabled Internet of Things (IoT) (A_IoT) device. The first WTRU may be configured to receive a second WTRU identifier associated with the second WTRU. The second WTRU identifier may be a sidelink identifier that includes a timestamp, a distance between the first WTRU and the second WTRU, and one or more WTRU identifiers (e.g., a permanent equipment identifier (PEI), a 5G-GUTI, a GPSI, an application layer identifier, a service identifier, etc.). The first WTRU may be configured to pair with the second WTRU. The pairing may be based on PC5. For example, the pairing may be based on discovery and / or pairing of PC5. Additionally or alternatively, the pairing may be based on the first WTRU identifier and / or the second WTRU identifier. The first WTRU may be configured to initiate a mobile originated location request (MO-LR) procedure. A MO-LR procedure message may be transmitted based on the MO-LR procedure. For example, a MO-LR request message (e.g., a procedure message) may be transmitted to the network based on the MO-LR procedure.

[0004] The first WTRU may be configured to transmit a pairing report message to the network. The pairing report message may be transmitted to a network access and mobility function (AMF). The AMF may be configured to verify the MO-LR procedure. For example, the AMF may be configured to verify the MO-LR procedure based on the pairing report message. The MO-LR procedure may include one or more timestamps. The one or more timestamps may be associated with one or more second WTRUs. The MO-LR procedure may be requested by the second WTRU. The first WTRU may be configured to determine a distance between the first WTRU and the second WTRU. Additionally or alternatively, the first WTRU may be configured to initiate the MO-LR procedure when the distance between the first WTRU and the second WTRU exceeds a threshold. The first WTRU and the second WTRU may be paired via a side link.

[0005] A WTRU (e.g., a positioning partner WTRU) may establish a connection with an A_IoT device. The WTRU may receive a location update request. For example, the WTRU may receive a location update request from the A_IoT device via the connection. The WTRU may send an MO-LR. The WTRU may send the MO-LR to the network, for example, based on the received location update request. The MO-LR may include an identifier associated with the A_IoT device and / or an indication that positioning is requested for the A_IoT device. The WTRU may determine to perform positioning with respect to the network, for example, to indicate that a positioning procedure (e.g., a MO-LR procedure) is associated with (e.g., for) the A_IoT device. The WTRU may perform positioning, for example, with respect to the network, to indicate the location of the A_IoT device. For example, the positioning procedure may enable the network to estimate the location of the A_IoT device (e.g., based on the positioning measurements of the WTRU). The connection may be a sidelink connection and / or a backscatter connection.

[0006] The MO-LR may additionally or alternatively include one or more of a timestamp associated with the communication between the WTRU and the A_IoT device, an estimated distance between the WTRU and the A_IoT device, an application identifier, and / or a service identifier. The WTRU may receive one or more location update requests from multiple A_IoT devices, for example, within a predefined time period. The MO-LR may include an identifier for each of the multiple A_IoT devices. The locations indicated during positioning with respect to the network may be associated with the multiple A_IoT devices.

[0007] The WTRU may send pairing information to the network. The pairing information may indicate that the WTRU includes a positioning partner WTRU and / or that the A_IoT device has delegated location services to the WTRU. The indication that positioning is requested for the A_IoT device may include a positioning partner flag. The WTRU may send a (e.g., second) MO-LR to the network. The (e.g., second) MO-LR may include an estimated distance between the WTRU and the A_IoT device. The estimated distance between the WTRU and the A_IoT may be associated with a threshold. The WTRU may send the (e.g., second) MO-LR to the network based on the estimated distance between the WTRU and the A_IoT device exceeding the threshold. The WTRU may receive a mobile terminated location request (MT-LR), for example, from the network. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0009] Figure 1B is a diagram illustrating an embodiment of a Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is illustrated in FIG.

[0010] Figure 1C is a diagram illustrating an embodiment of a Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) for use within a communication system is illustrated in FIG.

[0011] Figure 1D is a diagram illustrating an embodiment of a Figure 1A A system diagram of a further example RAN and a further example CN for use within the communication system illustrated in FIG.

[0012] Figure 2 is a diagram illustrating an example non-roaming reference architecture for location services in 5G.

[0013] Figure 3 is a diagram illustrating an example high-level process for ambient power enabled Internet of Things (A_IoT) device positioning using a positioning partner WTRU (PC_WTRU).

[0014] Figure 4 is a diagram illustrating an example Mobile Originated Location Request (MO-LR) procedure using a PC_WTRU. DETAILED DESCRIPTION

[0015] Figure 1A1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content (such as voice, data, video, messaging, broadcast, etc.) to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-sOFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0016] like Figure 1A As shown in FIG, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in the context of an industrial and / or automated process chain), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a WTRU.

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

[0018] 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 a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service in a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, one for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

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

[0020] More specifically, as noted above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

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

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

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

[0024] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0025] Figure 1A The base station 114b in the may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. Figure 1A As shown in FIG, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114b may not be required to access the Internet 110 via CN 106 / 115.

[0026] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although Figure 1ANot shown, but it will be appreciated, the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0029] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B , the WTRU 102 may include, among other things, 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 peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the above elements while remaining consistent with an embodiment.

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

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

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

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

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

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

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

[0037] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geo-location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

[0039] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

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

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

[0042] Figure 1C The CN 106 shown in FIG may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the foregoing elements is depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by entities other than the CN operator.

[0043] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for facilitating switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0044] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0045] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0046] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0047] Even though the WTRU Figures 1A to 1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may employ (eg, temporarily or permanently) a wired communication interface with a communication network.

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

[0049] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or an interface with a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS and destined for a STA may arrive through the AP and be delivered to the STA. Traffic from a STA to a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within a BSS may be sent through the AP, for example, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between the source and destination STAs (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

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

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

[0052] Very high throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels or by combining two non-contiguous 80 MHz channels (which can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can be passed through a segment parser that can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed separately on each stream. 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).

[0053] The operating mode below 1 GHz is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to the channel operating bandwidth and carrier used in 802.11n and 802.11ac. 802.11af supports 5 MHz bandwidth, 10 MHz bandwidth and 20 MHz bandwidth in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz bandwidth, 2 MHz bandwidth, 4 MHz bandwidth, 8 MHz bandwidth and 16 MHz bandwidth using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, for example, limited capabilities, including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include batteries whose battery life is above a threshold (e.g., to maintain very long battery life).

[0054] 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 a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for a STA that supports (e.g., only supports) a 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 sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which only supports the 1 MHz operating mode) transmitting to the AP, the entire available frequency band may be considered busy, even if most of the frequency band is still idle and may be available.

[0055] In the United States, 802.11ah can use the available frequency band 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. Depending on the country code, the total available bandwidth for 802.11ah ranges from 6 MHz to 26 MHz.

[0056] Figure 1D 1 is a system diagram illustrating the RAN 113 and the CN 115 in accordance with an embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

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

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

[0059] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without also accessing another RAN (e.g., such as the eNode-Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect to the gNBs 180a, 180b, 180c while also communicating / connecting to another RAN, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRUs 102a, 102b, 102c.

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

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

[0062] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of services utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low-latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

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

[0064] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface. These gNBs may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184a, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0065] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. Additionally, the CN 115 may provide the WTRUs 102a, 102b, 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, the WTRUs 102a, 102b, 102c may be connected to a local data network (DN) 185a, 185b through the UPF 184a, 184b via an N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0066] Given that Figures 1A to 1D as well as Figures 1A to 1D

[0015] As described herein, one or more or all of the functionality described herein with respect to one or more of the following may be performed by one or more emulated devices (not shown) : the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) described herein. The emulated devices may be one or more devices configured to emulate one or more or all of the functionality described herein. For example, the emulated devices may be used to test other devices and / or simulate network and / or WTRU functionality.

[0067] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, the 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 in order to test other devices within the communication network. The 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. The simulation device can be directly coupled to another device for testing purposes and / or can use over-the-air wireless communication to perform testing.

[0068] The one or more simulation devices can perform one or more (including all) functions without being implemented / deployed as a part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test lab and / or in a non-deployed (e.g., test) wired and / or wireless communication network to realize the test of one or more components. The one or more simulation devices can be test equipment. The direct RF coupling and / or wireless communication carried out via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to transmit and / or receive data.

[0069] A wireless transmit / receive unit (WTRU) may be configured to transmit a (e.g., first) WTRU identifier to another (e.g., second) WTRU. The (e.g., first) WTRU may be a positioning partner WTRU (PC_WTRU). The other (e.g., second) WTRU may be an ambient power enabled Internet of Things (IoT) (A_IoT) device. The (e.g., first) WTRU may be configured to receive the other (e.g., second) WTRU identifier. The sidelink identifier may include and / or be associated with one or more of a timestamp, a distance between the (e.g., first) WTRU and the other (e.g., second) WTRU, and / or a WTRU identifier. The WTRU identifier may include and / or be associated with one or more of a permanent equipment identifier (PEI), a 5G-GUTI, a GPSI, an application layer identifier, a service identifier, and the like. The (e.g., first) WTRU may be configured to pair with the other (e.g., second) WTRU. Pairing may include PC5 (e.g., a PC5 interface). For example, pairing may include discovery and / or pairing based on PC5. Additionally or alternatively, pairing may be based on the (e.g., first) WTRU identifier and / or the other (e.g., second) WTRU identifier. The (e.g., first) WTRU may be configured to initiate a Mobile Originated Location Request (MO-LR) procedure. A MO-LR procedure message may be transmitted based on the MO-LR procedure. For example, the MO-LR procedure message may be transmitted to the network based on the MO-LR procedure.

[0070] The (e.g., first) WTRU may be configured to transmit a pairing report message to the network. The pairing report message may be transmitted to a network access and mobility function (AMF). The AMF may be configured to verify the MO-LR procedure. For example, the AMF may be configured to verify the MO-LR procedure based on the pairing report message. The MO-LR procedure may include one or more timestamps. The one or more timestamps may be associated with one or more other (e.g., second) WTRUs. The MO-LR procedure may be requested by the other (e.g., second) WTRU. The (e.g., first) WTRU may be configured to determine a distance between the (e.g., first) WTRU and the sidelink WTRU. Additionally or alternatively, the (e.g., first) WTRU may be configured to initiate the MO-LR procedure, for example, when the distance between the (e.g., first) WTRU and the other (e.g., second) WTRU exceeds a threshold. The threshold may be preconfigured. The (e.g., first) WTRU and the other (e.g., second) WTRU may be paired via the sidelink.

[0071] A WTRU may establish a connection with an A_IoT device. The WTRU may receive a location update request. For example, the WTRU may receive a location update request from the A_IoT device via the connection. The WTRU may send a MO-LR. The WTRU may send the MO-LR to the network, for example, based on the received location update request. The MO-LR may include an identifier associated with the A_IoT device and / or an indication that positioning is requested for the A_IoT device. The WTRU may determine to perform positioning with respect to the network, for example, to indicate the location of the A_IoT device. The WTRU may perform positioning, for example, with respect to the network, to indicate that a positioning procedure (e.g., a MO-LR procedure) is associated with (e.g., for) the A_IoT device. For example, the positioning procedure may enable the network to estimate the location of the A_IoT device (e.g., based on positioning measurements of the WTRU). The connection may be a sidelink connection and / or a backscatter connection. Additionally or alternatively, the connection between the WTRU and the A_IoT device may utilize one or more of Bluetooth, Bluetooth Low Energy (BLE), short-range wireless communication, ultra-high frequency (UHF) communication, and / or another type of communication.

[0072] The MO-LR may additionally or alternatively include one or more of a timestamp associated with the communication between the WTRU and the A_IoT device, an estimated distance between the WTRU and the A_IoT device, an application identifier, and / or a service identifier. The WTRU may receive one or more location update requests from multiple A_IoT devices, for example, within a predefined time period. The MO-LR may include an identifier for each of the multiple A_IoT devices. The locations indicated during positioning with respect to the network may be associated with the multiple A_IoT devices.

[0073] The WTRU may send pairing information to the network. The pairing information may indicate that the WTRU includes a positioning partner WTRU and / or that the A_IoT device has delegated location services to the WTRU. The indication that positioning is requested for the A_IoT device may include a positioning partner flag. The WTRU may send a (e.g., second) MO-LR to the network. The (e.g., second) MO-LR may include an estimated distance between the WTRU and the A_IoT device. The estimated distance between the WTRU and the A_IoT device may be associated with a threshold. The WTRU may send the (e.g., second) MO-LR to the network based on the estimated distance between the WTRU and the A_IoT device exceeding the threshold. The WTRU may receive a mobile terminated location request (MT-LR), for example, from the network.

[0074] Figure 2 An example non-roaming reference architecture 200 is depicted. The non-roaming reference architecture 200 may support location services. For example, the reference architecture 200 may support location services in 5G. WTRU positioning measurements may be performed. The WTRU and / or one or more network nodes may perform the WTRU positioning measurements. For example, the WTRU positioning measurements may be performed between the WTRU and a location management function (LMF). Additionally or alternatively, one or more other nodes (e.g., AMF and / or NG-RAN) may be utilized in the positioning measurements. Location information may be provided to a location service (LCS) client, for example, by a gateway mobile location center (GMLC) and / or a network exposure function (NEF).

[0075] The non-roaming reference architecture 200 may include a WTRU 204. The WTRU 204 may send and / or receive location information. For example, location information may be sent and / or received between an access control and mobility management function (AMF) 206 or a location management function (LMF) 208 and a (e.g., target) WTRU 204, among others. An AF 210 and / or a NF may access an LCS from a gateway mobile location center (GMLC) 214, for example, within the same 3GPP operator network. An LCS client 212 may access the LCS from the GMLC 214. An external AF 210 may access the LCS from a network exposure function (NEF) 216. The GMLC 214 may be configured to handle one or more requests from the external LCS client 212 (or from the AF via the NEF 216 if the AF is an external AF) or forward the location request to the appropriate NF. A location retrieval function (LRF) 218 ​​may be configured to retrieve or verify location information. The LRF 218 may be collocated with or separate from the GMLC 214. The LMF 208 may manage (e.g., overall) coordination and / or scheduling of resources for (e.g., required for) the location of the WTRU 204 registered with or accessing the 5GCN. The LMF 208 may calculate and / or verify (e.g., final) location-related information and / or (e.g., achieved) accuracy. One or more of the LMF 208, the LRF 218, and the GMLC 214 may be included as network function(s) of the 5GCN.

[0076] For example, two types of location service procedures may be supported. The types of location services supported may include Mobile Originated Location Request (MO-LR) and / or Mobile Terminated Location Request (MT-LR). In MO-LR, the WTRU may initiate the procedure with respect to the serving network and / or use the procedure to obtain its own (e.g., WTRU) location. In MT-LR, the procedure may be initiated by the LCS client. Alternatively or additionally, the network may bring the target WTRU into connected mode, for example, to perform positioning measurements and / or provide the WTRU's location to the LCS client.

[0077] A_IoT devices can play a critical role, for example, in situations where timely and / or relatively accurate positioning of the A_IoT device may be required. For example, A_IoT devices can be utilized in one or more of asset tracking, smart logistics, lost item recovery, and the like. The A_IoT device may not include a battery and / or may be power-limited. The absence of a battery and / or the (e.g., extremely) power-limited nature of the A_IoT device may cause the A_IoT device to be unreachable in the wireless network (e.g., for a significant period of time). For example, the A_IoT device may be unable to respond to and / or perform WTRU positioning procedures. When a location service client (e.g., an application server or a WTRU) requests (e.g., needs) to retrieve its location (e.g., via a wireless network), the A_IoT device may be unable to respond. The network may provide the last known location and / or defer location measurements. Additionally or alternatively, the network may report until the device becomes reachable again. The time at which the A_IoT device may become reachable may be unpredictable and / or may depend on the device's capabilities and / or the time required to collect sufficient energy. The deferred location reporting may not meet one or more requirements of the use case.

[0078] An A-IoT device may have one or more reduced WTRU capabilities (e.g., for cost savings). Additionally or alternatively, an A-IoT device may not support WTRU positioning capabilities and / or perform location measurements. Some existing location service mechanisms may not be used for positioning with respect to an A-IoT device. One or more methods and / or enhancements may assist an A-IoT device and / or existing location service mechanisms, which may, for example, enable a wireless network to locate (e.g., relatively accurately) a device location (e.g., in a timely manner).

[0079] A positioning partner WTRU (PC_WTRU) may be provided. An A_IoT device (e.g., a power-constrained A_IoT device) may delegate one or more location services to the PC_WTRU. For example, the PC_WTRU may not be power-constrained. The network may determine and / or consider the location of the A_IoT to be the same as or close to the location of the PC_WTRU (e.g., within a threshold distance from the location of the PC_WTRU).

[0080] When the A_IoT delegates one or more location services to the PC_WTRU, the A_IoT device may not need to communicate with the wireless network and / or perform heavy signaling procedures for its location updates. Additionally or alternatively, the network may obtain a location estimate (e.g., a usable location estimate) for the A_IoT device, such as when the A_IoT device and the PC_WTRU are in close proximity.

[0081] Figure 3An example process 300 for A_IoT device positioning using a PC_WTRU 302 is illustrated. The PC_WTRU 302 may be a WTRU and / or device in close proximity to an A_IoT device 304, 306 (e.g., a target A_IoT device). At 316, a sidelink discovery and / or pairing may occur between the target A_IoT device 304, 306 and the PC_WTRU 302. At 318, the PC_WTRU 302 may receive a location update request from the A_IoT device 304, 306. The target A_IoT device 304, 306 may be tracked and / or located by the network 308 (e.g., from time to time). The PC_WTRU 302 may not be power-constrained (e.g., as power-constrained as the A_IoT devices 304, 306). The PC_WTRU 302 may be able to remain connected to and / or reachable with respect to the serving wireless network 308. The PC_WTRU 302 may be configured to communicate with a wireless network 308 and concurrently to establish communications (e.g., communication and / or pairing) with proximal A_IoT devices 304, 306, for example, using sidelink technology (e.g., PC5-based discovery and / or communication). An example PC_WTRU 302 may include one or more of a phone (e.g., of a vehicle driver or passenger) and / or a vehicle (e.g., utilizing the vehicle to transport goods and / or packages with A_IoT-based tags). The PC_WTRU 302 may establish sidelink communications with the A_IoT devices 304, 306, for example, via sidelink discovery and / or pairing. The sidelink discovery and / or pairing may include one or more proximity services / procedures. Additionally or alternatively, the PC_WTRU 302 may establish communications (e.g., communication) with the A_IoT devices 304, 306 via backscatter, Bluetooth, Bluetooth Low Energy (BLE), short-range wireless communication, ultra-high frequency (UHF) communication, and / or another type of communication.

[0082] One or more A_IoT devices 304, 306 may be configured to discover and / or pair with a WTRU (e.g., a neighboring WTRU) as a PC_WTRU 302 for the one or more A_IoT devices 304, 306, for example, in a side link. The pairing of the one or more A_IoT devices 304, 306 and the PC_WTRU 302 may be reported to a serving network 308 (e.g., an AMF 310 in the network). The A_IoT devices 304, 306 may request the PC_WTRU 302 to initiate a MO-LR procedure with respect to the network 308 (e.g., a GMLC 312 in the network). The network 308 may store the location of the PC_WTRU 302 as the location of the A_IoT devices 304, 306 (e.g., a target A_IoT device). The location request for one or more target A_IoT devices 304, 306 may be converted into a location request for, for example, the PC_WTRU 302 that may be paired with the one or more A_IoT devices 304, 306 (e.g., at 326). The network 308 may initiate a MO-LR (e.g., at 320) and / or MT-LR (e.g., at 322) procedure with respect to the PC_WTRU 302. The network 308 may store the results of the MO-LR and / or MT-LR procedure, for example, as the location of the target A_IoT devices 304, 306 (e.g., at 324). The network and / or the PC_WTRU may determine (e.g., assume) that the location of the PC_WTRU is the location of the A_IoT device.

[0083] The A_IoT devices 304, 306 may be pre-configured for A_IoT device positioning (e.g., using the PC-WTRU 302). For example, the A_IoT devices 304, 306 may include configuration information. The configuration information may indicate that the A_IoT devices 304, 306 should discover and / or pair with nearby PC-WTRUs 302. For example, A_IoT devices 304, 306 that are tracked (e.g., closely) and / or do not have location service capabilities may be pre-configured for A_IoT device positioning using the PC-WTRU 302. The A_IoT devices 304, 306 may receive configuration information and / or configuration instructions from a serving network (e.g., an AMF in the network). The configuration information and / or configuration instructions may be received by the A_IoT devices 304, 306, for example, when the A_IoT devices 304, 306 communicate with the network during a registration process. The A_IoT devices 304, 306 may identify one or more opportunities to discover and pair with the PC_WTRU 302, confirm a paired PC_WTRU 302, and / or update an existing paired PC_WTRU 302, such as when the A_IoT devices 304, 306 are pre-configured for A_IoT device positioning using the PC_WTRU 302. The one or more opportunities may include one or more of when the device has collected enough energy to complete such a task (e.g., reaches an energy threshold), before and / or after the device has completed communications with the network, expiration of a (e.g., locally) configured periodic timer, and the like.

[0084] The A_IoT devices 304, 306 may use a sidelink (e.g., a sidelink) and / or a peer-to-peer communication technology (e.g., LTE / NR PC5), for example, to discover and / or pair with the PC_WTRU 302. The A_IoT devices 304, 306 may be pre-configured with one or more authorization policies, one or more valid candidate PC_WTRU identifiers (e.g., a layer 2 identifier for PC5-based communications, a permanent equipment identifier (PEI), etc.), and / or one or more security profiles (e.g., a required security profile). The PC_WTRU 302 may be pre-configured with the one or more authorization policies, one or more valid A_IoT device identifiers (e.g., a layer 2 identifier for PC5-based communications, a PEI, etc.), and / or the one or more security profiles (e.g., a required security profile). The A_IoT devices 304, 306 and the PC_WTRU 302 may obtain (e.g., receive) and / or store the identifiers of the peer devices. For example, the A_IoT devices 304, 306 and the PC_WTRU 302 may obtain and store identifiers of peer devices through a discovery and / or pairing process. For example, the A_IoT devices 304, 306 may obtain a 3GPP WTRU identifier (e.g., PEI, 5G Globally Unique Temporary Identifier (GUTI), etc.), an external identifier (e.g., General Public Subscription Identifier (GPSI)), and / or an application layer identifier of the paired PC_WTRU 302.

[0085] The PC_WTRU 302 may maintain a list of active A_IoT devices 304, 306. For example, the PC_WTRU 302 may maintain a list of active A_IoT devices that utilize (eg, rely on) the PC_WTRU 302 for location services. The A_IoT devices 304, 306 and / or the PC_WTRU 302 may transmit the pairing information (e.g., The pairing information is reported to the serving network 308 by the A_IoT device 304, 306 and / or the PC_WTRU 302 (the association identifier of the PC_WTRU device 302). For example, when the A_IoT device 304, 306 and / or the PC_WTRU 302 has an opportunity to communicate with the serving network, the A_IoT device 304, 306 and / or the PC_WTRU 302 may report the pairing information to the serving network. The serving network 308 may store the pairing information in a network function and / or database (e.g., AMF, Visited Gateway Mobile Location Center (V-GMLC), Home GMLC (H-GMLC), UDM, etc.). The network function and / or database may use this information for one or more location service processes.

[0086] The A_IoT device 304, 306 may request the PC_WTRU 302 to report the location of the A_IoT device 304, 306 to the network 308. For example, after the A_IoT device 304, 306 has been paired with the PC_WTRU 302, the A_IoT device 304, 306 may request the PC_WTRU 302 (e.g., using sidelink communication and / or backscatter) to report the location of the A_IoT device 304, 306 to the network 308. The request may be made after the initial pairing and / or when (e.g., whenever) the A_IoT device 304, 306 becomes active again (e.g., immediately). The PC_WTRU 302 may initiate the MO-LR process as described herein (e.g., upon this request).

[0087] The PC_WTRU 302 may initiate the MO-LR process as described herein. The PC_WTRU 302 may indicate its positioning partner role and / or indicate that a location request may be performed for, for example, one or more dependent WTRUs / devices with which the PC_WTRU 302 has paired (e.g., such as A_IoT devices 304, 306). The PC_WTRU 302 may send a list of A_IoT device identifiers to the network 308. The list may include an indication of the device(s) with which the PC_WTRU 302 has paired and / or for which location services have been requested. The device identifier may be associated with one or more of a timestamp, range information, an identifier of an application with which the device is associated, and / or an identifier of a service with which the device is associated. The timestamp may indicate the most recent time the PC_WTRU 302 performed a handshake (e.g., on a sidelink) with the A_IoT device 304, 306. The range information may include an estimate of the distance between the PC_WTRU 302 and the A_IoT device 304, 306. The network may use the identifier of the application and / or service, for example, to determine the LCS client 314 that should receive location updates.

[0088] At 320, the PC_WTRU 302 may send a MO-LR request. The AMF 310 may retrieve pairing information from the UDM and / or compare existing pairing information with the list of A_IoT devices 304, 306 (e.g., in the MO-LR request), for example, after receiving the MO-LR request and / or recognizing that the request is being performed on behalf of another WTRU. In some examples, the UDM may not have the pairing information.

[0089] The AMF 310 may include an indication that the location update is for (e.g., associated with) other dependent WTRUs / devices and / or may include one or more of an identifier of the dependent WTRU / device, an associated timestamp, scope information, and / or associated applications / services. For example, when the AMF 310 initiates a location update request with respect to the GMLC 312, the AMF 310 may include an indication that the location update is for (e.g., associated with) other dependent WTRUs / devices and / or may include one or more of an identifier of the dependent WTRU / device, an associated timestamp, scope information, and / or associated applications / services.

[0090] The GMLC 312 may determine whether to notify a potential LCS client 314 of a location update, e.g., for each (e.g., individual dependent) WTRU. Additionally or alternatively, the GMLC 312 may determine (e.g., when necessary) to receive LCS client 314 address information and / or send a location update to the LCS client 314 (e.g., directly or through an NEF). The LCS client 314 address information may be based on (e.g., may be determined based on) the dependent WTRU's associated application / service information.

[0091] Figure 4 An example MO-LR process 400 using a PC_WTRU 432 is illustrated. For example, the MO-LR process 400 may enable a network to store the location of an A_IoT device 430 using the PC_WTRU 432. At 402, the PC_WTRU 432 may establish communication with the A_IoT device 430. The non-roaming reference architecture 400 may be used for A_IoT device positioning using the PC_WTRU 432. For example, at 402, the A_IoT device 430 and the PC_WTRU 432 may discover and / or pair with each other using a sidelink discovery and / or communication process. For example, Proximity Service (ProSe) Model A and / or B discovery may be used. The A_IoT device 430 may be pre-configured with an authorization policy and / or one or more parameters for discovery (e.g., ProSe restriction codes, discovery query filters, ProSe response codes, etc.). For example, the A_IoT device 430 may be pre-configured with authorization policies and / or necessary parameters for discovery so that the A_IoT device 430 does not have to request authorization and / or obtain those parameters from the network.

[0092] The A_IoT device 430 may additionally or alternatively be pre-configured with candidate PC_WTRU identifiers (e.g., destination L2 identifiers). The candidate PC_WTRU identifiers may be associated with establishing communications with one or more candidate PC_WTRUs. For example, the communications may include sidelink and / or backscatter. The A_IoT device 430 and the PC_WTRU 432 may exchange 3GPP identifiers (e.g., PEI, 5G-GUTI, etc.) and / or external identifiers (e.g., GPSI, application layer identifiers, etc.). For example, the A_IoT device 430 and the PC_WTRU 432 may exchange 3GPP identifiers and / or external identifiers over sidelink communications. The A_IoT device 430 may notify the PC_WTRU 432 of the application and / or service identifiers with which the A_IoT device 430 is associated. The A_IoT device 430 and / or the PC_WTRU 432 may store identifiers of paired devices. The PC_WTRU 432 may maintain a list of multiple paired A_IoT devices. The PC_WTRU 432 may store a timestamp (e.g., when pairing occurs). Sidelink discovery and / or pairing may be repeated (e.g., periodically and / or when possible / when the A_IoT device 430 has sufficient energy stored to perform such tasks). The A_IoT device 430 and / or the PC_WTRU 432 may update one or more of the stored pairing information and / or associated timestamp and application / service information (e.g., at each handshake).

[0093] At 404, the A_IoT device 430 may send a registration message to the network (e.g., UDM 438). At 406, the PC_WTRU 432 may send a registration message to the network (e.g., UDM 438). The registration message (e.g., from the A_IoT device 430 at 404 and / or from the PC_WTRU 432 at 406) may indicate positioning partner pairing information. At 404 and / or 406, the A_IoT device 430 and / or the PC_WTRU 432 may report the pairing information, for example, to the network (e.g., during the registration process). The A_IoT device 430 and / or the PC_WTRU 432 may indicate the pairing information to the network for location service delegation purposes. The network may store the pairing information in one or more network functions (e.g., serving AMF 434, UDM 438, and / or GMLC 440). In some examples, the pairing information may not be sent immediately after sidelink discovery and / or pairing.

[0094] One or more of the following may be performed before and / or after the pairing information is sent to the network: At 408, the A_IoT device 430 may request the PC_WTRU 432 to perform a location update for the A_IoT device 430 (e.g., over a sidelink communication). The A_IoT device 430 may indicate to the PC_WTRU 432 the application and / or service identifier with which it is associated.

[0095] At 410, the PC_WTRU 432 may initiate a MO-LR procedure. For example, the PC_WTRU 432 may initiate a MO-LR procedure at 410 to update the location for the A_IoT device 430. The PC_WTRU 432 may initiate the MO-LR procedure upon receiving a request from the A_IoT device at 406 and / or upon its own decision. For example, the PC_WTRU 432 may run a periodic timer after pairing with the A_IoT device 430 and / or may initiate a location update upon expiration of the timer. Additionally or alternatively, the PC_WTRU 432 may determine that the distance the PC_WTRU 432 has moved since the last location update has exceeded a certain threshold (e.g., a predetermined threshold) and / or that a location update is required. The PC_WTRU 432 may include information, for example, in the MO-LR request. The request may be for location service delegation (e.g., the purpose of the request may be to update the location for other dependent WTRUs and / or A_IoT devices). The location of the requesting WTRU (e.g., PC_WTRU) may be determined (e.g., deemed) as the location of one or more other relying WTRUs and / or A_IoT devices. The information may include one or more identifiers of the relying WTRU, timestamp information associated with the relying WTRU (e.g., when the PC_WTRU has confirmed pairing and / or handshake with the relying WTRU and / or may be used to indicate the freshness of the relying WTRU's location), and / or one or more of the applications and / or services associated with the relying WTRU.

[0096] Applications and / or services associated with a dependent WTRU may be used by the network, for example, to locate an LCS client that may (e.g., need to) be informed of the location of the dependent WTRU. Additionally or alternatively, the MO-LR may include an indication that positioning is being requested for one or more A_IoT devices. The indication may include a positioning partner flag.

[0097] At 412, the AMF 434 may retrieve information (e.g., from the UDM 438) and / or verify the information included in the MO-LR request. The AMF 434 may retrieve information (e.g., from the UDM 438) and / or use it to verify the information included in the MO-LR request, for example, if pairing information is available in the network.

[0098] At 414, the AMF 434 may select the LMF 436 and / or invoke the Nlmf_Location_DetermineLocation service of the LMF 436. For example, the AMF may send a location request (e.g., an Nlmf_Location_DetermineLocation request) to the LMF 436 at 414.

[0099] At 416, one or more WTRU positioning procedures may be performed with respect to the LMF 436 (e.g., as described herein) to determine the location of the PC-WTRU 432. For example, the PC-WTRU 432 may perform positioning (e.g., positioning measurements) with respect to the network (e.g., the LMF 436) at 416 to indicate that a positioning procedure (e.g., MO-LR) is associated with (e.g., for) the A_IoT device 430. For example, the positioning procedure may enable the network (e.g., the LMF 436) to estimate the location of the A_IoT device 430 (e.g., based on the positioning measurements of the PC_WTRU 432). The location of the PC_WTRU 432 determined via the positioning performed at 416 may indicate the location of the A_IoT device 430. For example, the network (e.g., the LMF 436) may determine the location of the A_IoT device 430 based on the location of the PC_WTRU 432 determined via the positioning performed at 416. For example, the network (eg, LMF 436 ) may assume that the location of the A_IoT device 430 is the same as the location of the PC_WTRU 432 .

[0100] At 418 , the LMF 436 may send (eg, return) an Nlmf_Location_DetermineLocation response to the AMF 434 , eg, in response to the NLmf_Location_DetermineLocation service request sent at 414 .

[0101] At 420, the AMF 434 may select and / or invoke an Ngmlc_Location_LocationUpdate service operation to the GMLC 440. For example, the AMF 434 may send a location update request to the GMLC 440 at 420. The service operation may include relying on the WTRU's identity and / or multiple identities (e.g., instead of or in addition to the PC_WTRU). The location information may additionally or alternatively include the location of the PC_WTRU 432.

[0102] At 422, the GMLC 440 may send (e.g., forward) the location information to, for example, an LCS client 442 (e.g., an application server), which may request (e.g., require) the information. Sending (e.g., at 422) the location information to the LCS client 442 may utilize (e.g., invoke) an NEF notification service.

[0103] The MO-LR process may be performed in any order. Additionally or alternatively, one or more steps of the MO-LR process may be repeated. Additionally or alternatively, one or more steps of the MO-LR process may be omitted.

[0104] The PC_WTRU may combine requests and / or initiate a single MO-LR procedure for multiple A_IoT devices, for example, when multiple A_IoT devices issue location requests (e.g., at approximately the same time). For example, the PC_WTRU may combine requests and / or initiate a single MO-LR procedure for multiple A_IoT devices. The PC_WTRU may additionally or alternatively include the identifier(s) of the paired A_IoT device(s). For example, the PC_WTRU may include the identifiers of paired A_IoT devices that did not request (e.g., explicitly request) a location update (e.g., if the PC_WTRU has an opportunity to initiate a MO-LR procedure with the network).

[0105]

[00135] A PC_WTRU may have one or more active paired A_IoT devices that depend on it for location services. The PC_WTRU may start a periodic timer and / or initiate a MO-LR procedure as described herein, for example, upon expiration of a timer. The PC_WTRU may start a periodic timer and / or initiate a MO-LR procedure without an explicit request from a dependent A_IoT device. Additionally or alternatively, an A_IoT device may be paired with one or more PC_WTRUs.

[0106] The network (e.g., GMLC) may convert a location service request for a target A_IoT device from an external client into a location request for the PC_WTRU, e.g., based on stored pairing information between the target A_IoT device and the PC_WTRU. The network may receive a location service request, e.g., a mobile terminated location request. The network (e.g., GMLC) may convert a location service request for the (e.g., target) A_IoT device into a location request for the PC_WTRU, e.g., based on stored pairing information between the target A_IoT device and the PC_WTRU. Additionally or alternatively, the network may determine (e.g., deem) the location of the PC_WTRU as the location of the target A_IoT device and / or report the location to the external client.

[0107] The A_IoT device may receive location information of the PC_WTRU during sidelink communications and / or handshake procedures. The A_IoT device may compare the current PC_WTRU location with a previously received PC_WTRU location (e.g., to estimate / determine the distance it has moved). If the distance exceeds, for example, a certain threshold, the A_IoT device may initiate one or more of a direct MO-LR procedure with the network and / or a location update (e.g., using the PC_WTRU as described herein). The threshold may be one or more of the following: pre-configured in the device and / or configured by the network. The PC_WTRU may determine its location using its own Global Navigation Satellite System (GNSS) receiver and / or using location service procedures. For example, the PC_WTRU may determine its location using its own GNSS receiver and / or using location service procedures, for example, as described herein.

[0108] There may be a location tracking priority mode (e.g., for PC_WTRUs and / or A_IoT devices). In, for example, a location tracking priority mode, an A_IoT device may seek opportunities (e.g., frequent opportunities) to initiate location updates with the network and / or prioritize location update procedures over other service procedures. The network may maintain the location of the A_IoT device (e.g., a relatively fresh last known location) and / or be configured to provide a (e.g., last known) location (e.g., a usable last known location). For example, the network may maintain the location of the A_IoT device (e.g., a relatively fresh last known location) and / or be able to provide a (e.g., last known) location (e.g., a usable last known location) in the presence of a mobile terminated location request from an LCS client and / or in the event that the device is unreachable.

[0109] An A_IoT WTRU / device may be pre-configured and / or configured by the network to operate in a location tracking priority mode. The network may determine, for example, based on a subscription and / or application server request, that the WTRU should be tracked (e.g., closely) and / or may determine to send an indication and / or configuration to the A_IoT WTRU. For example, during a registration procedure, the network may determine, based on a subscription and / or application server request, that the WTRU should be tracked (e.g., closely) and / or may determine to send an indication and / or configuration to the A_IoT WTRU.

[0110] An A_IoT WTRU may seek an opportunity (e.g., every opportunity) to initiate a location update procedure (e.g., a direct MO-LR procedure with the network and / or location update using a PC_WTRU), for example, in a location tracking priority mode. For example, when the WTRU has collected enough energy to support the location update procedure (e.g., reaches a threshold), it may initiate the procedure. Additionally or alternatively, the WTRU may embed the location update procedure within one or more other procedures with the network (e.g., registration, service request, etc.). For example, when the WTRU has completed another service procedure and / or has residual energy to support the location update procedure, the WTRU may initiate the location update procedure. Additionally or alternatively, the A_IoT device may prioritize the location update procedure over other communication needs. The WTRU may perform a location update procedure first before sending data, for example, if the WTRU becomes available to communicate with the network and / or if the WTRU has some data to send to the network. The WTRU may additionally or alternatively be configured (e.g., by the network) with a distance threshold. The WTRU may initiate (eg, only initiate) a location update procedure (eg, in location tracking priority mode), for example, when the distance moved has exceeded a threshold. The terms WTRU, A_IoT device, and UE may be used interchangeably herein.

Claims

1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: Establish connections with Ambient Internet of Things (A_IoT) devices; receiving a location update request from the A_IoT device via the connection; Sending a Mobile Originated Location Request (MO-LR) to a network based on the received location update request, wherein the MO-LR includes an identifier associated with the A_IoT device and an indication that positioning is requested for the A_IoT device; and Positioning is performed with respect to the network.

2. The method of claim 1 , wherein the MO-LR further comprises one or more of a timestamp associated with the communication between the WTRU and the A_IoT device, an estimated distance between the WTRU and the A_IoT device, an application identifier, or a service identifier.

3. The method of claim 1 or 2, further comprising: A location update request is received from a plurality of A_IoT devices within a predefined time period, wherein the MO-LR includes an identifier of each of the plurality of A_IoT devices, and wherein the location indicated during positioning with respect to the network is associated with the plurality of A_IoT devices.

4. The method according to any one of claims 1 to 3, further comprising: Sending pairing information to the network, wherein the pairing information indicates that the WTRU is a positioning partner WTRU and that the A_IoT device has delegated location services to the WTRU.

5. The method of any one of claims 1 to 4, wherein performing positioning with respect to the network comprises: Performing positioning measurements with respect to the network that enable the network to estimate the location of the A_IoT device.

6. The method according to any one of claims 1 to 5, wherein the indication requesting positioning for the A_IoT device comprises a positioning partner tag.

7. The method of any one of claims 1-6, wherein establishing a connection with the A_IoT device comprises establishing a side link (SL) connection.

8. The method of any one of claims 1-7, wherein the MO-LR is a first MO-LR, wherein the method further comprises sending a second MO-LR to the network, and wherein the second MO-LR comprises an estimated distance between the WTRU and the A-IoT device.

9. The method of claim 8 , wherein the estimated distance between the WTRU and the A-IoT device is associated with a threshold, and wherein the second MO-LR is sent to the network based on the estimated distance between the WTRU and the A-IoT device exceeding the threshold.

10. The method of any one of claims 1 to 9, further comprising: A Mobile Terminated Location Request (MT-LR) is received from the network.

11. A wireless transmit / receive unit (WTRU) comprising a processor, the processor configured to: establish a connection with an ambient Internet of Things (A_IoT) device; receiving a location update request from the A_IoT device via the connection; Sending a Mobile Originated Location Request (MO-LR) to a network based on the received location update request, wherein the MO-LR includes an identifier associated with the A_IoT device and an indication that positioning is requested for the A_IoT device; and Positioning is performed with respect to the network.

12. The WTRU of claim 11 , wherein the MO-LR further comprises one or more of a timestamp associated with the communication between the WTRU and the A_IoT device, an estimated distance between the WTRU and the A_IoT device, an application identifier, or a service identifier.

13. The WTRU of claim 11 or 12, wherein the processor is further configured to: receive location update requests from a plurality of A_IoT devices within a predefined time period, wherein the MO-LR includes an identifier of each of the plurality of A_IoT devices, and wherein the location indicated during positioning with respect to the network is associated with the plurality of A_IoT devices.

14. The WTRU of any one of claims 11-13, wherein the processor is further configured to: send pairing information to the network, wherein the pairing information indicates that the WTRU is a positioning partner WTRU and that the A_IoT device has delegated location services to the WTRU.

15. The WTRU of any one of claims 11-14, wherein the processor being configured to perform positioning with respect to the network comprises: The processor is configured to perform positioning measurements with respect to the network, which enables the network to determine the location of the A_IoT device.

16. The WTRU of any one of claims 11-15, wherein the indication requesting positioning for the A_IoT device includes a positioning partner tag.

17. The WTRU of any one of claims 11-16, wherein the processor being configured to establish a connection with the A-IoT device comprises: The processor is further configured to establish a side link (SL) connection.

18. The WTRU of any one of claims 11-17, wherein the MO-LR is a first MO-LR, wherein the processor is further configured to send a second MO-LR to the network, and wherein the second MO-LR includes an estimated distance between the WTRU and the A_IoT device.

19. The WTRU of claim 18 , wherein the estimated distance between the WTRU and the A-IoT device is associated with a threshold, and wherein the processor is configured to send the second MO-LR to the network based on the estimated distance between the WTRU and the A-IoT device exceeding the threshold.

20. The WTRU of any one of claims 11-19, wherein the processor is further configured to receive a Mobile Terminated Location Request (MT-LR) from the network.

Images