Method and apparatus for supporting location representative functionality in wireless networks

Abstract

A method may include receiving information related to a location representative. The information may be used when at a first activity level. The information may be received while in a second activity level, during a transition from the second activity level to the first activity level, or while in the first activity level. The method may include receiving, in response to an explicit request or via broadcast information, information related to a positioning capability of the location representative. The method may include selecting a location representation based on a need or condition, which may include at least one of a desired accuracy level, an optimal signal level, or a higher layer application need. The method may include receiving location information from the selected location representative. The method may include reutilizing an existing message to request location information and receive location information for a new purpose while in the first activity level.

Description

[0001] Cross - Reference to Related Applications This application claims the benefit of U.S. Provisional Application No. 63 / 410,871, filed on September 28, 2022, the content of which is incorporated herein by reference. Background Art

[0002] Integrated access and backhaul (IAB), where a portion of the wireless spectrum is used for backhaul connection to a base station instead of a dedicated optical fiber link to the base station, allows for a more flexible and cheaper deployment of dense networks compared to a deployment where there is a dedicated optical fiber link to the base station. The protocol stack of an IAB node is partitioned into a user plane (UP) and a control plane (CP). Both the UP and CP architectures employ a routing / forwarding scheme inspired by IP networks, where each IAB node is assigned an IP address that can be routed from a donor base station, and intermediate IAB nodes transparently forward packets based on a routing identifier / destination address. A CU / DU split architecture can be used, in which case the IAB node terminates the DU function and the base station (referred to as the IAB donor) terminates the CU function. One of the usage scenarios for IAB is the support of mobile IAB. Mobile IAB can be used to provide connectivity to a large number of WTRUs while in motion. Mobile IAB nodes will be installed, for example, in trains, buses, airplanes, and still be very close to the WTRUs. Additionally, in these usage scenarios, multiple WTRUs can still be very close to each other for long periods of time. The positions of the WTRUs can be substantially the same. Independently performing positioning for each WTRU may be sub - optimal. It can be advantageous if a mobile IAB node or other similar entity that can provide connectivity to a large number of WTRUs that are very close to each other and are likely to move serially can act as a location representative for the WTRUs it serves. This can reduce WTRU power consumption and signaling overhead. Summary of the Invention

[0003] A method that may be implemented by a WTRU may include: receiving information related to one or more location representatives. The information may be used while in a first activity level. The information related to one or more location representatives may be received while in a second activity level, during a transition from the second activity level to the first activity level, or while in the first activity level. The first activity level may be a Radio Resource Control (RRC) idle or RRC inactive connection mode, and the second activity level may be an RRC connected mode. The method may include: receiving information related to the positioning capabilities of the one or more location representatives. The information related to the positioning capabilities of the one or more location representatives may be received in response to an explicit request or via broadcast information. The method may include: transitioning from the second activity level to the first activity level in response to a received message. The received message may be a Radio Resource Control (RRC) release message. The method may include: selecting a location representative based on a need or condition. The need or condition may include at least one of the following: a desired accuracy level, a best signal level, or a higher layer application need. The method may include: receiving location information from the selected location representative. The location information may be received from the selected location representative while in the first activity level. The location request and the receipt of the location information from the selected location representative are performed using a Small Data Transfer (SDT) procedure and resources. The location information may be received periodically. The location information may be received intermittently. The method may include: sending a request for location information in a Msg1 message during a 4-step random access procedure; and receiving the location information in a Msg2 message. The method may include: sending a request for location information in a MsgA message during a 2-step random access procedure; and receiving the location information in a MsgB message. The method may include: sending a request for location information in a Msg3 message; and receiving the location information in a Msg4 message. The Msg3 message may be an RRC resume request message. The Msg4 message may be an RRC release message or an RRC resume message. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] A more detailed understanding may be obtained from the following description taken in conjunction with the accompanying drawings, in which like reference numerals indicate like elements, and in which: Figure 1A is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented; Figure 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communication system illustrated in Figure 1A in accordance with one embodiment; Figure 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used within the communication system illustrated in Figure 1A ; Figure 1D is a system diagram illustrating a further example RAN and a further example core network (CN) that can be used within the communication system illustrated in Figure 1A ; Figure 2 shows an example of a location management architecture; Figure 3 shows an example of a split architecture IAB with separation of user plane and control plane; Figure 4 shows an example of an IAB architecture; Figure 5 shows an example of an IAB user plane; Figure 6 shows an example of an IAB control plane; Figure 7 shows an example usage scenario; Figure 8 shows an RRC connection setup call flow; Figure 9 shows an RRC connection resume call flow; Figure 10 shows different RRC modes and transitions between the modes; Figure 11 shows the message passing exchange for a 4-step random access procedure; Figure 12 shows the message passing exchange for a 2-step random access procedure; Figure 13 shows an example where location information can be sent in a broadcast channel or via a dedicated request / response procedure; Figure 14 shows a high-level view of an example of a location representation procedure; Figure 15 shows an example where a configuration can be sent to a WTRU when the WTRU is in the RRC connected mode; and Figure 16 shows an example where a configuration can be sent to a WTRU when the WTRU is in the RRC idle or RRC inactive mode. DETAILED DESCRIPTION

[0005] The following abbreviations and acronyms may be mentioned herein: AMF Access and Mobility Management Function AoA Angle of Arrival BAP Backhaul Adaptation Protocol CB contention-based CBRA contention-based random access CFRA contention-free random access CG configuration grant CHO conditional handover CPRI Common Public Radio Interface CP control plane CN core network (e.g., LTE packet core) CU central unit CUPS control and user plane separation DCI downlink control information DL downlink DN data network DU distributed unit eCPRI enhanced Common Public Radio Interface EPC evolved packet core GTP GPRS tunneling protocol IAB integrated access and backhaul IP Internet protocol LCS location service LMF location management function LPP LTE positioning protocol LTE Long Term Evolution, e.g., from 3GPP LTE R8+ MAC media access control MIMO multiple input multiple output MME mobility management entity Multi-RTT multi-cell round-trip time NAS non-access stratum NR New Radio, e.g., from 3GPP R15+ NRPPa NR positioning protocol A OFDM orthogonal frequency division multiplexing PGW packet gateway PHY physical layer PRACH physical random access channel PDCP packet data convergence protocol PDU protocol data unit PLMN public land mobile network PRS positioning reference signal QoS quality of service RACH random access channel (or procedure) RAN Radio Access Network RAR Random Access Response RNTI Radio Network Temporary Identifier RF Radio Front End RLC Radio Link Control RRC Radio Resource Control RS Reference Signal RSRP Reference Signal Received Power RSTD Reference Signal Time Delay RTT Round Trip Time RU Radio Unit SDAP Service Data Adaptation Protocol SDT Small Data Transmission SGW Serving Gateway SMF Session Management Function SRB Signaling Radio Bearer SRS Sounding Reference Signal TA Timing Advance TDOA Time Difference of Arrival TRP Transmission / Reception Point UL Uplink UDP User Datagram Protocol UP User Plane UPF User Plane Function WLAN Wireless Local Area Network and related technologies (IEEE 802.xx domain) WTRU Wireless Transmit / Receive Unit.

[0006] Figure 1A FIG. is a diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. Communication system 100 may be a multi-access system that provides content (such as, voice, data, video, messaging, broadcasts, etc.) to multiple wireless users. Communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, 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 Discrete Fourier Transform Spread OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

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

[0008] The communication system 100 may also include base station 114a and / or base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, 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), NodeB, eNodeB (eNB), home node B, home eNode B, next generation NodeB such as a gNode B (gNB), new radio (NR) NodeB, site controller, access point (AP), wireless router, etc. Although the base stations 114a, 114b are each 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.

[0009] Base station 114a may be part of RAN 104, 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), a relay node, 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, and such a base station 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. The cell may provide coverage of a specific geographical area for wireless services, and this specific geographical area may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

[0011] More specifically, as pointed out above, communication system 100 may be a multi-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a in RAN 104, as well as WTRUs 102a, 102b, 102c, may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), and this radio technology may use Wideband CDMA (WCDMA) to establish air interface 116. 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 Uplink (UL) Packet Access (HSUPA).

[0012] 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 the air interface 116.

[0013] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as NR radio access, which may use NR to establish the air interface 116.

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

[0015] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., 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.

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

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

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

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

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

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

[0022] 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 an air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive signals such as IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF and optical signals. It will be appreciated that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

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

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

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

[0027] The processor 118 can also be coupled to a GPS chipset 136, which can 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 the information from the GPS chipset 136, the WTRU 102 can receive location information from a base station (e.g., base stations 114a, 114b) via 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 can obtain location information by any suitable location determination method while remaining consistent with the embodiments.

[0028] The processor 118 can be further coupled to other peripherals 138, and these components / peripherals 138 can include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connections. For example, the peripherals 138 can include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, 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 peripherals 138 can include one or more sensors. The sensor can be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geographical location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, and so on.

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

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

[0031] The RAN 104 may include eNode-Bs 160a, 160b, 160c, although it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. Each of the eNode-Bs 160a, 160b, 160c may 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.

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

[0033] 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. Although the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

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

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

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

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

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

[0043] A very high throughput (VHT) STA can support channels that are 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining eight contiguous 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 done separately on each stream. The streams can be mapped to two 80 MHz channels, and the data can be transmitted by the STA that is performing the transmission. At the receiver of the STA that is performing the reception, the above operations for the 80 + 80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

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

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

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

[0047] Figure 1D FIG. is a system diagram of RAN 104 and CN 106 according to an embodiment. As noted above, RAN 104 can employ NR radio technology to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0048] The RAN 104 may include gNBs 180a, 180b, 180c, although it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with the embodiments. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c 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 the WTRU 102a and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive a coordinated transmission from the gNB 180a and the gNB 180b (and / or gNB 180c).

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

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

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

[0052] Figure 1DThe CN 106 shown in the figure may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and may possibly include data networks (DN) 185a, 185b. Although the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0053] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 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 protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing the registration area, terminating non-access stratum (NAS) signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize the CN support for the WTRUs 102a, 102b, 102c based on the type of service utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low-latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 182a, 182b may provide control plane functions for handovers between the RAN 104 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0054] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 106 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 106 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the 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 DL data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0055] UPF 184a and 184b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 104 via the N3 interface. These gNBs can provide access to a packet-switched network (such as the Internet 110) to WTRUs 102a, 102b, and 102c to facilitate communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. UPF 184a and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, etc.

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

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

[0058] Emulation devices 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 emulation 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 emulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Emulation devices can be directly coupled to another device for testing purposes and / or can perform tests using over-the-air wireless communication.

[0059] The one or more emulation devices can perform one or more (including all) functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices can be used in test scenarios in a test laboratory and / or in a non-deployed (e.g., test) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit (e.g., which can include one or more antennas) can be used by the emulation device to transmit and / or receive data.

[0060] 3GPP standards support location service features, i.e., features that allow the possible location of a specific WTRU (Wireless Transmit / Receive Unit) to be identified. Location can be used, for example, for charging, lawful interception, emergency calls, and to support location-based services such as push notifications. Location services can enable many new applications that are location-dependent. All 3GPP technologies (e.g., NG-RAN, E-UTRAN, GERAN, and UTRAN) have features for facilitating the determination of the location of a WTRU (e.g., a WTRU).

[0061] Location information includes geographical location (e.g., latitude and longitude), speed (e.g., rate and direction), or civic location (e.g., address). Among other things, important factors to consider for location services include positioning accuracy, response time, reliability, priority, and security.

[0062] The 3GPP architecture for location services includes a Location Services (LCS) client, an LCS server, a positioning function, and a target WTRU (e.g., the target WTRU). The LCS server is located within the 3GPP network and provides a platform to enable location-based services to be supported together with other communication services such as voice, data, messaging, etc. The LCS client is a logical functional entity that makes a request to the LCS server for location information of one or more target WTRUs within a specified set of parameters (e.g., QoS requirements). The LCS client can reside in an entity within the PLMN network to enable the provision of operator-based services, or in an entity outside the PLMN network, such as an application server. The LCS client can also reside in the WTRU, such as in an application running in the WTRU that may require location information. The LCS client is the requester of location information; if the considerations of target WTRU privacy are met, the LCS server can respond to a location request from an authorized LCS client with the location information of the target WTRU (specified by the LCS client).

[0063] The positioning function is the basic function for determining the location of a specific target WTRU. The target WTRU is the object to be located by the LCS server. The trigger for this function is a positioning request from the LCS client with a set of parameters such as QoS requirements. The final result of this function is the location information for the target WTRU. For network-based positioning methods, no support for LCS is required by the target WTRU. For mobile-assisted and mobile-based positioning methods, the target WTRU actively supports LCS.

[0064] Throughout this document, the terms LCS server and Location Management Function (LMF) are used interchangeably. Additionally, the examples provided in this document are 3GPP-specific and furthermore 5G-specific. However, the use of these terms is not restricted in any way, as the concepts apply to other network technologies for providing location services.

[0065] Figure 2An example of the location management architecture in a PLMN network is shown, depicting the relevant protocols used in 3GPP 5GNR. The NR Positioning Protocol A (NRPPa) 201 is used between the gNB 202 and the Location Management Function (LMF) 203. The LMF 203 resides in the 3GPP network 204. The LTE Positioning Protocol (LPP) 205 is used between the WTRU 206 and the LMF 203. The interface between the WTRU 206 and the LMF 203 is the logical interface 205, and the WTRU 206 can communicate with the LMF 203 via the gNB 202, which uses the RRC and NAS protocols (carrying NAS messages in the RRC PDU) 207. The LCS client can be inside the PLMN network 208 or in an application server outside the PLMN network (e.g., in a part of the Internet or a private network) 209. The LCS client can send a request to the LCS server to request the location of a specific WTRU.

[0066] The LMF function determines the positioning methods to be supported by the WTRU (e.g., WTRU-assisted / WTRU-based and / or DL-based / UL-based) based on the positioning capability information sent by the WTRU. In one example, the LMF function provides a positioning reference signal (PRS) configuration to the WTRU (for DL-based positioning) and provides a sounding reference signal (SRS) configuration to the gNB / TRP (for UL-based positioning). For WTRU-assisted positioning, the LMF performs the calculation of the WTRU location based on the measurement report sent by the WTRU. For WTRU-based positioning, the WTRU sends the location information to the LMF, and the LMF then forwards the WTRU location to the LCS client.

[0067] Refer to Figure 2, the NRPPa protocol 201 can be used to send SRS and / or PRS configurations from the LMF 203 to the gNB / TRP 202 such that the gNB / TRP knows what to transmit / receive to support WTRU 206 positioning. The LMF 203 can also send PRS to neighboring cells 210, 211 since the WTRU 206 can use the PRS associated with the gNB / TRP in both the serving cell 202 and the neighboring cells 210, 211. The LMF 203 can use the LPP protocol 205 to send measurement details with information related to what to measure and how to measure to the WTRU 206. The WTRU 206 can use the LPP 205 to transmit its positioning capability information, assistance data requests (e.g., in the case where the WTRU does not have any PRS configuration), measurement reports for WTRU-assisted positioning, and location information for WTRU-based positioning. The LPP messages (WTRU <-> gNB <-> AMF <-> LMF) can be carried in NAS PDUs encapsulated in RRC messages. For DL-based positioning, the WTRU can obtain the PRS configuration via posSIB. Before the WTRU 206 starts performing measurements of DL-PRS, the WTRU 206 can also request the gNB 202 to configure a measurement gap. For UL-based positioning, the WTRU 206 can receive the SRS configuration from the serving gNB 202. When the LMF 203 receives a request for the location of a specific WTRU from the LCS clients 208, 209, the LMF 203 can use the LPP protocol 205 to send the location request to the WTRU 206. The WTRU 206 can then start performing measurements and execute the positioning process.

[0068] In the description herein, consider the following positioning methods. A downlink (DL) positioning method may refer to any positioning method that uses a downlink reference signal such as a PRS. A WTRU may receive multiple reference signals from a (one or more) gNB / TRP and measure the DL reference signal time delay (RSTD) and / or the reference signal received power (RSRP). Examples of DL positioning methods include DL angle of arrival (AoD) and DL time difference of arrival (TDOA) positioning. An uplink (UL) positioning method may refer to any positioning method that uses an uplink reference signal such as a positioning SRS. A WTRU may transmit an SRS to multiple TRPs, and the TRPs may measure the UL relative time of arrival (RTOA) and / or the RSRP. Examples of UL positioning methods include UL-TDOA or UL-AoA positioning. DL and UL positioning methods may refer to any positioning method that uses both uplink and downlink reference signals for positioning. In one example, a WTRU may transmit an SRS to multiple TRPs, and the gNB may measure the Rx-Tx time difference. The gNB may measure the RSRP of the received SRS. The WTRU may measure the Rx-Tx time difference for the PRS transmitted from multiple TRPs. The WTRU may measure the RSRP of the received PRS. The Rx-Tx differences and possible RSRP measured at the WTRU and the gNB may be used to calculate the round-trip time. Here, the Rx and Tx difference refers to the difference between the arrival time of the reference signal transmitted by the TRP and the transmission time of the reference signal transmitted from the WTRU. An example of DL and UL positioning methods is multi-cell round-trip time (multi-RTT) positioning.

[0069] The 3GPP Release 15 specification introduced a split architecture that defines 3 sub-components of the gNB. Figure 3 An example of a split architecture with separation of the user plane and the control plane is shown. Refer to Figure 3 , which depicts the integrated architecture 301 and the split architecture 302. In Figure 3In [Figure], a traditional RAN node (i.e., an integrated RAN node) 301 is illustrated. The RAN node can be an eNB, a gNB, etc. In the integrated architecture, all sub-components of the RAN node (i.e., PHY 303, MAC 304, RLC 305, PDCP 306, RRC 307, and SDAP 308) are part of a single component, and thus, they are all installed in the same location. In the split architecture 302, the RAN node is split among a radio unit (RU) 309, a distributed unit (DU) 310, and a central unit (CU) 311. The interface between the RU 309 and the DU 310 is referred to as the fronthaul 312; the interface between the DU 310 and the CU 311 is referred to as the midhaul 313. In the split architecture, the midhaul 313 and fronthaul 312 interfaces are standardized and clearly specified in the standard, allowing RAN vendors to specialize in different components and allowing operators to use components from different vendors in their networks.

[0070] It should be noted that for ease of installation, the RF and antenna 314 can be installed in a location different from the RAN node (in the integrated architecture 301) or different from the RU (in the split architecture 302). For example, in the case of a macro cell, the RF and antenna 314 can be installed at the top of the tower, and the remaining part of the sub-components can be installed at the bottom of the tower, and a common public radio interface (CPRI) interface 315 can be used to connect them. The interface 315 is a TDM serial interface, is standardized, and is the same for both architectures. In the split architecture, an enhanced common public radio interface (eCPRI) is used in the fronthaul 312. The enhanced CPRI (eCPRI) is a packet-based technology using Ethernet / IP. Additionally, in the split architecture, there is an option to use control and user plane separation (CUPS), which includes the separation of the CU 311 into a CU user plane (CU-UP) 317 and a CU control plane (CU-CP) 318. Finally, in both architectures, the backhaul 316 connects the RAN to the core network (CN).

[0071] Compared with a deployment where there is a dedicated fiber optic link to the base station, integrated access and backhaul (IAB), where a portion of the wireless spectrum is used for the base station instead of a fiber optic backhaul connection, allows for a more flexible and cheaper deployment of dense networks. In version 16 of the 3GPP standard, a fully qualified multi-hop IAB solution based on the split architecture of version 15 has been specified for NR. Figure 4An example of an IAB architecture is shown. In the IAB architecture, there are two main components: the IAB donor 401, which is a gNB; and the IAB nodes 402, 403. In addition, the IAB architecture is based on a split architecture, so there are two parts of the IAB donor: the IAB donor CU 404 and the IAB donor DU 405. The IAB system architecture enables the relaying of NR Uu access traffic 406 from a WTRU via the NR Uu backhaul links 407, 408. The Uu backhaul link can exist between an IAB node and the IAB donor (gNB) 407 or another IAB node 408. In the case where two IAB nodes are connected, they can be referred to as the parent IAB node 402 and the child IAB node.

[0072] There are sub-components of the IAB node that support WTRU-like functions towards the IAB donor 409 or towards the parent IAB node 410 via Uu backhaul. This enables the IAB node to register with a PLMN (or SNPN) and manage the backhaul connectivity. This sub-component is referred to as the IAB-WTRU or IAB-MT or IAB-UE 409, 410.

[0073] In Figure 5 and Figure 6 the protocol architecture for Release 16 IAB (as disclosed in 3GPP TR 38.834) is shown. Figure 5 An example of the IAB user plane is shown. Figure 6 An example of the IAB control plane is shown.

[0074] The IAB donor includes the IAB donor CU and one or more IAB donor DUs. In the case of the separation of gNB-CU-UP 501 and gNB-CU-CP 601, the IAB donor can include the IAB donor CU-CP 601, one or more IAB donor CU-UPs 501, and one or more IAB donor DUs 502, 602. The IAB nodes 503, 504, 603, 604 can be connected to the upstream IAB node (503, 603 are connected to 504, 604) or the IAB donor DU (502, 602 are connected to 502, 602) via a subset of the WTRU functions of the NR Uu interface (i.e., the IAB-MT / IAB-WTRU function of the IAB node). The IAB node provides a wireless backhaul to the downstream IAB node and the WTRU via the network functions of the NR Uu interface (i.e., the IAB-DU function of the IAB node).

[0075] In the user plane, F1-U traffic between IAB nodes 503, 504 and the IAB donor CU-UP 501 is backhauled via the IAB donor DU 502, using optional intermediate hops between (one or more) IAB nodes 505. In the control plane, F1-C traffic between IAB nodes 603, 604 and the IAB donor CU-CP 601 is backhauled via the IAB donor DU 602 and optional intermediate hops between (one or more) IAB nodes 605.

[0076] The protocol stack of an IAB node contains two sides: a Mobile Termination (MT) part for communicating with the parent node; and a DU part for communicating with child nodes or normal WTRUs. Both the UP and CP architectures employ a routing / forwarding scheme inspired by IP networks, where each IAB node is assigned an IP address (and associated L2 address) that can be routed from the donor base station, and intermediate IAB nodes transparently forward packets based on the routing identifier / destination address. The IAB node terminates the DU function, and the base station (i.e., the IAB donor) terminates the CU function. Thus, regardless of how many hops physically separate the IAB node and the donor CU from each other, they form one logical base station unit adopting the CU / DU split architecture. The IAB node serving the WTRU is called an access IAB node, while the nodes between the IAB donor DU and the access IAB node are called intermediate IAB nodes. It should be noted that an IAB node can play the role of both an access IAB node (for the WTRU directly connected to it) and an intermediate IAB node (for the WTRU served by its descendant IAB nodes).

[0077] One usage scenario currently being studied in version 18 of the 3GPP standard for the IAB usage scenario is the support of mobile IABs for providing connectivity to a large number of WTRUs while on the move (e.g., on a bus, train, plane, etc.). The work item description can be found in 3GPP tdoc RP-221815. Another usage even related to version 16 IAB nodes is an IAB node acting as a Fixed Wireless Access (FWA) connection point for multiple WTRUs (e.g., installed outside a home, building, shopping mall, etc. and providing connectivity to indoor WTRUs).

[0078] In the above scenarios where multiple WTRUs are in close proximity to each other (such as in a bus, train, airplane, in the same building, etc.), the positions of the WTRUs can be significantly close and can be considered the same for applications that may not require a high level of accuracy. Performing positioning for each WTRU independently (either WTRU - based or network - based) is thus sub - optimal for many reasons such as: unnecessary WTRU power consumption (e.g., for performing PRS measurements, for sending SRS, for performing GNSS measurements, etc.); unnecessary signaling and resource utilization in the case of positioning via the mobile network (e.g., sending of PRS, sending of SRS, etc.); low positioning accuracy of GNSS in the case of indoor WTRUs; and throughput loss of the WTRU in the case of mobile network - based positioning (due to measurement gaps that may be required by the WTRU to perform positioning - related measurements).

[0079] Accordingly, the following process has been proposed: where a mobile IAB node (or other similar entity that can provide connectivity to a large number of WTRUs that are in close proximity to each other and are likely to move serially) can act as a location representative for the WTRUs it serves. In Figure 7 an example usage scenario is shown.

[0080] In NR, a WTRU can be in one of the following three RRC modes: RRC_CONNECTED (also referred to as "connected mode" in this disclosure); RRC_INACTIVE (also referred to as "inactive mode" in this disclosure); and RRC_IDLE (also referred to as "idle mode" in this disclosure).

[0081] Figure 8 Different RRC modes and transitions between the modes are shown. In the RRC_CONNECTED mode 801, the WTRU is actively connected to the network when signaling and data radio bearers are established (e.g., SRB and DRB), and is capable of receiving downlink (DL) data from the network in unicast and also sending uplink (UL) data to the network. The mobility of the WTRU from one cell / node to another is controlled by the network. The network can configure the WTRU to send measurement reports either periodically or when certain conditions are met (e.g., an adjacent cell becomes better than the serving cell by more than a certain threshold), and based on these reports, the network can send a handover command to move the WTRU to another cell / node. The network can also be configured with conditional handover (CHO), where instead of sending measurement reports, when certain conditions are met, the WTRU executes a pre - configured handover command. The network can also send a handover (HO) command to the WTRU without receiving any measurement reports (e.g., based on an implementation such as the determination of the current location).

[0082] Keeping the WTRU in the connected mode is power-intensive for the WTRU (e.g., the WTRU needs to continuously monitor the PDCCH of the serving cell, e.g., for determining the arrival of DL data, for UL data scheduling, etc.), and a certain cell / gNB can accommodate a certain number of WTRUs in the connected mode (e.g., due to resource limitations). Thus, when there is no activity in the UL or DL for a certain duration (e.g., based on an inactivity timer maintained at the network), the network can send or direct the WTRU to the RRC_INACTIVE 802 or RRC_IDLE 803 mode.

[0083] If the network expects the WTRU to become active for a long duration, it can direct the WTRU to the RRC_IDLE mode 803. While in the RRC_IDLE 803, the WTRU can camp on the best cell (e.g., the cell with the best signal level at the highest priority RAT and the highest priority frequency within that RAT), which can facilitate the WTRU to establish a connection via that cell in case the WTRU needs to transition back to the connected mode. The WTRU can also monitor the downlink paging channel to detect the arrival of DL data. If the WTRU detects a paging indicating the arrival of DL data from the network or if the WTRU needs to send UL data, the WTRU can initiate a connection setup / establishment process.

[0084] The random access process can be performed in a contention-based manner called contention-based random access (CBRA) or in a contention-free manner called contention-free random access (CFRA). During the RACH process, the WTRU can send a message, called Msg1, on the RACH to the gNB, which contains a preamble and a RA-RNTI (random access - radio network temporary identifier). In the case of contention-based random access (CBRA), the preamble is randomly selected from a set of possible preamble values, which implies that there may be contention if another WTRU uses the same preamble value to initiate a random access process. In the case of contention-free random access (CFRA), a specific preamble is provided to the WTRU in advance (e.g., when the WTRU is in the connected mode, during the transition to the idle / inactive mode, etc.). The RA-RNTI is calculated based on the PRACH (physical RACH) occasion where the random access message is to be sent to the network.

[0085] When the gNB receives Msg1, it can respond with Msg2, which includes a Random Access Response (RAR). The network also sends Downlink Control Indicator (DCI) scrambled with the RA-RNTI in the PDCCH, which is used by the WTRU to determine on which resources (e.g., time and frequency resources) the RAR (and other relevant information) will be provided to the WTRU. The WTRU attempts to detect this DCI within a period of time (referred to as the RAR window) after transmitting the preamble. If this DCI is not received, the WTRU may retransmit the preamble. If the DCI is received, the WTRU will obtain the RAR in the PDSCH at the provided time and frequency resources. In the RAR and associated information, the WTRU will be provided with a Timing Advance (TA) to be applied to transmit UL data, a TC-RNTI (Temporary Cell RNTI), and UL resources for transmitting a setup / resume request message.

[0086] Two types of random access are supported in NR: 4-step RA (RACH) and 2-step RA (RACH). The 2-step RACH procedure is useful in scenarios where latency is important, due to the reduced signaling exchange required to complete the random access procedure.

[0087] In Figure 9 The 4-step random access procedure is illustrated in. The procedure is as follows: (1) The 4-step random access begins with the WTRU transmitting Msg1 901, which includes a preamble on the PRACH. When Msg1 901 is transmitted, the WTRU monitors for a random access response (e.g., RAR / Msg2) 902 from the network within the configured window. (2) When the WTRU receives the RAR 902, which includes a UL grant and a timing advance command, the WTRU applies the timing advance command and uses the UL grant provided in the RAR to transmit Msg3 903. (3) When Msg3 903 is transmitted, the WTRU monitors again for a network response (e.g., Msg4) 904 that includes contention resolution information. (4) If contention resolution is successful, the random access is complete and the WTRU begins the connection. If contention resolution fails, the WTRU restarts the random access again via the transmission of Msg1 901.

[0088] In Figure 10The 2-step random access procedure is shown. The procedure is as follows: (1) The 2-step random access begins with the transmission of MsgA, which includes a preamble on PRACH 1001 and a payload on PUSCH 1002. After the transmission of MsgA 1001, 1002, the WTRU monitors for a response (e.g., MsgB) 1003 from the network within the configured window, including information related to contention resolution. (2) If contention resolution is successful, the WTRU terminates the random access procedure. If contention resolution fails and a fallback indication is provided in MsgB 1003, the WTRU uses the UL grant contained within the MsgB fallback indication to perform a Msg3 transmission and begins to monitor for contention resolution (steps omitted in the figure). If contention resolution fails again after the Msg3 transmission, the WTRU resumes back to the MsgA transmission (steps omitted in the figure). If the MsgA transmission fails the configured number of times, the WTRU may resume back to the 4-step random access procedure (steps omitted in the figure).

[0089] The type of random access procedure to be used is selected at the initiation of the random access procedure (e.g., 4-step or 2-step), and the type is based on network configuration. When contention-free random access resources are configured, the WTRU performs a 4-step or 2-step random access depending on whether the random access resources correspond to 2-step or 4-step. If no contention-free random access resources are provided, the WTRU selects between 4-step and 2-step random access based on an RSRP threshold.

[0090] During RRC connection setup or resume, the WTRU first performs the described random access channel (RACH) procedure as described above. The RACH procedure is performed before the WTRU sends an RRCSetupRequest or RRCResumeRequest message. The RACH procedure serves two main purposes: to obtain UL synchronization between the WTRU and the network (e.g., gNB); and to obtain resources to be used for sending the request message. The WTRU may obtain detailed information / configurations related to the use of the random access channel, such as RACH occasion, random access response window, etc., via dedicated configuration when in connected mode, during a transition in idle / inactive mode, or from system information broadcast (SIB).

[0091] Figure 11 The RRC connection establishment / setup procedure is shown. Figure 12 The RRC connection resume procedure is shown. In Figure 11 and Figure 12 the RA procedure is omitted.

[0092] The term Msg3 is used to refer to RRCSetupRequest 1101 or RRCResumeRequest 1201. The term Msg4 is used to refer to RRCSetup 1102 or RRCResume 1202. The term Msg5 is used to refer to RRCSetupComplete 1103 or RRCResumeComplete 1103.

[0093] As can be seen in Figure 11 the RRC connection setup procedure is a lengthy procedure that requires several round-trip times to complete and it must involve the CN. This is because: when the WTRU goes to the idle mode, the RRC context of the WTRU is released and, as a result, the WTRU is not known at the RAN level and the RAN must obtain the WTRU context from the CN. Also, security must be re-established thereafter and the WTRU, which is reconfigured with DRBs and SRBs before UL / DL data transmission / reception, can appear.

[0094] This lengthy setup procedure is not compatible with low-latency services and, therefore, NR has introduced an intermediate mode between the connected and idle modes, called the inactive mode. This mode has most of the power-saving advantages of the idle mode (e.g., the WTRU does not need to continuously monitor the PDCCH, which is one of the most power-consuming procedures in the connected mode), but at the same time, the RAN still maintains the RRC / security context of the WTRU. When there is a need to transition the WTRU to the connected mode (e.g., due to the arrival of UL data or the reception of a paging indicating the arrival of DL data), the connection can be restored very quickly without involving the CN, thus re-establishing the WTRU's security context and reconfiguring the bearers.

[0095] When the WTRU performs a connection setup / establishment or resume procedure, it includes the setup or resume cause in the RRCSetupRequest or RRCResumeRequest.

[0096] Currently, the establishment causes are defined as: EstablishmentCause::=ENUMERATED{

[0097] Currently, the resume causes are defined as:

[0098] For example, if the connection is set / resumed due to a voice call or video call originating from the WTRU, the WTRU may set the establishment / resumption cause to mo-VoiceCall (mobile-originated voice call) or mo-VideoCall (mobile-originated video call). In another example, if the connection is set / resumed due to a downlink paging indicating DL data, the WTRU may set the establishment / resumption cause to one of mt-Access (mobile-terminated access), highPriorityAccess, mps-PriorityAccess, or mcs-PriorityAccess (according to the access category of the WTRU).

[0099] When the WTRU is sent to the inactive mode, the network includes a SuspendConfig message in the RRCRelease message. The SuspendConfig message may include the resumeIdentity (short identity shortI-RNTI and long identity fullI-RNTI) to be used by the WTRU. The WTRU may determine which identity to use based on the system information broadcast in the target cell (e.g., if useFullResumeID is indicated in the SIB, use the long identity, otherwise, use the short identity). The SuspendConfig message may include: the RAN paging area (e.g., a list of cells), which is the RAN area where the WTRU can be paged at the RAN level. If the WTRU performs cell reselection to a cell outside the RAN area, the WTRU may perform a RAN area update procedure. The SuspendConfig message may include: the nextHopChaining count, which is used to derive the security context (e.g., encryption / integrity protection keys) when resuming the connection.

[0100] The procedure for RAN area update is sometimes referred to as the "two-step resume" procedure because the WTRU sends a ResumeRequest indicating cell reselection outside the RAN area, and the network responds with a release message (e.g., including the new RAN area configuration). That is, the WTRU will still be in the inactive mode, and if there is a need to page the WTRU (e.g., DL data intended for the WTRU arrives at the RAN), the network now has information on which RAN area the WTRU can be accessed in.

[0101] The Small Data Transfer (SDT) procedure allows for data and / or signaling transfer while still in the RRC_INACTIVE state. SDT is enabled on a per-radio bearer basis and applies when the following conditions are met: (1) the amount of data across all radio bearers configured for small data transfer is less than the configured threshold; (2) the DL RSRP is above the configured threshold; and (3) valid ST resources are available.

[0102] The SDT procedure is initiated using a transmission on the RACH (which is configured via system information) or on type 1 configured grant (CG) resources (configured via dedicated signaling in the RRCRelease message). CG resources are only valid within the cell that provided the RRCRelease message, and based on the NW configuration, both two-step and four-step RACH can be used for small data transfer. The WTRU can transmit small data with a valid UL timing alignment only on the CG resources, which are maintained by the WTRU based on an SDT-specific timing alignment timer configured by the network via dedicated signaling.

[0103] When using CG resources, the network can schedule subsequent UL transmissions via dynamic grant or on subsequent CG resource occasions. The WTRU can initiate subsequent UL transmissions only after receiving an acknowledgement (dynamic UL grant or DL assignment) from the network for the initial PUSCH transmission. When using RACH resources, the network can schedule subsequent UL and DL transmissions using dynamic grant and DL assignment respectively after completion of the random access procedure.

[0104] Once initiated, the SDT procedure is completed successfully (e.g., after the WTRU is directed to RRC_IDLE or RRC_CONNECTED) or unsuccessfully (e.g., upon cell reselection, expiration of the SDT failure detection timer, reaching the maximum configured PRACH preamble transmission, or expiration of the SDT-specific timing alignment timer).

[0105] Some aspects of having location measurement / signaling / computation capabilities even when the WTRU is in an idle / inactive state may be desirable. For example, the WTRU may want to monitor its location and apply a certain behavior based on this (e.g., as required by a higher layer application, etc.). For example, in a Mobile Originated Location Request (MO-LR) scenario, it may be desirable for the WTRU to report location information to an application / higher layer in the WTRU on a periodic or event-triggered basis.

[0106] However, performing positioning related measurements / signaling / calculations is not compatible with the WTRU power saving targets for idle / inactive modes. Moreover, UL based positioning (e.g., using SRS for positioning) may not be feasible in some scenarios while the WTRU is in idle / inactive mode without transitioning the WTRU back to connected mode. Therefore, using the concept of positioning delegate for idle / inactive WTRUs is an attractive solution that can be adopted while still maintaining the WTRU power saving targets for the WTRU in those modes. However, currently, there is no process for supporting location delegate when the WTRU is in idle / inactive mode.

[0107] The (mobile) IAB scenarios discussed herein are illustrative example scenarios, and the solutions proposed herein may be applicable to any scenario in which there are groups of WTRUs that are in close proximity to each other and are served by the same node or (one or more) neighboring nodes. For simplicity, most of the solutions discussed herein consider GNSS as an alternative to cellular network-based positioning available to WTRUs. However, as described above, a large number of positioning methods that are not based on mobile networks are available and also applicable. The terms location representative, positioning representative, or location representative are used to refer to an entity (e.g., an IAB node, a gNB with a small coverage area, another WTRU, etc.) that performs positioning-related operations (e.g., measurements / calculations / reports, etc.) on behalf of the WTRU. LMF is a non-limiting example of a node or entity (e.g., a network node or entity) that can be used for positioning or supporting positioning. Any other node or entity may replace LMF and may still be consistent with the present disclosure. In the description herein, the terms "activity level", "mode", and "state" may be used interchangeably (e.g., idle activity level, idle mode, and idle state). In the description herein, the terms "camping cell" and "serving cell" may be used interchangeably. In the description herein, when describing some messages, a shorter version is used (eg, release message instead of RRCRelease, etc.).

[0108] The WTRU may be provided with the configuration information required to support the positioning delegate functionality.

[0109] In one embodiment, a WTRU may receive information related to one or more location representatives. In one example, the information may be received while the WTRU is in a second activity level. In another example, the information may be received during a transition from the second activity level to the first activity level. In one example, the information may be received while in the first activity level. In one embodiment, the first activity level may be a radio resource control (RRC) idle or RRC inactive connection mode, and the second activity level may be an RRC connected mode. In one example, the information may be used while in the first activity level. The WTRU may receive information related to the positioning capabilities of the location representative and how to obtain location information from the location representative (e.g., via an explicit request, via broadcast information, etc.). The WTRU may transition from the second activity level to the first activity level, e.g., in response to a received message (e.g., an RRC release message). The WTRU may select the location representative that is most suitable for the needs and conditions of the WTRU (e.g., which has a desired accuracy level, has the best signal level, higher layer applications, etc.). The WTRU may obtain or receive location information (e.g., absolute or relative) from the location representative while in the first activity level by performing one or more of the following (e.g., periodically, within a configured period, or intermittently, according to the needs of the WTRU and / or application (such as the needs of a higher layer application)): reading the system information of the location representative; sending a request in Msg1 during a 4-step random access (RA) procedure (RACH) and implicitly or explicitly receiving the location in Msg2; sending a request in MsgA during a 2-step RA procedure and implicitly or explicitly receiving the location in MsgB; or sending a request in Msg3 (e.g., an RRC resume request) and implicitly or explicitly receiving the location in Msg4 (e.g., an RRC release). A small data transfer (SDT) procedure and resources may be used to perform the location request and the reception of location information from the selected location representative.

[0110] Location representative information may be provided to the WTRU from a base station (eNB, gNB), or an LMF (or equivalent location management server), or an IAB node, or another network node (such as an AMF), or a combination thereof. Configuration information may be provided to the WTRU in RRC idle, inactive, connected, or a combination thereof.

[0111] The WTRU may be provided with location representative information while in connected mode (e.g., RRC reconfiguration message). The WTRU may be provided with location representative information during a transition to idle / inactive mode (e.g., RRC release message). The WTRU may be provided with information about the location representative capabilities of the cell on which it is camped on while in idle / inactive mode (e.g., broadcast information while camped on). The WTRU may be provided with information about the location representative capabilities of neighboring cells while camped on another cell in idle / inactive mode (e.g., broadcast information via the serving cell or broadcast information via neighboring cells). The location representative information may include simple information (e.g., 1-bit information) of whether location representative is supported.

[0112] In one embodiment, the location representative information may include one or more of the following information: the positioning method employed by the representative (e.g., WTRU-assisted, WTRU-based, DL-based, UL-based, GNSS, etc.); the accuracy level / estimate (e.g., confidence interval expressed in % or absolute value, confidence / accuracy level / percentage, etc.); how the location information is provided by the representative, which may be one or more of the following: a push process, such as a broadcast (including information about the periodicity of the location broadcast); a pull process, such as through a WTRU request; or a combination in which the WTRU can request / subscribe to the location representative and the location representative can provide the location to the WTRU on an agreed periodicity (in which case, what periodicity is supported); and whether the absolute position or only the relative position can be provided via broadcast (e.g., the WTRU may have to obtain the absolute position via dedicated signaling or process, and then obtain the relative position change via broadcast signaling or process). In one embodiment, the WTRU may receive relative location information (e.g., a delta position from a previously provided position) from the network.

[0113] In one embodiment, the location representative information may include information for more than one location representative (eg, a list of location representative identifiers, such as a cell ID for a mobile cell or a WTRU ID for a location representative WTRU, and corresponding positioning representative information).

[0114] In one embodiment, the WTRU may be configured manually with information regarding one or more location representatives at the application layer or by another means outside the RAN.

[0115] The indication of the location representative can be an implicit indication. For example: The cell involved (e.g., the serving cell, neighboring cell) broadcasts location information. The cell involved is a mobile IAB cell. The WTRU can receive the broadcast of location information with an associated LPP session ID from the cell involved. The LPP session ID can also be associated with a unique ID for the WTRU (e.g., RTNI, recovery identity, etc.) or a unique ID for a group of WTRUs, indicating that the node / cell involved has established an LPP session with the LMF on behalf of the WTRU.

[0116] The WTRU can be configured with different periodicities for obtaining location information that can depend on the time of day (e.g., different periodicities for different time intervals).

[0117] The WTRU can be configured with different periodicities for obtaining location information that can depend on the current location of the WTRU (e.g., different periodicities for different ranges of location coordinates).

[0118] The WTRU can be configured with different periodicities for obtaining location information that can depend on the current mobility state of the WTRU (e.g., different periodicities for different ranges of WTRU speed, such as no mobility, low mobility, medium mobility, high mobility, etc.).

[0119] The WTRU can be configured with different periodicities for obtaining location information that can depend on the signal level of the current serving cell (e.g., different periodicities for different ranges of RSRP of the serving cell, different periodicities depending on how fast / slow the RSRP changes, etc.).

[0120] The WTRU can be configured with different periodicities for obtaining location information that can depend on the location change (e.g., rate of change) indicated as obtained previously (e.g., less frequent acquisition if a certain number of consecutive acquired locations are not so different from each other; more frequent acquisition if there are significant differences in consecutive acquired locations; etc.).

[0121] Based on the above information, the WTRU can decide whether to use the location representative. In one embodiment, the WTRU selects a representative and temporarily or sporadically determines its own location (e.g., measures a positioning signal and estimates its own location), and compares it with the location provided by the representative. If there is a consistent difference or if the difference is small compared to the required accuracy, the WTRU can continue to use the location information provided by the representative.

[0122] The WTRU can be configured to use the location representative when in the idle / inactive mode and read the system information of the serving cell (e.g., a specific SIB for obtaining location information) to obtain location information.

[0123] The WTRU may be configured to use location representation when in idle / inactive mode and read location information by sending a request to the network without transitioning to the connected mode.

[0124] The WTRU may be configured to receive location information from the representation at a certain periodicity (e.g., read the relevant SIB every x milliseconds or complete a request for location information, etc.). The WTRU may receive absolute location information from the network.

[0125] The WTRU configured to use location representation in idle / inactive mode when determining that the new resident cell does not support location representation may send an indication related thereto to the network without transitioning to the connected mode.

[0126] The WTRU configured to use location representation in idle / inactive mode when determining that the new resident cell does not support location representation may trigger connection recovery or connection establishment (e.g., including a new establishment or recovery cause value indicating this).

[0127] The WTRU configured to use location representation in idle / inactive mode when determining that the new resident cell does support location representation (while the previous resident cell did not) may send an indication related thereto to the network without transitioning to the connected mode.

[0128] The WTRU configured to use location representation in idle / inactive mode may preferentially camp on a cell that provides location representation, even if that cell may not be the best cell according to traditional cell reselection principles. For example, the WTRU may be configured to apply a positive offset on top of the measurement results of cells that can provide location representation (e.g., the current serving cell, neighboring cells, etc.). In an alternative embodiment, the WTRU may be configured to apply a negative offset on top of the measurement results of cells that do not provide location representation (e.g., the current serving cell, neighboring cells, etc.).

[0129] According to the location capabilities of the representation, the WTRU may be configured with different offset values / ranges (e.g., different values or value ranges for different accuracy levels and / or positioning methods and / or location update periodicities, etc.).

[0130] The WTRU may be configured to apply the offset or apply different offsets according to the current WTRU conditions. For example, the WTRU may be configured to: if its battery level is below a certain level and / or if it determines that its own location determination is no longer accurate enough (e.g., when indoors, etc.), then start applying the offset or start using a higher offset for the location representation cell.

[0131] The WTRU may be configured to camp on the best cell according to traditional principles (e.g., the best cell from a signal level perspective on a prioritized frequency / RAT), but when it comes time to obtain location information, it will obtain the location from an adjacent cell that provides location representation (e.g., read the SIB of the adjacent cell, send a request to the adjacent cell, etc.).

[0132] The WTRU may be configured with timing information (e.g., specifying a duration) and / or location margin information (e.g., absolute or relative offset) that may be associated with performing positioning measurements when camping on a node / cell that is a location representative. For example, the WTRU may be configured to: continue performing positioning measurements for a specified duration after camping on a cell that is a location representative; and compare the location information it has determined with the location information provided by the representative. If, during that time period, the determined location is the same as or within a specified absolute or relative location margin of the location provided by the representative, the WTRU may consider the location determination made by the representative to be accurate enough and stop performing its own location determination (e.g., performing GNSS or PRS measurements). The WTRU may send an indication related thereto (e.g., that it has verified the location accuracy provided by the representative and has stopped performing measurements itself) to the network (e.g., the LMF). This may be done without the WTRU transitioning to the connected mode.

[0133] The WTRU may determine its own location and continuously compare the location difference between the location it has determined and the location provided by the location representative. This comparison process may occur for a specified duration or for multiple instances. If there is a significant difference between the two (e.g., above a certain margin) but the difference is consistent (e.g., within another specified margin), the WTRU may consider the location information provided by the representative to be accurate enough and stop its own location determination (e.g., performing GNSS or PRS measurements). When the WTRU receives future location information from the representative, it may take the difference into account. The WTRU may send an indication related thereto (e.g., that it has verified the location accuracy provided by the representative and that it has detected a consistent difference of x meters between the two and has stopped performing measurements) to the network (e.g., the LMF). The LMF may thus apply the difference on top of the location provided by the representative to determine a more accurate location of the WTRU. This may be done without the WTRU transitioning to the connected mode.

[0134] The WTRU may be configured to: occasionally or periodically start location measurements and / or determinations when in the idle / inactive mode to verify whether the location provided by the representative is still accurate or whether the difference is consistent. For example, the WTRU may be configured to perform location determination / comparison every x minutes. If the location information is still accurate or consistent, the WTRU may send an indication to the network. This may be done without the WTRU transitioning to the connected mode.

[0135] The WTRU may be configured to: send an indication to the network when the location representative is no longer used / needed (e.g., the location representative accuracy is not good enough, as determined during initial cell reselection or during occasional / periodic verification while camping on a cell, etc.). The WTRU may be configured to: trigger connection establishment / resumption; and add a cause value indicating why the location representative is no longer used / needed. The WTRU may send the information to the network without transitioning to the connected mode.

[0136] As described above, it is beneficial to enable the WTRU to send a location request to the network, or receive location information from the network, or send additional information related to the use of the location representative while still in the inactive / idle mode, e.g., in terms of reducing power consumption and signaling overhead. The reuse of existing messages to support the location representative function may also contribute positively to the reduction of power consumption and signaling overhead. Processes that are part of the current behavior of the WTRU may be enhanced to support location processes.

[0137] The WTRU may request a location update from the representative by performing a two-step recovery-like scheme. For example, the WTRU may use a specific cause value (e.g., position_update_request) to send a recovery / setup request message. The WTRU may further indicate additional information in the recovery / setup request message (e.g., whether the requested location information is absolute or relative, etc.). The network may send the location information in a release message. In one embodiment, the network may send the location information in a recovery message.

[0138] To initiate or stop communication related to the use of network-assisted location representation or to perform cell reselection from a cell supporting representation to a cell not supporting representation (or vice versa), the WTRU may perform a two-step recovery-like procedure. For example, the WTRU may use specific cause values (e.g., position_delegation_started, position_delegation_stopped, cell_reselection_to_a_position_delegate, cell_reselection_away_from_a_delegate, etc.) to send a recovery / setup request message, and the gNB may inform the LMF of this. The recovery request may include information about the difference / deviation between the location provided by the delegate and the location initially measured / determined by the WTRU. The network may respond to the WTRU with a release message. The release message may include information about other alternative positioning delegates or may be used to configure the WTRU to perform positioning measurements while in idle / inactive mode. Alternatively, since the network may want the WTRU to move to the connected mode, the network may decide to resume or establish a connection for the WTRU (e.g., if the WTRU has indicated the stop of using a delegate) in order to start performing UL-based positioning, e.g., via SRS.

[0139] The information for supporting the positioning delegate function may indicate specific methods to request a location update. For example, the WTRU may be provided with one or more of the following: a set of preambles; a set or RACH occasion; or a dedicated RNTI. The information for supporting the positioning delegate function may be provided to the WTRU via one or more of the following methods: within system information; via a dedicated RRC message (e.g., in an RRC release and / or an RRC release with a suspend message); or via a random access message (e.g., Msg2, Msg4, and / or MsgB), or a combination thereof.

[0140] The WTRU may assume that the information used to support the provided positioning representative function (e.g., RACH preamble, RACH occasion, etc.) may be valid in one or more of the following: indefinitely (e.g., for any serving cell, or regardless of the RRC mode until it is otherwise informed); for all serving cells within a tracking area (TA) or RAN area; for all cells served by the same CU; for all cells served by the same DU; for the indicated set of cell IDs (e.g., PCI, PCI range, etc.); within the same serving cell that broadcasts the configuration / indication; while the WTRU is still in the RRC_INACTIVE mode (e.g., when transitioning to RRC idle, the WTRU may no longer assume that the configured preamble and / or RACH occasion may be valid for location update requests); for a specific signaling method, e.g., the WTRU may only assume that the preamble and / or RACH occasion is valid for one or more of the following: 4-step random access; 2-step random access (via SDT of RACH or via SDT of configured grant); and for cases where the RSRP is above a threshold (e.g., if the measured SSB is above a preconfigured threshold).

[0141] Figure 13An example is shown in which location information can be sent in a broadcast channel or via a dedicated request / response procedure when the WTRU is in the idle / connected mode. The WTRU can receive configuration 1301 in the RRC connected mode. The configuration information can include one or more of the following: one or more candidate representatives with associated identifiers; candidate representative capabilities (e.g., positioning methods used, accuracy levels, capability-based offsets, QoS support); methods for obtaining location information from the network (e.g., broadcast, request / response, reserved resources, LPP protocol, RRC protocol); whether location information can be provided periodically or intermittently or is event-driven; absolute versus relative location provisioning; positioning methods employed by the representative (e.g., WTRU-assisted, WTRU-based, DL-based, UL-based, GNSS, etc.); accuracy levels / estimations (e.g., confidence intervals expressed as % or absolute values, confidence / accuracy levels / percentage, etc.); how location information is provided, which can be one or more of the following: push procedures such as broadcast (including information related to location broadcast periodicity); pull procedures such as via WTRU request; a combination where the WTRU can request / subscribe to a location representative and the location representative can provide the location to the WTRU at an agreed-upon periodicity (in which case, what periodicities are supported); whether absolute location can be provided via broadcast or only relative location (e.g., the WTRU may have to obtain the absolute location via dedicated signaling or procedures and then obtain relative location changes via broadcast signaling or procedures); and configuration of preambles and / or RACH opportunities for location updates, details / configurations related to the use of the random access channel such as RACH opportunities and random access response windows. The configuration can include: configuration of reference signals (SRS, PRS) for the serving cell and optionally for neighboring cells; measurement configuration; and any location influencing factors (e.g., mobility, location, time of day).

[0142] Location representative information can be provided to the WTRU from a base station (eNB, gNB), or an LMF (or equivalent location management server), or an IAB node, or another network node (such as an AMF), or a relay WTRU, or another WTRU, or a combination thereof.

[0143] The network may release the RRC connection 1302 and send the WTRU to the RRC idle or RRC inactive mode 1303. The WTRU may select a representative 1304 based on one or more of radio signal level, desired accuracy level, and configuration information for supporting the positioning representative function, among other factors. Information regarding which representative is selected may be sent to the LMF and / or gNB. When the location is determined by the representative, the representative may send the location information in a broadcast channel 1305, and the WTRU may read the broadcast channel to obtain its location information 1306. If the representative does not send the location information in the broadcast channel 1307, an explicit request / response for location update may be required 1308. The explicit request / response process for location update may occur in RRC idle or inactive. The explicit request / response process may be accomplished by reusing existing messages for a new purpose.

[0144] The WTRU may indicate the start / stop of using the location representative, or cell reselection towards the location representative, or cell reselection away from the location representative by using a specific preamble configured for this purpose in Msg1. The WTRU may request a location update from the representative by using a specific preamble configured for this purpose in Msg1. The WTRU may request a location update from the representative by using a specific RACH occasion configured for this purpose. The WTRU may request a location update from the representative by using a specific RNTI configured for this purpose. The WTRU may request a location update from the representative by using a combination of a specific preamble and / or RACH occasion and / or RNTI configured for this purpose in Msg1.

[0145] The WTRU may receive a location update from the representative in Msg2. For example, if the WTRU initiates random access via one or more of the above methods (e.g., via a dedicated preamble and / or RACH occasion and / or RNTI), and the resources are still valid (e.g., the Msg1 transmission occurs on a valid cell), the WTRU may assume that Msg2 contains the location update. The location update may be included in Msg2 by reusing one or more of the Msg2 fields for a new purpose (e.g., the TAC (Timing Advance Command) field and / or the (one or more) UL grant fields for Msg3 transmission). The WTRU may receive an indication regarding which (which) fields are reused for the new purpose, e.g., indicated by the following: explicitly indicated within Msg2 (e.g., via the Msg2 header and / or flag); indicated via system information; preconfigured via RRC (e.g., indicated within RRCRelease or RRCRelease with a pending indication); or provided within the CG (configured grant) configuration.

[0146] The WTRU may alternatively determine whether a field can be reused for a new purpose, e.g., based on one or more of the following conditions: if the RSRP is above a configured threshold, the TAC field may be reused for a new purpose; or if the WTRU does not request a transition to connected or the WTRU requests any further information, the Msg3 UL grant field may be reused for a new purpose.

[0147] Upon successful acquisition of the location information in Msg2, the WTRU may, e.g., perform one or more of the following actions: stop the random access procedure; continue the random access procedure; restart the random access procedure; remain in RRC_INACTIVE; and remain in and / or transition to RRC_IDLE.

[0148] The WTRU may request a location update during Msg3 transmission. For example, the WTRU may include an explicit request in the Msg3 PUSCH resource. Whether the WTRU may request a location update in Msg3 may also be based on whether the WTRU has previously requested location information during Msg1 transmission and / or Msg3 transmission.

[0149] The WTRU may request a location update from the representative by using a specific preamble and / or RACH occasion and / or RNTI configured for that purpose in MsgA during a 2-step RACH. The WTRU may include a request for location information within the MsgA PUSCH resource. Whether the WTRU may include a request for location information in the PUSCH resource may depend on whether the MsgA preamble is used for a location request. For example, the network may interpret one or more fields of the MsgA PUSCH resource differently (e.g., for the purpose of a location request) based on the content or the MsgA preamble.

[0150] The WTRU may indicate the start / stop of using a location representative, or cell reselection towards a location representative, or cell reselection away from a location representative, by using a specific preamble configured for that purpose in MsgA during a 2-step RACH.

[0151] The WTRU may receive a location update from the representative in MsgB during a 2-step RACH. For example, the content of MsgB may be modified similarly to Msg2. In another example, the location information may be provided in the MsgB PDSCH resource.

[0152] The WTRU may be configured to use a small data transfer (SDT) procedure to transmit a location request and / or receive a location update. Whether the WTRU may use the SDT procedure for a location request may be subject to configuration (e.g., based on one or more of an enable / disable indication, per radio bearer configuration, based on an RSRP threshold, or based on the SDT type, such as RACH-based SDT or CG-based SDT).

[0153] In one embodiment, the WTRU may request a location update only in an initial SDT. In another example, the WTRU may request location information only within a dynamic authorization received in response to an initial SDT.

[0154] In one example, upon successful acquisition of location information during an SDT procedure, the WTRU may stop the random access procedure and / or the SDT on the procedure. In another example, the WTRU may continue the SDT procedure.

[0155] Figure 14 A high-level view of an example of a location representation procedure is depicted. In one example, the WTRU may be in any mode (RRC idle, inactive, or connected) 1401. In one example, the WTRU may request configuration information to support a location representation function from the network 102. Optionally, the network may configure the WTRU autonomously 1403. The provided configuration information is to be used in the RRC idle mode. The WTRU may select the most suitable location representative based on several factors (e.g., desired accuracy, desired method for determining location, location history, WTRU location, WTRU speed, etc.) 1404. The WTRU may notify the network (e.g., gNB, LMF) of the selected representative 1405. When the WTRU is in RRC idle or RRC inactive 1406, it may obtain its location information from the selected representative 1407 without transitioning to the RRC connected mode. The location representative may be a gNB, an IAB node, or a WTRU. The location representative may determine the location of a specific WTRU on behalf of the WTRU, thus allowing the WTRU to remain in the inactive or idle mode.

[0156] In one embodiment, the WTRU may receive configuration information to support a location representation function including candidates for a location representative from the network. The information may include: a list of location representative candidate identifiers; for each candidate representative: representative capabilities, such as the positioning method used, accuracy level; the method used to be represented for location determination; information related to one or more reference signals (RS) such as PRS, SRS, etc.; measurement configuration; support for periodic and / or event-based location determination; and absolute versus relative location provisioning.

[0157] When the WTRU is in RRC idle / inactive, it can receive location information from a representative. The WTRU can use this information and maintain a history of location information, allowing for the calculation of statistics, comparison of consecutive locations, and use of historical data to improve its positioning requirements.

[0158] With the desired accuracy, the WTRU can use the representative location as its own location. In one example, a mobile IAB node can be in a train or bus and can determine its own location. The WTRU, which is also in the train or bus, can determine its own location once and then calculate its distance from the mobile IAB node. From that point on, if the mobile IAB broadcasts its own location, the WTRU can also calculate its own location.

[0159] Figure 15 An embodiment of a positioning representative process is shown in which the WTRU can be at a first or second activity level. It should be noted that Figure 15 is split across 2 figures, Figure 15 and Figure 15 (continued). The first activity level can correspond to RRC idle or RRC inactive, and the second activity level can correspond to RRC connected. The WTRU is at the second activity level 1501. Configuration information for supporting the positioning representative function can be received by the WTRU when it is at the second activity level 1502 or during a transition 1503 between the second and first activity levels (e.g., in an RRC connection release message). The WTRU can select a location representative 1504 after transitioning to the first activity level as shown in 1505. Optionally, the WTRU can select a location representative (an option omitted from the figure) when it is at the second activity level or during a transition between the second and first activity levels. In one example, a location representative can be used when the WTRU is at the first activity level 1505. Optionally, the WTRU can use a location representative at any activity level (an option omitted from the figure). The WTRU can use other information such as location history, location requirements, application requirements, WTRU measurement results, gNB measurement results, etc., in addition to using candidate configurations when selecting a representative 1506. The WTRU notifies the network of the selected location representative 1507.

[0160] Refer to Figure 15(Continued), when the WTRU needs location information 1508, it can use a request / response process on a message 1509 that is reused for a new purpose or use it in a broadcast channel 1510. The WTRU can provide location information to the LMF and / or its applications and can also process and maintain statistical data 1511 of the location information, which can be used by the WTRU later, for example, as one of the inputs for a representative selection process 1506.

[0161] Figure 16 Another embodiment of the location representative process is shown. In this embodiment, a configuration can be sent to the WTRU 1601 when the WTRU is at a first activity level. The WTRU can receive configuration information via a broadcast channel 1602. The remainder of the process is equivalent to the process described in the Figure 15 embodiment.

[0162] Although the features and elements are described above in specific combinations, those skilled in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. Additionally, the methods described herein can be implemented in a computer program, software, or firmware that is incorporated into a computer-readable medium for execution by a computer or a 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 memories, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, WTRU, terminal, base station, RNC, or any host computer.

Claims

1. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: Receiving, from a network associated with the WTRU, configuration information comprising one or more identifiers, each of the one or more identifiers being associated with one or more location representative candidates to be used at a first activity level; Selecting a location representative from the one or more location representative candidates to be used at the first activity level; Transmitting, to the network, one or more identifiers associated with the selected location representative; And Receiving location information from the selected location representative.

2. The method according to claim 1, wherein the first activity level is radio resource control (RRC) idle or RRC inactive mode, and the second activity level is RRC connected mode.

3. The method according to claim 1 or 2, wherein receiving configuration information comprising one or more identifiers from a network associated with the WTRU is performed while in the first activity level.

4. The method according to any one of claims 1 to 3, wherein transmitting the one or more identifiers to the network is performed while in the first activity level.

5. The method according to any one of claims 1 to 4, further comprising: Transmitting a location request to the selected location representative while in the first activity level.

6. The method according to any one of claims 1 to 5, wherein receiving location information from the selected location representative is performed while in the first activity level.

7. The method according to claim 5, wherein transmitting a location request to the selected location representative is performed in Msg1 or in Msg3 during a 4-step RACH procedure.

8. The method according to claim 5, wherein transmitting a location request to the selected location representative is performed in MsgA during a 2-step RACH procedure.

9. The method according to any one of claims 1 to 8, wherein transmitting the one or more identifiers to the network is performed in Msg1 or in Msg3 during a 4-step RACH procedure.

10. The method according to any one of claims 1 to 8, wherein transmitting the one or more identifiers to the network is performed in MsgA during a 2-step RACH procedure.

11. The method according to any one of claims 1 to 10, wherein receiving location information from the selected location representative is performed in Msg2 or in Msg4 during a 4-step RACH procedure.

12. The method according to any one of claims 1 to 10, wherein receiving location information from the selected location representative is performed in MsgB during a 2-step RACH procedure.

13. The method according to any one of claims 1 to 10, wherein receiving location information from the selected location representative is performed using a small data transfer (SDT) procedure.

14. The method according to any one of claims 1 to 10, wherein receiving location information from the selected location representative is performed in a broadcast or multicast channel.

15. The method according to any one of claims 1 to 14, further comprising: Transmitting the location information received from the selected location representative to the network.

16. The method according to claim 15, wherein transmitting the location information received from the selected location representative to the network is performed in Msg1 or in Msg3 during a 4-step RACH procedure.

17. The method according to claim 15, wherein transmitting the location information received from the selected location representative to the network is performed in MsgA during a 2-step RACH procedure.

18. A wireless transmit / receive unit (WTRU), the WTRU comprising: a processor; a communication interface; the processor and the communication interface are configured to receive configuration information including one or more identifiers, each of the one or more identifiers being associated with one or more location representative candidates to be used at a first activity level; the processor is configured to select a location representative from the one or more location representative candidates to be used at the first activity level; the processor and the communication interface are configured to transmit to the network one or more identifiers associated with the selected location representative; and the processor and the communication interface are configured to receive location information from the selected location representative.

19. The WTRU according to claim 18, wherein the one or more identifiers include a physical cell identifier (PCI).

20. The WTRU according to claim 18 or 19, wherein the processor configured to select a location representative is further configured to: select the location representative based on one or more of a desired accuracy level, a best signal level, or a higher layer application requirement.

21. The WTRU according to any one of claims 18 to 20, wherein the received configuration information includes one or more of the following: the accuracy level / estimate of the location information, the confidence interval or granularity of the location information, positioning methods such as WTRU-assisted, WTRU-based, DL-based, UL-based, GNSS-based, etc. adopted by the location representative; the frequency of location determination, such as periodic, on request, or event-based location determination; and an indication of whether it supports the absolute value, relative value, or both absolute and relative values of the location.

22. The WTRU according to any one of claims 18 to 21, wherein the received location information is received periodically.

Images