Methods and apparatus for measurement reporting based on prediction of time of stay in a cell

Abstract

A wireless transmit and receive unit (WTRU) may have the capability to predict a time of stay in a cell. The WTRU may send the capability to a network, and the network may configure the WTRU to report a condition associated with the predicted time of stay in a cell. The condition may be e.g., the predicted time of stay in a cell being less than a configured threshold. Upon detecting the condition, the WTRU may send a notification to the network. The WTRU may include, in the notification to the network, at least one of a time duration until the predicted time value when a handover will occur, a predicted buffer level at the predicted time value when the handover will occur, or a predicted signal level at the predicted time value when the handover will occur.

Description

METHODS AND APPARATUS FOR MEASUREMENT REPORTING BASED ON PREDICTION OF TIME OF STAY IN A CELLCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 602,284, filed November 22, 2023, U.S. Provisional Application No. 63 / 602,286, filed November 22, 2023, U.S. Provisional Application No. 63 / 602,288, filed November 22, 2023, the contents of which are incorporated herein by reference.BACKGROUND

[0002] Existing wireless transmit receive units (WTRU) mobility procedures are reactive and rely on current measurements being available at the WTRU. For instance, measurement may be reported by the WTRU and the gNB may send the Handover (HO) command In some cases, a Conditional Handover (CHO) may be configured in the WTRU and the WTRU may execute the handover when the CHO conditions are fulfilled. The existing handover process may increase the overhead on both the WTRU and network sides, e.g., WTRUs may continuously perform measurements of neighbor cells and evaluate measurement reporting or CHO conditions. In the case of CHO, resources on several candidate neighbor cells must be reserved in anticipation of the WTRU handing over to one of these cells.SUMMARY

[0003] This disclosure pertains to procedures, methods, architectures, apparatus, systems, devices, and computer program products for, and / or directed to, utilizing a capability of a WTRU to predict or estimate a time of stay in a cell.

[0004] In some examples, the WTRU may determine that the reporting conditions are fulfilled (e.g., based on one or more of: measurements, determined predicted time of stay left in a current serving cell, configured reporting events, and reporting configuration). The WTRU may predict detailed information about one or more neighbor cells and may send a measurement report that includes the detailed information and the identities of the one or more neighbor cells. The WTRU may optionally select a subset of neighbor cells for which to report detailed information, based on one or more of cell measurements, predicted detailed information of the cells, ranking of measurements of cell, configured thresholds. In one example, the WTRU may report neighbor cell measurements for neighbor cells whose measurements or predicted detailed information is greater than of minimum threshold.

[0005] Existing mechanisms for mobility and beam change / switching are reactive in that candidate cells for mobility can only be determined after a certain number of measurements for potential candidate cells have been recorded. With knowledge of its upcoming trajectory for a predetermined time window (e.g., trajectory prediction via AI / ML model at the WTRU and / or gNB), proactive methods for mobility, which may bring several benefits: The WTRU may not need to measure all the neighbor cells for a potential handover candidate, which may save battery consumption; the WTRU may be able to perform handover faster and with less overhead; the WTRU may make more accurate selection of candidate cell (since the AI / ML model may be able to anticipate the length of time in each cell based on the trajectory).

[0006] For AI / ML model(s) for trajectory prediction at the WTRU, the WTRU may report the predicted trajectory to the network. This may be accompanied by timing information (e.g., the WTRU may report the corresponding time instance with every position / coordinate of the trajectory). For AI / ML model(s) for trajectory prediction at the network, the network may predict the trajectory of more than one WTRU over a time window. During that time window, the WTRU may be configured to report some measurements to the network (e.g., positioning) for the network to validate that its trajectory prediction is accurate.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein:

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

[0009] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0010] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0011] FIG. 1D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment; and

[0012] FIG. 2 illustrates an example of the communication between the WTRU and the network for supporting mobility enhancements based on AIML predictions.

[0013] FIG. 3 illustrates the trajectory of a WTRU moving within an ideal coverage scenario of a cell.DETAILED DESCRIPTION

[0014] The following acronyms are used herein:BM Beam ManagementCA Carrier AggregationCHO Conditional HandoverCSI Channel State InformationDC Dual ConnectivityDL DownlinkHO HandoverHOF Handover FailureLMF Location Management FunctionLTM L1 / L2 Triggered MobilityOTT Over The TopPCell Primary CellPSCell Primary Secondary CellRA Random AccessRLF Radio Link FailureRRC Radio Resource ControlRSRQ Reference Signal Received QualityRSRP Reference Signal Received PowerSCell Secondary CellSI NR Signal to Interference Noise RatioSNR Signal to Noise RatioTA Timing AdvanceTTT Time To TriggerUL Uplink

[0015] Terminology:

[0016] The terms AI / ML and AI / ML may be used interchangeably.

[0017] The terms “prediction”, “projection”, “expectation”, and “estimation” may be used interchangeably.

[0018] The terms “predicted”, “projected", “expected”, and “estimated” may be used interchangeably.

[0019] The terms “report” and “indication” may be used interchangeably.

[0020] The term Ax is used to refer to any of the events A1 , A2, A3, A4, A5, A6.

[0021] The term Bx is used to refer to any of the events B1 , B2.

[0022] The term Condx refers to any of the conditional events Cond Event A3, Cond Event A4, Cond EventA5, Cond Event D1 , Cond Event T 1 .

[0023] The term HO is used to describe either a legacy HO (e.g., RRC triggered handover) or a L1 / L2 triggered HO (LTM).

[0024] The term CHO is used to describe either a legacy CHO (e.g., an RRC HO command that is preconfigured at the WTRU and executed when the CHO conditions are fulfilled) or an LTM CHO (e.g , an LTM configuration that is executed when certain LTM trigger conditions are fulfilled).

[0025] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail, so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples described, disclosed, or otherwise provided explicitly, implicitly and / or inherently (collectively "provided") herein.

[0026] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 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), singlecarrier 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), and the like.

[0027] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (ON) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though itwill 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 a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operatingon commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a WTRU.

[0028] The communications systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While 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.

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

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

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

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

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

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

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

[0036] The base station 114b in FIG 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may 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.

[0037] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1 A, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition tobeing connected to the RAN 104, which may be utilizing a NR radio technology, the ON 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0040] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0041] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

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

[0048] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (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, and the like. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like.

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

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

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

[0052] 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, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0053] The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While 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.

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

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

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

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

[0058] Although the WTRU is described in FIGS. 1A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0059] In representative embodiments, the other network 112 may be a WLAN.

[0060] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA The traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. The peer-to- peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., allof the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.

[0061] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0062] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0063] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0064] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11ah relative to those used in 802.11n, and 802.11ac. 802.11 af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine- Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g , only support for) certain and / or limited bandwidths The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0065] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802 11 n, 802.11ac, 802.11af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by allSTAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

[0066] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

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

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

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

[0070] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g.,such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may 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 may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non- standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0071] Each of the gNBs 180a, 180b, 180c 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, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0072] The CN 106 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While 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.

[0073] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized 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 MTC access, and the like The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

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

[0076] The CN 106 may facilitate communications with other networks For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0077] In view of FIGs. 1A-1 D, and the corresponding description of FIGs. 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0078] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices may perform the 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 may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network The emulation device may be directly coupled to another device for purposes of testing and / or performing testing using over-the-air wireless communications.

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

[0080] Existing WTRU mobility procedures are reactive and rely on current measurements being available at the WTRU. For instance, measurement may be reported by the WTRU and the gNB may send the Handover (HO) command. In some cases, a Conditional Handover (CHO) may be configured in the WTRU and the WTRU may execute the handover when the CHO conditions are fulfilled. The existing handover process may increase the overhead on both the WTRU and network sides, e g., UEs may continuously perform measurements of neighbor cells and evaluate measurement reporting or CHO conditions. In the case of CHO, resources on several candidate neighbor cells must be reserved in anticipation of the WTRU handing over to one of these cells.

[0081] If a WTRU has a capability to do trajectory prediction (e.g., based on an AI / ML model), such as estimating the expected time of stay in a serving cell, a more proactive approach for mobility handling may be implemented (e.g., a system with AI / ML mechanism may be implemented). With the advancement of AI / ML mechanisms, some models may be trained to predict the trajectory of the WTRU, at least within a short / limited time horizon. Having such information may facilitate making mobility decisions in a proactive approach. Using a proactive approach may allow, e.g., the network to better prepare target cell candidates, to anticipate spectrum usage, to estimate how much time a WTRU will need to be served in a given cell, etc.

[0082] To leverage predictive information about WTRU trajectory for more optimal / robust WTRU mobility handling, a new trigger may be defined for the WTRU to report to the Network (NW) on imminent mobility The WTRU may be configured, e.g., with a time threshold, RSRP threshold, buffer threshold, etc. For example, by leveraging on its own trajectory prediction, the WTRU may be able to assess if the predicted remaining time in the current serving cell is lower than a configured time threshold.

[0083] In one example, the WTRU may send an indication / report to the NW when the remaining time is lower than the configured time threshold.

[0084] In one example, the WTRU may determine when to start performing neighbor cell measurement based on the serving cell radio signal level and the expected / predicted time of stay in that cell.

[0085] In one example, the WTRU may be configured to report to the NW on information related to the conditions that triggered it to start monitoring neighbor cells.

[0086] In one example, the WTRU may trigger the sending of detailed information related to HO candidate cells based on a configured criteria. The detailed information related to HO candidate cells may comprise predicted time of stay in a cell, predicted cell quality, confidence or likelihood of a target cell being the best cell, etc. Additionally, the WTRU may execute a HO, e.g., via a received CHO configuration, based on the detailed information that it determines.

[0087] The term “quality” may be used to refer to cell quality, link quality or radio quality. The cell / link quality may be evaluated based on one or more WTRU measurements, such as measured Reference Signal ReceivedQuality (RSRQ), Reference Signal Received Power (RSRP), Signal to Noise Ratio (SNR), and / or Signal to Interference Noise Ratio (SINR). The WTRU performs the measurements and processes them to compare with configured thresholds. Examples of thresholds may include the minimum value of a signal level measurement, e.g., the cell / link quality may be considered good only if the measured signal level (or an average of the measurements) is above a threshold; the maximum number of times a measured signal level is below a threshold, e.g., the WTRU counts the number of times a signal level is below a threshold in the cell, and the cell / link quality may be considered good if the count is below a threshold; the maximum drop rate of a signal level measurement, e.g., the cell / link quality may be considered good only if the drop rate of a measured signal level is below a threshold

[0088] A time duration may be associated with the evaluation. The network may configure a period of time for the quality evaluation, such as from time t_1 to t_2; the network may configure a time duration, such as a moving window of size Td. For example, the cell / link quality may be considered good if the average RSRP remains above a threshold for a time duration of Td, where Td may be a moving window and the average RSRP may be calculated based on measurements taken during the moving window Td. The WTRU may determine the cell / link quality at several points as it moves through the cell (e.g., the WTRU determines the quality every time it takes a new measurement), and continuously processes the results of the several points. This may follow a periodic fashion, e.g., when periodic measurements are configured.

[0089] A combination of measurements may be used for cell / link quality evaluation. For example, the quality may be considered good if the average RSRP is above a threshold and a maximum number of SNR values being below a threshold is not reached. As another example, the quality may be considered good if, during a time window Td, the RSRQ drop rate remains below a threshold; the average SINR remains above a threshold, and the number of times the RSRP is below a threshold is less than the maximum number allowed.

[0090] The cell quality may be determined by processing several measurements based on an equation or formula given a number as a result and the quality is determined to be good only if that resulting number is above a threshold.

[0091] The cell / link quality can be predicted or estimated for a future point in time using AI / ML . The predicted or estimated cell / link quality may be determined by the WTRU using different methods For example, the WTRU may use a configured set of rules for quality evaluation (such as the many examples provide above) and it may predict the results for each of the applicable measurements, and then determine the predicted cell / link quality based on the predicted measurement results. The WTRU may use neighbor cell measurements to determine the neighbor cell quality. The WTRU may predict the neighbor cell measurements to determine the predicted neighbor cell quality.

[0092] A WTRU may perform measurements of serving and neighbor cells based on a configuration received by the gNB. In one example, the measurement configuration contains several elements such as the measurement object (what is to be measured, e.g., RAT, frequency, cells, reference signals, etc.,), a reporting configuration that indicates when the WTRU transmits the measurement reports (e.g , periodic reporting, eventbased reporting, etc.), and what to include in the report (e.g., reference signals to be reports, e.g., CSI-RS or SSB, number of cells / beams to be reported, etc.,)

[0093] There are several ways of configuring event triggered reporting, for example:Event A1 (Serving cell becomes better than threshold)Event A2 (Serving becomes worse than threshold)Event A3 (Neighbor becomes offset better than SpCell)Event A4 (Neighbor becomes better than threshold)Event A5 (SpCell becomes worse than threshold 1 and neighbor becomes better than threshold2)Event A6 (Neighbor becomes offset better than SCell)Event B1 (Inter RAT neighbor becomes better than threshold)Event B2 (PCell becomes worse than thresholdl and inter RAT neighbor becomes better than threshold2)

[0094] The term SpCell refers to a Primary Cell (PCell). In the case of Dual Connectivity (DC), the term SpCell refers to the Primary Secondary Cell (PSCell). Preferably, event A3, A5, B2 may be configured for the PCell or PSCell; events A1 , A2, A3, A5, B2 may be configured for any serving cell; event A6 may be configured for SCells (i e., for the secondary cells in carrier aggregation, CA); events A4 and B1 may be related to neighbor cell measurements (i.e., not related to PCell or PSCell).

[0095] The WTRU’s measurement configuration preferably may contain an s-measure configuration (s- MeasureConfig), which specifies a threshold for NR SpCell RSRP measurement controlling when the WTRU is required to perform measurements on neighbor cells. That is, when the serving cell’s (e.g., PCell) RSRP is above the s-measure threshold, the WTRU may not be required to perform neighbor cell measurements, thereby saving WTRU battery. In addition to the threshold values, each event configuration may be associated with a hysteresis and timeToTrigger (TTT) parameters, to limit the number / frequency of ping pong handovers.

[0096] The network may instruct the WTRU to perform a handover to a neighbor cell at any time (e.g., due to load conditions in the current serving cell). Typically, handover may be triggered due to the reception of a measurement from the WTRU (e g., WTRU sending a measurement report due to the fulfillment of an A3 event, i.e., indicating that a neighbor cell has become better than the serving cell by a certain threshold).

[0097] When the WTRU receives a HO command (which may be received in an RRC reconfiguration containing information about the target / nei gh bor cell), it generally stops communicating with the serving cell; it may perform a Random Access (RA) procedure in the target cell to identify itself and to get the Uplink (UL) Timing Advance (TA) to use towards the target cell for future communications; it may apply the RRC reconfiguration that is the HO command, and it may send a HO complete message to the target cell.

[0098] During the RA procedure to the target cell, there may be an interruption of UL and DL user plane communication with the network, which is typically referred to as "handover interruption’’. If the measurementreports are not received in due time before and the serving cell conditions get very bad (e.g., the WTRU goes out of coverage of the serving cell before it sends the measurement report), the WTRU may experience a Radio Link Failure (RLF). If the measurement reports were sent on time but the WTRU goes out of coverage of the serving cell before the HO command is received, the WTRU may experience what is known as a Handover Failure (HOF).

[0099] A Conditional Handover (CHO) may be implemented with the purpose of reducing radio link failures (RLFs) and handover failures (HOFs). In CHO, a WTRU may be configured with a conditional measurement event, where the main difference from legacy measurement events is that instead of sending a measurement report when the event conditions are fulfilled, the WTRU executes a HO command that is associated with the event. The CHO command may be sent when the radio conditions towards the current serving cell is still favorable, thereby reducing the two main points of failure in legacy handover, i.e., risk failing to send the measurement report (e.g. if the link quality to the current serving cell falls below acceptable levels when the measurement reports are triggered in normal handover) and the failure to receive the handover command (e.g. if the link quality to the current serving cell falls below acceptable levels after the WTRU has sent the measurement report, but before it has received the HO command).

[0100] The triggering conditions for a CHO may be based on the radio quality of the serving cells and neighbor cells like the conditions that are used in legacy NR / LTE to trigger measurement reports For example, the WTRU may be configured with a CHO that has an A3 like triggering conditions and associated HO command. The WTRU may monitor the current and serving cells and when the A3 triggering conditions are fulfilled, it may execute the associated HO command instead of sending a measurement report, and it switches its connection towards the target cell.

[0101] The following conditional event configurations are defined in NR:CondEvent A3: Conditional reconfiguration candidate becomes amount of offset better than PCell / PSCell;CondEvent A4: Conditional reconfiguration candidate becomes better than absolute threshold;CondEvent A5: PCell / PSCell becomes worse than absolute thresholdl AND Conditional reconfiguration candidate becomes better than another absolute threshold2;CondEvent D1 : Distance between WTRU and a reference location referenceLocationl becomes larger than configured threshold distanceThreshFromReferencel and distance between WTRU and a reference location referenceLocation2 of conditional reconfiguration candidate becomes shorter than configured threshold distanceThreshFromReference2;CondEvent T1: Time measured at WTRU becomes more than configured threshold t1 -Threshold but is less than t1 -Threshold + duration;

[0102] The condEvent D1 and CondEvent T1 are used in scenarios like NTN (non-terrestrial networks) where there is some location or / and time based predictability of the network conditions (e.g., it is known or canbe predicted at what time a certain geographical location / area will be covered by a cell that is being served by a moving satellite).

[0103] L1 / L2 Triggered Mobility (LTM) is a mechanism that may improve handover latency. LTM may be viewed as a CHO that is triggered due to a reception of a L1 / L2 indication from the network. That is, the WTRU may be configured with a multitude of LTM candidate configurations, like it is done for the case of CHO, and may execute the configuration associated with a given candidate when it receives a L1 / L2 indication, such as a MAC Control Element (MAC CE) from the network that indicates the candidate cell as the target cell. The network may trigger the sending of the L1 / L2 indication based on the L1 measurement reports that it is receiving from the WTRU.

[0104] The WTRU may perform early timing advance (TA) acquisition of a candidate cell(s) before receiving the LTM command to switch to that cell For example, this may be done via Contention-Free Random Access (CFRA) triggered by a PDCCH order from the source cell, following which the WTRU may send a preamble towards a candidate cell. The information that identifies the allocated CFRA resource can be indicated in the PDCCH order to enable shared preamble resource among multiple WTRUs in the RRC configuration: the source gNB dynamically indicates which WTRU uses the resource at any specific time. To minimize the data interruption of the source cell due to CFRA towards the candidate cell(s), the WTRU may not wait to receive RAR. That is, the target cell may indicate the delta TA to be applied to the source cell. In case both the source and the target are served by the same gNB, then this may be done internally within the gNB. When the source sends the LTM command to the WTRU, it may indicate to the WTRU the delta / absolute TA value to apply to the target. That is, if the TA value of the candidate cell is indicated in the LTM command, the WTRU may perform a RACH-less handover to the candidate cell.

[0105] The following three use cases are pertinent to the use of AI / ML for wireless communication air interfaces such as NR:Channel State Information (CSI): related enhancements: CSI compression (frequency domain), timedomain prediction, etc.,Beam Management (BM): Temporal prediction (predicting of a beam’s quality based on earlier beam quality), spatial prediction (prediction of a certain beam’s quality based on the quality of other beams), etc.,Positioning: Direct AI / ML positioning (e.g , fingerprinting) and AI / ML assisted positioning (e.g., the output of the AI / ML model inference is a new measurement and / or an enhancement of an existing measurement)

[0106] The AI / ML model may be operating / running at the WTRU, the gNB, other network node, e.g., LMF (Location Management Function) for positioning, or even outside the wireless network domain e.g., Over The Top (OTT) server. There may also be use cases where there is model running at more than one entity for a certain function, e.g., for CSI-Compression use case. There may be a need for a model in the WTRU as wellas a model in the network, where the model at the WTRU may provide compression related functionality, while the model at the network may provide the decompression.

[0107] Another aspect that is being investigated in 3GPP in conjunction with the three use cases discussed above is the lifecycle management (LCM) of AI / ML operations. This is being studied in collaboration across multiple RAN groups, RAN 1 / 2 / 3, and it comprises functionalities such as:Model inferenceModel training (offline training, online training, etc.,)Model storage / transferModel updateModel validationPerformance monitoringData collection (for inference, training, performance monitoring)Model selectionModel activation / deactivation / fallback to legacy operation

[0108] The use of AI / ML for enhanced WTRU mobility (e.g., improve handover performance / robustness, reduce WTRU power consumption, reduce network signaling overhead, etc.,) is considered herein. Some of the proposed objectives in utilizing AI / ML for enhanced WTRU mobility include:HO decision optimization, including: o Candidate / target cell prediction in L3-based mobility, or, candidate / target beam(s) and cell(s) prediction in LTM o HO parameter adjustment / tuning o Unintended events prediction, e.g., HO failure / RLF prediction, ping-pong and short-stay HO predictionRRM measurement prediction, including: o Beam-level measurement prediction o Cell-level measurement prediction, e.g., using intra-frequency measurement results to forecast the RRM measurement of inter-frequency / inter-RAT cellsType of mobility: o L3-based mobility as starting point, or, o L3-based mobility and L1 / L2-triggered mobility (LTM) are both consideredType of AI / ML model o UE-side model and network-side model are both considered, oro UE-side model as starting pointLCM framework and others o The conclusions in Rel-18 AI / ML study can be reused as much as possible o Other impacts are further studied

[0109] Based on AI / ML, a WTRU may be capable of predicting its trajectory for a certain time horizon / duration. More optimal and robust mobility management procedures may be identified based on the new knowledge. It may be possible to leverage AI / ML to transform the reactive approach of making mobility decisions into a proactive approach.

[0110] In one example, the WTRU may send a report or indication based on expected time remaining in serving cell The WTRU may indicate to the NW its expectation of leaving the current source cell, so that the NW can e.g., start to prepare candidates for mobility. A new trigger may be defined for the WTRU to report to the NW on imminent mobility. The WTRU may be configured with e.g., a time threshold, RSRP threshold, buffer threshold, etc The WTRU may leverage its own trajectory prediction, to assess if the remaining time in the current serving cell is lower than the configured threshold. If so, the WTRU may send an indication / report to the NW.

[0111] For example, the WTRU may transmit to the network its capability to predict time of stay in a cell. The WTRU may receive a configuration from the network with one or more conditions to trigger a report based on one or more of: predicted time of stay in the serving cell, time thresholds, current / predicted UL buffer levels, or active bearer / data type. In one embodiment, the WTRU may predict the time of stay and compare to time threshold, if UL buffer level is above buffer threshold x. In another embodiment the WTRU may predict time of stay compared to time threshold b, if UL buffer level is above buffer threshold y. The predicted time of stay may be defined as a time duration, or number of slots, or number of symbols, between the time of the report and the time when a mobility event occurs.

[0112] In one example, the WTRU may receive a configuration for the information to be included in the report (e.g., predicted time of stay duration, measurements, buffer levels, etc.). The WTRU may determine one or more of: predicted time of stay in the serving cell, current / predicted UL buffer levels, or active bearer / data type. Upon determining that one or more triggering conditions is fulfilled, the WTRU may transmit the report to the network. The report may additionally contain current / predicted measurement of serving / neighbor cells and current / predicted buffer levels.

[0113] In one example, the WTRU may perform neighbor cell measurements more efficiently, depending not only on the current level of the serving cell (e.g., legacy s-measure, RSRP thresholds), but also expected time in the serving cell. The WTRU may be configured to determine when to start performing neighbor cell measurements based on the expected time remaining in the serving cell, and the serving cell radio conditions. The WTRU may determine when to start performing neighbor cell measurement based on the serving cell radiosignal level and the expected / predicted time of stay in that cell. The WTRU may be configured to report to the NW on information related to the conditions that triggered it to start monitoring neighbor cells.

[0114] In one example, the WTRU may transmit to the network capability to predict time of stay in a cell. The WTRU may receive a configuration from the network with conditions to start performing neighbor cell measurements based on the determined predicted time of stay in a cell. The triggers / conditions may, for example, contain one or more time thresholds and associated serving cell signal levels (e.g., s-measure RSRP of x for time threshold a, s-measure RSRP of y if time threshold is b, etc.,).

[0115] In one example, the WTRU may receive a measurement reporting configuration (e.g., Ax events). The WTRU may determine one or more of: the predicted time of stay in a cell, the serving cell RSRP. The WTRU may determine that one or more conditions to start performing neighbor cell measurements are satisfied based on one or more of: the determined predicted time of stay in a cell, the determined serving cell RSRP, and a time threshold.

[0116] The WTRU may start performing neighbor cell measurements. In one example, the WTRU may monitor the conditions for measurement reporting (e.g., Ax conditions). Upon determining that the conditions for measurement reporting are fulfilled, the WTRU may send the measurement report. The report may include information on the conditions that were satisfied to trigger the performing of the neighbor cell measurements (e g., predicted time of stay in a cell, timing of the neighbor cell measurement conditions being satisfied, identity of the condition that was satisfied, etc.)

[0117] In one example, the WTRU may include in the measurement report, detailed information about target cells, such as expected time of stay, expected average quality, etc. The WTRU may be configured to provide detailed information about the different target cells in the measurement report. The WTRU may indicate the likelihood of a particular neighbor cell being the target cell and / or expected time of stay in that target cell, and / or expected average quality in that target cell, etc.

[0118] The WTRU may trigger, based on a configured criteria, the sending of detailed information related to HO to candidate cells, such as predicted time of stay in the target cell, predicted average quality, confidence or likelihood of a target cell being the best cell, etc. Additionally, the WTRU may execute a HO, e.g., via a received OHO configuration, based on the detailed information that it determines.

[0119] In one example, the WTRU may transmit to the network capability to predict detailed information about a neighbor cell, such as the likelihood of neighbor cell being the target, the predicted time of stay in the neighbor cell, and the average radio quality in the neighbor cell. The WTRU may receive a measurement (or reporting) configuration (e.g., legacy Ax event, periodic reporting configuration, configuration based on predicted time of stay left in current serving cell, etc.), and an indication in the configuration to include detailed information about one or more neighbor cells in the measurement report.

[0120] The WTRU may determine that the reporting conditions are fulfilled (e.g., based on one or more of: measurements, determined predicted time of stay left in a current serving cell, configured reporting events, and reporting configuration). The WTRU may predict detailed information about one or more neighbor cells andmay send a measurement report that includes the detailed information and the identities of the one or more neighbor cells. The WTRU may optionally select a subset of neighbor cells for which to report detailed information, based on one or more of cell measurements, predicted detailed information of the cells, ranking of measurements of cell, configured thresholds. IN one example, the WTRU may report neighbor cell measurements for neighbor cells whose measurements or predicted detailed information is greater than of minimum threshold.

[0121] Existing mechanisms for mobility and beam change / switching are reactive in that candidate cells for mobility can only be determined after a certain number of measurements for potential candidate cells have been recorded. With knowledge of its upcoming trajectory for a predetermined time window (e.g., trajectory prediction via AI / ML model at the WTRU and / or gNB), proactive methods for mobility, which may bring several benefits: The WTRU may not need to measure all the neighbor cells for a potential handover candidate, which may save battery consumption; the WTRU may be able to perform handover faster and with less overhead; the WTRU may make more accurate selection of candidate cell (since the AI / ML model may be able to anticipate the length of time in each cell based on the trajectory).

[0122] For AI / ML model(s) for trajectory prediction at the WTRU, the WTRU may report the predicted trajectory to the network. This may be accompanied by timing information (e.g., the WTRU may report the corresponding time instance with every position / coordinate of the trajectory). For AI / ML model(s) for trajectory prediction at the network, the network may predict the trajectory of more than one WTRU over a time window. During that time window, the WTRU may be configured to report some measurements to the network (e.g., positioning) for the network to validate that its trajectory prediction is accurate.

[0123] The network also benefits from trajectory determination / prediction in terms of provisioning of resources for one or more WTRU(s). Having information on the target cell candidate and the window when the WTRU is expected to handover to the candidate cells, the network may be able to provision the time and frequency resources for each cell. This may also prevent sub-optimal provisioning, which results in waste of resources and under provisioning which results in congestion / starvation for some WTRUs.

[0124] The WTRU may have the capability of predicting its time of stay in the serving cell. This may imply that the WTRU will not remain in the current serving cell after a certain point in time, but this may not be the case. As an example, the WTRU may be considered to have left the serving cell because it has detected an Radio Link Failure (RLF). The WTRU may then recover from RFL that event by connecting again to the same cell. In some other cases, the WTRU might recover from the RLF and connect to a different cell. Accordingly, the “time of stay in a cell” can be defined in several different ways, and it is considered that one or more of them will be more technically viable from a technological implementation point of view. For different use cases, scenarios, applications, cells, networks, operators, etc., some definitions of WTRU “time of stay in a cell” may be more technically viable than others.

[0125] At some point in time, the WTRU will be connected to some other cell, or simply disconnect from the current serving cell. However, the time of stay in a cell is not limited to be measured in terms of time only.As a couple of examples, the WTRU may have a grant to transmit some data in the uplink, and the NW may determine that after the data in that grant is transmitted by the WTRU, it will issue a HO command to this WTRU This implies that time of stay in a cell for that WTRU could also be measured as an amount of UL data. As another example, the WTRU, or the NW, or both, may have a good geographical understanding of its cell coverage, and may be able to determine that a WTRU is moving towards a cell coverage edge, e.g., via a positioning method, and the radio signal levels will become weaker. A WTRU in these conditions will probably be handed over to another neighbor cell and in this case, the time of stay in a cell can be defined as a geographical location representation or quantity.

[0126] Accordingly, time of stay in a cell can be defined as:An offset time in the future from the current time (e.g., a timer)An offset from a second, third, fourth, etc., time, counting from e.g., an initial timerAn offset time in the future from the RRC Reconfiguration message received before HOAn offset time in the future from the RRC Reconfiguration complete message sent after HOAn offset that starts counting from a specific event. Such events may happen at some point in time, or they may be predicted, either by the WTRU or by the NW In the case the NW predicts them, it is implicit that they have been transmitted to the WTRU, so the WTRU can assess them. Examples of events include: o A measurement at the WTRU (e.g., RSRP, RSRQ, SINR) falling above / below a threshold o A predicted measurement (e.g., RSRP, RSRQ, SINR) falling above / below a threshold o An UL buffer level falling above / below a threshold o A predicted UL buffer level falling above / below a threshold o A number of re-transmissions falling above / below a threshold o A number of predicted re-transmissions falling above / below a threshold o A specific number in the counters affecting RLF determination (e.g., if the WTRU determines / declares RLF after N instances of the counters, then N-X may be the time associated with the time offset) o A predicted time for when X above will happen o A predicted time for when RLF will happen

[0127] Measurement reporting events play a significant role in the NW decisions for mobility. In today’s cellular networks, WTRUs are configured to send measurement reports to the NW when there are measurement events. For example, upon certain measurements such as RSRP, RSRQ, SINR (as measured by the WTRU) falling within a certain range, or being above or below certain thresholds. There are many measurement events that are standardized:Event A1 (Serving becomes better than threshold)Event A2 (Serving becomes worse than threshold)Event A3 (Neighbor becomes offset better than SpCell)Event A4 (Neighbor becomes better than threshold)Event A5 (SpCell becomes worse than threshold 1 and neighbor becomes better than threshold2)Event A6 (Neighbor becomes offset better than SCell)Event B1 (Inter RAT neighbor becomes better than threshold)Event B2 (PCell becomes worse than thresholdl and inter RAT neighbor becomes better than threshold2)Event 11 (Interference becomes higher than threshold)Event D1 (Distance between WTRU and referenceLocationl is above thresholdl and distance between WTRU and referenceLocation2 is below threshold2)Event Y1 (PCell becomes worse than thresholdl and candidate L2 U2N Relay WTRU becomes better than threshold2)

[0128] These events may be useful for the WTRU’s assessment of time of stay in a cell. Preferably, the time of stay in a cell may be associated with these events, as the time of stay in cell may be useful to be interpreted in relation to these events. As an example, the NW may be aware that the WTRU is moving towards a cell edge, where coverage conditions are worse. If a WTRU is configured to send a measurement report using event A2 (serving cell becomes worse than threshold), the NW may determine that there is still a certain amount of time until that WTRU will be out of coverage. It is the NW’s decision of when to transmit a HO command to the WTRU. If a WTRU is capable of predicting measurements, then it may predict events. In such a scenario and in practice, this may result in a time of stay in cell that may be the sum of, e.g., the time from the current time until the time the event has been predicted, plus an extra amount of time where the WTRU will still be considered to be in good coverage. The second component in this case, i.e., the extra time, is referred to herein as “post-event time.” During the post-event time, the WTRU may be considered to still have good radio conditions, which may be determined by both the WTRU or the NW. This can be based on e.g., historical records of HO procedures executed, kept at WTRU or NW, and determined via e.g., any heuristic, statistical and / or artificial intelligence based methods. In case this determination is done at the NW side, it is also considered here that the WTRU has received this information via any message or exchange with the NW. The method for this determination can also be controlled by the NW, by providing the WTRU the relevant methods, functions and other relevant heuristic, statistical and / or artificial intelligence based information.

[0129] In a similar way, the time of stay in cell may be some time before the event actually happens, or it is predicted to happen. This may be useful in situations where, for example, the WTRU has a high UL buffer to transmit, and the NW determines it is better to hand that WTRU over to a neighbor cell, while it is known that the WTRU is still under good radio conditions. Considering again the case where the WTRU is capable of predicting events, the time of stay in a cell may be, as an example, the time from the current time until the eventhas been predicted, minus a certain amount of time that can be considered as a safety margin. This safety margin is herein referred to as “pre-event time.”

[0130] The referred times in relation to the events can also be considered in the case of legacy measurements, without the application of predictive methods. But in this case, if there is a scenario where it is better to handover a WTRU before the event happens, then predictive methods may be required for the WTRU to estimate the time of stay in a cell. Alternatively, the safety margin may be delivered by the NW to the WTRU, via e.g , configuring a second threshold for e.g., a RSRP measurement.

[0131] Metrics that are “time related” may relate to a measurement event, or to a predicted measurement event. Preferably, both pre-event and post-event times may be considered. The WTRU may assess a first time comprising the time of stay in a cell that happens before the event or predicted event and a second time comprising the time of stay in a cell, using different metrics for pre-event and post-event times. The following are examples of post-event time where the WTRU may determine the criteria for an event has been met via legacy methods and / or methods for predicting the event:An offset time in the future from the current time (e.g., a timer)An offset from a second, third, fourth, etc., time, counting from e.g., an initial timerThe time for predicted measurement (e.g., RSRP, RSRQ, SINR) falling above / below a thresholdThe time for a predicted UL buffer level falling above / below a thresholdThe time for a number of predicted re-transmissions falling above / below a thresholdThe time for a specific number in the counters affecting RLF determination to occur (e.g., if the WTRU determines / declares RLF after N instances of the counters, then N-X may be the time associated with the time offset)A predicted time for when X above will happenA predicted time for when RLF will happen

[0132] These examples may also be considered for the pre-event time. In this case, the NW may determine and transmit to the WTRU the pre-event time, via sending this information pre-emptively, i.e., before the event happens. This information may be encoded as a time format, but may also be any other format. For example, the NW may determine / set a certain pre-event time that is associated with an RSRP measurement value measured by the WTRU If the WTRU knows this information in advance, it may predict when the RSRP measurement will occur, and may therefore predict the time of stay in a cell that is associated with a certain event, and that will happen before the event occurs.

[0133] Preferably, the WTRU may have a pre-trained AI / ML model that can produce predictions of WTRU trajectory (e.g., time of stay in the current serving cell). However, it can be assumed that the model is trained based on historical observation of the WTRU’s mobility (e.g., during certain time durations of the day, during which days of the week, at which locations, etc.).

[0134] Different AI / ML models / technique may be used by the WTRU. For example, different algorithms used, different mechanisms such as neural network or what kind of neural network, e.g., depth and parameters / weights of the network, etc , different origin of the model (e.g., WTRU vendor, operator, network vendor, etc.), or how / where the training of the model is done (e.g., the input data used for the training, where the training is performed, if the training is performed offline or online, etc.).

[0135] The predicted value (e.g., time of stay) may be associated and / or represented by a confidence or error value, and may be represented by an average, peak, minimum value, etc. along a short time window representing the validity of that prediction. For example, the following may be the time of stay prediction that the AI / ML generates:At least x seconds with 95% confidenceAt least y seconds with 90% confidenceAt most z seconds with 80% confidence

[0136] As another example, the time of stay prediction may be:Time of stay of between x and y seconds, with 95% confidenceTime of stay of between y and z seconds, with 90% confidence

[0137] FIG. 2 illustrates an example of the communication between the WTRU and the network for supporting mobility enhancements based on AIML predictions.

[0138] The WTRU may determine which AIML model to use 201. The origin of model may vary. It may be pre-provisioned in the WTRU by either the WTRU vendor or the network operator. The model may also be dynamically configured by the network when the user registers with the network. The model bay be dependent on the geographic location, e.g., denser areas may be configured to use different models from sparse areas.

[0139] The WTRU and the network may preferably communicate about AI / ML capabilities 202. The WTRU may indicate to the network the supported AI / ML models / functions, confidence level of predictions, and time horizon of predictions (how far along in the future are the prediction being made. The WTRU may support several AI / ML models for a certain functionality (e.g , with different prediction time horizons, prediction confidence levels, processing requirements, and trained under / for operation in different frequencies / cells / location / times of day). A given AI / ML model can operate in different modes (e.g., with different levels of prediction confidence levels at different prediction time horizons).The WTRU may choose the AI / ML model to use for a certain functionality.

[0140] The network may provide input to the WTRU 203. In one example, the network may decide for which functionalities the WTRU may use AI / ML based operation, and the WTRU may choose the preferred AI / ML model to use for the given functionality. In another example, the network may explicitly control this selection. In one example, the WTRU may provide details of AI / ML models and their capabilities 202, and network may determine, based on the WTRU capabilities, which model to activate for a particular functionality 203.-7J -

[0141] In one example, the AI / ML models may be available at the WTRU already pre-trained, and optionally the WTRU may be enabled / configured to perform further training (e.g , for different conditions such as frequencies / cells / location / times of day, for the same conditions as the initial training but for increasing the level of confidence or / and the prediction time horizon). In another example, the WTRU may be provided with an untrained AI / ML model and performs the training by itself.

[0142] The network may configure the WTRU with one or more events associated with time of stay in a cell 204. When the event is detected 205, the WTRU may report the event to the network 206.

[0143] A WTRU may indicate to the NW about its expectation of leaving the current source cell. The NW may start to prepare candidates for mobility. A new trigger may be defined for the WTRU to report to the NW on imminent mobility The WTRU may be configured with e.g., a time threshold. Then, leveraging on its own trajectory prediction, the WTRU may be able to assess if the remaining time in the current serving cell is lower than the threshold. If so, the WTRU will send an indication / report to the NW. The threshold may also be related to other measurement, such as RSRP threshold and / or buffer threshold.

[0144] The WTRU may transmit to the network the capability to predict time of stay in a cell. The WTRU may receive a configuration from the network with one or more event / conditions to trigger a report, based on one or more of: predicted time of stay in the serving cell, time thresholds, current / predicted UL buffer levels, or active bearer / data type (e.g , predicted time of stay compared to time threshold “a” if UL buffer level is above buffer threshold “x”, or predicted time of stay compared to time threshold “b” if UL buffer level is above buffer threshold “y”). The predicted time of stay may be defined as a time duration, or number of slots, or number of symbols, between the time of the report and the time when a mobility event occurs. The WTRU may also receive a configuration for the information to be included in the report, e.g., predicted time of stay duration, measurements, and / or buffer levels.

[0145] The WTRU may determine one or more of: predicted time of stay in the serving cell, current / predicted UL buffer levels, or active bearer / data type. Upon determining that one or more triggering conditions are fulfilled, the WTRU may transmit the report, where the report may additionally contain the current signal level of the serving cells, the predicted signal level of the serving cells, the current signal level of the neighbour cells, the predicted signal level of the neighbor cells, the current buffer levels, and the predicted buffer levels, where the predicted values are based on a certain point in time in the future, for example, at the time the WTRU will be leaving the cell (at the end of time of stay in the serving cell).

[0146] In one example, the WTRU may indicate to the network its capability to perform signal level prediction of serving and / or neighbor cells.

[0147] In one example, the WTRU may be configured with a time duration threshold and further configured to send an indication to the network when it predicts that the time of stay in the current serving cell is below the configured time duration threshold.

[0148] In one example, the WTRU may be configured with a TTT that is related to the time of stay duration, and the WTRU considers the time of stay duration threshold is fulfilled and may send the indication to the network only if the predicted time of stay remains below the threshold for the configured TTT.

[0149] In one example, the WTRU may be configured with a signal level threshold of the serving cell and it may send the indication / report to the network only if the signal level of the serving cell is below the configured signal level threshold and the predicted time of stay in the serving cell is below the configured time of stay threshold. This, for example, may be provided via a modified A2 event, where the time say duration threshold is an additional condition to the A2 signal level threshold. In one variation of this solution, the WTRU may be provided with only one TTT (i.e., as in legacy A2 event) that is applicable to both the signal level and time of stay duration. In another variation of this solution, there may be separate TTT for the radio signal level and time of stay duration (e.g , and additional TTT concerning the time of stay duration included in the modified A2 event).

[0150] In one example, the WTRU may be configured with a signal level threshold (e.g , A2 event) and upon the fulfillment of that threshold, it may sends an indication to the network that includes the predicted time of stay in that serving cell (e.g., a separate indication, a new information element in the measurement report triggered as a result of the fulfillment of an Ax event).

[0151] In one example, the WTRU may be configured with an UL buffer threshold, and sends the indication / report to the network only if the UL buffer threshold is above / below the configured buffer threshold and the predicted time of stay in the serving cell is below the configured time of stay threshold The buffer threshold may be one or more of the following:The total UL buffer level of all bearers; the UL buffer levels of a certain bearer; the total UL buffer level of a group of bearers (e.g., list of bearer IDs indicated to the WTRU); the total UL buffer level of a certain types of bearers (e.g., bearers of QoS level x, bearers that have a guaranteed bit rate, and / or bearers with a latency requirement below a certain delay budget); or a combination of all the above (e.g., UL buffer level of bearer group 1 > thresholdl AND UL buffer level of bearer group 2 > threshold 2).

[0152] In one example, the WTRU may be configured with a data activity level threshold and may send the indication / report to the network only if the data activity level is above / below the configured threshold and the predicted time of stay in the serving cell is below the configured time of stay threshold. The data activity level may be related to UL data activity, DL data activity, or both. The data activity level can be one or more of the following:The activity duration. For example, the WTRU may be configured to stop the time of stay prediction (and any associated action related to time of stay prediction) if it detects no data activity in the UL or / and DL for a certain configured duration.The UL / DL data rate. For example, the WTRU may be configured to perform the time of stay prediction only if the UL or / and DL data rate is above a certain threshold, below another threshold, between two thresholds, etc.

[0153] In one example, a WTRU that has sent a first indication according to any of the solutions above, may be further configured to send a subsequent indication (e.g., second indication), if it determines that the prediction of the time of stay has changed by a certain margin (e g., margin may be absolute value and / or percentage value) from the predicted time of stay that led to the sending of the first report. The second indication may also be dependent on how slow or fast the changes happen e.g., second indication is sent if there is a change within a given time duration from the time of sending the first indication). For example, the WTRU may be configured to send a first indication when the time of stay in the serving cell is predicted to be below 3 seconds. The WTRU may be further configured to send a second indication when the time of stay in the serving cell increases by more than 20% within 0.25 seconds (e.g., with a given time duration of 0.25 seconds) as compared with the previous time of stay prediction that led to the triggering of the previous indication. In this case the WTRU may send the first indication upon predicting the time of stay to be 2.75 seconds. Then, 0.2 seconds after sending the first indication, the WTRU may predict the time of stay to be 3.5 seconds (i.e., a percentage increase of 27%) and thus triggers the second indication (because 0.2 < 0.25 and 27%>20%).

[0154] In one example, the WTRU may be configured to perform the time of stay duration prediction continuously (e.g., after the reception of the configuration related to time of stay duration prediction and reporting).

[0155] In one example, the WTRU may be configured to perform the time of stay duration prediction periodically (e.g., every 100ms).

[0156] In one example, the WTRU may receive an ON / OFF indication from the network regarding the time of stay prediction and reporting. The indication may be sent in a DCI, MAC CE, or RRC message.

[0157] In one example, the WTRU may be configured with a signal level threshold of the serving cell and may perform the prediction of the time of stay in the serving cell only if the serving cell’s signal level is below the configured signal level threshold. This may be provided via an A2 event, and the fulfillment of the A2 event activates the time of stay prediction at the WTRU.

[0158] In one example, the WTRU may be configured with an UL buffer threshold, and may start to perform the prediction of the time of stay in the serving cell only if the UL buffer threshold is above / below the configured buffer threshold.

[0159] In one example, the WTRU may be configured to perform the prediction of the time of stay in the serving cell only if it has an active bearer of a certain type (e.g., a bearer with a certain QoS profile).

[0160] In one example, the WTRU may be configured with a data activity level threshold and perform the prediction of the time of stay in the serving cell only if the data activity level is above / below the configured threshold. The data activity level may be associated to UL data activity, DL data activity, or both.

[0161] In a solution, the WTRU may be configured to perform the prediction of the Time of Stay (ToS) in the serving cell only when a preconfigured measurement-based event is satisfied. For example, the WTRU may start the prediction of the time of stay when the entering conditions for A3 are satisfied. For example, the WTRU may start the prediction of the time of stay when the TTT timer is started. In a solution, the WTRU may adjust the TTT value based on the ToS value. For example, the WTRU may set the TTT value to be equal to TTT - (ToS + delta), wherein the value of delta may be preconfigured or predefined. For example, if TTT - (ToS + delta) <= 0, then the WTRU may trigger the actions as if the TTT is expired For example, if the TTT- (ToS + delta) > 0, then the WTRU may set the TTT value to be equal to TTT- (ToS + delta). For example, the WTRU may stop the prediction of the time of stay when the leaving conditions for A3 are satisfied. Such solution may be beneficial to limit the WTRU behavior associated with time of stay prediction to scenarios where a handover is likely.

[0162] In a solution, the WTRU may be configured with both measurement event (e g., A3 or CondEvent A3) and ToS prediction In another solution, the WTRU may be further configured with priority of measurement event (e.g., A3 or CondEvent A3) relative to ToS prediction. In another solution, the WTRU may be configured with priority of ToS relative to measurement event (e.g., A3 or CondEvent A3) condition. In a solution, different priorities may be configured for ToS prediction as a function of confidence value associated with such prediction. For example, CondEvent A3 is higher priority than ToS prediction with confidence value of 70%, but CondEvent A3 is lower priority than ToS prediction with confidence value of 99%. In a solution, when the measurement condition and ToS prediction leads to conflicting / contradicting results, the WTRU may perform actions based on the priority associated with CondEvent A3 and ToS prediction configuration. For example, if the CondEvent A3 is satisfied, but ToS prediction indicates that the WTRU ToS in the cell is higher than a threshold, and if priority of CondEvent A3 is higher than the priority of ToS prediction, then the WTRU may perform actions according to CondEvent A3. For example, if the CondEvent A3 is not satisfied, but ToS prediction indicates that the WTRU ToS in the cell is less than a threshold, and if priority of CondEvent A3 is lower than the priority of ToS prediction, then the WTRU may perform actions according to ToS prediction. For example, if the priority of measurement event and ToS prediction is same, then the WTRU may execute the action only when both conditions are satisfied.

[0163] In one example, the WTRU may be configured (e.g., during the initial configuration of the time of stay duration threshold) on what to include in the report / i ndication that it sends upon the fulfillment of the time of stay duration threshold

[0164] In one example, the indication sent by the WTRU may be a simple indication that implicitly indicates the fulfillment of the time of stay duration being fulfilled (with no additional detailed information). For example, with this indication, the network will know the WTRU predicts to stay in the serving cell below the configured threshold, but it will not know for exactly how long.

[0165] In one example, the indication sent by the WTRU may contain the predicted time of stay duration in the serving cell. This may further include details of the prediction, such as prediction confidence, and error margins.

[0166] In one example, the indication sent by the WTRU may contain radio link measurement results (e.g., measurement of serving cells, measurement of neighboring cells)

[0167] In one example, the indication sent by the WTRU may contain predicted radio link measurement results (e.g., predicted measurement of serving cells, predicted measurement of neighboring cells).

[0168] In one example, the indication sent by the WTRU may contain UL buffer levels (e.g., total buffer level, and / or buffer level of a group / type of bearers)

[0169] In one example, the WTRU may be configured with the prediction time horizon (e.g., ‘x’ ms) for the predicted radio link measurements that are included in the report sent to the network upon the fulfillment of the time of stay duration threshold.

[0170] In one example, the WTRU may be configured with the prediction time horizon (e.g., ‘x‘ ms) for the predicted buffer levels that are included in the report sent to the network upon the fulfillment of the time of stay duration threshold.

[0171] In one example, the report may be sent via an RRC message (e.g., in a new RRC message, or in a modified RRC measurement report message)

[0172] In one example, the report may be sent via a lower layer message (e.g., MAC CE, UCI)

[0173] In one example, the report may be sent in parts For example, the WTRU may send a MAC CE / UCI indication, indicating the time of stay duration threshold has been fulfilled, and then may send the detailed information in an RRC message and / or Buffer Status Report (BSR).

[0174] In one example, if the WTRU has no UL grants to send the report, it may trigger a scheduling request (SR).

[0175] In one example, the WTRU may be configured with SR resources that are associated with the sending of the report related to time of stay duration and uses those resources to send the SR upon determining that no UL grant may be available for sending the report (i.e., network implicitly knowing that the WTRU is trying to send information related to the time of stay duration).

[0176] In one example, the WTRU may be configured with a CHO that has a triggering condition that is related to the time of stay in the given cell (e.g., in addition to or instead of one of the conditional event triggering conditions). For example, the Cond Event A3 can be modified / enhanced to include the relative signal level threshold between the serving cell and the target cell (i.e., the legacy A3 threshold) and time of stay threshold, and the WTRU will execute the CHO if the radio conditions are fulfilled by the source and target, and the predicted time of stay falls below the time of stay threshold.

[0177] In one example, the WTRU may need to collect data for model training (e.g., model training to be performed at the WTRU, or model training to be performed at the network or another entity outside the network / operator).

[0178] In one example, the WTRU may be configured to log information regarding the time duration between the occurrence of a first event and a second event. For example, the first event may be an Ax event, and the second event may be the execution of a HO (e.g., due to reception of a HO command or due the fulfillment of CHO conditions). In another example, the first event may be an Ax event, and the second event may be the detection of an RLF. In another example, the first event may be an Ax event, and the second event may be the detection of a HOF.

[0179] The WTRU may be further configured to log additional information such as the absolute / relative time of day, WTRU location (e g., if GNSS location is available or WTRU has 3GPP based positioning determining capability), and measurements of serving and neighboring cells.

[0180] In one example, the WTRU may be configured to store such logged information until certain conditions are fulfilled, such as:A certain number of entries are made in the log, the size of the log is below a certain size (e.g., ‘x’ Mbytes), the logging has been ongoing for less than a certain time duration, or the WTRU has remained within a certain area (e.g., within a certain list of cells or within a given geographic area).

[0181] In one example, the WTRU may be configured to send an indication to the network, informing the network that a logged measurement related to time of stay durations is available.

[0182] In one example, the WTRU may be configured to send the logged information upon an explicit request from the network.

[0183] In one example, the WTRU may be configured to autonomously send the logged information (or send an indication that it has the logged information available) upon the fulfillment of certain conditions. For example, the conditions may be similar to the conditions that are described above for stopping the logging of the measurements.

[0184] In some of the description of the solutions above, the event A2 was used just as an example. As such, all the above solutions can be associated within any of the Ax, Bx or Condx events.

[0185] In the above solutions, the conditions related to signal level and buffer level thresholds were assumed to be related to the current signal level and buffer level thresholds However, the solutions are equally applicable to cases where considerations are also made to predict measurements and buffer levels For example, the WTRU may be configured with predictive Ax events that are associated with the time of stay prediction. For example, the WTRU may be configured to send the report upon the joint fulfillment of an A2 event, a predictive A3 event, and the predicted time of stay duration.

[0186] In one example, the time of stay duration prediction and reporting configuration may apply to several serving cells at once For example, if the WTRU may be configured with CA (e.g., PCell, SCelU and SCell2), the network may need to be informed of the WTRU’s predicted joint time of stay duration in one or more of the cells (e.g , all the cells including the PCell and all the SCells). The joint time of stay duration may be defined as one or more of the following:The time of stay duration in all the concerned cells is below the configured threshold.The time of stay duration in at least one of the concerned cells is below the configured threshold.The average time of stay duration in all the concerned cells is below the configured threshold.There are more than n cells (where n is the configured threshold) that have a time of stay duration less than the configured threshold.The time of stay duration in one or more of the SCells is longer than the time of stay duration in the PCell.

[0187] The WTRU may be configured to determine when to start performing neighbor cell measurements based on the expected time remaining in serving cell and serving cell radio conditions. The WTRU may perform neighbor cell measurements more efficiently, depending not only on the current level of the serving cell (e.g., legacy s-measure or RSRP thresholds), but also the expected time of stay in the serving cell. The WTRU may determine when to start performing neighbor cell measurement based on the serving cell radio signal level and the expected / predicted time of stay in that cell. The WTRU may be further configured to report to the NW information related to the conditions that triggered it to start monitoring neighbor cells.

[0188] The WTRU may transmit to the network its capability to predict time of stay in a cell. The WTRU may receive a configuration from the network with conditions to start performing neighbour cell measurements based on determined predicted time of stay in a cell, where the conditions contain one or more time thresholds and associated serving cell signal levels (e.g., s-measure RSRP of ‘x’ for time threshold ‘a’, s-measure RSRP of ‘y’ if time threshold is ‘b’). The WTRU may receive a measurement reporting configuration (e.g., Ax events). The WTRU may determine one or more of: the predicted time of stay in a cell, the serving cell RSRP. The WTRU may determine that one or more condition to start performing neighbour cell measurements is satisfied based on one or more of: the determined predicted time of stay in a cell, the determined serving cell RSRP and a time threshold The WTRU may start performing neighbour cell measurements. The WTRU may monitor the conditions for measurement reporting (e.g., Ax conditions). Upon determining that the conditions for measurement reporting are fulfilled, the WTRU may send the measurement report to the NW The report may include information on the conditions that were satisfied to trigger the performing of the neighbour cell measurements (e.g., predicted time of stay in a cell, timing of the neighbour cell measurement conditions being satisfied, and identity of the condition that was satisfied).

[0189] FIG. 3 illustrates the trajectory of a WTRU moving within an ideal coverage scenario of a cell.

[0190] In FIG. 3, a possible ideal coverage scenario of a cell is illustrated by the elliptical area formed by the outer-most ring 301 (e.g , inside the outer-most ring) The elliptical area formed by the interior ring 302 may illustrate the point where the RSRP reaches an ideal RSRP threshold value, which may be configured by the network in the WTRU. In this case, once the WTRU reached that line (e.g., the RSRP threshold value is met), the WTRU may trigger the process of measuring neighbor cells for the purposes of cell evaluation for a possible handover.

[0191] Assuming a WTRU follows a trajectory as identified by the line 303, starting in the inner most elliptical area, as the WTRU travels around the cell, at time tO 304, the threshold for the configured s-measure may be met. At this point, the WTRU starts performing measurements for neighbor cells. The WTRU continues its trajectory and is eventually handed over to another neighbor cell, at some time between t1 and t2, which may be referred to as HO window 305.

[0192] Between times tO 304 and t1 305, the WTRU may perform measurements for neighbor cells and it may report them to the NW, if the reporting criteria is met. During this time, the purpose of the s-measure becomes less efficient. This is because of the WTRU’s trajectory, that during this time keeps the WTRU in good radio conditions (as per WTRU or NW assessment), and where the WTRU can maintain connectivity with the current serving cell, but at the same time still measures and reports on neighbors, without necessarily a real need.

[0193] In this scenario, as an example, the time of stay in a cell can play a role in making the measurement reporting more efficient This is valid for all definitions of time of stay in a cell. As an example, if the NW decides for HO based on an RSRP threshold on the serving cell, then that threshold is met only at time t1 (or very shortly before, if WTRU reporting is accounted for). And it is at this point in time when the WTRU measurements on neighbor cell candidates are the most reliable, in terms of useful information for the NW to coordinate HO procedures

[0194] Therefore, during times tO and t1 , there may be new conditions that the WTRU can assess to provide reporting of neighbor cell measurements to the NW, providing both signalling reduction benefits, as well as the benefit of providing extra information to the NW that may be useful for mobility strategies. In the former case, even if it is left to WTRU implementation when to actually start the measurements for neighbor cells, it is worth pointing that the reporting of the measurements implies that the WTRU actually started to measure them.

[0195] As previously described, a WTRU may be configured with an s-measure (e.g., RSRP threshold), and it may start performing neighbor cells measurements only when the serving cell radio level falls below the s-measure. This may help in reducing the WTRU battery consumption since the WTRU may perform neighbor cell measurements only when the serving cell is not in good conditions (e.g., no neighbor cell measurements when the WTRU is near the cell center, and neighbor cell measurements when the WTRU is outside the cell center).

[0196] In one example, the WTRU may be configured with s-measure values that are dependent on the predicted time of stay in the serving cell.

[0197] In one example, the WTRU is provided with a set of predicted time of stay in the serving cell and s- measure values. For example:S-measure value of RSRPJhreshoIdl and time of stay duration threshold of timejhresholdl ,S-measure value of RSRP_threshold2 and time of stay duration threshold of timejhreshold2,S-measure value of RSRP_threshold3 and time of stay duration threshold of time_threshold3,

[0198] Assume time_threshold1 > time_threshold2 > timejhreshold3, and RSRPJhreshoIdl < RSRPJhreshold2 < RSRPJhreshold3. If the expected time of stay in the cell is very short, the WTRU may need to start performing neighbor cell measurements even if the serving cell RSRP is still very strong. That means, the shorter the predicted time of stay in the cell, the higher the s-measure threshold. On the other hand, the longer the predicted time of stay in the cell, the lower the s-measure threshold, as if the expected time of stay in the cell is long, the WTRU may refrain from performing neighbor cell measurements even if the serving cell is not that strong

[0199] In one example, the WTRU may be configured to perform the time of stay duration prediction only if it has determined that one of the s-measure thresholds have been fulfilled (e.g., the serving cell signal level is below the largest s-measure, or it is below the smallest s-measure).

[0200] In one example, the WTRU may be configured with a fallback s-measure that it uses regardless of the time of stay prediction. That is, if the serving cell signal level falls below this threshold, the WTRU will start performing the neighboring cell measurements regardless of the predicted time of stay duration in the current cell.

[0201] In one example, the WTRU may be configured with a baseline s-measure value and scaling factors to determine the s-measure depending on the time of stay duration. For example,S-measure value of RSRPJhreshoIdl for time of stay duration threshold of timejhresholdl or above, orScale the s-measure by alpha for time of stay durations of below timejhresholdl, where alpha may be, e.g., timejhresholdl / predicted-time-of-stay-duration.

[0202] In one example, the WTRU may be configured with one s-measure as in legacy, but the type of neighbor cells that it measures can be configured to be dependent on the predicted time of stay duration. For example, when the serving cell radio level falls below the s-measure, the WTRU may start performing intrafrequency neighbor cells if the time of stay duration is expected to be below timejhresholdl . If the expected time of stay duration falls below timejhreshold2 (timejhresholl > timejhreshold2), the WTRU may start performing inter-frequency neighbor cells.

[0203] The embodiments herein are simple from a technical implementation point of view. We present however some additional ways the s-measure may be related with the time of stay in a cell.

[0204] Following are examples of events / conditions for the WTRU to start measuring neighbor cell related quantities, and that may lead to the WTRU reporting to the NW. the conditions leverage on the definitions of time of stay in cell, that is predicted e g., by the WTRU.

[0205] The coverage of a cell in a live deployment is not ideal as depicted in FIG. 2Error! Reference source not found.. In the figure, the s-measure would be the same for all WTRUs in the cell. In real scenarios, the WTRU’s location and trajectory create a need to associate the time of stay in a cell with the s-measure. This is again valid for all definitions of time of stay in a cell, not just an actual time

[0206] The WTRU may be configured to start measurements related to neighbor cells based on different s- measure thresholds associated with different times of stay in a cell. Both the s-measure threshold and the time of stay in a cell may be represented as a point value or an interval or range. Examples include: one on one mappings of a s-measure threshold(s) to a time to stay in a cell, e.g., s-measure threshold of ‘x’ for time of stay in a cell ‘a’, s-measure threshold of ‘y’ if time of stay in a cell ‘b’; one on one mappings of a s-measure threshold(s) to an interval of time to stay in a cell, e.g., s- measure threshold of ‘x’ for time of stay in a cell interval ‘[a,b]’, s-measure threshold of ‘y’ for time of stay in a cell interval '[c,d]’; one on one mappings of a s-measure interval(s) to a time to stay in a cell, e.g., s-measure interval of '[x,y]’ for time of stay in a cell ‘a’, s-measure interval of ‘[p,q]’ for time of stay in a cell ‘b’; one on one mappings of a s-measure interval(s) to a time to stay in a cell interval, e.g., s-measure interval of [x,y] for time of stay in a cell interval [a,b], s-measure interval of [p,q] for time of stay in a cell [c,d];

[0207] The definition of time of stay in a cell may encompass different events, both when they happen and / or when they are predicted to happen. The different s-measure thresholds and / or intervals above may also be associated with different conditions that the WTRU is monitoring to determine the time of stay in a cell. Associating the different WTRU monitored events to an s-measure, provides means to further configure the WTRU to report on neighbour cells when other conditions also make it beneficial to report. As a first example, the WTRU may be configured with a s-measure threshold for a time of stay in a cell equal to ‘a’. This may serve the purpose of reporting if cell measurements are the only relevant conditions for the scenario of the application. However, in a second example, the WTRU may be configured with a second s-measure threshold for time of stay in a cell equal to ‘a’, but with a condition that the time of stay in a cell was obtained due to the WTRU’s UL buffer level falling above / below a threshold. This would be particularly useful if the WTRU’s UL buffer is very high, and it may make the WTRU report earlier to the NW on neighbors, with an s-measure threshold that is theoretically lower than in the first example. As another example, the WTRU may predict RLF will occur or be declared without the legacy s-measure criterion being satisfied. If the time of stay in a cell is defined as the time when the RLF is predicted to happen, then it would make sense to configure the s-measure threshold at the WTRU as a delta value to apply to the current RSRP of the serving cell. This would serve the purpose ofavoiding the RLF, by making the WTRU report on neighbor cell measurements and the NW may decide, before the RLF happens.

[0208] Many more combinations are possible. Below is a non-limiting description of possible ways that the time of stay in a cell and the s-measure can be associated so that a WTRU starts measurement procedures on neighbor cells. The list is built based on the definition of time of stay in a cell. In different solutions, the s- measure can be associated with different events. For example, a measurement at the WTRU (e.g., RSRQ, SINR) falling above / below a threshold. This may be useful as the WTRU can be in a situation where the signal quality is low or interference levels are high, even in good RSRP coverage conditions, i.e. , without meeting the s-measure criteria. If this is the case, nothing should prevent the WTRU (e.g., by NW configuration) to set a timer from this measurement hitting the threshold, assess a second RSRP, RSRQ and / or SINR threshold(s), a delta RSRP amount from the current RSRP measurement, etc., to start measuring neighbor cells.

[0209] As another example, a predicted measurement (e g., RSRP, RSRQ, or SINR) falling above / below a threshold. If the s-measure criterion is not satisfied, but the WTRU or the NW predict that a measurement value will fall above / below a threshold, then it would be useful for the WTRU to start assessing candidate cells before the predicted measurement value occurs (or measurement event, as a consequence) If this is the case, nothing should prevent the WTRU (e.g., by NW configuration) to set a timer from this predicted measurement hitting the threshold, assess a second RSRP threshold, a second predicted RSRP threshold, a delta RSRP amount from the current RSRP measurement, etc , to start measuring neighbor cells.

[0210] For example, an UL buffer level falling above / below a threshold. This would be useful for example due to high UL buffer levels at the WTRU, as explained above, but also in the case of low UL buffer levels. In the latter case, the NW may want the WTRU to report on neighbors for the possibility of handing the WTRU over for load balancing and / or NW energy savings, e.g., to switch a cell off. If this is the case, nothing should prevent the WTRU (e.g., by NW configuration) to set a timer from the UL buffer hitting the threshold, assess a second RSRP, RSRQ and / or SINR threshold(s), a delta RSRP amount from the current RSRP measurement, a delta UL buffer level amount from the buffer level that hit the threshold, etc., to start measuring neighbor cells.

[0211] For example, a predicted UL buffer level falling above / below a threshold. This would be useful for the same reasons as described above, but with the UL buffer levels being predicted. The same additional conditions can be associated with the predicted UL buffer levels as described above.

[0212] For example, a number of re-transmissions falling above / below a threshold. If the WTRU follows a trajectory that keeps it at the cell edge as depicted in FIG. 2, it is likely that the number of re-transmissions increases. In the cases where the s-measure is not optimally tuned, or if interference levels are high, the number of re-transmissions will increase Measuring candidate cells for mobility is then useful in this context, so that the NW can prepare a HO in an effort to decrease the number of re-transmissions. The number of retransmissions can also be lower than a threshold, while the s-measure criterion is met. This would indicate that the WTRU still experiences good channel conditions, despite being at the cell edge, and keeps reporting on neighbors due to the s-measure rule. In this case, association with re-transmissions would reduce requiredsignalling. If this is the case, nothing should prevent the WTRU (e.g., by NW configuration) to set a timer from the number of re-transmissions hitting the threshold, assess a second RSRP, RSRQ and / or SINR threshold(s), a delta RSRP amount from the current RSRP measurement, a delta number of re-transmissions from moment this number met the threshold, etc.

[0213] For example, a number of predicted re-transmissions falling above / below a threshold. This would be useful for the same reasons as in the previous bullet, but this time, the UL buffer levels are predicted. Same additional conditions can be associated with the predicted number of re-transmissions as in the previous bullet.

[0214] In case of Radio Link Failure (RLF), its time of occurrence or its expectation of occurring may define the time of stay in a cell. Optionally, the time of stay in a cell may be defined as a certain delta time before RLF. Specific measurement events may be configured in the WTRU to help avoid RLF:A specific number in the counters affecting RLF determination (e.g., if the WTRU determines / declares RLF after N instances of the counters, then N-X may be the time associated with the time offset).A predicted time for when X above will happenA predicted time for when RLF will happen.

[0215] The WTRU may be configured to set a timer from the current time, assess a second RSRP, RSRQ and / or SINR threshold(s), a delta RSRP amount from the current RSRP measurement, a delta number of X above from moment this number met the threshold. As described before, the WTRU may assess all values as point or as intervals / ranges values.

[0216] In legacy measurement configuration, since the WTRU may be configured with only one s-measure for an SPCell (e.g., one s-measure for PCell, another s-measure for PSCell), when the network receives a measurement report from the WTRU, the network implicitly knows that the neighbor cell measurements were triggered due to the serving cell measured value being below the s-measure.

[0217] In the above solutions, where the WTRU may be configured to use different s-measure values for different predicted time of stay durations, it won’t be clear to the network which s-measure triggered the performing of the neighbor cell measurements For example, if the WTRU was configured with s-measures of RSRP_threshold_1 and RSRP_threshold_2 (assume RSRP_threshold_2 < RSRP_threshold_1) that correspond to two different time of stay durations and, in the WTRU measurement report, the serving cell results were below RSRP_threshold_2, the network will not be able to know which s-measure triggered the neighbor cell measurements. As such, the network will not be able to fine tune the s-measure values properly.

[0218] In one example, when the WTRU may send a measurement report, it may include an indication which s-measure triggered the measurement of the neighboring cells. In another solution, the WTRU may further include the predicted time of stay duration that also triggered the usage of that s-measure, which can be different from the time of stay duration threshold that was configured to be associated with the concerned s-measure, .e g., time of stay duration for that s-measure may have been set to be 3 seconds, but the predicted time of stay duration was actually 2 seconds, and the WTRU indicates the 2 seconds.

[0219] In one example, the above solutions of s-measures that depend on expected time of stay duration in the serving cell may be applicable only if the WTRU has stayed for less than a configured time duration in that cell (e.g., if the WTRU has stayed more than 5 minutes in that cell, WTRU falls back to legacy operation with one fall back / baseline s-measure value.)

[0220] In one example, the above solutions of s-measures that depend on expected time of stay duration in the serving cell are applicable only after the WTRU has stayed for at least a configured time duration in that cell.

[0221] In one example, the above solutions of s-measures that depend on expected time of stay duration in the serving cell are applicable only if the WTRU’s mobility state is below / above a certain threshold or between two thresholds (e.g., below a certain configured m / s threshold).

[0222] In one example, the WTRU may be configured with an UL buffer threshold, and if the UL buffer threshold is above / below the configured buffer threshold, it will resort to using the legacy (baseline) s-measure, regardless of the predicted time of stay in the serving cell.

[0223] In one example, the WTRU may be configured with a data activity level (e.g , data rate in the UL or / and DL direction, the inactivity time since the last UL and / or DL transmission, etc.) and if the activity level is above / below the configured threshold, it will resort to using the legacy (baseline) s-measure, regardless of the predicted time of stay in the serving cell.

[0224] The solutions related to UL buffer level and UL / DL data activity level ensure that the UL / DL transmission to a WTRU that has heavy traffic will not end up creating lots of interference in neighboring cells (without such solutions, the s-measure for the WTRU would have been set to a very low value due to the longer expected time of stay in the cell, and the WTRU would not have started the neighbor cell measurements and subsequent measurement reports would not have been sent to facilitate the handover of the WTRU to a neighbor cell.)

[0225] The WTRU may include detailed information about target cells, such as expected time of stay, expected average quality in the measurement report. The WTRU may be configured to provide detailed information about the different target cells in the measurement report. The WTRU may indicate the likelihood of a particular neighbour cell being the target cell and / or expected time of stay in that target cell, and / or expected average quality in that target cell, etc.

[0226] A WTRU may trigger, based on a configured criteria, the sending of detailed information related to HO candidate cells, such as predicted time of stay in a cell, predicted average quality, confidence or likelihood of a target cell being the best cell, etc. Additionally, the WTRU may execute a HO, e.g., via a received OHO configuration, based on the detailed information that it determines.

[0227] The WTRU may transmit to the network the capability to predict detailed information about a neighbour cell (e.g., likelihood of neighbour cell being the target, predicted time of stay in a neighbour cell, average radio quality in a neighbour cell, etc.). The WTRU may receive a measurement (or reporting)configuration (e.g., legacy Ax event, periodic reporting configuration, and configuration based on predicted time ofstay left in current serving cell), and configuration to include detailed information about one or more neighbour cells.

[0228] The WTRU may determine reporting conditions are fulfilled (e.g , based on one or more of: measurements, determined predicted time of stay left in a current serving cell, configured reporting events, reporting configuration).

[0229] The WTRU may predict detailed information about one or more neighbour cells and may send a measurement report that includes the detailed information and identities of the one or more neighbour cells.

[0230] The WTRU may select a subset of neighbour cells for which to report detailed information, based on one or more of: measurements or predicted detailed information of one or more neighbour cells, ranking of measurements or predicted detailed information of one or more neighbour cells, configured thresholds. For example, the WTRU may report neighbour cell measurements for neighbour cells whose measurements or predicted detailed information is greater than of minimum threshold.

[0231] In one example, the WTRU may be configured to send information regarding the likelihood of a certain neighbor cell being the chosen target cell (e.g., when sending a measurement report). The likelihood of each neighbor cell may be represented by a confidence value, e.g., a percentage, or an interval of confidence, i.e. , as an example, an interval of values for the likelihood with a certain measure of confidence of the interval.

[0232] In one example, the AIML model the WTRU may use for the determination of the likelihood of a certain neighbor cell being a HO target may be trained based on extensive (measurement) data related to the HOs that is collected by the WTRU. For example, the WTRU may be configured to collect information about the fulfilment of a certain event related to current serving cell measurement (e.g , A2 event), what the neighbor cell measurements were at that time, and to which neighbor cell the WTRU is handed over to. This information may contain additional information such as the time of day and location information (e g., if WTRU has GNSS location information). A model that is trained based on such information may then take a certain event fulfilment as an input and output the likelihood / probabil ity of each neighbor cell being the target cell for the HO.

[0233] In one example, the WTRU may be configured to send information regarding the expected time in a neighbor cell (e.g., when sending a measurement report).

[0234] In one example, the expected time in a neighbor cell, which is the time the WTRU is expected to stay in that neighbor cell, has the WTRU been handed over to that cell at the time the WTRU sent the measurement report to the network including the expected time of stay.

[0235] In one example, the AIML model the WTRU is using for the determination of the expected time of stay in a neighbor cell may be trained based on extensive (measurement) data that is collected by the WTRU related to HOs that were performed to that target cell. For example, the WTRU may be configured to collect information regarding the time the WTRU spent in that cell after being handed over to it, before it is handed over to another cell again, and what the serving cell and neighbor cell measurements were at the time theWTRU was first handed over to that cell. This information may contain additional information such as the time of day and location information (e.g., if WTRU has GNSS location information).

[0236] In one example, the WTRU may be configured to send information regarding the expected quality (e g., average quality) in a neighbor cell (e.g., when sending a measurement report)

[0237] In one example, the expected quality in a neighbor cell is the quality that the WTRU is expected to have during the time it is expected to stay in that neighbor cell, has the WTRU been handed over to that cell at the time the measurement report that includes the expected quality of that cell is sent to the network

[0238] In one example, the expected quality in a neighbor cell includes additional information (e.g., other statistical information) apart from the average. For example, this may be the maximum, minimum, standard deviation, mode To avoid one particular signal sample biasing the information, the WTRU may be provided with further parameters / configuration to filter out the measurements. For example, the measurements are filtered / averaged for a certain minimum duration or number of measurement samples to be considered as one sample / record in the data being collected.

[0239] In one example, the Al M L model the WTRU is using for the determination of the expected quality in a neighbor cell may be trained based on extensive (measurement) data that is collected by the WTRU related to HOs that were performed to that target cell. For example, the WTRU may be configured to collect information regarding the average radio link quality over the whole duration the WTRU spent in that cell after being handed over to it, before it is handed over to another cell again, and what the serving cell and neighbor cell measurements were at the time the WTRU was first handed over to that cell. This information may contain additional information such as the time of day and location information.

[0240] In one example, the average radio link quality is collected only for a certain configured time duration after the HO (i.e , not for the whole duration the WTRU stayed in the cell).

[0241] In one example, when the WTRU is gathering information related to average radio quality, the WTRU may be provided with filtering parameters, so that the WTRU will use a weighted averaging. For example, the radio link quality samples during the initial stages after the HO to that cell, e.g., the first ‘x’ ms, have more weight than the radio link quality samples during the later stages (e.g., after the first ‘x’ ms).

[0242] In one example, the WTRU may trigger measurement reporting based on legacy conditions (e.g., periodic reporting, or the fulfilment of Ax / Bx events) or conditions associated with the current serving cell (e.g., predicted time of stay in the serving cell falls below a certain threshold) and the WTRU may include the detailed information that it has determined about the neighbor cells that are included in the measurement report.

[0243] In one example, the WTRU may be configured to send a measurement report based on a threshold related to the predicted time of stay in a neighbor cell. For example, the WTRU may be configured to send a measurement report when it determines that there is a neighbor cell that the WTRU is expected to stay for more than a certain threshold time duration.

[0244] In one example, the WTRU may be configured to send a measurement report based on a threshold related to the likelihood of a neighbor cell being a target cell. For example, the WTRU may be configured to send a measurement report when it determines that there is a neighbor cell that the has a likelihood of being the target cell for the WTRU that is larger than a certain likelihood threshold.

[0245] In one example, the WTRU may be configured to send a measurement report based on a threshold related to the expected radio quality (e.g., average link quality) of a neighbor cell. For example, the WTRU may be configured to send a measurement report when it determines that there is a neighbor cell that the has an expected radio quality (e.g., average link quality) that is better than a certain quality threshold.

[0246] In one example, the WTRU may be configured with additional conditions related to more than one of the above conditions (e.g., conditions on the time of stay and average expected quality).

[0247] In one example, the WTRU may be configured with a signal level threshold(s) of the serving cell and / or a neighbor cell, and a threshold related to one or more of the conditions above (e.g., expected time of stay in the neighbor cell, average expected quality, and / or likelihood). In one example, the WTRU may trigger the measurement report if the serving cell and / or the neighbor cell fulfills the signal level threshold(s) and the predicted time of stay in the neighbor cell. For example, the WTRU may trigger a report if any of the neighbour cells meets the configured threshold, or if a specific neighbour cell meets the configured threshold, or if only the serving cell meets the threshold, or if both the serving cell and one or more neighbour cells meets the threshold.

[0248] In one example, the WTRU may be configured to include in the measurement report only the information related to the best ‘n’ neighbor cells, where the best neighbor cell is defined to be the cell where the WTRU is expected to stay the longest

[0249] In one example, the WTRU may be configured to include in the measurement report only the information related to the neighbor cells where the expected time of stay in that neighbor cell is greater than a certain configured threshold.

[0250] In one example, the WTRU may be configured to include in the measurement report only the information related to the best n neighbor cells, where the best neighbor cell is defined to be the cell that has the highest likelihood (e.g., percentage) of being a target.

[0251] In one example, the WTRU may be configured to include in the measurement report only the information related to the neighbor cells with a likelihood of being a target is above a certain configured (e.g., percentage) threshold.

[0252] In one example, the WTRU may be configured to include in the measurement report only the information related to the best n neighbor cells, where the best neighbor cell is defined to be the cell that is expected to provide the highest quality (e.g., best average radio link quality).

[0253] The examples above may also be used as event triggers for measurement reporting. A measurement report may be triggered as soon as any of the information which is to be included in ameasurement report is available in the WTRU. the WTRU may send a measurement report that includes the detailed information about the neighbor cell or / and it will trigger a measurement report based on the detailed information about the neighbor cells. In another example, the WTRU may execute a HO based on a CHO configuration. The WTRU may still report the detailed information, even if a CHO is executed towards a target cell, based on the detailed information.

[0254] In one example, the WTRU may be configured to execute a CHO based on triggering conditions that are related to the detailed information about the neighbor cells (e.g., in addition to legacy CHO triggering conditions). Several new / enhanced CHO triggering conditions may be added to the WTRU configuration, such as:Serving cell and neighbor cell fulfill radio thresholds (e.g., Cond A3, Cond A5), and the expected time of stay in the neighbor cell is above ‘x’ ms.Serving cell and neighbor cell fulfill radio thresholds (e.g., Cond A3, Cond A5), and the average expected radio quality in the neighbor cell is above an RSRP threshold.Serving cell and neighbor cell fulfill radio thresholds (e.g., Cond A3, Cond A5), and the expected time of stay in the neighbor cell is above ‘y’ ms, and the average expected radio quality in the neighbor cell is above an RSRP threshold.

[0255] In one example, if more than one cell fulfills the CHO conditions, the WTRU may prioritize one of the target cells based on one or more of the following:Prioritize the cell where the WTRU is expected to have the longest time of stay; prioritize the cell where the WTRU is expected to have the best average quality; or prioritize the cell that has the highest radio quality (at the time of the CHO triggering).

[0256] In one example, the WTRU may use the collected information to train its own model. In another example, the WTRU may send the collected information to the network or an entity outside the radio / core network (e.g., an OTT server), where the training occurs.

[0257] Though HOs are typically decided based on measurements (i.e., to have the WTRU served by the best cell in terms of signal strength), there are cases where WTRU is handed over, for load balancing purposes, to a cell with lower signal strength than the serving cell. There are also cases where the WTRU is kept longer in the serving cell even though there was a neighbor cell with a better signal strength.

[0258] In one example, to differentiate the HO cases done due to reasons other than radio conditions, the network may indicate to the WTRU in the HO command additional information (e.g., a flag in the HO command indicating that the HO was triggered due to reasons other than radio). In one example, the WTRU may disregard the collected information that is associated with this handover occasion (if it is doing the model training itself). In another example, if the training is performed elsewhere (e.g., in an OTT server, a server outside the RAN but within the network that doesn’t have information about why the HO decision was made), the WTRU may flag the information that is associated with this HO instance accordingly (e.g., a flag / indication in the recordcorresponding to this HO occasion). This way, the training entity will be able to differentiate the HOs that were done due to radio reasons and the HOs that were taken due to load or other reasons.

[0259] In one example, the WTRU may be configured to implicitly disregard the information collected corresponding to a particular HO if it determines that the HO was performed to a cell that didn’t have the highest signal level among the neighbor cell that the WTRU has indicated in a measurement report prior to the HO.

[0260] In one example, the WTRU may be configured to implicitly disregard the information collected corresponding to a particular HO if it determines that the HO was performed to a cell that has a lower signal level than the source cell.

[0261] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magnetooptical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMSWhat is Claimed:

1. A method to be performed by a wireless transmit and receive unit (WTRU), the method comprising: transmitting, to a network, capability to predict a time of stay in a cell; receiving, from the network, a configuration message, wherein the configuration message comprises a condition for the WTRU to send a notification to the network, wherein the condition is associated with a predicted time of stay in a cell; determining the predicted time of stay in the cell; and sending, based on the condition being met, the notification to the network.

2. The method of claim 1, wherein the condition comprises the predicted time of stay in the cell being less than a configured threshold.

3. The method of claim 1 or claim 2, wherein the notification to the network comprises at least one of a predicted time of stay in the cell, a predicted buffer level when leaving the cell, or a predicted signal level when leaving the cell.

4. The method of any one of claims 1-3, wherein the cell is a serving cell.

5. The method of any one of claims 1-4, wherein the predicted time of stay in a cell is a predicted time when the WTRU receives a message from the network triggering a handover.

6. The method of any one of claims 1-5, wherein the predicted time of stay in a cell is a predicted time when the WTRU sends a message to the network indicating a successful handover was performed.

7. The method of any one of claims 1-6, wherein the predicted time of stay in a cell is a predicted time when an RSRP value measured at the WTRU is less than a configured threshold.

8. The method of any one of claims 1-7, wherein the predicted time of stay in a cell is a predicted time when the WTRU receives an indication from the network in a downlink control information (DCI) or a medium access control (MAC) control element (CE).

9. The method of any one of claims 1-8, wherein the predicted time of stay in a cell is determined when the WTRU receives an indication from the network in a radio resource control (RRC) message.

10. A wireless transmit and receive unit (WTRU), the WTRU comprising at least one processor and a transceiver, wherein: the at least one processor and the transceiver are configured to: transmit, to a network, capability to predict a time of stay in a cell;receive, from the network, a configuration message, wherein the configuration message comprises a condition for the WTRU to send a notification to the network, wherein the condition is associated with a predicted time of stay in a cell; determine the predicted time of stay in the cell; and send, based on the condition being met, the notification to the network.

11. The WTRU of claim 10, wherein the condition comprises the predicted time of stay in the cell being less than a configured threshold.

12. The WTRU of claim 10 or claim 11, wherein the notification to the network comprises at least one of a predicted time of stay in the cell, a predicted buffer level when leaving the cell, or a predicted signal level when leaving the cell.

13. The WTRU of any one of claims 10-12, wherein the cell is a serving cell.

14. The WTRU of any one of claims 10-13, wherein the predicted time of stay in a cell is a predicted time when the WTRU receives a message from the network triggering a handover.

15. The WTRU of any one of claims 10-14, wherein the predicted time of stay in a cell is a predicted time when the WTRU sends a message to the network indicating a successful handover was performed.

16. The WTRU of any one of claims 10-15, wherein the predicted time of stay in a cell is a predicted time when an RSRP value measured at the WTRU is less than a configured threshold.

17. The WTRU of any one of claims 10-16, wherein the predicted time of stay in a cell is a predicted time when the WTRU receives an indication from the network in a downlink control information (DC I) or a medium access control (MAC) control element (CE).

18. The WTRU of any one of claims 10-17, wherein the predicted time of stay in a cell is determined when the WTRU receives an indication from the network in a radio resource control (RRC) message.

Images